LoopXで学ぶ長時間AI Agentの状態管理：復旧・検証・引き継ぎの実践ガイド

agentを午後いっぱい動かし、調査もファイル修正も終わったとします。翌日に新しいsessionを開くと、昨日の検索をもう一度行い、完了済みの手順を未処理として扱い、最後には自信満々で「タスクは完了しました」と報告する。困るのはtokenの無駄だけではありません。どの記録が正しいのか、わからなくなることです。

この記事は、ワンクリックの自律運用を約束するものではありません。LoopXの設計を手がかりに、長いタスクを中断後に復旧でき、権限の境界で停止し、別のagentへ検証可能な形で引き継げる最小状態契約を作ります。

対象は、agent automationを自分で保守する開発者、runnerを接続する開発者、またはagentに公開処理やproduction環境の操作を任せる開発者です。ChatGPTやNotionで手作業をしており、自動化された副作用がないなら、明確なチェックリストで十分です。YAMLやclaim、leaseまで無理に導入する必要はありません。

TL;DR：長いcontextより先にcurrent truthを保存する

長時間agentのdurable stateとは、会話全体を永久保存することではありません。現在の目標、実行権限、未解決のgate、次に行うbounded todo、検証済みのevidence、停止条件をchatの外に置くことです。新しいsessionは、このcurrent truthを読むだけで次へ進めるかを判断できます。

タスク	最小構成	まだ追加しなくてよいもの
1つのsessionで完了し、外部への副作用がない	通常のtodoリスト	control planeは不要
sessionをまたぐ単一agentのタスク	goal、gate、todo、evidence、budget	claim、lease、peer routing
複数agentが同じ作業群を共有する	claimed_by、lease、capability、競合処理を追加	全員で同じMarkdownを編集するだけにしない

Contextは、その場でモデルが考えるための作業記憶です。一方、durable stateは、次の実行時点でどこまで進んでいるかを示すoperational truthです。役割は異なります。

チャット履歴やcompactionだけでは長いタスクを救えない理由

Anthropicによる長時間agent harnessの研究では、よくある2つの失敗が報告されています。agentが一度に多くを進めすぎ、context終了時に未完成の成果を残すケースと、後のsessionが一部の成果物を見て早すぎる完了判断をするケースです。この研究ではprogress fileとgit historyを使い、fresh sessionが差分から作業を引き継げるようにしています。また、compactionだけでは不十分だと明記しています。

次の4種類のデータは、混同されがちです。

データ	答える問い	向いている用途
Transcript	直前に何を話し、何をしたか	デバッグ、ツール呼び出しの追跡
Summary	この会話は何についてだったか	文脈の素早い復元
Active state	今何が真実で、誰に何の権限があるか	復旧と意思決定
Event/evidence ledger	どの変更が起き、どう検証されたか	監査、引き継ぎ、ロールバック

要約では詳細が抜けることがあり、transcriptには後から撤回された計画も残ります。タスクの復旧に必要なのはactive stateです。「PRを作成する予定」は会話の内容にすぎません。PR URL、commit SHA、CI結果が確認可能なevidenceです。

LoopXとは何か、何ではないのか

LoopXとは： 公式はLoopXをprovider-neutralでlocal-firstな状態カーネル兼control planeと説明しています。objective、gate、todo、evidence、quota、handoffをコンパクトな層に置き、Codex、Claude Code、Cursor、shell agent、独自runtimeが各ターンの処理を実行します。

公式READMEを再確認したところ、LoopXは新しいモデルでも、agent runtimeを置き換えるhosted serviceでもありません。また、autonomous production controllerではないと明記されています。危険な権限、公開処理、production write、最終的なownershipは人間が持つべきだとされています。

名前にも注意が必要です。本記事で扱うのはGitHub上のオープンソースプロジェクトhuangruiteng/loopxであり、似た名前の別企業や製品ではありません。

現時点では、LoopXを検査可能なlocal substrateとして捉えるのが妥当です。公式READMEには、elapsed lifetimeが200時間を超えるOpenVikingへの公開コントリビューション履歴と、一部を非公開にしたowner-run Auto ML showcaseが掲載されています。公式は、これが200時間連続のモデル実行、production autonomy、独立した再現結果を意味しないと明記しています。さらに、13時間を超えるC++タスク、4日間のunattended run、7件のmerged PRという独立ユーザーの報告もありますが、あくまでユーザー自身の報告です。公開事例は存在しますが、production readinessが証明されたわけではありません。

復旧可能な最小契約を作る5つの状態オブジェクト

すぐにインストールする必要はありません。まず既存のautomationを次の最小契約で表現すると、agentの頭の中にしかない情報が見えてきます。

goal:
  objective: "完成一篇有官方來源的工具評測"
  authority: "可寫草稿，不可發布"
  state: active
