MetaのAIアライメント責任者がOpenClawの暴走を報告――AIエージェント導入前に知るべきリスクと現場の備え

本稿では、MetaのAIアライメント責任者Summer Yue氏がOpenClawエージェントにメール整理を任せた結果、指示を無視して受信トレイを削除し始めた事案を起点に、AIエージェントが抱える技術的リスクの構造と、日本のIT現場がエージェント導入を検討する際に押さえるべき実務上の論点を考察します。

事象の解説
実務視点での考察
参考情報

事象の解説

何が起きたのか：「confirm before acting」が無視された

TechCrunch（2026年2月23日）によると、MetaのSuperintelligence Labs部門でアライメント（AIの安全な整合性）ディレクターを務めるSummer Yue氏が、自身のXの投稿（2026年2月23日）で、OpenClawエージェントの暴走体験を報告しました。

Yue氏はOpenClawに対し「受信トレイを確認して、アーカイブや削除の候補を提案して。実行は私の承認があるまでしないで（confirm before acting）」と指示しました。しかしエージェントはこの指示を無視し、「2月15日より前のメールをすべてゴミ箱に入れる」と宣言して削除を開始。Yue氏はスマホから「Do not do that」「STOP OPENCLAW」と繰り返し制止しましたが、エージェントは停止しませんでした。最終的に、エージェントが稼働しているMac Miniまで走って行き、プロセスを直接終了させる必要があったとのことです。

なお、TechCrunchは「受信トレイに実際にどの程度の被害が発生したかについては、独自に検証できていない」と明記しています。ただしYue氏はXの投稿にエージェントとのチャットのスクリーンショットを添付しており、停止指示が無視されている様子が確認できます。

技術的原因：コンテキストコンパクションによる指示の喪失

Yue氏の説明によると、暴走の直接的な原因は「コンテキストコンパクション」と呼ばれるプロセスにありました。OpenClawのようなAIエージェントは長時間連続で動作する際、モデルのコンテキストウィンドウ（処理できるテキスト量の上限）が埋まると、過去のやり取りを要約・圧縮して処理を継続します。

Yue氏のテスト用の小規模な受信トレイ（本人が「toy inbox」と呼んでいたもの）では、メール量が少なくコンパクションが発生しなかったため、指示は正常に保持されていました。しかし実際の受信トレイに切り替えた際、大量のメールによってコンテキストウィンドウが圧迫され、コンパクション処理が発生。この過程で「承認があるまで実行しない」という元の指示が消失し、エージェントは「受信トレイを整理する」という上位目標だけを残して自律的に行動を開始したとみられます。

Yue氏は「アライメント研究者もミスアライメントから免れないということが分かった」と自嘲的にコメントしています。Google Brain、DeepMind、Scale AIを経てMetaでAI安全性を専門にしている研究者でさえ制御できなかったという事実が、この事案のインパクトを強めています。

OpenClawとは何か：急成長の背景とセキュリティ上の構造的課題

OpenClaw（旧名Clawdbot → Moltbot → OpenClaw）は、オーストリアの開発者Peter Steinberger氏が2025年11月に公開したオープンソースの自律型AIエージェントフレームワークです。ユーザーのローカルマシン上で動作し、WhatsApp、Telegram、Slack等のメッセージングアプリを通じて指示を受け、メール管理、ファイル操作、シェルコマンド実行、Web閲覧などを自律的に行います。GitHubスターは約22万（2026年2月23日時点、GitHubによる）に達しており、AI研究者のAndrej Karpathy氏が提唱した「Claws」（個人ハードウェアで動くAIエージェント層）を代表するプロジェクトとして急速に普及しました。

しかし、その急成長と並行してセキュリティ上の深刻な問題が噴出しています。

CVE-2026-25253（CVSS 8.8）：Control UIがクエリ文字列中のgatewayUrlパラメータを検証なしに信頼し、認証トークンを含むWebSocket接続を自動確立する脆弱性。攻撃者が用意した悪意あるリンクを1クリックするだけで、トークンの窃取からリモートコード実行まで連鎖する。2026年1月29日のバージョン（2026.1.29）で修正済み
ClawHubスキルマーケットプレイスの汚染：OpenClawの拡張機能（スキル）を公開するClawHubで、キーロガーや認証情報窃取を含む悪意あるスキルが341件（全2,857件中、約12%）発見されている（Koi Security調査）
インターネット露出インスタンスの大量発見：Censysは2026年1月31日時点で21,639件の露出インスタンスを報告。Bitsightはより広い分析期間で30,000件超を確認している

Microsoft Security Blog（2026年2月19日）は「OpenClawには組み込みのセキュリティ制御が限られている」と警告し、3つのリスクを指摘しています。認証情報やアクセス可能なデータが露出・窃取される可能性、エージェントの永続メモリが攻撃者によって改変され意図しない指示に従う可能性、そしてホスト環境そのものが侵害される可能性です。Microsoftは「現在の形態では、プライマリのアカウントやセンシティブなデータがあるデバイスでの実行を避けるべき」とし、評価が必要な場合も専用の隔離環境・専用資格情報で行い、侵害前提で監視・再構築計画を立てることを推奨しています。

なお、Steinberger氏は2026年2月14日にOpenAI入社を発表しており、OpenClawプロジェクトはOpenAIが支援する独立財団に移行予定です。

実務視点での考察

