ClaudeをBedrockとGoogle Cloudで使う — API機能の対応差を比較

Amazon BedrockとGoogle Cloud(Agent Platform)は、どちらもClaudeをクラウド事業者経由で呼び出せる経路です。ただしClaude APIの全機能がそのまま載るわけではなく、使える機能の集合が両者で違います。差がはっきり出るのは、Web searchツールです。

新規にAPIアプリを作る開発者が「どちらのクラウドで作り始めるか」を機能面で決められるように、公式の対応表を軸に、両者の違いを見比べます。Claude Codeの機能に絞った対応表はClaude Codeの機能比較にあります。ここではMessages APIを直接叩く場合を扱います。

結論: Web searchはGoogle Cloudだけ、残りの非対応はほぼ共通

差はGoogle Cloud側に寄っています。Features overviewの対応表を見ても、Bedrockだけが対応する機能はありません。Bedrockの強みは機能ではなく、AWSの認証・課金・ログ基盤に乗れる点です。その話はAmazon Bedrockでの使い方にまとめてあります。AWSで機能差を埋める移行先はClaude Platform on AWSへの移行で扱っています。

Bedrockには入口が2つある

Bedrockの機能表を読むときの最初の落とし穴は、Claudeを呼ぶ入口が2系統あることです。機能の有無が入口ごとに変わります。

新しい入口のモデル表にはOpus 4.6・Sonnet 4.6・Opus 4.5・Sonnet 4.5が並びません。これらは従来の統合側で使うモデルです。一方、Opus 5.5・Opus 5・Fable 5.1・Sonnet 5.5などの新しいモデルは、従来側でもInvokeModel経由で呼べます。ただし従来側のページは、完全な機能の対応を見るなら新しい入口のページを参照する、という構成のページです。

どちらの入口にもant CLIは使えません。Google Cloudも同じで、CLIで試したい場合はcURLかSDKを使います。

呼び出しの形そのものも違う

機能の有無だけでなく、リクエストの組み立てが違います。BedrockとGoogle Cloudを両対応にするアプリは、この差をクライアント側で吸収する必要があります。

Bedrockの認証は3系統あります。公式が推奨するのは、AWS管理者が用意するBedrockサービスロールです。次にIAMの引き受けロールで、最大セッションは12時間です。ベアラートークンも最大12時間で、公式の説明では最も推奨度が低い方式です。

両方で使える機能と、両方で使えない機能

共通して使える機能

どちらのFeature support節にも、次の機能が対応として並びます。

• Messages API
• プロンプトキャッシュ
• Thinking
• ツール使用(Bashツール、Browser useツール、Computer useツール、Memoryツール、Text editorツールを含む)
• Citations

クライアント側で完結するツールは通ります。ツールの実行を自分のコードが担う設計なら、どちらのクラウドでも土台は同じです。

両方で使えない機能

次の機能は、BedrockとGoogle Cloudの双方で非対応と明記されています。

• 入力ソース: 画像・ドキュメントのURL指定、Files API
• サーバーサイドツール: コード実行、Web fetch、advisor
• エージェント基盤: Agent Skills、MCP connector、プログラムからのツール呼び出し
• APIエンドポイント: Message Batches、Models、Admin、Compliance、Usage and Cost
• Claude Managed Agents
• サーバーサイドのfallbacksパラメータ

fallbacksは、クライアント側でフォールバックする書き方に置き換えます。大量バッチ処理を安く回したい場合も、Message Batchesが使えないので、通常のリクエストを並列に投げる形になります。画像やPDFはURLで渡せず、Base64などで本文に含めて送ります。

従来のBedrock統合でPDFを渡す場合は、もう1つ条件があります。Converse APIでは、図表やレイアウトの視覚的な解析にCitationsを有効にする必要があり、有効にしないとテキスト抽出だけになります。Citationsを強制されたくない場合は、InvokeModel APIを使います。

Web searchはGoogle Cloudだけで使える

Web searchツールは、Google Cloudでは対応、Bedrockでは非対応です。Web searchのページにも「Amazon Bedrockでは使えない」と書かれています。Claude Mythos Previewでも同じで、Google Cloudでは使え、Bedrockでは使えません。

ただしGoogle Cloudで使えるのは基本版に限られます。web_search_20260209以降が持つ動的フィルタリング(検索結果をコードで絞り込んでからコンテキストに入れる仕組み)は、Google Cloudの対象外です。

動的フィルタリングの仕組みとデータ保持の扱いはweb_searchのdynamic filteringとZDRで扱っています。Google Cloudで検索を使うなら、max_usesで1リクエストあたりの検索回数を絞る書き方があります。Vertex AI側のエンドポイント選びと10%の料金差はVertex AIのClaudeエンドポイント3種にあります。

Vertex側の呼び出し例は次のとおりです(公式の初回リクエストの形にツール定義を足した例)。

from anthropic import AnthropicVertex
 
client = AnthropicVertex(project_id="MY_PROJECT_ID", region="global")
 
message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "今週のClaudeの公式発表をまとめて"}],
    tools=[{"type": "web_search_20250305", "name": "web_search", "max_uses": 3}],
)

Bedrockでは同じリクエストのWeb searchが使えないため、検索は自分のコードで別の検索APIを呼び、結果をプロンプトに渡す構成になります。検索の呼び出し元と課金が自前になり、Claude側のCitationsと結びつける設計も自分で組みます。

Structured outputsは両方で使える

Structured outputs(output_config.formatによるJSON出力の保証と、strict: trueによるツール入力の検証)は、Google Cloudで対応です。Bedrockも、新しい入口(Claude in Amazon Bedrock)と従来の入口(InvokeModel系)のどちらの機能一覧にも対応機能として載っています。入口を理由にStructured outputsを諦める必要はありません。

