# エージェント接続レディネス診断レポート：サンプル銀行（架空）

2026-10-20 · 診断者 リードアーキテクト

## 1. 結論

7つの統制のうち **6つ** が、対象業務（最も高いリスク区分：金銭・個人情報が絡む）の本番に必要なレベルに届いていません。うち **6つ** は本番の最低ライン L3 を下回っており、更新系の業務を本番に出す前に解消が必要です。

![成熟度とギャップ](report/maturity-gap.png)

## 2. 統制ごとの評価

| 統制 | 現状 | 平均 | 必要 | 差 | 最も弱い質問 |
| --- | --- | --- | --- | --- | --- |
| 1 Identity | L2 | 2.7 | L3 | -1 | ID-1 エージェントは、どの資格情報で業務システムにアクセスしていますか。 |
| 2 Authorization | L2 | 2.2 | L3 | -1 | AZ-1 エージェントが使えるツールは、どの単位で許可していますか。 |
| 3 Guardrails | L1 | 2.0 | L3 | -2 | GR-3 検出のしきい値を、実績に基づいて調整していますか。 |
| 4 Blast Radius | L1 | 2.0 | L3 | -2 | BR-4 暴走時の最大影響（金額、件数）を説明できますか。 |
| 5 Transactional Safety | L3 | 3.5 | L3 | ±0 | TS-1 更新系のツールは冪等ですか（同じ依頼を二度受けても1回分しか動かない）。 |
| 6 Observability | L1 | 1.8 | L4 | -3 | OB-1 エージェントの1回の依頼を、どこまで一本のトレースで追えますか。 |
| 7 Audit & Traceability | L2 | 2.3 | L4 | -2 | AU-1 監査証跡には何が記録されますか。 |

## 3. 接続候補とリスク区分

| 業務 | 使うシステム | 操作 | リスク区分 | 必要な水準を満たすか |
| --- | --- | --- | --- | --- |
| 残高・明細の照会 | 勘定系 照会 API | 参照 | 参照のみ | 満たさない |
| 振込の受付 | 勘定系 振込 API（MQ 経由） | 更新 | 金銭・個人情報が絡む | 満たさない |
| 住所変更の受付 | CIF 管理システム | 更新 | 金銭・個人情報が絡む | 満たさない |
| 店舗の予約 | 予約システム（SaaS） | 更新 | 更新あり | 満たさない |

## 4. ロードマップ

### フェーズ1：本番の最低ライン（L3）に届かせる

- [ ] **統制1 Identity**：エージェント用クライアントを分け、利用者のトークンを交換（RFC 8693）して委任トークンを発行する
- [ ] **統制2 Authorization**：MCP サーバーを参照系と更新系に分け、ゲートウェイの AuthPolicy で経路ごとに役割を確認する。ツール側で所有者を確認する
- [ ] **統制3 Guardrails**：ツールの入力ガードレール（注入・個人情報）と、出力のマスキングを入れる
- [ ] **統制4 Blast Radius**：経路ごとの RateLimitPolicy、推論経路の TokenRateLimitPolicy、高額操作の承認 API、停止手順を整える
- [ ] **統制6 Observability**：エージェント・ツール・統合・基幹に OpenTelemetry を入れ、traceparent を MCP 呼び出しに伝播する。指標のダッシュボードと評価セットを作る
- [ ] **統制7 Audit & Traceability**：監査証跡のスキーマを決め、トレース ID を付けて追記専用で保管する

### フェーズ2：金銭・個人情報を扱う業務に必要な水準（L4）に届かせる

- [ ] **統制6 Observability**：SLO とアラートを定義し、障害対応の訓練で原因特定までの時間を測る。評価を CI に組み込む
- [ ] **統制7 Audit & Traceability**：ハッシュ連鎖の検証を定期実行し、監査部門向けの検索画面とレポートを用意する

## 5. 推奨する次の一手

M1 では「振込の受付」を対象に、委任トークン（統制1）、ツール単位の認可（統制2）、 全層のトレース（統制6）と監査証跡（統制7）を実装します。統制5は既存の振込基盤の Outbox と Saga を そのまま使えるため、PoC の工数を抑えられます。

## 付録：採点の根拠

| ID | 採点 | 証跡・メモ |
| --- | --- | --- |
| ID-1 | L2 | PoC のエージェントは共通のサービスアカウント（全店舗分の照会権限）で勘定系 API を呼んでいる |
| ID-2 | L3 |  |
| ID-3 | L3 |  |
| AZ-1 | L2 | ゲートウェイは API キーの有無のみ確認。ツール単位の制御なし |
| AZ-2 | L2 |  |
| AZ-3 | L3 |  |
| AZ-4 | L2 | エージェントのアカウントに業務端末と同じロールが付いている |
| GR-1 | L2 |  |
| GR-2 | L3 |  |
| GR-3 | L1 | 遮断の記録なし |
| GR-4 | L2 |  |
| BR-1 | L2 |  |
| BR-2 | L3 |  |
| BR-3 | L2 |  |
| BR-4 | L1 | 最大影響の試算なし。リスク管理部門から本番化の条件として要求されている |
| TS-1 | L3 |  |
| TS-2 | L4 | 既存の振込基盤で Saga と補償を運用中（統合基盤の資産を流用できる） |
| TS-3 | L4 | 既存の振込基盤で Outbox を運用中 |
| TS-4 | L3 |  |
| OB-1 | L1 | LLM の入出力ログのみ。ツールと勘定系の呼び出しをつなげない |
| OB-2 | L2 |  |
| OB-3 | L2 |  |
| OB-4 | L2 |  |
| OB-5 | L2 |  |
| AU-1 | L2 | 「誰の指示か」が記録されない（サービスアカウント名のみ） |
| AU-2 | L3 |  |
| AU-3 | L2 |  |