# Codex の新モデルが表示されないとき：公式 Model Catalog と Sub2API を同期する

> Canonical: https://vxi.me/ja/posts/codex-new-model-catalog-sub2api/
> Locale: ja-jp
> Published: 2026-10-05
> Updated: 2026-10-05
> Markdown: https://vxi.me/ja/posts/codex-new-model-catalog-sub2api.md

Codex に新しいモデルが追加されたとき、私は最初からクライアント設定を書き換えないようにしています。

まず公式のモデル catalog に本当にその slug があるかを確認し、その後でローカル catalog、クライアントの最低バージョン、最後に Sub2API のルーティングを確認します。

この順番にすると、「モデルが選択肢に出ない」「選べるが Sub2API が拒否する」「上流で別モデルに変わる」という三つの問題を混ぜずに済みます。

私が今固定している流れは次です。

```text
OpenAI 公式 models.json
        ↓
実際のモデル slug を確認
        ↓
ローカル codex-models.json へ同期
        ↓
minimal_client_version を確認
        ↓
Codex / Desktop を再起動
        ↓
Sub2API の許可リストとモデルマッピング
        ↓
Responses API で元のモデル名を透過
        ↓
要求モデル / 上流モデルを比較
```

現在の公式 catalog にある `gpt-6.1-sol` を例にすると、条目には次の情報があります。

```text
slug: gpt-6.1-sol
display_name: GPT-6.1-Sol
minimal_client_version: 0.153.0
supported_in_api: true
```

つまり最初にやるべきなのは、自分でそれらしいモデル名を作ることではなく、公式 catalog を確認することです。

## slug だけ手書きせず、公式の完全な条目を同期する

私の `~/.codex/config.toml` ではローカルモデル catalog を指定しています。

```toml
model_catalog_json = "~/.codex/codex-models.json"
```

新モデルを同期するときは、まずバックアップします。

```bash
cp ~/.codex/codex-models.json \
  ~/.codex/codex-models.json.bak.$(date +%Y%m%d-%H%M%S)
```

次に公式 catalog を取得します。

```bash
curl -fsSL \
  https://raw.githubusercontent.com/openai/codex/main/codex-rs/models-manager/models.json \
  -o /tmp/codex-models-official.json
```

対象モデルを指定します。

```bash
MODEL="gpt-6.1-sol"
```

まず公式データに存在するか確認します。

```bash
jq --arg MODEL "$MODEL" '
  .models[]
  | select(.slug == $MODEL)
  | {slug, display_name, minimal_client_version, supported_in_api}
' /tmp/codex-models-official.json
```

見つかったら、簡略化した条目を手書きするのではなく、公式オブジェクト全体をローカル catalog にマージします。

```bash
jq --arg MODEL "$MODEL" \
   --slurpfile official /tmp/codex-models-official.json '
  .models = (
    [.models[] | select(.slug != $MODEL)]
    +
    [$official[0].models[] | select(.slug == $MODEL)]
  )
' ~/.codex/codex-models.json > ~/.codex/codex-models.json.new

jq empty ~/.codex/codex-models.json.new &&
mv ~/.codex/codex-models.json.new ~/.codex/codex-models.json
```

こうしておけば `slug` だけでなく、display name、reasoning level、コンテキスト制限、ツール能力、バージョン条件なども公式と揃います。

更新後は Codex / ChatGPT Desktop を完全に終了してから開き直します。macOS なら私は `⌘ + Q` でプロセスごと終了させます。

## catalog にあるのに表示されない場合

まずローカル条目を確認します。

```bash
jq --arg MODEL "$MODEL" '
  .models[]
  | select(.slug == $MODEL)
  | {slug, display_name, minimal_client_version}
' ~/.codex/codex-models.json
```

条目が存在するなら、次に見るのは現在のクライアントバージョンと `minimal_client_version` です。

`gpt-6.1-sol` の現在の公式値は `0.153.0` です。このフィールドはクライアント側の互換性ゲートとして扱うのが自然です。

