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

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

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

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

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

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

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

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

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

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

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

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

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

本記事は 2025/11/25 に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 4 – DSQL components を翻訳した記事です。 Amazon Aurora DSQL  は、アクティブ-アクティブの分散データベース設計を採用しており、リージョン内およびリージョン間で、 すべてのデータベースリソースが等しく読み取りと書き込みの両方のトラフィックを処理します。この設計により、 シングルおよびマルチリージョンの Aurora DSQL クラスターにおいて 同期データレプリケーションとデータ損失ゼロの自動フェイルオーバーが 可能になります。 この Aurora DSQL に関するブログシリーズでは、 基本的な概念 を説明し、機能と注意点を探り、 トランザクションの動作 を分析してきました。この記事では、 ACID 準拠で強力な一貫性のあるリレーショナルデータベース機能を提供する、マルチリージョン分散データベースの各コンポーネントとその責務について説明します。 5 部構成の本シリーズの 第 2 回のブログ記事 では、Aurora DSQL の基本的なコンポーネントを示す次の図を紹介しました。この記事では、各コンポーネントをより詳細に見ていきます。主題に関して包括的に理解するために、第 2 回の記事の対応セクションを再確認することをお勧めします。以下の図は、Aurora DSQL 内のデータ処理ワークフローを示すシステムアーキテクチャ図です。 Amazon Aurora DSQL 内のデータ処理ワークフローを示すシステムアーキテクチャ図 クエリプロセッサ（QP）は、SQLの実行ライフサイクル全体を統括します。入力された SQL 文を解析し、実行計画を構築し、実行計画の処理を最適化します。QP はデータの取得を管理し、結果をマージし、クライアントに結果セットを返す前に必要な集計を行います。トランザクション処理中、読み取りセットと書き込みセットの両方を追跡し、トランザクションがコミットまたはロールバックするまで一時的に書き込みをスプールします。トランザクション完了時には（前回の記事で説明したように） 、QP は COMMIT プロトコル全体を調整し、他のシステムコンポーネントとの適切な連携を提供します。 QP は一時的で、ソフトステート特性を持つシェアードナッシングのコンポーネントとして 設計されています。したがって、耐久性、一貫性の強制、同時実行制御、耐障害性、スケールアウト操作などの従来のデータベース機能の多くを担当していません。これらの機能は、Aurora DSQL アーキテクチャ内の他のコンポーネントによって処理されます。インフラストラクチャの観点からは、QP は QP ホスト上の Firecracker マイクロ仮想マシン（microVM）内で動作し、各ホストが複数の QP をサポートしています。各トランザクションは単一の専用 QP によって処理されます。データベースごとに専用の QP プーラーが、接続とアクティブな QP のマッピングを管理し、厳密なデータベース分離を維持しながら効率的なリソース使用を提供します。 Aurora DSQL は、データベースカタログとメタデータに対してのみキャッシングを使用し、データキャッシングを完全に避けるという設計上の決定をしています。データベースは通常、次の3つの主要な課題に対処するためにキャッシュを使用することを考えると、この設計上の決定は直感に反するように見えるかもしれません： メモリアクセスと比較して高いストレージレイテンシー BTree などのデータ構造に対する複数のアクセスポイントの必要性 I/O ラッチによるクラッシュ一貫性を維持する要件 しかし、Aurora DSQL はこれらの課題に異なる方法で対処しています。このアーキテクチャは、QP がロックを保持せずに動作し、ストレージフリートの配置とパフォーマンスが最適化され、ラウンドトリップを最小限に抑えるために処理がプッシュダウンされるなど、いくつかの利点を提供します。この革新的なアプローチにより、キャッシングメカニズムを必要とせずに、あらゆる規模で一貫したパフォーマンスを実現しています。 Aurora DSQL の QP は、単一トランザクション処理モデルで動作します。データウェアハウスシステムとは異なり、クエリは複数のプロセッサに分散されるのではなく、単一の QP 内で実行されます。つまり、すべてのクエリ実行は QP で行われ、遅いクライアントがデータベースを遅くしたり、他のクライアントに影響を与えたりすることはありません（ノイジーネイバー問題はありません）。 アジュディケータ Aurora DSQL のアジュディケータシステムは分散コンポーネントとして機能し、複数のアジュディケータがデータベース全体で責任を共有しています。各アジュディケータは特定のキー範囲を所有しています。このシャーディングアプローチにより、単一のアジュディケータがボトルネックになることはなく、システムが複数のリージョンにわたってスケールすることが可能になります。 アジュディケータは、障害やパーティション発生時に一貫性を維持するために、高度な リースベースのシステム を実装しています。アジュディケーターがキー範囲の責任を引き受ける際、ジャーナルに対してリースを取得し、定期的なハートビートを通じてそれを維持します。このリースシステムにより、任意の時点で任意のキーに対して権限を持つアジュディケータは正確に1つだけとなり、障害シナリオ中の競合する決定を防止します。 これらのメカニズムを通じて、アジュディケータシステムは分散データベースシステムのスケーラビリティと信頼性の要件を維持しながら、堅牢な一貫性保証を提供します。 ジャーナル ジャーナルは Aurora DSQL アーキテクチャにおいて重要なコンポーネントとして機能し、データベースの耐久性の実装を根本的に再構築しています。従来のデータベースではストレージ層が耐久性の責任を担っているのに対し、Aurora DSQL ではこのタスクをジャーナルに委任しています。このアーキテクチャの選択により、機能を分離することでデータベースエンジンが大幅に簡素化されています。トランザクションはジャーナルにコミットされるとコミット済みとみなされ、トランザクション処理と耐久性保証の間に明確な境界を確立します。ジャーナルは単に操作や変更をログに記録するのではなく、トランザクションの包括的なポストイメージを保存します。このアプローチは、より大きなストレージ容量を必要とする一方で、いくつかの利点を提供します： 予測可能な回復操作を容易にします。 ストレージノードの処理を最適化します。 レプリケーション中の計算オーバーヘッドを最小限に抑えます。 ジャーナルは、高いスループットを管理するために複数のジャーナルが並列処理を行う洗練されたスケーリングモデルを採用しています。アジュディケータによって保証される順序のおかげで、トランザクションは利用可能な任意のジャーナルに書き込むことができます。コミットするアジュディケータと同じアベイラビリティーゾーン内のジャーナルを選択することで、パフォーマンスを最適化することができます。 ジャーナルはリカバリ機能を提供するために、 Amazon Simple Storage Service （Amazon S3）にスナップショットのデータを保存します。システムは定期的にスナップショットを取得し、ストレージの完全な状態を記録します。リカバリ時には、システムは最新のスナップショットをロードし、その時点からジャーナルを再生します。このアプローチにより、トランザクション履歴全体を再生することなく 耐久性保証を維持することができます。 クロスバー Aurora DSQL のジャーナルコンポーネントは、システム内の仲介役として機能するクロスバーコンポーネントにトランザクションデータを提供します。クロスバーは複数のジャーナルからのデータを完全に順序付けられたシーケンスにマージし、適切なストレージシャードにデータを配布します。重要なのは、クロスバーが操作を開始する前に、特定のタイムスタンプまですべてのジャーナルが処理を完了するのを待つ必要があることです。 クロスバーは高度なファンアウトメカニズムとして機能し、部分的に順序付けられたシステム内のすべての ジャーナルをサブスクライブして、完全に順序付けられ統合 された トランザクションのストリームを生成します。その主な責任は、キー範囲に基づいて原子的なトランザクションを分解し、各ストレージノードに割り当てられたキー空間に該当するデータのみを受け取るようにすることです。このターゲットを絞った配信により、システム効率が大幅に向上し、冗長なデータ転送が最小限に抑えられます。 クロスバーの主要な機能の1つは、ストレージノードへのデータ配信のタイミングを管理することです。監視するすべてのジャーナルで特定のタイムスタンプを確認した後にデータを転送します。この同期メカニズムは一貫性を提供しますが、潜在的なレイテンシーの課題をもたらします。これに対処するため、システムはすべての関連ジャーナルでデータが利用可能になると進む最低水準（low-water mark）を採用しています。 クロスバーは、 イレイジャーコーディングを使用した 革新的なテールレイテンシー削減アプローチを実装しています。このシステムでは、アジュディケータがメッセージを M 個のセグメントに分割し、元のメッセージは任意の k 個のセグメント（ k は M 以下）から再構築できます。これらのセグメントは複数のジャーナルに分散され、クロスバーは任意のメッセージの k 個のセグメントを受信した後に処理を進めることができます。この設計はスケーラビリティと耐障害性の両方を提供します。 これらのメカニズムを通じて、クロスバーはジャーナルとストレージノード間のデータフローを調整するという複雑なタスクを、一貫性とパフォーマンスを維持しながら管理します。この全体設計は Aurora DSQL のスケーラビリティと信頼性に貢献しています。 ストレージ Aurora DSQL のストレージ層は、データの永続性と取得のための基盤として機能し、従来のデータベースストレージシステムとは大きく異なります。その主な機能は、長期的なデータ耐久性の提供とデータクエリの実行であり、すべて複数のコンポーネントにわたって機能を分離するユニークなアーキテクチャフレームワーク内で行われます。 書き込み操作はシステムを通じて独自の経路をたどり、ジャーナルから始まり、データを適切なシャードに分割するクロスバーを経由します。その後、データはストレージノードに到達し、アプライヤーがそれをストレージシステムに取り込みます。対照的に、読み取り操作はより直接的な経路を採用し、効率性を高めるために中間コンポーネントをバイパスして  QP からストレージに直接流れます。 即時の耐久性（これはジャーナルの担当範囲）を処理する代わりに、ストレージ層は Amazon S3 に保存される定期的なスナップショットを通じて長期的な耐久性に焦点を当てています。これらのスナップショットは複数の重要な機能をサポートします： 障害後の回復 スケーリング操作 インデックスの作成 ポイントインタイムリカバリを含むバックアップと復元機能 ストレージシステムは、水平トリムの概念 （ 古いものから時系列順に処理する）に基づくガベージコレクションメカニズムを実装しており、最大トランザクション時間に対応するアジュディケータの 5 分の最低水準に合わせています。このアプローチにより、各コンポーネントはローカル時間に基づいて独自のガベージコレクションを管理でき、複雑な連携の必要性が排除されます。 ストレージノードの障害が発生した場合、システムはパーティションメンバーを他のストレージノードに再分配し、スナップショットを使用してシステムの状態を復元します。このアプローチは、ジャーナルの短期的な耐久性保証と組み合わさることで、高可用性とデータ耐久性の両方を提供します。 ストレージ層の設計は、Aurora DSQL が同時実行制御などの従来のデータベース機能を特化したコンポーネントに委任しながら、堅牢なデータ管理を重視していることを反映しています。 まとめ この記事では、Amazon Aurora DSQL の個々のコンポーネント、その処理メカニズム、そしてユニークな特徴について紹介しました。さらに、システム内での責任の分散についても説明しました。 次の記事 では、Aurora DSQL 内のクロックの概念について説明します。 Katja-Maja Kroedel Katja は AWS でデータベースと IoT の情熱的なアドボケイトです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、および戦略に関するガイダンスをお客様に提供しています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。

