10倍高くても、私がHaikuを選んだ理由

最近、文脈に応じた語釈を返す機能のために、モデルを選定する機会があった。ユーザーが英単語を選択すると、その単語が含まれる文と段落を踏まえ、1〜8個の漢字からなる中国語の語釈だけを返す機能だ。

一見すると軽いタスクだが、実際にテストしてみるとそう単純ではなかった。技術的な文脈の race は「竞争」ではなく「竞态条件」と訳すべきで、メッセージングシステムの Kafka も単に「卡夫卡」と音訳するだけでは不十分だ。正確に意味を判断しつつ、出力は十分に短く、厳密なJSON形式に従い、しかもユーザーを長く待たせない必要がある。

当初、最有力候補はGemini 2.5 Flash Liteだった。入力と出力の料金は、それぞれ100万tokenあたり0.10ドルと0.40ドル。1回のリクエストにつき入力200〜400 token、出力10〜15 tokenとして試算すると、1,000回の呼び出しにかかる費用はわずか約0.021ドルだ。

この価格は非常に魅力的だった。しかしユースケースを改めて整理し、選定基準を精度、安定性、速度、そして最後にコストの順に置いた。数十ミリ秒の差をユーザーが感じるとは限らないが、誤った語釈はユーザーに直接影響する。

安価なモデルも決して悪くない

事前テストでのGemini 2.5 Flash Liteの出来はよかった。63回の呼び出しでHTTPエラーはなく、結果はすべてパースできた。ルーティングを固定した後の15件のサンプルでは14件が許容範囲で、応答時間の中央値は約1.2秒だった。

問題は、promptとproviderの影響を受けやすいことだ。

「辞書的な基本義」だけを返すよう求めると、技術的な文脈の race を「竞争」と訳した。法律、技術、学術の文脈では各分野で一般的な用語を使うよう明示して、ようやく安定して「竞态」を出力するようになった。同じモデルでも、異なるprovider経由で呼び出すと、構造化出力の安定性が大きく変わることもある。

ここで、評価すべき対象はモデル名ひとつではなく、次の構成全体なのだと気づいた。

モデル × provider × prompt × パラメータ × 出力検証

どれかひとつが変わるだけでも、結果は変わりうる。

4モデルの実測結果

続いて、同じ15件のサンプルを使い、4つの候補モデルを横並びでテストした。テストには多義語、定型表現、技術用語、比喩表現を含めた。すべてのモデルで同じpromptを使い、厳密なJSONを返すよう求めた。

モデル	JSON準拠	レイテンシ中央値	主な問題
Claude Haiku 4.5	15/15	861ms	一部の表現がやや不正確
GPT-4.1 Mini	15/15	817ms	重要なフレーズで意味上の誤り
GPT-5.4 Mini	15/15	966ms	技術上の固有名詞を音訳しただけ
Gemini 3.7 Flash	10/15	937ms	構造化出力に複数回失敗

GPT-4.1 Miniは最速で、レイテンシ中央値はHaikuより44ms短かった。しかし、bears directly on を「具有」と訳した。GPT-5.4 Miniは形式には完全に準拠していたが、技術的な文脈の Kafka をそのまま「卡夫卡」と訳した。Gemini 3.7 Flashは一部のケースではよい回答を返したものの、有効な構造化結果を何度も生成できなかった。

この結果からも、JSONが正しいだけではタスクを完了したことにならないと分かる。Schemaで保証できるのはプログラムがパースできることまでで、ユーザーを誤解させないことまでは保証できない。

Haikuも完璧ではない。forked を「分支」と訳したが、「分叉」のほうが正確だった。それでもテスト全体を通して、原意を明らかに変えるような誤りはなく、15回の出力はすべて形式要件を満たし、応答速度も十分だった。

価格が10倍でも、コストまで10倍とは限らない

Gemini 2.5 Flash Liteと比べると、Haikuのtoken単価は約10倍高い。倍率だけを見れば大きな差だが、絶対額に直すと、Haikuは1,000回の呼び出しあたり約0.25〜0.48ドルだった。

この機能はユーザーが能動的に起動するため、呼び出し頻度は限られ、出力も短い。比較するときは、月々の増分費用に換算し、結果が安定することでどれだけ誤りを減らせるかを見積もるべきだ。

次のような単純な式で考えられる。

月間増分コスト = 月間呼び出し回数 × 2モデル間の1回あたりのコスト差

高価なモデルによって減らせると見込まれるエラーコストがこの増分を上回るなら、そのモデルを選ぶほうがむしろ経済的だ。エラーコストには再試行や人手による修正だけでなく、内容を誤解したユーザーが機能への信頼を失うことも含まれる。

Anthropicの評価手法でも、タスクへの忠実度、一貫性、レイテンシ、呼び出し1回あたりのコスト、利用頻度を含む多面的な評価が推奨されている。一方、DoiTが提唱するCost Per Taskフレームワークは、安価なモデルでも再試行が増えたり失敗しやすかったりすれば、1件のタスクを完了する総コストはかえって高くなりうると強調している。

これらの資料は、同種のあらゆるタスクでHaikuが優れていることを証明するものではない。最終的な判断は、あくまで今回の実際の入力、現在の呼び出し頻度、許容できるエラーリスクに基づいている。

最終的な選択

最終的にClaude Haiku 4.5を選び、providerを固定し、ランダム性を無効にし、出力token数を制限したうえで、JSON Schemaとアプリケーション層のルールを併用して結果を検証することにした。

Haikuは今回のテストですべての指標を制したわけではない。それでも15回すべてが形式要件を満たし、原意を明らかに変える誤りはなく、レイテンシ中央値は861msだった。現在の呼び出し量なら追加費用も許容できる。

リリース後も、意味上の誤り率、レイテンシ、月間呼び出し回数を記録する。利用量や誤りの分布が変われば、同じ基準でテストをやり直す。今回の選択が責任を持つ範囲は、現在のタスクとデータまでである。