みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊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 はアウトドア活動を楽しんでいます。

5 月 15 日より、 AWS CodeBuild の Docker サーバー機能を使用して、CodeBuild プロジェクト内で直接、永続的な専用 Docker サーバーをプロビジョニングできるようになりました。Docker サーバー機能を使用すると、イメージのビルドをリモートホストに集中化することで Docker イメージのビルドを高速化でき、待機時間を短縮して、全体的な効率を高めることができます。 私のベンチマークでは、この Docker サーバー機能を使用することで、ビルドの合計時間が 24 分 54 秒から 16 秒へと 98% 短縮されました。ここでは、私の AWS CodeBuild プロジェクトを用いて、この機能について簡単に見ていきます。 AWS CodeBuild は、ソースコードをコンパイルし、テストを実行して、デプロイ可能なソフトウェアパッケージを生成する、フルマネージド継続的インテグレーションサービスです。Docker イメージのビルドは、CodeBuild のお客様にとって最も一般的なユースケースの 1 つです。このサービスでは、時間が経過する中で、Docker ビルドのパフォーマンスを改善するために、 Docker レイヤーのキャッシュ や リザーブドキャパシティ機能 などの機能をリリースすることで、このエクスペリエンスを徐々に改善してきました。 新しい Docker サーバー機能で、一貫性のあるキャッシュを提供する永続的な Docker サーバーを提供することで、アプリケーションのビルド時間を短縮できます。CodeBuild プロジェクトで有効にすると、専用 Docker サーバーがプロビジョニングされ、Docker レイヤーのキャッシュを維持する永続的なストレージが提供されます。このサーバーは複数の同時 Docker ビルドオペレーションを処理でき、すべてのビルドで同じ集中キャッシュを利用できます。 AWS CodeBuild の Docker サーバーの使用 新しい Docker サーバー機能の利点を示すデモをご紹介します。 このデモでは、公式の AWS CodeBuild 厳選 Docker イメージリポジトリ 、具体的には 標準 Ubuntu イメージ をビルドするための Dockerfile に基づいて、複雑かつ多層的な Docker イメージを構築します。このイメージには、最新の継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインに必要な多数の依存関係とツールが含まれており、開発チームが定期的に実行する大規模な Docker ビルドの好例となります。 # Copyright 2020-2024 Amazon.com, Inc. or its affiliates.All Rights Reserved. # # Amazon ソフトウェアライセンス (以下「ライセンス」という) に基づいてライセンスされています。ライセンスに従わない限り、このファイルを使用してはなりません。 # ライセンスのコピーは、 # # http://aws.amazon.com/asl/ # # またはこのファイルに付属の「license」ファイルにあります。 # このファイルは「現状有姿」で配布されるものであり、明示または黙示を問わず、いかなる種類の保証または条件もありません。 # ライセンスに基づく権限および制限を規定する具体的な文言については、ライセンスを参照してください。 FROM public.ecr.aws/ubuntu/ubuntu:20.04 AS core ARG DEBIAN_FRONTEND="noninteractive" # git、SSH、Git、Firefox、GeckoDriver、Chrome、ChromeDriver、stunnel、AWS Tools をインストールし、SSM を設定して、AWS CLI v2、ランタイム用の環境ツール: Dotnet、NodeJS、Ruby、Python、PHP、Java、Go、.NET、Powershell Core、Docker、Composer、および他のユーティリティをインストールします COMMAND REDACTED FOR BREVITY # イメージバージョンに固有のランタイムバージョンをアクティブ化します。 RUN n $NODE_14_VERSION RUN pyenv global $PYTHON_39_VERSION RUN phpenv global $PHP_80_VERSION RUN rbenv global $RUBY_27_VERSION RUN goenv global $GOLANG_15_VERSION # SSH を設定します COPY ssh_config /root/.ssh/config COPY runtimes.yml /codebuild/image/config/runtimes.yml COPY dockerd-entrypoint.sh /usr/local/bin/dockerd-entrypoint.sh COPY legal/bill_of_material.txt /usr/share/doc/bill_of_material.txt COPY amazon-ssm-agent.json /etc/amazon/ssm/amazon-ssm-agent.json ENTRYPOINT ["/usr/local/bin/dockerd-entrypoint.sh"] この Dockerfile は、複数のプログラミング言語、ビルドツール、依存関係を備えた包括的なビルド環境を作成します。これはまさに、永続的なキャッシュの利点を享受できるタイプのイメージです。 ビルド仕様 (buildspec) では、 docker buildx build . コマンドを使用します: version: 0.2 phases: build: commands: - cd ubuntu/standard/5.0 - docker buildx build -t codebuild-ubuntu:latest . Docker サーバー機能を有効にするには、AWS CodeBuild コンソールに移動し、 [プロジェクトを作成] を選択します。既存の CodeBuild プロジェクトを編集する際にも、この機能を有効にできます。 すべての詳細と設定を入力します。 [環境] セクションで、 [追加設定] を選択します。 その後、下方向にスクロールして [Docker サーバー設定] を見つけ、 [このプロジェクトのために Docker サーバーを有効にする] を選択します。このオプションを選択すると、Docker サーバーのコンピューティングタイプの設定を選択できます。設定が完了したら、このプロジェクトを作成します。 ここからは、Docker サーバー機能が実際にどのように機能するのかを見てみましょう。 最初のビルドは、すべての依存関係を最初からダウンロードしてコンパイルする必要があるため、完了までに約 24 分 54 秒かかります。このような複雑なイメージの最初のビルドでは、通常この程度の時間がかかります。 コード変更のない後続のビルドでは、ビルド時間はわずか 16 秒です。これは、98% のビルド時間の短縮となります。 ログを見ると、Docker サーバーではほとんどのレイヤーが永続キャッシュからプルされていることがわかります。 Docker サーバーが提供する永続キャッシュは、ビルド間ですべてのレイヤーを維持します。これは、多くのレイヤーを持つ大規模かつ複雑な Docker イメージで特に役立ちます。このことは、CI/CD パイプラインで多数の Docker ビルドを実行するチームのスループットを Docker サーバーが劇的に増大できることを意味しています。 その他の知っておくべきこと いくつかの留意点を次に示します: アーキテクチャサポート – この機能は、x86 (Linux) ビルドと ARM ビルドの両方でご利用いただけます。 料金 – Docker サーバー機能の料金の詳細については、「 AWS CodeBuild の料金 」ページをご覧ください。 利用できるリージョン – この機能は、AWS CodeBuild が提供されているすべての AWS リージョンでご利用いただけます。CodeBuild が利用可能な AWS リージョンの詳細については、 AWS リージョンのページ をご覧ください。 Docker サーバー機能の詳細については、 AWS CodeBuild のドキュメント をご覧ください。 構築がうまくいきますように! – Donnie Prakoso 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

