mcpField
A
app-marketing-copy

app-marketing-copy

github.com/ckorhonenマーケティング・グロース2279 回インストール5 週間前に更新
リポジトリ

app-marketing-copy について

アプリチーム向けに、ストア掲載文やマーケティングコピーを作成するスキルです。要件の聞き取りから複数案の作成、媒体別の成果物、長さ・一貫性・コンプライアンス・読みやすさの確認まで扱います。

主な機能

  1. 01対象ユーザーと製品情報の確認
  2. 02iOS・Google Play向け掲載文
  3. 03マーケティング・スクリーンショット用コピー
  4. 04複数案と推奨案の提示
  5. 05文字数と品質のチェック

活用シーン

  1. 01新しいアプリストア掲載文の作成
  2. 02一般的またはキーワード過多な文面の改稿
  3. 03複数プラットフォーム向けローンチ準備

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ckorhonen/claude-skills --skill app-marketing-copy

インストール後、Claude Code で/app-marketing-copyを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
app-store-metadata.md
screenshot-prompts.md
scripts/
check_app_store_limits.py

詳細

アプリのマーケティングコピー

クイックスタート

  1. 不足している情報を尋ねます(または、リポジトリや製品のドキュメントから推測します)。
  • アプリ名+1文で表す価値提案
  • ターゲットユーザー+主な達成したいこと
  • 主な機能3~7個+差別化要因1~3個
  • 希望するトーン(および使用する/避ける言葉)
  • プラットフォーム:iOS App Store、Google Play、または両方
  • スクリーンショットの枚数とテーマ(必要な場合)
  1. 納品物を確認します。
  • ストア掲載情報(iOS、Google Play)
  • マーケティングパック(ランディングページのヒーローセクション、機能紹介文、CTA、広告)
  • スクリーンショットパック(キャプション文+画像生成プロンプト)
  1. 重要度の高い項目ごとに2~3案を作成し、1文の理由を添えて「おすすめ案」を提示します。

例

例 1:新しい App Store 掲載情報

ユーザー入力:

App: FocusTimer
Purpose: Pomodoro timer for students
Key features: Custom intervals, study stats, break reminders
Platform: iOS App Store
Tone: Friendly but not childish

ワークフロー:

  1. 受付時の質問を行い、不足している詳細を確認する
  2. サブタイトルを3案作成し、おすすめ案を提示する
  3. 学生の生産性向上に関する検索に最適化したキーワードセットを作成する
  4. 機能を箇条書きに含めた詳細な説明文を作成する
  5. ストーリーの流れに沿ったスクリーンショット用キャプションを5つ作成する
  6. scripts/check_app_store_limits.py で検証する

期待される出力:

  • iOS App Store 掲載情報(すべての項目が文字数制限内)
  • サブタイトル案3つとその理由
  • キーワードセット(最大100文字)
  • スクリーンショット用コピー一式
例 2:マーケティングコピーの刷新

ユーザー入力:

"Our app store listing conversion is terrible. Help refresh it."
App: PhotoFix (photo editing)
Current problem: Generic copy, keyword-stuffed

ワークフロー:

  1. 現在の掲載情報を確認する(提供されている場合)
  2. 「PhotoFixが競合製品と異なる点は何ですか?」と尋ねる
  3. ASOキーワードの詰め込みに関する問題を特定する
  4. 新しいサブタイトルを3案作成する(具体的で、メリットを重視)
  5. 詳細な説明文をユーザーにとってのメリット中心に書き直す(技術仕様ではなく)
  6. 新しいスクリーンショット用キャプションを作成する
  7. 変更前後の文字数を比較する

期待される出力:

  • 具体性を高めた掲載情報
  • 改善点を示す変更前後の比較
  • 各変更の理由
例 3:複数プラットフォームでのローンチ

ユーザー入力:

Launching on both iOS and Google Play
App: TaskFlow (project management for freelancers)
Need everything: store listings, landing page copy, ads

