AWS Summit のシーズンが始まります! 4月1日週は AWS Summit Paris 、4月8日週には AWS Summit Amsterdam で、お客様、パートナー、報道関係者の皆様にお会いできるのを楽しみにしています。私はモバイルアプリデベロッパーが生成人工知能 (AI) を使用して生産性を高める方法を説明する予定です。見かけたらぜひお声がけください。 Summit での講演の準備が終わったので、3月18日週の AWS のリリースを振り返り、この要約を書きました。 3月18日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS License Manager を利用することで、 Amazon Relational Database Service (Amazon RDS) で IBM Db2 ライセンスを追跡可能に – 2023 年 12 月に IBM Db2 をリリースしたとき 、私は Amazon RDS についての記事を書き、自分の Db2 ライセンスを使用する必要がある旨をお伝えしました。3月25日より、 AWS License Manager を利用して Amazon RDS for Db2 の使用状況を追跡できるようになりました。 License Manager を利用すると、ライセンスをより良く管理でき、その可視性が高まるため、ライセンスの超過を制限したり、コンプライアンス違反や誤報のリスクを軽減したりするのに役立ちます。 AWS CodeBuild で AWS Lambda のカスタムイメージのサポートを開始 – Lambda コンピューティングで実行するように設定されたプロジェクトのために Amazon Elastic Container Registry (Amazon ECR) リポジトリに保存されている コンピューティングコンテナイメージを使用 できるようになりました。以前は、 AWS CodeBuild によって提供されるマネージドコンテナイメージの 1 つを使用する必要がありました。AWS マネージドコンテナイメージには、 AWS コマンドラインインターフェイス (AWS CLI) 、 サーバーレスアプリケーションモデル 、およびさまざまなプログラミング言語ランタイムのサポートが含まれています。 AWS CodeArtifact パッケージグループ設定 – パッケージリポジトリの管理者は、 複数のパッケージの設定を 1 か所で管理 できるようになりました。パッケージグループを使用すると、内部のデベロッパーによって、またはアップストリームリポジトリから、パッケージが更新される方法を定義できます。内部のデベロッパーによるパッケージの公開を許可またはブロックしたり、パッケージのグループについてのアップストリームの更新を許可またはブロックしたりできるようになりました。 詳細については、私のブログ記事をお読みください 。 Savings Plans のキャンセル – Savings Plans の購入後 7 日以内であればキャンセルできる機能 を発表しました。 Savings Plans は柔軟な料金モデルで、1 年間または 3 年間の時間単位の一定の支出を確約する代わりに、オンデマンド料金と比較して請求額を最大 72% 削減できます。購入してから間もない Savings Plan がニーズに最適ではないことがわかった場合は、それをキャンセルし、必要に応じて、ニーズにより合った別の Savings Plan を再購入できます。 Amazon EC2 Mac 専有ホストで、サポートされている macOS バージョンの表示が可能に – EC2 Mac 専有ホストでサポートされている 最新の macOS バージョンを表示できるようになりました 。これにより、専有ホストが希望の macOS バージョンのインスタンスをサポートできるかどうかを事前に検証できます。 Amazon Corretto 22 の一般公開を開始 – OpenJDK の機能リリースである Corretto 22 では、デベロッパー向けにさまざまな新機能と機能強化が導入されています。ストリームギャザラーや名前のない変数などの新機能は、より明確でメンテナンスしやすいコードを記述するのに役立ちます。さらに、ガベージコレクションアルゴリズムの最適化により、パフォーマンスが改善されます。同時実行性、クラスファイル、外部関数用の既存のライブラリも更新され、堅牢で効率的な Java アプリケーションを構築するためのより強力なツールキットが提供されます。 Amazon DynamoDB でリソースベースのポリシーと AWS PrivateLink のサポートを開始 – AWS PrivateLink を利用すると、 Amazon Virtual Private Cloud (Amazon VPC) 、 Amazon DynamoDB 、およびインターフェイス VPC エンドポイントとプライベート IP アドレスを使用するオンプレミスデータセンター間のプライベートネットワーク接続を簡素化できます。一方、 リソースベースのポリシー は、 DynamoDB リソースのアクセスコントロールを簡素化するのに役立ちます。リソースベースのポリシーを使用すると、リソースにアクセスできる AWS Identity and Access Management (IAM) プリンシパルと、そのリソースに対して実行できるアクションを指定できます。リソースベースのポリシーを DynamoDB テーブルまたはストリームにアタッチできます。また、リソースベースのポリシーにより、異なる AWS アカウントの IAM プリンシパルとリソースを共有するためのクロスアカウントアクセスコントロールも簡素化されます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深いと思われる追加のニュース項目、オープンソースプロジェクト、Twitch の番組をいくつかご紹介します。 British Broadcasting Corporation (BBC) が 25 PB のアーカイブを Amazon S3 Glacier に移行 – BBC Archives Technology and Services チームは、100 年前の重要なアーカイブを一元化、デジタル化、移行する最新のソリューションを必要としていました。同社は Amazon Simple Storage Service (Amazon S3) Glacier Instant Retrieval の利用を開始しました。これは、ほとんどアクセスされず、ミリ秒単位での取得が必要な長期データ用に、極めて低コストのストレージを提供するアーカイブストレージクラスです。計算してみたところ、25 PB のデータを保存するには 2,788,555 枚の DVD ディスクが必要です。DVD の山が高さ 41.8 キロメートル (25.9 マイル) に達するところを想像してみてください! ぜひ全文をお読みください 。 Build On Generative AI – 生成 AI のあらゆるトピックを取り上げる人気の 毎週の Twitch 番組 のシーズン 3 が盛り上がりを見せています。 毎週月曜日、午前 9 時 (米国太平洋時間) にストリーミング配信されます。私の同僚の Tiffany と Darko が生成 AI のさまざまな側面について話し合い、ゲストスピーカーをお招きして、そのデモをご紹介します。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週 執筆しています。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – 冒頭でお伝えしたように、今年も AWS Summit のシーズンがやってきました。 最初のイベントは来週 パリ で開催されます (4 月 3 日)。その後は、 アムステルダム (4 月 9 日)、 シドニー (4 月 10～11 日)、 ロンドン (4 月 24 日)、 ベルリン (5 月 15～16 日)、 ソウル (5 月 16～17 日) と続きます。AWS Summit は、クラウドコンピューティングコミュニティが一堂に会して、つながり、コラボレーションし、AWS について学ぶための一連の無料のオンラインおよび対面イベントです。 AWS re:Inforce – ペンシルベニア州フィラデルフィアで開催される AWS re:Inforce (6 月 10～12 日) にぜひご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながり、AWS のお客様のセキュリティジャーニーについて学ぶことができます。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 3月25日週はここまでです。4月1日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

ソリューションアーキテクトの池田です。2024 年 3 月 12 日に「 AWS Compute Performance and Efficiency 」を目黒で開催しました。本セミナーでは、Amazon Elastic Compute Cloud (Amazon EC2) をコスト効率よく活用する方法について、海外のスペシャリストも交えて解説しました。インスタンスの選び方や AWS Graviton の活用、Kubernetes 環境での最適化、そして最新事例もご紹介をしました。 本記事では、発表内容の概要と発表資料を掲載しています。 セミナー概要 タイトル: 「 AWS Compute Performance and Efficiency 」 日時: 2024 年 3 月 12 日（火） セッション詳細 9:40 -10:10 「AWS における効率的なコンピュートサービス活用入門」 講師: Senior Specialist Solutions Architect, Compute 宮本大輔 概要: AWS で、Amazon EC2 を中心としたコンピュートサービスを効率的に活用するにはどうしたらよいでしょうか。本セッションでは、スポットインスタンスや AWS 独自の CPU である Graviton の活用を中心に、インスタンスサイズの最適化や Compute Optimizer 、Auto Scaling など、コンピュートサービスのコストを最適化するための幅広い戦略やツールについてご紹介します。 資料 10:10-10:30 「 Graviton Migration Story 」 講師: ASEAN Principal EC2 Specialist, Abhishek Singh 概要: Grab は配車や配送、決済など様々なサービスを東南アジアを中心に展開している企業です。本セッションでは、Grab がいかにして AWS Graviton に移行し、コスト最適化を成功させたかについてご紹介いたします。 本セッションの資料については非公開のため、参考情報を紹介いたします。 過去の関連動画 10:50-11:40 「 Deep Dive AWS Graviton パフォーマンス」 講師: Sr Mgr, Solutions Architecture, Arthur Petitpierre, Solutions Architect 石神 靖弘 概要: Graviton で最大の性能を引き出すにはどうしたらよいでしょうか。本セッションでは Graviton のアーキテクチャ詳細に加え、パフォーマンスを最大化し、コストを最小化するためのポイントについて紹介します。 資料 11:40-12:30 「 Karpenter をもちいた Kubernetes 環境でのコンテナ活用最適化」 講師: Sr. Specialist SA, EC2 Graviton, Wayne Toh, コンテナスペシャリストソリューションアーキテクト 落水 恭介 概要: Kubernetes におけるオープンソースの autoscaler である Karpenter を用いることで、x86 だけでなく、arm アーキテクチャである Graviton を組み合わせたマルチアーキテクチャ環境を構築し、最適化されたコンピュート環境を構築することが可能です。本セッションでは、Karpenter やマルチアーキテクチャコンテナイメージを作成するためのデプロイパイプラインについて、デモンストレーションを交えてご紹介します。 資料 まとめ 本セミナーでは、 Amazon EC2 をコスト効率よく活用するために、インスタンスの選び方、 AWS Gravitonの活用、Kubernetes 環境での最適化、そして最新事例のご紹介もしました。 セミナーにご参加いただいた皆様ありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき今後の AWS 活用の参考になりましたら幸いです。

こんにちは。カスタマーソリューションマネージャーの長倉です。 カスタマーソリューションマネージャーとしてお客様の CCoE をご支援する中で、クラウド人材、 IT 人材の育成に関するご相談を多くいただきます。 このブログでは、ビジネス成果を実現する人材育成計画を立案するためのポイントとして、人材育成計画のゴール設定、現状分析の重要性、実際のラーニングパス作成する上で活用できる AWS のプログラムを、一部お客様の事例とともにご紹介していきます。 人材育成のゴールの設定 人材育成において、ゴール設定はきわめて重要です。人材育成計画を立案する際は、知識やスキルの底上げだけを目的とするのではなく、育成した人材によってどのようなビジネス価値を実現したいのかを明確にすることが肝要です。例えば、「内製要員を中心とした体制で次期システムの AWS 上での構築と運用を実現し、ビジネスアジリティ向上を実現する体制を構築する」というゴールを設定し、ゴールを達成するための目標を「 AWS の運用業務をこなせる人材を現在の5名から15名に増やす」「次期システムの設計ができるアーキテクトを10名育成する」と数値を含めた指標として設定することで、具体的な計画の作成が容易となり、ゴールから逆算しての計画立案が可能となります。また、トレーニング完了後も、目的を達成したかの評価が容易となります。 ゴール設定に当たっては、教育のスポンサーとなる経営陣と十分に協議し、合意形成を図る事が重要です。人材育成計画を立案する部門/担当（例えば CCoE ）が、現状の課題を踏まえた人材育成のゴール、それによって実現するビジネス価値について経営陣との合意形成を図ってください。また、ゴールに設定したビジネス価値実現のために育成した人材の実業務やプロジェクトへのアサインが必要となる場合は、計画時点で育成した人材のアサイン計画を経営陣と合意してください。育成した人材を実務にアサインすることで、設定したビジネス価値の実現に初めてつなげる事ができます。 人材育成計画で設定したゴールの達成と学習する文化の醸成には、人材育成への投資やアサイン計画の後押しといった経営陣のバックアップが必要不可欠となります。 現状分析の実施 具体的な計画を立てる前に、人材育成の対象者に対する現状分析を実施し、ゴールとのギャップを特定する必要があります。人材育成対象者の所属部門や役割が異なる場合、習熟度も異なります。個別の状況を考慮した人材育成計画を立てるために現状分析は不可欠です。現状分析の実施にあたって、対象者が少ない場合は有識者によるヒアリングが効果的ですが、対象の人数が多くなるとヒアリングによる把握は困難になるため、アンケートを元にスキルマップを作成する方法が有効です。 AWS では、Web アンケート形式で対象者の AWS に関するスキルや学習状況を収集し、結果をレポートとして提供するツールとして LNA（Learning Needs Analysis） を提供しています。この情報をゴールの検討や組織内のクラウドに関するスキルギャップ特定に活用することができます。教育の定着状況を把握するために、定期的に年次で実施するといった活用も有用です。ご興味のある方は担当の AWS 営業にご相談ください。また、 LNA に関しては AWS ブログ「 LNAによるギャップ分析を活用した効率的なAWSスキル育成計画の立案 」で説明されていますのでぜひご参照ください。 ラーニングパスの設定 設定したゴールと現状分析の結果を元に、どういったギャップがあるかを確認し、それを埋めるラーニングパスを作成します。具体的には、ゴール達成のためにどういったロールの人材が必要になるのか、そのロールにはどういったスキルレベルが必要になるかをブレイクダウンします。ロールと求めるスキルレベルを具体化することで、現状とのギャップがより明確になります。具体化したギャップを埋めるために、どういった研修や学習コンテンツが必要かを検討し、それを組み合わせてラーニングパスを作成していきますが、ロールやスキルレベル別にラーニングパスを検討するのは骨が折れる作業です。 AWS ではロール別/ソリューション別/業種別のラーニングパスを AWS Ramp-Up Guides として公開しています。AWS Ramp-Up Guides では、 AWS Skill Builder のコンテンツや クラスルームトレーニング 、動画やドキュメントを組み合わせ、スキルを習得するためのラーニングパスがまとめられています。それ以外にも、 クラスルームトレーニングのデータシート ではロール別/ソリューション別のスキル習得に必要なクラスルームトレーニング が確認でき、 AWS Skill Builder でも Learning Plan として、ロール別のスキル習得に必要なオンラインコンテンツを活用したラーニングパスがまとめられています。これらの情報を参考にカスタマイズしていくことでラーニングパスを作成ください。 ラーニングパスの作成に加えて、効果的な学習を実施するためには、学習時間の確保/チームとして学びを進める体制/学習のためのコンテンツの用意/学習の途中経過の確認とフィードバック といった点に留意する必要があります。以下で留意いただきたいポイントをご紹介します。 業務時間中に学習時間を確保する 学習のための時間を自主的に確保するのは難しく、また、育成対象者のスキルレベルや学習意欲の違いにより、コンテンツのみを用意して実施を自主性に任せた形式とすると、進捗や習熟度にばらつきが出てしまいます。人材育成のゴールを達成するため、組織全体として人材育成を支援している姿勢を明確に示すためにも、人材育成計画をリードする部門が主体となり、経営層に対して業務時間内に一定の学習時間を確保するよう調整してください。 一緒に学んでいくチーム/コミュニティを作る IPAによる デジタル時代のスキル変革などに関する調査（2022年度）全体報告書 の中で、 IT 人材の学びを阻む障壁として、「共に学ぶ仲間や相談相手がいないために挫折してしまう」という課題が挙げられています。学習時に相談できる仲間がいる事によって、モチベーションを維持して継続的な学習の実施が期待できるだけでなく、学習した内容をアウトプットする機会を持つ事につながり、知識の定着・学習効率のアップが期待できます。また、一緒に学ぶチーム/コミュニティを組成し、その中に講師やメンターを設定することで、習熟度に応じた学び合いが実現できます。育成対象者に加えてメンターや講師をアサインするのが難しい場合もあると思いますが、あるお客様の事例で、学びの各テーマごとに人材育成の対象者どうしで講師を分担するという取り組みをされていました。自分が講師となった領域についてはみなさん積極的に学習されたそうです。その結果、入社歴2,3年の若いメンバーが特定のテーマに詳しくなり、ベテラン社員が若いメンバーの詳しいテーマについて、日常的に質問するようになったそうです。一緒に学んでいくチーム/コミュニティを作ることで、効率的で継続的な学習の実現に加えて、組織全体で人材育成に取り組む文化の醸成につなげる事が期待できますのでぜひご検討ください。 学習のためのコンテンツの用意 人によって最適な学習環境は異なります。効果的な人材育成のためには多様なコンテンツ、学習者の特徴に合わせた環境を用意する事が重要です。知識を体系的に学ぶ学び方を好む方もいれば、手を動かして学びたいという方もいるでしょう。学習者に合わせた様々な学習機会提供の重要性については「 日本におけるデジタル人材育成の現状と推進する上での勘所（後編） 」でも詳しく紹介しているので、ぜひご参照ください。 AWS では学習者の特徴にあわせることが可能な、多様なコンテンツ、トレーニングを用意しています。 クラスルームトレーニング では、短期集中で集合研修形式による AWS の学習が可能です。会社ごとで実施するプライベートトレーニングも提供しておりますので、ご興味のある方は担当の AWS 営業にご相談ください。また、 AWS Skill Builder ではオンラインのコンテンツを提供しており、学習者が自由な時間に好きなコンテンツを選んで学習が可能です。座学でのデジタルトレーニングに加えて、学習者が楽しんで学べる「 AWS Cloud Quest 」「 AWS Industry Quest 」といったゲームベースで学習ができるコンテンツや、演習用の AWS アカウントが払い出され、 AWS サービスに触れてみることができるハンズオンラボである AWS Builder Labs 、個人またはチーム単位で発生する様々な課題（セキュリティ、インフラ、 DevOps 、 ML 、サーバレスなど）を解決してスコアを競う実践的な演習の「 AWS Jam 」といったコンテンツがあります。「 AWS Jam 」は、チーム対抗で課題解決を目指す「 AWS Jam イベント」と、個人で解決を目指す「 AWS Jam Journey 」が用意されており、実際の AWS 環境で発生する障害や課題の解決に取り組んでいくコンテンツとなっています。詳細な説明や、解決策が提示されない中、個人・チームで試行錯誤しながら課題を解決していきます。課題には難易度ごとにスコアが設定されており、スコアを競いながら実際の業務で発生する障害対応や、各種課題の解決を手を動かしながら体験できる事で、実践力を強化するとともに、 AWS スキルの可視化が可能となります。同様のコンテンツとして、「AWS Jam」がクラスルームトレーニングの一環としても提供されております。ご興味のある方は クラスルームトレーニングのデータシート から全コースのデータシートをダウンロードすることでご確認いただけますので、ぜひご確認ください。 演習の実施が難しい場合は、メンターの十分なフォローの元、実務の実施を人材育成計画に組み込むのも効果的です。学習者に合った多様な学習コンテンツの提供とチームで学ぶ機会を適切に組み合わせていくことが、人材育成の成功につながります。 学習の途中経過の確認とフィードバック 人材育成の進捗と効果を測るために、第三者が客観的に評価できる基準を設定することが重要です。学習過程で定期的に理解度やスキル習得度を確認していき、基準を満たしていない場合は計画を見直し、目標達成に向けた改善を図ります。評価基準の例として、認定資格の取得や有識者によるスキルレベルのチェックが挙げられます。 AWSでは 認定資格/認定試験 を用意しています。認定資格の取得をラーニングパスに組み込む事で、人材育成の進捗を測れるようになるだけでなく、社内のクラウド知識とスキルの見える化を実現できます。また、認定資格/認定試験の内容は定期的にアップデートされるため、テクノロジーの進化へも対応が可能となるため、活用をご検討ください。 業務へのアサイン/経営陣との合意 ラーニングパスに基づいた学習の完了後、計画段階で合意した育成した人材の実案件やプロジェクトへのアサインを実施してください。人材育成が計画通りに進まなかったり、プロジェクトが予定通りに始まらないといったケースもあると思います。こういったケースで育成した人材のスキルが活かされない状況が発生しないように、学習の途中経過とあわせて、定期的に経営陣と人材育成の状況を報告・共有し、実案件へのアサイン計画についても状況に変化に対応できるよう調整を続けてください。人材育成をビジネス価値の向上につなげている事例として、 オムロンソフトウェア様のクラウド人財育成の取り組み があります。オムロンソフトウェア様では、トレーニングで獲得した知識をすぐに試せるように、事業部の壁を超えてクラウド案件に人財をアサインされています。スキルを高めるためのサポートは、独自の能力開発制度体系を用意し、職種別に必要な知識・スキルの習得を可能にする支援を行っており、特に重視されているのが、実践をとおして現場で使える技術を早期に身に付ける事と考えておられます。その他のお客様によるトレーニング実施の事例も、 お客様インタビュー – クラウド人材育成 でご確認いただけますのでぜひご参照ください。 学習する文化の醸成 継続して学習を実施していくため、学びによって得られた成果を業務評価につなげる事が大切です。評価につながる事により、各自の学習意欲が高まるという好循環につながります。ただし、その実現は簡単ではありません。人材育成計画検討部門（人事部や CCoE ）が中心となり、人材育成の計画段階から、経営陣と密に連携を取りながら、学習によって発揮できる成果とその評価方法を明確化することが重要です。 学習の成果が適正に評価されることで、自律的なスキルアップの文化が生まれます。組織全体で学びを推進するための仕組みづくり（例えば人材育成の成功体験を共有会やイントラネットを活用して社内で共有）ができれば、自律的にスキルアップしていく文化を組織として醸成できるようになります。 現場主導での学習 ここまで、人材育成のゴールを設定し、教育の成果としてビジネスバリューを発揮するために経営陣と合意して実際の業務にアサインすることの重要性をご紹介させていただきました。一方で、経営陣と合意して大規模に教育を推進するのは難しいが、現場の取り組みとして教育を推進していく必要がある、というケースもあると思います。こういったケースでも、人材育成のゴールを設定し、現状分析を行ったうえでラーニングパスを設定するというプロセスは同様に有効です。ゴールの設定や、現状分析、ラーニングパスの設定は社内の有識者や既にスキルを保有している方の歩んできた道のりを参考としたうえで検討してください。また、学習にあたっては、チーム単位で勉強会を開催し、先に紹介させていただいたように相互に講師を務めるといった取り組みを実施し、各人が積極的に参加できる仕組みをぜひご検討ください。 まとめ 人材育成計画を実現するうえでのゴール設定と学習していくための仕組みづくりの重要性についてご理解いただけたと思います。経営層を含む関係者とゴールを共有し、現状とのギャップを洗い出すことができれば、そのギャップを埋める手段としてのコンテンツは AWS から多数提供されていますので積極的に活用ください。 IT 技術、特にクラウドサービスの技術の進歩は早いため、最新の動向を把握し、より効果的にクラウドを活用してビジネス価値を最大化するには、計画した期間の学習が終わったら完了ではなく、継続して学び続ける必要があります。継続して学び続けるための仕組みづくりを人材育成計画検討部門が推進していってください。 参考リンク LNA(Learning Needs Analysis) LNAによるギャップ分析を活用した効率的なAWSスキル育成計画の立案 AWS Ramp-up Guides AWS Skill Builder クラスルームトレーニング クラスルームトレーニングのデータシート Learning Plan デジタル時代のスキル変革などに関する調査（2022年度）全体報告書 日本におけるデジタル人材育成の現状と推進する上での勘所（後編）AWSトレーニングデータシート AWS Cloud Quest AWS Industry Quest AWS Jam AWS 認定 オムロン ソフトウェア株式会社：グループのデジタル戦略実現に向けて AWS 人財を育成。半年間のトレーニングで 7 名が AWS 認定 5 冠を取得 お客様インタビュー – クラウド人材育成 今から始める CCoE、3 つの環境条件と 3 つの心構えとは CCoEブログ 著者 カスタマーソリューションマネジメント統括本部 カスタマーソリューションマネジャー 長倉隆浩

