はじめに こんにちは。AWS Analytics Specialist ソリューションアーキテクトの深見 です。 データベースの変更をリアルタイムに分析基盤へ反映したいというニーズに高まりを感じています。実際に多くのお客様から相談をいただいております。またデータベースの差分をもとに連携することが望まれる場面も多くあります。そういう場合の選択肢の一つが CDC（Change Data Capture）と呼ばれる MySQL の binlogなどの変更履歴をもとにデータを連携する手法になります。しかし、CDC での実装は、データ取得・キャッシュレイヤー・コンシューマーの実装とコンポーネントが多くなる場合も多く技術的なハードルが高く、ソースデータベースのスキーマの変更をターゲットの分析基盤に滞りなく連携する必要があるなど運用負荷も大きいワークロードになります。 CDC のターゲットの選択肢の１つとして、Iceberg を利用することで多様なエンジンから利用することができ、ソーススキーマの変更にも柔軟に対応ができるコスト効率の良い、DB のデータをソースにしたデータレイクハウスを構築することができます。 本記事では、AWS パートナーである primeNumber 社 が提供するデータ統合プラットフォーム「TROCCO」の CDC 機能を使って、MySQL から AWS 上の Apache Iceberg テーブルへのリアルタイムレプリケーションを実現する方法をご紹介します。実際に検証した内容をもとに、セットアップから運用まで詳しく解説していきます。 RDB から Apache Iceberg テーブルへのデータ連携のユースケース RDB をソースに Apache Iceberg へデータを連携したい場面はどのようなケースがあるでしょうか？いくつかの例をみてみましょう。 OLTP と OLAP の分離 RDB にあるデータを分析に使いたい場合でも、様々な理由で直接 RDB に分析クエリを実行することがためらわれる場面はよくあるかと思います。その中でも多く上がる理由としては、ソース DB のトランザクショナルなワークロードのパフォーマンスに影響を与えたくないといった理由です。インタラクティブに分析されるケースでは、そのためだけにリードレプリカなどで分析用のリソースを用意することもコスト増加につながってしまいます。そのため、 OLTP (Online Transaction Processing) と OLAP(Online Analytical Processing) を分離することでリソース管理・効率の向上やコスト最適化を狙った分離を行うことがあります。Apache Iceberg を利用することで高いコスト効率で OLAP 環境を用意することが可能になります。また、Apache Iceberg のオープンなフォーマットである特徴から分析ユーザーの好みのクエリエンジンを利用することが非常に簡単になります。例えば AWS のエンジンであれば Athena や Redshift 、OSS のエンジンであれば Spark や Trino 、 DuckDB や PyIceberg から同じテーブルを参照することができるようになります。これにより、広い活用の幅をもったデータレイクを構築することが可能になります。 タイムトラベル機能を利用した過去断面の参照 データベーステーブルの過去の断面を再現する必要のある場面は度々見受けられます。例えば、テーブルのデータに不整合が発生した際のロールバック、もしくは ML や AI のモデル開発時のモデル変更による影響を過去のテーブルを使って確認するバックテストといったユースケースがあげられます。 これに関連する Iceberg の大きな特徴として、スナップショットを利用した過去のテーブルの断面を指定してクエリを実行する タイムトラベル 機能があります。RDB から Iceberg テーブルにデータを差分で連携することで過去のテーブルの状態を容易に確認することが可能です。従来変更差分をバックアップとして保持しようとすると、定期的にフルスナップショットを取得しそれを保管しておくといったコストのかかる方法が必要でした。しかし、Iceberg では差分データを効率的に保持することが可能なため高いコスト効率でテーブルの断面を保持することが可能です。   他にも様々な場面で RDB から Iceberg テーブルへのデータ連携が有効なソリューションになりえます。これを実装や管理・運用の手間を低く抑えて実現することができる 1 つの手段が TROCCO の CDC 機能になります。 TROCCO とは TROCCO は、データの収集・加工・転送を簡単に実現できるデータ基盤構築・運用の支援 SaaS です。ノーコード/ローコードでデータパイプラインを構築でき、多様なデータソースとデスティネーションに対応しています。 今回ご紹介する TROCCO の CDC 機能 は、ソーステーブルの変更（INSERT/UPDATE/DELETE）やカラムの追加といったスキーマの変更をリアルタイムに検知し、ターゲットシステムへ自動的に反映することをインフラの管理なく実現することができる機能です。ソース DB としては、2025 年 12 月時点で MySQL と PostgreSQL に対応しています。(CDC 機能は Professional プランの契約が前提となります。) 今回はその中の、ソースの MySQL から ターゲットの AWS 上の Glue Data Catalog に登録された Iceberg テーブルにデータ連携する方法をご紹介します。 アーキテクチャ概要 今回構築するシステムのアーキテクチャは以下の通りです： ソース : MySQL データベース(8.x 以降推奨） CDC 処理 : TROCCO CDC 機能 ターゲット : Amazon S3 + AWS Glue Data Catalog（Apache Iceberg 形式） クエリエンジン : Amazon Athena TROCCO が MySQL のバイナリログを監視し、変更を検知すると、その変更を Iceberg 形式で Amazon S3 に書き込みます。 Glue Data Catalog にメタデータが登録されるため、Athena から即座にクエリ可能になります。 セットアップ手順 1. ネットワーク設定 TROCCO から MySQL へ接続するため、セキュリティグループの設定が必要です。TROCCO の固定 IP アドレスからの接続を許可します。 TROCCO の固定 IP アドレスは 公式ドキュメント で確認できます。また、エフェメラルポートとして 1024-65535 を使用するため、セキュリティグループでこの範囲を開放する必要があります。 2. IAM ロールの作成 TROCCO が S3 と Glue Data Catalog にアクセスするため、適切な権限を持つ IAM ロールを作成します。CDC 機能では IAM ロールのみがサポートされています（IAM ユーザーは使用できません）。 TROCCO のドキュメント  にある必要な IAM ポリシーの例はこのようなものになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": "arn:aws:s3:::<bucket_name>" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::<bucket_name>/*" }, { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:UpdateDatabase", "glue:CreateDatabase" ], "Resource": [ "arn:aws:glue:<aws_region>:<account_id>:catalog", "arn:aws:glue:<aws_region>:<account_id>:database/<database_name>" ] }, { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:UpdateTable", "glue:CreateTable", "glue:DeleteTable" ], "Resource": [ "arn:aws:glue:<aws_region>:<account_id>:catalog", "arn:aws:glue:<aws_region>:<account_id>:database/<database_name>", "arn:aws:glue:<aws_region>:<account_id>:table/<database_name>/*" ] } ] } ターゲットの Iceberg テーブルの Location である S3 と 該当の Glue Data Catalogへのアクセス権限が必要になります。 3. TROCCO 接続情報の設定 TROCCO の管理画面から、以下の接続情報を登録します。 Amazon S3 の接続情報: IAM Role の ARN、S3 バケット名、リージョン MySQL の接続情報: ホスト名、ポート、データベース名、ユーザー名、パスワード まずは Amazon S3 への接続情報を設定する必要があります。 AWS アカウント ID、先ほど 2 番で作成した IAM Role を設定します。                 また、下部に表示される TROCCO の AWS アカウントと外部 ID を先ほど作成した IAM Role に設定します。             IAM Role の 信頼ポリシーは以下のようになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{TROCCO AWS Account ID}:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": {External ID}" } } } ] } 次に、MySQL 接続情報を設定します。接続先 DB のホスト、ポート、ユーザー名、パスワードが必要になります。この設定をする前に ソース DB 側で binlogの設定 が必要になることに注意してください。                 4. CDC 転送設定の作成 今作成した接続情報を元に、TROCCO の管理画面から新しい CDC 転送設定を作成します。                 ここで、この CDC データ転送機能の特徴であるテーブルやカラムの自動追従に関する設定が可能です。テーブル・カラムどちらも追従する、カラムのみ追従する、追従しないの  3 パターンが選択できます。                             先ほど設定した MySQL と S3 の接続情報をここで選択します。S3 の設定については Iceberg のプレフィックスやターゲットテーブルの Glue データベースも選択する必要があります。 設定はなんとこれだけで完了です！ 主要な機能 それでは先ほど作成した CDC データ転送設定を実行してみます。                 データ連携 初回実行時にはフルロードが実行され、ソーステーブルの既存データがすべて Iceberg テーブルに転送されます。なお、スキーマ設定より連携するテーブルは選択することができます。 初回のフルロード完了後は、スケジュール設定に従って MySQL のバイナリログを監視して差分更新を継続的に実行します。スケジュールは最短 5 分間隔で設定可能です。 スキーマ変更の自動追従 TROCCO の CDC 機能は、ソースデータベースのスキーマ変更を自動的に検知し、Iceberg テーブルに反映します。 カラム追加の場合、新しいカラムが Iceberg テーブルに自動的に追加されます。既存レコードの新規カラムは NULL になります。バックフィル機能を有効にすると、全レコードを再転送できますが、Iceberg のスナップショット履歴が失われる点に注意が必要です。詳細は こちら をご覧ください。 カラム削除の場合、TROCCO 側では該当カラムのデータ転送が停止されますが、Iceberg テーブルからカラムは削除されません。必要に応じて手動での削除が必要です。 連携するテーブル・カラムの選択                     転送するテーブルやその中のカラムを選択できるため、機密情報を含むカラムを除外したり、不要なカラムを転送しないことでコストを最適化することも簡単にできます。 その他にも、事前に通知先を設定しておくことで、ジョブの実行結果やスキーマ変更の通知を E-mail や Slack に行うことも可能です。また、ジョブの履歴やそれぞれのログについても UI 上で確認が可能になっています。   連携した Iceberg テーブルへのクエリ ジョブの実行後に AWS コンソールからGlue カタログを確認してみると、TROCCO で設定したテーブルが適切に連携されていることがわかります。               連携先の Iceberg テーブルは Athena や Glue、Redshift などさまざまなエンジンからクエリすることが可能です。Iceberg テーブルへのクエリに対応している 3rd party の製品からのクエリももちろん可能です。（ただし、Equality Delete File の読み取りに対応している必要があります。詳細は Apache Iceberg のdocument をご参照下さい。） 今回は、 SageMaker Unified Studio の AI エージェントが組み込まれたノートブック からクエリを行ってみました。下のスクリーンショットのように、連携された Iceberg テーブルを簡単にクエリすることができました。 また、AI エージェントに対して連携した Iceberg テーブルへのクエリを指示することで、クエリ文を作らせて実行することも可能です。今回は、Iceberg の特徴の一つであるスナップショットの履歴を確認したい旨を指示してみました。 `Show me snapshots history of spark_catalog.trocco.movie_table_usecase.` 実際に生成されたクエリが以下の画像です。Iceberg 特有の概念ではありますが、適切なクエリを生成して実行してくれました。結果をみるとこのテーブルには２つのスナップショットがあるようです。この ID を指定することで、過去のテーブル断面をクエリすることができます。このように、Iceberg とくゆうの機能の操作に慣れていない場合でも AI エージェントを使いながら利用することが可能です。 まとめ TROCCO の CDC 機能を使うことで、複雑な CDC パイプラインを構築することなく低い実装コストで RDB と Apache Iceberg のデータ連携を実現することが可能になります。本ブログで説明したように GUI のみで非常に簡単に設定できる上に、ジョブやソーステーブルの監視と通知の機能も UI 上で利用が可能であり、運用する上でもその負荷を下げてくれる機能が揃っています。 これによって、簡単に RDB のデータをソースとした OLAP 基盤を構築したり、タイムトラベルによるバックアップの役割を持つデータレイクへの連携パイプライン構築することが可能になります。 連携した Iceberg テーブルについて、最適なパフォーマンスが出せるようにデータファイルサイズのコンパクションや期限切れスナップショットの処理などテーブルのメンテナンスが重要です。そのため、 Glue Data Catalog の Iceberg テーブルの自動メンテナンス機能 をはじめとして、メンテナンスジョブの実行についてもご検討いただくことをおすすめします。 ぜひ AWS と そのパートナーである primeNumber 社の TROCCO を利用して効果的なデータ基盤を構築していきましょう。 著者について Shuhei Fukami : AWS Japan で Analytics Specialist Solutions Architect としてデータ分析や検索などデータにまつわるワークロードのご支援をしています。趣味でピザ作りにはまっています。

2025 年 12 月 2 日、 AWS サポート がお客様の支援方法を根本から転換し、事後対応型の問題解決から事前対応型の問題予防へと進化することを発表しました。この進化により、AI を活用した機能と Amazon Web Services (AWS) の専門知識を組み合わせた新しいサポートプランが導入されました。新しく強化されたプランは、潜在的な問題が事業運営に影響する前に特定して対処するのに役立ち、クラウドワークロードをより効果的に運用および最適化するのに役立ちます。 ポートフォリオには、さまざまな運用ニーズに合わせて設計された 3 つのプランが含まれています。各プランには異なる機能があり、上位ティアには下位ティアのすべての機能に加えて、追加機能やサービスレベルが強化されています。それぞれを見てみましょう。 新しく強化された AWS サポート有料プラン Business Support+ は、AI を活用したインテリジェントな支援を提供することで、開発者、スタートアップ、中小企業のエクスペリエンスを変革します。AWS の専門家に直接問い合わせるか、必要に応じてシームレスに AWS の専門家に移行する AI を活用した状況に応じた推奨事項から始めるかを選択できます。AWS のエキスパートは、重大なケースについて 30 分以内 (以前の 2 倍の速さ) で対応します。以前の経緯を踏まえているため、同じことを繰り返す必要がなくなります。 このプランは月額料金が安いため、AI を活用したツールと AWS の専門知識を組み合わせて高度な運用機能を利用できます。このプランでは、お客様固有の環境に基づいてワークロードを最適化できるよう、個別の推奨事項を提示します。また、必要に応じて AWS の専門家にシームレスにテクニカルサポートを受けることができます。 エンタープライズサポート は、確立されたサポートモデルに基づいて構築されています。このティアでは、インテリジェントな運用と AI を活用した信頼できるヒューマンガイダンスを通じて、イノベーションとクラウド運用の成功を促進します。担当のテクニカルアカウントマネージャー (TAM) は、AWS に関する深い知識とお客様の環境からのデータに基づくインサイトを組み合わせて、最適化の機会と潜在的なリスクが業務に影響する前に特定できるよう支援します。このプランでは、追加料金なしで AWS Security Incident Response を利用できます。これは、セキュリティイベントの追跡、保管、管理を一元化する包括的なサービスであり、セキュリティ体制を強化するための自動モニタリングおよび調査機能も提供します。 このティアは、AI を活用した支援と AWS 環境の継続的なモニタリングを通じて、運用の規模を新たなレベルに引き上げるのに役立ちます。本番稼働環境での重大な問題への対応時間は最大 15 分で、サポートエンジニアは AI エージェントからパーソナライズされたコンテキストを提供されるため、このティアでは、オペレーショナルエクセレンスを維持しながら、より迅速でパーソナライズされた解決が可能になります。さらに、継続的な技術成長を促進するためのインタラクティブなプログラムや実践的なワークショップにもアクセスできます。 Unified Operations Support は、拡張された AWS 専門家チームを通じて、状況に応じた最高レベルのサポートを提供します。テクニカルアカウントマネージャー、ドメインエンジニア、指定のシニア請求およびアカウントスペシャリストで構成されるコアチームは、移行、インシデント管理、セキュリティに関するオンデマンドの専門家によって補完されます。これらの専任エキスパートは、お客様固有の環境と運用履歴を理解し、アーキテクチャに関する知識と AI を活用したインサイトを組み合わせながら、お好みのコラボレーションチャネルを通じてガイダンスを提供します。 この階層では、24 時間体制の包括的なモニタリングと AI を活用した自動化により、プロアクティブなリスクの特定と状況に応じたガイダンスにより、ミッションクリティカルな業務を強化します。重大なインシデントが発生すると、お客様のワークロードを理解しているサポートエンジニアから技術的な推奨事項が提供され、5 分以内に対応できます。チームは、体系的なアプリケーションレビューを実施し、運用準備が整っていることを確認し、ビジネスに不可欠なイベントをサポートします。これにより、最高レベルの運用能力を維持しながら、イノベーションに集中できます。 クラウド運用の変革 AWS サポートは、クラウドインフラストラクチャをより効果的に構築、運用、最適化できるように進化しています。お客様のアカウントのサポート履歴と過去のケース、構成、以前のケースのコンテキストを維持しているため、AI を活用した機能と AWS の専門家が、お客様固有の環境に合わせた、より適切で効果的なソリューションを提供できます。 サポートプランの機能は継続的に進化し、インフラストラクチャを包括的に可視化できるようになり、パフォーマンス、セキュリティ、コストの側面にわたる実用的なインサイトが得られ、ビジネスへの影響とコスト面でのメリットを明確に評価できるようになります。この AI 搭載ツールと AWS の専門知識の組み合わせは、事後対応型から事前対応型の運用への根本的な転換を意味し、ビジネスに影響が及ぶ前に問題を未然に防ぐのに役立ちます。 AWS デベロッパーサポート、AWS ビジネスサポート (クラシック)、および AWS Enterprise On-Ramp サポートプランのサブスクライバーは、2027 年 1 月 1 日まで現在のレベルのサポートを引き続き受けることができます。それまでは、AWS マネジメントコンソールにアクセスするか、AWS アカウントチームに連絡することで、いつでも新しいプランや拡張プランのいずれかに移行できます。AWS エンタープライズサポートに登録しているお客様は、いつでもこのプランの新機能を使い始めることができます。 知っておくべきこと Business Support+、Enterprise Support、Unified Operations は、すべての商用 AWS リージョンで利用できます。既存のお客様は、現在のプランを継続することも、パフォーマンスと効率を向上させる新しいサービスを検討することもできます。 Business Support+ は月額 29 ドルからで、以前のビジネスサポートの月額最低額から 71％ 節約できます。エンタープライズサポートは月額 5,000 ドルからで、以前のエンタープライズサポートの最低価格より 67% お得です。Unified Operations は、ミッションクリティカルなワークロードを抱える組織向けに設計され、専任の AWS 専門家チームを対象としており、月額 50,000 ドルからご利用いただけます。すべての新しいサポートプランでは、使用量が多いほどサポートの限界価格が下がる価格帯が採用されています。 重大なケースについては、AWS サポートはプランごとに異なる目標応答時間を提供します。Business Support+ は 30 分、Enterprise Support は 15 分以内、Unified Operations Support は 5 分で最速の応答時間を提供します。 AWS サポートのプランと機能の詳細については、 AWS サポートページ にアクセスするか、 AWS マネジメントコンソール にサインインしてください。 AWS サポート機能に関する実践的なガイダンスについては、アカウントチームとの相談をスケジュールしてください。 原文は こちら です。

2025 年 12 月 2 日、AWS DevOps Agent のパブリックプレビューを発表しました。AWS DevOps Agent は、過去のインシデントと運用パターンを体系的に分析することで、インシデントへの対応、根本原因の特定、将来の問題の防止に役立つ フロンティアエージェント です。 フロンティアエージェントは、自律的で非常にスケーラブルで、絶え間ない介入なしに数時間または数日働く、新しいクラスの AI エージェントです。 本番稼働のインシデントが発生した場合、オンコールエンジニアは、利害関係者とのコミュニケーションを管理しながら根本原因を迅速に特定しなければならないという大きなプレッシャーに直面します。複数のモニタリングツールにわたってデータを分析し、最近のデプロイ状況を確認し、対応チームを調整する必要があります。サービスの復旧後、チームはインシデント学習を体系的な改善に変えるだけの余裕がないことがよくあります。 AWS DevOps Agent は、常時稼働している自律的なオンコールエンジニアです。問題が発生すると、メトリクスやログから GitHub や GitLab での最近のコードデプロイまで、運用ツールチェーン全体のデータを自動的に関連付けます。考えられる根本原因を特定し、的を絞った緩和策を推奨することで、解決までの平均時間を短縮できます。エージェントはインシデントの調整も行い、Slack チャンネルを使ってステークホルダーに最新情報を伝えたり、詳細な調査スケジュールを管理したりしています。 開始するには、 AWS マネジメントコンソール を使用して AWS DevOps Agent を既存のツールに接続します。このエージェントは、 Amazon CloudWatch 、 Datadog 、 Dynatrace 、 New Relic 、 Splunk などの一般的なサービスと連携してオブザーバビリティデータを取得し、GitHub Actions や GitLab CI/CD と統合してデプロイとそのクラウドリソースへの影響を追跡します。Bring Your Own (BYO) モデルコンテキストプロトコル (MCP) サーバー機能により、組織のカスタムツール、専用プラットフォーム、 Grafana や Prometheus などのオープンソースのオブザーバビリティソリューションなどの追加ツールを調査に統合することもできます。 エージェントは仮想チームメンバーとして機能し、チケットシステムからのインシデントに自動的に対応するように設定できます。 ServiceNow のサポートが組み込まれており、構成可能な ウェブフック を通じて、 PagerDuty などの他のインシデント管理ツールのイベントに対応できます。調査が進むにつれて、エージェントはチケットと関連する Slack チャンネルに検出結果を更新します。これらはすべて、エージェントが作成するインテリジェントなアプリケーショントポロジに基づいています。つまり、調査中にデプロイに関連する潜在的な原因を特定するのに役立つデプロイ履歴を含む、システムコンポーネントとその相互作用の包括的なマップです。 仕組みを見ていきましょう その仕組みを説明するために、呼び出されたときに意図的にエラーを生成する単純な AWS Lambda 関数をデプロイしました。 AWS CloudFormation スタックにデプロイしました。 ステップ 1: エージェントスペースを作成する エージェントスペースは、AWS DevOps Agent がタスクを実行する際にアクセスできる範囲を定義します。 エージェントスペースは、運用モデルに基づいて整理できます。エージェントスペースを 1 つのアプリケーションに合わせるチームもあれば、オンコールチームごとに 1 つ作成して複数のサービスを管理するチームもあります。また、一元化されたアプローチを使用する組織もあります。このデモンストレーションでは、1 つのアプリケーション用のエージェントスペースを作成する方法を説明します。このセットアップは、特定のアプリケーションの調査とリソースを分離するのに役立ち、そのコンテキスト内でのインシデントの追跡と分析が容易になります。 AWS マネジメントコンソール の AWS DevOps Agent セクションで、 [エージェントスペースの作成] を選択し、このスペースの名前を入力して、自分または他のユーザーの AWS アカウントの AWS リソースのイントロスペクションに使用する AWS Identity and Access Management (IAM) ロールを作成します。 このデモでは、AWS DevOps Agent ウェブアプリを有効にします。これについては後で詳しく説明します。これは後の段階で実行できます。 準備ができたら、 [作成] を選択します。 作成後、 [トポロジ] タブを選択します。 このビューには、AWS DevOps Agent がタスクを効率的に実行する基盤として選択した主要なリソース、エンティティ、および関係が表示されます。これは、AWS DevOps Agent がアクセスまたは表示できるすべての情報を表しているわけではなく、エージェントが現在最も関連性が高いと見なしているものだけを表しています。デフォルトでは、トポロジには自分のアカウントにある AWS リソースが含まれています。エージェントがさらにタスクを完了すると、新しいリソースを見つけてこのリストに追加します。 ステップ 2: オペレーター向けに AWS DevOps ウェブアプリを設定する AWS DevOps Agent ウェブアプリには、オンコールエンジニアが手動で調査を開始したり、関連するトポロジ要素を含む調査の詳細を表示したり、調査を誘導したり、調査に関する質問をしたりするためのウェブインターフェイスが用意されています。 オペレータアクセス リンクを選択すると、AWS コンソールのエージェントスペースからウェブアプリケーションに直接アクセスできます。または、 AWS IAM アイデンティティセンター を使用してチームのユーザーアクセスを設定することもできます。IAM アイデンティティセンターでは、ユーザーやグループを直接管理したり、ID プロバイダー (IdP) に接続したりできるため、AWS DevOps Agent ウェブアプリケーションにアクセスできるユーザーを一元的に制御できます。 この段階では、この特定のアプリケーションの調査とリソースに集中できるようにエージェントスペースがすべてセットアップされ、DevOps チームがウェブアプリを使用して調査を開始できるようになりました。 このアプリケーションの 1 回限りのセットアップが完了したので、障害が発生した Lambda 関数を呼び出します。呼び出しのたびにエラーが生成されます。Lambda エラー数に関連付けられた CloudWatch アラームが ALARM 状態になります。実際には、ServiceNow などの外部サービスからアラートを受け取る場合があります。このようなアラートを受け取ったときに自動的に調査を開始するように AWS DevOps Agent を設定できます。 このデモでは、 [調査を開始] を選択して手動で調査を開始します。 また、事前に設定された複数の開始点から選択して迅速に調査を開始することもできます。たとえば、直近にトリガーされたアラームを調査し、基礎となるメトリクスとログを分析して根本原因を特定するための [最新アラーム]、コンピューティングリソース全体にわたる高い CPU 使用率メトリクスを調査し、どのプロセスまたはサービスが過剰にリソースを消費しているかを特定するための [高 CPU 使用率]、メトリクス、アプリケーションログを分析し、障害の原因を特定してアプリケーションエラー率の最近の増加を調査する [エラーレートスパイク] などです。 [調査の詳細] 、 [調査の開始点] 、 [インシデントの日付と時刻] 、 [インシデントの AWS アカウント ID] などの情報を入力します。 AWS DevOps Agent ウェブアプリケーションでは、調査の展開をリアルタイムで見ることができます。エージェントはアプリケーションスタックを識別します。CloudWatch からのメトリクスを相互に関連付け、CloudWatch Logs や Splunk などの外部ソースからのログを調べ、GitHub からの最近のコード変更を確認し、 AWS X-Ray からのトレースを分析します。 エラーパターンを特定し、詳細な調査概要を提供します。このデモのコンテキストでは、調査の結果、これらは意図的なテスト例外であることが明らかになり、アラームにつながる関数呼び出しのタイムラインが示され、エラー処理に関するモニタリングの改善も提案されています。 エージェントは Slack の専用インシデントチャンネルを使用し、必要に応じてオンコールチームに通知し、ステークホルダーにリアルタイムのステータス更新を提供します。調査チャットインターフェイスを通じて、「どのログを分析しましたか?」などの明確な質問をすることで、エージェントと直接やり取りできます。また、「これらの特定のロググループに焦点を絞って分析を再実行する」など、追加のコンテキストを提供して調査を進めることができます。 専門家による支援が必要な場合は、ワンクリックで AWS サポートケースを作成し、エージェントの検出結果を自動的に入力し、調査チャットウィンドウから AWS サポートの専門家に直接問い合わせることができます。 このデモでは、AWS DevOps Agent が Lambda コンソール内の手動アクティビティを正しく識別して、意図的にエラーをトリガーする関数を呼び出しました 。 インシデント対応以外にも、AWS DevOps Agent は私の最近のインシデントを分析して、将来の問題を防ぐ効果の大きい改善点を特定します。 インシデントが進行中の場合、エージェントはインシデント緩和タブを通じて即時の緩和計画を提示し、サービスの迅速な復旧を支援します。緩和計画は、開発者に詳細な実装ガイダンスを提供する仕様と、 Kiro などのエージェンティックな開発ツールで構成されています。 長期的なレジリエンスについては、オブザーバビリティ、インフラストラクチャ構成、デプロイパイプラインのギャップを調べることで、潜在的な強化点を特定します。しかし、意図的なエラーを引き起こした単純なデモでは、関連する推奨事項を生成するには不十分でした。 たとえば、重要なサービスにマルチ AZ 配置や包括的なモニタリングが欠けていることが検出されるとします。その場合、エージェントは、運用上の影響や実装の複雑さなどの要素を考慮して、実装ガイダンスを含む詳細な推奨事項を作成します。今後のクイックフォローアップリリースでは、エージェントはコードバグやテストカバレッジの改善を含むように分析を拡大する予定です。 可用性 米国東部 (バージニア北部) リージョンで AWS DevOps Agent を今すぐ試すことができます。エージェント自体は米国東部 (バージニア北部) ( us-east-1 ) で実行されますが、複数の AWS アカウントにわたる任意のリージョンにデプロイされたアプリケーションをモニタリングできます。 プレビュー期間中は AWS DevOps Agent を無料で使用できますが、1 か月あたりのエージェントタスク時間数には制限があります。 本番稼働環境の問題のデバッグに数え切れないほどの夜を費やしてきた者として特に興味深く感じるのは、AWS DevOps Agent が運用上の深いインサイトと実用的で実用的な推奨事項をどのように組み合わせているかという点です。このサービスは、チームが事後対応型の消防から積極的なシステム改善に移行するのに役立ちます。 詳細を確認してプレビューにサインアップするには、 AWS DevOps Agent をご覧ください。 AWS DevOps Agent がどのように運用効率の向上に役立つのかを聞くのを楽しみにしています。 — seb 原文は こちら です。

