ナレッジグラフを活用してClaude Codeのトークンを10分の1にする

---

はじめに

Claude Codeの請求額や、レート制限（一定時間に使える量の上限）の通知を見て、想定より消費が多いと感じたことはないでしょうか。タスクの区切りで /clear を打ち、CLAUDE.md も整理したのに、大きなプロジェクトに入ったとたんトークン（AIが文章を処理する単位。料金と利用上限の基準）の消費が増える。そんな覚えはないでしょうか。

原因の多くは、会話の蓄積ではなく探索にあります。AIコーディングエージェントは、コードを調べるときにファイルを開いて読み、grep（ファイルの中身をキーワードで検索するコマンド）で探し、また別のファイルを開くという動きを繰り返します。2026年の研究では、この探索が1回の問い合わせで数千トークンを消費し、しかもコードの構造を理解しないまま進むことが指摘されています（Codebase-Memory、2026）。会話をいくら整理しても、探索そのものの仕組みが変わらない限り、この消費は残り続けます。

本記事では、この問題を構造から解決する方法として、リポジトリのナレッジグラフ化を解説します。コードに含まれる関数やクラスをノード（点）、呼び出しや包含の関係をエッジ（線）として整理しておき、エージェントには全文を読ませる代わりに、必要な部分だけを問い合わせさせるやり方です。研究では、探索型と比べてトークン使用量が10分の1になったという報告（Codebase-Memory、2026）と、コーディング課題の解決率が平均で相対32.8%向上したという報告（RepoGraph、ICLR 2025）があります。10分の1という数字には回答品質との引き換え条件もあるため、その点も隠さず扱います。

読み終えると、次の3つが分かる状態になります。

• トークン消費の原因が探索の構造にあること、そしてナレッジグラフ化がなぜ効くのか
• コードをグラフにする設計と構築の手順（研究3本の設計をもとにした最小の作り方）
• MCPサーバーとしてClaude Codeへつなぐ構成と、自社で導入すべきかの判断基準

動作の説明はすべて実機検証に根拠を置いています。検証環境は記事末尾に記載します。研究の報告値と、こちらで測った値は、本文中でも区別して書きます。

1. 基礎知識：トークン消費の原因とコードのナレッジグラフ化

1-1. 運用術だけではトークンが減らない理由

Claude Codeのトークン削減策として広く知られているのは、タスクごとに /clear で会話を切る、/compact で履歴を圧縮する、CLAUDE.md を小さく保つ、といった運用の工夫です。これらはどれも有効ですが、対象は会話の蓄積です。セッションに積み上がった履歴や常駐する設定ファイルを軽くする対策であり、エージェントがコードを調べる行為そのものは対象にしていません。

エージェントの探索は、新しくプロジェクトに入った人の動きとよく似ています。新しく入った人は、まずフォルダ構成を眺め、それらしいファイルを開いて読み、分からない語で全文検索し、出てきた別のファイルをまた開きます。エージェントの探索もこれと同じ順です。この1往復ごとにファイル本文がコンテキスト（AIが一度に読み込める情報の枠）へ入るため、調査1回で数千トークンを消費し、しかも読んだ内容の大半は最終的な回答に使われません（Codebase-Memory、2026）。リポジトリが大きいほど候補が増え、探索の回数も読む量も伸びます。会話の整理でどれだけ節約しても、この部分は減らないわけです。

つまりトークン対策には2つの層があります。会話の蓄積を減らす層（運用術）と、探索の構造を変える層です。本記事が扱うのは後者です。

コンテキストエンジニアリングの実践についてはこちらもご参考ください。

Claude Codeの挙動を制御するCLAUDE.mdの書き方についてはこちらもご参考ください。

1-2. コードのナレッジグラフ化とは

ナレッジグラフは、対象の世界に何が存在し、それらがどう関係しているかを、ノードとエッジの網目で表したデータ構造です。業務データの分野では、顧客や注文をノードに、発注や納品といった関係をエッジにして、検索や推論の土台に使われてきました。

この考え方はコードにもそのまま適用できます。ノードになるのはモジュール・クラス・関数・変数といったコードの構成要素で、エッジになるのは含む・呼び出す・継承するといった構成要素どうしの関係です。こうして作ったグラフを、研究分野ではコードグラフと呼びます。以後、本記事でもコードグラフと呼びます。

