Claude Codeの「毎回ゼロから調べ直す」を止める「Graft」SWE-benchで33/50 vs 27/50まで踏み込んだ数字

3行まとめ

1. Graftは、コードベースの構造を「ノード＝システムや概念、リンク＝関係」というMarkdownのグラフとして書き出し、Claude Codeなどのフックに乗せてエージェントの再探索コストを減らすOSSツール。
2. 独自の162実行ベンチマークでは、トークン消費42%減・ツール呼び出し46%減・レイテンシ60%減、正答率は93%で変わらずとGitHub READMEに記載。
3. 業界標準のSWE-bench Verified（50件・公式グレーダー）では、正解数がCold Claude Codeの27/50からgraft併用で33/50まで伸びたと公開されている。

【更新 2026年9月25日】 初出時点の実測と比べると、GitHubスター数は5.1k→9,154、フォーク数は458→832に伸びていた（GitHub・2026年9月25日確認）。npmパッケージ@nanonets/graftも28→31バージョン、最新は0.15.0→0.19.0（2026-09-22公開）に進んでいる。「Zenn・Qiitaでの言及はゼロ」と書いた点も変わり、Windowsでの導入トラブルの対処記事がQiitaに1本公開されていた（9月16日）。一方、本記事の核である162実行ベンチマークとSWE-bench Verifiedの数値、「Up to 4× cheaper and 3× faster」の記載、NanoNets/Graft→trailhq/Graftの301リダイレクトは、READMEとリポジトリを再取得して変更がないことを確認した。詳細な差分は本文中に反映している。

「毎回ゼロから調べ直す」という無駄

READMEが指摘する問題は単純だ。コーディングエージェントはタスクごとに丸腰でリポジトリに入る。何かを変える前に、grepして、ファイルを開いて、importを辿って、行き詰まって、また探す——1時間前に自分がマッピングしたはずのコードベース像を、セッションが終わるたびに捨てて作り直している。この再探索が、1回の実行のツール呼び出し・トークン・レイテンシの大半を食い、しかも純粋なオーバーヘッドだとREADMEは書く。人間は一度オンボーディングすれば済むが、エージェントは毎回オンボーディングし直している、という表現だ。

やっていること──埋め込みでもインデックスでもなくMarkdownのグラフ

Graftはこの理解を一度だけ構築し、リポジトリ内にリンクされたMarkdownファイル群として書き出す。1つのシステム・API・概念につき1ノード、という単位だ。README上の特徴を要約すると次の通り。

• 本物の説明文であって、関数名の羅列ではない。シニアエンジニアが説明するような自然文で「何をしていて、他とどうつながっているか」を書く
• 埋め込みも類似検索もない、ただのリンクされたファイル群。エージェントは他の通常ファイルと同じようにopenしgrepしてたどるだけ
• graft/はローカルキャッシュであり.gitignoreに入る（node_modulesと同じ扱い）。コミットされるのはgraft initが生成する小さな配線（.claude/、AGENTS.md、MCP設定）だけで、チームメイトは各自graft buildで自分のグラフを生成する
• 常に最新：ask/grep/callers/skeleton/mapのどのクエリも、実行前に作業ツリーに対してグラフを再構築する（何も動いていなければ約3ms）。コミットされていない編集も反映される
• プロバイダは自由：要約生成にはOpenAI・Anthropic・OpenRouter・Fireworks・Groq・LiteLLMプロキシ・ローカルモデルのいずれも使える。構造グラフの構築自体（graft build/graft check）はtree-sitterによる決定論的処理で、モデル呼び出しは発生しない

導入はgraft initが対話的に「どのコーディングエージェントを配線するか」を聞き、コードからgraft/を構築、.claude/にステータスラインとフックを配置する、という流れになっている。

GitHubリポジトリはNanoNets/Graftからtrailhq/Graftへ移管されていた

