Claude Sonnet 5.5の提供基盤とモデルIDを選ぶ

結論：同じモデル名でも、接続先を先に決めない

Anthropicの公式リリースノートは2026年9月28日のSonnet 5.5提供開始をAPI、Amazon Bedrock、Google Cloud、Microsoft Foundryについて案内しています。公式モデルページには能力、コンテキスト、出力制限、料金へのリンクがあり、モデル一覧では各プラットフォームのIDを確認できます。公開前にこの2ページをreadbackし、価格や提供地域の変更を反映しました。

4つの提供基盤を比較する

経路	モデル指定の考え方	向いている判断
Claude API	Claude APIのalias・公式API仕様	Anthropic APIを直接使い、機能更新を追う
Amazon Bedrock	AWSのmodel ID・region・IAM	AWSの請求、権限、ネットワークへ統合する
Google Cloud	Vertex AIのpublisher/model指定	GCPの組織・監査・既存基盤とそろえる
Microsoft Foundry	Foundryのdeploymentと接続設定	Azureの契約、ID、監視と一体運用する

表は「どれが一番良い」というランキングではありません。例えばAPIの最新機能を早く試したいチームと、データ処理や請求をAWSに統一したいチームでは、同じ品質要件でも最適な経路が変わります。Claude APIモデルの選び方はモデル比較が主題であり、この記事はproviderの選択を主題にします。

モデルIDと料金を取り違えない5つの確認

1. 正式名とaliasを記録する。Sonnet 5.5という表示名、Claude APIのclaude-sonnet-5-5、各providerのIDを別欄にします。
2. 接続先の公式ページを指定する。モデル一覧のリンクだけでなく、provider側のモデルカタログ、region、quotaを確認します。
3. 料金単位をそろえる。入力・出力MTok、cache、Batch、provider手数料、為替、税を同じ見積もりに混ぜません。
4. 制限を実装へ写す。context、max output、rate limit、tool、thinking、streamの差をテスト条件に含めます。
5. 更新責任を決める。モデルaliasが更新された時の検知、固定IDの更新、承認者、rollbackを台帳に書きます。

特にaliasは便利な反面、同じ文字列が永久に同じ挙動を保証するものではありません。重要業務では解決されたモデルIDと取得時刻をログへ残し、月次で公式ページと突き合わせます。利用者がUIで使う場合も、APIの料金やIDをそのまま適用しないよう契約区分を分けます。

導入先を決める7ステップ

1. 対象業務をread-only、社内作業、外部影響ありに分類する。
2. 入力に個人情報、顧客秘密、ソースコードが含まれるか確認する。
3. 既存のAWS、GCP、Azure、Anthropic契約と請求主体を並べる。
4. 必要なregion、private network、IAM、監査ログ、保持方針を決める。
5. 同じ匿名化評価セットを各経路へ送り、品質、遅延、形式、toolを比較する。
6. 障害時にどこへ切り替えるか、切替でデータ境界が変わらないか確認する。
7. 利用者、費用、モデル更新のownerを決めてから本番へ出す。

複数基盤を使う場合は「どこでも同じ出力になる」と期待せず、経路ごとの受入基準を定義します。モデルが同じでもsystem prompt、tokenizerの扱い、tool wrapper、再試行、regionの混雑で結果が変わるからです。

企業利用のチェックリスト

• 表示名、API ID、provider ID、deployment IDを分けて台帳化した
• 公式モデルページ、料金ページ、providerの提供条件を公開直前に確認した
• 入力データの境界と保存・監査の責任者が決まっている
• 代表業務の品質、形式、tool、遅延、費用を経路別に比較した
• quota、rate limit、429、timeout、provider障害の対応を試験した
• alias変更とモデル退役を検知する定期readbackを設定した

APIキーやservice accountの管理はClaude APIキーの選び方、企業の入力・権限設計は企業利用前のセキュリティ確認も参照してください。接続先を変える作業は、SDKの差し替えだけでなく、認証と監査の変更でもあります。

provider変更後に残す運用記録

接続先を決めた後は、アプリケーションの設定値だけでなく、誰がどの基盤を承認したかを残します。記録項目は、モデル表示名、解決されたID、provider、region、取得日時、料金表の版、quota、データ分類、ログ保存先、障害時の連絡先です。月次の公式readbackで提供条件が変わったら、影響のある業務と再評価の要否を判断します。

複数providerのフェイルオーバーを作る場合は、データ境界と出力形式を同時に確認します。切替先が別地域なら顧客への説明や契約条件も変わる可能性があります。fallbackが動いたことを利用者へ隠さず、request IDと経路を監査ログへ記録して、品質・費用・安全のKPIを後から分解できるようにします。

providerの選択は一度決めたら終わりではありません。新機能の提供開始、モデル退役、region変更、rate limitの変更を定期的に読む担当を置き、変更があった場合に再評価する条件を台帳へ書きます。価格表のスクリーンショットだけでなく、確認URLと確認日も残してください。

本番前には同じリクエストを各経路へ送るだけでなく、タイムアウト、429、部分応答、再試行の挙動も確認します。正常系の比較だけでは、実際の運用コストと停止条件を決められません。

この記録があれば、provider変更後も差分を説明できます。

担当部署と更新期限も明記します。

環境ごとの設定レビューも同じ台帳で行います。

レビュー結果には、未確認の地域や未対応の機能を明記し、推測で埋めません。未確認の項目は導入条件から外し、公式更新後に再判定します。

FAQ

Claude APIのモデルIDをBedrockへそのまま設定できますか？

できるとは限りません。provider固有のID、region、IAM、呼び出し形式を公式ドキュメントで確認し、経路別の設定値を管理します。

一番安い提供基盤を選ぶにはどうしますか？

表示単価だけでなく、cache、Batch、外部ネットワーク、監視、再試行、運用時間を含めた一件あたりの総費用で比較します。

導入先の判断を無料診断で相談できますか？

できます。業務、データ境界、既存クラウド、費用上限、必要な監査を無料診断（60秒）へ入力してください。