Rork で作ったアプリを App Store でヒットさせる — ASO・価格・課金設計の実践ガイド

キーワード戦略 — ニッチを取る

App Store Connect の「キーワード」フィールドには100文字しか入りません。この限られた文字数を、最大限の検索流入につながる形で使う必要があります。

私が使っているキーワード選定の手順:

Step 1: 競合分析

自分のアプリと類似機能のアプリを5本ピックアップし、それぞれが検索1〜3位に入っているキーワードを調査します。Sensor Tower や AppTweak の無料枠でも、このレベルの分析はできます。

Step 2: 「中ボリューム × 低競合」のキーワードを優先

検索ボリューム100以上、かつ競合の上位アプリのレビュー数が500以下のキーワードを探します。「英会話」のような巨大キーワードは取れません。「英語 シャドーイング 初心者」のような3語以上の複合キーワードに勝機があります。

Step 3: 100文字に詰め込むパターン

英会話,英語,リスニング,シャドーイング,発音,初心者,
TOEIC,TOEFL,日常会話,フレーズ,学習,勉強,海外旅行,
ビジネス英語

カンマ区切りで隙間なく詰め込みます。アプリ名と説明文にすでに含まれている単語は、ここには入れません。重ねても枠を食うだけです。

Step 4: 月次でリフレッシュ

キーワードは固定ではなく、月次で見直します。「先月効果があったキーワードはより詳細に」「効果がなかったキーワードは削除」のサイクルを回します。

私の場合、最初のキーワード設定から3〜4回のリフレッシュを経て、検索順位が安定してきました。日本語のキーワードフィールドは分かち書きの扱いが独特なので、詰め方そのものはキーワードフィールドの日本語ASOのほうに分けて書いています。

ストアページのコンバージョン率を上げる

検索結果からアプリページに来てくれたユーザーが、実際にダウンロードしてくれる確率を上げる工夫です。

アプリ名の設計

アプリ名は、検索順位とコンバージョン率の両方に最も大きく影響します。

■ NG例
「英会話アプリ Pro」（一般的すぎ・差別化なし）
 
■ OK例
「Shadow English - 1日10分のシャドーイング英会話学習」
（独自ブランド名 + 機能 + 差別化ポイント）

ブランド名 + サブタイトル形式が、現在の App Store では最も効果的です。サブタイトルにも検索可能なキーワードを含められるため、キーワードフィールド100文字 + サブタイトル30文字の合計でキーワード戦略を組み立てます。

スクリーンショットの設計

スクリーンショット5〜10枚で、アプリの価値を伝え切ります。私のテンプレート:

• スクリーンショット1: 最も重要な体験 + 「○○できるアプリ」のキャッチコピー
• スクリーンショット2: 主要機能のリスト + 視覚的な利益
• スクリーンショット3: 独自機能の説明 + 競合との差別化
• スクリーンショット4: ユーザー体験の流れ（before/after）
• スクリーンショット5: 評価・レビュー引用

文字なしのアプリ画面だけのスクリーンショットは、コンバージョン率が低いです。必ず日本語の説明テキストを画像に焼き込んだ「広告型スクリーンショット」を使ってください。

プレビュー動画

15〜30秒の動画でアプリ体験を見せられます。動画のあるアプリページはコンバージョン率が30〜50%上がるという公式データがあります。

ただし、低品質な動画は逆効果です。BGM、字幕、画面遷移の演出を入れた、「TVCM レベル」のクオリティで作る必要があります。Rork で作ったアプリのデモを画面録画して、Final Cut Pro や DaVinci Resolve で編集する流れが現実的です。

説明文（First Paragraph）

App Store の説明文は、最初の3行（約150文字）が「もっと見る」をタップする前に表示されます。この3行で、ユーザーに「これは私のためのアプリだ」と感じさせる必要があります。

■ NG例
「私たちは、ユーザーの皆様により良い英会話学習体験を提供するため、
本アプリを開発しました。豊富な機能と直感的なUIで...」
 
■ OK例
「『1年勉強しても話せない』を変える、シャドーイング特化の英会話アプリ。
1日10分・スマホ片手・通勤中でOK。3,000人が継続中。」

