Claude Haiku 5.5は何に向く？小型モデルを使い分ける判断軸

「ログインできません。昨日までは使えました」。この問い合わせをAIが即座に「使い方」と分類したら、障害の見落としにつながるかもしれない。Claude Haiku 5.5のような小型モデルを使うなら、速さや単価より先に判断を保留して人に渡す条件を決めたい。

この記事では公式発表を確認したうえで、問い合わせ分類、資料の下読み、開発作業を例に使い分けを考える。AI Pulseによる実測比較はまだ行っていない。速度や精度の数値を自分たちの検証結果として扱わず、導入時に何を測るべきかを具体化する。

まず10件で試す：問い合わせを振り分ける

ここからは実際に手を動かすための例だ。製品の問い合わせ10件を、個人情報を除いて用意する。最初は送信や返信を自動化せず、分類結果を人が見るだけにする。たとえば「請求書を再発行したい」「ログインできない」「退会したい」のような短文でよい。請求や退会は誤処理の影響が大きいので、分類できても人へ渡す。

下の指示文を使うモデルに貼り、末尾の例文だけを自分の匿名化した問い合わせに替える。モデルの返答は正解として扱わず、担当者が付けたラベルと照合する。この指示文と出力例はAI Pulseの試験用テンプレートであり、Haiku 5.5での実測結果ではない。

あなたは問い合わせの一次仕分け担当です。返信文は作らず、次のJSONだけ返してください。
分類は「使い方」「請求」「解約」「その他」「要確認」のいずれか。
文面だけで判断できなければ「要確認」にしてください。
請求・解約・障害・個人情報が含まれる場合、needs_humanはtrueにしてください。
根拠は原文から短く抜き出し、書かれていない事情は推測しないでください。
形式: {"category":"...","needs_human":true,"evidence":"..."}
問い合わせ: ログインしようとするとエラーが出ます。昨日までは使えました。

この例なら「使い方」と即決するより、「要確認」かつ needs_human: true が安全だ。エラーの原因も障害の範囲も文面だけでは分からない。評価時は「JSON形式を守ったか」だけでなく、人へ回すべき案件を取りこぼさなかったかを確認する。

確認すること	10件での見方	次の判断
重要案件の見落とし	請求・解約・障害が人へ回ったか	1件でも漏れたら自動処理へ進めない
分類の一致	担当者の正解ラベルと照合	食い違いを分類ルールへ反映
回答の根拠	原文にない事情を足していないか	推測した例は「要確認」に寄せる
時間と費用	各件の所要時間と実際の使用量を記録	現行手順と同じ10件で比較

10件で危ない誤りが見つからなければ、次は複数の用件が混ざる文、怒りを含む文、情報が欠ける文を加えて30件、100件へ広げる。「全部自動で返す」より「安全に人へ渡せる範囲を広げる」方が導入しやすい。顧客データを外部サービスへ入力する前には、社内の利用規則とデータの取り扱いを確認する。

Haiku 5.5で何が変わったのか

Anthropicの発表によると、Haiku 5.5は要約、分類、データベースへの質問など、大量に発生する比較的短い仕事を想定している。顧客対応やブラウザ操作のように、返答までの待ち時間が使い勝手を左右する場面も挙げている。Claude Platformではモデル名 claude-haiku-5-5 で利用でき、AWS、Google Cloud、Microsoft Azureでも提供するとしている。

公式価格は、プロンプトが10万トークン以下の場合、入力100万トークンあたり0.10ドル、出力100万トークンあたり0.50ドル。10万トークンを超えるプロンプトには別の単価がある。キャッシュ読み取り・書き込みにも別料金が設定される。したがって「入力単価だけ」で総額を比べるのは危険だ。出力が長い処理や、同じ文脈を繰り返し読む処理では費用の内訳が変わる。

AnthropicはHaiku 4.5と比べたコスト低減や各種評価結果を示している。ただし、それは提供元の評価条件での結果だ。日本語の社内文書、固有名詞の多い問い合わせ、独自のツール連携でも同じ差が出るとは限らない。公式ベンチマークは候補選びの材料であり、自社の合格判定ではない。

