AI

AWS Bedrockのモデル選定|Claude・Nova・OpenAI・Gemmaの選び分けと切替判断

Amazon Bedrockを導入するとき、最後まで残る問いは「結局どのモデルを選ぶのか」です。カタログには数百のモデルが並び、性能表を眺めても決め手が見えません。実務で選定を分けるのは、ベンチマークのスコアよりもむしろ、そのモデルがどのエンドポイントで提供され、Bedrockのどの機能と組み合わせられ、日本国内のリージョンからどの経路で呼べるかという、地味な3点でした。本記事では2026年8月14日時点の公式モデルカードを直接あたって確認した内容をもとに、発注前に固めておくべき判断軸を整理します。

まとめ|Bedrockのモデル選定は接続方式とデータ所在地で決まる

先に結論を述べます。第一に、モデルの性能差より先に見るべき対象は接続先のエンドポイントになります。bedrock-runtimeで提供されるモデルはGuardrailsやKnowledge base、Agentsといったマネージド機能と組み合わせられますが、bedrock-mantleだけで提供されるモデルはそれらの対象外でした。第二に、日本のデータ所在地要件がある案件では、東京リージョンからどの推論経路を使えるかがモデルを絞り込みます。第三に、束ねて語られがちなGoogleモデルは、Bedrock上ではGemma系であってGemini系ではありません。この3点を先に確定させると、候補は数百から数個まで一気に減ります。細かな料金の計算式と月額試算はAWS Bedrockの料金はいくら?課金方式4種と月額試算に分けて書いたので、費用側はそちらを参照してください。

Bedrockで選べる基盤モデルの全体像とプロバイダー別の守備範囲

2026年8月14日時点で、AWS公式ユーザーガイドの Models at a glance に掲載されているプロバイダーは18社ありました。内訳はAI21 Labs、Amazon、Anthropic、Cohere、DeepSeek、Google、Meta、MiniMax、Mistral AI、Moonshot AI、NVIDIA、OpenAI、Qwen、Stability AI、TwelveLabs、Writer、xAI、Z.AI です。1年前と比べて明らかに増えたのは中国系と欧州系の開発元で、以前は「ClaudeかTitanか」で済んだ選定が、いまは層が厚くなった分だけ迷いやすくなりました。

ただし実際の案件で候補に挙がる系統は限られます。日本語を扱う業務システムで検討対象になるのは、テキスト生成ならAnthropicのClaude系、AWS純正のAmazon Nova系、OpenAIのGPT系、Metaのオープンウェイト系の4つでしょう。埋め込みならAmazon TitanかCohere Embed、再ランキングならCohere Rerank、画像ならAmazon Nova CanvasかStability AI、動画理解ならTwelveLabsという住み分けになります。残りのプロバイダーは、特定の言語や特定のワークロードで既に採用実績がある場合に検討すれば足ります。

選定の出発点として押さえておきたいのは、Bedrockが「単一のAPIでモデルを差し替えられる」という触れ込みで語られてきた点と、2026年時点の実態にはズレがあることです。差し替えが本当に容易なのは同一エンドポイント内に限られます。サービスの概要と開始手順そのものはAmazon Bedrockの使い方|料金・モデル・APIの始め方で扱っているため、本記事では選定の判断だけを追います。

BedrockでGeminiは使えるのか|Googleモデルの提供形態を確認する

「BedrockでGeminiを使いたい」という相談は実際によく受けます。結論から言えば、2026年8月14日時点のBedrockのモデルカタログにGeminiは載っていません。Googleの枠に並ぶのは、Gemma 4系(31B、26B-A4B、E2B)とGemma 3系です。Gemma 4系は2026年6月にBedrockでの一般提供が始まり、Apache 2.0のライセンスで公開されているオープンウェイトモデルにあたります。Gemini本体はGoogle Cloudの Vertex AI 側で提供されているため、Gemini自体が要件であればAWS単独では完結しません。

ここを取り違えると、要件定義の段階で成立しない構成を前提に見積りが動きます。実際にありがちなのは、社内でGeminiの回答品質を評価した後に「本番はAWSに寄せたいのでBedrockで同じモデルを」と話が進むケースでした。Bedrock側にGeminiは無いので、その時点で選択肢は3つに絞られます。Gemma 4系で品質が足りるか検証し直すか、Vertex AIとのマルチクラウド構成を受け入れるか、Claude 5系やGPT-5.6系といった別系統に評価をやり直すかです。