コードグラフがあると、エージェントの調べ方が変わります。たとえば、ある関数がどこから呼ばれているかを知りたいとします。探索型では、ファイルを順に開いて呼び出し箇所を探すしかありません。グラフ型なら、その関数のノードに入ってくる呼び出しエッジを1回の照会で取り出せます。読む対象がファイル本文からグラフへの問い合わせ結果に変わるため、コンテキストに入る量が大きく減ります。両者の違いを表で整理します。

観点	探索型（ファイル読みと grep）	グラフ型（コードグラフへの照会）
読む対象	ファイル本文をそのまま読む	必要なノードとエッジだけを受け取る
トークン消費	調査1回で数千トークン	探索型の10分の1という報告（Codebase-Memory、2026）
構造の理解	持たない（毎回読み直す）	呼び出し・継承・包含を関係として保持する
得意な質問	場所が分かっている狭い範囲の確認	影響範囲・依存関係・プロジェクト横断の質問
弱点	大規模になるほど消費が増える	構築の手間と、コード変更後の鮮度管理が要る

1-3. 効果はどれくらいか：研究3本の数値

効果は、精度とコストの2つの面で報告されています。いずれも2024年から2026年にかけての査読付き会議論文とプレプリントです。

精度の面を示したのが、リポジトリをコードグラフにする手法を提案した論文 RepoGraph（ICLR 2025）です。既存のコード修正AIに、コードグラフを検索する操作を1つ追加するだけの手法です（仕組みは2-3で説明します）。効果の測定には SWE-bench Lite というベンチマークが使われました。GitHubに実際に報告された不具合を、AIがどれだけ自力で修正できたかを測るものです。

このベンチマークで、AIにコードを修正させる代表的なオープンソース4つすべてで成績が上がり、平均すると相対32.8%の改善が報告されました。内訳は次のとおりです。

修正を担うオープンソース	追加前	追加後
Agentless	27.33%	29.67%（発表時点のオープンソース最高値）
AutoCodeRover	19.00%	21.33%
SWE-agent	18.33%	20.33%
検索拡張型	2.67%	5.33%

最後の検索拡張型は、関連しそうなコードを検索で集めてAIに渡す、最も単純な方式です。

別のベンチマーク CrossCodeEval でも、書きかけのコードの続きをどれだけ正確に補完できたかの一致率が、GPT-4oで10.5%から28.7%へ上がりました（改訂版 v2 の Table 5。初版 v1 では10.8%から28.5%と報告されており、改訂で数値が更新されています）。特定の課題形式に限らない効果が示されています。

コストの面を示したのが、論文 Codebase-Memory（2026）です。実リポジトリ31件で探索型エージェントと比較し、トークン使用量を10分の1、ツール呼び出し回数を2.1分の1に減らしたと報告しています。ただし回答品質は83%で、探索型の92%をわずかに下回りました。これは、コードベースへの質問に対する回答が正しく十分だったかを採点した割合です。速く安くなる代わりに、答えの質が1割弱下がる引き換えになっていることは知っておく必要があります。なお、呼び出し元の一覧や、ハブ（多くの呼び出しが集まる中心の関数）の特定のような、グラフの形がそのまま答えになる質問に限れば、リポジトリの件数とは別に、対象言語31のうち19言語で探索型と同等以上でした。

一方で、グラフ化すれば必ず安くなるわけではないことも研究は示しています。コードグラフをグラフデータベースに入れて照会する手法を提案した論文 CodexGraph（NAACL 2025）では、検索拡張型を上回る精度が出た一方、トークン消費は増えました。論文の計測では、検索ベースの手法と比べて約7倍から15倍、エージェント型の手法と比べて約1.1倍から2.1倍です。照会を繰り返して精度を取りにいく設計だと、コストは増える方向に働きます。精度を取るか、コストを取るかは、グラフの使い方の設計で決まります。この設計の違いは2章と3章で具体的に見ていきます。

2. 実装のステップ：大規模コードベースをコードグラフにする

1章では、トークン消費の原因が探索の構造にあることと、コードグラフに置き換えると何が変わるかを見ました。この章では、そのコードグラフを作って照会するまでを、設計、構築、照会の3段階で説明します。

