「最強モデルを1つ」の時代は終わるのか。GitHubのHydraFusionがAIを寄ってたかって働かせる

まず初めに

IT Postでは、この発表を「AI業界がついに、1人の天才に全部やらせるのは無理だと認めた日」として眺めている。

この2年、業界の会話はずっと同じだった。どのモデルが一番賢いか。どっちのベンチマークが高いか。まるでクラスの席次表を毎週貼り替えているようなものだ。ところが現場の仕事は、テストの点数ではない。誰が下書きをして、誰が粗を探して、誰が直すか。会社と同じだ。そこにようやく気づいた会社が、モデルを1人の天才ではなく、チームとして扱い始めた。遅い。しかし、やっと来た。

※個人の感想です

何が公開されたのか。「実行時オーケストレーション」の意味

GitHubの公式ブログによると、Project HydraFusionは「実行時のオーケストレーションによってフロンティア級の知性を届ける研究プレビュー」と位置づけられています。

オーケストレーションは、複数の部品を指揮者しきしゃのように取りまとめる、という意味の言葉です。ここでは、1つの依頼に対してどのモデルをどの順番で使うかという計画を、実行のたびにその場で組み立てることを指します。

従来のAIコーディング支援では、利用者が事前にモデルを1つ選び、そのモデルが最後まで担当していました。HydraFusionは、その選択をワークフローの最適化問題として扱い、依頼ごとに構成を決めます。人間の上司なら、これを「適材適所」と呼んで自分の手柄にするところだ。

3つの型。Single、Cascade、Critique

GitHubが挙げている実行パターンは3つです。

型	動き	向いている場面
Single	1つのモデルが直接そのまま解く	単純で迷いの少ない依頼
Cascade	効率重視のモデルがまず下書きし、品質の関門かんもんで必要と判断されれば、より強いモデルへ引き継ぐ	簡単な依頼と難しい依頼が混ざる場面
Critique	1つのモデルが下書きし、別系統けいとうの独立した批評役が読み、下書き役が1回だけ直す	見落としを減らしたい重要な変更

注目したいのはCritiqueです。批評役は「読むだけ」の役割で、しかも下書きをしたモデルとは別の系統から選ばれます。同じ会社の同じ系統のモデルは、似た考え方をするため、似た見落としをします。人間の会議で、同じ部署の人間だけを集めても新しい指摘が出てこないのと同じ理屈です。

ベンチマークの数字は「安くなった」が主役

GitHubは、Claude Opus 5を基準にした比較を公開しています。測定したのは、検証済みのタスク品質（正しく完了できた割合）と、すべてのモデル呼び出しを含めたワークフロー全体の推定コストです。

ベンチマーク	コスト	品質
TerminalBench 2.1	67%低い	4.9ポイント高い
DeepSWE	36%低い	1.5ポイント低い
CheckpointBench	65%低い	0.1ポイント低い

読み方には注意が必要です。コストは3本すべてで下がりました。品質は1本で上回り、2本ではわずかに下回っています。したがって「HydraFusionはOpus 5より賢い」とは言えませんし、逆に「品質を犠牲にした安物」とも言えません。同等に近い品質を、明らかに安く出した、という読み方が公開データに最も忠実です。

なお、これはGitHubが自社で測定して公表した数字です。第三者による追試ついしの結果ではありません。IT Postでは、9月に相次いだモデル発表でも、同じモデルが測り方によって大きく違う点数を出した例を確認しています。看板の数字は、測り方とセットで読む必要があります。

日本の読者にとって何が変わるのか

まず、いますぐ全員に影響する話ではありません。入り口はCopilot CLIという開発者向けの道具で、しかも研究プレビューです。仕事で毎日コードを書く人以外は、当面は「そういう方向へ進んでいる」と知っておけば十分です。

そのうえで、方向性としては3つの意味があります。

1つ目は、料金の考え方が変わることです。これまでは「高いモデルを使うか、安いモデルで我慢するか」の二択でした。役割ごとに振り分けられるなら、高いモデルを使う場面を必要な瞬間だけに絞れます。

