本文へ移動
Amazon Watch Japan Amazon.com, Inc.(AMZN)の製品、サービス、...

Gemma 4がAmazon Bedrockで提供開始:3モデルの違い、bedrock-mantle、東京リージョン未対応を確認

Gemma 4がAmazon Bedrockで提供開始:3モデルの違い、bedrock-mantle、東京リージョン未対応を確認の判断ポイントを表す抽象サムネイル

3行まとめ

VisualGemma 4導入前の3点整理Bedrockで試す前に、モデル、API、リージョンを分けて確認します。
3モデルが追加

`google.gemma-4-31b`、`google.gemma-4-26b-a4b`、`google.gemma-4-e2b`をBedrockで検証できます。

`bedrock-mantle`専用

`openai/v1/responses` pathを使うため、通常のBedrock RuntimeやConverse前提の実装とは分けて確認します。

東京リージョン未対応

2026年6月16日午前時点では4リージョンで確認され、日本からのPoCでは所在地、レイテンシ、料金を先に見ます。

名前だけで選ばず、モデルID、endpoint、リージョン、料金を同じチェックリストで確認します。

  • AWSは2026年6月10日、Google DeepMindのopen-weightモデルファミリー「Gemma 4」をAmazon Bedrockで利用可能にしたと発表しました。対象はgoogle.gemma-4-31bgoogle.gemma-4-26b-a4bgoogle.gemma-4-e2bの3モデルです。
  • 実装前の重要点は、Gemma 4がbedrock-mantle endpoint専用で、openai/v1/responses pathを使うことです。Responses APIとChat Completions APIには対応しますが、通常のbedrock-runtimeやConverse前提の実装とは分けて確認する必要があります。
  • 提供リージョンは米国東部2リージョン、米国西部オレゴン、欧州フランクフルトの4つです。2026年6月16日午前時点で東京リージョンは確認できないため、日本の開発者はデータ所在地、レイテンシ、社内規程、料金を先に確認してからPoCへ進むのが安全です。

AWSのモデル追加は、名前だけ見ると「Bedrockで選べるモデルがまた増えた」というニュースに見えます。けれども今回のGemma 4は、導入前に見ておくべき点がはっきりしています。3モデルの位置づけ、bedrock-mantle endpoint専用、OpenAI互換APIの扱い、Geo/Global推論非対応、東京リージョン未対応。ここを混ぜて読むと、PoCの初日に「いつものBedrock呼び出しで動かない」「東京で試せない」「価格比較がまだ固まっていない」とつまずきます。

この記事では、直近72時間の需要シグナルとしてAWS What’s Newの掲載、2026年6月15日のAWS Weekly Roundupでの再掲、AWS News Feedや開発者コミュニティでの話題化を確認しました。ただし、仕様の根拠はAWS公式のWhat’s New、Amazon Bedrockのモデルカード、リージョン対応ドキュメント、Bedrock Pricingページに寄せています。SNSやコミュニティ投稿は「読者が何を知りたがっているか」を見る材料であり、仕様断定の根拠にはしません。

Gemma 4のBedrock提供でまず変わること

Visual発表後に確認する5つの入口ニュース本文とモデルカードで、確認すべき情報の役割を分けます。
公式発表

AWS What’s Newで、Bedrock提供開始、3つのvariant、対応リージョンを確認します。

モデルの位置づけ

31B、26B-A4B、E2Bを、品質期待、応答速度、PoCの軽さで分けて見ます。

対応領域

reasoning、マルチモーダル入力、agentic、coding-heavy workloadsなどの説明を入口として読みます。

モデルカード

モデルID、endpoint、API path、service tier、payload制限はモデルカードで確認します。

需要シグナル

Weekly Roundupでの再掲や開発者コミュニティの反応は、検証優先度を決める材料として扱います。

発表文は概要、モデルカードは実装条件として読み分けると、PoCの確認漏れを減らせます。

今回の発表で変わるのは、Google DeepMindのopen-weightモデルファミリーを、Amazon Bedrockの管理された推論環境から選べるようになったことです。AWS What’s Newは、Gemma 4を reasoning、multimodal understanding、agentic、software engineering workflows に使えるモデルファミリーとして紹介しています。

