GPT-5.5が10月14日に提供終了|Codexのモデル設定・定期タスクを移行する手順【2026年9月】

AIニュース解説

OpenAIは2026年9月14日、GPT-5.5を2026年10月14日にChatGPT、ChatGPT Work、Codexで提供終了すると発表しました。個人向けだけでなく、Business、Enterprise、Eduを含むすべてのプランが対象です。一方で、OpenAI APIは今回の提供終了の対象外と明記されています。

ChatGPTの画面でモデルを選ぶだけなら、利用可能な別モデルを確認することが中心になります。しかし、Codexを仕事に組み込んでいるSEはそれだけでは足りません。CLIの起動コマンド、設定ファイル、ワークスペースのデフォルト、カスタムエージェント、スケジュール済みタスクなどに古いモデル名が残っている可能性があるためです。

先に要点を整理すると、ChatGPTでサインインしてCodexを利用している場合、公式に案内されている切り替え先はGPT-5.6 Sol(gpt-5.6-sol)です。移行はモデル名の検索、設定変更、代表作業の再確認という順番で進めると、変更漏れを減らせます。本記事は2026年9月18日に確認できたOpenAI公式情報をもとに、発表内容と実務向けの確認手順を分けて整理したものです。筆者自身の動作検証結果を示すものではありません。

  1. GPT-5.5の提供終了はいつ、何が対象になるのか
  2. まず認証方法と代替モデルの利用権限を確認する
  3. 見落としやすいGPT-5.5の指定箇所を洗い出す
    1. 設定を探す場所を運用単位で分ける
    2. 検索するときはモデル名の表記違いに注意
  4. Codex CLIでGPT-5.6 Solへ切り替える具体例
    1. config.tomlに古いモデルが固定されていないか確認
  5. Business・Enterprise環境で管理者が確認したいこと
  6. 移行後は「起動できた」だけでなく仕事の結果を確かめる
    1. 小さな代表タスクを三種類用意する
    2. 自動実行は別に確認する
  7. ありがちな失敗と、その切り分け方
    1. 失敗例1:画面だけ切り替えて保存済みのタスクを忘れる
    2. 失敗例2:ローカル設定だけ変更して管理対象の値を見落とす
    3. 失敗例3:APIも10月14日に停止すると誤解する
    4. 失敗例4:モデル名だけ置き換え、テスト結果を記録しない
  8. フリーランスSEなら顧客ごとに移行範囲を分ける
  9. よくある疑問:移行先・料金・既存タスクはどうなる?
    1. Q. GPT-5.5をAPIで使っているシステムも10月14日に止まりますか?
    2. Q. Codexではどのモデル名を指定すればよいですか?
    3. Q. 今の設定をそのままにしても自動で移行されますか?
    4. Q. GPT-5.6 Solに替えると料金や利用上限は必ず同じですか?
    5. Q. 一度切り替えれば、その後のレビューは不要ですか?
  10. 10月14日までに進めたい実務チェックリスト
  11. 参考情報

GPT-5.5の提供終了はいつ、何が対象になるのか

公式リリースノートに記載された発表日は2026年9月14日、提供終了日は同年10月14日です。「GPT-5.5という名前があらゆる場所から消える」という発表ではなく、製品ごとの提供範囲を区別して読む必要があります。

利用先 2026年10月14日の扱い 利用者が確認すること
ChatGPT GPT-5.5の提供終了対象 保存した作業手順やモデル選択を確認
ChatGPT Work GPT-5.5の提供終了対象 作業に使うモデル、ワークスペース設定を確認
Codex GPT-5.5の提供終了対象 ログイン方法、モデルの固定設定、タスクを確認
OpenAI API 今回の終了対象外 別途API向けの提供情報を継続して確認

ここで大切なのは、APIへの影響がないことを「永続的な提供保証」と読み替えないことです。今回の告知だけを理由にAPIシステムを10月14日までに改修する必要があるとはいえませんが、今後の変更案内は別途確認する必要があります。また、CodexでもChatGPTアカウントでサインインする運用と、自分のAPIキーを利用する運用は区別して整理しましょう。

以前のOpenAI o3の終了については、別の記事「OpenAI o3がChatGPTで終了する際の移行ポイント」で扱っています。今回はGPT-5.5についての新しい公式告知であり、特にCodex内の設定の置き換えが中心です。

まず認証方法と代替モデルの利用権限を確認する

作業の出発点は、自分がどのサービスにどの方法で接続しているかを確かめることです。普段のチャット、Codex CLI、IDE拡張機能、クラウド上の作業が、必ずしも同じモデル選択や認証条件で動くとは限りません。とくに複数の顧客環境を扱うフリーランスSEは、個人アカウントと顧客ワークスペースを混同しないようにしてください。

