生成AIの社内展開を提案すると、経営層・法務・情報システム部門から必ず同じ問いが返ってきます。「うちの機密情報は大丈夫なのか」。これに技術的な裏づけで答えられないと、プロジェクトはそこで止まります。裏を返せば、ここで述べる統制を立ち上げの数週間で固めておけば、その後の議論はぐっと進めやすくなります。
この記事では、機密の不安を分解し、統制を4つの柱として整理し、最も見落とされやすい社内の共有権限の設計までを扱います。なお、ここで触れる製品仕様の類は時点により変わるため、実際の設計・契約時には最新の公式ドキュメントでの確認が前提です。
「大丈夫か」を分解する——契約で片づく不安・設計でしか片づかない不安
「機密は大丈夫か」という一言には、実は種類の違う不安がいくつも同居しています。(a) 入力した情報がAIの学習に使われ、他社への回答に滲み出すのでは。(b) 情報がインフラの外へ漏れるのでは。(c) AIが誤った情報を答えて業務を壊すのでは。(d) 社内の見せてはいけない相手に見えてしまうのでは。これらを混ぜたまま議論すると、「危ないから禁止」か「ベンダーが安全と言うから大丈夫」という両極の思考停止に落ちます。
仕分ければ、それぞれに別の答えがあります。
- (a)(b) の大部分は、契約と規約が解決する。法人向けの契約では、入力・出力・知識ファイルが基盤モデルの学習に使われないことが規約で保証されるのが一般的です（無料の個人向けサービスとの決定的な違い）。だから「学習に使われるのでは」への答えは、技術論ではなく契約文書の確認です。法務と読み合わせる点は、学習非利用の対象範囲・例外処理の条件・適用プランの3つ。
- (c)(d) は契約では解決しない。AIが自信を持って間違える問題（前回までの三層対策と、次回のHuman-in-the-Loop）と、社内の権限を越えて見える問題（本記事の共有権限設計）は、いずれも設計の仕事です。
つまり「大丈夫か」への正しい答え方は、「大丈夫です」でも「危険です」でもありません。それぞれの不安について「これは契約で、これは設定で、これは運用の設計で守ります」と、守りの担い手を一つずつ名指しで示すこと。この答え方自体が、法務・経営の信頼を得る最短経路です。ひとつでも「ベンダーが安全だと言っているので」としか返せない項目があれば、そこがプロジェクト全体の足を止める一点になります。
統制の4つの柱
仕分けができたら、統制を4つの柱で整理します。
- 学習非利用（担い手＝契約）——入力・出力・知識ファイルがモデル学習や他社へ流用されないことを、法人規約で固定する。技術でなく契約なので全機能に一様に効く唯一の柱。ただし「企業契約の環境で使う限り」という前提（個人アカウントには効かない）を必ず添える。
- インフラの隔離と暗号化（担い手＝設定）——サービス境界による封じ込め、自社管理の暗号鍵、データの保存地域、改ざんできない監査ログ。「建物に塀を立て、出入り口を限定する」統制です。ただし塀は、正規の鍵で正面から入る社内の人間には何もしません。それは第4の柱の仕事です。
- 実行時の防御（担い手＝設定＋監視）——利用者を装ってAIを騙し機密を引き出すプロンプトインジェクションなど、生成AI固有の攻撃を実行時に検知・遮断する。特に、攻撃の指示文がAIの読む文書側に埋め込まれる間接的なインジェクションは、外部由来の文書を取り込むほど現実味を増します。最後のフィルタが実行時防御なら、最初のフィルタは取込の統制（正本区画に入れる文書の出所を限定し検収する）です。
- 共有権限の設計（担い手＝自社）——権限のない社内の相手に機密が見えないようにする。第1〜3の柱が「外と下」を固め、製品が機能として提供してくれるのに対し、この「内側」だけは、自社の機密区分と業務構造を知る組織にしか設計できません。最も見落とされ、最も自社の設計力が問われる柱です。
4本は独立ではなく層を成します。データの流れ（入力→保管→利用→共有）に沿って、契約→設定→監視→自社設計が割り当たる、と読むと分かりやすいはずです。
「対応している」を疑う——機能 × 統制 × リージョンで確かめる
第2の柱の各統制は、カタログ上は「対応」と書かれます。けれど本番の設計では、その「対応」を機能ごと・統制ごと・地域ごとに割って一つずつ確かめないと危険です。対応可否が、製品単位でなく機能単位・構成単位で変わるからです。
たとえば大規模な知識基盤の中核機能で、「サービス境界と自社鍵には対応するが、保存地域の指定には対応しない」「自社鍵が有効なのは特定のDB構成のときだけ」といった条件付きが普通にあります。地域を「global」にすると一部の暗号統制が使えない、といった罠もあります。
ここで勧めたいのが要件表です。縦に使う機能、横に統制要件（保存地域・鍵管理・閉域・監査）を並べ、交点に「可／不可／条件つき（条件を明記）／いつ確認したか」を書き込む表です。確認日が要るのは、この領域の公式ドキュメント自体が改訂され続け、古い記述が第三者記事に残っているからです。さらに機密区分から逆に引く使い方が効きます——区分ごとに「この区分は保存地域と自社鍵の両方が揃う構成にしか載せない」と先に決めておけば、新しい機能が出るたびの判断は「表の照合」という機械作業になり、属人的な「えいや」が消えます。
最も見落とされる第4の柱——共有権限の設計
現実に最も多い事故は、外部からの攻撃ではありません。ちゃんと権限を持った社内の人に、本来見えてはいけない情報が見えてしまう——これです。
どれほど堅牢な暗号化も、正規の権限で開かれる扉には無力だ。 『生成AIの内製化』第6章
出発点は、データ整備で文書に付けた機密区分タグです。このタグは整理のためではなく、最初から**「誰がアクセスできるか」を決める材料**として用意したものでした。正本区画が区分を跨がない単位で切られていれば、区画単位の権限がそのまま区分単位の統制になり、ボットやコーパスの分割が分類体系に従っていれば、「この窓口の共有範囲は、この区分にアクセスできる集団まで」と機械的に決まります。土台が正しくできていれば、権限設計は新しい難問ではなく、既にある区分の「写像」にすぎません。
そして権限よりさらに手前に、最強の原則があります。そもそも載せない（データ最小化）。未公開製品の仕様や、申請に関わる実数値のように最も慎重に扱うべき情報は、権限を固めて載せるのではなく、そもそも知識基盤に入れない。守るものを減らすこと自体が、どんな仕組みより確実な守りになります。共有権限の設計は、あくまで「載せると決めたもの」に対する二段目の防御。一段目は、そもそも何を取り込むかという入口にあります。
実装上の注意も一つ。多くの社内ボットの共有は、ファイル共有の仕組みに従うため、編集権限を持つ相手はカスタム指示（プロンプト）の中身まで見えます。だから指示文に機密を直書きしない——指示に置いてよいのは用語・ルール・作法であって、仕様の実数値ではありません。公開前には、共有範囲が機密区分と整合しているか・指示に直書きがないか・引用義務化が入っているか・知識ファイルの出所は正本区画か・評価セットが添えられているか、を関門としてチェックします。
運用の規律は3つ。最小権限（必要な人に必要な分だけから始め、広げる方向にだけ動かす）、四半期の棚卸し（使っていない人への共有や異動者の残置権限を点検）、人事イベントと連動（異動・退職・プロジェクト終了をトリガーに権限を引き継ぐか閉じる）。権限は、付けるときより外すときに漏れます。
シャドーAIと監査——統制を運用に変える
統制の最後の敵は、統制の外で起きる利用——シャドーAI（個人契約の無料サービスに業務情報を貼る行為）です。ここで効くのは、禁止令ではありません。学習に使われない公式環境が、個人の無料サービスより使いやすいことです。公式環境が十分に速く、正確で、根拠まで付いて返るなら、わざわざリスクを冒して外部サービスに頼る理由はなくなります。禁止と利便は統制の両輪です。
同時に、検知と記録も敷きます。操作は改ざんできない監査ログに残し、共有範囲の変更履歴・大量エクスポート・部門間の利用率の偏りを定期レビューする。「情報漏えい・著作権インシデント0件」を指標に組み込めば、統制は守りのコストでなく、経営に報告される成果になります。報告の仕方も、「事故はありませんでした」と守りを一行で述べるより、「利用を◯◯%まで広げつつ、事故ゼロを保っています」と、広げたことと守ったことをセットで語るほうが効果的です。
ただし、従業員監視に転化させない節度が要ります。レビューの目的を「機密保護と統制の検証」に限定し、個人の生産性評価には使わないと明文化する。この一線を引かないと、ログがあること自体が公式環境を使う気をそがせ、かえってシャドーAIを増やしてしまいます。そして事故は設計しても起きるものとして、自己申告者を罰しない報告経路（無過失報告）と対応手順をあらかじめ決めておきます。
導入は「書類が先、設定が後」
最後に順序です。すべてを初日に完成させる必要はありませんが、順序を誤ると手戻りが大きくなります。要点は書類仕事（契約・機密区分の確認）が先、画面の設定が後ということ。設定はやり直せますが、区分の定義がぐらつくと、その上に積んだ権限のすべてがぐらつくからです。ガバナンスの工期の大半は、実はコンソールの外にあります。
まとめ——事実・解釈・使い方
- 【事実/仕様】 法人契約では学習非利用が規約で保証される（個人版には効かない）。統制の対応可否は機能・構成・地域で変わる。共有は権限設計次第で社内に漏れる。
- 【本記事の整理】 「大丈夫か」を契約・設定・運用設計に分解し、4つの柱と要件表に落とす。柱の分け方・要件表・公開前チェックは本記事側の実務的な整理です。
- 【使い方】 担い手を分けて語る。第4の柱（共有権限）は機密区分の「写像」として設計し、最強の統制は「そもそも載せない」。書類が先、設定が後。
「うちの機密は大丈夫か」への答えは、一言の安心ではなく、担い手ごとの根拠の束です。それを最初の数週間で揃えることが、生成AI内製化を止めないための投資になります。