フロントエンド開発者なら誰でも経験があるはずだ：ページの構造は書いた、コンポーネントも組んだ、実行して見てみる——空っぽで画像が一枚足りない。
Empty State にプレースホルダー插图が欲しい、Feature Card に小さなアイコンが欲しい、Demo ページにモックサムネイルのセットが欲しい。これまでなら、画像生成ツールに切り替えて、プロンプトを書き直して、画像をダウンロードして、ファイル名を変更して、プロジェクトディレクトリにドラッグして、コードに戻って import を修正する。1〜2回ならいいが、製品開発中に何度も繰り返すと、開発リズム全体が崩れる。
Codex は今、このステップを開発ワークフローに直接組み込めるようになった。
「絵を描いて」から「この開発アセットをプロジェクトに接続して」へ
重要な違いは、「Codex でついでに絵を描く」のではなく、「Codex に現在のプロジェクトに基づいて開発アセットを生成させ、コードへの接続を続けさせる」ことだ。
前者は単なる画像生成。後者は開発のブレイクポイントを直接パッチする。
最も実践的な使い方：Codex に視覚アセットの要件を伝えるとき、保存パス、コンポーネント接続、コード修正を一緒に交代する。プロンプトを生図リクエストとしてではなく、開発タスクとして書く。
プロジェクトに直接进入できる5つの実践例
Empty State イラスト
ページ開発の途中、Projects ページが空で画像が足りない。Codex に直接伝える：
現在のプロジェクト UI スタイルに合わせて empty state 插图を生成し、現在のページに接続してください。使用场景は Projects ページにプロジェクトがない場合の表示。画像要件：4:3、明るい背景、シンプルな SaaS UI スタイル、空のフォルダー、作成待ちプロジェクトカード、小さなプラスボタン要素を含む。可読テキストとブランドロゴは不要。
/public/images/empty-projects.pngに保存し、ProjectsEmptyState コンポーネントで参照。現在の Tailwind スタイル体系を維持。
Codex が画像を生成、ファイルを保存、コンポーネント参照を修正——1回の会話で完結。「綺麗に描く」ことが重点ではなく、ページステートを完成させることが重点だ。
Feature Card 小イラスト
Landing page の機能カードに小さなイラストが必要。寸法が明確（1:1、320px 幅カードのトップに適合）、低い視覚複雑度要件、用途が明確——これが Codex が最も得意とする场景だ。
Mock Thumbnail / Demo Content
Video Projects ページにデモ内容を埋める6枚のサムネイルが必要。Codex は統一された 16:9 サムネイルを一括生成し、指定ディレクトリに保存し、mockProjects データを更新して各プロジェクトが対応するサムネイルを参照できるようにする。ページは瞬時に「空」から「現実に近い」状態になる。
Sprite Sheet ゲームプロトタイプ
2D ダンジョンゲームのプロトタイプを作っていて、キャラクターの sprite sheet が必要。Codex に pixel art、透明背景、4 セットのアクション各 4 フレームを生成させ、sprite sheet の寸法に基づいてアニメーション設定を更新し、Player.ts で idle、walk、attack、hurt の4つのアニメーションステートを接続させる。
ゲームプロトタイプはこの用法に特に適している。Codex は「キャラクターを描く」だけではなく、sprite sheet 生成 + 設定更新 + ロジック接続を一条龙でこなす。
Status Illustration 状態図セット
タスク実行結果ページ用の6つの状態イラスト（processing、success、failed、no connection、locked、empty）が必要。生成後に StatusIllustration コンポーネントにパッケージ化し、status prop に基づいて自動的に対応する画像を選択——コンポーネントライブラリアセットになり、後の各ページで再利用可能。
いつ使う価値があるか、いつないか
使う価値がある：コードに近いほど良い。Empty State、Feature Card、Mock Thumbnail、Sprite Sheet、Status Illustration——これらは「少量の重要な開発アセット」であり、生成後に直接コンポーネントや設定ファイルに接続できる。
お勧めしない：バッチマーケティング素材（50枚の広告図、数十版の表紙試し）、ブランドメインビジュアル。これらは消費が大きく、一貫性要件も高い——API や専用のデザインワークフローを使う方が良い。
一言：製品開発内の「少量の重要なアセット」に使え。ギャラリーが欲しいのではなく、ページがより速く完成し、デモがより速く走り、コンポーネントがより速く使えるようになることが欲しいのだ。
公開前の4つのチェック
画像が生成されたからといって blindly に公開してはいけない。最低限4つをチェック：
- 誤ったテキストがないか
- 実際のブランド、商標、ロゴがないか
- 複数の画像間でスタイルが一貫しているか
- 製品のブランドおよび著作権要件に適合しているか
一人で製品を作る開発者は今、Codex 内でこれらの開発ブレイクポイントを直接パッチできる。ツール切り替え不要、待ち時間不要、コンテキスト喪失不要——これがCodexが真正に前に進んだ一歩だ。