結論：$2/$10だけで予算を決めず、接続先と利用形態を分ける
Claude Sonnet 5.5のClaude API基本料金は入力$2/MTok、出力$10/MTokです。ただし実際の見積もりは、5分・1時間cache、Batch API、provider、契約条件、1M contextと128K出力の使い方を分けて作ります。モデルIDも接続先で異なり、Claude APIはclaude-sonnet-5-5、Amazon Bedrockはanthropic.claude-sonnet-5-5です。
一次情報はClaude Sonnet 5.5公式モデルページとClaude Platform公式料金ページです。2026年9月28日の公式リリースノートで提供開始と対応基盤も確認できます。既存のClaude料金ガイドがプラン全体を扱うのに対し、ここではSonnet 5.5をAPIへ接続する時の見積もりとID管理に限定します。
公式仕様を比較する
| 項目 | Claude Sonnet 5.5 | 見積もり・設計での注意 |
|---|---|---|
| 基本料金 | 入力$2 / 出力$10 per MTok | inputとoutputを別カウント |
| cache | 5分write $2.50、1時間write $4、read $0.20/MTok | TTLとhit率を記録 |
| Batch API | 入力・出力50%割引 | 同期処理と納期を混同しない |
| context / output | 1M tokens / 最大128K tokens | 上限と毎回の利用量は別 |
| 提供基盤 | Claude API、Bedrock、Google Cloud、Foundry、Claude Platform on AWS | 価格表とIDを基盤別にreadback |
価格は利用量の全てではありません。入力に大きな資料を毎回追加すれば、1M contextに収まっても費用と遅延が増えます。cache writeを使えば安くなると決めつけず、同じprefixを何回再利用するか、更新時にcacheが無効になるかを測ります。Batchの50%割引も、対話画面をそのままBatchへ置き換えられるという意味ではありません。
導入先別にモデルIDを間違えない8手順
- 接続先を一つずつ書く。Claude API、Amazon Bedrock、Google Cloud、Microsoft Foundry、Claude Platform on AWSをアプリ台帳へ登録します。
- 公式IDを転記する。Claude API等の
claude-sonnet-5-5と、Bedrockのanthropic.claude-sonnet-5-5を同じ欄に入れません。 - 単価の通貨と単位を固定する。per MTok、input、output、cache、Batchを別列で保存します。
- 1リクエストのfixtureを作る。system、user、tool、出力上限、再試行を固定して各基盤へ送ります。
- cacheの再利用を測る。5分と1時間のTTLごとにwrite、read、missを記録し、prefix更新時の挙動を確認します。
- Batchにできる処理を分ける。納期が許容される評価・集計と、利用者が待つ対話を別の予算にします。
- 実費を合算する。input、output、cache、再試行、人の確認、providerの請求明細を同じ期間で突合します。
- 公式readbackを保存する。公開前のモデルページ、料金ページ、契約担当の条件、変更日を見積もり票へ添付します。
手順2のID確認は、アプリ設定だけでなくIaC、secret store、テストfixture、監視ラベルまで対象です。BedrockのIDをClaude APIへ送る、または逆にすると、認証が成功してから別のモデル不明エラーになる場合があります。errorを「料金問題」とまとめず、provider、region、model ID、accountをログへ残します。
業務量から見積もる比較表
| 利用形態 | 主な費用 | 採用判断 |
|---|---|---|
| 短い対話 | input・output・retry | 応答速度と1件上限を優先 |
| 長い共通資料を反復 | cache write・read・更新 | prefixの安定性とhit率を測る |
| 大量評価 | Batch input・output | 納期と再実行条件を確認 |
| 複数provider | 基盤別料金・転送・運用 | 同一単価とみなさず比較 |
企業の予算承認では、公式の単価に自社の品質・安全コストを足します。128K max outputを設定しても、毎回そこまで出力されるわけではありません。完了条件を短くできるprompt、不要な資料を除く検索、利用者が確認する箇所の設計も、モデル単価とは別の改善項目です。値下げ率や削減率を先に約束せず、現行モデルとの差分を同一fixtureで測ります。
料金・制限の公開直前チェックリスト
- 正式名称をClaude Sonnet 5.5と表記した。
- Claude APIとBedrockのmodel IDを分けた。
- 入力$2、出力$10/MTokを公式ページで再確認した。
- 5分・1時間cache writeとcache readを見積もりへ分けた。
- Batch APIの50%割引を同期処理の価格として扱っていない。
- 1M contextと128K max outputを利用保証と混同していない。
- 対応基盤と契約・region・provider固有条件を別途確認した。
- 請求明細、内部usage、retry、cache hitを突合する期間を決めた。
よくある質問
Claude Sonnet 5.5は入力$2、出力$10で固定ですか？
Claude Platformのモデルページにある基本単価です。cache、Batch、Bedrockなどの基盤、契約、地域条件は別の公式料金表と請求書で確認します。
全基盤で同じmodel IDを使えますか？
使えません。特にBedrockはanthropic.claude-sonnet-5-5で、Claude API等のclaude-sonnet-5-5と分けて管理します。
1M contextを使うと得ですか？
上限が大きいことと費用対効果は別です。必要資料、cache hit、出力、review時間を同じ単位で比較します。
見積もり表には、月間リクエスト数だけでなく、一件あたりの入力token、出力token、cache write、cache read、失敗と再試行の件数を入れます。さらに、Bedrockなど別基盤へ切り替える場合は、同じ機能名でもリージョン、認証、監視、契約窓口が変わる可能性があります。料金の比較表と運用責任表を分けると、単価が安く見える接続先へ急いで移す判断を防げます。
導入後は、公式ページを一度読んで終わりにせず、モデルIDと価格のreadback日を変更管理へ残します。新しいaliasが追加された時も、既存の固定IDを自動置換しないことが重要です。モデルの提供終了や価格変更があった場合に、予算担当、開発担当、セキュリティ担当が同じ台帳を見る状態を作っておけば、請求差異を発見してから慌てて原因を探す必要がありません。
公式情報と次の一歩
モデルの正式名称、ID、料金、制限は公式モデルページを公開前にreadbackし、基盤の提供条件は公式リリースノートと各providerの料金表を確認します。モデル全体の比較はOpusとSonnetの比較、APIの認証責任はAPIキーの種類ガイドも参照できます。見積もりと実装の責任分界が曖昧なら、Miraigentの無料診断で接続先、費用、監査項目を整理します。