古い単価表で見積もりを出してしまった夜
開発中のアプリに Claude API を組み込む見積もりを、以前の単価表をそのまま使って出したことがありました。数日後に公式の料金ページを開き直したところ、モデルの顔ぶれも単価も入れ替わっていて、手が止まりました。結果は芳しくありませんでした。見積もりの桁そのものが、一世代ぶんずれていたのです。
最初にお伝えしたいのは、API の料金は「覚えるもの」ではなく「見るたびに確かめるもの」 だということです。この記事は、2026年10月時点の公式料金表を横に置いて、計算し直した記録です。単価は今後も動きますので、最後に必ず公式ページと照らしていただければ幸いです。
現行モデルの料金一覧（2026年10月時点）
単価は100万トークンあたりの USD です。まず、いま新しく使い始めるときに候補になる3つを並べます。
| モデル | 入力 | 出力 | 位置づけ |
|---|---|---|---|
| Claude Opus 5.5 | $4 | $20 | 複雑な推論・長い作業 |
| Claude Sonnet 5.5 | $2 | $10 | 日常のコーディング・文章 |
| Claude Haiku 5.5 | $0.10 | $0.50 | 分類・軽い処理（プロンプト10万トークン以下） |
Haiku 5.5 だけは、プロンプトの長さで単価が二段になります。10万トークンを超えると、入力 $0.50・出力 $2.50 です。しかも、この「長さ」にはキャッシュの読み書きぶんも含まれます。一部がキャッシュに当たっていても、リクエスト全体が高いほうの単価になる点は、見落としやすいところです。
上位には Fable 5.1 と Mythos 5.1（入力 $10・出力 $50）もあります。ここでは一般的な開発の出発点として、上の3つに絞ります。
旧世代も料金表に残っています。Sonnet 4.6 は入力 $3・出力 $15、Haiku 4.5 は入力 $1・出力 $5 です。今から新規に作るなら、同じ価格帯でも世代の新しいほうを先に検討する価値があります。
日本語で効いてくるトークナイザの差
もう一点、単価表だけでは見えない差があります。Claude 4.7 以降のモデルは新しいトークナイザを使っており、同じ文章でトークン数がおよそ30%増えると公式に案内されています。Sonnet 4.6 以前は従来のトークナイザです。
つまり、「単価が下がったから費用も下がる」とは限りません。単価が3割安くなっても、トークン数が3割増えれば、差し引きはほぼ変わらないこともあります。日本語の文章は、もともと1文字あたり1〜3トークンほど消費しますので、見積もりは実際の入力で測った値で出すのが確実です。
トークンの数え方と1リクエストの費用
測り方はとても単純で、レスポンスの usage を見るだけです。
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=1024,
messages=[
{"role": "user", "content": "Pythonでフィボナッチ数列を実装してください"}
],
)
print(f"入力トークン: {response.usage.input_tokens}")
print(f"出力トークン: {response.usage.output_tokens}")
# 出力例（実際の値はプロンプトとモデルで変わります）:
# 入力トークン: 28
# 出力トークン: 312この例を Sonnet 5.5 で計算します。入力 28 × ($2 / 1,000,000) と出力 312 × ($10 / 1,000,000) を足して、約 $0.003（1円に届かない額）です。1回ぶんは小さな数字ですが、本当に効いてくるのは、これが毎日、何万回と積み重なるときです。
利用シナリオ別の費用試算
3つの仮定で、月額を計算してみました。トークン数はあくまで仮定ですので、ご自身のログの値に置き換えてお読みください。
シナリオ1: 問い合わせの分類（月間10,000リクエスト）
Haiku 5.5 で、1回あたり入力500・出力300トークンと仮定します。入力 5,000,000 トークン × $0.10 = $0.50、出力 3,000,000 トークン × $0.50 = $1.50 で、合計 約 $2 です。
シナリオ2: コードレビュー（月間1,000回）
Sonnet 5.5 で、1回あたり入力3,000・出力1,500トークンと仮定します。入力 $6 + 出力 $15 で、合計 約 $21 です。
シナリオ3: 長いドキュメントの分析（月間100回）
Opus 5.5 で、1回あたり入力50,000・出力5,000トークンと仮定します。入力 $20 + 出力 $10 で、合計 約 $30 です。
三つを並べると、モデルの単価差よりも、「1回あたりの入力がどれだけ大きいか」のほうが月額を左右していることが見えてきます。
Batch API で 50% 引き
即答が要らない処理には、Batch API を使います。入力・出力ともに標準料金の50% で、処理は非同期です。たとえば Sonnet 5.5 なら、入力 $1・出力 $5 になります。
import anthropic
client = anthropic.Anthropic()
batch = client.messages.batches.create(
requests=[
{
"custom_id": "review-001",
"params": {
"model": "claude-sonnet-5-5",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "このコードをレビューしてください: def add(a, b): return a + b"}
],
},
},
{
"custom_id": "review-002",
"params": {
"model": "claude-sonnet-5-5",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "このSQLを最適化してください: SELECT * FROM users WHERE age > 20"}
],
},
},
]
)
print(f"Batch ID: {batch.id}")
print(f"Status: {batch.processing_status}")
# 出力例: Status: in_progress向いているのは、大量の翻訳や分類、定期レポート、データセットの一括分析です。ストアの説明文を多言語に直す作業のように、夜にまとめて投げて朝に受け取れる仕事とは相性が良いです。ただし、高速モード（Fast mode）は Batch API では使えません。
Prompt Caching で入力を大きく減らす
同じシステムプロンプトや共通の資料を何度も送るなら、Prompt Caching です。書き込みと読み取りで倍率が決まっています。
- 5分キャッシュの書き込み: 通常の入力の1.25倍
- 1時間キャッシュの書き込み: 通常の入力の2倍
- キャッシュの読み取り: 通常は0.1倍（Opus 5.5 と Sonnet 5.5 は0.05倍）
公式の説明どおり、5分キャッシュは1回読めば元が取れ、1時間キャッシュは2回読めば元が取れます。
import anthropic
client = anthropic.Anthropic()
response = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=1024,
system=[
{
"type": "text",
"text": "あなたは経験豊富なシニアエンジニアです。以下の規約に沿ってレビューしてください... (長い規約テキスト)",
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": "この関数をレビューしてください: ..."}],
)
print(f"入力トークン: {response.usage.input_tokens}")
print(f"キャッシュ作成: {response.usage.cache_creation_input_tokens}")
print(f"キャッシュ読取: {response.usage.cache_read_input_tokens}")
# 2回目以降の出力例:
# キャッシュ作成: 0
# キャッシュ読取: 20000具体的に計算します。20,000トークンの規約を付けて、Sonnet 5.5 を5分以内に100回呼ぶとします。
- キャッシュなし: 2,000,000 トークン × $2 = $4.00
- キャッシュあり: 書き込み 20,000 × $2.50 + 読み取り 99回ぶん 1,980,000 × $0.10 で 約 $0.25
規約の部分だけで見ると、約94%の削減です。なお、キャッシュは5分で切れますので、間隔が空く処理では1時間キャッシュを検討します。Batch API の割引とキャッシュの倍率は重ねて使えると、公式料金表に書かれています。
モデル選択の判断基準
選び方は、能力ではなくやり直しの回数で考えると迷いが減ります。
- Haiku 5.5: 分類、抽出、短い応答など、答えの形が決まっている処理。
- Sonnet 5.5: コーディング支援や文章生成など、品質と速度の両方が要る処理。多くの場合、最初の1本目はここです。
- Opus 5.5: 多段の推論や、長い作業を途中で破綻させたくない処理。
私の場合は、まず Sonnet 5.5 で試し、出力の質が足りないと感じた箇所だけ Opus 5.5 に切り替えています。逆に、毎回同じ形で返ってくる処理は、Haiku 5.5 に落とせないか一度は試す価値があります。
費用を抑える実装パターンは、Claude API コスト最適化プロダクションガイド で Batch API・Prompt Caching・Adaptive Thinking を組み合わせた形に踏み込んでいます。
全体を振り返って
料金は、モデルの選択、Batch API、Prompt Caching の3つの軸で下げられます。そして、その前提になる単価表のほうが、思っている以上の速さで入れ替わります。
見積もりの数字には、必ず日付と出典を添えるようにしています。 私はこの線引きにしてから、あとで桁がずれることがなくなりました。いま思えば、単価そのものより、確かめずに信じていた私の側に原因があったのかもしれません。まずは、ご自身のアプリのログから1リクエストあたりの入力・出力トークンを10件だけ拾い、公式の料金ページの単価で掛け算してみていただければと思います。