Rork の $15M シード調達を、個人開発者としてどう読んだか — 乗る判断の材料とローンチまでの実務

早期ユーザーが得られるもの、得られないもの

ここは切り分けが必要な箇所です。「早く使い始めた人は優遇される」という期待は、スタートアップの歴史を見れば半分は当たり、半分は外れます。

Rork について私が確認できた範囲では、生涯価格の据え置きや、早期ユーザー限定の永久ディスカウントといった公式プログラムは存在しません。他社の事例を根拠に「たぶんあるはず」と考えて意思決定するのは、事業としては危うい賭けです。

一方で、早期ゆえに実際に得られるものは確かにあります。

私が実際に価値を感じているのは3行目です。同じお題を投げ続けていると、生成品質が上がった月がはっきり分かります。これは早く始めた人にしか蓄積できない情報でした。

撤退線は、感覚ではなく数字で置く

先ほどの表の1行目に「値上げ時の撤退線を先に決めておく」と書きました。これは心構えの話ではなく、計算で出せます。

私の壁紙アプリの主な収益源は AdMob のインタースティシャル広告です。日本向けで eCPM がおよそ300円、1セッションに1回表示、DAU あたり1日1.5セッション。この前提なら、DAU 1人が1ヶ月に生む広告収益はこうなります。

1.5セッション × 30日 × 300円 ÷ 1,000 = 約13.5円

あとは、プラン料金をこの数字で割るだけです。

この表を手元に置いてから、判断がずいぶん速くなりました。DAU が300に届いていないアプリで Max を契約するなら、それは収益ではなく学習に投資している、と自覚できます。

学習への投資が悪いわけではありません。ただ、収益化のつもりで赤字を続けるのとは、まったく別の行為です。

私の撤退線は「この表の DAU が実質2倍になったとき」に置いています。クレジットの消費ルールが変わり、同じ作業に往復が倍かかるようになれば、月額表示が据え置きでも実質は倍額です。定点観測の1つ目の項目が、そのまま撤退の判断材料になります。

乗ると決めたあと、まず作った「戻れる状態」

調達を見て私が出した結論は「Expo 側で続けるが、いつでも降りられる形にしておく」でした。プラットフォームを信用するかどうかと、依存の深さを設計するかどうかは別の問題です。

最初にやったのは、生成物を自分の Git リポジトリに毎回スナップショットすることでした。Rork の画面上で履歴を追えても、手元に残っていなければ「先月の生成物と何が変わったか」を後から検証できません。

#!/usr/bin/env bash
# rork-snapshot.sh — Rork からエクスポートした zip を自分のリポジトリに取り込み、
# 生成のたびに差分を追えるようにする。
# 使い方: ./rork-snapshot.sh ~/Downloads/rork-export-2026-04-09.zip "AdMob 導入後"
set -euo pipefail
 
ZIP="${1:?エクスポートした zip のパスを渡してください}"
NOTE="${2:-}"
REPO="$HOME/apps/wallpaper-rn"        # 自分で管理するリポジトリ
STAGE="$REPO/generated"               # 生成物だけを置く場所
 
[ -d "$REPO/.git" ] || { echo "リポジトリが見つかりません: $REPO"; exit 1; }
 
# 生成物の置き場だけを丸ごと入れ替える。手書きコードは generated/ の外に置く。
rm -rf "$STAGE"
mkdir -p "$STAGE"
unzip -q "$ZIP" -d "$STAGE"
 
# node_modules や lock が混ざると差分が読めなくなるため落とす
find "$STAGE" -name node_modules -type d -prune -exec rm -rf {} + 2>/dev/null || true
find "$STAGE" -name "*.log" -delete 2>/dev/null || true
 
cd "$REPO"
STAMP="$(TZ=Asia/Tokyo date +%Y-%m-%d-%H%M)"
git add generated
if git diff --cached --quiet; then
  echo "生成物に差分はありませんでした ($STAMP)"
  exit 0
fi
 
# 何行増えて何行消えたかを、コミットメッセージに残す
SUMMARY="$(git diff --cached --shortstat)"
git commit -q -m "gen: ${STAMP} ${NOTE}" -m "${SUMMARY}"
git tag -f "gen-${STAMP}"
echo "記録しました: ${SUMMARY}"

このスクリプトの肝は、generated/ の外に手書きコードを置くという境界です。生成物は毎回まるごと入れ替わる前提にしておくと、AI が意図せず書き換えた箇所を git diff で一目で見つけられます。

逆に、生成された画面ファイルに直接手を入れ始めると、次の生成でその修正が消え、消えたことにも気づけません。私は最初の2週間これで無駄な時間を使いました。

境界を引いたうえで、外に出すべきものは3つでした。

