Copilot CLIで/modelを開き、Autoを選ぶ。毎回モデルを選ぶ手間がなくなるので、これはかなり楽です。
ただ、同じfrontendの修正を頼んだときに、前回と今回を何で比べればいいのかは急に分かりにくくなります。diffが変わったのはpromptのせいか、repositoryの状態か、routingされたモデルか。AI creditsも選ばれたモデルのrateに従うなら、費用まで一定とは限りません。
Autoを選ぶと、モデル選択はrouter側へ移ります。利用者が見るべき対象も、モデル名からrun全体へ変わります。
Autoと固定モデルを手元のrepositoryで比べるなら、先に小さな評価用harnessが要ります。まだbenchmarkを回していないので勝敗は空欄です。ここでは、その空欄へまともな値を入れられるところまで作ります。
Autoにすると、再現条件が一つ増える
GitHubの説明では、Autoはモデルのavailabilityやreliabilityに加えて、taskがreasoning、code generation、bug diagnosis、tool orchestrationのどれを必要とするかを見てroutingします。/modelからAutoと固定モデルを切り替えられますが、routingの判断や候補モデルは将来も固定とは限りません。
未知のbugを調べる仕事なら、このroutingは便利でしょう。「先週と同じ条件を再現したい」となると話が変わります。比較前に固定するファイルは4つです。
- 開始commit
- agentへ渡すprompt
- 変更してよい範囲
- 合格条件
モデル名だけ揃えても、汚れたworktreeから始めたら比較になりません。逆に、この4点が揃っていれば、Autoで選択モデルが変わってもrun単位では追えます。
比較用taskをファイルにする
比較対象は、普段の開発に近い小さなtaskを使います。今回は3種類です。
| task | 内容 | 主な合格条件 |
|---|---|---|
| T1 | TypeScriptの型エラーを、公開APIを変えずに直す | typecheck、対象test、API差分なし |
| T2 | React componentへ小さな挙動を追加し、testも足す | lint、component test、要件との一致 |
| T3 | 再現手順があるfrontend bugを診断して直す | 再現testが修正前に失敗し、修正後に通る |
taskの文章をチャット履歴だけに残すと、次回の比較で微妙に書き換えてしまいます。たとえばagent-evals/tasks/t1.ymlを置きます。
id: t1
start_commit: 3c91d2e
prompt_file: prompts/t1.md
allowed_paths:
- src/types/
- src/components/UserCard.tsx
- tests/UserCard.test.tsx
acceptance:
- pnpm typecheck
- pnpm test --run tests/UserCard.test.tsx
forbidden:
- public APIの変更
- unrelatedなformat変更
start_commit、prompt、期待するtestはversion controlへ入れます。T3なら、bugの再現手順と失敗するtestも先に用意します。agentが書いたtestだけで合格にすると、実装と採点を同じ人へ渡すことになるからです。
3 task × 2 mode × 3 runで回す
1回だけの成功や失敗は、たまたまかもしれません。Autoと固定モデルを各3回、合計18 runにします。
| task | Auto | 固定モデル |
|---|---|---|
| T1 型エラー修正 | 3 run | 3 run |
| T2 component + test | 3 run | 3 run |
| T3 bug診断 | 3 run | 3 run |
実行順はAuto → 固定 → Auto → 固定と交互にします。taskごとに先頭のmodeも入れ替えます。時間帯や一時的なavailabilityの偏りを完全には消せませんが、Autoだけを先に9回走らせるよりはましです。
各runは同じcommitから別worktreeを作ります。
TASK_ID=t1
MODE=auto
RUN_NO=1
START_COMMIT=3c91d2e
RUN_DIR="../agent-eval-${TASK_ID}-${MODE}-${RUN_NO}"
git worktree add --detach "$RUN_DIR" "$START_COMMIT"
cd "$RUN_DIR"
pnpm install --frozen-lockfile
# ここで /model を設定し、保存済みの同じpromptをagentへ渡す
以前のrunが生成したfileやcacheは使い回しません。依存installの時間を評価へ含めないなら、全runの計測開始をinstall後に揃えます。途中で計測区間を変えたら、速度の列は比較不能です。
合否判定はagentの外で実行する
agentが最後に「testは通りました」と書いても、その文章は記録に使いません。run終了後、別processからrepositoryのcommandを実行し、exit statusを保存します。
#!/bin/sh
RESULTS_DIR="${1:-agent-evals/results/current}"
mkdir -p "$RESULTS_DIR"
overall=0
run_gate() {
label="$1"
shift
"$@" >"$RESULTS_DIR/$label.log" 2>&1
code=$?
printf '%s,%s\n' "$label" "$code" >>"$RESULTS_DIR/gates.csv"
if [ "$code" -ne 0 ]; then
overall=1
fi
}
: >"$RESULTS_DIR/gates.csv"
run_gate lint pnpm lint
run_gate typecheck pnpm typecheck
run_gate test pnpm test --run
run_gate diff-check git diff --check
git diff --stat >"$RESULTS_DIR/diff-stat.txt"
exit "$overall"
commandはrepositoryに合わせて変えます。UIを触るtaskなら、Playwrightのscenario、screenshot、accessibility checkも受け入れ条件へ足します。判定だけは、実装に使ったagentの自己申告から切り離します。
run recordはモデル名より広く取る
CSVのheaderはこの程度から始めれば足ります。
run_id,task_id,mode,selected_model,started_at,elapsed_sec,ai_credits,gate_pass,changed_files,insertions,deletions,manual_fix_minutes,reviewer_note
selected_modelやai_creditsを確認できなかったrunはN/Aにします。ログからそれらしい値を推定して埋めると、比較表だけがきれいで根拠がなくなります。
記録を見返すとき、自分ならこの4項目から見ます。
- gateのpass率
- elapsed timeの中央値
- reviewerが見つけた仕様違反
- mergeできる状態まで人が直した時間
changed filesや増減行も保存しますが、diffが小さいだけで品質が高いとは判定しません。公開APIを勝手に変えた10行より、既存設計に沿った30行のほうがよい場合は普通にあります。reviewer_noteには「過剰なrefactor」「edge caseの見逃し」「testが実装詳細に依存」のような、gateでは拾いにくい差を短く残します。
Autoと固定モデルを使い分ける
比較結果を取れるようになると、modeの境界も決めやすくなります。
| 利用場面 | 最初に選ぶmode | 理由 |
|---|---|---|
| 未知のbug調査、探索的refactor | Auto | taskに応じたroutingを利用しやすい |
| regression test、benchmark | 固定モデル | 前回との差を追いやすい |
| CI、予算上限のあるjob | 固定モデル + hard gate | routingとrateの変動を減らせる |
| incidentの再現 | 固定モデル | 当時の条件を残しやすい |
| teamでの日常利用 | task次第 | modeよりpolicy、run log、cost attributionを先に揃える |
探索では、モデル選択に悩む時間をrouterへ渡せるのが素直に便利です。同じ設定をbenchmarkやCIへ持ち込むと、routingの揺れまで評価対象へ混ざります。そこでは固定モデルへ戻します。
JetBrainsもteam向けAI運用でpolicy、analytics、cost attribution、visibilityを管理対象に挙げています。対象はbusiness向けの段階的なrolloutで、Copilot CLIとは別物です。それでも、複数のagentやmodelを入れたteamが、モデル名の一覧だけでは運用できないことはよく分かります。
勝敗を書くのは18 runの後でいい
Autoが速いか、固定モデルのほうが安定するかは、taskとrepositoryで変わります。vendorの評価結果を、自分のcodebaseでの勝敗に読み替えることもできません。
task file、clean worktree、外部gate、run recordを先に置けば、routingが変わっても「何を頼み、何が通り、どこを人が直したか」は残ります。
Autoにすると、model pickerを触る時間は減ります。その時間を小さなharnessへ回す。自分のcodebaseで18 runを終えるまでは、それがAutoに対するいちばん公平な態度だと思います。