メッセージスレッド

「message thread」（メッセージスレッド）を使用すると、リクエストは小さくなり、「time to first token」（最初のトークンまでの時間）は会話が長くなっても低く安定した状態に保たれます。スレッドは、長いエージェントループで最も役立ちます。スレッドがない場合、各ターンで会話全体が再度アップロードされ、APIはそのすべてを再度検証してトークン化します。スレッドを使用すると、その作業の大部分は新しいターンのみが対象になります。

「message thread」（メッセージスレッド）は、会話を短時間サーバー上に保持します。完全な会話を、システムプロンプトとツールとともに最初に一度送信します。以降の各ターンでは、新しいメッセージと前回のレスポンスのidのみを送信します。APIはモデルを呼び出す前に会話を再構築します。Messages APIリクエストにthreadというパラメータを1つ追加するだけです。レスポンスは通常のメッセージです。

メッセージスレッドの仕組み

• 作成。 現在と同じように、会話全体、system、tools を含めて最初のリクエストを送信し、"thread": {"type": "create"} を追加します。APIは、Claudeの返信を含む会話を、レスポンスの id の下に保存します。
• 継続。 前回のレスポンス以降のメッセージのみを送信し、"thread": {"type": "continue", "previous_message_id": "<previous id>"} を追加します。system と tools はリクエストから除外してください。スレッドは作成リクエストの値を保持します。次のターンには、新しいレスポンスの id をそれぞれ使用します。
• リプレイ。 スレッドはベストエフォートです。スレッドの有効期限は最後のリクエストから5分後に切れ、APIは最後の使用から1時間以内にスレッドを削除します。APIがレスポンスを保存するたびに、この5分間がリセットされます。APIがスレッドを継続できなくなった場合、継続リクエストは404エラーを返します。新しい作成リクエストで会話全体を再度送信し、そのレスポンスの id から継続してください。SDKのスレッドヘルパーは、このリプレイを自動的に行います（SDKヘルパーの動作を参照）。フォールバックモデルからのレスポンスの後については、スレッドでフォールバックを使用するを参照してください。

会話の信頼できる情報源（source of truth）は、引き続きアプリケーション側にあります。すべてのメッセージのコピーを独自に保持し、最初からリプレイパスを構築してください。作成リクエストと 継続リクエストのどちらに対するレスポンスも、APIがそのターンを保存したかどうかを示しません。それが判明するのは次の 継続リクエストの時点です。SDKのスレッドヘルパーは、ヘルパーオブジェクトが存在する間このコピーをメモリ内に保持しますが、それ以外の場所には保存しません。会話をプロセスよりも長く存続させる必要がある場合は、独自のコピーを保持してください。

SDKでスレッドを使用する

SDKには、スレッドリクエストを構築するスレッドヘルパーがあります。Messagesリクエストと同じフィールドで作成し、1ターンずつ送信します。ヘルパーは会話全体をメモリに保持します。

この例には2つのターンがあります。ヘルパーは最初のターンでスレッドを作成し、2番目のターンでそれを継続し、ベータヘッダーも自動的に追加します。トップレベルのcache_controlはオプションです。これは各ターンでプロンプトキャッシングを要求します（スレッドでのプロンプトキャッシングを参照）。これがない場合でも、以降の各ターンは新しいメッセージのみを送信しますが、自分でキャッシュブレークポイントを追加しない限り何もキャッシュされません。

client = anthropic.Anthropic()

# ヘルパーを作成します。この呼び出しではリクエストは送信されません。
thread = client.beta.messages.thread(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    system="You are a support agent for Acme. Keep replies short.",
)

# ターン1: ヘルパーがスレッドを作成し、会話全体を送信します
thread.send({"role": "user", "content": "Hi! I have a question about an order."})

# ターン2: ヘルパーがスレッドを継続し、新しいメッセージのみを送信します
second = thread.send(
    {"role": "user", "content": "How long does standard shipping usually take?"}
)

for block in second.content:
    if block.type == "text":
        print(block.text)

threadフィールドを自分で送信する

cURL、CLI、またはSDKの通常のcreateメソッドなどを使用してスレッドリクエストを自分で構築するには、各リクエストにthreadフィールドを追加します。

スレッドのすべてのリクエストでmessage-threads-2026-08-12ベータヘッダーを送信してください。

この例では、最初のターンでスレッドを作成し、2番目のターンでそれを継続します。トップレベルのcache_controlは各ターンでプロンプトキャッシングを要求します。これは、会話がキャッシュ可能な最小長より長くなった時点で有効になります。

