Anthropic、サーバー側メッセージスレッドでClaude Codeの遅延を削減

Anthropicは、Messages APIの新機能「メッセージスレッド」を発表しました。この機能は、冗長なデータ送信を減らすことで、長時間にわたるAIセッションの処理速度を向上させることを目的としています。現在パブリックベータ版として提供されており、すでに多くのClaude Codeユーザーで有効化されています。これにより、モデルが応答を開始するまでの時間を短縮することを目指しています。

何が起きたか

今回のアップデートが解決する主要な課題は、長時間タスクにおける従来のAPIインタラクションの非効率性です。従来、Claudeへのすべてのリクエストでは、クライアントが会話履歴全体（過去のメッセージ、ツール呼び出し、システムプロンプトなど）をアップロードする必要がありました。コーディングエージェントがファイルの読み取りや編集などの複雑なタスクを実行するにつれ、この履歴は急速に増加します。セッションが50万トークンに達すると、新しいリクエストごとにこの大量のデータを再アップロードする必要があり、APIは処理を開始する前にそのデータの検証とトークン化を行わなければなりませんでした。

メッセージスレッドは、Anthropicのサーバー上で会話履歴を一時的に保持することで、この仕組みを変えます。最初のリクエストでは依然として完全なコンテキストを送信しますが、以降のリクエストでは新しいメッセージと前回のレスポンスIDへの参照のみを含めれば済みます。Anthropicはサーバー側で完全な会話を再構築してからモデルに渡します。この変更により、50万から100万トークンのコンテキストを含むClaude Codeリクエストにおいて、最初のトークン生成までの中央値時間が約35%短縮されました。

この機能は遅延とデータ転送量を大幅に削減しますが、APIコストは低下しません。Anthropicは、クライアントがアップロードするデータの量に関係なく、モデルによって処理されたすべてのトークンに対して引き続き課金を行います。同社は、開発者がメッセージスレッドとプロンプトキャッシュを組み合わせることでコストを低減できる可能性があることを指摘しています。両者はパフォーマンスと請求に関する異なる側面に対応しているためです。

仕組み

技術的には、メッセージスレッドはMessages APIに新しいパラメータを導入します。スレッドを開始するには、開発者は最初のリクエストに完全な会話履歴とともに thread={"type": "create"} を含めます。後続のターンでは、thread={"type": "continue", "previous_message_id": [ID]} を使用し、新しい入力のみを送信します。APIはサーバーメモリ内で以前のコンテキスト、システムプロンプト、ツール定義を保持するため、繰り返しアップロードする必要がなくなります。

Python SDKを使用する場合、スレッドヘルパーがこのプロセスを簡略化します。client.beta.messages.thread() を介してスレッドを初期化すると、SDKが作成と継続のロジックを自動的に管理します。これには、必要なベータヘッダー anthropic-beta: message-threads-2026-08-12 の追加も含まれます。この抽象化により、開発者はレスポンスIDの手動追跡や低レベルのAPIパラメータの処理を行うことなく、thread.send() を通じてメッセージを送信することに集中できます。

主な詳細

• メッセージスレッドは、AWS、Microsoft Foundry、Google Cloud上のモデルを含むすべてのClaudeモデルでパブリックベータ版として利用可能です。
• この機能により、50万から100万トークンの大規模コンテキストにおいて、最初のトークン生成までの中央値時間が約35%短縮されます。
• スレッドは5分間の非アクティブ状態後に期限切れとなり、この制限を超える停止が発生した場合は、履歴全体の再送信が必要になります。
• Claudeは各ターンで会話履歴全体を引き続き処理するため、トークン使用量と請求に変更はありません。
• スレッドの内容は暗号化され、最終使用後最大1時間までサーバーメモリに保存されますが、永続ストレージには書き込まれません。
• この機能は現在、ゼロデータ保持ポリシーおよびHIPAAコンプライアンス要件と互換性がありません。

なぜ重要なのか

AIエージェント、特にコンピュータ操作や長時間のコーディングタスクを含むものを構築するエンジニアにとって、遅延は重要なボトルネックです。StackOneのCTOであるGuillaume Lebedel氏は、その潜在的な影響について、スクリーンショットを撮影するコンピュータ操作エージェントの場合、50ステップのセッションで累積データアップロード量が191 MBから7.5 MBに削減される可能性があると推定して示しました。ネットワークペイロードのこの劇的な削減は、Anthropic側の計算コストが同じままであっても、往復時間の高速化とエージェントの応答性向上を意味します。

しかし、5分間の期限切れウィンドウは、開発者がアプリケーションロジックで考慮すべき制約をもたらします。連続的に動作するエージェントはこの制限にほぼ遭遇しませんが、人間が使用するインタラクティブなツールでは中断が発生する可能性があります。開発者がコーヒーブレイクなどで離席した場合、スレッドは期限切れとなり、次のリクエストでは履歴全体を再アップロードする必要があります。SDKは新しいスレッドを確立することでこれを適切に処理しますが、スレッドが再確立されるまでの休憩後の初回遅延は高くなります。

対応策

• Anthropic Python SDKを最新バージョンに更新し、client.beta.messages.thread() ヘルパーを利用できるようにしてください。
• 長時間稼働するエージェントループをスレッドヘルパーを使用するようにリファクタリングしてください。直接API呼び出しを行う場合は、betas=["message-threads-2026-08-12"] ヘッダーを渡すことを確認してください。
• エージェントのアイドル時間を監視し、セッション再開時にスレッド期限切れを適切に処理するためのローカル状態管理を実装してください。
• システム指示などの静的コンテンツに対して、メッセージスレッドとプロンプトキャッシュを組み合わせ、遅延とコストの両方を最適化してください。
• データコンプライアンス要件を確認してください。メッセージスレッドは現在、HIPAA規制対象環境やゼロ保持環境には適していません。
• 大規模コンテキストのワークロードでこの機能をテストし、特定のユースケースにおける最初のトークン生成までの実際の改善度を測定してください。