【訂正】Assistants API終了後の確認票

2026年9月5日訂正： 旧稿の「動いていたBotが停止」という見出しは、実際の障害を確認した表現ではありませんでした。終了前の履歴取得サンプルを終了後の手順のように紹介した点と、ファイルがそのまま引き継がれるという説明も訂正します。以下は公開資料の照合と、そこから作成した確認票です。Botの復旧・データ移行の実測記事ではありません。

終了の事実と、個別のBotの状態は別に確認する

9月5日に開いた公式移行ガイドは、Assistants APIが2026年8月26日に終了し、利用できなくなったことを明記している。新しい連携はResponses APIを使う案内となっている。

ただし、これだけで特定のBot全体が停止したとは判断できない。すでに移行した処理や別経路を持つツールまで同じ状態とは限らない。旧稿の「停止している可能性が高い」「気づいていないこと自体が障害のサイン」という一般化は撤回した。まず担当者が管理する範囲で、実際の呼び出し先と失敗した処理を確認する必要がある。

本稿の確認日と記事初出日は分けて表示した。実際のAPI呼び出し、利用者のログ調査、設定変更、データ取得は今回行っていない。記事に書かれた終了日を確認する作業と、自分のサービスへの影響を調べる作業は別である。

会話履歴は「今から旧APIで取得する」前提にしない

移行ガイドの会話移行の節には、掲載例は終了前の移行を示すもので、Threadのメッセージを取得する旧API呼び出しはもう動かないと注意書きがある。過去の履歴を維持する場合は、アプリケーション側で保存していたメッセージを使う案内である。

旧稿はこの時点の違いを落とし、「メッセージを1件ずつ変換するコードを作ればよい」と読める説明にしていた。手元に履歴のコピーがあるかどうかで、次にできることは変わる。古いコード例をそのまま実行すれば履歴を取得できる、あるいは履歴を必ず復元できるとは案内しない。

最初に調べるのは、保存済みメッセージの所在、保存期間、対象の利用者、添付やツール出力を含む範囲である。見つからないデータは「なし」と即断せず、担当者と既存の保存先を確認して「所在未確認」と記録する。ただし、あるはずだという期待だけで移行完了にはしない。復元可否が分からない状態と、新しい会話を開始できる状態も分けて扱う。

設定と検索資料も、自動で移ったとは見なさない

旧稿の「自動化ツールがなく手動書き換えが前提」という断定は範囲が広すぎた。公式資料に載る操作やサンプルの存在と、履歴・設定・動作のすべてが自動移行されることは別である。手作業しかできないとも、任せれば全部移るとも決めつけず、自分の移行対象を確認する。

特に注意したいのが設定である。移行ガイドにはAssistantからPromptを作る案内も残っているが、廃止予定では、再利用可能なprompt objectsと v1/prompts の終了予定は 2026年11月30日。古い対応表だけで長期運用の移行先を決めない。別の移行ガイドは、管理されたprompt objectの内容をアプリケーションコードへ移す方針を示している。これは「プロンプトという文章が使えなくなる」という意味ではない。

検索資料については、ResponsesのFile searchガイドで、対象のvector store IDを vector_store_ids に指定する構成を確認した。旧稿の「ベクトルストアやファイルが引き継がれる」は、自動で検索設定まで引き継がれるかのような説明になっていた。対象の保存状態、アクセスできる範囲、参照先の指定、意図した資料を検索できるかはそれぞれ確認する。本稿では既存ファイルの残存や再利用を実環境で確認していない。

実務への影響：移行対象と合格条件を分けて記録する

以下は今回作成した確認票であり、公式の指定書式ではない。単に「APIを変更済み」と記録せず、何を移したか、何を確認できたかが分かるようにする。実データや秘密値の貼り付けは不要で、管理された記録への参照と担当者を残せばよい。

対象	最初に確かめること	移行後に残す確認結果
会話履歴	アプリ側の保存済みメッセージの所在と範囲	必要な発言・順序・利用者の対応が保たれたか
設定	指示文、モデル、ツール定義の保存先と版	必須の回答条件やツール指定が欠けていないか
検索資料	対象ファイルと検索先、アクセス範囲	期待する資料が見つかり、対象外資料が混ざらないか
処理の流れ	ツール実行、再試行、失敗時の扱い	重複した外部処理や未処理の放置がないか

例えば「新しい会話への返答は成功したが、旧履歴は所在未確認」という仮の結果なら、新規応答の確認は済んでも履歴移行は未完了である。別の仮の例で、資料検索の回答が返っても、参照した文書が違えば検索資料の検収は通さない。この2例は判定方法の説明であり、顧客環境の実測ではない。

少数の人工入力で確認を始めるなら、履歴が必要な追加質問、指定した資料に答えがある質問、資料に答えがない質問、ツール処理が失敗する条件を分けて用意する。先に期待結果を決めておき、返答が出たことだけを成功と数えない。課金や外部への書き込みが起きる試験は、実行前に権限と範囲を確認する。

保存していた会話を新しいシステムへ渡す際は、内容だけでなく誰の会話か、誰が読めるかも確認する。足りない履歴をAIに補完させ、それを元の利用者の発言として登録する方法は採らない。取得不能・未確認の範囲はそのまま残し、新規対応と過去履歴の復旧を別の判断にする。

今回の訂正範囲と残る限界

終了日そのものは現行の公式ガイドで確認できた。一方、個別のBot停止、自動化ツール全般の不存在、ファイルや検索設定の自動引き継ぎ、履歴を必ず取り出せるような案内は、この調査の根拠を超えるため撤回・修正した。読者が要する工数や復旧の成功率も、資料だけでは分からない。

本稿は旧ニュース記事の訂正であり、完全な移行実装例ではない。移行先のモデルにも別の終了予定があり得るため、設定を点検するときはo3の記事で作った期限確認票のように、APIの種類とモデルIDの期限を分けて記録してほしい。