はじめに 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 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの吉田が担当しました。

Amazon Redshift Serverless は、ワークロードの需要に合わせて自動的に計算能力をスケーリングし、この能力を Redshift Processing Units (RPU) で測定します。従来のスケーリングはクエリキューの待ち時間に応じて行われていましたが、新しい AI 主導のスケーリングと最適化機能 は、クエリの複雑さやデータ量など複数の要因を考慮することで、より洗練されたアプローチを提供します。インテリジェントなスケーリングにより、パフォーマンスとコストのバランスを取ることができ、主要なデータウェアハウスの課題を解決できます。特に、日次パターンや月次サイクルに基づいてワークロードが変動する場合に有効です。 Amazon Redshift サーバーレスでは、ワークグループの構成をより柔軟に設定できるようになりました。ユーザーは、クエリ実行のベース RPU を指定してベース容量を設定するか、価格対パフォーマンスのターゲットを選択できます。RPU の範囲は 8 から 1024 で、各 RPU は 16GB のメモリを提供します。Amazon Redshift Serverless の AI 主導のスケーリングと最適化により、さまざまなワークロードの要件により適切に対応でき、インテリジェントにリソース管理を行い、クエリ実行中にリソースを自動的に調整し、最適なパフォーマンスを実現します。現在のワークロードが 32 から 512 ベース RPU を必要とする場合は、AI 主導のスケーリングと最適化を使用することをお勧めします。32 ベース RPU 未満または 512 ベース RPU を超えるワークロードでは、この機能の使用をお勧めしません。 この記事では、Amazon Redshift Serverless の AI 主導のスケーリングと最適化が、さまざまな最適化プロファイルにおいてパフォーマンスとコストにどのような影響を与えるかを示します。 AI 主導のスケーリングと最適化の選択肢 Amazon Redshift Serverless の AI による自動最適化では、直感的なスライダーインターフェースを提供し、価格とパフォーマンスのゴールをバランスさせることができます。次の図に示されるように、「コスト最適化」から「パフォーマンス最適化」までの 5 つの最適化プロファイルから選択できます 。スライダーの位置に合わせて、Amazon Redshift がリソース割り当てと AI による自動最適化の調整を行い、価格とパフォーマンスを望ましいバランスに保ちます。 スライダーには以下のオプションがあります: コスト最適化 (1) パフォーマンスよりもコスト削減を優先します コスト削減のため、最小限のリソースを割り当てます パフォーマンスが時間的に重要でないワークロードに最適です コストバランス (25) 適度なパフォーマンスを維持しつつ、コスト削減に重点を置きます 中程度のリソースを割り当てます クエリ時間に柔軟性がある混合ワークロードに適しています バランス (50) コスト効率とパフォーマンスに同等の重点を置きます ほとんどのユースケースに最適なリソースを割り当てます 汎用ワークロードに理想的です パフォーマンスバランス (75) ある程度のコスト管理を維持しつつ、パフォーマンスを優先します 必要に応じて追加のリソースを割り当てます 一貫して高速なクエリ経過時間を必要とするワークロードに適しています パフォーマンス最適化 (100) コストに関係なく、パフォーマンスを最大化します 利用可能な最大のリソースを提供します 最速のクエリ配信を必要とする時間的に重要なワークロードに最適です AI 主導のスケーリングと最適化を検討すべきワークロード Amazon Redshift Serverless の AI によるスケーリングと最適化機能は、ほとんどすべての分析ワークロードに適用できます。Amazon Redshift は、コスト、バランス、パフォーマンスのいずれかの価格と性能の目標に応じて、最適化を評価して適用します。 ほとんどの分析ワークロードは、数百万または数十億行のデータを処理し、集計や複雑な計算を行います。これらのワークロードはクエリパターンとクエリ数の変動が大きくなります。Amazon Redshift Serverless の AI 主導のスケーリングと最適化により、ワークロードのパターンを学習し、パフォーマンス重視の場合はパフォーマンス向上のためにリソースを多く割り当て、コスト重視の場合はリソースを少なく割り当てるため、価格、パフォーマンス、またはその両方が改善されます。 AI ドリブンのスケーリングと最適化のコスト効率性 Amazon Redshift Serverless の AI 主導のスケーリングと最適化の効果を適切に判断するためには、現在のコストパフォーマンスを測定できる必要があります。現在のコストパフォーマンスを測定するために、 sys_query_history を使用してワークロードの合計経過時間を計算し、開始時刻と終了時刻を確認することをお勧めします。次に、 sys_serverless_usage を使用してコストを計算します。 Amazon Redshift ドキュメント のクエリを使用し、同じ開始時刻と終了時刻を追加できます。これにより、現在のコストパフォーマンスが確立され、比較のための基準ができます。 ワークロードが継続的に実行されており、固定された開始時刻と終了時刻を決めるのが現実的でない場合、別の方法として、全体的に比較することもできます。前月比のコストをチェックしたり、パフォーマンス、システムの安定性、データ配信の改善、または前月比の全体的な処理時間の短縮に対するユーザーの評価をチェックすることができます。 ベンチマークの実施と結果 TPC-DS 3TB データセットを AWS Labs GitHub リポジトリ ( amazon-redshift-utils ) から評価し、最適化オプションを検証しました。このデータセットを、コスト最適化、バランス、パフォーマンス最適化に設定された 3 つの Amazon Redshift Serverless ワークグループに分けてデプロイしました。本格的なレポーティング環境を作成するため、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス 3 台に JMeter (エンドポイントごとに 1 台) を設定し、次のスクリーンショットに示すように、選択した 15 の TPC-DS クエリを約 1 時間同時に実行しました。 結果キャッシュを無効化 して、Amazon Redshift Serverless がすべてのクエリを直接実行し、正確な測定値を提供するようにしました。この設定により、各最適化プロファイルにおける本物のパフォーマンス特性を把握できました。また、Amazon Redshift Serverless ワークグループの 最大容量 パラメータを設定しない環境でテストを行いました。このパラメータは、データウェアハウスで利用可能な最大 RPU を制御する重要な設定です。この制限を外すことで、さまざまな設定がテストエンドポイントのスケーリング動作にどのように影響するかを明確に示すことができました。 包括的なテスト計画では、15 個の各クエリを 355 回実行し、テストサイクルごと 5,325 クエリを生成しました。AI 主導のスケーリングと最適化を行うには複数の反復が必要であり、パターンを特定し RPU を最適化するため、このワークロードを 10 回実行しました。これらの繰り返しを通して、AI は学習し、動作を適応させ、テスト期間中に合計 53,250 クエリを処理しました。 テストでは、AI 主導のスケーリングと最適化システムが、コスト最適化、バランス、パフォーマンス最適化の 3 つの異なる構成プロファイルに対してパフォーマンスを適応させ、最適化する様子が明らかになりました。 クエリと経過時間 同じコアのワークロードを繰り返し実行しましたが、JMeter で変数パラメータを使用して WHERE 句の条件に異なる値を生成しました。このアプローチにより、類似ではあるが異なるワークロードが作成され、システムが実際のシナリオでさまざまなクエリパターンを処理する方法を示す自然な変動が導入されました。 経過時間の分析により、パフォーマンス目標を達成するためにどのような設定にしたのかが示されています。 次のスクリーンショットで、各エンドポイントの平均消費メトリックスが示されています。 結果は期待通りで、パフォーマンス最適化の構成は大幅な高速化を実現し、バランス構成の約 2 倍、コスト最適化の構成の約 4 倍のクエリ実行速度でした。 次のスクリーンショットは、各テストの経過時間の内訳を示しています。 次のスクリーンショットは、10 回目の最終テスト反復で、構成間の明確なパフォーマンスの違いを示しています。 より詳しく説明すると、クエリの経過時間を 3 つのグループに分類しました。 短いクエリー: 10 秒未満 中程度のクエリー: 10 秒以上 10 分未満 長いクエリー: 10 分以上 最後のテストを考慮すると、分析は以下に示す通りです： 構成ごとの期間 コスト最適化 バランス パフォーマンス最適化 短いクエリ (<10 秒) 1488 1743 3290 中程度のクエリ (10 秒 – 10 分) 3633 3579 2035 長いクエリ (>10 分) 204 3 0 合計 5325 5325 5325 構成の容量は、クエリの経過時間に直接影響します。コスト最適化構成では、リソースを制限してコストを節約しますが、その結果クエリ時間が長くなるため、時間的な制約がなく、コスト削減が優先される作業に最適です。バランス構成では、中程度のリソースを割り当てることで、中程度の時間のクエリを効果的に処理し、短いクエリに対しては合理的なパフォーマンスを維持しつつ、長時間実行されるクエリをほぼ排除する中間的な性能を示します。一方、パフォーマンス最適化構成では、多くのリソースを割り当てることで、コストは増加しますが、クエリ結果が高速になるため、クエリの速度が重要な待ち時間に敏感な作業に最適です。 テスト中の使用容量 3 つの構成を比較した結果、Amazon Redshift Serverless の AI 主導のスケーリングと最適化テクノロジーが、ユーザーの期待に応じてリソース割り当てを調整することがわかりました。監視では、ベース RPU の変動はあるものの、構成間で異なるスケーリングパターンが確認されました。パフォーマンスを優先してスケールアップするか、コスト最適化のために RPU を抑えるかが、構成によって異なっていました。 コスト最適化構成は 128 RPU から開始し、3 回のテスト後に 256 RPU に増加します。コスト効率を重視するため、このセットアップではクエリが一時的に溜まった場合でも、スケーリング時の最大 RPU 割り当てを制限します。 次の表では、コスト最適化構成のコストを確認できます。 テスト # 起動時の RPU 数 拡張後の RPU 数 発生コスト 1 128 1408 $254.17 2 128 1408 $258.39 3 128 1408 $261.92 4 256 1408 $245.57 5 256 1408 $247.11 6 256 1408 $257.25 7 256 1408 $254.27 8 256 1408 $254.27 9 256 1408 $254.11 10 256 1408 $256.15 Amazon Redshift Serverless による戦略的な Redshift Processing Unit (RPU) の割り当てが、コストの最適化に役立つことが、テスト 3 と 4 で観測された大幅なコスト削減から示されています。これは次の図に示されています。 コスト最適化がベース RPU を変更しましたが、バランス構成ではベース RPU は変更されず、2176 RPU にスケールアップしました。これは、コスト最適化設定によって使用された最大値が 1408 RPU を上回っています。次の表は、バランス構成の数値を示しています。 テスト No. 開始 RPU 数 スケールアップ先 発生コスト 1 192 2176 $261.48 2 192 2112 $270.90 3 192 2112 $265.26 4 192 2112 $260.20 5 192 2112 $262.12 6 192 2112 $253.18 7 192 2112 $272.80 8 192 2112 $272.80 9 192 2112 $263.72 10 192 2112 $243.28 バランス構成は、テストあたり平均 $262.57 かかりましたが、パフォーマンスが大幅に向上し、コスト最適化構成 (テストあたり平均 $254.32) に比べてわずか 3% 高いコストでした。前のセクションで示したように、このパフォーマンス上の利点は経過時間の比較からも明らかです。次のグラフは、バランス構成のコストを示しています。 パフォーマンス最適化の構成から予想されるように、リソースの使用量が高くなり、高パフォーマンスを実現しました。この構成では、2 回のテスト後にエンジンが適応し、より多くの RPU から開始してクエリをより速く処理するようになったことも確認できます。 試行番号 開始時の RPU スケールアップ後の RPU 数 発生コスト 1 512 2753 $295.07 2 512 2327 $280.29 3 768 2560 $333.52 4 768 2991 $295.36 5 768 2479 $308.72 6 768 2816 $324.08 7 768 2413 $300.45 8 768 2413 $300.45 9 768 2107 $321.07 10 768 2304 $284.93 3 回目のテストで 19% のコストアップがあったものの、その後の大半のテストでは平均コストを下回りました。 パフォーマンス最適化構成は、クエリ時間を短縮することを優先し、コスト効率よりも速度を重視してリソース使用量を最大化します。 費用対効果の最終分析では、説得力のある結果が明らかになりました: バランス構成は、コスト最適化構成に比べてわずか 3.25% のコスト増でパフォーマンスが 2 倍向上しました パフォーマンス最適化構成は、コスト最適化オプションと比較して 19.39% のコスト増で経過時間が 4 分の 1 の時間で実行できました。 次の図は、コストパフォーマンスの調査結果を示しています。 これらの結果は特定のテストシナリオを反映していることに注意が必要です。各ワークロードには固有の特性があり、構成間のパフォーマンスとコストの違いは、他のユースケースでは大きく異なる可能性があります。 当社の調査結果は一般的な基準というよりは参考値として提示するものです。また、Amazon Redshift Serverless で利用可能な中間の 2 構成(コスト最適化とバランスの間、バランスとパフォーマンス最適化の間)はテストしていません。 結論 テスト結果は、さまざまなワークロード要件に対する Amazon Redshift Serverless の AI 駆動型スケーリングと最適化の有効性を示しています。この結果は、Amazon Redshift Serverless の AI 駆動型スケーリングと最適化が、組織がコストとパフォーマンスの理想的なバランスを見つけるのに役立つことを示唆しています。ただし、テスト結果は参考程度にすぎません。各組織は特定のワークロード要件とコストパフォーマンス目標を評価する必要があります。5 つの異なる最適化プロファイルの柔軟性と、インテリジェントなリソース割り当てを組み合わせることで、チームはデータウェアハウス運用を最適な効率で細かく調整できます。 Amazon Redshift Serverless の AI によって自動的に行われるスケーリングと最適化を開始するには、次のことをお勧めします。 現在の価格とパフォーマンスのベースラインを確立する ワークロードのパターンと要件を特定する 特定のワークロードでさまざまな最適化方法をテストする 結果に基づいて監視と調整を行う これらの機能を活用することで、組織は特定のパフォーマンスとコスト目標を達成しながら、リソースをより効率的に活用できます。 AWS マネジメントコンソールにアクセスして、今すぐ Amazon Redshift Serverless の AI 主導のスケーリングと最適化機能を作成し、さまざまな最適化プロファイルを探索してみてください。詳細については、Amazon Redshift Serverless の AI 主導のスケーリングと最適化に関するドキュメントをご覧いただくか、AWS アカウントチームにお問い合わせいただき、ご利用のユースケースについてご相談ください。 著者について Ricardo Serafim は、AWS のシニアアナリティクス専門ソリューションアーキテクトです。2007 年からデータウェアハウスソリューションの支援を行っています。 Milind Oke は、ニューヨークを拠点とするデータウェアハウス専門のソリューションアーキテクトです。15 年以上にわたってデータウェアハウスソリューションを構築しており、Amazon Redshift に特化しています。 Andre Hass は、AWS の Senior Technical Account Manager で、AWS のデータ分析ワークロードに特化しています。20 年以上のデータベースとデータ分析の経験を持ち、お客様のデータソリューションの最適化と複雑な技術的課題の解決を支援しています。データの世界に没頭していないときは、アウトドアアドベンチャーに情熱を注いでいます。週末や機会があれば、家族とキャンプ、ハイキング、新しい目的地を探索することを楽しんでいます。 翻訳は、ソリューションアーキテクトの平井が担当しました。原文は こちら です。

