CursorとClaude CodeがMCP経由でCodeGraphに接続しVueとSpring Bootの呼び出しを可視化

Cursor や Claude Code で API を変えると、バックエンドだけマージされフロントが古いまま——よくある話です。本記事は なぜ漏れるか、実例の捉え方、CodeGraph でどう直すか の3点だけ。Vue 3 + Spring Boot 分離リポに CodeGraph（MCP）を載せた検証です。

結論：OrderDTO.amount を変える前に codegraph_impact を実行すると、Java Service と Vue の createOrder、Pinia store を一度に列挙できます——Cursor が最も漏らす層です。

Cursor がフロントを漏らす理由

漏れは「モデルがコードを書けない」より、AI Coding がディレクトリ・言語をまたいだ参照を見えないことが多いです。Vue + Spring Boot では次の3つが典型です。

1. コンテキストウィンドウ：開いているファイルだけ

Cursor の @ ファイル、Claude Code の Read には上限があります。Agent は OrderController.java だけを見て、300行先の frontend/src/api/order.ts が同じ DTO フィールドを使っていることに気づきません。チャットやブランチを替えると「どこまで直したか」が消えやすく（Cursor の忘却とも重なります）。

2. grep：文字列は見つかるが呼び出しは分からない

探索は grep 依存がちです。amount 検索ではログ・テスト・未使用定数もヒットし、OrderService.createOrder の呼び出し元や @PostMapping の handler は分かりません。トークンは「入口探し」に消え、「影響範囲を直す」に回りません。

3. impact 分析がない：1箇所直して10箇所放置

人間は「このフィールドを変えたら誰が壊れる？」と聞きます。構造化された impact がないと、Agent は「Java 完了」で TypeScript・Pinia・テストを次のラウンドに回します——1回の会話で終わったつもりが、実は2回分の負債です。

必要なのは常に大きいモデルではなく、呼び出しグラフ・依存エッジ・ルート入口を引ける経路です。以下、注文 API の実例です。

実例：OrderDTO.amount

要件：POST /api/orders のリクエストボディで amount を number から string に（大口やフォーマット文字列向けなど）。リポは backend/（Controller → Service → OrderDTO）、frontend/（api/order.ts → Pinia → 注文画面）の分離構成です。

CodeGraph なし：Cursor / Claude Code が漏らしやすい箇所

業務説明だけ渡し、@ ファイルは指定しません。よくある結果：

  • ✅ OrderDTO.java、OrderService は更新
  • ❌ frontend/src/api/order.ts の createOrder payload 型
  • ❌ useOrderStore の amount マッピング
  • ❌ 注文画面の v-model が数値検証のまま

mvn compile は通ることも、pnpm build も通ることもあります——マージ後の結合や本番で初めて壊れる。これが「API は直したがフロントを忘れた」です。

対照：impact の波及リスト（抜粋）

codegraph_impact
  symbol: "OrderDTO.amount"

→ OrderService.createOrder
→ OrderController.create
→ frontend/src/api/order.ts :: createOrder
→ stores/order.ts :: useOrderStore

最後の行は grep で最も漏れやすい Pinia です。リストに沿って Cursor / Claude Code で直すと漏れは減ります。

CodeGraph で問題を見つける

CodeGraph は Tree-sitter で Java / TS / Vue script を索引し、呼び出し辺を .codegraph/ に保存、MCP で codegraph_* を公開します。データは基本ローカルで、社内リポ向きです。

この注文 API では次の順序を固定しています：

  1. codegraph_context — Controller・DTO・フロント API 入口をタスク単位で（パスを @ しなくてよい）
  2. codegraph_trace — Spring：OrderController.create → OrderMapper.insert
  3. codegraph_impact — OrderDTO.amount から Java + Vue + store へ
  4. codegraph_explore — 関連メソッドだけ（800行 Service を丸ごと入れない）

HTTP パスと axios 文字列に symbol 辺がなくても、DTO からの impact でフロントに届く——本ケースで「想定以上」だった点です。ツール比較は コード知識グラフの選び方；インストールは下記。

AGENTS.md に DTO 変更前に必ず codegraph_impact、frontend/src/api と Pinia を列挙 と書くと、「フロント忘れないで」より確実です。

インストール（約5分）

frontend/ + backend/ があるリポルート（macOS）：

curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh | sh
# または: npx @colbymchenry/codegraph

codegraph install --target=cursor --yes   # Claude Code は対応 target
cd /path/to/your-repo
codegraph init -i
codegraph status

初回全量索引は規模により10〜20分程度。node_modules、target、dist は除外。保存後約2秒で増分同期；MCP が ⚠️ Pending sync なら Agent にソース Read を促します。

結果比較

方式ツール呼び出し（同タスク・体感）フロントはリストに？
grep + Read のみ約 15+ 回Pinia / API を漏らしがち
CodeGraph MCP 先行約 5〜6 回impact で前後端を一括

公式 Java ベンチ（OkHttp ~645 ファイル）中央値 10→3（2026-05-29）。Vue + Spring でも探索は半分以下に感じました。グラフはテストの代わりではありません——mvn test + pnpm test:unit はマージ前に。

大規模リポの索引先

初回 codegraph index は CPU 高負荷・SQLite 書き込み・ファン全開——IDEA で Spring、pnpm build で Vue を同時に回すと Cursor の MCP も重くなります。

クローン＋全量索引＋定期再構築を Mac mini、CI、Cloud Mac に置き、ノート PC は編集と MCP のみ——私は日割りの Macstripe M4 で索引し、ローカルビルドとずらしています。worktree は 企業 Mac CI FAQ。

「Cloud Mac + CodeGraph デプロイ」は別記事向き——ここでは索引と対話を分けると安定する、まで。

まとめ

API 変更で Cursor がフロントを漏らす のは、コンテキスト不足 + grep は呼び出しを理解しない + impact がない ことが多いです。Vue + Spring Boot では CodeGraph MCP の context → trace → impact で DTO 変更の前後端リストを一度に揃え、探索は十数回の grep から数回の構造化クエリへ。

固定フロー：init → impact（DTO 前）→ リストに沿って修正 → テスト。概念記事・巨大リポの Claude Code・Cloud Mac 展開はシリーズ化——下の関連記事へ。

関連記事