生成AIの社内利用ルール策定｜情報漏えいを防ぐガードレール設計

生成AIの社内利用ルールが「全面禁止」か「性善説の野放し」に二極化し、結果として現場でシャドーITが横行する——製造業のDX推進担当者からよく聞く悩みです。本記事では、情報区分・技術制御・運用の3層でガードレールを設計し、90日で全社ルールとして回し始める具体的な手順を解説します。読み終えたとき、自社の情報漏えいリスクを下げながら現場の生産性を落とさないルールの骨子が描けるはずです。

「禁止」でも「野放し」でも情報漏えいは防げない

生成AIの業務利用をめぐって、企業の対応は大きく二極化しています。ひとつは「リスクが読めないので全面禁止」、もうひとつは「各自の判断に任せる」という実質的な野放しです。どちらも情報漏えい対策としては機能しません。 全面禁止の場合、現場は業務効率のために個人スマホや私用アカウントで生成AIを使い始めます。いわゆるシャドーITです。会社の管理外で機密情報が入力されるため、禁止したはずのリスクがむしろ見えない場所に移動します。実際、製造業のお客様の情報システム部門にヒアリングすると、「禁止しているはずなのに、設備の故障ログや検査手順書をそのままChatGPTに貼っている社員がいた」という話は珍しくありません。 一方で野放しの場合、悪意がなくても漏えいは起きます。典型的なのは、取引先との図面や品質クレーム情報、設備のセンサーデータをプロンプトに貼り付けてしまうケースです。学習に利用されない設定のサービスであっても、契約上の秘密保持義務や取引先とのNDAに抵触する可能性があり、「サービスの設定が安全だから問題ない」とは言い切れません。 実務で漏えいにつながる経路を整理すると、多くは次の4つに集約されます。

重要なのは、これらの経路の大半が「ルールの文言」だけでは塞げないという点です。人は忙しいとき、便利なほうに流れます。だからこそ、文書としてのルールに加えて、システム側の制御と運用の仕組みを組み合わせた「ガードレール」として設計する必要があります。

生成AIの社内利用ルールを支える3層のガードレール

ガードレールとは、利用者が多少誤った操作をしても重大事故に至らないようにする多層防御の考え方です。生成AIの社内利用ルールでは、次の3層で設計するのが実務的です。

第1層：情報区分と入力可否のマトリクス

最初にやるべきは、ツール選定でも規程の文章化でもなく、「どの情報を生成AIに入力してよいか」の区分です。既存の情報セキュリティ規程に区分がある企業でも、生成AI向けに読み替えたマトリクスを1枚作ることを強くおすすめします。現場の判断基準は、抽象的な規程ではなく具体的な対応表でしか機能しないためです。

ポイントは「機密」と「極秘」を分けることです。設備保全や品質管理の現場で生成AIが本当に役立つのは、故障履歴や検査基準書といった機密区分の情報を扱うときです。ここを一律禁止にすると現場のメリットがほぼ消え、ルールが形骸化します。機密区分は「社内に閉じた環境なら可」とし、極秘区分だけを個別承認制にする設計が、安全性と実用性のバランス点になります。

第2層：技術的ガードレール（システム側の制御）

マトリクスを作っても、人の判断だけに頼る限りミスは起きます。第2層として、システム側で最低限次の制御を入れます。

• 利用経路の一本化：会社契約のサービスまたは社内AI環境に限定し、SSOで認証。個人アカウント利用はネットワーク側でブロックする。
• 学習オプトアウトの契約確認：入力データがモデル学習に使われない契約・設定であることをAPI利用規約レベルで確認する。
• プロンプトログの取得：誰が何を入力したかのログを最低90日保持する。抑止効果と、インシデント時の影響範囲特定の両方に効く。
• DLP的なフィルタ：個人情報のパターン（電話番号、メールアドレス等）や特定キーワードを含む入力を警告・ブロックする。
• RAG環境のアクセス権継承：社内文書を検索対象にする場合、元文書の閲覧権限をAI回答にも引き継ぐ。

特に見落とされがちなのが最後のアクセス権継承です。社内文書を対象にしたRAG構成のAIチャットでは、全文書を無差別にインデックス化すると、本来は部長職以上しか見られない人事評価資料や原価情報が、一般社員の質問への回答に混ざって出てくる事故が起きます。これは外部漏えいではなく「社内漏えい」ですが、実害としては深刻です。文書のACLを検索時に評価する設計になっているかは、社内AIチャット導入時の必須確認項目です。