本記事は 2025年6月10日 に公開された「 Connect to Amazon RDS for Db2 using AWS CloudShell | AWS Database Blog 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 インスタンスへの接続は、従来 Amazon Elastic Compute Cloud (Amazon EC2) の踏み台ホストを起動するか、ローカルで Db2 クライアントを実行する必要がありました。新しい AWS CloudShell の Virtual Private Cloud (VPC) 統合環境により、Amazon EC2 不要、ローカルインストール不要、通常の Amazon RDS と AWS ネットワーキング以外のコスト不要で、安全に接続できるようになりました。 この記事では、CloudShell を使用して Amazon RDS for Db2 に接続する方法を紹介します。 ソリューション概要 CloudShell には以下のメリットがあります: ゼロコストクライアント – CloudShell は無料で、標準的なネットワークと Amazon RDS の料金のみ発生します 同一サブネット – CloudShell セッションは VPC 内の RDS データベースと同じ場所に配置されるため、レイテンシーが最小限に抑えられます Amazon EC2 不要 – 踏み台ホストのプロビジョニング、パッチ適用、管理が不要です AWS CLI プリインストール – AWS コマンドラインインターフェイス (AWS CLI) は CloudShell にデフォルトで設定されており、CloudShell はカスタム VPC ネットワーキングを完全にサポートしています このソリューションは以下のステップで構成されています: VPC 内で CloudShell を起動する IBM Data Server Driver シンクライアントをダウンロードしてインストールする プレーンテキスト (TCP/IP) と SSL 接続の両方を設定する IBM の Command line processor plus (CLPPlus) で接続をテストする 前提条件 以下の前提条件が必要です: VPC 内で到達可能な既存の RDS for Db2 インスタンス Db2 ポート (デフォルト TCP 50000+ または SSL 50xxx) へのインバウンドアクセスを許可する VPC サブネットとセキュリティグループ Amazon CloudShell へのアクセス VPC 内で CloudShell を起動する 以下の手順で VPC 内で CloudShell を起動します: AWS マネジメントコンソール にサインインし、メニューバーで CloudShell を選択します。 CloudShell ウィンドウで、 Actions を選択し、 Create VPC Environment を選択します。 Name に名前を入力します (例: PRIVATE )。 VPC で、RDS for Db2 データベースをホストしている VPC を選択します。 Subnet で、Amazon RDS for Db2 インスタンスのアベイラビリティーゾーンのサブネット ID を選択します。 Security group(s) で、TCP および SSL ポートのルールを含む最大 5 つを選択します。 Create を選択します。 CloudShell がプライベートサブネット内で再起動します。 CloudShell セッションは 30 分間非アクティブ状態が続くとタイムアウトします。Db2 クライアントは単一のスクリプトインストールなので、再作成できます。 （訳注：この Blog で紹介するスクリプトによる Db2 クライアントは非永続化領域に導入されるため、スクリプトの再実行が必要となります。） Amazon RDS for Db2 用に AWS CloudShell で Db2 クライアントをインストールする方法 直接実行 curl -sL https://bit.ly/getdb2driver | bash ダウンロードして実行 curl -sL https://bit.ly/getdb2driver -o db2-driver.sh chmod +x db2-driver.sh ./db2-driver.sh 注: 上記の短縮 URL は https://aws-blogs-artifacts-public.s3.us-east-1.amazonaws.com/artifacts/DBBLOG-4900/db2-driver.sh を指しています。 上記のスクリプトは、AWS CloudShell を Amazon RDS for Db2 に接続するための準備を行います。 ツールの出力に表示される 2 つのコマンドを実行する必要があります。 DB2 インスタンスに接続するための DSN 作成プロセスを完了します: db2inst1 ユーザーに切り替えます: sudo su - db2inst1 スクリプトを実行します: source db2-driver.sh スクリプトは db2inst1 ユーザーで実行すると以下を行います: Amazon RDS for Db2 インスタンスを一覧表示し、接続したいインスタンスを選択します RDS for Db2 インスタンス内で検出されたデータベースを db2dsdriver.cfg ファイルにカタログ登録します SSL が有効な場合、スクリプトは各データベースの SSL 接続も db2dsdriver.cfg ファイルに登録します これで、db2 コマンドラインプロセッサを使用して RDSADMIN データベースに接続して管理タスクを実行したり、ユーザー定義データベースに接続して通常の Db2 アクティビティを実行したりできます。 Amazon EC2 インスタンスで同じスクリプトを実行して、Amazon RDS for Db2 インスタンスに接続するための Db2 クライアントをインストールすることもできます。Amazon EC2 を使用する利点は、AWS CloudShell とは異なり、クライアントが永続化されることです。 （訳注：AWS CloudShell では、/home/cloudshell-user ディレクトリ以下は永続化されます。この Blog で紹介するスクリプトは、Db2 クライアントを /home/db2inst1 ディレクトリに導入するため、セッション切断後に削除されます。） トラブルシューティング curl コマンドを実行してスクリプトを直接実行し、スクリプトが何も出力しない場合は、VPC がインターネットアクセス用に適切に設定されていないことを示しています。スクリプトを正常に実行するには、インターネットアクセスが利用可能で、適切な IAM 権限があり、適切なサブネット ID を使用し、Db2 のインバウンドトラフィックが有効になっている適切なセキュリティグループが必要です。 スクリプトを実行するユーザーに適切な IAM 権限がない場合、スクリプトが失敗する可能性があります。以下のコマンドを使用して、スクリプトの実行に必要な権限を確認してください: curl -sL https://bit.ly/getdb2driver | bash -s -- --check-permissions または ./db2-driver.sh --check-permissions Amazon Secrets Manager でマスターユーザーパスワードを使用している場合は、 functions.sh で利用可能な get_master_user_password などのヘルパー関数を使用して、 MASTER_USER_PASSWORD 環境変数を設定できます。スクリプト functions.sh は db2inst1 ユーザー用にインストールされ、利用可能になっています。 Amazon RDS for Db2 データベースへの接続に使用する名前がわからない場合は、 CONN_HELP_README.txt ファイルを参照してください。このファイルには、Amazon RDS for Db2 に接続するための db2 コマンド構文が記載されています。 CloudShell は Amazon RDS for Db2 への迅速な接続を提供します。ただし、フルまたは軽量の Db2 クライアントインストールを使用するアプリケーションサーバーや Amazon EC2 インスタンスに必要な標準 Db2 クライアントの代わりにはなりません。 30 分間の非アクティブタイムアウトが発生した場合は、スクリプトを再度実行して RDS for Db2 データベースをインストールおよび登録し、再接続できます。 ツールの機能強化 このツールのソースコードは GitHub リポジトリ で公開されています。機能強化のリクエストは イシューを作成 するか、変更案を プルリクエストで送信 してください。 まとめ この記事では、わずか数コマンドで CloudShell 内で完全に Db2 コマンドラインプロセッサを Amazon RDS for Db2 に対して実行できることを紹介しました。EC2 インスタンスやローカルインストールは不要で、クリーンなサーバーレススタイルのワークフローを実現できます。ぜひご自身のユースケースでこのソリューションをお試しいただき、コメントでご意見をお聞かせください。また、Amazon EC2 インスタンスで同じスクリプトを複製して、Amazon RDS for Db2 インスタンスに接続するための Db2 クライアントをインストールすることもできます。 著者について Vikram S Khatri は Amazon RDS for Db2 のシニア DBE です。Vikram は Db2 で 20 年以上の経験があります。ゼロから新製品を開発することを楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くことを楽しんでいます。 Sumit Kumar は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを楽しんでいます。さまざまな業界のお客様が AWS クラウド上でワークロードを構築・設計するのを支援してきました。料理、チェス、家族との時間を楽しんでいます。 Rajib Sarkar は Amazon RDS for Db2 のシニアデータベースエンジニアです。Rajib は Db2 で 20 年以上の経験があります。 Ashish Saraswat は Amazon RDS for Db2 のシニアソフトウェア開発エンジニアです。Ashish は 10 年以上のソフトウェア開発経験があります。 この記事は ソリューションアーキテクト の Hidehiko Yamane が翻訳しました。

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 3 – Transaction processing を翻訳した記事です。 Amazon Aurora DSQL は、アクティブ-アクティブの分散データベース設計を採用しており、すべてのデータベースリソースが対等であり、リージョン内およびリージョン間の読み取りと書き込みトラフィックの両方に対応します。この設計により、同期データレプリケーションと、単一および複数リージョンのAurora DSQLクラスターに対する自動的なゼロデータ損失フェイルオーバーが可能になります。 このシリーズの3番目の投稿では、Aurora DSQLの2種類のトランザクションタイプ（読み取り専用と読み書き）のエンドツーエンド処理について検証します。Amazon Aurora DSQLには書き込み専用トランザクションはありません。なぜなら、各変更においてテーブルスキーマの確認や主キーの一意性を確保することが不可欠であり、その結果としてこれらも読み書きトランザクションとなるからです。 読み取り専用トランザクション 以下は、読み取り専用トランザクションのデータ処理ワークフローを示すシステムアーキテクチャ図です。 読み取り専用トランザクションのデータ処理ワークフローを示すシステムアーキテクチャ図 トランザクションフローの異なるフェーズをより深く理解するために、トランザクション開始から始まる複数のステップに分けて説明します。 トランザクション開始 : トランザクションプロセスは、クライアントが`START TRANSACTION`または`BEGIN`コマンドを発行することから始まります。フロントエンドは専用のクエリプロセッサ（QP）を割り当てます。このQPは、トランザクションのクエリを解析、計画、実行する専用のマイクロ仮想マシン（VM）です。各トランザクションには独自のQPが割り当てられます。この分離は、各トランザクションが他の同時実行トランザクションからの干渉なく独立して動作することを保証するため重要です。ステートメントを実行する前に、QPは Amazon Time Sync Service を使用して同期された現在時刻を読み取り、トランザクション開始時間τ-startを割り当てます。このタイムスタンプは、トランザクション全体の基準点となり、Auroraの分散アーキテクチャ全体での一貫性維持に重要な役割を果たします。 クエリ実行 : 初期化後、QPはSQLステートメントの包括的な解析を実行することでその主要機能を開始します。このフェーズでは、クエリの構文と意味の両方の正確さを検証し、実行計画を作成します。ストレージからデータを読み取るために、QPはシャードマップを参照して、ストレージノード全体で必要なデータの正確な位置を特定します。 ストレージノードからのデータ取得 : ストレージノードがリクエストを受信すると、各ノードは重要な事前取得チェックを実行します。これらのチェックにより、τ-start以前のタイムスタンプを持つすべてのトランザクションが完全に処理されていることを確認します。必要に応じて、ノードは一貫性保証を維持するための待機メカニズムを実装します。ストレージノードはτ-startタイムスタンプに基づくスナップショット分離を採用しています。このメカニズムにより、すべてのノードがトランザクション開始時点でのデータの一貫したビューを提供することが保証されます。このアプローチは、同時実行トランザクションから生じる可能性のある異常を効果的に防止します。その後、ストレージノードは要求されたデータを返します。データを取得した後、QPは複数のノードからの結果を集約します。Aurora DSQLのアーキテクチャはインタラクティブなトランザクションをサポートし、同じトランザクションコンテキスト内で複数のクエリを実行できるため、単一のトランザクション内でクエリプロセスを複数回繰り返すことができます。システムは、セッション全体を通じて一貫したトランザクション状態を維持し、複数の操作全体で分離保証を保持します。 トランザクションのコミット : 読み取り専用トランザクションでは、Aurora DSQLはコミット時間（τ-commit）をトランザクション開始時間（τ-start）に設定するユニークなコミットメカニズムを実装しています。これにより、論理的な観点からは実質的にゼロ期間のトランザクションが作成され、読み取り専用トランザクションが常に一貫したスナップショットを参照し、競合による失敗が発生しないことが保証されます。 読み取り書き込みトランザクション 以下は、Aurora DSQL内のデータ処理ワークフローを示すシステムアーキテクチャ図です。 Amazon Aurora DSQL内のデータ処理ワークフローを示すシステムアーキテクチャ図 トランザクション開始 : 読み書きトランザクションの初期フェーズは、読み取り専用トランザクションと同様です。 クエリ実行と書き込み処理 : 実行フェーズでは、QPは読み取り専用トランザクションと同様の方法でSQLステートメントを処理します。ただし、読み書きトランザクションでは、変更の処理に追加の複雑さが生じます。書き込み操作が発生すると、QPはこれらのデータベース変更の結果をローカルに保存し、トランザクションの期間中、効果的に書き込みをスプールします。ロールバックや切断が発生した場合、QPはスプールされた書き込みを破棄します。内部的には、Amazon Aurora DSQLでのトランザクションの実行は、同時実行メカニズムに基づいて最適化されています。使用されるMVCCの実装により、早期中止（この概念の詳細は論文 MVCCトランザクション間の競合の修復 の章 3.3.1 書き込み-書き込み競合の処理 で確認できます）が可能になり、コミット時に失敗する可能性のある読み書きトランザクションに対応します。QPがストレージから読み取る際、ストレージはデータの最新バージョンを参照しているかどうかを示します。トランザクションがすでに新しいバージョンを持つ行を更新しようとすると、トランザクションは即座に中止されます。 コミット処理 : コミット時に、QPはシャードマップを参照して、変更したキーを所有するアジュディケータを特定します。QPは書き込みセットを構築し、書き込んだ行（新しく作成された行を含む場合もあります）を含め、それらをポストイメージとともにパッケージ化してアジュディケータに送信します。最後に、この完全な書き込みセットを指定されたアジュディケータに送信します。 裁定フェーズ : 各アジュディケータは、トランザクションの開始時間（τ-start）以降に変更された行に書き込みが発生したかどうかを検証します。いずれかのアジュディケータによって競合が検出された場合、コミットは拒否されます。競合が検出されない場合、アジュディケータはコミットフェーズ中に影響を受ける行に対してロックを配置し、排他的アクセスを確保します。これらのロックは、現在のトランザクションが完了するまで他のトランザクションが同じデータを変更することを防止し、コミットされる更新の整合性を保護します。さらに、アジュディケータはτ-startを超え、以前に発行されたτ-commit値よりも大きいコミットタイムスタンプ（τ-commit）を選択します。ポストイメージとタイムスタンプはジャーナルに書き込まれます。ジャーナルがこれらの変更を確認した後、QPはクライアントにそれらを確認応答します。クライアントの観点からはトランザクションは終了しています。DSQLの観点からは、その内容をストレージノードに書き込む必要があります。 ストレージ更新フェーズ : クロスバーコンポーネントはジャーナルからトランザクションの書き込みを受け取り、キースペースの購読部分に基づいて関連する行を適切なストレージノードに転送します。これらのストレージノードはその後、変更を永続化します。 コミットフェーズの動作 データベース内のキースペースはシャード化され、アジュディケータ間で分散されており、アジュディケータの数はキースペースのサイズに比例してスケールします。その結果、各キーはグローバルに見て正確に1つのアジュディケータによって所有されています。読み書きトランザクションのコミット中、各アジュディケータは自身のキースペースがコミット可能かどうかを独立して判断し、その後、同じトランザクションに関与する他のアジュディケータと連携します。ジャーナルへのコミットの書き込みにより、コミットは成功し、永続的に保存されます。逆に、コミットが失敗した場合、関与するすべてのアジュディケータは中止する必要があります。 コミットアルゴリズムについて、このサービスは 2フェーズコミット と ワープスタイルコミット のハイブリッドアプローチを使用して、不要な往復時間を最小化しています。これは以下の図に示されています： アジュディケータが使用するコミットアルゴリズム Aurora DSQLでトランザクションをコミットすると、舞台裏では次のようなことが起こります： QPがトランザクションを担当し、変更されるデータに基づいて、どのアジュディケータが関与する必要があるかを決定します。 次に、関与するアジュディケータのうち1つを除くすべてに対して並行してPREPAREメッセージを送信します。これらのアジュディケータはトランザクションをコミットできるかどうかを確認し、指定された最終アジュディケータに応答を送信します。 最終アジュディケータは意思決定者として機能します：QPからのトランザクションデータと他のアジュディケータからの応答の両方を受け取ります。関与するすべてのアジュディケータによって競合が検出されなかった場合、トランザクションをコミットします。いずれかのアジュディケータが問題を報告した場合、トランザクションを中止し、全員に通知します。 このプロセスは効率的に設計されています – データは一度送信され、応答はシステムを通じて流れ、コミットの決定とリージョン間のデータレプリケーションの両方を1回のパスで処理します。この連携アプローチにより、分散トランザクションはシステム全体で一貫性を維持しながら、不要な往復通信を最小限に抑えることができます。 Amazon Aurora DSQL での SELECT FOR UPDATE の動作 SELECT FOR UPDATE はAmazon Aurora DSQLにおける特殊なSQLステートメントです。読み書きトランザクションでは、Aurora DSQLが読み取りレコードに対して同時実行チェックを実行しないため、 書き込みスキュー を管理するために SELECT FOR UPDATE を利用できます。詳細、例、これらのクエリの処理方法については、 Amazon Aurora DSQLにおける同時実行制御 をご覧ください。 まとめ この投稿では、Amazon Aurora DSQL内のトランザクション管理の複雑さについて探求しました。コミット処理の内部メカニズムを調査しました。 次回の投稿 では、Aurora DSQLを構成するコンポーネント（QP、アジュディケータ、ジャーナル、クロスバー、ストレージ）について包括的な分析を提供します。 著者について Katja-Maja Kroedel Katja はAWSでデータベースとIoTに情熱を持つアドボケイトです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと、IoTおよびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、戦略について顧客にガイダンスを提供しています。 翻訳はクラウドサポートエンジニアの新巻が担当しました。原文は こちら です。

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 2 – Shallow view を翻訳した記事です。 このブログ記事シリーズ では基本的なデータベースの概念と、それらが  Amazon Aurora DSQL  にどのように適用されるかの概要から始めました。 この第2回の記事では、Aurora DSQL のアーキテクチャを検証し、その設計判断が機能（楽観的ロックや PostgreSQL の機能サポートなど）にどのような影響を与えるかを説明し、アプリケーションとの互換性を評価できるようにします。ユーザーから完全に抽象化されている基盤アーキテクチャの包括的な概要を提供します。リージョンエンドポイントのみを介して操作することで、ユーザーはサービスの機能に直接アクセスできます。サービスのアーキテクチャを理解することで、その潜在能力を戦略的に活用できるようになると私は確信しています。 サービス概要 Aurora DSQL は、 オンライントランザクション処理 （OLTP）ワークロード向けに特別に設計された最新のサーバーレス分散型 SQL データベースです。PostgreSQL 互換性を念頭に置いて構築され、 その機能のサブセット を提供し、リージョン内およびリージョン間の両方で読み取りと書き込みトラフィックを処理できるピアとして、すべてのデータベースリソースが機能するアクティブ-アクティブデプロイメントモデルを採用しています。また、このサービスは実際のリソース消費量とデータストレージ要件に基づく 従量課金制の価格モデル を採用しています。 このサービスは、 同期データレプリケーション により、単一リージョンおよびマルチリージョンクラスターの両方でデータ損失ゼロを実現し、読み取りに対して書き込み後の 強い 読み取り一貫性を提供します。 次の図は、Aurora DSQL インフラストラクチャの高レベルな概要を示しており、単一リージョン（左）とウィットネスリージョンを持つマルチリージョン（右）の同期クラスターのスケーラビリティを示しています。 単一リージョンおよびウィットネスリージョンを持つマルチリージョン同期クラスターのスケーラビリティを示す Aurora DSQL インフラストラクチャの大まかな概要 単一リージョン構成では、コンピュート、トランザクションログ、ストレージの各層が3つのアベイラビリティーゾーンに分散配置された多層処理モデルで構成されており、高可用性を実現しています。アプリケーションは専用のエンドポイント経由でアクセスします。 マルチリージョン構成では、それぞれが単一リージョン構成と同じインフラストラクチャを持つ2つの同期リージョンに加え、ウィットネスリージョンと呼ばれる第3のリージョンで構成されています。ウィットネスリージョンは、トランザクションの合意形成に参加し、ネットワーク障害時におけるタイブレーカーとして機能します。 Aurora DSQL は、単一リージョン構成で 99.99% の可用性を提供し、マルチリージョン構成ではさらに高い可用性（99.999%）を実現できます。この高い信頼性を活用するためには単にサービスを複数のリージョンで稼働させるだけでは不十分で、アプリケーションが必要に応じて自動的にリージョン間を切り替えるよう設計されている必要があります。つまり、1つのリージョンで問題が発生した場合、アプリケーションは自動的に正常なリージョンに接続できることが重要です。これは非常用電源を持つのと似たような考え方で、複数の電源を用意するだけでなく、正常な電源への自動切り替え機能があってこそ真価を発揮します。この設計アプローチによって、1つのリージョンの障害が他に波及する相関障害を防ぎ、アプリケーションが稼働中のリージョンに接続できる限りサービス全体の停止を回避することが可能です。 Aurora DSQL の読み取り処理は実行元のリージョン内で完結するため、リージョン間のレイテンシーは完全に排除されます。書き込み処理では、コミット時にのみリージョン間レイテンシーが発生します。運用面では、Aurora DSQL はデータベース管理の簡素化とスケーラビリティ向上において複数のメリットを提供します。このアーキテクチャによって、コンピュート・コミット・ストレージの各層を独立してスケールできるため、ワークロードの要求に応じた精密なリソース配分が可能となります。これらの処理はすべてバックグラウンドで自動実行され、AWS が完全に管理するため、真のサーバーレス体験を実現しています。結果として、メンテナンスウィンドウが不要となり、運用負荷の軽減とシステムの可用性が向上します。 Aurora DSQL は他の AWS サービスと深く統合されており、アクセス制御のための  AWS Identity and Access Management （IAM）や監査ログのための  AWS CloudTrail  などのサービスとの連携を容易にします。 Aurora DSQL アーキテクチャ Aurora DSQL は、 Firecracker 仮想化 など、多数の Amazon のイノベーションを活用した新しい分散データベースシステムです。DSQL の設計では、コンピュートやストレージなどの単一インスタンスデータベースコンポーネントを、厳密に定義された仕様によって連携を確保しつつ、特定のタスクに集中できる疎結合なマルチテナントフリートとして再構築することで複雑さを削減しています。各コンポーネントは、それぞれのドメインにとって最適な設計判断を行います。これは次の3つの基本的な特性に沿っています： 各コンポーネントが独立して変更と改善を行う コンポーネントは個別にスケールする 各コンポーネントに対して異なるセキュリティ分離の決定が行われる Amazon Aurora DSQL の最も重要なコンポーネントは次の通りです： クエリプロセッサ （QP）は各接続専用の PostgreSQL エンジンとして機能し、SQL の処理のほとんどをローカルで処理し、読み取りに応じてデータを返し、トランザクションがコミットされるまで書き込みデータをスプールします。 アジュディケータ は読み書きトランザクションがコミットされるかどうかを決定し、分離を確保するために他のアジュディケータと通信します。 ジャーナル はコミットされたトランザクションを永続化し、アベイラビリティゾーン間、マルチリージョン構成ではリージョン間で、データを複製する順序付けられたデータストリームです。 クロスバー はジャーナルからのデータストリームをマージし、ストレージにルーティングします。 ストレージノード はデータへのアクセスを提供し、シャードキーに基づいてデータを保存します。また、データの複数の読み取りレプリカも含んでいます。 以下の図は、書き込みパス（実線）と読み取りパス（点線）を明確に示し、異なるアクセスパターンに対してシステムが最適化できる能力を強調しています。 Amazon Aurora DSQL 内のデータ処理ワークフローを示すシステムアーキテクチャ図 フロントエンド はトランザクションとセッションのルーターとして機能し、各接続を独自のクエリプロセッサにルーティングします。QP は SQL クエリを実行し、読み取りに応じて対応するデータを返す責任があり、時間ベースの分離と調整を通じて一貫した処理を提供するために メトロノーム （タイミングコンポーネント）と連携します。QP はローカルの シャードマップ を参照して、どのキーがストレージ（読み取り用）とアジュディケータ（読み書きトランザクションのコミット用）のどこに配置されているかを判断します。また、書き込みに応じてデータをバッファし、トランザクションプロトコルを管理します。Amazon Aurora DSQL のトランザクションは 最大300秒 （ハード制限）で、この期間を超えるトランザクションは拒否されます。特筆すべきは、QP が他の QP と通信することはなく、ディスクページではなく行を要求することです。Amazon Aurora DSQL は、パフォーマンス向上と QP に戻るデータ通信を削減するために述語をストレージにプッシュダウンします。これは、フィルタリング、集約、射影などの重要な処理の多くがストレージレイヤーで実行されることを意味します。各トランザクションは独自の QP を受け取り、水平方向にスケーリングが可能になり、各トランザクションが他のトランザクションに影響を与えたり、影響を受けたりすることなく独自のコンピュートリソースを確保できます。Aurora DSQL 内のコンピュートスタックは QP のみで構成されています。 コミット時に、QP はトランザクションをアジュディケータに提出し、アジュディケータは楽観的同時実行制御プロトコルを実行します。アジュディケータは特定のキー範囲を割り当てられ、複数のキーセットに影響するトランザクションについてピアと調整します。彼らはトランザクションが自分のシャード内でコミットできるかどうかを判断し、必要に応じて協力します。マルチリージョンクラスターでは、アジュディケータはすべてのリージョン間で競合する書き込みを検出します。このアプローチは楽観的同時実行制御を使用し、検証フェーズまでロックを取得せずにトランザクションを進行させます。これは分散システム全体でのデータ一貫性を維持しながら、同時操作を管理します。トランザクションの終わりに競合をチェックすることで、この方法はダーティリードやロストアップデートなどの問題を防ぎ、競合がまれなシナリオに特に適しています。 ジャーナルはコミットされたトランザクションを永続化する順序付けられたデータストリームであり、クライアントに書き込みを確認します。Amazon Aurora DSQL 内のコミットスタックはアジュディケータとジャーナルで構成され、各ジャーナルは単一のアジュディケータに排他的に関連付けられています。 クロスバーはジャーナルストリームを時系列順にマージし（ジャーナルがトランザクション順にコミットを保存するのとは対照的に）、ストレージに書き込みを発行します。 ストレージは複数のストレージノードで構成され、データは主キーに基づくレンジパーティショニングによってノード間に分散されています。ストレージノードは読み取りを提供するために存在し、短期的な耐久性については責任を負いません。ストレージは、ノード上のキーに対する大量の読み取りリクエストに対応するため、そのノードの読み取り専用レプリカを作成する場合があります。 アーキテクチャに基づく Aurora DSQL のメリット概要 以下は、この分散アーキテクチャを通じて得られるメリットの概要です（完全なリストではありません）： Aurora DSQL は、同期データレプリケーション、スナップショット分離、アトミック性、アベイラビリティーゾーン間およびリージョン間の耐久性により、強力な一貫性を持つ 原子性、一貫性、独立性、永続性（ACID）トランザクション を提供します。 Aurora DSQL は snapshot isolation とロックフリーの同時実行制御を実装しています。このアプローチの主な利点の1つは、読み取り専用トランザクションが強力な一貫性を維持しながらも、アベイラビリティーゾーン間やリージョン間のレイテンシーを発生させないことです。 書き込みトランザクションは、コミット時にリージョン間レイテンシーの往復時間（RTT）を2回発生させます。レイテンシーはステートメントごとではなくトランザクションごとに発生するため、ステートメントの数は関係ありません。 コミット前に発生するすべての処理は QP 内でローカルに行われ、各接続が専用のQPリソースを持つことで、処理の遅いクライアントが他のクライアントに影響を与えることはありません。 Aurora DSQL 内の各コンポーネントは、それぞれが受け取る個別のタスクに特化して設計されており、各コンポーネントが独立してスケールし、個別にシャーディングすることができます。これによってデータベースはさまざまな読み取り/書き込み、コンピューティング-読み取り、コンピューティング-読み取りの比率に対して動的に適応します。 コンポーネントは独立してデプロイされ、複数のステートレスホストに分散されています。必要に応じてホスト間で移動を行うため、顧客に影響を与えず、メンテナンスウィンドウを必要としません。 Aurora DSQL を使用する際の考慮事項 Aurora DSQL は PostgreSQL 互換の分散データベースで、事実上無制限のスケールと高可用性を提供します。PostgreSQL 互換ではありますが、Aurora DSQL は現在 PostgreSQL で利用可能なすべての機能を提供しているわけではありません。この機能差異は時間と共に解消されていく予定ですが、Aurora DSQL の分散アーキテクチャの特性上、一部の機能は異なる実装となります。サポートされている PostgreSQL 機能セットについては、 Aurora DSQLのドキュメント で透明性をもって公開されており、アプリケーション要件との適合性を事前に確認することができます。その結果、PostgreSQL の実績ある基盤と先進的な分散コンピューティング機能を組み合わせたデータベースが提供され、アプリケーションの将来の成長とスケール要求に対応できます。 Aurora DSQL のためにワークロードを設計する際は、以下の要素を考慮してください（完全なリストではありません）： Aurora DSQL は楽観的同時実行制御のため、ロックを実装していません。アプリケーションが明示的なデータベースロックを実装するロジックに依存している場合、アプリケーションの一部を再構築する必要があるかもしれません。詳細については、 Amazon Aurora DSQL の同時実行制御 を参照してください。 このサービスは3つ以上の読み書きエンドポイントを持つマルチリージョン構成をサポートしていません。つまり、3つ以上のリージョンでデータを同期的に複製する必要があるユースケースをサポートしていません。 Aurora DSQL は、2つの重要な設計原則に従うことで最も効果を発揮します：ホットキー書き込みとホットキー範囲の回避です。Amazon Aurora DSQL ではテーブルにランダムな主キーを定義することが理想的です。これは UUID に基づく単一キーか、または複数の列を組み合わせた高いカーディナリティを持つ複合キーを意味します。 楽観的同時実行制御を採用しているため、複数のトランザクションが同時に同じデータを変更しようとする場合（ホットキーの書き込み）、1つが成功し、他は再試行しなければならないことを意味します。 同様に、特定のキー範囲内に操作を集中すること（ホットキー範囲）は、DSQL の分散アーキテクチャが損なうことになります。 マルチリージョン構成で読み書き操作の強力な一貫性を保証するため（読み取り専用操作は対象外）、Aurora DSQL はコミット時に2往復分（2 RTT）の追加レイテンシーが発生します。このレイテンシーは選択した2つのリージョン間の物理的距離に比例して増加します。 これらの原則に沿って設計することで、Aurora DSQL の大きなメリットを最大限に活用でき、 データ要件の拡大に対応した成長と安定したパフォーマンスを実現する基盤を築くことができます。 まとめ この投稿では、Amazon Aurora DSQL のアーキテクチャと、そのアーキテクチャへの貢献、メリット、およびサービスを使用する上での考慮事項について探りました。 次回の投稿 では、Aurora DSQL のエンドツーエンドのトランザクション処理機能について詳しく掘り下げていきます。 著者について Katja-Maja Kroedel Katja  は AWS でデータベースと IoT の熱心なアドボケートです。彼女はクラウドテクノロジーの可能性を最大限に活用できるよう顧客を支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、戦略について顧客にガイダンスを提供しています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

