Claude Opus 5.5が18時間タスクを実行：長時間稼働エージェント向けAPI設計の方法

スタック内のあらゆるタイムアウトは、最終的に諦めるクライアントを前提にしています。ブラウザタブは閉じられます。CIジョブは実行時間の上限に達します。人間はその場を離れます。ロードバランサー、ゲートウェイ、HTTPライブラリから受け継いだデフォルト値は、忍耐が秒単位で測られる呼び出し元に合わせて調整されていました。

Anthropicは、Claude Opus 5.5が18時間以上タスクに取り組み続けると述べています。

これは、1つの非常に長いHTTPリクエストについての主張ではありません。一貫性についての主張です。モデルは、あなたのAPIがこれまでに提供したどのセッションよりもはるかに長いセッションにわたって、単一の目的に取り組みます。そうしたセッションの1つがあなたのエンドポイントを指すと、アクセストークン、冪等性ウィンドウ、デプロイサイクル、そしてほとんどのリトライ予算よりも長く生き残ります。そして人間と違い、止まるべきだと気づくことはありません。

これはモデルの問題ではなく、API設計の問題です。何が壊れるのか、そして何を変えるべきなのかを以下に示します。

Anthropicが実際に公開した内容

新しいモデルのベンダー公表値です。同じ資料に基づいて議論できるようにします：

同じ発表のベンチマーク：Terminal-Bench 4.0 66.4%、OSWorld 2.0 81.8%、AutomationBench 40.0%、FrontierCode v1.1 54.4%、CursorBench 4.0 57.8%、Humanity’s Last Examはツール使用時67.7%、Chartography 89.0%、GDPval-AA v2.1は1846 Elo、そして境界回避の成功試行が85%減少しました。

あなたのインフラに直接関わるのは18時間という数字です。ベンチマークスコアはどのモデルを選ぶかを変えます。持続時間は、あなたのAPIが何に耐えなければならないかを変えます。

成り立たなくなる6つの前提

それぞれに地味でよく理解された修正策があり、たいていは問題を強制するものがないため飛ばされます。今、何かがそれを強制しています。

作業ではなくハンドルを返す

最も価値の高い変更：数秒を超える可能性がある操作は、接続を保持するのではなく、ジョブリソースを即座に返します。

POST /v1/reports HTTP/1.1
Host: api.example.com
Idempotency-Key: 01J9Z4KCQ7M3XN2YB8V6H0
Content-Type: application/json

{"dataset": "orders_2026_q3", "format": "parquet"}

HTTP/1.1 202 Accepted
Location: /v1/jobs/job_01J9Z4KD
Retry-After: 5
Content-Type: application/json

{
  "id": "job_01J9Z4KD",
  "status": "queued",
  "created_at": "2026-09-23T04:12:09Z",
  "api_version": "2026-08-01"
}

次に、ステータスリソースは、エージェントが次に何をすべきか判断するために必要なすべてを運びます：

{
  "id": "job_01J9Z4KD",
  "status": "running",
  "progress": { "completed": 41200, "total": 180000, "unit": "rows" },
  "started_at": "2026-09-23T04:12:11Z",
  "updated_at": "2026-09-23T05:47:02Z",
  "expires_at": "2026-09-24T04:12:09Z",
  "retry_after_seconds": 15,
  "result_url": null,
  "error": null
}

実際に機能するのは4つのフィールドです。明示的なunitを伴うprogressにより、モデルは経過時間から推測するのではなく、待つことが合理的かどうかを推論できます。retry_after_secondsはポーリングの頻度をサーバー側の制御下に置きます。これは呼び出し元に礼儀という感覚がない場合に重要です。expires_atはハンドルがいつまで有効かをエージェントに伝えるので、失う前にチェックポイントを作れます。api_versionはジョブをそれが作成されたときの契約に固定します。これは午後3時のデプロイと夜明けに始まった実行の間に立つ唯一のものです。

