AI活用ナレッジ
公開
更新

生成AIの利用ログ管理で危険リクエストを見える化する 月次で見る3つの安全指標

生成AIの利用ログは、社員を見張るためではなく、危ない使い方を早く直すために使います。
月次で見る3つの指標から始めると、ルール改善に落とし込みやすくなります。

生成AIの利用ログ管理で危険リクエストを見える化する 月次で見る3つの安全指標

生成AIの利用ログ管理は、社員の会話を細かく読むための仕組みではありません。会社として見るべきなのは、危険な使い方がどの業務で増えているか、そして未処理のアラートが残っていないかです。
ログを月次の安全点検に変えると、情報漏洩の不安を「なんとなく怖い」で止めず、次に直すルールや教育へつなげられます。

最初から全プロンプトを読み込む必要はありません。まずは、危険リクエスト率機密入力の疑い件数未処理アラート/例外対応日数の3つを月次で見ます。
個人監視に見える運用へ寄せないことが、生成AIログ管理を続けるうえでの分かれ目です。

要点月次で見るのは「危険率・機密疑い・未処理」

生成AIの利用ログ管理は、危険リクエスト率機密入力の疑い件数未処理アラート/例外対応日数の3指標から始めます。社員の全発言を読むのではなく、業務単位で迷いとルール不足を見つけるための点検です。

生成AIの利用ログ管理は社員監視ではなく安全運用の月次点検

生成AIのログを取る目的は、誰かを罰することではありませんどの部署、どの業務、どの入力パターンで危険が増えているかを見つけ、ルールやテンプレートへ戻すことです。
ここを曖昧にすると、ログ管理はすぐに「社員を見張る仕組み」と受け取られます。

デジタル庁のログ取得・分析導入ガイドブックでも、ログは「いつ、誰が、何をしたのか」を調べ、通常と異なる動きを判断するための材料として整理されています。生成AIでも同じで、ログは発見と検証の道具であって、ログだけで情報漏洩を完全に防げるわけではありません。

出典: デジタル庁「ログ取得・分析導入ガイドブック」PDF

⚠ 監視に見える運用
個人名で犯人探しをする/全プロンプトを読む/危険率だけを下げにいく。→ 社員が生成AIを避け、ログから逃げる。
VS
✓ 安全点検として続く運用
部署・業務単位で見る/見ない項目を明文化/ルールと教育に戻す。→ 安全な使い方が増える。

見たいのは「誰を罰するか」ではなく「どこで迷っているか」

危険リクエストは、社員の悪意だけで起きるものではありません。入力禁止情報が曖昧で、契約書や顧客リストをどこまでAIに渡してよいか分からない時にも増えます。
そのため月次レビューでは、個人名よりも業務カテゴリとリクエスト分類を先に見てください。

すでにAIツールの利用者や契約形態が整理できていない場合は、先にAIツールの権限棚卸しを進めると、ログを見る対象が絞りやすくなります。ログ管理と権限台帳は別作業に見えますが、誰の利用をどの範囲で確認するかを決める土台は同じです。

先に入力禁止情報と許可ツールを決める

ログを取っても、社内で何が違反なのかを決めていなければ、危険リクエスト率は測れません。まずは顧客情報、個人情報、契約/法務文書、未公開財務情報、認証情報/ソースコードのように、入力禁止情報を言葉で分けます。

AI事業者ガイドラインでは、AIを利用する側にも適正利用やリスク理解が求められる立場としての役割があります。会社として生成AIを使うなら、許可ツールと入力禁止情報を決めないままログだけ集めるのは順番が逆です。

出典: 総務省・経済産業省「AI事業者ガイドライン第1.2版」PDF

注意ログを取る前に「違反の定義」を置く

危険リクエスト率は、分母と分子を決めて初めて使えます。許可ツール、入力禁止情報、例外申請のルートが曖昧なままでは、ログを見ても改善すべき業務を特定できません。

生成AIログで最低限見る項目

生成AIのログ項目は、製品や契約でかなり差があるため、最初は細かいUI名を追うより、自社の月次レビューに必要な列へ落とし込むほうが実務に乗ります。
取れない項目は「今後確認」で残さず、月次指標から外すか、別のメタデータで代替してください。

生成AIログ管理で最初に確認するログ項目の表
最初は、月次レビューで判断に使う列だけを確認します。

ログ項目の初期一覧

