数百〜数千人規模で社内向けAIチャットボットやエージェントをAzure OpenAI Assistants API（会話履歴やツール呼び出しの状態管理をAzure側が肩代わりするAPI）上に構築し、内部統制上の変更管理プロセスを経て本番投入している企業のIT部門・アプリ開発担当が対象である。Microsoftはこのアーキテクチャ層のAPIそのものを、2026年8月26日にretireすると告知している[1]。バージョンアップではなく、API自体の提供終了である。
移行先は現在GA（一般提供）済みのFoundry Agent Serviceだが、ThreadやRunといった基本概念自体が再設計され、コードの書き換えを避けられない[2]。本稿の公開時点で退役日まで11日しかなく、通常の稟議サイクルでは対応が間に合わない組織が出てくる。退役の実務的な意味、概念変更の中身、移行手順、日本企業特有の制約を整理する。
予備知識
- Assistants API: 会話履歴やツール呼び出しの状態管理をAzure側が肩代わりするAPI。本記事の退役対象
- Foundry Agent Service: Assistants APIの後継、現在GA済みのエージェント構築サービス
- Thread / Conversation: Threadは会話1本分の履歴を保持する単位。新概念のConversationが置き換える
Azure OpenAI上でのエージェント・RAG構築を扱う実践ガイドで、Assistants APIからの移行後に必要になる新サービスでの実装知識を補える
Azure OpenAI Assistants APIはいつ、なぜ使えなくなるのか
Azure OpenAI Assistants APIは2026年8月26日にretireする。これがMicrosoftの公開している唯一のスケジュールである[1]。
Microsoft Learnには「The Assistants API is deprecated and will be retired on August 26, 2026」とある[1]。同ページはChat CompletionsやResponses APIなど他機能を対象外と明記している[1]。影響はAssistants APIとThread・Run・Vector Store関連に限られる。
退役日を過ぎたあとの挙動について、Microsoftの公式ドキュメントは「retire（提供終了）」としか書いていない。即時に呼び出しが失敗するのか、一定期間の猶予があるのかは公表されていない[1]。Microsoft Q&Aには即時失敗とする回答があるが、AI生成回答としてラベルされたもので公式見解ではない[3]。移行計画は「猶予はない」前提で組むのが安全だが、記事としては公式に確認できる範囲を超えて断定しない。
移行先は二段構えだ。
| 世代 | 位置づけ | 退役予定 |
|---|---|---|
| Assistants API | Foundry（classic）の旧機能 | 2026年8月26日[1] |
| Foundry Agent Service（classic） | 旧ポータルの中間的な移行先 | 2027年3月31日[4] |
| Foundry Agent Service（GA・新） | 新ポータルの正式な移行先 | 未発表（現行の推奨先）[2] |
「classic」版へ乗り換えると7カ月後に二度目の移行が必要になる[4]。新ポータルのGA版へ直接乗り換える判断が要る。
Thread/Run相当の状態管理をエージェント側でどう設計するかを扱っており、Conversation/Response概念への移行設計の参考になる
Threads・Runsは新サービスで何に変わるのか
新サービスでは状態管理の概念が再設計されており、旧コードはそのままでは動かない[2]。
AssistantはAgent Versionに、ThreadはConversationに、RunはResponseに置き換わる[2]。
| 旧概念 | 新概念 | 主な変更点 |
|---|---|---|
| Assistant | Agent Version | バージョン管理の単位として再定義 |
| Thread | Conversation | 会話状態の保持単位、呼び出し方法が変わる |
| Run | Response | 実行結果の取得・監視ロジックの書き換えが必要 |
コード例では、client.beta.assistants.create()はclient.agents.create_version()に置き換わる[2]。Threadへのメッセージ追加はopenai.conversations.items.create()でrole: “user”のitemを追加する形になる[2]。Run状態で分岐していたロジックは、Response状態を見る形に書き換えが要る[2]。
数百のWebアプリをAzure App Serviceで運用し、年次のセキュリティ監査を受ける企業のプラットフォーム担当者は、2026年後半に複数のランタイムが立て続けにサポート終了を迎える事態に向き合うことになる。対象はAzure Ap[…]
移行はどのような手順で進めるべきか
Microsoftは移行支援ツールを公開しているが、対象はコード構造の変換に限られ、会話履歴などの状態データは自動移行されない[2]。
提供ツールはエージェント定義・Thread・メッセージ・Run作成のコード構文変換を自動化する[2]。過去のRun・Thread・メッセージ履歴は対象外で、引き継ぐ場合は別途エクスポート・再投入の設計が要る[2]。
| ステップ | 作業内容 |
|---|---|
| 1. 棚卸し | Assistants API系エンドポイントの呼び出し箇所をコード単位で洗い出す |
| 2. SDK更新 | クライアントSDKを新サービス対応版に切り替える |
| 3. コード変換 | 移行ツールで定義・Thread・Run作成の構文を変換する[2] |
| 4. 履歴の再設計 | 過去の会話履歴は自動移行されないため保持要否を判断する[2] |
| 5. 検証 | ツール呼び出し・ファイル検索が新サービス上で同等に動くか確認する |
| 6. 本番切替 | 退役日より前に完了し、旧経路のエラーを監視する |
AWSがEC2 Capacity Blocks for ML（GPUインスタンスを一定期間だけ確保予約できるAWSの購入方式）の料金を、2026年7月1日付で再び引き上げた。対象はP6-B300・P6-B200・P5・P5e・P5en・P[…]
変更管理と稟議のある日本企業に、2026年8月26日は間に合うのか
日付が動かない退役スケジュールは、日本企業の意思決定構造との相性が悪い。本稿の公開時点で残りは2週間を切っている。
最初に確認すべきは、自社のリージョンで何がいつ止まるかだ。Assistants APIの退役日はリージョンごとに段階適用されるものではなく、2026年8月26日で一律である[1]。Japan East／Japan Westで運用していても猶予は増えない。日本語ドキュメントは英語版から遅れて更新されることがあり、退役告知の有無を日本語ページだけで判断すると気づくのが遅れる。
次が体制側だ。SIerに保守を委託している場合、改修は年間保守契約の範囲外となり追加見積もりの交渉から始まる。社内で稟議を起票しても、承認と変更管理記録の作成に数週間〜数ヶ月を要する組織は珍しくない。つまり、いま起票しても8月26日には間に合わない可能性がある。
間に合わないと判断した場合の選択肢は2つある。ひとつは、Assistants APIを呼んでいる機能を一時停止して退役日を越え、移行を通常の変更管理サイクルで進めること。もうひとつは、緊急変更として承認を先行させ、事後に記録を整えることだ。どちらを選ぶかは統制の要求水準による判断であって、技術的な難易度の問題ではない。
| 論点 | 想定される対応速度 | 日本企業の実情 |
|---|---|---|
| 変更適用までの期間 | 数日〜1週間で着手 | 稟議・承認で数週間〜数ヶ月 |
| 開発体制 | 自社チームが直接書き換える | SIerとの契約範囲外で追加見積もりが必要になりやすい |
| 内部統制 | 軽微な変更は記録のみ | 変更管理プロセスの正式承認が必須 |
IT部門の判断は、通常の稟議ルートでは間に合わない前提で今週中に緊急変更として起票することだ。決裁側の判断は、通常サイクルでは本番障害が起きる前提に立ち、緊急承認ルートの適用可否をこの週内に決めることである。
⚠️ 結論：Sora 2（OpenAI）は提供終了しました Web版・アプリ版：2026年4月26日に提供終了（OpenAI公式ヘルプの案内）。 API：2026年9月24日に終了予定。 これ[…]
まとめ
Assistants APIの退役は、単なるバージョンアップではなく概念の入れ替えを伴う。IT部門担当者がまず取るべき一手は、自社の利用箇所を棚卸しし、移行ツールで変換できる範囲と手作業が必要な範囲を切り分けることだ。決裁側が判断すべき材料は、通常の稟議サイクルでは8月26日に間に合わない前提に立ち、緊急承認ルートを適用するかどうかである。
移行先をclassic版にするか新GA版にするかも、二度目の移行を避けたいなら今決める必要がある。
よくある質問（FAQ）
Q1. Assistants APIを直接呼んでいなくても影響はあるか。
社内基盤やSDKが内部でAssistants APIを使っている場合は影響を受ける。ベンダーやSIerに依存関係を確認する必要がある。
Q2. 移行ツールを使えば自動で移行が完了するか。
コード構文の変換は自動化されるが、過去の会話履歴やRun記録は対象外である[2]。履歴の保持要否は個別に設計する。
Q3. 退役日を過ぎるとどうなるか。
猶予なくAPI呼び出しが失敗する[1][3]。切替リハーサルなしに迎えるのは避けるべきである。
