Understand Anythingでコードベースを知識グラフに変える

グラフの目的は複雑さの展示ではない

Understand Anythingは、コードベースやknowledge baseを対話的なknowledge graphへ変換するClaude Code Pluginです。READMEの例は20万行の新しいコードベースで、どこから読み始めるか分からない状況です。解析対象はファイル、関数、クラス、依存関係で、各ノードを選ぶと要約、関係、案内を見られる構成です。

中心にある判断は、巨大な図を眺めることではありません。READMEは、グラフが複雑さで驚かせるのではなく、各部分のつながりを静かに教えることを目標にしています。したがって価値はノード数ではなく、担当者が目的の領域へ到達し、コードを読む順番を作れるかにあります。

構造、業務、知識ベースの三つの見方

構造グラフではfile、function、classをクリック、検索し、平易な要約や関係を確認します。domain viewへ切り替えると、コードを業務上のdomain、flow、stepとして横方向に並べます。API、Service、Data、UI、Utilityというarchitectural layerの自動グループ化もREADMEに記載されています。

`/understand-knowledge` はKarpathy-patternのLLM wikiを入力にできます。決定的なparserが `index.md` のwikilinkとcategoryを抜き出し、LLM agentsが暗黙の関係、entity、claimを探します。コード解析とwiki解析は同じ「グラフ」でも入力の前提が違うので、生成結果を混ぜて解釈しないことが必要です。

Guided Toursと検索の使い分け

Guided Toursは依存関係の順にwalkthroughを自動生成し、architectureを読む順序を提案します。Fuzzy searchとsemantic searchは名前だけでなく意味から対象を探し、READMEの例では「authを扱う部分はどこか」という質問を挙げています。Diff Impact Analysisではcommit前に変更の影響範囲を調べます。

persona-adaptive UIはjunior developer、PM、power userに合わせて詳細度を調整すると説明されています。Language Conceptsはgenerics、closures、decoratorsなど12のパターンを登場箇所の文脈で説明します。これらはREADMEの機能説明であり、対象言語や実装ごとの精度を保証する評価結果ではありません。

インストールから解析までの実際の入口

READMEはClaude Codeのmarketplaceから次の二段階で導入する流れを示しています。`/plugin marketplace add Egonex-AI/Understand-Anything` の後に `/plugin install understand-anything` を実行し、プロジェクト内で `/understand` を呼びます。解析結果は通常 `.ua/knowledge-graph.json` に保存されます。既に `.understand-anything/` があるプロジェクトでは、そのディレクトリをデータ領域として使い続けると説明されています。

解析後は `/understand-dashboard` でinteractive web dashboardを開きます。pan、zoom、search、clickでグラフを見られ、layerごとの色分けやnodeのコードと関係を確認できます。初回は全体を走査するため大きなtoken planやsubscriptionを推奨し、後続実行は変更ファイルだけを再解析するincremental動作です。

言語設定とモデルの境界

生成物の言語は `--language` で指定でき、READMEの例は `/understand --language zh` です。対応言語はen、zh、zh-TW、ja、ko、ruで、node summary、dashboard UI、guided tour explanationに影響します。初回に指定しない場合、英語以外の会話では確認を求め、選択は `.ua/config.json` に保存して次回へ引き継ぎます。

プライバシーやenterprise環境ではOllamaなどlocal model providerを使う道が示されています。ただし、必要なメモリ、モデル名、解析時間、外部送信の範囲はREADMEだけでは確定できません。実行前に対象ソースと生成ログの保存場所を確認し、機密コードを含むリポジトリでは自社のモデル利用規則と照合します。

最初に見るべき生成物

最初の検証では小さなfixture repositoryを用意し、`/understand` の完了後に `.ua/knowledge-graph.json` を開きます。既知の関数から期待するdependency edgeが出るか、`/understand-dashboard` のsemantic searchが同じ領域を返すかを確認します。業務フローを使うならdomain viewの順番が実装の呼び出し関係と矛盾しないかを見ます。

次に一つのファイルだけ変更して再度 `/understand` を実行し、incremental解析が変更箇所とその影響を更新するかを比較します。knowledge baseを使う場合は `index.md` のwikilinkとcategoryを数件固定し、parser由来の関係とagentが発見した暗黙の関係を区別します。READMEに書かれていない精度を数値で推測しません。

MITライセンスと運用判断

素材のメタデータはUnderstand AnythingをMITとして示しています。再配布や改変では著作権表示とライセンス通知を維持する条件を確認し、依存するClaude Code、Ollama、各モデルの条件を本体のMITと混同しません。READMEにはEgonexの公開プロジェクトであり、もともとはLum1104が作成したと記載されています。

向いているのは、コードの全体像を検索と可視化で掴みたいチームです。単純なgrepだけで足りる小規模作業、解析データを保存できない機密環境、初回token消費を許容できない環境では慎重な判断が必要です。結論は `.ua/config.json` と `.ua/knowledge-graph.json` の内容、dashboardの再現性、モデル送信方針を確認してから決めます。

Understand Anythingを試すときは、取り込む資料を短いMarkdown、PDF、コードファイルに分け、各資料が検索結果と回答へどう反映されたかを記録します。EgonexのREADMEにあるセットアップ手順、環境変数、対応モデルを固定し、同じ質問を資料ありと資料なしで実行します。回答に引用やファイル名が出る場合も、元の該当箇所へ戻って一致を確認します。大きなリポジトリではインデックス作成時間、除外されたファイル、更新後の再インデックスを別に測ります。READMEに記載のない精度や機密情報の扱いを補って断定せず、ローカル資料を使う範囲と外部サービスへ送る範囲を設定で分けます。

編集部の結論

Understand Anythingは、新しいチームや大規模なコードベースでファイル、関数、クラス、依存関係の位置関係を先に把握したい開発者向けです。採用前に実際のリポジトリで `/understand` を実行し、`.ua/knowledge-graph.json` に期待するノードと関係が生成されるか、続けて `/understand-dashboard` で検索とguided tourが使えるかを確認してください。初回解析のトークン消費はREADME自身が大きいプロジェクトで増えると説明しているため、ローカルモデルを含めて費用とデータの扱いを先に決めます。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes