Amazon BedrockでClaudeを使う方法 — APIの始め方と直接APIとの違い

Amazon Bedrockは、AWSのアカウントと請求の中でClaudeを呼び出せる提供経路です。モデルの中身はAnthropicの直接APIと同じですが、認証・課金・利用できる機能の範囲はBedrock側の枠組みに従います。使い始める流れは、Bedrockコンソールでモデルアクセスを申請し、認証方式を選び、Bedrock用のSDKでMessages APIを呼ぶ、の3段階です。直接APIとの違いを知らずに移行すると、動くはずのコードがそのままでは通らない場面が出てきます。違いの所在と手順を順に見ます。

Amazon Bedrockとは何か

Amazon Bedrockは、AnthropicのようなAIベンダーの基盤モデルを単一のAPIから呼び出せる、AWSのフルマネージドサービスです。サーバーレスで動くため、モデルを動かすためのインフラを自分で管理する必要がありません。ファインチューニングや検索拡張生成(RAG)による独自データでのカスタマイズ、既存のAWSサービスと組み合わせたエージェント構築にも対応しています。

Claudeのモデルは、このBedrockのカタログに載る形で提供されています。ユーザーはBedrockコンソールからモデルへのアクセスをリクエストし、許可されたモデルを自分のAWSアカウントの範囲で試したり本番投入したりできます。推論はAWSが管理するインフラの上で動き、Anthropicの担当者は推論インフラへアクセスできません。APIの形はAnthropic直接APIと同じMessages APIで、機密性の高いアプリケーションをAWSのセキュリティ境界の内側で組み立てられます。

なぜBedrock経由でClaudeを使うのか

理由の中心は、既存のAWS環境にそのまま乗せられる点です。柱は3つあります。IAMでの権限管理、CloudWatch・CloudTrailでのログ監視、AWSの請求にまとめる課金です。これらはAnthropicと個別に契約を結ばなくても、すでに使えるAWSの仕組みの上で完結します。

監査の面では、ログがCloudWatchとCloudTrailの両方に出力されます。Anthropicはアクティビティログを30日以上のローリングで保持することを推奨しています。データの扱いはBedrockの規定が正で、Anthropic側の規定ではありません。

一方で、Bedrockは万能ではありません。次の節で見るとおり、直接APIにある一部の機能が使えません。新機能が直接APIと同じタイミングで使えることを優先するなら、後述するClaude Platform on AWSが選択肢になります。

直接APIやClaude Platform on AWSとの違い

似た名前の選択肢が複数あるため、まず全体像を確認します。3つの提供経路は認証・請求・機能範囲がそれぞれ違います。

Claude Platform on AWSは、AWS Marketplaceで契約しながら中身はAnthropicが運用するAPIを呼び出す提供形態です。Anthropic側の説明では、新機能を同日程度で使える点が特徴です。認証と請求はAWS寄り、機能は直接API寄りという構成で、Bedrockとは別物です。設定手順と機能差の詳細はClaude Platform on AWSでClaude Codeを使うにまとめています。

Bedrockで使えない機能は主に次のとおりです。

対応している機能もあります。Messages APIそのもの、プロンプトキャッシュ、Thinkingです。Bash・Memory・Text editorなどのツール利用、Citationsも使えます。Computer useはbeta版のツールに限って利用でき、computer_toolset_20260801・browser_toolset_20260801のtoolsetは非対応です。この対応状況はモデルの世代でも変わります。Claude Opus 4.7以降とHaiku 4.5は、新しいMessages API形式のエンドポイント(/anthropic/v1/messages)で提供されます。Opus 4.6以前はInvokeModel・ConverseというARNベースの旧エンドポイントです。Haiku 4.5だけは両方にまたがり、旧形式(anthropic.claude-haiku-4-5-20251001-v1:0を推論プロファイル経由)でも呼べます。旧エンドポイントからの移行を考えているなら、まずどちらの形式で動いているモデルかを確認してください。

bedrock-mantleとbedrock-runtime、どちらに送るか

Bedrockにはエンドポイントが2種類あり、公式2ページの書き方が食い違います。Anthropicのガイドはbedrock-mantleを前提に手順を書いています。一方、AWSのFable 5のモデルカードは、可能なら新しいアプリケーションにはbedrock-runtimeを使うよう案内しています。同カードによると、Fable 5はbedrock-runtimeではMessages・Converse・Invokeに対応します。bedrock-mantleで使えるのはMessagesだけです。