現代のアプリケーションでは、複数段階の支払い処理、AI エージェントのオーケストレーション、または人間の決定を待つ承認プロセスなど、サービス間の複雑で長期にわたる調整がますます必要になっています。従来、これらを構築するには、状態管理を実装し、障害を処理し、複数のインフラストラクチャサービスを統合するために多大な労力が必要でした。 2025 年 12 月 2 日より、 AWS Lambda の耐久性のある関数 を使用して、使い慣れた AWS Lambda エクスペリエンス内で信頼性の高いマルチステップアプリケーションを直接構築できます。耐久性のある関数とは、すでにご存知のものと同じイベントハンドラーと統合を備えた通常の Lambda 関数です。任意のプログラミング言語でシーケンシャルコードを記述すれば、耐久性のある関数が進行状況を追跡し、障害発生時に自動的に再試行し、定義された時点で最大 1 年間実行を一時停止します。待機中のアイドルコンピューティングの費用を支払う必要はありません。 AWS Lambda の高耐久関数は、耐久実行と呼ばれるチェックポイントとリプレイのメカニズムを使用してこれらの機能を提供します。永続実行のための関数を有効にしたら、新しいオープンソースの永続実行 SDK を関数コードに追加します。次に、「steps」などの SDK プリミティブを使用してビジネスロジックに自動チェックポイントとリトライを追加し、「waits」を使用して計算料金なしで実行を効率的に中断します。実行が予期せず終了すると、Lambda は最後のチェックポイントから再開し、完了した操作をスキップしながらイベントハンドラーを最初からリプレイします。 AWS Lambda 高耐久関数の使用開始 耐久性のある関数の使用方法を説明します。 まず、 コンソールで Lambda 関数 を作成し、 [ゼロから作成者] を選択します。 [永続実行] セクションで、 [有効化] を選択します。耐久性のある関数設定は関数の作成時にのみ設定でき、既存の Lambda 関数では現在変更できないことにご注意ください。 Lambda 高耐久関数を作成したら、提供されているコードを使用して作業を開始できます。 Lambda 高耐久関数には、状態管理と回復を処理する 2 つのコアプリミティブが導入されています。 ステップ — context.step() メソッドは、ビジネスロジックに自動再試行とチェックポイントを追加します。ステップが完了すると、リプレイ中はスキップされます。 待機 — context.wait() メソッドは、指定された時間だけ実行を一時停止し、関数を終了し、計算料金なしで実行を一時停止して再開します。 さらに、Lambda の高耐久関数には、より複雑なパターンに対応するオペレーションが他にも用意されています。 create_callback() は API レスポンスや人的承認などの外部イベントの結果を待つために使用できるコールバックを作成し、 wait_for_condition() は特定の条件が満たされる (たとえば REST API をポーリングしてプロセスが完了する) まで一時停止します。また、 parallel() または map() オペレーションは高度な同時実行ユースケースに利用できます。 本番稼働準備が整った注文処理ワークフローの構築 次に、デフォルトの例を拡張して、本番稼働環境ですぐに使える注文処理ワークフローを構築しましょう。これは、外部承認にコールバックを使用し、エラーを適切に処理し、再試行戦略を設定する方法を示しています。これらのコアコンセプトに焦点を当てるために、コードは意図的に簡潔にしています。完全に実装すると、 Amazon Bedrock を使用して検証ステップを強化し、AI を活用した注文分析を追加することができます。 注文処理ワークフローの仕組みは次のとおりです。 最初に validate_order() は注文データをチェックして、すべての必須フィールドが存在することを確認します。 次に、 send_for_approval() は外部からの承認を求める命令を送信し、コールバック応答を待って、コンピューティング料金なしで実行を一時停止します。 その後、 process_order() は注文処理を完了します。 ワークフロー全体を通して、try-catch エラー処理は、実行をすぐに停止するターミナルエラーと、自動再試行をトリガーするステップ内の回復可能なエラーを区別します。 ステップ定義とメインハンドラーを含む完全な注文処理ワークフローは次のとおりです。 import random from aws_durable_execution_sdk_python import ( DurableContext, StepContext, durable_execution, durable_step, ) from aws_durable_execution_sdk_python.config import ( Duration, StepConfig, CallbackConfig, ) from aws_durable_execution_sdk_python.retries import ( RetryStrategyConfig, create_retry_strategy, ) @durable_step def validate_order(step_context: StepContext, order_id: str) -> dict: """Validates order data using AI.""" step_context.logger.info(f"Validating order: {order_id}") # 本番稼働: Amazon Bedrock を呼び出して注文の完全性と正確性を検証 return {"order_id": order_id, "status": "validated"} @durable_step def send_for_approval(step_context: StepContext, callback_id: str, order_id: str) -> dict: """Sends order for approval using the provided callback token.""" step_context.logger.info(f"Sending order {order_id} for approval with callback_id: {callback_id}") # 本番稼働: callback_id を外部承認システムに送信 # 外部システムは Lambda SendDurableExecutionCallbackSuccess を呼び出すか # 承認が完了したらこの callback_id を使って SendDurableExecutionCallbackFailure API を送信 return { "order_id": order_id, "callback_id": callback_id, "status": "sent_for_approval" } @durable_step def process_order(step_context: StepContext, order_id: str) -> dict: """Processes the order with retry logic for transient failures.""" step_context.logger.info(f"Processing order: {order_id}") # 時々失敗する不安定な API をシミュレート if random.random() > 0.4: step_context.logger.info("Processing failed, will retry") raise Exception("Processing failed") return { "order_id": order_id, "status": "processed", "timestamp": "2025-11-27T10:00:00Z", } @durable_execution def lambda_handler(event: dict, context: DurableContext) -> dict: try: order_id = event.get("order_id") # ステップ 1: 注文を検証 validated = context.step(validate_order(order_id)) if validated["status"] != "validated": raise Exception("Validation failed") # ターミナルエラー - 実行を停止 context.logger.info(f"Order validated: {validated}") # ステップ 2: コールバックを作成 callback = context.create_callback( name="awaiting-approval", config=CallbackConfig(timeout=Duration.from_minutes(3)) ) context.logger.info(f"Created callback with id: {callback.callback_id}") # ステップ 3: callback_id を使用して承認リクエストを送信 approval_request = context.step(send_for_approval(callback.callback_id, order_id)) context.logger.info(f"Approval request sent: {approval_request}") # ステップ 4: コールバックの結果を待つ # これは、外部システムが SendDurableExecutionCallbackSuccess または SendDurableExecutionCallbackFailure を呼び出すまでブロックされる approval_result = callback.result() context.logger.info(f"Approval received: {approval_result}") # ステップ 5: カスタム再試行戦略による注文を処理 retry_config = RetryStrategyConfig(max_attempts=3, backoff_rate=2.0) processed = context.step( process_order(order_id), config=StepConfig(retry_strategy=create_retry_strategy(retry_config)), ) if processed["status"] != "processed": raise Exception("Processing failed") # ターミナルエラー context.logger.info(f"Order successfully processed: {processed}") return processed except Exception as error: context.logger.error(f"Error processing order: {error}") raise error # 再発生して実行を失敗させる このコードは、いくつかの重要な概念を示しています。 エラー処理 — try-catch ブロックはターミナルエラーを処理します。未処理の例外がステップの外に投げられた場合 (検証チェックなど)、実行はすぐに終了します。これは、注文データが無効であるなど、再試行しても意味がない場合に役立ちます。 ステップ再試行 — process_order ステップ内では、例外によってデフォルト (ステップ 1) または設定された RetryStrategy (ステップ 5) に基づいて自動再試行がトリガーされます。これにより、一時的な API が使用できなくなるなどの一時的な障害が処理されます。 ログ記録 — メインハンドラーには context.logger を使用し、ステップ内では step_context.logger を使用します。コンテキストロガーは再生中の重複ログを抑制します。 次に、 order_id を使用してテストイベントを作成し、関数を非同期で呼び出して注文ワークフローを開始します。 [テスト] タブに移動し、オプションの 耐久性のある実行名 を入力して、この実行を識別します。なお、耐久性のある関数にはべき等性が組み込まれています。同じ実行名で関数を 2 回呼び出すと、2 回目の呼び出しでは複製を作成せずに既存の実行結果が返されます。 Lambda コンソールの [Durable 実行] タブに移動すると、実行状況をモニタリングできます。 ここでは、各ステップのステータスとタイミングを確認できます。実行すると、 CallbackStarted の後に InvocationCompleted と表示されます。これは、承認コールバックを待っている間にアイドル料金が発生しないように、関数が終了し、実行が一時停止されたことを示します。 これで、コンソールから [送信成功] または [送信失敗] を選択するか、プログラムで Lambda API を使用してコールバックを完了できるようになりました。 [送信成功] を選択します。 コールバックが完了すると、実行が再開され、注文が処理されます。シミュレートされた不安定な API が原因で process_order ステップが失敗すると、設定した戦略に基づいて自動的に再試行されます。すべての再試行が成功すると、実行は正常に完了します。 Amazon EventBridge による実行のモニタリング Amazon EventBridge を使用して永続的な関数の実行をモニタリングすることもできます。Lambda は実行ステータス変更イベントをデフォルトのイベントバスに自動的に送信するため、ダウンストリームのワークフローを構築したり、通知を送信したり、他の AWS サービスと統合したりできます。 これらのイベントを受信するには、デフォルトのイベントバスで次のパターンを使用して EventBridge ルールを作成します。 { "source": ["aws.lambda"], "detail-type": ["Durable Execution Status Change"] } 知っておくべきこと 留意点は以下のとおりです。 可用性 — Lambda 高耐久関数が米国東部 (オハイオ) AWS リージョンで利用できるようになりました。最新のリージョンの可用性については、 AWS Capabilities by Region ページをご覧ください。 プログラミング言語サポート — 起動時、AWS Lambda 高耐久関数は JavaScript/TypeScript (Node.js 22/24) と Python (3.13/3.14) をサポートしています。お好みのパッケージマネージャーを使用して、耐久性のある実行 SDK を関数コードにバンドルすることをお勧めします。SDK は動きが速いため、新機能が利用可能になったときに依存関係を簡単に更新できます。 Lambda バージョンの使用 — 耐久性のある関数を本番稼働環境にデプロイする場合は、Lambda バージョンを使用して、常に同じコードバージョンで再生が行われるようにしてください。実行が中断されている間に関数コードを更新すると、リプレイでは実行を開始したバージョンが使用されるため、長時間実行されるワークフローでのコード変更による不整合を防ぐことができます。 耐久性のある関数のテスト — より複雑な統合テストには、pytest 統合を備えた個別のテスト SDK と AWS サーバーレスアプリケーションモデル (AWS SAM) のコマンドラインインターフェイス (CLI) を使用して、AWS 認証情報なしで耐久性のある関数をローカルでテストできます。 オープンソース SDK —高耐久性 SDK は、 JavaScript/TypeScript および Python 向けのオープンソースです。ソースコードを確認したり、改善に貢献したり、最新の機能について最新情報を入手したりできます。 料金 — AWS Lambda 高耐久関数の料金の詳細については、 AWS Lambda の料金表 ページを参照してください。 AWS Lambda コンソール にアクセスして、AWS Lambda 高耐久関数を使い始めます。詳細については、 AWS Lambda 高耐久関数 のドキュメントページを参照してください。 構築がうまくいきますように! –  Donnie 原文は こちら です。

組織は、生成 AI の使用をビジネスのあらゆる部分で急速に拡大しています。深い専門知識や特定のビジネスコンテキストを必要とするアプリケーションには、独自の知識、ワークフロー、独自の要件を真に理解したモデルが必要です。 プロンプトエンジニアリング や 検索拡張生成 (RAG) などの手法は多くのユースケースでうまく機能しますが、モデルの核となる理解に専門知識を組み込むことに関しては基本的な制限があります。教師ありファインチューニングと強化学習はモデルのカスタマイズに役立ちますが、開発ライフサイクルの後半になってしまい、十分にトレーニングされたモデルの上に修正が重ねられるため、特定の関心領域への誘導が困難になります。 組織が所有データのみを使用して 継続的な事前トレーニング (CPT) を通じてより深いカスタマイズを試みると、モデルが新しいコンテンツを学習する過程で基本的な機能が失われるという、破滅的忘却に陥ることがよくあります。同時に、モデルをゼロからトレーニングするのに必要なデータ、コンピューティング、コストは、ほとんどの組織にとって依然として大きな障壁となっています。 2025 年 12 月 2 日は、Nova を使用して独自のフロンティアモデルを構築するための新しいサービス、 Amazon Nova Forge をご紹介します。Nova Forge のお客様は、初期のモデルチェックポイントから開発を開始し、データセットを Amazon Nova が収集したトレーニングデータとブレンドし、カスタムモデルを AWS で安全にホストできます。Nova Forge は、独自のフロンティアモデルを構築するための最も簡単で費用対効果の高い方法です。 ユースケースとアプリケーション Nova Forge は、独自のデータや業界固有のデータにアクセスでき、自社の領域を真に理解する AI を構築したい組織向けに設計されています。これには以下が含まれます。 製造と自動化 — 特殊なプロセス、機器データ、業界固有のワークフローを理解するモデルの構築 研究開発 — 独自の研究データとドメイン固有の知識に基づいてトレーニングされたモデルの作成 コンテンツとメディア — ブランドボイス、コンテンツ基準、特定のモデレーション要件を理解するモデルの開発 専門業界 — 業界固有の用語、規制、ベストプラクティスに関するトレーニングモデル 特定のユースケースによっては、Nova Forge を使用して差別化された機能の追加、タスク固有の精度の向上、コストの削減、レイテンシの削減を行うことができます。 Nova Forge の仕組み Nova Forge は、トレーニング前、トレーニング中、トレーニング後の各フェーズにわたる初期のチェックポイントからモデル開発を開始できるようにすることで、現在のカスタマイズアプローチの制限に対処します。 Amazon SageMaker AI の完全マネージド型インフラストラクチャで実証済みのレシピを使用してトレーニングを実施することで、すべてのトレーニングフェーズで所有データを Amazon Nova が収集したデータと組み合わせることができます。このデータミキシングアプローチは、生データのみを使ったトレーニングと比較して、破滅的忘却を大幅に減らし、専門知識を取り入れながら、コアインテリジェンス、一般的な指示に従う能力、安全上の利点などの基礎スキルを維持するのに役立ちます。 Nova Forge では、独自の環境で報酬関数を使用して 強化学習 (RL) を行うことができます。これにより、モデルはユースケースを代表する環境で生成されたフィードバックから学習できます。単一ステップの評価だけでなく、独自のオーケストレーターを使用してマルチターンのロールアウトを管理することもできます。これにより、複雑なエージェントワークフローや一連の意思決定タスクのための RL トレーニングが可能になります。化学ツールを使用して分子設計を採点する場合でも、効率的にタスクを完了して衝突を罰するロボットシミュレーションを使用する場合でも、独自の環境を直接接続できます。 また、Nova Forge に組み込まれている責任ある AI ツールキットを活用して、モデルの安全性とコンテンツモデレーションの設定を構成することもできます。安全、セキュリティ、機密コンテンツの処理など、特定のビジネスニーズに合わせて設定を調整できます。 Nova Forge の使用開始 Nova Forge は既存の AWS ワークフローとシームレスに統合されます。Amazon SageMaker AI の使い慣れたツールとインフラストラクチャを使用してトレーニングを実行し、カスタム Nova モデルをプライベートモデルとして Amazon Bedrock にインポートできます。これにより、Amazon Bedrock の他のモデルと同じセキュリティ、一貫性のある API、幅広い AWS 統合が可能になります。 Amazon SageMaker Studio では、Amazon Nova を使用してフロンティアモデルを構築できるようになりました。 モデルの構築を開始するには、使用するチェックポイント (事前トレーニング済み、中間トレーニング済み、トレーニング後チェックポイント) を選択します。ここにデータセットをアップロードするか、既存のデータセットを使用することもできます。 Nova が提供する厳選されたデータセットを組み合わせることで、トレーニングデータをブレンドできます。これらのデータセットはドメイン別に分類されているため、モデルが一般的なパフォーマンスを維持し、オーバーフィットや破滅的忘却を防ぐのに役立ちます。 オプションで、強化ファインチューニング (RFT) を使用して事実の正確性を高め、特定の領域でのハルシネーションを減らすこともできます。 トレーニングが完了したら、モデルを Amazon Bedrock にインポートして、アプリケーションで使用を開始します。 知っておくべきこと Amazon Nova Forge は米国東部 (バージニア北部) AWS リージョン でご利用いただけます。このプログラムには、複数の Nova モデルチェックポイントへのアクセス、所有データと Amazon Nova が収集したトレーニングデータを組み合わせるトレーニングレシピ、実証済みのトレーニングレシピ、Amazon SageMaker AI と Amazon Bedrock との統合が含まれます。 詳細については「 Amazon Nova ユーザーガイド 」をご覧ください。また、 Amazon SageMaker AI コンソール から Nova Forge を試してみてください。 専門家による支援を希望する組織は、 生成 AI イノベーションセンター に連絡し、モデル開発イニシアチブに関する追加サポートを受けることもできます。 – Danilo 原文は こちら です。

