先に要点
社内で生成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 そのもの というより、入力してよい情報の境界が決まっていないこと です。
よくある事故の入口は、だいたい次のどれかです。
- 顧客情報や個人情報をそのまま貼る
- 契約書、未公開資料、障害ログを無加工で入れる
- ソースコードや設定ファイルを丸ごと貼る
- 誰が使っているか分からない個人アカウントで利用する
- 回答を人が確認せず、そのまま社内文書や顧客向け資料へ流す
NIST の Generative AI Profile でも、生成AIの利用には情報漏えい、誤情報、プライバシー、セキュリティ、ガバナンスの観点をまとめて見る必要があると整理されています。
また、CISA の AI 利用向けガイドでも、公開してよくない情報は AI にも入れない という考え方がかなり強く出ています。
要するに、社内利用で先に決めるべきなのは どこまで入れてよいか と どの手段で使うか です。
最初に決めたい4つのルール
細かい話に入る前に、まずこの4つを決めると運用がかなり安定します。
- 何を入力してよいか
- どのサービスやプランを使ってよいか
- 誰が承認し、誰が管理するか
- ログと例外申請をどう残すか
ここが未整備だと、使っていいのか分からないから各自判断 になりやすく、現場ごとにバラつきます。
逆にここが決まっていれば、細かい利用ルールはあとから育てやすいです。
入力ルールは「禁止一覧」だけで終わらせない
社内向けの生成AIルールを作るとき、最初にやりがちなのが 個人情報禁止 機密情報禁止 だけ書いて終わることです。
もちろん禁止は必要ですが、それだけだと現場は じゃあ何なら入れてよいのか が分からず、使いづらいか、こっそり別ツールを使うかのどちらかに寄りやすいです。
そのため、入力ルールは 禁止一覧 ではなく、情報分類ごとの扱い として決める方が実務では回しやすいです。
| 情報の種類 | 扱いの目安 | 具体例 |
|---|---|---|
| 公開情報 | 基本的に入力しやすい | 公開済みの製品情報、公開マニュアル、一般公開された技術情報 |
| 社内限定だが低リスク | 承認済みツールで用途を限定して入力 | 一般的な社内手順、公開前ではないが機微性の低い定型文 |
| 要注意情報 | 原則は要マスキング・要承認 | PII、顧客情報、契約情報、障害ログ、問い合わせ本文 |
| 高リスク情報 | 原則入力しない | パスワード、APIキー、秘密鍵、認証トークン、未公開の経営情報、丸ごとのソースコード |
このように 何を禁止するか ではなく、どのレベルならどう扱うか にすると、現場へ説明しやすくなります。
特に データ分類 が未整備な会社では、まずここを簡単にでも決めるところから始めた方がいいです。
特に入力しない方がよいもの
社内利用で、少なくとも無加工で入れない方がよいものは次のとおりです。
- 氏名、住所、電話番号、メールアドレス、社員番号などの PII
- 顧客名簿、商談情報、契約書全文
- 認証情報、パスワード、秘密鍵、APIキー
- 社内の脆弱性情報や未公開の障害情報
- そのまま外へ出たら困るログや問い合わせ本文
- リポジトリ丸ごと、設定ファイル丸ごと、運用手順丸ごと
どうしても使いたいなら、匿名化、伏字化、値の置き換え、抜粋化などで そのままでは誰の何の情報か分からない状態 に近づけたうえで扱う方が安全です。
どのサービスやプランを使うかを決める
社内ルールでは、何を入力するか だけでなく、どの生成AIを使ってよいか も同じくらい大事です。
ここで見るポイントは、少なくとも次のとおりです。
- 入出力データが学習に使われるか
- データ保持期間をどこまで制御できるか
- 管理者設定、監査ログ、SSO、権限管理があるか
- 契約やセキュリティ説明が確認できるか
- 公式の管理機能で利用者を把握できるか
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 がそう言ったから正しいを禁止する
便利さはありますが、答えが自然に見えること と 正しいこと は分けて扱う必要があります。
実際の運用設計はどう組むか
ここまでを踏まえると、最初の運用設計は次の流れにすると進めやすいです。
- 利用目的を 2〜3 個に絞る
まずは議事録整理、定型文作成、社内FAQ補助のように、低リスクで効果が見えやすい用途から始めます。 - 入力してよいデータ分類を決める
公開情報、社内限定、要注意、高リスクくらいでも十分です。 - 公式に使ってよい手段を 1 つ決める
個人アカウントの持ち込みを避けるため、まずは会社の承認済み環境へ寄せます。 - 例外申請の窓口を作る
完全禁止ではなく、必要な場合に相談できる流れを用意します。 - 利用ログと見直し日を決める
半年放置すると実態とずれやすいので、見直しタイミングを持った方が運用しやすいです。
役割ごとの整理もしておくと、後で揉めにくいです。
情シス・セキュリティ
使ってよい手段、権限、監査ログ、問い合わせ先、例外申請の流れを整理します。
現場部門
何を入力してよいか、どこまで出力を使ってよいか、業務手順に落とし込みます。
法務・管理部門
契約、個人情報、社外持ち出し、記録の残し方を確認します。
承認者
例外利用や高リスク用途の承認基準を曖昧にしないようにします。
よくある失敗
社内で生成AIを導入するときに多いのは、利用規程だけ先に出して実際の使い道を示せていないことです。禁止だけが目立つと、現場は `使えないツール` だと感じやすく、逆に見えないところで別サービスが使われやすくなります。
ほかにも次の失敗がよくあります。
- 大きすぎる禁止だけを決めて、許容範囲が読めない
- レビューせずにそのまま顧客向け文書へ流す
- テスト環境のつもりで本番データを入れてしまう
- issue や問い合わせ本文を丸ごと貼って、余計な情報まで渡す
- 例外申請や相談窓口がなく、現場が自己判断で広げる
まとめ
生成AIを社内で使うときのセキュリティ対策は、使うな だけでは回りません。
実務では、何を入力してよいか、どのサービスを使うか、誰が承認し管理するか、出力をどう確認するか を決めて、初めて安定して運用できます。
特に、PII や顧客情報のようなデータを人がそのまま貼れないようにすること、データ分類 と DLP の考え方を持つこと、シャドーAI を起こさないように承認済みの利用手段を用意することは、かなり効きます。
便利さは大きいですが、とりあえず使う ではなく、どこまでなら安全に使えるかを決めて使う ことが、社内利用ではいちばん大事です。