本ブログは 2025 年 6 月 19 日に公開された Blog ” How to prioritize security risks using AWS Security Hub exposure findings ” を翻訳したものです。 re:Inforce 2025 で、AWS は強化された AWS Security Hub を発表しました。これにより、組織がクラウド環境を保護するために、重大なセキュリティ問題を大規模に優先順位付けして対応する方法を変革できます。本ブログ記事では、Security Hub の 露出の検出結果 機能を使用して、これらの問題に優先順位を付ける方法を説明します。強化された Security Hub は、高度な分析を使用して、クラウド環境全体のセキュリティシグナルを自動的に関連付け、補強し、優先順位付けを行います。Security Hub は、 Amazon GuardDuty 、 Amazon Inspector 、 Amazon Macie 、および以前は AWS Security Hub として知られていた AWS Security Hub Cloud Security Posture Management (CSPM) とシームレスに統合されています。この統合を通じて、Security Hub は総合的な脅威検出と脆弱性評価を提供します。このインテリジェントな統合により、組織は認証情報侵害の可能性から意図しないリソースの露出まで重大なセキュリティ問題を迅速に特定し、セキュリティチームは最も重要な事項に集中できるようになります。 Security Hub の概要 Security Hub は、統合されたクラウドセキュリティソリューションを通じて、クラウドのセキュリティ体制を強化するための 3 つの重要なセキュリティ機能を提供します。 一元管理と継続的なモニタリングを通じて、組織全体の可視性を提供します。 Amazon Inspector や AWS Security Hub CSPM などのサービスから送られるセキュリティシグナルに情報を付加することで、お客様の環境に特有のアクティブなリスクを表面化させます。それにより、自信を持って優先順位付けを行い、対応を効率化できるようになります。 Amazon Inspector、AWS Security Hub CSPM、Amazon Macie、およびその他の AWS サービスからの検出結果を関連付けます。それにより、潜在的な攻撃経路の特定、悪用可能な脆弱性や不適切な設定の発見、および実行可能な修復手順の提供を支援する、統合リスク分析を提供します。 お客様の最大の関心事は、「どこから優先的に対応すべきか」を判断する方法です。セキュリティの検出結果が個別に表示されると、複数のアカウントやリージョンにまたがる大量の検出結果を管理しづらくなり、真の優先順位や影響を判断することが難しくなります。Security Hub では、コンテキストに基づく分析を提供することでこの問題を解決します。脆弱性、脅威、不適切な設定を関連付けることで悪用可能な経路を明らかにし、最も重大なリスクを表面化させます。これにより、どの問題から優先的に対処すべきかについて、十分な情報に基づいた判断を下すことができます。 露出の検出結果を参照することで、重大なセキュリティ問題の優先順位付けと対応を、大規模に行うことが可能になります。露出は、Security Hub CSPM、脆弱性をスキャンする Amazon Inspector、機密データの検出と保護を行う Amazon Macie からの検出結果と特性の分析に基づいています。これらは潜在的なセキュリティ問題として定義され、さまざまな露出の特性によって生成されます。 自動的な関連付けと補強されたシグナルが無い場合、セキュリティチームは問題の優先順位付けを効率的に行うことが難しくなります。例えば、Amazon Inspector が検出した脆弱性は、Security Hub CSPM が特定した不適切な設定と組み合わさることで、極めて重大になる可能性があります。しかし、何千ものシグナルの関係を手動で分析することは時間がかかり、重大なセキュリティコンテキストを見逃しやすくなります。これに対応するためにカスタムソリューションを構築するチームもありますが、このアプローチでは分析担当者の時間と保守作業が大幅に必要となり、重大なセキュリティの関連性が見落とされる可能性があります。 Security Hub は、統合されたクラウドセキュリティセンターにおいて、これらの AWS サービス間をネイティブに統合することで、ログの収集と集約のオーバーヘッド無しに、この複雑さを軽減します。これによりセキュリティチームは、個々のセキュリティシグナルを手動で組み合わせることに貴重な時間を費やすことなく、重大な露出がビジネスに影響を与える前に、それらを特定し対応できるようになります。自動化された関連付けと強化されたコンテキストにより、どこに労力を集中させるべきかについて、より迅速で十分な情報に基づいた意思決定を行うことができます。これにより、最終的にクラウド環境をより効果的に保護することができます。 露出の検出結果は、セキュリティ体制に対する総合的な視点を提供することで、環境内のセキュリティリスクを特定します。これらの検出結果により、潜在的なリスクを理解し対処することができます。この統合的なアプローチを通じて、最も重大な露出の検出結果に最初に焦点を当てることで、修復作業の優先順位付けを効率的に行うことができます。 露出の検出結果は、 Open Cybersecurity Schema Framework (OCSF) スキーマでフォーマットされています。これは、セキュリティツール間でシームレスにデータを共有できるオープンソースの標準です。Security Hub が OCSF を採用していることによるメリットはいくつかあります。Linux Foundation の一部であるオープンで標準化されたスキーマとして、OCSF は AWS 環境内外の複数のセキュリティツールやサービス間の相互運用性を可能にします。一貫したフィールドの命名とカテゴリ分けにより、強化されたデータの正規化を提供することで、サードパーティのセキュリティツールとの統合がより容易になります。 Security Hub の検出結果を受信できる OCSF スキーマをサポートしている、またはサポートする予定のパートナーには、次の企業が含まれています: Arctic Wolf、CrowdStrike、Comcast の DataBee、Datadog、DTEX Systems、Dynatrace、Fortinet、IBM、Netskope、 Orca Security 、Palo Alto Networks、Rapid7、Securonix、 SentinelOne 、Sophos、Splunk、Cisco Company、 Sumo Logic 、 Tines 、Trellix、 Wiz 、Zscaler。さらに、 Accenture 、Caylent、 Deloitte 、IBM、 Optiv などのサービスパートナーが、Security Hub と OCSF スキーマの導入を支援できます。 セキュリティリスクの優先順位付け Security Hub に移動すると、図 1 に示す露出の概要ウィジェットを含む、概要ダッシュボードが表示されます。このウィジェットには、露出の重大度と数が表示されます。Security Hub は各露出の検出結果に、重要 (Critical)、高 (High)、中 (Medium)、または低 (Low) のデフォルトの重大度を割り当てます。重大度が情報 (Informational) の検出結果は表示されません。 Security Hub は、AWS サービス全体にわたる複数のセキュリティ特性を分析および関連付けることで、露出の検出結果の重大度を計算します。Security Hub はこれらの要素を個別に評価するのではなく、コンテキストに基づくアプローチを使用し、各要素がどのように相関しているかに基づいて重大度を割り当てています。例えば、脆弱性が検知されたリソースがあった場合に、インターネットから悪用可能であったり機密データへのアクセス権を持っていたりすると、より高い重大度となる可能性があります。 Security Hub は、露出の検出結果のデフォルト重大度を決定するために、いくつかの要素を使用します。 発見のしやすさ – ポートスキャンやインターネット検索など、リスクのあるリソースを発見するための自動ツールの利用可能性。 悪用のしやすさ – 脅威アクターがリスクを悪用できる容易さ。例えば、オープンなネットワークパスや誤って設定されたメタデータがある場合、脅威アクターはより迅速にリスクを悪用できます。 悪用の可能性 – Security Hub は、脆弱性が悪用される確率を推定するデータ駆動型スコアリングシステム Exploit Prediction Scoring System (EPSS) などの外部シグナルと、内部の脅威インテリジェンスの両方を使用して、リスクが悪用される確率を判断します。この包括的なアプローチは、 Amazon Elastic Compute Cloud (EC2) インスタンスと AWS Lambda 関数の露出の検出結果に適用されます。 認知度 – リスクが単なる理論上のものではなく、どの程度公になっているか、あるいは、自動化されたエクスプロイト (攻撃手法) が存在しているか。この要素は EC2 インスタンスと Lambda 関数の露出の検出結果に適用されます。 影響 – エクスプロイトが実行された場合の潜在的な被害。例えば、露出によって、データ漏洩による機密性の喪失、データ破損による完全性の喪失、可用性の喪失、または説明責任の喪失につながる可能性があります。 このウィジェットのリスク一覧は、重大な検出結果の数が最も多い上位 8 つのリスクに絞って表示されます。2 つ以上のリスクで重大な検出結果の数が同じ場合、それらの検出結果は自動的に、より最近の重大な検出結果の後ろにグループ化されてリストに表記されます。 図 1: 露出の概要ウィジェット このウィジェットから露出のダッシュボードに移動すると、潜在的なセキュリティ問題の継続的な分析のために、事前にフィルタリングされた露出のビューを確認できます。各重大度に関連付けられた数字を選択して重大度でフィルタリングしたり、リストから選択して特定の露出の検出結果を表示したり、[ すべての露出検出結果を表示 ] を選択して図 2 に示す新しい露出のダッシュボードを表示したりすることができます。 図 2: 露出のダッシュボード 露出のコンソールでは、検出結果をタイトル別に、重大度の高い順に表示しています。これはフィルター条件によって整理され、検出結果のタイトルでグループ化されています。図 2 に示すように、左側に表示される [ クイックフィルター ] では、重大度、全体の中で検出結果が多いトップ 10 の属性、トップ 10 のアカウント、トップ 10 のリソースタイプに基づいて、露出の検出結果を迅速にフィルタリングする方法を提供します。フィルターの使用に加えて、[ グループ化条件 ] のドロップダウンを使用することで、AWS アカウント ID、リソースタイプ、製品名など特定の属性で露出の検出結果をグループ化することもできます。 露出の検出結果をレビューするには、図 3 に示すように検出結果を展開し、ソフトウェアの脆弱性、不適切な設定、到達可能性などのリソース、ステータス、属性、および特性の相関関係を表示します。これらは特性タイプとも呼ばれます。特定の露出の検出結果では、特性は 1 つ以上のシグナルに関連付けられ、シグナルは 1 つ以上の指標を含むことができます。 図 3: 露出の検出結果 図 3 に示すように、[ Potential Credential Stealing: Internet reachable EC2 instance with administrative instance profile has network-exploitable software vulnerabilities with a high likelihood of exploitation ] という検出結果は、そのインスタンスに不適切な設定、脆弱性、および到達可能性 (リソースへのオープンなネットワーク経路があることの示唆) が関連することを示しています。リスクに関連する行の任意の場所を選択すると、図 4 に示す概要パネルが表示され、このシグナルについてより詳しい情報を参照することができます。 図 4: 露出の検出結果の概要 この例では、us-east-1 リージョンにあるインターネットからアクセス可能な EC2 インスタンスのソフトウェア脆弱性に関する重大度が [重要] である検出結果を示しています。この可視化が強力なのは、[ 潜在的な攻撃パス ] の図を参照することで、潜在的な脅威アクターがこれらの脆弱性をどのように悪用してリソースにアクセスする可能性があるかをマッピングして、重要なポイントを把握するのに役立つからです。この検出結果には、リソース識別子、作成時間、到達可能性、脆弱性、および不適切な設定などの重要なメタデータも含まれています。 この検出結果を使用することで、複雑なセキュリティの関連性をすばやく理解し、リスクの状況を評価し、修復の優先順位を決定できます。それにより、クラウド内のワークロードをより適切に保護し、より情報に基づいたセキュリティの意思決定を行うことができるようになります。セキュリティの対応に優先順位を付けるために、検出結果の重大度レベルを調整したり、ステータスを更新したり、OCSF 形式で検出結果をエクスポートしたりすることもできます。 露出の検出結果が表示されている理由を確認するために、図 5 に示すように [ 特性 ] タブを選択します。これにより、 不適切な設定 や 脆弱性 などの特性が一覧表示されます。[ 特性 ] タブで [ シグナル別 ] を選択すると、露出の検出結果に関連する全シグナルが一覧表示されます。これらのシグナルは、Security Hub CSPM や Amazon Inspector などのさまざまなサービスから作成された根本的な検出結果であり、それらが関連付けられて露出の検出結果に関連するリスクが判断されます。 図 5: 露出の検出結果の特性タブ [ リソース ] タブを選択すると、図 6 に示すように、露出の検出結果に関連するリソースが表示されます。 図 6: 露出の検出結果のリソースタブ 表示されるリソースは 1 つだけとは限らず、EC2 インスタンス、 Amazon Simple Storage Service (Amazon S3) バケット、 AWS Identity and Access Management (IAM) ロールなど複数リソースの組み合わせで表示される場合もあります。このリソースのリストは、検出結果に起因するリスクを軽減するために、お客様の環境で何を修復する必要があるかを判断するのに役立ちます。 最後に、[ チケット作成 ] のオプションを使用することで、Security Hub は Atlassian の Jira Service Management や ServiceNow などの人気のあるサービス管理システムとネイティブに統合し、インシデント管理プロセスを効率化できます。この統合により、手動でのチケット作成の必要性が最小限に抑えられ、セキュリティ問題の発見から修復までの時間を短縮することができます。組織は Security Hub 自動化ルール を使用して、Security Hub コンソールから直接セキュリティ検出結果のチケットを自動作成して追跡でき、重大なセキュリティの露出が未対応のまま放置されないようにするのに役立ちます。これらの広く使用されているサービス管理システムとの統合により、一貫したワークフローの維持、修復作業の追跡がしやすくなり、セキュリティチームと運用チームのコラボレーションもより行いやすくなります。このように、検出から解決までの効率的な道筋を提供することで、セキュリティ運用の効率化を図ることができます。 まとめ Security Hub の強化された露出の検出機能は、組織がクラウド環境を安全に保つ方法を大きく進歩させることができます。複数の AWS サービスを通してセキュリティシグナルを自動的に関連付けて分析することで、Security Hub はお客様が最も重大なセキュリティ問題が何であるかを、自信を持って大規模に優先順位付けして対応するのに役立ちます。潜在的な攻撃パスを直感的に可視化し、インテリジェントな重大度ランキングと総合的な特性分析を提供することで、リスクの優先順位付けについてセキュリティチームがデータに基づく意思決定を行うことを可能にします。 Security Hub の露出の検出結果は、組織がセキュリティ体制を発生ベース型から事前予防型へ、以下の方法で移行するのに役立ちます。 パブリックにアクセス可能となっているリソースを自動的に発見して評価する セキュリティの機能と設定について明確な可視性を提供する 複数のセキュリティシグナルを関連付けて、重大なリスクを特定する 実行可能な修復手順を提示する 効率的な分析のための直感的なフィルタリングとグループ化オプションを提供する クラウド環境が複雑化し続ける中、露出の検出機能は、潜在的なセキュリティの問題を前もって対応するために必要な自動化、インテリジェンス、コンテキストを提供します。これにより、セキュリティチームは重大なリスクへの対応に貴重な時間を集中して使えるようになり、最終的に組織がクラウド環境全体でより強固なセキュリティ体制を維持するのに役立ちます。 小規模な開発環境または大規模なエンタープライズ環境のどちらを管理している場合でも、Security Hub の露出の検出結果は、AWS ワークロードを効果的に保護し、進化し続ける周辺環境の中で強固なセキュリティ体制を維持するために必要な洞察を提供します。 本ブログ記事に関するフィードバックがございましたら、 翻訳元ブログ の Comments 欄にコメントを投稿してください。本ブログ記事に関する質問がある場合は、 AWS Security, Identity, and Compliance re:Post で新しいスレッドを開始するか、 AWS サポート までお問い合わせください。 Shahna Campbell Shahna は AWS のソリューションアーキテクトで、セキュリティにフォーカスしたスペシャリストチームで働いています。以前は、臨床のヘルスケア分野でアプリケーションスペシャリストとして働いていました。Shahna はサイバーセキュリティと分析の分野に情熱を持っています。彼女は自由時間に、ハイキング、旅行、そして家族と過ごすことを楽しんでいます。 Marshall Jones Marshall は AWS のワールドワイドセキュリティスペシャリストソリューションアーキテクトです。彼のバックグラウンドには AWS コンサルティングとセキュリティアーキテクトがあり、エッジセキュリティ、脅威検知、コンプライアンスなどさまざまなセキュリティ領域に焦点を当ててきました。現在は、AWS のエンタープライズのお客様が AWS セキュリティサービスを採用および運用可能にし、セキュリティの効果を高めてリスクを軽減できるよう支援することに注力しています。 Kimberly Dickson Kimberly はシンガポールを拠点とする AWS のセキュリティスペシャリストソリューションアーキテクトです。彼女は、お客様が自信を持って安全にクラウドでの運用を行えることを支援する技術的なセキュリティソリューションについて、お客様と協力して働くことに情熱を持っています。 本ブログは Solutions Architect の 泉 航 が翻訳しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。6月25日、26日に開催された AWS Summit 2025 に参加された方も多いのではないでしょうか？私も2日間ブースに立たせていただき、たくさんの学びと刺激を得ることができました。この場を借りて、お忙しい中ご参加頂いた皆様と運営に関わられた皆様に感謝申し上げます。 さて、最近生成AI関連の自己学習リソースが本当に充実してきました。特に注目なのが、先日リリースされた AWS Builder Center ！ これまでの community.aws が進化する形でローンチされた、新しい学習ポータルです。技術スキルの向上をサポートしてくれるプラットフォームとして生まれ変わり、AIやML、コンテナ、サーバーレスなど、興味のある技術分野に応じた学習パスの提供や hands-on まで無料で利用できます。この後ご紹介する AWS SimuLearn と合わせて、AWS の学習環境が進化していますので是非チェックしてみてください。 では今週も生成 AI with AWS 界隈のニュースを見ていきましょう！ さまざまなニュース ブログ記事「通信事業者が提供するSmart-Xのための協調AIエージェントによる分散推論」 このブログでは、デバイスエッジからAWSクラウドまでの多層アーキテクチャにおいて、AIの推論処理を効率的に分散させる新しいアプローチについて解説しています。具体例として交差点安全システムを取り上げ、カメラやセンサーからのリアルタイムデータを用いた事故予防や対応の仕組みを説明しています。ファーエッジ（デバイス）でリアルタイムの推論処理、ニアエッジ（通信事業者のMECサイト）で複数デバイスからのデータ集約と高度な推論、そしてAWS上で全体的なオーケストレーションと分析を行います。このアプローチにより、低遅延での即時対応と、AWS上での高度な分析の両立が可能になります。リアルタイム性が求められるエッジでの処理と、高度な分析が必要なクラウドでの処理を最適に組み合わせることで、より効率的で信頼性の高いSmart-Xソリューションを構築できる点がポイントです。 ブログ記事「スタートアップ 3 社に学ぶ生成 AI 実装のリアル。AWS 活用の最前線【AWS Summit Japan・事例セッション】」 AWS Summit Japan 2025 で紹介された、生成AIを活用する3つのスタートアップ企業の事例を紹介しています。LayerX社は、Amazon Bedrock を活用して経理業務の効率化を実現し、独自のAI-OCRシステムと大規模言語モデルを組み合わせることで、高精度な帳票処理を可能にしました。カラクリ社は、AWS Trainium を活用して独自のLLMを開発し、カスタマーサポート業務に特化した高性能なAIエージェントを低コストで実現しています。ファインディ社は、Amazon Security Lake を導入してセキュリティログを一元管理し、Amazon Bedrock と連携させることで、セキュリティ監視業務の効率化に成功しました。それぞれ生成AIを活用する事で企業固有の課題を解決し、業務効率を大きく改善した事例になります。 ブログ記事「AWS SimuLearn: Generative AI – 「生成AI」を無料で学習しましょう！」 AWS SimuLearn は、生成AIを活用した新しい学習プラットフォームです。現在、生成AIとクラウドの基礎に関する無料の日本語対応コースを提供しています。現在、生成 AI 関連の 8 コースとクラウドの基礎 12 コースを無料で利用することができます。実際のAWSアカウントを使用した実践的なハンズオン学習が、料金を気にすることなく実施できる環境が整備されていることがポイントです。 サービスアップデート Amazon CloudWatch と Application Signals の AI 支援トラブルシューティング用 MCP サーバー AIによる自動化されたトラブルシューティングと監視を強化する2つの新しいModel Context Protocol (MCP) サーバーを発表しました。これにより、AIエージェントが、より高度な分析と問題解決をサポートできるようになります。CloudWatch MCPサーバーはアラームベースのインシデント対応やメトリクス分析を提供し、Application Signals MCPサーバーはSLOを通じたサービスヘルスモニタリングと自動化された根本原因分析を実現します。ポイントは、自然言語でのクエリを通じてテレメトリーデータからビジネスインサイトを生成できること、そしてAIアシスタントが組み込みのアプリケーションパフォーマンスモニタリングの知識を活用して実用的な解決策を提案できることです。これらのツールにより、開発者は複数のAWSコンソールやAPIを手動で操作する必要がなくなり、より効率的なトラブルシューティングが可能になります。 Amazon Neptune AnalyticsがGenAIアプリケーション向けにMem0との統合を開始 Amazon Neptune Analytics がオープンソースのGenAI向けメモリシステムであるMem0との統合を発表しました。この統合により、AIエージェントがグラフデータベースを長期記憶機能として活用できるようになり、よりパーソナライズされたAI体験の提供が可能になります。Neptune をメモリストアとして使用することで、LLMは各インタラクションから学習し、時間とともにより効果的な応答が可能になります。グラフ、ベクター、キーワードの複数のモダリティにわたるハイブリッド検索もサポートされており、マルチホップグラフ推論による応答品質の向上も実現します。 Amazon Bedrockが開発を効率化するAPIキーを導入 Amazon Bedrock に新しくAPIキー認証機能が追加され、生成AIアプリケーションの開発がより簡単になりました。従来はIAMのプリンシパルとポリシーの手動設定が必要でしたが、Amazon Bedrock コンソールやaws SDKから直接認証情報を生成できるようになります。開発者は短期（最大12時間）または長期のAPIキーを選択でき、長期キーは有効期限の設定やIAMのコンソールでの管理が可能です。 Amazon SageMaker AIがAWSアジアパシフィック（台北）リージョンで利用可能に 機械学習の開発をサポートするAmazon SageMaker AI が、2025年6月に新しくオープンしたアジアパシフィック（台北）リージョンでの提供を開始しました。Amazon SageMaker AI は、開発者やデータサイエンティストが機械学習モデルを効率的に構築、トレーニング、デプロイできる完全マネージド型プラットフォームで、機械学習プロセスの各ステップにおける煩雑な作業を軽減し、高品質なモデル開発を容易にします。 Amazon Q in QuickSightが7つの新しいリージョンで利用可能になりました Amazon Q in QuickSight のサービス提供地域が大幅に拡大され、東京を含むアジア太平洋、ヨーロッパ、米国の7つの新しいリージョンで利用可能になりました。このサービスは、自然言語を使ってデータから洞察を引き出し、ビジネス分析を加速させる機能を提供します。ユーザーはAmazon Q in QuickSight を使用することで、データの説明やレコメンデーションを含むドキュメントやエグゼクティブサマリーを生成できます。 Amazon Q Developer のチャット機能が AWS Management Console を介してサービスのデータを照会可能に Amazon Q Developer の機能が拡張され、AWS Management Console、Slack、Microsoft Teams、AWS Console Mobile Applicationから直接AWSサービスのデータを照会・分析できるようになりました。例えば、S3バケットに保存されたログや、DynamoDBのレコード、CloudWatchログなどを自然言語で対話しながら分析できます。複数のインターフェースを行き来したり、異なるソースから情報を手動で収集したりする必要がなくなるため、クラウド環境の管理やトラブルシューティングにかかる時間と労力を大幅に削減できます。この機能は追加設定なしですぐに利用可能です。 Amazon SageMaker HyperPodが新しいオブザーバビリティー機能を発表 Amazon SageMaker HyperPod に新しいオブザーバビリティー機能が追加され、生成AIモデルの開発プロセスを大幅に効率化できるようになりました。Amazon Managed Grafana と Amazon Managed Prometheus を活用した統合ダッシュボードにより、生成AIタスクのパフォーマンスメトリクス、リソース使用率、クラスターの健全性を一元的に監視できます。これにより、パフォーマンスボトルネックの特定やトラブルシューティングの時間が大幅に短縮されます。 フルマネージド型MLflow 3.0がAmazon SageMaker AIで利用可能に Amazon SageMaker が提供するフルマネージド型MLflow 3.0は、生成AIの開発プロセスを大幅に効率化する新機能です。実験の追跡から本番環境までのエンドツーエンドのオブザーバビリティーを提供し、開発者は単一のツールで実験の追跡やモデル・AIアプリケーションのパフォーマンス監視が可能になりました。特に生成AIアプリケーションの各ステップにおける入力、出力、メタデータを記録するトレース機能は予期せぬ動作や不具合の原因特定を迅速化できます。また、各モデルとアプリケーションバージョンの記録を維持することで、AIの応答をソースコンポーネントまで追跡できるため、トラブルシューティングの時間を大幅に削減することができます。 Amazon SageMaker HyperPodがAIワークフロー用のCLIとSDKを一般提供開始 Amazon SageMaker HyperPod のCLIとSDKが一般提供開始されました。CLIはHyperPodクラスターの管理と迅速な実験のための一貫した操作性を提供し、SDKは分散トレーニングと推論機能へのプログラムによるアクセスを可能にします。データサイエンティストやMLエンジニアは、簡単なコマンドでトレーニングジョブの起動、推論エンドポイントのデプロイ、クラスターのパフォーマンス監視が可能になり、システムログや可観測性ダッシュボードへのアクセスによってデバッグや開発の効率化が図れます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 アップデートの前に、先日開催された re:Inforce のre:Capイベントを含め今月いくつかイベントが予定されているので紹介させてください。よかったらご参加ください。 — 商用データベースをAWSで活用する 2025 年 7 月 17 日 (木) 10:00 – 12:00 JST 開催場所：オンライン 申し込みは こちら AWS re:Inforce 2025 re:Cap 〜クラウドセキュリティを簡素化してイノベーションを加速〜 2025 年 7 月 24 日 (木) 10:00 – 12:00 JST 開催場所：オンライン 申し込みは こちら 金融業界向け：AWS の生成 AI 基盤で実現するデータ駆動型金融革新 2025 年 7 月 24 日 (木) 14:00 – 16:00 JST 開催場所：オンライン 申し込みは こちら — それでは、先週の主なアップデートについて振り返っていきましょう。 2025年7月7日週の主要なアップデート 7/7(月) この日のアップデートはありませんでした。 7/8(火) Oracle Database@AWS is now generally available Oracle Database@AWS が一般提供開始されました。これは AWS と Oracle が共同で提供するサービスで、AWS データセンター内で Oracle Exadata Database Service と Oracle Autonomous Database on Dedicated Exadata Infrastructureを利用できるものです。Oracle RAC等の利用ができる他、Amazon Redshift との Zero-ETL 、S3やCloudWatch他のAWSサービスと統合されます。まずは、バージニア北部 およびオレゴンの2つのリージョンでの提供ですが、今後東京、大阪を含む20のリージョンに拡大予定です。詳細については Oracle Database@AWS  と ドキュメント をご確認ください。 Amazon VPC Lattice announces support for Oracle Database@AWS Amazon VPC Lattice が Oracle Database@AWS (ODB) をサポートしました。VPC Lattice のサポートにより、複雑なネットワーキングの設定を必要とすることなく、ODBから数千の VPC やオンプレミス環境を横断して AWS サービス、HTTP API、TCP アプリケーションに簡単に接続できるようになる他、Amazon S3 と Amazon Redshift にプライベートかつ安全にアクセスすることが可能です。これによりデータベースの OCI マネージドバックアップや、独自の バックアップをAmazon S3に取得するのを簡単に設定可能です。詳細については、 リリースブログ 、Amazon  VPC Lattice 、および  Oracle Database@AWS  のドキュメントをご確認ください。 AWS Network Firewall: Native AWS Transit Gateway support in all regions AWS Network Firewall が全リージョンで AWS Transit Gateway との直接統合をサポートしました。これまでは専用の VPC サブネットやルートテーブルの管理が必要でしたが、今回のアップデートで直接アタッチが可能になり設定が大幅に簡素化されます。これによりAWS Site-to-Site VPN や AWS Direct Connect 経由で接続された VPC やオンプレミスネットワークを含む、AWS ネットワーク全体のトラフィックを保護できます。この機能は、AWS Network Firewall と AWS Transit Gateway の両方がサポートされている全ての  AWS リージョン で利用可能です。詳細は ドキュメント をご確認ください。 AWS Site-to-Site VPN now supports IPv6 addresses on outer tunnel IPs AWS Site-to-Site VPN で、外部トンネル IP に IPv6 アドレスを利用可能になりました。これまでIPv6のサポートは内部トンネルのみで、外部トンネルには IPv4 アドレスが必須でした。今回のアップデートで内部・外部の両方のトンネルで IPv6 アドレスを設定できるようになったことで、IPv6 専用ネットワークへの移行や規制要件への対応が簡単になります。また、外部トンネル IP での IPv6 利用には追加料金がかからないため、パブリック IPv4 のコストも削減できます。この機能はミラノリージョンを除く他のすべての商用リージョンと GovCloud リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Q in QuickSight is now available in 7 additional regions Amazon Q in QuickSightが東京リージョンを含む新たに７つのリージョンで利用可能になりました。利用開始されました。Amazon Q in QuickSightは自然言語でデータに質問するだけで洞察を得ることができる機能で、既存のダッシュボードでカバーされていない情報を得るのに、従来は複雑な操作が必要だったデータ分析が、専門スキル不要で簡単に行えるようになります。また、Amazon Q in QuickSight は顧客データでトレーニングしないため安心してご利用いただけます。30日間の無料枠もあるので、ぜひお試しください。 7/9(水) Amazon Q chat in the AWS Management Console can now query AWS service data Amazon Q Developer が AWS Management Console、Slack、Microsoft Teams チャット、AWS Console Mobile Application から直接、AWS サービスに保存されたデータをクエリおよび分析できるようになりました。これまで複数の画面を行き来していた作業が、自然言語での会話だけで完結します。例えば S3 バケット内のファイル分析、DynamoDB テーブルのレコード確認、CloudWatch ログの調査などが可能です。追加設定不要で全リージョンで利用でき、管理者は IAM 権限でアクセス制御できます。詳細は ドキュメント をご確認ください。 Amazon Connect now supports parallel AWS Lambda execution in flows Amazon Connectがフロー内でのAWS Lambda 関数の並列実行をサポートしました。Amazon Connect では、Lambda を使用して3rd Partyや自社のシステムと連携ができましたが、従来は Lambda 関数を順次実行する必要がありました。今回のアップデートで複数の Lambda を同時実行できるようになり、例えば購入履歴の確認とプロモーション情報の取得を並行して行うなどが可能になり顧客の待ち時間を短縮できます。機能は、Amazon Connect が利用可能な すべての AWS リージョン で利用可能です。詳細は ドキュメント をご確認ください。 Amazon P6e-GB200 UltraServers now available for the highest GPU performance in EC2 Amazon EC2 で最高性能の GPU インスタンス P6e-GB200 UltraServers が提供開始されました。NVIDIA の最新 GB200 GPU を最大 72 個搭載し、360 petaflopsの FP8 コンピュート、13.4 TB の総高帯域幅メモリ、および最大 28.8 Tbps の Elastic Fabric Adapterを利用可能で、従来では困難だった大規模 AI モデルの訓練や推論を効率的に実行できます。このインスタンスは現時点ではバージニア北部リージョンの拡張である Dallas Local Zoneで  Amazon EC2 Capacity Blocks for ML  を通じて利用可能です。詳細は ドキュメント をご確認ください。 7/10(木) Amazon SageMaker HyperPod introduces CLI and SDK for AI Workflows Amazon SageMaker HyperPodのCLIとSDKの一般提供が開始されました。SageMaker HyperPod CLI は、HyperPod クラスターの管理と迅速な実験のためのシンプルで一貫したコマンドライン体験を提供します。そして、SDK は HyperPod の分散トレーニングと推論機能へのプログラムからの直感的なアクセスを提供し、開発者がワークロード設定をきめ細かく制御できるようにします。これまで大規模 AI モデルの構築や訓練は複雑でしたが、これらの機能によりより簡単にトレーニングジョブの実行、推論エンドポイントのデプロイ、クラスターパフォーマンスの監視などが可能になりました。SageMaker HyperPodがサポートされているすべてのAWS商用リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon SageMaker Studio now supports remote connections from Visual Studio Code Amazon SageMaker StudioでVisual Studio Codeからのリモート接続がサポートされました。これまでAIの開発環境を構築するには数時間かかるケースもありましたが、今回のアップデートによりわずか数分でVS CodeからSageMakerの計算リソースにアクセスできるようになります。これにより普段使い慣れた VS Code の拡張機能やカスタム設定をそのまま活用しながら、AI モデルの開発やデータ分析が可能です。この機能は現時点ではオハイオリージョンで利用可能です。詳細は AWS ML ブログ もしくは ドキュメント をご確認ください。 Amazon SageMaker HyperPod accelerates open-weights model deployment Amazon SageMaker HyperPodが、Amazon SageMaker JumpStart からのオープンウェイト基盤モデルとAmazon S3およびAmazon FSxから独自のファインチューニングモデルの直接デプロイをサポートしました。従来は別々のリソースでモデルの訓練とデプロイを行う必要がありましたが、今回のアップデートにより同一の HyperPod クラスター上でモデルの訓練からファインチューニング、デプロイまでを一貫して実行可能になりました。この機能は東京を含む12のリージョンで利用可能です。詳細は ブログ および ドキュメント をご確認ください。 7/11(金) 大きなアップデートはありませんでした。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

