OpenAI Assistants APIが8月26日に停止｜自社コードの棚卸しと移行の実務手順

OpenAIのAssistants APIが2026年8月26日に停止します。公式の廃止カレンダーの本文には、2025年8月26日に開発者へ通知し、その1年後にAPIから削除すると記載されています(同ページの該当セクションの見出しは2025-08-20表記で、ページ内に表記ゆれがあります)。本記事を書いている2026年8月3日から数えると、残りは3週間ほどしかありません。値下げや新モデルの話題とは性質が違い、対応しなければ動いているものが止まる種類のニュースです。そこでこの記事は、自社のコードが該当するかをどう洗い出し、何から手を付けるか、間に合わない場合に何ができるかという実務手順に絞ります。あわせて2026年後半に続く他の停止予定も「引退カレンダー」としてまとめます。

何が止まるのか#

まず事実関係です。OpenAIの公式Deprecationsページには、2025年8月26日にAssistants APIの利用者へ廃止を通知し、その1年後の2026年8月26日にAPIから削除する、と記載されています。推奨される代替は「Responses APIとConversations API」です。

同ページの説明によれば、OpenAIは2025年3月にResponses APIを公開した時点で、Assistants APIの機能をResponses APIへ移していく計画と2026年中のサンセットを予告していました。今回の停止はその予告どおりの着地で、公式の移行ガイドの冒頭にも「Responses APIで機能パリティを達成したうえでAssistants APIを非推奨にした」という趣旨の説明があります。

まず棚卸し:自社のコードは該当するか#

意外と多いのが「うちはChat Completions APIだけのはずだが、断言はできない」というケースです。数年前のプロトタイプがそのまま本番に残っていたり、一部の機能だけAssistantsで作られていたりします。棚卸しは次の3方向から行うと漏れにくくなります。

コードから追えない場合は、実際の通信から確認します。プロキシやAPIゲートウェイを経由しているならアクセスログのパスを集計する、直接OpenAIを叩いているならダッシュボードで利用状況を見る、といった方法です。「grepで見つからなかった」だけを根拠に該当なしと結論づけず、ログ側からも裏を取っておくと安心です。

概念の対応表#

公式の移行ガイドには、旧APIと新APIの対応が表で示されています。ガイドに記載がある範囲では、次のとおりです。

ツールについては、Responses APIの側にfile search・code interpreterがホスト型ツールとして用意されています。file searchはvector storeにファイルをアップロードして使う形式、code interpreterはtoolsに{"type": "code_interpreter", "container": ...}を指定する形式で、いずれも公式ガイドにサンプルがあります。名前と役割は引き継がれていますが、設定の渡し方は変わるため、置き換え作業は必要です。

ここで一つ、素直に読むと落とし穴になる箇所があります。移行ガイドが示す「Assistants -> Prompts」というルートです。同じガイドの中に、再利用可能なprompt objectも廃止対象であり、長期運用する統合で採用する前に廃止のタイムラインを確認するように、という注意書きがあります。Deprecationsページで確認すると、v1/promptsと再利用可能なprompt objectは2026年11月30日に停止予定です。つまり、Assistantsの設定をダッシュボード上のPromptオブジェクトへ移すと、3か月余りで二度目の移行が発生する可能性があります。公式には、prompt objectの中身をアプリケーションコード側へ移す移行ガイドも別途用意されています。今から着手するなら、Promptオブジェクトを経由せず、最初からコード側に設定を持たせる形を検討する価値があります。

自動移行ツールは無い:既存Threadをどうするか#

公式ガイドは「ThreadsからConversationsへの移行の自動ツールは提供しない」と明言しています。推奨されているのは、新しいユーザーの会話からConversationsへ移し、古いThreadは必要に応じて移していく段階的な進め方です。ガイドには、Thread内のメッセージを取得してitemsの配列に変換し、conversations.create(items=...)でConversationを作るPythonのサンプルが掲載されています。サンプルが扱うのはテキストと画像のコンテンツで、それ以外のコンテンツ型をどう移すかは自分で決める必要があります。

実務上の判断は次の3択になります。

