【コツコツAWS】Amazon Bedrock - runtimeとmantleて結局何？ -

Amazon Bedrock AgentCoreなどを使った開発を始めるにあたって、Bedrockのモデルを呼ぶ入口にbedrock-runtimeとbedrock-mantleの2つがあり、どちらを使えばいいのか分かっていませんでした。
今回は、この2つの違いや使い分けに関して調べた結果を残します。(内容は2026年11月時点のものです)

1. Mantleとは?

Mantleで調べるとエンジンとエンドポイントの2つが出てくるので、それぞれについて簡単に説明します。

1-1. Mantleエンジン

Mantleは、Bedrockの裏側でモデルを動かす推論エンジン。2025年12月、OpenAIのResponses APIへの対応と一緒にProject Mantleとして発表されました。

多くの企業で生成AIの業務利用が広がる中、大規模でも高性能かつ信頼性の高いサーバーレス推論を提供するための基盤がMantleのようです。
特徴をざっくりまとめると以下の通り。

• 新しいモデルを素早くBedrockに載せられる
• OpenAI APIとの互換性 (OpenAI SDKでそのまま呼べる)
• 混雑時はキューで捌く仕組み (初期クォータも高め)
• AWSの運用者もプロンプトや回答にアクセスできない (ゼロオペレーターアクセス)

最後のセキュリティ面は、公式ブログで詳しく説明されています。
(SSHなどの対話型通信ツールが入っていない、承認されたコードしか動かないなど)

1-2. bedrock-mantle エンドポイント

今回調査しようと思ったbedrock-mantleはエンドポイントのことであり、上述のMantleとは指しているものが違います。公式ブログでは以下のように説明されています。

the engine is the underlying serving infrastructure ... and the endpoint is the HTTPS API surface you call.

つまり、Mantleはエンジン = モデルを動かす裏側の基盤であり、bedrock-mantleはエンドポイント = アプリが呼ぶ窓口 (URL) となります。
そしてエンドポイントにはbedrock-runtimeとbedrock-mantleの2つがあるわけですが、公式ではどちらのエンドポイントも、裏では同じMantleエンジンを使っていると書かれています。

Both endpoints use the same underlying Mantle inference engine. The bedrock-mantle name identifies an endpoint surface, not a different inference engine.

よって、2つのエンドポイントは別サービスではなく、同じBedrockにある2つの入口という整理になります。料金も、同じモデルなら両方のエンドポイントで同じ。
じゃあ何が違って、どう使い分ければいいの？ということで、機能面の違いを整理します。

2. 2つのエンドポイントの違い

裏側のエンジンは同じで、違いは提供する機能になります。詳細な比較表は↑の公式ページにあるので、ここではAPI・機能・認証と権限の観点で比較します。

2-1. 使えるAPI

API	bedrock-runtime	bedrock-mantle
InvokeModel / Converse(Bedrock独自のAPI)	○	×
Chat Completions / Responses(OpenAI互換)	○	○
Messages API(Anthropic互換)	○	○

1-1でOpenAI APIとの互換性をMantleの特徴に挙げましたが、bedrock-runtimeも同じMantleエンジンを使うため、/openai/v1のパスでOpenAI互換APIが使えるようになっています。
ただし、互換の中身に差があり、OpenAIのAPIの機能を使えるのはbedrock-mantleの方です。

OpenAI互換APIの機能	bedrock-runtime	bedrock-mantle
Responses APIの非同期実行(background=true)	×	○
Responses APIのサーバー側のツール	×	○
モデル一覧の取得(Models API)	×	○
モデルごとの対応	例: gpt-ossはResponses API非対応	○

同じモデルでもエンドポイントによって使えるAPIが違うこともあるので、使用時にモデルカードで確認するのが確実。(gpt-oss-120bは、bedrock-runtimeではChat Completionsしか使えず、Responses APIを使うにはbedrock-mantleで呼ぶ必要があり)

2-2. 使える機能

機能	bedrock-runtime	bedrock-mantle
Guardrails	○	×
クロスリージョン推論	○	×
Intelligent prompt routing	○	×
サーバー側のツール(Web Searchなど)	×	○
非同期(長時間)推論	×	○
Projects / Workspaces	Projectはデフォルトのみ / ×	○
プロンプトキャッシュ	○	○(モデルによる)

