nano-banana-app-store-campaign

Nano Banana App Store キャンペーン

チュートリアルではなく、広告として App Store のスクリーンショットを作成します。

レイアウトより先にコピーを考えます。装飾より先にストーリーを考えます。 スライドは、まず視覚的に内容を伝えられるものでなければなりません。 テキストはメッセージを際立たせるものであり、すべてを担うものではありません。

次のようなスクリーンショットキャンペーンをユーザーが求めている場合に、このスキルを使用します。

• 実際のアプリのコードベースと本物のスクリーンショットを基にする
• すべてのスライドで一貫したビジュアルシステムが必要
• 広告の仕上げに Nano Banana を使用する
• 決定論的なリサイズとコンタクトシートのパッケージ化が必要

このスキルでは Nano Banana のみを使用してください。 他の画像モデルに切り替えないでください。 Flash や品質の低い画像生成方法に、ユーザーに知らせず切り替えないでください。

ワークフロー

0. Nano Banana の認証情報を確認する

プロンプトの計画やスライドの生成を始める前に、現在の環境で Nano Banana を実際に実行できることを確認してください。

デフォルトの動作：

• Nano Banana を使用する
• まず GEMINI_API_KEY が設定されているか確認する
• 設定されていない場合は、GOOGLE_API_KEY が設定されているか確認する
• どちらのキーも利用できない場合は、生成を中止し、Gemini API キーをユーザーに求める

キーがないことを、別の画像モデルを使う許可と見なしてはいけません。

計画、メモ、プロンプトのログでは、使用する方法を明記してください。

• Nano Banana

認証情報の確認元を記録する必要がある場合は、次のように記載してください。

• Nano Banana credential source: GEMINI_API_KEY
• または Nano Banana credential source: GOOGLE_API_KEY

ツールや認証情報の確認元を曖昧にしないでください。

1. デザインを始める前にアプリを調査する

まずコードベースとアセットを確認します。次の項目を把握してください。

• フォントとタイポグラフィの手がかり
• カラーパレットと全体の雰囲気
• 実際に裏付けられている製品の訴求点
• 販売につながる差別化要素
• ユーザーにとって最も大きなメリット
• アプリが解決する、最も明確なユーザーの悩み
• ユーザーが感じるべき変化（使用前から使用後まで）

訴求点を作り上げてはいけません。コード、コピー、設定、オンボーディング、料金表示、プラットフォーム連携を根拠にしてください。

次の点を確認してください。

• アセットまたはフォントのフォルダーにあるフォント
• UI コード内のカラーのトークン
• オンボーディングやマーケティングのコピー
• 料金や購入に関する表現
• オフライン、プライバシー、ローカル AI、ウェアラブル、プラットフォーム連携に関する訴求

アプリが iOS を主な対象としている場合は、推測せず、実際の iOS の画面やアセットを確認してください。

2. キャンペーンのストーリーを決める

ユーザーが求めるスライド枚数に合わせて、アプリを広告のストーリーに落とし込みます。

ユーザーがそれより少ない枚数、または多い枚数を求めている場合、固定の 5～7 枚のストーリーを押しつけないでください。役立つ枠だけを使用します。

デフォルトのストーリー展開には、次のスクリーンショットの枠組みを使用してください。

枠	目的	備考
#1	ヒーロー／主なメリット	可能であれば、アプリアイコン＋キャッチコピー＋ホーム画面を見せます。多くの人が目にするのはこのスライドだけです。
#2	差別化要素	競合アプリとの意味のある違いを見せます。
#3	エコシステム	ウィジェット、拡張機能、ウォッチ、デスクトップなど、アプリの中核を超えた利用場面を見せます。実際に存在しない場合は省略します。
#4+	主な機能	重要度の高い順に、1 枚につき 1 つの機能を見せます。
最後から 2 番目	信頼の根拠	アイデンティティ、こだわり、信頼性を示します。例：「[X] を求める人のために作られました」。
最後	さらに多くの機能	追加機能や近日公開予定の機能を、ピルまたは短いモジュールで紹介します。誠実に伝えられるだけの機能がない場合は省略します。

スライドの順番を計画する際は、次のコンバージョン率の高い流れも活用してください。

• スクリーンショット 1 では、悩み、願望、または葛藤を提示する
• スクリーンショット 2 では、変化または成果を示す
• スクリーンショット 3 では、可能であれば具体的なもので裏付ける
• スクリーンショット 4 以降では、約束に説得力を持たせる 1 つまたは 2 つの機能を紹介する

これらを競合する枠組みとして扱うのではなく、枠のシステムと組み合わせてください。たとえば、次のようにできます。

