本日の主なトピック #
- Amazon Bedrock AgentCore Runtime がステートフルな MCP サーバー機能をサポート
- Amazon Connect でマネージャー向けのエージェント・コーチング・ワークフローを提供開始
- Amazon Bedrock が First Token Latency と Quota 消費のモニタリングに対応
- AWS Graviton4 搭載の EC2 C8gd/M8gd インスタンスの利用可能リージョンが拡大
- AWS Backup が RDS マルチ AZ クラスターのサポートを大阪を含む 17 リージョンに拡大
¥3,520 Amazonで見る
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本(ソフトカバー) – 2025/7/11
Amazon Bedrock AgentCore Runtime がステートフルな MCP サーバー機能をサポート #
投稿日: 2026年03月10日
何ができるようになったのか #
Amazon Bedrock AgentCore Runtime において、Model Context Protocol (MCP) のステートフルなサーバー機能(エポック、サンプリング、進捗通知)が利用可能になりました。これにより、開発者は、ツール実行中にユーザーに入力を求めたり、クライアントに LLM 生成コンテンツを要求したり、長時間の処理に対してリアルタイムで進捗状況を通知したりする MCP サーバーを構築できます。
何が嬉しいのか #
これまでの単純なリクエスト・レスポンス型を超えた、より複雑でインタラクティブなエージェントワークフローを実現できます。各ユーザーセッションは分離された専用の microVM で実行され、Mcp-Session-Id ヘッダーを通じてセッションコンテキストが維持されるため、ユーザーの好みを深掘りする対話や、航空券の検索などの進捗状況を可視化することが可能になります。
これまでとどう変わるのか #
- これまで: 2025年10月に一般提供が開始された際の AgentCore Runtime では、MCP サーバーの基本的なリソース、プロンプト、ツールのサポートに限定されていました。
- これから: エポック( elicitation )、サンプリング( sampling )、進捗通知( progress notifications )などのステートフルな機能が統合され、複数ターンにわたる高度な対話型エージェントの構築が可能になります。
具体的なユースケース #
- ユーザーの好みを段階的に聞き出してパーソナライズされた提案を行うエージェント
- クライアント側に LLM を使ったテキスト生成を依頼し、その結果を受け取って処理を続行するワークフロー
- 予約処理やデータ検索など、時間のかかる操作の進捗をリアルタイムでユーザーに通知する機能
MCPは「Model Context Protocol」の略です。 Anthropicが公開した、LLMアプリケーションがデータソースやツールとやり取りするためのオープンスタンダードです。 主な特徴は以下の通りです。
- ローカルデータやサードパーティツールとのシームレスな統合
- 複数のLLMプロバイダー間での相互運用性
Amazon Bedrock が First Token Latency と Quota 消費のオブザーバビリティをサポート #
投稿日: 2026年03月10日
何ができるようになったのか #
Amazon Bedrock において、新たに2つの CloudWatch メトリクス(TimeToFirstToken と EstimatedTPMQuotaUsage)がサポートされました。これにより、推論のパフォーマンス向上とクォータ消費の可視化が容易になります。
何が嬉しいのか #
TimeToFirstToken (TTFT) を使用することで、ストリーミング API においてリクエスト送信から最初のトークン受信までの遅延をモニタリングし、クライアント側での実装なしで CloudWatch アラームを設定できます。また、EstimatedTPMQuotaUsage により、1分あたりのトークン消費量(TPM)を把握し、制限に達する前に事前にアラームを通知したり、適切なクォータ増枠のタイミングを判断したりできます。
これまでとどう変わるのか #
- これまで: 推論の全体的な遅延やクォータの正確な消費状況をリアルタイムで把握するためには、クライアント側でのログ記録や集計といった独自の実装が必要な場合がありました。
- これから: 標準の CloudWatch メトリクスとして提供されるため、追加の実装なしで Bedrock の全商用リージョンにおいてパフォーマンスと制限の管理が可能になります。
具体的なユースケース #
- チャットアプリケーションにおけるレスポンスの「体感速度」を監視するための TTFT アラーム設定
- 複数のモデルを利用する大規模なワークロードにおいて、クォータ不足によるレート制限を回避するための事前通知
- さまざまな推論プロファイルを通じたクォータ消費パターンの追跡
Amazon CloudWatch Database Insights のオンデマンド分析が AWS GovCloud リージョンで利用可能に #
投稿日: 2026年03月11日
何ができるようになったのか #
Amazon CloudWatch Database Insights のオンデマンド分析機能が、AWS GovCloud (US-East) および AWS GovCloud (US-West) リージョンでも利用可能になりました。これにより、機密性の高いデータを扱うガバメントワークロードにおいても、機械学習を用いたデータベースパフォーマンスの診断と最適化が可能になります。
何が嬉しいのか #
データベース管理者や開発者は、過去の任意の期間のパフォーマンスデータを自動的に分析し、機械学習モデルによって特定されたボトルネックや異常の特定、および具体的な修復アドバイスを受けることができます。これにより、従来数時間かかっていた問題解決までの平均時間(MTTD)を数分に短縮できます。
これまでとどう変わるのか #
- これまで: GovCloud リージョンのユーザーは、データベースのパフォーマンスデータの相関分析や根本原因の調査を手動で行う必要があり、深いデータベースの専門知識と多大な時間を要していました。
- これから: 自動化されたインテリジェンスにより、通常のベースラインとの比較が自動で行われ、異常の特定から修正手順の提示までが数クリックで完結します。
具体的なユースケース #
- 突発的なパフォーマンス劣化が発生した際、過去の正常時と比較して原因を迅速に特定する
- 機械学習による推奨事項に基づき、RDS または Aurora インスタンスの最適なチューニングを行う
- 重要な公共サービス向けのデータベースにおける診断プロセスの自動化と効率化
Amazon Connect で送信元の「From」メールアドレスの選択が可能に #
投稿日: 2026年03月11日
何ができるようになったのか #
Amazon Connect において、インバウンドメールへの返信や新しいアウトバウンドメッセージを送信する際に、複数の「From(送信元)」メールアドレスから適切なものを選択できるようになりました。管理者はキューごとに複数の送信者アドレスを設定でき、エージェントは業務に応じて適切なブランドやビジネスアイデンティティを選択できます。
何が嬉しいのか #
一つの Amazon Connect インスタンスで複数のブランドや事業部門をサポートしているコンタクトセンターにおいて、顧客に対して正しい送信元名を表示し続けることが可能になります。これにより、顧客の信頼性を高め、ブランドごとの一貫したコミュニケーションを実現できます。
これまでとどう変わるのか #
- これまで: 送信元アドレスの柔軟な切り替えが難しく、複数のブランドを運営している場合には、送信元のブランド名と実際の業務内容が不一致になる懸念がありました。
- これから: エージェントがキューの属性に合わせて送信元アドレスを検索・選択できるため、マルチブランド環境でも正確かつ効率的なメール対応が可能になります。
具体的なユースケース #
- グループ会社共通のコンタクトセンターで、問い合わせ内容に応じて A 社と B 社のメールアドレスを使い分ける
- サポートと営業など、同一のキューであっても役割に応じた送信元アドレスから連絡を行う
- 顧客が問い合わせたブランド名を維持したまま、フォローアップメールを送信する
Amazon Connect のケースデータが分析データレイクで提供開始 #
投稿日: 2026年03月11日
何ができるようになったのか #
Amazon Connect Cases(ケース管理機能)のデータが、Amazon Connect の分析データレイクで利用可能になりました。これにより、複雑なデータパイプラインを自前で構築・維持することなく、Amazon Athena や Amazon QuickSight を使用して、ケースに関するレポートやインサイトを容易に生成できます。
何が嬉しいのか #
ケースデータと他の Amazon Connect 分析データ(通話履歴やコンタクト属性など)を組み合わせて分析できるため、ケースの種類ごとの量、エージェントのシフトをまたいだケース対応状況、ケースごとの顧客感情などのトレンドを迅速に把握できます。データ分析のセットアップ時間が大幅に短縮され、運用改善に集中できるようになります。
これまでとどう変わるのか #
- これまで: ケースの詳細データを分析に利用するためには、API を介したデータ抽出や、独自のデータパイプラインを構築してデータレイクに転送する必要がありました。
- これから: Amazon Connect 側でデータレイクへの提供が自動化されるため、標準的な分析ツールから即座にアクセスして可視化できるようになります。
具体的なユースケース #
- QuickSight を使用して、特定の期間におけるケースのクローズ率や平均対応時間をダッシュボード化する
- Athena でクエリを実行し、顧客の感情分析(センチメント)とケースの解決時間の相関を調査する
- エージェントの配置を最適化するために、時間帯ごとのケース発生ボリュームを分析する
Amazon Connect でマネージャー向けのエージェント・コーチング・ワークフローを提供開始 #
投稿日: 2026年03月11日
何ができるようになったのか #
Amazon Connect において、コンタクトセンターのマネージャーがエージェントに対してタイムリーで的を絞ったフィードバックを Connect UI 内で直接提供できる、統合されたコーチング・ワークフローが導入されました。マネージャーは評価スコアカードから改善の機会を特定し、実際の顧客とのやり取り例を紐付けたコーチングプランを即座に作成できます。
何が嬉しいのか #
コーチングセッション後、エージェントはフィードバックを確認し、理解した内容や次のステップをメモとして残すことができます。マネージャーとエージェントの両方が単一のページですべてのコーチング履歴にアクセスできるため、体系的な進捗管理が可能になります。これにより、コーチングの遅れをなくし、エージェントの能力開発プロセスにおける責任を明確化することで、コンタクトセンター全体のパフォーマンス向上を加速させます。
これまでとどう変わるのか #
- これまで: コーチングのプロセスは外部ツールや手動の記録に頼ることが多く、実際の通話記録や評価結果とコーチング内容が切り離されてしまい、フィードバックの提供までに時間がかかることがありました。
- これから: 評価からコーチングプランの作成、エージェントによる確認までが Amazon Connect の UI 上で完結するため、具体的かつ迅速なパフォーマンス改善のサイクルを回すことができます。
具体的なユースケース #
- 顧客への共感表現が不足していた通話を特定し、適切なフレーズの例を提示しながらコーチングを行う
- 特定の期間におけるエージェントのスキル向上の軌跡をコーチング履歴から可視化する
- 新人エージェントに対して、実際の成功事例を共有しながら段階的な改善目標を設定する
AWS Graviton4 搭載の EC2 C8gd および M8gd インスタンスが利用可能リージョンを拡大 #
投稿日: 2026年03月11日
何ができるようになったのか #
AWS Graviton4 プロセッサを搭載し、最大 11.4 TB のローカル NVMe SSD ストレージを備えた Amazon EC2 C8gd および M8gd インスタンスの利用可能リージョンが拡大しました。C8gd インスタンスは南米(サンパウロ)、M8gd インスタンスは欧州(アイルランド)で新たに利用可能になりました。
何が嬉しいのか #
Graviton4 プロセッサは、前世代の Graviton3 と比較して最大 30% のパフォーマンス向上を実現しています。特に I/O 集約型のデータベースワークロードでは最大 40%、リアルタイムデータ分析のクエリ結果では最大 20% の高速化が期待できます。また、AWS Nitro System により、ネットワークと EBS の帯域幅配分を柔軟に調整できる「Instance Bandwidth Configuration」もサポートされています。
これまでとどう変わるのか #
- これまで: 最新の Graviton4 搭載ストレージ最適化インスタンス(C8gd/M8gd)は、一部の主要リージョンに限定されていました。
- これから: 南米や欧州の追加リージョンでも利用可能になったため、低レイテンシなローカルストレージを必要とするアプリケーションを、より幅広い地域で Graviton4 の高いコストパフォーマンスで実行できるようになります。
具体的なユースケース #
- 南米リージョンにおける I/O 集約型の NoSQL データベースや分散ファイルシステムの実行
- 欧州リージョンでの低レイテンシなスクラッチスペースを必要とするリアルタイムデータ分析
- 高速なローカルストレージを活用したビデオエンコーディングやバッチ処理ワークロード
第4世代 Intel Xeon 搭載の EC2 C8id インスタンスが欧州(スペイン)で利用可能に #
投稿日: 2026年03月11日
何ができるようになったのか #
カスタムの Intel Xeon 6 プロセッサ(第4世代 Intel Xeon Scalable プロセッサ)を搭載した Amazon EC2 C8id インスタンスが、欧州(スペイン)リージョンで利用可能になりました。最大 384 vCPU、768 GiB のメモリ、および 22.8 TB の NVMe SSD ストレージを提供します。
何が嬉しいのか #
前世代の C6id インスタンスと比較して、最大 43% のパフォーマンス向上と 3.3 倍のメモリ帯域幅を実現しています。I/O 集約型のデータベースワークロードでは最大 46%、リアルタイム分析クエリでは最大 30% の高速化を達成しています。また、ネットワークと EBS の帯域幅を 25% の範囲で柔軟に割り当てられる機能も備えています。
これまでとどう変わるのか #
- これまで: スペインリージョンでは、最新世代の Intel プロセッサと大容量ローカル SSD を組み合わせたコンピューティング最適化インスタンスの選択肢が限られていました。
- これから: 最新の C8id インスタンスが導入されたことで、ハイパフォーマンスな Web サーバー、ビデオエンコーディング、ゲームサーバーなどのワークロードをより高性能なインフラで実行可能になります。
具体的なユースケース #
- スペインリージョンを拠点とするハイパフォーマンスな Web サーバーやアドサーバーの運用
- 大規模な分散分析やバッチ処理におけるローカルストレージの活用
- 低レイテンシな SSD アクセスが重要なビデオ編集やトランスコーディング業務
Amazon EC2 ハイメモリ U7i インスタンスが追加リージョンで利用可能に #
投稿日: 2026年03月11日
何ができるようになったのか #
8TB または 12TB のメモリを搭載した Amazon EC2 ハイメモリ U7i インスタンスの提供リージョンが拡大しました。8TB モデル(u7i-8tb.112xlarge)はアジアパシフィック(ハイデラバード)、12TB モデル(u7i-12tb.224xlarge)は欧州(スペイン)で新たに利用可能になりました。
何が嬉しいのか #
U7i インスタンスは第4世代 Intel Xeon Scalable プロセッサ(Sapphire Rapids)を搭載し、高速な DDR5 メモリを提供します。最大 100 Gbps の EBS 帯域幅とネットワーク帯域幅をサポートしており、大規模なインメモリデータベースの高速なデータロードやバックアップが可能です。
これまでとどう変わるのか #
- これまで: 12TB といった超大容量メモリを必要とする U7i インスタンスは、利用できるリージョンが非常に限られていました。
- これから: ハイデラバードやスペインなどのリージョンでも利用可能になったため、現地のデータレジデンシー要件を満たしつつ、SAP HANA や Oracle などのミッションクリティカルな大規模インメモリワークロードを実行できるようになります。
具体的なユースケース #
- スペインリージョンにおける SAP HANA の大規模な本番環境の構築と運用
- アジアパシフィック(ハイデラバード)での Oracle や SQL Server のインメモリ機能の活用
- 急成長するデータ環境におけるトランザクション処理のスケーリング
Amazon EC2 R7gd インスタンスが南米(サンパウロ)リージョンで利用可能に #
投稿日: 2026年03月11日
何ができるようになったのか #
AWS Graviton3 プロセッサを搭載し、最大 3.8 TB のローカル NVMe SSD ストレージを備えた Amazon EC2 R7gd インスタンスが、南米(サンパウロ)リージョンで利用可能になりました。
何が嬉しいのか #
R7gd インスタンスは、オープンソースデータベースやインメモリキャッシュ、リアルタイムのビッグデータ分析など、メモリ集約型かつ高速なローカルストレージを必要とするワークロードに最適です。一時的なスクラッチスペースやキャッシュとして利用可能な低レイテンシ・高スループットなローカル SSD を提供します。
これまでとどう変わるのか #
- これまで: サンパウロリージョンにおいて、Graviton3 プロセッサの効率性とローカル SSD のパフォーマンスを両立させたメモリ最適化インスタンスの選択肢が不足していました。
- これから: R7gd が導入されたことで、南米のユーザーも Graviton3 による高いコストパフォーマンスと DDR5 メモリによる高速なデータアクセスを享受できるようになります。
具体的なユースケース #
- Redis や Memcached などのインメモリキャッシュにおける一時データ保存
- 分散分析フレームワークにおける中間データ(シャッフルデータ)の高速な読み書き
- 南米リージョンにおけるメモリ負荷の高い Web アプリケーションのバックエンドサーバー
AWS Backup が Amazon RDS マルチ AZ クラスターのサポートを 17 リージョンに拡大 #
投稿日: 2026年03月11日
何ができるようになったのか #
AWS Backup による Amazon RDS マルチ AZ クラスターのデータ保護機能が、新たに 17 の AWS リージョン(ムンバイ、大阪、ソウル、香港、ロンドン、パリ、サンパウロなど)で利用可能になりました。これにより、自動化されたライフサイクル管理や不変バックアップ(AWS Backup Vault Lock)がこれらのリージョンでも適用可能になります。
何が嬉しいのか #
RDS マルチ AZ クラスターを利用しているユーザーは、既存のバックアップ計画にクラスターを追加するだけで、組織全体のコンプライアンス要件に合わせたデータ保護を一元管理できるようになります。Vault Lock を併用することで、バックアップの削除や変更を制限し、ランサムウェア対策やデータ改ざん防止を強化できます。
これまでとどう変わるのか #
- これまで: RDS マルチ AZ クラスターに対する AWS Backup の高度な機能は、利用可能なリージョンが限定的でした。
- これから: 大阪リージョンを含む主要な 17 リージョンに拡大されたことで、より多くのグローバルなワークロードにおいて、RDS マルチ AZ クラスターの耐障害性と AWS Backup の管理容易性を同時に享受できるようになります。
具体的なユースケース #
- 大阪リージョンの RDS マルチ AZ クラスターにおいて、コンプライアンスに基づいた長期保存ポリシーを自動適用する
- Vault Lock を使用して、ミッションクリティカルなデータベースのバックアップを保護し、誤削除や不正な変更を防ぐ
- 複数のリージョンにまたがるデータベースのバックアップ運用を AWS Backup で統合管理する