OpenAIのモデル資料は、ChatGPTでサインインしてCodexを使っている場合、gpt-5.5をgpt-5.6-solへ切り替えるよう案内しています。ただし、管理者向け文書は「ワークスペースのデフォルトモデルを変更しても、各メンバーにモデルへのアクセス権が付与されるわけではない」と明示しています。設定名を書き換える前に、対象ユーザーが利用しているクライアントで代替モデルを選択できるか確認しましょう。

たとえば自分のCLIではSolが利用できても、顧客の管理対象環境で同じモデルを選べるとは限りません。モデル名の指定が正しくても、アクセス権や管理ポリシーが異なれば、作業開始時に想定どおり動かない可能性があります。「設定値は正しい」と「その環境で利用できる」は別の確認項目です。

Sol以外にもGPT-5.6ファミリーには用途が異なるモデルがあります。モデルの役割そのものを整理したい場合は、既存の「GPT-5.6 Sol・Terra・Lunaの違いと使い分け」も参照できます。ただし、今回のGPT-5.5終了に対するCodexの公式な置き換え案内はSolです。予算やタスク特性を理由に別モデルを選ぶ場合は、組織の利用権限と検証結果を踏まえて判断する必要があります。

見落としやすいGPT-5.5の指定箇所を洗い出す

「今日のCodex画面で別モデルを選べたから移行完了」と判断するのは早計です。公式の移行案内では、ワークスペースのデフォルト、保存済みのモデル設定、管理対象の構成、カスタムエージェント、スケジュール済みタスク、スクリプトを更新対象として挙げています。

設定を探す場所を運用単位で分ける

  • 手元の実行環境:Codex CLI、デスクトップアプリ、IDE拡張機能のモデル選択と保存済み設定。
  • 実行コマンド:codex -m ...や、非対話実行時のcodex exec --model ...など、モデルを明示した呼び出し。
  • 再利用する作業:カスタムエージェント、作業用テンプレート、スケジュール済みタスク。
  • チーム共通設定:ワークスペースのデフォルト、管理対象の設定、端末管理で配布する構成。
  • ドキュメント:新人向け導入手順、顧客への説明資料、障害時の復旧手順に書かれたモデル名。

最後のドキュメント類はOpenAIが列挙する製品設定そのものではありませんが、現場で作業手順を再現する際には確認しておきたい項目です。古いモデル名を含むコマンドを手順書からコピーする運用では、システム設定だけ変更しても再発を防げません。

検索するときはモデル名の表記違いに注意

エディターやリポジトリの検索機能でgpt-5.5を探す方法は、確認作業の一例です。ただし、ワークスペースの設定画面やサーバー側で保持されるスケジュール済みタスクまで、ローカルファイルの検索だけで見つかるとは限りません。文字列検索は入口と考え、画面上の登録内容や管理者設定も個別に確認します。

モデル名が直接書かれていない仕組みもあります。環境変数から参照している場合は変数の値、共通の設定ファイルを読んでいる場合は実際に採用されている設定値を確認します。表記を一括置換する前に、どのアカウントとワークスペースで使われる設定なのかを記録しておくと、変更範囲を誤りにくくなります。

Codex CLIでGPT-5.6 Solへ切り替える具体例

OpenAIのCodexモデル資料では、対話型のCLIセッション中に/modelを使ってモデルを切り替える方法と、起動時に--modelまたは省略形-mを使う方法が説明されています。GPT-5.6 Solのモデル識別子はgpt-5.6-solです。

起動時に明示的に指定するなら、公式資料に記載されたモデル名を使って、次のようなコマンドにします。

codex -m gpt-5.6-sol

これは公式の起動オプションとモデル識別子に基づく記述例です。実際に利用できるかどうかは、認証方法、契約、ワークスペースの設定、クライアントの提供状況で異なります。実機での動作を本記事が保証するものではありません。

config.tomlに古いモデルが固定されていないか確認

OpenAIの資料によると、ChatGPTデスクトップアプリ、Codex CLI、IDE拡張機能は共通のconfig.tomlを使用します。モデルを固定している場合は、modelという項目を確認します。Solを指定する構成例は次の形です。

model = "gpt-5.6-sol"

設定ファイルの編集前に現在の内容を控え、他の項目を不用意に消さず、モデル名に関係する行を中心に変更してください。モデルを明示的に指定していない場合には推奨モデルが利用されると説明されていますが、どのモデルが実際に選択されるかは画面や実行時の表示で確認する方が確実です。「固定を外せば必ずSolになる」とは決めつけないようにします。

非対話で起動するバッチや定期実行がある場合は、CLIの普段のセッションだけでなく、実行コマンドのモデル指定も点検します。起動オプションの書き方とモデル識別子は公式資料に示されていますが、既存のスクリプト内での設定位置は実装により異なるため、変更後のテスト実行が必要です。

Business・Enterprise環境で管理者が確認したいこと

個人の端末でモデル名を書き換えても、組織全体の移行が済むわけではありません。OpenAIは管理者向けに、ChatGPT、ChatGPT Work、Codexのワークスペースのデフォルトを確認し、メンバーが利用可能な代替モデルを選ぶよう案内しています。個別ユーザーによる変更と、管理者による共通設定の変更は役割を分けましょう。

管理対象の設定資料では、managed_config.tomlなどの管理対象デフォルトは、ローカルのconfig.tomlより優先されることが説明されています。さらに、macOSのMDMプロファイルでモデルを固定している場合にも更新が必要とされています。手元で切り替えたつもりでも、クライアントの再起動後に管理設定が適用され、想定外の値に戻る可能性を考慮する必要があります。

管理者の確認対象は「設定値の置き換え」と「対象メンバーのアクセス権」と「実際の起動時の状態」の三つです。たとえば、ワークスペースのデフォルトをSolに変えたとしても、モデルへのアクセス権が自動付与されるわけではありません。部署や座席種別によって条件が違う環境では、代表的なユーザーでの確認も必要です。

本番に近いプロジェクトでは、設定変更の担当者、切り替える日時、確認する作業、問題があった場合の連絡先を短く記録しておくと引き継ぎしやすくなります。モデルの提供終了後に旧モデルへ戻せることを前提とした復旧計画ではなく、代替モデル利用時の作業手順や人手の確認工程をあらかじめ整えておくのが現実的です。

移行後は「起動できた」だけでなく仕事の結果を確かめる

モデルを変更するときは、設定ファイルの更新と業務で期待する結果の確認を分けて考えます。変更前に典型的な作業を数件選び、入力条件と合格基準を記録しておくと、切り替え後の評価が曖昧になりません。ここからは公式の移行必須項目ではなく、SE実務における検証手順の提案です。

小さな代表タスクを三種類用意する

一つ目は小さなバグ修正です。再現条件、修正するべき範囲、既存テストの結果を確認します。二つ目はコードレビューです。指摘の根拠がコード上に存在するか、重大度が過大でないか、人が追える説明になっているかを見ます。三つ目は定型的な調査や集計です。期待する出力形式、抜け漏れ、作業時間を確かめます。

比較するときは、モデルの回答文だけでなく、変更したファイル、テスト結果、差分の大きさ、追加指示の回数を残します。出力が一見正しそうでも、無関係なファイルの編集や既存仕様の変更が混入していれば、そのまま採用すべきではありません。

自動実行は別に確認する

スケジュール済みタスクや非対話スクリプトがある場合は、手動のチャットで成功したことをもって完了としない方が安全です。実際にそのタスクで使うモデル指定、対象プロジェクト、権限、出力先を確認し、影響の小さい条件で実行結果を見ます。通知先や成果物の保存先がある場合も、想定どおりに扱われたか人が確認します。

ただし、テストのために顧客環境へ勝手に変更を加えたり、機密データを個人環境へコピーしたりしないでください。検証用のデータやリポジトリは、契約・社内ルール・アクセス権の範囲内で用意します。テストを行っていない項目は「未確認」として記録しておく方が、後のトラブル対応で役立ちます。

ありがちな失敗と、その切り分け方

失敗例1:画面だけ切り替えて保存済みのタスクを忘れる

普段の画面でSolを選んでも、別に保存したタスクやカスタムエージェントにgpt-5.5が残っていれば設定の更新漏れになります。公式が明示している対象を一つずつチェックし、使用頻度の低いタスクも一覧から確認しましょう。

失敗例2:ローカル設定だけ変更して管理対象の値を見落とす

組織で管理する端末では、ユーザー設定より管理対象設定が優先される場合があります。変更した直後だけではなく、必要に応じてクライアントを再起動した後のモデル表示も確認します。利用権限がない場合に、設定ファイルを繰り返し書き換えるのではなく管理者へ確認するのが適切です。

失敗例3:APIも10月14日に停止すると誤解する

今回の公式告知ではOpenAI APIは対象外です。APIキー認証で利用する処理とChatGPTサインインのCodexを混同すると、不要な改修を急いだり、逆に必要なCodex設定の更新を見落としたりします。資産ごとに「接続先」「認証方式」「明示的なモデル名」を書き出してから対応範囲を判断します。

失敗例4:モデル名だけ置き換え、テスト結果を記録しない