github.com/NanoNets/Graftに直接アクセスすると、現在は301リダイレクトでgithub.com/trailhq/Graftに転送される（本記事執筆時点で確認。2026年9月25日にも再確認し、リダイレクトは変わっていない）。リポジトリのAboutには「Turbocharge Claude Code, Cursor, Codex, Gemini & every coding agent」とあり、Claude Code専用ではなくCursor・Codex・Geminiなど複数のコーディングエージェントに対応する、と明記されている。スター数は初出時点の実測で5.1k・フォーク数458・ウォッチャー23だったが、2026年9月25日にGitHubで確認するとスター数9,154・フォーク数832・ウォッチャー36まで伸びていた。同日のリポジトリページの表示では、オープン中のissueが95件、プルリクエストが110件あった。

Graftの配布元をたどると、graft.nanonets.aiというホームページURLもtrailhq.com/graftにリダイレクトされる。Trail社の公式サイトは自社を「Your Company Brain for AI Agents」と位置づける企業向けプロダクト（Context Graph、Natural Language Rule Engine、Agent Builderなど）を展開しており、Graftはその中の「オープンソース版のコードベース向けコンテキストレイヤー」という位置づけで製品ラインに含まれている。npmパッケージ名は@nanonets/graftのまま変わっておらず、npm registryの実測では2026-07-15に初回公開、2026-08-27時点で28バージョンがリリースされている（最新は0.15.0）。約6週間で28回のバージョン更新という頻度は、活発に開発が続いているツールであることを示している。2026年9月25日に同じregistryを再確認すると、**31バージョン・最新は0.19.0（2026-09-22公開）**まで進んでおり、公開後も更新が止まっていない。

独自ベンチマーク：162実行

READMEに掲載されている最初のベンチマークは、Claude Sonnet 5を使った3パターン（cold＝ゼロから探索／graft＝グラフを事前に一括投入／pull＝必要な時だけ取りに行く）の比較だ。Opus 4.8を判定役にして必須キーワードの充足を採点し、キャッシュを考慮したコストモデル（読み取り約0.1倍、書き込み1.25倍）で計測している。2つのリポジトリ（Graft自身と実際のNode/Express認証サービス）に対し、単一ファイル・複数ファイルの質問を織り交ぜて162回実行した結果が次の表だ。

pull方式（必要な時だけ取得するツールのみ渡す）はスピードでは劣るが正答率が98%まで上がり、「速さが要る時はpush、正しさが要る時はpull」という使い分けが提案されている。「コーディングエージェントがなぜ高くつくのか」を可視化する方向では、手元のセッションログを読み取るFrugal Tokensという、GitHubで公開されている別のツールもある。Graftが再探索そのものを減らすのに対し、Frugal Tokensは既に発生したトークン消費・キャッシュミスを事後に見える化する立場で、狙いが異なる。

SWE-bench Verifiedでの実測

自社ベンチだけでなく、業界標準のSWE-bench Verified（実際のGitHub issueを使い、公式swebenchハーネスで採点）でも検証したとREADMEは書く。50件のインスタンス、両アームともClaude Sonnet 5・同じDockerイメージ・同じターン数上限で、違いはgraftを配線したかどうかだけ、という条件だ。

README曰く、正解が増えた事例の多くは「ベースラインは1ファイルだけ直して兄弟ファイルを見落とす」という同じパターンだったという。django-11532ではCold版が5ファイル中1ファイルしか直さず、既存の通過済みテストを18件（2回分）壊した。django-16263では4ファイル中1ファイルしか直せずスコアは102/103止まりだったのに対し、graft併用版は残りを見つけ、しかもトークン・時間とも半分で到達したとされている。

