Amazon EC2 Mac インスタンスで、開発者が Apple の システム整合性保護 (SIP: System Integrity Protection) をプログラム的に無効化できるようになりました。ルートレスとも呼ばれるシステム整合性保護 (SIP) は、Apple が OS X El Capitan (2015 年、バージョン 10.11) に導入したセキュリティ機能です。ルートユーザーアカウントの権限を制限することで、害を及ぼす可能性のあるソフトウェアからシステムを保護するように設計されています。macOS では SIP が デフォルトで有効になっています。 SIP は、保護されたファイルやフォルダへの変更を防ぎ、システム所有のファイルやディレクトリへのアクセスを制限し、不正なソフトウェアによる起動ディスクの選択を阻止することで、システムを保護します。SIP の主な目的は、1 つのパスワード、または脆弱性だけでマルウェアがデバイスを完全に制御できるようになる恐れのある、無制限のルートアクセスに関連するセキュリティリスクに対処することです。Apple は、パスワードが弱い、または設定されていない管理者アカウントで操作を行っているユーザーが多いことを特に考慮して、この保護を実装することで macOS ユーザーのためのより高度なセキュリティレベルの確保を目指しています。 SIP は日常的な使用に対して優れたマルウェア防止機能を提供しますが、開発者の場合は、開発やテストの目的で SIP を一時的に無効化しなければならないことがあります。例えば、新しいデバイスドライバやシステム拡張機能を作成するときは、コードをインストールしてテストするために SIP を無効にする必要があります。さらに、SIP は、ソフトウェアが正常に機能するために必要な特定のシステム設定へのアクセスをブロックする場合もあります。SIP を一時的に無効化することで、macOS 用のプログラムを微調整するために必要な許可が付与されますが、これは承認されたメンテナンスのために金庫室の扉を一時的に無効化するようなものであり、永久に開いたままにしておくわけではないのを覚えておくことが重要です。 Mac で SIP を無効化 するには、マシンへの物理的なアクセスが必要です。マシンは、 リカバリモードで再起動 し、 csrtutil コマンドラインツールを使用して SIP を無効にしてから、再び再起動する必要があります。 これまで、EC2 Mac インスタンスでは標準の SIP 設定で作業を行う必要がありました。物理的にアクセスする要件とリカバリモードで起動する必要性は、SIP の Amazon EC2 コントロールプレーンや EC2 API との統合を困難にしていました。これからはその煩わしさがなくなります! Amazon EC2 Mac インスタンスで SIP を自由に無効化し、再度有効化できるようになりました。その方法をご紹介しましょう。 仕組み 私が Amazon EC2 Mac インスタンスを起動したとしましょう。Apple シリコン M2 プロセッサで動作する mac2-m2.metal インスタンスです。SIP の無効化または有効化は、新しい EC2 API: CreateMacSystemIntegrityProtectionModificationTask を呼び出すという簡単なものです。この API は非同期で、インスタンスの SIP ステータスを変更するプロセスを開始します。進捗状況は、もう 1 つの新しい EC2 API である DescribeMacModificationTasks を使用して監視できます。把握しておく必要があるのは、使用したいマシンのインスタンス ID だけです。 前提条件 Apple シリコンベースの EC2 Mac インスタンスや、より最近のマシンタイプでは、新しい EC2 API を呼び出す前に ec2-user ユーザーパスワードを設定し、macOS でそのユーザーの セキュアトークン を有効にする必要があります。これには、マシンに接続して、ターミナルに 2 つのコマンドを入力する必要があります。 # on the target EC2 Mac instance # Set a password for the ec2-user user ~ % sudo /usr/bin/dscl . -passwd /Users/ec2-user New Password: (MyNewPassw0rd) # Enable secure token, with the same password, for the ec2-user # old password is the one you just set with dscl ~ % sysadminctl -newPassword MyNewPassw0rd -oldPassword MyNewPassw0rd 2025-03-05 13:16:57.261 sysadminctl[3993:3033024] Attempting to change password for ec2-user… 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] SecKeychainCopyLogin returned -25294 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] Failed to update keychain password (-25294) 2025-03-05 13:16:58.690 sysadminctl[3993:3033024] - Done # The error about the KeyChain is expected.I never connected with the GUI on this machine, so the Login keychain does not exist # you can ignore this error. The command below shows the list of keychains active in this session ~ % security list "/Library/Keychains/System.keychain" # Verify that the secure token is ENABLED ~ % sysadminctl -secureTokenStatus ec2-user 2025-03-05 13:18:12.456 sysadminctl[4017:3033614] Secure token is ENABLED for user ec2-user SIP ステータスの変更 SIP ステータスを切り替えるためにマシンに接続する必要はありません。必要なのはマシンのインスタンス ID だけです。ノートパソコンでターミナルを開き、 AWS コマンドラインインターフェイス (AWS CLI) を使用して Amazon EC2 Mac のインスタンス ID を取得します。 aws ec2 describe-instances \ --query "Reservations[].Instances[?InstanceType == 'mac2-m2.metal' ].InstanceId" \ --output text i-012a5de8da47bdff7 次に、このままノートパソコンのターミナルを使って、 create-mac-system-integrity-protection-modification-task コマンドで SIP を無効にします。 echo '{"rootVolumeUsername":"ec2-user","rootVolumePassword":"MyNewPassw0rd"}' > tmpCredentials aws ec2 create-mac-system-integrity-protection-modification-task \ --instance-id "i-012a5de8da47bdff7" \ --mac-credentials fileb://./tmpCredentials \ --mac-system-integrity-protection-status "disabled" && rm tmpCredentials { "macModificationTask": { "instanceId": "i-012a5de8da47bdff7", "macModificationTaskId": "macmodification-06a4bb89b394ac6d6", "macSystemIntegrityProtectionConfig": {}, "startTime": "2025-03-14T14:15:06Z", "taskState": "pending", "taskType": "sip-modification" } } タスクが開始されたら、 aws ec2 describe-mac-modification-tasks コマンドでステータスを確認できます。 { "macModificationTasks": [ { "instanceId": "i-012a5de8da47bdff7", "macModificationTaskId": "macmodification-06a4bb89b394ac6d6", "macSystemIntegrityProtectionConfig": { "debuggingRestrictions": "", "dTraceRestrictions": "", "filesystemProtections": "", "kextSigning": "", "nvramProtections": "", "status": "disabled" }, "startTime": "2025-03-14T14:15:06Z", "tags": [], "taskState": "in-progress", "taskType": "sip-modification" }, ... インスタンスがプロセスを開始し、一連の再起動を行います。その間、インスタンスにはアクセスできなくなります。このプロセスは、完了するまで 60～90 分かかる場合があります。完了後、コンソールのステータスが再び利用可能になったら、いつものように SSH または EC2 Instance Connect 経由でマシンに接続 します。 ➜ ~ ssh ec2-user@54.99.9.99 Warning: Permanently added '54.99.9.99' (ED25519) to the list of known hosts. Last login: Mon Feb 26 08:52:42 2024 from 1.1.1.1 ┌───┬──┐ __| __|_ ) │ ╷╭╯╷ │ _| ( / │ └╮ │ ___|\___|___| │ ╰─┼╯ │ Amazon EC2 └───┴──┘ macOS Sonoma 14.3.1 ➜ ~ uname -a Darwin Mac-mini.local 23.3.0 Darwin Kernel Version 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.81.5~7/RELEASE_ARM64_T8103 arm64 ➜ ~ csrutil --status System Integrity Protection status: disabled. SIP を無効化する状況 SIP の無効化はシステムを潜在的なセキュリティリスクにさらすことになるため、慎重に行う必要があります。とは言うものの、この記事の冒頭で話したように、macOS 用のデバイスドライバやカーネル拡張機能を開発するときは、SIP の無効化が必要になるかもしれません。古いアプリケーションの中には、SIP が有効になっているときに正しく機能しないものもあります。 SIP の無効化は、Spotlight のインデックス作成を無効にするときにも必要です。Spotlight は、Mac 上のアプリケーション、ドキュメント、E メール、その他アイテムをすばやく見つけるために役立ちます。デスクトップマシンでは非常に便利ですが、サーバーの場合はそうでもありません。ドキュメントの変更に合わせてインデックスを作成する必要がない場合は、Spotlight を無効にすることで 一部の CPU サイクルが解放され、ディスク I/O が軽減されます 。 知っておくべきこと Amazon EC2 Mac での SIP の無効化については、他にも知っておくべき事柄がいくつかあります。 SIP の無効化は、API と AWS SDK 、 AWS CLI 、 AWS マネジメントコンソール を使用して実行できます。 Apple シリコンでは、設定がボリュームベースになっています。そのため、 ルートボリュームを置き換える 場合は、SIP を再度無効にする必要があります。Intel では設定が Mac ホストベースなので、この場合もルートボリュームを置き換えると SIP が無効化されます。 SIP を無効化した後でインスタンスを停止して起動すると、SIP が再び有効になります。インスタンスを再起動しても、インスタンスの SIP ステータスは変わりません。 EBS ボリューム間で SIP ステータスを引き継ぐことはできません。つまり、EBS スナップショットからインスタンスを復元した後や、SIP が有効になっているインスタンスから AMI を作成する場合でも、SIP は再び無効になります。 これらの新しい API は、 Amazon EC2 Mac が提供されているすべてのリージョン で利用でき、追加料金はありません。今すぐお試しください。 – seb 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 20 日は、 AWS Product Lifecycle ページ をご紹介したいと思います。このページは、AWS 全体でのサービス可用性の変更に関する包括的な情報を提供する一元化されたリソースです。 新しい AWS Product Lifecycle ページは、すべてのサービス可用性情報を 1 つの便利な場所にまとめます。この専用リソースでは、1) 新規のお客様へのアクセス提供を終了するサービス、2) サポートの終了が発表されたサービス、3) サポート終了日を迎えたサービスの 3 つの主要変更カテゴリに関する詳細を把握できます。リストされている各サービスに固有のサポート終了日や推奨移行パスを確認し、関連ドキュメントへのリンクにアクセスできるため、サービスの移行をより効率的に計画できます。 AWS Product Lifecycle ページは、ワークロードに影響する可能性のある変更の最新情報を入手するために役立ち、サービス移行のより効率的な計画を可能にします。このリソースの一元的な性質により、サービスのライフサイクル情報を追跡するために必要な時間と労力が削減されるので、管理上のオーバーヘッドではなく、中核的なビジネス目標に集中できるようになります。 5 月 20 日の新しい AWS Product Lifecycle ページでは、以下のサービス変更と機能変更に関するアップデートをご覧いただけます。 2025 年の AWS サービス可用性アップデート 検討を重ねた結果、一部の AWS サービスと機能の可用性変更を発表することになりました。AWS では、サービスまたは機能のサポートを終了するという判断が、お客様の業務に大きな影響を与えることを理解しています。このような判断は、徹底した評価を経た上でのみ行われるものです。サポートの終了が必要な場合は、利用可能な代替サービスや機能に関する詳細なガイダンスと、移行のための包括的なサポートを提供します。 新規のお客様へのアクセス提供を終了するサービス 2025 年 6 月 20 日をもって、新規のお客様に対する以下のサービスまたは機能へのアクセス提供を終了します。既存のお客様は、引き続きサービスをご利用いただけます。 Amazon Timestream for LiveAnalytics サポートの終了が発表されたサービス 以下のサービスはサポート対象外となります。サービス固有のサポート終了日、詳しい移行情報については、個々のサービスドキュメントページをご覧ください。 Amazon Pinpoint AWS DMS Fleet Advisor AWS IQ AWS IoT Analytics AWS IoT Events AWS SimSpace Weaver AWS Panorama Amazon Inspector Classic Amazon Connect Voice ID サポート終了日を迎えたサービス 以下のサービスはサポート終了日に到達したため、アクセスできなくなりました。 AWS Private 5G AWS DataSync Discovery AWS Product Lifecycle ページ が利用可能になり、新しいページにはこの記事で説明したすべての変更が掲載されています。このページをブックマークするとともに、「 AWS の最新情報 」をチェックして、今後の AWS サービス可用性アップデートを確認することをお勧めします。この新しいリソースの使用方法の詳細については、 AWS または通常の AWS サポート連絡先に連絡して、影響を受けるワークロードの移行に関する具体的なガイダンスを受けてください。 – seb 原文は こちら です。

5 月 19 日は、AWS クラウドインフラストラクチャでの最新イノベーションを包括的に紹介する AWS Cloud Infrastructure Day をご紹介します。このイベントでは、コンピューティング、 人工知能と機械学習 (AI/ML) 、ストレージソリューション、ネットワーク機能、サーバーレス、アクセラレーテッドテクノロジー、およびグローバルインフラストラクチャの全体における最先端の進歩に焦点を当てます。 2025 年 5 月 22 日の午前 11 時 (米国太平洋夏時間) (米国東部夏時間の午後 2 時) から開催される 1 日限りの無料バーチャルイベント、AWS Cloud Infrastructure Day にぜひご参加ください。このイベントは、 LinkedIn Live 、 Twitter 、 YouTube 、 Twitch などの複数のプラットフォームで同時にストリーミングされます。 このイベントで予定されているハイライトをいくつかご紹介しましょう。 イベントのオープニングとして、 顧客を第一に考えるイノベーションという目標を掲げて Amazon Elastic Compute Cloud (Amazon EC2) がリリースされた 2006 年から AWS が辿ってきた道のりを、VP of EC2 Technology である Willem Visser が紹介します。Visser は、規模、キャパシティ、柔軟性に基づいてスタートアップワークロードとエンタープライズワークロードの両方をサポートするために、ほぼ 20 年の年月をかけてクラウドインフラストラクチャで達成されてきた進歩について語ります。 ストレージ機能やネットワーク機能といったサービスの並行的な進化など、AWS が完全なクラウドインフラストラクチャを創り出すためにコンピューティングインスタンスの域を超えた開発をどのように行ったのかを学ぶことができます。 GoDaddy の Principal Engineer である Todd Kennedy 氏は、GoDaddy の Graviton 導入ジャーニーと、Graviton から得たメリットを共有します。Kennedy 氏は、Rust ワークロードの Graviton への移行を明らかにする例も説明します。GoDaddy が 40% のコンピューティングコスト削減と、20% を超えるパフォーマンス向上を達成した方法を学びましょう。 このイベントでは、AWS クラウドインフラストラクチャに関連するさまざまなトピックを取り上げます。私が関心を持った興味深いトピックには、以下のようなものがあります。 エッジでの生成 AI – AWS のハイブリッドサービスとエッジサービス を使用して、データレジデンシー要件をきっかけとしたオンプレミスユースケースとエッジユースケースのための小規模言語モデル (SLM) を選択し、ファインチューニングして、デプロイする方法を学ぶことができます。 エージェント型 AI の監査性のためのサーバーレス – AWS Step Functions や AWS Lambda が不透明なエージェント型 AI システムの運用を透明かつ監査可能なワークフローに変換する方法を学ぶことができます。 アクセラレーテッドコンピューティング – サーバー、データセンター、 シリコンでの AWS のイノベーション を詳しく検証して、お客様が AI チップをどのように使用しているのかを学びます。生成 AI の使用を開始して、コストを削減する方法をご覧ください。 ネットワーク機能 – 物理的なファイバーネットワークからソフトウェア定義のネットワークまで、AWS のインフラストラクチャが比類のないパフォーマンスと信頼性を世界的な規模で実現する方法を学ぶことができます。このセッションでは、ハイブリッド環境のためのセキュアな接続ソリューションに重点を置きながら、最新のアプリケーションネットワークパターンについて説明します。 このイベントは、技術面での意思決定者や開発者に最適で、深い技術的インサイトと、最新の AWS クラウドインフラストラクチャソリューションの実践的なデモを提供します。 詳細については、イベントスケジュールを確認して、 AWS Cloud Infrastructure Day に登録してください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

コンテナワークロードを実行するときは、ソフトウェア脆弱性がリソースのセキュリティリスクをどのように引き起こすかを理解する必要があります。これまで、 Amazon Elastic Container Registry (Amazon ECR) イメージの脆弱性を特定することはできましたが、これらのイメージがコンテナ内でアクティブかどうかを判断したり、その使用状況を追跡したりすることはできませんでした。これらのイメージが実行中のクラスターで使用されているかどうかを把握できなかったため、実際のデプロイや使用パターンに基づいて修正を優先順位付けする能力にも限界がありました。 5 月 19 日より、 Amazon Inspector が脆弱性管理を強化する 2 つの新機能の提供を開始し、コンテナイメージをより包括的に確認できるようになりました。まず、Amazon Inspector が Amazon ECR イメージを実行中のコンテナにマッピングするようになりました。このため、セキュリティチームは環境内で現在実行されているコンテナに基づいて脆弱性の優先順位付けを行えるようになります。これらの新機能を使用することで、Amazon ECR イメージの脆弱性を分析するとともに、それらが現在実行中かどうか、コンテナ環境で最後に実行されたのはいつだったかに基づいて、検出結果に優先順位を付けることができます。さらに、クラスターの Amazon リソースネーム (ARN) を表示し、イメージがデプロイされている EKS ポッドまたは ECS タスクの数を確認することもできます。これは、使用状況と重大度に基づいた修正の優先順位付けに役立ちます。 次に、脆弱性スキャンのサポートを最小限のベースイメージ (scratch、distroless、Chainguard イメージなど) に拡張するとともに、 Go Toolchain 、 Oracle JDK および JRE 、 Amazon Corretto 、 Apache Tomcat 、 Apache httpd 、 WordPress (コア、テーマ、プラグイン)、 Puppeteer などの追加のエコシステムに対するサポートも拡張しました。これらの拡張は、チームが高度に最適化されたコンテナ環境でも堅牢なセキュリティを維持するために役立ちます。 Amazon Inspector は、コンテナ上で実行されているイメージを継続的に監視して追跡することで、どのコンテナイメージが環境内でアクティブに実行されており、それらがどこにデプロイされているかをチームが特定できるようにして、 Amazon Elastic Container Service (Amazon ECS) や Amazon Elastic Kubernetes Service (Amazon EKS) 内のコンテナで実行されている Amazon ECR イメージと、関連する脆弱性を検出します。このソリューションは、委任された管理者機能を用いて単一の AWS アカウント 、クロスアカウントシナリオ、および AWS Organizations の全体で Amazon ECR イメージを管理するチームをサポートし、コンテナイメージの実行パターンに基づく一元化された脆弱性管理を可能にします。 実際の動作を見てみましょう Amazon ECR イメージスキャン は、リポジトリの継続的な自動スキャン機能を提供するために Amazon Inspector と統合する 拡張スキャン を使用して、コンテナイメージ内の脆弱性を特定できるようにします。この新機能を使用するには、 Amazon ECR コンソール で拡張スキャンを有効にする必要があります。拡張スキャンは、「 Configuring enhanced scanning for images in Amazon ECR 」ドキュメントページの手順に従って有効化できます。 私は Amazon ECR 拡張スキャン機能を既に有効化しているので、追加のアクションは必要ありません。 Amazon Inspector コンソール のナビゲーションパネルにある [ 全般設定 ] に移動し、[ ECR scanning settings ](ECR スキャン設定) を選択します。ここでは、[ Last in-use date ](最終使用日) と [ Last pull date ](最終プル日) のいずれかを選択して [ Image re-scan mode ](イメージの再スキャンモード) を設定できます。ここではデフォルトの [ Last in-use date ](最終使用日) を使用し、[ Image last in use date ](イメージの最終使用日) を [14 days](14 日) に設定します。これらの設定により、過去 14 日の間に私の Amazon ECS または Amazon EKS 環境でイメージがいつ実行されたかに基づいて、Inspector がイメージを監視するようになります。これらの設定を適用すると、Amazon Inspector がコンテナで実行されているイメージに関する情報の追跡を開始し、その情報を脆弱性検出結果に組み込むようになるため、環境内のコンテナでアクティブに実行されているイメージに焦点を当てることができるようになります。 設定が完了したら、コンテナで実行されているイメージに関する情報が [ 詳細 ] メニューに表示されます。ここでは、EKS ポッドまたは ECS タスクの数とともに、最終使用日と最終プル日を確認できます。 [ Deployed ECS Tasks/EKS Pods ](デプロイされた ECS タスク/EKS ポッド) の数を選択すると、各イメージのクラスター ARN、最終使用日、タイプを確認できます。 クロスアカウントの可視性デモのため、2 つのアカウントに EKS ポッドがデプロイされたリポジトリを用意しました。[ Resources coverage ](リソースカバレッジ) メニューで [ Container repositories ](コンテナリポジトリ) に移動し、リポジトリ名を選択してから、[ Image tag ](イメージタグ) を選択します。以前と同様に、デプロイされた EKS ポッド/ECS タスクの数を確認できます。 デプロイされた EKS ポッド/ECS タスクの数を選択すると、それが別のアカウントで実行されていることがわかります。 [ 検出結果 ] メニューでは脆弱性を確認でき、そのうちの 1 つを選択すると、[ 影響を受けるリソース ] データで [ Last in use ](最終使用) 日と、脆弱性に関係する [ Deployed ECS Tasks/EKS Pods ](デプロイされた ECS タスク/EKS ポッド) を見つけることができます。これは、実際の使用状況に基づいて修正の優先順位付けを行うために役立ちます。 [ すべての検出結果 ] メニューでは、[ Account ID ](アカウント ID)、[ Image in use count ](使用中のイメージ数)、[ Image last in use at ](イメージの最終使用日) などのフィルターを使用して、アカウント管理内の脆弱性を検索できるようになりました。 主な機能と考慮事項 コンテナイメージのライフサイクルに基づく監視 – Amazon Inspector は、イメージのプッシュ日 (期間範囲は 14 日、30 日、60 日、90 日、180 日、または lifetime (ライフタイム))、イメージのプル日 (14 日、30 日、60 日、90 日、または 180 日)、停止期間 (Never (停止なし) から 14 日、30 日、60 日、90 日、または 180 日)、およびコンテナで実行されているイメージのステータスに基づいてイメージのアクティビティを判断できるようになりました。この柔軟性により、組織はその監視戦略をリポジトリイベントだけでなく、実際のコンテナイメージの使用状況に基づいてカスタマイズできるようになります。Amazon EKS と Amazon ECS のワークロードについては、最終使用、プッシュ期間、プル期間が 14 日に設定されており、これが新規のお客様のデフォルトになりました。 イメージランタイム対応の詳細情報 – 修正作業の優先順位付けを支援するため、Amazon Inspector の各検出結果には、コンテナでのイメージの最終実行日を示す lastInUseAt 日付と、イメージを現在使用しているデプロイされた EKS ポッド/ ECS タスクの数を示す InUseCount が含まれるようになりました。Amazon Inspector は、すべてのアカウントの Amazon ECR 最終プル日のデータと、Amazon ECS タスクまたは Amazon EKS ポッドコンテナで実行されているイメージのデータの両方を監視し、この情報を少なくとも 1 日 1 回更新します。Amazon Inspector はこれらの詳細情報をすべての検出結果レポートに統合し、 Amazon EventBridge とシームレスに連動します。検出結果は、ローリングウィンドウまたは固定範囲のオプションを使用する lastInUseAt フィールドに基づいてフィルタリングできます。また、過去 14 日、30 日、60 日、または 90 日間の最終実行日に基づいてイメージをフィルタリングすることも可能です。 包括的なセキュリティカバレッジ – Amazon Inspector は、単一のサービスを通じて、従来の Linux ディストリビューションと、最小限のベースイメージ (scratch、distroless、Chainguard イメージなど) の両方に対する統合脆弱性評価を提供できるようになりました。拡張されたカバレッジにより、複数のスキャンソリューションを使用する必要がなくなるのと同時に、従来のディストリビューションから高度に最適化されたコンテナ環境におよぶコンテナエコシステム全体で堅牢なセキュリティプラクティスを維持することができます。このサービスは、一元化されたプラットフォームを通じた包括的な脆弱性管理を提供することでセキュリティ業務を合理化し、あらゆるコンテナタイプの効率的な評価を可能にします。 強化されたクロスアカウント可視性 – 単一アカウント、クロスアカウント設定、AWS Organizations 全体でのセキュリティ管理が、委任された管理者機能を通じてサポートされるようになりました。Amazon Inspector は、同じ組織内のコンテナで実行されているイメージの情報を共有します。これは、ゴールデンイメージリポジトリを維持しているアカウントにとっては特に有用です。Amazon Inspector は、リソースが API を使用するアカウントに属している場合、イメージが実行されている Amazon EKS クラスターと Amazon ECS クラスターのすべての ARN を提供するため、複数の AWS アカウント全体に対する包括的な可視性が得られます。システムは、デプロイされた EKS ポッドまたは ECS タスクの情報を少なくとも 1 日 1 回更新し、アカウントが組織に参加または離脱するときも正確性を自動的に維持します。 利用可能性と料金 – 新しいコンテナマッピング機能は、 Amazon Inspector が提供されている すべての AWS リージョン で利用でき、追加料金はありません。使用を開始するには、 AWS Inspector ドキュメント をご覧ください。料金の詳細と提供されているリージョンについては、 AWS Inspector の料金表ページ を参照してください。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、テクニカルガイダンスでの惜しみない援助と、専門知識を提供してくれた Nirali Desai に感謝の意を述べたいと思います。この包括的な概要をまとめることができたのは彼女のおかげです。 –  Eli 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

みなさん、こんにちは。ソリューションアーキテクトの深見です。OpenSearch Magazine の第 2 号をお届けいたします。本号では Amazon OpenSearch Service の最近のアップデート情報と、先日リリースされました OpenSearch 3.0 をはじめ OSS の OpenSearch Project にまつわるアップデートからピックアップしてご紹介します。また Hot Topic として OpenSearch のクエリを最適化する手助けになる機能の１つである Query Insights についてご紹介します。 OpenSearch Magazine は、 Amazon OpenSearch Service およびオープンソース版 OpenSearch の最新動向をキャッチアップいただくべく開設されました。開設の経緯や Amazon OpenSearch Service の概要につきましては、「 OpenSearch Magazine 開設のお知らせ 」よりご確認いただけます。 マネージドサービスのアップデート 直近でリリースされた、 Amazon OpenSearch Service に関する注目のアップデートについてご紹介していきます。 Amazon OpenSearch Service が OpenSearch バージョン 2.19 のサポートを開始 2025 年 4 月 30 日に Amazon OpenSearch Service で OpenSearch 2.19 を利用できるようになりました。OpenSearch 2.19 でのアップデートの中から ２ つピックアップしてご紹介します。 まずは、ハイブリッド検索において RRF（Relative Range Factor) が利用可能になりました。RRF は複数の検索システムの結果を順位の逆数をもとに並び替えるアルゴリズムです。 具体的な数式は、システム $r$ における文書 $d$ の順位 $r(d)$ とハイパーパラメーターである $k$ を用いて次のように計算されます。 この数式の意味を見ていきましょう。 まず、合成したいクエリ（ハイブリッド検索の場合、全文検索とベクトル検索）ごとに検索を実施します。 合成したい複数のクエリごとのランキング結果がでると、ドキュメントごとの順位の逆数をスコアとします。 クエリごとのスコアをそれぞれのドキュメントについて足し合わせることで最終的なスコアとする、と言った流れになります。 ハイブリッド検索を用いる際にベクトル検索のスコアと全文検索のスコアではスケールが異なることから単純にそのスコアをもとに並び替えをしてしまうと検索結果にバイアスが加わってしまいます。しかし、全文検索のスコアは相対的な値でありクエリやドキュメントの母集団によって異なったスケールをもつ値になるためベクトル検索のスコアと組み合わせるには複雑な計算が必要になってしまいます。そこで、RRF ではそれぞれの検索結果の順位を利用することでバイアスを軽減しながら検索結果の統合とリランクが可能になります。 ハイブリッド検索を利用する際には多くの場面で利用されているアルゴリズムのため、待望のアップデートでありました。OpenSearch で利用する場合は search pipeline 上の reranker として設定することで利用できます。 PUT /_search/pipeline/rrf-pipeline { "description": "Post processor for hybrid RRF search", "phase_results_processors": [ { "score-ranker-processor": { "combination": { "technique": "rrf", "rank_constant": 40 } } } ] } こちらのブログ でも詳しく紹介されていますので、合わせてご確認ください。 次に紹介するのは、 ML inference search です。ML inference search を利用することで、検索を行うロジックの前後で ML モデルを呼び出すことでクエリのリクエストやレスポンスの内容を書き換えたりエンリッチしたりすることができる機能になります。非常に柔軟な検索クエリを別のコンポーネントを用意することなく実現できます。例えば、クエリ対象の文字列を Embedding モデルに渡してベクトルに変換したり、LLM にわたすことでクエリ文字列とは違う表現の文章でエンリッチした上で検索を実施するといったことが可能になります。 レスポンスプロセッサー は 2.18 で、 リクエストプロセッサー が 2.19 で利用可能になっています。 その他にも、後述のHot Topicで紹介する Query Insights dashboard など多くのアップデートがありました。詳細は、 リリースブログ や リリースノート をご覧ください。 Amazon OpenSearch Ingestion のガイド付きビジュアルパイプラインビルダーの導入 2025 年 4 月 22 日のアップデートにより、 Amazon OpenSearch Ingestion で UI 上からパイプラインの構築が可能になるビジュアルパイプラインビルダーが利用可能になりました。これまでは、OpenSearch Ingestion のパイプラインを作成する際にはブループリントをベースにリソース ARN などの各種パラメータをユーザーが手書きする必要がありました。このアップデートにより、UI 上に表示される候補からリソースを選択することで自動でブループリントに入力がされるようになり、簡単にパイプラインを構築できるようになりました。 詳細は、こちらの ブログ をご確認ください。 OpenSearch Project の最新動向 OpenSearch Project では、2025 年 5月 6 日に OpenSearch 3.0 がリリースされました！OpenSearch 3.0 では多数のアップデートや新機能が追加されていますが、ベースとなる検索クエリのパフォーマンス向上に注目いただきたいです。詳細はぜひこちらの ブログ をご確認いただきたいところですが、 OpenSearch Big5 ワークロード において 以前までの最新バージョンである 2.19 と比べて 約 24% 高速 であるという結果になっています。これは、OpenSearch のベースの検索ライブラリである Apache Lucene や Java ランタイムのバージョンアップや OpenSearch 内部のロジックの最適化が要因となっています。 他にも、生成AI 界隈で注目のまとである MCP が OpenSearch にも登場しました。OpenSearch の MCP 関連機能では、OpenSearch への検索をエージェントに行わせるために利用できる MCP 組み込みサーバーの機能とOpenSearch の中のエージェントから外部の MCP サーバーを利用するための MCP クライアントの両面の機能が登場しています。詳細は、 OpenSearch における MCP の紹介ブログ をご覧ください。 3.0 に関するアップデートの詳細は、 リリースノート や リリースブログ をご確認ください。OpenSearch 3.0 は2025 年 5月時点でまだマネージドサービスの OpenSearch Service では利用できませんが、今後のアップデートが楽しみですね！ Hot Topic : Query Insights を使ったクエリ最適化 今号のHot Topic として Query Insights と その機能を OpenSearch Dashboard の UI で利用できる Query Insights dashboard についてご紹介します。 OpenSearch を利用して検索のやログ監視といったワークロードを運用していると、クエリが遅く感じ改善しようとされることは少ないありません。もしくは、一定の期間についてリソース使用量がスパイクしているような場合、その原因を探索することが求められる場合もあります。そういった際に、どのようなメトリクスを見て改善方法や問題の原因を検討するのが良いでしょうか？そう言った際に利用できる機能の１つが Query Insights になります。 Query Insights を利用することで、クエリの実行時間、CPU使用率、メモリ使用量などの主要なメトリクスを基準に設定した上位 N 件のクエリを履歴として保持することができます。また、クエリでつかわれている API やその構造をもとに類似しているクエリをグルーピングしたうえで、その中の上位 N 件のクエリグループを表示することもできます。 レイテンシーやリソース使用量について影響の大きなクエリを見つけることで、クエリ自体の改善やパターンに基づく予防策の検討に役立てることができます。 このように重要なメトリクスを追跡できる Query Insights ですが、2.19 より OpenSearch Dashboard の UI 上から 確認することができるようになりました。 UI 上ではクエリの履歴とそれに紐づく各メトリクスを確認することができます。この画面ではレイテンシーを基準に上位 N 件のクエリを探索するといったように、それぞれの項目をもとに履歴を並べかえることが可能です。また、期間やコーディネータノード ID でのフィルタや検索も可能です。 クエリの詳細ページでは、実際にどのようなクエリが実行されたのかや、実行タイムスタンプ、CPUとメモリの使用量、フェーズレベルのレイテンシー、インデックス、ノード、シャードなどのメタデータが確認可能です。 設定画面からは、メトリクスごとに上位何件を追跡するのか、グルーピング、履歴の保持期間や保存先の index の設定が可能です。 このように管理者がクエリパフォーマンスを監視する場合でも、開発者が特定のクエリの問題を調査する場合でもダッシュボード上から簡単にクエリの履歴の探索が可能になります。クエリのパフォーマンスに関してお悩みの場合はぜひ Query Insights dashboard をのぞいてみてください。 セットアップ手順と使用方法については、 Query Insights dashboards を参照してください。 まとめ 本号では、Amazon OpenSearch Service の最新アップデートとして、バージョン 2.19 に関連して RRF 対応と ML Inference の機能、OpenSearch Ingestion の ビジュアルパイプラインビルダーをご紹介しました。また OpenSearch Project のアップデートから、3.0 のアップデートの中からパフォーマンスの向上についてと MCP の機能をピックアップしてご紹介しました。そして、OpenSearch のクエリパフォーマンスを改善するのに有効な Query Insights という機能について解説しました。 今号の内容は以上になります。また次回をお楽しみに！ OpenSearch Project のロードマップは、 OpenSearch Project サイト および Github 上で公開されています。OpenSearch のロードマップについてご興味がございましたら、是非これらの情報をご確認ください。 https://opensearch.org/blog/opensearch-project-roadmap-2024-2025/ https://github.com/orgs/opensearch-project/projects/206 著者について ソリューションアーキテクト 深見 修平 (Shuhei Fukami) 2021 年に AWS Japan に Solutions Architect として入社しました。現在は Analytics SAとして Amazon OpenSearch Service をはじめ、AWS Glue、Amazon SageMaker LakeHouse などの Analytics Service にまつわるお客様のデータ分析やビッグデータ処理にまつわるシステムの導入および活用を支援しています。

