GPT-5.1廃止は2027年4月1日｜3本の移行先と注意点

GPT-5.1 の廃止日は 2027年4月1日です。同じ日に gpt-5.3-codex と gpt-5.4-nano も API から取り除かれます。OpenAI は 2026年10月1日付の Deprecations ページでこの3本をまとめて告知し、そこに「six months' notice（6か月の予告）」と明記しました。告知から停止までちょうど6か月あり、2026年10月2日時点で残り181日です。

公式が指定した推奨移行先は、gpt-5.1 と gpt-5.3-codex が GPT-6 Sol、gpt-5.4-nano が GPT-6 Luna。いますぐ止まるものは何もありませんが、今日やるべきことは「モデルIDを設定値として外に出す」「reasoning.effort の指定を棚卸しする」の2つです。理由は後述しますが、モデルIDを1文字差し替えるだけでは動かないケースが実在します。

2027年4月1日に止まる3本と、公式の推奨移行先

まず確定している事実だけを表にします。いずれも OpenAI の Deprecations ページ（2026年10月1日付）に記載されている内容です。推奨移行先は「こちらの推測」ではなく、OpenAI 自身が Recommended replacement として書いているモデルです。

停止の対象はAPI からの提供です。コーディング用途で gpt-5.3-codex を回している現場は、推奨どおりなら gpt-6-sol が受け皿になります。小さく速いモデルとして gpt-5.4-nano を分類・抽出・整形に使っている場合は gpt-6-luna です。

なお gpt-5.4-cyber は 2026年9月11日付の別の告知で扱われているモデルで、今回の3本とは別件です。社内の棚卸しリストを作るときに混ぜると期日を1つ取り違えるので、告知日ごとに分けて管理してください。モデル廃止そのものへの向き合い方はAIモデルの提供終了に企業がどう備えるかを6手順でまとめた記事に通しでまとめています。

「6か月の予告」は何を意味するか

今回の告知で実務的にいちばん大きいのは、OpenAI が予告期間を自分から宣言したことです。原文には "will be removed from the API on April 1, 2027, with six months' notice" とあり、告知（2026年10月1日）から停止（2027年4月1日）までがちょうど6か月に設計されています。

つまり、慌てて今週コードを書き換える必要はありません。一方で「気づいたら来週止まる」という進み方でもないので、6か月を4つに割って計画を立てられるという読み方ができます。実務では次の配分が無理のないところです。

• 最初の2週間: 自社のどのコードが gpt-5.1 / gpt-5.3-codex / gpt-5.4-nano を名指ししているかを洗い出す（ハードコード・環境変数・設定ファイル・ノーコードツールの設定画面まで）
• 1〜2か月目: モデルIDを設定値として外出しし、1箇所の変更で切り替わる形にする
• 3〜4か月目: 移行先候補で実際に出力を比べ、プロンプトの手直しを済ませる
• 5〜6か月目: 本番を切り替え、旧IDの呼び出しがゼロになったことをログで確認する

この手順でいちばん時間を食うのは3〜4か月目の出力比較です。モデルを変えると同じプロンプトでも返し方の癖が変わるため、出力をそのままパースしている箇所（JSON を前提にした処理、文字数を前提にした表示）は必ず実データで見ておく必要があります。

訂正: GPT-6 Sol が料金ページの既定表示から消えたことは、廃止の前兆ではありませんでした

ここは当サイトの記述の訂正です。GPT-6 Sol から 6.1 Sol への移行を料金で試算した2026年9月30日の記事で、私たちは「GPT-6 Sol は公式の料金ページから行が消え、推奨3枠からも外れた＝このあと廃止日が告知される流れ」と書きました。この読みは誤りでした。

2026年10月2日に同じページを取り直した結果は次のとおりです。

• developers.openai.com/api/docs/pricing の Standard / Batch / Flex / Fast の4タブすべてに gpt-6-sol の行が存在し、単価も従来どおり（入力 $2 / キャッシュ読み $0.20 / キャッシュ書き $2.50 / 出力 $10、100万トークンあたり）。既定の表示が上位3行（gpt-6-astra / gpt-6.1-sol / gpt-6-luna）だけなので、折りたたまれて見えていなかっただけでした。
• developers.openai.com/api/docs/models の全モデル一覧にも "GPT-6 Sol: Built to power complex coding and agentic workflows." として掲載されています（「まず使う3本」の推奨枠が Astra / 6.1 Sol / Luna であることは事実です）。
• そして 2026年10月1日の廃止告知で、OpenAI 自身が gpt-5.1 と gpt-5.3-codex の推奨移行先に gpt-6-sol を指定しました。
• gpt-6-sol 自身には、Deprecations ページに停止日の行がありません。

したがって結論はこうなります。公式が廃止モデルの移行先として名指ししているモデルは、当面の受け皿として安全です。逆に、ドキュメントの「おすすめ枠」や料金表の既定表示から外れたことを廃止の前兆と読むのは、根拠として弱いやり方でした。廃止の有無を判断してよい唯一の場所は Deprecations ページで、そこに行が無いことを確認するのが正しい手順です。

移行先3モデルの単価と、推奨先が最適先とは限らない理由

