AWSの基礎力をつけるためにAWS What’s Newを毎日目を通す事を始めました。 最初は日本語訳されたものを見ていたのですが、1週間ほど遅れて訳されるようなので、英語の情報を訳して整理することにしました。
本情報が役立つ人もいるかなと思い公開します。 個人的な理解なので、実際の情報は原典をあたってください。
¥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 Connect がエージェントの画面録画ステータスの追跡機能を提供開始 #
投稿日: 2026年01月12日
何ができるようになったのか #
Amazon Connect で、Amazon EventBridge を使用して CloudWatch 上でエージェントの画面録画ステータスをほぼリアルタイムに確認できるようになりました。これには、録画の成功/失敗、失敗時のコードと説明、インストールされているクライアントのバージョン、エージェントのWebブラウザのバージョン、OS、録画の開始・終了時刻などの情報が含まれます。
何が嬉しいのか #
スーパーバイザーは、音声通話の録音やチャットの記録を確認するだけでなく、画面録画を通じてエージェントの操作内容を把握し、ビジネスプロセスの不遵守などのコーチングが必要な領域を特定できます。今回の機能追加により、録画自体のステータスを詳細に追跡できるため、録画が正しく行われているかどうかの監視やトラブルシューティングが容易になります。
これまでとどう変わるのか #
- これまで: 画面録画のステータスや詳細なメタデータ（失敗理由や環境情報など）をリアルタイムに一元的に把握・追跡する仕組みが限定的でした。
- これから: Amazon EventBridge の
Screen Recording Status Changedイベントをサブスクライブすることで、録画ステータスや関連情報を詳細かつ即座に追跡可能になります。
具体的なユースケース #
- コンタクトセンターの運用管理者が、全エージェントの画面録画が正常に行われているかを監視ダッシュボード（CloudWatch等）で確認する。
- 特定のエージェント環境で画面録画が失敗した場合、エラーコードやOS・ブラウザ情報を基に迅速に原因を特定する。
Amazon Inspector が Java Gradle のサポートを追加し、エコシステムの対象範囲を拡大 #
投稿日: 2026年01月12日
何ができるようになったのか #
Amazon Inspector による AWS Lambda 関数と Amazon Elastic Container Registry (ECR) イメージのスキャンにおいて、Java Gradle のインベントリおよび脆弱性スキャンがサポートされました。 また、MySQL、MariaDB、PHP、Jenkins-core、7zip (Windows版)、Elasticsearch、Curl/LibCurl も新たにスキャン対象に追加されました。
何が嬉しいのか #
Java アプリケーションの開発において広く使われている Gradle の依存関係（gradle.lockfile の内容に基づく）を正確に評価できるようになり、包括的な脆弱性評価が可能になります。また、主要なデータベースやツールがスキャン対象に追加されたことで、AWSワークロード全体のセキュリティ体制をより強化し、コンプライアンス要件を満たしやすくなります。
これまでとどう変わるのか #
- これまで: Java Gradle プロジェクトや、特定のミドルウェア・ツール（MySQL, PHP等）に対する脆弱性検出の範囲が限定的でした。
- これから: Inspector を使用して Lambda 関数や ECR イメージをスキャンする際、Gradle の依存関係に加え、今回追加されたパッケージ（パッケージマネージャー外でインストールされたものを含む）の脆弱性も検出できるようになり、より広範囲なアプリケーションと環境を保護できます。
具体的なユースケース #
- Gradle をビルドツールとして使用している Java ベースの Lambda 関数をデプロイする際、依存ライブラリに既知の脆弱性がないかを自動的にチェックする。
- ECR に保存されているコンテナイメージに含まれる MySQL や PHP などのコンポーネントに脆弱性がないかを継続的に監視する。
Amazon Lex が音声アクティビティ検出 (VAD) 感度の設定機能を提供開始 #
投稿日: 2026年01月12日
何ができるようになったのか #
Amazon Lex で、ボットのロケールごとに音声アクティビティ検出 (VAD) の感度を「Default（デフォルト）」、「High（高）」、「Maximum（最大）」の3つのレベルから設定できるようになりました。 設定は Amazon Connect の Conversational AI designer から行うことができます。
何が嬉しいのか #
これまでは周囲の騒音レベルによっては、ユーザーの発話を正しく検出できなかったり、ノイズを発話と誤認識したりすることがありました。今回のアップデートにより、利用環境の騒音レベルに合わせて最適な感度を選択できるため、より正確な音声認識とスムーズな会話体験を提供できるようになります。
これまでとどう変わるのか #
- これまで: VAD感度の調整オプションがなく、騒がしい環境では認識精度に課題が生じることがありました。
- これから: 環境に合わせて以下の設定を選択できます。
- Default: 一般的なバックグラウンドノイズレベルの環境向け。
- High: 忙しいオフィスや小売店など、継続的に中程度のノイズがある環境向け。
- Maximum: 製造現場、建設現場、騒音の激しい屋外など、非常にノイズが多い環境向け。
具体的なユースケース #
- 建設現場や工場で作業員が使用する音声ボットにおいて、周囲の騒音を無視して作業員の声だけを拾うように「Maximum」感度を設定する。
- 賑やかなショッピングモール内の案内キオスク端末で、利用者の声を確実に認識するために「High」感度を設定する。
Amazon Redshift Serverless が AWS アジアパシフィック (ニュージーランド) リージョンで利用可能に #
投稿日: 2026年01月12日
何ができるようになったのか #
Amazon Redshift Serverless が AWS アジアパシフィック（ニュージーランド）リージョンで一般利用開始（GA）となりました。
何が嬉しいのか #
データウェアハウスのクラスターをプロビジョニングしたり管理したりすることなく、データの分析を実行しスケールさせることができます。データアナリスト、開発者、データサイエンティストなど、あらゆるユーザーが Redshift を使用して数秒でデータからインサイトを得ることができます。 また、ワークロードの実行時間に応じた秒単位の従量課金となるため、コスト管理も効率化できます。
これまでとどう変わるのか #
- これまで: ニュージーランドリージョンでは Redshift Serverless が利用できず、プロビジョニングされたクラスターを使用するか、他のリージョンを利用する必要がありました。
- これから: 同リージョン内でサーバーレスアーキテクチャを活用したデータ分析基盤を構築できるようになり、データレジデンシー要件を満たしつつ、運用の簡素化とコスト最適化が可能になります。
具体的なユースケース #
- ニュージーランド国内にデータを保持する必要がある企業が、インフラ管理の負担を最小限に抑えつつ、大規模なデータ分析基盤を構築する。
- スパイク的なアクセスがある分析ワークロードに対して、自動スケーリング機能を活用してパフォーマンスとコストのバランスを最適化する。
Amazon SageMaker HyperPod コンソールでクラスター作成前にサービスクォータを検証するように #
投稿日: 2026年01月12日
何ができるようになったのか #
Amazon SageMaker HyperPod のマネジメントコンソールにおいて、クラスター作成を開始する前に、AWS アカウントのサービスクォータ（利用上限）が十分にあるかどうかを自動的に検証できるようになりました。
何が嬉しいのか #
大規模な AI/ML クラスターを作成する際、これまではインスタンス、ストレージ、ネットワークリソースなどのクォータを手動で確認する必要があり、確認漏れによって作成が失敗することがありました。 今回の機能追加により、インスタンスタイプの上限、EBSボリュームサイズ、VPC関連のクォータなどが自動チェックされ、不足している場合は警告とクォータ引き上げ申請へのリンクが表示されるため、手戻りを防ぎ、スムーズにクラスターを構築できます。
これまでとどう変わるのか #
- これまで: クォータの確認は手動で行う必要があり、作成プロセス開始後にクォータ不足でエラーになることがありました。
- これから: コンソール上で設定内容に基づいたクォータ消費予測と現在の上限値が比較検証され、事前に問題（不足）を把握できます。
具体的なユースケース #
- LLM（大規模言語モデル）の学習用に数百台規模の GPU インスタンスを含むクラスターを作成しようとする際、事前にそのリージョンでのインスタンス数の上限に達していないかを確認する。
- チームで共有しているAWSアカウントで新しい実験用クラスターを立ち上げる際、他のリソースによってクォータが圧迫されていないかを即座にチェックする。