OpenAIはAssistants APIを2026年8月26日に停止する。公式の移行先はResponses APIとConversations APIである。

移行はAPIエンドポイントの置き換えに見えるが、実際にはアプリケーションの状態管理を作り直す作業になる。Assistants APIでは、Assistantが指示とツールの束、Threadが会話履歴、Runが実行状態を保持していた。Responses APIでは実行がResponseへ統合され、継続会話はConversationまたはprevious_response_idを使って構成する。

さらに、OpenAIは既存ThreadをConversationへ自動変換する移行ツールを提供しない。新規会話から切り替え、必要な既存Threadだけを個別にバックフィルする方針が案内されている。

何が終了するか

現行資産主な役割移行後の考え方
Assistant指示、モデル、ツール、ファイル設定アプリケーション設定、コード、Responsesの入力へ分解
Thread永続的な会話履歴Conversationまたは自社の会話ストア
MessageThread内の発言Conversation ItemまたはResponse入力
RunAssistantをThread上で実行Responseの作成と状態
Run Stepツール呼び出しなどの途中経過Response Item、イベント、アプリ側トレース
Vector StoreFile Searchの検索対象Responses側のFile Search設定として再接続

重要なのは、名前が変わるだけではない点である。データモデル、実行単位、監査対象、エラー処理が変わる。

最初に確認すべき依存関係

コード検索だけでは十分ではない。少なくとも次を調べる。

  • openai.beta.assistants
  • openai.beta.threads
  • threads.runs
  • assistant_id
  • thread_id
  • run_id
  • required_action
  • submit_tool_outputs
  • vector_store_ids
  • file_ids
  • Assistant IDを保存する環境変数
  • Thread IDを保存するデータベース列
  • Webhookまたはポーリング処理
  • Run Stepを監査ログへ保存する処理
  • ノーコード製品や外部SaaSからのAssistants API利用

Assistantを直接呼ぶコードがなくても、管理画面で作成したAssistant IDを設定ファイルに保存している場合がある。

最大の問題は状態の移行

新規会話と既存会話を分ける

すべてのThreadを一括変換しようとすると、停止日までに移行が終わらない可能性がある。実務上は次の二系統に分ける。

  1. 新規会話は即座にConversations APIへ切り替える
  2. 既存Threadは利用頻度と業務上の必要性で選別する

長期間参照されていないThread、再開される可能性が低い会話、法的保持義務のない履歴は、検索可能なアーカイブとして保存し、Conversationへ移植しない選択肢もある。

履歴の移植単位を決める

Threadの全メッセージを移すと、不要な履歴や大きなファイル参照まで引き継ぐ可能性がある。一方、直近数件だけを移すと、過去の合意や顧客属性が失われる。

会話ごとに次を分類する。

  • 今後の回答に必要な事実
  • 監査のために保存する事実
  • モデルへ再送してはいけない個人情報
  • 再取得できる外部システムの情報
  • 過去のモデル出力であり、事実として扱うべきでない内容

Conversationは履歴の保存場所であり、正確な業務状態の原本ではない。注文状況、契約状態、権限、承認結果は業務データベースを正本にする。

Assistant設定をそのままPromptへ移す危険

公式移行ガイドでは、Assistantの指示とツール構成からPromptを作成する経路が示されている。しかし、Reusable prompts自体も2026年11月30日に終了予定である。

そのため、次の設計は二重移行になる。

Assistant
  -> Reusable Prompt
      -> 数か月後にコード・設定へ再移行

長期運用するシステムでは、Assistantを次の資産へ分解した方がよい。

agent-config/
  system.md
  tools.yaml
  output-schema.json
  model-policy.yaml
  file-search.yaml
  safety-policy.yaml
  CHANGELOG.md

Promptオブジェクトは短期的な移行補助として使えても、唯一の正本にしない。設定をGitで管理し、変更理由と評価結果を追跡する。

RunからResponseへ移る際の差分

Assistants APIではRunを作成し、queued、in_progress、requires_action、completedなどの状態を監視する実装が一般的だった。

Responses APIへの移行では、次を再設計する。

ポーリング

Run IDを一定間隔で取得する方式から、ストリーミング、Background mode、Webhookなどへ変更できる。単純にポーリング間隔だけを移植すると、レート制限、遅延、タイムアウトの特性が変わる。

ツール実行

required_actionを検知してTool Outputを送信する実装は、Response ItemとFunction Callの処理へ置き換える。次を保証する必要がある。

  • 同じツール呼び出しを二重実行しない
  • 再試行時に副作用を重複させない
  • 引数検証をモデル任せにしない
  • 実行権限を会話単位で判定する
  • タイムアウト後の結果を破棄するか再利用するか決める

監査ログ

Run Stepを保存していた場合、Responseの入力、出力、Tool Call、Tool Result、モデル、設定、Conversation IDを結び付ける新しいトレース形式が必要になる。

