AI監査証跡｜AI監査で必要な証跡と現場手順

「全部のログを保存すれば良い」は現場でよく聞く誤解です。監査や問い合わせで実際に問われるのは、ある事象について誰が見ても同じ手順で再現して説明できるかどうかです。本稿は導入判断に迷う担当者、PoCを回す現場チーム、監査対応フローを整えたい事業部マネージャー向けに、現場で即使える判断軸とテンプレをまとめます。

要点（先に結論）
導入で壊す誤解：「ログ全部保存でOK」
- 導入時に必ず詰める判断軸
- 導入会議で行う具体作業
判断軸で決める：目的→粒度→権限
- 目的別の最小証跡例
- 承認ログ設計の例（事前合意項目）
現場で証明する実務手順：問い合わせ対応テンプレ
PoCとテストで収集すべき証跡と初回チェックリスト
- PoCチェックリスト（必須項目）
インシデントと承認：因果立証の現場手順
- 初動手順（即時実行）
よくある質問（FAQ）
まとめ：最初の一歩と見送る条件

要点（先に結論）

監査で有効な証跡は「誰が／いつ／どの画面・ログ・帳票でどの入力／出力を確認したか」を目的別に最小限定義し、チケット単位で再現できる手順（チェックリスト）に落とし込むことです。本記事から持ち帰るもの：導入可否の判断材料、PoC合否の定義、問い合わせ・インシデントで即使える証跡テンプレと初動手順。

導入で壊す誤解：「ログ全部保存でOK」

結論：全ログ保存は手段であり、監査で評価されるのは特定ケースを誰でも再現して説明できることです。量が多くても索引やID体系が整理されていなければ、操作主体や因果関係は説明できません。導入会議ではまず「問い合わせ1ケース」を定義し、そのケースを再現する最小証跡で導入可否を判断してください。

導入時に必ず詰める判断軸

証跡の目的（説明責任／因果立証／操作履歴／出力検証）を確定する。
粒度と検索性（即時対応用サマリ vs 深掘り用完全ログ、索引項目の統一）を決める。
権限と委任ルール（誰が閲覧・添付・承認できるか）を明文化する。

導入会議で行う具体作業

代表ケースを1件書く（例：請求差異／本人確認ミス）。
再現に必要な証跡を列挙：画面スクショ（URL・UTC時刻・表示ユーザー）、トランザクションID、承認記録、AI出力のメタ（prompt/model_id/version/response_id）など。
ベンダーとSLAで索引項目（timestamp, user_id, transaction_id, screen_id/url, model_id, model_version, response_id）で合意する。

判断軸で決める：目的→粒度→権限

結論：証跡設計は「目的→粒度→権限」の順で決めます。用途ごとに最小証跡セットと承認フローを定義し、即時対応用サマリと深掘り用ログを分離して管理すれば運用負荷を抑えられます。

目的別の最小証跡例

説明責任：承認記録＋表示スクショ（URL、時刻、表示ユーザー）。
因果立証：プロンプト／モデル履歴（model_id/model_version/response_id）とタイムライン。
出力検証：生成したPDFのハッシュ（SHA-256）と表示内容の照合。

承認ログ設計の例（事前合意項目）

承認レコード要素：approval_id, approver_user_id, original_owner_id, action, timestamp_utc, screen_id/url, transaction_id, evidence_link。
代理承認のルール：代理である旨・代理者ID・元承認者ID・理由を記載し、追加証跡を添付することを必須化。

現場で証明する実務手順：問い合わせ対応テンプレ

結論：チケットごとのチェックリストを1つ用意すれば大半の問い合わせは解決できます。テンプレは「誰が／何を／いつ／どの形式で保存するか」を明確にします。

ワンライン手順（運用フロー）

受領 → ID照合 → 画面スクショ（URL・UTC時刻・表示ユーザー） → 関連ログ／帳票紐付け → 承認者確認（承認レコード保存） → 回答作成（チケットに証跡リンク添付）

問い合わせテンプレ（請求差異・本人確認ミスの共通項）

受領：チケットID発行、影響範囲を記載。
ID照合：顧客ID／トランザクションIDを記録。
スクショ：該当画面を2点以上保存し、URL・UTC時刻・表示ユーザーを写す。
帳票：請求書等はPDFで保存し、SHA-256ハッシュと保存日時を記録。
AI出力：可能な限り完全なプロンプト、model_id/model_version、response_id、リクエスト/レスポンスのタイムスタンプを保存。UI利用時はスクリーンレコード＋メタを確保する。
承認：最終承認の承認レコードを添付してチケットをクローズ。

注意点：スクショだけでURLやトランザクションIDを書き忘れると他事案と混同します。AI応答を保存する場合はプロンプトとモデル情報も必須です。

技術的サンプル（検索索引・ログフィールド例）

