AWS What's New Digest

Appearance

2026年05月01日 ​

[Solution] Spatial Data Management on AWS adds custom transformations ​

概要 ​

Spatial Data Management on AWS (SDMA)はカスタム変換コネクタと統合デスクトップクライアントの単一インストーラを追加しました。これにより、Deadline Cloudへジョブを送信して重い処理を外部で実行し、結果をSDMAのガバナンス下に自動取り込みできます。

変更内容・新機能の詳細 ​

カスタム変換コネクタはOpen Job Descriptionテンプレートを使ってAWS Deadline Cloudにジョブを送信し、フォーマット変換、3Dレンダリング、画像タイル化、メタデータ抽出などの計算集約型処理を実行できます。既存のコンテンツ解析機能を拡張して、フォーマット検証や属性抽出といった独自ロジックを組み込めます。コネクタは分離されたコンピュート環境（Deadline Cloud上のワーカ）で実行され、出力を事前宣言された形式でSDMAのガバナンスされたアセットリポジトリへ自動的に取り込みます。この仕組みにより、処理ワークロードの自動化や連鎖実行（チェーン処理）が可能になり、空間データパイプライン全体の運用効率が向上します。さらに、SDMAデスクトップアプリは必要な依存関係を同梱した単体インストーラを提供するため、CLIや追加コンポーネントを個別にインストールする必要がなくなりました。これらの機能は以下のリージョンで利用可能です: アジアパシフィック（東京、シンガポール、シドニー）、ヨーロッパ（フランクフルト、アイルランド、ロンドン）、米国（北バージニア、オハイオ、オレゴン）。

影響範囲・利用シーン ​

  • 対象ユーザー: 衛星/航空画像処理チーム、地理空間データエンジニア、3D/可視化ワークフローを持つ開発者やSRE
  • 利用シーン: 大容量ラスタ/ベクタデータのフォーマット変換、タイル生成、3Dモデルレンダリング、メタデータ抽出・検証を外部コンピュートで実行してSDMAへ結果を自動取り込み
  • 運用効果: ローカルでの手作業やオンプレ処理を削減し、スケール可能なクラウドバッチ処理でパイプラインを自動化。ガバナンスされたリポジトリへの自動取り込みによりデータ追跡・再現性が向上

技術的な注意点 ​

  • IAM権限: Deadline CloudやSDMAのジョブ送信・出力取り込みに必要なIAMロール/ポリシーを事前に設定してください（ジョブ実行、S3アクセス、KMSなど）
  • リージョン制限: 本機能は公開済みのリージョン（東京、シンガポール、シドニー、フランクフルト、アイルランド、ロンドン、北バージニア、オハイオ、オレゴン）のみで利用可能です
  • コスト: Deadline Cloudのコンピュート利用、データ転送、ストレージ（アセットリポジトリ）に対する追加コストが発生します。長時間ジョブや大量データ転送のコスト見積もりを事前に行ってください
  • 依存関係/インストール: デスクトップの単体インストーラは主要な依存関係を同梱しますが、管理者権限やOS互換性（Windows/macOSなど）を確認してください。CLIや他ツールをカスタム構成する場合は別途設定が必要です
  • セキュリティ/データ管理: コネクタは隔離環境で実行されますが、出力の取り込み先（S3、アセットリポジトリ）に対するアクセス制御、暗号化（KMS）や監査ログの設定を必ず行ってください
  • 要件: Open Job Descriptionテンプレートの作成知識、Deadline Cloudのセットアップとジョブ定義の理解が必要です
  • 運用上の注意: ジョブキューの遅延やリソース競合が発生する可能性があるため、モニタリングとリトライ/エラー処理の設計を行ってください

参考情報 ​

[EKS] Announcing Kubernetes Dynamic Resource Allocation for Elastic Fabric Adapter ​

概要 ​

Amazon EKSがElastic Fabric Adapter（EFA）向けのKubernetes Dynamic Resource Allocation（DRA）をサポートしました。これにより、RDMAを使うAI/ML/HPCワークロードでのノード間通信をトポロジー認識で最適化し、EFAインターフェイスの共有利用が可能になります。

変更内容・新機能の詳細 ​