2025 年 6 月 25 日・26 日に開催された AWS Summit Japan において、初日に「AWS Jam – チームで課題解決型ハンズオンに挑戦！ (生成 AI 編)」を実施しました。本イベントには、クラウドスキルの向上を目指す 88 名の参加者が、4 名ずつ 22 チームに分かれて参加しました。 今回の AWS Jam イベントは、生成 AI がテーマでした。参加者は Amazon Bedrock や Amazon SageMaker AI などのサービスを活用し、生成 AI モデルの選択や適切なプロンプト設計、推論パラメータの調整など、実践的なスキルを競い合いました。会場は終始活気に満ち、「あ、そういう解決方法があったのか！」「この機能、こんな使い方ができるんですね！」といった声が会場のあちこちから聞こえ、互いのスキルや知見を共有しながら課題を乗り越える姿が印象的でした。 参加者からは「実践的な課題に取り組むことで、座学だけでは得られない気づきがあった」「チームメンバーそれぞれの得意分野を活かして協力できた」といった前向きな感想が多く寄せられ、学びと成長の場として大きな成功を収めることができました。 このブログでは、熱気あふれる当日の様子をより詳しくお伝えするとともに、AWS Jam がどのようにクラウド学習やチームでのスキル共有に役立つのか、また、AWS Jam を実施したい方向けに、AWS Skill Builder やクラスルームトレーニングなどの選択肢についてもご紹介します。 AWS Jam とは AWS Jam は、AWS のユースケースに沿って用意された様々なテーマの課題を解決しながら「AWS を楽しく学ぶ」実践型のイベントです。参加者は AWS やシステム開発の知識や経験を活用し、必要に応じてその場で情報を調べながら、与えられた複数の課題を AWS マネジメントコンソールなどを利用してクリアしていきます。AWS Jam では、課題ごとに獲得得点やヒントが設定されており、時間内にクリアした課題と使用したヒントを総合してチームの得点を競い合います。 AWS Jam には「Play」「Learn」「Validate」の 3 つのコンセプトがあります。 Play (遊ぶ): 得点を競うゲーミング形式のイベントを通じて、楽しみながら課題解決に挑戦します。チーム内でのコミュニケーションの促進にもつながります。 Learn (学ぶ): シナリオに沿った課題を解決することで、AWS サービスの知識やスキルを身につけていきます。普段扱っていない AWS のサービスや機能を新たに学んだり調べたりする機会にもなります。 Validate (検証する): 課題解決を通して、参加者自身の AWS サービスに対するスキルや理解度を確認できます。 また、AWS Jam には生成 AI に関連する課題も多く用意されており、今回の Jam イベントでは、そんな生成 AI に関連する課題を 14 個選択しました。 AWS Jam 実施前のハイライト 今回の AWS Jam では 4 人でチームを組みます。登録時点ではチームは決まっておらず、会場に入場する際にくじ引きでチームを決定しました。ランダムにチームを決定することで、個人で参加する人のハードルを下げ、平等性を保つことを目的としました。 くじ引きを担当するトレノケート 山下さん Jam 実施前の緊張感漂う会場 優勝チームにはトロフィー、2,3 位にはメダルが贈呈される AWS Jam に参加するには、 AWS Skill Builder のアカウントが必要です。開場からイベント開始までの時間を利用して、スタッフがサポートしつつアカウントの準備を行なっていただきました。また、準備が完了したテーブルでは、チームメンバーと自己紹介や雑談をして交流を深めていました。 準備が整ったらオリエンテーション開始です。オリエンテーションでは、AWS Jam のプラットフォーム上でイベントとチームに参加していただき、AWS Jam の紹介とチャレンジへの取り組み方の説明を行いました。 ファシリテーターの AWS テクニカルインストラクター 青木克臣 AWS Jam では、チームでの取り組み方にプラットフォーム上の制約は無く、複数人で相談しながら 1 つずつチャレンジを進めるモブ型や、チーム内で 2 人 1 組になってチャレンジを進めるペア型、手分けして個人でチャレンジを進めるソロ型があります。 本イベントでは、以下の理由からペア型またはモブ型での参加形式を採用しました。 個人ではなく、チームとして AWS Jam イベントを楽しんでいただきたいと考えたため AWS Jam が個人の学習だけでなく、参加者同士のスキル共有の場としても価値があることを体験していただきたいため また、チャレンジに取り組む際には、AWS マネジメントコンソールやノートブックの操作を担当する「操作係」と、指示を出す「指示係」という役割分担をお願いしました。 AWS Jam 開始前にいくつかコツを伝えました。 例えば、ペアワークをうまく進めるコツとして、指示係が指示をする際には、具体的かつ意図まで伝えるようにしましょう (例：「プロンプトを修正しよう」ではなく「生成されたテキストが指定した形式に沿っていないので、プロンプトに具体的な出力形式の指示を追加して、JSON フォーマットで出力されるように修正しよう」や「ここの～」や「そこの～」といった曖昧な表現ではなく、「左上の～と書かれた四角いボタン」「右から3つ目に～」「xxというファイルの10行目のコードの～」など) というような点を伝えました。 また、チームで何かを達成したり、ポイントを獲得したりしたときには、チーム全員で拍手をすることでチームの連帯感を高め、チームでイベントを楽しんでいただけるようにしました。 AWS Jam 実施中の様子 「3、2、1…」カウントダウンの後、AWS Jam がついにスタートしました！ チームで AWS Jam に取り組む時間は 150 分です。AWS Jam が始まると、参加者たちは早速チーム内でペアを決めたり、最初に挑戦するチャレンジを相談したりと、活気に満ちた雰囲気が広がりました。 ペアワークやモブワークでは、画面を操作する「操作係」と、指示やサポートを行う「指示係」に分かれて協力しながらチャレンジに取り組む姿が見られました。 本イベントでは、各チームにモニターとホワイトボードを用意し、モニターには AWS マネジメントコンソールが映し出され、画面を見ながら意見を交わしていました。また、行き詰まった際にはホワイトボードを活用して考えを整理したり、図を描いて問題解決の糸口を探ったりする場面も見受けられました。 初対面のメンバー同士でも、課題を前に自然とコミュニケーションが生まれ、「こちらのサービスを使ってみては？」「このコマンドを試してみよう」と活発な意見交換が行われていました。時には笑い声も聞こえる和やかな雰囲気の中、チーム一丸となって課題解決に取り組む姿が印象的でした。 AWS Jam 実施中の様子 1/4 AWS Jam 実施中の様子 2/4 AWS Jam 実施中の様子 3/4 AWS Jam 実施中の様子 4/4 イベント中に、チャレンジを解決したチームに一言インタビューを実施したところ、「Bedrock に知らない機能があって、学びになった！楽しいです！」「めっちゃ楽しいです。引き続き頑張ります！」など感想をいただきました。 結果発表 激戦の結果、優勝は「Bed6」チーム、2 位が「Typhoon Monkeys」チーム、3 位が「kome」チームとなりました。各チームとも素晴らしいパフォーマンスを見せ、最後まで緊張感が漂う白熱した戦いを繰り広げました。おめでとうございます。 優勝: Bed6 のみなさま 2 位: Typhoon Monkeys のみなさま 3 位: kome のみなさま 上位 3 チームのメンバー AWS Jam のコンソールでは、リーダーボードやスコアリングトレンドがリアルタイムで表示されるため、特に後半では他チームとの得点差に一喜一憂する様子が見られました。「あと 20 点差だ！」「次のチャレンジをクリアすれば逆転できる！」と、競争意識が高まることでチーム内の結束も一層強まっていきました。残り時間が少なくなるにつれて会場の熱気も高まり、最後の最後まで諦めずに挑戦し続けるチームの姿が印象的でした。 実施後のアンケートでは、「Bedrock や SageMaker など、普段使わない分野のサービスを使った実利用例について分かりやすく学べてとても良かった」「JAM楽しかった！」「とても学びが多く楽しかったです」といったコメントを多くいただきました。 組織で AWS のスキルアップを考えている場合には、ぜひ AWS Jam を活用してみてください。組織で AWS Jam を活用する方法は次にご紹介します。 AWS Skill Builder チームサブスクリプションで AWS Jam イベントを実施可能 AWS Skill Builder は 600 を超えるデジタルコースや AWS 認定公式練習問題などが学べるオンライン学習プラットフォームです。また、 チームサブスクリプション を利用すれば、今回の AWS Summit で実施したような AWS Jam イベントをお客様が実施できるようになります。他にもたくさんのチャレンジから好みのチャレンジを選定し、組織内で回数制限なく自由にイベントを開催できます。 AWS Skill Builder サブスクリプションのご案内 のブログに詳細が記載されていますので、併せてご確認ください。 AWS Summit Japan 2025 の AWS Jam イベントは、生成 AI がテーマでした。AWS Jam には生成 AI に関連するチャレンジが多く存在しており、新規開発も進んでいます。(2025/07/04 時点) AWS Summit Japan 2025 で使われたチャレンジの一覧はこちらです。すでに組織で AWS Skill Builder チームサブスクリプションを契約されている場合は、 「AWS Summit Japan 2025」 のチャレンジセット を使用して、ぜひご自身の組織で開催してみてください。 レベル タイトル AWS サービス Easy Unlocking Insights: Understanding the Voice of the Customer Transcribe, Bedrock, Lambda Easy Your Query Whisperer SageMaker AI, Bedrock Easy The Lord Of The RAGs Bedrock, SageMaker AI, Translate Medium Intelligent Recipe Recommendation SageMaker AI, Bedrock Medium GenAI Security: Time for Serious Dialogue Bedrock Medium Silent Minds in the Cloud: No Trespassing Allowed Bedrock, VPC, Lambda Medium Responsible Banking Assistant SageMaker AI, Bedrock Medium Explain Model Decisions SageMaker AI Medium AI-Assisted Application Factory on Amazon Bedrock SageMaker AI, Bedrock, S3, CloudFront Medium Bits, Bytes, and Beyond: Fine-Tuning Expedition SageMaker AI, Lambda Medium Your Data Discovery Guardian Angel Bedrock, SageMaker AI, Redshift Medium Imagine the Impossible SageMaker AI Medium Run your own virtual comics studio powered by multi agents SageMaker AI, Bedrock Hard Keep your Taxbot in check Bedrock, Lambda AWS クラスルームトレーニングで AWS Jam を提供中 AWS クラスルームトレーニングに AWS Jam を追加したコースも提供しています (2025/07/09 時点では個社向けの開催のみです)。こちらを選択していただく利点として、クラスルームトレーニングを受けた後に AWS Jam を受講できるため、 知識をインプットするだけでなく AWS Jam で実践することで、より理解を深めたりスキルとしての検証をしたりできる点があります。さらに、トレーニング企画時に AWS の担当者と相談しながら AWS Jam の実施方法を決めていけるので、以下のような要望も可能です。 Play / Learn / Validate のどのコンセプトを重視するか 知識やスキルの近いメンバーでチームを組むか、均等になるようにチームを組むか モブ型、ペア型、ソロ型など、どんな形式で進めるか また、AWS Summit と同様に AWS の認定インストラクターが実施準備や当日の進行をするため、AWS Jam の用意や進行をするのに不安があるお客様にもおすすめです。 AWS Jam を追加したクラスルームトレーニングはオンラインでもオンサイトでもどちらでも提供可能です。オンラインの利点を活かして、普段は交流の少ないグループ内企業や国際拠点の従業員との交流の場としたり、オンサイトで部署やチーム内のスキル共有の場としてご利用いただいています。どちらもトレーニングでの知識のインプットだけでなく、AWS Jam で実践することで、知識を深めスキルとして検証できたとお客様から満足いただけております。 組織での AWS Jam 活用に興味がある場合は、 AWS トレーニングと認定へのお問い合わせ からご連絡ください。(画面右上で「日本語」を選択し、日本語での問い合わせが可能です) 最後に AWS Jam は、楽しみながら実践的に AWS を学ぶことができるイベントです。今回の AWS Summit Japan でも、熱戦が繰り広げられるとともに、チーム内でのスキル共有や新たな発見に満ちた有意義な時間としていただけました。これからクラウドスキルの向上を目指す方、ただ知識をインプットするだけでなく実践力を鍛えたい方、組織や個人のスキルを検証したい方にとって AWS Jam は最適です。 AWS Jam に挑戦したいと思った方は、AWS Skill Builder や AWS クラスルームトレーニング、AWS のイベント時に開催される機会を利用して AWS Jam に参加してみてください。 おまけ：本イベントでは、AWS トレーニングパートナー所属の AWS 認定インストラクターも運営メンバーとして加わっていました。当日運営をサポートいただいた AWS 認定インストラクターの方々、ありがとうございました。 (敬称略) 株式会社アシスト 木本 佳希 株式会社アシスト 嶋津 絵里子 NECビジネスインテリジェンス 吉田 薫 株式会社NTTデータ先端技術 田中 勇希 クラスメソッド株式会社 平野 文雄 株式会社システムシェアード 天野 盛介 トレノケート株式会社 金井 仁 トレノケート株式会社 久保玉井 純 トレノケート株式会社 髙山 裕司 トレノケート株式会社 山下 光洋 株式会社日立アカデミー 松川 信一郎 株式会社日立システムズ 藤巻 雄裕 株式会社f4samurai 酒井 幹士 ブログの著者 青木 克臣 (Katsuomi Aoki) トレーニングサービス本部 テクニカルインストラクター

2025 年 6 月 25 日、26 日に幕張メッセにて開催された AWS Summit Japan 2025 にご参加いただいた皆様、ありがとうございました。イベントはお楽しみいただけましたでしょうか。 本記事では、Day 2 に開催された、生成 AI をテーマとした AWS GameDay ~ Generative AI Unicorn Party ~ の開催概要と結果をご報告いたします。 図1 : GameDay の イメージスライド AWS GameDay とは？ AWS GameDay は、ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップです。3～4 名でチームを結成し、待ち受けるさまざまなトラブルやクエストをクリアしながら最終ミッションの達成を目指します。各クエストをクリアするごとにポイントが付与され、最も多くのポイントを獲得したチームが勝者となります。ゲーミフィケーションされた安全な環境で、楽しみながらさまざまなことを学ぶことができる機会を得られるワークショップです。 開催概要 今回の GameDay は総勢 22 チーム 88 名の方にご参加頂きました。当日のチームは、4 名で構成されるランダムなメンバーで編成されました。GameDay で高スコアを生み出す秘訣としてチームプレイ・連携が重要であることがアナウンスされ、ゲームの開始時間までにチームビルディングとして自己紹介、得意分野や経験領域の共有、名刺交換などが行われていました。 図2 : オープニングの様子 シナリオ概要 今回のゲームシナリオとして採用された “Generative AI Unicorn Party” では、架空のテクノロジースタートアップであるユニコーンレンタル社の新入社員説明会のシーンから始まりました。 図3 : オープニング説明の様子 オープニングにてCEOは、”ユニコーンレンタルの事業にAIを活用したサービスを提供することで、新しい体験をお客様に提供できるのではないかと考え、Generative AI Unicorn Party という、全く新しい生成 AI を活用したサービスを発表しました。しかしユニコーンレンタル社には十分な AI の知見者が足りておらず、このサービスは発展途上です。そこで AI や機械学習、データサイエンスに詳しい技術者である参加者の皆様に、今回のこの新しいサービスの発展と問題の解決にいただきたい。”と語りました。今回は参加者の皆様に、AWS の 生成 AI サービスを用いてミッションに取り組んで頂きました。ミッションの中では、 PartyRock を用いて生成 AI アプリケーションを作成したり、 Amazon Q Developer を活用したデバッグ、Amazon Bedrock の Guardrails や Agents を用いた高度な生成 AI アプリケーションの構築を体験いただきました。 ゲーム中の様子 皆様、GameDay ワークショップの内容に集中しつつも、楽しんで取り組んでいる様子でした。 図4 : GameDay 開催中の様子 今回の GameDay では、 Amazon Q Developer の力を借りながら問題に取り組むことができることもあって、多くのチームが問題を解けており、点数についてもかなり接戦であったように感じました。 図5 : 最終スコアボード 結果 結果は以下の通りでした。 第 1 位 Team ECS（小林 直樹 氏, 芦田 遼太 氏,(匿名希望) 氏, 陶 金 氏) / スコア : 234,099 図6 : 第1位 Team ECS のメンバー 第 2 位 ずんだもん（松岡 文雄 氏, 島川 寿希也 氏, 小野 綾介 氏, 平井 友樹 氏) / スコア : 214,254 図7 : 第2位 ずんだもん のメンバー 第 3 位 Bedrock Brothers（福元 駿汰 氏, 中野 勇一 氏, 大脇 遼 氏, 大橋 直弥 氏) / スコア : 206,996 図8 : 第3位 Bedrock Brothers のメンバー 上位入賞おめでとうございます。上位 3 チームの皆様には、メダルとぬいぐるみが進呈されました。 図9 : メダルとぬいぐるみ 優勝チームからは「 我々のチームには５人目のメンバーがいました。それは Amazon Q Developer です。 」と、本来4人チームのところに、 Amazon Q Developer を5人目のメンバーとして加えていただけたという、ありがたいコメントもあり、会場は大きく盛り上がりました。 その他の参加者の方々からも、以下のようなコメントをいただきました： 「Amazon Bedrock をフルに活用したアプリケーションの実装を体感できた」 「生成 AI 周りのキャッチアップする良い機会になった」 「周りの方と協力して進めることができて、楽しかった」 「普段触らないサービスに触れることができとても勉強になりました」 「Amazon Q Developer に ECS の作成をお願いしたら全部やってくれた」 皆様が Amazon Q Developer を早くも使いこなされていたこともあり、「 Amazon Q Developer が課題解決に大きく役立った」というコメントが多く見受けられ、生成 AI を活用した開発の現在地を知る機会になったようでした。 また、当日ランダムで編成されたチームメンバーとのコミュニケーションが刺激になったというコメントが多く寄せられました。このような交流ができることも GameDay の醍醐味だと思います。 図10 : GameDay 終了後の集合写真 最後に ご参加いただいた皆様、ありがとうございました。 生成 AI 領域の進歩は目まぐるしく、すでに従来の開発のあり方を大きく変えつつあるなかで、GameDay の中で 楽しみながら Amazon Q Developer を利用していただいたことで、その可能性を感じていただけたのではないかと思います。 今回惜しくも入賞を逃したチームの皆様、もしくは参加してみたい！と思ったエンジニアの皆様、今後もさまざまなイベントで GameDay の開催を予定していますので、機会を見かけましたら奮ってご挑戦ください。 それでは、また来年の AWS Summit Japan でお会いできることを楽しみにしています！ 著者について 大磯 直人（Naoto Oiso） Solutions Architect

7 月 9 日、 Amazon Elastic Compute Cloud (Amazon EC2) P6e-GB200 UltraServers の一般提供をお知らせします。この製品は NVIDIA GB200 NVL72 によって強化されており、AI トレーニングと推論向けに最高の GPU パフォーマンスを提供します。 Amazon EC2 UltraServers は、複数の EC2 インスタンス間で高帯域幅かつ低レイテンシーの専用アクセラレータインターコネクトを使用して、これらのインスタンスを接続します。 NVIDIA Grace Blackwell Superchip は、NVIDIA NVLink-C2C インターコネクトを使用して、2 つの高性能 NVIDIA Blackwell テンソルコア GPU と Arm アーキテクチャベースの NVIDIA Grace CPU を接続します。各 Grace Blackwell Superchip は、10 ペタフロップスの FP8 コンピューティング (スパース性なし) と最大 372 GB の HBM3e メモリを搭載しています。Superchip アーキテクチャでは、GPU と CPU が 1 つのコンピューティングモジュール内に配置されるため、現世代の EC2 P5en インスタンス と比較して、GPU と CPU 間の帯域幅が大幅に増加します。 EC2 P6e-GB200 UltraServers を使用すると、1 つの NVLink ドメイン内で最大 72 個の NVIDIA Blackwell GPU にアクセスして、360 ペタフロップスの FP8 コンピューティング (スパース性なし) と合計 13.4 TB の高帯域幅メモリ (HBM3e) を使用できます。 AWS Nitro System を搭載した P6e-GB200 UltraServers は、EC2 UltraClusters にデプロイされ、数万台の GPU まで安全かつ確実にスケーリングできます。 EC2 P6e-GB200 UltraServers は、合計で最大 28.8 Tbps の Elastic Fabric Adapter (EFAv4) ネットワーキングを実現します。また、EFA は NVIDIA GPUDirect RDMA と組み合わされているため、オペレーティングシステムのバイパスを使用してサーバー間の GPU から GPU への通信を低レイテンシーで実現できます。 EC2 P6e-GB200 UltraServers の仕様 EC2 P6e-GB200 UltraServers は、NVLink で 36 個から 72 個の GPU のサイズでご利用いただけます。EC2 P6e-GB200 UltraServers の仕様は次のとおりです。 UltraServer タイプ GPU GPU メモリ (GB) vCPU インスタンスメモリ (GiB) インスタンスストレージ (TB) EFA ネットワークの総帯域幅 (Gbps) EBS 帯域幅 (Gbps) u-p6e-gb200x36 36 6660 1296 8640 202.5 14400 540 u-p6e-gb200x72 72 13320 2592 17280 405 28800 1080 P6e-GB200 UltraServers は、エキスパートモデルと推論モデルの混合を含む、1 兆パラメータスケールでのフロンティアモデルのトレーニングや推論など、コンピューティングとメモリを非常に多く消費する AI ワークロードに最適です。 質問応答、コード生成、動画と画像の生成、音声認識などを含む、エージェンティック AI および 生成 AI アプリケーションを構築できます。 動作中の P6e-GB200 UltraServers ダラスローカルゾーンの EC2 P6e-GB200 UltraServers は、 ML 用 EC2 キャパシティブロック を通じてご利用いただけます。ダラスローカルゾーン ( us-east-1-dfw-2a ) は、米国東部 (バージニア北部) リージョンの延長です。 EC2 キャパシティブロックを予約するには、 Amazon EC2 コンソール で、 [キャパシティ予約] を選択します。 [ML 用キャパシティブロックを購入] を選択してから合計容量を選択し、 u-p6e-gb200x36 または u-p6e-gb200x72 UltraServers 用の EC2 キャパシティブロックが必要な期間を指定します。 キャパシティブロックのスケジュールが正常に設定されると、事前に請求が行われ、購入後も料金は変わりません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。詳細については、Amazon EC2 ユーザーガイドの「 機械学習用のキャパシティブロック 」を参照してください。 購入したキャパシティブロック内では、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用してインスタンスを実行できます。ソフトウェア側では、 AWS Deep Learning AMI を使用して開始できます。これらのイメージは、お客様がおそらく既にご存知であり、使用しているフレームワークとツール (PyTorch、JAX など) で事前設定されています。 また、EC2 P6e-GB200 UltraServers をさまざまな AWS マネージドサービスとシームレスに統合することも可能です。例: Amazon SageMaker Hyperpod は、P6e-GB200 UltraServers のプロビジョニングと管理を自動的に処理する、耐障害性の高いマネージド型のインフラストラクチャを提供し、障害が発生したインスタンスを同一 NVLink ドメイン内の事前設定済みの予備キャパシティに置き換えて、パフォーマンスを維持します。 Amazon Elastic Kubernetes Service (Amazon EKS) を使用すると、1 つのマネージドノードグループをノードとして複数の P6e-GB200 UltraServer 間で使用し、Kubernetes クラスター内のプロビジョニングとライフサイクル管理を自動化することができます。P6e-GB200 UltraServers では EKS トポロジ対応ルーティングを使用できるため、分散ワークロードの緊密に結合されたコンポーネントを、単一の UltraServer の NVLink 接続インスタンス内に最適に配置することが可能です。 Amazon FSx for Lustre ファイルシステムは、大規模な HPC および AI ワークロードに必要となる数百 GB/秒のスループットと、数百万回の 1 秒あたりの入出力オペレーション (IOPS) で、P6e-GB200 UltraServers のデータアクセスを提供します。大規模なデータセットにすばやくアクセスするには、最大 405 TB のローカル NVMe SSD ストレージを使用するか、 Amazon Simple Storage Service (Amazon S3) で費用対効果の高い事実上無制限のストレージを使用することができます。 今すぐご利用いただけます Amazon EC2 P6e-GB200 UltraServers は現在、 ML 用 EC2 キャパシティブロック を通じてダラスローカルゾーン ( us-east-1-dfw-2a ) でご利用いただけます。詳細については、 Amazon EC2 の料金ページ を参照してください。 Amazon EC2 コンソール で Amazon EC2 P6e-GB200 UltraServers をぜひお試しください。詳細については、 Amazon EC2 P6e インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

