DiffContext

AIコーディングアシスタントに、その変更にとって本当に関係のあるコードだけを表示する。

DiffContextは、LLMコーディングエージェントのためのコンテキストコンパイラです。Pythonリポジトリと変更内容（git diff、ブランチ、または単一の関数名）を与えると、その変更を安全に行うためにモデルが実際に必要とする少数の関数群を返します。つまり、壊れる呼び出し元、オーバーライドするサブクラス、カバーするテストコードです。これらを任意のトークン予算に収め、また省略せざるを得なかったものについてもモデルに正しく伝えます。

LLMを実際のコードベースに組み込もうとしている人のために作られています。エージェントループ、PRレビューボット、CI検査など、プロンプトに何を入れるかを判断しなければならず、リポジトリ全体を送るには大きすぎるような場面のためのツールです。

しかも自己評価もします。リポジトリを指定すると、git履歴から実在の同時変更ペアを掘り出し、それに対して検索の評価を行い、適していない場合にはNULL RESULTを表示します。見合わないことが分かることがそれ自体が機能なのです。

問題

アシスタントに5万行プロジェクトの1つの関数変更を依頼すると、どれを取っても最悪の選択肢です。リポジトリ全体をすべて貼り付ける（収まらないうえ、巨大なコンテキストではモデル性能が悪化します）、その関数だけを貼り付ける（しかない場合の3つの呼び出し先を壊します）、またはgrepで名前を探す、という方法です。grepは、それをオーバーライドするサブクラスやfunctools.partial経由で受け取るハンドラを見つけることはできません。いくら予算を与えてもgrepの検索率が頭打ちになることを測定しています。

DiffContextは4つ目の選択肢です。リポジトリを一度、本物の依存関係グラフにパースしてしまえば、あとは変更対象ごとに実際に関係する少数の関数を選び出し、最小の役に立つプロンプトへ詰め込むだけです。

git change ──► changed functions ──► hybrid retrieval ──► token budget ──► LLM-ready context
                                      graph ∪ BM25 ∪ file      top-k + tokens

Related MCP server: Serena

インストール

pip install diffcontext

ランタイム依存ゼロ、Python 3.9+。

MCP連携（Claude Code / Cursor / Windsurf)する場合：

pip install "diffcontext[mcp]"

ラエククラウドのサーバー設定はdocs/MCP.mdを参照してください。

開発用のソースからのインストール：

git clone https://github.com/trakshan-mishra/Diffcontext.git
cd Diffcontext && pip install -e .

クイックスタート

diffcontext index /path/to/project              # cold: seconds; warm: ~0.02s
diffcontext compile --ref HEAD~1 --max-tokens 8000
diffcontext verify --from-history 20 --calibrate

詳しいコマンドはUSAGE.mdへ。本番運用のレシピはdocs/USE_CASES.mdにあります。

本サイトのベンチマークを信じるマアに、自分で試す（2分）

diffcontext verify --from-history 20 --calibrate は、あなたのリポジトリのgit履歴からテストケースを採掘し、それに基づいて検索性能を評定します。そしてツールがあなたのリポジトリに合わない場合、飾りだけの数値の代わりにNULL RESULTを出力します。合わないと発見することがそれ自体機能です。

モデルは本当に良くなるのか

なります。代理指標ではなく、エンドツーエンドで測定しています。ContextBenchの128 Pythonタスクを、各リポジトリのテストスイートで判定した結果（LLMによる審判ではありません）、コンテキストを与えることにpass@1は約4倍になります：5.5% → 25.8%、正確なMcNemar検定でp < 0.0001でした。

ただし条件が2つ、両方ともbenchmarks/contextbench/RESULTS.mdの§6にあります。(a) 全条件にわたして与えたシード関数はオラク（gold patchから取得した正解）です。つまり「正しく判断するローカライズが与えられた場合、コンテキストの質は影響するか」であって、エンドースの課題解決は計っていません（ローカライズは全アームで無条件に与えられています）。(b) 実効的128タスク中121はdjangoのため、本質は“django用の成果”だと言える。また率直に言うと、この3つのコンテキスト変種（default / gap / depboost）は統計的に区別できません（p = 0.36–0.81）。効果は「コンテキストの有無」によるもので、このセレクタの違いではありません。完全な結果はbenchmarks/contextbench/RESULTS.mdに。