本記事は、2024 年 12 月 4 日に公開された Build generative AI applications quickly with Amazon Bedrock in SageMaker Unified Studio を翻訳したものです。翻訳は Solutions Architect の 濱野谷(yoshiehm@) が担当しました。 生成 AI アプリケーションの構築は、組織にとって大きな課題となっています。専門的な ML の知識、複雑なインフラストラクチャ管理、そして複数のサービスの適切な連携が必要だからです。これらの課題に対応するため、生成 AI アプリケーションの開発とカスタマイズのための統合環境である Amazon Bedrock in SageMaker Unified Studio を紹介します。以前は Amazon Bedrock Studio として知られていた Amazon Bedrock in SageMaker Unified Studio は、 Amazon SageMaker Unified Studio に統合されました。Amazon SageMaker Unified Studio は、 Amazon Bedrock 、 Amazon SageMaker 、 Amazon Redshift 、 Amazon Glue 、 Amazon Athena 、 Amazon Managed Workflows for Apache Airflow (MWAA) などの AWS サービスを、包括的なデータ・ AI 開発プラットフォームに統合しています。このブログ記事では、Amazon SageMaker Unified Studio 環境における Amazon Bedrock in SageMaker Unified Studio とその生成 AI 機能に焦点を当てます。 複数のリージョンや国にまたがってグローバルに展開する小売サイトを考えてみましょう。セールスアナリストたちは日々、次のような課題に直面しています。データドリブンな意思決定を行う必要がありますが、膨大な情報量に圧倒されています。データベースに保存された販売取引や収益指標などの構造化データと、様々なチャネルから収集された顧客レビューやマーケティングレポートなどの非構造化データがあります。これらのアナリストは、SQL (構造化クエリ言語) の専門知識や RAG (Retrieval Augmented Generation) の専門知識がないため、両方のソースからのインサイトを効果的に組み合わせることに苦労しています。 この記事では、社内の誰もが Amazon Bedrock in SageMaker Unified Studio を使用して、販売実績データを分析する生成 AI チャットエージェントアプリケーションを素早く作成する方法をご紹介します。ビジネスチームは、このチャットエージェントとの簡単な会話を通じて、コードを書いたり複雑なデータパイプラインを管理したりすることなく、構造化データと非構造化データの両方から価値のあるインサイトを引き出すことができます。次の図は、 Amazon Bedrock in SageMaker Unified Studio を使用した AI アシスタントの概念アーキテクチャを示しています。 ソリューションの概要 Amazon Bedrock in SageMaker Unified Studio に作成した AI チャットエージェントアプリケーションは、構造化データと非構造化データの両方の分析結果を組み合わせることができます。 構造化データの場合 : Amazon Athena の販売記録に接続し、自然言語を SQL クエリに変換します 非構造化データの場合 : Amazon Titan Text Embeddings と Amazon OpenSearch を使用して、カスタマーレビューやマーケティングレポートに対してセマンティック検索を実現します Amazon Bedrock in SageMaker Unified Studio のインターフェースは、両方のソースからの結果をシームレスに組み合わせ、基盤となるデータ構造やクエリ言語をユーザーが理解する必要なく、包括的なインサイトを提供します。次の図は、ユーザーの初期操作から最終的なレスポンスまでのワークフローを示しています。ユーザーインタラクションフローの詳細については、関連する GitHub リポジトリ をご確認ください。 ソリューションアーキテクチャ 前図のアーキテクチャは、 Amazon Bedrock in SageMaker Unified Studio がどのようにデータフローを調整するかを示しています。ユーザーが自然言語インターフェースを通じて質問を投げかけると、チャットエージェントは、Amazon SageMaker Unified Studio の Amazon Bedrock 機能を通じて Amazon Athena の構造化データをクエリするか、Amazon Bedrock のナレッジベースを検索するか、または包括的なインサイトを得るために両方のソースを組み合わせるかを判断します。このアプローチにより、営業、マーケティング、製品、サプライチェーンのチームは、技術的な専門知識に関係なく、効率的にデータ駆動型の意思決定を行うことができます。たとえば、このチュートリアルを終えると、「今四半期のトップ 5 の売れ筋商品と、それぞれの主要な顧客の苦情を教えてください」や「衣料品の北米市場に影響を与えたサプライチェーンの問題はありましたか？」といったプロンプトでデータをクエリできるようになります。 以下のセクションでは、Amazon SageMaker Unified Studio プロジェクトのセットアップ、ナレッジベースの作成、自然言語クエリインターフェースの構築、およびソリューションのテストについて説明します。 Amazon SageMaker Unified Studio のセットアップ Amazon SageMaker Unified Studio は、すべてのデータとツールを使用できる分析と AI のためのブラウザベースのウェブアプリケーションです。Amazon SageMaker Unified Studio では、 AWS Identity and Access Management (IAM) の認証情報、 AWS IAM アイデンティティセンター を通じた IdP の認証情報、または SAML 認証情報を利用できます。 Amazon DataZone の AWS Management Console にアクセスすることで、ドメインの Amazon SageMaker Unified Studio の URL を取得できます。Amazon SageMaker Unified Studio をセットアップするには、 管理者ガイド の手順に従ってください。 生成 AI アプリケーションの構築 Amazon SageMaker Unified Studio は、生成 AI を探索し構築するためのツールを提供します。まずはプロジェクトを作成する必要があります。 Amazon SageMaker Unified Studio を開き、ページ上部の Generative AI playground を選択します。 ここでは、 chat インターフェースを通じて、さまざまな基盤モデル (FM) を探索、試行、比較することができます。 同様に、 Image & video playground で画像と動画のモデルを試すことができます。 チャットエージェントの作成を開始するには、チャットプレイグラウンドウィンドウで Build chat agent を選択します。アプリを構築する前に、新しいプロジェクトを作成します。 Create project を選択してください。 プロジェクト名を入力します。次に、利用可能なプロファイルから Generative AI application development を選択します。このプロファイルには、生成 AI アプリケーション開発で Amazon Bedrock コンポーネントを使用するために必要なすべての要素が含まれています。 Continue を選択します。 次の画面では、すべての設定をデフォルト値のままにしておきます。 Continue を選択して次の画面に進み、 Create Project ボタンを選択してプロジェクトの作成プロセスを開始します。プロジェクトのセットアップが完了するまで数分かかります。 プロジェクトを作成したら、生成 AI アプリケーションの構築を開始します。 前提条件 Amazon SageMaker Unified Studio で Amazon Bedrock のアプリケーションを作成する前に、AWS アカウントでいくつかのリソースをセットアップする必要があります。これにより、セールス分析アプリケーションが依存するバックエンドインフラストラクチャとサービスがプロビジョニングされます。これには、構造化された売上データのクエリを可能にするために、 Amazon API Gateway 、 AWS Lambda 関数 、Amazon Athena のセットアップが含まれます。 必要な AWS リソースをデプロイします： 任意の AWS リージョンで AWS CloudFormation スタックを起動します： スタックのデプロイ後、CloudFormation の出力タブから API Gateway URL の値 TextToSqlEngineAPIGatewayURL をメモしてください。 AWS Secrets Manager コンソールに移動し、シークレット <StackName>-api-keys を見つけます。 シークレットを取得 を選択し、以下のプレーンテキスト文字列から apiKey の値をコピーしてください。 {"clientId":"default","allowedOperations":["query"],"apiKey":"xxxxxxxx"} 後で Amazon Bedrock in SageMaker Unified Studio を設定する際に、これらの値が必要になります。 3 つのサンプルデータファイルをダウンロードします。これらのファイルには、生成 AI モデルによって生成された合成データが含まれており、ナレッジベースの構築に使用する顧客レビュー、顧客アンケートの回答、世界のニュースが含まれています： product-reviews.txt – ユーザーからの製品ごとのレビュー survey-response.txt – アンケートを通じて収集したユーザーフィードバック world-news.txt – 最近の業界および経済ニュース API 設定をダウンロードします： openapi_schema.json 。このファイルは、売上データを照会する関数のセットアップ時に使用します。 以上です！これらのリソースが準備できたら、セールス分析アプリケーションを作成できます。以降のセクションでは、これらのファイルをいつ、どのように使用するかを詳しく説明します。 チャットエージェントの指示設定 Amazon Bedrock in SageMaker Unified Studio のチャットエージェントアプリケーション に移動します。ドロップダウンからモデルを選択します (これは後で変更可能です – データと機能をサポートしていることを確認してください)。チャットエージェントの指示フィールドに以下を入力します： You are a Sales Analytics agent with access to sales data in the "sales" database, table "sales_records". Your tasks include analyzing metrics, providing sales insights, and answering data questions. Table Schema: - region, country: Location data - item_type: Product category - sales_channel: Online/Offline - order_priority: H/M/L/C - order_date, ship_date: Timing - order_id: Unique identifier - units_sold: Quantity - unit_price, unit_cost: Price metrics - total_revenue, total_cost, total_profit: Financial metrics. Use Amazon Athena SQL queries to provide insights. Format responses with: 1 SQL query used 2 Business interpretation 3 Key insights/recommendations You can also access sales-repo which contains details on products categories, customer reviews, etc. Error Handling: - If the user's query cannot be translated into a valid SQL query, or the SQL is invalid or fails to execute, provide a clear and informative error message. この指示により、AI アプリケーションは販売分析エージェントとして機能し、与えられた販売データスキーマに基づいて、製品レビューやその他の販売関連データにアクセスしながら、構造化された応答を提供します。 このアプリケーションでは、非構造化データを処理するためのナレッジベースと、構造化データを照会するために Amazon Athena を使用する関数という 2 つの主要なコンポーネントを作成します。これらのコンポーネントは連携して、生成 AI アプリケーションの情報処理と取得を行います。 ナレッジベースの作成 ナレッジベースを使用すると、アプリケーションでカスタマーレビューやニュース記事などの非構造化データを分析できます。 現在のチャットエージェント画面で Data セクションを選択します。 Create new Knowledge Base を選択し、新しいナレッジベースの名前を入力します。また、チャットエージェントがこのナレッジベースの目的を理解できるように、簡単な説明を入力する必要があります。 This contains product-specific reviews from users, user feedback gathered via survey, and recent industry and economic news ナレッジベースのデータソースを設定するには、ローカルファイルを使用するか、Web クローラーを設定するという 2 つのオプションがあります。Web スクレイピングは、アクセス権のある公開 Web ページからコンテンツを自動的に抽出します。ツールに Web サイトの URL を追加すると、これらのサイトをクロールし、定義されたすべての URL からナレッジベースを作成します。このプロセスにより、複数の Web ソースから効率的に情報を収集して構造化し、必要に応じた包括的なデータセットを構築できます。 この記事では、前述の非構造化データを含むファイル ( product-reviews.txt 、 survey-response.txt 、 world-news.txt ) をアップロードします。 Click to upload を選択し、3 つのファイルをアップロードします。パース設定はデフォルトのままにしてください。 埋め込みモデルとして、 Amazon Titan Text Embeddings V2 または他の埋め込みモデルを選択します。 ベクトルストアとして OpenSearch Serverless を選択します。 これらの選択を行った後、 Create を選択してナレッジベースを作成します。 ナレッジベースの作成が完了したら、 Select Knowledge Base ドロップダウンからアプリケーション用のナレッジベースを選択します。 この非構造化データは、生成 AI アプリケーションのナレッジベースを強化するために使用され、カスタマーレビュー、アンケート回答、ビジネス分野に関連する最新ニュースに基づいて、情報を処理しインサイトを提供できるようになります。 非構造化データの接続が正しく機能していることを確認するために、このサンプルプロンプトをアプリケーションに送信してください。生成 AI システムは非決定論的であるため、応答は毎回同じにはならないことに注意してください。 プロンプト: What is the customer sentiment surrounding our Office Supplies products? 期待されるレスポンス: Based on the customer reviews and feedback, the sentiment surrounding our Office Supplies products is mixed. While there are many positive reviews praising the product selection, store environment, and helpful staff, there are also a significant number of negative reviews citing issues like: Poor product quality (e.g. flimsy materials, inconsistent paper quality, adhesive issues) Frustrating in-store experiences (e.g. long wait times, rude staff, messy/disorganized stores) Problems with online ordering and apps (e.g. filters not working properly, payment issues, logging out repeatedly) To improve customer sentiment, we should focus on addressing these common pain points through better quality control, more efficient inventory management and staffing, and improving the online/app user experience. 関数の作成 このセクションでは、Amazon API Gateway と連携してデータベースにクエリを実行する関数を作成します。このクエリは Lambda 関数に転送され、Lambda 関数では Amazon Athena を使用して SQL クエリを処理し、 Amazon Simple Storage Service (Amazon S3) からデータを取得します。これらの AWS インフラストラクチャは、CloudFormation テンプレートの一部としてすでにデプロイされています。構造化データセットには、2010 年から 2017 年までの製品の注文情報が含まれています。この過去のデータにより、関数は 7 年間にわたる売上傾向、製品パフォーマンス、その他の関連指標を分析することができます。このアプリケーションは、この関数を使用して構造化データ分析機能を統合し、すでに組み込まれているレビューやニュースからの非構造化データと共に、具体的な売上データに基づくインサイトを提供できるようにします。 Amazon Bedrock in SageMaker Unified Studio のチャットエージェントアプリケーションで、画面上の Functions セクションを展開します。 Create New Function を選択します。 関数の名前を入力し、説明を記入します。 関数スキーマについては、 Import JSON/YAML を選択します。先ほどダウンロードした openapi_schema.json ファイルから API スキーマをインポートします。 重要：インポート後、スキーマ内の API エンドポイント URL を変更する必要があります。CloudFormation スタックの出力 TextToSqlEngineAPIGatewayURL から取得した実際の値に置き換えてください。このステップにより、関数がアプリケーションの適切な API エンドポイントに正しくリンクされます。 Authentication method で、 API Keys (Max. 2 Keys) を選択し、以下の詳細を入力します： Key sent in: Header Key name: x-api-key Key value: Amazon Secrets Manager の apiKey の値を入力します。 Create を選択し、関数の作成が完了するまで待ちます。 関数の作成が完了したら、 Functions ドロップダウンからアプリケーション用の関数を選択します。 構造化データへの接続が正常に機能していることを確認するために、以下のサンプルクエリをアプリケーションに送信してください。生成 AI システムは非決定論的であるため、応答は毎回同じにはならないことに注意してください。 プロンプト: List all the regions that we do business in. 期待されるレスポンス: Based on the query to get distinct region values from the sales_records table, the regions where we do business are: Europe Australia and Oceania North America Central America and the Caribbean Sub-Saharan Africa Middle East and North Africa Asia アプリケーションの共有 アプリケーションを構築した後、Amazon SageMaker Unified Studio を通じて組織内の他のユーザーと共有することができます。 アプリケーションインターフェイスの右上隅にある Share を探して選択します。 共有ダイアログで、エイリアスでユーザーを検索し、 Invite を選択して共有リストに追加します。 必要なユーザーをすべて追加したら、共有ダイアログからアプリケーションの URL をコピーし、任意の通信手段を使用して追加したユーザーに URL を送信します。 注意 : リンク共有をオンにすると、リンクを持っている人は誰でもアプリを購読して使用できるようになります。特定のユーザー名を追加した場合、それらのユーザーのみがアプリを閲覧でき、「共有された生成 AI アセット」セクションに表示されます。 共有アプリケーションを使用するには、有効な Amazon SageMaker Unified Studio のアクセス認証情報が必要です。アクセスに問題が発生した場合は、AWS 管理者に連絡してください。 使用例 以下の例では、グローバルな小売サイトがこのソリューションを使用して、販売分析プロセスを変革し、価値のあるインサイトを抽出する方法を示します。このアプローチの効果を示す 3 種類のクエリを見ていきましょう： 売上実績を理解するための構造化データの分析 インサイトを抽出するための非構造化カスタマーフィードバックの分析 包括的なビジネスインテリジェンスのための両データソースの組み合わせ 以下の例では、セールスアナリストが基本的な会話形式のクエリを通じて、価値のあるインサイトを抽出する方法を紹介します。 生成 AI システムは非決定論的であるため、応答は毎回同じにはならないことに注意してください。生成 AI システムは誤った情報を生成する可能性もあるため、応答の正確性を評価する際は注意が必要です。また、構造化データソースはダウンロード時にランダムに生成されるため、結果が必ずしも一致するとは限りません。Amazon S3 の CSV データソースにアクセスして、結果を手動で評価することができます。この例では Anthropic Claude 3 Sonnet モデルを使用しましたが、他のモデルも試してみることをお勧めします。 構造化データの例 クエリ可能な特徴量カラムは以下の通りです: Region (地域)、Country (国)、Item Type (商品タイプ)、Sales Channel (販売チャネル)、Order Priority (注文優先度)、Order Date (注文日)、Order ID (注文 ID)、Ship Date (出荷日)、Units Sold (販売数)、Unit Price (単価)、Unit Cost (単位コスト)、Total Revenue (総収益)、Total Cost (総コスト)、Total Profit (総利益)。このデータは 7 つの地域と 100 以上の国をカバーしており、以下の商品タイプが含まれています: ベビーフード、飲料、シリアル、衣類、化粧品、果物、家庭用品、肉類、オフィス用品、パーソナルケア用品、スナック、野菜。 プロンプト 1: What region accounts for our highest revenue, and how much revenue is that? 予想される応答 1: The region that accounts for our highest revenue is "Sub-Saharan Africa" with a total revenue of $356,724,250.12. プロンプト 2: Which 3 item types account for our most units sold? 予想される応答 2: The 3 item types that account for our most units sold are: Beverages with 504,905 units Personal Care with 475,724 units Vegetables with 471,276 units 非構造化データの例 以下の例では、非構造化データを照会するために使用できる自然言語プロンプトをいくつか紹介します。これらのクエリの目的は、テキストデータを照会して質問に回答し、共通のテーマを特定することです。 クエリ可能なデータには、ユーザーからの製品固有のレビュー、アンケートを通じて収集したオンラインとオフラインのフィードバック、最近の業界や経済ニュースが含まれます。 プロンプト 1: Search our customer surveys to see if customers seem to prefer our online or offline shopping experience 予想される応答 1: Based on the customer survey results from the knowledge base, there seems to be a preference for the in-store/offline shopping experience over the online experience (website and mobile app). The in-store reviews frequently mention positive aspects like helpful staff, clean stores, good product selection and organization. In contrast, the online reviews cite many issues with the website and mobile app like slow loading times, crashes, poor search functionality, and difficulties during checkout. While there are some positive online reviews as well, the negative experiences seem more prevalent for the online channels compared to the offline in-store experience. プロンプト 2: Were there any major world events in 2016 affecting the sale of Vegetables? 予想される応答 2: Based on the search results from the knowledge base, there were a few major events in 2016 that may have impacted vegetable sales: In July 2016, an extended drought in California's Central Valley resulted in reduced vegetable production, affecting supply chains for major retailers across North America. In April 2016, Morocco's innovative desert greenhouse project began operations, introducing new competition in the Mediterranean vegetable market and affecting prices in Southern Europe. In June 2016, India's successful implementation of cold chain infrastructure reduced vegetable spoilage by 35%, stabilizing prices across South Asian markets. So the drought in California likely reduced vegetable supply and increased prices in North America, while the new greenhouse operations in Morocco introduced more competition in Europe. However, improved cold chain logistics in India helped stabilize vegetable prices in that region. データ結合の例 以下は、構造化データと非構造化データの両方のソースに対してクエリを実行し、その結果をシームレスにビジネスインサイトとして組み合わせることができる、自然言語プロンプトの例です。 プロンプト 1: Do customers seem to prefer our online or offline shopping experience? Gather data from both customer surveys and number of units sold on different sales channels (online and offline), and try to identify a trend to see if the data corroborates these reviews. 予想される応答 1: Based on the customer reviews from the knowledge base, there seems to be a preference for the in-store/offline shopping experience over online shopping. Common complaints for online included slow websites, technical glitches, poor search functionality, and issues during checkout. In contrast, the in-store experience received more positive reviews praising helpful staff, clean stores, and good product selection. The overall sales data shows that the Offline sales channel had higher total revenue ($698.9M) and units sold (2.69M) compared to Online ($628.4M revenue, 2.36M units). This data corroborates the customer review sentiments, indicating customers may prefer the offline/in-store experience for our products and services. However, it is important to note that both channels received a mix of positive and negative reviews. To improve the overall customer experience, we should analyze the specific issues raised in the reviews and look for ways to enhance both the online and offline channels based on that feedback. プロンプト 2: Can you identify any major events that may have affected the sales revenue of Baby Food? What about any product reviews that may reflect the trends in revenue? Use order dates and news article publishing dates as you look for trends. 予想される応答 2: Based on analyzing the sales revenue data for the Baby Food item type and searching relevant unstructured data sources, here are some major events that appear to have impacted sales revenue: In November 2015, Japan introduced stricter quality control standards for imported baby foods (source 5). This appears to have disrupted supply chains in Asia and may have driven the spike in revenue that month as companies rushed to get products into Japan before the new standards took effect. In August 2016, Mexico reported a breakthrough in avocado cultivation that increased yields by 25% (source 3). This improved supply of a key baby food ingredient and may have contributed to the high revenue in late 2016 by lowering costs for manufacturers. In April 2014, Australia had a wheat shortage due to drought conditions, impacting costs for grain-based baby food products (source 2). This aligns with the low revenue on 4/26/2014 as manufacturers likely passed along higher costs to consumers. The unstructured data sources provided helpful context around supply chain disruptions, ingredient shortages and surpluses, major agricultural events, and changes in trade policies - all of which appear to have impacted baby food sales based on the timing of these events correlating with fluctuations in revenue in the structured data. クリーンアップ これらの手順でデプロイしたリソースをクリーンアップするには、まず CloudFormation スタックを 削除 します。その後、Amazon SageMaker Unified Studio プロジェクトから Amazon Bedrock のリソースを削除し、Amazon SageMaker Unified Studio の ドキュメント に従ってドメインを削除できます。 まとめ この記事では、Amazon Bedrock in SageMaker Unified Studio が、生成 AI アプリケーション開発を複雑な技術的な作業から、シンプルなポイント＆クリックの操作に変えることをご紹介しました。従来のアプローチでは、専門的な ML の知識と多大な開発時間が必要でしたが、Amazon Bedrock in SageMaker Unified Studio を使用することで、さまざまなスキルレベルのユーザーが、数週間ではなく数時間で本番環境対応の AI アプリケーションを作成できるようになります。 主なメリットとして、コーディングの専門知識がなくても、誰でも高度な生成 AI アプリケーションを構築できます。事前に構築されたコンポーネントにより、価値の実現までの時間を短縮でき、一元管理によってエンタープライズガバナンスを維持できます。さらに、統一された使いやすいインターフェースを通じて、組織のデータに安全にアクセスできます。この同じアプローチは、営業分析以外にも、チームが企業データと大規模言語モデルを組み合わせた AI アプリケーションを迅速に構築する必要があるシナリオにも適用できます。これにより、組織全体で生成 AI を真に利用可能にします。 組織の AI 機能を変革する準備はできましたか？ステップバイステップのガイドに従って最初の生成 AI アプリケーションの構築を始めるか、 Amazon Bedrock in SageMaker Unified Studio にアクセスしてビジネスニーズに合ったソリューションをさらに探索してください。 著者について Ameer Hakme は、ペンシルベニア州を拠点とする AWS ソリューションアーキテクトです。北東地域のインディペンデント・ソフトウェア・ベンダー (ISV) と協力し、AWS クラウド上でスケーラブルでモダンなプラットフォームの設計と構築を支援しています。AI/ML および生成 AI のエキスパートとして、お客様がこれらの最先端テクノロジーの可能性を引き出せるよう支援しています。余暇にはバイクに乗ったり、家族と質の高い時間を過ごすことを楽しんでいます。 Adam Gamba は、AWS のソリューションアーキテクトであり、アナリティクスおよび AI/ML スペシャリストを目指しています。コンピュータサイエンスのバックグラウンドを持ち、テクノロジーを活用して実世界の問題に対するソリューションを構築することに強い関心を持っています。ニュージャージー州出身で、現在はバージニア州アーリントンを拠点としており、ロッククライミング、ピアノ演奏、料理、地元の美術館やコンサートに行くことを楽しんでいます。 Bhaskar Ravat は、ニューヨークを拠点とする AWS のシニアソリューションアーキテクトで、AI の変革的な可能性に深い関心を持っています。AI が日常生活や人間の経験全般にどのような影響を与えるかを探求することに情熱を注いでいます。お客様のソリューション構築やサポートを行っていない時は、4 冊の本を同時に読んでいます。 Kosti Vasilakakis は AWS のプリンシパルプロダクトマネージャーです。元データサイエンティストからプロダクトマネージャーに転身し、現在は Amazon Bedrock in SageMaker Unified Studio のリーダーとして、企業が高品質な生成 AI アプリケーションをより迅速に構築できるよう支援しています。AI の急速な進歩に感銘を受け続けており、その民主化に携われることを楽しみにしています。仕事以外では、個人の生産性向上のための自動化コードを書いたり、テニスをプレイしたり、家族と自然の中で過ごしたりしています。

