この記事ではRAGに特化して解説します。RAG全般は RAGとは?仕組み・構築・ベクトルDB選定までの2026年実装マップ をご覧ください。

Graphifyは、コードベース全体——ソースコード・ドキュメント・PDF・画像・動画まで——をAIが問い合わせられるナレッジグラフに変換するOSSだ。AIコーディングツールで /graphify . と打つだけで、フォルダの中身が「ノードとエッジのグラフ」に変わり、AIは生ファイルをgrepする代わりにグラフへクエリを投げられるようになる。2026年4月3日の公開後わずか48時間でバズり、Y Combinator S26 採択という急成長を見せている。2026-08-06時点の実測ではGitHubスターは 103,086 に達した。

この記事のポイント
  • 何ができる:任意のフォルダを /graphify . でグラフ化し、querypathexplain で問い合わせる。コードのAST解析はLLM不使用・APIキー不要で、当サイトの実測でもグラフ構築のトークンコストは 0 input · 0 output だった
  • 何が読み取れる神ノード(最も結線の多い中心概念)コミュニティ(Leiden法で検出した機能の塊)。21ファイルのコーパスで16コミュニティ・神ノード上位10件が自動抽出された
  • 注意点:公式READMEは長らく掲げていた「71.5倍」という見出し数値を取り下げ、LOCOMO/LongMemEval-Sでの他システム比較に差し替えている。削減率はコーパス依存で、当サイト実測は14.7倍だった
【2026-08-06 実測】リポジトリ移管とライセンス変更(旧記事の「MIT」は誤り)
個人アカウントから Graphify-Labs Organization へ移管されている。YC採択後の法人化に沿った動きと読める。実測した現況は次のとおり:
正は github.com/Graphify-Labs/graphify。旧 safishamsi/graphify は301で新パスへ転送されるため既存リンクは切れないが、本記事のリンクは新パスへ更新した
ライセンスは Apache-2.0 に変更済み。リポジトリには LICENSE(Apache-2.0)と LICENSE-MIT が併存するが、NOTICE が「本製品は Apache-2.0 でライセンスされる。再ライセンス前にMITで提供された部分は引き続きその条件でも利用でき、原文を LICENSE-MIT に残す」と明記している。**現在の配布物全体に適用されるのは Apache-2.0**
スター 103,086 / 最終push 2026-08-05。最新リリースは v0.9.34(2026-08-05)で、開発は非常に活発
・本記事が解説する graphify . の基本的な使い方・出力ファイル(graph.html / GRAPH_REPORT.md / graph.json)の構成は現在も変わっていない

まずは、実際に動かしたときの雰囲気を1本の動画で掴んでほしい。Claude Code や Google Antigravity から /graphify を叩き、対話的なグラフが立ち上がるまでの流れが2分ほどで分かる。

