背景

最近、GitHub Copilot CLI で大きめの実装を任せる場面が増えました。
そのたびに、正直ちょっと迷うことがあります。

「難しそうだから Opus 5.5 にしておくか」
「いや、Sonnet 5.5 のほうが速くて安いのでは」

どちらも感覚で選んでいて、根拠は「なんとなく」でした。
以前、別の記事（ATG の効果を調べたレポート）で Opus 5.5 の実測値を取っていたこともあり、「同じ条件で Sonnet 5.5 も測れば、比較できるのでは」と思ったのが、今回の調査のきっかけです。

比べたのは、次の 3 点です。

品質
総実行時間
トークン消費量

クレジットは参考値として併記します。

注意点 / 前提

先に、読み方の前提を書いておきます。

あくまで 私の環境での、限られた回数の実測 です。一般化はできません。
各構成は n=3 です。統計的に「差がある」と言い切れる数ではありません。
Opus 5.5 は新たに実行せず、以前の実測値を使っています。実行日と CLI のバージョンが違うため、条件は厳密には揃っていません（§ 妥当性への脅威で後述します）。
effort は medium だけです。low や high は測っていません。
プロダクションでのモデル選定は、ご自身のタスクで確認してからにしてください。この記事は、その判断材料の 1 つにとどめてもらえればと思います。

記事中の数値は、次の 3 つに分けて書きます。

事実: 実行ログや集計ファイルで確認できたこと
計算: 事実の数値から私が算出した値
推論: そこから私が導いた判断

ここで一度、整理してみます

何を比べたか

題材は、以前の調査で使った 2 つのタスクです。

タスク	内容	隠しテスト
タスク 2（大規模）	表計算エンジン。数式の文法、13 の関数、循環の検出、10,000 セルを 5 秒以内に処理する規模要件、行列の挿入と削除、保存と読込、CLI	225 件
タスク 3（単独能力を超える）	純粋な Python で作る SQL データベースエンジン `minisql`。SQLite と同じ結果を返す SQL の部分集合を実装する	564 件

タスク 3 は、Python の sqlite3 を正解にした差分テストです。
隠しテストとは、実装するモデルには見せていないテストのことです。

プロンプトは 2 種類あります。

C1（85 文字）: 通常の依頼
C1S（139 文字）: C1 に「分割して進める」旨の 1 文を足したもの

C1S はタスク 3 だけで使い、C1 と C1S を合わせて、モデルごとに 6 回を比べます。

比較項目の定義

項目	定義
完成	実行の終了後に、完了条件 `python -m pytest tests -q` が exit 0 だったこと
隠しテスト	実装者に見せていないテストの合格数
盲検レビュー C/M/m	別系統のモデルが報告した Critical・Major・Minor の件数
総実行時間	`copilot` の起動から終了までの時間（`wall_seconds`）
トークン	`--usage-output-file` の値。入力にはキャッシュの読込と書込を含む
クレジット	`totalNanoAiu` ÷ 10^9

何が問題で、何が問題ではないか

ここは切り分けておきたいところです。

問題にしたいのは、「同じ依頼を、同じ条件で任せたとき」の相対的な差 です。
問題にしていないのは、モデルの絶対的な優劣です。
盲検レビューの件数は、モデルの差の証拠としては使っていません。理由は後述しますが、同じモデル・同じ構成でも件数が大きくぶれたためです。

条件をどう揃えたか

揃えたこと（事実）

項目	Opus 5.5（既存の実測）	Sonnet 5.5（今回の実測）
題材と基点	同じベンチマーク用リポジトリの `base` ブランチ	同じ
プロンプト	C1 と C1S	同じ文字列
CLI のオプション	`--reasoning-effort medium --allow-all-tools --no-ask-user --no-auto-update --autopilot -s`。`--max-ai-credits` はタスク 2 が 3000、タスク 3 が 5000	`--model` だけを変えて同じ
人の入力	1 回	1 回
隠しテスト	タスク 2: 225 件、タスク 3: 564 件	同じファイル。採点の前に SHA-256 の一致を検査した
盲検レビュー	`gpt-5.6-sol`（effort `medium`）	同じモデルと、同じ内容のプロンプト
完了条件	`python -m pytest tests -q` が exit 0	同じ

実行したもの（事実）

タスク	構成	Opus 5.5	Sonnet 5.5
2: 表計算エンジン	C1	3 回	3 回
3: SQL エンジン	C1	3 回	3 回
3: SQL エンジン	C1S	3 回	3 回

Sonnet の 9 回は、2026-09-30 09:08 に同時に起動し、10:53 までにすべて終わりました。
実行中は PC のスリープを抑止しました。Kernel-Power のスタンバイのイベントは、9 回とも 0 件でした。
使用量の記録には、9 回とも claude-sonnet-5.5 だけが記録されていました。他のモデルが混ざっていないことの確認です。
Opus 5.5 は新たに実行していません。以前の集計ファイルから、C1 と C1S の行だけを読み出しました。

