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

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

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

前提条件

• Anthropic APIキー(platform.claude.comのConsole > Settings > 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",
    system="あなたは契約書レビューの専門家です",
    messages=[{"role": "user", "content": contract_text}],
)
 
print(response.input_tokens)

レスポンスはinput_tokensフィールドを持つオブジェクトです。SDKを組み込まずに手早く確認したいだけなら、CLIのant messages count-tokensでも同じ結果を得られます。長文の契約書・議事録・問い合わせメールなど、実際に送るテキストをそのまま渡すのが重要です。英語の目安(4文字で1トークン)をそのまま日本語に当てはめると、漢字・ひらがな・カタカナが混ざる分だけ実際のトークン数とずれます。公式ドキュメントも「言語とコンテンツで正確なカウントは変わる」と明記しており、日本語コンテンツでは推測ではなく実測が前提になります。

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

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

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

繰り返し同じ社内文書をコンテキストに含める設計なら、プロンプトキャッシュも試算に入れる価値があります。キャッシュ書き込みは標準入力の1.25倍(5分)または2倍(1時間)、キャッシュヒットは標準入力の10%(Fable 5.1 / Mythos 5.1のみ2.5%)で課金されます。1回書いて2回以上読み取る運用なら、素の入力コストより安くなります。

バッチ処理と長文コンテキストで単価が変わるケース

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

例えば、Sonnet 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とおよそ半額になります。出力トークンは実行前に確定しないため、この計算はあくまでmax_tokensを上限とした最悪ケースの見積もりで、実際の出力が短ければコストはさらに下がります。

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

ツール(関数呼び出し)を併用する場合は、toolsパラメータのスキーマ定義自体もトークンとして課金され、ツール利用を有効にすると追加のシステムプロンプト分のトークンも加算されます。count_tokensのリクエストには実際に使うtools定義も含めて数えないと、見積もりが少なめに出ます。

先の18,000トークンの契約書を、同じ内容のまま1時間キャッシュで3回問い合わせる設計に変えると、1回目は書き込み分の2倍単価(18,000 ÷ 1,000,000 × $4 = $0.072)、2回目以降はヒット分の10%単価(18,000 ÷ 1,000,000 × $0.2 = $0.0036)が2回で$0.0072。合計$0.0792の入力コストで済みます。同じ文書を3回とも標準単価で送ると18,000 ÷ 1,000,000 × $2 × 3 = $0.108なので、キャッシュを使うほうが約27%安くなります。差が付くかどうかはキャッシュの有効期間内に何回読み直すかで決まるため、見積もり段階でアクセスパターンを想定しておく価値があります。

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

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

つまり、Sonnet 4.6で測ったトークン数をそのままOpus 5やFable 5.1のコスト試算に使い回すと、費用を過小評価します。モデルを乗り換える、あるいは複数モデルを比較検討するときは、候補モデルごとにmodelパラメータを変えてcount_tokensを呼び直すのが安全です。日本語コンテンツは元々トークン密度が英語と異なるため、この2つのずれ(言語差 + トークナイザー差)が重なると見積もり誤差が大きくなりやすいポイントです。

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

よくあるつまずき

• 英語の「4文字で1トークン」を日本語に流用する: 公式の目安はあくまで英語基準の概算で、日本語を含む非英語コンテンツでは同じ比率になりません。必ず対象言語のテキストで実測します
• 旧モデルで測ったトークン数を新モデルの見積もりに使う: 前述のとおりトークナイザーの違いで最大約30%のずれが生じます。モデルを変えたら数え直します
• 出力コストを入力と同じ感覚で見積もる: count_tokensは入力しか数えません。出力コストはmax_tokensの上限値、または過去の実行ログから推定した平均出力長で見積もります
• システムプロンプトを見積もりに含め忘れる: systemフィールドのテキストも課金対象で、count_tokensのリクエストボディにも含める必要があります。省くと実際の請求より少なく見積もることになります
• Anthropicが自動追加するトークンを自分のコンテンツと誤解する: カウントに含まれていても、システム最適化用のトークンは課金対象外です。返ってきた数字と実際の請求明細を照合するときはこの差分を考慮します
• 実際の契約書・議事録をそのまま送ってしまう: count_tokensはZero Data Retention(ZDR)の対象になり得るエンドポイントですが、対象外のモデル(Covered Models)もあります。社外秘のビジネス文書で見積もりを取るときは、自組織のZDR設定と対象モデルを確認したうえで送るか、社名・個人名を伏せたダミー文書で代用します

モデル選びの費用感を早見表にする

日本語ビジネス文書の要約・レビューのような用途を想定すると、要約タスクでコンテキスト予算をどう分割設計するかを含め、同じ入力トークン数でもモデル間の費用差は次のように変わります。

まとめ

日本語プロンプトの費用は、count_tokensで得たinput_tokensにモデルの単価表を掛けるだけで事前に見積もれます。返る数字は見積もりであって確定値ではありません。公式ドキュメントも「estimate」と明記しており、実際の送信時のinput tokenとは小さな幅でずれます。ただし英語基準の目安をそのまま流用しない、モデルを変えたら数え直す、出力コストは別枠で見積もる、の3点を外すと実際の請求とのずれが大きくなります。バッチ処理やプロンプトキャッシュを併用する設計なら、それぞれの割引率も見積もり式に組み込んでおくと精度が上がります。料金体系全体の詳細はClaudeの料金プランで確認できます。