Codexに画像を頼んだのに、なぜかSVGを変換したような、のっぺりした絵が返ってくる。
写真やイラストを期待していたのに、出てきたのは単純な図形の集まり。
「Codexの画像生成って、この程度なの？」
私も最初はそう思いました。
そして、原因は「アイコン」「ロゴ」という言葉を使ったからだと考えました。Codexが画像生成ではなく、SVGやHTML、CSSで描く経路を選んだのではないか、と。
そこで今回、実際にCodexを動かして確かめました。
Claude CodeからCodexを呼び、次のBefore／Afterを比べました。
- Before：「シンプルな猫のアイコンを作って」とだけ依頼
- After：画像生成ツール、題材、色、質感、禁止事項、保存先まで指定
結果は、最初に感じた違和感どおりでした。
短い依頼で返ってきたのは、拡張子こそPNGですが、実際にはSVGをラスター化した平面的な猫のアイコンでした。
一方、画像生成ツールと完成条件を明示した依頼では、マイクを持つ猫、青い丸フレーム、黄色の背景、星と丸ボケまで反映された、情報量のある1枚絵が生成されました。
つまり、今回の検証で分かったのは、次のことでした。
欲しい題材だけでなく、画像生成モデルを使うこと、SVGで代替しないこと、色や質感まで伝えると、Codexの作り方そのものを変えられる。
この記事では、OpenAIの公式情報と、2026年7月13日に行った実測結果をもとに、Codexで狙った画像を作る方法を整理します。
先に結論
最初に要点をまとめます。
- Codexは、写真やイラストを生成することも、SVGやHTML、CSSでビジュアルを作ることもできる
- 拡張子がPNGでも、中身はSVGを変換した画像である場合がある
- 写真やイラストが欲しいときは、プロンプトに$imagegenを入れると画像生成スキルを明示的に呼べる
- 品質の差を生むのは、プロンプトの長さより「用途・主役・スタイル・構図・制約」
- 詳細な指定の価値は、見た目を豪華にすることより、用途に合った構図を再現しやすくすること
- 一度で完璧を狙わず、変える場所と変えない場所を指定して1要素ずつ直す
最短で試すなら、依頼文の先頭に次の一文を足してください。
──────── コピペ用 ────────
\$imagegen\を使って、画像生成モデルでラスター画像として生成してください。SVG、HTML、CSS、canvasでは代替しないでください。
──────────────────────
ただし、本当に効くのはこの一文だけではありません。
「何に使う画像か」「どこまで入れば合格か」まで伝えることで、Codexは初めて、あなたと同じ基準で画像を確認できます。
そもそも、なぜ画像ではなくSVGが出るのか
Codexは画像生成専用のサービスではありません。
コードを書き、既存ファイルを読み、Webサイトを修正し、必要ならSVG、HTML、CSS、canvasも扱います。
これは大きな強みです。
たとえば、Webサイトに既存のSVGアイコンセットがあり、そこへ同じ線幅、同じ色、同じサイズのアイコンを1つ追加したいとします。この場合、画像生成モデルでPNGを作るより、既存SVGを編集したほうが正確です。
一方、記事の見出し画像、写真風のビジュアル、質感のあるキャラクター、広告バナーなどは、コードより画像生成が向いています。
現在のCodexのimagegenスキルも、この2つを分けています。
- 写真、イラスト、テクスチャ、スプライト、モックアップなど、ビットマップ画像が向く仕事では画像生成を使う
- 既存のSVG、ベクター、コード資産を編集するほうがよい仕事では、そちらを優先する
重要なのは、「アイコン」「ロゴ」という単語だけで機械的に決まるわけではないことです。
同じアイコンでも、用途は2種類あります。
- UIで使う、拡大縮小可能なベクター部品
- SNSで使う、質感や陰影のある装飾的な1枚絵
依頼が曖昧だと、Codexはプロジェクト内の既存ファイルや前後の文脈から、どちらを求めているか推測します。
その推測がこちらの意図とずれたとき、「写真が欲しかったのにSVGのようなものが出た」という現象が起きます。
したがって、問題の本質は「アイコンという言葉が禁止」ではありません。
欲しい成果物の形式が、Codexに伝わっていないことです。
公式情報で確認できること
Codexの画像生成では、似た名前が3つ出てきますが、意味は別です。
- $imagegen：Codexの画像生成スキルを明示的に呼び出す名前
- image_gen：Codexに組み込まれた画像生成ツールの名前
- gpt-image-2：APIやフォールバックCLIでモデルを直接指定するときのモデルID
- 「Image 2.0」「GPT Image 2相当」：品質のイメージを伝える呼び方で、実行時の正式なモデルIDではない
通常の画像生成では、$imagegenでスキルを呼び、組み込みのimage_genツールを使うのが基本です。この経路では、別途OPENAI_API_KEYを用意する必要はありません。
gpt-image-2をモデルIDとして直接指定するのは、APIまたはフォールバックCLIを明示的に使う場合です。この経路ではOPENAI_API_KEYが必要になります。
そのほか、効果的な画像プロンプトには次の原則があります。
- 効果的なプロンプトでは、用途、主役、背景、構図、スタイル、制約を具体的に伝える
- 抽象的な「きれいに」「おしゃれに」より、光の方向や配置を具体的に書く
- 修正するときは、1要素ずつ変え、維持したい条件を繰り返す
- 画像内の文字は引用符で囲み、書体、色、サイズ、配置を指定する
ここから分かるのは、$imagegenは公式に用意された明示的な呼び出し方だということです。
「絶対に付けなければ画像を作れない」という意味ではありません。ただし今回のBeforeでは、画像生成ではなくSVGを作る経路が選ばれました。
役割は、自動判定に任せず、画像生成を使う意図を明確にすることです。
実際のBefore／After
ここからは実測です。
Claude CodeからCodexを呼び出して生成しました。呼び出し先のCodex CLIはバージョン0.144.1で、ChatGPTアカウントにログインし、APIキーを追加せずに実行しています。
先に断っておくと、これは1つの条件だけを変えた厳密な比較実験ではありません。
Beforeでは、作りたいものだけを短く伝えました。Afterでは、生成ツール、保存形式、題材、色、構図、禁止事項、品質まで指定しています。
つまりこれは、実際に失敗を経験したあと、依頼文をどこまで具体化すると結果が変わるかを見たBefore／Afterです。
Before：「シンプルな猫」だけを頼む
最初にClaude Codeへ送った依頼は、これだけでした。
──────── コピペ用 ────────
シンプルな猫のアイコンを作って
──────────────────────
画像生成モデル、PNG、SVG、色、質感、背景、保存先は指定していません。
そして返ってきたのが、こちらです。
ファイルを調べると、次の結果でした。
- ファイル名：cat-icon.png
- 形式：PNG、RGBA
- サイズ：1024×1024ピクセル
- 色深度：16ビット
- ファイル容量：約121KB
- 見た目：単純な図形を重ねた、平面的な茶トラ猫の顔
薄い黄色の丸い背景に、猫の顔を大きく置いた構図です。表情はかわいく、「シンプルな猫のアイコン」という依頼には沿っています。
つまり、Codexが指示を無視したわけではありません。
むしろ問題は、依頼が短すぎて、こちらが期待していた「画像生成モデルによる、質感のある完成イラスト」が伝わっていなかったことです。
同じフォルダにはcat-icon.svgも作られていました。さらにPNGのメタデータには、svg:titleとして「かわいい茶トラ猫の顔アイコン」、svg:commentとして「背景」「耳」「顔」「目」「首輪」など、SVGの構成要素が残っています。
つまりCodexは、「シンプルなアイコン」をベクター素材の依頼だと解釈し、SVGを作ってPNGへ変換していました。
Beforeは失敗というより、指示どおりすぎた。
こちらが「シンプル」としか伝えなかったため、Codexは編集しやすい単純な図形でシンプルに作ったのです。
After：生成方法と完成イメージを固定する
そこで次は、Claude CodeからCodexを次の内容で呼び出しました。
──────── コピペ用 ────────
mkdir -p ./images
codex exec -C "$(pwd)" -s workspace-write --skip-git-repo-check \
"画像生成ツール（image_gen / gpt-image-2）を使って、マイクを持った可愛い猫のイラストをPNGで生成し ./images/cat-mic.png に保存して。フラットで可愛い塗り、やわらかい陰影とハイライト、青い丸フレーム、背景は #FDE68A に小さな星と丸ボケ、差し色 #2563EB、猫はクリーム〜オレンジ系。1枚のイラストとして作り、SVGやHTML/CSSでの代替はしないこと。文字やウォーターマークは入れない。品質はhigh。"
──────────────────────
これは実際に使ったコマンドです。ただし、image_genとgpt-image-2は同じものの別名ではありません。
通常のCodex内蔵機能を使う前提なら、現在おすすめする書き方は次です。
──────── コピペ用 ────────
mkdir -p ./images
codex exec -C "$(pwd)" -s workspace-write --skip-git-repo-check \
'$imagegenを使い、組み込みのimage_genツールで、マイクを持った可愛い猫のイラストをPNGとして生成して。フラットで可愛い塗り、やわらかい陰影とハイライト、青い丸フレーム、背景は #FDE68A に小さな星と丸ボケ、差し色 #2563EB、猫はクリーム〜オレンジ系。SVGやHTML/CSSでは代替しない。文字やウォーターマークは入れない。完成後、生成画像を ./images/cat-mic.png に保存して。高品質で仕上げて。'
──────────────────────
プロンプト全体をシングルクォートで囲んでいるのは、$imagegenの$をシェルの変数として展開させず、そのままCodexへ渡すためです。
Beforeとの違いは、単に文章が長いことではありません。
- 画像生成ツールを明示する
- PNGで保存する
- SVGやHTML/CSSで代替しない
- 主役はマイクを持った猫
- フラットでかわいい塗りに、柔らかな陰影とハイライトを加える
- 青い丸フレームを入れる
- 背景色を#FDE68Aにする
- 星と丸ボケを入れる
- 差し色を#2563EBにする
- 猫をクリームからオレンジ系にする
- 文字とウォーターマークを入れない
- 品質をhighにする
- 保存先を./images/cat-mic.pngに固定する
生成された画像がこちらです。
実ファイルは次のとおりでした。
- ファイル名：cat-mic.png
- 生成経路：Codex内蔵の画像生成ツール
- 形式：PNG、RGB
- サイズ：1254×1254ピクセル
- 色深度：8ビット
- ファイル容量：約1.74MB
画像には、クリームからオレンジ系の猫がマイクを持つ姿、青い丸フレーム、黄色の背景、青い星、丸ボケが反映されています。
毛やマイクには柔らかな陰影とハイライトがあり、単色の図形を並べたBeforeよりも、1枚の完成イラストとしての情報量が増えました。文字やウォーターマークも入っていません。
2つの結果を比較して分かったこと
同じPNGでも、中身はまったく違う
BeforeもAfterも拡張子は.pngです。
しかし、BeforeはSVGをPNGへ変換した画像。Afterは画像生成ツールが直接作ったラスター画像でした。
「PNGで納品された」だけでは、期待した生成方法かどうかは判断できません。
Beforeの結果は、プロンプトに対しては正しい
Beforeで頼んだのは「シンプルな猫のアイコン」です。
実際に出たものも、シンプルな猫のアイコンでした。Codexの能力が低かったというより、こちらの言葉が完成イメージを限定していなかったのです。
Afterは、生成経路まで指示した
Afterで効いたのは、「もっときれいにして」という感覚的な注文ではありません。
画像生成ツールを使うこと、SVGで代替しないこと、色、主役、背景、質感、保存先を明示したことです。
画質差をimage_genだけの効果とは断定できない
Afterでは、生成ツールだけでなく、題材や配色、陰影、背景、品質も同時に変えています。
そのため、見た目の改善をimage_genという一語だけの効果とは切り分けられません。
ただし、少なくとも「SVGを作ってPNGへ変換する経路」を避け、画像生成モデルへ進ませる意図は明確になりました。
欲しい絵だけでなく、どう作ってほしいかまで伝える。
これが、今回のBefore／Afterから得られた一番大きな教訓です。
$imagegenは何のために付けるのか
ここまでの結果を見ると、「付けなくてもPNGが出たなら、$imagegenは不要では？」と思うかもしれません。
確かに、写真やイラストだと明らかな依頼なら、Codexが自動で画像生成を選ぶことがあります。
それでも明示する意味は3つあります。
1．経路の取り違えを減らす
既存のSVGやUI資産が多いプロジェクトでは、Codexがコード編集を適切と判断する可能性があります。
1枚絵が必要なら、画像生成を明示することで意図のずれを減らせます。
2．チームで頼み方をそろえられる
人によって「画像」「アイコン」「バナー」の意味が違うと、成果物もばらつきます。
$imagegenと用途を共通ルールにすれば、依頼する人が変わっても同じ経路を選びやすくなります。
3．失敗原因を切り分けやすい
画像生成を明示したのに結果が悪いなら、次に見るべきは構図、スタイル、制約です。
経路が不明なままだと、「画像生成モデルが悪いのか」「SVGで作ったのか」「プロンプトが曖昧なのか」が分かりません。
$imagegenは、画質を上げる呪文というより、実行方法を固定するスイッチだと考えると分かりやすいです。
最短で使えるプロンプト
まずは次の形をコピペしてください。
──────── コピペ用 ────────
\$imagegen\を使って、画像生成モデルで次の画像を作ってください。SVG、HTML、CSS、canvasでは代替せず、1枚のラスター画像として生成してください。
用途：Xのプロフィール画像
主役：マイクを持った猫
スタイル：親しみやすく、立体感のある3Dイラスト
構図：正方形、中央配置、丸く切り抜いても主役が欠けない
制約：文字、ロゴ、ウォーターマークを入れない
──────────────────────
全部を細かく書く必要はありません。
OpenAIの公式ガイドでも、画像プロンプトは1〜3文程度の明確な文章で十分な場合が多いと説明されています。
重要なのは、長さではなく、成功を左右する条件が入っていることです。
画像の質を安定させる5項目
プロンプトに迷ったら、次の5つだけ書きます。
1．用途
どこで使う画像かを書きます。
例：Xの投稿、プロフィール画像、ブログの見出し、LPのヒーロー、商品紹介
用途を書くと、Codexは必要な構図や余白を判断しやすくなります。
2．主役
何を、どんな状態で描くかを書きます。
例：マイクを持った茶トラ猫、ノートPCで作業する女性、机に置かれたコーヒー
3．スタイル
写真、イラスト、3Dなど、欲しい質感を指定します。
例：自然光のリアルな写真、雑誌風の編集イラスト、柔らかい水彩、立体感のある3D
4．構図
縦横比、主役の位置、必要な余白を書きます。
例：横長、人物は左、右側に見出し用の余白を残す
今回のAfterでは、「青い丸フレーム」という指定によって、猫とマイクを円の中へ収めた構図になりました。
5．制約
入れてほしくないものと、守るべき条件を書きます。
例：文字なし、ロゴなし、ウォーターマークなし、背景を複雑にしない
この5項目があれば、Codexは「絵を作る」だけでなく、「用途に合うか」を確認できます。
用途別のコピペ例
記事のヘッダー画像
──────── コピペ用 ────────
\$imagegen\を使って、ブログ記事の横長ヘッダー画像を生成してください。木製デスクに置かれたノートPCとコーヒーを、朝の柔らかい自然光で撮影したリアルな写真にしてください。主役は左寄せにし、右側には見出しを置ける広い余白を残してください。文字、ロゴ、ウォーターマークは入れないでください。SVG、HTML、CSSでは代替しないでください。
──────────────────────
「おしゃれに」ではなく、「朝の柔らかい自然光」「右側に余白」と具体的に書くのがポイントです。
X投稿用の正方形画像
──────── コピペ用 ────────
\$imagegen\を使って、X投稿用の正方形イラストを生成してください。AIと人が同じ机で協力して企画を考えている様子を、親しみやすい編集イラストで表現してください。人物とAI端末を中央に置き、スマートフォンのタイムラインで見ても主題が分かる構図にしてください。青とオレンジを基調にし、文字、ロゴ、ウォーターマークは入れないでください。
──────────────────────
LPのヒーロー画像
──────── コピペ用 ────────
\$imagegen\を使って、オンライン業務ツールのLP用ヒーロー画像を生成してください。明るいオフィスで、少人数のチームが大きな画面を見ながら話している自然な写真にしてください。横長で人物は右寄せ、左側に見出しとボタンを置ける余白を残してください。過度に未来的な表現、文字、企業ロゴ、ウォーターマークは入れないでください。
──────────────────────
日本語を入れる画像
──────── コピペ用 ────────
\$imagegen\を使って、X投稿用の正方形画像を生成してください。中央上部に「AIで仕事が変わる」の文字だけを、大きく太い白色のゴシック体で入れてください。文字は1行、中央揃え。ほかの文字、ロゴ、ウォーターマークは追加しないでください。背景は濃い青から紫へのグラデーションで、ビジネス向けの落ち着いたデザインにしてください。
──────────────────────
画像内に文字を入れる場合は、次の3点を守ります。
- 表示したい文字を引用符で囲む
- 書体、色、大きさ、位置を指定する
- ほかの文字を追加しないよう伝える
生成後は、公開前に一字ずつ確認してください。
修正するときは「変えるもの」と「残すもの」を書く
最初の画像が惜しかったとき、プロンプトを最初から全部書き直す必要はありません。
むしろ、一度に多くを変えると、気に入っていた部分まで変わります。
修正は1要素ずつ行います。
- 構図はそのままで、背景だけ明るくする
- 人物と机は変えず、マグカップだけ観葉植物に置き換える
- 色と光は維持し、右側の余白だけ広げる
- 猫の表情と毛色は変えず、マイクを少し小さくする
OpenAIの公式ガイドでも、編集時には「何を変えるか」と「何を維持するか」を明確にすることが推奨されています。
使える形はこれです。
──────── コピペ用 ────────
添付画像を編集してください。変更するのは背景だけです。背景を明るいグレーにしてください。人物、服装、表情、構図、光、色味はすべてそのまま維持してください。文字やロゴは追加しないでください。
──────────────────────
「ここだけ変える。ほかは触らない」と書くことで、画像全体のドリフトを減らせます。
毎回書くのが面倒なら、ルールを固定する
Claude CodeからCodexを呼ぶ場合、同じ注意書きを毎回入力するのは面倒です。
この運用では、まずプロジェクトのCLAUDE.mdに画像生成ルールを置くのがおすすめです。CLAUDE.mdを読むのはClaude Codeなので、「画像を頼まれたらCodexへどう依頼するか」をここで固定します。
Codexを直接使うプロジェクトなら、同じ考え方をAGENTS.mdに置きます。AGENTS.mdはCodex側が読むプロジェクトルールです。
──────── コピペ用 ────────
画像生成ルール
- 写真、イラスト、バナー、ヒーロー画像、SNS投稿画像を作るときは、\
$imagegen\を使う。 - ラスター画像を求められた場合は、SVG、HTML、CSS、canvasで代替しない。
- 生成前に、用途、主役、スタイル、構図、制約を整理する。
- 既存のSVGアイコンセットへ追加する場合だけ、既存形式に合わせてSVGを編集する。
- 完成した画像はプロジェクト内へ保存し、保存場所を報告する。 ──────────────────────
このルールの目的は、常にSVGを禁止することではありません。
UI部品にはSVG、完成した1枚絵には画像生成と、用途に合わせて選ぶことです。
Skillにする必要はある？
画像を生成するためだけに、新しいSkillを作る必要はありません。Codexには、すでにimagegenスキルがあります。
独自Skillを作る価値が出るのは、複数のプロジェクトで次のような手順まで共通化したい場合です。
- ブランドカラーや画風を毎回適用する
- X用、記事用、LP用など、用途別の構図を自動で選ぶ
- 生成後に文字、余白、サイズ、禁止事項を確認する
- ファイル名と保存先を統一する
- 不合格なら、同じ基準で修正をかける
判断はシンプルです。
- 1つのプロジェクトで使うルール：CLAUDE.md
- Codexへ直接守らせるプロジェクトルール：AGENTS.md
- 複数プロジェクトで「生成→確認→保存」まで再利用する仕組み：独自Skill
最初からSkillを作り込む必要はありません。まずCLAUDE.mdで運用し、同じ手順を3回以上繰り返すようになったらSkill化を検討するくらいで十分です。
SVGのほうが正解な場面
ここまで画像生成の呼び出し方を説明しましたが、SVG自体が悪いわけではありません。
次の用途では、SVGのほうが適しています。
- 既存のUIアイコンセットに新しいアイコンを追加する
- 拡大縮小しても線を鮮明に保ちたい
- CSSで色を変更したい
- 形や線幅を数値で正確に管理したい
- コードとして差分レビューしたい
反対に、画像生成が向くのはこちらです。
- 写真風のビジュアル
- 毛並み、布、金属などの質感が必要なイラスト
- 広告や記事のアイキャッチ
- キャラクターや物語性のある1枚絵
- 雰囲気や感情を伝えるビジュアル
判断基準は、「SVGかPNGか」ではありません。
決定論的に管理したい部品か、表現力を優先する1枚絵か。
ここを決めてからCodexへ頼むと、経路のミスマッチを減らせます。
今回の検証で修正した3つの思い込み
最後に、実際に試したからこそ修正できた点をまとめます。
思い込み1：PNGなら画像生成モデルで作られている
今回の初回画像はPNGでしたが、メタデータにはSVGのタイトルや構成要素が残っていました。
見た目も単純な図形の組み合わせで、SVGをPNGへ変換した画像だと判断できます。
確認すべきなのは拡張子だけではありません。どの経路で作られたかと、実際の見た目です。
思い込み2：$imagegenを付ければ画質が上がる
今回のAfterは、Beforeより明らかに情報量のある見た目になりました。
ただし、同時にマイク、配色、陰影、背景、構図、品質まで指定しています。画像生成ツールを明示することは生成経路を固定しますが、それだけで好みの仕上がりになるわけではありません。
見た目を決める条件と、用途に合っているかを判断する合格条件も必要です。
思い込み3：プロンプトは長いほど良い
Afterが良くなった理由は、文字数が増えたからではありません。
画像生成ツール、SVG禁止、主役、配色、背景、質感、保存先という、結果を左右する条件が入ったからです。
長さではなく、判断に必要な条件を書く。
まとめ
Codexで簡素な画像が返ってきたとき、最初に疑うべきは画像生成モデルの性能ではありません。
欲しいものが、コードで使うベクター部品なのか、写真やイラストとして完成した1枚絵なのか。その意図が伝わっているかを確認してください。
1枚絵が欲しいなら、まず次の一文を足します。
──────── コピペ用 ────────
\$imagegen\を使って、画像生成モデルでラスター画像として生成してください。SVG、HTML、CSS、canvasでは代替しないでください。
──────────────────────
そのうえで、用途、主役、スタイル、構図、制約を書く。
今回の実測では、Claude Codeから「シンプルな猫のアイコン」とだけ頼むと、Codexはそれをベクター素材の依頼と解釈し、SVG由来の平面的なPNGを作りました。
一方、$imagegenで画像生成スキルを呼び、組み込みのimage_genツールを使うこと、SVGで代替しないこと、題材、配色、質感、背景、品質を明示すると、指定を反映した完成イラストを作りやすくなります。
画像の品質を決めるのは、プロンプトの長さではありません。
何を作るかだけでなく、何に使い、どの状態なら合格なのかを共有できているか。
ここまで伝えると、Codexは単なる画像生成機ではなく、用途に合わせて画像を作り、確認する制作パートナーになります。
まずは、いつもの画像依頼に「用途」と「合格条件」を1つずつ足してみてください。
それだけでも、偶然の当たりを待つ画像生成から、意図した結果を再現する画像制作へ近づけます。
参考：
