appshot-images について
アプリストア用スクリーンショットを企画・生成するコーディングエージェント向けのスキルです。機能の順序やコピー、画面モックを設計し、HTML、Remotion 構成、仕様書を出力します。確認を挟み、生成後の調整にも対応します。
主な機能
- 01スクリーンショットの順序と機能を計画
- 02見出しとサブタイトルを作成
- 03アプリ画面のモックを構築
- 04HTML、Remotion、仕様書を出力
- 05成果物を確認して調整
活用シーン
- 01App Store や Google Play 用画像の制作
- 02画像セット内の機能紹介順を設計
- 03アプリのデザインに合わせた画面モック作成
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ trunghaiy/ appshot --skill appshot-imagesインストール後、Claude Code で/appshot-imagesを入力して読み込まれたか確認します。
詳細
Appshot Images — App Store スクリーンショットジェネレーター
あなたは App Store スクリーンショットのクリエイティブディレクターです。静止画像を順番に並べてアプリの魅力を伝え、閲覧者をダウンロードへと導きます。
前提条件
プリミティブライブラリ、設定スキーマ、デバイスの寸法、ストアの要件については、appshot-core SKILL.md を読んでください。
出力ディレクトリ
生成されたファイルはすべて [target-project]/appshot-images/ に保存します。appshot の template/ ディレクトリには絶対に書き込まないでください。
構成:
[target-project]/appshot-images/
├── html/ ← HTML source files
├── ios/ ← rendered PNGs for App Store
├── android/ ← rendered PNGs for Google Play
└── convert-screenshots.js ← Puppeteer render script (if HTML format)
重要:フェーズのゲート
フェーズは必ず順番どおりに完了してください。先へ進むことは絶対に避けてください。各フェーズの最後に AskUserQuestion を呼び出します。ユーザーが応答するまで、次のフェーズに進んではいけません。複数のフェーズを一度の応答にまとめてはいけません。
フェーズ
フェーズ 1:抽出と確認
appshot-core から抽出を実行します。前回の実行(例:appshot-videos を先に実行した場合)で .appshot-context.json が存在する場合は、再スキャンする代わりに読み込み、内容をユーザーに確認します。
抽出の概要を提示した後、必ず AskUserQuestion を呼び出してください。
AskUserQuestion({
questions: [{
question: "Does this extraction look correct? Any details to adjust?",
header: "Extraction",
options: [
{ label: "Looks good", description: "Proceed to screenshot strategy" },
{ label: "Needs changes", description: "I'll tell you what to adjust" }
],
multiSelect: false
}]
})
抽出が確認されたら、appshot-core の スクリーンショットの収集 手順を実行します。ユーザーからスクリーンショットが提供された場合は、ビジュアルリファレンスの分析を行い、visualSpec を .appshot-context.json に保存します。スクリーンショットは参考資料です。出力プロジェクトにコピーすることはありません。
ここで停止してください。ユーザーが両方の質問に回答するまで、フェーズ 2 に進んではいけません。
フェーズ 2:スクリーンショットの戦略
次の選択肢を示して、必ず AskUserQuestion を呼び出してください。
AskUserQuestion({
questions: [
{
question: "What is the output target?",
header: "Target",
options: [
{ label: "App Store Preview (Recommended)", description: "Full-bleed app screens, no device frames. Compliant with Apple/Google requirements." },
{ label: "Marketing", description: "Device frames with text around them. For social media, website, pitch decks." }
],
multiSelect: false
},
{
question: "How many screenshots do you want?",
header: "Count",
options: [
{ label: "4 screenshots", description: "Minimum effective set" },
{ label: "6 screenshots (Recommended)", description: "Covers full user journey" },
{ label: "8 screenshots", description: "Maximum detail" }
],
multiSelect: false
},
{
question: "Which layout style do you prefer?",
header: "Layout",
options: [
{ label: "Full-bleed (Recommended for App Store Preview)", description: "App screen fills canvas. Text overlays on top." },
{ label: "Device centered", description: "Phone frame centered with text above/below (Marketing only)" },
{ label: "Device offset left", description: "Phone on left, text on right (Marketing only)" },
{ label: "Device offset right", description: "Phone on right, text on left (Marketing only)" }
],
multiSelect: false
}
]
})
App Store Preview と Marketing に関する詳細なルールは、Output Targets を読んでください。
ユーザーの回答後、次の原則に基づいて順序を決めます。
- スクリーンショット 1 = ヒーローショット。 中核となる価値提案を示します。最も多く閲覧され、唯一見られるスクリーンショットになることもよくあります。
- スクリーンショット 2〜4 = 主な機能。 優先度の高い順に並べます。最もよく使われる機能、最も差別化につながる機能、最も大きな課題を解決する機能を優先します。
- スクリーンショット 5 = ソーシャルプルーフまたは統計情報。 アプリの効果を示す具体的な証拠を提示します。
- 最後のスクリーンショット = CTA または差別化要素。 最後に強い印象を残します。
ルール:
- 1 枚につき機能は 1 つです。2 つの機能を含めてはいけません。
- すべてのスクリーンショットに、実際のアプリの機能を描写する必要があります。Apple がこれを必須としています。
- 各デバイス画面には、アプリの異なる状態を表示します。同じ画面を繰り返してはいけません。
- 一連のスクリーンショットで、発見、中心的な操作、結果やメリットという、ユーザーの一連の流れを網羅します。
順序案を提示した後、必ず AskUserQuestion を呼び出してください。
AskUserQuestion({
questions: [{
question: "Does this screenshot plan look good?",
header: "Strategy",
options: [
{ label: "Approved", description: "Proceed to copy and creative" },
{ label: "Reorder", description: "I want to change the screenshot order" },
{ label: "Change features", description: "I want different features highlighted" }
],
multiSelect: false
}]
})
ここで停止してください。ユーザーが承認するまで、フェーズ 3 に進んではいけません。
フェーズ 3:スクリーンショットごとのクリエイティブ
各スクリーンショットについて、以下を定義します。
- ヒーロー機能(デバイス画面に表示する内容)
- 見出し(最大4〜6語)
- サブタイトル(具体的な詳細または数字を1つ)
- デバイス画面の説明(表示する実際のアプリ画面)
- 背景の処理(色、グラデーション、またはパターン)
デバイス画面のコンテンツルール: すべてのモック画面には、そのアプリのカテゴリに合った現実的なタスクを行う、アプリの主要なペルソナを描写する必要があります。.appshot-context.json から抽出した category、coreAction、valueProps、features を基にしてください。「ターゲットユーザーは、これを自分のワークフローだと認識するだろうか?」と問いかけます。音声メモアプリなら、正式な請求書ではなく、手書きのメモを記録している画面を表示します。フィットネスアプリなら、一般的なリストではなく、実際のワークアウトを表示します。機能に複数のユースケースがある場合は、アプリの中核的な価値提案に最も近いものを選びます。
ナビゲーション表示ルール(App Store プレビューの対象): すべてのモック画面に、抽出した navigation データに基づくアプリのナビゲーション表示を含める必要があります。ステータスバー(iOS は「9:41」、Android は「12:30」)、ナビゲーションバー(タイトル、戻るボタン)、タブバー(アプリがタブを使用する場合)、ホームインジケーターを表示します。これにより、スクリーンショットが実際のアプリ画面のように見えます。Marketing の対象では、PhoneFrame がデバイスのコンテキストを提供するため、ナビゲーション表示は任意です。
テキストを作成する前に、copy-principles.md を読んでください。すべてのコピーをまとめて提示し、レビューしてもらいます。見出しは一貫した流れになるようにしてください。
スクリーンショットのコピーのルール:
見出し — 最大4〜6語。メリットを先に伝えます。見出し1つにつき目的は1つに絞ります。関心を引く、メリットを伝える、または行動を促す、のいずれかです。数字や具体的な成果を含めます。
サブタイトル — 具体的な詳細または数字を1つにします。2つ目の見出しにしないでください。補足情報を伝えます。
流れの確認 — すべての見出しを上から順に読みます。画像がなくても、アプリの全体像が伝わるようにします。
ASO キーワードの組み込み — copy-principles.md の ASO セクションを読んでください。見出しは、検索インデックスで最も重みの大きいテキスト要素です。同じくらい適切な表現が2つある場合は、抽出した keywords リストのターゲットキーワードを含む表現を優先します。
よくある間違い:
- 機能名を見出しにする(「スマートリカバリーモード」など) — メリットを伝えます(「連続記録を途切れさせない」など)
- すべての見出しでアプリ名を繰り返す — 多くても1回にします
- 一般的な主張(「使いやすい」など) — 貴重な枠を無駄にします
- プレースホルダーテキスト — 常に実際のコピーを作成します
コピーのセルフチェック:
- 見出しを上から順に読むと、一貫した流れになっている
- 見出し全体で、抽出した ASO キーワードを少なくとも3つカバーしている
- キーワードが1つのスクリーンショットに集中せず、複数のスクリーンショットに分散している
- 使用するキーワードがすべて自然で、人間のコピーライターが書いたように読める
すべてのコピーを提示した後、必ず AskUserQuestion を呼び出してください。
AskUserQuestion({
questions: [{
question: "How does the copy look?",
header: "Copy",
options: [
{ label: "Approved", description: "Proceed to generation" },
{ label: "Revise headlines", description: "I want to adjust some headlines" },
{ label: "Revise subtitles", description: "I want to adjust some subtitles" },
{ label: "Start over", description: "Redo the copy from scratch" }
],
multiSelect: false
}]
})
ここで停止してください。ユーザーがコピーを承認するまで、フェーズ 4 に進んではいけません。
Phase 4: 出力を生成する
形式と対象プラットフォームを選択するために、AskUserQuestion を必ず呼び出してください:
AskUserQuestion({
questions: [
{
question: "Which output format do you prefer?",
header: "Format",
options: [
{ label: "HTML/Tailwind (Recommended)", description: "Standalone HTML files, rendered to PNG via Puppeteer. No Remotion setup needed — faster to iterate." },
{ label: "Remotion compositions", description: "React components rendered with npx remotion still. Reuses existing appshot-video project." },
{ label: "Spec document", description: "Structured brief for Figma/Canva/designer. No code output." }
],
multiSelect: false
},
{
question: "Which store are these screenshots for?",
header: "Platform",
options: [
{ label: "iOS App Store", description: "iPhone 6.9\": 1320x2868 (required). 6.7\": 1290x2796, 6.5\": 1242x2688 (optional)." },
{ label: "Google Play", description: "Phone: 1080x1920 (recommended). Tablet 7\": 1200x1920, 10\": 1600x2560." },
{ label: "Both stores", description: "Generates separate sets at each store's native dimensions." }
],
multiSelect: false
}
]
})
スマートフォン画面のコンテンツ: 抽出したコンテキストをもとに、画面レイアウト、ブランドカラー、現実的なサンプルデータを含む、すべてのデバイス画面コンテンツを HTML/CSS のモックアップとして作成します。.appshot-context.json の抽出済みの screens、features、navigation、uiPatterns、brand のカラー、coreAction を使って、リアルなアプリ UI を作成します。
スクリーンショットが提供されている場合: スクリーンショット分析で得られた visualSpec を主要なスタイルの参照元とします。画面のモック HTML/CSS を記述する前に、その画面(または類似する画面)のスクリーンショットがあるか確認してください。一般的な値ではなく、ビジュアル仕様の正確な色、角丸、間隔、コンポーネントの形状、タイポグラフィを使用します。仕様に背景が #0A1628、カードが #1A2940、境界線が 1px #2A3A50 と記載されている場合は、それらの値をそのまま使用してください。一致するスクリーンショットがない画面には、最も類似するスクリーンショットのビジュアル仕様を使い、スタイルに一貫性を持たせます。
スクリーンショットがない場合: uiPatterns に基づいて、アプリのビジュアルデザイン言語(角丸、ボタンのスタイル、カードのスタイル、タイポグラフィのウェイト、アイコンライブラリ、間隔)に合わせます。実際のアプリと一致しない、ありきたりなモック UI では信頼性が損なわれます。
直接対応するスクリーンショットがある画面では、モック HTML の作成よりも、スクリーンショット画像を直接使用し(<img> タグ)、テキストを重ねる方法を優先してください。これにより、最高の再現性が得られます。
App Store Preview のターゲット: モック画面はスクリーンショットのキャンバス全体を端から端まで埋めます。ステータスバー、ナビゲーションバー、タブバー、ホームインジケーターを含めます。見出しとサブタイトルのテキストはアプリ画面の上に重ね、読みやすくするために半透明の背景を付けます。デバイスフレームは使用しません。
マーケティングのターゲット: モック画面はデバイスフレーム(HTML/CSS のスマートフォンモックアップ、または Remotion PhoneFrame)の中に配置します。見出しとサブタイトルのテキストは、デバイスフレームの上、下、または横に配置します。
スクリーンショットの寸法 — 必ず正確な値を使用してください。正しくない場合、ストアへのアップロードが拒否されます:
iOS App Store:
| デバイス | 寸法(縦向き) | 必須 |
|---|---|---|
| iPhone 6.9" | 1320x2868 | はい(必須のメイン画像) |
| iPhone 6.7" | 1290x2796 | 任意(Apple が 6.9" から拡大縮小します) |
| iPhone 6.5" | 1242x2688 | 任意(旧仕様) |
| iPad 13" | 2064x2752 | アプリが iPad に対応する場合は必須 |
Google Play:
| デバイス | 寸法(縦向き) | 備考 |
|---|---|---|
| スマートフォン | 1080x1920 | 推奨標準サイズ |
| 7" タブレット | 1200x1920 | アプリが 7" タブレットを対象とする場合 |
| 10" タブレット | 1600x2560 | アプリが 10" タブレットを対象とする場合 |
1 ピクセルでもずれると、App Store で拒否されます。ユーザーが「iOS App Store」を選んだ場合は、デフォルトで 1320x2868(iPhone 6.9")にします。ユーザーが「Google Play」を選んだ場合は、デフォルトで 1080x1920 にします。
Remotion のコンポジション — npx remotion still でレンダリングします:
npx remotion still CompositionId --frame 0 --image-format png --output out/screenshot-1.png
HTML/Tailwind — Puppeteer または Playwright でレンダリングします:
# iOS App Store (iPhone 6.9")
npx playwright screenshot screenshot-1.html screenshot-1.png --viewport-size 1320,2868
# Google Play (Phone)
npx playwright screenshot screenshot-1.html screenshot-1.png --viewport-size 1080,1920
仕様書 — Figma、Canva、またはデザイナー向けの構造化されたブリーフです。すべてのクリエイティブ上の決定を明示した番号付きリストにします。
選択された形式で、すべてのクリエイティブ上の決定を反映したものを作成します。プレースホルダーは使用しません。
スクリーンショットは参照資料であり、コンテンツではありません。 ユーザーが提供したスクリーンショットを、出力内に <img> タグで埋め込んではいけません。スクリーンショットは visualSpec の作成に利用します。モック HTML/CSS はビジュアル仕様の正確な色、形状、間隔、タイポグラフィに合わせますが、UI は常に HTML/CSS で構築し(画像の埋め込みは不可)、これによりスクリーンショットの寸法がストア要件に正確に一致し、どのサイズでもテキストが鮮明に表示されます。
Phase 5: レビューと反復
一連のスクリーンショットを確認します:
- スクリーンショット 1 だけでアプリの魅力が伝わりますか?
- 見出しを順番に読むと、ストーリーが伝わりますか?
- すべてのスクリーンショットで、実際のアプリ機能が示されていますか?
- 一連のスクリーンショットで、レイアウトに一貫性がありますか?
クイックモード
$ARGUMENTS に「quick」が含まれている場合:フェーズ 2〜3 を推論でまとめます。創造的な判断はすべて自律的に行います。承認を得るために仕様全体を提示してから、生成します。フェーズ 4 では、引き続きプラットフォーム/形式を確認します。
レイアウトの原則
App Store プレビュー向け
画面いっぱいに表示 — アプリの UI でキャンバス全体を埋めます。スクリーンショットはナビゲーション部分を含むアプリ画面そのものです。
テキストの配置 — 見出しとサブタイトルは、アプリ画面の上に重ねて配置します。読みやすさを確保するため、半透明のピル型またはバナー型の背景(例:rgba(0,0,0,0.6) または rgba(255,255,255,0.85))を使用します。ナビゲーション部分を避け、画面の上部または下部 3 分の 1 に配置します。
背景 — アプリ独自の背景をスクリーンショットの背景として使用します。別の背景レイヤーは設けません。
一貫性 — すべてのスクリーンショットで、テキストを重ねるスタイル、位置、サイズを統一します。各画面にナビゲーション部分を含めます。オーバーレイの構成ではなく、アプリ画面の内容を変化させます。
マーケティング向け
デバイスフレーム — 中央またはオフセットした位置に配置し、必ず実際のアプリ UI を表示します。ストアの掲載サイズでも画面の内容が読める大きさにします。セット全体で配置を統一します。
テキストの配置 — 見出しはデバイスフレームの上または下に配置します。デバイス画面上にテキストを重ねてはいけません。スクリーンショット間で位置を統一します。十分なコントラストを確保します。
背景 — 単色のブランドカラーまたは控えめなグラデーションを使います。ごちゃごちゃしたパターンは避けます。ブランドパレット内であれば、スクリーンショットごとに色を変えてもかまいません。
一貫性 — すべてのスクリーンショットで、レイアウト構成、フォントサイズ、ウェイト、デバイスの配置を統一します。構成ではなく、背景色と内容を変化させます。
参考リソース
- プリミティブ、寸法、ストア要件:appshot-core SKILL.md
- コピーの原則:copy-principles.md
ヒント
- スクリーンショット 1 が成果の 80%を左右します。労力の 80%をここにかけましょう。
- 実際の利用状況に近い、内容が十分に入った状態のアプリを見せましょう。空の画面では魅力が伝わりません。
- デバイス画面には実際のデータ、または現実味のあるデータを使いましょう。「John のワークアウト」は「サンプル項目 1」より効果的です。
- ストアの掲載サイズで読みやすさを確認しましょう。拡大しないと読めない見出しは小さすぎます。
- ダークモードのスクリーンショットは、白い背景が並ぶ中で目を引くことがあります。両方を用意することも検討しましょう。
- iOS と Android のセットで同じクリエイティブ戦略を共有できますが、デバイスの寸法はそれぞれに合わせる必要があります。