本ブログは 2025 年 2 月 14 日に公開された Blog “ Introducing the AWS Trust Center ” を翻訳したものです。 Amazon Web Services (AWS) において、信頼を獲得することは単なる目標ではなく、私たちのあらゆる意思決定を導く中核的なリーダーシップ原則の一つです。AWS の CISO として、この信頼獲得への取り組みが私たちの文化、サービス、そして日々のお客様とのやり取りをどのように形作っているかを直接目の当たりにしてきました。お客様が他のプロバイダーではなく AWS を選ぶ理由は、最も安全なインフラストラクチャとサービスを提供し、データ保護の方法を正確に伝えることを信頼しているからです。 その情報をさらに見つけやすくするため、AWS はクラウドでの資産保護へのアプローチを共有する新しいオンラインリソース「 AWS Trust Center 」を立ち上げました。AWS Trust Center は、私たちのセキュリティ対策、コンプライアンスプログラム、データ保護管理を紹介し、私たち AWS が日々お客様の信頼を獲得するためにどのように取り組んでいるかを示す透明性を持った情報源です。 信頼の基盤の上に構築 セキュリティは Day 1 (創業当初) から AWS の最優先事項です。2006 年に AWS を立ち上げた時、利用可能な最も安全なクラウドコンピューティング環境としてインフラストラクチャを設計しました。既存のオンプレミスインフラストラクチャと同レベルのセキュリティを提供するだけでは不十分だと認識していました。お客様の信頼を獲得するためには、世界で最もセキュリティを重視する組織の厳格な業界基準を上回る必要がありました。AWS は日々の意思決定においてセキュリティを常に強化し続けています。Trust Center により、AWS がお客様のワークロードを保護し、データを守り、コンプライアンス目標の達成をどのように支援しているかを理解しやすくなります。 Trust Center は、情報への容易なアクセスが信頼を構築・維持するという考えに基づいています。データセンターの管理に関する情報を探す場合でも、コンプライアンス認証を確認する場合でも、共有責任モデルを確認する場合でも、必要なセキュリティとコンプライアンスの情報を一箇所で見つけることができるようになりました。 セキュリティとコンプライアンスの単一情報源 Trust Center では、物理的なデータセンターからクラウドインフラストラクチャ、そしてクラウドサービスのポートフォリオに至るまで、あらゆるレベルでのセキュリティアプローチに関する情報を見つけることができます。セキュリティサービスとツールに関するドキュメントを含め、AWS がクラウドをどのように保護し、お客様がその中でワークロードをどのように保護できるかを理解するのに役立ちます。また、グローバルに維持している認証や証明を含むコンプライアンスプログラムに関する情報も見つけることができます。これは、監査人や規制当局にコンプライアンスを証明する必要がある規制産業で働くチームにとって価値があります。 Trust Center はデータ保護とプライバシー対策に関する情報を強調しています。お客様はデータの保護方法や暗号化の管理方法について学ぶことができます。さらに、お客様がデータにアクセスできる人とその状況について懸念していることを理解しています。最小権限の原則を核とする オペレーターアクセス制御 に関する詳細情報を統合しました。 AWS Key Management Service (AWS KMS) や Amazon Elastic Compute Cloud (Amazon EC2) などの主要サービスのゼロアクセス設計、お客様の承認を暗号的に強制する転送アクセスセッション (FAS) の使用、そしてグローバル監視システムについて学ぶことができます。 Trust Center は、サービスの健全性とセキュリティイベントに関する情報を見つけるための中心的な場所を提供し、運用の優秀性を維持するために必要な情報を得ることができます。セキュリティ速報を常に最新の状態に保ち、リアルタイムのサービス健全性状態を確認できます。セキュリティ上の懸念を報告したり、独自のセキュリティ評価を実施したりする必要がある場合、それらのプロセスを見つけやすくしました。リソースはアクセスしやすいように整理され、クラウドセキュリティポスチャについて情報に基づいた決定を下すために必要な契約、ドキュメント、リソースへの直接リンクが提供されています。 お客様のセキュアなイノベーション推進を支援 私が Trust Center で最も素晴らしい点は、お客様の障壁を取り除く方法です。詳細なセキュリティ情報、コンプライアンス文書へのより簡単なリンク、そして運用上の洞察が今や指先一つで得られるため、より迅速に行動し、自信を持ってイノベーションを起こすことができます。 AWS サービスの革新と拡大を続ける中で、最新のセキュリティ情報で Trust Center を強化することに取り組んでいます。これはクラウドとサービスとともに進化し、常に更新されるリソースです。お客様の信頼を維持することは、今日構築したものだけでなく、私たちのコミットメントと実績を通じて、信頼できるセキュリティパートナーとしての価値を証明することです。それが AWS のお客様へのコミットメントであり、AWS Trust Center が表すものです。 ぜひ本日から AWS Trust Center をご覧ください。AWS は日々お客様の信頼を獲得し続けるよう努めてまいります。 このポストに関する質問がある場合は、 AWS サポート にお問い合わせください。 Chris Betz Chris は AWS の CISO です。セキュリティチームを監督し、リスク管理とビジネス目標に沿ったセキュリティ態勢の整合を目的としたセキュリティポリシーの開発と実装を主導しています。Chris は 2023 年 8 月に Amazon に入社し、それ以前は主要企業で CISO およびセキュリティリーダーシップの役割を担っていました。バージニア州北部で家族と暮らしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 2025 年 6 月 5 日 14:30 – 19:00 に、目黒のオフィスでイベント AWS Marketplace Solution EXPO Spring 2025 を開催します。SaaS・ソフトウェア ソリューション ベンダー 兼 AWS Marketplace パートナー 11 社が集まるイベントとなっており、様々な最新のソリューションを情報収集したい方などにおすすめです。Okta Japan株式会社、クラウドストライク合同会社、Snowflake合同会社、Splunk Services Japan 合同会社、ゼットスケーラー株式会社、株式会社セールスフォース・ジャパン、Datadog Japan 合同会社、データブリックス・ジャパン株式会社、トレンドマイクロ株式会社、New Relic株式会社、パロアルトネットワークス株式会社 の 11 社 (50 音順) にご登壇いただくイベントです。是非ご登録の上ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025 年 5 月 19 日週の主要なアップデート 5/19(月) Amazon Inspector が ECR コンテナイメージの使用状況追跡機能を強化 Amazon ECR で管理しているコンテナイメージが Amazon ECS や Amazon EKS のどの環境で実行されているか追跡できるセキュリティ機能を、Amazon Inspector で提供を開始しました。アクティブに使用されているコンテナイメージ、イメージを最後に使用した時期、どのクラスターがイメージを実行しているかを特定できます。これにより、実行中のワークロードに関連する最も重要な脆弱なイメージを特定しやすくなり、セキュリティの対応と修復までの時間を短縮できます。 AWS CloudWatch Synthetics がカナリアの安全なアップデートと自動再試行を追加 お客様のウェブサイトをモニタリングできる CloudWatch Synthetics が、2 つの新機能「カナリアの安全なアップデート」と「カナリアの自動再試行」を提供開始しました。「カナリアの安全なアップデート」は、更新を適用する前にテストを実施できます。新しくリリースされたランタイムとカナリアの互換性、また、構成やコードの変更との互換性を確認でき、影響を抑えたカナリアの更新が可能です。「カナリアの自動再試行」は、誤警報を減らすのに役立ちます。持続的な問題と一時的な障害を区別することで、より信頼性の高いモニタリング結果を提供し、不必要な中断を防ぎます。 DynamoDB local が AWS CloudShell で利用可能 AWS CloudShell で DynamoDB local を利用できるようになりました。DynamoDB local を使用すると、ローカル開発環境で DynamoDB を利用した開発やテストを実行でき、料金発生を抑えられるメリットがあります。DynamoDB local は既存の DynamoDB API 呼び出しを利用でき、既存のソースコードの影響を最小限に抑えられます。CloudShell で dynamodb-local エイリアスコマンドを実行すると DynamoDB local を起動できます。プログラムコードで DynamoDB Local に接続するために、「Endpoint_url=’http://localhost:8000’」といった形でエンドポイントを指定します。 5/20(火) Amazon RDS for Oracle で Oracle マルチテナントアーキテクチャを使用するデータベース向けに AWS Secrets Manager による認証情報管理をサポート Amazon RDS for Oracle で、複数のプラガブルデータベース (PDB) を稼働する Oracle マルチテナントアーキテクチャを使用する際に、 AWS Secrets Manager による認証情報管理ができるようになりました。定期的なパスワードローテーションを自動化し、IAM を使用して権限のあるユーザーへのアクセス制御を行い、アプリケーションコード内の平文パスワードの使用を AWS Secrets Manager から認証情報を取得するプログラム呼び出しに置き換えることによるセキュリティ向上、といったメリットがあります。 Amazon CloudWatch Application Signals が EKS ワークロードの自動監視サポートを導入 CloudWatch Application Signals で、EKS ワークロードの自動監視機能をサポートしました。Amazon CloudWatch EKS アドオンをインストールして設定することで、CloudWatch 上の APM を EKS にセットアップできるようになりました。CloudWatch Application Signals 内の事前構築された標準ダッシュボードで EKS アプリケーションのパフォーマンスに関する指標を確認できるようになります。 Amazon EC2 High Memory インスタンスが米国東部 (オハイオ) リージョンで利用可能 18 TB のメモリを搭載した Amazon EC2 High Memory U-1 インスタンス (u-18tb1.112xlarge) が米国東部 (オハイオ) リージョンで利用可能になりました。Amazon EC2 High Memory インスタンスは、本番環境での Business Suite on HANA、SAP S/4HANA、Data Mart Solutions on HANA、Business Warehouse on HANA、および SAP BW/4HANA の実行について SAP による認定を受けています。詳細は こちらのブログ をご確認ください。 5/21(水) AWS Transfer Family が SFTP 向けの ML-KEM 量子耐性鍵交換を提供開始 AWS Transfer Family で SFTP を利用する際に、米国国立標準技術研究所 (NIST) によって標準化された量子後暗号アルゴリズムである ML-KEM (FIPS-203) をサポートしました。「今収集し、後で復号する」脅威に対して長期的な機密性を必要とするデータファイルの転送を保護します。この発表により、古典的な楕円曲線ディフィー・ヘルマンと量子耐性 ML-KEM 鍵交換を組み合わせた量子後 (PQ) ハイブリッドセキュリティポリシーを、AWS Transfer Family SFTP エンドポイントと OpenSSH、Putty、JSch などの PQ アルゴリズムをサポートするクライアント間で使用できるようになりました。 Amazon EKS ダッシュボードの複数リージョン、Organizations 全体のサポート EKS のダッシュボードが、複数の AWS リージョンとアカウントにわたる Kubernetes インフラストラクチャの一元的な可視性を提供する新機能の一般提供を開始しました。AWS リージョンやアカウントを切り替えることなく、Kubernetes インフラストラクチャ全体を可視化できるようになり、クラスター、マネージドノードグループ、EKS アドオンに関する集約された洞察を得ることができます。これには、特定の Kubernetes バージョンを実行しているクラスター、サポートステータス、今後のサポート終了自動アップグレード、マネージドノードグループの AMI バージョン、EKS アドオンバージョンなどが含まれます。 AWS Cost Anomaly Detection が AWS User Notifications を通じて高度なアラート機能を実現 AWS Cost Anomaly Detection が AWS User Notifications (Amazon EventBridge 経由) と統合して、高度なアラート機能を作成できるようになりました。お客様はサービス、アカウント、またはその他のコスト要素に基づいた高度なアラートルールを設定し、予期しない支出の変化をより迅速に特定して対応することができます。メール、AWS Chatbot、AWS Console Mobile Application などから通知先を設定できます。 5/22(木) Anthropic の Claude 4 基盤モデルが Amazon Bedrock で利用可能 Anthropic の Claude モデルの次世代版である Claude Opus 4 と Claude Sonnet 4 が Amazon Bedrock で利用可能になりました。これらのモデルはコーディングに優れ、AI エージェントが何千もの情報源を分析し、長時間実行タスクを実行し、高品質のコンテンツを作成し、複雑なアクションを実行することを可能にします。この 2 つのモデルは、ほぼ即時の応答を行うモードと、より深い推論のための extended thinking モードを利用できます。料金については、これまで提供しているモデルと同様です。Claude 3.7 Sonnet と Claude Sonnet 4 が同一、同様に Claude 3 Opus と Claude Opus 4 が同一となっています。また、新しい Claude 4 モデルの名前は、数字が末尾につくように変更されています。間違えがちなので留意しましょう。詳細は こちらのブログをご参照 ください。 Amazon Managed Service for Prometheus がクエリインサイトとコントロール機能を開始 Amazon Managed Service for Prometheus は、高コストな PromQL クエリを特定し、その実行を制限する機能を提供するようになりました。Amazon Managed Service for Prometheus ワークスペースに対して発行されるクエリの種類を監視および制御できるようになります。Amazon Managed Service for Prometheus は、クエリを実行したときに処理されるサンプル (データ) の数によって料金が上下する従量課金が含まれています。多くのデータを取得するクエリを特定することで、改善のアクションをしやすくなりました。 AWS が EC2 パブリック DNS 名の IPv6 サポートを発表 EC2 パブリック DNS 名で、 IPv6 グローバルユニキャストアドレス (AAAA レコード) を解決できるようになりました。これまでは、EC2 パブリック DNS 名は IPv4 アドレス (A レコード) に解決されていました。そのため、IPv6 を採用するお客様は、IPv6 のみの Amazon EC2 インスタンスにアクセスするために DNS 名の代わりに特定の IPv6 アドレスを使用するか、Amazon Route 53 を使用してホストゾーンを作成してカスタムドメインを使用していました。EC2 パブリック DNS 名の IPv6 サポートにより、お客様は IPv6 のみの Amazon EC2 インスタンスに簡単にアクセスできるようになりました。 Amazon Aurora が クロスリージョン グローバルデータベース スイッチオーバー時間を通常 30 秒未満に短縮 Amazon Aurora は、より高速な グローバルデータベース クロスリージョン スイッチオーバーを提供しました。通常 30 秒未満でスイッチオーバーが可能です。グローバルデータベースでは、単一の Aurora クラスターが複数の AWS リージョンにまたがることができ、リージョン全体の障害からの災害復旧を提供します。スイッチオーバーは事前に計画された切り替えに利用する機能となっており、事前の切り替えテストなどのシナリオで利用する機能です。 5/23(金) CloudWatch Database Insights が Aurora Limitless PostgreSQL のサポートを追加 CloudWatch Database Insights が Amazon Aurora PostgreSQL Limitless データベースをサポートしました。Database Insights は、事前構築されたダッシュボード、推奨アラーム、および自動テレメトリ収集を使用して、データベースフリートの健全性を監視し、根本原因分析を行うことができます。Aurora Limitless データベースで Database Insights を有効にして、Limitless シャードグループ全体でのデータベース負荷の分散状況の監視を開始できるようになりました。 Amazon ECS がコンテナ終了理由メッセージを 1024 文字に増加 Amazon ECS はコンテナ終了理由メッセージの長さを 255 文字から 1024 文字に拡張しました。この強化により、コンテナが失敗した際により多くのなエラーメッセージを提供することで、より効果的なデバッグが可能になります。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 気づけば 5 月も終盤ですが、もう少し生成 AI のイベントが続きます！ 5 月 27 日（火）：ナウいフロントエンド開発 ~ 生成 AI と協調するには ~ 5 月 28 日（水）：Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発体験ハンズオン ~ 大阪開催 6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 もあと 1 ヶ月を切りました。登録は こちら から！ 4 月に発表した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 先週は、Claude ユーザー待望の Claude 4 Sonnet/Opus が Amazon Bedrock で使えるようになるといった注目が高いアップデートがありました。 それでは、5 月 19 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AI イノベーションを加速する NVIDIA Blackwell GPU を搭載した新しい Amazon EC2 P6-B200 インスタンス」を公開 5 月 15 日に NVIDIA B200 を搭載した Amazon EC2 P6-B200 インスタンスの一般提供を開始しました。Amazon EC2 P6-B200 は特に、強化学習 (RL) と蒸留を用いた基盤モデルの大規模な分散 AI トレーニングおよび推論、マルチモーダルのトレーニングと推論、HPC アプリケーションに適しています。本記事ではインスタンスの特徴や仕様を紹介しています。 ブログ記事「Amazon Bedrock で 基盤モデルを使用する際のコスト最適化」を公開 生成 AI の推論コストの管理と最適化は、従来のクラウドコスト管理と同じくらい重要です。本記事では、Amazon Bedrock でコスト最適化を行う様々な方法を紹介しています。料金オプション、モデル選択、ナレッジベースの最適化、プロンプトキャッシュや自動推論について触れています。 ブログ記事「Strands Agents – オープンソース AI エージェント SDK の紹介」を公開 5 月 16 日に Strands Agents というAI エージェント構築のためのオープンソース SDK をリリースしました。Strands Agents は、わずか数行のコードで AI エージェントの構築や実行を行うことができます。本記事では、Strands Agents の仕組みやサンプルコード、デプロイ方法を紹介しています。まずはサンプルコードを是非実行してみてください！ ブログ記事「AWS Transform for VMware の新機能」を公開 5 月 15 日に AWS Transform for VMware が一般提供開始されました。これは、大規模な VMware モダナイゼーションを簡素化するエージェント型 AI サービスです。本記事では、実際の操作方法を画像付きでステップバイステップで紹介しています。実際にテストを行ったパートナー様の声も掲載していますので是非ご覧ください。 ブログ記事「AWS Transform for .NET: .NET アプリケーションを大規模にモダナイズするための初のエージェント型 AI サービス」を公開 .NET アプリケーションをモダナイズする機能は、これまで Amazon Q Developer 変換機能 でプレビューで提供されていましたが、今回 AWS Transform for .NET というサービスとして一般提供が開始されました。これまでの移植機能に加えて、プライベート NuGet パッケージを使用するプロジェクトをサポートする機能などいくつかの新機能が追加されています。本記事では操作画面のスクリーンショット付きで移植方法と新機能を紹介しています。 ブログ記事「AWS Transform によるメインフレームと VMware ワークロードモダナイゼーションの加速」を公開 AWS Transform for Mainframe は、メインフレームワークロードを大規模にモダナイズするための初のエージェント型 AI サービスです。IBM z/OS アプリケーションのモダナイゼーションを数年から数ヶ月に短縮します。本記事にて、各機能や設定方法を紹介しています。 ブログ記事「開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock と LiteLLM 活用のコツ」を公開 5 月 13 日に「Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ ~」というイベントを開催しました。本ブログはイベントで提供した内容をまとめたものです。AIコーディング支援エージェントの導入時に考慮すべきガバナンスについて、AWSサービスとオープンソースツールを組み合わせたアプローチ例を紹介しています。 ブログ記事「ライフサイエンスのイノベーションをAWSのAIエージェントで加速」を公開 ヘルスケア・ライフサイエンス業界全体でエージェント開発の民主化を促進するため、AWS はヘルスケア・ライフサイエンス分野向けの オープンソースAIエージェントツールキット を開発しました。本記事では、ツールキットのはじめ方やアーキテクチャの解説をしています。ツールキットには創薬研究エージェントや臨床開発エージェント等が含まれています。 ブログ記事「IoT@Loft #26 関西発 IoT × 生成 AI が描く新たな未来 【開催報告＆資料公開】」を公開 5 月 15 日に 第 26 回 IoT@Loft 「関西発 IoT× 生成 AI が描く新たな未来」を開催しました。本ブログでは、イベントの内容を紹介し、各登壇者の発表資料を公開しています。生成 AI と IoT の融合による新たな可能性について、お客様 3 社と AWS がセッションした様子が紹介されています。 サービスアップデート Amazon Bedrock Data Automation がビデオからのカスタムインサイト生成に対応 Amazon Bedrock Data Automation（BDA）がビデオのカスタムブループリントに対応し、標準出力では取得されない情報を抽出・生成することができるようになりました。自然言語の指示によって、生成する内容や出力データタイプを指定することが可能です。例えば、広告配置のためにテレビ番組を分析するユーザーは、カスタムブループリントを使用してシーンを要約したり、映っているオブジェクトを検出し製品ロゴを識別したりすることが可能です。 Amazon Bedrock Agents の CloudWatch メトリクスを発表 Amazon Bedrock Agents に対する包括的な CloudWatch メトリクスサポートを提供しました。これにより、開発者はエージェントベースのアプリケーションをより高い可視性で監視、トラブルシューティング、最適化できるようになりました。メトリクスには呼び出し回数、レイテンシー測定、トークン使用量、エラー率などが含まれお客様が本番環境でのエージェントのパフォーマンスをより良く理解するのに役立ちます。Amazon BedrockがサポートされているすべてのAWSリージョンで現在利用可能です。 Anthropic Claude 4 基盤モデルが Amazon Bedrock で利用可能に Anthropic Claude モデルの次世代版、Claude Opus 4 と Claude Sonnet 4 が Amazon Bedrockで利用可能になりました。これらのモデルは特にコーディングに優れており、複雑で長時間にわたるタスクやエージェントワークフローにおいて高いパフォーマンスを発揮します。Opus 4 と Sonnet 4 はどちらもハイブリッド推論モデルで、深い推論のための拡張思考モードをサポートしています。Claude Opus 4 は、米国東部（オハイオ、バージニア北部）および米国西部（オレゴン）リージョンで利用可能です。Claude Sonnet 4 は米国東部（オハイオ、バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ハイデラバード、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京）、および欧州（スペイン）リージョンにて呼び出し可能です。どちらもクロスリージョン推論を通じてアクセスできます。詳しい特徴は ブログ や ガイド を参照ください。 Amazon Bedrock モデルが AWS GovCloud (US) で FedRAMP High および DoD IL-4/5 承認を取得 Anthropic Claude 3.5 Sonnet v1 と Claude 3 Haiku、および Meta Llama 3 8B と 70B モデルが、AWS GovCloud (US) リージョンの Amazon Bedrock において、FedRAMP High および国防総省クラウドコンピューティングセキュリティ要件ガイド (DoD CC SRG) インパクトレベル (IL) 4 および 5 の承認を取得しました。さらに、Amazon Bedrock の各機能（エージェント、ガードレール、ナレッジベース、モデル評価）も承認されました。連邦政府機関、公共部門の組織、およびFedRAMP High コンプライアンス要件を持つ企業は、Amazon Bedrock を使用して Anthropic と Meta の高性能な基盤モデル (FM) にアクセスできるようになりました。 次世代版 Amazon SageMakerが新たなリージョンで利用可能に 次世代版 Amazon SageMaker が欧州（ストックホルム）リージョンで利用可能になりました。サポートされているリージョンの一覧は こちら からご覧いただけます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

こんにちは。元自動車メーカー生産技術出身で AWS ソリューションアーキテクトへ転身し、普段は製造業のお客様の技術支援をしている、岩根です。本記事では、きたる 2025 年 6 月 25 日 (水) と 26 日 (木) の 2 日間、幕張メッセで開催される AWS Summit Japan 2025 のブース予告をお届けします。製造業に関する展示は Hall 7 の AWS Expo 内にある AWS Industries Pavilion にあります。その中でも「スマート製造」に焦点を当て、詳しい内容をご紹介します。 ブース概要 スマート製造の取り組みとして、製造データの収集と可視化に取り組まれるお客様が「どこから手を付けてよいのか」「ハードルが高いのでは？」と言う声をいただくことが多いです。今回スマート製造ブースでは、 三菱電機株式会社様ご協力 のもと、FA 機器を用いて、e-Bike (電動自転車)のフレームの塗装工程を再現しています。そして、そこから得られるデータを可視化したうえで、データ活用の事例として、生成 AI エージェントを用いたトラブルシューティングのデモをご覧いただけます。 図1：製作中のデモブース よくある課題 今回のデモで想定する課題は以下のようなものです。 製造オペレーションの最適化 設備トラブルの早期解消 設備の予知保全 品質問題の未然防止 これらを始めるためにデータを活用したいが、どこから手を付けてよいのかわからない このブースの注目ポイント 産業用ロボットを用いた e-Bike の模擬塗装ブースを展示し、実機から得られるデータをニアリアルタイムで可視化します 設備トラブルや品質トラブル発生時に、トラブルシュートまでの手順や、事後の予備品発注などの事務作業をアシストするAIエージェントをデモします トラブル発生時には、設備のどの箇所で起きたトラブルかを視覚的に理解できるように、デジタルツインで故障箇所をアノテーションします 三菱電機様とのパートナーシップにより、三菱電機製ロボットや制御機器を活用した実用的な展示を行います このブースでは、上記のように実機を用いて、そこで発生するデータの収集と可視化ダッシュボード、設備や品質トラブルの際のトラブルシューティングをアシストする AI エージェントを展示します。これら動くデモにより、自社のデータ活用のイメージを持っていただくことができます。 AWSサービス AWS IoT Greengrass ：制御機器の OPCUA Server からデータを収集し、クラウドに送信するために利用しています AWS IoT SiteWise ：収集した製造データを構造化し、時系列に保存するために利用しています AWS IoT TwinMaker ：デジタルツインで故障箇所をアノテーションするために使っています Amazon Managed Grafana ：ニアリアルタイムのダッシュボードを実現しています Amazon Bedrock ：AIエージェントの機能実現のために使っています デモでご紹介予定のシナリオ 工程における平時のオペレーションに必要な情報は、ニアリアルタイムのダッシュボードとして Grafana を用いて可視化しています。異常時のオペレーションで紹介する予定のシナリオはいくつかありますが、ここでは設備にトラブルが起きたときを想定したシナリオをご紹介します。 設備トラブルをダッシュボードで発見する（図2） ダッシュボードから該当のトラブルを開くと、AI エージェントの画面になる（図3） 機器から得られた情報を元に、考えられるトラブルの想定原因と対処方法をAIエージェントが提案する。また、DigitalTwin 上に、原因箇所をアノテーション表示する 対処方法をオペレータが実施したら、実施完了を AI エージェントに連絡する 交換部品の在庫数を AI エージェントが確認し、発注有無をオペレータに確認する オペレータが発注を依頼すると、AI エージェントが ERP と連携して部品発注を行う 図2：ニアリアルタイムダッシュボード 図3：AIエージェントによるトラブルシューティング アーキテクチャ 以下がデモ予定のアーキテクチャとなります。Edge Gateway として AWS IoT Greengrass をデプロイした Windows/Linux PC を置き、PLC の OPCUA Server ユニットから情報を収集しています。エッジ⇔クラウド間はデバイス証明書を用い、通信も暗号化するなどセキュリティ対策も実施しています。AI エージェントは Agent for Amazon Bedrock を使って実現しています。 図4：アーキテクチャ 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。  

2025 年 5 月 15 日に開催したウェビナーでは、2025 年 4 月にラスベガスで開催された NAB Show 2025 における AWS 展示の振り返りを行いました。AWS 展示では従来の放送を超えた新しいエンターテインメント体験の創出をテーマに、スポーツエンターテインメント、ファンエンゲージメント、没入型技術、ラジオ/ポッドキャストなどの多面的なソリューションを提案しました。F1 シミュレーターを使用したeスポーツ体験や、放送局向けのクラウドベースのソリューション、さらにコンテンツ制作からビジネス支援まで幅広い業務の革新を可能とする Amazon Nova や Amazon Bedrock などの最新 AI サービスを展示しました。 NAB Show 2025 では、次の 6 つのソリューションエリアで、AWS が提供するメディア & エンターテインメント向けソリューションの最新アップデートや機能強化と共にデモ展示を行いました。 [ライブクラウドプロダクションと放送] クラウドネイティブの制作ワークフロー、eスポーツレースの活性化、AI を活用したレース自動ハイライト [コンテンツ制作とポストプロダクション] 編集ソリューション、AI 支援型アセット作成、レンダリング自動化 [ラジオとポッドキャスト] クラウドベースのラジオ自動化、ポッドキャスト制作ソリューション、AI を活用したコンテンツ強化 [ファンエンゲージメント] 没入型視聴体験、インタラクティブなデータ可視化、デジタルヒューマンコミュニケーション [マルチチャネル収益化] パーソナライズ広告、バーチャルプロダクトプレイスメント、コンテキスト広告 [イノベーション事例] 生成 AI アプリケーション、ゲームとインタラクティブ体験、データサイエンスとアナリティクス、メディアオペレーション自動化 また、NAB Show 期間中にはAWS主催のセッションとして “ How to build entertainment breakthroughs using generative AI and the cloud ” と題し、AWS M&E の General Manager の Samira Panah Bakutiar と、Prime Video、PBS、COSM の代表者が集まり生成 AI とクラウドを活用したトレンド、実践事例を紹介するセッションを行いました。本メディアセミナーではそのセッションの振り返りも行いました。   NAB Show 2025 – AWS 展示概要 – 新たな視聴体験を実現するコンテンツ制作（ライブクラウドプロダクションと放送、コンテンツ制作とポストプロダクション、ラジオとポッドキャスト） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 井村 紀彦 [ 資料 、 動画 ] 視聴者体験を革新的に進化させるコンテンツ制作ソリューションをご紹介します。従来の一方向の放送から、よりイマーシブでインタラクティブな体験へと変化する視聴者ニーズに応える最新技術をデモ展示の内容に基づき解説します。West Hall ロビーで展開されるeスポーツレーシングチャレンジを通じて、クラウドベースのライブプロダクション、AI によるリアルタイム分析、視聴者参加型の体験の実現方法を紹介します。さらに、プロダクションコントロールルーム、ポストプロダクション環境、ラジオ/ポッドキャストスタジオなど、実践的なデモ環境を通じて、次世代の放送制作ワークフローの全体像をご説明します。   NAB Show 2025 – AWS 展示概要 – コンテンツの収益化を強化するファンエンゲージメントと生成 AI/データ活用（ファンエンゲージメント、マルチチャネル収益化、イノベーション事例、セッション振り返り） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 金目 健二 [ 資料 、 動画 ] コンテンツの価値最大化を実現する AWS の最新テクノロジーを活用し、ファンエンゲージメントの強化とデータドリブンな収益化戦略について解説します。Amazon Nova と Amazon Bedrock によるマルチモーダルな生成 AI により、パーソナライズされたコンテンツ生成やインタラクティブな視聴者体験が実現します。イマーシブでパーソナライズされたデジタル体験の事例を通じて、ファンエンゲージメントと新たな収益機会の創出を可能にする、視聴者との深い関係性を構築し持続可能な収益化を実現する AWS のソリューションを紹介します。   おわりに 本ブログでは、2025 年 5 月 15 日に開催されたメディアセミナー 2025 Q2 ～ NAB Show 2025 の recap ～について紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。   参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは SA 金目、井村が担当いたしました。