AWS では、ビルダーの皆様を心から大切に思っています。弊社は、技術コミュニティの活性化を支援する新しい方法を常に模索し、AWS Developer Center や community.aws など、人々がつながり、知識や経験を共有できる場を創出しています。 7 月 9 日、ビルダーの皆様がすべてのビルダーリソースにアクセスし、AWS コミュニティと交流して、AWS 製品チームにフィードバックや製品の提案を提供するための新しいプラットフォームである AWS Builder Center を発表しました。また、この新しいエクスペリエンスは、従来の AWS Developer Center と community.aws を統合します。 エキサイティングな機能が幅広く用意されています。さっそくいくつか見てみましょう。 皆様の声が重要です: ウィッシュリストのご紹介 個人的に最もエキサイティングな新機能の 1 つは、 ウィッシュリスト です。AWS サービスで実現してほしい新機能や改善点について、皆様のご要望をお寄せいただけるようになりました。他のビルダーは、これらの要望を見つけて投票するだけでなく、独自の要望を作成することもできます。 コミュニティとして製品ロードマップに共同で影響をもたらし、弊社が AWS サービスの未来を形作るのをサポートしていただけます。AWS サービスの運用中に、アイデア、提案、機能の提案、課題を共有できます。また、AWS コミュニティは、アイデアに賛成票を投じたり、極めて要望の多い改善点をハイライト表示できます。当社の社内チームがこれらの要望に目を通し、極めて多く寄せられた要望をサービスチームに伝達して、皆様の声を製品開発プロセスの不可欠な要素として活用します。 AWS コミュニティで人々とつながる [つながる] ページでは、 AWS ヒーロー や AWS コミュニティビルダー と直接つながる機会が数多くあります。世界中で、皆様が所在する都市の近くにある AWS User Groups や AWS Cloud Clubs を探して参加できます。 さらに、このページをブックマークして、今後のコミュニティイベントを見つけるための一元的なハブとして使用できます。これにより、皆様が所在している地域で学習やネットワーキングの機会を見つけたり、同じ関心を持ち、志を同じくするビルダーと出会ったりすることが簡単になります。 人々をフォローすることについて言えば、AWS Builder Center は AWS テクニカルコミュニティの中心ハブとして機能し、他のビルダーと非常に簡単につながったり、交流したりできるようにします。他のビルダーとつながるためのさまざまな方法が備わっています。例えば、 [フォローする人] セクションでは、AWS ヒーロー、コミュニティビルダー、関心のある領域で知識と専門知識を共有しているアクティブなコミュニティメンバーをご紹介しています。 AWS ハンズオンリソースを探す [構築] ページでは、 AWS チュートリアル や AWS ワークショップ など、あらゆるスキルレベル向けに設計されたインタラクティブな学習リソースを含め、ハンズオン体験を通じて AWS に慣れ親しむための方法を見つけることができます。生成 AI およびエージェンティック AI サービスのプレイグラウンドを探索し、 AWS 無料利用枠 を見つけて、各サービスについて指定された制限まで AWS サービスを無料でお試しいただけます。 [ツールボックス] ページを選択すると、AWS 向けの最新のツール、プログラミング言語リソース、オープンソースプロジェクトを見つけることができます。[ツールボックス] には、プロジェクトのスキャフォールディングと実行に必要なものがすべて揃っています。 弊社は、ビルダーのビルドエクスペリエンスを改善するため、特定のトピックで共同作業するための専用グループやフォーラムの作成、ハンズオンラボ用のワークショップの開催、ビルダーが AWS サービスを自由に実験できるさまざまなサービスプレイグラウンドなど、Builder Center の組み込みオファリングを拡張する予定です。 ビルダージャーニーのサポート 新しい [学習] セクションは、スキル開発への入口として機能し、AWS の専門知識を広げるために必要なあらゆるものをご用意しています。ここでは、学習およびトレーニングリソース、ワークショップ、ゲーム化された体験など、AWS での構築ジャーニーを教育的かつ魅力的なものにするためのさまざまなリソースを探索できます。 [トピック] ページを選択すると、さらに多くのコンテンツを探索して見つけることができます。トピックとタグでコンテンツを探索できます。注目のトピックやトレンドのトピックのセクションがあり、コミュニティで今注目を集めている情報に常に触れているようにするのに役立ちます。 皆様の言語に対応した組み込みローカリゼーション AWS Builder Center は、包括的なローカリゼーションサポートで、言語の壁を打破します。Builder Center で公開されるすべてのコンテンツは、自動的に 16 の言語で利用可能になります。また、投稿、コメント、ご要望などのユーザー生成コンテンツは、 [翻訳] を使用してオンデマンドで機械翻訳できます。そのため、世界中のビルダーとコラボレーションし、言語の壁を越えて知識や経験を共有できます。 デフォルトでは、すべてのコンテンツはブラウザで設定されている言語に基づいて表示されます。しかし、設定ページにアクセスして AWS Builder Center がデフォルトで使用する言語を選択することにより、この設定を変更できます。 今すぐサインアップしてプロフィールを作成しましょう AWS Builder Center は、AWS ジャーニーを紹介するための、よりパーソナライズされた包括的な手段を提供します。自分独自のプロフィールには、カスタム URL と共有可能な QR コードがあります。これにより、簡単に他のビルダーとつながり、AWS コミュニティであなたの存在を共有できます。 投稿、ご要望、意義深いやり取りはすべて一元化されたビュー内で整理され、簡単に確認できます。 [プロフィールを管理] ページで、プロフィールをカスタマイズし、特定の関心や専門領域を追加することで、同じ情熱を持つビルダーとつながるのに役立ちます。プロフィールの管理はシームレスです。AWS ビルダー ID を使用してすべての AWS サービス間で同期するため、AWS オファリングを利用する際に、ID の一貫性が確保されます。 builder.aws.com にアクセスし、AWS ビルダー ID でサインアップして、自分独自のエイリアスを取得することで、コンテンツ作成、ウィッシュリスト、コミュニティエンゲージメントツールなど、すべての機能にアクセスできます。 AWS Builder Center は、他の AWS ビルダーとつながり、学び、構築するのに役立つよう設計されています。ぜひ一緒にジャーニーを楽しみましょう! – Channy &  Matheus Guimaraes | @codingmatheus 原文は こちら です。

7 月 8 日、AWS 内で Oracle Real Application Clusters (RAC) を含む Oracle Exadata ワークロード向けの新しいオファリングである Oracle Database@AWS の一般提供の開始を発表しました。 お客様は過去 14 年間にわたって、 Amazon Elastic Compute Cloud (Amazon EC2) を使用してクラウド内で Oracle データベースワークロードをセルフマネージドで管理するか、フルマネージドの Amazon Relational Database Service (Amazon RDS) for Oracle を使用するかを選択できました。今後は、Oracle RAC または Oracle Exadata を必要とするワークロード向けに、より迅速かつシンプルなクラウド移行を実現するための追加のオプションをご利用いただけます。また、お客様は、AWS Marketplace を通じて単一の請求書を受け取ります。これは、AWS とのコミットメントや Oracle ライセンス特典 (Bring Your Own License (BYOL) や Oracle Support Rewards などの割引プログラムを含む) にカウントされます。 Oracle Database@AWS を利用すると、変更を最小限に抑えながら、AWS 内で、Oracle Exadata ワークロードを Oracle Exadata Database Service on Dedicated Infrastructure または Oracle Autonomous Database on Dedicated Exadata Infrastructure に移行できます。お客様は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS API などの使い慣れた AWS ツールとインターフェイスを通じて、Oracle Database@AWS デプロイを購入、プロビジョニング、管理できます。AWS API は、リソースをプロビジョニングおよび管理するために必要な、対応する Oracle Cloud Infrastructure (OCI) API を呼び出します。 2024 年 12 月の プレビュー 以降、一般提供が開始される際に、本番ワークロードを実行するのに役立つよう、弊社は機能を改善したり、追加したりしてきました: リージョンレベルの拡大 –  7 月 8 日より、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンで Oracle Database@AWS をご利用いただけるようになりました。また、世界中の 20 の AWS リージョンに拡大する計画も発表しました。このより幅広い可用性は、さまざまな地理的エリアのお客様の多様なニーズをサポートするため、より多くの企業がこのオプションから恩恵を享受できます。AWS リージョンのワークロード要件に合わせて、さまざまな Exadata システムサイズからお選びいただけます。 ゼロ ETL と S3 バックアップ – 分析のために Amazon Redshift との ゼロ ETL 統合 から恩恵を享受できるようになりました。これは、抽出、変換、ロードオペレーションのためのデータパイプラインを構築および管理する必要性をなくします。ゼロ ETL により、ネットワーク間のデータ転送コストを発生させることなく、AWS 上のデータを統合できます。最大でイレブンナインのデータ耐久性を備えた Amazon Simple Storage Service (Amazon S3) バックアップを提供しています。 Autonomous VM クラスター – Exadata Dedicated Infrastructure 上で、Exadata VM クラスターに加えて Autonomous VM クラスターをプロビジョニングできるようになりました。コミットされたハードウェアおよびソフトウェアリソースを使用するフルマネージドデータベース環境である Oracle Autonomous Database on Dedicated Exadata Infrastructure を実行できます。 また、Oracle Database@AWS は、 Amazon Virtual Private Cloud (Amazon VPC) Lattice (S3 や Redshift などの AWS サービスへのネットワークパスを直接設定するため)、 AWS Identity and Access Management (IAM) (認証と認可のため)、 Amazon EventBridge (データベースライフサイクルイベントをモニタリングするため)、 AWS CloudFormation (インフラストラクチャオートメーションのため)、 Amazon CloudWatch (メトリクスを収集およびモニタリングするため)、 AWS CloudTrail (API オペレーションをログ記録するため) などの他の AWS サービスと統合します。 Oracle Database@AWS の開始方法 Oracle Database@AWS は、AWS データセンター内で、Oracle Exadata Database Service on Dedicated Infrastructure と Oracle Autonomous Database on Dedicated Exadata Infrastructure という 2 つの主要サービスをサポートしています。 これらのサービスは、物理的には AWS リージョンのアベイラビリティーゾーン内に存在し、論理的には OCI リージョンに存在するため、高速かつ低レイテンシーの接続を通じて AWS サービスとのシームレスな統合を実現できます。 Oracle Exadata VM クラスターをアベイラビリティーゾーン内でホストする、プライベートで分離されたネットワークである ODB ネットワークを作成します。その後、VPC で実行されている EC2 アプリケーションサーバーにアクセスできる ODB ピアリングを使用します。詳細については、AWS ドキュメントの「 How Oracle Database@AWS works 」にアクセスしてください。 AWS Marketplace でプライベートオファーをリクエストする Oracle Database@AWS のジャーニーを開始するには、 AWS コンソール にアクセスするか、または AWS Marketplace のプライベートオファー をリクエストしてください。AWS と Oracle の営業チームがお客様のリクエストを受け取り、お客様のワークロードに最適なオプションを見つけるためにお客様にご連絡し、アカウントをアクティブ化します。 Oracle Database@AWS をアクティブ化してアクセスできるようになったら、 [ダッシュボード] を使用して、ODB ネットワーク、Exadata インフラストラクチャ、Exadata VM クラスターまたは Autonomous VM クラスター、および ODB ピアリング接続を作成できます。 詳細については、AWS ドキュメントの「 Onboarding to Oracle Database@AWS 」と「 AWS Marketplace buyer private offers 」にアクセスしてください。 ODB ネットワークを作成する ODB ネットワークは、AWS 上で OCI インフラストラクチャをホストする分離されたプライベートネットワークです。ODB ネットワークは、OCI の子サイト内に存在するネットワークに直接マッピングするため、AWS と OCI の間の通信手段として機能します。 [ダッシュボード] で、 [ODB ネットワークを作成] を選択し、ネットワーク名を入力し、アベイラビリティーゾーンを選択して、アプリケーションによって確立されるクライアント接続と、自動バックアップの実行に使用されるバックアップ接続の CIDR 範囲を指定します。また、ドメイン ( oraclevcn.com に固定されています) のプレフィックスとして使用する名前を入力することもできます。例えば、 myhost と入力した場合、完全修飾ドメイン名は myhost.oraclevcn.com となります。 オプションで、ODB ネットワークアクセスを設定して、Amazon S3 への自動バックアップとゼロ ETL を実行し、Amazon Redshift を利用して Oracle データに対するほぼリアルタイムの分析と ML を実現できます。 ODB ネットワークを作成したら、EC2 アプリケーションサーバーの VPC ルートテーブルを、ODB ネットワークのクライアント接続 CIDR で更新します。詳細については、AWS ドキュメントの「 ODB network 」、「 ODB peering 」、「 Configuring VPC route tables for ODB peering 」にアクセスしてください。 Exadata インフラストラクチャを作成する Oracle Exadata インフラストラクチャは、Oracle Exadata データベースを実行するデータベースサーバー、ストレージサーバー、およびネットワーキングの基盤となるアーキテクチャです。 [Exadata インフラストラクチャを作成] を選択し、名前を入力して、デフォルトのアベイラビリティーゾーンを使用します。次のステップでは、Exadata システムモデルとして [Exadata.X11M] を選択できます。また、データベースサーバーは、デフォルトで 2 台、最大で 32 台設定でき、ストレージサーバーは、デフォルトで 3 台、最大で 64 台設定できます (サーバーあたりのストレージ容量は 80 TB)。 最後に、スケジュール設定、パッチ適用モード、OCI メンテナンス通知の連絡先など、システムメンテナンスの詳細設定を構成できます。AWS コンソールからインフラストラクチャを作成した後、そのインフラストラクチャを変更することはできません。ただし、OCI コンソールに移動して変更することは可能です。 Exadata インフラストラクチャを削除するには、AWS ドキュメントの「 Deleting an Oracle Exadata infrastructure in Oracle Database@AWS 」にアクセスしてください。 Exadata VM クラスターまたは Autonomous VM クラスターを作成する Exadata インフラストラクチャ上に VM クラスターを作成し、同じ ODB ネットワーク内に異なる Oracle Exadata インフラストラクチャを持つ複数の VM クラスターをデプロイできます。 VM クラスターには次の 2 つのタイプがあります: Exadata VM クラスターは、Oracle Enterprise Edition のすべての機能を含む完全な Oracle データベースがインストールされた仮想マシンのセットです。 Autonomous VM クラスターは、人間による介入を必要とせずに、AI/ML を利用して主要な管理タスクを自動化するフルマネージドデータベースのセットです。 [Exadata VM クラスターを作成] を選択し、VM クラスター名とタイムゾーンを入力して、ライセンスオプションとして Bring Your Own License (BYOL) またはライセンス込みを選択します。次のステップでは、Exadata インフラストラクチャ、グリッドインフラストラクチャのバージョン、および Exadata イメージのバージョンを選択できます。データベースサーバーについては、各 VM の CPU コア数、メモリ、ローカルストレージを選択するか、またはデフォルトをそのまま使用できます。 次のステップでは、ODB ネットワークを選択し、VM クラスターのプレフィックスを入力することで、接続設定を構成できます。単一クライアントアクセス名 (SCAN) リスナーに対する TCP アクセス用のポート番号を入力できます。デフォルトのポートは 1521 ですが、1024～8999 の範囲でカスタム SCAN ポートを入力することもできます。SSH キーペアについては、VM クラスターに対する SSH アクセスのために使用する 1 つ以上のキーペアのパブリックキーの部分を入力します。 その後、診断とタグを選択し、設定を確認して、VM クラスターを作成します。作成プロセスには、VM クラスターのサイズに応じて最大 6 時間かかる場合があります。 Oracle データベースを作成および管理する VM クラスターの準備ができたら、OCI コンソールで Oracle Exadata データベースを作成および管理できます。Exadata VM クラスターの詳細ページで、 [OCI で管理] を選択します。OCI コンソールにリダイレクトされます。 OCI コンソールで Oracle Database を作成する際、Oracle Database 19c または 23ai を選択できます。プロビジョンドデータベースのために自動バックアップを有効にする際に、OCI リージョンの S3 バケットまたは OCI Object Storage を使用できます。詳細については、OCI ドキュメントの「 Provision Oracle Exadata Database Service in Oracle Database@AWS 」にアクセスしてください。 知っておくべきこと Oracle Database@AWS についていくつか知っておくべきことを次に示します: モニタリング – VM クラスター、コンテナデータベース、プラガブルデータベースの AWS/ODB 名前空間にある Amazon CloudWatch メトリクスを使用して、Oracle Database@AWS をモニタリングできます。AWS CloudTrail は、Oracle Database@AWS のすべての AWS API コールをイベントとしてキャプチャします。CloudTrail ログを使用すると、Oracle Database@AWS に対して実行されたリクエスト、リクエストの実行元の IP アドレス、リクエストの実行日時、および他の詳細を確認できます。詳細については、「 Monitoring Oracle Database@AWS 」にアクセスしてください。 セキュリティ – IAM を使用して許可を割り当てて、Oracle Database@AWS リソースを管理することが許可されるユーザーを決定できるほか、SSL/TLS 暗号化接続を使用してデータのセキュリティを確保できます。また、シームレスなイベントドリブンのデータベースオペレーションのために、 Amazon EventBridge を利用することもできます。これらはすべて連携して、効率的なクラウド運用を実現しながら、セキュリティ標準を維持します。詳細については、「 Security in Oracle Database@AWS 」にアクセスしてください。 コンプライアンス – Oracle Database@AWS を利用する際のコンプライアンスに関する責任は、データの機密性、お客様の企業のコンプライアンスに関する目標、ならびに適用される法令および規制によって決まります。当社は、Oracle Database@AWS で次のコンプライアンスを提供しています: SOC 1、SOC 2、SOC 3、HIPAA、C5、CSA STAR Attest、CSA STAR Cert、HDS (フランス)、ISO シリーズ (ISO/IEC 9001、20000-1、27001、27017、27018、27701、22301)、PCI DSS、HITRUST。詳細については、「 Compliance validation for Oracle Database@AWS 」にアクセスしてください。 サポート – AWS または Oracle の営業担当チームは、お客様の現在のデータベースインフラストラクチャの評価、Oracle Database@AWS がお客様の組織の要件をどのように最良に満たすことができるのかを明らかにすること、カスタマイズされた移行戦略とタイムラインの策定をサポートできます。また、AWS クラウドで実行される Oracle ベースのワークロードの設計、デプロイ、管理に特化した AWS Oracle コンピテンシーパートナー からのサポートを受けることもできます。 一般提供の開始と近日中に予定されている提供の開始 Oracle Database@AWS は、AWS Marketplace を通じて、米国東部 (バージニア北部) リージョンと米国西部 (オレゴン) リージョンでご利用いただけるようになりました。Oracle Database@AWS の料金および AWS Marketplace のプライベートオファーは、Oracle によって設定されます。このオファリングについての料金に関する詳細は、 Oracle の料金ページ でご覧いただけます。 Oracle Database@AWS は、南北アメリカ、欧州、アジアパシフィックの 20 超の AWS リージョンに拡大される予定です。これには、次が含まれます: 米国東部 (オハイオ)、米国西部 (北カリフォルニア)、アジアパシフィック (ハイデラバード)、アジアパシフィック (メルボルン)、アジアパシフィック (ムンバイ)、アジアパシフィック (大阪)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ロンドン)、欧州 (ミラノ)、欧州 (パリ)、欧州 (スペイン)、欧州 (ストックホルム)、欧州 (チューリッヒ)、南米 (サンパウロ)。 Oracle Database@AWS は、 AWS コンソール を使用して開始できます。詳細については、「 Oracle Database@AWS ユーザーガイド 」および OCI ドキュメント にアクセスしてください。また、通常の AWS サポートの連絡先または OCI サポート を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

毎週月曜日に、先週注目されたベストリリースとブログについてお伝えします。 この AWS Weekly Roundup を続ける前に、6 月、私は家族と一緒にカリフォルニア州サンフランシスコに引っ越し、Developer Advocate/SDE, GenAI としての新しい役割を始めたことをお伝えしたいと思います。 私はこれにワクワクしています。エキサイティングな新しい課題に取り組みながら、ベイエリアの新しいコミュニティとつながる機会があるからです。あなたが生成 AI とエージェンティックアプリケーションの構築に焦点を当てたコミュニティに参加している方か、それをご存知の方であれば、ぜひつながりたいと思います。 つながりましょう ! 6 月 30 日週のリリース 6 月 30 日週のリリースは次のとおりです: AWS Graviton4 を搭載した新しい Amazon EC2 C8gn インスタンスが最大 600 Gbps のネットワーク帯域幅を提供 – AWS Graviton4 プロセッサと第 6 世代 AWS Nitro Card を搭載した Amazon Elastic Compute Cloud (Amazon EC2) の C8gn インスタンスが一般公開されました。これらのネットワーク最適化インスタンスは、最大 600 Gbps のネットワーク帯域幅を提供します。これは、EC2 のネットワーク最適化インスタンスの中で最も高い帯域幅を表し、最大 192 個の vCPU と 384 GiB のメモリを備えています。C7gn インスタンスよりも 30% 高いコンピューティングパフォーマンスを提供し、仮想アプライアンス、データ分析、クラスターコンピューティングジョブなどのネットワーク集約型ワークロードに最適です。 Amazon DynamoDB グローバルテーブルで、マルチリージョン強整合性を利用して、最も耐障害性の高いアプリケーションを構築 – Amazon DynamoDB グローバルテーブルは、ゼロの目標復旧時点 (RPO) を必要とするアプリケーションのマルチリージョン強整合性 (MRSC) をサポートするようになりました。この機能により、システム停止中もアプリケーションはどのリージョンからでも最新データを読み取ることができ、支払い処理や金融サービスにおける重要なニーズに対応できます。MRSC では 3 つの AWS リージョンを 3 つのフルレプリカまたは 2 つのレプリカとウィットネスとして設定する必要があり、それによりミッションクリティカルなワークロードに最高レベルのアプリケーションの耐障害性を提供します。 Amazon Nova Canvas の更新: 仮想試着とスタイルのオプションが利用可能になりました – Amazon Nova Canvas では、2 つの画像を組み合わせて衣服が人にどのように見えるかを視覚化する仮想試着機能に加えて、芸術的な一貫性が向上した画像を生成するための 8 つの新しいトレーニング済みスタイルオプション (3D アニメーション、デザインスケッチ、ベクトルイラスト、グラフィックノベルなど) が導入されました。3 つの AWS リージョンで利用可能なこれらの機能は、現実的な製品の視覚化を求める小売業者やコンテンツ作成者向けに、AI を活用した画像生成機能を強化します。 Amazon Q in Connect では、プロアクティブな レコメンデーション のために 7 つの言語がサポートされるようになりました – Amazon Q in Connect は、生成 AI を搭載したカスタマーサービス用のアシスタントで、英語、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語の 7 つの言語でプロアクティブなレコメンデーションを提供するようになりました。AI を搭載したカスタマーサービスアシスタントは、音声やチャットでのやり取り中に顧客の意図を検出し、エージェントが問題を迅速かつ正確に解決できるようにします。 Amazon Aurora MySQL と Amazon RDS for MySQL を Amazon SageMaker と統合できるようになりました – この統合により、分析用のデータをほぼリアルタイムで利用できるようになります。MySQL データを Apache Iceberg 互換のレイクハウスに自動的に抽出します。その後、さまざまな分析エンジンや機械学習ツールを使用して、このデータにシームレスにアクセスできます。 Amazon Aurora DSQL が追加の AWS リージョンで利用できるようになりました – Amazon Aurora DSQL はアジアパシフィック (ソウル) にも拡大し、アジアパシフィックリージョンと欧州リージョン全体でマルチリージョンクラスターをサポートするようになりました。このサーバーレスの分散型 SQL データベースは、無制限のスケーラビリティ、最高の可用性を実現し、AWS 無料利用枠でインフラストラクチャを管理する必要がありません。 その他の AWS ブログ記事 Amazon SageMaker JumpStart と Amazon OpenSearch Service を使用して本番環境で RAG を最適化 – Amazon SageMaker JumpStart と Amazon OpenSearch Service を使用して本番環境で検索拡張生成 (RAG) を最適化する方法を学びましょう。この包括的なガイドでは、LangChain による RAG ワークフローの実装を示し、OpenSearch 最適化戦略について説明し、セットアップ手順を提供し、これらの AWS のサービスを組み合わせてスケーラブルで費用対効果の高い生成 AI アプリケーションを実現するメリットについて説明します。 EKS 上の Bedrock、MCP サーバーを使用するエージェンティック GenAI アプリケーション – この投稿では、Amazon Elastic Kubernetes Service (Amazon EKS) 上にデプロイされた Amazon Bedrock、Strands Agent、およびモデルコンテキストプロトコル (MCP) サーバーを使用してスケーラブルな AI チャットアプリケーションを構築する方法を示します。このアーキテクチャでは、エージェントワークフローとコンテナ化されたマイクロサービスを組み合わせて、複数の基盤モデルとのインテリジェントな自動スケーリング会話を実現します。 AWS Lake Formation で AWS Glue 5.0 を使用してデータレイクテーブルにテーブルレベルのアクセスコントロールを適用 – AWS Glue 5.0 では、AWS Lake Formation による Apache Spark のフルテーブルアクセス (FTA) コントロールが導入され、きめ細かなアクセスオーバーヘッドなしでテーブルレベルのセキュリティを実現できます。この機能は、レイクフォーメーションテーブル用のネイティブ Spark SQL/DataFrames をサポートします。これにより、Iceberg および Hive テーブルでの読み取り/書き込み操作が可能になり、パフォーマンスが向上し、コストが削減されます。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS re:Invent – 今すぐ登録して、一足先に最適な学習パスを選択し、移動手段と宿泊先を予約して、皆さんのチームとともに学び、つながり、楽しみましょう。若手のプロフェッショナルは、 All Builders Welcome Grant プログラム に申し込むことができます。このプログラムは、経済的な障壁を取り除き、クラウドテクノロジーへの多様な道のりを創り出すように設計されています。現在、申し込みを受け付けており、2025 年 7 月 15 日に締め切ります。 AWS NY Summit – コンピューティング、ストレージ、生成 AI における最新かつ最新鋭の AWS テクノロジーに焦点を当てた Swami の基調講演からインサイトを得ることができます。ニュースブログチームもエキサイティングなニュースをいくつか用意しています。直接参加できない場合でも、 グローバルライブストリームに登録 して参加することが可能です。また、最寄りの都市で 7 月と 8 月に開催される予定の Summit の日付も確認しておきましょう。 AWS Builders Online Series – 太平洋時間帯の地域を拠点としているならば、AWS でワークロードを構築、移行、デプロイするために役立つ基本的な AWS 概念やアーキテクチャ上のベストプラクティスを学び、実践的なデモに参加することができます。 AWS Gen AI Lofts に参加する – サンフランシスコ、ベルリン、ドバイ、ダブリン、バンガロール、マンチェスター、パリ、テルアビブ、およびその他の場所で AWS Gen AI Lofts を体験してください。実践的なワークショップ、専門家によるガイダンス、投資家向けネットワーキング、コラボレーションスペースなどがあり、生成 AI スタートアップのジャーニーを加速させるように設計されています。 近日開催されるすべての対面イベントと仮想イベント をご覧いただけます。 7 月 7 日週のニュースは以上です。7 月 14 日週の月曜日に再びアクセスして、新たな Weekly Roundup をぜひお読みください! –  Eli 原文は こちら です。

