AIに仕事を任せるとき、モデル名は画面で選べれば十分だと思いがちです。ところが、2026年9月4日に公開されたCodex 0.153.4とOpenCode 1.18.29は、ほぼ同じ不具合を別々に直しました。新しいモデルが選択画面に出ない。設定しなければ使われるはずのモデルが、一覧からは見えない。原因はAIの性能ではなく、モデル一覧を管理する側の食い違いでした。
これは小さな表示修正に見えます。会社でAIを使うなら、むしろこちらの方が厄介です。利用者は「契約しているのに使えない」「昨日と結果が違う」と判断し、管理者は権限や請求を調べ始める。実際には、接続先が持つモデル名と、クライアント側の判定ルールがずれているだけかもしれません。
CodexとOpenCodeで同じ日に起きたこと
OpenAIの公式リリースによると、Codex 0.153.4はAstraを同梱モデルの選択画面に表示し、モデルを明示していない場合の既定値として扱う修正を入れました。関連するPull Request #42874には、0.153系のカタログで gpt-6-astra の表示設定が hide になっていたため、カタログ経由の選択肢から消えていたと書かれています。修正は表示設定を list に変え、既存の優先順位に従って既定モデルに戻すものです。
同じリリースのもう一つの修正は、利用できるツールの扱いです。Pull Request #42878では、非同期で質問する機能がすべてのセッションにあるように読める指示を改め、「利用できる場合」という条件を加えました。モデルへの指示と、実行時に本当に渡される道具が一致しなければ、AIは存在しない機能を前提に動こうとします。そこで製品側が、能力を決め打ちしない文章に直したわけです。
OpenCode 1.18.29も、Codex OAuthで取得したモデルを絞り込む処理を修正しました。公式リリースには、gpt-6のような整数形式のGPTバージョンを認識できるようにし、OpenAIのサブスクリプション利用者に gpt-6-astra が表示されない問題を直したとあります。
二つのプロジェクトが同じ日に似た修正を出した事実から分かるのは、新モデルの提供だけでは利用可能にならないということです。プロバイダー、認証方式、モデルカタログ、表示フィルター、既定値、実行時のツール一覧。このどこか一つが古いと、利用者から見た機能は消えます。
モデル選択は設定画面ではなく運用契約
社内AIで管理すべきなのは「どのモデルが強いか」だけではありません。少なくとも、次の四つを一組で扱う必要があります。
- 利用を許可するモデルの正式な識別名
- 明示指定がないときに選ばれる既定モデル
- そのモデルへ渡せるツールと権限
- 候補が消えたときの代替先と停止条件
ここが曖昧だと、更新後にモデルが静かに切り替わっても気づけません。画面上の名前が同じでも、実際の識別名や提供経路が変わることがあります。反対に、契約上は使えるモデルでも、クライアントのフィルターが名前を認識しなければ一覧に出ません。
私は、モデル選択を「利用者の好み」ではなく、業務ごとの実行条件として残す方が安全だと考えています。請求書の読み取り、顧客メールの下書き、コード修正では、必要な精度も許される権限も違います。名前だけを台帳に書くのでは足りません。「この業務ではこのモデル、この道具がなければ停止」という条件まで決めて、初めて引き継げます。
更新後に見るべき三つの差分
最初に確認するのは、一覧の差分です。更新前後で選べるモデルを保存し、追加、消失、既定値の変更を見ます。新しい候補が増えたことより、従来の候補が消えていないかの方が実務では重要です。定期処理が特定モデルに依存している場合、消失はそのまま停止や代替モデルへの意図しない切り替えにつながります。
次は、認証経路ごとの差分です。同じツールでも、APIキー、サブスクリプションのOAuth、クラウド事業者経由では見えるモデルが一致するとは限りません。接続先を切り替える際の確認項目は、複数AIモデルの接続確認とモデル台帳の作り方でも整理しています。OpenCode 1.18.29の修正も、Codex OAuthのモデルフィルターが対象でした。「管理者の端末では見える」だけで完了にせず、実際に社員が使う認証経路で確認します。
最後に、道具の差分を見ます。モデルが選べても、必要な検索、質問、ファイル操作がそのセッションに渡されていなければ仕事は終わりません。Codex 0.153.4が指示文へ「利用できる場合」という条件を足したのは、このずれを避ける修正です。会社側でも、モデルの疎通確認だけでなく、主要な道具を一つずつ呼び出す短い検査を用意した方がいい。
現場で起きる失敗
典型的なのは、更新直後に新モデルを全員の既定値へ変えることです。一部の端末や認証方式だけ候補が見えないと、チーム内で出力が揃いません。担当者は同じ手順を使っているつもりでも、裏では別モデルが動いている。品質差をプロンプトの問題だと誤認し、指示文を延々と直すことになります。
もう一つは、モデル名を文字列の前方一致だけで判定する実装です。OpenCodeの修正が示す通り、バージョン表記の想定が外れると正規のモデルまで除外されます。新モデルの命名規則を先回りして決めつけるより、公式カタログから取得した識別名を記録し、未知の形式を勝手に捨てない方が壊れにくい設計です。
ただし、未知のモデルを自動で本番業務へ通すのも危険です。検出と利用許可は分けます。新しい識別名を見つけたら管理者へ通知し、短い評価を通した後に業務別の許可表へ加える。この一段が手綱になります。
まず一つだけ試すなら
毎朝動くAI処理を一つ選び、実行記録に「要求したモデル」「実際に使われたモデル」「利用できた道具」を残してください。更新前後でこの三項目が変わったら止める。利用した認証経路とツールの版も一緒に残せば、別の端末で再現しやすくなります。これだけでも、結果が変わった原因をプロンプト、モデル、権限のどこから調べるべきか絞れます。
確認用の仕事は、本番データを書き換えないものにします。たとえば、既知の短い文書を読ませ、指定した形式で要約し、承認が必要な操作の直前で停止させる。期待する結果、使う道具、止まる地点を固定しておけば、モデル更新による差と権限設定の差を切り分けられます。評価を自由作文だけにすると、文章の好みしか比べられません。
代替モデルへ切り替える場合も、無条件には進めません。閲覧と下書きは代替先で続けても、顧客への送信、公開、削除、金額の確定は止める。性能順位ではなく、業務の責任範囲で切り替え条件を決めます。これなら新モデルが一覧から消えた日でも、安全な作業だけは継続できます。
今回の二つの修正は、新モデルの性能評価ではありません。AIへ仕事を委譲する入口で、見えている選択肢と実際に使える能力を一致させる話です。モデル名の流行を追うより、既定値と道具の組み合わせを記録する。会社でAIを安定して回すなら、先に整えるのはこちらです。