OWASP GenAIデータセキュリティ2026で見えてきた、企業のAI活用で本当に見直すべきポイント

生成AIのセキュリティというと、プロンプトインジェクションやモデル悪用に目が向きがちです。ですが、現場で実際に事故につながりやすいのは、その手前とその周辺にある「データの流れ」です。

OWASPが2026年3月17日に公開した「OWASP GenAI Data Security Risks & Mitigations 2026 Version 1.0」は、その点をかなり正面から扱っています。モデル単体の防御論ではなく、学習、RAG、ツール連携、ログ、監視、メモリ、エージェント間連携まで含めて、どこでデータが生まれ、移動し、変換され、残るのかを見に行く構成です。

OWASPが今回強調したのは「AIモデル」ではなく「AIを取り巻くデータ面」

このガイドは、OWASP Top 10の置き換えとして出されたものではありません。位置づけとしては、LLM、GenAI、Agentic AIに特有のデータセキュリティへ焦点を当てた補助線であり、2025年の「LLM and Gen AI Data Security Best Practices Guide」を発展させたものです。さらに今回は、リスクと対策の整理を行う文書と、実装寄りのガイドを分ける構成になっており、実務で参照しやすくなっています。

この整理が効いている理由は明快です。企業のAI導入では「モデルは閉域で動かしたから安心」「API接続先を選んだから大丈夫」と考えがちですが、実際にはその前後で扱うデータのほうが広く、長く残ります。プロンプト、添付ファイル、検索で引いたRAG断片、ツールの実行結果、推論ログ、トレース、エージェントのメモリなどが、思っている以上に多層で残るからです。

従来のアプリケーションより厄介なのは、信頼境界が会話の中で平坦化されること

この文書でいちばん重要だと感じたのは、コンテキストウィンドウが複数の信頼領域をひとつの推論空間に押し込んでしまうという整理です。システムプロンプト、ユーザー入力、RAGで取得した文書、ツール出力、会話履歴が、内部的なアクセス制御なしに同じ場へ並びます。OWASPは、この構造自体が従来の計算モデルと違う前提だと明記しています。

ここが怖いのは、機密情報が「保管場所から直接漏れる」だけではないからです。推論の材料として一度混ざった情報が、回答文、デバッグログ、監視基盤、別ツールへの引き渡し、別エージェントへの委譲という形で、別の出口から出ていく可能性があります。しかも現状、あるコンテキスト片だけを「推論には使ってよいが、そのまま出力してはいけない」とモデル内部で厳密に区別できるわけではありません。

GenAIで守るべきデータは、思っているよりずっと広い

OWASPは、GenAIにおけるデータセキュリティをかなり広く定義しています。対象は学習データだけではありません。原本データ、埋め込みやインデックスのような派生データ、チェックポイントやアダプタなどのモデル成果物、プロンプトやツール呼び出しなどの実行時データ、ログやトレースのような観測データ、さらにエージェントのメモリや委譲チェーン、キャッシュされた資格情報まで含めています。

この整理は、企業側の実感とも合っています。たとえば「元データへのアクセスは絞った」「外部送信は制限した」という状態でも、埋め込み、ベクターストア、可観測性基盤、一時キャッシュ、ラベリング用の出力データが残っていれば、そこが新しい露出面になります。機密性だけではなく、完全性、可用性、真正性まで含めて見ないと、AI導入後のデータ保護は抜けやすいということです。

21のリスクカテゴリの中でも、先に見るべきもの

OWASPはこのガイドで21のリスクカテゴリを並べています。漏えい、認証情報露出、シャドーAI、データ汚染、検証不備、ツール連携、ガバナンス、法令順守、マルチモーダル漏えい、会話の越境混線、LLM-to-SQL、ベクターストア、テレメトリ、過剰なコンテキスト、ブラウザ支援AIの過剰権限、可用性、推論攻撃、ラベラー露出、モデル流出など、かなり網羅的です。

特に企業の実装で先に効いてくるのは、次のあたりです。

機密情報の漏えいは、いまも基礎リスクの中心にある

生成AIでは、機密情報がそのまま漏れるだけでなく、ほぼ原文に近い形で再出力されることがあります。入力欄、RAG検索結果、ログ、監視トレースなど、出口が一つではないためです。しかも、希少なデータを含む微調整モデルやアダプタは、抽出面として鋭くなりやすいとOWASPは見ています。

エージェントの認証情報は、侵害の足場になりやすい

Agentic AIでは、人ではなくエージェントがサービスアカウント、APIキー、OAuthトークン、ツール資格情報を持ちます。これがオーケストレーション層に広く散らばる一方で、ライフサイクル管理は追いつきにくい。結果として、権限が広すぎる、期限が長すぎる、ログに残ってしまう、といった古典的な問題が、より見えにくい形で再発します。OWASPはここで、細粒度のRBAC/ABAC、短命トークン、JITアクセスを強く推しています。