EFA DRAドライバーはアップストリームのDRANETプロジェクトを基に実装されたKubernetesのDRA対応ドライバーです。PCIeルートやデバイスグループを共有するEFAインターフェイスと加速デバイス（NVIDIA GPU、AWS Trainium、AWS Inferentiaなど）をトポロジーに基づいて割り当てることで、各加速デバイスに最も近いネットワークインターフェイス経由でのインター・ノード通信（RDMA）を実現します。ノード内で複数のワークロード間でEFAインターフェイスを共有できるため、EFAインターフェイスの利用効率を高められます。EFA DRAはAmazon EKS上のKubernetes 1.34以降での新規デプロイを推奨しており、EKSマネージドノードグループおよびセルフマネージドノードの両方で利用可能です。一方、従来のEFAデバイスプラグインは引き続きサポートされ、KarpenterやAmazon EKS Auto Modeを利用する環境ではデバイスプラグインの利用が推奨されています。EFA DRAはAmazon EKSが利用可能なすべてのリージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AI/MLエンジニア、HPCユーザー、クラウドインフラ/プラットフォームエンジニア
  • 利用シーン: 分散学習（GPU/Trainium/Inferentiaを用いたモデル並列・データ並列）、低遅延RDMA通信を必要とするHPCアプリケーションのクラスタ構築
  • 運用効果: ネットワークトポロジーを考慮したデバイス割当てにより通信レイテンシと帯域利用が改善され、EFAインターフェイスの共有によりリソース効率が向上するためコスト対性能比が改善される

技術的な注意点 ​

  • Kubernetesバージョン: EFA DRAはKubernetes 1.34以上を推奨（EKSの同等バージョンで確認してください）
  • ノード要件: EFA対応インスタンスタイプとEFAカーネルドライバー／libfabric等の前提ソフトウェアがノードで必要です（Amazon Linux/Bottlerocketの対応AMIを利用することを推奨）
  • 互換性: 既存のEFAデバイスプラグインは引き続きサポート。KarpenterやEKS Auto Modeを使う環境ではデバイスプラグインが推奨されます
  • IAM権限: クラスタにドライバーをインストール／設定するにはクラスタ管理者権限（cluster-adminなど）が必要になる可能性があります。オペレーション用のRBAC設定を確認してください
  • リージョン制限: Amazon EKSが利用可能なすべてのリージョンで提供されています（ただし個別リージョンのインスタンスタイプ可用性は確認してください）
  • コスト: DRAドライバー自体に追加課金はありませんが、EFA対応インスタンスと加速デバイス（GPU/Trainium/Inferentia）の利用コストが発生します
  • 運用上の注意: ノードのAMI／カーネル／ドライバーのバージョン不整合は通信障害や性能劣化を招くため、EFAとRDMA周りのソフトウェア要件を事前に確認しておくことを推奨します

参考情報 ​

[Rds For Sql Server] Amazon RDS for SQL Server supports cross-account snapshot sharing with additional storage volumes ​

概要 ​

Amazon RDS for SQL Server が追加ストレージボリュームを使うDBインスタンスのスナップショットをアカウント間で共有できるようになりました。これにより、最大256 TiB構成のスナップショットを別アカウントに渡して復元・コピー・バックアップに利用できます。

変更内容・新機能の詳細 ​

追加ストレージボリューム（プライマリに加え最大3つ、各最大64 TiB）を利用する RDS for SQL Server インスタンスのスナップショットについて、別 AWS アカウントへの共有（cross-account snapshot sharing）をサポートします。共有されたスナップショットは、ターゲットアカウント内の許可されたユーザーが別インスタンスへ復元したり、同一または別リージョンへコピーしたり、異なる IAM 権限下で独立したバックアップとして扱うことができます。共有時にはオリジナルのストレージレイアウト（追加ボリュームの構成を含む）が保持されます。本機能は全ての商用 AWS リージョンで利用可能で、AWS マネジメントコンソール、AWS CLI、AWS SDK を通じて操作できます。ユースケースは、コンプライアンス目的での分離バックアップ環境構築、プロダクション問題の切り分けのため別アカウントでの復元・診断、災害対策用のバックアップ運用などが想定されます。

影響範囲・利用シーン ​

  • 対象ユーザー: RDS for SQL Server を運用するデータベース管理者、SRE、セキュリティ/コンプライアンス担当者
  • 利用シーン: 別アカウントでの隔離バックアップ保管（コンプライアンス）、開発/検証環境での本番スナップショット復元、クロスアカウントでの障害調査・復旧訓練
  • 運用効果: バックアップのアカウント分離により権限分離とコンプライアンス対応が容易になり、本番問題の安全な再現・診断や DR/移行の柔軟性が向上する
  • 制限事項: 共有対象はスナップショット単位で、スナップショットの種類（手動スナップショットか自動か）や暗号化（KMS）に依存する操作上の制約がある
  • リージョン影響: 本機能は全商用リージョンで利用可能（ただしリージョン間コピー時はクロスリージョン料金や遅延が発生）

