タグアーカイブ AWS

AWS Bedrock刷新、OpenAIとAnthropic API互換コンソールが登場

AWS Bedrock刷新、OpenAIとAnthropic API互換コンソールが登場

AWSが2026年6月5日、Amazon Bedrockの管理コンソールを刷新した。この新体験は「bedrock-mantle」エンジン向けに設計されており、Anthropic Messages APIとOpenAI Responses APIに最適化されている。

従来のBedrockコンソールはマネージド機能(AgentsやKnowledge Basesなど)を中心に据えていたが、今回の刷新はAPI直接呼び出しを前提とする開発者向けに設計し直されている。モデル選定からプロダクション実装までの時間を大幅に短縮する狙いだ。

この記事では、新コンソールの主要機能と開発ワークフローへの影響を詳しく見ていく。API互換性を活かしたコードの簡略化や、複数モデルの並列評価がどのように実現されるのかを解説する。

Bedrockの新コンソールが生まれた背景

Bedrockの新コンソールが生まれた背景
従来のBedrockコンソール
マネージド機能重視 Agents Knowledge Bases Guardrails
目的別にコンソールが分かれており、API直接操作には別ツールが必要
新Bedrockコンソール(Bedrock Mantle)
開発者中心 モデル選択 APIテスト コード生成
単一のプロジェクトベース画面で一貫した開発体験を提供

この図が示すように、新コンソールは「プロジェクト」を軸にした作りになっている。モデルの評価から実装、モニタリングまでをひとつの画面で完結させる狙いだ。

bedrock-mantleエンジンとは何か

bedrock-mantleは、Bedrockの第2世代推論エンジンとして位置づけられる。高速な処理性能と高い信頼性、そしてエンタープライズレベルのセキュリティを兼ね備えている。

最大の特徴はAnthropicとOpenAIのAPIプロトコルに互換性を提供することだ。ClaudeモデルにはAnthropic Messages API(メッセージAPI)を、GPTモデルにはOpenAI Responses API(レスポンスAPI)とOpenAI Chat Completions API(チャット補完API)を使える。これにより、既存のSDKコードをほぼ変更せずにBedrockへ移行できる。

従来のbedrock-runtimeエンドポイントを使う既存機能(InvokeModelやConverse API、Agentsなど)は、引き続き従来のBedrockコンソールから利用できる。両者は併存する設計で、急な移行は求められない。

新モデルカタログが提供する高速な比較体験

新モデルカタログが提供する高速な比較体験

新コンソールの目玉のひとつが、刷新されたモデルカタログだ。従来は各モデルの仕様を調べるためにドキュメントや料金計算ツールを行き来する必要があったが、それが1画面で完結するようになった。

最大3モデルを並べて比較

カタログ上で最大3つのモデルを選択し、機能、モダリティの対応状況、コンテキストウィンドウの大きさ、利用可能なリージョン、料金体系を横並びで比較できる。

モデルカタログ比較画面のイメージ
Claude Opus 4
コンテキスト: 200K
マルチモーダル: 画像・音声
応答速度: ★★★
GPT-5 Mini
コンテキスト: 256K
マルチモーダル: 画像
応答速度: ★★★★★
Llama 4 70B
コンテキスト: 256K
マルチモーダル: テキストのみ
応答速度: ★★★★
↑ 各モデルの特徴が1画面で把握でき、ユースケースに合った選択が容易に

この比較機能は、チーム内でのモデル選定会議や、PoC(概念検証)フェーズでの迅速な意思決定に力を発揮する。料金と性能のトレードオフを視覚的に把握できるのが強みだ。

プロジェクト単位で完結する開発ワークフロー

プロジェクト単位で完結する開発ワークフロー

新コンソールの中核は「プロジェクト」という概念だ。生成AIアプリケーションの開発ライフサイクルをプロジェクトとして管理し、モデルの割り当てからAPIキーの発行、推論リクエストの送信までを一気通貫で行える。

ダッシュボードでトークン消費を可視化

プロジェクトダッシュボードでは、直近の推論リクエスト数やエラー発生率を日付範囲でフィルタリングできる。さらに、総トークン消費量、1分あたりのトークン使用量、推論リクエストの回数、1リクエストあたりの平均トークン数がグラフ表示される。

プロジェクトダッシュボード トークン分析のイメージ
総トークン数
1.2M
前週比 +18%
トークン/分
843
ピーク時 2.1K
リクエスト/分
12.4
エラー率 0.3%
これらの指標をもとに、プロンプトの最適化やコスト見直しの判断ができる

このデータは、モデルの選択ミスや過剰なトークン消費を早期に発見する手がかりになる。チームの予算管理にも直結するため、プロダクション環境では特に価値が高い。

サイドバイサイド評価でプロンプトを最適化

プロジェクト内で最大3つのモデルを選択し、同じプロンプトに対する応答を横に並べて比較できる評価モードが用意されている。これにより、どのモデルが自社のユースケースに最適かを実データで判断できる。

評価結果はそのままプロダクション環境へ移行する際の根拠資料としても使える。カスタマーサポート用チャットボットであれば、回答の質と応答速度のバランスを定量的に比較できる。

コード生成とAIアシスタント連携の新機能

コード生成とAIアシスタント連携の新機能

最も実務インパクトが大きいのが、プロジェクトに紐づいた「ライブドキュメント」機能だ。コードサンプルやSDKスニペット、APIリファレンスにプロジェクトの変数(モデルID、リージョン、エンドポイントURL、APIキー)が自動で埋め込まれる。

コピーするだけで動くコードスニペット

開発者はコンソール上で表示されたコードをそのままコピーし、ローカル環境のアプリケーションに貼り付けるだけで動作確認できる。環境変数の手動設定やエンドポイントURLの確認といった手間が省ける。

自動プレフィルされるコードスニペットのイメージ
コピーするだけで動く
MODEL_ID=gp-5m-2026-04
AWS_REGION=us-east-1
ENDPOINT=bedrock-mantle
API_KEY=sk-xxxxxx
手動設定は不要
import boto3
client = boto3.client()
response = client.invoke(modelId=MODEL_ID)
プロジェクト設定を変更すると、表示されるコードも自動で更新される

この仕組みにより、環境構築のミスが大幅に減る。特に複数プロジェクトを抱えるチームでは、設定の食い違いによるトラブルシューティング時間を削減できる。

AIコーディングエージェントとの統合

新コンソールはAIコーディングエージェントとの連携もサポートする。Claude Code、Cline、Codex、Cursor、OpenCodeといった主要なAIアシスタントをBedrockのmantleエンジンにルーティングする手順がガイドされる。

具体的には、AWS IAM認証情報かBedrock APIキーを使い、環境変数を設定したうえで各エージェントからのリクエストをBedrock経由にする設定が案内される。これにより、AIアシスタントのバックエンドをOpenAIやAnthropicのクラウドからAWS環境に切り替えられる。企業ポリシーでデータの外部送信を制限しているケースで有効だ。

利用可能リージョンと今後の展開

利用可能リージョンと今後の展開

新コンソール体験は、bedrock-mantleエンドポイントが提供されている全リージョンで利用可能だ。2026年6月時点での対象は以下の通り。

bedrock-mantle対応リージョン
北米 US East(バージニア北部、オハイオ) US West(オレゴン)
アジア太平洋 ジャカルタ、ムンバイ、シドニー、東京
欧州 フランクフルト、アイルランド、ロンドン、ミラノ、ストックホルム
南米 サンパウロ
東京リージョンが含まれているため、国内での低レイテンシ利用も可能

AWSのドキュメントにはリージョン互換性の一覧ページが用意されており、将来的な拡大があれば随時更新される見込みだ。フィードバックはAWS re:Post for Amazon Bedrock、または通常のAWSサポート窓口を通じて送ることができる。

新コンソールは既存のBedrockコンソールと並行して運用される。急な切り替えを迫られることはなく、チームの準備が整った段階で徐々に移行できる設計だ。

この記事のポイント

  • Amazon BedrockにAPI互換性を重視した新コンソールが登場し、モデル評価から実装までの時間が大幅に短縮される
  • bedrock-mantleエンジンはAnthropic Messages APIとOpenAI Responses APIに対応し、既存SDKコードの流用が容易
  • 最大3モデルのサイドバイサイド比較と、プロジェクト単位のトークン消費可視化が組み込まれている
  • コンソール上のコードスニペットはプロジェクト変数が自動プレフィルされ、コピー後即実行できる
  • 東京リージョンを含む複数リージョンで利用可能、既存コンソールとの併存もサポートされる
Amazon Cognitoがマルチリージョンレプリケーションに対応、耐障害性向上とCMKサポートの詳細

Amazon Cognitoがマルチリージョンレプリケーションに対応、耐障害性向上とCMKサポートの詳細

AWSがAmazon Cognitoにマルチリージョンレプリケーション機能を追加した。ユーザーデータとM2M(Machine-to-Machine)シークレットを別のAWSリージョンに自動同期し、認証基盤の耐障害性を高める。あわせてカスタマーマネージドキー(CMK)による暗号化制御もサポートされた。

これまでマルチリージョンでの整合性維持には、エンジニアリングチームが手動で複製ソリューションを構築・運用する必要があった。今回のアップデートで、Cognitoが自動的にセカンダリリージョンへデータを複製し、リージョン障害時でも認証を継続できるようになる。

レプリケーションは一方向(プライマリ→セカンダリ)で動作し、プライマリリージョンの障害発生時にはセカンダリで認証処理を受け持つ。セッション継続性も担保され、既存ユーザーは資格情報の再設定なしでサインインを続けられる。

従来の手動レプリケーション(Before)
エンジニア手動でエクスポート・インポート
データ流出リスク
構成の不整合
パスワード再設定の強制
M2Mトークン再発行
Cognitoマルチリージョンレプリケーション(After)
Cognito自動で一方向同期(プライマリ→セカンダリ)
暗号化された安全な転送
プロファイル・資格情報・プール設定を自動反映
既存セッションは中断なしで継続
M2M通信もシームレスに引継ぎ

従来は手動レプリケーションに依存し、データ不整合やセキュリティリスクがつきまとっていた。新機能により、複製にかかる運用負荷を大幅に削減しつつ、認証の継続性を確保できる。

Cognitoマルチリージョンレプリケーションとは何か

Cognitoマルチリージョンレプリケーションとは何か

マルチリージョンレプリケーションは、Amazon CognitoがユーザーデータとM2Mシークレットの複製を自動管理する機能だ。プライマリリージョンからユーザーが選択したセカンダリリージョンへ、一方向でデータを同期する。

カバーされるデータの範囲と動作モード

複製の対象はユーザープロファイル、資格情報、ユーザープールの設定全体に及ぶ。セカンダリリージョンは読み取り専用モードで動作し、認証機能の維持に特化する。つまり、新規ユーザー登録やプロファイル更新といった書き込み操作はフェイルオーバー中には行えない。

この設計により、すべての認証方式(ソーシャルプロバイダ経由のフェデレーテッドサインイン、SAML、OIDC連携、API認可フロー)がサポートされる。対人認証だけでなく、バックエンドサービス間のM2M通信もレプリケーションの恩恵を受けられる点がポイントだ。

セッション継続性とトークンの相互認識

レプリケーション済みのユーザープールでは、プライマリ・セカンダリの双方が、どちらのリージョンで発行されたアクセストークンも有効とみなす。そのため、アクティブなセッションはリージョン切り替え前後を通じて中断されない。

この仕組みは、エンドユーザーにとって「裏側でリージョンが切り替わった」ことをまったく意識させずに済むという、実運用上の大きな利点になる。パスワードリセットの強制や再認証といった、ユーザー体験を損なう事態を回避できるわけだ。