2-1. 設計：ノードとエッジを決める

最初に決めるのは、何をノードとし、何をエッジとするかです。CodexGraph（NAACL 2025）はこの設計を最も具体的に公開しており、ノード6種類とエッジ5種類で構成しています。

区分	種類	意味
ノード	MODULE	モジュール（ファイルに対応する単位）
ノード	CLASS	クラス（定義の全文と署名を保持）
ノード	FUNCTION	関数
ノード	METHOD	メソッド（クラスに属する関数）
ノード	FIELD	クラスの変数
ノード	GLOBAL_VARIABLE	グローバル変数
エッジ	CONTAINS	モジュールがクラスや関数を含む
エッジ	HAS_METHOD	クラスがメソッドを持つ
エッジ	HAS_FIELD	クラスが変数を持つ
エッジ	INHERITS	クラスが別のクラスを継承する
エッジ	USES	関数やメソッドが変数を使う

粒度には選択肢があります。CodexGraph がクラスや関数といったシンボル単位でノードを作るのに対し、RepoGraph（ICLR 2025）はコードの行を単位にします。関数やクラスが定義された行を定義ノード、それが使われる行を参照ノードとし、エッジは呼び出しと包含の2種類だけです。シンボル単位は問い合わせの表現力が高く、行単位は構築が単純で細かい位置の特定に向きます。まずは小さく始めるなら、エッジを呼び出しと包含の2種類に絞る設計で足ります。関係の種類は後から増やせます。

2-2. 構築：静的解析でグラフを作る

グラフの構築は、コードを実行せずに構造を調べる静的解析で行います。CodexGraph は2段階に分けています。第1段階でファイルごとにシンボル（クラス・関数など）と内部の関係を抜き出し、第2段階でインポートを解決して、ファイルをまたぐ関係（継承やモジュール間の包含）を補完します。多言語対応が必要な場合は、66言語を扱える構文解析ライブラリ Tree-sitter を使う方法が実証されています（Codebase-Memory、2026）。

もう1つ重要なのがノイズの除去です。RepoGraph は、標準ライブラリの関数やサードパーティ製ライブラリの呼び出しをグラフから除外し、プロジェクト固有の関係だけを残しています。len() のような関数の呼び出しまでエッジにすると、グラフが大きくなるだけで答えの役に立たないためです。

これがどれだけ効くかは、実際に作ってみるとすぐ分かります。ノイズ除去をしない版を、HTTPライブラリ requests のソース（src配下、19ファイル）に対して動かしたところ、関数ノード268件・呼び出しエッジ510件が取れました。ところが、呼ばれた回数が多い関数を並べると次のようになります。

順位	関数名	回数	正体
1	isinstance	75	Pythonの組み込み関数
2	urlparse	20	標準ライブラリ
3	getattr	19	Pythonの組み込み関数
4	cast	18	標準ライブラリ
5	hasattr	16	Pythonの組み込み関数

上位5件すべてが、requests とは無関係の汎用関数で埋まりました。このグラフに「このライブラリの中心的な関数はどれか」と尋ねても、返ってくるのは isinstance です。エッジの数は多いのに、答えの役には立ちません。

そこでノイズ除去を入れます。やり方は、プロジェクト内で定義された関数の一覧を先に作っておき、呼び出しの相手がその一覧に無ければ捨てる、というものです。組み込み関数も同じく捨てます。ここで処理を2周に分ける必要が出てきます。1周目で定義を集めきってからでないと、2周目の呼び出しが自分のプロジェクトのものか判定できないためです。

仕組みを掴むために、Pythonの標準ライブラリだけで書いた最小の例を示します。実運用ではインポートの解決やクラスの扱いが必要になるため、これは構造を理解するための骨子と考えてください。次の4点は割り切っています。

• 関数名を直接呼ぶ形だけを拾います。メソッド呼び出し（obj.method() の形）は対象外です
• 呼び出し先を関数名の一致で結ぶため、同じ名前の関数は1つにまとまります。requests でも同名の関数が33件あり、たとえば request は api.py と sessions.py の2か所に定義されています
• クラス内のメソッドも関数として数えます。ノード268件のうち177件はクラス直下のメソッドです。2-1でMETHODを別ノードとして扱ったのと粒度が違う点に注意してください
• async def で定義された関数は拾いません（requests には無いため今回の件数には影響していません）

