generate-image

GEMINI_API_KEY 環境変数と uv パッケージマネージャーが必要です。

ワークフロー

1. 把握する — モード（t2i、i2i、複数の参照画像）を判定し、パラメーター（モデル、アスペクト比、解像度、出力先）を収集します。プロンプトで正確な実行（特定のポーズ、非対称なフレーミング、正確なトリミング）が求められる場合は、デフォルトで --batch 3 または --batch 4 を指定し、この点をユーザーに伝えます。画像生成は確率的であり、正確な指示が意図どおりに反映される確率はシードごとに約50％です。終了条件：モード、パラメーター、バッチサイズが明確になっていること。
2. プロンプトを作成する — 意図を伝えられる最小限のプロンプトをデフォルトとします。t2i では物語調の文章を使い、i2i／複数の参照画像では参照ブロックと最小限の指示を使います。該当するモードに合わせて、コアのチェックリストを適用します（常に適用）。エスカレーションツールキットを使うのは、既知の難しいパターン（細部や形状の忠実度が重要なショット）の場合、またはバッチでずれが確認された後に限ります。その際は、ツールキット全体ではなく、ずれが生じている属性に対する具体的な固定指示だけを追加します。単純な編集に過剰な制約を加えると、複雑な指示を不足させた場合と同様に品質が低下します。終了条件：プロンプトが作成され、コア項目が満たされ、エスカレーションツールは既知のパターンまたは確認されたずれに正当性がある場合にのみ追加されていること。
3. 確認する — 正確なプロンプト、入力画像（ある場合）、モデル、解像度、アスペクト比、バッチサイズをユーザーに提示します。確認を求めます。終了条件：ユーザーの承認が得られていること。
4. 生成する — 確認済みのパラメーターでスクリプトを実行します。終了条件：画像が保存され、表示されていること。
5. 反復する — 結果を提示し、改善案を出す前に意図との一致度を評価します。モードごとの評価順序は次のとおりです。t2i — 被写体が正しいか、構図、スタイルの忠実度。i2i 編集 — 変更対象が正しく見え、ほかの部分が変わっていないこと。複数の参照画像による合成 — まず、転写する主な属性が元の参照画像と一致していること（細部を重視するショットでは、形状の寸法、つまり幅、縁の形状、数、角度）、次に、二次的な一貫性（アイデンティティ、環境）、最後に演出（照明、構図、フレーミング）を確認します。タスクごとに何を優先するかを決めてください。一貫性を求めて約75％を超えて再プロンプトするのではなく、バッチから最良のフレームを選びます。終了条件：ユーザーが満足するか、次に進むこと。

デフォルトの出力とログ記録

ユーザーが保存先を指定しない場合、画像は次の場所に保存します。

~/Documents/generated images/

生成された画像ごとに、使用したプロンプトとモデルを記載した .md ファイルも作成します（例：logo.png → logo.md）。

パラメーター（アスペクト比、解像度）を収集する際は、カスタムの出力先を指定できることも提示します。

基本的なプロンプト作成の原則

キーワードの羅列ではなく、場面を物語として描写します。 Gemini の言語モデルは、文章を完全な意味理解に基づいて解析します。物語形式のプロンプトは、カンマで区切ったタグでは表現できない空間的な関係性、雰囲気、意図を伝えます。タグ形式のプロンプトでは構図の意味が失われ、ありきたりな結果になります。

Bad:  "cat, wizard hat, magical, fantasy, 4k, detailed"

Good: "A fluffy orange tabby sits regally on a velvet cushion, wearing an ornate
       purple wizard hat embroidered with silver stars. Soft candlelight illuminates
       the scene from the left. The mood is whimsical yet dignified."

否定形ではなく、肯定形で記述します。 プロンプトに含まれる概念はすべて、たとえ「〜ではない」「ない」「しない」のような語句が前に付いていても、その概念に出力を寄せます。拡散モデルは、極性にかかわらずトークンを条件として利用します。X を除外するには、（a）同じ役割を担う肯定的な代替要素を指定するか、（b）X が入り込む余地のないようにプロンプトの範囲を定めます。

Bad:   "A clean studio backdrop. No warm tones, no cream, no beige, no tan."
Good:  "A clean cool-neutral gray studio backdrop with subtle blue undertones."

Bad:   "A headshot with no harsh shadows on the face, no distracting background."
Good:  "A headshot on a clean neutral gray backdrop, even soft frontal fill light
        that flatters the face."

このルールは、スキル内のあらゆる箇所に適用されます。t2i プロンプト、i2i ディレクティブ、参照画像の役割の説明、構図の指示が対象です。