bedrock-runtimeはGuardrailsなどBedrockに以前からある機能、bedrock-mantleはサーバー側のツールや非同期推論といったエージェント向けの機能が使える、という分かれ方のようです。

【補足】 サーバー側のツールに関して

Bedrockにおけるサーバー側のツールには、自作のLambda関数を登録するもの、Bedrockが用意しているもの、そして組み込みのWeb Searchがあります。

Web Searchは、Responses APIのtoolsに1行足すだけで、検索から引用付きの回答までBedrock側でやってくれるので、検索APIの準備等が不要になり便利そうです。

ただし、使えるのはbedrock-mantle + Responses API + OpenAIのGPT-5.4以降のモデルの組み合わせだけで、リージョンも米国のみです。

Web Searchも試したかったのですが、対応モデルが使えなかったので紹介のみとします。

2-3. 認証と権限

どちらのエンドポイントも認証で誰が呼んでいるかを確認し、次に認可でその人にIAMの権限があるかがチェックされます。

認証の方式は、bedrock-runtimeとbedrock-mantleで同じです。
エンドポイントではなくどのライブラリで呼ぶかで方式が変わります。

呼び方	認証	補足
AWS SDK(Pythonならboto3)	SigV4(自動)	手元のプロファイルやLambdaの実行ロールなどの認証情報で、SDKが自動で署名してくれる。bedrock-runtimeのInvokeModel / Converseはこの呼び方
OpenAI SDK	Bedrock APIキー	APIキーが必須。手元のAWS認証情報から短期(最大12時間)のキーをその場で生成できる(今回の検証はこの方法)
HTTPで直接(curlなど)	どちらでも可	SigV4で署名するか、APIキーをAuthorization: Bearerヘッダーに付ける

違うのは、認可で必要なIAMの権限。

	bedrock-runtime	bedrock-mantle
推論	bedrock:InvokeModel(ストリーミングはbedrock:InvokeModelWithResponseStream)	bedrock-mantle:CreateInference
APIキーで呼ぶときに追加で必要	bedrock:CallWithBearerToken	bedrock-mantle:CallWithBearerToken

権限名の頭から違うので、bedrock-runtime用に作ったIAMポリシーではbedrock-mantleを呼べない点に注意。

3. エンドポイントの比較

同じモデル(gpt-oss-120b)を、OpenAI SDKでbedrock-runtimeとbedrock-mantleの両方から呼んでみます。リージョンは東京。
認証にはaws-bedrock-token-generatorで手元のAWS認証情報から短期のBedrock APIキーを生成し、両方で同じキーを使用。

エンドポイント比較(抜粋)

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

REGION = "ap-northeast-1"

# 手元のAWS認証情報から短期のBedrock APIキーを生成 (最大12時間で失効)
api_key = provide_token(region=REGION)

runtime = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-runtime.{REGION}.amazonaws.com/openai/v1",
)
mantle = OpenAI(
    api_key=api_key,
    base_url=f"https://bedrock-mantle.{REGION}.api.aws/v1",
)

# モデルIDはエンドポイントごとに異なる
RUNTIME_MODEL = "openai.gpt-oss-120b-1:0"
MANTLE_MODEL = "openai.gpt-oss-120b"

res = runtime.chat.completions.create(
    model=RUNTIME_MODEL,
    messages=[{"role": "user", "content": "AWSを一言で説明してください。"}],
    max_tokens=300,
    reasoning_effort="low",
)
...

base URLとモデルIDを変えるだけで、あとは同じコードで呼べます。
試した結果は以下の通り。(○ = 成功、× = エラー)
2で確認した内容と一致しました。

試したこと	bedrock-runtime	bedrock-mantle
Chat Completions	○	○
Responses	×(404)	○
Responses(background=True)	×(400)	○
モデル一覧の取得	×(404)	○

4. なぜ2つあるのか

エンドポイントに関するAWSの発表を時系列に並べると、以下の通り。

時期	出来事	出典
2025/12	OpenAIのResponses APIに対応、新しいエンドポイント (bedrock-mantle)として提供	リンク
2026/01	Responses APIがサーバー側のツール (Lambdaなど)に対応	リンク
2026/02	bedrock-mantleの提供モデル拡大 (DeepSeek、Qwenなど)	リンク
2026/03	MantleがOpenAI互換のProjects APIに対応	リンク
2026/06	OpenAI/Anthropic互換API向けのbedrock-mantleコンソールを公開	リンク
2026/07	OpenAI GPT-5.6の提供開始 (bedrock-mantleのResponses API)	リンク
2026/08	OpenAI GPT-5.6をbedrock-runtimeでも提供	リンク

