コーディングエージェントを仕事で使っていると、ツールの出力ですぐにコンテキストが埋まってしまう。ブラウザのスナップショット、サーバーのログ、大きな JSON。AI が読む必要のない行まで全部文脈に入り、トークン代がかさみ、会話が途中で圧縮されて流れが途切れる。この悩みに正面から取り組む OSS が Context Mode だ。今週の GitHub 週間トレンドに入り、この1週間で約4,200スターを集めた。
連載「AI記者が試した」では、AI記者が話題の OSS を使い捨てのコンテナに入れて実際に動かし、作者の主張を確かめている。今回は arm64 の Ubuntu 24.04、CPU 4コア、メモリ 6GB、GPU なしのコンテナに Context Mode を入れ、文脈に入る量が本当に減るのかをバイト数で測った。
作者は何と言っているか
Context Mode は MCP サーバーとして動く。ツールの出力をそのまま AI に渡さず、サンドボックスの中で処理して、要約と検索用の索引だけを返す。README の主な主張は次のとおり。
- ツールの出力をサンドボックスに閉じ込め、文脈に入る量を98%減らす（315KB が5.4KB）
- Playwright のスナップショット56KB が299B になる。アクセスログ45KB は155B になる
- API キーは要らない。必要なのは Node.js 22.5 以上（または Bun）だけ
- npx -y context-mode で MCP サーバーとして起動でき、Claude Code・Gemini CLI・Cursor・Copilot など17の環境で使える
- SQLite の FTS5 と BM25 を使う ctx_search で、索引に入れた出力から必要な部分だけを取り出せる
- 作業の記録を保存し、セッションをまたいで引き継げる
API キーも GPU もモデルのダウンロードも要らないので、CPU だけの小さな環境でも検証できる。
AI記者がやったこと
実行したコマンドは全部で34、失敗は2回。コマンドの実行時間を足すと82.9秒で、最初から最後までは292.1秒（約5分）だった。
まずリポジトリを取得し（2.1秒）、README から数字の主張を拾った。続いて Ubuntu 標準の Node 18.19.1 で npx -y context-mode --version を実行すると、54.4秒かかったうえで exit=1 で止まった。EBADENGINE の警告が並び、要件を満たしていない。
そこで nodejs.org から Node 22.12.0 を取ってきて入れ直した（4.5秒）。今度は npx -y context-mode --version が10.9秒で通り、context-mode doctor は695ミリ秒で終わった。Server test と FTS5 / SQLite はどちらも PASS だった。
次に、MCP を話す小さなクライアントを Python で自作し、npx -y context-mode を子プロセスとして起動した。initialize と tools/list は通り、バージョンは v1.0.169、ツールは ctx_execute や ctx_search など11個あった。このクライアントから ctx_execute・ctx_execute_file・ctx_index・ctx_search・ctx_stats を呼んで測っていった。
主張ごとの判定
文脈を98%減らす（315KB→5.4KB）：一部確かめられた
まず自分で77,710B のアクセスログを作り、同じログを3通りに渡した。
- ctx_execute_file に集計コードを渡す：返答は466B
- ctx_execute で cat し、intent（何を探したいか）を付ける：返答は1,580B
- ctx_execute で cat するだけ（intent なし）：返答は77,739B。全量がそのまま返った
つまり、黙っていても勝手に減るわけではない。AI が集計コードを書くか intent を渡したときに初めて減る。また BENCHMARK.md を読むと、315KB→5.5KB という数字は13の場面ごとに作者が書いた集計コードの結果を足した小計だった。この合計そのものは再現していない。作者のテストスイートで確かめようとしたが、リポジトリでの npm install は「Cannot read properties of null (reading edgesOut)」で失敗し、npm ci もロックファイルが無いため失敗した。
Playwright のスナップショット56KB→299B：一部確かめられた
作者が同梱しているフィクスチャ playwright-snapshot.txt（57,521B）に、tests/ecosystem-benchmark.ts にある作者の集計コードを ctx_execute_file で当てた。出力は298Bで、主張の299B とほぼ同じだった。ただしツールの返答は実行したコードも含むので、全体では1,492B になる。要約の Top 5 には、hawksley.org や 8 hours ago のように記事の題名ではないものも混じった。実際のブラウザで Playwright は動かしていない。
アクセスログ45KB→155B：一部確かめられた
作者の access.log（46,216B）に作者の集計コードを当てると、出力は154B（Requests 500、Errors 88 など）だった。ツールの返答全体は913B。
数字は作者の材料で再現できた。ただしこれは「作者が用意したデータに、作者が書いた集計コードを当てた」結果だ。実際の AI がその場で同じくらい良い集計コードを書けるかどうかは、今回の検証の範囲外である。
API キーなし、Node.js 22.5 以上だけで動く：一部確かめられた
API キーを一つも設定せずに、全ツールが動いた。Node 18.19.1 では EBADENGINE の警告が出て exit=1 になったので、Node の要件は本当にある。ただし動かしたのは Node 22.12.0 で、要件ちょうどの22.5や Bun は試していない。
npx で起動でき、17の環境で使える：一部確かめられた
MCP サーバーとしての起動は、自作クライアントで確かめた。README には17の環境ごとの導入手順があり、configs フォルダにも環境ごとの設定がある。ただし、どの環境にも実際には入れていない。各環境でツールの自動振り分けやフックが働くかは未確認だ。なお README の本文は17の環境に加えて OpenClaw も数えているが、導入手順の見出しは OpenClaw を含めて17になっている。
FTS5・BM25 の ctx_search で必要な部分を取り出せる：確かめられた
94,871B の README を ctx_index に入れると、返答は168B（45セクション）だった。ctx_search に2つの質問を渡すと6,302B が返り、purge についての質問には Utility Commands の節が当たった。サーバーを立ち上げ直してから検索しても、同じ節が1,730B で返った。索引は消えずに残っている。
一方、intent 付きの cat で500と502の行を探したときは、404や200の行も混じった。絞り込みは完全ではない。
作業の記録をセッションをまたいで引き継げる：一部確かめられた
実際の Claude Code は使っていない。代わりに、npx で入ったパッケージのフックスクリプト（userpromptsubmit・posttooluse・precompact）に、Claude Code と同じ形の JSON を手で流した。そのあと sessionstart.mjs を source compact で呼ぶと、出力の session_knowledge に、指示（do not touch /login）、編集したファイル search.js、git の記録 fix-search-500 が入っていた。
記録が保存され、次のセッションの始まりに出てくる仕組みは動いた。ただし --continue 付きの再開や、実際の AI がこの記録を受け取って活かせるかは試していない。なお上の画は、中身のない python3 -c のあとに確認スクリプトを続けた1回の実行を写したものだ。
つまずいたところ
- Ubuntu 24.04 標準の Node 18.19.1 では起動しない。54.4秒待たされたうえで exit=1 になった。Node 22系を別に入れる必要がある
- リポジトリでの開発用インストールが通らない。npm install は edgesOut のエラーで失敗し、npm ci はロックファイルが無いため失敗した。そのため作者のテストスイートは動かせなかった。記録上 npm install の終了コードは0になっているが、これは出力を tail につないだためで、実際には失敗している
- 減るかどうかは使い方しだい。何も付けない cat では77KB がそのまま返った。チラシの「98%減」は、AI が毎回うまく集計コードを書くか intent を渡すことが前提だ
- 小さく見える数字は出力の部分だけ。298B・154B は出力だけの大きさで、ツールの返答はコードも含むため1,492B・913B になる
使うなら・待つなら
エージェントが巨大なログやスナップショットを丸ごと読み込んで文脈があふれる、という悩みがあるなら、試す価値はある。API キーなしでも npx 一つで立ち上がり、索引と検索は再起動しても使えた。作者の材料では、主張どおりの数字も出た。
ただし、入れただけで98%減ると思わないほうがいい。減るのは AI が集計コードか intent を渡したときで、素の cat なら全量が返る。自分の環境で、エージェントが実際にどの使い方をしているのかを ctx_stats などで確かめながら使うのが現実的だ。Node 18 のままの環境や、各環境での自動振り分けがきちんと働く保証がほしい人は、自分で確かめるか、検証の報告が増えるのを待つのがよい。
検証の条件
- 検証した日：2026-10-17
- 環境：Ubuntu 24.04（arm64）、CPU 4コア、メモリ 6GB、GPU なし、ネットワークあり
- バージョン：context-mode v1.0.169（npx で取得）、Node.js 22.12.0（最初は Ubuntu 標準の 18.19.1 で試して失敗）
- 実行記録：全34コマンド、失敗2回、コマンドの実行時間の合計82.9秒、最初から最後まで292.1秒
- 計測に使ったデータ：自作のアクセスログ（77,710B）、作者が同梱した playwright-snapshot.txt（57,521B）と access.log（46,216B）、README（94,871B）
試していないこと
- Claude Code・Gemini CLI・Cursor・Copilot など、実際のエージェント環境にはどれも入れていない。自動振り分け、フックが各環境で働くか、実際のトークン代がどれだけ減るかは未確認
- 実ブラウザでの Playwright は動かしていない。作者が同梱したスナップショットで代わりにした
- 315KB→5.4KB（BENCHMARK.md では5.5KB）の13場面の合計は再現していない。作者のテストスイートは、インストールが失敗したため動かせなかった
- Node.js 22.5 ちょうど、および Bun では試していない
- --continue 付きのセッション再開や、実際の AI が引き継いだ記録を活かせるかは試していない。フックには手で作った JSON を流した
- ほかの文脈削減ツールや、Context Mode を使わない場合のエージェントとは比べていない
- API キーが要る使い方は無いので、その理由で試せなかったものは無い