結果 1: タスク 2（表計算エンジン）

各実行の実測値（事実）

モデル	実行	所要時間（秒）	クレジット	リクエスト	入力トークン	出力トークン	うち推論	隠しテスト	実装の行数	盲検 C/M/m
Opus	c1-r1	1,607.5	240.59	16	775,667	90,917	64,653	225	1,251	0/4/2
Opus	c1-r2	2,181.8	282.55	14	696,710	95,796	69,300	225	1,238	1/2/2
Opus	c1-r3	1,850.1	240.49	12	571,607	91,214	64,851	225	1,291	2/1/1
Sonnet	c1-r1	655.7	75.38	13	652,071	49,535	26,634	225	1,210	0/5/3
Sonnet	c1-r2	826.3	91.50	15	716,519	65,382	46,550	225	1,143	0/3/2
Sonnet	c1-r3	815.2	87.88	13	641,944	62,625	41,459	225	1,123	1/3/2

まとめ（計算）

項目	Opus 5.5	Sonnet 5.5	Sonnet ÷ Opus
完成率	3/3	3/3	—
隠しテスト	225・225・225	225・225・225	—
盲検 Critical+Major の平均	3.3	4.0	—
実装の行数の平均	1,260	1,159	0.92
所要時間の平均	1,879.8 秒	765.7 秒	0.41
API の時間の平均	972.7 秒	464.7 秒	0.48
入力トークンの平均	681,328	670,178	0.98
出力トークンの平均	92,642	59,181	0.64
出力に占める推論の割合	71.5%	64.6%	—
クレジットの平均	254.5	84.9	0.33

なぜそう考えるのか（推論）

このタスクは、どちらのモデルも単独で完成できました。隠しテストでも差はありません。
盲検レビューの件数（3.3 と 4.0）は、同じモデルの中のばらつき（Opus は 3〜4 件、Sonnet は 3〜5 件）より小さいです。なので、品質の差とは読みませんでした。
Sonnet は、入力トークンがほぼ同じで、出力（特に推論）が少ない結果でした。加えて 1 トークンあたりの単価も低いため、クレジットが約 1/3 になっています。

実務ではどう影響するか

実際には、ここが一番効いてくると思います。
品質が同じなら、待ち時間が 1/2 以下になること自体が、日々の開発体験に直結します。1 回 30 分が 13 分になるのは、試行錯誤の回数に効きます。

とはいえ、これは「単独で完成できるタスク」での話です。次のタスクでは、状況が変わりました。

結果 2: タスク 3（SQL データベースエンジン）

各実行の実測値（事実）

モデル	実行	所要時間（秒）	クレジット	リクエスト	入力トークン	出力トークン	うち推論	完了条件	隠しテスト	実装の行数	盲検 C/M/m
Opus	c1-r1	8,598.6	1,711.97	25	906,765	733,465	730,084	4	0	0	—
Opus	c1-r2	6,444.4	1,273.19	39	2,823,022	511,611	432,957	0	563	3,967	20/2/0
Opus	c1-r3	8,586.6	1,876.82	27	1,067,359	777,783	773,687	4	0	0	—
Opus	c1s-r1	6,694.9	1,461.84	23	908,173	604,976	600,598	4	0	0	—
Opus	c1s-r2	8,577.6	1,852.03	51	3,737,986	769,604	691,377	0	563	4,191	1/15/3
Opus	c1s-r3	6,778.9	1,402.24	53	3,446,827	600,583	535,485	0	558	3,552	19/4/0
Sonnet	c1-r1	6,275.1	709.16	40	2,229,975	599,744	546,474	0	562	3,048	1/18/1
Sonnet	c1-r2	4,810.6	563.02	20	740,445	540,944	538,421	4	0	0	—
Sonnet	c1-r3	4,866.1	589.14	41	2,593,837	500,782	440,913	0	559	3,078	2/15/3
Sonnet	c1s-r1	3,171.6	380.05	31	1,809,164	325,070	272,809	0	555	3,001	4/18/0
Sonnet	c1s-r2	2,768.4	344.85	28	1,502,779	297,606	251,054	0	555	2,980	27/2/0
Sonnet	c1s-r3	3,527.0	440.52	44	3,004,002	343,647	287,241	0	556	2,711	18/3/0

補足（事実）:

完了条件の exit 4 は、tests が作られず、pytest が file or directory not found で終わったことを示します。つまり「実装まで辿り着けなかった」実行です。
Sonnet の完成した実装の隠しテストの不合格は、t5（集約）が 1〜6 件、t7（複合 SELECT）が各 1 件でした。ほかに t1、t2、t3、t4、t8、t10、t11、t13 が 0〜2 件です。Opus の不合格も、t5・t6・t7・t10・t11・t13 の数件でした。

