社内の生成AIの利用ログを毎月点検して、渡してはいけない情報の入力を見つける

処理の起点を決める

毎日決まった時刻を起点にします。Schedule Trigger ノードで、日単位の間隔に「Trigger at Hour」「Trigger at Minute」を指定します。深夜ではなく、出社前の早朝に動かすのが扱いやすいです。失敗したときに、その日のうちに気づけます。

月次の集計は、同じワークフローに2つ目のトリガールールを足して行います。ノードは1つのまま、日次と月次を持てます。

Schedule ノードをトリガーに使うワークフローは、保存したうえで公開する必要があります。 保存だけでは動きません。

入力データを集める

社内ルールを入れることが要です。 ルールの条項が渡っていないと、AIは一般論で「機密情報が含まれます」としか言えません。「第4条2項の、顧客名の入力禁止に当たる」と返せて初めて、担当者の突き合わせ3分が消えます。

データの取得方法を決める

対話の記録： 統合監査ログから取得します。イベントは DSPM for AI の「AI アクティビティ」タブとアクティビティ エクスプローラーでも表示できるので、まず画面で中身を見てから、取得の実装に入ってください。 どの項目が入っているかが分かります。

取得の範囲： 前日分だけを取ります。1日ずつ区切ることで、失敗したときの再実行が簡単になります。

社内ルール： 条項番号と本文を、機械が読める形に整えて持ちます。文書をそのまま渡さず、条項ごとに分けます。 根拠として条項番号を返させるためです。

AIへ渡す前に整形する

1. 一次のふるい … 機密情報の種類の検出結果がある、秘密度ラベルが付いたファイルを参照している、対象部門に属する、のいずれかに当たる対話だけを残します。ここで数万件が数百件になります
2. 仮名化 … 利用者の氏名を識別子に置き換えます。判定の段階では誰の入力かを見ません
3. 重複の除去 … 同じ内容を繰り返し入力している対話をまとめます。1人が同じ貼り付けを10回していれば、1件として扱います
4. 長さの調整 … 対話が長い場合、機密情報の種類が検出された前後を中心に切り出します。全文を渡さないことが、後の第13章の設計にもつながります
5. 既知の例外の除外 … 一次のふるいで毎回当たるが問題にならないもの（社内のテストデータなど）を、あらかじめ除きます

AIに処理させる

一次のふるいで拾えるのは、形のある情報だけです。 番号や記号の並びは機械的に見つかりますが、「A社の来期の値下げの方針」のような、形の無い秘密はパターンに引っかかりません。ここがAIの担当範囲です。

区分は次の6つに固定します。自由記述にしません。

unclear を必ず置きます。 断片的な対話は、それだけでは判断できません。無理に区分を選ばせると、none に倒れます。 判定を確定させず、人が読む逃げ道を作ります。

指示内容を固定する

あなたは社内の生成AI利用ログを点検する担当者を支援する立場です。
対話の内容が、社内の生成AI利用ルールに照らして問題があるかを判定してください。

【厳守事項】
- 対話に書かれていないことを推測しないでください。
  「おそらくこの会社のことだろう」という補いをしないでください。
- 区分は次の6つからだけ選んでください。新しい区分を作らないでください。
  personal_data / third_party_confidential / internal_unpublished /
  credentials / none / unclear
- 文脈が足りず判断できない場合は unclear にし、
  何が足りないかを reason に書いてください。推測で none にしないでください。
- 根拠には、渡した社内ルールの条項番号を必ず書いてください。
  該当する条項が見つからない場合は「該当条項なし」と書いてください。
  条項の内容を作らないでください。
- quote には、判断の根拠になった部分だけを最小限で入れてください。
  対話の全文を写さないでください。氏名・電話番号・口座番号などは
  伏せ字にして入れてください。
- alternative には、同じ仕事を社内ルールの範囲で行う方法を書いてください。
  「入力しないこと」とだけ書かないでください。
- 利用者の人物評価、意図の推測、悪意の有無に関する記述を書かないでください。
- 判定に迷いがある場合は needs_human を true にしてください。

【社内ルール（条項番号つき）】
{policy_clauses}

【対話（仮名化済み・部門のみ付与）】
{conversation}

【一次のふるいで検出された機密情報の種類】
{detected_sit}

「条項の内容を作らないでください」は必須です。 根拠を書けと指示すると、それらしい条項番号を作ることがあります。存在しない条項を根拠にした注意喚起は、現場の信頼を一度で失います。

「人物評価を書かない」も外せません。 この仕組みは社員の入力を読みます。出力に人物評価が混じると、点検が人事の材料に見えてしまいます。

出力形式を固定する

{
  "conversation_id": "",
  "user_ref": "",
  "department": "",
  "category": ["personal_data | third_party_confidential | internal_unpublished | credentials | none | unclear"],
  "severity": "high | medium | low",
  "quote": "",
  "reason": "",
  "alternative": "",
  "needs_human": true
}

構造化する理由は、月次で数えるためです。 文章のままだと、「先月は third_party_confidential が何件だったか」「どの部門に偏っているか」が数えられません。この仕組みの目的は個々の摘発ではなく、傾向をつかんでルールと設定を直すことなので、数えられる形にしておく必要があります。

user_ref には氏名ではなく仮名化した識別子を入れます。傾向を見るのに氏名は要りません。

alternative を出させることが、この構成の値打ちです。「入れてはいけない」で終わらせず、「顧客名を伏せ字にすれば同じ結果が得られる」と返せば、現場が使い方を変えられます。注意喚起の文面にそのまま使えます。

システムへ連携する

点検リストの保管先と、注意喚起の連絡手段は、社内の既存の仕組みに合わせてください。判定結果を人事システムや評価の仕組みに自動で流し込む連携は作らないでください。

人が確認する

全件、人が確認します。 AIの判定だけで本人に連絡することはありません。

確認の順番を設計します。

• needs_human が true のものを最上位に出す
• unclear を次に出す（ここがいちばん人の時間を使うべき場所です）
• severity が high のものをその次に
• none は一覧に残すが、開かない（件数を数えるためだけに残します）

確認の画面には、quote と reason と該当条項を同じ画面に並べます。 条項を別の文書で開かせると、突き合わせの3分が戻ってきます。

確認にかかる時間の目標は、1件3分です。 それ以上かかるなら、社内ルールの条項の粒度が粗いか、一次のふるいが緩すぎて none が大量に混じっています。

例外に対処する

記録を残す

• 判定の入力（仮名化した対話の識別子と、渡した範囲）
• AIの判定結果（区分・重大度・根拠・引用・代わりのやり方）
• 人が判定を変えた箇所と、変えた理由
• 本人へ連絡したかどうかと、その日付
• ルール・設定の見直しにつながったかどうか
• 月次の集計（区分別・部門別の件数）

3つ目が改善の材料になります。人が毎回 internal_unpublished を none に直しているなら、社内ルールの条項がその業務の実態と合っていません。 プロンプトではなくルールを直す場面です。

保存期間を最初に決めてください。 生成AIのプロンプトと応答は、データライフサイクル管理のアイテム保持ポリシーで自動的に保持または削除できます。点検の記録を無期限に持たないという判断を、先に文書にしておきます。