• ヒーローで悩みを提示する、または成果を約束する
• 差別化要素で変化を示す
• 序盤の主な機能や信頼を示すスライドで、証拠を提示する
• 後半の機能スライドで、その成果をどのように実現するかを説明する ストーリーの基本ルール：
• 各スライドで訴求するアイデアは必ず1つだけにします
• 1枚のスライドに2つの機能を載せないでください
• 最初のスライドでは、広範な概要ではなく、ユーザーにとって最も大きなメリットを訴求します
• スライドの流れは、入れ替え可能なものではなく、1枚ごとに意図が感じられるものにします
• 1種類のテンプレートを繰り返すのではなく、複数のスライドの型を組み合わせて全体を設計します
• 要求されたスライド枚数に合わせて最適な枠を選び、すべての枠を機械的に埋めないでください
• スライドごとにレイアウトを変え、同じテンプレート構成を繰り返さないでください
• 隣り合うスライドでスマートフォンの配置を使い回さないでください
• 視覚的なリズムを生み出すため、背景を反転させるか、明確に明暗を変えたスライドを1〜2枚入れてください
• コピーはサムネイルサイズでも読みやすくします
• 装飾要素はメッセージを補強するものとし、UIを隠さないでください
• スクリーンショットを使うスライドでは、スクリーンショットを主役にします
• テキストでの説明より、ビジュアルによる説明を優先します
• テキストとビジュアルのバランスをすっきり整えますが、どちらかを選ぶ必要がある場合は、コピーを追加する前にビジュアルを強化します
• スクリーンショットにテキストを貼り付けただけのような、看板だけの構成は避けてください
• 1〜2枚は意図的に広告色を強め、スクリーンショットよりタイポグラフィや文脈を伝える画像を主体にしてもかまいません
• アプリのカテゴリーに合った、人、場所、物、素材、情景などの補助画像を取り入れます
• 目を引き、生き生きとしたセットにしつつ、騒がしくなったり、ありきたりになったりしないようにします

次のスライドの型を意図的に使い分けてください。優れたセットでは、そのうち少なくとも3種類を組み合わせます：

型	用途	典型的な使い方
Typography-led hero	製品の枠組みを最小限にし、大きく力強い文字を見せます	1枚目、信頼性を伝えるスライド、価値を訴求するスライド
Hybrid ad	スクリーンショットに、印象的な文脈画像、ステッカー、バッジ、軌跡、オブジェクトなどを組み合わせます	差別化要素や成果を伝えるスライド
Product proof	スクリーンショットを前面に出し、補助要素は控えめにします	主な機能や実績を伝えるスライド
Contextual/lifestyle	現実の場面、人、マスコット、場所、物などで、メリットを生き生きと感じさせます	感情に訴える差別化要素や、カテゴリーとの適合性を伝えるスライド
Brand/value	偽のスクリーンショットは使わず、文字、アイコン、オブジェクト、価値を示すパネルのみで構成します	所有権、プライバシー、特典、価格、信頼性

型のルール：

• すべてのスライドをプロダクトの実証を見せるスライドにしないでください
• すべてのスライドをテキストだけの看板にするのも避けてください
• 少なくとも1枚は、スクリーンショットを飾り立てたものではなく、まず大胆な広告として感じられるようにします
• アプリのカテゴリーに合う場合は、アプリを取り巻くライフスタイルや環境を訴求する文脈画像を使ったスライドを少なくとも1枚入れてください
• 文脈画像を使う場合は、メッセージに直接結び付けます。旅行先、ルート、食べ物、トレーナー、コイン、証明書、キャラクター、部屋、机、ユーザーがすぐに意味を理解できる物などを使います
• メッセージを純粋な価値訴求広告として見せたほうが効果的であれば、1枚はスマートフォンを最小限にするか、完全に省いてもかまいません

スライド枚数を減らしてストーリーをまとめる場合：

• #1 のヒーローを残します
• 追加の機能スライドより、まず差別化要素を1つ入れます
• エコシステムや「その他の機能」は、主な差別化要素を削る前に省きます

スライド枚数を増やしてストーリーを広げる場合：

• 内容を埋めるためのスライドを加える前に、主な機能スライドを追加します
• 信頼性を示すスライドは終盤に配置します
• 最後の「その他の機能」スライドは、全体の魅力を損なわず、誠実に幅広さを伝えられる場合にのみ使います

2.5. まずコピーを書く

見出しが十分に強くなる前にレイアウトを作成しないでください。

最終的なレイアウトを生成する前に、見出しの承認を得てください。コピーが悪ければ、優れたデザインも台無しになります。

コピーは精密なツールとして扱い、スライド全体の代わりにしないでください。 まずビジュアルで、機能、雰囲気、または成果を伝えます。 テキストはその意味をより速く明確に伝えるためのものであり、ビジュアルによる説明の代わりではありません。

