生成AIの使用ログはどこまで取るべきか｜監査で見られる範囲

生成AIを社内に入れたあと、必ず出てくるのが「使用ログはどこまで取るべきか」という問いです。情報システムや総務の立場では「何かあったときに追えないと困る」、一方で現場からは「入力した文章まで全部見られるのか」という反発が返ってきます。この記事は、その線をどこで引くかを決めるための判断軸をまとめたものです。

結論：ログは3層に分け、線を引くのは「プロンプト本文」から

結論から書きます。生成AIの使用ログは①利用メタデータ（誰が・いつ・どのツールのどの機能を使ったか）②プロンプト本文と出力 ③添付ファイルの中身の3層に分かれます。実務で破綻しない線引きは、①は全員・常時取る／②と③は原則取らず、目的と発動条件を決めたうえで条件つきに留めるという形です。

この線に置く理由は2つあります。1つは、インシデント調査の初動で本当に要るのは「誰が・いつ・どのサービスに触ったか」であって、本文は特定の調査に入ってから必要になるものだという点。もう1つは、プロンプト本文を保存した瞬間に、従業員のモニタリングとして目的の特定・社内規程への明記・従業員への明示が必要になる（個人情報保護委員会がモニタリングの留意点として示している内容）という点です。

つまり「どこまで取るか」は技術の問題ではなく、取った情報を説明できるところまでという運用の問題です。以下の判断表が、この記事の主役になります。

残す／残さない／条件つきの判断表

この表の肝は4行目です。「プロンプト本文を残さない」を既定に置くと、残すときだけ説明を用意すればよくなります。逆に「とりあえず全部取る」から始めると、取得済みのデータについて目的も閲覧者も保存期間も後追いで決めることになり、現場の納得を得にくくなります。

生成AIで実際に残せるログの4種類

線を引く前に、何が技術的に残せるのかを揃えておきます。「生成AIのログ」と一言で呼ばれているものは、中身がかなり違う4種類の集合体です。

1. 利用メタデータ（誰が・いつ・どのツールを使ったか）

最も取りやすく、最も使い道が広いのがこの層です。利用者のアカウント、日時、どのサービス・どの機能を使ったか、どこから操作したか（IPやデバイス）といった情報が入ります。

たとえば Google Workspace の場合、管理コンソールの「レポート」→「監査と調査」→「Gemini for Workspace ログイベント」から確認できます。公式ドキュメントが挙げている記録項目は、アクション、実行者（メールアドレス）、アプリケーション名、日時、イベント、イベントカテゴリ、機能の呼び出し元、IPのASN、デバイスIDなどです。本記事執筆時点（2026年10月）で公開されている属性一覧には、プロンプト本文そのものの項目は含まれていません。

ここが現場でよく誤解されるところです。「管理者はAIに打ち込んだ文章を全部読める」と思われがちですが、標準の監査ログで見えるのは利用の事実であって本文ではない、というのが多くのサービスの既定です。周知の場面では、この違いをはっきり伝えるだけで反発が小さくなります。

2. プロンプト本文と出力本文

本文まで取得するには、多くの場合法人向けの上位プランと、別途の仕組みが必要になります。

ChatGPT では、Enterprise・Edu 向けの OpenAI Compliance Platform が、認証ログ・アプリログ・監査ログなどに加えて会話の内容を取得する経路を提供しています。注目すべきは権限設計で、会話メッセージ（Conversation messages）へのアクセス権を付与できるのはワークスペースのオーナーだけとされており、管理者ロールを持っているだけでは自動的に本文が読めるようにはなっていません。また、同プラットフォームのログ保持は30日間と案内されています（本記事執筆時点）。

Claude では Enterprise プランで監査ログとComplianceの経路が用意され、データ保持期間を組織側で設定できる仕組みがあります。公式ドキュメントでは最低30日という下限と、保持設定の変更や削除といった操作が監査ログに記録されることが明記されています。

仕様は更新が早いので、導入検討時は必ず各社の公式ドキュメントで現状を確認してください。この記事の数字も「執筆時点のもの」として扱ってください。

3. 添付したファイル

