Communitygithub.com

app-store-header-video

App Storeのプロダクトページヘッダー(21:9、3840x1646)と検索結果ヘッダー(3:2、1920×1280~3840×2560)のループ動画を制作、レンダリング、検証します。

app-store-header-video とは?

このスキルは、App Store用のクリエイティブアセット動画(プロダクトページヘッダーと検索結果ヘッダー)を制作するための包括的なワークフローを提供します。HyperFrames(HTML to video)をビルドツールとして使い、イメージ生成、ループシームの設計、Appleの仕様に準拠した動画のレンダリングと検証を行います。ユーザーは「App Storeヘッダー動画」「プロダクトページヘッダー」「検索結果ヘッダー」などのリクエストでこのスキルを呼び出せます。主な機能として、配置の特定と仕様の読み取り、単一アイデアへのフォーカス、ループシームの設計、HyperFramesでのビルド、画像生成、スナップショットでのイテレーション、仕様へのコンフォーム、検証、そしてアップロード手順の案内があります。このスキルはファイルの準備のみを行い、アップロードや申請はユーザーが自身で行います。App Store Connectでの公開前に、動画の寸法、フレームレート、コーデック、ループシームの品質を検証する検証スクリプトが含まれています。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/kairon007/app-store-header-video/tree/main

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

App Store ヘッダー動画

2種類のApp Store クリエイティブアセット動画を制作します。アプリアイコンの上でループするプロダクトページヘッダーと、検索結果のアプリカードで再生される検索結果ヘッダーです。どちらもミュートで自動再生され、永遠にループするため、すべてのフレームが無音で機能し、最後のフレームが最初のフレームにシームレスに繋がる必要があります。

このスキルはファイルを準備します。アップロードや提出は一切行いません — 公開はユーザーがApp Store Connectで行います。

収集すべき入力情報

不足しているものだけを質問してください。会話の中で既に提供されている場合もあります。

  1. 配置 — ヘッダー(21:9)、検索結果(3:2)、または両方。それぞれ異なる寸法のため、ヘッダー用のレンダリングをそのまま検索結果に再利用することはできません。
  2. 単一のアイデア — 動画で伝えたいことを一文で。アップル自身のガイダンス:「単一の明確なアイデアに焦点を当てる」。2つのアイデアがあると、どちらも伝わりません。
  3. アプリのアイデンティティ — アプリ名、一言の価値提案、ブランドカラー、ロゴファイル、アプリアイコンPNG。
  4. 実際のプロダクト素材 — コンセプトがアプリ自体を示す場合、実際のアプリのスクリーンショットまたは映像。クリエイティブアセットはブランドやコンテンツを強調することもできるため、これは必須ではありませんが、アプリを表示する場合は実際のキャプチャでなければなりません。
  5. 長さ — デフォルトは8秒。アップルは5~30秒を許容します。
  6. 機会 — 常設、季節限定ローンチ、機能ドロップ、リブランド。アセットを後で再利用できるかに影響します。

手順

このスキルのスクリプトは、このファイルの隣の scripts/ にあります。実行時は、このSKILL.md自身のディレクトリからの相対パスで解決してください — ユーザーの作業ディレクトリはスキルディレクトリとは異なります。

1. 配置を確定し、仕様を読む

制作前に references/specs.md を読んでください。アップルの正確なテーブル、アプリプレビューとクリエイティブアセットの区別、セーフエリアルールが記載されています。

asc CLIがPATHに通っていれば、asc asset-library specs でアップルの最新リファレンスデータが取得できます — このスキル作成時から数字が変わっていないことを確認するために使用してください。references/publishing.md にクエリが記載されています。

2つの配置は互換性がありません:

配置アスペクト比サイズ一般的な用途
プロダクトページヘッダー21:9正確に3840x1646アイコンの上の全幅バナー
検索結果3:21920×1280~3840×2560検索結果のカード

2. 単一のアイデアを選び、ポスターフレームを決める

単一のアイデアとポスターフレームを書き留めます — 再生開始前にユーザーが目にする静止画であり、自動再生がオフのときにアップルが表示するフレームです。ポスターフレームは静止画像として単独で成立していなければなりません。「価値提案や最も魅力的な機能でリードする」(アップル)。ポスターフレームが理解されるためにキャプションを必要とする場合、アイデアはまだ完成していません。

