去年、AIで自動化したい仕事を試算して、単価が合わないと見送った会社があると思います。問い合わせメールの分類、日報の要約、商品説明の体裁を統一する作業。1件あたりの判断は軽いが、件数が多い仕事です。その試算の前提が、2026年10月に変わりました。

Anthropicが10月7日に公開した小型モデルClaude Haiku 5.5の単価は、プロンプトが10万トークン以下の場合、100万トークンあたり入力0.10ドル、出力0.50ドルです。前世代のHaiku 4.5は入力1ドル、出力5ドルでした。単価は10分の1です。この記事は、去年の試算を、去年の件数と資料を使って作り直す手順を書きます。読者は、自社の定型処理の自動化を検討した経験がある経営者と、情報システムや業務改善の担当者です。

結論を先に書きます。

  1. 去年の試算は、件数と入力の資料をそのままに、トークン数を測り直し、単価を差し替えて作り直せます。 単価は公式の料金表にあり、この記事に確認日つきで並べました。トークン数を測り直すのは、Haiku 5.5のトークナイザーが前世代と違うからです
  2. 試算の順番は、1回の要求に含める入力全体のトークン数を測るところからです。 要求のプロンプトが10万トークンを超えると単価が5倍になるので、ここを先に確かめます
  3. 単価が下がっても減らない費用があります。 人が結果を確かめる時間と、確かめられない判断を安いモデルに任せたときの手戻りです。安いモデルで足りる仕事の線引きを、担当者が確認した正解と比べる最初の100件で決めます

2026年10月30日時点の単価

Anthropicの料金ページで、当社が2026年10月30日に確認した数字です。単位は米ドル、100万トークンあたりです。

Claudeの主なモデルの100万トークンあたりの入力単価を棒グラフで並べた図。Haiku 4.5が1ドル、Haiku 5.5が0.10ドル、Haiku 5.5の10万トークン超が0.50ドル、Sonnet 5.5が2ドル、Opus 5.5が4ドル

モデル 入力 出力 Batch API（入力／出力）
Claude Haiku 5.5（プロンプトが10万トークン以下） 0.10 0.50 0.05／0.25
Claude Haiku 5.5（プロンプトが10万トークン超） 0.50 2.50 0.25／1.25
Claude Haiku 4.5 1.00 5.00 0.50／2.50
Claude Sonnet 5.5 2.00 10.00 1.00／5.00
Claude Opus 5.5 4.00 20.00 2.00／10.00

読み方を3つ書きます。

Haiku 5.5だけ、プロンプトの長さで単価が変わります。 1回の要求のプロンプトが10万トークンを超えると、入力も出力も5倍になります。料金ページの説明では、プロンプトの長さはキャッシュの読み書きを含む入力トークンの合計で数え、要求ごとに判定されます。対象のメール本文だけでなく、共通の指示や参照させる資料も含めた、要求に入れる入力の全体です。Sonnet 5.5とOpus 5.5には、この区切りがありません。

Batch APIは入力も出力も半額です。 結果をすぐに返す必要がない処理を、まとめて非同期で流す仕組みです。夜間に日報を要約する、月初に先月分の問い合わせを分類する、といった仕事に向いています。Haiku 5.5をBatch APIで使うと、プロンプトが10万トークン以下の場合で、入力0.05ドル、出力0.25ドルです。

Anthropicの発表では、Haiku 4.5と比べて同じ作業のコストが平均で約75%下がる、としています。 単価は10分の1なのに75%なのは、要求の長さの分布と、新しいトークナイザーで1タスクあたりのトークン数が増えることを含めた同社の試算だからです。10万トークン超の要求では、単価の削減率は50%です。Claude Platformのモデル説明では、同じ文章がHaiku 4.5より約30%多いトークンになると書かれています。試算では、単価の10分の1をそのまま使わず、候補のモデルでトークン数を測り直します。

試算をやり直す5つの手順

去年見送った自動化の試算をやり直す5つの手順を、担当者、情シス、経営者の3つのレーンで示した図。1件のトークン数を測る、月の件数を数える、モデル別に計算する、最初の100件を上位モデルと並べる、広げる範囲を決める、の順に進む