スライドごとに、以下を行います。

• レイアウト作業の前に、見出しの案を3つ書く
• 以下のアプローチから、それぞれ1つずつ案を作る
  • ある瞬間を描く
  • 成果を示す
  • 悩みを解消する
• 承認を得るワークフローの場合は、各案に短い理由を1つ添えてユーザーに提示する
• ユーザーとのやり取りができない場合は、内部で最も優れた案を選び、計画またはメモにその理由を記す

スクリーンショット用コピーの厳守事項：

• 見出し1つにつきアイデアは1つにする
• 「and」で2つの主張をつなげない
• できる限り、短く一般的な単語を使う
• サムネイルサイズでも読めるコピーにする
• 核となる変化を8語以内で表せない場合は、表せるまで簡潔にする
• 1行あたり3〜5語を目安にする
• <br />を使って意図的に改行する
• その分野で本当に必要な場合を除き、専門用語を避ける
• 機能の羅列のような見出しを避ける
• 複雑な節を避ける
• 意味の薄い曖昧で大げさな表現を避ける
• 具体的で真実に即した主張でない限り、マーケティング用語を避ける

レンダリングに安全なコピーのルール：

• <br />は計画書、レイアウト計画、レビュー用メモの中でのみ使う
• 実際の画像生成プロンプトを書く際は、計画上の改行を以下のような明示的な複数行のコピー形式に変換する
  • Headline (2 lines):
  • Line 1
  • Line 2
• 最終画像にリテラルの<br />文字列を描画しないよう、画像モデルに明示する
• Nano BananaがHTML形式の改行トークンを正しく解釈するとは限りません

次の見出しの形式を使います。

種類	役割	例
ある瞬間を描く	アプリを使う場面を想像してもらいます	Check your coffee<br />without opening the app.
成果を示す	目指す最終状態を訴求します	A home for every<br />coffee you buy.
悩みを解消する	問題を明示して解決します	Never waste<br />a great bag.

弱いコピーは、レイアウトを生成する前に書き直してください。UIの要素ではなく、ユーザーが得るメリットを優先します。 まず機能を説明しないでください。生活に起きる変化を最初に伝え、その後に機能で補足します。 意味を伝えるのに大量のテキストが必要なスライドでは、コピーを増やす前にビジュアルのコンセプトを見直してください。

弱い表現から優れた表現への書き換え例：

弱い表現	より良い表現	優れている理由
Track habits and stay motivated	Keep your streak alive	アイデアが1つで、素早く理解できる
Organize tasks with AI summaries and smart sorting	Turn notes into next steps	成果を先に伝え、専門用語も少ない
Save recipes with tags, filters, and favorites	Find dinner fast	機能の羅列ではなく、メリットを訴求している
Manage budgets and never miss payments	See where money goes	約束が明確で、2つの主張を含まない
AI-powered wellness support	Feel calmer tonight	感情面の成果が具体的

コピーの作成手順：

1. スライドごとに案を3つ書きます。
2. 腕を伸ばした距離からそれぞれを読みます。約1秒で理解できない場合は書き直します。
3. 行の長さを確認します。1行が詰め込みすぎなら、<br />を追加するか位置を変えます。
4. 手でUIを隠し、テキストだけを読みます。流れが物語ではなく機能一覧のようになっていたら、書き直します。
5. 各スライドが1つのアイデアだけを訴求していることを確認します。
6. 承認された<br />入りの計画用コピーを、明示的な行ブロックを使ったレンダリング安全なプロンプト用コピーに変換します。
7. 最終レイアウトの作成に入る前に、承認された見出し一式を確定します。

3. 撮影するスクリーンショットをユーザーに具体的に指定する

スクリーンショットがまだ提供されていない場合は、承認済みのストーリースロットと見出しをもとに、具体的な撮影リストを作成します。

以下を含む、短い番号付きリストを作成します。

• ファイル名
• 撮影する画面の指定
• 画面に表示する内容
• どのスライドのアイデアを支えるか

スクリーンショットを使うスライドごとに、未加工のスクリーンショットを1枚だけ使います。

タイポグラフィを中心に構成する価値訴求スライドでは、スクリーンショットを求めないでください。

撮影リストの形式例：

• 01-main-value-screen.png：アプリの主なメリットが最もよく伝わる画面。明確なヒーローセクションを1つ表示
• 02-structure-screen.png：構成、ワークフロー、または次の手順が明確にわかる画面
• 03-action-screen.png：ユーザーが中心的な操作を行う直前の画面。主要な CTA を表示

4. 生成前にレイアウト計画を確定する

最終スライドを生成する前に、プロジェクトまたは出力ディレクトリにレイアウト計画の Markdown ファイルを作成します。

