◉ AIモデル/2026-06-24中級

Rork Max の AI 機能を本気で使い倒す — Vibe Coding を超える実装力の引き出し方

Rork Max を実装パートナーとして使い倒すための深掘りガイドです。プロンプト設計とコンテキスト管理に加え、無印 Rork と Rork Max の選び分け、クレジットを無駄にしない作り方、App Store 提出前の検証までを、個人開発の実体験からまとめました。

Rork Max²²⁹ AI³¹ Vibe Coding² プロンプトエンジニアリング⁴ ネイティブアプリ²⁰ 実装力

✦ プレミアム記事

import { Callout } from '@/components/ui/callout';

Rork Max を「Vibe Coding ツール」として紹介する記事はたくさんあります。私自身、最初は「自然言語でアプリを作れる」という側面に惹かれて触り始めました。しかし数週間使い込んでみると、Rork Max の AI 機能にはもっと深い使い方があることに気付きました。

ここでは表面的な使い方の先にある、Rork Max を実装パートナーとして使うためのテクニックを共有します。私が個人開発で複数のアプリを作ってきた経験をベースに、実際に質を引き上げてくれた工夫を中心に整理します。

Rork Max の AI 機能は何が特別なのか

他の AI コーディングツールと比べたとき、Rork Max には3つの特徴的な強みがあります。

強み1: ネイティブアプリの完全な生成

ほとんどの AI コーディングツールは Web アプリ生成を主軸にしていますが、Rork Max は最初から iOS / Android のネイティブアプリ（React Native + Expo ベース、SwiftUI ネイティブ生成も可）を出力できる設計です。「アプリを作るための AI」として最適化されているため、モバイル特有の課題（プッシュ通知、決済、認証、画面遷移）を理解した上でコードを生成してくれます。

強み2: 機械学習による生成最適化

裏側で独自の機械学習最適化が走っており、過去の生成パターンとフィードバックから「どういうコード構造が動きやすいか」を学習しています。これは Anthropic / OpenAI のモデルに丸投げするだけのツールにはない強みで、React Native のバージョン互換性や Expo の特定 API の使い方など、細かい部分での精度が高いと感じます。

強み3: Companion アプリでの即時実機テスト

生成したコードを iOS/Android の実機で即座にテストできる Rork Companion との連携は、開発体験を大きく変えます。シミュレータでは見えないネイティブ機能（カメラ・GPS・センサー）を含めて、即座に手元で確認できます。

これら3つを意識して使うと、Rork Max は単なるノーコードツールから「実装パートナー」に変わります。

プロンプト設計の3つの基本

Rork Max でいいコードを引き出すためのプロンプト設計には、私なりの型があります。

型1: 機能を「画面」と「データ」で分けて伝える

良いプロンプト例:

タスクを管理するアプリを作りたいです。
画面構成:
1. ホーム画面 — 今日のタスク一覧、未完了が上、完了済みが下
2. タスク追加画面 — モーダルで開く、タイトル・期日・優先度を入力
3. 詳細画面 — タスクをタップしたとき、編集と削除ができる

データモデル:
- Task: id, title, dueDate, priority (low/medium/high), isCompleted
- ローカル保存（後で Supabase に移行する想定なので、データ層は分離してください）

使う技術:
- React Native + Expo
- Zustand for state management
- AsyncStorage for persistence

「画面」と「データ」の分離が重要です。多くの人がやりがちなのは「タスク管理アプリを作って」だけ書く形で、これだと AI が抽象的な部分から推測することになり、出力が曖昧になります。

型2: 段階的な指示を出す

複雑なアプリは1回のプロンプトで完成させようとしないのがコツです。

ステップ1: まずはホーム画面とタスクのデータモデルだけ作ってください。
　他の画面は次のステップで指示します。

→ 出力後 →

ステップ2: 次に、タスク追加画面をモーダルで実装してください。
　ホーム画面のヘッダー右上の "+" ボタンから開く形にしてください。

→ 出力後 →

ステップ3: 詳細画面を実装してください。

私はこのスタイルを「段階的な相談」と呼んでいます。一気に作らせると、後から修正したい部分が複雑に絡み合って手が入れにくくなります。段階的に作ると、各ステップで「ここをこう変えたい」という会話が成立します。

型3: コードレビューしながら進む

Rork Max が出したコードを「とりあえず動けばいい」で受け入れず、私は次のように追加プロンプトを投げます。

このコードについて2つ質問させてください:
1. なぜ useState ではなく useReducer を選んだのですか？
2. AsyncStorage の書き込みエラーが起きたときの挙動が見えないのですが、
   ハンドリングを追加できますか？

