ほとんどのAI製品を開くと、画面の隅に同じドロップダウンがあります。何かに取りかかる前に、まずやるべき仕事があるのです。それはモデルを選ぶこと。場合によっては、どれくらい深く考えさせるかまで決めなければなりません。
この選択は重要です。あるモデルは難しいバグの追跡に優れていても、なぜかデザインは苦手かもしれません。別のモデルは美しいインターフェースを作れても、長いビルドの途中で流れを見失うことがあります。そして新しいモデルがリリースされ、ランキングがまた入れ替わり、価格も変わります。
あるモデルを「最高」と呼ぶのは、最先端モデルの世界に王座があるという前提に立っています。しかし、そんなものはありません。モデルの選択によってアプリケーションが動くかどうかが変わるのなら、作業を始める前に正解を当てる必要などないはずです。
Lovableにとって、それこそがモデル非依存の意味です。私たちはモデルを交換可能なものとは考えていません。モデルについて強いこだわりを持っているからこそ、モデル非依存なのです。
モデルに依存しない。でもモデルに無頓着ではない
モデルに無頓着であるとは、すべてのモデルを同じインターフェースの裏に置き、同じ指示を与え、名前を差し替えるだけのことです。本当のモデル非依存とは、それぞれのモデルが最も力を発揮する方法を学ぶことです。
Lovableにはこの仕事に専念するチームがあります。チームはモデルごとに、その得意分野に合わせて指示、ツール、プロジェクトのコンテキストを調整します。長いデバッグのループなのか、バックエンドの設定中なのか、インターフェースの仕上げ中なのか、あるいはまったく別の場面なのか、モデルがどこで行き詰まるのかを調べます。そのうえで、構成全体を完全なビルドを通してテストします。
たとえばある評価では、最先端モデルが前のバージョンに比べてタスクを15%速く完了し、ターン数は40%少なく、スコアは2〜3%高くなりました。これは意味のある改善であり、当時はその新しいモデルの方が有力な選択肢となりました。
私たちは、あるモデルをLovableの中でうまく機能させるために多くの投資をしながらも、より優れたものが登場すれば乗り換えることができます。移植性があるからこそ、モデルごとに振る舞いがどれほど違うかについて学んだことを捨てずに、その自由を得られるのです。
コントロールプレーンこそがプロダクト
「アプリに決済機能を追加して」というのは、一つの指示に聞こえます。Lovableの中では、このリクエストがアプリ構築エージェントを動かします。エージェントはリクエストから実際に動く変更までビルドを進め、その途中で見つけたあらゆることに対応します。
エージェントは、ユーザーの意図を理解し、プロジェクトの関連箇所を見つけ、変更を計画し、コードを書き、アプリを実行して、動くかどうかを確認しなければなりません。何かが壊れたとき、正しい回復の道筋は必ずしも明らかではありません。システムは再試行すべきでしょうか。それとも計画を変えるべきか、別のツールを使うべきか、異なる推論をするモデルを呼ぶべきか、あるいはユーザーに質問すべきでしょうか。
答えは、ビルドの途中で何が明らかになるかによって変わります。シンプルなリクエストが、アーキテクチャ上の問題を浮かび上がらせることもあります。あるいは最初の試みで、モデルが目標は理解していたものの、ツールの一つにつまずいていたとわかることもあります。
だからこそコントロールプレーンは、作業の進行を見守ります。ユーザーが何をしようとしているのか、作業がどれほど難しくなっているのか、エージェントが前進しているのか、それとも堂々巡りを始めているのか。そのうえでコントロールプレーンは、一つのモデルに全体を任せるのではなく、ビルドの各部分を異なるモデルに割り当てることができます。
コントロールプレーンは、モデルを取り巻くシステムも調整します。ある評価では、あるモデルがすでにコンテキストにあるファイルを何度も読み直し、編集が成功した後にも再確認していました。そこで私たちは別の指示を与えました。コンテキストを信頼し、編集結果を信頼し、冗長なツール呼び出しを省くように、と。ほかにも、ツールそのもの、ツールの説明の仕方、モデルに見せるプロジェクトのコンテキストの量、次のターンの前に長いビルドをどう要約するかを変えることもあります。
これはモデルのルーレットではありません。同じプロンプトを5つのモデルに送り、気に入った応答を選ぶわけではないのです。各モデルに合った指示、ツール、コンテキストを与え、そのうえでアプリが良くなるかどうかを判断します。
モデル非依存とは、頻繁に切り替えることではない
ビルドの途中でモデルを変えると、かえって状況が悪くなることがあります。長く続くプロジェクトには履歴が蓄積されるからです。エージェントはファイルを探索し、さまざまなアプローチを試し、エラーにぶつかり、何が重要かを学んできました。モデルはそのエージェントの一部にすぎません。モデルが変わると、その履歴を圧縮し、キャッシュされたコンテキストを再構築しなければならない場合があります。会話の細部の中には、要約としてしか残らないものもあるでしょう。
つまり、単体では優れたモデルでも、目の前のビルドにとっては誤った選択になりうるということです。コントロールプレーンは、得られる可能性のある効果と、失うかもしれないコンテキストややり直しになるかもしれない作業とを比較しなければなりません。目指すのは、できるだけ頻繁にモデルを切り替えることではありません。意味のある切り替えは、そのコストに見合うものでなければなりません。そうでなければ、無駄なモデルの入れ替えを生むだけです。
切り替えるかどうかの判断は、システムが失敗した理由を知ることから始まります。アプリ構築エージェントが「ぼやき」ツールを通じて直接教えてくれることもあり、ほかの方法では見えにくい問題を浮かび上がらせてくれます。
モデルプロバイダーが過負荷になっている場合、Lovableは次の呼び出しを別のプロバイダー経由で同じモデルに送ることができます。これで可用性の問題は解決できますが、まずいアプローチは解決できません。コンテキストが間違っている、ツールがわかりにくい、モデルが作業を誤解している、といった場合にプロバイダーを切り替えても、失敗の原因に対処しないままキャッシュを手放すことになります。ユーザーからのフィードバックを添えて再試行すれば役立つこともあります。そうでなければ、別のモデルが別のアプローチを試せます。
回復では、失敗したものそのものを変えるべきです。それがコンテキストであれ、計画であれ、ツールであれ、モデルであれ。
ベンチマークはアプリケーションそのもの
モデルは見事な回答を出しながら、壊れたアプリを残すことがあります。一度も動かない説得力のあるコードを書いたり、完成したように見えるのに誤ったデータを保存するチェックアウトページを作ったりすることもあります。ベンチマーク上では素晴らしい応答に見えても、ブラウザ上では話が別かもしれません。
そのため、Lovableにおける最適化の単位は完成したアプリケーションです。私たちが重視するのは全体の道のりです。システムが何を試したのか、どこで回復したのか、ビルドにどれくらい時間がかかったのか、コストはいくらだったのか、そして最終的にアプリケーションが依頼どおりに動くのか。
これによって「速い」「安い」の意味が変わります。応答が速いモデルでも、完了までに3倍のラウンドを要するなら遅いのです。安い呼び出しでも、ビルドを誤った方向に進ませれば高くつきます。どれほど優れた計画も、システムがそれを動くソフトウェアに変えられなければ意味がありません。
公開リーダーボードは有望なモデルを見つける手がかりにはなりますが、それらのモデルがLovableの中でより良いアプリを生み出すかどうかまではわかりません。私たちは、自社のプロンプト、ツール、コンテキスト、エージェントループを使って、候補となる各モデルをLovableの中でテストします。一度の素晴らしい結果は運かもしれないため、すべてのビルドを複数回実行します。良い結果を出したモデルは、まず少しの作業から任され、成果を出し続けた場合にのみ、より多くの作業を任されます。
テスト自体も、私たちの信頼を得なければなりません。私たちは、人間の判断、LLMによる評価者（LLMジャッジ）、そして外部の根拠から予想されるモデルのランキングが一致しているかどうかを確認します。これらのシグナルが食い違うときは、ビルドを調べてその理由を突き止めます。ある比較評価では、その結果、中身のないビルドを上位近くに評価していたジャッジを再調整し、ほぼ同一のビルドに正反対のスコアをつけた別のジャッジを外しました。
一貫してより良いアプリを作るモデルほど、多くの作業を任されます。最終的なチェックは人間の判断です。
最適なモデルが自社製のこともある
プロンプトに段落を一つ追加することで得られる改善には限界があります。例外が積み重なり、ある指示で一つの失敗を直すと、今度はモデルの注意が別のことからそれてしまいます。やがて、プロンプトを編集してもそれ以上は改善しなくなります。十分に頻繁に発生する作業なら、専門のモデルを用意する方が理にかなっています。
こうして私たちは独自のモデルのトレーニングを始めました。リクエストのルーティング、応答の要約、コミットメッセージの作成は、明確に定義された作業であり、モデルのトレーニング、評価、リリースの方法を学ぶのに適していました。
現在、私たちがポストトレーニングしたモデルは、本番環境でアプリ構築作業のかなりの部分を担っています。次のモデルは、より難しい問題や、各ビルドのより多くの部分を担えるようトレーニングしていきます。
自社のモデルも、外部のモデルと同じコントロールプレーンを通ります。ある作業で外部モデルの方が優れていれば、自社モデルと置き換わることもあります。自社でトレーニングしたモデルでさえ、担当するトラフィックは実力で勝ち取らなければなりません。私たちの目標は、Lovableが最もよく理解している作業において、世界最高のモデルを作ることです。
学んだことは次に生きる
最先端モデルへのアクセスは、どの企業でも購入できます。難しいのは、ムラがあり急速に変化するモデルの強みを、人々が頼れるソフトウェアに変えられるシステムを作ることです。あらゆる失敗がシステムの改善に役立ちます。一つひとつの失敗がテストとなり、プロンプト、ツール、コンテキスト、オーケストレーション、評価者、モデルのうち、どれを変えるべきかを教えてくれます。私たちはビルドを再実行し、学んだことをコントロールプレーンにフィードバックします。
その学びは、新しいモデルがリリースされたときにも生きます。Lovableは新しいモデルを、何が良い結果なのかをすでに知っていて、その能力が活きる場所を見つけられるシステムにかけるのです。
モデル企業は自社のモデルを改善できます。Lovableはシステム全体を改善できます。
最先端のすべてを、ユーザーのために
基盤モデルは今後も進化し続けます。ただし、同じ分野で、同じ速さで、誰かの予想どおりの順番で進化するわけではありません。
推論、速度、あるいは繰り返し発生するタスクで飛躍的に進化したモデルがあれば、Lovableはそれが役立つ場面で活用すべきです。遅れをとったなら、Lovableは次へ進むべきです。
モデルピッカーが行き止まりなのは、システムが問題について十分な情報を得る前に判断を固定してしまうからです。Lovableは作業を見守り続け、その作業に必要なモデルを使い、根拠が変われば方向を変えるべきです。
作りたいものをLovableに伝えるだけで大丈夫です。その裏で最先端の技術がどれだけ動き続けても構いません。その変化に追いつくのが私たちの仕事です。だからこそ、人々に愛されるソフトウェアを作ることに集中できるのです。
