格安モデルでも Rank S:Haiku 4.5 × 24問テスト実測(+Advisor で97.5%)
Haiku 4.5を24問で実測。単体93%でも十分強く、Advisor(Opus)の2パスで97.5%まで改善。ただし自信満々に間違える盲点も見えました。
関連記事としては
BlogClaude Opus 4.8 は何が変わった?ベンチより「正直さ」と並列エージェントが本命だったClaude Opus 4.8 で本当に変わったのは、ベンチの数ポイントではなく『正直さ』と並列サブエージェントでした。公式ベンチ、4つの新機能、OpenRouter の実トラフィックを重ねて、価格据え置きの今回のアップデートを乗り換え目線で整理します。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。
今回のベンチマークは、総合スコアだけでなく、用途ごとの強みと弱みで見るほうが判断しやすい結果でした。
📋 この記事で使用したテスト問題(全24問)は LLM 24問テストスイート で確認できます。
目次
- 先に結論:Haikuは安いだけじゃない
- 検証のやり方:24問を同時並列で回した
- 結果:単体93%、Advisor込みで97.5%
- A4「りんごを取った」事件:Advisorが呼ばれないのに直した
- D3の採点者事故:Sonnetの誤りをOpusが修正した
- 見えた盲点:自信満々に間違える問題はすり抜ける
- 実務でどう判断するか
- 次に共有・検証するときの観点
- どんな場面で効くか
- 誰には不要か
- 注意点・制約
- どのように検証したか
- よくある質問
- 参考リンク
- 関連記事
- この記事を書いた人
先に結論:Haikuは安いだけじゃない
Haiku 4.5を「コストを抑えるための軽量枠」として使っている人は多いと思います。私も最初はその一人でした。
ただ、実測してみると印象は少し変わりました。Haiku単体でも24問テストで93%のRank Sを取り、さらにAdvisor(Opus)を挟む2パス構成で97.5%まで改善しました。
これは「安いから精度はそこそこ」という雑な話ではありません。少なくとも今回の条件では、Haikuはかなり実務向きでした。
ただし、ここで話をきれいに終わらせると危ないです。Advisorは万能ではありません。自信満々に間違える問題は、すり抜けます。 この盲点まで含めて見ないと、使う側の判断を誤ります。
検証のやり方:24問を同時並列で回した
今回の検証は、机上の比較ではなく、実際に自分でサブエージェントを並列起動して計測しました。
ポイントは3つです。
- model:haiku のサブエージェントを使用
- APIは不要。Maxサブスクの範囲で実施
- 24問を同時並列で回した
この条件で、まずHaiku単体の回答品質を見ました。次に、必要なケースだけAdvisor(Opus)を挟む2パス構成にして、どこまで伸びるかを確認しています。
ここで大事なのは、単純な「正答率」だけではなく、どんな問題でAdvisorが効いたか、逆に効かなかったかです。実務では平均点より、この差分のほうが効きます。
結果:単体93%、Advisor込みで97.5%
まずHaiku単体の結果です。
- 24問中 93%
- Rankとしては S
正直、ここは予想を外しました。格安枠として見ていたモデルが、ここまで素直に点を取るとは思っていませんでした。
さらにAdvisor(Opus)を使った2パスにすると、
- 24問中 97.5%
まで改善しました。
この差は、ただの数値の伸び以上の意味があります。 Haikuが一次回答でかなりの精度を出し、危ないところだけOpusが補正する形なので、「全部を高いモデルに投げる」よりコスト効率がよい可能性があります。
ただし、ここで気をつけたいのは、2パスにしたから安心、ではないことです。後述しますが、Advisorが出てくる前提そのものが外れるケースがあります。
A4「りんごを取った」事件:Advisorが呼ばれないのに直した
今回いちばん面白かったのが、A4のケースです。
要約すると、「りんごを取った」系の判断で、Advisorが呼ばれていないのに、Haiku側が自己訂正したのです。
普通なら「低コストモデルが雑に処理して終わりかな」と思う場面でした。ところが実際には、Haikuが途中で違和感を拾って、回答を直してきました。
これが何を意味するか。
- Advisorは「誤りを見つける最後の砦」ではない
- Haiku単体にも、文脈を見て自分で立ち止まる挙動がある
- ただし、その自己訂正が常に起きるわけではない
つまり、Advisorあり=Haikuが常に雑、ではないし、Advisorなし=即ダメ、でもない。 この辺りは、実際に触るまで見えにくいところです。
A4は、Haikuの見直し能力が想像以上だった一方で、どの問題でも同じように働くわけではない、という現実も同時に見せました。
D3の採点者事故:Sonnetの誤りをOpusが修正した
もう一つ重要なのがD3です。
ここでは採点者(Sonnet)が誤った判定をしていたのを、Advisor(Opus)が修正しました。
これはかなり示唆的です。なぜなら、AIベンチを回していると、つい「採点側は正しい前提」で見がちだからです。でも実際は、採点官も間違える。
この実例は、今回の2パス構成の価値をよく表しています。
- 問題を解くHaikuがいる
- その回答を見る採点者がいる
- さらに上位のAdvisorが、採点者のミスを拾う
要するに、モデル本体だけでなく、評価の鎖も壊れるということです。 現場で「このモデル、思ったよりダメだな」と判断したとき、実は採点側の前提がズレていた、ということは普通に起こります。
このD3は、単なる1問の修正ではなく、ベンチ結果の見方そのものを疑えというメッセージでした。
見えた盲点:自信満々に間違える問題はすり抜ける
ここが本題です。
Advisor(Opus)はたしかに効きます。ですが、「自信満々に間違える」タイプの問題には弱いです。
今回の観測では、Haiku側がそれっぽく筋の通った答えを出してしまい、しかもその誤りが一見もっともらしいと、Advisorが介入する契機が弱くなります。つまり、誤りの自覚が薄いまま通過する。
これは厄介です。
なぜなら、実務ではこのタイプのミスがいちばん痛いからです。 雑な間違いなら人間がすぐ止められます。でも、丁寧に見える誤りはレビューを通りやすい。
今回の実験で分かったのは、
- 単純な精度はかなり高い
- Advisorでさらに底上げできる
- それでも「間違いの質」が悪い問題は残る
ということでした。
つまり、Haiku + Advisor は強いが、完全な検査装置ではないです。 データではかなり優秀ですが、ツール呼び出しはまだまだ。Claude Codeの代替としては厳しいですね、という言い方に近い感覚です。今回のHaikuも同じで、期待以上に強いが、最後の安全弁にはならない。
実務でどう判断するか
では、実際に使うならどう考えるべきか。
私の判断はこうです。
- 定型寄り・局所的・レビュー前提の作業なら、Haiku単体でもかなり戦える
- ミスのコストが高い箇所では、Advisorを挟む価値がある
- ただし、「Advisorを入れたから安心」という運用は危険
特に、次のような場面では相性がよいです。
- 複数案の要約
- 仕様の読み合わせ
- コードレビューの一次チェック
- 小さめの実験や分類タスク
逆に、
- 仕様の解釈ミスが致命傷になる
- 誤りがもっともらしく見える
- 評価基準そのものが曖昧
このあたりは、Haiku単体でもAdvisor込みでも、最後は人間の確認が必要です。
今回の結果だけで「高いモデルを全部やめていい」とは言えません。そこまで単純ではないです。 ただ、軽量モデルを雑に見積もるのはもったいない。これははっきり言えます。
次に共有・検証するときの観点
この手の結果を社内やチームで共有するときは、正答率だけ貼って終わると危ないです。
最低でも次の3点は一緒に見るべきです。
- 単体精度と2パス精度を分ける
- Advisorが発動したケースとしなかったケースを分ける
- 採点側の誤りが混ざっていないか確認する
今回の24問では、Haiku単体でも十分に実用圏に入り、Advisorでさらに伸びました。 でも同時に、A4の自己訂正やD3の採点者修正が示したように、「モデルの強さ」と「評価の正しさ」は別問題です。
この切り分けをしないと、数字だけ見て判断を誤ります。
結論をもう一度だけ置きます。
Haiku 4.5は、安いだけのモデルではありません。24問実測でRank S、単体93%。Advisor(Opus)を組み合わせれば97.5%まで伸びました。 ただし、自信満々に間違える問題はAdvisorをすり抜ける。ここを見落とすと、実務では痛い目を見ます。
だから私は、Haikuを「コスト削減の妥協案」ではなく、条件付きでかなり使える実戦モデルとして見直しました。
どんな場面で効くか
- 次に試すローカルLLMを絞り込むために、スコアと用途の両面から判断材料が欲しい場面
- 使用中のモデルを更新すべきか、具体的な数値を見て判断したい場面
誰には不要か
- すでにモデル選定が完了していて、ベンチマーク情報が不要な人
- 特定の用途に絞っていて、汎用スコアより自分の実測結果だけで判断したい人
注意点・制約
- スコアはテスト設計と採点基準に依存します。他のベンチマークと単純比較はできません。
- 推論速度はGPU・量子化・同時実行数で大きく変わります。
- 実機で試すまで、スコアだけで用途を決めないほうが安全です。
どのように検証したか
- 統一した24問テストセットを使い、カテゴリ別(意地悪・論理・コード・日本語)にスコアを記録しました。
- 実機環境で確認し、ハードウェア構成・モデル設定・実行日時を併記しました。
よくある質問
スコアが低いと実用にならないですか?
用途を絞れば低スコアでも実用になる場面はあります。カテゴリ別スコアで得意分野を確認するのが判断しやすいです。
自分の環境でも同じ結果になりますか?
GPU・量子化・ランタイムが変わると速度・精度ともに変わります。本記事の環境を参考に、差異を見込んで判断してください。
他のモデルとどう比べればいいですか?
同じテストセットでのスコアが最も比較しやすいです。当サイトの過去ベンチ記事も参照してください。
参考リンク
関連記事
この記事を書いた人
HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です!エンジニア専門結婚相談所も運営中、ClaudeCodeで解決できない心の課題も解決いたします!
関連記事
Claude Codeを10時間放置で実測:177k再読は空ターン何回分か
約10時間放置したセッションの再開で 177k トークンが再書き込みされた実測を起点に、Claude Code で1時間キャッシュを空ターンで温め続ける価値を API 単価とサブスク枠の両面から損益分岐で計算しました。
effort を途中で変えるとキャッシュはどうなる? Fable 5.1 と Opus 5 で実測した
Fable 5.1 の値下げはキャッシュ読みだけ。Claude Code が TTL を決める仕組み、キャッシュを壊す操作と壊さない操作、effort 切替時の再書き込みを Fable 5.1 と Opus 5 の usage で実測しました。
Fable 5.1 は『low で旧 max 超え』なのか|公式グラフ5枚をベンチ別に正直に読む
Claude Fable 5.1 の公式グラフ5枚をベンチ別に読み、low が旧 Fable 5 の max を超えたベンチと超えなかったベンチを表にしました。常用 effort の決め方と Pro/Max の課金条件も整理します。
直ったのは生物分野だけ――Claude Code で Fable 5 の拒否が続く理由
8月7日のFable 5再調整は生物分野に限定。Claude Codeで拒否を招く三層の原因と、Opus 5との使い分けを整理します。
META-MARK × AI
ローカルAIを動かすGPU、ちゃんと選べていますか?
VRAM・性能・コスパをMetaScoreで数値化。AIアプリ別の推奨ハードウェア要件も確認できます。
PR広告:開発環境・キャリアまわりのサービス