情報源を明示し、参照に曖昧さを残しません。 プロンプト内の要素はすべて、特定の情報源にたどれるようにします。「この男性」ではなく「Image 2 の男性」、「シャツ」ではなく「Image 3 のシャツ」と指定します。曖昧な参照は、モデルが最も重視する情報源に結び付けられますが、それが正しいとは限りません。これは過剰に説明するということではありません。参照画像にすでに写っているものを説明し直す必要はありません。各参照が一つの情報源だけを指すようにすることが重要です。

便利な形式は次のとおりです。[被写体] が [状況] で [動作] をしている。[カメラ／構図]。[照明]。[スタイル]。[制約]。 すべてのプロンプトに各要素が必要なわけではありません。意図に応じて詳細度を調整します。ユーザーのビジョンが明確な場合は、具体的な描写を指定します。アイデアを探っている場合は、方向性を大まかに示し、詳細はモデルに任せます。不明な点があれば、確認してください。

高度なプロンプト作成テクニック

細部まで具体的に指定する：数量、位置、属性を正確に指定します。「木製のテーブルの上に、三角形に並べた赤いリンゴを3個」は、「テーブルの上にリンゴがいくつか」よりも優れた結果になります。曖昧な言葉はどれも、モデルが自由に補う余地になります。

背景と意図を伝える：目的を明示します。視覚的な被写体が同じでも、「コーヒーの写真」より「コーヒーブランドのランディングページ用ヒーロー画像」と指定したほうが、意図によって構図、雰囲気、フレーミングが変わり、異なる結果になります。

手順を段階的に指示する：複雑な場面では、プロンプトを順を追った指示に分けます。「まず、広大な砂漠の風景を描きます。下部3分の1に、左から右へ歩く一人の人物を配置します。その後ろでは、右側から巨大な砂嵐が迫っています。」

肯定的な制約で除外する：出力に含めたくないものがある場合、それを否定形で指定しないでください。肯定的な代替要素を指定する（「ロゴなし」ではなく「ブランド表示のないすっきりした表面」）か、不要な要素が入り込む余地のないように場面を設定します（「机の上に閉じたノートパソコン」と指定すると、画面は描画できません）。「X はない」と指定しても、X は出現しやすくなるだけで、出現しにくくはなりません。

カメラを制御する：ショットの種類（極端なクローズアップ、ミディアムショット、空撮）、レンズ（魚眼、望遠）、カメラアングル（ローアングル、鳥瞰、ダッチアングル）を指定すると、フレーミングを正確に制御できます。

参照画像を使った編集には別の原則があります。references/editing-guide.md を参照してください。

---

編集の主な原則

編集プロンプトでは、シーンを描写するのではなく、変更内容を指示します。モデルが見ているものを指し示し、見えていないものだけを説明します。意図を明確に指定してください。必要最低限を超える形容詞、色の表現、保持に関する指示は、どれも参照画像と競合し、忠実度を損ないます。確実な形式は、参照ブロックに置換指示を1つ加えることです。動詞の暗黙の適用範囲が保持を担うため、停止指示は不要です。詳細はediting-guide.mdを参照してください。

複数の参照画像を使う場合（3枚以上）は、参照画像ごとに役割を割り当てます。各参照画像が担う要素を指定する1文を記述します（「Image 2のファサード、Image 3の車、Image 1の空と照明」）。editing-guide.mdの「Per-Reference Role Assignment」を参照してください。

名前を指定すると、その美学を直接呼び出せます。「shot on Kodak Portra 400」と指定するほうが、暖色系の肌やパステル調のハイライトを説明するよりも、その特徴的な見た目を確実に再現できます。

---

参考資料

プロンプトの作成時に、関連する参考資料を読み込んでください（ワークフローのステップ2）。

• references/capability-patterns.md — 写実的なシーン、製品写真、ロゴ、様式化されたイラスト、テキスト描画、グラウンディングに関するモード別のヒント
• references/editing-guide.md — 編集の文法、参照ブロック、指示の構成、画像の順序、セマンティックマスキング、キャラクターの一貫性
• references/style-reference.md — 名称付きの美学の用語集（フィルム、カメラ、スタジオ、アーティスト、ムーブメント）

---

設定

モデルの選択

	Nano Banana（デフォルト）	Nano Banana Pro
速度	高速、大量処理向け	低速、高品質
解像度	0.5K、1K、2K、4K	1K、2K、4K
追加のアスペクト比	1:4、4:1、1:8、8:1	—
思考モード	あり（minimal/low/medium/high）	なし
画像検索によるグラウンディング	あり	なし
参照画像の最大数	14	11（オブジェクト6個＋キャラクター5人）
テキスト描画	高度	標準