本稿は、2025 年 5 月 16 日に Migration & Modernization Blog で公開された “ New Capabilities in AWS Transform for VMware ” を翻訳したものです。 はじめに AWS Transform for VMware の一般提供を発表できることを嬉しく思います。これは VMware ワークロードのモダナイゼーションを加速するために特別に構築された最初のエージェント型 AI エクスペリエンスです。アプリケーションの検出、依存関係のマッピング、移行計画、ネットワーク変換、Amazon Elastic Compute Cloud (EC2) インスタンスの最適化を自動化し、手作業の労力を削減してクラウド導入を加速します。これは VMware モダナイゼーションにおける最も複雑な課題のうちの 2 つに対応します：VMware ネットワーク設定を AWS ネイティブの構成要素に変換すること、そしてスムーズな切り替えのための依存関係を考慮した移行ウェーブのオーケストレーションです。この投稿では、現在利用可能な AWS Transform の機能について説明します。 前提条件 サービスへのフェデレーションのための AWS Identity and Access Management (IAM) Identity Center のセットアップ AWS Organizations のセットアップ VMware discovery アカウントとして機能する AWS アカウント。このアカウントにはすべての検出データが含まれます。このアカウントは AWS 組織の一部である必要があります。 VMware infrastructure provisioning アカウントとして機能する AWS アカウント。このアカウントは、変換されたリソースがデプロイされます。discovery アカウントと同じである必要はありませんが、本番移行には別のアカウントが推奨されます。このアカウントは AWS 組織の一部である必要があります。 開始方法 – AWS Transform の有効化 AWS コンソールで AWS Transform を検索します。次に Get Started を選択します。 図1. AWS Transform メインページ 暗号化キーを指定し、 Enable AWS Transform を選択します。デフォルトの暗号化またはカスタム暗号化を選択できます。 図2. AWS Transform 暗号化 Manage Users を選択します。 図3. Manage Users を選択 IAM Identity Center にあるユーザーまたはグループを AWS Transform に追加できます。 図4. AWS Transform にユーザーを追加する ユーザーは Web アプリケーション URL を使用して AWS Transform に直接アクセスできます。 図5. AWS Transform の URL エンドツーエンドの移行ワークフロー AWS Transform for VMware は、お客様が希望する変換アプローチを選択できる柔軟なエクスペリエンスを提供します。このサービスは、特定の移行シナリオに対応するように設計された 4 つの異なるワークフロータイプを提供します。このモジュラー設計により、お客様は VMware から AWS への移行の特定の側面（ネットワーク変換、サーバー移行、または包括的なエンドツーエンド移行）に集中できます。 以下のワークフローオプションから選択できます： End-to-End Migration – ディスカバリー、ウェーブプランニング、VPC 設定、ネットワークデプロイメント、サーバー移行を通じてお客様を案内する包括的なワークフロー Network Migration Only – ネットワーク変換に焦点を当て、VPC 設定とデプロイを処理 Network and Server Migration – ネットワーク設定とデプロイをサーバー移行機能と組み合わせたもの Discovery and Server Migration – お客様によるディスカバリーの実行、ウェーブプランの生成、およびサーバー移行の実行 図6. AWS Transform チャットインターフェイス ニーズに最適な VMware 移行ジョブタイプを選択します： 図7. VMware 移行用の AWS Transform ジョブオプション AWS Transform for VMware は AWS Application Migration Service (MGN) と統合されており、AWS Transform コンソールから直接 MGN 移行ライフサイクル全体を管理できます。この統合により、すべての MGN 関連タスクのための一元化されたインターフェイスを提供することで、移行プロセスを合理化します。AWS Transform 内で、以下のことができます： MGN エージェントをインストールしてソースサーバーを追加 カットオーバー前にアプリケーションの機能を確認するためのテストインスタンスの起動 移行状況の追跡 カットオーバーの実行 図8. AWS Transform ワークフロー AWS Transform for VMware は、ソースサーバー全体への自動エージェントデプロイメントのために MGN Connector を統合しています。MGN Connector はソース環境内の自動化サービスとして機能し、効果的に動作するために特定のコンポーネントを必要とします。これには、AWS Secrets Manager に保存された管理者資格情報、ソースサーバー上のサポートされているオペレーティングシステム、および TCP ポート 1500 と 443 を介した MGN Connector からソースサーバーへのネットワーク接続が必要です。 MGN Connector のデプロイメントは、必要な IAM ロール、ポリシー、ネットワークコンポーネントを確立し、AWS Systems Manager、AWS Secrets Manager、MGN サービスアクセスの権限を設定する AWS CloudFormation テンプレートを使用して自動化できます。 AWS Transform コンソール内で、ユーザーは既存のコネクタを選択するか、新しいコネクタを作成し、管理者資格情報を含む適切な AWS Secrets Manager シークレットに関連付けることで MGN Connector を構成できます。AWS Transform はまた、ソースサーバーに手動でレプリケーションエージェントをデプロイするオプションも提供します。 エージェントは MGN Connector または手動インストールを通じてデプロイされると、サービスは設定タスクを管理し、AWS Transform インターフェイスを通じてデプロイメントステータスの更新を提供します。要件と MGN 機能に関する最新かつ詳細な情報については、公式の AWS Application Migration Service ドキュメント を参照してください。 図9. AWS レプリケーションエージェントのインストール方法 AWS Transform インターフェイスから直接テストインスタンスを起動できます。このサービスはエクスポート可能なインベントリファイルを提供し、要件に応じてダウンロード、レビュー、変更してから AWS Transform にアップロードし直すことができます。インターフェイスはレプリケーションステータスの可視性を提供し、アプリケーションを「正常」、「遅延」、「停止」に分類し、ソースサーバーとその移行進捗の詳細なモニタリングを可能にします。 図10. テストインスタンスの起動 AWS Transform ダッシュボードでは、ウェーブ、アプリケーション、サーバー、ネットワークという 4 つの主要カテゴリを通じて移行の進捗を追跡できます。インターフェイスは移行メトリクスを単一のビューにまとめ、チームが複数の同時移行を監視できるようにします。ダッシュボードは単一のインターフェイスに移行ステータスデータを集中させることで、複数の AWS コンソールをナビゲートする必要性を減らします。 図11. AWS Transform ジョブダッシュボード ネットワーク作成 AWS Transform for VMware Migrations では、RVTools エクスポート (.csv と .xlsx の両方) と VMware NSX エクスポートを使用して、AWS でのネットワークトポロジーをモデル化およびデプロイできます。RVTools のみを使用すると、既存の VMware ネットワークに一致する VPC を構築できます。NSX を使用する場合、既存の NSX ネットワークを AWS にシームレスに変換して移行できます。VMware NSX 設定データは、オープンソースの Import/Export for AWS ユーティリティを使用して VMware 環境から効率的にエクスポートできます。NSX データのインポートにより、AWS Transform はセキュリティグループも構築できます。AWS Transform は CloudFormation と AWS Cloud Development Kit (CDK) の両方でネイティブな AWS ネットワーク設定を生成します。AWS Transform にネットワーク設定を自動的にデプロイさせることもできます。これは、ターゲットアカウントで生成された CloudFormation コードを実行することで達成されます。また、生成された CloudFormation または CDK コードをダウンロードして既存のビルドプロセスに統合することで、手動でデプロイするオプションもあります。 ネットワーク設計モデル Hub-and-spoke – Hub-and-spoke モデルでは、AWS Transform for VMware は VPC、AWS Transit Gateway、および AWS Transit Gateway アタッチメントをデプロイし、すべての VPC 間の通信を可能にします。 Isolated VPC – Isolated VPC モードは、Transit Gateway またはアタッチメントをデプロイせずに VPC を作成します。つまり、VPC は互いに分離されたままになります。分離された VPC は、顧客が既存の AWS インフラストラクチャを持っている場合に最も頻繁に使用されます。AWS Transform は VPC を作成し、それらを既存のネットワークにアタッチします。分離された VPC を使用すると、重複する IP 範囲を別々の非相互接続環境に移動でき、移行完了後に後でリンクすることができます。また、AWS Transform を使用して AWS を災害復旧サイトとして設定する場合にも効果的で、クリーンな分離と段階的な統合のための柔軟性を提供します。 クロスリージョン移行のサポート AWS Transform はクロスリージョン移行をサポートしており、コントロールプレーンはバージニア北部 (us-east-1) またはフランクフルト (eu-central-1) のいずれかに存在し、以下にリストされているリージョンのいずれかをターゲットに移行できます。 米国 バージニア北部 (us-east-1) オレゴン (us-west-2) アジア太平洋 ムンバイ (ap-south-1) ソウル (ap-northeast-2) 東京 (ap-northeast-1) シンガポール (ap-southeast-1) シドニー (ap-southeast-2) カナダ 中部 (ca-central-1) ヨーロッパ フランクフルト (eu-central-1) ロンドン (eu-west-2) パリ (eu-west-3) 南アメリカ サンパウロ (sa-east-1) MAP 2.0 タグ付けサポート AWS Migration Acceleration Program (MAP) は、数千のエンタープライズ顧客をクラウドに移行した AWS の経験に基づいた包括的で実績のあるクラウド移行プログラムです。MAP は、コストを削減し自動化して実行を加速するツール、カスタマイズされたトレーニングアプローチとコンテンツ、AWS パートナーネットワークのパートナーからの専門知識、グローバルパートナーコミュニティ、および AWS 投資を提供します。 タグとは、 AWS リソースにユーザーが適用するキーと値のペアで、そのリソースに関するメタデータを保持するためのものです。タグの例としては、名前、環境、ビジネスオーナー、またはあなたが追跡する必要があるその他の情報などが挙げられます。MAP の利点の 1 つは、一度限りの移行コストを相殺するのに役立つ AWS 投資であり、サービスクレジットの形でお客様に提供されます。クレジットの適格性は MAP 2.0 タグ付け によって追跡され、移行したリソースに特定のタグを活用します。AWS Transform がなければ、これは移行後に覚えておく必要のある手動のステップです。AWS Transform では、 MPE ID を入力するだけで、移行したすべてのリソースに自動的にタグが付けられます。 図12. MAP 2.0 タグ付けサポート 料金 現在、評価と変換を含む主要機能を AWS のお客様に無料で提供しています。これにより、初期費用なしで移行とモダナイゼーションの旅を加速できます。 結論 AWS Transform for VMware が一般提供を開始しました。これは、VMware ワークロードの AWS 上でのモダナイゼーションを簡素化し加速するために設計された画期的なエージェント型 AI を活用したサービスです。このツールはアプリケーションの検出、依存関係マッピング、ネットワーク変換、EC2 インスタンスの最適化という複雑なプロセスを自動化し、手作業の労力と移行リスクを大幅に削減します。私たちのパートナーは数ヶ月間このサービスをテストしてきました。以下は、そのうちの 2 社が顧客に対して見ている効果です。 「AWS Transform for VMware は、手戻りを減らし、コンサルティングの必要性を最小限に抑え、従来の知識のギャップを埋めることで、クライアントのクラウド移行プロセスを大幅に加速できます。内部テストに基づくと、AWS Transform for VMware は AWS への VM 移行時間を少なくとも 50% 削減できることがわかっています。現在、より迅速な移行と、ビジネスにとって価値主導の成果をさらに引き出すために、AWS Transform を私たちのツールに統合しています。」 – Neil Redmond, Managing Director | Accenture 「AWS Transform for VMware は VM の検出とワークロードの評価を自動化することで、移行計画を劇的に加速しました。このエージェント型 AI サービスは 100% の検出精度を達成し、リソース使用率、依存関係マッピング、およびインフラストラクチャの適切なサイジングに関する重要な洞察を提供しました。AWS Application Discovery Service および Migration Hub との統合は、当社の複雑な移行ニーズにとって特に価値があり、顧客の資産におけるアプリケーション依存関係をより良く理解するのに役立ちました。ディスカバリーのタイムラインを 50% 削減し、評価フェーズだけで 2 倍から 3 倍の加速を実現しました。私たちは、お客様のクラウドジャーニーを加速し続ける中で、インフラストラクチャモダナイゼーション提供の中核として AWS Transform を活用することを楽しみにしています。」 – Stefan Buchman, Head of Solutions | Slalom さらに読む VMware モダナイゼーションについてさらに詳しく知り、 VMware 移行の旅を始める方法を探ってください 。 AWS Transform for VMware のインタラクティブデモをチェックしてください。 ユーザーガイド を使用して、今すぐ自分のアカウントで AWS Transform の機能の探索を開始してください。 Patrick Kremer Patrick Kremer は、インフラストラクチャの移行とモダナイゼーションに特化したシニアスペシャリストソリューションアーキテクトです。Patrick は 2022 年に AWS に加わり、20 年間の VMware 経験を活かして、お客様が AWS ソリューションへ移行するのを支援しています。彼は教育とブログ執筆に情熱を持つ AWS 認定ソリューションアーキテクトプロフェッショナルです。 Pedro Calixto Pedro Calixto は AWS のシニアソリューションアーキテクトであり、ワークロードの移行とモダナイゼーションを専門としています。彼は、企業がオンプレミス環境を AWS 内で拡張、移行、保護するのを支援すること、そして AWS サービスを使用したアプリケーションのモダナイゼーションを加速することに重点を置いています。 Paul Cradduck Paul Cradduck は、テクノロジーとイノベーションへの生涯にわたる情熱に突き動かされ、約 20 年の経験を持つ経験豊富な IT プロフェッショナルです。AWS のシニアスペシャリストソリューションアーキテクトとして、スケーラブルなクラウドネイティブソリューションを中心に、組織のオンプレミスワークロードのモダナイズと移行を支援しています。深い好奇心と実践的なアプローチで知られる Paul は、常に最新の新興テクノロジーを探求し、学び、洞察を共有することに熱心です。彼はオハイオ州シンシナティで妻の Kathryn と 3 人の娘 Arlo、Isla、Zuri と暮らしています。 この投稿の翻訳は Solutions Architect の澤が担当させていただきました。原文記事は こちら です。

みなさんこんにちは。ソリューションアーキテクトの中島です。 本記事では 2025/04/17 に開催された 小売・消費財のお客様向けのデータ分析基盤イベント の様子を皆様にお伝えさせていただきます。 イベントの目的 本イベントは「データ分析を始めたいが、まず何から始めたらいいのか分からない。」「データ分析業務を進めているが技術だけでなくさまざまな障壁があり苦労している。」というお客様の声にお応えすべく企画されました。 そのため、以下 2 つを主題としてイベントを実施しました。 先行企業の経験からデータ活用の実践方法を学ぶ データ活用アイデアソンの結果をお持ち帰りいただきデータ活用の第一歩を踏み出していただく また、本イベントは AWS ではなくお客様の事例登壇が主体であるという点もユニークです。 当日のアジェンダ このイベントでは前半にユーザー企業様の事例登壇をしていただき、後半それをインプットにダッシュボードを描いてみるという構成になっておりました。 それでは以降詳細をご共有いたします。 大丸松坂屋百貨店 林 直孝氏 「カスタマーデータドリブン経営の勘所」 デジタルトランスフォーメーション（DX）が叫ばれる現代、実際の現場ではどのようにデータを活用し、ビジネス変革を進めているのでしょうか。大丸松坂百貨店 林氏による講演から、J.フロント リテイリンググループがどのようにデータドリブン経営に取り組み、成果を上げているかをお伝えします。 大丸松坂屋百貨店 林 直孝氏 J.フロントリテイリングの事例から見えた小売業におけるデータドリブン変革の重要ポイント データ活用の目的を明確にする（顧客のライフタイムバリュー最大化） グループ内の壁を越えてデータを統合し、顧客理解を深める データ活用のためのフレームワーク（DAPCサイクル）を構築する 実践を重視したデジタル人財育成プログラムを展開する 技術とともに「マインドセット」の変革も推進する 戦略 J フロントリテイリング (以降、JFR) 様は大丸松坂屋百貨店様と PARCO 様を擁する持株会社として、「価値共創リテーラー」を目指しています。同社の DX 戦略は単なるデジタル化ではなく、従業員体験 (EX) と顧客体験 (CX) を向上させることに焦点を当てています。 JFR 様では若い世代のお客様から支持の高い PARCO と幅広い年齢層向けの大丸松坂屋という異なる業態を持つ強みを活かし、顧客のライフタイムバリューの最大化を図っています。 データ活用の原点 データ活用の原点となったのは、PARCO での興味深い顧客行動の発見です。データ分析により、複数のショップを利用する顧客の方が、単一ショップのみの利用者よりも翌年の再来店率が高いという事実が判明しました。この発見は PARCO と大丸松坂屋の双方をご利用になるお客様の方が、どちらか一方を利用するお客様よりも LTV が高いお客様ではないか？という仮説につながり、実際にデータ分析を行いそれが実証され、グループ間データ統合の重要性を示す根拠となりました。 グループデータの統合と活用 ライフタイムジャーニーに寄り添ったお客様固有のサービスを提供していくことが重要であると考えられているため、世代ごとに利用の違う PARCO・大丸松坂屋百貨店、両社のアプリ等から収集したデータを統合し分析する環境を構築されていました。これにより、お客様のライフステージに応じた長期的な関係構築が可能になっています。 DAPC サイクルとデジタル人材育成 データ活用を組織的に進めるため、JFR グループのパルコでは「DAPC サイクル」を回すことで組織としての CRM を実行していました。 JFR グループとして複数の事業会社のデータを活用してこのサイクルを回すための課題の一つとしてグループ共通のデータを駆使できるデータアナリストやデジタルデザイナー人財の育成が 必要でした。 JFR では 2022 年から本格的な デジタル人財育成プログラム を開始し、2030 年までにグループ内で 1,000 名のデジタル人財育成を目標に掲げています。このプログラムの特徴は、 徹底した実践重視のアプローチ です。受講者は実際の業務データを使用し、3 ヶ月間で約 50〜60 時間のカリキュラムを受講します。プログラム中に作成した ダッシュボードなどのツールは、修了後もそのまま業務で活用 できます。また育成されたデジタル人財は後続メンバーの育成にも関わり、組織全体のデジタルリテラシー向上に貢献しています。 技術スキルだけでなく、「完成度が 60% でもまずやってみる」「スピードを重視する」などのアジャイルなマインドセットも重視されています。 独自の「花伝書」を作成 し、 デジタル文化の定着 を図っています。 データアナリスト育成講座の卒業生の手で「JFR グループ データ活用ポータル」が構築され、現場での意思決定に活用されています。コア人財の育成と現場への還流によって、DAPC サイクルも機能しはじめました。 まとめ 大丸松坂屋百貨店様のご登壇は、小売業におけるデータ活用の重要性と、それを実現するためのテクノロジー・組織・人財の三位一体の取り組みの重要性を示されていました。特に、AWS 基盤を活用した統合データ基盤の構築と、それを活用できる人財の育成に注力している点は、多くの企業様にもご参考になると思います。 オイシックス・ラ・大地株式会社 中野 高文氏 「食の課題をデータで解く 〜ゼロから構築した分析基盤と成果〜」 オイシックス・ラ・大地（以下、オイシックス）様のご登壇では、実際にビジネスインパクトを出すための実践的なデータ基盤構築と活用のアプローチが示されました。ご登壇では、同社がデータ活用を進める中で直面した課題とその乗り越え方をご紹介いただきました。 オイシックス・ラ・大地株式会社 中野 高文氏 オイシックス様の事例から見えたデータ基盤導入を確実に前に進めるための重要ポイント 活用テーマ: ROI 説明可能なテーマから着手する トップダウン: 経営層の巻き込みが成功を後押し ボトムアップ: 現場の知見が DWH 品質を決める 内製化: 改善スピードを担保するためには不可欠 アジャイル: 完璧を目指さず使いながら育てる データ基盤導入の壁 データ活用を成功させる上での課題を 4 つ挙げていただきました。まず、データ基盤構築には高額な投資が必要ですが、具体的な ROI が見えにくく経営層の承認を得るのが困難 です。また、データに関する経験不足から判断に自信を持てない経営層も多くいます。次に、 システム側が作ったツールが現場のニーズに合わない という事業部とデータチームの連携不足があります。データ基盤はビジネスナレッジの塊であり、現場を理解せずに構築することはできません。さらに、一度構築したデータ基盤は 放置すると品質が劣化 するため、継続的な監視と改善が必要です。最後に、最初から完璧な設計を目指す ウォーターフォール型アプローチよりも柔軟な対応が必要 で、初期は外部パートナーの活用が効率的ですが、長期的には内部人材の育成が重要です。 Data Cuisine によるデータ活用の成果 こうした課題を解決しながら、オイシックス様は AWS サービスを一気通貫で活用するアーキテクチャを選択し、Data Cuisine を構築されていました。既存システムとの連携のしやすさ、サービス間のオーケストレーションの容易さ、複数クラウド管理の負担回避が主な理由です。 オイシックス様ではデータ基盤の構築により複数の重要な成果が得られました。まず業務効率が劇的に改善され、データアナリストが手作業から解放されて 本来の分析業務に集中できる環境 が実現しました。この変化は単に作業時間の短縮だけでなく、専門人材の 職場満足度向上 にも大きく貢献しています。次に、構築したデータ基盤は販売計画システムの中核として組み込まれ、過去実績に基づく計画立案、在庫数決定などの 重要なビジネスプロセスを支え ています。さらに、経営層が気にする売上に貢献する形で、様々な販売チャネルで パーソナライズされた商品提案が可能 になりました。 5 つの成功ポイント オイシックス様が先述の課題をどのように乗り越え、データ基盤構築を成功させたか 5 つのポイントを発表くださいました。 1. 活用テーマを先に決める: 「完全なデータを集める」には膨大なコストと時間がかかるため、まずビジネス目的を明確にしました。オイシックス様では「生産者とお客様のマッチング」と「需要予測」を優先テーマとし、そこから必要なデータを特定しました。これにより効率的な基盤構築が可能になりました。 単なる生産性向上だけでは ROI が見えづらいため、具体的なビジネス価値と紐づけることが投資説得にも効果的 でした。 2. トップダウンでの推進: 大規模プロジェクトには経営層の継続的サポートが不可欠です。オイシックス様では事業部門とシステム部門両方の執行役員の協力を得て推進しました。 プロジェクト途中で経営体制が変わり支援者がいなくなった 時期は苦戦したため、経営層が交代しても継続的に支持されるよう、 定期的な成果報告と次の展望を示し続けることが重要 でした。 3. ボトムアップでの巻き込み: オイシックス様では 事業部兼務のデータアナリストとエンジニアを配置 し、日々の業務から得られる 現場の声を直接システムに反映 しました。例えば「この受注データは除外すべき」「この数値は別ロジックで計算する必要がある」といった現場特有のルールを把握できたことがシステムの実用性を高めました。また、一度構築したら終わりではなく、日々発生する新しいデータの品質維持にも現場の協力が不可欠だという認識が重要でした。 4. 内製化の推進: 初期段階では社内にスキルを持つ人材がおらず、パートナー企業に依存していましたが、段階的に内製化を進めました。経験からわかったのは、パートナーは初期構築には有効でも、ビジネス特有の ドメイン知識が必要な改善 や、日々増加する 要求への迅速な対応 には 内部人材が不可欠 だということです。データ基盤が活用され始めると、事業部からのリクエストが急増しますが、その多くはビジネスコンテキストの深い理解が必要なため、継続的に内製化を進めてきました。これにより変化するビジネスニーズに素早く対応できる体制が整いました。 5. アジャイルな進め方: 実際にデータ基盤を使い始めてみると 要件が次々と変わる ことに気づきました。そこで、小さな価値を早期に提供しながら改善を繰り返す アジャイルアプローチ に転換しました。また、一から完璧に作るより、 既存ロジックを継承 しつつ 徐々に改善 する方が、 現場の混乱も少なく効率的 だったという教訓を得ています。 まとめ オイシックス様が目指す「こだわりの生産者とお客様をデータでつなぐプラットフォーム」の実現には、数々の課題がありました。しかし、明確な目的設定、経営層の巻き込み、現場との協働、内製化推進、アジャイル開発という 5 つのアプローチで乗り越え、データ基盤をビジネスの中核に据えることに成功されています。これらの知見は、同様の課題に直面する多くの組織にとって参考になるでしょう。 データ活用アイデアソン 「事例講演を聞き参考になった」、「データ活用に課題感を持っている」お客様にデータ活用の一歩を踏み出していただくべく、現状の課題を仮説し、ダッシュボードのスケッチを描くアイデアソンを実施いたしました。 データ活用アイデアソンはご説明を含めて 70 分 で実施しました。 実質的なワークは上記 1, 2 にあたる個人ワーク (50分) でしたが、この短い時間でも 20 以上のダッシュボードのアイデアが生まれました。 短い時間にも関わらず、ご参加いただいた方全員がダッシュボードを描くことができたのは、皆様の集中力と前向きに取り組んでいただいた結果だと思います。 グループワークでは皆様のダッシュボードの見どころを 1 分 という短い時間でご共有いただき、懇親会での決勝戦に進むアイデアを選定いただきました。私はグループを回らせていただき皆様のアイデアを拝見いたしましたが、どのアイデアも素晴らしく甲乙つけ難かったかと思います。 懇親会 (アイデアソン決勝戦) 懇親会ではユーザー企業様同士でネットワーキングしながらダッシュボードに投票していただくワールド・カフェ形式で実施しました。「このアイデアのいいところはなんだろうか」とユーザー企業様同士で会話しながらワイワイと投票していただきました。 ユーザー企業様の投票で決める「お客様賞」には株式会社 PALTAC 村田さんが選ばれました。おめでとうございます！ 村田さんの勝因は「日頃から事業部側と会話することが多い」とのことでした。 事業部の課題感をしっかり捉えたダッシュボードがユーザー企業様の心を掴んだ結果となりました。 また、AWS メンバーの投票で決める「AWS 賞」にはクオール株式会社 北嶋さんが選ばれました。おめでとうございます！ 北嶋さんは「日頃からデータ分析を業務としており、今回は目的に合わせてどれだけシンプルにできるかを心がけた」とのことでした。 シンプルかつ効果的なダッシュボードが AWS メンバーを唸らせた結果となりました。 お客様の声 本セミナー全体の CSAT (お客様満足度) 4.52 / 5 となりご満足いただける内容になったのではと一安心しております。ユーザー企業様登壇では「他社事例が大変勉強になった」「リアルな内容で良い時間になった」と嬉しいお声をいただいています。またアイデアソンについては「色々な方のアイデアが見れて良かった」「もっと時間が欲しかった。今回は複数社合同だったが自社のみでの開催も可能か？」とイベント後にも活用いただけそうなお声をいただき大変嬉しいです。 最後に ご登壇くださった大丸松坂屋百貨店 林氏、オイシックス・ラ・大地 中野氏に心より感謝申し上げます。お二方の素晴らしいプレゼンテーションは、多くの企業様に勇気と情熱を与えるものでした。また、3 時間という長時間にも関わらず、懇親会まで積極的にご参加いただいた皆様にも御礼申し上げます。本イベントが皆様のデータ活用の一助となれば幸いです。 これからも、AWS 小売・消費財チームはユーザー企業様間の情報共有・議論の場をご提供し、1 つでも多くのお客様ビジネス課題の解決をご支援させていただく所存です。今後ともご期待ください！ 著者 中島 佑樹 西日本の小売・消費財のお客様をメインで担当するソリューションアーキテクト。社会人博士を修了したことをきっかけに AIML を得意分野としている。Amazon Bedrock Agents の BlackBelt や Blog を執筆。

