先週は、Claude Haiku 5.5 が Opus に負け始める地点を測りました。答えは marked パーサーの難しいバグ1件で、報告に書かれていない境界ケースを Sonnet と Opus はよく拾い、Haiku はほとんど見落としました。ただ、バグ1件では根拠が弱いので、今回は3モデルに実際のバグを25件任せました。
要約: Haiku は Opus と同じくらいバグをきれいに直し（75回中52回と54回）、コストは約95%少なく済みました。難しいバグでは Opus が上回りましたが、主な理由は他のテストを壊す回数が少なかったことです。そして、報告に書かれていなかったケースは3モデルとも同じように見落としました。
測定方法
- バグ25件: 2026年8〜10月に実際に修正された、オープンソース13プロジェクトのバグです。js-yaml、jsdiff、qs、PapaParse、markdown-it、marked、zod、humanize、tomlkit、more-itertools、cachetools、Python-Markdown、pyparsing。
- 出発点: 修正直前のコミットです。依存関係はインストール済みで、git の履歴は消してあるので、修正コミットを調べることはできません。
- プロンプト: 報告から症状だけを残しました。何が起きるか、再現手順、期待する結果だけで、原因の分析や修正案は消しました。
- Claude Code 2.1.295 をヘッドレス、effort medium で実行しました。ファイルの読み書きとプロジェクトのテスト実行は許可し、パッケージのインストールとネットワークは禁止しました。
- バグとモデルごとに3回、合計225回です。
- 採点: 実行結果からライブラリのソース変更だけを取り出し（モデルが書いたテストは捨てる）、メンテナーが修正と一緒に入れたテストを実行しました。他の箇所を壊したかはプロジェクトのテストで確認しました。
バグは2段階に分けました。易しい段階（15件）は原因と症状が近いバグ、難しい段階（10件）は報告に症状しかなく、原因が別の場所にあることが多いバグです。
結果
「きれいな修正」とは、メンテナーのテストケースをすべて通し、他のテストを1つも壊さなかった場合です。
| Haiku 5.5 | Sonnet 5.5 | Opus 5.5 | |
|---|---|---|---|
| きれいな修正、易しい段階 | 40/45 | 35/45 | 38/45 |
| きれいな修正、難しい段階 | 12/30 | 14/30 | 16/30 |
| きれいな修正、全体 | 52/75 | 49/75 | 54/75 |
| 他のテストを壊した実行（難しい段階） | 10 | 7 | 5 |
| 1回あたりのコスト（API価格） | $0.019 | $0.14 | $0.38 |
| 75回の合計 | $1.41 | $10.83 | $28.53 |
25件中22件で、Haiku と Opus のきれいな修正の回数はまったく同じでした。違った3件は次のとおりです。
- marked、リンクテキストの中のリンク: Opus は3回中2回きれいに直し、Haiku は0回でした。Haiku は3回とも、まさにその例のスペックテストを壊しました。
- markdown-it、閉じていないリンクラベルがコードスパンを隠すバグ: Opus は3回中3回、Haiku は1回です。Haiku の2回はバグを直したものの、隣のテストを2つ壊しました。
- js-yaml、空白だけのブロックスカラー: 今度は Haiku が3回中3回、Opus が1回、Sonnet が0回でした。
もう1件あります。zod で数値キーのレコードを JSON Schema の複数箇所で扱う必要があるバグは、完全に直した実行はありませんでしたが、3回合計でテストケース24個中 Opus が14個、Haiku が9個、Sonnet が5個を通しました。
どのモデルも見つけられなかったもの
難しいバグ3件では、全モデルの全実行が報告の例は直し、報告にない同じケースを見落としました。
- cachetools: 報告はクラス経由でキャッシュ付きメソッドを呼ぶ方法を1つだけ示していました。メンテナーはデコレーターの他の変種もすべてテストしていて、それを扱った実行はありませんでした。
- js-yaml: 報告はファイル先頭の BOM の問題でした。メンテナーは複数ドキュメントのストリームで各ドキュメントの前にある BOM もテストしていて、それを扱った実行はありませんでした。
- Python-Markdown: すべての実行が報告された HTML コメントの問題は直しましたが、他のインライン HTML の後に来るコメントについてのメンテナーのテストを3〜5個ずつ壊しました。
前回は Sonnet と Opus がこの種のケースをよく見つけましたが、バグ25件に広げるとその傾向は続きませんでした。大きいモデルにお金を払っても抜けたケースは出てこず、メンテナーのテストを読むほうが見つけられたはずです。
この差は本物か
この規模では見分けにくい、というのが正直なところです。慎重に書きます。
- Haiku 対 Opus、全体: きれいな修正についてのフィッシャーの正確検定は p = 0.86 です。バグ単位でリサンプリングすると、Haiku から Opus を引いた差の95%区間は −11 から +5 ポイントです。Opus のほうが多く直すという証拠はありませんが、10ポイント程度の差まで否定はできません。
- 難しい段階だけ: 区間は −33 から 0 ポイントです。この種のバグでは Opus が本当に上かもしれませんが、10件では言えません。
- Sonnet は全体のテストケース通過率が Opus より低く（対応のある並べ替え検定 p = 0.006）、はっきり有意な差はこれだけでした。
2つのモデルが ±10 ポイント以内で同じだと示すには、モデルごとに数百回、別々のバグが必要です。同じ方法でバグを増やしていくつもりです。
まとめ
- 原因が症状の近くにあるバグなら Haiku で十分です。 きれいな修正の回数は Opus と同じで、コストは約95%少なく済みます。
- 複数箇所を直す必要があるバグは Opus のほうが安全です。 難しい段階で他のテストを壊した実行は Haiku の半分でした（5回対10回）。
- 報告から抜けたケースはどのモデルも見つけません。 難しい段階では、どのモデルでも実行の47〜60%がきれいな修正ではありませんでした。どのモデルを使うにしても、レビューの時間はここに使うべきです。
限界
- バグとモデルごとに3回、バグ25件です。モデル間の差は参考程度に見てください。
- 先週の測定と違い、今回はすべての実行がプロジェクトのテストを実行できました。
- tomlkit のアンダースコアのバグは、再現例のない元の issue をもとに私が報告文を書きました。全モデルの全実行が29個中同じ20個を通しました。
- Windows では zod の CLAUDE.md（シンボリックリンク）が展開されず、zod の実行にはプロジェクトの指示がありませんでした。
- 時間計測のテストは負荷でランダムに失敗するため、「壊した」には数えていません。
- 公開プロジェクトなので、モデルが学習中に似たコードを見ていた可能性があります。修正はすべて2026年8〜10月のものです。
データ（225回、実行ごとの通過ケース・壊したテスト・時間・コスト、CSV・JSON、CC BY 4.0）: https://tokensave.app/data/claude-haiku-vs-opus-real-bugs
DOI: 10.5281/zenodo.23619927（Hugging Face・Kaggle・GitHubにもあります）
開示: この測定を公開している TokenSave は私が運営しています。Anthropic からの支援やクレジットは受けていません。