context-mode - ツール出力を外部処理し、検索とセッション記憶でエージェントの文脈を保つ
Context Mode(パッケージ・CLI名はcontext-mode)は、AIコーディングエージェント向けのMCPサーバーとクライアント別プラグインである。ログ、ブラウザーのスナップショット、API応答などの大きなツール出力は、そのまま会話に入ると有限のコンテキストを消費する。このツールは、生データの処理を会話の外へ移す。モデルは分析コードや検索意図を書き、別プロセスで計算した結果、または索引から取り出した原文の該当箇所だけを受け取る。 構成は三層で読める。サブプロセスでコードを実行して標準出力だけを返す層、出力や文書をSQLite FTS5へ索引化して検索する層、フックで集めた作業イベントを保存して会話圧縮後に復元する層である。主な留意点は二つある。対応範囲がクライアントごとに異なること、そして説明の根拠がREADMEとリリースノートにとどまることだ。「約98%削減」などの数値は作者の報告であり、サブプロセスは完全なOSサンドボックスでもない。
なぜ注目されているか
10月2日の観測ではGitHub Trendingの日次8位に入り、当日のスター増加は362。累計24,782スター、1,784フォークが確認できる。継続的な成長率や10月5日の掲載時点の順位は、この資料だけでは分からない。
なぜ重要なのか
エージェント運用では、モデルの会話に何を載せるかが設計上の論点になる。従来はツール出力を会話へ流し、選別もモデルが担っていた。context-modeは、その選別を会話の外の計算と検索へ委ねる。モデルの役割は、データを読むことから、データの扱い方をコードや検索意図として書くことへ寄る。この分担の変化は、MCP連携とコンテキスト管理を考える題材になる。
作業状態をSQLiteへ外出しすれば、会話の圧縮や再開を前提にした運用も選べる。ただし効果は、フックで経路を遮断でき、圧縮前後の保存と復元が使えるクライアントに限られる。会話へ渡さない情報は、取りこぼしの可能性と引き換えでもある。精度への影響は取得資料から分からない。本稿は、仕組みを理解し、導入条件を判断するための整理として読んでほしい。
この記事に出てくる言葉(6語)
- ctx_execute
モデルが生成したコードを呼び出しごとの独立サブプロセスで実行し、標準出力だけを会話へ返すツール。READMEは12言語に対応すると説明する。
- intent
大きな実行結果から必要な箇所を選ぶための検索意図。標準出力が5KBを超えて指定されていると、全出力を索引化したうえで合致箇所を返す。
- SQLite FTS5 / BM25
SQLiteの全文検索機能と、その順位付けに使うスコア関数。本ツールは見出し単位に分割したMarkdownを保存し、見出しを5倍に重み付けする。
- Reciprocal Rank Fusion(RRF)
複数の検索結果の順位を統合する手法。本ツールは語幹検索とtrigram検索の結果をこれで統合する。
- 経路制御
大きな出力を生むツール呼び出しを、集計や索引を経由する経路へ遮断・誘導すること。フックはプログラムで遮断でき、指示ファイルはモデルへの依頼にとどまる。
- セッションスナップショット
PreCompact時にイベントから作る、優先度別で2KB以下のXML。session_resumeテーブルに保存され、復元時に保存状態として読み出される。
1. 読む前に知っておきたいこと
ツール出力が会話を占有する構造
通常のエージェントは、Bash、Read、WebFetchや外部MCPツールの出力をそのまま会話に取り込み、集計も選別もモデル自身が行う。READMEはここを課題に挙げる。ログ、ブラウザーのスナップショット、API応答、ファイル内容が直接入ると、有限のコンテキストを生データが占める。複数ファイルを読むだけで容量を使い、集計のための反復的な読み取りはツール呼び出しと入力量も増やす。
会話圧縮と作業状態の喪失
容量が尽きると、クライアントが会話を圧縮し、残った文脈から作業を続ける。READMEは、この過程で作業中のファイル、未完了のタスク、ユーザーの判断が失われると述べる。再開後に修正指示を説明し直す手間が生じる。圧縮自体はクライアントの機能で、このツールが狙うのは、圧縮の前後で作業状態を外部へ保存し、戻す段階である。
指示文だけでは経路を縛れない
出力を絞る方針を指示文に書いても、モデルが通常のツールを選べば、大きな出力は再び会話へ流れ込む。READMEは、フックならツール呼び出しをプログラムで遮断・誘導できる一方、指示ファイルはモデルへの依頼にとどまると説明する。この差は、後述するクライアント別の対応差を読む軸になる。
本稿の根拠範囲
リポジトリはmksglu/context-modeで、主要言語はTypeScript、作成は2026-02-23(製品の初公開日とは限らない)。READMEの正式表記はContext Modeで、パッケージとCLIにはcontext-modeを使う。取得できた最新リリースはv1.0.169(2026-06-29公開)で、10月時点の開発状況は確認できていない。技術的な説明はREADMEとリリースノートに依拠する。実装コード、設計文書、テストは取得しておらず、実装を独立に検証した記述ではない。
2. どう動くのか
構成要素と全体の流れ
中核はMCPサーバーで、クライアントごとにアダプターが付く。Claude Codeでは11のMCPツール(処理・検索6、メタ5)を登録する。OpenCodeとKiloCodeはTypeScriptプラグインとして同一プロセス内でツールを提供する。OpenClawはgatewayプラグイン、Pi Coding AgentとOMPは拡張のイベントに接続する。保存先はSQLiteで、bun:sqlite、node:sqlite、better-sqlite3を環境に応じて選び、要件はNode.js 22.5以上またはBunとされる。
一回の作業は次の順に進む。まず呼び出し前のフックが、大きな出力を生む経路を遮断・誘導する。次にモデルが分析コードをctx_executeへ渡し、標準出力だけが戻る。出力が大きければ索引へ退避され、intentに合う箇所だけが戻る。追加情報はctx_searchで原文の該当箇所として引く。実行後のフックは作業イベントを保存し、圧縮の前後でスナップショットの保存と復元が走る。以下、順に見る。
出力の隔離:ctx_executeとintent
ctx_executeは、モデルが書いた分析コードを呼び出しごとの独立サブプロセスで実行し、標準出力を返す。対応は12言語である。README掲載の例は、src配下の.tsファイルを列挙してファイル名と行数だけを出力するコードで、ファイル本体は会話に入らない。複数ファイルの読み取りと集計を一度の実行にまとめ、反復読み取りで増えるツール呼び出しと入力量を避ける狙いと読める。標準出力が5KBを超えintentが指定されていれば、全出力を知識ベースへ索引化し、意図に合う箇所と追加検索用の語彙を返す。単純な切り詰めと違い、出力は捨てずに会話の外へ退避され、後から検索できる。返される語彙は、最初のintentが外れたときの再検索の手がかりになると読める。ただし何が届くかは、モデルが書くコードとintentの質に左右される。
索引と検索:FTS5・BM25・RRF
索引への入口は二つある。ctx_indexがローカル内容を、ctx_fetch_and_indexがURLの内容を分割・保存する。Markdownは見出し単位に分け、コードブロックを保ったままSQLite FTS5へ入れ、BM25で順位付けし、見出しを5倍に重み付けする。検索はctx_searchが担い、Porterトークナイザーの語幹検索とtrigramの部分文字列検索を並列に走らせ、Reciprocal Rank Fusionで統合する。近接度による再順位付け、誤字補正、検索語周辺の原文抜粋も備える。URLはHTMLをMarkdownへ変換して索引化し、既定24時間のTTL内は再取得しない。14日より古いコンテンツDBとソースは、起動時に削除すると説明されている。語形の揺れへの対処は読み取れるが、語彙が一致しない言い換えの扱いは資料から分からない。
経路制御:フックと権限設定
ツール呼び出し前のフックが、大きな出力を生む経路を規則に応じて遮断・誘導する。フックのないクライアントでは、コピーした指示ファイルに従うモデルの選択に依存する。権限面では、Claude Code形式の権限設定を参照してdeny規則を実行ツールへ適用する。設定がなければこの制御は有効にならない。ctx_execute_fileにはプロジェクト境界の検査があり、URL取得先にも制限を設ける。ただし既定の範囲は後述する。強制力はクライアントが提供するフックに左右され、ツール単体で閉じた保証ではない。
セッション記憶:保存・圧縮前スナップショット・復元
ツール実行後のフックが、ファイル操作、タスク、Git操作、エラーなどの構造化イベントをSQLiteへ保存する。ユーザープロンプト用フックを持つクライアントでは、ユーザーの判断や修正指示も記録する。PreCompactが発火すると、イベントから優先度別の2KB以下のXMLスナップショットを作り、session_resumeテーブルへ保存する。復元はSessionStartまたは代替フックが担う。保存状態を読み、イベントをFTS5へ索引化し、Session Guideと検索用の指示を会話へ注入する。記憶も全文を戻さず、小さな案内と検索で必要分を引く設計で、文書と履歴が同じ索引に乗る点が構成上の特徴だ。この復元経路を使えるかは、クライアントとバージョンに依存する。
3. 使いどころと限界
向く作業と、置き換える範囲
集計できる大量のログ、CSV、JSON、複数ファイルの調査では、コードで処理して結果だけをモデルへ渡せる。仕様書やAPI文書を索引化して原文を繰り返し引く作業や、フックが使えるクライアントでの長い実装にも適した構成と考えられる。置き換える対象は、Bash・Read・WebFetchで大量出力を会話へ渡す経路であり、基盤のCLIやファイルではない。会話圧縮は置き換えず、イベント保存と復元を足して補完する。逆に、全出力をモデルが逐一読む必要がある作業では、集計や検索で選別する利点を得にくい。ホストから厳密に隔離した任意コード実行環境をこのツール単体に求める運用や、Antigravity IDEやZedで強制的な経路制御と自動復元を必須にする運用も噛み合わない。
クライアント差:フックの有無が機能を分ける
「17プラットフォーム対応」は作者側の訴求である。READMEの対応表には18のクライアント列があり、IDEとCLI、gateway内のPi Agentと独立したPi Coding Agentが混在するため、本稿は数を断定しない。Antigravity IDEとZedにはフックがなく、経路選択を指示ファイルに頼り、イベント保存も復元もない。CursorとKiroはイベントを保存できるがSessionStart相当がなく、圧縮後の復元は未対応で、Antigravity CLIもフックが限られる。Codex CLIは機能フラグと信頼設定が必要で、PreToolUseの入力書き換えは未対応、PreCompactは実行時対応に依存する。MCPの応答だけではフックの稼働を確認できない。
実行権限・保存データ・通信の境界
ctx_executeとctx_batch_executeは任意コードを実行し、プロセスのファイルシステムアクセスを継承する。完全なOSサンドボックスではなく、ctx_execute_fileの境界検査を他の実行ツールへ一般化できない。gh、aws、gcloud、kubectl、dockerは環境変数と設定パスの引き継ぎで認証済みのまま使える。資格情報が実行プロセスへ渡るため、導入だけで最小権限の実行環境にはならず、deny規則は設定して初めて効く。保存面では、ユーザープロンプトやプロジェクト規則の内容も記録される。MCP引数の機密キーを正規表現で伏せるだけでは、保存内容全体の機密情報除去を保証できないと考えられる。URL取得はループバックとプライベートネットワークを既定で許可し、遮断にはCTX_FETCH_STRICT=1が要る。READMEは、テレメトリー、クラウド同期、利用追跡がなくすべてローカルと説明する。一方、v1.0.167〜169のリリースノートはInsight向けの利用量・コスト・削減量の転送を記す。有効化条件と送信先は資料から確定できない。
削減率の読み方
作者の報告では、セッション全体の生出力315KBが5.4KB(約98%削減)、Playwrightスナップショットが56.2KBから299B(表記は99%削減)、GitHub Issues 20件が58.9KBから1.1KB(表記は98%削減)になった。いずれも会話へ渡すデータ量の比較で、モデル、実行環境、入力、タスク精度は取得資料に記載がない。バイト数の削減は、総トークン費用やタスク精度の改善を独立に立証しない。v1.0.168〜169では、取得データ量の転送、削減率の表示、コスト帰属などの修正も報告された。READMEの数値が修正後の計測定義と一致するかは未確認である。
運用上の制約とライセンス
検索は1〜3回目がクエリごと2件、4〜8回目が1件、9回目以降は遮断されてctx_batch_executeへ誘導される。反復検索を中心にした作業では、利用経路を変える必要がある。LinuxはNode.js 22.5未満が非対応とされるが、古いglibc環境向けのネイティブビルド手順との適用関係は確認が要る。ライセンスはElastic License 2.0のsource-availableとREADMEが案内し、ホスト型・マネージドサービスとしての提供は制限される。LICENSE本文は取得しておらず、法的条件は別途確認したい。
このツールから考える
ここからは、一次情報と限界を踏まえた編集上の考察です。
観察できる仕組みは、データ処理と作業記憶をモデルの会話の外へ出し、小さな結果と検索で文脈へ戻す点にある。READMEに基づく範囲では、大量出力を会話へ渡す直接のBash・Read・WebFetchの経路を置き換え、会話圧縮にはイベント保存と復元を足して補完する構成である。これが定着すれば、コンテキスト管理は、モデルの内側の工夫から、周辺の実行基盤と記憶ストアの責務へ寄る可能性がある。その分、実行権限、保存データの扱い、フック対応の確認が、導入側の仕事になる。
条件と未知は多い。サブプロセスは完全なOSサンドボックスではなく、フックのないクライアントでは遮断も復元も指示ファイル頼みになる。削減率はバイト数の比較で、費用や精度の改善は立証されていない。READMEのテレメトリー説明とInsight向け転送の関係も、資料からは確定できない。取得できた最新リリースは2026-06-29公開のv1.0.169で、実装やテストは見ていない。今後は、精度を含む再現可能な評価、クライアント別の復元対応の広がり、保存データの保持と削除の範囲を確認したい。
検証に使用した一次情報
DevTool Lensでは、第三者の二次情報やREADMEの宣伝文句に依存せず、以下の公式リポジトリ・ドキュメント・リリース情報を精査して記事を作成しています。
- [readme]mksglu/context-mode README
- [repo]mksglu/context-mode GitHub Repository
- [release]mksglu/context-mode Releases
- [github_trending]GitHub Trending Daily (2026-10-02)