Azure AI FoundryでAzure OpenAI Assistants API（classic）を利用している場合、最優先で進めるべき対応は、2026年8月26日までの移行です。MicrosoftはAssistants APIを非推奨とし、同日で廃止すると明記しています。移行先として案内されているのは、一般提供済みのMicrosoft Foundry Agent Serviceです。 (Microsoft Learn)
今回の変更は、ポータル画面を切り替えるだけでは完了しません。従来のThread、Message、Runを中心とした構成から、Conversation、Item、Response、Agent Versionを中心とした構成へ移行します。SDK、エンドポイント、認証方式、会話履歴の扱いも見直しが必要です。
特に注意したいのは、公式の移行ツールが過去のThreads、Messages、Runsを移行しない点です。2026年6月24日時点でAssistants APIを運用している管理者は、コード改修だけでなく、履歴データの保存、リージョン、ツール互換性、権限、監視まで含めた移行計画を立てる必要があります。 (Microsoft Learn)
Azure AI FoundryのAssistants API（classic）で確認すべき更新ポイント
今回の公式情報から、最初に押さえておきたいポイントは次の4つです。
- Azure OpenAI Assistants APIは非推奨で、2026年8月26日に廃止される
- 対象の概念ページはFoundry（classic）ポータル向けであり、現行のFoundryポータルには適用されない
- 移行先ではAPIのオブジェクト構造や実行方法が変わる
- 過去の会話履歴は自動移行されないため、別途対応が必要になる
対象のMicrosoft Learnページには、Foundry（classic）ポータルにのみ適用されることと、Assistants APIの廃止予定が明記されています。新しいFoundryポータルでは既存のAssistantsをそのまま作成・編集できず、現行環境ではResponses APIを基盤とするAgents v2が利用されます。 (Microsoft Learn)
なお、MicrosoftのAIプラットフォームは「Azure AI Studio」「Azure AI Foundry」「Microsoft Foundry」と名称が変化しています。本記事では検索時に広く使われる「Azure AI Foundry」を中心に表記しますが、現行の移行先サービス名はMicrosoft Foundry Agent Serviceです。Azure上のリソースタイプが名称変更だけで別物になったわけではないため、名称ではなく、使用中のAPI、SDK、エンドポイントで影響を判断してください。 (Microsoft Learn)
Azure OpenAI Assistants API（classic）の基本概念
Assistants APIは、会話履歴やツール実行をサーバー側で管理できる、ステートフルなAPIです。Chat Completions APIではアプリケーション側で管理していた会話状態、ファイル、ツール呼び出しなどを、Assistants APIでは複数のオブジェクトに分けて管理します。 (Microsoft Learn)
従来の主な構成要素は次のとおりです。 (Microsoft Learn)
| 構成要素 | 役割 | 移行時に確認すること |
|---|---|---|
| Assistant | モデル、指示、ツールを組み合わせたAIアシスタント | Agent Versionとして再定義する |
| Thread | ユーザーとAssistantの会話セッション | Conversationへの置き換えを検討する |
| Message | ユーザーまたはAssistantが作成したメッセージ | Itemとして扱う構成に変更する |
| Run | Threadの内容を使ってAssistantを実行する処理 | Responseを生成する処理へ書き換える |
| Run Step | Runの途中で実行したツールやメッセージ生成の詳細 | Responses APIの出力Itemやトレースで検証する |
この構成を理解しておくことが重要なのは、移行先で単に名称が変わるだけではないからです。たとえばRunは非同期で状態をポーリングする実装が一般的でしたが、Responsesは既定で同期的に処理できます。ポーリング処理、タイムアウト、再試行、画面上の進捗表示なども見直し対象になります。
影響範囲を判定する方法
Assistants APIの廃止対象かどうかは、Azureポータル上のリソース名だけでは判断できません。アプリケーションのソースコード、環境変数、APIログ、依存パッケージを調査してください。
影響を受ける可能性が高い環境
次の文字列や処理が見つかった場合は、移行対象である可能性が高いと判断できます。
| 確認場所 | 検索する例 |
|---|---|
| PythonやJavaScriptのコード | client.beta.assistants、threads.create、runs.create |
| Azure SDKを使ったコード | create_agent、create_and_process、create_run |
| APIリクエスト | assistants、threads、messages、runsを含むパス |
| 環境変数 | AZURE_OPENAI_ENDPOINT、Assistants用APIバージョン |
| データベース | assistant_id、thread_id、run_idを保存する列 |
| 運用手順 | classicポータルのAssistantsプレイグラウンドを使用する手順 |
| 監視ログ | Runのqueued、in_progress、completedをポーリングする処理 |
複数のGitリポジトリを運用している場合は、ソースコード検索だけで終わらせないことが重要です。Logic Apps、Azure Functions、コンテナ、バッチ処理、検証用ノートブック、外部ベンダーが管理するアプリケーションも調査対象に含めます。
今回の廃止が直接意味しないもの
今回の告知はAssistants APIに対するものです。Azure OpenAI全体やChat Completions API全体が2026年8月26日に終了するという意味ではありません。公式の比較表でも、Chat Completionsはclassicポータルと現行ポータルの両方で利用可能な機能として整理されています。 (Microsoft Learn)
すでに次の構成へ移行済みであれば、今回のAssistants API廃止による直接的なコード変更は限定的です。
- Responses APIを直接利用している
- Foundry Agent Serviceの現行Agentsを利用している
- Conversation、Response、Agent Versionを使用している
- Assistants、Threads、Runsを作成していない
ただし、同じシステム内に旧APIと新APIが混在しているケースがあります。フロントエンドだけResponses APIへ移行し、バックグラウンド処理ではThreadsやRunsを使い続けていることもあるため、システム単位ではなく処理単位で確認してください。
移行先では何が変わるのか
Microsoftの移行ガイドでは、Assistants APIからResponses APIを基盤とする新しい構成への対応関係が示されています。主な変更点は次のとおりです。 (Microsoft Learn)
| classicの構成 | 現行の構成 | 実務上の変更 |
|---|---|---|
| Assistants／Agents | Agent Versions | エージェント定義をバージョン管理する |
| Threads | Conversations | メッセージ以外のツール呼び出しや出力もItemとして保持する |
| Messages | Items | メッセージだけを前提とした処理を見直す |
| Runs | Responses | 非同期ポーリング処理を再設計する |
create_agent() | create_version() | PromptAgentDefinitionなどを使って定義する |
月次のapi-version | 安定版v1ルート | URLとAPIバージョン管理を変更する |
| 複数のサービス別エンドポイント | プロジェクトエンドポイントとOpenAI v1エンドポイント | 接続先を整理する |
| classic向けSDK | azure-ai-projects 2.xとopenai | 依存パッケージと初期化コードを更新する |
Agentの管理と会話処理でクライアントが分かれる
新しい開発モデルでは、エージェントの作成・バージョン管理と、会話・応答の実行で使用するクライアントが異なります。
- プロジェクトクライアント：Agentの作成、更新、バージョン管理
- OpenAIクライアント：Conversationの作成、Responseの実行
Pythonでは、プロジェクトクライアントからget_openai_client()を呼び出してOpenAIクライアントを取得します。Conversationをプロジェクトクライアントから直接作成しようとするとエラーになるため、移行時に間違えやすいポイントです。 (Microsoft Learn)
SDKの世代を混在させない
現行ポータル向けにはazure-ai-projects 2.xが使用され、1.xはclassicポータル向けです。Microsoftは、1.x向けの環境で2.xのサンプルを使用したり、その逆を行ったりするとエラーになると注意しています。 (Microsoft Learn)
また、azure-ai-inferenceパッケージの廃止日は2026年5月30日と案内されています。モデル推論についてはopenaiパッケージへの移行も併せて確認してください。 (Microsoft Learn)
依存パッケージを更新するときは、開発者の端末だけでなく、次の環境も確認します。
- CI/CDのビルドイメージ
- Azure Functionsやコンテナの依存ファイル
- 社内パッケージミラー
- セキュリティスキャンの許可リスト
- 運用手順書に記載されたインストールコマンド
設定変更で見落としやすいポイント
旧APIのパラメーターをそのままコピーしない
Assistants APIでは、tool_choice、temperature、top_p、response_formatなどで出力を調整できます。また、Run単位でmax_prompt_tokens、max_completion_tokens、autoまたはlast_messagesによる切り捨て戦略を設定できます。 (Microsoft Learn)
移行後も似た目的の設定が存在する場合がありますが、実行単位や会話状態の扱いが変わるため、値を機械的にコピーするのは避けてください。次の観点で再評価します。
- 回答品質が旧環境と同等か
- 長い会話で必要な過去情報が残るか
- トークン使用量が想定内か
- ツール呼び出しが意図した条件で実行されるか
- 構造化出力を利用する処理が失敗しないか
- タイムアウトや再試行の条件が適切か
旧Assistants APIの公式情報では、File Search利用時のmax_prompt_tokensについて、2万以上を推奨し、長い会話では5万への引き上げや上限の解除も検討するよう案内されています。ただし、これは旧APIにおける目安です。移行後は実際の文書量、会話長、検索精度、料金を測定して設定し直してください。 (Microsoft Learn)
ツール名が同じでも互換性を前提にしない
Code Interpreter、File Search、一般的なFunctionは、classicと新しいFoundry Agent Serviceの両方で利用可能とされています。一方、公式の移行比較ではAzure Functionsは新しいAgent Serviceで非対応とされるなど、ツールによって差があります。Connected AgentsやDeep Researchについても、A2AやWeb Searchを使った別構成が案内されています。 (Microsoft Learn)
ツールを利用している場合は、次の4点をセットで確認してください。
- 移行先サービスでサポートされているか
- 対象リージョンで利用できるか
- 使用するモデルがツールに対応しているか
- 認証方式と必要な権限が変わらないか
過去のThreadやMessageは移行ツールで移せない
Microsoftが公開している移行ツールは、Agent定義、Thread作成、Message作成、Run作成といったコード構造の変換を支援します。一方で、過去のRuns、Threads、Messagesなどの状態データは移行しません。 (Microsoft Learn)
そのため、移行前に次の方針を決める必要があります。
- 過去の会話履歴を業務上保持する必要があるか
- 監査、法務、問い合わせ対応で参照する可能性があるか
- 旧ThreadをJSONや自社データベースへ保存するか
- 移行日以降は新しいConversationを開始するか
- 旧Thread IDと新Conversation IDの対応表を残すか
- ユーザーに会話履歴がリセットされることを案内するか
旧APIが利用できなくなってから履歴の取得方法を検討するのでは遅いため、データ保存はコード移行より先に実施するのが安全です。
グローバル展開ではリージョンとデータ配置を再確認する
Foundry Agent ServiceとResponses APIは、すべてのAzureリージョンで同じように利用できるわけではありません。公式のリージョン一覧には日本東部を含む複数リージョンが掲載されていますが、モデルやツールの可用性はリージョンごとに異なります。ソブリンクラウドでも利用できる機能が限定される場合があります。 (Microsoft Learn)
グローバル向けシステムでは、国や地域ごとに次のマトリクスを作成してください。
| 項目 | 確認内容 |
|---|---|
| 利用国・地域 | ユーザー、運用担当者、データ主体が所在する国 |
| Foundryリージョン | Responses APIとAgentsの対応状況 |
| モデル | 必要なモデルとデプロイ方式を利用できるか |
| ツール | File Search、Code Interpreter、Web Searchなどの対応状況 |
| データ所在地 | 会話、ファイル、ベクトルデータが保存される場所 |
| ネットワーク | Private Link、VNet、送信先制御の要件 |
| 法令・契約 | データ越境、保存期間、監査ログの要件 |
| 障害対応 | 別リージョンへ切り替えられる設計か |
「対象リージョンでAgent Serviceが使える」だけでは不十分です。必要なモデルとツールの組み合わせまで利用できることを、実際のFoundryプロジェクトで確認します。
管理者が確認すべきセキュリティとデータ管理
classic環境ではリソース単位でデータにアクセスできる
Assistants APIで作成したAssistants、Threads、Messages、Filesは、Azure OpenAIリソース単位で管理されます。Azure OpenAIリソースへのアクセス権またはAPIキーを持つユーザーは、それらのデータを読み書きできる可能性があります。Microsoftは、アプリケーション側の認可、リソースとAPIキーへのアクセス制限、定期的な権限監査、診断設定の有効化を推奨しています。 (Microsoft Learn)
SaaSや複数部門で共有するシステムでは、Thread IDを知っていることだけをアクセス許可の条件にしないでください。ユーザーやテナントとThread、Fileの所有関係を自社側で管理し、APIを呼び出す前に認可判定を行います。
Agent Serviceの保存方式を選択する
現行のFoundry Agent Serviceでは、保存方式としてBasicとStandardが示されています。
- Basic：論理的に分離されたMicrosoft管理ストレージを利用する
- Standard：自社サブスクリプション内の単一テナントAzureリソースを利用する
Standardでは、ファイルをAzure Storage、ベクトルストアをAzure AI Search、会話履歴やAgent定義をAzure Cosmos DBに保存する構成が示されています。エンドポイントはリージョン単位で提供され、データはエンドポイントと同じリージョンに保存されます。 (Microsoft Learn)
機密情報、規制対象データ、独自のバックアップ要件がある場合は、開発開始後ではなく設計段階で保存方式を決めてください。後から保存構成を変更すると、データ移行、ネットワーク、権限、監視の再設計が必要になる可能性があります。
APIキー中心の運用を見直す
現行のFoundryポータルでは、Agentsなど一部の機能にMicrosoft Entra ID認証が必要です。ガバナンスが重要な本番環境では、Microsoft Entra IDとRBACの利用が推奨されています。APIキーは権限を細かく分離しにくいため、移行を機にマネージドIDやサービスプリンシパルへ切り替えるのが現実的です。 (Microsoft Learn)
確認する権限は、単に「APIを呼び出せるか」だけではありません。
- Agent定義を作成・変更できる権限
- Agentを実行できる権限
- モデルをデプロイできる権限
- ファイルや会話履歴を参照できる権限
- ツールが外部サービスへアクセスする権限
- ログ、トレース、クォータを閲覧できる権限
開発者、運用担当者、監査担当者の権限を分け、最小権限になるように設計してください。
外部データとツール呼び出しを無条件に信頼しない
Microsoftは、Function Calling、Code Interpreter、File Search、Threadsを通じて信頼できないデータを取得すると、Assistantやアプリケーションのセキュリティが損なわれる可能性があると警告しています。 (Microsoft Learn)
移行後も、次の対策が必要です。
- ツールに渡す引数をスキーマと業務ルールの両方で検証する
- 読み取りツールと更新ツールの権限を分離する
- 注文、削除、送信などの重要操作では人間の承認を挟む
- File Searchへ登録するファイルを検査する
- ユーザー入力によって接続先URLやSQLが自由に変わらないようにする
- ツールの入力、出力、実行者、結果を監査ログへ残す
管理者向け移行チェックリスト
移行作業では、次の表をそのまま進捗管理に利用できます。
| チェック項目 | 確認内容 | 完了条件 |
|---|---|---|
| 対象資産の棚卸し | サブスクリプション、リソース、アプリ、リポジトリ、担当者を列挙する | すべてのAssistants利用箇所にオーナーが設定されている |
| API利用状況 | Assistants、Threads、Messages、Runsの呼び出しを確認する | 旧APIの呼び出し件数と利用機能を把握している |
| 移行先の決定 | Agent ServiceまたはResponses API直接利用を選ぶ | システムごとに移行先と理由が文書化されている |
| リージョン確認 | モデル、ツール、ネットワークの対応状況を調べる | 本番候補リージョンで結合テストが完了している |
| SDK更新 | classic向けSDKと現行SDKを分離する | CI/CDを含めて依存関係が固定されている |
| エンドポイント更新 | プロジェクトとOpenAI v1の接続先へ変更する | 旧エンドポイントへの通信が残っていない |
| 認証・RBAC | APIキー、Entra ID、マネージドIDを見直す | 最小権限で本番実行できる |
| 履歴データ | Threads、Messages、Runsの保存方針を決める | 必要な履歴を移行前に取得済み |
| ツール互換性 | File Search、Code Interpreter、Functionsなどを検証する | 全ツールの代替方法と権限が決まっている |
| データ所在地 | Basic／Standardと保存リージョンを決める | セキュリティ・法務部門の承認を得ている |
| 監視 | トレース、診断ログ、アラートを設定する | エラー率、遅延、429、ツール失敗を検知できる |
| クォータ | モデルのTPM、RPMとサービス制限を確認する | 想定負荷のテストを通過している |
| 切り戻し | 旧環境へ戻す条件と手順を決める | 切り戻しテストが完了している |
| 廃止作業 | キー、接続、不要ファイル、旧ジョブを削除する | 旧APIへの通信がゼロになっている |
現行ポータルでは、Agentの構築は「Build」、トレースやクォータ、権限、コンプライアンス関連の確認は主に「Operate」から行います。classicポータルのManagement Centerと場所が異なるため、運用手順書や画面キャプチャも更新してください。 (Microsoft Learn)
Assistants APIから移行する実務手順
classicでの新規開発を止める
新しいAssistantsやThread依存機能を追加すると、移行対象が増えます。緊急修正を除き、classic環境への機能追加を凍結し、新機能は現行のAgent ServiceまたはResponses APIで実装します。
対象システムを3段階に分類する
棚卸ししたシステムを、次のように分類すると優先順位を付けやすくなります。
- 本番・高優先度：顧客向け、売上や業務継続に影響する
- 本番・低頻度：利用回数は少ないが停止できない
- 検証・不要：PoC、サンプル、終了済みプロジェクト
検証環境であっても、APIキーや機密ファイルが残っている場合は放置せず、移行または削除します。
移行先の構成を選ぶ
ツール、会話状態、Agentのバージョン管理、監視、公開機能が必要なら、Foundry Agent Serviceが第一候補です。
一方、既存アプリケーション内で独自にオーケストレーションしており、モデル応答と一部のプラットフォームツールだけを利用したい場合は、Responses APIを既存プロセスから直接呼び出す構成も検討できます。Foundry Agent Serviceは、Prompt Agent、Hosted Agent、既存プロセスからのResponses API利用という選択肢を提供しています。 (Microsoft Learn)
対応リージョンにFoundryプロジェクトを用意する
既存Azure OpenAIリソースのリージョンがResponses APIやAgent Serviceに対応していない場合は、対応リージョンに新しいFoundryリソースを作成する必要があります。モデル、ツール、ネットワーク、データ所在地を確認してから本番リージョンを決めます。 (Microsoft Learn)
APIオブジェクトと実行処理を書き換える
コードの主な置き換えは次の流れです。
- Assistant定義をAgent Versionとして作成する
- ThreadをConversationへ置き換える
- Message中心の処理をItem中心の処理へ変更する
- Runの作成とポーリングをResponseの生成へ変更する
- Tool CallとTool Outputの処理を再実装する
- エラー処理、タイムアウト、再試行を調整する
Microsoftの移行例では、Agent Versionの作成にcreate_version()、Conversation作成にconversations.create()、応答生成にresponses.create()を使用しています。 (Microsoft Learn)
状態データを保存し、新しいConversationを開始する
移行ツールでは旧履歴を移せないため、必要なデータを事前に保存します。本番切り替え時には、新規リクエストを旧Threadへ追加しないようにルーティングを切り替え、新しいConversationを開始します。
ユーザーに過去履歴を表示する必要がある場合は、旧履歴を自社データベースから表示し、新しい会話だけAgent Serviceへ送る構成が分かりやすい方法です。
並行稼働で品質とコストを比較する
同一のテスト入力を旧環境と新環境へ送信し、回答を比較します。完全に同じ文章になることを合格条件にするのではなく、業務要件を満たすかで判断してください。
比較する主な指標は次のとおりです。
- 正答率、根拠、引用の妥当性
- ツール選択の正確性
- 応答時間
- 入出力トークン数
- ツール実行回数
- エラー率
- 429の発生率
- 1リクエスト当たりの概算コスト
公式期限より前に本番を切り替える
公式期限は2026年8月26日ですが、期限当日に切り替える計画は避けてください。実務上は8月上旬までに本番移行を完了し、残りの期間を監視、修正、切り戻しに使うスケジュールが現実的です。
移行後は旧APIへのリクエスト数を監視し、ゼロになったことを確認してから旧キー、旧接続、不要なファイル、スケジュールジョブを削除します。
移行後に実施するテスト
Microsoftの公式ガイドでは、コードの実行、Agent Versionの作成、ConversationとResponseの生成、複数ターンでの文脈保持を確認するよう案内しています。 (Microsoft Learn)
本番移行では、公式の基本確認に加えて次のテストを実施してください。
| テスト | 確認内容 | 合格基準の例 |
|---|---|---|
| Agent作成 | 指示、モデル、ツール、バージョン | 意図した定義で作成される |
| 単発応答 | 代表的な質問への回答 | 必須情報を含み、禁止事項に違反しない |
| 複数ターン | 同じConversationで過去情報を参照 | 直前の条件やユーザー指定を保持する |
| File Search | 文書検索、引用、アクセス制御 | 対象文書のみを参照する |
| Function | 引数、認証、実行結果 | 不正な引数を拒否し、重複実行しない |
| Code Interpreter | ファイル、計算、生成物 | 想定形式で結果を取得できる |
| 長文・大容量 | 長い会話や多数のファイル | 品質低下と料金が許容範囲内 |
| 障害系 | タイムアウト、429、ツール障害 | 再試行や代替処理が動作する |
| 権限 | 別ユーザー、別テナントからのアクセス | 他者の会話やファイルを参照できない |
| 監視 | トレース、ログ、アラート | 障害原因を追跡できる |
| 負荷 | 想定同時実行数 | 目標応答時間とエラー率を満たす |
| 切り戻し | 新環境の重大障害 | 定めた時間内に旧経路へ戻せる |
移行で起こりやすい失敗
ポータルの切り替えだけで移行したと判断する
新旧ポータルの切り替えは表示画面を変える操作であり、Assistants APIのコード、データ、SDKを変換するものではありません。新ポータルでプロジェクトが表示されたとしても、アプリケーションが旧APIを呼び出していれば移行は未完了です。
classic向けと現行向けのサンプルを混ぜる
azure-ai-projects 1.xと2.x、AzureOpenAIと標準のOpenAIクライアント、旧エンドポイントとOpenAI v1エンドポイントを混在させると、属性エラー、404、MethodNotAllowedなどが発生します。 (Microsoft Learn)
移行用ブランチでは依存パッケージを固定し、参照する公式ドキュメントも現行ポータル向けに統一してください。
Conversationを誤ったクライアントから作成する
Agentの作成にはプロジェクトクライアント、ConversationとResponseにはOpenAIクライアントを使用します。役割を混同すると、メソッドが見つからないエラーが発生します。
共通ライブラリを用意する場合も、1つのクライアントにすべての責務を持たせず、管理系と実行系を分離すると保守しやすくなります。
移行ツールが履歴も移すと思い込む
移行ツールが変換するのは主にコード構造です。過去のThreads、Messages、Runsは別途保存しなければなりません。履歴の保持要件を確認せずに本番を切り替えると、問い合わせ対応や監査で必要な情報を参照できなくなる可能性があります。
リージョンだけを見てツール互換性を確認しない
Agent Service対応リージョンであっても、すべてのモデルやツールが利用できるとは限りません。リージョン、モデル、ツールを組み合わせた検証が必要です。 (Microsoft Learn)
APIキーを共有したまま移行する
旧環境のAPIキーを多数のアプリや担当者で共有している場合、そのまま新環境へ持ち込むと、権限分離や監査が難しくなります。移行時にマネージドID、サービスプリンシパル、RBACへ切り替え、不要なキーを失効させてください。
Azure OpenAI Assistants API（classic）に関するよくある質問
2026年8月26日にAzure OpenAI自体が使えなくなるのですか
今回の廃止対象はAssistants APIです。Azure OpenAI全体やChat Completions全体が同日に終了するという案内ではありません。
ただし、Assistants APIをラップしている社内ライブラリや外部サービスを使っている場合は、利用者が直接APIを呼び出していなくても影響を受ける可能性があります。
既存のAssistantを新しいFoundryポータルでそのまま編集できますか
現行のFoundryポータルはAgents v2をサポートしますが、既存のAssistantsや旧Agentはそのままサポートされません。移行が完了するまではclassicポータルで確認しつつ、新しいAgent Versionとして再構築します。 (Microsoft Learn)
公式の移行ツールを使えば作業は完了しますか
完了しません。移行ツールはコード構造の変換を支援しますが、過去のRuns、Threads、Messagesなどの状態データは移行しません。また、ツールの権限、リージョン、データ保存、テスト、監視も別途対応が必要です。
Agent ServiceではなくResponses APIへ直接移行できますか
会話状態、ツール、Agentのライフサイクル管理、公開、監視などが必要ならAgent Serviceが適しています。
既存アプリケーション側で処理を管理し、モデルやResponses APIだけを利用したい場合は、既存プロセスからResponses APIを直接呼び出す構成も検討できます。要件に応じて選択してください。
旧Threadの履歴は期限後も取得できますか
期限後も旧APIへアクセスできることを前提にしてはいけません。保持が必要な履歴は、公式期限より前に取得し、自社の保存要件に合った場所へ保管してください。
まず着手すべき3つの対応
Azure AI FoundryのAssistants API（classic）を利用している組織は、次の3つから着手してください。
- 全リポジトリと実行環境でAssistants、Threads、Runsの利用箇所を検索する
- 各システムに移行責任者を割り当て、Agent ServiceまたはResponses APIのどちらへ移すか決める
- 過去のThreads、Messages、Runsを保存したうえで、対応リージョンに検証環境を作成する
今回の変更で最も危険なのは、廃止日だけを把握して作業開始を遅らせることです。移行ではコードだけでなく、会話履歴、ツール、権限、リージョン、データ所在地、監視が変わります。
2026年8月26日を最終作業日にするのではなく、その前に本番切り替えと動作確認を終えられる計画を作成してください。
コメント