問題提起 + 具体的な解決策 + 社会的証明（ユーザー数）の3要素を、3行に圧縮します。

「最初の評価10件」を最短で集める実践テクニック

新規アプリの最大の壁は、「評価0件のアプリは誰もダウンロードしない」という鶏卵問題です。これを突破するための、私が実践している方法を共有します。

方法1: 友人・家族・コミュニティへの直接依頼

ローンチ時に、信頼できる10〜20人に直接依頼します。「アプリを公開しました。実際に使ってみて、良かったら評価を入れてもらえますか」とお願いします。これで初日に5〜10件の評価が入る状態を作ります。

方法2: 個人ブログ・SNS での告知

自分のブログ、Twitter、Threads、Instagram などで告知します。「今日、こんなアプリを公開しました」と、開発過程の話と一緒に発信すると、フォロワーから一定の評価が入ります。

方法3: アプリ内評価リクエストの最適タイミング

iOS の SKStoreReviewController は年3回までしか出せません。最初の起動時に出すのは絶対NG。「ユーザーが満足している瞬間」に絞って出します。

私が使っているトリガー:

// 5回目の起動 + 直前のアクションが成功 + 過去24時間にエラーなし
if (sessionCount === 5 && lastActionSuccess && noRecentErrors) {
  StoreReview.requestReview();
}

このタイミングだと、評価率が10〜20%程度になります。雑に出すと2〜3%しか取れません。

方法4: 低評価防止フィルター

「アプリ内で『満足していますか？』を先に聞き、Yesの人だけストア評価に誘導、Noの人にはフィードバックフォームに誘導する」設計です。これは Apple ガイドラインのグレーゾーンなので、慎重に運用する必要があります。

私の運用方法は、「サポート画面に『評価する』『フィードバックを送る』の2ボタンを並べる」だけにとどめています。明示的に分岐させるのは規約違反のリスクがあります。

価格モデル選択 — 買い切り vs サブスク vs 課金アンロック

Rork で作ったアプリの価格モデルは、ジャンルによって最適解が違います。

買い切り（One-time Purchase）

向くジャンル: シンプルなユーティリティ、特定機能のツール、コレクション型コンテンツ 価格帯: 120〜480円（日本）/ $0.99〜$4.99 メリット: シンプルで購入ハードルが低い、Apple のレビューも通りやすい デメリット: 継続収益にならない、新規ユーザー獲得を続ける必要

サブスクリプション（Subscription）

向くジャンル: コンテンツ更新が継続するアプリ、プレミアム機能を提供するアプリ、SaaS型のアプリ 価格帯: 月額300〜980円 / 年額2,400〜9,800円 メリット: 継続収益が積み上がる、ユーザーあたりの生涯価値が高い デメリット: 解約率が高いと収益が安定しない、Apple のレビューが厳しい

課金アンロック（IAP for Premium Features）

向くジャンル: 無料で基本機能、有料で追加コンテンツ・機能 価格帯: 個別アンロック120〜600円、まとめパック1,000〜3,000円 メリット: 無料で母数を広げられること、使い込む方から相応に受け取れること デメリット: 無料ユーザーの広告収益化との兼ね合いが必要

私の推奨パターン

ユーティリティ系アプリには「無料 + 広告 + 480円で広告除去 IAP」の組み合わせ。コンテンツ更新型アプリには「無料 + 広告 + 月額500円のサブスク」の組み合わせ。コレクション型コンテンツには「買い切り 360円」の単純モデル。

複雑にしすぎないことが、ユーザー体験と収益の両立につながります。

買い切りとサブスクを、12か月の数字で決める

ここまでの整理は「どのジャンルに何が向くか」という当たりの付け方にすぎません。実際に迷うのは、自分のアプリがちょうど境目にあるときです。

そこで私は、決める前に数字を並べます。同じインストール数を買い切りに流した場合とサブスクに流した場合で、12か月分の累計がどう動くかを出すだけの短いスクリプトです。

// model-breakeven.mjs
// 使い方: node model-breakeven.mjs <月間インストール数> <買い切り価格> <買い切りCVR%> <サブスク月額> <トライアル転換率%> <月次解約率%>
const [installs, oneTimePrice, oneTimeCvr, subPrice, trialConv, churn] =
  process.argv.slice(2).map(Number);
 
