Rork Max で SwiftUI ネイティブアプリを生成する — AI が書くコードの品質を本気で検証

プロンプト設計の決定版テンプレート

生成精度を最大化するために、私が確立したプロンプトテンプレートを共有します。このテンプレートを使うかどうかで、生成結果の品質が劇的に変わります。

# プロジェクト概要
[1〜2 文でアプリの目的と主要機能を説明]

# 対象プラットフォーム
- iOS 17 以降（SwiftUI ベース）
- iPhone のみ / iPad 対応 / 両対応のいずれか

# 技術スタック
- UI: SwiftUI（UIKit との混在は避ける）
- データ: SwiftData（Core Data ではない）
- 状態管理: @Observable（@StateObject は避ける）
- 非同期: async/await（Combine は避ける）
- ナビゲーション: NavigationStack（NavigationView は避ける）

# 画面構成
- 画面 1: [画面名] — [主要要素を 3〜5 個列挙]
- 画面 2: [画面名] — [主要要素を 3〜5 個列挙]
（必要な画面数だけ繰り返す）

# データモデル
- [エンティティ名]: [プロパティを型と一緒に列挙]

# 機能要件
- [機能 1]
- [機能 2]
（具体的に列挙）

# デザイン要件
- カラースキーム: [Light/Dark 両対応]
- タイポグラフィ: System default
- 余白: 標準（HIG 準拠）

# 制約
- 外部依存（CocoaPods、SPM パッケージ）は避け、Apple 純正 API のみで実装
- iOS 17 で非推奨になった API は使わない

このテンプレートのポイントは、Rork Max に「やってほしいこと」だけでなく「やってほしくないこと」を明示する 部分です。@StateObject は避ける、Combine は避ける、NavigationView は避ける のような制約を入れると、生成結果が古いパターンに引きずられず、最新の SwiftUI のベストプラクティスに沿ったコードが返ってきます。

生成コードの典型パターンを読む

Rork Max が生成する SwiftUI コードの典型的な構造を 1 例として示します。これは To Do アプリの最小構成です。

import SwiftUI
import SwiftData
 
@main
struct TodoApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .modelContainer(for: TodoItem.self)
    }
}
 
@Model
final class TodoItem {
    var id: UUID
    var title: String
    var isCompleted: Bool
    var createdAt: Date
 
    init(title: String, isCompleted: Bool = false) {
        self.id = UUID()
        self.title = title
        self.isCompleted = isCompleted
        self.createdAt = Date()
    }
}
 
struct ContentView: View {
    @Environment(\.modelContext) private var context
    @Query(sort: \TodoItem.createdAt, order: .reverse) private var items: [TodoItem]
    @State private var newItemTitle: String = ""
 
    var body: some View {
        NavigationStack {
            List {
                ForEach(items) { item in
                    TodoRow(item: item)
                }
                .onDelete(perform: deleteItems)
            }
            .navigationTitle("To Do")
            .toolbar {
                ToolbarItem(placement: .bottomBar) {
                    HStack {
                        TextField("新しいタスク", text: $newItemTitle)
                            .textFieldStyle(.roundedBorder)
                        Button("追加") { addItem() }
                            .disabled(newItemTitle.isEmpty)
                    }
                    .padding(.horizontal)
                }
            }
        }
    }
 
    private func addItem() {
        let item = TodoItem(title: newItemTitle)
        context.insert(item)
        newItemTitle = ""
    }
 
    private func deleteItems(offsets: IndexSet) {
        for index in offsets {
            context.delete(items[index])
        }
    }
}
 
struct TodoRow: View {
    @Bindable var item: TodoItem
 
    var body: some View {
        HStack {
            Image(systemName: item.isCompleted ? "checkmark.circle.fill" : "circle")
                .foregroundStyle(item.isCompleted ? .green : .gray)
                .onTapGesture { item.isCompleted.toggle() }
            Text(item.title)
                .strikethrough(item.isCompleted)
        }
    }
}

この生成コードを見ると、SwiftData の @Model マクロ、@Query プロパティラッパー、@Bindable の使い方が、最新の SwiftUI のベストプラクティスに沿っていることが分かります。これは、私がプロンプトで明示的に「SwiftData を使う」「@Observable を使う」と指定した結果です。

