MCPコンテクスト肥大化：Claude Codeユーザー向けの実質的なコストと実用的な修正方法

4ヶ月間Claude Codeで9つのMCPサーバーを実行しているRedditユーザーが、直面した隠れたコストとパフォーマンス低下、および具体的な解決策を詳述しました。この投稿は、MCPを本番環境で使用するすべての人にとって必読です。

計算

9つのサーバー（filesystem、GitHub、Stripe、Linear、Notion、Postgres、Sentry、AWS、カスタム）で合計142のツールを公開している場合、コールドスタートでは毎ターンシステムプロンプトとツールスキーマに38kトークンを消費します。1日200ターンの場合、1日あたり760万入力トークンになります。Sonnetの価格（出力100万トークンあたり約15ドル、入力100万トークンあたり約3ドル）では、実際の作業を行う前のMCPツール定義だけで1日約23ドル、月額約700ドルになります。キャッシュは同一のプレフィックスにのみ有効で、1つのMCPサーバーをローテーションするとキャッシュが無効になります。

問題点

• ツール選択の品質低下：142のツールがコンテキストにあるため、Claudeが明らかなクエリに対して誤ったツールを選び始めました（例：ファイルを読むよう指示したときにlinear_search_issuesを使用）。
• 列挙の遅さ：AWSのようなスキーマが多いサーバーでは、ツール一覧表示に4～6秒かかります。
• エラーの無言伝播：1つのツールの説明が不適切だと、関連するすべてのクエリのランキングが損なわれる可能性があります。

解決策：BM25を使用したゲートウェイパターン

ユーザーは、BM25ランキングを備えたオープンソースのインプロセスRustライブラリRatelを使用したゲートウェイパターンに切り替えました。Claudeが認識するツールはsearch_tools、invoke_tool、authの3つだけです。その他はすべてオンデマンドでランク付けされます。結果：

• コールドスタートが38kトークンから約4kトークンに削減。
• 誤ったツール選択がほぼ解消されました。モデルはクエリに基づいてランク付けされた上位5つのツールしか見ないためです。
• セットアップは10分で完了しました（1つのコマンドでClaude Codeインポートが可能）。

著者は、ほとんどの「MCP最適化」スタートアップはBM25検索を装ったものに過ぎないと指摘しています。ツールの説明は短く構造化されており、キーワードマッチで溢れています。ベクトルDBやLLM-in-the-loopは不要です。名前と説明のフラットな射影に対するBM25で、決定論的にマイクロ秒、オフラインで90%の効果が得られます。

重要な教訓：「提案」ではなく「置き換え」が効果的です。ゲートウェイが142のツールの代わりに5つのツールをモデルに渡せば、計算が成り立ちます。5つのツールを142と一緒に提案しても、モデルは依然として142のツールをロードするため、何も節約できません。