vlm-code-context-mcp

本格的なAIエンジニアリングチーム。npmパッケージ1つ。コンテキストの無駄はゼロ。

📖 スタートガイド — 初めての方はこちらから！

プロダクトオーナー。アーキテクト。QA。セキュリティ。2人の開発者。スクラムマスター。マネージャー。リード開発者。 すべてが実際の開発スプリントを実行し、あなたのコードベースと対話し、単一のSQLiteデータベース内で完結します。

npm install vlm-code-context-mcp
npx code-context-mcp setup .
npx code-context-dashboard ./context.db

なぜこのツールが存在するのか

すべてのAIコーディングツールは同じ壁に突き当たります。モデルは、何か有用なことをする前に、コードベースを「読む」だけでコンテキストウィンドウを使い果たしてしまうのです。そしてセッションが終了し、次回はまた最初からやり直しになります。

2つ目の問題はさらに深刻です。プロセスが存在しないことです。有能なAIを手に入れても、何を、どの順番で、なぜ構築すべきかを知る術がありません。

vlm-code-context-mcp はその両方を解決します。プロジェクト全体を構造化されたSQLiteデータベースに事前インデックス化することで、エージェントは生のソースコードではなくメタデータをクエリします。これにより、224ファイルのコードベースにおいて、トークン消費量を25分の1、データ量を26分の1に削減します。さらに、このインテリジェンスを、81個のMCPツールを通じて実際のスクラム儀式（フェーズゲート、レトロスペクティブ、ベロシティ追跡、ライブReactダッシュボードなど）を実行する完全な仮想スクラムチームで包み込みます。

これはClaudeを付け足しただけのタスクトラッカーではありません。AI駆動開発のためのオペレーティングシステムです。

60秒で得られるもの

Step 1/4 — Indexing files into context.db...
  Indexed 25 files, 142 exports, 87 dependencies

Step 2/4 — Loading scrum schema...
  Created 10 scrum tables

Step 3/4 — Importing team from .claude/agents/...
  Loaded 9 agents, 3 sprints, 24 tickets

Step 4/4 — Writing .mcp.json...
  Configured MCP server entry

=== Setup complete! (my-project) ===

次にダッシュボードを開きます：

npx code-context-dashboard ./context.db
# Opens at http://localhost:3333

これだけです。 あなたのAIチームの準備は完了です。APIキーも、外部サービスも、クラウドへの依存もありません。すべてが context.db 内に存在します。

チーム構成

各エージェントには定義された役割、システムプロンプト、責任範囲に限定されたツールアクセス権があり、チケット負荷とレトロスペクティブの感情から導き出されたムードスコアが設定されています。システムはスプリント全体を通して燃え尽き症候群の兆候を追跡します。

スプリントプロセス

スプリントは、自動化されたゲートチェックを備えた10の強制フェーズを通じて実行されます：

preparation → kickoff → planning → implementation → qa → refactoring → retro → review → closed → rest

ゲートは本物です。チケットが割り当てられ、見積もられるまでスプリントはQAに進みません。レトロスペクティブの結果が記録されるまでスプリントは終了しません。ベロシティはすべてのスプリントで自動的に追跡され、ダッシュボードに表示されます。

ダッシュボード

6ページ。68コンポーネント。ライブSSE更新。

チケットのステータス変更、エージェントのムード更新、スプリントフェーズの移行など、あらゆる変更がSQLite WAL監視を通じてダッシュボードの即時更新をトリガーします。ポーリングも手動更新も不要です。

• スプリントボード — カンバン、計画ビュー、QAゲートトラッカー、バーンダウンチャート

• コードエクスプローラー — ファイルツリー、依存関係グラフ、エクスポート/インポートマップ、変更履歴

• プロジェクト管理 — ガントタイムライン、マイルストーントラッカー、ディスカバリーパイプライン、ビジョンエディター

• チーム — エージェントのヘルスカード、ムードトレンド、ワークロード分布

• レトロスペクティブ — カテゴリ別の調査結果、スプリント間のパターン分析、アクション追跡

• マーケティング — リリースノート、ポジショニング、Remotionビジョンアニメーション

📸 [スクリーンショット]
📸 [スクリーンショット]

ブリッジレイヤー

エージェントツールにおける最も困難な問題は双方向通信です。UIとAIがリアルタイムで実際に会話できるようにすることです。

