https://knightli.com/ja/tags/understand-anything/ Recent content in Understand-Anything on KnightLiブログ Hugo -- gohugo.io ja Sat, 06 Jun 2026 22:26:00 +0800 https://knightli.com/ja/2026/06/06/understand-anything-code-knowledge-graph/ Sat, 06 Jun 2026 22:26:00 +0800 https://knightli.com/ja/2026/06/06/understand-anything-code-knowledge-graph/ <p><code>Lum1104/Understand-Anything</code> は、コードリポジトリをインタラクティブなナレッジグラフに変換するツールです。README のスローガンは明快です。Graphs that teach &gt; graphs that impress。つまり、グラフは見た目を派手にするためではなく、コード理解を助けるためにあります。</p> <p>Claude Code、Codex、Cursor、Copilot、Gemini CLI などに対応し、開発者と AI Agent の両方がリポジトリをより早く理解できるようにすることを目指しています。</p> <h2 id="なぜコードナレッジグラフが必要なのか">なぜコードナレッジグラフが必要なのか </h2><p>AI コーディングツールは強力になりましたが、大規模リポジトリの理解は今でも詰まりやすいです。</p> <ul> <li>ファイルが多く、入口がわかりにくい；</li> <li>関数、クラス、モジュールの関係が複雑；</li> <li>新しい参加者がどこから読み始めればよいかわからない；</li> <li>Agent が断片を見つけても、全体アーキテクチャ内の位置を理解できない；</li> <li>ドキュメントは古くなり、コードこそが真実になる；</li> <li>複数言語、複数ディレクトリのプロジェクトは全体像を作りにくい。</li> </ul> <p>コードナレッジグラフの価値はここにあります。「ファイルとシンボルの一覧」を「探索できる関係ネットワーク」に変えます。単に関数名を検索するだけでなく、それが何につながり、誰から呼ばれ、どのモジュールに属し、業務フローのどこにあるのかを見られます。</p> <h2 id="何ができるのか">何ができるのか </h2><p>プロジェクト紹介を見ると、Understand-Anything は主に次の点を重視しています。</p> <ul> <li>任意のコードをインタラクティブなナレッジグラフに変換する；</li> <li>探索、検索、質問に対応する；</li> <li>グラフを見た目ではなく理解のために使う；</li> <li>Claude Code、Codex、Cursor、Copilot、Gemini CLI などと連携できる；</li> <li>リポジトリ onboarding、コードレビュー、リファクタ前の整理、Agent のコンテキスト強化に使える。</li> </ul> <p>この種のツールは、特に未知のリポジトリで役立ちます。初めてプロジェクトを引き継ぐとき、Agent にいきなり <code>rg</code> させるより、先に構造グラフを作り、重要ノードを中心に質問するほうがよい場面があります。</p> <h2 id="向いている利用シーン">向いている利用シーン </h2><p>まず使いたいのは次のような場面です。</p> <ul> <li>新しいメンバーが古いプロジェクトを引き継ぐ；</li> <li>オープンソースリポジトリを読む；</li> <li>リファクタ前にモジュール依存を整理する；</li> <li>主要な入口と重要な呼び出しチェーンを探す；</li> <li>AI Agent にリポジトリ構造のコンテキストを渡す；</li> <li>コードレビュー前に変更影響範囲を把握する；</li> <li>技術文書やアーキテクチャ説明を作る。</li> </ul> <p>小さなプロジェクトには少し重いかもしれません。数十ファイル程度なら直接コードを読めば十分です。リポジトリが数百、数千ファイル規模になると、グラフの価値が見えやすくなります。</p> <h2 id="rag-との違い">RAG との違い </h2><p>RAG は「関連する断片の検索」が得意です。ナレッジグラフは「関係の理解」が得意です。</p> <p>たとえば、次のような質問です。</p> <ul> <li>「決済フローはどこにある？」</li> <li>「この関数は誰から呼ばれている？」</li> <li>「このモジュールを変えるとどこに影響する？」</li> <li>「なぜ似たサービスが 2 つある？」</li> </ul> <p>通常の RAG はいくつかのコード片を返せますが、グラフは経路、依存関係、近接ノードを見るのに役立ちます。最適なのは二者択一ではなく、RAG でテキスト証拠を探し、グラフで構造をナビゲートすることです。</p> <h2 id="注意点">注意点 </h2><p>コードグラフは万能ではありません。</p> <ul> <li>言語解析の品質がグラフ品質に影響する；</li> <li>動的呼び出し、リフレクション、設定駆動ロジックは完全には捕捉しにくい；</li> <li>グラフが大きすぎると情報ノイズになる；</li> <li>生成結果は実際のコードと照合する必要がある；</li> <li>Agent はグラフだけを見て直接コード変更すべきではない。</li> </ul> <p>本番プロジェクトで使うなら、権威あるアーキテクチャ文書ではなく、読解補助として扱うのがよいです。最終的な根拠は、コード、テスト、実行時の挙動です。</p> <h2 id="まとめ">まとめ </h2><p>Understand-Anything の位置づけは明確です。コードリポジトリを探索、検索、質問できるナレッジグラフに変え、人間と Agent がより早く全体像を作れるようにします。</p> <p>未知のリポジトリを読むことが多い人、大規模プロジェクトを保守する人、リファクタを行う人、または Codex / Claude Code に変更前にシステム構造を理解させたい人には、試す価値があります。コードを代わりに読んでくれるわけではありませんが、どこから読むべきかを見つけやすくしてくれます。</p> <h2 id="参考ソース">参考ソース </h2><ul> <li><a class="link" href="https://github.com/Lum1104/Understand-Anything" target="_blank" rel="noopener" >Lum1104/Understand-Anything - GitHub</a></li> </ul>