イントロダクション 今日のデジタル時代において、クラウドへの移行は「なぜやるのか」ではなく、「いつやるのか」というトピックになりました。インフラコストの削減以外にも、クラウドには柔軟性、機動性、信頼性の向上など多くの利点があります。しかし、クラウド移行には多くの利点がある一方で、進捗を妨げる予期せぬ費用が発生する可能性もあります。移行コストは、組織の規模、アプリケーションの複雑さ、移行プロセスの期間によって大きく異なります。さらに、現在の経済状況下では、限られたIT予算と効率性の必要性がクラウド移行の取り組みをさらに複雑にしています。 このブログでは、大規模な企業のクラウド移行におけるコスト削減戦略について考えていきます。 クラウド移行を開始する前に クラウド移行を成功させるためには、組織全体の利害関係者を結集させるビジネスドライバーを特定することが不可欠です。これには、移行プロジェクトの範囲、利点、およびタイムラインを概説したデータドリブンなビジネスケースを作成する必要があります。移行タイムラインをデータセンター退去などの具体的なビジネス成果と合わせることで、進捗状況を評価する具体的な基準が得られます。 AWS Migration Evaluator などのツールを活用して、コスト効率の良い移行のための説得力のあるビジネスケースを作成してください。 クラウド移行の複雑さに立ち向かうことは大変な作業ですが、適切なパートナーがそばにいれば、その旅路は容易で報われるものになります。AWSは、顧客の移行コストを軽減するために、 AWS Migration Acceleration Program (MAP)を提供しています。AWS MAPは、ツール、ベストプラクティス、 AWS パートナーネットワーク (APN)へのアクセス、および移行への投資を提供します。プログラムの早期段階からAWSに相談することで、クラウドマイグレーションジャーニーの各ステップを確認し、最適化されたアプローチを確保することができます。 MAPでは、移行に3ステップのアプローチ(図1参照)を推奨しています。Assess(評価)、Mobilize(準備)、Migrate & Modernaize (移行とモダナイズ）です。 図1 – AWS MAPの3ステップアプローチ 評価フェーズ このフェーズの目標は、クラウドで運用する組織の準備状況を評価することです。 現在のオンプレミスのIT資産（Assets）を理解することは、移行作業とクラウドコストを見積もるために不可欠です。移行を検討する際に組織が直面する一般的な問題の1つが「ダブルバブルコスト」であることを覚えておいてください。このバブルは、組織が現在のオンプレミスインフラの費用を負担しながら、新しくクラウド移行のコストが発生することで形成されます。 インフラストラクチャの組み合わせに基づいて適切なディスカバリーツールを選択するには、 AWS規範的ガイダンス を参照してください。ディスカバリーには、移行計画時に見落とされがちな、サードパーティのライセンスコストの評価を含める必要があります。AWS MAPには、ライセンスコストを理解するための実証済みのフレームワーク「 Optimization and Licensing Assessment (OLA)」が含まれており(図2参照)、クラウドネイティブで費用対効果の高い代替案を提供します。多くのAWSの顧客がOLAを活用することで、大幅なコスト削減を実現しています。この包括的な発見は、（１）コミットメント支出に基づいた割引価格を提供するAWSホスティングプラン(Savings plansとリザーブドインスタンス)の選択、(２)移行の加速と「ダブルバブルコスト」の削減のための移行計画に役立ちます。 古い機器の保守コストを削減することで、ダブルバブルコストを軽減する別の選択肢は、ReluTechなどのAWSパートナーが提供するIT売却のアプローチです。このアプローチには、ITメンテナンスの外部委託、高額なITリフレッシュの回避、オンプレミスアセットの購入とリースバックなどのコスト削減戦略が組み込まれており、顧客がクラウドへの移行を迅速かつ費用対効果の高い方法で行えるようサポートします。   図2 – ライセンス: 移行コスト削減の大きな要因 次のステップは、クラウドへの移行と運用の準備状況を評価することです。 AWS Migration Readiness Assessment (MRA) は、ビジネス、人材、ガバナンス、プラットフォーム、セキュリティ、運用の6つの AWS Cloud Adoption Framework (CAF) の柱に沿って組織を評価する無料のワークショップです。MRAの出力には、特定された課題に対処するための計画と、 AWS Learning Needs Analysis (LNA) などの追加ワークショップの推奨事項が含まれます。LNAはAWSスキルの準備状況を評価し、カスタマイズされた学習計画を推奨します。AWS Immersion Daysは、移行イニシアチブに参加する従業員にクラウドサービスのハンズオントレーニングを提供します。 詳細なポートフォリオの発見、ホスティング計画、およびMRAの出力により、プログラムはモビライズフェーズに移行する準備ができます。 モビライズフェーズ このフェーズの目標は、移行のためのベースラインとなるクラウド環境を構築し、再現可能な移行パターンを持ったアプリケーションの移行戦略を策定することです。 これには、（１）クロスファンクショナルチームであるCCoE(Cloud Center of Excellence)を設立し、クラウド移行におけるガバナンスとベストプラクティスを標準化する。（２）適切に設計された基礎となるクラウド環境(ランディングゾーン)を構築する。（３）評価フェーズで実施したMRAから特定されたギャップに対処する ことが含まれます。 組織はこの段階で、初期のワークロードの選択と移行の順序付け、移行戦略の曖昧さ、セキュリティとコンプライアンスのフレームワーク、有識者や専門家の有無など、潜在的な障害に気づく必要があります。これらの懸念に早期に対処することで、分析の停滞を防ぎ、移行の期限を守ることができます。 AWS Experience Based Acceleration (EBA)は、アジャイルでハンズオンのアプローチで、摩擦点と障害を解決することを目指しています。EBAでは、お客様の主要な意思決定者とAWSの専門家が集中的なワークショップ環境に集まり、「実際にやってみて証明する（do it to prove it approach）」アプローチで障害を解決するのを支援します。プラットフォームEBAと移行EBAを組み合わせると、モビライズフェーズの目標を達成するのに最適です。プラットフォームEBAでは適切に設計されたランディングゾーンを作成し、移行EBAではいくつかのアプリケーションを素早く移行してランディングゾーンをテストします。CCoEは引き続きガードレールを見直し、繰り返し可能なパターンを確立し、コスト最適化の管理を実装します。 社員の余力や専門知識が限られている場合は、AWS MAP パートナー資金調達プロセスを活用して、適切に設計されたランディングゾーンと繰り返し可能な移行アプローチの構築に関連するコストを、AWS Professional Services またはAWSパートナーを起用して補填することができます。 この段階で最も重要な活動の1つが移行のwaveの計画です。事前に移行のwaveを計画しておくと、チームが移行プロセスに慣れるにつれ、プロジェクトがスムーズに進むようになります。 適切に設計されたランディングゾーン、テスト済みの移行アプローチ、移行のwaveの計画ができれば、移行を加速させる時が来ます！ 移行フェーズ このフェーズの目標は、ダブルバブルコストを抑え、ビジネスケースで概説されているクラウド導入の利点を実現するために、ワークロードをクラウドに迅速に移行することです。 AWS Cloud Migration Factory は、ワークロードをAWSに大規模に移行するための移行ガバナンスと自動化レイヤーです。Maydenは、AWS Cloud Migration Factoryを活用して、6週間でAWSに300台のサーバーを移行しました。 AWS Application Migration Service や AWS Database Migration Service (DMS)などのAWSツールを活用して、ビジネス運用を中断することなく移行を迅速化し、コストを削減します。これらのツールは幅広いアプリケーションをサポートしており、追加の投資は必要ありません。また、段階的な価格設定オプションが用意されています。 最初は小さく始め、その後の各waveで移行の速度を上げていくことを計画します。最初のwaveでは、単一のアプリケーションまたは依存関係の少ないアプリケーションから始めます。複雑なアプリケーションは後続のwaveに加えることで、チームが学習し調整する時間を確保できます。さらに、チームはプロセスの改善を特定し実施して、後続のwaveの速度を上げることができます。 移行が進行中は、AWS Cost Optimization の専門家と定期的に打ち合わせを行い、コスト削減の機会を確認することが重要です。 また、この時点で次の大きなステップである「モダナイゼーション」を開始することも重要です。 移行とモダナイゼーションの両方が、継続的なコスト最適化と、クラウドの利点を完全に実現するためのキーです。(図3参照)。 図3 – マイグレーションとモダナイゼーションは、クラウドの恩恵を完全に実現するために重要 まとめ 企業のクラウド移行を主導することは難しい課題ですが、実証されているコスト削減戦略を活用することで、成功の可能性を最大化できます。 このブログで参照されているAWSクラウドサービスの詳細については、以下のリンクを参照してください。 ・ Cloud Migrations Services on AWS ・ AWS Migration Evaluator ・ AWS Migration Acceleration Planning (MAP) ・ AWS Migration Readiness Assessment (MRA) ・ AWS Optimization and Licensing Assessment (OLA) ・ AWS Learning Needs Analysis (LNA) ・ AWS Cloud Adoption Framework (CAF) ・ AWS Experience Based Acceleration (EBA) ・ AWS Application Migration Service ・ AWS Prescriptive Guidance Strategy and best practices for AWS large migrations 翻訳はソリューションアーキテクトの柳　嘉起が担当しました。原文は こちら です。 著者について Sai S Jeedigunta Sai S Jeedigunta Sai Jeediguntaは、AWSのシニアカスタマーソリューションマネージャーです。クラウド変革の取り組みを推進し、クラウドの恩恵を実現するために、経営陣や部門横断的なチームとパートナーシップを組むことに情熱を注いでいます。20年以上にわたり、大手企業向けのIT インフラストラクチャ関連の業務を主導してきました。 Joe Rader Joe Rader Joe RaderはAWSのシニアカスタマーソリューションマネージャーで、2020年から在職しています。Joeは、お客様がクラウドで成功を収められるよう支援し、長期的な成功に焦点を当て、常にコスト削減を意識しています。Joeには30年以上のIT経験があります。

強烈なインパクトを残したイベント Amazon Web Services (AWS) re:Invent 2023 を振り返ってみると、今年の会議がネバダ州ラスベガスで開催されたことは、自動車および製造業界にとっては特に革新と先進思考の中心であったことが明らかです。このダイジェストでは、イベント中に発表された豊富な情報と発表を詳細に確認しつつ、特に自動車産業を前進させることができるコンテンツについて整理しています。 AWS の自動車および製造業界ビジネスユニット (IBU) チームの洞察に富んだブレイクアウトセッションから、ワークショップやチョークトークで実証された実用的なアプリケーションに至るまで、 re:Invent 2023 で提供されたリソースは、自動車分野の進化する課題に対処するためのものです。このダイジェストは、業界が安全で持続可能でお客様中心のモビリティの未来に向かって加速するために、変革のナビゲートについて考え、今後お客様にとっての優れたモビリティ体験を保証します。 AWS では、独自のコラボレーションとイノベーションを通じて、持続可能で安全なモビリティ、製品、サービス、ソリューションの提供を加速し、お客様が変革の課題を解決するのを支援することに尽力しています。 AWS 内の自動車および製造業界ビジネスユニット (IBU) は、複数の大手 OEM 、 Tier1 、お客様、パートナーと協力し、 8 つの戦略的ワークロードに焦点を当てています。このブログ投稿では、 re:Invent で発表された自動車および製造業界に関連する発表を 8 つの戦略的ワークロードに分けて紹介しています。各セクションの中で re:Invent セッションで録画があった場合はそのリンクを記しています。 ソフトウェア定義車両 (SDV) ソフトウェア定義車両 (SDV) の分野は、車両のソフトウェアを再構築し新しいモビリティソリューションに不可欠なサービスへのアクセス、理解、使用、更新を改善するユースケースに触れています。 AWS の次世代クラウドファーストのインテリジェントなコードパイプラインに対するビジョンを概観する AUT102 ブレイクアウトセッションでは、 Traton と Volvo が製品化までの時間を短縮し、車両からクラウドへの連続性を維持することで開発コストを削減している方法について学ぶことができました。この連続性は、異なるコンテキストに車両の機能を分割し、開発ワークフロー内で Amazon Elastic Cloud Compute (Amazon EC2) インスタンス用の BlackBerry QNX AMI を利用しています。これらの革新により、チームはバグを早期に特定し、コード品質を向上させ、ハードウェア・イン・ザ・ループ (HIL) システムへの依存を減らすことができます。これは業界におけるシフトレフトアプローチへの証です。 チョークトークセッション AUT203 では、クラウドネイティブなツールと仮想化されたターゲットを使用した加速とスケールアップについて、車両へのデプロイ前にクラウドでコードを構築しテストするための、 SDV アーキテクチャ向けの最新クラウドネイティブ革新が紹介されました。ディスカッションの焦点は、仮想エンジニアリングワークベンチ、仮想電子制御ユニット、 CI/CD パイプラインであり、 Amazon CodeWhisperer を使用した生成型人工知能（生成 AI ）が生産性向上にどのように役立てられるかを示すユースケースについて深く掘り下げました。オリジナル機器メーカー (OEM) と様々な階層のサプライヤーは、 SDV の現在の採用状況を議論し、チョークトーク中に今後の取り組みを概説しました。 AUT301 ワークショップ 「 Automotive software development with Virtual Engineering Workbench (VEW) 」には、 100 人以上の開発者とアーキテクトが参加しました。このワークショップでは、 AWS 上で車載グレード評価機能を構築しテストする方法を実演しました。参加者が事前に設定された AUTOSAR ＆QNX ランタイム環境を作成し、 AWS Service Catalog に公開しました。 VEW セルフサービスポータルから、ユーザーは事前に設定された AUTOSAR ＆ QNX 環境を選択し、ログインしてデモ車両機能アプリケーションを開発しました。参加者はその後、仮想ターゲット（仮想 ECU ）上で車両アプリケーションを統合・実行し、 Amazon EC2 インスタンス上で機能を検証しテストしました。さらに、 VEW のエンドツーエンドのビジョンについて議論し、 OEM の特定の要件とワークフローに合わせて拡張・カスタマイズする方法を提供しました。 ライトニングトーク AUT103 「 Accelerate automotive cockpit development with Panasonic SkipGen on AWS 」では、 Panasonic SkipGen on AWS Graviton が自動車コックピットドメインコントローラーの開発を革命的に進化させる方法について深掘りしました。これにより SkipGen は業界に変革をもたらし、 AWS 上で完全な現代のコックピットソフトウェア開発、コンピューティングオフロードおよび 大規模なテストを可能にしました。 AWS は、クラウドネイティブな Software Developer Workbench がどのように拡張し、 SDV 時代の車両ソフトウェア開発を加速しているかについてのデモを示しました。自動車業界のパビリオンでの体験では、 BMW i7 車両の開発に関する情報を含む 8 つのデモを AWS が展示しました。 自動運転モビリティ 自動運転モビリティ分野では、 AWS は Amazon が長年にわたり自律システム、ロボティクス、機械学習において蓄積した経験を活用し、自動運転車の開発を加速していることについて触れました。 ブレイクアウトセッション AUT202 では、 BMW が Qualcomm と協力してクラウド上で次世代の高度自動運転開発プラットフォームを開発する方法についての事例が講演されました。 ブレイクアウトセッション AUT206 では、 Torc Robotics が AWS 上でデジタルテストプラットフォームを作成し、シミュレーションで何百万マイルものテストを実行し、レベル 4 の自動運転機能のテストカバレッジを最大化する方法について掘り下げられました。このセッションでは、 AWS の管理サービスを使用してプラットフォームを設定する方法について話されました。講演者は、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA), Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Simple Storage Service (Amazon S3) を使用してプラットフォームを設定する方法、直面した技術的な課題、学んだ教訓、および実装されたソリューションの結果としての利点について詳しく説明しました。 次世代トラッキングに関するブレイクアウトセッション PRO301 では、「 Iveco が AWS を使用して自動運転のための生成 AI を活用し、安全性と効率性の新たな高みを実現する方法」について紹介しました。このビジョンを実現するため、 Iveco は AWS 上で構築された生成 AI 技術を利用して、ドライバーと車両の関係を再定義しています。 AWS プロフェッショナルサービスの協力のもと、 Iveco はプライバシーに準拠したフリートデータにカスタマイズされた生成モデルをトレーニングし、ドライバー体験を向上させています。 チョークトークセッション AUT302 では、自動運転開発における生成 AI と 自然言語処理 (NLP) に基づくシーン検索に焦点を当てました。このディスカッションでは、自動運転機能の開発において直面する最も重要な課題について詳しく議論しました。ペタバイト規模のデータから、トレーニングやテストに関連するシーンを特定するために、生成 AI を使用する方法についてのインサイトが説明されました。またこのチョークトークでは、参加者は生成 AI がシーン選択を加速し、低頻度なイベントや意味的に類似したシーンを特定する方法を学びました。これらは、 ML トレーニング、テスト、検証などの下流タスクで使用されます。 ビルダーセッション AUT303 では、 ADDF ソリューションにおいて、モデルトレーニングのためのシナリオ内にオブジェクトを追加するために生成AIを使用しました。自動車メーカーは通常、自動運転や高度自動運転機能の開発のために車両テストフリートから何百ペタバイトものドライブデータを収集しますが、 ML エンジニアがコーナーケースに対してモデルをトレーニングするために必要になる正確なシナリオを記録していないことがあります。このビルダーセッションでは、生成 AI を使用して、停止標識などのイメージやオブジェクトを既存のシーンに追加する方法を実演しました。 デモブースでは、 お客様がクラウドで高度に自動化された運転機能を開発する際にサポートするための様々なツールを展示しました。他にもデータの取り込み、データの前処理、シーン生成、シーン検索、大規模な再シミュレーションのサポートに使用される AWS サービスが紹介されました。 接続モビリティ 接続モビリティ分野では、 AWS のお客様は、データの力を活用して、インテリジェントでパーソナライズされた機能や収益を生み出すモビリティサービスを構築しています。 AWS IoT FleetWise チームは、車両ビジョンシステムデータの収集をサポートすることを 発表 し、お客様がカメラ、 LiDAR 、 Radar などのビジョンサブシステムからメタデータ、オブジェクトリストと検出データ、画像やビデオを収集できるようにしました。 特に好評だったブレイクアウトセッション ALX201 は、車内ボイスエクスペリエンスをコンセプトから現実に変えることに焦点を当てました。参加者は、 BMW が独自の次世代 AI ボイスアシスタントを構築し、車内ボイスエクスペリエンスを新たな高みに引き上げる方法を学びました。インターネット接続に関係なく、埋め込み型ニューラルテキストトゥスピーチ SDK を展開することで、 BMW のクラウド環境を強化し、お客様に途切れのない自然なボイスエクスペリエンスを提供したことについて学びました。 別のブレイクアウトセッション IOT 204 では、 AWS IoT Connected Vehicle (CV) プラットフォームを使用した接続車両プラットフォームの革新と近代化について掘り下げました。このセッションでは、 AI による保証と修理通知、ライブビデオストリーミングと再生、 EV バッテリーの健康監視などの革新的なアプリケーションの可能性を強調しました。 American Honda Motor Company は、 AWS IoT Core への移行についてを共有し将来の革新に向けた計画を概説しました。 ANT 317 セッション「電気自動車からのリアルタイムアナリティクス構築」では、 Rivian が AWS 上での接続モビリティユースケースを共有しました。 Rivian の車両データプラットフォームは、デジタルコマース、保険、先進運転支援システム、車両の信頼性、スマート診断、充電、車両サービスなど、様々なドメインをサポートする基盤サービスとして機能しています。 ブレイクアウトセッション IOT 309 「 AWS IoT Core を使用してアプリケーションを革新する – MQTT 5 」では、 MQTT 5 の概要を説明した後、接続された車両のユースケースを探求しました。参加者は、 MQTT のパブリッシュおよびサブスクライブメッセージ機能を使用して、潜在的に断続的なネットワーク接続で通信する方法を学びました。またライブデモでは、共有サブスクリプションを使用してフリートとアプリケーションをスケールする方法を紹介しました。 デモエリアでは AWS Connected Mobility Solution 2.0 (CMS) を展示しており、大規模な接続モビリティインフラの開発、展開、管理がどのように容易になるかについて触れていました。 デジタルカスタマーエンゲージメント デジタルカスタマーエンゲージメント (DCE) の分野では、 AWS はお客様がパーソナライズされたマーケティングコンテンツ、没入型デジタル体験、リアルタイムデータ分析を通じてお客様エンゲージメントを増加させるのを支援しています。これには、広告、ファイナンス、アフターサービス、リピート購入体験など、所有のライフサイクル全体とお客様の旅にわたる様々な側面が含まれます。 AIM 206 ブレイクアウトセッション「 Generative AI で価値とビジネス成果を実現する」では、 AI と人間の心の融合、技術進歩によって駆動される急激なイノベーションについて発表しました。このセッションでは、 Ferrari が DXC Technology と AWS と共に生成 AI を探求している方法、生成 AI の導入における主な障害、メインストリームの導入に焦点を当てるべき分野、内部および外部の消費者の両方に対する価値ストリームマッピングを構築する方法を学びました。 チョークトークセッション AUT 204 「 Generative AI で未来へと進む」では、 AWS Generative AI Innovation Center の専門家によって提示されたように、 Amazon Bedrock と Amazon CodeWhisperer がプレセールスからポストセールスまでのお客様旅行全体のデジタル体験を強化するためにどのように採用されているかについて議論しました。 デモエリアでは、コールセンターから予測保守に至るまで生成 AI がデジタルお客様体験をどのように強化しているかが披露されました。 製造 製造 業界では、 AWS はショップフロアからのデータをキャプチャ、分析、視覚化することにより、製造業務と全体的な設備効率を最適化しています。 AIM 216 ブレイクアウトセッション「大規模な予測保守」では、 Amazon Monitron を用いた Koch Ag & Energy Solutions (KAES) のジャーニーが共有されました。予期しない機器の故障は産業施設にとってコストがかかる一方、保守を頻繁にスケジュールすることは資源の無駄遣いです。このセッションでは、 Koch AG から、彼らが Amazon Monitron を活用して産業用機械に予測保守を実装する方法について聞くことができました。 チョークトークセッション AIM240 「 Amazon Q で従業員に生成 AI の力を提供する」では、 Amazon Q が従業員に生成 AI の力への安全かつ迅速なアクセスを提供する方法を実演しました。 Amazon Q は自然言語を理解し、接続されたデータソースを使用して文脈に沿った回答を提供し、ドキュメントを要約し、コンテンツを生成し、企業アプリケーションやドキュメントリポジトリ全体でアクションを自動化することができます。これはショップフロアアプリケーションでの作業者ガイダンスの実装に特に有用です。 サプライチェーン AWS は、 re:Invent 2022 で AWS Supply Chain サービスを発表しました。このサービスは、機械学習 (ML) を活用したサプライチェーンアプリケーションによりリスクを軽減し、コストを削減します。お客様は、生産プロセス全体を追跡し追跡するために必要なエンドツーエンドのサプライチェーンの可視性を得ることができ、前例のない効率性を実現します。 AUT207-INT インダストリアルイノベーションセッションでは、自動車、航空宇宙、消費者電子機器を含むさまざまな産業分野のクラウドインダストリアル企業が、ビジネスを再創造し、運用を最適化し、市場投入までの時間を短縮し、新しい収益ストリームを生成するために、データとクラウドテクノロジーをどのように活用しているかが紹介されました。 Siemens 社は、 AWS を活用した Xcelerator インダストリアルソフトウェアポートフォリオや新しい工場自動化の提供を行い、 Industrial Metaverse 内で仮想工場を構築した方法について発表しました。 Honda は、日本と北米で AWS との協業について議論しつつ製品開発、サプライチェーン、製造全体での革新を加速する計画を語りました。 製品エンジニアリング AWS は、製品開発者やエンジニアが AWS 上の ハイパフォーマンスコンピューティング (HPC) 、モデルベースの設計、大規模並列シミュレーションを使用して複雑な問題を解決することを支援しています。 MFG 106 ブレイクアウトセッションでは、 トヨタモーターノースアメリカ と Autodesk の登壇者が、人工知能がどのように計算集約的なシミュレーションとモデリングを迅速化し、製品設計とデジタルエンジニアリングを加速させ、最終的に市場投入までの時間を短縮するかについて議論しました。 持続可能性と EV （電気自動車） 電気自動車 (EV) では、バッテリーが持続可能性とコストにおける最大の要因です。チョークトークセッション AUT 201 「バッテリーデジタルツインの力を解き放つ」では、物理的なバッテリーシステムの仮想表現であるバッテリーデジタルツインモデルが紹介されました。このセッションでは、 Mahindra と Our Next Energy がリアルタイムの車両バッテリーデータを機械学習アルゴリズムやデータ分析と組み合わせて、バッテリー性能の最適化、バッテリー寿命の延長、故障の検出、安全性の向上を図る方法を追求しました。 ワークショップ IOT 305 「 AWS IoT を使用した EV バッテリーの異常検出」では、電気自動車 (EV) バッテリーの異常を早期に検出するソリューションがデモンストレーションされ、参加者は車両のフリートの管理、プロビジョニング認証、車両モデリング、キャンペーン作成、データの取り込み、および洞察のためのダッシュボードの設定において実践的体験ができました。 デモエリアでは、 お客様が AWS 上で高度にスケーラブルで低遅延の OCPP EV 充電 CPO ソリューション を構築するのに AWS のサービスがどのように使用されているかを示しました。別のデモでは、 AWS がバッテリーサーキュラーエコノミー内のステークホルダー間の透明性と信頼性にどのように貢献しているかを示しました。さらに、 AWS はバッテリーデジタルツインを使用してバッテリー性能の最適化、バッテリー寿命の延長、 EV 効率の向上を実現する方法をデモンストレーションしました。 結論 AWS は、 re:Invent 2023 で 8 つの戦略的ワークロード領域における革新とお客様の成功事例を発表しました。 AWS は、中国リージョンで展開する OEM （オリジナル機器メーカー）にとってのプリファードクラウドプロバイダーとなり、対象として SAIC や BYD を含むといった発表がありました。 AWS for Automotive チームは、お客様と共に、またお客様のために革新を続けています。他の re:Invent 2023 の発表 に最新の情報については、 AWS for Automotive のページを探索するか、今すぐ担当の AWS チームにご 連絡 ください。 このブログは「 Recap of AWS re:Invent 2023 for the Automotive Industry 」と題された記事の翻訳となります。 翻訳は Solutions Architect Leader のショーン・セーヒーと Solutions Architect の佐藤高士が担当しました。

現代の車は単なる交通手段を超えて、つながったモノのインターネット (IoT) デバイスに進化しており、従来の車における所有と使用のあり方を再定義しています。 このビジョンの変化は、移動に関連する課題の解決方法を変えています。自動車産業は、スマート充電、バッテリーの状態監視、予知保全、フリート管理、循環型経 済などの課題に対処するために、人工知能 (AI) による「デジタルツイン」を活用しています。 デジタルツインとは、物理的なシステムを仮想的に表現することであり、データを動的に更新して物理システムの構造、状態、振る舞いを模擬します。 Amazon Web Services (AWS) は、デジタルツインの使用事例の幅広さを考慮して、顧客が使用事例を分類しデジタルツインを大規模に構築および展開するために必要なサービス、技術、データ、モデルを理解するのを支援するために、 4-level index を提案しています。 2022 年、Management- und IT-Beratung GmbH ( MHP ) は AWS との戦略的協業契約 を発表し、モビリティと製造業におけるクラウドの変革をさらに支援することになりました。MHP は、モビリティと製造環境における長年の専門知識をもつ AWS のアドバンスドティアサービスパートナー であり、クラウド戦略、アーキテクチャ、開発、移行、運用の課題に焦点を当てて協力しています。 この記事では、MHP が AWS と協力して電気自動車のレベル 4 デジタルツインを構築し展開する取り組みをご紹介します。具体的にはライブデータ、フリートの知識、AI を活用して電気自動車 (EV) のバッテリーを監視および分析する手段についてです。 フリートからドライバーの振る舞い（ドライバーツイン）とバッテリーの特性（バッテリーツイン）を学ぶことによってバッテリーの健康状態とパフォーマンスの管理を行う事例をご紹介します。また、業界における課題についても触れ、AWS 上で構築および展開された技術的なソリューションとリファレンスアーキテクチャについて深掘りします。 電気自動車のバッテリーに関する課題 電気自動車のバッテリーの管理と最適化は、バッテリー製造業者、自動車メーカー (OEM) 、および利用者の全てにとって重要です。 電気自動車のバッテリーに関して、最適な長期健康状態と残存価値に向けてどのように充電するかの最適解を導き出すのは難しいです。なぜなら、それぞれの電気自動車は異なる環境条件や使用パターンに晒されているからです。 結果として、各バッテリーそれぞれの具体的なサービス履歴に基づいて個別に運用性能を計算する必要があります。バッテリーの状態 (SoH) や充電状態 (SoC) などの特性をモニタリングし予測することで、航続距離の懸念や予知保全、残存価値、および再利用などの課題に対処できます。 現在、バッテリーのこれらのパラメータを計算するために開発された物理ベースのモデルには、2 つの主な問題があります。精度が低いことと、計算コストが高いということです。これらのモデルは、ドライバーの振る舞いなどの重要な要素を過度に単純化（または無視）するか、逆に詳細なバッテリー電気化学を数値的に解くことを試みて過度に複雑化してしまっていることが課題です。 物理ベースとデータドリブンのハイブリットアプローチを使用したデジタルツインによって、現実世界の要素の影響を考慮しながら、リアルタイムに実行可能な運用モデルを作成することができるようになります。 ソリューションのショーケース この記事で詳細に説明されているソリューションは、いくつかの課題に対処する必要があります。以下の要件を満たす必要があります。 大規模な車両台数に対してスケーラブルであること。 デジタルツインがより複雑になるにつれて、コンポーネントを追加できるようにモジュール化されていること。 個々の電気自動車のモデルを自動的に再キャリブレーションし、正確な予測を続けるためのスケーラブルなメカニズムを提供できること。 以下の 図 1 に示されているスクリーンショットは、4 台の車両フリートにおける展開ソリューションです。また以下のビデオも、MHP のデジタルツインのプラットフォームを理解するのに役立ちます。 バッテリーの健康状態は、電気自動車の残存価値の直接的な指標です。SoH の劣化は、使用パターンや環境条件、そしてバッテリーの管理に強く依存しています。 ショーケースでは、運転パターンに基づいて EV のバッテリーの SoH を予測することに焦点を当てています。私たちは、2 つのデジタルツインを使用して電気自動車をモデル化しています。1 つ目はドライバーをモデル化し、2 つ目はバッテリーをモデル化します。両方のデジタルツインには、人工的なドライバーの振る舞いデータおよびバッテリーの劣化データを使用した合成データが利用されます。 ドライバーのデジタルツインは、次のトリップがいつ発生するか、トリップの所要時間はどれくらいか、そして他のドライバーに関連する情報を、カーネル密度推定を用いた振る舞いモデルに基づくサンプリングベースのアプローチで予測します。バッテリーのデジタルツインは、ドライバーのデジタルツインからのデータを使用して、バッテリーの将来の健康状態を予測し、バッテリーの劣化をモデリングします。 図 1 – 4 台の車両フリートにおける展開ソリューションのスクリーンショット サービスアーキテクチャ ここに示されているアーキテクチャでは、 AWS IoT FleetWise を使用してシミュレートされた車両データを Amazon Timestream データベースに取り込みます。データは、カスタムビルトの MHP デジタルツインサービスによって受信され、予測メタデータは Amazon DynamoDB に保存され、予測結果は再び Amazon Timestream に格納されます。 予測結果は AWS IoT TwinMaker にフィードされた後に、 Amazon Managed Service for Grafana を介してフリートオペレーターが簡単に使用できるダッシュボードで健康状態や他の車両情報を監視できるようになります。 図 2 – 全体的なサービスのアーキテクチャ MHP のデジタルツインサービスは、レベル4のデジタルツインソリューションの中心的な役割を果たします。運用データをデジタルツインモデルに渡し、モデルを実行し、モデルエラーを計算し、必要に応じてデジタルツインモデルを再キャリブレーションします。 このサービスは、 aws-do-pm のオープンソースフレームワークの一部として開発されたモデルキャリブレーション技術を活用しています。図 3 は MHP のデジタルツインサービスのアーキテクチャを示しています。 MHP のデジタルツインサービスには、新しいコンポーネントが追加されるにつれて成長する、いわばモジュラー型デジタルツインを可能にする 2 つの主要な機能があります。 まずデジタルツインは、各々が独自のデジタルツインで表されるサブモジュールに分割されます。それぞれの子デジタルツインは相互作用することで、親ツインの振る舞いを合成することができます。例えば、バッテリーは、セルのデジタルツインを使用してモデリングすることができますし、異なるコンポーネントのデジタルツインを使用して車をモデリングすることができます。モデリングの深さは、ユースケースと利用可能なモデリング技術に依存します。 次に、図3に示されるように、各デジタルツインは3つのモジュールに分割されます。新しいデータが利用可能になる度にモデルを更新して予測を改善するために、これらのモジュールはレベル4のリビングデジタルツインの基本的な要件を反映しています。これを可能にするために、すべてのデジタルツインにはデータサービス、更新サービス、予測サービスの 3 つのモジュールが含まれています。 図 3 – デジタルツインサービスのアーキテクチャ データサービスは、モデルへのデータの取り込みを処理します。また、予測結果をデータベースに書き込み、モデルパラメータをシリアライズする責任も持ちます。 更新サービスは、初期トレーニングを実行したり、モデル全体を更新したり、予測エラーが大きくなった場合にモデルにベイジアンキャリブレーションを実行することができます。 このベイジアン更新は、非線形システムのパラメータ推定に使用される Unscented Kalman Filter (UKF) に基づいています。UKF は、ガイダンス、ナビゲーション、車両の制御からロボットの動作計画や軌跡最適化まで、さまざまなフィールドで適用される手法です。UKF は、予測モデリングのための aws-do-pm フレームワークでも中心的な役割を果たしています。 これらの 3 つのモジュールは、個々のタスクとして開発され、 AWS Fargate 上に展開されます。各サービスは、スケーラビリティを確保するために Application Load Balancer を使用します。AWS Fargate 上のそれぞれのツインサービスとモジュール間メッセージのやり取りは、リモートプロシージャコール (RPC) フレームワークである gRPC を介して処理されます。 新しい外部データは、 Amazon Simple Notification Service (SNS) トピックで収集され、 AWS Lambda 関数に受信されます。Lambda 関数は gRPC リクエストを使用して、新しいデータを対応するデジタルツインに転送します。 結論 この記事では、MHP が AWS と協力して電気自動車の課題、特に EV バッテリーのパフォーマンスに対応するためにモジュラー型でスケーラブルなデジタルツインソリューションの構築に取り組んでいることに触れました。 このソリューションは、AWS が提案する 4-level のインデックス に基づく レベル 4 のリビングデジタルツイン です。詳細については、 MHP の ホワイトペーパー や ウェビナー をご覧ください。 上記は自動車産業の例ですが、デジタルツインには無限の可能性があります。 MHP – AWS パートナースポットライト MHP は、 1996 年に Porche AG の子会社として設立された AWS のアドバンストティアサービスパートナーです。 MHP のアプローチは、自動車業界をはじめとするさまざまな業界に対するマネジメントおよび IT コンサルティング、および深いプロセスノウハウの提供を含んでおり、顧客が自社のビジネスの将来をより良いものにすることができるよう支援しています。 MHPにお問い合わせ | パートナー概要 本ブログは、 Using Digital Twins to Drive Electric Vehicle Battery Insights with MHP and AWS を翻訳したものです。 翻訳は Solutions Architect Leader ショーン・セーヒーと Solutions Architect 佐藤高士が担当しました。

