「どのモデルを選ぶか」が消える日｜実行時オーケストレーションが崩す、AIコストと説明責任の前提

「どのモデルを選ぶか」が消える日｜実行時オーケストレーションが崩す、AIコストと説明責任の前提

従業員数十〜数百名の会社でAI活用が部署ごとに広がっていくと、多くの経営者・情シス担当が同じ壁にぶつかります。今月の請求額が先月と違う理由を、誰も即答できない。「どの部署が、どのモデルを、なぜ使ったのか」という台帳がないまま、月末の請求書だけが積み上がっていく状態です。

この記事で扱うのは、その壁が今後さらに厚くなる可能性がある、という話です。2026年9月4日、GitHubはProject HydraFusionというリサーチプレビューを発表しました。ここで起きている変化は「どのモデルを使うか」という意思決定そのものが、人間の手から離れていくというものです。この記事では、この変化が予算管理と説明責任の前提をどう変えるのかを、発表内容に基づいて整理します。

30秒で要点

• GitHubは2026年9月4日、モデルを実行時に自動選択する「Project HydraFusion」をリサーチプレビューとして発表した。利用者は「HydraFusion」という1つの選択肢を選ぶだけで、内部では複数プロバイダのモデルが実行時に選ばれる
• 課金は「実際に使われたモデルのトークン消費量に応じ、各モデルの標準単価で」行われる。これまでの「導入前にモデルを選び予算化する」という前提が、「実行後に何が使われたかを集計する」前提に置き換わる
• ベンチマーク結果は一様ではない。コスト削減幅は3指標とも改善（36〜67%減）だが、品質は+4.9ポイントの改善もあれば-1.5ポイントの悪化もあり、符号が指標ごとに異なる
• 同時期に発表された別の研究EarlyEval（2026年9月2日投稿）も、評価の打ち切りタイミングという別の判断を実行時のアルゴリズムに委ねる仕組みを示しており、「事前に人間が決めていた基準を実行時の判断に渡す」という流れが複数の場所で同時に起きている

なぜ「モデルを選ぶ」がコスト管理の起点だったのか

これまでAI活用のコスト管理は、多くの場合「どのモデルを使うか」を導入前に決めるところから始まっていました。GPT系を使うのかClaude系を使うのか、高性能だが高単価のモデルを使うのか、安価なモデルで様子を見るのか。この選択を情シスや現場責任者が事前に行い、その選択に基づいて月額の見込みを立てる。これが、これまでの予算管理の骨格でした。

この骨格が機能していたのは、「モデルの選択」という1つの意思決定ポイントに、選んだ人・選んだ理由・想定コストのすべてが紐づいていたからです。請求額が想定と違えば、「誰が何を選んだか」を確認すれば原因を追える構造でした。

HydraFusionが変えているのは「選択」という行為そのもの

GitHubの発表文は、Project HydraFusionの仕組みをこう説明しています。利用者はモデル一覧から個別のモデルを選ぶのではなく、「HydraFusion」という1つの選択肢を選ぶだけでよい（"you select HydraFusion like any other model"）。実際にどのモデルが使われるかは、タスクの内容に応じて実行時に内部で決まります。提供形態はGitHub Copilot CLIの/experimental経由で、全プランの利用者が利用できます。

このとき課金は「HydraFusionが使用したモデルのトークン消費量に応じ、各モデルの標準単価で」行われるとGitHubは明記しています。つまり、請求額の内訳は実行が終わったあとにしか確定しません。これまでの「事前に選んで予算化する」という前提が、「実行後に何が使われたかを集計する」という前提に置き換わっているのです。

GitHubはこの変化を裏づけるように、5つの運用原則を掲げています。中でも重要なのが「Complete accounting」と呼ばれる原則で、下書き・批評・修正・エスカレーション・リトライ・フォールバックを含む全ワークフロー区間のコストと利用量を集計するというものです。発表文はこう述べています。「Internally, the runtime records the role, outcome, cost, latency, and diagnostics of each leg so the workflow can be understood after execution.(ランタイムは各区間の役割・結果・コスト・レイテンシ・診断情報を内部で記録し、ワークフローが実行後に理解できるようにする)」。ここで明言されている「after execution(実行後に)」という言葉が、この仕組みの性格を端的に表しています。

HydraFusionの内部には3つの実行パターンがあります。Singleは1つの選ばれたモデルがタスクを直接解く構成。Cascadeは効率的なモデルがまず下書きを作り、品質ゲートがそれを受理するか、より強いモデルにエスカレーションするかを判断する構成。Critiqueは1つのモデルが下書きを作り、別系統の独立した読み取り専用モデルがレビューし、元のモデルが一度だけ修正する構成です。いずれの場合も、どのパターンが選ばれ、どのモデルが関与したかは、タスクごとに変わり得ます。

ベンチマークが示す「品質同等でコスト減」ではない現実

GitHubは、Claude Opus 5とGPT-5.6 Solを比較基準とし、全モデルを同一のmedium reasoning levelで評価したベンチマーク結果を公表しています。TerminalBench 2.1ではコスト67%減・品質+4.9ポイント。DeepSWEではコスト36%減・品質-1.5ポイント。GitHub内部ベンチマークのCheckpointBenchではコスト65%減・品質-0.1ポイントでした。

3つともコストは大きく下がっていますが、品質の符号は一致していません。1つは改善し、2つは悪化しています。GitHub自身もこの点を留保しており、「These controlled offline results are specific to the evaluated benchmark revisions, workflow configurations, model pool, and pricing assumptions(この管理下でのオフライン結果は、評価したベンチマーク版・ワークフロー構成・モデルプール・価格前提に固有のものである)」と明記しています。TerminalBench 2.1については「その相対的な飽和により、より広範な検証が重要になる」とも述べており、+4.9ポイントという改善幅そのものにも慎重な読み方を求めています。