Claude Code / Google Antigravity で Graphify を動かすデモ。/graphify 一発でコードベースが対話的グラフになる(出典: Graphify: Instant Knowledge Graph for Claude Code/Antigravity — FuturMinds / YouTube
Graphifyがコードと文書を1枚のグラフに変換し、graph.html・GRAPH_REPORT.md・graph.jsonの3ファイルを出力する全体像。コーパス規模とトークン削減率(52ファイルで71.5倍、4ファイルで5.4倍、6ファイルで1倍)を棒グラフで示した図
Graphifyの全体像。フォルダを渡すと graph.html(対話グラフ)・GRAPH_REPORT.md(要約)・graph.json(永続グラフ)が出力される。棒グラフの削減率は公式リポジトリ worked/ のサンプル実測値(出典: Graphify-Labs/graphify worked/)。※後述のとおり71.5倍はREADMEの見出し指標からは外れ、現在は worked/karpathy-repos/ にのみ残る

Graphifyとは——なぜコードをナレッジグラフにするのか

大規模コードベースをAIに理解させるとき、最大のボトルネックはトークン消費だ。10万行のコードをAIに読ませるには膨大なトークンが必要で、コンテキストウィンドウの制限にもすぐぶつかる。ファイルを1つずつ Read し、grep で探し回るたびに、AIは同じ構造を何度も読み直す。この非効率が、大きなプロジェクトでAIアシスタントの回答が浅くなったり遅くなったりする原因になる。

Graphifyの発想はシンプルだ。「毎回ファイルを読む」のをやめ、いちど作ったグラフに問い合わせる。コードベースを「関数・クラス・概念(ノード)」と「呼び出し・依存・参照(エッジ)」のグラフに変換しておけば、AIは質問に関連する部分グラフだけを参照すればよく、ファイル全体を読む必要がなくなる。

この記事を読む開発者が知りたいのは、突き詰めれば次の3点だろう。①Graphifyは結局何ができるのか、②どんな課題を解決するのか、③既存の何を代替するのか。先に結論を示すと——

①何ができる:任意のフォルダを /graphify . 一発でナレッジグラフ化し、querypathexplain で自然言語問い合わせできる
②何を解決する:大規模コードベースを読むときのトークン枯渇・コンテキスト溢れ・調査の遅さを、グラフへの部分クエリで解消する
③何を代替する:AIに「ファイルを全部読ませて把握させる」運用や、素朴な grep/全文検索ベースの調査を置き換える

ナレッジグラフ化の最大のメリットはトークン効率だ。公式リポジトリの worked/ に置かれた実測サンプルでは、Andrej Karpathy のリポジトリ群+論文5本+画像4枚を合わせた52ファイルの混在コーパスで、生ファイルを読む場合と比べクエリあたり71.5倍のトークン削減を記録している。削減率はコーパスが大きいほど伸びる(後述のとおり、数千行規模の小さなプロジェクトでは削減効果はほぼ出ない)。

【2026-08-06 実測】「71.5倍」は公式の見出し指標ではなくなった
この数値は本記事の初出時、READMEのトップに掲げられていた。だが2026-08-06に確認した時点で、README本文にも BENCHMARKS.md にも「71.5」という文字列は1件も存在しないgrep -c でいずれも0)。現在READMEが掲げるのは、mem0・supermemoryなど競合システムを同一ハーネス・同一モデルで走らせた比較ベンチマークに置き換わっている。
ただし撤回されたわけではない。71.5倍という記述は worked/karpathy-repos/README.md に「この数値を生んだコーパス」として現存する。つまり「特定コーパスでの再現可能な実測値」から「プロジェクトの看板指標」の座を降りた、と読むのが正確だ。単一コーパスの圧縮率より第三者比較可能な精度指標を前面に出す方針転換であり、OSSの誠実さとしてはむしろ good sign と言える。

現在READMEが掲げるベンチマークは次のとおり。判定は独立した第2のジャッジで盲検証されており(一致率90.6%、Cohenのκ=0.81)、BENCHMARKS.md に再現コマンドまで公開されている。

ベンチマーク 指標 graphify 比較対象
LOCOMO (n=300) recall@10 0.497 BM25 0.362 / mem0 0.048
LOCOMO (n=300) QA精度 45.3% supermemory 49.7% / BM25 31.3% / mem0 27.3%
LongMemEval-S (n=50) QA精度 76% dense RAG 76%(同率)/ mem0 70%
LOCOMO ingest コスト 約 $1.40 supermemory $15.67 / mem0 $3.48
グラフ構築 LLMクレジット $0

注意したいのは、これらが会話メモリ(long-term memory)としての評価軸だという点だ。「コードベースの地図」としての価値を直接測ったものではない。コード用途で効くかどうかは、次章で自分のリポジトリを実測して確かめる。

Graphifyの土台は、NetworkXtree-sitter というよく知られたライブラリだ。Neo4jのようなグラフDBサーバは不要で、すべてローカルで完結する。ライセンスは Apache-2.0(旧MITから変更済み。冒頭の box-warning 参照)で、特許条項を含むぶんMITより企業利用の予見性が高い。


フォルダを渡すとグラフになる:解析の仕組み

Graphifyの処理は、大きく2種類の解析に分かれる。コードは決定論的なAST解析でローカル処理し、それ以外の素材(ドキュメント・PDF・画像・動画)だけをAIモデルに送ってセマンティック解析する。この使い分けが「速さ」と「深さ」を両立させている。

