Amazon BedrockでGemma 4 31Bが利用可能になったので、日本語要約力を試してみた

はじめに

GoogleのGemma 4 31BがAmazon Bedrockで利用可能になりました。

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

Gemma 4 31BはBedrockの新しいエンドポイントであるbedrock-mantle経由で利用します。
OpenAI互換のResponses APIとChat Completions APIに対応しており、従来のbedrock-runtimeのInvokeModel / Converse APIには非対応です。

本記事ではChat Completions APIを使って検証します。画像・動画入力、Reasoningの返却内容、Function callingは扱いません。

https://dev.classmethod.jp/articles/bedrock-mantle-console-gpt55/

公式情報に基づく、Gemma 3 27Bとの主な仕様差分は以下の通りです。

Bedrockでの利用にあたっていくつかの注意点があります。

• bedrock-mantle エンドポイント専用（bedrock-runtime InvokeModel / Converse API非対応）
• Reasoning関連の出力情報はResponses APIでのみ確認可能（Chat Completions APIでは返らない）
• 256Kはモデル仕様上のコンテキスト長。Bedrock Mantleではリクエストペイロード上限3.5 MBもあるため、実際に投入できる入力量はペイロードサイズの制約も受ける
• 並列tool call非対応（1回の応答で複数のtool callを返す形式には非対応）

今回は日本語の要約タスクで、Gemma 4 31Bの出力品質や指定遵守の傾向を確認しました。

価格比較

以下はAmazon Bedrock公式料金ページのon-demand料金（us-east-1、執筆時点）を参照した、1M tokensあたりの単価比較です。倍率はGemma 4 31Bを基準とした単純比較であり、実ワークロードでの総コスト比較ではありません。

検証環境・条件

• リージョン： us-east-1（提供リージョン： us-east-1, us-east-2, us-west-2, eu-central-1）
• エンドポイント： https://bedrock-mantle.us-east-1.api.aws/openai/v1（Chat Completions API）
• モデルID: google.gemma-4-31b
• SDK: Python（openaiライブラリ）
• 認証： IAM認証（aws-bedrock-token-generator でトークン生成し、OpenAI SDKの api_key 引数に渡す）

検証条件：

• 生成パラメータは明示指定せず、APIのデフォルト設定で実行
• 各検証は1回ずつ実行し、単発実行の結果として扱う
• 文字数はPythonの len() でカウント（改行・空白・句読点・記号を含む）
• Gemma 4 31Bの各レスポンスでfinish_reasonがstopであることを確認（途中打ち切りなし）
• 入力記事は自分の公開済みブログ記事を使用

モデルカタログ API 応答

/v1/models で取得したGemma 4ファミリーの一覧です（検証時点のus-east-1での実測結果）。

モデル一覧は /v1/models、Chat Completionsは /openai/v1/chat/completions とパスが異なります。

import requests
from aws_bedrock_token_generator import provide_token

token = provide_token(region="us-east-1")
resp = requests.get(
    "https://bedrock-mantle.us-east-1.api.aws/v1/models",
    headers={"Authorization": f"Bearer {token}"},
    timeout=30,
)
resp.raise_for_status()
models = resp.json()

検証スクリプト

import time
from pathlib import Path
from openai import OpenAI
from aws_bedrock_token_generator import provide_token

REGION = "us-east-1"
MODEL = "google.gemma-4-31b"
BASE_URL = f"https://bedrock-mantle.{REGION}.api.aws/openai/v1"

client = OpenAI(
    base_url=BASE_URL,
    api_key=provide_token(region=REGION),
)

samples_dir = Path("samples")

tests = [
    {
        "name": "検証1: 200文字以内の要約",
        "file": "article3-s3.txt",
        "prompt": "以下の記事を200文字以内で要約してください。\n\n",
    },
    {
        "name": "検証2: 3行まとめ",
        "file": "article2-ecs.txt",
        "prompt": "以下の記事を3行でまとめてください。\n\n",
    },
    {
        "name": "検証3: 3行まとめ（別の記事）",
        "file": "article1-gmail.txt",
        "prompt": "以下の記事の要点を3行でまとめてください。\n\n",
    },
]