ワークフロー:

  1. 受付を完了する(対象者、差別化要因、裏付けとなる情報)
  2. iOS の掲載情報を作成する(サブタイトル、キーワード、説明文)
  3. Google Play の掲載情報を作成する(短い説明、機能の箇条書き、詳細な説明)
  4. マーケティングパックを作成する(キャッチコピー10案、ヒーローセクション3案、機能紹介文6案、CTA10案)
  5. スクリーンショット用コピー一式を作成する(キャプション8つ+画像プロンプト)
  6. scripts/check_app_store_limits.py ですべてを検証する

期待される出力:

  • iOS App Store の掲載情報一式
  • Google Play の掲載情報一式
  • マーケティングコピー一式(成果物50点以上)
  • ストーリーの流れに沿ったスクリーンショットパック

受付テンプレート(質問してから進める)

  • 対象者:誰が、何を求めているか
  • 課題:現在、何が難しいのか
  • 成果:「成功」がどのような状態か
  • 差別化要因:代替手段ではなく、これを選ぶ理由
  • 裏付け:数値、レビュー、受賞歴、報道(あれば)
  • 制約:避けるべき主張、法務/コンプライアンス上の注意、価格への言及方針
  • ロケール:特に指定がなければ米国英語を既定とする

出力

iOS App Store の掲載情報
  • 提供するもの:アプリ名の候補、サブタイトルの候補、プロモーションテキスト、キーワードセット、詳細な説明文、「新機能」(リリースノート)。
  • 各項目の文字数制限を遵守します。不明な場合は references/app-store-metadata.md を開くか、scripts/check_app_store_limits.py を実行してください。
Google Play の掲載情報
  • 提供するもの:タイトルの候補、短い説明の候補、詳細な説明文、機能の箇条書き、リリースノート。
  • 文字数制限を遵守します。references/app-store-metadata.md または scripts/check_app_store_limits.py を参照してください。
マーケティングコピー一式
  • 提供するもの:キャッチコピー5~10案、ヒーローセクション3案(見出し+サブ見出し+CTA)、機能紹介文6案(各1~2文)、マイクロCTA10案、短い広告フック10案、ソーシャル投稿5案。
  • 裏付け可能な主張にとどめ、証明できない限り「#1/最高」は避けてください。
スクリーンショットパック(コピー+プロンプト)
  • スクリーンショット用キャプションを5~8個(各2~5語)と、必要に応じてサブキャプションを用意します。ストーリーの順序(導入→価値→裏付け→CTA)も含めてください。
  • 各スクリーンショットのアートディレクションと、ユーザーのツールに合わせたテキスト画像生成用プロンプトテンプレート(背景/イラスト)を用意します。
  • プロンプトのパターンとネガティブプロンプトには references/screenshot-prompts.md を使用してください。

品質チェック(最終確認の前に実施)

  • 文字数制限:ストアの各フィールドについて、scripts/check_app_store_limits.py --platform ios --input draft.json(または --platform google_play)で検証します。
  • 一貫性:タイトル/サブタイトル/ヒーロー画像/スクリーンショット 1 で、同じ中核的な価値提案を維持します。
  • コンプライアンス:禁止されている主張、競合他社の商標、センシティブなターゲティングは避けます。規制対象分野(医療/金融/子ども向け)の場合は確認してください。
  • 読みやすさ:短い文を使い、能動態で書き、箇条書きを見やすくします。

よくある落とし穴

1. ASO キーワードの詰め込み(不自然で、コンバージョンを損なう)

問題: タイトル、サブタイトル、説明文にキーワードを詰め込むと、文章が機械的になり、コンバージョン率が下がります。App Store のアルゴリズムは、ユーザーエンゲージメント指標に基づいて、キーワードを詰め込んだ文章の評価を下げます。

❌ 悪い例(iOS サブタイトル):

Photo Editor Photo Filter Photo Effects Photo Editor App

✅ 良い例(iOS サブタイトル):

Professional photo editing

うまくいかない理由:

  • 悪い例では「Photo」が 4 回、「Editor」が 2 回繰り返され、アルゴリズムにもユーザーにもスパムだと受け取られます
  • 不自然な文章になり、信頼性に欠ける印象を与えるアプリは敬遠されます
  • App Store では、キーワードを詰め込んだ文章より、キーワードを自然に盛り込んだ文章のほうがランキングの評価が高くなります