この記事は Under the hood: Amazon EKS Auto Mode (記事公開日: 2025 年 3 月 31 日) を翻訳したものです。 この記事は、EKS シニアプロダクトマネージャーの Alex Kestner、EKS シニアソフトウェアエンジニアの Todd Neal、EKS シニアソフトウェア開発マネージャーの Neelendra Bhandari、プリンシパルスペシャリストソリューションアーキテクトの Sai Vennam が共同執筆しました。 re:Invent 2024 で、Amazon Elastic Kubernetes Service (Amazon EKS) Auto Mode を発表しました。EKS Auto Mode は、すぐにワークロードをホストできる、Kubernetes 準拠の本番環境対応のクラスターを提供する新機能です。この記事では、EKS Auto Mode が Kubernetes ワークロードにとってどのような意味を持つのか、そして EKS Auto Mode クラスターの内部構造について詳しく説明します。 EKS Auto Mode の概要 EKS Auto Mode を利用するとアプリケーションをより効率的に運用できるようになります。Kubernetes コントロールプレーンとワーカーノードのセットアップ、スケーリング、メンテナンスを自動的に管理するため、基盤となるインフラストラクチャを気にする必要がありません。アプリケーションのデプロイに集中すれば、EKS Auto Mode が残りの部分を処理します。これは、複雑さを管理することなく Kubernetes を使用したいユーザーに最適です。 2017 年の re:Invent で、Kubernetes の運用を効率化する Amazon EKS をローンチしました。ローンチ時の Amazon EKS は、 AWS Identity and Access Management (IAM) などの既存のサービスと統合された、マネージド Kubernetes コントロールプレーンを提供しました。私たちはそのコントロールプレーンの健全性とパッチ適用に責任を持ち、現在ユーザーは毎年数千万の EKS クラスターを実行しています。しかし、ワークロードが実行される Kubernetes クラスターのデータプレーンである Amazon Elastic Compute Cloud (Amazon EC2) ノードの運用はユーザーが責任を負っていました。 マネージドノードグループ や Karpenter などの機能を年々導入し、データプレーンの運用負荷を軽減してきましたが、ユーザーは依然として、適切な OS の選択、基盤となるノードのスケーリング、CNI や kube-proxy などのコアアドオンやコンポーネントの管理に責任を負っていました。 図 1: Amazon EKS (Auto Mode を含まない) の責任共有モデル EKS Auto Mode は、2017 年に導入した運用モデルの進化版で、Kubernetes クラスターのデータプレーン部分の責任を AWS がより多く引き受け、マネージド型のコンピューティング、ネットワーキング、ストレージ機能を提供します。EKS Auto Mode を使用すると、ユーザーはクラスターを作成し、すぐに本番環境対応のワークロードをデプロイできます。EC2 インスタンスの設定、パッチ適用、健全性の管理は AWS が担当するため、ユーザーは VPC とクラスターの設定、および実行するアプリケーションコンテナにのみ注力できます。 図 2: Amazon EKS (Auto Mode を含む) の責任共有モデル EKS Auto Mode におけるデータプレーン EKS Auto Mode クラスターのデータプレーンを構成する重要なコンポーネントがいくつかあります。 EC2 マネージドインスタンス は、AWS に運用管理が委任された標準的な EC2 インスタンスです。 Bottlerocket は、AWS がコンテナの実行を目的に構築したオープンソースのオペレーティングシステムです。 コア機能とアドオン は EKS Auto Mode が管理するノードに組み込まれており、ユーザーがこれらのコンポーネントを管理・維持する必要がありません。 ワーカーノード管理 (Karpenter) は、ワーカーノードの健全性を自動的に処理し、コスト効率を最適化するための理想的なインスタンスタイプでノードを削除および置き換えることができます。 EC2 マネージドインスタンス 最も基本的なレベルでは、EKS Auto Mode は re:Invent 2024 で発表された新機能である EC2 マネージドインスタンス を使用します。マネージドインスタンスは標準的な EC2 インスタンスですが、Amazon EKS のような AWS サービスに運用管理を委任している点が異なります。基本的に、EKS Auto Mode は運用のオーバーヘッドと一部の制御を手放すことで、セキュリティの向上を得ることができます。例えば、マネージドストレージ機能がワークロードに必要な EBS ボリュームのアタッチとデタッチを担当するため、EKS Auto Mode が管理するノードから Amazon Elastic Block Store (Amazon EBS) ボリュームを手動でデタッチする必要がなくなります。同様に、ノードに直接 SSH 接続することはできませんが、Amazon EKS サービスを通じてインスタンスの情報取得や トラブルシューティング を行う機能は常に維持されています。EKS クラスターの削除時にクラスターに関連付けられた EC2 マネージドインスタンスが強制的に終了されるため、EKS クラスターのクリーンアップがより直接的になります。 EC2 マネージドインスタンスにより、EKS Auto Mode は Kubernetes ワークロードのコンピューティングキャパシティをシームレスに管理できます。そのため、ノードの管理ではなく、アプリケーションのデプロイと実行に集中できます。ワークロードは、 AWS Lambda や AWS Fargate のように、AWS がお客様に代わってワークロードを実行する場合と同じ基準で維持されます。既存ノードのキャパシティをワークロードが超過した場合、EKS Auto Mode は Karpenter (後述のワーカーノード管理セクションで詳しく説明) を使用して、高可用性とパフォーマンスを確保するために EC2 マネージドインスタンスを動的にプロビジョニングし、手動でのスケーリング調整の必要性を排除します。 EC2 マネージドインスタンスは、インフラストラクチャ管理の合理化だけでなく、コストの最適化にも役立ちます。 リザーブドインスタンスや Savings Plans などの既存の AWS のコスト削減メカニズムを利用でき、予測可能な支出を維持しながら柔軟性を提供します。 EKS Auto Mode を通じて EC2 マネージドインスタンスを使用することで、AWS がインフラストラクチャを管理する完全マネージド型の Kubernetes をユーザーは利用でき、アプリケーションの開発とスケーリングに集中できます。 オペレーティングシステムとしての Bottlerocket の選択肢 EC2 マネージドインスタンスは、他の EC2 インスタンスと同様にオペレーティングシステムが必要です。EKS Auto Mode は、 Bottlerocket を使用します。これは AWS がコンテナ実行を目的として開発したオープンソースのオペレーティングシステムです。Bottlerocket は、Kubernetes ワークロードを効率的かつ安全に実行するように設計されているため、EKS Auto Mode の理想的なベースオペレーティングシステムです。Bottlerocket には、コンテナの実行に必要なソフトウェアのみが含まれています。大規模な汎用オペレーティングシステムが約 50,000 のパッケージ定義を持つのに対し、Bottolerocket のオープンソースプロジェクトは約 100 のパッケージ定義を維持しています。これにより、不要な機能と依存関係がビルド時に無効化されます。さらに、コンテナのユースケースに不要なサービスを排除することで、潜在的な CVE の対象領域を減らすとともに、ワークロードにより多くのリソースを提供します。Bottlerocket は、ルートファイルシステムの暗号化整合性チェックと、SELinux などの強制アクセス制御を実施し、コンテナエスケープが発生した場合の攻撃対象領域を削減します。 EKS Auto Mode で利用する Amazon Machine Image (AMIs) は、Bottlerocket の新しい Out of Tree Build (OOTB) システムを使用するカスタム Bottlerocket バリアントです。OOTB は、カスタム Bottlerocket バリアントを作成するための合理化されたメカニズムです。OOTB はバリアントと Bottlerocketのコア部分との依存関係を疎結合に定義します。これにより、カスタムバリアントは独自の進化を遂げながらも、Bottlerocketのコアアップデートを安全に取り入れることができます。 kernel kit と core kit は Bottlerocket のコアを形成し、EKS Auto Mode で利用する AMI はこれらを Bottlerocket プロジェクトから取り込むことで、セキュリティと慎重に選定された依存関係に焦点を当てた恩恵を受けています。 EKS Auto Mode 固有の新しい ノード機能を提供するだけでなく、Auto Mode AMI は Bottlerocket の基本的な設定にもいくつかの変更を加えています。たとえば、標準の Bottlerocket は SSH やコンソールを介したインタラクティブなログインをサポートしていません。代わりに、アクセスを提供するためのホストコンテナと呼ばれる特別なタイプのコンテナを利用することができます。EKS Auto Mode は Bottlerocket ホストコンテナを完全に無効化し、代わりに ノードログの取得 や、ノードとの 直接的なやり取り のための Kubernetes ネイティブなメカニズムを提供します。これには、ネットワーク接続がない場合の ノードのトラブルシューティング情報 の取得などが含まれます。また、EKS Auto Mode は、ブートストラップコマンドのような新しい Bottlerocket の機能を利用して、ローカルインスタンスストレージ (インスタンスタイプが対応している場合) を設定します。これにより、対応するインスタンスタイプに含まれる高速なエフェメラルローカルストレージが、コンテナイメージ、Pod のエフェメラルデータ、およびログに自動的に使用されます。 コアノードの機能 Kubernetes ノードには通常、ノードレベルの重要な機能を提供するための Pod を作成する DaemonSet が必要です。ユーザーからは、これらのコンポーネントの管理、パッチ適用、互換性の確保が困難で時間がかかるという声が多く寄せられていました。EKS Auto Mode の一環として、最も一般的に使用されるコンポーネントについて、この煩雑な作業を解消しました。まず、EKS クラスターの大多数で使用されているコアとなるノード機能を特定し、それらの機能を EKS Auto Mode ノードに直接組み込むように取り組みました。 ネットワーク:ノードのローカルネットワーク設定、DNS、および Network Policy の適用 ストレージ: Amazon EBS にバックアップされた Persistent Volume と、一時データ用の ローカルインスタンスストレージ の、オペレーティングシステムレベルの設定 アイデンティティ: Pod に IAM アイデンティティを設定できるようにします 専門ハードウェアのサポート AWS Neuron : Inferentia アクセラレータと Trainium アクセラレータを Pod で利用できるようにするドライバとデバイスプラグイン NVIDIA: NVIDIA GPU を Pod で使用できるようにするためのドライバーとデバイスプラグイン Elastic Fabric Adapter (EFA) : EFA デバイスを Pod で使用できるようにするドライバーとデバイスプラグイン ヘルス: ノードヘルスモニタリング 。特定の障害モードのレポート作成と自動修復が可能 上記から、EKS Auto Mode を利用するクラスターでは Network Policy での適切なネットワーク設定、 Pod Identity を使用した AWS サービスへのリクエスト、Persistent Volume を使用した EBS へのデータ保存を行う Pod を作成できます。NodePool がアクセラレーテッドインスタンスタイプをサポートしている場合、ノード上の Pod はリソースリクエストを通じて Neuron アクセラレータや NVIDIA GPU を使用することもできます。さらにユーザーの負担を軽減するため、組み込みのヘルスモニタリングは、Amazon EKS の運用を通じて特定してきた一連の問題や障害モードを定期的にチェックし、Kubernetes のイベントやコンディションを通じて報告します。応答しない kubelet やプロセス ID の枯渇などのエラーケースでは、EKS Auto Mode はノードを自動的に修復し、置き換えることでアプリケーションへの影響を最小限に抑えることができます。 ワーカーノードの管理 Karpenter を活用した EKS Auto Mode のコンピュート機能は、EC2 マネージドインスタンスと Bottlerocket ベースの EKS Auto Mode AMI を組み合わせて、EKS Auto Mode ノードを作成します。このコンピュート機能は、ワークロードの実行に必要なコンピュート容量を提供するために、必要に応じてノードを自動的に起動および終了します。これらのノードは、設定された NodePool とクラスター内のワークロード要件に基づいて、コスト効率を継続的に最適化します。 このプロセスは、ワークロード要件 (CPU、メモリ、または特殊なハードウェアのニーズなど) と Kubernetes のスケジューリング制約を満たす、最もコスト効率の高いインスタンスタイプを特定することから始まります。ワークロードや NodePool の要件を通じてインスタンスタイプの選択を正確に制御するか、より広範なインスタンスタイプを許可することで柔軟性を維持しコストを削減することができます。適切なインスタンスが特定されると、EKS Auto Mode は、それらの特定のインスタンスタイプに対応する Auto Mode AMI を使用して、必要な EC2 マネージドインスタンスを起動します。 時間の経過とともに、需要に合わせてスケールアップ / スケールダウンしたり、ワークロードがクラスターに追加 / 削除されたりすると、ワークロード要件が変化する可能性があります。EKS Auto Modeは、統合プロセスの一環としてクラスター全体を継続的に評価し、ワークロードをより費用対効果の高い方法で実行できるかどうかを判断します。大まかに言うと、次の 2 つの方法でこれを実現しています。 ノードの削除: クラスター内の他のノードの利用可能なキャパシティで、そのノードのすべての Pod が実行できる場合、そのノードは削除の対象となります。 ノードの置き換え: 既存のノードの利用可能なキャパシティと、より低コストの代替ノード 1 つの組み合わせで、そのノードのすべての Pod を再分配できる場合、そのノードは置き換えの対象となります。 迅速なノードプロビジョニングと継続的なコスト最適化のシームレスな統合により、EKS Auto Mode がノード管理タスクを処理する間、ユーザーはクラスター内のワークロードに集中できます。 ノードのライフサイクルとメンテナンス EKS Auto Mode が登場する以前は、ノードレベルのコンポーネントと EKS クラスターコントロールプレーンの互換性の検証、それらのコンポーネントのデプロイ、パッチ適用と更新管理はユーザーの責任でした。 Cluster Insights のような機能により、非互換性を表示することで負担は軽減されましたが、デプロイとパッチ適用はユーザーの責任のままでした。EKS Auto Mode では、すべてのコアノード機能を含むテスト済みの最新 AMI を、すべての EKS Auto Mode ノードで継続的に利用できるようにすることで、AWS がその責任を引き受けます。Auto Mode AMI のビルドとリリースプロセスは、以下を担当する継続的デプロイメントパイプラインによって駆動されます。 CVE スキャン AMI のビルド AMI の検証 Kubernetes コンフォーマンス テスト コンポーネントの機能テスト (例: Pod が EKS Pod Identity を通じて IAM 認証情報を取得できることの検証) セキュリティテスト AMI のデプロイ このパイプラインは、 安全なハンズオフデプロイメントの自動化 の標準的なベストプラクティスに従っています。このプロセスは、新しくテストされた AMI を単一のリージョン内の少数の EKS Auto Mode クラスターにデプロイすることから始まり、潜在的な問題を検出するための時間を設けています。AMI の安定性に対する信頼性が高まるにつれて、より多くのクラスターに段階的にロールアウトされ、より大規模な展開とより多くの AWS リージョンへの展開が行われ、デプロイメント間の時間も短縮されていきます。 EKS Auto Mode では、ユーザーがすべてのコントロールプレーンのアップグレードを制御およびトリガーすることができます。データプレーンの更新については、 Pod Disruption Budget と Node Disruption Budget を使用して更新プロセスを管理できます。これらのツールは、 Pod とノードの両方のレベルで詳細な制御を提供します。 Pod Disruption Budgets は、特定のワークロード更新時に許可される中断の最大数を定義します。 Node Disruption Budgets は、メンテナンスウィンドウを指定し、同時に更新できるノード数を制御することができます。 AWS が新しいセキュリティパッチを適用した EKS Auto Mode AMI をリリースすると、EKS Auto Mode は Kubernetes のスケジューリング制約と設定された Disruption Budgets を考慮しながら、ワーカーノードを自動的にアップグレードできます。 EKS のベストプラクティスドキュメント では、アップデート中のアプリケーションの信頼性を維持するための具体的な推奨事項など、これらの制御を効果的に実装するための詳細なガイダンスを提供しています。 まとめ Amazon EKS Auto Mode は、ユーザーが AWS 上で Kubernetes を実行する方法を大きく進化させたものです。セキュアなコンピュート管理のための Amazon EC2 マネージドインスタンス、コンテナ最適化オペレーティングシステムとしての Bottlerocket、そして重要な機能が組み込まれたノードを組み合わせることで、EKS Auto Mode はユーザーがインフラストラクチャ管理からアプリケーション開発へと注力できるようにします。ノードコンポーネントの設定、セキュリティパッチの管理、運用ツールのメンテナンスに時間を費やす代わりに、チームはビジネスにとって重要なアプリケーションのデプロイとスケーリングに集中できます。 EKS Auto Mode を使用してクラスターインフラストラクチャを自動化する 準備はできましたか？ eksctl、AWS CLI、AWS マネジメントコンソール、EKS API、またはお好みの Infrastructure as Code ツールを使用して、新しい EKS Auto Mode クラスターをデプロイしたり、既存のクラスターで EKS Auto Mode を有効にしたりできます。ワークロードのデプロイと Auto Mode の機能を探索するハンズオンワークショップをお試しください。 お客様自身の AWS アカウント で実行するか、 AWS 主催のイベント に登録して参加できます。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

