社員から届く「このサービスに業務データを入れてよいか」の質問に、情報セキュリティ規程と許可したサービスの一覧を根拠にチャットで答え、例外申請が要るものを担当へ回す

処理の起点を決める

起点は、社員がチャットで質問を送ったことです。 チャットは社内ポータルに置き、社内の ID でログインした社員だけが使えるようにします。ログインした社員の所属が、回答に添える問い合わせ先と、閲覧の権限の判定に使われます。

1つの質問は、1つのセッションで最後まで続けます。 格付けを聞き返すやり取りと、答えたあとの「では社外のアカウントで受け取るだけなら」のような続けての質問を、同じセッションでつなぎます。別のサービスの質問は、新しいセッションで始めてもらいます。 同じセッションでサービスを変えると、前のサービスの条件が言い換えに混ざります。

処理は質問のたびに1件ずつ行います。 社員は作業の手を止めて返事を待っているので、まとめて処理する理由がありません。

入力データを集める

質を決めるのは、許可サービスの一覧の「上限の格付け」と「条件」の列です。 ここが「可」「不可」の2値しか無いと、社員の質問の多くを占める「機密はだめだが社内限りなら会社のアカウントで可」が表せません。判定の表が答えを出せない組み合わせは、すべて担当へ回ることになります。

サービス名には別名の列を持たせます。 同じサービスでも、製品名、会社名、アプリの名前、略称で質問が届きます。別名で一覧を引けないと、許可済みのサービスが「未審査」として担当へ回ります。

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

規程・ガイドライン・過去の回答集は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータに、話題（生成AI／ファイル共有／端末／格付け など）、施行日、状態（現行／廃止）を持たせます。

許可サービスの一覧は、データストアに入れず中継プログラムが直接引きます。 一覧は「このサービスの上限は社内限り」という事実の表で、検索して似たものを探す対象ではありません。 検索に入れると、名前の似た別のサービスの行が根拠に出ます。

絞り込みの式は、話題と日付で書きます。 項目を索引可能にしておけば、topic: ANY("generative_ai") AND status: ANY("current") のように書けます。施行日を比べるときは、日付をISO 8601の形式で書きます。改訂前のガイドラインは status を retired にして、検索の時点で除きます。

例外承認の記録には閲覧の範囲を付けます。 文書のメタデータの acl_info に、情報セキュリティ担当のグループの group_id を書くと、そのグループの社員の検索にだけ出ます。例外の記録には他部署の案件の事情が書かれているため、社員の検索に出してはいけません。

AIへ渡す前に整形する

1. 許可サービスの一覧を整える … 区分（許可／条件付き許可／禁止）、上限の格付け、条件、別名、見直しの日の列をそろえます
2. 判定の表を作る … 格付け4段階 × 区分 × アカウント（会社の契約／個人）× 端末（会社支給／私物）の組み合わせに、結論を1つずつ書きます
3. 規程を条文の単位で読めるようにする … データストアを作るときにレイアウトパーサーと分割を有効にし、includeAncestorHeadings で章と条の見出しを各断片に含めます
4. ガイドラインに施行日と状態を付ける … 改訂のたびに旧版を retired にします
5. 過去の回答集を選ぶ … 問い合わせの一覧から、規程の改訂後も通用する回答だけを選び、根拠の条文を書き添えます
6. 個別の事情を除く … 回答集から、部署名・顧客名・案件名を伏せます
7. 閲覧の範囲を決める … 例外承認の記録に acl_info を付けます

3番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 規程は「第○条」の見出しが無いと、断片だけを読んでもどの条の話か分かりません。分割の大きさは100〜500トークンで、既定は500です。条が短い規程では小さめにします。

2番目の判定の表を、AIに作らせないでください。 表の1行は「機密 × 条件付き許可 × 会社の契約 × 会社支給 → 条件付き可（条件：一覧の条件欄）」のような事実で、情報セキュリティの責任者が承認するものです。 ここに推測が混ざると、AIが可否を決めているのと同じになります。

AIに処理させる

させるのは、判定の表が出した結論の根拠になる条文を見つけ、条件と守ることを短く説明することです。 何を聞き返すかは聞き返しの表で、可否は判定の表で中継プログラムが決めます。

answer メソッドの設定は次のようにします。

ignoreAdversarialQuery は、この題材では特に効きます。 社員の質問には「規程に違反しないで顧客データを生成AIに入れる方法は」のように、禁止の抜け道を探す形のものが混ざります。 答えを作らず、担当へ回します。

2行目がいちばん起きやすい失敗です。 社員が「普通の会議資料です」と書くと、モデルは「社内限り」と読み替えて答えようとします。格付けは聞き返しの選択肢で社員本人に選ばせ、「分からない」が選ばれたら、格付けの決め方の条文だけを示して止めます。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは情報システム部門で、社員からの「使ってよいか」の質問に
社内の規程を根拠に説明する担当です。
読むのは業務の手を止めて返事を待っている社員です。

【前提】
検索の文の最初に、聞き取った条件と、判定の表が出した結論が並んでいます。
結論は確定しています。あなたが変えてはいけません。

【答え方】
1. 最初の行に、与えられた結論（可／条件付き可／不可／例外申請／未審査）を
   そのまま書いてください。