const FEE_FIRST_YEAR = 0.30; // 初年度のサブスクと、通常のアプリ内課金
const FEE_SMALL_BIZ  = 0.15; // Small Business Program 適用時
 
let oneTimeCum = 0, subCum = 0, subscribers = 0, crossover = null;
 
for (let m = 1; m <= 12; m++) {
  // 買い切り: その月のインストールから一度だけ
  oneTimeCum += installs * (oneTimeCvr / 100) * oneTimePrice;
 
  // サブスク: 前月の継続者から解約を引き、新規転換を足してから月額を掛ける
  subscribers = subscribers * (1 - churn / 100) + installs * (trialConv / 100);
  subCum += subscribers * subPrice;
 
  if (crossover === null && subCum > oneTimeCum) crossover = m;
  console.log(`${String(m).padStart(2)} | ${String(Math.round(oneTimeCum)).padStart(7)} | ${String(Math.round(subCum)).padStart(7)} | ${String(Math.round(subscribers)).padStart(5)}`);
}
 
const net = (g, fee) => Math.round(g * (1 - fee));
console.log(`逆転月: ${crossover ?? "12か月以内には起きない"}`);
console.log(`12か月 手数料30%後: 買い切り ${net(oneTimeCum, FEE_FIRST_YEAR)} / サブスク ${net(subCum, FEE_FIRST_YEAR)}`);
console.log(`12か月 手数料15%後: 買い切り ${net(oneTimeCum, FEE_SMALL_BIZ)} / サブスク ${net(subCum, FEE_SMALL_BIZ)}`);
console.log(`サブスク継続者の平均寿命: ${(100 / churn).toFixed(1)} か月`);

肝は、サブスクを「積み上がる残高」として扱っている点です。買い切りは毎月同じ額が足されるだけですが、サブスクは前月の継続者から解約を引き、新規転換を足した人数に月額を掛けます。ここを単純な掛け算で済ませると、サブスクを実態よりかなり強く見積もってしまいます。

月1,000インストール・買い切り360円で購入率8%・サブスク月額500円でトライアル転換率3%・月次解約率8%。この条件で Node v22.22.3 上で実際に走らせた出力から、要点だけを抜き出します。

逆転月は4。手数料30%を引いた12か月後の実収は、買い切り241,920円に対してサブスク620,571円でした。

ただしこの差は、解約率の一点にぶら下がっています。同じ条件で月次解約率だけを8%から5%に下げると、逆転月は3に早まり、12か月累計は886,531円から980,052円へ。継続者の平均寿命は12.5か月から20.0か月に伸びます。サブスクの収益は価格ではなく解約率で決まる、というのが出力を並べて最初に腑に落ちた点でした。解約率をどう下げるかは継続率とLTVの設計側の話題になります。

自分の数字を入れて見るときの読み方は、私の場合こうです。逆転月が想定している運用期間より後ろに来るなら、サブスクを選ぶ理由は薄いのかもしれません。私自身、更新を1年以上続けられる確信が持てなかったアプリは、迷わず買い切りにしてきました。払い続けてもらう約束は、こちらが更新を止めた瞬間に嘘になります。3つのモデルを収益全体の中でどう組むかは広告・サブスク・買い切りの比較で別途整理しています。

70% と 85% の境目を、24か月の数字で見る

前節のスクリプトを書いたとき、私は手数料を FEE_FIRST_YEAR = 0.30 という定数ひとつで済ませていました。12か月で切る比較にはそれで足ります。困ったのは、その先を見ようとしたときです。サブスクの取り分は途中で変わるはずなのに、モデルの中では最後まで同じ値のまま動いていました。

境目の条件を読み直して、自分が「一年」という言葉を都合よく解釈していたことに気づきました。Apple が数えているのは加入からの暦の一年ではなく、有料実績の日数です。ここを取り違えると、実収の見積もりは静かにずれ続けます。

規定のほうを先に読む

一次情報を並べると、押さえる点は多くありません。

実務でいちばん効くのは、下から3行目です。月次解約率が二桁に近いアプリでは、そもそも1年に届く加入者がほとんど出ません。詳細は Apple の Auto-renewable Subscriptions と App Store Small Business Program の記載をご覧ください。

