Single単独
選ばれたモデル→回答・変更案
1つのモデルが直接解く。
VS Code / App
使える画面が拡大CLI先行から研究プレビューを展開
3 workflows
モデルと手順を選択Single / Cascade / Critique
1.140+
VS Codeの入口対象プラン・組織の許可を確認
各モデル料金
総使用量で確認Autoの割引と分ける
研究の評価
条件と結果をセットで読む社内測定・実請求の保証ではない
01
THE NEW SURFACES
新しいのはモデル名ではなく、使える画面
公式発表｜9/30深夜の展開拡大を10/1号で解説
GitHubは、CLIで先行していたHydraFusionの研究プレビューをVS CodeとGitHub Copilotアプリへ拡大した。モデル選択欄に並ぶが、単一の新モデルではない。
- 研究の初出
複数モデルを組み合わせる実行方式と、社内オフライン評価を公開。
- 利用画面の拡大を告知
VS Code・Copilotアプリでも選択可能に。日時は公式ページの公開メタ情報をJSTに換算。
- 告知ページの更新
ページ更新の時刻。全利用者への反映完了時刻を示すものではない。
出典：GitHub：VS Code・Copilotアプリへの展開 ／ GitHub：Project HydraFusionの研究・評価
本号は10/1 JSTを対象にしたニュース解説。一次情報の照合・制作は10/2 JST。9/30号のDevDay発表とは別の続報であり、「10/1に新モデルを発表」とは扱わない。
02
THREE WAYS TO SOLVE
単独で解く。必要なら上げる。別の視点で見直す
公式の処理方式｜図は本号による概念整理
依頼に応じて、次の3方式から選ぶ。毎回、複数モデルを呼ぶとは限らない。図中の「作成」「評価」は役割を示し、特定のモデル名を固定していない。
Cascade段階的に引き上げ
効率重視のモデル→品質を評価→採用 / 強いモデルへ
最初の案が基準を満たすかで、次の呼び出しを決める。
Critique独立レビュー
作成モデルの案→別系列が読取レビュー→作成側が1回修正
レビュー担当が直接編集する流れではない。
出典：GitHub：VS Code・Copilotアプリへの展開
本号の読み方
「何モデル使ったか」より「どこで、何を確かめたか」
同じ不具合でも、最初の案だけで直る場合と、別の見方で見落としが分かる場合がある。方式の名前から合格を決めず、変更した箇所と検証結果を対応させる。
03
MODEL OR WORKFLOW
固定・Auto・HydraFusion。何を任せるかが違う
仕様の比較＋本号の使い分け提案
Autoは、依頼の難度やモデルの稼働状況などを考慮してモデルを選ぶ。HydraFusionは、さらに1つのターンの中で、どの処理方式で進めるかを選ぶ。
| 選び方 | 任せる選択 | 本号が提案する比較の目的 |
|---|---|---|
| モデルを固定 | 指定したモデルで実行 | 今の環境の基準値を残す |
| Auto | 依頼に合うモデルを選択 | モデル選びの手間を減らせるか確認 |
| HydraFusion | モデルとSingle / Cascade / Critiqueを選択 | レビューや引き上げを含めた総結果を比較 |
出典：GitHub：VS Code・Copilotアプリへの展開 ／ GitHub Docs：Auto model selection
使い分けは本号の提案。固定モデル・Auto・HydraFusionのどれが常に上かという順位ではない。同じ開始状態・依頼文・合格条件で比較すると、選択方式の差を判断しやすい。
04
CHECK YOUR ENTRY POINT
まず対象プランと設定を確認する
提供条件｜9/30告知の対象を採用
今回のVS Code・Copilotアプリの告知では、対象としてCopilot Pro / Pro+ / Business / Enterpriseを列挙。Business・Enterpriseは管理者によるプレビュー機能の許可が必要。
VS Code
- 1.140以上、またはInsidersを使う。
- Copilot Chatのモデル選択欄でHydraFusionを探す。
- 表示されない場合は
chat.copilot.hydraFusion.enabledを有効化する。
GitHub Copilotアプリ
- 最新版へ更新する。
- SettingsでHydraFusionを検索して有効化。
- モデル選択欄から選ぶ。
出典：GitHub：VS Code・Copilotアプリへの展開 ／ VS Code：1.140リリースノート
見つからないときの確認順序（本号の提案）
- アプリ版とサインイン先を記録する。
- 対象プラン・設定・組織の許可を順に確認する。
- 条件が揃っても表示されなければ、画面と時刻を添えて管理者やサポートへ確認する。
研究プレビューは提供条件・動作が変わり得る。9/4のCLI研究記事にある「全プラン」を、今回の2画面の対象へ読み替えない。告知に列挙のないプランの可否は、この号では断定しない。
05
COUNT THE WHOLE WORKFLOW
費用は、呼んだモデルのトークンを合計する
公式の費用の仕組み＋本号の記録案
研究記事は、HydraFusionが実際に使うモデルのトークンを、各モデルの標準料金で計算すると説明する。安いモデルから始めても、レビュー・修正・引き上げが入れば呼び出しが増える。
費用を見る単位
作成 ＋ レビュー ＋ 修正 ＋ 必要な引き上げ → 仕事1件の総使用量
これは本号の概念図。各工程が常に発生するという式ではない。実際の料金は、使われたモデル、入力・出力、キャッシュ等の適用条件で確認する。
出典：GitHub：Project HydraFusionの研究・評価 ／ GitHub Docs：モデルごとの料金
| 残すもの | 確認する理由 |
|---|---|
| 使用量・請求の前後差 | 画面上の実際の消費を確認する |
| 経過時間と、人が直した時間 | 安くても手直しが多い仕事を見分ける |
| 合格した条件 / 残った問題 | 未完成の安い案を成功と数えない |
06
ROUTING IS NOT A DISCOUNT
自動で選ぶことと、割引があることを分ける
公式料金の条件｜Autoの説明をHydraFusionへ転用しない
Auto：有料プランでは10%割引
公式Docsは、有料CopilotプランのAuto model selectionについて、モデル費用の10%割引を説明する。
HydraFusion：Autoの割引は適用されない
10/2に照合したHydraFusionの公式Docsは、各モデルの標準料金を使い、Auto model selectionの割引は適用しないと明記する。
出典：GitHub Docs：Auto model selection ／ GitHub Docs：HydraFusionの使い方と課金 ／ GitHub Docs：モデルごとの料金
本号の比較方法
請求の差を見たら、まず「どの方式で、どのモデルが、何回呼ばれたか」を残す。割引の条件と、呼び出し自体を減らす効果を別々に確認する。単価だけを比べて、仕事全体が安く済んだと判断しない。
料金Docsは現行資料を10/2に照合した補助情報。10/1に料金改定があったというニュースではなく、試す前に確認する条件として掲載する。
07
READ THE CONDITIONS
「67%低い」は研究の推定費用。実請求の保証ではない
GitHub自身の社内オフライン評価｜独立測定ではない
9/4の研究記事は、全モデルmedium設定・調整済みのHydraFusion構成を評価した。以下はOpus 5を基準とする、仕事全体の推定費用と、正しく完了したタスク割合の差。
| ベンチマーク | 推定費用の差 | 品質の差 |
|---|---|---|
| TerminalBench 2.1 | 67%低い | ＋4.9ポイント |
| DeepSWE | 36%低い | −1.5ポイント |
| CheckpointBench（社内評価） | 65%低い | −0.1ポイント |
出典：GitHub：Project HydraFusionの研究・評価
3つすべてで品質が上がったわけではない。モデル群・実行方式・料金仮定・採点条件を揃えた特定の評価結果であり、製品の全タスクや自分の請求額への保証ではない。
数字を実仕事へ使う前の3つの問い（本号の提案）
- 品質：自分の合格条件には、回帰や見た目の確認も入っているか。
- 費用：やり直し・レビュー・人の修正まで合計しているか。
- 再現：アプリ版、開始コミット、依頼文、実行日時を残せるか。
ベンチマークは試す理由になる。採用は、自分の仕事の結果を見て判断する。
08
REVIEW HAS A BOUNDARY
別系列のレビューでも、差分とテストは人が確かめる
研究の説明＋本号の受入確認案｜製品を独自実測した結果ではない
Critiqueは、別のモデル系列から読み取り専用の視点を入れる。研究記事では、レビューは隔離したツールなしの文脈で実行すると説明する。
通常のRubber Duckとは、同じ実装とみなさない
Copilot CLIのRubber Duckの公式説明には、読み取り用の探索ツールを使うレビューがある。HydraFusionは同じレビューの考え方を参照するが、研究記事の隔離・ツールなしという条件と混ぜない。
出典：GitHub：Project HydraFusionの研究・評価 ／ GitHub Docs：Rubber Duck
出典：GitHub：Project HydraFusionの研究・評価
本号の受入確認
REQUIREMENT元の合格条件→DIFF変更した実物→TEST結果と未確認→ACCEPT人が採用判断
「レビュー済み」という説明だけで受け入れない。例えば表示の不具合なら実画面、計算の不具合なら入力と期待値、リンクなら遷移先まで確かめる。共有された前提の誤りは、別モデルでも見逃し得る。
09
COMPARE ONE REAL JOB
合否を決められる不具合を、同じ条件で比べる
本号の実践提案｜HydraFusionを使った独自実験は未実施
研究記事は、最初の一度の依頼で渡せる、範囲の明確なコーディング課題を試し始めの候補にする。ここでは空検索で件数が更新されない小さな不具合を例に、比較のやり方を組み立てた。
出典：GitHub：Project HydraFusionの研究・評価
- 先に再現する。通常の検索・空検索・0件の検索について、画面と期待値を残す。
- 開始状態を揃える。独立した作業場所を同じコミットから用意し、先の修正を後の試行へ持ち込まない。
- 同じ依頼を渡す。今の固定モデルを基準に、HydraFusionと比べる。Autoも試すなら同じ合格条件にする。
- 実物で判定する。3つの検索ケースを実行し、件数・一覧・既存機能を確認する。
- 総結果を残す。使用量・所要時間・人の修正・未確認を一行で並べる。1件の結果だけで一般の優劣を決めない。
コピー後に［ ］を書き換えて、比較する環境へ渡します。
この例と比較手順は本号の提案で、GitHubの推奨プロンプトや製品の成功保証ではない。
ONE JOB, ONE ACCEPTANCE BAR
選択を任せた後も、合格条件は手元に残す。
次の不具合1件で、品質・総費用・人の手直しを並べて比べる。