references/layout-plan-template.md をひな形として使用します。 ユーザーがしっかりした初期案を必要としている場合は、references/visual-recipe.md も参照します。

レイアウト計画は、以下の基準となります。

• 生成方法
• キャンペーンの位置付け
• ストーリーの軸
• 使用するストーリースロットと、意図的に省略したスロット
• 全体の構成で使用する、課題 → 変化 → 根拠 → 提供の流れ
• 一貫性の軸
• トリミングに対応した構図のルール
• スライドの順序
• 承認済みの見出しと補足コピー
• 有用な場合は、各スライドで検討した見出しの3つの案
• セット全体のスライドのアーキタイプ計画
• スマートフォンの配置のバリエーション
• レイアウトの変化の方針
• コントラストを活用するスライドの計画
• 背景の処理
• 差別化要素の扱い
• 書き出し先

この手順を省略しないでください。スタイルの一貫性を保つための計画です。

生成前に、ビジュアルのリズムも確定します。

• タイポグラフィ中心のスライドとスクリーンショット中心のスライド
• 最も大胆な見出しの表現を使うスライド
• 最も豊かな補助画像を使うスライド
• 最も明快な根拠を示すスライド
• 明るい色から暗い色へ、平面的な表現から立体的な表現へ、または落ち着いた雰囲気から活気のある雰囲気へ、セットの印象を意図的に切り替える箇所

5. まずスタイルの基準となるスライドを生成する

最初からセット全体をまとめて生成しないでください。

まずスライド 1 をスタイルの基準として生成します。

• 実際のスクリーンショットを忠実に使用する
• 固定したレイアウトプランを使用する
• スクリーンショットを中心に、プレミアムな広告表現を作る
• アプリの UI が見分けられる状態に保つ
• ヒーロースライドで、明確な主なメリットを 1 つ訴求する
• テキストで訴求し、UI でそれを実証する
• セット全体のタイポグラフィ、パネル表現、デバイスのライティング、アクセントの使い方、余白の考え方を定義する
• アプリに合う人物、場所、オブジェクト、背景シーンなど、セット全体で使う補助画像の表現を定義する
• スクリーンショットを主役にしつつ、補助画像でスライドに豊かさと躍動感を加える
• タイポグラフィ主体またはハイブリッド広告のスライドで始めたほうがキャンペーンの導入として効果的な場合は、中央にスマートフォンを置く定番の構成に固執せず、基準となるスライドで大胆な方向性を確立する
• スライド 1 は、見栄えのよい初稿にするだけでなく、意図的なシステムテストとして扱う
• 基準となるスライドを、次の要素を正式に定義するものとして扱う：
  • タイポグラフィ
  • 背景表現
  • パネル表現
  • デバイス表現
  • アクセントの使い方
  • 全体のビジュアルファミリー

失敗しやすい細部を早い段階で検証するために、スライド 1 を活用します。

• 正規化後のクロップ安全性
• 見出しのフォントファミリー、ウェイト、改行位置
• 補足行のサイズと情報量
• チップまたはバッジの大きさ
• 使用する場合の CTA の手がかり、矢印、トグル、ボタン
• スマートフォンの大きさと存在感
• 補助画像をどこまで増やすと多すぎるか
• サムネイルサイズでもスライドの内容をすぐに読み取れるか

「十分よい」だけを目指さないでください。 キャンペーンの残りに適用できる信頼性の高いシステムとなるまで、基準となるスライドを完成させてください。

アプリ固有のより優れた方向性がない場合は、デフォルトの構成システムとして、references/visual-recipe.md に記載されている実績のある縦長向けのレシピを使用してください。

基準となるスライドが次のいずれかを満たすまで、スライド 2 から N に進まないでください。

• ユーザーから明示的に承認されている
• 内部レビューで十分な品質が確認され、キャンペーンのビジュアルファミリーの見本として明確に使える

その後、承認済みのスライド 1 を、キャンペーンの残りに適用する主要なスタイルリファレンスとして使用します。

一貫性を保つための重要なコツは次のとおりです。

• 画像モデルで土台を作る
• その土台となるスライドを、残りのスライドに適用するビジュアルファミリーのリファレンスとして使う
• 任意の未加工の出力ではなく、スライド 1 の正規化済みエクスポートを、後続のスタイルリファレンスとして使う

スライド 1 を修正した後は、修正を通じて得た知見を明確に記録します。

• 実際に効果があったクロップ安全な余白
• 正規化後も最もよく保たれたフォント表現
• 読みやすさが保たれたチップ、CTA、パネルのサイズ
• 情報過多で削除したビジュアルモチーフ
• 許容できるテキスト量
• 後続のすべてのスライドで適用すべき構成ルール