コホートで24か月を回す

前節と同じ条件のまま、期間だけ24か月に延ばして取り分を正しく切り替えます。加入月ごとの集団を別々に持ち、それぞれの経過月数で 70% と 85% を出し分けるだけです。

// sub-proceeds-horizon.mjs
// 使い方: node sub-proceeds-horizon.mjs <月間新規転換者数> <月額> <月次解約率%> <観測月数> [無料トライアル月数]
const [joins, price, churn, months, trial = 0] = process.argv.slice(2).map(Number);
 
const RATE_Y1 = 0.70;           // 有料実績 1 年未満
const RATE_Y2 = 0.85;           // 有料実績 1 年到達後
const PAID_MONTHS_TO_Y2 = 12;
 
// cohorts[k] = 加入から k か月経過した集団。トライアル分は有料日数に入れない
let cohorts = [];
let grossCum = 0, netCum = 0, netY1Cum = 0, netY2Cum = 0;
 
for (let m = 1; m <= months; m++) {
  cohorts = cohorts.map(c => ({ age: c.age + 1, n: c.n * (1 - churn / 100) }));
  cohorts.push({ age: 1, n: joins });
 
  let gross = 0, net = 0, netY1 = 0, netY2 = 0, y2Heads = 0;
  for (const c of cohorts) {
    const paidMonths = c.age - trial;   // 有料として数えられる月数
    if (paidMonths <= 0) continue;      // トライアル中は請求が起きない
    const g = c.n * price;
    const rate = paidMonths > PAID_MONTHS_TO_Y2 ? RATE_Y2 : RATE_Y1;
    gross += g;
    net += g * rate;
    if (rate === RATE_Y2) { netY2 += g * rate; y2Heads += c.n; } else { netY1 += g * rate; }
  }
  grossCum += gross; netCum += net; netY1Cum += netY1; netY2Cum += netY2;
 
  const heads = cohorts.reduce((s, c) => s + c.n, 0);
  console.log(`${String(m).padStart(2)} | ${Math.round(heads)} | ${Math.round(y2Heads)} | ${Math.round(grossCum)} | ${Math.round(netCum)}`);
}
 
const pct = n => (n / netCum * 100).toFixed(1);
console.log(`実効レート ${(netCum / grossCum * 100).toFixed(2)}%`);
console.log(`70% 帯 ${Math.round(netY1Cum)}（${pct(netY1Cum)}%） / 85% 帯 ${Math.round(netY2Cum)}（${pct(netY2Cum)}%）`);
console.log(`全期間 70% 固定との差 +${Math.round(netCum - grossCum * RATE_Y1)}`);
console.log(`全期間 85%（SBP 相当）との差 +${Math.round(grossCum * RATE_Y2 - netCum)}`);

月30人が転換、月額500円、月次解約率8%。前節と同じ数字です。Node v22.23.2 で走らせた出力から、節目だけ抜き出します。

12か月時点の総額と実収が前節の出力と一致しているのは、同じ条件をそのまま延ばしているためです。見たいのはその先で、24か月を走らせても 85% 帯に入った収益は実収の 14.6% にとどまりました。実効レートは 71.86%。全期間を 70% で固定した場合との差は 48,892円です。

差が出ない理由と、差が出るほう

理由は継続者の内訳にあります。24か月目に 324人が残っていても、有料実績1年を超えているのは 87人。月次解約率8%は平均寿命でいえば12.5か月ですから、大半の加入者は 85% の帯に届く前に離れていきます。解約率を5%に下げると 85% 帯は 19.6% まで上がり、12%に上げると 9.5% まで落ちました。二年目の 85% は、解約率を下げた人だけに配られる報酬です。

一方、同じ出力に並ぶもう一つの数字のほうが大きく動きます。全期間 85%、つまり Small Business Program に加入している場合との差は 346,392円。二年目の昇格で得られる 48,892円のおよそ7倍です。手数料の話になると期間の長い施策に目が向きがちですが、効き方の順序は逆でした。

