Rork のコード生成は本番に使えるか — 累計5,000万DL開発者が実機テストで見つけた3つの落とし穴

アプリを12年作り続けて、累計5,000万ダウンロードを超えた頃に気づいたことがあります。「コードの質が一定を下回ると、ダウンロード数が増えれば増えるほど、クラッシュ報告も増える」という、シンプルで残酷な事実です。

最近、いくつかの場面でRorkを試しています。AIがコードを生成してくれるのは便利ですが、実際に実機テストを重ねると、「動くコード」と「本番で安定するコード」の間に確実なギャップがあることが分かってきました。

「Rorkは使えるのか」という問いへの、現場目線の正直な回答をまとめました。Rorkが生成するコードを実際の開発現場に持ち込んだときに直面した3つの落とし穴と、それぞれの対処法を紹介します。

落とし穴①：リスト表示の並行処理でクラッシュが起きる

Rorkが生成するリスト表示コンポーネントは、視覚的には完成しています。スクロール、グリッドレイアウト、サムネイル表示——見た目の動作は概ね期待通りです。ところが、ユーザー数が増えてきたとき、特定の操作パターンでクラッシュが発生しやすい構造が隠れています。

Beautiful HD Wallpapers（iOS/Android、累計5,000万DL超）のAndroidアプリをv2.0.0にアップデートした後、28日間で50ユーザー以上からのクラッシュ報告が集まりました。原因を追跡すると、RecyclerViewのIndexOutOfBoundsExceptionでした。表示中のリストデータが別スレッドから更新されるタイミングで、インデックスの整合性が崩れるケースです。

// ❌ Rork が生成しやすいパターン（並行アクセスで危険）
private var wallpaperList: MutableList<Wallpaper> = mutableListOf()
 
fun updateWallpapers(newList: List<Wallpaper>) {
    wallpaperList.clear()
    wallpaperList.addAll(newList)
    adapter.notifyDataSetChanged()  // UIスレッド外から呼ぶと危険
}
 
// ✅ 防御的コピーを使った安全なパターン
fun updateWallpapers(newList: List<Wallpaper>) {
    val safeCopy = newList.toMutableList()  // 防御的コピーで元リストの変更を遮断
    runOnUiThread {
        wallpaperList = safeCopy
        adapter.notifyDataSetChanged()
    }
}

v2.1.0でこのパターンに修正したところ、クラッシュ報告はほぼゼロになりました。Rorkが生成するリスト系コンポーネントを本番で使うときは、必ずデータ更新の並行処理パターンを確認してください。

これは「Rorkが悪い」という話ではなく、「AIが生成するコードは基本的なケースに最適化されている」という特性の話です。1,000ユーザーの段階では問題が顕在化せず、50,000ユーザーを超えたあたりから急に増えるのが、この種のバグの特徴です。並行処理のエッジケースは、使用状況が多様になるほど表面に出てきます。

落とし穴②：ライブラリのバージョン互換性

Rorkが生成するコードは、おおむね現行バージョンのライブラリを参照します。ただし、マイナーバージョンの組み合わせによっては実行時エラーが出ることがあります。

直面したのは、Glide 5.0.5とAndroid Gradle Plugin 9.xの組み合わせでした。java.lang.NoClassDefFoundError: java.util.function.Supplierというエラーで、Android 6.0.1端末だけがアプリ起動時にクラッシュしていました。エミュレーターでは一切再現せず、特定OS世代の実機でのみ発生するため、開発環境では見つけられないタイプのバグです。

