単位
1. 即時注入と多層防御 2. データ漏洩防止と PII マスキング 3. 出力の検証と人による検査 4. アクセス制御、ID、および秘密の管理 5. ロギング、監査証跡、証明可能性 6. モデルのリスク管理とレッドチーム 7. サプライヤー評価と第三者リスク 8. オンプレミス、VPC、Openweight ホスティング 9. 継続的なモニタリング、可観測性、ドリフト 10. インシデント対応と事業継続 11. エンタープライズ AI セキュリティ チェックリストとガバナンス
ユニット 5 / 11

ロギング、監査証跡、証明可能性

利益:

  • イベントを再構築するのに十分な最小限の監査証跡スキームを設計する能力
  • プロンプト/応答をマスクすることでログが漏洩源となるのを防ぐ機能
  • 相関 ID、不変性、保存期間を備えた検証可能なログを確立する機能

AI システムでは、いつか必ず「この決定はなぜこのように行われたのか、その日何が起こったのか?」という疑問が生まれるでしょう。この質問は、顧客、監査人、規制当局、または裁判所から尋ねられる場合があります。あなたの答えは、検証可能な監査証跡であるか、「わかりません」のいずれかになります。後者は企業環境では受け入れられません。この単元では、AI に特有のログに何を記録すべきか、何を記録すべきではないか、監査証跡を確立する方法、ログとセキュリティとプライバシーのバランスを保つ方法を学びます。

AI ではロギングが異なるのはなぜですか?

従来のソフトウェアでは、「誰が何をしたか」が記録されます。 AI では、これに、どのモデル/バージョンが使用されたか、どのようなプロンプトが送信されたか、どのような応答が生成されたかという 3 つの新しい側面が追加されます。エラーやクレームが発生した場合、この 3 つがなければインシデントを再構築することはできません。しかし、ユニット 2 で見たように、このプロンプト/レスポンスには PII が含まれる可能性があり、ログ自体が漏洩の原因になる可能性があります。これはバランスの芸術です。

注意: ロギングは「すべてを記録する」わけではありません。ログが多すぎるとプライバシーのリスクが生じ、ログが少なすぎると証拠が不足します。目標は、イベントをマスクして再構築するのに十分な PII を保持することです。

何を記録する必要がありますか?監査証跡スキーマ

確実な AI 監査証跡には、少なくとも次のものが含まれます。

  • 誰: ユーザー ID とロール (またはサービス ID)。
  • いつ: タイムスタンプ (可能な場合は追加のみ)。
  • 内容: 希望するアクションと召喚ツール。
  • どのモデル: モデル名とバージョン (例: claude-opus-4-8)、温度などの重要なパラメータ。
  • 入力/出力ダイジェスト: リクエストとレスポンスのマスクされたバージョンまたはダイジェスト/ハッシュ。
  • 決定: 自動的に処理されたのか、人間が処理したのか、承認されたのか拒否されたのか?
  • 結果: 操作は成功したかエラーでしたか、どのリソースが影響を受けますか?

ステップバイステップ: 監査証跡の確立

  1. 目標を設定します。誰がこれらのログを読むのでしょうか?なぜ読むのでしょうか? (インシデント対応、コンプライアンス監査、デバッグ。) 何を保持するかは目的によって決まります。
  2. PII ポリシーを適用します。ログを記録する前にプロンプ​​ト/応答をマスクします (ユニット 2)。
  3. 不変性を提供します。重要なログは追加専用にします。過去を黙って消すことは誰にもできないはずです。
  4. 保存期間を定義します。法的要件と機密保持のバランスに応じて期間を決定します。時間が経過すると自動的に削除されます。
  5. アクセスを制限します。ログへのアクセスも RBAC で保護する必要があります。ログの読み取りも記録する必要があります。
  6. 相関ID（トレースID）を追加します。リクエストのすべてのステップ (入力、ツール呼び出し、検証、出力) を単一の ID で接続します。

4 つのコピー可能なテンプレート

監査ログのスキーマ (JSON):

{ "trace_id": "...", "time": "YYYY-MM-DDThh:mm:ssZ", "user": "...", "role": "...", "model": "claude-opus-4-8", "parameters": { "温度": 0 }, "request_summary": "<マスク>", "response_summary": "<マスク>", "tools": ["tool_a", "tool_b"], "決定": "auto|human_approval", "approval": "approved|rejected|none"、 "result": "success|error"、 "affected_resource": "..."}

PII 制御プロンプトをログに記録します:

以下のログの例を確認してください。監査証跡に必要なフィールド (誰が、いつ、モデル、決定、結果) は完了していますか?生の PII も漏洩しましたか?各行について、次のようにレポートします: 「スペースが不足しています / 不足しています: ... /PII リーク: ...」 <logs>{{例 }}</logs>

