生成AIセキュリティの実務｜OWASP 2026・PII・ガードレールと権限管理

生成AIを業務で使う際は、入力する情報だけでなく、検索する文書、外部ツール、出力先、ログまで含めて安全性を確認します。プロンプトへの注意書きや検出ツールの導入に加え、利用者の権限と業務上の承認をアプリケーション側で制御することが重要です。2026年10月25日時点で確認した公式資料を基に、OWASPのガイド、個人情報の扱い、ガードレール、検証と運用の確認点を整理します。

OWASPの版と対象を区別し、生成AIのデータと操作を把握する

OWASPには、LLMアプリケーション、データ、AIエージェントという異なる観点のガイドがあります。名称に同じ「2026」が含まれていても、公開時期や対象、分類が同じとは限りません。確認したリソースページの説明を整理すると、次のように使い分けられます。項目名や番号を引用する場合は、参照した文書と版を記録してください。

公式ガイド	主な対象	リソースページの掲載日
OWASP GenAI LLM Top 10 2026	LLMを使うアプリケーションの主要なセキュリティリスク	2026年8月3日
GenAI Data Security Risks & Mitigations 2026	学習・調整用データから入力、出力などに至るデータ層	2026年3月17日
Top 10 for Agentic Applications for 2026	計画や操作を行うAIエージェントのリスク	2025年12月9日

これらはリスクの整理や対策の検討に使う資料であり、参照した項目をチェックしただけで法令適合や安全性が認証されるものとは扱いません。利用する構成と業務への影響を先に確認し、該当するリスクに優先順位を付けます。従来の認証・権限、ライブラリの更新、ネットワークやバックアップの管理も併せて必要です。

最初に、利用者の入力、添付資料、検索元、モデルの実行先、連携するツール、出力先と保存先を図や一覧にします。「文書を読んで答えるだけ」の機能と、メール送信やデータ更新まで行う機能では、許可する操作と被害の範囲が異なります。誰の権限で何を読み、どこへ書き込めるかを、機能ごとに確認してください。

プロンプトインジェクションでは、入力や参照する情報の中の指示によって、意図しない動作へ誘導されることが問題になります。利用者が直接入力する場合に加え、Webページ、文書、検索結果やツールの応答に含まれる場合も想定します。Microsoftの入力・文脈・検索の防御に関する説明も、こうした内容を信頼しないデータとして扱い、指示と分離することを示しています。

そのため、検索した文書に別の処理を要求する文章があっても、業務上の指示や承認が追加されたとは判断しません。文書の出所、閲覧できる利用者、更新できる担当者を確認し、検索元を修正した場合に索引や継続して使う情報へどう反映するかも管理します。文書を検索・参照する処理と、モデルを学習させる処理は区別して整理します。

PII対策は、入力・検索・保存・ログの経路ごとに設計する

個人情報や営業秘密への対策では、まず業務上必要な情報と、利用を認める範囲を決めます。PIIは個人を識別する情報を表す用語として使われますが、具体的な情報の区分や取扱いは、適用される法令、利用目的、契約と社内ルールに照らして確認します。文字列を検出する仕組みだけに任せず、自由記述、添付ファイル、検索結果、連携先への送信も対象にします。

マスキングと、法令上の匿名加工情報は同じではありません。個人情報保護委員会の説明は、単にマスキングし、法令に定める適切な加工を行っていない場合は、匿名加工情報ではなく個人データだと示しています。氏名を置換できたから外部へ自由に送れる、と判断しないでください。対応表や他の情報から識別できる可能性と、元情報や対応表を誰が扱えるかも確認します。

利用するサービスについては、製品・契約・設定ごとに、学習への利用、保存される情報、処理場所、管理者や委託先のアクセス、削除の条件を確認します。学習に使われないことと、保存されないことは別の条件です。法人向け契約の有無だけで入力の可否を決めず、組織で認めた情報と用途に対応しているかを点検します。選定時の確認は、法人で使うAIの契約・データ・権限管理でも整理しています。

ログもデータの保存先です。OWASPのLogging Cheat Sheetは、アクセストークンやパスワード、機微な個人情報などをそのまま記録することを避ける扱いと、保存期間やアクセスの管理を示しています。すべてのプロンプトと応答を無条件に長期保存する方法にせず、調査に必要な処理ID、時刻、判断結果、実行結果と、本文を保存する必要性を分けて設計します。

