Anthropicが長い会話の応答開始を35%速める新機能を公開しました。
Message Threadsとは、2ターン目以降は前回の応答IDと新しいメッセージだけを送れば会話を続けられる、Claude APIのベータ機能のことです。 Anthropicの発表によると、50万〜100万トークン規模のリクエストでは、最初のトークンが返るまでの時間(TTFT)の中央値が約35%短くなりました。長く動き続けるAIエージェントほど効果が大きい仕組みです。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)が解説します。

Message Threadsで何が変わったか:毎ターンの全文再送が不要に
結論から言うと、Message Threadsは「会話履歴を毎回まるごと送り直す」というAPIの前提をなくしました。これまでのMessages APIはステートレスで、10ターン目のリクエストには1〜9ターン目の履歴をすべて含める必要がありました。そのたびにAPI側も全文を受け取り、検証し、トークン化し直していたため、会話が長くなるほど応答の立ち上がりが遅くなっていました。
公式ドキュメントによると、使い方は次の流れです。
- 最初のリクエストで
threadパラメータを付け、会話全体を送ってスレッドを作る - 2回目以降は、前回の応答IDと新しく増えたメッセージだけを送る
- API側はメモリ上に保持したスレッドに新しいターンを足して処理する
ベータヘッダーは message-threads-2026-08-12 で、SDKにはこのヘッダー付与や再送を代行するヘルパーも用意されています。The Decoderの記事によると、Anthropicは本機能をClaude Codeの大半のユーザーで既定でオンにしたうえで、35%短縮という数字を計測しています。
提供範囲も広く、Claude API本体に加えてClaude Platform on AWS、Microsoft Foundry、Google Cloud上のClaude Models(Anthropic管理)のすべてでパブリックベータとして使えます。対応モデルはClaude Opus 5.5、Sonnet 5.5、Haiku 5.5などの5系に加え、Opus 4.5〜4.8、Sonnet 4.5・4.6、Haiku 4.5までと幅広く、既存の実装を大きく変えずに試せます。
なぜ重要か:速くなるのは「待ち時間」で、料金は変わらない
押さえるべき点は、Message Threadsが縮めるのは待ち時間であって、トークン料金ではないことです。Claudeは毎ターン会話全体を読み直すため、消費トークン数は従来と同じで、通常のトークン単価と既存のレート制限がそのまま適用されます。費用を下げたい場合は、これまでどおりプロンプトキャッシュを自分で設定する必要があります。ドキュメントでも「スレッドがプロンプトを自動でキャッシュするわけではない」と明記されており、cache_control のブレークポイントは1リクエスト4個までという制約も同じです。
運用面では3つの制約があります。1つ目は寿命です。スレッドは最後のリクエストから5分で失効し、遅くとも最終利用から1時間以内に削除されます。失効後に続きを送ると404エラーが返るため、クライアント側で会話の控えを持ち、全文を送り直して新しいスレッドを作る必要があります。2つ目はデータ保持です。スレッドの中身はサーバー管理の鍵で暗号化され、ディスクには書き込まれないものの、ゼロデータ保持(ZDR)の対象外とされています。ZDR契約を前提に社内AIを組んでいる企業は、法務・情報システム部門との確認が必要です。3つ目は、まとめて非同期処理するMessage Batchesでは使えない点です。
業界全体で見ると、APIが「毎回すべて送るステートレス型」から「サーバー側に会話の状態を短時間持つ型」へ寄ってきた流れの一つです。OpenAIもResponses APIで前回の応答IDを指定して会話を続ける方式を提供しており、長時間動くエージェントの応答速度をどう保つかが、各社の主な競争点になりつつあります。
今後の動き:エージェントと画像の多い業務ほど恩恵が大きい
Anthropicが効果の大きい用途として挙げたのは、長時間動くコーディングエージェント、画面のスクリーンショットを何枚も扱うComputer Useエージェント、文書や画像を大量に読ませるワークフローの3つです。Computer Useでは、過去のスクリーンショットがスレッド側に残るため、毎ターン画像をアップロードし直さずに済みます。
今後の注目点は、ベータが外れる時期と、5分という失効時間が延長されるかどうかです。人の確認を挟んで数十分止まるような業務フローでは、現状の仕様だとスレッドが切れて全文再送になるため、恩恵が限られます。プロンプトキャッシュには1時間保持の選択肢があることから、スレッド側にも長い保持時間が用意されるかは要確認です。
日本のEC事業者への影響は、Claude APIで自社ツールを作っている場合に限られます。たとえば数百SKUの商品画像を読み込ませて説明文を連続生成する社内エージェントや、受注データを順番に確認させる業務ボットは、会話が長くなるほど速さの差が出やすい用途です。既存の実装でSDKのスレッド用ヘルパーに切り替え、待ち時間とトークン消費をベータ前後で比べてみると、効果を判断しやすくなります。
まとめ
Message Threadsは、Claude APIで2ターン目以降の送信量を差分だけに減らし、長い会話の応答開始を約35%短くするベータ機能です。料金は変わらず、5分で失効し、ZDRとMessage Batchesの対象外という制約があります。長時間動くエージェントを運用している企業は、プロンプトキャッシュと組み合わせて速度と費用の両面を見直すとよいでしょう。
参考文献
- Anthropic「Message threads」発表記事
- Claude Platform ドキュメント「Message threads」
- Claude Platform ドキュメント「Prompt caching」
- The Decoder「Anthropic’s Message Threads cut time to first token by 35 percent for long conversations」
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
引用元: The Decoder
【監修】齋藤竹紘(株式会社オルセル代表 / 19年・5,000社のEC支援実績)

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。