Minimum Evidence Requirements（最小証跡要件）
本ページは、監査人・実装者向けの Minimum Evidence Requirements チェックリストです。ライフサイクル別に整理した MUST レベルの最小証跡要件を定義します。説明可能性と証跡準備を支えるものであり、法的助言の提供や適合の保証は行いません。
提出物の準備・レビュー時は Evidence Bundle と Validator とあわせて本ページを参照してください。
1) Request（申請）
- MUST フィールド: 識別子、タイムスタンプ、actor/role、scope（申請内容）、rationale（理由）。
- MUST リンク: request id を review および利用を記録する EV 項目から参照する。
- 示すこと: 利用が承認・実施前に申請されスコープが定められていること。
2) Review / Approval（審査/承認）
- MUST フィールド: 識別子、タイムスタンプ、actor/role、decision（承認/却下/条件付き）、scope、rationale、request への参照。
- MUST リンク: review id を EV および後続の exception/renewal から参照する。
- 示すこと: 利用（または例外）の前に定義された審査・承認が行われていること。
3) Exception（例外）
- MUST フィールド: 識別子、タイムスタンプ、scope、expiry（期限）、compensating controls、rationale、review/request への参照。
- MUST リンク: exception → 代替統制；exception → 有効期限；exception → renewal（再評価時期）。
- 示すこと: 逸脱が有効期限付きであり、代替統制と renewal に紐づいていること。
4) Renewal / Re-evaluation（更新/再評価）
- MUST フィールド: 識別子、タイムスタンプ、actor/role、decision（更新/取り消し/条件付き）、先行 exception/request/review/EV への参照。
- MUST リンク: renewal は更新対象の exception または承認を参照；EV 項目は renewal id を参照可能。
- 示すこと: 例外・承認が定義に基づき再評価され、更新または取り消しされていること。
5) Change Log（変更管理）
- MUST フィールド: 識別子、タイムスタンプ、actor/role、変更内容、references（変更対象の EV/request/review/exception/renewal 等）。
- MUST リンク: change log エントリは変更対象アーティファクトを参照する。
- 示すこと: バンドルまたはその内容の変更が記録され追跡可能であること。
6) Integrity & Access（完全性/アクセス制御）
証跡の完全性とアクセス制御は監査の依拠に不可欠である。AIMO は特定の技術的統制を規定しないが、採用者はこれらの期待事項がどのように満たされているかを文書化すべきである。
アクセス制御の指針
| 観点 | 指針 |
|---|---|
| ロールベースアクセス | ロール（証跡作成者、審査者、監査人、管理者等）を定義し、誰が証跡を作成・閲覧・更新・削除できるかを文書化する。 |
| 最小権限 | 必要最小限のアクセスを付与し、書き込み権限を承認された担当者に制限する。 |
| アクセスログ | 監査証跡のため、アクセスイベント（誰が、いつ、何を）を記録する。 |
| 職務分離 | 可能な場合、証跡作成と承認のロールを分離する。 |
保持期間の指針
| 観点 | 指針 |
|---|---|
| 保持期間 | 規制要件と組織ポリシーに基づき保持期間を定義・文書化する（例：財務監査では5〜7年）。 |
| 保持スケジュール | どの証跡を、どのくらいの期間保持し、いつ廃棄可能かを示すスケジュールを維持する。 |
| 訴訟ホールド | 訴訟・調査のため通常の保持・削除を停止する訴訟ホールドプロセスを支援する。 |
不変性オプション
| オプション | 説明 |
|---|---|
| 暗号学的ハッシュ | 証跡ファイルに対し SHA-256（またはより強力な）ハッシュを生成し、検証用にハッシュを別途保管する。 |
| WORM ストレージ | 証跡アーカイブに Write-Once-Read-Many ストレージを使用し、変更を防止する。 |
| 追記専用ログ | 変更追跡に追記専用の監査ログを使用する。 |
| デジタル署名 | 証跡バンドルに署名し、作成者を証明し改ざんを検出する。 |
監査証跡の期待事項
| 要素 | 文書化すべき内容 |
|---|---|
| 変更ログ | 誰が、何を、いつ、なぜ変更したかを記録する（Change Log ライフサイクルグループ参照）。 |
| アクセスログ | 誰が、いつ、何のために証跡にアクセスしたかを記録する。 |
| システムログ | 証跡の完全性主張を支える関連システムログ（認証、認可）を保持する。 |
| 検証記録 | 定期的な完全性検証（ハッシュチェック、監査レビュー）を文書化する。 |
示すこと
- 証跡が保全されている: 完全性メカニズム（ハッシュ、WORM、署名）により、証跡が改ざんされていないことを示す。
- アクセスが制御されている: アクセスログとロール定義により、誰がアクセス権を持ち、最小権限が適用されていることを示す。
- 監査の依拠が支えられている: これらの要素を合わせて、監査人に証跡の信頼性への確信を与える。
推奨運用プロファイル
リスク許容度と規制要件に基づきプロファイルを選択する。これらは推奨であり、義務ではない。
| 観点 | 軽量（Lightweight） | 標準（Standard） | 厳格（Strict） |
|---|---|---|---|
| 用途 | 内部パイロット、低リスクAI | 本番システム、中リスク | 規制産業、高リスクAI |
| 保持期間 | 1〜2年 | 5〜7年 | 7〜10年以上または規制最低限 |
| 不変性 | SHA-256 ハッシュ | SHA-256 + 追記専用ログ | WORM ストレージ + デジタル署名 |
| アクセス制御 | ロールベース（基本） | ロールベース + アクセスログ | 職務分離 + 完全監査証跡 |
| 監査証跡 | 変更ログのみ | 変更ログ + アクセスログ | 完全システムログ + 定期検証 |
| 検証頻度 | オンデマンド | 四半期ごと | 月次または継続的 |
| バリデータ利用 | 任意 | 提出前に必須 | 必須 + 自動 CI チェック |
!!! note "保持期間は例示" 表中の保持期間は例示である。組織は適用法令、契約、業界要件、内部ポリシーに基づき保持期間を決定すること。
!!! tip "選び方" - 軽量: 実験、内部ツール、正式な監査が想定されない低リスク用途に適する。 - 標準: 監査の可能性はあるが継続的ではない、ほとんどの本番デプロイに推奨。 - 厳格: 規制産業（金融、医療、政府）またはリスク影響の大きいAIシステムに必須。
Important note
本最小セットは説明可能性と証跡準備を支援する。法的助言の提供および適合の保証は行わない。
バンドル構造と TOC は Evidence Bundle、フィールドレベルの整合は EV Template およびスキーマを参照。
関連：ログスキーマ — Shadow AI 検知およびエージェント活動証跡のための正規化ログ形式。