5 月 15 日、NVIDIA B200 を搭載した Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 インスタンス の一般公開を開始しました。この新しいインスタンスは、 人工知能 (AI) 、 機械学習 (ML) 、 ハイパフォーマンスコンピューティング (HPC) アプリケーションにおける高いパフォーマンスとスケーラビリティへのニーズに応えます。 Amazon EC2 P6-B200 インスタンスは GPU 対応の幅広いワークロードを高速化しますが、中でも、強化学習 (RL) と蒸留を用いた 基盤モデル (FM) の大規模な分散 AI トレーニングおよび推論、マルチモーダルトレーニングおよび推論のほか、気候モデリング、創薬、地震分析、保険リスクモデリングなどの HPC アプリケーションにも適しています。 Elastic Fabric Adapter (EFAv4) ネットワーキング、 EC2 UltraClusters を用いたハイパースケールクラスターリング、 AWS Nitro System を用いた高度な仮想化およびセキュリティ機能と組み合わせることで、速度、スケール、セキュリティを強化しつつ、FM のトレーニングとサービス提供を実現しています。さらに、これらのインスタンスは、 EC2 P5en インスタンス と比較して、AI トレーニング (トレーニング時間) と推論 (トークン/秒) のパフォーマンスが最大 2 倍向上しています。 FM トレーニングの市場投入までの時間を短縮しながら、推論スループットを高速化できます。これにより、推論コストを削減し、生成 AI アプリケーションの採用を促進できるだけでなく、HPC アプリケーションの処理性能も向上します。 EC2 P6-B200 インスタンスの仕様 新しい EC2 P6-B200 インスタンスには、1440 GB の高帯域幅 GPU メモリを搭載した 8 機の NVIDIA B200 GPU、第 5 世代インテル Xeon スケーラブルプロセッサ (Emerald Rapids)、2 TiB のシステムメモリ、30 TB のローカル NVMe ストレージが搭載されています。 EC2 P6-B200 インスタンスの仕様は次のとおりです。 インスタンスサイズ GPU (NVIDIA B200) GPU メモリ (GB) vCPU GPU ピアツーピア (GB/秒) インスタンスストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) P6-b200.48xlarge 8 1440 HBM3e 192 1800 8 x 3.84 NVMe SSD 8 x 400 100 これらのインスタンスは、P5en インスタンスと比較して GPU TFLOP が最大 125% 向上、GPU メモリサイズが 27% 増加、GPU メモリ帯域幅が 60% 増加しています。 稼働中の P6-B200 インスタンス 米国西部 (オレゴン) AWS リージョン では、 ML 用 EC2 キャパシティブロック を介して、P6-B200 インスタンスを利用できます。EC2 キャパシティブロックを予約するには、 Amazon EC2 コンソール で、 [キャパシティ予約] を選択します。 [ML 用キャパシティブロックを購入] を選択してから合計容量を選択し、 p6-b200.48xlarge インスタンス用の EC2 キャパシティブロックが必要な期間を指定します。EC2 キャパシティブロックを予約できる合計日数は、1 ～ 14 日間、21 日間、28 日間、または 7 日単位で、最長 182 日までです。利用開始日は、最大で 8 週間先まで選択可能です。 これで、EC2 キャパシティブロックが正常にスケジュールされます。EC2 キャパシティブロックの合計料金は前払いで請求され、購入後に料金が変更されることはありません。支払いは、EC2 キャパシティブロックを購入してから 12 時間以内にお客様のアカウントに請求されます。詳細については、Amazon EC2 ユーザーガイドの「 Capacity Blocks for ML 」を参照してください。 P6-B200 インスタンスの起動時には、 AWS Deep Learning AMI (DLAMI) を使用して EC2 P6-B200 インスタンスをサポートできます。DLAMI は、事前設定された環境でスケーラブルで安全な分散型 ML アプリケーションをすばやく構築するためのインフラストラクチャとツールを ML の専門家や研究者に提供します。 インスタンスの起動には、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用できます。 EC2 P6-B200 インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon FSx for Lustre などの各種 AWS マネージドサービスとシームレスに統合できます。 Amazon SageMaker HyperPod にも間もなく対応予定です。 今すぐご利用いただけます Amazon EC2 P6-B200 インスタンスは、現在、米国西部 (オレゴン) リージョンで利用可能で、 ML 用 EC2 キャパシティブロックとして購入できます 。 Amazon EC2 コンソール で Amazon EC2 P6-B200 インスタンスをお試しください。詳細については、 Amazon EC2 P6 インスタンスのページ をご確認ください。ご意見やご要望がありましたら、 EC2 の AWS re:Post 、または通常の AWS サポート窓口までお寄せください。 – Channy 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

2025 年 4 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Managed Workflows for Apache Airflow (MWAA) Amazon Managed Workflows for Apache Airflow (MWAA) は、オープンソースの Apache Airflow のマネージドサービスで、ワークフローと呼ばれる一連のタスクを Python で作成し、実行、監視、スケジュールできます。本セミナーでは、MWAA の概要や他のサービスとの使い分けについて、デモを交えながらご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 MWAA に関心がある、またはご利用予定の方 AWS でワークフローを作成したいが、どのサービスを使うか検討中の方 既存の Airflow を利用していて、MWAA に移行予定の方 本 BlackBelt で学習できること Airflow, MWAA のサービス概要と機能を学習できます。 MWAA を使ってワークフローを実行するまでに実施する内容が分かります。 MWAA と 他のサービス (Step Functions など) の特徴が分かります。 スピーカー 佐藤 悠 プロフェッショナルサービス Savings Plans Savings Plans は、1 年または 3 年の期間で特定の使用量を契約するかわりに、オンデマンド料金と比較して低料金を実現する柔軟な料金モデルです。本セッションでは、Savings Plans の概要、購入方法および購入計画などについて説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Savings Plans の概要や購入方法を知りたい方 Savings Plans のコミットメントに迷っている方 コンピューティングワークロードのコスト最適化を促進したい方 本 BlackBelt で学習できること Savings Plans の概要・購入方法について学んでいただけます コミットメントを決める購入計画や購入後のモニタリングについても紹介します スピーカー 加須屋 悠己 テクニカルアカウントマネージャー AWS Database Migration Service ベストプラクティス – 計画編 AWS Database Migration Service は、オンプレミスから AWS へのデータベース移行や異なるエンジン間でのデータ連携など、データベース間でのデータ移行に役立つデータベースサービスです。難易度の高いデータ移行が容易に移行できるようになることから、多くのお客様のデータ移行で採用頂いています。本セミナーでは、データベース移行を計画する上で知っておきたいノウハウやベストプラクティスについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これからデータベースの移行を予定されている方 データベース間のデータ連携を検討している方 AWS Database Migration Service を用いた DB 移行やレプリケーションについてさらに深く学びたい方 本 BlackBelt で学習できること 移行計画を立てる際に事前に確認しておくべきポイント テスト移行の重要性と進め方 DMS の各機能の活用と使い分け DMS における移行完了判定の手法 スピーカー 菅原 照太 クラウドサポートエンジニア AWS Backup で考える DR 戦略 #1 基本編 AWS Backup は、AWS サービス全体のデータのバックアップを一元的にオーケストレーションし、自動化できるフルマネージドサービスです。Disaster Recovery (DR) というユースケースに対して AWS Backup がどのように活用できるかという点を機能とともにご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 DR 戦略において AWS Backup がどのように活用できるか知りたい方 AWS Backup の概要を知りたい方 AWS Backup を用いたバックアップ方法を学びたい方 本 BlackBelt で学習できること AWS 上での DR 戦略の概要 AWS Backup の概要 AWS Backup でのバックアップ取得方法 スピーカー 小島 七海 クラウドサポートエンジニア Amazon Connect 最新・重要アップデート ( 2024 年 1 月 〜 2025 年 3 月 ) Amazon Connect が東京リージョンでローンチされてから 6 年が経ちたくさんの新機能が追加されてきました。この動画では 2024 年 1 月から 2025 年 3 月までに発表された、Amazon Connect のアップデートの中から、特に重要なアップデートについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のお客様、パートナーの方 Amazon Connect のご利用をご検討中の方 Amazon Connect のアップデートを知りたい方 本 BlackBelt で学習できること 2024 年 1 月から 2025 年 3 月までに発表された、Amazon Connect のアップデートの中から、特に重要なアップデートについてキャッチアップすることができます。 スピーカー 濱上 和也 ソリューションアーキテクト Amazon Chime SDK WebRTC Media 編 音声や動画によるリアルタイムコミュニケーション機能を組み込んだアプリケーションの開発を検討されている方や、既存のアプリケーションの拡張や運用などで課題感をお持ちの方に対して、Amazon Chime SDK を使用して、リアルタイムコミュニケーション機能をアプリケーションに実装する方法について、特に WebRTC Media 機能を中心にご説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS についての深い知識や経験はなくても Amazon Chime SDK は利用可能ですが、一方で、クライアントサイドおよびサーバーサイドのアプリケーション開発に関する広範な知識は前提知識として必要になります。 本 BlackBelt で学習できること インテリジェントなリアルタイム通信機能をアプリケーションに組み込むためのソリューションである Amazon Chime SDK について、WebRTC Media 機能を中心にご紹介します。WebRTC Media 機能を利用することで高品質な音声・映像通話、画面共有機能などの機能を簡単にアプリケーションに組み込むことが可能になります。 スピーカー 石井　悠太 ソリューションアーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2025-06 Amazon Timestream 基本編 ソリューションアーキテクト 小林 新一