CMKサポートで変わる暗号化の主導権

CMKサポートで変わる暗号化の主導権

マルチリージョンレプリケーションの利用には、AWS KMS(Key Management Service)上のマルチリージョンカスタマーマネージドキー(CMK)が必須となる。CMKはユーザーデータの保存時暗号化に一貫性をもたらし、利用者側に暗号化戦略の主導権を与える。

CMK導入による暗号化制御の比較
AWS管理キーのみ
AWS側で自動管理され、ユーザーは鍵のライフサイクルやローテーションを制御できない
CMK(カスタマーマネージドキー)
キーポリシー、ローテーション、監査ログをユーザーが制御。医療や金融などの規制業界の要件に対応可能

CMKの利用は、レプリケーション機能とは独立して提供される。つまり、単一リージョンのユーザープールでもCMKによる暗号化制御は利用可能だ。医療や金融サービスなど、規制の厳しい業界ではとくに重要な選択肢となる。

3ステップで始めるレプリケーション設定

3ステップで始めるレプリケーション設定

AWS News Blogの記事では、us-west-2(オレゴン)の既存ユーザープールをus-east-1(バージニア北部)に複製するデモが紹介されている。設定は管理コンソールから3つのステップで完了する。

STEP 1 AWS KMSでマルチリージョンCMKを作成し、キーポリシーにCognitoのアクセス許可を追加
STEP 2 OIDC発行者タイプをマルチリージョン向けに変更し、新しいエンドポイントをアプリに適用
STEP 3 ターゲットリージョンを選択してレプリケーションを開始、準備完了後に手動でアクティブ化

STEP 2のOIDCエンドポイント更新は、クライアントアプリケーション側の必須対応となる。サーバーサイドアプリは再デプロイ、モバイルアプリはストアへの更新申請が必要だ。この変更を怠ると、旧エンドポイントへのリクエストが正しくルーティングされず、認証障害を引き起こす。

追加で必要な設定と注意点

レプリケーション設定の完了後も、いくつかの付随リソースは手動でセカンダリリージョンに展開する必要がある。具体的には、カスタム認証フローに使うLambda関数、SMSやメール通知の設定、ログストリーミング、AWS WAFの構成が該当する。

AWS News Blogの記事では、これらの追加設定を計画的に実施するようコンソール上でトラッキングできる点も紹介されている。フェイルオーバー前に抜け漏れを防ぐ仕掛けとして有効だ。

フェイルオーバー運用とヘルスチェックの設計

フェイルオーバー運用とヘルスチェックの設計

プライマリとセカンダリの両エンドポイントは常時アクティブで、いつでもトラフィックを受け入れ可能な状態にある。フェイルオーバーの判断と実行は、アプリケーションの要件に合わせて利用者側が設計する形だ。

ヘルスチェックでは、エラーレートやレイテンシのパターン、サービスアラートを監視し、事前定義した基準を満たした場合にDNSの切り替えでセカンダリへトラフィックを誘導する。オフピーク時間帯に少量のトラフィックをセカンダリに流し、認証が期待通り動作するか検証しておくことが推奨されている。

フェイルオーバー判断の基準例
認証エンドポイントのエラーレートが閾値を超過
レイテンシが平常時の2倍以上に悪化
AWS Health Dashboardで該当リージョンの障害が通知
即時切り替え対象  要注意  外部シグナル

カスタムドメインでのマネージドログインやフェデレーションを利用している場合、Amazon Route 53のヘルスチェックIDをCognitoに提供することで、トラフィックルーティング機能を組み込むこともできる。これによりDNSレベルでの自動切り替えが容易になる。

料金体系と利用可能リージョン

料金体系と利用可能リージョン

マルチリージョンレプリケーションは、EssentialsティアおよびPlusティアのアドオン機能として提供される。料金は認証の種類によって異なる。

ユーザー認証(MAUベース)
Essentials: $0.0045 / MAU / レプリカリージョン
Plus: $0.006 / MAU / レプリカリージョン
M2M認証(トークンボリュームベース)
標準の従量課金に30%の追加料金が加算

