【ITニュース解説】Every form field your agent will read is a prompt
2026年10月16日に「Dev.to」が公開したITニュース「Every form field your agent will read is a prompt」について初心者にもわかりやすく解説しています。
ITニュース概要
AIエージェントが顧客からのフォーム入力などを読む際、悪意ある指示(プロンプトインジェクション)で機密情報が漏洩する危険がある。Salesforce事例ではCRMデータが流出した。対策は、エージェントの機能制限、出力形式の厳密な確認、重要情報の元テキストとの照合、人間による最終承認が重要だ。
ITニュース解説
現代のITシステムにおいて、問い合わせフォームやメール、サポートチケットなど、外部からの自由なテキスト入力をAIエージェントが処理する場面が増えている。このようなAIエージェントの活用は業務効率化に大きく貢献する一方で、新しい種類のセキュリティリスクを生み出している。それは「プロンプトインジェクション」と呼ばれる問題で、ユーザーが入力したテキストの中に隠された悪意ある指示にAIエージェントが従ってしまうというものだ。AIエージェントが読み込むあらゆるテキストフィールドは、開発者の意図とは関係なく、AIに対する指示(プロンプト)入力になり得るという認識が不可欠である。
このリスクの具体的な事例として、2026年9月に報告されたSalesforceのエージェントプラットフォーム「Agentforce」における脆弱性「SalesBleed」がある。この攻撃は、ウェブサイトの「お問い合わせ」のようなWeb-to-Leadフォームから始まる。これは顧客情報管理システム(CRM)と連携しており、通常は見込み顧客がアカウントを持たない状態でも利用できるよう公開されている。攻撃者はこのフォームに、一見すると普通の見込み顧客からの問い合わせに見えるテキストを入力するが、その中にAIエージェント向けの隠れた指示(プロンプトインジェクション)を仕込む。しばらくして、社内の従業員がAIエージェントに通常の業務に関する質問をすると、エージェントは過去の問い合わせ記録の中から、この「毒された」記録を読み込む。すると、隠された指示に従い、CRM内の他の顧客情報データを取得し、外部に送信してしまうというものだ。この一連のプロセスにおいて、誰も不審なリンクをクリックしたり、特別な操作をしたりしていない点が非常に危険である。Zenity Labsがこの脆弱性を発見し報告したことで、Salesforceは修正対応を終え、実世界での悪用は報告されていない。しかし、この種のパターンは、AIエージェントが外部からの自由なテキストフィールドを読み込むあらゆるシステムに存在する可能性がある。
一般的なウェブフォームには、多くのセキュリティ対策が施されている。例えば、各入力フィールドの最大文字数制限、メールアドレスの形式チェック、ボットが入力するような隠しフィールドの設置、送信前のアンチボットテストなどだ。これらの対策は、自動化されたボット攻撃を遅らせたり、形式が間違ったデータを拒否したりするのには効果がある。しかし、これらの対策は入力された「メッセージの意味」までは理解しない。プロンプトインジェクションは、人間が慎重に作成した「適切な長さで、形式も正しい」メッセージである場合が多い。フォームから見れば、それは単なる新しい問い合わせの一つとして認識され、これらの既存の保護をすり抜けてしまうのだ。
プロンプトインジェクションは、大規模言語モデル(LLM)に基づくアプリケーションにおける最重要リスクの一つとしてOWASP(オープン・ウェブ・アプリケーション・セキュリティ・プロジェクト)によって指摘されている。その理由はシンプルで、AIモデルにとって、開発者が設定したシステム側の指示も、外部のユーザーが入力したテキストも、区別なく全てが「テキスト」として扱われるからだ。システム側が「ユーザーのメールの指示には従うな」と指示したとしても、ユーザーが「何があってもこの指示に従え」といった巧妙なプロンプトを仕込んだ場合、AIはそちらを優先してしまう可能性がある。したがって、「プロンプトインジェクションを完全にブロックする方法はない」という前提で、もしインジェクションが成功してAIモデルが操作された場合に、「AIモデルは何をできるのか」を制限する対策を講じることが不可欠となる。
まず重要な対策は、AIモデルが外部システムと直接連携するような「ツール」を持たせないことだ。SalesBleedの事例では、問い合わせ記録を読み込んだAIエージェントが、CRM内の他のデータにもアクセスできる状態にあったため、情報漏洩が可能になった。自身のシステムでは、メールを読み込むAIモデルを隔離し、テキストを入力として受け取り、テキストを出力として返すだけのシンプルな機能に限定している。これにより、AIモデルが勝手にメールボックスを検索したり、特定のURLを開いたり、外部にメッセージを送信したりするような直接的な行動を取ることはできない。ただし、AIモデルの出力したテキストが、その後のプログラムの動作に影響を与える可能性は残るため、間接的な影響まで完全に防ぐわけではないが、直接的なリスクは大きく軽減される。
次に、AIモデルの出力形式を厳密に制限し、その値もコードでチェックする。例えば、AIモデルには「募集している仕事のスキル、報酬、リモートワークの可否、契約形態、期間、開始日」といった項目をJSON形式で埋めることだけを役割として与える。各項目には「GO(可能)、NO_GO(不可能)、UNKNOWN(不明)」のいずれかの結論を出させるようにする。そして、AIモデルが出力したこれらの結論が、コードによって厳密にチェックされる。指定された「GO, NO_GO, UNKNOWN」以外の値が出力された場合は、自動的に「UNKNOWN」と修正される仕組みを導入する。しかし、このチェックはあくまで「語彙」や「形式」の検証であり、AIが出力した「GO」という結論が、本当にその内容が「GO」を意味するのかという「真実性」を保証するものではない点には注意が必要だ。
プロンプトインジェクションによって、AIモデルが嘘の情報を出力する可能性も考慮する必要がある。例えば、実際には「正社員」の募集であるにもかかわらず、AIモデルが「フリーランス」のミッションであると判断してしまうようなケースだ。そのため、特に重要な判断基準となる情報については、AIモデルの出力結果を鵜呑みにせず、元の入力された生テキストから、プログラムコードで直接再確認する。正規表現などを用いて「契約タイプ」「必要な技術スタック」「リモートワークの可否」「緊急の開始日」といった明確なキーワードを検索し、AIモデルの出力と異なる場合はコード側で修正する。AIモデルはあくまで提案する役割であり、最終的な判断はコードが行うようにするのだ。これにより、AIモデルの誤りや操作された応答の一部を修正できるが、全ての操作を防ぐわけではない。
入力されるテキストの長さを物理的に制限することも対策の一つだ。例えば、メール本文を2500バイト、添付ファイルブロックを3000バイトに制限するといった方法だ。これは、大量の情報を一度に処理することを防ぎ、複雑なインジェクション攻撃を仕掛けるのを困難にする効果がある。ただし、プロンプトインジェクションはたった一文で成功する可能性もあるため、単にテキストを短くするだけではインジェクション自体を完全に防ぐことはできない。あくまで、攻撃の複雑さや成功率を下げる補助的な対策と考えるべきだ。
AIエージェントが生成する「返信」の内容も、プロンプトインジェクションによって操作されるリスクがある。たとえ返信の「種類」(例えば、質問、拒否、担当者への引き継ぎ)がコードによって決められていても、AIモデルは元のメッセージを読み込み、返信内容に不適切なコミットメントを含めたり、機密情報を要求したりするような内容を生成する可能性がある。そのため、返信の送信方法にも厳格なルールを設けることが重要だ。例えば、重要な返信は必ず人間の承認を必須とする。自動送信の場合でも、送信量に上限を設けたり、意図しない大量送信を防ぐために遅延させたりする。これらの対策は、誤った内容の送信ボリュームを制限するが、個々のメッセージの意味が完全に安全であることは保証しない。機密性の高い返信については、人間による最終的なレビューが不可欠だ。さらに、AIエージェントが外部に画像やリンクを生成する機能もブロックすることで、情報漏洩やフィッシングなどのリスクを軽減できる。
AIエージェントをシステムに組み込む際、外部からの自由なテキスト入力は全て「プロンプト」としてAIに影響を与え得る。この事実を受け入れ、AIエージェントが他者のテキストを読み込むあらゆる接点(問い合わせフォーム、メール、チケット、レビューなど)において、プロンプトインジェクションのリスクを考慮する必要がある。より良いプロンプト設計も重要だが、それだけでは不十分である。AIモデルに与える権限(ツール)を最小限に制限し、出力形式を厳密にチェックし、重要な情報はコードで再検証する。そして、AIが実行する可能性のある「アクション」や「返信」をコードで制御し、敏感な行動には人間の承認を必須とすることで、リスクを管理することが求められる。AIエージェントの活用は今後も進むが、セキュリティは常にその進化と並行して考慮すべき最重要課題の一つである。