WWDC26の後で、個人開発が「いま作るもの」を選び直す

無償枠が外したのは、どのブレーキだったのか

問い1の答えは、感覚ではなく計算で出せます。外部 API に払っていた額が企画のどこを止めていたのかを、手元の Node で確かめました。

// ai-cost-model.mjs — 外部API課金が企画のどこを止めていたかを数字にする
const PRICE_IN = 0.15 / 1e6;   // USD / 入力トークン（小型モデルの想定単価）
const PRICE_OUT = 0.60 / 1e6;  // USD / 出力トークン
const USDJPY = 155;
const PRICE = 500;             // 月額（円）
const STORE_FEE = 0.30;        // ストア手数料
 
const profiles = [
  { name: "軽い（要約を1日1回）",   calls: 2,  tin: 400,  tout: 150 },
  { name: "日課（毎朝ひとつ示唆）", calls: 10, tin: 800,  tout: 300 },
  { name: "常時（入力ごとに解釈）", calls: 40, tin: 1500, tout: 500 },
];
 
// 1DAUあたりの月額AIコスト（円）
const costPerDau = (p) =>
  p.calls * 30 * (p.tin * PRICE_IN + p.tout * PRICE_OUT) * USDJPY;
 
for (const p of profiles) {
  const c = costPerDau(p);
  const breakevenCvr = c / (PRICE * (1 - STORE_FEE));
  console.log(
    `${p.name} : 1DAU ${c.toFixed(2)}円/月 / DAU5000で ${(c * 5000).toFixed(0)}円/月 ` +
    `/ 損益分岐の課金転換率 ${(breakevenCvr * 100).toFixed(2)}%`
  );
}

Node v22.22.3 で実行した出力を表にしました。単価はモデルによって上下しますので、桁の感覚として読んでください。

読み取れたのは、私が思っていたのとは違う形でした。1日1回の要約程度なら、外部 API でも 1DAU あたり月1.4円です。課金転換率0.40%で元が取れる計算で、これは無償枠がなくても普通に成立していました。ブレーキがかかっていたのは、そこではなかったのです。

止まっていたのは「日課」から先でした。毎朝ひとつ示唆を返すだけで、損益分岐の転換率は3.99%まで上がります。個人開発で現実に出る課金転換率が2〜4%あたりであることを踏まえると、ここはちょうど採算の境界線の上です。入力のたびに解釈を返す設計にいたっては27.90%が必要で、事実上どうにもなりません。

つまり無償枠が外したのは「AI を足せるかどうか」のブレーキではありません。「AI を毎日回せるかどうか」のブレーキでした。問い1と問い2は、同じことを別の角度から聞いていたわけです。クラウドを経由せずに端末側で完結させる選択肢については、Rorkで作るAIアプリにオフラインエッジモデルを組み込むでも触れています。

問い2：継続して開く理由が、機能の中にあるか

企画段階で最も見落とされるのが継続理由です。賢い機能があっても、一度使えば満足してしまう体験では、継続率は伸びません。私が運用してきたアプリで長く残ったのは、毎日少しずつ意味が生まれるものでした。

オンデバイス AI は、ここで効きます。たとえばユーザーのデータをその場で解釈して、今日の小さな気づきを返す、という体験は、外部 API では躊躇するコストでも、無償枠なら毎日回せます。企画の段階で「この機能は、毎日開く理由になるか」を言葉にしてください。ならないなら、それは単発の便利機能であって、事業の核にはなりにくいです。

問い3：課金導線が、企画の中に最初からあるか

個人開発で収益を狙うなら、課金は後付けではなく企画の一部です。私は企画書の段階で、無料で提供する価値と、課金してもらう価値の線をはっきり引くようにしています。

企画書に最初から書く3行（私が使っているテンプレート）
- 無料で渡す価値： 毎日開きたくなる体験の核（継続の燃料）
- 課金で渡す価値： 無料体験を深める拡張（広告除去 / 上限解放 / 高度なAI）
- 課金の置き場所： ユーザーが価値を実感した直後の自然な瞬間

オンデバイス AI の文脈では、「軽い AI 機能は無料、重い・高頻度の AI 機能は課金」という線引きが自然に効きます。無償枠にも実質的な利用の現実があるため、ヘビーユーザーには有料プランで支えてもらう設計が、無理なく成立します。AdMob による広告と RevenueCat によるサブスクリプションを併用するなら、その配分も企画段階で決めておきます。

問い4：Rork で最小の形を、何日で検証できるか

企画が筋のよいものでも、検証に時間がかかりすぎると勢いが死にます。ここで Rork（Expo）の速さが効きます。私は新しい企画を、まず Rork で最小限の形にして共有リンクで触ってもらい、継続理由が本物かを数日で確かめるようにしています。

