Anthropicは11月2日、Claude Platformで「message threads」の公開ベータを開始した。開発者はMessages APIのリクエストにthreadパラメーターを追加し、最初のターンで会話全体を送る。以降は新しいメッセージと直前の応答のIDだけを送れば、サーバー側が会話を組み立て直す。
同社が示す数字はClaude Codeのものだ。この機能はすでにClaude Codeの大半のユーザーで既定で有効になっており、50万〜100万トークンのリクエストでは、最初のトークンが返るまでの時間の中央値が約35%短くなったという。ほかの長さの区間での効果は、ブログには記載されていない。
公開ベータの対象は、Claude API、Claude Platform on AWS、Microsoft Foundry、そしてGoogle Cloud上でAnthropicがホストするClaudeだ。ドキュメントに挙がる対応モデルは、Sonnet 4.5とOpus 4.5からFable 5.1、Mythos 5.1までに及ぶ。
省けるのは検証とトークン化
スレッドがない場合、エージェントはターンごとに会話全体をアップロードし直し、APIも検証とトークン化をやり直す。セッションが長いほどこの準備作業に時間がかかる。特にコンピューター操作型のエージェントは不利で、過去のスクリーンショットを毎ターン送り直さなければならない。
スレッドはこれらの内容をサーバーのメモリー上に置くため、処理の対象は基本的に新しく加わった1ターン分だけになる。
Claudeは毎ターン会話全体を読むので、モデル側のトークン数は減らず、課金とレート制限も従来のルールのままだ。目安を計算してみよう。80万トークンのセッションで毎ターン2000トークンが追加される場合、スレッドを使うとリクエストで送る内容は従来の約400分の1になるが、請求上の入力トークンは80万超のままだ。コストを抑えるにはやはりプロンプトキャッシュが必要で、これは別のスイッチになる。スレッドを使うリクエストでは最上位にcache_controlを付けられる。付けなければ、新規メッセージだけを送っても何もキャッシュされない。
導入時は退路を残す
ドキュメントはスレッドを「ベストエフォート」と位置づけており、これが実装方針を左右する。
- 失効：スレッドは最後のリクエストから5分で失効する。応答が保存されるたびにタイマーはリセットされ、最後の使用から最長1時間で削除される。
- 無効化：継続リクエストが404を返したら、会話全体を送り直して新しいスレッドを開く必要がある。そのターンが正しく保存されたかどうかは応答からは分からず、次の継続リクエストで初めて判明する。
- 複製：会話の正本は引き続きアプリケーション側にある。公式SDKのヘルパーはメモリー上にコピーを持ち、自動で再送するが、プロセスが終了すると消える。プロセスをまたぐ必要があるなら、自前で保存しなければならない。
- 固定フィールド：
systemとtoolsは作成時にしか送れず、継続リクエストに含めるとnullであっても400エラーになる。model、thinking、tool_choice、mcp_serversなどは毎ターンそのまま再送する必要があり、変更するとthread_fingerprint_mismatchが返る。システムプロンプトやツールを変えたい場合は、新しいスレッドを開くしかない。
コンプライアンス面にも制約がある。スレッドの内容はメモリー内で暗号化して保持され、永続ストレージには書き込まれないが、この機能はゼロデータ保持（ZDR）の要件を満たさない。ZDRを契約している企業でも、ほかの機能への影響はないが、スレッドだけは使えない。
開発者は、Claude Managed Agentsにあるsession threadsと、今回のmessage threadsが別物であることにも注意が必要だ。
埋められた空白
OpenAIのResponses APIには以前からprevious_response_idがあり、IDを渡して前の文脈を引き継ぐ仕組みになっている。Anthropic側は長く、クライアントがターンごとに全履歴を送る方式を採ってきた。ステートレスで実装が素直という利点がある一方、会話が長くなると遅延が増える。今回の方式はその折衷案で、状態はサーバー上に短時間だけ置かれ、失われたら再送すればよく、クライアント側のコピーは1つも欠かせない。
公式が挙げる想定用途を見ると、主な対象は長時間動くコーディングエージェント、コンピューター操作エージェント、文書や画像が多いワークフローだ。Anthropicも、まず自社のClaude Codeで既定で有効にしてから、APIユーザーに開放した。
数十万トークンに満たない通常の会話でどれだけ改善するかについては、公式は数字を出していない。ドキュメントには、スレッドが最も効くのは長いエージェントのループだとあるだけだ。エージェントを自前で構築しているチームは、まず自分たちのセッション長の分布で一度測定し、その上で、この404時の再送経路のために余分なコードを書く価値があるかを判断するのがよさそうだ。
参考資料：Claude公式ブログ、CocoLoop、Claude Platform開発者向けドキュメント。遅延の短縮幅は公式が公表したClaude Codeの中央値に基づき、概算部分は編集部による試算。