Claudeが書き、Geminiがレビューし、ChatGPTが壁打ち相手になる

単一ベンダーのAIは紙の上では簡単に見えるが、実際には脆さを出荷する。RakuAIは複数ベンダーによるエージェントループによって構築されている — そして、どのベンダーのモデルでも動かせるように構築されている。開発プロセスは製品の主張を映し出している。

土曜の朝、コーヒー、そしてまた変わる前のワークフロー。エージェントと一緒にエンジンを構築していると人に話すと、最初の質問は「どのエージェント」だ。正直な答えは「複数、それぞれ異なる役割で、そしてその分業が重要だ」というものだ。この投稿はその、より長い答えだ。

今、開発ワークフローには少なくとも3つの異なるAIベンダーが、ループの中で異なる役割を演じている。理由は忠誠心や好き嫌いではない。それぞれのモデルが実際に異なる形の作業に長けており、1つのモデルにすべてをやらせようとすると、明らかに質の低いコードが生まれるからだ。

今日における役割分担

Claudeがランタイムコードのほとんどを書く。 大きなコードベースにわたる長文脈の推論、編集前の計画立て、1つの頭の中に多くの状態を保持すること。これは、実質的なサブシステム作業でイシューキューに走らせるモデルだ。あるイシューが「OpenXRコンポジションレイヤーマネージャーとアクションスペースを実装せよ」と書けば、そのPRを着地させるのはClaudeだ。

Geminiがほとんどのpr.のレビューをする。 異なる学習、異なる死角。Claudeが1つのPRを着地させると、Geminiが差分を読み、押し返す。Geminiが表面化させる種類のコメントは、私が手作業で表面化させる種類とは異なる。ノイズもあれば、有用なものもある。そのシグナル対ノイズの比は十分に良く、あらゆる差分に対する最初のレビューパスとしてGeminiを信頼している。

ChatGPTは私が壁打ちする相手だ。 アーキテクチャ上の決定で行き詰まり、まだどちらに進むべきか分からないとき、ChatGPTに向けて声に出して考える。この役割ではモデルはコードを書かない。前提を突いてきて、3つの代替の枠組みを提案し、私にそれと議論させる。もし自分に上級の同僚がいれば果たすであろう役割だ。今のところ私にそういう人はいない。ChatGPTがそのシミュレーションだ。

Copilotはエディタの中にいる。 これは自動補完の役割だ。手作業でコードを書いているとき(人々が思うより頻度は低いが、実際にある)、CopilotはIDEの中でその提案を目にするモデルだ。局所的な文脈、次の4行という作業を得意とする。

それがワークフローだ。4つのモデル、4つの役割。それぞれが、他のモデルがその役割を担うよりも優れている。

なぜ複数ベンダーが重要なのか

理由は3つある。

能力の上限はベンダーごとに異なる。 もし私がすべての役割に1つのモデルを使っていたら、そのモデルのあらゆる弱点が開発プロセスの弱点として現れるだろう。Claudeは書くことに優れている。自分自身が書いたもののバグを見つけることにはそれほど優れていない。Geminiはバグを見つけることに優れているが、監督なしにリファクタを計画させたいモデルではない。ChatGPTは開放的なアーキテクチャの問いについてよく考えるが、実際のサブシステムにおけるそのコードは出荷したいものではない。それぞれが、1つの枠にとって最良のツールだ。

レビューにおける独立性は構造的なものだ。 私が行き着いた、ただ一つ最も重要なルールは、あるPRを書いたモデルは、それをレビューするモデルにはなれないということだ。自己レビューはレビューではない。異なるベンダーのモデルに最初のレビューパスをやらせることは、アーキテクチャの独立性、学習データの独立性、失敗モードの独立性を生む。GeminiがClaudeのコードの中に見つけるバグは、そうでなければ着地していたはずの本物のバグだ。