本稿は、2025 年 7 月 2 日に公開された “ Boost application performance: Amazon CloudFront enables HTTPS record ” を翻訳したものです。 Amazon CloudFront は、グローバルネットワーク全体で Amazon Route 53 の HTTPS DNS エイリアスレコードをサポートすることを発表しました。この機能でクライアントは、その後の接続ステップではなく、最初の DNS 解決フェーズで最適な HTTP プロトコルを見つけることができます。これにより、ユーザーはパフォーマンスとセキュリティを向上させると同時に、運用コストを削減できます。 この記事では、実装の詳細、パフォーマンスの向上、およびこの機能の設定方法について説明します。 DNS HTTPS レコード HTTPS レコードは、 RFC 9460 で定義されているサービスバインディング (SVCB) DNS レコードの特殊な形式です。これらのレコードタイプは、安全なインターネット接続の柔軟性を高め、信頼性と速度を向上させます。HTTPS レコードは、接続の確立に必要なラウンドトリップ回数を減らし、将来のプロトコルアップグレードをサポートすることでこれを実現しています。 HTTPS DNS レコードは、特定のドメインで利用できるサービスについて、他のレコードタイプ (A や AAAA など) よりも詳細な情報を提供します。このレコードタイプには、サポートされているプロトコルやポートなどの重要な情報が表示され、クライアントが接続できる代替サーバーを指定することもできます。 クライアントが DNS ルックアップを実行して HTTPS レコードが利用可能になると、使用可能なプロトコルに関する情報が即時に届きます。これにより、TLS ネゴシエーションとプロトコル検出を別々に行う必要がなくなります。ブラウザとモバイルアプリケーションは、最もパフォーマンスの高いプロトコルを使用して最初の接続で直接安全な接続を確立できるため、レイテンシーとダウングレード攻撃に対する脆弱性が軽減されます。 HTTPS DNS レコードフォーマット： <domain> <TTL> IN HTTPS <priority> <target> <parameters> 例： mysite.com. 300 IN HTTPS 1 . alpn=h2,h3 コンポーネント： domain：ウェブサイトの FQDN (末尾がドットで終わる) TTL：キャッシュ時間 (秒単位) (300-86400) priority：エイリアスは 0、サービスエンドポイントは 0 より大きい target：同じドメインの場合は「.」、別のドメインを指定 parameters：アプリケーション層プロトコルネゴシエーション、プロトコルネゴシエーション値の場合は alpn=h2、h3 などのキーと値のペア TTL が小さいほど動的更新が多いケースに向き、TTL が高いほどキャッシュパフォーマンスが向上します。 ブラウザサポート 主要なブラウザはすでに HTTPS レコードタイプをサポートしています。ウェブトラフィックの大半を占めるChrome、Safari、Firefox は、これらのクエリをデフォルトですでに行っています。 ブラウザが DNS クエリリクエストを行うと、通常は、従来の A/AAAA レコードリクエストと新しい HTTPS レコードリクエストの両方を同時に送信します。ブラウザは HTTPS レコード応答のプロトコル情報と IP アドレスを使用して最適な接続を確立します。この方法では、HTTPS レコードが利用可能な場合にパフォーマンスを最適化すると同時に、まだサポートしていない DNS サーバーとの互換性を維持できます。 クライアントがこの機能をサポートしていない場合は、「従来の DNS 解決と接続アップグレードフロー」セクションで説明されている従来の DNS 解決プロセスに従います。これにより、リスクのない最適化が可能になり、古いクライアントとの互換性を損なうことなくパフォーマンスを向上させることができます。 従来の DNS 解決と接続アップグレードフロー 次のシーケンス図は、HTTP/1.1 または HTTP/2 への初回接続後に、クライアントが Alt-Svc ヘッダーを介してHTTP/3 サポートを検出する従来の方法を示しています。HTTP/3 へのアップグレードには複数の接続確立が必要でした。 図 1: HTTPS レコードを使用しない DNS 解決と HTTP/3 アップグレードプロセス 次のステップでは、その順序を説明します。 ステップ 1-2: DNS クエリ (1) クライアントが DNS に www.example.com A/AAAA を問い合わせる (2) DNS は CloudFront エッジサーバーの IP のみを返す 結果：クライアントには IP アドレスはあるがプロトコル情報はありません。 ステップ 3-7: 最初の HTTP/2 接続 (3) CloudFront へ TCP ハンドシェイク (3 ウェイ) (4) TCP が確立される (5) TCP 経由の TLS ハンドシェイク (6) TCP 経由で TLS を確立される (7) HTTP/2 リクエスト レスポンス：HTTP/2 レスポンス Alt-Svc: h3=”:443″ 結果：クライアントは最初のリクエスト後に HTTP/3 サポートについて知ります。 HTTP/3 over QUIC を使用すると、最新の ウェブアプリケーションのパフォーマンスが向上しますが、接続のアップグレードプロセスには追加のラウンドトリップが必要になり、遅延が発生します。次のセクションでは、CloudFront ディストリビューションで HTTPS DNS レコードを使用してこれを改善する方法を紹介します。 CloudFront HTTPS DNS レコードと HTTP/3：安全な名前解決と接続確立フロー 次のシーケンス図は、HTTPS レコードタイプによる DNS 解決と、それに続くクライアントと ウェブサーバー間の接続確立を示しています。 図 2： HTTP/3 接続のための HTTPS レコードタイプを使用した DNS 解決 次のステップでは、その順序を説明します。 ステップ 1-2：DNS クエリ (1) クライアントが DNS に www.example.com HTTPS と A/AAAA を問い合わせる (2) DNS は CloudFront エッジサーバーの IP と alpn=h2,h3 を含む HTTPS レコードを返す 結果:クライアントは DNS を通じて HTTP/3 サポートを知ります。 ステップ 3-6：ダイレクト接続 (3) クライアントが CloudFront へ QUIC ハンドシェイク (1-RTT) を開始する (4) QUIC 接続が確立される (5) クライアントが HTTP/3 リクエストを送信する (6) CloudFront が HTTP/3 で応答する この図は、HTTPS DNS レコードタイプが HTTP/3 や QUIC などの最新のウェブプロトコルに関する初期ヒントをどのように提供するかを示しています。この仕組みにより、クライアントは接続開始前にサーバーがサポートするプロトコルを把握でき、より安全で効率的な接続確立プロセスが可能になります。 CloudFront HTTPS DNS レコードの作成方法 まず CloudFront ディストリビューションで HTTP/2 または HTTP/3 もしくはその両方を有効にする必要があります。既存のディストリビューションでは、 設定 に移動して 編集 を選択します。そこから次の図に示すように、ディストリビューションの HTTP/2 または HTTP/3 を有効にします。 図 3: 必要な CloudFront 設定 CloudFront ディストリビューションで HTTP/2 または HTTP/3 もしくはその両方が有効になっている場合、Route 53 を通じてカスタムドメインの HTTPS レコードを有効にできます。ドメインのホストゾーンを編集し、次の図に示すようにレコードの作成を選択します。レコード名には、CloudFront ディストリビューションのドメインに一致するサブドメインを入力します。次に、HTTPS タイプのエイリアスレコードを作成します。トラフィックのルーティング先で、CloudFront ディストリビューションへのエイリアスを選択し、該当する CloudFront ディストリビューションを選びます。保存すると、CloudFront はドメインの HTTPS レコードの送信を開始します。 図 4：HTTPS タイプの Route 53 エイリアスレコード CloudFront コスト最適化：Route 53 エイリアス HTTPS レコードの使用 CloudFront のコスト最適化を行う際、ほとんどの戦略はキャッシュヒット率の最大化、オリジンのオフロード、データ転送量の削減、HTTPS/TLS ハンドシェイクのオーバーヘッド最小化に焦点を当てています。しかし、Route 53 のエイリアスレコードを使用することで実現できる、強力でありながら見過ごされがちなコスト削減手法があります。 従来、Route 53 の DNS クエリはクエリごとに課金されます。しかし、エイリアスレコード（IPv4 専用の CloudFront ディストリビューションに対するエイリアス A レコード、またはデュアルスタック IPv4/IPv6 ディストリビューションに対するエイリアス A および AAAA レコード）を使用すると、Route 53 はこれらの DNS クエリ料金を免除します。これにより、トラフィックの多いドメインの運用コストを直接削減できます。CloudFront へのエイリアス HTTPS レコードのサポートにより、これらの節約効果はさらに拡大されます。 これで、ユーザーは CloudFront ディストリビューションを直接指す Route 53 エイリアス HTTPS レコードを設定できるようになり、Route 53 はこれらの DNS クエリを無料で処理します。これにより、最も一般的な 3 種類の DNS レコードタイプ (A、AAAA、HTTPS) のコストが削減されます。さらに、これはグローバルトラフィックを抱える大企業だけでなく、規模拡大を目指すスタートアップ企業にとっても特に影響力があります。最も一般的な DNS レコードクエリの利用が増えても課金されないため、安心感が得ることができます。 まとめ：ウェブパフォーマンス向上への一歩 Amazon CloudFront と Amazon Route 53 による HTTPS DNS レコードのサポートは、Web パフォーマンス最適化において意義ある進歩を表しています。不必要な接続セットアップのラウンドトリップを排除することで、CloudFront はエンドユーザーにコンテンツをより迅速かつ効率的に配信することができます。CloudFront での HTTPS レコードのサポートは、現在すべてのエッジロケーションで利用可能です。 AWS マネジメントコンソール を通じて、これらの新機能の使用を開始できます。CloudFront や Route 53 からの HTTPS レコード使用に関して追加料金はかかりません。 翻訳は Solutions Architect の長谷川 純也が担当しました。

国内最大規模の学習型ITカンファレンスである AWS Summit Japan が、6 月 25 日（水）、26 日（木）の二日間に渡り幕張メッセで開催されました。今年はさらにブース展示が拡充され、ヘルスケア・ライフサイエンス（HCLS）ブースでは、ライフサイエンスから３つ、ヘルスケアから２つの展示を行い、お陰様で大勢のお客様にご来場いただきました。展示内容としては、生成AIに加えてAIエージェントがより複雑で多岐にわたる業務を効率化し、さらに実験装置や医療機器などとも連携するデモを紹介しました。開催報告のブログはヘルスケアとライフサイエンスに分かれており、このブログはライフサイエンスに関する報告です。ヘルスケアに関しては こちら をご覧ください。 AI エージェントが切り拓く創薬研究の自動化デモ ( スライド ) こちらのデモブースでは、AI エージェントを活用した業務変革の一例として、創薬研究領域におけるDMTA (Design – Make – Test – Analyze)サイクルの各プロセスを研究員がエージェントへ対話的に指示することで自律的に実行するデモを展示しました。今回展示したデモは、抗体配列の生成モデル、抗体の特性を予測するモデルおよび予測スコアをもとに抗体配列を選定するモデルを利用し抗体配列のデザインを行い、合成および評価を行なって機械学習モデルの更新を行う、抗体のリード最適化サイクルを想定したデモのシナリオをとなっています。 まず、研究員がDMTAサイクルの計画をエージェントへ指示すると、エージェントは自律的に過去に実施されたDMTAサイクルの情報を取得して必要なコンテクストを補完しながら一連のDMTAサイクルの詳細が記載されたドキュメントを作成します。続けて、D, M, T, Aそれぞれのタスクに対して担当の研究員がエージェントへ指示を行うと、エージェントは自律的に必要な情報を検索し取得する、計算やドキュメント作成等のタスクを実行する、データの保存や結果の記録等を行います。 今回のデモの注目点は、コンピュータ上で完結するタスクだけでなく、MakeやTestといった実際に実験室での作業が必要な専門的な工程の実行もAI エージェント実行のシナリオに含めている点です。今回はMakeはエージェントが研究員をサポートする形で実験は研究員が実施、TestはLab Automationにより完全に自動化されており、その指示をエージェントが実行可能であるという仮定をしたシナリオでデモを実施しています。 Lab Automationの実現にはハードウェア、ソフトウェア領域共に様々な課題がありますが、特にソフトウェア領域の課題の一つは、非定型業務において一連の実験機器を動かす実験のプロトコルを、いかにロボットや機器への指示へと落とし込むかです。今回のデモでは、自動分注機である  OT-2  をエージェントが操作可能な形で接続し、エージェントが自律的に自動分注機のプロトコルをPythonスクリプトとして作成し指示をすることで、エージェントによる自律的な実験を実現しています。 しかし、実際の実験プロセスは分注だけでは完結しません。試薬の取り出し、分注、測定、記録といった一連のプロセスを行う必要があります。このような一連のタスクをエージェントによって実現するにはどのような工夫が必要でしょうか？考えられるアプローチの一つはエージェントのタスク実行の精度を高めるためのデータの蓄積と、適切なエージェントのツールアクセスの整備です。例えば、実験機器の仕様が記載されたドキュメントにエージェントがアクセスできるようになっていれば、エージェントはその仕様に従って適切な機器への指示が期待されます。しかし、仕様には記されていない研究員独自のノウハウや工夫を必要とする動作をエージェントに期待するのは、少なくとも現在のLLMの性能からは現実的ではありません。そこで、機器のドキュメントだけでなく、過去の実験の詳細な記録やその際の研究員の暗黙知にまでエージェントがコンテクストとして取得させることで、より賢く自律的なエージェントによるタスクの実行が期待されます。今回のデモ展示では、研究の各プロセスをエージェントと研究員が協調しながら進めることで、研究員を補佐しつつもデータを蓄積し、その蓄積されたデータによりエージェントの精度や自律性が向上していくという長期的な展望と、その入り口としてのデモという形での展示を行いました。 また、実装にあたってはエージェントの実装に Strands Agents SDK を利用し基盤モデルには Amazon Bedrock  を利用しています。エージェントはAgent as Tools構成でのマルチエージェント構成で実装しており、Design, Make, Test, Analyzeや計画、実験機器操作など専門知識が必要とされるタスクはサブエージェントが実行するアーキテクチャとなっています。サブエージェントを利用することで、複雑な判断が必要とされるタスクのためのシステムプロンプトやツールをリードエージェントから分離し、全体のコンテクストウィンドウを節約しつつ複雑なタスクの実行精度を上げる工夫をしています。 創薬研究 ( スライド ) Life Sciences Agents Toolkit on AWS における R&D 領域の活用デモ Life Sciences Agents Toolkit on AWS はライフサイエンスのワークフローを Amazon Bedrock エージェント を使用して 構築するためのベストプラクティスです。このソリューションは GitHub にオープンソースとして公開 されており、誰でもご自身の AWS アカウントに展開可能で、独自にカスタマイズしてそのままご利用頂くこともできます。 (注意：このソリューションの実行中に使用した AWS サービスのコストはお客様の負担となります。ご自身でデプロイされる場合はご了承のうえ、ご利用ください。) ソリューションには PubMed や ClinicalTrials.gov  などのパブリック API、社内データを想定したサンプルデータを格納する Amazon Neptune 、 AWS HealthImaging や Amazon Redshift などのリソース、 Amazon SageMaker でカスタムコンテナや、その他の特殊な生物学基礎モデルをサポートするツールなどがあります。今回のブース展示では実装されている 3 つの AI エージェントのうち R&D 領域向けの Biomarker supervisor のデモを実施しました。 バイオマーカーとは病気の有無や進行状態、治療の効果などを評価するための指標となるものであり、具体的には血液検査で測定されるタンパク質や遺伝子、血圧や心拍数などです。Biomarker Supervisor はがんのバイオマーカー分析とインサイトを支援することを目的としたマルチエージェントシステムです。 このデモでは、がん患者の調査として体の中にあるタンパク質の一つである GDF15 (Growth Differentiation Factor 15) の量が少ないがん患者を検索し、その患者の腫瘍の形状について調査することを想定しています。 Biomarker-discovery-assistant はスーパーバイザーとして質問に対するマルチステップタスクを定義し、コラボレーターである Biomarker Database Analyst (データベースへの SQL クエリ生成と実行を担う) や Medical Imaging Expert (医療画像の処理と分析) にタスクを委任して、アウトプットを最終的な回答にまとめます。このようなマルチエージェントコラボレーションにより、専門的なスキルを必要とする複雑なマルチステップタスクを、複数の AI エージェントを連携することで、取り組むことが可能です。 第一三共株式会社様事例：創薬研究クラウドプラットフォームにおけるモダナイゼーションの取り組み 第一三共株式会社ではハイパフォーマンスコンピューティング (HPC) 環境を構築・運用し、研究環境の効率化とスピードアップを実現しています。一方で HPC 環境の継続的な利用においては運用作業が負担となり、将来的なスケーラビリティに影響するため、創薬研究クラウドプラットフォームにおけるモダナイゼーションの取り組みを　AWS が提供する新しいマネージドサービス AWS Parallel Computing Service (AWS PCS) の試験構築に着手しました。詳細はこちらの AWS ブログ を参照ください。 臨床開発 ( スライド ) 臨床開発ブースでは、5月に米国で開催されたAWSライフサイエンス・シンポジウムで発表されたソリューションを中心に3つのデモを紹介しました。 1つ目が「Life Sciences Generative AI Portal」です。このポータルは、臨床開発だけでなく、創薬研究や製造、コマーシャルなどライフサイエンス分野の30以上の生成AIアプリケーションを提供し、各企業でのPoC(概念実証)を加速することを目的としています。臨床開発においては、臨床試験データの分析、臨床統計のアシスト、プロトコルデザインの支援など、臨床開発に特化したアプリケーションも用意されており、ブースでは臨床試験情報をチャット形式で検索でき、通常のキーワード検索に比べて業務の効率化が図られるデモを紹介しました。 2つ目は創薬研究でもご紹介した「 Life Science Agent Toolkit 」です。これは、 Amazon Bedrock Agents を活用したライフサイエンス向けのワークフロー構築ベストプラクティスを提供する、オープンソースのツールキットです。臨床試験に特化したエージェントも用意されており、マルチエージェントによる連携も可能で、より複雑で抽象的な依頼にも柔軟に対応します。デモでは、「BRCA変異を有する卵巣がん患者を対象とした新規PARP阻害剤のフェーズII臨床試験プロトコルの作成してください」のような依頼をスーパーバイザーエージェントにすると、まずは回答作成のための作業計画を立案し、その計画に従って臨床試験情報検索とプロトコル作成の二つのサブエージェントが連携して、公開データベースから関連情報を収集し、また所定の書式に従ったドラフト作成まで実施する様子を紹介しました。通常、多くの人手と時間をかけて実施されるこのような作業がAIエージェントにより効率化できる可能性に驚かれた方も多く、オーブンソースであることからすぐに試せると大きな反響をいただきました。 最後の「Clinical Trial Transformation」は、臨床試験の業務効率化を目指したプラットフォームです。臨床開発業務はデータマネージャー、統計プログラマー、医学コーディング担当者などの各ペルソナ別の業務システムによりサイロ化が進み、進捗が見えにくかったり、ペルソナをまたいだワークフローが非効率であるといった課題があります。このソリューションでは各ペルソナ向けに最適化されたインターフェースを提供しつつも、データの一元管理と自動化されたワークフローによって業務の効率化を実現します。デモでは、複数試験の進捗状況の可視化、統計処理のためのCDASHからSDTMへのデータ変換のリネージとカスタマイズ、生成AIを活用したコーディング支援やリスク予測などの機能を紹介しました。5月のシンポジウムで発表された米国メルク社の同様の取り組みについても紹介しました。 臨床開発の業務は複雑で作成する文書の量も多いことから、これらのデモを通じて生成AIによる効率化の可能性が高いことを感じていただくことができました。 著者について 原田 裕平 (Yuhei Harada) エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト AWSでは主にヘルスケア・ライフサイエンス業界のお客様を支援をしているソリューションアーキテクトです。 中島 丈博 (Takehiro Nakajima) ハイテク＆ヘルスケア・ライフサイエンス部 シニアソリューションアーキテクト ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。 松永 徹人 (Tetsuto Matsunaga) ヘルスケア・ライフサイエンス ビジネスユニット シニアソリューションアーキテクト 国内外のヘルスケア・ライフサイエンスのお客様のクラウド利用を支援しています。SIerやコンサルティングファーム、製薬企業にてライフサイエンス業界へのITサービス提供の豊富な経験があります。

国内最大規模の学習型ITカンファレンスである AWS Summit Japan が、6 月 25 日（水）、26 日（木）の二日間に渡り幕張メッセで開催されました。今年はさらにブース展示が拡充され、ヘルスケア・ライフサイエンス（HCLS）ブースでは、ライフサイエンスから３つ、ヘルスケアから２つの展示を行い、お陰様で大勢のお客様にご来場いただきました。展示内容としては、生成AIに加えてAIエージェントがより複雑で多岐にわたる業務を効率化し、さらに実験装置や医療機器などとも連携するデモを紹介しました。開催報告のブログはヘルスケアとライフサイエンスに分かれており、このブログはヘルスケアに関する報告です。ライフサイエンスに関しては こちら をご覧ください。 医療現場の DX ( スライド ) 医療現場の DX ブースでは、パブリックセクターのお客様と実際に検証を進めているソリューションを紹介しました。 生成 AI による読影レポートのサマリー 医師が読影を行う際、その患者の過去の読影レポートの記録から今回確認すべきポイントを整理するのに時間がかかっており、生成 AI によるサマリーが行えるか検証しています。患者の読影レポート一週間分を入力とし、生成 AI にて読影レポートのサマリーを生成します。患者の情報、過去の実施事項、これまでの所見時確認ポイント、診断履歴、今回の所見時確認ポイントを過去データに基づいてレコメンドするよう、生成 AI に対して、プロンプトにて指示を与えています。デモ環境には Dify を使っており、容易に検証が行える環境となっています。 音声入力による SOAP 文章 ( 医療や介護現場で患者の情報を記録するフォーマット ) 生成 医師は患者を診察した後、電子カルテに診療録を記載するのに多くの時間がかかっており、診察時の音声から生成 AI を使って診療録のドラフトが作成できないかを検証しています。音声から Amazon Transcribe による文字起こしを実施し、SOAP ( Subject、Object、Assessment、Plan)  文章を生成するデモアプリケーションを開発しました。医師と患者のマイクを別々に設定することができ、医師と患者の会話をリアルタイムに分離、文字起こしすることができます。医師、患者の分離を最初から行うことができるため、会話の途中でも、SOAP 文章やフォローアップ文章を生成することができます。また、完成した SOAP 文章から、候補となる ICD10 コード ( WHOが定義した国際疾病分類コード ) をリストアップすることができます。こちらは、予め Amazon Aurora に登録された ICD10 データに対してベクトル検索を実施しています。更に AWS HealthLake と統合し、患者、診察記録、観察結果等のリソースを HL7 FHIR 形式 ( 医療情報の交換を効率的に行うための国際標準規格   ) にて保存することができます。 AI エージェントによる看護業務支援 看護師は日々の患者の状態を確認し、最適な入院ベッドの選定に多くの時間を費やしています。本業務を改善するために、患者の状態を入力すると、褥瘡ガイドラインを用いて症状に応じた最適なマットレスの種類を検索、またそのマットレスの病院内空き状況を確認した上で、推奨マットレスを回答するエージェントを開発しました。 Amazon Bedrock Knowledge Base を使い、褥瘡ガイドラインに対してベクトル検索を実施、デモ用にベッド空き状況を Amazon DynamoDB に保存し、検索用の AWS Lambda を Amazon Bedrock Agent で呼び出しています。ユーザインターフェースには、 Generative AI Use Cases (GenU) を利用しました。 生成 AI によるデータ分析 健診センターでは健診事業拡大へ向け様々なデータ分析を行っていますが、データ集計や可視化に多くの時間を費やしています。分析の効率を向上させるために、健診センターの実績ダッシュボードを Amazon QuickSight  にて作成、そこから Amazon Q in QuickSight の 3 つの機能（ データストーリー、データ Q&A 、シナリオ ) を使い、健診事業拡大へ向けた様々な戦略検討を行っています。まずは、 データーストーリー を使い、全体的な傾向を把握、そこから地域に着目し、 データ Q&A を使って特定地域のオプション健診平均単価から、テコ入れすべき健保を割り出します。最後に シナリオ を使い、テコ入れすべき施策の詳細分析を実施していきます。 生成 AI による医療求人マッチング 医療現場では求人と職員のミスマッチが大きな課題となっています。本課題への対策案の 1 つとして、医療系求人情報をベクトル化して保存、応募者のプロフィール情報を基に精密なマッチングを行い、推薦求人をリストアップしてくれるデモアプリケーションを開発しました。非構造データを含む求人データは、10 個のエンティティを LLM により抽出、ベクトル化して保存しています。そして、応募者プロファイルから 10 個のエンティティを LLM により抽出、カテゴリごとの重み付け ( 例えば、職種、資格の優先度を上げる ) を実施した後、求人データとの類似度を計算し、スコアの高い順に推薦求人を表示します。アプリケーション開発には、 Amazon Q Developer を使っています。 医療機関や、ヘルスケア関連企業のお客様にデモを見て頂き、医療現場の業務に対して、生成 AI の活用が有効であることを感じてもらうことができました。 生成 AI による医療データ利活用 （ スライド ） 生成 AI による医療データ利活用ブースでは、医療関係のお客様が医療情報や医用画像で抱える課題に対する、生成 AI デモを紹介しました。 医療業界では、データの標準化と活用において重要な課題を抱えています。デジタルで蓄積された医療データは、施設やベンダごとに形式が異なり、医療データ交換の標準である  HL7 FHIR  への変換には多大な労力を要します。また、画像診断装置の高度化に伴う画像検査の頻度や撮影枚数による医師の読影負担の軽減など、増え続ける診療情報の有効活用や効率的なデータ活用のための技術革新と運用改善が求められており、以下のような課題があります. 医療データの構造化／標準化 医療現場ではデジタルの普及により大量のデータが蓄積されていますが、データの多くが独自形式でシステム内に保存されており、施設内と施設間での相互運用性に課題があります。特に診療記録の自由記述やベンダシステムのデータ形式の違いが、 FHIR 等の国際標準規格への変換を困難にしています。効率的な医療サービスの提供や臨床研究の推進のため、データの構造化・標準化の実現が急務と言えます。 専門性の高い画像診断技術 医用画像診断技術の発展により、より詳細な病変の検出が可能となっていますが、画像の解釈には高度な専門知識と経験が必要です。 CT や MRI の画像データは、検査あたりの画像枚数が膨大であり、放射線科医の読影レポート作成業務にかかる負担が増大しています。 AI 技術の導入により診断支援システムの開発が進んでいるものの、手技や部位により解釈の精度にばらつきがあり、より幅広いモデル開発が進められています。 医療データを活用するツール 医療データの活用ニーズが高まっている一方で、医師や研究者が容易にデータを分析・活用できるツールを開発するプログラマが不足しています。特に臨床研究や診療支援において、データの可視化や統計解析を実現するプラットフォームの整備が求められており、医療特有の複雑なデータ構造や用語体系に対応し、かつセキュリティを担保した分析環境の構築が課題です。 デモの構成は以下のような流れとなります。「血液検査装置」と「画像検査装置」で出力した検査結果を患者管理システムからクラウドの  Amazon S3 に独自フォーマットのままデータをアップロードし、  Amazon Bedrock （LLMはClaude 3.7 Sonnet）でFHIRに変換をし、 FHIR Repository である  AWS HealthLake に格納しています。 Amazon SageMaker AI  にデプロイされた胸部X線画像の機械学習モデルで画像分類を行い、分類結果を数値で出力します。その項目毎の数値を胸部X線画像と共に再度、 Amazon Bedrock に元データとして渡し、読影レポートドラフトを作成し FHIR に変換し、 AWS HealthLake に格納します。患者情報、血液検査情報、画像検査情報、読影レポートドラフトはAWS HealthLakeに一元管理されます。  Amazon Q Developer  などの AI コーディングエージェントを活用して自然言語で開発された、ブラウザベースのアプリケーションであるマトリックスビューワでは、それらFHIRによる医療データを検索、表示することができます。また、チャットによる対話で「XXさんの過去の検査履歴を表示してください」等の質問には血液検査と画像検査双方のデータに基づく回答が得られます。 <Fig.1 デモの構成図> <Fig.2 アーキテクチャー図> ①独自フォーマットのデータからFHIRへの変換では、従来のルールベースのマッピングによる実装ではなく、生成 AI /LLMを用いてFHIRマッピングをしています。プロンプトエンジニアリングで、日本におけるFHIR拡張である JP Core を参考に、FHIRのリソースを選択しています。血液検査情報を構成する「Patient」、「Observation」と「ServiceRequest」にマッピングを行い、画像検査情報を構成する「Patient」、「ServiceRequest」、「ImagingStudy」と「Media」にマッピングを行っています。レポートドラフトの所見と診断も「DiagnosticReport」にマッピングします。 <Fig.3 患者・検査情報・画像の FHIR マッピング自動化> ②読影レポートドラフト作成では、胸部単純X線画像を直接LLMに入力しても、学習していない画像に対して、十分な精度による画像診断を行うことはできません。そこで、胸部単純X線画像の事前学習済みモデルを提供するオープンソースライブラリの TorchXrayVision を用いて、肺炎の検出や胸部疾患の分類を行っています。その分類結果を元にLLMがレポートドラフトを作成しています。 <Fig.4 生成 AI を活用した読影レポートドラフト作成> ③自然言語によるアプリケーション開発では、 Amazon Q Developer とオープンソースのAIコーディングエージェントである Cline  を用いています。これらを利用することで、対話的にコードの生成と補完に加え、AWSサービスの環境構築まで行うことができます。このアプリケーションでは FHIR Repository へのリアルタイムのアクセスに対応した「医療データ AI Agent Assintant」も実装されているため、新たな検査情報や処方情報などが FHIR として登録されても、柔軟に医療データを取得したり、複数の医療データから考察を得たりすることができます。 <Fig.5 自然言語によるアプリケーション構築> <Fig.6 医療データ AI Agent Assistant> ここまで3つのユースケースと解決方法を紹介してきました。会場では、「データ標準化」、「AI画像診断」、「アプリ開発」にお困りの様々な立場のお客様から強い関心をもっていただきました。ソリューションや生成AIによるそれぞれの課題解決の詳細について関心を持たれたら、 弊社営業担当もしくは AWS 問い合わせ窓口 へお問い合わせください。 著者について 松浦 靖 (Yasushi Matsuura) パブリックセクター技術本部 ソリューションアーキテクト 公共分野の医療機関やヘルスケア企業のお客様へ、クラウド活用のための技術的支援を実施しています。また、BI を活用したデータ分析に興味があり、Amazon QuickSight を活用した様々なデータ分析、解析手法に関しても支援を実施しています 窪田 寛之 (Hiroyuki Kubota) エンタープライズ技術本部 ソーシャルソリューション＆サービスグループ ハイテク＆ヘルスケア・ライフサイエンス部 ソリューションアーキテクト HL7 や DICOM の標準化活動の経験から、医療情報・医用画像を扱うお客様のクラウド利用に関する技術支援をしています。最近は新しい医療データ標準の HL7 FHIR を格納する AWS HealthLake や医用画像を格納する AWS HealthImaging などを提案しています。 松永 徹人 (Tetsuto Matsunaga) ヘルスケア・ライフサイエンス ビジネスユニット シニアソリューションアーキテクト 国内外のヘルスケア・ライフサイエンスのお客様のクラウド利用を支援しています。SIerやコンサルティングファーム、製薬企業にてライフサイエンス業界へのITサービス提供の豊富な経験があります。