3. クリップではなく、シームをデザインする

動画は連続的にループし、人々は繰り返し視聴するため、t=0とt=Dの状態が一致しなければなりません。アニメーションを始める前にこれを計画します:

  • 連続的な動き — 360°の完全な回転や無限に移動するフィールドは、追加の作業なしで完全にラップします。
  • ベース状態への復帰 — スケールや位置が開始値にアニメーションで戻り、最後のビートが正確に開始フレームで終了します。
  • フェードスルー — 開始ビートでフェードイン、ホールド、終了ビートでベース状態にフェードバックし、ラップがソフトなディゾルブになります。

クリップは [start, start + duration) の範囲で表示され、終了状態が正確にクリップの終わりに来ることはありません。終了のトゥイーンを1フレーム早く(start + duration - 1/fps)終了させ、最終的な表示フレームが本当にベース状態になるようにします — そうしないと、ループは1フレーム不足して閉じることになります。

開始フレームと異なるフレームで終了するクリップは、ループではなくバグとして認識されます。

4. HyperFramesでビルドする

npx hyperframes init <project-dir>

ルートの index.html がキャンバスを宣言します。配置の正確なピクセルサイズに設定します — HyperFramesはコンポジションの作成時に指定された寸法でレンダリングし、想定したサイズは無視します:

<div id="root"
     data-composition-id="main"
     data-width="3840" data-height="1646"
     data-duration="8" data-fps="30">

このステップの成否を分けるルール:

  • #root に 1920px/1080px をハードコードしないでください。スタイルは width:100%; height:100% にします。
  • 21:9や3:2用の --resolution プリセットはありません — --resolution landscape-4k は3840x2160であり、形状が間違っており拒否されます。
  • ホストdiv、シーンルート、タイムラインキーに同じIDを指定します。不一致があると、各レンダリングでシーンあたり45秒待機し、その後静止フレームが表示されます。
  • シーン内では from ではなく fromTo を使用します — ホストがシーンを再シークし、from はシークバック時にドリフトし、ループを壊す原因になります。
  • フォントは assets/fonts/ に @font-face でファイルとしてバンドルする必要があります。バンドルされたファミリーのみが名前で解決されます。
  • テキストやコピーは、画像に焼き付けるのではなく、コンポジション内の変数(data-var-text)として配置します。
  • すべてのシーンを compositions/ 内に独自のサブコンポジションとして保持し、単一のビートを再レンダリングできるようにします。

references/hyperframes-build.md には、ループテクニックのスニペット、チェックおよびスナップショットコマンド、レンダーフラグ、および3840x1646のブラウザレンダリングがイテレーションに遅すぎる場合のフォールバックとしてのキャンバスからffmpegへのパイプラインが記載されています。仕様と検証はどちらも同じです。

5. コンセプトが必要とする場合のみ、サポート画像を生成する

写真、イラスト、雰囲気のある背景は画像生成から取得します。画像モデルでアプリUIを決して生成しないでください — インターフェースを幻覚し、ストアリストに偽のUIがあるのはUIがないより悪いです。アプリには実際のスクリーンショットを使用し、その他の周辺には生成を使用します。

mcode-tools connector tools --keyword image
mcode-tools connector tool <tool_name>          # 最初にinput_schemaを読む
mcode-tools connector call <tool_name> --args '{"prompt":"...","aspect_ratio":"21:9"}'

references/asset-generation.md には、完全な発見と呼び出しフロー、および特定のアスペクト比をプロンプトする方法が記載されています。

6. チェック、スナップショット、プレビュー — そしてレンダリング

npx hyperframes check --json                                  # クリーンである必要あり
npx hyperframes snapshot --at 0,4,8                            # PNGを確認する
npx hyperframes preview --background                           # ユーザーにURLを提供する

プレビューを表示する前にスナップショットを確認してください。チェックに合格しただけでは、フレームが正しく見えるとは限りません。

ユーザーがプレビューを確認して承認した後、またはファイルを停止せずに要求した場合にのみレンダリングします:

npx hyperframes render --quality delivery --fps 30 --format mp4 --output out/<name>.mp4