Apache Flink は、ストリームおよびバッチ処理向けの、パワフルなプログラミングインターフェースを提供するオープンソースの分散処理エンジンです。ステートフルな処理やイベントタイムセマンティクスをサポートしています。Apache Flink は、複数のプログラミング言語、Java、Python、Scala、SQL、および異なる抽象化レベルの複数の API をサポートしています。これらを単一のアプリケーション内で組み合わせて使用することも可能です。 Amazon Managed Service for Apache Flink は、Apache Flink アプリケーションをフルマネージド、サーバーレスで実行可能なサービスです。このたび、 Apache Flink 1.18.1 がサポートされたことをお知らせします。 本投稿では、直近のメジャーリリース 1.16、1.17、1.18 で導入され、かつ Managed Service for Apache Flink でサポートされた、Apache Flink の興味深い機能の一部について説明していきます。 新しいコネクタ Apache Flink バージョン 1.18.1 で利用可能な新機能を詳しくみていく前に、新しいオープンソースコネクタについて説明させてください。 OpenSearch 専用の OpenSearch コネクタが利用可能になりました。本コネクタにより、Apache Flink アプリケーションは Elasticsearch の互換モードに頼らずに、直接 OpenSearch にデータを書き込むことができます。本コネクタは Amazon OpenSearch Service のプロビジョンドクラスター、および OpenSearch Service Serverless と互換性があります。 新しいコネクタは SQL と Table API をサポートし、Java と Python の両方で動作します。また、Java については DataStream API もサポートされています。本コネクタは Flink のチェックポインティングと同期して書き込みを行うため、追加設定なしで at-least-once を保証しています。一意の ID とアップサート方式を組み合わせることで、exactly-once を達成することも可能です。 デフォルトでは、コネクタは OpenSearch バージョン 1.x のクライアントライブラリを使用します。 適切な依存関係を追加することで 、バージョン 2.x に切り替えることができます。 Amazon DynamoDB Apache Flink アプリケーション開発者は、 Amazon DynamoDB にデータを書き込むための専用のコネクタを利用できるようになりました。 本コネクタは、AWS によって開発され、今や Apache Flink プロジェクトの不可欠なコンポーネントである Apache Flink AsyncSink をベースとしています。Apache Flink AsyncSink を活用することで、ノンブロッキングな書き込みリクエストとアダプティブバッチングにより、効率のよい出力コネクタを簡単に実装できます。 本コネクタは SQL と Table API (Java と Python)、および DataStream API (Java のみ) の両方をサポートします。デフォルトでは、スループットを最適化するためにバッチ書き込みを行います。SQL バージョンにおける注目すべき機能は、PARTITIONED BY 句のサポートです。1 つ以上のキーを指定することで、クライアント側の重複排除を実現でき、各バッチ書き込み時に最新のレコードのみを指定されたキーごとに送信することができます。DataStream API でも、各バッチ内で上書きするパーティションキーのリストを指定することで、同等の処理を実現できます。 このコネクタはシンクとしてのみ動作します。DynamoDB からのデータ読み取りには使用できません。DynamoDB のデータを検索するには、 Flink Async I/O API を使って参照処理を実装するか、SQL の場合はカスタムユーザー定義関数 (UDF) を実装する必要があります。 MongoDB 興味深い別のコネクタとして、 MongoDB 向けのものがあります。本コネクタはソースとシンクの両方で、 SQL と Table API と DataStream API が利用可能です。新しいコネクタは、公式な Apache Flink プロジェクトの一部であり、コミュニティによってサポートされています。本コネクタは、MongoDB 自身が提供していた以前のコネクタに置き換わるものです。以前のコネクタでは、Flink の Sink および Source API のみをサポートしていました。 他のデータストアコネクタと同様に、ソースコネクタはバッチモードで bounded source として、または参照用として使用できます。シンクコネクタはバッチモードとストリーミングの両方で利用可能で、upsert および append の両モードをサポートします。 本コネクタには多くの注目すべき機能がありますが、その中でも言及しておきたいのは、ソースにおける参照時のキャッシュ有効化と、シンクにおける追加設定なしでの at-least-once 保証の二点です。プライマリキーが定義されている場合、シンクは idempotent upserts により、exactly-once をサポートすることもできます。 コネクタのバージョニング 新機能ではありませんが、コネクタのバージョン管理が新しくなった点は、以前の Apache Flink アプリケーションを更新する際に考慮すべき重要な要素となります。 Apache Flink バージョン 1.17 以降、ほとんどのコネクタがメインの Apache Flink ディストリビューションから外部化され、独立したバージョン管理に従うようになりました。 依存関係を正しく含めるためには、 - の形式でアーティファクトバージョンを指定する必要があります。 例えば、本投稿の執筆時点で最新の Kafka コネクタは、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) とも連携する、バージョン 3.1.0 です。Apache Flink 1.18 で本コネクタを使用する場合は、次の依存関係を使用する必要があります。 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kafka</artifactId> <version>3.1.0-1.18</version> </dependency> Amazon Kinesis の新しいコネクタバージョンは 4.2.0 です。Apache Flink 1.18 における依存関係は以下のとおりです。 <dependency> <groupId>org.apache.flink</groupId> <artifactId>flink-connector-kinesis</artifactId> <version>4.2.0-1.18</version> </dependency> 次のセクションでは、Apache Flink 1.18 から利用可能となった強力な新機能の中で、Amazon Managed Service for Apache Flink でサポートされているものについて、さらに説明していきます。 SQL Apache Flink SQL において、オプティマイザに効果的なクエリプランを提案するために、 hints を結合クエリに付与可能となりました。特にストリーミングアプリケーションでは、外部システム (一般的にはデータベース) からクエリされたデータを使用して、ストリーミングデータを表すテーブルのエンリッチのために、 lookup joins が使用されます。バージョン 1.16 以降、lookup joins にいくつかの改善が導入され、結合の動作を調整してパフォーマンスを向上できるようになりました。 ルックアップキャッシュ は、最も頻繁に使用されるレコードをメモリにキャッシュすることで、データベースの負荷を軽減する強力な機能です。以前は、ルックアップキャッシュはいくつかのコネクタのみの専用機能でした。Apache Flink 1.16 以降、このオプションはルックアップをサポートしているすべてのコネクタで利用可能になりました ( FLIP-221 )。執筆時点では、 JDBC 、 Hive 、および HBase コネクタがルックアップキャッシュをサポートしています。ルックアップキャッシュには 3 つのモードがあります。メモリ上にすべて保持できる小さなデータセットの場合は FULL 、大きなデータセットの場合は最新のレコードのみをキャッシュする PARTIAL 、キャッシュを完全に無効にする NONE です。 PARTIAL キャッシュでは、バッファ行数と有効期限を設定可能です。 非同期ルックアップ はパフォーマンスを大幅に改善するための異なるアプローチです。非同期ルックアップは、Apache Flink SQL における DataStream API で利用可能な非同期 I/O と同様の機能を提供します。これにより、Apache Flink は、前のルックアップへの応答を受信するまでスレッドをブロックすることなく、データベースに新しい要求を送信できます。非同期 I/O と同様に、結果の順序付けを強制や、順不同な結果の許容、バッファ容量やタイムアウトの調整が可能です。 PARTIAL または NONE ルックアップキャッシュと組み合わせて、外部データベースのルックアップ失敗時の動作を設定する lookup retry strategy を設定することもできます。 これらの動作はすべて LOOKUP ヒントを使用して制御できます。以下に非同期ルックアップを使用したルックアップ結合を示します。 SELECT /*+ LOOKUP('table'='Customers', 'async'='true', 'output-mode'='allow_unordered') */ O.order_id, O.total, C.address FROM Orders AS O JOIN Customers FOR SYSTEM_TIME AS OF O.proc_time AS C ON O.customer_id = O.customer_id PyFlink このセクションでは、PyFlink の新機能と改善点について説明します。 Python 3.10 のサポート Apache Flink 1.18 では、PyFlink ユーザー向けのいくつかの改善が導入されました。 最も重要なのは、Python 3.10 がサポートされ、Python 3.6 のサポートが完全に削除されたことです ( FLINK-29421 )。 Managed Service for Apache Flink も、Python 3.10 ランタイムを使用して PyFlink アプリケーションを実行します。 機能差異の解消 プログラミング API の観点から見ると、PyFlink は、バージョンを重ねるごとに Java に近づいています。DataStream API では、サイド出力やブロードキャスト状態などの機能がサポートされるようになり、ウィンドウ API における不足も解消されました。また PyFlink は DataStream API から直接 Amazon Kinesis Data Streams などの新しいコネクタをサポートするようになりました。 スレッドモードの改善 PyFlink は非常に効率的です。PyFlink で Flink API オペレータを実行するオーバーヘッドは、Java や Scala に比べて最小限に抑えられています。これは、アプリケーションの言語に関係なく、ランタイムが実際にオペレータの実装を JVM で直接実行するためです。しかし、ユーザー定義関数の場合は少し異なります。 lambda x: x + 1 のような単純な Python コードでも、複雑な Pandas 関数でも、Python ランタイムで実行する必要があるためです。 デフォルトでは、Apache Flink は JVM の外部で、各 Task Manager 上で Python ランタイムを実行します。各レコードはシリアライズされ、プロセス間通信を介して Python ランタイムに渡され、デシリアライズされて処理されます。その結果は再度シリアライズされ、JVM に戻され、デシリアライズされます。これが PyFlink の PROCESS モード です。非常に安定していますが、オーバーヘッドが発生し、場合によってはパフォーマンスのボトルネックになる可能性があります。 Apache Flink バージョン 1.15 以降では、PyFlink 向けに THREAD モード もサポートしています。このモードでは、Python のユーザー定義関数が JVM 内で実行されるため、シリアライズ/デシリアライズおよび、プロセス間通信のオーバーヘッドが取り除かれます。THREAD モードには いくつかの制限 があります。たとえば、Pandas や UDAF (多数の入力レコードから 1 つの出力レコードを生成するユーザー定義集約関数) では使用できません。しかしながら、PyFlink アプリケーションのパフォーマンスを大幅に向上させることができます。 バージョン 1.16 では、THREAD モードのサポートが大幅に拡張され、Python DataStream API もカバーされるようになりました。 Managed Service for Apache Flink は THREAD モードをサポートしており、 PyFlink アプリケーションから直接有効化が可能です 。 Apple Silicon サポート Apple Silicon ベースのマシンで PyFlink アプリケーションの開発をする際に、PyFlink 1.15 においては、Apple Silicon における既知の Python 依存関係の問題に遭遇したかもしれません。これらの問題はついに解決されました ( FLINK-25188 )。これらの制限は、Apache Flink の Managed Service 上で実行される PyFlink アプリケーションには影響しませんでした。バージョン 1.16 より前は、M1、M2、M3 チップセットを使用するマシン上で PyFlink アプリケーションを開発する場合、PyFlink 1.15 以前をマシン上に直接インストールすることができないため、 回避策 を適用する必要がありました。 アンアラインドチェックポイントの改善 Apache Flink 1.15 ではすでに Incremental Checkpoint と Buffer Debloating がサポートされています。特にこれらの機能を組み合わせて使用することで、チェックポイントのパフォーマンスを改善し、バックプレッシャーが発生している場合でもチェックポインティングの期間をより予測可能とすることができます。これらの機能の詳細については、 Amazon Managed Streaming for Apache Flink アプリケーション向けのバッファデブロートとアンアラインドチェックポイント をご覧ください。 バージョン 1.16 および 1.17 では、安定性とパフォーマンスを向上させるためにいくつかの変更が導入されました。 データスキューの処理 Apache Flink は ウォーターマークによるイベントタイムのセマンティクスをサポートしています 。ウォーターマークは、通常はソースオペレーターからフローに挿入される特別なレコードで、イベントタイムウィンドウ集計などのオペレーターのイベントタイムの進行をマークします。一般的な手法は、最新の観測されたイベントタイムからウォーターマークを遅延させ、ある程度の範囲でイベントが順不同になることを許容することです。 しかし、ウォーターマークの使用には課題があります。アプリケーションが複数のソースを持つ場合、例えば Kafka トピックの複数のパーティションからイベントを受信する場合、ウォーターマークは各パーティションごとに独立して生成されます。内部的には、各オペレーターは常に、すべての入力パーティションで同じウォーターマークを待機します。これは実質的に最も遅いパーティションに合わせることを意味します。これがネックとなり、あるパーティションがデータを受信していない場合は、ウォーターマークが進まず、エンドツーエンドのレイテンシが増加します。このため、多くのストリーミングソースに オプションとしてアイドルタイムアウト が導入されています。設定したタイムアウト後は、レコードを受信していないパーティションを無視してウォーターマークの生成を行い、ウォーターマークを進めることができます。 1 つのソースがほかよりもイベントを大幅に早く受信している場合、逆の課題に直面する可能性があります。ウォーターマークはもっとも遅いパーティションに揃えられるため、ウィンドウ集約のためにウォーターマークを待つ必要が生じます。高速なソースからのレコードは、バッファリングされながら待たされることになります。オペレータ状態が制御できない程に、バッファリングされたデータが肥大化する恐れがあります。 より高速なソースの問題に対処するため、Apache Flink 1.17 以降では、ソース分割におけるウォーターマークアライメントを有効化できます ( FLINK-28853 )。デフォルトでは無効になっているこのメカニズムにより、特定のパーティションが他のパーティションと比べてウォーターマークを速く進めすぎないようになります。複数のソース (複数の入力トピックなど) を 1 つのアライメントグループ ID に割り当て、現在のウォーターマークからの最大ドリフト期間を指定することで、これらを束ねることができます。特定のパーティションがイベントを高速で受信する場合、ソースオペレーターはドリフトが指定されたしきい値を下回るまで、そのパーティションの消費を一時停止します。それぞれのソースごとに有効化できます。必要なのは、同じ ID を持つすべてのソースを結びつける整列グループ ID と、現在の最小ウォーターマークからの最大ドリフト時間を指定することです。これにより、あまりにも速く進んでいるソースサブタスクの消費が一時停止し、ドリフトが指定された閾値を下回るまで待機します。 以下のコードスニペットは、Kafka ソースから協会のない順序性のウォーターマークを出力するために、ソース分割のウォーターマークアラインメントを設定する方法を示しています。 KafkaSource kafkaSource = ... DataStream stream = env.fromSource( kafkaSource, WatermarkStrategy.forBoundedOutOfOrderness( Duration.ofSeconds(20)) .withWatermarkAlignment("alignment-group-1", Duration.ofSeconds(20), Duration.ofSeconds(1)), "Kafka source")); この機能は、 FLIP-217 に準拠した、ソース分割のウォーターマークアラインメントをサポートしているソースでのみ利用可能です。執筆時点では、主要なストリーミングソースコネクタのうち、Kafka ソースのみがこの機能をサポートしています。 Protobuf フォーマットの直接サポート 現在、SQL と Table API は、 Protobuf 形式 を直接サポートしています。この形式を利用するには、 .proto スキーマ定義ファイルから Protobuf の Java クラスを生成し、アプリケーションの依存関係に含める必要があります。 Protobuf フォーマットは SQL およびテーブル API でのみ利用可能で、Protobuf でシリアルライズされたデータをソースまたはシンクから読み書きする場合にのみ機能します。現在、Flink はステートを直接シリアルライザブルする Protobuf を直接サポートしておらず、Avro などのように schema evolution もサポートしていません。アプリケーション用に カスタムシリアライザー を登録する必要がありますが、オーバーヘッドを伴います。 Apache Flink をオープンソースのまま維持 Apache Flink は、サブタスク間のデータ送信を、内部的に Akka に依存してきました。 2022 年、Akka を開発している企業である Lightbend は、 今後の Akka バージョンのライセンスを Apache 2.0 からより制限的なライセンスに変更し、Apache Flink で使用されているバージョンである Akka 2.6 にはこれ以上のセキュリティアップデートや修正が提供されないこと を発表しました。 Akka は従来から非常に安定しており、頻繁な更新は必要ありませんでしたが、このライセンスの変更は Apache Flink プロジェクトにとってリスクとなりました。Apache Flink コミュニティの決定は、Akka 2.6 のフォークである Apache Pekko ( FLINK-32468 ) に置き換えることでした。このフォークは Apache 2.0 ライセンスを維持し、コミュニティによって必要な更新が加えられます。それまでの間、Apache Flink コミュニティは、Akka ならびに Pekko への依存関係を完全に削除するかどうかを検討しています。 ステート圧縮 Apache Flink は、すべてのチェックポイントとセーブポイントに対してオプションの圧縮 (デフォルト: オフ) を提供します。 Apache Flink は、スナップショット圧縮が有効になっている場合にオペレーターの状態を適切に復元できないという Flink 1.18.1 の バグ を特定しました。これにより、データが失われるか、チェックポイントから復元できなくなる可能性があります。これを解決するために、Managed Service for Apache Flink は、Apache Flink の将来のバージョンに含まれる 修正 をバックポートしました。 Managed Service for Apache Flink におけるインプレースバージョンアップグレード Apache Flink 1.15 以前のバージョンを使用して Managed Service for Apache Flink で現在アプリケーションを実行している場合、 AWS コマンドラインインターフェース (AWS CLI)、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) または AWS API を使用するツールのいずれかを使用して、ステートを失うことなくバージョン 1.18 にインプレースアップグレードが可能です。 UpdateApplication API アクションによって、既存の Managed Service for Apache Flink アプリケーションの Apache Flink ランタイムバージョンを更新できるようになりました。実行中のアプリケーションに直接 UpdateApplication を使用できます。 インプレースアップグレードを続行する前に、アプリケーションに含まれる依存関係を検証したうえで更新し、新しい Apache Flink バージョンと互換性があることを確認する必要があります。特に、Apache Flink ライブラリ、コネクタ、場合によっては Scala バージョンを更新する必要があります。 また、更新を続行する前に、更新されたアプリケーションをテストすることをお勧めします。リグレッションが発生していないことを確認するために、ターゲットの Apache Flink ランタイムバージョンを使用して、ローカルもしくは本番以外の環境でテストすることをお勧めします。 最後に、アプリケーションがステートフルである場合は、実行中のアプリケーションの状態の スナップショット を取得することをお勧めします。これにより、以前のアプリケーションバージョンにロールバック可能となります。 準備ができたら、 UpdateApplication API アクションまたは update-application AWS CLI コマンドを使用して、アプリケーションのランタイムバージョンを更新し、更新された依存関係を含む新しいアプリケーションアーティファクト、JAR、または zip ファイルをポイントできるようになります。 プロセスと API の詳細については、 Apache Flink のインプレース バージョン アップグレード を参照してください。ドキュメントには、ステップバイステップの手順とアップグレードプロセスを説明する動画が含まれています。 まとめ この投稿では、Apache Flink の Amazon マネージドサービスでサポートされている Apache Flink の新機能のいくつかを調べました。このリストは包括的なものではありません。 Apache Flink は、SQL およびテーブル API のオペレーターレベル TTL [FLIP-292] やタイムトラベル [FLIP-308] など、非常に有望な機能もいくつか導入しましたが、これらは API ではまだサポートされておらず、ユーザーが実際にアクセスできる状態にありません。そのため、本投稿で取り上げる対象から外しました。 Apache Flink 1.18 で利用できる興味深い新機能と新しいコネクタのいくつかと、Apache Flink のマネージド サービスが既存のアプリケーションのアップグレードにどのように役立つかを見てきました。 最近のリリースの詳細については、Apache Flink ブログとリリースノートをご覧ください。 Amazon Managed Service for Apache Flink のリリースノート Apache Flink 1.16 リリース記事 および リリースノート Apache Flink 1.17 リリース記事 および リリースノート Apache Flink 1.18 リリース記事 および リリースノート Apache Flink を初めて使用する場合は、 適切な API と言語を選択するガイド を参照し、 スタートガイド に従って Apache Flink のマネージド サービスの使用を開始することをお勧めします。 著者について Lorenzo Nicora は AWS でシニア ストリーミング ソリューション アーキテクトとして働いており、EMEA 全体の顧客をサポートしています。彼は 25 年以上にわたってクラウドネイティブでデータ集約型のシステムを構築しており、コンサルティング会社や FinTech 製品会社の両方を通じて金融業界で働いています。彼はオープンソース テクノロジーを幅広く活用し、Apache Flink などのいくつかのプロジェクトに貢献してきました。 Francisco Morillo は AWS のストリーミング ソリューション アーキテクトです。 Francisco は AWS の顧客と協力し、AWS のサービスを使用したリアルタイム分析アーキテクチャの設計を支援し、Amazon MSK および Amazon Managed Service for Apache Flink をサポートしています。 本記事は、 Amazon Managed Service for Apache Flink now supports Apache Flink version 1.18 を翻訳したものです。翻訳は Solutions Architect の榎本が担当しました。

