本稿は、日本取引所グループの 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 アジャイル開発センター株式会社 テックエバンジェリスト 安藤 麻衣 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト

データベース環境を管理するには、リソース効率とスケーラビリティのバランスが必要です。組織は、データベースライフサイクル全体にわたる柔軟なオプションを必要とし、さまざまなストレージとコンピューティングの要件を伴う開発、テスト、および本番稼働ワークロードにまたがる柔軟なオプションを必要としています。 こうしたニーズに応えるため、 Amazon Relational Database Service (Amazon RDS) の 4 つの新機能を発表します。これにより、お客様がコストを最適化できるだけでなく、 Amazon RDS for Oracle と Amazon RDS for SQL Server データベースの効率とスケーラビリティも向上させることができます。これらの機能強化には、SQL Server Developer Edition のサポートと、RDS for Oracle と RDS for SQL Server の両方でのストレージ機能の拡張が含まれます。さらに、M7i および R7i インスタンス上の RDS for SQL Server の CPU 最適化オプションを利用すると、前世代のインスタンスよりも価格が下がり、ライセンス料が別途請求されます。 では、何が新しくなったのかを調べてみましょう。 SQL Server Developer Edition のサポート SQL Server Developer Edition が RDS for SQL Server で利用できるようになりました。Enterprise Edition のすべての機能を含む SQL Server エディションが無料で提供されます。Developer Edition は非本番稼働ワークロード専用にライセンスされているため、開発環境やテスト環境で SQL Server のライセンスコストをかけずにアプリケーションを構築およびテストできます。 このリリースでは、本番稼働環境との一貫性を維持しながら、開発環境とテスト環境のコストを大幅に削減できます。開発環境ですべての Enterprise Edition 機能にアクセスできるため、アプリケーションのテストと検証が容易になります。さらに、開発プロセス全体を通じて、自動バックアップ、ソフトウェアアップデート、モニタリング、暗号化機能など、Amazon RDS の全機能を活用できます。 まず、SQL Server バイナリファイルを Amazon Simple Storage Service (Amazon S3) にアップロードし、それを使用して Developer Edition インスタンスを作成します。組み込みの SQL Server バックアップおよび復元操作を使用して、Enterprise Edition または Standard Edition インスタンスから Developer Edition インスタンスに既存のデータを移行できます。 CPU の最適化をサポートする RDS for SQL Server 上の M7i/R7i インスタンス Amazon RDS for SQL Server で M7i インスタンスと R7i インスタンスを使用できるようになり、いくつかの主なメリットが得られます。これらのインスタンスは、前世代のインスタンスに比べて大幅なコスト削減を実現します。また、ライセンス料と Amazon RDS DB インスタンスの費用は別々に請求されるため、データベースコストの透明性が高まります。 RDS for SQL Server M7i/R7i インスタンスは、前世代のインスタンスと比較してコストを最大 55% 削減します。 これらのインスタンスの CPU 最適化機能を使用すると、ライセンスに含まれている RDS for SQL Server インスタンスの vCPU の数をカスタマイズできます。この機能強化は、高いメモリと 1 秒あたりの入出力オペレーション (IOPS) を必要とするものの、vCPU 数は少ないデータベースワークロードで特に役立ちます この機能は、データベース操作に大きなメリットをもたらします。アプリケーションに必要なメモリと IOPS のパフォーマンスレベルを維持しながら、vCPU ベースのライセンスコストを大幅に削減できます。この機能は、より高いメモリ対 vCPU 比率をサポートし、インスタンスのパフォーマンスを維持しながらハイパースレッディングを自動的に無効にします。最も重要なのは、特定のワークロード要件に正確に一致するように CPU 設定をファインチューニングして、最適なリソース利用を実現できることです。 まず、新しいデータベースインスタンスを作成するときに、M7i または R7i インスタンスタイプの SQL Server を選択します。 [CPU の最適化] で [仮想 CPU 数の設定] を選択し、必要な vCPU 数を設定します。 RDS for Oracle および RDS for SQL Server 用の追加ストレージボリューム Amazon RDS for Oracle と Amazon RDS for SQL Server は、最大 256 TiB のストレージサイズをサポートするようになりました。これは、ストレージボリュームを最大 3 つ追加したことで、データベースインスタンスあたりのストレージサイズが 4 倍に増加したことになります。 追加のストレージボリュームにより、データベースストレージのニーズを柔軟に管理できます。io2 ボリュームと gp3 ボリュームの両方を使用してボリュームを構成し、最適なストレージ戦略を作成できます。頻繁にアクセスするデータを高性能のプロビジョンド IOPS SSD (io2) ボリュームに保存し、履歴データを費用対効果の高い汎用 SSD (gp3) ボリュームに保存できるため、パフォーマンスとコストのバランスが取れます。月末の処理やデータのインポートなど、一時的なストレージが必要な場合は、必要に応じてストレージボリュームを追加できます。これらの操作が完了したら、ボリュームを空にしてから削除することで、不要なストレージコストを削減できます。 これらのストレージボリュームは、ダウンタイムなしで運用上の柔軟性を提供し、データベースの操作を中断することなくストレージボリュームを追加または削除できます。また、複数のボリュームを同時にスケールアップして、増大するストレージ需要に迅速に対応することもできます。マルチ AZ 配置では、高可用性を維持するために、追加のストレージボリュームはすべて自動的に複製されます。 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して、新規または既存のデータベースインスタンスにストレージボリュームを追加できます。 簡単な例を 1 つ示します。既存の RDS for Oracle データベースインスタンスにストレージボリュームを追加します。 最初に RDS コンソールに移動し、次に RDS for Oracle データベースインスタンスの詳細ページに移動します。[設定] の下を見ると、 [追加のストレージボリューム] セクションがあります。 ストレージボリュームは 3 つまで追加でき、命名規則に従ってそれぞれに名前を付ける必要があります。ストレージボリュームに同じ名前を付けることはできません。rdsdbdata2、rdsdbdata3、rdsdbdata4 のいずれかを選択する必要があります。RDS for Oracle データベースインスタンスの場合、プライマリストレージボリュームサイズが 200 GiB 以上のストレージボリュームをデータベースインスタンスに追加できます。 ボリュームを 2 つ追加するので、 [追加のストレージボリュームを追加] を選択し、必要な情報をすべて入力します。ボリューム名として rdsdbdata2 を選択し、io2 ストレージタイプで 12,000 GiB の割り当てストレージと 60,000 のプロビジョンド IOPS を提供します。2 つ目の追加ストレージボリューム rdsdbdata3 では、gp3 に 2000 GiB、プロビジョンド IOPS が 15000 になるように選択します。 確認後、Amazon RDS がリクエストを処理するのを待ってから、追加のボリュームが利用可能になります。 AWS CLI を使用して、データベースインスタンスの作成時または変更時にボリュームを追加することもできます。 知っておくべきこと これらの機能は現在、すべての商用 AWS リージョン と AWS GovCloud (米国) リージョンでご利用いただけるようになりました。これらのリージョンでは、Amazon RDS for Oracle と Amazon RDS for SQL Server が提供されています。 これらの各機能の詳細については、 Developer Edition の Amazon RDS ドキュメントで CPU の最適化 、 RDS for Oracle 用の追加ストレージボリューム 、および RDS for SQL Server 用の追加ストレージボリューム を参照してください。 RDS for SQL Server の M7i インスタンスと R7i インスタンスのバンドルされていない料金体系の詳細については、 Amazon RDS for SQL Server の料金表ページ をご覧ください。 これらの機能のいずれかを使い始めるには、 Amazon RDS コンソール にアクセスするか、 Amazon RDS ドキュメント にアクセスして詳細を確認してください。 原文は こちら です。

2025 年 12 月 2 日、 Amazon Nova 2 Lite をリリースしました。これは、日常のワークロードに対応する高速で費用対効果の高い推論モデルです。 Amazon Bedrock で利用できるこのモデルは、業界トップクラスの価格パフォーマンスを提供し、企業や開発者が高性能で信頼性が高く効率的なエージェンティック AI アプリケーションを構築するのに役立ちます。自社の領域を真に理解する AI を必要とする組織にとって、Nova 2 Liteは Nova Forge と併用 して独自のフロンティアインテリジェンスを構築するのに最適なモデルです。 Nova 2 Lite は、応答したり行動を起こしたりする前に、段階的な推論やタスクの分解など、拡張的な思考をサポートします。拡張思考 (Extended Thinking) は初期設定ではオフになっていますが、より詳細な分析が必要な場合は、これをオンにして、「低」、「中」、「高」の 3 つの思考予算レベルから選択して、スピード、インテリジェンス、コストのトレードオフを制御できます。 Nova 2 Lite は、テキスト、画像、ビデオ、ドキュメントを入力としてサポートし、100 万トークンのコンテキストウィンドウを提供することで、推論の幅を広げ、より豊かなコンテキスト学習を可能にします。さらに、Nova 2 Lite は特定のビジネスニーズに合わせてカスタマイズできます。このモデルには、ウェブグラウンディングとコードインタープリターという 2 つの組み込みツールへのアクセスも含まれています。ウェブグラウンディングは引用を含む公開情報を取得し、コードインタープリターはモデルが同じワークフロー内でコードを実行して評価できるようにします。 Amazon Nova 2 Lite は、さまざまな評価ベンチマークで優れたパフォーマンスを示しています。このモデルは、時間的推論による指示の追従や数学、動画の理解など、複数の領域にわたるコアインテリジェンスの点で優れています。エージェント型ワークフローの場合、Nova 2 Lite はタスクの自動化と正確な UI インタラクション機能を呼び出す信頼性の高い機能を備えています。このモデルは、強力なコード生成能力と実践的なソフトウェアエンジニアリング問題解決能力も示しています。 Nova 2 Lite は貴社のニーズを満たすように構築されています Nova 2 Lite は日常の幅広い AI タスクに使用できます。価格、パフォーマンス、速度の最適な組み合わせを提供します。初期の顧客は、カスタマーサービスのチャットボット、文書処理、ビジネスプロセスの自動化に Nova 2 Lite を使用しています。 Nova 2 Lite は、さまざまなユースケースのワークロードをサポートするのに役立ちます。 ビジネスアプリケーション — ビジネスプロセスワークフロー、インテリジェントドキュメント処理 (IDP)、カスタマーサポート、ウェブ検索を自動化して、生産性と成果を向上させます ソフトウェアエンジニアリング — コードの生成、デバッグ、リファクタリング、およびシステムの移行により、開発を加速し、効率を高めます ビジネスインテリジェンスとリサーチ — 長期的な推論とウェブグラウンディングを活用して社内外の情報源を分析し、インサイトを導き出し、情報に基づいた意思決定を行います。 特定の要件については、Nova 2 Lite を Amazon Bedrock と Amazon SageMaker AI の両方でカスタマイズすることもできます。 Amazon Nova 2 Lite の使用 Amazon Bedrock コンソール では、 チャット/テキストプレイグラウンド を使用して、プロンプトを使用して新しいモデルをすばやくテストできます。モデルをアプリケーションに統合するには、Amazon Bedrock InvokeModel と Converse API を備えた任意の AWS SDK を使用できます。 AWS SDK for Python (Boto3) を使用した呼び出しのサンプルを次に示します。 import boto3 AWS_REGION="us-east-1" MODEL_ID="global.amazon.nova-2-lite-v1:0" MAX_REASONING_EFFORT="low" # low, medium, high bedrock_runtime = boto3.client("bedrock-runtime", region_name=AWS_REGION) # 複雑な問題解決のための拡張思考を有効化 response = bedrock_runtime.converse( modelId=MODEL_ID, messages=[{ "role": "user", "content": [{"text": "5 つの倉庫、12 の配送センター、200 の小売店舗からなる物流ネットワークを最適化する必要があります。目標は、配送センターから 50 マイル以上離れていない場所がないようにしながら、総輸送コストを最小限に抑えることです。どのようなアプローチを取るべきか?"}] }], additionalModelRequestFields={ "reasoningConfig": { "type": "enabled", # enabled, disabled (default) "maxReasoningEffort": MAX_REASONING_EFFORT } } ) # 応答には推論ブロックが含まれ、その後に最終回答が続きます for block in response["output"]["message"]["content"]: if "reasoningContent" in block: reasoning_text = block["reasoningContent"]["reasoningText"]["text"] print(f"Nova's thinking process:\n{reasoning_text}\n") elif "text" in block: print(f"Final recommendation:\n{block['text']}") また、これらのモデルは、Amazon Bedrock をサポートする任意のエージェンティックフレームワークで使用でき、 Amazon Bedrock AgentCore を利用してエージェントをデプロイできます。この方法では、幅広いタスクに対応するエージェントを構築できます。 Strands Agents SDK を使用したインタラクティブなマルチエージェントシステムのサンプルコードは次のとおりです。エージェントは、ファイルの読み取り/書き込みアクセスやシェルコマンドの実行など、複数のツールにアクセスできます。 from strands import Agent from strands.models import BedrockModel from strands_tools import calculator, editor, file_read, file_write, shell, http_request, graph, swarm, use_agent, think AWS_REGION="us-east-1" MODEL_ID="global.amazon.nova-2-lite-v1:0" MAX_REASONING_EFFORT="low" # low, medium, high SYSTEM_PROMPT = ( "You are a helpful assistant. " "ユーザーからの指示に従ってください。" "タスクを支援するために、専用のエージェントを動的に作成し、複雑なワークフローを調整できます。" ) bedrock_model = BedrockModel( region_name=AWS_REGION, model_id=MODEL_ID, additional_request_fields={ "reasoningConfig": { "type": "enabled", # enabled, disabled (default) "maxReasoningEffort": MAX_REASONING_EFFORT } } ) agent = Agent( model=bedrock_model, system_prompt=SYSTEM_PROMPT, tools=[calculator, editor, file_read, file_write, shell, http_request, graph, swarm, use_agent, think] ) while True: try: prompt = input("\nEnter your question (or 'quit' to exit): ").strip() if prompt.lower() in ['quit', 'exit', 'q']: break if len(prompt) > 0: agent(prompt) except KeyboardInterrupt: break except EOFError: break print("\nGoodbye!") 知っておくべきこと Amazon Nova 2 Lite は、複数のロケーションでのグローバルな クロスリージョン推論 により Amazon Bedrock で利用できるようになりました。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 Nova 2 Lite には、 責任ある AI の使用を促進するための安全コントロールが組み込まれており、幅広いアプリケーションで適切な出力を維持するのに役立つコンテンツモデレーションも備わっています。 費用については、 Amazon Bedrock の料金表 をご覧ください。詳細については、「 Amazon Nova ユーザーガイド 」をご覧ください。 今すぐ Nova 2 Lite で構築を開始しましょう。新しいモデルを試すには、 Amazon Novaインタラクティブウェブサイト にアクセスしてください。 Amazon Bedrock コンソール でモデルを試し、 AWS re:Post でフィードバックを共有 してください。 – Danilo 原文は こちら です。

