はじめに
2026年11月2日、Anthropic の Messages API に、会話をサーバー側に保持する message threads がベータ提供されました。
これまでの Messages API はステートレスでした。毎回のリクエストに、過去の会話履歴をすべて含める必要がありました。message threads を使うと、API が会話履歴をサーバー側に保持します。2回目以降のリクエストでは、新しいメッセージだけを送れば済みます。
得られる効果は次の2つです。
- リクエストが小さくなる
- 最初のトークンが返るまでの時間(TTFT)が短くなる
📌 影響を受ける人
- 長い会話を扱うチャットアプリの開発者
- ツール呼び出しを何度も繰り返すエージェントループの実装者
- Claude API、Claude Platform on AWS、Claude Models on Google Cloud(Anthropic managed)、Claude in Microsoft Foundry のいずれかで Messages API を使っている人
今回は ベータ提供で、利用にはベータヘッダーの指定が必要です。既存コードは何も変更しなくても動き続けるため、対応は必須ではありません。ただし、「5分で期限切れ」という仕様があります。採用するなら、そこを考慮した設計が必要です。
変更の全体像
従来と message threads の違い
リクエストフロー
変更内容
概要
| 項目 | 内容 |
|---|---|
| 機能名 | message threads |
| ステータス | ベータ |
| 対象 API | Messages API |
| ベータヘッダー | message-threads-2026-08-12 |
| 主な用途 | 長い会話、エージェントループ |
| 主な効果 | リクエストの小型化、TTFT の短縮 |
| 期限切れ | 最後のリクエストから 5分 |
| 削除 | 最後の使用から 1時間以内 |
提供先
| 提供環境 | 対応 |
|---|---|
| Claude API | ✅ |
| Claude Platform on AWS | ✅ |
| Claude Models on Google Cloud(Anthropic managed) | ✅ |
| Claude in Microsoft Foundry | ✅ |
なぜ効果があるのか
ステートレスな API では、会話が長くなるほど毎回送るデータが増えます。エージェントループでは、ツール呼び出しと結果の往復が数十回になることもあります。その場合、同じ履歴を何度も送り直すことになります。
message threads では、履歴をサーバー側に置きます。クライアントが送るのは差分だけなので、リクエストサイズが小さくなります。そのぶん、TTFT も短くなります。
期限切れの仕様
この機能で最も注意が必要なのは、スレッドの寿命です。
- 最後のリクエストから5分で期限切れになる
- 最後の使用から1時間以内に削除される
⚠️ 注意
5分を超えて間隔が空く処理では、スレッドが期限切れになります。たとえば、ユーザーの入力待ちが長いチャットや、時間のかかる外部処理を挟むエージェントがこれに当たります。こうした処理では、期限切れ後に会話を作り直す処理が必須です。
作り直しには、クライアント側にも会話履歴のコピーが必要です。サーバー側にあるから安心と考えて、手元の履歴を捨ててはいけません。
影響と対応
判断フロー
開発者が取るべきアクション
- 対象を見極める: 長い会話やエージェントループがあるか確認します。短い単発のやり取りが中心なら、効果は限定的です。
-
検証環境で試す: ベータヘッダー
message-threads-2026-08-12を付けて、リクエストサイズと TTFT がどう変わるか計測します。 - 期限切れ対応を実装する: 5分を超えて間隔が空く可能性があるなら、会話の再作成処理を入れます。
- 本番投入は慎重に: ベータなので、仕様が変わる可能性があります。本番に入れる場合は、従来方式にフォールバックできるようにしておくと安全です。
- 利用環境を確認する: 対応環境は上の4つです。それ以外の環境では前提にしないでください。
💡 Tips
チームでCLAUDE.mdを運用しているなら、次のような方針を追記しておくと、AI コーディング支援も一貫した実装をしやすくなります。## Claude API / Messages API の利用方針 - 長い会話やエージェントループでは message threads (ベータヘッダー: message-threads-2026-08-12)の利用を検討する - 2回目以降は新しいメッセージだけを送ればよい - スレッドは最後のリクエストから5分で期限切れ、 最後の使用から1時間以内に削除されるため、 期限切れ時に会話を作り直す処理を実装する - 対応環境: Claude API、AWS、Google Cloud(Anthropic managed)、Microsoft Foundry
コード例
⚠️ 注意
提供された情報には、スレッドの作成方法や識別子の渡し方といった具体的なリクエスト仕様が含まれていません。以下は、公開情報で確認できた範囲(ベータヘッダー名、期限切れの挙動)に沿った設計の骨子です。...の部分と関数名は説明用の仮のもので、実際のパラメータ名は公式ドキュメントで確認してください。
Before: 毎回全履歴を送る(従来)
import anthropic
client = anthropic.Anthropic()
history = []
def chat(user_text: str) -> str:
history.append({"role": "user", "content": user_text})
# 毎回、履歴全体を送る → 会話が長いほどリクエストが大きくなる
resp = client.messages.create(
model="...", # 利用するモデル
max_tokens=1024,
messages=history,
)
text = resp.content[0].text
history.append({"role": "assistant", "content": text})
return text
After: 新メッセージだけ送る + 期限切れ時の再作成(骨子)
import anthropic
client = anthropic.Anthropic()
BETA = "message-threads-2026-08-12" # ベータヘッダー
# 再作成に備え、クライアント側にも履歴を保持しておく
history = []
thread = None # サーバー側スレッドへの参照(取得方法は公式ドキュメント参照)
def send_new_message_only(thread, user_text):
"""2回目以降: 新しいメッセージだけを送る(仮の関数)"""
...
def start_thread_from_history(history):
"""スレッドを作り直す: 保持している履歴から会話を再構築(仮の関数)"""
...
def chat(user_text: str) -> str:
global thread
history.append({"role": "user", "content": user_text})
try:
# 通常は差分のみ送信 → リクエストが小さく、TTFT も短い
text = send_new_message_only(thread, user_text)
except ThreadExpired: # 期限切れ(5分超)を検知した場合(仮の例外)
# 期限切れ → クライアントの履歴から会話を作り直す
thread = start_thread_from_history(history)
text = send_new_message_only(thread, user_text)
history.append({"role": "assistant", "content": text})
return text
ポイントは3つです。
- 履歴はクライアントにも残す: 期限切れで再作成が必要になるためです。
- 期限切れは例外として扱う: エラー時の分岐を最初から設計に含めます。
- ベータヘッダーを一箇所で管理する: GA 時やバージョン更新時に差し替えやすくなります。
まとめ
- Messages API に、会話をサーバー側に保持する message threads がベータで追加されました。
- 利用にはベータヘッダー
message-threads-2026-08-12が必要です。 - 2回目以降は新しいメッセージだけを送ればよく、リクエストが小さくなり、TTFT も短くなります。
- 長い会話やエージェントループで特に効果が見込めます。
- スレッドは最後のリクエストから5分で期限切れになり、最後の使用から1時間以内に削除されます。5分を超えて間隔が空く処理では、会話の作り直し処理が必須です。
- 対応環境は、Claude API、Claude Platform on AWS、Claude Models on Google Cloud(Anthropic managed)、Claude in Microsoft Foundry です。
- 既存コードへの影響はなく、対応は任意です。まず検証環境で、サイズと TTFT の変化を計測するのがおすすめです。
ベータ機能なので、仕様は今後変わる可能性があります。導入前に公式ドキュメントで最新の仕様を確認してください。