Claude APIのMessage threadsとは｜長い会話を新しい分だけ送るベータ機能と注意点【2026年】

Claude APIのMessage threadsを、僕は「長い会話の荷物を、API側に少しの間だけ預けておける仕組み」と読んでいます。2026年11月2日にベータで公開され、2回目以降のリクエストは、新しいメッセージと前の返答のidを送るだけでよくなりました。長いエージェントの処理ほど効く、と公式は説明しています。

この記事は公式情報・公開情報をもとにまとめた解説です。僕の会社で検証していない点は、その旨を書いています。出典はAnthropicの公式ページで、確認日は2026年11月3日です。

何が変わるのか、誰が使えるのか、始め方、料金と制限、つまずきやすい点の順に並べます。「結局、うちのチャットボットに入れると何が楽になるの？」という問いには、最後の見立ての節で答えます。

Claude APIのMessage threadsとは：会話をAPI側に置き、2回目から新しいメッセージだけ送る

Message threadsは、Messages APIで会話をサーバー側に短い時間だけ保管しておく機能です。最初に会話全体を1回送れば、次からは新しいメッセージだけを送れば済みます。

これまでのMessages APIは、毎回のリクエストで会話の最初から全部を送り直す作りでした。公式ドキュメントは、スレッドが無いと毎回すべてを送り直し、APIもそのたびに全部を検証・トークン化し直すと書いています。

スレッドを使うと、その作業の大半が新しい1往復の分だけになります。

使うには、Messages APIのリクエストに thread という項目を1つ足し、ベータのヘッダー message-threads-2026-08-12 を付けます。返ってくる答えは、いつもの形のメッセージです。

Managed Agentsの「session threads」とは別もの

公式ドキュメントは、Message threadsはClaude Managed Agentsの「session threads」とは別のものだと注記しています。名前が似ているので、資料を探すときは混ぜないようにしておきたいところです。

何が変わる：リクエストが小さくなり、最初のトークンまでの時間が伸びにくい

リリースノートの説明は、長い会話やエージェントのループで、リクエストが小さくなり、最初のトークンまでの時間が短くなる、というものです。

ここでいう最初のトークンまでの時間は、リクエストを送ってから、返答の最初の文字が届き始めるまでの待ち時間を指します。ドキュメントは、会話が長くなっても、この時間が低く安定しやすいと説明しています。

作る・続ける・送り直す、の3つの動き

スレッドの動きは、公式ドキュメントで3つに分けて説明されています。名前は公式の表記のまま並べます。

• Create：1回目は今までどおり会話全体と system・tools を送り、thread に type を create と指定する
• Continue：2回目からは前の返答以降の新しいメッセージだけを送り、前の返答の id を指定する
• Replay：スレッドが続けられないときは、会話全体を新しい Create で送り直す

APIは返答も含めた会話を、その返答の id で保管します。次の回はその id から続け、新しい返答の id をまた次の回に使う、というリレーの形です。

毎回送るもの・1回目だけ送るもの

どの項目をいつ送るかは、公式の表で3つの組に分かれています。ここを取り違えるとエラーになるので、要点を表にします。

モデルやシステムプロンプトを途中で変えたいときは、新しいスレッドを作り直す決まりです。僕なら、変えそうな設定は1回目を送る前に固めておきます。

会話は追記だけ、1つの id から続けられるのは1回

スレッドは追記だけの作りで、1つの返答の id から続けられるのは1回だけです。途中のメッセージを直したり、話を枝分かれさせたりするには、新しいスレッドを作ります。

長くなった会話を要約で置き換えたいときも同じで、要約を普通のメッセージとして新しい Create で送る、と公式にあります。

誰が使える：Claude APIなど4つの提供先、日本からも利用できる

Message threadsは、Messages APIのベータ機能として、次の4つの提供先で使えると公式に書かれています。

• Claude API
• Claude Platform on AWS
• Claude Models on Google Cloud（Anthropic managed）
• Claude in Microsoft Foundry

この一覧に、Amazon Bedrock の名前はありません。Google Cloud は「Anthropic managed」の版だけが挙がっています。

対応するモデル

ドキュメントの対応モデルの一覧には、Claude Fable 5.1、Claude Opus 5.5、Claude Sonnet 5.5、Claude Haiku 5.5 などの現行モデルが並んでいます。