まず確認したいのは、発表ページだけで終わらせないことです。What’s Newでは、3つのvariant、35以上の言語、マルチモーダル入力、提供リージョンがまとまっています。一方で、モデルID、endpoint、API path、service tier、payload制限、reasoningの返り方はモデルカード側で確認する領域です。実装者にとっては、後者のほうが初日の成否に直結します。

AWS What’s Newで確認できる発表内容

AWSの2026年6月10日付けWhat’s Newでは、Gemma 4 familyとして3モデルがAmazon Bedrockで利用可能になったと説明されています。3モデルは、Gemma 4 31B、Gemma 4 26B-A4B、Gemma 4 E2Bです。

発表文では、Gemma 4 31Bはreasoningやcoding-heavy workloads向け、Gemma 4 26B-A4Bはcost and latency-sensitive workloads向け、Gemma 4 E2Bは低レイテンシの対話的ユースケース向けと位置づけられています。これだけを見ると「大きい順に性能が高い」と読みたくなりますが、実務ではそう単純ではありません。最初に見るべきなのは、自社の用途が精度優先なのか、応答速度優先なのか、長いコンテキストを使うのか、tool callingやstructured outputをどこまで使うのかです。

また、発表ページでは提供リージョンがUS East (N. Virginia)、US East (Ohio)、US West (Oregon)、Europe (Frankfurt)とされています。日本の読者にとって一番大きい確認点はここです。東京リージョンや大阪リージョンでの提供は、この発表ページとモデルカードからは確認できません。

Weekly Roundup再掲は需要シグナルとして読む

2026年6月15日のAWS Weekly Roundupでも、Gemma 4 on Bedrockが取り上げられています。これは「すでに公式発表済みの話題が、翌週のAWSまとめでも再掲された」という意味では重要です。開発者が新モデルの選定、価格、API対応を確認したがっているという需要シグナルになります。

ただし、Weekly Roundupは仕様表ではありません。モデルIDや対応API、リージョンの最終確認は、モデルカードやリージョン対応表へ戻るべきです。Amazon Watch Japanでは、こうした再掲やコミュニティの反応を「需要の強さ」として扱い、事実認定は一次情報で切り分けます。

3モデルの違いをどう見るか

VisualGemma 4の3モデル比較最初の検証では、公式の位置づけをそのまま本番判断にせず、同じ条件で実測します。
モデルIDまず試す場面確認する軸
`google.gemma-4-31b`複雑な指示、長文、コードや設計文書の検証品質期待、レイテンシ、料金
`google.gemma-4-26b-a4b`コストとレイテンシを意識した業務タスク品質差、応答速度、運用しやすさ
`google.gemma-4-e2b`低レイテンシの対話や軽量なPoC速度、費用感、用途の限界

用途や制約で候補が変わるため、単純な勝敗ではなく、同じプロンプト、同じリージョン、同じservice tierで比べます。

Gemma 4を試すときは、まず3モデルを同じ土俵に置いて比較します。今回のモデルカードで確認できるモデルIDは、google.gemma-4-31bgoogle.gemma-4-26b-a4bgoogle.gemma-4-e2bです。どれもbedrock-mantle endpointから呼び出す前提で、Responses APIとChat Completions APIに対応します。

大事なのは、モデルの説明をそのまま本番判断にしないことです。モデルカードは入口です。実際には同じプロンプト、同じリージョン、同じservice tier、同じログ観測で比べないと、品質、レイテンシ、コストの差は見えません。

google.gemma-4-31bを選ぶ場面

評価基準

Gemma 4 31Bは、30.7B parameterのdense modelとして説明されています。モデルカードでは、built-in reasoning、native function calling、multimodal input、256K token context windowが確認できます。最初に試すなら、複雑な指示、長い文脈、コードや設計文書の要約、多言語応答、tool callingの品質を厚めに見る検証に向いています。

ただし、31Bを最初から本番候補に固定するのは早いです。大きなモデルを選ぶと、期待品質は上がる一方で、レイテンシや料金の確認が重くなります。PoCの初期段階では、31Bを基準モデルとして置き、26B-A4BやE2Bとの差を実測する形が扱いやすいでしょう。

google.gemma-4-26b-a4bを選ぶ場面