1. 1件のトークン数を測り直す。 去年の試算で使った入力の資料を、そのまま使います。問い合わせメール1通と、それに付ける分類と担当の案。日報1日分と、その要約。実物を10件、候補のモデルごとにAPIに流して、使った入力と出力のトークン数を記録します。トークナイザーがモデルで違うので、去年のトークン数は流用せず、測り直します。Anthropicの料金ページには、トークン数を数えるAPIの案内もあります。ここで確かめるのは、1回の要求に入れる入力の全体が10万トークンを超えないことです。メール本文だけでなく、共通の指示や、分類の基準として参照させる資料も含めて数えます。超える設計になるのは、過去の例を毎回まとめてプロンプトに入れるような作りのときです。

2. 月の件数を数える。 去年の試算の件数をそのまま使います。件数が変わっていれば、直近3か月の実数で置き換えます。

3. モデル別に計算する。 月額は、件数×（1件の入力トークン数×入力単価＋1件の出力トークン数×出力単価）÷1,000,000です。単価が100万トークンあたりなので、最後に100万で割ります。Haiku 5.5、Haiku 5.5のBatch API、Sonnet 5.5、の3通りを並べます。去年Haiku 4.5で試算した会社なら、去年の数字も横に置きます。

4. 最初の100件を、担当者が確認した正解と並べる。 単価の比較だけで本番に広げません。同じ100件をHaiku 5.5とSonnet 5.5で処理し、担当者が確認した正解と比べて、違う答えになった件数と、業務上の問題が出る件数を数えます。上位モデルも間違えるので、上位モデルの答えを正解にはしません。100件に入りにくい例外の事例は、別に足して試します。ここで、安いモデルで足りる仕事と、そうでない仕事の線が見えます。

5. 広げる範囲を決める。 100件と例外事例の結果で、Haiku 5.5で足りる種類の仕事はHaiku 5.5に、足りない種類はSonnet 5.5に、確かめる人が要る種類は人に残します。間違いの影響が大きい仕事は、許容できる誤りの水準を決めてから、件数を増やして追加で評価します。この振り分けを決めるのは、業務の責任者です。

当社の試算例。倍率で書きます

当社でも、去年の秋に見送った処理があります。社内に届く問い合わせと、自動で集めている記事の候補を、決めた分類に振り分ける処理です。件数は多いが、1件あたりの判断は軽い。去年は、上位モデルで全件を処理する前提の試算で、月の費用が見合わないと判断しました。

去年の試算に使った単価の記録は、今の料金表とは別の体系なので、ここでは今の料金表の数字で比べます。入力2ドル・出力10ドルの上位モデルで全件を処理する費用を1として、同じトークン数で単価だけ差し替えると、次の倍率になります。単価の比なので、入力と出力の比率が変わっても倍率は同じです。

前提（プロンプトが10万トークン以下、同じトークン数） 倍率
入力2ドル・出力10ドルの上位モデルで全件（通常処理） 1
Haiku 5.5で全件（通常処理） 0.05
Haiku 5.5で全件（Batch API） 0.025

別の条件も1つ書きます。1回の要求のプロンプトが10万トークンを超える設計のままHaiku 5.5に切り替えると、適用されるのは入力0.50ドル・出力2.50ドルのほうで、倍率は0.25です。

API料金が主な理由で見送った仕事は、確認と修正の費用も含めて、再検討できる水準になりました。ただし、下がり方は自社の去年の前提で変わります。去年Haiku 4.5で試算していた会社なら、単価の比は10分の1、Batch APIで20分の1です。トークン数も測り直すと変わるので、この表の倍率ではなく、手順3で自社の数字を出してください。

もう1つ、当社の例で分かったことがあります。去年の設計は、分類の基準を説明するために、過去の分類済みの例を毎回まとめてプロンプトに入れていました。その作りだと、1回の要求のプロンプトが10万トークンを超え、Haiku 5.5では5倍の単価のほうが適用されます。例を絞って10万トークン以下に収めると、適用される単価が5分の1になります。トークン数自体も減るので、費用は短縮後のトークン数で計算し直します。去年の設計を見直す価値があるのは、ここです。

安いモデルで足りる仕事の線引き

手順4で100件を並べたあと、どの仕事をHaiku 5.5に任せるかを決める軸を、当社は2つにしています。

安いモデルで足りる仕事を決める2軸の図。横軸は答えが正しいかを機械的に確かめられるか、縦軸は間違いが業務に及ぼす影響の大きさ

