「CodexにUIを任せると見た目が崩れる」と感じているなら、画像生成と実装を分ける二段階ワークフローが有効です。

2026年7月、OpenAIでOpenClawを手がけるPeter Steinberger氏が、内部プロジェクトで試した結果をXに投稿しました。「Codexがデザイン苦手だと思うなら、imagegenでこのデザインをre-imagineさせてから実装させろ」という一文が、AI開発者の間で話題になりました（参考）。

この記事では、Steinberger氏の提案を軸に、Codex公式のimagegenスキルとOpenAIドキュメントが示す手順を整理します。

この記事でわかること

  • CodexのUI実装がうまくいかない典型的な原因
  • imagegenでデザインを再想像してから実装する二段階ワークフロー
  • 公式ドキュメントが推奨する画像の渡し方
  • 実際に試した開発者の所感と注意点

テキストだけの指示ではCodexのUIは伸びにくい

CodexはOpenAIが提供するコーディングエージェントで、ローカルCLIやIDE拡張、デスクトップアプリから利用できます。コード生成やリファクタリングは得意ですが、「もっとモダンに」「余白を広げて」といった曖昧なデザイン指示だけでは、期待した見た目に届きにくい場面があります。

Steinberger氏の投稿でも、Codexは「taste（センス）を発明する」のが苦手で、コピー元があれば実装は問題ない、という反応が寄せられています。つまり課題は実装力そのものではなく、視覚的なゴールが言葉だけで伝わっていない点にあります。

解決策は「再想像→実装」の二段階ワークフロー

Steinberger氏が提案する手順はシンプルです。まずimagegenで既存デザインをより良い形に再想像した画像を作り、次にその画像を参照させながら実装させます。

AI図解を手がけるテツメモ氏が同投稿を紹介し、具体的な指示例を整理しています（参考）。

  1. Codexに「imagegenツールで今のデザインをより良く再想像した画像を生成しろ」と指示する
  2. 生成された画像を参照させ、「これを実装しろ」と続ける

デザインの創造性は画像生成に任せ、レイアウトやコンポーネントへの落とし込みはCodexに任せる、という分業です。テツメモ氏は自身のポートフォリオサイトで試し、改善案の画像が出てきたと報告しています。

imagegenスキルとGPT-Image-2の位置づけ

https://developers.openai.com/codex/use-cases/idea-to-proof-of-concept

Codexに公式搭載されているimagegenは、ビルトインのimage_genツールを使うスキルです。OpenAIの公式ユースケースでは、画像生成モデルとしてGPT Image 2がUIモックアップの生成に適していると説明されています（参考）。

GitHub上のimagegenスキル定義では、ウェブアセット、UIモックアップ、ワイヤーフレーム、プロダクトモックアップなどのラスター画像生成が対象とされています。通常はビルトインのimage_genツールが優先され、APIキーなしで動作します（参考）。

SVGや既存のベクターアイコンを拡張する作業には向きません。HTMLやCSSで直接作れる単純な図形より、完成したビジュアルイメージを先に固めたい場面で力を発揮します。

公式が推奨する「新しいターンで画像を渡す」コツ

OpenAIの公式ドキュメントにも、同じ考え方が書かれています。ImageGenでUIの方向性を固めたあと、実装に移るときは会話をそのまま続けず、採用した最終画像を新しいターンで添付し直すことが推奨されています（参考）。

理由は明確です。Codexはユーザーが添付した画像を参照できる状態のほうが、実装精度が上がるためです。ユーザーストーリーからUIモックを作るユースケースでも、「最終的に実装したいモック画像を新しいターンで再添付する」と明記されています。

Webアプリの場合はBuild Web Appsプラグインを併用すると、デザイン生成からコード実装、ブラウザでの見た目比較までを一連の流れで進められます。概念実証を素早く作るユースケースでも、まずビジュアル方向を決めてからプロトタイプを組む流れが推奨されています。

実務での進め方

既存サイトの改善から始めるなら、現行画面のスクリーンショットをCodexに渡し、imagegenで「情報設計は維持しつつ、タイポグラフィと余白を洗練させた案を3つ」と依頼するのが現実的です。案が固まったら、採用した1枚だけを新ターンで添付し、「この画像に忠実にHTML/CSSで実装して」と指示します。

新規画面なら、ユーザーの課題と画面に載せる要素を文章で整理したうえで、imagegenにモックを作らせます。OpenAIドキュメントは、変更範囲を狭くするほど、そのまま実装に落とし込みやすいと述べています。大きな画面全体より、ヘッダーやカード単位などスコープを切ったほうが成功率は上がります。

実装後の確認には、Playwrightスキルでブラウザを開き、レンダリング結果を参照画像と比較する方法も公式に案内されています。見た目のズレをCodex自身に検出させ、差分だけ直させるループに入れられます。

うまくいかないときの見方

Steinberger氏の投稿への返信では、「24時間走らせても期待外れだった」「imagegenは良いがCodexの実装がまだ弱い」といった声もあります。ワークフローは万能ではなく、参照画像の解像度、指示の具体性、既存コードベースとの整合性が結果を左右します。

特にデザインシステムやコンポーネントライブラリが既にあるプロジェクトでは、生成画像が既存トークンと乖離しやすいです。その場合はスクリーンショットやFigmaファイルを参照として渡し、情報設計とデザイン制約を守るよう明示すると、OpenAI公式のUIモック作成ガイドと同じ方向に寄せられます。

それでも実装が崩れるときは、画面をセクション単位に分割し、ヘッダー、ヒーロー、フッターなどを個別に画像化して順に実装する方法が有効です。一度に全体を渡すより、Codexが追従しやすくなります。

画像を先に作る発想がCodex UIの鍵

CodexのUI実装を改善する核心は、言葉でセンスを説明するのをやめ、GPT-Image-2によるimagegenで視覚的な正解を先に作ることです。Steinberger氏の一文は短いですが、OpenAI公式の「ビジュアル方向から始める」「最終画像を新ターンで添付する」という設計思想と一致しています。

Codexでフロントエンドを触っているなら、次のUI改善から「re-imagineしてから実装」の二段階を試す価値があります。デザインの発想は画像生成に、コードへの落とし込みはCodexに任せる分業が、いま最も再現性の高いやり方です。