# Day 4：基幹統合を MCP ツールにする（約4分）

**ねらい：** 既存の基幹 API を、参照系と更新系に分けた MCP ツールとして公開する実装を見せる。冪等キーと Outbox の意味を伝える。
**映すもの：** `demo/agent-tools/` のコード、ターミナル（curl、テスト）。

| 時間 | 画面 | ナレーション | テロップ |
| --- | --- | --- | --- |
| 0:00 | タイトル画面 | 今日の結論です。MCP サーバーは、参照系と更新系で分けて作ります。それだけで、権限設計とゲートウェイのポリシーが一気に単純になります。 | Day 4：MCP ツール |
| 0:13 | ディレクトリ構成（demo/） | デモは Quarkus で作りました。基幹の模擬と、agent-tools という MCP サーバーです。agent-tools には Camel が入っていて、更新は統合層を通して基幹に届けます。 | Quarkus + MCP + Camel |
| 0:33 | `BankingReadTools.java` | 参照系のツールです。注目は @McpServer("banking-read")。このクラスのツールは /mcp/read にだけ公開されます。もう一つ、ツールの中で「その口座が本人のものか」を確認しています。ゲートウェイの認可だけでは、データ単位の確認はできないからです。 | データ単位の認可はツール側で |
| 1:00 | `BankingWriteTools.java` | 更新系は /mcp/write に分けました。振込依頼のツールは、冪等キーが必須です。同じキーで再送されたら、新しい振込は作らず、前回の結果を返します。 | 冪等キーは必須 |
| 1:16 | `TransferStateService.create` | 依頼を受けたら、依頼の記録と Outbox を同じトランザクションで書きます。Outbox は「基幹に送る予定のメモ」です。こうしておくと、アプリが途中で落ちても、送り忘れが起きません。 | 状態と送信予定を同時に確定 |
| 1:34 | ターミナル：curl で initialize と tools/list | 実際に呼んでみます。alice のトークンで /mcp/read に接続し、ツール一覧を取ると、参照系の4つだけが返ります。 | /mcp/read のツール一覧 |
| 2:02 | ターミナル：get_balance で他人の口座 | 他人の口座 ACC-101 を照会すると、「この口座は alice のものではない」と拒否されます。 | 他人の口座は拒否 |
| 2:27 | ターミナル：request_transfer を同じキーで2回 | 振込を同じ冪等キーで2回送ります。2回目は duplicate が true で、基幹の残高は1回分しか減っていません。 | 二重送金しない |
| 2:54 | ターミナル：`mvn test` の結果 | ガードレールの判定と監査のハッシュ連鎖は、単体テストも書いてあります。 | テスト4件成功 |
| 3:17 | 締め | 明日は、このツールの周りを、権限委任とガードレールで囲います。 | 次回：統制層 |

**収録メモ：** curl の手順は `docs/05_demo_runbook.md` と `demo/agent/demo_scenario.py` の場面1・2・4を参考にする。トークン文字列は画面に映さない（`$A` などの変数で隠す）。