横軸は、答えが正しいかを機械的に確かめられるか。分類なら、決めた分類の一覧に入っているか、要約なら、元の文に無い固有名詞や数字が入っていないか、はプログラムで確かめられます。ただし、これで確かめられるのは形式と一部の誤りです。分類先として正しいか、要約が意味を取り違えていないかは、正解のデータか担当者の確認で評価します。機械で確かめられる範囲が広い仕事ほど、右に置きます。縦軸は、間違いが業務に及ぼす影響の大きさ。問い合わせの担当を間違えても、担当者が気づいて回せば済みます。見積もりの金額を間違えると、取引先に届きます。

  • 確かめられて、影響が小さい仕事は、Haiku 5.5に任せます。手順4の100件で違いが出ても、機械の確認と抜き取りの確認で拾います
  • 確かめられて、影響が大きい仕事は、Haiku 5.5で処理したあとに機械の確認を必ず通し、確認で落ちたものと、機械で確かめられない部分をSonnet 5.5か人に回します
  • 確かめられず、影響が小さい仕事は、Haiku 5.5で始めて、抜き取りで人が読みます
  • 確かめられず、影響が大きい仕事は、安いモデルに任せません。上位モデルで処理した上で、人が確かめます

10月10日の週刊 海外AIウォッチ #14で紹介したRedditのコメントには、「難しさではなく、検証できるかで振り分ける」という意見がありました。grepやテストで機械的に確かめられる仕事は安いモデルへ、確かめられない判断は高いモデルへ。当社の2軸は、その整理に影響の大きさを足したものです。

注意点

単価が下がっても、人が確かめる時間は減りません。 自動化の費用は、APIの請求額だけではありません。結果を確かめる人の時間、間違いを直す時間、分類の基準を更新する時間が、単価と関係なくかかります。世田谷区の事例で書いたとおり、削減した時間と、確認に増えた時間は、同じ表で数えます。

10万トークンの区切りは、要求ごとに判定されます。 100件のうち1件だけ長い要求があれば、その1件だけが5倍の単価です。平均で10万トークン以下でも、長い要求が混ざる設計なら、その分を見込みます。

為替と単価の改定を試算に書き添えます。 単価は米ドルで、改定されることがあります。試算には、確認日と、確認したページを書いておきます。半年後に見直すとき、どの前提が変わったかが分かります。

effortの設定で、同じモデルでも使うトークン数が変わります。 Haiku 5.5には、low・medium・high・xhigh・maxの5段階のeffort設定があり、高い設定ではトークンの消費が増える傾向があります。品質がどれだけ改善するかは仕事によるので、設定ごとに品質の改善幅と費用を実測します。試算で使った設定を記録し、本番で変えたら試算も直します。

全体の費用を誰が見るかを、先に決めます。 1つの処理の試算が合っても、社内の複数の処理が同じAPIキーで動けば、合計は別の話です。AIの費用を誰が見るかに、経営・情報システム・現場の3つの役を書きました。

KOIYALの見解

単価が10分の1になった、という知らせの受け止め方は、2つあると当社は考えています。1つは、AIが安くなった、という受け止め方。もう1つは、去年の自分たちの試算がまだ使える、という受け止め方です。当社は後者を勧めます。去年、件数を数え、入力の資料を用意し、見合わないと判断した会社は、その材料を持っています。トークン数を測り直し、単価の行を差し替えれば、今日の判断ができます。

インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）の文脈で言うと、自社で試算の表を持っていることが、この記事の前提です。試算を外注した場合も、計算式と前提の条件を自社で確かめて更新できる形で受け取っておきます。そうなっていれば、単価が変わった日に、自分で差し替えられます。

読者の会社が自社でできるようになることを1つ挙げるなら、1件のトークン数と月の件数を、自社で測って表に持つことです。この2つの数字と、測るのに使った入力の資料があれば、モデルが変わっても、単価が変わっても、試算は自社で作り直せます。何を自動化するか、どの仕事を安いモデルに任せるかを決めるのは、業務の責任者です。表は、その判断の材料です。

次の行動

  1. 去年見送った自動化の試算と、そのとき使った入力の資料を探す。無ければ、見送った仕事を1つ選び、実物を10件用意する
  2. 10件を候補のモデルごとにAPIに流して、1回の要求に入れる入力全体と出力のトークン数を測る。10万トークンを超えていないかを見る
  3. 月の件数と単価の表で、Haiku 5.5・Batch API・Sonnet 5.5の3通りを計算し、去年の数字と並べる

3通りの数字が出たら、次は100件を担当者が確認した正解と並べる段階です。FDE型支援では、社外の推進チームが社内に入り、100件の比較から本番の振り分けまでを一緒に作り、運用を社員に移して離れます。お問い合わせの本文に、自動化したい仕事と月の件数を書いていただければ、初回の前に試算の表の型をお持ちします。

参考