AIREITER2026年8月26日の終了が迫るAssistants API。その移行で最も危険なのは、「名前を置き換えれば済む」と考えることです。OpenAIは2025年8月26日の廃止告知で、1年前からAssistants APIの終了を予告していました。後継はResponses APIです。ドキュメント上ではオブジェクト名がきれいに対応している一方、内部のオーケストレーションは別物です。公式ガイドどおりに進めても不具合を出した開発者はいます。ここでは、終了するもの、対応表だけでは見えない変更点、そして残り期間ごとに取るべき対応を整理します。
2026年8月26日に止まるもの、残るもの
期限を過ぎると、Assistants APIのエンドポイント群はすべてエラーを返します。対象には/v1/assistants、/v1/threads、スレッドメッセージ、runs、run stepsが含まれ、OpenAI-Beta: assistants=v2ヘッダーを送るワークフローも例外ではありません。Assistantの設定とスレッド履歴にも、API経由ではアクセスできなくなります。
ただし、Assistants連携に紐付くものがすべて消えるわけではありません。
| 2026年8月26日に利用不可 | 引き続き利用可能 |
|---|---|
/v1/assistantsのCRUDエンドポイント | ベクターストアとアップロード済みファイル（Responsesのfile searchで再利用可能） |
/v1/threads、スレッドメッセージ | Chat Completions API（今回の終了対象外） |
| Runsとrun steps | Responses APIとConversations API |
OpenAI-Beta: assistants=v2のワークフロー | Realtime API |
OpenAIの廃止予定トラッカーでも、正式な後継としてResponsesとConversationsが挙げられています。
4つの対応表だけでは足りない：設計を変える2つの注記
OpenAIの移行ガイドでは、Assistants APIの4つの概念をResponses世代の要素へ次のように対応付けています。
| Assistants API | 移行先 | 実際に変わること |
|---|---|---|
Assistants | Prompts | 設定はダッシュボードで作成・バージョン管理するオブジェクトへ移る |
Threads | Conversations | メッセージだけでなく、ツール呼び出しやツール出力を含む汎用アイテムを保存する |
Runs | Responses | create-run-poll-retrieveというループが、単一のresponses.create呼び出しに集約される |
Run steps | Items | メッセージ、関数呼び出し、結果を扱うユニオン型 |
この集約は公式サンプルにも現れています。gpt-4.1で完了したrunは34 prompt tokensと130 completion tokensを報告するのに対し、gpt-5.5で完了したresponseは17 input tokensと150 output tokensを返します。ワークロードの形は同じでも、フィールド名は異なります。
これが1つ目の注記です。旧来のusageフィールドを前提にした課金ダッシュボードやペイロードパーサーは、名称変更によって静かに壊れます。
| Assistantsのフィールド | Responsesのフィールド |
|---|---|
usage.prompt_tokens | usage.input_tokens |
usage.completion_tokens | usage.output_tokens |
max_completion_tokens / max_prompt_tokens | max_output_tokens |
truncation_strategy | truncation |
object: "thread.run" | object: "response" |
2つ目はアーキテクチャ上の問題です。PromptsはAPI経由では作成できず、ダッシュボードでしか作れません。顧客、ワークスペース、文書セットごとにAssistantを動的作成するシステムは、この制約に引っかかります。公式ガイド自身も、再利用可能なpromptオブジェクトには独自の終了リスクがあるため、長期運用の連携で採用する前にpromptの廃止予定を確認するよう勧めています。長く使える設計は、instructions、ツールスキーマ、モデル選択を自社のソース管理に置き、リクエストごとに渡す形です。スレッド履歴についてのOpenAIの立場は一文で明確です。「ThreadsをConversationsへ移行する自動ツールは提供しません。」
組み込みツール3種の移行先
Assistantsの各ツールにはResponsesでの明確な移行先があります。ただし、そのぶんアプリケーション側で担う処理も増えます。
| Assistantsのツール | Responsesでの移行先 | アプリケーション側で管理すること |
|---|---|---|
| File search | ベクターストアは残る。リクエスト時にツール定義へvector_store_idsを指定する | 呼び出し前に正しいストアIDを解決する処理 |
| Code interpreter | type: "auto"で設定するコンテナ | コンテナのライフサイクル |
| Functions | ネストされていたfunctionキーがなくなり、name、description、parametersが1階層上へ移る | ツールループ。呼び出しを実行し、対応するcall_id付きで結果を返し、ループ継続の要否を判断する |
マルチテナントアプリでは、file searchの行が静かな設計変更になります。以前はテナントごとに用意したベクターストアをAssistantオブジェクトへセットアップ時に紐付けられました。これからは、受信したセッションの所有テナントを判定し、リクエスト送信前に適切なストアIDを解決しなければなりません。
すでに移行したチームが遭遇した問題
OpenAIは、Responsesが機能面で同等になったことを移行の理由として挙げています。ただし以下の移行報告を見る限り、オブジェクト単位では同等でも、内部では実質的なリファクタリングが必要です。マルチテナントのチャットボットSaaSを運営する開発者は、r/aiagentsで2週間の移行を記録しています。公式ガイドを忠実に読んでも、問題は残りました。
すべてのオプションフィールドを
["type", "null"]として後付けしなければならなかった。型システムの回避策のように感じる。 — u/aidenclarke_12
厳格なツールスキーマでは、任意プロパティをnullableとして宣言するだけでなく、requiredにも含める必要があります。そのためスキーマは膨らみ、「存在しない＝未指定」とみなしていたハンドラーも見直しが必要です。同じ開発者は、より深い変更点も指摘しています。
ベクターストア周りの配線変更こそ、本当のアーキテクチャ変更だ。 — u/aidenclarke_12
もう1つ見落とされやすい破壊点がストリーミングです。AssistantsのrunストリーミングはResponsesへそのまま流用できません。response.created、response.output_text.delta、response.completed、response.function_call_arguments.delta / .doneといった型付きServer-Sent Eventsを前提に書き直す必要があります。完了イベントが明示され、ツール呼び出しイベントの形も変わります。イベント名は移行情報のまとめに掲載されています。SSEプロキシとクライアントハンドラーの両方を、再接続ロジックも含めて作り直す必要があります。
3つ目の問題はAPIそのものではなく、周辺エコシステムの追随遅れです。
Responses APIはかなり前からあるのに、まだ多くのフレームワークやSDKが対応していない。 — u/zhlmmc
u/zhlmmcが直面したように、導入しているエージェントフレームワークがThreads/Runsモデルを前提としている場合は、自前の接着コードだけでなく、そのレイヤーの移行時間も見込むべきです。
状態管理は3通り：チェーン、Conversations、手動リプレイ
Responsesで複数ターンのコンテキストを維持する方法は3つあります。用途は同じではありません。
| 方式 | 向くケース | 注意点 |
|---|---|---|
previous_response_id | もっとも簡単なチェーン接続、最小限の書き換え | 過去のコンテキストも課金対象の入力として残る |
| Conversations API | Threadsにもっとも近い仕組み。サーバー側で履歴を管理したい場合 | バックフィルは自作。ベンダー提供ツールはない |
手動リプレイ、store: false | ZDRや厳格な保存期間要件がある場合 | すべての状態を自分で管理し、reasoning itemsも引き継ぐ必要がある |
既存スレッドを変換する際、OpenAIが推奨する履歴の移行手順は次のとおりです。
- スレッドのメッセージを昇順で取得する。
- ユーザーのテキストメッセージを
input_textへ変換する。 - アシスタントのテキストメッセージを
output_textへ変換する。 - 画像URLのコンテンツを
input_imageへ変換し、image_urlとdetailを維持する。 - 変換した
itemsでConversationを作成する。
ロールの対応を誤ると、モデルが自分の過去の回答を新しいユーザー指示として読んでしまいます。保存されたresponseのTTLは、store: falseを渡さない限りデフォルトで30日です。一方、conversationsはこのresponse TTLの対象外であり、2026年7月下旬時点では別途の保存期間は公開されていません。これはこの点を追跡した移行情報によるものです。削除期限を開示しているサービスでは、特に重要な違いになります。
移行後、トークン料金はどう変わるか
課金面で押さえるべき点は2つです。
第一に、previous_response_idは割引機能ではなく利便性のための機能です。OpenAIのResponses移行ガイドによれば、responseチェーン内の過去の入力トークンも入力トークンとして課金されます。そのため、削減しなければ長期の会話は線形に膨らみます。
第二に、キャッシュ済み入力は未キャッシュ入力より大幅に安価です。2026年7月時点のGPT-5.x各階層では入力単価のおよそ10分の1であり、OpenAIの社内テストではResponsesのキャッシュ利用率がChat Completionsより40～80%高かったとされています。これは収集された情報によるものです。自社ダッシュボードで確認できるまでは、この利用率の幅をベンダー公表値として扱うべきでしょう。重要なのは、切り替え前後でセッションあたりのトークン数を自分たちで比較することです。
今回の移行をGPT-5.xワークロード自体の価格見直しの機会にするなら、GPT-5.6の料金解説でトークン単価の計算を確認できます。GPT-5.6 APIページのようなOpenAI互換エンドポイントでも、同じResponsesスタイルのワークロードを実行でき、直接比較が可能です。
残り期間別：現実的な移行プラン
残り1～6日。まずバックアップです。limit=100でassistantsとベクターストアを一覧取得し、ファイルを取り出し、SDKオブジェクトはmodel_dump()でシリアライズします。バックアップ優先の解説が指摘する重要な制限として、スレッド一覧取得エンドポイントは存在しません。エクスポートできるのは、自身のアプリケーションがすでに保存しているthread IDだけです。その後はフラグで切り替えます。新規セッションは直ちにResponsesへ送り、既存スレッドはユーザーが再度開いたときだけ遅延バックフィルします。
1週間以上ある場合。まずは低リスクのフローを1つ選び、最初から最後まで移行します。他へ手を広げる前にツールループを再構築し、各関数結果に対応するcall_idが付いていることを検証してください。ストリーム処理はイベント型による分岐へ置き換え、トラフィックを広げる前に、Assistantsを基準として挙動、レイテンシー、トークン使用量、エラー率を比較します。
期限後。エンドポイントはエラーを返し、Assistantの設定もAPI側から消えます。復旧は、アプリケーションデータベースとバックアップに残っている情報から再構築するしかありません。ベクターストアとファイルはfile search経由で引き続き利用できます。
残るトレードオフは明確です。ポーリング、切り詰め、ツールループをサーバー側で管理するライフサイクルと引き換えに、単一呼び出しモデルと、可視化・テスト可能なオーケストレーションを手に入れることになります。両方を本番導入した開発者は、この交換をこう表現しています。
Responses APIは、重い処理を任せつつ、独自機能のために十分コントロールもできる、ちょうど中間の存在だ。 — u/landongarrison
OpenAI Assistants API終了 FAQ
Chat Completions APIも終了しますか？
いいえ。Chat Completionsは2026年8月26日の終了対象ではありません。OpenAIのガイダンスでは、強制期限に追われるのではなく、フロー単位でResponsesへ移行できるものとして扱われています。
既存のスレッドはOpenAIが自動移行してくれますか？
いいえ。公式移行ガイドには「ThreadsをConversationsへ移行する自動ツールは提供しません」と明記されています。バックフィルは、上記のitem変換手順に沿ってアプリケーションコードで実装する必要があります。
2026年8月26日以降もAssistants APIを使えますか？
いいえ。Assistants、threads、messages、runs、run stepsはすべて期日後にエラーを返します。assistants=v2のワークフローも対象です。必要なものは期限前にエクスポートしてください。
保存したresponsesには有効期限がありますか？
はい。store: falseを指定しない限り、保存されたresponsesのデフォルト保存期間は30日です。2026年7月の報道時点では、conversationsはこのTTLの対象外です。
Assistantの設定はPromptsへ移す必要がありますか？
いいえ。特に動的に生成するAssistantでは、移すべきではありません。Promptsはダッシュボードでしか作成できず、公式ガイドも再利用可能なpromptオブジェクトについて廃止予定の確認を促しています。instructionsとツールスキーマをソース管理に保持し、リクエストごとに渡す設計が長期的には堅実です。