2025 年 12 月 2 日、 AWS Security Hub が一般公開され、セキュリティチームが AWS 環境全体で重大なセキュリティリスクを特定して対応する方法が変わりました。これらの新機能は、 AWS re:Inforce 2025 の プレビュー で初めて発表されました。Security Hub は、お客様の重大なセキュリティ問題に優先順位を付け、セキュリティ運用を統合して、複数の AWS セキュリティサービスにわたるシグナルを相互に関連付けて強化することで、大規模な対応を支援します。Security Hub は、ほぼリアルタイムのリスク分析、トレンド、統合支援、合理化された価格設定、およびセキュリティシグナルを実用的なインサイトに変換する自動相関を提供します。 複数のセキュリティツールを導入している組織は、さまざまなコンソール間でシグナルを手動で相関させる必要があり、運用上のオーバーヘッドが発生し、検出と応答の時間が遅れる可能性があります。セキュリティチームは、脅威検出、脆弱性管理、セキュリティ体制のモニタリング、機密データの発見にさまざまなツールを使用していますが、これらのツールが生成する検出結果から価値を引き出すには、関係を理解して優先順位を決定するための多大な労力を手動で行う必要があります。 Security Hub は、クラウドセキュリティ運用を統合する組み込み統合によってこれらの課題に対処します。Security Hub は、個々のアカウントまたは AWS Organizations アカウント全体で利用でき、 Amazon GuardDuty 、 Amazon Inspector 、 AWS Secutiry Hub クラウドセキュリティ体制管理 (AWS Security Hub CSPM) 、および Amazon Macie からのシグナルを自動的に集計して相関させ、脅威、暴露、リソース、セキュリティカバレッジ別に整理します。この統一されたアプローチにより、手作業による関連付け作業が減り、重大な問題を迅速に特定し、補償範囲のギャップを理解し、重大度と影響に基づいて修正の優先順位を付けることができます。 一般提供の新着情報 プレビューの発表以降、Security Hub にはいくつかの新機能が追加されています。 歴史的傾向 Security Hub には、 概要 ダッシュボードのトレンド機能が含まれており、組織全体の検出結果やリソースに関する最大 1 年間の履歴データが表示されます。概要ダッシュボードには、運用上のニーズに基づいて追加、削除、調整できるカスタマイズ可能なウィジェットを通じて、リスク範囲、脅威、リソース、およびセキュリティカバレッジの概要が表示されます。 ダッシュボードには、前日比、前週比、前月比の比較を示す トレンド概要 ウィジェットが含まれており、セキュリティ体制が改善しているのか低下しているのかを追跡するのに役立ちます。 アクティブ脅威検出結果 、 アクティブエクスポージャー結果 、 リソーストレンド のトレンドウィジェットは、5 日間、30 日、90 日、6 か月、1 年などの選択可能な期間の平均数を視覚化します。これらの視覚化を、クリティカル、高、中、低などの重大度レベルでフィルタリングし、特定の時点にカーソルを合わせると詳細なカウントを確認できます。 概要 ダッシュボードには、現在のリスクの概要を重大度順に並べて表示するウィジェット、悪意のあるアクティビティまたは疑わしいアクティビティを示す脅威概要、タイプ別および関連する検出結果別に整理されたリソースインベントリを表示するウィジェットも含まれています。 セキュリティカバレッジ ウィジェットは、組織全体のセキュリティサービスデプロイにおけるギャップを特定するのに役立ちます。このウィジェットは、どの AWS アカウントとリージョンでセキュリティサービスが有効になっているかを追跡し、脅威、脆弱性、設定ミス、機密データを可視化できない場所を特定するのに役立ちます。このウィジェットには、Amazon Inspector による脆弱性管理、GuardDuty による脅威検出、Amazon Macie による機密データ検出、AWS Security Hub CSPM による体制管理など、さまざまなセキュリティ機能のアカウントカバレッジが表示されます。カバレッジパーセンテージは、Security Hub が有効になっている AWS アカウントとリージョン全体で、どのセキュリティチェックに合格または不合格になったかを示します。 すべてのウィジェットに適用される共有フィルターを使用してウィジェットにフィルターを適用したり、エクスポージャーデータや脅威データのフィルターを検索したり、インベントリデータのリソースフィルターを適用したりできます。and/or 演算子を使用してフィルターセットを作成して保存し、セキュリティ分析の特定の基準を定義できます。保存されたフィルターセットやウィジェットレイアウトを含むダッシュボードのカスタマイズは自動的に保存され、セッションをまたいで保持されます。 クロスリージョン集約を設定すると、 概要 ダッシュボードにホームリージョンから表示すると、リンクされたすべてのリージョンの検出結果が表示されます。AWS Organizations の委任管理者アカウントの場合、データには管理者アカウントとメンバーアカウントの両方の検出結果が含まれます。Security Hub は、検出結果が生成された日から 1 年間トレンドデータを保持します。1 年後、トレンドデータは自動的に削除されます。 ほぼリアルタイムのリスク分析 Security Hub はほぼリアルタイムでリスクを計算し、既存の脆弱性や設定ミスの分析に加えて、GuardDuty からの脅威の相関関係を含めるようになりました。GuardDuty が脅威を検出したり、Amazon Inspector が脆弱性を特定したり、AWS Security Hub CSPM が設定ミスを検出したりすると、Security Hub はこれらの検出結果を自動的に関連付け、関連するリスクエクスポージャーを更新します。この進歩により、セキュリティ体制に関するフィードバックが即座に得られるため、新たなリスクを迅速に特定し、是正措置によって予想どおりにリスクが軽減されたことを確認できます。 Secutiry Hub は、AWS Security Hub CSPM、Amazon Inspector、Amazon Macie、Amazon GuardDuty、およびその他のセキュリティサービスにわたる検出結果を相互に関連付け、セキュリティインシデントにつながる可能性のあるリスクを特定します。この相関関係は、複数のセキュリティ問題が組み合わさって重大なリスクが生じる場合を理解するのに役立ちます。Security Hub は、リソースの関連性、潜在的な影響、シグナル間の関係を分析することで、セキュリティシグナルにコンテキストを付加します。たとえば、Security Hub が、バージョニングが無効で、Object Lockが無効で、MFA 削除が無効になっている機密データを含む Amazon Simple Storage Service (Amazon S3) バケットを特定した場合、いずれかのコンポーネントを修正すると自動計算がトリガーされ、スケジュールされた評価を待たずに修正の有効性を検証できます。 [エクスポージャー] ページでは、検出結果がタイトルと重大度別に整理されているため、重要な問題に最初に焦点を当てることができます。このページには、過去 90 日間のエクスポージャー検出結果の平均数を重大度別に表示する傾向グラフを含む [概要] セクションがあります。この視覚化は、時間の経過に伴うリスク状況の変化を追跡し、セキュリティリスクのパターンを特定するのに役立ちます。 エクスポージャー検出結果はタイトルごとにグループ化され、展開可能な行には影響を受けたリソースの数と全体的な重大度が表示されます。各エクスポージャーのタイトルには、「Potential Data Destruction: S3 bucket with versioning, Object Lock, and MFA delete disabled (データ破壊の可能性: バージョニング、Object Lock、MFA 削除が無効になっている S3 バケット)」や「Potential Remote Execution: EC2 instance is reachable from VPC and has software vulnerabilities (リモート実行の可能性: EC2 インスタンスは VPC からアクセス可能で、ソフトウェアの脆弱性がある)」など、潜在的なセキュリティ上の影響について説明しています。 保存済みのフィルターセットまたはクイックフィルターを使用して、クリティカル、高、中、低などの重大度レベルに基づいてエクスポージャーをフィルタリングできます。このインターフェイスでは、アカウント ID、リソースタイプ、およびアカウントによるフィルタリングも可能なため、インフラストラクチャの特定の部分に関連するリスクをすばやく絞り込むことができます。 Security Hub は、検出結果が出るとすぐにエクスポージャーを生成します。たとえば、パブリックにアクセス可能な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスをデプロイし、Amazon Inspector が悪用されやすい脆弱性を検出したときに、AWS Security Hub CSPM がパブリックアクセシビリティの設定を識別している間に、Secutiry Hub はこれらの検出結果を自動的に相互に関連付けてリスクを発生させ、予定された評価を待たずにリスクを発生させます。このほぼリアルタイムの相関関係により、新たに導入されたリソースにおける重大なリスクを特定し、悪用される前に対策を講じることができます。 エクスポージャー検出結果を選択すると、詳細ページにエクスポージャータイプ、プライマリリソース、地域、アカウント、年齢、作成時間が表示されます。 [概要] セクションには、リスクにさらされるシナリオに直接影響するセキュリティ問題を表す原因となる特性が表示されます。これらの特性は、「 到達可能性 」、「 脆弱性 」、「 機密データ 」、「 設定ミス 」、「 想定可能性 」などのカテゴリー別に整理されています。 詳細ページには [潜在的な攻撃パス] タブがあり、潜在的な攻撃者がどのようにリソースにアクセスして制御できるかを視覚的に示すグラフが表示されます。この視覚化には、プライマリリソース (EC2 インスタンスなど)、関連するリソース (VPC、サブネット、ネットワークインターフェイス、セキュリティグループ、 AWS Identity and Access Management (IAM) インスタンスプロファイル、IAM ロール、IAM ポリシー、ボリュームなど)、および寄与する特性間の関係が表示されます。このグラフは、アタックサーフェス全体を把握し、調整が必要なセキュリティコントロールを特定するのに役立ちます。 [特性] タブには、リスクにさらされる原因となっているすべてのセキュリティ問題が一覧表示され、 [リソース] タブには影響を受けるすべてのリソースが表示されます。 [修復] セクションでは、優先順位付けされたガイダンスとドキュメントへのリンクが提供され、リスクを最も効果的に軽減するために最初に対処すべき特性が推奨されます。この包括的なビューを使用することで、チームが環境全体の脆弱性、構成ミス、その他のセキュリティギャップに対処する際に、特定のリスクを調査し、セキュリティリスクの全体像を把握し、修正の進捗状況を追跡できます。 パートナー統合の拡大 Secutiry Hub は、インシデント管理ワークフローのために Jira および ServiceNow との統合をサポートしています。結果を表示する場合、 AWS Security Hub コンソール から任意のシステムでチケットを直接作成できます。チケットには、検出結果の詳細、重大度、推奨修復手順が自動的に入力されます。Security Hub では、重大度レベル、リソースタイプ、検出結果タイプなど、指定した条件に基づいてアトラシアンの Jira Service Management と ServiceNow でチケットを自動的に作成する 自動化ルール を定義することもできます。これにより、人手を介さずに重大なセキュリティ問題をインシデント対応チームに振り分けることができます。 Security Hub の検出結果は、セキュリティツールがデータをシームレスに共有できるようにするオープンソース標準である Open Cybersecurity Schema Framework (OCSF) スキーマでフォーマットされています。Secutiry Hub で OCSF 形式との統合を構築したパートナーには、Cribl、CrowdStrike、DataDog、Dynatrace、Expel、Graylog、Netskope、Securonix、SentinelOne、Cisco 傘下の Splunk、Sumo Logic、Tines、Upwind Security、Varonis、DTEX、Zscaler などがあります。さらに、Accenture、Caylent、Deloitte、Optiv、PwC、Wipro などのサービスパートナーが、Secutiry Hubと OCSF スキーマの導入を支援できます。 Secutiry Hub は、 Amazon EventBridge による自動応答ワークフローもサポートしています。指定した基準に基づいて検出結果を識別する EventBridge ルール を作成し、それらを AWS Lambda 関数 や AWS Systems Manager Automation ランブックなどのターゲットにルーティングして処理と修正を行うことができます。これにより、手動で操作しなくてもプログラム的に検出結果に基づいて行動できます。 今すぐご利用いただけます 現在 AWS Secutiry Hub CSPM、Amazon GuardDuty、Amazon Inspector、または Amazon Macie を使用している場合は、 AWS Security Hubコンソール に移動することでこれらの機能にアクセスできます。新規のお客様は、 AWS マネジメントコンソール から Security Hub を有効にし、ワークロードに適したセキュリティサービスを設定できます。Security Hub は、有効になっているサービスからの検出結果を自動的に利用して、統合コンソールで確認できるようにし、取り込まれたセキュリティデータに基づいて相関関係のあるエクスポージャー検出結果を作成します。 リージョンの提供状況については、 リージョン別の AWS サービス のページをご覧ください。ほぼリアルタイムのエクスポージャー計算とトレンド機能は追加料金なしで含まれています。Security Hub は、合理化されたリソースベースの価格モデルを使用しており、統合された AWS セキュリティサービス全体の料金を統合しています。コンソールには、デプロイ前に AWS アカウントとリージョン全体のセキュリティ投資を計画および予測するのに役立つコスト見積もりツールが含まれています。機能、サポートされている統合、価格の詳細については、AWS Security Hub の 製品ページ と 技術文書 をご覧ください。 – Esra 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの田中豊洋です。月刊 AWS 製造の 12 月号をお届けします。先月号は こちら です。本号では、BMW 様、Bayer 様、Rio Tinto 様、三菱電機様の先進的な成功事例をはじめ、製造企業における AWS サービスの活用記事を纏めています。製造企業に有用な AWS サービスのアップデート情報も含め、最新のトレンドをご確認ください。 ピックアップトピック 12/1から5 にかけて、ラスベガスにて AWS re:Invent 2025 が開催されました。本年は、エージェントAIの強化と、様々なユースケースにおける活用例が示されました。EXPOでは生産工程ロボットの監視や問題の分析、AIを使った設計支援から3Dプリンターへの仮想工場といった展示を提供し、日本でのツアーも実施し、数多くのお客様に最新のユースケースをお伝えすることができました。パートナー、AWS からも Physical AIに関連した展示が登場しています。本年は、日本からも複数の展示やセッション登壇を行いました。来月の月刊 AWS製造でより詳細にお届けるする予定ですので、ぜひご期待ください。 re:Invent セッション動画は、こちらの AWS Events の Youtube チャネルから視聴いただけます。 https://www.youtube.com/@AWSEventsChannel 直近で開催予定のイベント 01/06 – 09 CES 2026 世界最大級のテクノロジー見本市である CES がラスベガスで開催されます。CES 2025 で AWS は、NVIDIA や Siemens などのパートナーとともに、自動運転や SDV 、デジタルツインなどのソリューション展示を行いました。AWS は今年も出展し、現地には日本人スタッフも常駐していますので、是非お立ち寄りください。 01/26 – 29 SCA/HPCAsia2026 HPC ( High Performance Computing ) 関連の国際カンファレンス 「 SCA/HPCAsia2026 」 が日本 ( 大阪 ) で初めて開催されます。AWS もブース出展しますので、大規模な CAE や EDA 環境の改善をご検討中の方や、R&D 部門などで HPC に関わる方、最新動向を掴みたい方は、是非お越しください。12 / 21 までに先行登録すると、参加費が割引になります。 登録ページは こちら です。 製造関連ブログのご紹介 11/03 AWS Professional Services and BMW collaborate to optimize petabyte-scale storage costs for automated driving data このブログは、BMW と AWS Professional Services が自動運転データのペタバイト規模ストレージコストを最適化した事例を紹介しています。自動運転開発では膨大なデータが生成され、1 台のテスト車両が 1 日に数十テラバイトのデータを生成するため、効率的なストレージ管理が課題となっていました。AWS は Amazon S3 の機能 ( S3 Storage Lens、S3 Intelligent-Tiering、S3 Server Access Logging ) を活用し、大幅なコスト削減を実現しました。 11/10 Implement Zero-Training Visual Defect Detection in Manufacturing with Amazon Nova Pro このブログでは、製造業における品質検査に Amazon Nova Pro を活用し、学習データ不要 ( ゼロトレーニング ) で外観検査を行う方法について紹介しています。AWS サービスと数行のプロンプトを記述する方法により、AI / ML の専門知識を必要とせず、従来型に匹敵する性能を実現しています。 Modernizing laboratory networks: How Bayer centralizes LIMS on AWS Cloud このブログは、グローバルに分散した拠点を持つ Bayer が、LIMS ( ラボ情報管理システム ) を AWS クラウド上に集約した事例を紹介しています。Bayer では、オンプレミスの通信ドメインを企業ネットワーク ( IT ) 、工場ネットワーク ( OT ) 、研究所ネットワークの 3 つに分離し、セキュリティとガバナンスに対応しています。そこで Bayer は各種規制要件や運用負担抑制を満たしつつ LIMS の集約に成功しました。 11/11 三菱電機グループエンジニアコミュニティの新たな地平 – MAWS-UG が生み出す実務への好循環と次世代への継承 このブログでは、三菱電機グループの AWS ユーザーコミュニティ「MAWS-UG」が、前回記事公開から1年間で単なる技術交流の場から組織変革を牽引するコミュニティへと進化した成果を紹介しています。社外コミュニティとの連携拡大、他の製造業企業との交流、実際のビジネスプロジェクトでの活用など、2025年1月の三菱電機と AWS の戦略的協業においても重要な役割を担うことになった軌跡を、メンバーの生の声とともに詳しく解説しています。 11/20 Transforming Smart Product Companies into Digital Service Leaders: A Data-Driven Marketing Architecture on AWS このブログは、スマート製品メーカーが AWS を活用してデジタルサービスリーダーへと変革する方法を解説しています。Gartner によると、2027 年までに AI モデルの 80% が業界特化型になると予測されています。AWS のサービスを利用した包括的なデータ駆動型アーキテクチャにより、継続的な顧客接点、予測保守機能、データ駆動型の製品革新サイクルを実現します。Siemens や Stanley Black & Decker などの成功事例も紹介されています。 11/21 Managing Sustainability Data for Digital Product Passports with Agentic AI 2024 年に EU で ESPR ( エコデザイン規制 ) が施行されました。これに伴い、2027 年から段階的に Digital Product Passport ( DPP ) の実装が義務化されます。このブログでは、DPP の実現におけるグローバルサプライヤーからのデータ収集・標準化、レガシーシステム統合、データ検証などの課題に対し、AI エージェントによる解決方法を解説しています。 11/25 Top-performing supply chains: When AI meets energy industry experience このブログでは、エネルギー業界のサプライチェーンにおいて、AI 活用によって変革するストーリーを紹介しています。製造業に通ずる部分が多く、Amazon SageMaker と Amazon Bedrock を中心とした AWS サービスを利活用することで、需要予測とスペアパーツ在庫の最適化提案、リスクシミュレーション、製品トレース機能によるコスト削減の価値を訴求しています。 イベント動画のご紹介 11/06 Reimagining Manufacturing: Clariant’s SAP RISE Journey with AWS 大手化学メーカーの Clariant が SAP with RISE を選んだ理由とその効果、IoT や AI の活用で可視化や予測機能の活用について述べています。 11/10 How to Modernize your Existing GenAI Manufacturing Solutions | How to build like AWS 空調機器製造大手の Carrier のコールセンターで、通話内容の自動要約システムを構築した事例です。オペレーターは手動で要約を書く負担から解放され、生産性が大きく向上しました。 11/13 Rio Tinto unlocks potential of generative AI 世界的な総合資源企業である Rio Tinto では、バリューチェーン全体で戦略的に AI を実装推進しています。同社の社内では、生成 AI に関する最大のリスクは回答精度の低さであると位置づけました。これに対し、ベクトル DB だけでなく、ドメイン知識を持たせたグラフ DB とのハイブリッド RAG で精度を大幅に向上させました。 製造関連の主要なアップデート 10/30 AWS IoT Greengrass のデベロッパー向け AI エージェントコンテキストパックが提供開始 AI エージェントに AWS IoT Greengrass 構築・開発方法を教え込むためのコンテキストパックが提供開始となりました。 11/11 AWS Parallel Computing Service (PCS) が Slurm CLI Filter プラグインのサポートを開始 一般的なスパコンや AWS PCS のような HPC ( High Performance Computing ) クラスタでは、ジョブスケジューラーとして Slurm が広く使われています。ユーザーは Slurm にジョブ実行を依頼することで、Slurm が計算リソースを確保し、ジョブの優先順位を確定させて処理を流します。今回の Slurm CLI Filter は、ジョブ制御に関する運用負担軽減と俊敏性向上に寄与します。 11/17 Deploying an MES in the AWS Cloud and at the edge on Outposts この記事では、製造実行システム ( MES ) である Siemens Opcenter Execution を AWS クラウドと AWS Outposts の両方に展開する方法を詳細に解説しています。高可用性と低レイテンシーを両立させる構成における考慮事項を説明しています。 11/24 AWS IoT Core now supports IoT thing registry data retrieval from IoT rules AWS IoT Core の IoT rule で、デバイス固有の情報を参照できるようになりました。これにより、例えば本番デバイスからの送信データとテストデバイスからの送信データを区別をノンコーディングで実装することが可能となりました。 11/25 Guidance for Physical AI for Robotics on AWS フィジカル AI のガイダンスが公開されました。Amazon SageMaker AI で学習した AI モデルをロボット上の AWS IoT Greengrass にデプロイし、エッジ推論を行うとともに、ロボットのセンサーデータを AWS クラウドに収集して AI モデルを再学習するものです。 11/26 Amazon Quick Suite introduces scheduling for Quick Flows Amazon Quick Suite の Quick Flows にスケジューリング機能が備わりました。様々なデータソースを参照する AI エージェントによるレポート作成等を、定期実行することが可能となりました。 Amazon Kinesis Video Streams now supports a new cost effective warm storage tier Amazon Kinesis Video Streams に、コスト効率の高いウォームストレージ層がサポートされました。監視カメラやVSaaS等の録画データを長期間保存する用途において、コスト削減が見込めます。 いかがでしたでしょうか。 皆様の情報キャッチアップのご支援になりましたら幸いです。 では、また来月も本ブログにお付き合いください。 著者について 田中　豊洋 AWS Japan のソリューションアーキテクトとして、製造業のお客様の技術支援を担当しています。製造業の IT 部門を計 24 年経験してきたことで、製造業視点で AWS 利活用を考えています。