本記事は、 Announcing data filtering for Amazon Aurora MySQL zero-ETL integration with Amazon Redshift を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 組織がよりデータドリブンになり、データを競争力向上の源として利用するようになると、売上の成長、コスト削減、ビジネスの最適化のために、データ分析を実行し主要なビジネス上の課題をより深く理解しようとします。 稼働中のサービスにまつわるデータで分析を実行するために、データベース、データウェアハウス、ETL(extract, transform, and load) パイプラインの組み合わせで構成されるソリューションを構築する場合があります。 ETL とは、データエンジニアが異なるソースからのデータを組み合わせるために使用するプロセスです。 ETL パイプラインの構築と保守の労力を軽減するために、AWS は Amazon Redshift との Amazon Aurora ゼロ ETL 統合 を AWS re:Invent 2022 で発表しました。この機能は現在、 Amazon Aurora MySQL 互換エディション 3.05.0 以降で一般提供されています。 AWS は本日、ゼロ ETL 統合のデータフィルタリングを発表しました。これにより、Amazon Aurora MySQL と Amazon Redshift 間のゼロ ETL 統合においてデータを選択して取り込むことができます。この機能により、分析ユースケースにおいて、データウェアハウスである Redshift にレプリケートする個々のデータベースとテーブルを選択できます。 この投稿では、この機能を使用できるユースケースの概要を示し、この機能を使用してニアリアルタイムの運用分析を開始する方法について段階的に説明します。 データフィルタリングの使用例 データフィルタリングを使用すると、Amazon Aurora MySQL から Amazon Redshift へレプリケートするデータベースとテーブルを選択できます。 複数のフィルターをゼロ ETL 統合に適用できるため、レプリケーションを特定のニーズに合わせて調整できます。 データフィルタリングは、 exclude フィルターまたは include フィルターのいずれかのルールを適用し、正規表現を使用して複数のデータベースとテーブルを照合できます。 このセクションでは、データフィルタリングの一般的なユースケースについて説明します。 PII データを含むテーブルをレプリケーションから除外することによるデータセキュリティの向上 サービス内で運用されているデータベースには、個人を特定できる情報(PII)が含まれていることがよくあります。これは性質上センシティブな情報であり、郵送先住所、顧客確認書類、クレジットカード情報などが含まれます。 厳格なセキュリティコンプライアンス規制のため、分析ユースケースに個人を特定できる情報(PII)を使用したくない場合があります。データフィルタリングを使用すると、PII データを含むデータベースやテーブルをフィルタリングして、Amazon Redshift へのレプリケーションから除外できます。これにより、分析ワークロードのデータセキュリティとコンプライアンスが向上します。 特定のユースケースに必要なテーブルをレプリケートすることで、ストレージコストを節約し、分析ワークロードを管理 サービス内で運用されているデータベースには、分析に役立たない様々なデータセットが含まれていることがよくあります。これには補助データ、特定のアプリケーションデータ、異なるアプリケーションのための同じデータセットの複数のコピーが含まれます。 さらに、Redshift を利用したデータウェアハウスはそれぞれの異なるユースケースごとに構築することが一般的です。そういったアーキテクチャでは、個々のエンドポイントで異なるデータセットを利用できる必要があります。 データフィルタリングを使用すると、ユースケースで必要なデータセットのみをレプリケートできます。 これにより、使用されていないデータを保存する必要性をなくすことでコストを節約できます。 既存のゼロ ETL 統合を変更して、必要に応じてより制限的なデータレプリケーションを適用することもできます。 既存の統合にデータフィルターを追加すると、Aurora は新しいフィルターを使用してレプリケートされるデータを完全に再評価します。 これにより、対象の Redshift エンドポイントから新しくフィルタリングされたデータが削除されます。 Aurora の Amazon Redshift とのゼロ ETL 統合のクォータの詳細については、 クォータ を参照してください。 小規模なデータレプリケーションから開始し、必要に応じてテーブルを段階的に追加する Amazon Redshift 上でより多くの分析ユースケースが開発されるにつれ、個々のゼロ ETL レプリケーションにさらにテーブルを追加したいと考えるかもしれません。 将来的に使用する可能性に備えて、Aurora データベースのすべてのテーブルを Amazon Redshift にレプリケートするのではなく、データフィルタリングを使用することで、Aurora データベースの一部のテーブルのサブセットから小規模に開始し、必要に応じてフィルターにさらにテーブルを増分的に追加できます。 ゼロ ETL 統合のデータフィルターが更新されレプリケーションの対象にテーブルが追加された際には、Aurora はフィルター全体を評価しなおします。これにより、以前にレプリケートされたテーブルを使用しているワークロードは、新しいテーブルを追加しても影響を受けることはありません。 レプリケーションプロセスの負荷分散によるワークロードごとのパフォーマンスを向上する 大規模なトランザクションデータベースの場合、レプリケーションとその下流の処理を複数の Redshift クラスタにロードバランスする必要があるかもしれません。これにより、個々の Redshift エンドポイントのコンピューティング要件を削減し、ワークロードを複数のエンドポイントに分割することができます。複数の Redshift エンドポイントにわたってワークロードをロードバランスすることで、エンドポイントが個々のワークロードに適切にサイズ設定されたデータメッシュアーキテクチャを効果的に作成できます。これによりパフォーマンスが向上し、全体的なコストが低減できます。 データフィルタリングを使用すると、異なるデータベースとテーブルを個別の Redshift エンドポイントにレプリケートできます。 次の図は、ゼロ ETL 統合でデータフィルターを使用して、Aurora の異なるデータベースを Redshift エンドポイントに分割する方法を示しています。 使用例 TICKIT データベースを考えてみましょう。TICKIT サンプルデータベースには、ユーザーが各種イベントのチケットを売買する架空の会社のデータが含まれています。この会社のビジネスアナリストは、Aurora MySQL データベースに保存されているデータを使用して、さまざまなメトリックを生成したいと考えており、この分析をニアリアルタイムで実行したいと考えています。そこで、この会社はゼロ ETL がソリューションになりうるのではないかと考えました。 会社のアナリストが必要なデータセットを調査している間に、users テーブルには顧客ユーザー情報に関する個人情報が含まれているが、その情報は分析要件にとって有用ではないことがわかりました。 したがって、users テーブルを除くすべてのデータをレプリケートしたいと考えており、ゼロ ETL のデータフィルタリングを使用して　それを実現したいと考えています。 セットアップ まず、 Amazon Aurora と Amazon Redshift のゼロ ETL 統合を使用したニアリアルタイム運用分析のためのスタートガイド に従って、新しい Aurora MySQL データベース、 Amazon Redshift Serverless エンドポイント、ゼロ ETL 統合を作成します。 次に Redshift クエリエディター v2 を開き、users テーブルからのデータが正常にレプリケートされていることを確認するために、次のクエリを実行します。 select * from aurora_zeroetl.demodb.users ; データフィルター データフィルターは、 Amazon Relational Database Service (Amazon RDS) のゼロ ETL 統合に直接適用されます。 単一の統合に対して複数のフィルターを定義でき、各フィルターは Include フィルター型または Exclude フィルター型のいずれかとして定義されます。 データフィルターは、既存および将来のデータベーステーブルにパターンを適用して、適用するフィルターを決定します。 データフィルタの適用 ゼロ ETL 統合から users テーブルを削除するフィルターを適用するには、次のステップを行います。 Amazon RDS コンソールのナビゲーションペインで、 ゼロ ETL 統合 を選択します。 フィルターを追加するゼロ ETL 統合を選択します。 デフォルトのフィルターは、 include:*.* というフィルターで表され、すべてのデータベースとテーブルを含めます。 変更 を選択します。 ソース セクションで フィルターを追加する を選択します。 フィルタータイプを選択する で 除外する を選択します。 フィルター式 に demodb.users と入力します。 フィルター式の順序が重要になります。フィルターは左から右、上から下に評価され、後続のフィルターが前のフィルターをオーバーライドします。この例では、Aurora はすべてのテーブルを含める必要があると評価し(フィルター 1)、次に demodb.users テーブルを除外する必要があると評価します(フィルター 2)。exclusion フィルターは inclusion フィルターの後にあるため、inclusion フィルターをオーバーライドします。 続行 を選択します。 変更内容をレビューし、フィルターの並び順が正しいことを確認したら、　 変更内容を保存 を選択します。 統合が追加され、変更が適用されるまで 変更中 の状態になります。これには最大 30 分かかる場合があります。変更の適用が完了したかどうかを確認するには、ゼロ ETL 統合を選択し、そのステータスを確認してください。 アクティブ と表示されていれば、変更が適用されたことを意味します。 変更の確認 ゼロ ETL 統合が更新されたことを確認するには、次のステップを完了してください: Redshift クエリエディター v2 で、Redshift クラスターに接続します。 作成した aurora-zeroetl データベースを右クリックで選択し、 更新 を選択します。 demodb と Tables を展開します。 users テーブルはレプリケーションから削除されたため、もう利用することができなくなっています。 他のすべてのテーブルは引き続き利用可能です。 以前と同じ SELECT ステートメントを実行すると、オブジェクトがデータベースに存在しないというエラーが発生します: select * from aurora_zeroetl.demodb.users ; AWS CLI を使用したデータフィルタの適用 会社のビジネスアナリストは、Aurora MySQL データベースにさらに多くのデータベースが追加されていることを理解し、 demodb データベースのみが Redshift クラスタにレプリケートされるようにしたいと考えています。 このため、 AWS Command Line Interface (AWS CLI) を使用して、ゼロ ETL 統合のフィルタを更新したいと考えています。 AWS CLI を使用したゼロ ETL 統合にデータフィルターを追加するには、 modify-integration コマンドを呼び出すことができます。 統合識別子に加えて、 include フィルターと exclude フィルターをコンマ区切りでならべたリストを使用して、 --data-filter パラメータを指定します。 ゼロ ETL 統合のフィルターを変更するには、次のステップを完了します: AWS CLI がインストールされたターミナルを開きます。 利用可能なすべての統合を表示して確認するには、次のコマンドを入力します。 aws rds describe-integrations 更新したい統合を見つけ、統合識別子をコピーします。 統合識別子は、統合の ARN の末尾にある英数字の文字列です。 前のステップでコピーした識別子で <integration identifier> を更新し、次のコマンドを実行します: aws rds modify-integration --integration-identifier " <integration identifier> " --data-filter 'exclude: *.*, include: demodb.*, exclude: demodb.users' Aurora がこのフィルターを評価するとき、デフォルトですべてを除外し、 demodb データベースのみを含めますが、 demodb.users テーブルは除外します。 データフィルターは、データベースとテーブルに対して正規表現を利用したフィルタリングが可能です。 たとえば、 user で始まるテーブルをすべてフィルタリングしたい場合は、次のように実行できます: aws rds modify-integration --integration-identifier " " --data-filter 'exclude: *.*, include: demodb.*, exclude *./^user/' 前のフィルターの変更と同様に、変更が適用されるまで統合が追加され 変更中 の状態になります。これには最大 30 分かかる場合があります。 アクティブ と表示されたら、変更が適用されたことを意味します。 クリーンアップ ゼロ ETL 統合に追加されたフィルターを削除するには、次のステップを完了してください: Amazon RDS コンソールのナビゲーションペインで、 ゼロ ETL 統合 を選択します。 該当のゼロ ETL 統合を選択します。 変更 を選択します。 削除したいフィルターのとなりにある 削除 を選択します。 exclusion フィルターを inclusion フィルターに変更することもできます。 あるいは、AWS CLI を使用して次のコマンドを実行することもできます: aws rds modify-integration --integration-identifier " " --data-filter 'include: *.*' 「 続行 」を選択します。 「 変更を保存 」を選択します。 データフィルターの変更を適用するには、最大 30 分かかります。 データフィルターを削除すると、Aurora は、削除されたフィルターが存在しなかったかのように、残りのフィルターを再評価します。 以前はフィルタリング基準に一致しなかったが、変更によって一致するようになったデータは、ターゲットの Redshift データウェアハウスにレプリケートされます。 結論 この投稿では、Amazon Aurora MySQL から Amazon Redshift へのゼロ ETL 統合にデータフィルタリングを設定する方法を示しました。これにより、必要なデータのみをレプリケートしながら、トランザクションデータや運用データでニアリアルタイムな分析を行うことができます。 データフィルタリングを使用すると、ワークロードを個別の Redshift エンドポイントに分割したり、プライベートまたは機密データセットのレプリケーションを制限したり、必要なデータセットのみをレプリケートすることでワークロードのパフォーマンスを向上させたりすることができます。 Amazon Redshift との Aurora ゼロ ETL 統合の詳細については、 Amazon Redshift との Aurora ゼロ ETL 統合の利用 および ゼロ ETL 統合の利用 を参照してください。 著者について Jyoti Aggarwal は、AWS ゼロ ETL の製品管理リードです。彼女は、パフォーマンス、顧客エクスペリエンス、セキュリティに関する取り組みの推進など、製品およびビジネス戦略を主導しています。彼女は、クラウド コンピューティング、データ パイプライン、分析、人工知能 (AI)、およびデータベース、データ ウェアハウス、データ レイクなどのデータ サービスに関する専門知識をもたらします。 Sean Beath は、アマゾン ウェブ サービスのAnalytics Solutions Architect です。彼は、AWS のサービスを使用したデータ プラットフォームの最新化の配信ライフサイクル全体の経験があり、顧客と協力して AWS での分析価値の向上を支援しています。 Gokul Soundararajan AWS の主任エンジニアであり、トロント大学で博士号を取得し、ストレージ、データベース、分析の分野で働いてきました。

このブログ記事は Senior Solutions Architect の Dmitriy Novikov と Senior Edge Specialist Solutions Architect の Harith Gaddamanugu によって書かれました。 ネットワークセキュリティオペレーターの多くの方にとって、アプリケーションの稼働時間を守ることは、ネットワークトラフィックのベースラインを設定し、不審な送信者を調査し、リスクを軽減するための最善の方法を決定するという、時間のかかる課題となっています。このプロセスを簡素化し、常にネットワークセキュリティの状態を把握することが、セキュリティオペレーションスタッフを増員することなくアプリケーションを拡張しようとしている IT 組織の目標となっています。この課題に対処するため AWS WAF でアプリケーションを保護している場合に、セキュリティ状況に関する十分な情報に基づいて意思決定ができるようにするための AWS WAF traffic overview ダッシュボード を導入しました。 この記事では新しいダッシュボードを紹介し、AWS WAF を使用してアプリケーションの全体的なセキュリティを把握して、ダッシュボードから得られる洞察に基づいて意思決定できるようにするための、いくつかのユースケースを詳しく説明します。 Traffic overview ダッシュボードの紹介 AWS WAF の Traffic overview ダッシュボードには、セキュリティ関連のメトリクスが表示されるため、分散型サービス拒否 (DDoS) イベント発生時に レートベースのルール を追加するなど、数クリックでセキュリティリスクを特定して対処できます。これらのダッシュボードには、AWS WAF がアプリケーションの Web トラフィックを評価する際に収集する Amazon CloudWatch メトリクスをほぼリアルタイムで表示することができます。 これらのダッシュボードはデフォルトで利用できるため、追加の設定は必要ありません。AWS WAF で監視する各 Web ACL について合計リクエスト数、ブロックされたリクエスト数、許可されたリクエスト数、ボットと非ボットのリクエストの割合、ボットカテゴリ、CAPTCHA 解決率、上位 10 件のマッチしたルールなどのメトリクスが表示されます。 総リクエスト数、ブロックされたリクエスト数、ブロックされた一般的な攻撃などのデフォルトメトリクスにアクセスすることも、最も重要なメトリクスと視覚化を選んでダッシュボードをカスタマイズすることもできます。 これらのダッシュボードは可視性を高め、以下のような質問に答えることができます: AWS WAF で検査されたトラフィックの何%がブロックされていますか? ブロックされているトラフィックの主な発信国はどこですか? AWS WAF が検知して保護している攻撃は何ですか? 今週のトラフィックパターンは先週と比べてどうですか? ダッシュボードには CloudWatch との間でネイティブかつシームレスな統合が用意されており、ダッシュボードと CloudWatch を行き来しながら、より詳細なメトリクスを CloudWatch で確認することができます。また、既存の CloudWatch ウィジェットやメトリクスを Traffic overview ダッシュボードに追加し、実績のある可視性をダッシュボードに取り込むこともできます。 Traffic overview ダッシュボードの導入とともに、AWS WAF の Sampled requests は Web ACL 内のスタンドアロンタブになりました。このタブでは、AWS WAF が検査した Web リクエストのルールマッチのグラフを確認できます。さらに、リクエストサンプリングを有効にしている場合、AWS WAF が検査した Web リクエストのサンプルをテーブルビューで確認できます。 リクエストのサンプルには Web ACL のルールの条件に一致した最大 100 件のリクエストと、ルールに一致せず Web ACL のデフォルトアクションが適用されたリクエスト 100 件が含まれます。サンプル内のリクエストは、過去 3 時間以内にコンテンツへのリクエストを受信した保護リソースからのものです。 以下の図は Traffic overview ダッシュボードのレイアウトの一例を示しています。ここでは攻撃タイプ、クライアントデバイスタイプ、国別などのアクションの取れる洞察が、表示されるカテゴリごとに検査されたリクエストが分類されています。この情報と期待するトラフィックプロファイルを比較することで、さらに調査する必要があるか、すぐにトラフィックをブロックするかを判断できます。図1 の例では、Web アプリケーションがフランスからのトラフィックを想定しておらず、デスクトップ専用のアプリケーションである場合、モバイルデバイスからのフランス発信のリクエストをブロックすることを検討するかもしれません。 図1: 複数のカテゴリを示すセクションがあるダッシュボード ユースケース1: ダッシュボードを使用してトラフィックパターンを分析する Webトラフィックの可視化に加えて、新しいダッシュボードを使って潜在的な脅威や問題を示すパターンを分析できます。ダッシュボードのグラフやメトリクスを確認することで、さらなる調査が必要な異常なトラフィックの増加や減少を発見できます。 トップレベルの Traffic overview では、ハイレベルのトラフィックとパターンが表示されます。そこから、特定のルールやルールグループの傾向とメトリクスを確認するために Web ACL メトリクスに掘り下げることができます。ダッシュボードには許可されたリクエスト、ブロックされたリクエストなどのメトリクスが表示されます。 予想されるトラフィックパターンからの逸脱に関する通知やアラートは、イベントを探る合図となります。探索中、ダッシュボードを使ってイベントを孤立させるのではなく、より広い文脈を理解できます。これにより、セキュリティイベントや設定ミスのルールを示す異常なトレンドを検出するのが簡単になります。例えば、通常は特定の国から 1 分あたり 2,000 件のリクエストがあるサービスで、突如 1 万件のリクエストがあった場合は調査する必要があります。ダッシュボードを使用すると、さまざまな側面からトラフィックを確認できます。リクエストの増加だけでは脅威の明確な兆候とはならないかもしれませんが、予期せぬデバイスタイプなどの別の兆候があれば、フォローアップ対応を取る十分な理由となります。 次の図は Web ACL のルールによるアクションと、最も一致したルールを示しています。 図2: ウェブリクエストの多次元的なダッシュボード このダッシュボードでは、時間経過に伴うブロックされたリクエストとアクセス許可されたリクエストのトップも表示されます。ブロックされたリクエストの異常なスパイクが、特定の IP アドレス、国、またはユーザーエージェントからのトラフィックのスパイクに対応しているかどうかを確認してください。これは、悪意のある活動またはボットトラフィックの試みを示している可能性があります。 次の図は、特定のベクターが保護されたウェブアプリケーションに対して使用されていることを示す、ルールへのマッチ件数が不相応に多いことを示しています。 図3: 最上位のルールは、攻撃のベクトルを示している可能性があります 同様に上位の許可されたリクエストを確認してください。特定のURLへのトラフィックに急増が見られた場合は、アプリケーションが適切に機能しているかどうかを調査する必要があります。 トラフィックを分析した後の次のステップ トラフィックパターンを分析した後、検討すべき次のステップは以下の通りです。 調査結果に基づいて、正常または悪意のあるトラフィックとより一致するように AWS WAF ルールを調整します。 正規表現 や条件を調整することで、False Positive（偽陽性）や False Negative（偽陰性）を減らすことができるかもしれません。正常なトラフィックをブロックしているルールを調整します AWS WAF のロギング を設定し、専用のセキュリティ情報およびイベント管理 （SIEM）ソリューションがある場合は、異常に対する自動アラートを可能にするためにロギングを統合します 既知の悪意のある IP を自動的にブロックするように AWS WAF を設定します。特定された脅威の発信元に基づいて IP ブロックリストを維持できます。さらに Amazon 脅威リサーチチームが定期的に更新する、 Amazon IP レピュテーションリスト のマネージドルールグループを使用できます 特定のページへのトラフィックの急増が見られた場合は、不審なパターンの原因がアプリケーションの問題でないかをチェックします トラフィックフローで新しい攻撃パターンを発見した場合は、それをブロックする新しいルールを追加します。次に、メトリクスを確認して、新しいルールの影響を確認します DDoS 攻撃やその他の悪意のあるトラフィックのスパイクのために送信元 IP を監視します。レートベースのルールを使って、これらのスパイクを緩和するのに役立ちます トラフィックフラッディングが発生した場合は、DDoS 保護付きの CloudFront を使用して、追加の保護レイヤを実装します 新しいダッシュボードにより、アプリケーションに到達するトラフィックについて貴重な洞察が得られ、トラフィック分析における推測の必要がなくなります。得られた洞察を活用して AWS WAF の保護を細かく調整し、可用性やデータが影響を受ける前に脅威をブロックできます。潜在的な脅威を検出し、保護を最適化するための情報に基づいた決定を行うために、データを定期的に分析してください。 例えば、ダッシュボードで過去のトラフィックパターンと比べて、トラフィックが発生すると予測していない国から不審な急増があった場合、Web ACL に 地理的一致ルールステートメント を作成して、そのトラフィックが Web アプリケーションに到達するのを防ぐことができます。 このダッシュボードは、洞察を得るための優れたツールであり、AWS WAFマネージドルールがトラフィックを保護する方法を理解するのに役立ちます。 ユースケース2: オンボーディング中のボットトラフィックを理解し、Bot Control ルールグループを細かく調整する AWS WAF Bot Control を使用するとスクレイパー、スキャナー、クローラー、ステータスモニター、検索エンジンなどのボットを監視、ブロック、またはレート制限できます。ルールグループのターゲットインスペクションレベルを使用すると、自己識別しないボットにチャレンジできるため、悪意のあるボットがWebサイトに対して操作することが困難になり、コストがかかります。 Traffic overview ダッシュボードの Bot Control タブでは、現在のトラフィックの内、ボットからのものがどの程度か (Bot Control を有効にしていない場合はリクエストのサンプリング、有効にしている場合は実時間の CloudWatch メトリクスに基づいて) 確認できます。 オンボーディングフェーズではこのダッシュボードを使用してトラフィックを監視し、さまざまなタイプのボットからのトラフィックがどの程度あるかを理解します。これをボット管理のカスタマイズの出発点として利用できます。例えば Bot Control ルールグループをカウントモードで有効にし、望ましいトラフィックが誤ってラベル付けされていないか確認できます。次に、「 AWS WAF Bot Control の例: 特定のブロックされたボットを許可する 」で説明されているように、ルールの例外を追加できます。 次の図はボットによって生成、検出されたリクエストのさまざまな次元を視覚化するウィジェットのコレクションを示しています。カテゴリとボリュームを理解することでさらにログを詳しく調査すべきか、望ましくないトラフィックはそのカテゴリをブロックするか情報に基づいた決定を下すことができます。 図4: ダッシュボード上のボット関連メトリックのコレクション 開始した後は同じダッシュボードを使って、ボットトラフィックを監視し、自己識別しない高度なボットに対するターゲット検出を追加するかどうかを評価できます。ターゲット保護ではブラウザ問い合わせ、フィンガープリンティング、行動のヒューリスティクスなどの検出手法を使用して、悪意のあるボットトラフィックを特定します。AWS WAF トークンはこれらの高度な保護に不可欠です。 AWS WAF はサイレントチャレンジや CAPTCHA パズルに正常に応答したクライアントに対して、トークンを作成、更新、暗号化します。トークンを持つクライアントが Web リクエストを送信すると暗号化されたトークンが含まれ、AWS WAF はトークンを復号化してその内容を検証します。 Bot Control ダッシュボードの「トークンステータス」ペインには、様々なトークンステータスラベルのカウントと、リクエストに適用されたルールアクションのペアが表示されます。 IP token absent thresholds ペインには、トークン無しでリクエストを多数送信した IPに関するデータが表示されます。この情報を使って AWS WAF の設定を細かく調整できます。 例えば Bot Control ルールグループ内で、有効なトークンがないリクエストがルールグループの評価を終了し、Web ACL による評価が続行される可能性があります。トークンがない、またはトークンが拒否されたリクエストをブロックするには、マネージドルールグループの直後に実行されるルールを追加して、 ルールグループが処理しなかったリクエストをキャプチャしてブロック できます。図5 に示す Token status ペインを参照してトークンを取得するリクエストの量を監視し、そのようなリクエストをレート制限またはブロックするかどうかを決定できます。 図5: トークンステータスではトークンを取得するリクエストの量を監視できます CloudFront セキュリティダッシュボードとの比較 AWS WAF traffic overview ダッシュボードは、AWS WAF で保護されているリソースに到達する Web トラフィックの全体的な可視性を向上させます。一方 CloudFront セキュリティダッシュボード は、AWS WAF の可視性と制御を CloudFront ディストリビューションに直接もたらします。潜在的な脅威や問題を示す可能性のあるパターンの詳細な可視性と分析が必要な場合は、AWS WAF traffic overview ダッシュボードが最適です。アプリケーションの配信とセキュリティを一箇所で管理し、サービスコンソール間を移動することなくアプリケーションのトップセキュリティトレンド、許可および遮断されたトラフィック、ボット活動を確認したい場合は、CloudFront セキュリティダッシュボードの方が適している可能性があります。 可用性と価格設定 新しいダッシュボードは AWS WAF コンソールでトラフィックをより適切に監視できます。デフォルトで無料で利用でき、追加の設定は必要ありません。CloudWatch ロギングには別の価格モデルがあり、フルロギングを有効にしている場合は CloudWatch の料金が発生します。CloudWatch の料金の詳細については こちら をご覧ください。環境のニーズに合わせてダッシュボードをカスタマイズすることもできます。 結論 AWS WAF traffic overview ダッシュボードを使用すると、Web セキュリティの状況と境界保護を改善する必要があるトラフィックパターンについて、実行可能な洞察を得ることができます。 この記事では、ダッシュボードを使用して Web アプリケーションを保護する方法を学びました。トラフィックパターン分析と次の可能なステップを説明しました。さらに、ボットからのトラフィックを観察し、アプリケーションのニーズに応じてそれらに関連するアクションを実行する方法を学びました。 AWS WAF traffic overview ダッシュボードは、ほとんどのユースケースに対応し、Web トラフィックのセキュリティ可視性のデフォルトのオプションとして設計されています。もしカスタムソリューションを作成したい場合は「 Deploy a dashboard for AWS WAF with minimal effort 」というブログのガイダンスを参照してください。 このブログは「 Introducing the AWS WAF traffic overview dashboard 」と題された記事の翻訳となります。 翻訳は Senior Solutions Architect の森が担当しました。

こんにちは、AWS トレーニングデリバリーマネージャー の西村航です。 こんな悩みをかかえている方はいませんか？「生成 AI を勉強したいんだけど何から勉強すればよいだろう？」という方、または「基盤モデルをチューニングしたり自社開発したりすることに興味があるけど、どこかに勉強方法がまとまってないかな？」という方。本記事はそういった 生成 AI を勉強したい初学者の方や生成 AI を活用した開発がしたいエンジニアの方を対象にした記事になります。 どこで生成 AI を勉強するのか？ AWS Skill Builder で勉強しましょう。AWS Skill Builder は AWS のオンライン学習センターです。何度でも視聴できるオンデマンドの AWS デジタルトレーニング、AWS 認定の公式練習問題、ゲーム形式で AWS を学べる AWS Cloud Quest などなど、幅広い AWS 学習コンテンツにアクセスすることができます。さらに AWS Skill Builder の 有償サブスクリプション にお申し込みいただくと、AWS 認定の公式模擬試験、ハンズオンラボ、AWS Jam Journey などの追加コンテンツをお楽しみいただけます。 本記事では 生成 AI を勉強する方法に関して、学習リソースとして AWS Skill Builder やイベント資料・ブログ記事をご紹介しつつ、４つのステップに分けてお話していきます。 ステップは勉強の内容や目的によって分かれています。 ステップ 1：生成 AI の基礎を勉強したい初学者の方 ステップ 2：公開済み生成 AI 基盤モデルや API をまず活用してみたいエンジニアの方 ステップ 3：公開済み生成 AI 基盤モデルをチューニングしたいエンジニアの方 ステップ 4：生成 AI の基盤モデルを自社開発したいエンジニアの方 それではここから各ステップに分けて詳細にお話していきます。 ステップ1. 生成 AI とは 本ステップは、エンジニアロールではない営業職や企画職の方なども含めた生成 AI 初学者を対象に、そもそも生成 AI とは何か？ユースケースは？といった生成 AI の基礎内容を取り扱います。 1. AWS で始める生成系 AI for Entry ：AWS における生成 AI の学習の第一歩となる日本オリジナルコースです。これから生成 AI を業務で活用していく上で、そもそも生成 AI とは何なのか、どのような技術的背景や種類があるのか、業務で活用する上でのユースケースや課題などを学習します。また、それらの課題に対して、AWS がどのように活用できるかを学習します。 2. Generative AI for Executives ：生成 AI の概要を説明するコースです。受講者は、生成 AI とは何か、それがどのようにして経営者の懸念や課題に対応するのか、またどのようにしてビジネスの成長をサポートするのかを学びます。また、AI が数多くの業界に大変革をもたらす可能性をどれほど秘めているのかも学びます。 3. Introduction to Generative AI – Art of the Possible ：3部構成のシリーズの1個目です。生成 AI とそのユースケースやリスクと利点について紹介するコースです。このコースを修了すると、受講者は生成 AI、およびそのリスクと利点の基本を説明できるようになります。また、自身のビジネスでコンテンツ生成をどのように活用できるかを説明できるようになります。 4. Planning a Generative AI Project ：3部構成のシリーズの2個目です。生成 AI に関する技術的な基本と主要な用語について学ぶコースです。また、生成 AI プロジェクトを計画するためのステップを学び、生成 AI を使用するリスクと利点を評価します。 5. Building a Generative AI-Ready Organization ：3部構成のシリーズの3個目です。このコースを修了すると、生成 AI 対応組織の構築に関する主な考慮事項を説明できるようになります。また、従業員をスキルアップさせ、職場に生成 AI の思考を導入するためのツールや知識を身に付けることができます。 6. AI ユースケースエクスプローラー ： AI に関してユースケースを探すことができるサイトになります。業種やビジネス機能やビジネス成果、テクノロジー など複数のフィルタリングメニューから選択することもできますので、興味のあるユースケースが探しやすい構成となっています。 7. 生成系 AI でプロダクトの価値を高めるには ：自社の現状を分析して、生成 AI でプロダクトの価値を上げる3ステップを知ることができる資料です。すぐに始めることができる生成 AI 活用プロジェクトチャートなど AWS の機械学習のサービスをどのように使うのか分かりやすく記載されています。 ステップ2. プロプライエタリ 本ステップでは、エントリーレベルの生成 AI エンジニアの方を対象に、公開済み生成 AI 基盤モデルや API を活用する際に必要な情報を取り扱います。 1. Amazon Bedrock Getting Started ：Amazon Bedrock は生成 AI アプリケーションの構築とスケールを素早く行うための基盤モデルと一連のツールを提供するフルマネージドサービスです。このコースでは、Amazon Bedrock の利点、特徴、一般的なユースケース、技術的概念、コストについて学習します。また、チャットボットソリューションを構築するために、他の AWS サービスと Amazon Bedrock を組み合わせて使用したアーキテクチャも確認することができます。 2. Amazon Bedrock で始める生成系 AI アプリケーション ：Amazon Bedrock を使った 生成 AI アプリケーションでどんなことができるのかを、実際にサンプルアプリケーションを動かしながら紹介するコースです。アプリケーションのコードは公開されていますので、実際に動かしてみたいという方は、動画を見ながら一緒に環境構築してみていただくこともできます。 3. Foundations of Prompt Engineering ：効果的なプロンプトを設計するための原則、テクニック、ベストプラクティスについて学習するコースです。プロンプトエンジニアリングの基礎から高度なプロンプトテクニックまでカバーしています。また、基盤モデルを操作する際に、プロンプトの誤用を防ぎ、バイアスを軽減する方法についても学習します。 4. Amazon CodeWhisperer – Getting Started ：Amazon CodeWhisperer は生成 AI を活用した高度なコーディングコンパニオンで、ユーザーの入力時にユーザーとやり取りしながらコードを提案することで、コーディングの効率と生産性を高めます。このコースでは、サポートされている統合開発環境 (IDE) やコードエディタに CodeWhisperer をインストールして、使用する方法を学習します。 5. Amazon Transcribe Getting Started ：Amazon Transcribe は、音声をテキストに変換できるフルマネージドの人工知能 (AI) サービスで、自動音声認識技術 (ASR) を用いて音声をテキストに変換します。この Getting Started コースでは、Amazon Transcribe の利点、特徴、一般的なユースケース、技術的概念、コストについて学習します。 6. Amazon Kendra Getting Started ：Amazon Kendra は、機械学習による高精度な検索結果と非構造化データの検索機能を提供する自然言語検索サービスです。このコースでは、Amazon Kendra の利点、特徴、一般的なユースケース、技術的概念について学習します。また、ユースケースにさらに適応できる Amazon Kendra を使用した検索ソリューションのアーキテクチャも確認します。 7. PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス ：PartyRock は生成 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。PartyRock でアプリケーションを作成してカスタマイズして公開する一連の流れをブログ記事で確認することができます。 8. Build Using Amazon CodeWhisperer ：AWS の安全なサンドボックス環境で一連の課題をこなすことで、DevOps プロフェッショナルの皆様に Amazon CodeWhisperer による構築を実際に経験してもらう、実践的なハンズオンラボです。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 9. Build a Question-answering Bot using Generative AI ：このハンズオンラボでは、AWS のサービスに関する質問に答えるチャットボットを作成します。ハンズオンラボは、大規模言語モデル (LLM) のデプロイ、Amazon Kendra データソースとの統合、さらに、ユーザーの質問に対する回答を見つけるために、LLM にクエリを実行して検索拡張生成 (RAG) を使用する Amazon Lex V2 チャットボットの作成といった実践的な経験を提供するよう設計されていますので、このハンズオンラボを実施することで言語モデルの基本的な機能に情報を追加して強化する方法を理解できます。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 ステップ3. チューニング 本ステップでは、ミドル〜ハイレベルの生成 AI エンジニアの方を対象に、公開済み生成 AI 基盤モデルをチューニングする情報を取り扱います。 1. Amazon SageMaker JumpStart で始める生成系AI ：Amazon SageMaker は、機械学習モデルの構築、トレーニング、デプロイを簡単にするフルマネージドサービスです。このコースでは、生成 AI に興味があるが、どのように始めればよいかわからないという方に向けて、Amazon SageMaker を使って、シンプルかつ迅速に生成 AI の基盤モデルをデプロイしたり、チューニングする方法を紹介します。Amazon SageMaker の機能には、ユーザーが迅速に機械学習を開始できるよう Amazon SageMaker JumpStart と呼ばれる機械学習ハブが含まれています。今回のコースでは、画像生成のユースケースをテーマに、Amazon SageMaker JumpStart で公開されている基盤モデルの利用方法をデモ動画で解説していきます。 2. AWS Cloud Quest: Machine Learning ：AWS Cloud Quest は、AWSのサービスを利用した演習や実習を通して、実践的なAWSスキルを身につけることができるロールベースの学習ゲームです。AWS Cloud Quest ではいくつかの技術領域から選択できるロールがありますが、本 Machine Learning Role では AWS AI サービスを使用したソリューション構築を支援するソリューション構築課題を探索します。なお、2024年3月時点では英語版のみの提供となります。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 3. Jam Journey GenAI re:Invent 2023 ：re:Invent 2023 にて使用されたハンズオンラボです。AWS 環境を触りながら与えられた課題を解決していく実践形式のハンズオンラボで、生成 AI をテーマにした課題が複数ピックアップされています。実施するには AWS Skill Builder の有償サブスクリプションが必要になります。 4. AWS AI Week For Developers ：オンラインイベント AWS AI Week for Developers の動画を YouTube で視聴することができます。生成 AI を中心とした AI 技術の基礎から最新情報、そして開発者視点の活用方法 / 適用事例など、「まだ生成 AI について十分な知識がない」とお考えの方から、すでに知識をお持ちの方まで、スキルレベルに合わせた内容になっており、どなたにもお楽しみいただけるコンテンツとなっております。 ステップ4. スクラッチ 本ステップでは、ミドル〜ハイレベルの生成 AI エンジニアの方を対象に、生成 AI の基盤モデルを自社開発する際に必要な情報を取り扱います。 1. AWS で作る自社用基盤モデル (YouTube) ：本セッションでは、AWS が提供する機械学習基盤を活用して、自社用の大規模言語モデルを独自に学習させるためのベストプラクティスや事例について取り扱います。基盤モデルの特徴と独自構築の必要性、基盤モデル構築のための開発プロセス、基盤モデル作成に関わる AWS の支援体制・テクノロジーを順を追ってお話します。 2. AWS での生成 AI 基礎 Technical Deep Dive Series ：YouTube にて視聴できる英語の動画コンテンツになります。本コンテンツでは、最先端の基盤モデルを事前トレーニング、ファインチューニング、デプロイするための概念的な基礎、実践的なアドバイス、実践的なガイダンスなど技術的に深堀りすることができます。 3. 大規模言語モデルからはじめる生成AI ：DeepLearning.AI と AWS が共同で Coursera 上で提供するコースです。このコースを受講することにより、データサイエンティストやエンジニアの方は、実世界のアプリケーション向けに LLM を選択、トレーニング、ファインチューニング、デプロイするエキスパートになるための準備を整えることができます。このオンデマンドコースは、約 16 時間の動画、クイズ、ハンズオンラボ、追加の読み物を含む 3 週間のコンテンツで構成されています。 4. FMOps/LLMOps : 生成系 AI の運用と MLOps との違い ：最近、多くのお客様は大規模言語モデル (Large Language Model: LLM) に高い期待を示しており、生成 AI がビジネスをどのように変革できるか考えています。しかし、そのようなソリューションやモデルをビジネスの日常業務に持ち込むことは簡単な作業ではありません。本ブログ記事では、MLOps の原則を利用して生成 AI アプリケーションを運用化する方法について説明します。これにより、基盤モデル運用 (FMOps) の基盤が築かれます。さらに、Text to Text のアプリケーションや LLM 運用 (LLMOps) について深掘りします。 Next Action Next Action では、さらに生成 AI を活用したシステム構築に向けて提案や実装方法の引き出しを増やしていくための、ワークショップ・フレームワーク・事例を取り扱います。 Action 1. Workshop で理解を深める 1. Generative AI Use Cases JP ：生成 AI を活用したビジネスユースケースのデモンストレーションです。 2. Amazon Bedrock Workshop ：Amazon Bedrock を通じて基盤モデルを活用する実践的な体験を提供するワークショップです。 3. Generative AI Workshop ：ユースケースに活用できる生成 AI モデルの構築、トレーニング、デプロイについて、エンドツーエンドで理解できるワークショップです。 4. ML Enablement Workshop ：組織横断的にチームを組成し、機械学習による成長サイクルを実現する計画を立てるワークショップです。 Action 2. フレームワークを理解する 1. CAF-AI ：CAF-AI は AI への移行を支援する目的で設計されており、AI/ML によってビジネス価値を生み出そうとする組織にとってのメンタルモデルを示しています。 2. Machine Learning Lens | AWS Well-Architected ：MLワークロードを設計する際に適用することができるガイダンスとアーキテクチャーの原則です。 Action 3. 事例やアップデートを確認する 1. AWS サービス別資料 (機械学習とAI) ：AI/ML のサービス別資料です。 2. AWS Summit Tokyo 2023(機械学習とAI) ：AI/ML カテゴリの AWS Summit Tokyo 2023 セッション資料です。 3. AWS ブログ(カテゴリ：GenerativeAI) ：AWS 公式ブログに投稿されている生成 AI の記事です。 まとめ 本記事では AWS Skill Builder で生成 AI を勉強する 4 ステップ を紹介しました。 今日から早速始めてみましょう。 最後まで読んでいただき、本当にありがとうございました！ 著者について 西村 航 (Wataru Nishimura) @kuwablo AWS トレーニングサービス本部 トレーニングデリバリーマネージャー ジャスミン茶が好きです。

