GPT-5.5 が Codex から退役済み — ChatGPT サインインのみ対象、API キー認証は影響なし

要約

Codex の changelog に 2026-10-14 付けのエントリが出ました。2026年10月14日正午 PDT（19:00 UTC）に、ChatGPT でサインインしているユーザーの Codex から GPT-5.5 が退役しました。

すでに発効済みです。 退役の予告は 2026-09-14 に出ていました。本日のエントリは発効の告知です。予告から発効まで30日でした。

影響範囲が認証方式で分かれる点が、この告知のいちばん重要な部分です。

• 対象: ChatGPT アカウントでサインインした Codex セッション
• 対象外: OpenAI API、および API キーで認証した Codex セッション

同じ Codex でも、どうやって入ったかで挙動が変わります。 社内に両方の使い方が混在していると、「自分の環境では問題なかったから大丈夫」が成り立ちません。 先にこの線引きを確認すると、作業範囲がはっきりします。

推奨移行先は gpt-6.1-sol（GPT-6.1 Sol）です。 ただし「プランとクライアントで利用可能な場合」という条件が付いています。公式エントリは、プラン別の移行先詳細と、ワークスペースのモデル利用可否に関する管理者向けガイダンスへのリンクを持っています。プランによって移行先が違う可能性があるため、ここは自社のプランで確認が必要です。

棚卸しの対象として挙げられている6か所が、実務上の要点です。 公式エントリは gpt-5.5 を選択している箇所として、次を列挙しています。

1. ワークスペースの既定値
2. 保存済みモデル設定
3. managed configuration
4. カスタムエージェント
5. スケジュール済みタスク
6. スクリプト

前半3つは人が設定画面で触る場所ですが、後半3つは違います。 カスタムエージェント、スケジュール済みタスク、スクリプトは、無人で走る構成です。モデルが使えなくなったとき、画面の前に誰もいません。

ここが気づきにくい理由です。 対話的に使っていれば、モデルが選べなくなったことはすぐ分かります。ところが毎晩動くスケジュール済みタスクに gpt-5.5 が書かれていた場合、失敗が翌朝まで、あるいは誰かが成果物を探すまで見つかりません。 スクリプトなら、エラーログを誰も見ていなければそのまま放置されます。

発効がすでに過ぎている点が、対応の順序を変えます。 期限前の告知なら「期限までに棚卸しする」で済みますが、今回は 19:00 UTC に発効済みです。 つまりすでに失敗している構成がある可能性があります。 確認すべきは「これから何を直すか」ではなく、**「昨夜以降、動かなかったものは無いか」**です。

何が変わったか

• 2026-10-14 正午 PDT（19:00 UTC）に、GPT-5.5 が Codex から退役（発効済み）
• 対象は ChatGPT アカウントでサインインした Codex セッション
• OpenAI API と API キー認証の Codex セッションは影響なし
• 推奨移行先は gpt-6.1-sol（プランとクライアントで利用可能な場合）
• プラン別の移行先詳細と、管理者向けのワークスペースモデル利用可否ガイダンスが公式からリンクされている
• 棚卸し対象: ワークスペースの既定値 / 保存済みモデル設定 / managed configuration / カスタムエージェント / スケジュール済みタスク / スクリプト
• 予告は 2026-09-14。予告から発効まで30日

業務インパクト（一般企業向け）

最初にやることは、認証方式の確認です。 社内の Codex 利用が ChatGPT サインインなのか API キーなのかで、対応が必要かどうかが決まります。両方が混在しているのが普通なので、「どちらか」ではなく「どこがどちら」を把握する必要があります。API キー認証だけで運用している組織は、この件の対応は不要です。

次にやることは、過去の失敗の確認です。 発効は 2026-10-14 の 19:00 UTC（日本時間 10月15日 午前4時）です。それ以降に走ったスケジュール済みタスクが、すでに失敗している可能性があります。 「これから直す」ではなく「昨夜動くはずだったものが動いたか」を確認してください。無人で走る構成は、失敗しても誰も通知を受けていないことが多いです。

managed configuration が対象に含まれる点は、管理者の作業を意味します。 組織側で配布している設定に gpt-5.5 が入っていると、利用者が自分で直せません。 管理者が配布設定を更新するまで、該当するユーザー全員が影響を受けます。利用者からの問い合わせを待つのではなく、配布設定を先に確認する順序が正しいです。

移行先の利用可否は、プランとクライアントに依存します。 gpt-6.1-sol が全プランで同じように使えるとは書かれていません。公式がプラン別の詳細へリンクしているのは、差があることの裏返しです。管理者はワークスペースのモデル利用可否を確認し、利用者が選べるモデルに移行先が含まれているかを見る必要があります。含まれていなければ、設定を直しても動きません。

30日という予告期間は、この種の変更としては短めです。 9月14日に予告、10月14日に発効。組織の変更管理プロセスを通すには、1か月は余裕のある長さではありません。 今回を機に、Codex の changelog を定期的に見る担当を決めておくと、次回の予告を取りこぼさずに済みます。無人構成を持っている組織では特に効きます。

副業・個人活用視点

「認証方式で影響が分かれる」という構造は、調査スキルとして売れます。 同じツールでも入り方で挙動が変わる仕様は、ドキュメントを読まないと分かりません。クライアントの環境でどちらが使われているかを特定し、影響範囲を切り出す作業は、短時間で終わるのに価値が分かりやすい仕事です。「対応不要です」と言えることにも価値があります。

無人構成の棚卸しは、継続案件になりやすい領域です。 スケジュール済みタスク・カスタムエージェント・スクリプトに埋まったモデル指定は、作った人が異動していると誰も把握していません。 一度リストを作ると、次のモデル退役でもそのまま使えます。「モデル指定の台帳を作る」という提案は、1回で終わらない仕事です。

失敗の検知の話へ広げられます。 今回いちばん怖いのは、モデルが使えなくなったことではなく、無人で走る構成の失敗に誰も気づかないことです。「実行されなかったことを検知する仕組みがあるか」という問いは、モデル退役に限らず通用します。監視の提案へつなげる入口として使えます。

予告から発効までの期間を記録しておくと、助言の根拠になります。 今回は30日でした。この数字を積み上げると、**「このベンダーはどれくらいの猶予をくれるか」**が見えてきます。顧客が「いつまでに準備すればいいか」と聞いてきたときに、実績に基づいて答えられるのは強いです。

個人で Codex を使っている場合も、スケジュール済みタスクの確認は必要です。 自分用の自動化に gpt-5.5 を書いていれば、日本時間 10月15日午前4時以降は動いていません。成果物を見に行くまで気づかない種類の故障です。動かなくなった時刻が分かっているうちに確認すると、原因の切り分けに時間を取られません。