メインコンテンツまでスキップ

プロバイダー間のサーバーサイド会話状態

上級
What you'll learn
  • 3 つの API と、その継続パラメータを混同せずに言える
  • 1 つの言葉の裏に隠れた 2 つのプロダクト — 一時的なレイテンシ最適化と、耐久的な会話ストレージ — を区別する
  • リリース前に保持期間の行を読む — 3 社のうち 2 社では、会話の保存は自分で選んだ結果ではなくデフォルトである
  • どれもトークン課金を削減しないと理解し、実際に削減する機能がどれかを知る
  • 3 社すべてに通用する 1 つの設計ルールを適用する: 自分のログが真実の源、プロバイダーの状態はキャッシュ
  • 3 社にまたがる抽象化が漏れる 3 か所を見つける

長年、あらゆるチャット API は設計上ステートレスでした。会話は自分で持ち、毎ターン再送する — それが契約のすべてでした。2026 年に主要 3 社がそろってそれを破りましたが、足並みはそろいませんでした。

Anthropic はメッセージスレッドを出しました。OpenAI は Responses API の previous_response_id と、その上に Conversations API を出しました。Google は Interactions API を出しました。いずれも、新しいターンだけを送って、それ以前のものを指し示せます。売り文句は 3 社のサイトで同じに読めます。

しかし内部では、2 社がストレージを作り、1 社がキャッシュを作りました。この 1 つの違いが、アプリケーションが会話の自前コピーを持たなければならないか、ユーザーのメッセージが他社のディスクにどれだけ長く置かれるか、午前 3 時の障害経路がどう見えるかを決めます。

3 つの API の概観​

比較表​

Anthropic(message threads)OpenAI(Responses / Conversations)Google(Interactions API)
ステータス2026-11-02 からパブリックベータ、ヘッダー message-threads-2026-08-12一般提供Gemini で構築するための新しい標準として位置づけ
エンドポイントthread フィールド付きの POST /v1/messagesPOST /responses、コンテナ用に POST /conversationsPOST /v1beta/interactions(interactions.create)
継続パラメータthread: {"type": "continue", "previous_message_id": …}previous_response_idprevious_interaction_id
オプトイン?オプトアウト?オプトイン。thread フィールドがなければ状態もない。オプトアウト。store のデフォルトは true。オプトアウト。store のデフォルトは true。
耐久性ベストエフォート。メモリ上に保持、サーバー管理の鍵で暗号化、永続ストレージには一切書き込まれない。耐久的。レスポンスは id で取得可能。耐久的。インタラクションは id で取得可能。
保持期間最後のリクエストから 5 分で失効、最後の使用から遅くとも 1 時間以内に削除。レスポンスが保存されるたびに 5 分がリセット。レスポンスオブジェクトはデフォルトで 30 日保存。Conversation オブジェクトとその項目は 30 日 TTL の対象外。**有料プラン: 55 日。無料プラン: 1 日。**有料プランは AI Studio で 7 / 14 / 28 / 55 日を設定可能。
削除できるか?スレッドを一覧、読み取り、削除する API はない。永続化したくなければ store: false。delete メソッドでいつでも可能。
何が保存されるかモデルに送られた会話、create リクエストの system と tools、fixed フィールドのフィンガープリント。ファイルは参照。チェーン内のレスポンスオブジェクト、コンテナ内の会話項目。実行履歴の全体: モデルの思考(thought)、サーバー側・クライアント側のツール呼び出しと結果(function_call、function_result)、model_output。
トークン課金変わらない。Claude は毎ターン会話全体を読む。変わらない。明示的に文書化: チェーン内の過去の入力トークンはすべて入力トークンとして課金される。課金ルールとしては変わらない。Google はステートフルな経路を、サーバーがキャッシュを最適化できる経路として説明。
分岐 / 編集 / その場での要約不可。Append-only で、各レスポンス id はちょうど 1 回しか continue できない。未検証 — 下の注記を参照。未検証 — 下の注記を参照。
ZDR / HIPAA**ZDR 対象外、HIPAA 対象外。**HIPAA readiness が有効な組織では利用不可。自社の契約を確認すること。自社の契約を確認すること。
自分で書くべき障害経路404 → 新しい create リクエストで会話全体をリプレイ。必須。保持期間の失効。store: false にすると previous_response_id は使えなくなる。保持期間の失効。store=false にすると previous_interaction_id とバックグラウンド実行の両方が無効になる。
検証できなかったこと、そして断言しないこと

Anthropic は append-only と id ごとに continue 1 回という制限を明示的に文書化しているので、スレッドに「分岐なし」という主張は確かです。OpenAI と Google のドキュメントには、上記の検証日時点で、引用したページに同等の制限は書かれていません — だからといってその機能が保証されているわけではありません。OpenAI や Google で会話を以前の時点から分岐させる設計に依存するなら、この表から推測せず、実際の API で試してください。

