Amazon Bedrockの新コンソール「Bedrock Mantle」を試してみた！3モデル比較とOpenAI SDKによるAPI呼び出し

■ はじめに 

2026年6月5日、AWSはAmazon Bedrockの新しいコンソールエクスペリエンスを発表しました。

新しいBedrock Mantleコンソールでは、複数のAIモデルの比較から、APIコード例の確認、アプリケーションへの組み込み、利用状況の確認までを一つの流れで進められます。

また、OpenAI互換APIやAnthropic Messages APIに対応しているため、OpenAI SDKやAnthropic SDKを利用した開発にも取り組みやすくなりました。

本記事では、3種類のモデルを比較した後、OpenAI SDKを使ってAmazon Bedrock上のモデルを実際に呼び出します。さらに、Projectダッシュボードでリクエスト数やトークン使用量を確認します。

■ 目次

1. Amazon Bedrockとは

2. bedrock-mantle と bedrock-runtime の違い

3. 新しいBedrock Mantleコンソールを確認する 新コンソールを開く 検証専用Projectを作成する API実行前のダッシュボードを確認する

4. 3種類のモデルと日本語プロンプトの回答を比較する モデルカタログを確認する 3種類のモデルを比較する 日本語プロンプトで回答を比較する

5. OpenAI SDKからモデルを呼び出す Live API docsを確認する 短期APIキーを発行する Windows PCで実行環境を準備する Pythonファイルを作成・実行する

6. Projectダッシュボードで実行結果を確認する

7. 実際に触って分かったこと

8. 検証時の注意点

9. まとめ

■ 1．Amazon Bedrockとは

https://cx.genech.co.jp/column/20250722

Bedrockについてこちらでも紹介しているので、読んでみてください！

■ 2．bedrock-mantle と bedrock-runtime の違い

Amazon Bedrockには、推論リクエストを送信するための主なエンドポイントとして、bedrock-mantle と bedrock-runtime があります。

※各APIの概要

● Responses API

OpenAI互換のAPIです。会話履歴を活用した複数ターンのやり取りや、ストリーミング、バックグラウンド処理などに対応しています。今回の検証では、このAPIを利用してGPT OSS 120Bを呼び出しました。

● Chat Completions API

OpenAI互換のチャット向けAPIです。ユーザーとAIのメッセージを渡し、回答を取得するシンプルな形式で利用できます。

● Messages API

Anthropic形式のAPIです。Claudeなどのモデルを、Anthropic SDKに近い書き方で呼び出す場合に利用します。

● InvokeModel API

Amazon Bedrock独自の推論APIです。モデルIDとリクエスト本文を指定し、モデルへ直接リクエストを送信します。モデルによって入力形式が異なる場合があります。

● Converse API

Amazon Bedrock独自の会話向けAPIです。複数の対応モデルを共通に近い形式で扱えるため、チャットボットなどの会話型アプリケーションを構築しやすくなります。

今回試す新コンソールは、bedrock-mantle を利用した開発に最適化されています。

OpenAI SDKに慣れている場合は、接続先URLやAPIキーなどをBedrock向けに設定することで、これまでの知識を活用しながらAmazon Bedrock上のモデルを呼び出せます。

一方で、従来の bedrock-runtime が廃止されたわけではありません。

InvokeModel APIやConverse APIを利用する場合や、bedrock-mantle では利用できないモデルを使う場合は、引き続き bedrock-runtime を使用します。

■ 3．新しいBedrock Mantleコンソールを確認する

● 新コンソールを開く

まず、AWSマネジメントコンソールからAmazon Bedrockを開きます。

従来のBedrock Runtimeコンソールの上部に、以下の案内が表示されています。

Try the new Amazon Bedrock Mantle Console

ボタンを選択すると、新しいBedrock Mantleコンソールへ移動できます。

新コンソールを開くと、ホーム画面に以下の情報が表示されました。

• 推論リクエスト数
• クライアントエラー数
• 最新モデル
• Project一覧
• 新しいProjectの作成欄

画面左側には、以下のメニューが表示されています。

