AI道場 / ニュース

Message threadsとは？新着だけ送り待ち時間を短縮

2026年11月3日・Anthropicの発表より・AI道場 編集部

AnthropicはMessages APIの新機能「Message threads」をベータ版で提供しています。会話をサーバー側に短時間保持するため、2回目以降のリクエストでは新しいメッセージだけを送れます。対象は、長い会話やエージェントのループをAPIで動かしている開発者や実務者です。

Message threadsとは

Message threadsは、Messages APIの会話をサーバー側に短時間保持する機能です。最初に会話全体とシステムプロンプト、ツール定義を送ります。以降は、新しいメッセージと直前の応答のidだけを送れば続きを頼めます。

APIはモデルを呼び出す前に、保持している内容から会話を組み立て直します。開発者が追加するのは thread というパラメータひとつで、返ってくる応答は通常のメッセージと同じ形式です。

公式の説明はAPIの機能としてのものです。Claudeのアプリ画面での扱いは、公式の発表では触れられていません。

何が変わるか

変わるのは、リクエストの大きさと、最初のトークンが返るまでの時間です。

• これまで: ターンごとに会話全体を送り直し、APIもその全体を検証してトークン化し直していました。
• threadを使う場合: 検証やトークン化の作業の大半が、新しいターンの分だけで済みます。

その結果、リクエストは小さくなります。最初のトークンが返るまでの時間も、会話が伸びても低く安定しやすくなります。公式は、効果が特に大きい場面として長いエージェントのループを挙げています。

仕組み

threadの流れは次の3種類の手順でできています。

• 作成（Create）: 普段どおり会話全体、system、tools を送り、thread の type に create を指定します。APIはClaudeの返答を含む会話を、応答のidに結び付けて保存します。
• 継続（Continue）: 前回の応答より後のメッセージだけを送り、thread の type に continue、previous_message_id に前回のidを指定します。system と tools は送りません。
• 再送（Replay）: threadを継続できなくなったら、会話全体を新しい作成リクエストで送り直し、その応答のidから続けます。

threadの保持はベストエフォートです。最後のリクエストから5分で期限が切れ、最後の利用から1時間以内に削除されます。継続できない場合、継続リクエストは404エラーを返します。

threadは追記専用で、各応答のidから継続できるのは一度だけです。過去のメッセージを編集したり分岐させたり、要約に置き換えたりする場合は、新しいthreadを作成します。

使い方・始め方

始め方は2通りあります。

• SDKのthreadヘルパーを使う: 通常のMessagesリクエストと同じ項目でヘルパーを作り、ターンごとに送信します。作成と継続の切り替えとベータヘッダーの付与はヘルパーが行います。
• threadフィールドを自分で送る: cURLやCLI、SDKの通常のcreateメソッドで組み立てます。threadのすべてのリクエストにベータヘッダー message-threads-2026-08-12 を付けます。

自分で組み立てる場合は、項目ごとの扱いの違いに注意が必要です。

• 作成時だけ送る項目: system、tools。継続リクエストに含めるとエラーになります。
• 毎回同じ値で送る項目: model、tool_choice、thinking、context_management、output_config、最上位の cache_control など。値が変わると400エラーになります。
• ターンごとに変えてよい項目: max_tokens、stop_sequences、stream、metadata、service_tier など。

プロンプトキャッシュは自動では有効になりません。各ターンをキャッシュするには、threadのすべてのリクエストに最上位の cache_control を同じ値で付けます。1つのリクエストに付けられるキャッシュのブレークポイントは最大4個で、最上位の指定もその数に入ります。

使う前に知っておきたい制約

• 会話の正本は自社側に置く: 応答を見ても、そのターンが保存されたかは分かりません。全メッセージの控えを持ち、再送の経路を最初から作るよう公式は求めています。SDKのヘルパーが控えを持つのはオブジェクトがメモリ上にある間だけです。
• データの取り扱い: ZDRとHIPAAの対象外です。
• 利用者の統一: 同じAPIキーとワークスペースをthread全体で使うよう案内されています。別の組織、ワークスペース、ユーザーからの継続は失敗の原因になります。
• 拒否された後: 応答の stop_reason が refusal の場合は継続せず、該当のターンを除くか言い換えて新しいthreadを作成します。
• フォールバックモデルの応答: threadはひとつのモデルを保つため、フォールバックモデルが書いた応答は保存されません。その応答のidからは継続できず、会話全体を新しい作成リクエストで送ります。
• ストリーミング: 応答のidは message_start イベントで届きますが、継続するのは message_stop イベントを受け取った後です。
• 思考ブロック: Claude Fable 5.1、Claude Mythos 5.1、Claude Opus 5.5、Claude Sonnet 5.5、Claude Haiku 5.5では、system や tools を変えると会話内の thinking と redacted_thinking のブロックが無効になります。作成リクエストがエラーになることもあるため、変更時はこれらのブロックを除いて送ります。

料金と提供範囲

提供先は次のとおりです。

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

提供状況はベータです。threadを使った場合の料金や、日本での提供条件については、公式の発表では触れられていません。

向いている用途

公式が最も効果の大きい用途として挙げているのは、長く動き続けるエージェントのループです。ターン数が増えるほど、毎回会話全体を送り直す負担が大きくなるためです。

一方、過去の発言を編集する、途中から分岐させる、といった処理ではそのたびに新しいthreadの作成が必要です。ターンの間隔が期限より長く空く場合も、再送が前提になります。

よくある質問

Message threadsを使えば、会話履歴を自分で保存しなくてもよくなりますか？

なりません。threadの保持はベストエフォートで、期限が切れれば継続できなくなります。再送に使うため、全メッセージの控えを自社側で持つ必要があります。

threadの期限が切れたらどうなりますか？

継続リクエストが404エラーを返します。保存しておいた会話全体を、system と tools とともに新しい作成リクエストで送り、その応答のidから続けます。SDKのヘルパーはこの再送を自動で行います。

threadを使うと料金は安くなりますか？

公式の発表では触れられていません。公式が挙げている効果は、リクエストの小ささと、最初のトークンが返るまでの時間です。

threadを使えばプロンプトキャッシュも自動で効きますか？

自動では効きません。キャッシュの仕組み自体はthreadなしの場合と同じで、最上位の cache_control を付けるか、ブレークポイントを自分で指定します。

機密性の高いデータにも使えますか？

ZDRとHIPAAの対象外とされています。これらの条件が必要な業務では対象外である点を踏まえて判断してください。

Claude Managed Agentsのセッションスレッドと同じものですか？

別のものです。Message threadsはMessages APIの機能で、Claude Managed Agentsのセッションスレッドとは異なると公式に明記されています。