AIを制作に使うとき、毎回いちばん大きなモデルへ仕事を投げる必要はあるのでしょうか。文章の分類、仕様からの項目抽出、短い修正案づくりには、範囲を絞った依頼で十分な場面もあります。そこで候補になるのが、2026年10月7日に発表されたClaude Haiku 5.5です。
注目点は「安いAIが出た」で終わりません。API料金はプロンプトの長さで変わり、考える深さの設定も結果に影響します。この記事では公式資料をもとに変更点を整理し、Web制作のFAQ整理を例に、使い分け、試し方、費用の見積もりまで説明します。情報確認日は2026年10月8日です。
1．Haiku 5.5で何が変わったのか
Anthropicは10月7日の発表で、Haiku 5.5を大量の短い処理や費用を抑えたい仕事向けのモデルと位置づけました。要約、分類、情報の抽出などが想定用途です。複雑なエージェント型のコーディングには、引き続きSonnet・Opusが適した選択肢とも説明しています。公式：Haiku 5.5発表
公式仕様では、コンテキストウィンドウは100万トークン、最大出力は12万8,000トークン。入力はテキストと画像、出力はテキストです。Claude APIのモデルIDは claude-haiku-5-5 です。公式：モデル仕様
コンテキストウィンドウは、モデルが一度に扱える情報量の枠です。ただし、枠が大きいことと、長い資料をいつでも低料金で処理できることは別です。入力の詰め込み方によって費用が変わるため、仕様表の「100万」だけで運用を決めない方がよいでしょう。
また、発表ページのベンチマークは、指定された評価課題での結果です。自分の問い合わせ文を正しく分類できるか、見出し案がブランドに合うかは、手元の課題で確かめる必要があります。本記事ではHaiku 5.5の応答速度や生成品質を実測していません。後半の課題と振り分け方は、試すための独自提案です。
2．料金は「10万トークン以下」と「超過」で分かれる
以下はClaude APIの通常の入力・出力料金です。100万トークンあたりの米ドル価格で、月額のClaudeアプリ料金とは異なります。Haiku 5.5はプロンプトが10万トークンを超えると、入力と出力の両方に高い単価が適用されます。公式：API料金
| モデル／条件 | 入力・100万トークンあたり | 出力・100万トークンあたり |
|---|---|---|
| Haiku 5.5・プロンプト10万以下 | $0.10 | $0.50 |
| Haiku 5.5・プロンプト10万超 | $0.50 | $2.50 |
| Haiku 4.5・比較用 | $1.00 | $5.00 |
出典は上記の公式料金表。Haiku 5.5の境界条件はモデル別の料金説明でも確認できます。表はキャッシュ、バッチ、追加ツールなどを含めない基本単価です。
ここで注意したいのは、長い依頼でも出力が短ければ安い、とは限らないことです。Web制作で「全ページの文章、過去の会話、長い仕様書を毎回添える」と、返答が数行でも入力が膨らみます。依頼ごとに必要な材料を選ぶことが、料金の見積もりにつながります。
公式の移行ガイドは、Haiku 4.5とはトークンの数え方が変わり、同じ文章でもカウントが増えると説明しています。旧モデルで測った入力数や出力上限を、そのまま流用せず、Haiku 5.5で数え直します。公式：移行時のトークン再計算
「前のモデルで9万だったから境界内」とは決めず、使用するモデルの計数結果を見る。文字数からトークン数へ一律に換算せず、実際の入力に、指示や履歴がどれだけ含まれるかも確認してください。
3．1件の単価より、修正まで含む費用を見る
基本の見積もりは、入力トークン数×入力単価と、出力トークン数×出力単価を足します。仮に1回の入力が2,000、課金対象の出力が500トークンで、低い料金帯の通常APIリクエストなら、計算は次のとおりです。
2,000÷1,000,000×$0.10 ＋ 500÷1,000,000×$0.50 ＝ $0.00045
同じ条件で1,000回なら$0.45です。これは単価からの仮定の計算であり、実際にFAQ整理を1,000回実行した請求額ではありません。キャッシュ・バッチ割引、追加ツール料金、税、地域条件などは含めていません。基本単価と追加料金の扱いは公式料金表を確認してください。掲載した計算はPythonのDecimalで確認しました。
本番では、合格した成果物までの呼び出し回数と、人が直した時間も記録します。たとえば初回の分類に誤りがあれば、追加依頼と再確認が発生します。最初の応答だけ安くても、何度もやり直す工程では、その利点が小さくなる可能性があります。
比較の単位を「1回の呼び出し」から「採用できた1件」へ変えると、判断が具体的になります。人の確認を除外したAPI代だけの比較と、確認まで含めた制作工程の比較は、別々に残すと読み違いを防げます。
4．FAQ整理を、小さな仕事に分けて任せる
最初の課題として、架空のWebデザイン講座サイトに届いたFAQ素材を整理する例を考えます。「FAQページを完成させて」ではなく、既存の回答をカテゴリへ分け、足りない情報を見つけるところまでに絞ります。
| 作業 | 最初に試す担当 | 合格の目安 |
|---|---|---|
| 質問を指定カテゴリに分ける | Haiku 5.5候補 | カテゴリが許可した値だけで、理由が素材に沿う |
| 文章から申込方法や条件を抜き出す | Haiku 5.5候補 | 素材にない条件を作らず、根拠の箇所がある |
| 複数の回答の矛盾を解く | 人・必要に応じて別モデル | 正式な条件を確定してから回答を直す |
| FAQ全体の順番と訴求を決める | 人・必要に応じてSonnet等 | 想定読者の迷いとページの目的を説明できる |
この表は製品が保証する担当分けではなく、本記事の運用案です。「小さなモデルだから単純な仕事しかできない」と決めつけるのではなく、入力と合格条件を限定して比較できる状態を作ります。
カテゴリは、たとえば「学習内容」「受講条件」「申込手続き」「判断保留」の四つ。学習開始時期と申込方法を同時に尋ねる質問は、どちらを優先するかのルールが必要です。「一番それらしいカテゴリを選んで」だけでは、人によっても正解が変わります。
先に、複数の用件がある場合は判断保留にする、素材に答えがなければ補わない、と決めます。AIの失敗をモデルの性能だけに帰さず、曖昧な分類ルールも点検できます。
5．同じ素材で試せるプロンプトとAPI設定例
次の指示文は本記事の作成例です。自分が公開してよい架空データや、検証用の素材に置き換えて試してください。実際のAI生成結果は掲載していません。
次のFAQ素材を整理してください。カテゴリは「学習内容」「受講条件」「申込手続き」「判断保留」だけを使います。複数の用件が同程度に含まれる質問、判断材料が不足する質問は「判断保留」にしてください。各項目についてid、category、evidence、missingを返してください。evidenceは分類の根拠になる素材の短い箇所、missingは不足情報です。質問への新しい回答は作らず、料金・日程・保証を補わないでください。素材：［id付きの質問と既存回答を貼る］。
Haiku 5.5には、考える深さを調整するeffortがあります。Claude APIの既定値はmedium。公式は、多くの仕事はmediumから試し、短い単純な大量処理にはlowを候補にするとしています。ただしlowでは、長い依頼で検索や確認を飛ばす傾向への注意があります。effortは厳密なトークン予算ではありません。公式：effort設定
まずmediumで基準を作り、同じ素材・指示でlowと比較します。APIを使う人向けに、Messages APIへ渡すリクエスト本文の形を示します。認証やHTTP送信部分は省略しています。
{
"model": "claude-haiku-5-5",
"max_tokens": 4096,
"thinking": {"type": "adaptive"},
"output_config": {"effort": "medium"},
"messages": [
{
"role": "user",
"content": "次のFAQ質問を分類。カテゴリは学習内容・受講条件・申込手続き・判断保留。複数用件や根拠不足は判断保留。idとcategoryと短い根拠のみ返す。q01: 初心者でも受講できますか？ q02: 申込フォームはどこですか？ q03: いつから学べて、どう申し込めますか？"
}
]
}これは公式の移行ガイドのリクエスト形式を参考にした独自の例です。JSON構文はローカルで検証済みですが、API送信とモデル応答は未検証です。4096は試行用の上限で、最適値や完了保証ではありません。thinkingも上限を消費するため、短い上限で回答が途切れたら設定を見直します。
なお、この例は出力をJSONスキーマで強制する設定を含みません。「項目名を指示した」ことと、プログラムが必ず読める形式を保証したことは分けて扱います。最初の検証では返答に必要な項目が揃ったか、人が確認してください。
6．20件の小さな評価セットで、使い分けを決める
分類を試すなら、20件程度の小さな素材を作り、先に人が基準ラベルを付けます。ここでの20件は、実験を始めるための提案で、性能を一般化できる十分な標本数という意味ではありません。
素材には、簡単な単一質問、用件が二つある質問、回答が欠けた質問を混ぜます。通常例だけでなく、判断保留にするべき例を入れると、都合のよい解釈で埋める返答を見つけやすくなります。
- 指示文、素材、基準ラベルを固定し、変更する前に版を保存します。
- mediumとlowを、同じ条件の新しい試行で比較します。モデル名と設定を結果に付けます。
- カテゴリの一致だけでなく、判断保留の扱い、根拠の有無、禁止した補完がないかを見ます。
- 実際のトークン数、開始から返答までの時間、人の修正時間を記録します。
- 誤りの原因を、分類ルールの曖昧さ、素材不足、モデルの誤判断へ分け、直した条件で再評価します。
たとえば正解数が似ていても、片方が「不明な受講条件を作った」なら、その誤りは軽く扱えません。一方、「学習内容」と「受講条件」の境界が人の基準でも不明確なら、モデルを変える前に分類ルールを直す余地があります。
評価に使った20件だけを何度も調整すると、その素材に合わせた指示になりがちです。最後は別の質問を少数追加し、同じルールで扱えるか確認します。採用を決める基準は、自分の仕事で許容できる誤りと確認負担です。
7．既存APIを移すなら、モデル名だけを変えない
Haiku 4.5から移行する場合は、呼び出し側も確認します。公式ガイドでは、従来のthinkingのbudget_tokens指定、サンプリング設定、assistantで終えるprefillなどに変更があります。また、回答はcontentの先頭と決めず、typeがtextのブロックを選びます。公式：API移行チェックリスト
本文のJSON例はadaptive thinkingを使い、temperature・top_p・top_kを設定していません。既存コードにこれらが埋め込まれているなら、モデルIDの置き換えだけで正常に動くと判断せず、公式ガイドの該当項目を確認します。
さらに、「結果が返った」と「必要な確認を終えた」は別です。Haiku向けの公式プロンプト資料も、検索が必要な場面、早期終了、コードの確認省略などを点検するパターンを説明しています。公式：Haiku 5.5の指示の工夫
Web制作なら、文章分類の合格条件と、コード修正の合格条件を同じにしないことが大切です。コードであれば、変更箇所が実際に動く確認を別途用意します。短い返答や「完了」という言葉だけで、制作物を採用しない手順にしてください。
8．今日の一歩は、繰り返している一つの仕事を選ぶこと
Haiku 5.5を試す価値は、制作の全部を一度に任せることより、繰り返し発生する小さな工程を切り出せる点にあります。FAQ分類、仕様からの項目抽出、短い文章の整形など、入力と合格条件を説明できる仕事を一つ選びます。
その仕事でmediumとlowを比較し、採用できた結果までの費用と確認時間を見る。曖昧な例は人や別モデルへ渡し、必要な資料だけを添える。こうした使い分けが成立するかを測ってから、量を増やしてください。
「安いから大量に使う」より、「合格させられる工程を、必要な量だけ回す」。新モデルのニュースを、制作の判断へつなぐための第一歩です。
情報確認：2026年10月8日。料金はClaude APIの通常単価を説明したもので、契約・追加機能を含む請求額の保証ではありません。図解は説明用に制作し、製品画面やベンチマークを再現していません。プロンプトとAPI設定例の実行結果は未検証です。