ChatGPT Images 2.0、Codex での GPT-Image-2 生成、OpenAI API の gpt-image-2 は、近い名前でも同じ使い方ではありません。人がプロンプトを書き、結果を見て、修正を頼み、画像を保存するなら ChatGPT が最短です。画像が MDX、コード、ドキュメント、公開アセットと一緒に管理されるなら Codex が向いています。ユーザー向け機能として画像を生成するなら、保存、再試行、ログ、権限、課金を持てる OpenAI API が主ルートです。プロバイダー経由は便利な場合がありますが、価格、別名、失敗時の扱い、データ条件はそのプロバイダーの契約です。
クイック判断
| ルート | 使う場面 | 確認する所有者 |
|---|---|---|
| ChatGPT Images 2.0 | 手作業の生成、編集、素材アップロード、目視確認、ダウンロード。 | ChatGPT のプラン、workspace、アプリ側の制限。 |
| Codex GPT-Image-2 | 記事、docs、コード、製品説明に入る画像をリポジトリで管理する。 | Codex タスク、画像クレジット、raw evidence、publish path。 |
OpenAI API gpt-image-2 | アプリが繰り返し生成し、保存、ログ、再試行、コスト管理を必要とする。 | OpenAI API project、model docs、endpoint、billing。 |
| プロバイダーまたは gateway | アクセス、互換層、支払い、検証環境を先に試す。 | provider alias、price、data terms、failure billing、support。 |
2026-05-13 時点では、OpenAI の開発者向け文書は gpt-image-2 を画像生成モデルとして扱い、Image API または Responses API のルートを示しています。Codex の価格面では GPT-Image-2 が Codex クレジットの文脈で扱われます。ChatGPT Images 2.0 は ChatGPT の製品機能です。したがって、ChatGPT の上限、Codex のクレジット、API の請求、プロバイダー価格を一つの費用として混ぜないことが最初の安全策です。
まず一文で分ける
判断の軸はモデル名ではなく、生成結果を誰が運用するかです。人が会話の中で画像を作り、見て、選び、保存するなら ChatGPT。エージェントが画像を作り、原本を evidence に残し、WebP に変換し、MDX に参照を書き、差分としてレビューするなら Codex。ユーザー操作で画像が生成され、アプリの storage、database、queue、billing に入るなら OpenAI API です。
この分け方にすると、よくある失敗を避けられます。ChatGPT で良い画像ができても、API の request payload、失敗処理、料金、保存先が検証されたわけではありません。Codex が画像を生成できても、外部ユーザー向けの runtime endpoint になったわけではありません。プロバイダーで同じような model alias が動いても、その価格が OpenAI 公式価格になるわけではありません。
| やりたい仕事 | 開始ルート | 理由 | 切り替える条件 |
|---|---|---|---|
| 構図、文字量、色、雰囲気を試す | ChatGPT | 人の判断で最速に回せる。 | request ID、storage、retry、user policy が必要になる。 |
| 記事や docs の画像を作る | Codex | ファイル、原本、MDX、alt、report を repo 内で扱える。 | ユーザーが本番環境から生成する。 |
| 画像生成をアプリ機能にする | OpenAI API | endpoint、logging、storage、billing、monitoring を設計できる。 | 一回限りの手作業アセットにすぎない。 |
| gateway や支払いを試す | provider route | アクセスや支払いの摩擦を下げられる場合がある。 | alias、price、data terms、support が説明できない。 |
公式の境界は三つに分かれる
OpenAI API 側で確認するのは developer contract です。model ID、snapshot、Image API、Responses API、対応サイズ、入力画像、出力形式、エラーの扱い、rate limit、billing owner を見ます。単発の生成や編集には Image API が扱いやすく、会話や tool flow の一部として画像生成を組み込むなら Responses API の方が自然な場合があります。
ChatGPT 側で確認するのは product contract です。プラン、workspace policy、画像機能の有効性、素材アップロード、出力の保存、手動ダウンロード、履歴の扱いが中心になります。強みは人が見て判断する速度であり、アプリ側の request log や storage を持つことではありません。
Codex 側で確認するのは repository workflow です。Codex は画像を生成し、生成ディレクトリから raw PNG を見つけ、evidence にコピーし、公開用 WebP を置き、MDX 参照を更新し、画像レポートに provenance を残せます。これは記事や docs の画像にとって大きな利点です。
| 証拠面 | 証明できること | 証明しないこと |
|---|---|---|
| OpenAI developer docs | gpt-image-2 と Image API / Responses API の存在。 | ChatGPT のアプリ制限や Codex credits。 |
| ChatGPT product notes | ChatGPT 内での画像生成と編集の入口。 | プロダクトの request log、retry、billing。 |
| Codex pricing and workspace | Codex の画像クレジットと repo 内の作業所有者。 | 外部アプリが Codex を endpoint として呼べること。 |
| provider contract | その provider の alias、price、support。 | OpenAI 公式価格や公式保証。 |
ChatGPT は人が判断する画像作業に使う
ChatGPT は、人が完成度を見て決める作業に向いています。たとえば、ポスターの方向性、SNS 画像、社内資料のビジュアル、アップロード画像の修正、文字が読めるかの確認、API 用プロンプトを作る前の探索です。会話の中で「もう少し余白を増やす」「文字を短くする」「背景を変える」といった指示をすぐ試せます。
確認すべき制限は API dashboard ではなく ChatGPT 側にあります。プラン、workspace policy、画像生成回数、アップロード制限、エクスポート形式、履歴、素材の利用権、生成モードを見てください。将来プロダクト機能に移すなら、最終プロンプト、入力素材、期待サイズ、禁止要素、受け入れ基準、失敗例を記録してから API 側で再検証します。
ChatGPT のままでよいのは、人が一枚ずつ確認し、手動で保存し、失敗しても会話でやり直せる場合です。ユーザー別の quota、請求、保存、再試行、監査、権限制御、latency budget が必要になった瞬間に、手作業ルートは主役ではなくなります。
Codex はリポジトリ内アセットに使う
Codex は、画像がリポジトリの成果物であるときに強いです。技術ブログの cover、API route map、pricing board、トラブルシューティング図、docs の説明図は、本文、frontmatter、alt text、画像ディレクトリ、最適化、レビューと結びつきます。Codex はその文脈を読み、画像と周辺ファイルを同じタスク内で更新できます。
良い Codex 画像フローには、生成ディレクトリの raw PNG、run evidence 内のコピー、公開用の public/posts/ja/chatgpt-gpt-image-2-vs-codex-gpt-image-2-api/img/cover.webp、MDX の ./img/... 参照、alt text、image report、hash が含まれます。これにより、あとで画像の由来、locale ごとの生成、最適化の有無、本文との対応を追跡できます。
Codex を production API と考えるのは危険です。Codex はコードや docs を直し、テスト素材を生成し、実装を補助できます。しかしエンドユーザーがボタンを押して画像を生成するなら、アプリ側が OpenAI API などの runtime route を持ち、auth、storage、logging、retry、billing、policy を管理する必要があります。
プロダクト機能なら OpenAI API を使う
OpenAI API は、画像生成がプロダクト機能になるときのルートです。ここで必要なのは「一度生成できた」証拠ではなく、「運用できる」設計です。route、model ID、endpoint family、input images、size、quality、output format、user、project、request metadata、latency、retry count、storage path、cost source、error class を記録します。
Image API と Responses API の使い分けも、UI と運用で決めます。単発の生成や編集なら Image API がわかりやすいことが多く、会話状態や tool call、複数回の修正と組み合わせるなら Responses API が適することがあります。どちらでも、入力画像の権利、出力の保存、content rules、unsupported parameters、rate limit、billing owner を先に確認します。
最小の本番テストは小さくて構いません。低コストのリクエストを一つ流し、入力と出力を保存し、storage URL を作り、失敗時のユーザー表示を決め、cost source を記録し、timeout、refusal、storage failure、provider error を分類します。ここまでできて初めて、queue、cache、concurrency、monitoring の話に進めます。
課金は一つの GPT Image 2 価格にまとめない
ChatGPT plan caps、Codex image credits、OpenAI API billing、provider pricing は別の会計面です。似た名前のモデルでも、上限、支払い、usage log、refund、support owner が違います。予算やチーム説明では、どのルートの費用なのかを必ず分けて記録します。
| 費用または上限 | 見る場所 | 意味 |
|---|---|---|
| ChatGPT plan caps | ChatGPT の plan と workspace。 | 手動生成の可用性と回数。 |
| Codex image credits | Codex pricing と workspace usage。 | agent task 内の画像生成消費。 |
| OpenAI API billing | OpenAI API project、pricing、usage。 | アプリが呼ぶ生成リクエストの費用。 |
| Provider pricing | Provider dashboard と terms。 | その provider route にだけ有効な価格。 |
プロバイダー経由は、支払い、互換 API、地域的なアクセス、検証環境、移行テストに役立つ場合があります。ただし、model alias、price unit、failed-generation billing、refund、data handling、support owner、exit plan を明確にできないなら、production の主ルートにするべきではありません。
小さなルートテストで判断する
一つの成功画像だけで決めないでください。ChatGPT では prompt、input images、final output、export constraint、human acceptance note を保存します。Codex では raw PNG、evidence copy、published WebP、MDX reference、image report を残します。API では request payload、model、endpoint family、latency、storage path、error behavior、cost source を記録します。Provider では alias mapping、price unit、data terms、support owner、failure billing を確認します。
比較する軸は output の見た目だけではありません。control、ownership、recovery、auditability を見ます。control はパラメータと安全性、ownership は file、log、cost、recovery は retry と fallback、auditability は後から説明できるかです。運用責任を説明できるルートが、その仕事の正しいルートです。
よくある誤読
Codex GPT-Image-2 は OpenAI API そのものではない
Codex は agent workflow の中で画像を生成できますが、外部ユーザー向けの production endpoint ではありません。Codex は workspace の作業面、API は runtime integration surface と分けます。
ChatGPT の成功画像だけでは本番運用にならない
ChatGPT は人が見る創作には強いですが、request IDs、server logs、retry、storage、user policy、billing attribution は別に設計が必要です。
Provider price は OpenAI 公式価格ではない
Provider route は便利な場合がありますが、価格、alias、data terms、support は provider contract です。OpenAI 公式価格として扱うには OpenAI の公式ソースが必要です。
画像品質だけでルートは決まらない
複数ルートで似た品質が出るなら、判断は再現性、ファイル所有者、ログ、課金、失敗復旧、権限管理に移ります。きれいでも追跡できない結果は production-ready ではありません。
次に見るもの
- ChatGPT Images 2.0：ChatGPT 側の画像機能と境界。
- GPT-Image-2 API：Image API、Responses API、request shape、provider boundary。
- GPT-Image-2 API Pricing：公式コスト、provider price、予算設計。
- How to Use GPT-Image-2：生成、編集、プロンプト、検証。
- Is GPT-Image-2 Free?：ChatGPT、API、trial、provider free route。
FAQ
ChatGPT Images 2.0 と gpt-image-2 は同じですか？
関係はありますが、同じ契約面ではありません。ChatGPT Images 2.0 は ChatGPT 製品内の機能、gpt-image-2 は developer docs や API logs で確認する model identity です。
Codex GPT-Image-2 を production API として使えますか？
その理解は避けるべきです。Codex は repo-bound assets の生成、証拠保存、MDX 更新に向いています。ユーザー向け生成には API route、auth、storage、logs、retries、billing が必要です。
開発者は ChatGPT から始めるべきですか、API から始めるべきですか？
視覚方向の探索なら ChatGPT から始めます。機能として出すなら早い段階で API の最小リクエストを作ります。ChatGPT は prompt と受け入れ基準の整理に使います。
ChatGPT 上限、Codex credits、API billing は共有ですか？
共有と考えないでください。ChatGPT は ChatGPT、Codex は Codex usage、API は OpenAI API project、provider は provider contract で確認します。
Provider route はいつ役に立ちますか？
支払い、互換層、アクセス検証、短期テストに役立つ場合があります。production に使う前に alias、price、failure billing、data handling、support、exit plan を確認します。
いつ OpenAI API に切り替えるべきですか？
ユーザー操作で画像を生成する、または user、project、order、time ごとに cost and logs を追う必要があるなら API に切り替えます。その時点で画像生成は手作業ではなくプロダクト機能です。