ChatGPT、Claude、Geminiなどの生成AIは、文章作成や調査、議事録の要約、企画立案、プログラミングなど、幅広い業務を効率化できます。
一方で、社員が個人の判断だけで生成AIを使い始めると、顧客情報や未公開情報の入力、誤った回答の利用、著作権侵害、個人アカウントへの業務データ保存といった問題が発生します。
企業に必要なのは、単に「機密情報を入力しない」と注意するだけの規程ではありません。利用できるAI、入力できる情報、出力結果の確認方法、管理者が設定すべき項目、事故発生時の対応までを一つの運用ルールとして整理する必要があります。
この記事では、社内AI導入ルールブックの制作手順と必須目標を整理したうえで、Claude・ChatGPT・Geminiのセキュリティ設定をサービスごとに詳しく解説します。
社内AI導入ルールブックとは
社内AI導入ルールブックとは、社員が生成AIを安全かつ効果的に利用するための判断基準をまとめた文書です。
情報システム部門だけが読むセキュリティ規程ではなく、一般社員が日々の業務で「何を入力してよいか」「どこまでAIの回答を信用してよいか」を判断できる内容にすることが重要です。
ルールブックには、少なくとも次の要素を含めます。
- 利用を許可するAIサービスと契約プラン
- 利用できる業務と禁止する業務
- AIに入力できる情報と禁止情報
- ファイルアップロードの基準
- AIの回答を確認する方法
- 顧客向け成果物に利用する際の承認手順
- アカウントとアクセス権限の管理方法
- 外部サービスやコネクターとの連携ルール
- 利用ログと保存期間の方針
- インシデント発生時の報告先
- 定期教育とルールの更新頻度
生成AIのリスク管理では、利用を全面禁止するのではなく、組織の目的や許容できるリスクに応じて、管理・測定・運用を継続する考え方が重要です。NISTの生成AI向けリスク管理資料でも、組織の目標や優先順位に沿ってリスク管理策を設計する考え方が示されています。
ルールブックに設定すべき必須目標
1．会社の情報を守る
最優先の目標は、個人情報、顧客情報、営業秘密、未公開情報などを、許可されていないAIへ入力させないことです。
ただし、「機密情報は禁止」という一文だけでは、社員によって判断が分かれます。情報を具体的に分類し、それぞれの入力可否を示します。
入力を原則禁止する情報
- 顧客の氏名、住所、電話番号、メールアドレス
- マイナンバー、口座情報、決済情報
- 診療情報や健康情報
- パスワード、秘密鍵、APIキー
- 未公開の決算情報やM&A情報
- 公開前の新商品、設計図、ソースコード
- 秘密保持契約の対象資料
- 他社から提供された非公開資料
- 社内調査、懲戒、人事評価に関する情報
条件付きで利用できる情報
- 個人名や会社名を削除した議事録
- 数値を仮の値に置き換えた分析データ
- 公開済みの会社案内や商品情報
- 権利関係を確認済みの社内テンプレート
- AI利用について顧客の同意を得た資料
情報区分は、「公開」「社内限定」「機密」「極秘」など、既存の社内情報管理規程と統一すると運用しやすくなります。
2．シャドーAIを減らす
会社が生成AIを全面禁止すると、社員が個人アカウントや無料サービスを隠れて使う「シャドーAI」が発生しやすくなります。
ルールブックでは、禁止事項だけでなく、会社が安全性を確認した正式な利用環境を示すことが重要です。
例えば、次のように明記します。
「業務で利用できる生成AIは、会社が発行したアカウントで利用するChatGPT Enterprise、Claude Enterprise、Google WorkspaceのGeminiに限ります。個人アカウントへの業務情報の入力は禁止します」
管理対象の企業用ワークスペースを用意し、SSOやアカウントの自動削除を設定することで、個人利用よりも統制しやすくなります。
3．AIの回答を人が検証する
生成AIは、事実と異なる情報、存在しない法律、誤った計算、架空の出典などを提示する場合があります。
そのため、ルールブックには次の原則を入れます。
- AIの回答をそのまま公開しない
- 法律、医療、税務、財務、人事判断は専門担当者が確認する
- 数値は元データと照合する
- 引用元やURLは実際に存在するか確認する
- 顧客へ提出する文書は責任者が承認する
- AIに最終決裁を任せない
生成AIは「作業を補助する道具」であり、「業務責任を負う主体」ではないことを明確にします。
4．便利さと統制を両立させる
セキュリティを重視するあまり、すべての機能を無条件に停止すると、導入効果が得られません。
部署や職種ごとにリスクを評価し、段階的に許可する方法が現実的です。
例えば、最初は次の業務から始めます。
- 公開情報を使った文章案の作成
- 社内文書のひな型作成
- 個人情報を除いた議事録の要約
- アイデア出し
- 表現や誤字脱字の確認
- 公開済み情報の整理
ファイル連携、社内検索、コード実行、外部サービス操作などは、検証後に対象部署を限定して開放します。
5．利用状況を把握し、継続的に改善する
AIサービスは頻繁に機能が更新されます。一度ルールブックを作って終わりにするのではなく、定期的な見直しが必要です。
少なくとも半年に一度は、次の項目を確認します。
- 新しく追加されたAI機能
- データ保持や学習利用に関する規約
- コネクターや外部連携の追加状況
- 社内で発生したヒヤリハット
- 利用率と削減できた作業時間
- 不要になったアカウント
- 部署ごとの利用権限
- 法律や取引先要件の変更
社内AI導入ルールブックの制作手順
手順1．AI利用の目的を決める
最初に、「AIを導入すること」ではなく、解決したい業務課題を定義します。
例として、次のような目標が考えられます。
- 提案書の初稿作成時間を30％削減する
- 社内問い合わせ対応を効率化する
- 会議後の議事録作成を自動化する
- プログラム開発時の調査時間を短縮する
- マーケティング案の作成数を増やす
目的が曖昧なままでは、必要以上の機能を開放したり、利用効果を評価できなかったりします。
手順2．現在のAI利用状況を調査する
社員へのアンケートやヒアリングを行い、すでに使われているAIを把握します。
確認項目は次のとおりです。
- 使用しているAIサービス
- 個人アカウントか会社アカウントか
- 入力している情報
- アップロードしているファイル
- 利用目的
- 外部サービスとの連携状況
- 有料プランの個人契約状況
- AIで作成した成果物の提出先
実態を調べずに規程を作ると、現場で守れないルールになりやすいため注意が必要です。
手順3．情報を分類する
既存の情報セキュリティ規程にAI利用の可否を追加します。
| 情報区分 | 情報の例 | AIへの入力 |
|---|---|---|
| 公開情報 | Webサイト、公開済みカタログ | 許可 |
| 社内限定 | 一般的な業務手順、社内通知 | 管理された企業向けAIのみ |
| 機密情報 | 顧客情報、契約書、設計情報 | 原則禁止または個別承認 |
| 極秘情報 | 秘密鍵、M&A、未公開決算 | 禁止 |
単に情報区分を示すだけでなく、具体例を多く掲載することがポイントです。
手順4．許可するAIと機能を決める
AIサービス単位だけでなく、機能単位で利用可否を決めます。
例えばChatGPTを許可しても、外部アプリ、Web検索、ファイルアップロード、共有GPT、エージェント機能をすべて許可する必要はありません。
次のような許可表を作ります。
| 機能 | 一般社員 | 管理部門 | 開発部門 |
| 通常のチャット | 許可 | 許可 | 許可 |
| ファイルアップロード | 条件付き | 条件付き | 許可 |
| Web検索 | 許可 | 許可 | 許可 |
| 社内ストレージ連携 | 不可 | 条件付き | 条件付き |
| 外部アプリ操作 | 不可 | 不可 | 検証環境のみ |
| AIによるコード実行 | 不可 | 不可 | 条件付き |
手順5．管理設定を実施する
ルールブックの内容と実際のシステム設定を一致させます。
ルールに「個人アカウントは禁止」と書いていても、会社のネットワークから個人ワークスペースへ自由にアクセスできる状態では、統制が不十分です。
SSO、SCIM、ロール管理、保存期間、コネクター制御、監査ログなどを、各サービスの管理画面で設定します。
手順6．小規模な試験導入を行う
最初から全社員へ展開せず、情報リテラシーが高く、業務内容を把握しやすい部署から試験導入します。
試験期間中は、次の内容を記録します。
- 使用した業務
- 削減できた時間
- 誤回答の発生状況
- 入力判断に迷った情報
- 使われなかった機能
- セキュリティ上の懸念
- 社員からの質問
試験結果をもとに、ルールブックの曖昧な部分を修正します。
手順7．教育と確認テストを行う
ルールブックを配布するだけでは定着しません。
研修では、実際に起こり得るケースを使って判断してもらいます。
例えば、「顧客名を削除した契約書ならアップロードしてよいか」「公開前の商品名を仮名にすれば入力してよいか」といった問題を用意します。
新入社員研修、年次研修、機能追加時の臨時研修を組み合わせると効果的です。
ChatGPTのセキュリティ設定
業務利用では、原則として個人向けアカウントではなく、ChatGPT Business、Enterprise、Eduなどの管理対象ワークスペースを使用します。利用できる管理機能はプランによって異なるため、契約前に必要な機能を確認してください。
OpenAIは、ChatGPT Enterpriseの推奨導入手順として、役割と導入範囲の確認、ドメイン認証、SSO、SCIM、ワークスペース設定、セキュリティ監視などを案内しています。
SSOを設定する
SSOを利用し、会社のIDプロバイダー経由でログインさせます。
これにより、退職者や異動者のアクセスを社内アカウントと連動して管理しやすくなります。
設定時には、次の点を確認します。
- 会社ドメインの認証
- SSOの強制対象
- 管理者用の緊急アクセス手段
- 多要素認証の適用
- 委託社員や外部スタッフの扱い
- 複数ワークスペースがある場合の所属先
OpenAIは、ChatGPT Enterprise、Eduなどのユーザー管理向けに、SSO、SCIM、ロールベースアクセス制御に関する管理機能を提供しています。
SCIMでアカウントを管理する
SCIMを設定すると、人事異動や退職に合わせてアカウントを追加・停止しやすくなります。
手作業でユーザーを管理すると、退職者のアカウントが残る、部署異動後も強い権限が残るといった問題が起きます。
次の運用を推奨します。
- 入社時に自動でアカウントを発行する
- 退職時に自動で無効化する
- 部署グループと権限を連動させる
- 一時的な外部ユーザーに有効期限を設ける
- 管理者権限を定期的に棚卸しする
ChatGPT Enterpriseでは、SCIMのほか、メール招待やCSVによる一括登録も利用できます。
ロールと管理者権限を最小化する
ワークスペース所有者や管理者を必要以上に増やさないようにします。
推奨される役割分担の例は次のとおりです。
- 所有者：契約・重要なセキュリティ設定
- 管理者：ユーザー、グループ、機能設定
- 一般ユーザー：通常利用
- 監査担当者：ログ確認や利用状況のレビュー
日常的な問い合わせ対応のために、全員へ最上位権限を与える運用は避けます。
データ保持期間を設定する
会話やアップロードファイルをどの程度保持するか、社内の文書保存規程や法的要件に合わせて決めます。
保存期間を短くすれば情報漏えい時の影響を抑えやすくなりますが、監査や業務記録が必要な組織では、単純に短くすればよいとは限りません。
次の観点で判断します。
- 法令や契約で必要な保存期間
- 内部監査の必要性
- 訴訟や調査時の証拠保全
- 個人情報の削除方針
- 保存データにアクセスできる担当者
OpenAIはChatGPT Enterpriseでカスタムデータ保持期間などの管理機能を案内しており、企業データをモデル学習に使用しない方針も示しています。
アプリ・コネクターを制限する
ChatGPTからGoogle Drive、SharePoint、Gmail、GitHubなどへ接続すると、業務効率は向上します。しかし、AIが参照できる情報の範囲も広がります。
導入初期は、コネクターを原則無効にし、必要な部署に限って許可する方法が安全です。
確認項目は次のとおりです。
- どのアプリへの接続を許可するか
- 誰がアプリを追加できるか
- 読み取りだけか、書き込み操作も可能か
- ユーザー本人の既存権限が適切か
- 退職者の連携が解除されるか
- 外部開発アプリを許可するか
- アクション実行前に人の確認を必須とするか
ChatGPTのBusiness、Enterprise、Eduワークスペースでは、管理者がアプリやコネクターへのアクセスを制御できます。また、EnterpriseとEduでは、コネクターへのアクセスをカスタムロールに割り当てるRBACも提供されています。
個人ワークスペースへのアクセスを制限する
会社が管理するワークスペースを用意しても、社員が個人のChatGPTアカウントを使用できる状態では、業務データが管理外へ持ち出される可能性があります。
ChatGPT Enterpriseでは、会社のネットワークからアクセスできるワークスペースを制限する企業ネットワーク制御が案内されています。
必要に応じて、次の対策を組み合わせます。
- 管理対象ワークスペースへのアクセス限定
- IP許可リスト
- プロキシやSWGによるアクセス制御
- 管理端末だけでの利用
- ブラウザ拡張機能の制限
- 個人メールアドレスでの登録禁止
IP許可リストはChatGPT EnterpriseおよびEdu向けのオプション機能として案内されています。
共有GPTや公開設定を管理する
社員が作成したカスタムGPTに、社内資料や独自プロンプトが含まれる場合があります。
ルールブックには次の条件を明記します。
- 外部公開は原則禁止
- 社内共有前に責任者が確認する
- 機密資料を知識ファイルへ登録しない
- 外部APIを使用するGPTはセキュリティ審査を行う
- 作成者の異動・退職時に管理者を変更する
- 不要になったGPTを削除する
Claudeのセキュリティ設定
Claudeを業務利用する場合も、個人向けプランではなく、Claude for WorkのTeamまたはEnterprise環境を使用します。
高度な統制が必要な場合は、SSO、SCIM、監査ログ、カスタムデータ保持、Compliance APIなどが利用できるEnterpriseを検討します。AnthropicはClaude Enterpriseの機能として、SSO、ドメインキャプチャ、SCIM、ロール管理、監査ログ、カスタムデータ保持などを案内しています。
SSOとドメイン管理を設定する
Claude Enterpriseでは、会社のIDプロバイダーと連携したSSOを設定できます。
設定前に、次のユーザーを整理します。
- 会社ドメインの正社員
- グループ会社の社員
- 業務委託者
- 既存の個人アカウント利用者
- 緊急時に利用する管理者
- 複数組織に所属しているユーザー
SSOを強制する前に、管理者がログインできなくなる事態を防ぐため、テスト用グループで認証を確認します。Anthropicも、SSOを有効化する前にユーザー区分などを確認すべき重要事項を案内しています。
SCIMでユーザーを自動管理する
Claude EnterpriseでSCIMを設定し、人事情報と連動してアカウントを管理します。
特に、開発者や外部委託者がClaude Codeなどを利用する場合、プロジェクト終了後の権限削除を忘れないようにします。
月に一度は、次の項目を確認します。
- 退職済みユーザー
- 長期間利用していないユーザー
- 外部ドメインのユーザー
- 管理者権限を持つユーザー
- 不要な有料シート
- プロジェクトや共有情報の所有者
ロールと権限を分離する
Claude for Workでは、ユーザーが実行できる操作がロールによって異なります。
Anthropicの案内では、SSO・認証、監査ログ、データ保持などのセキュリティ設定を管理できるロールが区別されています。
管理者の人数を抑え、通常の利用者には設定変更権限を与えないようにします。
また、次の機能は利用目的に応じて権限を分けます。
- ネイティブ連携の有効化
- カスタム連携の追加
- 公開プロジェクトの作成
- データのエクスポート
- 監査ログの取得
- データ保持設定の変更
データ保持期間を設定する
Claude Enterpriseでは、カスタムデータ保持制御が提供されています。
保持期間は、すべての部署で一律に決めるのではなく、業務上の必要性を確認します。
例えば、一般的な文章作成では短期間、監査対象となる業務では一定期間保存するといった設計が考えられます。
ただし、保存期間の変更が既存データへどのように適用されるか、削除後にどのデータが残るかは、契約条件と公式仕様を確認したうえで決定します。
監査ログを取得する
Claude Enterpriseでは、ユーザー操作、システムイベント、データアクセスなどを確認するための監査ログが提供されています。監査ログのエクスポートはEnterprise組織向けに案内されています。
ログを取得するだけでなく、誰が、どの頻度で、何を確認するかを決めます。
監視項目の例は次のとおりです。
- 管理者権限の変更
- 外部連携の追加
- 大量のファイル利用
- 通常とは異なる時間帯のアクセス
- データエクスポート
- 外部ユーザーの追加
- 公開範囲の変更
- 退職者アカウントの利用
外部連携とコネクターを管理する
ClaudeからGoogle Driveなどの業務データへ接続する場合、ユーザーが元から持っているアクセス権限が適切かを確認します。
AI側の設定が安全でも、Google Driveで「リンクを知っている全員」に共有されていれば、広範囲の情報を参照できる可能性があります。
次のルールを設定します。
- 利用を許可する連携先を限定する
- カスタム連携は事前審査制にする
- 個人用クラウドストレージとの連携を禁止する
- 読み取り対象のフォルダを限定する
- 公開プロジェクトの作成権限を制限する
- 連携先の権限を定期的に棚卸しする
開発支援機能の利用範囲を決める
Claude Codeなどの開発支援機能を利用する場合は、通常のチャットよりも厳しい管理が必要です。
ソースコードだけでなく、設定ファイル、環境変数、秘密鍵、顧客固有情報が意図せず読み込まれる可能性があるためです。
ルールブックには次の内容を入れます。
- 本番環境の秘密情報を読み込ませない
.envや秘密鍵を対象外にする- AIが生成したコードは人がレビューする
- ライセンスや依存関係を確認する
- 本番環境への直接反映を禁止する
- AIに付与するファイル・コマンド権限を最小化する
- 外部送信が禁止されているリポジトリでは使用しない
Geminiのセキュリティ設定
Geminiを業務利用する場合は、個人のGoogleアカウントではなく、会社が管理するGoogle Workspaceアカウントを使用します。
対象のGoogle Workspace環境では、Geminiに既存のデータリージョン、DLP、アクセス権限などの管理策を適用できます。Googleは、Workspace内のGeminiに対して、既存のデータリージョンポリシーやDLPなどが適用されると説明しています。
Geminiアプリの利用対象を限定する
Google管理コンソールでは、組織全体、組織部門、設定グループなどを単位として、Geminiアプリの利用を有効・無効にできます。
管理画面では、原則として「生成AI」からGeminiアプリのサービス状態を設定します。Googleの案内では、全ユーザーだけでなく、組織部門や設定グループ単位でも適用できます。
最初は次のように対象を絞ります。
- AI研修を受講済みの社員
- 試験導入部署
- 機密性の低い業務を行う部署
- 管理端末を利用している社員
- 利用目的が明確なプロジェクトメンバー
会話履歴と保存期間を設定する
Google Workspace管理者は、Geminiの会話履歴を有効または無効にし、保存する場合は自動削除期間を設定できます。
公式案内では、会話履歴は初期状態で有効とされ、保存期間は3か月、18か月、36か月から選択できます。履歴を無効にした場合でも、サービス提供やフィードバック処理のため、会話が最大72時間保存される場合があります。
保存期間を決める際は、次の点を検討します。
- 会話を業務記録として扱うか
- 管理者や監査担当者が確認する必要があるか
- 個人情報を含む可能性
- 訴訟・監査対応
- ユーザー自身による削除可否
- 他のWorkspaceデータとの保存方針の整合性
Google Workspaceアプリとの連携を管理する
Geminiは、Gmail、Google Drive、Google Docs、Google Calendar、Google Keep、Google Tasksなどの情報を利用できる場合があります。
Google管理者は、GeminiからGoogleアプリを利用できるかを管理できます。なお、Workspaceアプリとの連携には、Geminiの会話履歴を有効にする必要があると案内されています。
利便性だけで一括開放せず、次の点を確認します。
- Gmailへのアクセスが必要な部署か
- Drive内の共有範囲が適切か
- 機密フォルダへアクセスできる社員は誰か
- 共有ドライブの管理者が明確か
- 外部共有ファイルが混在していないか
- 個人情報を含むメールや文書の扱い
- 連携機能を使うために必要な履歴保存を許容できるか
Geminiが参照できるWorkspaceデータは、管理者設定だけでなく、各コンテンツの所有者や既存のアクセス権限にも左右されます。
DLPを設定する
Google WorkspaceのDLPを利用し、個人情報や機密情報の共有・持ち出しを検知または制限します。
対象となるエディションや機能範囲は契約によって異なりますが、Driveなどで機密情報の外部共有を防止するルールを設定できます。
DLPルールの例は次のとおりです。
- クレジットカード番号を検出する
- マイナンバーに該当する文字列を検出する
- 「社外秘」「極秘」などのラベルを検出する
- 顧客リストの外部共有を禁止する
- 機密ファイルのダウンロードを制限する
- 違反時に管理者へ通知する
ただし、DLPだけに依存せず、情報分類、アクセス権限、社員教育を組み合わせます。
データリージョンを確認する
保存データの地域要件がある企業は、Google Workspaceのデータリージョン設定と、Geminiの対象データを確認します。
Google Workspaceでは、対象プランにおいて、保存データの地理的な保存場所を指定するデータリージョン機能が提供されています。
すべてのデータや処理が同じ地域要件の対象になるとは限らないため、法務・セキュリティ担当者が契約内容を確認する必要があります。
既存のDrive権限を見直す
Gemini導入によって新しい情報漏えいが起きるというより、以前から広すぎたDriveの権限がAIによって見つけやすくなる場合があります。
導入前に次の項目を点検します。
- 全社員に共有されている機密ファイル
- リンクを知っている全員に公開された文書
- 退職者が所有するファイル
- 管理者不在の共有ドライブ
- 外部企業と共有したままのフォルダ
- 機密情報と一般情報が混在するフォルダ
- 個人のマイドライブに保存された会社資産
Geminiの導入は、Google Drive全体のアクセス権限を整理する機会として活用できます。
3サービス共通の推奨セキュリティ設定
Claude、ChatGPT、Geminiのいずれを利用する場合も、次の設定を共通基準とします。
IDとアカウント
- 会社発行アカウントだけを使用する
- SSOを強制する
- 多要素認証を有効にする
- SCIMで入退社を連動させる
- 共有アカウントを禁止する
- 管理者権限を最小限にする
データ
- 情報区分ごとに入力可否を決める
- 個人情報と秘密情報の入力を禁止する
- 保存期間を明文化する
- 不要な会話とファイルを削除する
- データリージョン要件を確認する
- 契約上の学習利用条件を確認する
機能
- 外部連携は初期状態で無効にする
- 必要な部署だけに段階的に許可する
- 公開共有を制限する
- ファイルアップロード条件を決める
- 外部操作を伴う機能は人の承認を必須にする
- 新機能を自動的に全面開放しない
監視
- 利用ログを取得する
- 管理者変更を監視する
- 異常なアクセスを検知する
- 外部連携の追加を確認する
- 退職者アカウントを点検する
- 四半期または半年ごとに権限を棚卸しする
ルールブック制作で陥りやすい失敗談
失敗1．「機密情報を入力しない」だけで終わる
ある企業では、ルールに「機密情報の入力禁止」とだけ記載しました。
しかし社員からは、「取引先名を消した見積書は機密情報なのか」「社内会議の議事録は入力できるのか」といった質問が相次ぎました。
判断基準が曖昧だったため、慎重な社員はAIを全く使わず、積極的な社員は自己判断で多くの資料を入力する状態になりました。
改善策
情報区分ごとに、入力可能、匿名化すれば可能、承認が必要、入力禁止の4段階で具体例を示します。
失敗2．無料版と企業版を区別していない
会社が「ChatGPTの利用を許可する」と案内したところ、社員が個人の無料アカウントを使い始めました。
その結果、会社側でユーザー管理、保存期間、退職時の削除、外部連携状況を確認できませんでした。
改善策
利用できるサービス名だけでなく、対象プラン、ログイン方法、ワークスペース名、会社アカウントの使用義務まで明記します。
失敗3．AIを全面禁止してシャドーAIが増える
情報漏えいを恐れてAIを全面禁止した企業で、社員がスマートフォンや個人アカウントから生成AIを使い続けていました。
禁止したことで、情報システム部門が利用実態を把握できなくなり、かえってリスクが高まりました。
改善策
低リスク業務から正式な利用環境を提供し、禁止ではなく管理された利用へ移行します。
失敗4．コネクターを最初から全面開放する
業務効率化を急ぐあまり、全社員にクラウドストレージやメール連携を許可したところ、以前から設定されていた過剰な共有権限が明らかになりました。
本来は別部署しか閲覧しないはずの文書を、複数の社員がAI経由で検索できる状態でした。
改善策
AI連携前に、Drive、SharePoint、メール、GitHubなどの元データ側のアクセス権限を棚卸しします。連携は部署単位で段階的に許可します。
失敗5．AIの回答をそのまま顧客へ提出する
社員がAIに市場調査を依頼し、出典を確認せずに顧客向け資料へ掲載しました。
しかし、統計数値と引用元が実在しないことが後から判明し、資料の再提出と説明が必要になりました。
改善策
外部提出物では、事実、数値、法律、引用、固有名詞を確認するチェックリストを設け、責任者の承認を必須にします。
失敗6．ルールブックを長くしすぎる
法務部門と情報システム部門が詳細な規程を作成したものの、本文が数十ページに及び、一般社員にはほとんど読まれませんでした。
改善策
文書を次の3層に分けます。
- 全社員向けの1ページ早見表
- 判断例を掲載した実務ルールブック
- 管理者向けの設定・監査手順書
日常的に確認する内容と、専門担当者向けの内容を分離します。
失敗7．導入後に設定を見直さない
導入時には安全な設定だったものの、新しい外部連携や共有機能が追加された後も確認されず、社員が管理者の想定外の機能を利用していました。
改善策
サービス更新情報を確認する担当者を決め、新機能は原則としてリスク評価後に許可します。ルールブックには、改定日、版番号、変更内容、承認者を記録します。
失敗8．ログを取得するだけで確認しない
監査ログを保存していたものの、誰も定期確認していなかったため、不適切な外部連携や退職者アカウントの残存を発見できませんでした。
改善策
「ログを取得する」ではなく、確認担当者、確認頻度、検知条件、エスカレーション先まで決めます。
すぐに使える社内AI利用ルールの例
基本原則
- 業務では、会社が承認したAIサービスと会社発行アカウントのみを使用する
- 個人情報、顧客機密、認証情報、未公開情報をAIへ入力しない
- ファイルをアップロードする前に、情報区分と共有権限を確認する
- AIの出力は参考情報として扱い、利用者が内容を確認する
- 顧客向け成果物は、事実確認と責任者の承認を行う
- 外部サービスとの連携は、会社が許可したものだけを使用する
- 誤入力や情報漏えいの可能性に気付いた場合は、直ちに報告する
- AIの利用責任は、AIではなく利用者と承認者が負う
インシデント発生時の対応
誤って機密情報を入力した場合、利用者だけで解決しようとしてはいけません。
次の順番で対応します。
- 追加の入力や共有を停止する
- 会話、日時、入力した情報、利用サービスを記録する
- 可能であれば会話や共有リンクを削除する
- 情報システム部門またはセキュリティ窓口へ報告する
- 関係するアカウント、APIキー、パスワードを変更する
- 影響範囲を確認する
- 法務、個人情報保護担当、取引先への報告要否を判断する
- 再発防止策をルールブックへ反映する
報告者を責める運用にすると、事故が隠されます。誤入力を早期に報告した社員を不当に処罰しない方針も検討すべきです。
まとめ
社内AI導入ルールブックの目的は、生成AIを禁止することではありません。社員が安全に利用できる範囲を明確にし、会社が利用状況を管理できる状態を作ることです。
ルールブックでは、次の5点を必須目標として設定します。
- 会社・顧客の情報を守る
- シャドーAIを減らす
- AIの回答を人が検証する
- 利便性とセキュリティを両立する
- 利用状況を監視し、継続的に改善する
ChatGPT、Claude、Geminiには、それぞれSSO、SCIM、ロール管理、データ保持、監査、外部連携制御などの企業向け機能があります。ただし、設定項目や利用条件は契約プランによって異なります。
ルールだけを作るのではなく、実際の管理画面設定、社員教育、権限の棚卸し、インシデント対応までを一つの仕組みとして設計することが、安全なAI導入への近道です。
また、生成AIは機能変更の頻度が高いため、ルールブックには必ず改定日と管理責任者を記載し、少なくとも半年に一度は見直しましょう。
