OnspaceとRork Max、複雑なロジックはどちらに任せるか — 決済・非同期・権限分岐で使い比べた記録

「複雑なロジックのあるアプリは、RorkとOnspaceのどちらで作るべきですか」という質問に、以前は「場合によります」としか答えられませんでした。歯切れの悪い回答になってしまうのは、私自身の中に比較の物差しがなかったからです。

そこで、決済・プッシュ通知・ユーザー権限分岐を含む同じ要件を両方のツールに渡し、生成されたものを並べて確かめることにしました。単純なCRUDアプリではなく、バックエンド連携・状態管理・エラーハンドリングが絡む中規模アプリを想定した比較です。

OnspaceとRork Maxの設計思想はどう違うか

ご存じない方のために簡単に整理しておきます。Onspaceは2025年後半から注目を集めてきたAIアプリビルダーで、バックエンドのワークフローをビジュアルに定義する仕組みを重視しています。フロントエンド生成よりも「データフローと処理の自動化」寄りの設計思想です。

一方のRork Maxは、React NativeのTypeScriptコードを直接生成し、Expoプロジェクトとして出力するアプローチを取ります。コードが手元に残るため、想定外の挙動もコードレベルで直せる余地があります。

つまり両者は「同じ市場の競合」というより、複雑さのどの側面を引き受けるかが最初から違うツールです。この前提を押さえると、後述の結果がすっきり読めるはずです。

「複雑なロジック」をどう定義したか

比較の前に、「複雑なロジック」が何を指すかを揃えておきます。今回は以下の4点を含む要件を想定しました。

外部API（決済、地図、AI）との連携が複数ある
非同期処理が失敗したときのフォールバック処理が必要
ユーザーの状態（認証・サブスクリプション・権限）によって表示内容が変わる
バックグラウンド処理（プッシュ通知、定期実行）がある

チュートリアルを卒業した実用アプリなら、ほぼ必ずどれかに突き当たる要素です。

検証に使った題材 — 環境音アプリにサブスクと通知を足す

抽象的な比較にならないよう、個人開発で実際に扱った構成を簡略化して題材にしました。要件は次の通りです。

環境音をループ再生するプレイヤー（無料機能）
サブスク加入者だけが追加音源と長時間タイマーを使える権限分岐
決済はStripe。解約・期限切れ時は無料表示に静かに戻すフォールバック
毎晩決まった時刻に再生を促すリマインダー通知

環境音のループ再生だけでも、Rork で癒し系アプリのアンビエントサウンドを実装して詰まった3つのことで書いたように、最初の生成がそのまま使えるとは限りません。そこに決済と権限分岐が重なったとき、それぞれのツールがどう振る舞うかを見ていきます。

Rork Maxが有利だった場面

コードの透明性とカスタマイズ性。 Rork Maxが生成するのはReact Native + ExpoのTypeScriptコードで、そのままGitHubにpushして管理できます。複雑なロジックで「AIが想定外のコードを書いた」ときに、自分の手で直せる余地が大きいことは想像以上の安心材料でした。

実際に生成された決済まわりの骨格はこの形でした。

// Rork Maxが生成したStripe連携のエラーハンドリング骨格
const handlePayment = async (amount: number) => {
  try {
    const paymentIntent = await createPaymentIntent(amount);
    const { error } = await stripe.confirmPayment({
      clientSecret: paymentIntent.clientSecret,
    });
    if (error) {
      // ここを自分でカスタマイズできる
      handlePaymentError(error.type, error.message);
    }
  } catch (e) {
    // ネットワークエラー等のフォールバック
    showToast("接続エラーが発生しました。もう一度お試しください。");
  }
};

この骨格をベースに、解約時のフォールバック表示やリトライ条件を書き足していく作業は、ゼロから書くよりずっと速く進みました。AIが配管を用意し、判断の部分を人間が書く分担です。