なお、SWE-bench Verifiedという物差し自体にも限界が指摘されている。論文「SWE-Bench ProMax」は先行監査の結果として、SWE-bench Verifiedの未解決インスタンスの約60%に欠陥のあるテスト（正しい解答を弾く狭すぎるテスト、明記されていない要件まで検査する広すぎるテスト）が含まれると引用している（紹介記事）。つまり「解けなかった」という判定が、そのままエージェントの実力不足を意味するとは限らない。本記事が扱うのはあくまでGraft開発元が同じ条件・同じハーネスで両アームを比較した相対差であり、ベンチマーク自体の妥当性を検証するものではない。

「4倍安く3倍速い」は、掲げている場所ではなく数字の読み替えの問題

「Up to 4× cheaper and 3× faster（最大4倍安く、3倍速い）」は、trailhq.com/graft のトップページだけでなく、README自身の見出し（23行目）と本文にも同じ文言で掲げられている（2026年9月4日にrawで取得して確認した時点では本文524行目。2026年9月25日に再取得した版（全603行）でも、同じ文言が見出しの23行目と、人気OSSリポジトリで検証した節「Tested on your popular repos」の本文536行目にある）。つまりWebサイト固有のマーケティング表現ではない。

問題はどこに書いてあるかではなく、この「4倍・3倍」と、同じREADMEが示す実測値が別の数字だということだ。162実行ベンチマークではコスト32%減（約1.47倍）、レイテンシ60%減（約2.5倍）、SWE-bench Verifiedではコスト19%減・実行時間32%減。「最大（Up to）」の語が付いている以上、条件が揃った場合の上限値であって、表に出ている平均値を4倍・3倍と読み替えることはできない。

確認できたこと・確認できていないこと

本記事はGitHubリポジトリのREADME・Trail公式サイト・npm registryを2026年8月27日〜30日にcurlで取得し、掲載されている表・数値をそのまま書き起こしている。ベンチマークの実行環境・タスクセットの詳細（具体的なタスク一覧、評価プロンプトの全文）まではREADMEの範囲を超えるため確認できていない。また、これらの数字はGraft開発元（Trail）自身が計測・公開したものであり、第三者による独立した再現結果は今回の調査では見つかっていない。実際に手元のリポジトリにgraft initを通して動作を検証したわけでもない。2026年9月25日にはGitHub README・リポジトリページ・npm registryを再取得し、2つのベンチマークの数値がこの時点でも変わっていないことを確かめた。実行環境・タスクセットの詳細は今回も確認できておらず、手元での動作検証もしていない。第三者による再現結果も、今回は改めて探していない。

Zenn・Qiitaの日本語記事は、Windowsでの導入トラブル対処の1本

本記事の初出時点（2026年8月27日〜30日確認）では、Zenn・Qiitaともに固有名詞としてのGraftへの言及はゼロだった。2026年9月25日に再確認したところ、状況が変わっていた。QiitaのAPIで検索すると、「WindowsのClaude Codeでgraft MCPサーバーが即切断される（CONNECTION_CLOSED）問題の対処法」（2026年9月16日公開）が1本見つかる。同記事によると、npx -y @nanonets/graft@latestで起動するとWindowsではパッケージ展開時にファイルロックに引っかかってEBUSYエラーが起き、親プロセスごと落ちていたという。回避策としてグローバルインストールした実行ファイルを直接呼ぶ設定を紹介しており、本記事が扱う@nanonets/graftと同一パッケージだ。Zennは「graft」「graft claude」で検索結果0件、「nanonets」では記事2件がヒットしたが、どちらもNanonetsのOCRモデルを扱った記事でGraftとは別物だった。「Claude Codeのトークン消費を減らす」というテーマ自体は日本語圏でも語られるが、Zenn・Qiitaを検索した範囲では、コードグラフをMarkdownファイル群として持つというアプローチそのものを解説する日本語記事は、この時点でもまだ見当たらない。

関連記事

• Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
• Claude Code 使い方・料金・できること【2026年最新ガイド】
• トークンとは何か──LLMの料金とコンテキストを決める最小単位
• AIコーディングに専門知識は要るのか──Anthropicが40万セッションを分析した研究を公開