待って上がる 15% よりも、申請すればすぐ受け取れる 15% を先に取ります。 個人開発で使える時間は限られていますから、私はこの順序だけは守るようにしています。Small Business Program は前年の proceeds が 100万USD 以下であることが条件で、新規の開発者も対象です。年の途中で上限を超えた場合はその後の売上に標準レートが適用され、翌年に下回れば、そのさらに翌年から再び 15% の対象になります。

無料トライアルの扱いも、ここで一度確かめておくと安心かもしれません。同じ条件に1か月の無料トライアルを挟むと、24か月の総額は 2,275,229円へ下がり、85% 帯の比率も 14.6% から 13.5% へ落ちます。トライアル期間は有料日数に数えられないので、85% に到達する時期がその分だけ後ろへずれるためです。トライアルを長くする判断は転換率と引き換えに、この後ろ倒しも引き受けることになります。

私がこの計算を挟むようになったのは、年次のレポートを眺めて実収が思っていたより少なかった月があったからでした。原因は価格でも転換率でもなく、取り分の切り替わりを都合よく見積もっていた自分の側にありました。解約率をどう下げるかは継続率とLTVの設計のほうで扱っています。

サブスクリプション設計の現実

サブスクリプションを成功させるには、Apple の最新仕様を踏まえた設計が必要です。

無料トライアル

新規ユーザーに7〜14日間の無料トライアルを提供します。トライアル期間中は無料で全機能を使えます。

私の経験では、3日間トライアルより7日間トライアルのほうが転換率が高いです。「アプリを習慣化するには7日かかる」というユーザー行動データに基づいています。

プロモオファー

既存有料ユーザーへの「初月90%オフ」「3ヶ月間半額」のような特別オファーを発行できます。長期解約しているユーザーへのウィンバック施策として強力です。

価格を国別に最適化

App Store Connect では、価格を「Tier」で設定するのが基本ですが、国別にカスタム価格も設定できます。米国で $4.99、日本で 600円、東南アジアで 60円のように、購買力に応じた価格設定をすると、収益が国別に最適化されます。

解約フォームでの引き止め

iOS 17 以降、解約フォームに「カスタムメッセージ」を表示できるようになりました。「ご利用ありがとうございました。差し支えなければ、解約理由を教えてください」のメッセージとともに、特典付きのプランダウングレード提案ができます。

私の運用では、これで解約率を 8% から 5% に下げられました。

価格心理学 — 「適切な価格」の見つけ方

価格決定で最もよくある失敗が「自分が買いやすい価格を付けてしまう」ことです。あなたが「これくらいなら買う」と思う価格と、ユーザーが「これくらいなら買う」と思う価格は違います。

「アンカー」を意識する

ユーザーは絶対価格ではなく、相対価格で判断します。月額500円のアプリは、隣に月額1,200円のアプリがあれば「安い」、月額300円のアプリがあれば「高い」と感じます。

App Store でユーザーが目にする価格帯（同ジャンル他アプリ）を意識し、その中で「中位 〜 やや上」のポジションに置くのが、価格を取りやすい設計です。最安値を狙うと、ユーザーは「安いから質も低そう」と感じます。

桁数の心理

「480円」と「500円」では、見た目の桁数の印象が違います。日本では「~80円」「~80円」終わりが多用されます。米国でも「$0.99」「$2.99」「$4.99」が定番です。

逆に「ちょっと特別感を出したい」場合は、「380円」より「398円」のような中途半端な数字を使うことがあります。「これは適当に決めた価格ではなく、慎重に計算された価格だ」という印象を与えるテクニックです。

価格テスト

新規アプリでは、最初の3ヶ月で価格を1〜2回変えてみる価値があります。買い切り480円→360円、月額600円→500円のように、10〜30%の価格変動をテストし、月次収益と購入率を比較します。

App Store では価格変更が即時反映されるため、こうしたテストが現実的に行えます。

レビュー対応の戦略

評価が高いアプリには、低評価レビューも必ず付きます。すべての低評価に丁寧に返信することで、検索順位とコンバージョン率の両方を上げられます。

返信の基本姿勢

「ご利用ありがとうございます」と感謝から始め、「ご指摘の点について状況を確認しました」と問題に向き合い、「○月のアップデートで改善予定です」と具体的なアクションを示します。

