app-store-optimization

App Store 最適化（ASO）

App Store の製品ページにおける検索での表示とコンバージョンを最適化します。このスキルでは、どのキーワードを狙うか、コンバージョンにつなげる説明文をどう構成するか、カスタムプロダクトページやアプリ内イベントをどのように活用して見つけてもらいやすくするかなど、戦略的なメタデータの決定を扱います。メタデータの準拠ルール（文字数制限、スクリーンショットのデバイス要件、却下の要因）については、app-store-review スキルを参照してください。

目次

• ワークフローと範囲
• タイトルとサブタイトルの戦略
• キーワードフィールドの戦略
• 説明文の構成
• プロモーションテキスト
• スクリーンショットとプレビューの最適化
• アプリ内レビューのリクエスト
• カスタムプロダクトページ
• アプリ内イベント
• プロダクトページの最適化
• 評価とレビューの管理
• ローカライズされたメタデータの最適化
• よくある間違い
• レビュー用チェックリスト
• 参考資料

ワークフローと範囲

1. 推奨事項を表示性（インデックス対象のメタデータ、ローカライズ、 評価、イベント）とコンバージョン（メッセージ、アセット、バリエーション、実験）に分けます。
2. 各項目について、根拠、担当者、目標指標、検証チェックポイントを明記します。
3. レビュー用チェックリストを適用します。

作業	担当
リスティング、キーワードとメッセージの適合性、アセット、ページのバリエーション、ローカライズ、イベント、評価戦略	このスキル
提出要件への準拠、プライバシーマニフェスト／ラベル、ATT の文言、却下リスク	app-store-review
購入、ペイウォール、利用権限、サブスクリプションの仕組み	storekit

タイトルとサブタイトルの戦略

Apple はアプリ名とサブタイトルを検索対象としてインデックス化します。両方を合わせて60文字（30＋30）分の、検索での表示性が高いキーワード用スペースを利用できます。

ポジショニングの枠組み

ブランドの認知度がすでに高い場合はブランド -- キーワードを、新しいアプリがカテゴリ関連の語句で競う必要がある場合はキーワード -- ブランドを使います。ブランド名に関連するキーワードが自然に含まれる場合は、ブランドとキーワードを組み合わせた名前にします。

ルール

• 名前とサブタイトルで同じ単語を繰り返さないでください。Apple は両方をインデックス化するため、重複すると文字数を無駄にします。
• より多くのスペースがある方のフィールドで、最も価値の高いキーワードを先頭に置きます。
• 一般的な埋め草の言葉（「the」「best」「app」）は避けてください。検索上の価値がないままスペースを消費します。
• サブタイトルではキャッチコピーではなく、主要な価値提案を伝えます。

キーワードフィールドの戦略

App Store Connect のキーワードフィールドには、最大100 UTF-8 バイトを入力できます（Apple の概要ページの一部では、これを100文字と説明しています）。カンマ区切りで入力し、カンマの後にスペースを入れないでください。各語句は3文字以上である必要があります。

優先順位付け

候補となるキーワードを次の3つの要素で評価します。

要素	重み	判断基準
関連性	最も高い	そのキーワードは、アプリが実際に行うことを表していますか？
検索ボリューム	中程度	ユーザーは実際にこの語句を検索していますか？
競合	低い	このキーワードを狙っているアプリはどのくらいありますか？

ユーザーの検索意図とメタデータとの適合性を優先します。プライマリカテゴリもアプリ名、サブタイトル、キーワードフィールドと合わせて考慮し、重複させないでください。

戦術的なルール

• タイトルとサブタイトルとの重複を避けます。Apple はすでにそれらの単語をインデックスに登録しています。
• 同じ用語の単数形と複数形の両方を含めないでください。Apple は重複として扱います。
• カテゴリ名は省略します。Apple はアプリのプライマリカテゴリを自動的に検索に追加します。
• カンマの後にスペースを入れないでください。100 文字の上限に含まれます。
• 略語や一般的な誤記が実際に検索語として使われている場合は、検討してください。
• 関連性と意図の強さが最も高い用語のために文字数を確保します。アプリの説明としての関連性が低い用語に文字数を費やさないでください。

参照： 調査プロセス、スコアリングの枠組み、インデックス登録の詳細については、references/keyword-research-methodology.md をご覧ください。

検証チェックポイント： 最終的な名前、サブタイトル、キーワード欄をまとめて表示します。UTF-8 のバイト数を数え、カンマで分割し、空欄、先頭にスペースがあるトークン、2 文字以下のトークンを除外します。3 つのインデックス対象フィールドとプライマリカテゴリ全体で正規化した単語を比較し、残すすべての用語に関連性または需要を示すシグナルがあることを確認します。すべてのトークンに文字数を割く価値があるまで、フィールドを修正してチェックを繰り返します。