古い方では Claude Opus 4.5、Claude Sonnet 4.5、Claude Haiku 4.5 までが入っています。全部で17のモデルIDが載っていて、可用性の欄には「すべてのモデルでベータ」とあります。

使えない組織

ドキュメントの「スレッドが対応しない機能」には、組織の設定が2つ挙がっています。HIPAA対応（HIPAA readiness）を有効にした組織と、Inference hooks を有効にした組織です。

プランの条件については記載がありません。ベータのヘッダーを付ければ、対応する提供先とモデルで使える書き方です。

日本で使えるか

Anthropicの提供地域の一覧に日本は入っていて、APIと開発者向けの基盤もこの一覧の国で提供される、と書かれています。Message threadsのドキュメントには、国ごとの制限の記載はありません。

始め方：ベータのヘッダーと thread を1つ足す

ここからは、公式ドキュメントに載っている形だけを並べます。手順を自分で補ってはいません。始め方は、SDKの補助機能を使う方法と、thread を自分で書く方法の2つです。

SDKの補助機能（thread ヘルパー）を使う

SDKには、スレッドのリクエストを組み立てる補助機能があります。公式のPythonの例は次のとおりで、1回目でスレッドを作り、2回目で続けます。

client = anthropic.Anthropic()

# Create the helper. This call sends no request.
thread = client.beta.messages.thread(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are a support agent for Acme. Keep replies short.",
)

# Turn 1: the helper creates a thread and sends the full conversation
thread.send({"role": "user", "content": "Hi! I have a question about an order."})

# Turn 2: the helper continues the thread and sends only the new message
second = thread.send(
    {"role": "user", "content": "How long does standard shipping usually take?"}
)

for block in second.content:
    if block.type == "text":
        print(block.text)

補助機能は、ベータのヘッダーを自動で付けます。2回目からは system と tools を外して送り、スレッドが切れたときの送り直しも1回は自分で行います。

例の cache_control は任意で、毎回プロンプトキャッシュを効かせるための指定だと書かれています。ドキュメントにはTypeScript、C#、Go、Java、PHP、Rubyの例も並んでいます。

thread を自分で書く

cURL や SDK の通常の create で送る場合は、リクエストに thread を足します。ベータのヘッダー message-threads-2026-08-12 は、スレッドのすべてのリクエストに付けるよう書かれています。

1回目は、いつものリクエストに次の1行を足します。

"thread": {"type": "create"}

2回目からは、新しいメッセージだけを messages に入れ、前の返答の id を指定します。system と tools は送りません。

"thread": {"type": "continue", "previous_message_id": "<previous id>"}

APIキーは、公式の cURL の例でも $ANTHROPIC_API_KEY のように環境変数から渡す形です。キーをコードに直接書かない点は、通常のMessages APIと変わりません。

料金・制限：料金とレート制限は変わらず、スレッドは5分で期限切れ

公式ドキュメントの「Pricing and rate limits」の節は、1文だけです。スレッドは料金もレート制限も変えない、と書かれています。

送るデータが小さくなっても、それで請求が下がるとは説明されていません。費用を抑えたいなら、別にプロンプトキャッシュを設定する必要があります。スレッドは、自動ではプロンプトをキャッシュしないと明記されています。

APIの従量課金と、Claude Codeなどのサブスクの違いは、Claude Codeの料金の解説に分けて書いています。

期限と保管の長さ

スレッドは最後のリクエストから5分で期限切れになり、最後に使ってから1時間以内に削除されます。APIが返答を保管するたびに、5分の時計は最初に戻ります。

公式はスレッドを「ベストエフォート」と呼んでいます。期限内でも続けられない場合があり、そのときは続きのリクエストが404エラーになります。

数の上限と、使えない機能

1つのスレッドのリクエストに付けられる cache_control の区切りは4つまでです。5つ以上だと400エラー（thread_unsupported_request）になります。

スレッドと一緒に使えない機能として、公式は次のものを挙げています。

• Message Batches（バッチ処理）
• トークン数を数えるAPI（Token counting）
• 会話の圧縮（Compaction）とオンデマンドの圧縮
• コンテキスト編集（clear_thinking_20251015 を keep: "all" で使う場合を除く）

スレッドを一覧・取得・削除するAPIはありません。会話の長さやメッセージ数の上限は、ドキュメントに数字の記載がありません。