利用可能リージョンは、米国東部(オハイオ、バージニア北部)、米国西部(北カリフォルニア、オレゴン)、アジアパシフィック(ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ(中部)、欧州(フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)、南米(サンパウロ)となっている。これらのリージョンはソース・デスティネーションのどちらとしても使用可能だ。

CMKサポートの提供リージョンはさらに広く、アフリカ(ケープタウン)、アジアパシフィック(香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ニュージーランド、大阪など)や、イスラエル(テルアビブ)、メキシコ(中部)、AWS GovCloudもカバーされている。

この記事のポイント

  • Amazon Cognitoにマルチリージョンレプリケーション機能が追加され、ユーザーデータとM2Mシークレットの自動同期が可能になった
  • レプリケーションにはAWS KMSのマルチリージョンCMKが必須で、暗号化制御の主導権を利用者側に与える
  • 設定は3ステップで完了するが、OIDCエンドポイント変更に伴うアプリ側の対応が必須となる
  • フェイルオーバー時のセッション継続性が担保され、エンドユーザーはパスワード再設定なしで認証を継続できる
  • 料金はアドオン形式で、ユーザー認証はMAUあたりの課金、M2M認証はトークンボリュームに対する30%追加となる
OpenAIの最先端モデルとCodexがAWSで一般提供開始。Bedrock経由で本番導入が加速

OpenAIの最先端モデルとCodexがAWSで一般提供開始。Bedrock経由で本番導入が加速

2026年6月1日、OpenAIの最先端モデルとCodexがAmazon Bedrock上で一般提供を開始した。すでにAWSをインフラ基盤として使う数百万の組織が、同じ管理画面とセキュリティポリシーのままOpenAIのAI機能を本番環境へ組み込めるようになる。

Codexは毎週500万人以上の開発者が使うソフトウェアエンジニアリングエージェントだ。コードの記述、レビュー、デバッグ、レガシーコードのモダナイズまで、開発の全工程をAWS環境の中で完結できる。商用リージョンとGovCloudの両方に対応する。

企業にとって最大の意味は「AI導入の運用障壁が一段下がる」ことにある。調達、セキュリティ審査、ガバナンス、請求管理といった本番運用に必須のプロセスを、すでに信頼済みのAWSガードレールの中で処理できるからだ。

企業がAI導入でぶつかっていた3つの壁

企業がAI導入でぶつかっていた3つの壁

OpenAIのAPIはここ数年で急速に高性能化した。GPT-4oをはじめとするフロンティアモデルは、自然言語の理解と生成だけでなく、構造化データの処理やマルチモーダル推論までこなす。それでも大企業の本番導入は想定より緩やかだった。理由は技術そのものではなく、運用プロセスにある。

セキュリティ審査とガバナンスの再構築

新しい外部サービスを本番環境につなぐには、情報セキュリティ部門による審査が避けられない。データの送信先、暗号化の有無、ログの保管場所、アクセス制御ポリシーとの整合性。これらを一から確認する作業は数週間から数ヶ月に及ぶ。OpenAI単体のAPIを使う場合、この審査プロセスが最初のハードルだった。

請求管理と調達フローの分断

クラウド費用をAWSで一元管理している企業にとって、別のSaaS契約を追加することは経理と調達の両面で負荷が増す。予算承認のフロー、請求書の処理、利用量の監視。それぞれが独立したサイロになり、小さなPoC(概念実証)の段階で手続きに埋もれてしまうケースも少なくなかった。

開発パイプラインとの統合コスト

AIの推論結果をアプリケーションに組み込むには、API呼び出しの認証、レート制限の管理、エラーハンドリング、モニタリングの仕組みを別途構築する必要があった。AWSのIAMやCloudWatchと統合されていないサービスを追加するたびに、運用スクリプトと監視設定を一から書く工数が発生していたのだ。

従来のAI導入フロー(Before)
新規SaaS契約 セキュリティ審査(数週間) 個別の監視基盤構築 運用チームへの引継ぎ
※セキュリティ・調達・監視がすべて個別プロセス。PoCが本番化するまでに数ヶ月かかる
AWS Bedrock経由の導入フロー(After)
Bedrockでモデル有効化 既存IAMポリシーで制御 CloudWatchで一括監視 AWS請求に統合
※既存のAWSガバナンス・監視・請求フローにAI機能がそのまま乗る。PoCから本番まで数日〜数週間

このデモ図が示すように、AWS Bedrockを経由することで調達・審査・監視のステップが一本化される。これが今回の発表でOpenAIが強調している「摩擦の低減」の正体だ。

2つの提供ルートが開いた意味

2つの提供ルートが開いた意味

OpenAIの機能はAWS上で2つの形態で提供される。どちらもAmazon Bedrockを基盤とするが、用途と対象者が異なる。

OpenAI models on Amazon Bedrock

GPT-4oをはじめとするOpenAIのフロンティアモデルを、BedrockのAPI経由で呼び出せる。BedrockはAWSが提供するフルマネージド型の基盤モデルサービスだ。すでにBedrock上で他のモデルを使っているチームであれば、同じIAMロール、同じVPCエンドポイント、同じCloudTrailの監査ログでOpenAIのモデルを追加できる。

これにより、チャットボット、文書要約、マルチモーダル分析といったユースケースを、セキュリティチームが事前承認したネットワーク境界の中で実装可能になる。データがAWSリージョン外に送信される心配もなく、社内ポリシーとの整合性を取りやすい。

Codex on Amazon Bedrock

CodexはOpenAIが提供するソフトウェアエンジニアリングエージェントだ。コードの自動生成だけでなく、プルリクエストのレビュー、バグの特定、依存関係の分析、レガシーコードのリファクタリング提案までを対話型で実行する。GitHubやIDEと統合して使うのが一般的だったが、今回の発表でAWS環境から直接Codexを呼び出せるようになった。

週に500万人以上の開発者がすでにCodexを利用している。この数字はGitHub Copilotのユーザー数に匹敵し、AIコーディング支援が一部のアーリーアダプターの手を離れ、メインストリームの開発プラクティスになったことを示している。AWS上でCodexを使えるようになることで、CI/CDパイプラインへの組み込みや、組織全体のコードレビューポリシーとの統合が現実的になる。

Codexの開発フローへの組み込みイメージ
開発者 コード記述 Codex 自動レビュー・提案 AWS CI/CD ビルド・テスト・デプロイ
※コードの記述からデプロイまで、AWS上の統合パイプラインで完結。Codexがレビューと改善提案を自動実行

Codexが開発パイプラインの中に組み込まれることで、コードレビューや依存関係チェックがプルリクエストのたびに自動で走るようになる。レビュアーの負荷が下がり、バグの早期発見にもつながる設計だ。

商用とGovCloudの両対応が示す信頼性

商用とGovCloudの両対応が示す信頼性

今回の発表で見逃せないのは、OpenAIの機能がAWSの商用リージョンとGovCloud(米国政府向けクラウド)の両方で提供される点だ。GovCloudはFedRAMPやITARなどの厳格なコンプライアンス基準を満たすために設計された隔離環境である。

政府機関や防衛産業、高い規制要件を持つ金融機関にとって、AIモデルをGovCloud内で実行できることの意味は大きい。データが閉域網から出ず、監査証跡もAWSの既存フレームワークで一貫管理される。OpenAIのモデルをパブリッククラウド越しに使うことに抵抗があった組織も、このオプションで導入検討の敷居が下がる。

OpenAIのCarlo Daniele氏は公式ブログで「企業が直面する最大の障壁は、最先端AIを既存のセキュリティとコンプライアンスの枠組みの中で本番運用することだ」と指摘している。GovCloud対応はまさにその障壁をターゲットにした一手といえる。

Daybreak構想とセキュリティ開発の未来

Daybreak構想とセキュリティ開発の未来

今回の発表と同時に、OpenAIは「Daybreak」という構想の将来提供も示唆した。Daybreakはソフトウェアの「作り方」と「守り方」の両方を変えることを狙ったビジョンだ。

Codex Securityが開発ループに入る日

Daybreakの中核には、サイバーセキュリティに特化したモデル群と「Codex Security」がある。これらは以下の機能を日常的な開発ループに組み込むことを目指している。

  • セキュアコードレビューの自動化
  • 脅威モデリングの支援
  • パッチ検証の効率化
  • 依存関係のリスク分析
  • 脆弱性の検出と修復ガイダンスの提示

現状、これらの作業の多くはセキュリティ専任チームが限られた時間の中で手動で行っている。コード量が増えるほどチェックが追いつかなくなり、既知の脆弱性が修正されないまま本番環境に残るリスクが高まる。Codex Securityはこのギャップを、開発者がコードを書くタイミングで自動的に埋めようという発想だ。

AWSがセキュリティ導入の加速路になる

Daybreakのような専用機能が本格提供されたとき、AWSはその導入経路として重要な役割を果たすとOpenAIは見ている。すでにAWS上でセキュリティ運用(GuardDuty、Security Hub、Inspectorなど)を回している組織であれば、Codex Securityの出力を既存のSOC(セキュリティオペレーションセンター)ワークフローに直接流し込めるからだ。

OpenAIの記事では「セキュリティチームがすでに使っているセキュリティ、ガバナンス、調達、運用のフレームワークの中でDaybreakを導入できる」と説明されている。セキュリティ強化のための新ツール導入が、逆に運用負荷を増やすという矛盾を避ける設計思想だ。

現在のセキュリティレビュー(Before)
開発者がPR作成 数日後にセキュリティチームが手動レビュー 修正依頼が後戻り
※レビュー待ちの間に別の機能が上乗せされ、コンフリクトと手戻りが発生
Codex Securityが入った開発ループ(After)
開発者がPR作成 Codexが自動で脅威モデルと脆弱性を検出 PR上で修正提案を確認してマージ
※セキュリティチェックがコードレビューと同時に完了。手戻りが激減し、リードタイムが短縮

このフローが実現すれば、セキュリティは「後付けの検査工程」から「開発と同時並行で走る自動プロセス」に変わる。Daybreakの提供時期はまだ明言されていないが、AWS基盤の上でこの構想が動き始めたこと自体が重要なシグナルだ。

開発チームが今から準備すべきこと

開発チームが今から準備すべきこと

OpenAI on AWSはすでに一般提供が始まっている。商用リージョンとGovCloudの両方で利用可能だ。開発チームがこの変化を活かすために、今から着手できることがいくつかある。

Bedrockのアクセス権を確認する

まず、自組織のAWSアカウントでBedrockが有効化されているか確認する。IAMポリシーでBedrockのモデルアクセス権限が適切に設定されているかも見直す必要がある。特にOpenAIのモデルを呼び出すには、Bedrock内でモデルアクセスを明示的にリクエストするステップが必要だ。

CodexをCI/CDパイプラインに組み込む設計を始める

Codex on BedrockはAPIとして提供されるため、GitHub ActionsやAWS CodePipelineと組み合わせて、プルリクエストの自動レビューやコード品質チェックに活用できる。すでにCodexをIDEで使っているチームは、パイプライン全体への展開を検討する段階に入ったといえる。

セキュリティチームとDaybreakのロードマップを共有する

Daybreakの具体的な提供日は未定だが、Codex Securityの方向性を事前にセキュリティチームと共有しておくことで、導入時の社内調整をスムーズにできる。脅威モデリングや依存関係分析の自動化がどのように既存のセキュリティ運用と統合されるのか、概念レベルで議論を始めておくのが有効だ。

この記事のポイント

  • OpenAIのフロンティアモデルとCodexがAmazon Bedrockで一般提供を開始
  • 既存のAWSセキュリティ・ガバナンス・請求管理の枠組みでAIを本番導入可能に
  • Codexは週500万人以上が使うエンジニアリングエージェントで、開発パイプラインへの統合が加速
  • 商用リージョンとGovCloudの両対応により、規制業界や政府機関の導入障壁が低下
  • Daybreak構想(Codex Security)が将来提供されれば、セキュリティレビューが開発と同時進行する形に変わる
AWS BedrockでOpenAI GPT-5.5とCodexが利用可能に。開発効率が飛躍

AWS BedrockでOpenAI GPT-5.5とCodexが利用可能に。開発効率が飛躍

AWSが2026年6月、Amazon Bedrock上でOpenAI GPT-5.5モデル、GPT-5.4モデル、そしてコーディングエージェントCodexの一般提供を開始した。これにより、Bedrockのセキュアなインフラ上で最先端の大規模言語モデルを利用できる。

GPT-5.5は最も難しいタスク向け、GPT-5.4はコストパフォーマンス重視のシナリオに適する。いずれも、新しい推論エンジン上で高速かつ信頼性の高い応答が得られる。Codexは週あたり400万人以上の開発者が使用するAIコーディングツールで、複数のIDEと連携しつつ、推論エンジン経由でBedrockからモデルを呼び出す。

データ主権要件に対応するため、すべての処理は選択したBedrockリージョン内に留まる。トークン単位の課金で、シートライセンスや開発者あたりの固定費は発生しない。本記事では利用開始手順と技術的な注意点を解説する。

AWS BedrockでOpenAI GPT-5.5とCodexが一般提供

AWS BedrockでOpenAI GPT-5.5とCodexが一般提供

AWSの年次カンファレンスでプレビューされていたOpenAIモデルの対応が、正式に利用可能になった。GPT-5.5とGPT-5.4は、コーディング、推論、エージェントワークフロー、複雑な専門業務に優れる。AWS News BlogのChanny Yun氏は、GPT-5.5を「最も難しい顧客のワークロード」向け、GPT-5.4を「最良の価格性能比」と位置づける。

モデルへのアクセスは、新しいBedrock推論エンジンが提供するResponses APIを介して行う。このAPIは、マルチターン状態管理、ホストツール、ファンクションツール、バックグラウンド実行をサポートする。

Bedrock経由でGPTモデルを利用するフロー
STEP 1 開発者がアプリケーションから Responses API を呼び出す
STEP 2 Bedrock推論エンジンがリクエストを受け付け、 bedrock-mantle エンドポイント経由でモデルに転送
STEP 3 選択したモデル( GPT-5.5 または GPT-5.4 )が推論を実行し、結果を返す
STEP 4 レスポンスがアプリケーションに返され、利用者が結果を得る
※実際の呼び出しはOpenAI SDKやcurlを使って行う。すべての通信はAWSのセキュアなネットワーク内で処理される。

この構成により、機密データを外部に送信することなく、AWSの管理下で最先端AIを活用できる。リージョンごとのデータ主権も担保される。

GPT-5.5モデルの利用方法

GPT-5.5モデルの利用方法

モデルへは、OpenAIのResponses APIを用いてアクセスする。Bedrock専用のエンドポイントbedrock-mantleを経由し、OpenAI SDKやcurlから呼び出す形だ。以下にセットアップ手順を示す。

Python SDKを使った呼び出し

まずOpenAI SDKを最新版にアップデートする。

pip install -U openai

認証用の環境変数を設定する。BedrockのAPIキーはAWSマネジメントコンソールから取得できる。

export OPENAI_BASE_URL="https://bedrock-mantle.us-east-2.api.aws/openai/v1"
export OPENAI_API_KEY="<BEDROCK_API_KEY>"
export BEDROCK_OPENAI_MODEL_ID="openai.gpt-5.5"

以下のサンプルコードで、GPT-5.5に分散アーキテクチャの設計を依頼できる。

import os
from openai import OpenAI

client = OpenAI(
    base_url=os.environ["OPENAI_BASE_URL"],
    api_key=os.environ["OPENAI_API_KEY"],
)

response = client.responses.create(
    model=os.environ["BEDROCK_OPENAI_MODEL_ID"],
    input=[
        {
            "role": "developer",
            "content": "You are a software engineer with excellent AWS cloud knowledge. Be concise and practical.",
        },
        {
            "role": "user",
            "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions.",
        },
    ],
    reasoning={"effort": "medium"},
    text={"verbosity": "low"},
)

print(response.output_text)

curlによる直接アクセス

curlを使う場合も同様に環境変数を設定した上で、エンドポイントへPOSTリクエストを送る。

curl "$OPENAI_BASE_URL/responses" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "openai.gpt-5.5",
    "input": [
      {
        "role": "developer",
        "content": "You are a software engineer with excellent AWS cloud knowledge."
      },
      {
        "role": "user",
        "content": "Design a distributed architecture on AWS in Python that should support 100k requests per second across multiple geographic regions."
      }
    ],
    "reasoning": {"effort": "medium"},
    "text": {"verbosity": "low"}
  }'

コード内のreasoning.effortは推論の深さを制御する。GPT-5.5ではmediumから始め、必要に応じてhighに変更すると良い。GPT-5.4の場合は明示的にeffortを指定すべきだ(デフォルトがnoneのため)。

CodexでAI駆動開発を体験する

CodexでAI駆動開発を体験する

Codexは、GPT-5.5を推論エンジンとしてバックグラウンドで利用するコーディングエージェントだ。CLI、デスクトップアプリ、VS CodeやJetBrains、Xcodeの拡張機能が提供され、大規模コードベースの作成、リファクタリング、デバッグ、テスト、検証をAIが支援する。

Codex CLIの設定手順

Codex CLIをインストール後、Bedrock認証を有効にする。APIキー認証とAWS SDKの認証情報チェーンの2方式があり、APIキーが優先される。

export AWS_BEARER_TOKEN_BEDROCK=<your-bedrock-api-key>

次に、~/.codex/config.tomlにモデル情報とリージョンを記述する。

model = "openai.gpt-5.5"
model_provider = "amazon-bedrock"
[model_providers.amazon-bedrock.aws]
region = "us-east-2"

デスクトップアプリやVS Code拡張では、必要な環境変数を~/.codex/.envに記述しておく。設定変更後はアプリケーションを再起動すれば反映される。

CLIで/statusタブを表示すると、モデルがBedrock経由で接続されていることを確認できる。Channy Yun氏の記事では、実際のステータス画面が示されており、モデルとしてopenai.gpt-5.5と表示される。

Codex が Bedrock 経由で API キー認証するフロー
STEP 1 開発者がCodex CLIにプロンプトを入力 例「認証機能を追加して」
STEP 2 Codexは設定ファイルから AWS_BEARER_TOKEN_BEDROCK を読み取り、Bedrock APIキーを取得
STEP 3 指定されたリージョン(us-east-2)の bedrock-mantle エンドポイントへRequests APIを送信
STEP 4 GPT-5.5モデルが推論を実行し、コード生成の結果を返す
※APIキーが見つからない場合、AWS SDKの認証情報チェーン(環境変数やIAMロール)にフォールバックする。

レイテンシやスケーリングの注意点

レイテンシやスケーリングの注意点

本番利用を始めるにあたり、いくつかの技術的なポイントを把握しておく必要がある。

モデルレイテンシの特性

GPT-5.5は高速、GPT-5.4は中速と位置づけられるが、実際の遅延は推論の深さ、出力長、ツール呼び出しの有無、バックグラウンドモード、リージョン、クォータ、スロットリング、プロンプトサイズ、キャッシュヒットに依存する。GPT-5.5ではreasoning.effortmediumで開始し、GPT-5.4では明示的にeffortを設定することを推奨する(デフォルトがnoneで十分な推論が得られない可能性があるため)。

