Token Count APIで日本語コンテンツの費用を事前に見積もる

Token Count APIで送信前に費用が分かる

count_tokensエンドポイントは、メッセージをClaudeに送る前に入力トークン数を無料で返します。日本語プロンプトは英語の「1トークン≈4文字」という目安が通用しにくいため、実際に数えないとコストが読めません。この記事では、count_tokensの結果にモデル別の単価と各種の倍率を掛けて、費用を見積もる手順を扱います。基本的なリクエストの組み立て方(ツール・画像・thinkingを含むケース)と各利用ティアのレート制限はcount_tokensで送信前にトークン数を数える方法とレート制限にあります。ここでは日本語コンテンツのコスト試算に絞ります。

前提条件

• Anthropic APIキー(platform.claude.com/settings/keysのAPI keysページで発行)
• 現行の全アクティブモデルがcount_tokensに対応
• カウント結果は見積もりです。実際にメッセージを送信したときのinput tokenと小さな幅でずれることがあります
• Anthropicが自動追加するシステム最適化用のトークンには課金されません。表示されるカウントに含まれていても、実際の請求は自分のコンテンツ分だけです

手順1: 日本語コンテンツのトークン数を数える

日本語ビジネス文書のような実際のコンテンツをsystemまたはmessagesに入れてリクエストします。返るのはinput_tokensの合計だけです。

import anthropic
 
client = anthropic.Anthropic()
 
with open("contract.txt", encoding="utf-8") as f:
    contract_text = f.read()
 
response = client.messages.count_tokens(
    model="claude-sonnet-5-5",
    system="あなたは契約書レビューの専門家です",
    messages=[{"role": "user", "content": contract_text}],
)
 
print(response.input_tokens)

SDKを組み込まずに手早く確認したいだけなら、CLIのant messages count-tokensでも同じ結果を得られます。長文の契約書・議事録・問い合わせメールなど、実際に送るテキストをそのまま渡すのが肝心です。漢字・ひらがな・カタカナが混ざる日本語は、英語の「4文字で1トークン」を当てはめると実測からずれやすく、サンプル文書での実測が前提になります。

手順2: モデル別の単価と掛け合わせてコストを算出する

input_tokensが分かれば、あとはモデルの単価(1 MTok = 100万トークンあたりの価格)を掛けるだけです。主要モデルの入力単価は次のとおりです。

Sonnet 5の$2 / $10は発売時に導入価格として案内され、2026年9月1日に$3 / $15へ上がる予定でした。この値上げは実施されず、$2 / $10がそのまま標準価格になっています。9月以降を前提にした古い資料の「$3」は読み替えが要ります。

同じ契約書1件でinput_tokensが18,000だった場合、Sonnet 5.5なら18,000 ÷ 1,000,000 × $2 = $0.036。Opus 5なら$0.09と、同じ入力でもモデル選びだけで2.5倍の差が出ます。出力トークンはこの時点では分かりません。count_tokensは入力専用のエンドポイントで、生成される返答の長さは実行してみないと確定しないため、出力コストはmax_tokensを上限とした見積もりに留めます。

サブスクリプションの料金はClaudeの料金プランにまとまっています。この記事の単価表はAPI従量課金のものです。

キャッシュ・バッチ・地域指定で単価が変わるケース

非同期でよい大量処理なら、Batch APIが入力・出力とも標準単価の50%引きになります。同じ文書処理をリアルタイムで回すかバッチに回すかで、見積もりの前提が変わります。

例えば、Sonnet 5.5でinput_tokensが18,000、出力がmax_tokensの上限4,000まで使い切ると仮定すると、リアルタイム処理の見積もりは18,000 ÷ 1,000,000 × $2 + 4,000 ÷ 1,000,000 × $10 = $0.076です。同じ処理をBatch APIに回すと$0.018 + $0.02 = $0.038とおよそ半額になります。実際の出力が短ければ、コストはさらに下がります。

Claude 4.6以降のモデルでinference_geoにUS限定推論を指定すると、入力・出力・キャッシュ書き込み・キャッシュ読み取りのすべてに1.1倍がかかります。この倍率はBatch APIの割引などと重なります。上のSonnet 5.5の入力18,000トークンなら、$0.036 × 1.1 = $0.0396です。

長文の日本語文書を1回で送る設計なら、Claude 4.6以降のモデルとClaude Mythos Previewが持つ1Mトークンのコンテキストウィンドウも見積もりに関わります。900kトークンのリクエストも9kトークンのリクエストと同じ単価で課金されるため、大きな文書だからといって単価自体が上がるわけではありません。プロンプトキャッシュとBatch APIの割引も、このロングコンテキスト全体に標準どおり適用されます。

ツール(関数呼び出し)を併用する場合は、toolsパラメータのスキーマ定義自体もトークンとして課金されます。toolsを付けると、ツール利用を有効にする追加のシステムプロンプトも加算されます。この分はOpus 5で286トークン(tool_choiceがautoかnoneのとき)、anyかtoolなら406トークンです。Sonnet 5は354トークン(anyかtoolなら474トークン)です。Opus 5.5とSonnet 5.5は286トークンで、anyかtoolの数値は料金ページの表に載っていません。旧トークナイザー側のHaiku 4.5は496トークン(anyかtoolなら588トークン)で、モデルごとに違います。count_tokensのリクエストには実際に使うtools定義も含めて数えないと、見積もりが少なめに出ます。