2025 年 12 月 2 日、 ストレージのパフォーマンスと使用パターンをより深く理解できる Amazon S3 ストレージレンズ の 3 つの新機能を発表しました。パフォーマンスメトリクスの追加、数十億のプレフィックスの分析のサポート、 Amazon S3 Tables への直接エクスポートにより、アプリケーションパフォーマンスの最適化、コストの削減、Amazon S3 ストレージ戦略に関するデータ主導の意思決定に必要なツールが手に入ります。 新しいパフォーマンスメトリクスカテゴリー S3 ストレージレンズには、組織全体のパフォーマンス制約の特定と解決に役立つ 8 つの新しいパフォーマンスメトリクスカテゴリーが追加されました。これらは組織、アカウント、バケット、プレフィックスレベルで利用できます。たとえば、このサービスは、アプリケーションのパフォーマンスを低下させる可能性のあるバケットまたはプレフィックス内の小さなオブジェクトを識別するのに役立ちます。これは、 Amazon S3 Express One Zone ストレージクラスを使用してスモールオブジェクトワークロードのパフォーマンスを向上させるためにスモールオブジェクトをバッチ処理することで軽減できます。 新しいパフォーマンスメトリクスにアクセスするには、新しいストレージレンズダッシュボードを作成するとき、または既存の設定を編集するときに、S3 ストレージレンズアドバンストティアのパフォーマンスメトリクスを有効にする必要があります。 メトリクスカテゴリー 詳細 ユースケース 緩和策 読み取りリクエストサイズ 読み取りリクエストサイズ (GET) の日別分布 パフォーマンスを低下させる小さな読み取りリクエストパターンを持つデータセットを特定 小規模なリクエスト: 小さなオブジェクトをバッチ処理するか、Amazon S3 Express One Zone を使用して高性能の小さなオブジェクトワークロードにする 書き込みリクエストサイズ 書き込みリクエストのサイズ (PUT、POST、COPY、およびアップロードパート) の日別分布 パフォーマンスを低下させる小さな書き込みリクエストパターンを持つデータセットを特定 大規模なリクエスト: リクエストを並列化、MPU を使用、または AWS CRT を使用 ストレージサイズ オブジェクトタグの分布 パフォーマンスを低下させる小さなオブジェクトを持つデータセットを特定 小さなオブジェクトのサイズ: 小さなオブジェクトをまとめることを検討 同時に発生する PUT 503 エラー 同じオブジェクトに対する同時 PUT 操作による 503 の数 パフォーマンスを低下させる同時 PUT スロットリングのあるプレフィックスを特定 シングルライターの場合は、再試行の動作を変更するか、Amazon S3 Express One Zone を使用します。複数のライターの場合は、コンセンサスメカニズムを使用するか、Amazon S3 Express One Zone を使用 クロスリージョンデータ転送 リージョン内のリージョン間で転送されたバイト数と送信されたリクエスト数 地域間のデータアクセスによる潜在的なパフォーマンスとコストの低下を特定 コンピューティングを同じ AWS リージョンのデータと同じ場所に配置 ユニークオブジェクトへのアクセス 1 日あたりにアクセスされたユニークオブジェクトの数または割合 オブジェクトのごく一部が頻繁にアクセスされるデータセットを特定。これらをよりパフォーマンスの高いストレージティアに移動してパフォーマンスを向上させることができます アクティブなデータを Amazon S3 Express One Zone または他のキャッシュソリューションに移動することを検討 ファーストバイトのレイテンシー (既存の Amazon CloudWatch メトリクス) 1 バイト目のレイテンシーメトリクスの日次平均値 リクエストが完了してからレスポンスが返され始めるまでのリクエストごとの日次平均時間 合計リクエストレイテンシー (既存の Amazon CloudWatch メトリクス) 合計リクエストレイテンシーの日次平均値 最初のバイトが受信されてから最後のバイトが送信されるまでのリクエストごとの日平均経過時間 仕組み Amazon S3 コンソール で [ストレージレンズダッシュボードを作成] を選択して新しいダッシュボードを作成します。既存のダッシュボード設定を編集することもできます。次に、 ダッシュボード名 、 ステータス 、オプションの タグ を指定するなどの一般的な設定を行います。 その後、 [次へ] を選択します。 次に、 [すべてのリージョンを含める] と [すべてのバケットを含める] を選択し、含めるリージョンとバケットを指定して、ダッシュボードの範囲を定義します。 ストレージレンズダッシュボード設定で [アドバンストティア] を選択し、 [パフォーマンスメトリクス] を選択して [次へ] を選択します。 次に、追加のメトリクス集計として [プレフィックス集計] を選択し、残りの情報はデフォルトのままにしてから [次へ] を選択します。 [デフォルトメトリクスレポート] を選択し、次にバケットタイプとして [汎用バケット] を選択し、AWS アカウントの Amazon S3 バケットを [宛先バケット] として選択します。残りの情報はデフォルトのままにして、 [次へ] を選択します。 すべての情報を確認してから、 [送信] を選択してプロセスを終了します。 有効にすると、 ストレージレンズコンソール のダッシュボードに毎日のパフォーマンスメトリクスが直接表示されます。レポートを CSV 形式または Parquet 形式でアカウント内の任意のバケットにエクスポートするか、Amazon CloudWatch に公開するかを選択することもできます。パフォーマンスメトリクスは毎日集計および公開され、組織、アカウント、バケット、プレフィックスといった複数のレベルで利用できます。このドロップダウンメニューで、 [メトリクス] に同時 PUT 503 エラー率 (%)、 [日付範囲] に [過去 30 日間]、 [上位 N バケット] に 10 を選択します。 同時 PUT 503 エラー数メトリクスは、同じオブジェクトに対する同時 PUT 操作によって生成された 503 エラーの数を追跡します。スロットリングエラーはアプリケーションのパフォーマンスを低下させる可能性があります。シングルライターの場合は、再試行の動作を変更するか、Amazon S3 Express One Zone などのよりパフォーマンスの高いストレージティアを使用して、同時発生する PUT 503 エラーを軽減します。複数のライターのシナリオでは、コンセンサスメカニズムを使用して PUT 503 エラーが同時に発生しないようにするか、Amazon S3 Express One Zone などのよりパフォーマンスの高いストレージティアを使用します。 S3 バケット内のすべてのプレフィックスの完全な分析 S3 ストレージレンズは、新しい 拡大プレフィックスメトリクスレポート を通じ、S3 バケット内のすべてのプレフィックスの分析をサポートするようになりました。この機能により、サイズ閾値 1%、最大深度 10 レベルを満たすプレフィックスに分析を制限していた以前の制限がなくなりました。サイズや深さに関係なく、バケットごとに最大数十億のプレフィックスを追跡して、最も詳細なプレフィックスレベルで分析できるようになりました。 拡大プレフィックスメトリクスレポートには、既存の S3 ストレージレンズメトリクスカテゴリー (ストレージ使用量、アクティビティメトリクス (転送されたリクエストとバイト数)、データ保護メトリクス、詳細なステータスコードメトリクスが含まれます。 開始方法 「 仕組み 」セクションで説明されているのと同じ手順に従って、ストレージレンズダッシュボードを作成または更新します。エクスポートオプションを選択するコンソールのステップ 4 では、新しい Expanded prefix メトリクスレポート を選択できます。その後、拡張プレフィックスメトリクスレポートを CSV または Parquet 形式でアカウントの任意の汎用バケットにエクスポートして、ストレージレンズデータを効率的にクエリできます。 知っておくと便利な情報 この機能強化は、組織がプレフィックス構造全体をきめ細かく可視化する必要があるシナリオに対応します。たとえば、マルチパートアップロードが不完全なプレフィックスを特定してコストを削減したり、暗号化とレプリケーションの要件についてプレフィックス構造全体のコンプライアンスを追跡したり、最も詳細なレベルでパフォーマンスの問題を検出したりできます。 S3 ストレージレンズメトリクスを S3 Tables にエクスポート S3 ストレージレンズメトリクスを S3 Tables に自動的にエクスポートできるようになりました。これは、Apache Iceberg サポートが組み込まれた AWS のフルマネージド機能です。この統合により、AWS が管理する S3 Tablesにメトリクスが毎日自動的に配信され、追加の処理インフラストラクチャを必要とせずにすぐにクエリを実行できます。 開始方法 まず、コンソールでステップ 5 で説明したプロセスに従い、エクスポート先を選択します。今回は、 [拡張プレフィックスメトリクスレポート] を選択します。汎用バケットに加えて、 [テーブルバケット] を選択します。 新しいストレージレンズメトリクスは AWS マネージドバケット aws-s3 の新しいテーブルにエクスポートされます。 拡張プレフィックスレポートの API 使用メトリクスを表示するには、 expanded_prefixes_activity_metrics テーブルを選択します。 Amazon S3 コンソールでテーブルをプレビューすることも、 Amazon Athena を使用してテーブルをクエリすることもできます。 知っておくと便利な情報 S3 Tables と S3 ストレージレンズの統合により、データパイプラインを必要とせずに、使い慣れた SQL ツールと Amazon Athena、 Amazon QuickSight 、 Amazon EMR 、 Amazon Redshift などの AWS 分析サービスを使用してメトリクス分析を簡素化できます。メトリクスは自動的に整理されて最適なクエリが実行されるようになり、必要に応じて保存と暗号化のオプションをカスタマイズできます。 この統合により、クロスアカウントおよびクロスリージョンの分析、カスタムダッシュボードの作成、および他の AWS サービスとのデータ相関が可能になります。たとえば、ストレージレンズメトリクスと S3 メタデータを組み合わせて、プレフィックスレベルのアクティビティパターンを分析し、低コストのストレージティアへの移行に適格なコールドデータを含むプレフィックス内のオブジェクトを特定できます。 エージェンティック AI ワークフローでは、自然言語を使用して S3 Tables MCP サーバー で S3 Tablesの S3 ストレージレンズメトリクスをクエリできます。エージェントは、「先月最も増加したバケットはどれか」などの質問をすることができます。または「ストレージクラス別のストレージコストを見せて」と、オブザーバビリティデータから即座にインサイトを得ることができます。 今すぐご利用いただけます 3 つの拡張機能はすべて、S3 ストレージレンズが現在提供されているすべての AWS リージョン (中国リージョンと AWS GovCloud (米国) を除く) で利用できます。 これらの機能は Amazon S3 ストレージレンズアドバンスドティアに含まれており、標準アドバンストティアの価格を超える追加料金はありません。S3 Tables のエクスポートでは、S3 Tables のストレージ、メンテナンス、クエリに対してのみお支払いいただきます。エクスポート機能自体に追加料金はかかりません。 Amazon S3 ストレージレンズのパフォーマンスメトリクス、数十億のプレフィックスのサポート、S3 Tables へのエクスポートの詳細については、「 Amazon S3 ユーザーガイド 」を参照してください。料金の詳細については、 Amazon S3 料金表ページ をご覧ください。 Veliswa Boya 。 原文は こちら です。

2025 年の初めに 、Nova Act のリサーチプレビューをリリースしました。これは、AI エージェントがユーザーインターフェイスと相互作用し、複雑なワークフローを自動化する可能性を実証したものです。開発者は Nova Act を試して、これらの自動化エージェントを本番稼働環境に導入したいと私たちに話しました。 しかし、エージェントを本番稼働環境に持ち込むには、モデルへのアクセスだけでは不十分でした。開発者は、信頼性の高い自動化を実現するために、ワークフローの調整、プロンプトの改良、適切なツールの選択、さまざまなコンポーネントの統合に多大な時間を費やしていました。課題はインテリジェンスだけではなく、信頼性、統合、本番稼働環境までのスピードでした。そこで、本番稼働環境ですぐに使えるブラウザ自動化のための完全に統合されたソリューションを構築しました。 2025 年 12 月 2 日、 Amazon Nova Act が一般公開されたことを発表しました。これは、開発者が本番稼働 UI ワークフローを自動化するための信頼性の高い AI エージェント群を構築、デプロイ、管理するのに役立つ新しい Amazon Web Services (AWS) サービスです。Nova Act は、大規模環境において 90％ 以上の信頼性を提供すると同時に、他の AI フレームワークと比較して、価値創出までの時間が最も短く、実装が容易です。 Nova Act コンソールを簡単に見てみましょう。 Nova Act は、企業規模で信頼性の高いブラウザ自動化を構築するという課題に対処します。カスタム Amazon Nova 2 Lite モデルを搭載した Nova Act は、ブラウザの操作、API 呼び出しのサポート、必要に応じた人へのエスカレーションといった点で優れています。このサービスには、ウェブ品質保証 (QA) テスト、データ入力、データ抽出、チェックアウトフローのコア機能があります。 今日のほとんどのモデルは、タスクを実行するオーケストレーターやアクチュエーターとは別に個別にトレーニングされているため、信頼性が低下します。Nova Act は、エージェントが現実世界の UI をシミュレートするカスタム合成環境 (「ウェブジム」) 内で動作する一方で、強化学習を使用することでこれに対するアプローチが異なります。モデル、オーケストレーター、ツール、SDK をすべて一緒にトレーニングして垂直統合することで、大規模環境でも高い完成率を実現できます。その結果、時折機能するだけでなく、変化に対処するための推論と適応性を備えた、大規模でも信頼できるエージェンティックなシステムが生まれました。 FortiCNP の使用開始 Nova Act は、プロトタイプから本番稼働まで数時間で完了する統合開発エクスペリエンスを提供します。次に、その工程を示します。 プレイグラウンドから始める まず、 nova.amazon.com/act にアクセスして Nova Act Playground にアクセスします。そこでは、Nova Act をすばやく実験し、実際の動作を確認できます。 これらのテストには、Nova Act エージェントのテスト用に設計されたシミュレートされたブラウザ環境である Nova Act Gym を使用します。 架空の旅行予約ウェブサイト を使って、地球型太陽系外惑星に行きます。 ここでは、コードを記述しなくても、自然言語コマンドを使用してワークフローのプロトタイプをすばやく作成できます。自動化する URL を入力し、Nova Act が実行する必要のあるアクションについて説明します。 [アクションを追加] を選択すると、さらにアクションを追加できます。 アクションを定義したら、ライブブラウザセッションで Nova Act エージェントを実行します。これにより、自動化アプローチが期待どおりに機能することを検証できます。 ワークフローを検証したら、それをエクスポートして、 Visual Studio Code (VS Code) 、 Kiro 、 Cursor などの 統合開発環境 (IDE) で開発を続けることができます。 IDE で絞り込む この段階では、サポートされている IDE で自動化を改良する必要があります。Kiro を使用し、 Nova Act 拡張機能プラグインをインストールします。 この拡張モジュールは、各ステップを個別にテストおよびデバッグできるノートブックスタイルのビルダーモードを提供します。ライブブラウザビューにはエージェントが何をしているかが正確に表示され、実行ログにはモデルの理由とアクションが表示されます。これにより、ワークフローの改善とエッジケースの処理が簡単になります。 IDE で Nova Act 拡張機能を使用する方法については、 AWS ニュースブログの「Nova Act IDE 拡張機能で AI エージェント開発を加速」 を参照してください。Nova Act 拡張機能には、一般的なワークフローパターンをすばやく使い始めるのに役立つテンプレートが含まれています。 今回のリリースでは、Nova Act IDE 拡張機能に、認証、ビルダーモード、デプロイ、実行ワークフロー専用のタブが導入され、開発ライフサイクル全体が IDE に取り込まれます。この拡張機能は本番稼働環境への最も簡単な方法ですが、開発者は Nova Act コマンドラインインターフェイス (CLI) または SDK を直接使用して、より高度なデプロイ設定を行うこともできます。 AWS にデプロイ ワークフローの本番稼働環境が整ったら、 [デプロイ] タブに移動して AWS に直接デプロイします。ワークフロー定義名 (スクリプト内の名前と一致する必要があります) を入力し、 AWS リージョン を選択し、オプションで既存の AWS Identity and Access Management (IAM) ロールの Amazon リソースネーム (ARN) を指定します。この拡張機能は、ワークフローを Docker コンテナにパッケージ化し、 Amazon Elastic Container Registry (Amazon ECR) にプッシュし、必要な IAM ロールと Amazon Simple Storage Service (Amazon S3) バケットを作成し、それを Amazon Bedrock AgentCore Runtime にデプロイします。 デプロイ後は、Nova Act コンソールでワークフローの実行をモニタリングできます。 [ワークフロー定義] に移動します。コンソールにはオブザーバビリティダッシュボードがあり、ワークフローに人間の入力が必要な場合、スーパーバイザーが介入するように通知するカスタムダッシュボードを設定します。 次に、ワークフロー定義を選択するには、下にスクロールして、実行されたワークフローを探します。 ここでは、ワークフローの実行に関する詳細情報を確認できます。 ここから、ワークフローの進行状況と実行ログを追跡します。各ステップには、エージェントの理由、アクション、ブラウザのスクリーンショットが表示されます。IDE で開発していたときと同じレベルの可視性で、本番稼働環境の実行を大規模にモニタリングできるようになりました。 実験から本番稼働環境へのこの簡単な移行により、異なるツールやオーケストレーションロジックをつなぎ合わせるのに通常何週間も費やす必要がなくなります。 組み合わせるとより強力: Nova Act と Strands Agents エージェントシステムが成熟するにつれ、専門のエージェントがシームレスに連携する必要性が不可欠になります。Nova Act は Strands Agents フレームワークと自然に統合されるため、カスタム統合作業なしで包括的なマルチエージェントワークフローを構築できます。Strands はドメイン間のエージェントシステムを調整するためのオーケストレーション層を提供し、Nova Act はブラウザ主体の UI 自動化に特化した信頼性を提供します。このようなすぐに使用できる互換性は、現代のエージェントアーキテクチャ、つまり複雑なビジネス上の問題を解決するために統合される専用コンポーネントがどのように機能すべきかを反映しています。 開発者は Strands を使用して複雑なワークフローを調整できます。Nova Act はブラウザ自動化コンポーネントを特殊なツールとして扱い、それらを他のエージェントと組み合わせます。チームはこのアーキテクチャを使用して、Strands によってオーケストレーションされたより広範なエージェントエコシステム内で、Nova Act 専用の UI 自動化機能を活用できます。 知っておくべきこと 留意点は以下のとおりです。 統合 — Strands Agents フレームワークと連携して、ドメイン全体で複雑なマルチエージェントワークフローを構築します。 料金 — 詳細については、 Amazon Nova Act の料金表ページ をご覧ください。 Nova Act と責任ある AI — Nova Actには、 責任ある AI の使用を促進するための安全管理機能とコンテンツモデレーション機能が組み込まれており、推論の進歩、エージェントの安全性、敵対的攻撃に対する堅牢性を組み込んでいます。 可用性 — Amazon Nova Act が米国東部 (バージニア北部) AWS リージョンで利用できるようになりました。最新のリージョンの可用性については、 AWS Capabilities by Region ページをご覧ください。 Nova Act を使い始めるには、 nova.amazon.com/act にアクセスし、API キーを入手してプレイグラウンドを探索します。 ハッピーオートメーション! — Danilo & Donnie 原文は こちら です。

2025 年 12 月 2 日、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと Amazon Elastic Container Service (Amazon ECS) タスクの 2 つの攻撃シーケンス検出結果を追加した、 Amazon GuardDuty Extended Threat Detection の新しい拡張機能を発表しました。これらの新しい検出結果は、既存の Extended Threat Detection 機能に基づいており、 AWS Identity and Access Management (IAM) の認証情報の悪用、異常な Amazon Simple Storage Service (Amazon S3) バケットアクティビティ、 Amazon Elastic Kubernetes Service (Amazon EKS) クラスター侵害などのシーケンスをすでに組み合わせています。今回の発表では、EC2 インスタンスグループと ECS クラスターの対象範囲を追加することで、同じアプリケーションをサポートする仮想マシンとコンテナ環境へのシーケンスレベルの可視性が拡大されます。これらの機能を組み合わせることで、さまざまな Amazon Web Services (AWS) ワークロードにわたる多段階のアクティビティをより一貫性のある統一された方法で検出できます。 現代のクラウド環境は動的で分散されており、多くの場合、仮想マシン、コンテナ、サーバーレスワークロードを大規模に実行しています。セキュリティチームは、これらの環境全体の可視性を維持し、複雑で多段階の攻撃シーケンスを示す可能性のある関連アクティビティを結び付けるよう努めています。これらのシーケンスには、初期アクセスと永続性の確立、不足している認証情報の提供、予期しないデータアクセスの実行など、複数のステップが含まれる場合があります。これらのステップは、時間の経過とともに、さまざまなソースにわたって展開されます。GuardDuty Extended Threat Detection は、AWS 規模でトレーニングされた AI と 機械学習 (ML) モデルを使用してこれらのシグナルを自動的にリンクし、アクティビティの全体像を構築し、顧客が対応アクションの優先順位を決めるのに役立つ信頼性の高いインサイトを提示します。この分析では、さまざまな情報源からのエビデンスを組み合わせることにより、個々の事象から推測するのが困難な、忠実度の高い統一された検出結果が得られます。 仕組み Extended Threat Detection は、ランタイムアクティビティ、マルウェア検出、 VPC フローログ 、DNS クエリ、 AWS CloudTrail イベントなど、複数のタイプのセキュリティシグナルを分析して、Amazon EC2 および Amazon ECS ワークロードにわたる多段階攻撃のパターンを特定します。検出は GuardDuty 基本プラン と連携します。EC2 または ECS の ランタイムモニタリング を有効にすると、プロセスやネットワークレベルのテレメトリが深まり、シグナル分析が強化され、各攻撃シーケンスの完全性が向上します。 新しい攻撃シーケンスの検出結果は、ランタイムと環境全体で観察されたその他の動作を 1 つのクリティカルな重大度シーケンスにまとめたものです。各シーケンスには、インシデントの概要、観察されたイベントのタイムライン、マッピングされた MITRE ATT&CK® の戦術とテクニック、およびアクティビティがどのように展開され、どのリソースが影響を受けたかを理解するのに役立つ修復ガイダンスが含まれています。 EC2 インスタンスと ECS タスクは多くの場合、Auto Scaling グループ、共有起動テンプレート、 Amazon マシンイメージ (AMI) 、IAM インスタンスプロファイル、またはクラスターレベルのデプロイによって自動的に作成および置き換えられます。これらのリソースは通常、同じアプリケーションの一部として動作するため、リソース全体で見られるアクティビティは、1 つの根本的なセキュリティ侵害が原因である可能性があります。EC2 と ECS の新しい検出結果は、これらの共有属性を分析し、GuardDuty がグループに影響を及ぼすパターンを検出すると、関連するシグナルを 1 つのシーケンスに統合します。 シーケンスが検出されると、 GuardDuty コンソール は、該当する EC2 インスタンスグループまたは ECS クラスターがすでに特定されている状態で、重大度が高いシーケンスの検出結果を [概要] ページに強調表示します。検出結果を選択すると、リソースがどのように接続されているか、シーケンスに寄与したシグナル、アクティビティの経時的な進行状況を示す統合ビューが開き、仮想マシンとコンテナのワークロード全体にわたる影響範囲をすばやく把握できます。 コンソールでシーケンスを表示できるだけでなく、これらの結果は AWS Security Hub でも確認できます。新しい公開ダッシュボードには、他の GuardDuty 検出結果と一緒に表示されるため、全体的なセキュリティリスクを 1 か所で把握するのに役立ちます。この詳細なビューにより、分析によって関連するシグナルがどのようにしてより広範な攻撃シーケンスにまとめられるかを解釈するためのコンテキストが確立されます。 分析モデルとグルーピングロジックを組み合わせることで、仮想マシンとコンテナのワークロード全体のアクティビティをより明確かつ統合的に把握できるため、多数の検出結果を個別に調査する代わりに、重要なイベントに集中できます。Extended Threat Detection は、関連する行動を 1 つのシーケンスに統合することで、攻撃経路の全容を評価し、最も緊急な修復アクションに優先順位を付けるのに役立ちます。 今すぐご利用いただけます EC2 インスタンスと ECS タスクの対象範囲が拡大された Amazon GuardDuty Extended Threat Detection を、GuardDuty が提供されているすべての AWS リージョン で利用できるようになりました。今すぐこの機能を使用して、ランタイムアクティビティ、マルウェア実行、AWS API アクティビティからのシグナルを組み合わせることで、仮想マシンとコンテナのワークロード全体にわたる協調的な多段階アクティビティを検出できます。 この拡張により、Amazon EKS の既存の Extended Threat Detection 機能が補完され、AWS コンピューティング環境全体で調整された多段階のアクティビティを一元的に可視化できるようになります。詳細については、 Amazon GuardDuty 製品ページ にアクセスしてください。 – Betty 原文は こちら です。

本ブログは 2025 年 11 月 10 日に公開された AWS Public Sector ブログ「 Accelerating CMMC readiness: How AWS and Wiz help public sector organizations 」を翻訳したものです。 米国政府のコントラクターおよびサブコントラクターにとって、 Cybersecurity Maturity Model Certification (CMMC) の取得は片手間にこなせる仕事ではありません。この認証の取得にはリスクが伴い、要件は複雑です。国防総省 (DoD)（別名、戦争省）が新規契約および既存契約に CMMC を段階的に導入するなか、正しく対応しなければならないというプレッシャーは高まり続けています。そのため、チームや予算に過度な負担をかけることなく、CMMC 評価に備えて環境を調査する効率的でスケーラブルな方法がより強く求められています。 Amazon Web Services (AWS) と Wiz は、契約で定義された Controlled Unclassified Information (CUI) の所在を発見し、認証境界を適切なサイズに設定し、自信を持ってコンプライアンスを実証するために必要な証拠を収集することで、コントラクターがより迅速に明確性を得られるよう支援します。AWS と Wiz はこれらのプロセスを自動化することで、組織が管理リソースや組織リソースへの負担を軽減しながら、CMMC 対応準備状況を迅速に評価できるよう支援します。 2024 年 10 月 15 日に公開された CMMC 最終規則 32 CFR Part 170 は、CMMC コンプライアンスを 3 つのレベルに分類しており、レベル 1 と一部のレベル 2 コンプライアンスには自己評価で十分、一部のレベル 2 とすべてのレベル 3 にはCMMC サードパーティ評価機関 (C3PAO) による評価が必要です。Wiz と AWS は、CMMC に必要な技術インフラストラクチャとセキュリティコントロールの多くを提供し、組織が CMMC 評価を開始する前にセキュリティギャップの可能性がある箇所をより迅速に評価できるよう支援します。 次の表は、3 つのレベルのスコープ、要件、評価アプローチの概要を示しています。 図 1: Wiz と AWS は、CMMC レベル 1～3 に必要なさまざまな技術的コントロールのサポートと測定を組織が行えるよう支援します CMMC が大きな負担である理由 国家を後ろ盾とする脅威アクターが防衛産業基盤 (DIB) を標的にし続ける中、CMMC フレームワークは非連邦システムにおける CUI を保護するために不可欠なものとなっています。DoD は現在、防衛関連業務に携わろうとするコントラクターにとって CMMC を必須かつ強制力のあるものと考えています。 しかし、多くの組織はまだ基本的な質問を投げかけています。 どのシステムが CUI を含むまたは処理しているのか？ 認証境界に何が含まれるのか？ コンプライアンスを確保しながら、過剰な監査をどのように避けられるのか？ これらの不明点が共通の課題につながります。 環境の盲点 が評価のスコーピングを複雑にします。 過剰な監査 はコスト増加と無駄な労力を招きます。 チームが適切な成果物を提示できないと 監査の遅延 が発生します。 CUI データフローのマッピング は根拠のない推測作業になります。 従来の技術や手動の方法論に頼ると、CMMC コンプライアンスに必要な裏付け証拠を収集することは非常に困難になる可能性があります。例えば、現役軍人に高度な医療ケアを提供するために CUI 指定の患者データを扱う大規模な医療グループは、CUI がどこに存在し、どのシステムが相互接続されているかを分類するのに 2 年を費やしたと報告しています。この取り組みは、可視性の欠如、 シャドー IT 、クラウド環境におけるワークロードの分散所有権のために困難でした。Wiz は、これらのプロセスの多くを自動化し、手動の労働時間を必要とせずにシャドー IT を発見するのに役立ちます。自動化と可視性により、評価中に必要なデータの手動収集と関連付けを大幅に削減することで、CMMC 認証準備に必要な管理作業を大幅に削減できます。 Wiz と AWS の力 Wiz は、組織に AWS クラウド環境への完全な可視性を提供するクラウドセキュリティプラットフォームです。Wiz を AWS に接続すると、Wiz はパブリックセクターチームがリソース（CUI データが存在する場所を含む）の検出を自動化し、コンテキストに基づいてリスクを評価し、自己評価とサードパーティ監査の負担を軽減するために、防御可能な方法でセキュリティ体制を証明するのに役立ちます。 エージェントなしで数分で AWS 環境に接続することで、Wiz は次のことを特定できます。 どのリソースが CUI を含むまたは CUI に接続しているか どのアイデンティティが何にどこからアクセスできるか どの脆弱性または設定ミスがセキュリティに影響を与えるか AWS 内にデプロイされているリソース、それらのリソースの接続方法、どのアイデンティティがアクセス権を持っているかに関するコンテキストを含む完全な可視性を持つことは、CMMC レベル 2 と 3 の重要な要素であり、Wiz ではすぐに利用できます。AWS GovCloud (US) のセキュリティ機能と組み合わせることで、組織はミッションを遅らせることなく、コンプライアンスのための安全でスケーラブルな基盤を構築できます。 AWS GovCloud (US) は、テクノロジーリーダーが機密データや CUI データをホストするために信頼する革新的なコンプライアント対応クラウドソリューションです。これは、物理的および論理的に分離された 2 つの米国主権 リージョン 、AWS GovCloud (米国東部) と AWS GovCloud (米国西部) で構成されており、米国内で米国市民によって運用されています。政府機関のお客様、テクノロジーパートナー、および高度に規制されたエンタープライズクラウド要件を持つ組織は、 AWS GovCloud (US) のコンプライアンスプログラム と機能を使用して、ワークロードを保護し、運用許可 (ATO) を取得する能力を加速しています。 AWS GovCloud (US) は、連邦、州、地方レベルの米国政府機関、クラウドで機密ワークロードを実行するコントラクター、教育機関、その他の米国のお客様の特定の規制およびコンプライアンス要件に対応するように設計されています。すべての AWS リージョンに適用される保証プログラムに加えて、AWS GovCloud (US) リージョンは、お客様が米国武器国際取引規則 (ITAR)、 Federal Risk and Authorization Management Program (FedRAMP) 、および DoD Cloud Computing Security Requirements Guide (SRG) Impact Levels 2、4、5 に準拠できるように設計されています。AWS GovCloud (US) がサポートする米国のコンプライアンス基準の完全なリストについては、 AWS Compliance をご覧ください。 自信を持って CMMC 評価に臨む AWS と Wiz が組織と緊密に連携して CMMC 監査プロセスを合理化し、本番環境への移行時間を短縮し、イノベーションを促進する方法を以下に示します。 CUI データフローを理解する Wiz は、 Data Security Posture Management (DSPM) 内のカスタムデータ分類ルールを通じて、CUI がどこに存在するかを理解するという一般的な課題にチームが対処できるよう支援します。これらのルールは、防衛契約、作業記述書 (SOW)、業績作業記述書 (Performance Work Statements) 内で定義された CUI を検索するために使用できます。クラウド環境内で CUI が存在する場所を特定することで、組織はこれらのデータに対する適切な保護が実施されていることをより簡単に確認できます。 組織は、防衛契約で定義されているように、CUI が Basic か Specified かを追跡する必要があります。この区別は重要です。なぜなら、CUI Specified には、ITAR によって義務付けられているようなより厳格な法的要件が伴うことが多く、AWS GovCloud (US) や Wiz for Gov などの特殊な環境で見られる強化された保護が必要になるためです。 次のスクリーンショットは、Data Findings ダッシュボードを示しています。 図 2: Wiz は、統合された DSPM 機能を通じてデータ検出を自動化し、データが存在する場所を特定し、検出されたセキュリティリスクの修復に優先順位を付けるのに役立ちます CUI の検出と、どのシステムとリソースが相互接続されているかを自動化することで、組織は CUI Specified データに対する高度なセキュリティ要求とコンプライアンスを満たしているかどうかをより簡単に評価できます。 CMMC のスコープを最適化する AWS クラウド環境全体を認証しようとすることは、単に高額であるだけでなく、多くの場合不要です。適切な可視性があれば、組織は CMMC に必要なものだけを含む明確で防御可能な境界を定義できます。 境界を適切なサイズに設定するには、エンジニアリング、コンプライアンス、法務チーム間のパートナーシップが必要です。これは圧倒的に思えるかもしれませんが、CUI が存在する場所、どのリソースとアイデンティティが接続できるか、これらのシステムが外部にどのように公開されているかの検出を自動化することで、境界を設定できます。 Wiz は、このプロセスを加速するための可視性を提供します。組織の AWS インフラストラクチャ全体にわたるコンテキストに富んだインサイトにより、次のことが可能になります。 CMMC 環境のスコープを適切に定義する どのアイデンティティとリソースが CUI にアクセスできるかを明確に示す 無関係なリソースの監査にかかる時間とコストを回避する このバランス（セキュリティと俊敏性）は、厳しい予算とスケジュールで作業する政府のコントラクターとサブコントラクターにとって不可欠です。次のベン図は、最小限の境界を持つ厳密なスコープと、すべてを囲む境界を持つフルスコープの交差を示しています。厳密なスコープとフルスコープの重なりを示す中央の領域には、CUI と関連システムの周囲に CMMC 評価境界を配置することの利点がいくつか記載されています。 図 3: CMMC 評価のスコープに何を含めるべきかを決定することは、監査のコストと期間、およびスコープとサービスを拡大する柔軟性に影響を与える可能性があります 包括的な監査証拠を収集する 監査人は証拠が示されることを期待します。しかし、脆弱性、設定、アクセスコントロールなどにわたって適切な成果物をまとめることは困難な場合があります。 Wiz は、AWS 環境を継続的に監視し、関連性のある検出結果を表面化させることで、このプロセスを自動化します。Wiz は、 Amazon Bedrock 、 AWS Certificate Manager (ACM) 、 AWS CloudTrail 、 AWS Key Management Service (AWS KMS) 、 AWS Lambda 、 AWS Network Firewall 、 Amazon OpenSearch Service 、 AWS Secrets Manager など、 多数の AWS のサービス を検査します。Wiz は、手動入力を必要とせず、監査要件をサポートするドキュメントを迅速に提供するために、カスタマイズ可能なレポートを生成できます。 次の画像は、検出結果、コンプライアンス、インベントリレポートを示す Wiz Cloud-Native Application Protection Platform (CNAPP) レポートユーザーインターフェイスのスクリーンショットです。各レポートカテゴリの下には、ネットワーク露出、脆弱性、データ検出結果、コンプライアンス評価、コンプライアンスのための脆弱性、データストア、クラウドリソースインベントリなど、レポートサブカテゴリのオプションがあります。 図 4: Wiz は、CMMC 監査をサポートするために必要な情報を迅速にエクスポートするための、カスタマイズ可能なオプションを備えたいくつかのすぐに使えるレポートを提供します 継続的な監視プロセス、脆弱性とリスク指標の迅速な特定、ベストプラクティスと技術的ベンチマークへの準拠、ベースラインからの逸脱が検出されたときのアラートの自動化の組み合わせはすべて、組織が NIST SP 800-171r2 へのコンプライアンスを迅速に示すのに役立ちます。DoD CMMC 最終規則 32 CFR Part 170 は、CUI データが CMMC レベル 2 (Self および C3PAO) 認証のために十分に保護されているかどうかを評価するための技術標準として NIST SP 800-171r2 を指定しています。 例として、Wiz には、多数の技術的ベンチマークに対するすぐに使える自動評価が付属しています。これには、Center for Internet Security (CIS) フレームワークと Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) が含まれます。これらの自動評価は、サイバーセキュリティの脅威からシステムを保護するための強化要件を満たしているかどうかを特定するように設計されています。これにより、組織は NIST SP 800-171r2 の Configuration Management コントロールファミリー内の多くのコントロールを迅速に満たすことができます。 CMMC クラウドサービスプロバイダー (CSP) 要件を満たし、それを超えるために、AWS と Wiz はどちらも FedRAMP High 認可環境を提供しています。 Wiz for Government と AWS GovCloud (US) は、ITAR、FISMA、HIPAA、FedRAMP を含む多くの規制フレームワークを満たすか、それを超えるように構築されています。これらの FedRAMP High 認可は、これらの環境のセキュリティを証明するための追加ドキュメントを削減または免除することで、CMMC を含む監査を簡素化するのに役立ちます。 Wiz for Government が支援できる CMMC および NIST SP 800-171r2 コントロールの詳細については、Wiz for CMMC Certification データシートを参照してください。 CMMC の達成: 標準をセキュリティに変える CMMC への準備は、DoD と契約またはサブコントラクトを結ぶ多くの組織にとって、もはや任意ではありません。しかし、長く困難なプロセスである必要もありません。 AWS の堅牢な保護と Wiz の CNAPP の可視性を組み合わせることで、パブリックセクターチームはスコーピングを簡素化し、検出を加速し、自信を持って監査準備態勢に移行できます。 組織が AWS GovCloud (US) で構築している場合でも、既存の環境を拡張している場合でも、Wiz は CUI が存在する場所を特定し、セキュリティコントロールを検証し、データでコンプライアンス境界をサポートすることで、手動で生成および保守されるスプレッドシートの必要性を排除することがよくあります。 Wiz の FedRAMP High 認可が AWS のお客様のセキュリティをどのように強化するかについてお読みください 。 CMMC への取り組みを加速する準備はできていますか? 今すぐ AWS Global Security & Compliance Acceleration (GSCA) と Wiz の使用を開始する方法の詳細 をご覧ください。 著者について Varun Jasti Varun Jasti は AWS のソリューションアーキテクトであり、AWS パートナーと協力して、コンプライアンス基準を満たすパブリックセクターのユースケース向けの人工知能ソリューションを設計およびスケールしています。コンピュータサイエンスのバックグラウンドを持つ彼の業務は、主に LLM のトレーニング/推論とコンピュータビジョンに焦点を当てた幅広い ML ユースケースをカバーしています。余暇には、テニスや水泳を楽しんでいます。 Bryan Rosensteel Bryan Rosensteel は Wiz のパブリックセクタープロダクトマーケティング責任者です。彼は 20 年以上のパブリックセクターでの経験を持っています。彼は、ICAM を含む多くのサイバーセキュリティイニシアティブについて米国連邦政府に助言し、NIST 1800 シリーズの特別刊行物につながる複数の NCCoE プロジェクトに取り組み、ATARC などの非営利組織でワーキンググループの形成と運営を支援し、複数の政府 IT モダナイゼーションプロジェクトの設計と実装を支援してきました。 Greg Carpenter Greg Carpenter は AWS Global Security & Compliance Acceleration Partner Team のシニアセキュリティパートナーストラテジストであり、パートナーとお客様がセキュリティと認可のニーズを満たせるよう支援しています。これには、ツールとコントロールのアーキテクト、設定、デプロイ、統合が含まれます。キャリアを通じて、Greg はパートナーおよびお客様とのコミュニケーション、セキュリティとコンプライアンスのサポートで優れた実績を上げてきました。AWS に入社する前、Greg は CIS で 4 年間勤務し、メンバーと非メンバーが独自のサイバーセキュリティ戦略を進める際に、グローバルコミュニティ向けのクラウドサイバーセキュリティ製品と戦略に焦点を当てて支援しました。Greg は、CIS Benchmarks、CIS Controls v8 Cloud Companion Guide、および最新版の CIS Critical Security Controls にも貢献しています。クラウドに頭を悩ませていないときは、家族との時間、ハーレーに乗る時間、アイスホッケー、釣り、マウンテンバイクを楽しんでいます。 Greg Hewitt Greg Hewitt は Wiz のグローバルパブリックセクタービジネスにおける AWS GTM 戦略を主導しており、政府機関や規制産業がクラウド導入を安全に加速できるよう支援することに注力しています。Splunk と Second Front Systems でのリーダーシップの役割を経て、Greg はクラウドセキュリティと防衛モダナイゼーションにおけるイノベーションの推進の中心にいました。彼は AWS と緊密に連携して、FedRAMP、CMMC、ITAR コンプライアンスを可能にする共同ソリューションを提供しており、政府組織にとってクラウドをより安全でアクセスしやすいものにすることで、ミッションレジリエンスを向上させることに情熱を注いでいます。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。