特定ベンダーへのロックインがない。 このエンジンは、どのクラウドLLMからの指示も受け取れるように構築されている(先月のXRAssistantServiceの作業で取り上げた通りだ)。エンジンを構築する開発ワークフローも、その姿勢に合わせるべきだ。私は、このランタイムのエンジニアリングが、今後5年間ある一社のベンダーが競争力を保ち続けることに依存するのを望まない。そのどれも保ち続けはしないだろう。今良いものは、後には違う形で良くなるだろう。開発レイヤーで複数ベンダーのワークフローを走らせることで、エンジニアリングは移植可能なままでいられる。

正直なコスト

いくつかある。

調整のオーバーヘッドは本物だ。 タスクの途中でベンダーを切り替えることには認知的なオーバーヘッドが伴う。修正策は、各タスクを1つのベンダーの車線の中に収め、タスクとタスクの間で引き渡しを行うことであって、タスクの中で行わないことだ。

請求額は積み重なる。 4つのモデルのサブスクリプションを走らせるのはタダではない。コストは相応にあり、今のところ私が個人で支払っている。その見返りは出荷されたサブシステムという形で測定可能なので、この段階では計算は合っている。いつもそうだとは限らない。

ベンダー間の品質のずれは本物の問題だ。 GeminiがClaudeがこれまでやってきた種類のタスクをより得意になったとき、正しい答えはそのタスクをGeminiに移すことだ。間違った答えは、ワークフローの文書がそう書いているからという理由で古いやり方を続けることだ。ワークフローの文書は、モデルの勢力図がワークフローの下で動くたびに、数週間ごとに改訂されなければならない。

ベンダー同士は互いのことを知らない。 Claudeが、Geminiによってレビューされることになるコードを書くとき、Claudeはそのことを知らない。ChatGPTが私とアーキテクチャ上の判断について議論するとき、Claudeによる最終的な実装はその議論を見ない。ベンダー間の統合は私の頭の中にある。それは統合が存在するには脆い場所であり、もし私が他の人々がこのワークフローを運用するのを助けるインフラを構築するとしたら、修正したいことの一つだ。

ランタイム側についてはどうか

ここが、開発ワークフローの話とエンジンの話が収束する部分だ。

2週間前にランタイムに着地したXRAssistantServiceは、設計上モデルに依存しない。その理由は、この開発ワークフローが複数ベンダーであることの理由とまったく同じだ。このインターフェースは、これらのラボのどのモデルでも、ランタイムを通じてAR体験を駆動できるように構築されている。任意のタスクにおいて最も優れたモデルを持つラボが、任意の体験においてそのタスクの意図を提供することになる。

これがより広い賭けだ。「この製品はこのベンダーのこのモデルの上に構築されている」という時代は短い。私たちが入りつつある時代は「この製品はモデル形の能力を中心に構築されており、任意の瞬間にどの具体的なモデルがどの能力の枠を埋めるかは設定上の選択である」というものだ。エンジンはそれに備えていなければならない。エンジンを構築する開発ワークフローは、それを反映すべきだ。

ビルダーとラボにこれから読み取ってほしいこと

もしあなたがコーディングエージェントのベンダーで、これを読んでいるなら、私が最適化したいと思う指標は「このエージェントのPRが、競合ベンダーのエージェントによるレビューをどれだけの頻度で生き延びるか」だ。自己整合性は基準ではない。ベンダー横断のレビューを生き延びることが基準だ。その指標で良い成績を出すエージェントが、本気の作業に使われることになるエージェントだ。

もしあなたが、本気のコードベースに対してAI支援のワークフローを採用しようと考えている開発者なら、1つのモデルを選んでそこで止まらないでほしい。書くためのモデルを1つ選ぶ。レビューのために別のモデルを選ぶ。開放的なアーキテクチャの判断を壁打ちするために3つ目を使う。コストの上乗せは本物だが、品質の違いはもっと大きい。

もしあなたが、自社の開発組織におけるAIについて考えているエンタープライズのリーダーなら、複数ベンダーのパターンがスケールするパターンだ。単一ベンダーの採用は紙の上では簡単に見える。実際には、技術的にも戦略的にも脆さを生み出す。

静かな土曜日。エンジンは35コミットの週末を得た。それらのコミットのほとんどは、半年後には目に見えなくなっているだろう。それらを生み出したワークフローはそうならない。