アプリケーションのログ、監視基盤、開発時のデバッグ出力、外部のガードレールへの送信など、経路ごとに確認します。ローカルでモデルを動かす場合も、検索、埋め込み、連携ツールや監視が外部サービスを呼ぶ構成なら、その経路の管理が必要です。許可した環境と情報区分、困った際の相談先を利用者に示し、設定変更や例外の扱いを見直せる運用にします。

ガードレールの検査と、検索・ツールの権限制御を組み合わせる

ガードレールは、入力や検索結果、生成した応答、ツールの呼出しなどを検査・制御する仕組みです。例えばNVIDIA NeMo Guardrails v0.24.1のFAQでは、入力・検索・出力・ツールなどの検査箇所を分け、単独の仕組みであらゆる攻撃を防げるとはしていません。ツール名だけで選ぶより、どの経路で何を止め、何を変更し、何を記録するかを確認します。

確認する箇所	主な確認事項
入力・添付・検索結果	必要な情報の範囲、攻撃指示や機密情報の検出、文書の出所と利用者の閲覧権限
ツール呼出し	許可する操作、対象、引数、実行者の権限、必要な承認と実行結果
応答・保存先	出力形式と公開範囲、機密混入、検査前に表示・送信される経路、ログの取扱い

NVIDIAのLLM連携のセキュリティ指針は、利用者に対応する権限で外部の情報や機能へアクセスし、引数や応答を検証し、認証情報をモデルから分離する考え方を示しています。モデルが「許可された」と出力しただけで権限を増やすのではなく、保護するデータやツールを持つアプリケーション・サービス側で認証と認可を行います。

検索では、ログインできることと、すべての文書を読めることを分けます。利用者や組織をまたぐデータが混在する場合は、検索時にも対象文書へのアクセスを確認します。メール送信、削除、支払いなどの操作は、許可する対象と範囲、実行前に誰が何を確認するかを決めます。検出された文言の有無だけで操作を承認せず、送信先・変更対象・内容を確認できる形にします。

検査するタイミングも重要です。ストリーミングで応答を先に利用者へ渡す設定では、後から検査が止めても内容が既に届く場合があります。また、ガードレールの呼出しがタイムアウトしたときに、すべての構成が自動で安全側に停止するとは限りません。必要な検査を完了できない場合の中止、保留や人への引継ぎを、利用する構成で確認します。

従来のWebセキュリティも並行して点検します。生成した文字列をSQLやコマンド、画面表示へ渡す際は、用途に応じた検証が必要です。WAFを導入したことだけで文書権限やツール操作の確認が済むとは扱いません。WAFの役割と運用の確認点を参照し、アプリケーション内部で行う制御との担当を整理します。

検証・変更管理と、異常時に止めて戻す手順を整える

導入時は、何を守り、どの動作を許可し、何が起きたら止めるかを決め、その条件を検証項目にします。攻撃を検出した件数だけでなく、許可した業務が正しく動くか、必要な情報だけを返せるか、承認のない操作を実行しないかも確認します。実データを使う前に、必要な権限と検証環境を合意し、架空の情報などで条件を確かめる段階を置きます。

例えば、閲覧権限のない文書を参照できないこと、検索文書に含まれた指示で別の操作が始まらないこと、承認前の送信や削除が実行されないこと、検査が失敗した場合に定めた対応へ進むことを確認します。これらは自社の構成に合わせて選ぶ検証例です。許可のない実システムへの攻撃や、本番の顧客情報を使った試行を前提にするものではありません。

評価では、見逃し、正常な処理の誤遮断、遅延や費用、確認にかかる作業を分けます。PII検出も対象言語や情報の種類、データや設定で結果が変わるため、製品に搭載されているだけで自社の入力をすべて検出できるとは判断しません。モデル、プロンプト、検索元やツール、検査設定を変えたときは、過去の結果だけで済ませず、対象の構成で再確認します。

本番運用では、異常を確認する担当者、停止・継続を決める責任者、アクセス制限や代替業務、復旧の順序を決めます。バックアップの存在に加え、どの時点へ戻し、どの情報を照合して再開するかを確認してください。必要なイベントを既存の監視へつなげる際は、SIEMのログ管理と対応体制も参考になります。通知が届くことと、対応が完了したことを区別します。

自社のリスク整理や診断、対策の実装を進めたい場合は、renueのAI脆弱性診断支援サービスへ相談できます。公開サービスでは、コード分析、合意した範囲・テスト環境での検証、影響と改善方法の報告を案内しています。対策の整備、改修・刷新や移行は診断と分けて範囲を合意するため、生成AI固有の検証項目、データの取扱い、成果物と未確認範囲を事前に相談してください。確認した弱点を、担当者・優先順位と改善後の再確認につなげる進め方が重要です。