ソースがアプリの画面録画の場合は --video-frame-format png を追加し、UIテキストやフラットな色がフレーム抽出で生き残るようにします。

スナップショットでイテレーションし、レンダリングは1回だけ。 単一フレームのスナップショットはほぼ瞬時なので、npx hyperframes snapshot --at 0,4,7.9 でコンポジションを評価し、PNGを確認します。8秒の3840x1646デリバリーレンダリングは、MシリーズMacで約9秒かかります — レンダリング自体は遅い部分ではなく、イテレーションが遅いのです。フレームが正しく見えたら、一度だけレンダリングします。

テストはデリバリー品質でレンダリングするか、シーム判定を信頼する前に再エンコードしてください。 ドラフト品質のレンダリングは量子化ノイズを含み、エンコーダの最終フレームのノイズは最初のフレームのノイズと異なります。これは、ジオメトリではないラップの違いとして現れ、存在しないバグを追いかけることになります。小さなテストが --quality draft から来た場合は、コンフォームスクリプトと同じ方法(libx264 -crf 18 -pix_fmt yuv420p)で再エンコードし、確認してください。

7. ファイルを仕様にコンフォームする

HyperFramesレンダリングの後でも実行してください。誤ったフレームレートと誤ったピクセルサイズは、ユーザーが最初に直面する2つの拒否理由です。

node <skill-dir>/scripts/conform-video.mjs --in out/header.mp4 --out out/<app>-header.mp4 --placement header
node <skill-dir>/scripts/conform-video.mjs --in out/search.mp4 --out out/<app>-search.mp4 --placement search

各配置には独自のコンポジションと独自のレンダリングが必要です。ヘッダーキャンバスは21:9、検索キャンバスは3:2です — 一方をもう一方にクロップすると、コンポジションが破棄され、被写体がフレームから外れます。コンフォームは解像度、フレームレート、コーデックを修正しますが、間違った形状用に作成されたコンポジションは修正できません。検索コンポジションのルートは data-width="3840" data-height="2560" に設定します。

配置ごとに1つのプロジェクトルート。 ルートコンポジションがキャンバスを宣言するため、2つの配置はルートを共有できません。各配置に独自の index.html とアセットのコピーを持つ独自のプロジェクトフォルダを与えます — check と snapshot はルートのみを参照し、render --composition <file> はスタンドアロンのコンポジションファイルをレンダリングします。

スクリプトは正確なキャンバスにスケーリングおよびクロップし、一定の30または60 fpsを強制し、H.264 yuv420p(アルファなし)でエンコードし、オーディオを除去し、faststart を設定します。また、ソースが小さすぎる場合に警告を表示し、無音のアップスケールを拒否します。

8. 引き渡し前に検証する

node <skill-dir>/scripts/verify-video.mjs out/<app>-header.mp4 --placement header
node <skill-dir>/scripts/verify-video.mjs out/<app>-search.mp4 --placement search

スクリプトは寸法、アスペクト比、フレームレート(一定、正確に30または60)、持続時間、コーデック、ピクセルフォーマット、およびオーディオをチェックします。また、ループシームも判定します:最初のフレームを最後のフレームと、クリップ自身の典型的なフレーム間の動きと比較し、通常のフレームステップよりも乱れの多いラップを視覚的なジャンプとして報告します。両方のフレームの *-seam.png ストリップ画像を書き出し、目視確認できるようにします。終了コード0でなければなりません。 そうでない場合は、コンポジションを修正して再レンダリングします。

次に、ポスターフレームを抽出し、単独で確認します — これは再生開始前にストアが表示する静止画です。キャプションが必要な場合、動画に手直しが必要です。最も強いフレームを選択します。これは必ずしも最初のフレームではありません:

ffmpeg -v error -y -ss 00:00:04.000 -i out/<app>-header.mp4 -frames:v 1 out/<app>-poster.png

選択したタイムコードを報告します。ポスターフレームはアセットライブラリでアセットに設定され、アセットが承認された後は編集できません。そのため、提出前に選択する必要があります。

9. 引き渡し

ユーザーに以下を提供します:

  • 最終ファイルパス(配置ごとに1つ)
  • 検証レポート
  • ポスターフレームとそのフレーム番号
  • 公開手順