料金を業務の数字に置き換える

単価の感覚をつかむため、仮に1件あたり入力1000トークン、出力200トークンの分類を1万件行うと考える。合計は入力1000万、出力200万トークンになる。10万トークン以下のプロンプト向け基本単価だけで計算すると、入力1ドル、出力1ドルで合計2ドルだ。これは料金表を使った単純な試算であり、実測費用ではない。為替、キャッシュ、追加ツール、再試行、接続先サービスの課金は含まない。

実務では件数だけでなく、依頼文に毎回添える長い説明が効く。分類対象のメールが短くても、数千トークンのルールブックを毎回送り直せば入力が増える。一方で、ルールを短くしすぎると分類の一貫性を失う。まず実際のAPI使用量を記録し、品質を落とさずに共通文脈を整理できるかを確認したい。

小型モデルへ任せやすい仕事

判断の出発点は、回答を間違えたときの影響と、正解を判定できるかだ。例えば問い合わせメールを「請求」「使い方」「解約」「その他」に振り分ける作業なら、ラベルの正誤を後から確認できる。資料の要点抽出も、元文書と照合する工程を組める。大量の候補から必要な数件を絞る一次選別は、後工程で人が確認する前提なら小型モデルと相性がよい。

一方、契約上の判断、複雑な障害の原因特定、顧客に送る最終回答などは、短い返答でも誤りの影響が大きい。小型モデルに全面委任するのではなく、下読みや分類だけを担当させ、曖昧な案件を人や上位モデルへ送る方が現実的だ。

もう一つの境界は、情報が足りないときに質問し直す必要があるかどうかだ。決まったカテゴリに振り分けるだけなら一往復で済みやすい。しかし依頼の背景を推測し、相手の状況に応じて提案を組み立てる仕事は、会話が長くなる。小型モデルを使う場合も、必要な確認事項を定型化し、情報不足なら回答を保留する設計にしたい。速く答えることと、早まって答えることは違う。

三つの仕事で境界を比べる

第一に、会議メモから決定事項と未決事項を抜き出す仕事。元の発言と照合できるため、Haiku 5.5を下書き担当に置きやすい。ただし、発言者の意図を推測して担当者を確定するのは避ける。第二に、製品レビューの感情分類。大量処理に向くが、皮肉や複数の評価が混在する文章を別枠で調べる。第三に、障害対応の原因報告。ログの要約は任せられても、原因の断定と対外説明には追加の検証がいる。

この三つは「文章を読む」点では似ている。違いは、正解を照合できる範囲と、誤った答えが次に何を動かすかだ。モデル名から仕事を決めるのではなく、仕事の出口から逆算する。結果が検索候補として人に渡るだけなら許容できる誤りも、自動返信や本番システムの変更につながれば許容できない。

問い合わせ100件で考える使い分け

ここからは導入設計を考えるための仮の例だ。ある日100件の問い合わせが届くとして、まず個人情報を扱うルールを決め、過去の回答済み案件から評価用サンプルを作る。Haiku 5.5には「分類」「緊急度の仮判定」「根拠となる問い合わせ文の短い抜き出し」までを依頼する。自信が低い、複数カテゴリにまたがる、請求や契約に関わるものは人へ回す。

合格基準は全件の平均正答率だけでは不十分だ。「緊急案件を通常案件に誤分類しないか」「解約を見落とさないか」を個別に測る。次に、1件あたりの処理時間と入力・出力・キャッシュを含む費用を記録する。上位モデルだけで100件処理した場合、人手で分類した場合とも比較する。これなら、安価という宣伝文句ではなく、自分たちの業務に合うかで判断できる。

運用開始後も、誤分類例を週ごとに見直す。問い合わせの種類は季節や製品変更で変わるため、初日の成績を固定の品質と考えない。小型モデルの価値は単価の低さだけでなく、失敗を見つけて引き継ぐ仕組みまで含めて決まる。

