Rork Max の SwiftUI 生成は AI 機能とどう連動しているか — 出力品質を左右する 7 つのプロンプト設計

「Rork Max の SwiftUI 生成機能と AI 機能、どっちを使えばいいんですか？」と聞かれることが増えてきました。答えは「両方を意識したプロンプトを書くと出力品質が変わります」です。この 2 つは別々のメニューに見えても、内部では同じ AI レイヤーの上で動いていて、書き方ひとつで生成される SwiftUI コードの完成度がはっきり変わってきます。私自身、同じ要件を 3 通りの伝え方で投げてみて、レビュー対象になるレベルから「ほぼそのまま本番投入できるレベル」まで差が出た経験があり、その時の知見をまとめておきます。

SwiftUI 生成と AI 機能は分離されていない

Rork Max のドキュメント上は「SwiftUI ネイティブアプリ生成」と「AI capabilities」が並列で説明されていることが多いのですが、実装側から見ると両者は同じ AI モデルが担当しています。SwiftUI コードを吐き出す時にも、画面遷移を提案する時にも、State の構造を決める時にも、内部的には同じ推論パイプラインを通っています。

この前提を理解しておくと、「画面のラフを伝えるとそれっぽい SwiftUI が出てくる」という単純な使い方から一歩進めて、「AI に何を判断させて、何を判断させないか」を意識したプロンプトが書けるようになります。私の体感では、これを意識し始めてから手戻りが半分以下になりました。

AI が「読む」プロンプトと「書く」コードの間にある変換

Rork Max にプロンプトを送ると、AI レイヤーは大まかに 3 段階の処理をしています。1 段目はプロンプトの解釈（要件抽出）、2 段目は内部表現の組み立て（画面構造・State・データフローの設計）、3 段目が SwiftUI コードへの落とし込みです。

出力品質が悪く感じるケースの多くは、2 段目で曖昧な解釈が入って、3 段目で「無難だが浅い」コードに着地してしまうパターンです。逆に言えば、2 段目で AI が迷わなくて済むようなプロンプトを設計できれば、3 段目の SwiftUI コードはかなり安定します。

出力品質を変える 7 つのプロンプト設計

1. 画面の状態を最初に列挙する

「ログイン画面が欲しい」だけだと AI は標準的な実装に流れます。「未入力／入力中／送信中／エラー／ロック中の 5 状態を持つログイン画面」と書くと、@State や enum を使った State パターンに自然に誘導できます。

2. データソースを名指しする

「API から取得」ではなく「AuthService.login(email:password:) async throws -> Session を呼ぶ」と書くと、生成される SwiftUI 側もこの関数シグネチャに合わせた await 呼び出しを書いてきます。型を先に決めると AI は迷いません。

3. 失敗パターンを 1 つだけ具体的に伝える

「エラー処理を入れて」だけだと try-catch の雛形しか出ません。「ネットワーク不通時にはバナーで再試行ボタンを出す」と 1 例だけ具体化すると、Result 型や do-catch を含む実用的なエラーハンドリングが返ってきます。

4. 描画パフォーマンスの制約を伝える

「100 件のリストでスクロールが滑らかに」と書くだけで、LazyVStack と id: の使い方、Equatable 適合の有無まで AI が考慮してくれます。これは内部の AI が iOS 開発の文脈知識を持っているからです。

5. 既存コードの一部を貼り付ける

ゼロから書かせるのではなく、既存の Model や ViewModel を 10〜20 行ほど貼り付けて「これに合わせて Detail 画面を生成」と頼むと、命名規則やプロパティアクセスのスタイルが揃います。プロジェクト全体の一貫性を保ちたい時に効きます。

6. アクセシビリティ要件を最初に書く

VoiceOver 対応を後付けで頼むと差分が大きくなりがちです。最初のプロンプトに「VoiceOver で操作可能、Dynamic Type 対応」と一行入れておくと、.accessibilityLabel や .dynamicTypeSize の付与が自動で組み込まれます。

7. 出力コードのスタイルを宣言する

「SwiftUI のみで書く・UIKit 経由は使わない」「@Observable ではなく ObservableObject を使う」のような方針を最初に宣言しておくと、生成途中でスタイルがブレません。これは AI が「最新ベストプラクティスに引っ張られる」傾向への対策でもあります。

