Claude Skill図鑑#2: Understand-Anything — コードベースを「読み物」に変えるSkill

2026年5月9日 14:25

Anthropic公式のClaude Code Skillから、GitHubで人気のオープンソースSkillまで、私が実際に自分の手で動かしてレビューしていく「Claude Skill図鑑」

シリーズ第1回では UI/UX 系の OSS Skill「ui-ux-pro-max」を公式 frontend-design Skill と比較しました。

今回は Coding カテゴリに移って、コードベース解析 Skill の「Understand-Anything」を実際に動かしてみます。

本記事では、Understand-Anything を line-harness-oss(LINE 公式アカウントの OSS CRM)に対して走らせ、素の Claude Code(/init + CLAUDE.md 生成)と比較した結果をレビューします。

「コードベース全体を可視化してくれる Skill」と聞くと、バイブコーダーが自分のプロダクトを把握したい場面で万能のように見えます。しかし、実際に動かしてみると、規模感によって体験がはっきり変わるのが分かりました。具体的には、350 ファイル規模の OSS では分析にそれなりの時間とトークンを消費する一方、生成される出力は「教材として読ませる」用途では独自の価値があります。

この温度差をどう評価するかが、本記事の中心テーマです。

結論

350 ファイル規模の OSS だと、分析に十数分・相応のトークン消費。日常的に回すには重い。
出力の独自価値は「12 ステップのガイド付きツアー」「言語/技術概念の補足解説(LANGUAGE LESSON)」「インタラクティブダッシュボード」の 3 点に集約される。素の Claude では出ない体験。
自分のバイブコーディングプロダクト(目安 100〜300 ファイル程度)を第三者に説明する用途には向いている。逆に、大規模 OSS の精読や、行番号レベルでの追跡には素の Claude のほうが向く。

詳細は以下で解説します。

サンプルコードについて

検証には、野田氏(Shudesu)が公開している line-harness-oss を勝手に使わせていただきました。LINE 公式アカウントを運用するためのオープンソースの CRM(顧客管理ツール)で、Cloudflare のサーバレス環境で 0 円から動かせる、というのが売りのプロダクトです。

このリポジトリをサンプルに選んだ理由は 2 点です。

個人開発者が短期間で作ったプロダクトとして規模感がちょうどよい(後述しますが、Skill が想定する閾値を超える絶妙なサイズ)
Claude Code を前提にしたリポジトリで、Claude Code 用 Skill で解析するというメタ構造が面白い

なお、本記事の評価対象はあくまで Understand-Anything Skill です。line-harness-oss そのものへの批評や評価は射程外で、コードを Skill に読ませて挙動を観察した記録として書いています。コードを公開してくださっていること自体に、まず感謝を申し上げます。

Understand-Anything とは

リポジトリ: github.com/Lum1104/Understand-Anything
スター数: 約 5.5k(取り上げ時点)
配布形態: Claude Code のプラグインマーケットプレイス経由

雑にまとめると「コードベース全体を読んで、新しく入る人向けの社内研修資料を自動生成する Skill」というのが私の理解です。

サンプルコード: line-harness-oss について

検証対象を簡単に紹介します。

ポイントは、Cloudflare Workers の単一 Worker に API・管理画面・5 分ごとの cron まで全部集約された構成で、サーバ代 0 円で動かせる点です。

「個人で作るプロダクトの上限近くだろう」という想定でこれを選んだのですが、結果としてその想定がちょうど Skill の限界とぶつかることになりました。

検証環境と方針

検証は 2 段階で実施しました。

Round 1: Skill を入れない素の Claude Code で、/init を打って全体を読ませる → コアドメインの実装を質問する → 説明資料を作らせる
Round 2: Understand-Anything を入れて、Round 1 と同じ問いをもう一度

実施順は Round 1 → Round 2 ですが、記事では「同じ問いに対する両者の出力を並べる」ほうが読みやすいので、テーマごとに比較していきます。

セットアップ

Understand-Anything のインストールは Claude Code のプラグインコマンド 2 行で完了します。

/plugin marketplace add Lum1104/Understand-Anything
# → Successfully added marketplace: understand-anything

/plugin install understand-anything
# → Installed understand-anything. Run /reload-plugins to apply.

/reload-plugins

LLM API の追加設定や別途のサーバ準備も不要で、ここは特に詰まりませんでした。

検証

