5,000万DLの個人開発者がRork Maxでアプリを作り直した記録：開発時間・品質・収益の実測比較

2014年、最初のアプリをApp Storeにリリースしたとき、審査通過の通知メールを受け取った瞬間のことを今でも覚えています。Objective-Cで書いたコード、Xcodeとの格闘、深夜まで続いた試行錯誤。あれから12年、累計5,000万ダウンロードを超えるまでの道のりは、毎晩画面に向かい続けた記憶の積み重ねです。

そのわたしが、昨年末からRork Maxを本格的に使い始めました。最初は半信半疑でした。AdMob実装やApp Store審査対応まで含めた「リリースまでの全工程」をAIツールで完結できるとは想像していなかったからです。

実際に試した結果、驚いたことも、期待外れだったことも両方ありました。ここでは実際に運営している壁紙アプリ（累計200万DL超）をRork Maxで再実装した体験を、数字を添えて正直にお伝えします。

なぜ「作り直し」という選択をしたのか

再実装のきっかけは、メンテナンスコストの積み重ねでした。React Native製の壁紙アプリは、Expoのバージョンアップのたびにネイティブモジュールとの競合が起きていました。依存関係の解決に半日使うことも珍しくなく、新機能追加より「壊れていないことの確認」に時間を費やすループに陥っていました。

個人開発を続けてきた経験から言うと、この状態は「技術的負債の臨界点」です。修正コストが新規開発コストを超えた瞬間に、作り直しを検討するのが合理的な判断です。

Rork Maxを試すにあたって、以下の条件を設定しました。

• 対象アプリ: 壁紙表示・カテゴリ分類・お気に入り登録・サブスクリプション課金を備えた壁紙アプリ
• 比較基準: 従来手法（React Native + TypeScript）でゼロから実装した際の実績時間
• 測定項目: 工程別の実作業時間・生成コードの品質・App Store審査通過・AdMob表示・収益指標

従来手法での開発時間（参考値）

過去に同規模の壁紙アプリをゼロから作った際の実績です。フルタイムで集中した場合の実作業時間です。

• プロジェクト設定・Expo初期化・ライブラリ選定: 4時間
• UI設計（Figmaワイヤーフレーム）: 8時間
• 壁紙一覧・カテゴリ画面の実装: 12時間
• 画像最適化・キャッシュ処理（expo-image）: 6時間
• お気に入り機能（AsyncStorage）: 3時間
• RevenueCatサブスクリプション統合: 8時間
• AdMob実装（バナー・インタースティシャル・ATT対応）: 6時間
• App Store審査対応（プライバシーマニフェスト・スクリーンショット）: 4時間
• テスト・バグ修正: 10時間

合計: 約61時間

フルタイムで集中しても最低8日はかかる工程です。この数字は、10年以上アプリを作り続けてきた経験者の時間です。初めて同じ工程を踏む方であれば2〜3倍はかかると思います。

Rork Maxでの実装記録

実際にRork Maxで同じアプリを作り直した際の記録を、時系列で共有します。

Day 1: プロジェクト設定〜基本UI（6時間）

最初のプロンプトはシンプルに書きました。

壁紙アプリを作ってください。

要件:
- カテゴリ別に壁紙を表示（自然、都市、抽象、アニメ）
- ピンチズームで拡大表示
- お気に入り機能（ハートアイコン）
- iOS・Android両対応
- ダークモード対応

デザインは落ち着いた黒背景でミニマルに。

生成されたコードを見て、最初に驚いたのはFlashListの採用でした。FlatListではなくFlashListを使うことで、大量画像のスクロール時のパフォーマンスが最初から確保されていました。以前、自分で実装したときはFlatListで始めてパフォーマンス問題が起きてから移行するという二度手間を踏んでいたので、この選択は経験のある開発者の判断に見えました。

生成されたコードの一部（壁紙リスト画面）:

// WallpaperGrid.tsx — Rork Maxが生成したコード
import { FlashList } from '@shopify/flash-list';
import { Pressable, Dimensions, StyleSheet } from 'react-native';
import { Image } from 'expo-image';
import { useRouter } from 'expo-router';
 