本稿は、日本取引所グループの SCRIPTS Asia 社による「生成 AI を活用 した決算説明会等スクリプトの自動翻訳」について、サービス開発をリードされた 松田 敬治 様、雪永 スチュアート 様、アーキテクティングと開発をリードされた 太子 智貴 様に寄稿いただきました。 イントロダクション SCRIPTS Asia は、上場企業の決算説明会や IR イベントの内容をテキスト化し、機関投資家や情報ベンダーに配信しています。従来は、日本語の書き起こしテキストから英語翻訳、成果物の品質確認までをすべて人手で対応していました。しかし、SCRIPTS Asia がカバーする上場企業の全イベントを英訳するには時間及び費用の両面で大きな課題がありました。 今回、AWS の Amazon Bedrock を活用した生成 AI 翻訳を導入し、業務全体の自動化と品質向上を実現しました。 SCRIPTS Asia 社の概要 SCRIPTS Asia は JPX 総研の子会社です。上場企業の決算説明会や IR イベントの音声をテキスト化し、話者情報などのイベント詳細をデータベース化して、機関投資家や金融機関、情報ベンダーに提供しています。併せて、イベントデータの英語翻訳も行っており、グローバル投資家の投資判断や分析に活用されています。このサービスは、単なる技術導入や機械翻訳ではなく、長年の業界知識と翻訳ノウハウを融合した独自の体制によって支えられています。さらに、人力オペレーションによるラストワンマイルの品質保証を組み込むことで、高品質な翻訳やデータ品質の両立を実現しています。 課題 イベントデータの英訳にあたり、SCRIPTS Asia が直面していた主な課題は次のとおりです。 翻訳の作業量は膨大で、コスト負担が大きい 繁忙期には翻訳作業を行う大量の人員が必要（季節要因が激しく、人員確保が困難） 会社固有の専門用語 や業界用語に対応した高い精度での翻訳が求められる ソリューション Amazon Bedrock の導入 Amazon Bedrock を活用し、日本語スクリプトの英語翻訳から成果物出力までを自動化しました。導入にあたっては、BERT や BLEU スコアなどの評価指標を用いて、従来の人手での翻訳結果を用いた精度比較を行い、最適なモデルを選定しました。 ナレッジの融合 過去の翻訳履歴や辞書、証券用語集といった形式知に加え、翻訳作業のレビューアーによるフィードバック資料等からプロダクション担当者が持つ暗黙知についても生成 AI で整理しました 。 この整理した知見をプロンプトや辞書情報等に取り込むことで、従来の SCRIPTS Asia のスタイルを維持しつつ、高品質な翻訳が実現できました。 技術的詳細 AWS サービスの活用 Amazon Bedrock ： Anthropic Claude Sonnet AWS Fargate ： Amazon Bedrock と連携した英訳処理、整形処理 Amazon EventBridge ＋ AWS Lambda ＋ Amazon SQS でクォータを超えないように 制御 Amazon DynamoDB ：過去の翻訳情報 や単語情報の保持 プロンプトエンジニアリングとチャンク分割 長文翻訳では、プロンプトの 指示が反映されにくく、数字表現の精度が低下する傾向がありました。精度向上のため、複数の生成 AI モデルを比較し、文章を細かく 1 行ずつに分割（チャンキング）して英訳することで、プロンプトの意図を正確に理解させるように工夫しました。なお、全体的な文章としての適切性を保持するために、前後の文章についても参考して読み込ませることで文意が保たれるようにしております。 コストと精度のバランス プロンプトの解釈精度向上のためにチャンク分割を実施したことにより、生成 AI への入出力回数が増大し、翻訳辞書等のナレッジを参照した翻訳に係る処理時間と費用面の課題が浮上しました。こちらは単語分割を踏まえつつ辞書情報の組み込み方式を見直すことで、プロンプトのボリュームを圧縮し、処理時間と費用を許容範囲に抑え込みました。 生成 AI を意識した効率的な運用設計 生成AIによる翻訳が難しく、誤訳リスクが高いケース（音声が不明瞭な個所があり、文として成立しない場合など）については、あえて自動翻訳を行わずにエラーとして処理を止め、人手で翻訳するフローに回しています。 こうすることで、「見た目上は訳されているものの、明らかな誤訳」をそのまま出してしまう“クリティカルエラー“を最小化し、英語読者が誤った理解をするリスクを回避しています。 このような翻訳困難ケースは全体の 1 〜 3 ％程度に収まるため、あらかじめ“止めるべき条件“として定義して、それ以外の翻訳は自動処理で回せる設計としており、Human-in-the-loop（人手チェック）を最小限に抑えつつ、必要な部分には確実に人の目を入れることで、効率と品質の両立を実現しています。 効果・成果 翻訳品質の大幅向上 SCRIPTS Asia 社の翻訳有識者による相対的な評価で、各種チューニング後の最終的な品質は 90 点以上を達成し、単純な AI の一括翻訳（ 45 ～ 50 点評価）から大幅に改善しました。この品質は、生成AIの性能だけでなく、専門知識と人力による品質保証の知見の組み合わせによって支えられています。 作業効率の改善とコスト削減 生成 AI を利用した翻訳により、人手での成果物作成と比較して、時間効率は概ね 10 倍以上、費用効率は概算で数十倍となる、プロダクションアウトプットを実現しました。 この成果により、注目度が低いイベントなど従来はコスト面の問題で英文翻訳が実施出来なかったイベントについても英文スクリプトが作成され、日本語と英語に差が無い環境を整えることができました。結果として、SCRIPTS Asia の品質を確保した英文対応のイベント数が大幅に増加することで、グローバルな投資家ニーズに更に応えられるようになりました。 今後の展望 さらなる生成AI活用の拡大 今回の成功経験を活かし、人手で実施している音声の書き起こし業務についても、生成AIの適用を検討していきます。話者情報の識別など現在の高品質と評価いただいている成果物（テキスト及びデータ構造特性）を踏まえた書き起こしという課題はありますが、この取組みにより、これまで人手不足を要因としてリーチできなかったイベントについても対応可能な範囲が増え、データ拡充を通じて世界中の市場関係者に対する新たな価値創出を目指していきます。 執筆者紹介 （松田 敬治（右）、雪永 スチュアート（左）、太子 智貴（中央）） 松田 敬治 (SCRIPTS Asia 株式会社 テクノロジー部長／(株)JPX 総研 IT ビジネス部 パブリッククラウド基盤 統括課長) 東京証券取引所に入所後、市場運営部門を経て、清算機関 (JSCC) 設立時からシステム部門に従事。清算システム構築後、SIer 出向・arrownet 担当を経て、2010 年から株式売買システム arrowhead や CONNEQTOR 等の取引インフラ基盤を開発。2024 年度より SCRIPTS Asia 社システム統括兼 JPX 総研を担当 雪永 スチュアート (株式会社 JPX 総研 フロンティア戦略部 Manager) 金融、外交、映像制作など多様な分野で経験を積む。取引所入所後は広報業務や 清算機関 (JSCC) の OTC デリバティブの海外コンプライアンスを担い、2025 年より SCRIPTS Asia 社の IT サポートおよび JPX 総研のデータサービス営業を担当 太子 智貴 (株式会社 JPX 総研 IT ビジネス部 JPX 生成 AI プロジェクト 統括課長) 取引所入所後、10年以上にわたり上場審査・市場監視などの中核業務を担い、2019 年に IT 部門へ異動。2023 年から JPX グループにおける社内・社外向けの生成 AI プロジェクトをリードし、数十件に及ぶ生成 AI 関連サービスのリリースを主導

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 今年も熱気に包まれた re:Invent 2025 は  Dr. ワーナーの最後のキーノート と合わせて幕を閉じました。現地に行かれた方も、日本からオンラインで参加された方も、得た学びを整理している状況かなと思います。サービスアップデートの発表だけでなく、会場で行われた多くの講演がすでに 動画としてアップロード されています。ぜひ気になる講演を視聴し、新たなる気づきや技術整理にお役立てください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年12月8日週の主要なアップデート 12/8(月) 空間データの洞察を加速させる Spatial Data Management on AWS (SDMA) の発表 AWS が空間データ管理ソリューション Spatial Data Management on AWS (SDMA) を発表しました。SDMA は空間データを大規模に保存、エンリッチ、接続することを可能にするソリューションで、CloudFormation を利用してお客様の AWS アカウントにデプロイして利用します。SDMA により、3D や地理空間データなどのマルチモーダル空間データを一元化されたセキュアなクラウド環境に保存できます。さらに、自社の空間データ、ISV SaaS アプリケーション、AWS サービス間の接続を可能にするコラボレーションハブとしても機能します。また、自動生成されるファイルプレビュー機能により、大容量ファイルをダウンロードせずにデータを表示および検証が可能です。東京リージョンを含む 9 リージョンで利用可能です。詳細は こちらをご参照ください。 Amazon Quick Suite で Quick Research と Quick Flows を統合したレポート生成の自動化 Amazon Quick Suite で Quick Research と Quick Flows が統合され、自動化ワークフローの中でリサーチレポートを生成できるようになりました。これまで手動で行っていたり Quick Research の作業を、スケジュール実行や他システム連携で自動化可能です。例えば営業チームの顧客分析レポートを定期生成し、結果を Salesforce に自動反映するといった活用が実現します。バージニア北部、オレゴン、シドニー、アイルランドリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 12/9(火) Amazon GameLift Servers が AI を活用したサポートでゲーム開発者向け AWS コンソールを強化 Amazon GameLift Servers に Amazon Q Developer を活用した AI アシスタンス機能が追加されました。ゲーム開発者は AWS コンソール内で、サーバー統合やフリート設定、パフォーマンス最適化に関する AI による専門的なガイダンスを受けられます。従来は複雑な設定やトラブルシューティングに時間がかかっていましたが、この機能によりコスト削減とプレイヤー体験向上を同時に実現できます。詳細は こちらのドキュメントをご参照ください。 Amazon RDS と Aurora が自動バックアップのリソースタグ付けに対応 Amazon RDS と Aurora で、自動バックアップに対するリソースタギング機能が追加されました。これまで自動バックアップ機能を利用する際、親の DB インスタンスやクラスターと同一のタグが、バックアップに自動付与されていましたが、今回から独立してタグを設定できるようになりました。これにより、アプリケーション別やプロジェクト別にバックアップのアクセス制御やコスト追跡が可能となり、より細かなリソース管理が実現できます。 AWS Partner Central に案件規模の算定機能が追加 AWS Partner Central に AI を活用した deal sizing 機能が追加されました。この機能により、AWS パートナーは案件の規模見積もりや AWS サービス推奨を自動化できます。AWS Pricing Calculator の URL をインポートすることで、手動での再入力作業が不要になり、価格戦略の最適化や Migration Acceleration Program (MAP) の適格性分析なども提供されます。案件管理業務を大幅に効率化でき、プログラム申請のプロセスの迅速化にもつながります。詳細は こちらのドキュメントをご参照ください。 12/10(水) AWS Support Center Console でサポートケースのトラブルシューティング用画面共有をサポート AWS Support Center Console にスクリーン共有機能が追加されました。これまでサポートとのやり取りは電話やチャットのみでしたが、今回のアップデートでバーチャルミーティング中にスクリーンを共有できるようになりました。アクティブなチャットや通話中にワンクリックでミーティングに参加でき、画面を見せながら問題を説明できるため、より迅速で効果的なトラブルシューティングが可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 C8gb インスタンスの一般提供開始 Amazon EC2 C8gb インスタンスの一般提供が開始されました。AWS Graviton4 プロセッサ搭載により、従来の Graviton3 比較で最大 30% のパフォーマンス向上を実現します。最大 150 Gbps の EBS 帯域幅を提供し、高性能ファイルシステムなどの大容量データ処理ワークロードでより高いスループットを実現できます。最大 24xlarge サイズまで対応し、192 GiB メモリと 200 Gbps ネットワーク帯域幅を提供します。現在バージニア北部リージョンとオレゴンリージョンで利用可能です。 Amazon ECS が AWS Fargate でカスタムコンテナ停止シグナルをサポート Amazon ECS が AWS Fargate でカスタムコンテナ停止シグナルに対応しました。従来は強制的に SIGTERM シグナルが送信されていましたが、今回から Docker イメージの STOPSIGNAL 設定を尊重するようになります。これにより SIGQUIT や SIGINT を使うアプリケーションも適切にグレースフルシャットダウンできます。データベース接続の正常切断やファイル保存処理など、終了時の処理が重要なアプリケーションで特に効果的です。全リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 12/11(木) Amazon Aurora PostgreSQL が Kiro powers との統合をサポート Amazon Aurora PostgreSQL が Kiro powers との統合を開始しました。この統合により、AI エージェントの支援を受けながら Aurora PostgreSQL を使ったアプリケーション開発が可能になります。Kiro powers は事前にパッケージ化された MCP サーバーを提供し、データベースの作成、スキーマ設計、クエリ最適化などの作業で適切なガイダンスを自動的に提供します。従来は手動で行っていたデータベース操作や設計判断を AI がサポートすることで、開発効率が大幅に向上します。詳細は こちらの Blog 記事をご参照ください。 Amazon Cognito アイデンティティプールが AWS PrivateLink によるプライベート接続をサポート Amazon Cognito identity pools が AWS PrivateLink に対応しました。これまで認証トラフィックはパブリックインターネット経由でしか流せませんでしたが、VPC とのプライベート接続が可能になり、セキュリティが大幅に向上します。企業の機密データを扱うアプリケーションで、認証処理を完全にプライベートネットワーク内で完結できるため、コンプライアンス要件の厳しい業界でも安心して利用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora DSQL が数秒でのクラスター作成可能に Amazon Aurora DSQL でクラスター作成が数秒でできるようになりました。従来は数分かかっていた作業が劇的に高速化され、即座に利用できます。AWS コンソールの統合クエリエディターを使えば、外部クライアントの設定なしですぐに開発を開始でき、AI 支援ツールとの連携も可能です。詳細は こちらのドキュメントをご参照ください。 12/12(金) AWS Shield ネットワークセキュリティディレクターがマルチアカウント分析をサポート AWS Shield のネットワークセキュリティディレクターがマルチアカウント分析に対応しました。従来は単一アカウント内でのセキュリティ設定チェックのみでしたが、今回のアップデートにより複数の AWS アカウントを横断してネットワークセキュリティの状況を一元管理できるようになりました。委任管理者を設定することで組織全体のセキュリティ設定不備を検出し、修正手順も提示されます。大規模な組織でアカウント管理が複雑になりがちな環境で特に有効です。2025年12月時点ではまだ Preview 提供ですが、今回のアップデートと合わせて、追加で５つのリージョンにおいても利用可能となっています。利用詳細は こちらの概要ページをご参照ください。 AWS DataSync がオンプレミスファイル転送のスケーラビリティとパフォーマンスを向上 AWS DataSync Enhanced モードがオンプレミスファイルサーバーと Amazon S3 間のデータ転送に対応しました。従来は S3 間とマルチクラウド転送のみでしたが、今回 NFS や SMB ファイルサーバーからの転送も可能になりました。並列処理により高速転送を実現し、ファイル数制限も撤廃されています。生成 AI の学習データセット移行やデータレイク構築、大規模アーカイブ移行などに活用できます。詳細は こちらのドキュメントをご参照ください。 今年の週刊AWS は次回が最後です！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