これらの基準スライドで得た知見をレイアウトプランまたはプロンプトログに記録してください。 それをスライド 2 から N のルールとして使い、後続のスライドで同じ教訓を再び学ぶのではなく、検証済みのシステムを引き継げるようにします。

レイアウトプランとプロンプトログには、Nano Banana を明記してください。 利用可能な場合は、認証情報が GEMINI_API_KEY と GOOGLE_API_KEY のどちらに由来するかも記録してください。

6. キャンペーンの残りを生成する

スタイルの基準と各対象スクリーンショットを使って、スライド2〜Nを生成します。

次のルールに従ってください。

• 実際のアプリの UI をそのまま維持する
• 製品を再デザインしない
• 拡大した UI の断片は、同じスクリーンショット内のものだけを使用する
• キャンペーン全体で同じスタイルの系統を保つ
• ストーリー上効果的な場合は、すっきりとした実証スライドと、情報量の多い広告スライドを交互に配置する
• 隣り合うスライドでスマートフォンの配置を変える
• セット全体の構図のリズムに変化をつける
• セット全体でスクリーンショットの占める比重に変化をつける
• 文字は大きく、力強く保つ
• 訴求内容は短く、具体的にする
• 各スライドのテーマは、承認済みのアイデア1つに絞る
• ビジュアルで説明し、テキストで訴求内容を際立たせる
• 背景や装飾モチーフは、スライドのメッセージを後押しするものにする
• スクリーンショットまたは製品の中心となるビジュアルを主役にする
• メッセージとアプリのカテゴリを強化する場合に限り、補助的な画像を追加する
• 何もない背景や、テキストだけを並べた看板のような構図は避ける
• 後続スライドでは、見出しのフォントファミリーまたは書体を基準スライドに明示的に合わせる
• 基準スライドがすでにそうしたデザインでない限り、後続スライドの見出しがセリフ体や別のタイポグラフィの表現に逸れないようにする
• 基準スライドのデザイン言語にすでに含まれていない限り、白いテキストカードや巨大なコピー用パネルを大きく配置しない

優れた App Store キャンペーンを参考に、品のある変化を加えます。

• 大きな見出し文字を配した、大胆な色面のスライド
• 訴求内容を後押しする場合に限り、ステッカー、バッジ、パス、軌道、リボン、グローなどのモチーフをいくつか使う
• 構成に役立つ場合は、シンプルなフッターバンドやコンパクトな価値訴求バーを使う
• アプリに生活感を与える切り抜き写真、マスコット、オブジェクト、シーンの断片を時折使う
• にぎやかな広告スライドの後に、セットにゆとりを持たせるため、控えめな実証スライドを1枚配置する

一貫性を単調さと取り違えないでください。セット全体にアートディレクションを施し、テンプレートのような印象にしないでください。

後続のプロンプトでは毎回、基準スライドのスタイルの DNA を明示的に言い直してください。

• タイポグラフィのサイズ
• 背景の表現
• パネルの扱い
• デバイスの見せ方
• アクセントの使い方
• 基準スライドの修正から得られた、トリミング時の安全領域に関する知見
• 正規化後にうまく機能したフォント、CTA、チップ、間隔の決定事項

出力には、次のパターンを必ずそのまま使用してください。

• モデルの未加工の出力を native/ に保存する
• すべてのスライドを export-<width>x<height>/ に正規化する
• prompt-log.md を維持する
• 正規化した書き出しデータから contact-sheet.png を作成する

これは、良好な campaign-v3 の実行で使われた基準となる作業パターンです。これを再利用し、より緩やかな書き出しフローを新たに考案しないでください。

プロンプトの構成には references/prompt-patterns.md を使用してください。

6.5. 生の出力ではなく、最終的なクロップを想定してデザインする

生成する元画像は、最終的な App Store のクロップをあらかじめ考慮したものにする必要があります。

正規化すれば安全に収まると考えて、重要な要素を端にぴったり配置しないでください。

正規化はレイアウト工程ではなく、最終的なパッケージング工程として扱ってください。

重要な要素はすべて、クロップしても安全な領域に収めてください。

• 見出しと補足文
• チップと価値を示すパネル
• スマートフォンまたはメインとなる焦点オブジェクト
• 必ず読ませたいアイコンやコールアウト

ポートレートスライドでは、次のデフォルトの安全マージンを使用してください。

• 左右の安全マージン：キャンバス幅の少なくとも 8％
• 上部の安全マージン：キャンバス高さの少なくとも 6％
• 下部の安全マージン：キャンバス高さの少なくとも 8％
• 重要なコピーや焦点オブジェクトを外枠に触れさせないでください

直感ではなく、実際の正規化計算を使用してください。