取り違えると別々の形で失敗します。mantleにus.anthropic.claude-sonnet-4-6のような推論プロファイルIDを送ると、モデルIDを名指しした400が返ります。Claude Code側の説明では、mantleは標準のBedrockカタログとは別のモデル構成です。

旧形式のモデルは逆向きの失敗をします。ベースのモデルIDでオンデマンド呼び出しすると400になります。文言は「Invocation of model ID ... with on-demand throughput isn't supported」で、推論プロファイルのIDかARNを求められます。

料金の差は別の切り口になります。モデル単価・リージョン加算・Batch割引の対応状況・CCU課金の4点で直接APIとどれだけずれるかは、AWS BedrockのClaude料金は直接APIとどう違うかで扱っています。Google Cloud側と機能を並べたい場合は、ClaudeをBedrockとGoogle Cloudで使う際のAPI機能の対応差が参考になります。

利用できるモデルとリージョン

mantleのモデルIDにはanthropic.という接頭辞が付きます。アクセス条件はモデルごとに決まっていて、開放されているのはFable 5.1・Fable 5・Opus 4.8・Opus 4.7・Sonnet 5・Haiku 4.5です。

招待制のMythos系はProject Glasswing経由の申し込みが必要です。Mythos Previewにはさらに、Bedrockのマーケットプレイス担当チームが許可リストに載せた専用のAWSアカウントが要ります。Anthropicのアカウント担当者がアカウントIDを提出すると、通常24時間以内に処理され、完了時にAWSからウェルカムメールが届きます。

Mythos Previewはリージョンの面でも他のモデルと異なり、グローバルエンドポイントには対応せずus-east-1のリージョナルエンドポイントのみで提供されます。制約の詳細はBedrockのMythos Previewがus-east-1限定である理由で扱っています。

リージョンは27のAWSリージョンに展開されていて、東京・大阪を含むアジア太平洋、米国、欧州、南米、中東、アフリカまで広くカバーしています。エンドポイントには2種類あります。全リージョンへ動的にルーティングする「グローバル」は追加料金なしで可用性を優先する構成です。単一リージョンに固定する「リージョナル」はデータの所在地を保証する代わりに、グローバルより10%高い料金がかかります。

日本のデータを日本国内に留めたい場合は、東京リージョンをリージョナルエンドポイントで単独指定するか、日本向けの推論プロファイル(inference profile)で複数リージョンをまたいで振り分けます。JPプロファイルがあるかはモデルごとに違い、Fable 5とFable 5.1には東京・大阪とも用意されていません。さらにFable 5.1のリージョナルエンドポイントはus-east-1のみです。リージョン表で東京は「Global、JP、In-region only」、大阪は「Global、JP」なので、単独リージョンへの直接ルーティングは東京だけが該当します。モデル別のGlobal・JP・In-region対応はAmazon Bedrock東京リージョンでClaudeを使うで一覧にしています。

利用量の上限はデフォルトで入力200万トークン/分です。Anthropicの追加承認なしで、入力500万トークン/分・出力50万トークン/分まで引き上げられます。それ以上、あるいはAWS側のリクエスト数上限(RPM)を調整したい場合はAWSサポートへの申請が必要です。

Bedrockへのアクセスをリクエストする手順

PythonならインストールはBedrock用のextraを付けます。

pip install -U "anthropic[bedrock]"

クライアントはAnthropicBedrockMantle(aws_region="us-east-1")で作ります。通常のAnthropicクライアントも使えます。その場合はbase_urlをhttps://bedrock-mantle.{region}.api.aws/anthropicにして、bearerトークンをapi_keyに渡します。この経路はbearer認証専用で、SigV4署名にはBedrock用のクライアントが必要です。cURLで直接呼び出す場合は次のようになります。

curl https://bedrock-mantle.us-east-1.api.aws/anthropic/v1/messages \
  --aws-sigv4 "aws:amz:us-east-1:bedrock-mantle" \
  --user "$AWS_ACCESS_KEY_ID:$AWS_SECRET_ACCESS_KEY" \
  -H "x-amz-security-token: $AWS_SESSION_TOKEN" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "anthropic.claude-opus-5-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Hello, Claude"}]
  }'

エンドポイントはhttps://bedrock-mantle.{region}.api.aws/anthropic/v1/messagesという形式です。認証情報はAWS標準の優先順位(コンストラクタ引数 → 環境変数 → AWS設定ファイル・認証情報チェーン)で解決されます。

Claude CodeやCoworkからBedrockを使う場合

Claude CodeからBedrockを使う場合は、CLI内蔵の/setup-bedrockウィザードで認証方式・モデルのピン留めを対話的に設定できます。手順はClaude Code Bedrockセットアップにまとめています。Fable 5.1をBedrock経由で使うにはClaude Code 2.1.257以降が必要です(AnthropicのBedrock解説ページは2.1.255以降と記載)。Opus 5.5は2.1.280以降で、どちらもclaude updateで更新します。Claude Codeで.awsを書き換えずBedrock認証だけ注入する設定はawsCredentialExportです。

BedrockもmantleもCLIのフラグではなく環境変数で切り替えます。手元のv2.1.285で確認したところ、claude --helpにBedrock専用のフラグはありませんでした。

claude --version
claude --help | grep -i bedrock

出力のバージョンは2.1.285 (Claude Code)でした。Bedrockに触れる行は--bareの説明にある「(Bedrock/Vertex/Foundry) use their own credentials」の1か所だけでした。切り替えはCLAUDE_CODE_USE_BEDROCKでBedrock、CLAUDE_CODE_USE_MANTLEでmantleを有効にします。mantleを有効にして/statusを開くと、プロバイダー行がAmazon Bedrock (Mantle)になります。両方を設定すると、mantle形式のモデルIDはmantleへ、それ以外はInvoke APIへ振り分けられます。/statusはAmazon Bedrock + Amazon Bedrock (Mantle)と表示します。

mantleで403が返ったときは、エラーがbedrock-mantle:の操作名を挙げていればIAMにその権限を足します。操作名が無く認証情報が有効なら、そのモデルへのアクセスがAWSアカウントに付与されていません。

Claude CodeがBedrock・Vertex AI・Microsoft Foundryのどれでどこまで使えるかは提供元ごとに差があります。機能の対応状況はClaude Codeの機能比較 — Bedrock・Vertex・Foundry別対応表で確認できます。Foundry側の設定手順はClaude Code Microsoft Foundry設定ガイドにまとめました。CoworkでもBedrock経由の運用に対応しており、こちらはCoworkをBedrock・Vertex・Foundryで動かす方法で扱っています。

サポートへの問い合わせ先

Anthropicの2つの公式ページで、案内先が違います。サポート記事はAWSサポートかAWSアカウントマネージャーを挙げ、コミュニティ相談にはAWS re:Postを案内しています。

一方、API解説ページはbedrock-ant-eap@amazon.comを窓口とし、AWSアカウントIDと失敗したレスポンスのrequest-idを添えるよう求めています。食い違いの理由はどちらにも書かれていません。障害の切り分けにはAPI解説ページの形式で情報を揃えておくと、どちらの窓口にも渡せます。

Bedrock経由の利用料は返金対象外です。Anthropicと直接契約したプライベートオファーの顧客だけは、Anthropicのリレーションシップマネージャーに相談できます。日本の顧客向けには、法定の基準を超えて日本の消費税の課税事業者になった時点でAnthropicが登録する、という注記がサポート記事にあります(最短で2026会計年度)。

導入でよくあるつまずき

• 拒否が成功に見える: Fable 5のモデルカードによると、分類器がリクエストをブロックしても、HTTP 200でstop_reason: "refusal"が返ります。推論前にブロックされた分は課金されず、生成の途中でブロックされた分は出力済みトークンが課金されます
• グローバルとリージョナルの取り違え: データ所在地の要件がないのにリージョナルエンドポイントを選ぶと、10%の追加料金だけを払うことになります。要件がなければグローバルで十分です

まとめ

依存している機能が「使えない機能」の表に無ければBedrock、あればClaude Platform on AWSを先に確かめる、というのが判断の軸です。モデルの世代でエンドポイント形式が分かれるため、移行前に対象モデルがどちらの形式かも確認しておくと、400エラーの原因を絞れます。