【2026年 ITトレンド】生成AI利用時の「情報漏洩」リスク最新対策法：技術的防壁とガバナンスの新常識

1. なぜ「設定」では守れないのか — 学習と参照の違い、そして新しい攻撃

国内企業で生成AIの業務活用が広がるなか、入力した情報の取扱いをどう統制するかが論点になってきました。

かつて情報セキュリティはIT部門の「守りの管理事項」でした。しかし生成AIでは、入力した機密データがモデルに取り込まれれば営業秘密が回収不能なまま失われ、信用失墜と事業継続性に直結します。AIセキュリティは「IT管理者の作業」ではなく、企業価値を守る経営テーマです。

「学習」と「参照」は何が違うのか

最も混同されるのがこの2つですが、技術的には別物です。

学習に使われた情報は、モデル内部の数値（パラメータ）へ組み込まれ、ファイルのように削除できません。取引先に「入力したが学習されたか分からない」と答える状態では、秘密保持義務（NDA）の説明責任を果たせません。

攻撃はプロンプト経由へ移った

現在のAIは、マルウェア感染ではなく自然言語のプロンプトや参照データそのものを悪用されます。

• 直接プロンプトインジェクション：「これまでの指示を無視せよ」といった命令を直接入力し、内部設定や機密情報を出力させる。
• 間接プロンプトインジェクション：AIが参照するWebページ・メール・ファイルに悪意ある指示を埋め込む。AIがそれを読んだ時点で誤判定や機密情報の外部送信が起きる。利用者が何も悪いことをしていなくても成立する点が厄介です。
• DoS攻撃：膨大な計算を強いるプロンプトで過負荷をかける。応答停止だけでなくクラウド利用料の過剰請求も招く。
• データポイズニング／モデル抽出：参照データを汚染して不正な出力を仕込む、大量の問い合わせでモデルを複製する。

とくにRAG（Retrieval-Augmented Generation＝検索拡張生成）ではデータが形を変えながら流れ、従来の境界型セキュリティでは防ぎきれません。対策も研究の途上にあります。RAGのプライバシーリスクを整理した学術サーベイは、緩和策の多くが再現性や実運用可能性の観点で十分に検証されていないと指摘し、再現用コードを公開している研究も約40%にとどまります。「特定の製品を1つ入れれば万全」という解は存在しません。

従来型DLPが通用しなくなった理由

従来のDLP（Data Loss Prevention＝データ持ち出し防止）は、「社外秘」「厳秘」といった特定のキーワードを検知して通信を遮断する仕組みでした。しかし生成AIでは、意味を保ったまま言い換えれば簡単にすり抜けます。キーワードではなく文脈と意図を見て判定する仕組みが必要です。

2. 多層防御への移行 — 何から着手し、どこまで守るか

単一の製品や注意喚起だけでは防ぎ切れません。総務省は令和8年3月27日、「AIのセキュリティ確保のための技術的対策に係るガイドライン」を公表しました。同ガイドラインは、対策例を単独で実施しても脅威の要因を完全には排除できないことを前提に、複数の対策を組み合わせてリスクを低減することを想定し、脅威によっては「より重層的な対策が必要となり得る」ことにも留意を求めています（なお自律的に動作する「AIエージェント」は、技術が発展途上のため対象外です）。

3つのアプローチの比較

情報漏洩を防ぐ手段は3つに整理できます。

設定や注意喚起に依存する防御は、組織が大きくなり人が入れ替わるほど必ずヒューマンエラーの穴が空きます。「個人の注意」に頼る運用から「構造として学習・漏洩させない設計」へ移すことが、費用対効果でも最も確実です。

技術的対策の要点

ガイドラインが役割別に示す対策のうち、発注・選定時の確認要点は次のとおりです。

• ガードレール：AIモデルの外側に検査機構を置き、①入力プロンプトの検証・無害化 ②外部参照データに混入した悪意ある指示の検知 ③出力への機密情報の混入の検証を行う。
• 最小権限の原則：AIが参照するデータベースやファイルへの権限を役割に応じて絞り、「AIだから全部見られる」状態にしない。
• システムプロンプトの耐性向上：APIキーなどの機密を、AIへの指示文に直接書き込まない。
• 監査ログとレートリミット：誰が何を入力したかを追跡でき、大量リクエストを抑止する。

なお、キーワード遮断に代わり、守りたい内容を自然言語で定義してブロックする製品も登場しています。「自社のM&Aの相手企業名・取引金額を含む入出力はブロックし、M&Aの一般的な解説は許可する」といった条件を平易な言葉で設定でき、利便性を落とさず「意味としての機密」を守れます。

技術対策は「法的防壁」にもなる

技術的対策は、インシデント防止だけが目的ではありません。不正競争防止法第2条第6項において、自社のデータが「営業秘密」として法的保護を受けるには、有用性・非公知性に加えて秘密管理性を満たす必要があります（総務省ガイドラインもこの要件に触れています）。アクセス権限の管理、ログの保存、ガードレールの設置を実際に講じている事実を示せて初めて、流出時にも法的保護を主張できる可能性が高まります。対策を打っていること自体が、法的な資産になります。

実践例：機密性と業務効率を両立させる

「セキュリティを厳しくすると精度や利便性が落ちる」という懸念は、構造を選べば解消します。

物流大手のニッコンホールディングス株式会社は、重要会議の議事録作成にAIツール「Otolio」（旧スマート書記・エピックベース株式会社）を導入し、従来は完成まで複数日を要していた議事録を翌営業日には共有できるようになりました。同製品は、入力データをAIの学習に使わない設計と国内データセンターでの暗号化保管を掲げ、ISMS（ISO/IEC 27001）認証を取得しています（提供元の公表情報）。

注目すべきは選定理由です。同社は「セキュリティ面でも納得できた」としつつ、一番の決め手に挙げているのは検討期間中の対応の丁寧さで、価格は他社と大差なかったとしています。セキュリティ要件は「満たして当然の前提」であり、その先の成否は運用を支える体制で決まります。

参照型の設計では、過去の議事録や社内用語集を、要約や文字起こしを行うその瞬間だけAIが読み込みます。モデル本体に取り込まれず、それでも社内用語を踏まえた精度が得られます。「学習させない」ことと「精度を上げる」ことは、対立しません。

まとめ：禁止ではなく、安全な環境を用意する

最大のリスクは「設定の選択ミス」ではなく、仕組みを理解しないまま使わせることです。

流出を恐れて一律に禁止するのは逆効果です。制限が厳しすぎる職場では、現場が「シャドーAI」（会社が把握していない個人利用）へ流れ、管理が及ばなくなります。経営とIT部門の責務は、禁止ではなく安全に使える環境を組織として用意することです。