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

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

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

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

Web searchとStructured outputsの2つがGoogle Cloud側に寄っています。逆にBedrockだけが持つ機能は、両者のFeature support節を並べても見当たりません。Bedrockに固有の価値は機能ではなく、AWSの認証・課金・ガバナンスに乗れる点にあります。その話はAmazon Bedrockでの使い方にまとめてあります。

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

共通して使える機能

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

• Messages API
• プロンプトキャッシュ
• Thinking
• ツール使用(Bashツール、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などで本文に含めて送ります。

差が出る機能1: Web search

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

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

動的フィルタリングの仕組みとデータ保持の扱いはweb_searchのdynamic filteringとZDRで扱っています。Google Cloudで検索を使うなら、max_usesで1リクエストあたりの検索回数を絞る設計が、トークン消費を抑える手段の中心になります。

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と結びつける設計も自分で組むことになります。

差が出る機能2: Structured outputs

Structured outputs(output_config.formatによるJSON出力の保証と、strict: trueによるツール入力の検証)は、Google Cloudで対応です。Bedrockは、公式ページの記述が2か所で割れています。

• BedrockのFeature support節: 「非対応の機能」にStructured outputsが挙がる
• Structured outputsのページ: Amazon Bedrockを対応プラットフォームに含め、Opus 4.6、Sonnet 4.6、Sonnet 4.5、Opus 4.5、Haiku 4.5で使えると注記する

Bedrockの対応ページは、/anthropic/v1/messagesを呼ぶ新しいエンドポイント(bedrock-mantle)の説明です。従来のInvokeModel・ConverseによるBedrock統合(Opus 4.6以前)は、別ページに切り出されて残っています。Structured outputs側の注記が挙げるモデルはすべて4.x世代です。両者が旧統合と新エンドポイントの違いに対応しているように見えますが、公式はその対応関係を明記していません。どちらが自分の呼び出し経路に当たるかは、この記述だけでは断定できません。

実務上の扱いは次のとおりです。

1. Bedrockでは、使うモデルとエンドポイントの組み合わせでoutput_config.formatを付けた最小リクエストを先に実行し、エラーの有無を確かめる
2. 通らない場合に備え、プロンプトで形式を指定してクライアント側でスキーマ検証する

2のクライアント側検証は、Bedrock・Google Cloud共通の保険にもなります。次のように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:
    ...  # 再試行、または別モデルへクライアント側でフォールバック

Structured outputsのスキーマ制限とSDKによる自動変換はStructured outputsのJSON Schema制限に詳しくあります。Google Cloudで使う場合も、この制限がそのまま効きます。

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

Google Cloudでは、上記の10モデルが1Mトークンのコンテキストを持ち、Sonnet 4.5など他のモデルは20万トークンです。PDFや画像を大量に載せる場合は、トークン上限より先に30MBのペイロード上限に当たることがあります。

BedrockのAPIページには1Mの対象モデル一覧がありません。ただしBedrockでも1Mは使えないわけではなく、Claude Codeから使う場合はSonnet 5・Opus 4.6以降・Sonnet 4.6が対象で、モデルIDの[1m]サフィックスで有効にします。手順はBedrockとVertexで1Mコンテキストを有効にする方法にあります。Messages APIを直接呼ぶ場合の対象は、このページからは確認できないため、使うモデルで実際に試すのが確実です。

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

リージョンの考え方も違います。Bedrockのグローバルエンドポイントは追加料金なしで、単一リージョン指定のリージョナルエンドポイントには10%の上乗せがあります。Google Cloudもグローバルエンドポイントは上乗せなしで、マルチリージョンとリージョナルに10%かかります。日本国内のデータ所在地要件がある場合の選び方はClaudeを日本から使う提供経路が別の角度から整理しています。

Computer useとBrowser use

• Bedrock: Computer useツールは対応。ただし新しいツールセット(computer_toolset_20260801、browser_toolset_20260801)は使えず、ベータ版のComputer useツールが引き続き使える
• Google Cloud: Computer useツールとBrowser useツールが対応機能に並ぶ

Bedrockでは新ツールセット(browser_toolset_20260801)が非対応の欄に入っています。ブラウザ操作を組み込むエージェントは、Google Cloud側のほうが構成の制約が少ない状態です。

選び分けの早見表

どちらのクラウドにもClaude APIの直接接続のほうが機能は多く、Claude Platform on AWSのようにAnthropicが運営するAWS経路もあります。この違いはClaude Platform on AWSの記事が扱っています。

選ぶ前に自分で確かめる3点

対応表は更新されるため、次の3点は自分の環境で実行して確認するのが確実です。

1. 使うモデルIDで、必要な機能を付けた最小リクエストを1回通す(モデルIDの表記はBedrockがanthropic.接頭辞付き、Vertex側はclaude-opus-5-5のようにそのまま)
2. 長い資料を扱うなら、Google Cloudでは1Mトークンの対象一覧に自分のモデルが入っているかを見る。Bedrockでは1Mが通るかを実際に試す
3. モデル世代を上げる予定があるなら、Claude Codeの/claude-api migrateが、クラウド事業者ごとのモデルID形式と機能差を見て置換してくれる

3つ目は、Bedrock・Google Cloudの双方の公式ページに案内があります。

まとめ

Web searchとStructured outputsを使いたいなら、Google Cloudが選びやすい状態です。ただしWeb searchは基本版のみで、動的フィルタリングは使えません。Bedrockは、この2機能が対応表で欠けるか、ページ間で記述が割れます。

Files API、Message Batches、MCP connector、Agent Skills、Managed Agentsは、どちらのクラウドでも使えません。これらが要件に入っているなら、クラウド経由ではなくClaude APIとの直接接続が候補になります。

機能差で決まらない場合は、認証とデータ所在地の要件が決め手になります。AWSに寄せているならBedrock、Google Cloudに寄せているなら機能面でも有利、という整理が、公式の記述から読み取れる範囲です。