AI が判断した理由を聞くと、コードへの理解が深まります。さらに、エラーハンドリングのような「動作には不要だがプロダクション品質に必要」な部分を意識的に追加させることで、コードの質が一段上がります。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦無印 Rork（React Native）と Rork Max（Swift ネイティブ）を、機能と月200ドルのコストから選び分ける判断表

✦クレジットの消費を抑える――作り直しを部分修正に変えるプロンプトの渡し方

✦AI が書いたネイティブコードを App Store に出す前の、キー走査・権限・初回起動の確認手順

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

コンテキスト管理 — 長いセッションを破綻させない

Rork Max でアプリを作り続けると、セッション内のコンテキストが膨大になります。これを上手く管理しないと、後半で「最初に決めた仕様を AI が覚えていない」状態になります。

コンテキスト管理の3つの原則

原則1: プロジェクトの全体像を agents.md に書く

プロジェクトルートに agents.md を置いて、AI に常に意識してほしいルールを書きます。

# プロジェクト基本情報
 
## 技術スタック
- React Native 0.84 + Expo SDK 52
- Hermes v1 を使用（パフォーマンス重視）
- TypeScript strict mode
- Tailwind CSS（NativeWind）
 
## デザイン原則
- 余白を多めに、視覚的に静かに
- フォントはシステムフォント
- 配色はモノトーン基調 + アクセント1色
 
## コーディングルール
- 関数は1つの責務に絞る
- コメントは英語で書く
- エラーハンドリングは必ず明示的に

このファイルがあると、AI は会話の冒頭で必ず参照してくれるため、セッション後半でも一貫性が保たれます。

原則2: 大きな機能ごとにセッションを分ける

「認証フロー全体を作る」「決済導入」のような大きな塊は、別のセッションで進めます。コンテキストが綺麗な状態で始められるので、AI の判断の精度が高くなります。

原則3: 重要な決定はメモに残す

「購入処理は RevenueCat を使うことに決めた」「データベースは Supabase を使う」のような決定は、セッションをまたいで継承する必要があります。プロジェクト内に decisions.md のようなファイルを作って蓄積しておくと、新しいセッションで AI に渡せます。

実装の癖と回避策

Rork Max の AI が時々ハマる癖と、それを回避する方法もまとめておきます。

癖1: パッケージのバージョンが微妙に古い

AI は学習時点での React Native や Expo のバージョンを基準にコードを書くので、最新版で API が変わっている場合に動かないコードを出すことがあります。

回避策: プロンプトで「Expo SDK 52 / React Native 0.84 を前提に」と明示します。エラーが出たら「このパッケージは現在のバージョンでは XX が変わっているので、最新の書き方で書き直して」と伝える。

癖2: 状態管理の選択が一貫しない

最初に Zustand を使っていたのに、別の機能では Redux を提案されることがあります。

回避策: agents.md に「状態管理は Zustand で統一」と明示。新しいセッションでも忘れないように。

癖3: TypeScript の型が緩い

any 型でその場をしのぐコードが出ることがあります。

回避策: 「TypeScript strict mode で any を使わずに型を定義してください」と毎回明示。少し冗長ですが、後から型エラーで苦しむより楽です。

アプリ自体に AI を載せるとき — オンデバイス ML とクラウド API の選び分け

ここまでは Rork Max の AI で「アプリを作る」話でした。作ったアプリ自体に画像認識やチャットのような AI 機能を載せたくなると、実装の選択肢は大きく2つに分かれます。端末内で推論するオンデバイス ML と、OpenAI や Gemini に送って処理するクラウド AI API です。私はこの2つを「どちらが優れているか」ではなく「この機能はどちらに向くか」で選んでいます。

判断の軸を整理すると、次のようになります。

観点	オンデバイス ML	クラウド AI API
レイテンシ	低い（端末内で完結）	ネットワーク往復ぶん遅い
プライバシー	データが端末から出ない	サーバーへ送信される
精度	モデル規模なりに限定的	大規模モデルで高い
アプリ容量	モデルを同梱するぶん増える	ほぼ増えない
オフライン	動く	通信が必須
コスト	初期のモデル用意のみ	呼び出しごとに課金

ざっくりした目安として、プライバシーが要で低遅延が欲しい基本機能はオンデバイスに、高い精度や最新の知識が要る機能はクラウドに寄せています。たとえば写真の簡単な分類は端末内で、ユーザーの自由入力を読み取る対話はクラウドで、という分け方です。両方を併用しても構いません。

オンデバイス ML を React Native に載せる最小構成

