それなら、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を使った実績を作ることではありません。いま動いている仕事を止めず、次の変更にも対応しやすい形へ組み直すことです。

新しいモデル、新しい料金、新しい機能。ひとつ調べると関連情報が何本も出てきて、どこまで読めばいいのか分からなくなります。

サイトを運営しているなら、全部を知る必要はありません。今週の予定を変える情報と、あとで読めばいい情報を分ければ十分です。

2026年7月13日から19日までの公式発表を見直すと、先に片づけたいことは4つでした。WordPressの更新、Assistants APIの棚卸し、API料金の計測、画像生成の使い分けです。

ニュースの大きさではなく、記事公開や問い合わせ、収益につながる入口を守る順番で見ていきます。

今週の最優先は、WordPress 7.0.2への更新

今週、最初に見るのはAIの新機能ではありません。

WordPressの管理画面です。

WordPress.orgは7月17日、WordPress 7.0.2を公開しました。Criticalが1件、Highが1件のセキュリティ問題を修正した更新で、影響を受けるサイトにはすぐに更新するよう案内しています。

自動更新の対象になっているサイトでも、通知メールを読んで終わりにはしません。管理画面を開き、いま使っているバージョンを確かめます。

7.0系なら7.0.2、6.9系なら6.9.5、6.8系なら6.8.6が今回の修正版です。6.8より前は今回の二つの問題には影響を受けないとされていますが、古いWordPressをそのまま使ってよいという意味ではありません。

更新する前に、データベースとファイルのバックアップを確認します。バックアップが「ある」だけでは足りません。いつ取られたものか、どこまで戻るのか、自分で復元できるのかまで見ておきます。

ステージング環境があれば、先に同じ更新を適用します。トップページの表示だけでなく、記事、検索、404ページ、下書き保存、問い合わせフォーム、REST APIまで確認します。

トップページが表示されても、決済や問い合わせフォームまで動いているとは限りません。更新後は、収益や仕事につながっているページから優先して開きます。

どこでAssistants APIを使っているか確認する

OpenAIのAssistants APIは、2026年8月26日に終了する予定です。

使っていなければ、移行作業はありません。困るのは、以前作った仕組みに入っているのを忘れている場合です。

記事作成、問い合わせ対応、社内検索など、AIを呼び出しているコードを検索します。assistants、threads、runsといった名前のほか、Assistant IDやThread IDを保存している場所も確認します。

公式の移行ガイドでは、Assistant、Thread、Run、Run stepの役割を、Prompt、Conversation、Response、Itemへ移す流れが示されています。

ただし、名前を置き換えるだけでは終わりません。会話履歴をどこへ残すか、ツールが失敗したときに誰が再実行するか、古いThreadをどこまで引き継ぐかを決める必要があります。

もう一つ気をつけたいのがPromptです。既存のAssistantから再利用可能なPromptを作る経路はありますが、そのPromptも2026年11月30日に終了予定です。長く使う仕組みなら、指示文やツール設定の原本をアプリ側でも管理しておきます。

今週中に全面移行を終わらせる必要はありません。

まず、Assistants APIを使っているファイル、処理の名前、止まったときに影響するページを一枚にまとめます。下書きが作れなくなるのか、問い合わせへの返事が止まるのか。それが分かれば、移行順を決められます。

8月26日当日に切り替えるのでは遅すぎます。旧処理へ戻せる期間を残し、少なくとも本番とは別の場所で一度動かしておきたいところです。

API料金を知りたいなら、まず1回分を測る

GPT-5.6にはSol、Terra、Lunaがあり、料金も違います。

だからといって、一番安いLunaを選べば月額が下がる、とまでは言えません。

OpenAIのAPI料金は、入力、キャッシュ済み入力、キャッシュへの書き込み、出力などで単価が分かれます。短い指示から長い記事を作る処理と、長い資料を読ませて短く分類する処理では、お金のかかる場所が違います。

