Anthropicは11月2日、ClaudeのAPIに「Message threads」を公開ベータとして加えた。長い会話をサーバー側に短時間だけ預かってもらい、2回目以降は新しい発言だけを送ればよいという仕組みだ。

Anthropicの説明では、入力が50万〜100万トークンに達する要求で、最初の文字が返ってくるまでの時間（TTFT）の中央値が約35%短くなる。一方で、料金も、読み込まれるトークンの数も、利用上限も変わらない。速くなるだけで、安くはならない機能である。

この変更の主役は、チャット画面でClaudeを使う人ではない。Claude Codeのようなコーディングエージェントや、自社でClaudeを呼び出して業務の自動化を組む人たちだ。どちらの側に立つかで、取るべき行動がまるで違ってくる。

⚠ 情報の鮮度について
一次情報はAnthropicの公式記事（2026年11月2日付）と、Claude Developer Platformのリリースノート（同日付）、および公式ドキュメントのMessage threadsのページです。公開時点で2日ほどが経過しており、ここでは発表の速報ではなく、選ぶ側・使う側にとっての意味を整理します。機能はベータで、仕様が変わる可能性があります。35%という数字はAnthropicの公表値で、第三者による再現は確認できていません。
Section 01

Message threadsとは何か──毎回の「全文送り直し」をやめる仕組み

ClaudeのAPIには、会話の記憶がない。人間同士のやり取りなら前の発言を覚えているが、APIでは毎回、会話の全文を送り直すのが決まりだった。10回目のやり取りなら、1回目から9回目までの発言を全部つけて10回目の質問を送る。Claudeはそれを頭から読み直し、続きを書く。

短い会話なら問題にならない。だが、コードを読み、ツールを何十回も呼び出し、結果を積み上げていくエージェントでは、会話が数十万トークンに育つ。トークンとは、AIが文章を処理する単位のことで、日本語なら1文字がおよそ1〜2トークンに当たる。数十万トークンを毎ターン送り直せば、通信量も、受け取った側の検査と分割の手間も膨らむ。公式ドキュメントは、送り直しのたびにAPIが全文を検証し、トークンに切り分け直していると説明している。

Message threadsは、この手間を省く。使い方は2段階だ。

01
作成（create）──最初の1回だけ全文を送る

いつもどおり会話の全文とシステムプロンプト、ツールの定義を送り、リクエストに thread の指定を足す。APIは会話とClaudeの返答を、返答のIDに紐づけて預かる。

02
継続（continue）──以降は新しい発言と直前のIDだけ

2回目からは、前回以降の新しいメッセージと「直前の返答のID」だけを送る。システムプロンプトとツールは送らない。サーバーが預かっていた会話に新しい発言をつなぎ、そのうえでモデルを呼ぶ。

対象モデルは広く、Claude Fable 5.1、Opus 5.5、Sonnet 5.5、Haiku 5.5といった現行世代から、旧世代のOpus 4.xやSonnet 4.xまで含まれる。提供先は、AnthropicのClaude APIのほか、AWS上のClaude Platform、Microsoft Foundry、Google Cloud上のClaudeモデル（Anthropic管理）で、いずれもベータ扱いだ。利用には、ベータ用のヘッダー message-threads-2026-08-12 をリクエストごとに付ける。

一言でまとめると──「会話の持ち運びをやめて、サーバーに置いてもらう代わりに、5分で消える前提で使う」機能です。得られるのは返答開始の速さで、料金の安さではありません。
Section 02

約35%速くなるのは、どんな場面か

Anthropicの公式記事は、効果を次のように示している。入力が50万〜100万トークンの要求で、TTFT（リクエストを送ってから最初のデータが返るまでの時間）の中央値が約35%下がる。しかも、Claude Codeの多くの利用者ではこの機能がすでに既定でオンになっているという。

