ターミナルのコマンド操作から鮮やかな生成画像が立ち上がる様子を描いた、CLIベースの画像生成をイメージしたテックビジュアル

Article

Codex Exec から画像生成できた。しかも今は gpt-image-2 が熱い

2026年4月22日
5 min read
#Codex#OpenAI#画像生成#gpt-image-2#CLI

codex exec というと「CLI からコードを書かせる道具」という印象が強い。でも実際に触ってみると、画像生成も普通にいける

しかも、ここが今かなり面白い。

OpenAI の API ドキュメント側では、画像モデルとして gpt-image-2 が見えている。さらに snapshot 名として gpt-image-2-2026-04-21 も出ていて、名前の通りほぼ出たてだ。2026-04-22 時点でこれがもう実際に触れるのは、かなりいい。

要するに、Codex Exec から画像を出せるだけでも便利なのに、その裏側でいま一番新しい画像モデルの気配が見えているのが今回の肝だ。

まず結論

手元で一番分かりやすく通ったのはこの形。

codex exec --skip-git-repo-check --sandbox workspace-write \
  '1024x1024 のPNG画像を1枚生成。内容は「白背景の上に、正面を向いた黒い猫のフラットなアイコン」。生成できた画像をカレントディレクトリに cat-icon.png として保存してください。成功したら最後に保存先パスだけを答えてください。'

ポイントは --sandbox workspace-write を付けること。これがないと、画像生成自体は成功しても保存だけ失敗することがある。

何が新しいのか: gpt-image-2 がもう見えている

今回いちばん書いておきたかったのはここ。

OpenAI の画像生成ガイドでは、最新モデルとして gpt-image-2 が案内されていた。モデル一覧側でも、alias の gpt-image-2 に加えて gpt-image-2-2026-04-21 という snapshot が見えている。

これ、かなり重要だと思う。

なぜなら、単に「画像生成できます」だけなら前から話はあった。でも今回は、発表されたばかりの新しい画像モデルが、もう API と実運用の導線に乗り始めているのが分かるからだ。

CLI ツール経由だと裏側のモデル選択はやや抽象化されることが多いが、少なくとも今の OpenAI 側の公開情報を見る限り、「いま触る画像生成」の本命は gpt-image-2 と見てよさそう。

このスピード感は、正直かなり良い。

Codex Exec で画像生成する時の実用メモ

1. まずは書き込み可能サンドボックスにする

一番ありがちなハマりどころはこれ。

画像そのものは生成できていても、保存先に書けないと最後に失敗する。なので、常用するならこれが無難。

codex exec --skip-git-repo-check --sandbox workspace-write '...'

強権で雑に試すなら --dangerously-bypass-approvals-and-sandbox もあるが、これは名前の通り強い。日常運用なら workspace-write の方が筋がいい。

2. -i は可変長なので雑に書くと事故る

入力画像を添付して編集したい時、-i の直後は可変長でファイルを食べる。なので、こういう書き方は危ない。

codex exec -i ref1.png ref2.png 'プロンプト'

この形だとプロンプト側の解釈が崩れて、No prompt provided via stdin. みたいな顔をされることがある。

安全なのは次のどちらか。

codex exec --skip-git-repo-check --sandbox workspace-write \
  '添付画像を参考に、白背景の黒猫アイコンを1枚生成して cat-icon.png として保存してください。' \
  -i ref1.png ref2.png
codex exec --skip-git-repo-check --sandbox workspace-write \
  -i ref1.png ref2.png -- \
  '添付画像を参考に、白背景の黒猫アイコンを1枚生成して cat-icon.png として保存してください。'

CLI はこういう細かい罠がある。ここは覚えておくとだいぶ平和。

3. 画像は一度別の場所に吐かれることがある

挙動としては、生成画像がいったん ~/.codex/generated_images/... に出て、その後で指定した保存先へコピーまたは移動されることがある。

だから切り分けは次の順番でやると早い。

  1. 画像生成自体に失敗したのか
  2. ~/.codex/generated_images/... に生成物があるか
  3. 最終保存先に書き込み権限があるか

この構造が分かっていると、「モデルが失敗した」のか「保存だけ失敗した」のかを見誤りにくい。

編集系のユースケースも普通に相性がいい

画像生成だけでなく、簡単な編集もやりやすい。

例えば背景透過ならこんな感じ。

codex exec --skip-git-repo-check --sandbox workspace-write \
  -i input.png -- \
  '添付画像を編集して、被写体はそのままに背景だけ透明にしてください。最終結果をカレントディレクトリに output.png として保存してください。'

README 用のラフ画像、説明図、仮アイコン、ちょっとした素材の整形あたりはかなり相性がいい。

これ、どこで効くのか

僕がいいと思ったのは、「画像生成をメインの作業にしない場面」で強いこと。

たとえば:

  • README や docs 用の仮アイコンをその場で出す
  • 記事の説明図のたたき台を作る
  • 既存画像の背景除去や簡単な編集をする
  • ブログや告知用のビジュアルを、コマンドラインから流れで用意する

要は、わざわざ別の UI に移動しなくていい。コードを書く流れの中で、そのまま画像も作れるのが気持ちいい。

まとめ

codex exec から画像生成できる、というだけでも十分便利だった。

でも今のタイミングで本当に面白いのは、OpenAI の新しい画像モデル gpt-image-2 が、もう見えていて、しかもかなり新しい snapshot と一緒に出てきていることだ。

ここは少し強めに言っていいと思う。

「Codex から画像も出せる」ではなく、
「Codex の流れで、発表されたばかりの新しい画像モデルの波にそのまま乗れる」

この感触は、かなりいい。

しばらくは README 用素材や記事用のラフ画像で、まず実戦投入していくのがいちばん楽しそうだ。