client = anthropic.Anthropic()

# ターン1: 会話全体を送信してスレッドを作成します
first = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    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"},
    betas=["message-threads-2026-08-12"],
)

# ターン2: 新しいメッセージとターン1のレスポンスのidのみを送信します。
# systemとtoolsは省略します。スレッドがそれらを保持します。
second = client.beta.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    cache_control={"type": "ephemeral"},
    messages=[
        {"role": "user", "content": "How long does standard shipping usually take?"}
    ],
    thread={"type": "continue", "previous_message_id": first.id},
    betas=["message-threads-2026-08-12"],
)

for block in second.content:
    if block.type == "text":
        print(block.text)

各リクエストで送信するもの

APIは、MCPサーバーのURL、MCP認可トークン、またはコンテナのidを保存しません。mcp_serversとcontainerは、それらを使用するすべてのリクエストで送信してください。MCP認可トークンはリクエスト間で変更できます。

SDKのスレッドヘルパーは、継続リクエストから system と tools を自動的に除外し、固定フィールドを毎ターン再送信します。

サーバーサイドフォールバックを使用する場合は、fallbacksフィールドをスレッドのすべてのリクエストで送信するか、まったく送信しないかのどちらかにしてください。スレッドでフォールバックを使用するを参照してください。

作成時のみのフィールドまたは固定フィールドを変更するには、新しいスレッドを開始します。新しい値を指定した作成リクエストで完全な会話を送信してください。

Claude Fable 5.1、Claude Mythos 5.1、Claude Opus 5.5、Claude Sonnet 5.5、Claude Haiku 5.5では、systemまたはtoolsを変更すると、会話内にすでにあるthinkingブロックとredacted_thinkingブロックが無効になり、作成リクエストが400エラーを返す可能性があります。これを回避するには、送信する会話からすべてのthinkingブロックとredacted_thinkingブロックを除外してください。その場合、モデルは以前の推論なしで応答します。編集とみなされるもの、prefix_mismatch_behaviorが未設定の場合、および無効なブロックに対するAPIの処理を参照してください。

継続リクエストでは新しいメッセージのみを送信してください。APIは、それらをすでに保持しているメッセージと照合しません。再送信したメッセージは会話内に2回現れる可能性があり、またはリクエストがエラーを返す可能性があります。たとえば、前回のレスポンスで始まる継続リクエストはエラーを返します。

新しいメッセージは通常 user メッセージで始まります。これは次のユーザーターン、または前回のレスポンスの tool_use に応答する tool_result ブロックです。レスポンスが stop_reason: "pause_turn" で停止した場合は、そのレスポンスの id からの継続リクエストと空の messages リスト（"messages": []）で再開してください。そのリクエストが404エラーを返した場合は、一時停止したレスポンスを含む会話全体を新しい作成リクエストでリプレイしてください。ターンが一時停止している間は新しい user メッセージを送信しないでください。APIはそれを拒否します。SDKのスレッドヘルパーでは、メッセージなしで send() を呼び出してください。ヘルパーがこのリクエストを送信し、404エラーの場合はリプレイします。

スレッドは追記専用であり、各レスポンスのidは一度だけ継続できます。常にスレッドの最新のレスポンスidから継続してください。以前のメッセージを編集または分岐させる場合は、作成リクエストで新しいスレッドを開始してください。以前のターンを要約に置き換える場合は、会話をコンパクションするを参照してください。

スレッドでのプロンプトキャッシング

スレッドはプロンプトを自動的にキャッシュしません。プロンプトキャッシングはスレッドがない場合と同じように動作します。キャッシュブレークポイントの配置場所は自分で選択します。

各ターンをキャッシュするには、前述の例のように、スレッドのすべてのリクエストでトップレベルのcache_controlを送信してください。APIはこれを、各リクエストのmessagesのうちキャッシュ可能な最後のブロックに適用します。これにより、各ターンは以前の会話をキャッシュから読み取り、新しいターンをキャッシュに書き込みます。トップレベルのcache_controlは固定フィールドです。すべてのリクエストで同じ値を送信してください。

ブロックにcache_controlブレークポイントを自分で配置することもできます：