技術的な注意点 ​

  • IAM権限: スナップショット共有には rds:ModifyDBSnapshotAttribute 等のスナップショット操作権限、ターゲットでの復元やコピーには rds:CopyDBSnapshot / rds:RestoreDBInstanceFromDBSnapshot 等の権限が必要です
  • スナップショットの種類: 通常、手動 (manual) DB スナップショットの共有が対象です。自動スナップショットは共有できない制約があるため事前に手動スナップショットを作成してください
  • 暗号化/KMS: 暗号化されたスナップショットを共有する場合は KMS キーのポリシーでターゲットアカウントへのアクセス許可を与える必要があります。クロスアカウントで直接アクセスできない場合はコピー時に別キーで再暗号化する運用が必要です
  • 復元先の前提: 復元先アカウントでは対象の追加ストレージボリューム構成をサポートする DB インスタンスクラスやストレージ設定を選択する必要があります。オプショングループやパラメータグループ、VPC 設定・セキュリティグループはアカウント固有のため復元後に適切に設定してください
  • コスト: スナップショットのコピーやクロスリージョン転送、復元後の DB インスタンス稼働は追加のストレージ・データ転送・インスタンス時間課金が発生します
  • リージョン制限: 記事では「全商用リージョンで利用可能」とされていますが、組織のガバナンスやローカル規制により利用可否が異なる場合があるため事前確認してください

参考情報 ​

[Govcloud Us] Amazon RDS for SQL Server supports read replica with additional storage volumes ​

概要 ​

Amazon RDS for SQL Server が追加ストレージボリュームを持つ DB インスタンスのリードレプリカをサポートしました。これにより、最大 256 TiB（プライマリ＋最大3つの追加ボリューム）までスケールしたインスタンスでも同一リージョン／クロスリージョンでリードレプリカを作成できます。

変更内容・新機能の詳細 ​

今回のアップデートにより、追加ストレージボリューム（primary に加え最大3つ、各最大64 TiB）を構成した Amazon RDS for SQL Server インスタンスでリードレプリカを作成可能になりました。リードレプリカ作成時点ではソースのストレージレイアウト（追加ボリュームの構成を含む）が保持されますが、初期作成後はソースとレプリカで追加ボリューム構成を独立して管理できます。作成は同一リージョン・クロスリージョン両方に対応しており、AWS マネジメントコンソール、AWS CLI、AWS SDK から利用できます。利用可能地域は全ての AWS 商用リージョンと AWS GovCloud (US) です。ストレージ合計はプライマリ + 最大3追加ボリューム（各最大64 TiB）で合計最大 256 TiB となります。

影響範囲・利用シーン ​

  • 対象ユーザー: 大容量ストレージを必要とする SQL Server ワークロードを運用するデータベース管理者、SRE、アプリケーション開発者
  • 利用シーン: 読み取り負荷の分散（レポーティング、ETL、BIクエリ）、地理的レイテンシー改善のためのクロスリージョンレプリケーション、バックアップや検証環境のためのリードレプリカ利用
  • 運用効果: 大容量データベースでも読み取りスケールアウトやリージョン間レプリケーションが可能になり、読み取り性能向上や災害対策/リカバリ戦略の柔軟性が向上
  • リージョン: 全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能（ただし個別リージョンのサービス制限は確認が必要）

技術的な注意点 ​

  • IAM権限: リードレプリカ作成やストレージ変更には RDS 関連の IAM 権限（rds:CreateDBInstanceReadReplica など）が必要です。事前に権限を確認してください。
  • リージョン制限: 発表では全商用リージョンと GovCloud (US) で利用可能とされていますが、特定リージョンでの個別制限やリージョン内の機能展開状況は確認してください。
  • コスト: 追加ストレージ分の料金、レプリケーションに伴うクロスリージョンデータ転送費用、リードレプリカ用のインスタンス料金が発生します。ストレージタイプやプロビジョニング IOPS の選択によっても費用が変わります。
  • ストレージ互換性: 発表文では追加ボリュームのサポートを明記していますが、使用できるストレージタイプ（gp3/io2 など）や IOPS 設定、インスタンスタイプとの互換性についてはドキュメントで確認してください。
  • 運用注意: リードレプリカ作成時にソースのストレージレイアウトが複製されますが、作成後はソースとレプリカで追加ボリューム構成を独立管理可能です。以降のサイズ変更やボリューム追加は自動で同期されないため、構成変更時は双方を個別に管理・確認してください。
  • バックアップ/スナップショット: 大容量ストレージや複数ボリューム構成はスナップショット作成時間やストレージトラフィックに影響します。運用バックアップウィンドウを検討してください。