約35% 50万〜100万トークン級の要求でTTFT中央値が短縮（Anthropic公表）
5分 最後の要求からスレッドが失効するまで
1時間 最後の使用から削除されるまでの上限

読み間違えやすい点が3つある。

1つめ。35%は返答の「出だし」の話で、作業が終わるまでの総時間ではない。回答を書き終えるまでの時間は、モデルが文章を生成する速さで決まるため、この機能では縮まらない。

2つめ。数字は中央値であり、対象は50万〜100万トークンという大きな会話に限られる。公式ドキュメントも、利点が大きいのは長いエージェントの繰り返しだと説明している。数千トークンの短いやり取りでは、そもそも送り直しの負担が小さく、体感は変わらないだろう。この点は公式が数値で示しているわけではないので、※観測として扱っておく。

3つめ。条件や測定方法の詳細は、公式記事でも明かされていない。使っているモデルや環境による差は、手元で測るしかない。

Section 03

変わらないもの──料金・上限・読むトークン数

公式ドキュメントには「スレッドは料金もレート制限も変えない」と明記されている。公式記事も、Claudeは毎ターン会話の全文を読むのでトークンの使用量は同じ、標準のトークン料金と既存の上限がそのまま適用される、と述べている。

つまり、削れるのは通信量と前処理の手間であり、Claudeが読むトークンの数ではない。請求書の数字は、機能をオンにしても動かない。

ⓘ プロンプトキャッシュは自動では付かない
料金を下げる手段としては、別に「プロンプトキャッシュ」（同じ前置きの読み込みを安く済ませる機能）があります。公式ドキュメントによれば、スレッドはキャッシュを自動では有効にしません。毎ターンキャッシュを使うには、リクエストごとに最上位の cache_control を指定する必要があります。速さの改善と料金の改善は、別々に設定する仕組みです。

なお、Claude Codeの週の上限のような利用枠は、公式ドキュメントが「レート制限は変えない」と述べているとおり、この機能の対象外だ。使える量が増えるわけではない。

Section 04

5分で消える──設計で踏みやすい3つの落とし穴

サーバーに預けるとは言っても、保管は一時的だ。公式ドキュメントによれば、スレッドは最後の要求から5分で失効し、APIは最後の使用から遅くとも1時間以内に削除する。失効したスレッドを続けようとすると404エラーが返り、全文を送り直して作り直すことになる。ここから、実装で差が出る注意点が3つ出てくる。

項目 作成（最初の1回） 継続（2回目以降）
会話の中身 全文を送る 新しい発言だけ
システムプロンプト・ツール 送る 送ると400エラー
モデル・思考設定など 指定する 同じ値を毎回送る（違うと400エラー）
最大出力トークン数など 指定する ターンごとに変えてよい
A
待ち時間が5分を超えると、速さの利点が消える

人間の承認を待つ工程や、遅い外部ツールの呼び出しで5分を超えると、スレッドは消えている。次の要求は全文の再送になり、それなら最初から使わなかったのと変わらない。機械だけで高速に回る繰り返しに向く機能である。

B
会話の正本は、自分の側に持ち続ける

公式ドキュメントは、会話の正本はあくまで利用者側のアプリだと明言している。しかも、返答がサーバーに保存されたかどうかは、その時点では分からない。分かるのは次の継続要求のときだ。全メッセージの控えを手元に残し、失敗したら送り直す経路を最初から作る必要がある。

C
途中で書き換えられない

スレッドは追記専用で、返答のIDは一度しか継続に使えない。システムプロンプトやツールを変えたい、過去の発言を直したいときは、新しいスレッドを作り直す。分岐させて試す使い方には向かない。

💡 ストリーミングでの注意
返答のIDはストリームの冒頭で届きますが、続きの要求を送れるのは、ストリーム終了の合図（message_stop）を受け取ってからです。早く送ると404エラーになることがあります。
Section 05

あなたの立場別に、何が変わるか

A
Claudeのチャットアプリだけを使う人：変わらない

