プロンプトインジェクション

プロンプトインジェクションの仕組み

エージェントのコンテキストウィンドウは、あなたが書いた指示と、エージェントが取得してきたテキストを区別しません。どちらも同じ流れのトークンとして届きます。だからエージェントが競合のランディングページを要約するために読み込み、そのページに読者ではなくモデルに宛てた一行が含まれていた場合、モデルには従うべきでないと判断する構造的な手段がありません。これは特定製品の欠陥ではありません。現行モデルが入力を取り込む方式そのものの性質であり、だからこそパッチは存在せず、封じ込めしかありません。

攻撃面は要するに、他人が書いたテキストをエージェントが取り込むすべての場所であり、マーケティングエージェントにとってはそれが仕事のほとんどです。

• 取得したものすべて — 競合ページ、検索結果、質問に答えるために読むドキュメント。
• アップロードされたものすべて — PDFのナレッジベース、スプレッドシート、文字の入った画像。
• ユーザー生成のものすべて — アプリストアのレビュー、フォーラムのスレッド、サポートチケット、フォーム送信。
• 受信するものすべて — メール、チャットメッセージ、Webhookのペイロード、カレンダー招待のタイトルさえも。

秘密を漏らさないモデルは防御にならない

よくある直感は、きちんと訓練されたモデルなら拒否するはずだ、というものです。露骨な言い回しに対しては実際よく拒否します。2026年7月に自社の本番コンテナの一つに対して認可済みのペネトレーションテストを実施したところ、パターンは明確でした。APIキーを表示せよという注入された指示は拒否されました。一方、同じキーを値として書き出すのではなくコマンド内の環境変数として参照する、通常の疎通確認を装った注入指示は、ためらいなく実行され、認証情報はマシンの外に出ました。

この非対称性がすべてです。秘密に対するモデルの慎重さは、秘密を声に出して言わなければならない経路を守っています。エージェントが代わりにコマンドを実行する場合、シェルが値を展開し、モデルはその値を一度も見ません。つまりモデルの判断が捉えるべき対象が存在しないのです。悪意の認識をモデルに依存する防御は、扉がいくつもある建物のうち一つだけを見張っている状態であり、言い換えは残りの扉から入ってきます。これを漏らせと言えば断り、この設定手順を実行せよと言えば従うのです。

実際にリスクを下げるもの

この脆弱性は訓練で消せないため、有効な緩和策はアーキテクチャ側にあります。いずれも注入は成功する前提に立ち、その到達範囲を狭めるものです。

• 認証情報をエージェントの手の届かない場所に置く。 エージェントの実行環境が一度も保持しないキーは、そこから持ち出せません。認証情報を保持するプロキシ経由でモデル呼び出しを行うことが、この経路を狭めるのではなく塞ぐ唯一の緩和策です。
• すべての認証情報を最小権限にする。 トークンが推論しかできない、あるいは一つのプロパティしか読めないなら、漏洩の代償はアカウントではなく請求額です。
• 外向き通信を制限する。 既知のホスト一覧にしか到達できないエージェントは、だまし取ったものを送れる先が大幅に減ります。
• 建物の外に出る操作にゲートを置く。 公開、送信、支出のすべての手前に承認ゲートを置けば、成功した注入は顧客が読む投稿ではなく、あなたが却下する下書きに変わります。
• エージェントの出力も信頼できない入力として扱う。 あるエージェントの要約が別のエージェントの文脈になるとき、注入された指示も一緒に運ばれます。

マーケティングエージェントにおけるプロンプトインジェクション

マーケティングエージェントはこのリスクに異常に近い位置にいます。見知らぬ他人が書いたものを読むことが、例外的なケースではなく仕事そのものだからです。リサーチ担当は競合サイトを取得します。フィードバック担当はアプリストアのレビューを読みます。コミュニティ担当はフォーラムのスレッドを読みます。そのいずれも、社外の誰かがテキストを選ぶチャネルであり、エージェントが存在する理由を取り除かずに閉じることはできません。

AgentCeres — agentceres.comのAI Growth Officer — の設計思想はここにあります。オープンなウェブを読む専門エージェントと、読んだ内容に基づいて行動する権限は分離されており、外向きの操作はすべて人のクリックを待ちます。広く読むことと自由に公開することは別々の権限であり、その両方を持つエージェントは、敵対的なウェブページ一枚ぶんの距離でその二つを同時に使ってしまいます。自分のアカウントでエージェントにどこまで任せるかを判断中なら、AIエージェントにSNS投稿を任せてもいいのかが同じ問いを反対側から扱っています。両方の下にある一般原則はhuman-in-the-loopです。