代わりに行うこと:

  • 各キーワードは文脈の中で自然に 1 回だけ使います
  • キーワードの密度より、読みやすさとユーザーにとってのメリットを優先します
  • 文章の流れを妨げない別々のフィールド(キーワードセット、詳細な説明文)にキーワードを配置します
  • 効果的な例:「Photo Editor-Professional Effects, Simplified」(キーワード:photo editor、effects。自然な文章になっています)

2. 汎用的な価値提案(どのアプリにも当てはまる)

問題: 「速い」「簡単」「シンプル」「最高」といった曖昧な約束では差別化できず、ユーザーの不信感を招きます。具体性がなければ、ユーザーはアプリが自分の課題を解決できるか判断できません。

❌ 悪い例:

- "The easiest way to edit photos"
- "Powerful and intuitive design tool"
- "Professional-grade app for everyone"
- "The best photo editor on the market"

✅ 良い例(具体的):

- "One-click background removal-no manual selection needed"
- "AI-powered portrait retouching in 3 taps"
- "Batch edit 100 photos with one template"
- "Remove objects from photos—no expensive subscriptions needed"

重要な理由:

  • 汎用的な表現は 50 以上の競合にも当てはまるため、ユーザーに読み飛ばされます
  • 具体的な主張は、ユーザーのワークフローを理解していることを伝えます
  • 具体性は信頼性につながり、曖昧さはグリーンウォッシングにつながります

代わりに行うこと:

  • 成果+仕組みを最初に示します:「2 秒で背景を自動削除」(「速い」ではなく)
  • ユーザーが達成したい作業を示します:「写真 100 枚を一括編集」(「高機能」ではなく)
  • 現状との違いを明確にします:「月額 20 ドルのサブスクリプション不要」(「お手頃」ではなく)
  • ユーザーのワークフローを具体的に示します:「LinkedIn 用のプロフィール写真をレタッチ」(「プロ仕様」ではなく)

3. ストア掲載文の文字数制限違反(ストアページで途中までしか表示されない)

問題: フィールドの制限を超える文章は文の途中で切れてしまい、メッセージが伝わらず、ユーザーを混乱させます。プラットフォームによって切り詰められる文字数は異なり、モバイルではデスクトップより表示される文字数が少なくなります。

プラットフォームの制限(必ず守ること):

フィールドiOSGoogle Playモバイルでの表示
サブタイトル30 文字N/A✂️ すべてのデバイスで 30 文字で切り詰め
短い説明文N/A80 文字✂️ モバイルでは 50 文字で切り詰め
特徴の箇条書きN/A各 80 文字✂️ モバイルでは 50 文字で切り詰め
プロモーションテキスト170 文字N/A✂️ モバイルでは 85 文字で切り詰め

❌ 悪い例(iOS サブタイトル:42 文字、30 文字制限を超過):

Professional photo editing, now simplified

表示例:「Professional photo editing, now si...」(単語の途中で切り詰め)

✅ 良い例(iOS サブタイトル:26 文字、制限内に収まる):

Professional photo editing

❌ 悪い例(Google Play の特徴の箇条書き:93 文字、80 文字制限を超過):

Automatically remove backgrounds from any photo without manual selection or complicated tools

表示例:「Automatically remove backgrounds from any photo without manual selection or...」(内容が完結しない)

✅ 良い例(Google Play の特徴の箇条書き:61 文字、余裕をもって収まる):

Auto-remove backgrounds in seconds—no manual selection needed

代わりに行うこと:

  • 最終確認の前に、必ず scripts/check_app_store_limits.py で文章をチェックします
  • 簡潔に書き、不要な語(a、the、very、really、just)を避けます
  • 最初の 50 文字を優先します。モバイルではそれ以降が表示されない場合があります
  • 文字数を節約しながら文体を保つため、短縮形(don't、it's)を使います

4. ユーザーのメリットではなく、技術仕様になっている箇条書き

問題: 得られる成果ではなく技術的な機能を列挙すると、アプリで何ができるのかユーザーに伝わりにくくなります。ユーザーが購入するのは仕様ではなく、結果です。

❌ 悪い例(技術仕様):

