# 動画台本（Day 7）

# Day 7：診断を「型」にする：アセスメントキット（約3分）

**ねらい：** M0 診断を、人によってぶれない手順と道具にしたことを見せる。
**映すもの：** `assessment-kit/maturity-model.yaml`、`questionnaire.md`、`scoring-sheet.xlsx`、`sample/report.md` と図。

| 時間 | 画面 | ナレーション | テロップ |
| --- | --- | --- | --- |
| 0:00 | タイトル画面 | 今日の結論です。診断の品質は、担当者の経験に頼ると毎回ぶれます。質問と採点基準とレポートを、一つの正本から作るようにしました。 | Day 7：アセスメントキット |
| 0:12 | `maturity-model.yaml` | 正本はこの YAML です。7つの統制に27の質問。質問ごとに、L3 と L4 の基準と、確認する証跡を書いています。リスク区分ごとに、本番で必要なレベルも決めています。 | 正本は1つ |
| 0:29 | `questionnaire.md` | ここから質問票を生成します。ヒアリングでは、この表を上から聞いていきます。証跡で確認できない回答は、1段階下げて採点します。 | 証跡がなければ1段下げる |
| 0:42 | Excel の採点シート（サマリーシート） | 採点シートも生成します。点数を入れると、サマリーで統制ごとのレベルと、必要なレベルとの差が自動で出ます。足りないところは赤くなります。 | 差が自動で出る |
| 1:10 | ターミナル：`kit.py report sample/answers-sample.yaml` | 回答の YAML から、診断レポートを自動で作ります。これは架空の「サンプル銀行」の例です。 | 架空の診断例 |
| 1:34 | `sample/report.md` の図と結論 | 結論は「7つのうち6つが本番に必要なレベルに届いていない」。図の青い点が現状、縦線が必要なレベルです。一番差が大きいのは可観測性。ただし Transactional Safety は既存の振込基盤の Outbox と Saga がそのまま使えるので、すでに足りています。 | 既存資産が効く統制もある |
| 2:01 | レポートのロードマップ節 | ロードマップは、まず L3 に届かせるフェーズ1、次に金銭や個人情報を扱う業務に必要な L4 へのフェーズ2。そのまま M1 の提案につながります。 | 診断がそのまま次の提案に |
| 2:16 | 締め | 明日は、この中身を顧客向けの提案書にまとめます。 | 次回：提案書 |


---

# 参考資料：README.md

# M0 アセスメントキット

M0 診断（エージェント接続レディネス診断）で使う道具一式です。正本は `maturity-model.yaml` で、ほかのファイルはそこから生成します。

| ファイル | 用途 |
| --- | --- |
| `maturity-model.yaml` | 7統制・27問・5段階の成熟度モデル、リスク区分ごとの必要レベル、改善策 |
| `questionnaire.md` | ヒアリング用の質問票（生成物） |
| `scoring-sheet.xlsx` | 採点シート。採点・サマリー（自動計算）・接続候補の3シート（生成物） |
| `kit.py` | 生成と採点のスクリプト |
| `sample/answers-sample.yaml` | 架空の診断例（サンプル銀行） |
| `sample/report.md` | 上の回答から自動生成した診断レポート（図つき） |

```bash
cd assessment-kit && ../.venv/bin/python kit.py build
```

```bash
cd assessment-kit && ../.venv/bin/python kit.py report sample/answers-sample.yaml
```

採点の原則は2つです。統制のレベルは、その統制で最も低い質問のレベルとします。証跡で確認できない回答は、1段階下げて採点します。


---

# 参考資料：questionnaire.md

# M0 ヒアリング質問票（7統制）

各質問を L1〜L5 で採点します。L3 が本番の最低ラインです。証跡で確認できない回答は、1段階下げて採点します。統制のレベルは、その統制で最も低い質問のレベルです。

| レベル | 意味 |
| --- | --- |
| L1 | 場当たり |
| L2 | 個別対応 |
| L3 | 標準化（本番の最低ライン） |
| L4 | 計測と自動化 |
| L5 | 継続的な改善 |

## 接続候補のリスク区分と、本番で必要なレベル

