エージェントを丸一日走らせるために — 長時間稼働コーディングエージェントの運用基盤

どんな問題か

コーディングエージェントの使い方は長らく短い往復だった。この関数を直して、このテストを見て、数分おきに人がキーボードを握っては離す。ところが OpenAI の Codex は、空のリポジトリからデザインツールを作る実験で約25時間、人の介入なしに走り続けた。1,300万トークンを燃やし、3万行を生んだ。エージェントを分単位ではなく時間・一日単位で放てるようになったのだ。問題は、そこまで長く放った瞬間、短いタスクでは見えなかったものが一斉に噴き出すことにある。コンテキストウィンドウが何度も満杯になって圧縮され、その過程でエージェントが最初の仕様からじわじわドリフトする。トークンコストは歯止めなく線形に積み上がり、ある実務者は長時間モードが「とんでもない量のトークンを消費する」と警告する。5時間上限のプランは大きな作業が終わる前に切れる。何より、深夜3時に走っていた25時間ランが静かに崩れても朝まで誰も気づかない。エージェントを起動はできるのに、それが本当に走っているかを覗き、コストが漏れたら止め、ドリフトしたら捕まえ、詰まったら人を呼ぶ — その運用層が丸ごと空いている。

なぜ今か

長時間稼働がラボのデモから実際のワークフローへ移る兆しがいくつも同時に立った。OpenAI は GPT-5.1-Codex-Max でコンパクションを出した。コンテキストが上限に近づくと履歴を刈り込みつつ核心の状態を保った新しいウィンドウを作り、実行を続ける方式で、内部評価では24時間超を単一タスクで自律走行したと報告する。Codex CLI は v0.128.0+ で /goal コマンドを追加し、中断・セッション切断・トークン上限を越えて生き残る持続的目標を扱う。一度に一つの指示ではなく、検証可能な停止条件を持つ目標を与え、エージェントが複数ターンにわたって追求する。モデル側の効率も追いついた。同じ推論強度で思考トークンを30%少なく使いながら高い精度を出すという報告は、一日がかりの自律を経済的に成り立たせる条件だ。つまりモデルとランタイムはすでに長時間稼働へ全力で動いている。なのに複数のランを同時に管制し、コストとドリフトをリアルタイムで見て、詰まった地点で人を呼ぶ計器盤は、各チームが Markdown ファイルとシェルスクリプトで毎回手作りしている。標準化された運用ツールがない、典型的な空白だ。

どう作るか

入り口は大きく三つ。一つ、チェックポイントと復旧の層。25時間の実験でエージェントを御したのは、リポジトリに刻まれた仕様・計画・状態の Markdown ファイルだった。この外部化された状態のパターンを手書きファイルから製品へ引き上げる。ランをスナップショットで取り、崩れたら最後に検証を通した地点からよみがえらせ、どの決定でどこまで進んだかの監査証跡を自動で残す。二つ、ドリフトとコストの管制ダッシュボード。複数のエージェントランを一画面で見る。今どのマイルストーンにいて、トークンをどれだけ燃やし、仕様からどれだけ外れたか（変えるなと言ったファイルに触れたか）、どこで検証が壊れたか。予算上限を掛け、深夜にトークンが暴走したら自動で止める。三つ、人の介入地点の設計。エージェントが判断の分かれ目で止まって人を呼び、答えを得たらその場で続きを走らせる流れだ。検証可能な停止条件と「変えるな」の制約を一か所で管理するポリシー層がここに付く。収益はチーム単位のサブスクで掛ける — 同時ランの数、保持するチェックポイントの容量、管制するエージェントの台数。最初からすべてのモデル・ランタイムを狙わず、Codex /goal のように長時間稼働を先に押す一つのランタイムに深く付いて、その生態系の管制塔になるのが現実的だ。

flowchart LR
  A[長時間稼働エージェント] -->|進捗状態| B[チェックポイント層]
  A -->|トークン・ドリフト指標| C[管制ダッシュボード]
  C -->|予算超過| D[自動停止]
  C -->|判断が必要| E[人の介入]
  E -->|回答| A
  B -->|崩れたら復旧| A

成功の条件

この市場は「どれだけ速く信頼を得るか」で分かれる。第一に、運用層そのものが、それが管制するエージェントより安定していなければならない。管制塔が揺れれば、その下のすべてのランが一緒に揺れる。チェックポイント復旧が一度でも狂ってまともな作業を飛ばせば、導入先はすぐに背を向ける。第二に、コストガードレールは事後の請求書ではなくリアルタイムの遮断でなければならない。「昨日これだけトークンを使った」ではもう遅く、上限を越える直前に止めることに価値がある。第三に、ドリフト検知こそデータのロックインの核だ。どの信号が本当のドリフトにつながるか（どのファイル編集、どの検証失敗パターン）は、ランが積み上がるほど精度が上がり、それが後発が追いつけない差になる。最初からすべてのランタイムを支えようとして、どれにも深く付けないのが最もよくある失敗だ。