追記: 2026年6月9日の最新情報
AWS News Blogが2026年6月5日（UTC）に、Amazon Bedrock新コンソールの詳細な使い方を公開しました。記事本文で整理した「新しい別サービスではなく、OpenAI/Anthropic互換APIとProjectsを扱いやすくする作業導線」という見方は変わりませんが、試す前に確認する項目はより具体的になっています。
- モデル評価では、同じプロンプトで最大3モデルを横並び比較できる導線が示されています。モデル名だけでなく、コンテキスト長、モダリティ、クォータを一緒に見る前提で使うのが安全です。
- Getting startedでは、AnthropicまたはOpenAI SDK、利用言語、認証方法を選ぶと、環境変数、.env、サンプルリクエストの確認に進めます。コピーして動かす前に、Projectの分け方と認証情報の置き場所を決めておく必要があります。
- Clientsでは、Claude Code、Cline、Codex、Cursor、OpenCodeなどのAIコーディングエージェントをbedrock-mantleへ接続する手順が示されています。IAM認証情報で扱うのか、Bedrock APIキーで扱うのかは、チームの権限設計に合わせて確認してください。
そのため、新コンソールは「モデルを選ぶ画面」だけでなく、Project、API互換性、認証方式、使用状況確認をまとめて棚卸しする入口として見ると判断しやすくなります。リージョンやエンドポイントは、引き続きAmazon Bedrockの公式ドキュメントで確認してください。
出典: AWS News Blog「Try the new console experience in Amazon Bedrock, optimized for Anthropic- and OpenAI-compatible APIs」、Amazon Bedrock User Guide「Endpoints supported by Amazon Bedrock」、Amazon Bedrock User Guide「Inference using Responses API」。
このテーマをもう少し広げて見るなら、AWS MCP Serverのクロスアカウント対応とは：AIコーディングエージェントに複数AWSアカウントを触らせる前に確認すべき権限設計 と Amazon Bedrock AgentCore RuntimeのInteractive Shellsとは：AIエージェントを端末から調査・デバッグする前に確認すべきこと も合わせて確認してください。Bedrock新コンソールからAIコーディングエージェント接続を試す前に、AWSアカウントとロールの扱いを確認できます。
Amazon Bedrockの新コンソールは、見た目の刷新だけで読むと少しもったいない発表です。AWSが2026年6月4日に公開した内容を見ると、主語は「新しいBedrockサービス」ではなく、OpenAI互換API、Anthropic Messages API、bedrock-mantle、Projects、モデル比較、使用状況確認をひと続きで扱いやすくする導線です。
この記事では、AWS公式発表とAmazon Bedrockドキュメントで確認できる範囲に絞り、日本のAWS利用者が試す前に見るべき点を整理します。確認日は2026年6月5日です。Amazon Watch JapanはAmazonおよび関係会社とは非提携の独立ブログであり、商標や公式情報は出典を明示して扱います。
3行まとめ
モデル比較、Projects、評価、使用状況、コードサンプルを、Bedrockの作業導線として見やすくします。
OpenAI SDKやAnthropic互換APIでは、Base URL、APIキー、対象モデル、Projectの扱いを先に確認します。
ap-northeast-1のbedrock-mantle endpointを確認し、モデル、API、料金、クォータは別々に見ます。
試す前にProject境界、認証情報、監査、コスト追跡の分け方を決めておきます。
新コンソールは、導入前の比較、Project設計、認証、リージョン確認を一緒に進める入口として読むと判断しやすくなります。
- Amazon Bedrockの新コンソールは、モデルカタログ比較、Projects、評価、使用状況、コードサンプルを、
bedrock-mantle前提の作業導線として見やすくする発表です。 - OpenAI SDKやAnthropic互換APIを使う場合は、Base URL、Amazon Bedrock APIキー、対象リージョン、対応モデル、Projectsの分け方を先に確認する必要があります。
- 東京リージョンは
bedrock-mantle.ap-northeast-1.api.awsとして公式ドキュメント上で確認できますが、使いたいモデル、API、クォータ、料金は別々に再確認するのが安全です。
このニュースは、すでにBedrock Mantleを見ている人ほど実務に響きます。過去に公開した<a href="https://amzn-watch.blog.mo-gmo.com/amzn-19-bedrock-mantle-cloudwatch-metrics/">Bedrock MantleのCloudWatchメトリクス記事</a>では本番監視を扱いましたが、今回の記事の焦点はその前段です。どのモデルを試し、どのProjectで分け、どの認証情報で呼び出し、どこまでをPoCで見るのか。新コンソールは、その初期判断を短くするための入口として読むと使いやすくなります。
Amazon Bedrock新コンソールで何が変わったのか
モデルのcapability、modality support、context window、service quotasを同じ流れで確認します。
アプリケーションや環境ごとの作業、評価、使用状況をProject単位で整理します。
モデルの試用結果や利用量を、導入判断に戻せる情報として見ます。
Project-aware documentationで、API呼び出しに必要な前提を取り違えにくくします。
コンソール刷新は、モデル性能や料金を一律に変える話ではなく、確認項目を同じ作業導線に集める話として捉えます。
AWS What's Newによると、新しいAmazon Bedrockコンソールは、基盤モデルを使った開発の流れを「試す、評価する、本番へ広げる」という実際の作業に合わせて設計されています。発表文では、既存のAmazon Bedrockと同じサービスであり、bedrock-mantle endpointに最適化された刷新ワークフローだと説明されています。
ここで大切なのは、新コンソールがモデルそのものの性能や料金を一律に変えるわけではない点です。読者が見るべきなのは、Bedrockを使う前に散らばりがちだった確認項目が、コンソール上の比較、Projects、ドキュメント、コードサンプルへ集まりやすくなったことです。
新サービスではなくBedrockの作業導線として見る
新コンソールは「Bedrockが別サービスになった」という話ではありません。公式発表では、従来のAmazon Bedrockサービスを使いながら、モデル選定から評価、利用状況の確認までを進めやすくする体験として説明されています。
この違いは、導入判断で重要です。新しい画面が出たから既存実装をすぐ移す、という話ではありません。既存のbedrock-runtime、InvokeModel、Converse、既存の監視、IAM設計がある場合は、何を残し、どこだけをbedrock-mantleやProjectsに寄せるかを分けて考える必要があります。
モデル比較で確認しやすくなる軸
AWSは、新しい体験でBedrockのモデルカタログを閲覧し、Claude、GPT、オープンウェイトモデルなどを、機能、モダリティ対応、コンテキストウィンドウ、サービスクォータといった軸で比較できると説明しています。
モデル名だけを見て選ぶと、実装段階で詰まりやすくなります。確認すべき軸は、少なくとも次のように分けられます。
| 確認軸 | 何を見るか | 導入判断への影響 |
|---|---|---|
| 対応API | Responses API、Chat Completions、Messages API、InvokeModel、Converse | 既存SDKを活かせるか、Bedrockネイティブ実装を続けるか |
| モダリティ | テキスト、画像、音声、マルチモーダル入力など | 既存ユースケースを1モデルで満たせるか |
| コンテキスト | 長文、履歴、ツール利用、状態管理 | RAG、エージェント、長い会話で必要な設計が変わる |
| クォータ | RPM、TPM、初期スループット、制限引き上げ | PoCの成功を本番負荷と取り違えないために必要 |
| リージョン | 東京、米国、欧州など | データ所在地、遅延、社内ポリシー、既存VPC設計に影響する |
Project-aware documentationが効く場面
公式発表で目を引くのは、Projectsに合わせたドキュメントです。AWSは、プロジェクトで選んだモデルID、リージョン、bedrock-mantle endpoint URL、APIキー参照がコードサンプルやSDKスニペットに反映されると説明しています。
これは、PoCの初速を上げるだけではありません。モデルを切り替えたとき、リージョンを変えたとき、Projectを分けたときに、どの設定が変わるのかを見落としにくくする効果があります。特にOpenAI SDKからBedrockへ向ける場合、Base URLとAPIキーの取り違えは起きやすいので、コンソール上のサンプルがProjectと連動する意味は大きいです。
注意点
コードサンプルが埋まることと、そのまま本番で使えることは別です。実際にはIAM権限、モデルアクセス、APIキーの種類、Secrets ManagerやCI/CDでの注入、ログ、クォータ、料金上限まで確認してから本番環境へ進める必要があります。
OpenAI/Anthropic互換API利用者が最初に確認すること
どちらか一方が常に正解ではありません。既存コード、認証方式、対象モデル、運用境界に合わせて選びます。
今回の発表は、bedrock-mantleを中心に読むと理解しやすくなります。Amazon Bedrockのエンドポイント関連ドキュメントでは、bedrock-mantle.{region}.api.awsがOpenAI互換のResponses API、Chat Completions API、Anthropic Messages APIを扱うエンドポイントとして説明されています。一方、従来のbedrock-runtime.{region}.amazonaws.comも引き続き使われます。
bedrock-mantleを選ぶケース
bedrock-mantleを先に見るべきなのは、既存のOpenAI SDK資産を活かしたい場合、Responses APIやChat Completions APIでBedrockモデルを呼びたい場合、Anthropic Messages APIの互換インターフェースを使いたい場合です。
Responses APIのドキュメントでは、OpenAI SDKを使うときにOPENAI_BASE_URLをAmazon Bedrockのエンドポイントに向け、OPENAI_API_KEYにはAmazon Bedrock APIキーを入れることが示されています。重要なのは、OpenAI本体のAPIキーやOpenAI本体の標準Base URLを使う話ではないことです。名前はOpenAI SDKの慣習に合わせていても、接続先と認証情報はAmazon Bedrock側のものです。
根拠として見る公式条件
bedrock-mantleは、OpenAI互換APIとAnthropic Messages APIを使うためのリージョン別エンドポイントです。新規アプリではbedrock-mantleが推奨される一方、対応モデルや対応APIには差があるため、エンドポイント可用性とモデル別対応を確認してから選びます。
bedrock-runtimeを続けるケース
既存のInvokeModelやConverseを使っているアプリ、BedrockネイティブAPIで安定運用しているアプリ、または使いたいモデルがbedrock-mantle側でまだ対応していない場合は、bedrock-runtimeを続ける理由があります。
AWSドキュメントでは、両エンドポイントを同じアプリで用途別に使い分けられると説明されています。つまり、移行は一括である必要はありません。新しいユースケースはbedrock-mantleで試し、既存の安定ワークロードはbedrock-runtimeで残す、という段階的な設計も現実的です。
Anthropic Messages APIを使う場合の見落とし
Anthropic Messages APIを使う読者は、OpenAI互換APIと同じ感覚で一括りにしないほうが安全です。Messages APIはAnthropic系モデルのリクエスト形式に寄せたインターフェースであり、ProjectsやWorkspacesの扱い、モデル対応、既存Claude実装との差分を別に確認します。
すでにClaude系モデルのAWS提供形態を追っている場合は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-15-claude-opus-48-aws-bedrock-platform/">Claude Opus 4.8のAWS提供記事</a>も合わせて見ると、BedrockとClaude Platform on AWSの使い分けを整理しやすくなります。ただし、この記事では新コンソール上で確認する項目に絞ります。
Projects運用で決めること
- 1アプリ単位を決める
生成AIワークロードを、どのアプリケーション単位で分けるかを先に決めます。
- 2環境を分ける
開発、ステージング、本番を同じProjectに入れるか、別Projectにするかを決めます。
- 3PoCを分離する
短期検証と本番候補を分け、利用量やコストを後から追いやすくします。
- 4タグと使用状況を見る
Project単位で評価、利用量、コスト感、クォータを確認できる状態にします。
- 5Project IDを管理する
アプリコードへの直書きを避け、環境変数や設定管理に寄せます。
Project、モデル、APIキーは同じ変更単位に見えても寿命が違うため、設定管理で分けて扱います。
新コンソールの発表では、作業がProjects単位で整理され、評価や使用状況を確認できるとされています。Projectsは単なるフォルダ名ではありません。Amazon BedrockのProjectsドキュメントでは、生成AIワークロードをアプリケーション単位で分離し、アクセス制御、コスト追跡、観測性を扱いやすくする単位として説明されています。
何をProjectで分けるか
最初に決めるべきなのは、Projectを何の境界にするかです。アプリケーションごとに分けるのか、開発、ステージング、本番で分けるのか、PoCと本番候補を分けるのか。ここを曖昧にしたまま試すと、あとから利用量やコストを追いにくくなります。
おすすめの考え方は、まず「用途」と「環境」を分けることです。たとえば社内検索PoC、顧客サポート本番、開発環境の評価ジョブを同じProjectに入れると、使用量、タグ、権限、失効判断が混ざります。小さく試す段階でも、Project名にアプリ名、環境、所有チームを入れておくと、後で棚卸ししやすくなります。
コストと使用状況のタグ設計
Projectsはコスト配賦にも関わります。Amazon Bedrockのコスト管理ドキュメントでは、Projectに付けたタグがAWS Cost ExplorerやCost and Usage Reportsで使える形に流れると説明されています。タグは作るだけでは十分ではなく、Cost allocation tagsとして有効化し、反映までの時間や非遡及性も見ておく必要があります。
| Project設計の項目 | 先に決めること | 決めない場合のリスク |
|---|---|---|
| Application | どのアプリの利用量か | PoCと本番の費用が混ざる |
| Environment | dev、stg、prodなど | 評価コストを本番コストと誤読する |
| Team | 所有チーム、運用責任者 | アラートや上限超過時の対応が遅れる |
| CostCenter | 社内の費用配賦先 | 月末の費用説明が属人的になる |
| Lifecycle | archiveや棚卸しの条件 | 使われないProjectが残り続ける |
コードサンプルとProject IDの扱い
新コンソールでProject-aware documentationが使えるなら、コードサンプルは単なる入門例ではなく、設定の棚卸しにも使えます。選択モデル、リージョン、エンドポイント、APIキー参照、Project IDがどこに入るのかを見れば、アプリ側の環境変数やSecret設計に反映できます。
注意点
Project IDをアプリコードに直書きする運用は避けたいところです。環境別にProjectを分けるなら、Project IDも環境変数や設定管理に寄せます。APIキー、Project ID、モデルID、リージョンは、同じ変更単位に見えても寿命が違います。モデルは検証で変わりやすく、Projectは運用境界として残りやすく、APIキーは期限や失効が前提になります。
APIキー、IAM、監査で確認すること
認証情報は勝敗ではなく条件差で見ます。短期キーと長期キーを同じものとして扱わず、IAMと監査の前提を先に決めます。
OpenAI SDKからAmazon Bedrockを呼び出す文脈では、APIキーの扱いが特に重要です。Amazon Bedrock API keysのドキュメントでは、短期キーと長期キーが分けて説明されています。短期キーは最大12時間またはセッション期間までで、生成元のIAM principalの権限を継承し、本番用途では短期キーが推奨されています。長期キーは設定した有効期限まで使える一方、探索用途として扱うべきものです。
短期キーと長期キーを同じものとして扱わない
ローカル検証だけなら、長期キーが便利に見える場面があります。しかし、長期キーは期限まで残る認証情報であり、管理対象のIAMユーザーやポリシーも関わります。PoCが終わったあともキーが残ると、誰がどの用途で使っているのか分かりにくくなります。
本番に近い検証では、短期キーの生成、更新、失効、CI/CDでの注入、Secrets Managerなどの管理先を先に決めておきます。OpenAI SDKの環境変数名を使っていても、中身はAmazon Bedrock APIキーです。OpenAI本体のキーとBedrockのキーを同じSecret名で混在させると、事故の原因になります。
CloudTrailで見えるもの、見えないもの
Amazon Bedrock API keysのドキュメントでは、APIコールはAWS CloudTrailに記録される一方、APIキー自体はAuthorization headerとして渡され、ログには記録されないと説明されています。これは安心材料であると同時に、誰がいつキーを作り、どの範囲で使えるようにしたかをIAMと運用記録で残す必要があるという意味でもあります。
IAMで確認すること
長期キーの作成を誰に許可するか、Bearer Tokenでの呼び出しをどのIDに許すか、短期キーだけを許可したいか、全APIキー利用を拒否したいIDがあるかを確認します。公式ドキュメントにはAPIキーの生成、利用、権限制御に関する項目が用意されているため、画面で試す前にIAMポリシーの棚卸しをしておくと安全です。
Secret管理で避けたい試し方
避けたいのは、便利だからという理由で長期キーを共有チャットやローカル設定ファイルに置き続けることです。もう一つ避けたいのは、OpenAI用の環境変数名を使っているために、チーム内で「これはOpenAI本体につながるキーなのか、Amazon Bedrockにつながるキーなのか」が曖昧になることです。
APIキー、Base URL、Project ID、モデルIDは、READMEやrunbookでセットとして説明しておきます。特にOPENAI_BASE_URLがbedrock-mantle.<region>.api.aws/v1形式のAmazon Bedrockエンドポイントを指しているか、OPENAI_API_KEYにAmazon Bedrock APIキーが入っているかは、初回接続時のチェックリストに入れる価値があります。
東京リージョン、料金、クォータの読み方
- 1リージョン
ap-northeast-1のbedrock-mantle endpointを確認します。
- 2モデル
使いたいモデルが東京リージョンと対象APIで使えるかを確認します。
- 3API
Responses API、Chat Completions API、Anthropic Messages API、Converse APIのどれで呼ぶかを分けます。
- 4料金
エンドポイント名だけで判断せず、Amazon Bedrock pricingとモデル別条件を確認します。
- 5クォータ
PoC負荷と本番想定に差がないか、Service Quotasと実測で確認します。
東京リージョン対応は出発点です。モデル対応、API対応、価格条件、スループットはそれぞれ別の確認項目です。
日本の読者にとって、東京リージョン対応は大きな確認点です。AWS What's NewとResponses APIのドキュメントでは、Asia Pacific Tokyoがbedrock-mantle提供リージョンに含まれ、ap-northeast-1のエンドポイントとしてbedrock-mantle.ap-northeast-1.api.awsが示されています。
東京リージョン対応とモデル対応は別に見る
リージョン対応が確認できても、使いたいモデル、API、クォータ、ツール利用、価格条件がすべて同じとは限りません。まず東京リージョンのbedrock-mantle endpointが使えることを確認し、次にモデル別のエンドポイント可用性、Responses API対応、Messages API対応、サービスクォータを確認します。
東京リージョンで試す場合の最小確認は、次の5つです。
| 確認項目 | 見る場所 | 判断 |
|---|---|---|
| endpoint | Responses API docs、コンソール | bedrock-mantle.ap-northeast-1.api.awsを使うか |
| モデル対応 | Endpoint availability、モデルカタログ | 使いたいモデルが対象APIで使えるか |
| API種別 | endpoints docs、モデル別ドキュメント | Responses、Chat Completions、Messages、Converseのどれか |
| クォータ | コンソール、Service Quotas | PoC負荷と本番想定に差がないか |
| ネットワーク | VPC、PrivateLink、既存接続設計 | NATやインターネット経由の前提を許容するか |
料金はエンドポイント名だけで判断しない
Amazon Bedrock endpointsドキュメントでは、同じモデルのper-token pricingはbedrock-runtimeとbedrock-mantleで同じと説明されています。つまり、エンドポイント選択は「どちらが安いか」ではなく、必要なAPI、状態管理、Projects、対応モデル、運用のしやすさで判断します。
ただし、最終的な費用はモデル、プロバイダー、モダリティ、入力トークン、出力トークン、利用ティア、バッチ推論、Guardrails、評価、追加機能で変わります。この記事では価格表を固定しません。公開後も変わりやすい情報なので、Amazon Bedrock pricingの公式ページを毎回確認してください。
クォータとスループットはPoC前に試す
エンドポイントの比較で見落としやすいのがスループットです。bedrock-runtimeはモデルごとのRPMやTPMを確認し、必要に応じて引き上げを検討する流れになります。bedrock-mantleはキューイングやスケジューリングの考え方が説明されていますが、すべてのリクエストが常に即時処理されると読むべきではありません。
評価基準
PoCの合格条件は、1回レスポンスが返ることだけにしないほうがよいです。p95レイテンシ、失敗率、ストリーミング中断、リトライ、Project別使用状況、上限に近づいたときの通知、コスト配賦まで見ると、本番へ進めるか判断しやすくなります。
既存利用者向け確認表
保存用の確認表として、API互換性、Project、認証、リージョン、観測性を同じ粒度で見直します。
すでにAmazon Bedrockを使っているチームは、新コンソールを「今すぐ移行する場所」ではなく「棚卸しする場所」として使うのが現実的です。特に、Bedrock Mantle、OpenAI互換API、Claude系モデル、AgentCore、CloudWatchメトリクスの情報が増えているため、導入判断を一度表に戻す価値があります。
| 利用状況 | 新コンソールで見ること | 追加で見る公式資料 | 未確認時のリスク |
|---|---|---|---|
| Bedrock Mantleを試している | Project、モデル比較、コードサンプル、使用状況 | endpoints docs、Responses API docs | Base URLやProjectの扱いが環境ごとにずれる |
| OpenAI SDKから移行したい | APIキー、OPENAI_BASE_URL、対象モデル | API keys docs、Endpoint availability | OpenAI本体とBedrockの認証情報を混同する |
| Anthropic Messages APIを使いたい | Messages API対応、モデルID、Project/Workspace | Workspaces、Projects、モデル別docs | OpenAI互換APIと同じ運用にまとめすぎる |
| 本番監視へ進みたい | Project別使用状況、評価、クォータ | CloudWatch、Cost Explorer、CUR | PoCの成功を本番安定性と誤読する |
| 東京リージョンで使いたい | ap-northeast-1、モデル対応、クォータ | Responses API docs、pricing | リージョン対応だけで全機能対応と誤解する |
Bedrock Mantleをすでに使っている場合
新コンソールで確認したいのは、既存の呼び出しコードがどのProject、どのモデル、どのリージョン、どのAPIキーに紐づいているかです。監視の詳細は<a href="https://amzn-watch.blog.mo-gmo.com/amzn-19-bedrock-mantle-cloudwatch-metrics/">Bedrock Mantle CloudWatchメトリクスの記事</a>で扱っていますが、メトリクスを見る前に、Project設計とモデル選定が整理されていないと、アラームやコスト配賦の意味が曖昧になります。
OpenAI SDKから移行を検討している場合
既存コードの変更点が少ないことは魅力です。ただし、移行判断は「最小変更で動いたか」ではなく、運用、監査、費用、リージョン、モデル対応を満たすかで決めます。OPENAI_BASE_URLの変更、Amazon Bedrock APIキー、Project指定、モデルID、対応API、ストリーミング、ツール利用を一つずつ確認します。
OpenAI系モデルやCodexのBedrock提供範囲を合わせて見たい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-14-openai-codex-bedrock-ga/">OpenAI GPT-5.5/5.4とCodexのBedrock一般提供記事</a>を参照してください。この記事では、新コンソールで何を確認するかに集中します。
Anthropic Messages API利用者の場合
Anthropic Messages APIを使う場合は、モデル対応、WorkspaceまたはProjectの境界、既存のClaude実装との差分を分けて確認します。OpenAI互換APIの話と同じ表に入れると便利ですが、実際のリクエスト形式、ヘッダー、モデル対応、運用境界は別です。
導入前に置く結論
開発環境でモデル比較をしたい、既存OpenAI SDKをBedrockに向けて最小検証したい、短期キーでPoCを動かしたい場合です。
本番候補、複数Project、長期キー、コスト追跡、監査要件が関わる場合です。
現在のbedrock-runtime運用で要件を満たし、互換APIへ寄せる理由がまだ薄い場合です。
導入判断は画面の便利さだけでなく、Project、認証、リージョン、クォータを先に整理できているかで分かれます。
今回のAmazon Bedrock新コンソールは、AWSの生成AI基盤を試す入口として便利になった発表です。ただし、便利な画面ほど、試す前の境界を決めておかないと後から整理しにくくなります。結論は、次の3つに分けられます。
すぐ試してよいケース
開発環境でモデル比較をしたい、既存OpenAI SDKをBedrockに向けて最小検証したい、東京リージョンでResponses APIの基本動作を見たい、PoC用Projectを作って短期キーで動作確認したい。このような場合は、新コンソールの価値が出やすいです。
それでも、最低限のProject名、所有チーム、APIキーの種類、上限予算、削除またはarchiveの条件は決めておきます。小さいPoCほど、後始末まで短くしておくと安全です。
設計してから試すべきケース
本番移行、複数チーム利用、顧客データ、監査要件、長期キー、費用配賦、ネットワーク制約が絡む場合は、コンソールを開く前に設計を置きます。Project分割、IAM、APIキー、CloudTrail、Secret管理、CloudWatch、Cost Explorer、ロールバックの責任者を決めてから試したほうが、結果を評価しやすくなります。
既存運用を維持する判断もあり得る
すでにbedrock-runtime、InvokeModel、Converseで安定しており、使いたいモデルやAPIがbedrock-mantleに乗っていない場合は、無理に寄せる必要はありません。新コンソールは、既存運用を置き換える命令ではなく、モデル比較とPoC設計を短くする道具として見るのがよいでしょう。
AmazonのAWS、Bedrock、AIエージェント基盤の更新は、月内で続けて出ることがあります。2026年6月の流れを横断して確認したい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月の重要トピックまとめ</a>も合わせて確認してください。記事更新の通知は<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>で受け取れます。
次に読むなら
参照した主な情報源
- AWS What's New「Amazon Bedrock launches a redesigned console optimized for OpenAI- and Anthropic-compatible APIs」確認日: 2026年6月5日 https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-redesigned-console-optimized-openai-anthropic-compatible-apis/
- Amazon Bedrock User Guide「Endpoints supported by Amazon Bedrock」確認日: 2026年6月5日 https://docs.aws.amazon.com/bedrock/latest/userguide/endpoints.html
- Amazon Bedrock User Guide「Inference using Responses API」確認日: 2026年6月5日 https://docs.aws.amazon.com/bedrock/latest/userguide/bedrock-mantle.html
- Amazon Bedrock User Guide「Projects (OpenAI-compatible)」確認日: 2026年6月5日 https://docs.aws.amazon.com/bedrock/latest/userguide/projects.html
- Amazon Bedrock User Guide「API keys」確認日: 2026年6月5日 https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html
- Amazon Bedrock User Guide「Projects」確認日: 2026年6月5日 https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-projects.html
- Amazon Bedrock Pricing 確認日: 2026年6月5日 https://aws.amazon.com/bedrock/pricing/