React Native + Expo なら、TensorFlow.js でモデルを読み込んで推論できます。要点は、推論前にバックエンド（WASM）の初期化を待つことと、確保したテンソルを使い終わったら dispose で必ず解放することです。解放を忘れると、セッションが長くなるほどメモリを食いつぶします。

src/utils/onDeviceModel.ts

import * as tf from '@tensorflow/tfjs';
import '@tensorflow/tfjs-react-native';
 
let model: tf.LayersModel | null = null;
 
export async function loadModel(modelUrl: string) {
  if (model) return model;
  await tf.ready();              // バックエンドの初期化を待つ
  model = await tf.loadLayersModel(modelUrl);
  return model;
}
 
// 224x224x3 に正規化済みの画像配列を渡して分類する
export async function classify(pixels: number[]): Promise<number[]> {
  const m = await loadModel('https://your-cdn.example/model.json');
  const input = tf.tensor(pixels, [1, 224, 224, 3]);
  const output = m.predict(input) as tf.Tensor;
  const scores = Array.from(await output.data());
  tf.dispose([input, output]); // テンソルを解放してメモリを守る
  return scores;
}

最高スコアのインデックスをラベルに対応させれば、写真の分類やタグ付けが端末内で完結します。通信をしないので、オフラインでもプライバシー面でも安心して使えます。

クラウド API を安全に呼ぶ — キーは絶対に端末へ置かない

クラウド AI を使うとき、最初に守るべき原則が一つあります。OpenAI や Gemini の API キーをアプリのコードに直接書いてはいけません。アプリのバイナリは解析されうるので、埋め込んだキーはいずれ抜かれ、見知らぬ誰かにあなたの API 課金を使われます。

正しい形は、自前のバックエンドを一枚挟んで中継することです。キーはサーバー側だけに置き、アプリはユーザー認証トークンでバックエンドを呼びます。

src/services/aiClient.ts

import * as SecureStore from 'expo-secure-store';
 
const BACKEND = 'https://your-backend.example/api';
 
export async function askAI(prompt: string): Promise<string> {
  const token = await SecureStore.getItemAsync('auth_token');
  const res = await fetch(`${BACKEND}/ai/chat`, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      Authorization: `Bearer ${token ?? ''}`,
    },
    body: JSON.stringify({ prompt }),
  });
  if (!res.ok) throw new Error(`AI request failed: ${res.status}`);
  const data = await res.json();
  return data.reply;
}

バックエンド側で OpenAI なり Gemini なりを呼び、結果だけをアプリへ返します。こうしておくと、後からモデルを切り替えても、レート制限を入れても、アプリ側のコードは一切変えずに済みます。キーが漏れない安心と、運用の柔軟さの両方が手に入ります。

Rork Max にこの構成を作らせるときは、「API キーはバックエンド経由で中継し、アプリには直接埋め込まないでください」と一文添えるだけで、初手から安全な雛形を出してくれます。

無印 Rork で作るか、Rork Max に行くか — 判断の分かれ目

ここまでの工夫は、無印の Rork（React Native + Expo でクロスプラットフォームに出すほう）でも、ネイティブ Swift を書き出す Rork Max でも、ほぼそのまま効きます。ただ、どちらを土台に選ぶかで、アプリの天井そのものが変わります。

私が個人開発で複数のアプリを回してきて、最初に決めるようにしているのは「このアプリは Apple のハードや OS の機能に踏み込むか」という一点です。踏み込まないなら、無印 Rork のまま iOS と Android を同時に持てるほうが圧倒的に得です。踏み込むなら、そこだけ Rork Max を検討します。

判断を一覧にすると、おおよそ次のようになります。

やりたいこと	無印 Rork（React Native）	Rork Max（Swift ネイティブ）
iOS と Android を同時に出す	得意	Apple 系のみ
通知・カメラ・位置情報などの一般的な端末機能	十分に届く	届く
Live Activities / Dynamic Island	制約が多い	素直に作れる
HealthKit / HomeKit / NFC / App Clips	追加実装が重い	本来の土俵
Metal による 3D・AR / LiDAR	現実的でない	狙える
Apple Watch / Vision Pro 単体アプリ	非対応に近い	対応
月のランニングコスト	無料〜月25ドル前後	月200ドル

月200ドルという金額は、個人開発者にとって軽いものではありません。私は「その差額を、Android を捨ててでも取りに行くネイティブ機能が、このアプリの中心にあるか」で見ています。たとえばウィジェットや Live Activities が体験の主役になるアプリなら、Rork Max の素直さは十分に元が取れます。

