Claude Code MCPスタックの測定：キャッシュ親和性とバイト節約の比較、およびプロンプトキャッシュの2行修正

Claude CodeのMCPスタックを最適化する際、1つの指標（バイト節約量）に集中しがちです。しかし、Greg Shevchenkoの新しい分析は、単一軸のベンチマークでは本番環境で厳密に悪いシステムを推奨する可能性があることを示しています。見落とされていた軸は、キャッシュ親和性、つまり同じ入力が実行間でバイト単位で同一の出力を生成し、Anthropicのプロンプトキャッシュがヒットするかどうかです。

Shevchenkoが最もバイトを節約したシステム（コンテキストを60～70%削減する検索MCP）は、実は毎回の呼び出しで5分間のTTLプロンプトキャッシュを無効化していました。同じクエリの2回の実行で異なるバイトが生成されたのは、rg --files-with-matchesの出力順序がMapへの挿入順序を通じて最終的なコンテキストに漏れたためです。修正は2行：スライス前にrgのヒットをソートし、Mapのエントリをパスでソート。変更後、バイト節約量は変わらず、cache_friendly_scoreは約0%から100%になりました。

ハーネスが測定するもの

Shevchenkoはオープンソースのベンチマークハーネス（stdlibのみのPython、オフライン）を公開し、以下を測定します。

• 平均比率 + CV：フィクスチャあたりN≧5回の実行で、バイト節約軸
• ユニークMD5カウント == 1チェック：キャッシュ親和性軸（0～100%）
• 12のアンチパターン監査：ツール定義における（DSA参照）

任意の圧縮機を(str) -> strとしてプラグイン可能。ハーネスはクラスタブートストラップCI、Wilson CI、事前登録、実データのCohen's κを使用。

調査された公開代替手段

Shevchenkoは公開ドキュメントを調査：Cursorコードベースインデックス、Sourcegraph Cody、Aider repo-map、Microsoft LLMLingua/LLMLingua-2、Firecrawl/Jina Reader、RouteLLM/Martian（2026年5月時点）。キャッシュ親和性の指標を開示したものはありませんでした。

制限

彼は準備レイヤーが後続のターンでより多くのダウンストリームキャッシュヒットを引き起こすと仮説を立てましたが、有意には達しませんでした（Welch p=0.32、Cohen's d≈0.18、N=137）。コーパス上の2判定者Cohen's κは0.5955（中程度、0.7未満）、5つの不一致のうち4つは曖昧なタスクによるもので、仕様を修正すればκは約0.83に上昇します。

ハーネスはMITライセンスです。Claude Code MCPスタックを実行しているなら、cache_friendly_scoreの測定は具体的で実行可能なステップです。