- Advanced color grading engine with 256-bit processing
- Support for RAW file formats (CR2, NEF, DNG)
- Multi-threaded rendering with GPU acceleration
- Compatible with iOS 14.0+ and requires 2GB RAM

✅ 良い例(ユーザーのメリット):

- Make any photo look professional in one tap
- Edit RAW files on your phone (not just JPGs)
- Preview edits in real-time without lag
- Works on any recent iPhone or iPad

うまくいかない理由:

  • 技術的な言葉は、ターゲットである一般ユーザーを遠ざけます
  • ユーザーはメリットをイメージできません(「256ビット処理」だから何でしょうか?)
  • 仕様が確認されるのはダウンロードを決めた後であり、その前ではありません
  • 例:「GPU アクセラレーション」は重要ですが、ユーザーが求めているのは「編集がすぐに終わること」です

変換パターン:

技術仕様ユーザーのメリット
「EXIF データの保持」「写真の撮影場所と日付をそのまま保持」
「32 ビットカラー深度」「バンディングや色落ちのない、滑らかなグラデーション」
「リアルタイムの共同編集」「ファイルをメールで何度もやりとりせず、チームで編集」
「デバイス上で処理(クラウド不使用)」「写真がスマートフォンの外に出ることはありません」

代わりにすること:

  • まず目的から考える:ユーザーは何を達成しようとしていますか?
  • 機能をメリットに変換する:「50 種類以上のフィルターに対応」→「プロ仕様のスタイルを何十種類も、すぐに使えます」
  • 「その結果」テストを使う:「機能 X、その結果、[メリット]を得られます」——文を完成できないなら、まだメリットになっていません
  • 可能であれば、コピーで使用前後を示す:「ぼやけた写真を、雑誌のような仕上がりに変えましょう」

5. ローカライズへの配慮がない(文化的なトーンの問題)

問題: 米国英語向けに書かれたコピーは、他の市場の文化に合わせて翻訳できるとは限りません。英語では自然な表現も、別の言語や地域では不自然でぎこちなく、文化に配慮していない印象を与えることさえあります。キーワード検索も地域によって異なります。

❌ 悪い例(米国中心で、うまく翻訳できない表現):

