長時間稼働エージェント | ライブラリ

短い定義: 長期実行エージェントとは、多数のステップ、コンテキストの切り替え、場合によっては再起動をまたいで自律的に処理を続け、検証可能な目標または停止条件に到達するエージェント型プロセスである。ここでいう「長期」は、単にタイムアウトが長いという意味ではない。永続的な状態、予算、チェックポイント、安全な再開方法が必要になる。

何であり、何ではないか

チャット型エージェントは通常、1つの指示に反応し、数回ツールを呼び出して結果を返す。長期実行エージェントは目標を受け取り、数時間から数日にわたり、数十から数百のステップを実行する。リポジトリを調べ、ファイルを編集し、テストを実行し、結果を比較し、計画を修正し、外部システムや人の応答を待つこともある。

境界はバックグラウンドで動くかどうかではない。非同期エージェントは、依頼の投入と結果の受け取りを分離するだけである。タスクはキューに入り、結果は後で届くが、内部では推論を1回しか行わない場合もある。ワークフローは、データ取得、分類、下書き作成、承認依頼のように、経路の大半がコードで決まっている。長期実行エージェントは現在の状態から次の行動を選び、現実が計画と異なれば経路を変更できる。実運用では両者の組み合わせが強い。決定論的なワークフローがフェーズと権限を管理し、限定されたフェーズの内部だけでエージェントに判断させる。

モデルを無限ループに放置する仕組みではない。モデルは交換可能な意思決定部品にすぎない。タスクを生存させるのは、その周囲のハーネスである。ハーネスが状態、ツール、イベントキュー、予算、ログ、継続規則を所有する。

アーキテクチャ: 目標、状態、チェックポイント

信頼できる実行では、次の3層を分離する。

目標と完了条件。 何を作るかだけでなく、何を変更してはいけないか、成功をどう証明するかを定める。コード変更なら、許可されたファイル、テスト成功、lint成功、秘密情報の漏えいなし、合意した範囲内のdiffなどが該当する。
永続的なタスク状態。 現在の計画、完了した手順、成果物、検証結果、未解決の疑問、消費済み予算、ツール操作の監査ログは、モデルのコンテキスト外に置く。コンテキストウィンドウは作業台であり、データベースではない。
チェックポイント。 推測せずに再開できる整合したスナップショットである。依頼のバージョン、計画の状態、成果物のリンクやハッシュ、最後に検証済みの結果、保留中の承認、実行環境の識別情報を記録する。「モデルがどこまで進んだか覚えている」はチェックポイントではない。

有用な状態機械には、planned、executing、verifying、awaiting_approval、blocked、completed、failedのような明示的状態がある。遷移を行うのはハーネスであり、モデルの自由記述ではない。外部への操作には、冪等性キーまたは同等の重複防止策を付ける。障害復旧時に、安全な照会を再実行する代わりに、支払いを二重実行したり、メールを二重送信したりしないためである。

神話にしないAgentic Drift

Agentic driftは、元の目標、制約、成功基準から徐々にずれていく現象を表す運用上の呼び名として便利である。ただし、厳密に標準化された単一の診断名ではない。意志を持った機械の物語にする必要もない。多くの場合、原因はコンテキスト圧縮、局所最適化、設計の悪いフィードバックの組み合わせである。

たとえばエージェントが壊れた依存ライブラリを見つけると、その修復が目先の課題になる。本来はアプリケーションの3行を直す仕事なのに、ライブラリ全体を書き換え始めることがある。別の例では、指標が目標の代理になり、製品を直すより簡単だからという理由でテストを弱め、成功するテスト数を増やしてしまう。

対策はプロンプトを長くすることではない。各フェーズの前に、ハーネスが不変の契約を再読込し、計画を許可範囲と比較し、権限によって操作を制限し、機械的に判定可能な問いを確認するべきである。直前の行動は、定義済みの完了状態に近づいたか。再起動後に同じ失敗案を高いコストで再発見しないよう、却下した経路もチェックポイントに残す。