はじめに 2025 年 4 月 17 日、 「AWS で実現する企業の包括的サイバーセキュリティ対策」と題したセミナー を開催いたしました。昨今の IT 環境は激しい変化の中にあり、特にランサムウェアや DDoS 攻撃など、企業の IT システムに対する脅威が社会的にも大きな関心を集めています。 本セミナーでは、セキュリティに携わる方、ご興味がある方向けに AWS を活用した包括的なサイバーセキュリティ対策についての知見を共有いたしました。当日参加できなかった方や、参加したけれども内容を振り返りたい方に向けて、 セミナー動画を公開 するとともに、当日の概要についてもご紹介いたします。 セッションの紹介 1. オープニングセッション アマゾン ウェブ サービス ジャパン合同会社 シニアセキュリティソリューションアーキテクト 勝原 達也 「AWSにとって、セキュリティは最優先事項です」— 本セミナーはこの AWS が大切にしているメッセージから始まりました。AWS の CEO であるマット・ガーマンは 2024 年の AWS re:Invent のキーノートで「すべてはセキュリティから始まる（Everything starts with security）」と述べています。セキュリティは大企業からスタートアップまですべての顧客が気にしているポイントであり、クラウドの基盤として組み込まれるべきものです。 一方、お客様の情報システムを取り巻く環境は日々変化しており、考慮すべきアクセスパターンは増え、外部からの脅威だけでなく内部からの脅威を想定したアプローチも求められています。また社会を支えるシステムの重要度が一層高まっていく点についても十分な考慮が必要です。 セッション中では、CISO との対話の中で得た昨今の印象的なエピソードとして、株主総会において株主から「うちのセキュリティは大丈夫なのか」という質問が出るようになってきたことについても語られました。これは、現場レベルだけでなく、経営レベルでのセキュリティ取り組みの重要性が高まっていることを示唆しています。 2. AWS で実現するセキュリティ アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 シニアソリューションアーキテクト 日吉 康仁 本セッションでは、AWS の特性を活かして、セキュリティと俊敏性を両立しながら、継続的にセキュリティの改善を実現することの重要性について説明しています。 はじめに、世の中の動向として、クラウドを利用していない企業が利用しない理由としてセキュリティへの不安を挙げている一方で、クラウドを利用している企業のが、導入理由として信頼性の高さや情報漏洩対策を挙げており、セキュリティに対する認識にギャップがあることを示しました。 次に、AWS のセキュリティの理解を深めていただくための重要なポイントとして、以下の3点を挙げています： 「責任共有モデル」：AWS はクラウドのセキュリティに対する責任を持ち、お客様はクラウド内のセキュリティに対する責任を持つ。AWS とお客様が互いに協力し、システム全体で優れたセキュリティを実現していく、責任共有モデルの考え方 「セキュリティとコンプライアンス」：143 の豊富なセキュリティ標準とコンプライアンスプログラムをサポート 「包括的なセキュリティサービス」：アイデンティティ管理から脅威検出、データ保護まで幅広く対応した、AWS が提供するセキュリティサービスと機能 その上で、ビジネスを展開していく上で、AWS の特性である「高い可視性」と「運用の自動化・機能連携」を活用することで、一見相反するセキュリティと俊敏性の両立を可能にし、API を通じた操作の記録や、様々な設定情報の収集・モニタリング機能により、ワークロード環境の透明性が高められることを説明しました。セキュリティ統制の考え方では、「ゲートキーパー型（予防的統制）」と「ガードレール型（発見的統制）」をバランスよく組み合わせる事で、俊敏性/利便性とセキュリティの確保の両立が可能になります。発見的統制の具体例として、AWS Config などのサービスを活用して「継続的コンプライアンス」を実現することが可能になります。AWS を活用したセキュリティの取り組みには、AWS Well-Architected Framework が道しるべとなります。 優れたブレーキがあるからこそ安心してスピードを出せるように、セキュリティは企業の事業活動や成長に必要なビジネスを支えるメカニズムの１つなのです。 3. DDoS 攻撃対策の最新動向と対応策 アマゾン ウェブ サービス ジャパン合同会社 Edge Services ソリューションアーキテクト 岡 豊 本セッションでは、DDoS 攻撃からお客様のアプリケーションを保護するためのクラウドでの効果的な DDoS 攻撃対策の実装やベストプラクティス、対応策について解説しました。 セッションの冒頭では、 DDoS 攻撃の種類をインフラストラクチャレイヤーとアプリケーションレイヤーの二つの主なグループに整理した上で、AWS の DDoS 攻撃対策の専門チームである Shield Response Team が観測している最近の DDoS 攻撃の傾向や DDoS 攻撃によるビジネスインパクトについて説明しました。 次に AWS がクラウドのインフラストラクチャ全体を DDoS 攻撃からどのように保護しているか、AWS Shield による DDoS 攻撃からの保護の仕組みと AWS の分散されたグローバルインフラストラクチャによる攻撃緩和の有効性について触れています。その後に、一般的な DDoS 攻撃対策の3つの基本アプローチ（1. DDoS 攻撃の対象となる領域を限定する、 2. 攻撃トラフィックを制限・緩和する、 3. 負荷分散可能な構成とする）を説明したうえで、そのアプローチを AWS 環境でどのように実現するか、DDoS 攻撃対策のベストプラクティスに基づいたアーキテクチャについて説明しました。また。お客様側でアプリケーションレイヤーの DDoS 攻撃からアプリケーションを保護するために利用できる DDoS 攻撃対策の機能として、AWS WAF、AWS Shield Advanced、Amazon CloudFront で利用可能な各種機能をご紹介しています。これらの機能を組み合わせることで、お客様側固有のアプリケーションの保護を実現します。 セッションの最後のセクションでは、DDoS 攻撃への備えと対応ということで、DDoS 攻撃発生時の対応プロセスの整備や DDoS 攻撃検知からの通知フローの例、また、ポストインシデントの対応について、一般的な例を交えて説明しました。 本セッションがお客様のアプリケーションを DDoS 攻撃から保護するための参考になれば幸いです。 4. ランサムウェア対策の実践的アプローチ アマゾン ウェブ サービス ジャパン合同会社 デジタルサービス技術本部 ISV/SaaS ソリューション部 ソリューションアーキテクト　吉田 裕貴 ランサムウェアは企業から金銭を強要するために使用するビジネスモデルであり、感染したパソコンに特定の制限（データの暗号化や削除など）をかけ、その制限の解除と引き換えに金銭を要求するマルウェアです。IPA の情報セキュリティ重大脅威では 10 年連続で 1 位となっており、世界中で被害が増加しています。 ランサムウェアの感染経路は多様化しており、実は従来のメールによる感染は全体の 18% 程度にとどまっています。警視庁サイバー警察局の情報によれば、近年は VPN 機器やリモートデスクトップ機器などのネットワーク機器を介した侵入が増加しています。 ランサムウェアに対する基本的な対策として、以下が重要です： AWS リソースの設定見直し（最小権限の原則、MFA の有効化、AWS Config の使用、適切な暗号化の実装など） コンピュートレイヤーでの継続的な脆弱性管理（定期的な脆弱性スキャン、セキュリティパッチ管理の自動化など） NIST のサイバーセキュリティフレームワークを用いた体系的なアプローチとして「識別」「防御」「検知」「対応」「復旧」の5つのフェーズがあります。これらの活動をAWS のサービスで実現するために、以下の7つのサービスが特に有効です： AWS Config：リソースの構成履歴の記録やコンプライアンス評価 AWS Security Hub：セキュリティチェックの自動化とセキュリティアラートの一元化 Amazon GuardDuty：マネージドな脅威検出サービス Amazon Inspector：コンピューティングリソースの脆弱性チェック AWS Systems Manager：パッチ管理などの自動化 AWS Backup：データバックアップの計画・管理 AWS Well-Architected Tool：セキュリティのベストプラクティス評価 ランサムウェアからのデータ保護には、重要データの特定、アクセス管理、バックアッププランの策定、多層防御の実装、暗号化の適切な設定などが重要です。保護しているバックアップデータに対する改ざんや削除を防ぐための多層防御も不可欠です。 クラウドのメリットを活かしたランサムウェア対策として、GuardDuty による侵入検知、セキュリティグループによる即時の通信遮断、自動化ツールを組み合わせた封じ込めの自動対応などが可能です。 AWS の様々なサービスを活用して、ランサムウェアに強い環境を構築していきましょう。 5. AWS 環境でのセキュリティインシデントレスポンス アマゾン ウェブ サービス ジャパン合同会社 シニアセキュリティソリューションアーキテクト 勝原 達也 本セッションでは、セキュリティインシデントに備え、検知・対応し、素早く封じ込め・回復していく、そのための考え方や活用できる AWS サービスについてご紹介しました。 全てのお客様にとって万が一セキュリティインシデントが発生したとしても、ビジネス影響を最小化できる形で対処したいと考えています。そのためには、平時のうちから有事を想定して、準備を備えていくことが欠かせません。その際、オンプレミスでのナレッジに加え、AWS の特性・オンプレミスとの違いなど考慮しておくことが重要です。 具体的には、実際のオペレーションにおいて重要な「検知と分析」の観点では、AWS が有する優れた可視性に基づいて、様々なログを大規模に取得・保存し、更に分析できることを示しました。また Amazon GuardDuty の活用が重要であることにも触れています。加えて、「封じ込め・根絶・復旧」においては、AWS の特性を踏まえて「適切・効果的な対処」を実現するための考え方に加え、インシデント対応の自動化の事例についてもご紹介しました。さらに、昨今セキュリティインシデントの考え方が幅広くなっており、実際の不審なアクティビティを検知し対処するという従来からあるものに加え、平時のうちからお客様環境に生じる既知脆弱性や設定不備に伴う大きなリスクが生じている状態を把握・改善し、問題の発生を未然に防ぐ継続的なアプローチが大切になってきていることに触れています。 セッション終盤では、効率的・効果的なセキュリティインシデント対応実現を支える新たな選択肢、AWS Security Incident Response という新サービスについて紹介しました。これは、AWS によるお客様環境の監視とアラートのトリアージに加え、AWS のセキュリティエキスパートである AWS Customer Incident Response Team(CIRT) とのコラボレーションを実現するものです。 本セッションでご紹介した考え方や AWS の特性・ツールを活用し、優れたインシデント対応を実現する、そしてビジネス影響を最小化するという目標達成へ向けて取り組んでいきましょう。 おわりに 本セミナーでは、4つのセッションを通じて、AWS を活用した包括的なサイバーセキュリティ対策について幅広い内容をお届けしました。 AWS を活用し、効率的かつ効果的にセキュリティを実現することは、俊敏性と安全性の両立、さらにお客様ビジネスの成長に繋がる AWS は高度化する DDoS 攻撃の脅威からお客様のアプリケーションを保護し、高い可用性を要するシステムの安定稼働を支える AWS のセキュリティサービスを活用し、識別から復旧まで一貫したアプローチでランサムウェアの脅威からお客様環境を保護する AWS 上で実現する高度な検知と対応に加え、AWS のセキュリティエキスパートの支援でインシデントのビジネス影響を最小化する AWS の CISO である Chris Betz は最新の ブログ で「大規模なセキュリティのシンプルな実現」と「イノベーションの加速と現代の脅威に耐え回復性を備えたアプリケーションの構築の両立」の重要性を強調しています。このメッセージは、AWS re:Inforce 2025 の基調講演の内容を先取りしたものとなっています。「セキュリティは最優先事項」であり、AWS は今後も引き続きお客様のセキュリティ強化を支援してまいります。AWS を活用して、ビジネスを安心して加速していただければ幸いです。 この記事は シニア セキュリティ ソリューションアーキテクト勝原達也が担当しました。

はじめに こんにちは、パブリックセクターのお客様向けにプロトタイピングの支援をしている、SA の鈴木です。 早速ですが、みなさま、デジタル庁が提供している、デジタル認証アプリはご存知でしょうか？ 「デジタル認証アプリ」 は、マイナンバーカードを使った本人確認を、安全に・簡単にするためのアプリです。 令和6年（2024年）4月時点で、マイナンバーカードの保有率は70%を越えており、マイナンバーカードの利用シーンが広がっています。「デジタル認証アプリ」は、マイナンバーカードを使った認証や署名を、安全に・簡単にするための、デジタル庁が提供するアプリです。 行政機関や民間事業者は、デジタル庁が提供するデジタル認証アプリと連携する API（デジタル認証アプリサービス API）を活用することで、マイナンバーカードを使った本人確認・認証や電子申請書類への署名機能を簡単に組み込むことができます。 引用元：デジタル認証アプリ – https://services.digital.go.jp/auth-and-sign/business/ デジタル認証アプリと連携する、デジタル認証アプリサービス API を利用すると、EC サイト・ネットバンキングの利用開始時に発生する本人確認や、イベント等での酒類購入時の年齢確認、地域に住んでいる方の住所確認、といったことをマイナンバーカードを用いて行うことができます。 これまでこのような本人確認は、申請書類と共に免許証や健康保険証のコピーを同封し、それら書類を申請先で確認、問題なければ申請が受理される、といった流れで進み、申請が受理されるまで、数日から1週間近くかかっていました。これは郵送による長いリードタイム、手作業による確認作業、とコストが高いものでした。しかし、デジタル認証アプリを利用することで、オンラインで本人確認を済ませることができ、より短時間での申請や、申請確認作業の効率化が可能になります。 本記事のゴール 本記事では、サービスサイトが示す、次の 「認証 API 利用の流れ」 を、Cognito と連携し、実現したいと思います。 本人確認が必要なサービスを企画・開発されている方々向けに、 デジタル認証アプリサービス API と、AWS の Customer Identity and Access Management (CIAM) のサービスである Amazon Cognito の連携の一例として ぜひご確認いただければと思います。 認証 API 利用の流れ（引用元：【民間事業者向け情報】マイナンバーカードで本人の確認を簡単に – https://services.digital.go.jp/auth-and-sign/business/ ） Cognito は ソーシャルなIdentity Provider (IdP) や、Open ID Connect (OIDC) 、Security Assertion Markup Language (SAML) といったサードパーティの IdP を経由した認証が可能です。そのため、Cognito を利用し、OIDC に対応しているデジタル認証アプリサービス API とも連携することが理論上可能です。しかし、デジタル認証アプリサービス API で求められている 実装のガイドライン を満たすには、private key jwt 認証を利用する必要があります。2025年2月現在、Cognito は、private key jwt 認証に非対応です。そのため、今回は client secret の代わりに、private key jwt 認証を Cognito で利用できるようにしたサンプル実装である、 cognito-external-idp-proxy をカスタマイズして利用します。本サンプルは、 ブログ も公開されていますので、まずこちらをご一読いただくことをお勧めします。 目を通していただいた、という前提の上で、先に進めたいと思います。次に示す構成図が cognito-external-idp-proxy を利用した場合の全体構成となります。 また、この構成のシーケンス図は以下のようになります。 ※上記は、 デジタル庁 開発者サイトのシーケンス図：認証 と cognito-external-idp-proxy のドキュメント を元に作成しました。 デジタル認証アプリサービス API の利用にあたって デジタル認証アプリサービス API は、利用にあたり事前に申請が必要です。詳しくは、 デジタル庁が公開しているサービスサイト をご一読いただき、申請してください。申請の際には、申請する企業の情報などが必要になり、特に、システム面で事前に注意すべき項目としては、次に示すものがあります。 private key jwt 認証用の秘密鍵と公開鍵のペア cognito-external-idp-proxy の README に作成手順 が記載されています。 ここで作成した公開鍵をデジタル認証アプリサービス API の利用申請時に提出します。ペアとなる秘密鍵は大事に保管してください。 コールバック URL cognito-external-idp-proxy をデプロイ後に提供される、コールバック関数と接続されている API Gateway のエンドポイントを申請時に提出することになります。 カスタムドメインを利用しない場合、ドメイン名はデプロイ後に決定されます。先んじてデプロイを進めておきましょう。 テストカード/テストカード代替機能の準備 J-LIS に別途申請する必要があります。貸与または購入から選択できます。 今回はテストカードを J-LIS から貸与していただき、検証を行いましたが、テストカード代替機能を用いた検証も可能になったようです。テストカードの管理が煩雑な場合や急ぎ検証したい場合は、この機能の利用も検討ください。 https://developers.digital.go.jp/documents/auth-and-sign/testcard_alternative/ デジタル認証アプリサービス API の実装ガイドラインとサンプルの比較 デジタル認証アプリサービス API を利用するために必要な実装は、 実装のガイドライン （本記事では、2025年3月27日時点を参照） にまとめられています。これを整理し、cognito-external-idp-proxy の実装状況と比較すると、次のような表にまとめることができます。（横長になってしまい、読みづらいですがご容赦ください） 要件 要件詳細 項目分類 項目とその概要 サンプルで実装済みかどうか 本記事で追加・変更するか 実装箇所または、追加実装方針の概要 リダイレクト URI の設定 以下の説明を確認のうえ、デジタル認証アプリサービスへの申込時に、各 RP アプリへのリダイレクト URI を指定してください。 RP がネイティブアプリの場合 iOSは Universal Link、Androidは App Link を指定してください。 悪意のある他アプリによる乗っ取り攻撃の危険があるため、Custom URL Schema は指定しないでください。 RP が WEB アプリの場合 リダイレクト URI に WEB アプリの URI を指定することで、WEB アプリ上で認可レスポンスを取得できます。 RP がブラウザベースアプリの場合 トークンを安全に取り扱うため、BFF アーキテクチャ（Backend For Frontend）を採用してください。 リダイレクト URI に BFF の URI を指定してください。 リダイレクト URI の設定 RP が WEB アプリの場合 リダイレクト URI に WEB アプリの URI を指定することで、WEB アプリ上で認可レスポンスを取得できます。 実装済み いいえ Cognito + cognito-external-idp-proxy の部分を RP として扱うことで、 RP が WEB アプリの場合 と同義として捉えています。 ID トークンの検証 認可コードフローのトークンレスポンスには、ID トークンが含まれています。 ※署名プロセスにおいてクライアントクレデンシャルズフローが扱われる過程がありますが、クライアントクレデンシャルズフローにおいては ID トークンは含まれません。 RP アプリは、利用者認証情報を含む改ざん検知用の署名付きトークンである ID トークンについて、トークンレスポンス取得後に必ず正当性を検証してください。 デジタル認証アプリサービスの JWT の署名アルゴリズムは ES256 です。 JWT はピリオド（”.”）区切りのヘッダ部、ペイロード部、シグネチャー部から構成され、各部位は Base64URL エンコードされています。 検証準備 取得した ID トークンを Base64URL デコードし、ヘッダ部、ペイロード部、シグネチャー部を（”.”）で分割します。 デジタル認証アプリサービスの JWK Set 公開エンドポイントを用いて、デジタル認証アプリサービス内の一連の公開鍵情報を取得します。公開鍵は定期的に更新されるため、ID トークン検証の度に取得してください。 実装済み いいえ Cognito で検証しています。 該当部分の引用です。 ユーザープールは、IdP 設定の発行者 URLs から IdP jwks_uri エンドポイントへのパスを決定し、JSON ウェブキーセット (JWKS) エンドポイントからトークン署名キーをリクエストします。IdP は JWKS エンドポイントから署名キーを返します。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html JWT ヘッダ部の検証 ID トークンヘッダ部の kid が検証準備で取得した公開鍵の kid と一致することを検証してください。 署名のアルゴリズム である alg と、検証準備で取得した公開鍵のアルゴリズムがともに「ES256」になっていることを検証してください。 未実装 はい cognito-external-idp-proxy の token Lambda 関数で実装します。 PyJWT で提供されている関数を用いて、ヘッダ部の検証を行います。 署名の検証 RP アプリでご使用の開発言語や、使用されるライブラリ等によって異なります。 検証の概要を以下に示します。 Base64URL エンコード状態のヘッダ部 + “.” + ペイロード部をデータ部として保持 ・・・変数① Base64URL デコードしたシグネチャー部を保持 ・・・変数② 検証準備で取得した公開鍵を保持 ・・・変数③ アルゴリズムを ES256 として保持 ・・・変数④ 変数①～④を使用し、開発言語または使用されるライブラリで署名を検証 検証結果の正常・異常を判断 実装済み いいえ Cognito で検証しています。 該当部分の引用です。 ID トークンの署名を、プロバイダーのメタデータに基づいて想定される署名と比較します。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html ペイロード部の検証 ID トークンの発行者を示す Issuer Identifierクレーム（iss）が OpenID Provider メタデータの issuer の値と一致することを検証してください。 実装済み いいえ Cognito で検証しています。 該当部分の引用です。 iss クレームを IdP に設定された OIDC 発行者と比較します。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html ID トークンの audience クレーム（aud）に、RP アプリのクライアント ID が含まれていることを検証してください。 実装済み いいえ Cognito で検証しています。 該当部分の引用です。 aud クレームが IdP で設定されているクライアント ID と一致するか、または aud クレームに複数の値がある場合は設定されたクライアント ID が含まれているかを比較します。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html ID トークンの有効期限を示す expiration time クレーム（exp）が、検証時の時間より未来であることを検証してください。 実装済み いいえ Cognito で検証しています。 該当部分の引用です。 exp クレームのタイムスタンプが現在の時刻より前でないことをチェックします。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html ID トークンの発行日時を示す Issued at クレーム（iat）が、 検証時の UNIX タイムスタンプ値 － 所要時間（秒） の値以上であることを検証してください。 所要時間は、RP アプリで決める必要があります。 nonce 保存から RP アプリが ID トークン受け取るまでの時間が目安です。 指定時間を経過していた場合は必要に応じて、RP アプリ側にて再認証を実施するなど、追加処理の実装を検討してください。 未実装 はい cognito-external-idp-proxy の token Lambda 関数で実装します。 PyJWT で提供されている decode 関数で iat クレームを検証しているため、これを利用します。 ID トークンの at_hash クレームについて、以下のとおり検証してください。 アクセストークンを、ID トークンヘッダ部の algorithm クレーム（alg）と同じハッシュアルゴリズムを用いてハッシュ化し、ハッシュ化した結果の左半分のビット群を Base64URL にてエンコードしたうえで、ID トークンの at_hash と値が一致することを確認してください。 未実装 はい cognito-external-idp-proxy の token Lambda 関数で実装します。 PyJWT で提供されている decode 関数から返される ID トークンから at_hash を取得し、アクセストークンから生成した at_hash と比較することで、検証します。 検証失敗時 タイムスタンプの検証で失敗する場合は、有効期限切れや認証時刻が過ぎているため、認証処理を中断し、トークンリフレッシュにて ID トークンの再発行を行ってください。 未実装 いいえ 本記事では実装しませんが、exp, iat, nbf クレームの検証後、有効期限切れであれば、トークンリフレッシュを行うように実装します。 その他の検証で失敗する場合は、ID トークンが改ざんされている可能性があるため、認証処理を中断し、エラー処理等を行ってください。 未実装 はい exp, iat, nbf クレームのタイムスタンプに関する例外以外は、認証失敗でレスポンスを返すよう実装します。 logout トークンの検証 デジタル認証アプリサービスから RP アプリへ back-channel logout リクエストを送信する際、logout トークンを POST パラメータへ含めます。 RP アプリは、logout トークンについて正当性の検証を含めて、利用者とのセッション終了処理を実施してください。 logout トークンの検証 同左 未実装 いいえ 設定が任意のため、今回は省略しますが、本来は RP 側でエンドポイントを実装し、そのエンドポイントのロジックで logout トークンについての正当性の検証とセッション終了処理を実施する必要があります。 ID トークン署名検証用公開鍵のローテーションを考慮した準備 署名を検証するための公開鍵は、暗号漏えいが疑われる場合を想定し、有効期限内であってもローテーションする可能性があります。RP アプリに保持する公開鍵について、キー変更を自動的に処理するように RP アプリを作成してください。 公開鍵のローテーション JWK Set 公開エンドポイント https://auth-and-sign.go.jp/api/realms/main/protocol/openid-connect/certs OpenID Provider Configuration エンドポイント https://auth-and-sign.go.jp/api/realms/main/.well-known/openid-configuration 未実装 はい ID トークンの検証を token Lambda 関数で実装する必要があるため、公開鍵のローテーションについても考慮する必要があります。 PyJWT ライブラリを用いて、リクエストごとに公開鍵を取得します。 ※本記事では、公開鍵のキャッシュは未実装ですが、実際に利用される場合は、公開鍵をキャッシュする仕組みの実装をお勧めいたします。 また、Cognito における検証は以下のようになっています。 該当部分の引用です。 ユーザープールは、IdP 設定の発行者 URLs から IdP jwks_uri エンドポイントへのパスを決定し、JSON ウェブキーセット (JWKS) エンドポイントからトークン署名キーをリクエストします。 IdP は JWKS エンドポイントから署名キーを返します。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/cognito-user-pools-oidc-flow.html Web アプリケーションの脆弱性悪用への対策 悪意のあるリクエストを送信させることを目的とするクロスサイトリクエストフォージェリ（CSRF）への対策をしてください。 検証結果が一致しない場合は CSRF による攻撃の可能性があるため、認証処理を中断し、エラー処理等を行ってください。 RP アプリの対応方法（CSRF） RP アプリは、state というランダムな値を生成して、認可リクエストに設定し、利用者のセッションにもその値を保存してください。 state に設定する値については、別紙の API リファレンスをご参照ください。 実装済み いいえ state は以下のコードで保持するよう実装されています。 https://github.com/aws-samples/cognito-external-idp-proxy/blob/d85fc2bed25627170fe5989b3b8d344d9b1ab860/lambda/authorize/authorize_flow.py#L82 必ず、認可リクエストごとに新しい state 値を生成してください。 実装済み いいえ Cognito がサードパーティー ID プロバイダーへ認可リクエストを送る際に、state を生成しています。 デジタル認証アプリサーバは、認可コードを含むリダイレクトをレスポンスする際に、state の値も RP へレスポンスします。 RP アプリが生成した state と、デジタル認証アプリサーバからリダイレクトで送られた state が一致することを検証してください。 実装済み いいえ https://github.com/aws-samples/cognito-external-idp-proxy/blob/d85fc2bed25627170fe5989b3b8d344d9b1ab860/lambda/callback/callback_flow.py#L65 上記処理でチェックしています。 リプレイ攻撃への対策 利用者のログインセッション確立の際に、攻撃者が ID トークンを置き換えて不正ログインするリプレイ攻撃への対策をしてください。 検証結果が一致しない場合はリプレイ攻撃の可能性があるため、認証処理を中断し、エラー処理等を行ってください。 RP アプリの対応方法（nonce） RP アプリは、nonce というランダムな値を生成して、認可リクエストに設定し、利用者のセッションにもその値を保存してください。 nonce に設定する値については、別紙の API リファレンスをご参照ください。 必ず、認可リクエストごとに新しい nonce 値を生成してください。Client セッションと ID Token を紐づける文字列。リプレイアタック対策に用いられる。 nonce 値は、case-sensitive (大文字と小文字を区別する) である点に留意すること。( OpenID Connect ) リクエスト毎にナンス値を生成し設定する。 code_verifier と同様に、256 ビットのエントロピーを推奨。 未実装 はい cognito-external-idp-proxy の authorize Lambda 関数で、nonce を生成し、DynamoDB で保持するよう実装する必要があります。 合わせて、nonce のレコードに TTL を設定し、nonce が自動的に削除されるようにします。 デジタル認証アプリサーバは、アクセストークン発行レスポンスを返却する際、RP アプリが生成した nonce を含む ID トークンを返却します。 RP アプリは、返却された nonce と自身が生成した nonce が一致することを検証してください。 未実装 はい Cognito は、認可リクエストに nonce パラメータを渡すと ID トークンの nonce パラメータを検証できます。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/authorization-endpoint.html Lambda で認可リクエストを送る際に、nonce パラメータを設定することで検証します。 認可コード横取り攻撃への対策 認可レスポンス受信時のリダイレクト処理における悪意のあるアプリへのなりすまし対策をしてください。 RP アプリの対応方法（PKCE） RP アプリは、認可リクエストに code_challenge、code_challenge_method パラメータを設定してください。 必ず、認可リクエストごとに新しい code_challenge 値を生成してください。 code_challenge の生成方法となる code_challenge_method の値については、必ず「S256」を指定してください。 code_challenge および code_challenge_method に設定する値の詳細については、 別紙の API リファレンスをご参照ください。 デジタル認証アプリサービスでは、渡された code_challenge、code_challenge_method のほかに、code_verifier を用いて検証を行い、正規のリクエストに対してのみアクセストークンを発行します。 実装済み いいえ https://github.com/aws-samples/cognito-external-idp-proxy/blob/d85fc2bed25627170fe5989b3b8d344d9b1ab860/lambda/authorize/authorize_flow.py#L66 上記から、トランザクションごとに code_verifier を発行していることがわかります。method も S256 になっています。 アクセストークン置き換え攻撃への対策 攻撃者がアクセストークンを置き換えて利用者になりすます攻撃の対策をしてください。 ID トークンのペイロードに含まれる at_hash を用いて、アクセストークンの置き換え対策のための検証を行ってください。 詳細な検証方法については以下をご参照ください。 参考：ペイロード部の検証 アクセストークン置き換え攻撃への対策 同左 未実装 はい cognito-external-idp-proxy の token Lambda 関数で実装する必要があります。 ログの保持 デジタル認証アプリサービスでは、API 実行ログの提供は行いません。 問題が発生した際の原因や影響範囲の調査を行えるよう、API 実行ログは RP アプリ内で一定期間保存してください。 内部ストレージからの漏洩対策のため、後述の保護対象のデータに記載されている情報は、ログの保存対象にしないでください。 ログの保持 同左 実装済み いいえ APIGateway と Lambda のログは取得されています。 ただし、既存設定は Amazon CloudWatch Logs のログの保持期間が5日間であるため、自社のガバナンスポリシーに合わせた修正が必要になる可能性があります。 プラットフォーム事業者に必要とされる証明書暗号対応 民間事業者が、デジタル認証アプリの署名 API を利用する場合、公的個人認証法に基づく大臣認定事業者（プラットフォーム事業者）と連携して電子署名の検証及び電子証明書の有効性確認を行う必要があります。 電子証明書の保持及び電子証明書の発行番号の取得・保持は、プラットフォーム事業者には認められていますが、プラットフォーム事業者に電子署名の検証等を委託する事業者（サービス提供事業者：SP 事業者）には認められていないため、署名APIの利用申込みを行う SP 事業者、連携するプラットフォーム事業者に以下の対応をお願い申し上げます。 民間事業者が署名 API を利用する場合、この対応は必須となります。 利用までの流れ SP 事業者は、事前準備契約の申込書に対象となるサービスと連携するプラットフォーム事業者を記入します。（自社がプラットフォーム事業者であり、連携する事業者の役割を兼ねる場合は自社名を記入してください。プラットフォーム事業者に電子署名の検証等を委託する場合は委託先のプラットフォーム事業者名を記入してください。） ※暗号化用公開鍵の登録はサービス単位で行います。テスト環境と本番環境は別の鍵をご用意ください。 テスト環境・本番環境の設定にあたり、デジタル庁から対象のプラットフォーム事業者に対して暗号化に用いる公開鍵の登録を依頼します。 プラットフォーム事業者はサービスごとに鍵を生成しサービス名と公開鍵をデジタル庁に登録します。 デジタル庁は SP 事業者に対象となるサービスにおける公開鍵登録完了を連絡します。 未実装 いいえ – 署名用電子証明書と署名値の暗号化について ECDH-ES の暗号化方式で署名用電子証明書と署名値を暗号化してデジタル認証サーバからプラットフォーム事業者側へ返却します。以下にデジタル認証サーバでの暗号化処理の概要を示します。 署名用電子証明書と署名値を暗号化するための鍵ペア（秘密鍵、公開鍵）を生成します。 生成した秘密鍵と取得したプラットフォーム事業者公開鍵で共有鍵を生成します。 署名用電子証明書と署名値を Base64 エンコードします。 署名用電子証明書と署名値を共有鍵により暗号化し、JWE Compact Serialization 形式にシリアライズします。 生成した公開鍵、暗号化した署名用電子証明書および署名値を返却します。 未実装 いいえ – データの保護 クロスサイトスクリプティング（XSS）やクロスサイトリクエストフォージェリ（CSRF）を受けて、RP アプリのキャッシュや内部ストレージ等から直接アクセストークンや利用者のプライバシー情報が窃取された場合を想定する必要があります。 アクセストークン・利用者のプライバシー情報をRPアプリで安全に保持するよう暗号化を行い、セキュアなストレージへ保管し、利用する際に復号する等のデータ漏洩対策をしてください。 トークン関連 private_key_jwt 認証方式における秘密鍵 実装済み はい AWS Secrets Manager で保管しています。 アクセストークン 実装済み はい Cognito や Lambda のメモリで保持されます。 リフレッシュトークン 実装済み はい Cognito や Lambda のメモリで保持されます。 IDトークン 実装済み はい Cognito や Lambda のメモリで保持されます。 認可エンドポイント関連 認可コード 実装済み はい サンプルが作成する DynmaoDB で保管します。TTL をつけているため、有効期限が来ると、5分後に自動的に削除されます。（5分はサンプルで定義しているデフォルト値です。必要に応じて変更してください。） 署名トランザクション結果取得エンドポイント関連 署名用電子証明書情報 未実装 いいえ – UserInfo エンドポイント関連 利用者識別子 実装済み はい Cognito の属性マッピングで連携され、Cognito のユーザープールで保管されます。 氏名 実装済み はい Cognito の属性マッピングで連携され、Cognito のユーザープールで保管されます。 住所 実装済み はい Cognito の属性マッピングで連携され、Cognito のユーザープールで保管されます。 生年月日 実装済み はい Cognito の属性マッピングで連携され、Cognito のユーザープールで保管されます。 性別 実装済み はい Cognito の属性マッピングで連携され、Cognito のユーザープールで保管されます。 それでは、次から、各要件ごとに、どのようにカスタマイズすべきか、みていきましょう。 準備：利用するライブラリの変更 サンプルで利用している python-jwt ライブラリは、ヘッダ部の kid の検証や iat クレームの検証が実装されていないため、 PyJWT に変更します。変更したことによって、private key jwt 認証の処理に関する部分を修正する必要があります。今回は PyJWT を利用しましたが、読者の方々が実装される際は、ご自身の環境に合わせてライブラリをお選びください。また、ライブラリを変更する場合は、 Layer の更新手順 に従い、 Layer を忘れずに更新してください。 ID トークンの検証（JWT ヘッダ部の検証） ID トークンの検証は、 ID トークンを取得する処理が記述されている、token Lambda 関数を更新します。 PyJWT では、ID トークン署名検証用公開鍵を取得するための関数 が用意されており、取得した ID トークンに含まれる kid の ID に最適な公開鍵を取得します。kid の ID に一致する公開鍵を取得する、ということは、JWT ヘッダ部の検証の要件である、 「ID トークンヘッダ部の kid が検証準備で取得した公開鍵の kid と一致することを検証してください。」  を満たすことがわかります。実際のコードは、 cognito-external-idp-proxy/lambda/token/token_flow.py の 186 行目 の直後に、以下のように追記します。 print("+++ VERIFYING ID TOKEN +++") id_token = json.loads(data)["id_token"] print("+++ GET JWKS +++") jwks_client = jwt.PyJWKClient(config["jwks_uri"]) signing_key = jwks_client.get_signing_key_from_jwt(id_token) ID トークンの検証（JWT ヘッダ部の検証とペイロード部の検証） ここでは、ヘッダ部の検証の要件である、 「署名のアルゴリズム である alg と、検証準備で取得した公開鍵のアルゴリズムがともに「ES256」になっていることを検証してください。」 と、 ペイロード部の検証の要件である、 「iat クレーム」 、 「at_hash クレーム」 の検証を実装します。 まず、iat クレームについてです。 PyJWT は、ID トークンのデコード関数で iat クレームの検証をデフォルトで行います。ただし、要件に 「所要時間は、RP アプリで決める必要があります。」 とあるように、所要時間をパラメータとして渡す必要があります。トークンが発行されてから検証を行うまでの所要時間を定義すれば良いので、今回は 60 秒程度とします。ここはそれぞれの環境で適した時間を設定ください。 実際のコードは、以下のようになります。JWT ヘッダ部の kid の検証で取得した公開鍵 (signing_key) も一緒に渡します。このコードでは、念の為、iss クレームと aud クレームも検証するように、必要なパラメータを渡しています。 cognito-external-idp-proxy/lambda/token/token_flow.py の signing_key = jwks_client.get_signing_key_from_jwt(id_token) の直後に以下を記述します。 try: decoded_id_token = jwt.decode( id_token, signing_key, # kid の検証時に取得した公開鍵 leeway=60, # 所要時間に 60 秒を設定 issuer=config["idp_issuer_url"], # iss クレームの検証 audience=config["client_id"], # aud クレームの検証 algorithms=["ES256"]) 続いて、at_hash クレームの検証を実装します。 at_hash クレームは、要件にある通り、 「アクセストークンを、ID トークンヘッダ部の algorithm クレーム（alg）と同じハッシュアルゴリズムを用いてハッシュ化し、ハッシュ化した結果の左半分のビット群を Base64URL にてエンコードした値」 です。 繰り返しになりますが、まず、（①）トークンエンドポイントから取得したデータから、アクセストークンを取得・検証し、（②）sha256 でハッシュ化します。続いて、（③）ハッシュ化した値の左半分のビット群を Base64URL でエンコードし、at_hash を生成します。最後に、（④）生成した at_hash とデコードした ID トークンに含まれる at_hash を比較し、同じ値であることを確認します。 cognito-external-idp-proxy/lambda/token/token_flow.py の 上記デコード処理の直後に以下を記述します。 access_token = json.loads(data)["access_token"] # ①アクセストークンの取得 jwt.decode( access_token, signing_key, algorithms=["ES256"]) # アクセストークンの検証 hashed_access_token = hashlib.sha256(access_token.encode()).digest() # ② calculated_at_hash = base64.urlsafe_b64encode(hashed_access_token[:len(hashed_access_token)//2]).decode('utf-8').rstrip('=') # ③ # ④ if decoded_id_token['at_hash'] != calculated_at_hash: print("at_hash mismatch") return { "statusCode": 400 } リプレイ攻撃への対策 要件では、リプレイ攻撃への対策として nonce の利用が求められています。 今回は、authorize Lambda 関数でリクエストごとに nonce を生成し、認可リクエストに設定し、DynamoDB の state テーブルと code テーブルで nonce を一定期間保持し、token Lambda 関数で検証します。 まず、authorize Lambda 関数で nonce を生成する処理の実装です。ここでは、Secrets Manager のクライアントを用いて、ランダムパスワードを生成し、その乱数を nonce のフォーマットに合うように変換します。 以下のコードを cognito-external-idp-proxy/lambda/authorize/authorize_flow.py の 77 行目 あたりに追加します。 nonce_random = SM_CLIENT.get_random_password( PasswordLength=64, ExcludePunctuation=True, IncludeSpace=False ) nonce_random = nonce_random["RandomPassword"] nonce = hashlib.sha256(nonce_random.encode("utf-8")).digest() nonce = base64.urlsafe_b64encode(nonce).decode('utf-8') nonce = nonce.replace('=', '') RP で生成した nonce を state テーブルで管理するため、state や code_verifier を格納する処理で合わせて state テーブルに格納するように、 cognito-external-idp-proxy/lambda/authorize/authorize_flow.py の 82 行目のコード を書き換えます。 DYNAMODB_CLIENT.put_item( TableName = config["state_table"], Item = { "state": { "S": str(hashed_state) }, "code_verifier": { "S": code_verifier }, "ttl": { "N": str(state_ttl) }, # Add "nonce": { "S": nonce } } ) そして、デジタル認証アプリサービス API の認可エンドポイントのパラメータとして設定します。 ここでは、cognito-external-idp-proxy の実装には存在しないパラメータである、 acr_values も合わせて設定します。（参照：認可エンドポイントのリクエストパラメータ、 https://developers.digital.go.jp/documents/auth-and-sign/authserver/ ） cognito-external-idp-proxy/lambda/authorize/authorize_flow.py の 100 行目あたり に以下のコードを追加します。 params["nonce"] = nonce params["acr_values"] = "aal3 crl" デジタル認証アプリサービス API からのレスポンスに、nonce は含まれていても、state は含まれていません。このままでは state テーブルから、RP が生成した nonce を取得できず、レスポンスに含まれる nonce を検証できません。そこで、callback Lambda 関数で、state テーブルの nonce を、code テーブルに格納し、token Lambda 関数で、code をキーに、nonce を取得するため、 cognito-external-idp-proxy/lambda/callback/callback_flow.py の 81 行目 の code テーブルへの追加処理を以下のように変更します。 DYNAMODB_CLIENT.put_item( TableName = config["auth_code_table"], Item = { "auth_code": { "S": config["auth_code"] }, "code_verifier": { "S": code_verifier }, # Add "nonce": { "S": state_result["Item"]["nonce"]["S"] }, "ttl": { "N": str(code_ttl) } } ) これで RP が生成した nonce を token Lambda 関数で取得する準備が整いました。 最後に、 cognito-external-idp-proxy/lambda/token/token_flow.py の 122 行目 の直後に、以下のコードを追加し、code テーブルから取得した nonce を変数に格納します。 nonce = code_result["Item"]["nonce"]["S"] デコードした ID トークンの検証後（ if decoded_id_token['at_hash'] != calculated_at_hash: での検証後）に、以下のコードを追加し、変数に格納した nonce の値（ RP で生成したもの）と ID トークンに含まれる nonce の値（デジタル認証アプリサービスのレスポンス）が等しいかを検証します。 if decoded_id_token["nonce"] != nonce: print("Nonce mismatch") return { "statusCode": 400 } # トークンの検証時に例外が発生したら、認証失敗とするための例外処理 except Exception as e: return { "statusCode": 400 } アクセストークン置き換え攻撃への対策 この要件は、ID トークンのペイロード検証時に、 at_hash クレームの検証を行なっているため、対策済みとなります。 SPA やバックエンドで必要な実装 これまでの実装で、デジタル認証アプリサービス API を通じて、認証を行うことができるようになりました。実際のサービスでは、この認証後に発行される Cognito のトークンを用いて、サービスの API に対する認可処理を行い、さまざまな処理を実行することになります。 今回のデモでは、Cognito のユーザ属性から生年月日を確認し、20歳以上かどうか判断するという一連の流れを、React と Amazon API Gateway と COGNITO_USER_POOLS タイプのオーソライザー（オーソライザー）を利用して実装したいと思います。React からは Cognito のアクセストークンを送信し、オーソライザーでアクセストークンに含まれるスコープ（ custom/read:age )を検証し、API の利用可否を判断（認可）します。 このアクセストークンに含まれるスコープは、独自で Cognito に設定した、デモ用に作成した API のためのスコープです。具体な実装は、この後の 「CDK の実装例」 で示しています。 SPA の実装 今回は、Cognito のコンソールで紹介されているサンプル実装を利用します。利用するライブラリは、 oidc-client-ts ライブラリと react-oidc-context ライブラリです。SPA における OIDC の利用で論点になるのは、トークンのハンドリング方法ですが、これは各サービスのポリシーに合わせ、BFF や、Custom Storage などの採用をご検討ください。 本実装はあくまでサンプルです。 InMemoryWebStorage を利用することでページリロード時のユーザ体験が損なわれてしまう点や、環境変数やバックエンドとの接続設定や、API 呼び出しの処理など、皆様がご利用される際には、本番環境向けに、適切に実装してください。 実装例 – main.tsx import React from "react"; import ReactDOM from "react-dom/client"; import App from "./App"; import { AuthProvider } from "react-oidc-context"; import "./index.css"; import { InMemoryWebStorage, WebStorageStateStore } from "oidc-client-ts"; const cognitoAuthConfig = { authority: "https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_XXXXXXXXXX", client_id: "xxxxxxxxxxxxxxxxxx", redirect_uri: "http://localhost:5173", // デモアプリのため、localhostで実装しています。 response_type: "code", scope: "custom/read:age openid", automaticSilentRenew: true, silentRedirectUri: "http://localhost:5173", // デモアプリのため、localhostで実装しています。 onSigninCallback: () => { window.history.replaceState({}, document.title, window.location.pathname); }, userStore: new WebStorageStateStore({ store: new InMemoryWebStorage() }), }; const root = ReactDOM.createRoot(document.getElementById("root")!); root.render( <React.StrictMode> <AuthProvider {...cognitoAuthConfig}> <App /> </AuthProvider> </React.StrictMode> ); 実装例 – App.tsx 今回は、 RFC6750 に従い、アクセストークンを指定し、オーソライザーでスコープによるアクセス制御を実現します。 参考： リソースサーバーを使用したスコープ、M2M、および API import { useCallback, useEffect, useState } from "react"; import { useAuth } from "react-oidc-context"; import AppIcon from "../public/App-Icon_White.svg"; function App() { const auth = useAuth(); const [isLoading, setIsLoading] = useState(true); const [isOver20, setIsOver20] = useState(false); const signOutRedirect = () => { const clientId = "xxxxxxxxxxxxxxxxxxxxxxxx"; const logoutUri = "http://localhost:5173"; const cognitoDomain = "https://xxxxxxxxxx.auth.ap-northeast-1.amazoncognito.com"; window.location.href = `${cognitoDomain}/logout?client_id=${clientId}&logout_uri=${encodeURIComponent(logoutUri)}`; }; const ageCheck = useCallback(async() => { try { const res = await fetch("https://xxxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/prod/api/age-check", { method: "GET", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${auth.user?.access_token}`, // アクセストークンを指定する }, }); if (res.ok) { const data = await res.json(); setIsOver20(Boolean(data.isOver20)); setIsLoading(false); } } catch(error) { console.error("Error was happend:", error); } }, [auth.user?.access_token]) useEffect(() => { if (auth.isAuthenticated) { ageCheck(); } }, [auth.isAuthenticated, ageCheck]) if (auth.isLoading) { return <div>Loading...</div>; } if (auth.error) { return <div>Encountering error... {auth.error.message}</div>; } return ( <div className="flex flex-col items-center justify-center h-screen"> <h1 className="text-2xl mb-20">デジタル認証アプリ デモ on AWS</h1> <> {auth.isAuthenticated ? ( <> <pre> {auth.user?.profile.name} さんは、 {isLoading ? "読み込み中..." : isOver20 ? "20歳以上です。" : "20歳未満です。"} </pre> <button className="mt-4 flex justify-center items-center bg-digital-agency-blue-default text-white px-4 py-2 rounded-md hover:bg-digital-agency-blue-hover active:bg-digital-agency-blue-active focus:outline-none focus:ring-2 focus:ring-[#0017C1] focus:ring-opacity-50" onClick={() => signOutRedirect()}> ログアウト </button> </> ) : ( <> <div className="text-center">本人確認のため、デジタル庁が提供するデジタル認証アプリを利用します。</div> <button className="mt-4 flex justify-center items-center bg-digital-agency-blue-default text-white px-4 py-2 rounded-md hover:bg-digital-agency-blue-hover active:bg-digital-agency-blue-active focus:outline-none focus:ring-2 focus:ring-[#0017C1] focus:ring-opacity-50" onClick={() => auth.signinRedirect()}> <img src={AppIcon} alt="App Icon" className="mr-4 w-6 h-6 fill-white" /> マイナンバーカードでログイン </button> </> )} </> <footer className="absolute right-0 left-0 bottom-0 bg-gray-100 w-full"> <div className="flex justify-center space-x-4"> <pre>サービスについて</pre> <pre>利用規約</pre> <pre>ポリシー</pre> </div> </footer> </div> ); } export default App アプリのデザインについて デジタル認証アプリを利用するアプリケーションには、デザインガイドラインも示されています。フロントエンドアプリケーションは、こちらに従うようにしてください。 https://developers.digital.go.jp/documents/auth-and-sign/design-guideline/ バックエンドの実装 前述の通り、API Gateway と オーソライザー、Lambda で API とその認可処理を実装します。今回実装したサンプルのバックエンドでは、トークンベースでアクセス制御、つまりトークン所有者による代理アクセスとして、バックエンドが保持するユーザー情報を特定、照合することで、データにアクセスしているユーザーが、本当にそのデータのユーザーであるかを検証しています。 CDK の実装例 バックエンド用のコンストラクトを次のように作成します。このコンストラクトを PjwtWithPkceStack から呼び出してください。 construct の実装例（ファイルは、 cognito-external-idp-proxy/cdk/construct/backend.py のように追加します）は次のようになります。 from aws_cdk import ( aws_apigateway as _apigw, aws_lambda as _lambda, aws_cognito as _cognito, aws_iam as _iam, Duration, ) from constructs import Construct from cdk_nag import NagSuppressions class Backend(Construct): def __init__(self, scope: Construct, id: str, user_pool: _cognito.UserPool, oauth_scopes: list[str], **kwargs): super().__init__(scope, id) # Create API Gateway with CORS self.api = _apigw.RestApi( self, "BackendApi", rest_api_name="Backend API", description="API Gateway with COGNITO_USER_POOLS type authorizer and custom scopes", default_cors_preflight_options=_apigw.CorsOptions( allow_origins=["http://localhost:5173"], allow_methods=["GET", "OPTIONS"], allow_headers=["Content-Type", "X-Amz-Date", "Authorization", "X-Api-Key", "X-Amz-Security-Token", "X-Amz-User-Agent"], max_age=Duration.days(1) ) ) # Create an authorizer of the type of COGNITO_USER_POOLS auth = _apigw.CognitoUserPoolsAuthorizer( self, "CognitoUserPoolsAuthorizer", cognito_user_pools=[user_pool] ) # Create age_check Lambda function age_check_lambda = _lambda.Function( self, "AgeCheckFunction", runtime=_lambda.Runtime.PYTHON_3_10, handler="age_check.handler", code=_lambda.Code.from_asset("./lambda/age_check"), timeout=Duration.seconds(30), environment={ "USER_POOL_ID": user_pool.user_pool_id } ) age_check_lambda.add_to_role_policy( _iam.PolicyStatement( effect=_iam.Effect.ALLOW, actions=["cognito-idp:AdminGetUser"], resources=[user_pool.user_pool_arn] ) ) # Create API resources and methods api_resource = self.api.root.add_resource("api") age_check_resource = api_resource.add_resource("age-check") # Add method with authorization age_check_get_method = age_check_resource.add_method( "GET", _apigw.LambdaIntegration(age_check_lambda), authorizer=auth, authorization_type=_apigw.AuthorizationType.COGNITO, authorization_scopes=["custom/read:age"] # Custom scope for age check ) # Grant Lambda permissions to be invoked by API Gateway age_check_lambda.add_permission( "ApiGatewayInvoke", principal=_iam.ServicePrincipal("apigateway.amazonaws.com"), source_arn=age_check_get_method.method_arn ) # Create custom resource scope age_check_scope = _cognito.ResourceServerScope( scope_name="read:age", scope_description="Permission to access age check endpoint" ) # Create resource server for custom scopes resource_server = user_pool.add_resource_server( "ResourceServer", identifier="custom", scopes=[age_check_scope] ) # Add custom scope to OAuth scopes oauth_scopes.append(_cognito.OAuthScope.resource_server(resource_server, age_check_scope)) """ SUPPRESSION RULES FOR CDK_NAG """ NagSuppressions.add_resource_suppressions( self.api, [ { "id": "AwsSolutions-APIG2", "reason": "This is demo api. There is no request parameters for this API."} ] ) NagSuppressions.add_resource_suppressions( self.api.deployment_stage, [ { "id": "AwsSolutions-APIG1", "reason": "This is demo api. Logging of APIGW is not necessary. Instead, Lambda turned on logging."}, { "id": "AwsSolutions-APIG3", "reason": "This is demo api. This is protected by COGNITO_USER_POOLS authorizer. It's enough for dev env. If you go to production, you have to attach WAF."}, { "id": "AwsSolutions-APIG6", "reason": "This is demo api. Logging of APIGW is not necessary. Instead, Lambda turned on logging."} ] ) NagSuppressions.add_resource_suppressions( age_check_lambda.role, [ { "id": "AwsSolutions-IAM4", "reason": "Managed policies were used by CDK automatically. Managed policies make CDK simple."} ] ) NagSuppressions.add_resource_suppressions( age_check_lambda, [ { "id": "AwsSolutions-L1", "reason": "Runtime version followed cognito-external-idp-proxy's runtime version."} ] ) Lambda の実装例 import boto3 import json from datetime import datetime import os headers = { 'Access-Control-Allow-Origin': 'http://localhost:5173', 'Access-Control-Allow-Headers': 'Content-Type', 'Access-Control-Allow-Methods': 'OPTIONS,GET' } def get_birthdate(username): """ Get custom:birth attribute by cognito AdminGetUser api """ try: cognito = boto3.client('cognito-idp') response = cognito.admin_get_user( UserPoolId = os.environ.get('USER_POOL_ID'), Username = username ) # Get value when match UserAttributes Name is custom:birth birthdate:str = next((attr['Value'] for attr in response['UserAttributes'] if attr['Name'] == 'custom:birth'), None) return birthdate except Exception as e: raise ValueError(f"Error getting birthdate: {str(e)}") def calculate_age(birthdate_str): """ Calculate age from birthdate string in YYYYMMDD format """ try: birthdate = datetime.strptime(birthdate_str, '%Y%m%d') today = datetime.now() age = today.year - birthdate.year - ((today.month, today.day) < (birthdate.month, birthdate.day)) return age except ValueError as e: raise ValueError(f"Invalid birthdate format. Expected YYYY-MM-DD, got: {birthdate_str}") def handler(event, context): """ Lambda function to check age from claims in the JWT token and verify if user is over 20 """ try: print("+++ event +++") print(event) # Get the claims from the authorizer context claims = event['requestContext']['authorizer']['claims'] # Check if sub claim exists if 'username' not in claims: return { 'statusCode': 400, 'headers': headers, 'body': json.dumps({ 'message': 'sub claim not found in token' }) } # Calculate age and check if over 20 birthdate = get_birthdate(claims['username']) if birthdate is None: return { 'statusCode': 400, 'headers': headers, 'body': json.dumps({ 'message': 'This user is not found in userpool.' }) } age = calculate_age(birthdate) is_over_20 = age >= 20 return { 'statusCode': 200, 'headers': headers, 'body': json.dumps({ 'isOver20': is_over_20, }) } except Exception as e: return { 'statusCode': 500, 'headers': headers, 'body': json.dumps({ 'message': f'Error processing request: {str(e)}' }) } 属性マッピングの修正 認証後にデジタル認証アプリサービス API から取得できる券面情報（基本4情報）をマッピングしたい場合、 name , gender , address は Cognito の標準の属性が利用できますが、 birthdate は 10 桁の YYYY-mm-dd フォーマットである必要があるため、この API で提供されるデータ形式と異なり、エラーとなってしまいます。そこで、UserPool 作成時に、カスタム属性として custom:birthdate を追加し、ログイン時にこのカスタム属性に券面情報の生年月日を連携します。これを行うには、以下のように CDK のソースコードを修正します。 UserPool へのカスタム属性の追加 生年月日をマッピングしたい場合だけ、追加してください。 cognito-external-idp-proxy/cdk/pjwt_with_pkce_stack.py の 346行目 を以下のように更新してください。 # Cognito User Pool base configuration cognito_user_pool = _cognito.UserPool(self, "UserPool", custom_attributes={"birth": _cognito.StringAttribute(mutable=True, max_len=8, min_len=8)} ) カスタム属性のマッピング また、基本 4 情報を全てマッピングする場合は、以下のように修正してください。（不要な属性はマッピング対象から除外してください。） cognito-external-idp-proxy/cdk/pjwt_with_pkce_stack.py の 350行目 を以下のように更新してください。 cognito_user_pool_idp_oidc = _cognito.UserPoolIdentityProviderOidc( self, "IdentityProvider", client_id = self.node.try_get_context("idp_client_id"), client_secret = self.node.try_get_context("idp_client_secret"), issuer_url = idp_issuer_url, user_pool = cognito_user_pool, attribute_request_method = _cognito.OidcAttributeRequestMethod.GET, attribute_mapping = _cognito.AttributeMapping( address = _cognito.ProviderAttribute.other("address"), fullname = _cognito.ProviderAttribute.other('name'), gender = _cognito.ProviderAttribute.other("gender"), custom = { "custom:birth": _cognito.ProviderAttribute.other("birthdate"), } ), endpoints = _cognito.OidcEndpoints( authorization = apigw_proxy_route_auth_uri, jwks_uri = idp_issuer_url + self.node.try_get_context("idp_keys_path"), token = apigw_proxy_route_token_uri, user_info = idp_issuer_url + self.node.try_get_context("idp_attributes_path") ), name = self.node.try_get_context("idp_name"), scopes = self.node.try_get_context("idp_scopes").split() ) Tips Cognito はカスタム属性をキーに検索できないため、カスタム属性をキーに検索したい要件があれば、外部のデータストア（Amazon DynamoDB など）に券面情報を保存することをご検討ください。 デプロイ方法 ここまで実装お疲れ様でした。この後はデプロイを行い、動作を確認していきます。 cognito-external-idp-proxy のカスタマイズが完了し、デジタル認証アプリのサンドボックス環境の準備が整っていることを確認し、以下のようにパラメータを設定の上、cognito-external-idp-proxy の README の手順に沿ってデプロイします。 { "api_version": "v1", "api_authn_route": "/oauth2/authorize", "api_callback_route": "/callback", "api_token_route": "/oauth2/token", "idp_attributes_path": "/protocol/openid-connect/userinfo", "idp_auth_path": "/protocol/openid-connect/auth", "idp_keys_path": "/protocol/openid-connect/certs", "idp_token_path": "/api/realms/main/protocol/openid-connect/token", "idp_client_id": "xxxxxxxxxxxxxxxxxxxxxxxx", "idp_client_secret": "secret", "idp_issuer_url": "https://sb-auth-and-sign.go.jp/api/realms/main", "idp_name": "digital-auth-and-sign", "idp_scopes": "openid name address birthdate gender", "pkce": true, "stack_name": "CognitoExternalIdpProxyStack", "userpool_allowed_callback_url": "http://localhost:5173" } 無事デプロイが終われば、J-LIS より貸与された、または購入したテストカードを利用し、動作確認を行います。 動作確認 それでは、デジタル認証アプリでのログインと券面情報（ユーザの情報、基本４情報）が取れるか、取得したアクセストークンを用いて年齢確認 API にリクエストを送り、20 歳以上かどうか判定するデモを、動画でご覧ください。 SPA に表示されている、 「マイナンバーカードでログイン」 をクリックすると、デジタル認証アプリが提供するサービスページに遷移し、デジタル認証アプリのログインシーケンスが始まります。 QR コードが表示されますので、これをスマートフォンで読み取ると、スマートフォンにインストールされたデジタル認証アプリが起動し、マイナンバーカードによるログインを求められます。 ログインが成功すると、先ほどまでデジタル認証アプリのサービスページが表示されていたタブは、リダイレクトし SPA のログイン後画面に遷移します。券面情報は、Cognito の属性マッピングにより、Cognito へ連携されているため、Cognito の API から取得でき、SPA 上に表示することができます。 Cognito へ属性マッピングされた券面情報は、引き続き、自社のサービスで利用することができます。今回は、アクセストークンの sub クレームから取得したユーザー ID をキーに、Cognito に登録された生年月日を GetAdminUser API で取得し、ログインしたユーザーが 20 歳以上か判定する処理を実装しました。 このようにデジタル認証アプリサービス API を利用し、自社のサービスをより高度に・高価値にしていくことができることでしょう。 終わりに いかがでしたでしょうか。本記事では、デジタル認証アプリサービス API を利用し、Cognito と連携するための実装方法を紹介しました。 皆様が実装を行う際には、利用予定のユーザの認証リクエストの予測数から、AWS 側の API のクォータ（本サンプルでは、Cognito の GetAdminUser API や、Secrets Manager の GetRandomPassword API を利用します）を確認し、問題なくサービス提供できるよう設計ください。 本人認証や本人確認は、サービスを提供する上でなくてはならないものであり、一連の体験は、お客様の満足度向上に大きく寄与する部分です。JPKI を利用した認証により、サービスの利便性を向上させることはこのデジタル社会では不可欠ですので、ぜひご活用いただければと思います。 著者 鈴木 陽三 (Yozo Suzuki) アマゾン ウェブ サービス ジャパン合同会社 プロトタイプ ソリューション アーキテクト 好きなAWSのサービスは、AWS CDK と AWS IAM Identity Center 趣味は、マンガを読むことと、カメラで娘の写真を撮ること