加えて、Gemma 4系はBedrock上での提供のされ方も他と違いました。公式モデルカードによると、Gemma 4 31Bはbedrock-mantleエンドポイントのみで提供され、標準のbedrock-runtimeには載っていません。呼び出しはOpenAI互換のChat CompletionsとResponsesの形式で、BedrockのConverse APIは対象外です。コンテキスト長は256Kトークン、提供リージョンは us-east-1、us-east-2、us-west-2、eu-central-1 の4つで、東京リージョンは含まれていませんでした。オープンウェイトで安価という利点はあるものの、既存のBedrock構成にそのまま差し込める部品ではないと考えたほうが安全でしょう。

Claude系とNova系とOpenAI系とGemma系を用途に落とす比較表

主要4系統の守備範囲を、2026年8月14日時点のモデルカード実測値で並べます。数値は代表モデル1本を基準にしたもので、同じ系統でも下位モデルでは条件が変わる点は補足しておきます。

モデル系統 主な用途 接続先エンドポイント 東京リージョン経路
Claude 5系(Sonnet 5他) 長文読解・エージェント runtime と mantle Globalのみ
Amazon Nova 2系 大量処理・費用の圧縮 runtime のみ jp.プロファイル可
OpenAI GPT-5.6系 推論・コーディング mantle 中心 要個別確認
Google Gemma 4系 軽量・自社検証向け mantle のみ 提供リージョン外
Meta Llama 4系 オープンウェイト前提 runtime 要個別確認

Claude 5系の代表であるClaude Sonnet 5は、コンテキスト長1Mトークン、最大出力128Kトークン、知識のカットオフは2026年1月と記載されていました。bedrock-runtimebedrock-mantleの両方に載っており、Converse・Invoke・Messagesの3つのAPI形式で呼べます。プロンプトキャッシュにも対応し、キャッシュの最小単位は4,096トークン、保持時間は5分と1時間の2種類でした。長い仕様書や契約書を丸ごと読ませて判断させる用途では、この系統が現時点で扱いやすい選択になります。

Amazon Nova 2系の代表であるNova 2 Liteは、コンテキスト長1Mトークン、最大出力64Kトークン、テキストに加えて画像と動画を入力に取れます。モデルIDはamazon.nova-2-lite-v1:0で、bedrock-runtimeのConverse APIから素直に呼べました。ただしKnowledge baseとAgentsとFlowsは非対応と明記されており、Bedrockのマネージド機能を土台に組む構成には向きません。大量の定型処理を安く回す層として位置づけるのが現実的だと考えます。

OpenAI系はGPT-5.6のSol・Terra・Lunaという3段構成に、GPT-5.5とGPT-5.4、そしてオープンウェイトのgpt-oss系とGPT OSS Safeguard系が並びます。Solが最上位、Terraが日常的な本番処理向け、Lunaが高速で安価な大量処理向けという位置づけでした。サイバーセキュリティ用途の派生モデルは個別の利用申請が要る旨も記載されています。

bedrock-runtimeとbedrock-mantleで使える機能が変わる境目

選定でいちばん見落とされるのがこの境目です。Bedrockにはbedrock-runtimebedrock-mantleという2系統のエンドポイントがあり、同じモデルでもどちらから呼ぶかでBedrock側の機能の効き方が変わります。Claude Sonnet 5のモデルカードには両方の対応表が併記されており、差は明確でした。

bedrock-runtimeから呼んだ場合、Guardrails、Knowledge base、Agents、Flows、Model evaluation、Prompt management、Prompt optimizationが対応と記載されています。一方bedrock-mantleから呼んだ場合、これらはすべて非対応で、代わりにトークン数の事前カウントが使えるようになっていました。つまりコンテンツフィルタをBedrock側で強制したい案件や、マネージドのナレッジベースでRAGを組む案件では、bedrock-mantleだけで提供されるモデルは土台から外れます。