確認項目

Gemma 4 26B-A4Bは、25.2B total parameters、3.8B active per tokenのmixture-of-experts modelとして説明されています。256K token context windowを持ち、built-in reasoning、native function calling、multimodal inputを確認できます。

このモデルは、31Bほど重い候補から少し下げつつ、E2Bほど軽量に振り切らない中間候補として読みます。社内ナレッジ検索、問い合わせ対応、ドキュメント処理、開発支援など、一定の品質が必要で、同時に応答速度やコストも見たい場面で比較対象に入りやすいモデルです。

比較するときは、31Bと同じ入力、同じ出力条件、同じリージョンで試してください。片方だけ短いプロンプト、片方だけ違うservice tierにすると、モデル差ではなく条件差を見てしまいます。

google.gemma-4-e2bを選ぶ場面

注意点

Gemma 4 E2Bは、5.1B total parameters、2.3B effective parameters using Per-Layer Embeddingsとして説明されています。モデルカードでは、low-latency workloads向け、128K token context window、built-in reasoning、native function calling、multimodal inputを確認できます。

E2Bは、UIに組み込む対話、軽量な社内ツール、分類や短い生成、検証時の反復に向く候補です。すぐに試して、ログを集め、ユーザーの反応を見るには扱いやすいはずです。一方で、長い文脈の推論、厳密なコード生成、複雑な意思決定支援では、31Bや26B-A4Bとの品質差を見てから判断する必要があります。

E2Bで見落としやすいのはreasoning effortです。モデルカードでは、Gemma 4 E2Bについてreasoning_efforthighにする推奨が記載されています。理由は、thinking modeを有効にし、推論内容を専用チャネル側へ分け、最終回答に推論テキストが混ざるのを避けるためです。既存アプリにそのまま挿す前に、応答形式を必ず確認してください。

bedrock-mantle endpoint専用で確認するAPIまわり

VisualGemma 4 API確認フロー通常のBedrock Runtime前提で進めず、endpointから順に確認します。
  1. 1`bedrock-mantle` endpoint

    Gemma 4は`bedrock-mantle` endpoint専用として確認します。

  2. 2`openai/v1/responses` path

    In-Region endpoint URLとpathを、モデルカードのProgrammatic Accessで確認します。

  3. 3Responses API

    reasoning contentの扱いを確認したい場合は、Responses API側の返り方を見ます。

  4. 4Chat Completions API

    既存のOpenAI互換チャット実装を使う場合も、base URLと認証先はBedrock側に合わせます。

  5. 5service tiersと制約

    Standard、Priority、Flex、Reserved非対応、parallel tool callsなどの制約を先に確認します。

SDKの見た目だけで判断せず、base URL、認証、path、APIごとの返り方を分けて検証します。

今回のGemma 4で、実装者が最も注意すべき点はendpointです。モデルカードには、Gemma 4 models are available only on the bedrock-mantle endpoint と明記されています。通常のBedrock runtimeやConverse APIを前提にした実装と同じ気分で進めると、最初の呼び出しで詰まります。

モデルカードのprogrammatic accessでは、In-Region endpoint URLとしてhttps://bedrock-mantle.{region}.api.aws/openai/v1が示されています。さらに、openai/v1/responses path on the bedrock-mantle endpointで利用できること、他モデルのResponses endpointで使うv1/responses pathとは異なることも説明されています。

Responses APIで試す場合

根拠

Responses APIを使う場合、モデルカードのサンプルはOpenAI SDKのclient.responses.create形式を示しています。ここで大事なのは、SDK名だけを見て「OpenAIへ投げる」と誤解しないことです。base URLはBedrockのbedrock-mantle endpointに向け、認証もBedrock側のAPI key前提で確認します。

Responses APIを選ぶ理由は、reasoning内容の扱いにもあります。モデルカードでは、reasoning effortはChat CompletionsとResponsesの両方でhonoredされる一方、reasoning contentが返るのはResponses API側であり、Chat Completions APIではOpenAI Chat Completions specification上の制約でreasoning tokensを返さないと説明されています。推論過程を監査したい、評価ログに残したい、アプリ内で別扱いしたい場合は、Responses APIから検証するほうが自然です。

