Claude Opus 4.7 APIはいくら？$5/$25料金とトークン計算の実務

ポイントは、「総トークン数 × 何か1つの平均単価」で見積もらないことです。Opus 4.7では、input、output、cache write、cache readで単価が異なります。Prompt Cachingを使うアプリなら、コストモデルもこの4種類を分けるのが基本です。

計算式：Prompt Cachingなしの場合

Prompt Cachingを使わない最小構成なら、計算はシンプルです。

たとえば、1回のrequestで200,000 input tokensと20,000 output tokensを使った場合、キャッシュなしなら次の通りです。

これはAnthropic APIのinput/output単価だけを使った単純計算です。別プラットフォーム経由の手数料や提供事業者ごとの差分は含みません。

計算式：Prompt Cachingありの場合

Prompt Cachingを使うなら、通常入力・出力に加えて、cache writeとcache readを足します。

5分TTLか1時間TTLのどちらか一方しか使っていないなら、使っていないcache write項目は外して構いません。Anthropicのstreamingドキュメントのusage例には、input_tokens、output_tokens、cache_creation_input_tokens、cache_read_input_tokensなどの項目が示されています。また、Pricingドキュメントではcache writeとcache hitが別料金として整理されています。

トークン数は送信前にcount_tokensで確認する

APIコストを見積もるとき、文字数や単語数からざっくり逆算するのは避けた方が安全です。Anthropicの/v1/messages/count_tokens endpointは、Claudeにmessageを送る前にトークン数を確認するためのものです。system prompt、tools、images、PDFsを含む、message作成時と似た構造化入力を受け取り、total input tokensを返します。すべてのactive modelsがtoken countingをサポートしています。

実務では、実際にMessages APIへ送る予定のpayloadをそのままcount_tokensに通すのが最も堅実です。system prompt、会話履歴、tool定義、画像、PDFなどを含めて数えれば、本番呼び出し前にinput tokenコストを見積もれます。プロダクト側で予算上限、利用制限、アラートを設定する場合にも、この方法が扱いやすくなります。

送信後はresponseのusageを保存する

request完了後の実コスト管理では、出力テキストの長さから推測するのではなく、API response内のusageを記録します。AnthropicのMessages API examplesではinput_tokensやoutput_tokensを含むusageが示されており、streamingドキュメントでもcache_creation_input_tokensやcache_read_input_tokensなどのキャッシュ関連項目が示されています。

streamingを使う場合は、集計方法に注意が必要です。Anthropicのstreamingドキュメントでは、message_delta内のusage token countsは累積値であり、各eventごとの増分ではないと説明されています。deltaごとにそのまま足し上げると、同じトークンを重複計上してしまいます。

月次・チーム単位の照合はUsage & Cost Admin APIで行う

個別requestのusageログは、リアルタイムの上限管理やユーザー別の概算には便利です。一方で、チームの月次精算、workspace別の配賦、長期的なコスト分析には、AnthropicのUsage & Cost Admin APIも使うべきです。

公式ドキュメントによると、このAPIは組織のhistorical API usage and cost dataに対して、programmaticかつgranularにアクセスするためのものです。usage reportはmodel、workspace、service tierなどの軸で分解できます。

つまり、アプリ側では各requestのusageを保存して即時制御に使い、正式な照合や月次レポートではUsage & Cost Admin APIの履歴データを見る、という分担が現実的です。

Opus 4.7へ移行する前にtoken budgetを再計算する

Opus 4.7では新しいtokenizerが導入されています。Anthropicのドキュメントでは、この新tokenizerはテキスト処理時に、以前のモデルと比べておよそ1x〜1.35xのトークン数を使う可能性があり、最大で約35%増える場合があると説明されています。実際の増減は内容によって変わります。また、同じinputでも、/v1/messages/count_tokensはOpus 4.7とOpus 4.6で異なるトークン数を返します。

そのため、「input $5/MTok、output $25/MTok」という単価だけを見て、移行後の請求も同じだと考えるのは危険です。Opus 4.6以前から移行する場合は、トラフィックの多いprompt、長いcontextを使うprompt、tool definitionsを含むpayload、コストの大きいworkflowを抜き出し、Opus 4.7向けに/v1/messages/count_tokensを再実行しましょう。その結果に合わせて、アラート、rate limit、ユーザー別の上限、社内予算を見直すのが安全です。

実務チェックリスト

• API model IDがclaude-opus-4-7になっているか確認する。
• 重要なrelease前に、代表的なpayloadを/v1/messages/count_tokensで見積もる。
• input_tokens、output_tokens、cache write、cache readを分けて保存し、単一のtotal tokenだけで管理しない。
• streamingでは、message_delta.usageが累積値であることを前提に集計する。
• チームの月次精算、workspace別の配賦、履歴分析にはUsage & Cost Admin APIを使う。
• 旧ClaudeモデルからOpus 4.7へ移行する前に、新tokenizerが実際のpromptへ与える影響を測り直す。

まとめると、Claude Opus 4.7の基本料金は「input $5/MTok、output $25/MTok」と覚えれば十分に見えます。ですが、コストを正確に出すには、送信前にcount_tokensでpayloadを数え、送信後にusageを保存し、Prompt Cachingと新tokenizerの影響をコストモデルへ反映する必要があります。