context-modeの使い方、ログは99%縮んだのにエラー行が見えなかった

context-modeは、Claude Codeなどのエージェントに渡る重いツール出力を別プロセスで受け、索引と一部だけを会話に返すMCPサーバーです。436KBのテストログで試すと返答は1KB未満に縮みましたが、intent付きのプレビューにエラー行は出ませんでした。

Playwrightのスナップショットや数千行のテストログで、エージェントの文脈がすぐ埋まったことはありませんか？ 気になるのは削れた量より、削ったせいで見えなくなった行のほうです。エラー行そのものは消えておらず、ctx_search で引き直すと2行とも返ってきました。

GitHub - mksglu/context-mode: Context window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP + hooks.

Context window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP + hooks. - mksglu/context-mode

github.com

context-modeは、Claude Codeのツール出力をどこで削るのか

Claude Codeがコマンドを実行すると、その出力はそのまま会話の文脈に入ります。READMEには、Playwrightのスナップショット1回で56KB、GitHubのissue20件で59KB、アクセスログ1本で45KBという例が並んでいます。これが何度か入るだけで、推論に使える枠は減っていきます。

context-modeは、この重い出力を会話に入る手前で受け止めます。ctx_execute などの専用ツールでコードを別プロセスのサンドボックスで動かし、会話に返すのは標準出力だけです。出力が5KBを超え、何を探しているかの一言（intent）が渡されたときは、全文をローカルのSQLiteに索引して、intentに合う部分だけを返します。

Claude Codeにプラグインとして入れると、hooksも一緒に入ります。hooksはツールの実行前後に割り込む仕組みで、context-modeはここでBashやRead、WebFetchの大きな出力を専用ツールへ振り分けます。会話の圧縮の前に作業状態を2KBの枠でまとめ、あとで戻す機能もあります。このあたりは公式の説明によるもので、僕はhooksの動きは試していません。

ツールは11個あり、処理を受け持つのが ctx_execute や ctx_search など6つ、残りは ctx_stats（節約量の確認）や ctx_doctor（インストールの診断）といった補助です。

Claude Codeへの入れ方と、MCPだけ登録する方法の違い

READMEが勧めているのはプラグイン方式です。Claude Codeの中で次の2つを実行します。

/plugin marketplace add mksglu/context-mode
/plugin install context-mode@context-mode

要件はClaude Code v1.0.33以上と、Node.js 22.5以上（またはBun）です。お使いのNode.jsは22.5を超えていますか？ 入れる前に node -v で確かめておくと、つまずきが1つ減ります。

MCPサーバーとしてだけ登録する方法もあります。

claude mcp add context-mode -- npx -y context-mode

こちらでも11個のツールは使えますが、hooksは入りません。READMEの説明では、モデルはツールを使えても、生のBashやReadより優先するようには促されない状態です。重い出力を確実に振り分けたいなら、プラグイン方式を選びます。

僕が動かした環境はこれとは別で、使い捨てのコンテナ（node:22-bookworm）の中です。Claude Codeには入れず、MCPサーバーの start.mjs を標準入出力で直接呼ぶ小さなクライアントを書き、ツールを1つずつ呼びました。リポジトリ直下の npm install --omit=dev は約21秒で TypeError: Cannot read properties of null (reading 'edgesOut') を出して失敗しましたが、同梱の server.bundle.mjs のおかげで node start.mjs はそのまま起動しました。

436KBのE2Eログをcontext-modeに渡した4つの条件

渡したのは、E2Eテストを模して作った架空のログです。4,000行で436,005バイトあり、INFO行の中にERROR行が2行だけ混ざっています。1234行目が TimeoutError: locator("#pay-button") not visible after 30000ms、2890行目が expect(received).toBe(expected) Expected: 3 Received: 2 でした。

このログを出すコマンドを、4つの条件で実行しています。

量だけ見れば、436KBがどの条件でも1KB前後から2.5KBに収まりました。Bで約99.8%、Cで約99.4%の削減です。ただ、架空のログを公式とは別の条件で流した数字なので、公式の98%と並べて比べるものではありません。