// build.gradle の compileOptions に追加が必要
android {
    compileOptions {
        // この1行がないと Android 6 でクラッシュする
        coreLibraryDesugaringEnabled true
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}
 
dependencies {
    // coreLibraryDesugaring の追加
    coreLibraryDesugaring 'com.android.tools.build:desugaring:2.0.4'
}

coreLibraryDesugaringEnabled trueの1行追加で、Android 6.0.1ユーザー全員のクラッシュが消えました。Rorkが生成するbuild.gradleには、この設定が含まれないことが多いので注意が必要です。

解決策は明快ですが、「特定のOSバージョンの端末でだけ起きる」「ライブラリのマイナーバージョンの組み合わせが原因」というクラッシュを見つけるには、実機テストが必須です。Rorkで生成したコードを使う場合も、最小サポートOSバージョンの実機テストは省略できません。Android 6（API 23）からサポートしているアプリなら、必ずその世代の端末か互換エミュレーターで確認することをおすすめします。

落とし穴③：広告ゲートロジックの入れ子構造

AdMobの広告表示を制御するロジックは、Rorkが生成してもそれなりに動きます。ただし、広告あり/なし（課金済み）の判定と、報酬広告視聴済みの判定を組み合わせると、入れ子構造になりがちです。

// ❌ 入れ子で複雑になるパターン（Rork が生成しやすい）
if (!isPremiumUser()) {
    if (isRewardAdWatched()) {
        showContent()  // どの条件でここに来るか追いにくい
    } else {
        showAd()
    }
} else {
    showContent()
}
 
// ✅ 並列独立構造（意図が明快、テストも容易）
val isAdFree = isPremiumUser() || isRewardAdWatched()
if (isAdFree) {
    showContent()
} else {
    showAd()
}

Rorkが生成する広告ロジックは、前者の入れ子スタイルになることがあります。小規模なアプリでは問題ないですが、広告の種類（バナー・インタースティシャル・報酬動画）が増えると、デバッグが格段に難しくなります。isAdFreeのようなSource of Truthを一箇所にまとめる設計を推奨します。

壁紙アプリのような「広告あり → 報酬動画で一時無効化 → 課金で永続解除」という3段階の広告ゲートを実装するとき、入れ子構造の問題が特に顕著になります。2014年からアプリ事業を続けてきた中で、この構造を後から直すコストは想像以上に大きいと実感しています。最初からisAdFreeという単一の判定軸を設けておくことが、将来の自分を助けることになります。

12年の経験から見た「Rork コードの正しい受け取り方」

「生成されたコードを鵜呑みにするか、全部書き直すか」という二択では、現場では機能しません。正しいのは「生成コードを起点にして、クラッシュパターンを体系的に検証する」という姿勢です。

Rorkが出力するコードは「動作確認済みのプロトタイプ」として受け取り、本番リリース前に以下の確認を習慣にしています。

リスト系UIはデータ更新の並行処理パターンを確認する
最小サポートOSバージョン（Android 6 / iOS 14など）の実機でテストする
広告・課金の判定ロジックにisAdFreeのような単一のSource of Truthを設ける
異常系（ネットワーク切断・端末回転・バックグラウンド移行）の動作を確認する

両家の祖父が宮大工だった影響で、「手を動かして確認することが一つの誠実さ」という感覚が自分にはあります。AIが生成したコードも、手を動かして確認しながら育てていく姿勢が、長期的に安定したアプリにつながると感じています。これはAIへの不信ではなく、長く使われるものを作るための作法だと捉えています。

実際の使い分けと判断基準

RorkはUIとビジネスロジックの初期骨格を作るのに適しています。一方、本番品質を担保するための並行処理、異常系処理、ライブラリ互換性の確認は、生成コードをベースに手を動かして加える必要があります。

「Rorkで作ってそのままリリース」より「Rorkで90%作って10%直す」が現実的なワークフローです。累計DLが1万を超えてきたあたりから、クラッシュ率0.3%以内の維持が重要になってきます（Google Playの推奨基準）。Rorkが生成した段階では、まだそのレベルには届かないことが多いです。

それでも、ゼロからコードを書く時間と比べると、生産性の差は明確です。アイデアを実装に変える速度において、Rorkは現時点でも有力な選択肢です。個人開発で一人で複数のアプリを維持している立場からすると、プロトタイプを短時間で作れることの価値は大きいです。

rork.com でシンプルなアプリを1本生成して、この記事で挙げた3つの落とし穴を実際に確認してみてください。本番アプリへの組み込みの判断は、それからでも遅くありません。同じ課題に取り組んでいる開発者の参考になれば幸いです。

Rorkで生成したコードの品質をより深く理解したい方には、Expo公式ドキュメントのReact Native並行処理のセクションも参考になります。並行処理の考え方はRorkが出力するコードにも共通して適用できます。実際に手を動かして確認する習慣をつけることが、長期的に安定したアプリ運営の基盤になると感じています。個人開発者としてアプリを一人で維持していく以上、クラッシュ修正の手戻りコストは最小化したいところです。その意味で、リリース前のこの確認ステップは省けません。