こんにちは。
11/11にStable版が配信された、VSCode 1.146のリリースノートを見ていたら、Compare Modelsという面白そうな機能を見つけました。
今日はこの機能についての解説と、実際に試してみようと思います！
Compare Modelsとは
Compare Models は、同じプロンプトを複数のモデルに投げて、その出力を比較・評価・合成できる機能です。Copilotで使用できるAIモデルが、その対象となります。
具体的には、次のようなことができます。
| できること | 内容 |
|---|---|
| 複数モデルで比較する | 2〜10個のモデルに同じ課題を渡し、結果を横に並べて比較 |
| 推論の強さを比較する | 対応モデルでは、同じモデルを異なる推論設定を試せる |
| 実装を比較する | それぞれ別のGit worktreeでコードを書かせる |
| AIに評価させる | Judgeという審査役が、推奨案・評価理由・所要時間などを提示する |
| 各案のよい部分をまとめる | Synthesizerという合成役が、複数の結果から新しい回答や実装を作る |
ずいぶん楽しそうな機能ですね！
今回は簡単に、何かについて説明させるタスクで試してみました。
試してみる
使い方を簡単に
Agents Windowのモデルを選択する画面から、右上の天秤マークを押します。
ここから、実験に使用するモデルを自由に選べます。
まだ試験段階中なので、設定をONにする必要があります。
詳しい方法については公式説明にあります。
使ってみる
今回は、GPT-6 Luna, Gemini 3.8Flush, Claude Haiku5.5 に以下の質問をしてみました。
Gitのブランチとworktreeの違いを、
コミットとブランチの基本は知っている人向けに説明してください。
すると以下のような3つの画面が並んで出ます。
何が何だかわからないですね。。。
この3つの文章を評価するだけでも一苦労です。
簡単に読んでみたところ、Geminiが相手の知っている知識をもとに話し始めている感じがして、とても分かりやすいです。GPTは具体例から入り、Claudeは両者の違いについて細かく説明していました。
出力の評価・合成
自分で評価するのがめんどくさいな～って方はほかのLLMに評価をさせることができます。LLM as a Judgeですね。
最初のモデル選択の画面の右下から、Configure Judgeで評価役のLLMを選択することができます。
さらに、次の画面で Configure Synthesis を選択すると、合成役のモデルを設定できます。
合成を実行すると、設定したモデルがそれぞれの回答をもとに、新しい回答を作ってくれます。
今回は両方ともClaude Sonnet5.5にやらせてみます。
それぞれのモデルの出力が終わると、Judgeセッションが新しく作成され、評価が始まります。
このセッションを開くと以下のように回答の質・回答時間・トークン数で評価をしてくれます。
簡単にまとめると以下のように書いてあります。
Attempt 1（Haiku 5.5）が最も正確で網羅的。
Attempt 2（Gemini 3.8 Flush）は文章が長く、繰り返しが多い。
Attempt 3（GPT-6 Luna）は読みやすいが、説明が浅い。
回答時間・トークンでの評価
今回は両方とも英語で出力されていますが、Judge Instructionとして、判断役に与えるプロンプトを調整できるみたいなので、これを使うことで日本語にできそうです。
次に、出力の合成を試してみます。
プロンプトを見ると、3つのモデルの回答・ジャッジの評価結果を与えて、それぞれの回答のもっともよい点を組み合わせなさいと書いてあります。
それを見ると確かに、わかりやすく・網羅的になってる気がします。末尾に貼ってあるので、興味ある人は見てみてください。
思ったこと
- 単純な説明では、うまくいきそうだが、コードの実装となると評価役がものすごい重要そう。
- 実装とかだと、評価役のコンテキストがパンパンになりそうなので、まともな評価が出てくるのかが気になる。
- トークンの消費が3~5倍なので、コンテキストを凝って、ほかのLLMにレビューをさせる方が出力されるもののイメージは近そう。
- ただ、試してみる分にはめちゃくちゃ面白い。
- 推論レベルによる違いとかすごい気になる。
3つのLLMの回答を合成した回答
一言でいうと
-
ブランチは、コミットを指す名前付きのポインタです。履歴のどこを指すかを表します。実体は
.git/refs/heads/配下にある、コミットハッシュを書いただけのファイルです。 - worktreeは、リポジトリに紐づいた作業ディレクトリです。ファイルをどこに展開して作業するかを表します。
ブランチは履歴上のラベルで、worktree はそのラベルを実際に置く作業机にあたります。
通常のブランチ切り替えとの違い
通常は作業ディレクトリが1つだけです。git switch すると HEAD が移り、同じディレクトリのファイルが丸ごと書き換わります。その結果、次のような不便が出ます。
- 未コミットの変更があると、stash か一時コミットが必要になる。
- ビルド成果物や
node_modulesが切り替えのたびに作り直しになる。 - 複数ブランチの開発サーバーを同時に動かして比べられない。
worktree を使うと、同じリポジトリから別ディレクトリを作り、そこに別のブランチを展開できます。
~/project/ ← main を checkout（メインの worktree）
~/project-hotfix/ ← hotfix/login を checkout（追加の worktree）
~/project-review/ ← detached HEAD で PR のコミットを checkout
これらは同時に存在し、未コミットの変更も互いに影響しません。
.git/（履歴・オブジェクトDB・ブランチ） ← 1つだけ、全 worktree で共有
├─ ~/project/ （HEAD・index・ファイルは個別）
├─ ~/project-hotfix/ （HEAD・index・ファイルは個別）
└─ ~/project-review/ （HEAD・index・ファイルは個別）
追加の worktree 側の .git は、メインの .git/worktrees/<名前>/ を指すポインタ用ファイルです。リポジトリ全体をコピーするわけではないので、git clone を複数回するよりディスクも節約できます。fetch も1回で済みます。
共有されるものと、個別のもの
| 項目 | 共有 | 個別（worktreeごと） |
|---|---|---|
コミット・オブジェクトDB（.git/objects） |
○ | |
| ブランチ・タグ・リモート設定 | ○ | |
| stash | ○ | |
| HEAD（今どのブランチ／コミットか） | ○ | |
| index（ステージング状態） | ○ | |
作業ツリーのファイル（未コミット変更、node_modules、ビルド成果物） |
○ |
コミットは一度作れば、どの worktree からも見えます。一方、作業中の状態は worktree ごとに独立しています。
基本コマンド
# 既存ブランチを別ディレクトリに展開
git worktree add ../project-hotfix hotfix/login
# 新規ブランチを作りつつ、origin/main を起点に展開
git worktree add -b feature/x ../project-x origin/main
# 一覧
git worktree list
# 不要になったら削除（作業ツリーとメタデータをまとめて消す）
git worktree remove ../project-hotfix
# ディレクトリを手動で消した後の後始末
git worktree prune
押さえておきたい制約
-
同じブランチを複数の worktree で同時にチェックアウトできません。 同じブランチの先端を別々の場所で動かして、不整合になるのを防ぐためです。同じ内容が必要なら
git worktree add --detach ...で detached HEAD として開きます。 - ディレクトリを
rm -rfで消すと、メタデータが.git/worktrees/に残ります。git worktree removeを使うか、後でgit worktree pruneを実行してください。 - 依存パッケージのインストールやビルド、IDE の設定は worktree ごとに用意し直す必要があります。
- サブモジュールは、通常のクローンと同様に別途
git submodule updateが必要になることがあります。
使い分け
- ブランチを切り替えるのは、同じ作業場所で作業対象を変えるだけのときです。
-
worktree を作るのは、ブランチを切り替えずに別の作業を並行したいときです。たとえば次のような場面です。
- 作業中のブランチを止めずに、緊急修正をする。
- 2つのブランチのテストやビルドを同時に回す。
- 今の作業を汚さずに、PR を別ディレクトリで動かしてレビューする。
要するに、ブランチは履歴上の名前、worktree はその名前を別々の場所で同時に開くための仕組みです。