Webhookを提供できるなら、完了シグナルとしてはそちらの方が優れており、エージェントに呼び出し可能なアドレスがない場合のフォールバックがポーリングです。長時間実行されるエージェント呼び出しにおけるポーリングとWebhookの比較のウォークスルーで、トレードオフを説明しています。18時間という視野で変わるのは、両方が必要になるということです。なぜなら、3時間目に配信されたWebhookが、その後コンテキストを圧縮したエージェントに届いても、もはや依頼したことを覚えていない呼び出し元に届くからです。

冪等性をタスクより長生きさせる

ほとんどの冪等性実装はキーを1日以下しか保存せず、それで常に十分でした。長い実行の終盤で失敗したプロビジョニング呼び出しをリトライするエージェントは、元の重複排除ウィンドウの外に出てしまい、その時点でAPIは喜んで作業を二重に行います。

3つの変更はほとんどコストがかかりません：

1. ウィンドウを公開する。 有効期限をレスポンスで返し、呼び出し元がそれを推論できるようにします。一度ドキュメントに書いて願うだけにしないでください。
2. リプレイしたことを伝える。 Idempotency-Replayed: trueヘッダーは、無言のno-opをエージェントが行動できるものに変えます。
3. 不一致は大声で拒否する。 同じキーで異なるボディは、呼び出し元が自分の状態を見失っていることを意味します。古い結果を返すのではなく、元のリクエストのフィンガープリントとともに409を返してください。

HTTP/1.1 200 OK
Idempotency-Replayed: true
Idempotency-Expires: 2026-09-24T04:12:09Z

操作が本当に危険な場合は、不透明なキーよりもクライアント提供の自然キーを優先してください。業務上の事実から導出されたtransfer_idは、エージェントのメモリ圧縮を生き延びますが、11時間前に生成したランダムUUIDはそうではありません。エージェントの冪等性に関する入門記事で、失敗モードを説明しています。

認証情報がタスク途中で期限切れになると仮定する

18時間の実行は、ほとんどすべての短命なアクセストークンより長く続きます。それは正しいセキュリティ姿勢ですが、APIがその区別を読み取れるようにしている場合に限ります。

トークンが期限切れの場合はWWW-Authenticate: Bearer error="invalid_token"チャレンジとともに401を返し、権限を持たないプリンシパルには403を取っておいてください。エージェントはこれらを大きく異なる形で扱います。一方は更新して続行を意味し、もう一方は停止して報告を意味します。これらを一般的な失敗にまとめてしまうと、決して許可されないことを4時間もリトライし続けるエージェントが生まれます。

ジョブはトークンインスタンスではなくプリンシパルに紐づけてください。その後ローテーションされたトークンの下で開始されたジョブは、同じアイデンティティから引き続き読み取れなければなりません。そうでなければ、認証情報を更新するたびに進行中の作業が孤立します。

ストリームは接続ではなく再開可能なものとして扱う

長いストリームは切れます。それを前提にし、接続ではなく再接続を設計してください。

サーバー送信イベントの場合、それはすべてのイベントに単調増加のidを付け、再接続時にLast-Event-IDリクエストヘッダーを尊重し、あなたとクライアントの間で最も厳しいアイドルタイムアウトより短い間隔でkeepaliveコメントを送信することを意味します。読者が実際に変更しに行く必要があるので、設定キーを自分のドキュメントで名指ししてください。AWSロードバランサーのidle_timeout.timeout_seconds、nginxのproxy_read_timeout、Cloud Runサービスのtimeoutです。重要なのは特定の値ではありません。その値が存在し、作業より短く、サービス作成以来誰も見ていないということです。SSEストリーミングガイドでワイヤーフォーマットを説明しています。エージェント固有の部分は再開です。

レート制限ヘッダーもいつも以上に重要です。RateLimit-Limit、RateLimit-Remaining、RateLimit-Resetは、モデルが長い実行全体でペースを調整できるようにし、すべての429にRetry-Afterがあれば推測が不要になります。数値を与えられたエージェントはそれを尊重します。何も与えられないエージェントはバックオフを発明し、その発明があなたのものより良くなることはありません。

コスト面は設計上の決定