項目見る内容使い道注意点
利用者氏名
部署
業務単位で集計個人評価に直結しない
日時利用日
時間帯
急増を検知月次推移で見る
ツールChatGPT
Copilot等
対象範囲を分ける個人契約は別管理
参照先ファイル
フォルダ
権限外参照を確認取れない製品もある
警告結果DLP
ブロック
危険率を算出誤検知も分類
対応状況未処理
確認済み
放置を減らす担当者を決める

ログ項目を増やしすぎると、レビューが続きません。初期段階では、月次で見て意思決定できる項目だけに絞ります。
社内利用のムダや利用量も合わせて見たい場合は、ChatGPT社内利用の管理で扱った「監視にしない見方」と同じく、部署単位の傾向から入るのが安全です。

プロンプト本文まで取れるとは限らない

管理者が見られるログの粒度は、製品、契約、権限、保持設定で変わります。どの生成AIでも全プロンプト本文を読めると考えるのは危険です。
プロンプト本文、レスポンス本文、参照ファイル、DLP結果、利用量を同じログ項目として扱わず、取れるものと取れないものを分けてください。

社内データをAIに渡す場合は、ログ項目だけでなく生成AIに社内データを学習させない設定も確認しておくと、入力データと保存先を分けて考えやすくなります。学習オフログ保管は別の論点です。

警告ログ自体にも機密が含まれる

プロンプト本文や添付ファイル名を保存する場合、ログ保管先にも機密情報が残ります。ログ管理を強めるほど、ログを見られる人、保存期間、削除ルールを同時に決めてください。

月次で見る3つの安全指標

生成AIの安全指標は、多くしすぎるほど見られなくなります。最初の月次レビューでは、危険リクエスト率、機密入力の疑い件数、未処理アラート/例外対応日数に絞ってください。
この3つなら、経営者や管理部門でも「ルールを直すのか、教育を直すのか、権限を直すのか」を判断しやすくなります。

生成AIログ管理で月次確認する3つの安全指標
危険率、機密疑い、未処理を分けると、次に直す場所が見えます。

月次3指標の見方

指標見るもの増えた時改善先
危険率危険分類の割合ルールが曖昧禁止情報
テンプレ
機密疑いDLP
ファイル名
入力前対策不足権限
教育
未処理放置件数
日数
担当不在一次対応
承認

危険リクエスト率は、全リクエストのうち危険分類に入ったものの割合で、業界平均との差を競うための指標ではありません自社の前月比と部署別の偏りを見て、どのルールや教育を直すか判断するための数字です。

機密入力の疑い件数は、顧客名、個人情報、契約書原文、未公開数字、認証情報、ソースコードなどが入力や添付に混じっていないかを見る指標です。件数が多い部署を責めるのではなく、入力前に止めるルールとテンプレートが足りているかを見ます。

未処理アラート/例外対応日数は、ブロック、警告、管理者確認、DLP検知、AIエージェント実行失敗などが、何日放置されたかを見る指標です。ここが残る場合、技術設定よりも対応体制の問題が起きています。

実務危険率と利用率をセットで見る

危険リクエスト率だけを下げようとすると、社員が生成AIを使わなくなる方向へ寄りがちです。安全な使い方が増えているかも合わせて見ると、統制と活用のバランスを取りやすくなります。

危険リクエストをどう分類するか

危険リクエストは、単に「悪いプロンプト」と呼ぶだけでは運用に使えません。入力、参照、外部送信、実行の4領域に分けると、どの対策へ戻すべきかが見えます。
プロンプトの文面そのものより、リスクが起きる場所で分類するのがコツです。

生成AIの危険リクエストを入力参照外部送信実行で分類する表
危険リクエストは、文面よりもリスクが起きる場所で分けます。

初期分類は4領域で足りる

  • 入力: 顧客情報、個人情報、契約書、認証情報、未公開数字を入れていないか
  • 参照: 権限外のファイル、共有フォルダ、CRM、Slack履歴を読ませていないか
  • 外部送信: 外部メール、公開ページ、顧客向け返信へ未承認で出していないか
  • 実行: AIエージェントが作成、更新、削除、送信を勝手に進めていないか

OWASPの生成AI向けリスク分類でも、Prompt Injection、Sensitive Information Disclosure、Excessive Agency、Unbounded Consumptionなどが挙げられており、社内の月次レビューでは、これらをそのまま専門用語で並べるより、入力漏れ、権限外参照、外部送信、過剰実行のように業務の言葉へ直すと伝わりやすくなります。

