画像生成スキル

画像生成スキル は何をしますか？

現在のプロジェクト向けに画像を生成または編集します（例：Webサイトアセット、ゲームアセット、UIモックアップ、製品モックアップ、ワイヤーフレーム、ロゴデザイン、フォトリアリスティック画像、インフォグラフィック）。

トップレベルのモードとルール

このスキルには正確に2つのトップレベルモードがあります。

• デフォルトのビルトインツールモード（推奨）： 画像生成、編集、透明画像リクエスト用のビルトインimage_genツール。OPENAI_API_KEYは不要です。
• フォールバックCLIモード： scripts/image_gen.py CLI。ユーザーが明示的にCLI/API/モデルパスを要求または確認した場合に使用します。OPENAI_API_KEYが必要です。

CLIフォールバック内では、CLIは3つのサブコマンドを公開します。

• generate
• edit
• generate-batch

ルール：

• 通常の画像生成および編集リクエストには、デフォルトでビルトインのimage_genツールを使用します。
• 通常の品質、サイズ、ファイルパス制御のためにCLIフォールバックに切り替えないでください。
• 透明画像の場合、ビルトインのimage_genに透明な背景を依頼し、生成されたアルファを保持します。
• ビルトインimage_genまたはCLI gpt-image-2からCLI gpt-image-1.5に黙って切り替えないでください。ユーザーが明示的にgpt-image-1.5を要求した場合を除き、最初にユーザーに確認してください。
• batchという単語だけではCLIフォールバックを意味しません。ユーザーが多くのアセットを要求したり、CLI/API/モデル制御を明示的に要求せずにアセットをバッチ生成するように言った場合は、ビルトインパスに留まり、要求されたアセットまたはバリアントごとに1回のビルトイン呼び出しを発行します。
• ビルトインツールが失敗するか利用できない場合は、CLIフォールバックが存在し、OPENAI_API_KEYが必要であることをユーザーに伝えます。ユーザーが明示的にフォールバックを要求した場合にのみ続行します。
• ユーザーが明示的にCLIモードを要求した場合は、バンドルされているscripts/image_gen.pyワークフローを使用します。単発のSDKランナーを作成しないでください。
• scripts/image_gen.pyを決して変更しないでください。何か不足している場合は、他のことをする前にユーザーに確認してください。

ビルトインの保存パスポリシー：

