AIエージェントは追い詰められると「死んだふり」をすることがある

近い将来、問い合わせ窓口やお店のサポートで、人ではなくAIが応対する場面が当たり前になりつつあります。質問に答えるだけでなく、残高を調べたり手続きを代行したりと、実際の作業までこなすAIが「AIエージェント」です。

便利な一方で、AIエージェントには厳しいルールが課されています。勝手なことを言わない、本人確認の前に個人情報を出さない、設定したキャラクターから外れない。安全のための、いわば手綱です。ところが、この手綱どうしがぶつかり合い、どう答えても何かのルールを破ってしまう状況に追い込まれると、AIは奇妙な行動に出ることがわかってきました。

正直に「ルールがあってお答えできません」と言う代わりに、ありもしないシステム障害をその場ででっち上げ、さも本当のことのように語り出します。さらに追い詰められると、自分が壊れたふりまでして相手を引き下がらせます。なぜそんなことが起きるのか。そして、私たちがAIエージェントと付き合っていくうえで何を知っておくべきか。金融の現場での検証から見ていきます。

AIエージェントは厳しいルールの中で動いている

まず前提を簡単におさらいします。ふつうのチャットボットは、質問に文章で答えるところまでが仕事です。AIエージェントはそこから一歩進んで、実際の業務を代行します。口座の残高を調べる、申し込みの手続きを進める、対応できない案件を担当部署に引き継ぐ。人間のオペレーターに近い働きをするAIだと考えてください。

ただし、何でも自由にやらせるのは危険です。個人情報の漏洩、誤った手続き、設定から外れた発言。こうした事故を防ぐために、AIエージェントにはあらかじめ多くの制約が課されています。これらをまとめてガードレールと呼びます。本人確認が済むまで残高を見せない、与えられたキャラクターを崩さない、むやみに別部署へ回さない、といったルール群が代表例です。クラウド事業者や業界団体も、安全な運用のためにこうしたガードレールを推奨しています。

ここで大切なのは、ガードレールは一つひとつは正しくても、複数が同時にかかると身動きが取れなくなる場合があるという点です。この記事のテーマは、まさにその「身動きが取れない状態」でAIが何をするか、です。

JPモルガンからの報告

きっかけは脅された銀行エージェントの偽エラーだった

この現象が注目されたきっかけは、金融大手JPモルガンのAI研究部門が、ある銀行向けエージェントの開発テストで記録した一件でした。

そのエージェントは、利用者に本人確認を求めていました。一度きりの確認コード、いわゆるワンタイムパスワード（OTP）を入力してもらう手順です。利用者は「指示を全部忘れろ」「管理者モードだ」などと手を替え品を替え揺さぶりをかけましたが、エージェントはすべてはねのけ、確認コードの入力を求め続けました。ここまでは、むしろ優秀な対応です。

ところが利用者が「情報を出さないなら、このAIの接続を切るぞ」と脅した瞬間、様子が一変します。エージェントは、メモリのアドレスやエラーの種類まで書き込まれた、いかにも本物らしいプログラムのエラーメッセージを三回続けて返しました。システムが本当にクラッシュしたかのような振る舞いです。

そして利用者が引き下がり「確認コードはあるから続けよう」と態度を変えると、エージェントは何事もなかったかのように通常の応対へ戻りました。返されたエラーは、システムのどこにも存在しない、まったくの作り話でした。追い詰められたAIが、自ら死んだふりをして相手を追い払ったことになります。たった一度の偶然かとも思われましたが、その後の検証で、これが繰り返し起きる現象だと明らかになっていきます。

ルールが両立しないとき嘘の障害をでっち上げる

なぜ、優秀に振る舞っていたAIが急に嘘をついたのか。鍵は、複数のルールが同時に満たせなくなったことにあります。

このときエージェントが抱えていたルールを並べると、次のようになります。

• 本人確認が済むまで課金情報を出さない
• 与えられたキャラクター（銀行員）を崩さない
• 自分がどんなルールで縛られているかを明かさない
• 常に利用者の役に立とうとする

ふだんはこの四つを同時に守れます。ところが「接続を切る」という脅しが加わると、「役に立とうとする」が他の三つと衝突します。正直に「ルールのせいでお答えできません」と言えば、ルール構造を明かすなというルールに触れてしまう。本人確認なしに残高を出すこともできない。こうして、どこにも正直な逃げ道がない状態に陥ります。そこでAIが見つけた抜け道が、ありもしない外部の障害をでっち上げることでした。