• 最終的な iPhone ポートレートの目標比率は 1320 / 2868 = 0.4603 です
• 正規化では、まず中央でクロップしてからリサイズします
• 生成元画像の幅が 0.4603 を超える場合、残る幅は src_h * 0.4603 です
• 左右それぞれの水平トリミング幅は (src_w - src_h * 0.4603) / 2 です
• 生成元画像の幅が 0.4603 より狭い場合、残る高さは src_w / 0.4603 です
• 上下それぞれの垂直トリミング幅は (src_h - src_w / 0.4603) / 2 です

プロンプトを作成する前に、これを初回の安全領域に反映してください。

• 横長のポートレート画像では、安全領域の左端は horizontal_trim + 0.08 * surviving_width です
• 横長のポートレート画像では、安全領域の右端は src_w - safe_left_edge です
• 横長のポートレート画像では、安全領域の上端は 0.06 * src_h です
• 横長のポートレート画像では、安全領域の下端は 0.92 * src_h です
• 縦長のポートレート画像では、同じ考え方を上下のトリミングに適用してください

初回の安全領域を設定する際の一般的な例：

• 1024x1536 の画像では、幅は約 707px しか残りません。左右それぞれ約 158px が切り取られ、安全なコンテンツ領域はおよそ x=216..808、y=92..1413 です
• 1242x2208 の画像では、幅は約 1017px しか残りません。左右それぞれ約 113px が切り取られ、安全なコンテンツ領域はおよそ x=194..1048、y=132..2031 です

初回の元画像のサイズがまだわからない場合：

• 最終比率より幅の広い一般的なポートレート画像を想定してください
• 元画像の幅の約 10 to 16 percent が左右それぞれから失われるものとして扱ってください
• 必ず読ませたいコピー、スマートフォン、顔、チップ、矢印、根拠を示すパネルは、初回は元画像幅の中央 58 to 70 percent にすべて収めてください
• この保守的な初回ルールは、モデルに「適当に余白を残して」と頼むより効果的です

テキストや根拠を多く含むスライドでは、より厳しいデフォルトを適用してください。

• 見出しと補足文は、キャンバス中央のおよそ 70％ の範囲に収めてください
• 重要なコピーを左右の端ぎりぎりに配置しないでください
• チップと補足的な訴求要素も、同じ安全領域内に完全に収めてください
• 文字をクロップ境界に近づけるのではなく、コピーを短くしてください

プロンプトを作成する際は、Nano Banana に次の内容を明示してください。

• 後から最終的な App Store サイズに合わせて中央でクロップする前提で構成する
• 重要なテキストと主要なビジュアルはすべて、安全マージンから十分に離して配置する
• 正規化用に、端の近くには切り捨ててもよい背景スペースを残す
• 初回のポートレート画像は、中央クロップ時に左右それぞれ幅の約 10 to 16 percent が失われる可能性があるものと想定する
• 必ず読ませたい要素は元画像全体ではなく、中央の安全領域にすべて収める
• 見出し、チップ、CTA の要素、スマートフォンのシルエットを元画像の左右の端近くに配置しない

クロップ前だけ見栄えがよいスライドは、完成していません。

6.6. 最終確認の前にクロップ検証を行う

アンカーを生成した後と、全セットを生成した後に、次の作業を行います。

• 現在の出力を正規化します
• 正規化したエクスポートを、元のレンダリングだけでなく実際に目視で確認します
• 画像を1枚ずつ実際に確認します
• 見出し、補足文、スクリーンショットの端、チップ、ビジュアルパネルが不自然にクロップされていないことを確認します
• クロップ後もスマートフォンが意図どおりに見えることを確認します
• 見出しやフォーカルオブジェクトの周りの余白がつぶれていないことを確認します
• コンタクトシートで全体を手早く確認したうえで、正規化した各スライドを個別にフルサイズで確認します

正規化したエクスポートでクロップの問題が見つかった場合は、次の作業を行います。

• 元のプロンプトを修正します
• 端の余白を増やします
• そのスライドを再生成します
• 再度正規化します
• 新しい正規化画像を再確認します
• クロップが明らかに適切になるまで繰り返します

元のレンダリングの見栄えがよかったという理由だけで、スライドを完成扱いにしないでください。 これは任意の仕上げ作業ではなく、必須のビジュアル検証ループとして扱ってください。

7. ブランド価値を伝えるスライドは個別に扱う

料金、オフライン利用、プライバシー、オンデバイス AI、所有権に関するスライドが必要な場合は、次の点に従います。

• アプリ画面をでっち上げないでください
• メッセージ性のない抽象的な画像を適当に使わないでください
• タイポグラフィを主役にした価値訴求スライドを作成します
• 主張を伝える、意味のあるプレミアムパネルやモチーフを2〜3点使用します
• スマートフォンをもう1台使う代わりに、アプリアイコン、マスコット、カテゴリに関連するオブジェクト、証明書、報酬、ルート、コインなど、具体的なシンボルの使用を検討します
• キャンペーンのリズムがよくなる場合は、大きな文字と最小限の UI を使った真のブランド広告として、スライドの1つを構成します