ただし、実際の運用ではこのコードに以下の修正を入れる必要があります。

ひとつは、エラーハンドリングの追加 です。生成コードでは context.insert や context.delete の失敗を考慮していませんが、本番では try/catch でハンドリングすべきです。

もうひとつは、アクセシビリティ対応の追加 です。生成コードには accessibilityLabel や accessibilityHint がほとんど含まれません。VoiceOver 対応を本気でやるなら、ここは手動で追加します。

最後に、テストコードの不足 です。Rork Max は機能コードの生成は得意ですが、XCTest や Swift Testing でのユニットテストは別途指示しないと書かれません。

Xcode への取り込みワークフロー

生成された SwiftUI コードを Xcode プロジェクトに取り込む手順を、実運用で使っている流れで整理します。

まず、Rork Max の Web 画面で生成されたコードをプロジェクト全体としてダウンロードします。この時点で .xcodeproj ファイルも一緒に生成される場合と、ファイル群だけが生成される場合があります。前者なら Xcode で開くだけで動きますが、後者の場合は手動でプロジェクトを作って取り込む必要があります。

私のおすすめは、先に Xcode で空のプロジェクトを作っておき、生成された .swift ファイルだけを取り込む やり方です。Bundle Identifier、署名設定、Capabilities といった Xcode プロジェクト固有の設定は、Rork Max の生成物が完璧にカバーできない領域なので、最初から自分で管理したほうが後の修正がラクになります。

取り込み後の最初のビルドでは、ほぼ確実にいくつかのエラーが出ます。主なエラーパターンと対処法を整理します。

Cannot find type X in scope というエラーが出たら、import 文の不足です。SwiftUI、SwiftData、Foundation あたりの import が漏れていることが多いので、ファイルの先頭に追加します。

X is unavailable: introduced in iOS 17.0 というエラーが出たら、Xcode プロジェクトの Deployment Target を確認します。Rork Max は iOS 17 以降を前提に生成しますが、プロジェクト側で iOS 16 以下を指定していると衝突します。

Type X does not conform to protocol Y というエラーは、SwiftData モデルの定義で @Model マクロを忘れているケースが多いです。生成コードを確認してマクロが付いていなければ追加します。

課金処理の生成 — StoreKit 2 を使う

Rork Max が SwiftUI と並んで実用的に使えるのが、StoreKit 2 を使ったサブスクリプション課金の生成 です。私の個人開発でも、Apple のサブスクリプション機能は売上の主要な部分を占めるため、ここの生成精度は重要です。

プロンプトに以下を加えると、StoreKit 2 を使った課金フローが生成されます。

# 課金要件
- StoreKit 2 を使用（StoreKit 1 は避ける）
- 月額プランと年額プランの 2 つを用意
- レシート検証は AppStoreServerLibrary-Swift を使用したサーバーサイド検証
- リストア機能を実装
- サブスクリプション状態の変化を監視

生成されるコードは、Product.products(for:) でストアから商品情報を取得し、product.purchase() で購入を実行し、Transaction.updates で状態変化を監視する、という StoreKit 2 の標準パターンに沿ったものです。私が試した範囲では、生成精度は 80% 程度で、リストア処理とサーバーサイド検証部分は手動修正が必要でした。

本番運用するときの注意点として、Sandbox 環境でのテスト を徹底することを強くおすすめします。生成コードは見た目には正しく見えても、実際のサブスクリプションのライフサイクル（更新失敗、グレースピリオド、価格変更通知など）に対応できていないケースがあるためです。

運用上の落とし穴 — 私が実際に踏んだもの

Rork Max を実プロジェクトで使う中で、私が実際に踏んだ落とし穴を共有します。

ひとつ目は、プロンプトを改訂すると過去のコードが上書きされる ことです。Rork Max のセッションは継続的に使えますが、プロンプトを大きく改訂して再生成すると、以前生成したカスタマイズが失われます。回避策として、生成後すぐに Git にコミットして、改訂前の状態を保持しておくのが安全です。

ふたつ目は、ローカライゼーションの抜け です。Rork Max は基本的に英語または指定された 1 言語で生成し、Localizable.strings のような多言語化の構造を自動では作りません。多言語対応を前提にしたアプリでは、生成後に自分で Localizable Catalog を整備する必要があります。