入力フォルダ→AST解析(tree-sitter、LLM不要、ローカル)→セマンティック解析(AIが概念と関係を抽出)→グラフとレポート出力という流れと、生ファイルを読む従来方式とグラフに問い合わせる方式の対比図
Graphifyの解析パイプライン。コードはローカルでAST抽出(APIキー不要)、文書・画像・PDFだけをAIモデルに送って概念とその「なぜ」まで抽出する(出典: Graphify-Labs/graphify README を図解)

AST解析(決定論的・LLM不要・ローカル)

tree-sitterで36文法を解析し、シンボル・呼び出しグラフ・import関係・クラス階層を抽出する。ここはLLMを一切使わないため高速かつ決定論的で、APIキーも不要。コードだけのコーパスなら graphify extract は完全にオフラインで走り、1バイトも外に出ない。

AST解析が抽出する情報は次のとおりだ。

・シンボル(関数・クラス・変数)
・呼び出しグラフ(関数A → 関数B)
・import/依存関係
・クラス継承階層
・エクスポート/公開API

対応するのはコードだけではない。SQLスキーマ、Terraform/HCL、Salesforce Apex(.cls.trigger)、さらにパッケージマニフェスト(pyproject.tomlgo.modpom.xml)まで解析でき、「アプリコード+DBスキーマ+インフラ」を1つのグラフに束ねられる。CUDA(.cu.cuh)やMetal(.metal)はC++の文法を流用して扱う。

セマンティック解析(AIが「なぜ」まで抽出)

ドキュメント(Markdown・PDF・reStructuredText・HTML)、画像(スクリーンショット・図・ホワイトボード写真)、動画・音声は、AIモデルに渡してセマンティック解析する。ここで抽出されるのは単なる要約ではなく、概念・関係性・設計意図だ。コード中の # NOTE:# WHY:# HACK: といったコメントやdocstring、ドキュメントに書かれた設計理由も独立したノードとして取り込まれ、それが説明している該当コードにリンクされる。

画像はAIのビジョン機能で処理されるため、アーキテクチャ図やホワイトボードの写真からも概念を抜き出せる。動画・音声はローカルの faster-whisper で文字起こししてからグラフに取り込むので、音声そのものが外に出ることはない。

この「2種類の解析」の分担は、プライバシー面でも効いている。コードはローカル、動画・音声もローカル、外部モデルに送られるのは文書・PDF・画像のセマンティック抽出だけ。データレジデンシー要件が厳しい環境では --backend ollama で完全ローカル運用に切り替えることもできる。


出力される3つのファイルと、神ノード・コミュニティの読み方

/graphify . を実行すると、graphify-out/ ディレクトリに主に3つのファイルが生成される。ここが「何ができるか」を最も体感しやすい部分だ。

graph.html — ブラウザで開ける対話的なグラフ。ノードをクリックし、検索し、コミュニティ(後述)で絞り込める
GRAPH_REPORT.md — グラフの要点をまとめたレポート。神ノード・意外なつながり・おすすめ質問が並ぶ
graph.json永続グラフ。数週間後でもファイルを読み直さずにクエリできる

レポート(GRAPH_REPORT.md)に含まれる情報は、単なる目次ではない。

神ノード(God nodes):最も多くの結びつきを持つ概念。「すべてがここを通る」ハブが分かる
意外なつながり(Surprising connections):別のファイル・モジュールにまたがるリンクを、意外性の高さでランク付け。それぞれに平易な「なぜ」が付く
設計理由(The “why”):コメントやdocstringから抽出した設計意図を、該当コードに紐付けて提示
おすすめ質問:そのグラフだからこそ答えられる4〜5個の質問
信頼度タグ:各関係に EXTRACTEDINFERREDAMBIGUOUS が付き、「見つけた事実」と「推測」が常に区別される

graphify-out/ はgitにコミットする前提で設計されている。1人が /graphify . して結果をコミットすれば、チーム全員がプルした瞬間に同じ「地図」を手にできる。graphify hook install を実行すればpost-commitフックが入り、コミットのたびにグラフが自動再構築される(コード部分はAST解析だけなのでAPIコストはゼロ)。しかも graph.json にはマージドライバが設定され、2人が並行でコミットしてもグラフはユニオンマージされ、コンフリクトマーカーが残らない。

graph.html に描かれるグラフは Leiden法(graspologic)によるコミュニティ検出で色分けされる。関連の強いノードがクラスタとして固まって見えるため、「このプロジェクトはどんな塊でできているか」が一目で掴める。