この記事は Migrating from AWS CodeDeploy to Amazon ECS for blue/green deployments (記事公開日: 2025 年 9 月 16 日) を翻訳したものです。 ブルー/グリーンデプロイは、同一環境で実行している 2 つの異なるバージョンのアプリケーション間でトラフィックを切り替えることで、新しいソフトウェアをリリースできます。これにより、新しいバージョンのアプリケーションの安全なテストを促進し、ほぼゼロダウンタイムでのロールバック機能を提供することで、新しいソフトウェアリリースのデプロイに伴う一般的なリスクを軽減します。 最近まで、 Amazon Elastic Container Service (Amazon ECS) は、ネイティブなデプロイ戦略としてローリングアップデートのみをサポートしていました。ブルー/グリーンデプロイを実装したい場合は AWS CodeDeploy を使用する必要がありましたが、最近リリースされた ECS ブルー/グリーンデプロイ によりサポートされました。 ECS ブルー/グリーンデプロイは CodeDeploy と同様の機能を提供しますが、利用可能な機能とその実装にはいくつかの違いがあります。この記事は、現在 Amazon ECS でのブルー/グリーンデプロイに CodeDeploy を使用しており、新しい Amazon ECS ネイティブなデプロイ戦略への移行を検討しているお客様を対象としています。 (1) 移行を計画する際に考慮すべき要因 (2) CodeDeploy の概念を ECS ブルー/グリーンデプロイの同等機能にマッピングすること (3) 移行戦略についてのガイダンスを提供します。 移行の計画 CodeDeploy から ECS ブルー/グリーンデプロイに移行する際は、計画プロセスの一部として以下の点を考慮する必要があります。 新たな可能性 ： ECS ブルー/グリーンデプロイは、 CodeDeploy ではサポートされていない多数のユースケースを可能にします。これには以下が含まれます。 サービスディスカバリーオプション：CodeDeploy は Elastic Load Balancing (ELB) の背後に配置された ECS サービスのみをサポートしますが、ECS ブルー/グリーンデプロイは ELB と ECS Service Connect の両方をサポートします。 ヘッドレスサービスサポート：ECS ブルー/グリーンデプロイは、キュー処理サービスなど、サービス公開が不要な状況で使用できます。 Amazon EBS サポート：ECS ブルー/グリーンデプロイは、ECS サービスのデプロイ時に Amazon Elastic Block Store (Amazon EBS) ボリュームの設定をサポートします。 複数のターゲットグループ：ECS デプロイコントローラーにより、サービスを複数のターゲットグループに関連付けることができます。これは、複数のロードバランサーを通じて同時にアクセス可能であることを意味します (例：内部および外部サービス公開の分離) 。 柔軟な ALB リスナー設定：CodeDeploy は異なるサービス、本番およびテストエンドポイントに対して別々のリスナーが必要です。ECS ブルー/グリーンはリスナールールレベルで動作するため、ホスト名、HTTP ヘッダー、パス、メソッド、クエリ文字列、またはソース IP に基づく 高度なリクエストルーティング を使用して単一のリスナーを活用できます。例えば、パスベースルーティングを使用して複数のサービスに共通のリスナーポートを使用し、クエリ文字列ベースルーティングを使用して A/B テストをサポートできます。同じリスナーポートでブルー/グリーンの本番およびテストトラフィックもサポートできます。 運用上の改善： ECS ブルー/グリーンデプロイは、 (1) 既存の Amazon ECS 機能 (サーキットブレーカー、デプロイ履歴、ライフサイクルフックなど) との整合性の向上により、異なるAmazon ECS デプロイ戦略間の移行を支援し、 (2) ライフサイクルフックの実行時間の延長 (CodeDeploy のフックは 1 時間に制限) 、 (3) AWS CloudFormation サポートの改善 (サービスリビジョンとライフサイクルフック用の個別の AppSpec ファイルが不要) を提供します。 API/CLI の違い： API (および関連する CLI コマンド) に違いがあります。ある API から別の API へのマッピングは通常簡単ですが、ECS ブルー/グリーンデプロイはデプロイステップを制御するためにライフサイクルフックをより広範囲に使用することに注意してください。例えば、CodeDeploy が新しいデプロイをテストするための待機時間オプション (本番トラフィックを再ルーティングする前) をサポートしているのに対し、ECS ブルー/グリーンデプロイではこれを実現するためにフックを使用する必要があります。 コンソールの違い： 運用の一部として CodeDeploy コンソールを使用している場合、Amazon ECS コンソールがデプロイの進行の手動オーバーライドオプション (例：強制再ルーティングまたはベイク時間の早期終了) を提供していないことに注意してください。代わりに、Amazon ECS ライフサイクルフック (より安全なアプローチと言える) を通じて、より広範な運用プロセスと統合されたカスタム UI を作成できます。 移行パス： CodeDeploy から ECS ブルー/グリーンデプロイにサービスを移行するために利用可能な多数のオプションがあり、環境に最適なものを検討する必要があります。これらのオプションと関連する長所と短所については、この記事の後半でより詳細に説明します。 パイプラインサポート： 既存のパイプラインツールでは、ECS ブルー/グリーンデプロイのサポートが最初は制限される可能性があります。より高度なパイプライン統合では、暫定期間中にカスタムアクションの使用が必要になる場合があります。この記事の執筆時点では、CodePipeline Amazon ECS「標準」アクションを使用して、ECS ブルー/グリーンデプロイを通じてコンテナイメージの変更をデプロイできます (ただし、他のサービス設定変更はできません) 。 CodeDeploy から ECS ブルー/グリーンデプロイへ ECS ブルー/グリーンデプロイへの移行の実装コストを見積もる際は、APIの 違いと、CodeDeploy の機能を ECS ブルー/グリーンデプロイの同等機能にどのようにマッピングできるかを理解する必要があります。CodeDeploy の「一括」設定から開始することを前提として、このセクションでは主要な違いについて説明します。 ロードバランサー設定と ECS サービスの作成 CodeDeploy を使用して Amazon ECS サービスを作成する場合、まず本番リスナーと (オプションで) テストリスナーを持つロードバランサーを作成します。各リスナーは、図 1 (a)に示すように、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする単一の (デフォルト) ルールで設定されます。次に、リスナーとターゲットグループを使用するように設定された Amazon ECS サービスを作成し、 デプロイコントローラー のタイプを CODE_DEPLOY に設定します。サービスの作成により、指定されたターゲットグループに登録された (ブルー) タスクセットが作成されます。 図 1：ロードバランサーの初期設定 ECS サービスが作成されると、CodeDeploy デプロイグループを (CodeDeploy アプリケーションの一部として) 作成し、ECS クラスター、ECS サービス名、ロードバランサーのリスナー、2 つのターゲットグループ (本番リスナールールで使用されるプライマリターゲットグループと、置換タスクに使用されるセカンダリターゲットグループ) 、 AWS Identity and Access Management (IAM) の CodeDeploy に Amazon ECS および ELB リソースを操作する権限を付与するサービスロール 、およびデプロイ動作を制御する様々なパラメータの詳細を設定します。 ECS ブルー/グリーンデプロイは、Amazon ECS サービス自体にデプロイ設定を指定します。ロードバランサーの本番リスナーは、重み 1 と 0 に設定された 2 つのターゲットグループを含むルールで事前設定されている必要があります。ECS サービス作成の一部として、このリスナールールの Amazon Resource Name (ARN) 、2 つのターゲットグループ、 IAM ロール (Amazon ECS にリスナーとターゲットグループを操作する権限を付与するため) 、 デプロイコントローラー のタイプを ECS に設定、および deploymentConfiguration.strategy を BLUE_GREEN に設定します。これにより、プライマリターゲットグループに登録されたタスクを持つ (ブルー) サービスリビジョン が作成されます。 両方のアプローチともタスクの初期セットの作成という結果になりますが、基盤となる実装は、CodeDeploy が タスクセット を使用するのに対し、Amazon ECS は サービスリビジョン を使用するという点で異なります。後者は Amazon ECS サービスデプロイ API の一部として導入され、デプロイプロセスとサービスデプロイ履歴への可視性を向上させます。 サービスリビジョンのデプロイ 図 2 は、新しいサービスリビジョンがどのようにデプロイされるかを示しています。CodeDeploy は CreateDeployment() を使用してサービスの新しいバージョンをデプロイし、CodeDeploy アプリケーション名、デプロイグループ名、および  AppSpec ファイル内のリビジョン詳細を指定します。これには、新しいリビジョンのタスク定義と、使用するコンテナ名およびポートが含まれている必要があります。ECS ブルー/グリーンデプロイは、 UpdateService() を呼び出して置換タスク定義の詳細を渡すことで、新しいサービスデプロイを作成します。 図 2：サービスリビジョンのデプロイ オプションで、CodeDeploy の AppSpecファイルは、ネットワーク設定やキャパシティプロバイダー戦略などのより多くのサービス設定変更を指定し、ライフサイクルフックを指定するためにも使用できます (次のセクションを参照) 。Amazon ECS を使用する場合は、 UpdateService() を使用してこれらの変更を指定します。 図 3：トラフィックの再ルーティング 図 3 は、トラフィック再ルーティングが実現される方法の違いを示しています。CodeDeploy では、デプロイが置換 (グリーン) タスクセットを作成し、そのタスクをセカンダリターゲットグループに登録します。これが正常になると、テスト (オプション) および本番で利用可能になります。どちらの場合も、再ルーティングは、グリーンタスクセットに関連付けられたセカンダリターゲットグループを指すように各リスナールールを変更することで実現されます。ロールバックは、本番リスナールールをプライマリターゲットグループに戻すことで実現されます。 対照的に、ECS ブルー/グリーンデプロイでは、サービスデプロイが (グリーン) タスクを持つ新しい サービスリビジョン を作成し、それらをセカンダリターゲットグループに登録します。その後、再ルーティングとロールバックは、リスナールールの重みを切り替えることで実現されます。 ライフサイクルフック CodeDeploy と ECS ブルー/グリーンデプロイの両方とも (オプションの) ライフサイクルフックをサポートしており、特定のライフサイクルイベントによって AWS Lambda 関数をトリガーできます。フックは、カスタムロジックでデプロイワークフローを拡張するのに役立ちます。例えば、ライフサイクルフックを使用して、本番ポートにライブトラフィックを再ルーティングする前に、テストポートでのテストを自動化できます。 CodeDeploy と ECS ブルー/グリーンデプロイは大まかに類似したライフサイクルに従いますが、設定オプションとライフサイクルフックの指定方法に違いがあります。 CodeDeploy は、 CreateDeployment() に提供される AppSpec ファイルの一部としてライフサイクルフックを指定します。これは、すべてのデプロイでフックを設定する必要があることを意味します。ECS ブルー/グリーンデプロイは、サービス設定の一部としてフック ( Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可 ) を指定し、変更には UpdateService() 呼び出しが必要になります。 CodeDeploy と Amazon ECS のライフサイクルイベントは同等ですが、以下の表に示すように異なる名前を持ちます。 ライフサイクルイベント CodeDeploy ECS ブルー/グリーン 新しいタスクが作成される前 BeforeInstall PRE_SCALE_UP 新しいタスクが準備完了 AfterInstall POST_SCALE_UP テストポートが有効になる前 同等のものなし TEST_TRAFFIC_SHIFT テストポートがトラフィックを受信する準備完了 AfterAllowTestTraffic POST_TEST_TRAFFIC_SHIFT 本番トラフィックをグリーンに再ルーティングする前 BeforeAllowTraffic PRODUCTION_TRAFFIC_SHIFT 本番トラフィックのグリーンへの再ルーティングが完了 AfterAllowTraffic POST_PRODUCTION_TRAFFIC_SHIFT CodeDeploy と ECS ブルー/グリーンデプロイの両方ともフック実装に Lambda を使用しますが、期待される入力と出力は異なり、特に Lambda 関数がフックステータスのレスポンスを返す方法が異なります。CodeDeploy では、関数は PutLifecycleEventHookExecutionStatus() を呼び出してフック実行ステータスを返す必要があり、これは Succeeded または Failed のいずれかになります。Amazon ECS では、Lambda のレスポンス自体がフック実行ステータスを示すために使用されます。 CodeDeploy は各フックを 1 回限りの呼び出しとして実行し、1 時間以内に最終実行ステータスが返されることを期待します。Amazon ECS フックはより柔軟で、 IN_PROGRESS インジケーターを返すことができ、これは SUCCEEDED または FAILED になるまでフックが繰り返し再実行されるべきであることを示します。フックはデフォルトで 30 秒ごとに実行されますが、レスポンスのパラメータを渡すことで次の実行のタイミングを設定できます。 その他の実装上の考慮事項 CodeDeploy は デプロイグループの詳細オプション の設定を提供しており、これらを Amazon ECS の同等機能にマッピングする必要がある場合があります。これには以下が含まれます。 Amazon Simple Notification Service (Amazon SNS) トリガー：Amazon ECS からの Amazon EventBridge イベントを使用して、状態変更を SNS トピックに発行します。 Amazon CloudWatch アラーム検出と自動ロールバック： Amazon ECS デプロイの失敗検出 機能を使用します。 移行パス CodeDeploy と ECS ブルー/グリーンデプロイ間の実装の違いを考慮した後、適切な移行アプローチを特定する必要があります。いくつかのオプションが利用可能であり、アーキテクチャと要件に最も適合するものを評価する必要があります。関与する要因には以下が含まれます。 ダウンタイム：ダウンタイムは発生するか、発生する場合はどの程度の時間か？ CodeDeploy へのロールバック：ECS ブルー/グリーンデプロイへの切り替えがうまくいかない場合に、移行をロールバックする能力を保持する必要があるか？これは「ブルー/グリーンソリューションのためのブルー/グリーン戦略！」と考えることができます。 サービスディスカバリー：サービスアドレスの変更 (新しい ALB の URI) に対応できるか、それとも同じアドレスを保持する必要があるか？ パフォーマンスおよび/またはデプロイの速度 コスト ロードバランサーの背後に配置された ECS サービスを継続して使用する場合、以下の移行オプションは、Amazon ECS サービス自体とロードバランサーのリソースの両方を考慮して、既存のリソースをどの程度再利用するかについての様々なバリエーションを示しています。すべての場合において、Amazon ECS デプロイコントローラーに渡すための IAM ロール を作成する必要があり、これにより必要なロードバランサーリソースを操作できるようになります。 オプション 1：インプレース更新 このアプローチでは、既存の Amazon ECS サービスを更新して、CodeDeploy デプロイコントローラーではなく、ブルー/グリーンデプロイ戦略を持つ Amazon ECS デプロイコントローラーを使用します。CodeDeploy で使用されているのと同じロードバランサーリスナーとターゲットグループを再利用します。前述のように、CodeDeploy は、サービスに接続されたロードバランサーのリスナーを、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする単一の (デフォルト) ルールで設定します。ECS ブルー/グリーンデプロイの場合、ロードバランサーリスナーは、重み 1 と 0 に設定された 2 つのターゲットグループを含むルールで事前設定されている必要があります。したがって、以下のステップが必要です。 本番/テストリスナーのデフォルトルールを変更して、代替ターゲットグループを含め、ターゲットグループと代替ターゲットグループの重みをそれぞれ 1 と 0 に設定します。 UpdateService() を呼び出して既存の Amazon ECS サービスを更新し、パラメータ deploymentController を ECS に、パラメータ deploymentStrategy を BLUE_GREEN に設定します。IAM ロール、ターゲットグループ、代替ターゲットグループ、本番リスナールール、およびテストリスナールール (オプション) の ARN を渡します。 Amazon ECS デプロイコントローラーが代替ターゲットグループの下で新しいタスクを持つ新しいサービスリビジョンを作成し、すぐにこのターゲットグループにトラフィックを再ルーティングします。これが完了するまで待機し、その後サービスが期待どおりに動作していることを確認します。 ECS ブルー/グリーンデプロイを使用するようになったら、この Amazon ECS サービス用の CodeDeploy リソースを削除します。 インプレース更新は安全な操作ですが、 (1) 手動エラーの可能性を最小限に抑えるためにプロセスを自動化し (特にリスナー設定を変更する場合) 、 (2) 開発者および/または UAT 環境でこのプロセスを徹底的にテストすることに注意する必要があります。また、Amazon ECS コントローラーがサービスリビジョンの初期作成を完了するとすぐにトラフィックが再ルーティングされることも認識しておく必要があります。さらに、再ルーティング前にこのリビジョンをテストするオプションはありません (ただし、タスクは CodeDeploy で実行されていたタスクセットと同一である必要があります) 。 オプション 2：新しい ECS サービスと既存のロードバランサー このアプローチは移行にブルー/グリーン戦略を使用します (言い換えれば、ブルー/グリーンソリューションのためのブルー/グリーン移行です) 。ECS ブルー/グリーンデプロイを使用して新しい並列ブルー/グリーンセットアップを作成し、それを検証し、CodeDeploy セットアップから新しい ECS ブルー/グリーンデプロイセットアップに切り替え、その後 CodeDeploy リソースを削除します。 必要に応じてこのセットアップにロールバックできるように、CodeDeploy セットアップ用のリスナー、ターゲットグループ、および Amazon ECS サービスをそのまま残しておきます。 既存のロードバランサーの下に新しいターゲットグループと新しいリスナー (元のリスナーとは異なるポート) を作成します。その後、既存の Amazon ECS サービスと一致する新しい Amazon ECS サービスを作成しますが、デプロイコントローラーとして ECS を使用し、デプロイ戦略として BLUE_GREEN を使用し、IAM ロール、新しいターゲットグループ、および新しいリスナールールの ARN を渡します。 新しいセットアップを検証します (新しいリスナーのポートを使用) 。すべてがうまくいけば、元のリスナーのポートを異なるポート番号に変更し (元のポートを解放するため) 、新しいリスナーのポートを元のポートに切り替えて、新しいセットアップにトラフィックをルーティングします。 新しいセットアップを観察し、すべてが期待どおりに動作し続けたら、CodeDeploy セットアップを削除できます。 図 4 はこのアプローチを示しています。 図 4：オプション 2 – 新しいサービスと既存のロードバランサー オプション 3：新しい ECS サービスと新しいロードバランサー 前述のアプローチと同様に、このアプローチは移行にブルー/グリーン戦略を使用します。主な違いは、CodeDeploy セットアップから ECS ブルー/グリーンデプロイセットアップへの切り替えが、ロードバランサーの上の別のルーティング層で行われることです (図 5 に示すとおり) 。この層の実装例には、 Amazon Route 53 、 Amazon API Gateway 、および Amazon CloudFront が含まれます。 このアプローチは、すでにこのルーティング層を持っているユーザーに適しており、Amazon ECS サービスとのすべての通信がその層を通じて行われている場合 (つまり、ロードバランサーレベルでの直接通信がない場合) に適用できます。オプション 2 と比較すると、このオプションはゼロダウンタイムという利点がありますが、少しコストが高くなります。 図 5：オプション 3 – 新しいサービスと新しいロードバランサー アプローチの比較 以下の表は、これら 3 つの移行アプローチを、あなたにとって重要度が異なる可能性のある多数の要因で比較しています。この表を使用して、あなた自身の特定の状況と優先事項に最も適したオプションを評価できます。 オプション 1：インプレース更新 オプション 2：新しい ECS サービスと既存のロードバランサー オプション3：新しい ECS サービスと新しいロードバランサー 移行の複雑さ シンプル 既存の Amazon ECS サービスのデプロイメントコントローラーとデプロイメント戦略を更新 より複雑 新しい Amazon ECS サービス、ターゲットグループ、リスナーを作成し、ポートを交換 より複雑 新しい Amazon ECS サービス、ターゲットグループ、ロードバランサー、リスナーを作成し、ルーティング層の設定を変更 リスク軽減オプション 中程度 テスト用の並列ブルー/グリーンセットアップが利用できません。プロセスの自動化とテストに重点を置く 強力 並列ブルー/グリーンセットアップ、トラフィックを再ルーティングする前に新しいセットアップをテスト 強力 並列ブルー/グリーンセットアップ、トラフィックを再ルーティングする前に新しいセットアップをテスト デプロイメントコントローラーのロールバック シンプル サービスデプロイメントコントローラーを CODE_DEPLOY に戻す シンプル ポート交換を元に戻す シンプル ルーティング層の設定変更をロールバック ダウンタイム ダウンタイムなし ポート交換中の最小限の中断 ダウンタイムなし 適用性 制約なし 制約なし 追加のルーティング層が必要 コスト 追加コストなし 追加コスト 関連するタスクを持つ2つの共存する Amazon ECS サービス 追加コスト 関連するタスクを持つ2つの共存する Amazon ECS サービスと追加のロードバランサー まとめ この記事では、AWS CodeDeploy から Amazon ECS の組み込みブルー/グリーンデプロイへの移行について説明しました。この議論には以下が含まれていました。 移行を決定する前に考慮すべき要因 主要なアーキテクチャの違いと関連する実装上の考慮事項 移行にアプローチする 3 つの異なる方法 現在 CodeDeploy を使用しており、ECS ブルー/グリーンデプロイへの移行を検討している場合は、この記事を実現可能性を評価し、移行を計画するためのガイドとして使用できます。ECS ブルー/グリーンデプロイの詳細については、 Amazon ECS の開発者ガイド をご確認ください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