本当に重要な軸​

パラメータ名はいったん忘れてください。この比較全体を組み替える問いが 1 つあります:

プロバイダーが状態を失ったとき、あなたのアプリケーションは壊れるか?

Anthropic では、答えは「壊れない。設計上そうなっている」です。スレッドは明示的にベストエフォートです。Anthropic 自身のドキュメントは、アプリケーションが真実の源であり続けること、どのレスポンスも — create も continue も — ターンが保存されたかどうかを教えないこと、次のリクエストで成功するか 404 が返るかで初めて分かることを述べています。5 分間の無操作で失われます。それは欠陥ではなく、製品そのものです。Anthropic は会話の形をしたキーを持つプレフィルキャッシュを作り、自社の作業も減るのでゼロ円で提供しました。

**OpenAI と Google では、答えは「どれだけ信頼したかによる」です。**どちらも、数週間単位の保持期限を持つ、耐久的で、取得でき、削除できるオブジェクトを提供します。プロバイダーを真実の源にすることもできます。コードが少なくて済むので、そうするチームは多いでしょう。その便利さの代償は 3 つの形で届きます: ユーザーの会話の 30 日または 55 日分のコピーが第三者のシステムに存在すること、データ削除の手順がその API を経由すること、プロバイダーを移るにはベース URL を切り替えるのではなく会話をエクスポートする必要があること。

どちらも間違いではありません。異なる問いへの答えです — 「エージェントループを速くしたい」と「会話を代わりに保管してほしい」。間違いは、あるプロバイダーのドキュメントを読んでメンタルモデルを作り、それを次のプロバイダーにそのまま持ち込むことです。

誰も選んでいないデフォルト​

これは今日行動に移す価値のある発見で、私たちが調べた比較記事のどれにも載っていません。

Watch out
  • OpenAI では store のデフォルトは true。Google の Interactions API でも store のデフォルトは true。
  • どちらかの API を深く考えずに呼ぶと、会話はサーバー側に保持されます — OpenAI ではデフォルトで 30 日、Google の有料プランでは 55 日、Google の無料プランでは 1 日。
  • チームの誰もこれを決めていません。それはデフォルトであり、あなたが持っていると思っているかもしれないステートレスな挙動の方がオプトアウトです: store: false。
  • Google では store=false にすると previous_interaction_id とバックグラウンド実行も無効になります — つまりプライバシー上安全な設定は、2 つの機能を犠牲にします。
  • Anthropic のデフォルトは逆です: thread フィールドがなければ状態もない。オプトインです。

LLM トラフィックを一時的なものとして説明するプライバシーポリシー、DPA、記録保持の約束があるなら、自分のコードがこの 3 つのうちどのデフォルトで動いているかを確認してください。この監査は 10 分で終わり、このページで最も価値の高い作業です。

Audit prompt — point an agent at your own repo

Search this repository for every call to an LLM provider's chat or response API.
For each call site, report:

1. Provider and endpoint (Anthropic /v1/messages, OpenAI /responses, Google /interactions, other).
2. Whether server-side conversation state is in use: a "thread" field,
 "previous_response_id", "previous_interaction_id", or a conversation/thread id.
3. The value of any "store" parameter — and flag it when the parameter is ABSENT,
 because OpenAI and Google both default store to true.
4. Whether we keep our own durable copy of the conversation independent of the provider.

Output a table. Mark as HIGH RISK any call site that relies on provider-held state
with no local copy, and any call site that omits "store" on OpenAI or Google.
Do not change any code.

どれもトークン課金を削減しない​

3 社とも、この点については異例なほど明確ですが、3 社とも誤って報じられます。

  • Anthropic: Claude は毎ターン会話全体を読むため、トークン使用量は同じままです。料金とレート制限は変わりません。公表されている利点はレイテンシです — 50 万〜100 万トークンのリクエストで time to first token の中央値が約 35% 短縮。
  • OpenAI: previous_response_id を使っても、チェーン内の過去の入力トークンはすべて入力トークンとして課金されます。
  • Google: ステートフルな経路が推奨される理由の一部は、サーバーがキャッシュを最適化できるからです — これはキャッシュに関する説明であって、会話トークンの割引ではありません。

これらの機能が取り除くのはアップロードです: 回線上のバイト、そして最初のトークンが出る前に終えなければならない検証とトークナイズの作業。これは本物の、ときに大きなレイテンシ改善です。しかし請求項目ではありません。