実測:当サイトのコードベースをグラフ化してみた

抽象論だけでは「何が嬉しいのか」が伝わらないので、実際に走らせた結果を出す。対象は本サイトの記事生成パイプライン(tools/shared/ 配下のPythonコード21ファイル)、graphify は最新の v0.9.34uvx で隔離環境に入れて実行した。

検証環境: macOS 14.5 (Darwin 23.5.0) / graphifyy v0.9.34 / 2026-08-06実施。APIキーは一切設定していない。

# 隔離環境で実行(グローバル環境を汚さない)
uvx --from graphifyy==0.9.34 graphify extract . --no-cluster
# → found 21 code, 0 docs, 0 papers, 0 images
# → wrote graphify-out/graph.json — 369 nodes, 683 edges (no clustering)

uvx --from graphifyy==0.9.34 graphify cluster-only . --no-viz
# → Graph: 369 nodes, 591 edges / Done - 16 communities

APIキーを一切設定せずに完走した。README が「コードは tree-sitter の決定論的AST解析、LLM不使用」と書いているとおりで、生成された GRAPH_REPORT.md のヘッダも Token cost: 0 input · 0 output を記録していた。コードだけのコーパスなら、費用ゼロ・完全ローカルでグラフが手に入るのは実測どおりだ。

肝心の GRAPH_REPORT.md から、神ノード(God Nodes) の上位はこう出た。

順位 ノード 結線数 実体
1 SourceResult 21 トレンド収集結果の共通データクラス
2 GA4Client 19 Google Analytics 4 APIクライアント
3 GSCClient 18 Search Console APIクライアント
4 _guard() 15 取得失敗を検知するガード関数
5 check_all() 15 全ソースの健全性チェック

これは「このコードベースの中心概念は何か」への直接の回答になっている。実際、SourceResult は全トレンドソースが返す共通の器で、ここを変更すると収集系すべてに波及する——新規参画者に最初に説明すべき型がそのまま1位に来た。神ノードは「触ると危ない場所」のランキングでもあるわけだ。

コミュニティ検出は16個の塊を返し、GA4Client GSCClient trend_sources.py fetch.py といったハブごとに機能が分かれていることが可視化された。あわせて Import Cycles: None detected(循環importなし)も報告される。

実測で分かった注意点:LLMなしだとコミュニティに「名前」が付かない
クラスタリング自体(Leiden法)は決定論的なのでAPIキー無しで走るが、実行時に [graphify label] no LLM backend configured; keeping Community N placeholders. という警告が出る。コミュニティの意味的なラベル付けだけはLLMを使うため、キー未設定だと Community 0 のような通し番号のままになり、代表ノード名が便宜的なラベルとして使われる。「塊の境界」は無料で得られるが、「その塊が何なのかの一言説明」は有料、という切り分けだ。

実測:トークン削減率は14.7倍だった

同梱の benchmark サブコマンドで、このグラフの削減率をそのまま測れる。

uvx --from graphifyy==0.9.34 graphify benchmark graphify-out/graph.json

結果は次のとおりだった。

項目 実測値
コーパス 18,450語 → 約24,600トークン(素朴に全文を読む場合)
グラフ 369ノード・591エッジ
1クエリあたり平均 約1,670トークン
削減率 14.7倍

質問ごとの内訳は「main entry point は何か」17.3倍、「data層とAPI層をつなぐのは何か」12.8倍、「中核の抽象は何か」14.7倍。公式の71.5倍には遠く及ばないが、これは当然の結果だ。71.5倍を出したコーパスは52ファイルの混在コーパスで、こちらは21ファイル。前掲のとおり削減率はコーパス規模に強く依存し、README自身も小さなコーパスでは削減率がほぼ1倍になると認めている。自分のリポジトリでの実値は自分で測るしかない——そしてそれが1コマンドでできる点こそ評価すべきだ。


エッジの3種類——情報の出自を正直に記録する

Graphifyの設計で特筆すべきは、すべてのエッジ(関係)に出自ラベルが付与される点だ。これは「AIが自信ありげに嘘をつく」問題への、地味だが効く対策になっている。