生成AIの利用では、議事録・見積書・顧客リストといったファイルをそのまま読み込ませる使い方が増えます。ログとして残せる範囲は「ファイルをアップロードした事実とファイル名」までが取りやすく、中身の保存は本文と同じか、それより重い判断になります。

実務では、ファイルの中身をAI側のログに溜めるより、元のファイルがどこに置かれていたか（Drive や共有フォルダのアクセスログ）で追うほうが筋が通ります。生成AIのログだけで完結させようとすると、同じ情報を二重に抱えることになります。

4. 管理コンソールの監査ログとDLP

見落とされがちですが、ここが一番コスパのよい層です。設定変更・権限付与・外部共有・エクスポート操作といった管理者側の操作ログと、機密情報の外部送信を検知する DLP（Data Loss Prevention＝情報漏えい対策）の検知記録です。

「誰がAIに何を入力したか」を全件見るのではなく、「クレジットカード番号やマイナンバーらしき文字列が外に出ようとしたときに検知する」という形にすると、本文を保存しなくても危ない事象だけ拾える構えになります。中小企業ではこの組み合わせで十分に回ることが多いです。

プロンプト本文まで保存するかの判断軸

ここが「どこまで」の本題です。本文を取るかどうかは、次の2つを天秤にかけて決めます。

軸1：監査・インシデント調査で本当に必要か

「必要かもしれない」ではなく、使う場面を具体的に1つ書けるかで判定します。実務で本文が本当に要るのは、だいたい次のような場面です。

• 顧客情報の漏えいが疑われ、誰がどの情報を入力したかを特定して本人や取引先に説明しなければならないとき
• AIの出力をそのまま社外に出してしまい、何を根拠に生成されたかを遡る必要があるとき
• 取引先や親会社の監査で「入力内容の管理状況」の提示を求められたとき

逆に「利用状況を把握したい」「使いこなせているか知りたい」という目的なら、本文は要りません。利用メタデータの集計（何人が・週に何回・どの機能を使ったか）で足りるからです。目的を書いてみて「把握のため」としか書けないなら、本文は取らないのが正解です。

軸2：従業員のプライバシーと、労務上の説明責任

プロンプト本文は、業務の内容だけでなく、その人の悩み方・調べ方・書きかけの文章まで含みます。従業員のモニタリングに踏み込む領域なので、取れるかどうか（技術）ではなく、説明できるかどうか（労務）で判断する必要があります。

個人情報保護委員会は、従業者を対象とするモニタリングを実施する際の留意点として、ガイドラインに関するQ&A（Q5-7）で次の内容を挙げています。

• モニタリングの目的をあらかじめ特定し、社内規程等に定めて従業者に明示すること
• 実施に関する責任者とその権限を定めること
• あらかじめ実施に関するルールを策定し、その内容を運用者に徹底すること
• ルールに従って適正に行われているか確認を行うこと

加えて、個人情報の取扱いに係る重要事項を定めるときは、あらかじめ労働組合等へ通知して必要に応じ協議を行うことが望ましく、定めたときは従業者へ周知することが望ましいとされています。これらは「違反すると即座に罰則」という性格のものではなく、社内で決めておくべき論点の一覧として読むのが実務的です。最終的な適法性の判断は、自社の就業規則や労使の状況を踏まえて弁護士・社会保険労務士に確認してください。

軸3：本文を残さずに済ませる代替手段があるか

本文を取る前に、次の代替で目的が達せられないかを必ず検討します。現場で多いのは、代替で足りるのに本文取得まで走ってしまうパターンです。

そもそも入力する情報の線引きが固まっていないと、ログの設計は決まりません。入力してよい情報の範囲については生成AI業務利用の情報漏洩対策と、個人情報を入力してしまった場合の扱いを整理した生成AIへの個人情報の入力は漏えい報告の対象になるのかも併せて確認しておくと、判断がぶれません。

取得する前に必要な、社内への周知と同意の考え方

ログ取得でもめる原因は、技術設定よりも順番です。取ってから説明すると「黙って見ていたのか」という話になり、設定を戻しても信頼は戻りません。

実務では、次の順番で進めるのが安全です。

