Graft: オープンソースのコンテキストレイヤーが Claude Code のトークン使用量を 42% 削減し、SWE‑bench の精度を向上させる

TL;DR

Graft は、エージェントがリポジトリを繰り返し grep する代わりにクエリできる、永続的な markdown ベースのコードグラフを構築します。これにより、Claude Code のトークン使用量が 42% 削減され、ツール呼び出しが 46% 削減され、実行速度が 60% 高速化し、SWE‑bench の正解率が 54% から 66% に向上します。


Graft の主張

  • 効率性の向上 – 制御された 162 回の実行ベンチマークにおいて、Graft は、タスクごとにリポジトリを再探索する「コールド」な Claude Code セッションと比較して、トークンを 42%、ツール呼び出しを 46%、レイテンシを 60% 節約しました。
  • 正解率の向上 – 業界標準の SWE‑bench Verified スイート(50 件の実在する GitHub issue)において、Graft はベースラインの 27 件に対し 33 件を解決し、12 ポイント向上しました。
  • コスト削減 – 同じベンチマークでは、実行時間(wall‑clock time)が 32% 減少し、金銭的コストが 19% 削減されることが示されています。
  • 言語サポート – TypeScript/JavaScript, Python, Go, Java の高精度なパース。20 以上の追加言語に対するより広範な tree‑sitter サポート。Rust, C/C++ などに対するオプションの LSP ベースのエッジ。
  • ゼロ・ランタイム・オーバーヘッド – 構造的なグラフ構築 (graft build) は API キーなしでローカルで実行されます。オプションの LLM 要約(--deep)のみがプロバイダーに接続します。

Graft の仕組み

2 パスによるグラフ構築

  1. ファイル要約 – 各ソースファイルは、短い英語の記述を生成するために LLM に一度渡されます(オプション)。
  2. ノード集約 – 要約は、型付き wikilinks ([[node]]) を持つ、厳選された markdown ノード(サブシステム、主要なファイル、概念)にグループ化されます。

生成される graft/ ディレクトリは、コードと並行して存在するプレーンファイルのキャッシュであり、Git にコミット可能です。

ノードの内容

Part Description
Summary LLM によって生成され、キャッシュされる、コードの目的に関する 1 文の英語の解説。
Crux コアロジックを実装する最小限のソースコード行。そのままの状態で保存されます。
Sources ノードを支えるファイルパスとコンテンツハッシュ。正確な鮮度チェック(stale‑check)を可能にします。
Links [[wikilinks]] として表現される、型付きのリレーションシップ (depends_on, part_of, uses, etc.)。
Notes 再生成を回避するためにユーザーが作成した自由記述テキスト。

漸進的なリフレッシュ

  • グラフの再構築はコンテンツハッシュによってキャッシュされます。変更されたファイルのみが LLM 呼び出しをトリガーします。
  • 軽量な $0 構造リフレッシュは、すべての graft ask/grep/callers コマンドの前に実行され、ネットワーク接続なしでグラフが未コミットの編集を反映するようにします。

コーディング・エージェントとの統合

  • graft init は、サポートされているエージェント(Claude Code, Cursor, Gemini, Codex, Copilot, etc.)を検出し、必要な指示書またはスキルファイルを書き出します。Claude Code は、ライブ・ステータス行、自動同期フック、およびセッションごとに一致するノードのインポートを行います。
  • MCP server – 6 つのツール・エンドポイント (graft_find_code, graft_file_api, graft_trace_calls, graft_find_all, graft_repo_map, graft_check_freshness) を登録します。エージェントはこれらを直接呼び出すことができます。
  • No daemon – グラフは通常のファイルとして存在します。ユーザーがオプションの MCP server を使用する場合を除き、バックグラウンド・サービスは必要ありません。

ベンチマーク

制御された 162 回のスイープ

Metric Cold Claude Code Claude Code + Graft
Cost savings ($) 0.0429 0.0292 (+32%)
Token savings 8,070 4,650 (+42%)
Tool‑call savings 4.2 2.3 (+46%)
Latency (s) 39.8 15.8 (+60%)
Correctness ----------------- 93%

「pull」バリアント(オンデマンドで graft ツールを使用する方式)は、最も高い正解率(98%)を達成しましたが、速度のメリットを大部分的に失いました。

SWE‑bench Verified (50 件の実在する issue)

Metric Cold Claude Code Claude Code + Graft
Correctness 27/50 (54%) 33/50 (66%)
Token savings 142 M 109.4 M (+23%)
Tool‑call savings 1,370 1,031 (+25%)
Wall‑clock time 13,094 s 8,922 s (+32%)
Correctness ----------------- 93%

正解率の向上は、ファイル間の推論をより良く行えるようになったことに起因します。ベースラインは、単一のファイルのみをパッチッチングし、依存関係のあるファイルを修正し損ねることがよくありました。


Hacker News でのコミュニティ・フィードバック

@seizethecheese – “The benchmark section reads like it was written by Claude/Codex; the 50‑task SWE‑bench sample is small and the p‑value (0.22) is weak. It’s easy to cherry‑pick tasks.”
ベンチマーク・セクションは Claude/Codex が書いたように読めます。50 タスクの SWE‑bench サンプルは小さく、p 値 (0.22) は弱いです。タスクをチェリー・ピックすることは容易です。

@icodestuff – “I worry about stale graphs over long sessions. Incremental refreshes may drift silently, graph/ directory in graft/ could be painful. Merge conflicts in graft/ could be painful.”
長期セッションにおいて、グラフが古くなることを懸念しています。漸進的なリフレッシュは静かに素質を漂わせる可能性があります。マージ・コンフリクトが graft/ 内で発生する場合、それは苦痛であることが可能です。

@xhrpost – “Does Claude’s LSP integration already reduce grep usage? Is Graft solving a duplicate problem?”
Claude の LSP 統合がすでに grep 活用を減らしているのではないか、という疑問です。Graft は、使い捨ての LSP ベースのシンボル・ルックアップではなく、永続的な、人間が読める知識グラフとして提供される点に価値があります。 \

Sources

関連

  • Dispatch
  • プロジェクト
  • Dispatch
  • プロジェクト