本記事は 2025/11/25に投稿された Everything you don’t need to know about Amazon Aurora DSQL: Part 1 – Setting the scene を翻訳した記事です。 2014年に発表された  Amazon Aurora  は、高性能な商用データベースのスピードと可用性、オープンソースデータベースのシンプルさとコスト効率を組み合わせたリレーショナルデータベースエンジンで、MySQL と PostgreSQL との互換性や強化されたパフォーマンスを提供しています。re:Invent 2024 において、AWS はさらに顧客中心のイノベーションを進め、 Amazon Aurora DSQL  を発表しました—これはクラウドベースの設計でトランザクション処理に最適化された新しいサーバーレス SQL データベースです。このブログ投稿シリーズでは、Aurora DSQL の技術的詳細を共有し、基盤となるコンポーネントとサービス開発全体で行われた設計上の選択について深く掘り下げていきます。 この投稿では、Aurora DSQL のメリット、機能セット、および基盤となるコンポーネントを理解するために重要な基本概念について詳しく説明します。 Amazon Aurora DSQL  は、マルチリージョン、アクティブ-アクティブ、分散データベースエンジンを実装し、データベースクラスターのすべてのリージョンで読み取りと書き込みのワークロードの両方を容易にします。このサービスはサーバーレスかつ  PostgreSQL 互換  であり、その機能のサブセットを提供しています。あなたが消費するリソースと保存するデータの量に応じて 課金 されます。 クラウドにおける可用性と耐久性 クラウドサービスは、確実性、パフォーマンス、そして信頼性を確保するために、可用性と耐久性といった重要な指標に依存しています。可用性とは、システムやデータへのアクセスのしやすさを指し、多くの場合、稼働率の割合として測定されます。例えば、可用性が 99.99% のデータベースは、年間のダウンタイムが1時間未満となります。耐久性は、データの損失や破損なしに長期的なデータ保存を保証します。 Amazon Web Services (AWS)  では、顧客がインフラストラクチャ管理ではなくイノベーションに集中できるよう、サービスは高可用性と高耐久性を念頭に置いて設計されています。Aurora DSQL は、マルチリージョン構成で 99.999% の可用性を持つサービスレベルアグリーメント（SLA）を提供し、これは 年間5分16秒の許容ダウンタイム に相当します。また、複数のリージョンにデータを保存することでデータの耐久性を提供し、コミットが成功した後にデータが失われないことを保証します。 可用性と耐久性はクラウドサービスにとって不可欠ですが、最適なパフォーマンスを得るためには、データベースが処理するように設計された特定のワークロードのタイプを理解することも同様に重要です。これにより、 オンライントランザクション処理 （OLTP）と オンライン分析処理 （OLAP）システムの 違い について考える必要があります。 OLTP と OLAP OLTP は、高速なクエリ処理による大量の日常的なトランザクション処理に優れています。例えば、顧客の注文を処理する e コマースプラットフォームは、通常 OLTP データベースに依存しています。対照的に、OLAP は複雑なクエリとデータ分析に最適化されており、チームが膨大なデータセットを分析して実用的な洞察を導き出すビジネスインテリジェンス（BI）アプリケーションに理想的です。Aurora DSQL は OLTP ワークロード向けに設計されています。 可用性と耐久性というこれらの基本的な指標を超えて、データベースシステムの成功は、特に OLTP と OLAP の操作 観点から、特定のタイプのワークロードをどれだけうまく処理できるかにも大きく依存しています。 ACID 原子性、一貫性、独立性、永続性（ACID）は、データベースがトランザクションにおけるデータの整合性と信頼性を維持するために必要な一連の特性です。 原子性（Atomicity） は、トランザクションが単一の単位として扱われ、完全に成功するか失敗するかのいずれかになることを保証します。 一貫性（Consistency） は、トランザクションがデータベースを一つの有効な状態から別の有効な状態へ移行させることを意味します。この概念は、書き込み後の読み取り整合性などの他の一貫性モデルとは異なります。後者では「一貫性」とは、クライアントが書き込んだデータを読み取ることへの期待を指し、データベースの状態自体を指すものではありません。 独立性（Isolation） は、並行トランザクションが逐次実行と同じ効果を持つことを保証します。 永続性（Durability） は、コミットされた変更が失われないことを保証します。 Aurora DSQL はインタラクティブな ACID 準拠のトランザクションを提供します。「インタラクティブ」とは、トランザクションを開始し、データを要求、取得し、追加のコードを実行できることを意味します。これらの原則、特に独立性の実装には、高度な同時実行制御メカニズムが必要です。 トランザクション分離レベル トランザクション分離レベルは、1つのトランザクションによって行われた変更が他のトランザクションにどのように見えるかを定義します。標準的な分離レベルには以下が含まれます： Read uncommitted  – トランザクションがまだコミットされていないデータを読み取ることを許可します。 Read committed  – トランザクションがコミットされたデータのみを読み取ることを保証しますが、 ノンリピータブルリード や ファントムリード の可能性があります。ファントムリードは、トランザクションが特定の条件に基づいて行のセットを取得したが、トランザクションが完了する前に、別のトランザクションがその条件に影響する行を挿入または削除した場合に発生します。例えば、トランザクション A が今日の注文をすべてカウントするクエリを実行し、その後トランザクション B が新しい注文を追加してコミットした場合、トランザクション A がカウントクエリを再度実行すると、この新しい「ファントム」行が表示されます。 Repeatable read  – トランザクションが行を読み取ると、同じトランザクション内の後続の読み取りで同じデータを取得することを保証し、ノンリピータブルリードを防止しますが、ファントムリードは依然として許可されます。これは、個々の行にロックをかけますが、新しい行が挿入される可能性のある「ギャップ」をロックしないためです。 Snapshot isolation  – トランザクションに対して、トランザクション開始時点のデータベースの一貫したスナップショットを表示することを許可し、完全な直列化のオーバーヘッドなしに、ダーティリード、ノンリピータブルリード、およびファントムリードを防止します。その背後にある概念は、トランザクション T の開始時間とコミット時間の間にタイムスタンプを持つ T の 書き込みセット に書き込みが受け入れられていない場合、トランザクション T はコミットするというものです。言い換えれば、現在のトランザクションが書き込もうとしている行に変更が加えられている場合、トランザクションは中止されます。 Serializable  – トランザクションを一つずつ実行することで最高の分離レベルを提供し、ダーティリード、ノンリピータブルリード、およびファントムリードを防止します。その背後にある概念は、トランザクション T の開始時間とコミット時間の間にタイムスタンプを持つ T の 読み取りセット に書き込みが受け入れられていない場合、トランザクション T はコミットするというものです。言い換えれば、現在のトランザクションが読み取っている行が変更されている場合、トランザクションは中止されます。 Amazon Aurora DSQL は snapshot isolation レベルで動作しており、トランザクションタイプレベルでの説明は 後のブログ記事 で説明します。 同時実行制御 現代のデータベースはしばしば、より洗練された同時実行制御 メカニズムを実装しており、 マルチバージョン同時実行制御（MVCC） は最も広く採用されているソリューションの1つです。 MVCC はデータベースにおいて、データへの同時アクセスと変更を管理するために使用される技術です。MVCC はデータの異なるバージョンを作成することでロックの必要性を減らし、読み取り側と書き込み側が互いにブロックすることなく同時に操作できるようにします。PostgreSQL では、各行の複数のバージョンを維持することでこれを実現しており、各バージョンには作成（xmin）と削除または更新（xmax）を担当するトランザクションを記録する隠しシステムカラムが含まれています。トランザクションがデータを更新すると、元のバージョンを保持しながら行の新しいバージョンを作成します。これは、古いバージョンに xmax 値をマークし、新しい行は新しい xmin（古いバージョンのxmaxと一致）を取得し、この新しいエントリには xmax 値が設定されないことで行われます。他のトランザクションがデータを読み取る際、これらのトランザクション ID によって決定される開始時に有効だったバージョンを表示し、進行中のトランザクションによって行われた変更は無視されます。これにより、ブロックなしで同時に読み取りと書き込みが可能になり、バックグラウンドプロセスが最終的にどのトランザクションからもアクセスできなくなった古いバージョンの行を削除します。 Amazon Aurora DSQL も MVCC を使用しており、データベース内に複数のデータバージョンを格納することを意味します。 MVCC の実装では、データベースは同時変更を処理するために、悲観的ロックスキームと楽観的ロックスキームという異なる高レベルのアプローチを採用しています：悲観的同時実行制御は、競合を防ぐためにリソースを事前にロックし、現在のトランザクション内ですでに変更またはロックされたデータを同時実行トランザクションによって変更できないようにします。しかし、このアプローチは過剰なリソースロックによりパフォーマンスのボトルネックを引き起こす可能性があります。対照的に、楽観的同時実行制御は競合が稀であると仮定し、トランザクションコミット時にそれらをチェックします。これは3つのフェーズで構成されます： クライアントからのすべての SQL 文が処理され、すべての書き込みはトランザクション内でローカルに記録されます。 クライアントのコミット時に、データベースはトランザクションの読み取りと変更を評価して、コミット能力を判断します。2つの検証方法が可能です：前方検証と後方検証。 前方検証は、現在進行中のトランザクションとの競合をチェックします。 後方検証は、以前にコミットされたトランザクションとの競合をチェックします。 その後、変更はストレージに書き込まれます。競合が検出されなければ、変更はストレージに書き込まれ、そうでなければ中止されます Amazon Aurora DSQL と標準 PostgreSQL はどちらも MVCC を使用していますが、ロックに対するアプローチが異なります。Amazon Aurora DSQL は後方検証による楽観的同時実行制御を採用しているのに対し、標準 PostgreSQL は悲観的アプローチを使用しています。 まとめ この投稿では、基本的なデータベース概念と Amazon Aurora DSQL への適用について探索し、サービスの予備的な概要を提供しました。Aurora DSQL はマルチリージョン構成で 99.999% の可用性を持つサービスレベルアグリーメント（SLA）を提供し、インタラクティブな ACID 準拠のトランザクションを提供し、楽観的同時実行制御を伴う MVCC を使用しながら snapshot isolation  レベルで動作しています。 このシリーズの次の投稿 では、サービス自体の包括的な理解、その利点と制限、および基盤となるアーキテクチャについて説明します。 著者について Katja-Maja Kroedel Katja  は AWS でデータベースと IoT の情熱的なアドボケイトです。彼女は顧客がクラウドテクノロジーの可能性を最大限に活用できるよう支援しています。コンピュータエンジニアリングのバックグラウンドと IoT およびデータベースにおける豊富な経験を持ち、これらの分野におけるクラウド導入、移行、および戦略に関するガイダンスを顧客に提供するために働いています。 翻訳はソリューションアーキテクトの 永末 健太 が担当しました。原文は こちら です。