評価セットの作り方

評価用の100件を無作為に集めるだけでは、よくある問い合わせばかりになりがちだ。少数でも影響の大きい案件を別枠にする。例えば二重請求の疑い、本人確認が必要な変更、怒りを含む苦情、複数の用件を一文に書いた依頼、添付ファイルが欠けている依頼を含める。個人情報は試験用に加工し、取り扱いの許可範囲を守る。

評価表には「正しい分類」「モデルの分類」「人への引き継ぎ要否」「判断理由」「処理時間」を並べる。正答率が高くても、重要な案件を見逃すなら採用しない。逆に、曖昧な案件を適切に保留できるなら、多少の自動処理率低下は受け入れられる。AI Pulseは、自動化率より取りこぼし率を先に見ることを勧める。失敗時の影響を制御できてから、処理範囲を広げる方が運用を戻しやすいからだ。

開発作業では「補助役」がわかりやすい

Anthropicは、Haiku 5.5をSonnetやOpusと組み合わせる補助役としても説明している。例えば大きな開発タスクの途中で、ログの要点抽出、関係するファイルの候補探し、テスト結果の分類といった狭い仕事を受け持たせる。最終的な設計判断や変更内容のレビューは別の工程に残す。

ここでも「小型なら必ず速い」と決めつけない。呼び出し回数を増やしすぎれば、待ち時間も費用も積み上がる。下位モデルへの依頼文を長くしすぎたり、失敗して何度も再試行したりすれば節約効果は薄れる。処理を分割したときの総所要時間、やり直し回数、最終成果物の品質をセットで測るべきだ。

例えば不具合修正を「ログから症状を抜く」「関係ファイルを探す」「修正案を書く」「テストする」に分ける。最初の二つは候補を集める仕事で、間違いを次工程で発見しやすい。修正案をそのまま本番へ反映する段階は別だ。ここで人間のレビューを残す。分業するなら各工程の入出力を短く定義し、前工程の推測を確定事項として次へ渡さない。

導入前に確認したい四つの条件

評価できる仕事か：正解例やレビュー担当を用意できるか。評価できないまま大量処理を始めない。
間違いを止められるか：曖昧なケース、高リスクのケース、人の確認が必要なケースを振り分けられるか。
総費用を測れるか：入力・出力・キャッシュ・再試行・上位モデルへの引き継ぎを含めて比較する。
実際の速さを測れるか：API応答時間だけでなく、利用者が結果を受け取るまでの時間を測る。

この四つがそろわないなら、まず小さな試験運用がよい。10件ほどの典型例と、間違えやすい例を意図的に混ぜて試す。モデルを替えるだけで業務が良くなるわけではない。処理の境界を決め、失敗を拾う仕組みを先に作る方が、安いモデルの利点を生かせる。

上位モデルとの切り替え線

判断に迷うのは「どこから上位モデルへ渡すか」だ。万能な点数はないので、業務側でルールを決める。例えば分類ラベルが二つ以上当てはまる、根拠の文章を示せない、入力が長く複数資料を突き合わせる、利用者に直接公開する最終文面である、といった条件だ。この条件を明示すると、単にモデルを比べるより運用の改善点が見える。

切り替えを増やしすぎると結局すべて上位モデルへ送られ、コストは下がらない。反対に切り替えを絞りすぎると品質が落ちる。最初の数週間は、切り替え率と見逃し件数を並べて記録する。費用削減は品質の下限を守った結果として見るべきだ。

比較するときは、利用する環境も揃える。同じモデルでも、APIの呼び出し方法、渡す文脈、ツールの有無、結果を待つ画面の作りで体感が変わる。まず入力例、依頼文、出力形式、再試行条件を固定する。そのうえで現行モデルとHaiku 5.5をそれぞれ走らせる。条件が違うまま「こちらが速い」と言っても、モデルの差なのか設計の差なのか分からない。