想定外の足止め: 「全部走らせるか、絞るか」を聞かれる

/understand-anything:understand コマンドを実行すると、いきなりフル走査が始まる、と思っていたら違いました。Skill 側がまず立ち止まって、こう警告してきます。

No existing graph — running full analysis. Let me gather project context.
Searched for 3 patterns, read 2 files

344 files — well over the 100-file threshold.
Let me get a breakdown before deciding.

つまり、Skill には「100 ファイル」という閾値が設計上組み込まれているということです。それを超えると、フル走査の前にユーザーに判断を求めてきます。

続けて、apps と packages のファイル数の内訳と、こんな選択肢が提示されました。

File breakdown:
- apps/worker        — 71 files (Cloudflare Worker / API)
- packages/db        — 61 files (D1 migrations + schema)
- apps/web           — 49 files (Next.js dashboard)
- packages/mcp-server — 37 files
- packages/sdk       — 34 files
- docs/wiki          — 25 files
- packages/create-line-harness — 18 files
- packages/plugin-template     — 11 files
- packages/line-sdk  — 9 files
- docs/manual        — 8 files
- packages/shared    — 5 files
- Top-level          — ~16 files

At ~25 files per batch with 5 concurrent subagents,
this will take a while (≈14 batches across multiple analysis rounds).
It will also burn a lot of tokens.

「時間かかるし、トークンもかなり消費する」と素直に警告してくれたのがありがたい。そのうえで、4 つの選択肢を提示してきます。

(a) Full repo       — analyze everything (~14 batches, longest)
(b) Scope to area   — apps/worker (71 files) or apps/web (49 files)
                      or packages/ (175 files)
(c) Code-only       — skip docs/wiki and migration SQL files (~80+ files cut)
(d) Subdomain split — analyze each app/package separately and merge

検証なので (a) のフル走査を選びましたが、現実的な運用では (b) や (c) を選ぶことになると思います。「全部やるかどうかを Skill 側が確認してくる」設計はコスト感覚として正しいと感じました。

Round 1: 素の Claude(/init)が出した全体像

/init で生成された CLAUDE.md は、リポジトリの README と AGENTS.md と主要なソースを舐めて、運用ルール・構成・cron で並列実行されるジョブの一覧・命名のクセまで言語化されたドキュメントになりました。

そのうえで「LINE Harness の全体像を説明して」と聞くと、アスキーアートの構成図 + ディレクトリの役割表 + 「効いてくる設計判断」が、自分の言葉で整理された形で返ってきます。

例えば「友だちは LINE のユーザー ID ではなく内部 UUID で管理している。1 人の人が複数 LINE アカウントに紐づく前提で設計されている」といった、コード読まないと分からない設計意図まで言語化されていました。

正直、この時点でかなり完成度の高い「プロダクトの地図」になっています。

Understand-Anything が出した全体像

一方、Understand-Anything のほうは、まず 14 バッチに分けて 350 ファイルを並列で読み込みます。完了後の出力統計はこんな感じです。

/understand complete

Project: line-oss-crm (LINE Harness)
Output:  .understand-anything/knowledge-graph.json (467 KB)

Files analyzed: 350 / 350 across 14 batches
- code: 241 / docs: 47 / data: 31 / config: 28 / markup: 2 / infra: 1

Nodes: 591
- file: 243 / function: 210 / document: 47 / class: 31 / table: 30 / config: 28 / schema: 1 / pipeline: 1

Edges: 638
- contains: 240 / exports: 146 / imports: 68 / depends_on: 63 / configures: 37
  / documents: 34 / migrates: 21 / related: 15 / tested_by: 7 / deploys: 3

8 architectural layers:
1. Admin Web UI (apps/web — 52 files)
2. API & Webhook Worker (apps/worker — 72 files)
3. Data Layer (packages/db — 61 files)
4. Public SDK & Shared Types (47 files)
5. MCP Server (37 files)
6. Setup CLI & Plugin Template (28 files)
7. Documentation (48 files)
8. Project Config & CI (5 files)

12-step guided tour:
README → monorepo skeleton → Worker kernel → middleware → webhook
→ DB → outgoing messages → admin UI → SDK → MCP server
→ setup CLI → CI/CD

/understand-anything:understand-dashboard でローカル Web サーバーが立ち上がって、ブラウザで対話的に閲覧できます。ここが素の Claude では出ない体験でした。

