分類・抽出・要約でClaude Haiku 5.5と4.5を比較

Claude Haiku 5.5は、繰り返し発生するアプリケーションのタスクで評価する価値があります。ただし、Haiku 4.5から切り替える前に、モデルのアップグレードが出力契約を満たすことを確認してください。Ofoxで行った小規模なテストでは、どちらのバージョンも分類と抽出で期待どおりの値を返しました。一方、要約の形式には違いがあり、どちらもJSONを求めたにもかかわらず、応答をMarkdownのコードフェンスで囲みました。正しく見える回答が、そのまま厳密なJSONパーサーに渡せるとは限りません。

この記事では、実際のAPIに送った合成データによる3つのタスクを比較し、記録された結果を示したうえで、バッチ処理やアプリケーションのバックエンドを保守する開発者向けに移行手順を紹介します。精度、レイテンシ、コストのいずれについても、全般的な優位性を示すものではありません。各モデルに対し、タスクごとに1回ずつ、合計6件のリクエストを行いました。構造化出力のスキーマは使用していません。

Anthropicは10月7日にHaiku 5.5を発表し、分類や要約を含む大量処理向けとして位置づけました。こうした製品上の説明と、以下で扱う限定的な観察結果は別のものです。

10月12日に撮影したOfoxの実際の英語版インターフェースです。モデルIDとAnthropic SDKの例が表示されています。以下の比較では、これとは別に指定したChat Completionsルートを使用しています。このスクリーンショットは設定の参考を示すものであり、評価の成功を示すものではありません。

テスト条件

https://api.ofox.ai/v1/chat/completionsを使用し、max_tokens: 1800を指定しました。使用したOfoxのIDは次のとおりです。

anthropic/claude-haiku-4.5
anthropic/claude-haiku-5.5

temperatureやreasoningの制御パラメーターは明示的に設定していません。プロバイダーによって、デフォルト値、ルーティング、トークン計上方法は異なる場合があります。そのため、同じユーザーテキストを送っても、実効的な計算予算が同じになるとは限りません。入力には顧客データ、実際の注文、個人情報を含めていません。

ダウンロード可能なテストキットには、プロンプト、サニタイズ済みの応答記録、スクリプトが含まれています。APIスクリプトを実行すると実際にリクエストが送信され、使用料金が発生する場合があります。まず内容を確認し、上限を設けたテスト予算を設定してください。元の観察結果はテストバッチの実施日に記録したもので、このページを読むたびに再生成されるわけではありません。

要約のプロンプトでは指定フィールドを求めましたが、正式なスキーマは与えていません。このテストは統合上のリスクを見つけるのには役立ちますが、スキーマを強制する機能を使ってもモデルが従えない、と結論づける根拠にはなりません。

結果：値と応答形式は別々に確認する

分類と抽出では、1組の外側のコードフェンスを取り除けば値は一致しました。コンシューマーがjson.loads(response_text)を直接実行する場合、同じ応答でもパースエラーになります。コードフェンスを1組だけ許容するのかどうかを決め、明文化してください。出力が期待どおりに見えるまで、任意の不正な応答を暗黙に「修復」するのは避けましょう。

Haiku 5.5の要約は、次のようなフラットなオブジェクトでした。

{
  "owner": "Maya",
  "deadline": "2026-10-14",
  "decision": "English-only pilot approved",
  "unresolved": "Price undecided"
}

一方、Haiku 4.5は、メールの草案、パイロットの承認、未決定の価格を個別のタスク項目にまとめていました。この形式にも有用な情報は含まれていますが、トップレベルのownerとdeadlineを期待するコンシューマーはそれらを見つけられません。サンプルは1件だけでスキーマも明確に定義されていないため、適切な結論は、どちらか一方のバージョンが常に要約で優れているということではなく、統合契約をテストして適用することです。

また、フラットなオブジェクトでは、メールの草案を作成するというアクションが明示されていません。業務でアクションと決定の両方が必要なら、別々のフィールドを必須にしてください。「スキーマに合っていること」と「業務上必要な事実をすべて含むこと」は、異なる2つの受け入れテストです。

観測されたレイテンシとトークン数

以下は、クライアント側で観測したリクエスト所要時間と、APIが報告したトークン数です。選択したゲートウェイ経路を含んでおり、モデル単体の推論時間を示すものではありません。

今回の実行では、5.5への要約リクエストのほうが時間がかかりました。この単独の観察結果は、ベンダーのより広範な位置づけを否定するものでも、本番環境のレイテンシを予測するものでもありません。サービスレベルの期待値を変更する前に、実運用を代表するケースを繰り返しテストし、失敗も含めてレイテンシ分布を収集してください。

