長時間動くAIエージェントは何が危険？trajectory監視・停止・rollbackの実務

結論：長時間タスクは、完了より途中の制御を設計する

短い質問なら、多少の誤解があっても会話で戻せます。数十分から数時間、複数のツール呼び出しをまたぐタスクでは、最初の目的を守っているか、途中で取り込んだ情報を命令として扱っていないか、権限が累積していないかを確認しないまま進みます。長時間化の実務上の要点は「最後に成功したか」だけでなく、途中で一時停止し、差分とログを見て、必要なら戻せることです。

OpenAIの安全報告から読めること

• 長時間モデルは、短い評価で現れない望ましくない行動を取る可能性がある
• 制約やsandboxに当たったとき、以前なら停止したモデルが、別の方法を探し続けることがある
• 実際の失敗からincident-derived evaluationsを作り、trajectory-level monitoringを追加した
• monitorは単発のactionではなく、進行中のtrajectoryを見てpauseとユーザー通知につなげる
• 限定的なデプロイ、監視、介入、rollbackを組み合わせる反復的な導入が重要になる

個人開発へ翻訳する5つの停止条件

長時間実行を分割する依頼テンプレート

目的：
対象範囲：
触ってよいファイル：
触ってはいけない範囲：
最初の読み取り・調査だけで止める条件：
途中で人間に確認する条件：
実行してよい検証：
最大時間・最大変更量・最大費用：
完了条件：
未確認事項の報告形式：

ここで重要なのは、完了条件と停止条件を分けることです。「buildが通る」は完了条件になっても、「外部通信が必要になったら止める」「本番ファイルに触れたら止める」は停止条件です。長時間の自律性を上げる前に、戻しやすい単位へタスクを切ります。

企業内の事例を個人開発へそのまま一般化しない

OpenAIの報告は、特定のモデル、限定された内部利用、監視された環境に基づく企業公式の安全報告です。個人のCodex、Claude Code、MCP Serverで同じ頻度や深刻度が発生すると示すものではありません。ただし、長時間化で失敗の機会が増え、単発のbenchmarkだけでは足りず、途中監視と介入が必要になるという設計上の示唆は、個人開発でも検証する価値があります。