ダッシュボードの特徴は次の 3 点です。

8 層に自動分類されたアーキテクチャマップ: 各層がカード状に並び、ファイル数と複雑度ラベル(simple / moderate / complex)が表示される
12 ステップのガイド付きツアー: README → モノレポ構造 → Worker 本体 → 認証ミドルウェア → Webhook → DB → 配信エンジン → 管理画面 → SDK → MCP サーバ → セットアップ CLI → CI/CD、という「読む順番」が明示される
LANGUAGE LESSON: 各ステップで、関連する技術概念(Hono、HMAC、pnpm workspace、GitHub Actions など)の補足解説が勝手についてくる

検索・フィルタ・パス機能も使えて、「マークダウンドキュメントではなく、対話可能な参照資料」として作られていることがわかります。

コアドメインの理解で比較する

「LINE のメッセージ配信がどう実装されているか」を両者に聞いてみました。

素の Claude: 共通基盤(SDK ラッパ + 速度制御層)→ ブロードキャスト 4 経路の分岐 → ステップ配信のフロー → cron 全体図、と階層構造で説明。ファイル名と行番号レベルで参照(broadcast.ts:207-213 等)が貼られて、コードのどこを見ればよいか具体的に分かる
Understand-Anything: 12 ステップツアーの「Outgoing Messages」ステップで該当領域を扱う。レイヤー単位の解説 + LANGUAGE LESSON。深さは素の Claude より浅め

つまり、「精読には素の Claude」「教材化には Understand-Anything」という棲み分けが見えてきました。

構成説明資料の作成

構成説明資料の作成で比較する

「第三者に説明する資料を作って」という依頼でも比較しました。

素の Claude: マークダウンの 1 ページ資料を生成。アスキー図 + 構成要素の表 + 設計判断 5 点 + ひとこと要約、という構成で、Slack やドキュメントツールにそのまま貼って使えるレベル
Understand-Anything: ダッシュボードの URL を共有して、相手にも触ってもらう前提。「相手が能動的に探索できる」点が強い。ただし、相手がローカルでダッシュボードを立ち上げる必要があり、共有のハードルは上がる

クライアント説明では、まず素の Claude のマークダウンで全体を伝えて、深掘りしたい相手にだけダッシュボードを案内する、というハイブリッドが現実的だと感じました。

構成説明資料での比較

クライアントへの説明用には、まず素の Claude のマークダウン資料で全体感を伝えて、興味を持った相手にだけダッシュボードの URL を共有する、というハイブリッドが現実的だと感じました。

良かった点

検証を通じて、Understand-Anything が独自に出している価値は次の 3 点に整理できました。

12 ステップのガイド付きツアー: 「README から CI/CD まで、どの順番で読めばいいか」が明示される。新しい人にコードを引き継ぐときの「順路」として使える
LANGUAGE LESSON: 関連技術概念を頼まなくても勝手に補足してくれる。教材として使える質
インタラクティブダッシュボード: 検索・フィルタ・探索機能など、静的なドキュメントには出せない体験

加えて、フル走査の前に「全部やるか、絞るか」を確認してきた挙動も好印象でした。LLM コストへの配慮が組み込まれているのは、Skill の設計として誠実です。

微妙だった点・ハマりポイント

1. 350 ファイル規模では「重い」と感じる

最大の論点はこれです。Skill 自身が「a while かかる、トークンもかなり消費する」と警告してきた通り、14 バッチの解析は待ち時間としても LLM コストとしてもそれなりの規模になります。

「コードを更新するたびに毎回回す」のは現実的とは思えませんでした。節目に 1 回回す、くらいが妥当です。

2. import 解決が不完全(57 個の孤立ノード)

解析完了後に、こんな警告が出ていました。

57 orphan nodes (no edges). Phase 1's import scanner only resolved imports for 7 of 350 files, so most cross-file imports edges are missing.

つまり、350 ファイルのうち 7 ファイル分しか import 解決できておらず、結果として 57 個の「孤立ノード」(他とつながりのない島)が発生した、ということです。

「グラフはまだ navigable」とは書かれていますが、ナレッジグラフの完全性を期待していた身としてはここは引っかかります。Cloudflare Workers + 静的エクスポートという独特の構成のせいかもしれませんが、Skill が想定する典型的な構成から外れた瞬間に、解析品質が落ちる可能性があるシグナルとして受け取りました。