注意点：会話の控えは自分で持つ・ZDRの対象外・ツールランナーは既定でスレッドを使う

公式ドキュメントの注意書きのうち、仕組みを作る前に知っておきたいものを4つに絞ります。

1つ目は、会話の控えです。公式は、会話の正本はあくまでアプリ側だとし、すべてのメッセージを自分で控えておくよう書いています。返答には、そのターンを保管できたかどうかが書かれていません。

保管できていなかったことは、次の続きのリクエストで初めて分かります。だから、送り直しの道を最初から作っておくよう案内されています。SDKの補助機能の控えはメモリの中だけで、プログラムが終われば消えます。

2つ目は、データの扱いです。Message threadsはゼロデータ保持（ZDR）の対象外で、HIPAAも対象外とされています。

スレッドの中身は、サーバーが管理する鍵で暗号化してメモリに置き、恒久的な保存先には書かない、と説明されています。この機能を使っても、ほかのZDR対象の機能の扱いは変わらないとも書かれています。

3つ目は、SDKのベータのツールランナーです。ツールランナーは既定でスレッドを使い、作るときに止められると書かれています。Pythonでは tool_runner に thread=False を渡す形です。

ZDRを前提にしている会社が、知らないうちにスレッドを使っていた、という形は避けたいところです。

4つ目は、エラーへの備えです。続きが返す404（thread_not_found）の理由は、レスポンスには書かれません。期限切れのほか、別のAPIキーや別のワークスペースからの続きも原因に挙がっています。

1つのスレッドは、最初から最後まで同じAPIキーと同じワークスペースで送るよう案内されています。返答が「refusal」で止まったときは、そのスレッドを続けずに、新しいスレッドで作り直す決まりです。

中小企業での使いどころ（僕の見立て）

ここからは事実ではなく、僕の見立てです。Message threadsは、自社のアプリやツールからClaude APIを呼んでいる会社のうち、1回の会話が長くなる仕組みを持っている会社に向く機能だと読んでいます。

逆に、ChatGPTやClaudeの画面で使っているだけの会社には、直接の関係はありません。APIで作った仕組みの裏側の話だからです。

合いそうな場面

• 自社サイトの問い合わせ窓口に置いたAIチャットで、1人のお客さんとのやり取りが長く続きやすい
• 社内のエージェントが、ツールを何度も呼びながら1つの作業を進める
• 長い社内資料を最初に渡し、その後は短い質問を続ける

どれも、会話の頭に重い荷物があり、後から小さな質問が続く形です。こうした仕組みでは、返答が出始めるまでの待ちが短くなる余地がある、と見ています。

向きにくい場面

1回の質問で終わる呼び出しや、記事や商品説明をまとめて作るバッチ処理には向きにくいと読んでいます。バッチ処理は、公式にスレッド非対応と書かれています。

返答の間が5分以上空く使い方も、スレッドが切れやすいはずです。お客さんが考え込んでから返信する窓口なら、送り直しが頻繁に起きる前提で作る方が安全だと考えています。

外注先に作ってもらっている場合

自社でコードを書かず、制作会社にAIの仕組みを作ってもらっている場合は、確かめる点が2つあります。ZDRやHIPAAの契約を前提にしているかと、会話の控えをどこに置いているかです。

Claude Codeの利用枠で「毎回送り直す量」を減らす考え方は、Claude Codeのトークン節約の記事に書いています。

Message threadsはAPIの機能で、Claude Codeの設定ではない点は分けて考えてください。

まとめ

• Claude APIのMessage threadsは、2026年11月2日に公開されたMessages APIのベータ機能。ヘッダーは message-threads-2026-08-12
• 1回目に会話全体を送り、2回目からは新しいメッセージと前の返答の id だけを送る。リクエストが小さくなり、最初のトークンまでの時間が伸びにくい
• 提供先はClaude API、Claude Platform on AWS、Google Cloud（Anthropic managed）、Microsoft Foundry。HIPAA対応の組織とInference hooksの組織は対象外
• スレッドは5分で期限切れ、1時間以内に削除。料金とレート制限は変わらず、ZDRの対象外
• 僕なら、まず会話の控えと送り直しの道をアプリ側に作ってから、SDKの補助機能でスレッドを足します