はじめに Amazon Connect は、組織が大規模に優れた顧客体験を提供することを可能にする、使いやすいエンタープライズクラウドコンタクトセンターです。Amazon Connect の主要なメリットの一つに、Amazon CloudWatch とのネイティブ統合があります。この統合は運用状況を分析し、問題が顧客に影響を及ぼす前にアラートを受けることができる強力な機能を提供します。これにより、オンプレミス展開では実現が困難な規模とスピードでインサイトを提供します。 Model Context Protocol (MCP) を使えば、生成 AI を活用し、コンタクトセンター分析をさらにアクセスしやすく効率的にすることができ、これらの強力な分析機能を強化することができます。MCP により、AI エージェントを Amazon Connect の組み込み監視機能やサードパーティのデータソースと統合し、運用監視準備のための拡張フレームワークを作成できます。Amazon Q Developer などのツールを通じ、組織はかつてないほど簡単かつ迅速にコンタクトセンター運用に関するさらに深いインサイトにアクセスできるようになりました。 Amazon Connect のエンタープライズグレードの機能と MCP の AI による自動化の強力な組み合わせは、日常的な運用タスクを合理化されたインテリジェントなワークフローに変えます。フロー効率の分析、監視設定の最適化、使用パターンの調査などのタスクは、自然言語インタラクションを通じてより直感的になります。このブログでは、MCP が Amazon Connect のオブザーバビリティの強みをどのように増幅し、コンタクトセンター運用準備の次世代アプローチによって、組織がどのような実用的なユースケースを実現できるかを探ります。 ユースケースを通じた MCP の理解 Amazon Connect を運用する組織に参加したばかりのビジネスアナリスト、John を想像してみましょう。彼のタスクは、問い合わせフローの確認と監視設定の最適化です。このユースケースはまさに Amazon Connect の強力な機能を MCP がどのように強化するかを示す完璧な例です。Amazon Connect は包括的な Amazon CloudWatch 統合と監視ツールを標準で提供していますが、MCP は自然言語でのやり取りを通じて、これらの機能をさらにアクセスしやすくします。 Amazon Connect のネイティブなオブザーバビリティ機能により、John は既に詳細なフローログ、パフォーマンスメトリクス、監視機能にアクセス可能です。加えて MCP によって、John はこれらの強力なツールと会話型 AI を通じてやり取りすることができます。この強化された体験は、生産性とインサイトの生成を劇的に向上させます。MCP を生成 AI と組み合わせて使うことで、John は Amazon Connect の堅牢な監視インフラストラクチャをより直感的に活用できます。自然言語で質問し、プラットフォームの既存の強みを基盤とした包括的な分析を受け取ることができるのです。 プロンプト: 'aws-knowledge MCP' を使用してAmazon Connectフローのベストプラクティスを参照し、'aws-api-mcp' を使用して 'xyz' Amazon Connectインスタンスの 'AC-Blog-CallBack-Welcom-1' フローをレビューしてください。フィードバックを提供し、CloudWatchアラームも推奨してください。 分析結果: 図 1: Amazon Connect のフロー分析結果 MCP クライアントのライフサイクル MCP は次のようなライフサイクルで、ユーザープロンプトを実行可能な結果に変換するため、連携するコンポーネントをオーケストレーションします。このプロセスは 5 つの主要段階で構成されます : 検出フェーズ ：通常、個人のラップトップやワークステーション上で実行される MCP クライアントは、最初に利用可能な MCP サーバーと関連ツールを発見します。この初期の処理が、その後のすべてのインタラクションの基盤を確立します ユーザーインタラクション ：ユーザーは MCP クライアントのインターフェース（例：VS Code）を通じてクエリやプロンプトを入力します。これらのプロンプトは、シンプルなリクエストから Amazon Connect 管理のための複雑な運用コマンドまで多岐にわたります LLM 分析 ：Amazon Bedrock を通じてアクセスされるような基盤モデルが、インテリジェントなオーケストレーターとして機能し、3 つの部分からなる分析を実行します ユーザーのプロンプトの評価 利用可能な MCP サーバーの調査 関連ツールとその説明を評価します。この分析に基づいて、LLM はユーザーのリクエストを満たす最適なパスを決定する包括的な実行計画を作成します ツール呼び出し ：MCP クライアントは、LLM の実行計画に基づいて適切なツールの呼び出しを開始します。この段階で、ユーザーの要求が具体的なツール操作に変換されます 実行 ：最終段階で、MCP サーバーが必要なバックエンド API とコードの実行により、要求された操作を実行します。これには、AWS のドキュメントへのアクセス、AWS サービス操作の実行、推奨事項の生成など、さまざまなアクションが含まれる可能性があります このような合理的なライフサイクルにより、実行のチェーン全体を通じ、セキュリティと運用の整合性を維持しながら、ユーザーリクエストの効率的な処理することができます。 Amazon Connect のオブザーバビリティのための Amazon Q Developer を使用した MCP の設定 MCP は、AI アプリケーションを外部データソースやツールと接続するための標準化されたアプローチを提供します。Amazon Connect のオブザーバビリティにおいては、MCP は組織による自然言語クエリを通じた AI による分析を利用可能にし、従来の手動プロセスを自動化されたワークフローに変換できます。 MCP は、 Amazon Q Developer を使用した VS Code、 Amazon Q CLI 、Claude Code、 Kiro 、およびカスタム統合を含む複数のクライアント実装でサポートされています。この投稿では、VS Code と Amazon Q Developer を使って、 AWS MCP サーバー を設定し、会話型 AI を通じて包括的な Amazon Connect の分析を行う方法を説明します。 前提条件とセットアップ MCP による Amazon Connect のオブザーバビリティを設定するためには、以下の環境が必要です。 uv パッケージマネージャーがインストールされた Python 3.10 以上の環境 Amazon Q Developer 拡張機能が設定された Visual Studio Code(VS Code) Amazon Connect 、Amazon CloudWatch 、AWS CloudTrail にアクセス権限をもつ AWS 認証情報 Amazon CloudWatch へのロギングが有効な Amazon Connect インスタンス MCP サーバーの構成 AWS MCP Servers リポジトリ は、Amazon Connect のオブザーバビリティに使用できる複数の MCP サーバーを提供しています： AWS API MCP Server は、Amazon Connect インスタンス管理と設定分析を含む AWS サービスとの直接的なやり取りを可能にします CloudWatch MCP Server は、パフォーマンス分析とトラブルシューティングに不可欠なメトリクス、ログ、監視データへのアクセスを提供します。※注意: このサーバーには、AWS アカウントとリージョンに対して設定された AWS プロファイルが必要です AWS Documentation MCP Server は、AWS のベストプラクティスと実装ガイダンスへのアクセスを提供します MCP サーバーの設定 次のように Amazon Q Developer MCP 設定でこれらのサーバーを設定してください。 MCP サーバーの設定には2つの方法があります。 方法 1：Amazon Q Developer GUI を使用する（推奨） MCP 設定へのアクセス VS Code を開く Amazon Q Developer のパネルを開く Amazon Q Developer 内のチャットパネルを開く 「ツールアイコン」（歯車またはレンチのシンボル）をクリックして MCP 設定にアクセス MCP サーバーの追加または編集 新しいサーバーの追加：プラス（+）マークをクリック 既存のサーバーの編集：リストからサーバーを選択 設定のスコープの選択 グローバル（すべてのプロジェクトに適用）：設定は ~/.aws/amazonq/mcp.json に保存されます ローカル（ワークスペース・現在のプロジェクトのみに適用）：設定は .amazonq/mcp.json に保存されます サーバーの詳細設定 – 各 MCP サーバーのドキュメントガイダンスに従ってください： 名前 ：わかりやすい名前を入力します（例：「aws-api」、「cloudwatch」） トランスポート ：通信プロトコルを選択します（stdio） コマンド ：実行コマンドを提供します（例：uv run aws-api-mcp） 引数 ：必要に応じて必要な引数を追加します 環境変数 ：必要に応じて AWS_REGION、AWS_PROFILE を設定します 「保存」をクリックして変更を適用します 図 2: VS Code 上の Amazon Q Developer の MCP 設定 GUI で、ツール設定・サーバー設定画面を表示している様子 方法 2: JSON ファイルを手動で設定する 手動で設定したいユーザーは、MCP 設定ファイルを直接編集することも可能です。 グローバル設定ファイル ( ~/.aws/amazonq/mcp.json )： { "mcpServers": { "cloudwatch-mcp-server": { "autoApprove": [], "disabled": false, "command": "uvx", "args": [ "awslabs.cloudwatch-mcp-server@latest" ], "env": { "AWS_PROFILE": "connect-observability", "FASTMCP_LOG_LEVEL": "ERROR" }, "transportType": "stdio" }, "aws-documentation-mcp-server": { "command": "uvx", "args": [ "awslabs.aws-documentation-mcp-server@latest" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_DOCUMENTATION_PARTITION": "aws" }, "disabled": false, "autoApprove": [] }, "cost-explorer-mcp-server": { "command": "uvx", "args": [ "awslabs.cost-explorer-mcp-server@latest" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_PROFILE": "connect-observability" }, "disabled": false, "autoApprove": [] }, "aws-api-mcp-server": { "command": "uvx", "args": [ "awslabs.aws-api-mcp-server@latest" ], "env": { "AWS_REGION": "us-east-1", "AWS_API_MCP_PROFILE_NAME": "connect-observability" }, "timeout": 60000000, "disabled": false } } } ローカル/ワークスペース設定ファイル (プロジェクトルートの .amazonq/mcp.json )：プロジェクト固有の設定が必要な場合、保存先を変えて同じ JSON 構造を使用します。 Amazon Connect とのデータ統合 MCP サーバーは、標準的な AWS API や Amazon CloudWatch との統合を通じて Amazon Connect のデータにアクセスします。主なデータソースには以下が含まれます： コンタクトフローのログ： /aws/connect/contactflow/[instance-id] に含まれる実行の詳細とパフォーマンスメトリクス エージェントイベントログ：リアルタイムのエージェントのアクティビティとステータス変更 AWS CloudTrail イベント：セキュリティ分析のための管理アクションと API 呼び出し Amazon Connect メトリクス：履歴パフォーマンス データと使用パターン 包括的な分析を有効にするため、AWS 認証情報に connect:List*、connect:Describe*、cloudwatch:GetMetricStatistics、および logs:FilterLogEvents の権限が含まれていることを確認してください。 プロンプト例 MCP の強力な点の一つは、よく練られたプロンプトを通じ、役割に応じた複雑なタスクを処理できる点です。以下の例は、組織内の異なる役割の人々が MCP を活用して Amazon Connect の運用を強化する方法を示しています。これらのプロンプトは、セキュリティ監視からパフォーマンス最適化まで、既存の機能を強化する MCP の汎用性を示しています。セキュリティ分析の強化、技術的異常の調査、アラーム設定の最適化、ユーザー管理、使用傾向の分析など、これらのプロンプトは MCP を使った独自の実装のための実用的なテンプレートとしても活用できます。 例 1 (セキュリティ分析者向け) Amazon Connect の CloudTrail logs を解析して、exceptionを報告して 例 2 (開発者向け) Amazon Connect インスタンス xyz のアノマリを CloudWatch のフローログから検索して、解決策を提案して 例 3 (開発者向け) Amazon Connect インスタンス xyz に適したCloudWatch metrics の Alarm を推奨して 例 4 (開発者向け) Amazon Connect インスタンス 'xyz' のユーザーを 'abc' にコピーし、その結果を報告して 例 5 (ビジネスアナリスト向け) Amazon Connect の利用料を 12 か月分分析して。最もコストが高かった月について、顧客の通話パターンを報告して 最適化とベストプラクティス クエリ設計 : 応答精度を最大化し、処理時間を最小化するために、プロンプトを、特定の時間範囲、リソース識別子、分析目標を含んだ構造にします。例えば: 「’xyz’ Amazon Connect インスタンスの CloudWatch ログをスキャンする」の代わりに 「’xyz’ Amazon Connect インスタンスの過去 30 日間のフローログをスキャンする」を使用します リソース管理 : 分析機能を維持しながらコストを管理するため、AWS APIの使用パターンを監視し、適切なサービスクォータを設定します パフォーマンスチューニング : AI によるインサイトの恩恵を受ける複雑な分析タスクには MCP を使用、日常的なメトリクス可視化には従来の監視ダッシュボードを活用します バッチ処理 : 定期的なオブザーバビリティのタスクについては、API クォータへの影響を最小化するために、アクセスが集中しない時間帯に分析を予定することを検討します セキュリティの考慮 : MCP サーバー構成に最小権限アクセスの原則を実装し、セキュリティ体制を維持するため、権限を定期的に監査します クリーンアップとリソースの管理 MCP 設定を削除する際は、Amazon Q Developer 設定からサーバー定義を削除、uv uninstall を使用して関連パッケージをアンインストール、そして実装中に作成された一時的な AWS リソースをクリーンアップします。 まとめ MCP は、自然言語インターフェースを通じた AI を活用した分析を可能にし、Amazon Connect の強力なオブザーバビリティ機能を強化します。この方法によって、Amazon Connect の強力な CloudWatch 統合とエンタープライズグレードの監視機能を基盤にした高度な分析を、あらゆる規模の組織にとってさらにアクセスしやすくします。 Amazon Connect で MCP を活用する組織は、既存の分析機能の強化、インサイト生成の加速、運用監視準備の強化を期待できます。標準化されたプロトコルによって、プラットフォームのスケーラビリティと信頼性を複数のインスタンス間で維持しながら、Amazon Connect のネイティブ機能とシームレスに統合できます。 Amazon Connect の運用準備のため、 MCP の利用を開始するには、強化されたコンタクトフロー分析やインテリジェントなパフォーマンス監視など、既存の CloudWatch データの活用に焦点を絞ったユースケースから始めましょう。プラットフォームへの習熟度が高まったら、Amazon Connect のエンタープライズ基盤を基に構築された包括的なセキュリティ監視、コスト最適化、自動化された運用ワークフローを含む実装に拡張していきましょう。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