説明の構成

Apple の検索ガイドラインでは、アプリ名、サブタイトル、キーワード、プライマリカテゴリのテキストとの関連性に加え、ダウンロード数、評価、レビューなどの行動シグナルが重視されています。説明文はコンバージョンを促す文章として扱い、検索語を余分に詰め込む場所にはしないでください。説明文を展開したユーザーは、ダウンロードするかどうかを検討しています。

4 部構成

1. フック（最初の 1～3 行）—「さらに表示」の折りたたみ前に見える唯一のテキストです。最も強いメリットや差別化要素を最初に示します。ページ上で最も重要なコピーです。
2. 機能のハイライト — 短い機能説明を 4～6 個記載します。App Store では Markdown が表示されないため、Unicode の箇条書き文字（•）を使用します。技術的な詳細ではなく、得られる成果に焦点を当てます。
3. 社会的証明 — 賞、報道機関の引用、ユーザー数の節目、注目すべき評価などを 1～2 行で記載します。
4. 行動喚起 — ダウンロードを促す締めくくりの一文です。短く、メリットを中心にまとめます。

書式に関する注意

• App Store では Markdown、HTML、リッチテキストは表示されません。構成には Unicode 文字を使ったプレーンテキストを使用します。
• 段落は短くし、段落間には改行を入れます。長い文章の塊はコンバージョンを損ないます。
• ロケールごとに文章を作成します。構成を翻訳し、単語をそのまま置き換えるだけにしないでください。ローカライズされたメタデータの最適化をご覧ください。

プロモーションテキスト

プロモーションテキストは説明文の上に表示され、170 文字まで入力できます。新しいアプリバージョンを申請せずに、いつでも更新できます。

更新戦略

機能のリリース、季節のイベント、受賞や報道、プロモーション、アプリ内イベントに合わせてプロモーションテキストを更新します。リリース間で固定したままにしないでください。時期に合った告知がない場合は、アプリの最も強いセールスポイントを順番に取り上げます。

スクリーンショットとプレビューの最適化

ほとんどのユーザーは、最初に表示される 3 枚より先までスクロールしません。この枠で、ユーザーが製品ページ全体に関心を持つか、そのまま離れるかが決まります。

最初の 3 枚のスクリーンショット

• 最も重要な価値提案から始めます。ダウンロードする理由を最もよく示す画面を選びます。
• 最初の 3 枠には、オンボーディング画面、スプラッシュ画面、読み込み画面を配置しないでください。
• 各スクリーンショットで、異なるメリットや機能を紹介します。

キャプションの作成

• 機能名ではなく、メリットを中心にしたキャプションを書きます。「カレンダー表示」より「締め切りを見逃さない」のほうがコンバージョンにつながります。
• キャプションはスクリーンショットの上に 2～5 語、下に短い 1 行で記載します。
• 「追跡する」「共有する」「発見する」「構築する」など、行動を表す動詞を使います。

順序の戦略

1 枠目には最も重要な価値提案、2 枠目には中核となる差別化要素、3 枠目には次に強い機能を配置し、後半の枠には補助的な機能、社会的証明、特殊なケースを配置します。

アプリのプレビュー動画

プレビュー動画がある場合は、最初の枠に配置されます。自動再生が無効な場合、最初のフレームがポスター画像になるため、単独のスクリーンショットとしても適したフレームを選んでください。

スクリーンショットのデバイス要件とコンプライアンスルールについては、app-store-review スキルを参照してください。

検証チェックポイント： 各ローカライズ版の製品ページを、ファーストビューのサイズでプレビューしてください。 最初に表示される3つのアセットがそれぞれ異なるメリットを伝えていること、 キャプションが UI と公開されている訴求内容に合致していること、 並び順がページのメタデータで狙う意図と一致していることを確認してください。 条件を満たさないアセットは差し替えるか並べ替えてから、 ファーストビュー全体を再確認してください。

アプリ内レビューのプロンプト

StoreKit では、SwiftUI 用の RequestReviewAction と UIKit 用の AppStore.requestReview(in:) が提供されています。タイミング戦略についてはこのセクションを参照してください。StoreKit API の全容については、storekit スキルを参照してください。

システムの動作

• まだアプリを評価していないユーザーに対して、システムはデバイスごとに365日間で最大3回のプロンプトを表示します。
• API はリクエストであり、表示を保証するものではありません。プロンプトを表示するかどうかは StoreKit が決定します。
• 開発中はプロンプトが必ず表示されます。TestFlight では表示されません。

