生成AIの社内ルールは、使える環境、入力できる情報、任せる仕事、確認する人を一組にして書くと運用しやすくなります。「機密情報を入力しない」だけでは、社内資料を要約してよいか、顧客への回答に使ってよいかを判断できません。
まず次の表を一つの業務で埋め、その判断を社内共通の規程と承認済みサービス一覧へ反映します。本稿の表は実務用のたたき台です。適法性や契約上の許可は、自社の法務・情報管理担当者が個別に確認してください。
最初に埋める利用ルールの完成形
以下は架空の「社員向け経費FAQ」の記入例です。実在の企業やサービスの承認状況ではありません。
| 決める項目 | 記入例 |
|---|---|
| 対象業務・利用者 | 国内社員の経費申請に関する質問の下書き。経理担当者が利用 |
| 利用環境 | 審査済み法人契約の社内FAQ環境。会社IDでログイン |
| 入力可能な情報 | 経理が公開承認した現行の経費規程・社内FAQ |
| 入力しない情報 | 領収書画像、社員氏名、口座情報、個別の相談履歴 |
| 出力の用途 | 経理担当者が根拠条文を確認してから社員に回答 |
| 許可する操作 | 規程の検索と回答案の作成。経費承認や送金は含めない |
| 判断できない場合 | 適用日・所属・例外が不明なら経理へ引き継ぐ |
| 管理責任者 | 経理が規程を所有し、情報システムがアクセス権を管理 |
| 見直す契機 | 規程改定、外部連携追加、契約変更、事故・誤回答 |
「法人契約だから全情報を入れてよい」とは決めません。データの保存、学習利用、管理者の閲覧、外部連携先などは契約・設定によって確認が必要です。未確認の欄は、担当者と確認期限を決めるまで利用範囲から外します。
入力可否は「ツール × 情報 × 用途」で判定する
情報の分類は、既存の社内情報管理規程と名称をそろえます。AI用に別の「機密」を定義すると、同じ資料の扱いが部署によって変わります。
横に長い表は、左右にスクロールして確認できます。
| 情報と用途 | 判断の出発点 | 利用前に確かめること |
|---|---|---|
| 公開済み資料の要約 | 指定環境で利用を検討 | 著作権・利用条件、公開してよい出力か |
| 社内限定規程のFAQ | 承認された情報区分と環境に限定 | 検索対象、社員ごとの閲覧権限、保存条件 |
| 顧客の未公開仕様の整理 | 案件ごとの審査が必要 | NDA、外部処理・再委託条件、顧客のAIルール |
| 個人情報を含む相談文 | 目的と取扱条件を個別確認 | 入力の必要性、利用目的、提供先での扱い |
| パスワード・秘密鍵 | 入力対象にしない設計 | 実値を渡さず処理できる仕組みへの変更 |
上の表は法的な可否一覧ではありません。公開情報でも用途や第三者の権利の確認は残ります。社内情報を扱う必要がある業務は、必要なデータを絞り、許可された環境・契約・権限を具体化します。
個人情報保護委員会は、生成AIへ個人情報を入力する際の利用目的や、サービス提供者による取扱いの確認について注意喚起しています。「名前を消したから大丈夫」と自己判断せず、所属・案件・時期の組み合わせで人を特定できないかも確認します。個人情報保護委員会の注意喚起
出力を誰が確認するかまで書く
「人が確認する」だけでは、忙しいときに確認が省かれます。用途ごとに確認者と必要な根拠を決めます。
| 出力の使い方 | 確認者と確認内容 | 次へ進める条件 |
|---|---|---|
| 自分用の下書き | 作成者が事実、数値、参照元を確認 | 誤りを直し、引用と自分の判断を区別 |
| 社員へのFAQ回答 | 業務担当者が現行規程・適用日を確認 | 根拠があり、例外や未確認事項を明示 |
| 顧客へ出す資料 | 案件責任者が契約、秘密情報、権利を確認 | 社外公開の既存承認を完了 |
| 人事・契約などの重要判断 | 権限を持つ担当者が原資料に基づき判断 | AIの結論だけで確定しない |
AIの文章が自然でも、承認済みとは限りません。経費FAQなら、「規程に書かれていない例外を認める回答」は、言い換えの上手さとは別に評価します。
規程は短くし、変わる情報は別紙へ分ける
社内規程には共通原則を置き、サービス名や設定値は更新しやすい別紙へ分けます。次の文案を、自社の既存規程の用語・権限に合わせて調整してください。
生成AI利用の基本ルール案
1. 業務では会社が承認したサービスと会社管理のアカウントを利用する。
2. 入力できる情報と用途は、承認済みサービス一覧の条件に従う。
3. 顧客・案件情報は、契約と案件固有の条件を確認してから利用する。
4. 外部連携の追加や、AIに許可する操作の変更は事前に審査する。
5. 出力を業務に使う前に、用途ごとの責任者が根拠・数値・権利を確認する。
6. 重要な判断をAI出力だけで確定しない。
7. ログは目的、閲覧者、保存期間を定め、必要な情報だけを残す。
8. 誤入力・不審な操作に気づいたら、追加利用を止めて指定窓口へ報告する。
9. 例外は対象・期限・承認者を記録し、条件変更時に再審査する。
10. 管理責任者は規程と一覧を更新し、影響する利用者へ周知する。
付属文書は「承認済みサービス一覧」「入力判断の早見表」「例外台帳」「事故連絡先」「判断事例集」に分けます。アカウントの停止、異動・退職時の権限変更、多要素認証、管理者権限の限定も、既存のID管理手順へ接続します。
ログには質問全文を無条件に保存せず、事故調査に必要な項目と保存期間を決めます。問い合わせ本文に秘密情報が含まれるなら、ログや障害票へ複製することも情報管理の対象です。
例外申請には期限と終了方法を残す
例外は「今回だけ許可した」という口頭合意で終えません。次の欄を使うと、何を誰が許可したかを後から確認できます。
例外申請・判断記録
対象業務／利用者：
通常ルールではできないこと：
利用するサービス・契約・設定：
必要なデータと、除外するデータ：
代替方法と、それでは足りない理由：
顧客契約・個人情報・権利に関する確認結果：
許可する操作／禁止する操作：
承認者／承認日／有効期限：
停止条件と連絡先：
期限後のデータ削除・権限回収・確認者：
期限が来たら自動延長せず、継続の必要性を確認します。同じ例外が繰り返される場合は、共通ルールが業務に合っていない可能性があります。例外台帳を、規程を改定するための材料にもします。
改定時は、本文・案件・判断事例を一緒に更新する
変更履歴には「版、変更理由、対象文書、影響する業務、承認者、施行日、周知先」を残します。公表日と施行日が異なる場合は両方を記録し、旧ルールで承認した案件の再審査が必要かを判断します。
Metaの公開事例では、専門家の修正を原因分析、限定的な編集、評価、専門家レビューへ通し、修正した事例を回帰評価へ加えています。これは同社のAIシステムの設計です。本稿では、その変更管理の考え方を「規程を変えたら、以前迷った事例を再確認する」という運用へ応用しています。Metaがこの社内規程を採用しているという意味ではありません。Metaの公開事例
経費規程の改定後なら、「施行日前の出張」と「施行日後の出張」を質問し、適用すべき版へ案内できるか確認します。古い文書が検索に残る問題は、RAGで古い社内規程が回答されるときの直し方で扱います。
初版を配る前の確認
利用者に架空の質問を渡し、早見表だけで「使える／相談する／使わない」を選べるか試してください。答えが割れた箇所は、社員の理解不足と決めつけず、文言や具体例を直します。教育へつなげる際は、生成AIの社員研修の設計も参照できます。
本番移行そのものが止まっている場合は、PoCが本番に進まない理由の診断で、ルール以外の未決条件も整理してください。
更新日：2026年10月7日。表・規程案・記入例は本稿独自の整理です。
WRITTEN BY
コメント