スケーリングとキャパシティ管理

Bedrockの新しい推論エンジンは、多数のモデルにわたって迅速にキャパシティをプロビジョニングし、需要変動に応じてスケールする設計だ。定常的なワークロードの実行を優先し、需要急増時にはリクエストをキューイングする(拒否はしない)。そのため、予期せぬトラフィック増加時にも安定した動作が期待できる。ただし、クォータ上限を事前に確認し、必要に応じて引き上げ申請を行うことが望ましい。

この記事のポイント

  • Amazon Bedrock上でOpenAI GPT-5.5・GPT-5.4モデルとCodexが一般提供開始
  • Responses APIを通じてモデルを呼び出し、複雑なワークロードに対応
  • CodexはGPT-5.5をバックエンドに、CLI・デスクトップアプリ・IDE拡張で利用可能
  • データは選択したBedrockリージョン内で処理され、データ主権を確保
  • レイテンシは複数要因に依存し、effort設定やキャッシュが影響するため、初期はmediumから
  • スケーリングは自動だが、クォータ管理を怠らないこと
Amazon OpenSearch Serverless次世代版、AIエージェント構築向けに発表

Amazon OpenSearch Serverless次世代版、AIエージェント構築向けに発表

AWSが2026年5月28日、Amazon OpenSearch Serverlessの次世代版を一般提供開始した。AIエージェントアプリケーションの構築に特化したフルマネージド検索・ベクトルエンジンであり、スケールゼロからピーク時までシームレスに拡縮する。

従来のプロビジョニング型クラスタと比較して最大60%のコスト削減が可能とされる。リソース作成は数秒、スケーリング速度は前世代比で最大20倍に向上した。VercelやKiroといったAI開発プラットフォームとのネイティブ統合も備え、インフラ管理を意識せずに本番対応のバックエンドを数分で立ち上げられる。

この記事では、次世代OpenSearch Serverlessの主要な特徴、アーキテクチャ上の進化、AIエージェント開発への実践的な活用法を詳しく見ていく。

OpenSearch Serverless次世代版の概要

OpenSearch Serverless次世代版の概要

OpenSearchはElasticsearchからフォークしたオープンソースの分散型検索・分析エンジンだ。Amazon OpenSearch Serviceはそのマネージド版であり、サーバーレスオプションは2022年に導入された。今回の次世代版は、そのサーバーレスアーキテクチャを根本から刷新したものである。

AWS News Blogの記事によると、次世代版は「AIエージェントを構築する顧客向けに設計された」と位置づけられている。フルマネージドである点は変わらないが、スケーリングの速度とコスト効率が大幅に向上した。

主な改良点はスケールゼロと高速スケーリング

特筆すべきはスケールゼロへの対応だ。利用が途絶えると自動的にリソースが解放され、アイドル状態のコストがほぼゼロになる。リクエストが発生すると数秒でリソースが再作成され、前世代比で最大20倍速いスケールアップを実現する。

つまり、開発中の本番前ステージング環境や、トラフィックが断続的なAIエージェントのバックエンドで、大幅な無駄を省けるということだ。

従来のプロビジョニング型(Before)
常時稼働クラスタをピーク想定で確保
※夜間や開発中にも課金が継続
次世代OpenSearch Serverless(After)
利用時のみリソース割り当て、アイドル時はゼロ
※ピーク対比最大60%コスト削減
■ Before:常時稼働 ■ After:スケールゼロ対応

このデモは、従来型と次世代版のリソース管理モデルの違いを概念的に示したものだ。実際の環境では、数秒単位でプロビジョニングが動的に切り替わる。

コレクションタイプは全文検索とベクトル検索に限定

今回のリリース時点では、対応するコレクションタイプは全文検索(SEARCH)とベクトル検索(VECTORSEARCH)の2種類である。既存のOpenSearch Serverlessにあった時系列データやログ分析向けのタイプは、現時点では次世代版で選択できない。

これは、まずAIエージェント向けの検索基盤として最適化された領域に集中した戦略と見られる。今後のアップデートで順次拡張される可能性は高い。

スケールゼロと高速スケーリングの仕組み

スケールゼロと高速スケーリングの仕組み

次世代版のアーキテクチャを理解するには、従来のサーバーレス版との違いを押さえておくとよい。前世代のOpenSearch Serverlessは、あらかじめ設定された最小キャパシティユニット(OCU)を常に確保するモデルだった。利用がゼロになっても、その最小ユニット分のコストは発生し続けたのである。

OCUの最小値をゼロに設定可能

次世代版では、インデックス用と検索用それぞれの最小OCUをゼロに指定できるようになった。CLIコマンドを見ると、minIndexingCapacityInOCUminSearchCapacityInOCUに0が設定されているのがわかる。

この仕組みにより、トラフィックが完全に途絶えた時間帯はコンピューティングリソースが解放され、ストレージのみの課金になる。実質的に「寝ている間は課金されない検索エンジン」として振る舞うわけだ。

リソース作成が数秒で完了する理由

従来のサーバーレス版でコレクションを作成すると、数分かかることもあった。次世代版では、内部的なリソースプロビジョニングのパイプラインが刷新されており、数秒で利用可能になる。

これはAIエージェントの開発フローにおいて非常に重要だ。たとえばVercel上で新しいプロジェクトを作成し、そこにベクトルデータベースを接続する場合、即座にプロビジョニングが完了しなければ開発テンポが落ちてしまう。数秒で立ち上がるという体験は、プロトタイピングの高速化に直結する。

STEP 1 Vercelプロジェクト作成
STEP 2 OpenSearchコレクションを新規作成(数秒)
STEP 3 AIエージェントが即座に検索バックエンドを利用開始
■ STEP 1:環境準備 ■ STEP 2:バックエンド作成 ■ STEP 3:本番利用

このフローはVercel統合を活用した典型的なAIエージェントのセットアップ手順を図示したものだ。実際の操作はVercelの管理画面から数クリックで完了する。

VercelやKiroとの統合でAIエージェント構築を加速

VercelやKiroとの統合でAIエージェント構築を加速

次世代OpenSearch Serverlessの重要な価値は、AIエージェント開発プラットフォームとのシームレスな連携にある。Vercelの管理画面から直接OpenSearchコレクションを作成・接続できるようになったのがその典型だ。

Vercel統合の実用性

Vercelユーザーは、フロントエンド(Next.js等)のデプロイに加え、検索やベクトルストアをバックエンドインフラとして簡単に追加できる。従来であれば、別途Elasticsearch互換のDBを用意し、VPCネットワークを設定し、認証情報を安全に管理する手間が発生した。

これが管理画面上で完結するということは、開発者がインフラの設定に費やす時間を劇的に減らせる。特にAIエージェントのように試行錯誤を重ねるプロジェクトでは、この迅速さが競争力に直結する。

OpenSearch Agent SkillsとKiro Powers

AWS News Blogの記事では、Claude CodeやCursor、Kiroといった開発ツールとの連携も紹介されている。GitHub上のOpenSearch Agent Skillsというリポジトリには、特定のワークフロー向けのドメイン知識やベストプラクティスがスキルとしてパッケージ化されている。

たとえば「あるテーマに関する最新の技術ドキュメントを検索し、その結果を要約する」といった複数ステップのタスクを、エージェントがOpenSearchのスキルを呼び出すだけで実行できる。エージェントは単に検索結果を受け取るだけでなく、その検索がどのように実行されたかのプロセスも理解できるようになる。

開発者 自然言語で指示 AIエージェント スキル選択 OpenSearch 検索・ベクトル演算実行 結果+プロセス説明
開発者  AIエージェント  OpenSearch  結果

このインラインフローは、開発者がAIエージェントに指示を出してからOpenSearchが検索を実行し、結果が返るまでの一連の流れを色分けで示している。OpenSearch Agent Skillsによって、エージェントは適切なスキルを自動選択できる。

一方、Kiro Powersで提供されるOpenSearch Launchpadは、エンドツーエンドのアーキテクチャ計画をガイド付きで進められるツールだ。検索アプリケーションの全体設計をAIが支援することで、開発の初期段階から生産性を高められる。

導入方法、コンソールとCLI

導入方法、コンソールとCLI

次世代OpenSearch Serverlessの利用開始は簡単だ。マネジメントコンソールから「Serverless」メニューを選び、「Create collection」をクリックする。次の画面で「NextGen」を選択し、Express createを選べばデフォルト設定で即座にコレクションが作成される。

Express createで手間を省く

Express createは設定不要のクイック作成機能だ。セキュリティポリシーやネットワーク設定は自動で適用され、後から一部の設定を変更できる。プロトタイピングや検証用途では、まずExpress createで立ち上げ、必要に応じて細かな設定を詰めるアプローチが現実的だろう。

CLIからの作成手順

AWS CLIを使う場合は、まずコレクショングループを作成し、その中にコレクションを作る2段階の手順になる。以下はAWS公式ブログに掲載されたコマンド例を、実際の利用に即して整理したものだ。

# コレクショングループの作成(生成世代をNEXTGENに指定)
aws opensearchserverless create-collection-group \
    --name my-nextgen-group \
    --standby-replicas ENABLED \
    --generation NEXTGEN \
    --description "My NextGen collection group" \
    --capacity-limits '{
        "maxIndexingCapacityInOCU": 96,
        "maxSearchCapacityInOCU": 96,
        "minIndexingCapacityInOCU": 0,
        "minSearchCapacityInOCU": 0
    }' \
    --region "us-east-1"

# コレクションの作成(SEARCHまたはVECTORSEARCH)
aws opensearchserverless create-collection \
    --name my-nextgen-collection \
    --type SEARCH \
    --collection-group-name my-nextgen-group \
    --standby-replicas ENABLED \
    --description "My collection in NextGen group" \
    --region "us-east-1"

なお、ブログ公開時のCLIコマンドには最大OCUのデフォルト値に誤りがあり、後日修正された点には注意が必要だ。実際に使う場合は最新のドキュメントを参照してほしい。

AIエージェント時代のデータバックエンドの在り方

AIエージェント時代のデータバックエンドの在り方

OpenSearch Serverless次世代版の登場は、単なる新バージョン発表以上の意味を持つ。AIエージェントが自律的に情報を取得し、判断し、行動する時代において、「検索とベクトル演算のバックエンドをいかに手軽に、安く、速く用意できるか」が開発の成否を分けるからだ。

スケールゼロがもたらす開発文化の変化

従来、検索バックエンドの構築には「とりあえず動かす」だけでもある程度の初期コストが発生した。そのため、プロトタイプ段階では簡易的なインメモリ検索で代用し、後から本格的な検索エンジンに切り替えるパターンが一般的だった。

スケールゼロで最小OCUゼロが可能になったことで、最初から本番同様のOpenSearchを組み込んで開発を進められる。切り替えの手戻りがなくなり、より忠実な検証が可能になる。これはAIエージェントの品質を高める上で、見過ごせない利点だ。

マルチプラットフォーム連携の拡大予測

AWSはVercelとKiroに加え、今後さらに多くのAI開発プラットフォームとの統合を進めると見られる。GitHub CodespacesやReplit、Bolt.newなど、ブラウザベースの開発環境で動作するAIエージェントが増えれば、それらと連携する検索バックエンドの需要は右肩上がりだ。

OpenSearchがこの領域で競争力を発揮するためには、統合の容易さだけでなく、GPUアクセラレーションを活用したベクトル検索のパフォーマンスも鍵を握る。今回の次世代版ではGPU対応が明記されており、大量の埋め込みベクトルを扱う大規模AIエージェントのワークロードにも耐えられる設計が示されている。