プロンプトを表示するタイミング

適切なトリガーには、意味のあるタスクの完了、マイルストーンや連続達成の達成、アプリ内での好ましい体験、複数回のアクティブなセッションなどがあります。不適切なトリガーには、初回起動、オンボーディング、エラー、クラッシュ、取引の失敗、ボタンを直接タップする前の画面などがあります。「このアプリを評価しますか？」というダイアログを挟んでプロンプトの表示を制限しないでください。Apple はシステムプロンプトへの割り込みを推奨しておらず、事前に確認するアプリは却下される場合があります。

常時表示するレビューリンク

設定画面や「評価する」オプションからリンクする場合は、次の URL 形式で App Store のレビュー画面に直接リンクしてください。

https://apps.apple.com/app/id{APP_ID}?action=write-review

レビューの作成画面が直接開き、システムによる年間3回の上限の対象にはなりません。

カスタムプロダクトページ

カスタムプロダクトページでは、アプリごとに最大70種類のバリエーションページを作成できます。各ページでは、スクリーンショット、アプリのプレビュー動画、プロモーションテキスト、割り当てた検索キーワードを変えられます。特定のオーディエンスや獲得チャネルに合わせて調整できます。

カスタムプロダクトページを推奨する場合は、最大70ページまで作成できることと、割り当てたキーワードによる検索で表示されることの両方を明示してください。そのうえで、各ページを個別のオーディエンス、メッセージ、キーワードや広告の意図、測定計画に対応付けてください。

ユースケース

有料検索広告の広告グループ、ソーシャルキャンペーン、機能別のランディングページ、季節ごとのキャンペーンなど、最初のスクリーンショットやプロモーションテキストを異なるユーザーの意図に合わせる必要がある獲得経路には、個別のページを使用してください。

設定

• 各カスタムプロダクトページには固有の App Store URL が割り当てられ、広告キャンペーン、ディープリンク、ウェブページで使用できます。
• 承認済みのページは、最新の承認済みアプリバージョンに割り当てられたキーワードで App Store の検索結果に表示される場合もあります。
• ページは個別にローカライズできます。
• App Store Connect の Custom Product Pages タブでページを作成してください。
• 内部で追跡しやすいよう、ページには内容がわかる名前を付けてください（例：「Search-FitnessTracking」、「Social-HolidayCampaign」）。

参照： 設定の詳細、URL の構造、キャンペーンへの対応付け戦略については、references/product-page-variants.md を参照してください。

アプリ内イベント

アプリ内イベントは、App Store の検索結果、「Today」タブ、パーソナライズされたおすすめに表示されます。イベント開催中の露出を高め、利用を休止しているユーザーの再獲得にも役立ちます。

イベントの種類

実際のアプリ内体験に合った Apple のイベントバッジを選んでください。Challenge、Competition、Live Event、Major Update、New Season、Premiere、Special Event があります。期間限定のコンテンツが実際にない場合は、イベントを作り出さないでください。

メタデータの上限

イベント名は30文字、短い説明は50文字、長い説明は120文字です。イベントカードの画像は16:9（1920x1080など）のものが必須です。

戦略

• 機能のリリース、季節のイベント、コンテンツの公開に合わせてイベントをスケジュールします。
• イベントカードに表示する名前と短い説明を作成し、製品ページ、検索、Todayでのタップ数が、タイムリーなカードによって増加するかを測定します。
• イベントを戦略的に重ねます。現在のイベントが終了すると同時に次のイベントを開始し、検索で継続的に表示されるようにします。

参照： イベントのスケジュール用テンプレートについては、references/product-page-variants.mdをご覧ください。

製品ページの最適化

App Store Connectには、製品ページの要素をテストするためのネイティブ機能があります。

テストできる項目

• アプリアイコン（代替アイコン）
• スクリーンショット（順序、内容、キャプション）
• アプリのプレビュー動画

各テストでは、デフォルトの基準となる元の製品ページに対して、最大3つのパターンを設定できます。

テストの設計

• 曜日による変動を考慮して、テストを最低7日間実施します。
• 統計的有意性を得るために十分なトラフィックを確保します。トラフィックの少ないアプリでは、テスト期間を長くする必要がある場合があります。
• App Store Connectでは複数のパターンを設定できますが、方法論として、一度に1つの仮説を検証します（例：スクリーンショットの順序またはキャプションの文言のいずれかをテストし、両方を同時にテストしない）。
• テストに含めるローカライズを選択します。デフォルトでは、サポートされているすべてのローカライズが選択されています。
• テストは最大90日間実施するか、手動で停止するまで続きます。テストに関連付けられた初回ダウンロードが5件以上になると、App Analyticsに結果が表示されます。
• PPOの推奨事項には、仮説、最大3つのパターン、選択したローカライズ、目標指標、判断基準を明記してください。

