Copilot Fusionのモデル振り分けと費用　基準値から日本での試し方まで

高性能モデルを常用すれば、難しい修正には対応しやすいが、単純な作業にも同じ費用がかかる。GitHub Copilot Fusionは、仕事ごとにモデルと実行手順を振り分け、必要な場合は別のモデルに検査や修正を引き継ぐ仕組みだ。

GitHubの公式発表は、Copilot Fusionをモデルの選択と協調を自動化する機能として説明している。Artificial Analysisの基準値は費用差を示すが、実際の請求額やチームの生産性は、仕事の種類とレビュー手順を含めて測る必要がある。

基準値の差は、チームの見積もりではない

約半分のAPI費用でも、そのまま導入効果とは言えない。Artificial AnalysisのCoding Agent Index v2.0では、Copilot Fusion Maxの総合スコアが60、Claude CodeのClaude Opus 5.5 Maxが62だった。同じ比較で、平均API費用はFusionが約5.59ドル、Claude Codeが約11.42ドルだった。

Artificial Analysisの比較ページは、Coding Agent Index、タスクごとの費用、実行時間を代理ツール単位で掲載している。比較対象はモデル単体ではなく、モデル、ツール、実行手順を含む代理環境である。

評価項目	Copilot Fusion Max	Claude Code Opus 5.5 Max
FrontierCode v1.1	51%	56%
Terminal-Bench 4.0	71%	63%
SWE-Atlas-QnA-AA	57%	66%
総合スコア	60	62
平均API費用	約5.59ドル	約11.42ドル

分野ごとの結果も同じではない。FusionはTerminal-Bench 4.0で71%、Claude Codeは63%だった一方、FrontierCode v1.1ではFusionが51%、Claude Codeが56%だった。総合点より、自社の仕事がコマンド操作、複数ファイルの修正、規準に沿った回答のどれに近いかを先に分ける必要がある。

Copilot Fusionはモデルをどう引き継ぐか

Fusionは、AIモデルを一つに固定する製品ではない。GitHub Docsは、Copilot Fusionを仕事ごとにモデルと実行パターンを自動選択する機能と説明し、Single、Cascade、Critiqueの努力レベルを案内している。

Singleは一つのモデルで処理する。Cascadeは効率のよいモデルが案を出し、別の判断モデルが受け入れや上位モデルへの切り替えを判定する。Critiqueは一つのモデルが起草し、複数モデルが独立に検査した後、元のモデルが修正する。HighやMaxでは呼び出し回数が増え、処理時間とAI creditsの消費も増えうる。

多くのモデルを通せば仕様の抜けが自動で埋まるわけではない。変更範囲、互換性、完了条件、テスト結果が引き継がれなければ、後段のモデルも誤った前提を受け取る。引き継ぎの評価では、最終回答の流暢さより、変更ファイル、失敗したテスト、未確認の仮定が残っているかを確認する。

課金はAPI費用とチームの実費を分けて見る

基準テストの費用は、月次請求書ではない。Artificial Analysisの数字はタスクごとのAPI費用で、契約料金、待ち時間、コードレビュー、人工修正、再実行を含む総コストではない。

GitHubの発表では、Fusionに別料金を設けず、実際に利用したモデルの標準料金を基に課金すると説明している。一つの仕事で複数モデルを使うHighやMaxは、StandardよりAI creditsを多く消費しうる。なお、公式Docsの料金欄や契約画面に表示されるモデル政策、割引、上限は更新されるため、試算時点で確認する必要がある。

企業事例も基準値とは分けて扱う。GitHubとAccentureの研究はCopilot利用企業の開発指標を扱うが、Fusionの効果を測った研究ではない。MicrosoftのKOHLER事例も、同社の教育や推進体制を含む顧客事例であり、別の企業やFusionの予測値にはならない。

引き継ぎで確認する五つの項目

モデル間の引き継ぎで問題になるのは、処理が終わったかではなく、次のモデルが同じ仕事を再現できるかである。特に、草稿を破棄した場合でも作業ツリーに変更が残る可能性があるため、画面の完了表示だけでマージを判断しない。

1. 目的。何を変更し、何を変更しないかを固定する。
2. 差分。変更ファイル、公開API、設定ファイルをバージョン管理で照合する。
3. 仮定。採用した仕様、互換性の前提、未確認事項を記録する。
4. テスト。実行したコマンド、成功と失敗、再現条件を残す。
5. 責任者。最終的に受け入れる人と、差し戻しの条件を決める。

日本ではどうなる

日本で利用できるか、いくらかかるかを判断するには、まずGitHubの日本向け契約画面と管理者向け設定を確認する。Copilot Fusionの公式Docsは全Copilotプランでの提供を案内しているが、組織契約のプラン、モデルの利用可否、AI creditsの上限、適用中の割引は契約条件で確認すべき項目だ。円建ての月額や国内代理店の料金を示す公式資料は、本稿の執筆時点で確認できていない。

法令面では、コードだけを扱う検証と、顧客情報や社内の個人情報をプロンプトに含める運用を分ける必要がある。個人情報保護委員会の法令・ガイドライン等のページを起点に、利用目的、委託先、国外のサービスへの提供、保存期間、削除方法を確認する。GitHubの機能を使うことだけで日本の特別な認証が必要になると断定できる資料は確認できていないため、実際のデータフローと契約条項を照合するのが先になる。

国内企業や行政がCopilot Fusionを本番運用したと裏付ける公的な事例は、本稿の執筆時点で確認できていない。導入前は、機密情報を含まない代表タスクを用い、Standard、High、Maxを分けて、費用、待ち時間、テスト通過率、人工修正、差し戻しを記録する。GitHubの公式発表、Docs、管理者設定、契約画面を同じ日に確認し、価格やモデル政策を固定値として扱わないことが日本での検証の出発点になる。

小規模試用で比較する

同じタスクを同じ基準で測ってから、適用範囲を決める。日常の小修正、難しいデバッグ、複数ファイルの変更を一つずつ選び、リポジトリの版、プロンプト、完成条件を固定する。既存の単一モデルや代理ツールでも同じ仕事を行い、成功例だけで平均を作らない。

記録するのはモデル費用だけではない。実行時間、AI credits、レビューにかかった分数、追加修正、再実行、テストとコードレビューの結果を一つの表に置く。費用が下がっても修正とレビューが増えれば、チーム全体の負担は下がらない。逆に、処理の種類ごとに差分とテストが安定するなら、その仕事だけFusionへ広げる判断が可能になる。

モデルの構成や料金は変わるため、試用日、契約プラン、努力レベル、利用モデルを記録する。比較の目的は「Fusionが常に安い」と証明することではなく、どの仕事なら振り分けと引き継ぎが人の確認を減らし、どの仕事なら固定モデルや手動分解のほうが安全かを決めることにある。

よくある質問

Copilot Fusionは新しいAIモデルか
違う。複数のモデルと実行手順を仕事に応じて選ぶ、ルーティングと協調の仕組みである。

毎回複数モデルを使うのか
違う。Singleは一つのモデルで処理し、CascadeやCritiqueでは検査、切り替え、修正の段階が加わる。

Fusionなら必ず安くなるか
判断できない。基準テストでは平均API費用に差があるが、実際の費用は仕事、モデル、努力レベル、利用量、契約条件、レビューの負担で変わる。

導入時に最初に見る項目は何か
管理者が許可したモデルとプラン、AI creditsの扱い、作業ツリーの差分、テスト結果、最終承認者を確認し、代表タスクで既存手順と比較する。