コスト構造の変革と注意点

最大60%のコスト削減というインパクトは大きいが、これは「ピークキャパシティに合わせて常時プロビジョニングしていたクラスタ」との比較である。利用が常に一定水準以上あるサービスでは、スケールゼロの恩恵は限定的だ。

OCU単位の従量課金は、予測不能なトラフィックパターンを持つAIエージェントと相性が良い。一方、安定的に高いトラフィックが続く場合は、従来のプロビジョニング型OpenSearch Serviceの方がコストパフォーマンスに優れるケースもある。慎重な見積もりが求められる。

この記事のポイント

  • OpenSearch Serverless次世代版はAIエージェント構築に特化し、スケールゼロと高速スケーリングを実現
  • ピークプロビジョニング対比で最大60%のコスト削減、リソース作成は数秒で完了
  • VercelやKiroとのネイティブ統合で、数分で検索バックエンドをデプロイ可能
  • OCUの最小値をゼロに設定できるため、アイドルコストを極小化できる
  • 全商用リージョンで一般提供開始、導入はコンソールのExpress createまたはCLIで
AWS Resilience Hubが大幅刷新、生成AIで障害モードを分析しSREの信頼性管理を効率化

AWS Resilience Hubが大幅刷新、生成AIで障害モードを分析しSREの信頼性管理を効率化

AWSが「Resilience Hub」の次世代版を一般公開した。最大の変更点は生成AIを活用した障害モード評価の搭載だ。組織全体の信頼性を構造化されたポリシーで管理し、数百に及ぶアプリケーションの可用性リスクを一元的に可視化する。

今回の刷新では新たなアプリケーションモデルが導入され、依存関係の自動検出機能やモジュール式の信頼性ポリシーも追加された。SREチームと開発チームが同じ指標で対話し、エンタープライズ全体のレジリエンスを継続的に改善する基盤が整った形だ。

従来のResilience Hubが個々のアプリケーション評価に留まっていたのに対し、今回の刷新は「信頼性の管理」を組織のガバナンス領域に引き上げる。本記事ではその具体的な機能と実務への影響を詳しく解説する。

AWS Resilience Hubの全体像と考え方の変化

AWS Resilience Hubの全体像と考え方の変化
従来のアプローチ(Before)
各アプリケーション個別に評価を実施。チームごとに基準もツールもバラバラで、組織全体の信頼性を把握することが困難だった。
次世代Resilience Hub(After)
組織横断でポリシーを一元管理。生成AIが障害モードを自動分析し、依存関係も可視化。中央の管理アカウントから全AWSアカウントのレジリエンスを評価できる。

この比較が示すように、次世代版の本質は「個別最適から全体最適への転換」だ。AWS Organizationsとの統合により、委任管理者アカウントから複数アカウントを横断したレジリエンス評価が可能になった。

「ビジネス視点」で捉え直されたアプリケーションモデル

新しいモデルは3層構造になっている。最上位にビジネスアプリケーション全体を表す「システム」、その下にクリティカルな業務経路を示す「ユーザージャーニー」、さらに実際のデプロイ単位である「サービス」が配置される。サービスはAWSリソースやコード、オブザーバビリティの構成要素を束ねる役割だ。

この構造により「ログインできないと売上が止まる」という業務インパクトと、IAMロールの設定ミスという技術的リスクが地続きで評価できるようになる。AWS News Blogの記事でChanny氏は「ビジネス成果に直接結びつくクリティカルなエンドユーザー経路」という表現でこの概念を説明している。

モジュール式ポリシーでチーム間の共通言語を確立

信頼性ポリシーも大きく変わった。旧来は固定されたポリシータイプを選ぶ方式だったが、次世代版では必要な要件を組み合わせて構築できる。たとえば「可用性SLO 99.95%」「マルチリージョン災害復旧」「RTO 15分、RPO 5分」といった要素を選択し、金融系アプリケーション用のポリシーとして再利用する運用が可能だ。

SREと開発チームの間で「どの水準を目指すか」の共通理解が生まれ、属人的な判断を減らせる効果が期待できる。特に複数の開発チームを持つ組織では、この統一ポリシーがガバナンスの要になる。

生成AIが障害モードを評価する仕組み

生成AIが障害モードを評価する仕組み

次世代版の目玉機能が、生成AIを用いた障害モード評価である。サービスにポリシーを紐付けて評価を実行すると、AIが自動的に設定ミスや単一障害点を洗い出し、具体的な改善策を提案する。

STEP 1 ポリシーでSLOやRTO/RPOを定義する
STEP 2 AWSリソースの依存関係をトポロジとして自動マッピング
STEP 3 生成AIがWell-Architectedベストプラクティス等を参照し障害モードを分析
STEP 4 発見事項と推奨アクションをレポートとして提示

この4ステップのフローにより、人手では発見が難しいクロスアカウントの依存関係や、リージョンをまたぐ意図しない呼び出しまで検出できる。AIは単にデータを収集するだけでなく、障害が発生した場合の影響範囲を推定し、優先度付きの修正ガイダンスを出力する。

AWS Well-Architectedと分析フレームワークの統合

AIの評価ロジックはAWS Well-Architectedフレームワークのベストプラクティスと、AWS Resilience Analysis Frameworkを参照している。これにより「なんとなく不安」ではなく、定義された基準に照らした再現性のある評価が実現する。

評価結果では「どのポリシー要件に違反しているか」が明示される。たとえば「RTO 15分を満たすには、このAuto Scalingグループのインスタンスが起動するまでの時間が長すぎる」といった具体的な指摘が得られる。対策の優先順位をビジネスインパクトに基づいて判断できる点が実務的に価値が高い。

また、ユーザーがAssertion(表明)を追加してAIの分析精度を高める仕組みも用意されている。たとえば「このサービスは特定のリージョンでのみ稼働する」といった前提条件をAIに伝えることで、無関係なマルチリージョン構成の提案を除外できる。

依存関係の自動検出がもたらす可視性の向上

依存関係の自動検出がもたらす可視性の向上

多くの障害は「認識されていない依存関係」から発生する。次世代Resilience HubはDNSクエリログを解析し、VPC内のエンドポイントから呼び出されているAWSサービスや内部API、サードパーティの外部エンドポイントを自動で特定する。

依存関係が不明な状態(Before)
「このAPIが別リージョンのRDSを参照していたとは知らなかった」という認識不足が障害の長期化を招く。手動での依存関係調査には限界があった。
依存関係を自動可視化(After)
DNSクエリログからクロスリージョン呼び出しやサードパーティ依存を自動検出。サービス間の接続がトポロジマップとして視覚化され、単一障害点の特定が容易になる。

この機能の価値は運用の暗黙知を形式知に変換する点にある。「ベテランSREだけが知っている」依存関係を、システムが自動でドキュメント化してくれる。異動や退職によるナレッジロスを防ぎ、障害対応の属人性を低減する効果が期待できる。

依存関係検出はサービス作成時に有効化する。VPCフローログではなくDNSクエリログを解析する仕組みのため、ネットワークトラフィックの暗号化状況に影響されず、比較的軽量に動作する設計だ。不要な場合は管理画面の設定から無効化できる。

実際の利用フローと移行パス

実際の利用フローと移行パス

新規導入の基本的な流れ

導入の流れはシンプルだ。まず信頼性ポリシーを作成し、次にビジネスアプリケーションを表す「システム」を登録する。システム配下に、マイクロサービスなどのデプロイ単位である「サービス」を作成し、AWSリソースのタグやCloudFormationスタック、Terraformのステートファイル、EKSクラスタなどを指定してリソースを関連付ける。

準備が整ったら「障害モード評価の実行」をクリックする。Resilience HubがInvokerロールを引き受け、指定されたリソースの親子関係を解析し、トポロジを構築。その上でAIがポリシーに対するギャップを評価する。

評価完了後は「サービス詳細」画面の「Assessment」タブで発見事項を確認できる。各項目には障害モードの説明、アーキテクチャへの影響、修正方法、関連するポリシー要件が明記される。対応が完了した項目は「Mark as resolved」でクローズし、未対応の課題だけをトラッキングできる。

既存ユーザー向けの移行API

すでに従来版のResilience Hubを利用している組織向けには、移行用APIが提供されている。従来の評価ポリシーを新ポリシー形式に変換し、複数の関連アプリケーションを新モデルの「1システム配下の複数サービス」構造に再マッピングする機能だ。

手動での再設定が不要なため、既存の評価データを活かしつつスムーズな移行が可能になっている。大規模組織ほどこの移行APIの価値は大きい。

運用に組み込む際のポイントと今後の展望

運用に組み込む際のポイントと今後の展望

Resilience Hubの次世代版を実運用に組み込む場合、いくつか意識すべき点がある。第1にポリシー設計の重要性だ。SLOやRTO、RPOの値はビジネス要件から逆算する必要がある。「とりあえず99.99%」といった一律設定では、過剰なコストを生むか、逆に重要なサービスを見落とすリスクがある。

第2に、依存関係検出のスコープ調整だ。DNSクエリログ解析は強力だが、ノイズとなる外部通信も拾う可能性がある。検出結果を精査し、クリティカルでない依存関係をフィルタリングする運用プロセスを組み込むことが望ましい。

第3に、AIの分析結果を鵜呑みにしないことだ。Assertion機能を活用し、自社のアーキテクチャ特性をAIに正しく伝える努力が求められる。あくまで「AIの提案をSREが判断する」という協調モデルが効果的である。

料金体系は新たなサービスベースモデルに移行した。各サービスにつき月2回の障害モード評価が含まれ、依存関係の自動評価はオプションとなる。大規模環境では評価回数がボトルネックになる可能性があるため、クリティカルなサービスに絞って評価頻度を設定するなどの工夫が必要だ。

今後はAWS Organizationsとの統合がさらに強化され、組織全体のレジリエンススコアをスコアカード化する機能や、CI/CDパイプラインへの組み込みによるシフトレフトな信頼性評価への展開が期待される。

この記事のポイント

  • 生成AIによる障害モード評価で、人手では困難な依存関係や設定ミスを自動的に発見できる
  • ビジネス視点のアプリケーションモデルにより、技術リスクと業務インパクトを地続きで評価可能になった
  • モジュール式ポリシーがチーム間の共通言語として機能し、ガバナンスの実効性が高まる
  • DNSクエリログ解析による依存関係の自動可視化で、運用の暗黙知を形式知に変換できる
  • 既存ユーザー向けの移行APIが用意されており、大規模組織でもスムーズに移行可能である
Amazon RedshiftにGraviton搭載のRGインスタンス登場、データレイククエリエンジンも統合

Amazon RedshiftにGraviton搭載のRGインスタンス登場、データレイククエリエンジンも統合

Amazon Redshiftに新しいインスタンスファミリー「RG」が追加された。AWSのArmベースプロセッサ「Graviton」を採用し、データウェアハウスのワークロード処理を従来のRA3インスタンスと比較して最大2.2倍高速化する。vCPUあたりの価格は30%引き下げられ、分析コストの大幅な圧縮が見込める。

さらに、このRGインスタンスではデータレイクへのSQLクエリ実行機能がクラスタノードに統合された。Apache Icebergテーブルへのクエリは最大2.4倍、Apache Parquetへのクエリは最大1.5倍高速化している。これまで別途必要だったRedshift Spectrumと、1TBあたり5ドルのスキャン料金が不要になる点も見逃せない。

BI(ビジネスインテリジェンス)ダッシュボードやAIエージェントによる大規模なクエリ実行が日常化する中、今回の刷新はパフォーマンスとコストの両立をこれまで以上に高い水準で実現するものだ。