この差は運用の現場で無視できない違いです。たとえば入力の検閲をGuardrailsに寄せる設計をしていた場合、後からGemma 4系に切り替えようとすると検閲層ごとの作り直しが必要です。フィルタの設計そのものはAmazon Bedrock Guardrails(ガードレール)とはで詳しく扱っていますが、選定段階では「そのモデルがGuardrailsの対象かどうか」を先に確認しておくだけで手戻りを避けられます。同様に、マネージドのナレッジベースを前提にRAGを組むならAmazon BedrockでRAGを実装する手順の構成が使えるモデルに候補が絞られますし、実装の書き味はAmazon Bedrock Converse APIの使い方で確認できます。

もうひとつ、サービスティアの対応にも差がありました。Bedrockには Standard、Priority、Flex、Reserved の4つのティアがあります。Nova 2 LiteとGemma 4 31Bは Standard・Priority・Flex の3つに対応していた一方、Claude Sonnet 5は Standard のみでした。夜間バッチを安いFlexに寄せて費用を圧縮する打ち手は、モデルによっては取れません。この点も含めた費用設計はBedrockの料金と課金方式の記事に分けてあります。

東京リージョンで動かせるか|In-RegionとGeoとGlobalの違い

国内案件では、ここが実質的な足切り条件です。Bedrockの推論経路は3種類あり、In-Regionは単一リージョン内で完結、Geo Cross-Regionは同一地域内の複数リージョンへ振り分け、Global Cross-Regionは世界中のどこへでも振り分けます。データの所在地に制約がある案件では、後ろの2つをそのまま採れないことがあります。

Claude Sonnet 5のリージョン表を見ると、東京(ap-northeast-1)はIn-Regionが非対応、Geoも非対応で、対応しているのはGlobalだけでした。Geo推論のプロファイルは米国・EU・オーストラリアの3地域に用意されており、日本向けのGeoは無い状態です。つまり東京リージョンのアカウントからClaude Sonnet 5を呼ぶと、リクエストは世界のどこかへ振り分けられます。

対照的にNova 2 Liteにはjp.amazon.nova-2-lite-v1:0というJP Geoのプロファイルがあり、送信元が東京の場合の振り分け先は東京と大阪に限定されると明記されていました。国内にデータを留めたい要件があるなら、この一点だけでNova 2系が選定の中心に来ます。逆にそうした制約が無いのであれば、Globalを許容してClaude 5系の読解力を取るほうが素直でしょう。要件を先に確認せずにモデルを決めると、この段階で全部やり直しになります。

なお、リージョン対応は月単位で更新されます。本記事の記載も2026年8月14日時点の実測であり、提案書に載せる際は各モデルカードのリージョン表を都度あたり直してください。AWS全体のリージョン選定と移行の考え方はクラウドとは?AWSとは何かを事業者向けに解説にまとめてあります。

Claude CodeをBedrockで動かすときのモデル指定とつまずき

開発現場側の需要として、コーディング支援のClaude CodeをBedrock経由で使いたいという要望も増えています。社内の資格情報をAWSに寄せたまま使えるので、統制の観点では扱いやすい構成です。設定自体は環境変数で完結し、CLAUDE_CODE_USE_BEDROCKを1にしてAWS_REGIONを指定すれば動きます。IAM側にはbedrock:InvokeModelbedrock:InvokeModelWithResponseStream、推論プロファイルの参照権限が要ります。

つまずきやすいのはモデルの指定でした。バージョンを固定しない場合、sonnetやopusといった別名はClaude Code側の既定値に解決されます。既定値が自社アカウントで有効化されていないと、起動時に別のモデルへ自動的に切り替わります。複数人へ配る前提なら、ANTHROPIC_DEFAULT_OPUS_MODELANTHROPIC_DEFAULT_SONNET_MODELに推論プロファイルIDを明示して固定しておくのが安全です。上位モデルは単価が高いため、固定を怠ると想定外の請求につながります。

もうひとつの注意点として、Claude CodeはBedrockのInvoke APIを使っており、Converse APIには対応していません。またWeb検索のツールはBedrock経由では利用できない旨も明記されています。自社アプリの実装でConverse APIに寄せていても、Claude Code側の挙動は別物だと切り分けて考えてください。エージェントを本番運用に載せる場合の全体像はAmazon Bedrock AgentCore APIの使い方を参照すると整理しやすくなります。

マルチモデル運用へ踏み切る条件と単一モデルで止めるべき場面の線引き

