AIの利用ログは「取れば安心」ではありません。取ったログを誰がいつ見て、何を説明できるようにするか——記録の設計と運用が伴って初めて監査と説明責任の土台になります。本稿では蓄積したログを継続的に活かす運用を、情シスと内部監査の実務から考えます。
生成AIや社内AIエージェントの導入が進み、多くの組織で「利用ログは取っています」という状態にはなりました。しかし監査部門や経営から「では、先月このエージェントがどの業務で、どんなデータを参照して、何を出力したのか、根拠を含めて説明できますか」と問われると、途端に答えに詰まる——これが今、情シスと内部監査の現場で静かに起きている課題だと考えられます。ログは器に溜まっているのに、説明責任を果たす形になっていないのです。
背景には、AI利用が「人が都度プロンプトを打つ」段階から、「エージェントが自律的に複数ステップを実行する」段階へ移りつつあることがあります。人手を介さない処理が増えるほど、後から「なぜその結論に至ったか」を再構成できるかどうかが、ガバナンス上の分かれ目になります。記録が断片的だと、インシデントが起きたときに原因追跡も再発防止もできません。
ログ収集はツールの機能でおおむね実現できます。難しいのはその先——溜まったログを定期的にレビューし、逸脱を検知し、ガイドラインや権限設計に反映して改善を回す運用です。ここは自動では回りません。利用ログの監査とガバナンスの全体像を踏まえつつ、本稿では特に「蓄積したログを継続活用する運用」に焦点を絞って掘り下げます。
内部監査や外部監査の場面でAI利用について問われるとき、その核心は多くの場合「事後に事実関係を再構成できるか」に集約されると考えられます。具体的には、誰が（あるいはどのエージェントが）・いつ・どの入力データを・どのモデルやツールを介して・どんな出力を得て・その結果どの業務判断に使ったか、という一連の流れです。これが途切れずにたどれることが、説明責任の技術的な土台になります。
誤解されやすいのですが、監査で第一に問われるのはAIの出力精度そのものではありません。問われるのは「その出力をどう扱う仕組みだったか」です。たとえば重要な判断にAI出力を使ったなら、人間の確認が挟まっていたか、その確認記録が残っているか。ここは人間承認の設計と表裏一体で、承認の事実がログとして残っていなければ、後から「確かに人が見て決めた」と主張する根拠が持てません。
説明責任の相手は監査部門だけではありません。取引先からの情報管理に関する問い合わせ、顧客からの苦情、規制当局への報告、そして社内での再発防止会議——それぞれ求める粒度が違います。だからこそ「どのレベルまで再構成できるようにしておくか」を事前に決めておく必要があり、ここを曖昧にしたまま記録を始めると、いざというとき粒度が足りない、あるいは逆に機密を取りすぎている、という事態になりがちです。
記録項目の設計は「全部取れば安心」ではありません。むしろプロンプト全文や参照データを無制限に長期保存すると、それ自体が機密情報の新たな蓄積場所になり、漏えい時のリスクを増やします。記録範囲は、監査で再構成したい粒度と、機密保持・個人情報保護の要請との間で、法務・現場と合意して決めるべき事項だと考えます。
一般に、後追いの土台として押さえておきたいのは、実行主体（利用者IDまたはエージェントID）、日時、利用したモデル・ツール・エージェントの識別子、入力の要約またはハッシュ、参照した社内データソースの範囲、出力の要約、そして人間の承認・却下の記録、といった項目です。入力そのものを丸ごと保存するのではなく、後から突き合わせできる識別子や要約にとどめる設計も選択肢になりえます。
どのデータがログに乗りうるかは、そもそも何をAIに入力してよいかという入口の設計に依存します。機密データ入力ルールで「入れてよいもの・悪いもの」を線引きしておけば、ログ側で保持してよい範囲もおのずと定まります。逆に入口が無統制だと、ログにも機微情報が無秩序に混ざり、記録すること自体がリスクになる、という逆転が起こりえます。
記録を活かすうえで地味に効くのが、ログ同士を関連づける「たどれる構造」です。エージェントが複数ステップを実行する場合、1つの依頼に対して複数のログ行が発生します。これらを共通の相関IDで束ねておかないと、後から「この結果に至った一連の処理」を組み立て直すのに膨大な手間がかかります。相関IDで一連を追える設計は、事後調査の速度を大きく左右すると考えられます。
監査証跡としての価値は、記録が後から書き換えられていないという信頼に支えられます。追記のみ（append-only）を基本とし、誰がログにアクセスしたかもまた記録する、といった多層の設計が望まれます。保存期間は、業種の規制や社内規程、そしてストレージコストとのバランスで決める事項です。規制で保存年限が定められている領域もあるため、該当する場合は所管省庁や業界団体の最新の公表資料でご確認ください。
ツールごとにログの形式がバラバラだと、横断的なレビューが実務上ほぼ不可能になります。利用ログを社内のデータ集約基盤に一定の共通フォーマットで寄せ、検索・集計できる状態にしておくことで、はじめて「先月の全AI利用を俯瞰して逸脱を探す」といった運用が現実的になります。ここは内製の社内AIエージェント基盤を組む際に、最初から設計に織り込んでおきたいポイントだと考えます。
記録構造が整っても、人が定期的に見なければ監査には活きません。とはいえ全ログを人力で読むのは非現実的です。現実的なのは、まず機械的なルールで注目すべきログを絞り込み（例：機密区分の高いデータへのアクセス、承認なしで実行された高リスク操作、通常と異なる大量実行など）、それを人がサンプリング的に確認する、という二段構えだと考えられます。
レビューの責任者が曖昧だと、運用は必ず形骸化します。情シスが技術的な異常を、業務部門が業務妥当性を、内部監査が定期的な独立チェックを——というように役割を分けて明文化し、レビューの頻度と記録の残し方まで決めておくのが実務的です。この役割分担そのものが、利用ガイドライン作成の一部として文書化されているのが望ましい姿だと考えます。
レビューで見つかった逸脱やヒヤリハットは、指摘して終わりではなく、ガイドライン・権限設計・承認フローの見直しに還元して初めて意味を持ちます。「この操作は承認を必須にすべきだった」「この区分のデータは入力禁止に変えるべき」——こうしたフィードバックのループが回り始めると、ログは監査のための証跡から、運用改善のための資産へと性格を変えていくと考えられます。
実際に運用を始めると、設計段階では見えなかった問題が出てきます。正直に挙げておきます。ここを想定しておくかどうかで、立ち上げの摩擦が変わると考えます。
これらの多くは、技術より運用と合意形成の問題です。ツールを入れれば解決するというより、記録の目的と守備範囲を関係部門で握れているかが分かれ目になると考えます。
最初から全社・全ユースケースを完璧に記録しようとすると、たいてい設計だけで止まります。現実的なのは段階を踏むことだと考えます。以下は一つの進め方の例であり、自組織の規制環境・リスク許容度に合わせた調整が前提です。
まず今あるログが「後から追える形」になっているかを客観的に把握します。代表的なユースケースを1〜2個選び、実際に「先月のこの利用を経緯まで再構成できるか」を試してみると、記録の欠落が具体的に見えます。ここは机上の設計より、現物のログでの検証から始めるのが有効だと考えます。
再構成に必要な項目を法務・現場と合意し、集約基盤に寄せ、二段構えのレビュー運用と責任者を決めます。この段階で利用ガイドラインとの整合をとり、承認フローの記録も揃えます。小さな範囲で回して、無理のない頻度と粒度を実測で調整していくのが現実的です。
レビューの気づきをガイドライン・権限・承認設計に還す循環を作り、うまく回った運用を他のユースケースへ広げます。Nsightは、元キーエンス画像処理事業部で培った「現物・現場から逆算する」検証志向を土台に、社内AIエージェント基盤・業務OSの内製化とAI研修を通じて、この記録運用の立ち上げを伴走できると考えています。まずは自組織のログが説明可能な状態にあるか、確認するところからで十分だと考えます。
監査で再構成したい粒度と、機密保持の要請とのバランスで決める事項だと考えられます。入力全文の長期保存はログ自体が漏えいリスク源になりうるため、実行主体・日時・利用モデル・参照データ範囲・出力要約・承認記録などを中心に、目的から逆算して絞るのが現実的です。規制で保存年限が定められる領域もあるため、該当する場合は所管省庁の最新の公表資料でご確認ください。
収集と活用は別の設計だからだと考えられます。ログが断片的で相関IDなどで一連の処理として束ねられていないと、後から経緯を再構成できません。また誰がいつレビューするかが決まっていないと、逸脱を検知できず改善にも還元されません。取得は出発点であり、レビューと改善の運用が伴って初めて説明責任の土台になると考えます。
高リスクな操作の前に人間の確認を挟み、その承認・却下の事実をログとして残す設計が望まれます。これにより「確かに人が見て決めた」という主張の根拠を持てます。どの操作を承認必須にするかは、人間承認の設計とセットで検討し、承認記録を他の実行ログと相関IDで結び付けておくと事後調査が容易になると考えられます。
ツールごとに形式が異なると横断的なレビューが実務上困難になります。利用ログを社内のデータ集約基盤に共通フォーマットで寄せ、検索・集計できる状態にしておくことで、全利用を俯瞰して逸脱を探す運用が現実的になると考えられます。規模が増えるほど後からの統一は難しくなるため、早い段階での設計が有効だと考えます。
まず代表的なユースケースを1〜2個選び、実際に「先月のこの利用を経緯まで再構成できるか」を試すことをおすすめします。現物のログで検証すると記録の欠落が具体的に見え、必要な項目や運用が定まります。全社一斉より、小さく回して頻度と粒度を実測で調整する進め方が現実的だと考えます。現物・現場での検証が前提です。
「ログは取っている」の先——監査で経緯まで再構成できるか、承認記録は残っているか。まずは代表的なユースケースの現物ログで、説明可能性を一緒に確認してみませんか。記録の設計から改善ループの立ち上げまで、現場起点で伴走します。
AI利用ログの監査運用について相談する