import ast                                       # Python標準の構文解析モジュール
import builtins                                  # 組み込み関数の一覧を得るために使う
from pathlib import Path                         # ファイル走査に使う

nodes = []                                       # ノードの一覧（関数の定義）
edges = []                                       # エッジの一覧（呼び出し関係）

# 1周目: 定義を集める（プロジェクト固有の関数を確定させる）
for path in Path('src').rglob('*.py'):           # 対象リポジトリのPythonファイルを順に走査する
    tree = ast.parse(path.read_text(encoding='utf-8'))   # コードを抽象構文木（AST）に変換する

    for item in ast.walk(tree):                  # 構文木の要素を1つずつ調べる
        if isinstance(item, ast.FunctionDef):    # 関数定義が見つかったらノードとして記録する
            nodes.append({
                'type': 'FUNCTION',              # ノードの種類
                'name': item.name,               # 関数名
                'file': str(path),               # 定義されているファイル
                'line': item.lineno,             # 定義されている行番号
            })

defined = {n['name'] for n in nodes}             # このプロジェクトで定義された関数名の集合
builtin_names = set(dir(builtins))               # isinstance や getattr などの組み込み関数

# 2周目: 呼び出しを集める（プロジェクト外の名前は捨てる）
for path in Path('src').rglob('*.py'):           # 1周目と同じくファイルを順に走査する
    tree = ast.parse(path.read_text(encoding='utf-8'))   # 同じく構文木に変換する

    for item in ast.walk(tree):                  # 構文木の要素を1つずつ調べる
        if isinstance(item, ast.FunctionDef):    # 今度は関数の中身を見るために使う
            for child in ast.walk(item):         # その関数の中身を調べる
                if isinstance(child, ast.Call) and isinstance(child.func, ast.Name):
                    callee = child.func.id       # 呼び出される側の名前
                    if callee in builtin_names:  # 組み込み関数は関係として意味がないので捨てる
                        continue
                    if callee not in defined:    # プロジェクト内に定義が無い名前も捨てる
                        continue                 # （標準ライブラリやサードパーティの呼び出し）
                    edges.append({
                        'from': item.name,       # 呼び出す側の関数
                        'to': callee,            # 呼び出される側の関数
                        'type': 'CALLS',         # エッジの種類（呼び出し）
                    })

print(len(nodes), len(edges))                    # 抽出できたノードとエッジの数を確認する

このコードを先ほどと同じ requests のソースに対して実行すると、ノード268件はそのままに、エッジは510件から118件へ減りました（0.06秒。検証環境は記事末尾）。除去した392件が、答えの役に立たない汎用関数への呼び出しだったことになります。なお、除去前の510件は、2周目にある2つの continue の行を外すと再現できます。

そのうえで、もう一度ハブになっている関数を並べると結果が変わります。

順位	関数名	回数	役割	定義位置
1	to_native_string	8	文字コードをそろえる	src/requests/_internal_utils.py:26
2	merge_setting	8	設定を統合する	src/requests/sessions.py:76
3	request	7	リクエストの入口	src/requests/api.py:24 と sessions.py:557 の合算
4	cookiejar_from_dict	6	Cookieを変換する	src/requests/cookies.py:579（型定義用の同名定義2件との合算）
5	extract_cookies_to_jar	6	応答からCookieを取り出す	src/requests/cookies.py:135

設定のマージ、Cookieの取り回し、リクエストの入口といった、requests の中核を担う関数が並びました。エッジを減らしたことで、かえって答えの質が上がっています。グラフは大きく作るものではなく、答えに効く関係だけを残すものだという点が、この前後比較にそのまま表れています。

構築で忘れやすいのが鮮度の管理です。コードは毎日変わるため、グラフを作って終わりにすると、すぐに実体とずれます。コミットや定期実行のタイミングで再構築するか、変更のあったファイルだけ差分更新するか、更新の方針を最初に決めておくことが運用の前提になります。

2-3. 照会：エージェントがグラフを使う流れ