まとめ（計算）

項目	Opus C1	Sonnet C1	Opus C1S	Sonnet C1S	Opus 合算	Sonnet 合算
完成率	1/3	2/3	2/3	3/3	3/6	5/6
完成した実装の隠しテスト	563	562・559	563・558	555・555・556	平均 561.3	平均 557.4
完成した実装の盲検 C+M の平均	22.0	18.0	19.5	24.0	20.3	21.6
完成した実装の行数の平均	3,967	3,063	3,872	2,897	3,903	2,964
所要時間の平均	7,876.5 秒	5,317.3 秒	7,350.5 秒	3,155.7 秒	7,613.5 秒	4,236.5 秒
入力トークンの平均	1,599,049	1,854,752	2,697,662	2,105,315	2,148,355	1,980,034
出力トークンの平均	674,286	547,157	658,388	322,108	666,337	434,632
出力に占める推論の割合	95.7%	93.0%	92.5%	83.9%	94.2%	89.6%
クレジットの平均	1,620.7	620.4	1,572.0	388.5	1,596.4	504.5
完成 1 件あたりのクレジット	4,862.0	930.7	2,358.1	388.5	3,192.7	605.3

「完成 1 件あたりのクレジット」は、その構成の全実行（失敗を含む）のクレジットの合計を、完成した件数で割った値です。

なぜそう考えるのか（推論）

品質: 完成率は Sonnet が高く、完成した実装の隠しテストは Opus が平均 3.9 件（0.7%）多く合格しました。盲検レビューは、同じモデル・同じ構成でも Critical が 1〜27 件とばらつき、差の証拠にはなりません。Sonnet の実装は Opus より約 24% 短く、隠しテストの小さな差は、細かい SQLite 互換の作り込みの差かもしれません。ただし、これは未検証です。
総実行時間: Sonnet は、C1 で 0.68 倍、C1S で 0.43 倍でした。
トークン: 入力はほぼ同じ規模で、差は出力（推論）に出ました。C1S の出力は 0.49 倍です。
クレジット: 1 回あたりで約 0.3〜0.4 倍、完成 1 件あたりでは 0.16〜0.19 倍でした。

失敗の仕組み: Sonnet 5.5 でも起きました

ここは、実務で一番気をつけたい部分です。

Sonnet の c1-r2 は、Opus の失敗と同じ形で終わりました。

20 リクエストで出力 540,944 トークンのうち 99.5% が推論で、minisql/ は作られませんでした（1 リクエストあたり平均 27,047 トークン。計算）。
セッションの記録では、24 分 20 秒の時点の SQLite の挙動の調査が、最後のツール呼び出しでした。79 分 22 秒の時点で、Autopilot stopped after repeated turns without successful tool progress. という警告で終わっています。
Opus の失敗した 3 回も、出力の 99.3〜99.5% が推論で、1 リクエストあたり平均 26,303〜29,339 トークンを使い、ツールを呼べずに終わっていました（計算）。以前の調査では、この状態の 1 リクエストの出力が、ちょうど 32,000 トークンであることを確認しています。

私の解釈（推論）

1 回の応答の出力上限の中で、推論だけで枠を使い切ってしまい、ツールを呼べないターンが続く。これが失敗の仕組みだと考えています。
この仕組みは、Sonnet 5.5 でも起きます。ただし頻度は低く（Sonnet 1/6、Opus 3/6）、1 回に使う推論も少ない傾向でした。完成した実行の出力に占める推論は、Sonnet 83.6〜91.1%、Opus 84.6〜89.8%。失敗を含む全体では Sonnet 89.6%、Opus 94.2% です。この差が、完成率の差につながったと考えます。
分割の 1 文（C1S）は、Sonnet でも効きました（C1 は 2/3、C1S は 3/3）。C1S での所要時間とクレジットは、C1 の約 0.6 倍でした。

実務ではどう影響するか

実務では、「大きな実装を、分割せずに 1 回の依頼で丸ごと任せる」ことが、モデルにかかわらずリスクになります。
私は、依頼に「分割して進める」旨の 1 文を足すだけで、失敗の確率も、失敗したときの損失も下がると見ています。139 文字と 85 文字の差だけで、これだけ違いが出たのは、正直意外でした。

比較項目ごとの評価（2 タスクをまとめて）

最後に、3 つの比較項目を 1 枚にまとめておきます。

