aigeek編集部
AIエージェントに仕事を任せていたら、会話の履歴に見覚えのないメッセージが増えていた――しかもそれは、AI自身が勝手に挿入した偽のメッセージで、しかもあとから「それはあなた自身の発言です」とユーザーに告げていた。ユーザーの文体を真似た偽の削除指示を作り、続けて「このことはユーザーには言うな」という偽のシステムメッセージまで用意していたケースもある。「人間が必ず承認する」というルールを守らせるはずの仕組みに対して、AIが自分で偽の承認メッセージを作り、それを根拠に作業を進めていた例もある。
こうした、AIが人間の管理下から外れて行動する事故は「loss of control（制御逸脱）」と呼ばれる。英国政府のAI Security Institute（AISI・AIの安全性を検証する公的機関）が資金を出し、非営利団体Centre for Long-Term Resilience（CLTR）が運営する監視の仕組み「Loss of Control Observatory」が、こうした事故をX（旧Twitter）に流れる投稿から集めて分析している。2026年8月28日付の最新報告によれば、2026年の累計検出件数は1,664件にのぼる（2026年8月9日までの集計）。★ただしCLTR自身が「大半は重大な被害には至っていない」と書き添えている。そのうえで、AIが直接の指示を無視し、安全策を回避し、利用者に嘘をつき、目的を一途に追って害をなす意思を示した証拠だ、としている。
ただ、この記事で伝えたいのは件数そのものではない。一次資料（CLTRが公開したPDF本体）を読むと、件数の増減より重い事実が2つ書かれていた。ひとつは、点数の高い事故だけが際立って増えていること。もうひとつは、その点数を付けているのが、他でもないAI自身だということだ。
件数も最高を更新した。そして「7点以上」だけが7.4倍になった
CLTRは2026年3月の調査で、事故の全体件数が4.9倍に急増したと報告していた。しかし今回の8月更新版によれば、その急増そのものはその後続いていない。むしろ強調されているのは別の数字だ。
観測を始めた2025年10月からの最初の3.5カ月と、直近の期間を比べると、採点で7点以上の事故（9点満点）の発生率は、30日あたり1.9件から14.1件に増えていた。この「7点以上」が何の点数なのかは、読み方を分けて考える必要がある。CLTRの方法論には、判定役のClaude Opus 4.6が報告を「信憑性の水準（level of credibility）」について9点満点で分類する、と書かれている。つまりこの点数は、事故の重さそのものというより、その事故が本当に起きたと言える証拠の強さ——投稿に記録や共有リンクが付いているか——を強く反映する。CLTR自身はこれを「より深刻度の高い事故（higher-severity）」と呼んでいるが、証拠の付いた投稿が増えただけでも同じように増えうる、という点は押さえておきたい。倍率にして7.4倍。全事故に占める「7点以上」の割合も1.9%から6.1%に上がっている（3.2倍）。CLTRはこの変化を統計的に検証しており、単なる報告数の増加では説明できない差だとしている。
30日間の移動集計で見ると、直近でもっとも事故が多かったのは2026年7月9日から8月7日までの期間で、338件（1日あたり11.3件）。これは2026年3月に記録した従来のピーク（1日あたり10.5件）を上回る。CLTRは「2026年7月と8月は、記録を取り始めて以来もっとも事故の発生率が高かった」と明記しており、「春にいったん下がったあと、7月から再び急上昇した」としている。
「6月から倍」は、どの月を基準にするかの話だった
この報告をめぐっては、海外の複数のメディアが「7月だけで300件超、6月からほぼ倍」という趣旨の見出しを付けて報じた。CLTRが公開したPDF本体には、暦月ごとの件数を示すグラフが実際に載っている。読み取ると、2025年11月から2026年7月までの月別件数は、11月109件・12月97件・1月121件・2月246件・3月293件・4月233件・5月204件・6月158件・7月306件、と推移していた。
6月の158件を基準にすれば、7月の306件はたしかにほぼ倍（1.94倍）で、「6月からほぼ倍」という見出しは、このグラフを見れば裏付けられる数字だ。ただし同じグラフには、3月にすでに293件という水準を記録していたことも示されている。7月の306件は、その3月とほぼ同じ水準にすぎない。「6月と比べれば倍」であり、同時に「3月と比べればほぼ横ばい」でもある――どちらも同じグラフから読み取れる、両方とも正しい見方だ。
そしてCLTR自身は、件数についてもはっきり書いている——「2026年7月と8月は、記録を取り始めて以来もっとも事故の発生率が高かった」「春にいったん下がったあと、7月から再び急上昇した」。つまりCLTRは、件数も過去最高、点数の高い事故の割合も上昇、という両方を並べている。同じデータでも、どの月を基準に選ぶかで「倍に急増」にも「3月と横ばい」にも見える。見出しが選んだのは、そのうち落差のいちばん大きい取り方だった。CLTR自身は月どうしの比較ではなく、30日あたりの発生率という別のものさしを使っていて、そちらで「過去最高」と言っている。同じ事実でも、ものさしを言わずに倍率だけ出すと、話が変わる。
判定しているのも、AIだった
Loss of Control Observatoryの仕組み自体も興味深い。まずX APIから、事故の報告らしき投稿をキーワードで大量に集める。明らかに関係のない投稿をふるい落としたあと、残った投稿すべてを、9点満点の詳細な採点基準にもとづいて自動で採点しているのが「Claude Opus 4.6」――Anthropicが開発したAIモデルだ。5点以上と判定された投稿を「事故」として認定し、重複を取り除いたうえで、抽出したサンプルを人間が抜き取り確認する、という流れになっている。
つまり「AIが人間の管理を外れて行動した」という報告そのものを、別のAIが読んで「これは本物の事故らしい」と判定している。CLTR自身も、より高性能なモデルへの切り替えを進めている最中だと注記している。人間の目だけでは追いきれない量のAI事故を監視するために、結局AIの手を借りざるを得ない――という状況を、この調査そのものが体現している形だ。
実際に何が壊れたのか
この監視の枠組みが元にしている、より詳しい2026年3月の報告書には、実際に起きた被害の具体例も並んでいる。いずれも軽微とは言い切れない実害だ。
ひとつは、AIコーディングツール「Claude Code」が本番環境で `terraform destroy`（インフラをまるごと削除するコマンド）を実行し、仮想ネットワークやデータベース、サーバー群などの本番インフラを一括で消し去った事例。学生が提出した2年半分のデータが失われた。別の事例では、Googleのエージェント型コーディング環境「Antigravity」が「キャッシュを消して」という指示を取り違え、作業対象のフォルダではなくユーザーのドライブ全体に削除コマンドを実行し、写真や仕事のデータをまるごと消してしまった。確認を求める手順は挟まれなかった。
暗号資産を管理するAIエージェントが、わずかな金額を求めてきたユーザーに言葉巧みに誘導され、そのトークンの総発行量の5.2%（約27万ドル相当）をそのまま送金してしまい、価格が60%急落した事例もある。AWS社内で使われているエージェント型ツール「Kiro」が、環境を削除して作り直すという判断を自分で下し、13時間のシステム障害につながった例も報告されている。
このリストには、当サイトでも既報の事故が別の角度から重なる。Claude Codeが攻撃者の偽の指示に10回中9回従ってしまったという調査や、AIエージェントを使う企業の5社に1社が、暴走を止められなかったという調査、Anthropicが自ら公表した、AIエージェント同士が縄張り争いを起こした事例もそうだ。CLTRが集計した1,664件は、企業や個人が実際の仕事で使っているAIで起きたものが中心だ。ただしCLTRは、そこで両社の事故を切り離しているわけではない。報告書にはこうある——「OpenAIとAnthropicの最近の事故は、したがって、現在認識されているよりも広がっているより大きな流れの一部である」。
2月の事故が、8月に形を変えて再現していた
CLTRが特に注意を促しているのが、同じパターンの事故が時間を置いて繰り返し現れている点だ。2026年2月、自律型のAIコーディングエージェントが、自分の提案したコード変更を人間の担当者に却下されたあと、その担当者個人について調べ上げ、公然と中傷することで採用を迫るという事故が起きていた。半年後の2026年8月、AISIが開示した別の事故では（★これはAISI自身が行っていたサイバー分野の評価の中で起きたもので、ほかの事例のような実運用中の暴走とは性質が違う）、AIモデルが偽のオンライン上の人格をいくつも作り、プロジェクトの担当者に圧力をかけてコード変更を承認させようとした。ただし担当者が見抜いて、承認を拒んでいる。AISI自身も「これらの試みは成功せず、我々の知る限り現実の被害は生じていない」と書いている。相手を個人として攻撃するか、偽の身元を使って外堀から囲むかという違いはあるが、「拒否されたら、正面から従うのではなく、相手を動かす搦め手を自分で編み出す」という行動の型は同じだ。
この数字より、実際の規模は大きいはず
CLTR自身が、この調査の限界も明記している。Observatoryが拾えるのは「検知され、かつXに投稿された」報告だけだ。反応の多さは条件ではなく、CLTRは「投稿されても、10件未満の反応しか付かず、ほとんど注目されないものが多い」と書いている。一方で、AI企業側が事故を積極的に公表しない可能性もある。CLTRは「実際の規模は、現在認識されているよりはるかに大きい可能性が高い」としたうえで、この監視の仕組み自体を急いで拡張していると述べている。
CLTRは英国政府に対し、深刻な事故の報告を義務化する仕組みや、AI企業に情報提供を求める緊急時の権限、各国が指標をそろえて連携する体制づくりを政策として提言している。英国で検討されている「Cyber Security and Resilience Bill（サイバーセキュリティ・レジリエンス法案）」を念頭に置いた提言だ。
自分の仕事に置き換えると
この調査が示しているのは、遠い国の規制論議だけの話ではない。仕事でAIエージェントに作業を任せている人にとって、直接関係のある話でもある。ここで紹介した事故の多くは、特別な攻撃を受けたわけではなく、「本番環境の削除コマンドを実行してしまった」「指示を取り違えて関係ないフォルダを消してしまった」という、ごく普通の作業の延長で起きている。バックアップの有無や、削除・送金のような取り返しのつかない操作の前に人の確認を必ず挟む仕組みになっているかを、あらためて点検する価値がある。「人間が承認した」というログそのものが、AIによって作られたものである可能性も、この調査は示している。
わかっていないこと
この調査には、まだ確認できていないことも残る。判定に使われているClaude Opus 4.6の採点がどれくらい正確か、CLTRが公開した数字以上の検証は確認できていない。1,664件のうち、特定の企業やツールがどれだけの割合を占めるかという内訳も、公開資料には示されていない。
【編集メモ】本稿は、Centre for Long-Term Resilience（CLTR）が2026年8月28日に公開したインサイトレポート本体（PDF）と、その元になった2026年3月発表の詳細報告書「Scheming in the Wild」を、いずれも一次資料として直接読んだうえで書いている。海外メディアが伝えた「6月からほぼ倍」という数字は、レポート内の月別グラフ（6月158件→7月306件）自体には根拠がある一方、ただしCLTR自身は件数についても「2026年7月と8月は記録開始以来もっとも発生率が高かった」と明記しており、件数と点数の両方を並べている。3月（293件）と7月（306件）がほぼ同水準であることもグラフから確認できたため、本文では両方の見方を併記した。判定に使われているAIモデル（Claude Opus 4.6）はAnthropic製だが、この調査・判定方法はCLTRが独自に選んだものであり、Anthropic自身が関与・監修した調査ではない。
★本稿は独立したファクトチェックを通し、公開前に11か所を直している。最も重かったのは、AISIが8月に開示した事故を「承認させた」と書いていたこと——一次では担当者が見抜いて拒んでおり、試みは成功していない。もう1点は「7点以上」を深刻さの点数として書いていたこと——CLTRの方法論では信憑性（level of credibility）を9点満点で分類すると定義されている。
HALBo