本稿は 2025 年 5 月 16 日 に AWS Open Source Blog で公開された “ Introducing Strands Agents, an Open Source AI Agents SDK ” を翻訳したものです。 2025 年 5 月 16 日、 Strands Agents のリリースを発表でき、嬉しく思います。Strands Agents は、わずか数行のコードで AI エージェントを構築・実行するモデル駆動型アプローチを採用したオープンソース SDK です。Strands は、シンプルなエージェントのユースケースから複雑なものまで、そしてローカル開発から本番環境でのデプロイまで対応します。AWS の複数チームが既に本番環境で AI エージェントに Strands を使用しており、これには Amazon Q Developer、AWS Glue、VPC Reachability Analyzer などが含まれます。今回、皆様が独自の AI エージェントを構築できるよう Strands について共有したいと思います。 開発者がエージェントに複雑なワークフローを定義する必要があるフレームワークと比較して、Strands は最先端モデルの計画、思考の連鎖、ツール呼び出し、リフレクションの機能を活用することでエージェント開発を簡素化します。Strands では、開発者はプロンプトとツールのリストをコードで定義するだけでエージェントを構築し、ローカルでテストしてクラウドにデプロイできます。Strands は、DNA の二重らせんのように、モデルとツールというエージェントの 2 つの核となる部分を結びつけます。Strands はモデルの高度な推論機能を使用してエージェントの次のステップを計画し、ツールを実行します。より複雑なエージェントのユースケースでは、開発者は Strands でエージェントの動作をカスタマイズできます。例えば、ツールの選択方法を指定し、コンテキストの管理方法をカスタマイズし、セッション状態とメモリの保存場所を選択し、マルチエージェントアプリケーションを構築できます。Strands はどこでも実行でき、Amazon Bedrock、Anthropic、Ollama、Meta、また LiteLLM 経由で利用できるその他のプロバイダーを含め、推論とツール使用機能を持つあらゆるモデルをサポートします。 Strands Agents はオープンコミュニティであり、Accenture、Anthropic、Langfuse、mem0.ai、Meta、PwC、Ragas.io、Tavily などの複数の企業がサポートと貢献で参加してくれることを嬉しく思います。例えば、Anthropic は既に Anthropic API を通じてモデルを使用するための Strands サポートを提供しており、Meta は Llama API を通じた Llama モデルのサポートを追加しています。ぜひ GitHub にアクセスして Strands Agents プロジェクトへの貢献にご協力ください！ エージェント構築の道のり 私は主に、ソフトウェア開発のための生成 AI アシスタントである Amazon Q Developer の開発に取り組んでいます。私のチームでは、オリジナルの ReAct (Reasoning and Acting) 論文 が公開された 2023 年初頭頃に AI エージェントの構築を開始しました。この論文は、大規模言語モデルが推論、計画、そして環境での行動が可能であることを示しました。例えば、LLM はタスクを完了するために API 呼び出しが必要であることを推論し、その API 呼び出しに必要な入力を生成できます。その後、大規模言語モデルが複雑なソフトウェア開発や運用トラブルシューティングを含む多くの種類のタスクを完了するエージェントとして使用できることを私たちは理解しました。 当時、LLM は一般的にエージェントのように動作するよう訓練されていませんでした。主に自然言語による会話のために訓練されることが多かったのです。LLM を使って推論と行動を成功させるには、ツールの使用方法に関する複雑なプロンプト指示、モデルの応答に対するパーサー、オーケストレーションロジックが必要でした。当時は、LLM に構文的に正しい JSON を確実に生成させることだけでも課題がありました！エージェントをプロトタイプし、デプロイするために、これらの初期モデルでエージェントがタスクを確実に成功させるための変換とオーケストレーションを処理する必要があり、私のチームでは様々な複雑なエージェントフレームワークライブラリに依存していました。これらのフレームワークを使っても、エージェントを本番環境で使用できるようにするまでに数か月の調整と工夫が必要でした。 以降、タスクを完了するための推論とツール使用における大規模言語モデルの能力が劇的に向上しているのを私たちは目の当たりにしました。モデルが今やネイティブなツール使用と推論機能を持つため、エージェントを構築するためにそれほど複雑なオーケストレーションは必要なくなったことを私たちは理解しました。実際、エージェントを構築するために使用していたエージェントフレームワークライブラリの一部は、新しい LLM の機能を十分に活用する妨げになり始めました。LLM が劇的に良くなっているにもかかわらず、これらの改善は、使用していたフレームワークでエージェントをより速く構築し、反復できることを意味しませんでした。エージェントを本番環境に対応させるのに依然として数か月かかっていました。 Q Developer のチームからこの複雑さを取り除くために、私たちは Strands Agents の構築を開始しました。最新モデルの機能に依存してエージェントを駆動することで、複雑なオーケストレーションロジックでエージェントを構築することと比較して、市場投入時間が大幅に短縮され、エンドユーザーの体験が向上できることを発見しました。Q Developer チームが新しいエージェントでプロトタイプから本番環境まで進むのに以前は数か月かかっていたところを、Strands では数日から数週間で新しいエージェントを提供できるようになりました。 Strands Agents の核となる概念 エージェントの最もシンプルな定義は、1) モデル 、2) ツール 、3) プロンプト 、の 3 つの要素の組み合わせです。エージェントはこれらの 3 つのコンポーネントを使用してタスクを完了し、多くの場合は自律的に行います。エージェントのタスクとしては、質問に答える、コードを生成する、休暇を計画する、または財務ポートフォリオを最適化することなどが考えられます。モデル駆動型アプローチでは、エージェントはモデルを使用して自身のステップを動的に指示し、指定されたタスクを達成するためにツールを使用します。 Strands Agents SDK でエージェントを定義するには、これらの 3 つのコンポーネントをコードで定義します。 モデル : Strands は柔軟なモデルサポートを提供します。ツール使用とストリーミングをサポートする Amazon Bedrock の任意のモデル、 Anthropic API を通じた Anthropic の Claude モデルファミリー、Llama API 経由の Llama モデルファミリー、ローカル開発用の Ollama 、そして LiteLLM を通じて OpenAI などの多くの他のモデルプロバイダーを使用できます。さらに、Strands で独自のカスタムモデルプロバイダーを定義することもできます。 ツール : エージェントのツールとして、公開されている何千もの Model Context Protocol (MCP) サーバーを選択できます。Strands は、ファイル操作、API リクエスト実行、AWS API との相互作用のためのツールを含む、 20 以上の事前構築済みのサンプルツール も提供します。Strands の @tool デコレータを使用するだけで、任意の Python 関数を簡単にツールとして使用できます。 プロンプト : エンドユーザーからの質問回答など、エージェントのタスクを定義する自然言語のプロンプトを提供します。エージェントの一般的な指示と望ましい動作を提供するシステムプロンプトも提供できます。 エージェントは、プロンプトによって提供されたタスクを完了するまで、モデルとツールとのループで相互作用します。このエージェンティックループ (agentic loop) が Strands の機能の核心です。Strands エージェンティックループは、強力になってきた LLM の推論、計画、ツール選択の能力を最大限に活用します。各ループで、Strands はプロンプトとエージェントのコンテキスト、そしてツールの説明と共に LLM を呼び出します。LLM は、エージェントのエンドユーザーに対する自然言語での応答、一連のステップの計画、エージェントの過去のステップの振り返り、そしてツールを選択をすることができます。LLM がツールを選択すると、Strands はツールの実行を処理し、結果を LLM に返します。LLM がタスクを完了すると、Strands はエージェントの最終結果を返します。 Strands のモデル駆動型アプローチでは、ツールはエージェントの動作をカスタマイズする鍵となります。例えば、ツールはナレッジベースからの関連文書の取得、API の呼び出し、Python ロジックの実行、または追加のモデル指示を含む静的な文字列を単純に返すことができます。以下の Strands Agents の事前構築済みのサンプルツールのように、モデル駆動型アプローチで複雑なユースケースを達成するのにも役立ちます。 Retrieve ツール: このツールは Amazon Bedrock Knowledge Bases を使用してセマンティック検索を実装します。文書を取得する以外に、retrieve ツールはセマンティック検索を使用して他のツールを取得することで、モデルの計画と推論を支援することもできます。例えば、AWS 内部のあるエージェントでは 6,000 以上のツールから選択します！今日のモデルは、これほど多くのツールから正確に選択する能力はありません。すべての 6,000 のツールをモデルに説明する代わりに、エージェントはセマンティック検索を使用して現在のタスクに最も関連するツールを見つけ、それらのツールのみをモデルに説明します。多くのツール説明をナレッジベースに保存し、モデルが retrieve ツールを使用して現在のタスクに関連するツールのサブセットを取得できるようにすることで、このパターンを実装できます。 Thinking ツール: このツールは、複数のサイクルを通じてモデルに深い分析的思考を促し、エージェントの一部として洗練された思考処理と自己省察 (self-reflection) を可能にします。モデル駆動型アプローチでは、思考をツールとしてモデル化することで、モデルがタスクに深い分析が必要かどうか、いつ必要かを推論できるようになります。 マルチエージェント ツール (workflow、graph、swarm ツールなど): 複雑なタスクについて、Strands は様々なマルチエージェント協調パターンで複数のエージェント間を調整できます。サブエージェントとマルチエージェント協調をツールとしてモデル化することで、モデル駆動型アプローチはモデルがタスクに定義されたワークフロー、グラフ、またはサブエージェントの連携 (swarm) が必要かどうか、いつ必要かを推論できるようになります。マルチエージェントアプリケーション用の Agent2Agent (A2A) プロトコルの Strands サポートは近日公開予定です。 Strands Agents の始め方 Strands Agents SDK でエージェントを構築する例を見ていきましょう。 長い間言われている ように、物事に名前を付けることはコンピュータサイエンスの最も難しい問題の 1 つです。オープンソースプロジェクトの命名も例外ではありません！Strands Agents プロジェクトの潜在的な名前をブレインストームするのを支援するために、私は Strands を使用して命名 AI アシスタントを構築しました。この例では、Strands を使用して、Amazon Bedrock のデフォルトモデル、MCP サーバー、事前構築済みの Strands ツールを使った命名エージェントを構築します。 agent.py という名前のファイルを次のコードで作成してください。 from strands import Agent from strands.tools.mcp import MCPClient from strands_tools import http_request from mcp import stdio_client, StdioServerParameters # 命名にフォーカスしたシステムプロンプトの定義 NAMING_SYSTEM_PROMPT = """ あなたはオープンソースプロジェクトの命名を支援するアシスタントです。 オープンソースのプロジェクト名を提案する際は、必ずプロジェクトに使用できる ドメイン名と GitHub の組織名を 1 つ以上提供してください。 提案する前に、ドメイン名がすでに登録されていないか、GitHub の組織名が すでに使用されていないか、ツールを使って確認してください。 """ # ドメイン名が利用可能かを判定する MCP サーバーを読み込む domain_name_tools = MCPClient(lambda: stdio_client( StdioServerParameters(command="uvx", args=["fastdomaincheck-mcp-server"]) )) # GitHub の組織名が利用可能かを判定するためのリクエストを # GitHub に送る Strands Agents の事前構築済みツール github_tools = [http_request] with domain_name_tools: # ツールとシステムプロンプトと共に命名エージェントを定義 tools = domain_name_tools.list_tools_sync() + github_tools naming_agent = Agent( system_prompt=NAMING_SYSTEM_PROMPT, tools=tools ) # エンドユーザーのプロンプトと共に命名エージェントを実行 naming_agent("AI エージェント構築のためのオープンソースプロジェクトの名前を考えてください。") エージェントを実行するには GitHub パーソナルアクセストークンが必要です。GitHub トークンの値で環境変数 GITHUB_TOKEN を設定してください。また、us-west-2 の Anthropic Claude 3.7 Sonnet への Amazon Bedrock モデルアクセスと、ローカルに設定された AWS 認証情報も必要です。 準備ができたらエージェントを実行してください。 pip install strands-agents strands-agents-tools python -u agent.py 次のスニペットのような、エージェントからの出力が表示されるはずです。 私が確認した内容に基づいて、オープンソース AI エージェント構築プロジェクトの名前をいくつか提案します。 ## プロジェクト名の提案: 1. **Strands Agents** - 利用可能なドメイン: strandsagents.com - 利用可能な GitHub 組織: strands-agents お気に入りの AI アシスト開発ツールの上で Strands Agents SDK を使い、新しいエージェントの構築をすぐ簡単に開始できます。素早く始められるよう、 Q Developer CLI や Cline などの MCP 対応開発ツールで使用できる Strands MCP サーバーを公開しました。Q Developer CLI をお使いの場合、以下の例を使用して CLI の MCP 設定 に Strands MCP サーバーを追加してください。 GitHub でより多くの設定例を確認できます。 { "mcpServers": { "strands": { "command": "uvx", "args": ["strands-agents-mcp-server"] } } } 本番環境での Strands Agents のデプロイ 本番環境でエージェントを実行することは、Strands の設計における重要な原則です。Strands Agents プロジェクトには、エージェントを本番環境に導入するのに役立つリファレンス実装のセットを含む デプロイツールキット が含まれています。Strands は本番環境でさまざまなアーキテクチャーをサポートするのに十分な柔軟性があります。Strands を使用して、会話型エージェントや、イベントトリガー型、スケジュール実行型、または継続的に実行されるエージェントを構築できます。Strands Agents SDK で構築されたエージェントは、エージェンティックループとツール実行の両方が同じ環境で実行されるモノリスとして、または一連のマイクロサービスとしてデプロイできます。以下では、AWS 内部における Strands Agents のデプロイで利用している 4 つのエージェントアーキテクチャーについて説明します。 次の図は、クライアントアプリケーションを通じてユーザーの環境で Strands が完全にローカルで実行されるエージェントアーキテクチャーを示しています。GitHub で公開している コマンドラインツールの例 は、エージェント構築のための CLI ベースの AI アシスタント用の以下のアーキテクチャーに従っています。 次の図は、エージェントとそのツールが本番環境で API の背後にデプロイされるアーキテクチャーを示しています。 AWS Lambda 、 AWS Fargate 、または Amazon Elastic Compute Cloud (Amazon EC2) を使用して、Strands Agents SDK で構築されたエージェントを AWS の API の背後にデプロイする方法についても、GitHub 上でリファレンス実装を提供しています。 Strands エージェンティックループとツール実行を別々の環境で実行することで、関心事を分離できます。次の図は、エージェントが API 経由でツールを呼び出し、ツールがエージェントの環境とは別の分離されたバックエンド環境で実行される Strands のエージェントアーキテクチャーを示しています。例えば、エージェント自体を Fargate コンテナで実行しながら、エージェントのツールを Lambda 関数で実行することができます。 Strands では、クライアントがツールの実行を担当するリターンコントロール (return-of-control) パターンも実装できます。この図は、Strands Agents SDK で構築されたエージェントが、バックエンド環境でホストされるツールと、エージェントを呼び出すクライアントアプリケーションを通じてローカルで実行されるツールの組み合わせを使用できるエージェントアーキテクチャーを示しています。 アーキテクチャーの選択にかかわらず、エージェントの可観測性 (observability) は本番環境でのエージェントのパフォーマンスを理解するために重要です。Strands は、本番エージェントのトレースとメトリクスを収集するための機能を提供します。Strands は OpenTelemetry (OTEL) を使用して、可視化、トラブルシューティング、評価のために任意の OTEL 互換バックエンドにテレメトリデータを送信します。分散トレーシングに対する Strands のサポートにより、エージェントセッションの完全な全体像を描くために、アーキテクチャーの異なるコンポーネントを通じてリクエストを追跡できます。 Strands Agents コミュニティへの参加 Strands Agents は Apache License 2.0 の下でライセンスされたオープンソースプロジェクトです。皆様と一緒にオープンに Strands を構築できることを嬉しく思います。追加プロバイダーのモデルとツールのサポート追加、新機能のコラボレーション、ドキュメントの拡張など、プロジェクトへの貢献を歓迎します。バグを見つけた場合、提案がある場合、または何か貢献することがある場合は、 GitHub のプロジェクトにご参加ください。 Strands Agents について詳しく学び、Strands で最初の AI エージェントの構築を開始するには ドキュメント をご覧ください。 著者について Clare Liguori は AWS Agentic AI のシニアプリンシパルソフトウェアエンジニアです。彼女は、Amazon Q Developer チームの一員として、生成 AI と AI エージェントによって強化されたツールを使用することで、アプリケーションの構築方法と開発者の生産性を再考することに焦点を当てています。 翻訳は機械学習ソリューションアーキテクトの本橋が担当しました。