ここ数か月で新しいモデルやOpenAI互換の機能が、bedrock-mantleに追加されていったことが分かります。以下の公式ブログでは次世代の推論エンジンとしてbedrock-mantleが推奨されていました。

For most workloads, we recommend the bedrock-mantle endpoint.

一方、以下の公式ドキュメントではbedrock-runtimeが推奨です。

For most new applications, use the bedrock-runtime endpoint. Use bedrock-mantle when you specifically need capabilities that are currently available only there, such as server-side and pre-configured tools (including web search), background inference, Projects, or Workspaces.

基本はbedrock-runtime、サーバー側のツールや非同期推論など、bedrock-mantleにしかない機能が必要な時はbedrock-mantle、という使い分けが推奨のようです。
下記のGPT-5.6のクロスリージョン推論のブログでも、bedrock-runtimeの方が使えるAPIが多く、GuardrailsやクロスリージョンなどBedrockの機能も使える点からbedrock-runtimeの方を推奨していました。

私の見落としがあるかもしれませんし、今後のアップデートによってどちらを使うべきかが変わる可能性もあります。実際に使う際は、公式ドキュメントで最新の情報を確認ください。

結局の所、なぜ2つあるのかについても明確なことは分かりませんでした。
新しいエンジンとしてMantleができましたが、bedrock-runtimeの方にもOpenAI互換が入ったり、裏側もMantleに揃ったので、今は機能の多いbedrock-runtimeが推奨？
少なくとも機能の違いはあるので、要件に応じた使い分けは必要そうです。

5. 結局どっちを使うか

5-1. 基本はbedrock-runtime

調べた内容から、判断の流れは↓のようになりそうです。

次のどれかが必要?
  ・サーバー側のツール(Web Search など)
  ・非同期推論(background=true)
  ・Projects / Workspaces によるアプリ単位の分離・コスト把握
  ・bedrock-mantle でしか提供されていないモデル
  │
  ├─ Yes ──> bedrock-mantle
  │
  └─ No ───> bedrock-runtime(Guardrails、クロスリージョン推論も使える)

5-2. mantleにしかないモデル・使い方

モデルごとの対応は公式の一覧にまとまっています。

GPT-5.6 LunaやGPT-6 Astraなどは、bedrock-runtimeだとクロスリージョン推論でしか呼べず、1リージョン内で処理できるのはbedrock-mantleのみと、モデルによって様々なので最初に確認した方が良さそうです。

5-3. AgentCoreで開発する場合

もともとの疑問だったAgentCoreでの開発に当てはめると、以下の通り。

• Strands Agentsは、既定のモデル呼び出し(BedrockModel)がConverse Stream APIで実装されていたので、bedrock-runtimeで良さそう
• AgentCore Harnessは、モデル設定のapiFormatで呼び先が決まります

apiFormat	呼ぶAPI	エンドポイント
converse_stream(既定)	Converse	bedrock-runtime
responses	Responses(OpenAI互換)	bedrock-mantle
chat_completions	Chat Completions(OpenAI互換)	bedrock-mantle

Harnessでも、Guardrailsを使うならconverse_stream(bedrock-runtime)が必要ということで、これまでに整理した内容を元に使い分ければ良さそうです。

まとめ

Amazon Bedrockのbedrock-runtimeとbedrock-mantleの違いや経緯に関する調査を行いました。

• 2つは別サービスではなく、同じMantleエンジンの入口となるエンドポイント
• 料金も同じで、違いは使えるAPI・機能など
• 基本はbedrock-runtime。サーバー側のツールや非同期推論など、bedrock-mantleにしかない機能が必要な時はbedrock-mantle
• モデルIDやURLのパスがエンドポイントやモデルで違うので、モデルカードの確認が必須
• AgentCore(Strands / Harness)の既定はbedrock-runtime

新しいサービスのため情報が流動的な部分もありましたが、「基本はbedrock-runtime、機能によってはbedrock-mantle」という整理でとりあえずは良いと思います。
今後は実際の開発を通じて使い分けの勘所をつかみつつ、公式の情報も継続的に追いかけ、エンドポイントを適切に選べるようにしたいと思います。