Sonnet 5.5のAPI料金：キャッシュとタスク完了までの費用を計算する

Claude Sonnet 5.5の標準Claude API料金は、入力100万トークン当たり2ドル、出力100万トークン当たり10ドルです。キャッシュ読み取りは100万トークン当たり0.20ドル。2026年9月29日に確認した提供元の公示料金であり、Ofoxの見積もりやClaudeの月額契約料金ではありません。予算を組む際には、アプリケーションが合格基準を満たす成果物を完成させるまでに、何トークン課金されるかを考えます。

Sonnet 5から移行しても単価表は変わりません。Anthropicが多くの用途で費用削減を説明しているのは、モデルの動作や消費トークン数についてです。すべてのリクエストへの一律割引ではありません。公式モデル仕様を確認し、実際に処理する仕事に合わせて見積もりましょう。

Sonnet 5.5の料金表

モデルの仕様ページには、Batch APIの入力・出力50%割引と、キャッシュ可能なプロンプトの最小長512トークンも記載されています。ただし、長さを満たすだけではキャッシュは作られません。設定を行い、使用量フィールドを確認してください。キャッシュ分を通常入力にも足して二重計上しないようにします。

ツール料金、データの保存地域に関するオプション、サービス固有の料金は料金ドキュメント全体で別途確認します。提供事業者によって機能、通貨、課金ルールが異なる場合があります。他のエンドポイントにこの計算を当てはめる前に、その事業者の条件を確認してください。

小さなリクエストの例：0.04ドルは月額予算ではない

キャッシュなし入力10,000トークン、課金対象出力2,000トークンの仮想リクエストなら、計算は次のとおりです。

入力：10,000 / 1,000,000 × $2  = $0.02
出力： 2,000 / 1,000,000 × $10 = $0.02
合計：                           $0.04

すべてがこの使用量なら、1,000リクエストで追加料金を除き40ドルです。これは算数の例であり、Sonnetの標準的な応答長を測定した値ではありません。思考が長くなる、ツールの往復が増える、再試行するといった変化で合計も変わります。画面上の回答の単語数に推測した換算係数を掛けても、正確な請求額は求められません。

キャッシュを使うと計算はどう変わるか

10件のリクエストで100,000トークンの共通プレフィックスを使うとします。5分キャッシュを1回作成し、有効期間内に9回実際にヒットし、それ以外の入力・出力はないという前提です。作成0.25ドルと読み取り9 × 0.02ドルで、合計は0.43ドル。10回ともキャッシュを使わない場合の2.00ドルに対し、このプレフィックスだけでは1.57ドル、78.5%の削減です。

アプリケーション全体が78.5%安くなるわけではありません。プレフィックスの変更、キャッシュミス、大量の出力があれば、全体の削減率は小さくなります。リクエストごとに作成量と読み取り量を記録しましょう。キャッシュ向けの構造にしたことは、実際にキャッシュ読み取り料金が適用された証拠にはなりません。

非対話処理で利用条件を満たす場合は、Batchも別に評価できます。入力・出力50%割引を先ほどのキャッシュなし0.04ドルの例に適用すると、同じ前提で0.02ドルです。この例はBatchとキャッシュを組み合わせた計算ではなく、あらゆる組み合わせの課金を説明するものでもありません。

合格したタスク当たりの費用を記録する

バグ修正、文書作成、データ抽出では、次のような記録表を使えます。

タスクID | モデル | Effort | 入力 | キャッシュ作成 | キャッシュ読み取り
出力 | ツール料金 | 試行回数 | 合格したか | 合計USD

失敗と再試行もそのタスクの費用に含めます。テスト合格、必須項目の正確性、成果物のチェックリストなど、合格基準を先に定めてから総費用を合格件数で割ります。月額契約の使用量は別欄に記録してください。CLIのAPI換算推定額が、そのまま月額契約の請求書に載るとは限りません。

Effortを記録する理由もあります。Artificial Analysisの公開時評価では、maxで出力消費が非常に多いことが報告されています。ただし、そのベンチマークから個別の請求額は予測できません。構造化出力の問題があった公開前環境での測定で、再評価の注意書きも重要です。タスク使用量を測る理由にはなりますが、Sonnetは常に高価だと断定する根拠にはなりません。

会話の見た目ではなく usage から料金を再計算する

上記の標準料金では、トークン料金は次の式で求められます。

USD = (2 × 通常入力
     + 2.5 × 5分キャッシュ書き込み
     + 4 × 1時間キャッシュ書き込み
     + 0.2 × キャッシュ読み取り
     + 10 × 課金対象の出力) / 1,000,000

各項目は重複しない課金区分です。Claude の usage 応答では input_tokens、cache_creation_input_tokens、cache_read_input_tokens を区別します。保持時間を混在させる場合は、作成トークンの内訳も保存してください。作成の合計と、その内訳である5分・1時間の数値を二重に加算してはいけません。ゲートウェイが応答形式を変える場合は、そのサービスの usage 定義に従います。項目がない場合は記録不足であり、料金ゼロとは限りません。