プロンプトキャッシュを使うと入力コストはどう変わるか

繰り返し同じ社内文書をコンテキストに含める設計なら、プロンプトキャッシュも試算に入れる価値があります。キャッシュ書き込みは標準入力の1.25倍(5分)または2倍(1時間)で、キャッシュヒットは標準入力の10%です。Opus 5.5とSonnet 5.5は5%、Fable 5.1 / Mythos 5.1は2.5%に下がります。5分キャッシュは1回の読み取りで、1時間キャッシュは2回の読み取りで、書き込みの上乗せ分を取り戻せます。

count_tokensはキャッシュの仕組みを通らず、リクエストにcache_controlを付けてもキャッシュは働きません。キャッシュ込みのコストは、input_tokensに上の倍率を手で掛けて出します。先の18,000トークンの契約書をSonnet 5.5で3回問い合わせる場合の入力コストは次のとおりです。

差が付くかどうかは、キャッシュの有効期間内に何回読み直すかで決まります。見積もりの段階で、1文書あたりの問い合わせ回数を置いておきます。

手順3: 新しいトークナイザーのモデルでは見積もりを使い回さない

Claude 4.7以降のモデルとClaude Mythos Previewは新しいトークナイザーを採用しており、同じテキストでも旧トークナイザー(Claude Sonnet 4.6以前)よりおよそ30%多いトークン数になります。増加幅はコンテンツと処理内容によって変わるため、正確な値は言語・文書ごとに実測が必要です。Opus 5・Sonnet 5.5・Fable 5.1は新しい側、Haiku 4.5は旧トークナイザー側に入ります。

単価表だけを見比べると、モデル替えの損得を読み違えます。仮に旧トークナイザーで18,000トークンだった文書が、新しいモデルで30%増えて23,400トークンになるとします。

この差は単価表からは見えません。

候補モデルごとにmodelを変えてcount_tokensを呼び直し、返ってきたinput_tokensを並べるのが確実です。増加幅の測り方としても、現行モデルと移行先で同じリクエストを2回数えて比べる方法が示されています。

for model in ["claude-sonnet-4-6", "claude-sonnet-5-5"]:
    r = client.messages.count_tokens(
        model=model,
        system="あなたは契約書レビューの専門家です",
        messages=[{"role": "user", "content": contract_text}],
    )
    print(model, r.input_tokens)

日本語は元々トークン密度が英語と異なるため、言語差とトークナイザー差が重なって見積もりの誤差が大きくなりやすい点にも注意が要ります。

AWS / Microsoft Foundry経由で使う場合の注意

count_tokensはClaude API直接利用だけでなく、Claude Platform on AWS・Amazon Bedrock・Google Cloud・Microsoft Foundryのいずれでも同じように使えます。ただし、Claude Platform on AWSとMicrosoft Foundryはトークン使用量をUSDでレーティングしたあと、$0.01を1CCU(Claude Consumption Unit)としてマーケットプレイス請求に変換します。単価そのものはこの記事の料金表と同じ(標準のper-model・per-featureレート)なので、input_tokens × 単価で出したUSD見積もりを100倍すればCCU数の目安になります。上のSonnet 5.5の$0.036なら3.6 CCUです。

実際の請求書はCCU単位の1行にまとめられます。モデル別の内訳を追いたい場合は、見積もり段階のUSD計算を別途残しておくと突き合わせが楽になります。

よくあるつまずき

• 出力コストを入力と同じ感覚で見積もる: max_tokensの上限値に加えて、過去の実行ログから推定した平均出力長でも見積もれます
• システムプロンプトを見積もりに含め忘れる: systemフィールドのテキストも課金対象で、count_tokensのリクエストボディにも含める必要があります。省くと実際の請求より少なく見積もることになります
• Web検索やMCPコネクタを使うリクエストをそのまま数える: Web検索・Web fetch・コード実行・ツール検索といったサーバーツール(advisorツールを除く)とMCPコネクタは、count_tokensでinvalid_request_errorになります。urlやfileを指すimage・documentブロックも同じです。画像とPDFはbase64で渡して数え、サーバーツールやMCPを使うリクエストの実使用量は、Messages APIが返すusageで見ます
• 実際の契約書・議事録をそのまま送ってしまう: count_tokensはZero Data Retention(ZDR)の対象になり得るエンドポイントですが、対象外のモデル(Covered Models)もあります。社外秘のビジネス文書で見積もりを取るときは、自組織のZDR設定と対象モデルを確認したうえで送るか、社名・個人名を伏せたダミー文書で代用します

用途別に単価と割引を組み合わせる

日本語ビジネス文書の要約・レビューのような用途では、要約タスクでコンテキスト予算をどう分割設計するかも費用を左右します。同じ入力トークン数でも、用途ごとに効く単価と割引は次のように違います。

まとめ

モデルを替えたときに請求が減るのは、単価の下がり幅が約30%のトークン増加を上回る場合です。Sonnet 4.6から5.5への移行はこれに当たり、単価が同じOpus 4.6から5への移行は請求がそのまま約3割増えます。