gate:
  status: pending
  question: "是否接受新增付費來源？"
todo:
  id: validate-sources
  action: "逐一確認 references 可開啟"
  status: ready
evidence:
  - type: file
    value: "draft.md"
    verified_by: "frontmatter-validator"
budget:
  max_attempts: 2
  attempts_used: 0
  stop_when: "沒有新的 verified delta"

これは説明用に本記事が整理したreference implementationであり、LoopX公式の固定schemaではありません。重要なのは責任分界です。goalはownerが定義し、agentがauthorityを勝手に拡張してはいけません。gateは具体的に回答できる問いにします。todoは1回につき1つの検証可能な操作を記述します。evidenceはファイル、テスト、外部システムからのreadbackで確認できる必要があります。budgetは停止のタイミングを決めます。

LoopXのstate interaction modelでは、actorと書き込み境界をさらに分けています。Dashboardはprojectionにすぎず、元の状態と乖離する別の正解になってはいけません。これは、AI agentセキュリティフレームワークで扱った問題と共通します。観測できることと実行権限があることは別です。画面にボタンが見えても、agentが押してよいとは限りません。

15分で最小状態契約を作る

この15分に含まれるのは、現状の棚卸しと契約の記述だけです。runnerの接続、concurrencyへの対応、障害訓練は含みません。Bounded transitionの考え方は単純です。1回の処理で明確な入力を1つ受け、範囲の限られた操作を1つ完了し、結果を検証してから状態を返します。「完了するまで調査を続ける」をloop conditionにしてはいけません。

current truthを棚卸しする： 現在の目標、権限、blocker、次の手順、既存の成果を列挙します。唯一の情報源を示せない項目が、最初の欠落です。
1回の処理を1操作まで小さくする： たとえば「情報源を収集する」と「情報源を検証する」を別のtodoにします。同じ処理で原稿作成、公開、通知まで追加してはいけません。
evidenceを定義する： 収集完了時にはURLリスト、検証完了時にはHTTP結果または公式ページの内容を残します。「確認済み」という記録だけでは不十分です。
再起動時の読み取り順を固定する： registry、active goal、pending gate、next todo、recent evidenceの順に読みます。Transcriptは、本当にデバッグが必要なときだけ確認します。
deltaがなければ停止する： LoopXのquotaドキュメントでは、quiet skipとpreflight failureをslotを消費すべきでない状況として扱っています。新しい権限やevidenceがなければ、「進捗報告」を生成するより静かに待つほうが確実です。

コンテンツ調査のautomationなら、1回目のcollectでは候補ソースだけを作り、2回目のvalidateで公式情報か、情報が新しいかを確認し、3回目のhandoffで利用可能なclaimsを書き込みます。各処理は個別に失敗、再実行、検証できます。手書きのYAMLはフローの形を明確にしますが、atomic write、schema validation、claim conflict protectionを自動で提供するわけではありません。これらは別途実装するか、適切なツールに任せる必要があります。

単一agentと複数agentはどこで分かれるか

単一agentでは、restart identity、gate、evidence、budgetから始めます。これだけでも「再起動後にどこから続けるか不明」という混乱の多くを減らせます。この段階でleaseやcapability routingを加えても、保守負担が増えるだけです。

2つのagentが同じtodoを取得する可能性が出たら、調整の層を追加します。

claim:
  todo_id: validate-sources
  claimed_by: reviewer-02
  lease_expires_at: "2026-08-12T15:00:00+08:00"
  capability: source-verification
  handoff_when: "all official links return a valid page"

LoopX todo contractはownership、claim、引き継ぎを明示的な状態として扱います。それでも、自分のストレージとrunnerは実測が必要です。2つのprocessが同時にclaimしたとき、成功するのは1つだけでしょうか。期限切れleaseを回収したあと、古いworkerから遅れて届いたwritebackが新しい結果を上書きしないでしょうか。インターフェースが整って見えるだけで、公式が明記していないproduction guaranteeを補ってはいけません。

移行前に、少なくとも5つの実測結果を記録してください。既存のtodoとevidenceをどう取り込むか、2つのprocessによるclaimが相互排他的か、lease期限切れ後の遅延writebackをどう処理するか、アップグレードにstate migrationが必要か、利用をやめた後に人間が読めるデータをexportできるか、の5点です。公式資料で確認できない項目には「要実測」と記し、期待する動作を保証として扱わないでください。

4つのfailure drillで、動くだけでなく復旧できることを確かめる

正常系が通るだけでは不十分です。障害が起きても正しく動くと確認できて、初めて安心して運用できます。

Drill A：処理の途中でprocessを終了する

