📈 今日のグロース研究
広告800ドルで200件、無料のコメント2本で3,000件。リンクが1本もない導線が15倍を運んできた
きょうの結論
波は自分では作れないが、受け皿は作れる。3,000件のインストールが来た日に3分の1が落ちていた原因は、ペイウォールで閉じたアプリを開き直すと1画面目に戻る、という実装だった。
TOPIC 1
クリックできるリンクが、どこにもない
8月だけでiOS約2,500件、Androidも同程度。ウクライナの健康カテゴリで最高14位まで上がった。
3,000件コメント2本から出たインストール
98%App Store検索経由の割合（2,536件中2,475件）
4ドル有料施策の実効CPI
SelfOSという健康・生活管理アプリを個人で運営するViktoriiaさんの実測です。2.0を出す前の累計ダウンロードは700件、平常時は1日1〜6件という「誰も知らない」状態でした。
CPI = 1インストールを獲得するのにかかった広告費。指名検索 = サービス名そのもので検索すること。
TOPIC 2
波が来たとき、受け皿が割れていた
D7の落ち込みの相当部分は、プロダクトの魅力ではなく「復帰地点」の設計で説明がついてしまう。
レビューも同じ構図でした。3,000件規模のインストールに対して、レビューはiOSで37件、Androidで46件。星は4.9と4.6と高いのに、母数が小さい。
今日できる直し方は2つ。①オンボーディングの各ステップ完了時に進捗をローカル保存（iOSはUserDefaults、AndroidはDataStore）し、起動時にそこから復帰させる。②レビュー依頼を「起動N回目」から「中核アクションの1回目が終わった直後」へ移す。波が来てから仕込むのでは間に合わない。
TOPIC 3
日本語圏で同じ波を受け取るには、条件が2つある
読み上げ・コメント紹介系のショートアカウントは日本語圏にも大量にあり、常に素材を探している。
拾われやすい投稿の形は観察でパターン化できます。短い言い切り、具体的な数字、感情が動く一行。この3つが共通していました。
広告費はゼロなので、外れても損失が出ません。先にやるのは撮影ではなく、自分のプロダクト名をApp Store・Google Play・Googleの3か所で検索して1位に出るか確かめることです。
TOPIC 4
「アプリを作る」をやめて「部品を売る」に変えた人
Anton LavrenovさんのPolotno。LPを作ってからドキュメントを書いたのではなく、逆の順序だった。
無料版の「Polotno Studio」は販促用のデモではなく、SDKそのものが動くサンドボックスとして置かれています。r/InternetIsBeautifulで20,000 upvotesを集め、広告としてだけでなく「このSDKは実際にこう動く」という証明としても機能しました。
日本に引き写すと空白が見えます。国内の「◯◯エディタ」「◯◯ビルダー」は自社アプリとして出すのが定番で、他社に埋め込む部品として売っている例が驚くほど少ない。しかも縦書き、ルビ、和文組版、帳票レイアウトといった日本語固有のUI要件は、海外SDKがまとめて弱い領域です。
SDK = 他社が自分のアプリに組み込んで使う部品のかたまり。サンドボックス = 契約前に自由にいじって試せる場所。
TOPIC 5
ログイン回数を見るのをやめる
全員に同じフォローをすると、工数が薄く広がって何も起きない。「放置する」を明示的に決めるのが効く。
JotForm創業者のAytekin Tankさんの設計です。スタックはSupabase（保管）、n8n（ワークフロー）、OpenAI（文面の下書き）、Gmail（送信ではなく下書き作成）。
⚠ この投稿に成果の数値はありません。「転換率が何%上がった」という話は出てこず、開示されているのは手法と実装スタックだけ。効果が証明されたものではなく、設計の考え方として読むのが適切です。本人の結論は「賢いAIから始めるな。良いシグナルから始めろ」。
下書きで止める設計は日本では法務的にも効く。特定電子メール法のオプトイン要件と表示義務を踏まえると、AIの文面をそのまま自動送信する運用はリスクを抱える。
TOPIC 6
作る速度だけが上がって、届ける速度は据え置き
作れる人は増えたが、届けられる人は増えていない。この非対称がいちばん再現性のあるチャンスの在り処だ。
もう一つ同じ日に共通して見えたのが「エージェントが読める形で出す」潮流です。Open Inspectorはサイトのデザインシステムを抽出し、CSS変数・Tailwind config・JSON・W3Cデザイントークン・Markdownで書き出します。つまりCursorやClaudeにそのまま貼れる形です。
PostSiderのコメント欄はもっと生々しく、エージェントから叩いている利用者が開発者に2つだけ要求していました。投稿後の実URLを返してほしい、エラー理由を具体的に返してほしい。これが無いとエージェントは次の行動を選べません。
MCPサーバを立てるかどうかという大きな判断の手前に、「既存の書き出しにMarkdownかJSONを1形式足す」「APIのレスポンスに実URLとエラー理由を入れる」という小さくて安い判断がある。国内SaaSのエクスポートは今もPDFとCSVで止まっているものがほとんどで、ここは1形式足すだけで差が付きます。