const { width } = Dimensions.get('window');
const ITEM_WIDTH = (width - 3) / 2; // 2列グリッド
 
interface WallpaperItem {
  id: string;
  thumbnailUrl: string;
  category: string;
}
 
export default function WallpaperGrid({ category }: { category: string }) {
  const router = useRouter();
  // wallpapers はZustandストアから取得（生成コードに含まれている）
 
  return (
    <FlashList
      data={[]} // ストアのデータをここに
      numColumns={2}
      estimatedItemSize={ITEM_WIDTH * 1.5}
      renderItem={({ item }: { item: WallpaperItem }) => (
        <Pressable
          style={styles.item}
          onPress={() => router.push(`/wallpaper/${item.id}`)}
        >
          <Image
            source={{ uri: item.thumbnailUrl }}
            style={styles.thumbnail}
            contentFit="cover"
            transition={200}
            cachePolicy="memory-disk" // ← メモリ+ディスクキャッシュ自動設定
          />
        </Pressable>
      )}
      keyExtractor={(item: WallpaperItem) => item.id}
    />
  );
}
 
const styles = StyleSheet.create({
  item: { width: ITEM_WIDTH, height: ITEM_WIDTH * 1.5, margin: 0.5 },
  thumbnail: { width: '100%', height: '100%' },
});

cachePolicy="memory-disk" の指定や transition={200} のフェードイン設定など、実用的な細部がデフォルトで含まれていました。自分が書いても概ね同じ構造になる、という品質です。

Day 2: RevenueCatサブスクリプション統合（4時間）

ここは正直、最も懸念していた工程でした。RevenueCatの統合は、環境変数・アプリID・Entitlement設定・Webhookなどプロジェクト固有の設定が多く、AIツールが「動くコード」を生成しにくい領域です。

実際のプロンプト:

RevenueCatを統合して以下のサブスクリプションを実装してください。

- 月額プレミアム: ¥480/月
- 年額プレミアム: ¥3,800/年（月換算 ¥316）
- 7日間の無料トライアル（年額のみ）
- プレミアム特典: カテゴリ「Premium」の壁紙閲覧、広告非表示

環境変数はプレースホルダーで記述:
EXPO_PUBLIC_REVENUECAT_IOS_KEY / EXPO_PUBLIC_REVENUECAT_ANDROID_KEY

生成されたコードは予想より実用的でした。Entitlement確認のロジック、購入フロー、復元ボタン、エラーハンドリングが一通り含まれていました。

// hooks/useSubscription.ts — RevenueCatとの統合フック
import Purchases, { CustomerInfo, PurchasesPackage } from 'react-native-purchases';
import { useEffect, useState } from 'react';
 
export function useSubscription() {
  const [customerInfo, setCustomerInfo] = useState<CustomerInfo | null>(null);
  const [packages, setPackages] = useState<PurchasesPackage[]>([]);
  const [loading, setLoading] = useState(true);
 
  // Entitlement「premium」がアクティブかどうかを判定
  const isPremium = customerInfo?.entitlements.active['premium'] !== undefined;
 
  useEffect(() => {
    async function initialize() {
      try {
        const info = await Purchases.getCustomerInfo();
        setCustomerInfo(info);
 
        const offerings = await Purchases.getOfferings();
        if (offerings.current?.availablePackages) {
          setPackages(offerings.current.availablePackages);
        }
      } catch (error) {
        console.error('RevenueCat 初期化エラー:', error);
      } finally {
        setLoading(false);
      }
    }
    initialize();
  }, []);
 
  async function purchasePackage(pkg: PurchasesPackage): Promise<boolean> {
    try {
      const { customerInfo: updated } = await Purchases.purchasePackage(pkg);
      setCustomerInfo(updated);
      return true;
    } catch (error: any) {
      // ユーザーがキャンセルした場合はエラーとして扱わない
      if (!error.userCancelled) {
        console.error('購入エラー:', error);
      }
      return false;
    }
  }
 
  async function restorePurchases() {
    const updated = await Purchases.restorePurchases();
    setCustomerInfo(updated);
  }
 
  return { isPremium, packages, loading, purchasePackage, restorePurchases };
}

