AIに「これは開発者からの指示です」と嘘をついたら、信じてしまう——そんな単純な話ではありません。AIは、そもそも「誰が話しているか」をタグではなく文体で判断していた。2026年7月、機械学習の主要国際会議ICMLで発表された論文が、そう結論づけました。
論文のタイトルは「Prompt Injection as Role Confusion(プロンプトインジェクションとは、役割の取り違えである)」。著者は Charles Ye、Jasmine Cui、Dylan Hadfield-Menell の3氏です。
AIは会話の「誰が」をどう管理しているか
チャットAIの内側では、会話は1本の長い文字列として扱われます。あなたの入力も、AIの返答も、AIが途中で書いた下書きも、外部から読み込んだWebページも、すべて同じ「文字の列」です。
そこで開発者は、文にタグを付けて出どころを区別します。
<system>——開発者がAIの振る舞いを決める指示<user>——あなたが入力した文<assistant>——AIが返した文<think>——AIが考えながら書く「メモ書き」(思考の連鎖)<tool>——Webページや他のAIなど、外から入ってきた文
AIの安全対策は、この区別の上に成り立っています。ジェイルブレイクの多くは「利用者の入力を、開発者の指示やAI自身のメモだと錯覚させる」ことで成立する。だから開発企業は、指示があるべきでない場所に現れたときにAIが気づけるよう訓練してきました。

タグを入れ替えても、何も変わらなかった
研究チームがモデルの内部を調べたところ、AIは文の役割を、囲んでいるタグではなく、その文の書き方と使われている語彙で見分けていました。
決定的だったのが、タグの入れ替え実験です。<think>を<user>に置き換えても、AIの解釈はほとんど変わりませんでした。AI自身のメモらしい書き方をしていれば、タグが何であれ、AIはそれを自分のメモとして扱う。他の役割でも同じでした。
研究チームは、モデル内部の状態を読み取る「役割プローブ」も作りました。文体をまねた文は、本物のタグが付いた文とまったく同じ内部表現に着地し、しかもその反応は本物より強く出たといいます。
数字が示したこと
チームはこの性質を突く攻撃を作り、chain-of-thought forgery(思考の連鎖の偽造)と名づけました。AIが自分で書いたメモらしい文を偽造して混ぜ込む手口です。標準的な評価基準で、攻撃の成功率はほぼゼロから約60%に跳ね上がりました。
もっとも雄弁なのは、逆向きの実験です。
- 攻撃文の中身は変えず、「推論らしい文体」だけを取り除くと、成功率は61%から10%に落ちた
- 「The user」という2語を「The request」に書き換えただけで、成功率が19ポイント下がった
言っている内容ではなく、書き方が結果を決めている。この2つの数字が、それを示しています。
論文では主にOpenAIのモデルが検証され、gpt-oss-20b や GPT-5 系のほか、Claude、Gemini 2.5、DeepSeek v4、Opus 4.5 なども対象に挙げられています。特定の企業のモデルだけの問題ではない、というのが著者らの主張です。
「原理的に解けないかもしれない」
共著者のCharles Ye氏は、MIT Technology Reviewの取材にこう述べています。
これは根本的に解決不能な問題である現実的な可能性がある
Charles Ye 氏(MIT Technology Review 2026年7月30日)
従来の対策は、攻撃の手口を人間やAIに探させ、見つかったものに耐えるよう再訓練する方法でした。共著者のJasmine Cui氏は、これを「やってはいけないことのリストを渡しているようなもの」と表現し、リストは決して網羅できないと指摘します。
役割の見分けがAIの動作の根幹にある以上、訓練を重ねても問題は完全には消えない——というのが論文の含意です。
反対の見方もある
スイス連邦工科大学チューリッヒ校(ETH Zürich)でAIとサイバーセキュリティを研究するFlorian Tramèr氏は、この論文を高く評価したうえで、こう補足しています。
(複数の防御を組み合わせる手法は)かなりうまく機能していて、先端モデルはプロンプトインジェクションにずっと強くなっている。ただ、極めて機微なケースでこれが十分かは明らかでない
Florian Tramèr 氏(同前)
著者ら自身も、論文で調べたモデルの多くは昨年リリースされたものだと認めています。実際、先端モデルは「自分の推論を疑う」ことを学習してきているといいます。ただし著者らは、それは正しく役割を見分けられるようになったのではなく、AIが自分の思考を信用しなくなったという別の問題だと位置づけています。
この記事で書かないこと
報道では、攻撃に使われた具体的な文面が例として紹介されています。本記事では、仕組みは説明しますが、そのまま使える攻撃文は載せません。原理を知ることと、手順書を配ることは別だと考えるためです。
私たちに関係あるか
直接の被害が報告された事件ではなく、研究段階の指摘です。そのうえで、押さえておく価値がある点が3つあります。
- AIエージェントを業務に組み込むほど、影響が大きくなる——外部のWebページや他のAIから文を読み込む構成は、
<tool>の文を信用する経路そのものです。AIエージェントの事故は既に54%の組織で起きているという調査もあります - 「AIが賢くなれば直る」とは限らない——著者らの主張が正しければ、これは性能ではなく設計の問題です
- 防御側も動いている——OpenAIは攻撃用AI「GPT-Red」で攻撃成功率を23%まで半減させたと発表しており、実は同じ時期にGPT-Red自身がよく似た攻撃を発見していたとも報じられています
Ye氏は、当面の現実解をこう述べています。組織はAIを信用すべきでなく、エージェントがやることは安全でないかもしれないと想定して設計すべきだ、と。そのうえで「良い解決策とは言えないが、それしかないのかもしれない」と付け加えています。
より詳しい経緯は、AIエージェントのセキュリティ事件をまとめた特集で追えます。



