File Search移行で確認すること

File Searchを利用している場合、回答品質だけでなく検索資産の所有関係を確認する。

  • どのAssistantがどのVector Storeを参照しているか
  • Vector Storeが複数Assistantで共有されているか
  • ファイルの原本を自社で保持しているか
  • ファイル削除が検索インデックスへ反映されるか
  • 部門または利用者ごとのアクセス制御があるか
  • 引用情報を監査ログへ残しているか
  • Conversation移行後も同じ検索対象を参照するか

Vector Store IDだけを移しても、検索権限やファイル保持方針は自動的に正しくならない。

移行アーキテクチャ

推奨する構成は次である。

Client
  -> Application API
      -> Conversation mapping
      -> Agent configuration registry
      -> Responses API
      -> Tool execution gateway
      -> Retrieval policy
      -> Audit log

アプリケーション側に変換層を置き、旧Thread IDと新Conversation IDを対応付ける。

legacy_thread_id -> conversation_id -> customer_id -> retention_policy

この対応表には、移行日時、移行したメッセージ範囲、移行担当バージョン、検証結果も記録する。

段階移行の手順

第1段階：棚卸し

Assistant、Thread、Vector Store、File、Runの件数と所有者を抽出する。月間利用量と最終利用日を付ける。

第2段階：新規会話を切り替える

新しいユーザーまたは新しいチャットセッションだけをResponsesとConversationsへ送る。旧システムは既存Threadの継続に限定する。

第3段階：シャドー実行

同じ入力を旧Runと新Responseへ送り、ユーザーには旧結果だけを返す。比較する項目は次である。

  • 回答の正確性
  • Tool Callの回数
  • Tool引数の妥当性
  • File Searchの引用一致
  • 最初のトークンまでの時間
  • 完了までの時間
  • 入出力トークン
  • 失敗率
  • 人間への引き継ぎ率

副作用のあるツールはシャドー環境で実行しない。読み取り専用モックまたは記録済み結果を使う。

第4段階：既存Threadを選別して移植する

すべてを移さず、再開率、顧客重要度、法的保持、業務継続性を基準に優先順位を付ける。

第5段階：切り戻し期間を設ける

新規会話をResponsesへ切り替えた後も、旧Assistants経路を一定期間残す。切り戻しはConversationを削除するのではなく、ルーティングフラグで制御する。

第6段階：停止前に旧API通信をゼロにする

8月26日より前に、Assistants APIへの通信件数を監視し、ゼロが継続することを確認する。

評価で見落としやすい点

同じ回答でも状態が違う

短いテスト質問で同じ回答が返っても、20ターン後の履歴保持、Tool Call後の状態、ファイル追加後の検索結果が異なる可能性がある。

成功率だけでは不十分

HTTP 200でも、ツールが二重実行される、過去Threadの情報が欠落する、引用元が変わる場合がある。業務結果で評価する。

Promptの移植で品質が固定されるとは限らない

同じ指示文でも、モデル、ツール定義、履歴構造、出力形式が変われば結果は変わる。Prompt本文だけを差分比較して移行完了と判断しない。

編集部分析

Assistants APIの終了は、OpenAIが「サーバー上のAssistantオブジェクトを中心に組み立てる設計」から、「Responseを中心に、会話状態と実行構成を分離する設計」へ移ったことを意味する。

この変更は柔軟性を高める一方、アプリケーション側が負う責任も増やす。どの設定で実行したか、どの会話状態を参照したか、どのツールを許可したかを、自社で明示的に管理しなければならない。

移行の成否を決めるのはAPI互換性ではなく、状態の正本をどこに置くかである。会話履歴、業務状態、Agent設定、評価基準を一つのベンダーオブジェクトへまとめると、次の移行でも同じ問題が起きる。

今回の移行を機に、会話はConversation、業務データは自社DB、Agent設定はGit、実行証跡は監査基盤というように、責務を分離するべきである。

実務チェックリスト

  • [ ] Assistants、Threads、Runsの利用箇所を全環境で検索した
  • [ ] Assistant IDとThread IDの保存場所を特定した
  • [ ] Vector Storeとファイル原本の所有関係を確認した
  • [ ] 新規会話をConversations APIへ切り替えた
  • [ ] 既存Threadの移植基準を決めた
  • [ ] Assistant設定をコードと設定ファイルへ分解した
  • [ ] Reusable Promptを長期的な正本にしていない
  • [ ] Tool Callの冪等性と権限検証を実装した
  • [ ] 旧Runと新Responseをシャドー比較した
  • [ ] 会話、設定、ツール実行を結ぶ監査IDを保存した
  • [ ] 切り戻し用ルーティングを用意した
  • [ ] 2026年8月26日より前に旧API通信がゼロになった

一次情報