• 作成リクエストで送信したブレークポイントは、tools、system、または最後のメッセージブロックより前のメッセージブロックに置かれている場合、以降のすべてのターンで引き続き機能します。リクエストの messages の最後のブロックに置かれたブレークポイントは、そのリクエストでキャッシュを書き込みます。新しいターンごとにキャッシュするには、すべてのリクエストでブレークポイントを送信してください。ブレークポイントのないリクエストでも、会話の一部をキャッシュから読み取る場合があります。
• 継続リクエストでは以前のメッセージを再送信できないため、送信後にブレークポイントを移動または削除することはできません。
• thread を含むリクエストには、最大4つの cache_control ブレークポイントを含めることができます。トップレベルの cache_control は1つとしてカウントされます。作成リクエストの system と tools にあるブレークポイントは、継続リクエストのたびに再度カウントされます。保存済みの以前のメッセージにあるブレークポイントはカウントされません。ブレークポイントが1つでも多すぎると、コード thread_unsupported_request を含む400エラーが返されます。
• メッセージブロックに自分でブレークポイントを配置する場合は、新しい 作成リクエストで会話をリプレイする際に以前のメッセージからブレークポイントを削除し、最後のブロックに1つ残して、リクエストが4つの上限内に収まるようにしてください。

ストリーミング

スレッドはストリーミングで動作します。レスポンスのidはmessage_startイベントで届きますが、そこから継続するのはmessage_stopイベントを受信した後にしてください。それより前に送信された継続リクエストは404エラーを返す可能性があります。

継続リクエストのストリームがmessage_stopの前に切断された場合は、同じ継続リクエストを再度送信してください。そのリクエストがthread_already_continuedまたはthread_continue_in_flightエラーを返した場合は、新しい作成リクエストで完全な会話をリプレイしてください。

サーバーがまだレスポンスを生成している間、またはサーバーがそれを保存した後に、接続が切断された可能性があります。そのため、APIは再試行を拒否することがあります。リプレイは常に安全です。

SDKのスレッドヘルパーは、ストリームが切断された後に継続リクエストを再試行しません。SDKヘルパーの動作を参照してください。

スレッドを継続できない場合の復旧

APIがスレッドを継続できない場合、継続リクエストはerror.details.error_codeがthread_not_foundに設定された404エラーを返します。レスポンスは理由を示しません。原因には次のものがあります：

• スレッドの有効期限が切れた。
• APIが前のターンを提供したが、保存しなかった。たとえば、APIはmax_tokensによって途中で切れたツール呼び出しで終わるレスポンスを保存しません。
• フォールバックモデルが前回のレスポンスを書いた。スレッドでフォールバックを使用するを参照してください。
• 前回のレスポンスがまだ生成中である。
• リクエストが異なる組織またはワークスペースから送信された。
• リクエストが、スレッドを作成したものとは異なるユーザーまたはサービスアカウントから送信された。ワークスペースキー（レガシー）で作成されたスレッドはそのキーに紐づくため、スレッド全体で同じキーを使用してください。
• 新しいメッセージが、保存された会話が受け入れられないものを追加している。たとえば、画像がなかった会話に最初の画像を追加すると、このエラーが返される場合があります。

復旧するには、手元のコピーから会話全体を、system と tools を含めて新しい作成リクエストで送信します。SDKのスレッドヘルパーはこの作成リクエストを自動的に一度送信し、その際に以前のターンの cache_control ブレークポイントを省略します。コピー内の以前のメッセージに cache_control ブレークポイントが含まれている場合は、先にそれらを削除してください（スレッドでのプロンプトキャッシングを参照）。その後、新しいレスポンスの id から継続します。フォールバックモデルが前のレスポンスを作成した場合は、スレッドでフォールバックを使用するを参照してください。所有権に関する原因を排除するには、スレッドのすべてのリクエストで同じAPIキーとワークスペースを使用してください。Claude Platform on AWSでは、スレッドのすべてのリクエストに、そのスレッドを作成したIAMロールまたはIAMユーザーの認証情報で署名してください。

存在しないモデルへのリクエストも404エラーを返すため、リプレイする前にerror.details.error_codeを確認してください。

リプレイ直後の継続リクエストが依然として404エラーを返す場合、APIがその会話（たとえば非常に大きな会話）を保存できない可能性があります。thread なしで送信してください。SDKのスレッドヘルパーは、unsupported_request_behavior を continue_unthreaded に設定して作成した場合にこれを行います。それ以外の場合は、ターンごとにリプレイします。

拒否の後