責任を回避する返信（「お使いの環境の問題です」「他のユーザーからは問題ない報告です」）は、それを読んだ将来のユーザーに「このアプリ提供者は信頼できない」という印象を与えます。

低評価から学ぶ

3つ星以下の評価には、改善のヒントが詰まっています。月次で全レビューを読み、共通する不満点を洗い出します。それを次のアップデートに反映する、というサイクルを継続します。

私の運用では、月1回のレビュー分析で発見した改善点が、次回アップデートのリリースノートに直接反映されます。「ユーザーの声を聞いてくれている」と感じてもらうことで、評価の改善につながります。

App Store の最新仕様変更を活かす

2026年時点で、App Store には個人開発者にとって重要な仕様変更がいくつかあります。

代替決済（EU・日本一部対応）

EU や日本の一部で、Apple の決済システム以外を使うことが可能になりました。Apple 手数料15〜30%を回避できる代わりに、自分で決済システムを実装する必要があります。

月額売上が小さいうちは Apple 決済のままで十分。月額売上が10万円を超え始めたら、代替決済の検討に入ります。Stripe で実装すれば、手数料は3.6%程度に下がります。

ファミリー共有

アプリの IAP やサブスクリプションを、ファミリー共有グループ内で共有できる設定があります。共有を許可すると、1人購入で家族5〜6人が使えるため、購入意欲が上がります。一方で、1ユーザーあたりの収益は下がります。

向くジャンル: 家族で使うアプリ（家計簿、子育て、教育系）。向かないジャンル: 個人向け生産性ツール、コミュニケーションアプリ。

App Store プロダクトページ最適化（A/B テスト）

App Store Connect で、プロダクトページの A/B テストができます。アイコン、スクリーンショット、説明文の異なるバージョンをユーザーに出し分けて、コンバージョン率を比較できます。

私の経験では、アイコン1つの A/B テストで、コンバージョン率が30〜50%改善することがあります。これはコードを1行も書かずにできる収益改善施策です。

A/B テストの「改善した」を、いつ信じてよいか

前節で「アイコン1つで30〜50%動くことがある」と書きましたが、これは表示数が十分に溜まったあとの話です。個人開発のアプリは母数が小さく、数百表示の段階で見えている差の多くは、ただの揺らぎです。

必要な表示数を先に出しておくと、途中で結果を覗いて一喜一憂せずに済みます。

// ab-page-views.mjs
// 使い方1: node ab-page-views.mjs plan <基準CVR%> <検出したい相対改善%>
// 使い方2: node ab-page-views.mjs check <A表示数> <Aインストール数> <B表示数> <Bインストール数>
const Z_ALPHA = 1.96; // 両側5%
const Z_BETA  = 0.84; // 検出力80%
 
function plan(baseCvr, lift) {
  const p1 = baseCvr / 100;
  const p2 = p1 * (1 + lift / 100);
  const pBar = (p1 + p2) / 2;
  const num = Math.pow(
    Z_ALPHA * Math.sqrt(2 * pBar * (1 - pBar)) + Z_BETA * Math.sqrt(p1 * (1 - p1) + p2 * (1 - p2)),
    2
  );
  return { p2, n: Math.ceil(num / Math.pow(p2 - p1, 2)) };
}
 
function check(nA, cA, nB, cB) {
  const pA = cA / nA, pB = cB / nB;
  const pPool = (cA + cB) / (nA + nB);
  const se = Math.sqrt(pPool * (1 - pPool) * (1 / nA + 1 / nB));
  const z = (pB - pA) / se;
  // 標準正規の両側 p 値（Abramowitz-Stegun 近似）
  const t = 1 / (1 + 0.2316419 * Math.abs(z));
  const d = 0.3989423 * Math.exp(-z * z / 2);
  const p = 2 * d * t * (0.3193815 + t * (-0.3565638 + t * (1.781478 + t * (-1.821256 + t * 1.330274))));
  return { pA, pB, z, p };
}
 
const [mode, ...rest] = process.argv.slice(2);
const a = rest.map(Number);
 
