AIREITERAnthropicは2026年11月2日、Message Threadsをパブリックベータで公開した。ただし、見出しだけを読むと誤解しやすい。500K〜1Mトークンのリクエストでは、初回トークン生成までの時間（TTFT）の中央値が約35%短くなる一方、トークン料金は変わらない。長時間動くエージェントを運用しているなら、これは転送量を減らす仕組みだ。ただし、アイドル状態が5分続くとスレッドは期限切れになる。
速くなっても料金は同じ。Message Threadsで変わること、変わらないこと
Message Threadsは、Messages APIで一時的に使えるサーバー側の会話状態だ。2026年11月2日にパブリックベータとして提供が始まった。最初のリクエストでthread: { "type": "create" }を指定して履歴全体を送信し、以降は新しいメッセージとprevious_message_idだけをthread: { "type": "continue" }で送る。Anthropicの発表と公式ドキュメントによると、状態は暗号化されたメモリ上に保持され、ディスクには書き込まれない。アイドル状態が5分続くと期限切れになり、最後の利用から1時間以内には削除される。
スレッド内のすべてのリクエストには、anthropic-beta: message-threads-2026-08-12のベータヘッダーが必要だ。料金体系とレート制限は変わらない。Claudeは各ターンで会話全体を読み込むため、入出力トークンの料金は従来どおり。ただし、クライアントからアップロードするデータ量は大幅に減る。
「いい仕組みだけど、トークン料金は下がらないんだよね :( Claudeは毎ターン会話全体を読み込むから、トークン消費量は変わらない」 — 公式ローンチスレッドへの返信、@_navicstein
公式の発表では、500K〜1MトークンのリクエストにおけるTTFTの中央値が約35%短縮されるとしている。トークン料金の割引はない。
Threadsとプロンプトキャッシュの違い
Threadsが減らすのは送信するデータであり、プロンプトキャッシュが減らすのは通常料金で課金される入力だ。Threadsが自動的にキャッシュしてくれるわけではないため、引き続きcache_controlでブレークポイントを指定する必要がある。詳しい連携方法は実装の解説に従う。すべての継続リクエストでトップレベルのcache_controlを維持し、キャッシュ読み取り時の料金は通常の入力料金の0.1倍（Claude Opus 5.5とSonnet 5.5では0.05倍）になる。
ThreadsとManaged Agentのセッションスレッドは別物
検索結果では、2種類の「スレッド」が混同されがちだ。この記事で扱うMessages APIのメッセージスレッドは、リクエストサイズを抑えるための一時的な仕組みで、一覧・取得・削除APIはない。一方、Managed Agentのセッションスレッド（GET /v1/sessions/{session_id}/threads/{thread_id}）は、Anthropicのmanaged-agents API内で実行を管理するスレッドであり、一覧表示・取得・アーカイブのエンドポイントを持つ。子スレッド、イベントストリーム、アーカイブといった記述が出てきたなら、別のAPIを見ている可能性が高い。必要な機能がどちらに属するかは、セッションスレッドのAPIリファレンスで確認してほしい。
スレッドの流れを理解する：作成、継続、期限切れ
実際のスレッドは追記専用だ。最初にコンテキスト全体を付けて作成し、その後は差分を送り、状態を失ったら最初からリプレイする。分岐、編集、巻き戻し、状態確認のAPIは用意されていない。レスポンスごとに新しいidが返され、各idを継続に使えるのは1回だけだ。このセクションのフィールドとエラーに関するルールは、公式ドキュメントおよび実装の解説に基づいている。
作成時は、messages、system、toolsを含む必要な情報をすべて送る。
{
"model": "claude-opus-5-5",
"system": "You are a support agent for Acme. Keep replies short.",
"messages": [{ "role": "user", "content": "Hi! I have a question about an order." }],
"thread": { "type": "create" }
}継続時に送るのは、新しく追加する内容だけだ。通常はユーザーメッセージ、またはtool_resultブロックになる。
{
"model": "claude-opus-5-5",
"messages": [{ "role": "user", "content": "How long does standard shipping usually take?" }],
"thread": { "type": "continue", "previous_message_id": "msg_xxx_from_create" }
}継続リクエストではsystemとtoolsを省略すること。"system": nullと指定しても400エラーになる。ストリーミング中はmessage_stopを受け取ってから次の継続リクエストを送る。継続に使えるIDはmessage_startで届く。
スレッド途中で変更できるフィールド
Anthropicは、作成リクエストの一部をフィンガープリントとして管理している。対象となる値を変更するとthread_fingerprint_mismatchが返り、新しいスレッドを作り直す必要がある。
| グループ | 例 | 継続時のルール |
|---|---|---|
| 作成時のみ | system、tools | 再送しない。nullでも失敗する |
| 固定 | model、tool_choice、thinking、mcp_servers、context_management、output_config、コンテナスキル、トップレベルのcache_controlの扱い | 同じ値を維持する必要がある |
| 変更可能 | max_tokens、stop_sequences、stream、metadata、service_tier | ターンごとに変更できる |
| 毎回再送 | MCPサーバーのURL / 認証トークン、container ID | サーバー側には保存されないため、使用するたびに含める |
拡張思考モデルを使う場合は、さらに注意が必要だ。systemやtoolsを変更すると、過去のthinking / redacted_thinkingブロックが無効になる可能性がある。期限切れ後のフルリプレイで400エラーが返った場合は、古いthinkingブロックを履歴から削除してからリプレイする。内容をそのまま再送しても解決しない。
5分ルールと、必ず実装すべきリプレイ処理
Threadsはベストエフォートの仕組みとして扱おう。完全な履歴、system、tools、ファイル参照はローカルに保持しておく必要がある。次の継続リクエストが成功するまで、サーバー側に保存されているとは考えないほうがいい。ファイルは参照として保持されるため、スレッドの途中でファイルを削除すると継続に失敗する。
期限切れのタイマーは、保存に成功したレスポンスを受け取るたびにリセットされる。アイドル状態が5分続くと、次の継続リクエストは404を返す。その場合は会話全体を新しいcreateとして送り直す。データは最後の利用から1時間以内には削除される。
| HTTP | コード | 起きたこと | 対処 |
|---|---|---|---|
| 404 | thread_not_found | 期限切れ、保存失敗、キーやワークスペースの不一致、テキスト専用スレッドへの最初の画像追加、フォールバックモデルによる応答、またはレスポンス生成中 | キー、ワークスペース、設定を確認し、履歴全体を新しいcreateとしてリプレイする |
| 400 | thread_fingerprint_mismatch | 固定フィールドが変更された | 元の値に戻すか、新しいスレッドを開始する |
| 400 | thread_already_continued | そのprevious_message_idはすでに使用済み | 最新のidから継続する |
| 400 | thread_continue_in_flight | 同じIDに対して並行した継続リクエストを送った | 処理を待ち、新しいIDを使う。難しければリプレイする |
| 400 | thread_unsupported_request | 未対応の設定（例：キャッシュブレークポイントが4個を超える、バッチ利用） | 設定を削除するか、スレッドなしで送信する |
ドキュメントの概要によれば、スレッド関連の失敗リクエストはモデル実行前に処理される。そのためトークンは消費せず、期限切れタイマーもリセットしない。次のターンを受け付ける前に、最後に成功したレスポンスIDをアトミックに保存しておこう。ツール操作に副作用がある場合は、リプレイが二重実行されないよう冪等性も確保する必要がある。
Pythonでのリプレイ例。確認済みのthread_not_foundだけを処理し、フィンガープリント不一致、同時実行、未対応リクエストのエラーは別分岐で扱う。
try:
resp = client.beta.messages.create(
model="claude-opus-5-5",
messages=[new_msg], # delta only
thread={"type": "continue", "previous_message_id": last_id},
extra_headers={"anthropic-beta": "message-threads-2026-08-12"},
)
except NotFoundError: # thread_not_found after checking identity/config
resp = client.beta.messages.create(
model="claude-opus-5-5",
system=SYSTEM, tools=TOOLS,
messages=full_history + [new_msg], # you stored this
thread={"type": "create"},
extra_headers={"anthropic-beta": "message-threads-2026-08-12"},
)プロキシとキーのローテーションで起きる404
ここからは公式ドキュメントではなく、運用者から報告されている挙動だ。スレッドは作成時の組織、ワークスペース、認証情報にひも付く。リクエストごとにAPIキーを切り替えるリレーでは、キーAで作成したスレッドをキーBで継続することになる。すると期限切れとまったく同じ404が発生し、レイテンシ短縮の恩恵がないまま、毎回フルリプレイを繰り返す。
「threadは作成したkeyとworkspaceにひも付いている。keyを変えると404 thread_not_foundになる。中継サーバーがkeyをローテーションすると、まず404になってから全量再送される」 — @ak12kpoot（プロキシ挙動に関する中国語の開発者メモ）
1つのスレッドでは同じキーを固定して使うか、キーをプールする経路ではThreadsを無効にしよう。
対応環境、制約、今すぐ移行すべきケース
Message Threadsは、Claude API、AWS上のClaude Platform、Anthropicが管理するGoogle Cloud Claude Models、Microsoft FoundryのClaudeで利用できる。ベータ対象のすべてのモデルが含まれており、別途モデルの許可リストやウェイトリストは案内されていない。
ローンチ時の計画では、使える場所よりも使えない機能のほうが重要になる。
| 項目 | 対応状況 |
|---|---|
| Amazon Bedrock | 非対応 |
| Message Batches | 非対応。バッチ内のスレッドアイテムは失敗する |
| トークンカウントエンドポイント | 非対応。履歴全体を自分で数える必要がある |
| コンパクション / コンテキスト編集 | 非対応（keep allを指定したclear_thinkingを除く） |
| ゼロデータ保持、HIPAA対応、推論フック | 対象外 |
| スレッド管理API | なし。スレッドの一覧表示、読み取り、削除はできない |
導入判断のチェックリスト
- 今すぐ使う: アクティブなコーディングエージェント、スクリーンショットを扱うコンピュータ操作ループ、または5分未満の間隔で数十ターン実行するドキュメント中心の処理。プロンプトキャッシュとリプレイ処理を組み合わせること。
- 現時点では見送る: 人間のペースで進むチャット、途中で長く停止するワークフロー、バッチ処理、ZDR/HIPAA要件のある処理、Bedrockへのデプロイ。
- 組み合わせる場合の注意: すべてのリクエストに付けるトップレベルの
cache_controlは、4個のブレークポイント制限に含まれる。create時のsystem/toolsに設定したブレークポイントも、すべてのcontinueで再びカウントされる。上限を超えるとthread_unsupported_requestになるため、両方を有効にする前にブレークポイントを整理しておこう。
関連記事：Claude API料金ガイド 2026、Claude Skills APIガイド。
FAQ
必要なベータヘッダーとパラメータは？
スレッド内のすべてのリクエストでanthropic-beta: message-threads-2026-08-12を送る。最初の呼び出しではthread: { "type": "create" }を指定し、2回目以降はthread: { "type": "continue", "previous_message_id": "<last response id>" }を使う。
スレッドの期限が切れるとどうなる？
次のcontinueが404のthread_not_foundを返す。messages全体と、最初に指定したsystem/toolsを新しいcreateとして再送する。期限切れはアイドル状態が5分続いた場合に発生し、最後の利用から1時間以内には削除される。
スレッドの一覧表示、確認、削除はできる？
できない。Messages APIのスレッドには管理APIが用意されていない。永続的な記録として残るのは、ローカルに保存した履歴だけだ。
Amazon Bedrockで使える？
使えない。対応しているのはClaude API、AWS Claude Platform、Microsoft Foundry、Anthropicが管理するGoogle Cloud。Bedrockでは、これまでどおり履歴全体を送信する方式を使う必要がある。
スレッド途中でsystem promptやtoolsを変更できる？
できない。新しいsystem/toolsでスレッドを作り直す必要がある。continueで変更後の値を送るとthread_fingerprint_mismatchになる。model、tool_choice、thinkingの設定も同様だ。
ストリーミング、ツール、MCPには対応している？
対応しているが、いくつかルールがある。次の継続リクエストはmessage_stopを受け取ってから送る。MCPのURLとトークン、container IDは毎ターン再送する。また、fallbacksはすべてのリクエストに含めるか、すべてから外すこと。フォールバックモデルが生成したレスポンスは保存されないため、リプレイが必要になる。