レスポンスに stop_reason: "refusal" がある場合は、スレッドを継続しないでください。APIはすでに拒否されたターンを保持している可能性があり、継続リクエストではそれを削除できません。拒否の原因となったターンを省略するか言い換えた作成リクエストで、新しいスレッドを開始してください。拒否とフォールバックを参照してください。SDKのスレッドヘルパーはこれを自動的に行います。拒否されたターンを保持せず、次のターンで新しいスレッドを開始します。

スレッドでフォールバックを使用する

サーバーサイドフォールバックは、Claude APIでスレッドとともに利用できます。スレッドの作成時に決定してください。fallbacksをスレッドのすべてのリクエストで送信するか、まったく送信しないかです。fallbacksの値はリクエスト間で変更できます。fallbacksを追加または削除する継続リクエストは、コードthread_fingerprint_mismatchの400エラーを返します。

スレッドは1つのモデルを保持するため、APIはフォールバックモデルが書いたターンを保存しません。レスポンスは通常どおり受け取れますが、そのidから継続することはできません。各レスポンスの後、次の手順に従ってください：

1. stop_reason が "refusal" の場合は、拒否の後に従ってください。
2. それ以外の場合は、usage.iterations 内の fallback_message エントリを探します。ストリームでは、最後の message_delta イベントから読み取ります。エントリがない場合は、通常どおりスレッドを継続します。
3. 存在する場合、そのレスポンスはフォールバックモデルが作成したものです。そのレスポンスと次のメッセージを含む会話全体を、新しい作成リクエストで送信します。そのリクエストには server-side-fallback-2026-07-01 ベータヘッダーを付けたままにしてください。次の2つのリクエストのいずれかを選択します。
   • 同じリクエストをもう一度送信する。 model、fallbacks、およびその他のパラメータはそのままにします。リクエストしたモデルが応答した場合、APIは新しいスレッドを保存します。フォールバックモデルが応答した場合、レスポンスには再び fallback_message エントリが含まれ、APIはそれを保存しないため、次のターンでこの手順を繰り返します。スティッキールーティングによってこれらのリクエストがフォールバックモデルに直接送られる場合があるため、毎ターン会話全体を送信することになる可能性があります。SDKのスレッドヘルパーはこの方法で動作します。
   • フォールバックモデルで新しいスレッドを開始する。 model をその fallback_message エントリ内の model に設定し、fallbacks を省略して、このモデルが受け付けるパラメータを使用します。APIはこのスレッドを即座に保存し、スレッドはフォールバックモデル上に留まります。フォールバックの試行は送信した設定とは異なる設定で実行された可能性があるため、最初のリクエストからコピーした値をAPIが拒否する場合があります。
4. そのリクエストへのレスポンスを使って手順1に戻ります。レスポンスに fallback_message エントリがない場合は、その id から新しいスレッドを継続します。

スティッキールーティングは、リクエストがフォールバックした後（作成リクエスト、または thread を含まないリクエスト）に開始されます。約1時間の間、fallbacks を含む同じ会話に対する後続の作成リクエストを、リクエストしたモデルを試さずにフォールバックモデルへ直接送る場合があります。APIはそれらのターンをいずれも保存せず、応答があるたびにその1時間がリセットされます。継続リクエストがこのルーティングを開始することはなく、このルーティングを使用することもありません。組織またはワークスペースがゼロデータ保持または顧客管理の暗号化キーを使用している場合、スティッキールーティングは適用されません。

会話をコンパクションする

スレッドは追記専用であるため、以前のターンを要約に置き換えることはできません。会話をコンパクションするには、要約から新しいスレッドを開始してください。要約はコード内で作成し、system と tools を含めた新しい作成リクエストで、通常のメッセージとして送信してください。オンデマンドコンパクションはスレッドでは利用できません（スレッドがサポートしていない機能を参照）。

SDKヘルパーの動作

ヘルパーが行うこと：

