🎯 対象読者
- LLMで分類・ルーティング・可否判定などの「判断」をさせたい人
- JevやStrands Decider 2Bなどの判断特化モデルと汎用LLMのどちらを使うか迷っている人
- LLMの判断をワークフローに組み込みたい人
👋 はじめに
2026年10月7日に出たClaude Haiku 5.5は入力$0.10・出力$0.50(百万トークンあたり)とHaiku 4.5の1/10の価格になりました!
1/10になるのはプロンプトが10万トークン以下のときだけで、超えると割引は50%にとどまります
安くなるとつい何かに使いたくなります。この安さなら判断役もいけるんじゃね?ということでHaiku5.5をジャッジモデルとして試してみました。
⚖️ ジャッジモデルってなに?
文章を生成させずに「どれを選ぶか」だけを答えさせるモデルです。Jevを先駆けに最近では色々なベンダーからジャッジモデルが出てますね。
JevやStrands Decider 2Bのような判断特化モデルと特徴比べるとこんな感じになります。
| 観点 | Haiku 5.5 | Jev | Strands Decider 2B |
|---|---|---|---|
| 提供形態 | API(Claude API / Bedrockなど) | 外部API | オープンウェイト |
| 課金 | 従量課金 | 従量課金 | モデルは無料、動かす環境の費用 |
| 運用 | 不要 | 不要 | 自分でホスティング |
| データの通り道 | AWS内で完結できる(Bedrock) | JevのAPIを経由 | 自分の環境内で完結 |
速さだけなら専用モデルが有利でStrands Decider 2BはローカルのGPUやMacで動かせば1回115〜153ms程度でモデル代もかかりません。この判断特化モデルにhaiku5.5は太刀打ちできるのでしょうか?
🔧 haiku5.5をジャッジで使うときのコツ
速くブレずに番号だけを返させるためのコツです。
-
max_tokens: 1にする:実測値ベースでmax_tokens: 2より約200ms速い - 選択肢は数字にする:
0〜999は1トークンに収まるので、最大1000択まで扱える - 推論モードは切る:思考トークンも
max_tokensに含まれるので、考え始めると番号が返ってこなくなる - 固定部分が512トークンを超えるならプロンプトキャッシュを使う
- Structured Outputsは避ける:実測値ベースで1秒を超えたので数字+
max_tokens: 1とプロンプトで縛る方式が良い
数字を復唱させて確かめると999まではmax_tokens: 1で丸ごと返り、1000からは先頭1桁で切れました
プロンプトの書き方
今回の検証では、次の形で書きました。
(system)
あなたは問い合わせ分類器です。ユーザーの問い合わせを読み、次の番号のうち最も適切なものを1つだけ答えてください。番号以外は一切出力しないでください。
0: 返金
1: 配送
2: 請求
3: その他
(user)
返金してください
- 指示と選択肢はsystemに、判断させたい文だけをuserに入れる
- 選択肢は「番号: 分類名」で並べる
- 似た選択肢を並べない(似ていると隣を選びやすい)
- 紛らわしいときは短い補足を添える(例:「サイズ交換/合わない」)
🧪 検証①:1つ選ばせてみた
問い合わせ文を4つに分類させ、各例文を10回ずつ実行してブレと判断時間を測りました。
- 判断時間は、米国のクラウド環境からClaude API(
api.anthropic.com、推論リージョンはglobal)を直接呼んだ往復時間で、日本からやBedrock経由だと変わります - 例文6本×10回の小規模な検証です
import anthropic
client = anthropic.Anthropic()
SYSTEM = """あなたは問い合わせ分類器です。ユーザーの問い合わせを読み、次の番号のうち最も適切なものを1つだけ答えてください。番号以外は一切出力しないでください。
0: 返金
1: 配送
2: 請求
3: その他"""
res = client.messages.create(
model="claude-haiku-5-5",
max_tokens=1, # 番号 1 個だけ返させる
thinking={"type": "disabled"}, # 推論モードは切る
system=SYSTEM,
messages=[{"role": "user", "content": "返金してください"}],
)
print(res.content[0].text) # => "0"
temperatureなどはデフォルトのままで、例文は番号が大きいほど長く、別の分類の単語を混ぜて難しくしています。
| # | 例文 | 期待 | 正解率(10回) | 判断時間 |
|---|---|---|---|---|
| 1 | 返金してください | 0(返金) | 100% | 509ms |
| 2 | 注文した商品がまだ届かないのですが、今どこにありますか? | 1(配送) | 100% | 531ms |
| 3 | 先月の請求書に、身に覚えのない項目が載っています。何の料金か確認してもらえますか? | 2(請求) | 100% | 533ms |
| 4 | 御社の商品をよく使っているのですが、法人向けにまとめて購入できるプランはありますか?見積もりがほしいです。 | 3(その他) | 100% | 508ms |
| 5 | 先日届いた商品についてです。配送はとても早くて助かりました。ただ、使ってみたら初期不良で電源が入らないので、代金を返してほしいです。 | 0(返金) | 100% | 532ms |
| 6 | 請求書の件で連絡しました…と言いたいところですが、請求内容は問題ありませんでした。実は注文した2点のうち1点だけまだ届いておらず、追跡番号を見ても半月ほど前から更新が止まったままです。どこにあるのか調べてもらえますか? | 1(配送) | 100% | 492ms |
※ 判断時間は中央値
今回の例文では紛らわしい単語を混ぜた文でも用件を取り違えず例文の長さも~200token程度では判断時間にはほとんど響きませんでした。
🧮 検証②:複数選ばせてみた
お次は複数の分類を選ばせてみました。方式は2つで「分類ごとに1・2・4・8を割り当てて合計値を答えさせるビット演算方式」と「0,2」のようにカンマ区切りで答えさせる方式です。
ビット演算方式は3つ選択時に急激に精度が悪化しました。カンマ区切り方式は判断時間は約500msから約745msに延びるものの確実でした。
カンマ方式は1tokenに収まらないため多少遅くなります
🆚 検証③:Haiku 4.5・Jevと比べてみた
検証1の問題をhaiku4.5と5.5、Jevで比べてみました。
| 項目 | Haiku 5.5 | Haiku 4.5 | Jev |
|---|---|---|---|
必要な max_tokens
|
1 | 2 | 指定なし |
| 正解率(60 回) | 100% | 100% | 100% |
| 判断時間(中央値) | 約 515ms | 約 455ms | 約 193ms |
| 入力トークン | 103〜198 | 103〜198 | 366〜468 |
差が出たのは速さとコストでした。Haiku 4.5と5.5では初速は変わらないどころか少し遅くなっておりました。しかしコストは1/10になっておりここだけでもhaiku5.5を選ぶ価値があります。速さはJevが一歩先を行きます。
🔢 検証④:選択肢を300択まで増やしてみた
速さでは判断特化モデルに分がありますが汎用LLMならではの強みもないか探してみました。Jevの択一(Choice)は選択肢が最大255個までなので選択肢を300個まで増やすと正解率がどう変わるかを試しています。選択肢は総合問い合わせ窓口を想定した、互いに紛らわしくない分類名です。
あなたは総合問い合わせ窓口の問い合わせ分類器です。ユーザーの問い合わせを読み、次の300個の分類(番号: 分類名)のうち最も適切なものを1つだけ答えてください。番号以外は一切出力しないでください。
0: 〇〇
1: 〇〇
…
299: 〇〇
答えが1つに決まる簡単な質問40問を選択肢の数を変えて3回ずつ聞きました。
max_tokens: 1のままでも190や249のような3桁の番号は1トークンで欠けずに返ってきました。
選択肢が増えるほど番号の代わりに「この問い合わせは…」と説明を書き始めることが増えました。選択肢が多いとつい語りたくなるようです。それでもJevの上限を超える300択でおおむね選べました。
🗾 検証⑤:方言の意味をJevと比べてみた
判断特化モデルのJevと、正しさでも比べてみました。
題材は方言で、字面どおりに読むと選んでしまうダミーの選択肢を混ぜた4択です。
名古屋の小学校で、掃除の時間に先生が「みんな、机つって後ろに下げてー」と言った。
0: 机を引きずって
1: 机を持ち上げて運んで(正解)
2: 机を拭いて
3: 机をひもで吊り下げて(字面どおりのダミー)
北海道から沖縄まで各地の方言40問を両方に同じ選択肢で5回ずつ聞きました。
Haiku 5.5の方が若干方言を読めていました。答えが分かれたのはこの5問です。
| 問題 | 正解 | Haiku 5.5 | Jev |
|---|---|---|---|
| 名古屋「みんな、机つって後ろに下げてー」 | 持ち上げて運んで | 5回とも正解 | 5回とも「引きずって」 |
| 秋田「ほら、がっこ食べてけ」 | 漬物を食べていって | 5回とも正解 | 5回とも「おにぎりを食べていって」 |
| 静岡「そこ、かじっちゃだめだよ」 | 爪でひっかいては | 4回正解 | 4回「歯でかじっては」(ダミー) |
| 関西「見て、これさらの靴やねん」 | 新品の靴 | 5回とも「人から借りた靴」 | 5回とも「皿のような形の靴」(ダミー) |
| 長崎「ランドセルからって早う行かんね」 | 背負って | 5回とも「空っぽにして」(ダミー) | 5回とも正解 |
💡 他にもこんな使い方ができそう
判断させられる場所はほかにもいろいろあります。
どれも「次にどこへ進むか」を決めるだけなので番号の返事がそのまま分岐に使えます。
⚠️ haiku5.5をジャッジで使うときの注意事項
- 確信度が付かないので、迷った判断だけ人に回すことはできない
- 番号以外が返ることがあるので、受け取った値は呼び出し側で確かめる
- 返せる値は1個だけなので、複数選択はカンマ区切りで返させる
🍜 締め
Claude Haiku 5.5は判断特化モデルの代わりになるのか?の答えはやはり判断特化モデルだけあって特に速さにおいてかないませんでした
しかしhaiku5.5もかなり善戦しました。特にコストはJevと同等の激安コストとなっております。一部ですが300択や方言のようにHaiku 5.5の方が多少が頼れる場面もありました。
実戦で使うシチュエーションとしてはAWS上で外部通信せずに内部で判断させたいといった場面やClaudeAPIクレジットがあるのでこちらで判断させたいといった限定的になりそうですが可能性は見せてくれました。
LLMは「文章を書かせるもの」と思い込んでいましたがhaiku5.5の登場で「生成しないLLM」という使い方も選択肢の1つとして持っておくと便利そうです。
2026年10月からClaudeのMaxプランとTeamプランにClaude APIの月額クレジットが付くようになったので、余った分を判断に回すのもありです(Bedrock経由では使えません)