src/bridge/ は、Claude Codeをダッシュボードに接続する PreToolUse フックを実装しています。UIでキューに入れられたアクションは、実行中のClaude Codeセッションによって処理されます。これが、チームを静的なボードではなく、生きているかのように感じさせる要素です。

現在も強化中です。PRを歓迎します。

コンテキストの効率性

このプロジェクト自身のコードベース（224ファイル、54K行、2.1 MB）で測定：

手法：「機能を理解して修正する」タスク — 関連ファイルの特定、エクスポート/インポート/依存先の理解、最近の変更の確認。MCPなしの場合、エージェントは約20個の生ファイル（平均9,200文字）を読み取ります。MCPありの場合、search_files、find_symbol、get_file_context を通じて構造化されたメタデータをクエリします。生のソースコードではなく、要約、エクスポートリスト、依存関係グラフを取得します。

最初のインデックス作成にはコストがかかります（メタデータを生成するためにファイルを読み取る必要があるため）。それ以降のクエリはすべて25倍安くなります。1回の使用で元が取れます。節約効果はコードベースのサイズに応じて拡大します。25ファイルのプロジェクトでは3倍の削減、この224ファイルのプロジェクトでは25倍の削減が見られます。

概要

プロジェクトの歴史

すべて独自のスクラムプロセスを通じて構築されました。仮想チームは、22のマイルストーン、69の生産的なスプリント、211のチケットを完了し、合計534ストーリーポイント、スプリントあたり約20ポイントのローリングベロシティを達成しました。

19スプリントにわたるレトロスペクティブの調査結果

うまくいったこと（主要パターン）：

• ディスカバリーファーストのアプローチにより、無駄な実装が一貫して排除されました。コードを書く前に3〜4つのアプローチをスパイクすることで、数日間の手戻りを防ぎました（S59, S65, S68）。

• 並列エージェント実行により、実装時間が劇的に短縮されました。メインスレッドが調整を行う間、4人のエージェントが独立したチケットを同時に処理しました（S59, S65, S67）。

• コードを書く前の調査により、行き止まりを早期に発見できました。S68では、3つの候補となるブリッジアプローチ（名前付きパイプ、Unixソケット、MCPリソースサブスクリプション）を数日ではなく数時間で排除しました。

• スキーマ移行パターン（schema_versionsテーブル）により、段階的なDB変更が安全かつ再現可能になりました。7回のスキーマ追加を通じてリグレッションはゼロでした（S53, S55）。

• 並列でのセキュリティ監査により、コードが出荷される前に2つのHIGHレベルの脆弱性を発見しました（S68）。実装後に監査するのではなく、実装と並行して監査を行うのが正しいパターンです。

うまくいかなかったこと（主要パターン）：

• テストを実行せずにDONEとマークされたテスト。 エージェントはテストを書きましたが実行できませんでした。DONEとマークする前にビルド検証が必要です（S61, S65, S66）。

• 既存のテスト失敗がノイズとなり、実際のリグレッションを隠していました。古いスキーマ変更による古いテストが表面化し続けました（S53, S67, S68）。

• ディスカバリーのベロシティが誤解を招きました。 S56では46spがコミットされましたが、すべてのチケットがドキュメントのみでした。ディスカバリーポイントは実装とは別に追跡すべきです。

• 説明や受け入れ基準のない一般的なチケットタイトルにより、QAが不可能になりました。すべてのチケットには具体的なスコープが必要です（S53）。

• フロントエンドの技術的負債が蓄積 — 800行以上のコンポーネント、850以上のインラインスタイル、テストゼロ。これらには早期に対処すべきでした（S59）。

• ブリッジはClaudeが積極的にツール呼び出しを行っている時のみ機能します。 キューに入れられたアクションのためにClaudeを起こす「ナッジ」メカニズムがありません（S68）。

次に試すこと（主要なアクションアイテム）：

• 各エージェントが完了した後、チケットをDONEとマークする前に npm run build を実行する（S65, S66, S67）。

• 作成時にすべてのチケットに受け入れ基準を追加する（S55）。

• 修正チケットを作成する前に現在の状態を確認する（すでに解決済みのものがあったため）（S58）。

• 新しいwrite-MCP-toolを作成するたびにSSE通知をトリガーするようにする（チェックリスト項目に追加）（S53）。

• APIが安定したら、真のプッシュベースのブリッジ信号のためにチャンネルを実装する（S68）。

• ディスカバリーポイントを実装ベロシティとは別に追跡する（S56）。