請求額を下げるのは、どのプロバイダーでもプロンプトキャッシュです — そして Anthropic ではスレッドがそれを代わりに有効にはしません。仕組み、TTL、損益分岐の計算はプロバイダー間のプロンプトキャッシュ、絶対額はプロバイダー間で見る AI の実際のコストを参照してください。

2 つの機能は組み合わさり、しばしば混同される

サーバーサイドの会話状態は「何を送らなければならないか?」に答えます。プロンプトキャッシュは「何に対して支払わなければならないか?」に答えます。両方が必要で、前者をオンにしても後者はどこでもオンになりません。

移植可能な設計ルール​

今日も、次の変更の後も、3 社すべてで通用するルールが 1 つあります:

Guided walkthrough1 of 5
  1. すべてのメッセージ、すべてのツール呼び出し、すべてのツール結果を、何かを送る前に自分のストレージに保存します。Anthropic では必須です — リプレイ経路にはそれ以外の情報源がありません。OpenAI と Google では、これがあなたの可搬性を保ち、削除の筋道を自分の手元に置いておくものです。

3 社にまたがる抽象化が漏れる場所​

プロバイダー非依存のレイヤーを作る場合 — あるいはゲートウェイを使う場合 — 後で発見するのではなく、あらかじめ計画しておくべき継ぎ目が 3 つあります。

**1. 耐久性は実装の詳細ではありません。**Anthropic と OpenAI にまたがる単一の continueConversation(id, messages) インターフェースは嘘です: 一方のバックエンドでは id が 5 分の無操作で消えうるのに、もう一方では 30 日生き残ります。インターフェースがすべての呼び出し元に「これはなくなっているかもしれない」と公開するか、Anthropic のアダプターが、OpenAI のアダプターにはない完全なリプレイ経路と会話のローカルコピーを黙って抱え込むかのどちらかです。明示的にしてください。

**2. 不変性が異なります。**Anthropic のスレッドは append-only で、レスポンス id ごとに continue は 1 回です — continue のリトライは冪等ではなく、別のエラーを返します。「同じリクエストをもう一度送れば安全」とみなす汎用のリトライラッパーは、他では問題なく動いても、Anthropic のスレッドを壊します。

**3. 保存されるものが異なり、レビューでは重要です。Google の Interactions API は、ツール呼び出しや出力と並んでモデルの思考(thought)**を保存します。Anthropic のスレッドは、会話に加えて create リクエストの system と tools を保持し、ファイルは参照です。「会話」はプロバイダーごとに同じオブジェクトではないので、一社を通したプライバシーレビューが他社を通したことにはなりません。

可搬性の全体像については、モデル間でのプロンプトの移植とネイティブなマルチエージェント APIを参照してください。

Check yourself

0/3
  1. OpenAI の Responses API から Anthropic のメッセージスレッドへエージェントを移植しています。現在のコードは会話をローカルに永続化せず、previous_response_id を渡すだけです。何が壊れますか?
  2. チームは、会話を保存するコードを誰も書いていないので LLM トラフィックはステートレスだと信じています。OpenAI の Responses API と Google の Interactions API を呼んでいます。この認識は正しいですか?
  3. 3 社すべてのサーバーサイド状態機能について、トークン課金に関して正しい記述はどれですか?
Key takeaways
  • 3 つの API、3 つのパラメータ: Anthropic は thread + previous_message_id、OpenAI は previous_response_id、Google は previous_interaction_id。売り文句は同じでも、契約は同じではない。
  • Anthropic は一時的なキャッシュを作った — メモリ上、5 分の無操作で失効、1 時間以内に削除、読み取り・削除 API なし、ZDR 対象外、リプレイ経路が必須。
  • OpenAI と Google は耐久ストレージを作った — id で取得・削除でき、OpenAI ではデフォルトで 30 日、Google では 55 日(有料)または 1 日(無料)保持される。
  • store のデフォルトは OpenAI でも Google でも true。考えたことがないなら、会話を保持している。今日監査を。10 分で済む。
  • Google では store=false にすると previous_interaction_id とバックグラウンド実行も無効になる — プライベートな設定は機能を犠牲にする。
  • 3 社のどれもトークン課金を減らさない。3 社とも、アップロードサイズと time to first token は減らす。コストのレバーはプロンプトキャッシュで、どのプロバイダーでも別に設定する。
  • 移植可能な唯一のルール: 自前の append-only な会話ログを持ち、プロバイダーの状態は失ってもよいキャッシュとして扱い、store を明示的に設定し、復旧経路を最初に書く。
  • 3 社にまたがる抽象化が漏れる場所はちょうど 3 つ: 耐久性の保証、リトライの冪等性(Anthropic のスレッドは append-only で id ごとに continue 1 回)、そして「会話」に実際に何が含まれるか。

出典とさらなる読み物​

次へ​