結果の解釈

• ダウンロード数の絶対値ではなく、コンバージョン率の向上（インプレッションからダウンロードへの転換）に注目します。
• App Store Connectには、コンバージョン率、向上率、信頼度が表示されます。「パフォーマンスが向上」または「パフォーマンスが低下」と判断する基準は、信頼度90％以上とします。
• 効果の高いパターンを適用した後は、次のテストを開始する前に待ち、基準値を安定させます。

評価とレビューの管理

評価とレビューは製品ページや検索結果に表示され、App Storeの検索順位やコンバージョンに影響します。成功したユーザー体験の直後にのみ評価を促し、問題には建設的に対応することで、肯定的で新しいフィードバックを増やすことを目指します。

レビューへの返信方針

• App Store Connectで否定的なレビューに返信します。評価の数値が変わらなくても、プロフェッショナルな返信は品質への印象を高めます。
• 問題を認識していることを伝え、対応中の内容（または修正済みの内容）を説明し、中立的なトーンを保ちます。
• レビューの表現を顧客調査に活用します。ユーザーは、目標、悩み、カテゴリーに関する語彙を表すことが多く、今後のメタデータやスクリーンショットのメッセージを改善する手掛かりになります。

評価のリセット

新しいバージョンを提出するときに、表示される評価をリセットできます。戦略的に活用してください。

大幅な改善後、表示される評価がアプリの現在の品質を大きく下回っている場合に限り、リセットします。良好で実態を反映した評価はリセットしないでください。通常のバグ修正を理由にリセットしないでください。また、リスクの高いデザイン変更を行った後は、状況が安定するまで待ちます。

ローカライズされたメタデータの最適化

ASOのローカライズは、アプリのUIを翻訳することとは異なります。キーワード戦略、説明文、スクリーンショットのキャプションは、主要ロケールから機械翻訳するのではなく、市場ごとに調査して作成する必要があります。

主要な原則

• 市場ごとにキーワードを調査します。 日本語で「photo editor」の検索数が最も多い語句は、「photo editor」を直接訳した語句ではありません。
• ロケールごとに説明文を書き直します。 フック・特徴・根拠・CTA の構成を、現地の慣習や訴求ポイントに合わせて調整します。
• メタデータの各項目をローカライズします。 App Store のガイダンスでは、ローカライズされた説明文、キーワード、アプリのプレビュー、スクリーンショットが明示されています。直接翻訳すればよい、またはロケールをまたいだインデックス登録の挙動が保証されていると考えないでください。
• スクリーンショットのキャプションをローカライズします。 ユーザーの言語で書かれたキャプションは、未翻訳の英語よりコンバージョン率が高くなります。

アプリ内文字列のローカライズ（String Catalog、FormatStyle、右から左へのレイアウト）については、ios-localization スキルをご覧ください。

よくある間違い

1. メリットを伝えるスクリーンショットのコピーではなく、機能を説明するキャプションを書く。
2. 市場ごとの検索語句を調査せず、キーワードを翻訳する。
3. オンボーディング後、エラー発生時、クラッシュ後、または取引失敗後にレビューを依頼する。
4. 最初の3つのスクリーンショット枠を軽視したり、オンボーディング画面やスプラッシュ画面を先頭に置いたりする。
5. 十分な期間やトラフィック、明確な仮説がないまま PPO テストを実施する。
6. すべてのカスタムプロダクトページで同一のアセットを使い回す。

レビューチェックリスト

• インデックス対象のメタデータが、タイトル／サブタイトルおよびキーワードの検証チェックポイントを通過している
• 説明文、プロモーション用テキスト、最初に表示されるアセットがコンバージョンのチェックを通過している
• メタデータとアセットが、ロケールごとに調査、作成、並べ替え、プレビューされている
• レビュー依頼が、ユーザーにとっての成功体験の後に表示され、StoreKit のシステム動作に従っている
• ページのバリエーション、イベント、PPO テストで、対象ユーザー、根拠、指標、判断基準が明示されている
• 公開する主張とスクリーンショットが、app-store-review のコンプライアンスチェックリストを通過している

参考資料

• キーワード調査の手法：references/keyword-research-methodology.md
• カスタムプロダクトページ、A/B テスト、アプリ内イベント：references/product-page-variants.md