• スレッドを使用するすべてのリクエストに message-threads-2026-08-12 ベータヘッダーを追加します。
• 最初のターンでスレッドを作成し、その後はスレッドを継続します。その際、新しいメッセージのみを送信し、system と tools は省略します。
• 継続リクエストが thread_not_found、thread_already_continued、または thread_continue_in_flight を返した場合、新しい作成リクエストで会話全体を一度リプレイします。
• メッセージなしで send() を呼び出すと、pause_turn レスポンスを再開します。
• 拒否の後に新しいスレッドを開始します。stop_reason: "refusal" レスポンスは通常どおり受け取りますが、ヘルパーはそのターンを保持しません。その呼び出しに渡したメッセージを取り消します。thread.append(...) で追加したメッセージや、ヘルパーの作成時に渡したメッセージは、ステージされたまま残ります。次のターンでは、それらを拒否されたターンより前の会話とともに、新しい作成リクエストで送信します。言い換えたメッセージを送信するか、ステージされたメッセージが拒否の原因となった場合は、そのメッセージを除いたparamsから新しいスレッドを開始してください。
• フォールバックモデルからのレスポンスの後は、新しい作成リクエストを送信します。レスポンスの usage.iterations に fallback_message エントリがある場合、ヘルパーはそのレスポンスを保持し、次のターンで会話全体を新しい作成リクエストで送信します。404エラーを待つことはありません。そのリクエストでは、設定した model と fallbacks が維持されます。
• 以前のターンを再度送信する際（たとえばリプレイ時やフォークの最初のターン）には、それらのターンの cache_control ブレークポイントを省略します。最新のメッセージ、system、tools、およびトップレベルの cache_control は、指定したとおりに送信されます。

自分で処理すること：

• フォールバック。 APIがフォールバックモデルから応答し続けている間、APIはそれらのターンを一切保存しないため、ヘルパーは毎ターン会話全体を新しい作成リクエストで送信します。リクエストしたモデルからのレスポンスを受け取った後は、継続リクエストに戻ります。代わりに会話をフォールバックモデルに移行するには、スレッドでフォールバックを使用するのように、その model を指定し fallbacks を含めずに、paramsから新しいスレッドを開始してください。
• 中断されたストリーム。 レスポンスの途中でストリームが終了した場合、ヘルパーは完了したブロックと受信済みのテキストを保持し、次のターンで会話全体を新しい作成リクエストで送信します。ヘルパーは自動的にリトライしません。代わりに中断されたターンを再送するには、メッセージなしで send() を呼び出してください。保持された部分がツール呼び出しで終わっている場合は、次のメッセージでそれらに応答してください。ストリームが stop_reason: "refusal" を示した後に読み取りを停止した場合、ヘルパーはそのターンを拒否として扱います。
• その他のエラー。 thread_fingerprint_mismatch および thread_unsupported_request エラーはコードに返されます。thread_unsupported_request エラーの後に thread なしで続行するには、unsupported_request_behavior を continue_unthreaded に設定してヘルパーを作成してください。この設定では、リプレイ後の最初の継続リクエストが再び thread_not_found を返した場合にも、ヘルパーは thread の使用を停止します。APIがその会話を保存できない可能性があります。この設定がない場合、ヘルパーはターンごとにリプレイします。独自のスレッドを作成するツールランナーは、デフォルトでこの設定を使用します。

SDKのベータ版ツールランナーもデフォルトでスレッドを使用しますが、ランナーの作成時にオフにできます。

その他のヘルパーメソッド

ストリーミング。 ヘルパーはストリームがmessage_stopに到達した時点でレスポンスを記録するため、ストリームを最後まで読み取ってください。途中で読み取りを停止する場合は、スレッドが次のターンで使用できるようにストリームを終了してください：

• Python：withブロックを抜けます。
• TypeScript：ループを抜けるか、abort()を呼び出します。
• Go：Closeを呼び出します。
• JavaとRuby：close()を呼び出します。
• C#：列挙子を破棄します。await foreachを抜けるとこれが行われます。
• PHP：close()を呼び出します。

C#では、ストリームの読み取りを開始した時点でリクエストが送信されます。

C#、Go、Java、PHPでは、拒否の後も thread.LastMessage は前のターンのレスポンスを返し、最初のターンでは何も返しません。拒否はストリームのイベントから読み取ってください。

フィールドの変更。 updateは何も送信せず、以降のすべてのターンに適用されます。スレッドにレスポンスがある場合、ヘルパーはsystemまたはtoolsを変更するターンを拒否し、APIはその他の固定フィールドの変更を拒否します（各リクエストで送信するものを参照）。これらのフィールドのいずれかを変更するには、paramsから新しいスレッドを開始するか、スレッドをフォークして最初のターンの前にフォークを更新してください。

フォーク。 フォークは会話、フィールド、リクエストオプションをコピーし、何も送信しません。最初のターンでは新しい作成リクエストで完全な会話を送信し、その後2つのスレッドは独立します。フォークは常に会話全体から開始し、以前のレスポンスからは開始しません。

