生成AIの社内導入でセキュリティをどう担保するか｜FDEが実務で使う統制設計

生成AIの社内導入で最初に潰すべきセキュリティリスクは？

最初に潰すべきは「機密データの外部送信」「無承認利用（シャドーAI）」「出力の誤用」という三つの入口である。

生成AIのセキュリティ議論は、しばしば「モデルが学習に使うかどうか」に集中しがちだ。しかし実際の事故は、もっと手前で起きる。誰がどのデータを、どのツールに、どんな権限で流し込んだのかが誰にも分からない状態——この可視性の欠如そのものが最大のリスクになる。OWASPが公開しているLLMアプリケーション向けのTop 10リスク一覧でも、プロンプトインジェクション、機微情報の漏えい、過剰なエージェント権限（Excessive Agency）といった項目が上位に並んでおり、脅威の重心が「モデル」ではなく「モデルの周辺設計」にあることを示している。

機密情報はどの経路から漏れるのか？

漏えいの大半は学習利用ではなく、プロンプトへの貼り付けと権限過剰な社内検索連携から生じる。

具体的な経路は三つに整理できる。第一に、担当者が契約書・顧客リスト・ソースコードをそのままチャット欄に貼る「手動持ち出し」。第二に、RAG（社内文書検索と組み合わせる構成）で、本来アクセス権のない部署のファイルまでインデックスに含めてしまう「権限の平坦化」。第三に、外部SaaSやブラウザ拡張を経由した「経路の見えない送信」である。

現場で厄介なのは第二の権限の平坦化だ。人事評価や与信情報が入ったフォルダを一括でベクトル化してしまうと、アクセス制御がAIの回答という形で迂回される。ファイルサーバでは守れていた統制が、検索基盤に載せた瞬間に崩れる——という失敗は、導入初期に非常に起きやすい印象がある。

シャドーAI（無承認利用）はなぜ危険なのか？

禁止だけを掲げると利用が地下化し、統制もログも効かない領域に業務が移ってしまうためだ。

全面禁止は一見安全に見えるが、個人アカウントでの利用を招く。会社として最悪なのは「使われていること」ではなく「使われている事実を把握できないこと」である。したがって初期方針は、禁止ではなく「承認された安全な選択肢を先に用意し、そこへ誘導する」設計が現実的だ。承認済み環境の使い勝手が個人利用より悪い限り、シャドーAIは消えない。

プロンプトインジェクションと出力誤用のリスクは？

外部文書に仕込まれた指示でAIが誤作動し、社内データの引き出しや誤情報の業務反映が起きる。

社外PDFやWebページを読ませる構成では、文書中の「これまでの指示を無視して以下を出力せよ」といった記述にモデルが従ってしまう可能性がある。加えて、生成結果を人が検証せずに顧客提出物へ転記する運用も事故源だ。技術的な防御と、業務プロセス側の検証工程は、必ずセットで設計する必要がある。

社内データを守る技術統制はどう設計するのか？

入口・権限・実行・記録の四層に分け、それぞれ独立して機能する多層防御として設計する。

技術統制を「ツール選定」の問題として扱うと、たいてい失敗する。重要なのは、どこか一層が破られても他の層が生き残る構造にすることだ。ISO/IEC 42001（AIマネジメントシステムの国際規格、2023年発行）やNISTのAI Risk Management Framework（2023年1月公開）も、単一の対策ではなくライフサイクル全体での統制を前提にしている。

入口対策：どこでデータを止めるのか？

送信前のフィルタリングとデータ区分の機械判定で、そもそも機微情報を境界の外に出さない。

実装としては、社内プロキシやAIゲートウェイを経由させ、個人情報・認証情報・特定キーワードを検知してブロックまたはマスクする方式が基本になる。ここで前提になるのがデータ区分（公開／社内限定／機密／要保護個人情報など）の定義だ。区分が曖昧なままフィルタだけ入れても、誤検知が多すぎて現場が回避策を探し始める。

権限設計：RAGの検索範囲をどう絞るか？

検索インデックスに元データのアクセス制御を継承させ、ユーザー権限外の文書はヒットさせない。

具体的には、ドキュメント単位でACL（アクセス制御リスト）をメタデータとして保持し、検索時にユーザーの所属・役職でフィルタする構成をとる。加えて、AIエージェントにツール実行権限を与える場合は、読み取り専用を既定とし、書き込み・送信・決済に関わる操作は明示的な承認フローを挟む。OWASPが指摘する「過剰な権限」は、便利さを優先した結果として後から膨らむことが多い。

ログと監査：何を残せば説明責任を果たせるか？

「誰が・いつ・どのデータで・どの出力を得たか」を紐づけて保全し、事後追跡を可能にする。