1. 何を取るかを決める（上の判断表で、残す／残さないを行ごとに決める）
2. 目的・閲覧者・保存期間・閲覧手順を文章にする（社内規程か、生成AI利用ルールの一節として）
3. 従業員に明示する（「利用の事実は記録しています。入力した文章は原則保存しません。保存する場合は○○のときだけで、見られるのは△△です」まで具体的に）
4. 労働組合等がある場合は事前に通知し、必要に応じて協議する
5. そのうえで設定を有効にする

同意については「全員から個別に同意書を取る」という形に走りがちですが、業務命令で使わせているツールの記録に個別同意を積み上げると、同意しなかった人の扱いが宙に浮きます。規程に書いて周知するという形をまず整え、本文取得のように踏み込むものだけ個別の説明を足す、という二段構えが現実的です。

なお、生成AIに個人情報を含むプロンプトを入力する場面については、個人情報保護委員会が生成AIサービスの利用に関する注意喚起（令和5年6月2日）で、個人情報取扱事業者に対し「特定された当該個人情報の利用目的を達成するために必要な範囲内であることを十分に確認すること」、そして本人の同意なく個人データを含むプロンプトを入力する場合は「当該個人データを機械学習に利用しないこと等を十分に確認すること」を求めています。ログ設計と入力ルールは、同じ文書の中でつなげて書くのがおすすめです。

ルール本体の書き方は生成AIの社内ルールの作り方に型をまとめています。ログの条項だけ単独で作ると浮くので、利用ルールの一節として差し込む形が収まりがよいです。

保存期間をどう決めるか

保存期間に「正解の日数」はありません。何のために使うログかで決まるので、目的ごとに逆算します。

ここで効いてくるのがサービス側の保持上限です。期間は自由に決められるわけではなく、「ベンダーが持っている期間」が実質の上限になります。

• Google Workspace の監査ログは、公式のデータ保持期間一覧で Gemini for Workspace のログイベントを含む多くのログが6か月とされています（本記事執筆時点）
• OpenAI の Compliance Platform のログ保持は30日間と案内されています（同）
• Claude Enterprise のデータ保持設定は最低30日から設定できるとされています（同）

したがって「1年分を監査で出せるようにしたい」なら、SIEM やログ保管先への定期エクスポートまで設計しないと成立しません。ここを詰めずに「保存期間は1年」と規程に書いてしまうと、規程と実態がずれた状態が続きます。規程に書く前に、管理コンソールで実際に何か月遡れるかを見ておいてください。

Mihataでは、AI導入支援の中でこうした設定確認を月1回のAIミーティングで一緒に画面を見ながら進めています。ログの要件を規程に落とす前に実機で確かめるだけで、後からの手戻りがかなり減ります。記事の途中で恐縮ですが、社内のAI運用を一緒に組み立てる独自AI開発・AI導入支援もお手伝いしておりますので、よろしければ合わせてご覧いただけたら嬉しいです。

無料アカウントと法人契約で、取得できる範囲はまるで違う

ログ設計で最初に突き当たる壁がここです。従業員が個人アカウントの無料プランで使っている限り、会社側にログは1行も残りません。

この表から導かれる結論は単純です。ログの話をする前に、業務利用を会社アカウントへ寄せる。そこが済んでいないのに「どこまで取るか」を議論しても、紙の上の話にしかなりません。

現場で多いのは「ルールで個人アカウントの業務利用を禁止した」で止まっているケースです。禁止しただけでは守られているかを確認できないので、会社アカウントを配って、そちらのほうが便利な状態を作るところまでをセットにしてください。機能が劣る会社アカウントを渡して個人利用を禁止すると、ほぼ確実に抜け道が使われます。

「取っているだけ」のログは、取っていないのと同じ

ログ設計で最も多い失敗は、取得範囲を決めて設定したあと、誰も見ないまま数か月が過ぎることです。ログは見る運用まで決めて初めて意味を持ちます。

決めることは4つだけです。

• 誰が見るか：情報システム担当と、もう1名（一人だけにしない。本人の操作を点検できる人を置く）
• いつ見るか：月1回・15分で十分。日付を決めて予定に入れる
• 何を見るか：新しく使い始めた人、急に利用が増えた人、DLPの検知、管理者権限の変更の4点
• 見たことをどう残すか：確認日・確認者・気づいた点を1行ずつ。本文を閲覧した場合は、その理由と承認者も記録する