Chat Completions APIで試す場合

注意点

Chat Completions APIにも対応しています。既存のOpenAI互換チャット実装を持っているチームにとっては、こちらのほうがPoCの心理的ハードルは低いでしょう。

ただし、既存コードのbase URL、認証、モデル名、レスポンス処理、エラーハンドリングを見直す必要があります。modelにはGemma 4のモデルIDを指定し、OPENAI_BASE_URLhttps://bedrock-mantle.<your-region>.api.aws/openai/v1へ向ける形になります。使うリージョンがGemma 4対応リージョンでなければ、当然ながら呼び出しは成立しません。

また、parallel tool callsにも注意が必要です。モデルカードのUsage Considerationsでは、1ターンで複数のtool callを要求することは現時点でサポートされず、tool callは一度に1つずつ要求するよう記載されています。複数ツールを並列に投げるエージェント設計をしている場合は、Gemma 4用に実行計画を調整する必要があります。

service tiersとReserved非対応

確認項目

Gemma 4のモデルカードでは、Standard、Priority、Flexが利用可能で、Reservedは非対応として示されています。Standardはコミットメントなしのpay-per-token、Priorityは時間ベースのコミットメントで高スループット、Flexは柔軟で時間に厳しくないワークロード向けの低コストアクセスと説明されています。

PoCではStandardから始めるのが自然です。負荷試験やピーク時間帯の応答を見たいならPriorityが候補になり、バッチ的な処理や急がない生成ならFlexを検討できます。Reserved前提で予算やスループット計画を組んでいるチームは、Gemma 4ではその前提を使えない点に注意してください。

リージョンは4つ、東京リージョンは未対応

VisualGemma 4の提供リージョン確認表日本から試す場合は、東京リージョンの有無と海外リージョン利用の前提を先に確認します。
リージョン名リージョンコード導入前の見方
US East (N. Virginia)`us-east-1`最初の検証候補になりやすい米国東部リージョン
US East (Ohio)`us-east-2`米国東部内の別候補
US West (Oregon)`us-west-2`米国西部側の候補
Europe (Frankfurt)`eu-central-1`欧州内で試す場合の候補
Asia Pacific (Tokyo)`ap-northeast-1`2026年6月16日午前時点では未確認

海外リージョンでPoCできる場合でも、データ所在地、契約上の制約、レイテンシ、ログ保存、周辺AWSサービスとの距離を先に確認します。

日本の読者にとって、今回の記事で一番大きな実務ポイントはリージョンです。AWS What’s Newとモデルカードで確認できる提供リージョンは、us-east-1us-east-2us-west-2eu-central-1です。東京リージョンのap-northeast-1は、2026年6月16日午前時点でGemma 4の対象として確認できません。

これは「日本から絶対に使えない」という意味ではありません。海外リージョンでPoCする選択肢はあります。ただし、本番導入を考えるなら、データ所在地、契約上の制約、レイテンシ、ログ保存、既存のBedrock運用、周辺AWSサービスとの距離を先に確認する必要があります。

提供リージョン一覧

確認項目

確認できる対象リージョンは次の4つです。

リージョン名リージョンコード読み方
US East (N. Virginia)us-east-1最初の検証候補になりやすい米国東部リージョン
US East (Ohio)us-east-2米国東部内の別候補
US West (Oregon)us-west-2米国西部側の候補
Europe (Frankfurt)eu-central-1欧州内で試す場合の候補

東京、ソウル、シンガポール、シドニーなどを勝手に追加してはいけません。Bedrockのモデル対応はモデルごとに異なり、同じBedrockで使える別モデルが東京にあっても、Gemma 4も同じとは限りません。

東京リージョン前提のシステムで困る点

条件

東京リージョン前提のシステムでは、まずデータの扱いが問題になります。プロンプトや出力を海外リージョンで処理してよいのか、社内規程や顧客契約に抵触しないのかを確認してください。個人情報、契約情報、機密コード、未公開の製品情報を扱う場合は、PoCでも判断が必要です。

次にレイテンシです。チャットUIやエージェントUIは、数百ミリ秒の差でも体感に出ます。米国や欧州リージョンに推論を投げる構成では、ネットワーク往復、認証、ストリーミング応答、ログ書き込みまで含めて測らないと、実際の利用感が見えません。