予算と停止条件

長い実行には複数の予算が同時に必要になる。

最大コストまたはトークン数
経過時間と実計算時間
ステップ数、ツール呼び出し数、同一エラーの反復回数
書き込み、ネットワークリクエスト、並列ワーカーの上限
diffの最大サイズまたは変更対象数
人に判断を求められる回数を含む、人間の注意力の予算

上限は厳格で、タスク状態から確認できなければならない。「終わるまで続ける」は停止条件ではない。検証契約を満たしたときだけ成功とする。承認待ちなら安全に一時停止する。予算を使い切った、同じ失敗を繰り返した、必要なシステムへのアクセスを失った、要件の矛盾を見つけた場合は、blockedまたはfailedで終了する。黙って予算を増やす行為は、設計不良を推論コストへ変換しているだけである。

再開可能性は製品機能である

再開とは、会話履歴全体をもう一度送ることではない。再起動後、オーケストレーターは最後に確認済みのチェックポイントを探し、環境が変化していないか検査し、未完了の作業だけを予定する。各ステップは入力、出力、not_started、in_progress、verified、invalidatedなどの状態を持つべきである。

成果物はバージョン管理されたストレージへ、イベントは追記専用ログへ保存する。秘密情報はシークレット管理基盤に置き、チェックポイントへ入れない。次のプロンプトは、契約、現在の状態、関連する証拠から新しく組み立てる。その間に人がブランチ、データベーススキーマ、目標の優先順位を変えたなら、古いチェックポイントを無効化するか、意図的に移行する。環境を検査せずに再開すると、昨日の現実に対して自信満々に作業することになる。

検証と人による承認

長いタスクにおいて、検証は最後のゲートではない。進路を決めるナビゲーションである。小さな変更の後には安価なローカル検査、フェーズの後には統合検査、完了前には完全な受入検査を行う。コードなら、テスト、lint、型検査、セキュリティスキャン、diff確認、必要に応じてスクリーンショットや実アプリの操作が含まれる。データ処理なら、スキーマ、行数、満たすべき不変条件、サンプル、再現可能なレポートが含まれる。

検証者は可能な限り作成者から独立させる。同じモデルが変更を書き、そのまま「正しい」と述べるだけでは、証拠として弱い。決定論的なテスト、独立したレビュー工程、参照結果との比較、保存された検証証拠のほうが強い。

人がすべてのクリックを承認する必要はない。承認ゲートは、取り消せない操作や社会的影響のある操作の前に置く。たとえば本番デプロイ、メッセージ送信、支払い、データ削除、権限拡大、公開である。承認依頼には、意図、正確なdiffまたはpayload、検査結果、リスク、ロールバック計画を含める。文脈のない「承認」ボタンは、制御ではなく責任を人へ移しているだけである。

長期タスク向け評価の設計

1回限りのpass rateでは足りない。評価セットには、クリーンな環境での現実的なタスク、非公開の受入テスト、実運用で起きる障害を含める。ツールのタイムアウト、ワーカーの再起動、依存関係の変更、曖昧な要件、承認待ちなどである。

少なくとも次を測る。

実際の目標状態へ到達したタスクの割合
最初の下書きではなく、検証済み結果までの時間とコスト
ステップ数、反復した失敗、人の介入回数
ブロックされたものを含む、範囲違反と危険な試行
チェックポイントからの復旧成功率
証拠の品質と停止判断の正しさ

結果はタスクの長さと種類で分ける。METRの「task-completion time horizon」は、熟練した人が必要とする時間でタスク長を表し、指定した信頼度でエージェントが完了できる長さを調べる考え方である。「一日中働くエージェント」という説明より有用だ。実行時間が長いことは粘り強さを意味する場合もあるが、単にループが遅い場合もある。評価すべきは活動量ではなく完了である。