シャドーAIは、単なる社内ルール違反では済まない

未承認のAI SaaSやブラウザエージェントに、顧客情報、設計資料、ソースコードを貼り付ける行為は、もはや珍しくありません。OWASPはこれをポリシー違反としてではなく、正式な統制外でデータ系の保護が外れるリスクとして扱っています。データの保存先、学習利用、地域、契約、監査権、削除対応が不透明なまま使われるためです。

RAG、ベクターストア、自然言語SQLは、便利さのぶんだけ設計差が出る

文書検索や「自然文でデータを聞ける」仕組みは、現場ではかなり魅力的です。ただ、ここで認可設計を甘くすると、一気に事故面が広がります。OWASPは、RAGでは文書単位のACL、検索時のマスキング、ユーザー・テナント単位の分離を重視しています。ベクターストアについても、クライアント側のフィルタ任せではなく、サーバー側でのテナントスコープ強制を求めています。自然言語からSQLやGraphクエリを生成する仕組みについては、任意クエリをそのまま流さず、ストアドプロシージャやパラメータ化テンプレート経由に限定すべきだとしています。

静かに危ないのは、監視ログとブラウザ側AI

運用が進むほど、ログとトレースは増えます。ところがGenAIでは、そこにプロンプト本文、ツール出力、資格情報、個人情報が混ざりやすい。OWASPは、本文レベルのログを既定で無効にし、高リスク項目は保存前にマスクまたはトークン化する「least-logging」を勧めています。

同時に、AIブラウザ拡張やローカルCopilotも見落としにくい論点です。タブ、DOM、クリップボード、ローカルファイル、認証済みセッションに触れられるため、権限設計を誤ると、ユーザー権限そのままで情報を持ち出されます。OWASPは、全サイト読取りやフルファイルアクセスを避け、サイト単位・プロジェクト単位の権限に絞るべきだとしています。

実務で先に効くのは、派手なAI対策より「出しすぎない」「残しすぎない」設計

OWASPの実務向けなところは、対策をTier 1、Tier 2、Tier 3に分けている点です。Tier 1は既存ツールでも比較的着手しやすい基礎対策、Tier 2は設計変更や部門横断の調整が必要な強化策、Tier 3は成熟した組織向けの高度な対策、という読み方ができます。

まず着手しやすいのは、次のような内容です。

• プロンプトと応答の入出力スキャン
• RAG検索時のマスキングと文書ACL適用
• エージェントへの短命トークン付与とJITアクセス
• 本文ログの既定無効化、資格情報やPIIの保存前マスキング
• ラベリングや人手確認に回すデータの最小化と識別子の伏せ込み

次に見直したいのは、アーキテクチャ側です。ベクターストアのテナント分離をクライアント実装任せにしないこと、外部LLMに渡す前のフィールド単位マスキングをゲートウェイで強制すること、自然言語SQLを任意SQLにしないこと、監視データの保存期間を元データ以下に抑えること。このあたりは、一度組んだあとで直すと重いので、早い段階で設計に入れておいたほうが楽です。

高度な段階では、マルチモーダルを含むレッドチーミング、微調整時の差分プライバシー、埋め込み空間への異常な問い合わせ監視などが入ってきます。ここまで来ると単発の設定ではなく、AIを継続運用する前提のセキュリティプログラムになります。

AI-DSPMが必要になるのは、「どこに残っているか」を人間が追えなくなるから

OWASPは、GenAI向けDSPM、つまりAI-DSPMをかなり重視しています。要点は、AI関連資産を洗い出し、分類し、データフローを見える化し、そこにポリシーを結び付けることです。対象には、学習データやRAG元文書だけでなく、プロンプトテンプレート、システムプロンプト、ベクターデータベース、埋め込みパイプライン、ツール連携、キャッシュ、ログ、トレースまで含まれます。

さらに重要なのは、派生物にもラベルと統制を引き継ぐという考え方です。元ファイルだけ機密区分を付けても、埋め込み、要約、キャッシュ、バックアップ、ラベリング出力にそれが継承されなければ意味がありません。OWASPは、ソースから前処理、埋め込み、索引化、検索、プロンプト組み立て、生成、ログまでの系譜管理を求めており、DBOMのような考え方で来歴を追える状態を勧めています。

モデルを守る前に、流れるデータを見直す

このOWASP文書を読んで改めて感じるのは、生成AIのセキュリティを「AI専用の新しい脅威」だけで語るのは、少し危ういということです。実際に事故になりやすいのは、入力しすぎること、拾いすぎること、渡しすぎること、残しすぎることです。

現場で最初に見直すべきなのは、モデルの精度より先に、どのデータがどこへ流れ、誰が見られて、どこに残るのかという基本設計かもしれません。生成AIの導入が進むほど、この確認は後回しにしにくくなります。今ある構成を一度棚卸ししてみるだけでも、見え方はかなり変わるはずです。