もうひとつは運用統合です。CloudWatch、IAM、VPC、ログ保管、監査、既存のBedrock利用ルールが東京リージョン中心に組まれている場合、Gemma 4のPoCだけ別リージョンで動かすことで運用が分かれます。導入判断では、モデルの性能だけでなく、この運用差分も評価に入れるべきです。

In-Regionのみとして読む

注意点

Amazon Bedrockのリージョン対応ドキュメントでは、推論の選択肢としてIn-Region、Geographic、Globalが説明されています。In-Regionは指定した単一リージョン内で処理する方式、Geographicは地理的範囲内でルーティングする方式、Globalは商用リージョン横断でルーティングする方式です。

Gemma 4のモデルカードでは、4リージョンのIn-Regionに対応し、Geo inference IDとGlobal inference IDはNot supportedと示されています。つまり、現時点では「東京からGlobal inferenceで柔軟に逃がす」「日本地理内のGeo routingで処理する」といった読み方はできません。

この点は、データレジデンシや監査要件に関わります。海外リージョンでIn-Region処理できることと、日本国内で処理できることは別です。日本企業のPoCでは、使うデータを匿名化する、サンプルデータだけにする、社内承認を取るなど、モデル評価の前に運用条件を整えるほうが安全です。

料金確認はモデル選定の最後ではなく最初に入れる

VisualPoC前の料金確認フロー固定単価を本文で断定せず、見積もりに必要な確認順序を整理します。
  1. 1Bedrock Pricingを開く

    モデルカードのPricing欄から、最新のAmazon Bedrock Pricingページを確認します。

  2. 2モデルとリージョン

    31B、26B-A4B、E2Bと対象リージョンを分けて見ます。

  3. 3service tier

    Standard、Priority、Flexで、コストとスループットの前提を分けます。

  4. 4入出力トークン

    長文プロンプト、RAG、生成量の多いアプリでは、入力と出力を別々に見積もります。

  5. 5利用量と監視

    1日あたりのリクエスト数、CloudWatch、評価ログ、監査ログを合わせて確認します。

価格はリージョン、モデル、service tier、入出力トークン、利用量で変わるため、PoC前に最新ページで再確認します。

Gemma 4を試すなら、料金確認は最後ではなく最初に入れてください。モデルカードはPricing欄でAmazon Bedrock Pricingページを参照するよう案内しています。ただし、本稿執筆時点では取得できたページ本文からGemma 4の価格行を安定して確認できなかったため、この記事では固定の単価を断定しません。

価格を載せないのは、情報を避けているからではありません。Bedrockの価格はリージョン、モデル、service tier、入出力トークン、場合によってはキャッシュやバッチ、推論方式で変わります。数字を本文に固定して古くするより、読者が本番前に確認する順序を残すほうが実用的です。

記事内で価格を断定しない理由

根拠

今回確認したGemma 4のモデルカードでは、Pricing欄がAmazon Bedrock Pricingページへの参照になっています。検索結果断片ではGemma 4の価格らしき行が見える場面もありましたが、記事本文に固定するには、公開ページの本文から安定して再確認できる必要があります。

そのため、この記事では「Gemma 4は安い」「31Bでも十分安い」「E2Bならこの単価で使える」といった断定を避けます。導入担当者は、PoC前にpricing pageで対象リージョン、モデル、service tier、入出力トークン単価を確認し、社内の想定利用量で見積もってください。

PoC前に作るミニ見積もり

確認項目

PoCの前に、簡単な見積もり表を作るだけで失敗はかなり減ります。最低限、次の項目を並べてください。

確認項目見る理由
対象モデル31B、26B-A4B、E2Bで単価、品質、速度の前提が変わるため
対象リージョンGemma 4は4リージョン確認で、東京未対応のため
service tierStandard、Priority、Flexでコストとスループットの期待値が変わるため
1リクエストの入力トークン長文プロンプトやRAGでコストが膨らむため
1リクエストの出力トークン生成量が多いアプリほど費用に効くため
1日あたりのリクエスト数PoCと本番で費用感がまったく変わるため
監視とログCloudWatchや評価ログの設計を後回しにしないため