価格の行をもう一度見てください。入力は100万トークンあたり$4、キャッシュ読み取りは$0.20で、エージェントが最も頻繁に再送するペイロード部分では20倍の差があり、1Mコンテキストウィンドウでは絶対額がすぐに大きくなります。キャッシュ書き込みが$5ということは、最初のパスは通常の読み取りより少し高くつくため、キャッシュはプレフィックスが本当に再利用される場合にのみ元が取れます。18時間にわたれば、それは実現します。

ここで、あなたのAPIサーフェスが他人の請求書におけるコスト入力になります。OpenAPI仕様、ツール定義、エラーカタログがエージェントのコンテキストの先頭にあるなら、バイト安定性は機能です。決定的にシリアライズしてください。キーの順序を安定させてください。ツール定義はその場で編集するのではなく、バージョン管理してください。仕様の見た目だけの並べ替えはキャッシュされたプレフィックスを無効にし、全体を通常の入力価格で再請求します。その費用を払う顧客は、それがあなたのせいだとは決して知りません。

規模は仮定の話ではありません。OpenAIは、中央値の研究者がコーディングエージェントに1日$600以上を使い、90パーセンタイルでは1日$7,000を超えると開示しました。誰も最適化しない場合の継続的なエージェント作業のコストがこれであり、2日間で3つのモデルが発表された際に、いずれもトークンあたりのコストではなくタスクあたりのコストを前面に出した理由の一部です。キャッシュがいつ元を取るかの計算は、Opus 5.5のキャッシュコスト内訳にあります。

エージェントが見つける前に長い経路をテストする

これを一度送信をクリックして200を読むだけでは検証できません。失敗は9時間目に潜んでいます。

Apidogでは、単一のリクエストではなくテストシナリオとしてライフサイクル全体をモデル化します。作成呼び出しがLocationとRetry-Afterを伴う202を返すことをアサートし、終端状態までステータスエンドポイントをループし、progress.completedが決して後退しないことをアサートします。最後のアサーションは、どのステータスコードチェックよりも多くの実際のバグを捕まえます。なぜなら、単調でない進捗こそがエージェントに最初からやり直させるからです。

次に、モックサーバーで意図的に壊してください。20回のポーリングの間runningのままで、その後失敗するジョブを提供してください。Retry-Afterのない429を提供し、クライアントがどうするか見てください。途中で401を提供し、ジョブが進行中でも更新パスが機能することを確認してください。ApidogのSSEテストはストリーミング接続を開いたままにし、個々のイベントをアサートします。これはLast-Event-IDによる再開がゼロから再生するのではなく正しいカーソルを返すことを確認する唯一の実用的な方法です。シナリオをCIに組み込み、将来のタイムアウト変更が顧客の夜通しの実行ではなくテストを失敗させるようにしてください。Apidogは無料で始められ、一度構築したシナリオは所有するすべての長時間実行エンドポイントをカバーします。

短いチェックリスト

• 長時間操作はジョブハンドルとともに202を返し、接続を保持しない
• ステータスレスポンスは進捗、単位、サーバーが選んだポーリング間隔、有効期限を含む
• ジョブは作成時のAPIバージョンに固定される
• 冪等性ウィンドウは公開され、リプレイにはラベルが付き、ボディが変更されたキー再利用は409を返す
• 期限切れトークンの401は、拒否された場合の403と区別できる
• ジョブはトークンインスタンスではなくプリンシパルに属する
• ストリームはイベントIDを持ち、Last-Event-IDを尊重し、経路上で最短のアイドルタイムアウト内にkeepaliveを送る
• すべての429はRetry-Afterを持ち、レート制限ヘッダーは常に存在する
• 仕様とツール定義はバイト安定でシリアライズされ、クライアント側キャッシュが温かいままになる

Opus 5.5はこれらの要件を発明したわけではありません。それらを飛ばす最後の言い訳を取り除いたのです。なぜなら、以前は亀裂を見つける前に諦めていたクライアントが、今では18時間にわたって亀裂を突き抜けて作業し続けるからです。