本日の主なトピック #
- Amazon Quick の進化: QuickSight と Q Business が「Amazon Quick」として統合され、自然言語によるダッシュボード生成やデータセットへの直接質問 (Dataset Q&A) が可能になりました。
- SageMaker AI のエージェント機能: AI エージェントがモデルのカスタマイズ工程をガイドし、数ヶ月かかっていたワークフローを数時間に短縮します。
- Aurora DSQL の JSON サポート: 分散 SQL DB で PostgreSQL 互換の JSON 型がネイティブ利用可能になり、半構造化データの扱いが容易になりました。
- Entity Resolution の効率化: 機械学習マッチングの増分処理に対応し、データ更新時の処理時間を最大 95% 削減。
- EventBridge の可視性向上:
PutEventsAPI の呼び出しが CloudTrail でロギング可能になり、監査とトラブルシューティングが強化されました。
¥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 EventBridge が AWS CloudTrail へのデータプレーンロギングをサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon EventBridge のデータプレーン API（具体的には PutEvents）が AWS CloudTrail でロギングできるようになりました。これにより、イベントバスへのイベント送信リクエストの詳細（リクエスタの IP アドレス、ID、リクエスト日時など）を CloudTrail で把握可能になります。
何が嬉しいのか #
セキュリティ監査、コンプライアンス対応、および運用のトラブルシューティングにおいて、より高い透明性が得られます。「誰が、いつ、どのイベントを送信したか」を正確に追跡できるため、リスク管理やガバナンスの強化につながります。
これまでとどう変わるのか #
- これまで: EventBridge の CloudTrail ログは、イベントバスの作成やルールの設定などの「管理イベント」に限られていました。イベントの送信アクションである
PutEventsはデフォルトでは記録されず、詳細な追跡にはカスタムの実装が必要でした。 - これから: CloudTrail の設定で「データイベント」を有効にすることで、
PutEventsの呼び出しをネイティブに記録し、他の AWS サービスと同様の標準的な方法で監査できるようになります。
具体的なユースケース #
- セキュリティ監査: 特定の IP アドレスからの異常なイベント送信を調査する。
- 運用トラブルシューティング: イベントが届かない、または予期せぬイベントが発生した際、送信側のリクエストが正常に行われていたかを CloudTrail で確認する。
Amazon Quick が企業データに対する対話型分析「Dataset Q&A」を導入 #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon Quick（旧 Amazon QuickSight と Amazon Q Business の統合スイート）において、データセットに対して自然言語で直接質問できる「Dataset Q&A」機能が導入されました。ユーザーが質問を入力すると、内蔵の Text-to-SQL エージェントが意図を解釈し、最適な SQL を生成して、SPICE や Amazon Redshift、S3 Table Buckets (Apache Iceberg) などのデータソースから回答を導き出します。
何が嬉しいのか #
SQL の knowledge がないビジネスユーザーでも、日常会話のような自然言語でデータからインサイトを得られるようになります。行レベル・列レベルのセキュリティ (RLS/CLS) も尊重されるため、ガバナンスを維持したまま全社的なデータ活用を推進できます。また、「Explain」機能により、AI がどのように質問を解釈し SQL を生成したかの論理ステップを確認できるため、回答の信頼性も担保されます。
これまでとどう変わるのか #
- これまで: ダッシュボードが用意されていないデータについて知りたい場合、アナリストにクエリ作成を依頼するか、ユーザー自身が BI ツールの操作を習得して分析を作成する必要がありました。
- これから: データセットへのアクセス権さえあれば、誰でも即座に複雑なトレンド分析や比較、探索的な質問を投げかけ、数秒で回答を得ることができます。
具体的なユースケース #
- アドホックな売上分析: 「先月の地域別の売上成長率を、前年同期と比較してランキング形式で教えて」といった具体的な質問への即答。
- データ探索の効率化: 新しいデータセットの傾向を掴むために、様々な角度から自然言語で質問を投げかけ、分析の足掛かりにする。
Amazon Quick は「Amazon Quick Suite」の略称です。 2025年後半に Amazon QuickSight と生成AIアシスタントの Amazon Q Business が統合され、現在のブランド名称になりました。 主な特徴は以下の通りです。
- BI（視覚化）と生成AIによる対話型分析のシームレスな統合
- 企業内データのナレッジベース（旧 Amazon Q Index）との連携
- 自然言語によるダッシュボード生成やワークフロー自動化
Amazon Quick が自然言語プロンプトからのダッシュボード自動生成をサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon Quick の「Generate Analysis」機能により、自然言語のプロンプト（指示文）からダッシュボード全体を自動生成できるようになりました。ユーザーが達成したい目標（例：「収益トレンド、地域比較、前月比成長を含む売上パフォーマンスダッシュボードを作成して」）を記述し、最大3つのデータセットを選択するだけで、AI が最適なビジュアル、フィルター、計算フィールド（YoY 成長など）を配置したシートを作成します。
何が嬉しいのか #
ダッシュボードの構築にかかる時間を、数時間から数分へと劇的に短縮できます。生成された内容は編集可能であり、既存のパブリッシングフローや CI/CD パイプラインにも統合できるため、プロトタイプ作成から本番デプロイまでを加速させます。
これまでとどう変わるのか #
- これまで: グラフ一つひとつを手動で構成し、計算式を設定し、レイアウトを調整する膨大な手作業が必要でした。
- これから: 意図を伝えるだけで AI が初稿を完成させ、作成者は微調整と洗練に集中できるようになります。
具体的なユースケース #
- 迅速なレポート作成: 会議直前に新しい視点でのデータ視覚化が必要になった際、プロンプト入力だけで即座にダッシュボードを用意する。
- 分析の自動化: 定型的な KPI ダッシュボードの構築を AI に任せ、データサイエンティストがより高度な分析業務に専念できる環境を作る。
Amazon Quick エクステンション for Microsoft Outlook がアップグレード（プレビュー） #
投稿日: 2026年05月04日
何ができるようになったのか #
Microsoft Outlook 内で Amazon Quick の生成AI機能を利用できるエクステンションがアップグレードされました。メールやカレンダーのワークフローに直接 AI が組み込まれ、未読メッセージの要約、受信トレイの整理、会議のスケジューリング、文脈に応じた返信の下書きなどを自然言語で行えるようになります。
何が嬉しいのか #
Outlook を離れることなく、Amazon Quick のナレッジベースやスペースにある関連情報を引き出しながら業務を遂行できます。メールのスレッドからアクションアイテムを抽出したり、同僚との最適な会議時間を自動で見つけたりすることで、生産性が大幅に向上します。
これまでとどう変わるのか #
- これまで: メールの内容を確認して社内のデータを確認し、カレンダーを調整して返信を書くという作業を、複数のツールを行き来しながら手動で行っていました。
- これから: Outlook 内のチャットインターフェースを通じて指示を出すだけで、AI がこれらのステップを代行し、外部アプリケーションとの連携アクションも実行可能になります。
具体的なユースケース #
- 多忙な時間の情報集約: 溜まったメールスレッドを一括要約し、重要なネクストアクションを特定する。
- データに基づいた顧客対応: Amazon Quick に蓄積された最新の分析データを引用しながら、Outlook 上で即座に顧客への回答案を作成する。
Amazon SageMaker AI がモデルカスタマイズのための AI エージェント体験を導入 #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon SageMaker AI に、モデルのカスタマイズ（ファインチューニングや評価）を劇的に効率化する AI エージェント体験が導入されました。開発者は自然言語でコーディングエージェント（Kiro、Claude Code、CoPilot など）と対話し、ユースケースの定義からデータ準備、モデル選択、実験の実行、評価、そして本番デプロイまでの全工程をガイド付きで進めることができます。
何が嬉しいのか #
従来、数ヶ月かかっていたモデルのカスタマイズプロセスが、数日あるいは数時間で完了できるようになります。エージェントはデータ形式の変換、LLM-as-a-judge による品質評価、Bedrock や SageMaker への柔軟なデプロイオプションなどの専門知識を提供し、再利用・編集可能なコードを生成するため、プロセスの透明性と再現性も確保されます。
これまでとどう変わるのか #
- これまで: インフラのセットアップ、データの整形、複数のモデルやチューニング手法の試行錯誤、複雑な評価指標の設計など、膨大な「差別化につながらない重労働」を手動でこなす必要がありました。
- これから: 使い慣れた IDE (VS Code, Cursor 等) や SageMaker Studio Notebooks からエージェントを呼び出すだけで、最適なワークフローを自動構築し、高品質なモデルを迅速に生産投入できます。
具体的なユースケース #
- 特化型 LLM の迅速な開発: 自社独自のドメイン知識を Amazon Nova や Llama などのモデルに学習させる際、データ準備から評価までを AI エージェントに伴走してもらう。
- AIOps パイプラインの自動化: エージェントが生成したコードを既存のパイプラインに統合し、モデルの継続的な改善とデプロイを自動化する。
Amazon SageMaker AI が容量を考慮した推論と自動インスタンスフォールバックをサポート #
投稿日: 2026年05月01日
何ができるようになったのか #
Amazon SageMaker AI の推論エンドポイントにおいて、複数のインスタンスタイプを優先順位リストとして指定できるようになりました。優先度の高いインスタンスの容量（キャパシティ）が不足している場合、SageMaker AI はリスト内の次の利用可能なインスタンスを自動的にプロビジョニングします。これにより、エンドポイントの作成、更新、およびオートスケーリングが容量制限に阻害されることなく、スムーズに進行します。
何が嬉しいのか #
生産環境で AI/ML モデルをデプロイする際、特定のインスタンスタイプの在庫不足によってエンドポイントの起動やスケーリングが失敗するリスクを大幅に軽減できます。手動での介入なしに耐障害性の高いインフラ構成を実現でき、スケーリングダウン時には優先度の低いインスタンスから削除されるため、コストとパフォーマンスの最適化も自動で行われます。
これまでとどう変わるのか #
- これまで: エンドポイント作成時に指定したインスタンスタイプの容量が不足していると、エラーが発生してデプロイが失敗していました。また、スケーリング時も特定のインスタンスに依存していたため、在庫状況によって柔軟な対応が困難でした。
- これから: 優先順位に基づいたインスタンスプールを定義でき、在庫不足時には自動で代替インスタンスが使用されます。インスタンスタイプごとに異なる最適化モデルを割り当てることも可能です。
具体的なユースケース #
- バースト性の高いワークロード: 急激なトラフィック増大に合わせて迅速にスケーリングが必要な際、優先インスタンスが足りなくても代替インスタンスでサービスを継続する。
- コスト最適化と可用性の両立: 低コストなインスタンスを優先しつつ、不足時にはより高機能なインスタンスで確実にエンドポイントを維持する。
Amazon Aurora DSQL が JSON データ型と圧縮をサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
分散 SQL データベースである Amazon Aurora DSQL が、PostgreSQL 互換の JSON データ型をネイティブにサポートしました。また、オプションで圧縮機能も利用可能です。これにより、API ペイロードや設定オブジェクト、イベントログなどの半構造化データを、リレーショナルデータと並べて直接保存・操作できるようになります。
何が嬉しいのか #
PostgreSQL の JSON 型に依存する既存のコードやツールを、修正なしで Aurora DSQL 上で動作させることができます。また、デフォルトで有効な圧縮機能により、大きな JSON ペイロードを効率的に保存でき、ストレージコストの削減にも貢献します。
これまでとどう変わるのか #
- これまで: Aurora DSQL の初期リリース（2024年12月）時点では、
json型はネイティブなストレージ型としてサポートされておらず、text型（最大 1 MiB）で代用し、クエリ時にキャストして利用する必要がありました。 - これから:
json型として直接列を定義でき、スキーマの柔軟性が向上します。また、圧縮により実質的に 1 MiB を超えるような大きな JSON データも扱いやすくなります。
具体的なユースケース #
- スキーマレスな属性の保存: Eコマースの製品メタデータやユーザー設定など、頻繁に構造が変わるデータをリレーショナルテーブルの一部として柔軟に管理する。
- ログデータの集約: アプリケーションから出力される JSON 形式のログを、高いスケーラビリティを持つ Aurora DSQL に直接流し込み、検索や分析を行う。
AWS Entity Resolution が機械学習ベースの増分マッチングをサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
AWS Entity Resolution において、機械学習 (ML) ベースのマッチングワークフローで「増分（インクリメンタル）処理」が一般提供 (GA) となりました。これにより、前回の実行以降に追加された新しいレコードのみを対象にマッチング処理を実行できるようになります。
何が嬉しいのか #
データ処理の効率が劇的に向上し、コストと時間を大幅に削減できます。100万件の増分レコードの処理を1時間未満で完了でき、従来の全件再処理と比較して処理時間を約95%削減可能です。最大10億件の履歴レコードを持つデータセットに対し、最大5,000万件の増分レコードを処理できるため、大規模かつ継続的なデータ統合が現実的なコストで実現します。
これまでとどう変わるのか #
- これまで: たった1件の新しいレコードを追加する場合でも、データセット全体を再処理する必要がありました。このため、大規模なデータセットでは処理に最大2日かかったり、高額なインフラ費用が発生したりするボトルネックが存在していました。
- これから: 新規データのみを効率的に処理できるため、ほぼリアルタイム、あるいは頻繁なデータ更新が可能になり、常に最新の「顧客の単一ビュー」を維持できます。
具体的なユースケース #
- 継続的な顧客データ統合: 毎日流入する数百万件の新しい顧客データを、既存の巨大なマスターデータと低コストで照合し、重複排除を維持する。
- リアルタイム・マーケティング: 新しく登録されたユーザーが既存の顧客と同一人物かを迅速に特定し、即座にパーソナライズされた体験を提供する。
AWS IoT Core が AWS GovCloud (US) リージョンでカスタムドメインをサポート #
投稿日: 2026年04月30日
何ができるようになったのか #
AWS GovCloud (US) リージョンにおいて、AWS IoT Core でカスタマー管理ドメイン（カスタムドメイン）が利用可能になりました。これにより、独自のドメイン名を設定し、AWS Certificate Manager (ACM) に保存された独自のサーバー証明書を使用したり、カスタムオーソライザーをアタッチしたり、複数のデータエンドポイントを作成したりできるようになります。
何が嬉しいのか #
デバイスの展開において、TLS 動作やドメイン名、信頼チェーンの長期的な安定性を確保できます。既存のデバイス群を AWS IoT Core に移行する際、デバイス側の設定（ドメイン名や認証方法）を変更せずに済むため、現場にあるデバイスのソフトウェアアップデートを最小限に抑え、スムーズな移行が可能になります。
これまでとどう変わるのか #
- これまで: GovCloud リージョンでは AWS が提供するデフォルトのドメイン名を使用する必要があり、独自ドメインによるエンドポイント管理には制限がありました。
- これから: 商用リージョンと同様にカスタムドメインが利用可能になり、柔軟なフリート管理と容易な移行パスが提供されます。
具体的なユースケース #
- 既存デバイスの AWS 移行: 既に独自のドメインを参照している大量の IoT デバイスを、ファームウェア変更なしで AWS IoT Core へ接続先を切り替える。
- マルチテナント・異種フリート管理: デバイス群ごとに異なるドメイン設定を適用し、セキュリティや運用ポリシーを分離する。
AWS Payment Cryptography が機密操作のマルチパーティ承認 (MPA) に対応 #
投稿日: 2026年04月30日
何ができるようになったのか #
AWS Payment Cryptography (APC) が AWS マルチパーティ承認 (MPA) と統合されました。これにより、ルート証明書のインポートなどの極めて重要なキー管理操作に対して、2名以上の権限を持つ担当者による承認を必須とするプロセスを構築できるようになります。
何が嬉しいのか #
特権ユーザー一人による誤操作や不正な変更を防ぎ、強力なガバナンスを実現できます。たとえ一人の担当者が IAM 権限を持っていたとしても、承認ポータルを通じた複数人のレビューを経て初めて操作が反映されるため、決済インフラの信頼チェーンにおける単一障害点（人的要因）を排除できます。
これまでとどう変わるのか #
- これまで: 適切な IAM 権限を持つ個人であれば、ルート証明書のインポートなどの機密操作を単独で実行することが可能でした。組織的なチェック機能を強制するには、外部のプロセスやカスタムの実装が必要でした。
- これから: AWS のネイティブ機能として MPA を有効化でき、IAM Identity Center と連携した標準的な承認フローにより、透明性と安全性の高い運用が提供されます。
具体的なユースケース #
- 厳格なコンプライアンス維持: PCI PIN や P2PE などの規格に基づき、重要キーの操作に「二人制」のルールを厳格に適用する。
- ルート証明書の更新管理: 決済ネットワークの信頼の基盤となるルート証明書の変更を、複数のセキュリティ責任者が確認した上で実行する。
AWS Payment Cryptography がリソースベースポリシーによるクロスアカウント共有をサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
AWS Payment Cryptography において、リソースベースポリシー (RBP) を使用したクロスアカウントでのキー共有が可能になりました。これにより、ある AWS アカウントで作成・管理されている暗号キーを、自社内の別アカウントや外部のパートナーアカウントから直接利用できるようになります。
何が嬉しいのか #
マルチアカウント構成におけるキー管理が大幅に簡素化されます。複数のアカウントで同じキー素材を重複して保持（インポート/エクスポート）する必要がなくなり、単一のマスターキー素材に対してきめ細かなアクセス制御を行えるため、キーのライフサイクル管理と監査の透明性が向上します。
これまでとどう変わるのか #
- これまで: アカウントをまたいで暗号化操作を行うには、各アカウントにキーをインポートするか、複雑なワークフローを構築する必要がありました。これにより、キーの同一性維持やアクセス制御の管理が煩雑になる課題がありました。
- これから: 単一のキー素材を「参照」する形でクロスアカウントアクセスを許可でき、PCI DSS 等のガイドラインに準拠したセキュアなマルチアカウント運用が容易になります。
具体的なユースケース #
- 共通決済プラットフォームの提供: 中央のセキュリティアカウントで管理するキーを、個別のビジネスユニットやアプリケーションアカウントから安全に呼び出して決済処理を行う。
- パートナー企業とのセキュアな連携: 外部パートナーに対し、特定のキーに対する制限された操作権限のみを付与し、安全にデータを共有・処理する。
Amazon Quick がデータソースとして S3 Tables バケットをサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon Quick（Amazon Quick Suite）が、Amazon S3 Tables をデータソースとして正式にサポートしました。これにより、S3 Tables バケットに保存された Apache Iceberg 形式のテーブルに対して、中間のデータウェアハウスや OLAP レイヤーを介さず、直接ダッシュボードの構築や自然言語による対話型分析（Dataset Q&A）を実行できるようになります。
何が嬉しいのか #
データアーキテクチャを大幅に簡素化でき、データレイク（レイクハウス）上の最新データに対してほぼリアルタイムにインサイトを得ることが可能になります。Salesforce や SAP から S3 Tables への Zero-ETL 統合と組み合わせることで、パイプラインの複雑さを排除しつつ、生成AIを活用したエージェント的な分析ワークフローをデータソースに対して直接適用できます。
これまでとどう変わるのか #
- これまで: S3 上のデータ（Iceberg 含む）を QuickSight 等で分析する場合、一度 Athena や Redshift Spectrum などを経由させるか、SPICE にデータをロードする必要がありました。
- これから: S3 Tables を直接参照先として指定でき、データレイクを「信頼できる唯一の情報源（Source of Truth）」として、BI と生成AIの両面からダイレクトに活用できるようになります。
具体的なユースケース #
- レイクハウスのリアルタイム可視化: S3 Tables に集約された最新のビジネスメトリクスを、追加の移動コストなしで即座にダッシュボードへ反映する。
- データレイクに対する対話型質問: Dataset Q&A を通じて、S3 上の膨大な Iceberg テーブルに対して自然言語で直接質問を投げかけ、回答を得る。
Amazon S3 Tables は re:Invent 2024 で発表された、分析ワークロード向けに最適化された S3 の新しいバケットタイプです。 主な特徴は以下の通りです。
- Apache Iceberg 形式をネイティブサポート
- ファイルのコンパクション（統合）などのメンテナンスを AWS が自動実行
- 従来の S3 上のテーブルと比較してクリスループットが最大3倍、TPS が最大10倍向上
Amazon RDS for SQL Server が M8i および R8i インスタンスをサポート #
投稿日: 2026年05月04日
何ができるようになったのか #
Amazon RDS for SQL Server において、最新の M8i および R8i インスタンスタイプが利用可能になりました。これらのインスタンスは、AWS 専用のカスタム Intel Xeon 6 プロセッサを搭載しており、クラウド内の同等の Intel プロセッサの中で最高のパフォーマンスと高速なメモリ帯域幅を提供します。
何が嬉しいのか #
第7世代の Intel ベースのインスタンスと比較して、価格パフォーマンスが最大 15% 向上し、メモリ帯域幅は 2.5 倍に拡大します。データベースの負荷が高いワークロードにおいて、より低コストで高いスループットと応答性を実現できます。
これまでとどう変わるのか #
- これまで: 第7世代の M7i/R7i インスタンスが Intel ベースの最新オプションでしたが、さらなる高負荷や高速なメモリ処理が必要なケースにおいて、ハードウェアの制約がありました。
- これから: 第8世代の Intel インスタンスを選択することで、同じ構成でもより高いパフォーマンスを得る、あるいはインスタンスサイズを下げてコストを最適化することが可能になります。
具体的なユースケース #
- 大規模な ERP/CRM システム: 大量の同時アクセスと複雑なクエリが発生する SQL Server 環境の安定稼働と高速化。
- データ集計ワークロード: 広いメモリ帯域幅を活かして、大量のデータをメモリ上で高速にスキャン・集計するバッチ処理。