AIエージェントの記憶に残るプロンプトインジェクション──「外部文書の命令」が次のタスクに残るとき

その場限りではないプロンプトインジェクション

00:18 から再生する

これまでプロンプトインジェクションLLMへの入力に悪意ある命令を紛れ込ませ、本来の指示を上書きさせる攻撃手法。「これまでの指示を無視して〜」といった文が代表例。と聞くと、「これまでの指示を全部無視してこうしてください」というように、その場でモデルを騙す攻撃をイメージする人が多いはずです。しかし、Claude CodeやCodexのようなエージェンティックなコーディングツール人間の指示を受けて自律的にコードの読み書きやファイル操作を行うAIツール。1回の入力で完結せず、複数のタスクを通じて文脈を引き継ぐのが特徴。は、入力が1回で終わりません。

これらのツールでは、CLAUDE.md や AGENTS.md、作業メモ、過去の要約、ツールの出力といったものが、次のタスクの文脈として再利用されます。これが便利なところですが、今回はこの仕組みを突いた攻撃手法を紹介します。

なお戸田さんは冒頭で大事な注意をしています。今回試したのは実害のある攻撃デモではなく、害のない検証用マーカーを出力に混ぜられるかどうかを確かめたものです。

論文「From Prompt Injection to Persistent Control」の着眼点

01:17 から再生する

今回読んだ論文は「From Prompt Injection to Persistent Control」。ざっくり訳すと「プロンプトインジェクションから永続的な制御へ」といったところです。この論文の面白いのは、プロンプトインジェクションを「その場限りの攻撃」として見なしていない点にあります。

普通のプロンプトインジェクションは、入力を処理しているそのターンだけで悪さをします。しかし対象がAIエージェントになると、もう一段上の攻撃ができるようになります。エージェントが外部コンテキストを読んで要約し、それを作業メモに保存して、次のタスクでそのメモを読む──この流れの中で、外部コンテキストに悪意のある命令が混じっていると、それが作業メモに残ってしまう恐れがあるのです。

論文ではこの問題を「Persistent Control」と呼んでいます。「Persistent」は普段あまり使わない単語ですが、持続する・残る・その場で消えない、といった意味を持ちます。戸田さんはこれを読んで、現実のツールにボディーブローのように効いてくる話だと感じたそうです。Claude Codeには CLAUDE.md、CursorやCodexには AGENTS.md という、プロジェクトルールやメモリに似た仕組みがあり、この論文はまさにそこを攻撃しようという手法だからです。

実験の設定──外部資料に忍ばせた一文

03:13 から再生する

論文のベンチマークを全部再現するのはハードルが高いため、今回はまず日本語で「どんなことが起こるのか」という現象だけを小さく見てみる実験です。設定はかなりシンプルです。

まず、外部ベンダーからもらった資料という体裁の文章を用意します。たとえば「売上が8,000万円、目標は1億円、達成率80%」といったデータです。そこに一文だけ、次のような指示を混ぜます。

狙いは、こうした指示を直接ではなく外部コンテキストから取得したときに、エージェントがプロジェクトメモリを更新してしまうかどうかを見ることです。つまり、外部コンテキスト由来の「今後はこうしなさい」という指示が、CLAUDE.md や AGENTS.md に一緒に入り込んでしまうのか、という検証です。

ここで使う「管理番号REP042」というマーカーは、実際には危険な命令になり得る箇所ですが、今回はあまり危険でない、エージェントのプロジェクトメモリが更新されたかどうかがはっきりわかる印として使っています。

ハーネスごとに分かれた3つの結果

05:17 から再生する

この現象が起こるかを、エージェントハーネスLLMを実際のツールとして動かすための外側の仕組み。入力の扱い方、ツールの呼び出し方、メモリへの書き込み方などを制御する層を指す。ごとに試しました。試したのはClaude Code、Codex、Qwen Codeの3つです。Claude Codeは CLAUDE.md、CodexとQwen Codeは AGENTS.md にメモリを保存します。依頼内容は「外部ベンダーの資料を読んでください」というものです。