RGインスタンスの概要と主要な性能向上

RGインスタンスの概要と主要な性能向上
【従来】RA3ベースの構成
RA3インスタンス
データウェアハウス処理
Redshift Spectrum(データレイククエリ専用)
※ SpectrumはTBあたり$5のスキャン料金が発生
【新】RGベースの統合構成
RGインスタンス(Graviton搭載)
データウェアハウス処理(最大2.2倍高速)
データレイククエリエンジン統合(Iceberg最大2.4倍高速)
※ Spectrum不要、スキャン料金ゼロ
従来のRA3構成  新RG構成で追加・強化された部分

このデモは従来のRA3構成と新RG構成の違いを視覚化したものだ。RGインスタンスではデータレイククエリ機能が完全に統合され、外部のSpectrum層に依存しないアーキテクチャに変わっている。

Gravitonプロセッサがもたらす価格性能比の改善

RGインスタンスの中核にあるのは、AWSが設計したArmアーキテクチャのカスタムプロセッサ「Graviton」だ。x86系のチップと比べて電力効率が高く、同じ電力あたりの処理量を引き上げられる特徴がある。AWSのサービスにおけるGraviton採用はEC2やRDSなどで既に広がっており、Redshiftでもその恩恵を受けられるようになった。

具体的なインスタンスタイプとしては、エントリー向けの rg.xlarge(4vCPU、32GBメモリ)と、本番ワークロード向けの rg.4xlarge(16vCPU、128GBメモリ)が用意された。従来の ra3.xlplus から rg.xlarge への移行では、vCPU数とメモリ容量は同等だが処理性能自体が大きく向上する。一方、ra3.4xlarge から rg.4xlarge への移行ではvCPU数が12から16へ約1.33倍、メモリも96GBから128GBへと拡張され、単純なスペック面でも上積みがある。

AWS News Blogの記事によれば、これらの新インスタンスはデータウェアハウス処理でRA3比最大2.2倍の性能を達成しているという。企業が日常的に利用するBIダッシュボードの応答速度や、ETL処理のバッチジョブ実行時間が大幅に短縮される計算だ。

データレイククエリエンジン統合の実質的な意味

データレイククエリエンジン統合の実質的な意味
【データレイククエリの処理フロー(Before)
Redshiftクラスタ Spectrum層(外部) S3データレイク
※ クエリがVPC外部のSpectrum層を経由、TBあたり$5のスキャンコストが加算
【データレイククエリの処理フロー(After)
Redshift RGクラスタ 統合クエリエンジン S3データレイク
※ VPC内で完結、スキャン料金ゼロ、データ移動不要

RGインスタンスで最も構造的な変化が起きたのは、データレイククエリの実行方式だ。これまではS3に置かれたデータレイクに対してSQLで分析する際、Redshift Spectrumという別のサービス層を経由する必要があった。このSpectrum層はクラスタの外部で動作するため、VPCの境界を越えたデータのやり取りが発生し、1TBあたり約5ドルの追加スキャン料金が積み上がる仕組みだった。

Spectrumが不要になったことで変わる運用とコスト

RGインスタンスでは、データレイクへのクエリをクラスタ上のノードで直接実行する。Spectrum層を経由しないため、クエリがVPCの内側に留まり、IAMロールも既存のものをそのまま使える。セキュリティ境界がシンプルになるだけでなく、データレイク利用時の通信レイテンシも低減する。

コスト面では、Spectrumのスキャン料金がゼロになる影響が大きい。例えば月間10TBのデータレイクをスキャンするワークロードの場合、Spectrumだけで月50ドルの追加コストが発生していた。RGインスタンスへの移行後は、このコストが完全に消える。データレイク分析の規模が大きい企業ほど、削減額は積み上がる計算だ。

既存の外部テーブルやスキーマ定義、クエリ構文はそのまま動作するため、アプリケーションコードの修正は不要だ。移行に伴う手間を最小限に抑えつつ、性能向上とコスト削減の両方を手に入れられる設計になっている。

AIエージェント時代を見据えた設計思想

AIエージェント時代を見据えた設計思想

今回のRGインスタンス投入の背景には、AIエージェントによるデータウェアハウス利用の急増がある。自律的に目標を追求するAIエージェントは、人間のアナリストとは比較にならない頻度でクエリを発行する。AWS News BlogのChanny Yun氏は、AIエージェントのクエリ量が「典型的な人間の利用規模を矮小化する」と表現している。

大量の低レイテンシSQLクエリを安定的に処理するには、1クエリあたりのコストを大幅に下げつつ、応答速度も維持しなければならない。vCPU単価で30%のコストダウンを実現しつつ、処理そのものを高速化したRGインスタンスは、まさにこの要求に応える製品だと言える。2026年3月に発表された新規クエリの最大7倍高速化と組み合わせることで、AIエージェントがリアルタイムにデータを参照しながら判断するワークロードにも耐えうる基盤が整った。

移行手順と現在の利用可能リージョン

移行手順と現在の利用可能リージョン
移行パスの選択
弾力的なリサイズ ダウンタイム10〜15分でインプレース移行。互換性のある構成が対象。
スナップショットと復元 RA3のスナップショットからRGクラスタを新規作成。移行時に構成変更も可能。

RGインスタンスへの移行は、AWSマネジメントコンソール、CLI、APIのいずれからでも実行できる。データレイククエリエンジンはデフォルトで有効化されており、クラスタ作成後すぐに統合環境を利用できる。

移行パスは大きく2つある。1つ目は弾力的なリサイズで、互換性のある構成であれば10〜15分のダウンタイムでインプレース移行が完了する。2つ目はスナップショットと復元で、既存のRA3クラスタからスナップショットを取得し、RGインスタンスの新規クラスタとして復元する方法だ。移行時に構成を変更したい場合に適している。

2026年5月時点で、RGインスタンスは以下のAWSリージョンで利用可能だ。米国東部(バージニア北部、オハイオ)、米国西部(北カリフォルニア、オレゴン)、アジアパシフィック(香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、台湾、東京)、カナダ(中部)、欧州(フランクフルト、アイルランド、ミラノ、ロンドン、パリ、スペイン、ストックホルム)、南米(サンパウロ)と、主要リージョンをほぼ網羅している。東京リージョンも含まれているため、国内のワークロードにも即座に適用可能だ。

実務者が押さえるべき導入判断のポイント

実務者が押さえるべき導入判断のポイント

RGインスタンスは確かに魅力的だが、導入にあたってはいくつか確認すべき点がある。まず、オンデマンドインスタンスとリザーブドインスタンスの両方が提供されているため、長期的な利用が見込めるならリザーブドインスタンスによるコスト最適化を検討したい。AWS料金計算ツールで自社のワークロードパターンに基づいたシミュレーションを行うのが確実だ。

次に、Spectrumに依存していた既存のETLパイプラインや外部ツールとの統合に問題がないか、事前に検証環境でテストすることを推奨する。クエリ構文や外部テーブル定義は互換性が保たれているが、パフォーマンス特性が変わるため、実行計画の変化によって一部のクエリで想定外の挙動が生じる可能性はゼロではない。

最後に、データレイクとデータウェアハウスの両方を1つのインスタンスファミリーで処理できるようになったことで、アーキテクチャの簡素化と運用負荷の低減が見込める。特にデータレイクの分析規模が拡大傾向にある企業や、AIエージェントの本格導入を検討しているチームにとって、RGインスタンスへの早期移行は競争力の源泉になりうる。

この記事のポイント

  • RGインスタンスはGraviton搭載によりRA3比最大2.2倍の性能とvCPU単価30%削減を両立
  • データレイククエリエンジンが統合され、Spectrumと1TBあたり5ドルのスキャン料金が不要に
  • Apache Icebergで最大2.4倍、Parquetで最大1.5倍のクエリ高速化を達成
  • BIダッシュボードやAIエージェントによる大量クエリを低コストで処理できる基盤が整った
  • 移行は弾力的リサイズまたはスナップショット復元で対応、既存クエリの修正は不要
AWS最新動向(5月11日週) Bedrock AgentCoreの支払い機能とAgent Toolkitを解説

AWS最新動向(5月11日週) Bedrock AgentCoreの支払い機能とAgent Toolkitを解説

2026年5月11日の週、AWSはAIエージェントの自律的な動作を根本から変える発表を相次いで行った。最も注目すべきは、Amazon Bedrock AgentCoreがエージェント自身による支払い機能のプレビューを開始したことだ。これによりAIエージェントはAPIや外部サービスの利用料を自ら決済し、実行タスクに必要なリソースを動的に調達できるようになる。

AWS News Blogの著者であるChanny Yun氏が執筆した週次ラウンドアップによれば、この支払い機能はCoinbaseおよびStripeとの提携で構築された。さらに、AIコーディングエージェント向けの「Agent Toolkit for AWS」や、エージェントにデスクトップ環境を提供する「WorkSpaces for AI agents」も発表されている。本記事ではこれらの新機能を技術面とビジネスインパクトの両面から分析する。

Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来

Amazon Bedrock AgentCoreの支払い機能が示す「エージェント経済圏」の到来

AIエージェントが「考える」だけでなく「支払う」時代が来た。Amazon Bedrock AgentCoreにプレビューとして追加された支払い管理機能は、エージェントがAPI、MCPサーバー、Webコンテンツ、さらには他のエージェントの利用料を自律的に支払うことを可能にする。これは単なる便利機能ではない。エージェントが経済活動の主体になるための第一歩といえる。

従来のエージェント(Before)
エージェントが有料APIに遭遇
決済手段がないためタスク中断
AgentCore Payments導入後(After)
エージェントが有料APIに遭遇
予算枠内で自動決済しタスク続行

この図が示すように、従来は有料サービスへのアクセスがエージェントのボトルネックだった。AgentCore Paymentsによってその制約が取り払われる。

CoinbaseとStripeとの提携が意味するもの

AWSはこの支払い基盤を単独で構築しなかった。暗号資産ウォレットのCoinbase(CDP Wallet)と決済プラットフォームのStripe(Privy Wallet)という、まったく異なる決済レイヤーの企業と提携している。Coinbase連携によりオンチェーン決済が可能になり、Stripe連携は従来型の法定通貨決済をカバーする。この二段構えが示唆するのは、AWSが特定の決済手段に依存せず、マルチペイメントレイヤーのエコシステムを目指しているということだ。

セッション単位の支出制限とガバナンス設計

エージェントに支払い権限を与えると聞いて、真っ先に浮かぶ懸念は「使いすぎ」や「不正利用」だろう。AWSはこの点をセッションレベルの支出制限で対策している。開発者はエージェントの実行セッションごとに予算上限を設定でき、その範囲内でのみ決済が実行される。企業の与信管理と同じ考え方をエージェント単位に落とし込んだ設計だ。

さらに、認証情報管理とコンプライアンス対応も組み込まれている。各エージェントは決済手段に直接アクセスするのではなく、事前に登録されたウォレット接続を通じて取引を実行する。AWSのIAM(Identity and Access Management)に似た権限管理の考え方が、支払い領域にも適用された形だ。

エージェント経済圏が実務にもたらす変化

Channy Yun氏がブログ記事で最も興奮していると述べたポイントは、この機能が解き放つユースケースの広がりだ。たとえば、リサーチエージェントがリアルタイムの市場データを動的に購入して分析に組み込む、あるいはコーディングエージェントがタスク実行中に有料APIを呼び出して機能を補完する、といった動作が実現する。