- "The #1 photo app" (claims don't work globally; also unverifiable)
- "Crush your creative goals" (aggressive tone doesn't translate; weird in Japanese/German)
- "Slay your edits" (slang; meaningless in translation; age-specific)
- "Our app rocks" (informal; risky in formal markets like Germany/Japan)

✅ 良い例(文化的に中立で、翻訳しやすい表現):

- "The most popular photo editor" (verifiable, neutral tone)
- "Achieve professional results in seconds" (universal benefit, formal enough)
- "Make every photo beautiful" (simple, universal, translates directly)
- "Trusted by millions worldwide" (global signal, works everywhere)

よくあるローカライズの落とし穴:

市場避ける表現使う表現
ドイツ攻撃的なスラング(「crush」「slay」)プロフェッショナルで明確な表現(「達成する」「最適化する」)
日本大げさな主張(「最高」「No.1」)謙虚ながらも確信のある表現(「数百万人に信頼されています」「多くの方に選ばれています」)
ブラジル米国英語のような形式的な表現温かみのある会話調のポルトガル語(ネイティブのライターを起用)
フランス英語のマーケティング表現フランス語として自然な表現(単に翻訳しない)
中国・アジア西洋の慣用表現(スポーツの比喩)文化的な言及を使わない、普遍的なメリット

地域によるキーワードの違い:

  • 米国での検索:「photo editor」(広い意味)
  • ドイツでの検索:「Fotobearbeitung」(より具体的。地域に根ざしたキーワード調査を実施)
  • 日本での検索:「写真編集」(まったく異なる語句が必要)

❌ 悪いアプローチ:

Write in US English → Translate to other languages → Done

(文化的な適合性、トーン、キーワードの機会を失います)

✅ 良いアプローチ:

1. Write core value prop in neutral, translatable English
2. Have native speakers for each market adapt tone, keywords, and examples
3. Test keywords in each region's App Store search (not just Google)
4. Avoid slang, sports metaphors, US-specific references
5. Keep formal enough to work in risk-averse markets (Germany, Japan, Korea)

代わりにすること:

  • まずは中立的な英語で書く(世界中で通用します)
  • 文化に合わせた調整が必要な単語や表現(「No.1」、スラング、米国特有の慣用表現)に印を付ける
  • 各地域で、単なる翻訳ではなく、トーンやキーワードを調整するためにネイティブスピーカーを起用する
  • 「プロフェッショナルで自信のある」トーンを維持する(さまざまな文化に通用します)
  • 可能であれば、各市場で異なるトーンを A/B テストする

トラブルシューティング

問題:生成後に文字数制限のエラーが発生する

症状: コピーの出来はよいものの、App Store/Play Store の入力欄の文字数制限を超えています

解決策:

# Validate all fields at once
python scripts/check_app_store_limits.py --platform ios --input input.json

# Input format (input.json)
{
  "app_name": "YourApp",
  "subtitle": "Your subtitle text",
  "description": "Full description...",
  "keywords": "keyword,list,comma,separated"
}

# Or pipe from stdin
echo '{"app_name":"YourApp","subtitle":"Edit photos fast"}' | \
  python scripts/check_app_store_limits.py --platform ios --input -

# Google Play variant
python scripts/check_app_store_limits.py --platform google_play --input input.json

すぐにできる修正:

  • iOS のサブタイトル(30 文字):冠詞(a、the)を削除し、短縮形を使う
  • Google Play の短い説明(80 文字):最も強いメリットを先頭に置く
  • キーワード(iOS は 100 文字):価値の低いキーワードを削除し、略語を使う
問題:良い入力を与えても、汎用的でありきたりなコピーになる

症状: 生成されたコピーが、ほかのどのアプリも同じように聞こえます

原因: 独自の差別化要素や実績を裏付ける情報が不足しています

解決策:

  1. ユーザーに尋ねます:「競合他社にはできない、アプリ独自の機能は何ですか?」
  2. 数字を尋ねます:「ユーザーは何人いますか?どれくらい時間を節約できますか?」
  3. 違いを見つけます:「ユーザーは今、どんな不便な方法を使っていますか?」
  4. 変換例:
    • 変換前:「誰でも簡単に写真を編集」
    • 変換後:「2回タップするだけで背景を削除—高額なサブスクリプションは不要」
問題:どの成果物を作ればよいか不明確

症状: ユーザーが具体的な内容を示さずに「アプリのマーケティングを手伝って」と言います

解決策: チェックリストを提示し、必要なものを尋ねます:

  • iOS App Store の掲載文
  • Google Play の掲載文
  • ランディングページのヒーローコピー
  • スクリーンショットのキャプション
  • ソーシャルメディア広告のフック
  • メールキャンペーンのコピー

その後、依頼された項目だけを作成します。

問題:キーワードの詰め込みが再発

症状: 文字数制限は守っているものの、不自然なコピーになります

原因: キーワード密度を最大化しようとしています

解決策:

  • コピーを声に出して読みます—ロボットのように聞こえる場合は、キーワードを減らします
  • サブタイトルと説明文を合わせて、各キーワードの使用は最大2回にします
  • 文字数の確認には scripts/check_app_store_limits.py を使い、読みやすさは手作業で確認します
  • 「人が実際にこんな言い方をするでしょうか?」と自問します
問題:参照ファイルやスクリプトが見つからない

症状: スキルで references/ や scripts/ のファイルが挙げられているものの、存在しません

解決策:

  1. ファイルが存在するか確認します:ls skills/app-marketing-copy/references/
  2. 見つからない場合は、それらを使わずに進めます:
    • app-store-metadata.md の代わりに、記載されている制限値を使います
    • スクリプトを実行する代わりに、文字数を手作業で確認します
  3. ユーザーに次のように提案します:「自動検証を行うには、scripts/check_app_store_limits.py を作成してください」

含まれるリソース

  • references/app-store-metadata.md:フィールド一覧、一般的な制限値、出力テンプレート。
  • references/screenshot-prompts.md:背景やプロモーション用ビジュアルのプロンプトテンプレート。
  • scripts/check_app_store_limits.py:iOS/Google Play の各フィールドの文字数制限をすばやく確認するツール(JSONを入力し、表を出力)。

コメント