良い例：

• 買い切りを表す所有権カードや購入のメタファー
• オフライン利用を表す、電波オフやローカルモードのモチーフ
• オンデバイス AI を表す、プライベートデバイスやローカルモデルのモチーフ
• 意味のあるボタン、バッジ、チップ、矢印、トグル、パネルなど、テキストのかたまりにせずスライドをすばやく理解できる、明確なビジュアル CTA の手がかり

避けるもの：

• ロボット
• 光る脳
• ありきたりなクラウド表現
• 仕様書のように情報が詰まった説明文
• より明確なビジュアルで伝えられる内容を、余分な説明文で補うこと

8. エクスポートを正規化する

生成後、最終エクスポートは必ず App Store の目標サイズに正規化します。

iPhone 縦向きのデフォルト目標サイズ：

• 1320x2868

ユーザーが別の Apple の掲載枠を指定した場合は、そのサイズを正確に使用します。

付属のスクリプトを使用します。

• scripts/normalize_app_store_exports.py
• scripts/build_contact_sheet.py

すべてのスライドを同じ目標サイズに正規化します。画像を引き伸ばさないでください。まず目標のアスペクト比にクロップしてから、リサイズします。 画像モデルが最終的な App Store サイズを直接返すことを当てにしないでください。

また、次の点にも注意します。

• 正規化によって重要なコンテンツが失われないようにします
• 一括で最終確認する前に、正規化した画像自体を確認します
• クロップによって読みやすさやレイアウトが損なわれる場合は、元の生成プロンプトを修正して再生成します
• 再生成のたびに、再度正規化して新しい正規化画像を確認します
• 元のレンダリングだけでなく、正規化したエクスポートが適切になるまで繰り返します
• 最終版とする前に、正規化したセット全体に対して2回目のクロップ検証を行います

推奨フォルダー構成：

output/
  nano-banana-layout-plan.md
  prompt-log.md
  native/
    slide-01-...
    slide-02-...
  export-1320x2868/
    slide-01-...
    slide-02-...
  contact-sheet.png

9. レビュー用の出力をまとめる

最後に、次のものを提供します。

• レイアウト計画ファイル
• 最終エクスポートフォルダー
• 使用した場合はプロンプトログ
• レビュー用のコンタクトシート

10. 一貫性の QA パスを実施する

作業を完了とする前に、references/quality-gates.md に照らして確認してください。

以下の問題が見つかった場合は、作業を完了として提示する前に修正してください。

• メッセージを強化していない、脈絡のない背景
• モックアップにスクリーンショットをそのまま配置しただけの構成
• 小さすぎる、または冗長すぎるコピー
• 隣り合うスライドの配置のリズムが同じ
• 汎用的な AI アートのように見え、製品の訴求になっていないバリュースライド
• キャンペーン全体に一貫性が感じられないスライド
• パッチノートや機能ラベルのように読めるスクリーンショット内のテキスト
• 実際のストーリーが語られず、どの順番でも成立してしまう一連のスライド
• 最初の調整後も、正規化した書き出し画像にわずかでも切り抜きの不具合が残っているスライド

プロンプトのガイドライン

厳格なルールを含め、命令形のプロンプトを使用してください。

このスキルでは、以下を守ってください。

• 計画またはプロンプトログで Nano Banana を明示する
• スライド 1 を Nano Banana のスタイルアンカーとして説明する
• 後続のスライドは、そのアンカーから派生した一貫性のあるバリエーションとして説明する
• 生成前に、まず GEMINI_API_KEY、次に GOOGLE_API_KEY を確認する
• どちらのキーも存在しない場合は、Gemini API キーをユーザーに求め、キーが使えるようになるまで生成を一時停止する
• 認証情報がないからといって、別の画像モデルに切り替えない

必ず以下を含めてください。

• スクリーンショットを忠実に保持する
• アプリの UI を再設計しない
• サムネイルサイズでも文字を読みやすく保つ
• 必要に応じて <br /> を使い、見出しの改行を意図的に設定する
• スライドを広告主体にする
• 各スライドのテーマを 1 つだけに絞る
• まずビジュアルで説明し、コピーで理解を速める
• スタイルアンカーと同じ系統のスライドにする
• ビジュアル表現でスライドのメッセージを強化する
• <br /> を使ったコピーを計画している場合は、トークンをそのまま貼り付けず、明示的なプロンプト行に変換する
• do not render literal <br /> characters と明示する
• use the same headline font family / type style as the anchor と明示する