EXTRACTED(確実・ソースから直接抽出)、INFERRED(推論・AIが根拠つきで推論した関係)、AMBIGUOUS(要確認・確信度が低い)という3種類のエッジ出自ラベルを信頼度順に並べた図
全エッジに出自ラベルが付く。AIは「見つけた事実」と「推測」を区別して回答できる(出典: Graphify-Labs/graphify README を図解)

各ラベルの意味は次の表のとおりだ。

ラベル 意味 信頼度
EXTRACTED ソースコードから直接抽出(AST解析) 確実
INFERRED AIが根拠つきで推論した関係
AMBIGUOUS AIが推論したが確信度が低い(要レビュー) 要確認

AST解析で得たエッジは EXTRACTED として「確実な事実」に分類される。一方、ドキュメントや画像からAIが読み取った関係は INFERRED、確信度が低いものは AMBIGUOUS になる。この透明性により、AIは「これはコードから確認できる事実」「これは私が文書から推測した関係」を分けてユーザーに回答できる。調査の裏取りをするときも、まず EXTRACTED だけを信じ、AMBIGUOUS は自分の目で確かめる、という使い分けができる。

何を解決するのかという観点で言えば、これはナレッジグラフ全般につきまとう「グラフが本当に正しいのか分からない」という不信感を、ラベルという形で可視化して解消する仕組みだ。


あらゆる素材を1つのグラフに:マルチモーダル対応

Graphifyの「コーディングツール」という枠を超えた強みが、マルチモーダルであることだ。コードだけでなく、設計ドキュメント・論文PDF・アーキテクチャ図の画像・解説動画までを、同じグラフに混ぜられる。

コード(36文法をAST)、SQL/IaC(スキーマ・Terraform)、文書/PDF(Markdown・論文)、画像(図・写真をVision)、動画(文字起こし)という5種類の入力素材を並べたアイコン図
Graphifyが扱う入力素材。アプリコード+DBスキーマ+インフラ、そして文書・画像・動画までを1つのグラフに束ねられる(出典: Graphify-Labs/graphify README を図解)

対応する主な素材と抽出方法は次のとおりだ。