スキーマの書き方に関する制限と、SDKによる自動変換はStructured outputsのJSON Schema制限に詳しくあります。どちらのクラウドで使う場合も、この制限がそのまま効きます。

ネイティブの保証に加えて、クライアント側でスキーマ検証を重ねる構成も取れます。Pydanticで受ける形が一例です。

from pydantic import BaseModel, ValidationError
 
class Contact(BaseModel):
    name: str
    email: str
    demo_requested: bool
 
try:
    Contact.model_validate_json(message.content[0].text)
except ValidationError:
    ...  # 再試行、または別モデルへクライアント側でフォールバック

コンテキスト長・ペイロード・クォータ

数字で差が出るのは、リクエストの上限とクォータです。

Bedrockのクォータは、Anthropicの追加承認なしに入力500万・出力50万トークン/分まで引き上げを依頼できます。RPM(毎分リクエスト数)の制限はAWS側が課すので、上げたい場合はAWSサポートへの問い合わせです。Google Cloud側のページにクォータの数値は載っていません。

新しい入口のページには1Mの対象モデルの一覧がありません。ただしClaude Codeの公式ドキュメントでは、Sonnet 5はInvoke APIでもMantleエンドポイントでも常に1Mウィンドウで動き、[1m]の変種は選べないとされています。Opus 4.6以降とSonnet 4.6は、モデルIDの[1m]サフィックスで有効にします。手順はBedrockとVertexで1Mコンテキストを有効にする方法にあります。

リージョンの考え方も違います。Bedrockのグローバルエンドポイントは追加料金なしで、単一リージョン指定のリージョナルエンドポイントには10%の上乗せがあります。複数リージョンをまとめて使うときは、US・EU・JP・AUの推論プロファイルを使う形です。Google Cloudもグローバルエンドポイントは上乗せなしで、マルチリージョンとリージョナルに10%かかります。

日本のリージョンはどう扱われるか

データ所在地を日本に寄せたい場合、2社の書き方が違います。

Bedrockでは、東京(ap-northeast-1)がグローバルとJPの推論プロファイル、そして単一リージョンだけで動く「In-region only」に対応します。大阪(ap-northeast-3)はグローバルとJPです。ただしFable 5.1のリージョナルエンドポイントは、現状us-east-1だけです。Mythos Previewもリージョナルのみで、us-east-1で提供されます。従来のBedrock統合では、JPの推論プロファイルに対応するのはOpus 4.6・Sonnet 4.6・Sonnet 4.5です。Opus 4.5とHaiku 4.5は対応しません。

Google Cloudのマルチリージョンは、現状usとeuの2つです。リージョナルエンドポイントは特定のリージョンに固定でき、対象はSonnet 4.6以前のモデルです。それより新しいモデルはグローバルかマルチリージョン(us / eu)で、特定のリージョンだけに固定する選択肢はありません。プロビジョンドスループットもリージョナルが前提で、同じくSonnet 4.6以前が対象です。グローバルとマルチリージョンは従量課金のみです。選び方を別の角度から見るなら、Claudeを日本から使う提供経路が参考になります。

Computer useとBrowser use

• Bedrock: Computer useツールとBrowser useツールのどちらも、Bedrockの対応機能に並ぶ。従来のBedrock統合(InvokeModel)でも、Fable 5.1・Opus 5.5・Sonnet 5.5・Haiku 5.5など8モデルは両ツールセットをベータヘッダーなしで使える
• Google Cloud: Computer useツールとBrowser useツールが対応機能に並ぶ

Browser useもComputer useも、両方の機能一覧に載っています。ブラウザ操作が要るかどうかは、BedrockとGoogle Cloudを選び分ける決め手になりません。確かめるのは使うモデルです。Bedrockでは、Opus 5.5・Sonnet 5.5・Haiku 5.5が旧ツールcomputer_20251124(ベータヘッダーcomputer-use-2025-11-24)も受け付けます。

ログ・アクセス権・データの扱い

機能ではなく運用面でも、2社は少し違います。

BedrockはログをCloudWatchとCloudTrailに出します。Google Cloudはリクエストとレスポンスをログに残すサービスを別に持ちます。この機能を有効にしても、GoogleやAnthropicが内容にアクセスできるようにはなりません。どちらのページも、Anthropicとして少なくとも30日のローリング保持を推奨しています。

データ保持の扱いは、それぞれのクラウド事業者の規定に従います。Anthropicのドキュメントは、BedrockについてはAWSのデータ保護、Google CloudについてはGoogle Cloudのデータガバナンスへ案内しています。

モデルの使い始め方にも差があります。Bedrockはモデルごとにアクセス条件があり、Fable 5.1・Fable 5・Opus 4.8・Sonnet 5・Opus 4.7・Haiku 4.5は全Bedrock顧客に開放されています。Opus 5.5・Opus 5・Sonnet 5.5の条件は、AWSコンソールのモデルアクセス画面で見ます。Mythos系は招待制です。

選び分けの早見表

どちらのクラウドにもClaude APIの直接接続のほうが機能は多く、Claude Platform on AWSのようにAnthropicが運営するAWS経路もあります。Claude Platform on AWSではWeb searchの基本版も動的フィルタリング付きも使えます。この違いはClaude Platform on AWSの記事が扱っています。

作り始める前に試す3点

対応表は更新されるため、使うモデルと入口の組み合わせで実際に通るかを最初に試します。

まとめ

機能で選ぶならGoogle Cloud、AWSの認証とログに寄せるならBedrockです。Bedrockでは、入口とモデル世代の組み合わせが使える機能を決めます。