生成AIの利用ログで、誰が何を参照したかを監査する

AIの依頼・実行主体・参照資料の版・操作・出力をIDで結び、本文を無制限に保存せず監査の問いへ答える記録を設計します。

確認日 2026年10月23日AIものさし編集部

生成AIの利用を監査するときは、誰がログインしたかだけでなく、どの依頼で、どの資料のどの版を参照し、どの操作や出力へ進んだかを結びます。全文のpromptやresponseを無制限に保存することを、追跡可能性の前提にしません。監査の問いと、製品で実際に取得できる記録を先に対応させます。

この記事は監査設計の例です。実ログの取得、利用者監視、保持・permission変更は行っていません。下記のschemaは架空のアプリで考えるためのもので、すべてのAI製品が同じfieldを提供するという意味ではありません。

監査で答えたい問いを決める

対象の利用目的、data区分、監査担当、必要な期間、閲覧できる人を決めます。「誰が何を参照したか」と「モデルが内部で何を考えたか」は別です。取得していない内部過程を、logから推測して監査結果へ書きません。

表は横にスクロールできます

OWASPのLogging資料（新しいタブで開く）は、いつ・どこで・誰が・何をしたかと、関連eventをつなぐinteraction identifierを説明しています。実アプリでは既存のIDを活用し、異なるsystemの同じ「user」という列をそのまま一つに混ぜないようにします。

人が依頼し、service accountが検索し、workerが送信する構成なら、三者のroleを追います。人のaccount IDだけで、すべての下流操作を本人が直接行ったと報告しません。代理実行、承認、credentialの参照先を秘密値なしで記録します。

request ID、run ID、tool call ID、外部operation IDを対応させます。再試行で新しいrunが作られる場合は親の依頼へ結び、試行ごとの結果を残します。最後の成功で元の失敗logを上書きすると、何が起きたかを説明できなくなります。

検索候補として返ったsource、実際に開いたsource、回答へ引用したsourceを同じ状態にしません。source ID、バージョンや取得時点、該当位置、アクセス結果を記録し、現在の文書内容だけで過去の回答を検証しないようにします。

AIが引用を付けても、実際にその資料を取得した証明とは限りません。retrieval/toolの記録と引用先を照合します。モデルの事前知識や推測で出た文を、社内source参照済みとして監査台帳へ登録しません。参照したが主張を支えない場合も、根拠の品質問題として別に残します。

input/outputの全文が必要か、限定された保管先への参照やhashで足りるかを判断します。hashは内容の一致を検査する手掛かりであり、元dataを復元したり、誰でも原本を読める権限を与えたりするものではありません。元資料の保持・削除・権限も別に管理します。

表は横にスクロールできます

通常logへtoken、password、接続文字列、不要な個人情報や機密本文を入れません。マスキング前の値を別logへ送っていたら、表示上のredactだけでは足りません。転送先やexport先を含む記録経路を確認します。

利用プラン、管理role、対象event、保持期間、取得遅延、export方法を、対象製品の現行公式資料と実設定で確認します。「監査logあり」という名称だけで、prompt、source、tool、出力先がすべて取得できるとはしません。取れないfieldは不明とし、アプリ側で補う範囲を決めます。

監査記録自身の閲覧・変更・exportも管理します。担当者が元dataを見なくても質問へ答えられる範囲を設計し、必要な場合だけ権限者が原資料へ戻ります。保存期間や通知・同意等の条件は、自社の適用規程と担当へ確認し、本稿で一律の法的期限を断定しません。

許可された検証で、一つの依頼から検索、source取得、引用、tool実行、出力までIDをたどります。権限拒否、再試行、資料更新、途中失敗、log転送遅延を条件に加えます。正常な一回だけで監査可能と判断しないようにします。

記録が見つからなければ、未実行、取得漏れ、保持期限、別account、時刻基準、転送遅延を分けます。不足を推測で埋めず、「このevent以降は確認不能」と示します。完了記録には、答えられた監査の問い、実際の記録範囲、照合方法、残る不明と改善担当を残します。