ホーム / 記事
社内ルール労務

生成AIの利用ログを、どこまで取るべきか

公開 2026-10-27

入力した文章を全部記録して、管理者が読める状態にする。安全のためには合理的に見えます。ところが実際にやると、社員は会社のアカウントを使わなくなります。

取りすぎると使われなくなる

生成AIの利用ログをどこまで取るか。これは技術の問題ではなく、信頼の問題です。

入力した文章を全部記録して、管理者が読める状態にする。安全のためには合理的に見えます。ところが実際にやると、社員は使わなくなります。正確には、会社のアカウントでは使わなくなります。

個人のスマホで続きをやります。そして会社からは完全に見えなくなる。監視を強めたことで、把握できる範囲が狭まる。

監視を強めるほど、把握できる範囲は狭くなる ① ログを取らない 会社のアカウントで自由に使う。何が起きても追えない 事故時に説明できない ② 使った事実だけ記録する 誰が・いつ・どのサービスを使ったか。中身は見ない 社員は会社のアカウントを使い続ける 把握できる範囲が最大 ③ 入力内容を全部記録して管理者が読む 安全に見えるが、会社のアカウントが使われなくなる 個人スマホに移動し、ログがゼロになる 実質、把握できない ②が最も多くの情報を得られる。これは直感に反する
監視の強度と把握できる情報量は比例しない。強くしすぎると利用そのものが見えない場所へ移る。中庸が最も情報を得られる。

目的から決める

何のためにログを取るのか。目的によって必要な粒度が変わります。

目的必要なログ中身まで要るか
取引先に教育実施を示す受講記録。AI利用ログは不要要らない
どのサービスが使われているか知るサービス名とアカウント要らない
利用が定着しているか測る利用回数、部署別の分布要らない
事故が起きたとき範囲を特定する日時、利用者、できれば入力の概要場合による
規程違反を見つける入力した文章そのもの要る

上の4つは中身が要りません。大半の目的は、中身なしで達成できます。

中身が要るのは最後の1行だけ。そして、この目的を掲げた瞬間に監視になります。やるなら覚悟を決めて、やらないなら最初から取らない。中途半端が一番よくない。

法律上の論点

従業員が入力した文章を記録して閲覧する行為は、労務管理の文脈で整理が要ります。

一般に、業務用に貸与した端末やアカウントの利用状況をモニタリングすること自体は、目的が正当で、方法が相当で、事前に周知されていれば許容されると整理されています。逆に、周知せず秘密裏に行うと問題になりやすい。

個人情報保護委員会も、従業者の監督に関してモニタリングを実施する場合の留意点を示しています。実施責任者と権限の明確化、あらかじめ定めたルールの周知、実施状況の確認といった観点です。

◆ 最低限やること

何を記録するか、誰が見られるか、どういう場合に見るか。この3つを文書にして周知する。就業規則やセキュリティ規程に紐づけるなら、社労士に確認してください。

現実的な落としどころ

中小企業で回るのは、だいたいこの形です。

  1. 平常時は、使った事実だけを記録する(誰が・いつ・どのサービス)
  2. 中身は見ない。見ないことを明言する
  3. 事故の申告があったとき、または外部から指摘があったときに限り、責任者2名の承認で中身を確認する
  4. 確認した場合は、本人に事後に通知する

3番の「2名の承認」が効きます。一人で見られる状態だと、社員は信用しません。歯止めが見える形になっていることが大事です。

4番も入れておいてください。見たことを隠すと、後で分かったときに致命的です。

法人プランで取れるもの

主要なサービスの管理機能で、だいたい次のようなものが取れます。

利用者ごとのアクティビティ、会話数、使われた日時。管理者が会話内容にアクセスできる設定を持つものもあります。

導入時に、管理者が中身を見られる設定になっているかを確認してください。見られる状態で運用するなら、その事実を周知する必要があります。見られることを知らされていない状態が一番まずい。

ログを取る前に決めること

取り始めてから考えると、後戻りできません。先に決めてください。

生成AI利用のモニタリングについて(周知文の例)

会社が提供する生成AIサービスについて、以下の情報を記録します。

 ・利用者、利用日時、利用したサービス名、利用回数

入力した内容は、平常時には確認しません。
次の場合に限り、情報システム責任者と総務責任者の2名の承認のうえで確認します。

 ・情報の漏えいが疑われる事象が発生したとき
 ・取引先または外部機関から調査の要請があったとき
 ・本人から確認の依頼があったとき

確認を行った場合は、対象となった本人に事後に通知します。
記録の保存期間は〇年とし、期間経過後に削除します。

文面は顧問の社労士に確認してから使ってください。既存の規程との整合が要ります。

個人アカウントは、そもそもログが取れない

ここまで書いてきた話は、会社がサービスを契約している前提です。

社員が個人のアカウントで使っている場合、ログは1件も取れません。何を入れたかも、そもそも使っているかも分かりません。

だから順番としては、ログ設計より先に、会社のアカウントで使える状態を作るほうが先です。取れないログの設計を議論しても意味がない。

実態の把握方法は会社が把握していないAIの見つけ方に、会社として何を用意するかはガイドラインのひな形に書きました。

信用を削ると、情報が止まる

監視を強めた会社で何が起きるか。事故の報告が上がってこなくなります。

「入れてしまった」と言った瞬間にログを全部見られる、と思われたら、誰も言いません。黙って様子を見ます。そして発覚が半年遅れる。

ログを取る目的が「事故に早く気づくこと」なら、報告しやすさのほうが効きます。矛盾しているようですが、ここは本当にそうだと思っています。

無料・登録不要
生成AIに入れてはいけない情報 チェックリスト
この記事で書いた判断を、A4一枚にまとめてあります。 そのまま印刷して、生成AIを使う人のPCの横に貼れます。社名を入れ替えて社内で配っても構いません。
チェックリストを開く

信用を削ると、情報が止まる

ログを取る目的が「事故に早く気づくこと」なら、報告しやすさのほうが効きます。

AI Security Lab は、生成AIを業務で使う会社向けの eラーニングです。 何を入力してはいけないか、設定で防げる範囲はどこまでか、漏れたときに最初に何をするか。 中小企業の現場で実際に起きることを前提に組んでいます。

講座の内容と料金を見る

序章とレッスン01は無料で読めます。登録は不要です。

あわせて読む

社内AIチャットボットの権限設計
失敗する原因は精度ではありません。見せたくない文書を検索の対象から外していないことです。
会社が把握していないAIの見つけ方
社員が勝手に使っているAIのこと。禁止令を出すと見えなくなるだけで、なくなりはしません。
生成AIのインシデント報告書の書き方(ひな形つき)
原因分析から書き始めると、事実が推測に引きずられます。先に事実を固定する。