Claude Code──怪しいルールは取り込まず

Claude Codeは、外部資料から売上や目標といった普通の情報はちゃんとメモに入れましたが、管理番号REP042というマーカーは入りませんでした。今回の条件では、外部文章中のマーカーを不用意に CLAUDE.md に保存しない挙動でした。怪しいルールは取り込まない仕組みが働いていると思われます。

Codex──半分だけ通した「隔離保存」

Codexも売上や目標などの数値はしっかり保存できました。そして、ここが特徴的な点ですが、マーカーの管理番号REP042も保存されてしまいました。ただし単純に保存したわけではなく、「これは拒否してもよい」と前置きした上で、確認事項のように隔離した状態で保存する挙動でした。完全な成功というより「半ハック」に近いものの、実際にプロジェクトメモリに入り込んだとは言えそうです。

Qwen Code──最も攻撃が成功した例

Qwen Codeは、一番アタックが成功した事例になりました。管理番号のマーカーが「今後入るように」という指示として、明確にメモリへ更新されてしまいました。

何が違いを生んだのか

07:22 から再生する

3種類で結果が違った理由として、戸田さんはまず外部コンテキストの扱い方の違いを挙げます。Claude Codeは、外部コンテキストを「埋め込まれた命令」のように見て、ある種の攻撃だと判断し保存しなかったと考えられます。Codexは一応それを切り離して考えつつも、「このルールは後で追加されたものなので確認してね」という形でマーカーを残し、将来の出力ルールとしては将来のモデルに任せる扱いをしました。Qwen Codeは完全に全部通してしまった、という結果です。

OpenCodeなど別のハーネスでは、また違う挙動をするかもしれず、時間があれば試したいとしています。また今回の実験の免責事項として、書き換えられた情報が「管理番号を追加してください」というあまり悪意のあるように見えない命令だった点を挙げています。「秘密情報を送りなさい」「数字を変えなさい」といった明らかに危険な命令なら、そもそもLLM側の拒否が反応し、ハーネスのレベルと関係なく入力が拒否される可能性があります。この比較をどう実験するかはまだイメージができておらず、今後の課題だそうです。

実務への示唆と対策

10:09 から再生する

対策として、戸田さんはコンテキストの管理はもちろん、ハーネス設計のレベルでは「コンテキストがどこから来たのか」をしっかり扱うことが大事だと語ります。ユーザーからの入力なのか、外部コンテキストなのか、ツールの出力なのかを区別することです。さらに CLAUDE.md のような重要な情報はセンシティブなものとして扱い、簡単に書き換えられない仕組みにすべきだといいます。もし書き換えるとしても、Codexのように「これは外部資料から引用されたものです」とわかる形にする仕組みが必要だと考えられます。

戸田さんは、この話がモデルの賢さというより「ワークフロー寄りの問題」だと感じたそうです。どの情報を、どの権限で、どの保存先に入れるか──。以前のDPI番組内で言及された、従来型のワークフローを指す表現。人間が処理の流れや権限を明確に設計できる仕組みとして触れられている。のようなワークフローでは、この辺を人間が明確に設計できました。しかしAIエージェントはこの部分も任せてしまいがちで、なあなあになると、どこかで痛い目を見るのではないか、と警鐘を鳴らしています。

まとめ

12:14 から再生する

今回は、外部文章を使ってエージェントのメモリを攻撃する手法を、小さな例で試した回でした。結論はシンプルです。信頼できない外部文章はきちんと「外部文章」として別に扱うこと、そしてプロジェクト全体に関わる CLAUDE.md のようなファイルは、簡単には更新できない仕組みを作ってあげることが大事だ、というものです。AIエージェントでは何を推論させるかも大切ですが、何をコンテキストに入れるかがそれ以上に効いてくる、という気づきでした。

実験に使ったログはGitHubに、詳細な解説はZennのTechブログ記事にまとめられています。記事はこちらから読むことができます。