Params。 paramsには、ヘルパーのフィールドと会話全体が保持されます。新しいスレッドを開始するには、これらをヘルパーを作成するメソッドに渡します。たとえば、異なるsystemを使用する場合（各リクエストで送信するものを参照）や、後のターンを削除するためにmessagesを切り詰める場合です。paramsから開始したスレッドは、cache_controlブレークポイントを含め、すべてのメッセージを指定したとおりに送信するため、上限の4以内に収めてください（スレッドでのプロンプトキャッシングを参照）。Rubyを除き、paramsにはリクエストオプションが含まれないため、それらを再度渡してください。

構造化出力。 ヘルパーの作成時に出力形式を指定します。後のターンで変更することはできません。解析結果の取得方法はSDKによって異なります。

• PythonとTypeScript：thread.parse(...) を呼び出します。
• C#：client.Beta.Messages.Thread<T>(...) でヘルパーを作成します。
• Go：Send は、Params.OutputConfig.Format.Schema が指す構造体にアンマーシャルします。
• Java：thread(...) と outputConfig(MyClass.class) でヘルパーを作成します。
• PHP：outputConfig がモデルクラスを指定している場合、send() はテキストブロックに parsed を設定します。
• Ruby：output_config: {format: MyModel} を thread(...) に渡し、reply.parsed_output を読み取ります。

エラー

APIは、この表のエラーをモデルの実行前に返します。リクエストはトークンを使用せず、スレッドとその有効期限は変更されません。error.typeは、400エラーの場合はinvalid_request_error、404エラーの場合はnot_found_errorです。

スレッドリクエストに対する一部の400エラーにはerror_codeが含まれません。たとえば、previous_message_idのない継続リクエストや、systemまたはtoolsを含む継続リクエストです。

次の例はエラー本文を示しています：

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "thread: a maximum of 4 blocks with cache_control may be provided when `thread` is set. Found 5.",
    "details": {
      "error_code": "thread_unsupported_request",
      "unsupported": ["cache_control"]
    }
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

スレッドがサポートしていない機能

スレッドは次の機能をサポートしていません：

• Message Batches。threadを含むリクエスト項目は、バッチ結果でinvalid_request_errorとして終了します。
• トークンカウント。threadを含むトークンカウントリクエストは400エラーを返します。代わりに、systemとtoolsを含む完全な会話をカウントしてください。
• コンパクション。オンデマンドコンパクションはスレッドでは利用できません。threadを含むリクエストは、compactionパラメータを設定した場合、またはcompact-2026-09-04ベータヘッダーとともにcompactionブロックを送信した場合に、400エラーを返します。会話をコンパクションするを参照してください。
• コンテキスト編集。ただし、keep: "all"を指定したclear_thinking_20251015を除きます。
• HIPAA対応が有効になっている組織。
• Inference hooksがオンになっている組織。

APIは、スレッドがサポートしていないほとんどのリクエストを、コードthread_unsupported_requestの400エラーで拒否します。error.details.unsupportedが存在する場合、そこには次のいずれかの値が含まれます：

APIはこのリストに値を追加する場合があります。認識できない値を受け取った場合は、threadなしで完全な会話を送信してください。これらの条件の複数に該当するリクエストは、そのうち1つのみを示すエラーを受け取ります。

制限事項

• スレッドを一覧表示、読み取り、または削除するAPIはありません。
• スレッドは、Claude API、Claude Platform on AWS、 Claude Models on Google Cloud (Anthropic managed)、およびClaude in Microsoft Foundryで利用できます。

料金とレート制限

スレッドは料金やレート制限を変更しません。

データ保持

メッセージスレッドは「Zero Data Retention」（ゼロデータ保持）、すなわちZDRの対象となりません。この機能の使用は、ZDRの対象となる他の機能の使用に影響を与えません。APIはスレッドをサーバー管理のキーで暗号化してメモリ内に保持し、永続ストレージには一切書き込まず、最後の使用から1時間以内に削除します。

スレッドは、APIがモデルに送信する会話、作成リクエストのsystemとtools、および以降のリクエストのチェックに使用する固定フィールドのフィンガープリントを保持します。ファイルは参照によって保持されるため、スレッドを使用している間は、会話で使用するすべてのファイルを利用可能な状態に保ってください。

すべての機能にわたるZDRの対象については、APIとデータ保持を参照してください。

関連項目

• プロンプトキャッシング
• ストリーミング
• エラー

利用可能状況

メッセージスレッドはすべてのモデルでベータ版です。

APIサポート

ベータヘッダーを使用すると、実験的な機能や新しいモデル機能が標準APIに組み込まれる前にアクセスできます。