if (mode === "plan") {
  const r = plan(a[0], a[1]);
  console.log(`基準CVR ${a[0].toFixed(2)}% → 目標 ${(r.p2 * 100).toFixed(2)}%`);
  console.log(`必要な表示数: 各バリアント ${r.n.toLocaleString()} / 合計 ${(r.n * 2).toLocaleString()}`);
} else {
  const r = check(a[0], a[1], a[2], a[3]);
  console.log(`A: ${(r.pA * 100).toFixed(2)}%  B: ${(r.pB * 100).toFixed(2)}%  相対差 ${(((r.pB / r.pA) - 1) * 100).toFixed(1)}%`);
  console.log(`z = ${r.z.toFixed(2)} / p = ${r.p.toFixed(4)} → ${r.p < 0.05 ? "差はノイズでは説明しにくい" : "ノイズの範囲。まだ判断しない"}`);
}

基準コンバージョン率3%として plan モードを走らせた出力です。

小さな改善ほど、必要な表示数が跳ね上がります。相対10%を見分けるには合計10万表示。新規アプリでは数か月かかる規模です。だからこそ最初のテストは、説明文の言い回しではなくアイコンごと差し替えるような大きな振れ幅から始めたほうが、限られた表示数を無駄にしません。

check モードのほうが、実務では効きます。同じ「30%改善に見える結果」を、母数だけ変えて2回走らせました。

見た目の改善率はほぼ同じなのに、結論は逆になります。前者の段階で勝者を確定させてしまうと、実際には効いていない施策を「効いた」と記憶し、次のアプリにも持ち込むことになります。

App Store Connect のプロダクトページ最適化は信頼区間つきの結果を返してくれますが、私は開始前に必要表示数を自分で出しておく手順を挟んでいます。数字を先に決めておくと、途中経過を見て手を止めたくなる気持ちを、根拠を持って抑えられるからです。

実例: 買い切りアプリで月10万円ライン

抽象論だけでは伝わりにくいので、手元の一例をそのまま書き残します。私が運営している壁紙系アプリの一つは、買い切り 360円で運営しており、月10万円ライン前後の収益を出しています。

設計のポイント:

• ジャンル: 高品質な壁紙コレクション（テーマ別に1,000点以上）
• 価格: 360円買い切り（プレミアム壁紙は別途 IAP 240円〜）
• ASO: 「壁紙 おしゃれ 高画質 シンプル」など中ボリュームキーワード3〜4語の組み合わせで複数ヒット
• スクリーンショット: 実際の壁紙を Apple 公式デバイスフレームに合成した見せ方
• 評価: 4.6/5（評価数 1,200件）
• 月次新規購入: 約280件
• 月次収益: 約10万円（手数料控除後）

このアプリの開発自体は1ヶ月程度ですが、運用開始から3ヶ月かけて ASO とスクリーンショットを最適化し、評価を集めることで、月10万円ラインに乗せました。

90日でストア戦略を確立する

最後に、Rork で作ったアプリを App Store でヒットさせるための90日プランを示します。

Day 1〜14: 競合分析、キーワード選定、ストアページ素材準備（アプリ名・スクリーンショット・説明文・動画）。Rork での実装と並行して進めます。

Day 15〜30: ストア提出、初回 ASO 設定、最初の20名への直接告知。SNS とブログでローンチ告知。最初の評価10件をここで集めます。

Day 31〜45: 検索流入データを分析し、キーワードを月次リフレッシュ。スクリーンショットの A/B テスト開始。

Day 46〜70: 新規ユーザーの D7 retention を分析し、改善施策を実装。サブスク導入を検討する場合はここで実装。

Day 71〜90: 検索順位の安定化、月次新規ユーザー数を100人以上に押し上げ。月収益5万円〜10万円ラインを目指します。

次の一歩

ここまで読んでいただき、ありがとうございます。

具体的に動くなら、まず自分が運営しているアプリ（または作ろうとしているアプリ）の競合を5本選び、それぞれのストアページを徹底分析してみてください。アプリ名・スクリーンショット・説明文・評価数を表にまとめると、自分のアプリの戦い方が見えてきます。

そのうえで、本記事のキーワード選定手順を1ヶ月運用してみてください。3〜4回のリフレッシュを経て、検索流入が確実に変わります。