壁紙アプリの一覧画面を Rork AI に出し直させながら、同じ「セルの間隔を広げてください」を三度書いている自分に気づきました。三度とも間隔は広がり、三度とも別の場所が狭くなっていました。
そのとき手を入れていたのは出力の側でした。けれど詰まっていたのは、こちらの指示が毎回わずかに違う前提の上に乗っていたことでした。ダークモードで撮った画面と明るいままの画面を混ぜて送り、文字サイズも端末ごとにばらばらのまま渡していたのです。
生成の質は、モデルの当たり外れよりも、渡す条件をどれだけ固定できているかで動きます。ここでは SwiftUI 出力でつまずきやすい箇所を整理したうえで、同じ画面を三通りの指示で出し直して往復回数を数えた記録と、スクリーンショットを送る前に端末側で決めておく条件を残します。
Rork AI のネイティブ生成の仕組み
Rork Max の役割
Rork Max は、AI エージェントとしてあなたの指示を理解し、SwiftUI のネイティブコードを自動生成するサービスです。生成されるコードの品質は、あなたの指示(プロンプト)の質に大きく左右されます。
生成の流れ :
Rork Max でアプリの概要を入力(例:「SNS フィード画面」)
Rork AI があなたの要件を解釈して SwiftUI コードを生成
ローカル環境で実行・テスト
問題があれば Rork Companion で修正指示を出す
新しいバージョンのコードが生成される
これを繰り返して完成度を上げていく
この循環が、Rork AI でのアプリ開発の本質です。
Rork Companion との連携
Rork Companion は、生成されたアプリをスマートフォンで実行しながら、スクリーンショットやビデオを Rork Max に送って修正指示を出すツールです。
Rork Companion の利点 :
ビジュアルフィードバック :実際の見た目を AI に見せることで、より正確な修正が可能
段階的改善 :小さな修正を積み重ねて、目指すデザインに近づけられる
リアルタイム動作確認 :複雑なアニメーションや状態遷移も実機で確認可能
Rork AI は、テキスト指示だけでなく、ビジュアル情報からも学習できます。つまり「見た目の違い」をスクリーンショットで示すことが、最も効果的な修正指示になります。
よくある品質問題と原因分析
ビルドエラーが発生する
症状 : コードを Xcode でビルドするとエラーが出て、コンパイルできません。
原因 :
View の戻り値が明示されていない
SwiftUI の View プロトコルは、some View という戻り値を要求
Rork AI が自動で補っていない場合がある
State 変数の型が不完全
@State var count などと型注釈なしで宣言されている
@State var count: Int = 0 のように明示する必要がある
Optional unwrap の忘れ
API レスポンスや画像読み込みで Optional 型が返される
適切に ?? や if let で処理していない
対処例 :
// 誤り:戻り値型が不明確
var body {
VStack {
Text ( "Hello" )
}
}
// 修正:some View を明示
var body: some View {
VStack {
Text ( "Hello" )
}
}
修正指示の例:
このコードが Xcode でコンパイルエラーになっています:「View の body プロパティが some View を返す必要があります」。以下のように修正してください:
var body: some View {
// ここに UI コード
}
UI が崩れている(レイアウト問題)
症状 : スマートフォンの画面で UI が期待と異なるレイアウトになっています。
原因 :
画面サイズに対応していない
Rork AI が固定サイズで UI を生成している(例:width: 300)
異なるデバイスサイズに対応していない
動的テキスト長に対応していない
短いテキストでは OK だが、長いテキストが入ると UI が崩れる
SafeArea を考慮していない
ノッチ付き iPhone でコンテンツが切れている
対処例 :
固定サイズの代わりに、GeometryReader や padding を使った相対サイズ指定:
// 誤り:固定サイズ
VStack {
Text ( "Hello" ). frame ( width : 300 )
}
// 修正:相対サイズ
VStack {
Text ( "Hello" ). frame ( maxWidth : . infinity )
}
修正指示の例:
スクリーンショット(添付)を見てください。テキスト「[長い文字列]」が画面右側にはみ出ています。以下のようにしてください:
各テキスト要素に lineLimit(2) を追加
VStack/HStack に適切な spacing と padding を設定
iPhone 12 mini〜iPhone 16 Pro Max で動作確認
機能が中途半端・未実装
症状 : ボタンをタップしても何も起こらない、フォームの検証がない、リスト読み込みが失敗します。
原因 :
UI だけで、ロジックが実装されていない
Rork AI が状態管理を忘れている
クロージャが empty で、処理が書かれていない
API 連携が簡略化されている
ダミーデータで動作する UI のみ生成
実際の API エンドポイントに接続していない
エラーハンドリングが不足
対処例 :
修正指示では「動作の詳細」を具体的に指示:
ボタン「保存」をタップしたとき、以下の処理を実行してください:
バリデーション:入力値が空でないか確認
ローディング表示:「保存中...」と表示
API 呼び出し:POST /api/save に JSON を送信
成功時:アラート「保存されました」を表示して画面を閉じる
エラー時:アラート「エラー: [サーバーエラーメッセージ]」を表示
パフォーマンスが悪い(遅い・重い)
症状 : アプリが重たく、リスト表示時にカクついたり、スクロールが引っかかります。
原因 :
リスト各行で複雑な処理が実行される
画像のダウンロード・処理が行・描画のたびに走っている
Rork AI がキャッシュを実装していない
State 更新が頻繁すぎる
不要な再描画
親 State の変更で、全子要素が再描画されている
対処例 :
修正指示では「パフォーマンス要件」を明示:
このリスト画面のパフォーマンスを最適化してください:
画像は AsyncImage で非同期読み込み
リスト各行は LazyVStack に変更
セルレイアウトは equatable() で再描画を防止
API は最初の 20 件を読み込み、スクロール時に追加読み込み
高品質なプロンプトの書き方
曖昧な指示が失敗の原因
最も一般的な失敗パターンは「曖昧なプロンプト」です。
ダメな例 :
SNS のようなアプリを作ってください
何が起きるか :
Rork AI 側で想定する「SNS」の像が定まりません
Instagram を想定するのか Twitter を想定するのか判断不能
結果:ニッチなレイアウト、実装されていない機能、が生まれる
具体的な UI 仕様の書き方
良い例 1:要素別の詳細指示
フィード画面を作ってください。仕様は以下の通りです:
ナビゲーションバー:背景色 #2563EB、右側に「投稿」ボタン
フィード:ユーザー画像(プロフィール)、ユーザー名、投稿日時、テキスト、画像、いいね数・コメント数の順
各セル:カード型、コーナー半径 12pt、影は radius 4 / opacity 0.12 程度
リスト読み込み:下スクロール時に「さらに読み込み」アニメーション表示
データソース:ダミーデータ 10 件
このレベルの具体性があると、Rork AI が正確に解釈でき、修正指示の回数も減ります。
良い例 2:参考画像の活用
最も効果的なのは、目指すデザインの参考画像を見せることです。
修正指示の例:
参考画像(添付)のような見た目に変更してください:
ヘッダーは薄いグレー背景
テキストはサンセリフフォント(例:-apple-system)
ボタンは青色の rounded rectangle
余白は 16pt で統一
Rork AI は視覚情報に強いため、文字説明だけより、スクリーンショット + 修正指示の方が効果的です。
コンポーネント単位の指示
複雑なアプリは「コンポーネント」に分割して指示するのが効果的です。
例:段階的な構築
ユーザープロフィールセルコンポーネントを作成してください
画像(円形、80×80pt)、ユーザー名、フォローボタンで構成
次に、フィードセルコンポーネントを作成
プロフィール + テキスト + 画像 + アクションボタン(いいね、コメント、シェア)
最後に、フィード画面を組み立て
この方法だと、各ステップで修正・確認でき、最終的な完成度が高くなります。
SwiftUI 特有のトラブルシューティング
Navigation(画面遷移)が動作しない
症状 : ボタンをタップしても画面が遷移しない、または遷移アニメーションがおかしい。
原因 :
修正指示の例 :
「詳細」ボタンをタップすると詳細画面に遷移し、戻るボタンで前の画面に戻る、という動作を実装してください。iOS 16+ 対応で NavigationStack を使ってください。
State・環境変数の管理エラー
症状 : 入力フィールドに文字を入力できない、チェックボックスの状態が反映されません。
原因 :
@State 変数がビューの外で定義されている
親ビューで定義された State を正しく子に渡していない
@Binding が使われていない
修正指示の例 :
TextFieldに入力した内容が保存されるように修正してください:
@State var inputText: String = "" を定義
TextField を $inputText にバインド
保存ボタンで inputText の値を処理
データバインディングエラー
症状 : API から取得したデータが画面に表示されない、またはデータが古いまま更新されません。
原因 :
修正指示の例 :
API(GET /api/feed)からデータを取得して表示してください:
ViewModelで @Published var items: [FeedItem] = [] を定義
画面表示時(onAppear)にAPIを呼び出し
取得結果を items に格納
リストで items を forEach で列挙
Rork Companion を使った反復改善ワークフロー
効果的なスクリーンショットフィードバック
Rork AI の最大の強みは、ビジュアルフィードバックから学習できることです。
ステップ 1:アプリを実行・スクリーンショット撮影
Rork Max → ビルド → iPhone シミュレータで実行 → スクリーンショット撮影
ステップ 2:問題点をアノテーション
撮影したスクリーンショットに、Markup(Mac の Preview、または iOS の Screenshot Markup)で矢印・テキストを追記:
例:
赤矢印で「このテキストが長すぎて右にはみ出ている」と指摘
緑矢印で「ここにボタンを追加」と指示
ステップ 3:Rork Companion で修正指示
スクリーンショット(添付)を見てください。以下を修正してください:
テキストが右にはみ出ている → 2 行表示 + 末尾「...」に設定
ボタンの間隔が狭い → 上下の余白を 16pt に広げてください
全体的に薄い灰色背景にしてください(現在は白)
段階的な改善サイクル
1回で完全に仕上げるのではなく、段階的に改善する方が、最終的な完成度は高くなります。
推奨フロー :
Day 1: 基本レイアウト完成
Day 2: 細かい UI調整(余白、フォントサイズ等)
Day 3: インタラクション実装(ボタン動作、画面遷移)
Day 4: API 連携(本物のデータ取得)
Day 5: エラーハンドリング、ローディング表示追加
Day 6: アニメーション・微調整
Day 7: 最終レビュー・App Store 提出準備
3〜4 日で本格的なアプリが完成することも珍しくありません。
バージョン管理のコツ
複数バージョンを並行開発している場合は、明確に名前を付けましょう。
例:
rork-ai-feed-v1.0-base (基本レイアウト)
rork-ai-feed-v1.1-styling (色・フォント調整後)
rork-ai-feed-v1.2-interaction (ボタン動作実装後)
rork-ai-feed-v1.3-api (API 連携完了)
rork-ai-feed-v2.0-release (App Store 提出版)
Rork Max でバージョン管理ができれば、ロールバックも簡単です。
パフォーマンス・品質向上のテクニック
不要なコードの削除指示
Rork AI はときどき「実装されたが使われていない」コードを生成することがあります。
修正指示の例:
以下のコードを削除してください。未使用です:
debugPrint() 呼び出し全て
ViewModel の unused_ で始まるプロパティ
Import statement の中で使われていないもの
コンポーネント分割
複雑な View を複数の小さな Component に分割すると、再利用性と保守性が向上します。
指示例:
以下のコンポーネントに分割してください:
FeedCellView: フィードセルの全体(プロフィール + コンテンツ + アクション)
UserProfileView: ユーザー情報表示部分(画像 + 名前)
FeedContentView: 投稿テキスト・画像表示
FeedActionsView: いいね・コメント・シェアボタン
親の FeedView では、これらコンポーネントを組み立てるだけにしてください。
アクセシビリティ対応
App Store 審査でも加点されるのがアクセシビリティ対応です。
指示例:
アクセシビリティを追加してください:
全ボタンに .accessibilityLabel() で日本語説明を設定
アイコンボタンに .accessibilityHint() で機能説明を追加
色でのみ情報を表現していないか確認(カラーユニバーサル対応)
実践サンプル:SNS フィード画面を段階改善
初期指示(Day 1)
SNS フィード画面を生成してください。機能:
ダミーデータ(10 件)をリスト表示
各行:ユーザー画像、ユーザー名、投稿テキスト、いいね数表示
参考デザイン(添付 Instagram フィードスクリーンショット)に近い見た目
iOS 16+ 対応
初回レビュー→修正指示(Day 2)
スクリーンショット(添付)を確認しました。以下の修正をお願いします:
テキストサイズ:本文 16pt → 14pt に縮小
ユーザー画像:正方形 → 円形(コーナー半径 50%)
セル間隔:現在 4pt → 12pt に拡大
セルの角丸:なし → 8pt に設定
セル影:なし → radius 2 / opacity 0.10 程度で追加
2 回目修正後(Day 3)
さらに以下を追加してください:
各セルに「詳細」ボタンを追加
「詳細」ボタンをタップで詳細画面に遷移(ダミー画面 OK)
詳細画面に戻るボタン
いいねボタンをタップで色が赤に変わる(状態管理)
3 回目修正(Day 4)
API 連携を実装してください:
ダミーデータの代わりに GET /api/feed から取得
画面表示時に自動読み込み
読み込み中は「Loading...」表示
エラー時は「エラーが発生しました」と「再試行」ボタン
このように、段階的に要件を追加していくことで、最終的には「本番品質」のアプリが完成します。
同じ画面を三通りの指示で出し直して、往復回数を数えた
指示の書き方で結果が変わるのは体感としてありましたが、どれくらい変わるのかを数字で持っていませんでした。そこで、個人開発で並行して運用している壁紙アプリの一覧画面という、私が何度も作り直している題材で揃えて比べました。
条件は三つです。到達点は同じ(2 列グリッド・サムネイル・タイトル・お気に入りボタン・無限スクロール)に固定し、指示の書き方だけを変えました。往復回数は「こちらが修正を依頼した回数」で数え、こちらが仕様を諦めて要件を下げた場合はそこで打ち切りとしています。
指示の書き方 収束までの往復 初回出力でそのまま残せた部分 最後まで残った問題
一文で頼む(「壁紙一覧の画面を作ってください」) 9 回 グリッドの骨格のみ セル高さが端末ごとに揃わない
箇条書きで仕様を渡す(列数・余白・角丸・状態を明記) 4 回 レイアウトとお気に入りの状態管理 サムネイルの読み込み中表示が未実装
箇条書き+目指す画面のスクリーンショット 1 枚 2 回 レイアウト・状態・余白の大半 特になし(細部の色味のみ)
セル高さのばらつきを最後まで潰しきれなかったのは、この画面の最下部に AdMob のバナーを固定で置いているからでもありました。高さが端末ごとに数ポイント動くと、最下段のセルがバナーの下に潜ります。指示の書き方が緩いほど、この種の「他の要素との関係で決まる寸法」が最後まで残りました。
差が出たのは往復回数だけではありませんでした。一文で頼んだ場合、往復のたびに前回直ったはずの箇所が戻ります。数字にすると 9 回のうち 4 回は「新しい要望」ではなく「戻ってしまった箇所の再依頼」でした。
参考画像を添えた場合が短かった理由は、こちらの頭の中にしかなかった基準が、画像という形で毎回同じものを指すようになったからだと考えています。言葉は往復のたびに揺れますが、同じ画像は揺れません。
ここから決めたこと : 新しい画面を起こすときは、指示を書く前に参考画像を 1 枚用意します。既存アプリの自分の画面でも、手描きのラフでも構いません。用意できないうちは、まだ仕様が固まっていない合図として受け取るようにしています。
スクリーンショットを送る前に、端末側の条件を固定する
Rork Companion で画面を見せながら直していく方法は強力ですが、送る画面の条件がそろっていないと指示同士がぶつかります。私が実際にぶつけた組み合わせを表にします。
固定する項目 ばらつくと起きたこと 私が既定にしている値
外観(ライト/ダーク) ダークで撮った画面を送った直後にライトで撮って送り、背景色の指示が二転三転した ライト固定。ダークは最後にまとめて 1 周だけ確認
文字サイズ(Dynamic Type) 大きめ設定の端末で「はみ出ている」と伝え、標準に戻したら余白が広すぎる状態になった 標準(Large)で撮影。最大サイズは最終確認のみ
端末サイズ 小さい端末で詰めた余白が、大きい端末で間延びして見えた 手元の実機 1 台に固定し、幅の両端は最後に確認
表示言語 日本語で詰めた行間が、英語表記に切り替えた画面で崩れた 日本語で作り込み、英語は文字数が伸びる箇所だけ個別に
データの中身 短いタイトルばかりのダミーで整え、実データで折り返しが発生した 最長のタイトルを必ず 1 件混ぜたダミーを使う
一番効いたのは最後の行でした。ダミーデータをきれいに揃えてしまうと、崩れる条件が画面に現れません。私は 10 件のダミーのうち 1 件を、実データで一番長かったタイトルに差し替えています。これだけで、あとから折り返しで作り直す往復がほぼ消えました。
条件を固定するのは、Rork AI のためというより自分のためでした。基準がぶれていると、直っているのか直っていないのかを自分で判定できません。
直感に反したこと — まとめて直させるほど、遅くなる
修正点が 5 つ見つかったとき、5 つまとめて渡すほうが往復が減って速い、と最初は考えていました。実際には逆でした。
まとめて渡すと、生成し直された画面のどこかが必ず巻き戻ります。5 点のうち 3 点は直り、直っていたはずの 1 点が戻る。すると次の依頼で「戻った 1 点」を書くことになり、そこでまた別の場所が動きます。往復は減るどころか増えました。
いまは 2 点ずつに刻んで渡しています。そして渡す順番を、次のように固定しました。
レイアウト(余白・サイズ・折り返し)— 見た目の土台が動くと、以降の判定ができなくなるため最初に閉じます
状態(ボタンの選択状態、読み込み中、空表示)— 土台が固まってから触ります
通信(API 接続、エラー時の表示)— 最後に回します。ここが入ると画面の見え方が実データ依存になり、切り分けが難しくなります
この順序にしてから、巻き戻りが目に見えて減りました。理由は単純で、後段の修正は前段の結果を前提にしていますが、前段の修正は後段の結果を前提にしていないからです。逆順で渡すと、前提のほうが動きます。
それでもまとめて渡してよい場面 もあります。色やフォントのように画面全体へ一律に効く指示は、分けても分けなくても結果が変わりませんでした。分けるべきなのは、位置や状態のように互いに影響し合う修正です。
本番品質に仕上げるための最終チェックリスト
アプリを App Store に提出する前に、以下をすべて確認してください。
機能テスト
[ ] 全画面遷移が正常に動作(戻るボタン含む)
[ ] 全入力フィールドが正常に機能(テキスト入力・ボタンタップ)
[ ] API 呼び出しが成功・エラー時の動作が正常
[ ] ネットワーク遅延時の動作確認(ローディング表示が出ているか)
[ ] 予期しないクラッシュが発生しないか(複数回のテスト)
UI・UX チェック
[ ] 画面レイアウトが iPhone 12 mini〜16 Pro Max で正常
[ ] テキストサイズ・余白がバランスしている
[ ] ボタンのターゲットサイズが 44×44pt 以上(Apple 推奨)
[ ] ダークモード対応(System Color を使用)
[ ] 横向き表示での動作確認
パフォーマンス
[ ] リスト表示で 60fps をキープ(スクロール遅延なし)
[ ] 大量データ読み込み時のメモリ使用量が適正(Instruments で確認)
[ ] 画像ダウンロードがキャッシュされている
セキュリティ・プライバシー
[ ] 通信が全て HTTPS(暗号化)
[ ] ユーザーデータが暗号化保存されている
[ ] プライバシーポリシーが完備され、アプリ内リンク配置
[ ] API キー・認証情報がコードに埋め込まれていない
Apple ガイドライン
[ ] プライバシーマニフェスト対応(iOS 17+)
[ ] アクセシビリティ対応(VoiceOver テスト)
[ ] App Store Guideline 4.3(Spam)に抵触していない
[ ] 不正な SDK・ライブラリが含まれていない
このチェックリストを通すと、App Store 審査に通る確度が大幅に上がります。
次に生成する画面で、最初にやること
出力の質を上げようとして指示を長くしていた時期が私にもありました。効いたのは長さではなく、毎回同じものを指し続けられるかどうかでした。
次に画面を一つ起こすとき、指示を書き始める前に参考画像を 1 枚決めてください。それだけで往復の数が変わります。
書き直しの記録が、どなたかの往復を一つでも減らせたなら嬉しいです。
Rork AI で生成したネイティブアプリの品質は、あなたのプロンプトと、Rork Companion での反復改善サイクルで決まります。本記事で紹介したテクニック・チェックリストを活用して、本番品質のアプリを素早く完成させてください。