ホーム
モデル
Dashboard
Evaluate
Getting started
Live API docs
アカウントダッシュボード
プロジェクト
APIキー

モデル選定、APIコードの確認、利用状況の把握までを、新コンソール内で進められる構成になっています。

● 検証専用Projectを作成する 

今回使用したAWSアカウントは、複数人が利用する共有アカウントです。

デフォルトで用意されている default Projectのまま検証すると、ほかの利用者が実行したリクエストと今回の検証結果が混在する可能性があります。

そこで、以下の検証専用Projectを作成しました。

「bedrock-mantle-blog-demo」

 Projectを作成すると、Project一覧に bedrock-mantle-blog-demo が追加されました。  

左側のProjectスコープも、作成したProjectへ切り替わっています。

Projectは、アプリケーション、環境、チーム、検証用途などの単位でワークロードを論理的に分けるために利用できます。

● API実行前のダッシュボードを確認する

Projectを作成した直後に、Dashboardを開きました。

この時点では、推論リクエストやトークン使用量は発生していません。

 今回の検証では、最後にもう一度Dashboardを確認し、実行前後でどのように変化するかを確認します。  

■ 4．3種類のモデルと日本語プロンプトの回答を比較する

● モデルカタログを確認する

次に、新コンソールのモデルカタログを開きます。

検証時点では、東京リージョンで複数のモデルが一覧表示されました。

各モデルのカードから、以下のような情報を確認できます。

• モデル名
• プロバイダー
• 入力料金
• 出力料金
• コンテキストウィンドウ
• 入出力として扱えるデータ形式

モデルによって料金、扱える入力形式、コンテキストウィンドウなどが異なります。

回答品質だけでなく、コストやユースケースも考慮してモデルを選択する必要があります。

● 3種類のモデルを比較する

新コンソールでは、最大3モデルを同時に選択して比較できます。

今回は、以下の3モデルを選択しました。

モデルカタログの比較画面では、各モデルの違いを横並びで確認できます。

検証時点で、東京リージョンのコンソールには以下の内容が表示されました。

料金や提供内容は変更される可能性があります。

実際に利用する際は、コンソールやAWS公式の料金ページで最新情報をご確認ください。

● 日本語プロンプトで回答を比較する

比較1：AWS構成の説明

最初に、AWSサービスを使ったサーバーレス構成について説明を求めました。

「AWS Lambda、Amazon API Gateway、Amazon DynamoDBを使用して、
　サーバーレスな問い合わせ受付APIを構築するとします。

　構成の概要、各サービスの役割、セキュリティ上の注意点、
　監視方法を、AWSを学び始めた人にも分かるように説明してください。 」

同じプロンプトを使用しても、回答の構成や説明方法には違いが見られました。

Claude Opus 4.8は、処理の流れを図に近い形式で示しながら、初心者向けに説明していました。

GPT OSS 120Bは、各サービスの役割を表形式に近い構成で整理していました。

DeepSeek V3.2は、全体構成を最初に示したうえで、各サービスの役割を順番に説明していました。

このように、同じ内容を質問しても、モデルによって説明の粒度や読みやすさが異なります。

比較2：Lambda関数のコード生成

次に、Pythonで動作するLambda関数のコード生成を依頼しました。

「Pythonで動作するAWS Lambda関数を作成してください。

API GatewayからPOSTリクエストを受け取り、
問い合わせ内容をAmazon DynamoDBへ保存してください。
入力値の検証とエラーハンドリングも追加してください。 」

表示された範囲を確認しただけでも、各モデルで回答の進め方に違いがありました。

Claude Opus 4.8は、コードの概要を説明した後、ログ出力や例外処理を含むコードを提示していました。

GPT OSS 120Bは、最初に目的を整理し、その後にコード全体を提示していました。

DeepSeek V3.2は、コードを中心に回答し、環境変数や入力値検証に関する処理を含めていました。

今回の比較は、限定的なプロンプトによる簡易的な確認です。

モデルの性能を網羅的に評価するものではありませんが、新コンソールを使うことで、用途に合うモデルを手軽に比較できることが分かりました。

■ 5．OpenAI SDKからモデルを呼び出す

