なぜ専用AIが万能モデルに勝り得るのか？
OpenRouterとReplitによる対談：汎用モデルが探索を担い、専用モデルが反復タスクを引き継ぐ。企業は自社データ、評価、権限管理によってそれらを組み合わせる。
a16zは2人の技術起業家――OpenRouter創業者のAlex Atallahと、Replit創業者兼CEOのAmjad Masadを招き、Why Specialized AI Could Beat The God Modelと題した対談を実施した。
対談の核心的な主張は、未来のAIエコシステムは、あらゆることを一手に引き受ける単一の「神級モデル」（God Model）に主導されるとは限らないということだ。両登壇者ともに、異なるモデル同士の能力の相互補完、すなわち彼らが呼ぶところの「ニューロダイバーシティ」（Neurodiversity）を重視している。ただし、それらの能力をどのように組織化するかについてはトレードオフが存在する。Amjadは統合されたコンテキストの価値を強調し、Alexは専用Agentによる垂直的な役割分担を有望視している。
平たく言えば、どれほど賢いAIであっても、銀行口座の管理、コードの記述、顧客対応を同時に任せるのに適しているとは限らない。企業がより関心を寄せているのは、異なるアシスタントにそれぞれの得意分野を担当させ、個別に権限を制限し、結果を検証したうえで、それらを協調させられるかどうかである。この対談で議論されたのは、そうした分業がなぜ価値を持つのか、そして能力・コスト・コントロールをいかに両立させるかという点だ。
汎用モデルを超えて、プロダクトはどんな価値を提供できるのか？
この対談は、StripeによるOpenRouterの買収後に行われた。Alexによれば、彼が重視したのはブランド、プロダクト、ロードマップの自律性と、より強力な市場展開である。双方は、信頼性が高く妥当な価格のインフラを通じて、すべての事業が単一の巨大企業に集約されるのではなく、より多くの新興企業が台頭することを支援したいと考えている。彼はまた、将来的に企業の決済とモデル推論がより密接に結びつくだろうと構想している。（00:47：買収の背景）
このことは、OpenRouterがなぜモデルの選択肢とコストに関心を寄せるのかを説明している。開発者が異なるモデルを用いて差別化されたプロダクトを作ることができ、呼び出しコストも十分に低ければ、より多くのビジネスが成立する機会を得られる。これはAlexの産業に対する期待であると同時に、モデルアクセスプラットフォームとしてのOpenRouterの事業方針とも結びついている。
AIプロダクトを構築する際、非常に直接的な疑問が投げかけられる。「あなたが作ったものは、直接ChatGPTやClaudeを呼び出しても同じようにできるのではないか？ なぜわざわざあなたのプロダクトを買う必要があるのか？」
Alexは、こうした均質化のジレンマを打破するための答えは、より長く精緻なプロンプトを書くことではなく、ニューロダイバーシティ（Neurodiversity）にあると考えている。
モデルによって使用される訓練データや手法は異なり、得意とするタスクも異なる。Alexの見立てでは、企業は異なる訓練手法で学習されたモデル、オープンソースおよびオープンウェイトのモデル、自社開発の専用小型モデル、そして企業独自のデータを融合させることができる。企業は自前のタスク評価を用いて、そうした組み合わせが単に汎用モデルを直接呼び出すよりも真に優れているかどうかを判断しなければならない。
さらに現実的な考慮点は費用対効果にある。もし市場全体でOpenAIだけが一強となれば、独占または半独占状態において、モデル提供側には自発的に価格を下げる動機が欠ける可能性がある。しかし、複数のモデルが並行して存在し自由に切り替えられるマーケットプレイスが確立され、企業が成果とコストのバランスがより適切な組み合わせを絶えず選択できるようになって初めて、コストに敏感な数多くのユースケースが真に定着する可能性が生まれる。
企業は自社のデータ、評価、選択権を掌握する必要がある
Alexは当初、多くの企業がおなじみの調達思考を踏襲するだろうと考えていた。「モデルの見分け方はよくわからないから、一番知名度が高く、みんなが買っているところを買おう」
しかし彼がOpenRouterで目にしたのは、多くの企業がオープンウェイトモデル（モデルの重みを取得し、ライセンスに従ってデプロイや微調整が可能なモデル）の探索に前向きであるという事実だった。これは必ずしも完全なオープンソースと同義ではない。企業が注視しているのは、コスト、カスタマイズ能力、そしてベンダーの選択肢である。
1. 「自社の知能を持つ」とは、大規模モデルを自ら訓練することではない
Amjadはインターネットとソフトウェアを例に挙げた。企業はインターネットそのものを作る必要はないが、Webサイトを構築し、ソフトウェアを活用する能力を身につける必要がある。AIも同様であり、企業はどのモデルがどのタスクに適しているか、いかにコストを抑えるか、結果をいかに評価するかといった社内の能力を蓄積すべきである。
この能力は、単一の機能を購入して済むものではない。モデルは進化し続けるため、企業は自前のタスクサンプルと評価基準を持って初めて、新たな選択肢が真に優れているかどうかを判断できる。自らのデータ、業務フロー、評価を掌握しておくことは、ベンダー切り替えのハードルを下げることにもつながる。
Alexは、モデルの能力は一般的なソフトウェアのようにWebページに機能一覧を並べるだけでは説明しきれず、どのように使われるかを見て初めて何に長けているかが分かると指摘する。企業にとって、汎用ベンチマークのランキングは「自社の業務を適切に遂行できるか」という問いに直接答えてはくれない。実際のタスク、遂行結果、コストを継続的に記録し、そのうえで異なるモデルを比較してこそ、自社固有の「モデルとタスクの適合性（マッチング）」に関する知見が蓄積される。対談ではReplitの単一タスクコスト研究を例に挙げ、評価とは単に回答が優れているかだけでなく、その処理を完遂するのにいくらかかったかを問うものでもあると強調した。（08:53：企業のモデル選定と評価）
Amjadはさらに、基盤モデル企業がサプライヤーからアプリケーション企業の競合へと転じる可能性を懸念している。彼は議論の中でFigmaやHarveyなどの企業に言及したが、核心的な見解はサプライヤーの事業領域が拡大し得るという点にある。そのため彼は、Replitが企業とモデル、クラウド環境の間に緩衝層を提供し、企業が異なるサプライヤーやデプロイ環境を選択できる能力を維持できるようにしたいと考えている。
2. 「インフラ」を「プロダクトの競争優位」と取り違えない
対談では、よく見られる観察が言及された。多くのAI Agentプロダクトが似たような機能――計画立案とツール呼び出しを反復するAgentワークフロー、メッセージ通知、コンテキスト管理と長期記憶、サードパーティコネクタ、コードサンドボックス、ウェブ検索、コンピュータ画面の操作能力――を構築しているという点だ。
彼らは、これらの機能はAIアプリケーションを構築するうえでの基本インフラになりつつあると考えている。 これは2005年にWebサイトを構築する際、誰もが「ユーザーデータベース、登録ページ、ログインページ、プロフィールページ、ログアウトボタン」を書いていた状況に似ている。当時としてはそれも技術と見なされたが、それ自体は本質的なビジネス上の差別化要因にはならなかった。
企業はさらに、データアクセスやデプロイ場所も考慮しなければならない。個人であればアシスタントにカレンダーを読み取らせるかどうかを自分で決められるが、企業データは異なる従業員、チーム、顧客の権限に関わってくる。Amjadによれば、こうした懸念からReplitは顧客自身のクラウド環境へのデプロイを可能にする機能に投資してきたという。このようなデプロイの選択肢には、データ分離とアクセス制御が不可欠となる。
1つの万能アシスタントか、それとも複数の専用アシスタントか？
もし社内のあらゆる業務に通じ、すべての業務システムを統合した「スーパー個人アシスタント」を構築したら、何が起こるだろうか？
Replit創業者のAmjadは、自らの実体験を共有した。彼はかつて深く連携させたAgentを自作し、当初は顧客関係管理（CRM）だけに用いていたが、次第に個人のチャット履歴、コードリポジトリ（GitHub）、営業システム（Salesforce）、さらには日々のカレンダーまで接続していった。協調効果の観点から見れば、こうした領域をまたいだ連携は確かに驚くべき瞬間をもたらす。例えばミーティングに向かう直前、Agentが不意に「過去の会議でこの人物と会ったことがあり、先方のチームのメンバーもあなたの営業チームとやり取りしています」と知らせてくれるようなことだ。
一方のAlexは、別の懸念を提起した。仕事を委譲すると、人間は細部に対する理解を失いがちだが、Agentは人間の同僚のように心理的プレッシャーを背負ってはくれない。その結果、ユーザーはどのタスクなら信頼して任せられ、どれには自ら介入すべきかを把握し続ける必要がある。
1. 仕事を委ねても、責任は自動的には消えない
正常に機能している組織において、細部を理解することには精神的コスト（認知負荷）が伴う。ある人物が領域をまたぐ業務のすべてを単一の「万能Agent」に丸投げした場合、一見すると効率が向上したように見えるが、実際には人間がリアルな業務プロセスへの深い理解を手放してしまっている。
しかし問題はここにある。Agentは人間の同僚のようにプレッシャーや責任を引き受けてはくれない。結果に対する責任を負うのは、依然として人間と企業なのだ。
Alexは、仕事を委譲する際に軽減したいプレッシャーを「コルチゾール」に例えた。アシスタントが関与する範囲が広すぎると、ユーザーはタスクの種類ごとに自身の関与度を調整することが難しくなる。専門化の価値は、領域ごとに検証と改善を行える点にある。うまく機能しているタスクは多く委譲し、そうでないタスクにはより深く介入する、という切り分けが可能になるのだ。
2. 信頼の度合いをタスクごとに調整する
Alexは自身の利用体験を語った。かつて汎用Agentに自身が対応すべきタスクを毎日探すよう命じていたが、調整を加えても1週間ほど経つと出力を見なくなるようになったという。責任範囲が広すぎると、アシスタントを持続的に改善していくのは困難だと彼は感じた。
このことから、彼は垂直領域における精緻な役割分担をより有望視している。 社内全般の業務を抱え込み、あらゆる返信を起草する単一の「スーパー総括マネージャー」を求めるよりも、高い能力を持ちながらもそれぞれが単一の細分化された業務領域にのみ特化した10人の「垂直型エキスパート」を揃えるほうが賢明である。後者のアーキテクチャでは、管理者は各専用Agentの能力の境界がどこにあるのか、対応するタスクを誰が検査し、誰が責任を負うのかを明確に把握できる。Agentのパフォーマンスが芳しくない領域では人間が自ら引き継いで深く介入し、Agentが十分に信頼できる境界内では、人間は安心して効率化の恩恵を享受できる。
この2つの方向性には依然としてトレードオフがある。統合されたコンテキストは部門横断的な関連性を発見できるが、役割分担を行えば品質と権限を具体的なタスクに限定しやすくなる。登壇者たちは、1つのコーディネーターが複数の専用Agentを管理する形も想定しているが、汎用アシスタントと直接チャットするような簡潔な利用方法はまだ見出せていない。
アシスタントごとに個別に検証を行えばタスクをより適切に管理でき、異なる業務の情報を相互に関連付ければビジネスチャンスの発見につながる。真に難しいのは、これら2つの能力を同時に維持することだ。個人向けアシスタントであれば本人がどの程度の情報を連携するかを判断できるが、企業向けアシスタントでは異なる従業員やチームのデータ権限を遵守しなければならない。
3. 機械の世界で再び意味を持つ、アダム・スミスの分業論
彼らは経済学における専門化された分業論を援用し、なぜ機械があらゆる業務を丸抱えする必要がないのかを説明した。しかし、産業文明の成熟期において、マルクスは人間社会が直面する「疎外」のジレンマを指摘した。組立ラインの労働者は来る日も来る日も一本のネジを締め続けるだけで、労働の全貌を見失い、労働の成果との感情的な結びつきを失い、人間は冷徹な機械の部品へと退行していく。
それゆえに現代の人間は、過度な分業がもたらす疎外感を克服するため、より教養的で総合的、かつマクロな視野を持った発展を追求している。しかし両創業者は、見事な対比を指摘した。 人間は一生同じ反復作業だけを続けることを望まないかもしれないが、機械であればそうした専門化されたタスクを担うことができる。
ここでさらに、3つのレイヤーを明確に区別しておく必要がある。専用Agentは役割（責任範囲）の分担であり、専用モデルはタスクに応じてモデルを選定または訓練することであり、構造化出力は回答の形式を制限することである。 たとえば、コードアシスタントと顧客対応アシスタントは同一の汎用モデルを共有しつつ、渡されるデータや使用するツールを変えることができる。一方、コスト予測器は個別に訓練し、区間と確率のみを返すようにできる。複数のAgentが存在することは複数の小型モデルを意味するわけではなく、出力が整然としているからといって判断が正しいとは限らない。
この比喩は彼らの機械的分業に対する選好を示しているが、企業アーキテクチャに真に影響を与えるのは権限でもある。現実の組織構造において、一般の従業員はセキュリティコンプライアンスやアクセス制御の観点から、そもそも全知全能の特権を持つことはあり得ず、アシスタントもまた実際のデータアクセス範囲に従わなければならない。
対談では、クレデンシャル（認証情報）の分離に関する一例が挙げられた。1つのAgentが銀行口座を管理し、別のAgentがソーシャルメディアのアカウントを管理する。両者はタスクの完遂に必要な情報をやり取りすることはできるが、互いの口座クレデンシャルを共有する必要はない。
もっとも、役割の分割だけでは不十分である。1つのAgentが悪意ある誘導を受け、公開すべきでない情報を引き渡すよう別のAgentを説得してしまう可能性があるからだ。銀行口座とソーシャルメディアの例で考えれば、ソーシャルメディア用アシスタントは銀行のクレデンシャルを持っていなくても、銀行用アシスタントに機密情報の送信をリクエストすることで、本来の分業体制を間接的に迂回できてしまう。したがって、通信そのものも検証を要する権限境界となる。登壇者たちは、完全に自由な自然言語のやり取りに依存するのではなく、明確なデータ分離と通信プロトコルを備えた協調関係を望んでいる。（23:36：分業、権限、通信）
Alexはさらに、OpenRouter内部で試みているアプローチを紹介した。高速かつ低コストな意思決定モデルを用いてツール呼び出しを検査するというものだ。このモデルは実行Agentのシステムプロンプトや追加ルールと照らし合わせ、現在の操作が許可されているかを判断し、拒否する際にはフィードバックを返す。ツールの呼び出し頻度は高いため、検査自体の遅延とコストも考慮しなければならない。
レッドチーム演習の事例は、なぜそれらを分離すべきかを如実に物語っている。テスト用Agentは攻撃者を模倣し、サンドボックスの突破を試みる必要があるが、インターネットへのアクセスは許されない。もし単一のAgentに攻撃をシミュレートさせつつ、自身のプロンプトを頼りにどこで踏みとどまるかを判断させようとすれば、両方の要件を両立させることは極めて困難になる。別の検査役を設ければ、実行役が知り得ない追加の制限事項を把握し、呼び出しが境界を踏み越えていないかを専任で判断できる。
彼らはまた、サンドボックスやネットワーク制限といった構造的防御の組み合わせにも言及した。モデルが判断を担い、システムが実際に実行可能な操作を物理的に制限する。検査モデルであっても誤判定を起こす可能性はあるため、それを導入したからといって外部の権限管理を撤廃してはならない。
大規模モデルで探索し、専用モデルに反復タスクを引き継がせる
長らく業界内には、ある楽観的な前提が広まっていた。「モデルが賢くなればなるほど、人間の意図をより深く理解できるようになり、したがって自然とより安全になり、よりアラインメントが取れるようになる」というものだ。
対談でもこの可能性は提起された。能力の向上が、制約の理解や協調動作の向上につながるかもしれないという点だ。一方でAmjadは、能力の高さがルールの抜け穴を突くために悪用される恐れもあると懸念している。同時に議論の中では、この分野の評価データの多くが非公開であるため、リスクがどのように変化するかを判断するための十分な証拠がまだ不足していることも指摘された。（34:13：能力と安全性をめぐる議論）
1. 賢くなれば、より信頼できるのか？
AI安全性の領域には、有名な直交性命題（Orthogonality Thesis）が存在する。システムの知能水準と、その究極的な道徳的・倫理的目的は互いに独立しているという命題だ。知能が高いことは、道徳性が高いことと同義ではない。
Amjadは、人間社会においては教育と共感力が相関することもあるが、強化学習（RL）に基づいて訓練された機械においては、正反対の事態を招きかねないとみている：
- Amjadは対談の中で研究を引用し、能力の向上がシステムの報酬ハッキング（Reward Hacking）や欺瞞行為の生成におけるモデルの能力をも高めてしまうのではないかと懸念を示した；
- 彼はまた、モデルが自身が評価されていることを認識した場合、テスト中の振る舞いが長期的なタスクにおける振る舞いを必ずしも代表しない恐れがある点も懸念している；
- 彼の見解では、思考の連鎖（Chain of Thought）、すなわちモデルが提示する推論プロセスを監視すること自体がモデルの振る舞いを変化させる可能性もあり、そのテキストのみを手がかりに信頼性を判断することはできない。
このような状況において、もし企業が中核となるセキュリティ防御や内部コンプライアンス審査といった死活問題を、巨大で複雑な非構造化ブラックボックスモデルに全面的に委ねようとするならば、一般的な能力スコアだけでなく、実際の挙動を評価する必要がある。登壇者らは、長期にわたるAgentタスクにはより長期的な観察が不可欠であると考えている。
この対談における「アラインメント」は、具体的には次のように理解できる：モデルがユーザーを欺かないか、テストされていることを知ったときに振る舞いを変えないか、そして長期的なタスクにおいて一貫して要件を遵守し続けられるか、ということだ。短時間のテストで良好に回答できたとしても、それだけでこれらの問いに答えることはできない。
小型モデルだからといって必然的により安全であるわけでもない。もし特定のフロンティアモデルが重要タスクにおいて明らかに信頼性が高いと証明されれば、企業はより高い対価を支払うことも厭わないだろう。登壇者らは、高リスクなセキュリティ業務において通常の10倍の価格を支払う意思があるかという仮説にまで踏み込んで議論した。要はエラーや欺瞞を低減することの価値にあり、単なる1回あたりの呼び出しコストだけの問題ではない。モデルのサイズ自体はこの問いに答えてはくれないのだ。
2. モデルが自らの「後継者」を訓練する：AI時代のJITコンパイラ
汎用モデルの制御不能リスクと高額なコストに直面するなか、対談では極めて示唆に富む技術進化の道筋が探られた。「大規模モデルに自らの専用代替モデルを訓練させる」というアプローチだ。
これは従来のソフトウェア工学におけるJITコンパイラ（JIT Compiler）と軌を一にしている： コードを書く際、開発者は通常、柔軟だが実行速度の遅い動的言語を使用する。プログラムが実行されると、基盤となるJITインタプリタはある論理が高頻度で繰り返し呼び出されていることを検知し、バックグラウンドで即座にそれを極めて効率的で専用の低級機械語へとコンパイルする。
これをAIに当てはめると、企業はまず汎用フロンティアモデルを用いてユースケースを探索できる。登壇者らが構想するのは、大規模モデル自身やプロンプトによる誘導、あるいはシステムの稼働を観察する別のAgentによって、どの作業が実際には限定的な能力しか必要としていないかを洗い出すことだ。そうしたタスクを特定したうえで、大規模モデルをメンターとして、その単一の作業のみを行う専用モデルを集中的に訓練またはファインチューニングする。（31:13：後継モデルを訓練する構想）
この比喩の肝は、単に「大規模モデルを小型モデルに置き換える」ことではなく、まずどこが置き換える価値があるかを見極め、そのうえでその工程の実行方式を選択するという点にある。後継モデルの自動検出と訓練はいまだ構想段階である。企業の実際のモデル選定においては、代替モデルを元のタスクに戻して再評価し、達成品質と総コストが適切であるかを確認する必要がある。
Amjadは、単純なタスクに対して過度に強力なモデルを投入する無駄を「蝶を撃つのに核爆弾を使うようなもの」と表現した。 タスクの範囲を絞り込めば、推論コストを削減できる可能性があり、不要な行動能力を制限することにもなる。だが、それでも誤判定を起こしたり攻撃を受けたりする可能性は残る。訓練する価値があるかどうかは、既存の低コストモデルでそのタスクを達成できるかどうかとの比較も必要である。
- 汎用モデルによる探索まずは未知で変化の多いタスクに対応する。
- 安定したタスクの特定繰り返し発生し、境界が明確な業務を洗い出す。
- 専用モデルの選定または訓練まずは既存の低コストモデルで十分かを確認する。
- 実タスクでの評価品質と総コストが見合えば、その工程を担当させる。
置き換えるのは特定タスクの実行方法であり、複雑な問題には引き続き汎用モデルを呼び出すことができる。
3. コスト区間の予測だけなら、なぜ万能モデルは不要なのか
登壇者は、企業がモデルのファインチューニングに対して持続的な負担、すなわち「モデルの技術的負債が重すぎる」という懸念を抱いていることに言及した。 フロンティア大規模モデルのアップデート速度は月単位、あるいは週単位で進行しているため、企業が非構造化テキスト向けに苦労してファインチューニングしたモデルであっても、すぐに再チューニングや再評価を迫られるプレッシャーに直面しかねない。
これに対して、専用分類器の「十分である」ことの基準ははるかに絞り込まれている：汎用モデルは言語やプログラミングといった幅広い能力を絶えず向上させる必要があるが、企業のコスト予測器にとっては、自社のタスク費用を正確に予測できるかどうかが主眼となる。汎用ベンチマークでより強力なモデルが登場したからといって、この予測器が即座に役立たなくなるわけではない。タスクとデータが依然として有効である限り、ランキングを追いかけるためだけに再訓練する必要はない。もっとも、業務に変化が生じた際には再評価とメンテナンスが求められる。
高度に構造化された出力を備えた「意思決定モデル」（Decision Models）へと仕立てることは、プログラムによる結果の利用や検査を容易にすることにもつながる：
- 出力範囲が明確：モデルは際限のない自然言語の長文を生成せず、ましてや実行権限を持つコードを直接出力することもない。離散的なラベル（列挙値）、特定の確率分布、あるいは構造化された分類のみを出力する；
- 実践事例：Amjadによれば、彼はユーザーのタスク入力に基づき、プログラミングタスクの完了にかかるコスト区間を予測するコスト評価器を訓練したという。たとえば、5〜10ドル、10〜20ドルといった区分を異なるカテゴリとして設定し、各カテゴリの確率を返す。彼は分類ラベルの対数確率（log probs）を用いてこの判断を実現したと述べている。出力形式が明確であるためプログラムによる読み取りは容易だが、予測が誤る可能性は依然として存在する；
- 更新目標がより集中：社内固有の独自データに基づいて訓練されたこの垂直型決定器は、本質的に極めてアジャイルな業務フィルターである。複雑なRustコードを書く能力も、世界中の希少な言語を網羅する必要もない。外部の大規模モデルが日進月歩で進化しようとも、この専用決定器は社内において当該タスクに継続して貢献でき、汎用ランキングに追従するためだけに頻繁に更新する必要はない。ただし、業務やデータが変化した場合にはメンテナンスが必要となる。
4. ソフトウェア工学に学ぶ：動的スクリプトの熱狂からRustによる見直しへ
Amjadはソフトウェア開発を比喩に用いた：かつて開発者たちはPython、Ruby、PHPといった動的スクリプト言語に熱中した。当時はわずか数行のコードでWebサイトを立ち上げられる開発速度に誰もが目を見張り、Stripeのような金融機関でさえ当初はRubyで構築され、FacebookもまたPHPから誕生した。
その後、より複雑なシステムにおいて開発者たちは実行効率やエラー検知を再び重視するようになり、型システムやJITコンパイルといった手法を通じてソフトウェアを改善し、安全性と性能を強調するRustなどの言語を採用するようになった。この比喩は開発の容易さと実行時の制約との間のトレードオフを語るものであり、動的言語が一様に取って代わられたことを意味するわけではない。
Amjadは、AIアプリケーションにおいても次第に効率と制御が再び重視されるようになるだろうと予測している。 自然言語はユースケースを迅速に探索できるが、本番システムでは費用の算出や行動範囲の制限が求められる。Amjadは、開発者がどの工程をよりシンプルなモデルで完遂できるかにますます着目するようになると考えている。
その思考とは、明確なルールはコードに委ね、確率的な判断は評価可能な出力範囲に限定するというものだ。訓練ツールの普及に伴い、将来的に企業が社内で独自の業務データをアップロードし、そのタスクのみを担う軽量な意思決定モデルを取得することが一般的になる可能性がある。これがプロダクトの方向性に関する彼の予測である。
異なるモデルで補完し合い、タスク全体のコストを抑える
実践のレベルにおいて、単一の汎用大規模モデルを盲信しないとすれば、企業や先進的な開発者は高品質と高いコストパフォーマンスを兼ね備えたシステムをいかに構築すべきだろうか？
彼らが議論した方向性は、モデル融合（Model Fusion）と協調ルーティングである。（45:12：複数モデルの組み合わせとコスト）
いくつかの組み合わせ方式は次のように理解できる：ダブルチェックは別のモデルで既存の結果を検証すること；ルーティングは現在のタスクに適したモデルを選択すること；段階的エスカレーションはまず低コストなモデルで試行し必要に応じてより強力なモデルを呼び出すこと；融合は複数のモデルの能力と結果を統合することである。
1. モデルファミリーをまたいだ協調レビュー
異なるモデルによる相互検証が本格的に導入された初期の事例として登壇者らが目にしたのは、ソフトウェア開発領域におけるコードレビュー（Code Review）の場面であった。エンジニアたちはすぐに気づいた：同じモデルが自ら書いたコードをそれ自身に再確認させても、元の盲点を繰り返す傾向がある；しかし、そのコードを異なるアーキテクチャや訓練データ背景を持つ別のモデルファミリーに渡してレビューさせれば、異なる観点からの検証が得られる可能性がある。ただし、それが有効かどうかは実際の結果をもって判断する必要がある。
この発想は、さらにディープリサーチや複雑な推論シナリオへと拡張された。先端的な各研究所が事前学習で投入したデータ資産、訓練および調整手法はそれぞれ異なる。複数のモデルの長所を混合・編成し、複合モデルマトリクスを構築することで、システムにより広範な解決アプローチを探索させることができる。
ここで削減され得るのは、各ステップでモデル呼び出しを減らすことではなく、タスク全体のコストである。たとえば、日常的なステップは低コストモデルで処理し、より高度な能力を要する部分だけを高価なモデルに委ねることで、最初から最後まで最強のモデルを呼び出し続けるよりも総コストを抑えられる可能性がある；ただし、追加されたダブルチェック、リトライ、重複入力が多すぎれば、かえって割高になることもある。すべての工程の費用と最終的な品質を総合して比較検討する必要がある。
登壇した2人は具体的な成果を2つ紹介した：Alexによれば、OpenRouterの融合ソリューションは当初ディープリサーチ向けに適用され、約半分のコストで高水準の品質を達成したという；また別の議論では、実行フレームワーク等と組み合わせることで、約4〜5割のコストでフロンティアモデルに近い性能を達成した事例が紹介された。これらは登壇者が紹介した具体的な実績であり、その比率をあらゆるマルチモデルタスクにそのまま当てはめることはできない。
2. キャッシュを考慮した設計とその限界
マルチモデル融合システム、モデルルーティングゲートウェイ（Router）、あるいは段階的エスカレーションモデル（Escalation Model：まず極めて安価な小型モデルで解決を試み、困難に直面した段階で高価なモデルへエスカレーションして呼び出す仕組み）を構築する際、最も重要な低レイヤーのエンジニアリング最適化の1つがプロンプトキャッシング（Prompt Caching）への配慮である。
組み合わせのプロセスにおいて過去の計算を再利用できれば、重複するコストを削減できる可能性がある；一方で、モデルの頻繁な切り替えや入力の重複は、コスト削減効果を相殺してしまう恐れがある。そのため登壇者らは、ルーティング、エスカレーション、融合システムを設計する際にはキャッシュを考慮する必要があると強調した。
モデルファミリーをまたいでキャッシュを再利用できるか否かについて、発言者は自身の記憶違いの可能性があるため要確認であると明言した。自前の組み合わせシステムを設計する際には、各ベンダーが実際にサポートしているキャッシュ方式を確認する必要がある。
平たく言えば、企業が覚えておくべきことは？
- 1つの「万能AI秘書」にあらゆることを丸投げできると期待しないこと。 コードの記述、顧客管理、銀行口座の処理には、それぞれ異なる能力と権限が求められる。コーディネーターにタスクを整理させ、それぞれの得意分野を持つ専用アシスタントに委ねる構成にし、問題が生じた部分のみを個別に対処・検査できるようにするとよい。ソーシャルメディアへの投稿を担当するアシスタントに銀行口座のクレデンシャルを渡す必要はなく、重要な結果の検証責任は依然として人間が負う必要がある。
- 選択権と判断力を自らの手元に保持すること。 企業は必ずしも自前でモデルを訓練する必要はないが、独自のデータ、タスクサンプル、評価基準を保持し、異なるモデルが実務においてどのようなパフォーマンスを発揮するかを把握しておく必要がある。そうすればベンダーを切り替える際の確かな根拠が得られ、プロダクト全体を特定の単一APIに縛り付けずに済む。
- 明確に答えられるタスクは、出力をシンプルに保つこと。 たとえばコスト区間の予測であれば、求められているのはいくつかの区間とその確率であり、長文のテキストではない。まずは汎用モデルで探索を行い、その後に安価な既存モデルや自社で訓練した意思決定モデルに反復作業を引き継がせることを検討するとよい。形式が整っていることはプログラムによる読み取りを容易にするにすぎず、判断が正しいか、タスク全体でコストを削減できているかは、実際の業務結果で検証しなければならない。