はじめに 2024/12/13 に待望の Direct Connect 大阪第2ロケーション 「KDDI TELEHOUSE OSAKA2(以下:OSAKA2)」の開設を 発表 しました。日本全体では 5番目、大阪では Equinix OS1(以下:OS1) に続き２番目のロケーションです。これまでは関西以西の国内 DX ロケーション は OS1 しかなく、ロケーション 冗長を取るには、東京にあるロケーション をバックアップルートに選択する必要があり大阪リージョンにワークロードをデプロイしようとしても 東阪間の往復を許容する必要がありました。今回のアップデートにより関西地域に閉じたロケーション冗長を行うことが可能になり、AWS クラウドの大阪リージョンをメインリージョンとしたワークロードおよびハイブリッドネットワークをより最適化することができます。 本イベントでは、この２つのロケーションを用いた冗長アーキテクチャについてご説明をしました。また、ロケーションを提供いただいた KDDI株式会社 様に加え、OSAKA2 へのコネクティビティを提供いただいている 株式会社TOKAI コミュニケーションズ様、株式会社JPIX様にもご登壇いただき、すぐに OSAKA2 を利用したいお客様のニーズに応える内容となっています。 電力、鉄道など関西を事業基盤とされているお客様や、数多くのお客様のシステムを AWS 上に構築いただいている AWS パートナー 様が中心となり、49名の方に参加いただきました。CSAT は 4.67/5(39名からの回答) と非常に満足度が高いイベントとなりました。 アジェンダ 本イベントでは、AWS セッション、パートナー様セッション、デモとバライティに富んだ内容となっております。 タイトル スピーカー 資料 1 Opening & Keynote AWS Shakeel Ahmad Download 2 AWS Direct Connect 大阪第2ロケーション Launch Overview AWS 櫻井俊和 Download 3 Service Introduction by Direct Connect Partners 3.1 AWS Direct Connect サービス KDDI Telehouse 大阪2 開設について KDDI株式会社 森島隆政様、菅原凛太様 (非公開) 3.2 AWS Direct Connect ⼤阪第２ロケーション開設におけるTOKAICOMのご紹介 株式会社TOKAI コミュニケーションズ 鈴木賢様、斎藤貴様 Download 3.3 AWS Direct Connect Telehouse OSAKA2への接続について 株式会社 JPIX 飯塚友久様 Download 4 Routing Topology デモ AWS 丁亜峰、奥村洋介 (非公開) 5 Networking ( 懇親会 ) Opening & Keynote オープニングスピーカーは APJ のスペシャリストチームをリードしている Shakeel から AWS のグローバルインフラストラクチャとダイレクトコネクトについてお話ししました。会場では逐次通訳にて日本語でもお届けしています。 ( Download ) Shakeel Ahmad – Specialist SA Leader, APJ AWS Direct Connect 大阪第2ロケーション Launch Overview 本セッションでは、 AWS Direct Connect の回復性に関する推奨事項 で本番環境のワークロードにはマルチサイト(ロケーション)でのデプロイを推奨していること、OS1/OSAKA2 の冗長構成を組むことで推奨構成を満たしつつ大阪リージョンへ低レイテンシーの接続が期待できることをご説明しました。注意事項として、OS1/OSAKA2 ロケーションは Associated AWS Region が OS1 は東京リージョンに、OSAKA2 は大阪リージョンに設定されています。異なるリージョンに関連付けられていることで、ルーティングを制御するための設定には注意が必要です。ネットワークスペシャリスト SA の奥村さんが投稿されたテックブログ「 AWS Direct Connect のトラフィックコントロールと大阪リージョンとの接続 」にて詳しく説明されています。ご確認ください。 ( Download ) 櫻井 俊和 – Sr. Solutions Architect Service Introduction by Direct Connect Partners ここからはイベントのメインセッションとなります。パートナー様よりOSAKA2 コネクティビティサービスの提供情報についてお話いただきました。 AWS Direct Connect サービス KDDI Telehouse 大阪2 開設について パートナー様セッションのオープニングは ロケーションを提供いただている 株式会社 KDDI 様にご登壇いただきました。はじめにグループ戦略本部 テレハウス企画部 森島様よりKDDI のデータセンターの取り組み、AWSとKDDI の連携について、Telehouse 大阪2について、AWS Direct Connect 接続パターンについてお話しいただきました。具体的な契約手続きについてもふれていただきました。Part 2 として プロダクト本部 ネットワークサービス企画部 菅原様より WVS2 マルチクラウドゲートウェイ の概要と、Telehouse 大阪2開設にむけた将来像についてお話しいただきました。 KDDI株式会社　森島 隆政 様 AWS Direct Connect ⼤阪第２ロケーション開設におけるTOKAICOMのご紹介 続いて、株式会社TOKAI コミュニケーションズ 法人営業部 ⻄⽇本事業部 鈴木様にご登壇いただきました。TOKAI コミュニケーションズ様は国内 14番目のプレミアパートナー (2025/04現在、国内15社)として企業様の AWS 導入をご支援いただいています。すでに閉域網サービス「 BroadLine 」からの AWS 接続サービスを展開されています。2025/04 には 「BroadLine」を九州エリアまで延伸され、多くの西日本エリアのお客様へ提供が可能となりました。後半には 法人営業部 技術開発事業部 齋藤 様にご登壇いただき、 BroadLine と AWS 接続サービスを使用して、OS1、OSAKA2、AT Tokyo CC1 とのレイテンシー比較のテスト結果を発表いただきました。OSAKA2 を経由したの大阪リージョン、東京リージョンとのレイテンシーは、OS1 と同等で安定しており、OS1をご利用のお客様がOSAKA2へ拡張した場合でもこれまでと同等のネットワーク品質が期待されます(計測データは当日のみ、資料非公開)。 ( Download ) 株式会社 TOKAIコミュニケーションズ　鈴木 賢 様 株式会社 TOKAIコミュニケーションズ　齋藤 貴 様 AWS Direct Connect Telehouse OSAKA2への接続について パートナー様セッションの最後として 株式会社JPIX コネクティビティ部 飯塚様にご登壇いただきました。Telehouse OSAKA2 は大阪ビジネスパーク(OBP) に立地しています。 OBP コネクトサービス を利用することで、OSAKA2 に芯線接続が可能となります。利用者は JPIX 様が提供するファイバー網を利用するか、OBPコネクトサービスと連携している 大阪なにわリング に接続することで、OSAKA2 へ接続することが可能です。大阪なにわリングは JR 西日本光ネットワーク様及びBBバックボーン様が光ファイバーを提供しており、提供エリアは大阪市内の主要データセンターから JR 西日本営業管轄エリアに広がります。JPIX様は インターネットエクスチェンジを提供する事業者様ですが、IX ポートサービスで提供される L2 ポートから Telehouse OSAKA2 まで延伸し、構内配線にて AWS Direct Connect への接続が可能な付加サービスとして提供されています。 ( Download ) 株式会社JPIX　飯塚 友久 様 Routing Topology デモ 最後に AWS SAs(丁/奥村) から OS1/OSAKA2 を冗長構成とした経路制御のデモを実施しました。オンプレミス模擬のルータに BGP commuity を設定して、AWS → オンプレミス向きの経路を OS1 を優先するよう変更し、Traceroute コマンドにて確認しました。検証用の回線は TOKAI コミュニケーションズ様より提供いただきました。ありがとうございました。 (左)　丁亜峰 – Solutions Architect　　　　　　　　　　 (右)　奥村洋介 – Network Specialist Solutions Architect おわりに Direct Connect 大阪第2ロケーション(OSAKA2)の登場により、関西以西の国内拠点からは、OS1/OSAKA2 に接続することで関西地域に閉じたロケーション冗長を行うことが可能になりました。２つのロケーションと大阪リージョンを活用することで、ミッションクリティカルなワークロード、低レイテンシーが求められるワークロードに対して要求を満たすことができます。また、これまでOS1 単独ロケーションで回線を冗長されていたお客様は OSAKA2 を利用することで可用性の向上が期待できます。ダイレクトコネクトロケーションまでのコネクティビティはご登壇いただいた皆様をはじめとしたパートナー様によるサービス提供によって成り立っています。本イベントにてOSAKA2 がパートナー様接続サービス含め利用可能な状態であることをお伝えいただきました。ご登壇いただきました KDDI株式会社様、株式会社TOKAI コミュニケーションズ様、株式会社JPIX様に重ねてお礼申し上げます。OSAKA2 のご利用にご興味がある方は、AWS担当営業へご相談ください。 著者: Sr. Solutions Architect　 櫻井 俊和

このブログは 2025 年 4 月 23 日に Margaret O’Toole、Alexis Bateman、Marta Fraga、Paula Csatlos によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 お客様の持続可能性への取り組みを支援するため、2022 年に AWS の請求とコスト管理コンソールに 顧客の二酸化炭素排出量ツール (CCFT) を導入しました。CCFT は、お客様の AWS 利用による炭素排出量を追跡、測定、確認できるツールです。CCFT は、温室効果ガスプロトコルで定義されているスコープ 1 とスコープ 2 の排出量を対象とし、Amazon EC2、Amazon S3、AWS Lambda など、AWS の製品全範囲をカバーしています。排出量はメトリックトン二酸化炭素換算 (MTCO2e) で提供されます。 本日、CCFT の継続的な改善プロセスの一環として、3 つの更新内容を公開します。 データアクセスの簡易化 ：請求とコスト管理 データエクスポートサービス を通じて、お客様の炭素排出量データへのアクセスを容易にします。 より詳細な炭素データ ：CCFT の粒度を高め、AWS リージョンを表示するようになります。 更新された独立検証済みの方法論 ：APEX 社による 検証 済みの更新された配分方法論 (v2.0) と付随する 方法論に関する文書 を公開しています。 これらの変更の結果、お客様は 2025 年 1 月以降の AWS 利用に関して、更新された方法論を反映した炭素排出量を確認できるようになり、一部のお客様は推定排出量の数値に変更が見られる可能性があります。業界の慣行に従い、2024 年 12 月以前の CCFT データは、従来の方法論 v1.0 を引き続き使用します。 CCFT 更新の詳細 1. データへのアクセスを容易に CCFT からのデータをより使いやすくするため、お客様は現在、AWS の請求とコスト管理データエクスポートサービスを通じて 2025 年 1 月のデータをエクスポートできるようになりました。お客様が AWS Organizations を使用している場合、炭素排出量データのエクスポートは、管理アカウントにリンクされているすべてのメンバーアカウントの炭素排出量推定値を提供します。データエクスポートサービスは、CSV または Parquet 形式で月次更新を自動的に Amazon S3 に配信し、お客様は AWS 組織全体で炭素データの処理を自動化できます。最初のエクスポートでは履歴分析を可能にするため、S3 バケットに最大 38 ヶ月分の履歴データが提供されます。2024 年 12 月以前のデータはバージョン 1.0 の方法論を使用して計算され、2025 年 1 月以降はバージョン 2.0 を使用します。データエクスポートの設定方法の詳細については、 データエクスポートユーザーガイド をご参照ください。 2. AWS リージョン別の詳細度 お客様は現在、AWS リージョン（例：米国東部（オハイオ））ごとに炭素排出量の内訳を確認でき、Amazon CloudFront CDN の使用量も別途表示されます（単一のグローバルサービスカテゴリとして表示）。これにより、お客様は AWS 上のワークロードのリージョン分布を再評価する際に、カーボンフットプリントに最も寄与しているリージョンを特定できます。 3. 更新された v2.0 の方法論 お客様は多くの場合、複数のリージョンにまたがって幅広い AWS サービスを使用しており、その結果、ワークロードに基づく炭素排出量の追跡と配分が課題となっています。クラウド使用に関するお客様への炭素排出量の配分について業界標準は存在しませんが、v2.0 の方法論の更新では、CCFT をサポートするために既存の基準を活用しました。これには以下が含まれます： GHG プロトコルコーポレートスタンダード 、 GHG プロトコルプロダクトスタンダード 、 ISO 14040 / 44 (LCA) 、 ISO 14067 （製品のカーボンフットプリント）、 ICT セクターガイダンス 。 お客様は 方法論に関する文書 で詳細を確認できますが、以下にアプローチの概要を示します： スコープ 1 排出量 (直接) の概要 v2.0 版 スコープ 1 には、AWS が所有または管理する発生源からの直接排出が含まれます。例えば、データセンターのバックアップ発電機での燃料燃焼などです。AWS は、Amazon の年次保証プロセスの結果として、前年のスコープ 1 活動データを翌暦年の第 1 四半期に受け取ります。その後、サイトレベルの粒度で推定炭素データを計算し、クラスターレベルに集計します。AWS クラスターは、AWS リージョン（例：us-east-1、eu-central-1）または AWS CloudFront Edge Cluster（例：北米の CloudFront、南米の CloudFront）となります。 スコープ 2 排出量 (間接) の概要 v2.0 版 スコープ 2 には、購入電力からの間接排出が含まれ、CCFT ではマーケットベース方式を採用しています。例えば、グリッドミックス（グリッドからのカーボンフリーエネルギーの割合）や排出係数 (kgCO2e/kWh) は毎年更新され、Amazon のカーボンフットプリント保証の一環として検証されます。スコープ 2 について、CCFT はロケーションに基づく排出係数を使用し、温室効果ガスプロトコルが推奨する排出係数の階層に従っています。 v2.0 の配分概要 このモデルでは、まず AWS クラスターレベルでサーバーラックに排出量を配分し、次にリソース消費量に基づいて特定の AWS サービスにそれらの排出量をマッピングします。このモデルは、専用ハードウェアを持つ基盤サービス（例：Amazon EC2）とその基盤の上に構築された非基盤サービス（例：AWS Lambda）間の依存関係を考慮します。最後に、これらのサービスを利用する各お客様アカウントに排出量が割り当てられます。 モデルは以下のように機能します。 クラスターレベルの推定排出量をクラスター内のサーバーラックに配分します。 サーバーラックのリソース使用率に基づき、相互依存関係を考慮しながら、サーバーラックに関連する推定炭素排出量を AWS クラウドサービスに配分します。 各クラウドサービスに関連する推定炭素排出量を個々のお客様アカウントに配分します。 CCFT の方法論が更新されたことにより、一部のお客様は推定排出量が変更される場合があります。これは、バージョン 2.0 がカーボン排出量をより正確にお客様ごとに割り当てられるようになり、実際の AWS サービス利用状況をより的確に反映できるようになったためです。 方法論 v2.0 における 3 つの主要な更新内容： 現在、未使用のキャパシティをすべての AWS カスタマーに配分しています。AWS は、すべてのお客様のニーズに効果的に対応できるよう、十分なサーバーラックを提供しています。これにより、時として未使用のキャパシティが発生します。この未使用のキャパシティに関連する推定炭素排出量は、現在 AWS サービスを利用するすべてのお客様に比例配分されています。これは、GHG プロトコル、プロダクトレベルの炭素報告に関連する ISO 規格 (ISO 14040/14044)、およびクラウドとデータセンターサービス業界のセクターガイダンスにおいて、お客様に製品 / サービスを提供するために必要なすべての余剰リソースと非効率性を含めることが要求されているためです。 AWS Lambda や Amazon Redshift など、専用ハードウェアを持たない AWS サービスからの推定排出量を AWS のお客様と Amazon チーム間で配分するロジックを改善しています。 ネットワークラックや AWS カスタマー向けの新規リージョン立ち上げに関連する推定炭素排出量など、データセンター運営に関連するオーバーヘッドの配分を更新しています。 お客様のニーズを起点に、私たちは引き続きツールの改善を進めてまいります。お客様は、 方法論に関する文書 、 CCFT ユーザーガイド 、および データエクスポートユーザーガイド をご覧いただくことで、これらの更新について詳しく知ることができます。 今後も、進化するデータや気候科学などに基づいて方法論の更新情報を発信し続けるとともに、お客様の持続可能性への取り組みを支援する機能の開発に継続的に投資していきます。 The Climate Pledge への誓約 The Climate Pledge (2040 年までにカーボンニュートラルを達成するという Amazon のコミットメント) や、AWS を含む事業全体における持続可能性への投資についての詳細は、 ここ の当社のサステナビリティサイトをご覧ください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 Margaret O’Toole Margaret O’Toole は、AWS のワールドワイド・テックリーダー (サステナビリティ担当) です。彼女の役割は、お客様が自社の持続可能性目標を達成するために AWS を活用できるよう支援することです。2017年 から AWS に在籍しており、それ以前はバージニア大学でコンピュータサイエンスと生物学を学びました。 Alexis Bateman Alexis Bateman は、Amazon Web Services (AWS) のサステナビリティ・テック部門の責任者です。この役職で、AWS とそのお客様、そしてパートナーがより持続可能な未来に向けて前進できるようにするためのデータ製品、ツール、意思決定支援機能の開発を担当するチームを率いています。Bateman は 2021年 にアマゾンに入社し、サステナビリティ研究とテクノロジー開発において 10 年以上の経験を持っています。AWS 入社以前は、MIT の輸送・物流センターで 10 年間、研究員およびサステナブルサプライチェーンラボのディレクターを務めました。Bateman は、カリフォルニア大学アーバイン校で環境計画・政策・デザインの博士号を取得し、また環境計画の修士号も保持しています。 Marta Fraga Marta Fraga は、AWS サステナビリティにおけるカスタマーカーボンフットプリントツール（CCFT）のプロダクトリーダーです。この役割において、彼女は AWS のお客様がサステナビリティ目標を達成するために必要なサステナビリティ製品とツールのビジョンを設定しています。Marta は 2011 年からアマゾンに在籍しており、ウェールズ大学で経営学の学士号を取得しています。 Paula Csatlos Paula Csatlos は、AWS サステナビリティ部門のシニアプロダクトマネージャー (テクニカル) として、お客様の気候目標達成を可能にする技術製品の開発を主導しています。B2B および B2C 製品の構築とスケーリングにおいて 10 年の経験を持ち、機械学習、生成 AI、カスタマーエクスペリエンスデザイン、プロセス自動化に関する深い専門知識を有しています。