Aではログの中身が1行も返らず、「Indexed 1 sections」と、ctx_search で検索するよう促す案内だけでした。intentなしは、続けて検索する前提の呼び方です。

context-modeのプレビューに、エラー行が出なかった

Bの返答には「Indexed 223 sections」「2 sections matched」とあり、intentに渡した failing tests and error messages に合う区切りを2つ見つけています。ところが、その下のプレビューに見えていたのは INFO [test-4] step 1225 passed という行でした。もう1つも2881行目の passed の行で、どちらもERROR行の少し手前にある正常な行です。

返ってきた中身を見るかぎり、プレビューには区切り（セクション）ごとの先頭の行が出ているようでした。エラー行はセクションの途中にあったので、先頭だけのプレビューには入らなかったと僕は読んでいます。ソースまでは確かめていないので、これは推測です。

プレビューだけ読むと、エラーは無いように見えます。失敗を探してログを読む場面で、これが一番困ります。「2 sections matched」を読み飛ばし、passedしか出ていないから通ったと判断すれば、2件の失敗をそのまま見逃します。

エージェントに失敗ログを読ませたあと、返ってきた要約のどこを見て「問題なし」と決めていますか？ 件数と中身が食い違っていたら、中身を引き直すのが先です。

ツール出力から消えると困る行を、ctx_searchで拾う

索引そのものは残っていました。Cでは、サーバーを別プロセスで起動し直してから ctx_search を呼んでいます。クエリは TimeoutError pay-button と ERROR Expected Received の2つで、limit は3です。返ってきた2,574バイトの中に、2つのERROR行が前後数行と一緒に入っていました。

返答の末尾には「Throttle: call #1/8 in this window」とありました。READMEによると、短い間に呼ぶ回数が増えると返る件数が減り、9回目からは止められます。クエリは最初から並べて、1回で投げるほうが向いています。

もう1つは、絞り込みをコードに書く方法です。Dでは bash gen.sh | grep ERROR を ctx_execute で実行し、241バイトでERROR行2行だけが返りました。素のbashで同じ絞り込みをすると191バイトなので、context-modeを通した上乗せは50バイトほどです。

探す語が決まっていればDのようにコードで絞り、決まっていなければintentで当たりを付けてから ctx_search で中身を引く。プレビューは判断に使わない、というのが今回の結論です。intentの言い回しは1通りしか試していないので、書き方しだいでプレビューに出る可能性は残ります。

あなたのログで、絶対に落としたくない1行は何でしょうか？ TimeoutError や Expected のように、エラー文に必ず出る語が分かっていれば、それがそのまま検索語になります。

98%の数字と、context-modeを入れる前に確かめること

READMEの「315KBが5.4KB、98%減」は、Playwrightのスナップショットやアクセスログなどのツール出力をバイトで測った例で、トークン数の話ではありません。BENCHMARK.md では21のシナリオで376KBが16.5KBになり、全体で96%減です。ログやテスト出力を処理するシナリオは95〜100%減る一方、ドキュメントを索引して検索するシナリオは44〜93%に散らばっています。要約で済む出力ほどよく減る、と読めます。

会社のPCに入れるなら、ライセンスも確認が要ります。MITなどのOSSライセンスではなく、Elastic License 2.0です。社内で使うぶんには引っかかりにくいものの、第三者へのホスティングやマネージドサービスとしての提供と、ライセンスキーの仕組みの回避は禁じられています。

索引したログはホームディレクトリのSQLiteに置かれ、今回もサーバーを起動し直したあとで引けました。顧客データが混じるログを渡すなら、索引をまとめて消す ctx_purge があることも覚えておきたいところです。

最新のリリースはv1.0.169（2026年6月29日）で、mainには2026年10月20日までコミットが続いています。対応環境は公式の説明文で17ですが、hooksへの対応には差があり、hooksが使えない環境ではREADME自身が指示の遵守率を約60%としています。

長いテストログやスナップショットを何度も読ませる作業なら、試す価値はあります。見るべきは縮んだ量より、縮んだ返答に欲しい行が入っているかです。プレビューで判断せず、ctx_search で引くか、絞り込みをコードに書く。この2つを決めてから入れれば、見落としにくくなります。