Claude 3 によってパワーアップされた生成 AI、Next.js、 AWS Amplify 、 Amazon Bedrock  の世界に飛び込んでいきましょう。このガイドでは、ユーザーが食材のリストを入力し、Claude 3 が入力された食材にもとづいて美味しいレシピを提案するレシピ提案アプリの作成方法を紹介します。 2023 年 11 月、AWS Amplify は次世代のフルスタックアプリ構築機能の パブリックプレビュー を発表しました。 Amplify Gen 2 はコードファーストの開発者エクスペリエンスを採用しており、開発者は TypeScript と AWS Cloud Development Kit ( AWS CDK ) を使用して、認証やデータ利用のユースケースを含むクラウドリソースを定義およびプロビジョニングできます。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの先進的な AI 企業から選択した高性能な基盤モデル (FM) をフルマネージドで提供するサービスです。単一の API を通じてこれらのモデルにアクセスできるほか、セキュリティ、プライバシー、責任ある AI の観点を考慮した生成型 AI アプリケーションを構築するために必要な幅広い機能を利用できます。Amazon Bedrock では、選択したモデルに関係なく単一の API にアクセスできるため、異なる FM を利用したり、コード変更を最小限に抑えて最新バージョンのモデルにアップグレードしたりする柔軟性が得られます。 AWS Amplify は、データ管理、UI コンポーネント、ホスティングなどの機能群を提供し、クラウドでの Web アプリ開発を加速します。生成AI アプリを構築する際、Amplify はプロセスを簡略化し、シームレスな開発に必要なツールを提供します。さらに、AWS CDK が Amplify Gen 2 を動作させることで、Amazon Bedrock への接続はほんの数行のコードで実現できます。この強力な組み合わせにより、レシピジェネレーターアプリの開発、デプロイ、スケーリングを効率的に行うとともに、セキュリティとパフォーマンスを確保できます。 前提条件 AWS アカウント 。Amplify は AWS 無料利用枠 が含まれています。 Node.js v18.17 以降 npm v9 以降 git v2.14.1 以降 テキストエディタ。このガイドでは VSCode を使用しますが、好みの IDE を使用できます。 Amazon Bedrock モデルアクセス Amazon Bedrock を使用すると、ユーザーはさまざまな生成 AI モデルへのアクセスをリクエストできます。 この例では、Anthropic の Claude 3 Sonnet へのアクセスが必要です。 以下の手順に従ってアクセスをリクエストしてください。 ステップ 1: AWS コンソールにサインインし、Amazon Bedrock に移動します。リージョン選択から us-east-1 リージョンを選択します。 ステップ 2: Claude モデルを選択し、 「モデルアクセスをリクエスト」 ボタンをクリックしてください。 ステップ 3:   「モデルアクセスを管理」 ボタンを選択 ステップ 4: Claude 3 Sonnet のオプションをチェックし、 「変更を保存」 ボタンをクリックしてください。 リポジトリのクローン ステップ 1: AWS Samples の リポジトリ に移動し、Fork ボタンから自分のリポジトリに Fork します ステップ 2: 端末で以下のコマンドを実行してアプリをクローンします git clone https://github.com/[REPLACE_YOUR_GITHUB_NAME]/recipe-ai ステップ 3: 端末で以下のコマンドを実行することで、VSCode で新しくクローンしたリポジトリのディレクトリを開きます。 cd recipe-ai code . -r VSCode でリポジトリフォルダを開きます。amplify ディレクトリにはバックエンドの詳細設定が含まれています。（次のセクションで説明します） ステップ 4: 以下のコマンドを実行して、Amplify Gen 2 パッケージを含む必要なパッケージをインストールします npm ｃi Amplify バックエンド 最終的なアプリ(記事の冒頭の gif を参照)では、ユーザーは食材を入力し、Amazon Bedrock からレシピをリクエストするボタンをクリックします。 このコードはクローンしたリポジトリにあります。 ここでは、Amplify アプリを Amazon Bedrock と接続するための主要なステップを説明します。 リポジトリには、データディレクトリを含む amplify フォルダがあります。 amplify/data/resource.ts ファイルには、食材のリストを受け取り、それらの食材に基づいてレシピを生成するために Amazon Bedrock にリンクできる GraphQL クエリを定義しました。このクエリは、Amazon Bedrock からのレスポンスを構造化するためにカスタムタイプを使用します。 GraphQL API のスキーマは 2 つの主要な部分から構成されます: askBedrock クエリは、 ingredients という文字列の配列を受け取り、 BedrockResponse を返します。 .authorization([a.allow.public()]) を使用して公開アクセス可能にしました。 .handler(a.handler.custom({ entry: "./bedrock.js", dataSource: "bedrockDS" })) 行は、 bedrockDS をデータソースとして使用し、 bedrock.js 内で定義されているこのクエリのカスタムハンドラを設定します。 BedrockResponse は body と error の 2 つの文字列型フィールドを持つカスタムタイプです。このカスタムタイプは、 askBedrock クエリからのレスポンスを構造化するために使用されます。 ... const schema = a.schema({ BedrockResponse: a.customType({ body: a.string(), error: a.string(), }), askBedrock: a .query() .arguments({ ingredients: a.string().array() }) .returns(a.ref("BedrockResponse")) .authorization([a.allow.public()]) .handler( a.handler.custom({ entry: "./bedrock.js", dataSource: "bedrockDS" }) ), }); ... amplify/backend.ts ファイルでは、Amazon Bedrock へのクエリを接続するために bedrockDS という名前の HTTP データソースを作成します。このデータソースは、 us-east-1 リージョンの Bedrock サービスに関連付けられています。さらに、 addToPrincipalPolicy メソッドを使用して、 bedrockDS データソースのプリンシパルに新しいポリシーを追加します。ポリシーステートメントは、許可されたリソースとアクションを指定します。この場合、リソースは Claude 3 モデルの AWS ARN(Amazon リソースネーム)であり、許可されたアクションは bedrock:InvokeModel です。 const bedrockDataSource = backend.data.resources.graphqlApi.addHttpDataSource( "bedrockDS", "https://bedrock-runtime.us-east-1.amazonaws.com", { authorizationConfig: { signingRegion: "us-east-1", signingServiceName: "bedrock", }, } ); bedrockDataSource.grantPrincipal.addToPrincipalPolicy( new PolicyStatement({ resources: [ "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0", ], actions: ["bedrock:InvokeModel"], }) ); amplify/data/bedrock.js  ファイルには、 askBedrock ハンドラの実装のロジックが含まれています。 これは、クエリの入力パラメータ、つまり ingredients を利用してプロンプトを生成し、メッセージ配列の一部としてプロンプト文字列をリクエスト本文に含めることで、Claude 3 モデルに対して POST リクエストを使用し、 HTTP データソース (今回はAmazon Bedrock) に送信します。 export function request(ctx) { const { ingredients = [] } = ctx.args ; const prompt = `Suggest a recipe idea using these ingredients : ${ ingredients.join( "," )}.` ; return { resourcePath: `/model/anthropic.claude-3-sonnet-20240229-v1:0/invoke`, method: "POST", params: { headers: { "Content-Type": "application/json", }, body: { anthropic_version: "bedrock-2023-05-31", max_tokens: 1000, messages: [ { role: "user", content: [ { type: "text", text: `\n\nHuman:${ prompt } \n\nAssistant:`, }, ], }, ], }, }, }; } export function response(ctx) { return { body: ctx.result.body, }; } アプリを実行すると(次のセクションで示されているように)、 amplifyconfiguration.json という名前のファイルが自動的に生成されます。このファイルには、API のエンドポイントの詳細が含まれています。 src/app/amplify-utils.ts で、以下のように Amplify クライアントライブラリを初期化して設定します。次に、Amplify バックエンドへの完全型付き API リクエストを容易にするデータクライアントを作成します。 import config from "@/../amplifyconfiguration.json"; import { Amplify } from "aws-amplify"; import { generateClient } from "aws-amplify/data"; import { type Schema } from "../../amplify/data/resource"; Amplify.configure(config); export const amplifyClient = generateClient(); このアプリは、 src/app/page.tsx ファイルを使用して、食材のリストを送信するためのフォームをユーザーに提示します。 送信されると、 src/app/actions.ts ファイルの generateRecipe 関数が呼び出され、生成されたレシピを取得してユーザーに表示します。 src/app/actions.ts ファイルには、 generateRecipe 関数があります。この関数は Amplify クライアントを利用して askBedrock クエリを呼び出し、食材をパラメータとして渡して Amazon Bedrock から AI 生成されたレシピを取得します。 import { amplifyClient } from "./amplify-utils"; export async function generateRecipe(formData: FormData) { const response = await amplifyClient.queries.askBedrock({ ingredients: [formData.get("ingredients")?.toString() || ""], }); const res = JSON.parse(response.data ?.body !); const content = res.content[0].text ; return content || ""; } アプリの実行 ステップ 1 : Amplify は各開発者に個人用のクラウド サンドボックス環境を提供し、高速なビルド、テスト、反復のための隔離された開発スペースを提供します。クラウド サンドボックス環境を開始するには、新しいターミナル ウィンドウを開き、次のコマンドを実行します: npx amplify sandbox ステップ 2: ローカルホスト開発サーバーを起動するために、以下のコマンドを実行します。 npm run dev アプリのデプロイ アプリが正しく機能するようになったので、Amplify でデプロイしてホストしましょう。Amplify は、組み込みの CI/CD を備えたフルマネージドのホスティングサービスを提供し、Git ブランチを使用した本番環境とステージング環境の設定を簡素化します。Gen 2 では、リポジトリの各 Git ブランチごとに Amplify のフルスタック環境が作成されます。 ステップ 1: AWS コンソールにサインインし、使用したい AWS リージョンを選択します。パブリックプレビューのバナーをクリックし、「 Amplify Gen 2 を試す 」を選択します。 ステップ 2 : 「オプション 2: 既存のアプリケーションを使用して開始」 を選択し、 GitHub を選んだ後、 「次へ」 を選択して進めます。 ステップ 3 GitHub にログインし、「 Authorize AWS Amplify 」ボタンをクリックします。 ステップ 4: ドロップダウンリストからリポジトリとブランチを選択し、 「次へ」 を選択して進めます。 注: ドロップダウンリストにリポジトリが表示されない場合は、「 View GitHub permissions 」ボタンをクリックしてください。次に、リポジトリを選択し、アクセスを許可するために「 Install & Authorize 」ボタンをクリックしてください。 ステップ 5: 設定を確認し、 「次へ」  ボタンをクリックして進めてください。 ステップ 6: 最後に、「 保存してデプロイ 」ボタンをクリックして、デプロイプロセスを開始します。 ステップ 7: デプロイプロセスが完了するのを待ち、 「デプロイされたURLにアクセス」 ボタンを使用して Web アプリを開きます。 リソースのクリーンアップ このチュートリアルを終えたので、以下に示すように Amplify コンソールからアプリを削除することで、バックエンドリソースを削除し予期しないコストを防ぐことができます。 結論 おめでとうございます! AWS Amplify Gen 2 と Amazon Bedrock を使用して、生成 AI の力を借りたレシピジェネレーターアプリを開発することに成功しました。 加えて、Amplify Hosting を使用して AWS にアプリをデプロイしました。 Amplify Gen 2 を始めるには、 クイックスタートチュートリアル をお試しください。 フィードバックや機能リクエストは、 コミュニティ Discord にご参加ください。 この記事は、 Use Generative AI and Next.js with AWS Amplify to build a Fullstack Recipe Generator を翻訳したものです。翻訳はソリューションアーキテクトの 髙柴元 が担当致しました。 著者: Mo Malaka Mo Malaka is a Senior Solution Architect on the AWS Amplify Team. The Solution Architecture team educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Mo enjoys using technology to solve problems and making people ’ s lives easier. You can find Mo on YouTube or on Twitter .

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 寒暖差が激しく体調管理が難しいですが、みなさんいかがお過ごしでしょうか？ 自分は数年ぶりに風邪をひいてしまい、やっと回復しました。みなさんもお気を付けください。 さて、直近でいくつかイベントが予定されています。ご都合つく方はぜひご活用ください！ 2024 年 3 月 28 日 (木) – サーバレスで始めるAWS データベースサービス-RDS/Aurora編 – AWS 物流 DX セミナー 2024 2024 年 4 月 11 日 (木) – IBM Db2 の資産を AWS で活用する – 生成 AI の新展開 – マルチモーダル生成 AI の活用方法 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年3月18日週の主要なアップデート 3/18(月) Get visibility to your auto deployment configuration with a new StackSets API AWS CloudFromation StackSetsにListStackSetAutoDeploymentTargets APIが追加されました。AWS CloudFormation StackSetsは、複数のアカウントおよび AWS リージョン のスタックを 1 度のオペレーションで、作成、更新、削除できるようにする機能です。StackSetsはOUをターゲットにすることができますが、自動デプロイする際OUによって利用可能なリージョンが違う場合、どのOUのどのリージョンに適用されているか各アカウントにログインして確認する必要がありました。今回のアップデートはこれを一覧表示できるAPIのリリースです。 AWS Secrets Manager announces support for Amazon Redshift Serverless data warehouse AWS Secrets ManagerがAmazon Redfhift サーバレスをサポートしました。これにより、データウェアハウスへのユーザー認証情報のローテーションを管理するといった認証情報の面倒な作業が不要になり、AWS Secrets Managerから直接作成および設定が可能になります。この機能はAmazon Redshift サーバーレスが利用可能なすべての AWS リージョンでご利用いただけます。詳細は ドキュメント もご確認ください。 New Amazon SageMaker integration with NVIDIA NIM inference microservices Amazon SageMakerとNVIDIA NIM inference microservicesが統合され、NVIDIAアクセラレータコンピューティングインフラストラクチャ上で大規模言語モデル(LLM)の価格パフォーマンスをさらに向上させることができるようになりました。NIMはNVIDIA AI エンタープライズソフトウェアプラットフォームの一部としてLLMによる推論用の高性能なAIコンテナを提供する機能です。推論のために最適化された様々なLLMのコンテナを提供しており。Llama 2 (7B、13B、70B)、Mistral-7b-Instruct、Mixtral-8x7b、NVIDIA Nemotron-3 などがサポートされる他、それ以外のモデルのGPU最適化バージョンを作成するためのツールも提供します。Amazon SageMaker が利用可能なすべての AWS リージョンでアクセスできます。詳細については ブログ もご確認ください。 Amazon Managed Service for Apache Flink adds support for Apache Flink 1.18 Amazon Managed Service for Apache FlinkがApache Flink 1.18をサポートしました。Ver 1.18で新たにサポートされる機能などの詳細については ドキュメント をご確認ください。同時にAmazon Managed Service for Apache Flinkの インプレースアップグレードのサポート も発表されています。これによりより簡素にトレーサビリティを確保してアップグレードが可能です。インプレースアップグレードの詳細は こちら もご確認ください。 3/19(火) Amazon Corretto 22 is now generally available Amazon Corretto 22の一般提供がGAしました。Linux, MacOS, Windows各々のバージョンを こちら からダウンロード可能です。OpenJDK 22のフィーチャーリリースの詳細に関しては OpenJDK 22のプロジェクトページ をご確認ください。 Amazon DynamoDB now supports AWS PrivateLink DynamoDBがPrivateLinkをサポートしました。これによりVPCや、オンプレミスからのプライベートネットワークからインターフェイスエンドポイントを介してアクセス可能になります。DynamoDBのPrivateLinkは全ての商用リージョンで使用可能です。詳細は ドキュメント もご確認ください。 AWS CodeBuild now supports custom images for AWS Lambda compute AWS CodeBuildで、AWS Lambda を使用してソフトウェアパッケージのビルドとテストを実行する際に、これまではマネージドコンテナイメージのみ利用可能でした。今回のアップデートによりLambdaの場合もAmazon ECRに保存されているコンテナイメージを使用できるようになり柔軟性が上がります。このアップデートは東京を含む10のリージョンでご利用いただけます。詳細は ドキュメント をご確認ください。 3/20(水) AWS announces a 7-day window to return Savings Plans Savings Plansを購入後、7日以内であれば返品できるようになりました。Savings Plansは柔軟な価格設定モデルで、1年または3年の利用契約をすることで、最大72%削減できる購入方法です。今回のアップデートで購入した後に最適ではないと気付いた場合に返品し、別の貯蓄プランを再購入でるようになりました。この機能は、中国リージョンを除くすべての AWS リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Neptune Database is now available in AWS Asia Pacific (Osaka) Region 大阪リージョンでAmazon Neptuneをご利用可能になりました。エンジンバージョン 1.1.0.0 以降および、R5、R5d、R6g、R6i、X2g、T4g、サーバーレスのインスタンスタイプがご利用いただけます。 Amazon Aurora zero-ETL integration with Amazon Redshift announces support for data filtering and CloudFormation Amazon MySQL to RedshiftのZero-ETL integrationでデータフィルタリングと、CloudFormationによるリソース設定・デプロイをサポートしました。データフィルタリングを使うことでレプリケートされるデータベースやテーブルを指定することができるので、より効率的にデータ分析との統合が可能になります。この機能は東京を含む9のリージョンでご利用いただけます。こちらの ブログ もご確認ください。 Amazon DynamoDB now supports resource-based policies Amazon DynamoDBがリソースベースのポリシーをサポートしました。リソースにアクセスできるIDおよびIAMプリンパルと、実行できるアクションを指定することが可能です。これにより、IAMプリンシパルによるクロスアカウントアクセスの制御も簡素化することができます。この機能はすべてのAWS 商用リージョンで利用できます。詳細については ドキュメント もご確認ください。 3/21(木) Amazon RDS Multi-AZ deployments with readable standby instances now support C6gd database instances Amazon RDSのc6gdインスタンスが２つの2つの読み取り可能なスタンバイを備えたマルチAZ 構成をサポートしました。PostgreSQLのバージョン 16.1以降、15.2以降、14.5以降、13.8以降、およびMySQLのバージョン 8.0.28以降で利用できます。東京、大阪リージョンを含む14のリージョンで利用可能です。 Announcing Package Group Configuration in AWS CodeArtifact AWS CodeArtifactがパッケージグループ設定の機能をサポートしました。この機能を使うと、パッケージ形式、名前空間および名前に基づいてCodeArtifactのパッケージをグループ定義できます。パッケージグループにPublish、External Upstream、Internal Upstreamのルール設定ができるため、意図しない公開や、パブリックリポジトリからのインポートを制御しセキュリティを強化できます。 3/22(金) Amazon DataZone launches enhancements to Amazon Redshift integration Amazon DataZoneとAmazon Redshiftの統合機能が強化されました。Datazone管理者はDefaultDatawarehouseBlueprint上にパラメーターセットを作成することができるようになりました。パラメーターセットを元にして環境プロファイルを作成することで、利用者は自分でパラメータ設定することなく環境を作成できるためプロセスを簡略化できます。この機能は東京を含む13のリージョンで利用可能です。詳細は ドキュメント もご確認ください。 Amazon MSK Connect now supports deleting worker configurations and tagging resources Amazon MSK ConnectでCloudFormationを利用したワーカー設定の削除やリソースのタグ付、カスタムプラグインの管理等がサポートされました。このアップデートによりリソースの管理やデプロイの自動化が容易になります。これらの機能はAmazon MSK Connect が利用可能なすべてのAWSリージョンでご利用いただけます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