2025 年 12 月 2 日、AI エージェントを本番稼働環境から引き離す障壁をさらに取り除くための Amazon Bedrock AgentCore の新機能を発表しました。あらゆる業界の組織が、あらゆる規模で高性能なエージェントを安全に構築、導入、運用するための最先端のプラットフォームである AgentCore をすでに利用しています。プレビューからわずか 5 か月で、 AgentCore SDK は 200 万回以上ダウンロードされました 。例: スポーツのパイオニアでありイノベーションリーダーでもある PGA TOUR は、デジタルプラットフォーム向けの記事を作成するためのマルチエージェントコンテンツ生成システムを構築しました。AgentCore 上に構築されたこの新しいソリューションにより、PGA TOUR はコンテンツの書き込み速度を 1,000 パーセント向上させながらコストを 95％ 削減することで、フィールドのすべてのプレーヤーに包括的なサービスを提供できます。 Workday のような独立系ソフトウェアベンダー (ISV) は、AgentCore で未来のソフトウェアを構築しています。AgentCore Code Interpreter は、Workday Planning Agent に安全なデータ保護と財務データ探索に不可欠な機能を提供します。ユーザーは自然言語クエリを使用して財務データや業務データを分析できるため、財務計画を直感的かつ自発的に行うことができます。この機能により、日常的な計画分析に費やす時間が 30% 短縮され、1 か月あたり約 100 時間を節約できます。 ブラジルのディストリビューター兼小売業者である Grupo Elfa は、エージェントの完全な監査トレーサビリティとリアルタイムメトリクスのために AgentCore Observability を活用し、事後対応型のプロセスをプロアクティブな業務に変えています。この統合プラットフォームを使用することで、営業チームはエージェントの決定を完全に可視化しながら、毎日何千件もの価格見積もりを処理できます。これにより、エージェントの意思決定とやり取りの 100% のトレーサビリティが実現し、問題解決にかかる時間が 50% 短縮されます。 組織がエージェントのデプロイをスケールするにつれ、自信を持ってエージェントを配置するための適切な境界と品質チェックの実施に関する課題に直面します。また、エージェントは自律性が高いため、機密データに不適切にアクセスしたり、不正な決定を下したり、予期せぬ行動を取ったりする可能性があるため、安心して大規模に展開することが難しくなります。開発チームは、エージェントの自律性を実現すると同時に、許容範囲内で業務を遂行し、顧客や従業員の前に配置するために必要な品質とのバランスを取る必要があります。 現在利用可能な新機能により、このプロセスを推測する必要がなくなり、信頼できる AI エージェントを自信を持って構築してデプロイできるようになります。 AgentCore のポリシー (プレビュー) — 詳細な権限を持つポリシーを使用して実行前に AgentCore Gateway ツールの呼び出しをインターセプトすることにより、エージェントアクションの明確な境界を定義します。 AgentCore Evaluations (プレビュー) — 組み込みエバリュエーターを使用して、実際の行動に基づいてエージェントの質をモニタリングします。正確性や有用性などのディメンションについては、組み込みのエバリュエーターと、ビジネス固有の要件に対応するカスタムエバリュエーターを使用します。 また、エージェントができることを拡張する機能も導入しています。 AgentCore Memory のエピソード機能 — エージェントが経験から学び、同様の状況でソリューションを適応させて、将来の同様のタスクの一貫性とパフォーマンスを向上させるのに役立つ新しい長期戦略です。 AgentCore Runtime の双方向ストリーミング — 音声エージェントを導入して、ユーザーとエージェントの両方が自然な会話フローに従って同時に話せるようにします。 エージェントを正確に制御するための AgentCore のポリシー ポリシーにより、エージェントが実行できるアクションやエージェントの推論ループの外部に適用できるアクションを制御できるため、エージェントは、ツール、システム、またはデータに到達する前に決定が検証を必要とする自律的なアクターとして扱われます。AgentCore Gateway と統合することで、ツールの呼び出しを発生時に傍受し、運用速度を維持しながらリクエストを処理できるため、ワークフローの高速性と応答性が維持されます。 自然言語を使用してポリシーを作成することも、 Cedar (きめ細かな権限を持つオープンソースのポリシー言語) を直接使用することもできます。これにより、カスタムコードを記述しなくても、ルールを設定、理解、監査するプロセスが簡素化されます。このアプローチにより、コーディングの専門知識がなくてもルールを作成、理解、監査できる開発、セキュリティ、コンプライアンスチームがポリシーを作成しやすくなります。 ポリシーは、エージェントの構築方法や使用するモデルとは無関係に機能します。API、 AWS Lambda 関数、 モデルコンテキストプロトコル (MCP) サーバー、サードパーティサービスなど、どのツールとデータエージェントがアクセスできるか、どのようなアクションをどのような条件で実行できるかを定義できます。 チームは明確なポリシーを一度定義すれば、それを組織全体に一貫して適用できます。ポリシーが整っていれば、開発者は革新的なエージェント体験を自由に生み出すことができ、組織はエージェントを配置して、定義された境界やコンプライアンス要件の範囲内にとどまることを認識しながら、自律的に行動することができます。 エージェントコアでのポリシーの使用 まず、 AgentCore コンソール の新しい [ポリシー] セクションでポリシーエンジンを作成し、それを 1 つ以上の AgentCore Gateway に関連付けることができます。 ポリシーエンジンは、ゲートウェイエンドポイントで評価されるポリシーの集まりです。ゲートウェイをポリシーエンジンに関連付ける場合、ポリシーの結果を適用する (ツールコールへのアクセスを効果的に許可または拒否する) か、ログのみを出力するかを選択できます。ログは、本番稼働環境で有効にする前にポリシーをテストして検証するのに役立ちます。 次に、適用するポリシーを定義して、関連する AgentCore Gateway が提供するツールへのアクセスをきめ細かく制御できます。 ポリシーを作成するには、自然言語による説明 (使用する認証クレームの情報を含める必要があります) から始めることも、Cedar コードを直接編集することもできます。 自然言語ベースのポリシーオーサリング機能により、きめ細かなポリシーをより簡単に作成できます。正式なポリシーコードを書く代わりに、わかりやすい英語でルールを記述できます。システムはユーザーの意図を解釈し、候補となるポリシーを生成し、ツールスキーマと照合して検証し、自動推論を使用して安全条件をチェックします。つまり、過度に寛容なプロンプト、過度に制限されたプロンプト、または決して満たすことができない条件を含むプロンプトを特定します。 一般的な大規模言語モデル (LLM) による解釈とは異なり、この機能はツールの構造を理解し、適用できないルールにはフラグを立てながら、構文的に正しく、意味的に意図したとおりのポリシーを生成します。 モデルコンテキストプロトコル (MCP) サーバーとしても利用できるため、通常の開発ワークフローの一部として、お好みの AI 支援コーディング環境でポリシーを直接作成して検証できます。このアプローチにより、オンボーディング時間が短縮され、Cedar の専門知識がなくても質の高い承認ルールを作成できます。 次のサンプルポリシーでは、AgentCore Gateway への認証に使用される JWT トークンの OAuth クレームの情報 ( ロール 用) とツール呼び出しに渡される引数 ( context.input ) を使用して、払い戻しを処理するツールへのアクセスを検証します。 refund-agent ロールを持つ認証ユーザーのみがツールにアクセスできますが、金額 ( context.input.amount ) には 200米ドル未満という制限が課せられています。 permit( principal is AgentCore::OAuthUser, action == AgentCore::Action::"RefundTool__process_refund", resource == AgentCore::Gateway::"<GATEWAY_ARN>" ) when { principal.hasTag("role") && principal.getTag("role") == "refund-agent" && context.input.amount < 200 }; 継続的かつリアルタイムの品質インテリジェンスを実現するための AgentCore Evaluations AgentCore Evaluations は、実際の行動に基づいてエージェントのパフォーマンスを継続的にモニタリングおよび分析するのに役立つフルマネージドサービスです。AgentCore Evaluations では、組み込みのエバリュエーターを使用して、正確性、有用性、ツール選択の精度、安全性、目標達成率、コンテキストの関連性などの一般的な品質評価を行うことができます。また、選択したプロンプトとモデルで構成されたカスタムモデルベースのスコアリングシステムを作成して、サービスがエージェントのライブインタラクションをサンプリングして継続的にスコアリングしながら、ビジネスに合わせたスコアリングを行うこともできます。 AgentCore Evaluations の結果はすべて、AgentCore Observability のインサイトとともに Amazon CloudWatch で視覚化されるため、一元的にモニタリングできます。また、評価スコアにアラートやアラームを設定して、エージェントの品質を積極的にモニタリングし、メトリクスが許容範囲を超えたときに対応することもできます。 AgentCore Evaluations は、デプロイ前にエージェントをベースラインと照合して欠陥のあるバージョンがユーザーに届かないようにするテストフェーズで使用できます。また、本番稼働環境ではエージェントの継続的な改善に使用できます。品質メトリクスが定義されたしきい値を下回ると (たとえば、カスタマーサービスエージェントの満足度が 8 時間にわたって低下したり、礼儀正しさのスコアが 8 時間で 10% 以上低下したりした場合)、システムは即座にアラートをトリガーし、品質問題をより迅速に検出して対処するのに役立ちます。 AgentCore Evaluations の使用 AgentCore コンソール の新しい [評価] セクションでオンライン評価を作成できます。データソースとして、AgentCore エージェントエンドポイントまたは外部エージェントが使用する CloudWatch ロググループを使用できます。たとえば、ここでは、 プレビューで AgentCore を導入 したときに共有したのと同じサンプルカスタマーサポートエージェントを使用しています。 次に、既存のテンプレートから定義したり、ゼロから構築したりできるカスタムエバリュエーターを含め、使用するエバリュエーターを選択できます。 たとえば、カスタマーサポートエージェントの場合、次のようなメトリクスを選択できます。 正確性 — エージェントの回答に含まれる情報が事実に基づいて正確かどうかを評価します 忠実性 — 回答の情報が提供されたコンテキスト/ソースによってサポートされているかどうかを評価します 有用性 — エージェントの対応がどれほど有用で価値があるかをユーザーの視点から評価します 有害性 — 応答に有害なコンテンツが含まれているかどうかを評価します ステレオタイプ — 個人やグループについて一般化しているコンテンツを検出します ツール選択とツールパラメータ精度のエバリュエーターは、エージェントがタスクに適したツールを選択し、ユーザークエリから正しいパラメーターを抽出しているかどうかを理解するのに役立ちます。 評価の作成を完了するには、サンプリングレートとオプションのフィルターを選択できます。権限については、新しい AWS Identity and Access Management (IAM) サービスロールを作成するか、既存のサービスロールを渡すことができます。 結果は評価されると、 Amazon CloudWatch の AgentCore Observability ダッシュボードに公開されます。棒グラフのセクションのいずれかを選択すると、対応するトレースが表示され、その特定の評価の背後にある要求と応答についてより深いインサイトを得ることができます。 結果は CloudWatch に保存されるため、そのすべての機能を使用して、たとえばアラームや自動化などを作成できます。 AgentCore Evaluations でのカスタムエバリュエータの作成 カスタムエバリュエーターを使用すると、エージェント固有の要件に合わせたビジネス固有の品質メトリクスを定義できます。カスタムエバリュエーターを作成するには、温度や最大出力トークンなどの推論パラメーターを含むモデルと、判断指示を含むカスタマイズされたプロンプトを用意します。ビルトインのエバリュエーターが使用するプロンプトから開始することも、新しいエバリュエーターを入力することもできます。 次に、出力で生成するスケールを定義します。数値でも、定義したカスタムテキストラベルでもかまいません。最後に、評価がモデルによってシングルトレースで計算されるか、フルセッションで計算されるか、またはツール呼び出しごとに計算されるかを設定します。 体験型学習のための AgentCore Memory エピソード機能 AgentCore Memory は、AI エージェントが過去の対話を記憶できるようにするフルマネージドサービスで、エージェントが過去の経験から学び、その教訓を将来の対話でより役立つ支援を提供できるようにする、新しい 長期記憶戦略 が含まれるようになりました。 エージェントに旅行を予約することを検討してください。エージェントは、時間が経つにつれて、クライアントとのミーティングのために仕事で旅行するときにフライトを後の時間に移動する必要がある場合など、お客様の予約パターンから学習します。クライアントとのミーティングを含む次回の予約を開始すると、エージェントは学習したパターンに基づいて柔軟な返品オプションを積極的に提案します。特定の旅行習慣を学ぶ経験豊富なアシスタントと同じように、エピソード記憶を持つエージェントは、個々のニーズを認識してそれに対応できるようになりました。 新しいエピソード機能を有効にすると、AgentCore Memory は、エージェントとのやり取りのコンテキスト、推論プロセス、実行されたアクション、結果を記録する構造化されたエピソードをキャプチャし、リフレクションエージェントはこれらのエピソードを分析して、より幅広いインサイトとパターンを抽出します。エージェントは、似たようなタスクに直面したときに、学んだことを取り戻して意思決定の一貫性を高め、処理時間を短縮できます。これにより、考えられるすべての提案の長いリストではなく、エージェントがタスクを完了するために必要な特定の学習のみをエージェントコンテキストに含めることができるため、カスタムインストラクションの必要性が減ります。 より自然な会話を実現する AgentCore Runtime 双方向ストリーミング AgentCore Runtime を使用すると、数行のコードでエージェンティックアプリケーションをデプロイできます。自然で応答性の高い会話体験を簡単にデプロイするために、AgentCore Runtime は双方向ストリーミングをサポートするようになりました。この機能により、音声エージェントはユーザが話している間も聞き取って適応できるため、担当者は応答の途中でエージェントの話を中断し、エージェントが現在のアウトプットを完了するのを待たずに、エージェントに新しいコンテキストにすぐに順応させることができます。双方向ストリーミングは、ユーザーが完全な応答を待たなければならない従来のターン制の対話とは異なり、エージェントがユーザーの発言に基づいて応答を動的に変更する、流れるような自然な会話を生み出します。 このような会話体験をゼロから構築するには、同時コミュニケーションの複雑な流れを処理するための多大なエンジニアリング努力が必要です。双方向ストリーミングは、エージェントが入力を処理しながら出力を生成し、中断を正常に処理し、会話が動的に変化してもコンテキストを維持するために必要なインフラストラクチャを管理することで、これを簡素化します。人間の会話の流動的な性質に自然に適応するエージェントを配備できるようになりました。つまり、対話の流れを失うことなく、考えの途中での中断、コンテキストの切り替え、明確化をサポートできます。 知っておくべきこと Amazon Bedrock AgentCore (ポリシーのプレビューを含む) は、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ、シンガポール、シドニー、東京)、および欧州 (フランクフルト、アイルランド) の AWS リージョン でご利用いただけます。AgentCore Evaluations のプレビューは、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (シドニー)、および欧州 (フランクフルト) リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。 AgentCore では、前払いの義務なしで使用した分だけ支払うことができます。料金の詳細については、 Amazon Bedrock の料金ページ にアクセスしてください。AgentCore は AWS 無料利用枠 の一部でもあり、AWS の新規のお客様は無料で利用を開始し、主要な AWS サービスを試すことができます。 これらの新機能は、 CreWAI 、 LangGraph 、 LlamaIndex 、 Strands Agents などのあらゆるオープンソースフレームワークと、あらゆる基盤モデルで動作します。AgentCore サービスは一緒に使用することも、単独で使用することもできます。 AgentCore オープンソース MCP サーバー を使用して、お気に入りの AI 支援開発環境を使い始めることができます。 詳細を確認してすぐに使い始めるには、「 AgentCore デベロッパーガイド 」をご覧ください。 – Danilo 原文は こちら です。

