Assistants APIを使った自動投稿が、いまは普通に動いている。
それなら、8月に入ってから移行しても間に合いそうに見えます。
けれど、OpenAIが案内している終了日は2026年8月26日です。その日に動かなくなる可能性があるのはAPIだけではありません。WordPressの下書きが作られない。問い合わせへの返事が返らない。止まった処理を、人が手作業で補うことになります。
今回の移行は、接続先のURLをResponses APIへ変えるだけでは終わりません。指示文、会話履歴、ツールの実行、古いThreadの保存先を順番に分け直す必要があります。
いきなりコードを書き換える前に、どこでAssistants APIが使われていて、止まると何が困るのかを確認します。
移行以外の対応も重なっているなら、今週の作業を4つに絞った記事で優先順位を決めてから戻ってくると、API調査に使える時間を確保しやすくなります。
最初に、どこでAssistants APIを使っているか探す
最初に検索するのは、assistants、threads、runsといったAPI名です。
ただ、ソースコードの一行を見つけただけでは足りません。
Assistant IDを環境変数に入れているかもしれません。Thread IDをデータベースへ保存していることもあります。管理画面の設定、定期実行するCron、外部サービスのWebhookにも古いIDやURLが残ります。
見つけた場所ごとに、その処理が何をしているかを一行で書きます。
記事の構成を作る。問い合わせ文を分類する。社内資料を検索する。WordPressへ下書きを保存する。同じAssistants APIでも、止まったときの影響は違います。
次に、Assistantへ何を持たせているかを確認します。モデル、指示文、ツール定義、出力形式。Threadには、メッセージだけでなく、ファイルや独自のIDを紐づけている場合があります。
Runを開始したあと、完了するまでどこで待っているかも見ます。ツールを呼ぶとき、実際の処理を動かしているのはどの関数か。失敗したときに何回やり直すのか。同じ処理を二重に実行しない仕組みがあるか。
ブログの自動投稿なら、二重実行で同じ下書きが二本できます。メールや注文を扱う処理では、同じ通知が二度送られるかもしれません。APIの置き換えより先に、この流れを一枚へまとめます。
Assistant・Thread・Runは、何に置き換わる？
公式の移行ガイドでは、Assistant、Thread、Run、Run stepの役割が、それぞれPrompt、Conversation、Response、Itemへ移ると説明されています。
これは、単語を一対一で置換するための表ではありません。
Assistantは、モデル、指示、ツールを一つのAPIオブジェクトとして持っていました。公式ガイド上のPromptは、AIにどう振る舞わせるかという設定を持ちます。
Threadはメッセージを保存していました。Conversationは、メッセージだけでなく、ツール呼び出しやツールの結果もItemとしてまとめて扱います。
Runは、Threadに対してAIを動かす処理でした。Responses APIでは、入力を送り、Responseとして出力Itemを受け取ります。途中でツールが必要になれば、アプリ側がツールを実行し、その結果を次の入力へ返します。
自動投稿の仕組みに当てはめると、記事の書き方は指示文、過去のやり取りはConversation、一回の下書き生成はResponse、検索結果やWordPressへの保存結果はItemとして考えられます。
この分け方を先に決めると、文章のルールを直す作業と、WordPressへ保存する処理を分けられます。移行後に記事の見出しだけ変えたいとき、投稿処理まで触らずに済みます。
再利用可能なPromptは11月30日に終了。指示文はアプリ側へ移す
Assistants APIの移行ガイドには、既存のAssistantからPromptを作る経路があります。
ただし、再利用可能なPromptも2026年11月30日に終了する予定です。
Assistant IDをPrompt IDへ置き換えるだけでは、数か月後にもう一度同じ問題を抱えます。OpenAIの廃止予定ページは、再利用可能なPromptの内容をアプリケーションコードへ移すよう案内しています。
指示文をコードへ直書きするという意味ではありません。専用の設定ファイルや管理画面でバージョンを管理し、変更履歴を残せる形にします。
たとえば記事生成なら、文体、見出し数、出典の出し方、禁止事項を一つの設定として保存します。どの版を、いつ、どの記事に使ったかも残します。
指示文を変えると、文章の雰囲気だけでなく、記事の長さや引用方法まで変わります。検索から読まれ、問い合わせや収益につながる記事なら、単なる技術設定ではなく編集ルールの変更です。
Promptを一時的な移行先として使う場合も、11月30日より前に外せる予定を作ります。今回の移行先が、次の廃止予定へそのまま依存しない形にします。
古いThreadは、必要なものからConversationへ移す
既存のThreadをConversationへ一括で移す自動ツールは提供されません。
公式ガイドは、新しい会話を先にConversationとResponses APIへ移し、古いThreadは必要に応じてあとから移す方法を案内しています。
すべてのThreadを同じ日に移す必要はありません。
いま対応中の顧客、進行中の案件、業務上保存が必要な履歴から始めます。何年も開かれていない会話まで先に移すと、確認作業だけが増えます。
古いThreadを移す場合は、メッセージの本文だけで判断しません。画像、ファイル、ツールの入出力、アプリ側で付けた顧客IDが欠けていないかを確認します。
移さないThreadをいつまで保存するかも決めます。Assistants APIの終了後も同じ方法で読めるとは考えず、必要なデータは自分の保存方針に合わせて退避します。
個人情報や顧客の資料を含む場合は、Conversationへ移してよいデータかも確認します。移行を理由に、必要のない履歴まで新しい保存先へ複製しないようにします。
新規の会話から切り替えると、旧処理との比較もしやすくなります。同じ種類の入力を両方へ流し、出力、ツールの実行回数、処理時間、費用を比べます。
移行テストでは、二重投稿と再試行を確認する
一度成功しただけでは、本番へ切り替えられません。
外部APIが遅い。WordPressが500エラーを返す。ツールの結果を返す前に処理が落ちる。同じResponseをもう一度送ってしまう。実際の運用では、こうした失敗が起こります。
タイムアウトするまでの時間と、再試行する回数を決めます。途中で止まった場合は、どこから再開するのかも記録します。
WordPressへ投稿する処理には、同じautomation IDの下書きがないかをサーバー側で確認する仕組みを残します。クライアントからstatus: draftを送るだけでなく、自動投稿用ユーザーから公開権限を外しておきます。
テストでは、意図的に一回失敗させます。WordPressの保存処理を止める、ツールからエラーを返す、同じリクエストを二度送る。下書きが重複せず、途中の状態をログから追えるかを確認します。
費用も比較します。会話履歴の渡し方やツールの回数が変われば、入力トークンと実行回数も変わります。モデルの単価だけでなく、人が確認できる下書き一件を作るまでの合計を見ます。
記事制作では、生成が速いことより、出典が残ること、下書きとして保存されること、同じ記事が重複しないことを先に確認します。読者の目に触れる前の安全装置を、移行で外さないためです。
本番の切り替えは8月26日より前に済ませる
8月26日は、本番へ切り替える日ではありません。
Assistants APIが終了する日です。
不具合が見つかったときに旧処理へ戻せるよう、本番切り替えは前倒しします。
最初は開発環境やステージングで動かします。次に新しい会話の一部だけをResponses APIへ流し、文章、ツール結果、費用、保存、ログを比べます。
問題がなければ、新しい処理へ送る会話の割合を増やします。旧処理へ戻すスイッチは、移行後もしばらく残します。
切り替え後には、Assistant ID、古いエンドポイント、Threadを読む処理が、コード、環境変数、Cronに残っていないかをもう一度検索します。使わなくなった認証情報は、復旧に不要なことを確認してから無効にします。
読者にとっては、Assistants APIがResponses APIへ変わったことより、記事が予定どおり公開され、問い合わせへの返事が届くことの方が大切です。
移行の目的は、新しいAPIを使った実績を作ることではありません。いま動いている仕事を止めず、次の変更にも対応しやすい形へ組み直すことです。
Assistants API移行で、今やること
- コード、環境変数、データベース、CronからAssistants APIを使っている場所を探す。
- 指示文、会話履歴、ツール実行、保存先を分け、古いThreadは必要なものから移す。
- 8月26日より前に本番を切り替え、二重投稿、再試行、旧処理へ戻す手順を確認する。
最初にやるのはコードの書き換えではありません。Assistants APIが見つかった場所と、止まったときに困る仕事を一枚へ書き出します。