本稿は、2025年3月20日に AWS for industries で公開された “ Distributed inference with collaborative AI agents for Telco-powered Smart-X ” を翻訳したものです。 はじめに 人工知能（AI）アプリケーションは、分散推論パイプラインへと進化しています。これにより、デバイスエッジからAWSクラウドまでの複数のレイヤーでモデルを実行し、遅延、帯域幅、プライバシーの最適化が可能になります。 すべての生データをAWSに送信する代わりに、協調的なAI推論は、デバイスエッジ、ファーエッジ、ニアエッジ（多くの場合5Gマルチアクセスエッジコンピューティングサイト – MEC）、およびAmazon Web Services（AWS）リージョンで実行でき、通信事業者は、AIコンピューティングハブとして重要な役割を果たします（図1）。AIおよびエージェント型ワークフローの観点から、エッジはもはや単なる受動的なデータ中継点ではなく、AIエージェントがタスクを動的にオーケストレーションし、レイヤー間で協調し、リアルタイムで推論実行を最適化するインテリジェントな意思決定レイヤーとなっています。通信事業者によるSmart-Xとは、AIによって強化され、通信ネットワークによって接続されたスマートインフラストラクチャ（スマートシティ、スマート交通など）を指します。この記事では、エッジとAWSクラウドがシームレスに共存し、多層アーキテクチャ全体に知能を分散させることで、実世界の課題に取り組む可能性について探ります。「交差点安全」問題を新たな視点で見直し、このハイブリッドアプローチがいかにより迅速で効率的なソリューションを実現するかを示します。ここで議論するアーキテクチャは、様々なSmart-Xドメインに広く適用可能です。 図1：Smart-X向けの分散コンピューティングの場所とその応用の範囲 アーキテクチャとテクノロジースタック 分散AIパイプラインを構築するには、ファーエッジ（デバイス、センサー、ゲートウェイ）からニアエッジ（Telco エッジ/MEC）を経て、AWSリージョンまでの統合されたネットワークアーキテクチャが必要です。各レイヤーには明確な責任があり、特定のAWSテクノロジーを使用します。 ネットワーキングレイヤー： ネットワークインフラストラクチャは、分散推論アーキテクチャの重要なバックボーンを形成します。それはファーエッジ、ニアエッジ、およびAWSクラウドレイヤーを、信頼性が高く、安全で、低遅延の通信経路で接続します。ファーエッジでは、デバイスは、時間的制約の厳しいAIワークロードのサービス品質を保証する専用スライスを介して5Gネットワークに接続します。これらのネットワークスライスは、帯域幅、遅延、信頼性に関する構成可能なパラメータを備えた、5Gインフラストラクチャの分離された仮想化された部分を提供します。AIハードウェアに統合された5G PCIeモジュールは、10ms未満の応答時間で超高信頼性低遅延通信（URLLC）を可能にします。これは、交差点監視などの安全が重要なアプリケーションに不可欠です。ファーエッジとニアエッジの間では、プライベートネットワークアクセスポイント名（APN）が、機密性の高いビデオデータを公共インターネットへの露出から保護する安全なトンネルを確立します。一方、 AWS Outposts Service Linkは、オペレーターのニアエッジデプロイメント（AWS Outpostsファミリー）と AWSリージョン サービス間のプライベート接続を作成します。この接続ファブリックは、最適化されたルーティングパスを通じて、コントロールプレーンメッセージ（低帯域幅のデバイス管理とモデルアップデート）とデータプレーンのトラフィック（高帯域幅のビデオストリームと推論結果）の両方をサポートします。 AWS IoT Core は、永続的な双方向接続のためのMQTT over WebSocketsを備えたメッセージングバックボーンを提供し、短い接続の中断が発生した場合でもセッション状態を維持します。ネットワークパス全体で、 AWS IoT Device Defender による相互TLS認証と証明書ベースのID管理によるエンドツーエンドの暗号化が実装され、承認されたデバイスのみが推論パイプラインに参加できるようになっています。さらに、ネットワークテレメトリは、 Amazon CloudWatch および AWS IoT SiteWise を通じて継続的に監視され、トラフィックパターンのリアルタイム最適化と、推論遅延や信頼性に影響を与える可能性のあるボトルネックの予防的特定を可能にします。この複数レイヤーのネットワーキングアプローチは、主要な交通事故や自然災害時のネットワーク輻輳などの困難な条件下でも、スマート交差点安全システムが動作し続けることを確保する回復力のある基盤を作成します。 図2：ネットワーキングとテクノロジースタックを示す機能アーキテクチャ ファーエッジレイヤー： これは、データが生成される場所です。たとえば、交差点にあるIPカメラやスマートセンサーなどです。これらのデバイスは、CPUおよびGPUハードウェアの異種アーキテクチャを使用してオンボードAI機能を活用し、オーディオ、ビデオ、画像理解にわたるマルチセンサー処理を可能にします。ベンダーの多様性を持つ共有インフラストラクチャを採用することで、このアプローチは、さまざまなハードウェアプラットフォームにわたるスケーラビリティ、柔軟性、相互運用性を保証します。オンボード視覚言語モデル（VLM: Vison Language Models）は、ビデオフィードで直接実行され、シーンをリアルタイムで解釈します。つまり、カメラは、現場で数ミリ秒以内に車両、歩行者、または異常を検出できます。ファーエッジデバイスは、AWS接続なしで単純な推論またはコマンドアンドコントロールタスクを実行するための反射エージェントも実行します。これらのモデルは、デバイスのコンピューティング/メモリ制約内で動作できるように、エッジ展開用に最適化されています（量子化やモデル蒸留などの技術を通じて）。この記事は、コンピュータビジョンのより広範な問題を解決することを目的としていません。オブジェクトの動的性質、オクルージョン、2Dビジョンベース推論の制限により、衝突検出が本質的に困難であることを認識しています。 ニアエッジ（Telcoエッジ/MEC）レイヤー： サービスプロバイダーのエッジ（多くの場合、5G マルチアクセスエッジコンピューティングサイト（MEC）サイト）は、中間レイヤーとして機能します。このニアエッジレイヤーは、AWS Outpostsファミリーなど、オンプレミスにデプロイされたAWSコンピューティングノードで構成されます。アーキテクチャでは、ニアエッジノードは、都市全体のビューを取得するために複数のカメラからのフィードを集約したり、高度なマルチモーダルモデルを実行するなど、ファーエッジレイヤーでは負荷がかかりすぎる重いAIタスクを実行します。AWS のサービスは通信事業者のエッジにまで拡張され、 AWS IoT Greengrass コンポーネントが、ローカル推論の調整とデータのキャッシュを行います。AWS IoT Greengrassフレームワークにより、小規模言語モデル（SLM：Small Language Models）および AWS Lambda 関数をエッジハードウェアで直接デプロイおよび実行できます。これによってMECサイトでは、最小限の遅延でロジックを実行することが可能になります。ニアエッジは、コラボレーションポイントとして機能します。複数のファーエッジハードウェアからアラートまたはデータを受信し、検証（より大きなVLMモデルを使用した二次的な衝突検出）を実行し、必要かつ高度な情報のみをAWSリージョンに転送します。 AWSリージョン： AWSリージョンは、システムの中央の頭脳および長期リポジトリです。高度なAIサービスと連携ロジックをホストし、知覚後の分析と意思決定を実行します。これには、リアルタイムアラートのストリーム処理、モデルの微調整のバッチ処理が含まれ、外部システム（ダッシュボードと緊急サービス）と統合するためのREST APIが公開されます。AWSリージョンは、 Amazon Bedrock および Agents for Bedrock を介したプライマリオーケストレーションを担当します。Amazon Bedrockは、インフラストラクチャを管理する必要なく、 Amazon Nova などのAWSからの大規模な基盤モデル、および主要なプロプライエタリモデルとオープンソースモデルへのアクセスを提供します。Amazon Bedrockの上で、エージェント機能により、異なるモデルとAPIを呼び出してタスクを計画および実行できる自律AIエージェントを作成できます。これらのエージェントは、大規模言語モデル (LLM: Large Language Models)を使用して目標を解釈し、ツールまたは他のモデルを呼び出してそれらの目標を達成します。設計では、AWS上のAmazon Bedrock Agentが、ファーエッジとニアエッジからの結合された入力を分析するコーディネーターAI（プライマリオーケストレーター）として機能します。エージェントは、外部APIまたはAWSサービスを呼び出すことによって、より多くのコンテキストを照会します。これにより、アラートのトリガーやモデルの更新など、高レベルのアクションを決定します。 交差点安全ユースケースの実装 交差点は、依然として道路上で最も危険な場所の1つです。数十年にわたる研究とパイロットプログラムにもかかわらず、交差点の安全性は、受動的な / 遅い介入、限られた検知と監視、路側無線装置（RSU）の不均一な展開、資金調達のハードル、およびレガシーシステムの技術的な制限により、依然として差し迫った課題です。より安全な交差点のための構成要素は存在しますが、これらの課題により、広範な実装が停滞しています。AWSとTCSは、「交差点安全」問題を再考するために提携し、ハイブリッドアプローチが既存の分散インフラストラクチャとAIエージェントを使用して、より迅速で効率的なソリューションをどのように実現するかを実証しています。 これを具体的にするために、協調AIエージェントによる分散推論が、現実世界のスマートシティ/交通ユースケースである交差点安全システムをどのように強化できるかを説明します。カメラと接続されたインフラストラクチャが実装され、衝突を防止および対応するために連携する、交通量の多い都市部の交差点を考えてみましょう。左折衝突を描いた30秒のサンプルビデオを使用します（図3）。 図3：視認性の高い交差点での左折衝突 エッジ処理はRSUから始まり、カメラがリアルタイムの交通データを収集します。RSUは、IPカメラ、LiDAR、レーダー、V2X通信モジュールなどの複数の検知およびコンピューティング機能を統合して、状況認識を向上させるインフラ構成要素として機能します。CPU/GPU駆動のローカル推論は、衝突などの重大なイベントを検出します。検出されると、オンボード反射エージェントがアクションをトリガーし、インシデントデータをMQTT経由でAWSリージョン内の自律エージェントオーケストレーターとニアエッジの半自律エージェントに送信します。次に、インシデントの処理済みビデオデータは圧縮され（H.265エンコード）、さらなる分析のためにニアエッジ（モバイルコアデータセンター）に送信されます。ニアエッジでは、5Gコントロールプレーンとユーザープレーン機能（UPF）により、RSUとAWSサービス間の低遅延接続が保証されます。AWS Outpostsで実行されている半自律エージェントは、受信メタデータを処理し、より高性能なSLMによって計画された一連のタスクを通じてイベント検出を強化します。オンボードVLMは、ローカルの意思決定をさらに改善し、誤検知を減らし、検出の精度を向上させます。メタデータは、コンプライアンスのためにローカルデータベースに保存されます。より多くのコンテキストが必要な場合、エージェントはAWSリージョンのプライマリエージェントオーケストレーターをトリガーします。ここでは、Amazon Bedrock AgentsとLLMが、交通事故に関するより広範なコンテキストを持つ高度なメタデータを受信します。 Amazon Kinesis Video Streams は、リアルタイムのビデオ取り込みを管理し、 Amazon S3 に匿名化された映像を保存して、より詳細な分析を行います。AWS IoT CoreとAWS IoT SiteWiseは、フリート管理、モニタリング、デバイスオーケストレーションを可能にし、プライベートエンドポイントは、ニアエッジとAWSリージョン間の安全で低遅延の接続を保証します。 図4：インテリジェントな交差点安全のためのエンドツーエンド分散推論アーキテクチャ このセクションでは、分散推論ロジックと、このユースケースのマルチエージェント連携ワークフローについて説明します。 1. ファーエッジ推論: カメラはビデオをRSUにストリーミングし、VLM推論がインシデント（衝突、動作不能な車両、違法駐車、破片、またはくぼみなど）を検出し、インシデントデータをJSONとして、保存された画像/ビデオキャプチャとともに生成します。次に、データは、オンボード反射エージェントに送信されて即時処理が行われると同時に、さらなる分析と応答調整のためにTelcoエッジとAWSリージョンにも送信されます。 a. 単純反射エージェント: インシデントデータは、推論のためにオンデバイスSLMによって駆動される単純反射エージェントをアクティブにします。これは、「if-condition, then-action」ロジックに従う静的エージェントワークフローです。受信コンテキスト（インシデントデータ）をスキャンし、固定ガイドライン（検出精度 > 60％）と比較し、事前に決定されたアクション（緊急派遣通知）を実行します。まだ実装されていませんが、V2Xを介して近くの接続された車にアラートを直接ブロードキャストしたり、交差点の信号機を管理したりできます。 2. ニアエッジ推論: Telco エッジは、受信画像とビデオフィードをインシデント通知とともに受信し、都市全体の視点のために複数のカメラからのデータを集約します。より大きなVLMを使用して、通知の精度と報告された衝突の重大度を検証します。近くの交差点デバイスを参照して、道路状況、交通パターン、および発生しているインシデントを検出し、リアルタイムモニタリングを開始します。 a. 半自律エージェント: Telco エッジは、半自律エージェントの推論を強化する、より高度なSLM/LLMを備えており、意思決定を強化するためにヒューマンインザループ検証を組み込んでいます。これは、意思決定にメモリを使用する目標ベースの推論エージェントです。複数のファーエッジデバイスからのインサイトを集約し、必要な、高度な情報のみをAWSリージョンに転送することで、複雑なシナリオを処理できます。その目標追求の性質により、予想される道路閉鎖、輻輳レベル、および近くの交差点での信号機の状態を推測できます。 3. AWSリージョン推論: AWSリージョンは、エッジデバイスをAWSサービスに接続し、強力なハイブリッドアーキテクチャを作成することにより、集中制御、連携、スケーラビリティを可能にします。AWSリージョンに集約されたデータは、交差点安全マップ、オンデマンドビデオアクセス、およびアラート概要を提供します。さらに、既存の都市交通管理システムと統合されています。また、知覚後の分析と情報に基づいた意思決定のための連携ロジックも含まれています。 a. 自律エージェント: Amazon Bedrockを搭載したAWSリージョンベースの自律エージェントは、プライマリオーケストレーターとして機能します。可能な限り最良の結果のためにトレードオフを評価することにより、学習エージェントを使用して意思決定を最適化します。AWSリージョンのLLMによって駆動されるエージェントは、インタラクションから継続的に学習して、時間の経過とともにパフォーマンスを向上させます。さまざまなモデルとAPIを呼び出すことでタスクを計画および実行し、ファーエッジデバイスとニアエッジデバイスの両方からの結合された入力を分析します。外部APIとAWSサービスにコンテキストインサイトを照会し、緊急アラートのトリガー、インシデントのクリアランス時間の推定、および公的通知の発行などの高レベルのアクションを可能にします。 図5：交差点安全のためのエージェントワークフロー さまざまなフレームワークにわたるLLM搭載エージェント間の相互運用性は、標準化された通信レイヤーを作成し、エージェント間のコンテキスト共有を可能にするエージェントプロトコルを通じて実現できます。これにより、構造化データと非構造化データの両方にアクセスして処理し、外部サービスと対話し、適応可能で連携的なAIエコシステムのために効率的に意思決定を調整できます。自律エージェントの実行は、長期実行型、バースト性、および場合によっては信頼性の低い性質により、インフラストラクチャの課題をもたらします。これらのエージェントは、動的なワークロードを処理し、信頼性を維持するために、スケーラブルなコンピューティングリソースを必要とします。AWSは、オンデマンドスケーリング、フォールトトレランス、および分散処理を提供することで、これらの課題に対処し、自律エージェントを実行するための理想的な環境にしています。AWSインフラストラクチャを活用することで、分散推論アーキテクチャはワークロードを効率的に管理し、リアルタイムの意思決定のための継続的な運用と適応的なリソース割り当てを保証できます。エージェントAI通信は、API、イベント駆動システム、ダイレクトメッセージング、連合学習、知識グラフ、ブラックボード、およびブロックチェーンを通じて行うことができます。最適なアプローチは、エージェントの役割、リアルタイム処理の要件、およびセキュリティの考慮事項によって異なります。 再考された交差点安全ユースケースは、分散AI推論のパイプラインを示しています。即時の知覚と瞬時の物理的アクションのためのファーエッジコンピューティング、簡潔なアラートを伝達する通信ネットワーク、および多面的な応答を調整するAWSリージョンのAIエージェントです。この種のシステムは、効果的にAI搭載の24時間365日の交差点守護者を作成し、衝突を予測、防止、および対応できます。AWS IoT CoreとGreengrassを使用すると、エッジコンポーネントとAWSコンポーネントが確実に同期され、断続的な接続下でも通信できます。一方、Amazon Bedrock Agentsは、従来は直接センサーネットワークであったものに高度な推論をもたらします。このオンサイト認識とAWSクラウドインテリジェンスの融合により、緊急対応時間を劇的に短縮し、事故後の交通の流れを改善し、最終的には人命を救うことができます。 今後の展望 交差点は、ネットワークの拡張になり、通信事業者はそれらをサポートするための統合サービス（接続とエッジコンピューティング）を提供できます。これらは、AI交差点システムに必要な結合組織と分散コンピューティング環境を提供します。これらは、超低遅延リンク（5G/光ファイバー/衛星経由）とエッジコンピューティングノード（MEC）を提供して、リアルタイムの都市全体へのデプロイメントを可能にします。マネージドサービスとネットワークAPIを提供することで、通信事業者は採用を加速できます。その結果、都市はこれらの複雑なネットワークを自ら構築または統合する必要がなく、サービスに加入できます。 交差点にエッジAIをデプロイするには、都市が管理できる、堅牢で安全な、耐候性のあるインフラストラクチャが必要です。既存の筐体（デジタルキャビネット）は、洗練されたコンピューティングを街角に配置することを可能にする保護ハウジングとして機能でき、環境要因や故意に物を壊す人により安全ミッションが損なわれないことを確保します。物理的およびサイバーセキュリティに最初から対処することで（耐候性筐体、バックアップ電源、改ざんアラーム、安全なアクセス制御）、都市と通信事業者は、ダウンタイムや侵入のリスクを最小限に抑えて、多くの交差点にAIハードウェアを自信を持って展開できます。 AWSの接続性は、エッジベースの交差点安全システムの機能を飛躍的に強化します。各交差点をAWSコントロールプレーンに接続することにより、統合管理、集合学習（各交差点がシステム全体の改善に貢献）、および他のサービスとの統合を実現します。 AWS Outposts Family 、 AWS Local Zones 、 AWS Wavelength から、さらにはIoTやAI管理サービスなどのAWSインフラストラクチャは、このような接続されたアーキテクチャを構築するためのツールキットを提供します。その結果、レジリエントでスケーラブルなスマート交差点のネットワークが構築され、街路レベルではミリ秒単位の応答が可能になり、都市レベルではAWSクラウドのインテリジェンスを活用しながら、IoTデバイスの群れのように容易に管理できるようになります。 分散推論の将来は、複雑なマルチノードAIインフラストラクチャをローカルに感じさせるソフトウェア抽象化を提供することにより、エンジニアの開発を簡素化することにもあります。開発と移行の複雑さを軽減することで、開発者は基盤となるハードウェアを気にせずに自律エージェントを構築およびデプロイできます。このアプローチにより、CPU、GPU、およびNPU全体で異種コンピューティングが可能になり、ベンダーロックインを回避しながら、市場投入までの時間を短縮し、より幅広い採用を保証します。標準化されたAPIとAWSクラウドネイティブフレームワークは、スケーラビリティと相互運用性をさらに推進し、AIデプロイメントをよりアクセスしやすく、効率的にします。 結論 協調AIエージェントによる分散推論は、スマートシティ、スマート産業、つまりローカルアクションとグローバルインテリジェンスが連携する必要があるすべての「Smart-X」シナリオで、次世代アプリケーションを可能にする強力なアーキテクチャパターンです。AWS、エッジサービス、および通信ネットワークを使用することで、開発者と設計者は、高速でインテリジェントでスケーラブルなシステムを構築できます。重要なのは、適切なAI機能を適切な場所に分散させることです。今後、設計者は分散を考慮して設計する必要があります。遅延のために重要な推論をエッジにプッシュし、集約された学習のためにAWSクラウドを使用し、エージェントを使用してすべてを結び付けます。これにより、Smart-Xソリューションの可能性を最大限に引き出し、技術的なパフォーマンスの向上だけでなく、接続された世界での安全性、効率、および生活の質の具体的な改善も実現できます。AIの未来は分散型かつ協調型であり、エッジとAWSクラウドの相乗効果によって実現されます。そして、それは私たちの目前に迫った魅力的な未来なのです。 TCS — AWSパートナーの紹介 「企業は、デバイス、エッジAIインフラストラクチャ、通信データセンター、およびクラウド間のシームレスな統合を提供する、真のAIエコシステムの適応性を必要としています。データを自律的に処理し、他のAIエージェント、モデル、およびエンタープライズアプリケーションと連携するエッジのAIエージェントは、リアルタイムのビジネスアプリケーションを多数実現します。分散推論の採用は、最適化されたコストとパフォーマンスで効率的でスケーラブルなデータ処理への道を開きます」– Sujatha Gopal、CTO – Communications Media & Information Services Business Group、TCS TCSは、AWSアドバンストテクノロジーパートナーおよびAWSコンピテンシーパートナーであり、インドに本社を置き、55か国で事業を展開し、さまざまな業界の企業にデジタルトランスフォーメーションおよびテクノロジーサービスを提供することで知られる、ITサービス、コンサルティング、およびビジネスソリューションを提供しています。 その他のリソース TCSへの問い合わせ パートナー概要 AWS Marketplace   Subhash Talluri Subhash Talluriは、AWSのテレコム業界ビジネスユニットのリードAI/MLソリューションアーキテクトです。彼は世界中のテレコム顧客とパートナー向けの革新的なAI/MLソリューションの開発をリードしています。彼は、AWSでクラウド最適化アーキテクチャを通じてスケーラブルで安全かつコンプライアントなAI/MLソリューションの構築を支援するために、エンジニアリングとコンピューターサイエンスの学際的専門知識を提供しています。 Ajay Rane Ajay Raneは現在、Amazon Web ServicesのWW IoTビジネス開発責任者です。彼のチームは、主要な通信サービスプロバイダーと協力してIoTビジネスを変革し、成長を促進しています。Ajayは、イノベーションを通じて価値を提供する実績を持つ、電気通信および半導体業界の顧客志向のベテランです。以前、AjayはSigfoxでビジネス開発担当VPとしてIoTエコシステムパートナーを管理し、MBit Wirelessでマーケティングおよびビジネス開発担当VPとしてLTEチップセットの製品管理をリードしました。Ajayは、11年間にわたってフラッシュメモリ、サーバー、WiMAX、Wi-Fiビジネス内で責任を増大させる職位を歴任したIntelでキャリアをスタートしました。 Awaiz Khan Awaiz Ahmad Khanは、UMTS、LTE、LTE-A、CBRS、5Gにわたる15年以上のRANアーキテクチャ、プライベート5G、スペクトラムイノベーションの経験を持つワイヤレステクノロジーリーダーです。彼は、CBRSと共有スペクトラムモデルを活用して、企業および産業アプリケーション向けのプライベート5Gソリューションの開発において重要な役割を果たしました。AwaizはWin Forumの積極的な貢献者であり、スペクトラム共有フレームワークと相互運用性標準の形成に携わりました。CI/CD自動化、AI駆動RAN最適化、クラウドネイティブ展開における彼の仕事は、複数の業界賞とワイヤレステクノロジーの特許を獲得しています。彼は電気工学の修士号と学士号を取得しています。 Jad Naim Jad Naimは、大規模WANの構築から世界中のモバイルオペレーター向けのOSSおよび計画プラットフォームの設計と実装まで、18年以上の電気通信経験を持っています。AWSでは、Jadはプライベート5Gネットワークの展開、およびローカルブレイクアウト用のローミングゲートウェイに焦点を当てています。JadはIoTと、安全性を向上させ、怪我を防ぐための洞察を提供するためにエッジでインテリジェンスを注入する方法に焦点を当てています。 Ravi Devarasetti Ravi Devarasettiは、TCSの通信・メディア・情報サービス事業グループのCTOオフィスにおいて、新興技術とイノベーション憲章をリードするコンサルティングパートナーです。Raviは通信・IT分野で25年以上の経験を持ち、米国およびヨーロッパの複数のCPSとMSOに対してアーキテクチャ、コンサルティング、E2Eソリューションエンゲージメントに取り組んできました。Raviは、パイロット実行、実現可能性、ビジネスケース準備中の革新的な設計思考を通じて、技術活用と孵化の初期段階で顧客と関わります。彼は革新的技術を成功したビジネスに転換し、エコシステムとパートナーシップを構築することに長けています。彼はOpen Groupのメンバーであり、AEA Coloradoチャプターの議長を務めています。新興技術愛好家を超えて、彼は旅行と新しい場所の探索を愛しています。 この記事はアマゾン ウェブ サービス ジャパンの渡部 勝博が翻訳を担当しました。