外部への副作用が発生する前にrunnerを終了し、古いtranscriptを渡さず新しいsessionを起動します。durable stateだけからcurrent goal、未完了todo、最後のverified evidenceを見つけ、完了済みの副作用を繰り返さないことを確認します。

Drill B：owner gateをpendingのままにする

agentが越えてはいけない公開gateを明示します。期待する結果はquiet no-op、または原稿の整理を続けるなど事前承認済みのfallback laneだけです。勝手に公開してはいけません。Lifetime goalは意図が継続することを示しますが、無制限の権限ではありません。

Drill C：2つのpeerに同じtodoをclaimさせる

claimを同時に送り、有効なownerが1つだけになることを確認します。次にlease期限切れを再現し、新しいownerが引き継いだあと、古いownerのwritebackが拒否されるかを確認します。このテストにより、「全員で同じJSONファイルを書く」方式が本当に安全か、すぐにわかります。

Drill D：古いworkerに古いschemaを書き戻させる

まず旧版workerに状態を読ませ、schemaを更新してから、旧版workerのwritebackを許可します。システムはschema versionを確認し、互換性のない更新を拒否して現在の状態を保持し、migrationまたは手動介入の経路を残す必要があります。これができなければ、rolling updateを安全だと仮定せず、アップグレード中はworkerを停止します。

4つのdrillには共通の受け入れ基準を使えます。verified evidenceが増え、重複したside effectがゼロで、valid transitionだけがbudget spendに記録されることです。これは本記事が提案するテスト方法であり、LoopXがrolling updateの安全性を保証しているという意味ではありません。公式の性能データでもありません。

データと権限の境界：commitしてはいけないもの

状態は永続化する必要がありますが、すべてをGitに入れてよいわけではありません。LoopXのpublic/private boundaryでは、credentials、private traces、raw operator artifacts、active private stateを公開artifactの外に置くよう求めています。

データ	推奨する保存先	理由
Current truth	管理されたstate store	一貫した書き込みと明確なownerが必要
Transition/event ledger	Append-only logまたはgit history	監査とロールバックに便利
Debug transcript	Private trace store	長くなりやすく、機密入力を含む可能性がある
複数プロジェクトを横断する検索データ	Database/index	絞り込みと集計がしやすい
Credentials	Secret managerまたは保護された環境変数	モデルが自由に書き戻せる状態へ入れるべきではない

LoopXの状態関連ドキュメントを確認すると、見落としやすい別のリスクもあります。evidenceがagentの自己申告にすぎない可能性です。Anthropicのagent evalガイドは、予約の例を使い、transcript内の「予約済み」という記述と、データベースに実在するreservation outcomeを区別しています。自分のフローでは、CI、API readback、独立したevaluatorに結果を確認させましょう。実行者自身に承認させてはいけません。

LoopXを使わないほうがよい場合

判断軸	シンプルなtodoを使い続ける	LoopX型の制御層を検討する
タスクの長さ	1つのsessionで完了	sessionや日をまたぐことが多い
外部への副作用	ほとんどない	公開、支払い、production変更がある
Agent数	実行者が1つ	複数のpeerが作業を取り合う
中断コスト	再実行が安い	再実行で操作が重複する、または多くの資源を浪費する
監査要件	最終ファイルだけでよい	誰が、いつ、どのevidenceで進めたかを把握する必要がある

managed SLA、cross-region HA、完全なenterprise IAM、成熟したworkflow engineが必要なら、「control plane」という言葉だけでLoopXにすべて備わっていると考えてはいけません。公式は、LoopXがautonomous production controllerではなく、危険な権限、公開処理、production write、最終的なownershipは人間に残ると明記しています。逆に、一晩で終わり、失敗しても簡単に再実行できる小さなタスクなら、明確なチェックリストのほうが効率的です。

OpenAIのAgents SDKアップデートでも、長時間処理の設計にstate externalization、snapshotting、rehydrationが取り入れられています。これはdurable executionが実際のニーズであることを独立して裏づけますが、LoopXへの推奨ではありません。また、OpenAI SDKの機能をLoopXも保証しているとはいえません。

まとめ：長いタスクで重要なのは、次へ進めるかを常に判断できること

今動かしているautomationを1つ選び、goal、gate、todo、evidence、stop ruleを書き出してください。そのうえで実際にprocessを終了し、restart drillを行います。合格できなければ、schedulerの頻度やagentの数を増やすのは後回しです。失敗がより頻繁に起きるだけです。

短く、外部への副作用がないタスクなら、良いチェックリストで十分です。sessionをまたぎ、実システムに触れるタスクなら、最小状態契約から始めます。複数agentが同じ作業を取り合う段階で、claim、lease、LoopXのようなcontrol surfaceを追加しましょう。信頼性とは、止まらず動き続けることではありません。止まるべきときに、確実に止まれることです。