本日の主なトピック #
- Amazon Bedrock AgentCore の強化: On-Behalf-Of トークン交換によるシームレスなユーザー代行アクセス、エージェント性能の自動最適化推奨、および SAP ERP とのセキュアな連携を可能にする AWS for SAP MCP サーバーが一般提供されました。
- インフラ運用の利便性向上: Amazon EKS クラスターへの CloudShell 経由のワンクリックアクセスや、CloudFront VPC オリジンでの WebSockets サポートにより、プライベートサブネット内のリソースへのリアルタイムアクセスが容易になりました。
- AI/ML 開発と計算リソースの最適化: AWS Neuron SDK での AI エージェントによるコーディング支援（Neuron Agentic Development）や、EKS での EFA デバイスの動的リソース割り当て (DRA) サポートにより、Trainium/Inferentia を活用した開発効率と通信パフォーマンスが向上します。
- セキュリティとコンプライアンスの強化: IAM Roles Anywhere の VPC エンドポイントポリシーによる CreateSession API の制御や、AWS Payment Cryptography による物理（紙ベース）キー交換のサポートなど、厳格なガバナンス要件への対応が拡充されました。
- データベースとBIの拡張: RDS for SQL Server における大容量ストレージ構成でのアカウント間共有やリードレプリカ対応、および Tableau/Power BI から QuickSight への移行を加速する AI エージェントが提供開始されました。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Amazon Bedrock AgentCore Identity が On-Behalf-Of (OBO) トークン交換をサポート #
投稿日: 2026年04月30日
何ができるようになったのか #
Amazon Bedrock AgentCore Identity において、On-Behalf-Of (OBO) トークン交換がサポートされました。これにより、開発者は認証済みユーザーに代わって、保護されたリソースに安全にアクセスするエージェントを構築できるようになります。ユーザーは複数のリソースに対して個別に同意フローを完了する必要がなくなります。
何が嬉しいのか #
従来、ユーザーの代わりに動作するエージェントを構築する場合、保護されたリソースごとに個別の同意フローを管理する必要があり、ユーザーの利便性を損なうだけでなく、開発の複雑さも増していました。OBO トークン交換を使用することで、元のユーザー ID とエージェント ID の両方を保持した、権限を絞り込んだ新しいアクセストークンを取得できます。これにより、ユーザーに追加の同意を求めることなく、ジャストインタイムかつ最小権限でのアクセスが可能になります。
これまでとどう変わるのか #
- これまで: エージェントが複数の保護されたリソース（APIなど）にアクセスする場合、リソースごとに個別の同意フローが必要で、ユーザー体験と実装の両面で負荷が高かった。
- これから: OBO トークン交換により、1回の認証から複数のリソースへのアクセスを仲介できるようになり、ユーザーの手間を省きつつ、セキュリティ（最小権限）を維持できる。
具体的なユースケース #
- 統合型AIアシスタント: ユーザーの代わりにメールの取得、カレンダーの更新、ドキュメントの検索などを、追加のログインなしでシームレスに行うエージェント。
- マルチサービス連携: 認証されたユーザーの権限に基づき、バックエンドの複数のマイクロサービスを呼び出す必要があるエンタープライズ向けエージェント。
Amazon CloudFront が VPC オリジンでの WebSockets サポートを発表 #
投稿日: 2026年05月01日
何ができるようになったのか #
Amazon CloudFront において、VPC オリジン（Virtual Private Cloud 内のリソース）を通じた WebSockets 通信がサポートされました。これにより、完全にプライベートサブネット内にホストされたリアルタイムアプリケーションの単一のエントリポイントとして CloudFront を利用できるようになります。
何が嬉しいのか #
チャットプラットフォーム、共同編集ツール、ライブダッシュボード、IoT デバイス管理システムなど、クライアントとサーバー間の持続的かつ双方向の接続を必要とするアプリケーションを、パブリックサブネットに公開することなく CloudFront 経由で提供できます。Application Load Balancer (ALB)、Network Load Balancer (NLB)、および EC2 インスタンスをプライベートサブネットに配置したまま、CloudFront を通じて安全にアクセスさせることが可能です。
これまでとどう変わるのか #
- これまで: WebSockets を使用するリアルタイムアプリケーションを実行する場合、オリジンをパブリックサブネットに保持し、ACL（アクセス制御リスト）などを用いてアクセスを制限する必要があった。
- これから: オリジンをプライベートサブネットに配置したまま、CloudFront を唯一の「フロントドア」として HTTP トラフィックと WebSockets 接続の両方を処理できる。これにより、攻撃対象領域を減らし、セキュリティ管理を簡素化できる。
具体的なユースケース #
- 企業内チャットシステム: 社内ネットワーク（VPC 内）に閉じた状態で運用しつつ、CloudFront の DDoS 保護やグローバル配信の恩恵を受けながらリアルタイム通信を実現する。
- リアルタイム監視ダッシュボード: プライベートなバックエンドサーバーからのライブデータを、セキュアな双方向接続を通じてフロントエンドに配信する。
Amazon ECS マネージド型インスタンスが NVIDIA GPU メトリクスをサポート #
投稿日: 2026年04月30日
何ができるようになったのか #
Amazon ECS マネージド型インスタンス（Amazon ECS Managed Instances）で実行されるコンテナ化されたワークロードにおいて、NVIDIA GPU メトリクスが利用可能になりました。これらのメトリクスは、Amazon CloudWatch Container Insights の「拡張された可観測性（enhanced observability）」を通じて提供されます。
何が嬉しいのか #
GPU を利用するワークロード（AI/ML のトレーニングや推論など）において、GPU の稼働状況やパフォーマンス、ハードウェアの健全性を CloudWatch で直接監視できるようになります。GPU デバイスレベルでの詳細な可視性が得られるため、パフォーマンスの問題のトラブルシューティング、GPU キャパシティの適正化、問題の早期検出が容易になります。
これまでとどう変わるのか #
- これまで: Amazon ECS のマネージド型インスタンス上で GPU ワークロードを実行する際、GPU 特有のメトリクス（利用率、メモリ使用量、温度など）を標準的に取得・監視する手段が限定的だった。
- これから: Container Insights を有効にするだけで、GPU のキャパシティ、利用率、メモリ、ハードウェアの健全性、温度条件などをグラフィカルに監視できる。
具体的なユースケース #
- AI/ML モデルの推論監視: 推論サービスを実行している GPU のメモリ使用量や利用率を監視し、負荷に応じたオートスケーリングやリソースの最適化を行う。
- パフォーマンス・デバッグ: GPU を使用するアプリケーションのボトルネックを特定するために、デバイスレベルでの利用統計を分析する。
Amazon EKS が CloudShell 経由のワンクリッククラスターアクセスをサポート #
投稿日: 2026年04月30日
何ができるようになったのか #
Amazon EKS において、AWS マネジメントコンソールから直接 AWS CloudShell を起動し、ワンクリックでクラスターにアクセスできるようになりました。これにより、ローカル環境に kubectl や AWS CLI、kubeconfig ファイルをインストール・設定することなく、ブラウザ上で即座にクラスター操作を開始できます。
何が嬉しいのか #
開発者や運用担当者は、環境構築の手間をかけずにクラスターにアクセスできます。コンソール上のクラスター画面から「接続（Connect）」を選択するだけで、kubectl が事前設定された CloudShell セッションが立ち上がります。パブリックおよびプライベートな API サーバーエンドポイントの両方をサポートしており、トラブルシューティングやリソース管理を迅速に行うことができます。
これまでとどう変わるのか #
- これまで: クラスターを操作するには、ローカルマシンにツールをインストールし、IAM 権限に基づいた
kubeconfigの更新（aws eks update-kubeconfigなど）を行う必要があった。 - これから: マネジメントコンソールから直接、事前設定済みのシェル環境を起動してコマンドを実行できる。
具体的なユースケース #
- 外出先や制限のある環境からの操作: 開発ツールがインストールされていない端末から、緊急のトラブルシューティングやワークロードの確認を行う。
- 迅速な動作確認: 新しく作成したクラスターやデプロイしたリソースの状態を、設定作業なしですぐに確認する。
Amazon Quick が Microsoft Excel、PowerPoint 拡張機能を追加、Word 拡張機能を更新 (プレビュー) #
投稿日: 2026年04月30日
何ができるようになったのか #
Amazon Quick（生成 AI アシスタント）において、Microsoft 365（Excel、PowerPoint、Word）向けの新しい拡張機能およびアップグレードされた拡張機能がプレビュー公開されました。これにより、Amazon Quick がユーザーの Microsoft 365 環境内で直接タスクを実行できるようになります。
何が嬉しいのか #
AI を使用して、ドキュメントの校閲、財務モデルの構築、プレゼン資料の作成といった複雑なローカルタスクを効率化できます。
- Excel: 複雑なスプレッドシート分析、ピボットテーブルやチャートの作成、データのインポートとクリーニングを支援。
- PowerPoint: 組織で定義されたテンプレートを使用して、Quick のデータからプレゼンテーションを作成・洗練。
- Word: フォーマット済みのドキュメント生成、変更履歴を有効にした大幅な編集、コメントへのレビュー参加が可能。
これまでとどう変わるのか #
- これまで: AI アシスタントで生成した内容を、手動で Office 製品にコピー＆ペーストしたり、書式を整えたりする必要があった。
- これから: Office 製品内のアドインとして Quick を呼び出し、データのクリーニングやドキュメント作成を直接指示できる。
具体的なユースケース #
- 財務チーム: 必要な内容を説明するだけで、複雑な財務モデルを Excel 上で構築する。
- 営業チーム: CRM データから自動的に情報を取得し、Word で提案書のドラフトを作成する。
- マーケティングチーム: 手動のフォーマット作業なしで、ブランドに合わせたプレゼン資料を PowerPoint で作成する。
AWS Neuron SDK が Trainium での NKI カーネル開発向けに Neuron Agentic Development を提供開始 #
投稿日: 2026年04月30日
何ができるようになったのか #
AWS Neuron SDK において、「Neuron Agentic Development」機能が発表されました。これは、AWS Trainium および AWS Inferentia 上での開発を加速させるための、AI コーディングアシスタント向けのオープンソースのエージェントとスキルのコレクションです。初期リリースでは、Neuron Kernel Interface (NKI) を使用したカーネル開発のワークフロー（作成、デバッグ、プロファイリング、パフォーマンス分析）をサポートします。
何が嬉しいのか #
NKI は、Trainium のハードウェア性能を最大限に引き出すカスタム計算カーネルを作成するための低レベルプログラミングインターフェースですが、高度な専門知識を必要とします。Neuron Agentic Development を使用することで、開発者は自然言語を通じて AI エージェント（Claude Code や Kiro など）の助けを借りながら、NKI カーネルの開発や最適化を行うことができます。
これまでとどう変わるのか #
- これまで: ハードウェア特有の最適化を行う NKI カーネルの開発には、深い専門知識が必要であり、デバッグやパフォーマンス分析にも多大な労力がかかっていた。
- これから: AI エージェントに PyTorch の操作を記述して NKI カーネルを生成させたり、コンパイルエラーの修正、ボトルネックの特定レポートを自然言語でリクエストしたりできるようになる。
具体的なユースケース #
- カスタム AI モデルの最適化: 特定のモデルアーキテクチャに合わせて、Trainium 上で最高効率で動作する独自の計算カーネルを迅速に開発・デプロイする。
- 開発効率の向上: NKI のドキュメントを検索したり、プロファイルをキャプチャして分析したりする作業を AI エージェントに委託し、開発サイクルを短縮する。
AWS Payment Cryptography が紙ベースのキー交換をサポート #
投稿日: 2026年04月30日
何ができるようになったのか #
AWS Payment Cryptography において、物理キー交換（Physical Key Exchange）機能がサポートされました。これにより、自前で安全なキーローディングインフラを維持することなく、紙ベースの暗号キー交換を PCI PIN および P2PE に準拠した形で実行できるようになります。
何が嬉しいのか #
電子的なキー交換をサポートしていないパートナーやベンダーとの間でも、コンプライアンスを維持したままキー交換を行えるようになります。従来、組織は紙ベースのキーセレモニー（儀式）を行うために HSM（ハードウェアセキュリティモジュール）や KLD（キーローディングデバイス）を自前で運用する必要があり、コストと運用の負担が大きかったのですが、これを AWS に委託できるようになります。
これまでとどう変わるのか #
- これまで: 紙ベースのキー交換が必要な場合、専用の設備（HSMなど）を備えたセキュアな施設を自社で用意し、厳格な手順（キーセレモニー）を自ら実施・管理しなければならなかった。
- これから: キーの構成要素を AWS のトレーニングを受けたキーカストディアン（保管責任者）に送付することで、AWS が運営する PCI 準拠のセキュアな施設でキーセレモニーが実施され、AWS Payment Cryptography にロードされる。
具体的なユースケース #
- レガシーな決済ネットワークとの統合: 電子的交換に対応していない銀行や決済プロバイダーとの間で、安全に暗号キーを共有し、クラウド上の決済アプリケーションで利用する。
- HSM 運用の廃止: 物理的な HSM やキー管理用デバイスの保守から解放され、決済システムのクラウド移行を加速させる。
Amazon Bedrock AgentCore で AWS for SAP MCP サーバーが一般提供開始 #
投稿日: 2026年04月23日
何ができるようになったのか #
Amazon Bedrock AgentCore において、「AWS for SAP MCP Server」が一般提供（GA）開始されました。これは、AI エージェントを SAP ERP システムに直接、安全かつ大規模に接続するために設計されたソリューションです。Model Context Protocol (MCP) と SAP の Open Data Protocol (OData) 標準に基づいて構築されています。
何が嬉しいのか #
AI エージェントが、財務、調達、物流、サプライチェーンなどの SAP ビジネスプロセスに直接アクセスできるようになります。SAP 内の販売注文、購買発注、品目、財務伝票などのビジネスオブジェクトに対して、作成、読み取り、更新、削除（CRUD）操作を行うことが可能です。フルマネージドな Amazon Bedrock AgentCore ランタイム上で動作するため、インフラ管理の手間がなく、セキュアな接続と認証が保証されます。
これまでとどう変わるのか #
- これまで: AI エージェントから SAP のデータやプロセスを利用するには、カスタム API の開発や複雑な統合設定、セキュリティ確保のための作り込みが必要だった。
- これから: 数分でデプロイ可能な CloudFormation テンプレートを使用し、AI エージェントを SAP システムに即座に連携させることができる。
具体的なユースケース #
- 自動 Procure-to-Pay ワークフロー: AI エージェントが調達依頼を自動で作成し、承認フローを回して SAP 上で購買発注を確定させる。
- サプライチェーン最適化: AI が在庫状況をリアルタイムで SAP から取得し、最適な補充計画を提案・実行する。
Amazon Bedrock AgentCore がエージェント性能最適化機能をプレビュー公開 #
投稿日: 2026年04月30日
何ができるようになったのか #
Amazon Bedrock AgentCore において、エージェントのパフォーマンスを最適化するための「推奨（Recommendations）」、「バッチ評価（Batch Evaluations）」、および「A/B テスト（A/B Tests）」の各機能がプレビュー公開されました。これにより、本番環境でのエージェントの監視、評価、改善のサイクルが完成します。
何が嬉しいのか #
従来、エージェントの評価結果を具体的な改善に繋げるには、開発者の直感や手動の介入が必要でした。新しい最適化機能では、本番環境のトレースや評価結果を分析し、特定のワークロードに合わせて最適化されたシステムプロンプトやツール記述を自動で推奨します。これをバッチ評価で検証し、さらに本番トラフィックを用いた A/B テストで統計的な有意性を確認した上で適用できるため、根拠に基づいた継続的な性能向上が可能になります。
これまでとどう変わるのか #
- これまで: モデルの進化やユーザー行動の変化に伴うエージェントの品質低下に対し、体系的に改善を検証・適用するツールが不足していた。
- これから: システムが推奨する最適化案をテストし、性能向上が確認されたものだけを承認・デプロイするという、データ駆動型の改善プロセスを確立できる。
具体的なユースケース #
- プロンプトの微調整: ユーザーの問い合わせパターンが変化した際、エージェントの回答精度を維持するために最適なプロンプトへの自動更新案を受け取る。
- ツールの説明文改善: AI がツールを選択する際の誤認を減らすために、より明確なツール記述への最適化案を検証・適用する。
IAM Roles Anywhere が CreateSession API に対して VPC エンドポイントポリシーを適用 #
投稿日: 2026年05月01日
何ができるようになったのか #
AWS Identity and Access Management (IAM) Roles Anywhere において、CreateSession API に対する VPC エンドポイントポリシーの設定が可能になりました。これにより、VPC エンドポイント経由での CreateSession 操作を明示的に許可または拒否できるようになります。
何が嬉しいのか #
CreateSession API は、AWS 外で実行されるワークロードが X.509 証明書を使用して一時的な AWS 認証情報を取得するための重要な API です。これまで VPC エンドポイントポリシーは CreateSession 以外の API 操作にのみ適用されていましたが、今回のアップデートにより、すべての IAM Roles Anywhere API 操作に対して一貫した、きめ細かなアクセス制御が可能になります。
これまでとどう変わるのか #
- これまで: VPC エンドポイントポリシーで他の操作を制限していても、
CreateSessionAPI にはポリシーが適用されていなかった。 - これから: VPC エンドポイントポリシーの
AllowステートメントにCreateSessionを明示的に含める（またはrolesanywhere:*を指定する）必要があります。許可されていない場合、VPC エンドポイント経由のリクエストに対して一時的な認証情報は返されません。
具体的なユースケース #
- セキュリティの強化: 特定の VPC エンドポイントからのみ、外部サーバーの一時的な認証情報取得を許可し、意図しない場所からの API 利用を制限する。
- データ境界（Data Perimeter）の確立: 組織の VPC 内から許可されたアクションのみが実行されるよう、ポリシーを厳格化する。
Elastic Fabric Adapter (EFA) 向け Kubernetes 動的リソース割り当て (DRA) を発表 #
投稿日: 2026年05月01日
何ができるようになったのか #
Amazon EKS において、Elastic Fabric Adapter (EFA) の動的リソース割り当て（Dynamic Resource Allocation, DRA）がサポートされました。これにより、AI/ML やハイパフォーマンスコンピューティング (HPC) ワークロード向けのノード間通信や RDMA (Remote Direct Memory Access) の設定が簡素化されます。
何が嬉しいのか #
EFA DRA ドライバーを使用すると、同じ PCIe ルートやデバイスグループを共有する EFA インターフェースとアクセラレーター（GPU、Trainium、Inferentia）をトポロジーを考慮して割り当てることができます。これにより、ネットワークトラフィックが各デバイスに最も近いネットワークインターフェースを流れるようになり、通信効率が最大化されます。また、ノード上の複数のワークロード間で EFA インターフェースを共有することも可能になります。
これまでとどう変わるのか #
- これまで: EFA デバイスの割り当て管理はデバイスプラグインに依存しており、トポロジーに応じた最適な割り当てや柔軟な共有設定に課題があった。
- これから: DRA を通じて、ハードウェアトポロジーを意識した高度なリソース管理が可能になり、大規模な分散学習などのパフォーマンスが向上する。
具体的なユースケース #
- 大規模言語モデル (LLM) の分散学習: 複数のノード間で膨大なデータを高速にやり取りする必要がある学習ジョブにおいて、GPU と EFA インターフェースの最短経路を自動で確保する。
- マルチテナント・クラスターでのリソース共有: 同じ計算ノード上の異なるジョブ間で EFA インターフェースを効率的に共有し、ハードウェア利用率を高める。
AWS Transform が Power BI および Tableau から Amazon Quick への BI 移行エージェントを提供 #
投稿日: 2026年05月01日
何ができるようになったのか #
AWS Transform において、Tableau および Power BI のダッシュボードを Amazon QuickSight (Amazon Quick の BI 機能) のアセットに自動変換する「BI 移行エージェント」が利用可能になりました。これにより、数ヶ月かかっていた移行作業を数日に短縮することが可能になります。
何が嬉しいのか #
Wavicle Data Solutions が開発したこれらのエージェントは、AWS Transform のワークフローに組み込まれており、チャットベースのインターフェースを通じて移行準備状況の評価から実際の変換までを支援します。データセット、計算フィールド、ビジュアライゼーション、フィルターを QuickSight 上で再構築します。処理はすべてユーザーの AWS アカウント内で行われるため、データが外部に出ることはありません。
これまでとどう変わるのか #
- これまで: 他社の BI ツールから QuickSight へ移行する場合、ダッシュボードの設計や計算ロジックを手動で一つずつ再作成する必要があり、多大な労力と時間が必要だった。
- これから: AI エージェントを活用することで、既存の資産を効率的に変換できる。移行後は、自然言語による質問（Amazon Q in QuickSight）などの AI 機能を即座に活用できる。
具体的なユースケース #
- BI ツールの統合: コスト削減や AI 連携のために、社内で分散していた Tableau や Power BI のレポートを Amazon QuickSight に集約する。
- モダナイゼーション: レガシーな BI 環境から、生成 AI 機能を備えたモダンなクラウド BI 環境への移行を加速させる。
Amazon RDS for SQL Server が追加ストレージボリューム構成でのアカウント間スナップショット共有をサポート #
投稿日: 2026年05月01日
何ができるようになったのか #
Amazon RDS for SQL Server において、追加ストレージボリューム（Additional Storage Volumes）を使用しているインスタンスのデータベーススナップショットを、他の AWS アカウントと共有できるようになりました。追加ストレージボリュームは、最大 256 TiB までのスケーリングを可能にする機能です。
何が嬉しいのか #
大規模なデータベース環境においても、アカウントを跨いだスナップショットの共有・コピーが可能になります。これにより、コンプライアンス要件に基づいた隔離されたバックアップ環境の構築や、本番環境の問題調査のために別アカウントの環境でスナップショットを復元して診断を行うといった作業が容易になります。
これまでとどう変わるのか #
- これまで: SQL Server インスタンスで追加ストレージボリューム機能を使用している場合、アカウント間でのスナップショット共有には制限があった。
- これから: 追加ストレージボリュームの構成（ボリューム数やサイズ）を保持したままスナップショットを共有でき、ターゲットアカウント側で別のインスタンスとして復元したり、同一または別のリージョンにコピーしたりできる。
具体的なユースケース #
- 開発・テスト環境への本番データ共有: 本番アカウントのスナップショットを、開発用アカウントに安全に共有してバグ修正や性能テストに利用する。
- ディザスタリカバリ (DR): コンプライアンス対応の一環として、スナップショットを別の AWS アカウントおよび別リージョンに保管する。
Amazon RDS for SQL Server が追加ストレージボリューム構成でのリードレプリカをサポート #
投稿日: 2026年05月01日
何ができるようになったのか #
Amazon RDS for SQL Server において、追加ストレージボリューム（Additional Storage Volumes）を使用しているデータベースインスタンスのリードレプリカを作成できるようになりました。同一リージョン内およびクロスリージョンの両方のリードレプリカをサポートします。
何が嬉しいのか #
最大 256 TiB の大容量ストレージを必要とする大規模な SQL Server データベースにおいても、リードレプリカによる読み取り負荷の分散や、リージョンを跨いだ可用性の向上が可能になります。作成されたリードレプリカは、ソースインスタンスのストレージレイアウト（追加ボリュームの構成など）を自動的に継承します。
これまでとどう変わるのか #
- これまで: SQL Server インスタンスで追加ストレージボリューム機能（ストレージの拡張）を使用している場合、リードレプリカの作成がサポートされていなかった。
- これから: 大容量ストレージ構成を維持したまま、読み取り専用の複製を柔軟に作成・管理できる。作成後は、ソースとレプリカで個別にストレージ構成を管理することも可能。
具体的なユースケース #
- 読み取りトラフィックの分散: 大規模なデータ分析やレポート作成のクエリをリードレプリカに割り振り、本番の書き込み処理への影響を抑える。
- 地理的な読み取り遅延の低減: アプリケーションのユーザーに近いリージョンにリードレプリカを配置し、参照パフォーマンスを向上させる。