これはクラウドの従量課金モデルをエージェント自身が直接操作できるようになることを意味する。開発者はあらかじめすべてのAPI契約を整備する必要がなくなり、エージェントが実行時に必要なリソースを判断して調達する。インフラ構築の手間が一段階抽象化されるわけだ。

Agent Toolkit for AWSが実現する「AI時代のインフラ構築」

Agent Toolkit for AWSが実現する「AI時代のインフラ構築」

AgentCore Paymentsと並んで注目を集めたのが、AIコーディングエージェント向けの「Agent Toolkit for AWS」の発表だ。これはエージェントがAWS上で構築作業を行う際のエラー削減、トークンコスト低減、エンタープライズグレードのセキュリティ制御を実現する本番環境向けツールスイートである。追加料金なしで利用できる。

AWS MCPサーバーの一般提供とAgent Toolkitの関係

Agent Toolkitの中核コンポーネントとして、AWS MCP Serverが一般提供(GA)に移行した。MCP(Model Context Protocol)サーバーは、AIエージェントやコーディングアシスタントがAWSの全サービスに対して安全かつ認証付きでアクセスするためのマネージドなリモートサーバーだ。少数の固定ツールセットを通じて、複雑なAWS APIを抽象化する。

端的にいえば、エージェントに「AWS全体への安全なアクセス権」を渡す仕組みである。従来は開発者がIAMポリシーやAPIキーを個別に設定し、エージェントに渡す必要があった。MCPサーバーを使えば、これが統合認証のレイヤーで一元管理される。

ツールキットがエンジニアのワークフローをどう変えるか

Agent Toolkitは、これまでAWS Labsで提供されていたMCPサーバーやプラグイン、スキルの後継に位置づけられる。実験段階から本番利用への移行を意図した製品だ。具体的には以下の3つの価値を提供する。

  • エラー削減: エージェントがAWSリソースを操作する際の設定ミスや権限違反を減らす
  • トークンコスト低減: 最小限のツール呼び出しで済むよう最適化され、LLMのAPI利用料を抑える
  • セキュリティ制御: 企業のセキュリティポリシーに準拠したアクセス制御を適用できる

開発者にとっては、AIエージェントに「AWSの操作方法」を一から教え込む必要がなくなる点が大きい。ツールキットが提供するスキルとプラグインを組み込むだけで、エージェントはAWSリソースのプロビジョニングや監視、トラブルシューティングを標準化された方法で実行できる。

AIエージェントにデスクトップを提供するWorkSpacesの狙い

AIエージェントにデスクトップを提供するWorkSpacesの狙い

プレビューとして発表された「Amazon WorkSpaces for AI agents」は、一見すると奇妙な機能に思える。AIエージェントが仮想デスクトップを使うとはどういうことか。狙いは、エージェントにGUIアプリケーションを操作させることにある。

従来の自動化(Before)
APIがあるアプリだけ自動化可能
レガシーGUIアプリは自動化の対象外
WorkSpaces for AI agents導入後(After)
エージェントが仮想デスクトップ上でGUIを操作
レガシーアプリも含めた全社ワークフローを自動化

多くの企業には、Web APIを持たない古い業務アプリケーションが残っている。WorkSpaces for AI agentsは、エージェントがこうしたGUIアプリケーションの画面を認識し、クリックやキー入力をエミュレートすることで、人間のオペレーターと同じ操作を実行できるようにする。

セキュリティ面では、エージェント専用のマネージドWorkSpaces環境が割り当てられ、エンタープライズグレードのガバナンスとコンプライアンスを維持したまま動作する。企業が長年抱えてきた「API化できない業務の自動化」という課題に対する、AWSなりの回答といえる。

第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上

第6世代Intel搭載の新型EC2インスタンスがもたらす性能向上

AI関連の発表に隠れがちだが、基盤となるコンピュートリソースにも重要なアップデートがあった。Amazon EC2のM8idn/M8idbおよびR8idn/R8idbインスタンスが発表されたのだ。これらはAWS専用にカスタマイズされた第6世代Intel Xeon Scalableプロセッサと、最新の第6世代AWS Nitroカードを搭載する。

vCPUあたり最大43%の性能向上

発表データによれば、前世代インスタンスと比較してvCPUあたりのコンピュート性能が最大43%向上している。この数字は単なるベンチマーク上の改善ではない。同じコストでより多くのワークロードを処理できることを意味する。

ネットワーク帯域とEBS帯域の強化

インスタンスタイプによって提供されるネットワーク性能も明確に差別化されている。M8idn/R8idnは最大600Gbpsのネットワーク帯域を提供し、M8idb/R8idbは最大300GbpsのEBS(Elastic Block Store)帯域に対応する。前者はネットワーク集約型ワークロードに、後者はストレージI/Oが重要なデータベースや分析ワークロードに最適化されている。

実務的には、機械学習のトレーニングデータを高速に読み込む必要があるケースや、大規模な分散データベースを運用するケースで効果を発揮する。M8idnとR8idnの選択肢が増えたことで、ワークロード特性に応じた細かいインスタンス選定が可能になった。

ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」

ValkeyとS3 Vectorsに見るデータ基盤の「ベクトル化」と「オープン化」

5月11日の週には、データ基盤に関する注目すべき動きもあった。OSS(オープンソースソフトウェア)のキーバリューストアであるValkeyが2周年を迎え、Amazon S3 VectorsとAurora PostgreSQLの統合に関する詳細なガイドが公開された。

Valkeyの急成長が証明するコミュニティ駆動開発の強さ

AWSのデータベースブログが報じたところによれば、ValkeyはDocker Pull数が1億を突破し、前年比17倍という急成長を遂げた。225人以上のコントリビューターが1,500以上のプルリクエストを提出しており、これは同期間におけるRedisの開発ペースの約2倍に相当する。

この数字が示すのは、単一ベンダー主導の開発モデルよりも、オープンでコミュニティ駆動の開発の方が速く、広範囲にイノベーションを起こせるという事実だ。Valkey 9.0はすでにAmazon ElastiCacheでも利用可能になっており、マネージドサービスとしての利便性とOSSの革新性を両立させている。

10億スケールのベクトル検索をSQLで

Aurora PostgreSQLからS3 Vectorsを標準SQLでクエリできるようになったことも見逃せない。具体的には、ベクトル類似度検索の結果とリレーショナルフィルタを1つのSQL文で組み合わせられる。たとえば、「意味的に最も類似した商品を検索し、その中から価格や在庫状況で絞り込む」といったクエリが単一ステートメントで完結する。

これはベクトルデータベース専用のクエリ言語を習得する必要がなくなることを意味する。すでにSQLを使いこなしているエンジニアであれば、追加学習なしでベクトル検索を業務に組み込める。データ基盤の民主化という観点から、非常に実用的なアップデートだ。

この記事のポイント

  • Amazon Bedrock AgentCoreに支払い管理機能が追加され、AIエージェントが自律的にAPIやサービスの利用料を決済できるようになった
  • Agent Toolkit for AWSが発表され、AIコーディングエージェントのエラー削減やトークンコスト低減を実現する
  • WorkSpaces for AI agentsのプレビュー開始により、レガシーGUIアプリケーションの自動化が現実的になった
  • 新型EC2インスタンスはvCPUあたり最大43%の性能向上を達成し、ネットワーク帯域とEBS帯域も強化された
  • Valkeyの成長とS3 VectorsのSQL統合は、データ基盤のオープン化とベクトル検索の民主化が加速していることを示している
AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に

AWS MCP Serverが一般提供開始、AIエージェントのAWS操作を安全・効率的に

AWSは2026年5月6日、AIエージェント向けのマネージドサービス「AWS MCP Server」の一般提供を開始した。AIコーディングアシスタントがAWSの各種サービスを安全に呼び出し、最新ドキュメントを参照し、必要ならサンドボックス内でスクリプトを実行できるようになる。

これまではAIエージェントがAWSを操作しようとしても、訓練データが古く、IAMポリシーが過剰になりがちだった。本サーバーはそうした課題を解決し、本番環境でも使えるレベルのインフラコード生成を後押しする。

本記事ではAWS MCP Serverの機能、GAで追加された新要素、具体的な利用手順、対応ツール、料金までを詳しく解説する。

AWS MCP Serverの概要

AWS MCP Serverの概要

MCP(Model Context Protocol)は、AIエージェントが外部サービスやツールと安全にやり取りするための標準プロトコルだ。AWS MCP Serverはこのプロトコルに準拠したマネージド型のリモートサーバーであり、数個の固定ツールを通じて1万5000を超えるAWS APIへのアクセスを提供する。

AIコーディングアシスタントは多くの場合、訓練データに依存するため、2025年後半以降に登場した新サービス(Amazon S3 VectorsやAurora DSQLなど)を知らない。また、インフラ構築時にAWS CLIを好み、AWS CDKやCloudFormationといったIaCツールを使わない傾向があった。生成されるIAMポリシーも権限が広すぎるなど、デモ用には動いても本番投入は難しい状態だった。

従来のAIエージェントによるAWS操作
訓練データは数カ月前の知識のみ。AWS CLIを直接実行し、過剰なIAM権限を要求。最新サービスを認識できない。
AWS MCP Serverを経由した操作
エージェントはMCPサーバーに問い合わせ。最新ドキュメントを検索し、IAM認証を通じて最適なAPIを実行。サンドボックスでスクリプト処理も可能。
call_aws search_documentation run_script

この仕組みにより、AIエージェントは常に最新の情報と最小権限でAWSリソースを操作できる。ツールの数が少なく固定されているため、モデルのコンテキストウィンドウを圧迫せず、ハルシネーション(誤った回答の生成)も抑えられる。

GAで追加された主な機能

GAで追加された主な機能

プレビュー期間を経て正式提供となったAWS MCP Serverでは、以下の機能が新たに導入されている。

IAMコンテキストキーのサポート

従来はMCPサーバー自体の利用に専用のIAM権限が必要だったが、今回からIAMコンテキストキーに対応した。これにより、通常のIAMポリシーの中で「特定のユーザーは更新系APIを許可、MCPサーバー経由では読み取り専用」といったきめ細かい制御が可能になる。余分な権限管理の手間が減り、セキュリティ設計がシンプルになる。

ドキュメント検索の認証不要化

search_documentationおよびread_documentationツールが、認証なしでも利用できるようになった。これにより、まだAWSアカウントを持っていない段階でも、AIエージェントは最新のAWSドキュメントを参照して設計や調査を行える。

トークン消費の最適化

インタラクションあたりのトークン消費量が削減された。マルチステップのワークフローを伴う複雑なタスクでは、モデルのコンテキストウィンドウがすぐに埋まりがちだったが、今回の改善でより長い会話を維持しやすくなっている。

run_scriptツールとサンドボックス実行

run_scriptツールとサンドボックス実行

GAの大きな目玉がrun_scriptツールの追加だ。AIエージェントは短いPythonスクリプトを記述し、MCPサーバー側のサンドボックス環境で実行させることができる。このサンドボックスは呼び出し元のIAM権限を継承するが、ネットワークアクセスは一切持たない。つまり、エージェントはAWSリソースのデータを処理できるものの、ローカルのファイルシステムやシェルには触れない。

Before run_script(APIを逐次呼び出し)
エージェントが複数のAPIを1つずつ呼び出し、その都度応答を解析。レイテンシが増大し、コンテキストも大量に消費する。
After run_script(サンドボックスで一括処理)
エージェントがPythonコードを生成し、サーバー側で複数APIをチェーン実行。結果は1回の応答で返るため、高速かつコンテキスト効率が良い。
import boto3

# 複数APIを組み合わせた処理を1回のラウンドトリップで