種類 拡張子(一部) 抽出方法
コード .py .ts .js .go .rs .java .c .cpp .rb .cs .kt .scala .php .swift .lua .zig .ex ほか tree-sitter AST(36文法)
DB・IaC .sql .tf .tfvars .hcl / Apex .cls .trigger スキーマ・リソース抽出
ドキュメント .md .mdx .txt .rst .html .yaml AIによる概念・関係抽出
論文 .pdf 引用マイニング+概念抽出
Office .docx .xlsx 拡張機能(graphifyy[office]
画像 .png .jpg .webp .gif AIのビジョン機能(図・写真・多言語)
動画・音声 .mp4 .mov .mp3 .wav / YouTube URL faster-whisperでローカル文字起こし

この「引用マイニング」が効くのは、論文PDFを混ぜたときだ。冒頭のヒーロー図で71.5倍を記録したコーパスも、Karpathyのコード群に論文5本と画像4枚を混ぜたものだった。README曰く、コードとコードのエッジより「コードと論文のエッジ」のほうが意外性スコアが高くランク付けされる。つまり「この実装はどの論文のどのアイデアに対応しているのか」といった、人間なら見落としがちな越境的なつながりを浮かび上がらせられる。

Karpathyが /raw フォルダに論文・ツイート・スクショ・メモをまとめて放り込むワークフローを紹介したことがバズのきっかけだった、という背景も、このマルチモーダル性を踏まえると腑に落ちる。散らかった素材を「1つの問い合わせ可能なグラフ」に束ねる、というのがGraphifyの提供価値なのだ。


インストールと基本コマンド

導入は2ステップで済む。パッケージをインストールし、使っているAIアシスタントにスキルを登録するだけだ。

注意:PyPIのパッケージ名は graphifyy(yが2つ)。他の graphify* パッケージは非公式。ただしCLIコマンドとスキル名は graphify のまま。

# 1. パッケージをインストール(uv tool 推奨。pipx / pip も可)
uv tool install graphifyy

# 2. AIアシスタントにスキルを登録し、任意のフォルダでグラフ化
graphify install
# → AIアシスタントを開いて  /graphify .  と打つだけ

基本の使い方は /graphify に引数を渡すだけだ。ビルドしたあとは自然言語でグラフに問い合わせられる。

/graphify .                        # カレントフォルダをグラフ化
/graphify ./raw --update           # 変更ファイルだけ再抽出してマージ
/graphify . --wiki                 # グラフからMarkdownの内部Wikiを生成

/graphify query "認証はどこでDBにつながっている?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

/graphify add https://arxiv.org/abs/1706.03762   # 論文を取得してグラフに追加
/graphify add <youtube-url>                       # 動画を文字起こしして追加

graphify hook install              # コミット時に自動再構築するgitフック

query / path / explain の3つは graph.json さえあればAIアシスタント抜きでも単体で動く。実際の出力はこうなる(前章と同じ21ファイルのグラフに対して実行)。

$ graphify path "run_pipeline()" "generate_cover_image()"
Shortest path (2 hops):
  run_pipeline() --calls [EXTRACTED]--> generate_image() --calls [EXTRACTED]--> generate_cover_image()

$ graphify explain "GA4Client"
Node: GA4Client
  Source:    shared/google_analytics.py L32
  Community: GA4Client
  Degree:    19
Connections (19):
  --> .get_page_views() [method] [EXTRACTED] shared/google_analytics.py:L61
  --> .get_declining_pages() [method] [EXTRACTED] shared/google_analytics.py:L155

path が返す2ホップの経路には、各辺に [EXTRACTED](ASTから直接抽出=確実)が付く。「この関数から画像生成まで、どう到達するのか」が行番号付きで即座に分かる形だ。

実測で踏んだ罠:query は既定の2,000トークン予算で黙って打ち切られる
日本語で graphify query "GA4のデータはどこで取得している?" を投げたところ、73ノードがヒットしたが出力はこう警告された:
[!] TRUNCATED: showing 63 of 73 nodes (~2000-token budget). The answer may be among the 10 cut nodes
つまり探している答えが切り捨てられた10ノードの側にある可能性がある。ツール側が正直に警告してくれるのは good だが、既定値のまま使うと取りこぼす。--budget 6000 のように予算を上げるか、--context call で辺の種類を絞るのが実用上の作法だ。なお日本語の質問文でも問題なくヒットした(docstringが日本語のコードベースでも機能する)。

対応プラットフォームは Claude Code・Codex・OpenCode・Cursor・Gemini CLI・GitHub Copilot CLI・VS Code Copilot Chat・Aider・Amp・OpenClaw・Factory Droid・Trae・Kiro・Devin CLI・Google Antigravity など20以上。多くは graphify install --platform <名前> で個別に登録できる(CodexだけはPowerShellではなく $graphify を使う、といった細かな差はREADMEに明記されている)。統合はIDEプラグインではなく、AIアシスタントのスキル/フック層で行われるのが特徴だ。


MCPサーバーとPRダッシュボード:グラフを他ツールから叩く

Graphifyは /graphify コマンドで完結させるだけでなく、生成した graph.jsonMCP(Model Context Protocol)サーバーとして公開できる。これにより、対応するAIクライアントから構造化されたグラフアクセスをツールとして呼び出せる。

# graph.json を stdio の MCPサーバーとして起動
python -m graphify.serve graphify-out/graph.json

# チームで1つのURLを共有したいときは HTTP トランスポート
python -m graphify.serve graphify-out/graph.json --transport http --port 8080 --api-key "$SECRET"

MCP経由で提供されるツールは、query_graph(グラフへのクエリ)・get_node(ノード詳細)・get_neighbors(隣接ノード)・shortest_path(最短パス)に加え、PR関連の list_prsget_pr_impacttriage_prs がある。デフォルトの stdio は開発者ごとにローカルで1プロセス起動する形だが、HTTPトランスポートを使えば1つの共有プロセスでチーム全体にグラフを配れる(この場合は --host 0.0.0.0--api-key を必ずセットにする)。

クエリ時のやり取りは、次のシーケンスのように進む。AIは生ファイルを読み込まず、グラフサーバーに問い合わせて関連サブグラフだけを受け取る。これがトークン削減の実体だ。

sequenceDiagram participant U as 開発者 participant AI as AIアシスタント
(Claude Code等) participant G as Graphify
グラフサーバー participant J as graph.json
(永続グラフ) U->>AI: 「認証はどこでDBに
つながっている?」 AI->>G: query_graph(自然言語) G->>J: 関連ノード・エッジを検索 J-->>G: 該当サブグラフ
(出自ラベル付き) G-->>AI: 関連部分だけ返す
(生ファイルは読まない) AI-->>U: 事実(EXTRACTED)と
推測(INFERRED)を分けて回答

さらに実務寄りの機能として、graphify prs というPRダッシュボードがある。

実測メモ:prs--help に出てこない“隠れコマンド”で、gh CLIに依存する
v0.9.34 で graphify --help を実行しても、コマンド一覧に prs は現れない(READMEには記載がある)。存在しないわけではなく、実際に graphify prs を叩くと cli.py の実装に到達し、次のエラーを返す:
Error: gh CLI not found or not authenticated. Run: gh auth login
つまりGitHub CLI(gh)の導入と認証が前提だが、この依存はREADMEのどこにも書かれていない(gh auth / GitHub CLI で検索しても0件)。PRダッシュボードを試して無反応だった場合は、まず gh auth login を疑うとよい。

CIの状態・レビュー状況・ワークツリーの対応関係を一覧でき、graphify prs 42 でPR #42のグラフ影響範囲まで掘り下げられる。graphify prs --conflicts は「同じグラフコミュニティを触っているPR」を検出し、マージ順序のリスクを教えてくれる。ナレッジグラフを単なる検索インデックスではなく、レビュー・マージ判断の土台として使う発想だ。


類似ツールとの比較

Graphifyの立ち位置を、コード理解系の代表的なツールと比べて整理する。

ツール スコープ 索引の作り方 マルチモーダル 設計意図の抽出 サーバ要否
Graphify リポジトリ内+文書+画像+動画 tree-sitter AST(コードはLLM不要・$0) 対応 対応(AI抽出+出自ラベル) 不要(ローカル完結)
GraphRAG(Microsoft) 文書コーパス LLMでエンティティ抽出(構築コストが従量) 文書中心 対応(要約主体) 不要だがLLM必須
ベクトルRAG一般 文書コーパス 埋め込み+ベクトルDB 実装次第 非対応 ベクトルDB必要
Sourcegraph クロスリポジトリのコード検索 独自インデクサ 非対応 非対応 サーバ/SaaS
Neo4j+自前抽出 汎用グラフDB 自作パイプライン 実装次第 実装次第 サーバ必須

GraphRAGとの違いが最も本質的だ。両者とも「グラフを作ってから答える」点は同じだが、索引の作り方が正反対である。MicrosoftのGraphRAGは文書をLLMに読ませてエンティティと関係を抽出するため、コーパスが大きいほど構築コストが積み上がる。対してGraphifyは、コードに関しては tree-sitter のAST解析だけで構造を取るのでLLMを1回も呼ばない——前章の実測どおり Token cost: 0 input · 0 output だ。この差は「グラフの正しさ」にも効く。ASTから取った辺は文法的に確定した事実なので EXTRACTED と言い切れるが、LLMに抽出させた辺は本質的に推論であり、Graphifyもドキュメント由来の辺は INFERRED に落とす。

もう一点、READMEが明言するのは「ベクトルインデックスではない」ことだ。埋め込みもベクトルDBも使わず、実際に辿れるグラフを持つ。類似度検索ではなく経路探索なので、前章の path のように「AからBへどう到達するか」を根拠付きで答えられる。RAGの系譜の中でどこに位置するかは RAGの進化|Naive・Advanced・Graph・Agentic RAGの仕組みと選び方2026 が詳しい。

Sourcegraphは複数リポジトリを横断するコード検索に強く、Graphifyとは補完関係にある(ただしv0.9系では graphify merge-graphs a.json b.json で複数リポジトリのグラフを1つに統合できるようになっており、クロスリポジトリも射程に入りつつある)。汎用のグラフDBであるNeo4jは表現力こそ高いが、サーバの構築と抽出パイプラインの自作が必要になる。文書からWikiを自動生成する方向性の近縁ツールとしては DeepWiki-Openの使い方|GitHubリポジトリからAI Wikiを自動生成するOSS、文書解析側を厚くしたRAGエンジンとしては RAGFlowとは|高精度な文書解析でRAGを組むOSSエンジンの使い方 が比較対象になる。

Graphifyの差別化は、①マルチモーダル(コード+文書+画像+動画)②設計意図まで抽出し出自ラベルで正直さを担保③Neo4jのようなサーバ不要でローカル完結④特定IDEに縛られずAIアシスタント層で20以上のツールに載る、の4点に集約される。「AIに読ませる前提の地図を、手元で低コストに作る」という一点に振り切った設計だ。


どんなコードベースで効果的か——効く場面・効かない場面

「入れれば必ず速くなる」わけではない。トークン削減はコーパス規模にスケールするので、大きくて雑多なプロジェクトほど効く。逆に、コンテキストに丸ごと収まる小さなプロジェクトでは、グラフ化のオーバーヘッドのほうが目立つ。

効果が高いケース

大規模モノレポ:数十万行でコンテキストが足りない場合、グラフからの部分クエリが威力を発揮する
ドキュメントが散在するプロジェクト:Markdown・PDF・設計図をコードと同じグラフに統合し、関連性を可視化
新規参画者のオンボーディング/graphify explain UserService でコンポーネントの役割と依存関係を即座に把握
レガシーコードの理解:ドキュメントがなくてもAST解析で構造を抽出し、AIが設計意図を推論
並行エージェント開発:複数エージェントが同時にコードを書く場面で、--watch によりグラフが波と波の間で自動的に最新化される

効果が限定的なケース

・小規模プロジェクト(数千行以下)——AIが直接ファイルを読む方が効率的(公式のhttpxサンプルは6ファイルで削減率ほぼ1倍)
・頻繁に作り替えるプロトタイプ——グラフ再構築のオーバーヘッドが割に合わない

規模と削減率の関係は、冒頭のヒーロー図の棒グラフがそのまま答えになっている。worked/ サンプルでは52ファイルで71.5倍、4ファイルで5.4倍、6ファイルで約1倍。本記事で実測した21ファイルのコーパスは、ちょうどその中間の14.7倍に着地した。「6ファイルはそもそもコンテキストに収まるので、そこでの価値は圧縮ではなく構造の可視化だ」とREADME自身が正直に書いている点は、このツールの信頼性を測るうえで見逃せない。各 worked/ フォルダには入力ファイルと実際の出力(GRAPH_REPORT.mdgraph.json)が同梱されているので、数字は自分の手で再現・検証できる。


セキュリティと運用上の注意点

導入前に押さえておきたい運用上の注意をまとめる。

graph.jsonにはコード構造情報が含まれる。公開リポジトリにうっかりコミットする場合は中身を確認する
コスト管理:ドキュメント・画像のセマンティック解析にはモデルAPIのコストが発生する(コードのAST解析はローカルで無料)。初回構築が最も重く、増分更新(--update)は低コスト
プライバシー:コードと動画・音声はローカル処理で外に出ない。外部に送られるのは文書・PDF・画像のセマンティック抽出のみ。完全ローカルにしたいなら --backend ollama
クエリログquerypathexplain は既定で ~/.cache/graphify-queries.log にJSON Lines形式で記録される(質問・コーパス・所要時間など。サブグラフ本文は既定で保存しない)。無効化は GRAPHIFY_QUERY_LOG_DISABLE=1
テレメトリなし:使用状況の追跡・分析は行わない

チーム運用では graphify-out/ をコミットする一方、graphify-out/cost.json(ローカルのコスト記録)は .gitignore に加えるのがREADMEの推奨だ。.graphifyignore.gitignore と同じ構文)で対象を絞れるほか、各ディレクトリの .gitignore は自動的に尊重される。

Graphifyは「AIにコードを理解させる」という誰もがぶつかる課題に、ナレッジグラフ+出自ラベル+ローカル完結というシンプルな解を出したツールだ。RAGを自前で組む前に、まず手元のリポジトリで /graphify . を1回叩いてみる価値はある。RAGの全体像から設計したい場合は、あわせて次の記事も参照してほしい。

関連記事: RAGとは?仕組み・構築・ベクトルDB選定までの2026年実装マップ

参照ソース