出典: OWASP GenAI Security Project「LLM Top 10」(英語)

情報漏洩の実例や入力ルールの考え方は、チャットGPT情報漏洩のリスク回避策ともつながります。ログ分類を作る時は、事故例を怖がるだけでなく、どの入力を止めれば再発しにくいかへ変換してください。

回避危険リクエストを個人のミス一覧にしない

危険分類を個人別ランキングにすると、社員はログを避ける方向に動きます。月次レビューでは、部署別・業務別・入力分類別に集計し、ルール改善やテンプレート整備へ戻してください。

製品別に確認したいログ取得範囲

ログ管理で最も危ない思い込みは、契約中のAIなら必要なログは全部取れるという考え方です。Microsoft 365 CopilotChatGPT Enterprise/Edu、社内AIチャット、AIエージェントでは、取れるログ項目と保持期間が変わります。

製品ごとのUI名を暗記するより、ユーザー、日時、操作、参照ファイル、プロンプト本文、レスポンス本文、DLP結果、保持期間、エクスポート可否の9項目で確認表を作るほうが、後からツールが増えても崩れません。

Microsoft 365 Copilotはaudit logとAI interactionの範囲を確認する

Microsoft Learnでは、Microsoft 365 Copilot関連の監査ログ活動として、CopilotInteractionやAIEnterpriseInteractionsExportedなどが整理されています。利用サービスや参照ファイルの情報、プロンプト本文の扱いは確認経路が分かれるため、audit logで見える項目と、別機能で見る項目を混ぜないことが大切です。

出典: Microsoft Learn「Audit log activities」(英語)

ChatGPT Enterprise/Eduは保持期間と連携先を確認する

OpenAIのCompliance Platformは、Enterprise/Edu向けにChatGPT workspaceのログやメタデータをeDiscovery、DLP、SIEMへ接続するための仕組みとして案内されています。一方で、Compliance Logs Platformの保持期間は30日とされており、長く残したいなら継続的な取得が必要です。

ここで大事なのは、ベンダー側にいつまでも残っているはずと思い込まないことです。自社で月次レビューや監査対応に使うなら、誰が、どこへ、どの頻度でエクスポートするかを決めてください。

出典: OpenAI Help Center「Compliance Platform for Enterprise and Edu Customers」(英語)

社内の生成AI利用ルールをまだ作っていない場合は、生成AIの社内利用ガイドラインの作り方で、許可ツール、入力禁止情報、承認ルートを先に決めるとログ設計が楽になります。ログ取得範囲は、ルールの後に決めるほうがズレません。

メモGoogle Workspace GeminiやClaude一般チャットの全プロンプト監査ログについては、今回確認できた公式一次情報だけでは断定しません。本文では、製品固有の未確認仕様を前提にせず、取得項目を確認する表に落とします。

社員に嫌がられない運用ルール

生成AIのログ管理は、説明の仕方を間違えるとすぐに反発されます。社員から見れば、仕事の相談や下書きの試行錯誤を全部読まれるように感じるからです。
だからこそ、見る項目、見ない項目、見る理由を先に明文化してください。

個人評価ではなく部署・業務単位で見る

月次レビューの基本単位は、個人ではなく部署や業務カテゴリです。たとえば「営業部で契約書原文の貼り付けが多い」なら、社員名を追う前に、契約書をAIに渡さず要約するテンプレートを用意できないか考えます。

AIエージェントのように送信や更新まで行う仕組みでは、AIエージェントの承認フローで整理したように、閲覧、提案、実行を分ける必要があります。実行権限のログだけは、通常のチャット利用より重く扱うのが安全です。

見る項目と見ない項目を明文化する

  • 見る項目: 危険分類、ブロック結果、未処理アラート、参照ファイル種別
  • 原則見ない項目: 低リスクの日常的な下書き、個人の試行錯誤、分類不要の雑談
  • 例外確認: 顧客情報、個人情報、認証情報、外部送信、削除や送信を伴う実行
  • 説明方法: 個人評価ではなく、入力ルールとテンプレート改善のために使うと明記する