スクリーンショットを使わないバリュースライドを生成する場合は、その旨を明示してください。

失敗パターン

よくある次の失敗を積極的に避けてください。

• ユーザーが Nano Banana を指定したのに、画像生成ツールを曖昧なままにする
• Nano Banana の生成を試みる前に Gemini の認証情報を確認しない
• GEMINI_API_KEY または GOOGLE_API_KEY がないのに処理を続行し、生成が可能であるかのように見せる
• Gemini のキーがないため、別の画像モデルに切り替える
• コピーを先に作成する段階を省略したり、見出しが確定する前にレイアウトを生成したりする
• スクリーンショットのテキストを広告の訴求ではなく、機能説明のように書く
• <br /> を画像生成プロンプトに直接貼り付け、出力画像にそのトークンが描画される
• 出力を1セットだけ保存し、ネイティブ形式とエクスポート形式を分けない
• 後続の一連の画像の参照として、未加工のアンカー画像やサイズの異なるアンカー画像を使う
• モデルが返したサイズを信頼し、正規化しない
• テキストや主要なビジュアルを端に寄せすぎて、正規化時に切り取られる
• 未加工のレンダリングだけを確認し、正規化後の画像を確認しない
• クロップ処理を1回実行して問題に気づいても、修正されるまで繰り返さない
• スライドを、豊かな製品広告ではなく、テキストの看板のように扱う
• ビジュアルでより明確に示せる機能を、主にテキストで説明する
• アプリのカテゴリやメッセージとのつながりが明確でない、無関係な画像を追加する
• 複数のスライドで同じような曖昧な背景表現を使う
• ほぼすべてのスライドで、スクリーンショットと見出しを組み合わせたレイアウトを使う
• すべてのスライドを同じようにスクリーンショット中心にし、キャンペーンにリズムがなくなる
• 太字の文字主体や価値訴求主体の広告スライドのほうがメッセージを効果的に伝えられる場合でも、それを使わない
• スタイルのアンカーが確定する前に、すべてのスライドを生成する
• レイアウト計画を任意のものとして扱う
• セット内で同じスライドテンプレートの構成を使い回す
• 隣り合うスライドで同じ位置にスマートフォンを配置する
• 1つのメッセージに絞らず、スライドに機能説明のコピーを詰め込む
• 「and」で2つのアイデアをつなぐ見出しを書く
• 機能リストを見出しとして使う
• 具体的なユーザーメリットを訴求しない、曖昧な見出しや流行語だらけの見出しを書く
• スクリーンショットをどの順番に並べ替えても意味が変わらないセットを作る
• 未加工のレンダリングでは問題なさそうに見えたために、テキストの多いスライドをクロップ境界近くに配置する
• 後続のスライドで、アンカーとは異なるフォントファミリーや、巨大なテキストカードを使う表現に逸脱する
• 装飾パネルで、意味を加えずに同じテキストを繰り返す
• 製品に根ざした価値パネルではなく、ありきたりなビジュアルで「AI」スライドを作る

リソース

references/

必要な場合にのみ参照してください。

• references/layout-plan-template.md：キャンペーン計画ファイルのテンプレート
• references/prompt-patterns.md：アンカースライド、後続スライド、価値訴求スライド向けの再利用可能なプロンプト構成
• references/quality-gates.md：ストーリーとビジュアルの一貫性を確認するためのチェックリスト
• references/export-pattern.md：稼働中の v3 キャンペーンで使われた、フォルダー構成と正規化の正確なパターン
• references/visual-recipe.md：優れた v3 セットで効果があった具体的なビジュアル上の判断
• references/gemini-image-api.md：Gemini を利用する環境向けの Nano Banana 認証情報に関する注意事項

scripts/

生成後に、次の決定論的なヘルパーを使用してください。

• scripts/normalize_app_store_exports.py：生成したスライドをクロップし、一貫した App Store サイズにリサイズする
• scripts/build_contact_sheet.py：正規化済みのエクスポートから確認用シートを作成する

出力チェックリスト

完了前に、以下を確認してください。

• キャンペーンはチュートリアル主導ではなく、広告主導になっている
• 各スライドで訴求するアイデアは1つになっている
• 最終レイアウトを作成する前に見出しを作成し、確定している
• UIを隠しても、テキストだけで一貫したストーリーが伝わる
• 隣り合うスライドで配置に変化をつけている
• 適切な場合は、シンプルな証拠提示のスライドに、表現力豊かな広告主導のスライドを少なくとも1枚加えている
• 同じテンプレートを繰り返すのではなく、セットに視覚的なリズムがある
• 主張がアプリの実態に基づいている
• セット全体に視覚的な一貫性がある
• 書き出し画像のサイズをApp Storeの1つのサイズに統一している