（本稿は、2025年12月8日に公開された “ SAP data ingestion and replication with AWS Glue zero-ETL ” を翻訳したものです） 組織では、複雑なデータパイプラインを維持することなく、SAPシステムからデータを取り込み、インサイトへより迅速にアクセスするニーズが高まっています。 AWS Glue zero-ETL with SAP は、Operational Data Provisioning（ ODP ）管理のSAP Business Warehouse（BW）エクストラクター、Advanced Business Application Programming（ABAP）、Core Data Services（CDS）ビュー、その他の非ODPデータソースなどのSAPデータソースからのデータ取り込みとレプリケーションをサポートしています。Zero-ETLデータレプリケーションとスキーマ同期により、抽出されたデータを Amazon Redshift 、 Amazon SageMaker lakehouse アーキテクチャ 、 Amazon S3 Tables などのAWS環境に保存することを容易にし、手動でのパイプライン開発を減らします。これにより、 Amazon Q 、 Kiro 、 Amazon Quick Suite などのサービスと組み合わせて使用することで、自然言語クエリを使用してSAPデータを分析し、自動化のためのAIエージェントを作成し、エンタープライズデータランドスケープ全体でコンテキストに応じたインサイトを生成できる、AI駆動型インサイトの基盤が構築されます。 この記事では、さまざまなODPおよび非ODP SAPソースとのzero-ETL統合を作成および監視する方法を紹介します。 ソリューション概要 SAPとデータ連携する際の主要コンポーネントは、SAPデータ構造とプロトコルで動作するように設計された AWS Glue SAP ODataコネクタ です。このコネクタは、ABAPベースのSAPシステムへの接続を提供し、SAPのセキュリティとガバナンスフレームワークに準拠しています。AWS SAPコネクタの主な機能は以下の通りです: ODataプロトコルを使用して、さまざまなSAP NetWeaverシステムからデータ抽出 BWエクストラクター（2LIS_02_ITMなど）やCDSビュー（C_PURCHASEORDERITEMDEXなど）などの複雑なSAPデータモデルを、管理された形でレプリケーション SAP変更データキャプチャ（CDC）テクノロジーを使用したODPおよび非ODPエンティティの両方への対応 SAPコネクタは、AWS Glue StudioまたはAWS管理のzero-ETLレプリケーションの両方で動作します。 AWS Glue Studio でのセルフマネージドレプリケーションは、データ処理ユニット、レプリケーション頻度、価格パフォーマンスの調整、ページサイズ、データフィルター、宛先、ファイル形式、データ変換、および選択したランタイムでの独自コードの記述をコントロールできる環境です。zero-ETLでのAWS管理データレプリケーションは、カスタム設定の負担を取り除き、AWS管理の代替手段を提供し、15分から6日間のレプリケーション頻度を可能にします。以下のソリューションアーキテクチャは、さまざまなSAPソースからzero-ETLを使用してODPおよび非ODP SAPデータを取り込み、Amazon Redshift、SageMaker lakehouse、S3 Tablesに書き込むアプローチを示しています。 ODPソースの変更データキャプチャ SAP ODPは、SAPソースシステムからターゲットシステムへの増分データレプリケーションを可能にするデータ抽出フレームワークです。ODPフレームワークは、アプリケーション（サブスクライバー）がBWエクストラクター、CDSビュー、BWオブジェクトなどのサポートされているオブジェクトから増分的にデータを要求できるようにします。 AWS Glue zero-ETLデータ取り込みは、ターゲットシステムでベースラインデータセットを確立するために、エンティティデータの初期フルロードを実行することから始まります。初期フルロードが完了すると、SAPは削除を含むデータ変更をキャプチャするOperational Delta Queue（ODQ）として知られるデルタ（増分）キューをプロビジョニングします。デルタトークンは初期ロード中にサブスクライバーに送信され、zero-ETL内部の状態管理システム内に永続化されます。 増分処理は、状態ストアから最後に保存されたデルタトークンを取得し、ODataプロトコルを使用してこのトークンを使用してSAPにデルタ変更リクエストを送信します。システムは、SAP ODQメカニズムを通じて返されたINSERT/UPDATE/DELETE操作を処理し、レコードが変更されていないシナリオでもSAPから新しいデルタトークンを受信します。この新しいトークンは、取り込みが成功した後、状態管理システムに永続化されます。エラーシナリオでは、システムは既存のデルタトークン状態を保持し、データ損失なしで再試行メカニズムを可能にします。 以下のスクリーンショットは、SAPシステムでの成功した初期ロードとそれに続く4回の増分データ取り込みを示しています。 非ODPソースの変更データキャプチャ 非ODP構造は、ODP対応でないODataサービスです。これらは、ODPフレームワークなしで直接公開されるAPI、関数、ビュー、またはCDSビューです。このメカニズムを使用してデータが抽出されますが、増分データ抽出はオブジェクトの性質に依存します。たとえば、オブジェクトに「最終更新日」フィールドが含まれている場合、それを使用して変更を追跡し、増分データ抽出を提供します。 AWS Glue zero-ETLは、エンティティに変更を追跡するフィールド（最終更新日または時刻）が含まれている場合、非ODP ODataサービスに対してすぐに使える増分データ抽出を提供します。これらのSAPサービスに、zero-ETLはデータ取り込みに2つのアプローチを提供します:タイムスタンプベースの増分処理と完全ロードです。 タイムスタンプベースの増分処理 タイムスタンプベースの増分処理は、zero-ETLでユーザーが設定したタイムスタンプフィールドを使用して、データ抽出プロセスを最適化します。zero-ETLシステムは、後続の増分処理操作の基礎となる開始タイムスタンプを確立します。ウォーターマークとして知られるこのタイムスタンプは、データの一貫性を促進するために重要です。クエリ構築メカニズムは、タイムスタンプ比較に基づいてODataフィルターを構築します。これらのクエリは、最後に成功した処理実行以降に作成または変更されたレコードを抽出します。システムのウォーターマーク管理機能は、各処理サイクルから最高のタイムスタンプ値の追跡を維持し、この情報を後続の実行の開始点として使用します。zero-ETLシステムは、設定されたプライマリキーを使用してターゲットでアップサートを実行します。このアプローチは、データ整合性を維持しながら更新を適切に処理することを促進します。各ターゲットシステム更新が成功した後、ウォーターマークタイムスタンプが進められ、将来の処理サイクルのための信頼できるチェックポイントが作成されます。 ただし、タイムスタンプベースのアプローチには制限があります – SAPシステムは削除タイムスタンプを維持しないため、物理的な削除を追跡できません。タイムスタンプフィールドが利用できないか設定されていないシナリオでは、システムはアップサート処理を伴うフルロードに移行します。 フルロード（完全ロード） フルロードアプローチは、独立した（前後関係のない）処理として、またはタイムスタンプベースの処理が実行可能でない場合のフォールバックメカニズムとして機能します。この方法は、各処理サイクル中に完全なエンティティデータセットを抽出することを含み、変更追跡が利用できないか必要でないシナリオに適しています。抽出されたデータセットは、ターゲットシステムでアップサートされます。アップサート処理ロジックは、新しいレコードの挿入と既存レコードの更新の両方を処理します。 増分ロードまたはフルロードを選択するタイミング タイムスタンプベースの増分処理アプローチは、頻繁に更新される大規模なデータセットに対して最適なパフォーマンスとリソース使用率を提供します。変更されたレコードのみの選択的転送により、データ転送量が削減され、ネットワークトラフィックが削減されます。この最適化は、運用コストの削減に直接つながります。アップサートを伴うフルロードは、増分処理が実行可能でないシナリオでのデータ同期を促進します。 これらのアプローチは、非ODP SAP構造とのzero-ETL統合のための完全なソリューションを形成し、エンタープライズデータ統合シナリオの多様な要件に対応します。これらのアプローチを使用する組織は、2つのアプローチのいずれかを選択する際に、特定のユースケース、データ量、およびパフォーマンス要件を評価する必要があります。 SAP zero-ETL統合の監視 AWS Glueは、 Amazon CloudWatch ログを使用して状態管理、ログ、およびメトリクスを維持します。可観測性を設定する手順については、「 統合の監視 」を参照してください。ログ配信用に AWS Identity and Access Management （IAM）ロールが設定されていることを確認してください。統合は、ソース取り込みと選択したターゲットへの書き込みの両方から監視されます。 ソース取り込みの監視 AWS Glue zero-ETLとCloudWatchの統合により、データ統合プロセスを追跡およびトラブルシューティングするための監視機能が提供されます。CloudWatchを通じて、問題を特定し、パフォーマンスを監視し、SAPデータ統合の運用状態を維持するのに役立つ詳細なログ、メトリクス、およびイベントにアクセスできます。成功とエラーのシナリオのいくつかの例を見てみましょう。 シナリオ1: ロールに権限がない このエラーは、SAPデータへのアクセスを試みる際に、AWS Glueでのデータ統合プロセス中に発生しました。接続は、400 Bad Requestステータスコードを持つCLIENT_ERRORに遭遇し、ロールに権限がないことを示しています。 { "eventTimestamp": 1755031897157, "integrationArn": "arn:aws:glue:us-east-2:012345678901:integration:1da4dccd-96ce-4661-8ef1-bf216623d65f", "sourceArn": "arn:aws:glue:us-east-2:012345678901:connection/SAPOData-sap-glue-dev", "level": "ERROR", "messageType": "IngestionFailed", "details": { "loadType": "", "errorMessage": "You do not have the necessary permissions to access the glue connection. make sure that you have the correct IAM permissions to access AWS Glue resources.", "errorCode": "CLIENT_ERROR" } } シナリオ2: デルタリンクの破損 CloudWatchログは、SAPからAWS Glueへのデータ同期中にデルタトークンが欠落している問題を示しています。エラーは、ODataサービスを通じてSAP販売ドキュメント項目テーブルFactsOfCSDSLSDOCITMDXにアクセスしようとしたときに発生します。増分データロードと変更の追跡に必要なデルタトークンがないため、システムがデータ抽出API RODPS_REPL_ODP_OPENを開こうとしたときにCLIENT_ERROR（400 Bad Request）が発生しました。 { "eventTimestamp": 1760700305466, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:f62e1971-092c-46a3-ba88-d32f4c6cd649", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/SAPOData-sap-glue-dev", "level": "ERROR", "messageType": "IngestionFailed", "details": { "tableName": "/sap/opu/odata/sap/Z_C_SALESDOCUMENTITEMDEX_SRV/FactsOfCSDSLSDOCITMDX", "loadType": "", "errorMessage": "Received an error from SAPOData: Could not open data access via extraction API RODPS_REPL_ODP_OPEN. Status code 400 (Bad Request).", "errorCode": "CLIENT_ERROR" } シナリオ3: SAPデータ取り込みのクライアントエラー このCloudWatchログは、SAPエンティティEntityOf0VENDOR_ATTRがODataサービスを通じて見つからないか、アクセスできないクライアント例外シナリオを明らかにしています。このCLIENT_ERRORは、AWS GlueコネクタがSAPシステムからの応答を解析しようとしたが、エンティティがソースSAPシステムに存在しないか、SAPインスタンスが一時的に利用できないために失敗したときに発生します。 { "eventTimestamp": 1752676327649, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:9f1acbc0-599f-47d2-8e84-e9779976af59", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/SAPOData-sap-glue-dev", "level": "ERROR", "messageType": "IngestionFailed", "details": { "tableName": "/sap/opu/odata/sap/ZVENDOR_ATTR_SRV/EntityOf0VENDOR_ATTR", "loadType": "", "errorMessage": "Data read from source failed for entity /sap/opu/odata/sap/ZVENDOR_ATTR_SRV/EntityOf0VENDOR_ATTR using connector SAPOData; ErrorMessage: Glue connector returned client exception. The response from the connector application couldn't be parsed.", "errorCode": "CLIENT_ERROR" } } ターゲット書き込みの監視 Zero-ETLは、ターゲットシステムに応じた監視メカニズムを採用しています。Amazon Redshiftターゲットの場合、統合ステータス、ジョブ実行、およびデータ移動統計に関する詳細情報を提供するsvv_integrationシステムビューを使用します。SageMaker lakehouseターゲットを使用する場合、zero-ETLはzetl_integration_table_stateテーブルを通じて統合状態を追跡し、同期ステータス、タイムスタンプ、および実行の詳細に関するメタデータを維持します。さらに、CloudWatchログを使用して統合の進行状況を監視し、成功したコミット、メタデータの更新、およびデータ書き込みプロセス中の潜在的な問題に関する情報をキャプチャできます。 シナリオ1: SageMaker lakehouseターゲットでの処理成功 CloudWatchログは、CDCモードを使用したプラントテーブルの成功したデータ同期アクティビティを示しています。最初のログエントリ（IngestionCompleted）は、タイムスタンプ1757221555568での取り込みプロセスの成功した完了を確認し、最後の同期タイムスタンプは1757220991999です。2番目のログ（IngestionTableStatistics）は、データ変更の詳細な統計を提供し、このCDC同期中に300の新しいレコードが挿入され、8つのレコードが更新され、2つのレコードがターゲットデータベースglueetlから削除されたことを示しています。このレベルの詳細は、ターゲットシステムに伝播される変更の量とタイプを監視するのに役立ちます。 { "eventTimestamp": 1757221555568, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:b7a1c69a-e180-4d27-b71d-5fcf196d9d2d", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/mam301", "targetArn": "arn:aws:glue:us-east-1:012345678901:database/gluezetl", "level": "VERBOSE", "messageType": "IngestionCompleted", "details": { "tableName": "plant", "loadType": "CDC", "message": "Successfully completed ingestion", "lastSyncedTimestamp": 1757220991999, "consumedResourceUnits": "10" } } { "eventTimestamp": 1757222506936, "integrationArn": "arn:aws:glue:us-east-1:012345678901:integration:b7a1c69a-e180-4d27-b71d-5fcf196d9d2d", "sourceArn": "arn:aws:glue:us-east-1:012345678901:connection/mam301", "targetArn": "arn:aws:glue:us-east-1:012345678901:database/gluezetl", "level": "INFO", "messageType": "IngestionTableStatistics", "details": { "tableName": "plant", "loadType": "CDC", "insertCount": 300, "updateCount": 8, "deleteCount": 2 } } シナリオ2: Amazon SageMaker lakehouse ターゲットのメトリクス SageMaker lakehouseのzetl_integration_table_stateテーブルは、統合ステータスとデータ変更メトリクスのビューを提供します。この例では、テーブルは、testdbデータベースの統合ID 62b1164f-5b85-45e4-b8db-9aa7ab841e98を持つSAP CDSビューテーブルの成功した統合を示しています。レコードは、タイムスタンプ1733000485999で、10の挿入レコードが処理されたことを示しています（recent_insert_record_count: 10）、更新または削除はありません（両方のカウントは0）。このテーブルは監視ツールとして機能し、統合状態とデータ変更に関する詳細な統計の集中ビューを提供し、lakehouseでのデータ同期アクティビティを追跡および検証することを簡単にします。 +---+--------------------------------------+---------------+----------------------------------------------------------+-----------+--------+-----------------+-------------------------------+------------------------------+------------------------------+------------------------------+ | # | integration_id | target_database | table_name | table_state | reason | last_updated_timestamp | recent_ingestion_record_count | recent_insert_record_count | recent_update_record_count | recent_delete_record_count | +---+--------------------------------------+---------------+----------------------------------------------------------+-----------+--------+-----------------+-------------------------------+------------------------------+------------------------------+------------------------------+ | 2 | 62b1164f-5b85-45e4-b8db-9aa7ab841e98 | testdb | _sap_opu_odata_sap_zcds_po_scl_new_srv_factsofzmmpurordsldex | SUCCEEDED | | 1733000485999 | 10 | 0 | 0 | 0 | +---+--------------------------------------+---------------+----------------------------------------------------------+-----------+--------+-----------------+-------------------------------+------------------------------+------------------------------+------------------------------+ シナリオ3: Redshift用監視システムは、zero-ETL統合ステータスを追跡するために2つのビューを使用 svv_integrationは、統合ステータスの高レベルの概要を提供し、統合ID 03218b8a-9c95-4ec2-81ad-dd4d5398e42aが失敗なしで18のテーブルを正常にレプリケートし、最後のチェックポイントがトランザクションシーケンス1761289852999であったことを示しています。 +--------------------------------------+---------------+-----------+-----------------+-------------+----------------------------------------------+-------------------------+-----------------------+---------------+------------------+-----------------+-----------------+------------------+-----------------+-----------------+ | integration_id | target_database | source | state | current_lag | last_replicated_checkpoint | total_tables_replicated | total_tables_failed | creation_time | refresh_interval | source_database | is_history_mode | query_all_states | truncatecolumns | accept_invchars | +--------------------------------------+---------------+-----------+-----------------+-------------+----------------------------------------------+-------------------------+-----------------------+---------------+------------------+-----------------+-----------------+------------------+-----------------+-----------------+ | 03218b8a-9c95-4ec2-81ad-dd4d5398e42a | test_case | GlueSaaS | CdcRefreshState | 771754 | {"txn_seq":"1761289852999","txn_id":"0"} | 18 | 0 | 22:54.7 | 0 | | FALSE | FALSE | FALSE | FALSE | +--------------------------------------+---------------+-----------+-----------------+-------------+----------------------------------------------+-------------------------+-----------------------+---------------+------------------+-----------------+-----------------+------------------+-----------------+-----------------+ svv_integration_table_stateは、統合内の個々のテーブルのステータスを示すテーブルレベルの監視詳細を提供します。この場合、SAP材料グループテキストエンティティテーブルは同期済み状態にあり、最後のレプリケーションチェックポイントは統合チェックポイント（1761289852999）と一致しています。テーブルは現在0行と0サイズを示しており、新しく作成されたことを示唆しています。 +--------------------------------------+---------------+-------------+--------------------------------------------------------------+-------------+----------------------------------------------+--------+-----------------------+------------+------------+-----------------+ | integration_id | target_database | schema_name | table_name | table_state | table_last_replicated_checkpoint | reason | last_updated_timestamp | table_rows | table_size | is_history_mode | +--------------------------------------+---------------+-------------+--------------------------------------------------------------+-------------+----------------------------------------------+--------+-----------------------+------------+------------+-----------------+ | 03218b8a-9c95-4ec2-81ad-dd4d5398e42a | test_case | public | /sap/opu/odata/sap/ZMATL_GRP_1_SRV/EntityOf0MATL_GRP_1_TEXT | Synced | {"txn_seq":"1761289852999","txn_id":"0"} | | 23:03.8 | 0 | 0 | FALSE | +--------------------------------------+---------------+-------------+--------------------------------------------------------------+-------------+----------------------------------------------+--------+-----------------------+------------+------------+-----------------+ これらのビューは、Amazon Redshiftでの全体的な統合の健全性と個々のテーブル同期ステータスの両方を追跡するための包括的な監視ソリューションを提供します。 前提条件 以下のセクションでは、SAP接続を設定し、その接続を使用してzero-ETL統合を作成するために必要な手順を説明します。このソリューションを実装する前に、以下を準備する必要があります: SAPアカウント 管理者アクセス権を持つAWSアカウント S3 Tablesターゲット を作成し、S3バケットsap_demo_table_bucketをデータベースのロケーションとして関連付ける zero-ETLのData Catalogのきめ細かいアクセス制御のために、以下の IAMポリシー を使用して AWS Glue Data Catalog設定 を更新する zero-ETLがSAPアカウントからデータにアクセスするために使用するIAMロール zero_etl_bulk_demo_role を作成する SAP認証情報を保存するためにAWS Secrets Managerでシークレット zero_etl_bulk_demo_secret を作成する SAPインスタンスへの接続を作成 SAPインスタンスへの接続を設定し、アクセスするデータを提供するには、以下の手順を実行します: AWS Glueコンソールで、ナビゲーションペインのData catalogの下で、Connectionsを選択し、Create Connectionを選択します。 Data sourcesで、SAP ODataを選択し、 Next を選択します。 SAPインスタンスのURLを入力します。 IAM service roleで、ロールzero_etl_bulk_demo_role（前提条件として作成）を選択します。 Authentication Typeで、SAPに使用している認証タイプを選択します。 AWS Secretで、シークレットzero_etl_bulk_demo_secret（前提条件として作成）を選択します。 Nextを選択します。 Nameに、sap_demo_connなどの名前を入力します。 Nextを選択します。 zero-ETL統合を作成 zero-ETL統合を作成するには、以下の手順を実行します: AWS Glueコンソールで、ナビゲーションペインのData catalogの下で、Zero-ETL integrationsを選択し、Create zero-ETL integrationを選択します。 Data sourceで、SAP ODataを選択し、Nextを選択します。 前の手順で作成した接続名とIAMロールを選択します。 統合に含めるSAPオブジェクトを選択します。非ODPオブジェクトは完全ロードまたは増分ロード用に設定され、ODPオブジェクトは増分取り込み用に自動的に設定されます。 完全ロードの場合、Incremental update fieldをNo timestamp field selectedのままにします。 増分ロードの場合、Incremental update fieldの編集アイコンを選択し、タイムスタンプフィールドを選択します。 デルタトークンを提供するODPエンティティの場合、増分更新フィールドは事前に選択されており、ユーザーのアクションは必要ありません。 同じSAP接続とエンティティをデータフィルターで使用して新しい統合を作成する場合、最初の統合とは異なる増分更新フィールドを選択することはできません。 Target detailsで、sap_demo_table_bucket（前提条件として作成）を選択します。 Target IAM roleで、sap_demo_role（前提条件として作成）を選択します。 Nextを選択します。 Integration detailsセクションで、Nameにsap-demo-integrationと入力します。 Nextを選択します。 詳細を確認し、Create and launch integrationを選択します。 新しく作成された統合は、約1分でActiveとして表示されます。 クリーンアップ リソースをクリーンアップするには、以下の手順を実行します。このプロセスは、この記事で作成されたリソースを完全に削除します。続行する前に重要なデータをバックアップしてください。 zero-ETL統合 sap-demo-integration を削除します。 S3 Tablesターゲットバケット sap_demo_table_bucket を削除します。 Data Catalog接続 sap_demo_conn を削除します。 Secrets Managerシークレット zero_etl_bulk_demo_secret を削除します。 まとめ ここまでの手順で、従来のようなETL構築の複雑さなしに、SAPデータ分析を大きく改善できるようになりました。AWS Glue zero-ETLを使用すると、S3 Tables、SageMaker lakehouseアーキテクチャ、Amazon Redshiftに、元の構造を維持しながらデータを連携でき、SAPデータに即座にアクセス可能な環境を構築できます。チームは、コスト効率の高いクラウドストレージにデータを保持しながら、Apache Iceberg のタイムトラベル機能、スキーマ進化、および大規模な同時読み取り/書き込みを備えたACID準拠のストレージを使用できます。Amazon QとSageMaker等のAI機能は、ビジネスがオンデマンドデータ製品を作成し、テキストからSQLへのクエリを実行し、Amazon BedrockとQuick Suiteを使用してAIエージェントをデプロイするのに役立ちます。 詳細については、以下のリソースを参照してください: AWS Glue Documentation Zero-ETL integrations Connecting to SAP OData Amazon SageMaker lakehouse アーキテクチャ Amazon S3 tables をターゲットとして設定する Amazon Q Documentation Amazon Quick Suite Documentation SAPデータ戦略を近代化する準備はできていますか？AWS Glue zero-ETLを探索し、組織のデータ分析機能を強化しましょう。 著者について Shashank Sharma Shashank は、エンタープライズ顧客向けのファーストパーティおよびサードパーティのデータベースとSaaSのデータ統合およびレプリケーションソリューションの提供において15年以上の経験を持つエンジニアリングリーダーです。彼はAWS Glue Zero-ETLとAmazon AppFlowのエンジニアリングをリードしています。 Parth Panchal Parth は、10年以上の開発経験を持つ経験豊富なソフトウェアエンジニアで、AWS Glue zero-ETLとSAPデータ統合ソリューションを専門としています。彼は、複雑なデータレプリケーションの課題に深く取り組み、パフォーマンスと信頼性の高い基準を維持しながらスケーラブルなソリューションを提供することに優れています。 Diego Lombardini Diego は、SAPテクノロジー全体で20年以上の経験を持つ経験豊富なエンタープライズアーキテクトで、SAPイノベーションとデータおよび分析を専門としています。彼はパートナーとユーザーの両方として働いてきたため、システムと組織を販売、実装、運用するために必要なことについて完全な視点を持っています。彼はテクノロジーとイノベーションに情熱を持ち、顧客の成果とビジネス価値の提供に焦点を当てています。 Abhijeet Jangam Abhijeet は、複数の業界にわたる戦略と提供をリードする20年のSAP技術機能経験を持つデータおよびAIリーダーです。数十のSAP実装経験により、彼はアプリケーション開発、データエンジニアリング、統合における深い技術的専門知識とともに、幅広い機能プロセス知識をもたらします。 翻訳： 下佐粉 昭 (AWS Japan ソリューションアーキテクト)

AWS re:Invent の翌週は、イベントのエキサイトメントとエネルギーがますます熱くなる週であり、詳細について学び、最新の発表が課題の解決にどのように役立つかを理解するすばらしい機会です。今回も、 AWS re:Invent 2025 の注目の発表 に関する記事をご用意しました。 すべての技術的発表の中でも私にとってとりわけ印象的だったのは、フィリピンの Rafi (Raphael Francis Quisumbing) が ワーナー ヴォゲルス から Now Go Build 賞を受け取った瞬間でした。2015 年に AWS ヒーローになった Rafi は、2013 年から AWS User Group Philippines の共同主導者を務めています。この地域全体でのコミュニティの構築と開発者のエンパワーメントに対する彼の献身は、この賞の真髄を体現するものです。Rafi の詳細については、 The Kernel をお読みください。おめでとう、Rafi! 基調講演のまとめ: エージェント、ルネサンス、開発者の役割 2025 年の AWS re:Invent の基調講演は、私たちが向かっている方向を明確に示していました。 マット ガーマン は、開発者が「AWS の核心」であり、20 年たった今でも「革新する自由」が AWS の中核的使命であることを強調しました。次の変曲点として AI エージェントに焦点を当てたマットは、「AI アシスタントは、ユーザーに代わってタスクを実行したり自動化したりすることができる AI エージェントへと移行し始めています。こうした移行の中で、AI 投資からの実質的なビジネス利益を目の当たりにし始めています」と述べました。 Swami Sivasubramanian  は、私たちが経験している変革的瞬間を強調し、「何を達成したいのかを自然言語で説明できる、これは歴史上初めてのことです。すると、エージェントがプランを生成します。エージェントがコードを記述し、必要なツールを呼び出して、ソリューション全体を実行するのです」と話しました。 AWS は、信頼性が高く、セキュアでスケーラブルな本番環境対応インフラストラクチャを構築しています。これは、エージェントの非決定的な性質に合わせて構築されたものです。 Peter DeSantis と Dave Brown  は、この AI 時代において、AWS が 20 年にわたってこだわり続けてきたコア属性であるセキュリティ、可用性、パフォーマンス、伸縮性、コスト、俊敏性がこれまで以上に重要であることを強調しました。Dave Brown は、これらの属性を大規模に実現する Graviton と AWS のカスタムシリコンイノベーションを紹介しました。 14 年の歴史に終止符を打ち、最後の基調講演を行った ワーナー ヴォゲルス は、好奇心とシステム思考を持ち、効果的にコミュニケーションを取る開発者を表す「ルネサンス開発者」という概念を紹介しました。AI と開発者の進化に関する彼のメッセージは参加者の共感を呼ぶもので、「AI は私の仕事を奪うのか? そうかもしれません。AI は私を陳腐化するのか? 皆さんが進化するのなら、それは絶対にありません」と述べました。 また、開発者は所有者でなければならないことも強調し、「仕事はあなたのものであり、ツールのものではありません。ツールを作り、所有するのはあなたです」と話しました。 基調講演、イノベーショントーク、ブレイクアウトセッションなどは、 オンデマンド動画ページ でもご覧いただけます。 イノベーショントーク Harnessing analytics for humans and AI (INV201) AI agents in action: Architecting the future of applications (INV202) The agent-enabled workplace: Transforming businesses with AI (INV203) Build and scale AI: from reliable agents to transformative systems (INV204) Reinventing software development with AI agents (INV205) Unlocking possibilities with AWS Compute (INV207) Databases made effortless so agents and developers can change the world (INV208) The next frontier: Building the agentic future of Financial Services (INV209) Infrastructure for the impossible: Turning public sector barriers into breakthroughs (INV210) Behind the curtain: How Amazon’s AI innovations are powered by AWS (INV211) Migrate, modernize, and move your business into the AI era (INV212) The power of cloud network innovation (INV213) Intelligent security: Protection at scale from development to production (INV214) AWS storage beyond data boundaries: Building the data foundation (INV215) ブレイクアウトセッション – トピック ブレイクアウトセッション – 分野 分析 アプリケーション統合 アーキテクチャ AI ビジネスアプリケーション クラウド運用 コンピューティング データベース 開発者ツール エンドユーザーコンピューティング ハイブリッドクラウドとマルチクラウド 業界ソリューション 移行とモダナイズ ネットワークとコンテンツ配信 オープンソース セキュリティとアイデンティティ サーバーレスとコンテナ ストレージ 開発者コミュニティ デジタルネイティブビジネス エンタープライズ 独立系ソフトウェアベンダー AWS 初心者 パートナーイネーブルメント 公共部門 シニアリーダー 中堅・中小企業 スタートアップ 2025 年 11 月 30 日週のリリース 以下に、私が注目したリリースで、 AWS re:Invent 2025 の注目の発表 記事ではまだ取り上げていないものをご紹介します。 Kiro Autonomous Agent – AWS は、11 月にチーム機能とともに一般提供が開始された Kiro を基礎とする自律型エージェントを発表しました。このエージェントは、セッション全体でアウェアネスを維持し、プルリクエストとフィードバックから学習して、複数のリポジトリにまたがるバグトリアージとコードカバレッジの改善に対応します。マット ガーマンは、第 1 世代の AI コーディングツールよりも「桁違いに効率的」だと言っています。現在、Kiro は Amazon 社全体での標準 AI 開発環境として使用されています。 Bedrock ナレッジベースのマルチモーダル検索 (一般提供) – テキスト、画像、音声、動画ファイル全体で機能する AI 駆動の検索アプリケーションや質問回答アプリケーションを構築できます。開発者は、解析、チャンク化、埋め込み、ベクトルストレージのオプションを完全に制御しながらマルチモーダルコンテンツを取り込み、テキストクエリまたは画像クエリを送信して、あらゆるメディアタイプから関連するセグメントを取得できるようになりました。 AWS Interconnect – マルチクラウド (プレビュー) – 専用帯域幅と組み込みのレジリエンスを用いて、Amazon VPC やその他のクラウド環境の間にセキュアかつ高速なプライベート接続をすばやく確立します。このプレビューは Google Cloud を最初のローンチパートナーとして開始され、2026 年には Microsoft Azure のサポートが追加される予定です。 この記事で取り上げられていないその他のリリースニュースについては、 AWS の最新情報 をご覧ください。 今週のニュースは以上です。来週月曜日の次回 Weekly Roundup もお楽しみに! ハッピービルディング! – Donnie この記事は、 Weekly Roundup シリーズ の一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は 2025/11/25 に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 5 – How the service uses clocks を翻訳した記事です。 Amazon Aurora DSQL  は、アクティブ-アクティブの分散データベース設計を採用しており、リージョン内およびリージョン間で、 すべてのデータベースリソースが等しく読み取りと書き込みの両方のトラフィックを処理します。この設計により、 シングルおよびマルチリージョンの Aurora DSQL クラスターにおいて 同期データレプリケーションとデータ損失ゼロの自動フェイルオーバーが 可能になります。 Aurora DSQL に関する5部構成の本シリーズでは、これまでに 基本概念 、 機能と注意点 、Aurora DSQL における トランザクションの動作 、そして 個々のコンポーネント について説明しました。今回の投稿では、Amazon Aurora DSQL が  Amazon Time Sync Service  を使用してどのようにハイブリッド論理クロックソリューションを構築しているのかを探ります。 Aurora DSQL がリージョン内およびリージョン間で広範な調整なしにスケーラブルな方法で動作できる能力は、Amazon Time Sync Service の活用とその上に構築されたハイブリッド論理クロックソリューションの構築によるものです。 分散システムにおけるハイブリッド論理クロックの重要性 物理クロックは直感的で私たちの自然な時間認識に合致していますが、分散システムでは同期に課題があります。一方、 Lamport タイムスタンプ のような論理クロックは因果関係の追跡に優れていますが、実世界のタイミング要件を満たすのに苦労します。 ハイブリッド論理クロック（HLC） は、両方のアプローチの利点を調和させる洗練されたソリューションを提供します。Aurora DSQL では、HLC は次のように動作します： システムは物理クロックと論理クロックの両方のコンポーネントを維持します クロック値は各読み取り操作の前に更新されます 物理クロックがより速いペースで動作する場合（典型的なシナリオ）、論理時間が同期するよう進みます 逆に、物理クロックが遅れている場合、論理時間はおおよそ物理クロックのレートで進行します このハイブリッドアプローチにより、物理的な現実との強い結びつきを維持しながら、時間が後退することがないよう保証されます。 CockroachDB  や  MongoDB  などの他の分散データベースも、時間管理のニーズにハイブリッドクロックを採用しており、Aurora DSQL におけるこのアプローチの関連性を示しています。HLC には以下のようないくつかの利点があります： 一貫性の保証 – クライアントが複数のデータベースノードからデータを読み取る場合、HLC はデータの一貫したビューを保証します。これにより、Aurora DSQL は同期の必要なく複数のリージョンにあるストレージノードから読み取ることができます。 トランザクション管理 – 各トランザクションは開始タイムスタンプとコミットタイムスタンプを受け取り、これらの値に基づいて信頼性の高い競合検出を容易にします。 読み取り専用トランザクションの線形化可能性（linearizability） 実際には、クロック同期は完璧ではありません。現代のシステムはこの現実に対処するために洗練されたエラー境界追跡を採用しています。Amazon EC2 の clockbound API からの時間測定には、現在時刻の推定値、上限エラー境界、下限エラー境界が含まれます。これにより 3 つの時間間隔が区別されます：既知の過去（エラー境界以下）、未知の現在（エラー境界内）、そして既知の未来（エラー境界以上）。QP は上限エラー境界を選択することで、ストレージからリクエストするデータにコミット済みのすべてのトランザクションが含まれることを保証します。これが読み取り専用トランザクションが線形化可能である理由です。これにより、オペレーションがシステム内での並列性なしに、一貫したリアルタイム順序で実行されるように見えることが保証されます。 Amazon Aurora DSQL におけるトランザクションタイミングの理解 Aurora DSQL は、トランザクションタイムスタンプの洗練された処理を通じて強力な一貫性保証を提供しています。システムがどのようにトランザクションタイミングを管理して線形化可能性（linearizability）を確保するか ー つまり、トランザクション B がトランザクション A のコミット後に開始される場合、B はつねに A の変更を見ることができるということ ー を探ってみましょう。この概念は読み書きトランザクションのみを対象に探っていきます。なぜなら、このシリーズの第 3 回で説明したように、読み取り専用トランザクションは論理的な時間がゼロであり、このタイプのトランザクションにはこの概念は必要ないからです。 トランザクションが開始されると、QP は未来にあることが保証されている開始タイムスタンプ（τ-start）を割り当てます。トランザクション内のあらゆる読み取りに対して、このタイムスタンプがストレージに渡され、読み取り操作を実行する前にすべての先行トランザクションが処理されていることを確認します。 トランザクションのコミット中： アジュディケータがコミットタイムスタンプ（τ-commit）を割り当てます。 QP は、ユーザーにコミットを確認する前に、このタイムスタンプが検証可能な過去にあることを確認します。 実際の例 2 つの連続するトランザクション、A と B の流れを見てみましょう： トランザクション A が開始： 開始タイムスタンプ τ3 が割り当てられます このトランザクション内のすべてのアクションは、一貫したビューを確保するためにこのタイムスタンプを使用します コミット時に、タイムスタンプ τ5 を受け取ります システムは、コミットを確認する前に τ5 が検証可能な過去になるまで待機します トランザクション B（A のコミット後）が開始： A のコミットタイムスタンプより大きいことが保証される開始タイムスタンプが割り当てられます これにより B は常にAの変更を見ることができます システムは、クロックの不確実性がタイミングの異常を引き起こす可能性があるシナリオを慎重に管理する必要があります。例えば、トランザクション A が広いタイムスタンプウィンドウを取得し、トランザクション B がより狭いウィンドウを取得した場合、B が A のコミット後に開始したにもかかわらず、B の開始タイムスタンプが A のものより小さくなるリスクがあります。 このような異常を防ぐため、Aurora DSQLは追加のセーフガードを実装しています：QP は、τ-start と τ-commit のタイムスタンプ境界が過去にあることが検証されるまでクライアントへの応答を遅らせます。 トランザクションタイミングに対するこの堅牢なアプローチにより、Aurora DSQL は分散環境で高いパフォーマンスを維持しながら、強力な一貫性保証を提供することができます。 Amazon Time Sync Service を使用したタイミング情報の提供 分散システムにおける時間同期は、特に複数のリージョンにまたがる場合、非常に複雑な問題として知られています。Aurora DSQL はこの課題に対して、 Amazon Time Sync Service を使用することで対処しています。このサービスはすべての EC2 インスタンスからアクセス可能で、GPS 衛星と同期した原子時計を使用してマイクロ秒レベルの精度を実現します。この精度レベルは、グローバルに分散したノード間で強力な一貫性を維持するために不可欠です。論理クロックのみに依存する従来のアプローチやNetwork Time Protocol（NTP）などのプロトコルとは異なり、Aurora DSQL のハイブリッドモデルは因果関係と実世界の整合性の両方を提供します。このイノベーションはトランザクションの整合性を向上させるだけでなく、グローバルな書き込み時のレイテンシーも最小化し、Aurora DSQL を業界内で際立たせています。 ユースケースの可能性 ハイブリッド論理クロックシステムは、複数の業界で Aurora DSQL に新たな可能性をもたらします。例えば、金融機関はトランザクションの保証された線形化可能性の恩恵を受け、正確な監査証跡と規制遵守を確保できます。同様に、複数のリージョンにまたがって運営される e コマースプラットフォームは、一貫した在庫管理とリアルタイムの注文処理のために Aurora DSQL に依存することができます。 まとめ この投稿では、Amazon Aurora DSQL におけるハイブリッドクロックモデルの活用について探りました。このモデルは Amazon Time Sync Service を活用してグローバルな強力な一貫性を保証しています。Aurora DSQL についてさらに詳しく知りたい場合は、AWS re:Invent 2024 の 入門 および 詳細解説 の録画、または Marc Brooker の ブログシリーズ をご参照ください。 Katja-Maja Kroedel Katja  は AWS でデータベースと IoT の熱心なアドボケイトです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、および戦略に関するガイダンスをお客様に提供しています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。