先に要点
社内で生成AIを使う場面は、要約、文章のたたき台、調査補助、議事録整理、コード補助、FAQ 作成など、かなり増えています。
ただ、便利だからといって入力ルールが曖昧なまま広がると、情報漏えい、権限逸脱、誤回答の社内展開、承認されていないツール利用が起きやすくなります。
この記事では、2026年4月4日時点で NIST の AI RMF: Generative AI Profile、OpenAI の business data privacy / security、OWASP の LLM Prompt Injection Prevention Cheat Sheet、CISA の AI 利用向けガイドを確認しながら、社内で生成AIを使うときに最初に決めたい入力ルールと運用設計 を整理します。
認証やアクセス制御を含む社内システム全体の考え方も見たい場合は、社内の業務システムに必要なセキュリティ対策は？どこまでやるべきかを整理 や SSOとは？便利さだけでなく運用とセキュリティの観点から解説 もあわせて読むとつながりやすいです。
生成AIから社内データや外部ツールへつなぐ仕組みとして最近よく出てくる MCP の全体像は、MCPとは？仕組み・できること・便利な理由を初心者向けにわかりやすく解説 でまとめています。
AIがサイバー攻撃と防御の全体像をどう変えるかまで広げて見たい場合は、AIはサイバーセキュリティをどう変える？攻撃・防御・運用リスクを整理 もつながります。
まず危ないのは何か
社内で生成AIを使うとき、いちばん危ないのは AI そのもの というより、入力してよい情報の境界が決まっていないこと です。
よくある事故の入口は、だいたい次のどれかです。
- 顧客情報や個人情報をそのまま貼る
- 契約書、未公開資料、障害ログを無加工で入れる
- ソースコードや設定ファイルを丸ごと貼る
- 誰が使っているか分からない個人アカウントで利用する
- 回答を人が確認せず、そのまま社内文書や顧客向け資料へ流す
NIST の Generative AI Profile でも、生成AIの利用には情報漏えい、誤情報、プライバシー、セキュリティ、ガバナンスの観点をまとめて見る必要があると整理されています。
また、CISA の AI 利用向けガイドでも、公開してよくない情報は AI にも入れない という考え方がかなり強く出ています。
要するに、社内利用で先に決めるべきなのは どこまで入れてよいか と どの手段で使うか です。
自社が保有する顧客情報を AI に読ませてよいか、要約・分類・問い合わせ対応補助のような用途ごとの線引きへ絞って見たい場合は、顧客情報をAIに読み取らせていいのか？ もつながります。
最初に決めたい4つのルール
細かい話に入る前に、この4つを決めると運用がかなり安定します。ここが未整備だと 使っていいか分からないから各自判断 になり、現場ごとにバラつきます。
1. 何を入力してよいか
2. どのサービス・プランを使うか
個人アカウントでの利用は避け、組織向けの管理機能がある契約に寄せる。学習利用設定・保持期間・SSO の有無を確認する。
3. 誰が承認し、誰が管理するか
情シス、現場部門、法務、承認者の役割を分ける。例外申請の窓口と、判断基準を曖昧にしないことが大事。
4. ログと例外申請の運用
利用ログ、承認記録、例外申請の履歴を残す。半年に一度の見直しタイミングを最初から決めると形骸化しにくい。
入力ルールは「禁止一覧」だけで終わらせない
社内向けの生成AIルールを作るとき、最初にやりがちなのが 個人情報禁止 機密情報禁止 だけ書いて終わることです。
もちろん禁止は必要ですが、それだけだと現場は じゃあ何なら入れてよいのか が分からず、使いづらいか、こっそり別ツールを使うかのどちらかに寄りやすいです。
そのため、入力ルールは 禁止一覧 ではなく、情報分類ごとの扱い として決める方が実務では回しやすいです。
| 情報の種類 | 扱いの目安 | 具体例 |
|---|---|---|
| 公開情報 | 基本的に入力しやすい | 公開済みの製品情報、公開マニュアル、一般公開された技術情報 |
| 社内限定だが低リスク | 承認済みツールで用途を限定して入力 | 一般的な社内手順、公開前ではないが機微性の低い定型文 |
| 要注意情報 | 原則は要マスキング・要承認 | PII、顧客情報、契約情報、障害ログ、問い合わせ本文 |
| 高リスク情報 | 原則入力しない | パスワード、APIキー、秘密鍵、認証トークン、未公開の経営情報、丸ごとのソースコード |
このように 何を禁止するか ではなく、どのレベルならどう扱うか にすると、現場へ説明しやすくなります。
特に データ分類 が未整備な会社では、まずここを簡単にでも決めるところから始めた方がいいです。
特に入力しない方がよいもの
社内利用で、少なくとも無加工で入れない方がよいものは次のとおりです。
- 氏名、住所、電話番号、メールアドレス、社員番号などの PII
- 顧客名簿、商談情報、契約書全文
- 認証情報、パスワード、秘密鍵、APIキー
- 社内の脆弱性情報や未公開の障害情報
- そのまま外へ出たら困るログや問い合わせ本文
- リポジトリ丸ごと、設定ファイル丸ごと、運用手順丸ごと
どうしても使いたいなら、匿名化、伏字化、値の置き換え、抜粋化などで そのままでは誰の何の情報か分からない状態 に近づけたうえで扱う方が安全です。
どのサービスやプランを使うかを決める
社内ルールでは、何を入力するか だけでなく、どの生成AIを使ってよいか も同じくらい大事です。
ここで見るポイントは、少なくとも次のとおりです。
OpenAI の business data privacy / security の説明でも、ChatGPT Enterprise / Business や API では、組織データをデフォルトで学習に使わないこと、保持制御や暗号化、管理機能があることが明記されています。
つまり、社内利用では 無料で使えるから ではなく、組織向けの管理と設定があるか を見るべきです。
特に、部署ごとに勝手にツールを選び始めると シャドーAI が起きやすいので、会社として まずはこの手段を使う を決めておく方が現実的です。
権限設計は「全員自由に使える」で終わらせない
社内で生成AIを使うときは、ライセンスを配るだけで終わらせず、権限も分けた方が安全です。
たとえば次のように分けると整理しやすいです。
- 一般利用者
要約、たたき台、定型文作成などの通常利用 - 管理者
ワークスペース設定、監査ログ確認、利用者追加、保持設定確認 - 高リスク用途の承認対象者
例外利用、特定データの持ち込み、外部連携の承認
ここで大事なのは、社内ツールだから全員同じ権限 にしないことです。
既存の社内システムでも同じですが、便利なツールほど管理者権限と一般権限を分けた方が事故が広がりにくくなります。
DLP とマスキングをどう考えるか
人に気をつけてもらう だけで回すのは限界があります。
そのため、可能なら DLP や入力時のマスキングも考えたいところです。
DLP は、機密情報や個人情報が外へ出るのを防ぐための制御です。
生成AIの文脈では、たとえば次のような考え方になります。
- 氏名、メールアドレス、社員番号を自動検知して警告する
- クレジットカード番号や口座番号らしき値をブロックする
- 高リスク情報を含むテキストは承認なしで送れないようにする
- まずはコピー元のデータを抜粋や匿名化してから入力する
全部をシステムで防げないとしても、無加工の生データをそのまま貼らない 運用にするだけでかなり違います。
プロンプトインジェクションや出力確認も外せない
社内利用で見落とされやすいのが、入力する情報の安全性 だけでなく、AI が返す内容をどこまで信用してよいか です。
OWASP の LLM Prompt Injection Prevention Cheat Sheet でも、外部入力や文書本文、Web ページ、コメントなどに紛れた命令でモデルの挙動がずれるリスクが整理されています。
社内利用でも、問い合わせ文、添付文書、社内Wiki、issue、メール本文などを AI に読ませるなら、この観点は外せません。
そのため、少なくとも次は決めた方がよいです。
- 外部由来の入力を読む用途では、出力を人が確認する
- 重要判断や承認文書は AI の出力をそのまま採用しない
- 要約用途でも、元文書へのリンクや出典を残す
AI がそう言ったから正しいを禁止する
便利さはありますが、答えが自然に見えること と 正しいこと は分けて扱う必要があります。
実際の運用設計はどう組むか
最初の運用設計は次の5ステップで進めると、スムーズに立ち上げられます。
役割ごとの整理もしておくと、後で揉めにくいです。
情シス・セキュリティ
使ってよい手段、権限、監査ログ、問い合わせ先、例外申請の流れを整理します。
現場部門
何を入力してよいか、どこまで出力を使ってよいか、業務手順に落とし込みます。
法務・管理部門
契約、個人情報、社外持ち出し、記録の残し方を確認します。
承認者
例外利用や高リスク用途の承認基準を曖昧にしないようにします。
よくある失敗
社内で生成AIを導入するときに多いのは、利用規程だけ先に出して実際の使い道を示せていないことです。禁止だけが目立つと、現場は `使えないツール` だと感じやすく、逆に見えないところで別サービスが使われやすくなります。
ほかにも次の失敗がよくあります。
- 大きすぎる禁止だけを決めて、許容範囲が読めない
- レビューせずにそのまま顧客向け文書へ流す
- テスト環境のつもりで本番データを入れてしまう
- issue や問い合わせ本文を丸ごと貼って、余計な情報まで渡す
- 例外申請や相談窓口がなく、現場が自己判断で広げる
社内 生成AI 利用に関するよくある質問
ChatGPT 無料版を業務で使ってよいか？
原則として避けたいです。無料版や個人 Plus 契約では、入力データの学習利用設定や保持期間を組織として制御できません。業務利用なら ChatGPT Business / Enterprise、Claude Team / Enterprise、Microsoft 365 Copilot、または API 経由の自社環境のように、組織向け契約に寄せるのが安全です。
「機密情報禁止」と書けば十分？
不十分です。機密情報 の定義が現場で揺れるので、氏名 / メール / 顧客名簿 / 契約書 / API キー / リポジトリ全体 のように具体例を伴った情報分類で書くと、現場が判断しやすくなります。OK 例 も必ず添えてください。
個人情報をマスキングして入れれば大丈夫？
リスクは下がりますが、ゼロにはなりません。マスキング漏れ、文脈からの再識別、AI 側のログ保持などで完全には防げません。要注意情報や高リスク情報は、マスキングしてもまず承認フローを通す前提にしてください。
シャドーAI を完全に防げる？
完全には防げませんが、減らせます。使ってよい公式手段を用意する、例外申請の窓口を作る、定期的にツール棚卸しをする の3つで多くは抑えられます。禁止だけで押さえ込むと逆効果なので、公式の代替を提供する が肝です。
プロンプトインジェクションは社内利用でも対策が要る？
要ります。外部由来の入力（問い合わせ本文、メール、添付文書、社内 Wiki、issue コメント、Web ページ）を AI に読ませる用途では、悪意ある命令が紛れ込む可能性があります。OWASP の LLM Prompt Injection Prevention Cheat Sheet が参考になります。最低限、重要判断や承認文書は AI 出力をそのまま採用しない を運用ルールに入れてください。
AI 利用ログはどれくらい残すべき？
業種や規制に依存しますが、最低 6ヶ月、可能なら 1年は残すと、事後調査や監査対応がしやすくなります。ChatGPT Business / Enterprise や Claude Team などには監査ログ機能があるので、契約時に取得期間と保持期間を確認してください。
まとめ
AIツールの契約費用やクライアントへの請求まで含めて整理したい場合は、AIツール利用料はクライアントに請求できる？経費計上と見積書の考え方 もあわせて読むと、運用ルールと費用負担をつなげて考えやすくなります。
生成AIを社内で使うときのセキュリティ対策は、使うな だけでは回りません。
実務では、何を入力してよいか、どのサービスを使うか、誰が承認し管理するか、出力をどう確認するか を決めて、初めて安定して運用できます。
特に、PII や顧客情報のようなデータを人がそのまま貼れないようにすること、データ分類 と DLP の考え方を持つこと、シャドーAI を起こさないように承認済みの利用手段を用意することは、かなり効きます。
便利さは大きいですが、とりあえず使う ではなく、どこまでなら安全に使えるかを決めて使う ことが、社内利用ではいちばん大事です。