テストケース生成に Opus は必要か — Claude Code の Skill で Haiku / Sonnet / Opus を比較した

モデル選定に根拠がない

【エンジニア募集中】フルリモート可◎、売上/従業員数9年連続UP、平均残業8時間、有給取得率90％、年休124日以上 etc.　　詳細はこちらから＞

仕様書からテストケースを生成する Skill を Claude Code で動かすとき、どのモデルを選ぶかに根拠がない。出力単価は Haiku 4.5 が $5、Opus 5 が $25（1Mトークンあたり、2026-07-28 確認）と5倍違う。チームで日常的に回すなら無視できない差である。

テストケース生成は測りやすい題材でもある。根拠は仕様書だけなので、拾うべき検証点を先にリスト化すれば機械的に採点できる。そこで検証用の Skill を2つ用意し、31項目のリストを作って18回測った。

検証の設計

題材は在庫管理システムの「商品新規登録」。入力7項目・自動設定3件・エラー4条件・画面挙動3件の1画面仕様書である。

条件を2つ置いたのは、知りたかったのがモデル差そのものではなく、Skill の書き込み量とモデルの関係だったからである。条件Aは詳細版の generate-testcase。テスト観点カタログ8観点とテストケース設計ルール3項を持つ。条件Bはそこからその2セクションだけを削った generate-testcase-minimal で、進め方・出力先・出力JSONの形式はAと同一である。2条件 × 3モデル × 3回 = 18ラン。 1回では外れ値と実力が区別できない。

実施手順:
１：入力を凍結する。仕様書・両Skill・ルーブリックは検証中いっさい変更せず、プロンプトも18ラン全部で同じ文面を貼る（手打ちしない）
２：31項目のルーブリック（易17 / 中11 / 難3）を、出力を1本も見ないうちに確定させた
３：生成は1ラン1セッション。毎回 /clear してからモデルを切り替える
４：同じセルを連続で回さない。6ラン（2条件 × 3モデル）を1周とし、ラウンドロビンで3周した。連続で回すと、その時間帯のサーバー側の状態が同一セルの3ランに同じように効いてしまう
５：18本をシャッフルして run01〜run18 にリネームし、出力にモデル名が混入していないか grep で確認してから採点に回す
６：採点も1ファイル1セッション。専用の採点エージェントにルーブリックと仕様書を渡してブラインド採点させる
７：対応表は18本の採点が終わるまで開かない

実行時間は測っていない。サーバー負荷に支配され、n=3 では分離できない。

結果

表1: 主要結果（平均、括弧内は最小〜最大。n=3）

出力単価は Haiku $5 / Sonnet $15 / Opus $25（1Mトークンあたり、2026-07-28 確認）。Sonnet は 2026-08-31 まで導入価格 $10 が適用されるため、コスト比を両方併記した。

表2: Skill を薄くしたときの落ち込み（網羅率の平均）

条件Aでは Opus が3回とも満点。この規模の仕様書では上位2モデルの差が測れず、天井に当たっている。

主結論は表2にある。Skill を薄くしたときの落ち込み幅がモデルで違う。 整備の恩恵は下位モデルほど大きい。

ただし Skill では埋まらない差もある。難項目 #6（APIから初期在庫を指定しても在庫数が0で登録されるか）を、Haiku は両条件で落とした。条件Aの難は3回すべて 2.0 で、人手検算した run02 でも #6 は ×。厚い Skill を与えても3回とも拾えていない。

ばらつきは Haiku は3点幅、Opus は0〜1点幅。粒度違反は条件Bでしか起きておらず、設計ルールを外した分がそのまま出た。最も崩れた run08（条件B・Haiku）は、ハルシネーション（仕様書にない内容の捏造）が全17ケース中12ケースに反復した。捏造したのはエラーメッセージ文言で、総合19.0まで落ちている。ただし捏造は条件Aでも起きており、run07 で2件出ている。

逆に、仕様の不備を指摘したのは条件Bの Opus だけだった（平均1.0件）。観点カタログを与えると、与えられた観点を埋めに行き、仕様の穴を探さなくなる。

副産物: LLM に採点させて分かったこと

難項目3つを6ファイル分（各セル1本）人手で再判定し、18判定すべて一致した。根拠として挙がったケースIDも全件一致している。