ただし、App Store Connect側のSandboxテスト環境の設定やRevenueCatダッシュボードでのOffering設定については当然含まれていないため、そこは自分で行いました。「コード外の設定作業」は従来と変わりません。詳細なRevenueCat統合の手順については、Rork アプリのRevenueCat収益化実装ガイドも参考になります。

Day 3〜4: AdMob実装とApp Store審査対応（5時間）

AdMobについては、ATT（App Tracking Transparency）対応を含む形で依頼しました。Rork Maxが自動的に expo-tracking-transparency の使用を提案し、UMPコンセントフォームとの統合まで含めたコードを生成した点が印象的でした。

2026年時点では、ATT・UMPの対応はApp Store審査通過の実質的な必須条件です。この最新要件をコードに反映できていたことは、プロダクション投入の観点から評価できます。ATTの最適なプロンプト表示タイミングについては、AdMob ATTオプトイン率を最大化するRork実装で詳しくまとめています。

生成されたAdMob初期化コード（抜粋）:

// app/_layout.tsx — ATT許可取得後にAdMobを初期化するパターン
import { useEffect } from 'react';
import { Platform } from 'react-native';
import mobileAds from 'react-native-google-mobile-ads';
 
// ATT許可取得（iOS 14.5以降）
async function requestTrackingPermission() {
  if (Platform.OS !== 'ios') return;
  
  try {
    const { requestTrackingPermissionsAsync } =
      await import('expo-tracking-transparency');
    await requestTrackingPermissionsAsync();
    // 許可・拒否に関わらずAdMobを初期化（結果に応じてターゲティングが変わる）
  } catch (e) {
    // 許可取得失敗時もAdMobは動作する
  }
}
 
export default function RootLayout() {
  useEffect(() => {
    async function initAds() {
      await requestTrackingPermission();
      await mobileAds().initialize();
    }
    initAds();
  }, []);
 
  // ... レイアウトの残りのコード
}

比較結果：工程別の実作業時間

Rork Maxでの実測値と従来手法の比較です。

• プロジェクト設定・UI基本実装: 24時間 → 6時間（75%削減）
• 画像最適化・キャッシュ処理: 6時間 → 2時間（67%削減）
• お気に入り機能（Zustand）: 3時間 → 0.5時間（83%削減）
• RevenueCat統合: 8時間 → 4時間（50%削減）
• AdMob実装: 6時間 → 3時間（50%削減）
• App Store審査対応: 4時間 → 3時間（25%削減）
• テスト・バグ修正: 10時間 → 4時間（60%削減）

合計: 61時間 → 22.5時間（63%削減）

「1/10」という見出しは少し誇張でした。正確には「約1/3」です。ただし、「体感的には1/10」という感覚は正直なところです。コードを書く時間より考える時間・設計する時間が明確に減り、一日に処理できる意思決定の量が変わりました。

特に削減効果が大きかったのは「UI基本実装」です。自分が書いたらどう書くかを把握しているからこそ、生成コードのレビューが速い。10年以上の経験がRork Maxの効果を最大化していると感じます。

Rork Maxが苦手だったこと

正直に書きます。Rork Maxが苦手だと感じた領域が3つありました。

1. プロジェクト固有の複雑なビジネスロジック

壁紙アプリで設定した「ダウンロード制限ロジック」（無料ユーザーは1日3枚まで、リセット時刻は日本時間午前0時）の実装で、何度か修正が必要になりました。タイムゾーン処理とローカルストレージの組み合わせで、最初の生成コードは協定世界時（UTC）を基準にしており、日本のユーザーには意図しない挙動をしました。

// ❌ 最初の生成コード（UTC基準のためJSTユーザーに誤動作）
const todayKey = new Date().toISOString().split('T')[0]; // UTC日付
 
// ✅ 修正後（JST基準に修正）
const getJSTDateKey = () => {
  const now = new Date();
  // UTC+9（JST）に変換
  const jst = new Date(now.getTime() + 9 * 60 * 60 * 1000);
  return jst.toISOString().split('T')[0];
};
const todayKey = getJSTDateKey();

このような「日本のユーザーを対象とした細かい仕様」は、プロンプトに明示しないとデフォルトでUTC基準になります。日本向けアプリを作る場合は「タイムゾーンはJST（UTC+9）を基準にしてください」とプロンプトに必ず加えることをお勧めします。