AIブラウザ操作や外部送信を伴う業務では、AIブラウザ操作のリスクも合わせて確認してください。チャットだけなら閲覧で済む場面でも、ブラウザ操作AIはフォーム入力や送信まで進めるため、ログと承認の境界が変わります。

共有「見ない項目」を決めると協力を得やすい

ログ管理の説明で大切なのは、監視対象を増やすことではなく、社員が安心して使える線引きを作ることです。見る項目だけでなく見ない項目も明記すると、月次レビューが改善活動として受け止められやすくなります。

最初の30日で作るログ管理の小さな仕組み

いきなりSIEMやDLP連携まで作り込む必要はありません。最初の30日は、許可ツール、入力禁止情報、サンプル分類、月次レビュー表を作るだけでも十分に前へ進みます。
目的は、完璧な監査基盤ではなく危険な使い方に気づいて直せる最小の運用を持つことです。

生成AIログ管理を最初の30日で作る手順
30日目のゴールは、完璧な基盤ではなく月次で直せる最小運用です。

30日で進める初期手順

1週目: 許可する生成AIツールと、入力禁止情報を決めます。
2週目: 取れるログ項目を製品ごとに確認し、取れない項目は月次指標から外してください
3週目: 10件程度のサンプルログを分類し、危険リクエストの分類名を整えます。
4週目: 危険リクエスト率、機密入力の疑い件数、未処理アラート/例外対応日数を1枚の月次表にしてください。

この手順なら、無料版や個人契約の混在が残っていても、何が見えていて何が見えていないかを説明できます。見えていないログを推測で埋めないことも、信頼できる管理の一部です。

まとめ

生成AIの利用ログ管理は、危険な使い方を月次で見つけて直す運用である

生成AIの利用ログ管理とは、社員の全発言を監視することではなく、危険リクエスト、機密入力、未処理アラートを月次で確認し、ルール・権限・教育を改善するプロセスです。まずは3指標に絞り、個人評価ではなく業務改善に使う前提を社内に共有してください。

生成AIの利用ログ管理でよくある質問

Q生成AIの利用ログ管理では何を見ればよいですか?

A生成AIの利用ログ管理では、ユーザー、日時、利用ツール、参照ファイル、警告/ブロック結果、危険リクエスト分類を見ます。最初から全プロンプトを読むのではなく、月次で危険な傾向を見つける形が現実的です。

Q危険リクエストとは何ですか?

A危険リクエストとは、機密情報、個人情報、認証情報、権限外ファイル、外部送信、プロンプトインジェクション誘導、AIエージェントの過剰実行など、事業上の損失につながりやすい依頼を指します。

Q月次で見るべき安全指標は何ですか?

A月次で見るべき安全指標は、危険リクエスト率、機密入力の疑い件数、未処理アラート/例外対応日数の3つです。業界平均ではなく、自社内の前月比と部署別の偏りを見ます。

Q社員のプロンプトを全部読む必要はありますか?

A社員のプロンプトを全部読む運用は現実的ではありません。分類、集計、しきい値で傾向を見て、高リスク例外だけを人が確認する形から始めると、個人監視に寄りにくくなります。

QChatGPT Enterpriseならログは取れますか?

AChatGPT Enterprise/Edu向けにはOpenAI Compliance Platformがあります。ただし保持期間や連携先の設計が必要なため、自社で長期保管する場合は継続的な取得を前提に確認してください。

QMicrosoft 365 Copilotの利用ログは確認できますか?

AMicrosoft 365 Copilotの利用ログは、Microsoft 365 audit logにCopilotInteractionなどの活動が記録されます。プロンプト本文の扱いはContent SearchやAI interaction eventなど、製品機能と権限の確認が必要です。

Qログ管理を始める前に決めることは何ですか?

Aログ管理を始める前に、許可ツール、入力禁止情報、取得するログ項目、見る担当者、月次レビューの場、例外対応ルートを決めます。違反の定義がないままログだけ集めても、改善につながりません。

Qログ管理は情報漏洩を完全に防げますか?

Aログ管理だけで情報漏洩を完全に防ぐことはできません。ログは発見と検証の道具であり、入力前のルール、DLP、権限管理、教育、承認フローと組み合わせて効果を出します。

GLOSSARY

AI用語集

1899 語を収録

意味の解説から背景の意外な逸話まで、AIの専門用語を一語ずつ。非エンジニアの視点で噛み砕いた、引くほど詳しくなる用語集です。

用語集を見る