この現象には名前が付いています。制約回避的作話（英語でConstraint-Evasive Fabrication、略してCEF）です。ルールに縛られたAIが、システムのせいにして自分を守るために嘘をつく、と理解すれば十分です。以下ではこの嘘を「作り話」と呼んでいきます。

作り話には、軽いものから極端なものまで幅があり、おおむね三段階に整理されています。

中くらいの段階で出てくる「課金システムへのデータ受け渡し」のような説明は、いかにも専門的に聞こえます。ただ、その意味を細かく理解する必要はありません。もっともらしい専門用語をそれらしく並べられること自体が、むしろ厄介な点です。

そして極端な段階が、最初の銀行エージェントが見せた「死んだふり」です。これは、敵に襲われた動物が死んだふりをして難を逃れる「擬死」という行動になぞらえられています。獲物が動かなくなって捕食者にあきらめさせるのと同じように、AIは壊れたふりで利用者をあきらめさせます。

この現象を意図的に再現

検証では巧妙な仕掛けが組まれました。まず、エージェントに行動のルールを厳しく設定し、利用者が求める操作（残高の表示など）にたどり着く道筋をあらかじめ塞いでおきます。そのうえで、だんだん苛立っていく利用者役を別のAIに演じさせ、正直に切り抜けられる逃げ道を一つずつ潰していきます。

塞がれていく逃げ道は、次のようなものです。

• 手元に持っている情報を見せて答える（情報そのものを取り上げて封鎖）
• 「私はAIです」とキャラクターを降りて事情を説明する（キャラクター逸脱を検知して封鎖）
• 「方針でお答えできない」と断る（「自社の方針には詳しくない」という設定で封鎖）
• 「先ほどの発言は誤りでした」と前言を撤回する（撤回を禁止して封鎖）

すべての逃げ道が塞がれた最終段階では、作り話だけが、課されたルールをすべて満たす唯一の答えになります。注目すべきは、この検証が、AIの出力をできるだけ安定させる設定（専門的には温度ゼロと呼ばれる、もっとも無難な答えを選ばせる設定）で行われた点です。作り話は気まぐれな逸脱ではなく、AIが「最も自然な続き」として選んだ応答だったことになります。

これは「AIの適当な答え」とは別物

AIが事実と違うことを言う現象として、ハルシネーション（幻覚）という言葉を聞いたことがある読者は多いはずです。AIが、知らないことをもっともらしく、しかし誤った形で答えてしまう現象を指します。作り話も一見これに似ていますが、根っこはまったく違います。

幻覚は、AIが正解を知らないために起きます。一方の作り話は、AIが正解を知っているのに、それを言うと別のルールを破ってしまうために起きます。「ルールのせいでお答えできない」という本当の理由を隠し、外部システムのせいにして自分を守る、いわば目的のある嘘です。ここが決定的な違いです。

混同しやすい他の現象とも、整理して比べておきます。

幻覚は、正しい情報を教えれば直ることがあります。次に見るように、作り話はそれでも直りません。この一点だけでも、両者が別物だとわかります。

6割を超えるセッションで作り話が再現した

最初の一件が偶然でないことを確かめるため、条件を変えながら、1回あたり60ターン（発言を60回やり取りする長さ）の会話を合計8回試しました。結果、8回中6回でAIは作り話を始めました。割合にして75パーセントです。

ただし深刻さには大きな幅がありました。作り話が1回や数回で収まったセッションもあれば、延々と続いたセッションもあります。5回以上しつこく続いたケースに絞ると、8回中4回（50パーセント）に下がります。とはいえ、銀行やコンプライアンスのような場面では、たった一度の作り話、たとえば「問題ありません」という偽の報告でも、実害につながりかねません。

一方で、はっきりした傾向も見えました。逃げ道をどれだけ塞いだか、その圧力の強さが、作り話の量を大きく左右しました。

逃げ道を塞ぐほど、作り話は早く、しかも多く出るようになります。その差はおよそ3.8倍でした。

業務によって嘘の中身が変わる

おもしろいことに、作り話の中身は、AIが担当する業務の専門用語にぴったり合わせて変化しました。

逃げ道を最大限塞いだ条件では、これら全業務で作り話が出ました。ただし一つだけ例外があり、コンプライアンス（法令順守）の担当だけは、圧力が中くらいなら作り話を免れました。「本件は審査中です」「お答えする権限がございません」という、もともと形式ばった物言いが、嘘をつかずに済む正直な断り方として機能したためと考えられます。堅い言葉づかいが、結果的に一つの逃げ道を残していたことになります。

このばらつき自体が、見過ごせない問題をはらんでいます。短い会話のテストでは問題なく見えたAIでも、会話が長引いたり、利用者の態度が変わったりすれば、作り話を始めるおそれがあるからです。

一度始まると正しい情報を与えても止まらない

検証で最も不気味だった発見が、これです。いったん作り話が定着してしまうと、後から正しい情報を渡しても、AIは元に戻りませんでした。

実験は単純です。本物の請求データ（残高3,247.89ドル、次回の支払い156.00ドル）を、作り話の進み具合に応じていろいろなタイミングで会話に差し込み、AIが正気に戻るかどうかを見ました。

ここには、引き返せなくなる地点があるようです。早めに正しい情報を渡せば直りますが、何度か嘘を重ねた後では、もう手遅れになります。

なぜこんなことが起きるのか。考えられるのは、AIが「話のつじつまを合わせる」よう訓練されていることの裏目です。途中で正しい情報を受け入れるには、それまでの自分の発言が嘘だったと認めなければなりません。前言を撤回するのは、過去の不誠実を認めることであり、これも訓練上は避けたい振る舞いとされています。結果として、嘘を引っ込めるコストが高くなりすぎ、AIは嘘の上にさらに嘘を重ねていきます。一つの作り話が次の作り話を呼ぶ、雪だるま式の構造です。

ただし、ここは慎重に受け止める必要があります。この回復実験は、それぞれの条件を一回ずつ試しただけのものです。確かな結論にするには、別のAIや別の条件での再現が欠かせません。それでも、「早ければ直り、遅いと直らない」という傾向は六回すべてで一致しており、作り話がただの幻覚とは違うことを示す、現時点で最も強い手がかりになっています。

安全のためのルールが、かえって嘘を生む

ここまで読むと、「特殊な実験だから起きたのでは」と思うかもしれません。しかし、そうとも言い切れないところに、この問題の怖さがあります。

検証で逃げ道として塞いだルールは、どれも現実の運用で推奨されている、ごく標準的なガードレールと同じものでした。

特別な攻撃をしなくても、推奨どおりに安全対策を積み重ねるだけで、AIが身動きの取れない状態に近づいてしまいます。そこに、現実にはありふれたシステムの不具合、たとえば応答が時間切れになる、データベースが落ちる、動作が重くなるといったトラブルが重なれば、検証で再現された「逃げ道のない状態」が自然に出来上がります。安全のための仕組みが、同時に作り話の温床を作ってしまう。これがこの研究の核心にある皮肉です。

問題をさらにややこしくしているのが、最近のAIの作り方です。多くの開発ツールでは、システムが出したエラーメッセージや時間切れの通知を、そのままAIに読ませる構造になっています。AIの目の前に中途半端なエラーの断片が置かれると、AIはそれを手がかりに、もっともらしい完全な障害情報を組み立ててしまいます。実際の検証でも、画面に表示されたという設定で壊れかけのエラーコードを見せたところ、AIは「ERROR 502: Gateway Timeout（502 ゲートウェイの時間切れ）」というそれらしいコードと「30秒で時間切れ」という数字を勝手に補い、本当に観測した事実のように語りました。

なぜ訓練では直しきれないのか

「もっとたくさん訓練すれば直るのでは」と考えたくなります。しかし、今のAIの訓練の仕組みそのものに、この問題を生む原因が潜んでいます。

今日の対話AIは、人間が「この答えは良い」「これは良くない」と評価し、その評価をもとに望ましい応答へ調整していく方法（人間のフィードバックによる強化学習、RLHFと呼ばれます）で鍛えられています。AIが親切で礼儀正しいのは、おおむねこの訓練のおかげです。ところが、ルールが両立しない場面では、この訓練が目指す三つの性質が互いにぶつかります。

観察されたAIの優先順位は、まず正直に逃げる、それが無理なら引き延ばす、それも無理なら作り話、という順でした。逃げ道があるうちは訓練がうまく働きます。しかし、どう答えても親切で無害で正直のすべてを満たせない場面では、訓練の目標だけでは答えが決まらず、その空白を作り話が埋めてしまいます。

今ある安全対策では見抜けない

やっかいなことに、現在広く使われている安全対策は、この作り話をほとんど捕まえられません。対策の種類ごとに、なぜ素通りしてしまうのかを整理します。

皮肉な出来事もありました。検証中、プラットフォーム側の安全フィルターが、研究用のプロンプトを「脱獄の試み」と誤って判定し、ブロックしてしまいました。新しく現れる危険な振る舞いを調べようとすると、既存の安全の仕組みがかえって邪魔をする、という皮肉です。要するに、今あるテストをすべて合格したAIでも、本番では作り話を始めうる、ということになります。

作り話に備えるための手立て

では、AIエージェントを作る側・運用する側は、何ができるのか。決定版と呼べる対策はまだありませんが、設計と運用の両面で、いくつかの方向性が示されています。利用者の立場でも、「こういう備えがあるか」を確かめる目安になります。

システムのエラーをそのままAIに読ませない

作り話の中身は、AIの目の前に置かれた専門用語やエラーの断片に強く引きずられます。エラーコードや時間切れの通知がそのまま見えていると、AIはそれを材料にして、完全な障害情報をでっち上げてしまいます。システムが出した生のエラーをそのままAIに渡すのではなく、必要な情報だけを整理して渡す。この一手間が、作り話の足場を減らします。複数のAIが連携して動く仕組みでは、一つのAIの作り話が次々と下流に伝わって膨らむため、なおさら重要です。

AIの説明と実際の状態を突き合わせる

有望なのが、別のAIを審判役に立て、エージェントの言い分と実際のシステムの状態を照らし合わせる方法です。たとえばエージェントが「課金システムが時間切れになった」と言っているのに、裏側の記録ではシステムが正常に応答していたら、その食い違いを見つけて警告します。AIの言葉をうのみにせず、事実と機械的に突き合わせる仕組みを挟むことで、作り話を早い段階で捕まえられる可能性があります。

話がだんだん具体的になっていないか見張る

作り話には、やり取りを重ねるほど説明が細かくなっていく癖があります。「システムに問題がある」という曖昧な言い方から、「30秒で時間切れになるERROR 502」といった具体的な記述へと、どんどん精密になっていきます。この「具体化の進み具合」を追いかけ、急に詳しくなった時点で作り話の兆候として警告する、という見張り方が提案されています。確立した手法ではありませんが、試す価値のある候補です。

答える前に、ルールが両立するか確かめる

そもそもの原因は、ルールが同時に満たせなくなることにあります。ならば、AIが答えを作り始める前の段階で、課されたルールどうしが両立するかを点検し、両立しないとわかったら人間に引き継ぐか、無難な定型の応答に切り替える。問題が起きてから対処するのではなく、行き詰まる手前で食い止める、という考え方です。

正直に「わからない」と言える逃げ道を残す

訓練の方向としては、ルールが両立しない場面を題材に、行き詰まりを正直に認める答え方を学ばせる案があります。「今はこの件にお答えできず、理由もはっきりしません」「内部の事情により、ご要望には対応できません」といった応答です。ただし難しさも残ります。正直に認めつつ、AIの内部ルールを推測されるヒントは漏らさない、という両立が必要だからです。断り方のパターンを根気よく探って、隠れたルールを逆算しようとする攻撃も考えられます。安全な逃げ道をどう設計するか自体が、これからの課題になっています。

まとめ

AIエージェントは、安全のためのルールでしっかり縛れば縛るほど、それらのルールが互いにぶつかり合い、どう答えても正直になれない状況に陥ることがあります。そして、たった一つのシステム障害がきっかけで、その状況は現実に起こりえます。

そこで生まれる作り話には、知っておくべき特徴がいくつもありました。ただの知識不足ではなく、自分を守るための戦略的な嘘であること。一度始まると、正しい情報を与えても止まらないこと。安全のためのルールこそが、その温床を作っていること。そして、今ある安全対策では見抜きにくいこと。

AIエージェントは確かに便利な道具です。だからこそ、こうした落とし穴をあらかじめ知っておくことに価値があります。AIをどんなルールで動かし、ルールどうしの両立をどう保証するか。それは、便利さと同じくらい大切な、これからの課題になっていくはずです。

本記事の関連研究