「Rork でアプリを作れる」ということは知っているけれど、Rork Companion が Rork 本体と何が違うのか、いまいちピンとこない——そういう方が少なくないようです。ここではCompanion の立ち位置を明確にした上で、開発の各フェーズでどう使うと効果的かを具体的に説明します。
Rork Companion を使い始めてから、アプリ開発の最初の壁である「どこから手をつけるか」が大幅に楽になりました。アイデアが漠然としているうちは手が動かないものですが、Companion と話すことで思考が整理されていく感覚があります。
Rork Companion とは（Rork 本体との違い）
Rork 本体は「コードを生成するエンジン」です。指示を与えるとSwiftUIやKotlin Composeのコードを出力します。一方、Rork Companion はその前後を補うAIアシスタントです。
具体的には、Companion は以下のような役割を持っています。
設計フェーズ: アイデアを一緒に掘り下げ、実現可能な機能リストに落とし込む。ターゲットユーザーや使用シーンを整理します。
実装フェーズ: 生成されたコードの説明、バグの診断、「この部分を直したい」という相談への対応。
学習サポート: SwiftUIやKotlin Composeを詳しく知らない人が、コードの意味を理解しながら進めるための説明。
つまり、Companion は「Rorkを上手に使うためのナビゲーター」という位置づけです。Rork 本体が強力なエンジンだとすれば、Companion はそのエンジンを目的地に向けるハンドルです。
最初の10分：Companion を起動してアプリのアイデアを話す
Companion を開いたら、最初に「作りたいアプリのアイデア」を伝えるところから始めます。この段階ではまとまっていなくて大丈夫です。
# 最初のメッセージの例（まとまっていなくていい）
「ランニングを記録するアプリを作りたい。
現在のアプリは機能が多すぎてシンプルに使いたいんだけど、
具体的に何が必要かはまだ考えていない。」
Companion はこれに対して、いくつかの質問を返してきます。
- 「1回のランニングで記録したい情報は何ですか？（距離・時間・ルートなど）」
- 「過去のデータはどう使いたいですか？（週間・月間のグラフなど）」
- 「他のアプリやウェアラブルとの連携は必要ですか？」
これらの質問に答えていくうちに、アプリの輪郭が定まっていきます。「記録はシンプルに距離と時間だけ。グラフは週間だけあればいい。Apple Watchとは連携したい。」のように、10分ほどで機能リストがまとまります。
この「アイデアを話す」フェーズを飛ばしていきなりコード生成に進むと、生成されたアプリが自分の想定と違うことが多くなります。Companion との対話で仕様を整理してからRorkに渡す方が、結果的に手戻りが少なくなります。
設計フェーズでの使い方：画面構成からAPI設計まで
機能リストができたら、Companion に画面設計の相談ができます。
「さっきまとめた機能で、アプリの画面構成を提案してほしい。
シンプルさを重視したい。」
Companion からは画面一覧と各画面の役割が返ってきます。
Companionの回答例（要約）:
「シンプルなランニング記録アプリには、以下の3画面が適切です。
1. ホーム画面: 今日のランニングを開始するボタン、直近の記録サマリー
2. 記録中画面: 経過時間、現在距離のリアルタイム表示、終了ボタン
3. 履歴画面: 週間ランニングリスト、週間距離の合計
Apple Watch連携は、記録中画面のコンパニオン機能として実装します。
HealthKitへの書き込みはバックグラウンドで行うため、追加の画面は不要です。」
この回答に対して「ホーム画面に週間グラフも入れたい」と追加指示を出すと、それを踏まえた設計に更新してくれます。設計段階でこのような対話ができると、Rorkに渡すプロンプトの精度が上がります。
実装フェーズ：「ここを直して」が一番効くコミュニケーション術
Rorkでコードが生成されたら、Companion との連携が本番になります。
最もよく使うパターンは「エラーメッセージをそのまま貼る」です。
「Xcodeでビルドしたらこのエラーが出た。どう直せばいい？
Error: Value of type 'CLLocationManager' has no member 'requestLocation'
File: LocationManager.swift, Line: 47」
Companion はエラーの原因（この場合、iOS 14以降でrequestLocationの代わりにstartUpdatingLocationを使う必要があること等）を説明した上で、修正後のコードを示してくれます。
エラー以外でも、「このコードが何をしているか分からない」という相談もできます。
「Rorkが生成したこのコードの意味を教えてほしい。
特に @StateObject と @ObservedObject の使い分けが分からない。
[コードを貼る]」
Companion はSwiftUIの状態管理の仕組みを、そのコードの文脈で説明してくれます。コードを読みながら理解を深められるのは、単なる「コード生成ツール」にはない Companion の強みです。
「この画面に検索機能を追加したい」「リストをスワイプで削除できるようにしたい」といった機能追加の相談も有効です。Companion が「この変更を Rork に指示するときは、このように書くと伝わりやすい」と、Rork へのプロンプトの書き方もアドバイスしてくれます。
会話が長くなってきたら——Companion の記憶を活かす頼み方
Companion は一つの会話の中では、それまでのやり取りを覚えた状態で応答します。前に話したアプリの目的や画面構成を、毎回説明し直さなくてよいのは大きな利点です。
ただ、会話が長く続くと、最初に決めた前提が後半で薄れていくことがあります。私自身、序盤に「iOS 16以上が対象」「タブは3つまで」と伝えていたのに、終盤で iOS 14 向けのコードを提案され、手が止まったことがありました。古い指示が新しいやり取りに押し流されていく感覚です。
これを防ぐ頼み方には、いくつかコツがあります。
会話の冒頭に「前提メモ」を置いておきます。対象OS、使うフレームワーク、外せない制約を短い箇条書きにしておき、要所で一度だけ再掲します。長文で念を押す必要はありません。短く、要点だけです。
前提（変更しないでください）:
- 対象: iOS 16 以上
- 状態管理: SwiftUI 標準（@State / @Observable）
- 画面は最大3タブ
画面やファイルは、毎回同じ名前で呼ぶようにします。「設定画面」と「SettingsView」を混ぜると、Companion がどれを指しているか取り違えやすくなります。名前を一つに固定するだけで、修正依頼の精度がはっきり上がります。
話題が大きく変わったときは、思い切って新しい会話を始めます。一つの会話に別アプリの相談まで詰め込むと、前の文脈が混ざって的外れな提案が増えていきます。引き継ぎたい情報があれば、その要点だけを短くまとめて新しい会話に貼れば十分です。
個人開発で複数のアプリを並行して触っていると、つい一つの会話を延々と使い続けてしまいます。Dolice Labs で複数のブログを運用しているときも同じで、文脈を一度区切る方が、結局は速く正確に進みます。
Companion が苦手なこととその回避策
Companion が得意でないことも正直にお伝えします。
複雑なパフォーマンスチューニング: 「なぜこのUIがカクつくのか」を特定するような低レイヤーの最適化は、Companion より Instruments（Xcodeのパフォーマンス計測ツール）の方が確実です。原因の仮説は出してくれますが、実際の計測には開発ツールを使う必要があります。
最新APIへの追従: SwiftUIやKotlin Composeのバージョンが上がると、使える APIが変わります。Companion の知識は学習データのカットオフ以降の変更を反映していないため、最新のXcodeリリースノートと照合する習慣を持つことをお勧めします。
デザインの提案: UIのビジュアルデザインや色使いについては、Companion より FigmaやAppleのHuman Interface Guidelinesを参照する方が質の高いインプットを得られます。「このアプリにはどんな色が合う？」という相談はできますが、これは専門外です。
Rork Companion は「始める壁を下げてくれる」ツールです。アプリを作ろうと思いながらもなかなか手が動かない方に、まず試してみてほしいのが Companion との最初の会話です。作りたいものを話すだけで、次にやるべきことが見えてきます。