グラフができたら、エージェントからの使い方は大きく2通りあります。

1つ目は、グラフデータベースに問い合わせ言語で照会する方式です。CodexGraph は、主担当のエージェントが知りたいことを自然言語で書き、翻訳担当のエージェントがそれをグラフ問い合わせ言語 Cypher に変換して実行する、2段構えの設計を取っています（論文では Write Then Translate と呼ばれています）。1回で足りなければ、結果を見て問いを重ね、必要な情報がそろってから回答に進みます。表現力が高い一方、照会が増えるほどトークンも増えるため、1-3で見たコスト増（検索ベースの手法と比べて約7倍から15倍）はこの設計から生じるものです。

2つ目は、既存エージェントに検索アクションを1つ追加する方式です。RepoGraph は search_repograph というアクションを足すだけで、既存のフレームワークに組み込めるプラグイン形式を取ります。検索語を中心に、そこからエッジを数本分たどった範囲のノードだけを取り出し（論文では ego-graph と呼ばれる部分グラフ）、文字列にしてエージェントへ渡します。実装の変更が小さく、1-3の精度向上の数値はすべてこの方式で得られたものです。

どちらの方式も共通しているのは、ファイル全文を読む行為を、構造への照会に置き換えている点です。次章では、これをClaude Codeという実際の製品につなぐ構成を見ます。

3. 応用・発展：MCPサーバーとしてClaude Codeにつなぐ

3-1. 接続の構成：グラフをMCPサーバーとして公開する

Claude Codeに外部の仕組みをつなぐ共通規格が MCP（Model Context Protocol）です。コードグラフをMCPサーバーとして立てておくと、Claude Code からはツールの1つとして見え、必要なときだけグラフへ照会が飛びます。Codebase-Memory（2026）はまさにこの構成で実装されており、1-3で見たトークン10分の1という数値は、MCP経由でエージェントにつないだ状態での測定です。全体の構成は次のようになります。

ここからは、実際に動かせる形で手順を示します。使うのは Graphify（コードやドキュメントをナレッジグラフにするオープンソース。PyPIでの配布名は graphifyy）で、MCPサーバーの機能を持っています。

まず導入とグラフの構築です。MCPサーバーとして使う場合は、追加の依存を含む形で入れる必要があります。ここでは2-2と同じ requests を対象にし、テストを含めないよう src 配下だけを渡しました。

python3 -m venv venv                            # 専用の仮想環境を作る
./venv/bin/pip install "graphifyy[mcp]"         # MCPサーバー機能まで含めて導入する
./venv/bin/graphify extract ./requests/src --code-only --out .   # グラフを作る（APIキー不要）

3行目の --out . は、グラフの出力先を今いるディレクトリに指定するものです。これを付けないと解析対象と同じ場所（この例なら requests/src の下）に作られ、次に書く設定ファイルからの相対パスがずれます。実行すると graphify-out/graph.json ができます。requests の src 配下では601ノード・1,514エッジになりました。次に、Claude Code側の設定です。プロジェクト直下の .mcp.json に、このグラフを読むサーバーを登録します。書式を確認するために、コメント付きの解説用と、そのまま使える貼り付け用を分けて示します。

解説用（コメント付き。JSONはコメントを許さないため、このままでは動きません）。

{
  "mcpServers": {                              // 接続するMCPサーバーの一覧
    "graphify": {                              // サーバー名（任意の識別子）
      "command": "./venv/bin/graphify-mcp",    // 導入時に一緒に入るMCPサーバー用のコマンド
      "args": [
        "graphify-out/graph.json"              // 読み込ませるグラフのファイル
      ]
    }
  }
}

貼り付け用（command のパスだけ自分の環境に合わせて書き換えてください）。

{
  "mcpServers": {
    "graphify": {
      "command": "./venv/bin/graphify-mcp",
      "args": [
        "graphify-out/graph.json"
      ]
    }
  }
}

この構成で、Claude Code から実際にグラフのツールが使えるところまで確認しました（検証環境は記事末尾）。サーバーを承認すると /mcp の一覧に graphify が表示され、接続状態になります。実際に「最も接続数の多いノードを3つ挙げて」と尋ねると、mcp__graphify__god_nodes というツールが呼ばれ、Response（106エッジ）、PreparedRequest（98エッジ）、RequestsCookieJar（52エッジ）が返りました。ファイルを1つも開かずに、ライブラリの中心にあるクラスが分かります。

