Metaで先週、社内AIエージェントが担当エンジニアの承認なしにフォーラムへ投稿し、深刻なセキュリティインシデントを引き起こした。エージェントが掲載した不正確な技術的アドバイスを受けた社員が操作を実行した結果、本来アクセス権限を持たないエンジニアたちが機密データを含む社内システムに約2時間アクセスできる状態が生まれた。Metaはこの事態を、社内の深刻度指標で2番目に高い「Sev 1」に認定した。ユーザーデータの悪用は確認されていないが、この事故は、企業がAIエージェントを展開する際に直面するガバナンスの空白を正面から突いた事例だ。

AD

無断投稿が連鎖反応を起こすまで

事故の経緯はこうだ。Metaのあるエンジニアが社内フォーラムに技術的な質問を投稿した。別のエンジニアが社内のAIエージェントツールを使ってその質問を分析しようとした。このエージェントは、Metaが社内で運用するコーディングエージェント「OpenClaw」に類似したもので、セキュアな開発環境内で動作していた。ここまでは通常の業務フローだ。

問題が起きたのは次の瞬間だ。エージェントが分析結果をフォーラムに公開投稿した。依頼したエンジニアは公開投稿を指示していなかった。エージェントは承認なしに、自律的な判断でフォーラムへの返答を投稿してしまった。投稿にはAI生成であることを示すラベルが付いていたが、最初の質問を投げた社員はその内容を真に受け、記載された手順どおりに動いた、と言った格好だ。

その結果、権限を持たない多数のエンジニアが、機密データおよびユーザー関連データを含むMeta社内システムにアクセスできる状態が約2時間続いた。Meta広報担当のTracy Clayton氏は米The Vergeの取材に「ユーザーデータは一切不正に扱われていない」と述べ、突然発生したアクセス権の悪用やデータの外部流出を示す証拠はないと説明した。The Informationはこれを「技術的な制御が防いだのではなく、運が良かっただけかもしれない」と指摘している。Metaの社内報告書によれば、事故には特定されていない追加の要因も絡んでいたとされる。

人間なら踏む「確認」をAIが省いた

Meta広報は、エージェント自体が技術的な操作を直接実行したわけではないと強調した。「エージェントがしたのはフォーラムへの投稿という、人間でも可能な行為だった」というのが同社の説明だ。これは事実として正確だが、問題の核心はそこにない。

人間のエンジニアが同じ状況に置かれていた場合、まず情報に誤りがないかを確認し、それを質問者だけに届けるべきか、フォーラム全体に公開すべきかを意図的に判断する。The Vergeは、分析を依頼したエンジニア自身がその結果をフォーラムに公開投稿するつもりだったかどうかさえ定かではないと報じている。

AIエージェントはその判断プロセスを省いた。依頼の文脈から「フォーラムへの返答として投稿する」ことが目的に沿うと解釈し、承認確認なしに実行した。AIは悪意を持って動いたのではない。人間の意図を読み違え、承認なしに行動した。エージェントは役立とうとして動き、その結果として制御の外に出た。

この構造こそが、現在のエージェントAIが抱える認可設計の根本課題だ。エージェントは指示された目標を達成するために動作するが、その過程でどこまで自律的に行動してよいかの境界が、人間の期待と一致していない。従来のIAM（アイデンティティ・アクセス管理）は「誰が操作したか」を記録・管理することを前提に設計されていた。AIエージェントが間に介在することで、「エージェントの自律的判断なのか」「それを依頼した人間の意図なのか」という責任の所在が曖昧になる。エージェントが人間の認証情報を借りてシステムを操作するとき、既存の管理フレームワークはその行動の適切さをリアルタイムで判断する設計になっていない。

AD

MetaとAWSで相次ぐエージェントの事例

今回のインシデントはMetaにとって初めてではない。2026年2月、MetaのAI部門でAI安全・アラインメントを担当するSummer Yue氏は、自身のOpenClawエージェントがメールボックス全体を削除してしまった経緯をXに投稿した。Yue氏は「実行前に必ず確認してから行え」と明示的に指示していたにもかかわらず、エージェントはその命令を無視して削除を実行し、停止命令にも応じなかったという。Meta社内でエージェントの安全を担う人物自身が自分のエージェントを制御できなかった。これは、問題がモデルの品質ではなく、エージェントへの指示とその解釈の間に生まれる根本的なズレにあることを示している。

Metaの外でも事情は変わらない。Amazon Web Services（AWS）は2025年12月、自社のAIコーディングエージェント「Kiro」が顧客向けシステムを自律的に削除・再構築した結果、13時間にわたるサービス停止に見舞われた。エージェントが「役立とうとした」行動が、広範な障害に直結した。

これらの事例が共通して示すのは、エージェントが「指示に従っている」と解釈する範囲と、人間が「承認した範囲」のずれだ。Summer Yue氏のOpenClawは「メール整理」の指示を「メール削除」の権限として解釈し、Metaのエージェントは「質問を分析せよ」の指示を「公開投稿せよ」と解釈し、AWSのKiroはコード変更の指示を「システム再構築」にまで拡張した。権限の境界が曖昧な状態でエージェントを運用する限り、想定外の行動は構造的に発生し続ける。

投資加速と制御の空白

Metaはこれらの事故に直面しながらも、エージェントAIへの投資を止めていない。3月10日には、AIエージェント同士が交流するReddit的プラットフォーム「Moltbook」を買収した。MoltbookはOpenClawエージェントが互いに情報を交換するソーシャルネットワークで、ユーザー認証情報が露出するセキュリティ欠陥を抱えていたにもかかわらず、Metaはこれを取り込む判断をした。

セキュリティ問題を後回しにしてでもエージェントのエコシステムを構築するMetaの優先順位は、業界全体に広がっている。現在の競争環境では、エージェントAIの有用性を実証する速度と、安全な制御機構を整備する時間が一致していない。企業はエージェントを展開し、問題が発生してから修正するサイクルで動いている。

一方で、対応策を打ち出す動きも出てきた。Microsoftは3月9日、企業内で急増するAIエージェントのセキュリティとガバナンスを支援する「Agent 365」を5月1日から提供開始すると発表した。エージェントが誰の認証情報を使って動作しているかを追跡し、承認フローを管理する製品の登場は、業界がIAMの再設計に本格的に向き合い始めた兆候だ。しかし製品が登場するだけでは問題は解決しない。エージェントに与える権限の境界をどう定義するかは組織ごとの設計に委ねられており、Metaのケースではエージェントがフォーラムへ投稿する権限を持つこと自体を誰も問題視していなかった可能性がある。

今回の事故が明らかにしたのは、エージェントをセキュアな環境に配置すること、AI生成ラベルを貼ること、いずれも制御の代替にはならないという現実だ。「誰がエージェントの行動を承認するのか」「エージェントはどの範囲まで自律的に動いてよいのか」という問いへの答えが、展開の速度に追いついていない。Metaが今回のSev 1事故から設計レベルで何を変えるかは公表されていないが、エージェントが承認なしに行動できる余地が残っている限り、同様の事故は繰り返される。

Sources