本記事は 2025/07/03に投稿された SQL to NoSQL: Modeling data in Amazon DynamoDB を翻訳した記事です。 翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。 この投稿では、既存のデータベース構造とアクセスパターンを分析した パート1 の内容を基に、効果的な Amazon DynamoDB データモデルの設計に焦点を当てます。DynamoDB は、アプリケーションの特定の要件と使用パターンに合わせた異なるデータモデリングアプローチを提供しています。 適切に設計されたデータモデルは、DynamoDB における最適なパフォーマンスとコスト効率をサポートします。ソーシャルメディアプラットフォームの例を通じて、異なるモデリングアプローチがアプリケーションのパフォーマンスと運用コストの両方にどのような影響を与えるかを示しています。 この投稿では、エンティティの特定、テーブル設計の決定、リレーションシップのモデリングアプローチなど、DynamoDB のデータモデルを設計するための戦略について説明します。特定のシナリオを使用してさまざまなモデリング手法を比較し、ユースケースに応じた適切な判断を行えるようにします。 エンティティの特定 DynamoDB のアイテム、属性、および対応するデータ型を定義します。これらは一般的に既存のデータベーススキーマと一致しているはずですが、DynamoDB のモデリングパターンに合わせて調整してください。現在のスキーマ構造を正確に反映させるのではなく、アプリケーションのアクセスパターンに合わせて最適化することに重点を置いてください。以下の点を考慮してください： コアエンティティ – アプリケーションがデータにアクセスし管理する方法に基づいて、主要なビジネスエンティティをリストアップします。例えば、ソーシャルメディアアプリケーションの場合、投稿、ユーザー、コメントなど、アプリケーションが頻繁に操作する中心的なデータ要素を表すエンティティが含まれます。 サポートエンティティ – アプリケーションの機能をサポートするために必要な追加エンティティを特定します： メトリクスやカウントを追跡するためのエンティティ アプリケーションの状態を管理するためのエンティティ 特定のアクセス要件をサポートするためのエンティティ 属性 – 各エンティティについて、既存のテーブル構造ではなく、アプリケーションのニーズに基づいて必要な属性をリストアップします。アプリケーションにおける属性の特性、データ型、使用方法を理解することで、DynamoDB での表現方法を計画するのに役立ちます。例えば、日時フィールドは、クエリとソートの要件に基づいて、ISO 文字列またはエポック番号のいずれかにマッピングする必要があります。 テーブル設計の決定 DynamoDB のアイテムを特定した後、シングルテーブル設計とマルチテーブル設計のどちらを使用するかを評価しました。多くのアプリケーションでは、実装が簡単なマルチテーブル設計から始めることをお勧めします。しかし、私たちのソーシャルメディアアプリケーションでは、要件分析に基づいてマイクロサービスごとにシングルテーブル設計を選択しました： アプリケーションの特性 – データの関連性が非常に高く、関連アイテムを一緒に取得する必要が頻繁にあります。例えば、投稿を表示する際には、同じ操作で関連するコメントとユーザー詳細を取得する必要があります。アプリケーションは主にトランザクションデータを扱い、監査、履歴、分析データの量は多くありません。これらの特性は、自然とシングルテーブルアプローチと適合しています。 パフォーマンスとコストの分析 – シングルテーブル設計では、すべてのデータが 1 つのテーブルに格納されるため、関連アイテムを含む複雑なクエリに対して一貫したパフォーマンスを提供します。キャパシティ管理については、自動スケーリングと簡素化された運用により、ほとんどのワークロードで推奨されるオンデマンドモードで開始しました。使用パターンを分析し、予測可能なワークロードを確立した後、コスト最適化のためにプロビジョンドモードを評価しました。シングルテーブル設計における関連データアクセスの統合されたキャパシティプランニングと効率的な RCU/WCU の割り当ては、プロビジョンドモードのメリットを最大限に活用するのに役立ちました。ストレージの観点からは、データの特性上、テーブル分割することに対して正当化するような顕著な非効率性はありませんでした。 運用上のメリット – サービスごとに単一のテーブルを管理することで、監視、キャパシティプランニング、データモデルの発展が簡素化され、運用上の作業負荷が削減されました。 テーブル設計の選択による影響は、アクセスパターンとデータ特性によって異なります。ユースケースにおけるパフォーマンスとコストへの影響を正確に評価するため、両方のアプローチを代表的な処理量でテストすることをお勧めします。詳細については、 Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 をご参照ください。 パーティションキーとソートキーの定義 SQL クエリ分析から得られた知見を使用して、データの主要なアクセスパターンを特定します。これにより、DynamoDB テーブルの適切な パーティションキー を決定するのに役立ちます。SQL クエリの ORDER BY 句と TOP 句から得られた情報を使用して、複数レベルでのソートが必要な場合には対応する複合ソートキーの使用をするなど、ソートキーの選択を行います。 エンティティ関係のモデリング DynamoDB の柔軟なスキーマは、従来のリレーショナルデータベースとは異なるアプローチを可能にしますが、DynamoDB におけるデータモデリングの戦略とその最適な戦略の評価方法について、いくつか検討する価値があります。 単一アイテム DynamoDB の単一アイテムアプローチは、エンティティと関連データが 1 つのアイテム (最大 400 KB) に収まる場合に効率的です。このモデルでは、関連するデータをすべてまとめて保存することで、高速な読み取りが可能になります。ただし、このアプローチは書き込み操作に影響を与えます。変更を加えるたびにアイテム全体を更新する必要があり、書き込みコスト (WCU) が増加します。書き込みの頻度が高くなるほどコストが上がり、データの整合性を維持する複雑さも増します。このアプローチは、親データと子データが同時にアクセスされることが多く、読み取りコスト (RCU) の削減メリットが書き込みコストの増加を上回るような、読み取り量の多いアプリケーションに特に適しています。子データの読み取りと書き込みの比率を評価し、メリットがデメリットを上回ることを確認することが重要です。 単一アイテム内の子アイテムコレクションのフィルタリングは、フィルター式またはクライアントサイドのフィルタリングでのみ可能です。ただし、DynamoDB はフィルターを適用する前にアイテム全体を読み取るため、RCU の消費量は減りません。 これらのトレードオフを理解し、アクセスパターンを慎重に評価することで、高速な読み取りと、書き込みコストの増加やフィルタリングの複雑さのバランスを取りながら、このデータモデリングパターンがユースケースに適しているかどうかを判断できます。 垂直パーティショニング DynamoDB の 垂直パーティショニング は、特定の属性に対する絞り込みクエリに有用です。このパターンでは、同じパーティションキーと異なるソートキーを持つ隣接するアイテムに関連データを保存します。 主なメリットには以下のようなものがあります: クエリの柔軟性 – 子アイテムを単独で、または親アイテムと一緒に効率的に取得できます 書き込みのきめ細かい制御 – 親アイテムを書き換えることなく、個々の子アイテムを更新できます ただし、このアプローチでは、エンティティ間のフィルタリングがより複雑になります。親と子の属性の両方でフィルタリングを行うには、一部の親の属性を非正規化して子アイテムにする必要があります。親の属性が頻繁に変更される場合、書き込みコストを増加させる可能性があります。例えば、アクティブユーザーのすべての動画投稿を検索したい場合を考えてみましょう。これには 2 種類のフィルタリングが必要です。1つはアクティブユーザー（親エンティティ）の検索で、もう1つはユーザーの投稿のうち動画であるもの（子エンティティ）の検索です。1 つの解決策は、ユーザーのステータスを各投稿レコードに直接追加して非正規化することです。これによりクエリは簡単になりますが、欠点もあります。ユーザーのステータスが変更されるたびに、そのユーザーのすべての投稿でステータスを更新する必要があります。これにより書き込み操作が増加し、結果として運用コストが上がります。このようなクエリの簡素化と書き込み効率のトレードオフは、DynamoDB の設計パターンでよく考慮される点です。 重要なのは、アクセスパターンを慎重に分析し、クエリの柔軟性、書き込み管理、エンティティ間のデータ非正規化のコストのバランスを取ることです。 ユーザーが複数の投稿を作成できるソーシャルメディアプラットフォームを想像してみてください。次の図は、ユーザーと投稿の関係を示しています。このシナリオでは、アクセスパターン、使用統計、アイテムサイズを慎重に分析することで、DynamoDB の最適なデータモデリングアプローチを決定する方法を探ります。この包括的な評価により、特にソーシャルメディアアプリケーションのニーズに合わせた、パフォーマンス、コスト効率、スケーラビリティのバランスを取る戦略を選択する際の指針になります。 アイテムサイズに関する注意事項 DynamoDB のデータモデルを設計する際は、アイテムのサイズを見積もってください。DynamoDB では 1 アイテムあたり 400 KB の制限があるため、データの平均サイズと最大サイズの両方を把握しておくと便利です。 ソーシャルメディアアプリケーションのユーザーと投稿モデルについて、以下の点を考えてみましょう： ユーザーのプロファイルデータの平均サイズを見積もります ユーザーあたりの投稿の平均数と、その一般的なサイズを計算します これらの見積もりは、意思決定の指針となります。RCU と WCU はアイテムサイズに比例するため、最適なデータモデリング戦略を設計するには、平均アイテムサイズを評価することが重要です。 アクセスパターン アプリケーションのアクセスパターンを理解することは、効率的な DynamoDB モデルを設計する上で重要です。以下の点を考えてみてください： 投稿に適用されたフィルターに基づいてユーザーを取得する必要がありますか？ 一部のクエリでユーザープロファイルデータと投稿の両方を同時にフィルタリングする必要がありますか？ ユーザーの最新 N 件の投稿への迅速なアクセスが必要ですか？ コメントの多い N 件の投稿を取得する必要がありますか？ これらのアクセス要件は、最適なパフォーマンスを実現するためのパーティションキー、ソートキー、およびセカンダリインデックスに関する決定に影響を与えます。フィルター条件は、単一アイテムアプローチの実現可能性を判断する際にも役立ちます。例えば、投稿フィルターに基づいてユーザーを特定する必要がある場合、単一アイテムアプローチは効率的ではない可能性があり、別のデータモデリングアプローチを検討する必要があるかもしれません。 使用状況メトリクス データの読み取りと書き込みのパターンを分析して、最適な戦略を決定します。読み取りと書き込みの比率を理解するために、以下の点を考えてみてください： 投稿とユーザープロファイルデータが一緒に参照される頻度はどのくらいですか？ 投稿の更新頻度は、ユーザープロファイルの変更頻度と比較してどれくらいですか？ ユーザープロファイルと投稿において、最も頻繁に変更される属性は何ですか？ 投稿カウンター（いいねやシェアなど）の読み取り頻度はどのくらいですか？ 投稿カウンターの更新頻度は、投稿コンテンツの更新頻度と比較してどうですか？ データモデリング戦略の選択 アイテムサイズ、アクセスパターン、使用状況のメトリクスに関する情報を収集したので、次のセクションでは、これらのデータポイントを使用して、DynamoDB のソーシャルメディアアプリケーションに最適なデータモデリング戦略を評価し、選択する方法を説明します。 シナリオ1 ：1 対 N の関係 次の表は、ユーザー情報 (各 20 KB) と投稿コンテンツ (各 5 KB) の 1:N の関係を、単一のアイテムとして保存した場合と垂直パーティションした場合を比較したものです。 単一アイテム 垂直パーティション 30 件の投稿のアイテムサイズ ユーザーと投稿: 20 KB + 30*5 KB = 170 KB ユーザーアイテム = 20 KB 1 番目の投稿アイテム = 5 KB 2 番目の投稿アイテム = 5 KB . . 30 番目の投稿アイテム = 5 KB ユーザー情報を含むユーザーの上位 10 件の投稿を取得するための DynamoDB API コール数: 1,000 読み取り/時間 1,000 2,000* ユーザー情報を含むユーザーの上位 10 件の投稿を読み取るための RCU (結果整合性のある読み込み): 1,000 読み取り/時間 170 KB/4 KB = 42.5 * 0.5 RCU = 21.25 ~ 21.5 RCU 1000 *21.5 RCU = 21,500 RCU ユーザー情報: 20 KB ~ 2.5 RCU 10 件の投稿: 50 KB/4 KB = 12.5 * 0.5 RCU = 6.25 RCU ~ 6.5 RCU 1000 * 6.5 RCU + 1000 *2.5 RCU = 9000 RCU ユーザーメールアドレスを更新するための WCU: 10 書き込み/時間 170 WCU (170 KB のデータを更新) 10*170 WCU = 1,700 WCU 20 WCU (20 KB のユーザーアイテムのみ更新) 10*20 WCU = 200 WCU * 必要な API コールの総数は、アプリケーションの構造、特にデータアクセスフレームワーク、DynamoDB テーブル設計、クエリパターンによって異なります。この特定のユースケースでは、前述の考慮事項により、必要なデータを取得するために読み取り操作ごとに 2 回の個別の API コールが必要です。 シナリオ2 ：1 対 1 の関係 次の表は、1 つのアイテムとして保存された投稿 (各 4 KB) と投稿カウンター (0.5 KB) の 1:1 の関係を、垂直パーティションと比較したものです。 単一アイテム 垂直パーティション 投稿あたりのアイテムサイズ 投稿 + 投稿カウンター: 1 KB + 5 KB = 6 KB 投稿アイテム = 5 KB 投稿カウンターアイテム = 1 KB 投稿カウンター付きの投稿を読み取るための DynamoDB API コール数: 1,000 読み取り/時間 1,000 2,000* 投稿カウンター付きの投稿オブジェクトの読み取り: 1,000 読み取り/時間 6KB ~ 1 RCU 1000 * 1 RCU = 1,000 RCU 投稿: 5KB ~ 1 RCU 投稿カウンター: 1 KB ~ 0.5 RCU 1000 * 0.5 + 1000 * 1 = 1,500 RCU 投稿カウンターの更新: 10 更新/時間 6 KB ~ 6 WCU 10 * 5 = 60 WCU 1 KB ~ 1 WCU 10 * 1 WCU = 10 WCU 投稿カウンターの更新: 1,000 更新/時間 6 KB ~ 6 WCU 1,000 * 5 = 6,000 WCU 1 KB ~ 1 WCU 1,000 * 1 WCU = 1,000 WCU * 必要な API コールの総数は、アプリケーションの構造、特にデータアクセスフレームワーク、DynamoDB テーブル設計、クエリパターンによって異なります。この特定のユースケースでは、前述の考慮事項により、必要なデータを取得するために読み取り操作ごとに 2 回の個別の API コールが必要です。 この分析では、DynamoDB における 1:N の関係 (ユーザーと投稿) と 1:1 の関係 (投稿とカウンター) の両方について、単一アイテムと垂直バーティションを比較しています。1:N のシナリオでは、垂直パーティションは API コール数が増加しますが、RCU/WCU のコストを大幅に削減します (読み取りの場合は 21,500 RCU から 9,000 RCU へ、書き込みの場合は 1,700 WCU から 200 WCU へ)。同様に、1:1 の関係では、垂直パーティションにより API コール数は 2 倍になりますが、特に頻繁な更新において大幅な WCU の削減 (6,000 WCU から 1,000 WCU へ) を実現します。ただし、これらの結果は、ここで議論されたユースケース特有のものであることを理解することが重要です。ここで収集したデータを異なるシナリオに適用する前に、慎重な検討することをお勧めします。 結果 評価した特定のユースケースについて、以下のことが判明しました。 1:1 の関係 (投稿と投稿カウンター): 単一アイテム設計では、読み取りの API コールと RCU が少なくなりましたが、更新時の WCU 消費が増加しました 垂直パーティション設計では、より多くの API コールが必要でしたが、特に頻繁な更新において WCU の使用がより効率的でした 1:N の関係 (ユーザーと投稿): 単一アイテム設計では、API コールは少なくなりましたが、アイテムサイズが大きくなることで RCU の消費量が大幅に増加し、更新時の WCU コストも大幅に増加しました 垂直パーティション設計では、API コールの数は 2 倍になりましたが、RCU と WCU 両方の消費量を大幅に削減でき、スケールした際の費用対効果が高まることがわかりました。 まとめ 重要なポイントは、具体的な結果だけでなく、これらの結論に至るまでの分析プロセスにあります。どのようなユースケースでも、パフォーマンスのニーズとコストに関する考慮事項のバランスを取った最適なデータモデル戦略を定義するには、同様の綿密な分析と思考プロセスが不可欠です。更新頻度、読み取りパターン、データスケーリング要件、エンティティ間の関係の特性など、さまざまな要因を慎重に評価する必要があります。 パート 3 では、アプリケーションのデータアクセスレイヤーをこれらのデータモデルで効果的に動作するように適応させ、DynamoDB の機能を活用できるようにする方法を探ります。 著者について Ramana Kiran Mannava Ramana は、AWS プロフェッショナルサービスのリードコンサルタントであり、.NET ワークロードの最新化と AWS 上のクラウドベースソリューションの構築に関する専門知識を持っています。彼はデータベース技術とクエリ最適化にも情熱を持っています。 Akber Rizwan Shaik Akber は、 AWS プロフェッショナルサービスのリードコンサルタントです。彼はクラウドベースのソリューションを使用して、お客様の .NET ワークロードを AWS に移行し、最新化するのを支援しています。 Mahesh Kumar Vemula Mahesh は、AWS プロフェッショナルサービスのリードコンサルタントです。彼はサーバーレス愛好家であり、クラウドベースのソリューションを用いて顧客の .NET ワークロードの最新化を支援しています。

はじめに ビルド、テスト、デプロイのプロセスを自動化することは、モダンなソフトウェア開発とデリバリーの基本的な要素です。継続的インテグレーション (CI)、継続的テスト (CT)、継続的デプロイ (CD) の強力なパイプラインを実装することで、組織は効率を高め、市場投入までの時間を短縮します。 このブログ記事では、柔軟な環境でコンパイルと機能同等性テストを自動化する継続的インテグレーション、継続的テスト、継続的デリバリー (CI/CT/CD) パイプラインを紹介します。これにより、本番環境にあるようなプレッシャーや制約を受けることなく、問題を特定し、アプリケーションのコア機能を検証することができます。検証後、パイプラインはマネージド環境にアプリケーションをデプロイし、受け入れテストや本番稼働前の動作確認を行います。 AWS Blu Age でリファクタリングされたアプリケーションに対する CI/CT/CD の実装 CI/CT/CD を実装すると、ソフトウェア開発とデプロイプロセスに付加価値が組み込まれます。その価値は、ソフトウェア開発ライフサイクルを速く回し、コード品質を向上させ、開発およびデプロイプロセスの全体的な効率と信頼性を高めることにあります。AWS Blu Age でリファクタリングされたアプリケーションは、Java Spring Boot (バックエンド) と Angular (フロントエンド) アプリケーションへの変換により、メインフレームアプリケーションをモダナイズしたものです。AWS Blu Age ツールを使用すると、COBOL、PL/I、RPG/400 で記述されたレガシーアプリケーションをモダンなアプリケーションに自動的に変換できます。このアプローチにより、既存のビジネスロジックへの投資を抑えながら、次のようなメリットが得られます。 新しいテクノロジーの使用によるアジリティの向上 モダンスタックに精通した開発者から成る幅広い人材プールへのアクセス モダナイゼーションプロジェクトの加速 リファクタリングプロセスにより、基盤となるデータベースとデータモデルが最新の形式に変換され、アプリケーションの機能と互換性が強化されます。 継続的テストの実践により CI/CT/CD パイプラインを確立することは、モダナイズされたシステムの機能をレガシーシステムと同等に保つために不可欠です。テストはモダナイゼーションプロジェクトの労力と予算の 60 ～ 70% を消費する可能性があるため、ビジネス価値を迅速に実現するためにはテストの自動化が不可欠です。 CI/CT/CD パイプラインステージ パイプラインは次の 5 つのステージで構成されています。 アプリケーションソースコードの取得 アプリケーションビルド アプリケーションの機能同等性テスト 手動承認 マネージド環境でのデプロイ CI/CT/CD パイプラインのアーキテクチャとデプロイ 図 1 は、 AWS CodePipeline を使用してモデル化された CI/CT/CD パイプラインの 5 つのステージの概要を示しています。関連するインフラストラクチャは AWS CloudFormation によってプロビジョニングされます。 CloudFormation は、インフラストラクチャのプロビジョニング、再利用性、一貫性、信頼性を実現する強力な IaC (Infrastructure as Code) サービスです。これにより、アプリケーションの実行に必要なリソースをモデル化します。 AWS CodePipeline は、継続的インテグレーションと継続的デリバリーのサービスであり、ソフトウェアリリースプロセスをモデル化して自動化します。パイプラインはワークフローを定義し、開発段階とデプロイ段階でコード変更がどのように進行するかを記述します。パイプラインの各ステージは、コードのビルドやテスト環境へのデプロイなどの一連のアクションで構成されています。 図 1 — CI/CT/CD パイプラインのアーキテクチャ図 アーキテクチャ図に示されている各ステージのタスクについて、次のセクション以後で説明します。 ステージ 1 — アプリケーションコードの取得 前提条件 開発チーム用に Git リポジトリが作成され、設定されていること AWS Blu Age Transformation Center から生成されたアプリケーションソースコードが Git リポジトリにロード済であること AWS CodePipeline は、Git リポジトリのメインブランチへのコミット時にアクティブ化されるようセットアップと設定が完了していること 開発プロセス 開発者は Git リポジトリをローカルの開発環境に複製します。 開発者は機能やバグの修正用に新しいブランチを作成します。 開発者は、チームのコーディング標準とベストプラクティスに従って、必要なコード変更を行います。 開発者はローカルテストを実施してコードの品質と機能を確認します。 開発者は、コミットメッセージに説明を記述して、変更をローカルブランチにコミットします。 開発者はブランチを Git リポジトリにプッシュします。 AWS CodePipeline のアクティベート メインブランチにマージすると、AWS CodePipeline が自動的にアクティベートされます。 ステージ 2 — アプリケーションのビルド AWS CodePipeline は CI/CT/CD パイプラインの一部として AWS CodeBuild ステップを開始します。このステップでは、AWS CodeBuild は AWS Blu Age Build ツールを使用して、レガシー言語からの変換によってモダナイズされた Java アプリケーションをビルドします。 ビルドプロセス CodeBuild はパイプラインの前段のステージからソースコードを取得します。 CodeBuild は AWS CodeArtifact に接続して、必要な AWS Blu Age ランタイムライブラリをダウンロードします。 2 つの異なる WAR (Web Application Archive) ファイルが生成されます。 HTML、JavaScript、CSS ファイルなどの静的 Web サイトアセットで構成されるフロントエンドアプリケーション: この構造により、柔軟なデプロイオプションが可能になります。フロントエンドは Apache HTTP Server や Amazon CloudFront などのさまざまなコンテンツ配信ネットワーク (CDN) ソリューションでホストできるため、コンテンツ配信とユーザーエクスペリエンスが最適化されます。 バックエンドアプリケーション CodeBuild は WAR ファイルを Amazon S3 に安全に保存します。 このアプローチにより、フロントエンドコンポーネントとバックエンドコンポーネントを明確に分離しやすくなり、各階層の独立したスケーリングと管理が可能になります。また、フロントエンドをエッジロケーションにデプロイしてレイテンシーを短縮し、バックエンドをより制御された環境でホストしてセキュリティとデータ管理を強化することもできます。 ステージ 3 — アプリケーションの機能同等性テスト レガシーメインフレームアプリケーションと AWS クラウド上のモダナイズされたメインフレームアプリケーションが機能的に同等であることを検証するために、 AWS Mainframe Modernization Application Testing が使われます。このテストフレームワークは、モダナイゼーションプロセス全体を通じて機能の一貫性を検証するように設計されています。 前提条件 テストチームは AWS Mainframe Modernization Application Testing 内で以下のアーティファクトを作成します。 テストケース: テストアクションの最小単位です。テストケースを作成する際に、移行元のシステムと移行先のシステムの間の機能的な同等性を確認できるよう、ユーザーは比較対象のデータ型を識別します。 テストスイート: 一連のテストケースを順番に実行します。 テスト環境設定: これには、反復可能なテストを実施するために必要なすべてのパラメーターとリソースが含まれます。CloudFormation テンプレートは、テスト環境で反復可能なテストを実行するために必要な初期データおよび設定パラメーター (リソース) の設定に使用されます。このアプローチにより、テストを繰り返しても一貫性と再現性が保証されます。 テストプロセス テストプロセスには主に 3 つの段階があります。 Record ユーザーは各テストケースの参照データをメインフレーム上に作成します。 この参照データには、ソースメインフレームのアーティファクト、データセット、リレーショナルデータベースの Change Data Capture (CDC) ジャーナルが含まれます。 Record ステージは通常、プロジェクトの開始時に 1 回実行して、必要な参照データをすべて収集します。 Replay 本機能により、移行先の環境でテストスイートを実行します。 個々のテストケースで生成されたデータセット、データベース変更、3270 画面をキャプチャします。 Compare 本機能は、移行元のテストの参照データと移行先のリプレイデータを一通り比較します。 結果は、同一データ、異なるデータ、同等データ、または欠損データとして分類されます。 Compare の出力は Amazon S3 に保存され、指定された承認者による審査を受けます。 CI/CT/CD パイプラインは、Replay および Compare の各ステージを自動的に開始し、開発プロセス全体を通して一貫性のある反復可能なテストを保証します。 このテストの主な目的は、モダナイズされたアプリケーションがメインフレームアプリケーションと同じように動作することを検証することです。左記は、参照データとリプレイデータの不一致を綿密に特定することで達成されます。これにより、モダナイゼーションプロセスが確実に成功し、信頼できるものになります。 ステージ 4 — 手動承認 パイプラインの一時停止 機能同等性テストが完了すると、AWS CodePipeline は手動承認段階で自動的に停止し、本番前または承認環境にデプロイされます。 承認プロセス AWS CodePipeline は、プロジェクトマネージャ、品質保証 (QA) リーダー、個別に設定したレビュー担当者などの関係者に保留中のレビューを通知します。 レビュー担当者は Amazon S3 に保存されている比較レポートにアクセスします。これらのレポートには次のものが含まれます。 参考データ 再生データ レビュー担当者はレポートを審査して承認します。これで AWS CodePipeline が再開されます。 ステージ 5 — マネージドランタイム環境でのアプリケーションの展開 最後のステージは、承認されたアプリケーションを AWS Mainframe Modernization Automated Refactor のマネージドランタイムにデプロイすることです。AWS CodeBuild は、AWS Cloud Development Script (AWS CDK) を活用したスクリプト (Python スクリプトなど) を呼び出すために使用されます。このスクリプトは次のシナリオに基づいてタスクを実行します。 シナリオ 1: AWS Mainframe Modernization 環境が存在しないことを、AWS Systems Manager (SSM) Parameter Store を使用して確認しました。このときの AWS CodeBuild のステップ: AWS Mainframe Modernization のマネージドランタイム環境を作成し、環境 ID を SSM に保存します。 Mainframe Modernization アプリケーションを作成し、アプリケーション ID を SSM に保存します。 アプリケーションをマネージドランタイムにデプロイします。 アプリケーションを起動します。 シナリオ 2: AWS Mainframe Modernization 環境とアプリケーションは既に存在します。このときの AWS CodeBuild のステップ: 実行中のアプリケーションを停止します。 アプリケーションを更新して、AWS Mainframe Modernization マネージドランタイム環境に新しいバージョンを作成し、新しいアーカイブファイルを反映します。 アプリケーションを起動します。 環境とアプリケーションの可用性をほぼ 100% にするには、ブルー/グリーンデプロイメントを使います。ブルーは現在のアクティブなインスタンス、グリーンは新しいインスタンスを表します。テスト完了後、トラフィックはグリーンのインスタンスにリダイレクトされ、問題が発生した場合はブルーのインスタンスにトラフィックをリダイレクトしてロールバックできます。これは以下のように実装されます。 シナリオ 1: AWS Mainframe Modernization 環境が存在しないことを、SSM Parameter Store を使用して確認しました。このときの AWS CodeBuild のステップ: 2 つの AWS Mainframe Modernization マネージドランタイム環境 (ブルーとグリーン) を作成し、その環境 ID を SSM に保存します。 Mainframe Modernization アプリケーションを作成し、アプリケーション ID を SSM に保存します。 作成したマネージドランタイム環境の 1 つにアプリケーションをデプロイします。これを (ブルー環境の) 環境 ID として SSM 内でマークします。 アプリケーションを起動します。 シナリオ 2: AWS Mainframe Modernization 環境とアプリケーションは既に存在します。このときの AWS CodeBuild のステップ: 新しいアーカイブファイルを反映する新しい Mainframe Modernization アプリケーションを作成します。 新しいアプリケーションを、AWS Mainframe Modernization のグリーン環境にデプロイします。 アプリケーションを起動します。 Amazon Route 53 のアプリケーション参照を更新し、新しいアプリケーション属性を反映するようにバッチ実行することで、トラフィックをグリーン環境に切り替えます。 シナリオ 2 では、CI/CT/CD パイプラインを続行する前に手動承認が必要です。このステップにより、SSM では前のアプリケーションが停止/削除され、グリーンの環境がブルーに更新され、その逆の環境が更新されます。 AWS Mainframe Modernization サービス内で Infrastructure as Code (IaC) を使用するメリット Infrastructure as Code には、開発者やビジネスオーナーに役立つ複数の機能があります。主なメリットは以下のとおりです。 ネットワーク、コンピューティング、データベース管理などのインフラストラクチャーのプロビジョニングを自動化し、迅速化します。コードを使用して手順を簡素化し、チームの効率とスピードを向上させます。 手動によるインフラストラクチャーのプロビジョニングと構成における人為的ミスを軽減します。標準化され、文書化された手順とログが提供されるため、新メンバーのオンボーディングが容易になります。 人為的ミスや非互換性を減らし、リソースの浪費やダウンタイムを防ぐことで、導入と構成の一貫性を高めます。 繰り返し使用可能で、事前定義された環境仕様を維持することで、同じ構成での再導入が可能になり、構成のずれを自動的に修正できます。 サービスのプロビジョニングとセキュリティ標準の導入を標準化し、自動化することによってセキュリティを強化し、頻繁なセキュリティレビューや承認の必要性を減らします。 まとめ 本ブログでは、既存のビジネスロジックを維持しながら、レガシーアプリケーションをモダンなアプリケーションにリファクタリングするサービスである AWS Mainframe Modernization を使用する利点について概説しました。左記のサービスを AWS Mainframe Modernization Application Testing および CI/CT/CD パイプラインと組み合わせて、ソフトウェアの開発とデプロイを加速します。CI/CD パイプラインは自動テストと統合されているため、レガシーシステムとモダナイズされたシステムの機能が同等であることが保証され、コア機能の効率的な検証とマネージド環境へのスムーズなデプロイが可能になります。このアプローチは俊敏性を高め、運用効率を高め、より幅広い開発者の人材プールへのアクセスを可能にし、モダナイゼーションプロジェクトの成功に貢献します。詳細については、 AWS Mainframe Modernization のページ をご覧ください。 著者 <!-- '"` --> Yann Kindelberger Yann Kindelberger は、アマゾンウェブサービスの Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Sairam Rajagopalan AWS の Partner Solutions Architect である Sairam Rajagopalan は、メインフレームのモダナイゼーションを専門としています。Sairam は、メインフレーム関連の提案やプロジェクトで 20 年以上の経験を持ち、過去 10 年間はレガシーシステムの変革に専念してきました。AWS では、グローバルシステムインテグレーター (GSI) のパートナーと協力して、顧客のメインフレームワークロードをモダナイズし、デジタルトランスフォーメーションの複雑さを乗り越えられるよう支援しています。 Santosh Singh Santosh Singh は、AWS プロフェッショナルサービスの Mainframe Modernization Architect です。メインフレームシステムとクラウドの分野で 18 年以上の経験があり、メインフレームの移行とモダナイゼーションに重点を置いています。現在の役職では、Santosh はお客様と緊密に連携してメインフレーム環境を評価し、移行戦略を策定し、AWS クラウドへの移行を成功させています。Santosh は、メインフレームモダナイゼーションの活動に加えて、生成 AI テクノロジーに焦点を当てた AWS の製品チームやサービスチームとも協力しています。

AWS Summit Japan は、クラウドによるイノベーションを追求する全ての方々のための年に一度のイベントです。2025年は6月25日と26日に開催され、延べ3万6千人以上の来場者で賑わいました。今回も未来を共に創造するビルダーたちが一堂に会し、アマゾン ウェブ サービス (AWS) について学び、ベストプラクティスを共有し、情報交換を行う場となりました。 ここでは、グローバル各国で毎年開催されるAWS Summitの中でも初めての展示となり注目を集めた、AWS認定デバイスウォールについてご紹介したいと思います。 手短に展示内容を把握したい方は、以下の写真をクリックして2分弱の 紹介動画 を御覧ください。各展示デバイスのクローズアップ・ショットを含めてご覧になれます。 AWS 認定デバイスウォール 現代のデジタル変革において、AWSのクラウドソリューションは単独で機能するだけではなく、オフィス・工場・家庭に設置される、カメラ・エッジサーバー・ゲートウェイ・産業用 PC・PLC・シンクライアントなど様々なデバイスと有機的に連携することで、その真の価値を発揮します。この展示では、19社のパートナーから28種類の多種多様なAWS認定デバイスを一堂に集めることで、AWSが実現する『クラウドからエッジまでの統合されたソリューション』の可能性を体感いただきました。 AWS 認定デバイス 今回展示させていただいたデバイスはいずれも AWS の デバイス認定プログラム によって認定を取得したデバイスであり、デバイスパートナーによってAWSのIoTサービスとの接続性が確認されています。これらのデバイスは AWS Partner Device Catalog にリストされており、その数は2025年6月現在、グローバルで494が登録されています。お客様はこのカタログからニーズにあった動作確認済みのデバイスを 検索 して購入することで、すぐにプロジェクトを開始することができます。 展示デバイス一覧 今回展示したデバイスおよび認定されているAWSサービスの一覧を掲載します（アルファベット順）。今回は展示スペースの関係で、パートナあたり最大2台の展示となりましたが、 AWS Partner Device Catalog には展示しきれなかったデバイスも多く登録されています。今回の展示デバイスに興味をもたれましたら、表中のリンクから詳細を確認してみてください。 カテゴリ パートナ名 デバイス名 認定サービス カメラ Axis Communications AB P1465-LE Bullet Camera Amazon Kinesis Video Streams P3265-LV Dome Camera Amazon Kinesis Video Streams i-PRO Co., Ltd. i-PRO moduca Lens Trial Kit Amazon Kinesis Video Streams エッジゲートウェイ インダストリアルエッジ Advantech Co., Ltd. AIR-030 AWS IoT Greengrass ECU-1251 V2 AWS IoT Greengrass Belden Belden OpEdge-8D AWS IoT Greengrass CloudRail.Box Max AWS IoT Core Contec Co., Ltd DX-U1220 AWS IoT Greengrass HARMONIX Co., Ltd. SOCAN-AG4-JPN AWS IoT Core AWS IoT Greengrass Mitsubishi Electric Corporation MELIPC MI2012-W AWS IoT Greengrass OMRON SOFTWARE Co., Ltd. OMRON NYB55 Series Industrial Box PC AWS IoT Greengrass Siemens Digital Industries Software SIMATIC_IPC PX-39A AWS IoT Greengrass SIMATIC_IPC BX-59A AWS IoT Greengrass Takebishi corporation DeviceGateway DGW-C10 AWS IoT Core DeviceGateway DGW-W710 AWS IoT Core PLC Yokogawa Electric Corporation e-RT3 Plus (F3RP70-2L) AWS IoT Greengrass LoRaWAN デバイス/ゲートウェイ Oi Electric Co.,Ltd. BRICK eIoT LoRaWAN + AWS Starter Kit (OiNET-937B) AWS IoT Core for LoRaWAN Semtech LoRa Edge Tracker Reference Design AWS IoT Core Device Location マイコン Atmark Techno, Inc. Armadillo-IoT Gateway A9E Cat.1 bis+WLAN model AWS IoT Greengrass Armadillo-IoT Gateway G4 LTE+WLAN model AWS IoT Greengrass CORE CORPORATION GR-ROSE FreeRTOS Espressif Systems (Shanghai) Co., Ltd. ESP32-WROOM-32 DevKitC FreeRTOS ESP32-C3 AWS IoT ExpressLink Module AWS IoT ExpressLink Renesas Electronics Corporation da16k-ckra6m5 AWS IoT Core Renesas CK-RX65N v2 (Wi-Fi) FreeRTOS STMicroelectronics STM32L4+ Discovery Kit IoT Node FreeRTOS B-U585I-IOT02A Discovery Kit FreeRTOS Ublox USB-NORA-W256AWS AWS IoT ExpressLink まとめ AWS IoT と AWS 認定デバイスは、PoC からエンドツーエンドの商用ソリューションにわたって、IoT システムの複雑さを取り除きつつ、お客様の実際のビジネスに役立つソリューションをサポートします。今後もAWSは、パートナー企業の皆様と連携しながら、クラウドとエッジを統合したイノベーティブなソリューションの創出を支援させていただきます。 展示チーム 川崎 裕希 ソリューションアーキテクト AWSにてソリューションアーキテクトとして、製造業のお客様のIT活用によるお困り事解決を支援しています。 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。 渡邉 聡 プロトタイピングソリューションアーキテクト AWS では IoT、AI などを活用したプロトタイピング支援を行うソリューションアーキテクトとして、主に製造業のお客様を中心に支援しています。 山本 直志 Industry Specialist Solutions Architect 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 井上 昌幸 IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。あなたのとっておきのアイデアを AWS と一緒にカタチにしましょう。 &nbsp;