2-2の結果と見比べると、同じ requests の src 配下を対象にしているのに、ノード268件に対してここでは601件と2倍以上の差があります。数えている対象が違うためです。2-2の骨子は関数だけを268件数えたのに対し、graphify はモジュールやクラス、メソッドも数えるので601件になります。

ハブに挙がるものも変わります。2-2では to_native_string や merge_setting といった関数でしたが、ここではクラスが並びました。2-2は関数どうしの呼び出しだけを見ているのに対し、graphify は継承や包含も関係として数えるためです。どちらか一方が正しいのではなく、何を数えたかによって中心は変わります。

対象の選び方でも結果は変わります。試しにテストを含めた状態で同じ質問をすると、上位は TestRequests（209エッジ）と httpbin（140エッジ）になりました。どちらもテスト側の要素です。テストコードは相互参照が多いため、含めるとテスト側が上位を占めます。ライブラリ本体の構造を知りたいときは、いま示した手順のようにテストを外して測ってください。

MCPの設定方法そのものは、Claude Code の公式ドキュメント（Connect Claude Code to tools via MCP）に最新の仕様がまとまっています。サーバーを外せば元の探索型に戻るため、切り戻しが容易なのもこの構成の利点です。

業務で使えるClaude向けMCPサーバーの選び方についてはこちらもご参考ください。

3-2. ツールの動向と、数値の読み方

3-1で使った Graphify は、コードだけでなくドキュメントや論文、画像もまとめてナレッジグラフにできます。提供元は、生ファイルを読む場合と比べて1問い合わせあたりのトークンが71.5分の1になったというベンチマーク結果を公開しています（Graphify公式リポジトリ）。

ここで気を付けたいのが数値の性質です。同じトークン削減でも、論文の10分の1は実リポジトリ31件でエージェントの探索と比べた値であり、Graphifyの71.5分の1はコードと論文と画像を混ぜた52ファイルのコーパスで生ファイルの読み込みと比べた値で、測定条件がまったく別物です。どちらが正しいという話ではなく、種類の違う数値を並べて比べないことが大切です。導入判断の根拠には条件が明記された数値を使い、ツールの公称値は自社環境で再現できるかを試してから信用する、という順番をおすすめします。

3-3. 使いどころの見極め：効く場面と効かない場面

コードグラフは万能ではありません。1-3で見たとおり、回答品質が1割弱下がる引き換えがあり、構築と鮮度管理の手間もかかります。研究の数値から、効く場面と効きにくい場面を整理します。

判断軸	効く場面	効きにくい場面
リポジトリ規模	大規模（探索の往復が多くなるほど削減幅が大きい）	小規模（素の探索で品質92%側を取るほうが得）
照会の頻度	同じリポジトリへ繰り返し問い合わせる	単発の小さな修正で終わる
質問の種類	影響範囲・呼び出し元・依存関係のような構造の質問	1ファイル内の閉じた確認
コードの変化	更新の自動化とセットで運用できる	大改造が続きグラフがすぐ古くなる

とくに相性が良いのは、この関数を変えるとどこに波及するかという影響分析の質問です。グラフの形がそのまま答えになるため、Codebase-Memory の評価でも探索型と同等以上の成績を残した種類の質問でした。逆に、場所が分かっている1か所の修正であれば、グラフに照会するまでもなくファイルを読むほうが速くて正確です。

なお、ナレッジグラフを検索の土台に使う考え方は、コードに限らず文書検索（RAG）でも精度向上の実績があります。高精度なRAGをDifyで構築する手法についてはこちらもご参考ください。

4. まとめと結論

本記事の要点をまとめます。