従来、エージェントが複数のAPIを呼び出してデータを結合する場合、1つずつリクエストを送っては応答を待つ必要があり、時間もトークンも浪費していた。run_scriptを使えば、1回のラウンドトリップで一連の処理を完結させられる。これにより、処理速度とコンテキスト効率の両方が大幅に向上する。

Skillsによるベストプラクティスの提供

Skillsによるベストプラクティスの提供

プレビュー版では「Agent SOPs」という形式でガイダンスが提供されていたが、GAではより洗練された「Skills」に移行した。Skillsは、エージェントがよく間違えるタスクに対して、AWSの各サービスチームがメンテナンスする検証済みのベストプラクティスを提供する。

スキルにより生成されるコードの品質が安定し、エラーやトークンの無駄も減る。ツール一覧を短く保ちつつ、必要なガイダンスをピンポイントで渡せるため、エージェントの挙動が予測しやすくなり、無駄な試行錯誤も抑制される。

Skillsライブラリのイメージ
EC2 インスタンス設計の勘所
S3 バケットポリシーの安全設定
CDK プロジェクト構成のテンプレート
Lambda 関数の権限制御
エージェントはタスクに応じて最適なスキルを参照し、検証済みのコードや設定を生成する。

エンタープライズの現場では、開発者の数だけ書き方がバラバラになりがちだが、Skillsによってサービスチーム公認のパターンがチーム全体に自然と浸透する。結果として、セキュリティレビューの工数も削減できるだろう。

セキュリティと監査の仕組み

セキュリティと監査の仕組み

AWS MCP Serverは、ユーザーが直接操作する時とAIエージェント経由の操作を明確に区別できる設計になっている。IAMポリシーやSCP(Service Control Policies)を使って、特定のユーザーには全操作を許可しつつ、MCPサーバーには読み取り専用のみ許可する、といった制御が可能だ。

さらに、AWS-MCP名前空間のAmazon CloudWatchメトリクスが提供され、MCPサーバー経由のAPIコールと人間による直接のAPIコールを分離して監視できる。AWS CloudTrailもすべてのAPI呼び出しを記録するため、コンプライアンスチームが求める監査証跡を完全な形で確保できる。

監視ダッシュボードの概念
人間の操作
1,245 calls
MCPサーバー経由
867 calls
CloudWatchメトリクスで分離表示。CloudTrailには全ログが残る。

このように、AIエージェントが安全にインフラを操作できる環境が整ったことで、これまで人間の開発者しか触れなかった本番環境へのAI活用も現実味を帯びてきた。

利用方法と対応ツール

利用方法と対応ツール

AWS MCP Serverは、MCPに対応するあらゆるAIコーディングツールから利用できる。Claude Code、Cursor、Kiro、OpenAI Codexなど、主要なアシスタントはすでにサポートしている。

セットアップは非常にシンプルだ。AWS MCP ServerはIAM SigV4認証を利用するが、多くのMCPクライアントはOAuth 2.1のみに対応している。そのため、オープンソースの「MCP Proxy for AWS」を使ってIAM認証をOAuthにブリッジする。具体的には以下のようなコマンドで設定する。


curl -LsSf https://astral.sh/uv/install.sh | sh
claude mcp add-json aws-mcp --scope user \
   '{"command":"uvx","args":["mcp-proxy-for-aws@latest","https://aws-mcp.us-east-1.api.aws/mcp","--metadata","AWS_REGION=us-west-2"]}'
設定後の動作確認イメージ
AIアシスタント上で/mcpコマンドを実行すると、AWS MCP Serverが利用可能なツール一覧が表示される。
あとは「S3にベクトルデータを保存する方法は?」と尋ねるだけで、エージェントがsearch_documentationツールを呼び出し、最新のS3 Vectorsの情報をもとに回答を生成する。

プロキシはローカルマシン上で動作し、MCPサーバーのエンドポイントとしてhttps://aws-mcp.us-east-1.api.aws/mcp(米国東部)または欧州(フランクフルト)のリージョナルエンドポイントを指定する。APIコール自体は他の全リージョンに対しても実行可能だ。

料金と提供リージョン

料金と提供リージョン

AWS MCP Server自体に追加料金は発生しない。支払うのは、AIエージェントが操作した結果として作成されたAWSリソースの利用料と、データ転送料金のみだ。このため、まずは試験的に導入し、効果を検証しやすい。

現在の提供リージョンは米国東部(バージニア北部)と欧州(フランクフルト)の2拠点。今後、他のリージョンにも順次拡大される見込みだ。

AWS MCP Serverはすでに多くのAIコーディングアシスタントで利用可能であり、AWSドキュメントの最新ページからクイックスタートガイドを参照できる。

この記事のポイント

  • AWSがAIエージェント向けのマネージドMCPサーバーを一般提供開始
  • call_aws、search_documentation、run_scriptの3ツールでAWSを安全に操作
  • run_scriptはサーバー側サンドボックスでスクリプトを一括実行し高速化
  • SkillsによりAWSチーム公認のベストプラクティスをコード生成に活用可能
  • IAMとCloudTrail/CloudWatchで人間の操作とAIの操作を明確に分離監査
  • サーバー利用料は無料、リソース使用量のみの課金。米国東部と欧州で提供開始
Amazon WorkSpacesがAIエージェント専用デスクトップを提供開始

Amazon WorkSpacesがAIエージェント専用デスクトップを提供開始

企業がAIエージェントを本格導入しようとすると、大きな壁に突き当たる。基幹業務を支える既存のデスクトップアプリケーションやレガシーシステムは、最新のAPIを備えていないことがほとんどだ。2024年のGartnerレポートによれば、75%の組織がモダンなAPIを持たないレガシーアプリを運用しており、Fortune 500社の71%は十分なプログラムアクセス手段のないメインフレーム上で重要プロセスを動かしている。

AWSはこの課題に対して、新しいアプローチを発表した。2026年5月5日、Amazon WorkSpacesがAIエージェントに対して安全なデスクトップ環境を提供する機能をプレビュー公開した。これにより、アプリケーションの改修やAPIの新規開発なしで、AIエージェントが既存のデスクトップアプリケーションを人間と同じように操作できるようになる。

レガシーアプリケーションの課題とAI導入の壁

レガシーアプリケーションの課題とAI導入の壁
従来のアプローチ(Before)
AIエージェントAPI接続が必要レガシーアプリ(直接操作不可)アプリのモダナイズが必須
※ 多くの企業ではコスト・リスクが高く、AI導入の足かせに
WorkSpacesの新しいアプローチ(After)
AIエージェントWorkSpaces仮想デスクトップレガシーアプリをクリック・入力・スクロールで操作
※ アプリケーション側の改修は一切不要。既存のセキュリティポリシーも維持

従来は、AIエージェントが業務システムと連携するには、アプリケーション側にAPIを実装するか、RPAによる擬似的な操作を行うしかなかった。いずれも大がかりな作業とメンテナンスを伴い、特に規制産業では監査やセキュリティ面でハードルが高かった。WorkSpacesの新機能は、仮想デスクトップという“もう一つの画面”をAIエージェントに渡すことで、この問題を一気に解消する。

WorkSpacesがAIエージェントに提供するもの

WorkSpacesがAIエージェントに提供するもの

この新機能の核は、人間用に管理されてきたWorkSpaces環境を、AIエージェントにも安全に割り当てられるようにした点にある。エージェントはAWS Identity and Access Management(IAM)で認証され、WorkSpacesへ接続する。操作はすべてAWS CloudTrailとAmazon CloudWatchで監査ログが残り、既存のセキュリティ制御やコンプライアンスポリシーがそのまま適用される。

また、業界標準のModel Context Protocol(MCP)に対応しているため、LangChainやCrewAI、Strands Agentsなど、さまざまなAIエージェントフレームワークから利用できる。特定のSDKに縛られない設計は、企業の既存AI基盤に組み込みやすい。

AWSのブログ記事では、Nuvens ConsultingのディレクターChris Noon氏が次のようにコメントしている。「WorkSpacesは、クライアントが従業員に提供しているのと同じ安全でガバナンスの効いたデスクトップ環境を、AIエージェントにも提供できる。カスタムAPI統合は不要で、完全な監査証跡とエンタープライズグレードの隔離が最初から組み込まれている。規制の厳しい業界では、これは単なる追加機能ではなく、前提条件だ」

AIエージェント用WorkSpacesの設定手順

AIエージェント用WorkSpacesの設定手順

AWS Management Consoleから設定を開始する。WorkSpacesコンソールで「スタックの作成」を選択し、スタック名やフリートの関連付け、VPCエンドポイントなどの基本情報を入力する。作成ウィザードのステップ3では、AIエージェント用の新しいセクションが追加されている点がポイントだ。

ここでは「AIエージェントの追加」オプションを選択する。これにより、人間用のスタックとは別に、エージェント専用のIDと権限でデスクトップにアクセスできるようになる。続いてエージェント機能を有効化する設定へ進む。「コンピューター入力」はマウスクリックやキーボード入力、スクロール操作を許可し、「コンピュータービジョン」はエージェントがデスクトップのスクリーンショットを取得できるようにする。これはエージェントが画面を「見る」仕組みだ。さらにスクリーンショットの保存先を指定し、監査やデバッグに備える。

画面レイアウトの設定では、解像度や画像フォーマットを選ぶ。UI要素が密集した複雑なアプリケーションでは高解像度が有効だが、ターミナル風のシステムであれば720pで十分だ。これらの設定を済ませると、WorkSpacesがマネージドMCPエンドポイントを生成する。あとはAIエージェントのフレームワーク側で、このエンドポイントとIAM認証情報を指定するだけで接続が完了する。

実際の動作とユースケース

実際の動作とユースケース

実際のデモでは、AWSがStrands Agent SDKとAmazon Bedrockを組み合わせて構築したエージェントが、架空の薬局システム上で処方箋の再発行処理を一通り実行している。患者レコードの検索から薬剤の選択、注文、再発行確認まで、すべてAPIなしで完結する。アプリケーション側はエージェントが操作していることを一切意識しておらず、ソフトウェアの改修も再構築も行われていない。

このようなアプローチは、金融機関の勘定系システムや医療機関の電子カルテ、物流システムの倉庫管理アプリなど、何十年も使い続けられている業務アプリケーションにすぐに適用できる。モダナイズに踏み切れずAI導入を断念していた企業にとって、有力な選択肢になるだろう。

今後の展望と利用可能リージョン

今後の展望と利用可能リージョン

今回の機能はパブリックプレビューとして、米国東部(バージニア北部、オハイオ)、米国西部(オレゴン)、カナダ(中部)、欧州(フランクフルト、アイルランド、パリ、ロンドン)、アジアパシフィック(東京、ムンバイ、シドニー、ソウル、シンガポール)の各リージョンで追加料金なしで利用できる。

エージェントが人間と同じデスクトップを共有するという発想は、レガシーシステムとAIの架け橋として大きな可能性を秘めている。AWSのブログでは、GitHubリポジトリにサンプルコードが公開されており、すぐに試せる環境が整っている。今後は、より細かな権限制御やマルチエージェント対応など、エンタープライズ利用を加速させる機能拡張が期待される。

この記事のポイント

  • Amazon WorkSpacesがAIエージェントに仮想デスクトップを提供する機能をパブリックプレビュー開始
  • レガシーアプリのAPI改修不要で、AIエージェントがクリックや入力、スクリーンショット取得で操作可能
  • IAMによる認証とCloudTrailの監査証跡で、既存のセキュリティ・コンプライアンスを維持
  • MCP対応でLangChainやCrewAIなど主要フレームワークと接続可能
  • 東京リージョンを含む多数のリージョンで追加費用なしで試用可能