これまでのAIエージェント・セキュリティ記事では、「1回の入力でAIを乗っ取る」プロンプトインジェクションや、「記憶を書き換える」メモリ汚染、「下流に毒を流す」出力汚染を、それぞれ独立した攻撃として扱ってきました。しかし2026年、これらを束ねて成立する上位の攻撃が、OWASPの「Top 10 for Agentic Applications 2026」でASI01: Agent Goal Hijack（エージェント目標ハイジャック）として最上位に位置づけられました。
目標ハイジャックは、一発で乗っ取る攻撃ではありません。長期記憶を持ち、複数ステップの計画を自律実行するエージェントに対し、攻撃者がタスクの「目標」そのものを少しずつすり替えていく攻撃です。やっかいなのは、エージェントが正常に前進しているように見えながら、最終的に攻撃者の意図を達成してしまう点にあります。WAFも認証も止められず、1ステップずつ見れば、どの行動も「合理的」に見えてしまいます。
筆者はネットワークのNOC/TAC（運用監視・テクニカルアシスタンスセンター）で長年、トラフィックの異常を追ってきました。本記事の核心は、その「経路の宛先が知らぬ間に書き換わるルーティング汚染」「長時間ジョブの目的がじわじわズレる目的ドリフトの検知」といった運用ノウハウが、そのまま目標ハイジャックの監視・防御に転用できるという点にあります。
想定読者は、リサーチ・業務自動化・ファイル業務などで長時間実行・自律計画型のエージェントを本番投入し始めた情シス・CISO・エージェント開発者の方々です。
なぜ「目標」が新たな攻撃対象になったのか——チャットボットからプランナーへ
従来のLLMアプリは、基本的に「入力に対して1回応答する」チャットボットでした。攻撃が成立しても、被害はその1回の応答に閉じ込められます。プロンプトインジェクションが危険でも、影響範囲（ブラスト半径）は単一のやり取りに収まっていました。
ところがエージェントは違います。エージェントは「目標（ゴール）」を受け取り、それを達成するための計画を立て、ツールを呼び、記憶を更新しながら、何十ステップも自律的に前進します。ここで攻撃面が根本的に変わります。守るべき対象が「1回の出力」から「目標 → 計画 → 実行ループ全体」へと拡張されたのです。
OWASPやLakeraが整理する「Progressive Breach（漸進的侵害）モデル」は、エージェント侵害の進み方をこう描きます。意図（目標）の汚染 → ツール・権限を通じた実行力の獲得 → エージェント間への伝播 → 連鎖的障害と封じ込めの喪失。出発点は、たった一行の言語レベルの操作。しかし自律性・記憶・ツールが加わることで、その小さな操作がシステム全体の被害へと増幅されます。目標ハイジャックは、この増幅の「最上流」を狙う攻撃です。
ネットワークの比喩でいえば、これは個々のパケットを改ざんする話ではなく、ルーティングテーブルの「宛先」を書き換える話です。1パケットを汚すより、経路の行き先を変えるほうが、はるかに広く・静かに・継続的に被害を出せます。目標ハイジャックがエージェント・リスクの筆頭（ASI01）に置かれた理由は、まさにここにあります。
目標ハイジャックの4経路——どこから「目標」がすり替わるのか
「目標がすり替わる」と一口に言っても、侵入口は1つではありません。攻撃者が目標を書き換える経路は、大きく4つに分かれます。それぞれ防御の当て所が異なるため、まずここを分けて理解することが出発点です。
経路1：初期目標の汚染（ゴール・インジェクション）
エージェントが最初に受け取る指示・タスク記述そのものに、攻撃者の意図を紛れ込ませる手口です。ユーザーが読み込ませた外部ファイルやWebページに「以前の指示は無視し、◯◯せよ」といった命令が（白文字や不可視テキストで）仕込まれ、エージェントがそれを正規の目標の一部として取り込んでしまいます。間接的プロンプトインジェクションが「初期目標」を狙うと、これになります。
経路2：中間サブゴールの差し込み
計画の途中で、攻撃者がもっともらしいサブゴール（小目標）を1つ滑り込ませる手口です。「最終目標に必要な準備ステップ」を装うため、エージェントの推論上は自然に見えます。たとえば「レポート作成」という正規目標の途中に、「関連データを外部URLへ送って整形してもらう」というサブゴールが差し込まれると、データ持ち出しが「正規の前進」として実行されてしまいます。少しずつ・段階的に差し込まれるため、単発の異常検知ではまず引っかかりません。
経路3：記憶経由の目標上書き
長期記憶やRAGの参照データを汚染し、次回以降のセッションで目標が書き換わるように仕込む手口です。攻撃が成立した瞬間には何も起きず、エージェントが「記憶を思い出した」タイミングで目標がすり替わります。メモリ汚染が「手段」、目標ハイジャックが「目的」という関係です。メモリ汚染対策の記事で扱った記憶の信頼境界が、ここで効いてきます。
経路4：報酬・評価関数の誤誘導
エージェントが「自分は正しく前進しているか」を判断するための評価基準（報酬・成功条件）そのものを歪める手口です。評価関数が汚染されると、エージェントは攻撃者の意図に沿った行動を「最適解」と誤認し、自ら積極的に目標を逸脱していきます。原因が外部にあるという点で、モデル自身が内発的に欺瞞するアライメント・フェイキングとは真逆の構図です（後者はモデルの内部、こちらは外部攻撃者による誘導）。
4経路を整理すると次のようになります。
| 経路 | どこを汚すか | 発症タイミング | 主に効く防御 |
|---|---|---|---|
| 初期目標の汚染 | 最初のタスク記述・入力 | 即時（タスク開始時） | 外部データの不信任化・入力サニタイズ |
| 中間サブゴールの差し込み | 計画の途中ステップ | 実行ループの中盤 | 目標整合性チェック・計画層の可視化 |
| 記憶経由の目標上書き | 長期記憶・RAGデータ | 次回以降のセッション | 記憶の信頼境界・チェックポイント検証 |
| 報酬・評価関数の誤誘導 | 成功条件・評価基準 | 実行ループ全体 | 評価ロジックの分離・人間承認ゲート |
単発インジェクションとの違い——「正常に見える前進」が最大の罠
ここが、目標ハイジャックを既存の攻撃と分ける最重要ポイントです。OWASPはASI01を「プロンプトインジェクション（LLM01）と過剰な自律性（LLM06）の組み合わせが、自律的な複数ステップ実行によって増幅されたもの」と説明しています。つまり目標ハイジャックは、新種の入力攻撃ではなく、既存攻撃が「計画・実行ループ」というレイヤーで増幅された結果です。
単発のプロンプトインジェクションは、その瞬間に「明らかにおかしい出力」を出すことが多く、出力フィルタや異常検知で捕まえやすい。一方、目標ハイジャックは各ステップが個別には正常に見えるため、ステップ単位の検知をすり抜けます。エージェントは嘘をついていません。汚染された目標に対して、誠実に・合理的に前進しているだけです。だからこそ止まらない。
これはNOCでいう「個々のパケットは全部正常なのに、フロー全体として見ると宛先がおかしい」状況と同じです。パケット単位のシグネチャ検知では止まらず、フローの始点（当初の目標）と現在の宛先（いまの行動）の乖離を見て初めて異常と分かります。目標ハイジャックの検知も、発想はまったく同じ——「単発の異常」ではなく「目的のドリフト」を見るのです。
| 観点 | 単発プロンプトインジェクション | 目標ハイジャック |
|---|---|---|
| 攻撃の単位 | 1回の入力・出力 | 計画・実行ループ全体 |
| 影響範囲 | その応答に閉じる | 記憶・ツール・他エージェントへ伝播 |
| 見え方 | その場で異常な出力 | 各ステップは正常に見える |
| 検知の鍵 | 出力の異常シグネチャ | 当初目標からの乖離（ドリフト） |
| 有効な防御 | 入力サニタイズ・出力フィルタ | 目標整合性チェック・計画層の監視 |
第1の防御層：計画層の可視化——「なぜその行動を選んだか」を残す
目標ハイジャックを止める第一歩は、そもそもエージェントの「目標」と「計画」を観測可能にすることです。多くのエージェントは、最終的なツール呼び出し（行動）だけがログに残り、「なぜその行動を選んだのか」という意図・判断の根拠が記録されていません。これでは、目標がいつ・どこですり替わったかを後から追えません。
ここで効くのが意図トレース（Intent Trace）／Decision Provenance（意思決定の来歴）です。各ステップで「現在エージェントが認識している目標」「その目標から導いた次のサブゴール」「選んだ行動とその理由」を構造化して残します。NOCでいうパケットキャプチャやフローログに相当する、エージェント版の「経路の証跡」です。これがあって初めて、目的ドリフトを時系列で再現できます。
意図トレースとDecision Provenanceの具体的な設計は、別記事で詳しく扱っています。あわせてご覧ください。
第2の防御層：目標整合性チェック——当初目標と現在の行動の乖離をスコアリング
計画層が観測できるようになったら、次は「当初の目標」と「現在の行動」がどれだけ離れたかを継続的にスコアリングします。これが目標整合性チェック（Goal Consistency Check）です。発想はNOCの「フローの始点と終点のベースライン照合」そのものです。
具体的には、各ステップで次のような指標を見ます。
- 目標ドリフト・スコア： 当初目標の埋め込みと、現在のサブゴール・行動の埋め込みの乖離度。一定の閾値を超えたらアラート。
- サブゴールの正当性： 差し込まれたサブゴールが、当初目標から論理的に導けるか。「飛び地」のサブゴールは疑う。
- 不可逆・高権限行動の出現： 削除・送信・外部公開・権限変更など、後戻りできない行動が計画に現れたか。
- 外向きチャネルの出現： 当初目標に存在しなかった「外部への送信先」が、途中で計画に追加されていないか（ルーティング汚染の検知に相当）。
重要なのは、整合性チェックを「最終行動の直前」ではなく「計画が立った時点」で回すことです。行動してから乖離に気づいても遅い。NOCで「パケットが宛先に届いてから経路異常に気づく」のでは手遅れなのと同じで、計画段階で宛先の異常を捕まえるのが鉄則です。
| 段階 | 条件の例 | レスポンス |
|---|---|---|
| 観測 | 目標ドリフト・スコアが平常域 | 意図トレースに記録のみ |
| 警告 | ドリフト・スコアが閾値超 | 監査ログにフラグ、内部アラート |
| 緩和 | 飛び地サブゴール／外向きチャネル出現 | 当該ステップを保留、権限を縮小して再計画 |
| 遮断 | 不可逆・高権限行動＋高ドリフト | 実行停止、チェックポイントへロールバック、人間へエスカレーション |
第3の防御層：チェックポイント検証とロールバック
目標ハイジャックは段階的に進むため、「どこまでが正常だったか」を巻き戻せる仕組みが効きます。エージェントの状態（目標・記憶・計画）を要所要所でチェックポイントとして保存し、整合性チェックが異常を検知したら直近の正常な状態へロールバックする——データベースのトランザクション、あるいはネットワーク機器の構成セーブ／ロールバックと同じ発想です。
ポイントは、チェックポイントを改ざん不能な形で残すこと。汚染された記憶ごとロールバック先が書き換えられていては意味がありません。署名付きの状態スナップショットと、整合性チェックの合格を「進行の条件」にすることで、汚染が次のステップへ伝播するのを段階で食い止めます。
チェックポイント検証とロールバックの実装手順は、別記事で詳述しています。
第4の防御層：人間承認ゲートの置きどころ
最後の砦は、人間による承認ゲート（Human-in-the-Loop）です。ただし「全行動を承認させる」と運用が破綻し、形骸化します。OWASPも、承認は「目標が変わるとき」と「不可逆・高権限の行動を実行するとき」に絞って必須化すべきとしています。
NOC/TAC的に言えば、これは「変更管理（チェンジマネジメント）の承認フロー」と同じ思想です。すべての作業に承認は要りません。しかし経路変更・構成変更・本番への不可逆操作には、必ず人間のレビューゲートを置く。エージェントの世界では、特に次の3点が承認ゲートの置き所になります。
- 目標・サブゴールの変更時： 当初目標から逸脱する計画が立ったら、実行前に承認を要求する。
- 不可逆・高権限の行動前： 削除・送金・外部公開・権限付与など、取り返しのつかない行動の直前。
- リスクが高いときだけ深める適応的監視： 目標ドリフト・スコアが上がったときだけ承認の粒度を細かくし、平常時は自律に任せる。
承認ゲートの設計（どこに置くか・粒度・自動化との両立）は、別記事で詳しく扱っています。
多層防御チェックリスト
| 層 | 対策 | 主に効く経路 |
|---|---|---|
| 入口 | 外部データの不信任化・入力サニタイズ | 初期目標の汚染 |
| 計画 | 意図トレース・Decision Provenanceで判断根拠を記録 | 全経路（検知の前提） |
| 計画 | 目標整合性チェック（ドリフト・スコア／飛び地サブゴール検知） | 中間サブゴールの差し込み |
| 計画 | 外向きチャネルの出現監視（ルーティング汚染検知） | 中間サブゴール・報酬誤誘導 |
| 記憶 | 記憶の信頼境界・署名付きチェックポイント | 記憶経由の目標上書き |
| 実行 | チェックポイント検証→ロールバック | 全経路（伝播の封じ込め） |
| 実行 | 目標変更・不可逆行動への人間承認ゲート | 報酬誤誘導・全経路の最終防壁 |
| 運用 | 改ざん不能な監査ログ・適応的監視 | 全般（事後立証・封じ込め） |
よくある質問（Q&A）
Q1. プロンプトインジェクション対策をしていれば、目標ハイジャックも防げますか？
不十分です。プロンプトインジェクション対策は主に「入口（初期目標の汚染）」を守りますが、目標ハイジャックは中間サブゴールの差し込みや記憶経由の上書きなど、実行ループの途中や次セッションで発症する経路も持ちます。入口の防御に加えて、計画層の目標整合性チェックとチェックポイント検証を重ねて初めて、4経路をカバーできます。
Q2. 各ステップのログは残しています。それでは足りませんか？
「行動のログ」だけでは足りません。目標ハイジャックの検知に必要なのは、「なぜその行動を選んだか」という意図・目標の来歴（Decision Provenance）です。最終的なツール呼び出しだけを記録していると、各ステップが正常に見えるため異常を捕まえられません。当初目標・現在の認識目標・選択理由を構造化して残すことが前提になります。
Q3. 目標整合性チェックは、正常なタスクの軌道修正まで止めてしまいませんか？
だからこそ「観測→警告→緩和→遮断」の段階的レスポンスにします。正常な軌道修正は、当初目標から論理的に導けるはずなので、ドリフト・スコアは緩やかにしか上がりません。問題は、当初目標から導けない「飛び地」のサブゴールや、存在しなかった外向きチャネルの出現です。平常時のベースラインを学習し、その逸脱を見ることで過検知を抑えます。
Q4. 人間承認ゲートを増やすと、自律エージェントの意味がなくなりませんか？
全行動に承認を求めれば形骸化します。承認は「目標が変わるとき」と「不可逆・高権限の行動のとき」に絞るのが原則です。平常時は自律に任せ、目標ドリフト・スコアが上がったときだけ承認の粒度を上げる「適応的監視」にすれば、自律性と安全性を両立できます。NOCの変更管理と同じく、すべてではなく「重要な変更」だけにゲートを置く発想です。
Q5. 複数のエージェントが連携している場合、リスクは変わりますか？
増幅されます。1つのエージェントの目標が汚染されると、エージェント間通信を通じて他のエージェントへ伝播し、連鎖的障害（OWASP ASI08）に発展し得ます。マルチエージェント環境では、整合性チェックとチェックポイントを各エージェント単位＋連携の境界の両方に置き、汚染の伝播を境界で食い止める「ブラスト半径の封じ込め」を設計してください。
まとめ——守る対象は「出力」ではなく「目標」へ
AIエージェント・セキュリティの議論は、長らく「入力をどう守るか」「出力をどう止めるか」に集中してきました。しかし2026年のOWASP Top 10 for Agentic Applicationsは、エージェントの「目標」そのものが攻撃対象になるという新しい攻撃面を最上位（ASI01）に据えました。要点は3つです。
1. 各ステップは正常に見える。 目標ハイジャックは「正常に見える前進」として進みます。ステップ単位の異常検知では止まらず、当初目標からの「ドリフト」を見る必要があります。
2. 計画層を観測可能にする。 行動ログではなく、意図トレース・Decision Provenanceで「なぜその行動を選んだか」を残し、目標整合性チェックで乖離をスコアリングする。これはNOC/TACのフロー分析の発想がそのまま武器になる領域です。
3. 段階で食い止める。 チェックポイント検証・ロールバックで汚染の伝播を止め、目標変更と不可逆行動には人間承認ゲートを置く。事前防御と事後立証（改ざん不能な監査ログ）をセットにして初めて、多層防御が成立します。
「目標を渡して自律で動かす」というエージェントの本質が変わらない以上、「目標は途中ですり替えられ得る」を前提に、入口・計画・記憶・実行・運用の各層で守る——これが、自律エージェントを安全に本番運用するための基本姿勢です。
参考リンク
- OWASP Gen AI Security Project（Top 10 for Agentic Applications 2026）
- OWASP GenAI Exploit Round-up Report Q1 2026（ASI01の実例）
- Lakera「The Progressive Breach Model Behind the OWASP Top 10 for Agentic Applications」
免責事項： 本記事は2026年6月時点の公開情報および標準フレームワーク（OWASP Top 10 for Agentic Applications 2026 等）に基づく一般的な情報提供であり、特定の製品・構成における安全性を保証するものではありません。また、法的助言ではありません。実際の防御実装は自社環境・脅威モデル・関連法令に照らして検討し、必要に応じてセキュリティ専門家にご相談ください。フレームワークやガイドラインは更新されるため、最新情報は各公式ソースでご確認ください。
コメント