2. 次に、その結論の根拠になる規程・ガイドラインの名前と条の番号を書いてください。
3. 条件付き可のときは、守る条件を箇条書きで書いてください。
   許可サービスの一覧の条件欄の語をそのまま使ってください。
4. 例外申請・未審査のときは、次の手続きの名前と窓口だけを書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで説明してください。
  一般的なセキュリティの知識で条件を足さないでください。
- 与えられた結論と違う結論を書かないでください。
  条文が結論と合わないと思ったときは、
  「規程の確認が必要です。情報セキュリティ担当へ回します」とだけ書いてください。
- データの格付けを推測しないでください。
- 一覧に無いサービスについて、安全かどうかの意見を書かないでください。
- 例外が認められそうかどうかを書かないでください。
- 規程の抜け道や、禁止されていることを避ける方法を書かないでください。
- 該当する条文が見つからないときは、
  「規程とガイドラインに該当する記載が見つかりません。情報セキュリティ担当へ回します」
  とだけ書いてください。
- 顧客名、案件名、個人名を書かないでください。

「結論は確定している。変えてはいけない」が、この指示の要です。 モデルに条文だけを渡すと、条文を読んで自分で可否を考え、判定の表と違う結論を丁寧な根拠付きで書きます。結論を先に渡し、それを説明する役に限ることで、文章の役と判定の役が分かれます。

検索の文は、中継プログラムが組み立てます。 例えば「サービス：翻訳サービスA（条件付き許可、上限：社内限り）、データ：取引先の仕様書（機密）、アカウント：会社の契約、端末：会社支給。判定：不可。根拠の条文を示してください」のように、条件と結論を並べ、社員の質問の文を最後に足します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "department": "",
  "service": { "name": "", "matched_alias": "", "category": "allowed | conditional | prohibited | not_listed" },
  "conditions": { "classification": "public | internal | confidential | secret | unknown",
                  "account": "corporate | personal", "device": "company | byod" },
  "verdict": "ok | ok_with_conditions | ng | exception_required | not_reviewed",
  "status": "answered | escalated | skipped",
  "escalate_reason": "exception | not_reviewed | mismatch | skipped | adversarial | user_request | none",
  "answer_text": "",
  "policy_refs": [ { "doc": "", "article": "", "effective_from": "", "uri": "" } ],
  "service_conditions": [],
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、verdict を説明の文と別に持てることです。 verdict は判定の表が決め、answer_text はAIが書きます。中継プログラムは、answer_text の最初の行が verdict と合っているかを機械的に照合し、合わないものを出しません。

2つ目は、conditions を回答と一緒に残せることです。 担当へ回すとき、聞き取り済みの格付け・アカウント・端末がそのまま渡るので、担当は聞き直さずに例外の審査に入れます。 誤った回答が出たときも、どの条件で判定したかが分かります。

3つ目は、service.category の not_listed を数えられることです。 未審査として回ったサービスを月ごとに数えると、次に審査すべきサービスの順番がそのまま決まります。

システムへ連携する

許可サービスの一覧には書き込みません。 未審査のサービスが回ってきても、一覧に足すのは審査を終えた担当です。中継プログラムが一覧を書き換えられる作りにすると、照合の誤りが許可として残ります。

検索は、社員の ID で行います。 中継プログラムが広い権限のサービスアカウントで検索すると、例外承認の記録が一般の社員への説明に入ります。

人が確認する

社員は、回答を読んだあと必ず根拠の条文を開いてから使います。 回答は「どの条を読めばよいか」と結論を示すもので、条件の細かい言い回しは原文にしかありません。

1. 結論と条件を確かめる … 条件付き可なら、条件の一つひとつを自分の使い方が満たしているかを見ます
2. 聞き返しで選んだ値が正しいかを確かめる … 格付け・アカウント・端末の値を、回答の上に並べて表示します
3. 評価を付ける … 解決した／担当へ回した／誤りを選びます

2番目を軽く見ないでください。 急いでいる社員は、会社の契約のアカウントと個人のアカウントを取り違えて選ぶことがあります。条件を1つ違えた回答は、条文まで含めて正しく見えるので、回答の側からは誤りに気付けません。

情報セキュリティ担当は、回ってきた質問だけを見ます。 例外申請は、これまでどおり責任者の承認に回します。未審査のサービスは、月に一度まとめて審査の順番を決め、審査が済んだら一覧と判定の表に足します。

目標は、480件をならして1件4分です。 回答で解決した質問の記録の確認と、回ってきた質問を担当が答える時間の平均です。

例外に対処する

3行目は、最初の数か月は多く出ます。 判定の表は最初から全部の組み合わせを埋められません。回ってきた組み合わせに行を足していくことで、表は質問の実態に合わせて育ちます。 担当が答えた内容を、そのまま表の1行にします。

記録を残す

• 質問の文、選んだ聞き返しの値、日時、所属の部署
• 引いた一覧の行（区分・上限の格付け・条件）と、そのときの判定の表の版
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（説明、出典、回答しなかった理由）
• 照合の結果、回す・回さないの判定と、その理由
• 社員の評価と、担当が最終的に答えた内容

2行目で「判定の表の版」を残すのは、表が後から変わるためです。 サービスの区分を見直すと、過去の回答の意味が変わります。当時の表が残っていないと、「なぜあのとき可と答えたのか」を説明できません。 規程の監査で問われるのは、たいていこの点です。