技術 約7分で読めます

Amazon Bedrock MantleエンジンのOpenAI API互換が一般提供開始、DeepSeekやMistralで既存SDKが使える

AWSは2026年3月3日、Amazon Bedrockの分散推論エンジン「Mantle」においてOpenAI API互換機能の一般提供開始を発表した。これにより openai Pythonライブラリや @openai/openai npmパッケージなど既存のOpenAI SDKコードを、ほぼそのままAmazon Bedrock上で動かせるようになる。

何が変わるか

これまでBedrockのネイティブAPIを使う場合、InvokeModelのリクエスト形式がモデルプロバイダーごとに異なり、AnthropicモデルとMistralモデルでは別々のSDKやリクエスト形式を使い分ける必要があった。今回のOpenAI API互換により、そのフラグメンテーションが大幅に解消される。

変更が必要な箇所はベースURL(エンドポイント)の切り替えとAWS認証情報の設定だけで済む。プロンプトロジック・メッセージ構造・パラメータ名はOpenAI API準拠のまま維持できる。

対応モデルとAPI

MantleエンジンのOpenAI互換APIが対応するのは、複数プロバイダーのオープンウェイトモデルだ。

  • Google(Gemmaシリーズ等)
  • DeepSeek(DeepSeek-R1等)
  • Mistral(Mistral Large、Mistral 7B等)
  • Moonshot AI
  • MiniMax
  • Nvidia提供のモデル
  • OpenAIのオープンウェイト版

対応APIは現時点でChat Completions APIとResponses APIの2系統。OpenAI SDKで gpt-4o を指定していたコードを、Bedrockのモデル識別子(例: mistral.mistral-large-2411-v1:0)に差し替えるだけでMistral LargeをBedrock経由で動かせる。

Projects APIとIAM統合

今回の発表にはProjects APIの追加も含まれる。複数アプリケーション・環境・チームにわたってBedrockを使っている場合、プロジェクト単位でリソースを分離管理できる。

  • IAMベースのアクセス制御 プロジェクトごとにIAMロールやポリシーを設定できる
  • コスト可視化 タグを使ってプロジェクト単位でコスト追跡が可能
  • 追加料金なし Projects API自体は無料で、モデル推論コストのみ課金

エンタープライズ環境では開発・ステージング・本番で異なるモデルを使い分けるケースが多い。プロジェクト分離によって、環境ごとのモデル利用を区別しやすくなる。

Mantleエンジンとは

MantleはAWSが構築した分散推論エンジンで、大規模なモデルサービングに特化している。複数のGPUインスタンスにまたがるテンソル並列推論を担い、Bedrock上で提供される多数のモデルの推論バックエンドとして機能する。

BedrockとしてはClaude(Anthropic)のような独自APIを持つモデルも提供しているが、Mantleが処理する範囲は主にオープンウェイトモデルの推論だ。AWSのインフラ上で最適化されたサービングレイヤーを意識せず使える。

AWS/OpenAI提携との文脈

2026年2月、AWSとOpenAIは戦略的パートナーシップを発表した。両社はステートフルなランタイム環境を共同開発しAmazon Bedrock経由で提供する計画で、大規模かつ複雑なコンテキスト処理を必要とするエンタープライズAIサービスへの対応が主な目的とされている。

このOpenAI API互換機能はその提携の文脈で位置づけられる。AWSはBedrockプラットフォームのOpenAI互換性を強化することで、OpenAIのSDKエコシステムに慣れた開発者がBedrockに移行しやすくする。

Responses API vs Chat Completions API

Mantleが提供する2つのAPIは、アーキテクチャも用途もかなり違う。

項目Responses APIChat Completions API
状態管理サーバー側(ステートフル)クライアント側(ステートレス)
会話チェーンprevious_response_id で接続毎回全履歴を送信
バックグラウンド処理対応非対応
データ保持約30日間ZDR(Zero Data Retention)準拠
対応モデルOpenAI GPT OSSシリーズのみMantle上の全モデル
ツール利用ネイティブ対応対応

Responses APIの最大の特徴はサーバー側での会話状態保持だ。previous_response_id を渡すだけで前回の会話コンテキストが自動復元されるため、クライアントが履歴全体を管理・送信する必要がない。長い会話ほど帯域幅の節約効果が大きい。

一方で、Responses APIは約30日間データを保持する。規制要件でZDRが必須な環境ではChat Completions API一択になる。また、Responses APIの対応モデルは現時点でOpenAI GPT OSS 20Bと120Bに限られており、DeepSeekやMistralを使いたい場合はChat Completions APIを選ぶことになる。

flowchart TD
    A[APIを選択] --> B{ZDR要件あり?}
    B -->|はい| C[Chat Completions API]
    B -->|いいえ| D{GPT OSS以外の<br/>モデルが必要?}
    D -->|はい| C
    D -->|いいえ| E{長時間推論や<br/>バックグラウンド処理?}
    E -->|はい| F[Responses API]
    E -->|いいえ| G{サーバー側で<br/>会話管理したい?}
    G -->|はい| F
    G -->|いいえ| C

