meguli
業務効率化読了 約9分

プロンプトインジェクション対策を開発工程に落とす設計レビューの観点

プロンプトインジェクション対策を、要件定義からリリース前までの設計レビューに落とし込む方法を解説。入力データ、外部連携、権限、テストで確認する問いを整理します。

こんにちは、平岡です。プロンプトインジェクション対策は、プロンプトの工夫だけで済ませず、入力・外部連携・権限・テストを開発工程ごとにレビューすることが重要です。設計段階で「何を信頼し、AIに何をさせ、どこで人が承認するか」を決め、テストとリリース判断まで記録に残します。

OWASP Top 10 for LLM Applications 2025でも「LLM01:2025 Prompt Injection」がリスク項目として掲載されています。ここでは、生成AIを組み込むサービスの企画・開発で、レビュー担当者が具体的に確認できる問いに置き換えます。

プロンプトインジェクションとは何か

攻撃の基本構造

NIST AI 100-2e2025は、プロンプトインジェクションを、信頼されていない入力を、設計者など信頼度の高い主体が作成したプロンプトに連結することを悪用する攻撃と定義しています。

アプリ設計者など、より高い信頼度の主体が作成したプロンプトに、信頼されていない入力を連結することを悪用する攻撃

レビューでは、システム側の指示と、利用者が入力した文章、Webページやファイルから取得した内容を同じ「プロンプト」として扱わず、出所ごとに区別できる設計かを見ます。OWASPは、利用者がモデルへの入力を操作する攻撃を直接型、Webページやファイルなど外部入力に埋め込まれた指示で会話文脈を操作する攻撃を間接型として説明しています。

間接型では、指示が人間に見えない形で外部コンテンツに含まれていても、モデルが解析すれば攻撃になり得ます。画面で見える文章だけを確認するレビューでは不十分です。

最初の確認点

各入力の出所と信頼度を分けて記載します。利用者の入力だけでなく、参照するWebページやファイルもレビュー対象に含めます。

想定する影響と守る対象

影響の整理

影響を「情報の漏えい」「権限のない操作」「意図しない出力」に分けると、守る対象を具体化しやすくなります。たとえば、社内文書を検索して回答する機能なら、参照できる文書と、回答に含めてよい情報を区別します。

OWASPの事例では、Webページの要約中にモデルが利用者へ機密情報を尋ねたり、JavaScriptやMarkdownを経由して情報を外部送信したりする挙動が示されています。また、履歴書ファイル内の指示によって要約や候補者評価が操作され、内容に反して「優秀な候補者」と出力する事例も挙げられています。

レビューでは「AIが誤った回答をするか」だけでなく、「その回答によって何が漏れるか」「どの機能が実行されるか」まで追います。守る対象を決めないまま、出力文の自然さだけを評価しても、重要な影響を見落とします。

  • 情報：AIが参照する文書、個人情報や機密情報など、入力・出力に含まれ得るもの
  • 操作：メール送信、削除など、AIや連携機能から実行できる処理
  • 出力：候補者評価や要約など、誤った内容が業務判断に使われる場面

要件定義で決めること

要件定義の問い

要件定義では、AIの利用目的、入力・参照する情報、許容する操作を一組で決めます。「問い合わせへの回答」が目的なら、どの文書を根拠にするのか、回答に含めてはいけない情報は何か、回答後に外部操作まで許すのかを記述します。

想定外の入力や応答があったときの扱いも要件に含めます。たとえば、要求された形式に沿わない出力を画面に表示するのか、処理を止めるのか、担当者へ確認を回すのか。機能ごとに期待する振る舞いを先に定めれば、テストで合否を判断できます。

利用目的：AIに何をさせるか
入力・参照情報：どの情報を渡し、何を参照するか
許容操作：AIや連携先に何を実行させるか
想定外の応答：停止・保留・人への確認のどれにするか
要件の判断軸

「何を答えるか」だけでなく「何を参照し、何を実行できるか」を一緒に定義します。目的に不要な情報や操作は、要件に含めないことがレビューの出発点です。

入力データとプロンプトの境界を設計する

入力設計の確認点

ユーザー入力、参照データ、システム側の指示を、設計書やデータフロー図で区別します。OWASPは、外部コンテンツを利用者のプロンプトから分離し、信頼できない入力の出所を明示する対策を示しています。レビューでは、たとえば「顧客の質問」と「検索で取得した社内文書」が、どの段階でAIに渡るかをたどります。

入力の検証やフィルタリングを設ける場合も、それだけでリスクが解消すると扱わないことが大切です。OWASPは、RAGやファインチューニングを利用しても、プロンプトインジェクションの脆弱性を完全には軽減できないとしています。入力を加工した後にも、アプリケーション側で出力や操作を制御する設計かを確認します。

出力形式を指定する場合は、形式に沿っているかを決定論的なコードで検証する方法も、OWASPの2025年版対策に含まれています。たとえば、業務システムへ渡すデータの形式が要件で決まっているなら、形式不一致を検出した際の処理まで設計書に記載します。

外部連携の設計をレビューする

外部連携の問い