移行先として名前が挙がる3本の単価を並べます（いずれも100万トークンあたり、2026年10月2日に公式モデルページで確認）。

ここに実務上の勘所があります。gpt-6-sol と gpt-6.1-sol は入力と出力の単価が同額で、違うのはキャッシュ読みだけ（$0.20 対 $0.10 で半額）です。長いシステムプロンプトや同じ資料を繰り返し読ませる構成なら、gpt-6.1-sol のほうが請求額は下がります。

ただし、そのまま差し替えられるとは限りません。gpt-6-sol は reasoning.effort に none を指定できますが、gpt-6.1-sol は none と minimal に対応していません。effort: none を前提にした実装のモデルIDだけを 6.1 に書き換えると、リクエストが 400 で落ちます。

つまり「公式の推奨移行先」と「自社にとって最適な移行先」は一致しないことがあるということです。判断の順番はこうなります。

1. reasoning.effort に none / minimal を使っているか確認する → 使っているなら素直に gpt-6-sol（＝公式の推奨先）
2. 使っていない、または low 以上に寄せられる → キャッシュ比率が高いほど gpt-6.1-sol が有利
3. 分類・抽出・整形など軽い処理 → gpt-6-luna で桁ひとつ安くなる（gpt-5.4-nano の公式推奨先もこちら）

どれだけ下がるかは、キャッシュ読みが全トークンの何割を占めるかで変わります。3ケースに分けた金額の試算は6.1 Sol への移行で請求額がどう動くかを計算した記事に置いているので、自社のトークン構成に近いケースを当ててみてください。

こうした棚卸しは、やること自体は単純でも「どのコードがどのモデルを呼んでいるか分からない」ところで止まりがちです。私たちはAIの導入と運用のご相談も受けており、こういう地味な棚卸しの伴走も中身に含めています。記事の途中で恐縮ですが、社内で手が足りないときの選択肢として見ていただけたら嬉しいです。

移行の手順とつまずきどころ

モデルIDをコードの外に出す

いちばん効くのはこれです。"gpt-5.1" という文字列がコードの各所に散っていると、次の廃止告知のたびに同じ作業を繰り返すことになります。環境変数か設定ファイルに1つだけ置き、アプリはそれを読むだけにしておけば、以降の切り替えは1行の変更で済みます。

見落としやすいのは、コード以外にモデルIDが書かれている場所です。ノーコードツールの設定画面、社内ドキュメントのサンプル、バッチ処理のシェルスクリプト、テストのモックデータまで洗ってください。

reasoning.effort の互換を先に確認する

前述のとおり、gpt-6.1-sol は reasoning.effort の none と minimal に対応していません。none を使う実装は、応答速度を優先して推論を抑える意図で書かれていることが多いので、6.1 へ寄せるなら「low に上げて速度と費用がどう変わるか」を実測してから決めるのが安全です。モデルIDだけを置換して本番に出すのが、今回の移行でいちばん起きやすい事故です。

IDの表記ゆれ（gpt-6-1-sol は存在しない）

gpt-6-1-sol というIDは存在しません。正しくはgpt-6.1-solで、バージョンの区切りはハイフンではなくドットです。他のモデル名がハイフン区切りなので、手で打つと取り違えます。設定値として1箇所に置いておけば、この取り違えも1回で終わります。

ツール呼び出しは Responses API へ寄せる

関数呼び出しやツール連携を含む実装は、移行のついでに Responses API 側へ寄せておくほうが、以降のモデル差し替えが楽になります。モデルを変えるたびにリクエストの組み立てを書き直す状態から抜けるのが目的で、移行作業のコストを次回に持ち越さないための投資です。

2027年までの期限カレンダー

OpenAI の Deprecations ページに掲載されている停止日を、近い順に並べます。残り日数は2026年10月2日時点の数値です。

いちばん近いのは今回の3本ではなく、2026年12月11日の o3 系です。推論モデルを使っている現場はこちらが先に来るので、o3 の終了日と移行先を整理した記事で対象スナップショットを確認してください。

同じ2026年10月1日に、TTS 4本の停止も告知されている

同日付でもう1本、音声合成（TTS）モデル4本を2027年1月6日に停止する告知が出ており、移行先は gpt-realtime-2.1-mini が指定されています。期日が今回の3本より約3か月早いため、読み上げ機能を持っているサービスはこちらを先に処理する必要があります。詳細はtts-1 の停止日と gpt-realtime-2.1-mini への移行をまとめた記事に分けました。

まとめ

確定している事実は3つです。停止は2027年4月1日、対象は gpt-5.1 / gpt-5.3-codex / gpt-5.4-nano の3本、公式の推奨移行先は Sol と Luna。予告は6か月あるので、今週やるのは棚卸しだけで十分です。

そのうえで判断が要るのは、gpt-6-sol（公式の推奨先）と gpt-6.1-sol（キャッシュ読みが半額だが effort: none 非対応）のどちらに寄せるかの1点です。ここを決めてからコードに触れば、移行は1回で終わります。

自社のどこが影響を受けるのか切り分けきれない、あるいは移行のついでに運用そのものを整えたい、ということであれば、状況をお聞かせいただければ一緒に棚卸しできます。売り込みのためではなく、期日前に慌てる会社を減らしたいという気持ちでご案内しています。