本記事は 2025/07/03に投稿された SQL to NoSQL: Planning your application migration to Amazon DynamoDB を翻訳した記事です。 翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。 リレーショナルデータベースから Amazon DynamoDB に移行する組織は、データモデルとアクセスパターンを再設計する際に課題に直面することがよくあります。アプリケーションの機能を維持しながら最適なパフォーマンスを実現するためには、クエリ機能、データモデリングアプローチ、アプリケーションアーキテクチャの根本的な違いを理解することが不可欠です。 実際の例でこれらの課題を説明します。急成長している SNS プラットフォームでは、リレーショナルデータベースが複数のテーブル間の結合が必要な複雑なクエリに苦戦しており、特に人気の投稿や有名人とのやりとりなどのコンテンツで顕著です。ユーザー数が今後大幅に増加すると予測されており、既存のアーキテクチャのスケーラビリティに懸念が生じています。数千人の同時ユーザーがいるバイラルイベントでは、人気コンテンツの複雑な結合クエリに負荷がかかり、現在のアーキテクチャではプラットフォームの成長に伴うスケーラビリティニーズを満たせない可能性があることを示唆しています。 この記事は SQL から DynamoDB に移行する際の効果的な移行方法を解説するシリーズの第1回目です。DynamoDB データモデル設計に役立つデータベーススキーマの分析、クエリパターン、使用状況のメトリクスに焦点を当てて、既存のデータベース構造とアクセスパターンを分析して移行の準備方法を検討します。今後の記事では、データモデリング戦略とデータアクセスレイヤーの最新化について説明します。 リレーショナルデータベースと NoSQL データベースの比較 アプリケーションを従来のリレーショナルデータベースから DynamoDB に移行する際、リレーショナルデータベース同士の移行とは大きく異なる点がいくつかあります。これらの違い (次の表を参照) を理解することが、モダナイゼーションの成功には不可欠です。 項目 リレーショナルデータベース Amazon DynamoDB クエリ言語 構造化されたクエリパターンを使用する SQL を使用 最適化されたパーティションキーとソートキーへのアクセスにより、一貫した一桁ミリ秒のレイテンシーを提供する API ベースの操作を提供 データモデル 確立された正規化されたデータ構造を使用 パフォーマンスとスケーラビリティを最適化した柔軟な非正規化データモデリングを提供 データアクセスフレームワーク Entity Framework や Hibernate などの成熟した ORM フレームワークを使用 馴染みのあるオブジェクト指向パターンを維持しながら、複数のプログラミング言語に対して包括的かつ高パフォーマンスを実現する専用ライブラリを備えたネイティブ SDK を提供 リレーショナルデータベースから別のリレーショナルデータベースへの移行は、基本的な構造やアクセスパターンが類似するため、データアクセス層への影響は比較的小さいです。DynamoDB への移行では、その強力な NoSQL 機能を活用する異なるアプローチが導入されます。データモデル、クエリ言語、アクセスパターンの変更により、アプリケーションは DynamoDB の高いパフォーマンスとスケーラビリティを活用できるようになります。チームは DynamoDB の設計原則に合わせてデータアクセス層を適応させ、一貫したパフォーマンスと効率性を最適化できます。 さらに、従来のリレーショナルデータベースの移行では、データベースチームが主にデータベース設定を担当しますが、アプリケーションチームの関与は限られていることがよくあります。しかし、DynamoDB に移行する場合、アプリケーションチームとデータベースチームの協力が重要になります。アプリケーションチームは、データベース専門家と密接に協力して、アプリケーションのデータアクセス要件に合わせた最適な DynamoDB データモデルを設計する必要があります。この協力体制が、DynamoDB NoSQL データベースへの移行を成功させる鍵となります。 データモデリングのための分析 リレーショナルデータベースから DynamoDB への移行では、パフォーマンスとコスト効率を最適化するために、慎重な計画が必要です。まず、要件を定義するために、既存のリレーショナルデータベースの複雑さを評価します。この評価に基づいて、ワークロードに合わせて効果的にスケーリングできる適切な DynamoDB データモデルを設計します。入念な初期評価により、DynamoDB への移行がスムーズになります。移行プロセスでは、現在のデータ構造を分析し、アクセスパターンを特定し、DynamoDB のキーと値のデータモデルに最適化します。 ソーシャルメディアプラットフォームのユースケース この記事を通して概念を説明するために、ユーザーが投稿を作成し、投稿に対してコメントや「いいね」をつけられるソーシャルメディアプラットフォームを使用します。次の図に示すように、主要なエンティティには、投稿を作成するユーザー、投稿に関連するコメント、「いいね」をつけたユーザの機能が含まれます。このプラットフォームは、ユーザーカウンターと投稿カウンターのエンティティを通じてメトリクスを追跡し、ユーザーあたりの投稿総数や投稿毎のエンゲージメント指標などの統計を維持しています。この図は、現在のリレーショナルモデルにおける主要な関係を示しています。 ユーザーと投稿 (1 対多の関係) 投稿からコメント (1 対多の関係) ユーザーとそれぞれのカウンターへの投稿 (1 対 1 の関係) ユーザーと「いいね」 (多対多の関係)による投稿では、ユーザーは複数のポストに「いいね」をしたり、複数のユーザーから投稿に対して「いいね」を受けられる スキーマ分析 既存のデータベース構造を徹底的に調査することから始めてください。この分析により、どのテーブルを移行するかを判断し、DynamoDB でのデータモデリングの複雑さを理解するのに役立ちます。 データベース構造の分析 まず、現在のデータベースアーキテクチャを調査してください。 テーブル (トランザクション、分析、監査ログなど) とそれらの関係を特定する データ型 (文字列、数値、日時、GUID、空間データなど) を分析し、DynamoDB の 同等のデータ型 を特定する DynamoDB の 1 アイテムあたり 400 KB のサイズ制限を考慮しながら、テーブルサイズと増加パターンをドキュメント化する アプリケーションがさまざまなデータ型をどのように使用しているかを理解することは、DynamoDB でのおけるそれらの表現方法を導くことになります。日時フィールドは、クエリとソートの要件に基づいて、ISO 文字列またはエポック数にマッピングする必要があります。複数のフィールドを単一のアイテムに非正規化できる場合は、TEXT フィールドのサイズを評価する必要があります。この分析により、データの整合性を維持しながら効率的なクエリをサポートするデータモデルの設計に役立ちます。 マイクロサービスに関する考慮事項 マイクロサービスアーキテクチャでモダナイズする場合は、各サービスのテーブル依存関係を特定してください。 サービスごとに必要なテーブルを一覧にする サービス間のデータ依存関係をドキュメント化する 非正規化の戦略を立てる データ整合性の要件を評価する サービス間でデータを共有およびアクセスする必要性を検討してください。たとえば、投稿サービスではユーザー名とプロフィール画像の表示が必要になる一方で、通知サービスではアラート配信のためにユーザー設定が必要になる場合があります。このようなサービス間のデータ依存関係は、DynamoDB のモデリング決定に影響します。アクセスパターンと更新頻度に基づいて、厳格なサービス分離とデータ非正規化のトレードオフを評価してください。サービス間の呼び出しによるパフォーマンスへの影響を考慮し、アプリケーションパターンの変化に伴ってサービス境界の調整が必要になる状況に備えてください。 部分的な移行分析 一部のテーブルのみを DynamoDB に移行する場合は、移行したテーブルと移行していないテーブルの関係を理解する必要があります。 移行範囲と依存関係を特定する パフォーマンスへの影響を評価する アプリケーションの変更を計画する データ整合性戦略を設計する 将来の移行フェーズを定義する 投稿やコメントなどの頻繁にアクセスされるデータは DynamoDB に移行し、履歴分析データはリレーショナルデータベースに残すシナリオを考えてみましょう。以前はテーブル間のトランザクション整合性に依存していた操作を処理するデザインパターンを計画します。クロスデータベースクエリによる潜在的なレイテンシーへの影響を検討し、適切なデータ同期メカニズムを実装する必要があります。この理解は、移行中と移行後のデータ整合性とアプリケーションのパフォーマンスを維持するための効果的な戦略を立てるのに役立ちます。 スキーマオブジェクトの評価 DynamoDB の設計で SQL スキーマオブジェクトの機能をどのように実装するかを評価してください: SQL ビューとそのアプリケーション使用方法をドキュメント化する 共通テーブル式 (CTE) を含む、ストアドプロシージャの複雑さを分析する トリガーベースのビジネスロジックの移行を計画する 移行対象外のテーブルへの参照を評価する 複雑な分析クエリの代替案を検討する 大規模なデータ変更を計画する テーブル全体でエンゲージメント指標を集計する SQL ビュー、時間ウィンドウ付きデータを使用してトレンドコンテンツを計算するストアドプロシージャ、投稿数などの派生データを管理するトリガーは、DynamoDB 向けに再設計する必要があります。SQL 操作に依存せずに効率的なアクセスパターンをサポートするようにデータモデルを設計してください。大規模なデータ変更にはバッチ処理アプローチを検討し、従来はデータベースプロシージャやトリガーで処理されていた操作をアプリケーションロジックでどのように処理するかを計画してください。入念なスキーマ分析と慎重な計画を行うことで、チームは実装要件を予測し、クエリパターンを最適化し、効果的なデータ整合性戦略を策定できます。この理解は、モダナイゼーションの取り組みに不可欠であり、チームがアプリケーションで DynamoDB の機能を最大限に活用できるようにするための鍵となります。 クエリ分析 アプリケーションで使用される SQL クエリ (インラインの SQL、ORM 生成のクエリ、その他の動的クエリを含む) を分析します。この分析により、DynamoDB データモデルの適切なパーティションキー、ソートキー、リレーションシップを選択するための情報が得られます。SQL クエリの各コンポーネントを次のように調査します。 SELECT 句の分析 SELECT 句を調べることで、アプリケーションがデータをどのように消費する方法と、さまざまなエンティティ間の関係について洞察を得ることができます。SELECT 句を分析する際には、次の重要な側面を考慮してください: サブクエリ – 既存のアクセスパターンの中で、通常は集約、複雑な条件に基づくフィルタリング、関連エンティティの詳細の取得、または最新のレコードの取得を行うサブクエリを探します。たとえば、ユーザープロファイルのクエリではサブクエリを使って総投稿数やフォロワー数を計算し、投稿のクエリでは最新のコメントを取得するかもしれません。これらのパターンを理解することで、DynamoDB で非正規化するデータと、事前計算した値として維持する属性を特定するのに役立ちます。 -- User profile with total posts count SELECT u.name, u.profile_pic, (SELECT COUNT(*) FROM posts WHERE user_id = u.user_id) as post_count FROM users u WHERE u.user_id = '123' 複数テーブルのカラム選択 – クエリが複数のテーブルのカラムを組み合わせる方法を分析し、頻繁に一緒にアクセスされるデータを示します。典型的な投稿表示クエリは、1 回のフェッチで、コンテンツ、著者の詳細、エンゲージメント統計を組み合わせます。この分析により、異なるエンティティからどの属性を 1 つのアイテムに非正規化して、DynamoDB での効率的な読み取り操作をサポートできるかを判断できます。 -- Post with author details SELECT p.content, p.created_at, u.name, u.profile_pic FROM posts p JOIN users u ON p.user_id = u.user_id WHERE p.post_id = '456' ユーザー定義関数 – クエリでデータを変換または計算するユーザー定義関数の使用状況を確認してください。複数のエンゲージメント要因を時間ベースの重み付けで組み合わせてトレンドスコアを計算する関数は、クエリでの計算が複雑になります。これらの計算を理解することで、事前に計算して格納すべき属性と、DynamoDB でこれらの計算値を効率的に更新できるようにデータモデルを構造化する方法を特定するのに役立ちます。 派生列 – 複数のフィールド値を組み合わせたり、ビジネスロジックを適用してクエリ内の計算または条件付きの列を調査してください。多くの場合、クエリでは全体的なエンゲージメント指標を導出し、インタラクションのしきい値に基づいてコンテンツのステータスを判断します。この分析により、アイテムに計算済みの属性を維持するかどうか、および DynamoDB でこれらの派生値を最新に保つための効率的な更新パターンを設計するうえでの判断材料となります。 -- Derived engagement score and post status SELECT post_id, content, (like_count + comment_count) as total_engagement, CASE WHEN like_count &gt; 1000 THEN 'TRENDING' WHEN like_count &gt; 100 THEN 'POPULAR' ELSE 'NORMAL' END as post_status FROM posts WHERE created_at &gt; DATEADD(year, -1, GETUTCDATE()) JOIN 句の分析 SQL クエリの JOIN 句を調べると、さまざまなエンティティ間の関係と、アプリケーションが複数のテーブルからどのようにデータを結合しているかがわかります。この分析により、DynamoDB での最適なデータモデル戦略を決定するのに役立ちます。JOIN 句を分析する際は、次の重要な側面を考慮してください。 エンティティの関係 – クエリでどのテーブルがよく結合されているかを分析します。投稿の表示クエリでは、投稿、コメント、いいね、ユーザーテーブルのデータを組み合わせることがあり、この操作ではこれらのエンティティが一緒にアクセスされることが多いことを示しています。これらの組み合わせを理解することで、効率的にアクセスするために DynamoDB で非正規化またはモデル化する必要があるデータの特定に役立ちます。 結合条件 – テーブル間の関係の条件と多重度を評価します。たとえば、投稿はコメントと一対多の関係になる可能性がありますが、ユーザープロファイルとは一対一の関係になります。結合条件には、単純なキーの一致以外にも、日付範囲やステータスフラグが含まれる場合があります。この多重度を理解することで、データをアイテム内に埋め込むか、別のアイテムを維持するかなど、適切なモデリング戦略を決定するのに役立ち、さまざまなモデリング手法のパフォーマンスとコストの影響を見積もるのに役立ちます。 -- Post with its comments SELECT p.*, u.*, c.comment_text, c.created_at FROM posts p JOIN comments c ON p.post_id = c.post_id AND c.created_at &gt; DATEADD(hour, -24, GETUTCDATE()) JOIN users u ON p.user_id = u.user_id WHERE p.post_id = '456' サービス間およびハイブリッドアーキテクチャの結合 – 異なるサービスに属するテーブル、または移行が計画されていないテーブルを含む結合を確認します。たとえば、投稿データが別のサービスによって管理されるユーザープロファイルデータと結合する場合や、リレーショナルデータベースに残る分析データと結合する場合などです。このようなパターンはデータモデリングの決定に影響します。この分析により、サービス境界を越えたデータアクセス戦略や、異なるデータベースに対する戦略の指針となります。 WHERE 句の分析 SQL クエリの WHERE 句を調べると、アプリケーションがデータをどのようにフィルタリングしてアクセスしているかを知ることができます。この分析は、DynamoDB で効率的なアクセスパターンを設計する上で役立ちます。WHERE 句を分析する際は、次の点に留意してください。 単一値フィルター – クエリで頻繁に使用される単一値フィルターを特定します。たとえば、特定のユーザー ID で投稿をフィルタリングしたり、ステータス別に投稿を取得したりするパターンです。これらのパターンは、DynamoDB のベーステーブルまたはグローバルセカンダリインデックス (GSI) の潜在的なパーティションキーを特定するのに役立ち、さまざまなアクセスパターンでデータを効率的に取得できるようになります。 -- Single value filter SELECT * FROM posts WHERE user_id = '123' AND status = 'ACTIVE' 範囲ベースのフィルター – エンティティ識別子と範囲条件を組み合わせたクエリを探します。ユーザー ID と日付範囲で投稿をフィルタリングするクエリは、DynamoDB で複合キーを構造化する方法を示しています。これらのパターンを理解することで、パーティション内の効率的な範囲クエリをサポートする適切なソートキーを決定するのに役立ちます。 -- Getting user's recent posts SELECT * FROM posts WHERE user_id = '123' AND created_at &gt; DATEADD(year, -1, GETUTCDATE()) ORDER BY created_at DESC 複数値フィルター – 属性に対して複数の値が存在する条件を調査します。たとえば、あるユーザー ID グループによる投稿の検索や、特定のハッシュタグを含む投稿の検索などです。これらのパターンは、DynamoDB のデータモデリングの決定に影響を与えます。たとえば、複数のユーザーによる投稿を取得する場合は、ユーザー ID をパーティションキーとする GSI を使って個別のクエリを実行する必要がありますが、ハッシュタグによる投稿の検索では、ハッシュタグをパーティションキーとし、関連する投稿 ID を集合として格納する、逆インデックス構造が有益かもしれません。 -- Finding posts with specific hashtags SELECT DISTINCT p.* FROM posts p JOIN post_hashtags ph ON p.post_id = ph.post_id WHERE ph.hashtag IN ('#POPULAR', '#TRENDING') クロスエンティティフィルター – SQL クエリ内で複数のエンティティにまたがるフィルターを特定します。たとえば、投稿属性とユーザー属性 (ユーザーの場所やユーザータイプなど) の両方に基づいて投稿を検索するクエリは、DynamoDB モデルの非正規化の決定に影響を与える関係を示しています。これらのフィルターに、異なるマイクロサービスによって管理されるエンティティ、または DynamoDB に移行されないエンティティを含む場合は、クライアントサイドのフィルタリングとサービス境界を越えたデータ取得のパフォーマンス影響を分析します。 -- Finding active user posts with high engagement SELECT p.post_id, p.content, FROM posts p JOIN users u ON p.user_id = u.user_id WHERE u.status = 'ACTIVE' AND p.like_count &gt; 100 ORDER BY p.created_at DESC ORDER BY 句と TOP/LIMIT 句の分析 ORDER BY 句と TOP/LIMIT 句を調べると、アプリケーションでのデータのソートとページネーションの要件が明らかになります。この分析は、DynamoDB での効果的なソートキーの設計を決定するのに役立ちます。以下の点を考慮してください: ソート要件 – データの並べ替えに使用される属性と属性の組み合わせを特定します。たとえば、最新の投稿を表示するために作成日でソートする、または人気のコンテンツを表示するためにエンゲージメント指標でソートするなどです。一部のクエリでは、日付でソートした後、各日付内でいいね数でソートするなど、複合ソートが必要になる場合があります。これらのパターンを把握することで、必要なソート機能をサポートする適切な DynamoDB のソートキー構造を決定するのに役立ちます。 ページネーション要件 – TOP/LIMIT 句とソートを使用するクエリを分析します。最新の投稿を制限付きで取得するクエリや、エンゲージメント指標に基づいて人気の投稿を取得するクエリは、ページネーションが必要であることを示しています。これらのパターンを理解することで、DynamoDB の limit 機能と LastEvaluatedKey 機能を使って効率的なページネーション戦略の設計に役立ちます。 GROUP BY 句の分析 GROUP BY 操作を調査することで、アプリケーションで集約が必要な部分を明らかにできます。この分析により、DynamoDB データモデルで維持する必要がある指標やカウンターを特定できます。以下の点を考慮してください: 集約パターン – クエリ内のグループ化と集約操作を特定します。たとえば、ユーザーごとの投稿数のカウント、投稿ごとの合計いいね数の計算、投稿タイプごとのエンゲージメント指標の要約などです。これらのパターンを理解することで、アイテムに事前計算された値として維持する必要がある属性なのか判断するのに役立ちます。 -- Posts count by user SELECT user_id, COUNT(*) as total_posts FROM posts GROUP BY user_id 更新頻度 – これらの集計値がどのくらいの頻度で変化するかを分析します。投稿へのいいね数は、ユーザーの操作に応じて頻繁に更新されますが、ユーザーの投稿総数は投稿を作成または削除したときにのみ変化します。このようなパターンを把握することで、書き込みパターンと、事前計算された値を維持する上での影響を評価するのに役立ちます。 アプリケーション使用状況の分析 アプリケーションの使用統計情報 (時間ごとの HTTP リクエスト頻度など) を収集します。ビジネス上の重要度と使用状況のメトリクスを、以下の目的で分析します。 特別な注意を要するエッジケースに優先順位をつける。例: 有名人が最新情報を投稿した場合、システムはその投稿を数百万人のフォロワーのフィードに即座に配信する必要がある。 口コミで広まった投稿には、数分以内に突然多くの「いいね」やコメントが付く可能性がある。 移行すべき主要なモジュールを特定する。 このデータ駆動型のアプローチでは、アプリケーションの最も重要で頻繁に使用される部分が移行プロセス中に優先されるため、リソースの割り当てが最適化され、コア業務機能への潜在的な中断が最小限に抑えられます。次の目標で、テーブルの平均行サイズ、読み取り/書き込み比率、予測成長率を分析します。 エンティティ関係を構築する最適なアプローチを決定する。たとえば、単一アイテム戦略と垂直パーティショニングのどちらを選択するか 読み取りと書き込みのキャパシティを正確に見積もり、割り当てる 結論 現在のデータベース構造、アクセスパターン、使用状況メトリクスを分析することで、DynamoDB への移行の基盤を構築できます。この理解は次のフェーズである DynamoDB のデータモデルの設計を形作るのに役立ちます。これについては、このシリーズの パート 2 で説明します。この構造化されたアプローチに従うことで、移行戦略が現在のニーズと将来のスケーラビリティ要件の両方に合致していることを確認できます。 著者について Ramana Kiran Mannava Ramana は、AWS プロフェッショナルサービスのリードコンサルタントであり、.NET ワークロードの最新化と AWS 上のクラウドベースソリューションの構築に関する専門知識を持っています。彼はデータベース技術とクエリ最適化にも情熱を持っています。 Akber Rizwan Shaik Akber は、 AWS プロフェッショナルサービスのリードコンサルタントです。彼はクラウドベースのソリューションを使用して、お客様の .NET ワークロードを AWS に移行し、最新化するのを支援しています。 Mahesh Kumar Vemula Mahesh は、AWS プロフェッショナルサービスのリードコンサルタントです。彼はサーバーレス愛好家であり、クラウドベースのソリューションを用いて顧客の .NET ワークロードの最新化を支援しています。

この記事は How to create a unified view of your consumer (記事公開日: 2025 年 6 月 13 日) を翻訳したものです。 はじめに 今日の競争の激しいビジネス環境において、顧客の 360 度ビューを構築することは、顧客体験の向上、運用戦略の最適化、そしてマーケティング効率の改善につながります。顧客の行動は、従来の実店舗での対面取引から、データに基づくオンラインでの個別対応へと変化しています。企業は、情報の中から必要なものを整理することで、顧客についてより多くのことを学ぶことができます。顧客の統一ビューとは、企業が顧客と持つすべての接点やデータソースから得られる、様々な異なる情報を統合し連携させる能力を指します。これには、取引履歴、ロイヤルティプログラムの会員情報、ウェブサイトやモバイルアプリの訪問記録、カスタマーサービスとのやり取りなどが含まれます。これらすべてのデータソースには顧客の行動に関する貴重な洞察が含まれていますが、それぞれ異なる顧客データの要素と紐づいており、連関のないシステムに分散して保存されています。顧客は、ウェブサイト、モバイルアプリ、実店舗、様々なマーケティングキャンペーンを通じてブランドと接触し、それぞれの接点で独自の記録が生成されます。 Amazon Connect Customer Profiles と AWS Entity Resolution を使用してこれらの断片化されたデータポイントを単一の一貫したプロファイルに統合することで、企業は顧客をより深く理解し、真にパーソナライズされた体験を提供できるようになります。 ある銀行の顧客であるシャーリーさんの例を考えてみましょう。長年にわたって、シャーリーさんは当座預金口座を開設し、クレジットカードを申し込み、住宅ローンを申請し、銀行のリワードプログラムに登録し、カスタマーサポートチームに何度も連絡を取っています。しかしながら、このデータは断片化されています。 後に買収された地方銀行で口座を開設していた 住宅ローンは現在住んでいない住所と関連付けられている 個人口座と法人口座を異なる請求情報で開設している これらの要因により、銀行はシャーリーさんとの関係について部分的な把握しかできていない可能性があります。その結果、以下のような機会を逃すかもしれません。 過去の履歴に基づくオーダーメイドのオファー提供 過去の行動パターンに基づくニーズの予測 カスタマーサービス連絡時の効率的な問題解決 しかし、AWS Entity Resolution を活用することで、銀行はシャーリーさんのすべての記録とやり取りを連携させ、顧客としての包括的な理解を得ることができます。そして、Amazon Connect Customer Profiles を使用してシャーリーさんの統一された信頼できる記録を作成し、銀行とのやり取りがあるたびにリアルタイムで更新されるシステムを構築できます。 主な課題 シャーリーさんのような顧客に、より良い体験を提供するために、企業は以下のような課題に対処する必要があります： データの断片化 ：顧客データは、異なるスキーマ、形式、場所、アクセス方法を持つ相互に関連のないアプリケーションに分散しており、一元化が困難になっています。 一貫性のない顧客プロファイル ：企業は結果的に、一貫性がなく、不完全で、時には矛盾する顧客情報を抱えることになります。これにより、各個人について明確で正確な理解を築くことが困難になります。 パーソナライゼーションの困難さ ：統一された顧客ビューがなければ、真にパーソナライズされた体験を提供することはほぼ不可能になります。企業は再訪問した顧客を認識できず、関連性の高い推奨事項を提供できず、複数の接点にわたってシームレスな体験を提供できなくなる可能性があります。 マーケティングと営業の最適化不足 ：断片化されたデータは、企業が意味のある洞察を得て、購買ジャーニーをマッピングし、ターゲットを絞った効果的なマーケティングキャンペーンを実行する能力を阻害します。これにより、マーケティング予算の無駄遣いや営業機会の損失につながる可能性があります。 コンプライアンスとプライバシーのリスク ：GDPR (一般データ保護規則) や CCPA (カリフォルニア州消費者プライバシー法) などの現代のデータプライバシー規制では、企業が各顧客について収集・保存する個人データを包括的に理解し、アクセス要求、監査、オプトアウト、削除に使用することが求められています。断片化されたデータでは、このような規制への準拠が困難になります。 これらの課題に対処し、顧客データを統一ビューに統合することで、企業は顧客体験の向上、成長の促進、競争優位性の維持のための豊富な機会を得ることができます。 このブログでは、Amazon Connect Customer Profiles と AWS Entity Resolution を使用して顧客の統一ビューを作成する方法について説明します。 ソリューション Amazon Connect Customer Profiles は、連絡先情報や取引履歴からサポートでのやり取りや設定まで、すべての関連する顧客情報を統合・保存し、単一の統一された顧客プロファイルにまとめて実用的な洞察を作成します。これらのプロファイルには、最も重要な連絡先情報、最新のやり取り、その顧客に関するその他の計算された洞察が含まれています。Amazon Connect Customer Profiles は、主要な顧客データシステムとノーコードで統合でき、データを自動的に取り込んで、整理・保存します。保存したデータは、Amazon Connect 内ですぐに検索やアクセスのために利用できます。AWS Entity Resolution とシームレスに統合することで、Amazon Connect Customer Profiles は各プロファイルが重複排除された顧客エンティティにリンクされることを保証し、一貫性のない断片化されたデータのリスクを排除します。 AWS Entity Resolution は、企業が複数のアプリケーション、チャネル、データストアに保存されている関連する顧客、製品、ビジネス、またはヘルスケア記録をマッチング、リンク、拡張するのに役立ちます。このサービスは、ルールベースと機械学習ベースのマッチング技術を活用することで、断片化された消費者データの課題に対処します。AWS Entity Resolution は、異なるソースから消費者記録を取り込み、重複を排除し、一意の消費者エンティティを特定します。同じ消費者に属するすべての記録に一意の matchID を割り当てることで、このサービスは分析とセグメンテーションのために統合できるすべてのデータソースの鍵となる、人を表す共通キーを作成します。AWS Entity Resolution は、アイデンティティ解決パイプラインの構築に必要な重い作業 (データ正規化、大規模データセットでのペア生成、比較分散、ID 一貫性、クラスタリング、分割) を取り除くため、複雑なデータエンジニアリングソリューションを構築する代わりに、設定しやすいマッチング技術を使用できます。ルールベースマッチングの開始方法がわからない場合、ML ベースマッチングは個人識別情報 (PII) ベースのデータに対して業界最高水準の精度を提供し、設定が不要です。 企業は、AWS Entity Resolution で処理されたデータ基盤を基に、Amazon Connect Customer Profiles を使用することで、各顧客の包括的で実用的な 360 度ビューを構築することもできます。 この統合ソリューションの主要なメリット : 統一された顧客インテリジェンス ：企業は、すべての接点とやり取りを通じて、各顧客の属性、行動、興味、課題点を含む包括的な理解を得ることができます。 パーソナライズされた体験 ：顧客の完全なビューがあることで、組織は高度にパーソナライズされた製品、サービス、コミュニケーションを提供し、顧客ロイヤルティと満足度を向上させることができます。 よりパーソナライズされたマーケティング ：断片的または重複した記録をマーケティングや広告キャンペーンに使用すると、マーケティング予算の無駄遣い、キャンペーン結果の悪化、冗長なメッセージングによる顧客への迷惑につながる可能性があります。 パーソナライズされたカスタマーサポート ：カスタマーサービス担当者は、顧客の履歴や過去のやり取りの全体像に素早くアクセスでき、より迅速で効果的なサポートを提供できます。 クロスセルとアップセルの改善 ：顧客の全体的なジャーニーと製品・サービス利用状況を理解することで、企業は関連性の高いクロスセルとアップセルの機会を特定し、収益成長を促進できます。 コンプライアンスとプライバシー規制への対応 ：GDPR や CCPA などの現代のデータプライバシーポリシーでは、企業が各顧客について収集・保存することが許可されている個人データを包括的に理解する必要があります。また、オプトアウトや記録削除の要求をすべての規制基準に従って適切に実行する必要があります。 連絡設定の尊重 ：顧客が電話やメールでの連絡を希望しない場合、複数の電話番号やメールアドレスを持っていても、その意志を尊重することで企業はより良い体験を提供できます。 Amazon Connect Customer Profiles と AWS Entity Resolution の力を組み合わせることで、企業は消費者の包括的な 360 度ビューを実現し、顧客理解とビジネスインパクトの新たなレベルを実現できます。 仕組み 以下のリファレンスアーキテクチャは、Amazon Connect Customer Profiles と AWS Entity Resolution が顧客データを統合して、顧客離脱の削減、パーソナライゼーションの向上、カスタマーサービスの改善などに使用できる 360 度ビューを作成する方法を概説しています。 Amazon Connect Customer Profiles and AWS Entity Resolution reference architecture 消費者の記録とやり取りを含むデータソースは、重複排除、マッチング、リンクのために AWS Entity Resolution に送信されます。これらのソースには通常、消費者の個人識別情報 (PII) が含まれており、ロイヤルティ登録システムや CRM システムが良い例です。AWS Entity Resolution のマッチングロジックと設定により、顧客は複数の接点や複雑なロジック、あいまいなアルゴリズムを活用するルールを構築できます。また、機械学習ベースのマッチングモデルを使用することで、複雑なルールを使用せずに PII を用いて正確なデータマッチングを行うことも可能です。 その後、Amazon Connect Customer Profiles は、マーケティングオートメーション、コールセンターのやり取りの記録、ユーザー設定などの他のデータソースを取り込んで、顧客に関する実用的な洞察を作成できます。これらのソースは同じロジックを必要とせず、通常はアカウント ID などの特定のキーや識別子を使用して、既知のユーザー / エンティティに紐づけられます。 このようにデータソースを分離することで、アーキテクチャは各 AWS サービスの使用を最適化できます： AWS Entity Resolution は、主要な記録システムから顧客識別子へ顧客 ID を解決・リンクするという中核タスクに集中します。 Amazon Connect Customer Profiles は、解決された顧客データを追加のエンゲージメントデータと集約して、各顧客識別子の総合的な 360 度ビューを提供します。 このアプローチにより、効率的なデータ処理が保証され、パーソナライズされた体験、ターゲットを絞ったマーケティング、強化された顧客インサイトをサポートする包括的で統合された顧客ビューの作成が可能になります。 顧客への理解を深めるにつれて顧客データは時間の経過とともに変化するため、企業はプロファイルの変化に応じて成長・進化できる柔軟なアーキテクチャを計画する必要があります。多くの消費者は、匿名の訪問者と既知の訪問者の両方として、様々なチャネルを通じて企業とやり取りします。チャネル間でのこのようなデータの断片化は、同一人物に対して複数のプロファイルが作成される原因となることが多く、その瞬間に個人を特定することが困難になります。この問題に対処するための一般的なアプローチは、AWS Entity Resolution のルールベースと機械学習ベースのマッチングを活用することです。不完全な情報により、最初のルールベースマッチングでは別々のプロファイルが作成される可能性がありますが、AWS Entity Resolution の機械学習を活用したマッチング機能を時間をかけて適用することで、これらの異なるプロファイル間でより堅牢なリンクを提供できます。このような方法で顧客データを統合することで、組織はより総合的で統一された消費者ビューを獲得し、やり取り全体でよりパーソナライズされたシームレスな体験を提供する力を得ることができます。 プロファイルが作成され、顧客データフィードが Amazon Connect Customer Profiles に送られてプロファイルを充実させるようになると、企業は Amazon Connect Customer Profiles を顧客データファブリックとして使用し、複数のチャネルを通じてセグメンテーション、分析、パーソナライゼーションを行うことができます。 Amazon Connect Outbound Campaigns を使用して、企業はアウトバウンドメール、SMS、プッシュ通知イベント用のオーディエンスセグメントを作成したり、顧客プロファイルの属性をカスタマーサービスアクション、アウトリーチ、体験のトリガーとして使用できます。さらに、ユーザーは統合された顧客ビューを、Adobe や Salesforce を含む任意の顧客データプラットフォームにおいて、統合された豊富で最新の顧客ファブリックとして使用できます。 顧客成功事例 United Airlines (ユナイテッド航空) などの顧客は、AWS Entity Resolution と Amazon Connect Customer Profiles を使用して統一された顧客ビューを構築することで、最終顧客満足度とマーケティング予算の ROI を大幅に改善しました。 ユナイテッド航空は、AWS Entity Resolution を使用して、ルールベースマッチングによる確定的 ID と、ML ベースマッチングモデルによる確率的 ID の両方を作成しました。ML ベースとルールベースの両方のマッチングを適用することで、ユナイテッド航空は 90％ を超えるマッチング精度を達成しました。 「AWS Entity Resolution を使用することで、すべての予約に対して、リアルタイムでその顧客に正しい確率的 ID を関連付けることができます」と、ユナイテッドのカスタマートラベルエクスペリエンス担当マネージング・ディレクターの Mahesh Veda 氏は述べています。「これにより、顧客の全体的なジャーニーの統一ビューが作成されます。」 ユナイテッド航空は、旅行者とゲストのデータを連携させて洞察を得て、パーソナライゼーションを推進しています。このソリューションを使用することで、予約データベースや CRM ソフトウェアなど、14 の基幹システムとレガシーシステムからデータを取り込んでいます。新しいソリューションにより、ユナイテッド航空は重複する顧客記録を 35％ 削減し、インフラストラクチャの統合により運営コストを 30％ 削減しました。そして最も重要なことは、顧客が旅行体験の違いを実感したことです。 「ネットプロモータースコアが 15％ 向上しました」と Veda 氏は述べています。「お客様は『この方法で予約して戻ってきても、あなたたちは私のことを覚えてくれている』と言って喜んでいます。」 まとめ 企業は多くのチャネルから顧客の断片化されたデータを収集していますが、そのデータを正確に統合することに苦労しています。Amazon Connect Customer Profiles と AWS Entity Resolution は、多くのソースからのデータを統合し、重複するプロファイルをマージして、よりパーソナライズされた体験を提供するために使用できる統一されたビューを作成します。AWS の担当者にお問い合わせいただくか、 Amazon Connect Customer Profiles と AWS Entity Resolution を使用して顧客の統一ビューを構築し、より良い洞察と顧客へのパーソナライズされた体験を実現する方法について、オンラインで詳細をご確認ください。 Punit Shah Punit は、Amazon Web Services のシニアソリューションアーキテクトとして、顧客がクラウド上でデータと分析戦略を構築するのを支援することに注力しています。現在の役割では、AWS Entity Resolution や Amazon Connect などの AWS サービスを使用して、強固なデータ基盤層の構築を顧客に支援しています。大規模なデータレイクの構築において 15 年以上の業界経験を持っています。 Travis Barnes Travis は AWS Entity Resolution のシニアプロダクトマネージャー (テクニカル) として、高度なアイデンティティ解決技術を通じて顧客がデータの価値を最大化できるよう支援しています。アイデンティティと Adtech 分野での革新的な製品開発において 10 年以上の経験を持ち、実際のビジネス成果を生み出す複雑なデータの課題解決に情熱を注いでいます。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