results = []
for test in tests:
    article = (samples_dir / test["file"]).read_text(encoding="utf-8")
    user_msg = test["prompt"] + article

    start = time.time()
    response = client.chat.completions.create(
        model=MODEL,
        messages=[{"role": "user", "content": user_msg}],
    )
    elapsed = time.time() - start

    usage = response.usage
    choice = response.choices[0]
    finish_reason = choice.finish_reason
    output = choice.message.content
    results.append(
        f"## {test['name']}\n\n"
        f"- 応答時間: {elapsed:.1f}秒\n"
        f"- 入力トークン: {usage.prompt_tokens}\n"
        f"- 出力トークン: {usage.completion_tokens}\n"
        f"- finish_reason: {finish_reason}\n\n"
        f"{output}\n"
    )
    print(f"✓ {test['name']} | {elapsed:.1f}s | in:{usage.prompt_tokens} out:{usage.completion_tokens} | {finish_reason}")

print("\n".join(results))

検証1: ブログ記事の要約（200文字以内）

入力としてS3静的ウェブサイトホスティングに関する記事（約1300文字）を使用し、「以下の記事を200文字以内で要約してください。」と指示しました。

結果:

出力全文:

S3静的ウェブサイトホスティングを2026年時点でもセキュアに運用するための最適化構成を解説した記事です。CloudFrontをフロントに配置し、カスタムヘッダーによるアクセス制限や監視体制（SecurityHub、Chatbot連携等）を構築することで、制約を補いつつ低コストかつ低負荷な配信基盤を実現しています。ベストプラクティスではないものの、用途を限定すれば実用的であると結論付けています。

文字数はlen()で199文字でした。200文字以内の指定を満たしています。内容は元記事の要点（CloudFront + カスタムヘッダーによる制約の補完、低コスト運用、用途限定での実用性）を押さえており、日本語として不自然な表現や文法の崩れは見られません。

検証2: 3行まとめ

入力としてDevelopersIOのECS移行記事（約1500文字）を使用し、「以下の記事を3行でまとめてください。」と指示しました。

結果:

出力全文:

・パブリックサブネットを廃止し、CloudFront VPC Originと内部ALBを組み合わせたセキュアなネットワーク構成へ移行した。
・Graviton4（ARMアーキテクチャ）とFargate Spotを採用し、パフォーマンスを維持しつつ大幅なコスト削減を実現した。
・NAT Gatewayの選択やApp RunnerによるDR環境の構築など、コスト最適化と可用性の向上を両立させた。

3行の箇条書きとして出力されました。それぞれの粒度は、ネットワーク構成・コンピュート最適化・運用戦略と適切に分かれており、元記事の主要なポイントをおおむね押さえています。

検証3: 3行まとめ（別の記事）

入力として神奈川県のGmail問題に関する自分のブログ記事（約850文字）を使用し、「以下の記事の要点を3行でまとめてください。」と指示しました。検証2と同じ「3行まとめ」形式で、異なる記事でも同様の品質が得られるかを確認します。

結果:

出力全文:

・神奈川県の高校出願システムで、Gmail宛のメールが迷惑メール判定され届かないトラブルが発生した。
・不適切なサーバー設定やDNSミス、急激な送信量の増加など、複数の技術的要因が複合的に作用していた。
・システムの切り替え後も準備不足から再発し、最終的に県教委によるメールアドレス貸出という対応に至った。

検証2と同様に3行の箇条書きで出力されました。問題の発生・原因・結末という時系列を押さえた構成です。元記事と照合した範囲では大きな技術的誤りは見られず、検証2と同様の品質が得られました。

参考比較: Claude Sonnet 4.6（Kiro CLI 経由）

入力記事と要約指示を揃えて、Claude Sonnet 4.6でも実行しました。Sonnet 4.6はMantleエンドポイント非対応のため、Kiro CLI経由で生成しています。同じAPI条件での厳密なモデル比較ではなく、出力品質の参考比較として扱います。

