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 の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 16 日に公開された Blog “ How AWS improves active defense to empower customers ” を翻訳したものです。 AWS ではセキュリティが最優先事項であり、本日は AWS をあらゆるワークロードを実行するための最も安全な場所にするという目標に向けた取り組みについてご紹介します。このブログの以前の投稿では、 MadPot (グローバルハニーポット) 、 Mithra (ドメイングラフニューラルネットワーク) 、 Sonaris (ネットワーク脅威緩和) などの内部のアクティブディフェンスシステムの詳細を共有しました。AWS では脅威インテリジェンスと自動対応の効果を高め、攻撃の検出と防止に向けた新たな手法を開発し続けています。今回は、マルウェア、ソフトウェアの脆弱性、AWS リソースの設定ミスに関連するアクティブディフェンスの進歩についてご紹介します。前述のブログ投稿でご紹介したシステムと同様に、これらは、AWS をご利用している全てのお客様に自動的に適用され、常に改善されているセキュリティ機能です。これらのトピックについては、 re:inforce 2025 Innovation Talk SEC302 でより詳しく説明します。 マルウェアの拡散阻止 金銭的な動機を持つ脅威アクターは、ネットワーク化された幅広い資産へのアクセスを獲得しようとします。脅威アクターが制御するリソースが多いほど、隠れる場所が増え、不正な操作から利益を得られる期間が長くなります。そのため、脅威アクターのマルウェアには、新しいターゲットをスキャンし、ネットワーク経由で自身のコードを他のシステムに複製し、感染を拡大させる機能がよく含まれています。このような急速に拡散する動作を放置すると、ネットワークの輻輳、サービスの可用性の喪失、データの破壊につながるリスクがあります。AWS はこのような振る舞いを可能な限り阻止したいと考えています。 AWS が採用している効果的な戦略の一つは、脅威アクターがマルウェアを集中管理している主要インフラを特定することです。多様な技術を使用して、脅威インフラの特定、検証、追跡、妨害を行っています。さまざまなセンサー位置から得られたネットワークトラフィックログ、ハニーポット活動記録、マルウェアの検体を分析して、その情報を活用して、ボットネット、不正プロキシ、マシン間で直接拡散するマルウェアを阻止しています。過去 12 か月間で、AWS は 31.5 万以上の異なる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスへ試みられた 400 万件以上のマルウェア感染を阻止しました。これらのマルウェア感染からワークロードを保護することで、AWS のネットワークとお客様だけでなく、さらなるマルウェアの拡散からインターネット全体も保護しています。 現在、AWS はネットワークルーティングレベルでお客様にアクティブディフェンス対策を適用しています。場合によっては、これらのクラウドネットワークルーティングの変更の規模が正当なお客様ワークロードに影響を与える可能性があるため、対策を講じないことを決定することもあります。このような場合、お客様固有のワークロードに対して AWS Network Firewall によるセキュリティ制御を提供します 。Amazon 脅威インテリジェンスを使用する新しい アクティブ脅威防御マネージドルールグループ により、AWS のグローバルインフラストラクチャ全体で観測された脅威活動から Amazon Virtual Private Cloud (Amazon VPC) ワークロードを保護することができます。有効にすると、マネージドルールの設定、一致するトラフィックの侵害指標の表示、コマンド＆コントロール通信、埋め込み URL、悪意のあるドメインなど、脅威アクターのインフラストラクチャに関連する不審なトラフィックの自動ブロックが可能になります。 脅威ハンティングとソフトウェア脆弱性の緩和における進歩 Amazon では、 バグバウンティ 、 脆弱性開示 、 オープンソース貢献 のプログラムでソフトウェア脆弱性研究をサポートしていることを誇りに思っています。また、Amazon が提供するソフトウェアとサービスの CVE 番号付与機関 (CNA) になることで、CVE プロセスのより積極的な参加者になりました。公開 CVE データベースのおかげで、脆弱性研究は加速しており、報告された CVE は 2013 年以降、前年比 21% 増加し、2024 年には 4 万件以上の CVE が公開されています。脆弱性を発見して解決するこの好循環は、時間の経過とともにサイバーセキュリティを向上させますが、AWS は脅威アクターが未解決の脆弱性を探して無許可でリソースにアクセスしようとしているのを観測しています。 AWS は MadPot と Sonaris を拡張して、より広範囲の悪意のある脆弱性スキャンと攻撃活動の特定・ブロックし、すべての AWS のお客様を脆弱性の露出から保護しています。実際の攻撃を特定するために、MadPot に何百もの新しい検出機能とサービスをエミュレートする機能を追加しました。可視性を拡大するにつれて、AWS は AWS ネットワーク全体で毎日何億もの CVE を悪用する試みをブロックし続けています。 これらのアクティブディフェンスシステムが CVE 悪用の攻撃を阻止する能力を向上させるにつれて、図 1 に示すように、過去 12 か月間で攻撃の総数は 55% 以上減少しました。この観測結果には AWS の制御外の要因も影響していますが、CVE 悪用の攻撃が減少していることを嬉しく思います。この傾向は、2025 年に行った検出、リージョン化、レイテンシー、ガードレールの改善と一致しています。すべてを阻止できるシステムはないため、悪用の試みが少ないということは、幅広いワークロードにわたるリスクが低減されることを意味します。 図 1: グローバルな悪意のある脆弱性悪用試行の減少を示すグラフ 実際の既知の悪用を特定するこの取り組みは、 Amazon Inspector の脆弱性インテリジェンス のユーザーに直接恩恵をもたらします。これにより、セキュリティ強化リソースをどこに投入するかを優先順位付けするための Amazon Inspector スコアがお客様に提供されます。これには、観測された悪用試行の最新日付、攻撃活動に関連する MITRE ATT&amp;CK 手法、標的とされた業界が含まれます。 AWS 上に構築されたアーキテクチャの保護 AWS はお客様のコンピューティングおよびネットワークリソースを積極的に防御しています。また、お客様が依存する AWS ネイティブリソースも防御しています。AWS アクセスキー認証情報は、お客様のアカウントへのアクセスを可能にする重要なリソースです。 AWS Identity and Access Management のベストプラクティス では、お客様が認証情報を悪用から守るための実証済みの手法を共有しています。アクティブディフェンスを通じて、AWS はこれらのベストプラクティスをまだ採用していないお客様をさらに支援しています。 AWS は毎日平均 1 億 6,700 万件の悪意のあるスキャン接続から、意図せず公開された AWS アクセスキーペアを保護しています。アクセスキーが他の手段で発見された場合に備えて、お客様が管理する IAM 認証情報の保護を拡張しました。脅威インテリジェンス分析により、お客様が管理する認証情報が脅威アクターに知られていることが判明した場合、高い権限を持つ操作へのアクセスを制限する対策を講じます。また、認証情報がどのように公開されたかを特定するためのカスタマイズされた通知をお客様に送信します。これらの取り組みは毎日お客様に成果をもたらしています。以下は、定期的に寄せられるお客様からのフィードバックの例です。 これは、数週間前に AWS からの別のアラームに基づいて既にローテーションしたアクセスキーです。新しくローテーションしたアクセスキーが、AWS からの 2 回目のアラームに含まれていたことがわかりました。つまり、アクセスキーにリンクされていたアプリがまだそれを漏洩させていたということです。 そこで月曜日に開発チームと一緒に調査し、アプリがどこからシークレットを漏洩させていたかを見つけ、修正し、公開されていたすべてのシークレット (IAM アクセスキー以外にもありました) をローテーションし、アプリに追加のセキュリティを組み込みました。 これらのアラートに再度感謝します。非常に貴重です。 – AWS のお客様 2024 年 11 月と 12 月の特定の脅威活動の事例では、お客様から Amazon Simple Storage Service (Amazon S3) ストレージ内のオブジェクトに対するランサムウェア活動が報告されました。これらの身代金要求の脅威が、公開されたお客様管理の IAM アクセスキーと高い相関関係があることが判明しました。AWS は公開されたアクセスキーを隔離し、お客様の通常の運用が安全に継続できるよう配慮しました。攻撃のリスクが高まっていたため、公開されている可能性の高いアクセスキーについて、お客様に積極的な通知を再送信しました。この期間中、AWS はお客様と協力して 3 万件以上の公開された認証情報を無効化しました。この脅威活動が始まって以来、AWS は 9 億 4,300 万件以上の悪意のあるお客様の Amazon S3 オブジェクト暗号化の試みを防止してきました。 これらの認証情報公開の検出は Amazon GuardDuty 拡張脅威検出 に取り込まれ、最新のクラウド環境における脅威検出と対応オペレーションを簡素化します。 より良い協力関係 AWS のアクティブディフェンスの取り組みは、システム基盤の各層に複数のセキュリティ対策を配置し、脅威インテリジェンスを積極的に活用することでリスクを減らしています。この多層防御アプローチは、クラウドセキュリティを効果的に強化しています。AWS はサービスに追加コストなしでアクティブディフェンスを組み込むことで、お客様が幅広い脅威から保護されるようにしています。 AWS はお客様の保護を常に改善し続けていますが、お客様のワークロード内部を見ることはないため、私たちの取り組みの一部は本質的に確率的なものです。検出が曖昧な状況では、お客様の本番システムに影響を与える可能性があるため、アクティブディフェンスを適用しません。安全を確保するために、お客様は自身の防御を決して怠るべきではありません。 AWS Identity and Access Management (IAM) 、 AWS Shield Advanced 、 AWS WAF 、 AWS Network Firewall 、 Amazon GuardDuty 、 Amazon Inspector などの AWS セキュリティサービスは、お客様が独自のニーズに合わせて設定できる予防、検出、対応を提供します。良いニュースは、協力することで、私たちは皆にとってインターネットをより安全にしているということです。 Stephen Goodman Amazon アクティブディフェンスのシニアマネージャーとして、Stephen はデータ駆動型のプログラムを主導し、AWS のお客様とインターネットを脅威アクターから保護しています。 Tom Scholl AWS VP および Distinguished Engineer の Tom は、悪意のあるアクターからのトラフィックをその発生源で追跡することで、サイバー攻撃を阻止するために世界中のネットワークと協力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 17 日に公開された Blog “ How AWS is simplifying security at scale: Four keys to faster innovation from AWS re:Inforce 2025 ” を翻訳したものです。 私がセキュリティ分野でキャリアを始めた当時は、システムを保護することは生産性を犠牲にするという事実を多くの人が受け入れていました。当時からそうである必要はなく、現在は確実にそうではありません。クラウド、特に AWS クラウドがその大きな理由です。しかし、テクノロジーが進化し、システムがより複雑になるにつれて、大規模な運用にはセキュリティへの新しいアプローチが求められます。私たちはお客様のセキュリティを最優先事項として考え、組織が安心して積極的なイノベーションを推進し、迅速にビジネスを拡大できるようなガードレールを構築しています。 AWS CISO としての新たな役割において、私は日々これが実現されているのを目の当たりにしています。お客様と会うと、生成 AI のようなテクノロジーへの期待と同時に、複雑な環境の保護や新しいタイプのリスク管理に関する質問が寄せられます。彼らはイノベーションに熱心ですが、その意欲的な取り組みをセキュリティ基盤がしっかりと支えられるという安心感を必要としています。セキュリティを損なうことなくビジネスを迅速に前進させたいと考えているのです。 本日 2025 年 6 月 17 日、 re:Inforce で、AWS がこれらのニーズからさかのぼって考え、クラウドでのセキュリティをスケールする方法を根本的に変革する取り組みについて共有しました。すべては 4 つの重要な柱に基づくセキュリティ基盤から始まります。アイデンティティとアクセス管理、データとネットワークセキュリティ、監視とインシデント対応、そしてマイグレーション・モダナイゼーション・パッチ適用の継続的な作業です。これらの柱全体で成熟したセキュリティモデルを持つ組織が、最も速くビジネス変革やイノベーションを実現しています。これらの各領域において、AWS はお客様が新しいテクノロジーを採用し、革新的な取り組みに自信を持って挑戦できるようなセキュリティ機能の提供に注力しています。 クラウドのためのアイデンティティのスケーリング お客様がクラウド運用を急速に拡大する中で、複雑な環境全体でのアイデンティティとアクセスの管理がますます困難になっていると伺っています。彼らは強力なセキュリティを維持しながらビジネスとともに成長できるソリューションを必要としています。アイデンティティとアクセス管理はクラウドセキュリティのあらゆる側面の基盤であり、この分野での成功には厳格な認証コントロールとアクセス権限への包括的な可視性の両方が必要です。 本日、 AWS IAM Access Analyzer の新しい内部アクセス検出結果を発表できることを嬉しく思います。この機能は、組織が大規模に機密データへのアクセスを管理する方法を変革し、お客様が成長するにつれて直面する複雑さに対応します。自動推論のテクノロジーを使用して、多様なポリシータイプにわたる複雑な権限レイヤーを分析し、セキュリティチームに組織内の誰がどのリソースにアクセスできるかについての包括的な可視性を提供します。新しく付与されたアクセスの日次監視と通知により、最も複雑な環境でも自信を持って最小権限アクセスを実装できるよう支援しています。これにより、お客様はクラウドでスケールする際にビジネスが求める俊敏性を維持しながら、重要なリソースのアクセスコントロールを強化するための可視性を得ることができます。 データとネットワークセキュリティを通じた変革の実現 お客様はビジネスを変革することに意欲的ですが、急速なイノベーションに対してセキュリティ対策もしっかりと対応できるという安心感が必要とされています。これは特に大規模なネットワークとデータの保護に関して言えることです。基調講演では、Comcast の CISO である Noopur Davis 氏が、彼女の組織がどのように広大なネットワークと顧客データを保護しながら、急速なイノベーションを可能にしているかを共有しました。何百万人もの顧客が彼らのサービスに依存している中で、Comcast のアプローチ「セキュリティは単に防御するだけでなく、変革を可能にするべき」に私は共感しました。 AWS はこのビジョンを、大規模なセキュリティを簡素化する新機能で実現しています。本日、 AWS Certificate Manager が ACM 発行の公開証明書とその秘密鍵を AWS 内外で使用するためにエクスポートできるようになったことを発表しました。これにより、ワークロードのセキュリティ確保に役立つ柔軟性を備えた自動証明書管理が可能になります。また、 AWS Shield を拡張し、ネットワークセキュリティ分析を実行して構成の問題を特定し、修復の推奨事項を提供する強化されたネットワークおよびアプリケーション保護機能を追加しています。AWS の生成 AI 搭載アシスタント Amazon Q Developer を使用して、シンプルな自然言語で実用的な洞察を得ることもできます。これらのイノベーションにより、チームは環境がより複雑になっても、データを保護し、進化する脅威に先んじることができます。 脅威検出と対応の向上 お客様からは、特にクラウド運用の規模が拡大するにつれて、日々進化するセキュリティ脅威に対応し続けることの難しさが共通の課題として挙げられています。従来の自動化は増大する複雑さを管理するのに役立ちますが、AI はセキュリティ運用を変革するさらに強力な機会を表しています。慎重に実装すると、AI は複雑な攻撃パターンを特定し、誤検知を減らし、大規模な対応を自動化する能力を劇的に向上させます。 本日 re:Inforce で、2 つの重要なセキュリティイノベーションを発表しました。 Amazon GuardDuty 拡張脅威検出の機能拡張と、これらのニーズに直接対応する強化された AWS Security Hub です。これらのサービスを組み合わせることで、大規模なセキュリティの簡素化を支援します。GuardDuty は AWS がトレーニングした AI と機械学習 (AI/ML) モデルを使用して、高度な多段階の脅威を検出し、実用的な洞察を提供します。一方、Security Hub はセキュリティシグナルを自動的に分析して相関付け、明確で優先順位付けされたアクションに変換することで、重要なセキュリティ問題を優先順位付けします。このアプローチにより、チームは AWS 環境全体でセキュリティリスクを効率的に検出・対応できるという安心感を持ちながら、自信を持って運用の規模を拡大することができます。 より良いセキュリティへの道のりの加速 AI や自動化などの高度な機能がセキュリティ運用を強化する一方で、セキュリティは基盤が最も重要です。クラウドへの移行は、オンプレミス環境では実現困難なレベルの、より強固なセキュリティ基盤を構築できる大きな変革のチャンスとなります。AWS に移行することで、物理的なインフラストラクチャセキュリティを管理する必要性が減少し、継続的に更新・維持される組み込みの保護機能を活用することができます。 クラウドの採用を成功させるには、単純なリフト＆シフトを超える必要があります。モダナイゼーションがこれらの利点を実現するための鍵です。 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3) 、または AWS Key Management Service (AWS KMS) などのマネージドサービスを使用するためにスタックの上位にソリューションを移行することで、後付けではなく組み込まれたセキュリティコントロールの恩恵を受けることができます。これらのサービスは AWS によって継続的にパッチが適用され維持されるため、チームはお客様のためのイノベーションに集中できます。結局のところ、より良いセキュリティへの最速の道は、コアとなる保護機能がすでに組み込まれている道なのです。 セキュリティ成功のためのパートナーシップ セキュリティ変革は組織が単独で取り組む必要のある旅ではありません。私はキャリアを通じて、適切なパートナーシップが成功を加速させ、複雑な課題に新しい視点と深い専門知識をもたらすことを目の当たりにしてきました。AWS のセキュリティパートナーは、ID ソリューションの実装からセキュリティ運用の最新化まで、本日ご紹介した 4 つの柱全体にわたってお客様を支援しています。彼らは技術的な複雑さとクラウドでのセキュリティをスケールするビジネス上の現実の両方を理解しており、多くの場合、各業界に特化した専門知識を持っており、これによりお客様は自信を持ってイノベーションをより迅速に加速することができます。 今後の展望 クラウドでの運用をスケールする際、AWS の目標は強力なセキュリティコントロールを維持しながら迅速に進む自信をお客様に提供することです。セキュリティがビジネスと共に自然にスケールすると、チームはインフラストラクチャの管理ではなく、次の構築に集中できます。 AWS が前例のない規模でセキュリティを設計、構築、運用する方法についてさらに詳しく知るために、 re:Inforce でのイノベーショントーク にぜひご参加ください。これらの 1 時間のセッションでは、最新のクラウドセキュリティの主要な柱の、セキュアな基盤、回復力のあるアーキテクチャ、AI を活用したイノベーション、大規模な脅威インテリジェンスについて探求します。 AWS CISO としての役割に就くにあたり、私は今後の機会に活力を感じています。AWS は約 20 年間、急速に革新しながらも安全に提供できるユニークなセキュリティ文化を維持してきました。生成 AI と急速な技術変化の環境を進む中で、お客様の信頼を獲得するということは、イノベーションのペースに追いつくだけでなく、それをさらに成功させるお手伝いをすることを意味します。この使命を前進させることに、これ以上ないほどの興奮を感じています。 Amy Herzog Amy は AWS の副社長兼最高情報セキュリティ責任者 (CISO) であり、セキュリティが最優先事項である企業において、クラウドセキュリティの専門家からなるグローバル組織を率いています。AWS に入社する前は、Amazon のデバイスとサービス、メディアとエンターテイメント、広告事業の CISO を務め、Alexa+ や Ring などの消費者向けテクノロジー製品のセキュリティを監督し、低軌道衛星を通じて世界中の顧客とコミュニティに高速で信頼性の高いブロードバンドを提供する Amazon のイニシアチブである Project Kuiper の安全な開発において重要な役割を果たしました。Amy のキャリアは、サイバーセキュリティ、イノベーション、企業変革の交差点で 20 年以上にわたります。彼女は MITRE Corporation で 15 年間を過ごし、政府と産業界にまたがる複雑なセキュリティ課題に対する最先端のソリューションを開発しました。また、Pivotal Software、VMware、Travelers Insurance でリーダーシップの役割を担い、テクノロジー主導のビジネス変革に焦点を当てた 2 つのスタートアップを共同設立しました。Amy は Pomona College で数学の学士号を、MIT の Sloan School of Management で MBA を取得しています。また、複数の出版物の著者であり、2 つの特許を保有しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Amazon Redshift は、クラウドで提供される完全マネージド型のペタバイト規模のデータウェアハウスサービスです。MPP (Massively Parallel Processing) アーキテクチャにより、クエリをコンピュートノード全体に分散してデータを処理します。各ノードは、割り当てられたデータに対して同一のクエリコードを実行し、並列処理を実現します。 Amazon Redshift は、データベーステーブルにカラムナーストレージを採用し、全体的なディスク I/O の必要量を削減しています。このストレージ方式は、クエリ時のデータ読み取りを最小限に抑えることで、分析クエリのパフォーマンスを大幅に向上させます。データは多くの組織にとって最も価値のある資産となり、データウェアハウスでのリアルタイムまたはニアリアルタイムの分析への需要を増加させています。この需要に応えるには、クエリのパフォーマンスを維持しながら、同時にデータをロードできるシステムが必要です。この投稿では、Amazon Redshift の同時データ取り込みオペレーションにおける主要な改善点をご紹介します。 書き込みワークロードにおける課題と問題点 データウェアハウス環境では、データへの同時アクセスの管理が重要でありながら、課題となっています。Amazon Redshift を使用するお客様は、さまざまなアプローチでデータを取り込んでいます。例えば、一般的に INSERT や COPY ステートメントを使用してテーブルにデータを読み込む方法があり、これらは 純粋な書き込み オペレーションとも呼ばれます。データの鮮度を最大化するために、低レイテンシーでの取り込みが要件となることがあります。これを実現するために、同じテーブルに対して同時にクエリを実行することができます。これを可能にするため、Amazon Redshift はデフォルトで スナップショット分離 を実装しています。スナップショット分離は、複数のトランザクションが同時に実行されている場合のデータ整合性を提供します。スナップショット分離は、各トランザクションがトランザクション開始時点のデータベースの一貫したスナップショットを参照することを保証し、データの整合性を損なう可能性のある読み取りと書き込みの競合を防ぎます。スナップショット分離により、読み取りクエリを並列に実行できるため、データウェアハウスが提供する完全なパフォーマンスを活用できます。 しかし、純粋な書き込みオペレーションは順次実行されます。具体的には、純粋な書き込みオペレーションはトランザクション全体で排他ロックを取得する必要があります。このロックは、トランザクションがデータをコミットした時点でのみ解放されます。このような場合、純粋な書き込みオペレーションのパフォーマンスは、セッション間での書き込みの直列実行速度によって制限されます。 これをより深く理解するために、純粋な書き込みオペレーションがどのように機能するかを見てみましょう。すべての純粋な書き込みオペレーションには、同じテーブルに対するスキャン、ソート、集計などの取り込み前のタスクが含まれます。取り込み前のタスクが完了すると、データの一貫性を維持しながらテーブルにデータが書き込まれます。純粋な書き込みオペレーションは直列に実行されるため、並列性がないことにより取り込み前のステップも直列に実行されていました。つまり、複数の純粋な書き込みオペレーションが同時に送信された場合、取り込み前のステップでさえ並列化されることなく、1 つずつ順番に処理されます。同一テーブルへの取り込みの並列性を向上させ、取り込みの低レイテンシー要件を満たすため、お客様はしばしばステージングテーブルを使用する回避策を採用しています。具体的には、ステージングテーブルに INSERT ... VALUES(..) ステートメントを送信します。その後、 ALTER TABLE APPEND を使用してターゲットテーブルにデータを追加する前に、ファクトテーブルや ディメンションテーブルなどの他のテーブルとの結合を実行します。このアプローチは、ステージングテーブルを維持する必要があり、 ALTER TABLE APPEND ステートメントの使用によるデータブロックの断片化により、より大きなストレージ容量が必要になる可能性があるため、望ましくありません。 まとめると、INSERT 文と COPY 文の同時実行は、排他的なロック動作のため、Amazon Redshift でのデータ取り込みワークフローのパフォーマンスと効率を最大化する際に課題となります。これらの制限を克服するには、追加の複雑さとオーバーヘッドを伴う回避策を採用する必要があります。次のセクションでは、Amazon Redshift が同時挿入の改善によってこれらの課題にどのように対処したかを説明します。 同時挿入処理とそのメリット Amazon Redshift の パッチ 187 では、同時挿入のサポートによりデータ取り込みの同時実行性が大幅に向上しました。これにより、COPY や INSERT ステートメントなどの純粋な書き込みオペレーションの同時実行が改善され、Amazon Redshift へのデータロードにかかる時間が短縮されます。具体的には、複数の純粋な書き込みオペレーションが同時に進行し、スキャン、ソート、集計などの取り込み前のタスクを並列で実行できるようになりました。 この改善を視覚化するために、異なるトランザクションから同時に実行される 2 つのクエリの例を考えてみましょう。 以下はトランザクション 1 のクエリ 1 です。 INSERT INTO table_a SELECT * FROM table_b WHERE table_b.column_x = 'value_a'; 以下は、トランザクション 2 のクエリ 2 です。 INSERT INTO table_a SELECT * FROM table_c WHERE table_c.column_y = 'value_b' 次の図は、同時挿入機能のない場合の純粋な書き込みオペレーションを簡略化して視覚化したものです。 同時挿入機能がない場合、主要なコンポーネントは以下の通りです。 まず、純粋な書き込みオペレーション (INSERT) は、それぞれ table b と table c からデータを読み取る必要があります。 ピンク色のセグメントはスキャンステップ (データの読み取り) で、緑色のセグメントは書き込みステップ (実際のデータの挿入) です。 「同時挿入前」の状態では、両方のクエリが順次実行されます。具体的には、クエリ 2 のスキャンステップは、クエリ 1 の挿入ステップが完了するのを待ってから開始されます。 たとえば、異なるトランザクションで同じサイズのクエリを 2 つ実行する場合を考えてみましょう。両方のクエリは同じ量のデータをスキャンし、ターゲットテーブルに同じ量のデータを挿入する必要があります。両方のクエリが午前 10 時に発行されたとします。まず、クエリ 1 は午前 10 時から午前 10 時 50 分までデータをスキャンし、午前 10 時 50 分から午前 11 時までデータを挿入します。次に、クエリ 2 はスキャンと挿入の量が同じなので、午前 11 時から午前 11 時 50 分までデータをスキャンし、午前 11 時 50 分から午後 12 時までデータを挿入します。両方のトランザクションは午前 10 時に開始されました。エンドツーエンドの実行時間は 2 時間です（トランザクション 2 は午後 12 時に終了）。 次の図は、前の例と異なり、同時挿入機能が使用できる場合の純粋な書き込みオペレーションを簡略化して示したものです。 同時挿入機能が有効な場合、クエリ 1 とクエリ 2 のスキャンステップを同時に実行できます。いずれかのクエリがデータを挿入する必要がある場合は、順次実行されます。異なるトランザクションで同じサイズの 2 つのクエリを使用した同じ例を考えてみましょう。両方のクエリは同じ量のデータをスキャンし、ターゲットテーブルに同じ量のデータを挿入する必要があります。ここでも、両方のクエリが午前 10 時に発行されたとします。午前 10 時に、クエリ 1 とクエリ 2 が同時に実行を開始します。午前 10 時から午前 10 時 50 分まで、クエリ 1 とクエリ 2 は並行してデータをスキャンできます。午前 10 時 50 分から午前 11 時まで、クエリ 1 がターゲットテーブルにデータを挿入します。次に、午前 11 時から午前 11 時 10 分まで、クエリ 2 がターゲットテーブルにデータを挿入します。両方のトランザクションの合計実行時間は 1 時間 10 分に短縮され、クエリ 2 は午前 11 時 10 分に完了します。このシナリオでは、両方のクエリの取り込み前のステップ (データのスキャン) を同時に実行でき、前の例と同じ時間 (50 分) で完了します。ただし、ターゲットテーブルへの実際のデータ挿入は順次実行され、クエリ 1 が最初に挿入を完了し、その後クエリ 2 が続きます。これは Amazon Redshift の同時挿入機能のパフォーマンス上の利点を示しています。取り込み前のステップを同時に実行できるようにすることで、この機能が導入される前の順次実行と比較して、全体の実行時間が 50 分短縮されます。 同時挿入により、取り込み前のステップを並行して進めることができます。取り込み前のタスクには、スキャン、ソート、集計などの単一または複数の組み合わせがあります。クエリのエンドツーエンドの実行時間において、大幅なパフォーマンス向上が達成されます。 メリット サービスが自動的に同時挿入処理を行うため、追加の設定なしでこれらのパフォーマンス改善の恩恵を受けることができます。同時挿入の改善には複数のメリットがあります。同じテーブルに書き込む際のインジェストワークロードのエンドツーエンドのパフォーマンスが向上します。社内のベンチマークでは、同じテーブルへの同時挿入トランザクションにおいて、エンドツーエンドの実行時間が最大 40% 改善されることが示されています。この機能は、特にスキャン処理の多いクエリ (データの書き込みよりもデータの読み取りに時間を要するクエリ) に効果的です。クエリにおける scan:insert の比率が高いほど、より大きなパフォーマンスの改善が期待できます。 この機能は、 データ共有によるマルチデータウェアハウス書き込み のスループットとパフォーマンスも向上させます。データ共有を通じたマルチウェアハウス書き込みにより、専用の Redshift クラスターまたはサーバーレスワークグループ全体で書き込みワークロードをスケールでき、リソース使用率を最適化し、ETL (抽出、変換、ロード) パイプラインのより予測可能なパフォーマンスを実現できます。具体的には、データ共有を通じたマルチウェアハウス書き込みでは、異なるウェアハウスからのクエリが同じテーブルにデータを書き込むことができます。同時挿入により、リソースの競合を軽減し、クエリを同時に進行させることで、これらのクエリのエンドツーエンドのパフォーマンスが向上します。 次の図は、同時挿入における内部テストのパフォーマンス改善を示しています。オレンジ色のバーはデータ共有を通じたマルチウェアハウス書き込みのパフォーマンス改善を、青色のバーは同一ウェアハウスでの同時挿入のパフォーマンス改善を示しています。グラフが示すように、INSERT オペレーションに対して SCAN オペレーションの割合が高いクエリは、この新機能により最大 40% のパフォーマンス向上が得られます。 同時挿入を使用してインジェストパイプラインを管理することで、さらなるメリットを得ることができます。 ALTER TABLE APPEND ステートメントを使用する回避策ではなく、同時挿入の利点を活用して同じテーブルに直接データを書き込むことで、ストレージ使用量を削減できます。これには 2 つの利点があります。1 つは一時テーブルの排除、もう 1 つは頻繁な ALTER TABLE APPEND ステートメントによるテーブルの断片化の軽減です。さらに、複雑な回避策を管理する運用上のオーバーヘッドを避け、頻繁なバックグラウンドでの自動実行および手動実行の VACUUM DELETE オペレーションにより一時テーブルをターゲットテーブルに追加することによって引き起こされる断片化を軽減できます。 考慮事項 Amazon Redshift の同時挿入機能の強化は大きなメリットをもたらしますが、スナップショット分離環境で発生する可能性のあるデッドロックシナリオに注意することが重要です。具体的には、スナップショット分離環境では、同じテーブルで同時書き込みトランザクションを実行する際に、特定の条件下でデッドロックが発生する可能性があります。スナップショット分離のデッドロックは、同時実行される INSERT 文と COPY 文がロックを共有して処理を進めている際に、別のステートメントが同じテーブルに対して排他ロックを必要とするオペレーション (UPDATE、DELETE、MERGE、または DDL オペレーション) を実行しようとする場合に発生します。 以下のシナリオを考えてみましょう。 トランザクション 1: INSERT/COPY INTO table_A ; トランザクション 2: INSERT/COPY INTO table_A; &lt;UPDATE/DELETE/MERGE/DDL statement&gt; table_A 共有ロックを持つ同じテーブルで INSERT および COPY オペレーションを含む複数のトランザクションが同時に実行され、そのうちの 1 つのトランザクションが純粋な書き込みオペレーションの後に UPDATE、MERGE、DELETE、DDL ステートメントなどの排他ロックを必要とするオペレーションを実行する場合、デッドロックが発生する可能性があります。このような状況でデッドロックを回避するには、排他ロックを必要とするステートメント (UPDATE、MERGE、DELETE、DDL ステートメント) を別のトランザクションに分離することで、INSERT および COPY ステートメントを同時に進行させ、排他ロックを必要とするステートメントをその後に実行することができます。あるいは、同じテーブルに対して INSERT および COPY ステートメントと MERGE、UPDATE、DELETE ステートメントを含むトランザクションの場合、アプリケーションにリトライロジックを組み込むことで、潜在的なデッドロックに対処することができます。デッドロックの詳細については、 単一のテーブルが関連する同時書き込みトランザクションの考えられるデッドロック状況 を参照し、同時実行トランザクションの例については 同時書き込みの例 を参照してください。 まとめ このブログ記事では、Amazon Redshift が単一のテーブルへの同時データ取り込みパフォーマンスの向上という重要な課題にどのように対処したかを説明しました。この機能強化により、最新データへのアクセス時の低レイテンシーとより厳格な SLA の要件を満たすことができます。このアップデートは、お客様のフィードバックに基づいて Amazon Redshift に重要な機能を実装するという私たちのコミットメントを示すものです。 著者について Raghu Kuppala は、データベース、データウェアハウス、分析の分野で経験豊富なアナリティクス スペシャリスト ソリューションアーキテクトです。仕事以外では、様々な料理を試したり、家族や友人と時間を過ごすことを楽しんでいます。 Sumant Nemmani は AWS のシニアテクニカルプロダクトマネージャーです。Amazon Redshift のお客様が、機械学習とインテリジェントなメカニズムを活用した機能を利用できるよう支援することに注力しています。これらの機能により、サービス自身によるチューニングと最適化が可能となり、お客様の利用規模が拡大しても Redshift の価格性能比を維持することができます。 Gagan Goel は AWS のソフトウェア開発マネージャーです。顧客中心のソリューションを提供するためにチームの優先順位付けとガイダンスを行い、顧客のワークロードに対するクエリパフォーマンスの監視と向上を通じて、Amazon Redshift の機能が顧客のニーズを満たすことを確実にしています。 Kshitij Batra は Amazon のソフトウェア開発エンジニアで、レジリエントでスケーラブル、高性能なソフトウェアソリューションの構築を専門としています。 Sanuj Basu は AWS のプリンシパルエンジニアで、Amazon Redshift を次世代のエクサバイトスケールのクラウドデータウェアハウスへと進化させる取り組みを主導しています。Redshift のコアデータプラットフォーム (マネージドストレージ、トランザクション、データ共有を含む) のエンジニアリングをリードし、お客様がシームレスなマルチクラスター分析とモダンなデータメッシュアーキテクチャを実現できるようにしています。Sanuj の取り組みは、Redshift のお客様が限界を突破するのを支援しています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