この記事は 「 Mastering Direct-to-Consumer Marketing with First-Party Data: Delivering Personalized Experiences Using Generative AI 」（記事公開日： 2025 年 3 月 11 日）の翻訳記事です。 消費財 (Consumer Packaged Goods) 企業が長期的な成功を収めるためには、考慮すべき点がたくさんあります。とりわけ、ブランドイメージを維持し、利益率を改善し、顧客との良い関係を築く新しい方法を見つける必要があります。幸いなことに、生成 AI の出現により、消費財企業がこれらすべての課題に対処できるようになりました。ただし、これは万能のアプローチではありません。AI を組織に導入するだけでは、最大のメリットは得られません。ビジネス目標に沿った戦略的アプリケーションを採用する必要があります。 このため、消費財ブランドは、そうした消費者への D2C 戦略を実施するために、高度な分析と生成 AI のサービスとソリューションを豊富に用意しているアマゾンウェブサービス（AWS）に目を向けています。専用の基盤モデル、豊富なツール、AWS の堅牢なインフラストラクチャを活用することで、企業はファーストパーティデータを実用的なインサイトに変えることができます。サードパーティーデータへの依存を減らし、AWS のソリューションとサービスを使用してパーソナライズされた体験を向上させた Tapestry、Adidas、DoorDash、FrontDoor Inc. の事例を参照してみてください。彼らの投資は事業の将来を見据えたものであり、持続可能な成長を促進し続けています。さらに、今日の競争の激しいビジネス環境においても、プライバシーコンプライアンスを遵守しながら、インサイトを収集し、パーソナライズされた体験を実現しています。このブログではそうした方法についても説明しますが、その前に、こうした変革をもたらした背景について説明します。 ファーストパーティデータによる消費者行動の予測 ファーストパーティデータは、消費財企業が高度な分析機能を通じて顧客のニーズを予測する上で重要な役割を果たします。過去の購入パターンを分析することで、企業は将来のキャンペーン戦略のベースとなる有意義な傾向を明らかにすることができます。高度な機械学習 (ML) モデルは、購入意向や潜在的な解約リスクなどの特定の行動を予測することで、この機能を強化します。消費財企業は、これらのインサイトを活用して、さまざまな顧客セグメントの共感を呼び起こす、セグメント別のターゲットごとに最適化されたメッセージングキャンペーンを推進することもできます。 消費財企業によるファーストパーティデータ戦略への適応 消費財企業は、ロイヤルティプログラムと改善された CRM（顧客管理）システムを通じて収集されたファーストパーティデータを活用することで、Cookie が使えなくなる未来に適応しようとしています。そこで AWS では、パーソナライズされたマーケティング、データ駆動の商品開発、および効果的なターゲット広告のためのリテールメディアネットワークの連携を可能にする 5 つの主要な戦略に焦点を当てることを提案しています。 ロイヤルティプログラムの構築：ロイヤルティプログラムは、報酬と引き換えにデータを共有してもらうよう消費者にインセンティブの形でアプローチします。たとえば、割引や限定商品を提供することで、購入パターンに関する貴重なインサイトを収集し、リピート購入を促すことができます。 Starbucks はその好例です。 CRM システムの強化：ファーストパーティデータを CRM プラットフォームに統合することで、消費財企業は詳細な顧客プロファイルを作成できます。こうしたプロファイルを活用して、パーソナライズされたマーケティングキャンペーンや顧客とのより強固な関係構築が可能になります。 パーソナライズされたマーケティングキャンペーン：ファーストパーティデータを分析することで、ブランドは消費者の好みや行動に基づいてオーディエンスをセグメント化できます。たとえば、オーガニック製品（商品）に関心のあるセグメントを特定した企業は、こうした商品を強調してセグメント別のターゲットごとに最適化されたキャンペーンを作成し、コンバージョン率を高めることができます。 商品開発の最適化：ファーストパーティのデータは、商品イノベーションに役立つ消費者からの直接的なインサイトを提供します。したがって、企業が消費者の間でグルテンフリーのスナックへの関心が高まっていることに気付いた場合、需要に合わせてそうした種類の商品の開発を優先することができます。 リテールメディアネットワーク： iHerb や Oriental Trading などの企業は、Amazon Ads テクノロジーと連携して、パーソナライズされた広告を配信し、広告主とのつながりを最適化し、プラットフォーム全体で買い物客の体験を向上させています。これにより、企業は Amazon Ads をすでに利用しているブランドに広告を簡単に提供できるようになり、広告主とのつながりがスムーズになります。 AWS ベースのファーストパーティデータソリューションの主要インフラストラクチャコンポーネント 消費財企業が長期的な価値を追求したいのであれば、ファーストパーティのデータ戦略に投資すべきです。データの収集と利用に不可欠な AWS ソリューションとサービスを活用することで、企業は長期的な価値をいくつかの方法で実現できます。 テクノロジーインフラストラクチャ：顧客データプラットフォーム（Customer Data Platform; 以後 CDP）などのツールを導入することで、企業は複数のソースからの消費者データを統一されたプロファイルに一元化し、パーソナライズされたマーケティング活動を行うことができます。これには、クラウドストレージソリューションと分析ソフトウェアへの投資が不可欠です。 データ管理：企業には、クリーンで正確かつ安全なデータを維持するためのプラットフォームが必要です。データレイクには Amazon Simple Storage Service (Amazon S3) 、データウェアハウスには Amazon Redshift というのは素晴らしい選択肢です。というのも、分析を可能にしながら大規模なデータセットを安全に保存できるからです。 AWS Glue などのツールは、生データを自動的に取り込んで実用的なインサイトに変換し、データ準備の簡素化をサポートします。 データ分析とインサイト： Amazon SageMaker 、 Amazon QuickSight 、 Amazon Bedrock などの AWS 分析ツールは、CDP からのファーストパーティデータを分析してパターンを特定し、消費者の行動を予測することができます。 Amazon Q Business の生成 AI 機能は、自然言語によるインサイトを提供し、トレンド分析を自動化し、履歴データとリアルタイムの行動シグナルに基づいて顧客セグメントに関する予測を行います。 コンプライアンスへの取り組みとプライバシー遵守： AWS Artifact は、企業が監査レポートにアクセスできるようにし、規制コンプライアンスを維持できるようにする包括的なコンプライアンスツールと認証を提供しています。このソリューションには、きめ細かなアクセス制御、暗号化機能、および地域別のデータ保存オプションが付属しているため、組織は詳細な監査証跡を維持しながら特定のプライバシー要件を満たすことができます。 組織的な連携：Amazon S3 と Amazon Redshift によってデータの保管場所を集約することができますが、消費財企業はこれらを利用して部門間のコラボレーションを促進することもできます。さらに、 AWS Lake Formation と AWS Glue を使用して、抽出、変換、およびロード機能とともに安全なデータ共有をサポートできます。最後に、Amazon QuickSight と Amazon OpenSearch Service は、チームが共有データを分析して視覚化するのをサポートします。これらのサービスには、さまざまな部門に適切なアクセスレベルを割り当てて管理するアイデンティティアクセス管理コントロールが含まれます。 こうしたシステム導入には初期投資が必要な場合がありますが、ROI は確実に得られます。 IDC と Forrester の調査によると、ファーストパーティのデータを広告ターゲティング戦略に統合することで、ビジネスに大きなメリットがもたらされることがわかっています。これを実施した企業は、AI 駆動のインサイトを利用してメディア支出を再配分することで、購入数を 500% 向上させ、広告のクリックスルー率（CTR）を 300% 向上させ、顧客満足度を 78% 向上させ、コンバージョン率を 73% 向上させました。 AWS の包括的なツールキットで生成 AI の力を引き出す AWS のエンタープライズソリューションは、 Claude や Llama 2 などの大規模言語モデル (LLM) へのアクセスを提供する Amazon Bedrock を中核としています。 また、コンテキストに応じたリアルタイムの応答のための検索拡張生成機能が備わっている Amazon Titan にもアクセスできます。Amazon Q for Business では自然言語でデータのやりとりが可能で、Amazon SageMaker はモデル開発およびデプロイツールを提供します。企業はまた、自然言語処理のための Amazon Comprehend 、インテリジェントなエンタープライズ検索のための Amazon Kendra 、そして Amazon Q Developer を実装することもできます。これらのツールを組み合わせることで、組織は安全でスケーラブルな AI ソリューションを導入し、さまざまなユースケースを通じてビジネスを変革できます。以下は、AWS のソリューションとサービスを使用して顧客体験とエンゲージメントを強化した方法のほんの一部です。 1. インテリジェントなカスタマーサポート：パーソナライズされたインタラクションをリアルタイムで提供し、日常業務を自動化することで、顧客体験を向上させます。消費財ブランドは以下を使用してこれを実現できます。 a. Amazon Connect ： AI 搭載のチャットボットと音声アシスタントにより、24 時間 365 日の顧客セルフサービスを実現 し、待ち時間を短縮し、初回問い合わせの解決率を向上させます。 b. Amazon Lex V2：音声とテキストを使用するアプリケーション用の会話型インターフェイスを構築します。Amazon Bedrock の生成 AI 機能を使用して、Amazon Lex V2 ボットのボット作成を自動化し、スピードアップさせます。 c. Amazon Q in Connect ：動的で状況に応じた応答を生成し、エージェントと顧客への正確で、共感をもたらすコミュニケーションを実現します。 2. パーソナライズされた顧客エンゲージメント：生成 AI と顧客データ分析を組み合わせることで、高度にパーソナライズされた体験を実現します。これにより、ブランドはマーケティングメッセージ、レコメンデーション、オファーを顧客にあわせて簡単に調整できます。 a. Amazon Personalize ：AI により高度にパーソナライズされたユーザー体験をリアルタイムで大規模に提供することで、顧客体験を向上させます。 b. Amazon Bedrock：複数の大規模言語モデル (LLMs) から選択可能で、パーソナライズされた E メール、商品説明、プロモーションコンテンツを生成します。 c. Amazon SageMaker：ML モデルを構築し、ターゲットを絞ったキャンペーンを作成するために顧客行動を分析します。 3. プロアクティブな顧客への働きかけ：生成 AI を使用して顧客のニーズを予測し、タイムリーな対応を開始することで、プロアクティブなエンゲージメントを容易にします。 a. Amazon Connect のセグメンテーション機能：リアルタイムデータと履歴データに基づいて顧客を自動的にセグメント化し、ML と生成 AI の両方を使用してパーソナライズされたアウトリーチキャンペーンを生成します。 b. Amazon Comprehend：顧客からのフィードバックのセンチメントを分析して、積極的にエンゲージすべき機会を特定します。 4. エージェント支援の強化：顧客とのやり取り中に、生成 AI を活用したリアルタイムのインサイト、要約、レコメンデーションをブランド担当者に提供してサポートします。 a. Amazon Q in Connect ：通話中やチャット中に関連情報にすぐにアクセスできるため、エージェントの作業体験が向上し、生産性が向上します。 b. Amazon Kendra：インテリジェントなエンタープライズ検索をサポートして、ナレッジベースから正確な回答を取得します。これにより、担当者の調査時間が節約され、提供する情報の正確性が向上します。 5. セルフサービスの強化：生成 AI により、企業は直感的で効果的、かつ高度なセルフサービスオプションを提供して顧客が自分で実行できることを増やします。 a. Amazon Transcribe ：自動で音声入力をテキストに変換して、シームレスなやり取りを実現します b. Amazon Translate ：多言語に対応できるため、世界中の顧客にアプローチできます。 生成 AI は、業務のビジネス面だけでなく、顧客にもメリットをもたらします。例としては次のような機能があります。 パーソナライズされた自動応答により、問題をより迅速に解決できます。AI を搭載したシステムは、顧客からの問い合わせを即座に分析して応答できるため、応答時間を短縮できます。自動応答は顧客の履歴とコンテキストに基づいてパーソナライズされるため、数時間ではなく数分で正確なソリューションを提供できます。 シームレスなやり取りを通じて顧客満足度を高めます。一貫性のある正確な回答は、顧客満足度スコアを向上させることができます。AI システムは、24 時間 365 日、遅延なくサポートを提供し、ピーク時でも高品質を維持したサービスを提供できます。 正確なターゲティングによりコンバージョン率を高めます。AI は顧客の行動パターンと購入履歴を分析して的を絞ったレコメンデーションを提供します。その結果、従来の方法と比較して、クエリの解決が速くなり、コンバージョン率が高くなります。 実際に発生する前に顧客のニーズを予測します。予測分析を使うと、行動パターンと履歴データに基づいて潜在的な顧客ニーズを特定します。これにより、積極的なサポート介入が可能になり、顧客がサポートに問い合わせる回数が減ります。 不満に早期に対処することで解約率を減らします。リアルタイムの感情分析により、解約リスクのある顧客を特定し、即時対応を可能にします。問題の早期発見と解決は、顧客離れを減らし、顧客維持率を高めます。 多様なデータを最大限に活用 ファーストパーティのデータは、第三者による Cookie の利用が制限されつつある状況をうまく乗り切っていかなければならない消費財企業にとって重要な資産として浮上しています。AWS を使用することで、企業は社内と社外の両方でデータをさらに活用できるようになりました。生の顧客データを実用的なインサイトに簡単に変換し、よりパーソナライズされた経験を提供できるので、消費財企業にはこれまで以上に多くの選択肢を持つことができます。 データのニーズについて相談したい場合や、小売店向けに 生成 AI ソリューションを導入する準備ができている場合は、AWS がお手伝いします。 今すぐアカウントチームに連絡して始めましょう。 その他の参考資料 Tapestry は、何千人もの店舗スタッフから顧客の需要に関するリアルタイムのフィードバックを収集し、在庫管理と店舗の品揃えを最適化しました。 Adidas は AWS の生成 AI を使用して、受信者ごとにカスタマイズされたマーケティングキャンペーンを提供し、エンゲージメント率を向上させています。 DoorDash は Amazon Connect と Amazon Lex を使用してインタラクティブな音声応答システムを作成し、エージェントの移動距離を 49% 削減し、ファーストコンタクトの解決率を 12% 向上させ、年間 300 万ドルの経費節減を実現しました。 Frontdoor, Inc. の経験から、AI を活用したワークスペースがいかにエージェントの能力を強化し、顧客からの複雑な問い合わせに初日からより効果的に対処できるようになるかが明らかになっています。 著者について Udit Jhalani Udit は、バージニア州アーリントンを拠点とする AWS の 消費財シニアソリューションアーキテクトです。彼はクラウドベースのアプリケーションの設計に豊富な経験があります。彼は現在、大企業と協力して、そうした企業が拡張性、柔軟性、耐障害性に優れたクラウドアーキテクチャを構築することを支援し、クラウドに関するあらゆることを指導しています。彼はニューヨーク州立大学でコンピューターサイエンスの理学修士号を取得しており、「ソフトウェアは進化させなければ意味がない」という Dr. Werner Vogels の格言を信奉しています。 Krishnan Harihanan Krishnan はシカゴを拠点とする AWS のソリューションアーキテクチャ兼シニアマネージャーです。現在の役職では、顧客、商品、テクノロジーに関する広範な知識、運用に関する多様なスキルを活用して、小売/消費財企業の顧客が AWS を使用して最適なソリューションを構築できるよう支援しています。AWS に入社する前は Kespry 社の社長兼 CEO、LightGuide 社の COO を務めていました。デューク大学 Fuqua School of Business で経営学修士号を、デリー大学で電子工学の理学士号を取得しています。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

