新モデルの発表を見て、日次バッチのモデル名だけを変更する。簡単な更新に見えますが、APIで提供されるモデルと、自分がログインしているCodexから使えるモデルは同じとは限りません。設定に文字列を書けることも、サーバーがそのモデルを受け付けることの証明にはなりません。

私は、影運転のモデルを変更する前に利用可否を調べた記録から、切替の入口に置く確認手順を整理しました。主題は性能比較ではなく「この日時、この認証経路、このクライアントで使えるか」です。題材には銘柄評価の処理を含みますが、本記事はソフトウェア・データ運用の説明であり、投資助言ではありません。

最近の取り組みで確認できたこと

2026年9月24日の作業記録では、ChatGPTサブスクリプション認証のCodexで、影運転に`gpt-6-luna`を使えるか調べています。当時のCLI版は0.153.3でした。App Serverの`model/list`が返した一覧には候補がなく、明示指定した一件の試行も「ChatGPTアカウントでの利用では、そのモデルは対応していない」という内容の400エラーで拒否されています。

ローカルにはモデルのメタデータが見つからない警告も出ました。ただし、警告だけで結論にせず、一覧の結果とサーバーの応答を別々に記録しています。当日の判断は、既存の`gpt-5.6-luna`による影運転を維持することでした。別候補でのリプレイ計測や、APIキー認証での試行は未実施です。

**これは9月24日の当該環境の診断であり、現在の全利用者に対する非対応宣言ではありません。** 9月25日に確認した公式Modelsページには、GPT-6 SolとLunaの案内があり、利用可否は段階提供、ログイン方法、クライアントに依存すると明記されています。過去の拒否記録を一般的な提供状況へ拡張せず、再確認の必要がある記録として残します。今回の記事制作では、本番設定の変更やモデルへの追加試投はしていません。

仕組みを分解する

確認は四段階に分けます。第一に、認証経路を固定します。公式Authentication資料は、ChatGPTによるサブスクリプション利用と、APIキーによる従量課金利用を区別しています。経路を変えると課金だけでなく、適用される管理・データ取扱いの条件も変わります。「使えないから別のキーで試す」は単なる再試行ではありません。

第二に、その環境に表示される候補を確認します。今回の記録ではApp Serverの一覧を使いました。対話CLIであれば、公式資料が案内する`/model`の選択画面も確認入口です。ただし、画面とApp Serverの出力が常に同一とは仮定せず、どちらで観測したかを残します。一覧が取得できなかった場合は「候補なし」ではなく「確認不能」です。

第三に、必要性と利用枠を確認してから、機密情報を含まない最小要求を一件だけ試します。記録するのは指定したモデル、認証方法、実行日時、成功または拒否の理由です。候補一覧への掲載と、実要求の成功は別の証拠として扱います。モデル名を変えながら大量試行する必要はありません。

第四に、結果を移行判断へつなぎます。非対応なら既存処理を維持し、再確認条件を残します。利用可能なら初めて品質、処理時間、利用枠への影響を調べます。利用資格の確認と、業務に適したモデルの選定を一度に済ませないことが要点です。

小さく再現する手順

まず、検証票に「確認日時・CLI版・認証経路・候補モデル・一覧結果・試行結果・判断」を用意します。アカウントの実名やメール、組織識別子は不要です。現在の認証方法を確認するコマンドは、公式資料にある次のものです。

“`text
codex login status
“`

出力は手元で確認し、公開用には認証方法だけを転記します。認証ファイルを開いて内容を貼り付ける方法は使いません。続いて対話CLIの`/model`で候補を確認します。閲覧と選択の確定を混同せず、検証のために本番の既定モデルを書き換えないようにします。

最小要求を試す場合も、本番リポジトリや顧客資料を入力にしません。機密ファイルや外部連携を持たない検証環境で、ファイル操作を必要としない短い応答だけを求めます。`codex exec –model`でモデルを明示できることは公式Models資料に記載されていますが、ここでは未確認のモデル名をコピーして実行する例は置きません。承認・サンドボックス設定を緩めることも不要です。

