Codex で `gpt-image-2` モデルが存在しません: Status、Image API、provider の切り分け

Codex が The model 'gpt-image-2' does not exist、または「gpt-image-2 モデルが存在しません」と返しても、最初にモデル名を変えないでください。先に、どの surface が失敗したのかを分けます。OpenAI のドキュメントには gpt-image-2 が載っていますが、Codex のセッション、Image API、Responses の tool、外部 provider、組織や project の access gate は別々に失敗します。

まずこの表で切り分けます。

停止ルール：Codex だけが incident window で失敗したなら、status と session reset を先に行い、product code の変更は後にします。

速い答え

このエラーは一つの意味だけではありません。Codex 内なら status/session/tool routing の問題かもしれません。直接 API なら endpoint、project、organization verification、request shape の問題かもしれません。provider 経由なら model mapping や base URL の問題かもしれません。だから最初の仕事は、モデル名を変えることではなく、owner を決めることです。

2026-06-03 の確認では、OpenAI の image generation docs は gpt-image-2 を掲載しています。つまり、エラー文だけでは「モデルが世界中で存在しない」とは言えません。ある surface がそのモデルに到達できなかった、という証拠です。

Codex がそう表示する理由

Codex は作業 surface であり、あなたの https://api.openai.com/v1/images/generations への直接 request ではありません。Codex には session state、auth state、tool availability、routing、service health があります。どれかが image route に到達できないと、公式 docs にモデル名があっても model-not-found 風のメッセージになります。

日本語の開発者向け情報では、provider/API 設定、Codex の画像生成、OpenAI Help、外部記事が同じ問題の説明として混ざりがちです。これは読者が「モデルが本当にあるか」だけでなく、「Codex、provider、公式 API、Responses のどこを直せばよいか」で迷っているという合図です。したがって日本語版は背景説明より先に route split を出す必要があります。

普通の API 実装ミスなら owner は request に近い場所にあります。endpoint、key、project、organization、provider mapping、Responses tool shape のどれかです。Codex-only failure はその前段にある場合があります。repo が Image API を呼んでいないなら、application code を最初に直すのは遅いだけでなく危険です。

先に Status と Codex session を確認する

Codex の中だけで失敗している場合は、次の順序で確認します。

1. OpenAI Status を開き、同じ時間帯に Codex incident があるかを見る。
2. monitoring または resolved になってから同じ Codex task を一度 retry する。
3. fresh session を作るか、authentication を refresh する。
4. CLI / app が古ければ update する。
5. timestamp、exact error、task、image tool の有無を残す。
6. それでも失敗するか、direct API でも失敗した時だけ API/provider の検証に進む。

この順序にすると、正しいモデル名を誤って消すリスクを避けられます。incident 中に gpt-image-2 を別名へ変えると、後から billing、logs、retry、reproduction が読みにくくなります。

OpenAI Image API を最小 request で確認する

自分の OpenAI API route が gpt-image-2 に届くかを確かめる時は、公式 base URL、同じ organization、同じ project だけでテストします。provider、proxy、複雑な prompt、business wrapper は混ぜません。

bash
curl https://api.openai.com/v1/images/generations \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-image-2",
    "prompt": "A small lighthouse on a cliff, simple test image",
    "size": "1024x1024"
  }'

Image API の詳細な contract は隣の記事にまとめています：GPT-Image-2 API Guide。

Image API と Responses を混ぜない

Image API と Responses image tool は request shape が違います。直接画像を作るなら Image API に model: "gpt-image-2" を渡します。assistant や agent の一部として画像を作るなら、main model に image_generation tool を付ける形になります。

この混同はエラーを増やします。Image API の model field を Responses の main model として使う、または Responses の tool shape を /images/generations に投げると、見た目は model error でも owner は request shape です。

js
const response = await client.responses.create({
  model: "gpt-5.5",
  input: "Create a simple test image and explain the composition.",
  tools: [{ type: "image_generation" }]
});

main model の具体名は account と docs によって変わります。固定すべきなのは名前ではなく、direct image endpoint と Responses tool の分離です。

Provider や custom base URL の場合

OpenAI-compatible provider は OpenAI 風の名前を受け付けることがありますが、model map、billing、availability、fallback、upstream account は provider の契約です。provider が The model 'gpt-image-2' does not exist を返しても、OpenAI direct route が存在しない証明にはなりません。

確認する点は次です。

• base URL は本当に https://api.openai.com/v1 か、それとも provider/proxy か。
• provider の model list は gpt-image-2 を exact に含むか。
• provider が別 endpoint、route name、image mode を要求していないか。
• provider key と OpenAI docs、または OpenAI key と provider docs を混ぜていないか。
• price、speed、availability、quota、refund claim はこの run で検証済みか。

laozhang.ai は API/developer/provider route の文脈でだけ有用です。価格や coverage は provider-owned claim として扱い、OpenAI official pricing とは分けます。

Access、project、organization の gate

公式 docs にモデルがあることと、すべての key が使えることは別です。Image API は organization verification、project scope、region/account state、key permissions の影響を受けることがあります。ChatGPT や Codex の product access は Platform API access を保証しません。

direct OpenAI でも失敗するなら、次を保存します。

• endpoint と base URL
• model name
• request id または response headers
• organization と project
• verification state
• timestamp と timezone
• region、network path、proxy
• 一番小さい reproducible request

この evidence pack があると、support は owner を Codex、OpenAI API、provider、network、access gate に分けられます。

Status resolved 後の順序

Status が resolved なのに Codex が失敗する時は、短い ladder で確認します。

1. 同じ Codex task を一度だけ retry。
2. fresh Codex session または auth refresh。
3. Codex CLI / app を update。
4. 同じ network から direct Image API test。
5. provider を使うなら model list と base URL を別々に確認。
6. request id と minimal repro を持って support/provider ticket を開く。

一つの surface が通ったら、そこで拡大を止めます。direct OpenAI が通って provider が落ちるなら provider owner。fresh Codex で通るなら session/route state。direct OpenAI が access error なら org/project owner です。

よくある質問

gpt-image-2 は本当に OpenAI のモデルですか？

はい。本 run では OpenAI image generation docs に gpt-image-2 が掲載されています。Codex の error だけでモデル不在とは判断しません。

別のモデル名に変えるべきですか？

最初の対応としては不要です。実際に使っている route の docs が別の supported model または alias を要求する時だけ変えます。

Direct API は成功し、Codex だけ失敗します

application route は第一 owner ではない可能性が高いです。Codex session を refresh し、status が安定してから retry し、direct API success を evidence として残します。

provider が HTTP 400 または model_not_found を返します

provider の model list、base URL、endpoint、billing、upstream access を確認します。OpenAI direct が成功しているなら provider 側の coverage/mapping 問題です。

ChatGPT や Codex plan は Image API access を保証しますか？

いいえ。ChatGPT product、Codex tool、Platform API key は別 surface です。

保存すべき evidence は何ですか？

exact error、surface、model name、base URL、endpoint、org/project、timestamp、request id、status state、minimal reproduction を保存します。