参考情報 ​

[General] AWS Outposts racks now support LagStatus CloudWatch metric ​

概要 ​

AWS OutpostsラックでLAG（Link Aggregation Group）の接続状態を示すCloudWatchメトリクス「LagStatus」が全商用リージョンおよびAWS GovCloud (US-East/West)のOutposts対応リージョンで利用可能になりました。CloudWatch上でLAGの稼働状況を直接監視・アラーム設定できます。

変更内容・新機能の詳細 ​

LagStatusメトリクスはOutpostsのLAGがトラフィックを転送できる状態かを示すブール的な指標で、値は「1（up）」「0（down）」です。CloudWatchコンソールから参照・グラフ化・アラーム設定が可能で、既存のVifConnectionStatusおよびVifBgpSessionStateメトリクスと組み合わせることで、問題の切り分け（LAG自体か、接続/物理リンクか、BGPピアリングか）を速やかに行えます。本メトリクスは第1世代・第2世代のOutpostsラックの全LAGに対して提供され、外部のネットワーク監視ツールや別チームとの調整に頼らず運用監視を行えます。導入手順や可視化はCloudWatchコンソールと関連ドキュメント（Outposts向けCloudWatchメトリクス）を参照してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ネットワーク・クラウドエンジニア、SRE、オンプレネットワークとOutpostsを連携する運用チーム
  • 利用シーン: OutpostsラックのLAG稼働監視、接続障害の早期検知、CloudWatchアラームによる自動通知（例: 運用インシデントのトリガー）
  • 運用効果: 外部ツールなしでLAGの死活を監視でき、VIF/BGP関連メトリクスと合わせることで障害切り分けが高速化されるためMTTR短縮に寄与する

技術的な注意点 ​

  • IAM権限: CloudWatchのメトリクス閲覧・GetMetricDataやDescribeAlarms等の権限が必要です（参照用の最小権限を適用してください）
  • リージョン制限: 全商用リージョンおよびAWS GovCloud (US‑East/West)のOutposts提供リージョンで利用可能（Outposts自体が未提供のリージョンでは未対応）
  • コスト: CloudWatchメトリクスの取得・保持、アラーム数に応じた課金が発生する可能性があります。詳細はCloudWatchの料金を確認してください
  • メトリクス値: 1 = LAGがup（トラフィック転送可能）、0 = down（トラフィック不可）
  • 互換性: 第1世代および第2世代OutpostsラックのLAGで利用可能
  • 運用上の注意: LagStatusはLAGのリンク状態を示すものであり、BGPネゴシエーションや上位プロトコルの疎通（経路伝播・フィルタ）までは保証しません。他メトリクス（VifConnectionStatus、VifBgpSessionState）やログと併用して原因を特定してください
  • 設定: CloudWatchでの表示、グラフ化、アラーム設定が可能。自動化や通知（SNS等）と組み合わせた運用設計を推奨します

参考情報 ​

[ECS] Amazon ECS Managed Instances now supports NVIDIA GPU metrics ​

概要 ​

Amazon ECS Managed InstancesがNVIDIA GPUのメトリクスをCloudWatch Container Insights（enhanced observability）経由で取得・表示できるようになりました。GPUのキャパシティ、利用率、メモリ、ハードウェア健康状態、温度などのデバイスレベル指標を監視できます。

変更内容・新機能の詳細 ​