はじめに 株式会社カプコン（以下、カプコン）は、学生を対象としたゲーム開発コンペティション『CAPCOM GAMES COMPETITION』を開催しました。 このイベントでは、PLATINUM SPONSOR である Amazon Web Services (AWS) のクラウドサービスを活用し、カプコンの独自ゲームエンジン『RE ENGINE』を AWS クラウド上で提供することにより、本格的なゲーム開発に取り組む環境を実現しました。 本記事では、AWS がどのようにこのコンペティションを⽀えているかについて、技術的な詳細とともにご紹介します。 図1: CAPCOM GAME COMPETITION ロゴ イベント概要 カプコンは 2025 年 4 月から 9 月にかけて 『CAPCOM GAMES COMPETITION』 を開催しました。 このコンペティションでは参加者が自由に環境を選択できる従来の形式とは異なり、『RE ENGINE』 の使用を必須としました。これはAAAタイトル開発で実績のある『RE ENGINE』でのゲーム制作を、より多くの学生に体験していただくことで、世界水準で活躍できる若手クリエイターの早期創出を目指したものです。一般公開されていない『RE ENGINE』をゲーム制作に活用できる貴重な体験と、半年間の制作期間の間カプコンスタッフによる専門的な技術サポートを受けられるという点が、参加者にとって大きな魅力となり多数の参加応募がありましたが、最終的にその中から選抜された15チームが参加することになりました。 AWS はこのコンペティションにおいて技術的なサポートを包括的に提供し、カプコンはこれを活用して200名以上の学生が、場所を問わず高性能な開発環境にアクセスできる体制を実現しました。 また、AWSのクラウド技術を活用することで、従来は大規模な設備投資が必要だったゲーム開発環境を柔軟かつスケーラブルに提供することが可能となり、次世代のゲーム開発者育成に大きく貢献しています。 アーキテクチャ システム全体像 今回のアーキテクチャは、前年の 近畿⼤学での実習 をベースに、15 チームが同時利⽤できる設計に拡張しています。AWS のクラウドサービスを活⽤することで、セキュアで⾼性能、かつ⼤規模なゲーム開発環境を実現しました。 図2: CAPCOM GAMES COMPETITION 全体アーキテクチャ図 ネットワーク構成 15 チームが異なる拠点から安全にアクセスできるよう、 Amazon Virtual Private Cloud (VPC) を学⽣環境⽤ VPC および共通基盤⽤ VPC の 2 つに分けています。 共通基盤⽤ VPC には、学⽣が利⽤する Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを起動・停⽌するウェブアプリケーション、バージョン管理データを保存する Perforce サーバー、アセットを保存する NAS サーバーなどの共有サービスをホスティングしています。⼀⽅、学⽣が直接利⽤する 『RE ENGINE』 端末は、学⽣環境⽤ VPC に配置しています。 学⽣は、まず⾃分の PC から AWS Client VPN を利⽤して学⽣環境⽤ VPC に接続し、ゲーム開発を⾏います。ゲーム制作に使⽤するアセットやその他のデータのアップロードには、 AWS Transfer Family Web Apps を利⽤しており、これらのファイルは Amazon S3 に保存された後、NAS サーバー経由で 『RE ENGINE』 の EC2 インスタンスから利⽤できる仕組みとなっています。 開発環境 各チームには Visual Studio 開発環境がプリインストールされたワークステーション (Amazon EC2) を最⼤ 8 台まで提供しました。インスタンスタイプは NVIDIA T4 GPU を搭載した g4dn.4xlarge (16 vCPU、64 GB メモリ、20 Gbps ネットワーク) を使⽤しています。東京リージョンと⼤阪リージョンを組み合わせて約 100 台の GPU インスタンスを確保することで、学⽣は⾃宅から Amazon DCV によるリモートデスクトップアクセスを通じて快適にアクセスでき、⾼性能ワークステーションと同等の開発体験を得ることができます。 試遊環境 ゲーム開発環境に加えて、実際にゲームをプレイする試遊環境も提供しました。 Amazon API Gateway および AWS Lambda を利⽤して Web ベースのシステムを構築し、ゲームの本体は Amazon S3 に保存する仕組みとしています。さらに、 Amazon GameLift Streams を活⽤することで、ユーザーはブラウザから直接ゲームコントローラーを利⽤して、低レイテンシーでゲームをプレイできる環境を実現しました。 図3: 試遊環境アーキテクチャ図 スケーラビリティと可⽤性 15 チームが同時に開発できるよう、以下の点を考慮した設計としています。 東京リージョンでは ap-northeast-1a、1c、1d の 3 つの AZ を、⼤阪リージョンでは ap-northeast-3b、3c の 2 つの AZ を活⽤し、キャパシティを分散させることで可⽤性を確保しています。さらに、AWS のクラウドならではの柔軟性を活かし、開発期間中の利⽤状況に応じてリソースを調整しており、特に夏休み期間の利⽤ピークに備えた追加確保など、必要なタイミングで迅速にスケールアップを実現しました。 AWS による⽀援とサポート 本プロジェクトの成功に向けて、AWS は事前準備段階から運⽤期間中まで、包括的な技術⽀援とサポートを提供しました。 事前準備段階からの技術⽀援 プロジェクト開始の数ヶ⽉前（2024 年 11 ⽉〜12 ⽉）から、AWS はカプコンと密に連携を開始しました。⼤規模開発環境の運⽤⽅法、リソース確保の戦略、コスト最適化など、多岐にわたる技術的な課題について、専⾨的な知⾒を提供し、最適なアーキテクチャ設計を⽀援しました。 運⽤期間中の継続的なサポート キャパシティの確保と最適化 開発期間中、特に夏休み期間（7 ⽉〜8 ⽉）には学⽣の利⽤が急増し、東京リージョンと⼤阪リージョンを組み合わせて約 115台のインスタンスを確保する必要がありました。稼働している状態を安定的に維持するため、 EC2 オンデマンドキャパシティ予 約 を活⽤した計画的なキャパシティ確保を提案しました。利⽤ピークに備えた追加確保を迅速に対応することで、学⽣が開発に集中できる環境を提供できました。 技術的な課題解決への協⼒ 半年間の運用では、Windows ライセンス管理や macOS ユーザーのゲームパッド対応など、様々な技術的な課題が発生しました。 AWS はカプコンと協力しながら、これらの課題に対して解決案を提示することで、学生が開発に専念できる環境を維持するための技術支援を提供しました。 結果 ⾼い完⾛率の実現 参加していた 15 チーム中 14 チームが半年間の開発期間を完走し、作品を完成させることができました。完走率 93% という高い数値を達成できた要因として、AWS上に構築した 『RE ENGINE』 開発環境により、学生は自身のPCスペックや使用OSなどの制約を受けることなく、また学校・自宅の双方で制作できる自由度の高さなどにより、創作活動に集中できたことが挙げられます。 さらにカプコンスタッフによるサポートで技術面・進行管理面の両方をカバーし、加えて充実したチュートリアルと学習コンテンツで 『RE ENGINE』 の使い方を段階的に習得できる環境を提供しました。通常、このような難易度の高いコンペティションでは完走率が低くなりがちですが、十分な環境とサポートを提供することで高い完走率を実現しました。 図4: 授賞式の様子(左からAWS 賞、最優秀賞、タートル・ビーチ賞) 『RE ENGINE』 の認知拡⼤ 参加した学生からは、「RE ENGINE の性能の高さに驚いた」「企業で使っているエンジンを触る機会が嬉しい」「実際の現場での使い方や分業等のワークフローが知ることができた」といったポジティブなフィードバックを得られました。 コンペティション開催前の全く 『RE ENGINE』 を使ったことのない状態から、半年間のゲーム開発を通じて 『RE ENGINE』 を実際に使いこなし、作品を完成させる経験を積むことができました。その過程でカプコンの開発環境や技術力を肌で感じることができ、ゲーム業界への就職を目指す学生にとって貴重な経験となりました。カプコンも今回のコンペティションを通じて、 『RE ENGINE』 の認知度向上と利用ハードルの低減という当初の目的を達成することができました。 今後の展望 今回のコンペティションで得られた知見とフィードバックは、『RE ENGINE』 の今後の開発と展開に活かしていきます。外部ユーザーへの提供方法、サポート体制、チュートリアルの充実など様々な改善を進め、将来的により多くの開発者に 『RE ENGINE』 を使っていただける環境を整備していく計画です。今回の成功事例は、その過程において大きな進歩となりました。 カプコンでは、オープンカンファレンスでの技術発信、近畿大学での実習、そして今回の 『CAPCOM GAMES COMPETITION』 の開催と、継続的に外部への情報発信と社会貢献を行っており、このような取り組みを通じて「RE ENGINE開発で培われた技術やカプコンのゲーム開発などの情報を発信することで 面白いことにチャレンジしている企業だと知ってほしい」という思いのもと、来年以降も何らかの形で継続していきたいと考えています。 またAWS のクラウド技術を活用することで、地理的な制約を超えた教育機会の提供が可能となりましたので、今後もより多くの学生がゲーム開発の世界に触れられる環境を整備していきます。 今回の経験を活かし、カプコンは今後も AWS と協力しながら、『RE ENGINE』 の社外活用、産学連携の拡大、そして業界全体の発展に貢献できるよう新しい施策にチャレンジすることで、次世代のゲーム開発者育成と、ゲーム業界全体の持続的な成長に寄与することを目指します。 AWS では多くのゲーム会社様が AWS のクラウドサービスを使ってゲームを開発・運⽤するための技術⽀援をしています。またこのブログを始め、CEDEC や GDC などのゲーム業界イベントや AWS 主催のイベント ( Game Tech Night ) などでゲーム会社様向けの情報を発信しています。私たちの活動がゲーム業界の発展に貢献できる様、今後も技術とビジネスの両⾯から全⼒でお客様をサポートしていく所存です。 著者について 伊集院 勝 株式会社カプコン 基盤技術研究開発部 基盤開発支援室 室長 山田 拓海 株式会社カプコン 基盤技術研究開発部 基盤技術開発室 エンジニア 富澤 淳太 株式会社カプコン 基盤技術研究開発部 業務システム開発室 エンジニア 長田 義広 アマゾン ウェブ サービス ジャパン合同会社 ゲームエンターテイメントソリューション部 ゲームスペシャリスト シニアソリューションアーキテクト Zheng Shao アマゾン ウェブ サービス ジャパン合同会社 ゲームエンターテイメントソリューション部 ソリューションアーキテクト

