OpenAIのAssistants API(アシスタントAPI)は、会話履歴とツール実行の状態をOpenAI側に預けてAIアシスタントを作るためのAPIでした。2023年11月にベータ公開され、2025年8月26日に廃止が告知され、2026年8月26日に終了しました。公式のAssistants移行ガイドは冒頭で「officially sunset on August 26, 2026, and is no longer available」と明記しています。既存コードの移行や、旧APIを前提とする解説の読み替えには、終了後の仕様確認が必要です。どちらの場合も行き先はResponses API(会話を保存するならConversations APIと併用)です。この記事では、Assistants APIの仕組みを移行に必要な範囲で振り返り、終了後に何が起きているか、どこへ何を移すかを2026年10月28日時点の公式ドキュメントで整理します。
まとめ:Assistants APIの終了状況と移行の要点
- 状態:2026年8月26日に終了し、現在は利用できない。新規採用はできない。
- 会話履歴:Threadのメッセージを取り出すAPIも止まっている。移せるのは自社で保存していた履歴だけ。
- SDK:openai Python 3.40.0(2026年10月27日)にも
client.beta.assistantsとclient.beta.threadsが残る。importは通り、呼ぶとDeprecationWarningが出て、APIは応答しない。 - 移行先:Thread→Conversation、Run→Response、Run Step→Item。Assistantの受け皿だったPromptsは2026年11月30日に終了予定なので、指示とツール定義はアプリのコードに持つ。
- ツール:File Searchは同じベクトルストアを
vector_store_idsで渡す。Code Interpreterはコンテナ単位の課金(1GBで20分$0.03)に変わり、20分使わないと中のファイルごと消える。 - Azure:Azure OpenAIのAssistantsも終了済み。Foundry Agent Serviceへの移行ツールはエージェント定義やThread・Message・Runの作成コードを変換するが、過去の状態データは移さない。
Assistants APIの仕組み:Thread・Runで会話状態を預けるAPI
移行で何を置き換えるかを決めるために、旧APIの構造を確認しておきます。古いコードを読むときの手がかりにもなります。
Assistant・Thread・Message・Runの4オブジェクトと非同期実行
- Assistant(
asst_で始まるID):モデル・指示(instructions)・ツールを束ねた設定。APIで作成・更新した。 - Thread(
thread_):1つの会話。メッセージをサーバー側に保持し、モデルの文脈長を超えると自動で古い分を切り詰めた。 - Message:Threadに積むユーザーとアシスタントの発話。
- Run(
run_):AssistantをThreadに対して実行する処理。queued→in_progress→completedと非同期に進むため、runs.retrieveで状態を確認するポーリングや、ストリーミングで完了を待つ方式を使った。関数呼び出しではrequires_actionで止まり、結果を返して再開させた。
古いコードに client.beta.threads.runs.create と while run.status in ("queued", "in_progress") のポーリングがあれば、それがAssistants APIの実装です。REST直呼びでは OpenAI-Beta: assistants=v2 ヘッダが付いています。v1ベータは2024年12月18日に先に止まっています(OpenAIの廃止一覧)。
組み込みツール3種と終了時点の料金
Assistants APIの利点は、Code Interpreter(サンドボックスでのPython実行)、File Search(ベクトルストアを使った文書検索)、Function calling(自社の関数を呼ばせる)を設定だけで使えた点でした。料金はモデルのトークン代にツール代を足す形で、Assistants API向けの別料金はありません。現在の料金ページも「Assistants APIは別建てで価格設定していない」と書いています。File Searchの保存は$0.10/GB/日(1GBまで無料)で、Responses APIでも同じ単価です。
Assistants APIの終了日と既存システムへの影響
告知から終了まで1年の経緯
| 日付 | 出来事 |
|---|---|
| 2024年4月 | v2ベータ公開 |
| 2024年12月18日 | v1ベータ停止 |
| 2025年3月 | Responses API公開 |
| 2025年8月26日 | Assistants APIの廃止を告知 |
| 2026年6月3日 | Prompts(再利用プロンプト)の廃止を告知 |
| 2026年8月26日 | Assistants API終了 |
| 2026年11月30日 | v1/prompts 終了予定 |
廃止一覧には「Responses APIを2025年3月に公開した際、Assistants APIの機能をすべてResponses APIへ移し、2026年に終了させる計画を発表していた」とあります。終了日の後継欄は「Responses API and Conversations API」です。
Thread履歴の取得停止と保存済みデータの確認
移行で最も影響が大きいのがこの点です。移行ガイドは終了前に使えた履歴の移し方(threads.messages.list で全件取得してConversationへ入れる)を載せたうえで、「Threadのメッセージを取得するAssistants APIの呼び出しはもう動かない。保存済みのメッセージを使う」と注記しています。終了前にエクスポートしていなかった会話は、OpenAIのAPIからは取り戻せません。
そのため移行作業の最初にやるのは、自社のDBやログにどこまで会話が残っているかの棚卸しです。Assistants APIは履歴をサーバー側で持つ前提だったので、ユーザーIDとThread IDの対応だけを保存し、本文を保存していない構成では、移行に使えるメッセージ本文がありません。この場合、過去の会話は引き継げません。新しい会話から始めると利用者に案内するしかありません。
SDKにはメソッドが残る:openai 3.40.0での実測
PyPIで2026年10月27日に公開されたopenai 3.40.0を入れ、APIキーを使わずにローカルで確認しました(base_url を接続先の無いアドレスに向けた検証)。client.beta.assistants・client.beta.threads は今も存在し、client.beta.assistants.list() を呼ぶと DeprecationWarning: deprecated が出てから通信に進みました。メソッドには @typing_extensions.deprecated が付いているだけです。
このバージョンではメソッドが残るため、importだけでは終了を検出できません。ただし、非推奨診断に対応した型チェッカーで診断を有効にすれば、実行前に呼び出し箇所を検出できます。Pythonの既定の警告設定では、__main__ 以外のモジュールから呼んだ DeprecationWarning は表示されません。CIで python -W error::DeprecationWarning を付けてテストを走らせると、残っている呼び出しを洗い出せます。
移行先の選び方:Responses API・Agents API・Foundry Agent Service
| 今の状況 | 移行先 |
|---|---|
| OpenAI本家のAssistantsでチャットを作っていた | Responses API+Conversations API |
| Runに数分〜数時間の処理を任せていた | Responses APIのバックグラウンドモード、またはAgents API(ベータ) |
| Azure OpenAIのAssistantsを使っていた | Foundry Agent Service |
OpenAI本家の既存実装はResponses API+Conversations API
公式の移行先です。Responses APIは入力のItemを渡して出力のItemを受け取る形で、1回のリクエストの中でWeb検索・File Search・Code Interpreter・リモートMCPなどのツールを回せます。会話をサーバーに残したいときはConversations APIで会話オブジェクトを作り、そのIDを conversation に渡します。会話状態のガイドによると、Conversationとその中のItemには、Responseに通常かかる30日の保存期限が適用されません。Chat Completions APIとの違いや、Responses APIへ移さない方がよい条件はOpenAI Responses APIとChat Completions APIの違いで扱っています。
長時間のエージェント処理をサーバーに任せたい場合はAgents API
Runの「投げておいて後で結果を取りに行く」使い方を引き継ぎたいなら、選択肢は2つです。1つはResponses APIのバックグラウンドモードで、background=True を付けて送り、queued か in_progress の間は取得を繰り返します。もう1つは2026年9月に公開されたAgents API(パブリックベータ)で、公式の概要は「OpenAIが管理するAPIでCodexハーネスを使える」「セッション・オーケストレーション・コンテキスト圧縮・復旧はOpenAIが管理する」と説明しています。単純な質問応答のチャットならResponses APIで足ります。Agents APIはサンドボックスでコードを動かす長い作業向けで、ベータであることも含めてOpenAI Agents APIの解説で採否を判断してください。
Azure OpenAI AssistantsからFoundry Agent Serviceへの移行範囲
Microsoft Learnの旧Assistants解説(Foundry classic)は冒頭に「The Assistants API is retired.」と掲げています。移行先のFoundry Agent Serviceの移行ガイドは、GitHubの移行ツールを案内しています。変換対象はエージェント定義と、Thread・Message・Runを作成するコードです。一方で「過去のrun・thread・messageといった状態データは移さない」と明記されているため、保存済み履歴の所在と移し方は別に確認します。Foundry側の料金や構成はFoundry Agent Serviceの解説にまとめています。
Responses APIへの移行手順:対応表とPythonコード
Assistant・Thread・Run・Run Stepの対応
| Assistants API | 移行先 | 実装の変わり方 |
|---|---|---|
| Assistant | アプリのコード | instructions・tools をリクエストごとに渡す |
| Thread | Conversation | メッセージ以外のItemも保持 |
| Run | Response | 既定は同期。ポーリング不要 |
| Run Step | Item | 出力の配列で受け取る |
| requires_action | function_call のItem | call_id を付けて結果を返す |
移行ガイドの対応表ではAssistantの移行先はPromptsになっています。ただ、同じガイドの手順欄に「再利用プロンプトも廃止予定」と注記があり、Promptsからの移行ガイドは「プロンプトの内容をアプリのコードへ移す」ことを求めています。2026年10月にAssistantからPromptへ移すと、1か月後にもう一度移行することになります。最初からコードに持つのが正解です。
もう1つ注意が要るのはinstructionsの扱いです。openai SDKの型定義の説明では、conversation を指定したResponseで会話に自動追加されるのは入力と出力のItemです。instructionsはこれに含まれないので、Assistantに持たせていた指示は毎回のリクエストで渡します。
保存済みの会話履歴をConversationへ載せ替えるコード
自社DBに保存した、roleがuserまたはassistantでtextが文字列の履歴を、古い順にConversationへ入れ、続きの質問にFile Search付きで答えさせる例です。ユーザーの発話は input_text、アシスタントの発話は output_text にする点が移行ガイドの変換と同じです。
import os
from openai import OpenAI
client = OpenAI()
MODEL = os.environ.get("OPENAI_MODEL", "gpt-6-astra")
INSTRUCTIONS = "あなたは社内規程に答えるアシスタントです。根拠の文書名を添えて答えます。"
def to_items(saved_messages):
"""自社DBの {"role", "text"} の並びを Conversations API の item に変換する"""
items = []
for m in saved_messages:
part_type = "input_text" if m["role"] == "user" else "output_text"
items.append({"role": m["role"], "content": [{"type": part_type, "text": m["text"]}]})
return items
def migrate_and_continue(saved_messages, question, vector_store_id):
items = to_items(saved_messages)
# 1回に追加できるItemは20件まで。21件目以降は items.create で分けて追加する
conversation = client.conversations.create(
items=items[:20],
metadata={"migrated_from": "assistants"},
)
for i in range(20, len(items), 20):
client.conversations.items.create(conversation.id, items=items[i:i + 20])
response = client.responses.create(
model=MODEL,
instructions=INSTRUCTIONS,
conversation=conversation.id,
input=question,
tools=[{"type": "file_search", "vector_store_ids": [vector_store_id]}],
)
return conversation.id, response.output_text
移行ガイドの例は全メッセージを1回の conversations.create に渡していますが、SDKの型定義には「1回に追加できるItemは20件まで」とあります。長い会話はそのままでは入らないため、上のコードでは21件目以降を conversations.items.create で20件ずつ足しています。openai 3.40.0で通信をモックに差し替え、45件の履歴を渡すと POST /v1/conversations に20件、/v1/conversations/{id}/items に20件と5件が送られ、最後の POST /v1/responses に conversation・instructions・tools が載ることを確かめました。モデルIDは最新モデルのガイドが2026年10月時点で挙げる gpt-6-astra を既定にし、環境変数で差し替えられるようにしています。SDKの導入や認証の設定はOpenAI Python SDKの使い方にあります。
requires_actionからfunction_call_outputへの処理変更
Assistants APIでは、Runが requires_action で止まったら submit_tool_outputs で結果を返していました。Responses APIでは、出力に function_call のItemが含まれていたら関数を実行し、同じ call_id を付けた function_call_output を次のリクエストの入力に入れます。Conversationを使っていれば、前のResponseの関数呼び出しは会話に自動で入っているので、送るのは結果だけです。
import json, os
from openai import OpenAI
client = OpenAI()
MODEL = os.environ.get("OPENAI_MODEL", "gpt-6-astra")
TOOLS = [{
"type": "function",
"name": "get_order_status",
"description": "注文番号から配送状況を返す",
"parameters": {
"type": "object",
"properties": {"order_id": {"type": "string"}},
"required": ["order_id"],
"additionalProperties": False,
},
"strict": True,
}]
def get_order_status(order_id):
return {"order_id": order_id, "status": "出荷済み"} # 実際は自社DBを引く
def ask(conversation_id, text):
response = client.responses.create(
model=MODEL, conversation=conversation_id, input=text, tools=TOOLS,
)
while True:
calls = [item for item in response.output if item.type == "function_call"]
if not calls:
return response.output_text
outputs = [{
"type": "function_call_output",
"call_id": call.call_id,
"output": json.dumps(get_order_status(**json.loads(call.arguments)), ensure_ascii=False),
} for call in calls]
response = client.responses.create(
model=MODEL, conversation=conversation_id, input=outputs, tools=TOOLS,
)
モックで1回目に function_call を返させると、2回目のリクエストの input が call_id 付きの function_call_output だけになり、最終的にテキストの回答が返ることを確認しました。関数を複数持たせる場合は call.name で振り分けます。本番実装では関数呼び出しの往復回数に上限を設け、上限到達時は処理を中断して利用者へ通知します。関数定義の書き方はFunction Callingの解説を参照してください。
File SearchとCode Interpreterの引き継ぎ
File Searchのベクトルストアは v1/vector_stores のオブジェクトで、Responses APIでは上のコードのように tools の file_search に vector_store_ids で渡します。File Searchのガイドのアップロード例も今なお purpose="assistants" を使っています。既存のベクトルストアIDを使い回す前に、client.vector_stores.list() で残っているか、期限切れになっていないかを確かめてください。料金と対応形式はOpenAI File Searchの解説にあります。
Code Interpreterは仕組みが変わりました。Code Interpreterのガイドによると、Responses APIでは実行環境が「コンテナ」になり、"container": {"type": "auto"} で自動作成するか、v1/containers で明示的に作ります。コンテナは20分使われないと失効し、中のデータは復元できません。生成されたファイルは失効前にダウンロードします。料金はメモリ1GBで20分あたり$0.03、4GBで$0.12で、対象のセッションは分単位・最低5分で課金されます(料金ページ)。
移行で失敗しやすい3つの判断
終了後の移行では、終了前の移行記事の手順をそのまま追うと遠回りになる箇所があります。
- AssistantをPromptへ移す:対応表どおりに移すと、2026年11月30日の
v1/prompts終了でもう一度作業が発生します。指示とツール定義はコードとGitで管理します。 - Thread IDだけ保存して本文を捨てていた構成で、履歴の復元を約束する:OpenAI側の履歴はもう取れません。利用者には新しい会話から始まると先に伝えます。
- Conversationを作りっぱなしにする:Conversationには30日の期限がかかりません。退会や削除依頼への対応では、Conversation内のItemを削除したうえでConversationを削除する処理を用意します。Conversationだけを削除しても、内部のItemは削除されません。
逆に、Assistants APIで作っていたのが1往復で終わる問い合わせ応答なら、Conversationすら不要です。会話履歴を自社で持ち、毎回 input に入れて送るだけで済みます。社内向けのチャットボットを作り直すついでに、構成から見直したい場合はAPI開発・システム連携の支援も行っています。
よくある質問
OpenAI Assistants APIは廃止されたのですか?
はい。2025年8月26日に廃止が告知され、2026年8月26日に終了しました。公式の移行ガイドは「no longer available」としており、新しいアシスタントやスレッドは作れません。後継はResponses APIとConversations APIです。
終了後にAssistants APIを呼ぶとどうなりますか?
APIは処理されず、失敗が返ります。openai Python SDK 3.40.0にはメソッドが残っているため、importだけでは気付けませんが、対応する型チェッカーの非推奨診断では検出できます。呼び出し時に DeprecationWarning が出るので、テストで警告をエラー扱いにすると残った呼び出しを見つけられます。
過去のスレッドの会話履歴は取り出せますか?
OpenAIのAPIからは取り出せません。移行ガイドはThreadのメッセージを取得する呼び出しがもう動かないと明記し、自社で保存したメッセージを使うよう案内しています。Azure版の移行ツールもスレッドやメッセージは移しません。
Assistants APIとChat Completions API・Responses APIの違いは何ですか?
Chat Completions APIは会話の状態を持たず、毎回履歴を送る方式で、現在もサポートされています。Assistants APIはThreadで状態をサーバーに持ち、Runを非同期に実行する方式でしたが終了しました。Responses APIは既定では同期実行ですが、バックグラウンド実行にも対応します。Responseは既定で30日保存され、会話の継続にはprevious_response_idやConversationを使えます。
移行すると料金は変わりますか?
モデルのトークン代はどのAPIでも同じ単価です。File Searchは保存$0.10/GB/日(1GB無料)と呼び出し$2.50/1,000回で、呼び出し料金はResponses APIだけに適用されます。Code Interpreterの料金はコンテナのメモリ量に応じ、1GBでは20分セッションあたり$0.03です。ただし、対象セッションは分単位・最低5分で課金されます。
関連記事
- OpenAI Responses APIとChat Completions APIの違い|移行手順と見送る条件【2026年10月】
- OpenAI Agents APIとは?セッション実装・料金とSDKとの違い、Artifact SDK対応【2026年10月】
- OpenAI File Searchとは|Responses APIのベクトルストア検索・料金・対応形式
- Function Callingとは|仕組みとOpenAI APIでの実装をコードで解説
- Foundry Agent Serviceとは?旧Azure AI Agent Serviceからの移行・料金とブラウザ自動化の実装手順【2026年10月】