モデル選択画面からo3が消えたとき、最初に確認すべきなのは「どの製品で、いつ、何が終了したのか」です。
ChatGPTの画面で選べなくなることと、APIのモデルIDが停止することは別の変更です。
さらに、普通のChatGPTチャット、BusinessやEnterpriseの管理画面、CodexやWorkでは、表示される選択肢と課金の仕組みが一致しません。
OpenAIは2026年8月26日、90日間の移行期間を経てo3をChatGPTから退役させました。
公式リリースノートは、この変更がChatGPTに限られ、APIには変更がないと明記しています。
したがって「o3が完全廃止された」「APIコードを今すぐ全面改修しなければ停止する」という理解は正確ではありません。
一方、ChatGPT上でo3を選んでいた業務は、別モデルへ切り替えたときの出力差を無視できません。
移行で必要なのは、o3に似た名前を探すことではなく、o3に任せていた仕事を分解することです。
難しい判断、日常の文書作成、素早い反復、大量処理では、適切な推論強度とコストが違います。
本記事では、提供終了の範囲を整理し、重要なワークフローを壊さずに移す手順を示します。
公式のChatGPT Release NotesとModel Release Notesによると、o3は2026年8月26日にChatGPTから退役しました。
発表には90日間のサンセット期間があり、対象はChatGPTです。APIには変更がないと同じ記載の中で説明されています。
ニュースの見出しだけで「o3終了」と捉えると、この製品境界を見落とします。
ChatGPTでの退役後は、通常のモデルピッカーからo3を新たに選べません。
過去の会話が履歴から消えることと、モデルが退役することも別です。
OpenAIの法人向けレガシーモデル案内は、退役済みモデルはピッカーに表示されず、既存会話が新しい対応モデルへ移る場合があるとしています。
会話ログを読めても、新しいメッセージがo3で生成される保証にはなりません。
ここで注意したいのは、モデル終了がデータ削除の告知ではない点です。
チャット履歴、プロジェクト、添付ファイル、共有設定にはそれぞれ別の保持・管理ルールがあります。
重要な業務でo3を使っていた場合は、対象会話を開いて現在選択されているモデルを確認し、同じ質問を再送する前に出力要件と機密データの扱いを見直します。
同じOpenAIのモデル名でも、提供面は少なくとも三つに分かれます。
第一は一般のChatGPTチャットで、プランやロールアウト状況によりモデルピッカーと利用上限が決まります。
第二はAPIで、開発者がモデルIDを指定し、入力・出力トークンなどに応じて支払います。
第三はCodexやChatGPT Workで、Sol、Terra、Lunaなどの選択肢やクレジット消費が、通常チャットと別に管理される場合があります。
o3のChatGPT退役について、公式発表はAPIへの変更なしとしています。
ただし「現時点で継続」と「将来にわたり無期限」は同義ではありません。
API利用者はモデルカタログ、deprecations、ダッシュボードの告知を監視し、スナップショットまたはモデルID、移行期限、料金を定期的に確認する必要があります。
GPT-5.6系も、製品面ごとに見え方が異なります。
2026年9月4日時点のOpenAI APIモデル一覧では、Solは複雑な専門業務向け、Terraは知能とコストの均衡、Lunaはコスト重視の大量処理向けと位置づけられています。
通常のAPI価格は100万トークン当たり、Solが入力4ドル・出力20ドル、Terraが入力2ドル・出力12ドル、Lunaが入力0.20ドル・出力1.20ドルです。
長文脈や処理モード、地域処理などでは別条件があり、Solには期間限定の価格も示されています。
既存チャットを移すときは、履歴が見えるかだけで判断しません。
新しいモデルは過去ログを参照できても、回答の長さ、推論の深さ、ツールを呼ぶタイミング、曖昧な依頼への確認方法が変わります。
長い会話ほど、途中で積み上げた前提や訂正が新モデルに正しく反映されるかを確かめる必要があります。
まず、業務上の重要な会話を三つに分類します。
再現可能なテンプレート、個別案件の途中経過、保存すべき最終成果です。
テンプレートはシステム指示、入力例、出力形式、禁止事項を会話の外へ書き出します。
途中経過は、決定済み事項と未決事項を要約して新しいスレッドでも再現できる形にします。
最終成果は、社内の正規保存先へ移し、チャット履歴だけを記録保管にしないようにします。
Business、Enterprise、Eduでは、管理者がレガシーモデルを有効化できる移行期間が設けられる場合があります。
ただし公式案内は、利用可能なレガシー一覧がワークスペースや時期で変わり、退役期間が閉じれば削除されると説明しています。
管理者設定にo3が見えない場合、メンバー側の操作で復活させることはできません。
モデルの可否、クレジット、データ保持、コネクタ権限を管理画面で確認します。
APIを組み込んだシステムは、ChatGPTの画面変更だけで直ちに壊れません。
しかし、UIとAPIを同じモデルだと思い込んだ運用手順は修正が必要です。
障害対応手順には、ChatGPTの代替モデルとAPIの代替モデルを別々に記載し、どちらか一方の告知をもう一方へ自動適用しないルールを設けます。
移行先は、o3を何に使っていたかで変わります。
第一は、高難度の分析、複雑なコード設計、複数資料の統合など、誤りのコストが高い仕事です。
ここではGPT-5.6 Solや、利用可能であれば上位の現行推論モデルを候補にし、推論強度を上げたときの精度と所要時間を測ります。
料金が高くても、レビュー工数を減らせるなら総コストは下がる可能性があります。
第二は、メール下書き、要約、調査の整理、定型文書などの日常業務です。
Terraのように性能と費用の均衡を狙うモデルが候補になります。
o3と完全に同じ文体を期待するのではなく、完成基準、長さ、引用方法、確認事項をプロンプトへ明示します。
第三は、対話的な修正、分類、短い変換など速度優先の仕事です。
Lunaのような軽量モデルを使い、人がすぐ確認できる範囲へ限定します。
第四は、大量処理やバックグラウンド作業です。
単価だけでなく、キャッシュ、バッチ、長文脈、レート制限、失敗時の再試行費を含めます。
同じ組織で一つのモデルへ統一する必要はありません。
高リスクな最終判断だけSol、日常処理はTerra、大量の前処理はLunaと分ける設計も可能です。
反対に、モデルを増やし過ぎると評価、権限、プロンプト管理が複雑になります。業務のリスク階層に合わせ、2〜3種類から始めるのが現実的です。
再テストでは、o3で成功していた代表タスクを20〜50件選び、入力、参照資料、期待出力、禁止事項、合格基準を固定します。
比較するのは「なんとなく良い回答」ではなく、必須項目の充足率、事実誤り、形式エラー、ツール実行の成否、所要時間、1件当たり費用、人の修正時間です。
コードや自動処理では、構造化出力、関数呼び出し、再試行、タイムアウト、トークン上限を確認します。
長い会話では文脈の保持、過去の訂正、添付ファイルの参照を試します。調査用途なら、出典の実在、日付、引用の正確さを人が点検します。
モデルが高性能でも、既定の推論強度やツール設定が違えば結果は変わります。
切り替えは一斉ではなく、低リスク業務から段階的に進めます。
APIでは一定割合だけ新モデルへ流すカナリア運用が有効です。
ChatGPT中心のチームでは、代表者がテンプレートを検証し、合格した設定とサンプルを共有します。
失敗時に元へ戻せない場合に備え、手動手順や別モデルを準備します。
今後の退役に備え、台帳へ「モデル名」だけでなく、利用面、モデルID、推論設定、入力テンプレート、出力スキーマ、評価セット、合格値、担当者、最終検証日を残します。
毎月または四半期ごとに公式リリースノートとAPIの非推奨化情報を確認し、告知が出たら期限の半分までに比較試験を終える運用にすると、終了直前の混乱を減らせます。
o3の2026年8月26日の変更は、ChatGPTでの退役です。
公式発表では同日時点のAPIに変更はありません。
この区別ができれば、ChatGPTユーザーはモデルピッカーと既存会話を確認し、API利用者は別のライフサイクル情報を監視するという、必要な対応が見えてきます。
代替モデルは「o3の後継」という一語で決めず、仕事を高難度推論、日常業務、速度優先、大量処理へ分けて選びます。
Sol、Terra、Lunaは能力と費用の狙いが異なり、通常チャットでの提供とAPI・Workでの提供も同一ではありません。
重要業務は同じ評価セットで再テストし、モデル名に依存しない合格基準を残すことが、今回と次回の移行を安全にします。
.png){kind=logo}