2. 既存コードベースへの安全な追加

今回はゼロからの構築だったため問題になりませんでしたが、既存のReact Nativeプロジェクトへの機能追加では難易度が上がると予想しています。既存の型定義や状態管理の構造を理解した上での変更は、現状のRork Maxだけでは完結しにくい印象があります。

3. ネイティブAPIとの深い統合

CoreMLを使ったオンデバイスAI処理や、HealthKitとの統合など、Expo管理外のネイティブAPIとの深い統合では、Rork Maxだけでは完結しませんでした。ゼロからの実装ではなく、生成コードをベースに自分でネイティブ部分を追加する形になります。

リリース後30日間の収益指標比較

再実装したアプリをTestFlightで2週間テストし、App Storeにリリースしました。旧バージョンとの30日間比較です。

• クラッシュ率: 0.8% → 0.2%（74%改善）
• 起動時間（P75中央値）: 2.1秒 → 1.3秒（38%短縮）
• サブスクリプション転換率: 2.3% → 2.8%（0.5ポイント向上）
• AdMob eCPM: $0.82 → $0.85（横ばい）

パフォーマンス改善が転換率向上に直接寄与したかどうかは断定できませんが、UIの応答速度が体感で明らかに向上していることは確認しています。クラッシュ率の改善は、FlashListへの移行と画像キャッシュ設計の改善が大きかったと分析しています。

AdMob収益については、eCPMはほぼ横ばいでした。広告収益はATTオプトイン率とインプレッション数に大きく依存するため、アプリの再実装だけで劇的に変わるものではありません。AdMobで月150万円以上を達成していた時期の経験から言うと、収益最大化の鍵はコードの品質より「広告配置の設計」と「ATTオプトイン率」にあります。その知見はAdMobで月収150万円を達成した個人開発の収益モデルに詳しくまとめています。

「手を動かすことが一つの信心だ」

宮大工だった両祖父が語っていた言葉を、アプリ開発を続ける中で何度も思い出しています。祖父たちは、一本の柱を削り、継ぎ手を合わせる作業に、技術と精神の両方を注いでいました。ツールが変わっても、「丁寧に作ること」への信念は変わらなかった。

Rork Maxで開発速度は上がりましたが、アプリという「作品」に魂を込める作業は相変わらず自分の手で行うしかないと感じています。どんなアプリを作るか、どんな課金モデルにするか、どのユーザー層に届けるか、そういった問いに答えを与えてくれるわけではありません。

ただ、1997年に16歳でインターネットに出会い、独学でプログラミングを学んで国境を越えてデザイナーやエンジニアと繋がったとき感じた種類の驚き、あの「ツールが変わることで届けられるものの量と質が変わる」というポジティブさが、Rork Maxにあります。それは素直に享受したいと思っています。

個人開発者がRork Maxを試す前に確認しておきたいこと

12年の実践経験から、正直にお伝えします。

向いている用途:

• 壁紙・癒し・習慣トラッカー系など、データ構造がシンプルなアプリ
• MVPを早く市場に出して検証したい場面
• 既存アプリの機能を別プラットフォームに展開したい場合

向いていない用途:

• 既存のReact Nativeコードベースへの大規模な機能追加
• 複雑なオフライン同期・リアルタイム同期の実装
• Unity的な描画処理が必要なゲームアプリ

コスト観点: Rork Maxの月額費用と、節約された開発時間を時給換算で比較すると、今の私の場合は明らかにプラスです。ただし「節約された時間で何を作るか」が重要で、単純にアプリの本数を増やすだけでは意味がないと感じています。

次にRork Maxで構築する予定のプロジェクトは、引き寄せ系アプリの新版です。5,000万DLの実績があるカテゴリの一つですが、UIと課金モデルを現代化したバージョンをRork Maxで試みています。その記録もいずれここで共有できればと思っています。

まず試してみるなら、小さく始めることをお勧めします。今運営しているアプリの1機能だけをRork Maxで試作し、自分のプロジェクトとの相性を確かめるのが、最もリスクの低い始め方です。