長時間動く AI Agent には、会話画面ではなくタスクシステムが必要

Agent が「作業中」と表示していても、プロダクトが仕事を管理できているとは限りません。ツールがタイムアウトし、翌朝に担当者が戻ったとき、何を終えたのか、どこから安全に再開できるのか、誰の判断を待つのかが分からないなら、それはモデルよりタスク設計の問題です。

OpenAI の長時間 Codex 作業に関する公開実践は、準備済みの環境、具体的な依頼、明確な受け入れ条件、成果物へのフィードバックを重視します。重要なのは特定の製品ではなく、長い仕事を無限のプロンプトではなく「仕事の契約」として扱うことです。

時間ではなく、失敗したときの責任で決める

次のうち二つ以上が当てはまるなら、チャットからタスクへ移します。

• ブラウザの一回の要求を超えて待機・再開する。
• メール送信、CRM 更新、公開、決済、デプロイなど外部に作用する。
• モデル、API、計算、クレジットの予算を消費する。
• パッチ、レポート、顧客返信のように他者へ渡す成果物を作る。
• 再試行が二重送信、二重請求、上書きを起こし得る。

コンテキストエンジニアリングは正しい判断材料を与えます。タスクシステムは、途中で止まった仕事を人とソフトウェアが引き継げるようにします。

最小の状態機械

最初から大企業向けワークフローを作る必要はありません。queued、running、waiting、awaiting approval、completed、failed/cancelled の六状態で十分です。各状態には次の行動が必要です。

日本のチームでは、稟議や変更責任が曖昧なまま自動送信・自動更新を始めると、実装速度より確認コストが増えます。承認画面には「何をするか」だけでなく、対象の顧客・レコード・環境、根拠、取り消せるかを表示します。

チェックポイントと再試行

チェックポイントは「考え中」ではありません。「情報源を収集・重複排除したが、結論は未作成」「テストは通ったが PR は未作成」のように、会話を読み直さず確認できる境界です。次の操作を再実行しても同じメールや請求を繰り返さないよう、外部操作には idempotency key と予算上限、試行回数、停止条件を持たせます。

Temporal の Workflow 資料が示す durable execution の考え方は、障害を一回の失敗で終わらせず、記録された状態から回復することです。実装基盤の選択より先に、worker 再起動、API 制限、担当者不在のとき何が残るかを決めてください。

一週間の小さな検証

毎週の競合調査、問い合わせ下書き、Issue の一次分類など、一つだけ選びます。十件の実タスクで、入力不足、最後のチェックポイント、承認回数、安全な再試行、受け入れ可否、モデル・ツール・レビュー費用、停止理由を記録します。AI ROIで見るべきなのは呼び出し数ではなく、受け入れられた仕事と回復コストです。

短く可逆な要約や書き換えは今もチャットで十分です。後で結果を受け取り、別の人が信頼し、重複操作が害になる仕事から、検査可能なタスクへ移してください。