ほとんどのリクエストでは、デフォルトのNano Bananaを使用してください。ユーザーが最高品質を明示的に求めている場合や、Nano Bananaの結果をさらに改善する必要がある場合は、Nano Banana Proを使用します。

アスペクト比

両モデル：1:1、2:3、3:2、3:4、4:3、4:5、5:4、9:16、16:9、21:9
Nano Bananaのみ：1:4、4:1、1:8、8:1

解像度

• 0.5K（約512px） — 高速プレビュー（Nano Bananaのみ）
• 1K（約1024px） — デフォルト、高速
• 2K（約2048px） — 高品質
• 4K（約4096px） — 最大限の詳細

デフォルト：解像度1K、バッチ数1、アスペクト比はベース画像から自動検出（最初の入力画像。画像がない場合は1:1）。手早くプレビューして反復する場合は0.5Kを使用してください（Nano Bananaのみ）。より高品質な結果を求める場合は2Kを使用し、高精細さが明示的に必要な場合に限り4Kを使用してください。

思考モード（Nano Bananaのみ）

Nano Bananaは、複雑なプロンプトの解釈を改善する、調整可能な思考レベルに対応しています。

• minimal（デフォルト） — 最速。単純なプロンプトに適しています
• low/medium — 中程度に複雑なシーン向けのバランスの取れた推論
• high — 複数の要素を含む複雑な構図、正確なテキスト描画、または複雑な空間配置向けの最大限の推論

プロンプトに、正確な空間関係、複数のテキスト要素、または細かな構図の指定が含まれる場合は、--thinking highを使用してください。i2i編集では、思考モードは複数の参照画像を使った構成（3枚以上）、既存のシーンにテキストやサインを正確に配置する編集、要素の配置が重要となる複雑な空間編集にも役立ちます。

---

スクリプトの使用方法

1つの統合スクリプトですべてのモードに対応します。t2i、i2i、複数の参照画像を使った構成に使用できます。デフォルトのモデルはNano Bananaです。

# Text-to-image (t2i) — uses Nano Banana by default
uv run ${CLAUDE_PLUGIN_ROOT}/skills/generate-image/scripts/generate.py --prompt "A serene mountain lake at dawn" --output landscape.png

# Nano Banana Pro model
uv run ${CLAUDE_PLUGIN_ROOT}/skills/generate-image/scripts/generate.py --prompt "A serene mountain lake at dawn" --output landscape.png --model pro

# Image-to-image editing (i2i)
uv run ${CLAUDE_PLUGIN_ROOT}/skills/generate-image/scripts/generate.py --prompt "Make it sunset colors" --input photo.png --output edited.png

# Multi-reference composition
uv run ${CLAUDE_PLUGIN_ROOT}/skills/generate-image/scripts/generate.py --prompt "Combine the cat from image 1 with the background from image 2" --input cat.png --input background.png --output composite.png

# With options (aspect ratio, resolution, thinking, batch, grounding, format)
uv run ${CLAUDE_PLUGIN_ROOT}/skills/generate-image/scripts/generate.py --prompt "Logo for 'Acme Corp'" --output logo.png --aspect 1:1 --resolution 2K --thinking high

スクリプトのオプション

フラグ	短縮形	説明
--prompt	-p	画像の説明または編集指示（必須）
--output	-o	出力ファイルのパス（必須）
--input	-i	編集／合成する入力画像（繰り返し指定可能、最大14枚）
--model	-m	モデル：nano-banana（デフォルト）または pro
--aspect	-a	アスペクト比（ベース画像／最初の入力画像から自動検出、または1:1）
--resolution	-r	出力解像度：0.5K、1K、2K、または4K（デフォルト：自動検出または1K）
--grounding	-g	Google Searchによるウェブグラウンディングを有効化
--image-grounding		画像検索によるグラウンディングを有効化（Nano Bananaのみ。--groundingと併用）
--thinking	-t	思考レベル：minimal、low、medium、high（Nano Bananaのみ）
--quality	-q	出力圧縮品質1～100（JPEGのみ）
--format	-f	出力形式：png（デフォルト）またはjpeg
--batch	-b	複数のバリエーションを生成：1～4（デフォルト：1）
--json		エージェントでの利用向けに結果をJSON形式で出力
--quiet		進行状況の出力を抑制（MEDIA行は引き続き出力）

フラグが省略された場合、スクリプトは入力画像から解像度とアスペクト比を自動検出し、APIへの送信前に大きな入力画像（>2048px）を自動的にリサイズします。

---

生成前チェックリスト