1. AdMob のユニット ID とリモート設定のキー — 生成物に埋め込むと、再生成のたびに本番 ID が消える
2. App Store / Google Play の申請メタデータ — 生成の対象外なのに、なぜか毎回探し直すことになる
3. 端末で撮ったスクリーンショットと審査用の説明文 — 資産として最も再利用が効く

// src/config/ads.ts — generated/ の外に置く。ここだけは AI に触らせない。
type AdSlot = "wallpaper_detail" | "download_complete";
 
const UNIT_IDS: Record<AdSlot, { ios: string; android: string }> = {
  wallpaper_detail: {
    ios: "ca-app-pub-XXXXXXXXXXXXXXXX/1111111111",
    android: "ca-app-pub-XXXXXXXXXXXXXXXX/2222222222",
  },
  download_complete: {
    ios: "ca-app-pub-XXXXXXXXXXXXXXXX/3333333333",
    android: "ca-app-pub-XXXXXXXXXXXXXXXX/4444444444",
  },
};
 
// 開発ビルドで本番 ID を叩くと、AdMob 側で無効トラフィック扱いになります。
// テスト ID への切り替えは実行時ではなくビルド時に決めます。
const TEST_UNIT = {
  ios: "ca-app-pub-3940256099942544/2934735716",
  android: "ca-app-pub-3940256099942544/6300978111",
};
 
export function adUnitId(slot: AdSlot, platform: "ios" | "android"): string {
  if (__DEV__) return TEST_UNIT[platform];
  return UNIT_IDS[slot][platform];
}

__DEV__ での分岐をここに集約しておくと、生成された画面側は adUnitId("wallpaper_detail", Platform.OS) を呼ぶだけになります。画面が何度再生成されても、広告の設定は生き残ります。

収益設計そのものについては、RorkアプリのAdMob収益化戦略で別途整理しています。

申請で詰まった4点は、いずれも生成物の外側にあった

試作を実際に App Store と Google Play に出す過程で止まった箇所は、コードの品質ではなく、生成の対象外にある設定でした。同じ構成なら再現すると思うので、具体的に残しておきます。

権限の説明文は、app.json に書けば Expo のビルド時に反映されます。

{
  "expo": {
    "ios": {
      "infoPlist": {
        "NSPhotoLibraryAddUsageDescription": "選んだ壁紙を写真アプリに保存するために使用します。",
        "NSUserTrackingUsageDescription": "広告の表示回数を適正に保つために使用します。オフのままでもアプリのすべての機能をご利用いただけます。"
      }
    },
    "android": {
      "permissions": ["POST_NOTIFICATIONS"]
    }
  }
}

ATT の文言で一度差し戻された経験から、私は「オフのままでも機能は使える」と明記するようにしています。ここを曖昧にすると、審査側が機能制限の有無を確かめられず、質問が往復して数日失います。

Privacy Manifest は SDK の依存が増えるほど厄介になります。監査の手順はRork の Privacy Manifest と SDK チェーンの事前監査に分けて書きました。

4点に共通していたのは、どれも生成されたコードの品質とは無関係だったことです。AI がアプリを書いてくれる時代でも、審査を通すのは依然として人間側の準備でした。ここを見誤ると「Rork の生成品質が低いせいで落ちた」と原因を取り違えます。

調達後の変化を、自分の手元で測る

プラットフォームが良くなったかどうかを、公式の発表文で判断するのは無理があります。私は月に一度、同じお題を投げて記録することにしました。

回帰テストのつもりで、次の3つを毎月同じ文面で投げています。

1. 一覧・詳細・保存の3画面を持つ最小構成のアプリを生成させる
2. そこに「保存済みだけを絞り込むフィルタ」を後から追加させる
3. 生成物をエクスポートして、そのままビルドが通るかを確かめる

記録するのは4つの数字だけです。

4番目が一番大事だと考えています。AI 生成ツールの実用性は、最初の生成の見栄えではなく、追加指示を重ねたときに前の実装が生き残るかでほぼ決まります。ここが崩れるツールは、試作までは楽しく、運用に入った瞬間に破綻します。

3ヶ月続けると、数字が判断してくれるようになります。感想で乗り換えを決めるより、はるかに落ち着いていられます。

結局、乗るかどうかをどう決めたか

私は Expo 側で続けることにしました。理由は資金調達の規模ではなく、上の定点観測で「後追い指示での破壊」が起きにくくなっていたからです。

調達ニュースは、判断のきっかけにはなっても、判断の根拠にはなりませんでした。根拠になったのは、自分の手元に溜めた4つの数字のほうでした。

もしいま同じ場所に立っているなら、最初の一手として定点観測の3つのお題を決めることをお勧めします。乗るにせよ見送るにせよ、来月には自分の数字で判断できるようになります。

私自身まだ手探りの部分が多く、来月の記録が読みを裏切ることも十分あり得ます。それでも記録があれば、裏切られたことに気づけます。お読みいただきありがとうございました。