イベント再構築プロンプト:

次の監査レコードは、単一のtrace_idに属します。イベントを時系列の物語に変えます。ユーザーは何を望んでいたのか、モデルは何をしたのか、どのような検証が行われたのか、どのように意思決定が行われ、結果はどうなったのか。欠落しているステップまたは矛盾したステップにフラグを立てます。<records>{{trace_registers }}</records>

保持ポリシーの決定ルール:

ログの種類ごとに、以下を決定します。 - 法的な保存義務はありますか? (存在する場合は最小期間) - PII が含まれていますか? (含まれている場合は、期間を短縮し、アクセスを絞り込みます)- セキュリティ インシデントの証拠はありますか? (ストアは変更できません)結果:「ストア N 日 + 追加専用 mi + アクセス レベル」。

弱いプロンプト / 強いプロンプト

下手なアプローチ

強力なアプローチ

まったくログを記録しない (「必要ない」)

イベントを再構築するための最小セットをログに記録する

生のプロンプト/応答をそのままログに記録する

マスクされたサマリー + トレース ID のロギング

ログを無制限に保存

法的保護とプライバシーのバランスを考慮した保存期間

誰でもログを削除できる

重要なログは追加のみでアクセス制御されます

ミニケース3個

ケース 1 — Trace ID により、1 日の調査が 15 分に短縮されました。 「私の申請は不当に拒否されました」と顧客は銀行の信用事前評価アシスタントに語った。相関 ID のおかげで、チームはアプリケーションの入力、従業員の検証、決定を 15 分で再構築しました。エラーがルール検証の間違ったしきい値によって引き起こされたことを示し、それを修正しました。

ケース 2 — 監査で過剰なロギングが発見されました。ある電子商取引会社は、デバッグのためにすべてのプロンプト/応答を生のログに書き込んでいました。年次監査では、これらのログには顧客の住所と電話番号が含まれており、2 年間保存されていたことが判明しました。この調査結果は、マスキング + 90 日間の保存ポリシーに切り替えることで解決されました。監査証跡機能は維持されました。

ケース 3 — 追加のみのログにより内部不正行為が明らかになりました。あるプロバイダーの従業員は、作成した間違ったバッチを隠すためにログを削除しようとしました。ログは追加専用であり、ログの読み取り/削除の試行が記録されるため、試行はすぐに確認できました。このインシデントにより、懲戒処分とプロセスの是正が行われました。

ヒント: 各リクエストに相関 ID (トレース ID) を割り当て、それをすべてのステップで実行します。問題が発生したときに、1 つのクエリで「そのリクエストに関するすべて」を収集できることは、インシデント対応の最大の加速手段となります。

よくある間違い

  • まったくログが記録されていないか、ログが少なすぎてイベントを再構築できない。
  • マスクなしで生のリクエスト/レスポンスをログに記録し、そのログを漏洩源にします。
  • モデル名/バージョンと決定 (自動/人的) を記録しません。
  • ログを無制限に保存すると、プライバシー リスクが増加します。
  • 変更される可能性がある重要なログを残す。ログアクセスを記録しません。
  • 相関 ID (トレース ID) を使用しないため、ステップを接続できません。

要約すると

  • AI ログにより、「誰が何をしたか」という 3 つの側面、つまりどのモデル/バージョン、どのプロンプト、どの応答が追加されます。
  • 目標は、PII をマスクしてイベントを再構築できる程度に最小限に抑えることです。それ以上でもそれ以下でもありません。
  • 監査証跡には、誰が、いつ、何を、どのモデル、決定、結果のフィールドを含める必要があります。
  • 重要なログは追加専用にし、アクセスを制限し、ログ アクセスも記録する必要があります。
  • 相関 ID (トレース ID) はリクエストのすべてのステップを結び付け、インシデント調査を迅速化します。

アプリケーションタスク

独自の AI フローからリクエストを選択し、上記の JSON スキーマを使用してそのリクエストの理想的な監査証跡を書き込みます。次に 2 つのテストを行います: (1) この録音だけでストーリーを最初から最後まで伝えることができますか? (2) 記録に生の PII はありますか?欠落しているフィールドがある場合は追加し、PII がある場合はマスクします。最後に、保存期間とアクセス レベルを設定します。

チェックリスト

  • [ ] 監査証跡には、誰が/いつ/何を/パターン/決定/結果フィールドが含まれます。
  • [ ] プロンプト/応答はログの前にマスクされます (PII はありません)。
  • [ ] 各リクエストには相関 ID (トレース ID) が割り当てられます。
  • [ ] 重要なログは追加のみでアクセスが制御されます。
  • [ ] 保存期間は法定+機密性のバランスによって定められ、期間終了後に削除されます。
  • [ ] ログを使用すると、30 分以内にイベントを再構築できます。
前へ 次へ