私が最初に作ったアプリを App Store に出したのは2014年でした。当時はサーバーもストアの審査も全部自分で触らないと何も動かず、それが結果として「全部持ち出せる」状態を作っていました。ノーコードでアプリを生成できる今は、その逆の心配が生まれます。便利さと引き換えに、自分のアプリがプラットフォームの中に閉じ込められていないか、という心配です。
Rork で説明文からアプリが立ち上がる体験は確かに気持ちのよいものです。ただ、個人開発で収益を狙うなら、最初の数日で考えておきたいのは見た目や機能ではありません。「このツールから離れることになっても、作ったものを連れて出られるか」です。今日はそこを、Rork と Rork Max の構造の違いに沿って整理します。
「出口」を最初に設計するという発想
事業を始めるときに撤退を考えるのは縁起が悪いように聞こえますが、実際は逆です。出口が見えているほど、安心して投資できます。月額 $25 の Rork も $200 の Rork Max も、価格が変わったりサービス方針が変わったりする可能性はゼロではありません。2026年に Rork が $15M を調達したことはツールの持続性にとって明るい材料ですが、それでも「依存しても大丈夫」と「いつでも離れられる」は別の話です。
私は新しいツールを業務に入れるとき、必ず次の3つを確認しています。
自分が作ったデータを、いつでも構造化された形でエクスポートできるか
生成されたコードを、プラットフォーム外で動かせる形で取り出せるか
課金やユーザー基盤を、別の手段に引き継げるか
この3点が揃っていれば、ツールは「資産を増やす道具」になります。揃っていなければ、それは「資産を預ける金庫」であり、鍵を相手が持っている状態です。
Rork と Rork Max でロックインの深さが違う
ここが最も大切な見極めです。同じ Rork ブランドでも、出力されるものの性質がまったく違います。
通常の Rork は Expo（React Native）を基盤にアプリを生成します。つまり出力は React Native のプロジェクトであり、これは世界中に膨大な開発者と資料がある標準的な技術です。一方 Rork Max は Swift コードを直接生成し、ブラウザ上の iOS シミュレータや自動の App Store 公開といった独自の体験で包んでいます。生成物の標準性という意味では React Native のほうが「持ち出しやすい」側にあります。
私自身の判断としては、収益化を本気で狙うアプリの土台には、まず Expo ベースの Rork を選ぶようにしています。理由は単純で、いざというときの脱出経路が広いからです。Swift 生成はネイティブ機能の深さで魅力的ですが、独自体験に依存する分、外へ出る道は相対的に狭くなります。
データを最初から外に出せる形にしておく
機能を作り込む前に、データの持ち出し口を用意しておくことを強くお勧めします。アプリ内のデータをプラットフォーム任せにせず、自分が管理できるバックエンド（Supabase などのマネージド Postgres）に置いておくと、ツールを乗り換えてもユーザーのデータは手元に残ります。
// データ層はツールに依存しない薄いクライアントに隔離する // アプリのどこからも、この関数経由でしか保存・取得しない import { createClient } from "@supabase/supabase-js" ;
const db = createClient ( process.env. EXPO_PUBLIC_SUPABASE_URL ! , process.env. EXPO_PUBLIC_SUPABASE_ANON_KEY ! );
export async function saveEntry ( userId : string , entry : Record < string , unknown >) { // 保存先を1か所に集約しておくと、後でバックエンドを差し替えても // 画面側のコードを一切触らずに済む const { error } = await db. from ( "entries" ). insert ({ user_id: userId, ... entry }); if (error) throw error; }
export async function exportAll ( userId : string ) { // 「いつでも全部出せる」を関数として用意しておく — これが出口の実体 const { data } = await db. from ( "entries" ). select ( "*" ). eq ( "user_id" , userId); return data ?? []; } ポイントは exportAll のような関数を、機能要件になくても最初に書いておくことです。ユーザーから「データを返してほしい」と言われたときに対応できるだけでなく、自分がツールを移行するときの避難はしごにもなります。月に数万円の収益が出てから「データが取り出せない」と気づくのが、いちばん避けたい事態です。
コードの脱出経路を2本用意しておく
Expo ベースで作っておくと、出口が2方向に開きます。
ひとつは Expo の prebuild（いわゆる eject）です。Rork が生成した Expo プロジェクトを手元に取り出し、ネイティブのプロジェクトとして展開できれば、以降は Rork なしでもビルドを続けられます。
# 生成された Expo プロジェクトをネイティブプロジェクトへ展開する # これが通れば、以降はツールに依存せず自分でビルドを回せる npx expo prebuild --clean
# 生成された ios / android ディレクトリで通常のネイティブビルドが可能 npx expo run:ios もうひとつは、2026年に Android Studio がプレビューした移行エージェントです。React Native のコードを解析してネイティブ Kotlin アプリへ自動移行する機能で、これは Rork（Expo）で出したアプリの「将来の引っ越し先」として現実味があります。Swift 生成からは、こうした標準ツールによる自動移行の恩恵を受けにくいことも、土台選びの判断材料になります。
実務上の注意点として、prebuild は一度実行するとネイティブディレクトリが生まれ、それ以降の Rork 側の自動更新と衝突しやすくなります。ですので「いつでも eject できる準備はしておくが、収益が安定して移行を決断するまでは実行しない」という運用にしています。準備と実行を分けて考えるのが、ロックイン対策の現実的なバランスです。
課金とユーザー基盤を「持ち出せる資産」にする
意外と見落とされがちですが、いちばん移行が難しいのは課金とユーザーです。サブスクリプションを RevenueCat のような中間層で管理しておくと、ストアの仕組みやアプリの実装が変わっても、課金状態の真実は手元に残ります。AdMob による広告収益も、メディエーション設定を自分のアカウントで管理しておけば、アプリの作り直しに伴って失われることはありません。
私が運用しているアプリでは、課金まわりは必ず「アプリの実装」と「収益の記録」を分離するようにしています。アプリは作り直すかもしれませんが、誰がいつ課金してくれたかという履歴は、事業の背骨だからです。LTV やリテンションの数字も、自分が管理するデータとして持っておくと、ツールを変えても判断の連続性が保てます。
結論として、最初の設計に少しだけ時間を割く
ノーコードの魅力は速さですが、その速さに任せて出口のないアプリを量産すると、収益が育ったときに身動きが取れなくなります。逆に、データ・コード・課金の3点を最初から「持ち出せる形」にしておけば、Rork で素早く出して、必要なら Rork Max のネイティブ機能へ広げ、いざとなれば eject や Kotlin 移行で外へ出る、という多段の自由が手に入ります。
次の一歩として、いま作っているアプリに exportAll に相当する持ち出し関数がひとつでもあるか、確認してみてください。そこが出口設計のいちばん小さな第一歩になります。お読みいただきありがとうございました。