バックグラウンド処理

Responses APIにはバックグラウンドモードがある。リクエストをキューに投入して非同期で処理し、クライアントはポーリングで完了を待つ仕組みだ。

sequenceDiagram
    participant Client
    participant Mantle
    Client->>Mantle: POST /v1/responses<br/>(background: true)
    Mantle-->>Client: 202 Accepted<br/>(response_id)
    loop ポーリング
        Client->>Mantle: GET /v1/responses/{id}
        Mantle-->>Client: status: in_progress
    end
    Client->>Mantle: GET /v1/responses/{id}
    Mantle-->>Client: status: completed<br/>(結果)

長時間の推論タスクでHTTP接続がタイムアウトする問題を回避できる。複雑な推論やツール呼び出しチェーンを伴うエージェント的なワークロードで有用だ。

対応リージョンとエンドポイント

エンドポイントの形式は bedrock-mantle.{region}.api.aws で統一されている。東京リージョンにも対応済み。

リージョンコードエンドポイント
米国東部(バージニア)us-east-1bedrock-mantle.us-east-1.api.aws
米国東部(オハイオ)us-east-2bedrock-mantle.us-east-2.api.aws
米国西部(オレゴン)us-west-2bedrock-mantle.us-west-2.api.aws
アジア太平洋(東京)ap-northeast-1bedrock-mantle.ap-northeast-1.api.aws
アジア太平洋(ムンバイ)ap-south-1bedrock-mantle.ap-south-1.api.aws
アジア太平洋(ジャカルタ)ap-southeast-3bedrock-mantle.ap-southeast-3.api.aws
欧州(フランクフルト)eu-central-1bedrock-mantle.eu-central-1.api.aws
欧州(アイルランド)eu-west-1bedrock-mantle.eu-west-1.api.aws
欧州(ロンドン)eu-west-2bedrock-mantle.eu-west-2.api.aws
欧州(ミラノ)eu-south-1bedrock-mantle.eu-south-1.api.aws
欧州(ストックホルム)eu-north-1bedrock-mantle.eu-north-1.api.aws
南米(サンパウロ)sa-east-1bedrock-mantle.sa-east-1.api.aws

2026年2月にはPrivateLinkのサポートも拡大され、VPCエンドポイント経由でMantleのOpenAI互換APIにアクセスできるようになった。パブリックインターネットを経由せずにBedrock推論を利用できるため、セキュリティ要件の厳しい環境でも導入しやすい。

移行のコード例

OpenAI直接利用からBedrock Mantleへの移行は、環境変数2つの差し替えだけで済む。

# OpenAI直接利用
export OPENAI_API_KEY=sk-xxxxx
export OPENAI_BASE_URL=https://api.openai.com/v1

# Bedrock Mantleへ切り替え
export OPENAI_API_KEY=<Amazon Bedrock APIキー>
export OPENAI_BASE_URL=https://bedrock-mantle.ap-northeast-1.api.aws/v1

Pythonコード側の変更はモデルIDだけ。

from openai import OpenAI

client = OpenAI()  # 環境変数から自動読み込み

# OpenAI直接: model="gpt-4o"
# Bedrock Mantle: モデルIDを差し替える
completion = client.chat.completions.create(
    model="mistral.mistral-large-2411-v1:0",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Hello!"}
    ]
)

Responses APIでステートフルな会話を行う場合はこうなる。

# 1ターン目
response = client.responses.create(
    model="openai.gpt-oss-120b",
    input=[{"role": "user", "content": "Pythonの非同期処理について教えて"}]
)

# 2ターン目(サーバー側でコンテキスト自動復元)
response2 = client.responses.create(
    model="openai.gpt-oss-120b",
    input=[{"role": "user", "content": "asyncioとの違いは?"}],
    previous_response_id=response.id
)

実装上の注意点

OpenAI API互換といっても全機能が完全対応しているわけではない。

  • stream=True(ストリーミング)の対応はモデル依存
  • n > 1(複数候補生成)や logprobs などの高度なパラメータは未対応の可能性
  • Embeddings APIへの対応状況は現時点で未確認

基本的なChat Completions APIが機能するという前提で、本番移行前に動作確認のテストは必要になる。既存のOpenAIコードをそのまま投入してモデルIDを変えるだけで全動作するというより、コア機能が互換性を持つという理解が正確だろう。

既知の互換性問題

AWS re:Postで報告されている問題として、公式OpenAI .NET SDKとの非互換がある。

  • created_at フィールドが科学記数法(float)で返され、整数を期待する.NET SDKがパースに失敗する
  • content を配列形式で送信するとリジェクトされるケースがある

Python SDKでは現時点で大きな問題は報告されていないが、.NETやGoなど他言語のSDKを使う場合は追加のテストが必要だ。Mantleの互換レイヤーはOpenAI Python SDKを主なターゲットにしている印象で、他言語SDKのエッジケースは後追い対応になる可能性がある。