第3層：運用ガードレール（教育・例外申請・監査）

技術で塞げない部分は運用で補います。柱は3つです。

1. 具体例ベースの教育：「機密情報を入力しない」ではなく「故障報告書は設備名と取引先名をマスクすれば入力可」のように、現場の実際の文書を例に可否を示す。30分の研修で十分です。
2. 例外申請フローの整備：マトリクス外のケースは情報システム部門が3営業日以内に回答するフローを作る。回答が遅いと現場は勝手に判断します。
3. 四半期ごとのログ監査：プロンプトログをサンプリング監査し、ルール逸脱の傾向を教育内容に反映する。

例外申請の判断結果をマトリクスに追記していくと、半年ほどでルールが現場の実態に馴染み、申請件数自体が減っていきます。ルールを「作って終わり」にしない仕組みがこのループです。

90日で回し始めるルール策定の進め方

完璧な規程を目指して1年かけるより、90日で最小構成を動かして改訂するほうが確実に定着します。実務的なスケジュール感は次の通りです。

最初の30日：棚卸しとマトリクス作成

現場3〜5部門（例：品質管理、設備保全、営業）にヒアリングし、「生成AIに入力したい情報」を具体的な文書名レベルで20〜30件リストアップします。そのリストを情報区分マトリクスに落とし込み、法務・情シスと可否を確定させます。抽象的な規程の議論から入らず、実際の文書リストから始めるのが最大のコツです。

次の30日：パイロット運用

1〜2部門・20名程度でパイロットを開始します。技術的ガードレールはこの時点では「利用経路の一本化」と「ログ取得」の2つだけで構いません。パイロット中に出た「これは入力していいのか」という質問をすべて記録し、マトリクスを改訂します。実務では、この30日で判断に迷うケースの7〜8割が出尽くします。

最後の30日：全社展開と教育

改訂済みマトリクスをもとに30分研修を全対象者に実施し、例外申請フローと監査サイクルを開始します。規程文書はこの段階で正式化すれば十分です。順番を逆にして規程から作ると、現場の実態と乖離した文言が固定化されがちです。

つまずきやすいポイントと回避策

これまでの支援経験から、ルール策定でつまずく典型パターンを3つ挙げます。

禁止事項が長すぎて誰も読まない

禁止リストが30項目を超えると、現場は読まなくなります。禁止事項は「個人アカウントで使わない」「極秘区分を入力しない」「生成物を検証せず社外に出さない」の3本柱に絞り、細部はマトリクスに寄せるのが実用的です。

「匿名化すれば可」の匿名化基準が曖昧

「固有名詞を消せばよい」と考えがちですが、製造現場では設備の型番や検査条件の組み合わせだけで取引先や製品が特定できることがあります。匿名化の対象は「社名・人名・型番・図番・数値仕様のうちどれか」を文書種別ごとに明示してください。曖昧なままだと、担当者ごとに判断がぶれて事実上のノールール状態になります。

ルール策定とAI活用の検証を分離してしまう

ルールだけ先に完成させると、実際のユースケース（例：故障履歴の要約、検査手順書の検索）で使いにくい制約が判明し、作り直しになります。逆にPoCだけ先行すると、検証で使ったデータの扱いが後から問題になります。小規模なAIの効果検証とルールのパイロットを同じ90日の中で並走させると、双方の手戻りを最小化できます。PoCで扱うデータの区分を最初に確定させることが、検証プロジェクト自体のリスク管理にもなります。

次の一歩：まず「入力してよい情報」を1枚にまとめる

生成AIの社内利用ルールは、分厚い規程ではなく「情報区分と入力可否のマトリクス1枚」から始まります。今週できることとして、自部門でよく使う文書を10件書き出し、上のマトリクスに当てはめてみてください。判断に迷った文書こそが、法務・情シスと最初に議論すべき論点です。 そのうえで、社内文書を安全に活用したいのであれば、外部サービスの利用ルールと並行して、アクセス権制御を前提とした社内RAG環境の検討を進める価値があります。機密区分の情報を「使えない」から「安全に使える」に変えることが、ルール策定の本当のゴールです。shinei-aiでも、ルール設計とAI活用検証を並走させる形での相談を随時受け付けていますが、まずは自社のマトリクス1枚を作るところから始めてみてください。