メインコンテンツへスキップ
← ブログに戻る
開発ログ2026年4月13日by K.hirano

格安モデルでも Rank S:Haiku 4.5 × 24問テスト実測(+Advisor で97.5%)

Haiku 4.5を24問で実測。単体93%でも十分強く、Advisor(Opus)の2パスで97.5%まで改善。ただし自信満々に間違える盲点も見えました。

#dev-log#Claude#benchmark#ai-dev#haiku#opus

関連記事としては Claude Opus 4.8 は何が変わった?ベンチより「正直さ」と並列エージェントが本命だったBlogClaude Opus 4.8 は何が変わった?ベンチより「正直さ」と並列エージェントが本命だったClaude Opus 4.8 で本当に変わったのは、ベンチの数ポイントではなく『正直さ』と並列サブエージェントでした。公式ベンチ、4つの新機能、OpenRouter の実トラフィックを重ねて、価格据え置きの今回のアップデートを乗り換え目線で整理します。 もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

今回のベンチマークは、総合スコアだけでなく、用途ごとの強みと弱みで見るほうが判断しやすい結果でした。

📋 この記事で使用したテスト問題(全24問)は LLM 24問テストスイート で確認できます。

目次

先に結論:Haikuは安いだけじゃない

Haiku 4.5を「コストを抑えるための軽量枠」として使っている人は多いと思います。私も最初はその一人でした。

ただ、実測してみると印象は少し変わりました。Haiku単体でも24問テストで93%のRank Sを取り、さらにAdvisor(Opus)を挟む2パス構成で97.5%まで改善しました。

これは「安いから精度はそこそこ」という雑な話ではありません。少なくとも今回の条件では、Haikuはかなり実務向きでした。

ただし、ここで話をきれいに終わらせると危ないです。Advisorは万能ではありません。自信満々に間違える問題は、すり抜けます。 この盲点まで含めて見ないと、使う側の判断を誤ります。

検証のやり方:24問を同時並列で回した

今回の検証は、机上の比較ではなく、実際に自分でサブエージェントを並列起動して計測しました。

ポイントは3つです。

  1. model:haiku のサブエージェントを使用
  2. APIは不要。Maxサブスクの範囲で実施
  3. 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点は一緒に見るべきです。

  1. 単体精度2パス精度を分ける
  2. Advisorが発動したケースしなかったケースを分ける
  3. 採点側の誤りが混ざっていないか確認する

今回の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再読は空ターン何回分か
2026年9月3日
開発ログ

Claude Codeを10時間放置で実測:177k再読は空ターン何回分か

約10時間放置したセッションの再開で 177k トークンが再書き込みされた実測を起点に、Claude Code で1時間キャッシュを空ターンで温め続ける価値を API 単価とサブスク枠の両面から損益分岐で計算しました。

#Claude Code#Claude#Anthropic#LLM#コスト削減
effort を途中で変えるとキャッシュはどうなる? Fable 5.1 と Opus 5 で実測した
2026年9月3日
開発ログ

effort を途中で変えるとキャッシュはどうなる? Fable 5.1 と Opus 5 で実測した

Fable 5.1 の値下げはキャッシュ読みだけ。Claude Code が TTL を決める仕組み、キャッシュを壊す操作と壊さない操作、effort 切替時の再書き込みを Fable 5.1 と Opus 5 の usage で実測しました。

#Claude Code#Claude#Anthropic#LLM#コスト削減
Fable 5.1 は『low で旧 max 超え』なのか|公式グラフ5枚をベンチ別に正直に読む
2026年9月3日
開発ログ

Fable 5.1 は『low で旧 max 超え』なのか|公式グラフ5枚をベンチ別に正直に読む

Claude Fable 5.1 の公式グラフ5枚をベンチ別に読み、low が旧 Fable 5 の max を超えたベンチと超えなかったベンチを表にしました。常用 effort の決め方と Pro/Max の課金条件も整理します。

#Claude#Claude Code#Anthropic#LLM#ベンチマーク
直ったのは生物分野だけ――Claude Code で Fable 5 の拒否が続く理由
2026年8月27日
開発ログ

直ったのは生物分野だけ――Claude Code で Fable 5 の拒否が続く理由

8月7日のFable 5再調整は生物分野に限定。Claude Codeで拒否を招く三層の原因と、Opus 5との使い分けを整理します。

#Claude Code#Claude Fable 5#Claude Opus 5#AI安全性#dev-log

META-MARK × AI

ローカルAIを動かすGPU、ちゃんと選べていますか?

VRAM・性能・コスパをMetaScoreで数値化。AIアプリ別の推奨ハードウェア要件も確認できます。