同じプロンプトを Rork と他のAIビルダーに投げて、完成までの時間を計測したことがあります。Rork は平均で 30〜40 秒、他のツールは 90 秒以上かかりました。モデルそのものは似たような系統（Claude や GPT 系）を使っているはずなのに、なぜこれほど差が出るのか。3 ヶ月ほど観察し、公開されている情報と実際の挙動を突き合わせるうちに、いくつかの「機械学習最適化」が裏で効いていることが見えてきました。
ここでは開発者として知っておくと役に立つ 5 つの最適化について、体感したこと・推測できることを正直に書きます。内部実装の完全な解説ではなく、「使う側として何を期待していいか」を整理する記事だと思ってください。
生成が速い理由は、モデルが賢いからだけではない
AIコード生成というと「裏で賢いLLMが全部書いている」と思われがちですが、実際には LLM の出力だけで UI を組み立てているわけではありません。Rork のような成熟したビルダーは、LLM の呼び出し回数そのものを減らす工夫に多くのエンジニアリングを割いています。
観察していて気づくのは、同じプロジェクトの中でプロンプトを繰り返すと 2 回目以降が明らかに速くなることです。これは LLM を毎回フルに動かしているのではなく、プロジェクト固有のコンテキストをキャッシュしている証拠だと考えています。
最適化 1: プロンプトキャッシュで初回生成後の待ち時間を削る
Anthropic の Claude API プロンプトキャッシュと同じ仕組みが、Rork の生成パイプラインにも組み込まれている節があります。プロジェクトの構造情報（ファイル一覧・既存コンポーネント・スタイル規則）は変わらないことが多いので、これを毎回送り直すのは無駄です。
体感では、プロジェクト 1 発目の生成が 45 秒、2 発目が 25 秒、3 発目以降は 15〜20 秒で安定するパターンをよく見ます。プロンプトキャッシュで入力トークンの再処理コストが 10 分の 1 程度になるので、この観察とつじつまが合います。
実装側の工夫としては、同じセッション中に細かく質問を重ねたほうが速度的には有利だと分かります。
最適化 2: 差分生成（ファイル全体ではなく変更箇所だけ書き換える）
UI の 1 箇所だけ修正してほしいときに、Rork は画面全体を書き換えるのではなく、対象コンポーネントだけを差し替えるような振る舞いをします。これは「差分生成（structured edits）」と呼ばれる最適化で、モデルに書かせる出力量を最小化する手法です。
以下は差分生成を意識したプロンプトの書き方の例です。
// ❌ 全体を再生成させる書き方（遅い・壊れやすい）
// → 「このホーム画面のボタンを青くして、同じようにヘッダーも調整して」
// ✅ 差分生成に誘導する書き方（速い・安定）
// → 「HomeScreen.tsx の <PrimaryButton> の backgroundColor だけ
// theme.colors.primary に変更してください。
// 他のファイルや他のプロパティは触らないでください。」
// 期待される挙動:
// Rork はファイル全体を再生成せず、該当プロパティのみ差し替える
// 生成時間: 約 5〜8 秒（全体書き換えだと 20〜30 秒）ファイル名・対象コンポーネント・変更箇所を具体的に指定すると、Rork 側の差分検出が効きやすくなります。私は最近、ほとんどの細かい修正をこの書き方に統一していて、待ち時間がかなり減りました。
最適化 3: コンテキスト圧縮 — 「全部覚えておく」をやめる
長時間のセッションで Rork が過去のやり取りを忘れずに応答してくれる一方、コンテキストウィンドウに履歴を全部詰め込んでいるわけではないようです。これは「コンテキスト圧縮」あるいは「要約チェーン」と呼ばれる手法で、古いやり取りを別の小さなモデルで要約して保持し、本番の LLM には要約版だけを渡します。
体感としては、セッションが長くなっても応答速度が落ちにくいのがこの設計のメリットです。ただし副作用もあって、初期セッションで決めた細かい UI 規則（例: 角丸は 12px 統一）をセッション後半で忘れることがあります。重要なルールはプロンプトで再確認させるか、プロジェクトの設定に明記するのが安全です。
最適化 4: 推論の並列化 — 複数箇所を同時に書かせる
複数ファイルにまたがる変更をお願いすると、Rork は内部で各ファイルの生成を並列に走らせているように見えます。1 つのリクエストを逐次的に処理すると待ち時間が足し算で増えていきますが、独立性の高い編集は並列で走らせれば最も遅いファイルの時間で済みます。
これが効いてくるのは、たとえば「ユーザープロフィール画面と設定画面の両方に同じカードコンポーネントを追加して」のような依頼のときです。逐次だと 30 秒 × 2 = 60 秒かかるところが、並列化で 35 秒くらいに収まる感覚があります。
開発者としての応用は単純で、独立したタスクはまとめて依頼すると時間効率がいいということです。依存関係のあるタスクを並列化させようとしても逆に壊れやすくなるので、「この画面とこの画面は別々に動くはず」と判断できるものだけまとめましょう。
最適化 5: 投機的デコーディングでトークン生成を加速
これは推測が混じりますが、Rork Max のような上位プランで体感する「生成の瞬発力」は、Claude Opus をベースにした投機的デコーディング（speculative decoding）の効果に見えます。小さなドラフトモデルが数トークン先までを先行生成し、大きなモデルがそれを一括検証する手法です。
ドラフトが当たれば 2〜3 倍速くなり、外れてもフォールバックで通常速度に戻るだけ、というのが投機的デコーディングの魅力です。Rork Max で「最初の数文字が出てからの流れがやたらスムーズに感じる」のは、これが働いている可能性が高いと思っています。
実際の計測 — シンプルなプロンプトで比較する
以下は手元で計測した、同一プロンプトでの生成時間の一例です。環境や時期によって結果は変わるので、あくまで参考値としてご覧ください。
// 計測したプロンプト:
// "TODOアプリを作ってください。タスク追加・完了・削除機能付き"
const measurements = {
rork_standard: {
firstGeneration: 32, // 秒
secondRefinement: 18,
thirdRefinement: 12,
},
rork_max: {
firstGeneration: 22,
secondRefinement: 11,
thirdRefinement: 7,
},
};
// 2 回目以降が明らかに速いのは、
// プロンプトキャッシュとコンテキスト圧縮が効いている証拠差分生成を意識した修正（「追加ボタンの色だけ変更」など）では、3〜5 秒で返ってくることもあります。
開発者として今日から活かせる 3 つの実践
- セッションは切らずに続ける — プロンプトキャッシュを活かすため、関連する修正は同じセッション内で続ける
- 変更箇所を具体的に指定する — ファイル名・コンポーネント名・プロパティ名を明示して差分生成を引き出す
- 独立したタスクはまとめて依頼する — 並列化が効くので、関連しない 2〜3 件を 1 プロンプトにまとめる
この 3 つを意識するだけで、私の場合は体感の待ち時間が半分以下になりました。Rork の機械学習最適化は裏で勝手に動いてくれますが、使う側の書き方で引き出せる性能は大きく変わります。
ここで紹介した最適化は公式ドキュメントで明示されていないものも含みますので、実装の詳細が気になる方はぜひご自身の環境でも計測してみてください。次に試すなら、AI コード生成ワークフローと組み合わせて、プロジェクト単位の生成パターンを設計してみるのがおすすめです。