この記事は Improving Amazon ECS deployment consistency with SOCI Index Manifest v2 (記事公開日 : 2025 年 7 月 3 日) の翻訳です。 Seekable OCI (SOCI) は、コンテナイメージ全体をダウンロードする前にコンテナを起動すること (遅延読み込み) で、 Amazon Elastic Container Service (Amazon ECS) タスクの起動時間を短縮します。Amazon ECS では、 ソフトウェアバージョンの一貫性 によって特定の ECS デプロイメント 全体で同一のコンテナイメージが使用されることを保証し、信頼性の高いデプロイメントを実現します。しかし、SOCI を用いて ECS タスクを実行する場合、SOCI インデックスはコンテナイメージとは独立しているため、デプロイメントの途中で SOCI インデックスを変更または削除した場合に「一部のタスクは遅延読み込みされるものの、他のタスクはイメージ全体のダウンロードを必要とする」など、起動時間が予測できなくなる可能性がありました。この問題を解決するために、私たちは新しく SOCI Index Manifest v2 を導入しました。これにより、コンテナイメージと SOCI インデックスの間に明示的な関連付けを構築し、SOCI を用いた場合でも一貫したデプロイメントを実現できるようになります。 背景 SOCI を用いてコンテナイメージを遅延読み込みする場合、コンテナランタイムは SOCI インデックスを使用して「各ファイルがコンテナイメージ内のどこに格納されているか」を特定します。 SOCI の内部動作に関するブログ記事 で説明されているように、SOCI インデックスはコンテナイメージとは独立したアーティファクトであり、イメージレイヤーごとのファイルのインベントリを含みます。以下の図は、SOCI インデックス内の Subject メタデータフィールドを介して、SOCI インデックスとコンテナイメージが関連付けられていることを表しています。この実装を SOCI Index Manifest v1 と呼び、コンテナイメージを変更せずに SOCI インデックスを作成することを可能としていました。 図 1 : コンテナイメージマニフェストと SOCI Index Manifest v1 の関係性 SOCI Index Manifest v1 では、コンテナイメージと SOCI インデックスの関連付けが一方向な設計によるいくつかの制約がありました。まず、 crane や Skopeo などのイメージレプリケーションツールが、リポジトリ間でコンテナイメージを複製する際に SOCI インデックスを見落とすことがよくありました。そのため、SOCI インデックスを個別にプッシュする必要がありました。また、デプロイメントの途中で SOCI インデックスを変更または削除した場合に「一部のタスクは遅延読み込みされるものの、他のタスクはイメージ全体のダウンロードを必要とする」など、デプロイメントの一貫性が損なわれる可能性がありました。 SOCI Index Manifest v2 SOCI Index Manifest v2 では、 イメージインデックス を用いて SOCI インデックスとコンテナイメージを関連付けます。イメージインデックスは、マルチアーキテクチャイメージにおける複数プラットフォーム (amd64 や arm64 など) のコンテナイメージを関連付けたり、メタデータを付与するために使用されます。 以下の図は、SOCI Index Manifest v2 において、SOCI インデックスとコンテナイメージが、イメージインデックスのアノテーションを介して相互に関連付けられていることを表しています。 図 2 : コンテナイメージマニフェストと SOCI Index Manifest v2 の関係性 コンテナイメージと SOCI インデックスの新たな関連付けにより、一貫性のあるコンテナの実行が可能となります。イメージインデックスを削除または更新しない限り、SOCI インデックスを削除・更新することはできません。また、様々なアーキテクチャにおけるコンテナイメージと SOCI インデックスはすべて、イメージインデックス内で関連付けられるため、SOCI インデックスの大規模な管理が可能となります。これにより、削除やレプリケーションといったライフサイクル管理も合理化されます。 ウォークスルー SOCI Index Manifest v2 は、 soci convert コマンドを使用して作成できます。このウォークスルーでは、Linux 環境でコンテナイメージを操作します。ここでは、まず Finch を使用してコンテナイメージをビルドし、SOCI CLI を使用して SOCI インデックスを作成します。その後、2 つのアーティファクトを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。 1. まず、コンテナイメージをビルドするための Dockerfile を作成します。ここでは、Amazon Linux 2023 のベースイメージを使用して、nginx をインストール・実行するように設定します。 cat &lt;&lt;EOF &gt; Dockerfile FROM public.ecr.aws/amazonlinux/amazonlinux:2023-minimal RUN dnf install -y nginx CMD ["nginx", "-g", "daemon off; error_log /dev/stdout info;"] EOF 2. 続いて、コンテナイメージをビルドします。以下の例では Finch を使用していますが、 containerd イメージストア にアーティファクトを保存する任意のコンテナイメージビルダーを使用できます。 export ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text) export AWS_REGION=us-east-1 sudo finch build \ --tag $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:latest . 3. soci convert コマンドを使用して、SOCI インデックスを作成します。SOCI CLI は SOCI Snapshotter リポジトリ からダウンロードできます ( convert サブコマンドは v0.10.0 以降で利用可能です)。このとき、お使いのコンテナイメージビルダーに合わせて、適切な名前空間を指定する必要がある点に注意してください。例えば Docker を利用する場合は、 containerd イメージストアを利用するように設定 した上で --namespace moby を指定してください。 sudo soci --namespace finch convert \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:latest \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:soci-latest 4. AWS CLI を使用して、Amazon ECR リポジトリを作成します。 aws ecr create-repository \ --repository-name nginx-demo \ --region $AWS_REGION 5. Finch を使用して、コンテナイメージと SOCI インデックスを Amazon ECR リポジトリにプッシュします。 sudo finch image push \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:soci-latest 認証エラーが出る場合は、Amazon ECR にログインしていることを確認してください。 aws ecr get-login-password --region $AWS_REGION | \ sudo finch login \ --username AWS \ --password-stdin $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com 6. Amazon ECR リポジトリのアーティファクトを一覧表示するには、Amazon ECR コンソールまたは AWS CLI を使用できます。 aws ecr describe-images \ --repository-name nginx-demo \ --region $AWS_REGION 上記コマンドの出力から、リポジトリ内に 3 つのアーティファクト (コンテナイメージ、SOCI インデックス、イメージインデックス) が存在することを確認できます。 { "imageDetails": [ { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3", "imageSizeInBytes": 129069250, "imagePushedAt": "2025-05-30T18:01:06.613000+00:00", "imageManifestMediaType": "application/vnd.oci.image.manifest.v1+json", "artifactMediaType": "application/vnd.oci.image.config.v1+json" }, { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20", "imageSizeInBytes": 3590218, "imagePushedAt": "2025-05-30T18:01:06.624000+00:00", "imageManifestMediaType": "application/vnd.oci.image.manifest.v1+json", "artifactMediaType": "application/vnd.amazon.soci.index.v2+json" }, { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:98dbde520076de139d3f8e9589364daf2ed246edc686f1fd6e47dd3fbadc45a6", "imageTags": ["soci-latest"], "imageSizeInBytes": 129069250, "imagePushedAt": "2025-05-30T18:01:06.887000+00:00", "imageManifestMediaType": "application/vnd.oci.image.index.v1+json" } ] } 7. イメージインデックスを取得して、コンテナイメージと SOCI インデックスの新しい関係性を確認しましょう。 aws ecr batch-get-image \ --region $AWS_REGION \ --repository-name=nginx-demo \ --image-ids imageTag=soci-latest \ --query 'images[0].imageManifest' \ --output text | jq -r '.' イメージインデックスは SOCI Index Manifest v2 に従い、コンテナイメージと SOCI インデックスがアノテーションを介してお互いを参照していることを確認できます。 { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests": [ { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3", "size": 699, "annotations": { "com.amazon.soci.index-digest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20" }, "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20", "size": 1038, "annotations": { "com.amazon.soci.image-manifest-digest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3" }, "platform": { "architecture": "amd64", "os": "linux" }, "artifactType": "application/vnd.amazon.soci.index.v2+json" } ] } これで、 ECS タスク定義 でこのコンテナイメージのタグまたはダイジェストを参照し、 AWS Fargate 上でコンテナイメージを遅延読み込みできるようになりました。SOCI を使用してコンテナイメージを遅延読み込みするために、ECS タスク定義や ECS サービス定義 にフラグやパラメーターを追加する必要はありません。 後片付け 余分なコストの発生を防ぐために、Amazon ECR リポジトリを削除しましょう。 aws ecr delete-repository \ --repository-name nginx-demo \ --region $AWS_REGION \ --force 考慮事項 SOCI Index Manifest v2 のリリースに関して、いくつかの考慮事項があります。 SOCI Index Manifest v2 は、 SOCI Snapshotter v0.10 以降、および AWS Fargate プラットフォームバージョン 1.4.0 でサポートされています。 AWS Fargate で初めて SOCI を使用するお客様は、SOCI Index Manifest v2 のみを使用できます。この場合、AWS Fargate は SOCI Index Manifest v1 に関連付けられたコンテナイメージを遅延読み込みせず、コンテナイメージ全体をダウンロードしてからコンテナを起動します。 過去に AWS Fargate で SOCI を使用したことがあるお客様は、引き続き SOCI Index Manifest v1 を使用できます。ただし、v2 への移行を強く推奨します。この場合、AWS Fargate は SOCI Index Manifest v1 または v2 のいずれかに関連付けられたコンテナイメージを遅延読み込みします。 SOCI Index Manifest v1 から v2 に移行するには、ウォークスルーで説明した手順に従って SOCI インデックスマニフェストを作成、プッシュし直す必要があります。 AWS Fargate が使用する snapshotter (soci または overlayfs) は、 ECS タスクメタデータエンドポイント で公開されます。この値は amilazy init コンテナ を使用してログに出力し、一元的に管理できます。 SOCI Index Manifest v2 を作成すると、SOCI インデックスに関連する アノテーション が追加され、コンテナイメージマニフェストが変更されるため、コンテナイメージダイジェストも再生成されます。このとき、コンテナイメージのイメージレイヤーの内容は変更されません。 コンテナイメージがすでにコンテナイメージリポジトリに保存されている場合、SOCI インデックスを作成後、コンテナイメージをプッシュし直す必要があります。このとき、すでにレポジトリに存在するイメージレイヤーのアップロードはスキップされるため、イメージレイヤー重複によるストレージコストの増加は発生せず、新しいマニフェストファイルのみがアップロードされます。 SOCI インデックス作成の自動化ソリューションである SOCI Index Builder を使用している場合、最新バージョンにアップデートすることで SOCI Index Manifest v2 を利用できます。 最新情報については、 Amazon ECS ドキュメント または SOCI Snapshotter リポジトリ をご確認ください。 まとめ Seekable OCI (SOCI) は、コンテナイメージを遅延読み込みすることで AWS Fargate のタスク起動時間を短縮します。今回導入された SOCI Index Manifest v2 によって、SOCI を使用する際の ECS デプロイメントの一貫性について、より高い信頼性を提供するようになりました。コンテナイメージと SOCI インデックスの明示的な関連付けにより、SOCI インデックスの大規模な管理も容易になります。AWS Fargate 上の ECS タスクにおいて SOCI を利用開始するには、 Amazon ECS 開発者ガイド および SOCI Toolbox をご確認ください。また、SOCI プロジェクトと SOCI Index Manifest v2 の詳細については、 SOCI Snapshotter プロジェクト をご覧ください。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今年も半分が終わりましたね (焦り)。残りの半年で生成 AI がどんな進化を遂げるのか楽しみです。 2025 年 7 月 31 日 (木) に AWS Builders Online Series というオンラインイベントが開催されます。生成 AI もテーマに含まれていますので、ぜひ登録してみてください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、6 月 30 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「ユーザックシステム株式会社様のAWS 生成 AI 活用事例「非定型の受注業務の自動化に生成AI活用」」を公開 ユーザックシステム株式会社様は、企業の業務プロセスの自動化・効率化を支援するビジネスに取り組まれています。一方で、取引先ごとに独自ルールが存在するケースやFAXやメールで注文書のやり取りを行うケースでは、効率化が難しく、新たな方法による生産性向上が求められていました。そこで生成 AI と RPA を組み合わせて非定型の受注業務の完全自動化を目指すソリューション「Knowfa 受注AIエージェント」を Amazon Bedrockを使って開発しました。これまで RPA で対応できなかった受注業務の 80% の自動化に成功したとのことです。AWSのマネージドサービスの活用により、エンジニア 3 名とプロジェクトマネージャー 1 名という少人数体制で、約 4 ヶ月という短期間で β 版開発を実現できました。今後は、対応可能な業務範囲の拡大を目指しています。 【GENIAC】グローバル生成AIモデルプロバイダ訪米記録 2025 年 5 月 12 日 〜 16 日に、経済産業省が推進するプログラム『 Generative AI Accelerator Challenge(GENIAC) 』の採択者と共に、米国ベイエリアおよびシアトルの米大手モデルプロバイダーを訪問し、技術交流セッションを実施しました。本ブログでは、AWS、Anthropic、Meta、Cohere、NVIDIAや現地で挑戦する日本人起業家たちとディスカションした様子をレポートしています。 Amazon Nova 理解モデルにおけるパフォーマンスの最適化 本ブログでは、Amazon Nova 理解モデルのパフォーマンスを最適化する方法について説明しています。最適化のポイントは、明確な指示で構造化されたプロンプトを反復的に改善すること、Tool use において Greedy Decoding を使用する設定を行うことです。記事内にプロンプト例があるので是非参考にしてみてください。 Amazon Q Developer から Claude Sonnet 4 がアクセス可能に 先日、 Amazon Q Developer が CLI で Claude Sonnet 4 のサポートを開始し、追加コストなしで高度なコーディングと推論機能を開発プロセスに導入できるようになりました。本ブログでは、Q Developer CLI で Claude Sonnet 4 をモデルとして選択する方法と簡単なデモを紹介しています。複雑なコードリファクタリングから効率的なドキュメント作成まで便利に使えますので、まだ使ってない方は是非お試しを！ 【開催報告】 消費財業界向け Amazon Q in QuickSight ワークショップ ～生成 AI で加速するインテリジェントデータ分析～ 2025 年 6 月 9 日、AWS 目黒オフィスにて消費財業界向け Amazon Q in QuickSight ワークショップを開催しました。本ブログはそのイベントの開催報告記事です。BI に興味ある方はデータ分析ダッシュボード設計の進め方などぜひ参考にしてみてください。 Amazon Q のコスト最適化 本ブログではAmazon Q Business と Amazon Q Developerそれぞれの料金プランと機能の違いについて説明しています。いづれのサービスの最大の利点の 1 つは、予測可能なコスト構造です。コアビジネスの目標に焦点を当てながら、経費を正確に予測できますので、ご興味ある方はぜひブログを参照ください。 Amazon Nova Canvas update: Virtual try-on とスタイルオプションが一般公開 画像生成を行うモデル Amazon Nova Canvas に、 Virtual try-on 機能機能とスタイルオプションが追加 されました。このブログでは、それぞれの機能の解説・デモ・サンプルコードを紹介しています。Virtual try-on 機能は顧客体験の向上に繋がる可能性がある機能ですので、サンプルコードを参考にお試しください！ サービスアップデート Amazon Q in Connect がプロアクティブな推奨事項機能に対して 7 言語をサポート Amazon Q in Connect の、音声・チャット対応で顧客意図を検出し「プロアクティブな推奨事項を提供する機能」が、英語に加えて、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語でも利用可能になりました。多言語対応により、グローバル企業のカスタマーサービス担当者が各国の顧客とより効率的にやり取りできるようになり、問題解決の精度とスピードが向上します。詳細は こちらのドキュメント をご参照ください。 Q-Index がシームレスなアプリケーションレベル認証をサポート Amazon Q-Index の SearchRelevantContent API で、シームレスなアプリレベル認証がサポートされました。従来、サードパーティアプリで Q-Index を使う際、ユーザーは自分のアプリにログイン後、企業コンテンツを取得するために AWS IAM への再認証が必要でした。今回のアップデートにより、Trusted Token Issuer 機能を使って一度のログインだけで企業コンテンツから回答を取得できるようになり、ユーザー体験が大幅に向上します。バージニア北部、オレゴン、アイルランド、シドニーリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Q Business がレスポンスのカスタマイズ機能を開始 Amazon Q Business で新機能「レスポンスカスタマイゼーション」が提供開始されました。従来は AI の回答スタイルが固定でしたが、今回のアップデートで企業の要望に合わせて回答の口調、長さ、詳細度を自由に設定できるようになりました。例えば、カジュアルな表現で短い回答にしたり、フォーマルで詳細な回答にしたりと、組織のコミュニケーションスタイルに統一できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock で Claude モデル向けの Citations API と PDF サポートが利用可能に Amazon Bedrock の Claude モデルで Citations API と PDF サポートが追加されました。Citations API により AI 回答に根拠文書の引用が自動付与され、信頼性向上が実現します。PDF サポートでテキスト抽出やチャート分析も可能になり、法的研究や学術執筆での活用が期待されます。詳細は こちらの API ドキュメント をご参照ください。 &nbsp; Amazon Nova Canvas にVirtual try-on 機能とスタイルオプションを追加し、画像生成機能を強化 Amazon Nova Canvas に「Virtual try-on 機能」と「スタイルオプション機能」が追加されました。Virtual try-on 機能では人物画像と商品画像をアップロードするだけで、服を着た姿や家具配置をリアルに生成できます。スタイルオプションでは 8 つのスタイルから選択可能で、プロンプト指定が不要になります。バージニア北部、東京、アイルランドリージョンで利用可能です。詳細は こちらのブログ記事 をご参照ください。 Amazon SageMaker HyperPod トレーニングオペレーターの発表 Amazon SageMaker HyperPod の新しいトレーニングオペレーターが一般提供開始されました。これは Kubernetes 上で大規模な AI モデルトレーニングの耐障害性を向上させる拡張機能です。従来は 1 つのプロセスが失敗すると全ノードで完全再起動が必要でしたが、今回のアップデートにより影響を受けた部分のみを選択的に再起動する「surgical recovery」が可能になりました。詳細は こちらのドキュメント をご参照ください。 AWS Neuron 2.24 の新機能には PyTorch 2.7 と推論機能の強化が含まれます AWS Neuron 2.24 がリリースされ、AI モデルの推論処理が大幅に高速化されます。PyTorch 2.7 に対応し、大規模言語モデルの実行時間短縮を実現する prefix caching や、長い文章処理に適した context parallelism などの新機能を搭載しています。これにより Inferentia や Trainium インスタンスでの AI ワークロードがより効率的になり、コスト削減と性能向上を同時に達成できます。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。