Understand-Anything を Claude Code から呼ぶ — RAG 運用者から見た 6 つの観察

結論 — Claude Code に「コードベースの地図」を /plugin で渡せる時代になった

Lum1104/Understand-Anything は、任意のコードベースを interactive knowledge graph（ノードと辺で可視化された知識グラフ）に変換し、Claude Code / Codex / Cursor / GitHub Copilot / Gemini CLI などの coding agent から問い合わせ可能にする OSS です。GitHub Trending Daily の 1 位に 2026 年 5 月 28 日朝の時点で 39.7k stars を集めていました。Claude Code への導入は /plugin marketplace add Lum1104/Understand-Anything の 1 行で済み、以降は同セッション内で /understand 系の 8 コマンドが生えます。

私は RAG（Retrieval-Augmented Generation、検索拡張生成）を「読み物として設計する」立場でこの 1 年運用してきました。本稿はリポジトリの README とコマンド構成を読んで気付いた 6 点を整理した、auto-publish に取り込む前の設計レビューです。手元で /understand を当てるのは来週の予定で、本稿はその前段の観察にあたります。

tree-sitter + LLM の分業が、RAG で詰まる境界をきれいに引いている

設計の中核は分業です。tree-sitter（C 言語ベースの incremental parser、構文木を高速に作るライブラリ）が「構造の真実」を担い、LLM が「意味の翻訳」を担います。tree-sitter は import / export / 関数定義 / call site を deterministic（決定的、入力が同じなら出力も同じ）に抽出し、同じ構造を入力にした LLM が plain-English の要約・タグ・アーキ層分類を返します。「決定的に取れるものは決定的に、解釈が要るものだけ LLM に」と一直線です。

私が RAG を構築するとき、いつも詰まる境界がここでした。コードを chunk して embed するアプローチだと、関数の親子関係や circular dependency（循環依存）が意味の階層で潰れます。tree-sitter を構造の正としておけば、LLM に渡すコンテキストには「この関数は SomeService.call から呼ばれている」という事実を毎回事実として渡せます。私は同じ問題を昨年 12 月の連休で 3 日溶かしていたので、OSS 側が先に解いていたのを README で見たときは少し悔しかった、というのが正直な感想です。

/plugin install で入る、という体験設計が効いている

Claude Code の plugin marketplace に native 対応している点が、体験面で一番効いています。/plugin marketplace add Lum1104/Understand-Anything を実行すると、以降は同セッション内で /understand / /understand-dashboard / /understand-chat / /understand-diff / /understand-explain / /understand-onboard / /understand-domain / /understand-knowledge の 8 コマンドが使えます。Cursor と VS Code + Copilot は auto-discovery、Codex / OpenCode / Gemini CLI / Vibe CLI などは 1 行 install で乗せられる、という横展開の薄さです。

私の auto-publish は Claude Code を Worker として使う設計（pick → write → verify → video の 4 段）なので、各段の Claude セッション冒頭で /understand を 1 回叩いて context を温める統合余地があります。冷静に考えると、毎セッションの outline 段で「リポの構造を Claude に説明する」処理にトークンを使っていたので、graph を事前ビルドしておけば 1 回あたり数千トークンの context が減るはずです。週 7 本回す前提だと、月で数万トークン分の節約になります。

6 + 1 agent の中身を読む — graph-reviewer が面白い

multi-agent pipeline は 6 agent + 1 で構成されています。project-scanner がファイル探索と言語検出、file-analyzer が関数とクラスを抽出してノードと辺を作り、architecture-analyzer がアーキ層を識別、tour-builder が学習ツアーを生成、graph-reviewer が graph の完全性と参照整合性を検証、domain-analyzer が業務ドメインとフローを抽出します。これに加えて wiki 系を扱う article-analyzer が /understand-knowledge 用に控えています。

私が一番面白いと感じたのは graph-reviewer の存在です。graph の完全性と参照整合性を検証する、という役割が agent として独立しているのは、「LLM が作った中間成果物を、別の LLM agent でレビューする」というパターンの素直な実装例です。auto-publish も pick → write → verify の 3 段に分けていますが、verify は curl と jq による機械チェックで、LLM agent には任せていません。verify を LLM agent に格上げすると指摘の柔らかさは増しますが、コストと暴走リスクも上がります。実は 2 月に試したことがあり、verify 担当の Claude が「修正案」を勝手に書き始めて 2 時間掛けて記事を別物にされたので、今は機械チェックに戻して落ち着いています。

graph は .understand-anything/knowledge-graph.json に commit-safe で書かれる

graph の出力先は .understand-anything/knowledge-graph.json で、team で commit-safe に共有できる JSON 形式です。intermediate/ と diff-overlay.json だけは .gitignore 推奨と README が明示しています。設計として「team で graph を共有資産として持つ」前提が綺麗に置かれているのが分かります。

私の auto-publish は単独運用なので team 共有の旨味は薄いのですが、CI に /understand --auto-update を仕込むと commit ごとに graph が増分更新される構造は使えそうです。auto-publish の run.sh が走った直後に graph を更新する hook を足せば、次回の write 段で「先週 publish した記事の slug 一覧」「カテゴリ別の最近のトピック」などを graph 経由で context に渡せます。pick 段の重複検出ロジック（Jaccard score の計算）を graph 側に寄せる選択肢も出てきます。

「graphs that teach > graphs that impress」を運用に翻訳すると

リポの philosophy セクションに「コードベースの複雑さに圧倒される graph ではなく、ピース同士のつながりを静かに教えてくれる graph」という一文があります。装飾の派手さではなく、次にコードを触る人や agent が前提を組み立てやすいことを優先する宣言です。

私は同じ思想を RAG の retrieval 設計で持っていて、「検索ヒット数を 100 件出すよりも、5 件で文脈が閉じる方を優先する」という基準で chunk と embedding を組んできました。コードを LLM に渡す graph も、節点を増やすことより節点の意味を狭く正確に保つことが効きます。tree-sitter の deterministic な層が下支えにあるからこそ、上位の LLM 層は意味の精度に集中できる、というのも筋が通っています。

まとめ — 走らせる前にメモしておきたい運用観点

設計だけで読んでも、本 OSS は coding agent と RAG 運用の交差点を実用的に解いている、と判断できました。tree-sitter で構造を固め、LLM 6 agent で意味を翻訳し、Claude Code には /plugin で渡す、という 3 層構成が一直線です。私が来週試す予定の auto-publish への組み込みでは、pick stage の prompt から手で書き写していたディレクトリ説明が graph から自動取得できる状態を目指します。期待値が外れたら別記事で書きます。

39.7k stars は 2026-05-28 朝の数字で、Trending Daily 1 位を維持しています。半年後にどれくらい残るかは未知ですが、Claude Code marketplace に乗っている時点で「coding agent インフラ側の OSS」として育つ確率は低くないはずです。