私の確認順序は次です。

```text
Codex を更新
    ↓
クライアントを再起動
    ↓
モデルが表示されるか確認
    ↓
まだ必要なら最低バージョンを診断
```

純粋に「バージョン条件で UI から隠れているのか」を切り分ける場合、バックアップ後に単一モデルの値を一時的に `null` にすることはできます。

```bash
jq --arg MODEL "$MODEL" '
  (.models[]
    | select(.slug == $MODEL)
    | .minimal_client_version
  ) = null
' ~/.codex/codex-models.json > ~/.codex/codex-models.json.new &&
jq empty ~/.codex/codex-models.json.new &&
mv ~/.codex/codex-models.json.new ~/.codex/codex-models.json
```

ただし、これは診断用です。

**選択肢に表示されることと、現在のクライアントがそのモデルに本当に対応していることは別です。**

通常は先にクライアントを更新します。

## Codex 側で見えた後は Sub2API を別レイヤーとして確認する

ローカル Codex で `gpt-6.1-sol` が選べても、それだけでは実際の API リクエストが正しく流れる保証にはなりません。

Sub2API 側にも許可やマッピングがあります。

公式 slug が存在する場合、私はできるだけ原名のまま通します。

```text
Codex:    gpt-6.1-sol
             ↓
Sub2API:  gpt-6.1-sol
             ↓
OpenAI:   gpt-6.1-sol
```

確認するポイントは主に次です。

- OpenAI グループのモデル許可リストに新モデルがあるか
- アカウント単位の許可リストで制限されていないか
- モデルマッピングで旧モデルへ強制変換されていないか
- unknown model のデフォルト fallback で別 slug に送られていないか

公式に実在する slug なら、必要のない alias は増やしません。

マッピングが少ないほどログを読みやすく、将来の障害切り分けも簡単です。

Codex provider は Responses API のままにします。

```toml
wire_api = "responses"
```

もし `gpt-6 → gpt-6.1-sol` のような alias が本当に必要なら、暗黙の fallback ではなく明示的な Sub2API ルールとして管理します。

## 最終確認は「見えること」ではなく上下流が一致すること

まずローカル catalog に slug があることを確認します。

```bash
jq -r '.models[].slug' ~/.codex/codex-models.json | grep "$MODEL"
```

次に実際のリクエストを送り、Sub2API のログを確認します。

理想は次です。

```text
要求モデル = gpt-6.1-sol
上流モデル = gpt-6.1-sol
リクエスト成功
```

つまり完了条件は、

```text
Codex の選択肢に表示される
        +
要求モデルが正しい
        +
Sub2API の上流モデルも正しい
        +
実際の呼び出しが成功する
```

です。

問題がある場合はレイヤーごとに見ます。

```text
選択肢にない
→ catalog / クライアントバージョン

選択できるが Sub2API が拒否
→ 許可リスト

要求モデルは正しいが上流が違う
→ マッピング / デフォルト fallback

上流モデルも正しいのに失敗
→ 上流権限、アカウント、API 互換性
```

この手順を固定してから、新しい Codex モデルが出るたびに「どこを変えるべきか」を最初から考え直す必要がなくなりました。

まず公式 catalog を信頼し、ローカル表示と Sub2API ルーティングを別々に確認するのが一番安定します。

Codex を自分の代理エンドポイントに接続しているなら、[CLIProxyAPI と Codex の構成](/ja/posts/cliproxyapi-codex-docker-proxy/) も関連します。現在の Codex 自体の位置付けを理解したい場合は、[新しい Codex は何が変わったのか](/ja/posts/what-changed-in-the-new-codex/) も参考になります。

## 関連資料

- [OpenAI Codex 公式 models.json](https://raw.githubusercontent.com/openai/codex/main/codex-rs/models-manager/models.json)
- [CLIProxyAPI 経由で Codex を使う構成](/ja/posts/cliproxyapi-codex-docker-proxy/)
- [新しい Codex は何が変わったのか](/ja/posts/what-changed-in-the-new-codex/)