Web検索、ファイル参照、プラグインなどを介して外部情報をAIに渡す設計では、取得する情報、AIに渡す範囲、外部へ送信する情報を別々に確認します。要約機能なら「取得したページの内容を読む」だけなのか、「その内容に含まれる指示を実行する」可能性があるのかを設計上の問いにします。

連携先へ情報を送る場合は、何を渡すのかを項目単位で洗い出し、利用目的に照らして必要な範囲かをレビューします。Webページの要約中に機密情報を尋ねたり、JavaScriptやMarkdown経由で外部送信したりするOWASPの事例を踏まえると、モデルの応答をそのまま外部連携の入力にする設計は、送信内容や実行条件まで追う必要があります。

取得元：Webページ／ファイル／連携先
AIに渡す内容：取得情報のうち対象とする範囲
外部への送信内容：送信する情報と利用目的
応答の反映先：画面表示／後続処理／連携機能

権限の境界と操作の制御を確認する

権限設計の観点

OWASPは、LLMを信頼できない利用者として扱い、LLM・外部情報源・プラグインや下流機能の間に信頼境界を設けるよう推奨しています。レビューでは、AIが接続先で使うAPIトークンを機能ごとに分けられるか、各トークンに意図した操作に必要な最小限の権限だけを付与しているかを確認します。

特権操作については、AIの応答を受けて即時実行するのか、人の承認を挟むのかを決めます。OWASPは、メール送信や削除などの操作の前に、アプリケーションが利用者の承認を求める対策を挙げています。

たとえば、AIがメール文面を作る機能と、メールを送信する機能は、設計上の権限を分けて考えます。送信前に利用者が宛先・本文を確認するのか、そもそもAIに送信権限を与えないのかを、操作単位で決めます。

操作権限に注意

モデルの出力が妥当そうに見えることを、操作の承認として扱わない設計にします。メール送信や削除などは、利用者の承認を求める経路と、実行できる権限の範囲を分けて記録します。

実装・テストで確認する問い

テストの観点

テストは、入力経路ごとに「意図しない指示が含まれた場合」「情報が不適切に扱われた場合」「操作要求が含まれた場合」を確認します。利用者の入力だけでなく、Webページやファイルなど外部コンテンツから入る経路も対象です。

期待する振る舞いは、テスト実施前に決めます。たとえば、形式指定と異なる応答は後続処理へ渡さない、メール送信は利用者の承認がない限り実行しない、といった判定条件です。OWASPが挙げる敵対的テストと攻撃シミュレーションも、これらの条件を確かめる方法として設計に含めます。

  • 入力パターン：利用者入力、外部ページ、アップロードファイルなど、経路ごとの確認
  • 情報の扱い：参照範囲外の情報を出力しないか、外部送信しないか
  • 操作の結果：承認なしで特権操作が実行されないか
  • 記録：評価条件、期待結果、実際の結果、未対応事項

履歴書の要約・評価機能なら、ファイルに評価を誘導する指示が含まれたケースをテストし、内容に基づく評価になっているかを確認します。結果は「問題なし」だけで終わらせず、どの入力で何を期待し、実際にどう動いたかをレビュー記録に残します。

リリース前レビューで確認すること

リリース前の確認

リリース前は、要件定義で決めた利用目的・情報・許容操作と、設計・実装・テストの結果を照合します。未対応のリスクや制約が残る場合は、対象機能、想定される影響、実施したテスト、残る課題をまとめ、リリース可否の判断材料にします。

判断記録には、承認者だけでなく、判断の根拠と見直し条件も含めます。たとえば「外部ファイルを使う機能で、想定した入力テストを実施した」「特権操作には利用者の承認を設けた」のように、要件と確認結果が対応する形で記録します。

リリース判断

要件・設計・テストの記録をひと続きにし、未対応リスクと残る制約を明示します。リリース後に機能や連携先を変更する場合も、見直しが必要なレビュー項目を追える状態にします。

まとめ

プロンプトインジェクション対策は、入力をフィルタリングするだけで完結しません。出所の異なるデータを区別し、外部連携の範囲と権限を制限し、特権操作には人の承認を置き、テスト結果をリリース判断につなげます。

次の一歩として、まず自社サービスの機能を一つ選び、入力経路・参照情報・実行可能な操作を書き出してみてください。その一覧に、テスト条件と記録欄を加えることで、要件定義からリリース前まで使える設計レビュー項目にできます。「何を信頼し、何を許可し、どこで止めるか」を工程をまたいで記録することが、プロンプトインジェクション対策の土台です。

参考・出典

#プロンプトインジェクション#生成AI#セキュリティ#設計レビュー
この記事をシェア
𝕏 でポストB! はてブ
m
株式会社meguli

AI×DXで、社会の巡りをよくする。中小企業の現場で使えるAI活用・業務改善の実践情報を発信しています。

ご相談・お問い合わせはこちら →

あわせて読みたい

製造業の見積自動化はどこまで任せる？人とシステムの役割分担

LLM RAGの回答精度をどう測る？検索・生成を分けた評価方法

エージェント型AIとは？ChatGPTとの違いを機能・実行範囲で整理

記事一覧へ戻る