検証1: 200文字以内の要約

出力全文:

S3静的ウェブサイトホスティングをCloudFrontと組み合わせ、2026年時点でもセキュアに運用する構成の紹介。OACが使えない制約をカスタムオリジンヘッダーによるアクセス制限やSSE-S3、SecurityHub・GuardDutyによる監視で補完。月$1〜1.5程度の低コストで実用的な配信基盤として機能する。

Gemma 4と同様に元記事の要点を押さえています。len()による文字数は159文字で、200文字以内の指定を遵守していました。

検証2: 3行まとめ

出力全文:

1. VPC内のパブリックサブネットを廃止し、Regional NAT Gateway・CloudFront VPC Origin・Internal ALBを組み合わせることで、全リソースをプライベートサブネットに配置したセキュアなECS構成を本番導入した。
2. ARM Fargate Spotの採用でx86オンデマンド比約75%のコスト削減を実現し、Graviton4が最も低遅延（平均0.150秒）であることを確認してEC2インスタンスのメイン世代として採用した。
3. 複数インスタンスファミリーのスポット活用・3AZ分散でスポット中断リスクを低減しつつ、DR環境はApp Runner（月額$10程度）＋CloudFront Failoverで低コストに構成した。

Gemma 4と同じ3点（ネットワーク・コンピュート・運用）を取り上げつつ、具体的な数値（75%削減、0.150秒）をより多く含んでいます。

検証3: 3行まとめ（別の記事）

出力全文:

2024年1月、神奈川県のネット出願システムでGmailへのメール到達率が2〜3%台に落ち込み、受験生の出願登録に深刻な支障が生じた。

原因は、不適切なAmazon SES設定・DNSレコードのミス・バウンスメール処理不備が重なった状態で大量送信を行ったことで、Gmailにスパム判定されたことである。

ベアメールへの切り替えで一時改善したが出願開始日の送信量急増で再発し、最終的に県教委のメールアドレスを生徒に貸し出すという応急対応を余儀なくされた。

Gemma 4と同じ時系列構成（発生・原因・結末）で、具体的な数値（到達率2〜3%）を含めた出力です。

比較まとめ

応答時間はAPI経路やクライアントが異なるため、モデル単体のレイテンシ比較としては扱えません。Kiro CLI経由の参考比較の範囲では、今回の3件の要約タスクで要約内容や日本語の自然さに目立つ差は見られませんでした。

まとめ

Amazon Bedrockでは、Gemma 3 27Bはbedrock-runtimeのInvokeModel / Converse APIで利用できます。一方、検証時点のGemma 4 31BはMantleエンドポイント経由のOpenAI互換APIで利用する形です。OpenAI互換APIのため、既存のOpenAI SDKコードを流用しやすく、base_url・モデルID・認証部分を差し替えることで接続しやすい構成でした。

公式料金上は入力$0.14/1M tokens、出力$0.40/1M tokensです。Claude Sonnet 4.6と比べると、入力単価は約1/21、出力単価は約1/38です。

今回の技術記事を対象にした日本語要約では、自然な日本語で要点を押さえた出力が得られました。Sonnet 4.6（Kiro CLI経由）との参考比較でも、要約内容や日本語の自然さに目立つ差は見られませんでした。Bedrock公式料金上の入出力トークン単価を踏まえると、要約用途でコストを抑えやすい選択肢になり得ます。

Gemma 4 31Bは、Bedrock上で利用できる低単価な要約向けモデル候補の1つとして検討できそうです。なお、Google公式ブログではDiffusionGemma（拡散モデルベースのテキスト生成モデル）も紹介されており、今後のGemma系モデルの展開にも注目です。

参考リンク

• Gemma 4 31B model card (Bedrock docs)
• Gemma 3 27B model card (Bedrock docs)
• Amazon Bedrock pricing
• Google Gemma 4 (HuggingFace)
• DiffusionGemma (Google blog)