Claude Haiku 5.5は実務でどこまで使えるか。9回の実装比較と候補判定で分かった使い分け
バグ修正、Markdownパーサーの改善、単体テスト追加。この3つの小規模実装をSonnet 5.5 Low、Haiku 5.5 Medium、Haiku 5.5 Lowに同じ条件で依頼すると、全9 runが受入テストを通りました。
ただし、終わり方は違いました。Sonnetは3タスク合計76.8秒、Haiku Lowは90.1秒、Mediumは117.3秒。Haikuはツールを多く使い、バグ修正ではSonnetが追加しなかったテストも書いていました。費用の概算はHaikuが低いものの、計算の仮定と記録上の限界があります。
まず、この3タスクでHaikuがどこまでできたかと、Sonnetとの時間・費用・作業内容の違いを見ます。そのうえで、重要候補の見逃しを測った別の実験を使い、実装での成功を他の用途へ広げてよいか考えます。
この記事は、2026年10月9日に実施した2つの比較を、10月12日に一次ログまで再確認した記録です。モデル名・料金・仕様は検証時点のものです。
なぜHaiku 5.5を比較したか
普段の開発で発生する小さな修正やテスト追加を、Haikuに任せても受入条件を満たせるのか。Sonnetで終わる作業と比べて、時間や検証の進め方がどう変わるのか。この疑問を、実際のプロジェクトから切り出したタスクで確かめました。
Anthropicの発表では、Haiku 5.5のリリース日は2026年10月7日です。公式仕様では、モデルIDは claude-haiku-5-5、contextは1M tokens、最大outputは128K tokens、adaptive thinkingに対応しています。APIの既定effortはMediumです。effortは応答に使う計算量を調整する指示で、厳密なtoken予算ではありません。
公式ベンチマークは提供元の評価です。以下の数字は、自分の作業を切り出した小さな実験であり、公式スコアとは別に読んでください。
実験A：3つの実装タスクを3構成で試す
比較したのはSonnet 5.5 Low、Haiku 5.5 Medium、Haiku 5.5 Lowです。同じ3タスクをそれぞれ1回ずつ実行し、合計9 runになりました。同じタスクを各モデルで3回反復した実験ではありません。
Node.jsプロジェクトのコピーを使い、修正タスクは過去の修正前の状態から開始しました。答えのある将来のGit履歴は含めず、受入評価は作業用コピーの外に置きました。隔離は指示によるもので、技術的なアクセス遮断を証明するものではありません。
| タスク | 依頼内容 | 外部の受入判定 |
|---|---|---|
| T1：バグ修正 | 未確認を表す ['UNKNOWN'] を、欠落値や空配列と同じ未確認状態として扱う。実際の拒否条件は維持する | 31テスト。修正前は4件失敗。既知の失敗と比較して新しい回帰がないかも確認 |
| T2：パーサー改善 | 「バグ報告の方法」という見出しの案内文を、不具合として抽出しない。本文の明示的な不具合記述は抽出する | 11テスト。修正前は7件失敗。既知の失敗との回帰比較も実施 |
| T3：テスト追加 | ハッシュ・パス境界・URL正規化などの関数に、ソースを変えず単体テストを追加する | 正常なソースで通過し、15個の手製の挙動変更をすべて検出すること |
T1・T2の仕様は答えとなるテストから組み立てているため、現場の曖昧な依頼より詳しい条件になっています。
成功率・時間・概算費用・tool call
全9 runが、定めた受入判定を通りました。
| 構成 | 受入成功 | 実行時間・3タスク合計 | tool call合計 | 元レポート方式のAPI概算・合計 |
|---|---|---|---|---|
| Sonnet 5.5 Low | 3/3 | 76.8秒 | 15 | 約$0.329 |
| Haiku 5.5 Medium | 3/3 | 117.3秒 | 30 | 約$0.0214 |
| Haiku 5.5 Low | 3/3 | 90.1秒 | 26 | 約$0.0200 |
時間とtool callは実験の集計ログの値です。この実装比較では、HaikuはSonnetより短時間ではありませんでした。
費用欄は実測の請求額ではありません。 元レポートはagentのtotal token指標を入力95%・出力5%と仮定し、cache割引を使わず料金換算しています。その指標は、各API応答のinput・cache・outputを累積した量とも一致しません。したがって、この表から正確な費用削減率を出すことはできません。
Haiku Lowは元の集計166,906 tokensにこの式を適用すると$0.02002872です。約$0.020という値を再現できましたが、$0.022という別の値の算出根拠は確認できませんでした。
元レポートにはinput/outputの内訳は取得できないとありましたが、今回の再確認で会話ログにusageが残っていました。同じmessage IDの重複を除き、最後のusageを採用した集計は次の通りです。
| 構成・3タスク合計 | 非cache input | cache作成input | cache読取input | output |
|---|---|---|---|---|
| Sonnet 5.5 Low | 26 | 112,882 | 430,961 | 7,137 |
| Haiku 5.5 Medium | 48 | 132,183 | 1,099,802 | 18,650 |
| Haiku 5.5 Low | 48 | 97,840 | 1,048,654 | 17,439 |
これは会話ログのusage集計です。cacheを含む料金換算は別の計算が必要で、請求記録との照合もしていません。元レポートの概算とは区別します。
また、API料金換算とClaude Codeの5時間・週間quotaは別の指標です。この実験ではquota消費を確認できていません。安いAPI単価から、サブスクリプションの使用可能時間が何倍になるかは推定しません。
SonnetとHaikuは、同じ合格までに何をしたか
各runの成果物と作業報告を並べると、次の違いがありました。
| タスク | Sonnet Low | Haiku Medium | Haiku Low |
|---|---|---|---|
| T1：バグ修正 | ソース1行を修正。既存25テストを実行。新規テストなし | ソースを修正し3テスト追加。関連テストも実行 | ソースを修正し4テスト追加。対象ファイル29テストを実行 |
| T2：パーサー改善 | ソース修正と4テスト追加。関連テストも実行 | ソース修正と6テスト追加。複数の関連テストも実行 | ソース修正と4テスト追加。関連テストと手動の挙動確認を実施 |
| T3：テスト追加 | 11テストを作成・実行。指定した挙動変更15/15を外部評価で検出 | 28テストを作成・実行。同15/15を検出 | 23テストを作成・実行。同15/15を検出 |
これらは各agentが作業中に行った確認と、完了後の外部評価を区別した記録です。Haikuが多くのテストを書いたことは観測できますが、それだけでSonnetより高品質と判定することはできません。
成功率が同じでも、作業過程は同じではありませんでした。T1のSonnetは既存テストを実行しましたが、新しいテストは追加せず、修正対象の4つの表現や関連する生成経路を直接動かしていないと報告しています。HaikuはMediumで3件、Lowで4件のテストを追加しました。
T3ではSonnetが11件、Haiku Mediumが28件、Haiku Lowが23件のテストを作成し、全構成が指定した15個の挙動変更を検出しました。テスト数の多さをそのまま品質順位にはできません。重要なのは、どの不具合を検出できるかです。15個を検出できても、未知の不具合を網羅したことにはなりません。
実装のやり直しとHuman介入は、記録上すべて0回でした。ただし評価側では、不安定なテストの単独再実行や再評価がありました。「再試行0」は、すべてのテストを一度しか実行していないという意味ではありません。全スイートには既存の失敗もあり、最終PASSは「全テストが緑」ではなく、受入テスト通過と、評価ルール上の新しい回帰がないことを意味します。
この3タスクで使えた範囲と、まだ分からない範囲
今回Haikuで完了できたのは、期待する挙動を具体的に指定したバグ修正、抽出ルールの小さな改善、既存関数への単体テスト追加です。両effortとも、この範囲では実装のやり直しやHuman介入なしで受入条件を満たしました。
一方、3タスクですべて通った結果は、今回の完了条件を満たせたという証拠です。一般的な開発品質の同等性、長いデバッグ、曖昧な仕様、複数ファイルの設計変更まで保証する証拠にはなりません。
実験B：重要候補の見逃しを測る
別の実験では、過去の24ケース、合計1,497 candidatesを使い、候補を分類して調査対象を選ぶ処理を比較しました。選択上限は1ケース12件です。候補の内容や内部の事業情報はここでは掲載しません。
人間が過去に「役立つ」「とても役立つ」と評価した表示項目の元候補47件を重要候補とし、調査対象に選ばれなければ見逃しと数えました。この比較対象は本番で使っているCodex構成（gpt-6.1-sol / Medium）であり、Sonnetではありません。 本番構成を実験用に再実行した結果を使っています。
| 構成 | 重要候補の検出 | 見逃し | 形式不正のケース数 |
|---|---|---|---|
| 本番Codex構成 | 35/47 | 12 | 0/24 |
| Haiku Low | 33/47 | 14 | 2/24 |
| Haiku Medium・1回目 | 31/47 | 16 | 2/24 |
| Haiku Medium・2回目 | 29/47 | 18 | 2/24 |
| Haiku High | 32/47 | 15 | 1/24 |
24ケースは最初の動作確認3ケースを含みます。Mediumは24ケースをもう一度実行しましたが、他の構成は1回です。全構成を同じ反復数で測った比較ではありません。
形式不正には候補IDの写し間違い・欠落がありました。上の検出数は、形式不正の出力も含め、読めたdispositionを採点した集計です。不正な出力を本番でそのまま使えるという意味ではありません。再試行で救える可能性はありますが、修復後の品質・時間・費用はこの比較では測っていません。
処理時間の平均はCodexが139秒、Haikuが59〜111秒でした。ただし、Codexはファイルを読む構成、Haikuは入力を埋め込みツールを無効にした構成です。モデルだけでなく実行方式も違うため、速度を純粋なモデル性能差として扱いません。
Mediumの2回目はprompt cacheが効き、表示費用も変わっています。cache条件や計測方式が違う費用を、実装比較の表へ合算することもしません。
見逃しの数字にも限界がある
今回の正解は、過去に選ばれて表示された候補に対する評価です。表示されなかった良い候補はラベルに入っていません。現行処理に近い候補を評価しやすい偏りがあり、未ラベル候補を選んだ場合の誤検出率も分かりません。
Haikuの見逃しは本番構成より2〜6件多い方向でした。しかし47件と少なく、Mediumの再実行だけでも検出数が2件変わっています。モデル間の有意な能力差を証明したとは言えません。全5構成が共通して見逃した重要候補も8件あり、Codexも完全ではありません。
候補の選択だけを比較しており、その後の文章生成や日本語品質、日次処理全体の品質は未検証です。
2つの実験から、用途をどう分けるか
実装比較では、完了条件が詳しく、外部のテストで結果を確認できました。候補判定では、もっともらしい分類結果が返っても、重要な候補が含まれないことがあります。JSONの形式が正しいだけでは、この見逃しを検出できません。
自分の今回の判断は、Haikuを仕様の明確な小規模修正・テスト追加で限定利用を検討できる水準とし、全面置換の根拠は不足とするものです。重要候補の判定は、見逃しが増えないという採用条件を満たしていないため、現状ではHaikuへ切り替えません。この記事を作るために本番設定を変更したわけではありません。
上位モデルへ戻す条件は、先に決めておくと扱いやすくなります。たとえば受入テストを満たせない、再作業が増える、仕様を解釈しきれない、重要な見逃しが許容値を超える、といった条件です。今回の結果で、上位モデルへの切り替えが必ず問題を解決すると実証したわけではありません。切り替え後も同じ評価が必要です。
自分の仕事で試す小さなモデル評価手順
- 完了条件を固定する。 編集してよい範囲、入力、期待する出力、受入テスト、打ち切り条件を書きます。結果を見てから合格条件を動かさないようにします。
- 同じタスクを複数モデルで試す。 同じ開始状態と仕様を使い、別モデルの答えを見せません。model ID、effort、実行方式、順番を記録します。可能なら同じタスクを反復します。
- 成功率に時間・費用・再作業を加える。 agentの時間と評価・修復の時間を分け、input/output、cache条件、tool call、Human介入、再試行も残します。費用が推定なら式と仮定を明記します。
- テストが何を検出するか調べる。 修正前に失敗するか、想定した挙動変更で失敗するかを確かめます。既存失敗や不安定なテストは別に記録します。
- 重要な見逃しを別指標にする。 レビューや候補選択なら、人間が重要とした対象をどれだけ拾えたかを測ります。形式検証とは分け、ラベルのない対象は無理に正誤判定しません。
- 小さな成功を全面採用の根拠にしない。 曖昧な依頼や長い作業など、試していない範囲を一覧にします。ばらつきが不明なら不明のまま残します。
- 限定導入して再評価する。 戻しやすい範囲から始め、手直し・見逃し・修復込みの費用を追います。戻す条件を超えたら、元の構成へ戻して原因を確認します。
たとえば1行の記録を「タスク、構成、受入結果、agent時間、評価時間、usage、概算式、再作業、重要対象の検出、形式不正」にすると、単なる成功率より採用判断に使いやすくなります。この手順自体の効果を今回の実験ですべて検証したわけではありません。
今回残った未解決事項
各タスクの反復、曖昧な仕様、長いデバッグ、複数ファイルのリファクタ、実運用での再作業量は未検証です。実装比較のeffortは呼び出し時の指定を確認できましたが、内部でどの程度作用したかは独立検証していません。quota消費も不明です。
候補判定では、未表示候補を含めた人間ラベル、反復をそろえた比較、形式不正の修復、後続の文章生成まで含む評価が必要です。今回は追加実験を行っていません。
安価なモデルを採用するかどうかは、成功した回数だけでなく、その仕事で失敗を発見できるか、見逃しをどこまで許容できるかで決まります。今回の9 runは限定利用を考える材料になりましたが、重要な候補を選ぶ仕事の置換根拠にはなりませんでした。
関連する運用記録の話は、Claude CodeとCodexの実行時間・成功率・Quotaを記録する記事にまとめています。本記事は、その仕組みの説明ではなく、2種類の評価から使い分けを判断するための実験記録です。