Anthropicは2026年11月2日、Claude APIの「Message threads」をパブリックベータで公開しました。会話の全体を最初に送り、その後は新しいメッセージと直前の返答IDを送ることで会話を継続できます。長い会話で、Claudeが返答を始めるまでの待ち時間を減らす仕組みです。[1][2]
変わるのは、会話を毎回送り直す負担です。 会話が長くなったAIエージェントほど、資料、操作結果、過去のやり取りを再送する量が増えます。Message threadsは、その往復を軽くします。本記事では、仕組み、効果が出る場面、料金やキャッシュとの違い、導入条件を整理します。
情報は2026年11月3日時点の公式発表・仕様・公開SDKに基づきます。速度の数値はAnthropicの計測であり、CAGがClaude APIを実行して測った結果ではありません。
01 Message threadsで何が変わるか
APIとは、アプリやプログラムから外部の機能を呼び出すための窓口です。ClaudeのMessages APIでは、通常、アプリが過去のやり取りを含む会話をリクエストに載せて送ります。開発作業ならファイルの内容やツールの実行結果、文書を扱う作業なら資料や追加の質問が、会話に積み上がります。[1]
Message threadsを使うと、API側が会話を短時間保持します。アプリは初回に会話の全体を送り、次からは、前の返答以降に増えた内容だけを送れます。送られてこなかった過去の会話は、API側でつなぎ直してからモデルに渡します。 モデルが参照する文脈を短くする機能ではありません。[3]
| 比較する点 | 毎回履歴を送る方式 | Message threadsを使う方式 |
|---|---|---|
| 最初のリクエスト | 会話全体を送る | 会話全体を送り、スレッドを作る |
| 次のリクエスト | 過去の会話と新しい内容を送る | 新しい内容と直前の返答IDを送る |
| 過去の文脈 | アプリが毎回送り直す | APIが保持した会話と結合する |
| 履歴の正本 | アプリが管理する | 引き続きアプリが管理する |
これは、APIを利用するアプリの通信方法の変更です。自社の業務アプリにClaudeを組み込む開発者や、長い作業を続けるエージェントを運用するチームが対象になります。公式発表では、多くのClaude Code利用者に対して既定で有効になっているとも説明されています。[1]
02 会話を差分でつなぐ仕組み
最初のリクエストでは、通常の会話に加えてthreadという設定を付け、type: "create"でスレッドを作ります。APIからは通常どおり返答とIDが返ります。次のリクエストでは、type: "continue"とprevious_message_idでそのIDを指定し、新しいメッセージだけを送ります。以降は、毎回いちばん新しい返答のIDを使います。[3]
新しいメッセージには、利用者の次の質問だけでなく、エージェントが呼んだツールの実行結果も含められます。「資料を読む→内容を整理する→追加の資料を読む」と処理が続く場合も、前のターンから増えた内容をつないでいく形です。
IDを送るだけで、ほかの設定がすべて不要になるわけではありません。 何を初回だけ送り、何を毎回そろえるかは、項目ごとに決まっています。[3]
| 項目の扱い | 主な例 | 継続リクエストでの送り方 |
|---|---|---|
| 初回に設定するもの | system、tools | 継続時には含めない。初回の値を引き継ぐ |
| 同じ値を使うもの | model、thinking、ベータ指定など | 毎回送り、初回と値をそろえる |
| ターンごとに変えられるもの | max_tokens、streamなど | 必要に応じて変更できる |
systemはAIへの基本指示、toolsはAIが利用する道具の定義です。たとえば、途中で基本指示やモデルを変える場合は、会話全体を載せて新しいスレッドを作ります。過去の返答から会話を分岐する場合も、新規作成に切り替えます。各返答IDを継続に使えるのは一度です。[3]
スレッドが失効していると、継続の要求に404エラーが返ることがあります。そのときは、アプリが保存している会話全体から作り直して再開します。公式SDKには、この再送を扱う補助機能が用意されています。[6]
03 どんな仕事で効果があるか
効果を捉える指標は、リクエストを送ってから最初の出力が届くまでの時間です。公式資料ではTTFT（Time to First Token）と呼んでいます。トークンは、AIが文章などを処理するときの単位です。
Anthropicは、Claude Codeの50万〜100万トークンのリクエストで、TTFTの中央値が約35％低下したと発表しています。対象は大きな文脈を持つリクエストであり、「すべての回答が35％早く終わる」という計測ではありません。回答全体の生成時間や業務の完了時間とは、分けて読み取る必要があります。[1]
公式発表で挙げられている利用場面は、次のような連続作業です。
- 長い開発作業：コードや実行結果が増えるたびに、過去の会話を送り直しているエージェント。
- 画面操作のエージェント：スクリーンショットを文脈に含め、何度も操作と確認を繰り返す処理。
- 文書・画像の多い作業：複数の資料を参照しながら、追加の質問や処理を続けるアプリ。
いずれも、会話に多くの情報を持ち、短い間隔で次のリクエストを送る場面です。履歴の送信、検証、トークン化で繰り返していた作業を減らせるため、返答開始までの負担を抑えられます。[3]
たとえば社内文書を読むアシスタントであれば、資料の読み込み後に質問を重ねる工程が試す対象になります。これは業務への当てはめ例であり、CAGが実装・測定した事例ではありません。自社で比較する際は、最初の出力までの時間と、回答が出そろうまでの時間を別々に記録すると、利用者が感じる変化を見分けやすくなります。
04 料金・キャッシュ・長期記憶との違い
送るリクエストが小さくなっても、Claudeは各ターンで会話全体を読みます。Message threadsを使うこと自体では、トークン使用量は減りません。 公式仕様でも、料金とレート制限は変わらないとされています。通信量の縮小を、そのままAPI料金の削減率には置き換えられません。[1][3]
ここで分けたいのが、プロンプトキャッシュです。これは、繰り返し使う入力の処理結果を再利用する仕組みです。Message threadsは会話の送り方、キャッシュは再利用する入力の扱いを受け持ち、併用できます。ただし、スレッドを有効にしただけでキャッシュまで自動設定されるわけではありません。cache_controlなどを使い、キャッシュの条件に合わせて設定します。[3][4]
| 仕組み | 主に受け持つこと | 別に確認すること |
|---|---|---|
| Message threads | 会話の再送を減らす | 失効時に会話を送り直せるか |
| プロンプトキャッシュ | 繰り返し使う入力の処理を再利用する | 対応条件、保持時間、キャッシュの料金 |
| アプリの履歴保存 | 会話の正本を管理し、後から再開する | 保存期間、利用者ごとの管理、復元方法 |
Message threadsが一時的に会話を保持していても、自社アプリによる履歴管理は引き続き必要です。スレッドを一覧取得・読み出し・削除するAPIは用意されていません。日をまたいだ問い合わせ対応や、利用者が戻ってきたときの再開に必要な履歴は、アプリ側で保持します。[3]
05 導入前に確認すること
2026年11月3日時点で、Message threadsはClaude API、Claude Platform on AWS、Claude Models on Google Cloud（Anthropic managed）、Microsoft Foundryでベータ提供されています。各リクエストにはmessage-threads-2026-08-12というベータ指定を付けます。この指定名の日付と、今回の公開発表日である11月2日は別です。[2][3]
保存の扱いは、次のように整理できます。会話の有効期限と、サーバーから削除される期限は別の条件です。[3][5]
| 確認する点 | 公式仕様 | アプリ側の準備 |
|---|---|---|
| 継続の有効期限 | 最後のリクエストから5分で失効。継続はベストエフォート | 期限内でも復元が必要になる前提で、履歴を保持する |
| データの削除 | 最後の使用から遅くとも1時間以内に削除 | 会話の長期保存先として利用しない |
| 保持の方法 | 暗号化したメモリ内に保持し、永続ストレージには書き込まない | 一時保持されるデータの範囲を確認する |
| データ保持ゼロの条件 | ZDRの対象外 | 自社のデータ取扱条件と照らし合わせる |
ZDRは、Zero Data Retention（データ保持ゼロ）というデータ取扱条件です。メモリ内の一時保持も保存条件として確認する必要があり、「ディスクに書かないからZDR対象」とは扱えません。スレッドの利用が、ほかのZDR対象機能の扱いを変えるわけではありません。[5]
公式SDKの補助機能は、保持している会話からスレッドを作り直せます。ただし、その補助機能が持つ会話はメモリ内にあり、プロセスが終わった後まで永続保存してくれるものではありません。アプリが再起動した後にも会話を続けるなら、別途保存した履歴から戻せるようにします。[3][6]
導入時には、次の点を一つの業務フローで確かめると、使える範囲を判断できます。
- 長い会話で、返答開始までの待ち時間が実際に減るか。
- 期限切れや通信中断の後に、保存した履歴から再開できるか。
- 基本指示、道具、モデルを変える際に、新しいスレッドへ切り替えられるか。
- 一時保持される業務データが、自社の利用条件に合っているか。
Message threadsは、長い作業を続けるAIの通信を軽くする機能です。会話の正本をアプリが持ち、必要なときに再送できる形にすると、待ち時間の短縮と会話の継続を両立する設計に使えます。
出典・確認範囲
- Anthropic公式発表：Make long-running agents faster with message threads。2026-11-02発表。約35％はClaude Codeの50万〜100万トークンのリクエストにおけるTTFT中央値の低下で、Anthropicの計測。CAGによる再測定ではありません。2026-11-03確認。
- Claude Platform公式リリースノート。2026-11-02欄のベータ提供、対応プラットフォーム、有効期限・削除期限を参照。2026-11-03確認。
- Message threads公式仕様。作成・継続・復元、設定項目、料金、制限、保存条件を参照。2026-11-03確認。
- Prompt caching公式仕様。キャッシュの役割、設定と料金の区別を参照。2026-11-03確認。
- API and data retention公式資料。Message threadsのZDR対象外、一時保持と削除条件を参照。2026-11-03確認。
- Anthropic Python SDKのthreads実装。公式ガイドのSDK補助機能の説明と併せて参照。業務例・図版は説明用で、CAGによるAPI実行結果ではありません。2026-11-03確認。
