# 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〕 | 参照 | 参照のみ | 〔コールセンター〕 |