● Live API docsを比較する

続いて、左側のメニューから Live API docs を開きました。

Live API docsでは、Anthropic API ProtocolとOpenAI API Protocolを切り替えられます。

今回は、OpenAI SDKを利用するため、以下を選択しました。

OpenAI API Protocol

さらに、APIとして以下を選択しました。

Create a model response
POST /responses

 右側には、Python向けのコード例が表示されます。  

コード例には、以下の内容が自動的に反映されていました。

• 東京リージョン向けのBedrock Mantleエンドポイント
• Project ID
• モデルID
• APIキーを設定する箇所
• Responses APIを利用したリクエスト例

東京リージョン向けのエンドポイントは、以下です。

「https://bedrock-mantle.ap-northeast-1.api.aws/v1 」

使用するモデルIDは、以下です。

「openai.gpt-oss-120b」

Projectごとの値があらかじめ反映されるため、コンソールでモデルを試した後、ローカルPCでのAPI検証へ進みやすくなっています。

※クライアント連携について

新コンソールでは、APIコード例の確認に加えて、CodexやCursorなどのクライアントをBedrock Mantleへ接続するための設定例も確認できます。

今回は、OpenAI SDKを利用したAPI呼び出しを中心に検証したため、各クライアントとの連携については実際の動作確認を行っていません。

● 短期APIキーを発行する

OpenAI SDKからAmazon Bedrockへ接続するため、Bedrock APIキーを発行します。

左側のメニューから APIキー を開き、短期APIキーを生成します。

短期APIキーは、コンソールセッションの有効期間または最大12時間で失効します。

今回のような一時的な検証では、短期APIキーを利用します。

APIキーはソースコードへ直接記述せず、環境変数として設定します。

● Windows PCからOpenAI SDKを使って呼び出す

ここからは、Windows PCのPowerShellで操作します。

本記事では、操作画面を大量に掲載せず、実行したコマンドのみを記載します。

Pythonがインストールされていることを前提とします。

作業用フォルダを作成する

mkdir bedrock-mantle-blog-demo

cd bedrock-mantle-blog-demo

● Python仮想環境を作成する

py -m venv .venv

.\.venv\Scripts\Activate.ps1

PowerShellの実行ポリシーにより仮想環境を有効化できない場合は、現在のPowerShellセッションに限定して以下を実行します。

Set-ExecutionPolicy -Scope Process -ExecutionPolicy RemoteSigned

.\.venv\Scripts\Activate.ps1

環境によっては、py の代わりに python を使用します。

● OpenAI SDKをインストールする

py -m pip install --upgrade pip

py -m pip install openai

● 環境変数を設定する

$env:OPENAI_API_KEY="<Bedrockで発行した短期APIキー>"

$env:OPENAI_BASE_URL="https://bedrock-mantle.ap-northeast-1.api.aws/v1"

$env:BEDROCK_PROJECT_ID="<作成したProject ID>"

APIキーやProject IDは、実際の値へ置き換えます。

● Pythonファイルを作成実行する

作業フォルダ内に、以下のファイルを作成します。

「bedrock_mantle_demo.py 」

コードは以下のとおりです。

import os

from openai import OpenAI

client = OpenAI(

base_url=os.environ["OPENAI_BASE_URL"],

api_key=os.environ["OPENAI_API_KEY"],

default_headers={

"OpenAI-Project": os.environ["BEDROCK_PROJECT_ID"]

},

)

response = client.responses.create(

model="openai.gpt-oss-120b",

input="Amazon Bedrock Mantleの特徴を、初心者向けに3つ説明してください。",

max_output_tokens=512,

)

print(response.output_text)

実行します。

py bedrock_mantle_demo.py

PowerShell上に回答が表示されれば、OpenAI SDKを使ったAPI呼び出しは成功です。

コードではOpenAI SDKを使用していますが、接続先にはAmazon Bedrock Mantleのエンドポイントを指定しています。

また、リクエストヘッダーへProject IDを設定することで、今回作成した bedrock-mantle-blog-demo Projectにリクエストを関連付けています。

