aso-marketing

ASO マーケティング — アプリストア最適化の全ライフサイクル

Apple App Store と Google Play Store の両方を対象に、分析から計画、実行、検証、レポート作成まで、モバイルアプリの ASO を一貫して進める包括的で反復的なワークフローです。

環境の確認

このスキルを実行する前に、以下を確認してください。

• プロジェクトがモバイルアプリ（iOS、Android、または両方）であること
• アプリのソースコードまたはメタデータファイルにアクセスできること
• プロジェクトの設定ファイル（build.gradle、Info.plist など）を読み取れること
• プロジェクトディレクトリ内のメタデータファイルを作成・更新できること

いずれかの確認に失敗した場合は、作業を中止してユーザーに確認してください。

編集前のリポジトリ同期（必須）

既存のリポジトリ内でファイルを作成、更新、または削除する前に、現在のブランチをリモートと同期してください。まずドライランコマンドを実行してプレビューし、その後、破壊的な同期を行う前にユーザーの確認を得てください。

# Dry-run preview first
git fetch --dry-run origin
git status

# Then sync (after user confirms working tree is clean or backed up)
branch="$(git rev-parse --abbrev-ref HEAD)"
git fetch origin
git pull --rebase origin "$branch"

作業ツリーがクリーンでない場合は、stash する前にユーザーに確認してください。origin が存在しない場合、pull を実行できない場合、または rebase／stash の競合が発生した場合は、作業を中止して、続行する前にユーザーに確認してください。

**メタデータファイルのバックアップ優先ルール：**既存のメタデータファイル（例：metadata/version/1.0/en-US.json、fastlane/metadata/android/en-US/title.txt）を上書きする前に、同じディレクトリに .bak コピーを作成するか、そのファイルがバージョン管理されていることを確認してください。ユーザーの明示的な確認なしにメタデータファイルを削除しないでください。

サブエージェント構成

このスキルでは、ステージ式パイプライン＋レビューサイクル構成を採用しています。各フェーズは agents/ 内のサブエージェントに対応します。

1. agents/analyzer.md — フェーズ 1 の分析レポート
2. agents/plan-writer.md — フェーズ 2 の ASO 計画
3. agents/compliance-checker.md — フェーズ 3 の禁止キーワード＋商標チェック
4. agents/executor.md — フェーズ 4 のメタデータ変更
5. agents/reviewer.md — フェーズ 5〜6 のレビュー＋ベストプラクティス検証

メインエージェントがフェーズ間の移行と、フェーズ 3 後のユーザー承認ゲートを統括します。

ワークフローの概要

このスキルは 7 フェーズのサイクルに従います。ポリシー準拠チェックや計画承認ゲートを決して省略しないでください。実行を開始する前に、ユーザーがポリシーに準拠した計画を承認する必要があります。

Phase 1: Analyze → Phase 2: Plan → Phase 3: Policy Compliance Check
  → [User Approval Gate] → Phase 4: Execute → Phase 5: Review
  → Phase 6: Verify → Phase 7: Summarize

開始前に

1. ASO に関する知識を網羅した references/aso_best_practices.md を読みます。特に、Apple と Google の両方における禁止キーワード、商標規則、掲載ポリシーの制限を詳述した「ストアポリシーへの準拠」セクションを必ず確認してください。
2. ユーザーが最適化を希望するストアを特定します。
3. ユーザーが既存のメタデータファイルや公開中のストア掲載情報を持っているか、それとも新規に公開するのかを確認します。

フェーズの実行

各フェーズを順番に実行します。詳細な手順、テンプレート、チェックリストは参照ファイルに記載されています。コンテキストウィンドウを小さく保つため、各フェーズを実行する直前に、そのフェーズの参照ファイルを読んでください。

フェーズ 1：分析

references/phases-1-2.md のフェーズ 1 のセクションを読みます。コードベースの情報を収集し、既存のストアメタデータを監査し、競合他社を特定し、ベースラインのパフォーマンスを把握して、分析レポートを作成します。

フェーズ 2：計画

references/phases-1-2.md のフェーズ 2 のセクションを読みます。目標、ターゲットキーワード（主要／副次／ロングテール）、メタデータの最適化（タイトル、サブタイトル、キーワード、説明、「新機能」）、ビジュアルアセット、ローカライズ、評価戦略、スケジュールを網羅した優先順位付きの計画を作成します。

フェーズ 3：ポリシー準拠チェック

references/phase-3-compliance.md を読みます。提案する各メタデータ項目について、以下の基準に照らして検証します。

• 禁止キーワードのリスト（Apple＋Google）
• 商標および競合他社のブランドチェック
• 書式ルール（絵文字禁止、すべて大文字の表記禁止、文字数制限）
• コンテンツの正確性

違反が見つかった場合は、計画をユーザーに知らせずに修正し、準拠チェックを再実行してください。ユーザーに提示する計画は、常に準拠したものでなければなりません。

ユーザー承認ゲート

準拠チェックに合格した後、計画と準拠レポートをユーザーに提示します。**ユーザーが計画を明示的に承認するまで、フェーズ 4 に進まないでください。**必要に応じて何度でも調整してください。修正のたびに準拠チェックに合格する必要があります。

フェーズ 4：実行