※このブログは ” Highlighting modern innovations in cloud-based broadcast production at Inter BEE 2023 ” を翻訳したものです。 このブログは、Waves Audio Ltd のアソシエイト・プロダクト・マネージャー兼プロダクト・アプリケーション・エンジニアである Daniel Kamhaji が共同執筆しています。 はじめに このブログ記事では、 2023 年 11 月 15 日～ 17 日に幕張メッセで開催された Inter BEE で、アマゾンウェブサービス（ AWS ）ジャパンが紹介した、クラウドベースの放送制作における最新のイノベーションについて詳しく説明します。Inter BEE 2023 の AWS ブースでの Waves Cloud MX の役割に焦点を当てて、放送制作を形作るテクノロジーとコラボレーションをご紹介します。イノベーションが、信頼性が高く高度なライブプロダクションワークフローの基準をどのように設定しているかを明らかにします。さらに、AWS が提供するシグナルフローと配信サービスについても触れ、それらが日本市場に与える影響と、世界中のライブ放送とメディア制作の進化する状況に焦点を当てています。 Inter BEE 2023 における AWS ブース AWS Japan ブースで Waves Audio や業界のリーダーたちと未来の放送技術を紹介 国際放送機器展「 Inter BEE 」は、コンテンツビジネスにおける最新のイノベーションをグローバルに紹介する展示会です。毎年開催されるこのイベントと展示会は、テクノロジーの先駆者たちとのコラボレーションの拠点となり、放送ソリューションとワークフローの機能を紹介しています。Waves Audio Ltd. は、Inter BEE 2023 に AWS Japan と共に参加し、クラウドワークフローにおける業界の革新を紹介し、ライブ放送制作技術の一連のツール群を紹介しました。業界リーダー間の団結を示すブースでは、 ソニーの M2L-X ソフトウェアビジョンスイッチャー 、 SiennaND プロセッシングエンジン 、 Viz Trio &   Viz Engine 、 Telos Alliance Infinity VIP 、 Ateme TitanLive 、 LiveU Cloud Connect 、 TAG Video Systems  Multiviewer 、 Waves Cloud  MX オーディオミキシングプラットフォーム 、基本的なメディアサービス機能を提供する AWS Elemental により統合されました。これらの要素が一体となって、現在の技術的実装度合いを実証し、放送制作の発展のための実践的な青写真を提供するまとまりのあるエコシステムを作り上げています。 Inter BEE 2023 の AWS ブースでのライブプロダクション・デモンストレーションシステム コア接続 : NDI プロトコルによるストリームの簡略化 NDI (ネットワーク・デバイス・インターフェース) は、NewTek が標準的な LAN ネットワークを使用した IP 伝送およびライブプロダクション用に開発したオープンプロトコルです。その使いやすさと信頼性により、制作チェーンのさまざまな要素をつなぎ、理解のしやすさと信頼性によりプロセスの合理化を促進する、放送環境における魅力的なツールとなっています。 オペレーターのための操作方法 Waves Cloud MX は中心的な役割を担い、NDI オーディオ入力をライブフィードとして 4ch 、NDI による追加の 8ch のローカル再生を巧みにミックスして、洗練された最終ミックスを生み出しました。 NVIDIA GRID  ドライバーを搭載した Windows サーバー上で g4dn.4xlarge タイプの   Amazon Elastic Compute Cloud  (Amazon EC2) インスタンスを活用することで、本番環境では CPU パワーをオンデマンドでスケールアップし、必要に応じて最適なパフォーマンスを実現できます。 この適応性により、オペレーターはオーディオ処理用の広範なツールキットを活用できます。これらには、複数のマイクのリアルタイム自動バランスを実現する Dugan Speech プラグイン 、複雑なオーディオシェーピング用の F6 Floating-Band Dynamic EQ 、正確なノイズ抑制用の WNS 、正確なラウドネスメータリング用の WLM および Dorrough プラグインなどがあり、それぞれがプレミアムなサウンド体験に貢献しています。 150 種類以上の Waves プラグインを幅広く取り揃えているため、オーディオプロフェッショナルに豊富なインテリジェントでクリエイティブな機能を提供できます。Cloud MX のライセンスは   Amazon Elastic Block Store  (EBS) ドライブでアクティベートされるため、インスタンス間のライセンス移動が容易になり、デプロイプロセスが合理化されます。 NICE DCVとWaves FITコントローラーによる制御と仮想化の強化 操作感とバーチャルを融合させた Waves FIT コントロールサーフェス は、オーディオオペレーターにハンズオンフェーダーとエンコーダーインターフェースを提供します。コントローラーはローカルコンピューターに直接接続され、Amazon EC2 環境の RTP Midi を介して UDP IP パケットを介して制御情報を送信します。このセットアップにより、低レイテンシー測定により、オペレーターとクラウド間の応答性が向上します。 NICE DCV とタッチパネルディスプレイは、もう1つのコントロールサーフェスとしてリモートデスクトップ操作を提供しました。ユーザーは複数のタッチディスプレイでミキサーを操作でき、Waves Cloud MX の EC2 インスタンスに接続することで、ミキサーのウィンドウを好みに合わせて柔軟に広げたり配置したりできます。これにより、オペレーターは NICE DCV を介してローカルコンピューターのスピーカー構成でオーディオをモニタリングすることもでき、専用の Waves ASIO NDI コントロールパネルを使用してさまざまなオーディオドライバーやプロトコルの制限を回避できます。これにより、オーディオを Windows システムオーディオに送ることができます。 タッチスクリーンとフィットコントローラーを備えた Waves オーディオディスプレイ シグナルフロー : ライブ制作の全体像 1. このシステムの信号フローは、定義された経路をたどります。セキュア・リライアブル・トランスポート（ SRT ）ストリームは、Sienna の「 IP Connect SRT 」を介してオンプレミスの場所から送信され、NDI ストリームに変換され、本番環境ですぐに使用できます。 2. ブースのプレゼンテーションステージでは、 AWS Elemental Link デバイスを使用してライブ映像を撮影しました。これらのデバイスは、エンコーディングにおいて重要な役割を果たし、カメラやビデオ制作機器などのライブビデオソースをクラウドにリンクします。 3. さらに、LiveU は自社の LiveU Cloud Connect ソリューションを使用して、ブースでライブ信号を提供しました。このシステムは、LiveU LU800 マルチカメラフィールドユニットと LiveU クラウド EC2 インスタンスを効率的にブリッジし、LiveU の信頼性の高いトランスポートストリームプロトコル（ LRT ）を介したスムーズで統合された接続を保証します。 4. Amazon S3  はシステムのコアリポジトリとして機能し、Sienna ND プロセッシングエンジン、ソニーのスイッチャー、Waves Audio などの要素間でコンテンツを共有できます。デモシステムのメイン配信ハブおよび中央ストレージとして機能し、各パートナーソリューション用のビデオファイルやオーディオファイルなどのコンテンツを準備します。 5. その後、EC2 インスタンスでホストされる Sienna ND プロセッシングエンジンは、受信ストリームを処理し、メディアソースから追加のストリームを作成します。これにより、NDI 対応カメラからのライブフィードと事前に録画されたコンテンツの両方が、制作セットアップ内の目的の宛先向けに管理および準備されます。 6. NDI ストリームがセットアップをナビゲートすると、ソニー のM2L-X ソフトウェアベースのスイッチャーが ソニー製コントロールパネルでビデオスイッチングを管理し、エクスペリエンスをさらに向上させます。さらに、Viz Trio と Viz Engine によるグラフィックの強化により、視覚体験がさらに洗練され、リアルタイムのグラフィックレンダリングと管理が可能になり、視覚的に魅力的でダイナミックなライブコンテンツが視聴者に配信されます。同時に、32 ビットの浮動小数点倍精度ミックスエンジンを搭載した Waves Cloud MX は、オーディオフィードをミキシングして処理します。ミキサーは、処理されたオーディオを NDI を介して Sienna ND の「 NDIソースコネクト 」に送り、次に「オーディオエンベッダー」に送り、そこでビデオと同期します。その後、この新しい結合フィードは、ソニーのスイッチャーを介してループバックされます。 7. 番組全体は SRT ストリームを介して   AWS Elemental MediaConnect にブロードキャストされ、そこでライブビデオフィードの管理と配信が実行されます。 この段階で、 SRT 信号は Ateme TitanLive を通過し、ライブプロダクションとマスタープレイアウトシステムの間の接続ブリッジとして機能し、そこでライブビデオフィードを管理および配信します。その後、Ateme TitanLive は放送を複数のストリーミングプラットフォームに配信し、コンテンツの作成から視聴までの流れを完了します。さらに、 AWS Elemental MediaConnect の出力信号は、 TAG VS Multiveier ソリューションと    AWS Elemental MediaLive に送られ、クラウドマスタープレイアウトのデモンストレーションに向けてさらにモニタリングと処理が行われます。 ライブプロダクションデプロイメントのアーキテクチャ概要 結論 : 業界をリードするソリューションを統合して放送技術を進歩させる Inter BEE 2023 はクラウドベースの放送制作技術におけるイノベーションのショーケースだった。さまざまなメーカーの統合や AWS サービスの使用など、これらの進歩は、ライブ放送制作のワークフローに革命をもたらしています。これは、信頼性と最先端のパフォーマンスへのこだわりが日本市場ですでに話題を呼んでおり、ライブ放送やメディア制作への期待を変えています。 詳細については、以下のリソースを参照してください。 Inter BEE ウェブサイト 国際放送機器展とその業界における意義について詳しくは、Inter BEE の公式ウェブサイトをご覧ください。 WavesAudio ウェブサイト Waves Audio のウェブサイトにアクセスして、Waves Cloud MX をはじめとするオーディオミキシング技術の最新イノベーションをご覧ください。 ソニー M2L-X ソフトウェアビジョンスイッチャー ソニーの M2L-X ソフトウェアビジョンスイッチャーと、ビデオスイッチングテクノロジーにおけるその役割などについて詳しく学んでください。 Viz Trio と Viz Engine これらのテクノロジーの詳細については、Viz Trio と Viz Engine のサイトをご覧ください。 SiennaND プロセッシングエンジン さまざまなプロトコルなどのストリーム処理のための主要コンポーネントである SiennaND プロセッシングエンジンをご覧ください。 NDI (ネットワークデバイスインターフェイス) 中核となる接続フレームワークである NDI と、オーディオストリームとビデオストリームの統合を簡素化する上での NDI の役割について学んでください。 Ateme TitanLive Ateme TitanLive がさまざまなストリーミングプラットフォームへの放送コンテンツの配信にどのように貢献しているかをご覧ください。 Telos Alliance Infinity VIP このテクノロジーの詳細については、Telos Alliance Infinity VIP ページをご覧ください。 LiveU Cloud Connect IP ベースのライブブロードキャストソリューションの詳細については、LiveU Cloud Connect ページを参照してください。 Tag Video Systems Multiviewer Tag Video Systems Multiviewer の詳細をご覧ください。 メディア・ インテグレーション株式会社 日本最大のプロ仕様制作ソフトウェアの販売代理店であり、Waves 製品の日本における公式再販業者です。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 執筆及び翻訳は SA 斎藤、確認は SA 小林が担当しました。原文は こちら をご覧ください。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その後半となります。前半については、 こちらのリンク からご確認ください。 4．クラウド利活用の重要なポイント 一方、私たちが新たにクラウド上での開発を進めている次世代スマートメーターシステムでは、前回の 第 2 回のブログの 3 章 でご紹介したように、疎結合アーキテクチャによる拡張性とシステム開発に対する柔軟性、高い可用性の実現、マネージドサービス活用によるスケーラビリティや俊敏性、および運用最適化の実現、スマートメーターデータを分析し利活用するための AWS のデータ分析サービスの活用、という 3 つの開発方針に基づいて取り組んでいます。 この方針に沿って TCO 削減を含めたクラウドメリットを最大限に享受するため、AWS サービスの最適な組み合わせでシステム開発を進めていくことが重要ですが、AWS は多様なサービスや機能を提供しており、それぞれに特長や利用方法も異なります。要件やニーズにマッチした最適なサービスや機能を選択するためには、AWS クラウドを正しく理解して使いこなしていくことが肝要です。また、データの保護やアクセス制御など適切なセキュリティ対策を実現していくためには、AWS クラウドのセキュリティ機能やベストプラクティスを理解して使う必要があります。 こういった背景を踏まえて、AWS クラウド上でシステム開発を進めるうえで特に重要なのは、次の三つのポイントだと考えています。 私たち自身がシステムとクラウドを正しく理解すること。 システムベンダーがクラウドを正しく理解して受け入れ、積極的な活用に向けた体制整備ができていること。 私たち自身もシステムベンダーも、継続的なクラウドスキル獲得と向上を図っていくこと。 つまり、私たち自身の強い意志は不可欠ですが、それだけでクラウド活用を成功させることは容易ではなく、やはりクラウド活用を積極的に伴走してくれるシステムベンダーを私たちが適切に選択し、綿密に協業しながらシステム開発を進めることが不可欠です。 4-1. システムとクラウドに対する私たち自身の正しい理解 従来のシステム開発の経緯を顧みて、上記の方針に沿って着実にシステム開発を進めていくためには、アプリケーションシステムの全体像を私たち自身が正しく捉えることが重要と考え、業務とシステムの両面から現行システムへの理解を深めるよう取り組みを進めています。同時に、クラウド活用の議論を進めていくためにも、私たち自身がまずクラウドを正しく理解することも重要です。この点については、 第 2 回のブログの 5 章 の共通基盤の導入とシステム統制で詳しくご紹介した通りです。つまり、私たちがインフラレイヤを正しく理解し、深層まで把握することで、これを基盤とするアプリケーションの開発についても、システムベンダーとしっかり連携して協調しながら進めることができると考えています。 クラウド活用に関連して、よくある議論として「自分たちが所有することで得られる安心」に根差した意見提起がなされることもありますが、私たちはこれまで取り組んだ結果として、「クラウドを正しく理解する」ことで、自分たちが所有する以上のメリットがクラウド活用により享受できると考えています。特にフォーカスされやすいセキュリティ面で言うと、AWS を利用する場合、AWS 自身が多種多様なセキュリティ対策とそれを保証するための 認証 を取得しています。こうした対策を自分たち自身で実現しようとすると、自らがその検討や実装に時間を割く必要があります。しかし、餅は餅屋です。セキュリティ面を含めたインフラの整備や維持運用はクラウド事業者にアウトソーシングし、私たちはそれらを適切に利用しながら環境準備する( 責任共有モデル )とともに、本来実現したい業務要件に的を絞り、システム開発に本質的に注力すべきと考えています。 4-2. システムベンダーの適切なクラウドの理解と体制整備 また、正しいクラウド活用に向けては、私たちがクラウドを活用しようとする理由や動機、またどのように取り組もうとしているか、その方針などクラウド活用に係る基本スタンスの整理と、システムベンダーへのメッセージングも非常に重要です。クラウド活用方針を正しく伝えない限り、従来のサーバを Amazon EC2(EC2) 上に載せ換えてクラウド実現しただけ、ということになりかねません。それがたとえパッケージシステムであっても、そのまま EC2 の上に載せただけではクラウドの本質的なメリットを享受できるような取り組みとは言えません。クラウドメリットを最大限享受していくうえでは、マイクロサービスアーキテクチャの思想に根差し、AWS サービスのビルディングブロックを形成しながら AWS マネージドサービスをフル活用するようなシステム構想など、多様なサービスや機能を適材適所で選択しながら開発を進めていく必要性があります。 従来、オンプレミスでサーバ環境を整備しシステムを構築してきたシステムベンダーは、ともすればクラウド上に従来のシステムを組む方向に流れがちだと感じており、ユーザである私たちの強いニーズや意図を明確にシステムベンダーに示し、それを伝えなければ、クラウド活用に係る検討さえもなかなか進まないという状況はよく見られるかと思います。システムベンダーがクラウド活用の必要性を腹落ちして理解し、従来のやり方を刷新し、将来性を見据えて積極的なクラウド活用を一体的に推進できるよう、システムベンダーを活用する私たちからの積極的な働きかけは不可欠です。つまり、保有する安心感やメリットからクラウド活用へのマインドチェンジが重要なポイントだと考えます。アプリケーション開発を担うのはシステムベンダーであることから、このマインドチェンジは、私たちユーザのみならずシステムベンダーも一緒に実現すべきなのは明白です。そういった姿勢で並走できるシステムベンダーを私たちが選択し、相互に協調したシステム開発でなければクラウドの正しい活用は成功し得えないといえます。 その大前提としては、システムベンダーがそもそも正しくクラウドを理解していることが必須です。まず、システムベンダーがこれまで組み上げてきたアプリケーションシステム自体が、クラウド上でも正しく動くことを前提として理解を進め、クラウドの仕様や要件を適切に取り入れ組み直すことで、システムの移行や運用におけるトラブルや障害を防ぐことができます。また、その際には AWS のサービスやその機能を正しく理解することを通して、マイクロサービスの考え方やサーバレスアーキテクチャ、各種マネージドサービスの活用などクラウドメリットを最大限享受できるように設計開発を進めることで、システム自体の性能や信頼性を向上させることができます。堅牢なシステムの組み上げには、クラウドセキュリティを正しく理解することも不可欠です。 こういった協業関係を深化させるうえでも、 第 2 回のブログの 5 章 で説明したような共通基盤の導入を通して私たちがインフラを統制し、アプリ開発を担うシステムベンダーに必要な環境を共有する形で協業体制を整理してシステム開発を進めることも有効と考えています。 なお、私たちのプロジェクトにおいては、 AWS Professional Services も本プロジェクトに参画し、システムベンダーの自律的な取り組みを促しながら、システムベンダーの全体統括や技術支援という立ち位置で、私たちやシステムベンダーと常にコミュニケーションを図りながら強力なプロジェクト推進に協力いただいています。 4-3.　継続的なクラウドスキル獲得と向上 こういったクラウド活用推進において重要な考え方として、コンテナやサーバレスに代表されるクラウドと相性の良い技術の採用とその技術習得は非常に重要です。新しい技術を採用することが目的であればシステムとして導入することでゴールを達成できますが、 第 2 回のブログの 5 章 の共通基盤に係る説明でも触れた通り、自分たちのスキル醸成を狙うためには技術力向上の実現とは切り離せない取り組みであり、これら AWS クラウドの技術を理解しながら活用することも必須と考えています。新しい技術の習得やそれに伴うスキル醸成には、どうしても属人的な活動になりがちですが、それをいかに組織的に実現するか、当社の関係者にモチベーション高く活動を継続的に行っていくかという観点は、私たちが目指すスマートメーターシステムの実現や、その先のデータ利活用の更なる高度化にとっても必要不可欠だと考えています。 5. まとめ 本ブログでは、私たちのスマートメーターシステムの取り組みについて、現行世代システムのクラウドシフトとフルクラウドによる次世代システムの開発という、性格の異なる二つのプロジェクトの同時並行の様を、私たちの着眼点や留意事項を中心にご紹介してきました。 いずれのシステムもクラウドをベースにする、という判断は大きな判断であり、ブログの中でも紹介致しました通り、詰めた社内議論を経て、やっと合意形成を取り付けて進めてきました。クラウド推進側にも慎重側にも、踏み込んだ議論を要求してきたこともあり、私たちも非常に苦労してここまで進めて参った次第です。 AWS の紹介で海外の同業者との意見交換の場を持つことができましたが、そこで聞けたのは、私たちが経験してきたような社内議論を繰り広げてクラウド採用に至った等の話でした。日本に比べて進んでいる印象の海外事業者といえども社内にはクラウド慎重派がいて、クラウドの導入が手放しで円滑に進んでいるわけではない、ということがよく分かりました。また、国にもよりますが、規制当局がクラウドの利用に制限を設けたり、そもそも OT システムについてはクラウド利用を認めていなかったりなどの事情があることも分かりました。 このように、クラウドの利活用については、まだ慎重に考える関係者や制約となる規制の存在など、課題が残っているものの、これもブログにてお示しした通り、システムの将来における拡張性や柔軟性、これから間違いなく肝になるデータ利活用の環境整備、という観点からクラウドの徹底的な利活用は避けて通れないと考えています。 クラウドを徹底的に利活用していくためには、私たちのようなエンドユーザーとシステムベンダーの双方が、何を目指しているのか、そのためにどういう仕組みを導入しようとしているのか等々、相互理解を深め、双方ともに知見や知識、スキルを磨き続けていく意識が問われてくると考えています。私たちが導入した共通基盤の考え方や、それに伴うインフラ統制やアカウント管理のあり方などが、そうした意識を形にした一つの姿だと思います。また、こうした地道な意識浸透の活動を進めていくに当たって、クラウドのプロ中のプロである AWS、なかんずく AWS Professional Services の方々に負うところが非常に大きく、彼らのサポート無しには私たちの活動は簡単に頓挫していたように思います。私たちの取り組みはまだまだ道半ばではありますが、この場をお借りして改めてお礼申し上げます。 このブログが、読者皆様方のこれから先のシステム開発にあたって、クラウド利用を考えられる一助になれば幸いです。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

本稿は、 関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みの第 3 回となります。執行役員である松浦 康雄様より寄稿いただきました。前半、後半の 2 回に分けてご紹介いただきます。本稿は、その前半となります。 連載記事として、以下も公開されておりますので、ぜひご参照ください。 第 1 回の記事「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 1 回) – 前半 」 第 2 回の記事「 寄稿：関西電力送配電株式会社によるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 2 回) – 前半 」 1. はじめに 本稿では、三部構成で当社の取り組みをご紹介してきました。 第 1 回 は、当社スマートメーターシステムにおけるクラウド活用に向けた議論の全体像をご紹介しました。 第 2 回 では、次世代スマートメーターシステムの全体像について、技術的な観点も交えて私たちの現在の取り組みをご紹介しました。最後となる今回、第 3 回は、現行スマートメーターシステムのクラウド移行を中心に、私たちのクラウド活用に関する思いとこだわり、及びその取り組みについてご紹介します。 2. オンプレミスからクラウド活用へ 　当社の現行スマートメーターシステムは、第 1 回のブログで記載した通り、他電力に先立って開発を進めていた当時の背景もあって、昨今のようなメーターデータの収集管理システムのパッケージソリューションが存在しない中、複数のシステムベンダーとの協力のもと試行錯誤しながらシステム開発を進め、システムベンダーの技術や仕様に基づいて組み上げたシステムを、当社データセンターで構築しました。スマートメーターは 2012 年から当社管内のお客さまに本格導入を開始し、2023 年 3 月に全戸導入が完了するまで、スマートメーターの設置台数の拡大に伴い、現行システムで利用するサーバ数も増台しながらも、継続的な安定稼働を実現してきました。 一方で、そのような経緯で開発されたシステムであるため、独自 OS や商用データベースおよびミドルウェア採用に伴う経済性や将来持続性の問題、開発と運用のシステムベンダー依存に伴うシステムのブラックボックス化、業務処理ロジックの隠匿化などの課題に直面しており、また、スマートメーター収容数の拡大に伴うサーバハードウェアの増台、サーバのメーカー保守切れ対応の継続的な発生、さらにそのリプレイスに伴う OS やミドルウェアの技術検証など影響範囲が広く、コスト面だけではなく人的な業務負担も大きくなっていました。加えて、昨今の社会情勢の大きな変化により、半導体枯渇によるサーバのハードウェアの調達納期の遅延に代表される将来の不確実性といった、様々な課題も顕在化しています。そしてそのような複雑な状況が、スマートメーターから収集されるデータの柔軟かつ高度な利活用の拡大の障壁となっていました。 自社のオンプレミス環境でシステム運用していれば、私たちと同じような状況に陥り、同様の課題に直面するケースも多いかと思います。私たちは、それら課題に対する包括的な解決方策として、クラウド技術の活用が一つの選択肢になると考え、現行スマートメーターシステムのクラウドシフトを指向することにしました。 3. 現行スマートメーターシステムにおけるクラウド活用方針 本章では、私たちの現行システムにおける AWS 機能やサービスの捉え方やシステム移行の方針についてご紹介します。掲げた方針は 3 点あります。 現行システムのクラウド移行に向けた取り組み方針 AWS クラウドのサービスで代替できるものは、AWS に任せてオフロードする AWS クラウドならではの柔軟性をフル活用する 開発を進めながら AWS クラウドの技術革新や新サービスを随時取り込む 3-1. AWS クラウドサービスへのオフロード オンプレミスではディスク故障など日々のハードウェア障害にも個々に対処していく必要がありますが、クラウドではそういった障害対応は AWS にオフロードし私たちは意識する必要がなくなります。また、オフロードする割合を高めることで、インフラの構築や運用保守は、単にサービスの利用という形に置き換えることができます。つまり、データベースさえも組み上げる必要はなく、単にサービスを選んで利用するだけというように、システム構築の体制や考え方も大きく変わります( 図 1 )。 私たちのオンプレミスのサーバシステムでは、信頼性確保に必要となるクラスタソフトなどミドルウェアはシステムベンダー各社各様のものを採用されてきましたが、こういったミドルウェアはまず脱却の対象として位置付けました。その実現のため、 Amazon Elastic File System(EFS) や Amazon FSx 等を活用したステートレス化を含めたアプリケーション改修を実施するとともに、 Elastic Load Balancing(ELB) を活用したサーバ群のヘルスチェックを組み合わせ、かつ、マルチ AZ による拠点間冗長も実現しながら、システム全体としてのシステム信頼度を向上させています。 併せて、商用データベースの脱却も基本としています。検討当初から DB on Amazon EC2 の考え方は一切取らず、 Amazon Aurora または Amazon RDS の AWS マネージドサービス活用を前提とした移行検討を行っています。こういった AWS の各種マネージドサービスの積極活用の考え方は、マネージドサービスを活用した方が信頼性や運用保守性の向上とともに、運用負荷軽減に確実につながると評価した結果です。 図 1. AWS マネージドサービス活用による IT インフラ業務の AWS へのオフロード 3-2. AWSクラウドならではの柔軟性の活用 クラウドでは、リソースを必要な時に使って不要となれば捨てる、という身軽さがあり、「後戻りできる」というメリットがあります。 例えば、従来はサーバのリソースサイジングを緻密に行ったうえで、サーバの調達や導入に時間をかけながら進めていましたが、クラウドにおいては、「好きなときに、好きなリソースを、好きなだけ使える」という従量課金の考えのもと、その時点で決めた構成やソリューションを、よりよいものに柔軟に変更できます( 図 2 )。私たちの検討においては、インスタンスの変更も柔軟かつ簡単であることから、リソースサイジングを綿密に行うことなく、机上検討や実機検証を進めながらインスタンスタイプの選定を進めています。 図 2. AWS を活用する IT インフラ調達観点でのメリット また、従来は本番環境や開発環境をそれぞれ整備するのに、それぞれ大きな手間とコストをかけてきました。私たちは、今回、IT インフラの構築において Infrastructure as Code（IaC）を積極活用しています。IaC を活用し IT インフラのデプロイを自動化することで、人的ミスも回避することができますし、システム構成の見直しもアプリ開発を進めながら柔軟に対応可能です( 図 3 )。 図 3. AWS における IaC メリット 3-3.技術革新や新サービスの随時取り込み 導入当時には適切と判断したアーキテクチャであったとしても、導入からの時間経過に伴う技術革新により、当時よりも選択肢が増えたことで検討の幅が広がり、より良い構成を選択できる可能性があります( 図 4, 図 5 )。 例えば、私たちが検討を進める中で、「 Network Load Balancer(NLB) でセキュリティグループのサポートを開始 」という発表が 2023 年 8 月にありました。当初は、NLB についてはセキュリティグループチェーンの対象外としていましたが、この発表を受けて設計変更した結果、システム全体にわたるセキュリティグループのチェーン化を取り込みシンプルな仕組みでのセキュリティ確保が実現できています。 現在進めている、次世代スマートメーターシステムの構築においても、同様により良いサービスや機能が提供開始された場合には、それを活用しながら開発を進める方向です。 図 4. AWS の技術革新による新サービス・新機能の提供拡大 図 5. アナリティクス分野を含めて拡大する AWS サービス(抜粋) 本稿では、当社のスマートメーターシステムのクラウド採用に向けた取り組みについて、「 3．現行スマートメーターシステムにおけるクラウド活用方針まで」をご紹介致しました。後半については、「 寄稿：関西電力送配電株式会社におけるスマートメーターシステムのクラウド採用に向けた取り組みのご紹介(第 3 回) – 後半 」をご参照ください。 執筆者 松浦　康雄 関西電力送配電株式会社 執行役員（配電部、情報技術部） 2000 年代初期より、次世代配電網に適用する通信メディアの技術開発に携わり、 2010 年よりスマートメーターシステムの開発・導入プロジェクトを担当。 この経験を踏まえ、 CIGRE （国際大電力会議）にてスマートメーターのデータ利活用に関するワーキンググループを立ち上げて報告書をまとめるなど、スマートメーターシステムの全体像からデータ利活用にかかる論点を国内外の場で調査・発表し、脱炭素社会の実現、レジリエンス向上や効率化の実現に欠かすことのできない重要なキーデバイスとして、日本におけるスマートメーターの認知度向上に貢献。 2020 年には、資源エネルギー庁の声掛けのもと再開された次世代スマートメーター制度検討会に委員として参画し、次世代スマートメーターに求められる構造、機能や性能などについて、現行スマートメーター導入の経験や諸外国調査の知見を活かして議論をけん引。 2022 年度には、同社の現行スマートメーター全数導入を成し遂げるとともに、データプラットフォームとなり得る次世代スマートメーターシステム構想を描き、同社における検討を推進。 現在に至る。