本記事は 2025 年 4 月 17 日に公開された “ Announcing General Availability of GitLab Duo with Amazon Q ” を翻訳したものです。 本日（原文公開日 : 2025/4/17）、 GitLab Duo with Amazon Q の一般提供開始を発表できることを嬉しく思います。この新しいサービスは、 GitLab の DevSecOps プラットフォームと Amazon Q の生成 AI 機能を組み合わせた製品です。GitLab Duo with Amazon Q は、GitLab の DevSecOps プラットフォームに Amazon Q エージェント機能を直接組み込み、ソフトウェア開発ライフサイクル全体にわたる複雑で多段階のタスクを加速します。 現在の急速に変化するソフトウェア開発環境では、開発者はコード品質やセキュリティ、デプロイメントのベストプラクティスを維持しながら、いかに生産性を高められるかを日々模索しています。GitLab Duo と Amazon Q の統合により、GitLab の包括的な DevSecOps プラットフォームと Amazon Q のインテリジェントなコーディング支援が組み合わさり、こうしたニーズに応えます。 この統合により、開発者は普段使い慣れた GitLab 環境の中で、アイデアの構想からデプロイメントまで、開発プロセス全体を通して AI を活用できます。新規ユーザーも既存ユーザーも、IDEで利用しているのと同じ Amazon Q Developer エージェントをそのまま GitLab でも使えるため、ツールが変わっても操作感は変わりません。 主な利点と機能 GitLab Duo と Amazon Q の統合が、より効率的で安全、かつ協調的なワークフローを作り出し、開発チームに大きな価値をもたらします。 この統合により、開発者は強力な AI 支援機能に GitLab から直接アクセスできるため、ツールや環境を切り替る必要がなくなります。GitLab は安全なコードのビルド、テスト、パッケージング、デプロイメントを自動化し、開発ライフサイクル全体を効率化します。とくに優れているのは、AI エージェントが GitLab プロジェクト全体のコンテキストを活用し、 ソフトウェア開発ライフサイクルの「ループ」を継続できることです。失敗したパイプラインのトラブルシューティング、脆弱性の調査、新機能の作成など、ありとあらゆる場面で、Amazon Q エージェントは適切なコンテキストを活用して適切なサポートを提供します。 セキュリティとコンプライアンスは、この統合の基本要素です。エンドツーエンドのセキュリティ制御がプラットフォームに直接組み込まれています。Amazon Q エージェントには適切なガードレールが備わっており、開発速度に影響を与えることなくコンプライアンスを満たすのに役立ちます。また、AWS のクラウドインフラストラクチャを活用することで、AI を取り入れた開発プロセスを安心して拡張できます。さらに、プロジェクトの脆弱性レポートの修正や、失敗したパイプラインのトラブルシューティングも Amazon Q エージェントに依頼できます。 開発プロセス全体にわたり、さまざまなタスクを支援する協調的な AI エージェントが用意されています。たとえば、Java コードをバージョン 8 または 11 から 17 にアップグレードする必要がある場合や、AI を活用したコードレビューの提案がほしい場合、包括的なテストケースを自動生成したい場合、または、アイデアをそのままマージリクエストに変換したい場合など、あらゆる場面で Amazon Q がサポートします。これらのインテリジェントなエージェントはチームと連携して作業し、生産性を向上させます。 ユースケースと例 GitLab と Amazon Q がどのように連携して開発生産性を加速し、組織のアプリケーションセキュリティを支援するかをお見せするために、ここではパズル愛好家に人気のある Java アプリケーションを使用してご紹介します。 アイデアからマージリクエストへ 開発者チームを拡大したい場合でも、機能リクエストから本番環境へのプロセスを効率化したい場合でも、GitLab Duo with Amazon Q は GitLab のプラットフォームに統合されており、GitLab の Issue を Amazon Q Developer エージェントに割り当てるだけで開発を始められます。 まず、GitLab プロジェクトでタスクを作成します。Q words ゲームに複数の言語をサポートする新機能を追加したいと思います。 ここから、Issueのコメントセクションで GitLab の クイックアクション の「 /q dev 」を使用して、タスクを直接 Amazon Q エージェントに割り当てます。 エージェントは、提案されたコード変更を確認するためのマージリクエストを自動的に作成します。ここでは、エージェントがフロントエンド、API、スタイル変更を含む 11 のファイルにわたる修正を行ったことが確認できます。以前であれば、IDE を立ち上げ、プロジェクトをクローンし、自分でこれらの変更をコーディングしていたでしょう。GitLab Duo with Amazon Q を使えば、新しいコードを確認してテストするだけで、すぐにデプロイの準備が整います。 コードレビュー コードレビューは開発ライフサイクルにおいて重要な機能を果たします。セキュリティやコーディング標準の高い品質を維持するための品質ゲートとして機能します。しかしその一方で、レビュアーが不在だったり、変更が複雑だったりすると、コードレビューはソフトウェアのリリースを遅らせる要因にもなります。 GitLab で利用できる Amazon Q エージェントによるコードレビュー機能は、チームがコードレビューをより迅速に進めるのに役立ちます。マージリクエストのコメント欄でクイックアクション「 /q review 」を実行すると、そのマージリクエストが Amazon Q に送信され、コード変更に関連するセキュリティや品質のリスクを自動的に検出します。 まず、マージリクエストを作成します。この例では、別の開発者が Q words アプリケーションに認証を追加するタスクを担当していました。 次に、クイックアクション「 /q review 」でエージェントを呼び出します。 レビューはマージリクエストにインラインのコード提案として返されます。ここでは、レビューエージェントによる指摘の一例を確認できます。コメントには発見された問題の説明と、コードを改善するためのガイダンスと関連リンクが含まれています。 次に、ウェブインターフェイスで GitLab Duo with Amazon Q のチャットエージェントを使い、変更内容の要約を依頼し、重要な問題を強調するようリクエストします。GitLab Duo チャットでは、現在の URL で表示されているリソースについて質問できます。この例ではマージリクエストについて質問していますが、他にも GitLab の Issue やリポジトリ内のコードファイルの概要についても質問できます。 テスト生成 次に、クイックアクション「 /q test 」を使用して、GitLab Duo with Amazon Q にテストの生成を依頼します。このアクションをコメントフィールドに追加すると、マージリクエストに十分なテストが含まれてない場合に、推奨されるテストコードが自動で生成されます。 GitLab Duo with Amazon Q から受け取る概要は、変更の範囲を把握するのに役立ち、重要なポイントに注意を集中させてくれます。さらに、Q Developer エージェントが提案したテストを活用することで、マージリクエストをより短時間で承認できます。 Java 変換 古いバージョンの Java アプリケーションを Java 17 にアップグレードすることは、時間がかかり、エラーが発生しやすい作業です。GitLab Duo と Amazon Q を使用すると、変換エージェントを活用して Java 8 コードから Java 17 へのコード移行を自動化し、プロジェクトの依存関係もアップグレードできます。まずは、GitLab プロジェクトで Java アップグレードに関する新しい Issue を作成します。 アップグレードを開始するには、GitLab Q のクイックアクション「 /q transform 」を使用します。Amazon Q 変換エージェントは、プロセスを続行するために gitlab-ci.yaml ファイルの更新を求めてきます。 エージェントの進行状況は、Issue の詳細画面で更新内容を確認することで把握できます。また、GitLab Duo with Amazon Q は、アップグレードに必要な変更内容を把握できるよう、Issue に変換計画も追加します。 変換が完了すると、確認のための新しいマージリクエストが自動的に作成されます。ご覧のとおり、pom.xml ファイルが Java 17 にてコンパイルできるように更新され、さらにプロジェクトが正しくコンパイルされるように追加の変更も行われています。さらに、更新された Java コードをマージしてデプロイする前に検討すべき次のステップを詳しくまとめたレポートも含まれています。 まとめ この記事では、GitLab Duo with Amazon Q がアプリケーション開発のスケールと改善にどのように役立つかをご紹介しました。GitLab Duo with Amazon Q を活用することで、GitLab の統合されたインターフェイス内で、追加機能の迅速な実装、コード変更のレビュー、アプリケーションの Java 17 へのアップグレードまで、すべてをスムーズに実施できました。これで、スペイン語の練習にも使える、安全でモダンな Java アプリが完成しました。 GitLab Duo with Amazon Q の一般提供は、AI を活用したソフトウェア開発における重要なマイルストーンとなります。GitLab の包括的な DevSecOps プラットフォームと Amazon Q の生成 AI 機能を組み合わせることで、この統合は開発チームがセキュリティとコンプライアンスの高い基準を維持しながら、より効率的に作業できるよう支援します。 組織はこの強力な統合を活用してソフトウェア開発ライフサイクルを加速し、手作業を減らし、より安全なコードをより迅速に提供できるようになります。シームレスな開発者体験、エンタープライズグレードのセキュリティ、開発プロセス全体にわたる協調的な AI エージェントにより、この統合はあらゆる開発チームのツールキットにとって価値ある追加となるでしょう。私たちは、お客様がこの統合を活用して開発プロセスを変革し、生産性とイノベーションの新たなレベルを達成されることを楽しみにしています。 さらに学びたい方はこちら GitLab Duo ドキュメント Amazon Q ドキュメント GitLab Duo with Amazon Q へのアクセスを取得 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Ryan Bachman Ryan Bachman は、Amazon Web Services（AWS）Next Generation Developer Experience チームのシニアスペシャリストソリューションアーキテクトです。Ryan は、クラウド向けアプリケーション開発の効率を高めるプロセスとサービスの採用をお客様が支援することに情熱を持っています。彼は開発、ネットワークアーキテクチャ、テクニカルプロダクトマネジメントなどの役割を含む 20 年以上の専門的な技術者としての経験を持っています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。 GWはリフレッシュできましたでしょうか？　休み明けの今週は火、水、木と生成AI関連のイベントが続きます！ 5 月 13 日 (火)：Coding Agent Workshop ~ 開発生産性向上とガバナンスの両立を目指した、Cline with Amazon Bedrock活用のコツ 5 月 14 日 (水)：JAWS-UG Expert Online: Amazon Q Developer 特集 5 月 15 日 (木)：GenAIOps – 生成 AI オブザーバビリティを Amazon Bedrock と Langfuse で実現 イベントの申し込み方法などのリンクはこちらのブログ「 生成 AI 最前線！5月開催の AWS 生成 AI イベントガイド 」にまとめていますので是非参照してみてください。 また、6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 の事前登録 が始まっていますのでこちらも登録をお忘れなく！ それでは、5 月 5 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Amazon Nova Premier: 複雑なタスクを実行したり、モデル蒸留の教師として機能させたりするための、当社の最も有能なモデル」を公開 ついに Amazon Nova Premier の一般提供を開始しました。これは複雑なタスクの実行や100万トークンの長文処理が可能な高性能モデルで、テキスト、画像、動画を処理できます。特筆すべき点は、モデル蒸留の教師モデルとしても機能し、Nova Pro、Lite、Microなどの小規模モデルに高度な機能を効率的に移行できることです。17のベンチマークで最高性能を示し、業界最高クラスの非推論モデルと同等以上のパフォーマンスを発揮します。Amazon Bedrock で利用可能で、マルチエージェントコラボレーションなど複雑なワークフローにも対応し、コスト効率の高いソリューションを提供します。 ブログ記事「Amazon Q Developer が新しいエージェントコーディングエクスペリエンスで IDE エクスペリエンスを改善」を公開 Amazon Q Developer に新しいエージェントコーディング機能が追加され、Visual Studio Code 上でより直感的な開発体験が可能になりました。素晴らしいのはこの機能により、自然な対話を通じてコードの作成、ドキュメント作成、テスト実行などがリアルタイムで行えるようになります。英語を含む10言語に対応していることや、コードベースのコンテキストを理解した的確な提案が可能なこと、そして Amazon Q Developer Pro と Amazon Q Developer 無料利用枠の両方で追加コストなく利用できることです。是非一度お試しください。 ブログ記事「Amazon Q Developer in GitHub (プレビュー) がコード生成を加速」を公開 GitHub環境で直接利用できるAmazon Q Developer for GitHub（プレビュー）の提供を開始しました。このツールを使用することで、GitHubのIssueに「Amazon Q Developer agent」ラベルを付けるだけで、新機能の開発から自動コードレビューまでをAIが支援してくれます。特筆すべき点は、セキュリティリスクの自動検出機能や、Java 8/11からJava 17への自動コード移行機能を備えていることです。AWS アカウント不要で無料で利用できるため、GitHubを日常的に使用する開発者の生産性向上に大きく貢献します。まさにAIを活用したフルスタック開発支援ツールとして、コード品質の向上とプロジェクトの効率化を実現します。 ブログ記事「Amazon Q Developer for GitHub (プレビュー) を活用して開発ワークフローを加速し、リリースサイクルを短縮する」を公開 開発 サイクルを短縮するためタスクを自動実行できる Amazon Q Developer for GitHub（プレビュー）は、AWS アカウントが不要で無料利用できます。Amazon Q Developer は GitHub.com と GitHub Enterprise Cloud での機能開発を加速します。。追加コストなしで Q Developer を支える高性能モデルを活用し、新機能の自動実装、バグの修正、テストカバレッジの向上、ドキュメント作成、すべての新しい Pull Request に対するコードレビューの実行、レガシー Java アプリケーションのモダナイズを行うことができます これらは GitHub 上にある Issue と Pull Request を使用しながら実現できます。 builders.flash 「天気のことならなんでも聞いて !」Amazon Bedrock で作るお天気エージェント ~ 株式会社ウェザーニューズによる実装解説」を公開 株式会社ウェザーニューズは、Amazon Bedrock を活用して気象情報のアシスタント機能「お天気エージェント」を開発しました。このシステムは、LangChain Agentsを利用し、Claude 3.5 Sonnet v2 モデルを採用することで、ユーザーからの多様な天気関連の質問に柔軟に対応できます。独自の気象データと組み合わせることで高い信頼性を確保し、ユーザーは「車で2時間の週末晴れる観光スポット」といった従来のアプリでは得られなかった情報まで取得できるようになりました。builders.flashでは「お天気エージェント」開発の背景や実装について解説しています。 「3 分でプロレベルの記事が完成 ! Amazon Bedrock を活用した AI コンテンツ作成支援機能の実装」を公開 株式会社いえらぶGROUPは、不動産業界向けSaaS「いえらぶCLOUD」に、Amazon Bedrock を活用したAIコンテンツ作成支援機能を実装しました。この機能は、Claude 3.5 Sonnet v2 を利用し、不動産業者が対象読者とSEOキーワードを入力するだけで、わずか3分程度でプロレベルのブログ記事を自動生成できます。従来3〜4時間かかっていた記事作成が大幅に効率化され、「書く時間が取れない」という課題を解決しています。builders.flashではAI コンテンツ作成までの流れやプロンプトエンジニアリングの工夫などを解説しています。 サービスアップデート GitHub向けのAmazon Q Developer 統合機能（プレビュー版）が利用可能に GitHub環境で直接利用できる Amazon Q Developer for GitHub（プレビュー）を発表しました。開発者はGitHub.comとGitHub Enterprise Cloudプロジェクトにおいて、機能開発、コードレビュー、Javaコード変換などをAmazon Q Developerエージェントを通じて実行できます。詳細はこのブログの前半で紹介した ブログ記事「Amazon Q Developer for GitHub (プレビュー) を活用して開発ワークフローを加速し、リリースサイクルを短縮する」を公開 を参照ください。 Amazon Bedrock Data Automationが音声からのカスタムインサイト抽出に対応 Amazon Bedrock Data Automation（BDA）が、ブループリントを通じて音声データからのカスタムインサイト抽出機能を追加しました。ブループリントをニーズに合わせてカスタマイズすることで、顧客との通話や臨床討論、会議など様々な音声会話から要約、重要トピック、意図、感情などの洞察を抽出できます。この機能は米国西部（オレゴン）および米国東部（バージニア北部）のAWSリージョンで利用可能です。 Amazon SageMaker AIがカスタムコード提案とワークスペースコンテキストでAmazon Q Developerを強化 Amazon SageMaker AI Jupyter LabにおけるAmazon Q Developerの機能強化を発表しました。プライベートコードリポジトリに基づくコード提案のカスタマイズ機能では企業や組織が持つ独自のプログラムを学習させることで、その組織に最適なコード提案ができるようになります。ワークスペース全体のコンテキストを含めた支援機能では、開発中のプロジェクト全体を理解した上でアドバイスができるようになります。これにより、例えば「このプロジェクトではこういう書き方が推奨されています」といった、より実践的なサポートが可能になります。開発者は通常のチャット感覚でAIに質問でき、プロジェクトの規模や複雑さに関係なく、一貫性のある高品質なコード作成支援を受けられます。 今週は以上でした。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅焼き鳥で串打ちにハマっています。