references/phases-4-7.md（フェーズ 4 のセクション）を読みます。承認された変更を優先順位に従って体系的に実装します。**既存のメタデータファイルを上書きする前に、.bak バックアップを作成するか、バージョン管理で保護されていることを確認してください。**編集のたびに文字数制限を検証します。

フェーズ 5：レビュー

references/phases-4-7.md（フェーズ 5 のセクション）を読みます。変更したすべてのフィールドにレビュー用チェックリストを適用します。禁止キーワードと商標の漏れがないか再スキャンします。

フェーズ 6：ベストプラクティスに照らして検証

references/phases-4-7.md（フェーズ 6 のセクション）を読み、references/aso_best_practices.mdと照合します。最後に、ポリシーへの準拠を確認します。

フェーズ 7：要約

references/phases-4-7.md（フェーズ 7 のセクション）を読みます。最終サマリーレポート（Changes Made、Metadata Comparison、Compliance Status、Expected Outcomes、Next Steps、Files Modified）を作成します。

ステップ完了レポート

実行ごとにレポートを正確に 5 件出力します。分母 M は常に 5 です。対象はフェーズ 1、フェーズ 2～3、フェーズ 4、フェーズ 5～6、フェーズ 7 です。各レポートでは、合格に √、不合格に × のマーカーを使用します。形式とフェーズごとのチェックリストは、references/edge-cases.md（ステップ完了レポートのセクション）に記載されています。

想定される出力

完全な実行では、3 つの成果物が生成されます。分析レポート（フェーズ 1）、ASO 計画＋コンプライアンスレポート＋更新済みメタデータファイル（フェーズ 2～4）、およびサマリーレポート（フェーズ 7）です。それぞれの具体例は、references/expected-output.mdを参照してください。実行の最後に最終レポートを出力します。

最終レポート

ステップ完了レポートの後に、4 行の Result／Evidence／Uncertainty／Decision ブロックを記載して、すべての実行（停止した場合を含む）を終えます。このブロックはフェーズ 7 のサマリーレポートの代わりにはなりません。Result: の後の最初の語は、COMPLETE（該当するすべての合格基準項目にチェックが付いている場合）、PARTIAL（分析レポートは存在するものの、未チェックの項目がある場合。たとえば、ユーザーが計画を承認しなかった場合）、または BLOCKED（分析レポートがない場合）です。ステータステーブル、例、記入ルールについては、references/final-report.mdを参照してください。

例

入力：メタデータが不十分な iOS＋Android の生産性アプリ。

Title (iOS): FocusFlow: Work Timer            (21/30, no primary keyword)
Keywords (iOS): timer,focus,work,productivity (29/100, 71 chars unused)
Short Desc (Android): A simple timer for focused work. (32/80, weak)

フェーズ 4 の出力（metadata/app-info/en-US.json）：

{
  "name": "FocusFlow: Focus & Work Timer",
  "subtitle": "Deep Work Sessions & Tracking"
}

キーワードフィールドの出力：

pomodoro,concentration,study,productivity,distraction,blocker,habit,goal,task,routine,break,planner

（99/100 文字。禁止語はすべて除外され、タイトルやサブタイトルと重複する単語はありません。）詳しい手順は、references/expected-output.mdを参照してください。

合格基準

メタデータがすべて文字数制限内に収まり、禁止キーワードや商標が含まれておらず、ユーザー承認ゲートが守られ、必要なレポートがすべて作成された場合、スキルの実行は成功です。合格基準の全項目については、references/edge-cases.md（合格基準のセクション）を参照してください。最終レポートは、references/final-report.mdに記載された 4 つの読者確認項目も満たす必要があります。人間のレビュー担当者からの回答がない場合、人間が内容を理解したかどうかは未確認です。

エッジケース

一般的なエッジケース（ローカルにメタデータファイルがない、単一プラットフォームのアプリ、競合にアクセスできない、リリース前のアプリ、主要ロケールが英語以外、ユーザーが計画を拒否、草案のコンプライアンス違反）は、references/edge-cases.mdに記載されています。該当するエッジケースがある場合は、そのファイルを読み、独自の判断で対応しないでください。

プラットフォーム固有の注意事項

Apple App Store、Google Play Store、および複数ストアに共通する慣例（インデックス対象フィールド、文字数制限、OCR でインデックスされるスクリーンショット、A/B テストの掲載枠）については、references/edge-cases.md（プラットフォーム固有の注意事項のセクション）に記載されています。

スキル間の連携

このスキルはseo-ai-optimizerを補完します。どのような場合に組み合わせるかについては、references/edge-cases.md（スキル間の連携のセクション）を参照してください。

安全性と注意事項

• 確認なしに破壊的な操作を行わないでください。 git pull --rebase の前に、Repo Sync でドライランのプレビューを実行し、ユーザーの確認を得てください。git stash やファイルの削除を行う前に、ユーザーに確認してください。既存のメタデータファイルを上書きする前に、.bak バックアップを作成するか、そのファイルがバージョン管理の対象であることを確認してください。すべての失敗やエラーをユーザーに報告し、黙って再試行しないでください。
• コンプライアンスの審査は必須です。 コンプライアンスに準拠していない計画をユーザーに提示してはならず、明示的な承認なしに実行してはなりません。
• 商標に関する注意： フェーズ 1 の分析で挙げた競合他社のブランド名を、提案するメタデータに含めてはなりません。