はじめに 2023 年初頭の初回リリース以来、 AWS Systems Manager for SAP チームは SAP のお客様が AWS で SAP システムを管理できるように、お客様からのフィードバックに基づいてサービスの強化に取り組んできました。このブログでは、AWS Systems Manager Application Manager でリリースされた次の 2 つの機能強化について説明します。 AWS System Manager Application Manager コンソールによる SAP HANA データベースシステムの登録:AWS Systems Manager Application Manager コンソールが導入される前は、SAP HANA データベースシステムの登録と検出には AWS コマンドラインインターフェイス (CLI) を使用する必要がありました。AWS System Manager Application Manager コンソールを使用して、コマンドラインインターフェイスに加えて SAP HANA データベースへの運用アクティビティの登録と実行が可能になりました。これには、シングルノードと高可用性 SAP HANA データベースシステムの両方のサポートが含まれます。 AWS Systems Manager (SSM) for SAP と SSM アプリケーションレジストリーのアプリケーションタグ付けを統合すると、AWS Systems Manager Application Manager コンソールから SAP HANA アプリケーションのインサイトを確認できます。複雑な SAP ワークロードを実行している AWS のお客様は、SAP 自動化タスクの管理に苦労することがよくあります。多くのお客様が、オンプレミスでのデプロイから引き継いだツールやスクリプトを使用しており、これらのアプリケーションの管理と運用を一元的に管理してほしいという要望がありました。SSM Application Manager には、SAP アプリケーションの管理を容易にするためのこれらの 機能が備わっています 。AWS Systems Manager (SSM) for SAP と SSM アプリケーションレジストリーのアプリケーションタギングとの統合が開始されたことで、お客様は AWS Systems Manager Application Manager コンソールから登録された SAP HANA アプリケーションのアプリケーション詳細を表示できるようになります。この統合により、特定の SAP アプリケーションのコンテキストにおけるリソース、インスタンス、モニタリング、および推定コストに関する詳細が提供され、カスタマーエクスペリエンスが向上します。 概要 このセクションでは、AWS Systems Manager Application Manager コンソールで SAP HANA データベース (シングルノード及び高可用性) システムを簡単に登録する方法を示します。 前提条件 ここに記載 されているバージョン要件を満たす SAP HANA データベースシステム AWS Systems Manager for SAP ユーザーガイド の「はじめに」セクションに記載されているステップを完了しました。 AWS Systems Manager Application Manager コンソールによる SAP HANA データベースシステムの登録 リンク先 の AWS Systems Manager コンソールを開きます。 左側のナビゲーションペインで Application Manager を選択します。 Create Application を選択し、 Enterprise Workload を選択します。 Application name  (例:「HANADBHA」) を入力し、SAP HANA Database High Availability のように Application Description を入力します。 Browse instances を選択し、登録したい SAP HANA データベースのインスタンス ID を選択します。注:高可用性 SAP HANA データベースを登録するには、プライマリノードまたはセカンダリノードのインスタンス ID を選択できます。 登録する SAP HANA データベースシステムの SAP System identifer (SID) と SAP instance number を入力します。 HANA システムデータベースのセキュリティ認証情報を含む AWS Secretes Manager に保存されているシークレットの Secret ID を選択します。 テナントデータベースを追加するには、 Add credential を選択します。 テナントデータベース名を入力し、HANA テナントデータベースのセキュリティ認証情報を含む AWS Secretes Manager に保存されているシークレットのシークレット ID を選択します。 Create を選択します。 登録プロセスが完了するまでに約 3 ～ 5 分かかります。 登録が完了すると、登録が完了したことを知らせる緑色のメッセージバーがコンソールの上部に表示されます。 登録が完了すると、アプリケーションマネージャー画面に戻り、登録したアプリケーションが一覧表示されます。 アプリケーションの詳細を表示 登録したアプリケーションの詳細を表示するには、 Find Application でアプリケーション名を検索します。登録されたアプリケーションが一覧表示されたら、以下に示すようにリスト内のアプリケーション名を選択します。 Application Manager 画面でアプリケーションを選択すると、次に示すように、Application type, Application ID, Application source など、登録したアプリケーションの詳細が表示されます。Application Manager アプリケーションの操作方法や AWS リソースに関する運用情報の表示方法の詳細については、 アプリケーションの使用 を参照してください。 システムを構成するコンポーネントを確認するには、 Resources タブを選択し、Topology セクションまでスクロールします。 登録したシステムは高可用性システムなので、3 つのコンポーネントが登録されていることがわかります。 HDB – HDB00 = 論理データベースを表す親コンポーネント HDB – HDB00-sappridb = プライマリデータベースホストエンティティを表す子コンポーネント HDB – HDB00-sapsecdb = セカンダリデータベースホストエンティティを表す子コンポーネント *注-登録プロセスでは、プライマリデータベースのインスタンス ID を選択するだけで良く、セカンダリデータベースは AWS Systems Manager for SAP によって自動的に検出され登録されます。 特定のコンポーネントに関する追加情報を表示するには、コンポーネント名の左にあるラジオボタンを選択します。この例では、SAP HANA データベースバージョン、OS バージョン、SAP HANA System Replication モード、SAP ホスト名など、SAP Systems Manager for SAP によって登録されたセカンダリ SAP HANA データベースシステムの詳細を確認します。 Application Manager コンソールで SSM for SAP の設定が完了すると、さまざまなウィジェットが有効になっていることがわかります。まず、Overview タブから特定の SAP アプリケーションのダッシュボードを確認します。詳細については、 Register an application with AWS Systems Manager Application Manager を参照してください。 SAP アプリケーションを Amazon CloudWatch Application Insights とコストレポートにオンボードする アプリケーションのタグ付け機能により、SSM Application Manager は SAP アプリケーションを実行している特定の EC2 インスタンスにタグを適用できます。登録後は、SAP システムのログを SSM コンソールに追加するための追加の手動設定や追加の手順は必要ありません。インサイトを表示するには、SSM Application Manager の Monitoring タブから SAP アプリケーションを CloudWatch Application Insights にオンボードする必要があります。 以下の手順に従って、SAP application with CloudWatch Application Insights for SSM で SAP アプリケーションをオンボーディングします。 Application Manager コンソールで SAP アプリケーションを見つけて選択し、Application Details ビューに移動します。 Components ツリーで、アプリケーション名を選択します。 Monitoring タブの Application Insights セクションに移動し、 Add an Application ボタンを選択します。 これにより、 CloudWatch Application Insights の Add an Application widget ウィジェットが開きます。 Specify application details ページの Select an Application or resource group のドロップダウンリストから、SAP リソースを含む SSM for SAP アプリケーションの名前を選択します。 Monitor EventBridge events で、”integrate Application Insights monitoring with CloudWatch Events” チェックボックスを選択すると、通知や Amazon EBS、Amazon EC2、AWS CodeDeploy、Amazon ECS、AWS Health API, Amazon RDS、Amazon S3、AWS Step Functions から分析情報を取得できます。 Integrate with AWS Systems Manager OpsCenter で、 Generate AWS Systems Manager OpsCenter OpsItems for remedial actions の横にあるチェックボックスを選択すると、選択したアプリケーションで問題が検出されたときに通知を表示して受け取ることができます。お客様の AWS リソースに関連する OpSitems と呼ばれる運用上の作業項目を解決するために実行されるオペレーションを追跡するには、SNS トピック ARN を指定します。 Next を選択してモニタリングの設定を続行します。 表示されている特定の HANA データベースの箇条書きアイコンを選択します。  Review detected components ページでは、監視対象コンポーネントとそのワークロードが CloudWatch Application Insights によって一覧のように自動的に検出されます。 Next を選択します。  Specify component details ページで、HANA データベースのユーザー名とパスワードを入力します。 Next を選択します。 Review and submit でアプリケーション監視設定を確認し、 Submit を選択します。 アプリケーション詳細ページが開き、アプリケーションの概要、監視対象コンポーネントとワークロード、および監視対象外のコンポーネントとワークロードのリストを表示できます。設定を送信すると、アカウントが SAP アプリケーションのすべてのメトリクスとアラームをデプロイします。これには最大 2 時間かかることがあります。 Application Manager コンソールに戻り、お使いの SAP アプリケーションを見つけて選択し、アプリケーション詳細ビューの Monitoring タブに移動します。これで、アプリケーションインサイトの監視情報が表示されるはずです。 Monitoring タブでは、SAP アプリケーションからのアプリケーションインサイトとアラームを確認できます。 Instances タブ のスクリーンショットをご覧ください。 EC2 インスタンスには、自動的に追加された新しい AWS Application タグが付けられます。これにより、EC2 コンソールにアクセスしなくても EC2 インスタンスの停止などのアクションを実行したり、EC2 インスタンスの詳細を表示したりできます。 Compliance タブでは、コンプライアンス違反項目、保留中のパッチ、修正すべきランブックを確認できます。 Runbooks タブでは、選択した Runbook の実行ログとステータスを確認できます。Compliance、Opsitems、Runbooks などの一部のタブは、現在のバージョンでは SAP アプリケーションに対応していません。今後 SSMSAP が SSM AppManager とより緊密に統合されるときに、これらのタブを含める予定です。 Logs タブでは、CloudWatch から SAP アプリケーションのログにアクセスできます。 Cost タブでは、アプリケーションのコスト履歴とコスト傾向を調べたり、それに合ったコスト削減の推奨事項を受け取ったり、リソース支出を最適化したりできます。現在統合されている SSM for SAP 用 Cost Explorer では、HANA (シングルノード、HA) が稼働している基盤となる EC2 インスタンスに基づいてコスト計算を行うことができます。 結論 このブログでは、AWS System Manager Application Manager コンソールを使用して、コマンドラインインターフェイスに加えて SAP ワークロードで運用アクティビティを登録および実行する方法について説明しました。また、AWS Systems Manager (SSM) アプリケーションマネージャーコンソールを使用して、1 つの画面から SAP アプリケーションを管理および運用する方法についても学びました。SSM アプリケーションマネージャーと MyApplications には、SAP アプリケーションの管理を容易にするためのこれらの機能が備わっています。 SAP ワークロードの移行、近代化、革新において、何千ものお客様が AWS を信頼している理由については、 SAP on AWS ページ をご覧ください。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

(Source: MIXI, Inc) MIXI,Inc.(MIXI) has been providing MIXI M, a platform system & wallet service that offers authentication through payment in a one-stop manner, to consumers. On this occasion, MIXI implemented 3D Secure in MIXI M. 3D Secure is a mechanism that confirms the consumer’s purchase intention through additional authentication, realizing a more secure and safe online payment experience. The following is an visualization of the payment experience including 3D Secure from the consumer’s perspective. PCI 3DS (Payment Card Industry Data Security Standard) requires the use of an HSM (Hardware Security Module) certified to FIPS 140-2 Level 3 or higher, or PCI PTS certified for some key management. Therefore, AWS Key Management Service(KMS) could not be used previously, but it became compliant in May 2023 because the internal HSM of AWS KMS was upgraded to FIPS 140-2 Level 3 . There were no precedent cases of PCI 3DS compliance using AWS KMS at the customer’s planning stage. Through support from AWS, the design progressed with AWS KMS as the primary option instead of AWS Cloud HSM. The primary reason is that MIXI understand the advantages of utilizing AWS KMS and clear points of conversation with the PCI 3DS QSA (Qualified Security Assessor) became apparent. Reduction of compliance workload In case of using AWS, compliance responsibilities are shared between the user and AWS based on a shared responsibility model. The higher the level of abstraction of services used, such as managed services, the smaller the user’s responsibility scope and the more compliance work that can be offloaded to AWS. It was clear that using AWS KMS would reduce the amount of compliance work required compared to the initial plan to use AWS CloudHSM. This was beneficial as ongoing work is needed to maintain compliance after conforming to PCI 3DS. Reduction of operation workload In case of using AWS CloudHSM, the user needs to handle some backups of HSMs and cluster management themselves. With AWS KMS, as it is a managed service, everything can be left to AWS. As the customer actively adopts managed services that allow operation with few people, there was a major benefit to using the more managed AWS KMS compared to AWS CloudHSM. AWS SDK In case of using AWS CloudHSM, use of HSM standard SDKs like PKCS #11 or OpenSSL Dynamic Engine was needed for accessing keys. With AWS KMS, keys can be accessed using the familiar AWS SDKs, making development and testing easier. Ease of access control PCI 3DS has requirements for physical and logical access protection of keys. Physical access is AWS’ responsibility for both services, but logical access protection requires work from both the user and AWS. With AWS CloudHSM, protection must follow the HSM specifications, while with AWS KMS there was a benefit to being able to use key policies and the familiar AWS Identity and Access Management (AWS IAM) system that had been used previously. Running costs AWS CloudHSM uses hourly billing so HSM costs are incurred, meaning a minimum configuration of 2 units would cost around $3,400 per month, and adding extra units one by one is needed for scaling out. On the other hand, AWS KMS incurs costs by request, so payment can be made cost-effectively according to the number of requests. Therefore, it was possible to greatly reduce costs from what was originally estimated. Architecture We will introduce the architecture involved in implementing 3D Secure in MIXI M. The customer has been actively utilizing managed services like Amazon API Gateway in MIXI M previously, and also complies with PCI DSS. Operations that use keys managed by AWS KMS are executed via REST API. As long as it is within the request quota defined by AWS KMS, no additional work is incurred due to increases or decreases in access. VPC Endpoint is utilized to call the API through a private route. Changes to keys managed by AWS KMS and key usage can be checked via AWS CloudTrail. Logical access to AWS KMS is managed by key policies, and IAM users or IAM roles that can access keys can be limited from the key side. Voice of the Customer Fumitoshi Taoka (Development Head Office, MIXI M Business Division, MIXI Corporation) Compliance with PCI 3DS was unprecedented and highly challenging for MIXI. When we consulted our AWS account team, they instantly understood our needs and promptly set up a meeting with a security specialist. In the meeting, they provided a lot of useful information, which ultimately allowed us to respond to PCI 3DS compliance rapidly while ensuring security and reliability. Kosuke Asami (Development Head Office, MIXI M Business Division, MIXI Corporation) At MIXI M, a small team does full-stack development and operations, so reducing operation and development costs is always the top priority. By using AWS KMS, we were able to significantly reduce the operation costs required for PCI 3DS and focus on developing the 3D secure system. We fully utilize AWS’s fully managed services, and through that, we have reconfirmed that there are major benefits to reducing development and operation costs. Summary Our customer, MIXI, was able to keep operation costs low while achieving implementation of 3D secure and compliance with PCI 3DS by utilizing AWS KMS. Going forward, they aim to continue optimizing their architecture by leveraging the benefits of managed services, and advancing implementation of various features that will lead to improving their services. Authors Shuhei Akiyama (Game Solutions Architect) Tomohiro Nakashima (Senior Security Solutions Architect)