通常入力8,000、5分キャッシュ書き込み40,000、キャッシュ読み取り60,000、出力3,000トークンという仮のリクエストなら、$0.016 + $0.100 + $0.012 + $0.030 = $0.158 です。入力コンテキストには三つの入力区分が含まれますが、すべてを通常入力料金で計算するわけではありません。元の usage 応答を計算と一緒に保存すれば、請求との違いをプロンプトの長さから推測せず、区分ごとに確認できます。

thinking も見落としやすい項目です。表示される回答が短くても、課金対象の思考トークンが多い場合があります。思考の表示を隠しても、その使用量はなくなりません。max_tokens は思考とテキストを合わせた上限であり、その範囲で正しく完了する保証ではありません。上限で中断した試行も、続行前にタスク費用へ計上します。

5分と1時間のキャッシュは何回で割安になるか

100,000トークンの共通部分だけを計算します。N回をすべて通常入力にすると $0.20N。5分キャッシュを一度作り、残り N−1 回が実際にヒットすれば $0.25 + $0.02(N−1) です。2回で $0.27 となり、通常入力の $0.40 を下回ります。1時間キャッシュなら $0.40 + $0.02(N−1)。2回では $0.42 と通常入力より少し高く、3回では $0.44 となって通常入力の $0.60 より安くなります。

これは作成が1回で、後続がすべて読み取りになった場合の分岐点です。呼び出し間隔だけでヒットを保証するものではありません。実際の usage で書き込みと読み取りを数えます。10回とも5分キャッシュを作り直すと $2.50 で、キャッシュなしの $2.00 より高くなります。1時間キャッシュの高い作成料も、再作成を減らせる場合に初めて正当化できます。

本当に変わらない資料を可変のタスク入力より前に配置します。ただしヒット率だけを上げるために必要な情報を削ってはいけません。無関係なコードを大量にキャッシュしてもコンテキストは消費します。関連部分を少量だけ通常入力する方が適切な場合もあります。モデルを変えたときのキャッシュ共有も、サービスの対応と課金を確認するまで予算へ織り込まないでください。

再計算できる三つの月額例

次の例は標準の同期 Claude API、キャッシュなし、Batch 割引なし、別途ツール料金なしという条件です。予算を考えるための合成例であり、モデルの実測値や一般的な消費量の予測ではありません。

コーディングの行は、毎ターンの入力を数えています。会話履歴を送り直すと後半の入力が増える可能性があるため、4ターンとも同じ使用量というのは簡略化です。予測に使う前に各ターンの実際の usage へ置き換えます。ツール結果は次の入力に入り得ます。モデルが生成するツール呼び出しと、ツール実行自体に別途かかる料金も分けてください。

500件のうち100件で $0.08 の追加ターンが1回必要なら、$8 を加えて $168 です。最終的に480件だけが合格した場合、合格タスク当たりのトークン料金は $168 / 480 = $0.35。失敗20件も報告に残します。合格率は96%であり、500件完了とは書けません。人の確認、ホスティング、外部ツールの料金はなお小計の外です。

請求が想定より高いときの切り分け

最大の項目から調べます。出力が大きければ effort、実際の thinking 使用量、上限による中断、不要な長文を確認します。入力が大きければ履歴の再送と過剰な検索結果を確認します。キャッシュ作成が大きければ設定の有無ではなく書き込み・読み取りイベントを比較します。再試行が多ければ無効なリクエスト、ツール障害、成果物の不合格を分けます。スキーマの不備はクライアント修正の対象で、形式上正しいが不十分な回答はタスク設計やモデル選択の調査対象です。

1リクエストの出力上限に加え、アプリ側でタスク全体の支出上限を設けます。予算を使い切ったら止め、未完了と表示してください。アプリ独自の制限を公式のレート制限と説明したり、記録を変えずに安いモデルへ切り替えたりしてはいけません。Batch を選ぶ前には非同期完了を許容できるか、対象サービスで利用条件を満たすかを確認します。単価が低くても、対話ユーザーが待てない処理には適しません。

次に確認すること

単価が分かっていても請求額を説明できない場合は、事業者を切り替える前に、実際の出力トークン数、キャッシュヒット、再試行数を比較します。設定調整はSonnet 5.5のeffortガイド、モデル選択はコーディングでのSonnetとOpusの比較を参照してください。

Ofox 経由で利用する場合は、Claude Sonnet 5.5 のモデルページでモデル ID、現在の提供事業者、料金、対応プロトコルを確認してください。上記の計算例は Anthropic 公開の料金を使っており、各提供事業者が Anthropic の全機能に対応することを保証するものではありません。