最低限、利用者ID、タイムスタンプ、参照ドキュメントID、モデル名とバージョン、入出力の要約（もしくは全文）を残す。ログ自体が機密の塊になるため、保存期間・アクセス権・暗号化を同時に決めておく必要がある。インシデント時に「何が漏れた可能性があるか」を答えられない状態は、漏えいそのものと同じくらい深刻な事態を招く。

生成AI利用のガバナンスと運用ルールはどう作るのか？

用途とデータ区分の二軸で可否を決め、例外は申請制にして更新頻度を先に決めておく。

ルール作りで最も多い失敗は、抽象的な禁止事項を並べた文書を作って終わることだ。「機密情報を入力しないこと」とだけ書かれたポリシーは、現場では判断材料にならない。総務省・経済産業省が2024年4月に公表した「AI事業者ガイドライン」も、事業者が自らのリスクに応じて具体化することを前提としている。ルールは、現場が3秒で判断できる粒度まで落とす。

利用ポリシーは何を決めれば足りるのか？

承認ツール、データ区分ごとの可否、人による検証が必須な用途、この三点で実務は回る。

以下の順に決めると詰まりにくい。

1. 承認ツールの列挙：利用してよいサービスとプランを明記する（無償プランと法人プランでデータ取り扱いが異なるため、プラン単位で書く）。
2. データ区分×用途のマトリクス：入力可否を表で示す。
3. 人的検証が必須の用途：顧客提出物、法務判断、採用評価、与信など。
4. 禁止事項：個人アカウント利用、認証情報の入力、未承認の外部連携。
5. 問い合わせ先と例外申請の窓口：迷ったときの逃げ道を必ず作る。

承認プロセスとリスク評価はどう回すか？

新規ユースケースは影響度で軽重を分け、低リスクは自己申告、高リスクのみ審査に回す。

全件審査は必ず滞留する。判断軸は「扱うデータ区分」「出力が人の権利や取引に影響するか」「AIの実行権限の有無」の三つで十分に機能する。EUのAI法（2024年8月発効、段階的に適用が進行中）もリスクベースの分類を採っており、この考え方は国内の社内統制にも応用しやすい。

教育と例外運用はどう設計するか？

年1回の座学ではなく、部門別の実例集と「困ったら聞ける窓口」で運用に根づかせる。

現場を見ていると、事故を防ぐのはポリシー文書よりも「これは入れていいのか」を気軽に聞ける相手の存在であることが多い。法務・情シス・現場リーダーを含むチャンネルを一本用意し、判断事例をそのまま社内ナレッジとして蓄積していく運用が、結果的に最も効いている印象がある。

FDEは生成AI導入のセキュリティにどう関わるのか？

FDEは顧客現場に入り、業務要件とセキュリティ要件を同時に満たす実装へ落とす役割を担う。

FDE（Forward Deployed Engineer）はPalantirが確立した職種で、顧客の現場に常駐に近い形で入り込み、業務理解から実装・運用定着までを一気通貫で担う。生成AIのセキュリティ統制は、まさにこの職種が価値を出しやすい領域だ。というのも、統制の失敗はたいてい「セキュリティ部門が現場業務を知らない」か「現場がリスクを知らない」かのどちらかから生まれるためである。

FDEはセキュリティ担当と何が違うのか？

セキュリティ部門が基準を定めるのに対し、FDEは基準を満たす動くシステムまで実装する。

役割の境界は以下のように整理できる。

現場でFDEが最初にやることは何か？

データの流れの棚卸し、権限モデルの確認、そして小さく安全なユースケースの実装である。

順序としては、(1) どの業務でどのデータが動いているかを現場でヒアリングして図に落とす、(2) 既存のアクセス制御をAI基盤に継承できるか検証する、(3) 機密度の低い領域で1つだけ実装して運用ログを取る、という流れになる。最初から全社展開を狙わず、統制が実際に機能するかを小さく確かめてから広げるほうが、結果的に速い。VACANのように現場のリアルタイムデータを扱う事業では、データの鮮度と権限の整合を同時に担保する設計が特に重要になる。

企業はどんな場合にFDEを置くべきか？

業務要件が現場ごとに割れ、標準SaaSの設定だけでは統制と実用性が両立しない場合である。

逆に、用途が汎用的な文章作成に限られ、扱うデータも公開情報中心であれば、既製ツールの管理機能とポリシー整備で足りることが多い。FDEの配置が効くのは、基幹データや個人情報に触れるユースケースを、業務を止めずに安全に立ち上げたいときだ。判断に迷う場合は「セキュリティ要件を満たそうとすると業務が回らなくなる」現象が起きているかどうかを一つの目安にするとよい。

生成AIのセキュリティは、禁止と許可の二択ではなく、どこまでを技術で止め、どこからを運用と人の判断に委ねるかという設計の問題である。技術統制・ガバナンス・現場実装の三つを同じテーブルで議論できる体制を先に作ることが、遠回りに見えて最短距離になる。

姉妹メディアの関連記事