• 全件バックフィルする:履歴の連続性が重要なプロダクト(継続的な相談・サポート履歴など)向け。件数が多いとAPIコールとコストがかさむため、対象期間で区切るのが現実的です。
• 直近だけ移す:過去N日以内に更新のあったThreadだけ移し、それ以前は読み取り専用のアーカイブとして自社DBに保存する折衷案。多くのケースではこれで足ります。
• 移さない:新規会話のみ新APIで作り、既存の会話は停止日までに自然に終了させる。会話が短命なプロダクトなら成立します。

いずれを選ぶにせよ、Thread側のデータを自社のデータベースへエクスポートする作業は、移行方針とは独立に済ませておくことをおすすめします。停止後のデータ取り扱いが公式に明示されていない以上、手元にコピーがある状態を先に作っておくほうが安全です。

オーケストレーションを自前で持つことになる#

これがコード量としてはいちばん影響の大きい変化です。公式ガイドはPromptsへの移行の利点として「関心の分離」を挙げ、アプリケーションコードが履歴の刈り込み・ツールループ・リトライといったオーケストレーションを担当し、プロンプト側は高レベルの振る舞いと制約に集中する、と説明しています。裏を返せば、これまでAssistants APIが引き受けていた部分を自分で書くことになります。

とくに文脈長の管理は要注意です。Microsoft LearnのAzure OpenAI Assistants(classic)の解説では、Threadがモデルのコンテキスト長に収まるよう自動的に切り詰められること、max_prompt_tokensやtruncation_strategyで挙動を調整できることが説明されています。新しい構成では、会話が長くなったときにどこを削るか、要約して圧縮するかを自分で決める必要があります。ここは移行前後で最も挙動が変わりやすく、テストで最初に確認すべき箇所です。

一方で、Runsのポーリングループは不要になります。公式ガイドの比較例では、Assistants API版がRun作成後にステータスがqueuedかin_progressの間ずっと1秒ごとにポーリングするコードなのに対し、Responses API版はresponses.create()を1回呼んでoutput_textを読むだけです。減るコードもある点は、見積もりに織り込んでよいところです。

移行の優先順位とテスト観点#

残り3週間で全部を完璧に、というのは多くの場合現実的ではないので、優先順位を付けます。

テストで見るべき観点は、単に「エラーが出ないこと」ではありません。

間に合わない場合の緩和策#

正直に書くと、8月26日までに完了しない現場は出ます。取りうる手は限られますが、次の3つは現実的です。

第一に、機能を削った暫定版を先に出すこと。Assistants API依存の機能を一時的に無効化し、単純なResponses API呼び出し(会話履歴はアプリ側で配列として持つだけ)へ置き換えます。file searchやcode interpreterまで含めた完全移行は後追いにして、少なくとも会話が止まらない状態を作る、という順番です。

第二に、既存データの退避を最優先にすること。移行が間に合わなくても、Thread内の会話履歴を自社側へエクスポートしてあれば、後から新APIへ載せ替える道が残ります。ここを落とすと取り返しがつかない可能性があります。

第三に、利用者への事前告知です。会話履歴が引き継がれない、一部機能が一時的に使えないといった変化がある場合、事後に説明するより事前に伝えたほうが穏当に済みます。

2026年後半の引退カレンダー#

Assistants APIの停止は単発の出来事ではありません。公式Deprecationsページで確認できる範囲で、今後の停止予定を並べると次のようになります(執筆時点=2026年8月3日に同ページで確認できたもの)。

この表を眺めると、移行と同時に確認しておくべきことが見えてきます。Assistants APIのAPIリファレンスで指定できるモデルとして挙がっているのはgpt-4oやo1、o3-miniといった世代で、これらの多くは10月23日にも停止が控えています。移行先で使うモデルを選ぶ際、そのモデル自体の引退予定も一緒に確認しておかないと二重の作業になります。

もう一点、Evals(評価)のダッシュボードとAPIが11月30日に停止予定である点も今回の移行と直接絡みます。移行前後で品質が落ちていないかを確かめる評価を組もうとしている場合、その評価基盤自体が数か月後に無くなる可能性を織り込んでおく必要があります。公式ページには外部ツールへの移行例を紹介するCookbookへのリンクもあります。

Azure OpenAIを使っている場合#