{
  "timestamp_utc":"2025-03-01T12:34:56Z",
  "user_id":"user-123",
  "transaction_id":"tx-20250301-0001",
  "screen_id":"invoices/detail",
  "url":"https://app.example.com/invoices/tx-20250301-0001",
  "evidence_links":["s3://evidence/screenshots/tx-0001-1.png"],
  "ai_meta": {
    "prompt":"請求書の差異について説明してください",
    "model_id":"gpt-4-xyz",
    "model_version":"2025-02-01",
    "response_id":"resp-abc123"
  },
  "pdf_hash":"sha256:abcdef..."
}

この構成で保存すれば、transaction_idで絞り込み検索し証跡一式を即座に返す運用が可能になります。

PoCとテストで収集すべき証跡と初回チェックリスト

結論：PoC合否は「定義した1ケースを別担当者が同じ手順で再現できるか」。PoCは設計欠陥を露呈させる場であり、ここで得られた証跡と手順が本番運用の核になります。

PoCチェックリスト（必須項目）

再現ケース定義：実運用に近い問い合わせシナリオを1件固定する。
必須ログ（API）：timestamp_utc, user_id, request_body（プロンプト）, response_id, model_id, model_version。
必須ログ（UI）：スクリーンレコード/スクショ（url/screen_id, timestamp_utc, displayed_user）、トランザクションID。
帳票：生成PDFとそのSHA-256ハッシュ。
保存場所：Read-Onlyのテストバケット＋検索索引（transaction_idで一括取得できること）。
合否基準：別担当者が10分以内に同一証跡（スクショ+APIログ+PDFハッシュ）を検索・ダウンロードできること。

PoCでよくある失敗：画面操作のみ検証してAPIメタを取らず本番で再現できない、テストログを匿名化しすぎて実運用へ紐付けられない、など。

インシデントと承認：因果立証の現場手順

結論：インシデント対応は「速やかな一次保存→責任者への即報→詳細収集」。初動で改変不可の保全を優先してください。初動のRead-Only保全を失敗すると因果立証が難しくなります。

初動手順（即時実行）

一次保全：該当会話・画面をスクリーンレコードで保存しRead-Only化。APIレスポンスをエクスポートしてRead-Only保管。帳票はPDFで保存しSHA-256を取得。
一次報告：発生日時・影響範囲・保全場所リンクを監査・法務へ送付する一次報告を作成。
承認：事前定義の承認者リストに従い調査開始を決定。代理承認があれば代理記録を必須で保存。
詳細調査：DBトランザクション、AIモデルの完全ログ、モデルバージョン履歴を時系列で取得し、タイムラインを作成する。

回避策の例：ログ上書き防止のためエクスポート＋Read-Only保管を自動化、承認者リストと代理ルールを事前に明文化して教育する。

よくある質問（FAQ）

どのくらいの期間、証跡を保持すれば良いですか？

法令や業界ガイドラインに依存しますが、実務では短期検索性を保つサマリ（例：90日）＋深掘り用の完全ログ（業務重要度に応じて1〜7年）という二層設計が現実的です。会計・請求関連は法定保存期間に従ってください。

外部モデル（ChatGPT/Claude等）利用時に必ず保存すべきメタは？

必須：可能な限り完全なプロンプト、model_id、model_version、response_id（API利用時）、リクエスト/レスポンスのタイムスタンプ、ユーザーID、生成パラメータ。UI利用時はスクリーンレコードと画面上のユーザー識別情報を保存してください。

承認者不在時の代理ルールはどう設計すべきか？

職務分掌に代理ルールを事前定義し、代理承認時は必ず「代理であること（代理者名・元承認者名・理由・タイムスタンプ）」を承認記録に残し、代理承認には追加の証跡を要求する運用にしてください。

PoCの合否基準は何ですか？

PoC合格は「定義した再現ケースを別担当者が同じ手順で再現でき、索引で証跡一式（スクショ・APIログ・PDFハッシュ）が取得できること」と定義してください。検索応答時間などのSLAもここで確認します。

まとめ：最初の一歩と見送る条件

導入会議で「問い合わせ1ケース」を定義し、そのケースを再現するための最小証跡要件（スクショに含める項目、トランザクションID、承認記録）を決める。
現場テンプレを作成し、受領→ID照合→スクショ→帳票ハッシュ→AIメタ保存→回答の手順を実演して習熟させる。
PoC合格を「別担当者が同じ手順で再現できること」とし、API/UI両面のログを検証する。
見送る条件：ベンダーが必要最小限の証跡セットを再現できない、またはログ形式・索引が整理されず検索に使えない場合は導入を見送るべきです。承認権限や代理ルールが事前に定まらず初動保全が担保できない場合も同様です。

監査で使える証跡は「全部」ではありません。目的を明確にし、最小限の証跡セットを定義して現場で再現可能な手順に落とし込めたときだけ、はじめて実務で運用できるAI監査体制が成立します。まず会議で問い合わせ1ケースを決め、PoCで再現できるかを合否基準にしてください。

AI監査で押さえるべき証跡と現場の再現手順（実務テンプレ付き）