| 区分 | 1 Identity | 2 Authorization | 3 Guardrails | 4 Blast Radius | 5 Transactional Safety | 6 Observability | 7 Audit & Traceability |
| --- | --- | --- | --- | --- | --- | --- | --- |
| 参照のみ | L3 | L3 | L2 | L2 | L2 | L3 | L3 |
| 更新あり | L3 | L3 | L3 | L3 | L3 | L3 | L3 |
| 金銭・個人情報が絡む | L3 | L3 | L3 | L3 | L3 | L4 | L4 |

## 統制1 Identity：エージェントの身元を定め、利用者からの権限委任を扱う

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| ID-1 | エージェントは、どの資格情報で業務システムにアクセスしていますか。 | 利用者からの権限委任（OBO）のトークンで、誰の権限で動いたかが呼び出しごとに分かる | 委任トークンは短命で、対象（aud）が業務ツールに限定されている | トークンの中身（sub、azp、aud）、IdP のクライアント設定 |
| ID-2 | エージェント（クライアント）は台帳で管理されていますか。 | エージェントごとにクライアントが登録され、所管部署と用途が台帳にある | 登録・廃止が申請フローで管理され、使われていないクライアントを定期的に棚卸しする | クライアント一覧、台帳、申請記録 |
| ID-3 | エージェントが使う秘密情報（キー、シークレット）はどう管理していますか。 | 秘密情報はコードや設定ファイルに書かず、シークレット管理から渡している | 自動ローテーションされ、漏えい時に即時失効できる | デプロイ設定、シークレット管理の画面 |

## 統制2 Authorization：ツール単位で最小権限にし、参照と更新を分ける

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| AZ-1 | エージェントが使えるツールは、どの単位で許可していますか。 | ツール（または参照系・更新系の経路）単位で、ゲートウェイのポリシーで許可している | ポリシーが GitOps で管理され、変更にはレビューが必要 | ゲートウェイのポリシー、リポジトリの履歴 |
| AZ-2 | 参照と更新は分かれていますか。 | 参照系と更新系のツールが別の経路・別の権限になっている | 更新系の権限を持つエージェントが、業務ごとに限定されている | ツール一覧、権限設計書 |
| AZ-3 | 顧客や口座など、データ単位の認可はどこで行っていますか。 | ツール側で、利用者がそのデータの所有者・担当者であることを確認している | 拒否の件数と内容を計測し、異常な拒否の増加を検知している | ツールのコード、拒否のログ |
| AZ-4 | エージェントが人間専用の操作（承認、監査など）を行えないようになっていますか。 | 人間専用の操作の権限を、エージェントの委任範囲から外している | 人間専用の経路に、エージェントのトークンが届かないことを定期的にテストしている | 委任範囲の設定、テスト結果 |

## 統制3 Guardrails：入力と出力を検査する（PII、プロンプトインジェクション）

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| GR-1 | ツールへの入力（引数）を検査していますか。 | 注入攻撃らしき文言と個人情報を、ツールの実行前に検査して止めている | 検出器（TrustyAI Guardrails など）をゲートウェイ側にも置き、二重化している | ガードレールの設定、遮断のログ |
| GR-2 | ツールや LLM の出力を検査していますか。 | 不要な個人情報や他の顧客の情報を、出力前に伏せている | 出力の検査結果を計測している | マスキングの設計、出力のサンプル |
| GR-3 | 検出のしきい値を、実績に基づいて調整していますか。 | 誤検知と見逃しを記録している | 遮断件数と誤検知率を計測し、定期的にしきい値を見直している | 遮断の記録、見直しの議事録 |
| GR-4 | 攻撃を想定したテスト（レッドチーム）をしていますか。 | リリース前に、既知の攻撃パターンで試験している | 評価セットに攻撃ケースを含め、モデルやプロンプトの変更ごとに自動で流している | 試験結果、評価レポート |

## 統制4 Blast Radius：レート制限、トークン上限、更新系の人間承認で被害範囲を限定する

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| BR-1 | エージェントの呼び出し回数や LLM のトークン量に上限はありますか。 | 利用者ごとの回数制限と、トークン量の上限がゲートウェイにある | 上限の到達を監視し、業務量に応じて見直している | RateLimitPolicy / TokenRateLimitPolicy、監視画面 |
| BR-2 | 更新系の操作に、人間の承認はありますか。 | 金額やリスクのしきい値を超える操作は、独立した人間の承認を経る（本人承認は不可） | リスクに応じて承認の要否と承認者が自動で振り分けられる | 承認フロー、職務分掌の設定 |
| BR-3 | 暴走時に、エージェントを止める手段はありますか。 | エージェント単位で即時に停止できる手順がある | 異常（急増、連続エラー）を検知して自動で遮断する | 停止手順、訓練記録 |
| BR-4 | 暴走時の最大影響（金額、件数）を説明できますか。 | 上限額と回数から、最大影響を数値で示せる | 最大影響が、リスク管理部門の許容範囲として合意されている | 影響試算、合意文書 |

