Anthropicは2026年10月7日、軽量モデル「Claude Haiku 5.5」を公開しました。Claude Haiku 5.5 API料金は、プロンプト10万トークン以下なら、入力が100万トークン当たり0.10ドル、出力が0.50ドルです。同社はHaiku 4.5より平均の実行コストが約75％下がると説明しています。単価だけを見ると、定型文の分類や短い要約を大量に処理する事業者にとって魅力的です。
ただし、価格表の差をそのまま自社の節約額と考えるのは早計です。同じ文章でも新しいトークナイザーではトークン数が増えることがあり、結果の確認や修正に時間がかかれば、人件費を含む総コストは下がらないためです。最初に試すべきなのは、正解を人が判断でき、誤分類を後から直せる小さな工程です。
この記事では、Haiku 5.5のAPI料金、既存モデルとの役割分担、業務で試す例と比較手順を整理します。日本からの利用はAnthropicの対応地域一覧に含まれていますが、AWSなど各提供元の契約やリージョンで利用条件は異なるため、導入前に自社の管理画面でも確認してください。価格と提供条件の根拠はAnthropicの発表と対応地域一覧です。
Haiku 5.5は「小さく速く大量に回す仕事」を狙う
Claude Haiku 5.5は、Anthropicが高頻度で費用を意識する処理向けに公開したモデルです。発表では、要約、会話履歴の圧縮、データベースへの問い合わせ、分類、コーディング作業のサブエージェント、応答速度が重要なカスタマーサポートやブラウザー利用が例に挙がっています。APIで指定するモデルIDはclaude-haiku-5-5です。
この発表の実務上の意味は、すべての難問を最安モデルへ置き換えることではありません。業務を「毎回似た入力で、出力の型が決まり、間違いを検知しやすい工程」と「例外が多く、誤りの影響が大きい判断」に分け、前者で価格と速度を確かめる選択肢が増えたことです。問い合わせの要点抽出やタグ付けなら前者になり得ますが、返金の可否、契約条件の解釈、顧客への最終回答までを無確認で決めさせるのは別の設計です。
「定型作業」とは、単に短い文章を扱う仕事ではありません。入力欄、分類先、判断に使う基準、出力後に誰が何をするかが定義され、例外を見つけたときに止められることが条件です。たとえば「問い合わせを分類する」だけでは、複数の要望が同時にある場合や、必要情報が不足する場合の扱いが決まりません。「複数ラベルを付ける」「判断できないときは未分類にする」「緊急らしい表現があれば人へ回す」といったルールまで定義して初めて、低価格モデルとの比較が意味を持ちます。
また、同じ問い合わせ処理でも、文章の分類と返信の送信は別の作業です。前者は担当者が確認する候補を作りますが、後者は顧客との約束を生みます。最初の評価では、分類や要約を既存システムの横で実行し、結果だけを担当者に見せる並行運用にします。一定期間、元の業務手順も残せば、モデルが判断を誤ったときに処理を戻せます。
Anthropicは、Haiku 5.5をAWS、Google Cloud、Microsoft Azureを含む各プラットフォームで提供中としています。これは日本のすべての組織で同じ設定が即時に使えるという意味ではありません。Anthropicの対応地域一覧では日本が掲載されていますが、モデルの提供元、契約、アカウント、データ処理条件は利用先ごとに確認が必要です。既存のClaude利用契約とAPIの従量課金も同じ料金表ではありません。API料金を見て、チャット画面の月額プランまで安くなると見積もらないようにしましょう。
APIのトークン単価はHaiku 4.5より大きく下がる
Anthropicの発表では、Haiku 5.5の価格はプロンプトが10万トークン以下か、それを超えるかで分かれています。比較すると、従来モデルより安い一方、長いプロンプトでは価格差が小さくなります。料金は100万トークン当たりの米ドル建てで、入力と出力を別々に計算します。
| モデル・条件 | 入力 | 出力 | 読み込みキャッシュ | 書き込みキャッシュ |
|---|---|---|---|---|
| Haiku 5.5・プロンプト10万トークン以下 | $0.10 | $0.50 | $0.01 | $0.125 |
| Haiku 5.5・プロンプト10万トークン超 | $0.50 | $2.50 | $0.05 | $0.625 |
| Haiku 4.5 | $1.00 | $5.00 | $0.10 | $1.25 |
| Sonnet 5.5 | $2.00 | $10.00 | $0.10 | $2.50 |
小さな試算で差をつかめます。仮に1回当たり入力2,000トークン、出力500トークンの処理を月1万回行うとします。同じトークン数で計算したHaiku 5.5の料金は、入力20百万トークン分の2ドルと出力5百万トークン分の2.50ドルを足した4.50ドルです。Haiku 4.5なら同じ条件で45ドルです。これはキャッシュ、リトライ、アプリの実行費用、消費税などを含めないAPIの単純試算です。
APIを使った組み込みがまだない会社では、この表だけからチャット利用の月額費用が減るとは判断できません。APIは自社のアプリやワークフローからモデルを呼ぶ従量課金で、日常的なClaudeのチャット利用とは請求の見方が異なります。まずは手元の契約でHaiku 5.5を選べるか、利用上限や超過時の扱いがどうなっているかを管理画面で確認し、API導入を検討するのはその後にします。
この例の90％差は、あくまで「入力と出力のトークン数が同じ場合」の単価比較です。AnthropicはHaiku 5.5のトークナイザーが更新され、同じ作業でも前モデルより少し多くトークンを使うことがあると説明しています。そのため、同社が示す「平均約75％低い実行コスト」と、同じトークン数を前提にした価格表の90％差は意味が異なります。見積もりでは現在のリクエスト数をHaiku 5.5で再計測し、実際の入出力トークンとキャッシュの利用を使ってください。
プロンプトが10万トークンを超えると、Haiku 5.5の入力・出力単価はそれぞれ0.50ドル・2.50ドルになります。長い議事録や複数ファイルを丸ごと毎回読み込ませる運用では、「小さいモデルだから低額」とは限りません。必要な範囲だけを渡す、共通の指示文が繰り返されるならキャッシュ条件を調べる、出力形式を短く固定するなど、モデル選定と一緒にリクエスト設計も見直す必要があります。
どの工程ならHaiku 5.5を先に試せるか
Anthropicの公開ベンチマークは、Haiku 5.5が前モデルより幅広い評価で改善したと示しています。たとえば同社の発表では、知識業務を測るGDPval-AA v2.1のスコアはHaiku 5.5が1,620、Haiku 4.5が735、Sonnet 5.5が1,840でした。OSWorld 2.1のオフライン部分ではそれぞれ72.4％、15.7％、83.9％です。数字は特定のテスト条件でのメーカー公表値であり、日本語の顧客文面や自社手順で同じ精度が出る保証ではありません。
モデル選びでは、ベンチマーク順位よりも、仕事を分けてどの結果を人が確認するかが重要です。次のような基準で候補を絞ると、導入後に「思ったより直す仕事が増えた」という失敗を避けやすくなります。
| 仕事の性質 | Haiku 5.5を試す候補 | 別モデルや人の確認を残す条件 |
|---|---|---|
| 入力の種類と出力項目がほぼ決まる | 分類、要点の抽出、定型の短い要約 | 入力に前例のない例外が頻繁に混ざる |
| 誤りを原文や台帳と照合できる | 問い合わせ種別、製品名、期限、要対応フラグの整理 | 根拠となるデータが欠け、推測で埋めてしまう |
| まず下書きや候補を作る | 週次レポートの論点候補、返信案の草稿 | 送信、返金、契約変更など外部への影響を伴う |
| 間違いの損失が小さく、修正可能 | 社内検索の質問振り分け、問い合わせの仮タグ | 安全、法務、医療、金融などの重大判断を任せる |
同社の比較表では、Haiku 5.5はSonnet 5.5より安い一方、同じ発表のTerminal-Bench 4.0ではHaiku 5.5が39.2％、Sonnet 5.5が70.6％です。これは複雑なコーディングを含む評価の一例ですが、安さだけで難しい作業まで下位モデルへ移すべきではないことを示します。小さな分類をHaikuへ送り、曖昧な例だけをSonnetや担当者に渡す二段構成なら、安価な処理と難しい判断を分離できます。ただし、振り分け自体が見落としを生むので、後述する検証が必要です。
小さな会社で想定できる活用例は二つ
以下は機能を評価するための仮想例です。実際にHaiku 5.5で検証した結果や、導入企業の実績を示すものではありません。既存業務に当てはめるときは、利用規約や社内の情報管理ルールを確認し、最初は個人情報などを除いたサンプルで試してください。
例1：問い合わせを担当者へ振り分ける
小規模な通販会社に、配送状況、商品仕様、返品相談、法人見積もりなどが同じ受信箱へ届いているとします。担当者が一通ずつ開いて担当部署へ送っている場合、Haiku 5.5には「分類ラベル」「緊急度」「不足している情報」「根拠となる原文の短い抜粋」だけを出させます。顧客への返信文を完成させるのではなく、担当者が最初に見る一覧を整える使い方です。
たとえば「商品がまだ届かない。明日の展示会で使う予定だった」という文面なら、配送状況の確認に加えて、使用予定日が迫っていることを根拠として示すよう指示します。注文番号がない場合は回答を作らず「要確認」にする、返金やキャンセルを希望する文面は必ず人へ回す、といった境界を決めておきます。結果に原文の抜粋がなければ担当者は誤振り分けの理由を追えないため、その出力は失敗として数えます。
この工程で比べるのは、単なる分類正解率ではありません。重要問い合わせの見落とし、通常案件を緊急として扱う誤り、担当者がラベルを直す時間、未分類で戻ってくる件数も記録します。誤りが許されない区分は自動確定させず、人へエスカレーションする設計を先に作ります。
出力形式を決めるときは、分類名だけを求めず、各分類の根拠を原文の短い抜粋で示させます。「該当する文章がない」「複数のラベルが必要」「情報不足」の選択肢も用意します。人は、注文番号が存在しないのにモデルが番号を補っていないか、配送遅延と返品希望を一つのラベルへ押し込んでいないかを見られます。確信度の数字を出させるだけで安全と見なすのではなく、実際の誤分類を記録して判定ルールを調整してください。
日本語の問い合わせでは、敬語や曖昧な依頼、日付の書き方、商品名の略称、誤字なども境界例になります。たとえば「できれば週末までに」には期限の希望はありますが、必ず納品する約束ではありません。モデルの出力が希望を確定条件に書き換えないか、原文と並べてチェックします。日本語で使えるかという一般論ではなく、自社の表記や過去に誤解が生じた言い回しで試すことが大切です。
例2：週次の顧客フィードバックを整理する
別の例として、問い合わせフォームやアンケートに届いた自由記述を週ごとに整理する業務があります。Haiku 5.5には、設定済みのテーマ（配送、使い方、価格、要望など）へ一件ずつ分類し、該当する原文の一部と記録IDを添えさせます。最後に集計する場合も、件数は分類済み行から計算し、コメントの強さや顧客全体の傾向を文章だけから推定しないようにします。
たとえば「説明書を見ても初期設定が進まない」という声が複数ある場合、担当者は該当する行を読み直し、「初回設定でどの手順が止まるか」という改善候補へつなげられます。一件の不満を「全顧客の共通課題」とまとめたり、引用のない原因を補ったりしたら、その要約は採用しません。原文への戻り先を残せるので、要約の速さと検証可能性を両立できます。
この例では、分類だけのAPI費用より、週次レポートを読んで修正・承認する時間が重要です。出力が短くても、担当者がすべての根拠を再検索しなければならないなら、仕事全体は軽くなっていません。原文IDと抜粋が常に対応するかを確認項目に含めます。
要約を意思決定に使う場合、AIが付けたテーマ名だけでなく、元データの行数と重複の扱いを明らかにします。同じ顧客が同じ問題を三回送ったときに三件と数えるのか、一人の顧客の一事例とするのかは、事業側の定義です。モデルに集計の意味を決めさせず、重複排除や期間の区切りは担当者が指定します。出力に件数が含まれる場合は、集計元データの件数と照合し、抜けた行や二重カウントをサンプル確認します。
さらに「不満が増えた原因は新しい料金体系だ」といった因果関係は、自由記述の分類だけでは確定できません。要約には「料金に触れたコメントが何件あったか」と根拠を載せ、原因を判断するなら変更時期や利用状況など別の情報を担当者が確認します。整理と解釈を分けることで、短時間のまとめが経営判断に使えるように見えて、根拠が薄い結論を作る危険を抑えられます。
導入可否は「採用できた1件当たり」で測る
最小の比較テストは、本番の置き換えを決める場ではなく、どの工程で精度とコストの折り合いがつくかを知るためのものです。最初から幅広い部署へ展開せず、ひとつの処理を選んで、現在のモデルとHaiku 5.5を同じ入力で比べます。
- 仕事を限定する。「問い合わせ対応全体」ではなく、「配送・商品仕様・返品などの一次分類」のように、入力と完了条件が一文で説明できる仕事を選びます。曖昧な相談をどう扱うかも先に決めます。
- 正解を人が付けたサンプルを用意する。まずは過去の実例から、通常ケースだけでなく誤りやすい境界例も含めて数十件を抽出します。個人情報や社外秘を取り除き、正解ラベルと「人へ渡す条件」を担当者が確認します。後から同じ例でプロンプトを調整する場合に備え、評価用の一部は手を付けずに残します。件数の多い一般分類だけでなく、まれでも重大な緊急案件を別に集めてください。全件正解でも緊急ケースを一件も含んでいなければ、その業務の安全性は判断できません。
- 比較条件をそろえる。同じ本文、同じ説明、同じ出力項目で、現在のモデルとHaiku 5.5を実行します。結果に必要な情報の欠落、原文にない事実、誤分類、形式崩れを同じルールで採点します。モデル名だけを変えて本番に反映するのではなく、移行前に現在のAPIや利用画面に対応した公式手順を確認します。評価担当者には、できればどちらのモデルの回答かを伏せ、同じ基準で採点してもらいます。
- 利用量と確認時間を一緒に記録する。1件ごとの入力・出力トークン、リトライ数、応答時間、担当者の確認・修正分数を記録します。API料金だけでなく、修正に要する人件費も含めて、採用できた成果1件当たりの費用を見ます。特に日本語の入力では、文章の長さだけからトークン数を推測せず、APIの使用量を実測します。平均値だけでなく、最も遅い処理や多くの修正が必要だった例も見れば、繁忙時に詰まりそうな箇所が分かります。
- 合格条件と戻し方を先に決める。重要な案件の見落としはゼロを求めるのか、人による最終承認を必須にするのか、許容範囲を担当部門と合意します。品質が現行より落ちる、修正時間が増える、予測外の入力で形式が崩れる場合は、切り替えを止めるか、対象範囲をさらに狭めます。
計算の考え方は、（API利用料＋人の確認・修正にかかった費用＋再処理の費用）を、担当者が採用できた件数で割ることです。たとえば新モデルのAPI料金が下がっても、誤りを見つけるため全件を最初から読み直すなら、採用可能な1件当たりの費用は下がらないかもしれません。逆に同じ精度を保ったまま振り分け時間が短くなれば、処理待ちの解消や顧客への一次応答を早める余地が生まれます。改善の有無はテスト結果で確かめ、予測を成果として書き換えないでください。
評価結果は「全体正解率」ひとつにまとめず、種類ごとの件数と誤りを並べます。通常の問い合わせが多いと、緊急案件を見落としていても全体の正解率が高く見える場合があります。見逃してはいけないケースでは、正しく拾えた割合と、誤って緊急扱いした割合を別々に確認し、どちらを優先するかを業務責任者が決めます。誤りの多い入力を追加して再テストする場合も、最初の評価用セットと分けて、改善後に未知の例で確かめてください。
現行モデルとの比較では、同じ入力で一度だけ答えを比べるのではなく、実際の運用で生じる空欄、複数依頼、長文、略称、曖昧な期限などを含めます。回答が偶然よかったのか、一定して同じ基準を守るのかを確かめるため、重要なケースは複数回試す方法もあります。テスト結果を見てプロンプトを直したら、その直した例だけで合格とせず、別に残した評価用データでも基準を満たすか確認します。
本番に移すときも、一括で全面切り替えず、まず担当者が結果を確認する期間を設けます。自動処理の対象は合格した分類だけにし、未分類、根拠不足、複数の依頼、出力形式の異常は既存の手順へ戻します。最初に決めた評価条件を満たさなくなった場合、すぐ旧モデルに戻せるよう、元の設定とプロンプトを残しておくことが現実的な失敗対策です。
切り替え前に確認したいトークン数とAPI条件
Haiku 5.5をAPIに組み込む場合、モデルIDの差し替えだけで移行が終わるとは限りません。発表ページはモデルIDを示し、同じ仕事でも新しいトークナイザーによってトークンの使い方が変わる可能性を説明しています。現在のAPIコード、利用先のクラウド、出力上限、応答の扱いは実装によって異なるため、本番のリクエストを変更する前に対象プラットフォームの現行移行手順を読み、テスト環境で確認してください。
費用を抑える目的なら、プロンプトを無制限に長くしないことも大切です。毎回の依頼に共通する長い説明、過去の全会話、関係のない資料を足すほど、入力トークンと確認対象が膨らみます。必要なルールを短く固定し、元データは対象部分だけ渡せるかを見直します。繰り返し使う文面ではキャッシュ料金が使える場合もありますが、読み込み・書き込みの費用や保持期間を含めて実際の条件を確認し、必ず得だと決めつけないでください。
Anthropicの発表は、モデルの安全評価や利用制限についても説明しています。特にサイバー分野では、Haiku 5.5はHaiku 4.5より強い制限を持つ一方、より新しいモデルより一部の防御的作業が広く許可されるとされています。業務の種類によっては応答拒否や利用制限が発生するため、失敗時に処理が止まったことを人が把握できる仕組みが要ります。価格が低いことを理由に、すべての処理を無条件に自動化しないようにします。
いま試すなら、修正できる反復作業を一つ選ぶ
Claude Haiku 5.5の発表で増えたのは、安価なトークンを使って反復業務を試す選択肢です。Anthropicの比較評価では改善が示されていますが、自社の日本語データでの正確さや、担当者の確認時間まで保証されるわけではありません。価格表の差を導入効果と混同せず、実測値で判断する必要があります。
まずは、分類や要約などのうち、現在の担当者が正解を付けられて、間違いを送信前に直せる一工程を選んでください。過去例を少量用意し、現行モデルと同じ条件で比べ、正確さ・重大な見落とし・実測トークン・修正時間を記録します。採用できた結果一件当たりの費用が下がり、重要な誤りが増えない場合だけ、対象件数を少しずつ広げるのが安全です。返金や顧客への確定回答など、後から取り消しにくい判断は人の承認を残します。