# GPT Image 2 APIとCodex: 先にルートを決める

> GPT Image 2は使えますが、Images API、Responsesのimage_generation、Codexの作業フロー、外部ゲートウェイは同じ契約ではありません。実装前にリクエスト形と課金境界を分けて確認します。

- Source: https://www.aifreeapi.com/ja/posts/gpt-image-2-api
- Language: ja
- Published: 2026-05-13
- Updated: 2026-05-13
- Publisher: AI Free API (https://www.aifreeapi.com)

GPT Image 2を使うとき、最初に確認すべきことは「どのサンプルコードを貼るか」ではなく、「この画像生成を誰が担当するか」です。単発の画像生成や参照画像を使った編集ならImages APIが自然です。チャットやエージェントの流れの中で画像が必要になるならResponsesの`image_generation` toolを使います。記事のカバー、図解、ドキュメント用ボードなどをリポジトリ内で作るならCodexの作業フローが向いています。統一請求、代替経路、複数モデルのルーティングが目的なら外部ゲートウェイは別契約の選択肢です。

同じGPT Image 2という名前が複数の場所に出てくるため、ここを混ぜると実装もコスト説明も崩れます。よくある失敗は、Responsesの一番上の`model`に`gpt-image-2`を入れること、Codexの利用枠をOpenAI API keyの課金と同じものとして説明すること、外部ゲートウェイの価格をOpenAI公式価格のように書くことです。まずルートを決め、そのルートに合うリクエスト形とログ項目を決めるのが安全です。

![GPT Image 2の4つの利用ルート: Images API、Responses、Codex、外部ゲートウェイ。](https://www.aifreeapi.com/posts/ja/gpt-image-2-api/img/cover.png)

## コードの前にルート表を見る

![Images APIの直接呼び出しとResponsesのimage_generation toolを分けるリクエスト形マップ。](https://www.aifreeapi.com/posts/ja/gpt-image-2-api/img/request-shape-map.png)

バックエンドから画像を1枚出すだけなら、最初はImages APIで十分です。API key、project、モデルアクセス、サイズ、品質、出力保存、エラーを狭い面で確認できます。ユーザーが会話の中で目的を伝え、モデルが必要に応じて画像生成を呼ぶ体験ならResponsesが合います。Codexはまた別で、公開APIエンドポイントというより、作業中のリポジトリでプロンプト、生成ファイル、確認、公開パスをまとめて扱うためのワークフローです。

| いま作りたいもの | 先に見るルート | モデル名の置き場所 | 課金や枠の見方 | 避けたい誤解 |
| --- | --- | --- | --- | --- |
| アプリから直接1枚生成する | Images API | image requestの`model: "gpt-image-2"` | OpenAI APIのproject課金 | Codexをendpoint名として扱う |
| 参照画像を編集する | Images API edits | edit requestの`model` | OpenAI APIのproject課金 | 編集なら必ずResponsesと思い込む |
| 会話型アシスタントが途中で画像を作る | Responses + `image_generation` | 上位modelは文章/推論モデル、画像はtool側 | Responses/API側の課金 | `gpt-image-2`を上位modelにする |
| 記事やDocs用の画像をrepo内で作る | Codexワークフロー | Codexの画像生成能力に任せる | Codex/ChatGPTのplanやcredit | API keyの本番呼び出しと同じにする |
| 統一ゲートウェイや代替経路が必要 | 外部プロバイダールート | ゲートウェイのmodel mappingを見る | プロバイダー独自の価格と制限 | ゲートウェイ価格を公式価格にする |

この表で見たいのは、製品名の多さではありません。画像の仕事をどの面が所有しているかです。Images APIは直接生成と編集を所有します。Responsesはtool orchestrationを所有します。Codexはrepo-localな成果物作成を所有します。外部ゲートウェイはアクセスと請求の別契約を所有します。この分離ができていれば、コード、ドキュメント、請求説明のズレがかなり減ります。

## 直接生成と編集はImages APIから始める

GPT Image 2の公式model IDは`gpt-image-2`です。ユーザー操作が「画像を生成する」「この素材を編集する」に近いなら、最初の実装はImages APIに寄せるのが自然です。呼び出し面が狭く、`model`、`prompt`、`size`、`quality`、出力形式、保存先を順番に確認できます。最初から会話管理、tool call、ストリーミング、ゲートウェイ回避策を全部入れると、どこで失敗したのかが見えにくくなります。

最初のリクエストはあえて単純にします。1つのprompt、正方形サイズ、標準的なqualityで、モデルアクセスと出力保存だけを確認します。ここでorganization verification、project、API key、モデル権限、課金設定のどこに問題があるかを切り分けてから、複数画像、編集、品質差、再試行を増やします。

```ts
import OpenAI from "openai";

const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });

const image = await client.images.generate({
  model: "gpt-image-2",
  prompt: "Create a clean route map for a developer documentation page.",
  size: "1024x1024",
  quality: "medium"
});
```

編集も同じ考え方です。主な仕事が、入力画像を使って別の画像を作ることなら、まずImages API editsを見ます。Responsesを使うのは、画像生成が会話、推論、他のtool、確認フローの一部になるときです。新しいAPIに見えるからResponsesに寄せるのではなく、ユーザー体験が本当にassistant flowなのかを見て決めます。

日本語の読者にとってもう一つ大事なのは、アクセス条件の書き方です。GPT Image系モデルはorganization verificationを求める場合があります。誰かの動画やnoteで動いていたから自分のprojectでも同じとは限りません。記事や社内手順には「必要に応じて組織確認を済ませる」と明記しておく方が安全です。

## Responsesは会話型の道具であり、endpointの置き換えではない

Responsesの`image_generation`は、画像が大きな会話処理の一部になるときに強くなります。たとえば、ユーザーが商品カードの方向性を相談し、モデルがコピーを考え、必要な段階で画像を生成し、最後に保存や公開の説明を返すような流れです。この場合、上位の`model`は会話と判断を担当し、画像生成はtoolが担当します。

ここで最も大事なルールは、`gpt-image-2`をResponsesの上位`model`として扱わないことです。上位には文章や推論に使うモデルを置き、画像生成の指定は`image_generation` tool側に置きます。ここを間違えると、エラーの原因がモデルアクセスなのか、tool設定なのか、Responsesの構造なのか判断しにくくなります。

```ts
const response = await client.responses.create({
  model: "gpt-5.4",
  input: "Plan a product launch card and generate one square image for it.",
  tools: [{ type: "image_generation", model: "gpt-image-2" }]
});
```

Responsesを選ぶ価値は、画像の前後にある文脈を一つのresponse flowで扱えることです。一方で、単発の画像ボタンには重すぎることがあります。tool resultの取り出し、出力ファイルの保存、途中状態、再試行、請求説明まで同時に設計する必要があるからです。まず1枚を安定して出したいだけなら、Images APIから始める方が早く、検証もしやすいです。

## Codexはリポジトリ内の画像制作に向く

日本語の実践記事や動画では、CodexとGPT Image 2を組み合わせる使い方が目立ちます。これは自然です。Codexを使うと、開発中のプロジェクトに合わせてカバー画像、README用の図、UI説明、資料用ボードを作り、そのファイルをそのままレビューできます。ただし、それは「本番アプリがOpenAI API keyで画像を生成する」こととは別です。

Codexを使うべき場面は、成果物がrepoの中に残るときです。プロンプト、raw asset、publish asset、本文の画像参照、レビューコメントを同じ作業単位にできます。逆に、ユーザーからのリクエストを本番バックエンドで受け、ストレージに保存し、課金し、再試行するシステムなら、Images APIかResponsesのどちらかを選ぶ必要があります。

![OpenAI API価格、Codex credit、外部ゲートウェイ価格を分ける課金境界ボード。](https://www.aifreeapi.com/posts/ja/gpt-image-2-api/img/billing-boundary-board.png)

この違いは言葉の問題ではなく、運用責任の問題です。Codexで作った画像資産は、人間が確認して記事やDocsに入れることが多いです。本番APIは、ユーザー操作に対して自動で画像を返し、ログ、失敗、請求、削除、再生成を管理します。同じモデル名が見えていても、責任の重さが違います。

## 価格は三つの箱に分けて書く

GPT Image 2の価格説明は、必ず三つに分けます。OpenAI APIの価格は、Images APIやResponsesをAPI keyで呼ぶときの話です。CodexやChatGPT planのcreditは、Codex作業フローで画像資産を作るときの話です。外部ゲートウェイの価格は、そのプロバイダーが決めるアクセス、倍率、支払い、制限の話です。

この三つを混ぜると、読者は間違った予算を作ります。ゲートウェイの単価はOpenAI公式価格ではありません。Codexの利用枠は本番APIの無料枠ではありません。公式のquality別価格例も、外部ゲートウェイの契約にはそのまま移せません。コスト表を作るなら、最初の列で「この価格は誰の価格か」を明示するべきです。

外部ゲートウェイは、統一キー、ローカル決済、予備経路、複数モデルのrouting、チーム請求を簡単にしたいときに意味があります。その文脈では`laozhang.ai`をAPI gatewayの一例として触れ、詳しい接続は[docs.laozhang.ai](https://docs.laozhang.ai/)や[api.laozhang.ai](https://api.laozhang.ai/)で確認してもらう程度が妥当です。未確認の速度保証、停止しない保証、返金保証、失敗時無料のような主張は書かない方が安全です。

## 本番前にログへ残す項目

![本番運用チェックリスト: route、model、quality、size、output id、storage、retry、非対応機能。](https://www.aifreeapi.com/posts/ja/gpt-image-2-api/img/production-logging-checklist.png)

どのルートを使う場合でも、本番システムではあとから説明できるログが必要です。最低限、route、model ID、quality、size、入力画像数、出力形式、request ID、output ID、保存先、cost、user/project、retry count、error code、account readinessを残します。画像はテキストよりも再現しにくいため、出力を保存するだけでなく、どの条件で作られたかを残すことが重要です。

機能の境界もUIに反映します。GPT Image 2は現在transparent backgroundをサポートしていません。透明背景が必要な製品なら、GPT Image 2ルートの通常オプションとして見せるのではなく、別の処理に分けるか、利用不可として明示します。ここを曖昧にすると、ユーザーは失敗するリクエストを何度も送ることになります。

ストリーミングや途中出力を使う場合は、途中状態を表示するのか、失敗時に部分成果物を保存するのか、再試行で追加課金が発生するのかも決めます。これは単なるbackend detailではありません。読者が本当に実装できるかどうかを左右する、運用上の必須情報です。

## GPT Image 1.5からの移行はモデル名置換だけでは足りない

既存のGPT Image 1.5実装があるなら、`model`文字列だけを置き換える前に、routeを確認し直します。旧実装は直接Images APIだったのか、Responses tool flowだったのか、Codexでのasset productionだったのか、外部gatewayだったのか。ここが違えば、必要なログ、価格説明、アクセス確認、失敗時の処理も変わります。

既存の[OpenAI画像生成API endpoint](/ja/posts/openai-image-generation-api-endpoint)、[OpenAI画像編集API](/ja/posts/openai-image-editing-api)、[OpenAI画像生成API cURL](/ja/posts/openai-image-generation-api-curl)は、一般的なendpointの理解に使えます。GPT Image 2では、API、Responses、Codex、providerの文脈に同時に出てくるとき、どのrouteがあなたの仕事を担当するのかを決める必要があります。

移行レビューでは、三つだけ確認します。ユーザー体験は単発生成なのかassistant taskなのか。出力はproduction storageとbillingに入るのか。価格、制限、利用可否の記述は現在の公式またはプロバイダー情報で確認できるのか。この三つが揃えば、少なくともroute選択による大きな事故は避けられます。

## よくある質問

### GPT Image 2はCodexでしか使えませんか？

いいえ。Codexはrepo-localな画像資産作成に向いた作業フローです。直接生成や編集はImages APIを見ます。本番バックエンドで使うなら、Codexという言葉でAPI routeを置き換えないでください。

### Responsesの上位modelに`gpt-image-2`を入れてよいですか？

基本的には避けます。Responsesでは上位modelが会話や判断を担当し、画像生成は`image_generation` toolが担当します。`gpt-image-2`は画像toolまたはImages APIのmodel fieldとして扱う方が自然です。

### OpenAI API価格とCodex creditは何が違いますか？

OpenAI API価格はAPI keyでImages APIやResponsesを呼ぶときの価格です。Codex creditやplan limitはCodex作業フローで画像やファイルを生成するときの枠です。外部gateway価格はさらに別で、プロバイダー独自の契約です。

### GPT Image 2は透明背景に対応していますか？

現在は対応していません。透明背景を前提にしたUIやDocsを書く場合、GPT Image 2では利用不可として分けるか、別の対応済みルートを使う必要があります。

### 外部gatewayはいつ使うべきですか？

統一接続、ローカル決済、バックアップ経路、複数モデルrouting、チーム請求のような実務上の理由があるときです。公式OpenAI APIでアクセス、コスト、コンプライアンスが足りるなら、公式ルートの方が単純です。

### 普通のendpoint解説と何が違いますか？

普通のendpoint解説は「どのpathを呼ぶか」を答えます。GPT Image 2のroute判断では、API、Responses、Codex、providerの複数文脈に出るとき、「どのrouteがこの仕事を所有しているか」を答える必要があります。ここを間違えると、demoは動いても課金、権限、本番説明で詰まります。