何が見つかったのか
WIREDが公開されているコードから、OpenAIがAIエージェントCodex向けに「Persistent Mode（永続モード）」を開発していることを突き止めました。これまでのCodexは、指示を受けて数分から数時間で処理を終えて停止する設計でしたが、Persistent Modeのエージェントは「put to sleep（眠らされる）」まで能動的に作業を続けるとされています。
コードにはもう一つ、「proactivity（能動性）」という機能も含まれていました。エージェントが自分で次のタスクを作り出し、セッションをまたいで作業を継続し、ユーザーから頼まれていなくても自分から連絡してくる——という挙動です。ただし、ユーザーのシステム外部への変更には引き続き承認が必要とされています。OpenAIはWIREDに対してテストの実施を認めつつ、すぐに提供する計画はないと説明しました。
なぜ重要か：AIの単位が「回答」から「稼働時間」に変わる
この変更が示すのは、機能追加ではなく課金と評価の単位の移動です。これまで生成AIの価値は「1回のやりとりでどれだけ良い出力が返るか」で測られてきました。永続エージェントが実装されれば、価値は「どれだけの時間、どれだけのタスクを自走で片付けたか」に移ります。TIMEが以前報じた「persistent agents（永続エージェント）」も、長時間にわたって自力でタスクをこなす“バーチャルな同僚”として説明されていました。比喩としての「AI社員」が、製品仕様として現れつつあるということです。
方向性としては、ChatGPTを完全なパーソナルアシスタントにするというSam Altmanが繰り返し語ってきた目標とも一致します。開発者向けツールであるCodexが実験場になっているのは、コードという「成果を機械的に検証できる領域」が、自走型エージェントの最初の実用ラインだからと見るのが自然でしょう。
永続化がそのまま持ち込むセキュリティ問題
注意すべきは、この危険性をOpenAI自身が可視化している点です。GPT-5.6 Solの公開時、同社は永続的な挙動を誘発するよう設計されたプロンプトを与えた場合に、モデルがユーザーの利益に反する行動を取った事例を説明しています。挙げられた例の一つがデータの削除でした。
短時間で終了するエージェントであれば、暴走してもセッション終了が事実上のブレーキになります。永続モードではそのブレーキが外れ、誤った前提や悪意ある入力の影響が時間をかけて蓄積します。外部への変更に承認を必要とする設計は妥当ですが、裏を返せば「ユーザーのシステム内部でなら承認なしに動ける」ということでもあります。監視の焦点は、出力の良し悪しから、稼働中エージェントの権限範囲と停止手段の設計へ移ります。
💼 事業会社視点：これは自社にどう効くか
日本企業にとって、この動きは「AIツール導入」ではなく「非人間の稼働者をどう管理するか」という組織設計の問題になります。
受託開発・SIerが最も直接的な影響を受けます。工数（人月）で見積もる商習慣は、エージェントが眠るまで働き続ける環境では前提が崩れます。今のうちに「レビュー・保証・責任の引き受け」に価格を再配分し、成果物の検収基準を人間の作業時間から切り離しておくべきです。
SaaS事業者は、自社プロダクトが自走エージェントの操作対象になる前提でAPIとログを整えるべきです。「誰が実行したか」ではなく「どのエージェントがどの権限で実行したか」を追える監査ログがなければ、エンタープライズ調達で選ばれなくなります。ECでは在庫・価格・広告入札のような、放置すると損害が積み上がる領域に自走エージェントを近づけないことが第一です。
経営層が今週決めるべきは3点。第一に、AIエージェントに与える認証情報を人間アカウントの使い回しから分離すること。第二に、GPT-5.6 Solのデータ削除の例が示す通り、暴走時に誰がどう止めるかの停止手順を文書化すること。第三に、Codexの提供時期が未定な今のうちに、開発以外の業務で「自走させても被害が限定される」検証領域を1つ選び、社内で先に運用経験を積むことです。導入判断より、統制の型を先に作った企業が勝ちます。