AWS の生成 AI ワークロードのコスト最適化に関する 5 回構成のシリーズの続きとして、3 回目のブログでは Amazon Bedrock に焦点を当てます。以前の投稿では、 生成 AI の導入に関する一般的なクラウド財務管理の原則 と、 Amazon EC2 とAmazon SageMaker AI を使用したカスタムモデル開発の戦略について説明しました。今回は、Amazon Bedrock のコスト最適化手法についてご案内します。料金オプション、モデル選択、ナレッジベースの最適化、プロンプトキャッシュや自動推論について、十分な情報に基づいた意思決定について探っていきます。基盤モデルに関して取り組み始めたばかりでも、既存の Amazon Bedrock 実装の最適化を検討している場合でも、これらの手法はマネージド AI モデルの利便性を活用しながら機能とコストのバランスを取るのに役立ちます。 Amazon Bedrock とは？ Amazon Bedrock は、統合された API を通じて複数の AI 企業の主要な基盤モデル（FM）へのアクセスを提供するフルマネージド型サービスです。これにより、開発者は複雑なインフラストラクチャを管理しなくても、生成 AI アプリケーションを構築して拡張できます。主な利点として、シームレスなモデル切り替え、エンタープライズグレードのセキュリティとプライバシーの制御、モデルのファインチューニングによるカスタマイズ機能や AWS サービスとの直接統合などがあります。Amazon Bedrock には、コストとパフォーマンスのバランスを取るのに役立つ強力な手段がいくつか用意されています。 モダンアプリケーションの新しい構成要素である推論 re:Invent 2024 で、AWS の CEO である Matt Garman は、アプリケーションアーキテクチャについての考え方におけるパラダイムシフトを紹介しました。それは、コンピューティング、ストレージやデータベースなどの従来のコンポーネントと並んで、 推論 をモダンアプリケーションの基本的な構成要素として位置付けることです（ AWS re:Invent 2024 – Matt Garman による CEO 基調講演 をご覧ください）。生成 AI 機能をオペレーションワークフローに組み込むことが増えるにつれ、推論コストの管理と最適化は、従来のクラウドコスト管理と同じくらい重要になります。この進化をサポートするために、AWS は 推論レベルのコスト配分タグ を導入し、推論の支出をきめ細かく可視化できるようにしました。この強化された機能により、推論レベルでのコストの視覚化と分析、AI ワークロードに特化した予算の設定と管理、モデル選択と使用に関するデータドリブンな意思決定が可能になります。次のセクションでは、推論コストの削減に役立つ実用的なコスト最適化手法について説明します。 あらゆるユースケースに対応する柔軟な料金モデル Amazon Bedrock の柔軟な 料金モデル には、3 つの主要なオプションがあります。1) 従量課金制の柔軟性を実現する オンデマンド 、2) 1 か月または 6 か月のコミットメントで 40～ 60% の節約を実現する プロビジョンドスループット 、3) オンデマンドと比較して最大 50% 低い価格を実現できる バッチ処理 です。最適な料金オプションを選択することは、財務とオペレーション効率に直接影響するため、成功にとって非常に重要です。最も適切なオプションを選択することで、サービス品質を維持しながら支出を最適化できます。つまり、変動するワークロードにはオンデマンド、一貫した使用パターンにはプロビジョンドスループット、時間的制約のないオペレーションにはバッチ処理を選択します。この柔軟性は AI 実装のさまざまな段階をサポートし、適切なリソース配分を可能にし、過剰なプロビジョニングを防いだり、予算の予測可能性を高めます。間違った選択は、オペレーション効率と収益の両方に影響を与える不必要な費用につながる可能性があるため、情報に基づいた料金オプションの決定を行うことが不可欠です。 戦略的モデル選択 図 1. Amazon Bedrockは、大手 AI 企業のフルマネージドモデルを幅広く提供しています Amazon Bedrock でのモデル選択は、戦略的に重要な判断であり、コスト、効率性、そしてパフォーマンスの成果に大きく影響します。Amazon Bedrock では、Anthropic、Meta、Mistral AI そして Amazon などの業界リーダーによる多様な基盤モデルにアクセスできます。これらのプロバイダーから入手できるモデルに加えて、Amazon Bedrock Marketplace では 100 種類以上の他のモデルを活用できます。単一のモデルやプロバイダーにこだわるよりも、Amazon Bedrock の柔軟性を活用すれば、最小限のコード変更でモデルをシームレスに切り替えることができます。より効率的な新しいモデルがリリースされたら、コスト削減とパフォーマンスの向上のために簡単に切り替えることができます。プラットフォームのバッチ処理機能は、新しいモデルが利用可能になったときに継続的に評価できるようにすることで、この利点をさらに強化します。これにより、ソリューションが長期にわたって最適化され続け、急速に進化する AI 環境において競争上の優位性を維持できます。モデルの多様性と評価に対するこの戦略的アプローチは、オペレーションの俊敏性を維持しながら AI への投資を最大限に活用するのに役立ちます。 モデルを選択する際に他に考慮することは、応答時間です。Amazon Bedrock モデルの中には、レイテンシー最適化設定をサポートしているものがあります。「 レイテンシーに関するモデル推論の最適化 」を参照してください。これにより、通常のパフォーマンスと比較して応答時間が短縮されます。これらのモデルは効率性を高め、生成 AI アプリケーションの応答性を高めます。現在、Amazon Nova Pro、Anthropic の Claude 3.5 Haiku、Meta の Llama 3.1 405B と 70B でレイテンシー最適化設定を使用できます。これらは、AWS 上で他のどこよりも高速に実行できます。 ナレッジベースの活用 Amazon Bedrock では、独自のデータソースからのコンテキスト情報を組み込むことで、高精度、低レイテンシーで安全なカスタム生成 AI アプリケーションを作成できるナレッジベースの組み込みをサポートしています。RAG（検索拡張生成）としても知られているナレッジベースを使用すると、より正確で関連性が高い最新の回答が得られます。ナレッジベースを活用することで、より質の高い回答を得ることができ、必要なプロンプトや応答の数が減るため、コスト削減につながります。ナレッジベースを最適化する鍵は、データとインデックス作成頻度を管理することです。インデックス料金が主なコスト要因であり、ベクトルデータベースによってオブジェクト単位、または OpenSearch Compute Unit（OCU）時間単位で請求されます。これらのコストを最小限に抑えるためにできることは次の 3 つです。 ソリューションに貢献しないデータのインデックス作成を避けるため、データソースには関連データのみを含めます。 すでにインデックスが作成されているファイルの更新や変更は避けます。ファイルが変更されると、そのファイルのインデックスが再作成され、追加料金が発生するためです。 インデックスを簡略化するために不要になったデータを削除します。これにより、インデックス作成の合計コストが削減され、インデックス化されたデータに対するリクエストがスピードアップします。 これらのプラクティスに従うことで、ナレッジベースのデプロイメントのコスト削減とインデックス作成の高速化を実現できます。 図 2. Amazon Bedrock は検索拡張生成（RAG）をネイティブでサポートしています パフォーマンス向上のためのカスタマイズ 最近のファインチューニング機能の進歩により、モデルパフォーマンスの最適化がこれまでになく簡単になりました。現在はコードを記述しなくても、 データを使用してモデルのカスタマイズやファインチューニング を行うことができます。これにより、継続的にモデルを再トレーニングする必要性が減り、出力の品質が高くなるため、より効率的かつ低コストなソリューションの運用が可能になります。 蒸留によるコスト効率の向上 Amazon Bedrock の モデル蒸留 機能は、パフォーマンスと効率のバランスをとる機会を提供します。このテクノロジーは、大規模な「教師」モデルから小規模な「生徒モデル」モデルへの高度な知識伝達プロセスを通じて、精度を大幅に損なうことなく最適化を実現できます。このプロセスにより、元のモデルよりも最大 500% 高速に動作し、コストも最大 75% 削減できる蒸留モデルが生成されます。RAG などのユースケースでは精度の低下は 2% 未満です。この機能は、モデル機能とオペレーション効率の間の従来のトレードオフに対処し、高度な AI アプリケーションをあらゆる規模の予算でより利用しやすく、経済的に実行可能なものにします。 図 3. モデル蒸留により、高度なモデルのパフォーマンスとコスト効率の高いモデルをユースケースに合わせて調整できます コストとレイテンシーの削減のためのプロンプトキャッシュ Amazon Bedrock の プロンプトキャッシュ 機能は、コストとパフォーマンスの面で非常に大きなメリットをもたらします。この機能では、複数の API コールにわたって頻繁に使用されるプロンプトをインテリジェントにキャッシュすることで、同じリクエストを再処理する必要性を排除します。これにより、サポート対象モデルのコストが最大 90% 削減され、レイテンシーが 85% 削減されます。プロンプトキャッシュは、キャッシュされたプロンプトプレフィックスを再利用することで機能し、一致するプレフィックスを再処理する必要がないため、応答の品質を維持しながら出力の生成に必要な計算リソースを大幅に削減できます。この最適化により、エンタープライズ規模の AI 実装がより経済的に実現可能になり応答性も高くなります。 精度を向上させる自動推論 自動推論 の統合により、Amazon Bedrock は生成 AI の精度を向上させ、コストを最適化する機会を提供します。自動推論は Amazon Bedrock Guardrails を通じて利用でき、人事、財務やコンプライアンスなどの戦略的領域における正確性を保証するために数学的手法を採用しています。この数学的証明プロセスにより、応答の信頼性が向上するだけでなく、オペレーション効率も向上します。この効率化は、正確な応答を得るために必要なプロンプトの数を減らすことで実現されます。さらに、このシステムは、すべての応答について正確性の証明と論理的な説明を提供することで、通常は手動による検証やエラー修正に投入されるリソースを費やすことなく、精度が重要なユースケースでの AI の運用をスピードアップできます。精度の向上、インタラクションコストの低さや検証の組み合わせを考慮に入れると、コストが大幅に削減される可能性があります。 結論 上記の最適化戦略を実装することで、パフォーマンスを維持または向上させながら、コストを大幅に削減できます。重要なのは、新しい機能が利用可能になったときに、アプローチを継続的に評価して調整することです。Amazon Bedrock の柔軟性と包括的な機能セットは、生成 AI の実装を最適化したい場合に理想的なプラットフォームです。 Amazon Bedrock の生成 AI アプリケーション開発コストを最適化するためのさまざまなアプローチについて説明してきました。次の投稿では、料金階層の選択、ユーザー管理やコンテンツのインデックス作成など Amazon Q のコスト最適化戦略について説明します。コスト効率を維持しながら AWS の AI 搭載アシスタントを最大限に活用する方法を学びましょう。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能に貢献したほか、AWS re:Invent やその他の業界プラットフォームでの講演を通じてオピニオンリーダーとしての役割を果たしてきました。 Bowen Wang Bowen は AWS 請求およびコスト管理サービスの主任プロダクトマーケティングマネージャーです。彼女は、財務およびビジネスリーダーがクラウドの価値とクラウドファイナンス管理を最適化する方法をよりよく理解できるようにすることに重点を置いています。以前のキャリアでは、テック系スタートアップの中国市場への参入を支援しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 5月は残り10日ほどですが、生成AI関連のイベントはまだまだ続きます！ 5 月 22 日 (木)：AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜 5 月 23 日 (金)：Dify Enterprise on AWS – 企業 AI 活用の極意 5 月 27 日 (水)： AWS Developer Live Show 「ナウいフロントエンド開発 ~ 生成 AI と協調するには ~」 5 月 28 日 (木)：Coding Agent at Loft #1 ~ Cline with Amazon Bedrock で 爆速開発体験ハンズオン ~ 大阪開催 イベントの申し込み方法などのリンクはこちらのブログ「 生成 AI 最前線！5月開催の AWS 生成 AI イベントガイド 」にまとめていますので是非参照してみてください。 また、6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 の事前登録 が始まっていますのでこちらも登録をお忘れなく！ それでは、5 月 12 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「ファーストパーティデータによる D2C (Direct-to-Consumer) マーケティングの実現：生成 AI によるパーソナライズされた体験の提供」を公開 この記事では、D2C（Direct-to-Consumer）マーケティングにおけるファーストパーティデータの活用と、生成 AI を用いたパーソナライズされた顧客体験の提供方法について解説しています。Amazon Bedrock、Amazon OpenSearch Service、Amazon Personalize、Amazon Q Business などの AWS サービスを組み合わせることで、顧客データを効果的に活用し、パーソナライズされたマーケティングを実現する方法が紹介されています。消費財業界における生成 AI 活用の具体的な事例として参考になるでしょう。 ブログ記事「GitLab Duo with Amazon Q の一般提供開始のお知らせ」を公開 GitLab Duo with Amazon Q が一般提供開始されました。この統合により、GitLab ユーザーは Amazon Q Developer の AI アシスタント機能を GitLab 環境内で直接利用できるようになります。コード生成、コードレビュー、テスト作成などの開発タスクを効率化し、開発者の生産性を向上させることが可能です。GitLab と Amazon Q の連携により、開発ワークフローをシームレスに強化できる機能として注目されています。 ブログ記事「Eclipse での Amazon Q Developer によるインラインチャットの発表」を公開 Eclipse IDE で Amazon Q Developer のインラインチャット機能が利用可能になりました。この機能により、開発者は Eclipse 内でコードを編集しながら、コンテキストを理解した AI アシスタントとチャットできるようになります。コードの説明、バグの修正、リファクタリングの提案などを直接 IDE 内で受けられるため、開発効率が大幅に向上します。Eclipse ユーザーにとって、開発体験を向上させる強力なツールとなるでしょう。 サービスアップデート NVIDIA B200 GPUを搭載したAmazon EC2 P6-B200インスタンスが一般提供開始 * NVIDIA B200 GPU を搭載した Amazon EC2 P6-B200 インスタンスが一般提供開始されました。このインスタンスは P5en インスタンスと比較して最大 2 倍のパフォーマンスを提供し、AI トレーニングと推論を加速します。8 基の Blackwell GPU、1440 GB の高帯域幅 GPU メモリ、第 5 世代 Intel Xeon プロセッサ、最大 3.2 Tbps の EFAv4 ネットワーキングを搭載しています。現在、米国西部（オレゴン）リージョンの Amazon EC2 Capacity Blocks for ML を通じて利用可能です。 Amazon Bedrock Guardrails がクロスリージョン推論をサポート Amazon Bedrock Guardrails がクロスリージョン推論をサポートするようになりました。この機能により、トラフィックの急増時に複数の AWS リージョンにわたって計算リソースをシームレスに活用できるようになります。これまで Amazon Bedrock  で提供されていたクロスリージョン推論機能が Guardrails でも利用可能となっており、ご利用の際のスケーラビリティをさらに高めることができるようになりました。この機能の利用に追加のルーティングコストはかかりません。 AWS Transform for .NET が一般提供開始 AWS Transform for .NET が一般提供開始されました。これは、.NET アプリケーションを大規模にモダナイズするための初のエージェント型 AI サービスです。Windows .NET アプリケーションを Linux 対応にモダナイズする速度を従来の方法と比較して最大 4 倍高速化し、ライセンスコストを最大 40% 削減できます。MVC、WCF、Web API、クラスライブラリ、コンソールアプリ、ユニットテストプロジェクトなど、幅広い .NET プロジェクトタイプの変換をサポートしています。現在、米国東部（バージニア北部）および欧州（フランクフルト）リージョンで利用可能です。 AWS Transform for mainframe が一般提供開始 AWS Transform for mainframe が一般提供開始されました。これは、メインフレームアプリケーションを大規模にモダナイズするための初のエージェント型 AI サービスです。IBM z/OS アプリケーションのモダナイゼーションを数年から数ヶ月に短縮します。このリリースでは、コードベース全体のサイクロマティック複雑性、同音異義語、重複 ID の識別などの拡張分析機能が導入されています。また、ドキュメント生成機能も強化され、より大規模なコードベースをサポートし、生成されたドキュメントに対するAIパワードチャット体験も提供されています。現在、米国東部（バージニア北部）および欧州（フランクフルト）リージョンで利用可能です。 AWS Transform の移行評価機能を発表 AWS Transform の移行評価機能が一般提供開始されました。この機能は、IT 環境を分析し、インテリジェントでデータ駆動型のインサイトと実行可能な推奨事項を提供することで、クラウド移行を簡素化し最適化します。インフラストラクチャデータをアップロードするだけで、通常数週間かかる包括的な分析を数分で提供します。エージェント型 AI を活用することで、手動分析の数週間を省き、インフラストラクチャの即時可視化とコスト最適化の機会の自動検出を実現します。現在、米国東部（バージニア北部）および欧州（フランクフルト）リージョンで利用可能です。 AWS Transform for VMware が一般提供開始 AWS Transform for VMware が一般提供開始されました。これは、大規模な VMware モダナイゼーションを簡素化する初のエージェント型 AI サービスです。大規模言語モデル、グラフニューラルネットワーク、および AWS のエンタープライズワークロード移行における深い経験を活用しています。エージェント型 AI により、発見から依存関係マッピング、ネットワーク変換、Amazon EC2 最適化まで、モダナイゼーションのライフサイクル全体を自動化します。テストでは、500 台の VM の移行プランを 15 分で生成し、ネットワーク変換を従来の方法と比較して最大 80 倍高速化しました。パイロットプログラムに参加したパートナーは、実行時間を最大 90% 削減しています。 今週は以上でした。それでは、また来週お会いしましょう！ 著者について 三厨 航(Wataru Mikuriya) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たアニメは「NANA」です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 サービスのアップデートの前に２つイベントの宣伝をさせてください。 一つ目は、5月27日にAWS Developer Live Showで「ナウいフロントエンド開発 ~ 生成 AI と協調するには ~」が予定されています。フロントエンド開発での生成 AI 活用について学べる機会ですのでぜひご活用ください。 2025 年 5 月 27 日 (火) 17:00 – 18:00 JST ナウいフロントエンド開発 ~ 生成 AI と協調するには ~ https://aws.amazon.com/jp/builders-flash/developer-live-show/ もう一つは6月5日にSaaS・ソフトウェア ソリューション ベンダー 兼 AWS Marketplace パートナー 11社が集結するイベントです。AWS Marketplace活用のアイディアの一つとしてぜひご参考にしていただければと思います。 2025 年 6月 5日 (木) 14:30 – 19:00 JST AWS Marketplace Solution EXPO Spring 2025 https://pages.awscloud.com/aws-marketplace-solution-expo-spring-2025-jp.html それでは、先週の主なアップデートについて振り返っていきましょう。 2025年4月14日週の主要なアップデート 5/12(月) AWS EC2 instances now support ENA queue allocation for your network interfaces EC2インスタンスのElastic Network Interface（ENI）ごとに柔軟なキュー割り当てを可能にするElastic Network Adapter（ENA）が発表されました。これまで静的に割り当てられていたENAキューが、インスタンスの総キュープールから動的に割り当て可能になることで、ワークロードの要件に応じて最適なネットワークリソースの配分が可能になりました。この機能強化により、ネットワーク集約型アプリケーションにより多くのキューを割り当てたり、CPU集約型アプリケーションには少ないキューで運用したりと、より効率的なリソース管理が実現できます。この機能はすべてのAWS商用リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon SageMaker Unified Studio now allows you to bring your own image (BYOI) Amazon SageMaker Unified Studioで独自のイメージを持ち込める（BYOI）機能が追加されました。このアップデートにより、規制やコンプライアンス要件がある企業や、デフォルトのSageMaker Distributionイメージを使用したくないユーザーが、カスタマイズされた開発環境を構築できるようになりました。必要なフレームワークの選択や新しい依存関係の追加、開発環境と本番環境間でのコードの再現性確保などの面で利点があります。このアップデートはAmazon SageMaker Unified Studioが利用可能なすべてのAWS商用リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Announcing Code Editor (based on VS Code – Open Source) in Amazon SageMaker Unified Studio Amazon SageMaker Unified Studioで、Code EditorとMultiple Spacesの2つの新機能が追加されました。Code EditorはCode-OSSベースの軽量かつパワフルなIDEで、Visual Studio Code互換の拡張機能を利用できます。また、Multiple Spacesサポートにより、ユーザーごとプロジェクトごとに複数の作業スペースを管理できるようになりました。これらの機能強化により、開発チームの生産性が向上し、より効率的なML開発環境が実現します。これらの機能が利用可能なAWSリージョンについては、 こちら をご覧ください。また、機能の詳細については ドキュメント をご確認ください。 5/13(火) Amazon VPC adds CloudTrail logging for VPC resources created by default Amazon VPCのCloudTrailログ機能が強化され、VPC作成時にデフォルトで作成されるリソースも記録されるようになりました。これまでは明示的に作成されたリソースのみが記録されていましたが、今回の更新により、セキュリティグループ、ネットワークACL、ルートテーブルなどのデフォルトリソースの作成や削除も自動的に記録されるようになりました。この機能強化により、監査とガバナンスの要件への対応が容易になり、VPCリソースの可視性が向上します。このアップデートは、追加コストなしですべてのAWS商用リージョンとAWS GovCloud（US）リージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon ECS adds support for Amazon EBS Provisioned Rate for Volume Initialization Amazon ECSがAmazon EBSのボリューム初期化のためのプロビジョニングレートをサポートしました。これまでもEBSスナップショットからECSタスクに接続されたEBSボリュームを初期化することは既に可能でしたが、今回のアップデートにより初期化レートを指定することで、予測可能な時間内でボリュームの完全なパフォーマンスを確保できるようになりました。この機能はすべてのAWS商用リージョンで利用可能です。詳細は ドキュメント をご確認ください。 AWS announces new AWS Data Transfer Terminal location in the San Francisco Bay Area 新しいAWS Data Transfer Terminalがカリフォルニア州サンタクララのCoreSite SV8に開設されました。Data Transfer Terminalは、お客様が物理的なストレージデバイスを持ち込んで高速なネットワーク接続を通じてAWSに大容量データをアップロードできる安全な施設で、ロサンゼルスとニューヨークに続く3つ目の拠点となります。利用に際しては、AWSコンソールで最寄りのData Transfer Terminalを予約いただけます。また、詳細については ドキュメント をご覧ください。 5/14(水) Amazon Aurora and RDS for PostgreSQL, MySQL, and MariaDB now offer Reserved Instances for R8g and M8g instances Amazon AuroraおよびPostgreSQL, MySQL, MariaDBのRDSでGraviton4ベースのR8gおよびM8gインスタンスのリザーブドインスタンス(RI)購入が可能になりました。RIは、オンデマンド料金と比べて大幅な割引を提供する購入オプションです。同じファミリー内でインスタンスサイズの柔軟性があり、シングルAZとマルチAZの構成の両方に自動的に適用されるため、リソースが変動する本番ワークロードに理想的です。今回のRI対応は、Graviton4ベースのインスタンスが提供されているすべてのAWSリージョンで利用可能で、対応するDBエンジンバージョンについては、 Aurora と RDS のドキュメントを参照してください。同じタイミングで、Intel第4世代Xeon Scalableプロセッサを搭載した R7iおよびM7iインスタンスも同様にRI購入が可能に なっています。 Amazon Bedrock Guardrails now supports cross-region inference Amazon Bedrock Guardrailsがクロスリージョン推論をサポートしました。Bedrock Guardrailsは有害なコンテンツの検出とブロック、特定トピックの制限、個人情報の編集など、さまざまな保護機能を提供し、さらにモデルのハルシネーションの検出や事実確認を行う機能です。今回のアップデートにより、異なるAWSリージョンのコンピュートを活用してトラフィックバーストをシームレスに管理できるようになり、需要の急増時でも一貫したスループットと高い可用性を実現できます。クロスリージョン推論による追加コストは発生しません。 サポートリージョン はこちらを、機能の詳細は ドキュメント をご確認ください。 Amazon RDS for Oracle now supports the April 2025 Release Update (RU) Amazon RDS for OracleがOracle Database 19cと21cの2025年4月リリースアップデート（RU）のサポートしました。このアップデートにはバグ修正とセキュリティ修正が含まれており、Standard Edition 2とEnterprise Editionの両方で利用可能です。コンソールやAWS SDK、CLIを通じて簡単にアップグレードできる他、自動マイナーバージョンアップグレード（AmVU）を有効にすることで、自動的なアップデートも可能です。新しいマイナーバージョンは、Amazon RDS for Oracleが利用可能なすべてのAWSリージョンで利用可能です。 5/15(木) Amazon EC2 P6-B200 instances powered by NVIDIA B200 GPUs now generally available NVIDIA B200 GPUを搭載した最新のGPUインスタンス、P6-B200がGAしました。このインスタンスは、AIワークロードの処理能力が大幅に向上しており、前世代のP5enと比較して最大2倍のパフォーマンスを実現し、GPUメモリ帯域幅も60%向上しています。8個のBlackwell GPUと1440 GBの大容量メモリを搭載し、最新のIntel Xeonプロセッサと高速なネットワーク機能を組み合わせることで、大規模なAIワークロードの処理を可能にしています。AWS Nitroシステムとの統合により、数万個のGPUまでスケールアップが可能で、高度なセキュリティも確保されています。P6-B200インスタンスは現在、米国西部（オレゴン）リージョンのAmazon EC2 Capacity Blocks for MLにおいて、p6-b200.48xlargeサイズで利用可能です。詳細については 製品ページ をご確認ください。 AWS Transform for .NET is now generally available AWS Transform for .NET（旧：Amazon Q Developer transformation capabilities for .NET porting）がGAしました。AWS Transform for .NETはエージェント型AIサービスで、.NETアプリケーションをクロスプラットフォームに変換し、Linux対応することでライセンスコストを最大40%削減することができます。MVC、WCF、Web API、クラスライブラリ、コンソールアプリ、単体テストプロジェクトなど、幅広い.NETプロジェクトタイプの変換をサポートしています。現時点では米国東部（バージニア北部）およびヨーロッパ（フランクフルト）で利用可能です。詳細は ブログ または ドキュメント をご確認ください。なおAWS Transformに関しては同じくプレビューだった AWS Transform for mainframe , AWS Transform for VMware is now generally available も同日にGAが発表されているので、そちらもぜひチェックしてみてください。 Announcing migration assessment capabilities of AWS Transform AWS Transformの移行評価機能がGAしました。この新機能では、エージェント型AIを活用することで、従来数週間を要していた移行分析作業を数分で完了させることが可能になります。インフラストラクチャデータをアップロードするだけで、AIが自動的に詳細な分析を行い、コスト最適化の機会を発見し、包括的なビジネスケースを生成します。これにより、企業は迅速かつ正確な移行計画を立案することができ、さまざまな購入オプションやライセンス形態の比較検討も容易になりました。現時点では米国東部（バージニア北部）およびヨーロッパ（フランクフルト）で利用可能です。詳細は ブログ をご確認ください。 AWS CodeBuild announces support for remote Docker servers AWS CodeBuildがリモートDockerイメージビルドサーバーをサポートしました。この新機能では、ビルド間で永続的なキャッシュを維持する完全マネージド型のDockerサーバーを提供し、キャッシュされたレイヤーの再利用や並列ビルドの実行が可能になりました。これにより、プロビジョニングとネットワーク転送の遅延が削減され、ビルド速度が最適化されます。この機能強化により、より効率的なCI/CDパイプラインを構築でき、特に大規模なDockerイメージを扱うプロジェクトに大きな恩恵があります。この機能はすべてのCodeBuild提供リージョンで利用可能です。詳細と設定方法は ブログ もしくは ドキュメント をご確認ください。 Amazon OpenSearch Ingestion increases memory for an OCU to 15 GB Amazon OpenSearch Ingestionのメモリ容量が、OpenSearch Compute Unit（OCU）あたり8GBから15GBへと大幅に増強され、処理能力が向上しました。このアップデートは、既存の設定を変更することなく、自動的により多くのメモリリソースが利用可能になります。これにより特にトレース分析や集計処理などのメモリを大量に使用する処理において、パフォーマンスの向上とメモリ不足によるエラーのリスク軽減が期待できます。この機能強化は追加コストなしで提供され、すべてのAWSリージョンですぐに利用可能となっています。詳細については ドキュメント をご確認ください。 5/16(金) AWS Config rules now available in additional AWS Regions AWS Config rulesが新たに大阪を含む17のリージョンで利用可能になりました。このアップデートにより、より多くのリージョンでAWSリソースの設定を自動評価し、コンプライアンスを確保することが可能になります。Config rulesはAWSリソースの設定を評価し、Amazon EventBridgeを通じて通知できるサービスで、ベストプラクティスへの準拠を確認できるマネージドルールも提供しています。詳細は ドキュメント をご確認ください。 Amazon Cognito now supports OIDC prompt parameter Amazon Cognitoで、CognitoマネージドログインにおけるOpenID Connect（OIDC）プロンプトパラメータのサポートが発表されました。この機能強化により、認証フローの制御がより細かく柔軟になり、セキュリティとユーザー体験の両面が向上します。特に’login’プロンプトによる明示的な再認証と’none’プロンプトによるサイレント認証状態チェックの2つの重要な機能が追加されました。これにより、機密情報へのアクセス時の追加認証や、複数アプリケーション間でのシームレスなシングルサインオン体験の実現が可能になります。この新機能はAmazon Cognitoが利用可能なすべてのAWSリージョンで、EssentialsまたはPlus Tierで利用可能です。詳細については ドキュメント をご確認ください。 AWS CodePipeline now supports deploying to AWS Lambda with traffic shifting AWS CodePipelineに新しいLambdaデプロイアクションが追加され、AWS Lambdaへのアプリケーションデプロイが簡素化されました。このアップデートにより、リニアまたはカナリアデプロイメントパターンをサポートすることで、より安全なリリースが可能になりました。CloudWatchアラームと連携した自動ロールバック機能も備えており、本番環境のワークロードに対してより信頼性の高いデプロイメントを実現します。このアップデートはAWS GovCloud（US）リージョンと中国リージョンを除く、AWS CodePipelineがサポートされているすべてのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