先に見るのはモデルの料金表ではなく、自分の処理一回分です。

入力と出力のトークン数、キャッシュの利用量、再試行した回数を記録します。Web検索や画像生成などのツールを使った場合は、その費用も別に足します。

1回分の費用に、ひと月の実行件数を掛ければ、月の予算が見えてきます。

ブログ記事なら、人が直した時間も外せません。安いモデルで3回作り直し、タイトルと出典の確認に1時間かかったなら、API料金だけを比べても実際の負担は分かりません。

反対に、分類や定型の要約など、同じ条件で大量に処理する仕事では、低価格のモデルが効きやすくなります。

今週やるのは、料金表を暗記することではありません。実際の処理を一件だけ動かし、公開できるところまでに何円と何分かかったかを残します。

画像を1枚作るならImage API、何度も直すならResponses API

OpenAIの画像生成には、Image APIとResponses APIという二つの入口があります。

ブログの見出し画像を一枚作る。手元の画像を一度だけ直す。同じ仕様で何枚か生成する。こうした作業なら、Image APIから始めると流れが単純です。

一方で、作った画像を見ながら「背景だけ変える」「表情をもう少し明るくする」と何度も調整するなら、Responses APIが使いやすくなります。前の画像を会話の流れに残したまま、編集を続けられるためです。

Responses APIでは、画像生成だけでなく、会話に使うメインモデルのトークン料金もかかります。便利さだけで決めず、採用できる一枚までに何回やり直したかを記録します。

キャラクター画像では、かわいく生成できたかだけで終わりません。同じ人物に見えるか、手やツノに不自然なところがないか、読めない文字や見覚えのあるロゴが入っていないかも確認します。

記事へ載せる前には、スマートフォンでも開きます。横長の画像でキャラクターの顔が切れていないか、文字を入れた場合は小さな画面でも読めるかを見ます。

画像生成で時間を使いすぎる人は、API選びより先に「何回直したら別案へ移るか」を決めてもよさそうです。ボツを減らすには、生成回数だけでなく、採用までの流れを見直す必要があります。

今週やることを4つに絞る

ここまでの話を、実際の作業へ戻します。

1. WordPressのバージョンとバックアップを確認し、修正版へ更新する
2. Assistants APIを使っているファイルと処理を洗い出す
3. API処理一回分のトークン、再試行、作業時間を記録する
4. 画像一枚が採用されるまでの修正回数を数える

立派な調査資料は必要ありません。

WordPressなら、更新前後のバージョンと確認したページをメモに残す。Assistants APIなら、ファイル名と止まる機能を表にする。料金と画像は、実際の一件を測ります。

時間が足りない場合は、上から二つだけでも構いません。WordPressには今回のセキュリティ更新があり、Assistants APIには終了日があります。料金と画像の改善は、そのあとでも試せます。

やる順番が決まれば、ニュースを追う時間を減らし、サイトの手入れへ戻れます。

ニュースは「今週の仕事が変わるか」で選ぶ

週間まとめで難しいのは、何を載せるかより、何を載せないかです。

新しいモデルが発表された。デモ動画が話題になった。SNSで多く共有されている。それだけでは、今週の作業を変える理由にはなりません。

期限がある。公開サイトが止まる。料金や権利に影響する。今の仕事の進め方が変わる。AIやまらぼでは、まずこの順番で見ます。

この基準なら、今週はWordPress 7.0.2とAssistants APIが先です。API料金と画像生成は、慌てて契約や実装を変える段階ではなく、自分の使い方を測り始める段階です。

ニュース記事を増やせば、検索から読まれる入口も増えます。ただ、読者が「結局どうすればいいの」と感じる記事ばかりでは、次に戻ってくる理由にはなりません。

一本の記事を読んだら、一つでも作業を終えられるようにする。

WordPressを更新できた。古いAPIの場所が分かった。ひと月の予算が見えた。画像のボツが減った。そうした小さな成果が、読者がもう一度サイトへ戻る理由になります。