3月21日より、パッケージリポジトリの管理者は、新しい AWS CodeArtifact パッケージグループ設定機能を使用して、複数のパッケージの設定を 1 か所で管理できるようになりました。パッケージグループを使用すると、内部のデベロッパーによって、またはアップストリームリポジトリから、パッケージが更新される方法を定義できます。内部のデベロッパーによるパッケージの公開を許可またはブロックしたり、パッケージのグループについてのアップストリームの更新を許可またはブロックしたりできるようになりました。 CodeArtifact は、組織がアプリケーション開発に使用されるソフトウェアパッケージを安全に保存および共有することを容易にする、フルマネージドパッケージリポジトリサービスです。CodeArtifact は、 NuGet 、 Maven 、 Gradle 、 npm 、 yarn 、 pip 、 twine 、および Swift Package Manager などの人気のビルドツールやパッケージマネージャーで使用できます。 CodeArtifact は、 npmjs.com 、 maven.org 、 pypi.org などのパブリックリポジトリからのパッケージのオンデマンドインポートをサポートしています。これにより、組織のデベロッパーは、唯一の信頼できるソースである CodeArtifact リポジトリからすべてのパッケージを取得できるようになります。 シンプルなアプリケーションには通常、数十のパッケージが含まれています。大規模なエンタープライズアプリケーションには、何百もの依存関係が存在する場合があります。これらのパッケージは、ネットワークアクセス、暗号化機能、データ形式の操作などの一般的なプログラミングの課題を解決するコードを提供することで、デベロッパーが開発とテストのプロセスをスピードアップするのに役立ちます。これらのパッケージは、組織内の他のチームによって作成されたり、サードパーティーによって保守されたりする場合があります (例: オープンソースプロジェクト)。 サプライチェーン攻撃のリスクを最小限に抑えるために、一部の組織では、内部リポジトリで使用可能なパッケージと、これらのパッケージの更新を承認されたデベロッパーを手動で精査します。リポジトリ内のパッケージを更新するには 3 つの方法があります。組織内の選択されたデベロッパーがパッケージの更新をプッシュする場合があります。これは通常、組織の内部パッケージを使用する場合に当てはまります。パッケージはアップストリームリポジトリからインポートされる場合もあります。アップストリームリポジトリは、承認されたパッケージの全社的なソースや、人気のオープンソースパッケージを提供する外部パブリックリポジトリなど、別の CodeArtifact リポジトリである場合があります。 デベロッパーにパッケージを公開するさまざまな方法を示す図を以下に示します。 リポジトリを管理する場合、パッケージをダウンロードおよび更新する方法を定義することが重要です。例えば、外部のアップストリームリポジトリからのパッケージのインストールや更新を許可すると、組織は タイポスクワッティング 攻撃や 依存関係の混乱 攻撃にさらされます。有名なパッケージの悪意のあるバージョンを、わずかに異なる名前で公開しようとしている不正行為者を想像してみてください。悪意のあるパッケージは、 coffee-script ではなく、「f」が 1 つだけ含まれた cofee-script であるとします。 アップストリーム外部リポジトリからの取得を許可するようにリポジトリが設定されている場合、深夜まで働いている、集中力を欠いたデベロッパーが、 npm install coffee-script ではなく、 npm install cofee-script と入力してしまえばおしまいです。 CodeArtifact は、パッケージを更新する 3 つの可能な方法として 3 つの許可を定義します。管理者は、内部の publish コマンド、内部のアップストリームリポジトリ、または外部のアップストリームリポジトリからのインストールと更新を allow または block できます。 これまで、リポジトリ管理者はこれらの重要なセキュリティ設定をパッケージごとに管理する必要がありました。本日の更新により、リポジトリ管理者はパッケージのグループのために、これらの 3 つのセキュリティパラメータを一度に定義できるようになりました。パッケージは、そのタイプ、名前空間、および名前によって識別されます。この新しい機能は、リポジトリレベルではなくドメインレベルで動作します。これにより、管理者はドメイン内のすべてのリポジトリでパッケージグループのルールを適用できます。すべてのリポジトリで パッケージオリジンコントロール の設定を保守する必要はありません。 仕組みの詳細 私が CodeArtifact を利用して内部パッケージリポジトリを管理しており、私の組織によって精査済みの AWS SDK for Python ( boto3 とも呼ばれます) のバージョンのみを配布したいと考えているとします。 AWS マネジメントコンソール で CodeArtifact のページに移動し、精査済みのパッケージを内部のデベロッパーに提供する python-aws リポジトリを作成します。 これにより、作成したリポジトリに加えてステージングリポジトリが作成されます。 pypi からの外部パッケージは、まず pypi-store 内部リポジトリにステージングされます。ここで私は、 python-aws リポジトリに提供する前にこれらのパッケージを検証します。ここは、デベロッパーがこれらのパッケージをダウンロードするために接続する場所です。 デフォルトでは、デベロッパーが CodeArtifact に対して認証し、 pip install boto3 と入力すると、CodeArtifact はパブリック　 pypi リポジトリからパッケージをダウンロードし、それらを pypi-store にステージングして、 python-aws にコピーします。 ここで、CodeArtifact がアップストリームの外部 pypi リポジトリからパッケージの更新を取得するのをブロックしたいと考えているとします。 python-aws には、 pypi-store 内部リポジトリから私が承認したパッケージのみを提供してもらいたいと考えています。 本日リリースした新機能により、この設定をパッケージのグループに適用できるようになりました。自分のドメインに移動し、 [パッケージグループ] タブを選択します。その後、 [パッケージグループを作成] ボタンを選択します。 [パッケージグループの定義] を入力します。この式は、このグループにどのパッケージが含まれるのかを定義します。パッケージは、パッケージ形式、オプションの名前空間、名前という 3 つのコンポーネントの組み合わせを使用して識別されます。 許可された各組み合わせで使用できるパターンの例をいくつか次に示します: すべてのパッケージ形式: /* 特定のパッケージ形式: /npm/* パッケージ形式と名前空間のプレフィックス: /maven/com.amazon~ パッケージ形式と名前空間: /npm/aws-amplify/* パッケージ形式、名前空間、名前のプレフィックス: /npm/aws-amplify/ui~ パッケージの形式、名前空間、名前: /maven/org.apache.logging.log4j/log4j-core$ あらゆる可能性を知るために、 ドキュメント をぜひお読みください。 この例では、Python パッケージには名前空間の概念がありません。また、グループには pypi からの boto3 で始まる名前を持つすべてのパッケージが含まれるようにしたいと考えています。そのため、 /pypi//boto3~ と記述します。 その後、パッケージグループのセキュリティパラメータを定義します。この例では、組織のデベロッパーが更新を公開することを望んでいません。また、CodeArtifact が外部アップストリームリポジトリから新しいバージョンを取得することも望んでいません。内部ステージングディレクトリからのパッケージ更新のみを承認したいと考えています。 [親グループから継承] のすべてのチェックボックスをオフにします。 [公開] と [外部アップストリーム] で [ブロック] を選択します。 [内部アップストリーム] の [許可] をそのままにします。その後、 [パッケージグループを作成] を選択します。 一度定義すると、デベロッパーは、 python-aws リポジトリで承認されているものとは異なるパッケージバージョンをインストールできなくなります。デベロッパーとして別のバージョンの boto3 パッケージをインストールしようとすると、エラーメッセージが表示されます。これは、 boto3 パッケージの新しいバージョンがアップストリームステージングリポジトリでは使用できず、外部アップストリームリポジトリからパッケージやパッケージの更新を取得できないようにする block ルールがあるためであり、想定内のことです。 同様に、管理者が依存関係置換攻撃から組織を保護したいと考えているとします。すべての内部 Python パッケージの名前は会社名 ( mycompany ) で始まります。管理者は、 mycompany で始まる pypi.org パッケージからデベロッパーが誤ってダウンロードするのをブロックしたいと考えています。 管理者は、 /pypi//mycompany~ のパターンで、 publish=allow 、 external upstream=block 、 internal upstream=block を使用してルールを作成します。この設定では、内部のデベロッパーまたは CI/CD パイプラインはこれらのパッケージを公開できますが、CodeArtifact は、 mycompany.foo や mycompany.bar など、 mycompany で始まるパッケージを pypi.org からインポートしません。これにより、これらのパッケージに対する依存関係置換攻撃が防止されます。 パッケージグループは、 CodeArtifact が利用可能なすべての AWS リージョン で追加料金なしでご利用いただけます。これは、パッケージとパッケージの更新を内部リポジトリに配置する方法をより適切に制御するのに役立ちます。また、 タイポスクワッティング や 依存関係の混乱 など、さまざまなサプライチェーン攻撃を防ぐのにも役立ちます。これは、CodeArtifact リポジトリを作成および管理するために、Infrastructure as Code (IaC) ツールに今すぐ追加できる追加設定の 1 つです。 今すぐ最初のパッケージグループを設定しましょう 。 — seb 原文は こちら です。

本記事は、「 Event Recap: AWS news from Mobile World Congress 2024 」（2024年3月6日公開）を翻訳したものです。 Mobile World Congress (MWC) 2024 は、10 万人以上の出席者、2,700 社以上の出展者、スポンサー、パートナー、そして1,100 人のスピーカーとリーダーが参加しました。AI、収益化のオポチュニティ、およびクラウドが通信業界にもたらす変革などのトピックが深く議論されました。 「このイベントは、将来を展望し、AI、5G、API が新しい可能性をを示します。 GSMA Open Gateway のような共同イニシアチブを感謝します。」と GSMA のジェネラルディレクターである Mats Granryd は述べました。 AWS は、生成 AI、Network API、5G、Network Transformation などのトピックで、多数のお客様とパートナーのアナウンスメントを発表しました。20 以上の AWS デモを通じて、通信領域の変革、産業のデジタル化、消費者体験の改善におけるる AWS のイノベーションを見ることができました。AWS Recap ビデオをご覧ください。 MWC 2024 での AWS のハイライトをお届けします。 生成 AI は everywhere 通信事業者は、コストと効率の合理化、より良いユーザーエンゲージメント、革新的な新サービスを推進するために、人工知能（AI）、機械学習（ML）、生成 AI を期待しています。エンタープライズグレードのセキュリティとプライバシー、他種類の基盤モデル（LLM）の選択権、データファーストのアプローチ、パフォーマンスが高くコストが低いインフラストラクチャ、これら生成 AI によるイノベーションを加速するための要素を AWS が提供し、通信事業者から信頼を得られています。 MWC 2024 では、AI に焦点を当てたセッションが 40 以上あります。生成 AI は私たちが生きる、働く、そしてコミュニケーションする方法を変えようとしています。 BT グループ は、 Amazon Q のコーディングコンパニオン（ Amazon CodeWhisperer ）を活用し、ソフトウェアエンジニアに生成 AI コーディングアシスタンスを提供したと発表しました。このソリューションは既に、BT グループのアクティブユーザーごとに 1日あたり 15-20 のコード提案を提供しており、プラットフォームを使用するソフトウェアエンジニアによる受入率は 37% です。これは、生成 AI が提供できる価値、効率、およびサポートの素晴らしい例です。 Tele2 は、Internet of Things（IoT）ユーザーサポートソリューションに Amazon Bedrock を活用していると発表しました。このソリューションは AWS サービスを活用し、Tele2 IoT のユーザーサポートエージェントが複数のチャネルにわたる IoT ユーザーの問い合わせに対して、より迅速で詳細な回答に役立ちます。 Network API への関心は史上最高 Application Programming Interfaces（API）を受け入れることは、通信事業者が将来に備えた組織への変革の中心です。McKinsey は、Network API の市場が今後 5〜7 年間で、通信とエッジコンピューティングに関連して、通信事業者に約 100〜300 億ドルの収益をもたらす可能性があると推定しています。さらに API 自体から追加で 10〜30 億ドルの収益が生み出される可能性があります。 GSMA Open Gateway イニシアチブは、AWS を含む 21 のモバイルネットワークオペレーターとクラウドプロバイダーの支援を受けて、MWC 2023 で発表されました。それ以来、Open Gateway は 47 のオペレーターに拡大し、APIがネットワークのユニークな特性を公開することを利用して、革新的なユースケースやアプリケーションを構築したい開発者を引き付けています。 MWC 2024 に向けて、AWS は Verizon、Telefónica、T-Mobile、Orange、Liberty Global を含む世界中の通信事業者と協力して、 AWS 開発者に対し通信事業者のネットワーク API を提供する と発表しました。AWS 開発者は既に 240 以上の AWS サービスの数千の AWS API を使用していますが、ネットワーク API を活用しながら、 AWS Marketplace を通じてより多くの開発者やユーザーにお届けできます。多くのアプリケーションがAWS 上でテレコ API を活用して金融サービス、ゲーム、没入型体験を提供しています。採用が進むにつれて、世界中でより多くのオペレーターと協業していく予定です。 5G Future Forum（5GFF） のメンバーである Telstra、Verizon、Vodafone、Rogers、America Movil、KT、および Bell Canada は、AWS との協力のもと、エッジコンピューティング（MEC）インフラストラクチャ統合およびアプリケーションを促進するために、通信事業者とクラウドプロバイダー間の双方向 API の役割を定義するホワイトペーパーを発表しました。 Vonage は、新しいソリューションの提供を加速するために AWS とのコラボレーションを発表しました。詐欺対策ソリューションを最初のソリューションとして提供します。AWS の生成 AI サービスは、ソリューションの詐欺検出能力を強化し、モバイル詐欺から自身をより効果的に保護しつつユーザー体験を改善することを可能にします。 通信業界におけるネットワーク変革 世界中の通信事業者は、クラウドの経済性、拡張性、および俊敏性を活用してネットワークを変革し、より重要なことにフォーカスすることができます。これには、通信事業者のコアネットワークの変革、投資の収益化、産業のデジタル化、消費者体験の改善、レジリエンスとセキュリティの向上が含まれます。 8,900 万人以上の加入者を持つ日本の主要なモバイルオペレーターである NTT DOCOMO は、日本全国で 5G オープン無線アクセスネットワーク（RAN）の商業展開に AWS を選びました。DOCOMO は、コンテナ管理ソフトウェアである Amazon Elastic Kubernetes Service Anywhere を 5G オープン RAN に展開し、自動化されたクラスタ管理ツールを使用することによってネットワークオペレーションを簡素化します。そして、AWSは、NTT DOCOMO のハイブリッドクラウド環境での 5G コアの開発を支援しています。 TELUS は、Samsung Electronics および AWS との新しいコラボレーションを発表しました。北米でローミングのアーキテクチャを進化させる最初の通信事業者になることを目指して、海外旅行のユーザーにより高い信頼性と高速のローミングサービスを提供します。一方、欧州では、スイスの通信事業者である Sunrise Business が、スイスの中小企業のクラウド化を加速するために AWS と協力していると発表しました。 ラテンアメリカでは、 Beyond ONE / Virgin Mobile が、地域の通信セクターにおける成長とイノベーションを推進するために AWS と協力していると発表しました。Virgin Mobile は、 AWS Regions と AWS Outposts および AWS Local Zones を含む AWS ハイブリッドクラウド技術の組み合わせを使用して、Beyond One スタックをモダナイズし、地域におけるクラウド採用とデジタル変革における重要な一歩を記します。 以下で他の発表についてもご覧ください。 Women in Tech AWSはテクノロジー分野における多様性を推進し、女性のテクノロジー分野でのキャリアを支援しています。 GSMA によると、MWC 2024 は 26% の女性参加者が参加し、1,100 人のスピーカーのうち 40% が女性でした。今年、AWS はテレコム業界における女性が直面する機会と課題についてのパネルディスカッションを主催し、AWS エグゼクティブレセプション中にテレコムエコシステム全体にわたる多様性へのコミットメントを強化しました。 デモ 今回の MWC 2024 では、AWS は 3つの主要なテーマを通じて、20 以上のデモを展示しました。 1/ 通信事業の変革 このエリアのデモは、CSP のネットワーククラウド化（RAN、Core、IMS、OSS/BSS など）のジャーニーにフォーカスします。統合的な自動化、オーケストレーション、および生成型 AI ツールチェーンの活用により、新たな成長機会の創出、OPEXの削減、持続可能性の向上、およびレジリエンスの強化を実現しています。reCap のビデオをご覧ください： 例として、Samsung Cloud RAN は、Amazon Bedrock および Anthropic Claude v2 とともに Amazon Bedrock Agents を使用して、AIを用いた RAN 設定チューニングを実現し、最大 25% のパフォーマンス向上を達成できました。 2/ 産業のデジタル化 このエリアのデモでは、AWS がいかに通信事業者を支援し、医療、製造、旅行およびホスピタリティ、金融サービスなどの産業をデジタル化しているのかを示しています。これは、プライベートネットワークソリューション、Network API、パブリック MEC などの通信サービスの革新、ビジネスモデルの革新を通じて実現しています。reCap のビデオをご覧ください： AWS、Accenture、および Verizon は協力し、製造業で 5G の価値を示すために、オンプレミス 5G およびプライベートモバイルエッジコンピューティング（MEC）を展開しました。AWS は Jabil の製造施設で、組み立てラインの異なる場所でのライブストリームカメラの映像を、 AWS Snowball Edge に転送し、コンピュータビジョンのモデルで処理される新しいソリューションを展開しました。このソリューションは、組み立てラインの不良ユニットの誤検出率を 95% 削減しました。 3/ 消費者体験の改善 このエリアのデモは、AWS が通信事業者および ISV と共同開発しているいくつかの革新的なソリューションを紹介しています。これらのソリューションは面白く、スマートで、パーソナライズされた消費者体験につながります。 私たちの SmartHome+ デモでは、TELUS との協力により、AWS 生成 AI、 AWS IoT Core 、および Alexa Voice Services を活用しています。このデモは、TELUS が消費者とのインタラクションを変革し、高度な接続性とAIの時代においてスマートソリューションを拡大していることを示しています。 MWC 2024 に参加しましたか？ AWS for Telecom をフォローしていただければ、今年のイベントのハイライトや、最新のニュースをチェックすることができます。 Mobile World Congress 2025 でお待ちしております！ MWC 2024 における AWS の発表 概要 AWSは、AI-RAN Alliance への参加を発表しました。 AI-RAN Alliance はモバイル通信技術にAIを統合し、無線アクセスネットワーク（RAN）技術とモバイルネットワークを進化させることを目的とした新しい協業イニシアチブになります。 Canonical は、AWS との協業を拡大し、Amazon EKS Anywhere のユーザーが オープン RAN の商用展開で使用するリアルタイム Ubuntu をサポートすることを発表しました。 Unmanned Life は、Liberty Global および AWS とのデジタルトランスフォーメーションにおける GSMA Foundry Excellence Award を受賞しました。受賞したユースケースは、アントワープ港での U-Security の展開であり、Liberty Global の Telenet を通じたドローン接続のためのスライスされた 5G ネットワークと、AWS Snowball Edge デバイスを介したエッジでの AI コンピュータビジョン分析を活用しています。 生成 AI Amdocs は AWS と協業して新しいソリューションを開発しました。Amazon Bedrock でホストされる Anthropic の Claude モデルは、ネットワークデータと Amdocs のアルゴリズムによって生成された洞察にアクセスし、情報の抽出、要約、データのリアルタイム集約などのタスクを実行します。 BT グループ は、Amazon Q のコーディングコンパニオン（CodeWhisperer）を展開し、ソフトウェアエンジニアに生成 AI コーディング支援を提供したと発表しました。このソリューションは既に、BT グループのアクティブユーザーごとに 1日あたり 15-20 のコード提案を提供しており、プラットフォームを使用するソフトウェアエンジニアによる受入率は 37% になります。最初の4ヶ月間で Amazon Q によって生成されたコードは 100,000 行を超えており、退屈で繰り返しの多い時間のかかる作業の約 12% を自動化しています。BTグループは現在、ビジネス全体で 1,200 人のエンジニアにこのソリューションを広げています。 CelcomDigi は、AWS とのコラボレーションを発表しました。Amazon Bedrock を利用し、従業員が生成 AI ソリューションの実験、革新、実装するための AI サンドボックスを設立します。これには、人事、カスタマーサービス、法務、財務など、CelcomDigi の運用プラットフォームに統合される可能性のあるユースケースが含まれます。 Maxis は、マレーシアのエンタープライズ顧客向けの生成 AI および 5G ユースケースの分野で、イノベーションを加速するための新しい AWS とのコラボレーションを発表しました。Maxis はこれにより、AWS の先進的な機械学習機能を活用し、AI モデルを大規模に構築、トレーニング、およびデプロイして、人工知能の可能性を繰り広げていきます。 MYCOM OSI は、Amazon Bedrockを使用して構築された新しい生成 AI ベースのエキスパートアプリケーションコンセプト、Experience Assurance and Analytics (EAA) GenAie を発表しました。これは、CSP のフロントラインの運用チームとビジネスチームが複雑なネットワークおよびサービスの問題を支援します。データを民主化し、運用コストを削減し、顧客体験を改善することを可能にします。 Snowflake は、AWS と協力して通信分野を変革し、技術的な業務クエリの解決を数日から数分に短縮していることを発表しました。AWS は Snowflake と協力して GenTwin を構築しました。これは、プライベート5G、Amazon Bedrock を活用した生成 AI、および AWS IoT TwinMaker を活用したデジタルツインの組み合わせで、革新的なネットワークオペレーションソリューションです。業界に前例のない効率化、自動化、および適応性を提供し、ネットワーク運用に変革的な時代の幕開けを告げています。 Tele2 は、Amazon Bedrock を活用した IoT ユーザーサポートソリューションを立ち上げると発表しました。このソリューションは AWS サービス活用し、2023 年末の Tele2 IoT Talks でユーザーに披露されました。これにより、Tele2 IoT のユーザーサポートエージェントは、複数のチャネルにわたる IoT ユーザーの問い合わせに対して、より迅速で詳細な回答を提供できるようになります。 ネットワーク変革 AWS は、Verizon、Telefónica、T-Mobile、Orange、Liberty Global などの通信事業者と共に、 AWS の開発者に対し通信事業者の Network API を提供する と発表しました。AWS 開発者は既に 240 以上の AWS サービスの数千の AWS API を使用しており、これにより開発者は通信事業者の API にもアクセスし、AWS Marketplace を通じてより多くの開発者やユーザーにサービスをお届けします。 Beyond ONE/Virgin Mobile は、地域の通信分野における成長とイノベーションを推進するために AWS との協業を発表しました。Virgin Mobile は、AWS Regions と AWS Outposts および AWS Local Zones を含む AWS のハイブリッドクラウドソリューションの組み合わせを使用して、Beyond One スタックをモダナイズし、地域におけるクラウド採用とデジタル変革における重要な一歩を記します。 BICS は、AWS と協力して新しいクラウドベースのローミングサービスを立ち上げ、国内外で旅行している際に、より速く、より信頼性の高いインターネットアクセスを提供し、モバイルローミング体験を向上させます。BICS は、そのローミング接続プラットフォームを AWS のグローバルインフラストラクチャに移行することにより、従来の国際モバイルローミングサービスよりも最大 5倍 速くローミングインターネット接続を提供することができます。 Casa Systems は、無線と有線の融合（wireless wireline convergence: WWC）における画期的な取り組みを発表しました。Casa の仮想 5G コアの制御プレーン機能を AWS Region に展開し、Casa の仮想化アクセスゲートウェイ機能（AGF）と 5G コアのユーザープレーン機能をプライベートクラウドで展開しました。この取り組みは、通信におけるクラウドネイティブネットワークソリューションの成長を示しています。 Clear Mobitel と NEC Corporation は、AWS 上に構築された NEC の最先端の 5G スタンドアローン（SA）クラウドネイティブコアネットワークソリューションの英国での展開に成功したと発表しました。 Finetwork は、エンドユーザーに対してファイバー、TV、モバイルサービスを含むトリプルプレイオプションをより柔軟で費用効果の高い方法で提供できるようにするために、Amdocs を選び、コアビジネスシステムを変革します。AWS 活用した Amdocs AI ベースの Digital Brands Suite as a Service は、Finetwork のオファリングを強化し、エンドユーザーによりシンプルなデジタルカスタマーエクスペリエンスを提供することを可能にします。 8,900 万人以上の加入者を持つ日本の主要なモバイルオペレーターである NTT DOCOMO は、日本全国で 5G オープン無線アクセスネットワーク（RAN）の商用展開に AWS を選びました。DOCOMO は、コンテナ管理ソフトウェアである Amazon Elastic Kubernetes Service Anywhere を 5G オープン RAN に展開し、自動化されたクラスタ管理ツールを使用することによってネットワークオペレーションを簡素化します。そして、AWSは、NTT DOCOMO のハイブリッドクラウド環境での 5G コアの開発を支援しています。 NTT DOCOMO は、NEC、AWS、および Red Hat、Qualcomm、Hewlett Packard Enterprise、Dell Technologies の組み合わせによるさらなるオプションを追加したと発表しました。 NTT DOCOMO & OREX は、AWS が OREX パートナーグループに参加したと発表しました。コンテナ管理ソフトウェア、オートメーションフレームワーク、およびオープン RAN ライフサイクル管理を含むエンドツーエンドの オープン RAN クラウドプラットフォームソリューションを提供します。 Omantel は、オマーンのためのソブリンクラウドを作成するために AWS との協力を発表しました。この戦略的関係の目標は、特にオマーンの政府機関や規制産業におけるデータ所在地とセキュリティ要件に対処することです。Omantel は、AWS と協力してクラウドセンターオブエクセレンス（CCoE）を立ち上げ、オマーンの組織がクラウドへの移行を成功させるためのトレーニング、エネーブルメント、およびサポートを提供します。さらに、AWS は Omantel がデジタル変革を追求する際の優先クラウドプロバイダーとなります。 Qvantel は、Etisalat Misr by e& と契約し、AWS Outposts 上で実行される Qvantel Flex BSS ソリューションを実装して、Etisalat BSS のデジタル変革を支援します。 Red Hat は、通信サービスプロバイダーがハイブリッドクラウドで 5G の採用と展開を加速し、管理を容易にするためのコラボレーションを発表しました。Tech Mahindra の Multi-mode Companion Cloud with Red Hat OpenShift は、AWS 上で実行され、RAN、エッジコンピューティング、トランスポート、5Gコアにまたがる複数のハイブリッドクラウドでのネットワークユースケースをサポートします。 Samsung は、AWS との画期的なコラボレーションを通じて 5G イノベーションを牽引します。仮想化ネットワークの未来を垣間見せ、次世代サービスと機能のさまざまな要求を満たすための革新的な道と改善された能力を提供しています。 Sateliot は、Kongsberg Satellite Services (KSAT) 商用ネットワークである KSATlite を介して、5G サービスメッセージング接続を達成したと発表しました。AWS を使用して、Sateliot は完全に仮想化されたクラウドネイティブの 5G コアを Narrowband (NB)-IoT Non-Terrestrial Networks (NTN) 用に構築し、Sateliot のエンドツーエンドサービスをサポートする柔軟で低コストで超スケーラブルなナローバンドソリューションを提供します。 スイスの通信事業者の Sunrise Business は、スイスの中小企業のクラウド化を加速するために AWS との協業を発表しました。Sunrise Business のユーザーは事前定義済みのモジュール化の製品パッケージからベネフィットを得られます。この製品パッケージは、中小企業の要件に合わせてクラウドと通信機能を提供します。この新サービスは、Amazon Simple Storage Service (Amazon S3)、Amazon Elastic Compute Cloud (Amazon EC2)、および AWS Storage Gateway などの AWS サービスをベースに構築されています。 Telstra は、AWS および Nokia との世界初のコラボレーションで、Nokia の IP マルチメディアサブシステム（IMS）のハイブリッドネットワークアーキテクチャの耐久性検証を発表しました。この IMS 検証では、特にネットワークの信頼性、耐久性、およびユーザー体験の向上を目指した AWS との長期的な戦略関係に基づいています。 TELUS は、Samsung Electronics および AWS との新しいコラボレーションを発表し、北米で初めてローミングのアーキテクチャを進化させます。海外旅行中のユーザーにより高い信頼性と高速なネットワークを提供する通信事業者になることを目指します。TELUS は、仮想化されたローミングゲートウェイを使用し、世界中の AWS リージョン内に自社のネットワークを収容することができます。これにより、トラフィックはカナダを経由する必要はなく、TELUS のネットワークを収容している最も近い AWS リージョンに直接ルーティングされ、モバイルサービスの速度と応答性が大幅に向上します。 Verizon Business と Audi AG は新しいパートナーシップを発表しました。ドイツのノイシュタットにある Audi 自動車の試験トラックで最先端のプライベートワイヤレスネットワークと技術テスト環境を構築します。Audi の試験トラックは、5G および LTE のデュアルモジュラープライベートワイヤレスプラットフォーム（Nokia）、プライベートマルチアクセスエッジコンピュート（MEC）機能（AWS）、リアルタイムビデオおよびデータ伝送技術（Smart Mobile Labs）、C-V2X 通信、および音声、データ、自動運転、安全性などをカバーするモバイル/自動車アプリケーションで実装されます。 Vodafone Ireland は、AWS 上の Celfocus BSP の成功展開を発表しました。プロジェクトの主な目的は、AWS が選ばれたクラウドプロバイダーとして、クラウドへの移行における可用性、耐久性、スケーラビリティの要件を確保し、将来の BSP ロードマップへの展開の入り口になります。 Vonage は、AWS とのコラボレーションを発表し、新しいソリューションの提供を加速します。最初のソリューションは、詐欺対策ソリューションであり、AWS の生成 AI サービスを活用することにより、詐欺検出機能を強化します。ユーザーがモバイル詐欺から自身をよりよく保護しつつユーザー体験を改善することを可能にします。 ネットワーク収益化 2degrees は、MVNO およびデジタルブランド市場への卸売ビジネスをモダナイズ化するために Totogi を選択しました。これは、ユーザー、コミュニティ、および環境への 2degrees の継続的なコミットメントの一環であり、MVNO ブランドを繁栄させるための software-defined offering になります。Totogi が選ばれた理由として、Totogi の Charging-as-a-Service（CaaS）は、AWS の AI サービスの Amazon Bedrock および機械学習（ML）サービスの Amazon SageMaker を使用して構築され、迅速なオンボーディングとMVNO ユーザーに対する効率的なサービスを提供できます。 5G Future Forum（5GFF） のメンバーである Telstra、Verizon、Vodafone、Rogers、America Movil、KT、および Bell Canada は、AWS との協力のもと、エッジコンピューティング（MEC）インフラストラクチャ統合およびアプリケーションを促進するために、通信事業者とクラウドプロバイダー間の双方向 API の役割を定義するホワイトペーパーを発表しました。 DigitalRoute、Intraway Symphonica、および Totogi は、Trektel のもとに 、AWS と協力してモバイル仮想ネットワークオペレーター（MVNO）in-a-box ソリューションを導入しています。業界の go-to-market の能力強化が狙いとなります。 Ericsson は、Wipro と協力し、AWS 上で ODIDO の Billing インフラストラクチャのモダナイズ化と発表しました。ODIDO のモバイル仮想ネットワークオファリング（MVNO）である Ben の全加入者が、AWS上でホストされる Ericsson Billing への移行に成功しました。 Intel は、AWS との継続的な連携により、ユーザーがバーティカルマーケットにおけるプライベートネットワークの加速を支援すると発表しました。最新の事例として、Integrated Private Wireless（IPW）on AWS プログラムのシステムインテグレーターとして Amdocs が追加されました。このプログラムを通じて、AWS のユーザーは、エンドツーエンドの Amdocs Mobile Private Network（MPN）サービスにアクセスし、Intel® Xeon® プロセッサが入る AWS Outposts サーバー上に構築されたインフラストラクチャを利用することが可能になります。 Liberty Global は、AWSとの協力で、Network-as-a-Service（NaaS）フレームワークを作成すると発表しました。開発者がイノベーションのために、NaaS を通じて、Liberty Global の固定およびモバイルネットワークにアクセスできます。Liberty Global の通信ネットワークと AWS のグローバルクラウドインフラストラクチャおよび既存の開発者エコシステムの組み合わせを活用して、NaaS ならではの魅力的なユースケースを開発することを目指しています。 著者について Chivas Nambiar Chivas Nambiar は、アマゾン ウェブ サービス (AWS) の Global Telecom Business Unit のゼネラルマネージャーです。 彼は、通信事業者、ネットワーク機器プロバイダー、ISV がクラウドに移行してビジネス変革を支援する世界規模のチームを率いています。 彼のチームは、クラウドの積極的な導入を推進し、コスト削減を実現し、ビジネスの俊敏性を高め、イノベーションを加速し、世界中のさまざまな通信ドメインにわたって新しいビジネスチャンスを創出してきました。 Chivas は熟練なエンジニアでありながら、チームを構築し、顧客やパートナーと協力してイノベーションを加速することに情熱を注いでおり、電気通信業界の変革に専念しています。 2020 年に AWS に入社する前は、Verizon Communications 社で通信業界に 17 年間勤務しました。彼の最後の役職では、クラウドおよびプラットフォーム エンジニアリングの担当エグゼクティブ ディレクターとして、Verizon の広範な IT およびネットワーク システム ポートフォリオから 1,000 を超えるビジネス クリティカルなアプリケーションをパブリック クラウドに移行する取り組みを主導しました。 以前の職務では、Chivas はグローバルな 24 時間年中無休の運用チームと、Voice Over IP (VoIP) および Wi-Fi 製品の開発と実装に取り組むエンジニアリング チームを運営していました。 Chivas は仕事がないときは、水が大好きな子どもについていくために水泳を習い、大家族の集まりのためにグリルを楽しんでいます。 翻訳はソリューションアーキテクトの陳誠が担当しました。

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 このブログでは、昨年末のAWS re:Invent 2023 で発表された新機能・Knowledge Bases for Amazon Bedrock を活用して、設計開発や研究における特許検索を効率化する方法について解説します。 はじめに　過去の関連ブログ 前々回、 こちらのブログ で、AWS の生成系 AI サービス・ Amazon Bedrock の Claude v2 ( by Anthropic 社) モデルを指定して、 Playgrounds のチャット機能を手軽に使用し、設計開発ドキュメントを効率的に作成する方法について解説しました。 前回、 こちらのブログ で、Amazon Bedrock の Stable Diffusion XL v0.8 ( by Stability AI 社) モデルを指定して、 Playgrounds の画像生成機能を手軽に使用し、新規プロダクト開発において意匠を文章から作るような、企画構想を充実させる方法について解説しました。 Knowledge Bases for Amazon Bedrock について Knowledge Bases for Amazon Bedrock を使用すると、 Amazon Bedrock 内から 基盤モデル をデータソースに接続して 検索拡張生成 (RAG) を行うことができます。 RAG は、プライベートデータの使用と基盤モデルを組み合わせた技術です。仕組みを理解するために、 Amazon Bedrock のチャット機能 と比較します。まずチャット機能のイメージ図です。 次に、Knowledge bases for Amazon Bedrock （RAG）のイメージ図です。 上のレーンの流れを説明します。①データソースから②ドキュメントを管理しやすいチャンク（通常2〜8語程度からなる意味を形成する塊）に分割し、③ Embedding （埋め込み：テキストを言語モデルが処理しやすい数値ベクトル表現に変換する）を生成し、④埋め込みを ベクトルDB に格納します。 下のレーンでは、水色の箇所が通常のチャット機能と共通する部分になりますが、⑤ユーザーの問い合わせに対して上のレーンと同様に Embedding を生成し、⑥ベクトル DB と照らし合わせて似たドキュメントを検索した上で、検索結果を加味して Text モデルが回答生成し、ユーザーに回答します。 これによって、例えばデータソースを社内ストレージに指定することで世に出ていない自社固有の回答をセキュアに生成したり、または外部の信頼できる知識ベースから事実を検索して、最新の正確な情報に基づいて回答を生成することが可能になります。 Knowledge Bases for Amazon Bedrock を使用することで、RAGの機能がコード不要で、Amazon Bedrock のマネージドな機能で簡単に実現でき、エージェントの構築時間を短縮できます。また、ナレッジベースを追加することで、プライベートデータを活用できるようにモデルを継続的にトレーニングしたりする必要がなくなるため、費用対効果も向上します。 なお、本ブログの内容は2024年3月21日時点の内容に基づいて執筆しています。執筆段階では東京リージョンにおいては Knowledge Bases for Amazon Bedrock は利用できません。 現時点で Knowledge Bases for Amazon Bedrock が利用できる北米のバージニア北部リージョンで試行を行います。また、 Amazon Bedrock は日々進化しており、執筆段階ではできなかったことも、ブログを読んでいただいた時点ではできるようになっている場合もありますのでご注意ください。 取り組む内容 今回のテーマは設計開発における特許検索です。特許を検索する際の主な課題は以下のようなものがあります。 特許の内容は一見難解であることが多いため、解釈が難しい 新規発明案に対して、既に類似の特許が出願されているかを調べるのが困難 こういった課題に対して、Knowledge Bases for Amazon Bedrock を活用して、特許データが保管されているデータソースを対象として RAG を実行することで解決を試みましょう。 Knowledge Bases for Amazon Bedrock のデータソースは現状、 Amazon S3 が指定できるようになっています。Amazon S3 に検索対象のデータを保管しますが、例えばもし世の中に存在する全ての特許ファイルを保管してしまうと、データ保存コストやベクトル DB を作成するコストが大幅に上がってしまうため、例えば関連する大きなテーマで絞り込むなどして、RAG を行う目的に応じて適切な特許ファイルを保管するようにしましょう。 Knowledge Bases for Amazon Bedrock の使用にあたって発生する料金については以下関連サービスの料金ページをご参照ください。 Amazon Bedrock Amazon S3 Amazon OpenSearch Serverless 今回はサンプル題材として、筆者が過去に発明した以下の特許3件を対象に、Bedrock で実現した RAG の仕組みに取り込みます。PDF ファイルをダウンロードして Amazon S3 に保存 します。 JP2013174393A JP2013174394A JP2014194291A 実行方法 まずマネジメントコンソール上部の検索バーで、「bedrock」などと打ち込んでいただくと、 Amazon Bedrock が候補に表示されます。クリックしてサービス画面に移行してください。 サービス画面に移行すると、画面左に オーケストレーション という項目が表示されます（※初回アクセス時はペーンが表示されておらず「Get started」ボタンを押す必要がある場合があります）ので、配下にある ナレッジベース 機能にアクセスしてみましょう。これが Knowledge Bases for Amazon Bedrock になります。 ここからページ下部にあるオレンジ色の「ナレッジベースを作成」をクリックします。 まずナレッジベース名を入力します。識別しやすい名前をつけてください。 画面下部にある IAM 許可については、「新しいサービスロールを作成して使用」を選択します。サービスロール名は自動的に付与されたもので構いません。 「次へ」を押すと、データソース設定ステップに進みます。 ここではデータソース名を入力します。ナレッジベース名のときと同様、識別しやすい名前をつけてください。 また、RAG のデータソースとなる S3 の URI を指定します。今回のサンプル題材である特許 PDF 3ファイルが保存された S3 バケットのURIを指定します。PDF ファイルを S3 バケットに保存する方法はこちらをご参照 ください。なお、Knowledge Bases for Amazon Bedrock は 次のファイル形式 をサポートしています。 「次へ」を押すと、埋め込みモデルの選択画面に進みます。埋め込みモデルは、RAG のイメージ図のところで説明した Embedding モデルに相当します。ここでは、Amazon が提供する Titan Embeddings G1 – Text モデルを選択します。このモデルは、テキスト検索や、テキスト間のセマンティック類似性の測定、クラスタリングなどのユースケースに活用ができ、日本語もサポートされています。 画面下のほうにあるベクトルデータベースについては、「新しいベクトルストアをクイック作成」を選択します。 「次へ」を押すと、確認して作成ステップに進みます。これまでのステップでの設定をあらためて確認し、一番下にあるオレンジ色の「ナレッジベースを作成」ボタンを押すと、ベクトルデータベース作成、ナレッジベース作成が自動的に開始されます。作成が完了したら、「同期」ボタンを押します。データソースの同期が完了するまでに要する時間はデータ量によりますが、今回のような サンプル題材 PDF 3ファイルの場合は、筆者のネットワーク環境では数秒ですぐに完了しました。 今後、例えばデータソース内の PDF ファイルが新たに100個追加された場合など、更新があったときは同様にデータ同期を実施すると RAG のデータソースが都度更新されることになります。 データソース同期が完了すると、ナレッジベースをテストすることができます。画面右側にあるオレンジ色の「モデルを選択」をクリックします。ここでいうモデルは、 RAG のイメージ図のところで説明した Text モデルに相当します。 候補として提示された基盤モデルの中から選択しますが、ここでは Anthropic 社の Claude の中で最新バージョンの v 2.1 モデルを指定します。 わずかこれだけの前準備で Knowledge Bases for Amazon Bedrock が使用可能な状態になりました。 特許検索における課題への対応 それでは、特許検索における以下課題にどのように対応できるかを見ていきましょう。 課題1 「特許の内容は一見難解であることが多いため、解釈が難しい」 今回のサンプル題材の3つはいずれも極低温冷凍機という一般の方には馴染みが薄いプロダクトを対象としています。その中の一つ、たとえば、 JP2013174393A の文章を見てみますと、馴染みが薄い方には文意を読み取るのが難しいかもしれません。発明者の私ですら正直理解するのが困難です。 そこで、Bedrockに対して以下のような質問を投げてみましょう。以下画像のメッセージ入力欄に質問を書き、オレンジ色の実行ボタンを押します。 Bedrockへの質問「特許JP2013174393Aについて。この特許はどのような内容で、どのような点に新規性、進歩性があるのか、中学生にもわかる言葉で簡潔に説明してください。」 すると、以下画像の紫枠のように、回答を返してくれました。 極低温冷凍機がどういう原理で動作しているかや、特許要件として重要な要素である新規性・進歩性は「弾性手段」を設けてモータ負荷を軽減する工夫を取ったところにあるということが簡潔に要約されました。 また、回答文の中に[1]、[2]といったリンクが付いています。[1]、[2]は回答の元になった文書を指しており、これによって、ファイル内の広範囲に及ぶ情報の中のどの箇所を根拠として回答したかが明らかになり、ユーザーは回答の信頼性を簡単に確認できます。 課題2 「新規発明案に対して、既に類似の特許が出願されているかを調べるのが困難」 自分の思いついた発明内容は既に他人によっても発明されており、特許取得されていたというのはよくあるケースです。手戻りの無駄が発生することを防ぐために、以下のようなRAGを使って類似特許を確認する事前確認を取りましょう。 例えば、極低温冷凍機に関する以下のような発案をした場合です。 Bedrockへの質問「モーターの回転運動を往復運動に変換するネジ螺合駆動形式の極低温冷凍機を発案しました。これによって従来の形式よりも機構部分の部品点数が少なくコストが低くできます。これと内容が重複する既存特許はデータソースの中にありますか？」 これに対しても課題1のときと同様の形式で以下回答を返してくれました。 Bedrockからの回答「はい、データソースの中に本発明と内容が重複する既存特許があります。[1] [2] [3] [4] [5] 特許文献1から5は、モーターの回転運動を螺合機構(ネジ機構)によってディスプレーサの往復運動に変換する極低温冷凍機に関するものであり、本発明と同様に機構部分の部品点数が少なくコストが低減できることが記載されています。[6] [7] [8] [9] [10] 」 これはデータソース内にある JP2013174394A という特許を指します。 このような形で、概要のような曖昧な文章からでも類似特許を検索でき、重複を指摘してくれます。今回はサンプル題材3ファイルをデータソースに保存しただけですが、データが膨大になるほどより効果を発揮します。 ただし、プロンプト（質問文の書き方）によっては似たような特許が存在するにも関わらず検索されない場合もあります。プロンプトが望ましい形で書かれていた場合であっても、 出願するにあたっての判断のためには弁理士など専門家によるチェックを依頼することを推奨します。 また、今回のような利用方法をする場合には、著作権など法的な問題がないことをご確認のうえ実施いただきますようお願いします。 まとめ いかがでしょうか。今回は特許検索を題材としましたが、取り扱った二つの課題解決応用以外にも、データソース内にある特許を組み合わせて新たな発明を検討するような使い方をするなど、他にも様々な活用アイデアが考えられると思います。 また、特許検索以外にも、社内文書をデータソースにした RAG は多種多様なユースケースが考えられます。例えば、自社製品の設計過去トラブル集をデータソースとし、新規製品の設計を行うに当たって困っている検討箇所があった場合に、注意すべき点を問いかけて、該当する過去の失敗事例やその解決策を提示してもらう、などが考えられます。 新機能の Knowledge Bases for Amazon Bedrock を活用して、少ない前準備で手軽に RAG を実施し、業務を効率化させていきましょう。 著者プロフィール 山田 航司  (Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Transcribe です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。