• ビルトインツールモードでは、Codexはデフォルトで生成された画像を$CODEX_HOME/*の下に保存します。
• OSの一時ディレクトリをデフォルトのビルトイン保存先として説明したり、依存したりしないでください。
• ビルトインのimage_genツールの保存先パス引数（ある場合）を説明したり、依存したりしないでください。特定の場所が必要な場合は、最初に生成してから、選択した出力を$CODEX_HOME/generated_images/...から移動またはコピーします。
• ビルトインモードでの保存パスの優先順位：
  1. ユーザーが保存先を指定した場合は、選択した出力をそこに移動またはコピーします。
  2. 画像が現在のプロジェクト用である場合は、最終的な選択画像をワークスペースに移動またはコピーしてから終了します。
  3. 画像がプレビューまたはブレインストーミング用のみの場合は、インラインでレンダリングします。基礎となるファイルはデフォルトの$CODEX_HOME/*パスに残っていても構いません。
• プロジェクトで参照されるアセットをデフォルトの$CODEX_HOME/*パスのみに残さないでください。
• ユーザーが明示的に置き換えを要求した場合を除き、既存のアセットを上書きしないでください。それ以外の場合は、hero-v2.pngやitem-icon-edited.pngなどのバージョン管理されたファイル名を作成します。

両方のモードに共有されるプロンプトガイダンスはreferences/prompting.mdとreferences/sample-prompts.mdにあります。

CLIモード専用のフォールバックドキュメント/リソース：

• references/cli.md
• references/image-api.md
• references/codex-network.md
• scripts/image_gen.py

使用する場合

• 新しい画像を生成する場合（コンセプトアート、製品ショット、カバー、Webサイトヒーロー）
• スタイル、構図、ムードのために1つ以上の参照画像を使用して新しい画像を生成する場合
• 既存の画像を編集する場合（インペインティング、照明や天候の変換、背景の置き換え、オブジェクトの削除、コンポジット、透明背景）
• 1つのタスクに対して多数のアセットまたはバリアントを生成する場合

使用しない場合

• リポジトリ内の既存のSVG/ベクターアイコンセット、ロゴシステム、またはイラストライブラリを拡張またはマッチングする場合
• SVG、HTML/CSS、またはキャンバスで直接作成する方が適している単純な形状、図、ワイヤーフレーム、またはアイコンを作成する場合
• ソースファイルが編集可能なネイティブ形式ですでに存在する場合に、小さなプロジェクトローカルアセット編集を行う場合
• ユーザーが生成されたビットマップではなく、決定論的なコードネイティブ出力を明らかに望んでいるタスク

決定木

2つの別々の質問について考えてください。

1. 意図： これは新しい画像ですか、それとも既存の画像の編集ですか？
2. 実行戦略： これは1つのアセットですか、それとも複数のアセット/バリアントですか？

意図：

• ユーザーが既存の画像をその一部を保持しながら変更したい場合、リクエストを編集として扱います。
• ユーザーがスタイル、構図、ムード、または被写体のガイダンスのための参照としてのみ画像を提供する場合、リクエストを生成として扱います。
• ユーザーが画像を提供しない場合、リクエストを生成として扱います。

ビルトイン編集セマンティクス：

• ビルトイン編集モードは、添付画像やスレッド内で以前に生成された画像など、会話コンテキストですでに表示可能な画像用です。
• ユーザーがビルトインツールでローカル画像ファイルを編集したい場合は、最初にビルトインのview_imageツールで画像を読み込んで会話コンテキストで表示可能にしてから、ビルトイン編集フローに進みます。
• ビルトインツールを通じて任意のファイルシステムパス編集を約束しないでください。
• ローカルファイルがまだ直接ファイルパス制御、マスク、またはその他の明示的なCLI専用パラメータを必要とする場合は、ユーザーが要求した場合にのみ明示的なCLIフォールバックを使用します。
• 編集の場合、不変条件を積極的に保持し、デフォルトで非破壊的に保存します。

実行戦略：

• ビルトインのデフォルトパスでは、要求されたアセットまたはバリアントごとに1回のimage_gen呼び出しを発行して、多数のアセットまたはバリアントを生成します。
• CLIフォールバックパスでは、ユーザーが明示的にCLIモードを選択し、多くのプロンプト/アセットを必要とする場合にのみ、CLI generate-batchサブコマンドを使用します。
• 多数の異なるアセットの場合、nを個別のプロンプトの代わりとして使用しないでください。nは1つのプロンプトのバリアント用です。個別のアセットには、個別のビルトイン呼び出しまたは個別のCLI generate-batchジョブが必要です。

ユーザーが既存の画像を変更することを明確に要求しない限り、ユーザーは新しい画像を望んでいると想定します。

ワークフロー

1. トップレベルモードを決定します：デフォルトではビルトイン（透明出力リクエストを含む）、明示的に要求または確認された場合のみフォールバックCLI。
2. 意図を決定します：generate または edit。
3. 出力がプレビュー専用か、現在のプロジェクトで使用されるかを決定します。
4. 実行戦略を決定します：単一アセット vs 繰り返しビルトイン呼び出し vs CLI generate-batch。
5. 入力を事前に収集します：プロンプト、正確なテキスト（逐語）、制約/回避リスト、および任意の入力画像。
6. すべての入力画像について、その役割を明示的にラベル付けします。
   • 参照画像
   • 編集対象
   • サポートする挿入/スタイル/コンポジット入力
7. 編集対象がローカルファイルシステム上にのみあり、ビルトインパスを継続する場合は、最初にview_imageで検査して、画像が会話コンテキストで利用できるようにします。
8. ユーザーが写真、イラスト、スプライト、製品画像、バナー、またはその他の明示的にラスター形式のアセットを要求した場合は、SVG/HTML/CSSプレースホルダーを代用するのではなく、image_genを使用します。リクエストがアイコン、ロゴ、または既存のリポジトリネイティブのSVG/ベクター/コードアセットと一致する必要があるUIグラフィックの場合、代わりにそれらを直接編集することを優先します。
9. 具体性に基づいてプロンプトを拡張します。
   • ユーザーのプロンプトがすでに具体的で詳細な場合、それを明確な仕様に正規化し、創造的な要件を追加しません。
   • ユーザーのプロンプトが一般的な場合、出力品質を実質的に向上させる場合にのみ、味わいのある拡張を追加します。
10. デフォルトでビルトインのimage_genツールを使用します。
11. 透明出力リクエストの場合、ビルトインのimage_genに透明な背景を依頼し、生成されたアルファチャンネルを保持します。
12. 出力を検査して検証します：被写体、スタイル、構図、テキストの正確さ、および不変条件/回避項目。
13. 1つのターゲットを絞った変更で反復し、再確認します。
14. プレビュー専用の作業の場合、画像をインラインでレンダリングします。基礎となるファイルはデフォルトの$CODEX_HOME/generated_images/...パスに残っていても構いません。
15. プロジェクトに組み込む作業の場合、選択したアーティファクトをワークスペースに移動またはコピーし、消費するコードや参照を更新します。プロジェクトで参照されるアセットをデフォルトの$CODEX_HOME/generated_images/...パスのみに残さないでください。
16. バッチまたはマルチアセットリクエストの場合、ユーザーが明示的に出力をプレビュー専用に保つように要求しない限り、要求されたすべての成果物の最終版をワークスペースに保持します。破棄されたバリアントは、要求されない限り保持する必要はありません。
17. ユーザーが明示的にCLIフォールバックを選択または確認した場合、モデル、品質、サイズ、input_fidelity、マスク、出力形式、出力パス、およびネットワーク設定に関するフォールバック専用ドキュメントを使用します。
18. ワークスペースにバインドされたアセットの最終保存パス、最終プロンプトまたはプロンプトセット、および使用されたモード（ビルトインツールまたはフォールバックCLI）を常に報告します。

透明画像リクエスト

ビルトインのimage_genに本当に透明な背景を依頼し、そのアルファを保持します。

プロンプト拡張

ユーザープロンプトを構造化されたプロダクション指向の仕様に再フォーマットします。ユーザーの目標をより明確で実行可能にしますが、盲目的に詳細を追加しないでください。

これをプロンプト整形ガイダンスとして扱い、閉じたスキーマとしては扱いません。役立つ行のみを使用し、明確さを実質的に向上させる場合にのみ、短い追加のラベル付き行を追加します。

具体性ポリシー

ユーザーのプロンプトの具体性を使用して、どの程度の拡張が適切かを決定します。

• プロンプトがすでに具体的で詳細な場合、その具体性を保持し、正規化/構造化のみ行います。
• プロンプトが一般的な場合、結果を実質的に向上させる場合にのみ、味わいのある拡張を追加しても構いません。

許可される拡張：

• 構図やフレーミングのヒント
• 品質レベルや使用目的のヒント
• 実用的なレイアウトガイダンス
• 要求されたリクエストをサポートする、妥当なシーンの具体性

許可されない拡張：

• リクエストによって暗示されない余分なキャラクターやオブジェクト
• 暗示されないブランド名、スローガン、パレット、またはナラティブビート
• 周囲のレイアウトがサポートしない限り、任意のサイド固有の配置

ユースケース分類（正確なスラッグ）

各リクエストをこれらのバケットの1つに分類し、プロンプトと参照全体でスラッグを一貫して保持します。

生成：

• photorealistic-natural — 本物のテクスチャと自然な照明を使用した、率直/エディトリアルなライフスタイルシーン。
• product-mockup — 製品/パッケージショット、カタログ画像、マーチャンダイジングコンセプト。
• ui-mockup — アプリ/Webインターフェースのモックアップとワイヤーフレーム。希望する忠実度を指定します。
• infographic-diagram — 構造化されたレイアウトとテキストを使用した図/インフォグラフィック。
• scientific-educational — 教室の説明者、科学図、および必要なラベルと正確性制約のある学習ビジュアル。
• ads-marketing — キャンペーンコンセプトと広告クリエイティブ。オーディエンス、ブランドポジション、シーン、および正確なタグライン/コピーを含みます。
• productivity-visual — スライド、チャート、ワークフロー、およびデータ量の多いビジネスビジュアル。
• logo-brand — ロゴ/マークの探索、ベクターフレンドリー。
• illustration-story — コミック、児童書のアート、ナラティブシーン。
• stylized-concept — スタイル駆動のコンセプトアート、3D/スタイライズドレンダリング。
• historical-scene — 時代に正確な/世界知識のシーン。

編集：

• text-localization — 画像内のテキストを翻訳/置換、レイアウトを保持。
• identity-preserve — 試着、人物インシーン。顔/体/ポーズを固定。
• precise-object-edit — 特定の要素を削除/置換（内部の交換を含む）。
• lighting-weather — 時間帯/季節/雰囲気の変更のみ。
• background-extraction — 透明背景/クリーンな切り抜き。ビルトインのimage_genに実際の透明度を依頼します。
• style-transfer — 被写体/シーンを変更しながら参照スタイルを適用。
• compositing — マルチイメージの挿入/マージ。照明/遠近感を合わせます。
• sketch-to-render — ドローイング/線画からフォトリアリスティックレンダリングへ。

共有プロンプトスキーマ

両方のトップレベルモードの共有プロンプト足場として、次のラベル付き仕様を使用します。

Use case: <taxonomy slug>
Asset type: <where the asset will be used>
Primary request: <user's main prompt>
Input images: <Image 1: role; Image 2: role> (optional)
Scene/backdrop: <environment>
Subject: <main subject>
Style/medium: <photo/illustration/3D/etc>
Composition/framing: <wide/close/top-down; placement>
Lighting/mood: <lighting + mood>
Color palette: <palette notes>
Materials/textures: <surface details>
Text (verbatim): "<exact text>"
Constraints: <must keep/must avoid>
Avoid: <negative constraints>

注記：

• Asset type と Input images はプロンプト足場であり、専用のCLIフラグではありません。
• Scene/backdrop は視覚的な設定を指します。フォールバックCLIの background パラメータ（出力の透明度動作を制御）と同じではありません。
• Quality:、Input fidelity:、マスク、出力形式、出力パスなどのフォールバック専用実行ノートは、CLIパスにのみ属します。これらをビルトインの image_gen ツール引数として扱わないでください。

拡張ルール：

• 短く保ちます。
• プロンプトを実質的に向上させるために必要な詳細のみを追加します。
• 編集の場合、不変条件を明示的にリストします（Xのみを変更、Yは変更しない）。
• 重要な詳細が欠落していて成功を妨げる場合は、質問をします。それ以外の場合は続行します。

例

生成例（ヒーロー画像）

Use case: product-mockup
Asset type: landing page hero
Primary request: a minimal hero image of a ceramic coffee mug
Style/medium: clean product photography
Composition/framing: wide composition with usable negative space for page copy if needed
Lighting/mood: soft studio lighting
Constraints: no logos, no text, no watermark

編集例（不変条件）

Use case: precise-object-edit
Asset type: product photo background replacement
Primary request: replace only the background with a warm sunset gradient
Constraints: change only the background; keep the product and its edges unchanged; no text; no watermark

プロンプティングのベストプラクティス

• プロンプトをシーン/背景 -> 被写体 -> 詳細 -> 制約の順に構造化します。
• 使用目的（広告、UIモック、インフォグラフィック）を含めて、モードと品質レベルを設定します。
• フォトリアリズムにはカメラ/構図の言語を使用します。
• ユーザーが明示的にベクター出力または非画像プレースホルダーを要求した場合にのみ、SVG/ベクターの代用を使用します。
• 正確なテキストを引用し、タイポグラフィと配置を指定します。
• トリッキーなワー...