AWS での新しい リージョンとアベイラビリティーゾーン の立ち上げの迅速さには、いつも感動しています。現在、36 のリージョンと 114 のアベイラビリティーゾーンがリリースされています。これは素晴らしいことです! 5 月 5 日週の AWS でのニュースは、グローバルインフラストラクチャの大幅な拡張です。南米向けの新しいリージョンの発表により、お客様にとって、低レイテンシーとデータレジデンシーの要件を満たすための選択肢が増えます。拡張と並行して、AWS はより多くのリージョンで多数のインスタンスタイプを利用できるようになったことを発表しました。 インフラストラクチャの拡張に加えて、AWS は Amazon Q Developer の対象範囲を Amazon OpenSearch Service にも拡大しています。 5 月 5 日週のリリース Amazon OpenSearch Service での Amazon Q Developer の使用 – Amazon Q Developer が Amazon OpenSearch Service と統合されました。これにより、開発者は関連するコードの提案やトラブルシューティングガイダンスを使用して検索アプリケーションを迅速に構築するのに役立つ、AI を活用した支援を受けることができます。 構築中 – AWS 南米 (チリ) リージョン – AWS は、南米 (チリ) リージョンの新設計画を発表しました。この計画では、グローバルインフラストラクチャを拡張して、地域のお客様に低レイテンシーおよび強化されたデータレジデンシーの選択肢を提供できるようになります。 AWS Zero Trust Accelerator for Government のご紹介 – 新しい AWS Zero Trust Accelerator for Government は、公共部門の組織がコンプライアンス要件に特化したツールとガイダンスを使用して、ゼロトラストセキュリティアーキテクチャをより効率的に実装するのに役立ちます。 Amazon EBS スナップショットから新しい EBS ボリュームへのデータ転送の高速化 – AWS は、Amazon EBS Provisioned Rate for Volume Initialization の一般提供を発表しました。これは、ユーザーが EBS スナップショットから新しい EBS ボリュームへのデータ転送を 100 MiB/秒〜300 MiB/秒の範囲の指定されたレートで高速化できる新機能です。 インスタンスに関する発表 AWS は、さまざまなインスタンスタイプのインスタンス可用性を、さらに多くのリージョンに拡大しました。 Amazon EC2 C8gd、M8gd、R8gd インスタンスが AWS リージョン欧州 (フランクフルト) で利用可能に – Amazon EC2 C8gd、M8gd、R8gd インスタンスが AWS 欧州 (フランクフルト) リージョンで利用できるようになりました。これにより、ローカル NVMe ベースの SSD ストレージを使用した Graviton 搭載のコンピューティングインスタンスが、より多くのお客様に提供されるようになりました。 Amazon EC2 R7g インスタンスがさらに多くの AWS リージョンで利用可能に – AWS Graviton3 プロセッサを搭載した Amazon EC2 R7g メモリ最適化インスタンスが、さらに多くの AWS リージョンで利用できるようになり、メモリを大量に消費するワークロードのデプロイオプションが広がりました。 Amazon EC2 R7g インスタンスが AWS GovCloud (米国東部) で利用可能に – Amazon EC2 R7g インスタンスは AWS GovCloud (米国東部) で利用できるようになりました。これにより、政府や規制対象のワークロードに、高性能のメモリ最適化コンピューティングの選択肢がもたらされます。 Amazon EC2 X2idn インスタンスが AWS イスラエル (テルアビブ) リージョンで利用可能に – Intel Xeon Scalable プロセッサを搭載した Amazon EC2 X2idn メモリ最適化インスタンスが、AWS イスラエル (テルアビブ) リージョンで利用できるようになりました。これにより、インメモリデータベースとハイパフォーマンスコンピューティングのワークロードがサポートされます。 Amazon EC2 P5en インスタンスが AWS 米国西部 (北カリフォルニア) リージョンで利用可能に – 高性能機械学習トレーニングと生成 AI 推論用に設計された Amazon EC2 P5en インスタンスが、AWS 米国西部 (北カリフォルニア) リージョンで利用できるようになりました。 その他のアップデート AWS Systems Manager にオンボーディング設定のカスタマイズオプションを追加 – AWS Systems Manager では、オンボーディング設定のカスタマイズオプションが拡張され、管理者がより柔軟にリソースを設定および管理できるようになりました。 Amazon MSK により MSK プロビジョニングクラスターでのシームレスな証明書更新が可能に – Amazon MSK では、MSK プロビジョニングクラスターでのシームレスな証明書更新が可能になり、Apache Kafka 環境のセキュリティ管理が簡素化されます。 AWS Resource Explorer が 41 種類の新しいリソースタイプをサポート – AWS Resource Explorer は 41 種類の新しいリソースタイプをサポートするように拡張され、アカウント全体でより多くの AWS リソースを簡単に見つけて視覚化できるようになりました。 Amazon Managed Service for Prometheus が AWS カナダ (中部) リージョンで利用可能に – Amazon Managed Service for Prometheus が AWS カナダ (中部) リージョンで利用できるようになり、北米のより多くのお客様にコンテナモニタリング機能を提供できるようになりました。 AWS End User Messaging がメキシコ (中部) で利用可能に – AWS End User Messaging がメキシコ (中部) で利用できるようになりました。これにより、企業は地理的地域の顧客に SMS、音声、E メールメッセージを送信できます。 Amazon WorkSpaces が AWS 欧州 (パリ) リージョンで利用可能に – AWS のマネージドデスクトップ仮想化サービスである Amazon WorkSpaces が AWS 欧州 (パリ) リージョンで利用できるようになり、欧州のお客様における仮想デスクトップインフラストラクチャの選択肢が広がりました。 今後のイベント AWS Summit シーズン の真っ只中です! AWS Summit は夏の間、世界中の都市で開催されます。カレンダーをチェックして、お近くで AWS Summit が開催される日をご確認ください。2025 年 5 月の残りの Summit は次のとおりです。 韓国、ソウル – 5 月 14 日〜15 日 アラブ首長国連邦、ドバイ – 2025 年 5 月 21 日 イスラエル、テルアビブ – 2025 年 5 月 28 日 シンガポール – 2025 年 5 月 29 日 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)