最小検証で見るのは「数」ではなく「翌日また開いたか」
1. Rork で核となる1画面だけを生成し、共有リンクで配る
2. 5〜10人に1週間使ってもらう
3. 翌日も開いたか / 1週間後も残ったかだけを見る
4. 残らなければ企画を捨てる。残れば次の問いへ進む

この段階で月 $200 の Rork Max を払う必要はありません。プラン差の実際についてはRorkの料金プランを正直に比較するにまとめています。Expo ベースの Rork で核を検証し、継続理由が本物だと確信できてから、ネイティブの深さが必要かを判断すれば十分です。企画の検証に高い投資を先払いしないのが、個人開発の現実的なリズムです。

5人のテストで言えること、言えないこと

問い4で「5〜10人に配って、翌日また開いたかを見る」と書きました。ただ、この人数で何がどこまで言えるのかを、私はずっと曖昧なまま運用してきました。二項比率の信頼区間で確かめます。

// retention-signal.mjs — 少人数の「翌日また開いた」から何が言えるか
const Z = 1.96;
 
function wilson(k, n) {
  const p = k / n, d = 1 + Z * Z / n;
  const c = p + Z * Z / (2 * n);
  const s = Z * Math.sqrt((p * (1 - p) + Z * Z / (4 * n)) / n);
  return [(c - s) / d, (c + s) / d];
}
 
for (const n of [5, 8, 10, 20, 30, 100]) {
  const [lo, hi] = wilson(Math.round(n * 0.5), n);  // 半分が開いた場合
  const [lo2] = wilson(n, n);                       // 全員が開いた場合
  console.log(
    `n=${n} : 半分なら D1 ${(lo * 100).toFixed(1)}〜${(hi * 100).toFixed(1)}%` +
    `（幅 ${((hi - lo) * 100).toFixed(1)}pt） / 全員なら下限 ${(lo2 * 100).toFixed(1)}%`
  );
}
 
for (const p of [0.3, 0.4, 0.5]) {
  console.log(
    `真のD1=${(p * 100).toFixed(0)}%でも 3/3 は ${(p ** 3 * 100).toFixed(1)}%、` +
    `5/5 は ${(p ** 5 * 100).toFixed(1)}% の確率で起きる`
  );
}

半分が開いた程度の結果には、ほとんど情報がありませんでした。8人中4人という観測から言えるのは「本当の D1 は21.5%から78.5%のどこか」だけです。幅57ポイントの区間を根拠に企画の生死を決めるのは、コインを投げているのとあまり変わりません。

一方で、全員が戻ってきた場合は話が別でした。5人全員が翌日も開いたなら、D1 の下限は56.6%まで持ち上がります。真の D1 が30%しかないアプリで5人連続の再訪が起きる確率は0.2%、40%のアプリでも1.0%です。少人数テストは、揃った結果に対してだけ強いのです。

そこで私は問い4の見方を、こう言い直すことにしました。割れた結果は情報がないものとして捨て、全員が戻ってきた企画だけを次へ進める。 6人中4人という中途半端な結果を「まずまず」と解釈して先へ進むのが、時間の使い方としてはいちばん高くつきます。ここで残った企画をどう削除されない形に育てるかは、Rork で作ったアプリを「削除されない」ものにするで別途扱っています。

問い5：伸びたとき、どこまで深くできる余地があるか

最後の問いは、上限の高さです。検証で残った企画が、その後どこまで深くできるかを企画段階でうっすら見積もっておきます。Rork（Expo）で出した核が、いずれウィジェットや Live Activities、オンデバイス Core ML といったネイティブの深さを必要とするなら、その時点で Rork Max への段階的な移行が選択肢に入ります。どこまでが生成で届き、どこからが手作業になるのかはRork Max で届かない領域はどこかで線を引いています。

私はこれを「多段の企画」と呼んでいます。最初から完成形を狙うのではなく、Rork で素早く出し、継続理由を確かめ、伸びたらネイティブで深くする。各段で投資と確信を釣り合わせるこのやり方が、限られた時間で個人開発を続けるうえでいちばん消耗しません。

結論：前提が変わったら、企画も並べ直す

オンデバイス AI が個人開発者に無償開放されたことは、新しい機能がひとつ増えた、という話ではありません。「何を作るべきか」の前提が動いたという話です。AI コストを言い訳に諦めていた企画が、いま採算に乗るかもしれません。

次の一歩として、温めているアプリのアイデアを3つ書き出し、それぞれを今日の5つの問いに通してみてください。いちばん多く Yes がついたものが、あなたが Rork で最初に検証すべき企画です。私自身まだ学びの途中ですが、共に考えていけたら嬉しいです。