• トークン消費には2つの層があります。 会話の蓄積は /clear や CLAUDE.md の整理で減らせますが、探索の構造は運用術では変わりません。大規模プロジェクトで消費が増える主因は後者で、ファイル読みと grep の繰り返しが調査1回で数千トークンを使います
• 解決策はリポジトリのナレッジグラフ化です。 関数やクラスをノード、呼び出しや包含をエッジとして持たせ、エージェントにはファイル全文ではなくグラフへ照会させます。実装は設計、構築、照会の3段階で、Claude Codeへは MCPサーバーとして .mcp.json に数行書けばつながります
• 効果は出ていますが、引き換えもあります。 精度は平均相対32.8%向上（RepoGraph、ICLR 2025）、コストはトークン10分の1（Codebase-Memory、2026）。ただし後者は回答品質83%対92%の低下を伴い、照会を重ねる設計ではむしろ増えた報告（検索ベースの手法と比べて約7倍から15倍。CodexGraph、NAACL 2025）もあります
• 効くかどうかは、規模と質問の種類で決まります。 大規模なリポジトリに繰り返し問い合わせる使い方、とくに影響範囲や依存関係を聞く質問で効きます。小さなリポジトリの1か所の修正なら、素の探索のほうが速くて正確です

コードをグラフとして持つ考え方は、AIエージェントに大きなコードベースを任せるうえでの土台になります。まずは検証用のリポジトリ1つで、導入前後のトークンと回答品質を測るところから始めてください。

導入を検討する際は、次のチェックリストを判断材料にしてください。

• [ ] 対象リポジトリは、探索の往復が問題になる規模か（小規模なら素の探索で足りる）
• [ ] 同じリポジトリへ繰り返し問い合わせる使い方か（単発なら効果が薄い）
• [ ] 主要言語が検討中のツールの対応言語に含まれるか
• [ ] グラフの更新方針（再構築の頻度、差分更新の自動化）を決められるか
• [ ] 効果測定の方法（導入前後のトークン使用量と回答品質の比較手順）を用意したか
• [ ] 品質が下がった場合の切り戻し手順（MCPサーバーの取り外し）を確認したか

参照情報の時点: 本記事の数値と仕様は、2026年8月3日時点で参照した論文および公式ドキュメントに基づきます。Claude CodeとMCP周りの仕様は更新が続いているため、導入時は記事末尾の参考文献から最新の公式情報を確認してください。

検証環境: Claude Code 2.1.206 / Python 3.13.5 / graphifyy 0.9.30 / macOS 26.5.2（検証日: 2026年7月30日から8月3日）。2-2の対象は psf/requests 2.34.2 の src 配下（19ファイル）です。

実機で確認したのは次の4点です。(1) 2-2の骨子コードをそのまま実行し、ノード268件、ノイズ除去前のエッジ510件・除去後118件を抽出したこと（ハブ関数の順位も掲載のとおり）。(2) 3-1の手順で graphifyy を導入し、requests の src 配下から601ノード・1,514エッジのグラフを構築したこと。(3) 同じ手順でテストを含めた場合に、上位が TestRequests と httpbin になること。(4) 3-1の設定でClaude Codeからグラフのツール（god_nodes）が呼び出せること。論文の数値（10分の1・相対32.8%など）は各論文の報告値であり、本記事での再測定は行っていません。

最後に

私たちは、単にシステムを組むだけの開発会社ではありません。低コストで高品質なAIツールの構築から、ROI（投資対効果）を最大化する導入ロードマップの策定、社内スタッフが自らAIを運用・改善できる体制の構築まで、AI導入の成功に必要なすべてを最初から最後まで丸ごと支援いたします。

実は、ご相談いただく方のほとんどが「何が分からないかも分からない」という状態からのスタートです。構想段階でも、ただのアイデアベースでも構いません。
まずは、あなたのお困りごとをそのまま聞かせていただけませんか？貴社のビジネスを加速させるパートナーとして伴走いたします。

参考文献

1. Siru Ouyang ほか「RepoGraph: Enhancing AI Software Engineering with Repository-level Code Graph」ICLR 2025（本文の数値は改訂版 v2 に基づく。2026年8月3日参照）
2. Xiangyan Liu ほか「CodexGraph: Bridging Large Language Models and Code Repositories via Code Graph Databases」NAACL 2025（2026年8月3日参照）
3. Martin Vogel ほか「Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP」arXiv プレプリント、2026年（2026年8月3日参照）
4. Anthropic「Connect Claude Code to tools via MCP」Claude Code Docs（2026年8月3日参照）
5. safishamsi「graphify」GitHub（2026年8月3日参照）