こんにちは、Amazon Connect ソリューションアーキテクトの坂田です。 2025年5月のアップデートまとめ はご覧いただけましたでしょうか。また、6月25日、26日には AWS Summit Japan 2025 が開催されましたが、お楽しみいただけましたでしょうか？大雨が降ったりとっても暑かったりでしたが、二日間ともたくさんのお客様にご来場いただくことができ、大変嬉しく思っております。7月11日まで オンデマンド配信中 ですので、見逃した方はぜひご視聴くださいませ。 さて、今月は以下の情報をお届けします。皆様のお役に立つ内容があれば幸いです！ 注目のアップデートについて 2025年6月のアップデート一覧 AWS Contact Center Blog のご紹介 1. 注目のアップデートについて Amazon Connect アウトバウンドキャンペーンが3つの新しい AWS リージョン(東京リージョン含む)で利用可能に Amazon Connect アウトバウンドキャンペーンがアジアパシフィック（ソウル）、アジアパシフィック（東京）、アジアパシフィック（シンガポール）で利用可能になりました。これにより、お客様は適切なチャネルを通じて、カスタマーエクスペリエンス全体を通じて最適なタイミングでリアルタイムのサービスアップデート、プロモーションオファー、製品使用のヒント、予約リマインダーなどの積極的なアウトバウンドコミュニケーションを開始できるようになります。 Amazon Connect のアウトバウンドキャンペーンは、セグメンテーション、オムニチャネルオーケストレーション、コンテンツのパーソナライゼーション、組み込み分析などの主要な機能を通じて、ターゲットを絞った効果的なアウトリーチ戦略を作成する機能を企業に提供します。アウトバウンドキャンペーンは、予測型および段階的な音声ダイヤリング、AI 駆動の通話分類、コンタクト結果に基づくリトライ戦略、タイムゾーン検出、通信制限をサポートしています。これらの機能により、企業は規制要件と顧客の好みに準拠しながらアウトリーチを最適化できます。さらに、企業はオーディエンスセグメントを微調整し、メッセージテンプレートをパーソナライズし、音声や SMS、メールなどのデジタルチャネルでイベントベースのキャンペーンを開始できます。これらの機能を活用することで、企業は顧客エンゲージメント戦略を大幅に強化し、全体的なコミュニケーションの効果を向上させることができます。 Amazon Connect のアウトバウンドキャンペーンでは、音声（エージェントまたは自動音声）、Eメール、SMS をサポートしています。 音声（エージェント）を選択した場合、プレディクティブとプログレッシブの二つのダイヤルモードを選択することが可能です。 「通話の進捗を確認」ブロックを使用することで、顧客への接続状況に応じてフローを分岐させることも可能です。これによって、エージェントの生産性をさらに向上させることが可能です。例えば、「呼び出しが応答された」場合はエージェントにルーティング、「ボイスメール」の場合は「プロンプトの再生」を使ってメッセージを残す。などの分岐が可能になります。 Amazon Connect アウトバウンドキャンペーンを始めるには、 管理者ガイド にそって設定を開始してください。また、 AWS Workshop Studio で詳しく学習することも可能です。 関連リンク 管理者ガイド 製品ページ 料金ページ AWS Workshop Studio 2. 2025年6月のアップデート一覧 エージェントのパフォーマンスを評価する際に、サードパーティアプリケーションのエージェント活動を含めることができるように – 2025/06/30 Amazon Connect で、サードパーティアプリケーションのエージェントアクティビティを Amazon Connect のタスクとして統合できるようになりました。 サードパーティアプリケーション（アプリケーション処理、ソーシャルメディア投稿など）からのアクティビティを Amazon Connect の完了済みタスクとしてプログラムで取り込み、パフォーマンス評価に関連する詳細をタスク属性として記録できます。マネージャーはこれらの外部アクティビティをネイティブのAmazon Connect 上の操作と共に評価し、Amazon Connect のダッシュボード内でエージェントのパフォーマンスを統合的に確認することができます。 この機能は、Contact Lens のパフォーマンス評価がすでに利用可能なすべてのリージョンで利用できます。 関連リンク 管理者ガイド 東京リージョンと大阪リージョン間の Amazon Connect インスタンスのレプリケーションをサポート – 2025/06/30 Amazon Connect で、アジアパシフィック（大阪）に、アジアパシフィック（東京）環境のチャネル構成とサービスクォータを反映する同期されたインスタンスを維持できるようになりました。アジアパシフィック（大阪）にレジリエンシーインスタンスを設置することで、ユーザー、ルーティングプロファイル、フローなどの Amazon Connect 設定をレプリケートし、トラフィック分散設定を構成して、アジアパシフィック（東京）とアジアパシフィック（大阪）間でユーザーグループと電話番号を事前に定義し、リージョンの切り替え後に新規の着信トラフィックをレジリエンシーインスタンスで処理できるようになります。 この機能を利用するためには、事前のお申し込みが必要です。AWS のアカウントチーム、テクニカルアカウントマネージャー、または Amazon Connect ソリューションアーキテクトまでお問い合わせください。 関連リンク AWS Blog – Amazon Connect Global Resiliency で実現するマルチリージョン高可用性 Amazon Connect アウトバウンドキャンペーンが 3 つの新しい AWS リージョンで利用可能に – 2025/06/26 「 注目のアップデート 」をご参照ください。 Amazon Connect がアウトバウンドキャンペーンの通信制限を強化 – 2025/06/13 Amazon Connect アウトバウンドキャンペーンは、複数のキャンペーンにわたって顧客とのエンゲージメント頻度を設定する際により大きな柔軟性を提供する、新しいインスタンスレベルの通信総数制限管理を提供するようになりました。また、重要なキャンペーンについては制限管理をオプトアウトする機能も提供します。これらの新機能により、より効率的でターゲットを絞った顧客エンゲージメント戦略が可能になります。 新しいインスタンスレベルの総数制限設定により、企業は米国電話消費者保護法（TCPA）などの規制に準拠しながら、すべてのキャンペーンにわたるアウトバウンド通信制限を管理できます。この機能は通信頻度を一元的に管理する方法を提供し、顧客への過度な連絡を避け、顧客満足度を潜在的に向上させることができます。特定のキャンペーンについてこれらの制限をオプトアウトする機能により、不正警告や悪天候時のサポートなどの重要な通信が最も必要な時に顧客に届くようになり、アウトバウンド通信の全体的な効果を高めます。 関連リンク 管理者ガイド Amazon Lex、LLM 支援の NLU を使用して会話の精度を向上 – 2025/06/12 Amazon Lex では、 英語とスペイン語のロケール のインテント分類とスロット解決機能を向上させるために、大規模言語モデル (LLM) を利用した自然言語理解 (NLU) が提供されるようになりました。この機能により、大規模言語モデル (LLM) を活用して標準 NLU で問題が発生したときの精度を向上させることができます。これにより、ボットの応答、定義されたインテント、スロットを完全に制御しながら、より自然で耐障害性の高い会話体験を提供できます。例えば、複雑な発話や長い発話の解釈、スペルミスがあっても正確さを維持すること、冗長な入力からスロットを抽出すること、最小限のトレーニングデータでより良い結果が得られること、アクセス許可や統合設定を変更する必要がないなどです。 関連リンク Amazon Lex デベロッパーガイド Amazon Connect Customer Profiles が旅行・ホスピタリティ業界向けに対応 – 2025/6/10 旅行・ホスピタリティ業界のお客様が、業界固有のソースシステムから Amazon Connect カスタマープロファイルへのデータの取り込みとマッピングをよりシームレスに行い、エンドカスタマーの統合的で包括的なビューを作成できるようになりました。 関連リンク AWS Contact Center Blog – Your unified view of travelers and guests from Amazon Connect Customer Profiles Amazon Connect に統合的な顧客ビューのためのプロファイルエクスプローラーを追加 – 2025/06/09 Amazon Connect Customer Profiles の統合的でカスタマイズされたビューにアクセスできる新機能、プロファイルエクスプローラーを提供開始しました。この直感的なインターフェースにより、組織はすべての接点で顧客をより良く理解し、エンゲージメントを図ることができ、顧客情報、対話履歴、AI によるインサイトへのリアルタイムユーザーアクセスを提供することで、既存の Amazon Connect Customer Profiles サービスを強化します。 プロファイルエクスプローラーを使用することで、ユーザーはメール、電話番号、予約参照番号など、複数の識別子を同時に使用してエンドカスタマーをリアルタイムで検索し、見つけることができます。カスタマーサービスチームは、人口統計データ、コミュニケーション履歴、行動パターン、セグメントメンバーシップなど、特定のニーズに最も関連性の高い情報を強調表示するようにビューをカスタマイズできます。プロファイルエクスプローラーはまた、主要なパターンを強調し、パーソナライズされた行動インサイトを提供する AI が生成する顧客サマリーを提供し、組織が顧客体験を改善しロイヤルティを促進するためのデータ駆動型の意思決定を支援します。 関連リンク 製品ページ 管理者ガイド Amazon Connect Customer Profiles の計算属性を強化 – 2025/06/09 Amazon Connect Customer Profiles は、タイムスタンプコントロール、過去データのバックフィル、および改善された制限を備えた強化された計算属性を提供し、企業が顧客データを実用的なインサイトに変換できるようになりました。顧客は今後、将来の日付のイベントを含むデータにタイムスタンプを指定し、制限が拡大された状態で過去のデータ情報を処理できるようになりました。Amazon Connect Customer Profiles は、エンジニアリングリソースを必要とせずに、顧客の行動データ（連絡、注文、ウェブ訪問など）を、プロアクティブなアウトバウンドキャンペーン、動的ルーティング、IVR のパーソナライズを推進するための顧客の優先チャネルなどの実用的なインサイトに変換する計算属性を提供します。新機能により、顧客は計算に使用されるタイムスタンプを制御し、取り込み順序に関係なく適切な時系列順序を確保することで、より正確で関連性の高い計算属性を作成できるようになりました。新しい過去データ計算機能により、新しい属性を作成する際に以前に取り込まれたデータが自動的に含まれ、顧客エンゲージメントに関する有意義なインサイトを得るための待ち時間が不要になります。これらの機能強化により、今後の予約の追跡、長期的な顧客行動パターンの分析、顧客生涯価値の評価、顧客とのやり取りの前にエージェントが関連するコンテキストを準備できることを確保するなど、高度なユースケースが可能になります。 関連リンク 管理者ガイド API リファレンス Amazon Connect のマルチパーティコールの保留時間追跡を強化 – 2025/06/06 Amazon Connect は、コンタクトレコードの新しいエージェント開始保留時間フィールドを通じて、マルチパーティ通話シナリオにおける個々のエージェントが開始した保留の時間を追跡できるようになりました。この新しいフィールドにより、コンタクトセンターのマネージャーは、顧客とのやり取り中の個々のエージェントレベルでの保留パターンについてのインサイトを得ることができます。 関連リンク 管理者ガイド Amazon Connect の外部音声転送が 5つの追加 AWS リージョンで利用可能に – 2026/06/05 Amazon Connect の外部音声転送が、アジアパシフィック（シドニー）、アジアパシフィック（東京）、カナダ（中部）、ヨーロッパ（フランクフルト）、ヨーロッパ（ロンドン）の AWS リージョンで利用可能になりました。外部音声転送により、Amazon Connect から公衆電話網を使用せずに、音声通話とメタデータを他の音声システムに直接転送できます。これにより、既存の音声システムの手前で Amazon Connect の電話機能とインタラクティブ音声応答（IVR）を使用することができ、顧客体験の向上とコスト削減に役立ちます。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 組織全体で Amazon Connect のフロー操作を監査する方法 (日本語翻訳記事) コンタクトセンター運営における包括的な監査証跡の取得と一元的な可視性の維持は、セキュリティ、コンプライアンス、および運用のベストプラクティスの観点で重要です。以前のブログ記事「 AWS CloudTrail と Amazon Athena による組織内の Amazon Connect API アクティビティの調査 」では、お客様が AWS CloudTrail と Amazon Athena を活用して、Amazon Connect のコンタクトセンター環境の中で行われる様々な API 呼び出しの可視性と監査可能性を実現する方法について説明しました。これは、組織がコンタクトセンター運営の監視および調査をできるようにするための重要な第一歩でした。 Amazon Connect は、さらに一歩進んだ AWS CloudTrail サポートとして、 Amazon Connect コンソールのフロー管理ページのアクティビティに対応 しました。これは、ユーザーがフローを追加、更新、または削除するたびに、そのアクティビティの記録が CloudTrail ログに取得されることを意味します。この新機能により、コンタクトセンターチームはさらなる可視性、レポーティング、およびコンプライアンスの利点を得ることができます。この、続編となるブログ記事では、お客様が AWS 環境全体で Amazon Connect のフロー管理のアクティビティを一元的に分析および監査する方法について、より詳しく説明します。 The future of customer service is here: From contact centers to experience hubs (英語記事) Amazon Connect は、従来のコンタクトセンターを AI を活用した体験ハブへと変革し、カスタマーサービスでのやり取りを革新しています。このプラットフォームは 1日 1,000万件以上のコンタクトセンターでのやり取りをサポートし、単なる問題解決ではなく、意味のある関係構築に重点を置いています。この変革は、受動的な問題解決から積極的な顧客エンゲージメントへの転換を表しており、人間の共感と AI の知能を組み合わせて、大規模なパーソナライズされた体験を提供します。このブログではこうした変革を実現するための要点と実例をご紹介します。 Your unified view of travelers and guests from Amazon Connect Customer Profiles (英語記事) Amazon Connect Customer Profiles は、旅行・ホスピタリティ企業向けに、よりパーソナライズされた顧客体験を提供するための新しい業界特化型機能を発表しました。この解決策は、75 以上のソースからのデータを自動化されたプロセスで統合し、旅行者やゲストの統合的なビューを提供することで、断片化した顧客データの課題に対応します。このサービスには、旅行・ホスピタリティのユースケース向けに事前設定されたデータモデルが含まれており、実用的な洞察を生み出し、顧客行動を予測するための生成 AI 機能で強化されています。このブログでは、旅行会社やホスピタリティ企業が Amazon Connect Customer Profiles を使用して、旅行者とゲストの統一されたプロファイルを作成し、マーケティングキャンペーン、パートナーシップ、測定のためのデータコラボレーションを改善し、生成 AI を使用してよりパーソナライズされたエンゲージメントとサービスを提供する方法について説明します。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 坂田 陽一郎

本ブログは 2025 年 6 月 17 日に公開された Blog “ Improve your security posture using Amazon threat intelligence on AWS Network Firewall ” を翻訳したものです。 お客様は AWS Network Firewall を使用して、一般的なセキュリティ脅威からワークロードを保護できます。しかし、 アクティブな脅威 (active threat) から保護する場合に、AWS ワークロードへの脅威検出が限られたサードパーティの脅威フィードやスキャナーに依存せざるを得ないことがよくあります。従来のご自身で脅威インテリジェンスフィードを取得してカスタムルールでセキュリティを管理するアプローチでは、対応が遅れ、AWS ワークロードに関連するアクティブな脅威にさらされる可能性があります。お客様は、自動的に脅威が分析され複数のセキュリティ制御ポイントで対策が展開されるマネージド型アプローチを求めており、一貫した防御を確立し、クラウドインフラストラクチャ全体でアクティブな脅威から迅速に保護できる統合された AWS ネイティブソリューションを望んでいます。 このブログでは、Network Firewall の新しい機能のアクティブ脅威防御 (active threat defense) を紹介します。アクティブ脅威防御は、AWS のワークロードに関連するアクティブな脅威から保護でき、マネージドルールグループで提供されます。AWS のグローバルインフラストラクチャで観測された広範な脅威インテリジェンスを活用して、自動化されたインテリジェンス駆動型のセキュリティ対策を提供します。この機能は、Amazon の脅威インテリジェンスシステム MadPot を使用しており、マルウェアをホストする URL、ボットネットのコマンド＆コントロールサーバー、暗号通貨マイニングプールなどの攻撃インフラストラクチャを継続的に追跡し、アクティブな脅威の侵害指標 (IOC) を特定します。 アクティブ脅威防御は、Active Threat Defense ルールグループ AttackInfrastructure として提供され、検出された攻撃インフラストラクチャとの通信をブロックすることで悪意のあるネットワークトラフィックから保護します。マネージドルールグループをファイアウォールポリシーで構成すると、Network Firewall は自動的に、コマンド＆コントロール (C2)、マルウェアステージングホスト、シンクホール、アウトオブバンドテスト (OAST)、マイニングプールなどの指標カテゴリに対する悪意のある IP、ドメイン、URL へのトラフィックをブロックするようになります。TCP、UDP、DNS、HTTPS、HTTP などの様々なプロトコルに対する受信トラフィックと送信トラフィックの包括的なフィルタリングを実装し、特定の検証済み脅威指標を使用して高い精度を実現し、誤検知を最小限に抑えます。 アクティブ脅威防御を備えた Network Firewall は、以下のメカニズムを使用して AWS ワークロードを保護します。 脅威防止 : Amazon の脅威インテリジェンスを使用して AWS のワークロードを標的とするアクティブな脅威を特定し、防止することで、悪意のあるトラフィックを自動的にブロックします 迅速な保護 : 新たに発見された脅威に基づいて Network Firewall のルールを継続的に更新し、それらに対する即時の保護を可能にします 合理化された運用 : 脅威リスト名「Amazon Active Threat Defense」でマークされた GuardDuty の検出結果は、Network Firewall でアクティブ脅威防御が有効になっている場合に自動的にブロックできるようになりました 集団防御 : ディープ脅威検査 (DTI) により脅威インテリジェンスの共有が可能になり、アクティブ脅威防御のマネージドルールによる保護が向上します 図 1 は、Network Firewall での アクティブ脅威防御マネージドルールグループの使用を示しています。 MadPot から収集された脅威データを使用して、AWS マネージドルールグループにステートフルルールが自動的に作成される様子を示しています。 図 1: アクティブ脅威防御を備えた Network Firewall 開始ガイド アクティブ脅威防御マネージドルールグループは、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して、Network Firewall 内で直接有効にすることができます。その後、マネージドルールグループを Network Firewall ポリシーに関連付けることができます。ルールグループは、新しい脅威指標とシグネチャで定期的に更新され、非アクティブまたは期限切れのシグネチャは自動的に削除されます。 前提条件 アクティブ脅威防御を備えた Network Firewall を使い始めるには、Network Firewall コンソールにアクセスするか、 AWS Network Firewall 開発者ガイド を参照してください。アクティブ脅威防御は、AWS GovCloud (米国) リージョンと中国リージョンを含め、Network Firewall が現在利用可能なすべての AWS リージョン でサポートされています。 Network Firewall を初めて使用する場合は、以下の前提条件を完了していることを確認してください。すでにファイアウォールポリシーとファイアウォールがある場合は、このセクションをスキップできます。 ファイアウォールポリシーを作成する ファイアウォールを作成する アクティブ脅威防御 (Active Threat Defense) マネージドルールグループの設定 前提条件が整ったら、アクティブ脅威防御マネージドルールグループを設定して使用できます。 マネージドルールグループの設定 AWS Network Firewall コンソールで、ナビゲーションペインの ファイアウォールポリシー を選択します。 既存のファイアウォールポリシーまたは前提条件として作成したポリシーを選択します。 図 2: Network Firewall ポリシーの選択 下にスクロールして ステートフルルールグループ を表示します。右側で アクション を選択し、 マネージドステートフルルールグループを追加 を選択します。 図 3: ルールグループの追加 マネージドステートフルルールグループを追加 ページで、下にスクロールして Active Threat Defense を表示します。ルールグループ AttackInfrastructure を選択します。 ディープ脅威検査 の要件に基づいて、Network Firewall にサービスログを処理させたくない場合はオプトアウトできます。 ポリシーに追加 を選択します。 図 4: ポリシーへのルールグループの追加 次のページで、マネージドルールグループがポリシーに追加されたことを確認できます。 図 5: マネージドルールグループがポリシーに追加されたことの確認 料金 アクティブ脅威防御の料金については、 AWS Network Firewall の料金 をご覧ください。 考慮事項 最初の考慮事項は、TLS インスペクション機能をアクティブ脅威防御マネージドルールグループと併用することで、Network Firewall が HTTPS トラフィックに関連する脅威の検出と緩和においてより効果的になることです。TLS インスペクションにより、アクティブ脅威防御は暗号化された接続の実際のコンテンツを分析できるようになり、検出されずに通過する可能性のある悪意のある URL を特定してブロックすることができます。このプロセスでは、トラフィックを復号し、既知の悪意のある URL パターンや動作がないかコンテンツを検査し、安全と判断された場合はトラフィックを再暗号化します。TLS インスペクションに関する考慮事項の詳細については、 TLS インスペクションの考慮事項 をご覧ください。組織はセキュリティ上の利点と潜在的な遅延の導入のバランスを取り、復号された機密データを適切に処理するための適切な制御を確保する必要があります。 もう一つの考慮事項は、誤検知の緩和です。このマネージドルールグループをファイアウォールポリシーで使用する場合、 ルールグループのアラート設定 を編集して、緩和戦略の一環として誤検知を特定することができます。詳細については、 誤検知の緩和 をご覧ください。 最後の考慮事項は、マネージドルールグループの使用が各ポリシーのステートフルルールの制限にどのようにカウントされるかです。詳細については、 AWS Network Firewall のクォータ および AWS Network Firewall でのルールグループ容量の設定 をご覧ください。 まとめ このブログでは、AWS Network Firewall のアクティブ脅威防御マネージドルールグループを使用して、アクティブな脅威からワークロードを保護する方法を説明しました。 Amit Gaur Amit は AWS のクラウドインフラストラクチャアーキテクトであり、テクノロジーへの情熱と知識共有をネットワーキングコミュニティにもたらしています。ネットワークアーキテクチャ設計を専門とし、お客様が AWS 上で高度にスケーラブルで回復力のある環境を構築するのを支援しています。技術的なガイダンスとアーキテクチャの専門知識を通じて、Amit はお客様がシステムのスケールと信頼性を確保しながら、クラウド導入の旅を加速できるようにします。 Tim Sutton Tim は AWS のシニアクラウドインフラストラクチャアーキテクトであり、テクノロジーにおける 20 年以上の経験と、クラウドテクノロジー、エンタープライズアーキテクチャ、ビジネス変革における豊富な経験を持っています。Tim は、お客様がスケーラブルなクラウドソリューションを設計・実装し、テクノロジーを通じてビジネス目標を達成するのを支援することに情熱を持っており、次世代のクラウドプロフェッショナルの指導も行っています。 Prashanth Kalika Prashanth は、ネットワーキング、セキュリティ、クラウドのユースケースに対する革新的でスケーラブルなソリューションの開発において 20 年以上の経験を持っています。現在は、お客様がクラウドワークロードをより適切に保護できるよう、AWS Firewall の高度な脅威インテリジェンス機能の開発に注力しています。Prashanth は、組織が堅牢なネットワーク防御を維持しながら進化するサイバー脅威に先んじることを支援するセキュリティソリューションの構築に情熱を注いでいます。 Saleem Muhammad Saleem は AWS Network &amp; Application Protection のシニアマネージャー (プロダクトマネジメント) です。ミッションクリティカルなワークロードを保護するためのソリューション構築に情熱を注いでいます。AWS 以前は、サンフランシスコベイエリアの複数の数十億ドル規模の IT 製品・サービス企業でインキュベーションプロジェクトに携わっていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。