2025 年 12 月 2 日、 Amazon CloudWatch の機能を拡張して、運用、セキュリティ、コンプライアンスのさまざまなユースケースでログデータを統合して管理し、柔軟で強力な分析を 1 か所で行い、データの重複とコストを削減しました。 今回の機能強化により、CloudWatch は、 Open Cybersecurity Schema Framework (OCSF) および Open Telemetry (OTel) 形式の組み込みサポートにより、ソース間の一貫性が保たれるようにデータを自動的に正規化および処理できるため、分析とインサイトに集中できます。CloudWatch では、 Amazon Simple Storage Service (Amazon S3) Tables を介したデータへのApache Iceberg 互換のアクセスも導入されています。これにより、ローカルだけでなく、 Amazon Athena 、 Amazon SageMaker Unified Studio 、またはその他の Iceberg 互換ツールを使用して分析を実行できます。 また、CloudWatch の運用データを、お好みのツールの他のビジネスデータに関連付けて、他のデータと相関することもできます。この統一されたアプローチにより、管理が合理化され、セキュリティ、運用、ビジネスのユースケースを包括的に関連付けることができます。 詳細な機能強化は次のとおりです。 データインジェストと正規化を効率化 — CloudWatch は、複数アカウントや複数の AWS リージョンにわたって AWS が提供するログを自動的に収集し、 AWS Organizations と連携して、 AWS CloudTrail 、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、 AWS WAF アクセスログ、 Amazon Route 53 Resolver ログなどの AWS サービスに対応します。また、エンドポイント (CrowdStrike、SentinelOne)、アイデンティティ (Okta、Entra ID)、クラウドセキュリティ (Wiz)、ネットワークセキュリティ (Zscaler、Palo Alto Networks)、生産性およびコラボレーション (Microsoft Office 365、Windows Event Logs、GitHub) などのサードパーティソース向けの事前構築済みコネクタに加え、ServiceNow CMDB を備えた IT サービスマネージャーとも連携します。CloudWatch では、取り込まれているデータを正規化して処理するために、さまざまな AWS およびサードパーティのデータソース、およびカスタム解析、フィールドレベルの操作、文字列操作を行うための Grok などの他のプロセッサ向けのマネージド OCSF 変換を提供しています。 コストのかかるログデータ管理を削減 — CloudWatch は、ガバナンス機能が組み込まれた単一のサービスにログ管理を統合します。異なるツールやデータストアに同じデータの複数のコピーを保存して維持する必要はありません。CloudWatch の統合データストアにより、複雑な ETL パイプラインが不要になり、複数の個別のデータストアやツールを維持するために必要な運用コストと管理オーバーヘッドが削減されます。 ログデータからビジネス上のインサイトを得る — CloudWatch では、自然言語クエリと LogSQL、PPL、SQL などの一般的なクエリ言語を使用して 1 つのインターフェイスからクエリを実行したり、Apache Iceberg 互換テーブルから任意の分析ツールを使用してデータをクエリしたりできます。新しいファセットインターフェイスでは、ソース、アプリケーション、アカウント、リージョン、ログタイプで直感的にフィルタリングできます。これを使用して、インテリジェントなパラメータ推論により、複数の AWS アカウントとリージョンのロググループにわたってクエリを実行できます。 次のセクションでは、CloudWatch Logs の新しいログ管理および分析機能について説明します。 1.データソースとタイプによるデータの発見と管理 CloudWatch コンソールの新しいログ管理ビューでは、ログとすべてのデータソースの概要を確認できます。開始するには、 CloudWatch コンソール に移動し、左側のナビゲーションペインの [ログ] メニューで [ログ管理] を選択します。 [概要] タブでは、ログ、データソース、タイプ、取り込み後のロググループの状態に関するインサイト、異常を確認できます。 [データソース] タブを選択すると、データソース、タイプ、およびフィールドごとにログデータを検索して管理できます。CloudWatch は、AWS サービス、サードパーティ、またはアプリケーションログなどのカスタムソースごとにデータソースを取り込み、自動的に分類します。 S3 Tables を統合する データソースアクション を選択して、選択したデータソースの今後のログを作成します。Athena や Amazon Redshift、Spark などの他のクエリエンジンを介し、Iceberg 互換のアクセスパターンを使用してログを柔軟に分析できます。この統合により、CloudWatch からのログは読み取り専用の aws-cloudwatch S3 Tables バケットで利用できるようになります。 CloudTrail データなどの特定のデータソースを選択すると、データ形式、パイプライン、ファセット/フィールドインデックス、S3 Tables の関連付け、そのデータソースとのログ数に関する情報を含むデータソースの詳細を表示できます。このデータソースに含まれるすべてのロググループを確認し、新しいスキーマサポートを使用してソース/タイプフィールドインデックスポリシーを入力および編集できます。 データソースとインデックスポリシーの管理方法の詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「 データソース 」を参照してください。 2.CloudWatch パイプラインを使用したインジェストとトランスフォーメーション パイプラインを作成して、テレメトリデータやセキュリティデータの収集、変換、ルーティングを効率化すると同時に、データ形式を標準化してオブザーバビリティとセキュリティデータ管理を最適化できます。CloudWatch の新しいパイプライン機能は、データソースのカタログからのデータを接続するため、ライブラリからパイプラインプロセッサを追加して設定し、データを解析、強化、標準化できます。 [パイプライン] タブで [パイプラインを追加] を選択します。パイプライン設定ウィザードが表示されます。このウィザードでは、5 つの手順に従ってデータソースとその他のソースの詳細 (ログソースタイプなど) を選択し、保存先を設定し、データに対してアクション (フィルタリング、変換、エンリッチングなど) を実行するプロセッサを最大 19 個まで設定し、最後にパイプラインを確認してデプロイすることができます。 CloudWatch の新しい 取り込み 機能を使用してパイプラインを作成するオプションもあります。パイプラインの設定と管理方法の詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「 パイプライン 」を参照してください。 3.データソースに基づく分析とクエリの強化 ファセットとデータソースに基づくクエリをサポートすることで、分析を強化できます。ファセットを使用すると、ログをインタラクティブに探索したり掘り下げたりできます。ファセットの値は、選択した期間に基づいて自動的に抽出されます。 左側のナビゲーションペインの [ログ] メニューの [Log Insights] で [ファセット] タブを選択します。パネルに表示される使用可能なファセットと値を表示できます。1 つまたは複数のファセットと値を選択して、データをインタラクティブに調べることができます。VPC フローログのグループとアクションに関するファセットを選択し、AI クエリジェネレータを使用して VPC フローログで最も頻繁な 5 つのパターンを一覧表示するようにクエリし、結果のパターンを取得します。 選択したファセットと指定した値を使用してクエリを保存できます。保存したクエリを次回選択すると、クエリ対象のログには事前に指定されたファセットと値が含まれます。ファセット管理の詳細については、「CloudWatch Logs ユーザーガイド」の「 ファセット 」を参照してください。 前に説明したように、データソースを S3 Tablesに統合し、まとめてクエリを実行できます。たとえば Athena のクエリエディタを使えば、特定の IP レンジ ( 174.163.137.* ) からのネットワークトラフィックと AWS API アクティビティを相関分析できます。これは、VPC フローログと CloudTrail ログを、送信元 IP アドレスの一致を基に結合することで実現できます。 このタイプの統合検索は、セキュリティモニタリング、インシデント調査、疑わしい動作の検出に特に役立ちます。ネットワークに接続している IP が、ユーザーの作成、セキュリティグループの変更、データへのアクセスなどの機密な AWS 操作も実行しているかどうかを確認できます。 詳細については、「CloudWatch Logs ユーザーガイド」の「 S3 Tablesと CloudWatch の統合 」を参照してください。 今すぐご利用いただけます Amazon CloudWatch の新しいログ管理機能は現在、AWS GovCloud (米国) リージョンと中国リージョンを除くすべての AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。前払いの義務や最低料金はありません。データインジェスト、ストレージ、クエリに既存の CloudWatch Logs を使用した分だけお支払いいただきます。詳細については、 CloudWatch の料金表ページ をご覧ください。 CloudWatch コンソール で試してください。詳細については、 CloudWatch の製品ページ にアクセスしてください。フィードバックは、 AWS re:Post for CloudWatch Logs 、または通常の AWS サポートの担当者までお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。先週の re:Invent 2025 、みなさまはいかがお過ごしでしたか？　現地に来てくださった方も、オンデマンドで視聴いただいた方も、何か学びになるものを身につけていただけましたなら幸いです。 そして、毎年おなじみ 1 時間で振り返る re:invent 速報を今年も開催いたしました。忙しくてなかなかキャッチアップできなかった方も こちらのページ からキャッチアップをお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、12 月 08 日週の生成 AI with AWS界隈のニュースを見ていきましょう。re:Invent 2025 で発表された内容が続々と日本語化されています。ぜひお役立てください。 さまざまなニュース お客様事例 AWS生成AI国内事例ブログ: エスツーアイ株式会社様、Kiro を活用した経費精算システムの迅速な開発 エスツーアイ株式会社様は、愛知県に本社を置く製造業向けシステムインテグレーションサービス企業です。同社では、経営層が AI コーディングの重要性を認識していたものの、現場エンジニアが日々の業務に追われ、新しい技術に取り組む余裕がない状況でした。この課題を解決するため、AI IDE「Kiro」を活用して出張経費精算システムの開発に取り組まれました。ベテランエンジニアが実働約 10 日間（1 日 1〜2 時間の作業）で基本機能を実装し、従来手法と比較して大幅な期間短縮を実現されました。特に Kiro の「Vibe」と「Spec」の使い分けにより、コード生成とドキュメント作成の両方を効率化できたことが成功のポイントでした。 AWS生成AI国内事例ブログ: 明治ホールディングス株式会社様、Amazon Q Developer 導入により 80-90% の生産性向上を実現 明治ホールディングス株式会社様のグループ DX 推進部 AWS 事務局では、300 を超える AWS アカウントを 20 名のメンバーで管理する中で、開発・運用効率化が課題となっていました。Amazon Q Developer を段階的に導入し、ドキュメント・設計資料の自動化、Infrastructure as Code 開発の効率化、運用・トラブルシューティングの高度化、組織全体の管理基盤整備を実現されました。その結果、AWS 事務局全体で 80-90% の生産性向上を達成し、30 名超が継続的に活用されています。特に Model Context Protocol サーバの利用により、素早く正確な情報へのアクセスと調査、ドキュメント生成が可能になりました。 AWS生成AI国内事例ブログ: 地方病院がシステムの内製化に挑戦、IT 知識ゼロから始めた生成 AI による業務効率化への 90 日 兵庫県立リハビリテーション中央病院様と熊本中央病院様が、ANGEL Dojo 2025 プログラムに参加し、IT 知識ゼロの状態から 90 日間で生成 AI を活用したシステム開発に取り組まれました。兵庫県立様は Amazon Bedrock を用いたリハビリスケジュール自動化で 60% の自動化を実現し、月当り約 36 単位（88,200 円）の収益増加を見込んでいます。熊本中央病院様は退院サマリ等の文書作成に生成 AI を活用し、月 800 時間の文書作成時間削減を確認されました。企業とパートナーによる共創型内製化により、医療機関でも AI を活用したシステム開発が現実的になることを実証されています。 技術記事 ブログ記事「 Amazon Nova 2 Sonic の紹介: 会話型 AI 向けの新しい音声変換モデル 」を公開 2025 年 12 月 2 日に発表された Amazon Nova 2 Sonic は、自然でリアルタイムな音声対話をアプリケーションにもたらす音声変換の基盤モデルです。この記事では、業界トップクラスの会話品質と価格設定を実現する Nova 2 Sonic の特徴を詳しく解説しています。多言語サポートの拡張（ポルトガル語とヒンディー語を追加）、ポリグロット音声による言語切り替え機能、自然なターンテイキング、クロスモーダルインタラクション、非同期ツール呼び出しなど、実用的な音声 AI アプリケーション開発に役立つ機能が紹介されています。 ブログ記事「 高速で費用対効果の高い推論モデル、Amazon Nova 2 Lite の紹介 」を公開 Amazon Nova 2 Lite は、日常のワークロードに対応する高速で費用対効果の高い推論モデルとして 12 月 2 日にリリースされました。この記事では、拡張思考（Extended Thinking）機能による段階的な推論、100 万トークンのコンテキストウィンドウ、ウェブグラウンディングとコードインタープリターの組み込みツールなど、Nova 2 Lite の特徴を紹介しています。ビジネスアプリケーション、ソフトウェアエンジニアリング、ビジネスインテリジェンスなど幅広いユースケースでの活用方法も解説されています。 ブログ記事「 新しい AWS Security Agent は、設計からデプロイまでアプリケーションをプロアクティブに保護します（プレビュー） 」を公開 2025 年 12 月 2 日に発表された AWS Security Agent は、開発ライフサイクル全体を通じてアプリケーションを積極的に保護するフロンティアエージェントです。この記事では、設計セキュリティレビュー、コードセキュリティレビュー、オンデマンド侵入テスト機能を提供する AWS Security Agent の詳細を解説しています。AI を活用した自動セキュリティレビューと状況に応じた侵入テストにより、開発の早い段階で脆弱性を防ぐことができ、従来の手動プロセスと比較して大幅な時間短縮を実現します。 ブログ記事「 Amazon Bedrock を活用した太陽光発電データの異常検知・分析システムの構築事例 」を公開 株式会社エナリス様および KDDI アジャイル開発センター株式会社様と共同で執筆した、Amazon Bedrock を活用した太陽光発電データの異常検知・分析システムの構築事例を紹介しています。この記事では、Amazon Bedrock Agents と Amazon Bedrock Knowledge Bases を組み合わせて、太陽光発電設備の運用データから異常を検知し、分析結果を自然言語で提供するシステムの実装方法を解説しています。生成 AI を活用したデータ分析の実践的な事例として参考になります。 ブログ記事「 Amazon Bedrock AgentCore には、信頼できる AI エージェントをデプロイするための品質評価とポリシーコントロールが追加されました 」を公開 2025 年 12 月 2 日に発表された Amazon Bedrock AgentCore の新機能について解説した記事です。AgentCore のポリシー機能により、詳細な権限を持つポリシーを使用してエージェントアクションの明確な境界を定義できます。AgentCore Evaluations では、組み込みエバリュエーターを使用して実際の行動に基づいてエージェントの質をモニタリングします。また、AgentCore Memory のエピソード機能により、エージェントが経験から学び、将来の同様のタスクの一貫性とパフォーマンスを向上させることができます。 ブログ記事「 Amazon Bedrockは、開発者がより賢く、より正確なAIモデルを構築する方法を簡素化する強化学習によるファインチューニングを追加しました 」を公開 Amazon Bedrock に新たに追加された強化学習ファインチューニング機能について詳しく解説した記事です。従来の大規模なラベル付きデータセットを必要とする手法とは異なり、フィードバックから学習してモデルを改善する新しいアプローチを紹介しています。基本モデルと比較して平均 66% の精度向上を実現し、深い機械学習の専門知識なしに高度なモデルカスタマイズが可能になることが説明されています。 ブログ記事「 MCP を用いた Amazon Connect の監視運用準備 」を公開 Model Context Protocol (MCP) と生成 AI を活用して Amazon Connect の監視機能を強化する方法を紹介した記事です。MCP と Amazon Connect の組み合わせにより、フロー効率の分析や監視設定の最適化などが自然言語で直感的に行えるようになり、コンタクトセンターの運用準備体制の向上に役立つことが解説されています。 ブログ記事「 小売業の未来を読み解く：AI ショッピングエージェントの活用 」を公開 AI を活用したショッピングエージェントが小売業界に与える影響と、Model Context Protocol (MCP) を活用した対応策について解説した記事です。AI エージェントが商品発見と購入方法を根本的に変革する中で、小売企業が AWS 上に MCP サーバーを構築することで、AI エージェントとの直接的な関係を築き、競争優位性を確保する方法を紹介しています。 ブログ記事「 AWS Transform discovery tool の紹介 」を公開 VMware インフラストラクチャにデプロイする Open Virtual Appliance（OVA）として提供される AWS Transform discovery tool について解説した記事です。クラウド接続や外部依存関係を必要とせずにオンプレミスでデプロイできる自己完結型アプリケーションとして動作し、ワークロードからパフォーマンスデータとネットワーク接続データを収集します。厳格に規制された業界や、厳格なデータガバナンス要件を持つ組織での移行準備に適しています。 ブログ記事「 Amazon SageMaker AI の新しいサーバーレスカスタマイズにより、モデルのファインチューニングが加速します 」を公開 Amazon Nova、DeepSeek、GPT-OSS、Llama、Qwen などの人気の AI モデル向けの Amazon SageMaker AI の新しいサーバーレスカスタマイズ機能について解説した記事です。強化学習などの最新ファインチューニング手法を簡単に操作できるインターフェイスを提供し、AI モデルのカスタマイズプロセスを数か月から数日に短縮できます。完全にサーバーレスで実行されるため、インフラ管理ではなくモデルのチューニングに専念できます。 ブログ記事「 Amazon SageMaker HyperPod でのチェックポイントなしかつ弾力的なトレーニングの紹介 」を公開 Amazon SageMaker HyperPod における 2 つの新しい AI モデル訓練機能について解説した記事です。チェックポイントレストレーニングは、従来のチェックポイントベースのリカバリーの必要性を軽減し、数時間かかる復旧時間を数分に短縮します。エラスティックトレーニングは、リソースの可用性に基づいて AI ワークロードを自動的にスケールさせることを可能にし、クラスターの利用効率を最大化します。 サービスアップデート Amazon Quick Suite でレポート自動化のための Research と Flow の統合機能を発表 Amazon Quick Suite に、データ分析と研究ワークフローを自動化する新機能が追加されました。この機能により、複雑なデータ分析プロセスを自動化し、レポート生成の効率化が可能になります。生成 AI を活用したインサイト抽出と組み合わせることで、より高度なビジネスインテリジェンス機能を提供します。 Amazon Aurora PostgreSQL で Kiro powers 統合を発表 Amazon Aurora PostgreSQL に、AI 開発プラットフォーム Kiro との統合機能が追加されました。この統合により、データベース操作と AI 開発ワークフローをシームレスに連携させることが可能になり、データドリブンな AI アプリケーションの開発効率が向上します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見た映画は「舟を編む」です。

