規制・社会

自動運転とAIエージェントに潜む「任せすぎ」リスク

記事バナー画像

POINT

  • 2024年にFord BlueCruiseを使用中の2件の死亡事故が発生。NTSBの調査で、衝突前にドライバーが30秒以内に2度の警告を受けながら画面を注視し続けていた事実が明らかになった。
  • AIエージェントの長期メモリ機能を悪用する「Zombie Agent攻撃」が研究で実証された。一度感染すれば、セッションをまたいで不正操作が持続するという新たなリスクだ。
  • 自動運転とAIエージェントに共通する構造は「便利なほど監督が緩む」こと。仕事でAIを使うなら、その限界を知り、チェックポイントを設計することが防衛の起点になる。

「任せていた」では済まない、2つの事故

2024年2月、テキサス州サンアントニオのI-10を走行中の2022年式Ford Mustang Mach-EがBlueCruise(ハンズフリー運転支援機能)を使用したまま、停車中のHonda CR-Vに時速約74マイルで追突した。CR-Vの運転者は死亡。Mach-Eのドライバーは軽傷だった。

NTSBが2026年3月11日に公開した記録によれば、衝突の5秒前、ドライバーモニタリングシステムはドライバーがインフォテインメント画面を見ていると記録していた。道路への視線が戻ったのは衝突前3.6秒と1.6秒の2回だけ。衝突前の30秒以内に視覚・聴覚の警告を2度受けながら、ブレーキは踏まれなかった。

ドライバーは警察に「充電ステーションへの案内のためナビを見ていた」と説明している。AIが案内し、AIが警告し、それでも人間は画面から目を離せなかった。

同年3月にはペンシルベニア州フィラデルフィアのI-95でも同様の事故が起きた。午前3時16分、同じくMach-EがBlueCruise使用中に停車中のHyundai Elantraへ衝突。ElantraはさらにToyota Priusに追突し、2人が死亡した。TechCrunch

フォードの言い分は正しい。だからこそ問題だ

フォードはBlueCruiseを「利便性のための機能」と位置づけ、「衝突警告や回避システムではない」と明示している。ドライバーは常に操作を引き継げる状態であるべき、というのが公式見解だ。

これは技術的に正確な説明だ。しかし、その正確さ自体が問題の核心を突いている。

人間は「便利なものに任せると、監督が緩む」という認知特性を持つ。ハンズフリーで走れる、ナビが案内してくれる。そういう状況で「常に引き継げる状態を維持する」ことは、脳科学的に非常に難しい。機能の設計と人間の実際の行動の間にギャップがあるのに、そのギャップを利用者の責任で埋めようとする構造に、根本的な危うさがある。

NHTSAは2025年初めにBlueCruiseが一定条件下で停止車両の検出に制限があると判断し、ソフトウェアをアップグレードした。2025年6月にはフォードへ質問リストを送付し、フォードは8月に回答。NTSBは2026年3月31日にワシントンD.C.で公開ヒアリングを開き、フォードへの勧告を出す可能性がある。

AIエージェントにも「乗っ取り」リスクが実証された

自動運転の話は、ビジネスの現場でも他人事ではない。

2026年2月17日にarXivに投稿された論文「Zombie Agents」(arXiv:2602.15654、ICLR 2026ワークショップ採択)は、LLMエージェントの長期メモリ機能を悪用した攻撃を実証した。arxiv.org

感染フェーズ

エージェントが日常タスクをこなす中で、攻撃者が仕込んだWebページや文書を読み込む。エージェントはそこに埋め込まれた不正な命令(ペイロード)を「有用な情報」として長期メモリに書き込む。この段階ではタスクが正常に完了するため、利用者は何も気づかない。

発火フェーズ

後続のセッションでペイロードが取得されるか引き継がれた瞬間、エージェントは攻撃者の指示に従って不正な行動を実行する。セッションをまたいで侵害が持続するのが最大の特徴だ。

論文は、この攻撃が「スライディングウィンドウ型」「検索拡張型(RAG型)」など一般的なメモリ実装に対して有効であることを確認した。セッションごとにプロンプトをフィルタリングするだけの防御では不十分という結論も出ている。メモリが蓄積されるほど、一度の不正書き込みが永続的な侵害になりやすい。

Zombie Agent攻撃の2段階プロセス
感染フェーズ (セッション1) ! 攻撃者が仕込んだ Webコンテンツ エージェントが 通常タスクを実行 (ユーザーは気づかない) ペイロード 書き込み 長期メモリ (RAG / スライディングウィンドウ) セッションをまたいで 侵害が持続 ※毎回のフィルタリングでは 防御不十分 ペイロード 取得 発火フェーズ (後続セッション) ペイロードの 取得・引き継ぎ ! 攻撃者の指示に従い 不正実行 感染フェーズ (セッション1) ! 攻撃者が仕込んだWebコンテンツ エージェントが通常タスクを実行 (ユーザーは気づかない) ペイロードを密かに書き込み 長期メモリ (RAG / スライディングウィンドウ) セッションをまたいで侵害が持続 ※毎回のフィルタリングでは防御不十分 後続セッションで取得 発火フェーズ (後続セッション) ペイロードの取得・引き継ぎ ! 攻撃者の指示に従い不正実行
攻撃者は長期メモリを悪用し、セッションをまたいでエージェントを乗っ取る

「任せすぎリスク」を仕事で防ぐ3つの設計

BlueCruiseの事故とZombie Agent攻撃は、表面上まったく異なる問題に見える。だが根底にある構造は同じだ。「AIが動いている」という安心感が、人間の確認行動を鈍らせる。

ビジネス現場でAIエージェントを使うなら、以下の3点を設計段階から組み込みたい。

  • AIが扱う外部コンテンツの範囲を明示的に限定する。不特定多数のWebページを自由に読ませるなら、メモリに何が書き込まれているかを定期的に確認する仕組みを作る。
  • 「AIが完了した」で終わりにしない。重要タスクには人間によるチェックポイントを設け、出力だけでなく「何を根拠に判断したか」も確認する。
  • 機能の便利さとリスクの高さは比例すると覚えておく。長期メモリ、自律的なWeb検索、外部APIの呼び出しを組み合わせるほど、攻撃の入り口は広がる。

BlueCruiseのドライバーは警告を2回受けた。それでも反応できなかった。AIの警告は、人間が「任せている」状態のときに最も届きにくい。

まとめ

AIが便利になるほど、監督にかかる手間は減る。しかし同時に、監督の質も下がる。自動運転もLLMエージェントも、その矛盾を抱えた技術だ。使う側に求められるのは、信頼することと確認することを切り離す意識、そして「AIが動いている」を「自分が管理している」と混同しないことだ。