代替モデルで作業が開始できても、成果物の品質や動作が以前と同一である保証にはなりません。特にコード変更を伴う仕事では、人によるレビュー、既存のテスト、差分確認を省かないでください。判断が難しい場合は、影響範囲の小さな作業から移行し、確認結果を残します。

移行のメリットは、終了日を迎える前に運用上の不確実性を減らせることです。一方、設定の棚卸しや再検証には作業時間がかかります。大規模な置き換えを一度に行うより、影響が大きいタスクから順に確認する方が、問題箇所の切り分けがしやすくなります。

フリーランスSEなら顧客ごとに移行範囲を分ける

複数案件でCodexを使うフリーランスSEは、全案件に同じ移行手順を当てはめず、環境単位で整理したいところです。個人のChatGPT契約、顧客のBusinessワークスペース、APIキーを使った社内アプリは、それぞれ確認すべき対象が違います。

顧客へ説明するときは「OpenAIの発表では10月14日にChatGPT・ChatGPT Work・CodexのGPT-5.5が終了し、APIは対象外」「こちらの案件ではどの認証方法と設定を使っているか」「変更箇所とテスト範囲は何か」を分けて伝えると、事実と実務上の提案を混同しにくくなります。

運用の引き継ぎ先がある場合は、作業担当者だけでなく、定期タスクの所有者や管理者も確認対象に入れます。顧客の許可なく本番設定を変更せず、必要な変更管理やレビューの手順に従ってください。モデル変更後の応答が異なることを理由に、成果物の正しさをAI任せで判断するのも避けたいところです。

現時点でGPT-5.5を使っておらず、すべての対象環境で別モデルが選択されているなら、今回の告知を理由に不要な変更を増やす必要はありません。ただし、将来の引き継ぎ資料や使っていない定期タスクに古い指定が残っていないかは、短時間でも点検する価値があります。

よくある疑問:移行先・料金・既存タスクはどうなる?

Q. GPT-5.5をAPIで使っているシステムも10月14日に止まりますか?

今回の発表ではOpenAI APIは提供終了の対象外です。APIの将来の提供期限や料金まで保証する説明ではないため、APIについては別途公式のモデル情報と変更案内を確認してください。

Q. Codexではどのモデル名を指定すればよいですか?

ChatGPTでサインインしてCodexを利用する場合、OpenAIが今回案内している切り替え先はGPT-5.6 Sol、識別子はgpt-5.6-solです。利用可否は契約・アカウント・クライアント・管理設定によって異なるため、実際の環境で確認します。

Q. 今の設定をそのままにしても自動で移行されますか?

公式は、保存済みのモデル設定やスケジュール済みタスク、スクリプトなどのgpt-5.5を更新するよう求めています。どの環境でどのような自動置換が起きるかを一律に保証する説明は確認できないため、自動移行を前提に放置せず設定を点検しましょう。

Q. GPT-5.6 Solに替えると料金や利用上限は必ず同じですか?

今回参照した提供終了の告知は、すべての利用環境に対する同一料金・同一上限を保証していません。課金方式、クレジット、プランやワークスペースの条件は個別に確認してください。本記事では未確認の料金数字を掲載していません。

Q. 一度切り替えれば、その後のレビューは不要ですか?

不要にはなりません。モデル変更と成果物の品質保証は別の話です。実務ではテスト、差分確認、人による承認を作業の性質に応じて続けてください。とくに本番環境の変更や顧客への納品物は、従来の責任分担を維持する必要があります。

10月14日までに進めたい実務チェックリスト

まずは利用中のChatGPT・Codex環境を一覧にし、GPT-5.5を使っているかと認証方式を確認します。続いて保存済み設定、コマンド、定期タスク、カスタムエージェント、ワークスペースや管理対象の構成を見直します。ChatGPTサインインのCodexで指定が残っている場合は、利用権限を確認してから公式の案内に沿ってSolへ切り替えます。

その後、手元の小さな代表作業を使って起動、出力、テスト、権限、作業時間を確認し、問題がなければ手順書を更新します。担当者・変更日・未確認事項を簡単に記録しておくと、終了日が近づいたときにも進捗を把握しやすくなります。対象が見当たらない場合も、何を確認したかを一言残しておくと再調査の手間を抑えられます。

今回の変更は、モデルそのものの性能評価よりも、いつまでに、どの環境の、どの固定設定を変更するかが実務の焦点です。APIまで一律に終了するという誤解を避け、Codexの保存済み設定と自動タスクを漏れなく点検してください。

参考情報

情報確認日:2026年9月18日。提供状況、設定画面、料金、利用条件は変更される可能性があります。操作前には利用中の環境と公式資料を確認してください。

コメント