Codex MiniとAzure OpenAIの違い・運用条件と選ぶ基準

Codex Miniという名前を三つに分ける

検索結果で「Codex Mini」とだけ表示されると、CLIの標準モデル、APIで指定するモデルID、Azureのモデルカタログに並ぶ選択肢を一つにまとめてしまいがちです。しかし、同じ文字列に見えても、どのサービスが管理し、どの接続先で使い、いつまで提供されるかは別々に決まります。最初に名前の層を分けると、古い解説にある価格や上限を現在のAzure環境へそのまま持ち込む誤りを減らせます。

codex-mini-latestはCodex CLI向けの別名

OpenAIのモデルページは、codex-mini-latest をCodex CLI向けに最適化した高速な推論モデルと説明し、o4-miniを基に調整したモデルであることを示しています。一方で同じページのスナップショット欄にはDeprecatedの表示があります。つまり、この名前を見つけたからといって、これから新規にAPIの中心へ据えるべきだとは限りません。まずその文字列が、既存のCLI設定に残る過去の指定なのか、現在のポータルで選べる候補なのかを確かめます。出典: OpenAIのモデルページ。

GPT-5.1-Codex miniは旧世代のモデルID

GPT-5.1-Codex miniは、GPT-5.1-Codexを小型化した世代名として使われてきました。OpenAIの全モデル一覧では、GPT-5.1-Codex、GPT-5.1-Codex-Max、GPT-5.1-Codex Mini、GPT-5-Codex、codex-mini-latest が非推奨モデルの欄に並んでいます。ここで大事なのは、miniという単語が「安くて新しい」という意味を自動的に持たないことです。新規採用では、現行モデル一覧と対象サービスの提供条件を先に確認します。出典: OpenAI APIの全モデル一覧。

Azureのモデル名はデプロイ先で読み替える

Microsoft Foundryのモデル一覧には、gpt-5.1-codex-mini と codex-mini が別の表記で掲載されています。前者はGPT-5.1世代のCodex系モデルID、後者はo4-miniを基にしたCodex向けモデルとして説明されています。Azureでは、画面上のモデルIDと、利用者が作成したデプロイ名が異なることもあります。Codex CLIの設定に入れる値は、記事や検索結果の名前ではなく、対象のデプロイに割り当てた実際の名前を記録するのが安全です。出典: Microsoft Foundryのモデル仕様。

2026年9月12日に確認すべき「いま」

このKWを今読む意味は、miniという名前が残っていることと、実際に新規選択すべきモデルが一致しなくなっているからです。OpenAIのモデル一覧は世代をまたいで更新され、Azure側のドキュメントも同じモデル名を別の提供単位で掲載します。日付を付けずに「最新のCodex Mini」とだけ説明すると、読者が古いモデルを新規設定に採用する可能性があります。本記事では、2026年9月12日に公式ページで確認できる状態を基準にします。

OpenAI側は旧miniを新規採用の前提にしない

OpenAIの全モデル一覧には、現在の代表的な候補としてGPT-6 Astra、GPT-5.6系、GPT-5.4 Mini、GPT-5.3-Codexなどがあり、旧世代のCodex系にはDeprecatedが付いています。これは過去のモデルがすぐ全環境から消えるという意味ではありませんが、これから作る設定の基準を旧名に置く理由は弱くなっています。既存アプリの互換性確認で旧IDを見る場合と、新しい作業のモデルを決める場合を分け、後者では現行カタログを先に開きます。出典: OpenAI APIのモデル一覧。

Microsoft側は候補一覧と実利用を分ける

MicrosoftのCodex手順は、Azure上で使える推論モデルの例としてGPT-6 Astra、GPT-5.6 Sol、GPT-5.3-Codex、GPT-5.2-Codex、GPT-5.1-Codex系、GPT-5-Codexなどを挙げています。これはAzureを経由したCodex CLIの構成を考えるうえで有用ですが、サブスクリプションやリージョンの条件を省略して全利用者に同じ表示が出ると読むものではありません。実際のモデルカタログ、対象リージョン、デプロイ操作がそろって初めて利用候補になります。出典: MicrosoftのCodex構成手順。

Azure OpenAIでCodexを使う場合の構成

AzureでCodexを使うときは、モデルそのものを買い直すというより、Codex CLIの接続先をAzureのモデルデプロイへ向けます。Microsoftの公式手順では、Azureのプロジェクトでモデルをデプロイし、エンドポイントと認証用の環境変数を用意し、Codexの設定ファイルからAzureプロバイダーを指定する流れです。OpenAIの通常のAPIエンドポイントへ送る構成と、Azureのリソースへ送る構成を混ぜないことが重要です。

Step 1: 先にモデルの提供元を決める

最初に、OpenAIのAPIを使うのか、Microsoft FoundryでAzure側へ配置したモデルを使うのかを決めます。前者ならOpenAIの現行モデルIDと料金ページを基準にし、後者ならAzureのモデルカタログ、対象リージョン、契約中の利用条件を基準にします。両方を同じ設定ファイルで試す場合も、接続先、モデル名、請求の単位を一緒に書き換えず、比較対象を一つずつ固定します。これで「同じminiなのに結果が違う」というとき、提供元とモデルのどちらが原因かを追いやすくなります。

Step 2: デプロイ名とモデルIDを記録する

Azureのポータルでモデルを配置したら、カタログに表示されたモデルIDと、自分で付けたデプロイ名を別の値として控えます。Microsoftの例では設定の model に実際のAzureデプロイ名を入れる形が示されています。gpt-5.1-codex-mini を選んだつもりでも、デプロイ名を codex-mini-team としていれば、Codex CLIから指定する値は後者です。名前の取り違えを避けるため、作成日、リージョン、モデルID、デプロイ名を一行ずつ記録します。