なお、モデルが生成した回答には、常に正確性が保証されているわけではありません。

今回の目的は、OpenAI SDKを利用してAmazon Bedrock上のモデルへ接続できることを確認することです。

実際のアプリケーションでは、出力内容の検証やガードレールなども検討する必要があります。

■ 6．Projectダッシュボードで実行結果を確認する

 最後に、Bedrock Mantleコンソールへ戻り、作成したProjectのDashboardを確認しました。  

Dashboardのモデル一覧には、以下の結果が表示されました。

Evaluate画面では、2種類のプロンプトを3モデルへ送信しました。

その後、OpenAI SDKからGPT OSS 120Bを1回呼び出しました。

そのため、GPT OSS 120Bだけ推論リクエスト数が1回多くなっています。

Claude Opus 4.8 ：Evaluateで2回
DeepSeek V3.2 ：Evaluateで2回
GPT OSS 120B ：Evaluateで2回 + OpenAI SDKで1回

これにより、OpenAI SDKから送信したリクエストが、検証専用Projectへ関連付けられていることを確認できました。

Project単位でモデル別のリクエスト数、入力トークン数、出力トークン数、クライアントエラー率などを確認できるため、アプリケーションごとの利用状況を把握しやすくなっています。

撮影直後の画面では、モデル別のリクエスト数やトークン数が上部の一覧へ反映されていました。

一方で、下部の集計グラフにはまだ数値が反映されていない箇所もありました。

■ 7．実際に触って分かったこと

● モデルの違いを比較しやすい

同じ日本語プロンプトを最大3モデルへ送信し、回答を横並びで確認できます。

生成AIアプリケーションを構築する際は、単純に高性能なモデルを選べばよいとは限りません。

回答の傾向、料金、コンテキストウィンドウ、出力上限などを確認し、用途に合うモデルを選定する必要があります。

● Projectを使うと検証結果を切り分けやすい

共有AWSアカウントで複数人が作業する場合、default Projectのまま検証すると、利用状況が混在する可能性があります。

検証専用Projectを作成しておくことで、今回のPoCに関連するリクエスト数やトークン数を確認しやすくなりました。

● Live API docsからAPI実行へ進みやすい

Live API docsには、リージョン、Project ID、モデルIDなどが反映されたコード例が表示されます。

コンソールで試した後、ローカルPCからAPIを呼び出すまでの流れが分かりやすくなっています。

● OpenAI SDKの知識を活用できる

今回はOpenAI SDKの responses.create() を利用し、Amazon Bedrock上のGPT OSS 120Bを呼び出しました。

接続先URL、APIキー、モデルID、Project IDをBedrock向けに設定することで、OpenAI SDKの書き方を活用できます。

既存アプリケーションを移行する場合は、利用しているAPIや機能によって追加確認が必要ですが、PoCを始める際のハードルは下がりそうです。

■ 8．検証時の注意点

今回の検証では、以下の点に注意しました。

• モデルの呼び出しには料金が発生する
• 複数モデルへ同時にプロンプトを送ると、モデルごとに推論料金が発生する
• モデルの回答は、内容を確認したうえで利用する
• 料金や提供モデルは変更される可能性があるため、利用時に最新情報を確認する

■ 9．まとめ

Amazon Bedrockの新しいBedrock Mantleコンソールを使い、モデル比較からOpenAI SDKによるAPI呼び出しまでを試しました。

今回の検証では、以下を確認できました。

• 新コンソールから複数モデルを比較できる
• Project単位で検証結果を管理できる
• Live API docsからProjectに応じたコード例を確認できる
• OpenAI SDKを使ってAmazon Bedrock上のモデルを呼び出せる
• SDKから送信したリクエストをProjectダッシュボードで確認できる

新コンソールは、単なる画面デザインの変更ではありません。

モデルの選定、検証、API実装、利用状況の確認までを一つの流れで進めやすくするアップデートです。

OpenAI SDKを利用したアプリケーションの開発経験がある場合や、複数モデルを比較しながら生成AIのPoCを進めたい場合は、Bedrock Mantleコンソールを試してみてはいかがでしょうか。