この最後が抜けやすいところです。ログを見た事実そのものを記録に残すと、「必要があって見た」ことを後から説明できます。個人情報保護委員会が示している「ルールに従って適正に行われているか確認を行うこと」は、まさにこの点を指しています。

政府側のガイドラインも、記録の整備を透明性・アカウンタビリティの文脈で位置づけています。総務省・経済産業省のAI事業者ガイドラインは、AIの開発者・提供者・利用者が守るべき「共通の指針」を示しており、その中に透明性とアカウンタビリティが含まれます。関係者に説明できる状態を作ることがログの目的だと捉えると、「全部取る」でも「何も取らない」でもない中間解に落ち着きます。ガイドラインの改定動向は政府の生成AIガイドライン改定2026の読みどころにまとめています。

中小企業で現実的に回る最小構成

専任の情報システム担当がいない規模でも回る構成を、順番つきで挙げます。上から順に埋めれば、監査で聞かれたときに説明できる状態になります。

1. 業務利用を会社アカウントへ寄せる。無料・個人アカウントでの業務利用は禁止し、代わりに会社アカウントを配る
2. 取るのは利用メタデータと管理コンソールの監査ログだけにする。設定は既定のまま、追加費用なしで始まる
3. プロンプト本文は「原則取らない」と明文化する。あわせて、漏えいの疑いなど取得する場面の条件・承認者・閲覧者を書く
4. DLPで機密情報の外部送信を検知する。全文を読むのではなく、危ない事象だけ拾う構えにする
5. 申請・承認フローと台帳を作る。何に使うかを申請時に書かせておくと、ログを本文まで掘らなくても用途が追える
6. 月1回15分のレビュー担当を決める。確認日・確認者・気づきを1行記録する
7. ここまでを従業員へ周知する。「記録するのは利用の事実」「本文は原則保存しない」をはっきり伝える

5番目の申請・承認は、ログの負担を軽くする効果があります。用途が台帳にあれば、本文を保存しなくても「何のために使ったか」を説明できるからです。ログと申請はセットで設計してください。具体的な作り方は生成AIの利用申請と承認フローの作り方にまとめています。

よくある失敗3つ

1. 取れるものを全部取ってから考える

一番多い失敗です。取得した瞬間に、目的・閲覧者・保存期間の説明責任が発生します。後から「実は目的を決めていませんでした」とは言えません。設定を有効にする前に、判断表を1行ずつ埋めてください。

2. 無料アカウントのまま、ルールだけで縛る

ログが取れない状態でルールを作っても、守られているかを確認できません。ルールと技術のどちらかしかない状態は、「管理しているつもり」という一番危ない形になります。会社アカウントへの寄せ替えを先にしてください。

3. 取ったログを誰も見ない

月1回15分でよいので、見る日と見る人を決めます。見ないログは、容量と説明責任だけが増えて、リスクは1つも減りません。棚卸しの場を作ると、同時に「この使い方は便利だ」という発見も拾えるので、見る運用はセキュリティだけでなく活用の側にも効きます。

まとめ：線は「本文の手前」に引き、説明できる範囲に留める

生成AIの使用ログをどこまで取るかの答えは、利用メタデータと管理操作のログまでを既定とし、プロンプト本文と添付ファイルの中身は目的・閲覧者・保存期間・周知が揃ってから条件つきで取るです。保存期間は目的から逆算し、ベンダー側の保持上限（本記事執筆時点で、Google Workspace の監査ログは6か月、OpenAI の Compliance Platform は30日、Claude Enterprise は最低30日から設定）を踏まえて、超える分はエクスポートまで設計します。

そして、取ったら見る。月1回15分のレビューと、見たことの記録まで決まって初めて、ログは監査に耐える資料になります。

自社の状況だと線をどこに引くべきか、設定画面で何が取れているのか、規程の文言をどう書くか。この3点は、実際の管理コンソールを一緒に見ながら決めるのが一番早いところです。Mihataでは月1回のAIミーティングという形で、ルールづくりから設定の確認、現場への周知まで並走しています。もし社内で止まっている論点があれば、お気軽にご相談ください。