このツールはそういうものではありません

• **コード生成器ではありません。**コンテストを選んでパックするだけであり、コードを書くのはモデルです。

• **精度優先ではありません。**網を広くかけます。デフォルトのtop-kでは平均適合率は0.1未満です。トークン課金で使うなら--cutoff gapを指定しましょう。

• **まだ、ではありません。**Pythonは完全対応です。TypeScript / JS (ESM)は動くプロトタイプですが、CommonJSは実測済みの失敗パターンです。

• **コードを読む代替ではありません。**静的解析には盲スペックがします。以下とdocs/BENCHMARKS.mdに列挙しました。

検索の質（主張ではない、測定値）

正解データはgit履歴から得ています。開発者によって1コミットで同時変更された関数の組 — 一方を提示すると、もう一方を見つけられるか？ でですね。Pythonリポジトリ9次、701検の実コミットで測定。 さらにプッシュのたびにCIゲートとして再実行され、精度が静かに後退するのを防いでいます。

実同時変更相手とのコミットごとのヒット率 / 再現率（ハイブリッド検索）

* 検証用リポジトリで、チューニングには不使用。9リポジトリ全テーブルはbenchmarks/README.mdです。

同一トークン予算で記grepと比較すると、grepは4kトークンを越えると再現率0.215で横打ち,DiffContextは8kで0.576（2.7倍）に達します。公平な裏面もあります：デフォルトtop-kでの平均精度は0.1未満。つまり抽出された記号の大半は同時変更そのものではなく補助コンテキストです。--cutoff gapで点数が最も大きく落込むところで切ると、co-changeベンチで適合率約4倍/再現率約30%のコストになります（ContextBenchでは2.2倍/約14%のコスト）。

自前のベンチマークを監査したところ、3つの主張が崩れた

2026-07の見直しでは、ツールではなく評価手法を攻めました。公表済みの3つの数値が確認を通過できません。

• キャルブレーション — 「引用に耐える唯一の数値」（r=0.274, n≈25）は汚染されたインデックスでした。n=1,080でクリーンに再取得すると旧スコアはr=0.016 (p=0.60)：相関なし。そこで「分からない」方向に縮める修正後 → r=0.287 (p=0.0001) — 確率としてではなく、順位信号として得る。

• ブレンド重み — 配布時の\経由**[ないように**なラウをやって納得。各foldでグラフィクを低く重な blend が選ばれ。現在は[0.3, 0.5, 0.2]。

• Denseベースライン — TF-IDFが一時的を代にした experimental pass では dense retrieval を過大評価していた（0.664、BM25を5戦5勝）。実際のMiniLMエンコーダは0.597で、BM25相手には2/5しか勝てません。以前の結論の件をこの場で修正します。

-full docs: docs/auditing-my-own-benchmark.md · 素のパスは benchmarks/RIGR_REPORT_2026-07.md。

ライブラリとして使う

from diffcontext.pipeline import index_repository, analyze_impact, compile

idx = index_repository("/path/to/repo")
impact = analyze_impact(idx, ["./src/auth.py:validate_jwt"])
ctx = compile(idx, impact, max_tokens=8000, top_k=20)
print(ctx.text)  # paste-ready, meta-header discloses what was dropped

インクリメンタルAPI（idx.update([...])）、構造化された出力、拡張可能トークナイザ：docs/ARCHITECTURE.mdをご覧ください。

言語サポート状況

既知の限界（推測ではなく実測した）

静解析には天井があります。呼び出し関係をテーマに（ない）組まれとの類型的関係、クロスサブシステムの概念関連（全メソッドで0/20）、そして動的ディスパッチは測定済の盲点です。詳細はdocs/BENCHMARKS.mdです。「呼び出ししろなし」と確定する前には grep -rn "function_name(" --include="*.py" . で確認してください。

さらに

• docs/ARCHITECTURE.md — パイプライン、モジュール図、エージェントAPI

• docs/BENCHMARKS.md — 全数値、下流パス@1、制限

• docs/MCP.md — Claude Code / Cursor / Windsurf用MCPサーバー

• docs/ROADMAP.md — Measurementに基づく優先計画

• diffcontext-service/ — FastAPIサービス + Web UI

• observability/ — 検索パイプランノトレーシング

• CONTRIBUTING.md — Setup、CI gates、 adapter development

ライセンス

MIT