今回のアップデートにより、Amazon ECSのManaged Instances上で稼働するコンテナ化されたGPUワークロードについて、CloudWatch Container Insights（enhanced observability）を通じてNVIDIA GPUメトリクスを取得できるようになりました。取得できる主なメトリクスはGPUキャパシティ（デバイス数/割当）、利用率（GPU利用率）、GPUメモリ使用量、ハードウェアのヘルス指標（ECCエラー等）、およびサーマル情報（温度）などで、GPUデバイス単位での粒度ある可視化が可能です。これにより、GPU容量の適正化（right-sizing）、性能ボトルネックの特定、ハードウェア障害の早期検出が容易になります。利用開始手順の概略は、（1）対象のAmazon ECSクラスターでContainer Insightsのenhanced observabilityを有効化、（2）Amazon ECS Managed Instancesのキャパシティプロバイダー経由でGPU対応のAmazon EC2インスタンスタイプを起動、です。料金はCloudWatch Container Insightsの料金体系に従います。なお、AWSの商用リージョンでは利用可能とされています。

影響範囲・利用シーン ​

  • 対象ユーザー: GPUを使うAI/MLエンジニア、データサイエンティスト、SRE/運用チーム、コンテナ基盤担当者
  • 利用シーン: トレーニング/推論ジョブの性能監視、GPUリソース配分の最適化、GPUハードウェア障害の早期検知
  • 運用効果: GPU利用率やメモリ使用状況を可視化して過不足を解消できるためコスト削減とパフォーマンス安定化に寄与
  • スケーリング影響: GPU利用率に基づくスケーリング判断やキャパシティプランニングがしやすくなる

技術的な注意点 ​

  • IAM権限: Container InsightsおよびCloudWatchにメトリクスを送信するためのCloudWatch/Logs/IAM権限が必要です（クラスターやEC2用のIAMロール設定を確認してください）
  • リージョン制限: 記事では「商用リージョンで利用可能」と明記されていますが、AWS GovCloud／中国リージョン等は別途確認が必要です
  • コスト: CloudWatch Container Insightsのメトリクス収集・保存・ダッシュボード表示に基づく課金が発生します（CloudWatchの料金ページを確認してください）
  • 対応インスタンスタイプ/ドライバ: GPU対応のAmazon EC2インスタンスタイプ（NVIDIA GPU搭載）と適切なNVIDIAドライバが必要です。ドライバやCUDAのバージョン互換性に注意してください
  • 有効化手順: クラスターでContainer Insightsのenhanced observabilityを有効化し、Managed Instancesのキャパシティプロバイダー経由でGPUインスタンスを起動する必要があります（エージェントや設定の適用を確認してください）
  • 依存コンポーネント: CloudWatchのContainer Insights収集エージェント（または関連の統合）がGPUメトリクスを収集します。エージェントバージョンや設定が古いと一部メトリクスが取得できない可能性があります
  • メトリクス粒度/遅延: メトリクスの収集間隔やCloudWatchへの反映遅延はあるため、リアルタイム応答が必要な用途では設計に注意してください

参考情報 ​

[Mq] Amazon MQ for RabbitMQ now supports Prometheus metrics ​

概要 ​

Amazon MQ for RabbitMQ が RabbitMQ 4.2 ブローカーで Prometheus プラグインをサポートしました。ブローカー上にネイティブな Prometheus 互換の /metrics エンドポイントを公開し、直接メトリクスをスクレイプできます。

変更内容・新機能の詳細 ​

RabbitMQ 4.2 ブローカーに Prometheus プラグインが組み込まれ、/metrics、/metrics/detailed、/metrics/memory-breakdown の各エンドポイントで Prometheus テキスト形式のメトリクスを公開します。これにより、ブローカー、キュー、接続などのメトリクスを任意の Prometheus 互換ツール（Grafana、Amazon Managed Service for Prometheus、セルフホスト Prometheus など）で直接スクレイプおよび可視化・アラート可能になります。Amazon MQ はこれらの Prometheus メトリクスのキュレーション済みサブセットを CloudWatch にも公開します。Prometheus プラグインは Amazon MQ for RabbitMQ 4.2 ブローカーでデフォルト有効化されており、Amazon MQ が利用可能な全リージョンで有効です。既存のブローカーが 4.2 未満の場合はバージョンアップが必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: メッセージング基盤の監視を行うSRE/運用チーム、プラットフォーム/インフラエンジニア、データエンジニア
  • 利用シーン: GrafanaダッシュボードやAmazon Managed Service for Prometheus(AMP)、自社Prometheusでブローカー/キュー/接続のメトリクスを直接可視化・アラート
  • 運用効果: エクスポーター不要で標準的なPrometheus監視スタックへ統合でき、障害検知や容量計画、パフォーマンスチューニングが容易になる
  • 導入メリット: 既存の Prometheus ベースの監視投資を流用でき、CloudWatch への二次公開で既存の CloudWatch アラームやダッシュボードも併用可能

