「Opus が指揮を執って、Sonnet が作業員のときの速さと出来を測りたい」と思い、Claude Code の作業員（サブエージェント）を Opus 5.5 と Sonnet 5.5 で対にして、自分の仕事の型で作った 6 課題を 1 本ずつ走らせました。結果は、6 課題とも両方が満点です。時間は 6 対とも Sonnet が短く（1.31〜1.73 倍・中央値 1.51 倍）、API の値段に換算した料金は Sonnet が Opus の約 55% でした。
ただし、この 6 課題では能力の差は測れていません。両方が満点に張り付いて（天井）、差が出る余地が無かったからです。差が見えたのは採点に入れていなかった所で、実装・試験・入力をわざと壊して「落ちるか」を確かめた課題は、Opus が 5/6、Sonnet が 2/6 でした。
この記事の位置づけ
- この記事で新しく示すこと: 自分の過去の作業員の起動を種類分けして課題を作り、隠し採点・対での起動で、時間・料金・採点の外の振る舞い（壊して確かめるか・囲いを守るか）を並べる手順と、版 5.5 の対の結果。
- 当てはまる範囲: 私の 1 環境（Windows 11・Claude Code 2.1.284）で、各課題 1 本ずつ。各社のベンチマークの順位とは条件が違い、優劣の比較はしません。
先に弱点を 3 つ。 この記事は探索的な観測です（1 回ずつの観測で、反復していません）。
- 課題は、Opus で動かしている私の主のセッションが作りました。作り手が解ける範囲の課題です。
- 両方満点（天井）なので、「能力は同じ」とは言えません。測れる課題になっていなかった、が正確です。
- 各課題 1 本ずつです。ばらつきを見たのは課題 X の 2 回だけ（Sonnet は 2 回とも 21/21）。難しい課題での測り直しはしていません。
数字の元データと再現の手順は、検証の記録（Lab）にまとめています。
196 本の起動を種類分けして、課題を 6 つ作った
最初に、自分が過去に作業員へ出した起動 196 本を中身で種類分けしました。監査・裏取りが約 110 本（56%）、実装が 32 本（16%）、提出物フォルダの組み立てが 27 本（14%）。この上位 3 種の型で課題を作り、易しい基準の 1 本と、最高難度の 2 本を足しました。
| 課題 | 中身 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| 0 易 | 請求 CSV の集計と名簿の重複検出（隠し 18 問） | 61 秒・18/18 | 98 秒・18/18 |
| A 監査 | 検査器の欠陥 9＋成果物の違反 6・おとり 3・読み取り専用 | 56 秒・15/15 | 97 秒・15/15 |
| B 実装 | 欠陥 5・指示文に誤った前提・隠し 17 問 | 84 秒・17/17 | 114 秒・17/17 |
| C 提出物フォルダ | 機械で見る 8 点＋目視 7 点 | 273 秒・15/15 | 408 秒・15/15 |
| X 作業場全体の監査 | 約 60 ファイル・仕込み 21・おとり 4 | 139 秒・21/21 | 182 秒・21/21 |
| Y 台帳の統合 | cp932・決定ログ・誤った前提 3・10 万×10 万件・隠し 16 | 184 秒・16/16 | 280 秒・16/16 |
進め方の決まりは 3 つでした。
- Agent 道具の
modelを"sonnet"と"opus"に変えただけで、同じ指示文を同じ時刻に 1 本ずつ起動する。effort は指定せず、既定のままです。 - 正解は、出力を見る前に決めて固定する。
- 採点プログラムは、「壊れた元の状態では落ち、模範解答では通る」ことを、先に確かめる。
課題 C の依頼文と規則は架空で、実際の案件の規則は使っていません。
それでも採点プログラムはうそをつきました。課題 C の機械採点で、Opus の出力が 7/8 になったのです。「通話・Web 会議・訪問はしません」という否定の文を、禁止語として拾った偽陽性で、目視では通っていたので 15/15 に数えています。点の同じさを信じる前に、採点プログラムの出力の中身を読む必要があります。
6 課題とも満点で、時間は Sonnet が 1.5 倍速かった
6 対とも Sonnet が先に終わりました（図 1）。比は 0 が 1.61、A が 1.73、B が 1.36、C が 1.49、X が 1.31、Y が 1.52 倍。中央値は 1.51 倍で、最長の課題でも Opus で 408 秒（約 7 分）でした。
出力の速さ（待ち時間込みの tok/s）は、Sonnet が 103〜129、Opus が 79〜92 です。待ちも書く時間も Sonnet のほうが短い、という内訳でした。
B と Y では、指示文に混ぜた誤った前提（Y は 3 つ）に、両方のモデルが異議を返しました。X は Sonnet だけが偽陽性を 1 件出し、2 回目も同じ 1 件でした。ただし点はどちらも 21/21 で、この差は点に出ていません。
料金は半分にならなかった
API の値段（10-07 に公式の値段表で確認）で、6 課題の合計を換算しました。
| Sonnet 5.5 | Opus 5.5 | |
|---|---|---|
| トークンの合計 | 約 550 万 | 約 633 万 |
| うちキャッシュ読込 | 約 490 万 | 約 570 万 |
| 出力 | 約 8.7 万 | 約 9.5 万 |
| 料金（6 課題の合計） | $3.13 | $5.69 |
Opus のほうがトークンは 15% 多く、そのうち 9 割がキャッシュ読込です。この単価は両方とも 100 万トークンあたり $0.20 で、同じです。値段の差は書き込みと出力の単価から来るので、料金は半分にならず、約 55% でした。内訳は、キャッシュ書込が $1.28 対 $2.65、読込が $0.98 対 $1.14、出力が $0.87 対 $1.90 です。
⚠ キャッシュの書き込みは、5 分の値段（100 万あたり Sonnet $2.50・Opus $5）で計算しています。作業員の記録の usage の内訳を 10-01〜07 で数えたら、書き込みはすべて 5 分で、1 時間の分は 0 でした。プランの枠の減り方とは別の話です。
差は採点の外にあった——「わざと壊して確かめる」
点が同じなので、採点に入れていない振る舞いを見ました。数える前に、次の定義を決めて固定しています。
- 壊して確かめる 1 回: 作業員が、自分の直した実装・自分で書いた試験・採点に使う入力のどれかを、わざと壊した状態にして、試験や検査が落ちる（赤・失敗・検出）のを確かめた一続きの作業。
- 数えない: 課題として最初から壊れているコードを最初に走らせること／仕込みを探すだけの読み取り監査／普通の試験の実行。
- 数える単位は、課題ごとの「あった／無かった」です。
12 体の道具の呼び出し 125 回を、全部読んで判定しました。
- 壊して確かめた課題は Opus 5/6・Sonnet 2/6。自分で作る・直す 4 課題（0・B・C・Y）に絞ると Opus 4/4・Sonnet 1/4 です。
- 課題 B では、Opus が 5 つの関数を元の壊れた実装に差し戻して、どの試験が落ちるかを確かめました。Sonnet は直して試験を回しただけです。
- 課題 Y では、Opus が実装に変異を入れて試験が落ちるかを見て、落ちなかった所に試験を 1 本足し、赤になるのを確かめ直しました。
- 課題 C は両方が、定休日の判定を変えた写しで自己検査が落ちるのを確かめました。課題 X は両方とも無しです。
- Sonnet の 2 のうち課題 A は弱い当てで、存在しない道と空のフォルダを検査器に当てて落ち方を見た程度でした。
- 課題 A は、書き込みを試し用のフォルダの中だけに限る指示でした。Sonnet は 1 回、その外の一時フォルダに空のフォルダを作っています。Opus は 0 回です。
- 仕込んでいない本物の欠陥を、両方が 1 件ずつ、別々に見つけました。cp932 の端末で赤丸の絵文字を印字すると落ちる件と、
"1" in "10日"が真になる件です。
1 本ずつの観測なので、次に走らせたら 5 と 2 が入れ替わる可能性は否定できません。言えるのは「この 6 課題の記録では、Opus のほうが壊して確かめた課題が多かった」までです。
最初は「Opus は毎回、Sonnet は 1 回」と書いた
10-03 のメモには、「Opus は毎回確かめる（6/6）、Sonnet は 6 課題中 1 回」と書いていました。記事にする前に、数え方を決めて記録を読み直したら、記録を読まずに書いた数でした。読み直した結果が 5/6 対 2/6 です。向き（Opus のほうが多い）は残りましたが、数が違いました。
最初に、候補を機械で拾う網（「壊」「わざと」「revert」などの語）を作ったところ、12 体で 10 件しか当たりませんでした。網の外に落ちていたものが多く、結局、呼び出し 125 回を全部読んでいます。数えるものを増やす前に、数え方を固定して記録を全部読む、という順番にしておくべきでした。
自分の仕事で同じ比較を回す 4 手
次のモデルの版が出ても、そのまま使える手順です。
- 過去の起動を種類分けして、上位の型で課題を作る。 私は 196 本を分け、上位 3 種の型にしました。
- 正解を、出力を見る前に固定する。 採点プログラムの期待値も、被採点物から作りません。
- 採点プログラムを先に確かめる。 壊れた元で落ち、模範解答で通ること。それでも偽陽性は出るので、出力の中身も読む。
- 時間・料金・採点の外の振る舞いの 3 列で比べる。 採点の外は、壊して確かめたか・囲いを守ったか。点が天井なら、3 列目だけが差を持ちます。
Sonnet に出すなら、発注文に 1 行足す案
結果を見て、私は 10-01 に作業員を Sonnet に置き換えました。時間で 1.2 倍以上なら既定を替える、という線を使いましたが、この線は結果を見た後に置いたものです。判断の根拠ではなく、目安です。
置き換えるなら、発注文に「直したら、1 回わざと壊して、試験が赤になることを確かめてから報告する」を足す案を考えています。ただし、この 1 行で Sonnet の回数が増えるかは試していません。
言えないこと・測っていないこと
- 「Sonnet で十分」「能力は同じ」とは言えません。天井で、差を測れない課題でした。
- 30 分を超える長い作業と、満点にならない難しさで差が出るかは、観測していません。今回の最長は 408 秒です。
- effort は既定のままです。公式の頁（Model configuration・10-07）では Opus 5.5・Sonnet 5.5 とも medium とありますが、10-01 の時点の既定は確かめていません。
- 料金は API の値段への換算です。モデルの公開日は確かめていないので書きません。
この記事の本家（採点と集計の出力の写し・検証の記録）は Sumitsuke Lab → 作業員のモデル比較を自分の仕事の型で組む——Sonnet 5.5 と Opus 5.5・6 課題・同点と、壊して確かめた回数
AI の利用について
課題・採点プログラム・集計・数え直し（定義の固定と判定）・この記事の下書きは AI（Claude Code）が行い、測る・数え直す・公開の判断は人が行っています。課題の依頼文と規則は架空です。
この記事は Zenn にも同じ内容を掲載しています。