## 統制5 Transactional Safety：書き込みの冪等性、補償、Outbox、Saga を設計する

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| TS-1 | 更新系のツールは冪等ですか（同じ依頼を二度受けても1回分しか動かない）。 | 冪等キーが必須で、キーはエージェント側（LLM ではない）で決める | 二重送信を試験で定期的に確かめている | ツールの仕様、試験結果 |
| TS-2 | 複数のシステムをまたぐ更新が途中で失敗したら、どう戻しますか。 | Saga などで補償処理が設計され、状態が記録される | 補償の発生を計測し、補償が失敗したときの手順がある | 設計書、補償のログ |
| TS-3 | 状態の更新と外部への送信の整合性をどう取っていますか。 | Transactional Outbox などで、状態の更新と送信の指示を同じトランザクションで確定させている | 送り残しを自動で拾い直す仕組みと、その監視がある | 設計書、Outbox のテーブル |
| TS-4 | 障害注入テストをしていますか。 | リリース前に、基幹の失敗・遅延を注入して補償を確かめている | 定期的（四半期など）に障害注入テストを行っている | 試験計画と結果 |

## 統制6 Observability：推論、ゲートウェイ、ツール、統合、基幹を一本のトレースで追い、品質・コスト・遅延を計測する

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| OB-1 | エージェントの1回の依頼を、どこまで一本のトレースで追えますか。 | 推論・ゲートウェイ・ツール・統合・基幹が、同じトレース ID でつながっている | トレースから、遅延とエラーの原因層を数分で特定できることを運用部門が確かめている | トレースの画面、障害対応の記録 |
| OB-2 | 品質・コスト・遅延の指標はありますか。 | ツールの成否、LLM のトークン量、応答時間を指標として集めている | 業務単位・エージェント単位でコストを配賦できる | ダッシュボード |
| OB-3 | SLO とアラートはありますか。 | 応答時間とエラー率の目標があり、逸脱を通知している | 品質（評価スコア）も SLO に含め、エラーバジェットで運用している | SLO 定義、アラート設定 |
| OB-4 | エージェントの評価を継続して行っていますか。 | 評価セットがあり、モデルやプロンプトの変更時に流している | 本番のトレースから評価ケースを追加し、自動で回している | 評価セット、評価レポート |
| OB-5 | トレースやログに含まれる個人情報をどう扱っていますか。 | 保存前にマスキングし、保管期間とアクセス権を定めている | マスキング漏れを定期的に検査している | 収集設定、保管規程 |

## 統制7 Audit & Traceability：誰の指示で、どのエージェントが、何をしたかを証明する

| ID | 質問 | L3 の基準 | L4 の基準 | 確認する証跡 |
| --- | --- | --- | --- | --- |
| AU-1 | 監査証跡には何が記録されますか。 | 指示した人、実行したエージェント、操作、対象、結果、トレース ID が記録される | 拒否・遮断・補償も含め、すべての判断が記録される | 監査証跡のサンプル |
| AU-2 | 監査証跡の改ざんをどう防いでいますか。 | 追記のみで、改ざんを検出できる（ハッシュ連鎖、WORM ストレージなど） | 改ざん検証が定期的に自動で行われ、保管期間が規程と一致している | 保管方式、検証結果 |
| AU-3 | 監査部門は、自分で証跡を検索・検証できますか。 | 監査部門が、IT 部門を介さずに検索できる | 監査レポートが自動で作られ、監査部門が自分で改ざん検証もできる | 監査部門の利用画面、権限設定 |

## 接続候補の棚卸し

| 業務 | 使うシステム | 操作 | リスク区分 | 所管部署 |
| --- | --- | --- | --- | --- |
| 〔例：残高照会〕 | 〔勘定系 API〕 | 参照 | 参照のみ | 〔コールセンター〕 |


---

# 参考資料：report.md

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

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 |  |