プロンプトの粒度が結果を左右する。 ただし、要件をまとめて渡すとうまくいきません。最初に「決済とサブスク権限と通知をまとめて実装してください」と渡したところ、決済完了前に権限フラグが立つ順序の混乱が起きました。「決済フローだけ」「権限分岐だけ」と処理単位に分けて順番に渡すと、各ステップの生成精度は目に見えて安定します。この感覚はRorkでアプリを「作り切る」ために知っておくべきプロンプト設計の原則で書いた内容とも一致しています。

React Nativeエコシステムとの親和性。 標準的なExpoプロジェクトが出力されるため、npmパッケージをそのまま追加できます。react-queryやzustandのような成熟したライブラリで状態管理を補強できるのは、複雑なロジックほど効いてきます。認証まわりを外部サービスに任せたい場合も、Rork でユーザー認証を実装する — Firebase・Supabase 連携ガイドで整理した構成がそのまま使えます。

Onspaceが有利だった場面

ノーコードでのデータフロー定義。 「フォーム入力 → バックエンド保存 → 通知送信」のような一方向のデータフローは、Onspaceのビジュアルフローエディタで素早く組めます。リマインダー通知の定期実行も、コードを書かずにスケジュール設定だけで動きました。技術的な背景が薄いメンバーが流れを目で追えるのは、チームでの開発では効く場面があると思います。

バックエンドの管理が不要。 Onspaceは内蔵のバックエンドインフラを提供しており、サーバー管理やスケーリングを意識せずに済みます。Rork MaxではFirebaseやSupabaseを自分で選んで設定する必要があり、ここは明確にOnspaceが軽い部分です。

想定外だった挙動 — 両ツールの限界

使い比べて気づいた「事前情報からは見えなかった部分」を率直に書きます。

Rork Maxの限界。 直列と並列の非同期処理が混在するフロー（決済確認を待ってから権限を更新し、その間にUIは楽観的更新する、など）は、1回のプロンプトで正確に生成されることがほとんどありませんでした。生成→動かす→ずれを指摘する、の反復が前提です。また、生成済みコードに対するテストコードの生成は精度が安定せず、複雑なロジックほど自分でテストを書く必要を感じました。

Onspaceの限界。 条件分岐が3段を超えたあたりから、ビジュアルフローは急に読みにくくなります。サブスクの状態×通知許可の有無×初回起動かどうか、のような掛け合わせ分岐を組んだ時点で、フロー図はコードより追いにくくなりました。結局カスタムコードを書く場面が出てくるなら、最初からコードが手元にあるほうが私には扱いやすかったです。フロントエンドのカスタマイズ余地もRork Maxより狭く感じました。

私の判断基準

両方を試したうえで、いま使っている判断基準を整理します。

Rork Maxを選ぶとき:

React Nativeの知識がある、または学ぶ意欲がある
最終的にコードを手元に持ちたい
App Store / Google Playへの配信が目標
複雑なUIアニメーションやネイティブ機能（カメラ、Bluetooth等）が必要

Onspaceを選ぶとき:

バックエンドのワークフロー自動化が主目的
技術的な背景が混在するチームで使う
外部配信よりも社内ツール寄りのプロトタイプを素早く作りたい

「複雑なロジック」の中身がバックエンド処理の自動化に近いならOnspace、モバイルアプリとしての複雑さ（UI・ネイティブ機能・配信）に近いならRork Max、というのが現時点の私の結論です。継続コストも判断材料になるので、Rork側の料金体系はRorkの料金プランを正直に比較する：無料・Pro・Maxの違いと個人開発者が損しない選び方で整理した内容をあわせて参照してみてください。

小さく試して見極める手順

最後に、これから選ぶ方へ。カタログスペックの比較よりも、次の順序で小さく試すほうが確実です。

自分のアプリの要件を「画面」ではなく「処理」の単位で箇条書きにする
その中でいちばん複雑な処理を1つだけ選び、両方のツールに同じ文面で渡す
生成結果そのものより、ずれていた部分を自分で直せそうかを見る
直せると感じたほうに、残りの処理を順番に渡していく

どちらのツールも進化が速く、数ヶ月後には状況が変わっている可能性があります。だからこそ、最新のレビュー記事を探すより、手元のいちばん複雑な処理を1つ渡してみることをおすすめします。同じ判断で迷っている方の参考になれば幸いです。