みなさん、こんにちは。ソリューションアーキテクトの松本です。本記事では、2025/04/15 に開催された、 流通小売・消費財のお客様向けの基幹システム移行イベント の内容をお伝えいたします。 イベントの目的 市場の拡大や頻繁に変化する顧客のニーズに対応するために、流通小売・消費財業界ではテクノロジーを活用して組織やシステムの柔軟性を保つことが求められます。AWS クラウドへの移行はシステム基盤のコスト削減だけでなく、ビジネス側からの要求に短期間で応えられるようになることも含みます。コアビジネスこそ AWS に移行することでビジネスの俊敏性を実現し、企業の経営戦略に貢献できます。しかし、そのための障壁、変化へのリスクやレガシーシステムであること、クラウド人材の不足といったものからクラウド移行を躊躇される企業様を見受けるケースがあります。このイベントではそれらを乗り越えられた顧客事例をご紹介し、ビジネス変革へのチャレンジの参考にしていただくことを目的としました。 当日にご参加のお客様はクラウドへの リフト & シフト をご検討中である傾向がありました。 当日のアジェンダ このイベントでは、ユーザー企業様に事例登壇をしていただき、パネルディスカッションでさらに取り組みを伺う構成にしました。 コーナン商事株式会社 佐々木 史人氏 コーナン商事株式会社 佐々木 史人氏からは、「事業の成長を支える基幹システムを中心としたオンプレミスから AWS へのシステム移行」と題してお話いただきました。 登壇内容のポイント オンプレミス環境でのデータ保持制限や高コスト、拡張性の問題が移行の契機となった。 コストや基盤停止リスクの声 に対し丁寧な説明を行い、専任部署を設置して円滑な移行を実現した。 AWS移行後、データの長期保管や分析が可能となり、店舗情報の共有も効率化された。 コーナン商事株式会社様が AWS に移行する前のシステム課題として、既存のオンプレミスシステムが Solaris 上で構築されており、POS をはじめとする業務データを 1 年ごとに捨てざるを得ず、OS の将来性やディスク装置の拡張性に懸念がありました。また、開発コストが高いファイルベースの他システム連携や、Oracle や VMware を使い続ける場合の高いコストも課題でした。そこで、今後の事業拡大を見据えて、これらの課題を解決するために AWS への移行を検討しました。 移行にあたっての課題は、主に社内の抵抗感でした。特に、既存のオンプレミスのみを経験していたベンダーやシステム部門のメンバーからの疑念が強かったとのことです。これに対して、例えば従量課金でのコストの懸念に対しては、クラウドでは必要最低限のスペックで運用でき、コストを抑えられるという説明をされました。また、クラウドの突然の停止や遅延に対する懸念に対しては、オンプレミスでは全て自分たちで対処する必要があるのに対して、AWS なら基盤が自動復旧するので運用負荷を下げられることを説明されました。他にもセキュリティの確保や運用体制の構築といった対処によって社内の理解を得ました。 移行スケジュールは、2019 年から検討を開始し、移行は 2020 年 1 月から着手、2021 年 6 月には オンプレミスから AWS に切り替えました。移行後は、発注量の多い年末年始に OS レイヤーの設定起因で障害が起きたものの、その後は安定稼働を続けています。そして、AWS 移行ができたことでさらなる事業の成長に向けた、拡張性のある基盤を獲得できました。 Amazon S3 を使ったデータレイクを導入し、データの無期限保管が可能になったことで、BI で長期間のデータを分析できるようになりました。また、データレイクから API 基盤を通じたデータ連携により、EC サイトやコールセンターでも 1 時間ごとの店舗在庫情報が参照可能になりました。 コーナン商事株式会社 佐々木 史人氏 クラウド化にあたっての振り返りとしては、システム部門と異なる専任部署を独立させて、これを主導したことで、大きなスケジュール遅延を回避し、システム部門の通常業務も維持しながら移行を進めることができたとのことです。また、移行準備期間中に有償の AWS セミナーに参加し、クラウドに関する知識を深めたことで、ベンダーとの円滑なコミュニケーションが可能になりました。一方で、社内でのクラウド人財をもう少し確保していれば知見がたまりやすかったことや、移行中の想定外のコスト増加に注意しておくと良かったことも述べられていました。 青山商事株式会社 石塚 正明氏 青山商事株式会社 石塚 正明氏からは、「基幹システムの AWS 移行から始まる DX への挑戦 〜決断から実践、そして未来への展望」と題してお話いただきました。 登壇内容のポイント 高額な保守費用と非効率な運用体制の改善のため、AWS への移行によるシステム刷新を決断した。 複雑な多層構造のシステムがネックだった ため、ゼロベースの要件定義からの再構築を選択した。 AWS 移行後、自社でのシステム理解が進み、データ活用や新技術導入への基盤が整備された。 青山商事株式会社 石塚 正明氏 青山商事株式会社様では、システム保守費用が小売業平均の 3 倍以上かかっていました。これは、複数システムに存在した類似機能、不明瞭なシステム構造、情報システムにかかわる償却や維持費用を積み上げてきたためでした。また、基幹システムがバッチ処理中心である一方、EC システムはリアルタイム処理が必要なため、在庫データを二重に持つなどの非効率な運用を強いられていました。こうした状況から、デジタル化を加速するには、最新のテクノロジーを拡充できる柔軟性と拡張性のあるインフラ環境を獲得した上で、シンプルかつリアルタイムに連携出来るシステムにマイグレーションすべきとの仮説を立て、クラウド環境への移行を前提に、システムのマイグレーションを進める決断をしました。他社クラウドと比較検討した上で保守性・柔軟性・技術者の多さ、そして 小売業からの発祥である点を踏まえて AWS を選定されました。 基幹システムは、メインフレームの COBOL で書かれたシステムを最下層として、その上に Solaris、Red Hat など異なる OS で作られたシステムが重なる多層構造であり、さらに EC システムは 古い OSS パッケージに機能拡張をしていました。しかし、前述した状況を打開し、時々刻々と変化する事業状態を営業、損益、顧客、そして商品視点で見える化するためには、根幹となる基幹システムと機能冗長が著しかった EC システムをシンプルなシステムにする必要がありました。そこで、既存システムベースでの置き換えは断念し、ゼロリセットで要件定義から開発を進める決断をされました。 青山商事株式会社様はオンプレミスの経験しかなく、はたして AWS で構築が出来るのかと不安がありましたが、AWS アカウントチームおよびパートナー会社からのサポートを受けながら社員のリスキリングを行いました。テスト工程時の環境設定等で様々なトラブルはありましたが、2024 年末に移行させることができました。 移行を完了した後に不具合が発生しており完全な安定稼働とは言えない状況ではあるものの、これまでシステムベンダーに丸投げしていた開発について、自社で中身を理解し、開発ベンダーと直接対話できるようになったことは大きな進歩であり、経営層にも世に言われる 2025 年の崖を乗り越えられたと理解を得られています。また、業務フローやデータの使われ方についての理解が深まり、社内にナレッジが蓄積されるようになったとのことです。 AWS に移行したことでデジタル化推進の基盤を整備できた青山商事株式会社様は、 GenU という AWS の生成 AI アプリケーションの利用や Amazon Connect を活用したクラウドベースのコンタクトセンターの運用も行っています。また、アプリケーションのデータを Amazon S3 に蓄積できているため、今後はデータドリブンな経営ができるためのダッシュボードの作成や、OMO 戦略の加速によるシームレスな顧客体験の提供といった新しい取り組みに、AWS とのパートナーシップを活かして挑むとのことです。 株式会社ポーラ・オルビスホールディングス 佐々木 哲哉氏 株式会社ポーラ・オルビスホールディングス 佐々木 哲哉氏からは、「クラウドで拓く基幹システム革新と持続的変革への挑戦」と題してお話いただきました。 登壇内容のポイント モノリシックな基幹システムの技術負債と外部依存が経営リスクとなり、クラウド移行を決断した。 一挙に移行したときの失敗 を踏まえて段階的に移行してコストを削減し、経営層への可視化と理解促進に成功した。 現在は経営戦略と連動したIT戦略として、クラウドネイティブな組織・システム変革を推進している。 株式会社ポーラ・オルビスホールディングス 佐々木 哲哉氏 株式会社ポーラ・オルビスホールディングス様の基幹システムは、EC とリアルな顧客接点を統合し、商品企画から出荷、会計まで一気通貫で支える集中型のモノリシックな構成となっていました。そのため、システムの変化への対応力が著しく低く、アーキテクチャの進化に追従することが困難でした。また、外部ベンダーへの依存度が高く、エンジニアの外注単価の高騰やシステムのブラックボックス化もあり、基幹システムが大きな技術負債となり経営リスクとなっていました。このような課題を放置していると、顧客体験の質も向上せず、外部サービスとの連携も遅れ、企業の競争力を損なう恐れがあると判断し、クラウド移行を決断されました。 株式会社ポーラ・オルビスホールディングス様の AWS 移行は 3 つのフェーズに分けられます。第 1 フェーズでは、2018 年から2019年にかけて、業務とシステムを同時にシンプル化する次世代システムの再構築に挑戦しましたが、この取り組みは頓挫しました。失敗の主な要因は、業務のシンプル化が実現できなかったことによる膨大なコストと長期の開発期間のために事業の戦略案件との同時並行が実現できなかったことでした。また、関係者の意識改革や組織文化の変革が不十分だったこと、経営者の意思決定に必要な具体的な成果や実現可能性を十分に示せなかったことも大きな要因であったと述べられていました。 第 2 フェーズでは、2022 年までにクラウドリフトとリファクタリングによる段階的なクラウド移行を実施しました。このフェーズでは、システム環境の変化による成果を数値で可視化することに重点を置きました。例えば、EC サイトでは受注数が 5 分間で 5 倍以上に跳ね上がるような急激な負荷変動が発生しますが、オンプレミス環境では常時 2 倍の余剰リソースを確保する必要があった一方、クラウドでは必要な時だけリソースを確保できる柔軟性を経営者にも分かりやすく説明されました。クラウドの柔軟性を利用して、オンプレミスよりも少ない費用と短い時間でシステム復旧できることも説明されました。また、一部のシステムではサーバーレスアーキテクチャを採用して機能のリファクタリングを行い、事業戦略案件も実現しました。結果として、移行前と比べて 30% のインフラコスト削減、18% の開発コスト削減、リファクタリングしたシステムは 50% のインフラコスト削減を実現できました。 現在の第 3 フェーズでは、クラウドに移行したシステムのアーキテクチャ刷新に取り組まれています。これは単なる IT システムの変革ではなく、経営戦略と連動した IT 戦略として位置づけられています。具体的には、クラウドネイティブに特化した内製開発組織の構築、システム全体のアーキテクチャ刷新、IT ガバナンスの確立など、「ヒト・モノ・カネ」の各側面から変革を進めています。特に為替変動の影響でクラウドコストが上昇する中、単純なリフトにとどまらず、クラウドネイティブなアーキテクチャーへの移行を通じて、より本質的な変革を目指しています。具体的には開発スピードを 1/2 に、システムコストを 1/3 に抑えることを現実的な目標として進めています。 成果を可視化して経営層をはじめとする組織を味方につけ、組織の成長に合わせた段階的な移行を行い、経営戦略と IT 戦略を連動させるまでに至るステップを踏めているとまとめられました。 パネルディスカッション 各社様の登壇の後、パネルディスカッションを行い、システム移行の実態と今後の展望についてご紹介いただきました。 発言内容のポイント 移行前は基幹システムの再構築範囲や方法の判断に苦心した。 移行中は各社で人材育成とシステム理解に重点的に取り組んだ。 移行後はコスト最適化とデータ活用による価値創造を進めている。 移行前の段階では、各社とも経営層の理解を得ることに大きな苦労はなかったものの、具体的な移行方法の検討で課題に直面しました。特にコーナン商事株式会社様では、COBOL、Oracle、Solarisを使用したバッチ処理主体の基幹システムの機能群をどこまで移行するか、また作り直すかの判断に苦心されました。しかし、最終的には、将来の人材確保のしやすさを新しい技術での再構築を決断しました。 移行作業では、各社それぞれに特徴的な課題がありました。青山商事株式会社様では、現行システムにこだわらずゼロベースでの見直しを実施されました。その中で、古いシステムの多重構造テーブルの解析やシステム間インターフェースの理解に時間をかけられました。また、自社のプロジェクトメンバーの皆さんは AWS から提案を受けたトレーニングの受講や、プロジェクトマネジメントの方法を学び、移行プロジェクトの中で実践されました。学びに時間をかけることそのものが投資であったと述べられました。株式会社ポーラ・オルビスホールディングス様では性能テストでの課題をエンジニアの迅速な対応で克服し、マネージドサービスの活用で開発コストの削減に成功されました。また、コーナン商事様では Oracleから PostgreSQL への移行作業において、SQL の変更や新しいエンジンの学習に取り組まれました。 移行後は、各社ともコスト最適化に取り組んでいます。例えばコーナン商事株式会社様では、 AWS Cost Explorer や AWS 請求コンソール での料金の定期チェック、 Amazon EC2 リザーブドインスタンス の活用、不要リソースの削除など、きめ細かな対策を実施されました。また、青山商事株式会社様ではシステムの内部構造を自社で理解・管理する体制が確立し、株式会社ポーラ・オルビスホールディングス様はクラウドネイティブなアーキテクチャにすることでビジネス側の要求に応えられやすくなり、IT メンバーが成功体験を得られたことなど、組織のレベルアップにも取り組まれました。 今後の展望として、各社ともクラウドを活用した新たな価値創造を目指しています。青山商事株式会社様はシステム間連携の API 化を進め、データドリブンなビジネスモデルへの転換を図り、株式会社ポーラ・オルビスホールディングス様は例えば顧客の声の分析のように、消費者の多様なニーズへの迅速な対応を目指しています。コーナン商事株式会社様は、データレイクを活用した他システムとの連携強化や、店内での顧客向け商品探索サービスの提供を計画されているとのことです。 クラウド移行を単なるシステム基盤の刷新にとどめずに、ビジネス変革の重要な契機とされていることがわかりました。 お客様の声 本セミナー全体の CSAT（お客様満足度）は、4.66 / 5.0 となり、参加されたみなさまにご満足いただけるものであったと考えております。参加者からは、「各社の苦労話が聞けてよかった」「どの企業様も人材の育成に力を入れていることが印象に残った」といった感想をいただきました。 最後に 今回、ご登壇くださった、コーナン商事株式会社 佐々木 史人様、青山商事株式会社 石塚 正明様、株式会社ポーラ・オルビスホールディングス 佐々木 哲哉様 には心から感謝を申し上げます。各社のチャレンジや苦労を乗り越えた先に、ビジネスへの貢献ができていることは、参加された多くの企業様にとって参考になり、クラウド移行の動機を強めることになったと思います。また、本イベントの内容がみなさまのシステム移行の取り組みの一助となれば幸いです。