この記事は「 Consolidate, modernize, transform: Edge computing for modern retail 」（記事公開日：2025 年 9 月 10 日）の翻訳記事です。 現在、小売業者は「計画的な資本投資を維持しながらインフラストラクチャをモダナイズする」という圧力の高まりに直面しています。お客様との対話から、一貫して3つのテーマが浮かび上がってきています。高額な店舗サーバーを統合する必要性、クラウドとエッジ全体で統一されたアーキテクチャを確立したいという要望、そして高度な店舗内アプリケーションをサポートする緊急性です。企業は、店舗を次世代の小売体験を提供できるインテリジェントなハブに変革しようとしていますが、既存のインフラストラクチャでこの取り組みをどのように始めればよいか苦慮していることがよくあります。本記事では、小売業者がエッジコンピューティングを活用して、既存の投資を最大限に活用しながらインフラストラクチャを統合し、統一されたクラウド-エッジアーキテクチャの確立を経て、次世代の店舗アプリケーションを実現する方法について説明します。 エッジコンピューティングのビジネスケース エッジコンピューティングは、クラウドネイティブな機能を店舗に提供することで、小売業者がインフラストラクチャを統合し、コストを削減し、高度なアプリケーションへの変革できるようサポートします。IDC によると、2028 年までに小売業者の 30% が AI チップを搭載した分散エッジコンピューティングを活用することで、店舗の IT コストを 10% 削減し、レイテンシーを低減し、IT 運用パフォーマンスを向上させるとされています。 予測可能な数値を見てみましょう。最新のエッジコンピューティングソリューションを使用することで、小売業者は以下を実現できます： 新しい店舗機能とアプリケーションのデプロイが 70% 高速化 サーバー統合による IT コストの 10% 削減 レイテンシーが 60% 向上し、アプリケーションパフォーマンスが向上 一元管理によるセキュリティとコンプライアンスの強化 レジリエンス、データ管理、ディザスタリカバリの改善 ビジネス価値を推進する主要ユースケース エッジコンピューティングは、実店舗の運営に即座に価値をもたらす 3 つの変革的な機能を実現します： 店舗サーバーの統合 多くの小売業者は、異なるアプリケーション（POS、在庫管理、セキュリティなど）のために、店舗ごとに 3〜5 台の個別サーバーを維持しています。 Amazon EKS Hybrid Nodes を使用することで、小売業者はこれらのワークロードを単一のモダンなエッジプラットフォームに統合できます。例えば、AWS パートナーの Spectro Cloud は、あるグローバルコーヒーチェーンが店舗サーバーのフットプリントを 60% 削減し、アプリケーションパフォーマンスを向上させ、管理の複雑さを軽減することを支援しています。この統合により、通常 10〜15% のコスト削減を実現しながら、将来のイノベーションの基盤を提供します。 モダンな POS（販売時点情報管理）システム 従来の POS システムは、専用ハードウェアと複雑なネットワークを必要とすることが多くありました。エッジコンピューティングを使用することで、小売業者は EKS Hybrid Nodes 上で実行されるコンテナ化されたアプリケーションを使用して、POS インフラストラクチャをモダナイズできます。AWS パートナーの Artisan Studios は、米国のクイックサービスレストランがクラウドネイティブ POS ソリューションをデプロイし、ハードウェアコストを 40% 削減しながら、アップデートの高速化と信頼性の向上を実現することを支援しました。このソリューションは、オフライン運用やリアルタイム在庫更新などの高度な機能もサポートします。 高度な店舗内アプリケーション エッジコンピューティングは、コンピュータビジョン、IoT、AI/ML ワークロードを含む次世代小売アプリケーションの基盤を提供します。小売業者は、クラウドサービスとのシームレスな統合を維持しながら、これらのワークロードをエッジで効率的に実行できます。例えば、小売業者は在庫モニタリングのためにリアルタイムで動画を処理し、IoT センサーで環境制御を行い、パーソナライズされた顧客体験のために AI モデルを実行できます。これらすべてが単一で統一されたコントロールプレーンを通じて管理されます。 Gartner によると、これにより小売業者は、単一のデジタルエクスペリエンスを通じて店舗データ、運用インテリジェンス、アプリケーションを統合した従業員向けの「スーパーアプリ」をデプロイできます。例えば、 GameStop は、すべての店舗、配送センター、本社の拠点にわたってタスクとコミュニケーションを統合する「現場従業員向けのスーパーアプリ」を使用しています。監査作業、ロス削減、従業員エンゲージメントにおいて測定可能な改善を実現し、より良い意思決定のためのリアルタイム分析を可能にしました。 AWS は、小売業者が Amazon EKS Hybrid Nodes に基づいたモダンなエッジコンピューティングプラットフォームを設計、および実装するための詳細な アーキテクチャガイダンス を提供しており、クラウドとエッジ環境全体で Kubernetes ワークロードの統一された管理を可能にします。さらに、軽量モデルとコンテナを使い小売拠点で AI および生成 AI 機能を活用するための ガイダンス も提供しており、お客様が実店舗に高度で革新的な機能をデプロイできるよう支援しています。AWS のリファレンスアーキテクチャと実装パターンは、ネットワーク接続、セキュリティ、可観測性、アプリケーションライフサイクル管理などの重要な考慮事項をカバーしています。各リファレンスアーキテクチャには、POS、在庫管理、コンピュータビジョンアプリケーションなどの小売ワークロード向けの具体的なガイダンスが含まれています。検証済みのパートナーソリューションと AWS Professional Services の専門知識を通じて、既存のアプリケーションと将来の小売イノベーションの両方をサポートできる、スケーラブルでレジリエントなエッジアーキテクチャを作成するための規範的なガイダンスを提供します。 図1 – AWS における小売業向けエッジコンピューティングのガイダンス 図2 – AWS におけるエッジでのAIのガイダンス 戦略的実装の考慮事項 ビジネスリーダーがエッジコンピューティングの導入を開始する際、成功への鍵は、3 つのフェーズを中心とした実用的で体系的なアプローチから始めることです： 評価 ：まず、現在の店舗テクノロジー環境をマッピングし、統合とモダナイゼーションの機会を特定します。Spectro Cloud の評価フレームワークは、小売業者が既存のインフラストラクチャ、アプリケーション要件、運用プロセスを評価し、明確なモダナイゼーションロードマップを作成するのに役立ちます。 実装 ：ニーズに最適なアプローチを選択します。新規店舗の場合、Spectro Cloud は AWS サービスとシームレスに統合される完全なエッジプラットフォームを提供します。既存の店舗の場合、Artisan Studios は、ビジネスの継続性を維持しながら、小売業者がインフラストラクチャを段階的にモダナイズすることを専門としています。多くの成功している顧客は、新規店舗では本格的なソリューションを実装し、既存店舗では段階的にアップグレードするハイブリッドアプローチを選択しています。 投資戦略 ：短期的な価値と長期的な変革目標のバランスを取ります。店舗ごとのデプロイメントモデルにより、組織はそれぞれの店舗での導入から得られる知見を活かしながら、支出を効果的に管理できます。Spectro Cloud と Artisan Studios の両社は、コストと価値実現を一致させる柔軟な消費モデルを提供しています。 AWSとともに進む道 AWS は、エッジコンピューティングへの各組織の道のりが各社により異なることを理解しています。ご紹介したアプローチは、ビジネスリーダーにとって重要な実用的な考慮事項を示しています：すなわち、初期資本要件の最小化、既存投資の最大化、そしてソリューションが効率的にスケールできることの保証、です。 Amazon EKS Hybrid Nodes はエッジコンピューティングにおける画期的な進歩をもたらし、小売業者は既存のオンプレミスのインフラストラクチャを Amazon EKS クラスターのノードとして使用できます。これにより、クラウドとエッジ環境全体で統一された Kubernetes 管理が実現し、その運用が大幅に簡素化されコストが削減されます。 エッジコンピューティングの導入を加速するために、AWS は以下を提供しています： Amazon EKS Hybrid Nodes ：オンプレミスのエッジロケーションと AWS クラウド全体で Kubernetes ワークロードを一貫して実行 AWS Outposts ファミリー ：AWS のサービスと運用モデルをあらゆる施設に提供 AWS Professional Services ：深い技術的専門知識と実装ガイダンス 検証済み パートナーソリューション ：Spectro Cloud や Artisan Studios などのパートナーによる事前構築された小売ソリューション 次のステップ エッジコンピューティングは、イノベーションから必須要素へと進化しました。AWS の包括的なサービスとパートナーソリューションにより、大規模な資本投資や専門知識を必要とせずに、店舗の変革を開始できます。IDC が予測するように、「2026 年までに、小売ツールの 90% が AI アルゴリズムを組み込むようになる」でしょう。こんにち、堅牢なエッジコンピューティングインフラストラクチャを確立する小売業者は、これらの次世代アプリケーションを活用するための独自の立場に立つことができます。 競合他社に先を越されないようにしましょう。今すぐ AWS 担当者に連絡して、ディスカバリーセッションをスケジュールし、店舗でエッジコンピューティングの力を引き出す方法をご確認ください。小売業の未来は、インテリジェントで、レスポンシブで、エッジによって支えられています。変革をリードする準備はできていますか？ その他のリソース: A deep dive into Amazon EKS Hybrid Nodes Use your on-premises infrastructure in Amazon EKS clusters with Amazon EKS Hybrid Nodes 著者について Justin Swagler Justin Swagler は、AWS のワールドワイド実店舗小売責任者として、実店舗小売のグローバル戦略とThought Leadership を統括しています。Justin は、消費財、小売、戦略分野において 15 年以上の経験を持ち、イノベーション戦略、小売オペレーション、製品開発、エグゼクティブリーダーシップにわたる専門知識を有しています。組織が戦略的にイノベーションを起こし、消費者体験を再発明することを支援することに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ経営大学院で MBA を取得しています。 Jacob Cravinho Jacob Cravinho は、AWS のエンタープライズソリューションアーキテクトです。小売業界に焦点を当てたソフトウェアエンジニアリングのバックグラウンドを持っています。チャレンジを楽しみ、常に次の素晴らしい食事を探求しています。 Leland Johnson Leland Johnson は、旅行・ホスピタリティ分野を担当する AWS のシニアソリューションアーキテクトです。ソリューションアーキテクトとして、スケーラブルで安全なクラウドソリューションを設計することで、お客様のクラウドジャーニーをガイドする重要な役割を果たしています。仕事以外では、音楽演奏や軽飛行機の操縦を楽しんでいます。 Will Strye Will Strye は、小売・消費財分野を担当する AWS のシニアソリューションアーキテクトです。ソリューションアーキテクトとして、小売業界のリーダーと協力して革新的なクラウドソリューションをアーキテクトし、顧客体験を向上させ、ビジネス変革を推進するスケーラブルでレジリエントな設計を提供するとともに、テクノロジーの未来に関する戦略的ガイダンスを提供しています。仕事以外では、アート、音楽、執筆を楽しんでいます。 本ブログはソリューションアーキテクトの羽生田が翻訳しました。原文は こちら です。