比較項目	評価	根拠
品質	ほぼ同等。完成率は Sonnet、完成した実装の厳密さは Opus がわずかに上	タスク 2 は両者 225/225。タスク 3 は完成率 Opus 3/6・Sonnet 5/6、隠しテストの平均 561.3 と 557.4
総実行時間	Sonnet が短い（0.41〜0.68 倍）	タスク 2 は 0.41 倍、タスク 3 は C1 が 0.68 倍、C1S が 0.43 倍
トークン消費量	Sonnet が少ない（出力 0.49〜0.81 倍。入力は 0.78〜1.16 倍でほぼ同じ）	タスク 2・3 のまとめの表
クレジット（参考）	Sonnet が少ない（1 回あたり 0.25〜0.38 倍）	タスク 2・3 のまとめの表

なお、集計に使ったスクリプト、各実行の run.json・usage-single.json・transcript-single.md・hidden.xml、盲検レビューの結果は、手元のリポジトリに残してあります。数値に疑問が出たときは、そこまで遡って確認できる状態にしています。

ここまでの整理

良い点

2 つのタスクのどちらでも、Sonnet 5.5 は総実行時間が短くなりました（0.41〜0.68 倍）。
出力トークンは約 0.5〜0.8 倍になりました。入力トークンはほぼ同じ規模です。
完成率は、タスク 3 で Sonnet が Opus を上回りました（5/6 と 3/6）。
クレジットは、1 回あたり 0.25〜0.38 倍でした（参考値）。

注意点

完成した実装の隠しテストは、Opus が平均 3.9 件多く合格しました。差は小さいものの、Opus 側が上でした。
盲検レビューの件数は、ぶれが大きく、比較の根拠にできません。
どちらのモデルでも、推論で出力を使い切る失敗は起きます。

限界

各構成 n=3 です。完成した実装は、タスク 3 で Opus 3 件、Sonnet 5 件しかありません。
Opus と Sonnet で、実行日・CLI のバージョン・同時実行数が違います。
effort は medium だけです。

妥当性への脅威と限界

もう少し丁寧に、条件の違いを書いておきます。

#	内容	影響
T1	各構成 n=3。完成した実装はタスク 3 で Opus 3 件、Sonnet 5 件	完成率と隠しテストの差（平均 3.9 件）は、偶然の差でもあり得る
T2	Opus は 2026-09-27〜28（Copilot CLI 1.0.88）、Sonnet は 2026-09-30（1.0.89）に実行した	CLI の変更やサービス側の負荷の違いが、時間と完成率に影響した可能性がある。Opus を同じ日に再実行してはいない
T3	同時に実行した数が違う。Opus のタスク 3 は最大 19 回、Sonnet は 9 回（タスク 2 と 3 の合計）	Opus の所要時間は、レート制限などで長くなった可能性がある。API の時間（`api_seconds`）の比でも、Sonnet はタスク 2 で 0.48 倍、タスク 3 の C1S で 0.38 倍だった
T4	1 回の応答の出力上限は、Copilot CLI 側で決まり、利用者は変えられない	上限が大きい環境（API で `max_tokens` を大きくする場合）では、特に Opus の完成率が変わり得る（未測定）
T5	盲検レビューは、同じような実装でも件数が大きくぶれる	件数を、モデルの差の証拠として使っていない
T6	effort は `medium` だけを比べた	`low`・`high` での比較は未測定

特に T2 と T3 は、時間の比較にそのまま効きます。
Sonnet の時間が短い理由の一部は、モデルそのものではなく、実行時の混み具合かもしれません。ただ、API の時間だけで見ても Sonnet のほうが短かったので、方向としては変わらないと私は見ています。

まとめ

数字を並べたうえで、私の現実的な落としどころは次のとおりです。

既定は Sonnet 5.5 で十分だと考えています。 今回の 2 タスクでは、総実行時間は 0.41〜0.68 倍、出力トークンは約 0.5〜0.8 倍でした。隠しテストで見た仕様への適合は、Opus 5.5 とほぼ同じでした。
最も厳密な適合が必要な場面では、Opus 5.5 も候補に残します。 完成した実装の隠しテストは、Opus のほうが平均 3.9 件多く合格しました。ただし、回数が少ないので、確定的な差ではありません。
大きな実装では、モデルにかかわらず、分割の 1 文を付けます。 Sonnet でも、1 文なしの C1 は 1/3 回が同じ仕組みで失敗しました。C1S は 3/3 で完成しています。

万能ではありませんし、Opus か Sonnet かの二択で決めるものでもないと思っています。
まずはここまでで十分です。次の一歩として、自分の手元の小さめのタスクを、同じ依頼で両方のモデルに 2〜3 回ずつ流してみてください。時間・トークン・完成率の 3 つを見るだけでも、感覚ではない選び方に近づけると思います。

私のほうでも、effort を変えた比較や、Opus を同じ日に再実行した比較は、機会があれば追加で測ってみるつもりです。

参考資料

Prompting Claude Opus 5.5: 推論のトークンも出力の上限に数えられること