Context Fabric について
Context Fabricは、複数セッションにまたがるAIコーディングプロジェクト向けのローカルなコンテキスト同期MCPサーバーです。Gitコミットから状態を記録し、コンテキストのドリフトを検出して、関連度とトークン予算に基づくブリーフィングを作成します。
主な機能
- 01Gitコミット後のプロジェクト状態の記録
- 02ファイル変更とコンテキストドリフトの検出
- 03クエリとの関連度によるコンポーネント検索
- 04トークン予算に応じたコンテキスト選択
- 05構造化されたタスクブリーフィングの生成
- 06アーキテクチャ決定の記録とローカル状態の確認
活用シーン
- 01新しいコーディングセッション用のプロジェクト概要作成
- 02プロジェクトコンテキストの古さの確認
- 03エージェントに渡すコンテキストのトークン制限
- 04セッションをまたいだアーキテクチャ決定の保持
MCP 対応
cf_capture、cf_drift、cf_query、cf_health、cf_log_decisionなどのツールを提供し、コーディングエージェント向けのローカルなプロジェクトコンテキストを記録・検索・管理します。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
Context Fabric
現在の安定版リリース：v1.2.2。リリースノートについてはCHANGELOG.mdをご覧ください。
公式レジストリのサポート
Context Fabric は、Model Context Protocol（MCP）レジストリへの公式登録に対応するよう設定されています。
- 名前空間：
io.github.VIKAS9793/context-fabric - メタデータ：server.json
- 配布：公式の MCP レジストリメタデータを含む npm パッケージとして公開されています。
AI コーディングエージェント向けのコンテキスト同期レイヤーです。あらゆるコーディングセッションで、プロジェクトの継続性を確保し、エージェントのメモリのドリフトを解消し、トークン予算を自動的に管理します。
Context Fabric は、すべての git コミットでプロジェクトの状態を自動的に記録し、保存されたコンテキストがコードベースの実態から乖離したことを検出して、構造化されトークン予算に配慮したブリーフィングを AI エージェントに提供する MCP サーバーです。開発者による操作は必要ありません。
課題
AI コーディングエージェントを使う開発者は、プロジェクト継続性を支える標準機能がないため、その不足を補うドキュメントシステム、セッション引き継ぎの手順、コンテキストのワークフローを手作業で作成・維持しています。こうした回避策には共通点があります。コミット後に内容が古くなり、それを検出する仕組みがないことです。
問題は、AI が忘れることではありません。問題はコンテキストのドリフトです。コードが変更されると保存されたコンテキストが不正確になり、AI エージェントはその誤ったコンテキストを確信を持って前提に作業を進めてしまいます。
Context Fabric は、この問題を根本から解決するインフラストラクチャレイヤーです。
CADRE — Context-Aware Drift Resolution Engine
Context Fabric は、5つのエンジンからなる内部アーキテクチャ CADRE を基盤としています。各エンジンは、実際の開発ワークフローで確認された、具体的に記録された障害モードを解決します。
CADRE とは。 CADRE は、開発者が現在自ら構築している手作業のコンテキスト管理システムを、すべて自動化によって置き換えるものです。git イベントストリームと AI エージェントの間に位置し、何のコンテキストをいつ記録するか、いつドリフトしたか、現在のクエリにどの部分が関連するか、それらにどれだけのトークンが必要か、そしてどのように構造化して確実に提供するかを判断します。
CADRE の対象者。 複数のセッションにまたがる AI 支援ソフトウェアプロジェクトを開発していて、現在、次のいずれかに時間を費やしている開発者です。コミット後の Markdown ファイルの更新、セッション終了時の要約作成、CLAUDE.md または AGENTS.md ファイルの維持、プロジェクトコンテキスト用の RAG パイプライン構築、各タスクの前に読み込むドキュメントの手作業での選定。
5つのエンジン
E1 — WATCHER
context-fabric init の実行時に、git の post-commit フックをインストールします。コミットのたびに自動的に実行されます。変更可能な作業ツリーではなく、コミット済みの Git blob を読み取り、SHA256 フィンガープリントを計算し、エクスポートされたシンボルを抽出して、トークン数を推定したうえで、すべての情報をローカルの SQLite ストアに upsert します。セットアップ後、開発者が行う作業はありません。
置き換えるもの：コミットごとの Markdown 作成ワークフロー、5ステップのセッション習慣、セッション前に構造化されたプロジェクト知識を抽出するための AI インタビューワークフロー。
E2 — ANCHOR
cf_query を呼び出すたびに、保存済みの SHA256 ハッシュと、追跡対象ファイルすべての現在の状態を比較します。ドリフトスコア（0～100）と重大度分類（LOW（10%未満）、MED（10～30%）、HIGH（30%超））を含む DriftReport を返します。古くなったファイルは、パスとハッシュの差分で特定されます。
置き換えるもの：手動でのドキュメント整合性レビューと、ETH Zurich の研究（arXiv:2602.11988）が AI コーディングのパフォーマンスを低下させると実証した、AGENTS.md の検出されない古さ。
E3 — ROUTER
cf_query のクエリテキストを使って、保存済みのコンポーネントインデックスに対して SQLite FTS5 BM25 を実行します。関連度順に並べたコンポーネントを返します。ファイルパスはコードベースの構成に関する構造的な意味を持つため、パスの一致にはエクスポートシンボルの一致の2倍の重みを付けます。クエリで MATCH の結果が得られない場合は、更新日時順にフォールバックします。
置き換えるもの：タスクごとに含めるドキュメントを手動で選択する作業と、プロジェクトが複数のファイルに知識を分散させることで生じる、モジュール化されたコンテキスト選択の問題。
E4 — GOVERNOR
関連度順のリストから貪欲法で選択し、E3 のランク付け結果に設定可能なトークン予算の上限を適用します。デフォルトはモデルのコンテキストウィンドウの8%で、会話とコード用に92%を残します。サイズ超過のコンポーネントはスキップされるため、残りの予算を後順位の一致結果に利用できます。E1 があらかじめトークン数を推定するため、予算選択時にファイルを追加で読み取る必要はありません。
置き換えるもの：手動でのトークン管理と、再起動後にコンテキストを復元するコストを避けるため、セッションをいつまでも維持するパターン。
E5 — WEAVER
E3 と E4 の出力から、構造化された Markdown のブリーフィングを作成します。セクションは、Project State、Architecture、Architecture Decisions、Budget Summary です。E2 の重大度が MED または HIGH の場合は、ほかのすべての内容より前に Drift Warning セクションを追加し、AI がコンテキストを読む前にその信頼性を把握できるようにします。
置き換えるもの：更新されない静的な AGENTS.md のブリーフィングと、開発者がセッション開始のたびに手動で行うブリーフィングの準備。
データフロー
git commit
|
v
E1 WATCHER --- SHA256 fingerprint --- SQLite upsert --- FTS5 index update
|
cf_query("...")
|
v
E2 ANCHOR --- drift check --- DriftReport
|
v
E3 ROUTER --- FTS5 BM25 --- ranked component list
|
v
E4 GOVERNOR --- greedy selection --- budget-capped set
|
v
E5 WEAVER --- briefing composition --- MCP response
クイックスタート
npx context-fabric init
SQLite ストアを初期化し、git の post-commit フックをインストールして、安定したローカルランタイムを .context-fabric/runtime にステージし、初回のキャプチャを実行します。MCP サーバーをツールに接続すると、次のコミットからコンテキストが提供されます。
インストールとセットアップ
-
プロジェクトを初期化する： git で管理されている任意のリポジトリに移動し、次を実行します。
npx context-fabric init -
AI 環境を設定する（Cursor／VS Code／Windsurf）： MCP 設定ファイルに次の内容を追加します。
Windows ユーザー（重要）：
{ "mcpServers": { "context-fabric": { "command": "cmd", "args": ["/c", "npx", "context-fabric"] } } }Mac／Linux ユーザー：
{ "mcpServers": { "context-fabric": { "command": "npx", "args": ["-y", "context-fabric"] } } }
ヘルスチェックと修復
ローカルインストールの検証や、フック／ランタイムの状態が壊れた場合の復旧には、ヘルスチェックコマンドを使用します。
npx context-fabric doctor
npx context-fabric doctor --repair
doctor は、スキーマのバージョン、検索インデックスのバージョン、DB の整合性、縮退モード、保留中および失敗したキャプチャ、フックランタイムの準備状況を報告します。doctor --repair はローカルランタイムのバンドルを更新し、安定したフックラッパーを再インストールして、.gitignore を検証します。また、データベースが正常な場合は検索インデックスを再構築します。
トラブルシューティング
spawn npx ENOENT エラー
通常、IDE が継承するシステムのパスに npx が含まれていないことを意味します。
- 対処方法：
nodeとcontext-fabricバイナリの絶対パスを使用します。 - パスを調べるには、Windows では
where node、Mac／Linux ではwhich nodeを使用します。 - NVM／FNM ユーザー向けの例：
"command": "/Users/name/.nvm/versions/node/v22.14.0/bin/node", "args": ["/Users/name/.nvm/versions/node/v22.14.0/bin/context-fabric"]
WSL ユーザー
Windows で VS Code を実行し、コードが WSL 内にある場合は、必ず WSL ターミナル内で init を実行し、設定では node の WSL 絶対パスを使用してください。
プロジェクトパス内のスペース
Windows では、プロジェクトパスにスペースが含まれていると（例：C:\My Projects\app）、npx の起動に失敗することがあります。サーバーが起動しない場合は、スペースを含まないパスにプロジェクトを移動してください。
フィードバックと報告
問題が発生した場合は、次を実行してください：
npx context-fabric doctor
互換性エイリアスとして、引き続き npx context-fabric diag を利用できます。
FAQ
Context Fabric はコードをサーバーに送信しますか？ いいえ。ローカルのみで動作し、キャプチャ、検索、ドリフト分析のために外部ネットワークへ接続することはありません。
コミットしていない変更もインデックス化されますか？ いいえ。キャプチャされる状態は、コミット済みの Git オブジェクトに基づきます。コミットしていない変更はドリフトチェックで検出されますが、コミットしてキャプチャするまでは、新たな信頼できる情報源としてインデックス化されません。
AGENTS.md、CLAUDE.md、または人間向けドキュメントの代わりになりますか？
手動のセッション引き継ぎドキュメントの必要性は減らせますが、製品仕様書、オンボーディングガイド、関係者向けドキュメントの代わりにはなりません。
ローカルにはどのファイルが書き込まれますか？
データベースとランタイムバンドルは .context-fabric/ の下に書き込まれます。また、キャプチャを自動化するために .git/hooks/post-commit がインストールされます。
どのような場合に使用すべきではありませんか？ クラウド同期、リポジトリをまたいだ検索、実装本文の完全なセマンティックインデックス化、または MCP ツールによるプロジェクトファイルの変更が必要な場合は、Context Fabric を使用しないでください。
インストールが壊れた場合、どうすれば復旧できますか？
まず npx context-fabric doctor を実行してください。フックのランタイムやローカルの状態を修復する必要がある場合は、npx context-fabric doctor --repair を実行してください。
FAQ 全文：docs/FAQ.md
MCP ツール
| ツール | エンジン | 目的 |
|---|---|---|
cf_capture | E1 | git のコミット外で手動でコンテキストをキャプチャ |
cf_drift | E2 | 単独のドリフトチェック — 重大度と古くなったファイル数を返す |
cf_query | E2 + E3 + E4 + E5 | 現在のタスクに関するコンテキストの概要 |
cf_health | ローカルの健全性 | データベース、キャプチャ、フック、検索インデックスの健全性を報告 |
cf_log_decision | ストレージ | アーキテクチャ上の決定をセッションをまたいで保存 |
すべてのツールは、MCP annotations（readOnlyHint、destructiveHint、idempotentHint、openWorldHint）を公開します（1.1.0 時点）。cf_capture、cf_drift、cf_health、cf_log_decision は、テキスト出力に加えて structuredContent も返します。cf_query は、データ構造ではなくエージェントのコンテキストウィンドウに注入するための文章を出力するため、意図的に structuredContent を返しません。なお、cf_query は読み取り専用ではありません。HEAD がまだインデックス化されていない場合、内部でキャプチャを実行することがあります。
技術スタック
| レイヤー | パッケージ | バージョン |
|---|---|---|
| MCP プロトコル | @modelcontextprotocol/sdk | 1.29.0 |
| ストレージと検索 | better-sqlite3 + FTS5 | 12.8.0 |
| スキーマ検証 | zod | ^4.3.6 |
| 言語 | TypeScript | 5.5+ |
| ランタイム | Node.js | >=22.0.0 <25.0.0 |
| トランスポート | stdio（フェーズ 1） | MCP SDK 組み込み |
セキュリティ
| アクセスの種類 | 範囲 |
|---|---|
| ファイルシステムの読み取り | プロジェクトルートのみ — パストラバーサルは拒否 |
| ファイルシステムへの書き込み | .context-fabric/cf.db、.context-fabric/runtime/**、.context-fabric/bin/post-commit、および .git/hooks/post-commit |
| ネットワーク | なし — 外部接続は一切なく、テレメトリもありません |
| プロジェクトファイルへの書き込み | なし — ツール呼び出しでプロジェクトファイルに書き込むことはありません |
脆弱性の開示手順については、SECURITY.md を参照してください。
要件
- Node.js
>=22.0.0および<25.0.0 - git リポジトリ
- MCP 互換の AI コーディングツール
コントリビューション
プルリクエストを作成する前に、CONTRIBUTING.md をお読みください。
プロジェクトのドキュメント
👥 プロジェクトチーム
- VIKAS SAHANI — プロダクトリード / HITL / エージェントオーケストレーター
- Antigravity — AI エージェント / コードアーキテクト
🔬 研究およびデータに関する免責事項
このプロジェクトは、AI ネイティブな開発ワークフローとコンテキストを考慮したドリフト解決に関する継続的な研究の一環です。
- 公開データ：公開セッション中に生成されたスニペット、ログ、指標は、研究および検証の目的で使用される場合があります。
- プライバシー：個人データや独自のコードベースロジックは、明示的に共有されない限り、ローカルの
.context-fabricディレクトリの外部に保存されません。
ライセンス
MIT — LICENSEを参照してください。
VIKAS SAHANIが開発しました。
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。