このブログは、テクニカルアカウントマネージャーの Zakiya Randall が執筆し、シニアスペシャリストソリューションアーキテクトの Muru Bhaskaran と共同で書かれました。 はじめに コンピューティング環境が進化するにつれ、さまざまなコンピューティングアーキテクチャをサポートすることが求められるようになっています。 こうした動きは、多様なハードウェアプラットフォームにおける柔軟性、効率性、パフォーマンス最適化のニーズから生まれています。 その結果、開発者や組織にとって、複数のアーキテクチャ (マルチアーキテクチャ) に対応したコンテナイメージを構築することが、ますます重要になっています。 AWS CodeBuild は、フルマネージド型の継続的インテグレーションサービスで、現在マネージド GitHub Actions ランナーを サポートしています 。これは、GitHub Actions ワークフローのジョブイベントを受信するように CodeBuild プロジェクトを設定できる、GitHub Actions の セルフホステッドランナー です。この記事では、 GitHub 、GitHub Actions ワークフロー、および CodeBuild を使用して、AWS 上で x86 用と AWS Graviton ベースのコンピューティング環境用の両方のネイティブコンテナイメージをビルドするソリューションをご紹介します。GitHub Actions ワークフローが完了すると、マルチアーキテクチャイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。 ソリューションの概要 構成図は、GitHub リポジトリへ変更をコミットした際のワークフローを示しており、その後コンテナイメージを Amazon ECR にプッシュするまでの手順を詳しく説明しています。 図 1: ソリューションの構成図 GitHub リポジトリへ変更をコミットすると、ワークフローがトリガーされます 両方のアーキテクチャ用の CodeBuild ランナーが起動され、コンテナイメージのビルドを開始します コードが GitHub リポジトリからチェックアウトされます AWS アカウントへのアクセスに必要な認証情報が設定されます Amazon ECR にログインするためにロールが使用されます 両方のアーキテクチャのイメージリストを使って、マルチアーキテクチャイメージがビルドされます 前提条件 このソリューションを実施するには、以下の前提条件が必要です: AWS アカウント Amazon Command Line Interface (AWS CLI) GitHub リポジトリ 手順解説 以降の手順で、このソリューションの概要を説明します。 GitHub リポジトリファイルの作成 ソリューションを開始するには、Dockerfile、index.html ファイル、GitHub Actions ワークフロー YAML ファイルを格納する GitHub リポジトリが必要です。手順については、GitHub の 新しいリポジトリの作成 を参照してください。この例では、次の 2 つのファイルを GitHub リポジトリのルートにコミットします。 index.html ファイル <!DOCTYPE html> <html> <body> <h1>Containers</h1> <p>You can run containers!</p> </body> </html> コンテナイメージをビルドするための Dockerfile FROM public.ecr.aws/nginx/nginx COPY index.html /usr/share/nginx/html/index.html EXPOSE 8080 CMD ["nginx", "-g", "daemon off;"] x86 および arm64 アーキテクチャ用の 2 つの CodeBuild プロジェクトの作成 GitHub Actions ジョブを実行するには、2 つの CodeBuild プロジェクトを作成する必要があります。CodeBuild プロジェクトは、 <project-name> -x86 と <project-name> -arm64 という命名規則に従ってください。 x86 と arm64 の環境用に 2 つの CodeBuild プロジェクトを設定する方法については、 このチュートリアル を参照してください。 GitHub リポジトリに接続するには、OAuth アプリ認証方式を使用する必要があります。 x86 と arm64 の CodeBuild プロジェクトでは、それぞれのアーキテクチャに対応した環境イメージを選択してください。また、 Buildspec のビルド仕様は無視されます。 代わりに、コンピューティングランナーをセットアップするコマンドに CodeBuild が上書きします。 図 2: x86 と arm64 用の CodeBuild プロジェクト Amazon ECR リポジトリの作成 x86 と arm64 のコンテナイメージを格納するために、Amazon ECR リポジトリを作成する必要もあります。次の AWS CLI コマンドを実行して、Amazon ECR リポジトリを作成してください。 aws ecr create-repository \     --repository-name <repository-name> Amazon ECR リポジトリを作成した後、CodeBuild の実行環境が Amazon ECR リポジトリにアクセスしてイメージをプッシュできるように、IAM ロールを作成する必要があります。 次のロールにより、Amazon ECR リポジトリに対してコンテナイメージをプッシュできるようになります。 1. IAM コンソール に移動し、以下の権限を持つポリシーを作成します。ポリシー内の AllowPushPull ステートメントの Resource セクションでは、利用する AWS リージョン 、アカウント番号、リポジトリ名を含む Amazon ECR プライベートリポジトリの Amazon リソースネーム (ARN) に置き換えてください。このポリシーに名前を付け、 ポリシーの作成 を選択します。 {     "Version": "2012-10-17",     "Statement": [         {             "Sid": "AllowPushPull",             "Effect": "Allow",             "Action": [                 "ecr:BatchGetImage",                 "ecr:BatchCheckLayerAvailability",                 "ecr:CompleteLayerUpload",                 "ecr:GetDownloadUrlForLayer",                 "ecr:InitiateLayerUpload",                 "ecr:PutImage",                 "ecr:UploadLayerPart"             ],             "Resource": [                 "arn:aws:ecr:<aws-region>:<account-id>:repository/<repository-name>"             ]         },         {             "Sid": "AllowLogin",             "Effect": "Allow",             "Action": [                 "ecr:GetAuthorizationToken"             ],             "Resource": [                 "*"             ]         }     ] } ポリシーを作成した後、 AWS Identity and Access Management (IAM)  コンソールに移動して、Identity Provider を作成し、 OpenID Connect を選択します。プロバイダーの URL は https://token.actions.githubusercontent.com を選択します。対象者は sts.amazonaws.com を選択します。 2. プロバイダーを作成した後、ロールを作成し、 Web Identity を選択します。ドロップダウンボックスには、 https://token.actions.githubusercontent.com の プロバイダー URL が表示されるはずです。このオプションを選び、 対象者  に sts.amazonaws.com を指定します。 GitHub organization  では、あなたの GitHub Organization を指定し、上記で作成したリポジトリを追加します。 次へ を選択します。 図 3: ロール作成の例 3. 許可を追加 の項目で、ステップ 1 で作成したポリシーを選択し、Amazon ECR にイメージをプッシュできるようにします。 次へ を選択します。次の画面でロールに名前を付けて、 ロールを作成 を選択します。 図 4: ポリシーの許可を追加する例 4. GitHub リポジトリの Settings に移動し、左側ペインの Security の下にある Secrets and variables を選択します。Secrets and variables 内の Actions タブを選択します。 New repository secret を選択します。名前に AWS_ROLE_ARN と入力し、ステップ 3 で作成した AWS ロールの ARN を入力して、 Add secret を選択します。 図 5: AWS ロールの GitHub Actions シークレットを作成する例 5. AWS_REGION 用に別の 新しいリポジトリシークレット を作成します。リソースを作成したリージョンを指定し、 シークレットを追加 を選択します。 図 6: AWS リージョンの GitHub Actions シークレットの例 GitHub Actions ワークフローの準備 GitHub Actions ワークフローは、1 つ以上のジョブで構成された自動化プロセスであり、YAML ファイルでこれらのジョブを定義できます。GitHub リポジトリ内の .github/workflows ディレクトリに YAML ファイルを作成し、そこでソリューションのワークフローを定義します。今回、GitHub Actions ワークフローの YAML ファイルには、CodeBuild ランナー用のビルドジョブを指定します。ランナー環境は YAML ファイルの runs-on セクションで指定され、マルチアーキテクチャソリューション用に作成する各 CodeBuild プロジェクトを参照します。 container-image.yaml name: Docker on:   workflow_dispatch: {}   push:     branches: [ "main" ]     # Publish semver tags as releases.     tags: [ 'v*.*.*' ] env:   REGISTRY: xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com   IMAGE_NAME: myapp jobs:   build:     strategy:       matrix:         arch: [arm64, x86]     runs-on: codebuild-myapp-${{ matrix.arch }}-${{ github.run_id }}-${{ github.run_attempt }}     permissions:       contents: read       id-token: write     steps:       - name: Checkout repository         uses: actions/checkout@v4              - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2         with:           role-to-assume: ${{ secrets.AWS_ROLE_ARN }}           aws-region: ${{ secrets.AWS_REGION }}                  - name: Login to Amazon ECR Private         if: github.event_name != 'pull_request'         id: login-to-ecr         uses: aws-actions/amazon-ecr-login@062b18b96a7aff071d4dc91bc00c4c1a7945b076 # v2.0.1         with:           registry-type: private       # Extract metadata (tags, labels) for Docker       # https://github.com/docker/metadata-action       - name: Extract Docker metadata         id: meta         uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.0         with:           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}       # Build (and optionally) push Docker image (don't push on PR)       # https://github.com/docker/build-push-action       - name: Build and push Docker image         id: build-and-push         uses: docker/build-push-action@2cdde995de11925a030ce8070c3d77a52ffcf1c0 # v5.3.0         with:           context: .           push: ${{ github.event_name != 'pull_request' }}           tags: ${{ steps.meta.outputs.tags }}-${{ matrix.arch }}           labels: ${{ steps.meta.outputs.labels }}      manifest:     needs: build     runs-on: codebuild-myapp-x86-${{ github.run_id }}-${{ github.run_attempt }}     permissions:       contents: read       id-token: write     steps:       - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2         with:           role-to-assume: ${{ secrets.AWS_ROLE_ARN }}           aws-region: ${{ secrets.AWS_REGION }}                  - name: Login to Amazon ECR Private         if: github.event_name != 'pull_request'         id: login-ecr         uses: aws-actions/amazon-ecr-login@062b18b96a7aff071d4dc91bc00c4c1a7945b076 # v2.0.1         with:           registry-type: private       # Extract metadata (tags, labels) for Docker       # https://github.com/docker/metadata-action       - name: Extract Docker metadata         id: meta         uses: docker/metadata-action@8e5442c4ef9f78752691e2d8f8d19755c6f78e81 # v5.5.0         with:           images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}       # Build and push image manifest (don't push on PR)       # https://github.com/Noelware/docker-manifest-action       - name: Build and push Docker manifest         id: build-and-push         uses: Noelware/docker-manifest-action@master # v0.3.0         with:           images: ${{ steps.meta.outputs.tags }}-arm64,${{ steps.meta.outputs.tags }}-x86           inputs: ${{ steps.meta.outputs.tags }}           push: ${{ github.event_name != 'pull_request' }} GitHub Actions ワークフロー構成ファイル内の env variables セクションでは、GitHub Actions ジョブがコンテナマニフェストとコンテナイメージをプッシュする先の Amazon ECR リポジトリを定義する必要があります。作成したリポジトリの名前を IMAGE_NAME という環境変数に設定します。 env:   REGISTRY: xxxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com   IMAGE_NAME: <repository-name> GitHub Actions ワークフローの YAML ファイルでは、ホストランナーがジョブを実行するために使用するアーキテクチャを決定するために、runs-on 値の両方の CodeBuild プロジェクトを定義する必要があります。ここでは、 matrix フィールドで arm64 と x86 の変数を定義しています。マトリックス内の arch  フィールドで定義された変数の組み合わせごとにジョブが実行されます。CodeBuild ランナーにジョブを選択してもらうには、ジョブ名に CodeBuild プロジェクト名を接頭辞として指定する必要があります。 構成ファイルの runs-on 値は次のように設定します。 runs-on: codebuild-<project-name>-${{ matrix.arch }}-${{ github.run_id }}-${{ github.run_attempt }} jobs:   build:     strategy:       matrix:         arch: [arm64, x86]     runs-on: codebuild-myapp-${{ matrix.arch }}-${{ github.run_id }}-${{ github.run_attempt }} GitHub Actions ワークフローの構成ファイルには、 AWS_ROLE_ARN と AWS_REGION の GitHub シークレット変数が定義されています。 AWS にアクセスするための資格情報として、GitHub はこれらのシークレット変数の値を使用します。 - name: Configure AWS credentials         uses: aws-actions/configure-aws-credentials@e3dd6a429d7300a6a4c196c26e071d42e0343502 # v4.0.2         with:           role-to-assume: ${{ secrets.AWS_ROLE_ARN }}           aws-region: ${{ secrets.AWS_REGION }} すべてのファイルを GitHub リポジトリにアップロードした後、リポジトリは次の画像のようになります。 Dockerfile と index.html ファイルはリポジトリのルートに配置され、container-image.yaml ファイルは GitHub Actions ワークフローを定義するために .github/workflows ディレクトリに配置されています。 図 7: GitHub リポジトリ内のファイル構造の例 .github/workflows フォルダ内に container-image.yaml ファイルが格納されています。 図 8: GitHub Actions ワークフロー YAML ファイルの例 ソリューションのテスト GitHub と AWS 内のすべてのリソースが作成されたので、ソリューションをテストしてみましょう。 GitHub リポジトリ内の index.html ファイルのメッセージを変更し、変更をメインブランチにコミットしてください。これにより、GitHub Actions ワークフローが起動します。 GitHub Actions ワークフローが起動すると、CodeBuild ランナーが構成ファイルで指定したジョブを実行し始めるはずです。 1. index.html ファイル内の、body のメッセージを変更してください。変更をコミットし、main ブランチにプッシュします。 2. リポジトリの上部パネルの Actions を選択してください。 Actions  を選択すると、次の図に示すように、両方のアーキテクチャのビルドプロセスで実行されているジョブの詳細ページが表示されます。 図 9: 両方のアーキテクチャでビルドジョブが開始されています 3. 各ビルドジョブ内で、両方のアーキテクチャに対してビルドプロセスが完了するまでのステップを見ることができます。ランナーがこのジョブを受け取るのを待っている旨が表示されています。 図 10: x86 環境のランナー 図 11: arm64 環境のランナー 4. AWS コンソールの CodeBuild に移動すると、各アーキテクチャ用の 2 つのビルドプロジェクトが進行中になっているはずです。 ビルドが完了するまでに数分かかる場合があります。 図 12: 両方のアーキテクチャ用の CodeBuild プロジェクト 5. GitHub repository の Actions ページに戻ると、x86 と arm64 の両方のアーキテクチャに対してビルドジョブが完了したことがわかります。 マニフェストジョブは、x86 と arm64 のコンテナイメージを含むマニフェストリストを作成しています。 図 13: GitHib Actions ページ内のビルド完了画面 6. Amazon ECR リポジトリにアクセスすると、マニフェストおよび x86 と arm64 向けのコンテナイメージが更新されていることがわかります。 図 14: ECR での完了したイメージビルド クリーンアップ この記事で説明したインフラストラクチャをすべて破棄することで、追加の費用は発生いたしません。GitHub のリソースをクリーンアップするには、この例で作成したリポジトリを削除してください。AWS のリソースをクリーンアップするには、次のコマンドで 2 つの CodeBuild プロジェクトを削除することができます。 aws codebuild delete-project –-name <project-name>-x86 aws codebuild delete-project –-name <project-name>-arm64 また、次のコマンドを使用して Amazon ECR リポジトリを削除できます。 aws ecr delete-repository \     --repository-name <repository-name> \          --force 結論 この投稿では、GitHub Actions と AWS CodeBuild を統合して、マルチアーキテクチャイメージをビルドする方法を紹介しました。また、これらのマルチアーキテクチャイメージを Amazon ECR に格納し、x86 または Amazon Elastic Compute Cloud (Amazon EC2) の AWS Graviton コンピューティングから取得できるようにする手順を説明しました。CodeBuild には専用の ウェブサイト があり、ランナーをデプロイする際に役立つ情報、チュートリアル、リソースが用意されています。Graviton コンピューティングの詳細を知りたい場合は、こちらの ウェブサイト を参照してください。 本記事は、 Building multi-arch containers with GitHub Actions in AWS (2025 年 3 月 14 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。