目に見える回答の単語数を、課金対象の出力トークン数として数えないでください。返された使用量フィールドを記録し、プロバイダーのリクエスト記録と照合してください。表にはAPIが返した値を示していますが、内部計上の差をすべて説明するものではなく、確定した金額を主張するものでもありません。

予算を見積もる際は、入力と出力の単価だけでなく、受け入れられた結果1件あたりのコストを比較してください。実務で使える計算シートの例を示します。

cost per accepted result =
  reconciled spend across initial attempts, retries and fallbacks
  / number of results that pass your acceptance rules

拒否された出力やフォールバック呼び出しも分子から除外しないでください。受け入れられた結果がない場合、比率は未定義であり、ゼロではありません。費用を計算する前に、正確なプロバイダーの現在の料金と、適用されるキャッシュまたはコンテキストの料金区分を確認してください。この記事では、Ofoxで節約できる金額を固定値で示していません。

より厳密な抽出契約を使う

まず、値が欠けている場合の扱いと型の規則を明記したプロンプトを用意します。以下は改善したテンプレートであり、上記の測定に使用したプロンプトではありません。

Extract only facts explicitly present in the input.
Return a single JSON object, without Markdown or commentary.
Keys must be exactly:
order_id: string
quantity: integer
delivery_date: ISO YYYY-MM-DD string, or null if not stated
currency: three-letter currency code, or null if not stated
Do not infer a delivery date from today's date.
Do not convert an unknown value to an empty string.
Input:
Order BX-71 contains 12 notebooks. Delivery is not scheduled.
Total: 48 EUR.

得られたオブジェクトはコードで検証してください。使用するルートがスキーマ制約付き出力に対応している場合は、採用前に対象モデルとエンドポイントの組み合わせでその機能を検証してください。今回のプロンプトのみのテストでは、その機能を検証していません。

import json

def validate_order(text):
    value = json.loads(text)  # Strict: intentionally rejects code fences.
    expected = {"order_id", "quantity", "delivery_date", "currency"}
    if not isinstance(value, dict) or set(value) != expected:
        raise ValueError("Unexpected object shape")
    if not isinstance(value["order_id"], str):
        raise ValueError("order_id must be a string")
    if type(value["quantity"]) is not int:
        raise ValueError("quantity must be an integer")
    # Fixture-specific assertions; replace with production business rules.
    if value != {"order_id": "BX-71", "quantity": 12,
                 "delivery_date": None, "currency": "EUR"}:
        raise ValueError("Fixture facts do not match")
    return value

この合成フィクスチャでは、値が完全に一致するかを検証するのが適切です。本番環境のバリデーターには、使用可能な通貨値、妥当な日付、レコードIDなどの業務ルールも必要です。すべての顧客レコードをBX-71と比較するわけにはいきません。

失敗したレコードを失わずに移行する

モデルIDは明示的な設定値として保持し、置き換え先が代表的な評価に合格するまで元のモデルを残してください。入力ごとに、安定したレコードID、プロンプトのバージョン、モデルID、試行回数、返された使用量、検証ステータス、出力を記録します。バッチから行を落とすのではなく、エラーもレコードとして保存してください。

よくあるケースと境界ケースを含む、小規模なラベル付きデータセットから始めます。日付の欠落、矛盾した情報、未知のカテゴリ、空の入力、極端に長いテキスト、入力内に埋め込まれた指示などが境界ケースに当たります。入力文書はデータとして扱ってください。抽出指示を上書きしたり、任意のツールを選択したりできるようにしてはいけません。

意味上の受け入れ条件と、JSONの構文・形式を分けて比較してください。展開範囲を広げる前に、結果の不一致を確認します。限定的なロールアウト中は、管理されたフォールバックとして旧ルートを維持し、再試行回数に上限を設け、重複処理を追跡してください。リクエストがタイムアウトしても、プロバイダーに到達している可能性があります。使用量が発生しなかったと思い込まないでください。

分類では、許可されたラベルに当てはまらない場合の処理を決めてください。要約では、省略できる事実を定義します。抽出では、曖昧なフィールドをnullにするのか、人による確認に回すのかを決めます。こうした判断は、モデル文字列だけを変更するよりも、アプリケーションの正確性に大きく影響することがよくあります。

Claude Codeも使っている場合は、curlとクライアントの診断ガイドを使って接続を別途検証してください。テキストAPIが成功しても、コーディングクライアントのツールや設定が正しいとは限りません。