技術的な注意点 ​

  • バージョン要件: Prometheus プラグインは RabbitMQ 4.2 ブローカーで利用可能。4.2 未満のブローカーはアップグレードが必要
  • 有効化状態: Amazon MQ for RabbitMQ 4.2 ブローカーではデフォルトで有効（Amazon MQ が提供されている全リージョン）
  • エンドポイント: /metrics、/metrics/detailed、/metrics/memory-breakdown が Prometheus テキスト形式で公開される
  • ネットワーク/セキュリティ: Prometheus サーバーや AMP がブローカーのエンドポイントへ HTTP(S) で到達可能である必要がある。セキュリティグループやサブネット、NACL を確認してください（スクレイピングは通常 IAM 認証を使わない）
  • CloudWatch: Amazon MQ は Prometheus メトリクスのキュレーションされたサブセットを CloudWatch に公開する。CloudWatch によるメトリクス保存やアラームは追加コストが発生する可能性あり
  • パフォーマンス/コスト: 高頻度のスクレイプや多数の時系列（高カードinality）はブローカーの CPU/ネットワークに影響を与える可能性があるため、スクレイプ間隔や収集するメトリクスを調整してください
  • 統合例: Grafana、Amazon Managed Service for Prometheus、セルフホスト Prometheus と直接統合可能
  • アップグレード運用: 既存ブローカーのバージョンアップ時はダウンタイムや互換性を考慮した運用計画を検討してください

参考情報 ​

[Bedrock] Amazon Bedrock AgentCore Identity now supports On-Behalf-Of (OBO) token exchange ​

概要 ​

Amazon Bedrock AgentCore IdentityがOn-Behalf-Of (OBO) トークン交換をサポートし、認証済みユーザーを代理して保護された外部リソースへ安全にアクセスするエージェントを、追加の同意フローなしで構築できるようになりました。14リージョンで一般提供(GA)されています。

変更内容・新機能の詳細 ​

OBOトークン交換により、開発者は既存のユーザーアクセストークンを、当該外部保護リソース向けにスコープを絞った（scoped-down）新しいアクセストークンへ交換できます。交換後のトークンは元のユーザーIDとエージェントIDの両方の属性を保持し、特定のアウトバウンドリソースを対象として最小権限（least-privilege）のアクセスをその場で付与します。その結果、ユーザーに対して各リソースごとの追加同意（consent）を求めることなく、エージェントがユーザー権限で外部APIや保護リソースにアクセスできます。実装上は、AgentCore Identityのトークン交換APIに対してユーザーのアクセストークンを提示し、対象リソース向けの限定的なトークンを取得するフローになります（一般的なOBO／トークン交換の考え方に類似）。本機能は一般提供されており、以下のリージョンで利用可能です: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Asia Pacific (Mumbai), Asia Pacific (Seoul), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm)。

影響範囲・利用シーン ​

  • 対象ユーザー: エージェントを実装するアプリ開発者、SRE/運用チーム、セキュリティエンジニア
  • 利用シーン: エージェントが認証済みユーザーを代理して外部APIや保護リソース（サードパーティAPI、社内マイクロサービス、データストア等）へアクセスする場合
  • 運用効果: ユーザーへの同意要求を削減し、開発側の同意フロー管理負荷を低減。権限をスコープごとに最小化して付与することでセキュリティリスクを低減
  • セキュリティ効果: ユーザー証跡とエージェントの識別情報を保持した短期・限定スコープのトークンを発行するため、過剰権限や長期有効トークンによるリスクが軽減される

技術的な注意点 ​

  • IAM権限: AgentCore Identity のトークン交換APIを呼び出すための適切なIAMポリシーを付与する必要があります（トークン取得・管理に関する権限）。
  • 初期ユーザートークン: OBO交換は有効なユーザーアクセストークンを前提とします。ユーザーへの初回同意や認可は基礎トークン発行時に必要になる場合があります。
  • トークン設計: 交換後のトークンはスコープや寿命を限定して発行されるため、API側でのスコープ/オーディエンス検証を必ず行ってください。
  • リージョン制限: 本機能はGA時点で下記14リージョンで利用可能です: us-east-1, us-east-2, us-west-2, ca-central-1, ap-south-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1, eu-west-1, eu-west-2, eu-west-3, eu-north-1。
  • コスト: トークン交換API自体に明示的な追加料金は発表されていませんが、Bedrockや関連APIの利用、ログ出力、データ転送（リージョン間/インターネット向け）等に対して通常の料金が発生します。
  • 監査・ロギング: トークン交換操作やエージェントの外向きアクセスはCloudTrailやアプリケーションログで追跡・監査できるよう設定してください。
  • 互換性/プロトコル: OBOの考え方はOAuth系のトークン交換に類似しますが、実装時はAgentCore IdentityのAPI仕様（スコープ、リフレッシュ動作、トークン形式）を確認してください。

