はじめに
2026年3月17日、OpenAIとAmazon Web Services（AWS）がAIエージェント向けの新たなインフラ契約を発表した。注目すべきは単なるクラウド提携ではなく、 ステートレスAPIとステートフルランタイムを異なるクラウドに分離する という前例のないアーキテクチャ戦略が明らかになった点にある。
具体的には、Microsoft Azureが従来のステートレスAPI（セッション非永続の推論リクエスト）の独占配信権を維持する一方、AWSがAmazon Bedrock上で Stateful Runtime Environment を提供し、永続的なメモリ・コンテキスト・アイデンティティを保持するAIエージェントの実行基盤を担う。
この記事では、Stateful Runtime Environmentの技術的な仕組み、Amazon Bedrock Mantleを通じたAPI実装、そして開発者がどちらのクラウドを選ぶべきかの判断基準を解説する。
この記事で学べること
- Stateful Runtime EnvironmentとステートレスAPIの技術的な違い
- Amazon Bedrock MantleでOpenAI互換APIを使う具体的な手順
- Responses APIによるステートフル会話管理の実装パターン
- AzureとAWSの使い分け判断基準
対象読者
- OpenAI APIを本番環境で運用しているエンジニア
- AIエージェントのマルチクラウドデプロイを検討しているアーキテクト
- AWS環境でOpenAIモデルを利用したい開発者
TL;DR
- OpenAIのクラウド戦略が Azure = ステートレスAPI 、 AWS = ステートフルランタイム に分離された
- Amazon Bedrock Mantleが12リージョンでOpenAI互換APIを提供し、既存のOpenAI SDKをベースURL変更だけで移行可能
- Responses APIの
store: trueでターン間のコンテキスト永続化、background: trueで非同期エージェントタスク実行に対応
Stateful Runtime Environmentとは
ステートレスとステートフルの違い
従来のOpenAI APIは ステートレス に設計されている。各リクエストは独立したイベントであり、モデルは過去のやり取りを記憶しない。開発者が会話履歴を維持するには、毎回の呼び出しで全履歴をプロンプトに含める必要がある。
Stateful Runtime Environmentは、この制約を根本から変える。モデルが 永続的なコンテキスト、メモリ、アイデンティティ を保持し、マルチステップのワークフローを跨いで状態を維持する。
| 項目 | ステートレスAPI（Azure） | ステートフルランタイム（AWS） |
|---|---|---|
| セッション永続性 | なし（毎回履歴を送信） | あり（サーバー側で状態保持） |
| ユースケース | 単発の推論、Q&A、テキスト生成 | マルチステップエージェント、長期タスク |
| ツール実行 | 開発者がオーケストレーション | ランタイムが自動管理 |
| エラーリカバリ | 開発者実装 | 中断からの安全な再開 |
| ガバナンス | APIキー・エンドポイント単位 | プロジェクト単位の分離・IAM制御 |
何を解決するのか
本番環境でAIエージェントを運用する際、状態管理は大きな技術的負債になる。具体的には以下の課題がある。
- 状態の永続化: 会話コンテキスト、ツール呼び出し結果、承認フローの状態をどこに保存するか
- ツール呼び出しの管理: 複数のツール出力の依存関係と実行順序の制御
- エラーハンドリング: 長時間実行タスクが中断した場合の安全な再開
- マルチテナント分離: チームやアプリケーションごとのアクセス制御とコスト追跡
Stateful Runtime Environmentは、これらをインフラ層で解決する。開発者はビジネスロジックに集中でき、状態管理のボイラープレートから解放される。
Azure vs AWS: アーキテクチャの分離
なぜ分離されたのか
2026年2月、OpenAIは総額1,100億ドルの資金調達を完了した。このうちAmazonが500億ドルを投資し、Frontier（OpenAIのエンタープライズエージェント管理プラットフォーム）の排他的サードパーティクラウドディストリビューターとなった。
OpenAIとMicrosoftは共同で「Azure remains the exclusive cloud provider of stateless OpenAI APIs」と声明を出しており、従来のAPI利用にはAzureが引き続き使われる。一方、ステートフルなエージェントワークフローはAWS Bedrock上で実行される。
契約の技術的な意味
| 配信チャネル | クラウド | 対象サービス | 推論基盤 |
|---|---|---|---|
| OpenAI API直接契約 | Azure | Chat Completions API, Assistants API | Azure OpenAI Service |
| AWS Bedrock経由 | AWS | Responses API, Stateful Runtime | Bedrock Mantle |
| Frontier経由（AWS） | AWS | エージェントプラットフォーム | Bedrock + Trainium |
OpenAIはAWSとの既存の380億ドルの契約を1,000億ドル（8年間）に拡大し、AWS Trainiumチップ（Trainium3および次世代Trainium4）で2ギガワットの計算容量を確保している。
Frontierプラットフォームとの関係
Frontier は2026年2月5日にローンチされたエンタープライズ向けエージェント管理プラットフォームで、データウェアハウス、CRMシステム、社内アプリケーションをAIエージェントに接続し、組織固有の知識を活用したエージェントを構築できる。HP、Intuit、Oracle、State Farm、Thermo Fisher、Uberが初期導入企業として公表されている。
FrontierをAWS経由で購入した場合、推論はAmazon Bedrock上で実行される。OpenAIから直接購入した場合はAzure上で実行される。
Amazon Bedrock Mantleの技術詳細
Mantleとは
Mantle は、Amazon Bedrockが提供する大規模モデルサービング向けの分散推論エンジンである。OpenAI互換のAPIエンドポイントを提供し、既存のOpenAI SDKやツールからベースURLとAPIキーを変更するだけで接続できる。
対応リージョン
2026年3月時点で12リージョンにエンドポイントが展開されている。
| リージョン | エンドポイント |
|---|---|
| US East (N. Virginia) | bedrock-mantle.us-east-1.api.aws |
| US East (Ohio) | bedrock-mantle.us-east-2.api.aws |
| US West (Oregon) | bedrock-mantle.us-west-2.api.aws |
| Asia Pacific (Tokyo) | bedrock-mantle.ap-northeast-1.api.aws |
| Asia Pacific (Mumbai) | bedrock-mantle.ap-south-1.api.aws |
| Asia Pacific (Jakarta) | bedrock-mantle.ap-southeast-3.api.aws |
| Europe (Frankfurt) | bedrock-mantle.eu-central-1.api.aws |
| Europe (Ireland) | bedrock-mantle.eu-west-1.api.aws |
| Europe (London) | bedrock-mantle.eu-west-2.api.aws |
| Europe (Stockholm) | bedrock-mantle.eu-north-1.api.aws |
| Europe (Milan) | bedrock-mantle.eu-south-1.api.aws |
| South America (Sao Paulo) | bedrock-mantle.sa-east-1.api.aws |
東京リージョン（ap-northeast-1）が含まれるため、日本国内のレイテンシ要件にも対応できる。
認証と接続
Amazon Bedrock APIキーを発行し、OpenAI SDKの環境変数を書き換えるだけで接続可能。
export OPENAI_API_KEY=<your-amazon-bedrock-api-key>
export OPENAI_BASE_URL=https://bedrock-mantle.us-east-1.api.aws/v1
from openai import OpenAI
client = OpenAI() # 環境変数から自動読み込み
# 利用可能なモデル一覧を取得
models = client.models.list()
for model in models.data:
print(model.id)
HTTP経由ではAWS認証情報（SigV4）も使用できる。
提供API
Bedrock Mantleは3つのAPIを提供する。
| API | エンドポイント | 用途 |
|---|---|---|
| Models API | /v1/models |
利用可能モデルの一覧取得 |
| Responses API | /v1/responses |
ステートフル会話管理・ストリーミング・バックグラウンド処理 |
| Chat Completions API | /v1/chat/completions |
従来互換のチャット推論 |
Responses APIによるステートフル会話管理
Responses APIは、ステートフルなエージェント構築の中核を担う。2つの動作モードを提供する。
ステートフルモード
store: true を設定すると、会話履歴がサーバー側に自動保存される。ターン間の推論コンテキストやツール呼び出し結果が永続化され、次のリクエストで自動的に利用される。
from openai import OpenAI
client = OpenAI()
# 最初のターン（状態を保存）
response = client.responses.create(
model="openai.gpt-oss-120b",
input=[{"role": "user", "content": "プロジェクトの進捗を分析して"}],
store=True
)
# 2ターン目（前のコンテキストを自動引き継ぎ）
response2 = client.responses.create(
model="openai.gpt-oss-120b",
input=[{"role": "user", "content": "リスクが高い項目を優先順位付けして"}],
previous_response_id=response.id
)
ステートレスモード
previous_response_id を使って明示的にレスポンスをチェーンする方式。各リクエストで前のレスポンスIDを指定し、会話の連鎖を手動で制御する。状態の保存場所を開発者側で管理したい場合に適する。
バックグラウンド処理
background: true を設定すると、タスクが非同期に処理される。長時間実行のエージェントタスクに適しており、ポーリングでステータスを確認できる。
# バックグラウンドでタスクを開始（store: true が必須）
response = client.responses.create(
model="openai.gpt-oss-120b",
input=[{"role": "user", "content": "リポジトリ全体のセキュリティ監査を実施して"}],
store=True,
background=True
)
# ステータスをポーリング
import time
while response.status in ["queued", "in_progress"]:
time.sleep(5)
response = client.responses.retrieve(response.id)
print(response.output)
ストリーミング
stream = client.responses.create(
model="openai.gpt-oss-120b",
input=[{"role": "user", "content": "アーキテクチャの改善案を提案して"}],
stream=True
)
for event in stream:
print(event)
開発者への影響と選択指針
どちらのクラウドを選ぶべきか
判断基準はワークロードの性質による。
| 判断軸 | Azure（ステートレス） | AWS Bedrock（ステートフル） |
|---|---|---|
| 単発の推論・テキスト生成 | 適切 | オーバースペック |
| マルチターン会話（短期） | 適切（履歴を手動管理） | 適切（自動管理） |
| 長時間実行エージェント | 不向き | 最適 |
| マルチツール連携エージェント | 自前オーケストレーション | ランタイムが管理 |
| 既存Azure環境との統合 | 容易 | ネットワーク設計が必要 |
| 既存AWS環境との統合 | ネットワーク設計が必要 | 容易 |
| GovCloud・機密ワークロード | Azure Government | AWS GovCloud・Classified Regions |
移行の実務
既存のOpenAI API利用コードからBedrock Mantleへの移行は、環境変数の変更が中心となる。
# Before: OpenAI直接
# OPENAI_API_KEY=sk-xxx
# OPENAI_BASE_URL=https://api.openai.com/v1
# After: Bedrock Mantle
# OPENAI_API_KEY=<bedrock-api-key>
# OPENAI_BASE_URL=https://bedrock-mantle.ap-northeast-1.api.aws/v1
Chat Completions APIはそのまま動作する。Responses APIのステートフル機能を使う場合は、 store や previous_response_id パラメータの追加が必要になる。
Projects APIによるマルチテナント分離
Amazon Bedrockは Projects APIも提供しており、アプリケーション・環境・チームごとにプロジェクトを作成できる。各プロジェクトにIAMベースのアクセス制御とタグによるコスト可視化を適用できるため、エンタープライズでのマルチテナント運用に対応する。
Microsoft訴訟リスクと業界への影響
2026年3月18日、Financial Timesは Microsoft がAmazon-OpenAIの500億ドルクラウド契約に対して法的措置を検討していると報じた。争点は、OpenAIがFrontierをAWS経由で提供することが、Microsoftとの排他的クラウド契約に違反するかどうかである。
OpenAIとMicrosoftは2025年10月に関係条件を再交渉しており、OpenAIがSoftBank、NVIDIA、Amazonとの契約を結ぶ道を開いた。ただし、Azureの「ステートレスAPI独占」とAWSの「ステートフルランタイム」という線引きが契約上許容されるかは、まだ確定していない。
開発者にとっての実務的な影響として、以下の点に留意する必要がある。
- 訴訟が進展した場合、APIの配信チャネルや利用条件が変更される可能性がある
- マルチクラウド戦略を採用する場合、両方のクラウドでの動作検証を維持することが推奨される
- Stateful Runtime Environmentは現時点でプレローンチ段階のため、正式なGA（一般提供）時期と料金体系の確定を待って本番導入を判断するのが安全である
まとめ
- OpenAIのクラウド戦略が ステートレス（Azure） と ステートフル（AWS） に明確に分離された
- Amazon Bedrock MantleはOpenAI互換APIを12リージョンで提供し、東京リージョンも含まれる
- Responses APIの
store: trueとbackground: trueにより、ステートフルエージェントの状態管理がインフラ層で解決される - 既存のOpenAI SDKコードはベースURL変更でBedrock Mantleに接続可能
- Stateful Runtime Environmentはプレローンチ段階のため、GA時期と料金の確定を見極めた上で導入計画を立てることが推奨される
参考リンク
- Amazon Bedrock - OpenAI APIs（Mantle）公式ドキュメント
- OpenAI Secures AWS Distribution for Frontier Platform in $110B Multi-Cloud Deal - InfoQ
- OpenAI expands government footprint with AWS deal - TechCrunch
- OpenAI launches stateful AI on AWS, signaling a control plane power shift - InfoWorld
- OpenAI Conversation State - API Documentation
- OpenAI Responses API Reference