Microsoft Learnの「Azure OpenAI Assistants API concepts (classic)」のページには、Assistants APIが非推奨であり2026年8月26日に廃止されること、一般提供されているMicrosoft Foundry Agentsサービスを使い、移行ガイドに従ってワークロードを更新することが記載されています。日付はOpenAI本体と同じです。

移行先の考え方は少し異なります。Microsoft Learnの移行ガイドの対応表でも、ThreadsはConversationsへ、RunsはResponsesへという点はOpenAI本体と共通ですが、AssistantsおよびクラシックなagentsはPromptsではなく「新しいAgents」に対応づけられています。同ガイドにはクラシック環境と新環境のツール提供状況を比較する表もあり、Azure Functionsツールなど新環境で提供されないものや、Connected AgentsからA2Aツールへの読み替えが推奨されるものが示されています。Azureで運用している場合は、OpenAI本体のガイドではなくMicrosoft側の移行ガイドを基準にしてください。

もう一点、Azure側には移行を補助するツールがあります。同ガイドには、GitHubで提供されるmigration toolがagent定義・thread作成・message作成・run作成といったコード構造の移行を自動化すること、一方で過去のrun・thread・messageといった状態データは移行しないことが記載されています。前述の「自動移行ツールは無い」はOpenAI本体のThreads->Conversationsの話であり、Azure利用者はこのツールでコード側の書き換え負荷を下げられる可能性があります。ただし履歴の移行は結局自前で設計する必要がある点は変わりません。

Assistants APIの停止日(2026年8月26日)・告知日(2025年8月26日)・推奨代替、および引退カレンダーの各日付はOpenAI公式のDeprecationsページで確認しました。概念の対応表・自動移行ツールが提供されない点・Promptsがダッシュボードからのみ作成できる点・オーケストレーションの担当範囲・コード比較例は公式のAssistants migration guideによります。v1/promptsの停止日は同ページおよびMigrate from prompt objectsガイドで確認しました。file search/code interpreterの記述は各公式ガイド、エンドポイントのパスとOpenAI-Beta: assistants=v2ヘッダーは公式APIリファレンスによります。Azureの停止日・移行先・対応表・migration toolの機能範囲はMicrosoft Learnの該当ページによります。なお告知日については、公式Deprecationsページの本文が2025年8月26日と記載する一方、同項目の見出しは2025-08-20表記になっており、ページ内で表記が揺れています。本記事は本文の記載に従いました。停止後の旧エンドポイントの挙動や既存データの保持については、確認できた公式ページには記載がありません。

恒久対策:引退は定期的に起きる#

今回いちばん持ち帰るべき教訓は、移行手順そのものより「モデルやAPIの引退は定期的に起きる」という前提を運用に組み込むことだと思います。上の引退カレンダーを見れば、これが例外的な出来事ではないことは明らかです。

OpenAIのDeprecationsページには、モデル引退の最低通知期間も明記されています。一般提供モデルは最低6か月、その特殊バリアント(chat系・Codex系・deep research系など)は最低3か月、モデル名にpreviewが付くプレビューモデルは2週間程度という短い通知で引退することがある、という内容です。同ページには、短期間で移行できる体制がない限りプレビューモデルを業務クリティカルな本番ワークロードに使うことは推奨しない、とも書かれています。プレビューを本番に載せるかどうかの判断基準として、そのまま使える記述です。

そのうえで、次の廃止に備える恒久対策としては次のあたりが実務的です。

台帳と定点観測は地味ですが効きます。今回のように「該当するか分からない」状態から棚卸しを始めるコストは、台帳を維持するコストよりずっと高くつきます。

よくある質問#

まとめ#

Assistants APIの停止は、2025年8月に告知されてから1年の猶予があったものです。それでも直前になって「うちは該当するのか」から始まる現場は珍しくありません。まずは棚卸しを終わらせて、該当なしなら安心し、該当するなら業務影響の大きい順に手を付ける。この順番さえ守れば、残り3週間でも打てる手はあります。そして今回の作業のついでに、モデルとエンドポイントの台帳を1枚作っておくことをおすすめします。引退カレンダーを見れば分かるとおり、次は数か月後にまたやってきます。