長時間実行エージェント - エージェントが数日間動作すると何が変わるのか
(addyo.substack.com)- AIエージェントが単一のチャットセッションではなく、数日〜数週間にわたり自律実行され、複数のコンテキストウィンドウやサンドボックスをまたぎ、失敗から回復し、中断地点から再開する新たなパラダイムが登場
- 従来のエージェントは、コンテキストウィンドウの枯渇、自己評価への過信、以前の修正の再導入など、単一セッションの構造的限界に突き当たっていた
- Anthropic、Google、Cursor など主要企業は、モデルループ・実行サンドボックス・セッションログ分離のアーキテクチャへと収束しつつある
- 長時間実行エージェントの中核課題は、永続状態管理、自己検証、コンテキスト圧縮であり、これを解決する5つの設計パターンを提示
- モデル自体よりも、モデルを包む状態・セッション・構造化されたハンドオフ層が実際の生産性差を生む重要な投資領域
「長時間実行」の3つの意味
- Long-horizon reasoning: 多くの依存ステップにまたがって計画・実行する能力で、主にモデル品質の問題。METRの time horizon 指標によれば、フロンティアモデルが50%の信頼度で完了可能な作業時間は2019年以降およそ7か月ごとに2倍で増加しており、この傾向が続けば2028年には日単位、2034年には年単位の作業完了が可能
- Long-running execution: エージェントプロセスが数時間〜数日動作し、モデルが数千回呼び出されうる構造で、主に**ハーネス(harness)**設計の問題
- Persistent agency: 単一タスクを超えて、エージェントが同一性を保ちながらメモリを蓄積し、ユーザーの好みを学習する形態。Google の Memory Bank が代表例
- 実際の本番エージェントではこの3つが結びつくが、それぞれのエンジニアリング上の課題と解法は異なる
長時間実行エージェントが重要な理由
- 10分実行のエージェントは質問応答や小規模なバグ修正レベルだが、10時間実行エージェントは機能全体の開発、6四半期分たまったマイグレーションの完了、ジュニアアナリスト級のリサーチ実行が可能
- Anthropic の Claude Sonnet 発表では、社内テスト基準で30時間以上の自律コーディング事例が公開され、1回の実行で11,000行規模の Slack 風アプリを生成
- Project Vend では Claude インスタンスが1か月間、実際のオフィス向け自動販売機ビジネスを運営し、在庫管理、価格設定、サプライヤーとのやり取りを実施。第1段階では有意な失敗事例が得られ、第2段階で大きく改善
- 重要なのは収益性ではなく、エージェントがターン単位ではなく週単位で同一性を維持するときに生じる一貫性の問題を観察すること
すべての長時間実行エージェントがぶつかる3つの壁
- 有限のコンテキスト: 1Mトークンのウィンドウでもいずれ尽き、ウィンドウが埋まる前にすでに context rot（モデル性能の漸進的低下）が発生。24時間実行は現状どのコンテキストウィンドウのロードマップにも収まらない
- 永続状態の欠如: 新しいセッションは白紙状態から始まる。Anthropic はこれを「交代勤務のエンジニアが前の勤務で何が起きたかまったく知らずに出勤するようなもの」と例えている
- 自己検証の欠如: モデルが自分の作業を評価すると、一貫して肯定バイアスが生じる。「完了したか？」という問いに実態以上に「はい」と答えやすく、別個の検証シグナルがないと30%完成の状態でも完全な確信をもって成果物を提出してしまう
Ralphループ: 実務者向け長時間実行エージェントのシンプルな実装
- Ralphループ（Ralph Wiggum 手法）は、Geoffrey Huntley と Ryan Carson が広めた実務者向け長時間実行エージェントのパターンで、リファレンス実装はbashスクリプト1本
- 動作手順: 未完了タスクの選択(
prd.json) → タスク・コンテキスト・メモでプロンプトを構成 → エージェント呼び出し → テスト実行 → 結果をprogress.txtに追記 → タスクリスト更新 → 繰り返し - 中核原理: エージェント自体は健忘でも、ファイルシステムは記憶を保持する。
prd.jsonが計画、progress.txtがラボノート、AGENTS.mdがローリングルールブックの役割を担う - Ryan Carson の Compound Product は、分析ループ（日次レポート読解）→ 計画ループ（PRD生成）→ 実行ループ（コード作成）という形で複数ループを連結しており、これは Anthropic が独自に到達した planner-generator-evaluator 三層構造のオープンソース版
- bash スクリプトと JSON ファイルだけで、一晩動く長時間実行エージェントを構築できる。Google と Anthropic が製品化したのは、このパターンを回復可能で、安全で、観測可能にする作業
Anthropic: ハーネスから Brain/Hands/Session 分離へ
- 第1のアプローチ（ハーネス構造）: 自律フルスタック開発のための2エージェントハーネス。Initializerエージェントがプロジェクト初期環境を構成し、プロンプトを
feature-list.jsonに展開し、ブートスクリプト(init.sh)を作成。Codingエージェントが繰り返し起動して機能単位で進行し、テストを実行し、claude-progress.txtを記録し、コミットを行う- テストラチェット（test ratchet）ルール: 「テストの削除や修正は許可されない」— エージェントが失敗するテストを削除して通したことにする一般的な失敗を防ぐ
- InfoQ 拡張版では planner, generator, evaluator の三層構造へ発展。生成と評価を分けることが重要な理由は、モデルが自分の作業を甘く評価しすぎるため
- 第2のアプローチ（Brain/Hands/Session 分離）: Claude Managed Agents（2026年4月上旬リリース）のアーキテクチャ
- Brain: モデルとハーネスループ
- Hands: ツールが実際に実行されるサンドボックス化された一時実行環境
- Session: あらゆる思考、ツール呼び出し、観察の追記専用(append-only)イベントログ
- Anthropic の中核的なフレーミングは、「ハーネスのすべてのコンポーネントは、モデル自身にはできないことに関する仮定をエンコードしている」というもの。結合していると仮定が陳腐化した際にシステム全体を変えねばならず、分離すればハーネスはステートレスになり、サンドボックスは cattle（使い捨て資源）として扱える
- 新しいコンテナが
wake(sessionId)を呼び出してログから状態を再構築可能。time-to-first-token が p50 で約60%、p95 で90%以上減少 — サンドボックス準備前に推論を開始できるようになった結果 - セッション-イベント-ログという概念が最も過小評価されている部分。これこそが長時間実行エージェントを回復可能にする中核。これがなければコンテナ障害がそのままセッション障害になる
- 科学計算向けスタック:
CLAUDE.md（エージェントが学習しながら編集する生きた計画）、CHANGELOG.md（移植可能なラボノート）、tmux+SLURM+git（実行・調整レイヤー）、Ralphループ（完了主張時の再確認）- 代表例: Claude Opus が数日かけて構築したBoltzmann ソルバーが、参照実装 CLASS と1%未満の誤差を達成。研究者の数か月〜数年分の作業を圧縮
Cursor: Planner, Worker, Judge 構造
- Cursor の長時間自律コーディング拡張では3回の設計反復があった
- 第1段階（フラット調整）: 対等なエージェントたちがロックを使って共有ファイルに書き込む → ボトルネック発生、エージェントがリスク回避的になり、churning（繰り返すだけでコミットしない状態）が発生
- 第2段階（楽観的同時実行制御）: ボトルネックは解消したが、調整問題は未解決
- 第3段階（現在の本番）: Planner（コードベース探索・タスク生成、下位プランナーを再帰的に起動可能）、Worker（相互調整なしで独立作業に集中）、Judge（反復完了判定・再起動判断）
- 中核発見: 「システム挙動の驚くほど多くの部分が、ハーネスやモデルよりもプロンプトに左右される」
- モデル-役割マッチングも設計面の一部: GPT モデルは長時間の自律作業で Opus より優秀。Opus は早期停止や近道選択の傾向がある。同じタスクでも、役割・モデルが異なる
- Composer 2（独自のフロンティアコーディングモデル）とバックグラウンドクラウドエージェント: 長時間タスクはローカルではなく Anysphere のクラウドインフラで実行。8時間のリファクタリングやコードベース全体のマイグレーションがノートPCを閉じても継続
- ローカルで開始後、30分以上かかると判断されるとクラウドへ切り替えられ、その後はモバイルから再接続可能
- 各エージェントは分離された git worktree 上で実行され、PR 経由でマージ
- 最終構造は Anthropic と類似: 役割分離、セッション永続化、worker の横に judge を配置し、長時間タスクはクラウドサンドボックスで git ベースに調整
Google: Agent Platform の長時間実行エージェント
- Cloud Next '26 で Vertex AI を Gemini Enterprise Agent Platform に統合し、長時間実行エージェントを SLA 明記の正式製品へ転換
- Agent Runtime: 「数日間の自律実行」をサポートし、サブ秒コールドスタート、オンデマンドのサンドボックスプロビジョニングを提供。例示ユースケースは、1週間かかる営業プロスペクティングシーケンス
- Agent Sessions: 会話およびイベント履歴を永続化。カスタムセッション ID を CRM や DB レコードに対応付ければ、エージェント状態を業務状態と一緒に保存可能
- Agent Memory Bank: Next '26 時点で GA（一般提供）となった長期メモリ層。セッションからメモリをキュレーションし、ユーザー ID 単位でスコープし、検索 API を提供。Payhawk の事例では、Memory Bank ベースのエージェントが経費申請時間を50%以上短縮
- Agent Sandbox（強化されたコード実行）、Agent-to-Agent Orchestration、Agent Registry、Agent Identity、Agent Gateway、Agent Observability、Agent Simulation など、本番運用に必要なほぼすべての関心事をカバー。エンタープライズに必要な暗号化ID・監査ログも含む
- アーキテクチャ的には Anthropic の brain/hands/session 分離と同じ構造をプラットフォーム規模で製品化し、ADK（コードファースト開発キット）と Agent Studio（ビジュアルツール）を同梱。3年前なら自前構築が必要だったものが、今や**「どのバージョンの brain/hands/session 分離を借りるか」**の選択問題になっている
本番の長時間実行エージェントのための5つのパターン
- Checkpoint-and-resume: 最も一般的な複数日障害はコンテキスト喪失。200件の文書を処理した後に201件目でエラーが起きた場合、チェックポイントがなければ最初からやり直し。エージェントを長時間動くサーバープロセスのように扱い、中間状態をディスク保存し、N作業単位ごとにチェックポイントし、障害回復する。重要なのは適切なチェックポイント粒度の決定（毎ステップでも最後だけでもない）
- Delegated approval(human-in-the-loop): 従来実装は状態を JSON シリアライズ → Webhook → 応答待ちだが、状態が stale になり通知が埋もれる問題が起きる。長時間実行ランタイムでは、エージェントは推論チェーン、作業メモリ、ツール履歴、保留アクション全体を維持したまま一時停止できる。人間のレビュー中は計算消費ゼロ、サブ秒レイテンシで再開可能。Google の Mission Control がそのための受信箱の役割を果たす
- Memory-layered context: 7日間動くエージェントにはセッション状態以上が必要。Memory Bank（長期キュレーションメモリ）+ Memory Profiles（低レイテンシ参照）。本番の失敗モードはmemory drift — エージェントが非構造的な相互作用から手続き的近道を学び、それを広範囲に適用してしまう。メモリをマイクロサービスのようにガバナンスする必要がある。Agent Identity（読み書き権限）、Agent Registry（エージェント版追跡）、Agent Gateway（ポリシー適用）
- Ambient processing: 人間と対話せず、Pub/Sub ストリームや BigQuery テーブル上のイベントに反応するエージェント（コンテンツモデレーション、異常検知、受信箱分類）。ポリシーをエージェントにハードコードせずGateway に定義すれば、再デプロイなしで数百のエージェントにポリシー変更を反映できる
- Fleet orchestration: 実システムでは単一エージェントではなく、コーディネーターが専門家（Lead Researcher Agent、Scoring Agent、Outreach Agent）にサブタスクを委任する。各専門家は固有の Identity（Outreach Agent は Scoring 用の金融データにアクセス不可）、固有ポリシー、固有 Registry 項目を持つ。ADK がグラフベースワークフローで宣言的に処理
- パターンは組み合わせ可能。コンプライアンスシステムの例: 文書処理にチェックポイント、レビューゲートに委任承認、セッション間知識にメモリレイヤリング、専門家調整にフリートオーケストレーション
実際の構築方法
- 自分のリポジトリで長時間コーディング作業をしたい開発者: Claude Code、Antigravity、Cursor、Codex などを活用。
AGENTS.mdをパイロット用チェックリストのように管理（短く、実際の失敗経験から得た項目だけ）。型チェック・lint フックを追加し、開始前に計画ファイルを作成し、エージェントが完了を主張したらRalphループで再確認。複数時間・夜間の作業はworktreeで実行してノートPCを閉じても維持し、意味のある作業単位ごとにコミット。大半の人にとって最もレバレッジの高い道 - ホスティング型エージェント製品の構築: ランタイムを自前構築せず、マネージドを選ぶ。現時点で実質的な選択肢は3つ: Google Agent Platform（Agent Engine + Memory Bank + Sessions）、Claude Managed Agents、または ADK・Claude Agent SDK・Codex SDK 上に自社ホスティング。マネージドは brain/hands/session 分離、可観測性、ID、監査追跡を標準提供。自社ホスティングは制御権と特殊モデル利用が可能
- 自律・運用業務（監視、リサーチ、運用）: Memory Bank スタイルの永続性が必要。ADK + Memory Bank + Cloud Run + Cloud Scheduler が「N時間ごとにエージェントを実行し、状態を蓄積し、閾値通知する」ための最も整ったスタック
ルートに関係なく重要な実践事項
- エージェント開始前に完了条件を明文化: 長時間実行で最もレバレッジが高い。外部ファイルに明示的かつテスト可能な完了基準を書き、実行中にエージェントが「完了」の意味を再定義するのを防ぐ
- 評価者と生成者を分離: 自己採点は中核的な失敗モード。planner/worker/judge パイプラインや generator/evaluator の組は、スタイルではなく実際のアーキテクチャパターン。同じモデルでも役割・プロンプトを分ける
- プロンプトではなくセッションログに投資: 追記専用イベントログによって、エージェントは回復・デバッグ・監査可能になる。過去24時間のエージェント活動を永続ストレージから再構成できないなら、それは長時間実行のシェルスクリプトで LLM を呼んでいるだけ
- 圧縮とコンテキストリセットを第一級市民として扱う: Anthropic では非常に長い作業で要約ベース圧縮だけでは不十分で、ハーネスがセッションを完全に分解し、構造化されたハンドオフファイルから再構築する全面的なコンテキストリセットが必要だった。これは本質的に、新しいエンジニアをオンボーディングする方法と同じ
現在の現実的な限界
- コスト: フロンティアモデルで24時間動かすと費用は大きい。予算、サーキットブレーカー、ツール支出のハードキャップなしでは、半日で1週間分の API 予算を使い切る可能性がある
- セキュリティ: API キー、クラウドアクセス、シェルコマンド実行権限を持つ長時間実行エージェントは、チャットセッションよりはるかに広い攻撃面を持つ。brain/hands 分離パターンが重要で、モデル生成コードが走るサンドボックスでは認証情報へアクセス不可の状態を維持する必要がある
- Alignment drift: 複数のコンテキストウィンドウをまたぐうちに、エージェントが漂流する。元の目標が要約され、再要約される中で忠実度が下がる。これを防ぐためにフックや judge が存在しており、「エージェントが依頼されていない作業を行う」最も一般的な原因でもある
- 検証: 24時間の自律活動監査は現実には人間時間の問題。可観測性と構造化された成果物（PR、コミット、ブリーフィング、テスト実行）が、それを tractable にする方法
- 人間の役割: エージェントが1日動けるほどタスクを精密に定義することは、自分で作業するより難しい。価値が高まっている技能はコードを書くことではなく、自律実行者との接触に耐える仕様を書くこと
今後の方向性
- Google、Anthropic、Cursor は同じ構造へ収束している: モデルループ・実行サンドボックス・セッションログ分離、計画・生成・評価の分離、圧縮・フック・コンテキストリセットの内蔵、メモリのマネージドサービス化
- 違いは表層的。Google Agent Platform はエンタープライズ向けスタック（ID・監査追跡内蔵）、Claude Managed Agents は「Anthropic ハーネスのホスティング版」、Cursor バックグラウンドエージェントは「IDE からクラウドへ切り出した長時間コーディング」
- 今後1年のより難しい問題は個々のレイヤーではなく、その上の調整。共有コードベースで多数の長時間エージェントを運用すること、自分のトレースを読み自前のハーネスをパッチするエージェント、タスクに応じてツールとコンテキストを JIT(just-in-time) に組み立てるハーネス
- モデルは依然として重要だが、チャットウィンドウと一晩中動くエージェントの間のギャップの大半は状態、セッション、構造化されたハンドオフにあり、いま学習時間を投資すべき領域もそこにある
1件のコメント
私はこの問題を解決しようとして
hermesを使い始めたのですが、悪くない気がしますね（笑）