コア項目は最低限の要件です。該当するモードのすべてのプロンプトに適用してください。エスカレーションツールキットは任意です。シンプルなt2iや単一要素の編集では、完全に省略してください。既知の難しいパターン（細部や形状の忠実度が求められるショット）に該当する場合、またはバッチ生成でずれが見られた場合にのみ使い、その際も実際にずれている属性に対する制約だけを追加してください。制約を追加するたびに、それ以外の要素の忠実度が下がるため、エスカレーションの規模はプロンプトの野心ではなく、独立してずれうる要素の数に応じて調整してください。

コア — t2i（常に適用）

• キーワードの羅列ではなく、物語性のある説明になっていますか？
• 全体を通して肯定的な表現になっていますか？プロンプト内に「Xはない」／「Xではない」／「Xをしないで」のような句が含まれていませんか？
• 写実表現のためのカメラや照明の詳細がありますか？
• 画像にテキストがある場合、テキストを引用符で囲み、フォントのスタイルを説明していますか？
• 用途に適したアスペクト比ですか？
• モデルの選択は適切ですか？（デフォルトはNano Banana、最高品質にはNano Banana Pro）
• 複雑なプロンプトに合わせて思考レベルを設定していますか？（Nano Bananaのみ）
• バッチサイズは精度の要件に合っていますか？（ポーズ／フレーミング／非対称の指示を正確に反映するには、--batch 3または--batch 4）

Core — i2i / マルチリファレンス（常に実施）

• プロンプトの冒頭に各画像の役割を示す参照ブロックがあるか？
• 参照の役割はポジティブな内容のみか？各参照から「使用する」要素を列挙し、無視する要素は記載しないか？（editing-guide.md の「Reference Block」を参照）
• 指示は最小限のパターンか？（参照ブロック＋置換指示を1つ。「ほかは何も変更しないで」という停止句や、装飾的な保持句は含めない）
• 指示全体を通してポジティブな表現になっているか？（ロックや構図に関する句も含め、否定表現を使わない）
• --input の先頭にベース画像を指定しているか（Image 1）。プロンプト内のラベルは入力順と一致しているか？（役割のラベルが誤っていると、キャラクターが変化します）
• 1つのプロンプトにつき変更は1つだけか？（競合する指示は、順次実行する複数のパスに分ける）
• 要素を抽出・転写する場合、汎用的な「画像 X の服／物体」ではなく、各要素を明示的に指定しているか？
• ある参照画像に保持すべき要素があり、別の参照画像がその要素と競合する可能性があるか？→ 先回りして CRITICAL — [element] を追加し、参照元を明示する（「Image 1 is the sole identity source. Image 2 is scoped to [attribute] only.」）。変化が起きるのを待たないでください。役割の競合は、テキストによる指示をひそかに無効化します。
• 参照画像と競合する色のラベルがないか？（色を表す語句は視覚的な参照より優先されます。editing-guide を参照）
• ベース画像に、出力へ影響しうる不要なアクセサリーがないか？（バッグ、帽子、サングラスなどが出力に混入します）
• 参照画像の数はモデルの上限以内か？（Nano Banana：14、Nano Banana Pro：11）
• 参照画像が3枚以上の場合、参照画像ごとの役割を割り当てる文があるか？（各画像が担う要素を1文で割り当てる。editing-guide.md の「Per-Reference Role Assignment」を参照）
• 人物を写実的に描くショットでは、肌と仕上がりを固定しているか？（ほぼすべてのケースで必要となる唯一の CRITICAL セクションです。生成時に肌がプラスチックのようになったり、レタッチされたりします）

エスカレーション用ツールキット — 署名が大きく異なる場合、または変化が確認された場合にのみ使用

• バッチ内で属性（アイデンティティ、照明／色、向き、ドレープ）に変化が生じているか？その特定の属性だけを、独立した ## CRITICAL — セクションでポジティブに表現して固定します。安定している属性まで過度に制約しないでください。（editing-guide.md の「Constraint Locking with CRITICAL Sections」を参照）
• ディテールショットで形状を維持できない場合、汎用的な「完全に一致させる」ではなく、属性ごとに列挙して形状を固定しているか？（capability-patterns.md の「Geometry Lock for Detail Shots」を参照）
• Nano Banana で --thinking high を指定し、参照画像が3枚以上あるにもかかわらず指示への追従が弱いか？在庫確認の前置きを追加します。（「Silently inventory the design-critical details: ...」）
• 同じセットからの後続ショットか？連続性を明示します。（「Image N と同じセット：被写体、設定、光は同一」— editing-guide.md の「Continuity Assertion」を参照）
• ヒーロー画像を固定したキャンペーンか？入力を2つに絞り、ヒーロー画像を要素一式の参照元、新たな属性の参照画像を1枚だけ指定します。（editing-guide.md の「Single-Reference Collapse」を参照）