3. ダッシュボード共有のハードル

ローカル http://127.0.0.1:5173 で立ち上がるので、第三者に見せるには静的エクスポートするか、画面共有するか、相手のローカルで再現してもらう必要があります。「URL を Slack に貼って一発で見せる」運用にはなりません。

代替手段との比較(進化スピード視点)

第 1 回から続いている問いとして、「OSS Skill が公開された時点と現在で、Claude 本体の能力がどれだけ進化しているか」「公式機能で代替できる部分は何か」を、本 Skill にも当てはめます。

現時点での Claude Code(Opus 4.7)の素の能力は、「コードベース全体を読んで地図を作る」用途では既にかなり高い水準です。/init で生成される CLAUDE.md は、設計意図の言語化や行番号レベルの参照を含めて、相当な質で出力されます。

そのうえで Understand-Anything が今もなお価値を提供できているのは、「テキスト出力ではない領域」に振っているからだと感じました。12 ステップツアーという順序付き教材、LANGUAGE LESSON のような勝手に出てくる概念解説、対話的なダッシュボード、ナレッジグラフ JSON という後段ツールに渡せる中間表現 — これらは素の Claude では「依頼すれば似たものは作れるが、毎回作り直し」になる部分です。

逆に、テキストの解説そのものの質では、素の Claude が追いつきつつある(あるいは超えている)領域もあります。本 Skill のスイートスポットは、**テキストの精緻さよりも「教材としての構造化」と「対話的な参照体験」**だと整理できます。

総合評価

評点: ★3.5 / 5
一言: 「規模が合えば、教材化 Skill として強い。ただし大規模リポジトリで日常運用するには重い」

評点が中央寄りなのは、プロダクトの規模次第で印象が大きく変わるからです。100 ファイル以下なら ★4、300 ファイル超なら ★3、と感じています。

こんな人におすすめ

自分のバイブコーディングプロダクト(目安 100〜300 ファイル程度)を第三者に説明したい人: クライアント説明や新メンバー向けオンボーディング資料の自動生成に向く
「コードを読ませる順番」を Skill に決めてもらいたい人: 12 ステップツアーは引き継ぎ時の読み順テンプレートとして役立つ
ナレッジグラフ JSON を後段の自動化に渡したい人: MCP サーバや社内ドキュメント生成へのフックとして使える

こんな人には不要

大規模 OSS(1,000 ファイル超)を解析したい人: コストが現実的でなくなる
行番号レベルの精緻な追跡が欲しい人: 素の Claude のほうが直接的
「動作確認のための一回きりの解析」目的の人: /init だけで十分
共有が「Slack に URL 貼って終わり」で済ませたい人: ダッシュボードの共有は別途検討が必要

まとめ

Understand-Anything は「コードベース可視化 Skill」として一括りにすると見誤る Skill でした。テキスト出力の精緻さでは Claude 本体に追われている一方、「教材化された対話的参照体験」という別軸で独自の価値を維持している、というのが私の結論です。

冒頭にも書いた通り、ユーザーの言葉を借りれば「自分の小さなプロダクトには向いている」というのが、もっとも素直な使い方だと思います。350 ファイル規模の OSS で評価すると重さが目立ちますが、自分が育てている 100〜200 ファイル程度のプロダクトを節目に教材化する用途なら、コストは十分許容範囲ですし、出力の独自価値が活きてきます。

第 1 回から続く視点として「OSS Skill と Claude 本体能力の進化のスピード差」がありますが、本 Skill については、棲み分けが明確になっているのが現時点の実感です。Claude 本体は「読み解き・精読」、Skill は「教材化・共有」。この区別を持って使い分けるのが、現実的な落とし所になりそうです。

なお、本記事のサンプルとして使わせていただいた line-harness-oss は、Claude Code から MCP 経由で操作できることを前提に設計された LINE 公式アカウント運用 CRM です。本記事で扱った構成上の独自性(Cloudflare Workers + 単一 Worker、内部 UUID 基準のマルチアカウントモデル、stealth 層、5 分 cron 分割再送)については、興味があれば実装を覗いてみることをおすすめします。コードを公開してくださっている野田氏に改めて感謝を申し上げます。

次回の Claude Skill 図鑑も、Coding カテゴリから別の OSS Skill を取り上げる予定です。第 1 回の ui-ux-pro-max を frontend-design と比較もよければ併せてお読みください。