判定は次の疑似手順で再現できます。これはCodexのAPI仕様ではなく、運用上の分岐案です。

“`text
認証状態を確認できない → 診断を停止
候補一覧を取得できない → 確認不能として保留
候補が見当たらない → 提供条件を再確認
明示的な非対応応答 → 同じ条件での連打を停止
最小要求が成功 → 移行評価の候補に残す
品質・時間・利用枠が未評価 → 本番設定は維持
“`

検証票の「未実施」は空欄にせず、未実施と書きます。一覧不掲載だけで永久に使えないと断定せず、かといって確認のために毎朝自動試投する設計にもすぐ進みません。公式案内の更新やクライアント変更など、再確認する理由が生じたときに小さくやり直します。

確認指標

見る軸は三つです。**条件の一致**では、確認時の認証経路と実際のバッチの経路が同じかを確かめます。別のアプリや別アカウントで成功した結果は、そのまま本番への許可証にはなりません。

**証拠の分離**では、一覧取得の成否、候補の有無、ローカル警告、サーバー応答を別欄に残します。今回の根拠は一件の拒否試行とその前の一覧確認であり、モデルの品質劣位や恒久的な利用不能を示す測定ではありません。

**切替の準備状態**では、戻す設定が残っているか、評価用データと本番データを分けたか、追加負担が承認されているかを確認します。これらは推奨する確認項目であり、今回すべてを自動化したという実績ではありません。

失敗しやすい点と安全策

**発表を利用権限と取り違えること。** 公式のモデル紹介は提供条件を調べる入口です。実環境の結果と組み合わせて判断します。日付付きの拒否記録も将来の状態を保証しないため、公開予定日が後なら公開前にも公式情報を見直します。

**非対応を認証切れとして扱うこと。** 今回はモデルと認証経路の組合せに対する明示的な拒否でした。ログインし直せば直ると決めつけません。また、400という数字だけでは同じ原因と判断できないので、応答の意味を読みます。

**APIキーへの切替を無断の回避策にすること。** 別の課金・管理条件に移る操作です。予算とデータ送信条件の確認なしには行いません。今回もAPIキーなら成功すると実証したわけではありません。

**確認成功を即時採用へ飛ばすこと。** 短い要求に答えられても、長時間バッチの安定性や品質は分かりません。既存の影運転を壊さず、同じ入力を用いた小規模比較へ進む順序を守ります。

再現チェックリスト

• [ ] 確認日時とCLI版を記録した
• [ ] 認証経路を本番と照合した
• [ ] 一覧取得失敗と候補不掲載を区別した
• [ ] 警告とサーバー応答を別に記録した
• [ ] 最小試行に機密情報を渡していない
• [ ] 認証経路や課金条件を無断で変えていない
• [ ] 未実施の性能・負担評価を完了扱いしていない

次に改善するなら

次は、更新された公式案内を踏まえ、同じ認証経路で候補が利用可能になったかを再確認することです。使える場合に限り、小規模リプレイで品質・時間・利用枠への影響を比較します。この再試行と移行評価は未実施です。今回得た成果は新モデルへの移行ではなく、切り替えない理由と、次に判断を変える条件を明確にしたことです。

参考情報

• 作成根拠：2026年9月24日のローカル作業記録と同日の日次統合記録。非公開資料であり、当日の診断と維持判断だけを一般化しています。
• [OpenAI：Codex Authentication](https://developers.openai.com/codex/auth/) — 認証方法、課金・管理条件、認証状態の確認。
• [OpenAI：Codex Models](https://developers.openai.com/codex/models/) — 利用可否の条件、モデル選択、明示指定。9月25日に取得したHTML本文を参照しました。

公式資料の確認日：2026年9月25日。取得したMarkdown版とHTML版にはモデル案内の差があったため、固定的な対応一覧は転載していません。手元の最新の利用可否は、別途確認が必要です。