複数のモデルを使い分ける構成は魅力的に見えますが、運用の手間が素直に倍増する構成です。ここは言い切っておきます。マルチモデル運用に踏み切ってよいのは、次の3条件がすべて揃ったときだけだと考えています。

  • ワークロードが明確に2種類以上に分かれ、片方が月間で数千万トークン規模に達している
  • 切り替え対象のモデルが同一エンドポイントに載っており、周辺機能の対応状況も一致している
  • 出力品質の劣化を検知する評価の仕組みが、人手の目視ではなく仕組みとして回っている

逆に、次のいずれかに当てはまる場面では単一モデルで止めるべきです。月間のトークン消費が数百万規模にとどまる場合、切替で浮く金額より運用工数のほうが高くつくためです。エンドポイントをまたぐ切替を計画している場合、Guardrailsや評価の仕組みを二重に持つことになり、事故の起点が増えます。そして評価の基準が「担当者が読んで違和感がないこと」しか無い場合、モデルを増やすと品質の説明責任が果たせなくなります。

実務的にすすめやすい形は、まず単一モデルで本番を立ち上げ、稼働ログから処理を分類し、明らかに単純な処理だけを安価な系統へ切り出す順序です。最初から2本立てで設計すると、どちらの品質問題なのか切り分けられない状態で運用が始まります。段階的に進める前提で構成を組みたい場合は、生成AI導入支援で要件整理から本番運用までを一貫して引き受けています。

モデル選定を発注前に固める進め方と見積り段階で確認する項目一覧

選定を発注前に固めるなら、順序を守るだけで手戻りがほぼ消えます。実際に案件で使っている進め方は次のとおりです。まずデータの所在地要件を確定し、次に必要なBedrock機能を列挙し、その2つで候補を絞ってから、残った候補だけで品質を評価します。品質評価を先にやると、通らない構成のモデルを気に入ってしまう事故が起きました。

見積り段階で確認しておく項目は5つです。第一に、提案されたモデルの提供エンドポイントと、それが自社の必須機能に対応しているか。第二に、東京リージョンからの推論経路と、データが国外へ出る可能性の有無。第三に、モデルのバージョン固定の方針と、上位版が出たときの切替手順。第四に、サービスティアの対応状況と、バッチ処理を安いティアへ寄せられるかどうか。第五に、モデルの提供終了が告知された場合の移行計画です。

特に5つ目は見落とされがちです。モデルカードには提供終了日の欄があり、2026年8月時点の主要モデルはいずれも未設定でしたが、旧世代のモデルは順次入れ替わっています。契約書の保守範囲に「モデル入れ替え時の再検証」を含めるかどうかを、発注前に握っておくと後が楽になります。

よくある質問

BedrockでGeminiを使うことはできますか?

2026年8月14日時点のBedrockのモデルカタログにGeminiは含まれていません。Google枠で提供されているのはGemma 4系とGemma 3系というオープンウェイトのモデルです。Gemini本体が要件であればGoogle CloudのVertex AIを併用する構成になります。

Claude系とNova系はどちらを選べばよいですか?

日本国内にデータを留める要件があるならNova 2系が有利です。JP Geoのプロファイルがあり、東京と大阪の範囲で振り分けが完結します。長文の読解や複雑な判断が主目的で所在地の制約が無いなら、Claude 5系のほうが扱いやすいでしょう。

後からモデルを差し替えるのは簡単ですか?

同一エンドポイント内で、かつ周辺機能の対応状況が一致している場合は比較的容易です。bedrock-runtimeからbedrock-mantleへ、あるいはその逆へ移る場合は、呼び出し形式もGuardrailsの効き方も変わるため作り直しに近い作業になります。

OpenAIのモデルをBedrockで使う利点はどこにありますか?

AWSの資格情報と請求のまま利用でき、外部への接続経路を増やさずに済む点です。すでにAWS上で統制を組んでいる組織では、この一点だけで採用理由になります。ただし提供エンドポイントの制約は個別に確認してください。

モデル選定はどの段階で確定させるべきですか?

要件定義の後半、アーキテクチャ設計に入る前が目安です。データ所在地と必須機能の2条件で候補を絞ってから品質評価に進むと、評価のやり直しが起きません。逆に評価を先行させると、構成上採用できないモデルを基準にしてしまいます。

関連記事

資料請求

RELATED POSTS 関連記事