一方で、よくあるリスト型・コンテンツ閲覧型のアプリで「いつか使うかもしれない」程度の理由なら、無印 Rork のまま二つのストアを取りに行くほうが、私の経験では収益の総量で勝ちます。Android を最初から手放すというのは、思っているより大きな決断です。

迷ったら、無印 Rork で骨格を作り、ネイティブ機能が本当に要ると分かった段階で Rork Max に持ち替える。この順番が、お金も時間も一番こぼさずに済みます。

クレジットを無駄にしない作り方

Rork Max を使い込むと、誰もが一度はクレジットの減りの速さに驚きます。2026年に入ってからの利用者レビューでも「思ったより消費が大きい」という声を見かけます。私自身、最初の頃は同じ生成を何度もやり直して、ずいぶん溶かしました。

無駄を減らす鍵は、「作り直し」を「部分修正」に変えることです。

一番効くのは、前提を毎回書かずに済むよう agents.md に固定しておくこと（前の章で触れたとおりです）。スタックや状態管理の方針が毎回ぶれなくなるだけで、丸ごと作り直す回数が目に見えて減ります。

次に、動かないコードが出たときの渡し方です。「動きません、直して」とだけ送ると、AI は広い範囲を作り直しがちで、そのぶんクレジットを食います。代わりに、出たエラーメッセージそのものと、該当ファイル名・行を添えて渡します。

このエラーで止まっています。該当箇所だけ直してください。
他のファイルは変更しないでください。

ERROR: undefined is not an object (evaluating 'route.params.id')
  at TaskDetail.tsx:18

「他のファイルは変更しないでください」の一文が、余計な再生成を抑える地味な効きどころです。

最後に、大きな機能は一気に頼まないこと。前半で触れた段階的な指示は、品質だけでなくクレジットの面でも効きます。小さく出して確かめ、次へ進む。一回の生成が小さいほど、外したときの損も小さくて済みます。

AI が書いたネイティブコードを出す前に確かめること

AI が出したコードは、動いて見えても「出していい状態」とは限りません。私はアプリを App Store に出し始めた頃、審査で何度もリジェクトを食らいました。その多くは、コードが動くかどうかではなく、提出前の確認を怠ったことが原因でした。

Rork Max に作らせたアプリを公開する前、私は最低でも次の三つを手で確かめます。

第一に、API キーやトークンがコードに直接埋まっていないか。前の章で触れたとおりキーはバックエンド経由が原則ですが、AI が「とりあえず動く形」でべた書きすることがあります。提出前に一度だけ機械的に走査しておくと安心です。

# 提出前にキーらしき文字列が混入していないか走査する
grep -rEn "sk_live_|AIza[0-9A-Za-z_-]{10,}|AKIA[0-9A-Z]{16}" src/ \
  && echo "鍵らしき文字列を検出。バックエンド経由に直してください" \
  || echo "ベタ書きの鍵は見当たりません"

第二に、権限の利用目的（purpose string）が日本語でも自然に書かれているか。カメラや位置情報を使うのに、目的の説明が空だったり英語のままだと、それだけでリジェクトされます。

第三に、初回起動の動線です。AI は「ログイン済み」を前提にした画面から作りがちで、まっさらな状態で開いたときの空表示やエラーが抜け落ちます。インストール直後の端末で一度通しで触る。これが一番効く確認です。

派手な作業ではありません。けれど、この地味な数分が、審査の往復という数日の損を防いでくれます。AI に速く作ってもらうほど、最後に人が確かめる工程の価値は上がる。私はそう感じています。

個人開発者として Rork Max を選ぶ価値

私が個人で複数のアプリを作りつつ、その経験をブログに書いている立場として、Rork Max を選ぶ価値は次の3点に尽きます。

第一に、1人で「アイデア → 実機での動作確認」までを最短数時間で回せること。これは個人開発で最も重要なフィードバックループです。

第二に、ネイティブアプリの細かい設定（Push 通知の証明書、課金まわり、TestFlight への提出）まで AI が支援してくれること。Web アプリと違い、ネイティブアプリは設定の地雷が多く、ここで挫折する人が多い領域です。Rork Max はこの「設定の壁」を下げてくれます。

第三に、コードベースが React Native + Expo として見える形で残ること。AI が消えても、生成されたコードは残ります。後から手で改修できる安心感があります。

次のアクション

Rork Max を「もっと深く使いたい」と思ったら、まずは agents.md をプロジェクトルートに作って、プロジェクトの基本情報を書いてみてください。それだけで AI の応答の一貫性が大きく変わります。慣れてきたら、本記事のプロンプト3型を意識的に使い分けると、出力の質がさらに引き上がります。