ここから言えるのは、「HydraFusionを使えば品質を保ったままコストが下がる」という単純な要約は、GitHub自身が置いている留保を薄めてしまうということです。正確には「コストは3指標とも下がったが、品質は指標によって上がりも下がりもした」という、符号が揃わない結果です。

なぜ「品質同等でコスト減」と誤解しやすいのか

このベンチマークを見たとき、多くの読み手は「コストが下がった」という分かりやすい数字にまず反応します。コスト削減率は3指標とも二桁パーセントで揃っており、視覚的にもインパクトが強い数字です。一方、品質の変化は+4.9・-1.5・-0.1という小さな数値で、しかも符号がばらついているため、「誤差の範囲」として読み飛ばされやすい構造になっています。

さらに、発表そのものが「frontier quality via multi-model orchestration(マルチモデル・オーケストレーションによるフロンティア品質)」という見出しを掲げているため、読み手は「品質は保たれる前提の発表だ」という印象を先に受け取ります。見出しの印象と、表の中にある符号がばらついた実数値との間にギャップがあり、忙しく読むほど見出しの印象の方が記憶に残ります。これが「品質同等でコスト減」という単純化が起きやすい理由です。

同時期に起きているもう一つの「委譲」——EarlyEval

同じ時期、別の角度から似た変化を示す研究が発表されています。2026年9月2日にarXivへ投稿された論文EarlyEval（著者Yuling Shi, Zhensu Sun, Junsen Dong, Chengcheng Wan, David Lo, Xiaodong Gu）は、SWE-bench Verified・TerminalBench・Toolathlonという3つのベンチマークで、エージェント評価のステップ数を13%〜26%、入力トークンを最大44.1%、出力トークンを29.4%削減する手法を示しました。予測精度は89%〜97%とされています。一方で、per-agentの解決率（個々のエージェントが正解にたどり着いた比率）は平均1〜2パーセントポイント変動するとされています。詳細はarXiv（arxiv.org/abs/2609.02783）で公開されています。

HydraFusionが「どのモデルを使うか」を実行時の判断に委ねているのに対し、EarlyEvalは「評価をどこまで続けるか」を実行時の判断に委ねています。対象は異なりますが、どちらも「人間が事前に決めていた基準」を「実行時のアルゴリズムの判断」に置き換える方向で一致しています。1つの発表だけを見ていると個別の製品ニュースに見えますが、同じ週に近い性格の変化が複数の場所で起きていること自体が、この流れが一時的な流行ではない可能性を示しています。

確かなことと、まだ確かではないこと

確かなこと: GitHubが2026年9月4日にProject HydraFusionをリサーチプレビューとして発表したこと。仕組みが実行時にモデルを選択し、課金が使用モデルのトークン消費量に応じて事後的に決まること。5つの運用原則の中に「実行後の完全な集計」を掲げる項目が含まれていること。公表されたベンチマークでコストは3指標とも改善した一方、品質の符号は指標ごとに異なること。EarlyEval論文が2026年9月2日にarXivへ投稿され、評価の早期打ち切りによるステップ・トークン削減を示していること。

まだ確かではないこと: HydraFusionはリサーチプレビュー段階であり、GitHub自身が「結果・モデル・ワークフロー・提供可否・名称・製品挙動はプレビューからの学習に応じて変わりうる」と明記しています。今回のベンチマーク結果が、自社の実際のワークロードでも同様の傾向を示すかどうかは分かりません。EarlyEvalのコード・データが公開されているとされるリポジトリの中身は、この記事の執筆時点で確認していません。

「コストの説明責任」という指標をどう定義し直すか

これまでのコスト管理は、「どのモデルを、いくらの単価で、何件使ったか」という比較的シンプルな指標で説明責任を果たせていました。分母は利用件数、分子は請求額、単位は「モデルごとの月額」です。

実行時オーケストレーションのもとでは、この指標の立て方自体を見直す必要があります。GitHubが「Complete accounting」原則で示しているように、追うべき単位は「モデル」ではなく「ワークフローの区間(leg)」に変わります。1つのタスクの中で、下書き・批評・修正・エスカレーション・リトライ・フォールバックのそれぞれにどれだけのコストがかかったかを記録できて初めて、「なぜこのタスクにこのコストがかかったのか」を事後的に説明できます。分母を「タスク件数」、分子を「タスクごとの総コスト（全区間の合計）」、単位を「完了したタスク1件あたりのコスト」に置き直すことが、実行時オーケストレーションに対応した説明責任の指標になります。

判断軸の提示

実行時オーケストレーションを検討・導入する際は、「導入前にどのモデルを選ぶか」ではなく「実行後にコストと結果をどう記録し説明するか」を先に設計すること。モデル選択という意思決定ポイントが実行時の内部処理に移る以上、これまで「選定理由」で果たしていた説明責任は、「実行ログの記録」でしか果たせなくなります。ベンチマークの見出しにある「品質を保ったままコスト削減」という印象だけで導入を判断せず、GitHub自身が示す3つの数値の符号のばらつきを確認したうえで、自社のワークフローで検証する期間を設けることが、この移行を安全に進める条件になります。

自分でも試せる、最小の検証

自社が現在使っているAI関連ツールのうち1つを選び、「先月の請求額のうち、どの機能・どの部署の利用が何割を占めるか」をその場で説明できるかを確認してみてください。即答できない場合、それは実行時オーケストレーションが広がる前から既に「事後の記録」の仕組みが不足している状態です。オーケストレーション機能を試す前に、まずこの記録の仕組みを整えることが、順序として先に来ます。

この記事で扱ったような判断を、自社の状況に照らして整理したい場合は、無料診断ツールで状況を言語化するところから始めることができます。