参考情報 ​

[Inferentia] AWS Neuron SDK now available with Neuron Agentic Development for NKI kernel development on Trainium ​

概要 ​

AWS Neuronのオープンソース集合「Neuron Agentic Development」が公開され、AIコーディングアシスタント（agentic IDE）向けにTrainium向けの低レイヤーなNeural Kernel Interface（NKI）カーネル開発を自然言語で支援する機能が提供されました。初回リリースはカーネルの作成、コンパイルエラー修正、プロファイル取得およびボトルネック解析など開発ワークフロー全体をカバーします。

変更内容・新機能の詳細 ​

Neuron Agentic Developmentは、エージェント（AIアシスタント）と“スキル”の集合で、開発者が自然言語で指示するだけでTrainium向けのNKIカーネルの生成、デバッグ、プロファイリング、性能解析を支援します。NKIはTrainiumの低レベルAPIで、カーネル単位でハードウェア性能を最大化するための直接的なプログラミングを可能にします。本初回リリースの主な機能は以下のとおりです：

  • カーネル生成: PyTorchの演算を説明すると対応するNKIカーネルの雛形や動作する実装を生成。
  • エラー修正: コンパイルエラーやビルド失敗を解析し、問題箇所を特定して修正提案や自動適用を行う。
  • プロファイル取得・解析: 実行プロファイルをキャプチャして、カーネル内のどの行・ループがボトルネックかを報告する性能分析レポートを生成。
  • ドキュメント検索・参照: Neuron SDK/ドキュメントへの問い合わせを自然言語で実行し、APIや最適化手法を参照可能。
  • ワークフロー統合: カーネル作成→ビルド→実行→プロファイル→解析の一連をエージェント経由でシームレスに行える設計。 この機能群はオープンソースとしてGitHubで公開されており、agentic IDE（例: Claude Code、Kiroなど）へプラグイン的に組み込んで使えることを想定しています。Neuron Agentic Development自体はNeutonスタック全体に拡張可能なフレームワークを目指しており、今回の初回リリースはTrainium向けのNKIカーネル開発が対象です（将来的にInferentiaなど他コンポーネントへの拡張が想定されます）。利用には該当するNeuron SDKやコンパイラ／ランタイム、Trainiumインスタンスなどの環境が必要です。

影響範囲・利用シーン ​

  • 対象ユーザー: Trainium上で高性能カーネルを開発する機械学習エンジニア、ランタイムエンジニア、パフォーマンス最適化担当者
  • 利用シーン: PyTorchで定義した演算を基にNKIカーネルを生成・最適化する開発ワークフロー（作成→ビルド→デバッグ→プロファイリング→解析）
  • 運用効果: カーネルレベルのボトルネック特定が高速化され、手作業によるトライ＆エラーを削減してTrainium上の推論性能改善／開発速度向上に寄与

技術的な注意点 ​

  • IAM権限: EC2（Trainium）インスタンス起動、S3（アーティファクト保存）、CloudWatchログ、必要なNeuro SDKアクセス権限等が必要です。事前に最小権限のIAMロールを用意してください。
  • リージョン制限: 機能の利用はTrainiumが提供されているリージョンに依存します。利用前に対象リージョンでTrainiumインスタンスとNeuron SDKがサポートされているか確認してください。
  • コスト: リポジトリ自体はオープンソースで無償ですが、Trainiumインスタンスの実行、プロファイリング実行時間、データ転送、ログ保存などは通常のAWS利用料金が発生します。
  • 互換性: 今回の初回リリースは主にTrainiumのNKI向けです。Inferentiaなど他ハードウェア向けサポートは今後の拡張を予定しているため、現時点でInferentia固有のNKI相当機能は限定的な可能性があります。Neuron SDK／コンパイラのバージョン互換性を確認してください。
  • 開発環境依存: agentic IDE（例: Claude Code、Kiro等）側の統合サポートが必要です。ローカル開発ではNeuronコンパイラ、neuron-ccやNeuronランタイム、対応PyTorchブランチなどツールチェーンの導入が前提です。
  • セキュリティ/データ取扱い: エージェント経由でカーネルソースやモデルコードが外部サービス／LLMに送信される可能性があります。機密コードを扱う場合はネットワークポリシーやデータ送信設定（オンプレミスのLLM／プライベート環境での利用等）を検討してください。
  • OSSライセンス: リポジトリはオープンソースで提供されています。商用利用や二次配布を行う場合は付属のライセンス条項を確認してください。