この見積もりは、厳密な財務モデルである必要はありません。目的は、PoCを始める前に「このモデルをこのリージョンでこの回数使うと、どのくらいの幅になるか」を全員で見えるようにすることです。

導入前チェックリスト

VisualGemma 4導入前チェックリスト開発者と導入判断者が、最初の確認作業へ移れるように項目を分けます。
確認項目見る場所未確認時のリスク
モデルID各Gemma 4モデルカードmodel名の指定ミスで呼び出しに失敗する
endpointProgrammatic Access`bedrock-runtime`前提で実装して詰まる
API path`openai/v1/responses`他モデルのResponses pathと混同する
対応APIAPIs supportedConverseやInvoke前提の設計をしてしまう
リージョンWhat’s Newとモデルカード東京前提で検証計画を作ってしまう
reasoningの返り方Usage ConsiderationsChat Completionsでreasoning contentが返ると誤解する
tool callUsage Considerations複数tool callを1ターンで要求して失敗する
料金Bedrock PricingPoCと本番の費用感を取り違える

日本国内処理が必須か、海外リージョンでPoCしてよいかを決めてから、品質、速度、コスト、運用制約を同じ基準で比較します。

Gemma 4は、Bedrockの新しい選択肢として魅力があります。open-weightモデルを管理されたBedrock環境で扱えること、OpenAI互換APIの形で呼び出せること、reasoningやfunction callingを確認できることは、開発者にとって試す価値があります。

一方で、導入判断には慎重さも必要です。東京リージョン未対応、bedrock-mantle専用、Geo/Global inference IDなし、parallel tool callsの制約、価格の事前確認。ここを先に見ておけば、PoCはずっと進めやすくなります。

開発者が最初に確認すること

確認項目

開発者は、最初の1時間で次の項目を確認してください。

項目確認先未確認時のリスク
モデルID各Gemma 4モデルカードmodel名の指定ミスで呼び出しに失敗する
endpointモデルカードのProgrammatic Accessbedrock-runtime前提で実装して詰まる
API pathopenai/v1/responses他モデルのResponses pathと混同する
対応APIモデルカードのAPIs supportedConverseやInvoke前提の設計をしてしまう
リージョンWhat’s Newとモデルカード東京前提で検証計画を作ってしまう
reasoningの返り方Usage ConsiderationsChat Completionsでreasoning contentが返ると誤解する
tool callUsage Considerations複数tool callを1ターンで要求して失敗する
request payload sizeUsage Considerations画像や動画を含む入力で上限に当たる

特に、既存のOpenAI互換呼び出しを流用するチームは、base URL、モデルID、認証、レスポンス形式の4点を必ずログに残してください。動いたかどうかだけでなく、どのendpointへ、どのリージョンで、どのAPI形式で投げたかが後から追える状態にします。

導入判断者が確認すること

評価基準

導入判断者は、モデル性能だけを見ないほうが安全です。社内利用では、次の確認が先に来ます。

  • 日本国内処理が必須か、海外リージョンでPoCしてよいか。
  • プロンプトに個人情報、顧客情報、機密コード、未公開資料を含めるか。
  • Gemma 4を使う理由が、既存のBedrockモデルや他のopen-weightモデルとの差として説明できるか。
  • Standard、Priority、Flexのどれで試し、どの段階で料金を再確認するか。
  • CloudWatch、評価ログ、監査ログ、エラー時の再試行をどう扱うか。
  • 31B、26B-A4B、E2Bの比較基準を、品質、速度、コスト、運用制約に分けているか。

Bedrockの新モデルは、出た瞬間に試したくなります。そこは健全な好奇心です。ただ、社内導入では「動いた」だけでは足りません。どのデータを、どのリージョンで、どの料金前提で、どのAPIに投げ、何をログとして残したのか。ここまで決めると、Gemma 4を採用する場合も、見送る場合も説明しやすくなります。

日本読者向けの結論

判断基準

日本の開発者やクラウド担当者にとって、Gemma 4 on Bedrockは「いますぐ東京で本番投入するモデル」というより、「海外リージョンで仕様と品質を早めに検証し、東京対応や価格確認を待ちながら比較軸を作るモデル」と見るのが現実的です。