対象はAPIのMessages機能で、アプリの画面や月額プランの内容は動いていない。今回の記事は、読み飛ばしてよい側にいる。

B
Claude Codeを使う人：すでに恩恵を受けている可能性が高い

公式記事によれば、多くのClaude Code利用者ではこの機能が既定でオンになっている。長い作業で返答の出だしが軽くなったと感じていたなら、理由の一つはこれかもしれない。設定を触る必要は、基本的にない。

C
自社のエージェントをClaudeのAPIで組む人：試す価値が最も大きい

会話が50万トークン級まで育つ設計なら、効果が見込める。ただし、5分の失効・送り直しの経路・固定項目の一致という3つの約束事を守る実装が先に要る。ベータなので、本番の中核に据える前に、同じ入力で前後の応答時間を並べて測っておきたい。

⚠ データの扱いを契約で縛っている組織は要確認
公式ドキュメントによれば、Message threadsは「ゼロデータ保持（送ったデータをAnthropic側に残さない契約）」の対象外です。スレッドの中身（会話、システムプロンプト、ツール）は暗号化されてメモリ上に置かれ、永続的な保存先には書かれず、最後の使用から1時間以内に削除されるとされています。ゼロデータ保持を前提に契約している場合、この機能を有効にしてよいかは、事前に社内の担当者へ確認してください。この機能を使っても、ゼロデータ保持の対象である他の機能の利用には影響しないとも書かれています。
Section 06

編集部の見立て

Editor's Opinion

今回の発表でいちばん興味深いのは、35%という数字そのものより、AnthropicがAPIの「状態を持たない」という素朴な性質に手を入れたことだと考えます。会話を毎回持ち運ぶ設計は単純で、事故が少ない反面、エージェントの時代には重すぎました。そこで会話をサーバーに預かる方向へ寄せたわけですが、保管は5分と1時間という短い期限つきで、正本は利用者側に残すと明言しています。預かる範囲を意図して狭めている、というのが私たちの読みです。

この選び方は、AIを選ぶ側にとって意味があります。サーバー側に会話が溜まる仕組みは、便利になるほど乗り換えにくくなる性質を持つからです。今回の設計は、期限が短く、自分の側にも写しを置く前提なので、少なくとも現時点では、ほかのAPIへ移る道を塞ぐ形にはなっていません。他社の同種機能との比較は別の機会に譲りますが、データ保持の期間と場所を契約や社内規程と突き合わせるという確認の型は、どの会社の機能にも使えます。

一方で、速さが売りの機能が、人の承認待ちのような現実の業務の「間」に弱いことは、導入前に知っておいたほうがよい点です。自動化の設計図の上では連続して動くエージェントでも、実際の職場では誰かの確認で止まります。止まる時間が5分を超える工程が多いなら、恩恵は小さくなります。どちらに当てはまるかは、各社の運用を見ないと判断できません。

Section 07

まとめ

2026年11月2日、AnthropicがClaude APIのMessage threadsを公開ベータにしました。最初の1回だけ会話の全文を送り、以降は新しい発言と直前の返答のIDだけを送る仕組みです。

入力が50万〜100万トークンの要求で、TTFTの中央値が約35%短くなるとAnthropicは公表しています。料金とレート制限は変わらず、Claudeが毎ターン読むトークンの数も同じです。スレッドは最後の要求から5分で失効し、最後の使用から1時間以内に削除されます。

Claude Codeの多くの利用者では既定でオンです。APIで自前のエージェントを組む場合は、会話の控えを手元に持つこと、失効時に全文を送り直す経路を用意すること、ゼロデータ保持の対象外である点を確認することが前提になります。

自社のエージェントで承認待ちやツールの待ち時間が5分を超える場面がどれだけあるか──スレッドを有効にする前に、その実測から始めるのが筋だ。35%の短縮が見込めるのは、最後の要求から5分以内に次の要求が届く繰り返しに限られる。