フォーム読み込み中
2025年12月1日掲載
Amazon Quick Suite Embedded Chat が利用可能に
Amazon Quick Suite Embedded Chat の一般提供が開始されました。これにより、構造化データと非構造化知識を1つの会話に統合する Quick Suite の会話型AIをアプリケーションに直接埋め込むことができ、会話型インターフェース、オーケストレーションロジック、データアクセスレイヤーをゼロから構築する必要がなくなります。
Quick Suite Embedded Chat は、ユーザーが別のツールではなく、作業している場所で答えを求めているという根本的な問題を解決します。CRM、サポートコンソール、分析ポータルなど、どこにいても、即時かつ文脈に沿った応答が必要です。ほとんどの会話型ツールは、構造化データかドキュメント、分析かナレッジベース、質問への回答かアクションの実行のいずれかに優れていますが、その全てに対応することは稀です。Quick Suite はこのギャップを埋めます。これにより、ユーザーは埋め込みチャットを離れることなく、1つの連続した会話の中でKPIを参照したり、ファイルから詳細を取得したり、お客さまのフィードバックを確認したり、アクションをトリガーしたりできます。
Embedded Chat は、1-click embedding または既存の認証を持つ登録ユーザー向けの API-based iframes を介した簡単な統合により、この統一されたエクスペリエンスをアプリケーションにもたらします。コネクターを介してエージェンティック チャットをデータに接続し、SharePoint やWebサイトの検索、Slack メッセージの送信、Jira タスクの作成が可能です。また、ブランドカラー、コミュニケーションスタイル、パーソナライズされた挨拶でエージェントをカスタマイズできます。エージェントがアクセスするものや、全てのアクションのスコープを明示的に指定することで、セキュリティは常にお客さまの管理下に置かれます。
Quick Suite Embedded Chat は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、ヨーロッパ (アイルランド) の AWS リージョンで利用可能で、今後数カ月でほかの AWS リージョンにも拡大される予定です。Quick Suite Embedded Chat に追加費用はかかりません。
OpenSearch Service が、新しい PPL エクスペリエンスでログ分析を強化
Amazon OpenSearch Service のログ分析機能が強化され、OpenSearch UI の 可観測性 ワークスペースで Piped Processing Language (PPL) と自然言語がデフォルトのエクスペリエンスになりました。このアップデートは、実績のあるパイプライン構文と簡素化されたワークフローを組み合わせることで直感的な可観測性体験を提供し、お客さまが増大するデータ量をコストを管理しながら分析できるよう支援します。
新しいエクスペリエンスには、詳細な分析、ファセット検索、自然言語クエリのための35以上の新しいコマンドが含まれており、お客さまがインフラ、セキュリティ、ビジネスメトリクスにわたってより深いインサイトを得るのに役立ちます。この機能強化により、お客さまは使い慣れたパイプライン構文を使用しながら高度な分析機能を活用して、ログ分析ワークフローを効率化できます。このソリューションには、エンタープライズグレード のクエリ機能が含まれており、自然言語を使用した高度なイベント相関分析をサポートすることで、チームが有意義なパターンをより迅速に発見できるよう支援します。
ユーザーは単一のインターフェース内でクエリから可視化へシームレスに移行できるため、問題の検出と解決にかかる平均時間が短縮されます。管理者は、AWS コンソールの OpenSearch の Get Started ワークフローを使用して、エンドツーエンドの OpenTelemetry ソリューションを迅速に構築できます。この統合されたワークフローには、OpenTelemetry データ用の OpenSearch Ingestion パイプラインが標準で含まれているため、チームは迅速に利用を開始できます。
Amazon OpenSearch UI は、次の AWS リージョンで利用可能です: 米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (大阪)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (フランクフルト)、欧州 (パリ)、欧州 (ストックホルム)、欧州 (ミラノ)、欧州 (スペイン)、欧州 (チューリッヒ)、南米 (サンパウロ)、カナダ (中部)。
Amazon Redshift がマルチウェアハウスアーキテクチャーにまたがるフェデレーション権限をサポート
Amazon Redshift が、複数の Redshift データウェアハウスにまたがる権限管理を簡素化するフェデレーション権限をサポートするようになりました。お客さまは、ワークロードのスケーリングと分離のためにマルチウェアハウスアーキテクチャーを採用しており、ウェアハウス間で一貫したシンプルな権限管理を求めています。
Redshift のフェデレーション権限を使用すると、いずれかの Redshift ウェアハウスから一度データ権限を定義するだけで、アカウント内の全てのウェアハウスで自動的に適用されます。フェデレーション権限を持つ Amazon Redshift ウェアハウスは、全ての Redshift ウェアハウスに自動マウントされ、既存の AWS IAM Identity Center のIDや IAM ロールを使用して、ウェアハウスを横断してデータをクエリできます。
どのウェアハウスを使用してクエリを実行しても、行レベル、列レベル、マスキングの制御が常に自動的に適用され、きめ細かいアクセスコンプライアンスが実現されます。利用を開始するには、Redshift Serverless 名前空間または Redshift プロビジョニング済みクラスターを AWS Glue Data Catalog に登録し、Redshift Query Editor V2 またはサポートされている SQL クライアントを使用してウェアハウスを横断したクエリを開始します。
新しいウェアハウスを追加してもガバナンスの複雑さが増すことなく、複数のウェアハウスによる水平方向のスケーラビリティが得られます。新しいウェアハウスは自動的に権限ポリシーを適用し、アナリストは登録されたウェアハウスの全てのデータベースを即座に確認できます。Amazon Redshift のフェデレーション権限は、サポートされている AWS リージョンで追加費用なしで利用できます。
Amazon Quick Suite が Quick Flows のスケジューリングを導入
Amazon Quick Flows がスケジューリングをサポートし、手動介入なしで反復的なワークフローを自動化できるようになりました。Quick Flows を日次、週次、月次、またはカスタムの間隔で自動実行するように設定できるため、運用効率が向上し、重要なタスクの一貫した実行が保証されます。
この機能は、ダッシュボードからの定期的なリポート生成、外部サービスで割り当てられたオープンアイテムの要約、日々の会議のブリーフィング作成といった、定型的な管理タスクの自動化に役立ちます。自分で作成したフローでも共有されたフローでも、アクセス権があればスケジュールできます。
Quick Flows のスケジューリングは、米国東部(バージニア北部)、米国西部(オレゴン)、欧州(アイルランド)で利用可能です。スケジュール実行の利用には、標準の Quick Flows の利用料金に加えて追加料金は発生しません。
Amazon OpenSearch Service が OpenSearch バージョン 3.3 をサポート
Amazon OpenSearch Service で OpenSearch バージョン 3.3 を実行できるようになりました。OpenSearch 3.3 では、検索パフォーマンスや 可観測性 といった分野でいくつかの改善が導入され、エージェント型 AI 統合をよりシンプルかつ強力にする新機能が追加されています。
今回のアップデートには、ベクトル検索機能に関するいくつかの改善が含まれています。まず、エージェント検索により、複雑なドメイン固有言語 (DSL) クエリを構築することなく、自然言語入力を使用して正確な検索結果を得られるようになりました。次に、セマンティックハイライターのバッチ処理は、オーバーヘッドのレイテンシーを削減し、GPU 使用率を向上させることでパフォーマンスを改善します。最後に、Neural Search プラグインの機能強化により、セマンティック検索がより効率的になり、特定のデータ、パフォーマンス、関連性のニーズに合わせた最適化オプションが提供されます。
また、PPL のデフォルトクエリエンジンとして Apache Calcite のサポートも導入され、最適化機能、クエリ処理効率の向上、新しい PPL コマンドと関数の豊富なライブラリが提供されます。さらに、近似フレームワークの機能強化により、ページ分割された検索結果、リアルタイムダッシュボード、大規模な時系列データセットや数値データセットを介した深いページネーションを必要とするアプリケーションの応答性が向上します。
ワークロード管理プラグインにより、検索トラフィックをグループ化し、ネットワークリソースを分離できるようになりました。これにより、特定のリクエストによるネットワークリソースの過剰使用を防ぎ、テナントレベルの分離を提供します。
OpenSearch 3.3 は、Amazon OpenSearch Service が利用可能な全ての AWS リージョンで利用できます。
Amazon OpenSearch Service が Agentic Search を発表
Amazon OpenSearch Service で Agentic Search が利用可能になりました。これは、インテリジェントなエージェント駆動の検索により、お客さまのデータ操作方法を一新する機能です。Agentic Search は、お客さまの意図を理解し、ツールを調整して OpenSearch DSL (ドメイン固有言語) クエリを生成し、シンプルな agentic クエリ句と自然言語検索を通じて、意思決定プロセスを透明性高く要約するインテリジェントなエージェント駆動システムです。
Agentic Search は OpenSearch のクエリ計画と実行を自動化するため、複雑な検索構文は不要になります。お客さまは、「3万ドル以下の赤い車を探して」や「前四半期の売上トレンドを表示して」のように自然言語で質問できます。エージェントは意図を解釈し、最適な検索戦略を適用し、その推論プロセスを説明しながら結果を提供します。
この機能は、複雑な対話を処理して会話をメモリに保存できる conversational agents と、効率的なクエリ処理のための flow agents の2種類のエージェントを提供します。組み込みの QueryPlanningTool は、大規模言語モデル (LLM) を使用して DSL クエリを作成するため、技術的な専門知識がなくても検索を利用できます。
お客さまは、API または OpenSearch Dashboards を通じて Agentic Search を管理し、エージェントの設定や変更ができます。Agentic Search の高度な設定では、外部の MCP サーバーへの接続やカスタム検索テンプレートの使用が可能です。
Agentic Search は、OpenSearch Service が利用可能な全ての AWS 商用 および AWS GovCloud (US) リージョンにおいて、OpenSearch Service バージョン 3.3 以降でサポートされます。AI Search Flows プラグインで利用可能な新しい Agentic Search ユースケースを使用して、エージェントを構築し、agentic search を実行できます。
Amazon Kinesis Video Streams が、コスト効率に優れた新しいウォームストレージティアをサポート
Amazon Kinesis Video Streams (Amazon KVS) に、メディアの長期保持をコスト効率よく実現する新しいウォームストレージティアが追加されました。既存の標準ストレージティアは「ホットティア」と名称変更され、リアルタイムのデータアクセスと短期保存に最適化されています。新しいウォームティアは、ストレージコストを削減しつつ、1秒以内のアクセスレイテンシーでメディアを長期保持できます。
このウォームストレージティアにより、ホームセキュリティやエンタープライズビデオ監視ソリューションの開発者は、ビデオ分析や規制遵守のために保持期間を延長しながら、デバイス、カメラ、携帯電話からのデータをコスト効率よくストリーミングできます。また、開発者は要件に応じてフラグメントサイズを柔軟に設定できるようになり、低レイテンシーのユースケースには小さいフラグメントを、取り込みコスト削減には大きいフラグメントを選択できます。
ホットとウォームの両ストレージティアは、Amazon Rekognition Video および Amazon SageMaker とシームレスに統合されており、コンピュータービジョンやビデオ分析アプリケーション作成のための継続的なデータ処理をサポートします。
新しいウォームストレージティアを備えた Amazon Kinesis Video Streams は、AWS GovCloud (US) リージョンを除く、Amazon Kinesis Video Streams が利用可能な全てのリージョンで利用可能です。
Amazon EMR と AWS Glue が、AWS Lake Formation のきめ細かいアクセス制御による書き込み操作をサポート
Amazon EMR と AWS Glue で、Apache Spark ジョブにおいて AWS Lake Formation に登録されたテーブルに対する読み取りと書き込みの両方の操作で、きめ細かいアクセス制御 (FGAC) を強制できるようになりました。以前は、読み取り操作 (SELECT, DESCRIBE) にのみ Lake Formation のテーブル、列、行レベルの権限を適用できました。
今回のアップデートにより、単一の Spark ジョブで読み取りと書き込みの両方のタスクを実行できるようになり、データワークフローが簡素化され、個別のクラスターやアプリケーションが不要になります。組織は、一貫したセキュリティ制御でエンドツーエンドのデータワークフローを実行できるようになり、運用を合理化し、インフラコストを削減できます。
管理者は DML 操作 (CREATE, ALTER, INSERT, UPDATE, DELETE, MERGE INTO, DROP) を通じて、誰が新しいデータの挿入、特定のレコードの更新、変更のマージを許可されているかを制御できます。これにより、全てのデータ変更が指定されたセキュリティポリシーに準拠するため、不正なデータ変更や誤用のリスクが軽減されます。AWS Lake Formation でアクセスルールを単一の場所で定義し、Spark で読み取りと書き込みの両方の操作に対してこれらのルールを強制することで、データガバナンスとセキュリティフレームワークが簡素化されます。
この機能は、Amazon EMR (EC2, EKS, Serverless)、AWS Glue、AWS Lake Formation が利用可能な全ての AWS リージョンで利用できます。
Amazon EMR と AWS Glue が Lake Formation との連携における監査コンテキストをサポート
Amazon EMR と AWS Glue が、AWS Lake Formation の認証情報発行 API と AWS Glue Data Catalog の GetTable および GetTables API 呼び出しに対する包括的な監査コンテキストをサポートするようになりました。この監査機能は、デジタル市場法 (DMA) やデータ保護規制などの規制フレームワークへのコンプライアンス維持に役立ちます。この機能はデフォルトで有効になっており、既存のワークフローにシームレスに統合され、データレイクインフラ全体のセキュリティとコンプライアンス監視を強化します。
この監査コンテキスト情報は AWS CloudTrail ログで確認でき、EMR for Apache Spark のネーティブなきめ細かいアクセスコントロール (FGAC) とフルテーブルアクセスジョブにおいて、セキュリティ監査、規制コンプライアンス、トラブルシュートの強化を可能にします。監査ログ機能は、プラットフォームタイプ (EMR-EC2, EMR on EKS, EMR Serverless, または AWS Glue) と、それに対応する Cluster ID, Step ID, Job Run ID, Virtual Cluster ID などの識別子を自動的に記録します。
これにより、セキュリティチームは個々の Spark ジョブからの API 呼び出しを追跡・関連付け、コンプライアンスリポート作成を合理化し、過去のデータアクセスパターンを分析できます。さらに、データエンジニアは、アクセス関連の問題を特定のジョブ実行に結びつけて迅速にトラブルシュートしたり、FGAC の権限に関する課題を解決したり、異なるコンピューティングプラットフォーム間のアクセスパターンを監視したりできます。
この機能は、Amazon EMR, AWS Glue, AWS Lake Formation をサポートする全ての AWS リージョンで利用可能で、EMR バージョン 7.12 以降または AWS Glue バージョン 5.1 以降が必要です。
AWS が Apache Iceberg V3 の deletion vectors と row lineage をサポート
AWSは、Apache Iceberg Version 3 (V3) 仕様で定義されている deletion vectors と row lineage をサポートするようになりました。これらの新機能は、Apache Spark on Amazon EMR 7.12、AWS Glue、Amazon SageMaker notebooks、Amazon S3 Tables、および AWS Glue Data Catalog で利用できます。
これらの Iceberg V3機能は、お客さまがペタバイト規模のデータレイクを構築する際に役立ち、データ変更のパフォーマンス向上と、変更されたレコードを容易に追跡する機能を提供します。deletion vectors は、最適化された削除ファイルを書き込むことでデータパイプラインを高速化し、データ圧縮コストを削減します。row lineage は、各レコードにメタデータフィールドを提供することで、単純なSQLクエリによる変更追跡を可能にし、大規模テーブルでの小さな変更を見付けるための計算コストを不要にします。
V3テーブルを作成するには、Spark または SageMaker notebook の CREATE TABLE コマンドでテーブルプロパティを 「format-version = 3」 に設定します。既存のテーブルをアップグレードするには、メタデータのテーブルプロパティを新しいフォーマットバージョンで更新します。これにより、V3をサポートするAWSクエリエンジンは、自動的に deletion vectors と row lineage の使用を開始します。
Iceberg V3の deletion vectors と row lineage は、Amazon EMR、AWS Glue、SageMaker notebooks、S3 Tables、AWS Glue Data Catalog の各サービス/機能がサポートされている全てのAWSリージョンで利用可能です。
AWS Glue がリモート Apache Iceberg カタログのカタログフェデレーションを発表
AWS Glue で、リモート Iceberg カタログのカタログフェデレーションが一般提供されました。この機能により、Amazon S3 に保存され、リモートカタログにカタログ化された Iceberg テーブルに、AWS 分析エンジンを使用して直接かつ安全にアクセスできます。
カタログフェデレーションを使用すると、テーブルを移動またはコピーすることなく、リモート Iceberg カタログにフェデレーションし、好みの AWS 分析エンジンでリモート Iceberg テーブルをクエリできます。データチームがリモートテーブルをクエリすると、メタデータが AWS Glue Data Catalog とリモートカタログ間でリアルタイムに同期されるため、クエリ結果は常に最新の状態になります。これにより、一貫したセキュリティ制御を維持しながら、リモート Iceberg テーブルを分析する際に、ワークロードに最適な価格性能を選択できます。
カタログフェデレーションは、Amazon Redshift、Amazon EMR、Amazon Athena、AWS Glue、Apache Spark などのサードパーティーエンジン、およびサーバーレスノートブックを備えた Amazon SageMaker など、さまざまな分析エンジンでサポートされています。アクセスコントロールには AWS Lake Formation を使用し、きめ細かいアクセスコントロール、クロスアカウント共有、信頼されたID伝播が可能です。また、Iceberg REST 仕様をサポートするカタログ実装と統合されます。
この機能は、Lake Formation コンソール、および AWS Glue と Lake Formation の SDK と API を使用して利用でき、AWS Glue と Lake Formation が利用可能な全ての AWS 商用リージョンで一般提供されます。
AWS Glue Data Quality が前処理クエリをサポート
AWS Glue Data Quality の前処理クエリの一般提供が開始され、AWS Glue Data Catalog API を介してデータ品質チェックを実行する前にデータを変換できるようになりました。この機能により、データ品質評価プロセス内で直接、派生列の作成、特定の条件に基づくデータのフィルターリング、計算の実行、列間の関係の検証が可能です。
前処理クエリは、検証前にデータ変換を必要とする複雑なデータ品質シナリオにおいて、より高い柔軟性を提供します。例えば、税金と送料の列から合計料金を計算したり、データ品質の推奨事項で考慮される列数を制限したり、データセットをフィルターリングして特定のデータサブセットに品質チェックを集中させたりするなど、派生メトリクスを作成できます。この機能は、個別のデータ前処理ステップを不要にし、データ品質ワークフローを合理化します。
AWS Glue Data Quality の前処理クエリは、AWS Glue Data Quality が利用可能な全ての商用 AWS リージョンで、AWS Glue Data Catalog API の start-data-quality-rule-recommendation-run および start-data-quality-ruleset-evaluation-run を通じて利用できます。
AWS Glue Data Quality がリポート作成を強化するルールラベリングをサポート
AWS Glue Data Quality の機能であるルールラベルが一般提供されました。この機能により、データ品質ルールにカスタムのキーと値のペアのラベルを適用し、整理、フィルターリング、対象を絞ったリポート作成を改善できます。
この機能強化により、ビジネスコンテキスト、チームの所有権、コンプライアンス要件、またはデータ品質とガバナンスのニーズに合った任意のカスタム分類法でデータ品質ルールを分類できます。ルールラベルは、データ品質の結果を整理・分析するための効果的な方法です。特定のラベルで結果をクエリすることで、特定のカテゴリー内で失敗したルールを特定したり、チームやドメインごとにルールの結果をカウントしたり、さまざまな関係者向けに焦点を絞ったリポートを作成したりできます。
例えば、財務チームに関連する全てのルールに "team=finance" というラベルを適用し、財務チーム固有の品質メトリクスを示すカスタマイズされたリポートを生成できます。また、優先度の高いルールに "criticality=high" というラベルを付けて、修正作業の優先順位を付けることも可能です。
ラベルは DQDL の一部として作成できます。ルールの結果、行レベルの結果、API 応答の一部としてラベルをクエリできるため、既存の監視およびリポート作成ワークフローと簡単に統合できます。
AWS Glue 5.1 が一般提供
AWS Glue 5.1 の一般提供が開始されました。このバージョンでは、データ統合ワークロード向けに、パフォーマンスの向上、セキュリティアップデート、Apache Iceberg 機能の拡張、AWS Lake Formation の書き込みサポートが提供されます。AWS Glue は、複数のソースからのデータの検出、準備、移動、統合を簡素化する、サーバーレスでスケーラブルなデータ統合サービスです。このリリースでは、コアエンジンが Apache Spark 3.5.6、Python 3.11、Scala 2.12.18 にアップグレードされ、パフォーマンスとセキュリティが強化されています。また、Apache Hudi 1.0.2、Apache Iceberg 1.10.0、Delta Lake 3.3.2 などのオープンテーブルフォーマットライブラリのサポートも更新されています。
AWS Glue 5.1 では、Apache Iceberg フォーマットバージョン 3.0 のサポートが導入され、デフォルトの列値、読み取り時マージテーブルの削除ベクトル、複数引数変換、行リネージ追跡が追加されました。このリリースでは、AWS Lake Formation のきめ細かいアクセスコントロールが、Spark DataFrames および Spark SQL の書き込み操作 (DML と DDL の両方) にも拡張されました。これまで、この機能は読み取り操作のみに限定されていました。AWS Glue 5.1 では、Apache Hudi および Delta Lake テーブル用の Apache Spark におけるフルテーブルアクセスコントロールも追加され、データに対するより包括的なセキュリティオプションが提供されます。
AWS Glue 5.1 は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、欧州 (ストックホルム)、欧州 (フランクフルト)、欧州 (スペイン)、アジアパシフィック (香港)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、アジアパシフィック (マレーシア)、アジアパシフィック (タイ)、アジアパシフィック (ムンバイ)、南米 (サンパウロ) で利用可能です。
Amazon Connect のフローモジュールがカスタムの入力、出力、バージョン管理をサポート
Amazon Connect のフローモジュールで、カスタムの入力、出力、分岐、およびバージョンとエイリアスの管理がサポートされるようになりました。
これにより、特定のビジネスロジックに合わせて、再利用可能なフローモジュールに柔軟なパラメーターを定義できます。例えば、電話番号と PIN を入力として受け取り、お客さまの名前と認証ステータスを出力として返し、「認証済み」や「未認証」などの分岐を持つ認証モジュールを作成できます。全てのパラメーターは、特定のニーズに合わせてカスタマイズ可能です。
さらに、高度なバージョン管理機能とエイリアス機能により、モジュールの更新をよりシームレスに管理できます。不変のバージョンスナップショットを作成し、エイリアスを特定のバージョンにマッピングすることが可能です。エイリアスを新しいバージョンを指すように更新すると、そのモジュールを使用する全てのフローが自動的に更新されたバージョンを参照します。これらの新機能により、フローモジュールはより強力で再利用しやすくなり、フローの構築と保守をより効率的に行うことができます。
この機能は、Amazon Connect を提供する全ての AWS リージョンで利用可能です。
Amazon EC2 が中断可能な Capacity Reservations を発表
Amazon EC2 は、リザーブドキャパシティ の活用を向上させ、コストを削減するための中断可能な Capacity Reservations を発表します。On-Demand Capacity Reservations (ODCRs) は、特定の Availability Zone で任意の期間コンピューティングキャパシティを予約できる機能です。
ODCRs が使用されていない場合、中断可能な ODCRs として一時的に利用可能になり、重要なオペレーションのためにキャパシティを再要求する能力を維持しながら、組織内のほかのワークロードがそのキャパシティを利用できます。未使用のキャパシティを中断可能な ODCRs として再利用することで、バッチ処理、データ分析、機械学習トレーニングなど、柔軟でフォールトトレラントなオペレーションに適したワークロードが、一時的に利用可能なキャパシティを活用できます。
予約の所有者はいつでもキャパシティを再要求でき、中断可能な ODCRs の利用者は、終了前に中断通知を受け取ることで、正常なシャットダウンやチェックポイント作成を行えます。
中断可能な ODCRs は、全ての Capacity Reservations のお客さまに追加費用なしで利用可能です。CloudFormation のサポートは近日中に提供される予定です。
AWS Lambda が Node.js 24 をサポート
AWS Lambda で Node.js 24 を使用したサーバーレスアプリケーションの作成がサポートされるようになりました。開発者は Node.js 24 をマネージドランタイムとコンテナベースイメージの両方として使用でき、AWS は利用可能になり次第、マネージドランタイムとベースイメージにアップデートを自動的に適用します。
Node.js 24 は Node.js の最新の長期サポートリリースであり、2028年4月までセキュリティとバグ修正がサポートされる予定です。今回のリリースで、Lambda は開発者エクスペリエンスを簡素化し、最新の async/await プログラミングパターンに重点を置き、コールバックベースの関数ハンドラはサポートされなくなりました。
Node.js 24 を Lambda@Edge (サポートされているリージョン) で使用して、Amazon CloudFront を通じて配信される低レイテンシーのコンテンツをカスタマイズできます。サーバーレスのベストプラクティスを実装し、開発速度を向上させるための開発者ツールキットである Powertools for AWS Lambda (TypeScript) も Node.js 24 をサポートしています。
Lambda コンソール、AWS CLI、AWS Serverless Application Model (AWS SAM)、AWS CDK、AWS CloudFormation を含む AWS のあらゆるデプロイツールを使用して、Node.js 24 で記述されたサーバーレスアプリケーションをデプロイおよび管理できます。Node.js 24 ランタイムは、AWS GovCloud (US) Regions および中国リージョンを含む全てのリージョンで利用可能です。
AWS Lambda が Kafka イベント処理のエラーハンドリング機能を強化
AWS Lambda が、Amazon Managed Streaming for Apache Kafka (MSK) およびセルフマネージドの Apache Kafka (SMK) イベントソース向けのエラーハンドリング機能を強化しました。この機能により、お客さまはカスタムリトライ設定の構築、失敗したメッセージのリトライの最適化、失敗したイベントを失敗時の送信先として Kafka トピックに送信することが可能になり、堅ろうなエラーハンドリング戦略を持つ回復力のある Kafka ワークロードを構築できます。
開発者は、失敗したイベント処理を正確に制御し、Kafka ESM のプロビジョニングモード使用時に Kafka トピックを失敗時の追加の送信先として利用できるようになります。リトライ回数の上限と時間的境界を定義し、それを超えた失敗レコードは、お客さまが指定した送信先に自動的に破棄されます。また、バッチ内の失敗したレコードの自動リトライを設定し、個々の失敗メッセージを報告するように関数コードを強化することで、リトライプロセスを最適化できます。
この機能は、AWS Lambda の Kafka ESM 用プロビジョニングモードが利用可能な全ての AWS 商用リージョンで利用可能です。有効にするには、ESM API、AWS コンソール、または AWS CLI で Kafka ESM の設定パラメーターを指定します。
AWS Compute Optimizer が未使用の NAT ゲートウェイに関する推奨事項をサポート
AWS Compute Optimizer が、NAT ゲートウェイ のアイドル状態のリソースに関する推奨事項をサポートするようになりました。この新しい推奨タイプにより、未使用の NAT ゲートウェイ を特定し、コストを削減できます。
新しい未使用の NAT ゲートウェイ に関する推奨事項では、32日間の分析期間にわたってトラフィックアクティビティがない NAT ゲートウェイ を特定します。Compute Optimizer は、アクティブな接続数、送信元からの受信パケット、宛先からの受信パケットなどの CloudWatch メトリクスを分析して、NAT ゲートウェイ が本当に未使用であるかを検証します。重要なバックアップリソースを推奨しないようにするため、Compute Optimizer は NAT ゲートウェイ リソースが AWS ルートテーブル に関連付けられているかどうかも調べます。お客さまは、これらの未使用の NAT ゲートウェイ によって削減できる可能性のある総コストを確認し、詳細な使用率メトリクスにアクセスして、アクションを実行する前に未使用の状態を検証できます。
この新機能は、AWS GovCloud (US) と中国リージョンを除く、AWS Compute Optimizer が利用可能な全ての AWS リージョンで利用できます。
Amazon Aurora が PostgreSQL 17.6、16.10、15.14、14.19、13.22 をサポート
Amazon Aurora PostgreSQL-Compatible Edition が PostgreSQL バージョン 17.6、16.10、15.14、14.19、13.22 のサポートを追加しました。このアップデートには、PostgreSQL コミュニティーによる製品の改善やバグ修正に加え、Aurora 固有の機能強化も含まれています。
Dynamic Data Masking (DDM) (バージョン 16.10 および 17.6 のみ) は、実際に保存されているデータを変更することなく、ロールベースのポリシーに基づきクエリ時に列の値を動的にマスキングすることで、個人を特定できる情報などの機密データを保護する新しいデータベースレベルのセキュリティ機能です。今回のリリースには、共有プランキャッシュ、パフォーマンスと目標復旧時間 (RTO) の向上、Global Database の切り替えの改善も含まれています。
新しいバージョンを使用するには、Amazon RDS マネジメントコンソールで新しい Aurora PostgreSQL 互換データベースを作成するか、既存のデータベースをアップグレードします。これらのリリースは、全ての商用 AWS リージョン および AWS GovCloud (US) リージョンで利用可能です。
Amazon Aurora PostgreSQL が動的データマスキングを導入
Amazon Aurora PostgreSQL 互換エディションは、新しい pg_columnmask 拡張機能による動的データマスキングをサポートするようになり、データベース内の機密データの保護を簡素化できます。pg_columnmask は、PostgreSQL のネーティブな行レベルセキュリティと列レベルの権限付与を補完する列レベルの保護を有効にすることで、Aurora のセキュリティ機能を拡張します。
pg_columnmask を使用すると、SQL ベースのマスキングポリシーを通じて機密データへのアクセスを制御し、ロールに基づいてクエリ時にデータがユーザーにどのように表示されるかを定義できるため、GDPR、HIPAA、PCI DSS などのデータプライバシー規制への準拠に役立ちます。
pg_columnmask では、組み込み関数またはユーザー定義関数を使用して柔軟なマスキングポリシーを作成できます。情報を完全に非表示にしたり、部分的な値をワイルドカードに置き換えたり、カスタムのマスキングアプローチを定義したりすることが可能です。さらに、単一の列に複数のマスキングポリシーを適用し、重みを使用してその優先順位を制御できます。
pg_columnmask は、WHERE、JOIN、ORDER BY、または GROUP BY 句を含む複雑なクエリでのデータ保護に役立ちます。データはクエリ処理中にデータベースレベルでマスキングされるため、保存されているデータは変更されません。
pg_columnmask は、Aurora PostgreSQL が利用可能な全ての AWS リージョンで、Aurora PostgreSQL バージョン 16.10 以降および 17.6 以降で利用できます。
AWS Knowledge MCP Server がトピックベースの検索をサポート
AWS Knowledge MCP Server の検索機能が強化され、専門的な AWS ドキュメントドメインを横断したトピックベースの検索がサポートされるようになりました。AWS Knowledge MCP Server は、AI エージェントや開発者に AWS のドキュメントやナレッジリソースへのプログラムによるアクセスを提供する Model Context Protocol (MCP) サーバーです。
この機能強化により、MCP クライアントとエージェンティックフレームワークは、Troubleshooting、AWS Amplify、AWS CDK、CDK Constructs、AWS CloudFormation などの特定のドキュメントドメインにクエリを実行できるようになり、より正確で関連性の高い検索結果を得られます。これにより、ドメイン固有のクエリに対するノイズが減り、応答の精度が向上します。このトピックベースの検索は、API リファレンス、What's New (新着情報)、および一般的な AWS ドキュメントを検索する既存の機能を補完するものです。
AI エージェントを構築する開発者は、エラー解決のために Troubleshooting ドキュメントを検索したり、フロントエンド開発のガイダンスのために Amplify ドキュメントを検索したり、本番環境ですぐに使えるアーキテクチャーパターンのために CDK Constructs を検索したりするなど、特定のユースケースに合わせた情報を取得できるようになりました。この的を絞ったアプローチにより、開発ワークフローが加速され、AWS 固有のクエリに対する AI が生成した応答の品質が向上します。
強化された検索機能は、AWS Knowledge MCP Server を通じて追加費用なしで利用できます。使用には標準のレート制限が適用されます。
AWS IoT Core が IoT ルールからの IoT thing registry データ取得をサポート
AWS IoT Core に、IoT ルールを使用して IoT thing registry データを動的に取得する新機能が追加され、IoT メッセージのフィルターリング、エンリッチ、ルーティング機能が強化されました。
新しいインラインルール関数 get_registry_data() を使用すると、デバイスの属性、デバイスタイプ、グループメンバーシップなどの IoT thing registry データにアクセスし、この情報を IoT ルールで直接活用できます。
例えば、ルールで AWS IoT Core の接続ライフサイクルイベントをフィルターリングし、デバイスの属性(「テスト」や「本番」デバイスなど)を取得して、ライフサイクルイベントを下流処理のために異なるエンドポイントにルーティングできます。また、この機能を使用して、ほかのデバイスのレジストリデータで IoT メッセージをエンリッチしたり、ルーティングしたりすることも可能です。一例として、IoT thing registry からセンサーのしきい値温度を取得し、そのゲートウェイが中継するメッセージに追加できます。
この機能は、AWS IoT Core が利用可能な全ての AWS リージョンで利用できます。
新しい Amazon SageMaker AI MCP Server で Amazon SageMaker HyperPod クラスターの管理が可能に
Amazon SageMaker AI MCP Server が、HyperPod クラスターのセットアップと管理を支援するツールをサポートするようになりました。Amazon SageMaker HyperPod は、トレーニングやファインチューニングなどのモデル開発タスクを AI アクセラレータのクラスター全体で迅速にスケーリングすることで、生成 AI モデルの構築に伴う面倒な作業をなくします。
SageMaker AI MCP Server は、AI コーディングアシスタントがモデルのトレーニングとデプロイ用の AI/ML クラスターをプロビジョニングおよび運用できるようにします。このサーバーには、任意の AI アシスタントを使用して、初期セットアップから継続的な管理まで、エンドツーエンドの AI/ML クラスター操作を合理化するツールが付属しています。これにより、AI エージェントは、ネットワーク、ストレージ、コンピューティングリソースを最適化する CloudFormation テンプレートを利用して、Amazon EKS または Slurm によってオーケストレーションされた HyperPod クラスターを前提条件を含めて確実にセットアップできます。
この MCP サーバー経由で作成されたクラスターは、高性能な分散トレーニングおよび推論ワークロード向けに完全に最適化されており、ベストプラクティスのアーキテクチャーを活用してスループットを最大化し、大規模なレイテンシーを最小化します。さらに、スケーリング操作、ソフトウェアパッチの適用、さまざまなメンテナンスタスクの実行など、クラスターとノードの管理のための包括的なツールも提供します。
AWS API MCP Server、AWS Knowledge MCP Server、および Amazon EKS MCP Server と組み合わせて使用すると、全ての SageMaker HyperPod API を完全にカバーし、クラスターノードにアクセスできなくなった理由の診断など、一般的な問題を効果的に トラブルシュート できます。
クラスター管理者にとって、これらのツールは日常業務を合理化します。データサイエンティストにとっては、インフラストラクチャーの専門知識を必要とせずに大規模な AI/ML クラスターをセットアップできるため、モデルのトレーニングとデプロイに集中できます。
SageMaker HyperPod が利用可能な全てのリージョンで、SageMaker AI MCP Server を通じて AI/ML クラスターを管理できます。
SageMaker HyperPod が Managed Tiered KV Cache と Intelligent Routing をサポート
Amazon SageMaker HyperPod は、大規模言語モデル (LLM) 推論のための Managed Tiered KV Cache とIntelligent Routing をサポートするようになりました。これにより、長いコンテキストのプロンプトや複数ターンの会話における推論パフォーマンスを最適化できます。
従来の推論アプローチでは、新しいトークンが生成されるたびにアテンションメカニズムを再計算する必要があり、計算オーバーヘッドとコストが増加する課題がありました。Managed Tiered KV Cache は計算済みの値をインテリジェントにキャッシュして再利用し、Intelligent Routing はリクエストを最適なインスタンスに転送することでこの課題に対処します。これらの機能により、ベースライン構成と比較して、レイテンシーを最大40%削減、スループットを25%向上、コストを25%削減できます。
Managed Tiered KV Cache 機能の特長は、ローカルCPUメモリ (L1) とクラスター全体の分散ストレージ (L2) を組み合わせた2ティアアーキテクチャーです。AWSネーティブの分散ティアストレージが推奨バックエンドであり、テラバイト規模のスケーラブルな容量と自動ティアリングを提供します。代替のL2キャッシュオプションとして `Redis` も利用できます。このアーキテクチャーにより、リクエスト間で以前に計算されたキーと値のペアを効率的に再利用できます。
新しく導入された Intelligent Routing は、prefix-aware routing、KV-aware routing、round-robin の3つの設定可能な戦略を通じてキャッシュ使用率を最大化します。これらの機能はシームレスに連携し、関連するキャッシュデータを持つインスタンスにリクエストを転送することで、ドキュメント分析における最初のトークンまでの時間を短縮し、複数ターンの対話で自然な会話の流れを維持します。
パフォーマンス監視のために Amazon Managed Grafana との組み込みの可観測性統合によりメトリクスが提供されます。`EKS` でオーケストレーションされたクラスター上の HyperPod Inference Operator を介してモデルをデプロイする際に、InferenceEndpointConfig または SageMaker JumpStart を通じてこれらの機能を有効にできます。
これらの機能は、SageMaker HyperPod が利用可能な全てのリージョンで利用可能です。
Claude Opus 4.5 が Amazon Bedrock で利用可能に
お客さまは、主要な AI 企業が提供する高性能な基盤モデルを選択できるフルマネージドサービスである Amazon Bedrock で、Claude Opus 4.5 を利用できるようになりました。Opus 4.5 は Anthropic の最新モデルで、コーディング、エージェントワークフロー、コンピューター利用、オフィス業務において新たな基準を打ち立て、Opus レベルのインテリジェンスを3分の1のコストで利用できるようにします。
Opus 4.5 はプロフェッショナルなソフトウェアエンジニアリングタスクに優れており、SWE-bench で最先端のパフォーマンスを達成しています。このモデルは、曖昧さを処理し、トレードオフについて推論し、複数のシステムにまたがる推論を必要とするバグの修正を見つけ出すことができます。改善された多言語コーディング機能により、数日かかるチーム開発プロジェクトを数時間のタスクに変えることができます。
この世代の Claude は、開発ライフサイクル全体をカバーします。本番コードとリードエージェントには Opus 4.5、迅速なイテレーションとスケーラブルなユーザーエクスペリエンスには Sonnet 4.5、サブエージェントと無料ティア製品には Haiku 4.5 が対応します。
コーディング以外にも、このモデルは、一貫性、プロフェッショナルな仕上がり、ドメイン知識を備えたドキュメント、スプレッドシート、プレゼンテーションを作成するエージェントを強化し、金融やその他の精度が重要な業種に最適です。Anthropic のこれまでで最高のビジョンモデルとして、複雑な視覚的解釈と複数ステップのナビゲーションに依存するワークフローを可能にします。
Amazon Bedrock API を通じて、Opus 4.5 はツール検索とツール使用例という 2 つの新機能を導入します。これらのアップデートにより、Claude は大規模なツールライブラリをナビゲートし、複雑なタスクを正確に実行できるようになります。ベータ版で利用可能な新しい `effort` パラメーターを使用すると、思考、ツール呼び出し、応答に Claude が割り当てる労力を制御して、パフォーマンスとレイテンシー、コストのバランスを取ることができます。
Claude Opus 4.5 は、複数のロケーションでグローバルなクロスリージョン推論を介して Amazon Bedrock で利用可能になりました。
Amazon SageMaker HyperPod が生成AIタスク向けに NVIDIA Multi-Instance GPU (MIG) をサポートし、東京リージョンなどで利用可能に
Amazon SageMaker HyperPod は NVIDIA Multi-Instance GPU (MIG) テクノロジーをサポートするようになり、管理者は単一の GPU を複数の分離された GPU に分割できるようになりました。この機能により、管理者はパフォーマンスとタスクの分離を維持しながら、多様で小規模な生成系 AI (GenAI) タスクを GPU パーティション上で同時に実行することで、リソース使用率を最大化できます。
管理者は、SageMaker HyperPod コンソールでの使いやすい設定セットアップか、カスタムセットアップアプローチのいずれかを選択して、完全な GPU 容量を必要としない特定のタスク要件に対して、きめ細かい、ハードウェアで分離されたリソースを有効にすることができます。また、コンピューティングクオータを割り当てて、チーム間で GPU パーティションを公平かつ効率的に分配することもできます。GPU パーティション全体のリアルタイムのパフォーマンスメトリクスとリソース使用率監視ダッシュボードにより、管理者はリソース割り当てを最適化するための可視性を得られます。
データサイエンティストは、GPU パーティション上で軽量な推論タスクをスケジューリングし、インタラクティブなノートブックを並行して実行することで、完全な GPU が利用可能になるまでの待機時間をなくし、市場投入までの時間を短縮できるようになりました。
この機能は現在、EKS オーケストレーターを使用する Amazon SageMaker HyperPod クラスターで、以下の AWS リージョンで利用できます: 米国西部 (オレゴン)、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、欧州 (ストックホルム)、欧州 (スペイン)、欧州 (アイルランド)、欧州 (フランクフルト)、欧州 (ロンドン)、アジアパシフィック (ムンバイ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アジアパシフィック (東京)、アジアパシフィック (シドニー)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)。
Amazon SageMaker HyperPod がプログラムによるノードの再起動と置き換えをサポートし、東京リージョンなどで利用可能に
Amazon SageMaker HyperPod に、クラスターノードをプログラムで再起動および置き換えするための新しい API、BatchRebootClusterNodes と BatchReplaceClusterNodes が一般提供されました。SageMaker HyperPod は、大規模言語モデル (LLM) や基盤モデル (FM) などの開発に使用される、回復力のあるクラスターのプロビジョニングを支援します。
この新しい API により、お客さまは応答しない、または劣化したクラスターノードをプログラムで再起動または置き換えでき、ノードの復旧操作に対してオーケストレーターに依存しない一貫したアプローチが提供されます。この API は、Slurm と EKS の両方でオーケストレーションされたクラスターのノード管理機能を強化し、既存のワークフローを補完します。メモリのオーバーランやハードウェアの劣化などの問題でノードが応答しなくなった場合、これらの API を通じて復旧操作を開始できます。この機能は、時間に制約のあるワークロードを実行する際に特に役立ちます。
例えば、Slurm ノードが応答しなくなった場合に API で再起動をトリガーしたり、EKS クラスターの劣化したワーカーノードをプログラムで置き換えしたりできます。各 API は最大 25 インスタンスのバッチ操作をサポートしており、大規模な復旧シナリオを効率的に管理できます。
この再起動および置き換え API は、SageMaker HyperPod が利用可能な米国東部 (オハイオ)、アジアパシフィック (ムンバイ)、アジアパシフィック (東京) リージョンでサポートされています。API は、AWS CLI、SDK、または API コールを通じてアクセスできます。
Amazon SageMaker HyperPod がスポットインスタンスをサポート
Amazon SageMaker HyperPod がスポットインスタンスをサポートするようになりました。これにより、お客さまは HyperPod 上のオンデマンドインスタンスと比較して、GPU コンピューティングコストを最大 90% 削減できます。AI ワークロードが大規模化するにつれて、インフラストラクチャーコストの最適化はますます重要になります。SageMaker HyperPod の Spot 統合は、お客さまが HyperPod で利用できるマネージド AI エクスペリエンスを提供しつつ、余剰の EC2 キャパシティを大幅な割引価格で自動的に活用できるようにすることで、この課題に対応します。
スポットインスタンスを使用すると、フォールトトレラントなワークロードを大規模かつコスト効率よく実行できます。Spot とオンデマンドインスタンスを組み合わせることで、コスト最適化と可用性の保証のバランスを取ることも可能です。この機能は HyperPod EKS クラスターで利用でき、Karpenter と統合してインテリジェントなオートスケーリングを実現し、利用可能な Spot キャパシティを自動的に検出し、インスタンスの中断を処理します。
CreateCluster API または AWS コンソールを介してインスタンスグループを作成する際に Spot Instances を有効にでき、CPU や GPU を含む HyperPod で利用可能な全てのインスタンスタイプをサポートします。キャパシティの可用性は EC2 からの供給に依存し、リージョンやインスタンスタイプによって異なります。スポットインスタンスのサポートは、SageMaker HyperPod が現在利用可能な全てのリージョンで提供されます。
Amazon SageMaker HyperPod がカスタム Kubernetes ラベルと taint をサポート
Amazon SageMaker HyperPod がカスタム Kubernetes ラベルと taint をサポートするようになり、お客さまはポッドのスケジューリングを制御し、既存の Kubernetes インフラストラクチャーとシームレスに統合できるようになりました。
EKS でオーケストレーションされた HyperPod クラスター上の AI ワークロードでは、高価な GPU リソースがシステムポッドや非 AI ワークロードに消費されるのを防ぐため、ワークロードの配置を正確に制御する必要があります。以前は、お客さまは kubectl を使用して手動でラベルと taint を適用し、ノードの交換、スケーリング、パッチ適用のたびに再適用する必要があり、運用上のオーバーヘッドが大きくなっていました。
この機能では、CreateCluster および UpdateCluster API を通じてインスタンスグループレベルでラベルと taint を設定でき、ノードのライフサイクル全体にわたってスケジューリングポリシーを定義・維持するためのマネージドなアプローチを提供します。新しい KubernetesConfig パラメーターを使用すると、インスタンスグループごとに最大 50 のラベルと 50 の taint を指定できます。ラベルはノードセレクターによるリソースの整理とポッドのターゲティングを可能にし、taint は一致する toleration を持たないポッドを排除することで、特殊なノードを保護します。例えば、GPU インスタンスグループに NoSchedule taint を適用して、明示的な toleration を持つ AI トレーニングジョブのみが高コストのコンピューティングリソースを消費するようにしたり、デバイスプラグインポッドが正しくスケジュールされるようにカスタムラベルを追加したりできます。
HyperPod は、ノード作成時にこれらの設定を自動的に適用し、交換、スケーリング、パッチ適用操作全体でそれらを維持するため、手動での介入が不要になり、運用上のオーバーヘッドが削減されます。
この機能は、Amazon SageMaker HyperPod が利用可能な全ての AWS リージョンで利用できます。
Amazon SageMaker AI が推論向けの Flexible Training Plans キャパシティをサポート
Amazon SageMaker AI の Flexible Training Plans (FTP) が推論エンドポイントをサポートするようになりました。これにより、お客さまは計画的な評価や本番のピーク時に保証された GPU キャパシティを利用できます。お客さまは必要なインスタンスタイプを正確に予約でき、SageMaker AI が自動的に推論エンドポイントを立ち上げるため、自身でインフラストラクチャー管理を行う必要はありません。
お客さまが ML 開発サイクルを計画する際、モデル評価や本番前テストに必要な GPU が、指定した日に確実に利用できる必要があります。FTP を使用すると、お客さまは ML ワークロードを実行するための GPU キャパシティに簡単にアクセスできます。FTP の推論エンドポイントのサポートにより、推論ワークロードに合わせて、希望のインスタンスタイプ、コンピューティング要件、予約期間、開始日を選択できます。エンドポイントを作成する際に予約 ARN を参照するだけで、SageMaker AI がプラン期間全体にわたって、保証されたキャパシティ上でエンドポイントを自動的にプロビジョニングして実行します。これにより、数週間にわたるインフラストラクチャー管理とスケジューリングの労力が不要になり、モデルパフォーマンスの向上に時間を集中させながら、推論を予測どおりに実行できます。
SageMaker AI Inference 向けの Flexible Training Plans のサポートは、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国東部 (オハイオ) の各リージョンで利用可能です。
Amazon SageMaker AI が EAGLE 投機的デコーディングをサポート
Amazon SageMaker AI は、大規模言語モデルの推論スループットを最大2.5倍向上させる EAGLE (Extrapolation Algorithm for Greater Language-model Efficiency) 投機的デコーディング をサポートするようになりました。この機能は、モデルが一度に1つではなく複数のトークンを同時に予測・検証することを可能にし、AIアプリケーションの応答時間を改善します。
AIアプリケーションを本番環境にデプロイする際、お客さまは低レイテンシーと高スループットを必要としますが、これまでは出力品質を犠牲にしたり複雑なモデル再設計を行ったりせずにトークン生成を高速化することは困難でした。EAGLE 投機的デコーディング を使用すると、SageMaker AI は複数のトークンを並行して生成・検証することで推論スループットを高速化し、同じ出力品質を維持しながらスループットを大幅に向上させます。
SageMaker AI は、モデルアーキテクチャーに基づいて EAGLE 2 と EAGLE 3 を自動的に選択し、キュレートされたデータセットまたはお客さま自身のアプリケーションデータを使用して特殊な予測ヘッドをトレーニングする、組み込みの最適化ジョブを提供します。最適化されたモデルは、インフラストラクチャーを変更することなく既存の SageMaker AI 推論ワークフローを通じてデプロイでき、予測可能なパフォーマンスでより高速なAIアプリケーションを提供できるようになります。
EAGLE 投機的デコーディング は、米国東部 (バージニア北部)、米国西部 (オレゴン)、米国東部 (オハイオ)、アジアパシフィック (東京)、欧州 (アイルランド)、アジアパシフィック (シンガポール)、欧州 (フランクフルト) の AWS リージョンで利用できます。
Amazon SageMaker AI Inference が双方向ストリーミングをサポート
Amazon SageMaker AI Inference が、リアルタイムの音声テキスト変換のための双方向ストリーミングをサポートしました。これにより、バッチ入力ではなく継続的な音声処理が可能になり、ユーザーが話している間にモデルが音声ストリームを受け取り、部分的なトランスクリプトを同時に返すことができます。この機能により、最小限の遅延で音声を処理する音声エージェントを構築できます。
今回のアップデートにより、新しい Bidirectional Stream API でエンドポイントを呼び出すだけで、音声テキスト変換モデルをデプロイできます。クライアントが SageMaker AI ランタイムへの HTTP2 接続を開くと、SageMaker AI がコンテナへの WebSocket 接続を自動的に作成し、ストリーミング音声フレームの処理と部分的なトランスクリプトの返信を可能にします。
SageMaker AI コントラクトに準拠した WebSocket ハンドラーを実装したコンテナは自動的に動作し、Deepgram のようなリアルタイム音声モデルも変更なしで実行可能です。これにより、数カ月を要したインフラ開発が不要になり、モデルのパフォーマンス向上に集中しながら、継続的な文字起こしを行う音声エージェントを迅速にデプロイできます。
双方向ストリーミングは、カナダ (中部)、南米 (サンパウロ)、アフリカ (ケープタウン)、欧州 (パリ)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、イスラエル (テルアビブ)、欧州 (チューリッヒ)、アジアパシフィック (東京)、AWS GovCloud US (西)、AWS GovCloud US (東)、アジアパシフィック (ムンバイ)、中東 (バーレーン)、米国西部 (オレゴン)、中国 (寧夏)、米国西部 (北カリフォルニア)、アジアパシフィック (シドニー)、欧州 (ロンドン)、アジアパシフィック (ソウル)、米国東部 (バージニア北部)、アジアパシフィック (香港)、米国東部 (オハイオ)、中国 (北京)、欧州 (ストックホルム)、欧州 (アイルランド)、中東 (UAE)、アジアパシフィック (大阪)、アジアパシフィック (メルボルン)、欧州 (スペイン)、欧州 (フランクフルト)、欧州 (ミラノ)、アジアパシフィック (シンガポール) の各 AWS リージョンで利用可能です。
Amazon Quick Research が、信頼できるサードパーティーの業界インテリジェンスを統合
組織がエンタープライズデータから答えを得て、インサイトからアクションへと迅速に移行できるよう支援する AI 搭載ワークスペースである Amazon Quick Suite は、専門的なサードパーティーデータセットへのアクセスで Quick Research を強化します。Quick Research は、数週間かかるデータの発見、分析、インサイトの生成を数分で完了させることで、ビジネスプロフェッショナルによる複雑なビジネス問題への取り組み方を変革します。
今回のアップデートにより、Quick Research は、業界インテリジェンスプロバイダーである S&P Global、FactSet、IDC とのパートナーエコシステムを開始しました。今後もパートナーは追加される予定です。既存のサブスクリプションをお持ちのお客さまは、これらの信頼性の高いデータセットを、自社の全てのビジネスデータやリアルタイムのWeb検索と組み合わせることで、より深いインサイトの獲得と戦略的な意思決定を加速できます。さらに、全てのお客さまは、数十年にわたる米国特許商標庁のデータや、生物医学および生命科学文献における数百万件の PubMed の引用と抄録にアクセスできます。
あらゆる業界のビジネスプロフェッショナルは、統合された単一のワークスペースで複数のデータソースにアクセスして分析できるようになり、プラットフォーム間を切り替える必要がなくなります。例えば、金融アナリストは FactSet の財務データをリアルタイムのWeb検索や社内の市場リポートと併用して投資機会を評価でき、エネルギーチームは S&P Global の商品データを自社の戦略チームからのインサイトと組み合わせて取引戦略を最適化できます。同様に、営業チームや製品チームは、IDC の業界インテリジェンスを自社のお客さまデータと活用することで、新たなトレンドをより迅速に発見できます。重要なデータソースを 1 か所に集約することで、組織はより迅速かつ自信を持ってインサイトからアクションへと移行できます。
Quick Research のサードパーティーデータ統合は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、ヨーロッパ (アイルランド) の AWS リージョンで利用できます。
Amazon Lex が、自然言語理解の主要なオプションとして LLM をサポート
Amazon Lex で、音声やチャットでの対話におけるお客さまの意図を理解するために、大規模言語モデル (LLMs) を主要な選択肢として使用できるようになりました。この機能により、音声ボットやチャットボットは、お客さまのリクエストをより深く理解し、複雑な発話を処理し、スペルミスがあっても精度を維持し、冗長な入力から重要な情報を抽出できます。お客さまの意図が不明確な場合、ボットはインテリジェントにフォローアップの質問をすることで、リクエストを正確に実行できます。例えば、お客さまが「フライトのことで助けが必要です」と言った場合、LLM はお客さまがフライト状況の確認、フライトのアップグレード、フライトの変更のいずれを希望しているのかを自動的に明確にします。この機能は、Amazon Connect と Lex が利用可能な全ての AWS 商用リージョンで利用できます。
Amazon Bedrock が Reserved サービスティアを導入
Amazon Bedrock は、予測可能なパフォーマンスと保証された1分当たりのトークン容量を必要とするワークロード向けに設計された、新しい Reserved サービスティアを導入します。Reserved ティアは、優先的なコンピューティングキャパシティを予約する機能を提供し、ミッションクリティカルなアプリケーションのサービスレベルを予測可能に保ちます。また、ワークロードの正確な要件に合わせてコストを管理するために、入力と出力で異なる1分当たりのトークン容量を割り当てる柔軟性も備えています。多くのワークロードではトークンの使用パターンが非対称であるため、これは特に大きな特長です。例えば、要約タスクは多くの入力トークンを消費しますが、生成される出力トークンは少なく、一方、コンテンツ生成アプリケーションは少ない入力とより多くの出力容量を必要とします。
アプリケーションが必要とする1分当たりのトークン容量が予約分を超えた場合、サービスは自動的に従量課金制の Standard ティアにオーバーフローし、中断のない運用を保証します。Reserved ティアは、モデルの応答に対して 99.5% のアップタイムを目標としており、Anthropic Claude Sonnet 4.5 で利用可能になりました。お客さまは、1か月または3か月の期間でキャパシティを予約できます。お客さまは、1分当たり 1K トークンごとに固定価格を支払い、毎月請求されます。Reserved サービスティアにより、Amazon Bedrock はお客さまにより多くの選択肢を提供し続け、パフォーマンスとコスト要件のバランスを取りながら、生産性とお客さま体験を向上させるアプリケーションやエージェントの開発、拡張、デプロイを支援します。
AWS API MCP Server が AWS Marketplace で利用可能に
AWS Marketplace で AWS API MCP Server が利用可能になり、お客さまは Model Context Protocol (MCP) サーバーを Amazon Bedrock AgentCore にデプロイできるようになりました。Marketplace のエントリーには、AWS API MCP Server を組み込みの認証とセッション分離を備えたマネージドサービスとして Bedrock Agent Core Runtime にデプロイするための、ステップバイステップの設定とデプロイ手順が含まれています。
AWS Marketplace からのデプロイはコンテナ管理を簡素化し、Amazon Bedrock AgentCore Runtime を通じてエンタープライズグレードのセキュリティ、スケーラビリティ、セッション分離を提供します。お客さまは、設定可能な認証方式 (SigV4 または JWT) で AWS API MCP Server をデプロイし、最小権限の IAM ポリシーを実装し、AgentCore の組み込みログ記録およびモニターリング機能を利用できます。このデプロイにより、お客さまはセキュリティ要件に応じて IAM ロール、認証方式、ネットワーク設定を構成できます。
AWS API MCP Server は、Amazon Bedrock AgentCore がサポートされている全ての AWS リージョンで AWS Marketplace からデプロイできるようになりました。
Amazon CloudWatch がログの削除保護をサポート
Amazon CloudWatch で、CloudWatch ロググループの削除保護が設定可能になりました。これにより、お客さまは監査証跡、コンプライアンス記録、運用ログなどの重要なログデータを、偶発的または意図しない削除から保護できます。
削除保護を有効にすると、保護が明示的に無効化されるまでロググループは削除できなくなります。この保護は、トラブルシュートや分析に必要な監査ログや本番アプリケーションログを保存するのに特に有効です。
ロググループの削除保護は、全ての AWS 商用リージョンで利用可能です。削除保護は、ロググループの作成時または既存のロググループに対して、Amazon CloudWatch コンソール、AWS Command Line Interface (AWS CLI)、AWS Cloud Development Kit (AWS CDK)、AWS SDKs を使用して有効にできます。
AWS Service Quotas が自動クオータ管理機能をサポート
AWS Service Quotas の自動クオータ管理機能がアップデートされ、お客さまの使用状況に基づいて AWS サービスのクオータ値が自動的かつ安全に調整されるようになりました。これにより、クオータ使用量の監視や、複数の AWS アカウントおよびリージョンにまたがるクオータ引き上げリクエストといった運用負担が軽減されます。お客さまは、クオータの枯渇による予期せぬサービス中断のリスクなく、需要の増加に合わせてアプリケーションを安心してスケールできます。また、クオータ使用量が割り当てに近づいた際に、E メール、SMS、Slack などのチャンネルで通知を受け取る設定も可能です。この新機能は、全ての AWS 商用リージョンで追加費用なしで利用できます。
AWS Health がイベントのトリアージを改善
AWS Health のイベントスキーマに、actionability と persona という2つの新しいプロパティが追加され、お客さまは最も関連性の高いイベントを特定できるようになりました。これらのプロパティにより、組織はプログラムによってお客さまの対応が必要なイベントを特定し、関連チームに転送できます。
新しい actionability プロパティを使用すると、チームは対応が必要なイベントと情報共有のためのイベントを迅速に区別できます。persona プロパティは、セキュリティや請求などの特定のチームへのイベントのルーティングと可視性を効率化し、重要な情報が適切な関係者に確実に届くようにします。
強化されたイベントスキーマは、AWS Health API と Health EventBridge の両方の通信チャンネルを通じてアクセスでき、運用効率とチーム連携を向上させます。これらの構造化されたプロパティは既存の運用ツールとの統合を効率化し、チームが影響を受けるリソースを効果的に特定して修正すると同時に、組織全体で適切な可視性を維持できるようにします。
この機能強化は、全ての AWS 商用リージョンおよび AWS GovCloud (US) リージョンで利用可能です。
AWS Elemental MediaTailor がライブストリーム向けの HLS Interstitials をサポート
AWS Elemental MediaTailor は、ライブストリーム向けの HTTP Live Streaming (HLS) Interstitials をサポートするようになりました。これにより、放送事業者やストリーミングサービスプロバイダーは、さまざまな最新のビデオプレーヤーで、シームレスでパーソナライズされた広告体験を提供できます。
この機能により、お客さまは HLS Interstitials 仕様 (RFC 8216) を使用して、インタースティシャル広告やプロモーションをライブストリームに直接挿入できます。この仕様は、HLS.js、Shaka Player、Bitmovin Player、および iOS 16.4、iPadOS 16.4、tvOS 16.4 以降を実行する Apple デバイスなどの主要なプレーヤーでネーティブにサポートされています。
HLS Interstitials を使用すると、MediaTailor は、クライアントプレーヤーにインタースティシャルコンテンツをいつ、どのように再生するかを通知する必要なメタデータタグ (Interstitial class EXT-X-DATERANGE with X-ASSET-LIST attributes) を自動的に生成します。このアプローチにより、プレーヤー側でのカスタムなスティッチングロジックが不要になり、開発の複雑さが軽減され、一貫した再生動作が保証されます。
この機能は、MediaTailor の既存のサーバーサイド広告挿入 (SSAI) 機能と統合されており、コンテンツとインタースティシャルの間でバッファリングのない、フレーム精度の高い遷移を実現します。サーバーサイドビーコニングは HLS Interstitials でも引き続き機能するため、広告のトラッキングと測定のワークフローは維持されます。
ライブストリーム向けの HLS Interstitials は、正確な広告タイミングと最小限の遅延が重要となるスポーツ放送、ライブニュース、イベントストリーミングで特に価値があります。この機能はプレロールとミッドロールの挿入をサポートしており、お客さまはライブコンテンツを柔軟に収益化できます。今回のリリースは、MediaTailor の既存の VOD 向け HLS Interstitials サポートを補完し、Linear、Live、FAST、VOD の各ワークフローにわたるサポートを完成させます。
MediaTailor ではテストとデプロイが簡単で、お客さまはマルチバリアントマニフェストリクエストに簡単なクエリパラメーターを追加するだけで、HLS Interstitials を迅速に有効または無効にできます。これにより、基盤となる MediaTailor の設定を変更することなく、再生セッションごとに制御できます。
AWS Elemental MediaTailor のライブストリーム向け HLS Interstitials は、MediaTailor が利用可能な全ての AWS リージョンで利用可能です。初期費用は不要で、使用した機能に対してのみ料金が発生します。
Amazon Route 53 がパブリック DNS レコードを管理するための高速リカバリを発表
Amazon Route 53 は、パブリックホストゾーンの DNS レコードを管理するための高速リカバリオプションをリリースしました。このオプションは、米国東部(バージニア北部) の AWS サービスが一時的に利用できなくなった場合に、Route 53 パブリックホストゾーンの DNS レコードを変更する機能を回復するための目標復旧時間 (RTO) を60分とすることを目標としています。
Route 53 のパブリック DNS サービス API は、ソフトウェアのデプロイ、インフラストラクチャーの運用、新規ユーザーのオンボーディングを目的とした DNS レコードの変更にお客さまが利用されています。特に銀行、金融テクノロジー (FinTech)、Software-as-a-Service (SaaS) のお客さまは、事業継続と災害復旧の目標を達成するために、予測可能で短い RTO を必要としています。
従来は、米国東部 (バージニア北部) の AWS サービスが利用できなくなると、お客さまは DNS レコードを修正または再作成して、ユーザーや内部サービスを更新されたエンドポイントに向けることができませんでした。高速リカバリオプションを Route 53 パブリックホストゾーンで有効にすると、このような中断が発生した後すぐに、多くの場合1時間未満で、そのホストゾーンの Route 53 パブリック DNS レコード (リソースレコードセット) を変更できるようになります。
パブリック DNS レコードを管理するための高速リカバリは、AWS GovCloud と中国の Amazon Web Services を除き、グローバルで利用可能です。この機能の利用に追加料金はかかりません。
Amazon CloudFront が mutual TLS 認証のサポートを発表
Amazon CloudFront が mutual TLS Authentication (mTLS) のサポートを開始しました。mTLS は、サーバーとクライアントが X.509 証明書を使用して相互に認証するセキュリティプロトコルで、お客さまは CloudFront のエッジロケーションでクライアントのアイデンティティーを検証できます。
お客さまは、信頼できる証明書を提示するクライアントのみがディストリビューションにアクセスできるようにすることで、不正アクセスやセキュリティ上の脅威から保護できます。従来、お客さまは独自のクライアントアクセス管理ソリューションを実装・維持する必要があり、差別化につながらない重労働となっていました。mutual TLS のサポートにより、アプリケーションサーバーや API との接続が確立される前に、AWS エッジでクライアントのアイデンティティーを簡単に検証できるようになりました。
ユースケースの例として、企業向けの B2B セキュア API 統合や、IoT のクライアント認証が挙げられます。B2B API セキュリティでは、企業は mTLS を使用して信頼できるサードパーティーやパートナーからの API リクエストを認証できます。IoT のユースケースでは、デバイスがファームウェアの更新といった独自のコンテンツを受信する権限があることを検証できます。
お客さまは、既存のサードパーティー認証局または AWS Private Certificate Authority を利用して X.509 証明書に署名できます。Mutual TLS を使用することで、クライアント認証を必要とするワークロードに対して、CloudFront のパフォーマンスとスケールのメリットを享受できます。
Mutual TLS 認証は、追加費用なしで全ての CloudFront のお客さまにご利用いただけます。お客さまは、AWS マネジメントコンソール、CLI、SDK、CDK、CloudFormation を使用して、CloudFront で mTLS を設定できます。
Amazon CloudFront が VPC IPAM と統合し、BYOIP をサポート
Amazon CloudFront は、VPC IP Address Manager (IPAM) を介して、Anycast Static IPs 向けに独自の IP アドレス (BYOIP) を使用できるようになりました。これにより、ネットワーク管理者は独自のパブリック IPv4 アドレスプールを CloudFront ディストリビューションで使用でき、AWS のグローバルインフラストラクチャー全体での IP アドレス管理が簡素化されます。
CloudFront は通常、ローテーションする IP アドレスを使用してトラフィックを配信しますが、CloudFront Anycast Static IPs を使用すると、お客さまは専用の IP アドレスリストをパートナーやお客さまに提供でき、セキュリティの強化とネットワーク管理の簡素化が可能になります。以前は、Anycast Static IPs を実装するお客さまは、ワークロード用に AWS が提供する静的 IP アドレスを受け取っていました。IPAM の統合インターフェースを使用することで、お客さまは BYOIP を使用して専用の IP アドレスプールを作成し、それらを CloudFront Anycast Static IP リストに割り当てることができます。
お客さまは、CloudFront に移行する際にアプリケーションの既存の IP アドレス空間を変更する必要がなく、既存の許可リストやブランディングを維持できます。この機能は、AWS GovCloud (US) リージョン、および中国 (北京、Sinnet 運営) と中国 (寧夏、NWCD 運営) を除く、全ての商用 AWS リージョンの Amazon VPC IPAM 内で利用できます。
AWS が Network Firewall Proxy を発表(プレビュー)
AWS が Network Firewall Proxy をパブリックプレビューで提供開始しました。これを使用すると、データの抜き取りやマルウェアの注入に対して一元的な制御を行えます。
数回クリックするだけで Network Firewall Proxy を explicit モードで設定し、アプリケーションから送信されるトラフィックと、アプリケーションが受信する応答をフィルターリングできます。Network Firewall Proxy を使用すると、お客さまはWebトラフィックとネットワーク間トラフィックを効率的に管理および保護できます。ドメイン名やサーバー名インデックス (SNI) のなりすましの試みから組織を保護し、きめ細かいアクセスコントロールを設定する柔軟性を提供します。
Network Firewall Proxy を使用して、アプリケーションから信頼できるドメインや IP アドレスへのアクセスを制限したり、外部サーバーからの意図しない応答をブロックしたりできます。また、TLS インスペクションを有効にして、HTTP ヘッダー属性に対して詳細なフィルターリング制御を設定することもできます。
Network Firewall Proxy は、アプリケーションを監視するための包括的なログを提供します。これらを有効にして Amazon S3 や AWS CloudWatch に送信し、詳細な分析や監査を行うことができます。パブリックプレビュー期間中は、プロキシは無料で利用できます。
Amazon S3 Metadata が大阪など22の追加リージョンで利用可能に
Amazon S3 Metadata が、新たに追加された22の AWS リージョンで利用可能になりました: アフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (ジャカルタ)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (中部)、カナダ西部 (カルガリー)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、イスラエル (テルアビブ)、中東 (バーレーン)、中東 (UAE)、南米 (サンパウロ)、米国西部 (北カリフォルニア)。
Amazon S3 Metadata は、ほぼリアルタイムで更新される自動化されたクエリ可能なメタデータにより、S3 データを即座に発見・理解し、ビジネス分析やリアルタイム推論アプリケーションなどに活用するための、最も簡単で高速な方法です。S3 Metadata は、オブジェクトのサイズやソースなどのシステム定義の詳細を含むオブジェクトメタデータと、product SKU、transaction ID、content rating などの情報でオブジェクトにタグ付けできるカスタムメタデータをサポートします。S3 Metadata は、新規および既存のオブジェクト両方のメタデータを自動的に生成し、データの包括的でクエリ可能なビューを提供します。
今回の拡張により、S3 Metadata は合計28の AWS リージョンで一般提供されることになります。
Amazon S3 Block Public Access が組織レベルでの適用をサポート
Amazon S3 Block Public Access (BPA) は、AWS Organizations を通じて組織レベルでの制御が可能になりました。これにより、単一のポリシー設定で AWS 組織内の全てのアカウントにわたる S3 のパブリックアクセス設定を標準化し、強制できます。
ポリシーを組織のルートまたは組織単位 (OU) レベルでアタッチすると、そのスコープ内の全てのサブアカウントに伝播し、新しいメンバーアカウントは自動的にポリシーを継承します。また、よりきめ細かい制御のために、特定のアカウントにポリシーを適用することも可能です。
AWS CloudTrail を使用して、ポリシーのアタッチメントやメンバーアカウントへの適用を監査または追跡できます。
この機能は、AWS Organizations と Amazon S3 がサポートされている全ての AWS リージョンにおいて、AWS Organizations コンソールおよび AWS CLI/SDK を通じて追加料金なしで利用できます。
ソフトバンクはAWS アドバンストティアサービスパートナーです
「はじめてのAWS導入」から大規模なサービス基盤や基幹システムの構築まで、お客さまのご要望にあわせて最適なAWS環境の導入を支援します。
MSP(Managed Service Provider)サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。
条件に該当するページがございません