Step 3: Codex CLIの接続先を最小構成で確認する

Microsoftの公式例に沿うと、~/.codex/config.toml には次のような最小構成を置けます。YOUR_RESOURCE_NAME とデプロイ名は自分のAzure環境に合わせて置き換え、認証用の値そのものはファイルへ直接書かず、env_key が参照する環境変数から渡します。モデル名をいきなり新しい世代へ変えるのではなく、まず接続、短い質問、読み取り結果の順に確認します。

model = "gpt-5-codex"
model_provider = "azure"
model_reasoning_effort = "medium"

[model_providers.azure]
name = "Azure OpenAI"
base_url = "https://YOUR_RESOURCE_NAME.openai.azure.com/openai/v1"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"

この例で gpt-5-codex と書かれている場所は、Azureで作成したデプロイ名に置き換える前提です。Microsoftのページは、v1 Responses APIでは /v1 を含めること、APIキーを文字列として設定せず環境変数を参照することも説明しています。設定を保存した後は、Codex CLIの版と表示されたプロバイダーを控え、短い読み取り作業で応答を確かめます。出典: Microsoft Foundryの設定例。

Codex MiniとAzure OpenAIを選ぶ判断軸

名前の新しさだけで判断すると、現行性、料金、応答速度、データの置き場所、運用のしやすさを同時に比べられません。Codex MiniというKWから入った場合でも、最終的には「どこでモデルを動かすか」と「どの作業をどの品質で完了させたいか」を別々に決めます。Azureを選ぶ理由が組織の境界や既存の請求管理にあるのか、OpenAIを選ぶ理由が新しいモデルを早く試せる点にあるのかを、文章で説明できる状態にします。

小さな作業で比較する

候補を比べるときは、同じ短い作業を一つのモデルへ順番に渡します。たとえば、既存ファイルの構成を説明させ、変更案だけを出させ、最後に小さなテストコードの下書きを依頼する流れです。入力、対象ファイル、完了条件をそろえ、応答時間、説明の具体性、不要な変更の提案、確認にかかった時間を記録します。名前や価格表だけでなく、実際の作業で必要な確認量まで比べると、miniを選ぶ理由が明確になります。

チームで使う前に確認する

複数人で使うなら、モデル名だけでなく、誰がどのAzureプロジェクトを使い、どのリージョンへ接続し、デプロイ更新を誰が確認するかを決めます。Microsoftの手順にはContributor権限、Windows 11ではWSL2、Codex CLIの設定ファイルなどの前提が示されています。個人の端末で動いたからチームでも同じとは限らないため、OS、CLI版、設定ファイルの項目、モデルカタログの表示を同じ記録様式で残します。出典: Microsoft Foundryの前提条件。

既存設定から移行するときの確認手順

古いCodex Miniの設定が残っている場合、いきなり別のモデルへ置き換えるより、現状を記録してから一つずつ変える方が原因を追えます。OpenAIの全モデル一覧で非推奨表示を見つけても、すぐに削除する必要はありません。まずどの入口で使われ、どのモデルIDを呼び、どの結果を期待しているかを残します。そのうえで、Azureに移すのか、OpenAI側の現行候補へ寄せるのかを選びます。

Step 4: 旧設定の出どころを特定する

codex-mini-latest、gpt-5.1-codex-mini、Azureのデプロイ名のどれが設定に書かれているかを確認します。設定ファイル、端末の起動時表示、利用中のプロジェクト、請求画面を別々に見て、同じ名前が複数の場所にないかを確かめます。古い記事に記載されたモデル名だけを根拠にせず、現在の公式ページと手元の表示を並べて、既存設定がどのサービスに属するかを判断します。

Step 5: 現行候補と同じ作業で比べる

移行候補を決めたら、読み取りだけの確認、変更案の作成、小さな修正の確認という三つの課題を同じ条件で実施します。いきなり大きなリポジトリ全体を対象にすると、モデル差と準備時間が混ざります。結果を見るときは、正答だけでなく、触れたファイルの範囲、説明の根拠、失敗時の戻しやすさも記録します。Codex CLIの版、モデルID、デプロイ名、実施時刻を一緒に残すと、後から比較を再現できます。

Step 6: 非推奨表示を移行計画へ変える

非推奨は「今この瞬間に全てが止まる」という表示ではなく、将来の選択肢から外す準備を促す合図です。OpenAI APIでは新しい現行モデルを確認し、Azureでは対象リージョンとモデルカタログを確認します。移行先が決まったら、旧設定を消す前に新設定で短い作業を終え、速度、結果、費用、確認負担を比べます。問題が残ったときに戻せるよう、旧モデル名と変更日を記録し、段階的に切り替えると判断しやすくなります。

まとめ

Codex MiniをAzure OpenAIで使いたいときは、まず codex-mini-latest、GPT-5.1-Codex mini、Azureのcodex-miniを同じ名前として扱わないことが重要です。2026年9月12日時点のOpenAI公式一覧では旧mini系に非推奨表示があり、Microsoft Foundryの公式手順ではAzure上でCodex CLIを使うモデル候補と設定方法が案内されています。新規構成では、現行カタログ、実際のデプロイ名、CLI版、リージョンを確認し、同じ小さな作業で結果を比べてから運用を決めてください。

出典: OpenAI APIの全モデル一覧、OpenAI APIのcodex-mini-latest、Microsoft FoundryのCodex手順。