本ブログは 2025 年 12 月 4 日に公開された AWS Blog “ China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182) ” を翻訳したものです。 2025 年 12 月 12 日: ReactJS バージョンの更新が必要となるタイミングを明確にするため、このブログ記事を更新しました。 2025 年 12 月 3 日に CVE-2025-55182 (React2Shell) が公開されてから数時間以内に、Amazon の脅威インテリジェンスチームは、Earth Lamia や Jackpot Panda を含む複数の中国国家支援型脅威グループによる活発な悪用試行を観測しました。React Server Components におけるこの重大な脆弱性は、共通脆弱性評価システム (CVSS) スコアが最大値の 10.0 であり、App Router を使用している React バージョン 19.x および Next.js バージョン 15.x と 16.x に影響します。この脆弱性は AWS サービスには影響しませんが、お客様自身の環境で React または Next.js アプリケーションを実行しているお客様が直ちに対応できるよう、この脅威インテリジェンスを共有します。 中国は引き続き国家支援型サイバー脅威アクティビティの最も活発な発信源であり、脅威アクターは公開エクスプロイトを開示から数時間または数日以内に日常的に実戦投入しています。 AWS MadPot ハニーポットインフラストラクチャでの監視を通じて、Amazon の脅威インテリジェンスチームは、既知のグループとこれまで未特定だった脅威グループの両方が CVE-2025-55182 の悪用を試みていることを特定しました。AWS は、Sonaris アクティブディフェンス、 AWS WAF マネージドルール ( AWSManagedRulesKnownBadInputsRuleSet バージョン 1.24 以降)、および境界セキュリティコントロールを通じて、複数層の自動保護をデプロイしています。ただし、これらの保護はパッチ適用の代替にはなりません。お客様がフルマネージド AWS サービスを使用しているかどうかに関わらず、お客様の環境で影響を受けるバージョンの React または Next.js を実行している場合は、直ちに最新のパッチ適用済みバージョンに更新する必要があります。お客様自身の環境 ( Amazon Elastic Compute Cloud (Amazon EC2) 、コンテナなど) で React または Next.js を実行しているお客様は、脆弱なアプリケーションを直ちに更新する必要があります。 CVE-2025-55182 (React2Shell) の理解 Lachlan Davidson によって発見され、2025 年 11 月 29 日に React チームに開示された CVE-2025-55182 は、React Server Components における安全でないデシリアライゼーション脆弱性です。この脆弱性はセキュリティ研究者によって React2Shell と名付けられました。 主要な事実 CVSS スコア : 10.0 (最大深刻度) 攻撃ベクトル : 認証不要のリモートコード実行 影響を受けるコンポーネント : React 19.x および App Router を使用する Next.js 15.x/16.x の React Server Components 重要な詳細 : React Server Components をサポートしている限り、サーバー関数を明示的に使用していなくてもアプリケーションは脆弱です この脆弱性は Vercel によって Meta および AWS を含む主要なクラウドプロバイダーに責任を持って開示され、脆弱性の公開開示前に協調的なパッチ適用と保護のデプロイが可能になりました。 CVE-2025-55182 を悪用しているのは誰か AWS MadPot ハニーポットインフラストラクチャにおける悪用試行の分析により、既知の中国国家支援型脅威アクターに歴史的に関連する IP アドレスとインフラストラクチャからの悪用アクティビティを特定しました。中国の脅威グループ間で匿名化インフラストラクチャが共有されているため、攻撃主体の明確な特定は困難です。 Earth Lamia に関連するインフラストラクチャ : Earth Lamia は、ラテンアメリカ、中東、東南アジアの組織を標的とするために Web アプリケーションの脆弱性を悪用することで知られる中国関連のサイバー脅威アクターです。このグループは歴史的に、金融サービス、物流、小売、IT 企業、大学、政府組織などのセクターを標的としてきました Jackpot Panda に関連するインフラストラクチャ : Jackpot Panda は、主に東アジアおよび東南アジアのエンティティを標的とする中国関連のサイバー脅威アクターです。このアクティビティは、国内の安全保障と汚職に関する懸念に関連する収集の優先事項と一致している可能性があります 共有匿名化インフラストラクチャ : 大規模な匿名化ネットワークは中国のサイバー作戦の特徴となっており、攻撃元を隠しながら偵察、悪用、コマンド&コントロール (C2) アクティビティを可能にしています。これらのネットワークは複数の脅威グループによって同時に使用されるため、特定のアクティビティを個々のアクターに結びつけることが困難になっています これは、中国関連のサイバー脅威アクティビティと共通性を持つ他の多くの攻撃主体不明の脅威グループに加えてのものです。攻撃主体不明のアクティビティで観測された自律システム番号 (ASN) の大部分は中国のインフラストラクチャに関連しており、ほとんどの悪用アクティビティがその地域から発生していることをさらに確認しています。これらのグループが公開概念実証 (PoC) エクスプロイトを実戦投入した速さは、重大な事実を浮き彫りにしています。すなわち、PoC がインターネットに公開されると、高度な脅威アクターはそれらを迅速に武器化するということです。 悪用ツールと技術 脅威アクターは、自動スキャンツールと個別の PoC エクスプロイトの両方を使用しています。観測された一部の自動ツールには、ユーザーエージェントのランダム化などの検出を阻止する機能があります。これらのグループは、CVE-2025-55182 にアクティビティを限定していません。Amazon の脅威インテリジェンスチームは、CVE-2025-1338 を含む他の最近の N-day 脆弱性を同時に悪用していることを観測しました。これは体系的なアプローチを示しています。脅威アクターは新しい脆弱性の開示を監視し、公開エクスプロイトをスキャンインフラストラクチャに迅速に統合し、複数の CVE にわたって広範なキャンペーンを同時に実施して、脆弱なターゲットを見つける可能性を最大化します。 公開 PoC の現実: 品質より量 調査からの注目すべき観察は、多くの脅威アクターが実際のシナリオでは実際には機能しない公開 PoC を使用しようとしていることです。GitHub セキュリティコミュニティは、脆弱性の仕組みを正しく理解していない複数の PoC を特定しています。 一部の悪用可能なアプリケーションの例では、サーバーマニフェストに危険なモジュール ( fs 、 child_process 、 vm ) を明示的に登録していますが、これは実際のアプリケーションでは決して行うべきではありません いくつかのリポジトリには、安全なバージョンにパッチを適用した後でも脆弱なままになるコードが含まれています 多くの公開 PoC の技術的不備にもかかわらず、脅威アクターは依然としてそれらを使用しようとしています。これはいくつかの重要なパターンを示しています。 正確性より速度 : 脅威アクターは徹底的なテストよりも迅速な実戦投入を優先し、利用可能な任意のツールでターゲットを悪用しようとします ボリュームベースのアプローチ : 複数の PoC (機能しないものでも) で広範にスキャンすることで、アクターは脆弱な設定のわずかな割合を見つけることを期待しています 参入障壁の低さ : 公開エクスプロイトの利用可能性は、欠陥があっても、より洗練されていないアクターが悪用キャンペーンに参加することを可能にします ノイズの生成 : 失敗した悪用試行はログに大量のノイズを生成し、より高度な攻撃を隠す可能性があります 持続的かつ体系的な攻撃パターン MadPot からのデータ分析により、これらの悪用試行の持続的な性質が明らかになりました。注目すべき例として、IP アドレス 183[.]6.80.214 に関連する攻撃主体不明のアクティビティの脅威グループが、約 1 時間 (2025/12/4 02:30:17 〜 03:22:48 UTC) にわたって体系的に悪用試行のトラブルシューティングを行いました。 52 分間で合計 116 件のリクエスト 複数のエクスプロイトペイロードを試行 Linux コマンド ( whoami 、 id ) の実行を試行 /tmp/pwned.txt へのファイル書き込みを試行 /etc/passwd の読み取りを試行 この動作は、脅威アクターが単に自動スキャンを実行しているだけでなく、実際のターゲットに対して悪用技術を積極的にデバッグし、改良していることを示しています。 AWS によるお客様の保護 AWS は、お客様を保護するために複数層の保護をデプロイしました。 Sonaris アクティブディフェンス AWS の Sonaris 脅威インテリジェンスシステムは、この脆弱性を標的とする悪意のあるスキャン試行を自動的に検出し、制限しました。Sonaris は毎分 2,000 億を超えるイベントを分析し、MadPot ハニーポットネットワークからの脅威インテリジェンスを統合して、悪用試行をリアルタイムで特定しブロックします。 AWS WAF マネージドルール AWS WAF AWSManagedRulesKnownBadInputsRuleSet のデフォルトバージョン (1.24 以降) には、CVE-2025-55182 に対応する更新されたルールが含まれており、マネージドルールセットで AWS WAF を使用しているお客様に自動保護を提供します。 MadPot インテリジェンス AWS のグローバルハニーポットシステムは、悪用試行の早期検出を提供し、迅速な対応と脅威分析を可能にしました。 Amazon 脅威インテリジェンス Amazon 脅威インテリジェンスチームは、AWS インフラストラクチャを保護するために CVE-2025-55182 の悪用試行を積極的に調査しています。お客様のインフラストラクチャが侵害された兆候を特定した場合、AWS サポートを通じて通知します。ただし、アプリケーション層の脆弱性は、ネットワークテレメトリだけでは包括的に検出することが困難です。AWS からの通知を待たないでください。 重要 : これらの保護はパッチ適用の代替にはなりません。お客様自身の環境 (Amazon EC2、コンテナなど) で React または Next.js を実行しているお客様は、脆弱なアプリケーションを直ちに更新する必要があります。 直ちに推奨される対応 脆弱な React/Next.js アプリケーションを更新してください。影響を受けるバージョンとパッチ適用済みバージョンについては、AWS セキュリティ速報 ( https://aws.amazon.com/security/security-bulletins/AWS-2025-030/ ) を参照してください 暫定的な保護として、カスタム AWS WAF ルールをデプロイしてください (ルールはセキュリティ速報に記載されています) アプリケーションおよび Web サーバーのログで不審なアクティビティを確認してください next-action または rsc-action-id ヘッダーを含む POST リクエストを探してください アプリケーションサーバーで予期しないプロセス実行やファイル変更を確認してください アプリケーションが侵害された可能性があると思われる場合は、 インシデント対応の支援について直ちに AWS サポートケースを開いてください 。 注: マネージド AWS サービスを使用しているお客様は影響を受けず、対応は不要です。 侵害指標 (IoC) ネットワーク指標 next-action または rsc-action-id ヘッダーを含むアプリケーションエンドポイントへの HTTP POST リクエスト $@ パターンを含むリクエストボディ "status":"resolved_model" パターンを含むリクエストボディ ホストベース指標 偵察コマンド ( whoami 、 id 、 uname ) の予期しない実行 /etc/passwd の読み取り試行 /tmp/ ディレクトリへの不審なファイル書き込み (例: pwned.txt ) Node.js/React アプリケーションプロセスによって生成された新しいプロセス 脅威アクターのインフラストラクチャ IP アドレス, アクティビティ日, 攻撃主体 206[.]237.3.150, 2025-12-04, Earth Lamia 45[.]77.33.136, 2025-12-04, Jackpot Panda 143[.]198.92.82, 2025-12-04, 匿名化ネットワーク 183[.]6.80.214, 2025-12-04, 攻撃主体不明の脅威グループ 追加リソース AWS セキュリティ速報: CVE-2025-55182 https://aws.amazon.com/security/security-bulletins/AWS-2025-030/ AWS WAF ドキュメント: https://docs.aws.amazon.com/waf/ React チームセキュリティアドバイザリ: https://react.dev/blog/2025/12/03/react-server-components-security-advisory ご質問がある場合は、 AWS サポートにお問い合わせください 。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。CJ は Amazon 全体のセキュリティエンジニアリングと運用を統括しています。彼の使命は、セキュリティを最も導入しやすい選択肢とすることで、Amazon のビジネスを支援することです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO、そして最近では AWS CISO など、さまざまな役割を担当した後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon に入社する前、CJ は連邦捜査局 (FBI) のサイバー部門でコンピュータおよびネットワーク侵入アクティビティの技術分析を主導していました。CJ は空軍特別捜査局 (AFOSI) の特別捜査官も務めました。CJ は、今日のセキュリティ業界の基礎となるいくつかのコンピュータ侵入調査を主導しました。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、アクティブな SRO GT America GT2 レースカードライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

こんにちは、プロトタイピングソリューションアーキテクトの 市川です。本日は AWS Summit 2025 や IoT@Loft にもご登壇いただいたブラザー工業株式会社で IoT プラットフォームの開発・運用に携わっていらっしゃるP&S事業 SC開発部の瀧尻 氏と 墨 氏 にお時間をいただき、イベントでは語りきれなかった Deep な話について質問させていただきました。 自己紹介 市川: 本日はよろしくお願いします。イベントの動画やスライドでも紹介されていますが、簡単にお二人の自己紹介をお願いできますでしょうか？ 瀧尻: 新 IoT プラットフォーム開発のプロダクトオーナーを務めました。チームメンバーに恵まれ、とても充実した開発を経験できました。数多くの設計判断をしましたが、”理由さえ残せば、あとでチームとともに修正できる”というスタンスで臨みました。コードよりもドキュメントや ADR・Wiki ページを 10 倍書きました。 墨: 開発・実装担当として、IoT プラットフォームの開発に携わりました。運用フェーズに移行してからは、プロダクトオーナーを継承し、DevOps による改善を続けています。まだまだエンジニア歴は浅いですが、「AWS のサーバーレスサービスを組み合わせれば、本番システムの開発も怖くない」と感じるようになりました。 IaC による属人化排除とリソース管理の工夫 市川: セッションでのお話で特に印象的だったのが、IaC(CDK) によるデプロイに制限することで属人化を排除されている取り組みですが、そのように決めた経緯について教えていただけますか？ 瀧尻: つくった IoT プラットフォームを様々な事業・用途で使ってもらうためには、どのように各事業に提供すればよいか、ということを考えました。手動作業が多いと導入の敷居が高くなる上、導入先ごとの差分や予期しない変更が発生してしまうおそれがあります。なるべくコマンド1つでまったく同じ構成のものを一式デプロイできることが望ましいです。そこで、CDK を利用して IoT プラットフォーム一式を構成し、配布できるようにしました。CDK には TypeScript を採用したので、AWS Lambda 関数の実装言語とも統一できました。 市川: 複数の環境を管理する場合は、IaC 化をすることで、プラットフォームごとに差分が出ずに管理ができますからね。IoT プラットフォームでは、全体のアーキテクチャのような比較的固定的な部分と、Thing や証明書のように随時増えていくリソースがあると思いますが、どの範囲を IaC で管理され、増えていくリソースはどのように管理されているのか、詳しく教えていただけますか？ 瀧尻: 私たちは大きくコントロールプレーンとデータプレーンに分けて考えています。 まずコントロールプレーンについては、3つのレベルで管理を分けています。どのような用途・環境であっても共通 IoT プラットフォームとして構成を強制する部分は CDK で管理、用途ごとに調整可能にするものは CDK + 環境変数で管理、そして事業や用途・デプロイした環境ごとに運用上異なるものは CDK 外での手動設定としています。また AWS Organizations によって AWS アカウントに適用される構成設定もあります。 一方のデータプレーンについては、事業・用途・環境ごとに運用者が管理する形にしています。 具体的には、まず CCoE が管理する AWS Organizations により AWS Security Hub、Amazon GuardDuty 、AWS CloudTrail 、Amazon Inspector などの設定が AWS アカウント単位で適用されます。 IoT プラットフォームとしての IaC 管理には、 AWS IoT Core のルール、Thing に付与するポリシー、Amazon API Gateway、AWS Lambda 、Amazon DynamoDB、Amazon SNS、Amazon S3、AWS Identity and Access Management (IAM)、AWS Config、Amazon CloudWatch などの構成定義を含めています。 IaC 管理しつつ環境変数で調整可能にしているのは、ステージ名や環境識別子プレフィクス、AWS Lambda メモリサイズ、出力ログレベル設定、Amazon DynamoDB や Amazon CloudWatch Logs の TTL・保持期間、そして一部機能のオンオフ（データ基盤連携、ログへの本文ダンプ有無など）です。 IaC 管理外で手動運用としているのは、開発者のロール、Amazon Route53 ドメイン・ACM 証明書、AWS IoT Core に登録する CA 証明書、API Key などの認証情報、異常通知の通知先、外部システムが Amazon SNS トピックをサブスクライブするポリシー設定、Cost Anomaly Detection や AWS Budgets 設定、そして Amazon CloudWatch Dashboards などがあります。 データプレーンについては、運用に伴い増加・変動するものとして、Thing、Thing証明書、Device Shadow の内容、一時クレデンシャルやトークン、IoT Job、Amazon DynamoDB の内容（コマンド履歴、デバイスの通知設定など）、各種ログ、メトリクス値などがあり、これらは IaC 管理外としています。 市川: なるほど、コントロールプレーン、データプレーン で分けるという観点は良いですね。それに加えて組織という単位でも分かれるという考え方は、とても参考になります。 事業部に提供した後の運用はどのように行われているのでしょうか？ 墨: 開発は SC 開発部の IoT プラットフォーム開発チームが専任で行い、定期的に社内にリリースしています。導入先の事業ごとに、リリースバージョンを指定して CDK 一式を取得(git clone) し、それぞれの IoT プラットフォーム用 AWS アカウントへデプロイします。なお、P&S 事業用の IoT プラットフォームの運用は、DevOps として私たち開発チームが担当しています。 事業ごとに開発されるサービスサーバーとの独立性を保つために、1システム – 1アカウントの原則を採用し、事業ごとの IoT プラットフォームはサービスサーバーとは別の AWS アカウントを使用します。各導入先での、IoT プラットフォームそのものの改造・変更は禁止しており、手順に従い CDK 一式をそのままデプロイしてもらっています。AWS Config ルールによりAWS CloudFormation のドリフトを検出する機構も CDK による定義に含めているため、意図せず、手動でリソースの設定などを変更してしまった場合にも気付くことができます。仕様や機能の要望があれば、IoT プラットフォーム開発チームが交流と発展のチャンスとばかりに飛びつき、対応しています。 遠隔からの印刷を実現する仕組み 市川: IoT プラットフォームで提供されている仕組みについてお聞きしたいのですが、実は我が家では御社のプリンターを利用していまして、受験を控えた子どもの問題集の印刷など、さまざまなサイズや用途の印刷に対応していて大変重宝しています。課題とかで写真の印刷も必要な時に、スマートフォンからの印刷をすることも多いのですが、反応が非常に速いのでどのような仕組みなのか気になっていました。このようなリモート印刷は IoT@Loft で紹介いただいた過疎地域の新聞印刷の取り組みでも活用されているとのことですが、他にもこの仕組みは利用されているのでしょうか？ 墨: 外出先からオフィスのプリンターへレポートを送ったり、遠方に住むご家族へ写真を送ることもできます。また、LINE から印刷することもできます。ここではメール添付印刷を例に内側をご紹介します。 まず、E メールで送られたデータをリモート印刷システムが受信し、IoT プラットフォームに対してリモート印刷指示を出します。IoT プラットフォームは、プリンターがサブスクライブしている MQTT トピックへその指示を Publish します。プリンターはそれを即時受信し、印刷データをダウンロードしながら印刷します。つまり、大きな印刷データを全て受信し終える前に動きはじめます。印刷し終えると、プリンターは HTTP API により、IoT プラットフォームへ印刷結果を通知します。 このように、即時性が重要なクラウド側からデバイスへの指示伝達には、MQTT の常時接続を用いています。 市川: AWS IoT Core が対応している MQTT は常時接続のプロトコルですので、あの反応の速さにつながっているんですね。リモート印刷との相性がとても良いように思います。 大規模IoTデバイス管理におけるコスト最適化 市川: IoTのユースケースでは大量のデバイスがつながることが多いと思いますが、コストに関してなにか工夫をされていることはありますか？ 墨: 一度作ったシステムをそのまま維持するのではなく、より最適化できないかという視点を持ち続けるようにしています。その一環として、AWS の SA や TAM から情報をいただいたり、AWS の News Update の RSS を Slack で購読するなどして、関係しそうな新サービス・新機能をチームでウォッチしています。 デバイスの MQTT 接続状態を正確に把握することは意外と難しく、従来はデバイスが Shadow に明示的に状態を記録し、不慮の切断時は LWT により状態を更新する、という仕組みをとっていました。しかし、この仕組みの場合は、接続状態の更新の度に様々な処理が動くため、コストの面でも気になっていました。2024/12に AWS IoT Core の接続ステータスクエリ API が発表され、これは何だろうか？とチームで調査しました。AWS IoT Core がデバイスの正確な MQTT 接続状態を提供してくれる機能であることがわかり、チームを挙げてこれを利用した内部構造への改良を行いました。コストダッシュボードでも、この仕組みを導入したタイミングの前後で、AWS IoT Core 関連コストの減少が観測できました。 市川: 新しい機能を積極的に取り込んでいただくことにより改善が進む良い事例ですね。ちなみに、コストダッシュボードとおっしゃいましたが、どのような監視をされているのでしょうか？ 瀧尻: システム全体の状況は AWS CloudWatch のダッシュボードを使って監視しています。上にビジネスメトリクス的なグラフを、下にいくほどシステムメトリクスや内部状況のグラフを配置して、全体を把握してから詳細を確認できる導線をつくりました。ダッシュボードには「登録デバイス台数」「MQTT 接続台数」「各 API リクエスト数」「レイテンシ」「各 AWS Lambda 呼び出し回数」「AWS Lambda 同時実行数」「エラー・Warn 発生数」、「各ロググループ記録容量」といったメトリクスのグラフを作成し、スクラムの朝会で一通り眺める習慣になっています。複数環境・アカウントありますが、AWS CloudWatch のクロスアカウント機能で1つのアカウントのダッシュボードに集約しました。 コストダッシュボードは、各環境のコスト推移を監視するために作成した AWS CloudWatch のダッシュボードのことです。1日ごとのコストの推移、コスト上位の主要なサービスの内訳推移、デバイス1台あたりの推定年間コストの推移、月次コストの推移をグラフ化しています。こちらは AWS CloudWatch 標準のメトリクスでないため、GitHub Actions を使って各環境の AWS Cost Explorer の情報を取得し、毎晩集約アカウントの AWS CloudWatch メトリクスに登録しグラフ化しています。IoT プラットフォームの設計時に目標とした1台あたりの年間コストがありますが、各環境、稼働開始直後のデバイス数が少ない時期は、メトリクスやアラーム、Amazon GuardDuty などのほぼ固定費な要素により割高になりますが、デバイス数の増加に伴い、目標コストのレンジに収束しています。 AWS Budgets を用いたコストアラートも各環境に設定し、意図しないコスト増があってもすぐに気付けるようにしています。 市川:  コストを下げる取り組みの基点として、AWS CloudWatch のダッシュボードを作って可視化を行っているのはとても良い取り組みですね。これらのダッシュボードを朝会でチェックされているとのことですが、どのような気づきがありましたか？ 墨: チームで定期的に取り組んでいるコスト最適化を、本番環境にデプロイした前後のコスト変化にはいつも着目しており、下がった際には皆で喜びます。また、リージョン障害やその後の段階的な復旧の様子も、ひと目で確認できます。加えて、地域ごとのイベントや長期休暇のシーズンには、接続数やアクセス数に変化がみられます。販売のキャンペーン期間には、新規の登録台数が増加する様子も確認できます。グラフの期間を変えることで、短期と長期の変化や傾向を把握でき、しばしばチームで課題探索や将来予想にも活用しています。 さいごに 本日は貴重なお話をありがとうございました。IaC による運用の標準化から、大規模 IoT デバイスの管理、そしてコストの監視と、非常に参考になるお話をお聞かせいただきました。 特に印象的だったのは、プラットフォームを提供する側として、いかに事業部が使いやすく、かつ管理しやすい仕組みを構築されているかという点です。また、継続的な改善とコスト最適化への取組みも、多くの AWS 利用者にとって参考になる事例だと思います。 今後もブラザー工業様の IoT プラットフォームの進化に注目していきたいと思います。 参考： AWS Summit Tokyo 2025 オフィス機器から産業機器まで多様な製品群に対応する IoT プラットフォームの構築：長期運用を目指し、アジャイルで小さく始める設計 AWSブログ IoT@Loft #27 AI時代にIoTを語れ！【祝】AWS IoT Core 10周年レポート【開催報告＆資料公開】 ブラザー工業様登壇：未来へつなぐ IoT ～IoT でモノはもっと価値をもつ～

2025 年 12 月 2 日、自然でリアルタイムな音声対話をアプリケーションにもたらす音声変換の基盤モデル Amazon Nova 2 Sonic の一般提供開始を発表しました。このモデルは、業界トップクラスの会話品質、価格設定、クラス最高の音声理解を実現し、開発者が音声アプリケーションを構築できるようにします。 Amazon は 10 年以上にわたって音声ベースのテクノロジーをリードしてきました。今年の初めに、真にスムーズな音声インタラクションを実現するという根本的な課題を解決するために、 第 1 世代の Nova Sonic を発表しました 。これは、音声コンテキストを維持して音声応答をユーザーの言ったことだけでなく、どのように言ったかに適応させることです。Nova 2 Sonic では、その基盤の上にモデルの機能性とアクセシビリティを高め、モデルインテリジェンスとエージェントの機能を改善し、言語サポートを拡大し、より直感的で人間のような音声インタラクションを実現するための幅広い新機能を追加しました。 Nova 2 Sonic は、ネイティブの表現力、自然なターンテイキング、ユーザーによる中断へのシームレスな処理により、サポートされている各言語で、表現力豊かな声、男性の声と女性の声を提供します。人間の好みの評価によると、リスナーは全体的なリスニング体験において、他の主要モデルよりも常に Nova 2 Sonic 出力を好んでいます。 Nova 2 Sonic は、主要な評価ベンチマークの改善に裏付けられた、強力なインテリジェンスとより信頼性の高いエージェンティックな動作を提供します。このモデルは、オーディオ入力による推論能力を評価するための評価データセットである Big Bench Audio では、他の主要な会話型 AI モデルよりも優れています。その BFCL ベンチマーク スコアは、より正確で一貫性のある関数呼び出しを示していますが、 ComplexFuncBench の結果は、マルチステップで制約の多いタスクの処理の改善を反映しています。 Common Voice を使用して自動音声認識 (ASR) の精度の向上を実証し、 指示フォロー評価 (iFEval) を使用して、詳細で構造化された指示に従う際の精度が高いことを示しました。 音声理解の向上 Nova 2 Sonic では、基盤となる音声認識機能が大幅に強化されました。このモデルでは、英数字入力、短い発話、8kHz のテレフォニー音声入力をより正確に処理できるようになりました。また、実際のデプロイシナリオでは重要な、さまざまなアクセントやバックグラウンドノイズを処理する場合にもより堅牢になります。 多言語の声によるグローバルリーチの拡大 Nova 2 Sonic の最も重要なアップデートの 1 つは、言語サポートの拡張です。元の英語、フランス語、イタリア語、ドイツ語、スペイン語の他に、Nova 2 Sonic はポルトガル語とヒンディー語をサポートするようになりました。 Nova 2 Sonic は、複数の言語をサポートするだけでなく、(同じ会話の中で言語を切り替えることができる「ポリグロット音声」を導入しています。たとえば、Tiffany の声は、1 回の対話でサポートされているすべての言語を流暢に話せるようになりました。これにより、言語が混在する文を自然に処理する高度な コード切り替え (文の中で言語を混在させることを指す言語用語) 機能が提供されます。たとえば、同じ会話ダイアログでユーザーがあるターンから次のターンに言語を切り替えたときでも、ユーザーが希望する言語で応答できます。 開発者にとっては、言語ごとに個別の音声モデルを用意しなくても、世界中の視聴者にサービスを提供するアプリケーションを構築できるということです。カスタマーサポートアプリケーションは、英語で始まり、会話の途中でスペイン語に切り替わる会話を処理し、全体を通して同じフローと音声特性を維持できます。 自然なターンテイキング 音声アクティビティ検出感度を設定できるようになり、ターンテイキング機能が強化されました。開発者は、ユースケースに応じて、これを高、中、低に設定できます。感度を高くすると応答時間が短縮され、感度が低いとユーザーが考えをまとめて話し終えるまでの時間が長くなります。これは、教育用途や、コミュニケーションの好みが異なるユーザーに会話型 AI を提供する場合などに便利です。 シームレスなクロスモーダルインタラクション クロスモーダルサポートにより、ユーザーは同じセッション内でテキスト入力と音声入力を切り替えることができます。これは、ユーザーがいくつかの要求を話し、他の要求を入力したい場合に役立ちます。たとえば、簡単な質問をして、複雑な住所や技術仕様を入力する場合などです。 この実装では、モダリティに関係なくコンテキストが維持されるため、ユーザーは質問を入力して会話を始め、音声応答を受け取り、現在のスレッドを失うことなく音声入力を続けることができます。これにより、ユーザーが実際に望んでいるコミュニケーション方法に合わせて、より流動的で柔軟なインタラクションが可能になります。 クロスモーダル機能を使用して、ダイアログの最初にパーソナライズされたウェルカムメッセージを発話させる (最初に話させる) ためにテキストでモデルに指示したり、キーパッドトーンを表すテキストメタデータを使用してインタラクティブ音声応答 (IVR) アプリケーションを操作したりできるようになりました。たとえば、ユーザーに代わって予約をしたり、ボイスメールを残したりするために、Nova 2 Sonic でアウトバウンドコールを行う場合です。 高度なマルチエージェント機能 Nova 2 Sonic では、音声ベースの会話型 AI が複雑な複数ステップのタスクを処理する方法を改善する非同期ツール呼び出しが導入されました。モデルが外部のツールやサービスを呼び出す必要がある場合、ツールがバックグラウンドで実行されている間、モデルは一時停止せず、新しいユーザー入力に応答し続けます。 実際の動作例としては、ユーザーが「天気はどうですか?」と尋ね、その直後に「タスクリストの次は何?」と質問するといったケースが考えられます。 Nova 2 Sonic はこれらすべてのリクエストを処理し、質問にすぐに回答し、それぞれのツールから結果が返ってき次第、天気とタスクの情報を提供します。 私たちが会話の中で複数のトピックを同時に並行して処理するのと同じように、この機能は、対話の流れと即応性を維持しながら、複数の無関係なタスクを管理できる高度なインタラクションを実現します。 テレフォニーとプラットフォーム統合の強化 多くの会話型AIアプリケーションがさまざまな通信チャネルで動作する必要があることを認識したNova 2 Sonicは、 Amazon Connect 、 Vonage 、 Twilio 、 Audiocodes などの主要なテレフォニープロバイダーや、 LiveKit や Pipecat などのメディアプラットフォームと直接統合できるようになりました。 これらの統合は、音声コーデックの最適化、セッションライフサイクル管理、双方向入出力イベント処理、電話システムの音響上の課題など、電話ベースのやりとりに伴う複雑な技術的要件に対応します。開発者にとっては、Nova 2 Sonic 搭載アプリケーションを既存のコールセンターインフラストラクチャに直接デプロイしたり、電話ベースの新しいサービスを構築したりしても、根本的なテレフォニーの複雑さに対応する必要がなくなります。 Nova 2 Sonic の使用開始 Nova 2 Sonic は、モデルID amazon.nova-2-sonic-v 1:0 を使用して Amazon Bedrock から入手できます。アプリケーションですでに Nova Sonic を使用している場合、新しいバージョンへの更新は簡単です。既存のコードでモデル ID を更新するだけで、追加の設定を必要としない拡張機能をアプリケーションにすぐに活用できます。 このモデルはオリジナルの Nova Sonic と同じ双方向ストリーミング API を使用しているため、既存の統合パターンとイベント処理コードは引き続き機能します。クロスモーダル入力や設定可能なターンテイキングなどの新機能は、段階的に導入できるパラメーターやイベントを追加することで利用できます。 複数のプログラミング言語のコード例を使い始めるには、 Amazon Nova Sonic 音声変換モデルのサンプル を参照してください。 知っておくべきこと Amazon Nova 2 Sonic は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、および欧州 (ストックホルム) の AWS リージョン でご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 Nova 2 Sonic は、オリジナルの Nova Sonic と同様、業界トップクラスの価格パフォーマンスと低レイテンシーを維持しています。料金についての詳細は、Amazon Bedrock の 料金のページ でご確認いただけます。 このモデルは、転送時と保管時の暗号化、 VPC エンドポイント 、詳細なアクセス制御のための AWS Identity and Access Management (IAM) との統合など、他の Amazon Bedrock モデルと同じ堅牢なセキュリティおよびコンプライアンス機能をサポートしています。 Nova 2 Sonic には、 責任ある AI の使用を促進するための安全コントロールが組み込まれており、幅広いアプリケーションで適切な出力を維持するのに役立つコンテンツモデレーションも備わっています。 Amazon Nova 2 Sonic の詳細を知り、構築を開始するには、 「Amazon Nova ユーザーガイド」の 「Nova Sonic」セクション で詳細な実装ガイダンスを確認してください。 – Danilo 原文は こちら です。

2025 年 12 月 2 日、第 5 世代 AMD EPYC プロセッサを搭載した、メモリを最適化した新しい高頻度の Amazon Elastic Compute Cloud (Amazon EC2) x8Aedz インスタンスが利用可能になったことを発表しました。これらのインスタンスは、クラウドで最も高い 5GHz の CPU 周波数を提供します。前世代の X2IEZN インスタンスと比較して、最大 2 倍のコンピューティングパフォーマンスと 31% のコストパフォーマンスを実現します。 X8Aedz インスタンスは、物理レイアウトや物理検証ジョブなどの Electronic Design Automation (EDA) ワークロード、および高いシングルスレッドプロセッサパフォーマンスと大きなメモリフットプリントの恩恵を受けるリレーショナルデータベースに最適です。5 GHzプロセッサとローカル NVMe ストレージの組み合わせにより、フロアプランニング、ロジック配置、クロックツリー合成 (CTS)、ルーティング、パワー/シグナルインテグリティ解析など、メモリを大量に消費するバックエンド EDA ワークロードの処理を高速化できます。メモリと vCPU の比率が 32:1 と高いため、これらのインスタンスは vCPU ベースのライセンスモデルを使用するアプリケーションに特に効果的です。 インスタンスタイプの名前について説明します。サフィックス「a」は AMD プロセッサ、「e」はメモリ最適化インスタンスファミリーの拡張メモリ、「d」はホストサーバーに物理的に接続されたローカル NVMe ベースの SSD、「z」は高周波プロセッサを示します。 x8Aedz インスタンス X8aedz インスタンスは、2〜96 個の vCPU、64〜3,072 GiB のメモリ構成を備えた 8 つのサイズ (2 つのベアメタルサイズを含む) で提供されています。X8Aedz インスタンスは、 Elastic Fabric Adapter (EFA) のサポートにより最大 75 Gbps のネットワーク帯域幅、 Amazon Elastic Block Store (Amazon EBS) への最大 60 Gbps のスループット、および最大 8 TB のローカル NVMe SSD ストレージを備えています。 X8aedz インスタンスの仕様は次のとおりです。 インスタンス名 vCPU メモリ (GiB) NVMe SSD ストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) x8aedz.large 2 64 158 最大 18.75 最大 15 x8aedz.xlarge 4 128 316 最大 18.75 最大 15 x8aedz.3xlarge 12 384 950 最大 18.75 最大 15 x8aedz.6xlarge 24 768 1,900 18.75 15 x8aedz.12xlarge 48 1,536 3,800 37.5 30 x8aedz.24xlarge 96 3,072 7,600 75 60 x8aedz.metal-12xl 48 1,536 3,800 37.5 30 x8aedz.metal-24xl 96 3,072 7,600 75 60 60 Gbps の Amazon EBS 帯域幅と最大 8 TB のローカル NVMe SSD ストレージにより、データベース応答時間の短縮と EDA 運用のレイテンシーの短縮を実現でき、最終的にはチップ設計の市場投入までの時間を短縮できます。これらのインスタンスは、ネットワークと EBS 帯域幅の間で柔軟にリソースを割り当てることができるインスタンス帯域幅設定機能もサポートしています。ネットワークまたは EBS の帯域幅を 25% スケールして、データベース (読み取りと書き込み) のパフォーマンス、クエリ処理、およびログ記録速度を向上させることができます。 X8Aedz インスタンスは第 6 世代の AWS Nitro Card を使用しており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードし、ワークロードのパフォーマンスとセキュリティを強化します。 今すぐご利用いただけます Amazon EC2 X8Aedz インスタンスは現在、米国西部 (オレゴン) とアジアパシフィック (東京) の AWS リージョン で利用可能です。その他のリージョンも間もなく追加される予定です。リージョンの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [AWS CloudFormation] リソースタブでインスタンスタイプを検索してください。 これらのインスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス 、 ハードウェア専有インスタンス として購入できます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で X8aedz インスタンスをぜひお試しください。詳細については、 Amazon EC2 X8aedz インスタンスページ をご覧ください。フィードバックは、 AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Channy 原文は こちら です。

2025 年 12 月 2 日、開発ライフサイクル全体を通じてアプリケーションを積極的に保護するフロンティアエージェントである AWS Security Agent のプレビュー版を発表しました。組織の要件に合わせた自動アプリケーションセキュリティレビューを実施し、状況に応じた侵入テストをオンデマンドで提供します。設計からデプロイまでアプリケーションのセキュリティを継続的に検証することで、開発の早い段階で脆弱性を防ぐのに役立ちます。 静的アプリケーションセキュリティテスト (SAST) ツールはランタイムコンテキストなしでコードを検査し、動的アプリケーションセキュリティテスト (DAST) ツールはアプリケーションレベルのコンテキストなしで実行中のアプリケーションを評価します。どちらのタイプのツールも、アプリケーションのコンテキストを理解しないため、一次元的なものです。彼らは、アプリケーションがどのように設計されているか、どのようなセキュリティ脅威に直面しているか、どこでどのように実行されているかを理解していません。これにより、セキュリティチームはすべてを手作業で確認せざるを得なくなり、遅延が発生します。侵入テストはさらに時間がかかります。外部ベンダーまたは社内のセキュリティチームが時間を見つけるまで数週間待つしかありません。すべてのアプリケーションに手動のセキュリティレビューと侵入テストが必要な場合、バックログは急速に増えます。アプリケーションは、セキュリティ検証のために数週間または数か月待ってから起動します。これにより、ソフトウェアリリースの頻度とセキュリティ評価の頻度の間にギャップが生じます。セキュリティはアプリケーションのポートフォリオ全体に適用されないため、顧客は危険にさらされ、期限を守るために脆弱なコードを故意にリリースすることになります。60% 以上の組織が毎週またはそれ以上の頻度でウェブアプリケーションを更新し、75％ 近くがウェブアプリケーションを毎月またはそれ以下の頻度でテストしています。 Checkmarx の 2025 年のレポート によると、組織の 81% が、納期を守るために脆弱なコードを故意に導入していることがわかりました。 AWS Security Agent はコンテキストを認識し、アプリケーション全体を理解します。アプリケーションの設計、コード、特定のセキュリティ要件を理解します。セキュリティ違反を自動的に継続的にスキャンし、スケジュールなしで即座にオンデマンドで侵入テストを実行します。侵入テストエージェントは、セキュリティ要件、設計文書、およびソースコードから学習したコンテキストに基づいてカスタマイズされた攻撃計画を作成し、エンドポイント、ステータスコード、エラーコード、認証情報など、検出した内容に基づいて実行時に動的に適応します。これにより、より深刻で高度な脆弱性を本番稼働前に明らかにし、遅延や不測の事態を招くことなく、起動前にアプリケーションの安全を確保できます。 「SmugMug は、当社の自動セキュリティポートフォリオに AWS Security Agent を追加できることを嬉しく思います。AWS Security Agent は、手作業によるテストコストの数分の 1 で、数日ではなく数時間で完了する侵入テスト評価を可能にすることで、セキュリティ ROI を変えます。サービスをより頻繁に評価できるようになったため、ソフトウェア開発ライフサイクルの早い段階で問題を特定して対処する時間が大幅に短縮されました」と Erik Giberti, Sr. 氏 (SmugMug のプロダクトエンジニアリング担当ディレクター) は述べています。 AWS Security Agent の使用開始 AWS Security Agent は、設計セキュリティレビュー、コードセキュリティレビュー、およびオンデマンド侵入テスト機能を提供します。設計とコードレビューでは、定義した組織のセキュリティ要件をチェックし、侵入テストではソースコードと仕様からアプリケーションのコンテキストを学習して脆弱性を特定します。開始するには、 AWS Security Agent コンソール に移動します。コンソールのランディングページには、AWS Security Agent が開発ライフサイクル全体で継続的にセキュリティ評価を行う方法の概要が記載されています。 ランディングページの右側にある [AWS Security Agent の開始] パネルでは、初期設定を順を追って進めることができます。 Set up AWS Security Agent を選択して最初のエージェントスペースを作成し、アプリケーションのセキュリティレビューを開始します。 さまざまなセキュリティ評価でどのエージェントとやり取りしているのかを識別できるように、 エージェントスペース名 を指定します。エージェントスペースは、保護したい個別のアプリケーションまたはプロジェクトを表す組織のコンテナです。各エージェントスペースには、独自のテスト範囲、セキュリティ設定、および専用のウェブアプリケーションドメインがあります。明確な境界線と組織的なセキュリティ評価を維持するために、アプリケーションまたはプロジェクトごとに 1 つのエージェントスペースを作成することをお勧めします。オプションで 説明 を追加して、エージェントスペースの目的に関するコンテキストを他の管理者に提供できます。 AWS マネジメントコンソールで最初のエージェントスペースを作成すると、AWS はセキュリティエージェントウェブアプリケーションを作成します。セキュリティエージェントウェブアプリケーションでは、管理者がコンソールで設定した範囲内でユーザーが設計レビューを行い、侵入テストを実行します。ユーザーは、設計レビューや侵入テストを実施する際に、どのエージェントスペースで作業するかを選択します。 セットアッププロセス中、AWS Security Agent にはセキュリティエージェントウェブアプリケーションへのユーザーアクセスを管理するための 2 つのオプションが用意されています。1 つは、 AWS IAM アイデンティティセンター と統合することでチーム全体の SSO アクセスを可能にする IAM アイデンティティセンターによるシングルサインオン (SSO) 、もう 1 つは IAM ユーザー (この AWS アカウントの AWS Identity and Access Management (IAM) ユーザーのみがコンソールからセキュリティエージェントウェブアプリケーションに直接アクセスできるようにするもので、クイックセットアップに最適です。SSO 設定なしでアクセスします。SSO オプションを選択すると、AWS Security Agent は IAM アイデンティティセンターインスタンスを作成して、セキュリティエージェントウェブアプリケーションを通じて設計レビュー、コードレビュー、および侵入テスト機能にアクセスする AppSec チームメンバーに一元的な認証とユーザー管理を提供します。 権限設定セクションは、AWS Security Agent が他の AWS サービス、API、およびアカウントにアクセスする方法を制御するのに役立ちます。AWS Security Agent がリソースへのアクセスに使用するデフォルトの IAM ロールを作成するか、適切な権限を持つ既存のロールを選択できます。 初期設定が完了したら、 [AWS Security Agentのセットアップ] を選択してエージェントを作成します。 エージェントスペースを作成すると、エージェント設定ページに、設計レビュー、コードレビュー、侵入テストの 3 つの機能カードが表示されます。侵入テストの運用には必須ではありませんが、設計レビューまたはコードレビュー機能を使用する予定の場合は、それらの評価の指針となるセキュリティ要件を設定できます。AWS Security Agent には AWS 管理要件が含まれており、オプションで組織に合わせたカスタム要件を定義できます。また、どのチームメンバーがエージェントにアクセスできるかを管理することもできます。 セキュリティ要件 AWS Security Agent は、アプリケーションがチームのポリシーと標準に準拠するように、ユーザーが定義した組織のセキュリティ要件を適用します。セキュリティ要件は、設計段階とコードレビュー段階の両方でアプリケーションが従わなければならない制御とポリシーを指定します。 セキュリティ要件を管理するには、ナビゲーションペインの [セキュリティ要件] に移動します。これらの要件はすべてのエージェントスペースで共有されており、設計レビューとコードレビューの両方に適用されます。 マネージドセキュリティ要件 は業界標準とベストプラクティスに基づいています。これらの要件はすぐに使用でき、AWS によって管理されており、設定しなくてもすぐに有効化できます。 カスタムセキュリティ要件を作成するときは、ポリシーを定義するコントロール名と説明を指定します。たとえば、 Network Segmentation Strategy Defined という要件を作成し、データの機密性に基づいてワークロードコンポーネントを論理層に分離する明確なネットワークセグメンテーションを設計で定義するなどの使い方があります。または、 Short Session Timeouts for Privileged and PII Access を定義し、管理アクセスおよび個人を特定できる情報 (PII) へのアクセスに特定のタイムアウト時間を義務付けることもできます。もう 1 つの例として、 Customer-Managed Encryption Keys Required があります。この場合、保管中の機密データを暗号化するために、AWS マネージドキーではなく、お客様が管理する AWS Key Management Service (AWS KMS) キーを指定するように設計します。AWS Security Agent は、これらの有効な要件に照らして設計とコードを評価し、ポリシー違反を特定します。 設計セキュリティレビュー 設計レビュー機能では、コードが記述される前にアーキテクチャ文書と製品仕様を分析してセキュリティリスクを特定します。AppSec チームは、AWS Security Agent コンソールから設計文書をアップロードするか、S3 やその他の接続サービスから設計文書を取り込みます。AWS Security Agent は、組織のセキュリティ要件へのコンプライアンスを評価し、是正ガイダンスを提供します。 設計レビューを行う前に、AWS Security Agent がチェックするセキュリティ要件を設定していることを確認してください。「 セキュリティ要件 」セクションで説明されているように、AWS マネージドセキュリティ要件から始めることも、組織に合わせたカスタム要件を定義することもできます。 設計レビュー を開始するには、 [ウェブアプリアクセス] で [管理者アクセス] を選択してウェブアプリインターフェイスにアクセスします。ログインしたら、 [設計レビューを作成] を選択します。たとえば、アプリケーションを拡張する新機能の設計を評価する場合などに、評価を識別するための 設計レビュー名 を入力し、最大 5 つの設計ファイルをアップロードします。 [設計レビューを開始] を選択して、有効化されているセキュリティ要件に対する評価を開始します。 設計レビューが完了すると、設計レビューの詳細ページの [詳細] セクションにレビューステータス、完了日、レビューされたファイルが表示されます。 [検出結果の概要] には、次の 4 つのコンプライアンスステータスカテゴリーにわたる検出結果の数が表示されます。 [非準拠] — 設計がセキュリティ要件に違反しているか、対応が不十分です。 [データ不足] — アップロードされたファイルには、コンプライアンスを判断するための十分な情報が含まれていません。 [準拠] — デザインは、アップロードされたドキュメントに基づくセキュリティ要件を満たしています。 [該当なし] — セキュリティ要件の関連性基準から、このシステム設計には適用されないことが示されています。 [検出結果の概要] セクションは、注意が必要なセキュリティ要件をすばやく評価するのに役立ちます。非準拠の検出結果では設計ドキュメントを更新する必要がありますが、データが不十分な場合はドキュメントにギャップがあることを示しているため、セキュリティチームはアプリケーションチームと協力して、AWS Security Agent が評価を完了する前にさらに明確にする必要があります。 [レビューされたファイル] セクションには、アップロードされたすべてのドキュメントが表示され、元のファイルを検索してダウンロードするオプションも表示されます。 [レビューの検出結果] セクションには、レビュー中に評価された各セキュリティ要件とそのコンプライアンス状況が一覧表示されます。この例では、検出結果には、 Network Segmentation Strategy Defined 、 Customer-Managed Encryption Keys Required 、 Short Session Timeouts for Privileged and PII Access が含まれます。これらは、 [セキュリティ要件] セクションで前述したカスタムセキュリティ要件です。特定のセキュリティ要件を検索したり、コンプライアンスステータスで検出結果をフィルタリングしたりして、アクションが必要な項目に焦点を当てることができます。 特定の検出結果を選択すると、AWS Security Agent はコンプライアンス状況を説明する詳細な理由を表示し、推奨される是正手順を提示します。このコンテキスト認識型分析は、一般的なセキュリティガイダンスではなく、設計固有のセキュリティ上の懸念事項を理解するのに役立ちます。非準拠の検出結果が見つかった設計については、セキュリティ要件に対応するように文書を更新し、新しい設計レビューを作成して改善点を検証できます。また、 [この設計レビューを複製] を選択して現在の構成に基づいて新しい評価を作成することも、チームと共有するために [レポートをダウンロード] を選択してすべての検出結果をエクスポートすることもできます。 アプリケーション設計が組織のセキュリティ要件を満たしていることを確認したら、次のステップは、開発者がコードを書くのと同じ要件を適用することです。 コードセキュリティレビュー コードレビュー機能は、GitHub のプルリクエストを分析して、セキュリティの脆弱性と組織のポリシー違反を特定します。AWS Security Agent は、SQL インジェクション、クロスサイトスクリプティング、不適切な入力検証など、 OWASP Top Ten の一般的な脆弱性を検出します。また、設計レビューで使用されるのと同じ組織のセキュリティ要件を適用し、一般的な脆弱性を超えてチームのポリシーにコードコンプライアンスを実装します。 アプリケーションが新しいコードをチェックインすると、AWS Security Agent は一般的な脆弱性を超える組織のセキュリティ要件への準拠を検証します。たとえば、組織が監査ログを 90 日間だけ保持することを義務付けている場合、AWS Security Agent は、コードが 365 日の保持期間を設定しているタイミングを特定し、特定の違反を含むプルリクエストにコメントします。これにより、コードが技術的に機能的で安全であるために従来のセキュリティツールが見逃していたポリシー違反を検出できます。 コードレビューを有効にするには、エージェント設定ページで [コードレビューを有効にする] を選択し、GitHub リポジトリに接続します。特定のリポジトリのコードレビューを有効にしたり、代わりに侵入テストのコンテキストに使用したい場合は、コードレビューを有効にせずにリポジトリを接続したりできます。 詳細なセットアップ手順については、 AWS Security Agentのドキュメント を参照してください。 オンデマンド侵入テスト オンデマンドの侵入テスト機能は、包括的なセキュリティテストを実行して、多段階の攻撃シナリオを通じて脆弱性を発見および検証します。AWS Security Agent は、偵察とエンドポイントの列挙を通じてアプリケーションのアタックサーフェスを体系的に検出し、その後、専用のエージェントをデプロイして、認証、承認、インジェクション攻撃を含む 13 のリスクカテゴリーにわたるセキュリティテストを実行します。ソースコード、API 仕様、ビジネスドキュメントが提供されると、AWS Security Agent はアプリケーションのアーキテクチャとビジネスルールに関するより深いコンテキストを構築し、より的を絞ったテストケースを生成します。アプリケーションの応答に基づいてテストを調整し、評価中に新しい情報を発見した時点で攻撃戦略を調整します。 AWS Security Agent は、ウェブアプリケーションと API を OWASP Top Ten の脆弱性タイプに対してテストを実施し、静的分析ツールが見逃す悪用可能な問題を特定します。たとえば、動的アプリケーションセキュリティテスト (DAST) ツールはサーバー側テンプレートインジェクション (SSTI) のペイロードを直接探しますが、AWS Security Agent は SSTI 攻撃とエラー強制およびデバッグ出力分析を組み合わせて、より複雑なエクスプロイトを実行できます。AppSec チームは、人間の侵入テスト実行者に説明するのと同じように、テスト範囲 (ターゲット URL、認証の詳細、脅威モデル、文書) を定義します。この理解に基づいて、AWS Security Agent はアプリケーションコンテキストを開発し、高度な攻撃チェーンを自律的に実行して脆弱性を発見および検証します。これにより、侵入テストが定期的なボトルネックから継続的なセキュリティプラクティスに変わり、リスクにさらされるリスクが軽減されます。 侵入テストを有効にするには、エージェント設定ページで [侵入テストを有効にする] を選択します。ターゲットドメイン、プライベートエンドポイントの VPC 設定、認証情報、および GitHub リポジトリや S3 バケットなどの追加のコンテキストソースを設定できます。AWS Security Agent が侵入テストを実行する前に、各ドメインの所有権を確認する必要があります。 機能を有効にしたら、AWS Security Agent ウェブアプリケーションを使用して侵入テストを作成して実行します。 詳細なセットアップと設定の手順については、 AWS Security Agentのドキュメント を参照してください。 侵入テストを作成して実行すると、詳細ページにテストの実行と結果の概要が表示されます。このページから、新しいテストを実行したり、構成を変更したりできます。このページには、開始時間、ステータス、期間、検出された脆弱性の概要など、最新の実行に関する情報が重大度別に表示されます。また、以前のすべてのテスト実行の履歴とその検出結果の概要を表示することもできます。 各実行について、詳細ページには 3 つのタブが表示されます。 [侵入テスト実行の概要] タブには、期間や全体的なステータスなど、実行に関する大まかな情報が表示されます。 [侵入テストログ] タブには、侵入テスト中に実行されたすべてのタスクが一覧表示され、実行されたセキュリティテストアクション、アプリケーション応答、各テストの背後にある理由など、AWS Security Agent がどのように脆弱性を検出したかがわかります。 [検出結果] タブには、検出されたすべての脆弱性が、説明、攻撃の理由、再現手順、影響、修復ガイダンスなどの詳細とともに表示されます。 プレビューに参加 AWS Security Agent の使用を開始するには、AWS Security Agent コンソールにアクセスして最初のエージェントを作成し、開発ライフサイクル全体にわたる設計レビュー、コードレビュー、侵入テストの自動化を開始してください。プレビュー期間中は、AWS Security Agent は無料です。 AWS Security Agent は米国東部 (バージニア北部) リージョンでご利用いただけます。 詳細については、AWS Security Agent の 製品ページ と 技術文書 をご覧ください。 – Esra 原文は こちら です。

本ブログは、株式会社エナリス 星野 友宏 氏、KDDI アジャイル開発センター株式会社 御田 稔 氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 安藤 が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの安藤です。 電力分野、特に再生可能エネルギーの普及が進む中で、正確な発電予測は電力系統の安定運用に欠かせません。今回は、 株式会社エナリス （以下、エナリス）と KDDI アジャイル開発センター株式会社 （以下、KAG）が共同で取り組む、太陽光発電データの異常検知システムについてご紹介します。このシステムは生成 AI の活用と人間の知見を組み合わせた HCAI（Human-Centered AI）アプローチを採用しており、 Amazon Bedrock を中心としたアーキテクチャで構築されています。HCAI は、人間の能力を置き換えるのではなく増強・拡張する AI システムの構築を目指す新しい分野で、透明性、公平性、プライバシーを重視し、特に重要な意思決定では人間が主導権を保持することを重視しています。今回のシステムでは、AI の出力結果を別の AI が評価し、最終的に人間がフィードバックすることで AI の精度を継続的に向上させるアプローチを実現しています。 導入背景 電力は貯蔵が困難なエネルギーであり、供給と需要を常にバランスさせる必要があります。特に太陽光発電などの再生可能エネルギーは気象状態に依存して変動するため、正確な発電量予測は電力系統の安定運用において重要な要素です。エナリスは電力需給管理業務を創業事業とし、早くから AI を活用した発電量予測に取り組んできました。同社では Amazon SageMaker AI で構築した独自の AI モデルを用いて、時系列予測による太陽光発電量予測を行っています。 しかし、天候急変、災害、設備故障など予測困難な要素により、実績値と予測値に大きな乖離が生じるケースが発生していました。このような異常値が検出された場合、データ欠損の確認や原因分析を人手でチェックする必要があり、相応の工数を要することや、属人化が課題となっていました。 これらの課題解決に向けて生成 AI の活用を検討する中で、「ハルシネーション」や判断根拠の不透明性といった課題が浮上しました。社会インフラを支えるエネルギー分野では AI の出力結果に対する信頼性と説明可能性が重要であり、慎重なアプローチが求められていました。 ソリューション：HCAI による異常検知システム エナリスと KAG は、AI の能力を活用しながらも人間の判断を重視する HCAI（Human-Centered AI）アプローチに着目し、AI の出力結果を別の AI が分析・評価し、それをさらに人間が評価して改善指示するサイクルを回す異常検知システムの構築に着手しました。このアプローチにより、AI の精度を継続的に向上させながら、安心して活用できるシステムの実現を目指しています。 システムアーキテクチャの変遷と特徴要素 【ステップ 1：Amazon Bedrock API（Claude）ベースのシンプルシステム】 最初に構築したシステムは、Amazon Bedrock の Claude モデルを使用して実績/予測データを分析し、異常の有無を判定してテキストとして画面に出力する Web アプリケーションでした。システム構成は、フロントエンドに Vue.js on AWS Amplify（Gen 2） 、バックエンドに AWS Lambda を使用しています。 このステップでは、データ処理の基盤として以下の Lambda を構築しています： 乖離検知 Lambda: 実績発電データと予測発電データを比較して乖離を検知 異常検知 Lambda: 予測発電データとマスターデータを使用して異常を検知 これらの Lambda で検知された結果は Amazon Redshift Serverless に格納されます。Amazon Bedrock は、このデータを元に異常の原因分析や対応策の提案を行います。データ取得には Amazon Bedrock Knowledge Base の Text-to-SQL 機能 を使用し、Amazon Redshift Serverless に格納された検知結果から必要なレコードのみを自然言語から SQL で取得しています。一般的なベクトル検索の RAG（Retrieval Augmented Generation）で処理するとデータが断片化されてしまうため、構造化データは SQL で直接取得する方針を採用しました。 アーキテクチャ図_ステップ1 このような構成で開始しましたが、大量の元データを効率よく処理する方法や、Web 情報など外部の情報をいかに取り込むか、また複数のエージェントを協調させる方法といった課題がありました。 【ステップ 2：Amazon Bedrock Agents マルチエージェントコラボレーション】 ステップ 1 の課題を解決するため、Amazon Bedrock Agents を用いて大幅にアーキテクチャを改良しました。Amazon Bedrock Agents は、自律的な AI エージェントを構築・設定できるサービスです。今回は Amazon Bedrock Agents のマルチエージェントコラボレーションを活用して、複数のエージェントが協調して動作する構成を実装しました。 ステップ 1 で構築した乖離検知・異常検知 Lambda から Amazon Redshift Serverless へのデータ格納までの基盤はそのまま活用し、このステップではマルチエージェントシステムを構築しました。 各エージェントの役割は以下のとおりです。 監督者エージェント：スーパーバイザーエージェントとして機能し、各サブエージェントの結果を取りまとめます。またツールとしては当該地点の天候情報などを取得する Lambda function を構築し、Amazon Bedrock Agents のアクショングループに紐付けました。 検知結果取得エージェント：ステップ 1 で実装した Amazon Bedrock Knowledge Base の Text-to-SQL 機能を活用して、Amazon Redshift Serverless に格納された検知結果から必要なレコードのみを自然言語から SQL で取得します。 過去ナレッジ検索エージェント：こちらは Amazon S3 と Amazon OpenSearch Serverless を組み合わせた Knowledge Base のベクトル検索で社内のナレッジドキュメントを検索し、どういった場合にどのような有人対応が必要となるかのアドバイスをユーザーに提示します。過去の対応策が記載されたファイルを Amazon S3 に格納し、Amazon OpenSearch Serverless をベクターストアとして活用しています。 システムの実際の動作フローは以下のとおりです。ユーザーが入力した日付の分析結果ファイルを検索し、ファイルが存在しない場合は監督者エージェントを起動して分析用コンテキストを収集します。この際、外部の気象情報を取得して天候特徴を抽出し、これらのコンテキストを利用して LLM が分析結果ファイルを出力します。一方、分析結果ファイルが既に存在する場合は、そのファイル内容を取得してフロントエンドに連携します。 また、LLM-as-a-Judge 機能を実装し、分析結果の確からしさを LLM 自身に評価させてランク付けして画面に表示することにより、ユーザーがどこを疑って見るべきかの示唆を与えます。LLM-as-a-Judge とは、LLM 自身が生成した結果の品質や信頼性を評価する手法で、今回は RAG システムの品質を定量的に評価するためのオープンソースフレームワークである RAGAS を活用しています。 アーキテクチャ図_ステップ2 【ステップ 3（現在）：AWS Step Functions ワークフロー】 ステップ 2 の運用を進める中で、「AI が過度に汎化して評価の精度が低下する」という課題が判明しました。そこで RAGAS の評価精度を向上させるため、評価対象の処理区間や中間データを扱いやすいよう、Amazon Bedrock Agents を使用せずに AWS Step Functions で AWS Lambda を直接制御するカスタムワークフローに変更しました。AWS Step Functions は、分散アプリケーションのワークフローを視覚的に構築・管理するサービスです。 ステップ 2 で実現した各種情報収集機能（天候情報取得、検知結果取得、過去ナレッジ検索）を基盤として活用し、AWS Step Functions で AWS Lambda を直接制御するカスタムワークフローで以下の情報収集・評価 Lambda を順次実行します。 異常乖離検知結果取得 Lambda: Amazon Bedrock Knowledge Base の Text-to-SQL 機能で Amazon Redshift Serverless に格納された検知結果を取得し、そのデータを元に Amazon Bedrock が生成した分析結果を RAGAS で評価して Amazon DynamoDB に保存します。 当時の天候情報取得 Lambda: Tavily Search API で天候情報を取得し、Amazon S3 のマスターデータからデバイスの位置情報を取得し、これらをコンテキストとして Amazon Bedrock で異常値の発生原因を分析し、RAGAS で評価して Amazon DynamoDB に保存します。 対応策取得 Lambda: Amazon S3 と Amazon OpenSearch Serverless を組み合わせたベクター検索で過去のナレッジを取得し、RAGAS で評価して Amazon DynamoDB に保存します。 分析レポート作成: 上記 3 つの Lambda から収集した情報を統合し、AWS Lambda と Amazon Bedrock で総合的な分析レポートを作成し、Amazon S3 に格納します。 最終的に、Amazon S3 に保存された分析結果と Amazon DynamoDB に保存された RAGAS 評価結果を組み合わせてフロントエンドに出力します。AWS Step Functions への変更により、各処理段階をより細かく制御できるようになり、中間データの可視化やデバッグ性も向上しました。 また、HCAI アプローチの核心である人間のフィードバックループも実装しています。ユーザーは出力された分析情報を確認し、対応を決定して、その対応結果を入力します。この対応結果は過去の対応策ファイルとして Amazon S3 に格納され、上述した対応策取得 Lambda で活用される継続的な学習サイクルを形成しています。 アーキテクチャ図_ステップ3 システムアーキテクチャの継続的な改善として、ベクターストアの選択についても検討を進めています。現在はAmazon OpenSearch Serverless を使用していますが、よりコスト最適化できる選択肢として 2025 年 12 月に一般提供が開始された Amazon S3 Vectors を検討しています。Amazon S3 Vectors は S3 バケット内でベクターデータを直接格納・検索できる新機能で、従来のベクターデータベースと比較してコスト効率に優れており、大規模な過去ナレッジデータの管理において運用コストの削減が期待できます。 システムの実行結果 以下は、実際にシステムを動作させた際の画面例です。異常検知の結果とLLM-as-a-Judge 機能による評価結果が統合されたダッシュボードで確認できます。左側には検知された異常データの詳細（デバイス ID、時刻、実績値、予測値、誤差率など）が表示され、右側には異常値分析と乖離値分析それぞれについて A〜C 評価とスコアが表示されます。 また、RAGAS 評価の詳細画面では、忠実度、コンテキスト精度、回答関連性などの各評価指標について、重要度とスコアが可視化されており、ユーザーは分析結果のどの部分を重点的に確認すべきかを把握できます。RAGAS 評価では、各 Lambda がそれぞれ異なる質問（異常値抽出、対応策検討、原因分析）を LLM に 2 回投げ、1 回目の回答を Ground Truth（想定回答）とし、2 回目の回答と比較することで評価を実施しています。通常、RAGAS 評価では人間が作成した正解データを Ground Truth として使用しますが、太陽光発電異常分析のような専門性の高い領域では、事前に決まりきった正解を用意することが困難なため、LLM 自身に Ground Truth を生成させる手法を採用しました。これにより、コンテキスト精度（適切な資料を取得できたか）、忠実度（取得した情報に基づいて回答しているか）、回答関連性（質問に適切に答えているか）などの指標を定量的に測定し、RAG システムの検索精度と生成品質を客観的に評価できています。なお、最終的な品質保証は人間による確認と組み合わせることで信頼性を担保しています。 システム画面 1 システム画面 2 期待される効果と今後の展望 このシステムの導入によって、以下の効果が期待できます。 人間のフィードバックを継続的に学習データに反映することで、太陽光発電量の予測精度を段階的に改善 従来の手作業による調査・分析作業を、AI が AI を評価する仕組み（LLM-as-a-Judge）の活用により迅速化・効率化し、異常原因の特定時間を短縮 HCAI アプローチにより AI 出力の信頼性を可視化し、エネルギー分野での生成 AI 活用を促進 予測精度向上により電力需給のミスマッチを削減し、インバランス料金の発生を抑制 現在は PoC（概念実証）環境の構築が完了し、チューニングのフェーズに入っています。今後の本格運用を視野に入れていますが、現状では、取り込むコンテキスト量の問題や、LLM の API 利用における処理速度や回数の制約といった大量データ処理の困難さ、また、電力データ自体がリアルタイムで取得できないことによるリアルタイム処理の難しさといった技術的課題が残っています。そのため、まずはこれらの課題解決を優先し、少数のデバイスデータを選定運用することから始めます。この最小構成での運用を通じてシステムの精度向上を図り、その上で将来的な本格運用を検討していく予定です。 また、今回のフィールドは太陽光発電量予測ですが、今後はこの HCAI アプローチを、エナリスが推進する電力マネジメントサービスの品質を下支えする仕組みとして横断的に活用していきます。具体的には、創業以来の強みである需給管理業務に関連する発電量や需要量の予測精度向上をサポートするとともに、企業の CO2 排出量削減や再エネ導入を多角的に支援する脱炭素ソリューションをはじめとする自社の多様なサービスへ横展開し、事業全体の高度化を図っていくことを目指しています。 まとめ エナリスと KAG による本取り組みは、エネルギー分野における生成 AI の実用化に向けた重要な一歩です。特に、AI の出力結果を別の AI が評価し、最終的に人間がフィードバックする HCAI のアプローチは、生成 AI の信頼性向上と実用化の両立を目指す取り組みといえます。 ステップ 1 のシンプルな Amazon Bedrock API ベースのシステムから、ステップ 2 のマルチエージェントシステム、そしてステップ 3 の AWS Step Functions ワークフローへと、実際の運用から得られた知見に基づいて段階的に進化させてきた過程は、多くの企業にとって参考になるでしょう。今後の展開と成果に注目していきたいと思います。 著者 星野 友宏 株式会社エナリス 事業企画本部 みらい研究所 技術開発部門 御田 稔 KDDI アジャイル開発センター株式会社 テックエバンジェリスト 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト