最低証跡要件（Minimum Evidence Requirements）
本ページは、監査人・実装者向けの最低証跡要件チェックリストです。ライフサイクル別にグループ化した MUST レベルの最低証跡要件を定義します。説明可能性と証跡準備を支援するものであり、法的助言や準拠の保証は行いません。
提出物の準備・レビュー時は、Evidence Bundle および Validator とあわせて本ページを参照してください。
1) 申請（Request）
- MUST フィールド: 識別子、タイムスタンプ、担当者/役割、スコープ（申請内容）、理由（rationale）。
- MUST リンク: 審査および利用を記録する EV 項目から申請 ID を参照可能であること。
- 証明する内容: 利用が承認・実施の前に申請され、スコープが定められていたこと。
2) 審査 / 承認（Review / Approval）
- MUST フィールド: 識別子、タイムスタンプ、担当者/役割、判断（承認/却下/条件付き）、スコープ、理由、申請への参照。
- MUST リンク: EV および後続の例外・更新から審査 ID を参照可能であること。
- 証明する内容: 利用（または例外）の前に定義された審査・承認が行われたこと。
3) 例外（Exception）
- MUST フィールド: 識別子、タイムスタンプ、スコープ、有効期限（または期限）、代替統制、理由、審査/申請への参照。
- MUST リンク: 例外 → 代替統制；例外 → 有効期限；例外 → 更新（再評価期日）。
- 証明する内容: 逸脱が有効期限付きであり、代替統制を持ち、更新に紐づいていること。
4) 更新 / 再評価（Renewal / Re-evaluation）
- MUST フィールド: 識別子、タイムスタンプ、担当者/役割、判断（更新/取り消し/条件付き）、先行する例外/申請/審査/EV への参照。
- MUST リンク: 更新は対象となる例外または承認を参照；EV 項目は更新 ID を参照可能。
- 証明する内容: 例外・承認が定義された基準で再評価され、更新または取り消しされていること。
5) 変更ログ（Change Log）
- MUST フィールド: 識別子、タイムスタンプ、担当者/役割、変更内容、参照（対象となる EV・申請・審査・例外・更新など）。
- MUST リンク: 変更ログエントリは、変更対象または変更の契機となるアーティファクトを参照する。
- 証明する内容: バンドルまたはその内容の変更が記録され、追跡可能であること。
6) 整合性とアクセス（Integrity & Access）
証跡の整合性とアクセス制御は監査の信頼性に不可欠です。AIMO は特定の技術的統制を規定しませんが、採用者はこれらの期待をどのように満たしているかを文書化してください。
アクセス制御ガイダンス
| 観点 | ガイダンス |
|---|---|
| ロールベースアクセス | 役割（証跡作成者、レビュアー、監査人、管理者など）を定義し、誰が証跡の作成・閲覧・更新・削除を行うかを文書化する。 |
| 最小権限 | 必要最小限のアクセスを付与し、書き込みは権限ある担当者に制限する。 |
| アクセスログ | 監査証跡のため、アクセスイベント（誰が、いつ、何を）を記録する。 |
| 職務分離 | 可能な範囲で、証跡の作成と承認の役割を分離する。 |
保持ガイダンス
| 観点 | ガイダンス |
|---|---|
| 保持期間 | 規制要件と組織方針（例：財務監査では 5〜7 年）に基づき保持期間を定義・文書化する。 |
| 保持スケジュール | どの証跡をどの期間保持し、いつ廃棄するかを示すスケジュールを維持する。 |
| 訴訟ホールド | 訴訟・調査のため通常の保持・削除を停止するプロセスをサポートする。 |
改ざん防止の選択肢
| 選択肢 | 説明 |
|---|---|
| 暗号学的ハッシュ | 証跡ファイルの SHA-256（以上）ハッシュを生成し、検証用にハッシュを別途保管する。 |
| WORM ストレージ | 証跡アーカイブの改ざん防止のため、追記専用（Write-Once-Read-Many）ストレージを用いる。 |
| 追記専用ログ | 変更追跡のため追記専用の監査ログを用いる。 |
| デジタル署名 | 証跡バンドルに署名し、作成者を証明し改ざんを検知する。 |
監査証跡の期待
| 要素 | 文書化する内容 |
|---|---|
| 変更ログ | 誰が何をいつなぜ変更したかを記録する（Change Log ライフサイクル群を参照）。 |
| アクセスログ | 誰がいつ何の目的で証跡にアクセスしたかを記録する。 |
| システムログ | 証跡の整合性主張を支える関連システムログ（認証・認可）を保持する。 |
| 検証記録 | 定期的な整合性検証（ハッシュ照合、監査レビュー）を文書化する。 |
証明する内容
- 証跡は保全されている: ハッシュ・WORM・署名などの整合性機構により、証跡が改ざんされていないことを示す。
- アクセスは制御されている: アクセスログと役割定義により、誰がアクセスしたかおよび最小権限が適用されたことを示す。
- 監査の信頼性を支える: これらを総合し、監査人が証跡の信頼性を確認できるようにする。
推奨運用プロファイル
リスク許容度と規制要件に応じてプロファイルを選択してください。推奨であり、必須ではありません。
| 観点 | ライト | スタンダード | ストリクト |
|---|---|---|---|
| 用途 | 社内パイロット、低リスク AI | 本番システム、中程度のリスク | 規制業種、高リスク AI |
| 保持期間 | 1〜2 年 | 5〜7 年 | 7〜10 年以上または規制の最小値 |
| 改ざん防止 | SHA-256 ハッシュ | SHA-256 + 追記専用ログ | WORM ストレージ + デジタル署名 |
| アクセス制御 | ロールベース（基本） | ロールベース + アクセスログ | 職務分離 + 完全な監査証跡 |
| 監査証跡 | 変更ログのみ | 変更ログ + アクセスログ | システムログ全体 + 定期検証 |
| 検証頻度 | 必要時 | 四半期 | 月次または継続 |
| Validator 利用 | 任意 | 提出前に必須 | 必須 + CI 自動チェック |
!!! note "保持期間は例示" 記載の保持期間は例示です。組織は適用される法令、契約、業界要件、内部方針に基づき保持を決定してください。
!!! tip "選び方" - ライト: 実験・社内ツール・フォーマルな監査が想定されない低リスク用途に適する。 - スタンダード: 監査が行われる可能性はあるが継続的でない本番導入に推奨。 - ストリクト: 規制業種（金融・医療・政府）またはリスク影響の大きい AI システムで必要。
重要な注意
本最小セットは説明可能性と証跡準備を支援するものであり、それ自体は法的助言や準拠の保証を提供しません。
バンドル構造と TOC は Evidence Bundle、フィールドレベル整合は EV Template およびスキーマを参照。Shadow AI 検知・エージェント活動証跡の正規化ログ形式は Log Schemas を参照。
規制オーバーレイ（参考）
以下のオーバーレイは、特定の規制・調達文脈で求められることが多い追加証跡を説明する参考です。EV Template の External Forms セクションに公式テンプレート・チェックリストをそのまま添付し、マニフェストで logical_id により参照してください。
| オーバーレイ | 通常期待される追加アーティファクト | 添付先 | プロファイル（任意） |
|---|---|---|---|
| EU ハイリスク | リスク管理、技術文書（Annex IV）、ログ、人的監督、透明性（Art 50）、インシデント報告 | payload_index；Evidence Bundle + Annex IV プロファイル | eu_ai_act_annex_iv.json、eu_ai_act_high_risk.json |
| EU GPAI CoP | Model Documentation Form（透明性、著作権、安全・セキュリティ） | External Forms；logical_id 例: GPAI_MODEL_DOC_FORM | eu_gp_ai_cop.json |
| NIST GenAI | GenAI プロファイルのアーティファクト（モデル適応、評価、監視） | payload_index；change_log；External Forms / GenAI 記録 | nist_ai_600_1_genai.json |
| UK ATRS / 調達 | ATRS 透明性記録、説明責任者、調達評価メモ | External Forms；Summary、review | uk_atrs_procurement.json |
| JP 調達 | 政府 GenAI 調達チェックリスト、AI ビジネスガイドライン チェックリスト | External Forms；logical_id 例: JP_PROCUREMENT_CHECKLIST | jp_gov_genai_procurement.json |
プロファイルファイル名は coverage_map/profiles/<target>_<purpose>.json の形式で、各ファイルに target_version を含みます。英国・日本は Coverage Map — Procurement & Disclosure、EU・NIST は EU AI Act および NIST AI RMF を参照。