参考情報 ​

[Bedrock] Amazon Bedrock AgentCore launches capabilities for optimizing agent performance in preview ​

概要 ​

Amazon Bedrock の AgentCore に最適化機能（推奨、バッチ評価、A/B テストのプレビュー）が追加され、観測→評価→改善のループを完成させ、プロダクションで稼働するエージェントの性能改善を自動化・検証できるようになりました。

変更内容・新機能の詳細 ​

今回のリリースでは、AgentCore が生成するプロダクショントレースと評価結果を解析して、ワークロードに合わせた最適化されたシステムプロンプトやツール記述（tool descriptions）を自動生成する「推奨（recommendations）」機能を提供します。生成された推奨はまずバッチ評価（事前定義したテストケース群での一括検証）によって定量的に検証され、その後 A/B テスト（事前定義のテストセットまたはライブトラフィックを用いた対照実験）で実運用下の効果が統計的有意性をもって評価されます。A/B テストでは有意差が報告されるまで変更は昇格されず、またすべての推奨はオーナーによる承認が必須となるため、ヒューマンインザループを保った上で自動化された改善フローを回せます。これにより、モデルやユーザー挙動の変化による品質劣化を検出・対処しやすくなり、従来は開発者の直感や手作業で行っていたチューニング作業を体系化できます。これらの最適化機能は、AgentCore Evaluations が利用可能な AWS リージョンで利用可能です。

影響範囲・利用シーン ​

  • 対象ユーザー: AIエージェントを本番運用する開発者、SRE、MLエンジニアおよびプロダクトオーナー
  • 利用シーン: 本番トラフィックからのトレースを基にしたプロンプトやツール説明の最適化、テストケースに対するバッチ検証、ライブ／疑似ライブでの A/B 検証による変更の昇格判断
  • 運用効果: 手動チューニングの削減、変更のエビデンスベース化（統計的有意性）、品質劣化の早期検出と安全な改善適用
  • 導入効果: CI/CD やリリースフローに組み込むことで継続的な性能改善サイクル（observe→evaluate→improve）を自動化できる
  • リージョン: AgentCore Evaluations が有効な AWS リージョンで利用可能（全リージョンでの即時利用は保証されない）

技術的な注意点 ​

  • IAM権限: AgentCore Evaluations と最適化機能を実行・閲覧・承認するための適切な IAM 権限（AgentCore 関連の読み書き権限、A/B テスト実行権限等）が必要
  • リージョン制限: AgentCore Evaluations が提供されているリージョンのみ利用可能。東京リージョンなどの対応状況は事前確認が必要
  • コスト: トレース収集、バッチ評価、A/B テスト（特にライブトラフィック利用）には評価実行分のコストや追加のモデル呼び出しコストが発生する可能性あり
  • データプライバシー: プロダクショントレースは機微情報を含む可能性があるため、収集・保存・共有のポリシーおよび必要なマスキングや同意管理を検討すること
  • 前提条件: AgentCore Evaluations が有効化され、十分なカバレッジをもつトレースと事前定義テストケースが整備されていることが望ましい
  • 統計性: A/B テストは統計的有意性を報告するが、サンプルサイズ、バイアス（ユーザ層や時間帯）、メトリクス定義に注意し、複数指標で評価することを推奨
  • デプロイフロー: すべての推奨はユーザー承認が必要なため、自動昇格パイプラインを組む場合は承認フローの設計（ロール、通知、ロールバック手順）を整備すること
  • 互換性: 最適化されたプロンプトやツール記述は利用するベースモデルや外部ツールの仕様に依存するため、モデルの変更やツールAPIの変更時は再評価が必要

参考情報 ​

AI要約はOpenAI APIによって生成されています。

Copyright © 2026