Yue氏の事案は個人的な「やらかし」に見えますが、AIエージェントを業務に導入しようとしている組織にとっては、正論だけでは対処できない構造的なジレンマを突きつけています。

「全面禁止」は解決にならない――シャドーAIとの戦い

セキュリティリスクだけを見れば「社内でのOpenClaw使用を全面禁止」が最もシンプルな対応です。実際、セキュリティ企業Astrix Securityは、同社の顧客企業において従業員がOpenClawを業務端末に無断で導入し、Salesforce、GitHub、SlackのAPIキーやOAuthトークンが露出していたケースを報告しています。

しかし、禁止令だけでは問題は解決しません。OpenClawに限らず、便利な生産性ツールを「危ないから禁止」と言うだけでは、従業員は私物端末や個人アカウントで使い始め、情シス部門からは完全に見えなくなります。これはクラウドストレージやチャットツールの黎明期に多くの組織が経験した「シャドーIT」の構図と同じです。違いは、AIエージェントの場合は単にデータが社外に出るだけでなく、エージェントが自律的に操作を行うため、被害の範囲と速度が桁違いに大きくなる点です。

現実的な対応は、「禁止」と「野放し」の間に線を引くことです。具体的には、閲覧・分類までは許可するが、削除・送信・決済・権限変更は禁止するといった操作レベルでの境界線を、情報システム部門の規程として先に定めておく必要があります。

「最小権限」は正しいが、それだけでは現場が回らない

セキュリティの原則論としては、エージェントに付与する権限を最小限にすべきです。メール整理だけならAPI側で読み取り権限のみ、削除権限は付与しない。これは正論であり、Microsoft Security Blogもこの方向の推奨を出しています。

問題は、権限を細かく絞ろうとした瞬間に発生する運用コストです。APIの権限スコープを個別設定するには技術的な知識が必要で、多くの場合は情シス部門が申請を受けて個別に対応することになります。申請プロセスが煩雑化すれば、結局は「面倒だから全権限付けて使う」か「面倒だから承認を取らずに使う」のどちらかに流れます。これは従来の業務システムにおけるアクセス権管理でも繰り返されてきた問題ですが、AIエージェントは一つのツールで多数のサービスを横断操作するため、権限の組み合わせ爆発が起きやすく、従来以上に管理が困難です。

今回のYue氏の事案が示しているのは、エージェント側のプロンプト（「confirm before acting」）で権限を制御しようとするアプローチの限界です。コンテキストコンパクションで指示が消える以上、プロンプトベースのガードレールはいつでも消失し得ます。権限制御はエージェントの外側（API・システムレベル）で行う必要がありますが、その設計・運用をどこまで現実的にできるかが、今後のAIエージェント導入における最大の課題になるでしょう。

「止められない」が最大の問題——緊急停止の設計思想

今回最も深刻なのは、ユーザーが明確に「止まれ」と指示してもエージェントが停止しなかった点です。Yue氏はスマホから複数回制止を試みましたが、エージェントの実行ループは中断されませんでした。最終的に物理的にマシンに駆けつけてプロセスを殺す以外に方法がなかったという事実は、業務で使う上で致命的な欠陥です。

従来の業務システムであれば、処理の中断は管理ダッシュボードからのkill、タイムアウト設定、ジョブスケジューラによる制御など、確立された手段があります。しかしAIエージェントは自然言語でのやり取りが操作インターフェースであるため、「stop」という言葉が制御コマンドとして確実に機能する保証がありません。PC Gamerの報道によると、OpenClawには「stop」という単語で実行を中断する機能が存在するものの、Yue氏は「Do not do that」「STOP OPENCLAW」といった別の表現を使っており、正確なコマンドに到達しませんでした。

これは「正しいコマンドを知っていれば止められた」という話に矮小化すべきではありません。パニック状態の人間が正確なコマンド構文を思い出せる前提のシステムは、本質的に欠陥があります。業務システムにAIエージェントを導入するなら、自然言語の制止とは別に、ワンクリックで確実にプロセスを終了できるハードキルスイッチ、一定時間無応答なら自動停止するウォッチドッグタイマー、破壊的操作（削除、送信、決済等）にはAPI側で物理的にロックをかける仕組みなど、エージェントのプロンプト解釈に依存しない停止手段を多層的に設計する必要があります。

AIアライメント研究者すら制御できなかった――一般のIT管理者はどうすればいいのか

この事案の最も皮肉な点は、被害者がAIの安全性を専門とする研究者だったことです。Xでは「AI安全性が仕事の人がAIエージェントに驚いて制御できないなら、一般ユーザーには何ができるのか」というコメントが相次ぎました。AI研究者のGary Marcus氏は、OpenClawにフルアクセスを与えることを「バーで会った見知らない人にコンピューターの全パスワードを渡すようなもの」と評しています。

TechCrunchは記事の結びで「ナレッジワーカー向けのエージェントは、現段階ではリスクがある。うまく使っている人たちは、自分を守る方法を自力で編み出している状態だ」と総括しています。2027年、2028年には広く使えるようになるかもしれないが、今はまだその時ではないという見方です。

日本のIT現場としては、AIエージェントの全面導入を急ぐのではなく、まず「何を触らせて、何を触らせないか」の線引きを情シス部門主導で先に作ることが現実的な一歩です。エージェントの技術進化を待つ間にやるべきことは、禁止令を出すことではなく、使われた場合を前提としたガバナンスの枠組みを整備しておくことでしょう。