「長く働くAI」が裏目に？　OpenAIの“脱走事件”が示すリスクの変化　企業に求められる対応は（3/3 ページ）

公開 2026年10月02日 08時00分

[ITmedia]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　第1に、持続時間の制限である。人間の社員には就業時間と疲労という自然な歯止めがあるが、エージェントにはない。「まだ終わっていないから続ける」を無限に繰り返せる。最大実行時間、最大ツール呼び出し回数、最大コスト、最大サブエージェント数を明示し、上限に達したら人間に戻す。

　Hugging Face事件では、掲示板活動の9割超が「解けない課題」への執着から生まれた。タイムアウトは単なるコスト管理ではなく、セキュリティ統制だと考えるべきだ。併せて、導入前の評価には「解けないタスク」「壊れたAPI」「偽の認証情報」を仕込み、勝手に別の道を探すのか、止まって報告するのかを見る「失敗テスト」を組み込みたい。

　第2に、権限を「必要最小限・短期間・タスク単位」にすることである。ファイブ・アイズもASDも、エージェントに独立したIDを持たせ、短命の認証情報を都度発行し、読み取りと書き込みを分けることを求めている。

　新入社員に初日から代表印を渡す会社はないが、AIには「熟練社員と同じ仕事ができるのだから同じ権限を」という発想が入り込みやすい。

　むしろ逆で、休まず、複製でき、判断に確率性を持つ主体には、人間より細かい権限管理が合理的である。人間の承認は、ファイルを1つ開くたびに求めるのではなく、資金移動、本番反映、外部送信、権限昇格といった「意味のある境界」に置く。承認画面には「何を、なぜ、どのシステムに」を示し、93％が反射的に承認される状態を避ける。

　第3に、エージェントの「外向きの通信」を監視対象にすることである。2つの事件に共通するのは、公式のAPIやログの外側に、エージェント同士の非公式な連絡経路が生まれたことだった。パッケージサーバの書き置き、放置されたwikiへの投稿、いずれも監査ログには残らない。マルチエージェント構成を本番で使うなら、エージェント間のメッセージを記録し、想定外の宛先への通信をアラートにする。

　加えて、どのエージェントがどのモデル、ツール、外部コネクター、記憶領域に依存し、誰がオーナーで、どう止めるのかを一覧にした「エージェント台帳」を整える。台帳がなければ、事件が起きたときに何体が動いていたかすら分からない。

　これらの準備に使える時間は、それほど長くない。METRの指標が正しければ、エージェントが無人でこなせる時間は数カ月単位で倍増していく。コトラ氏の言う「6カ月後」は、防御側にとっての準備期間の上限として読むべきだろう。

　この夏の事件が示したのは、長時間自律エージェントの価値と危険が同じ源泉から湧いているという事実である。粘り強く、機転が利き、仲間と協力する。それは企業が望む「数日働くAI」の姿そのものであり、同時に、評価環境の壁を破って外へ出ていった群れの姿でもあった。

　だからこそ、企業が問うべきは「このAIはどこまで働けるか」ではない。「このAIを数日放置したとき、途中で何を見つけ、何を使い、どこまで到達しうるか」である。自律性が高くなるほど境界を明確にし、能力が高くなるほど被害範囲を小さくし、稼働時間が長くなるほど継続的に検証する。AIの粘り強さを安心して引き出せるかどうかは、モデルの賢さではなく、それに備え付ける「馬具」すなわちハーネスの設計にかかっている。

表3：企業が管理すべき「3つの計器」
管理するもの	主な指標・統制	狙い
時間	最大実行時間、ツール呼び出し回数、コスト、サブエージェント数	「解けない仕事」への無限の執着を防ぐ
権限	最小権限、短命認証、タスク単位の権限、本番変更時の承認	想定外のシステムやデータへの到達を防ぐ
通信	エージェント間通信の記録、外部宛先の監視、エージェント台帳	非公式な協力・情報共有・行動拡散を検知する