本日の主なトピック #
- SageMaker Data Agent: 自然言語によるチャート作成とマテリアライズドビューの管理が可能になり、データ分析フローが大幅に簡素化されました。
- CloudWatch Query Studio (プレビュー): ネイティブな PromQL サポートにより、Prometheus エコシステムと CloudWatch のシームレスな統合が実現しました。
- EMR Kiro Powers: AI エージェントが Apache Spark のトラブルシューティングとアップグレードを自動支援し、エンジニアの運用負荷を劇的に軽減します。
- Bedrock Guardrails: クロスアカウント保護機能が GA となり、組織全体の生成AI利用におけるセキュリティ制御を一元管理できるようになりました。
- Secrets Manager: コンソールでのカスタム KMS ARN 入力サポートにより、クロスアカウントでの暗号化設定がより直感的になりました。
¥3,520 Amazonで見る
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本(ソフトカバー) – 2025/7/11
Amazon SageMaker Data Agent がチャート作成機能とマテリアライズドビューのサポートを開始 #
投稿日: 2026年04月03日
何ができるようになったのか #
Amazon SageMaker Data Agentにおいて、インタラクティブなチャート作成、Snowflakeデータソースに対するSQL分析、およびSageMaker Unified Studioノートブック内でのマテリアライズドビュー管理が可能になりました。自然言語のプロンプト(例:「2025年の地域別月次売上トレンドをプロットして」)から直接インタラクティブなチャートを生成したり、クエリパターンを分析してパフォーマンス向上のためのマテリアライズドビュー作成を提案・実行したりできるようになりました。
何が嬉しいのか #
データ分析のワークフローがコード生成を超えて統合され、AWS内外のデータ探索、可視化、クエリ最適化をすべて自然言語で行えるようになります。特にSnowflakeとAWS Glue Data Catalogを跨いだ分析を単一のプロンプトで実行できるため、マルチクラウド環境でのデータ利活用が劇的に効率化されます。
これまでとどう変わるのか #
- これまで: ノートブックでの可視化にはPythonコード(MatplotlibやSeabornなど)を手動で書く必要がありました。また、外部データソースとの統合やクエリの最適化(マテリアライズドビューの検討)はデータエンジニアの専門的な知識と手作業に依存していました。
- これから: Data Agentとの対話を通じて、コーディングなしで可視化や最適化が完結します。エージェントがノートブックを分析して最適なマテリアライズドビューの作成や更新スケジュールの設定まで代行してくれます。
具体的なユースケース #
- 自然言語で「地域別の売上推移を折れ線グラフで表示して」と指示し、即座にビジネスレポート用の図を作成する。
- AWS上のデータとSnowflake上の顧客データを結合した複雑な分析を、SQLを意識せずに実行する。
- 頻繁に実行される重いクエリをエージェントに分析させ、自動的にマテリアライズドビューを作成してダッシュボードの応答速度を改善する。 \n—\n
Amazon CloudWatch が Query Studio (プレビュー) による PromQL クエリを導入 #
投稿日: 2026年04月03日
何ができるようになったのか #
Amazon CloudWatchに「Query Studio」がパブリックプレビューとして導入されました。これにより、CloudWatchコンソール上でネイティブなPromQL(Prometheus Query Language)を使用したメトリクスのクエリと可視化が可能になります。PromQLとCloudWatch Metric Insightsを一つのインターフェースで統合して利用でき、AWS提供のメトリクスとOpenTelemetryメトリクスの両方を好みの言語で分析できます。
何が嬉しいのか #
Prometheusのエコシステムに慣れ親しんだエンジニアが、言語を切り替えることなくCloudWatchのデータを分析できるようになります。オートコンプリート機能付きのビジュアルフォームビルダーや構文ハイライト付きのエディタが提供されるため、PromQLに不慣れなユーザーでも簡単に高度なクエリを作成でき、そのままアラーム作成やダッシュボードへの追加が可能です。
これまでとどう変わるのか #
- これまで: CloudWatchメトリクスの分析にはCloudWatch独自のクエリ言語やMetric Insightsを使用する必要がありました。OpenTelemetryで収集したメトリクスとAWS標準メトリクスをPromQLで横断的に分析するには、Managed Service for Prometheusなどの別サービスへの転送が必要な場合がありました。
- これから: CloudWatchコンソール内で直接PromQLが使えるようになり、既存のPrometheusスキルを活かしてAWS全域のモニタリングが可能になります。
具体的なユースケース #
- Amazon EC2で実行されているアプリケーションのカスタムOpenTelemetryメトリクスと、EC2標準のCPU使用率メトリクスをPromQLで並べて相関分析を行う。
- 既存のPrometheusダッシュボードのクエリをCloudWatchに持ち込み、統一された監視基盤を構築する。
- 複雑な集計が必要なメトリクスを、使い慣れたPromQLで迅速に可視化してトラブルシューティングに役立てる。 \n—\n
Apache Spark のトラブルシューティングとアップグレードエージェントが Kiro Powers として利用可能に #
投稿日: 2026年04月03日
何ができるようになったのか #
Amazon EMR向けのApache Sparkトラブルシューティングエージェントとアップグレードエージェントが、「Kiro powers」として提供開始されました。Kiro IDEからワンクリックでAI支援によるSpark運用が可能になります。トラブルシューティング機能では失敗したジョブのログやメトリクスを分析して根本原因を特定し、PySparkコードの修正案を提示します。アップグレード機能では、EMRのバージョン移行に伴うコード変換や依存関係の解決を自動化します。
何が嬉しいのか #
データエンジニアの運用負荷が劇的に軽減されます。これまで数時間かかっていたトラブルシューティングが数分に、数ヶ月かかっていたSparkのバージョンアップ作業が数週間に短縮されます。すべてのAIアクションはAWS CloudTrailに記録されるため、監査性も担保されています。
これまでとどう変わるのか #
- これまで: Sparkジョブの失敗原因を特定するには、複雑なログやドライバ/エグゼキュータのメトリクスを読み解く専門知識が必要でした。また、Sparkのメジャーバージョンアップ(例:EMR 6.xから7.x)は、コードの互換性チェックやデータ品質の検証に膨大な手作業が発生していました。
- これから: AIエージェントがログ分析やコード変換を代行します。リモート検証やデータ品質比較機能により、安全かつ迅速に最新のSpark環境へ移行できるようになります。
具体的なユースケース #
- 失敗したPySparkジョブの原因がメモリ不足(OOM)かコードの不備かをAIに即座に診断させ、提示された修正案を適用して再実行する。
- 複数のEMRクラスタを利用している環境で、最新のEMR 7.xへの移行作業をAIによる自動変換機能を使って一括で進める。
AWS Glue Schema Registry が新たに3つのリージョンで利用可能に #
投稿日: 2026年04月03日
何ができるようになったのか #
AWS Glue Schema Registryが、アジアパシフィック(ジャカルタ)、欧州(スペイン)、欧州(チューリッヒ)の3リージョンで利用可能になりました。これにより、これらのリージョンでもApache Avro、JSON、Protobuf形式を用いたストリーミングデータのスキーマ管理と検証をサーバーレスかつ無料で実行できます。
何が嬉しいのか #
データストリーミングシステムにおいて、アプリケーション間のデータ形式の不一致によるエラーを防ぐことができます。スキーマレジストリを利用することで、各アプリケーションにバリデーションロジックを実装する必要がなくなり、開発効率とデータの信頼性が向上します。MSK(Amazon Managed Streaming for Apache Kafka)、Kinesis Data Streams、Lambda、Flinkなどの主要なサービスとシームレスに統合可能です。
これまでとどう変わるのか #
- これまで: 対象の3リージョン(ジャカルタ、スペイン、チューリッヒ)では、スキーマ管理のために独自のレジストリを構築するか、他リージョンのエンドポイントを利用する必要があり、レイテンシや管理コストの面で課題がありました。
- これから: ローカルリージョンのフルマネージドなサービスとしてSchema Registryを利用でき、データガバナンスを維持しつつ低レイテンシなストリーミング処理が可能になります。
具体的なユースケース #
- ジャカルタリージョンで運用しているMSKクラスタにおいて、プロデューサーとコンシューマー間のデータ構造(Avroなど)を厳密に管理し、不正な形式のデータがパイプラインに混入するのを防ぐ。
- スペインリージョンのLambda関数でKinesisデータを処理する際、スキーマレジストリを参照して動的にデシリアライズを行い、柔軟なデータ処理を実装する。 \n—\n
AWS Secrets Manager コンソールがカスタム KMS キー ARN の入力をサポート #
投稿日: 2026年04月03日
何ができるようになったのか #
AWS Secrets Managerのマネジメントコンソールにおいて、シークレット作成時にAWS KMSキーのARN(Amazon Resource Name)を直接入力できるようになりました。これまではプルダウンリストから選択する形式のみでしたが、自由記述が可能になったことで、別アカウントのKMSキーなどを簡単に指定できるようになります。
何が嬉しいのか #
クロスアカウントでの暗号化ワークフローが簡素化されます。自アカウントのリストに表示されない外部アカウントのKMSキーを使用したい場合、これまではCLIやSDKを使用する必要がありましたが、今後はコンソール画面から直接設定可能です。
これまでとどう変わるのか #
- これまで: コンソールのドロップダウンリストには、現在のAWSアカウント内にあるカスタマー管理のKMSキーしか表示されませんでした。別アカウントのキーを使用するには、コマンドライン(AWS CLI)やプログラム(SDK)を介して作成する必要がありました。
- これから: コンソール上にARNの入力フィールドが追加されたため、別アカウントのキーARNをコピー&ペーストするだけで、簡単に暗号化設定を完了できます。APIの既存機能がコンソールにも反映された形となります。
具体的なユースケース #
- セキュリティ専用アカウントで集中管理しているKMSキーを使用して、開発用アカウントのシークレットを暗号化する。
- 複数のAWSアカウントを跨ぐ大規模なプロジェクトにおいて、共通の暗号化キーをコンソールから手軽に指定する。 \n—\n
Amazon Bedrock Guardrails がクロスアカウント保護機能の一般提供を開始 #
投稿日: 2026年04月03日
何ができるようになったのか #
Amazon Bedrock Guardrailsにおいて、組織内の全AWSアカウントに対してセキュリティ制御を一元的に適用できる「クロスアカウント保護機能」が一般提供(GA)されました。管理アカウントで設定したガードレールIDをBedrockポリシーに指定するだけで、組織単位(OU)や個別のアカウント全体に自動的に安全策を適用できます。
何が嬉しいのか #
中央のセキュリティチームや管理者が、組織全体の生成AI利用における安全基準を一括で管理できるようになります。有害なコンテンツのフィルタリングやハルシネーション(幻覚)の抑制といった制御を、アカウントごとに個別に設定する運用負荷がなくなります。組織レベルの共通ルールと、部門ごとの個別ルールを組み合わせて適用することも可能です。
これまでとどう変わるのか #
- これまで: ガードレールの設定はアカウントごとに行う必要がありました。組織全体に適用したい場合、CloudFormation StackSetsなどを使用して各アカウントに個別に配布・設定する手間が発生し、設定漏れのリスクもありました。
- これから: 管理アカウントからの単一のポリシー設定で、全メンバーアカウントのBedrock利用に対してガードレールを強制適用できます。これにより、全社共通の「AI安全ガイドライン」を技術的に担保することが容易になります。
具体的なユースケース #
- 企業内の全開発チームに対し、Amazon Bedrockを使用する際は必ず「社内規定の有害コンテンツフィルタ」が適用されるよう、管理アカウントから一括設定する。
- 特定の部門(OU)にはさらに厳しい個人情報保護フィルタを追加するなど、組織構造に合わせた階層的なセキュリティ制御を実装する。 \n—\n
Partner Revenue Measurement が一部サービスで User Agent 文字列をサポート #
投稿日: 2026年04月03日
何ができるようになったのか #
AWSパートナー向けの収益計測機能「Partner Revenue Measurement」において、User Agent文字列を利用した計測が可能になりました。パートナーは自社のソリューション(アプリケーション)が発行するAWS APIリクエストのUser Agentに、AWS Marketplaceのプロダクトコードを含む特定の形式(APN_1.1/pc_<プロダクトコード>$)を埋め込むことで、自社ソリューション経由のAWSリソース消費量を計測できるようになります。
何が嬉しいのか #
パートナー企業は、自社のプロダクトがどれだけのAWS売上に貢献しているかを正確に把握できるようになります。SDKの設定や環境変数の指定だけで自動的に付与できるため、既存のコードを大きく変更することなく導入可能です。Python, Node.js, Java, Kotlinなど主要なAWS SDKでサポートされています。
これまでとどう変わるのか #
- これまで: パートナーによる貢献度の計測には、主に「リソースタグ」の付与や「AWS Marketplace Metering」との統合が必要でした。タグ付けは全てのリソースに対して個別に行う必要があり、実装の負荷が高い場合がありました。
- これから: User Agent文字列という標準的なHTTPヘッダーを利用することで、APIベースのワークロードに対しても低コストで属性付与(アトリビューション)が可能になります。
具体的なユースケース #
- SaaS提供パートナーが、自社の管理ポータルから顧客のAWSアカウントに対してリソースを操作する際、User Agentを介して自社プロダクトの影響範囲を可視化する。
- パートナーが提供するSDKやライブラリにプロダクトコードを組み込み、そのライブラリを使用している全てのワークロードのAWS消費額を自動的にトラッキングする。