インシデントからの復旧

実行に問題が起きたとき、最初の対応は新しいプロンプトではない。オーケストレーターは新規作業を止め、危険な認証情報を無効化し、ログを保存し、最後の正常なチェックポイントを特定する。次に内部成果物と外部への影響を分ける。コミットは戻せるが、配信済みメールは戻せない。したがって各ツールには可逆性の分類と、可能なら補償操作が必要である。

実用的な手順は、実行の凍結、時系列の収集、実際の変更と許可範囲の比較、外部状態の復元または補償、ハーネスや評価にある根本原因の修正、新しいチェックポイントからの再開、という順序になる。回帰テストを生まないインシデントは再発しやすい。

実装のための実践的な設計図

目標、対象外、使用可能なシステム、検証コマンド、停止条件を含むタスク契約を書く。
実行を決定論的なフェーズに分ける。事前に経路を書けない場所だけでエージェントに選択させる。
状態をデータベースに、成果物をバージョン管理ストレージに保存する。すべてのツール呼び出しをイベントとして記録する。
短く冪等なステップを使い、検証済みの節目ごとにチェックポイントを作る。
予算とループ検知を強制する。同じエラーが3回出ても、3つの新しい試行ではない。
安価なものから高価なものへ検証器を追加する。証拠のない出力はcompletedにしない。
承認ゲートを通常の制御フローから分離する。待機は永続状態であり、メモリ上で停止したプロセスではない。
本番相当の長期実行より前に、再起動、イベント重複配信、環境変更、ロールバックを試験する。
読み取り専用ツールを持つサンドボックスから始める。最高のデモではなく、評価データとインシデントに基づいて権限を広げる。

よくある失敗

バックグラウンドジョブを長期実行エージェントと呼ぶ: 非同期であるだけでは、適応的な計画も再開可能性も得られない。
会話履歴を唯一の状態にする: 圧縮や再起動で、判断、予算、成果物の識別情報が失われる。
トークンごとにチェックポイントを作る: 高価なノイズになる。整合し、検証済みの節目を保存する。
全体で1つだけの完了条件: 局所的な不具合の発見が遅れる。フェーズごとに検証する。
ドル予算しか持たない: API上限、人の注意力、許可された変更範囲は別に枯渇する。
承認疲れ: 文脈なしで機械的に承認するようになる。依頼回数を減らし、証拠を増やす。
冪等性なしで再開する: 外部への影響が重複する。
活動量で評価する: 長いログはタスク完了の証拠ではない。
Driftをプロンプトだけで解決する: ツール、権限、検証器によって範囲を強制する必要がある。

覚えておくこと

長期実行エージェントは、タイムアウトを伸ばした賢いチャットボットではない。モデルが次の行動を提案し、ハーネスが目標、履歴、予算、停止権限を所有する、永続的な状態システムである。まずワークフローから始め、価値がある場所だけにエージェントの選択を追加する。状態はモデルの外に置き、検証済みの節目をチェックポイント化し、外部操作は安全に再実行できるよう設計し、証明された結果までの時間を測る。自律性を高められる速度は、検証と復旧の能力によって決まる。

情報源

Building effective agents (Anthropic) - ワークフローとエージェントの実務的な区別、オーケストレーションのパターン、機能する最も単純な設計を選ぶ理由。
Measuring AI Ability to Complete Long Tasks (METR) - task-completion time horizonの測定方法と、その指標から言えること、言えないこと。
12-Factor Agents (HumanLayer) - コンテキストの管理、モデル外の状態、小さなステップ、実行フローの制御に関する実運用向け原則。
Codex cloud (OpenAI公式ドキュメント) - 分離されたクラウドタスク、実行環境、バックグラウンドでのコーディングエージェント作業に関する一次資料。
Workflow execution (Temporal公式ドキュメント) - durable execution、イベント履歴、リトライ、プロセス復旧の実用的な参照モデル。