最初の検証は、us-east-1us-west-2など対応リージョンで、匿名化したサンプルデータを使い、3モデルを同じプロンプトで比べる形がよいでしょう。31Bで品質上限を見て、26B-A4Bでバランスを見て、E2Bで低レイテンシ用途を試す。そこに料金、リージョン、ログ設計を重ねれば、Bedrock上の他モデルと公平に比べられます。

本番導入を急ぐ場合でも、東京リージョン未対応のまま進めてよいかは別問題です。社内規程、データ所在地、顧客契約、監査要件を満たせないなら、モデルの魅力があっても採用タイミングを遅らせる判断は十分ありえます。

Amazon Watch JapanはAmazon.com, Inc.および関係会社とは非提携の独立ブログです。この記事は公式情報をもとに利用者、開発者、導入企業目線で整理したもので、Amazon公式の案内ではありません。商標やサービス名は識別のために使用しています。また、この記事は投資助言ではなく、AMZN株式の売買判断を目的としたものでもありません。

次に読むなら

BedrockやAWS生成AI基盤の更新を横断して読む場合は、<a href="https://amzn-watch.blog.mo-gmo.com/category/products-services-solutions/" rel="noopener">製品・サービス・ソリューション</a>カテゴリが入口になります。2026年6月の公式発表や更新を追う場合は、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/" rel="noopener">2026年6月 重要トピックまとめ</a>もあわせて確認してください。一次情報の見方は、固定ページの<a href="https://amzn-watch.blog.mo-gmo.com/source-checks/" rel="noopener">資料・確認ログ</a>に集約しています。

更新履歴と再確認ポイント

Visual公開後も変わり得る確認点導入前に、更新されやすい情報を再確認します。
  1. 2026年6月16日午前

    AWS What’s New、Gemma 4各モデルカード、リージョン対応ドキュメント、Bedrock Pricingページを確認しました。

  2. 導入前

    東京リージョン対応、Geo/Global inference ID、parallel tool callsの扱いを公式ドキュメントで再確認します。

  3. 見積もり前

    Bedrock Pricingページで、対象リージョン、service tier、入出力トークン、想定利用量を最新化します。

この記事の確認日は固定できますが、リージョン、料金、推論プロファイル、API制約は公開後に変わる可能性があります。

  • 2026年6月16日午前、AWS What’s New、Amazon BedrockのGemma 4各モデルカード、リージョン対応ドキュメント、Bedrock Pricingページを確認しました。
  • 東京リージョン対応、Geo/Global inference ID、料金ページのGemma 4行、parallel tool callsの扱いは、公開後も変わる可能性があります。導入前には必ず公式ドキュメントを再確認してください。
  • この記事では、Bedrock Pricingページの金額を本文に固定していません。PoCや本番見積もりでは、対象リージョン、service tier、入出力トークン、利用量を最新ページで確認してください。

Amazonの公式発表、AWSサービス更新、Bedrockモデル追加、噂と未確認点の整理を継続して追う場合は、ニュースレター登録ページも利用できます。更新通知は<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/" rel="noopener">ニュースレター</a>で受け取れます。

参照した主な情報源

  • AWS What’s New「Gemma 4 models now available on Amazon Bedrock」

https://aws.amazon.com/about-aws/whats-new/2026/06/gemma-4-amazon-bedrock/

  • Amazon Bedrock User Guide「Gemma 4 31B」

https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-google-gemma-4-31b.html

  • Amazon Bedrock User Guide「Gemma 4 26B-A4B」

https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-google-gemma-4-26b-a4b.html

  • Amazon Bedrock User Guide「Gemma 4 E2B」

https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-google-gemma-4-e2b.html

  • Amazon Bedrock User Guide「Regional availability」

https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html

  • Amazon Bedrock Pricing

https://aws.amazon.com/bedrock/pricing/

  • AWS News Blog「AWS Weekly Roundup: AWS FinOps Agent in preview, Gemma 4 on Bedrock, Kiro Pro Max, and more (June 15, 2026)」

https://aws.amazon.com/blogs/aws/aws-weekly-roundup-aws-finops-agent-in-preview-gemma-4-on-bedrock-kiro-pro-max-and-more-june-15-2026/