Claude APIのmessage threads:新しいメッセージだけを送る

AnthropicがClaude APIのmessage threadsをベータ公開しました。会話がしばらくサーバー側に残り、2回目以降のリクエストでは新しいメッセージだけを送ればよくなります。この機能は11月2日にClaude Release Notesに掲載され、ベータヘッダーmessage-threads-2026-08-12で利用できます。

Claude APIのmessage threadsはどう動くのか?

これまでMessages APIとの会話では、ターンごとに履歴全体を送り直す必要がありました。システムプロンプト、ツール、すべてのメッセージです。message threadsのドキュメントによると、APIは毎回そのすべてを検証し直し、トークン化し直していました。スレッドを使えば、その処理の大半は新しいターンだけで済みます。

仕組みは新しいパラメーターthreadひとつだけです。

1. 最初のリクエストは通常どおり、会話全体とsystem、toolsに加えて"thread": {"type": "create"}を付けて送ります。APIは会話をClaudeの応答と一緒に、その応答のidで保存します。
2. 以降のリクエストには"thread": {"type": "continue", "previous_message_id": "<id>"}と新しいメッセージだけを入れます。たとえば次のユーザーメッセージや、ツールの実行結果(tool_result)です。
3. systemとtoolsはスレッドが覚えているので省略します。continueリクエストでこれらを送ると400エラーになります。

Anthropicによると、リクエストが小さくなり、会話が長くなっても最初のトークンまでの時間が短く安定します。最も恩恵を受けるのは長いエージェントループです。エージェントが何十回もツールを呼び出し、そのたびに膨らみ続ける履歴を送っていたからです(こうしたループの仕組みはAIエージェントとは何かの記事で解説しています)。

SDKは何をしてくれるのか?

SDKには新しいヘルパーclient.beta.messages.thread(...)が加わりました。通常のリクエストと同じフィールドで作成し、以降のターンはthread.send(...)で送ります。ヘルパーがベータヘッダーを自動で付け、最初のターンでスレッドを作成し、次のターンからはそれを継続します。

興味深いことに、SDKのベータ版tool runnerはデフォルトでスレッドを使います。そのため、これを使って作ったエージェントはコードを変えずに速くなる可能性があります (runnerの作成時に無効化できます)。

ヘルパーは障害時の対応もしてくれます。スレッドが期限切れになると、会話全体を新しいcreateリクエストで送り直します。ただし、その完全なコピーはヘルパーオブジェクトが存在する間だけメモリ上に保持されます。

注意すべき点は?

1つ目は寿命の短さです。スレッドは最後のリクエストから5分で期限切れになり、APIは最後の利用から遅くとも1時間以内に削除します。ドキュメントはスレッドを「best-effort」と位置づけています。アプリケーション側が会話の正本(source of truth)であり続け、404エラーthread_not_foundの後に全体を送り直す処理を最初から用意しておく必要があります。

2つ目は変えてはいけないものです。model、thinking、tool_choice、context_managementなどのフィールドはスレッド全体で同じ値でなければならず、違うとAPIはthread_fingerprint_mismatchエラーを返します。スレッドは伸ばすことしかできず、各応答のidから継続できるのは1回だけです。前のメッセージを編集したり、システムプロンプトを変えたりするには、新しいスレッドを始めます。

3つ目はプロンプトキャッシュです。スレッド自体は何もキャッシュしません。キャッシュはこれまでどおりに動き、thread付きのリクエストに入れられるcache_controlブレークポイントは最大4つです。最も簡単なのは、毎ターン同じcache_controlをリクエストのトップレベルに付けて送ることです。

4つ目は、スレッドと併用できない機能です。

1. Message BatchesとToken Counting。
2. Compaction(オンデマンドのコンパクションを含む)とcontext editing(ドキュメントに記載された例外がひとつあります)。
3. HIPAA readinessまたはInference hooksを有効にしている組織。

5つ目はデータです。スレッドはZDR(zero data retention)の対象外です。ドキュメントによると、会話、システムプロンプト、ツールはメモリ上に保持され、サーバー管理の鍵で暗号化され、永続ディスクに書き込まれることはありません。

どこで、どのモデルで使えるのか?

message threadsはClaude API、Claude Platform on AWS、Claude Models on Google Cloud(Anthropicが管理するもの)、Microsoft Foundryでベータ提供されています。対応モデルにはClaude Fable 5.1とMythos 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5などがあり、旧世代ではOpus 4.5、Sonnet 4.5、Haiku 4.5も含まれます。

スレッドは料金もレート制限も変えません。トークン料金はこれまでどおりなので、節約できるのは時間とリクエストサイズです。コストは引き続き追跡する価値があり、たとえばClaudeのコスト分析用の新しいAPIが使えます。これはここ数日で続くAPI自体の変更のひとつで、リクエストサイズ上限の128MBへの引き上げに続くものです。

(Claude Managed Agentsの「session threads」と混同しないでください。ドキュメントも注意しているとおり、別の機能です。)

よくある質問

Claude APIのmessage threadsとは?

APIが会話を短時間サーバー側に保存するベータ機能です。最初のリクエストの後は、新しいメッセージと直前の応答のidだけを送ります。

message threadsでClaude APIのコストは下がる?

直接は下がりません。ドキュメントによると、スレッドは料金もレート制限も変えません。得られるのは、小さなリクエストと最初のトークンまでの短い時間です。

Claude APIはスレッドをどのくらい保持する?

スレッドは最後のリクエストから5分で期限切れになり、APIは最後の利用から遅くとも1時間以内に削除します。その後は会話全体を送り直す必要があります。

message threadsはAmazon Bedrockで使える?

ドキュメントに挙がっているのはClaude API、Claude Platform on AWS、Claude Models on Google Cloud(Anthropicが管理するもの)、Microsoft Foundryです。Amazon Bedrockはリストにありません。