同じ機能でも書き方で変わる実例

タスク追加画面を、雑なプロンプトと設計済みプロンプトの 2 通りで生成した例を比較します。まず雑なプロンプト「タスクを追加する画面を作って」では、おおむね次のようなコードが出てきます。

// 雑なプロンプトでの出力例（簡略化）
struct AddTaskView: View {
    @State private var title: String = ""
 
    var body: some View {
        Form {
            TextField("タイトル", text: $title)
            Button("追加") {
                // TODO: save
            }
        }
    }
}
// 期待出力: フォームは表示されるが、保存処理・バリデーション・閉じる処理が空

次に設計済みプロンプトを使います。「タイトル必須・1〜80 文字、保存中はボタンを無効化、保存成功で dismiss、TaskRepository.add(_:) async throws を呼ぶ」と要件を明示すると、次のようなコードが返ってきます。

// 設計済みプロンプトでの出力例
struct AddTaskView: View {
    @Environment(\.dismiss) private var dismiss
    @State private var title: String = ""
    @State private var isSaving: Bool = false
    @State private var errorMessage: String?
 
    private var isValid: Bool {
        let trimmed = title.trimmingCharacters(in: .whitespaces)
        return (1...80).contains(trimmed.count)
    }
 
    let repository: TaskRepository
 
    var body: some View {
        Form {
            Section {
                TextField("タイトル", text: $title)
                    .disabled(isSaving)
            } footer: {
                if let errorMessage {
                    Text(errorMessage).foregroundStyle(.red)
                }
            }
 
            Button {
                Task { await save() }
            } label: {
                if isSaving { ProgressView() } else { Text("追加") }
            }
            .disabled(!isValid || isSaving)
        }
    }
 
    private func save() async {
        isSaving = true
        defer { isSaving = false }
        do {
            try await repository.add(title.trimmingCharacters(in: .whitespaces))
            dismiss()
        } catch {
            errorMessage = "保存に失敗しました。もう一度お試しください。"
        }
    }
}
// 期待出力: バリデーション・保存中UI・エラー表示・dismissまで揃ったレビュー対象コード

差分は数十行ですが、レビュー前にやる手直しの量が大きく違います。同じ AI が同じモデルで動いているのに、入力情報の密度で出力が変わる典型例です。

私が現場で守っている運用ルール

Rork Max を 30 本以上のアプリ試作で使ってきて、最終的に落ち着いた運用ルールをいくつか挙げておきます。

ひとつ目は「画面ごとに 1 度の生成で完成させようとしない」こと。雛形生成 → 必要箇所の差分指示 → リファクタリングという 3 段階に分けたほうが、トータルの試行回数は少なく済みます。最初から完璧を狙うほど、AI は無難に逃げます。

ふたつ目は「プロジェクト全体の前提を毎回プロンプトの先頭に貼る」こと。状態管理ライブラリ・命名規則・最低 iOS バージョンなどを定型化しておくと、複数の画面を生成しても全体のトーンが揃います。これは Rork Max SwiftUI 機能の総合ガイドでも触れられている考え方ですが、実際にやってみると効果が大きい工夫です。

みっつ目は「AI の判断結果を必ずログに残す」こと。生成されたコードと一緒に「なぜその実装にしたか」を AI に説明させておくと、後から読み返した時に意図を追えます。これは Rork Max の AI コスト最適化ガイドで書いたコスト管理とも繋がる話で、ログ残しは無駄なリトライを減らす副次効果もあります。

AI に丸投げする前に「自分が読めるコード」を増やしておくと、生成結果の良し悪しが自分で判断できるようになり、結果的にプロンプトの精度も上がります。

ここまで紹介した内容は、すぐに試せるものばかりです。次に Rork Max を開く時、まずは「画面の状態を最初に列挙する」だけでも入れてみてください。同じ機能の生成でも、出てくるコードの粒度が変わるはずです。そこから 7 つの設計を 1 つずつ自分のスタイルに馴染ませていくと、Rork Max が「下書き生成器」から「実装の相棒」に変わっていきます。