2つ目は、特定の1社への依存が薄まる可能性です。複数の企業のモデルを横断して選ぶ設計であれば、1社の供給方針が変わっても、道具全体が止まりにくくなります。IT Postでは、AI開発ツールへのモデル供給が企業間の事情で揺れた事例を別記事で扱っています。

3つ目は、私たちが日常で触れるAIアプリにも、いずれ同じ考え方が下りてくることです。1つの質問の裏で複数のAIが分担する構造は、利用者からは見えません。見えないからこそ、「どのAIが答えたのか」を利用者が知る手段が今後の論点になります。

用語の整理

言葉	意味
研究プレビュー	正式な製品ではなく、試験的に公開して反応を見る段階
ワークフロー	仕事の進め方の型。ここでは、どのモデルが何をどの順で担当するかの計画
ベンチマーク	性能を測るための共通の試験問題。試験が違えば順位も変わる
AIエージェント	指示を受けて、道具を使いながら自分で手順を進めるAI
トークン	AIが文章を扱う際の単位。料金の計算に使われることが多い

よくある疑問

追加の料金はかかるのか。 GitHubは、全プランの利用者が使えると案内しています。CLIで /update を実行し、/experimental on を有効にしたうえで /model から選ぶ流れです。研究プレビューのため、条件が今後変わる可能性はあります。

VS Codeでは使えないのか。 公開時点の入り口はCopilot CLIです。CopilotアプリとVS Codeについては、9月中の追随を目標としているとしています。目標であり、確定した提供日ではありません。

批評役がいれば間違いは無くなるのか。 なりません。別系統のモデルが読むことで見落としが減る可能性はありますが、どちらのモデルも間違えることはあります。生成されたコードを人が確認する必要は変わりません。

どのモデルが使われているのか。 GitHubは複数プロバイダーのモデルから選ぶと説明していますが、公式ブログでは基準としてClaude Opus 5とGPT-5.6 Solの名前が挙がっているにとどまります。組み合わせの内訳がすべて公開されているわけではありません。

IT Postの見方——1位争いより、こっちの方がよほど実務的だ

IT Postでは、この研究プレビューを、ここ数か月のAI業界で一番地に足のついた発表だと評価する。

理由ははっきりしている。過去2年、各社が競ってきたのは「誰が一番か」だった。だが仕事を頼む側が本当に知りたいのは、誰が一番かではない。この作業をいくらで、どれくらい確実に終わらせられるか、それだけだ。1位のモデルに全部やらせるのは、社内の全業務を一番給料の高い社員1人にやらせるようなものだ。壮観だが、経理が卒倒する。

今回の数字も、そこを突いている。コストが3本すべてで下がり、品質は横並び。派手さは無い。見出しにもなりにくい。だが実務で効くのはこういう変化だ。速報の花火より、請求書の桁が1つ減るほうが、現場は喜ぶ。

批評役を別系統から連れてくる設計も好ましい。自分の答えを自分で見直させても、たいてい「問題ありません」と返ってくる。人間でもそうだ。だから他人に読ませる。当たり前のことを、当たり前にやっている。

一方で、浮かれるのは早い。これはGitHub自身が測った数字であり、しかも研究プレビューだ。ベンチマークが3本というのも、判断材料としては心もとない。同じモデルが測り方ひとつで点数を乱高下させる場面を、私たちはこの1か月で何度も見てきた。第三者の追試が出るまでは、「安くなりそうだ」以上には踏み込まない。

そしてもう1つ。複数社のモデルを束ねる仕組みは、裏返せば、複数社の都合に同時にさらされるということでもある。どこか1社が供給方針を変えれば、束ねている側が組み替えを迫られる。分散は依存を減らすが、ゼロにはしない。そこを「もう1社に縛られない」と言い切るのは、少々気が早い。

IT Postでは、モデル単体の順位表より、こうした組み合わせ方の工夫のほうが、これからの1年で効いてくると考える。天才を1人雇う話は、そろそろ飽きた。