この投稿は、「 Accelerating generator interconnection study with serverless workflow and elastic HPC 」を翻訳したものになります。 コスト削減と脱炭素化の取り組みに後押しされたクリーンエネルギーの急速な成長は、 既存の電力系統インフラに大きな負担をかけています 。太陽光、風力、その他の分散型エネルギーリソースの系統接続要請が増加するにつれ、発電設備の系統接続プロセスはますます複雑化し、課題が山積しています。時代遅れの系統計画プロセス、長期化する 系統接続待ち行列 、送電容量の不足は、新規電源をスムーズに統合する際の主要な障壁の一部となっています。これらの系統接続における課題は、再生可能エネルギー資源が豊富な地域と需要地との地理的なミスマッチによってさらに深刻化しており、クリーンエネルギーを消費者に届けるために大規模な送電網の整備が必要となっています。 この問題の規模は驚異的です：系統接続待ち行列のプロジェクト数は、現在の米国の電力系統全体の設備容量の２倍に達しています。2022 年時点で、およそ200 万メガワット（MW）のクリーンエネルギー設備容量が接続待ちの状態にあり、2023 年末までにこの数字は 260 万MW（2,600 ギガワット (GW) 、すなわち 2.6 テラワット (TW) ）にまで増加しました。これらの提案されているプロジェクトは、電力系統への接続前に必要とされる様々なアセスメントや手続きの段階にあります。2024 年時点で、接続待ち行列への参入から商業運転開始までの平均所要期間は 3〜5 年となっています（ レポート 参照）。 図1. The U.S. Clean Energy Backlog (2022年末時点データ, 図表元データ ) 図2. The U.S. generator interconnection queue in 2022 vs. 2023 ( 図表元データ ) 発電設備の系統接続プロセス は主に、系統接続申込み、系統接続検討、系統接続承諾、商業運転の４つの段階で構成されています。新規の発電設備を電力系統に接続する前に、実現可能性検討（Feasibility Study）、系統影響検討（System Impact Study）、設備検討（Facilities Study）として知られる一連の複雑なシミュレーションベースの技術検討を実施する必要があります。これらの接続検討では、１つまたは複数の提案された発電設備が系統全体の信頼性、安定性、性能にどのような影響を与えるかを評価します。この多段階の検討プロセスでは、提案されたプロジェクトの系統接続に必要な設備増強を決定し、関連コストを算出し、個々の影響度に基づいてこれらのコストを提案プロジェクト間で比例配分します。これらの検討結果は、以下の表に示すように、接続プロセスの後続段階の判断材料となります。 表1. 発電設備の相互接続プロセス概要 これらの検討は、長期化する系統接続プロセスの唯一の要因ではありませんが、間違いなく重要な要因の一つとなっています。検討の3つのフェーズ、すなわち実現可能性検証（通常 30-60 日）、システムインパクト検証（通常 90-180 日）、そして設備検証（通常 90-180 日）は、全体として考えると６ヶ月から２年以上かかる可能性があります。実際には、検討の複雑さ、再検討の必要性、またはリソースの制約により、目標とする期間を超えて検討が長引くことが少なくありません。 電力会社/系統運用者/AWSにとってのビジネス機会 連邦エネルギー規制委員会（FERC）は、「 発電設備の系統接続手続きと契約の改善 」と題された Order No. 2023 を通じて、発電設備の系統接続プロセスの合理化に向けた施策を実施しました。本命令の重要な側面として、送電事業者に対し、従来の「先着順」による逐次的なアプローチから、より効率的な「準備が整った順」によるクラスター方式での検討手法への移行を義務付けています。この移行により、複数のプロジェクトを同時に評価することが可能となり、系統接続待ち行列の進捗を加速することを目指しています。この新しいアプローチは、クラウド技術を活用することで、従来は時間のかかっていた重要な系統接続検討を大幅にスケールアップし加速する機会を系統接続のバリューチェーン全体の関係者にもたらします。この変更は、系統接続プロセスのボトルネック解消を実現するだけでなく、新規の電源を電力系統により迅速に統合するという広範な目標にも沿うものとなっています。 従来型ITリソースにおける系統接続検討の技術的課題 系統接続検討は通常、従来型ITインフラを基盤とするオンプレミスのサーバー群で実行されていますが、以下のような技術的課題が存在します： 検討量に対する計算リソースの不足： 系統接続検討、特にクラスター方式でのプロジェクト申込みを含む複雑なシステムの検討には、大きな計算能力が必要です。オンプレミスシステムでは、増加する検討の複雑さや量に対応できず、処理時間の長期化につながる可能性があります。 スケーラビリティの問題： オンプレミスシステムはスケーラビリティが限定的で、ピーク時やクラスター検討のためのリソースを迅速に増強することが困難です。さらに、容量増強のための新規ハードウェア追加には、多くの場合、コストと時間がかかります。 データ管理： 複数の検討から生成される大量のデータの保存と管理は、ローカルストレージシステムに負担をかけます。ローカルシステムでのデータバックアップの確保は、困難かつリソース集約的となる可能性があります。 協業の困難さ： オンプレミス環境では、特に検討が個々のワークステーションで分断されて実施される場合、チームメンバー間のリアルタイムな協業が妨げられます。他のメンバーがどのような作業を実行しているか、その進捗状況の把握、トラブルシューティングでの相互支援が困難です。また、大規模なデータセットや結果を外部の関係者と共有することも煩雑になります。 可用性と災害復旧： ローカルハードウェアの障害は、大幅なダウンタイムや潜在的なデータ損失につながる可能性があります。 目標復旧時間（RTO）と目標復旧時点（RPO） の要件を満たすことは、オンプレミスシステムではより困難かつ高コストとなる可能性があります。 先進技術へのアクセス制限： オンプレミスシステムでは、 系統接続検討の最適化に活用されている人工知能（AI）や機械学習（ML） などの先進技術の導入が困難な場合があります。 所有コスト： 複雑な検討に必要な高性能計算リソースの総所有コスト（TCO）は、オンプレミスで維持する場合、多額になる可能性があります。 ソリューション 発電設備の系統接続は、主要な産業拠点や電力需要の高い人口密集都市部に大容量の電力を供給する上で極めて重要です。この課題は電力会社やメーカーの懸念にとどまらず、世界最大の再生可能エネルギー購入者である Amazon にとっても特に重要な意味を持っています。 さらに、生成 AI の急速な普及により、データセンターの電力需要は前例のない成長を示しています。これらの増大するエネルギーニーズに対応するには、迅速な配慮が必要です。電力系統への新規電源接続を制限している技術的障壁を克服しなければなりません。この技術的なチャレンジは、 系統の拡張と近代化 に対して、より適した手法を確立するために継続的な政策改革の取り組みを補完するものとなるべきです。 本記事では、発電設備の系統接続検討プロセスにおける主要な課題に対処するため、AWS 上の包括的かつカスタマイズされたソリューションフレームワークを提示することで、発電設備の系統接続に対する重要な評価を大幅に迅速化・改善する AWS の多様な機能を紹介します。 以下の図は、サーバーレスベースのワークフローオーケストレーションと拡張性の高い HPC（High Performance Computing）クラスターを使用した系統接続検討アクセラレーターの拡張リファレンスアーキテクチャを示しています。この最新の設計図は、以前公開した ガイダンス を基に、計算サービス選択の柔軟性向上という重要な改善を加えたものです。この柔軟性により、ユーザーは特定の検討要件に応じて計算環境を調整し、様々な系統接続検討タスクのパフォーマンスとリソース配分を最適化できます。このソリューションでは、 AWS Step Functions を使用して検討プロセスをオーケストレーションします。実行時間、データの共通性、複雑さ、ランタイム依存関係などのタスク特性に応じて、Step Functions のステートは、 AWS Lambda 、 AWS Fargate 上の Amazon Elastic Container Service （Amazon ECS）、または AWS ParallelCluster （あるいは、HPCワークロードの実行とスケーリングを管理するサービスである AWS Parallel Computing Service ）上で実行できます。ユーザーは、これらのスケーラブルな計算サービスを柔軟に組み合わせて、複雑な分析を実行できます。例えば、Lambda 関数は 15 分の実行制限があるため、目的の系統接続待ち行列からのリクエスト取得などの短時間の計算タスクに理想的です。一方、Fargate 上のECSは、リモートリポジトリからの共通データバンドルの取得（ダウンロードと抽出）など、より長時間のタスクに適しています。事故解析、短絡解析、過渡安定度解析、投資最適化などの計算負荷の高い時間のかかるエンジニアリングシミュレーションジョブについては、Step Functions が ParallelCluster などの HPC クラスターを指定して処理することができます。 図3. 発電設備系統接続検証プロセスのリファレンスアーキテクチャ このソリューションは、フロントエンドは AWS Amplify を使用してフルスタックの Web アプリケーションを構築・ホストします。Web ユーザーインターフェースへのログイン前に、ユーザーは Amazon Cognito で認証され、管理者、標準ユーザー、レビュアー、承認者などの特定の役割を割り当てられます。また、ユーザーデータとタスク情報の保存には Amazon DynamoDB を使用します。 AWS AppSync は、Web ポータルでの情報表示のために NoSQL データベースへのクエリが可能な GraphQL API を作成するために使用されます。 高性能ファイルシステムとして、 Amazon FSx for Lustre 、または OpenZFS が構成され、Lambda、Amazon ECS、およびHPC クラスターと接続して、系統接続検討ツールによって生成される中間結果および統合結果を保存します。WebUI からのデータアクセスについては、このアーキテクチャ設計では、 AWS DataSync を使用して、Amazon FSx から、Amplify バックエンドのストレージリソースとして統合されている Amazon S3 に、選択されたデータを移動します。 このソリューションでは、 AWS CodePipeline を使用して DevOps プラクティスを実装し、Amplify コードと Amazon ECS タスクコンテナアーティファクトの両方のビルド、テスト、デプロイプロセスを自動化しています。継続的インテグレーションと継続的デリバリー（CI/CD）パイプラインの一部として、 AWS CodeConnection と AWS CodeBuild を組み込んでいます。この統合されたアプローチにより、開発ワークフローが効率化され、開発チームと運用チーム間のコラボレーションが向上します。 このソリューションの主な特徴は以下の通りです： マルチユーザー、マルチジョブの実行をサポート 並列実行の最大同時実行数を制御可能 イベント（ジョブ実行要求時）駆動のサーバーレスワークフローとアイドル時にゼロまでスケールダウンする弾力的な HPC クラスターにより、高いコスト効率を実現 フロントエンドと統合されたユーザー認証とAPI認可 ユーザー体験を向上させ、学習曲線を緩やかにする独立した WebUI 管理者、ユーザー、承認者など、異なる役割に対するきめ細かなアクセス制御 系統接続プロセスは組織によって異なり、各 RTO/ISO （訳註：北米では送電事業に TSO 以外に RTO：広域送電機関、ISO：独立系統運用機関が存在します）が設定した基準に基づいて地域ごとに検討サイクルが異なります。以下の図は、カスタマイズ可能なワークフローを編成するためのソリューションアーキテクチャの機能を示しています。このサンプルは、系統接続検討の全ステップを完全に実装したものではありません。むしろ、スケーラビリティ、信頼性、性能効率、コスト最適化を実現するために、サーバーレスサービスと HPC サービスを使用してどのように主要タスクを実行できるかを示すものです。このサンプルは、ユーザーが構築を進めるための基盤を提供します。AWS Step Functions を使用することで、ユーザーは実際の検討サイクルを正確に反映したより高度なワークフローを作成できます。Step Functions は様々な AWS コンピューティングサービスとの統合を可能にし、特定のジョブ要件に合わせて調整できます。ユーザーは、基本的なフレームワークを、各々の特定のプロセスに沿ったより包括的なシステムに拡張できる柔軟性を持っています。 図4. 系統接続検証のサンプルワークフロー このプロセスを実現するために、系統接続検討ワークフローの重要なステップすべてを実行する、様々なオープンソースの電力系統解析ツール（ GridCal 、 GridStatus 、 ANDES 、 PyPSA 、およびその関連ライブラリ PyPSA-USA ）を使用しています。これらのツールはすべて Python ベースのパッケージで、デプロイメントの柔軟性を提供します。Lambda、Fargate 上の ECS、ParallelCluster など、前述のすべての種類の計算環境で実行可能です。このアプローチは、電力系統解析における様々な計算ニーズに対応するクラウドベース環境内での、これらツールの汎用性とスケーラビリティを実証しています。 Step Functions では、先に定義したワークフローに基づいてステートマシンが作成されます。このステートマシンは、Task（タスク）、Choice（選択）、Fail（失敗）という3つの主要なステート型を組み込んでいます。Choice ステートはフロー制御メカニズムとして機能し、指定された条件に基づいて実行パスを制御します。この例では、特定のデータの存在有無に基づいてタスクを実行するか省略するかを制御します。Failステートは、失敗とタイムアウトの両方を含む例外を処理し、エラー管理の標準的な方法を提供します。各 Task ステートには、以下に示す定義による再試行ロジックが装備されており、一時的な障害が発生した場合に複数回の実行試行を可能にします。タスクが最大再試行回数を超えた場合、ワークフローは終了し、Fail ステートに移行します。この構造により、系統接続検討プロセス全体を通じて、堅牢なエラー処理とフロー制御が確保されます。 図5. Step Functions の系統接続検証ワークフロー定義 { ... "Retry": [ { "ErrorEquals": [ "Lambda.ServiceException", "Lambda.AWSLambdaException", "Lambda.SdkClientException", "Lambda.TooManyRequestsException" ], "IntervalSeconds": 1, "MaxAttempts": 3, "BackoffRate": 2 } ] ... } このステートマシンは、 AWS Systems Manager Run Command API を通じて ParallelCluster に系統接続検討シミュレーションジョブを投入する必要のあるタスクを管理するため、 コールバック待機 パターンを統合した標準的な Lambda 関数テンプレートを使用します。このコールバックメカニズムにより、ジョブ完了を示すタスクトークンを受信するまでワークフローを一時停止することができます。クラスターに投入されたジョブが完了すると、タスクの状態（成功： SendTaskSuccess 、または失敗： SendTaskFailure ）を報告するコールバック関数が起動されます。このアプローチにより、ワークフロー内の長時間実行される非同期プロセスを効率的に管理し、検討における順序依存性の整合性を維持できます。これにより、段階的な検討の各フェーズが適切に後続のステージに情報を伝え、開始することが可能となります。 ステートマシンからジョブを受信すると、HPC クラスターは以下の高度なジョブ管理プロセスを実行します： ジョブのキューイングとスケジューリング： 受信したジョブは初めにキューに配置され、処理のためにスケジューリングされます。 動的スケーリング： クラスターは、キューに入れられたジョブを効率的に処理するために必要に応じて計算最適化ノードを動的にプロビジョニングします。 固有のジョブ識別子： 各ジョブには以下の要素からなる固有の識別子が割り当てられます： ユーザー名 投入タイムスタンプ ジョブタイプ ジョブ番号 処理コアインデックス 出力ファイルの命名規則： クラスターはこの固有識別子を使用して、一貫したパターンで出力ファイルに名前を付けます。この命名戦略は以下の2つの重要な目的を果たします： 各出力に固有の名前を付けることでファイル名の競合を防止 誤ったファイルの上書きのリスクを排除 この体系的なアプローチにより、複数の系統接続検討を同時に実行する場合でも、効率的なジョブ処理、スケーラブルなリソース使用、および整理された出力管理が確保されます。 図6. ジョブキューステータスと出力結果 (クラスター管理者がアクセス可能） このソリューションでは、Fargate 上の ECS クラスターを使用して、ParallelCluster で実行されるもの以外の様々な系統接続検討タスク（ベースモデルの選択、クラスター化された接続要求に関連するプロジェクトデータセットの取得、ネットワークモデルの構築など）を実行します。多様な計算環境間でのシームレスなデータアクセスと永続性を確保するため、FSx ボリュームが作成され、ParallelCluster、Amazon ECS タスク、およびコンテナイメージを使用する Lambda 関数に対してマウントされます。 ワークフローの終了時に、Lambda 関数が起動され、２つの重要なタスクを実行します。第一に、検討プロセス全体で生成された分析結果を集約し、包括的な検討レポートを作成します（レポート作成には生成 AI の活用も可能）。第二に、DataSync タスクを開始し、マウントされた FSx ボリュームから出力層の S3 バケットへ選択的にデータを転送し、最終的な検討結果の効率的な保存とアクセシビリティを確保します。 前述のように、ソリューションのフロントエンドは Amplify でホストされ、 Cloudscape デザインシステムを使用したユーザーフレンドリーな Web インターフェースを提供します。このインターフェースにより、ユーザーはジョブの実行依頼、ジョブステータスの監視、および詳細な段階的分析結果を含む包括的な検討レポートを圧縮ファイル形式でダウンロードすることができます。ユーザー体験は直感的で魅力的であり、スケーラブルな包括性を備えています。 図7. 発電設備の系統接続検証用の Web アプリケーションホームページ ユーザーの観点から見ると、系統接続検討の一連のプロセスは以下のように展開されます： 開始： ユーザーが個別またはクラスター化された系統接続待ち行列リクエストを指定するトリガーファイルを Amazon S3 のランディングゾーンバケットにアップロードすることで実行が始まります。 前処理： このアップロードが Lambda 関数を起動し、データの整合性チェックを実行します。 ワークフロー開始： Lambda 関数が Step Functions を通じてステートマシンを開始し、同時に実行に関するメタデータを DynamoDB テーブルに記録します。 データ保存： DynamoDB テーブルには、 RunId, Owner, SubmissionTime, SourceFileName, OutputFileName, OutputFileLocation などの重要な情報が保存され、 RunId と Owner がそれぞれパーティションキーとソートキーとして機能します。 リアルタイム更新： AppSync を活用した GraphQL API が定期的にこのテーブルをクエリし、すべてのプラットフォームユーザーに最新情報を提示します。 進捗監視： ユーザーは、 Amazon API Gateway が管理する WebSocket 接続を通じて、特定の実行の進捗を追跡できます。(詳細は、こちらの AWS sample ) 結果アクセス： 完了後、検討結果が出力層の S3 バケットからダウンロード可能になります。アクセスはオブジェクトタグで指定されたユーザーグループのメンバーシップに基づいて条件付きで許可され、コラボレーションとデータセキュリティの両立を確保します。 この包括的なアプローチにより、堅牢なセキュリティと効率的なデータ管理を維持しながら、ユーザーの系統接続検討プロセスとの対話がスムーズになります。 図8. 発電設備の系統接続検証の Web アプリケーションのダッシュボード（系統ネットワークのトラフィックビュー） 図9. 発電設備の系統接続検証の Web アプリケーションの 「Runs（実行）」ページ 図10. 発電設備の系統接続検証の Web アプリケーションの「Run details（実行詳細）」ページ 複数のエンジニアが同時に系統接続検討を実行する実際のシナリオをシミュレートするため、プラットフォーム上で同時実行テストを実施しました。Lambda、Step Functions、Fargate 上の ECS を使用するこのソリューションのサーバーレスアーキテクチャは、これらの並列実行要求を効率的に管理する堅牢な能力を実証しました。このアーキテクチャに備わるスケーラビリティと非同期処理モデルにより、複数の同時検討要求をシームレスに処理することが可能となり、高負荷状況下でもレスポンス性能とパフォーマンスを確保することができました。 図11. 異なるユーザーによって開始された複数ワークフローの同時実行 まとめ 再生可能エネルギー発電の急速な成長により、系統接続プロセスに大きな課題が生じており、新規のクリーンエネルギープロジェクトの電力系統への接続検討に長い待機時間と遅延が発生しています。本記事では、これらの課題に対処し、系統接続検討プロセスを加速するためのAWSクラウドテクノロジーを活用した革新的なソリューションを提示します。 サーバーレスワークフローオーケストレーションと弾力的な高性能計算を組み合わせることで、提案するアーキテクチャは複雑な系統接続検討を実施するための、スケーラブルで費用対効果が高く効率的なアプローチを提供します。このクラウドベースのソリューションは、従来のオンプレミスシステムの多くの重要な制約に対処し、改善されたスケーラビリティ、協業能力、コスト効率を提供します。系統接続検討プロセスの効率化により、新規電源の系統統合におけるボトルネックを大幅に削減し、最終的によりクリーンで回復力のある電力系統への移行を支援することができます。 エネルギー情勢が進化し続ける中、電力会社、系統運用機関、その他の関係者にとって、クラウドコンピューティングは強力なプラットフォームとなります。このようなクラウドベースのソリューションを採用することで、これらの組織はよりサステナブルなエネルギーの未来に向けた取り組みを加速することができます。これらのアプローチは、再生可能エネルギーの統合と電力系統の近代化に対する増大するニーズへの対応に不可欠です。 本ブログは、ソリューションアーキテクトの丹羽が翻訳しました。原文は こちら です。 Dr. Song Zhang Dr. Song Zhang は、AWS エネルギー・ユーティリティ部門のシニアインダストリーソリューションスペシャリストです。HPC、IoT、AI/ML およびデータ分析を活用した AWS 上での電力事業者向けの系統ソリューションの近代化をリードしています。AWS に入社する前は、電力業界で 15 年の経験を積んでいました。Song はまた、積極的なコミュニティリーダーおよび貢献者でもあります。IEEE PES ワーキンググループ「Cloud4PowerGrid」の議長、IEEE PSOPE 技術革新小委員会の副議長、および IEEE Transactions on Cloud Computing の運営委員会メンバーを務めています。 Abhishek Naik Abhishek は、AWS エネルギー部門の電力・ユーティリティ向けソリューションアーキテクチャグループを率いるシニアマネージャーです。インフラストラクチャの設計・構築および製品ソリューションの主導において 15 年以上の経験を有しています。テクノロジーを活用して、お客様のビジネス成果の加速と事業運営の脱炭素化を支援しています。AWS 上でのお客様の成功を確実にするため、技術的なガイダンスと専門知識の提供、および実装プロジェクトの設計・主導を行っています。仕事以外では、Abhishek はアウトドア活動を楽しんでいます。