AIコーディングエージェントを長時間使っていると、会話が途中でおかしくなる感覚はないでしょうか。さっきまで編集していたファイルを急に忘れたり、タスクの途中でリセットされたような返答が来たり。あれはモデルが「忘れた」というより、コンテキストウィンドウが埋まって自動的に圧縮された結果、大事な情報が消えているケースが多いです。Context Modeは、そのコンテキスト問題に正面から取り組んだMCPサーバーです。単に「省略してください」という指示を追加するのとは、仕組みが根本的に違います。
どんなMCPサーバーか
Context Modeは、AIコーディングエージェントのコンテキストウィンドウ消費を構造的に削減するためのMCPサーバーです。Claude Code、Gemini CLI、VS Code Copilot、Cursorなど17のプラットフォームに対応しており、フック機構を通じてツール呼び出しの前後に介入します。
解決しようとしている問題は4つあります。ツール呼び出しの生データがそのままコンテキストに流れ込むこと、会話が圧縮されるとセッションの作業履歴が消えること、LLMがデータを直接処理しようとして大量のファイルを読み込むこと、そして不必要な出力を出力トークンとして消費すること、です。これらを「サンドボックスツール」「SQLiteによるセッション継続」「コード実行による分析の代替」という3つの仕組みで対処しています。
スター数は2万を超えており、Hacker Newsでも1位を獲得したことがあるようです。Claude Codeのプラグインマーケットプレイスから1コマンドでインストールできる点も、実際の利用者が多い理由のひとつかもしれません。
設計でここが上手い
サンドボックスとコンテキストの完全な分離
MCPのツールが返す生データをコンテキストウィンドウに直接流さず、サンドボックス内で処理してから必要な部分だけを返す設計が、このリポジトリの核心です。Playwright のスナップショットは56KB、GitHub issues 20件で59KB、アクセスログ1件で45KBとREADMEに書かれていて、それが ctx_execute や ctx_batch_execute を経由することで大幅に圧縮されます。READMEに示されている事例では315KBが5.4KBになっています。数字の真偽はさておき、「ツール呼び出しの結果をすべてコンテキストに流す」という前提を崩した点は、アーキテクチャとして興味深いです。
「LLMにデータを処理させない」という方針の徹底
「Think in Code」と名付けられたこの方針が、CLAUDE.mdの最上部に書かれています。50ファイルの行数を数えたいなら、50回Readツールを呼ぶのではなく、そのカウントを行うスクリプトを書いて ctx_execute で実行し、console.log の出力だけをコンテキストに戻す、という発想です。47回のRead呼び出しが700KBのコンテキスト消費になる代わりに、1回のスクリプト実行で3.6KBに収まるという対比がREADMEに示されています。LLMをデータプロセッサではなくコードジェネレーターとして扱う、という考え方をシステム側から強制する構造になっています。
セッション継続の仕組み
会話が圧縮（コンパクション）されると、通常はその時点までの文脈が大幅に失われます。Context Modeは、ファイル編集・git操作・タスク・エラー・ユーザーの判断をSQLiteに記録し続け、圧縮後もそのデータを一括でコンテキストに戻すのではなく、FTS5全文検索（BM25スコアリング）で必要な情報だけを取り出す設計にしています。「–continueで再開しなければ直前のセッションデータは削除される」という判断も、クリーンな状態を保つための明確なポリシーです。あいまいに残し続けるより、意図的なリセットを明示する設計は、運用上の混乱を減らすかもしれません。
フック機構を通じたルーティングの自動化
Claude CodeやGemini CLIなどフック対応プラットフォームでは、SessionStartフックが起動時にルーティング指示を自動注入するため、プロジェクトにファイルを書き込む必要がありません。これは、チームで使うときにリポジトリを汚さずに済む点で便利です。一方、フック非対応プラットフォームでは設定ファイルを一度コピーする必要があり、その差がドキュメントに明記されています。対応プラットフォームを2段階に分けて丁寧に説明している姿勢は、ユーザーが迷いにくい構成だと思います。
こういう人に向くかも
Claude Codeや Gemini CLIを使って長時間のコーディングセッションを行う機会が多く、「会話の途中でエージェントが迷子になる」経験をしたことがある開発者には、試してみる価値がありそうです。特に、大きなリポジトリで複数ファイルにまたがる作業をすることが多い場合、ツール呼び出しのたびにコンテキストが削られていく問題は体感しやすいはずです。
逆に、短い1問1答型の使い方が中心であれば、Context Modeが解決しようとしている問題はほとんど発生しないかもしれません。セッション継続やコンパクション後の復元といった機能は、長時間セッションを前提にした設計だからです。また、17プラットフォームへの対応を謳っているだけあって、設定の複雑さもプラットフォームごとに異なります。Claude Codeのプラグインマーケットプレイス経由が最も手軽で、他のプラットフォームではJSONの手動設定が必要です。
設計の良し悪しをどこで見るか
機能の単一性と責務の集中
Context Modeは「コンテキストウィンドウを守る」という目的に機能を絞り込んでいます。ただし、その実現のために複数の仕組みを内包しています。サンドボックス実行、SQLiteによる履歴管理、FTS5検索、フック連携、ステータスライン表示、Discordコミュニティなど、機能の範囲は想定より広いかもしれません。単機能とは言いにくいですが、「コンテキストを守る」という軸には一貫性があります。機能が増えるにつれて設計の焦点がぶれていないかは、継続的に見ておくべき点だと思います。
ドキュメントの深度
READMEはプラットフォームごとのインストール手順をdisclosure（折りたたみ）で整理しており、必要な情報を探しやすい構造になっています。CLAUDE.mdには「このツールを使うときにモデルがどう振る舞うべきか」が明示されており、ルールの意図とコマンドの対応が表形式でまとめられています。一方で、ライセンスは「ELv2（Elastic License 2.0）」と記載されていますが、GitHubのLicense検出では「NOASSERTION」になっています。商用利用の制約について事前に確認しておくことをおすすめします。特にチーム導入や業務利用を検討する場合、ELv2の条件を自分で読んで判断するのが安全です。
トークン経済性
このリポジトリが最も力を入れているのが、まさにこの観点です。ctx_batch_execute で複数コマンドをまとめて実行し、結果を自動インデックスして必要分だけ返すアーキテクチャは、オンデマンド設計の典型といえます。コンテキストに流れるのは「検索で取り出した断片」だけで、生データは原則としてコンテキストに入りません。ただし、この設計は「エージェントがルーティング指示に従う」という前提に依存しています。指示を無視してRawなReadツールを呼び続ければ、節約効果は薄れます。CLAUDE.mdの冒頭に「MANDATORY」と大文字で書かれているのは、この前提を崩されないための防衛策でしょう。
想定外の使われ方への備え
ctx_purge でインデックスを完全削除できる、--continue なしで起動すれば前セッションが消えるなど、「リセット手段」が明示されている点は好感が持てます。予期せずデータが積み上がり続けるより、意図的なクリーンアップの動線があるほうが、長期運用では安心しやすいです。
自分が書くなら、どこを変えるか
ひとつ気になるのは、「Think in Code」の強制が万能ではない点です。エージェントが生成したスクリプトそのものに誤りがあった場合、デバッグに追加の往復が必要になります。サンドボックス内で実行するため副作用は限定されますが、スクリプトのエラー出力がコンテキストに戻ってくるケースの扱いについては、ドキュメントがやや薄い印象です。エラーのハンドリングポリシーと、デバッグ時のコンテキスト消費についての記述があると、初めて使う人が判断しやすくなるかなと思います。
もうひとつは、SQLiteに記録されるセッションデータの可視化です。ctx_stats でコンテキストの節約量は見えますが、「どんな情報が記録されているか」「何件インデックスされているか」を一覧できる手段がやや限られています。ctx_insight でダッシュボードを開けるとありますが、外部サービス依存になるため、ローカルで完結する確認手段があるとチームでの利用がしやすくなりそうです。設計の方針としては「シンプルに保つ」という意識がありそうなので、そのトレードオフは理解できます。
導入を検討するときのチェック観点
- 使っているコーディングエージェントが17対応プラットフォームに含まれているか
- フック対応プラットフォームかどうか（Claude Codeなら最も手軽、それ以外はJSON設定が必要）
- ライセンスがELv2であることを確認し、業務利用の条件を事前に把握しているか
- Node.js 22.5以上がインストールされているか（多くのプラットフォームで前提条件）
- SQLiteのデータがローカルに蓄積されることを考慮し、センシティブな情報の取り扱いポリシーを確認しているか
ctx_doctorで動作確認が取れるか（インストール後に最初に確認する手順として明示されている）- セッション継続が不要な用途かどうかを判断した上で、
--continueオプションの使い分けを把握しているか
積み上がるコストの置き場
コンテキストウィンドウは有限で、ツールを呼ぶたびに削られていきます。これまでその消費をどこかで諦めていたとすれば、Context Modeはその「どこか」を設計で置き換えようとしたリポジトリです。すべてのプロジェクトに合うわけではないですが、長時間セッションで作業するエンジニアにとっては、一度試してみる価値のある仕組みだと思います。ライセンスと設定の確認を先に済ませた上で、ctx_doctor の結果を見ながら自分の環境に合うかどうかを判断するのが、最初のステップとして自然かもしれません。