クリエイティブアセットは、アップロード、承認、配置という3つの別々のゲートを通過する必要があり、承認だけでは公開されません。references/publishing.md には、正確な asc コマンドを使用した両方のルートが記載されています:

asc asset-library view --app APP_ID                     # ライブラリIDを見つける
asc asset-library videos upload --library-id ID --file ./header.mp4
asc asset-library videos set-poster-frame --id VIDEO_ID --time-code 00:00:04:00
asc localizations list --app APP_ID                     # ローカリゼーションIDを見つける
asc localizations placements create --localization-id LOC --video-id VID \
  --placement-type PRODUCT_PAGE_HEADER_ASSET           # または APP_STORE_SEARCH_RESULTS_ASSET

既に公開されているアプリの場合、App Store Connectでの簡単な手順は次のとおりです:Apps → 該当アプリ → サイドバー → アセットライブラリ → + → クリエイティブアセットをアップロード → 両方のファイルをアップロード → ポスターフレームを設定 → レビュー用に追加 → レビューに提出 → 承認済みを待つ → 公開バージョン → プロダクトページ情報 → 「ヘッダーと検索結果」 → アセットを参照 → アセットを選択 → 次へ → 公開。これにより、新しいバージョンや新しいレビューなしで公開されます。アプリにまだ公開バージョンがない場合は、代わりに次のバージョンにアセットを添付し、それを提出します。

ユーザーに、ヘッダーと検索結果タブのプレビューで結果を確認するよう伝えてください — iPhoneとiPad、向き、言語、ダークモード全体でアセットが表示され、配置によってクロップが異なります。ポスターフレームはアセットが承認された後は編集できないため、提出前に選択してください。

ここで止めてください。アップロード、レビュー提出、公開は自分で実行しないでください。アップロードと公開はユーザーのステップです。

出力契約

  • out/<app>-header.mp4 — 3840x1646、H.264 yuv420p、一定の30または60 fps、5~30秒、アルファなし、オーディオなし、500 MB未満
  • out/<app>-search.mp4 — 3:2、1920×1280~3840×2560の範囲、同じエンコーディングルール
  • すべてのチェックがPASSの検証レポート
  • ポスターフレームとそのタイムコード
  • references/publishing.md からの公開手順を含む短い引き渡しメモ

両方の配置に独自のファイルが必要です。1つのファイルを両方に使用して引き渡さないでください。

失敗処理

症状対処法
ffprobe / ffmpeg が見つからないbrew install ffmpeg(macOS)または choco install ffmpeg(Windows);スクリプトはチェックとコンフォームにこれらを必要とします
HyperFramesがChromeを起動できないnpx hyperframes browser ensure、次に npx hyperframes doctor --json で .ok を確認
レンダリングが遅いと感じる通常は遅くありません。3840x1646、8秒のデリバリーレンダリングはMシリーズMacで約9秒です。本当に遅い場合は、レンダラーにGPUワーカーがあることを確認し、再レンダリングの代わりに hyperframes snapshot フレームでイテレーションします。外観だけが必要な場合は、--quality looks は --quality delivery より高速です
エンコーダがファイルをレベル4.1でタグ付けする両方のキャンバスがレベル4.1のマクロブロック上限を超えています — 3840x1646は24720マクロブロック、1920x1280は9600(上限8192)。-level 5.1 で再エンコードします
シームチェックが失敗する最後のビートを修正して状態がベース状態に戻るようにします。クロスフェード(--seam-crossfade)はフォールバックであり修正ではありません。C秒のコンテンツを消費するからです
サムネイルサイズでテキストが読めない拡大します。アップルはアセットがストア全体で異なって表示されることに注意しています。そのため、最小のレンダリングが実際のテストです
App Store Connectでアップロードが拒否される実際にアップロードされたファイルで verify-video.mjs を再実行します(ローカルのオリジナルではなく)。asc asset-library videos upload はアップロード前にアップルのライブ仕様に対してファイルを検証するため、そのエラーは見落としたルールを指定します
アップルが配置を拒否するスロットが既に占有されている可能性があります — 配置を作成しても既存のものは置き換えられません。asc localizat...(原文が途中で切れています)

関連スキル