みっつ目は、App Store 提出時に必要なメタデータが生成されない ことです。Privacy Manifest、App Tracking Transparency の設定、サードパーティ SDK の使用申告など、App Store 申請に必要な書類は Rork Max の生成物の対象外です。

よっつ目は、API キーがコード内に直書きされやすい ことです。Rork Max は便利さ優先で、外部 API キーをソースコード内に書くケースがあります。本番では Keychain や環境変数経由に必ず置き換えます。

どのくらいの開発時間短縮効果があったか

実測値ベースで、Rork Max が個人開発の時間にどう影響したかを共有します。

従来のゼロからの SwiftUI 開発 では、5 画面程度のシンプルなアプリで、設計から MVP 完成までに概ね 30〜40 時間かかっていました。これは私が 11 年の経験を持つ前提でのスピードです。

Rork Max を活用した場合 は、同じ規模のアプリで概ね 12〜18 時間まで短縮できました。プロンプト設計に 2 時間、生成と確認に 1 時間、修正と仕上げに 8〜13 時間、テストとビルド調整に 1〜2 時間という内訳です。

開発時間が 約半分から 1/3 に短縮 されたことになります。これは個人開発者にとって極めて大きなインパクトで、新規アプリの立ち上げサイクルが本気で変わるレベルの効果です。

ただし、短縮効果が出るのは「自分が SwiftUI を書ける」前提です。生成コードのレビューと修正を自分で判断できないと、生成されたコードを盲信して品質を落としたり、エラーが出ても直せずに止まったりします。Rork Max は「SwiftUI を書ける人を加速する」ツールであって、「書けない人を書ける人にする」ツールではありません。

ストア申請までのチェックリスト

Rork Max で生成したアプリを App Store に提出する前に、私が必ず確認するチェックリストを共有します。

App Store Connect の準備として、Bundle Identifier の登録、Apple Developer Program の有効性確認、署名証明書とプロビジョニングプロファイルの設定を行います。これは Rork Max の生成物には含まれないため、すべて手動です。

Privacy Manifest の作成は必須です。PrivacyInfo.xcprivacy ファイルを Xcode プロジェクトに追加し、収集するデータの種類と用途を申告します。これを怠ると、App Store 提出時にリジェクトされます。

App Tracking Transparency が必要なアプリ（広告 ID を使う場合など）では、NSUserTrackingUsageDescription を Info.plist に追加し、ATTrackingManager.requestTrackingAuthorization の実装を確認します。Rork Max はここまで自動では設定しません。

スクリーンショットの準備、App Privacy の設定、価格設定、リリース日の設定といった App Store Connect 上の作業は、Rork Max の対象外なのですべて手動です。

個人開発者の視点から（実体験メモ）

全体を振り返って

Rork Max は、SwiftUI のネイティブ iOS アプリを実用的なレベルで生成できるツールです。生成精度は約 70% でビルド通過、85% で挙動正常という水準で、約 30% の手直しを前提として使えば、開発時間を半分から 1/3 に短縮できます。

最大の効果を引き出すコツは、プロンプトで「やってほしくないこと」を明示することです。@StateObject は避ける、Combine は避ける といった否定形の指定が、生成結果の品質を決定的に左右します。

一方で、Rork Max は万能ではありません。エラーハンドリング、アクセシビリティ対応、テストコード、ローカライゼーション、Privacy Manifest、StoreKit のサーバーサイド検証など、本番運用に必要な要素の多くは手動で追加する必要があります。

それでも、「SwiftUI を書ける個人開発者」が Rork Max を使うと、新規アプリの立ち上げが劇的に速くなる ことは、私が実測した結果として確信を持って言えます。アプリ開発で月収を立てたい方、新しいアイデアを次々試したい方、既存アプリの新機能を高速に試作したい方には、強くおすすめできるツールです。

私自身、現在も毎月いくつかのアプリのプロトタイプを Rork Max で立ち上げており、その中から本格開発に移行するものをセレクトしています。この使い方が、個人開発者にとっての Rork Max の最も実用的な活用法だと考えています。