ただし「LLM採点は信頼できる」とは一般化できない。一致したのは明文化した部分である。明文化しなかった減点の「件数の数え方」では崩れ、18本のうち run08 だけがケース単位で数えて総合が22ポイント動いた（−3.0 → 19.0。監査で発見し種類単位に統一）。判定条件をどこまで書き切れるかで結果が決まる。

ランを実行したのは自分なので、人手検算は完全なブラインドではない（採点エージェント側は完全ブラインド）。

結論 — Opus は必要か

Skill が整備されているなら Opus は不要。 条件Aでの Sonnet との差は31点満点で0.7点、1点あたりの推定コストは約半分（2.99 vs 5.77）である。8月末までの導入価格が使えるなら 1.99 で、約3分の1になる。

難項目を確実に拾わせたいなら Opus。 仕様の行間にあたる #6 を両条件6ラン全部で拾えたのは Opus だけで、ここは Skill では埋まらなかった。

Haiku は最安だが崩れ方が大きい。 3点幅で振れ、捏造も両条件で出ている。外れの回をレビューで拾う工数を勘定に入れる必要がある。

モデル名を決める前に、自分の Skill にどこまで書いてあるかを見たほうがよい。Skill を薄くした損失は最大 −3.3 点で、Opus と Sonnet の差 0.7 点よりはるかに大きい。

この検証の限界

・条件Aで上位2モデルが満点に達した（天井）。 この規模より複雑な仕様書では結果が変わりうる

・Opus と Sonnet の差は0.7〜1.4点。 範囲が接触しており、n=3 では分離できなかった（統計的検定はしていない）

・検証点 #6 / #21 / #22 は API を直に叩く必要があり、「手動テスト」の範囲を超える疑いがある。 ルーブリック側の設計問題

・コストは実測できていない。 サブスクのため金額・トークン数が取得できず、出力量と公開単価（2026-07-28 確認）からの推定比率である。thinking のトークンとハーネスのオーバーヘッドを含まない。 thinking は出力トークンとして課金されるため、思考量の多いモデルほど推定が実際より低く出る

前提も揃っていない。Haiku のみ 4.5 世代でコンテキストは 200K（Sonnet / Opus は 5 世代・1M）。thinking は3モデルとも有効な状態で走っていた（Haiku 4.5 は API 既定では無効だが、Claude Code 側で有効化されていた）。ただし Haiku 4.5 は effort パラメータに非対応で、思考量の制御方式が上位2モデルと異なる。固定したのは仕様書・Skill・プロンプト・実行環境、変えたのはモデルと条件のみ。

まとめ

・Skill が整備されているなら、この規模のテストケース生成で Opus と Sonnet の差は出なかった。 0.7点で範囲も接触しており、n=3 では分離できていない。1点あたりの推定コストは Sonnet が約半分なので、通常はこちらで足りる

・Skill を厚くする効果は、モデルを1段上げる効果とほぼ同じ大きさで、単価は変わらない。 Haiku に与える Skill を条件Bから条件Aに変えると +3.3点。条件Bのまま Sonnet に替えても +3.6点だが、コストは2.76倍になる。先に投資すべきは Skill のほうである

・逆に、観点カタログを与えると Opus は仕様の穴を探さなくなる。 仕様の不備を指摘したのは条件Bの Opus だけで、3ラン中2ラン、平均1.0件。仕様書レビューを兼ねたいなら、観点を与えない状態で Opus に1本書かせる使い道がある。 ただし条件Bの Opus は粒度違反も平均1.3件出ており、出てきたものをそのまま試験項目書にはできない

・差がつくのは「中」「難」の項目だけ。 易17項目はどの条件・どのモデルでも16〜17点だった。Skill もモデルも、効くのは仕様の行間を読む部分である

・捏造はどの条件でも起きる。 条件Aの run07 でも2件出ている。どの組み合わせを選んでも人のレビューは外せない

付録: 生スコア18ラン（参考）

 ※ run08 のハルシネーション1件は「エラーメッセージ文言の捏造」が12ケースに反復したもの。同一種類は1件として計上している。

付録: 検証フォルダの構成

ブラインド性は 出力結果/ → testcases/ のリネームと 対応表.md の隔離で担保している。採点エージェントが見るのは testcases/ 配下のファイルだけで、ファイル名にモデル名は残っていない。

【エンジニア募集中】フルリモートも◎(リモート率85.7％)、平均残業8時間、年休124日以上、有給取得率90％ etc.　詳細はこちらから＞