AWS Amplify ホスティング と Amazon Simple Storage Service (Amazon S3) の統合を発表します。これにより、数回クリックするだけで、S3 バケットに保存されたコンテンツを使用して静的ウェブサイトをデプロイし、コンテンツ配信ネットワーク (CDN) 経由で配信できるようになりました。 AWS Amplify ホスティングは、静的サイトをホスティングするためのフルマネージド型サービスで、ウェブサイトのデプロイのさまざまな側面に対応しています。また、SSL を使用したカスタムドメイン設定、リダイレクト、カスタムヘッダー、 Amazon CloudFront を活用したグローバルで利用可能な CDN へのデプロイなどの利点があります。 静的ウェブサイトをデプロイするとき、Amplify は S3 バケットとデプロイされたウェブサイトとの接続を記憶しているため、S3 バケット内のウェブサイトコンテンツに変更を加えた場合でも、ワンクリックで簡単にウェブサイトを更新できます。静的ウェブサイトホスティングには AWS Amplify ホスティングの使用をお勧めします。大規模なセットアップをすることなく、より合理的かつ迅速にデプロイできるからです。 Amazon S3 コンソール から開始する統合の仕組みは次のとおりです。 Amazon S3 コンソールを使用して静的ウェブサイトをデプロイする この新しい統合を使用して、私の S3 バケットから直接個人ウェブサイトをホストしてみましょう。 はじめに、Amazon S3 コンソールのバケットに移動します。この S3 バケットのすべてのコンテンツのリストを次に示します。 AWS Amplify ホスティングとの新しい統合を使用するには、 [プロパティ] セクションに移動し、下にスクロールして [静的ウェブサイトホスティング] を見つけ、 [Amplify アプリを作成] を選択します。 すると、Amplify ページにリダイレクトされ、S3 バケットの詳細が入力されます。ここでは、 [アプリ名] と [ブランチ名] を設定します。次に、 [保存してデプロイ] を選択します。 数秒以内に AWS Amplify が静的ウェブサイトをデプロイします。 [デプロイされた URL にアクセス] を選択してサイトにアクセスできます。静的ウェブサイトの S3 バケットに、さらに変更を加えた場合は、 [アップデートをデプロイ] ボタンを選択して、Amplify コンソールにアプリケーションを再デプロイする必要があります。 プログラムによるデプロイでは AWS コマンドラインインターフェイス (AWS CLI) を使用することもできます。そのためには、AWS Amplify ダッシュボードから APP_ID や BRANCH_NAME などの必須パラメータの値を取得する必要があります。デプロイに使用するコマンドは次のとおりです。 aws amplify start-deployment --appId APP_ID --branchName BRANCH_NAME --sourceUrlType=BUCKET_PREFIX --sourceUrl s3://S3_BUCKET/S3_PREFIX Amplify ホスティングがウェブサイトの URL を生成したら、オプションで静的ウェブサイト用のカスタムドメインを設定できます。そのためには、AWS Amplify のアプリに移動し、ナビゲーションペインで [カスタムドメイン] を選択します。次に、 [ドメインを追加] を選択して、静的ウェブサイトのカスタムドメインの設定を開始します。カスタムドメインの設定について詳しくは、 Amplify ホスティングユーザーガイド をご覧ください。 次のスクリーンショットでは、カスタムドメインを使用して静的ウェブサイトを設定しています。Amplify は、私のドメイン用の SSL/TLS 証明書も発行して、すべてのトラフィックが HTTPS で保護されるようにします。 これで、静的サイトの準備が整いました。 https://donnie.id で確認できます。 知っておくべきこと より多くの利用可能な機能 – AWS Amplify ホスティングには、静的ウェブサイトに使用できる機能が他にもあります。詳細については、 AWS Amplify 製品ページ をご覧ください。 デプロイオプション – Amplify ホスティングコンソール 、 AWS CLI 、または AWS SDK を使用して、Amazon S3 から静的ウェブサイトのデプロイを開始できます。 料金 – 料金情報については、 Amazon S3 の料金ページ と AWS Amplify の料金ページ をご覧ください。 可用性 – Amplify ホスティングと Amazon S3 の統合を、 Amplify ホスティングが利用可能な AWS リージョン でご利用いただけるようになりました。 この新しいインテグレーションで、静的ウェブサイトの構築を始めましょう。AWS Amplify を使用した Amazon S3 静的ウェブサイトホスティングの詳細については、 AWS Amplify ホスティングユーザーガイド をご覧ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

パブリックセクター 澤です。AWS の高等教育機関向けの教育プログラムである AWS Academy で、データセンターの技術職のキャリアにつながるコースの日本語版が新たにリリースされましたので詳細をご紹介します。 現在、日本で展開しているAWSの無料の教育プログラムには 、16 歳以上の方ならどなたでも無料で参加できるセルフラーニング型の AWS Educate と高等教育機関（大学、専門学校、高専、公的な職業訓練機関）でのクラウドスキル習得のための授業を支援するための AWS Academy のふたつがあります。 AWS Academy は 2018 年にスタートした高等教育機関でのクラウドスキル教育の授業を支援する無償の教育プログラムです。AWS Academy はクラウドスキル教育を担う教員をAWSが支援することで、より多くの学生がクラウドの授業の受講の機会を得ることができる教育の仕組みを構築していただくためのプログラムです。現在、世界で 7,500 以上、日本では 200 以上の高等教育機関が加盟し、授業で活用されています。AWS Academy に加盟した機関の教員は自身のスキル習得の他にメンバーポータルから授業を登録し、AWS Academy のコース教材を使った授業を行うことができます。メンバーの教員は以下のようなリソースが提供されます。 教員向けのクラウドや指導方法に関するトレーニング（対面あるいはオンラインでAWSの講師が実施） 授業の受講者向けのラボ環境であるLearnerLab という実際に AWS を利用する演習県境 授業用のオンライン教材 教員メンバー向けの情報交換のためのオンラインフォーラム 教員メンバーの交流の機会 AWS Academy は以下のような流れで利用します。 機関代表者を決めて教育機関として加盟する。（機関代表者は加盟後に変更可能です。） 機関代表者が教員メンバーを募り希望者をノミネートする。（専用のLMS上で簡単な作業を行うだけの簡単な作業です。） ノミネートされた教員はメンバーになり、自身でクラウドを教えるためのリソース（教材、教員メンバーが参加するフォーラムへのアクセス、教員向けワークショップ）などが利用できるようになる。 教員メンバーLMS内でクラスを作り受講する学生を招待する。 招待された学生がクラスに参加し、教材や演習環境にアクセスする。 設定されたクラスの終了後一定期間で演習環境は削除される。（学生はクラス退出等特に何もする必要がなくリソースが残るといった心配はない。） 2024年11月1日現在、以下のコースが提供されていて、このたび新たにデータセンターの技術者を目指す学生の方に必要な知識を身に着けていただくことができる「AWS Academy Data Center Technician」と「AWS Academy Engineering Operations Technician」の日本語での提供がはじまりました。 図：AWS Academy で提供されているコースと日本語版のリリース状況 (図中の Foundation は初級 Associate は中級を意味します。時間は目安です。) 「AWS Academy Data Center Technician」提供の背景として、世界的な計算ニーズの増大化に伴うデータセンターの増設で、国内外でデータセンターを運営する人材のさらなる育成が急務になっていることがあります。 コースカリキュラムの学習内容は、AWS のデータセンターにだけ特化したものではなく、広く一般的にデータセンターで業務に初めて就こうとされている方々を想定したものです。そのため他の AWS Academy のクラウドスキル習得のためのカリキュラムと異なり、サーバの仕組み、ネットワークの仕組みなどといった、ハードウェアの基本事項を中心にその構造や仕組みを学習できるようになっています。もちろん、CPU や メモリといった内部の動作についても学習することができます。また、OS、ブラウザやコマンドといった実際に操作して作業をする対象となるソフトウェアやアプリケーション、ツールの一般的な役割や仕組みについてもトピックとして取り上げられています。その中には興味深いことに、Microsoft Office なども含まれています。 このような内容ですので、カリキュラムの目的はデータセンターエンジニアですが、コンピュータのハードウェアレベルの基本を学習したい方々にもご活用いただけます。 このコースの受講にあたり、前提のスキルや知識は特に設定されていません。日本でいえば、IT パスポートや基本情報レベルの知識があれば、より理解が深まったり、よりスピーディーに学習が進むかもしれませんが、コースの受講者には IT に関する前提知識がなくても学習を進められる内容になっています。そのため、情報系以外の学部学科やコースの方でも学習いただけます。 英語版での授業をすでに開始されている神田外語学院デジタル情報コース講師　山岸明倫様から次のようなコメントをいただきました。 “神田外語学院では、国籍や文化など多様な背景を持つ学生が集い、それぞれの個性を伸ばす環境が整っています。英語が苦手な学生も、入学後には飛躍的に成長し、多くが英語版Data Center Technicianコースを修了しました。他に類を見ないAWS Academyの高品質な教材でITスキルを磨き、ぜひDCエンジニアというキャリアに挑戦してほしいです。” また新しい日本語コースでの教育を計画されている福岡デザイン＆テクノロジー専門学校／神戸・甲陽デザイン＆テクノロジー専門学校　教務部長　大西貫士様からは以下のようなご期待をお寄せいただきました。 “ クラウドの利活用が急増する中で、データセンターエンジニアは業界から求められる人材であると捉え、今後育成に注力する予定でした。AWS Academy Datacenter Technicianコースは、インフラスキルを学ぶ本校学生が、さらに高い専門性を身に付けることができる教育コンテンツとして、非常に期待しています。また本コースはベンダーに寄らず、汎用的にデータセンターエンジニアとしての知識・スキルが学べるので、学生にとっても新たなキャリアへチャレンジできる機会と考えています。” AWSのデータセンターについて、少しご紹介します。AWSのデータセンターはリージョンがある東京一円のエリア、大阪一円のエリアに複数の場所にあり、東京リージョン、大阪リージョンの安定したサービスを提供するため様々な職種の多くの人が働いています。データセンター内のクラウドサービスが稼働するサーバやネットワーク機器の設置・管理・運用をするサーバーエンジニアの他にも、機械や電気設備の運用や保守を担うファシリティエンジニア、データセンターの設計を担うエンジニア、保守を担うエンジニア、建物を管理するエンジニア といった多様な職種の方がデータセンターの運営に携わっています。女性の技術者も多く活躍していて、ジェンダーダイバーシティを大切にするカルチャーも強く根付いています。英語を使う機会も多く、働きながらグローバル人材として必要なコミュニケーションスキルを身に着けたり、もちろんクラウドスキルそのものを学ぶ機会もありますので、ご自身で長期的なキャリアをデザインしていくことが可能です。 データセンターで働く若手技術者の声： ”データセンター内での業務では、サーバーやネットワーク機器などのハードウェアの設置やメンテナンスを行うほか、これらの機器にトラブルが発生した際には、問題の特定と解決を行うトラブルシューティングも担当しています。これらのトラブルはお客様の業務に大きな影響を与える可能性があるため、迅速かつ的確な問題解決が求められます。緊張感のある仕事ではありますが、多様なトラブルに対して試行錯誤を重ねながら自ら解決できたときには、大きなやりがいを感じます。 現在、ネットワーク化は日本国内にとどまらず、世界中で進んでおり、データセンターは重要なインフラとして社会を支える存在となっています。私もこの流れに乗り続けるため、将来は海外のデータセンターで働き、常に学びを深めていきたいと考えています。” データセンター オペレーションズ 　サーバーエンジニア　小林　仁美　(入社2年目) AWS の教育プログラムがクラウド人材だけではなく日本国内でのデータセンター人材育成を加速できるよう、高等教育機関と連携をはかりたいと考えています。また、データセンターの技術者という職業を知らないという学生も多いかと思いますので、クラウドに関わるキャリアの多様さについての理解促進にも努めたいと思います。 本投稿はインフラストラクチャーオペレーションズ　プログラムマネージャー菊池、トレーニングサービス本部AWS Academy 担当平賀の協力を得てパブリックセクター高等教育・研究担当DXアドボケート澤が執筆しました。 問い合わせ　aws-jpps-er@amazon.com 　(AWS高等教育機関　相談窓口)

10 月 28 日、私たちは Amazon Elastic Container Service (ECS) の 10 周年と、クラウドで可能なことの限界を押し広げてきたそのすばらしいジャーニーをお祝いしたいと思います! Amazon Web Services (AWS) で Docker コンテナの実行を効率化するソリューションとして始まったものが、シームレスなコンテナオーケストレーションを実現する AWS Fargate を使用したサーバーレスオプションなど、優れたパフォーマンスと運用のシンプルさの両方を提供する基盤テクノロジーへと進化しました。 過去 10 年間で、Amazon ECS は数え切れないほどの組織にとって信頼できるソリューションとなり、インフラストラクチャの課題に悩まされることなく運用を強化するために SmugMug などのお客様が頼りにする信頼性とパフォーマンスを提供してきました。 SmugMug の Principal Engineer である Andrew Shieh 氏は、Amazon ECS が、AWS にシームレスに移行したり、PB 規模の写真を Amazon Simple Storage Service (Amazon S3) に移行するなど、膨大なデータの操作を効率的に処理したりする際に「縁の下の力持ち」として役立ってくれたと述べています。「コンテナのスピンアップが驚くほど速いため、お客様にすばらしいエクスペリエンスを提供できます」と同氏は付け加えます。このような信頼できるサポートのおかげで、Amazon ECS はデベロッパーやプラットフォームチームに好まれ、長年にわたってソリューションのスケールとイノベーションに役立っています。 2010 年代初頭、Docker などのコンテナ化されたサービスが普及するにつれて、デベロッパーは、この新しいパラダイムでアプリケーションを管理およびスケールする効率的な方法を探し始めました。従来のインフラストラクチャは扱いにくく、コンテナの大規模な管理は困難でした。Amazon ECS は 2014 年に登場しました。これはまさに、デベロッパーがコンテナの大規模な導入を検討していた時期でした。Amazon ECS は、AWS でのコンテナオーケストレーションを合理化する、信頼性の高いフルマネージドソリューションを提供しました。チームは、クラスターや複雑なインフラストラクチャの管理のオーバーヘッドなしでアプリケーションの構築とデプロイに注力でき、クラウドネイティブ開発の新しい時代を切り拓きました。 Amazon ECS チームがサービスの構築に着手したとき、そのビジョンは明確でした。Amazon ECS を立ち上げた Product Manager であり、現在は VP of Next Generation Developer Experience を務める Deepak Singh は当時、「当社のお客様は、AWS と深く統合され、大規模に機能し、成長に合わせて拡張できるソリューションを求めていました」と述べていました。 Amazon ECS は、スケーラビリティ、可用性、回復力、セキュリティなど、AWS が提供する最高の機能を使用して、お客様が安心して本番環境でアプリケーションを実行できるように設計されました。 進化 Amazon ECS は、過去 10 年間、お客様のために一貫してイノベーションを続けてきました。これは AWS におけるコンテナイノベーションジャーニーの始まりであり、企業がアプリケーションを構築および管理する方法を変革した、コンテナ関連サービスのより広範なエコシステムへの道を開きました。 Smartsheet は、Amazon ECS、特に AWS Fargate がこれまでに同社のビジネスにもたらした大きな影響を誇らしげに称賛します。「当社のチームは、より頻繁にデプロイし、スループットを増大させ、デプロイにかかるエンジニアリング時間を数時間から数分に短縮できます。週 1 回だったデプロイは、1 日に複数回行われるようになりました。また、以前は少なくとも 2 人のエンジニアを要し、何時間もかかっていた作業が、数分にまで短縮されました」と Smartsheet の Distinguished Engineer である Skylar Graika 氏は述べています。 「この 1 年で、キャパシティを 50 倍にスケールアウトできたほか、AWS サービス間の緊密な統合を活用することで、効率性を高め、セキュリティとコンプライアンスのプロセスを簡素化できました。さらに、Fargate デプロイで AWS Graviton を採用することで、コストを 20% 削減できました」。 Amazon ECS は、AWS における 10 年間のコンテナ進化の出発点として極めて重要な役割を果たしました。そして今日でも、極めてスケーラブルで信頼性の高いコンテナオーケストレーションソリューションの 1 つとして、 Amazon が 7,724 万もの ECS タスク を立ち上げた Prime Day 2024、 Amazon ECS をコアアーキテクチャの一部として使用する、生成 AI を利用したショッピングアシスタントエクスペリエンスである Rufus など、大規模な運用を支えています。 Instrumental の ML Engineering Manager であり、AWS Machine Learning Hero でもある Rustem Feyzkhanov 氏は、このサービスを導入することで得られる効率性の向上をすぐに認識しました。「Amazon ECS は、私たちの仕事に欠かせないツールとなりました」と Rastem 氏は述べています。「過去数年にわたって、コンテナ管理とサービスのスケーリングが簡素化され、インフラストラクチャではなく開発に注力できるようになりました。このサービスにより、アプリケーションコードチームがインフラストラクチャを共同所有できるようになり、開発プロセスがスピードアップします」。 タイムライン ECS の進化を形作った重要なマイルストーンのいくつかを見てみましょう。これらは、お客様が AWS でコンテナの力を活用する方法を変えた重要な瞬間です。 2014 年 – Amazon EC2 Container Service をリリースしました ! – ECS のプレビューモードでのリリースを記念した、懐かしいブログ記事をご覧ください。この記事を読むと、サービスの提供開始時からいかに多くの機能が提供され、最初から大きな影響をもたらしているのかがわかります。 お客様は既に、組み込みのリソース管理とタスクスケジューリングを使用して、 Amazon Elastic Compute Cloud (EC2) インスタンスのクラスターで Docker コンテナを実行、停止、管理することができました。2015 年 4 月 9 日に一般提供が開始されました。 2015 年 – Amazon ECS 自動スケーリング – より多くの Amazon CloudWatch メトリクスのサポートが追加され、お客様は、クラスター内の CPU とメモリの使用状況をモニタリングして自動スケーリングのしきい値を設定することで、クラスターを自動的にスケールインおよびスケールアウトできるようになりました。これは、一見控えめなリリースが、お客様に大きな影響をもたらし得ることを示すすばらしい例だと思います。もう 1 つのインパクトのあるリリースは、コンテナのストレージとデプロイを効率化するフルマネージドコンテナレジストリである Amazon ECR の提供開始 です。 2016 年 – ECS 向け Application Load Balancer (ALB) – ECS 向け ALB の提供開始により、コンテナ化されたアプリケーションのために高度なルーティング機能が提供されました。ALB により、マイクロサービス間の負荷分散がより効率的になり、ECS ワークロードのトラフィック管理とスケーラビリティが改善されました。また、この年には、いくつかの AMI による Windows Server 2016 のサポート の追加や、 Windows Server Containers のベータサポート など、Windows ユーザーはさまざまなリリースの恩恵を享受しました。 2017 年 – AWS Fargate の提供を開始しました ! – Fargate は、基盤となるインフラストラクチャを管理せずにコンテナを実行できるという大きな前進となり、お客様の運用が大幅に効率化されました。デベロッパーは、コンテナが実行される EC2 インスタンスのプロビジョニング、スケール、またはメンテナンスについて心配する必要がなくなり、アプリケーションロジックに完全に注力し、その他を AWS に任せることができるようになりました。これは、デベロッパーがより迅速にスケールしてより自由にイノベーションを行うのに役立ち、クラウド中心のジャーニーが加速され、コンテナ化されたアプリケーションに対するアプローチが変革されました。 2018 年 – AWS Auto Scaling – このリリースにより、チームは Amazon ECS タスクのスケーリングプランを簡単に構築できるようになりました。また、この年には、 Amazon ECR を Amazon ECS コンソール外の独自のコンソールエクスペリエンスに移行する 、 Amazon ECS と AWS Cloud Map を統合する など、多くの改善もリリースされました。さらに、AWS Fargate の採用は世界中のリージョンで拡大し続けました。 2019 年 – Amazon ECS で使用可能な Arm ベースの Graviton2 インスタンス – AWS Graviton2 は、多くの企業が持続可能性の目標の優先順位付けの見直しに目を向けていた時期にリリースされました。Graviton2 を搭載し、パフォーマンスの改善と電力使用量の削減に重点を置いた EC2 インスタンスは、リリース初日から Amazon ECS でサポートされました。お客様は、クラウド向けに特別に構築されたこの画期的なカスタムチップセットを最大限に活用できました。この年のもう 1 つの大きなハイライトは、 AWS Fargate Spot のリリースです。これは、お客様が大幅なコスト削減を実現するのに役立ちました。 2020 年 – Bottlerocket – コンテナの実行に最適化されたオープンソースの Linux ベースのオペレーティングシステム。セキュリティの強化と更新の簡素化を目的として設計された Bottlerocket は、Amazon ECS ユーザーがコンテナ化されたワークロードの管理において、より高い効率性と安定性を実現するのに役立ちました。 2021 年 – ECS Exec – Amazon ECS は 2021 年 3 月に ECS Exec の提供を開始しました。これにより、お客様は、Amazon EC2 または AWS Fargate で実行中のコンテナ内で直接コマンドを実行できるようになりました。この機能は、コンテナの変更や再デプロイを必要とせずに、強化されたトラブルシューティングとデバッグ機能を提供し、運用ワークフローが合理化されました。また、この年には、 Amazon ECS Windows コンテナ がリリースされ、クラスターでコンテナを実行しているユーザーのオペレーションが合理化されました。 2022 年 – Amazon ECS が Service Connect の提供を開始 – ECS Service Connect のリリースは、サービス間ネットワークに伴う複雑さの多くを抽象化したため、Amazon ECS でマイクロサービスアーキテクチャを実行している組織にとって極めて重要な瞬間となりました。これにより、サービス間の通信の管理が大幅に効率化されました。ネイティブのサービス検出とサービスメッシュ機能により、デベロッパーは、サービスがシームレスにインタラクションする方法を定義および管理できるようになり、カスタムネットワークやロードバランサーを管理することなく、オブザーバビリティや回復力を高め、セキュリティを強化できました。 2023 年 – Amazon GuardDuty ECS ランタイムモニタリング – 昨年、Amazon GuardDuty は AWS Fargate 向けの ECS ランタイムモニタリングの提供を開始し、実行中のコンテナ内の潜在的な脅威を検出することでセキュリティを強化しました。この機能により、コンテナワークロードの継続的な可視性が提供され、追加のパフォーマンスオーバーヘッドなしでセキュリティ体制が強化されます。 2024 年 – Amazon ECS Fargate と EBS の統合 – 今年 1 月、Amazon ECS と AWS Fargate は Amazon EBS ボリュームのサポートを追加し、コンテナの永続ストレージを実現しました。この統合により、ユーザーは EBS ボリュームを Fargate タスクにアタッチできるため、ストレージのデプロイや大量のデータを取り扱うアプリケーションのサポートがはるかに簡単になります。 現状 Amazon ECS は現在、イノベーションを続けながら新規および既存のお客様の両方に大きな価値を提供することを可能にする成熟度に達しており、エキサイティングな状況にあります。今年はサービスに多くの改善が加えられ、ますます安全でコスト効率が高く、使いやすくなっています。 これには、 Service Connect での TLS を使用した自動トラフィック暗号化のサポート 、 タスクの停止エラーメッセージの強化 (タスクの起動失敗のトラブルシューティングが簡単になります)、 タスクを再起動せずにコンテナを再起動 する機能などのリリースが含まれます。 AWS Fargate Spot を使用した Graviton2 ベースのインスタンスの提供開始 は、お客様にとって、コスト削減額を倍増させる絶好の機会となります。 AWS ではいつものことですが、Amazon ECS チームはお客様の満足に非常に力を入れています。「Amazon ECS と AWS Fargate を使用すると、AWS が提供する強力なすべてのコンピューティングを、管理することなく活用しながら、差別化されたビジネスロジックに注力することが非常に簡単になります」と Director of Product and Science, Serverless Compute である Nick Coult は述べています。「これらのサービスについての当社のビジョンは、インフラストラクチャ管理を最小限に抑え、作成するコードを減らし、拡張性を考慮して設計して、高いパフォーマンス、回復力、セキュリティを推進できるようにすることでした。そして、それは現在でも変わっていません。また、当社はこの目標を念頭に置いて、過去 10 年間、これらの領域で継続的にイノベーションを起こしてきました。Amazon ECS では、セキュリティを損なうことなく俊敏性を提供し、デベロッパーに優れたエクスペリエンスを提供するとともに、より幅広くシンプルな統合を実現して、生成 AI などの新しいワークロードの新たな可能性を生み出すというコミットメントを堅持しています」。 まとめ その歴史を振り返ると、ECS はお客様のニーズから逆算する AWS のアプローチの証であることは明らかです。コンテナオーケストレーションの合理化に取り組んでいた初期の頃から、Fargate と Service Connect の革新的な提供開始まで、ECS はデベロッパーと企業の両方の障壁を取り除くために一貫して進化してきました。 将来を見据えると、ECS は限界を押し広げ続け、さらに革新的でスケーラブルなソリューションを実現していくと思います。ECS が提供するものを引き続き探求し、新しい構築方法を発見して、プラットフォームの可能性を最大限に引き出すことを、あらゆるお客様にお勧めします。今後もさらに多くのことが予定されており、このジャーニーが私たちをどこへ連れて行ってくれるのか楽しみにしています。 学習リソース Amazon ECS を初めてご利用になる場合は、包括的でわかりやすい「 Amazon ECS の開始方法 」ガイドを読むことをお勧めします。 いくつかの実践的な無料トレーニングでスキルを磨く準備ができたら、この記事で言及した機能の多くを含む、サービスの多くの側面をカバーするこのセルフペースの Amazon ECS ワークショップ を試すことをお勧めします。 Amazon ECS に感謝します。また、このサービスを使用し、引き続きサービスの改善にご協力くださるすべての皆様にも感謝します。コンテナイノベーションの次の 10 年もすばらしいものとなりますように! 原文は こちら です。

2 週間前、私はグローバルな 24 Hours of Amazon Q ライブストリームイベントで、アジアパシフィック全体から内容領域専門家をお招きするすばらしい機会に恵まれました。ユースケース、製品デモ、質疑応答セッションを特色とするこの 24 時間連続のストリームでは、 Amazon Q Developer と Amazon Q Business に関する AWS エキスパートのインサイトが提供されました。 私にとってのハイライトは、これらのエキスパートから多くのことを学んだことです。それ以来、私は Amazon Q Business を自分のワークフローに統合しようと努めてきました。Amazon Q でできることについてご関心がおありの場合は、 Twitch でオンデマンドリプレイをご覧ください。 10 月 21 日週のリリース 10 月 21 日週の AWS のリリースのうち、私の目に留まったものを以下にまとめました。 AWS Lambda コンソールが、Code-OSS (VS Code – オープンソース) をベースとした新しいコードエディタを導入 – AWS Lambda は、人気の Code-OSS である Visual Studio Code Open Source コードエディタをベースとする、AWS コンソールでの新しいコード編集エクスペリエンスを導入します。Lambda コンソールでは、好みのコーディング環境とツールを使用できます。 Amazon Bedrock カスタムモデルインポートの一般提供を開始 – Amazon Bedrock では、単一の統合 API を通じて、カスタマイズされたモデルを既存の基盤モデルと一緒にインポートして使用できるようになりました。この機能により、インフラストラクチャやモデルライフサイクルタスクを管理することなく、人気のオープンソースアーキテクチャに基づいて、ファインチューニングされたモデルを活用したり、独自のモデルを開発したりできます。 EC2 Image Builder で macOS イメージの構築とテストのサポートを開始 – EC2 Image Builder は、既存の Windows および Linux サポートに加えて、macOS ワークロードのマシンイメージの作成と管理のサポートを追加しました。これにより、イメージ管理プロセスを合理化し、macOS イメージを維持するための運用オーバーヘッドを削減できます。 Amazon Bedrock で、Anthropic の Claude 3.5 Sonnet (現在利用可能)、コンピュータ使用 (パブリックベータ)、Claude 3.5 Haiku (近日公開予定) がアップグレード – Amazon Bedrock の Anthropic の Claude 3.5 モデルファミリーは、Claude 3.5 Sonnet 向けの改善されたインテリジェンスや、パブリックベータでの新しいコンピュータ使用機能など、大幅なアップグレードを受け取ります。これらの機能強化は、さまざまなユースケースのためのより高度な AI アプリケーションの構築、複雑なタスクの自動化、改善された推論機能の活用をサポートします。 Amazon Connect が画面共有の提供を開始 – Amazon Connect は、エージェント向けの画面共有機能の提供を開始しました。この機能は複数のリージョンで使用可能で、既存の音声通話およびビデオ通話設定に簡単に統合できます。この機能により、カスタマーエクスペリエンスをパーソナライズして改善できます。 Amazon Aurora がグローバルデータベースライターエンドポイントをリリース – Amazon Aurora は、可用性の高いフルマネージドグローバルデータベースライターエンドポイントをサポートするようになりました。この機能により、アプリケーションのルーティングが簡素化され、クロスリージョングローバルデータベーススイッチオーバーまたはフェイルオーバーオペレーションを開始した後でアプリケーションコードを変更する必要がなくなります。 新しい分析と会話のインサイトにより、Amazon Q Business に関するより深いインサイトを取得 – Amazon Q Business は、分析ダッシュボードと Amazon CloudWatch Logs との統合を提供するようになりました。Amazon Q Business アプリケーション環境と Amazon Q Apps の使用状況に関する包括的なインサイトが得られるようになり、使用状況のモニタリング、分析、最適化が容易になりました。 myApplications の新しい Resiliency ウィジェットの発表 – AWS は、アプリケーションの回復力に関する可視性とコントロールを強化した、myApplications の新しい Resiliency ウィジェットの提供を開始しました。myApplications ダッシュボードから直接、回復力評価を開始し、実用的なインサイトを得ることができます。 community.aws からの情報 community.aws から、私が個人的に最も気に入っている 5 つの記事をご紹介します。 Setting Up Microsoft Entra ID SAML 2.0 Federation with Amazon WorkSpaces Pools (著者: Dzung Nguyen 氏 )。 Getting Started with Rust: A Beginner’s Guide (著者: Matheus Guimaraes )。 Deploying AWS Infrastructure with GitOps and CloudFormation (著者: Jason Wood 氏 )。 Instrumenting applications on AWS ECS and AWS Fargate with AWS X-Ray (著者: Paulo Siecola 氏 )。 Becoming an AWS Cloud Captain: My Experience (著者: Rashi Dashore 氏 )。 今後の AWS イベント カレンダーを確認して、今後の AWS およびコミュニティのイベントにサインアップしましょう。 AWS GenAI Lofts – AWS GenAI Lofts で深いインサイトを得て、質問に答えてもらい、次のイノベーションの構築を開始するために知る必要のあるすべてのことを学びましょう: ソウル (10 月 30 日～11 月 6 日)、 サンパウロ (11 月 20 日まで)、 パリ (11 月 25 日まで)。 AWS Community Days – 技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とするコミュニティ主導のカンファレンスに参加しましょう。今後の AWS Community Day は、 マルタ (11 月 8 日)、 マレーシア 、 チリ (11 月 9 日)、 インドネシア (11 月 23 日)、 コチ (インド) (12 月 14 日) に開催されます。 AWS re:Invent – 12 月 2〜6 日にラスベガスで開催される、毎年恒例のテックイベントへの 登録 が開始されました。話題になること間違いなしの 5 つの基調講演で、新製品のリリースについて学び、デモを見て、舞台裏のインサイトを入手しましょう。 近日開催されるすべての 対面イベント と 仮想イベント を閲覧できます。 10 月 28 日週のニュースは以上です。11 月 4 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

そろそろ re:Invent も近づいてきましたが、日本でもまだまだイベントが続きます。流通・小売・消費財業界に関わられている方々を主な対象として、2024 年 10 月 24 日に「流通・小売・消費財業界向け：クラウドと生成 AI によるオペレーション改革」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログでは、その内容を簡単にご紹介します。またブログ最後に近く予定されているイベントのご紹介もしていますので、ぜひそちらもご参加を検討ください。 在庫管理、発注管理、物流配送、店舗設計、販促…小売業界における皆様の日々の業務、つまりオペレーションにおける改善・改革は常に企業のニーズとして存在してきました。テクノロジーで変革を支援、加速することのできるオペレーションもたくさんあり、急速に私たちの日常にも浸透しつつある生成 AI はそのテクノロジーの筆頭です。 生成AI を用いて蓄積された社内ナレッジを検索、再利用する、コンテンツを生成したり、解釈を手伝ってもらう – 今回のセミナーでは生成 AI を業務オペレーション改革に応用したお客様 5 社の、具体的な成功事例をお話いただきました。 1. オープニング AWS 技術統括本部 エンタープライズ技術本部 流通小売・消費財グループ 部長 　五十嵐 建平 資料ダウンロード 企業はオペレーション改革に対して、当該業務そのものをスマートに見直すこと、あるいは熟練性の伝達による属人性を排除することによる効率化、それらによりもたらされる時間やコストの削減や、より価値のある業務への集中などの期待を持っています。生成 AI をオペレーション改革に適用する試みは昨年から活発化し、今年に入り具体的な成果が次々と検証されています。その生成AIのユースケースは大きく 3 つのフェーズで進化していると考えられます。 (1) 既存ナレッジの検索 生成 AI で企業の既存ナレッジを検索しやすくすることなどにより、対応スキルの底上げや、チャットボットなどに代表されるアシスタントが各業務を支援するフェーズです。多くのお客様がまずここからスタートし、徐々に高難度なタスクへと挑戦していっています。 (2) データ読み取りや作成 最初のフェーズが進み始めると、より多様な業務に適用を進めるために、さらに幅広く企業内のデータを利用したくなります。データは構造化されるほど扱いやすくなります。データの種類も増やしたくなります。こういったデータを豊かにすることそのものに、生成 AI を利用します。 (3) コンテンツ監査 より重要な判断についての支援を生成 AI から得るために、コンテンツを高精度に監査する、そこにまた生成 AI の活用が見出されています。 今回の事例でご登壇いただく 5 社様、それぞれが異なるフェーズのお話になっています。そしていずれも今回ご紹介いただく「成功事例」のさらに次の挑戦、適用範囲の拡大や高度化が計画されています。業務ごと、適用フェーズごとに適切な生成 AI 技術を選択し、オペレーション改革そのものを継続させている、そんな点を念頭に各お客様事例を聞いていただければ、皆様のクラウド、そして生成AIによるオペレーション改革を実現するための手がかりを掴めるはずです。 2.お客様事例 (1) 生成AIを組み込んだ入札契約業務オペレーション改革 三井物産株式会社 デジタル総合戦略部 デジタルテクノロジー戦略室 Product Manager 伊藤 友貴様 資料ダウンロードリンク 三井物産株式会社様、そしてそのグループ内では、多くの国際入札に参加しています。入札業務においては短期間で 100 ページを超すような入札説明書を読み込まなくてはならないようなケースがあり、商材や契約実務に関する専門知識・業界知識が必要とされるために、熟練者でも40時間以上かかることがあります。そこで、生成 AI により入札説明書を解析するアプリを開発しました。まず、「AI 要旨項目抽出」機能が、入札説明書の構成単語を抽出・分類します。続いて「AI 重要単熟語着色」機能がこれらの単語をラベリングし、色分けします。最後に「要旨生成」機能がその入札説明書の要旨を生成します。担当者はアプリを使って分類、色分けされた情報を参照しつつ、訂正などを行い、最後に要旨を作成することができます。この一連の処理のデモを、講演の中でご紹介いただいています。実証実験では、熟練者で約 12 時間、新人では約 51 時間の業務時間削減効果が確認されました。さらに、新人の業務成功率も33% から100% に向上したとのこと。 技術的には、識別式モデル（BERT）による系列ラベリングと、 Amazon Bedrock の提供する LLM による修正を組み合わせて構築されています。当初ルールベースで構築していた部分をLLMに切り替えることで、ルールの保守運用から開放されました。LLM に切り替えた後も、利用するモデルを初期は Jurassic-2 Ultra から、その後、新しい Claude 3.5 Sonnetへと、継続的なアップデートを図られています。こういったモデルのアップデートを容易に実現できる点で、Amazon Bedrock を評価していただいています。アプリ開発の裏話として、単にモデルの選択や精度を追求するのではなく、開発サイドとユーザーサイドが協力し合って UI/UX を改善していったことで、より使ってもらえるサービスとなっていった点にも触れられていました。 現在、このアプリは三井物産グループ内で展開が進んでおり、今後は社外提供も計画されているそうです。 3. お客様事例 (2) Amazon Bedrock と Lambda を活用したホームページ制作支援システム 株式会社ペライチ カスタマーリレーション部 プロダクトマネージャー 藤代 康太 様 資料ダウンロードリンク ペライチ様は「テクノロジーをすべての人が使える世界に」をビジョンに掲げ、ホームページ作成にあたってユーザーの抱える「ページ構成を決められない」「社内にノウハウがなく負担が大きい」という課題を解決するために、専門知識がなくても簡単にホームページを制作できるサービスを提供されています。ノーコードでホームページを作れるように様々なユースケースに合わせたテンプレートや、組み合わせて使うことのできるビルディングブロックを提供されているのですが、それでもユーザーからは「どのテンプレートを選べばよいか分からない」といった声がありました。そこで、Amazon Bedrock と AWS Lambda を活用し、AI アシスタントによる、ページ自動生成システムを開発しました。通常は担当者が行うホームページの移行や制作準備の作業を、生成 AI が既存サイトを読み込み解析することで支援します。さらに、テンプレートからページを制作する作業も、テンプレートの選択や画像の再配置、キャッチコピーの生成などを生成 AI が手伝います。ご講演の中で実際に既存のウェブサイトの URL から新たなホームページを生成するまでの一連の流れをデモでご紹介いただいています。画像など既存サイトのアセットを有効活用しつつ、テンプレートに沿った新しいページが生成されていきます。生成 AI により生成されるコンテンツにはムラがあるので、生成したものをそのまま使うのではなく、いったんユーザーが確認、編集するステップを置くことでより納得感のある制作ステップを提供できるようにもなっています。 ユーザーのページ制作の効率化と品質向上を目指すこの新機能は、現在はベータ版として提供中で、80名のモニターユーザーから好評を得ているとのことでした。今後は、このシステムの効果を測定しつつ、既存サービスの改善や他の課題解決への応用を検討していくとのことです。 4. お客様事例 (3) Amazon Bedrock × Kendra で実現する、生成 AI による組織ナレッジの継承と効率化 ライオン株式会社 デジタル戦略部 データサイエンティスト 百合 祐樹 様 資料ダウンロードリンク ライオン様からは、研究開発部門が直面していた知識管理と情報共有の課題に対し、生成AIを活用したソリューションを導入した事例をご紹介いただきました。研究の分野では、長い商品研究の歴史の中で「新しい実験のアイデアを思いついたと思ったが、実はかなり以前にすでに実験済みだった」ということが実際に起っているそうです。長く在籍された研究者の方であれば蓄積された情報の所在を理解していることもありますが、それを次の世代の研究者へと伝えていくことも大変です。こういった過去に遡った大量データからの知見の活用というユースケースは、まさに生成 AI、その中でも RAG（Retrieval-Augmented Generation、検索拡張生成）の得意とするところです。 そこで「これまでの研究活動において培った技術知見を高度に活用できる仕組みを整備し、新たな顧客価値創造・イノベーション創出を加速する」ことを目標に、ナレッジ検索システムを開発されました。このシステムは、特に大規模なデータでの RAG で、技術的には Amazon Bedrockと Amazon Kendra を組み合わせて実現されています。この仕組みによって、情報検索時間は最大5分の1に短縮され、これまで見つけにくかった情報の発見や、若手や日本語を母国語としない海外出身の研究員の理解促進にも貢献しているとのことです。 ライオン様は、このシステムを研究集約知のフレームワーク確率への第一歩として、今後も、データの追加や改善を継続して対応するユースケースを増やし、より高度な組織ナレッジの活用を目指されているそうです。 5. お客様事例 (4) SaaS 事業者の生成 AI 活用パターン ～新機能開発から業務効率化まで～ ナビプラス株式会社 事業企画部 2グループ グループマネージャー 白石 卓也 様 資料ダウンロードリンク ナビプラス様は、EC サイト向けマーケティングツール、具体的には EC サイト内における、サイト内検索やレコメンデーションといった EC サイトに必要とされる機能を SaaS で提供されています。ナビプラス様では、生成 AI 導入の選択肢として、LLM だけでなく、LLM よりも精度や汎用性には劣るもののより手軽に利用できる、小規模言語モデル（SLM）にも注目しており、ユースケースを探りながらいろいろな生成 AI の選択肢を拡げているところだそうです。ご講演の中で、LLM と SML の比較実験をとてもわかりやすいサンプルでご紹介いただいています。 具体的な生成 AI活用事例としてはまず、社内 Slack ボットが取り上げられました。Amazon Bedrock と Amazon Kendra を組み合わせた、社内情報を活用した RAG を導入し、文章の要約・翻訳から、カスタマージャーニー作成まで、幅広い業務オペレーションで利用されています。もう一つの活用事例は、ナビプラス様の提供するサービスそのものへの生成 AI 適用事例です。ナビプラスシリーズにはいくつかのサービスがありますが、今回は EC サイトにおけるユーザーレビュー管理のためのサービス、ナビプラスレビューに、ユーザーが商品レビューを投稿する際のアシスト機能を組み込みました。ここでも Amazon Bedrock を利用し、商品ごとに適切な質問を投げかける生成 AI、そしてその質問に対するユーザーの回答からレビューコメントを下書きする生成 AI が活躍しています。この機能は約 3 ヶ月でリリースされたそうです。 「生成AIの進化は日進月歩で、私たちの想像を超えるスピードで新しい可能性が生まれています。まずは小さな一歩から始め、実践を通じて活用領域を広げていきましょう。顧客接点の革新とオペレーション改革で、皆様のビジネスの競争力向上につながることを願っています。」という、ご講演スライドから生成 AI によって作成されたメッセージで講演を締めくくっていただきました。 6. お客様事例 (5) 業務効率化のため取り込んだ新たな生成 AI 活用術 株式会社ファミリーマート システム本部 IT基盤部 クラウド推進グループ 朴 明振 様 ※資料ダウンロードは当日ご視聴いただいた方のみとなっております。 ファミリーマート様では、様々な業務オペレーションの補助手段として、生成 AI を積極的に検討されています。店舗管理業務、全社共通ツールなどそれぞれに適切なモデルでの検討が進んでいるそうですが、今回の講演では IT 部門のエンジニア向けのユースケースをご紹介いただきました。例えば AWS サポートへの問い合わせ履歴やマニュアルを効率的に検索、参照したい、といったとても身近な課題への対応です。実現には、AWS の GenU（Generative AI Use Case JP） を活用されています。GenU とは、生成 AI を安全に業務活用するための、ビジネスユースケース集を備えたアプリケーションの実装サンプル集で、Amazon Bedrock を使用した実装コードを AWS が公開しています。IaC で簡単に、完成度の高いシステムをデプロイすることができ、すぐに試せる点を評価いただきました。 これをさらに一歩進め、Amazon Kendra のドキュメント相互参照機能を活用し、複数のドキュメント間でルール違反がないかを確認するなど、より高度な分析を実現することに挑戦されました。これにより、“ある提案書が社内マニュアルのルールに準拠しているかどうかを確認する”（提案書やマニュアルはそれぞれ異なるドキュメント）といったことが可能になっています。具体的には、まず生成 AI に社内マニュアルから必要なルールを抜粋するように指示し、その抜粋されたルールを次の質問（プロンプト）に渡します。続けて、提案書がそのルールに準拠しているかどうかをチェックして、という指示を出します。この 2 つ目の指示を出す際に、先に抜粋されたルールが渡されているため、相互参照が可能になる、という仕組みです。ファミリーマート様ではこの機能の提供により、チームメンバー間のノウハウ共有や過去の知見の活用が促進され、プロジェクト管理の質が向上しており、さらなる機能拡張も計画されているそうです。 最後に「ドキュメントの相互参照をぜひお試しください」という力強い推薦メッセージをいただきました。 まとめ オープニングで紹介した、生成 AI のユースケース進化の 3 つのフェーズに照らし合わせると、ライオン様やファミリーマート様ではフェーズ (1) において、Amazon Kendra の特性を活かしてオペレーション改善を実現した事例と言えます。ナビプラス様のナビプラスレビューのレビューコメント生成は、さらなるデータの拡張を狙っている段階に進んでおり、フェーズ (2) のユースケース事例です。ペライチ様では、テキスト、画像を組み合わせるマルチモーダルでホームページ制作の半自動化が実現されています。三井物産様では BERT と LLM の組み合わせでの高度な入札業務の効率化を実施されています。これらの 2 社はフェーズ (3) の事例と言えるでしょう。 5 社の事例から、生成 AI の活用において オペレーションが実際にどれだけ改善されたのか、効果を定量的に計測している 小規模なチームで実験を繰り返し進化させている 1-3 ヶ月の短期間で本番稼働させ、それをさらに拡張・高度化させている という点が共通的な成功要素であることが見えてきます。 特に一点目の効果測定は非常に重要な要素です。生成 AI に限らず、DX のトレンドの中で、データ利活用に取り組む企業の 50% 近くは成果を測定していない（ DX 白書 2023 より）と言われています。成果が具体的に語れないと、そもそも成功しているか評価できず、それ以上の進化のための投資も難しくなってしまいます。 今回の成功事例から、技術的な仕組みだけでなくこういった側面からも学んでいただけると思います。 多くの企業において、企業トップや事業部で「生成 AI を使っていこう」という大きなモメンタムがあります。これは業務オペレーションそのものの変革に取り組んでいく絶好の機会です。ぜひ、早く進化を始め、そして進化を早めて、競争力を加速させていきましょう。私たちがお手伝いします。 今後のイベント 11 月にも、流通・小売・消費財業界の皆さまに向けたイベントを予定しています。ぜひご参加ください。 AWS Retail CPG Expo 2024: カスタマーエンゲージメントからスマートストアまで – 5つの戦略的イノベーションが牽引する次世代小売 リテール業界固有の課題と機会に応える、ソリューションプロバイダーのサービスやベストプラクティスを一挙紹介 2024 年 11 月 12 日 13:30 – 18:30 お申し込みはこちらから： https://aws-retail-expo-2024.splashthat.com/ イベントコンテンツの紹介ブログ も参照ください。 流通小売/消費財企業向け：2024 年 最新ソリューションによるレガシーシステムのクラウド移行 2024 年 11 月 15 日 (金) 10:00 – 11:10 お申し込みはこちらから： https://pages.awscloud.com/eib-cpg-241115-reg.html 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しておりますのでご覧ください。 流通小売参考情報 [1] AWS ブログ ”流通小売” カテゴリー [2] AWS ブログ “消費財” カテゴリー [3] AWS 消費財・流通・小売業向け ソリューション紹介 ページ [4] インダストリー向け e-Book： スマートストアテクノロジーの力を活用する（ e-Book | 紹介ブログ ） 小売業のデジタルコマースを最適化する 4 つの重要なステップ（ e-Book | 紹介ブログ ） 流通・小売・消費財企業のイノベーションを生成 AI で促進する（ e-Book | 紹介ブログ ） 消費財企業が成長するための極意（ e-Book | 紹介ブログ ） 消費者に愛されるブランドを構築する（ e-Book | 紹介ブログ ） このブログは、ソリューションアーキテクト 杉中 が担当しました。

こんにちは。 AWS パブリックセクター技術統括本部です。 ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目については、ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』をはじめとする「ガバメントクラウド活用のヒント」シリーズをご覧ください。 またその中でも、コスト最適化については気になる方が多いかと思います。 詳細解説：ガバメントクラウド名前解決編 にもある通り、複数の AWS アカウントに存在するリソースを 1 つの AWS アカウントへ集約すると、コストが下がるケースがあるため、リソース集約の検討をお勧めします。 本ブログは、VPC エンドポイントの構成に関して深堀していきます。ガバメントクラウド特有の制限ではなく、オンプレミスと AWS 環境をハイブリッドに構成するネットワーク設計では一般的な内容です。ぜひご検討の際に参考にしていただければと思います。 VPC エンドポイントとは？ VPC エンドポイントは、VPC と他の AWS サービス間でプライベートな接続を提供する機能です。主な特徴と利点は以下のとおりです。 概要 VPC 内のリソースが AWS サービスにプライベートアクセスできるようにする インターネットゲートウェイや NAT ゲートウェイを経由せずに接続可能 VPC 内に作成され、指定したサブネット内にエンドポイントのネットワークインターフェイスが作成される 種類 ガバメントクラウドで利用される VPC エンドポイントは、インターフェイスエンドポイントが多いかと思います。理由としては、AWS Direct Connect 経由でオンプレミスからのアクセスが可能なためです。自治体の個人番号利用事務系の業務システムでは通信を閉域で行う必要があるため、頻繁に利用されています。VPC エンドポイントのタイプの詳細については、 こちら をご確認ください。 インターフェイスエンドポイント AWS PrivateLink を使用して多くの AWS サービスに接続可能 エンドポイントのネットワークインターフェイス (ENI) を作成 ゲートウェイエンドポイント S3 と DynamoDB のみに対応 ルートテーブルを書き換えてアクセス 主な利点 セキュリティの向上: インターネットを経由せず AWS サービスにアクセス可能 ネットワークコストの削減: インターネット経由の通信が不要になる レイテンシーの改善: AWS ネットワーク内での直接接続により高速化 VPC エンドポイントのコストについて VPC エンドポイントのコストについてですが、時間単位の料金とデータ処理料によって構成されます。 各アベイラビリティーゾーンに VPC エンドポイントがプロビジョニングされている間、サービスとの関連性のステータスにかかわらず、時間単位の料金が発生します。東京リージョンの場合、各 AZ の VPC エンドポイント 1 つあたりの料金 (USD 0.014 / 時間)となります。 データ処理料金は、トラフィックの送信元か送信先かにかかわらず、VPC エンドポイントで処理されたデータ量 (ギガバイト単位) に対して請求されます。費用についての詳細は、 料金ページ をご参照ください。 ガバメントクラウドでは、マルチアカウントでの運用が前提になる場合が多いかと思います。その際のコストについては以下のように考えることができます。例えば、10 アカウントで 10 個の VPC エンドポイント (すべて東京リージョン) を利用している場合、月に $1041.6 (0.014$ × 744h × 10 個 × 10 アカウント)発生します。これを 1 つのアカウントに集約すると、純粋にアカウント数で割ったら月に $104.16 に下がり、多くのコストを削減できることになります。 項目 計算式 金額 (USD) 集約前のコスト 0.014 USD × 744 時間 × 10 エンドポイント × 10 アカウント 1,041.6 集約後のコスト 0.014 USD × 744 時間 × 10 エンドポイント × 1 アカウント 104.16 削減額 1,041.60 USD – 104.16 USD 937.44 さらに VPC エンドポイントは AZ につき 1 つ作成するため、可用性を求められるシステムだと、1 サービスの VPC エンドポイントを AZ 分で作成する必要があります。つまりアカウント数が多いほど、展開する AZ が多いほど、エンドポイントを作るサービスが多いほど、集約効果は高くなる場合が多いです。 とはいえ、ガバメントクラウドにおいては、複数の事業者の役割が定義されています。事業者としては、自治体ごとに他の事業者の振る舞いによって自分の役割を変えないといけないことが現状としてあり、最適な構成が見えづらいという以下の課題感があるかと思います。 環境全体を考える人がいないため、全体最適な構成が採用されづらい 各アカウントでどういった設定をすればいいか見えづらい (他事業者とどういった調整をすればいいか不明瞭) この課題感を少しでも解消すべく、本ブログでは VPC エンドポイント構成についてご紹介します。 構成 PrivateLink 構成 (ネットワークアカウント) この構成は、ネットワークアカウント側で VPC エンドポイントを作成し、各アカウントのアプリケーション分離方式のアプリケーションに接続する構成です。他に検討すべき事項としては、名前解決の機能をどのアカウントで持たせるかという点ですが、Route 53 Private Hosted Zone を他の VPC へ共有する方法で、エンドポイントを集約できる構成のため、コスト最適化につながります。詳細については、 詳細解説：ガバメントクラウド名前解決編 をご参照ください。 また、Transit Gateway Attachment ごとにコストがかかるため、エンドポイントを配置する VPC は集約するとコスト効率が良いです。もちろん、業務アカウントがそれぞれに独立してエンドポイントを持つことも可能ですが、Transit Gateway Attachment が増加します。 VPC エンドポイントの共有 この構成は、自治体 A と自治体 B の共同利用のネットワークアカウントがある構成で、自治体 A と自治体 B の庁舎から S3 に接続するときに VPC エンドポイントを共有することで、同一の VPC エンドポイントを用いて接続するという例です。 こちらは S3 を例にしていますが、インターフェイスエンドポイントのある AWS のサービスが対象で集約が可能です。参考となる詳細については こちら をご参照ください。 PrivateLink 構成 (ネットワークアカウント) と同様で、他に検討すべき事項としては、名前解決の機能をどのアカウントで持たせるかという点ですが、Route 53 Private Hosted Zone を他の VPC へ共有する方法で、エンドポイントを集約できる構成のため、コスト最適化につながります。詳細については、 詳細解説：ガバメントクラウド名前解決編 をご参照ください。 集約を検討する場合のユースケースとしては、以下のパターンがあるかと思います。 単独利用方式中心の場合 回線運用管理補助者や統合運用管理補助者へ依頼 共同利用方式中心の場合 オールインワンパッケージベンダーや回線運用管理補助者へ依頼 ただし、利用方式や ASP 事業者の提供形態に依って必ずしもエンドポイントを集約する構成が取れるとは限らないため、運用管理補助者並びに ASP 事業者と議論の上、構成を検討ください。 まとめ 本ブログでは、ガバメントクラウド上での全体のネットワーク設計の肝である VPC エンドポイント構成例をご紹介しました。重要なポイントとしては、方針の決定に併せて、ネットワーク運用管理補助者や他の事業者との調整事項を決めていただく点が挙げられます。 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたら、お気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介した VPC エンドポイントの構成に関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

Independent Service Vendor (ISV) のユーザーは、コストと運用管理を削減するために、マルチテナントアーキテクチャでホストされたエンドユーザーソリューションを提供することが多くあります。しかし、このアプローチでは、Kubernetes クラスターでリソース枯渇やネットワーク帯域の枯渇の問題が発生し、隣接するワークロードに影響を与える可能性があります。Kubernetes はデフォルトで、 CPU とメモリ などのリソース可用性を制限する機能を提供し、コンピューティングリソースの枯渇を防いでいます。しかし、ワークロードは急速に進化しており、パフォーマンスを向上させるためにネットワーク帯域幅などの他のリソースを使用するようになっています。例えば、pod はレスポンスタイムを改善するために大量のトラフィックをダウンロードすることを選択し、帯域幅の枯渇と隣接する pod への影響を引き起こす可能性があります。 この記事では、 Amazon Virtual Private Cloud (Amazon VPC) CNI プラグインを使用して、この Kubernetes の課題をどのように解決するかを見ていきます。Amazon VPC CNI プラグインを使用して、pod の入力と出力の帯域幅使用を制限することでネットワーク帯域の枯渇を防ぎ、ネットワークの安定性と QoS を確保する方法を示します。 Amazon VPC CNI とは 利用可能な CNI プラグイン は複数ありますが、AWS が Amazon Elastic Kubernetes Service (EKS) 向けに開発した Amazon VPC CNI プラグインは、コンテナネットワーキングが Amazon VPC のネットワーキングとセキュリティ機能を直接利用できるようにします。この CNI プラグインは、ノード上の Elastic Network Interface (ENI) を管理し、 Amazon Elastic Compute Cloud (Amazon EC2) と AWS Fargate の両方に対応しています。 ノードをプロビジョニングすると、プラグインは自動的にプライマリ ENI のノードのサブネットからスロット (IP またはプレフィックス) のプールを割り当てます。これにより、Amazon EKS にデプロイされたアプリケーションの Kubernetes Pod ネットワーキングと接続を可能にし、Amazon VPC ネットワーキング機能が直接 Kubernetes pod に統合されます。例えば、pod には VPC から独自のプライベート IP アドレスが割り当てられ、セキュリティグループを pod に直接適用できます。 帯域幅制限機能を有効にする場合、Amazon VPC CNI プラグインは bandwidth プラグイン に依存し、`tc` (Traffic Control) などの Linux トラフィック制御ユーティリティを使用して、個々のコンテナまたは pod の入力および出力帯域幅の制限を制御します。 ウォークスルー CNI プラグインを使用して、入力と出力のトラフィックシェーピングを有効にする方法を見ていきましょう。 前提条件 このウォークスルーを行うには、以下の前提条件を満たしている必要があります: Amazon EKS クラスターバージョン 1.24 以上 Amazon VPC CNI バージョン 1.15.0 以上 kubectl バージョン 24 以上 eksctl バージョン 175.0 以上 Step0: EKS クラスターを eksctl で作成 (オプション) この構成は、EKS クラスターバージョン 1.28 をプロビジョニングするために `eksctl` で使用されます。すでに独自の EKS クラスターがある場合は、このステップをスキップできます。 この EKS クラスターを v1.28 でプロビジョニングする場合は、`kubectl` も v1.28 であるか、クラスターとのマイナーバージョンの差が 1 以内であることを確認してください。例えば、v1.28 のクライアントは、v1.27、v1.28、v1.29 のコントロールプレーンと通信できます。 apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: dev-cluster region: ap-southeast-1 version: 1.28 managedNodeGroups: - name: ng-1-workers labels: { role: workers } instanceType: m6a.large desiredCapacity: 2 volumeSize: 30 privateNetworking: true Step1: EC2 インスタンスの CNI bandwidth プラグインを有効化 pod の帯域幅制限を設定する前に、Amazon EC2 にアクセスして CNI プラグインの帯域幅機能を有効にする必要があります。 AWS System Manager Session Manager を使用して Amazon EC2 に接続することをお勧めします。Session Manager は、インバウンドポートを開く必要がなく、踏み台ホストを維持したり、Secure Shell (SSH) キーを管理する必要がないため、セキュアで監査可能なノード管理を提供します。したがって、セキュリティを強化し、攻撃対象領域を減らすことができます。 上記の `eksctl` で EKS クラスターをプロビジョニングすると、デフォルトで Amazon Linux Amazon Machine Images (AMIs) の Amazon EKS 最適化版が使用されます。この AMI を使うと、EC2 インスタンスが必要な要件で構成されるため、Session Manager を使ってインスタンスに接続できるようになり、さらなるセットアップは不要です。 Amazon EC2 コンソールを使用して Session Manager で Linux インスタンスに接続する方法 Amazon EC2 コンソール を開きます。 ナビゲーションペインで、 Instances を選択します。 インスタンスを選択し、 Connect を選択します。 Session Manager を選択します。 Connect を選択します。 Session Manager のセットアップ方法と詳細については、 Session Manager のセットアップ をご覧ください。インスタンスに接続したら、次のコマンドを実行してください。 sudo su cd /etc/cni/net.d echo "$(cat 10-aws.conflist | jq '.plugins += [{"type": "bandwidth", "capabilities": {"bandwidth": true}}]')" > 10-aws.conflist 次の JSON オブジェクトが `plugins` キーの下に追加されます。 { ... "plugins": [ ... { "type": "bandwidth", "capabilities": {"bandwidth": true} } ] } Step2: iperf と tc CLI の EC2 インスタンスへインストール この手順では、帯域幅制限をチェックおよびテストするために使用される必要な CLI ツール `iperf` と `tc` をインストールします。 `iperf` はネットワークパフォーマンスを測定するためによく使われるコマンドラインツールです。クライアントとサーバー間、またはサーバー間の帯域幅を測定するのに使えます。 `tc` (Traffic control) は、Linux のユーザースペースユーティリティコマンドで、ネットワークインターフェースのトラフィック制御設定を構成・管理できます。ネットワークトラフィックシェーピング、スケジューリング、ポリシー付け、優先順位付けなど、強力なツールセットを提供します。 # If you are using Amazon Linux 2, need to enable epel before getting iperf package # https://repost.aws/knowledge-center/ec2-enable-epel sudo amazon-linux-extras install epel -y sudo yum install iperf -y sudo yum install iproute-tc -y Amazon Linux 2023 は Extra Packages for Enterprise Linux (EPEL) をサポートしておらず、`yum` を通して `iperf` をインストールすることはできません。ただし、 この AWS Knowledge Center の記事 の手順に従えば、AL2023 に iperf を手動でダウンロードしてインストールできます。 Step 3: 帯域幅制限なしで pod をデプロイ まず、標準のアプリケーションである `nginx` を EKS クラスターにデプロイします。後で 2 つの設定を比較しやすくするため、現時点では帯域幅制限は設定されていません。 `nginx-deployment.yaml` という新しいファイルを次の定義で作成してください: cat < nginx-deployment.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: securityContext: runAsNonRoot: true containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 8080 securityContext: readOnlyRootFilesystem: true allowPrivilegeEscalation: false volumeMounts: - mountPath: /tmp name: tmp volumes: - emptyDir: {} name: tmp EOF 次のコマンドを実行してデプロイします: kubectl apply -f nginx-deployment.yaml pod の IP とその pod が存在するノードの IP を確認するには、次のコマンドを実行します: kubectl get pods -o wide Step4: 入力/出力制限に関するテスト pod アプリケーションをデプロイする際に帯域幅の制限を指定しなかった後、EC2 インスタンス内で `tc` コマンドを使用して現在の `qdisc` を確認します。 `qdisc` (キューイング規律) は、ネットワークインターフェースでパケットがキューイングされ、送信されるための方法を管理するアルゴリズムです。カーネルのパケットキューからネットワークインターフェースカードへパケットが送出される順序を決定します。 `qdisc` を確認するには、次のコマンドを実行してください: tc qdisc show 出力: `qdisc pfifo_fast` は単純な先入れ先出し (FIFO) キューを使用し、トラフィックシェーピングや優先順位付けは行いません。 qdisc noqueue 0: dev lo root refcnt 2 qdisc mq 0: dev eth0 root qdisc pfifo_fast 0: dev eth0 parent :4 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth0 parent :3 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth0 parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth0 parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc noqueue 0: dev eniaafbc306ee3 root refcnt 2 qdisc noqueue 0: dev eni8abfd912174 root refcnt 2 qdisc mq 0: dev eth1 root qdisc pfifo_fast 0: dev eth1 parent :4 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 parent :3 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc noqueue 0: dev pod-id-link0 root refcnt 2 qdisc noqueue 0: dev enifb88ae1f006 root refcnt 2 次に、`iperf` を使用して帯域幅の測定を行います。最大の帯域幅を測定するには、次のコマンドを実行します。 Step3 で取得した IP で {POD_IP} を置き換えてください。 iperf -c {POD_IP} -p 8080 -i 1 出力: ------------------------------------------------------------ Client connecting to 192.168.113.250, TCP port 80 TCP window size: 3.90 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.137.88 port 51026 connected with 192.168.113.250 port 80 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 594 MBytes 4.98 Gbits/sec [ 3] 1.0- 2.0 sec 592 MBytes 4.97 Gbits/sec [ 3] 2.0- 3.0 sec 592 MBytes 4.97 Gbits/sec [ 3] 3.0- 4.0 sec 592 MBytes 4.96 Gbits/sec [ 3] 4.0- 5.0 sec 592 MBytes 4.96 Gbits/sec [ 3] 5.0- 6.0 sec 592 MBytes 4.96 Gbits/sec [ 3] 6.0- 7.0 sec 592 MBytes 4.97 Gbits/sec [ 3] 7.0- 8.0 sec 592 MBytes 4.96 Gbits/sec [ 3] 8.0- 9.0 sec 592 MBytes 4.96 Gbits/sec [ 3] 9.0-10.0 sec 591 MBytes 4.96 Gbits/sec [ 3] 0.0-10.0 sec 5.78 GBytes 4.97 Gbits/sec Step5: 帯域幅制限付きで pod を再デプロイ pod の出力入力制限なしでの帯域幅をテストした後、出力入力の帯域幅制限を指定するために、次のアノテーションをデプロイメントに追加します: `kubernetes.io/ingress-bandwidth` – 受信帯域幅を制御するため `kubernetes.io/egress-bandwidth` – 送信帯域幅を制御するため `nginx-deployment.yaml` のマニフェストを更新し、同じコマンドで再デプロイしてください: cat < nginx-deployment.yaml --- apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx annotations: kubernetes.io/ingress-bandwidth: 1G kubernetes.io/egress-bandwidth: 1G spec: securityContext: runAsNonRoot: true containers: - name: nginx image: nginxinc/nginx-unprivileged ports: - containerPort: 8080 securityContext: readOnlyRootFilesystem: true allowPrivilegeEscalation: false volumeMounts: - mountPath: /tmp name: tmp volumes: - emptyDir: {} name: tmp EOF アプリケーションを再デプロイしてください: kubectl apply -f nginx-deployment.yaml Step6: 入力/出力制限に関するテスト pod マニフェストを更新して、入力と出力の帯域幅制限を設定した後、Step4 を繰り返して、新しい構成が有効になっていることを確認します。 `qdisc` を確認するには、次のコマンドを実行してください: tc qdisc show 出力: qdisc noqueue 0: dev lo root refcnt 2 qdisc mq 0: dev eth0 root qdisc pfifo_fast 0: dev eth0 parent :4 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth0 parent :3 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth0 parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth0 parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc noqueue 0: dev eniaafbc306ee3 root refcnt 2 qdisc noqueue 0: dev eni8abfd912174 root refcnt 2 qdisc mq 0: dev eth1 root qdisc pfifo_fast 0: dev eth1 parent :4 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 parent :3 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 parent :2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc pfifo_fast 0: dev eth1 parent :1 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 qdisc noqueue 0: dev pod-id-link0 root refcnt 2 qdisc tbf 1: dev enif603d342b24 root refcnt 2 rate 1Gbit burst 512Mb lat 25ms qdisc ingress ffff: dev enif603d342b24 parent ffff:fff1 ---------------- qdisc tbf 1: dev bwp3163ee8c94ce root refcnt 2 rate 1Gbit burst 512Mb lat 25ms 出力から分かるように、`qdisc` は `tbf` (Token Bucket Filter) を使用しています。これはトラフィックコントロールで利用可能な階層構造を持ったキューイング規律です。 最大の実現可能な帯域幅を測定するには、次のコマンドを実行してください。 iperf -c {POD_IP} -p 8080 -i 1 出力: ------------------------------------------------------------ Client connecting to 192.168.125.111, TCP port 80 TCP window size: 1.68 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.137.88 port 43566 connected with 192.168.125.111 port 80 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 1.0 sec 594 MBytes 4.98 Gbits/sec [ 3] 1.0- 2.0 sec 149 MBytes 1.25 Gbits/sec [ 3] 2.0- 3.0 sec 118 MBytes 989 Mbits/sec [ 3] 3.0- 4.0 sec 118 MBytes 990 Mbits/sec [ 3] 4.0- 5.0 sec 119 MBytes 998 Mbits/sec [ 3] 5.0- 6.0 sec 118 MBytes 988 Mbits/sec [ 3] 6.0- 7.0 sec 119 MBytes 998 Mbits/sec [ 3] 7.0- 8.0 sec 118 MBytes 989 Mbits/sec [ 3] 8.0- 9.0 sec 118 MBytes 987 Mbits/sec [ 3] 9.0-10.0 sec 119 MBytes 1.00 Gbits/sec [ 3] 0.0-10.0 sec 1.65 GBytes 1.42 Gbits/sec 帯域制御の前後: 次の視覚化は、帯域幅を Gbits/sec で示しています。オレンジ線は、デプロイメントに帯域幅のアノテーションを追加する「前」を表しています。青線は、帯域幅のアノテーションを設定した「後」を表しています。 クリーンアップ 以下のコマンドでデプロイメントを削除します: kubectl delete -f nginx-deployment.yaml 以下のコマンドで Step0 でプロビジョニングした EKS クラスターを削除するには: eksctl delete cluster --name dev-cluster 考慮事項 bandwidth プラグインは、この記事を書いている時点では、Amazon VPC CNI ベースのネットワークポリシーと互換性がありません。ネットワークポリシーエージェントは、Traffic Classifier (tc) システムを使用して、pod に対して設定されたネットワークポリシーを適用します。bandwidth プラグインが有効になっていると、bandwidth プラグインと Network Policy エージェントの tc 設定が競合するため、ポリシーの適用に失敗します。私たちは、ネットワークポリシー機能と併せて bandwidth プラグインをサポートする方法を検討しており、この問題は AWS GitHub の Issue で追跡されています。 おわりに この記事では、Amazon VPC CNI プラグインとその機能を使用して、Amazon EKS 上で pod として実行されているアプリケーションの入力および出力帯域幅を制限する方法を示しました。これを使用することで、ユーザーはネットワーク上の pod の使用を制限し、Kubernetes クラスター内の他の pod による大量のネットワーク消費によるネットワーク帯域の枯渇を防ぐ機能を実装できます。 翻訳はソリューションアーキテクト祖父江が担当しました。原文は こちら です。

本ブログは 2024 年 4 月 24 日に公開されたBlog “ Using Protective DNS services with AWS workloads ” を翻訳したものです。 Protective DNS サービス (一般的に PDNS として知られています) は、インフラストラクチャのセキュリティを基礎から強化したい場合は最適なソリューションです。トラフィックのフィルタリングに、ソフトウェアベースのエージェントやデバイスを使用する従来の方法とは異なり、PDNS サービスは独自のアプローチを採用しています。ユーザーが行う DNS リクエストを詳しく分析し、サービス内で事前に定義されたルールに基づいて応答を制御します。 このプロアクティブな戦略は、ネットワークを基礎レベルで保護するだけでなく、潜在的な攻撃者が、最初の攻撃の足がかりを作る機会を防ぐこともできます。さらに、PDNS サービスは DNS トラフィックをリアルタイムで可視化し、セキュリティ脅威の迅速な特定と対応を可能にします。このブログでは、PDNS サービスと Amazon Web Services (AWS) クラウドのワークロードとのシームレスな統合を解説し、クラウド環境内でのサイバーセキュリティ強化における PDNS サービスの有効性を解説します。 PDNS サービスの仕組み 公共部門や、セキュリティ要件が高い業種では、重要なワークロードやデバイスが容易に侵害されないことを確認する必要がある場合があります。ワークロードが、DNS 名を解決できないようにして悪意のあるウェブサイトへのリクエストを防ぐことは、重要な防御手段です。 例えば、PDNS サービスはボットネットの脅威を軽減することができます。ボットネットは多くの場合、指示を受け取り結果を報告するために、コマンド＆コントロール インフラストラクチャに接続する必要があります。さらに、次のターゲットとなるホストを見つけ、コントロールインフラストラクチャに報告し、新しい指示を待ち、ネットワーク上で拡散しようとすることもよくあります。したがって、ボットネットの動作は単一の特定のホストに限定されず、攻撃範囲が広いため、感染がより深刻な問題となります。ボットネット攻撃の影響は、コントロールインフラストラクチャへのアクセスを制限することで、大幅に軽減できます。さらに、悪意のある第三者へのデータ流出を試みる攻撃を阻止することもできます。 PDNS サービスは DNS レスポンスを変更するため、通常その動作は レスポンスポリシーゾーン (RPZ) を使用して設定されます。RPZ は、DNS サーバーの名前解決機能と連携して動作するポリシーです。RPZ ポリシーは通常、信頼できるソースから受け取った脅威インテリジェンス情報に合わせて定期的に更新されます。脅威インテリジェンス情報は、既存のネットワークや公開・商用ソースから収集することができます。RPZ ポリシーは、Berkeley Internet Name Domain (BIND) DNS ゾーンと 同じ形式で記述されます 。 クライアントが DNS リクエストを行うと、そのリクエストは PDNS サービスに転送されます。PDNS サービスは、RPZ ポリシー内でリクエストされたドメインを検索し、ポリシーの設定に従って応答します。PDNS サービスは、設定に応じて次のような動作があります。 クライアントに、ドメインのアドレス解決ができなかったことを示す NXDOMAIN 応答 ( RFC8020 で定義) を返します。 通常の DNS リゾルバーが返すアドレスとは異なるアドレスで応答します。これにより、組織は例えば、クライアントにWebページを表示させ、セキュリティ上の問題が発生したことと、サポートを受ける方法を説明することができます。 カスタムレスポンスで応答し、応答をログに記録し、セキュリティ運用チームにそのような応答がされたことを通知できます。これにより、チームは問題を調査することができます。さらに、カスタムレスポンスは脅威が継続している間では特に有用で、セキュリティ運用チームがネットワーク上のクライアントに不必要な悪影響を与えることなく、リアルタイムで問題を調査することができます。 PDNS サービスは、官民問わず世界中の様々な組織によって提供されています。例として、 Cisco Umbrella 、 Vercara UltraDDR 、 米国国家安全保障局 (NSA) サイバーセキュリティ協力センター (CCC) の Protective DNS サービス 、そして 英国国家サイバーセキュリティセンター (NCSC) の Protective DNS サービス などがあります。 PDNS サービスの一部のプロバイダーは、既知の脅威リストだけでなく、新規の疑わしいドメイン名を自動的に判別するなどの追加機能を提供しています。脅威インテリジェンスの情報源の幅広さに加えて、これらの機能が PDNS サービス間の差別化要因となっています。PDNS サービスの利用を検討している場合は、可能な限り、複数サービスを相互に比較検討すると良いでしょう。 AWS の PDNS 機能を実装する場合は AWS Network Firewall または Amazon Route 53 Resolver DNS Firewall をご利用をできますが、次のセクションでは、AWS ワークロードに対して、サードパーティの PDNS サービスを実装するアーキテクチャの例を示します。 PDNS サービスによる AWS ワークロードの保護 Network Firewall と Route 53 DNS Firewall は、PDNS サービスを構築する際の優れた選択肢です。しかし、サードパーティの PDNS サービスが提供する追加の必須機能が必要な場合があります。サードパーティの PDNS サービスが提供する包括的な脅威インテリジェンスへのアクセスが必要な時などです。この例では、図 1 のようなアプローチを用いて、 Amazon Route 53 Resolver で外部の PDNS サービスにトラフィックを誘導することができます。 図 1. Amazon Virtual Private Cloud (VPC) とプライベート DNS (PDNS) サービスを統合するアーキテクチャの例。主要なコンポーネントは、VPC、Route 53 Resolver、そしてオプションとして Route 53 Resolver DNS Firewall です。 前述のアーキテクチャは、プライベートサブネットで実行されているアプリケーションが Amazon Route 53 Resolver アウトバウンドエンドポイントとどのようにやり取りするかを示しています。 アプリケーションをホストするプライベートサブネットには、ネットワーク ACL (NACL) が設置されており、サブネットレベルで特定のインバウンドまたはアウトバウンドトラフィックを許可または拒否します。 トラフィックが NACL によってブロックされない場合、パブリックサブネットの NAT Gateway に転送されます。 NAT Gateway は、トラフィックを Route 53 Resolver DNS Firewall に送信します。ポリシーに従い、トラフィックをフィルタリングし、アウトバウンド DNS トラフィック を制御します。 Route 53 Resolver DNS Firewall は、トラフィックを Route 53 Resolver アウトバウンドエンドポイントに転送します。 トラフィックが Route 53 Resolver に到達すると、可観測性のためにログ記録が行われます。 Route 53 Resolver クエリログ により、VPC 内の DNS クエリのインサイトが得られ、コンプライアンス、脅威検出、トラブルシューティングの目的に役立ちます。ログは Amazon CloudWatch Logs に送信され、そこから Amazon CloudWatch Log Insights を使用してさらなる分析を行い、メトリクスやアラームを作成することができます。 最後に、リクエストは PDNS サービスに転送され、PDNS サービスはクライアントのリクエストに応答する責任を負い、独自のルールと脅威インテリジェンスを使用して適切に応答します。 この設計を実装すると、リゾルバルールが適用された VPC で実行されるワークロードが保護されます。この設計により、外部アドレス(VPC 内のリソースや AWS サービスに解決されないアドレスなど) の名前解決を、複数の VPC にわたって信頼できるリゾルバーで行えるようにスケールします。クロスアカウントネットワーキングを適切に考慮すれば、トランジットゲートウェイを通じて実装することで、複数のアカウントから PDNS サービスへの中央集中型アクセスを提供することも可能です。 多くの場合、サードパーティの PDNS サービスを使用する場合、ルールを修正することで PDNS サービスの応答方法を設定することもできます。これにより、自前でサービスを運用する場合と比べて比類のない柔軟性が提供されます。PDNS サービスがそのような機能を提供している場合、信頼できる脅威インテリジェンスに裏打ちされたソースを利用しながら、カスタムの動作を定義することができます。 まとめ 規制対象の業界や、セキュリティ要件が高い組織では、重要なワークロードが DNS ベースの攻撃の容易な標的にならないように、DNSリクエストを確実に制御する必要があります。重要なワークロードをサポートするインフラストラクチャが行う DNS リクエストの可視性を得ることで、セキュリティチームはアプリケーションの動作をリアルタイムで把握でき、異常を発見するのに役立ちます。Route 53 DNS Firewall や Network Firewall などのサービス、あるいはサードパーティのソリューションを使用して Protective DNS 機能を提供することで、組織はボットネットやデータ漏洩などの脅威を軽減できます。 このサンプルアーキテクチャは、VPC 間の保護を確保するだけでなく、包括的なロギングを通じてコンプライアンス遵守と脅威検出を可能にし、CloudWatch や既存のセキュリティツールなどのサービスを使用した将来の分析を可能にします。 AWS ワークロードを Protective DNS サービスと統合することで、高度なセキュリティ要件を持つ組織は、追加のインフラストラクチャを管理する負担なく、DNS ベースの攻撃から保護する信頼性の高い手段を得ることができます。PDNS サービスと AWS ワークロードの統合は、進化するサイバー脅威に対するクラウドのレジリエンスを強化し、重要なワークロードのための安全な環境を確保します。 Amazon Route 53 Resolver を使用して、ワークロードに対する DNS ベースの攻撃の軽減にすぐに取り組むことができます 。 Awzair Chaudhrey Awzair は Amazon Web Services (AWS) のパブリックセクターでソリューションアーキテクトとして従事しています。彼はセキュリティとネットワーキングに強い情熱を持ち、顧客がクラウドへの移行の過程でベストプラクティスに従えるよう支援しています。仕事以外の時間は、読書や家族と過ごすことを楽しんでいます。 Andrew Langhorn Andrew は、AWSでプリンシパルソリューションアーキテクトとしてパブリックセクターの顧客と協力しています。仕事以外では、レコード・コレクションを充実させたり、ウィスキーの知識を深めたり、定期的に新しい都市や国を訪れるのが好きです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 10 月 24 日に公開されたBlog “ Amazon identified internet domains abused by APT29 ” を翻訳したものです。 APT29 (別名 Midnight Blizzard) が最近、何千もの人々に対してフィッシング攻撃を試みました。 ウクライナ国家コンピューター緊急対応チーム (CERT-UA) の調査を基に、Amazon は最近、ロシアの対外諜報庁 (SVR) とつながりのある APT29 グループによって不正利用されたインターネットドメインを特定しました。今回の事例では、政府機関、企業、軍関係者が標的とされ、フィッシングキャンペーンはロシアの敵対国からの認証情報の窃取を目的としていました。APT29 は対象者を絞った標的型攻撃が代表的な手法ですが、今回ははるかに多くの標的に対し、ウクライナ語のフィッシングメールを送信しました。使用されたドメイン名の一部は、標的に AWS のドメインだと錯覚させようとするものでした（実際には AWS のドメインではありません）。しかし、Amazon が標的だったわけではなく、AWS のお客様の認証情報を狙っていたわけでもありません。むしろ、APT29 は Microsoft リモートデスクトップを通じて標的の Windows 認証情報を狙っていました。この活動を分析した我々は、直ちに APT29 が AWS になりすまして悪用していたドメインを差し押さえるプロセスを開始し、活動を阻止しました。CERT-UA は、この活動に関する追加詳細を含む アドバイザリ を発行しています。 インターネットの安全性を高めるために尽力してくれた Amazon のサイバー脅威インテリジェンスチームと CERT-UA の感謝します。 このブログは、Amazon の最高情報セキュリティ責任者兼セキュリティエンジニアリング部門 VP の CJ Moses が当初 LinkedIn に投稿 したものです。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 CJ Moses CJ Moses は、Amazon の最高情報セキュリティ責任者（CISO）です。この役割において、CJ は Amazon 全体のセキュリティエンジニアリングと運用を指揮しています。彼のミッションは、セキュリティの利点を最も抵抗の少ない道にすることで、Amazon のビジネスを可能にすることです。CJ は 2007 年 12 月に Amazon に入社し、消費者部門の CISO、そして直近では AWS CISO など、様々な役割を経て、2023 年 9 月に Amazon の CISO に就任しました。 Amazon に入社する以前は、連邦捜査局（FBI）のサイバー部門でコンピューターとネットワークへの侵入の技術分析を主導していました。また、空軍特別捜査局（ AFOSI ）の特別捜査官としても勤務していました。CJ は、今日のセキュリティ業界の基礎と見なされる複数のコンピューター侵入調査を主導しました。 CJ はコンピューターサイエンスと刑事司法の学位を持ち、現役の SRO GT America GT2 レースカードライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

MUFG（三菱UFJフィナンシャル・グループ）は、企業の成長を支える3本柱の一つに「企業変革の加速」を掲げています。社長挨拶にもあるように、これまでのカルチャー改革をさらに進展させるとともに、「スピード」を新たな共有価値観に加え、人材・システム・AIなどの経営基盤を強化していくとのことです。 このような取り組みの一環として、三菱UFJ銀行の市場企画部市場エンジニアリング室では、以前からAWSのAI/ML活用を進めてきました。そして今回、より多くの社員にAI/MLに興味を持ってもらうべく、「AWS DeepRacer」を活用したイベントを開催しました。 8月21日の午後、銀行のオフィスがある大手町フィナンシャルシティグランキューブで同室とAWSとが協力し、AWS DeepRacerイベントを実施しました。参加者は、三菱UFJ銀行のほか、三菱UFJ信託銀行、三菱UFJ モルガン・スタンレー証券からも集められ、200名以上が応募。そのうち、110名超がワークショップやオンラインレースに参加しました。 AWS DeepRacerは、自動運転車のレースの楽しさを通じて、ゲーム感覚でAI/MLを体験できるサービスです。日頃業務でAIに触れる機会の少ないメンバーも、楽しみながらテクノロジーを学べる格好の機会となりました。オンラインレースの上位20チームが決勝レースに進出し、最速ラップタイムは7.301秒という驚きのタイムを記録。イベントには2023年度の全日本AWS DeepRacer Championship 優勝者もエキシビジョンレース者として参加し、6.968秒という驚異的な走りを見せつけました。 参加者からは「とても楽しかった」「チーム戦でチームの絆が高まった」「Pythonや機械学習の一端に触れられて有意義だった」などの声が寄せられ、イベント後のサーベイでは88%の参加者が満足したと回答しました。また、AI/MLの業務活用策として「相場予測」「社内マニュアル作成」などの提案もあり、今後の活用に向けた示唆を得られたようです。 三菱UFJ銀行では、この取り組みを通じて、社内DXの推進とAI/ML活用への機運醸成を図っています。企業変革の加速に向けた取り組みは続きます。 三菱UFJフィナンシャル・グループについて 三菱UFJフィナンシャル・グループ（MUFG）は、日本最大の金融グループです。MUFG は、三菱UFJ銀行、三菱UFJ信託銀行、三菱UFJ証券ホールディングス、三菱UFJリース、三菱UFJニコスなどの金融子会社を持ち、銀行、信託、証券、クレジットカード、リース、資産運用などの幅広い金融サービスを提供しています。グループ全体の総資産は約348兆円、国内シェアトップクラスの顧客基盤を有し、世界40か国以上に拠点を展開するなど、グローバルな金融サービスネットワークを構築しています。「企業の成長を支える3本柱」として「企業変革の加速」に力を入れており、DXの推進やAI・データ活用などの取り組みを通じて、顧客ニーズに応える革新的なサービスの提供を目指しています。 AWS DeepRacer について AWS DeepRacer は、強化学習に対応した 1/18 スケールの完全自律型レーシングカー、3D レーシングシミュレーター、およびグローバルレーシングリーグを備えた、強化学習 (RL) を自由自在に操る最速の手段です。デベロッパーは、オンラインシミュレーターで RL モデルのトレーニング、評価、調整を行います。学習したモデルを AWS DeepRacer にデプロイし、実際に自律型車両に搭載して、AWS DeepRacer League Championship Cupでの勝利を目指して AWS DeepRacer リーグで競争できます。 https://aws.amazon.com/deepracer/ 謝辞 アマゾン ウェブ サービス ジャパン合同会社の下記メンバーからブログの内容についてサポートいただきました。 Hattori Kyoko, Bhavesh Dave, Shuto Araki

生成 AI の導入は売上高 500 億円、従業員 1,000 名超の大企業では 7~9 割に達し、フェーズが「導入後」へ移行してきている企業も多いと推察します ( PwC Japan 2024 年春の調査 、また Exa Enterprise AI の調査 を参照しています ) 。導入後の主な課題の一つが、「導入した生成 AI ツールが使われない」ことです。まだまとまったデータを参照できていませんが、各種書籍やレポート等を参照するとチャットツールに代表される生成 AI を誰もが利用できるインフラ基盤の利用率は、導入後 3 割、以後数か月で 1~2 割に落ち込む傾向があります。2024 年に総務省が発表した 情報通信白書 では、日本において生成 AI を個人で利用している割合は 9.1% に留まり、比較対象とした中国 (56.3%)、米国(46.3%)、英国(39.8%)、ドイツ(34.6%) と 4~6 倍の差がありました (個人利用の 9.1% は導入が落ち着いた後の 1~2 割に符号しており、妥当な推計と考えています)。生成 AI を使わない理由は「使い方がわからない」「自分の生活に必要ない」が 4 割を超える主な理由となっており、使い方は伝えれば済むことから 利用促進においては業務・生活への必要性を感じる機会の創出、動機付けが最大の課題 といえます。 本記事では、 AWS の公開する生成 AI 事例 より利用者数の向上に顕著な効果が見られるユースケースを 4 つご紹介します。ぜひ、課題解決に、社内での生成 AI 利用促進に役立てていただければ幸いです。   1. サポートデスク業務での利用 : 30~50% の効率化を実現 マニュアル等の文章に基づき問合せに回答するサポートデスク業務での生成 AI 活用は、30~50% の業務効率化の効果が期待でき担当者の方に積極的に利用いただける傾向があります。 SBI 生命保険株式会社様 では、社内のサービスデスク業務に生成 AI を活用しています。誰もが一度は経験したことがあるであろうアカウントロック解除のプロセスを、 AI オペレーターで自動化されています。これにより対応部門の稼働が 40% ほど効率化されています。 株式会社セゾンテクノロジー様 では、お客様向けサポートとして HULFT 製品のテクニカルサポートセンターで生成 AI を活用した回答支援のシステムを RAG (検索拡張生成) で実装、回答作成時間を最大 30% 短縮しています。 電話からの受付、コールセンター業務では文字起こし機能と連携させることでさらに業務を効率化できます。 株式会社 PKSHA Communication 様 ではコンタクトセンターの業務効率化ツール「PKSHA Speech Insight」に文字起こしと生成 AI による要約・記録の機能を実装しオペレーターの方の通話後業務の 50% 削減を達成しています。 サポート業務は一定量の業務が定常的にあるため、日常的な利用を促進したい場合まず着目したいユースケースです。AWS では、Amazon Bedrock による生成 AI モデルの利用はもちろん、Amazon Transcribe による文字起こしと連携させたり、 クラウドベースのコンタクトセンターである Amazon Connect と連携したソリューション を構築できます。Amazon Transcribe による文字起こしとの連携は、AWS がオープンソースで公開している Generative AI Use Cases JP (GenU) ですぐに試すことができます。GenU はコマンドを 3 行実行するだけでデプロイができます。 2. 議事録作成の効率化 : 作成時間を 30%~ 削減 お客様との商談、会議の議事録作成で生成 AI を活用することで議事録の作成時間を数時間削減する効果が期待できます。会議をしていない企業はほぼないと思いますので、日常的な利用増を図るうえで重要なユースケースです。 KDDI アジャイル開発センター株式会社様 では、営業日報の作成に Amazon Transcribe による文字起こしと Amazon Bedrock を活用し、作成時間を最大 1 時間削減するとともに「そのまま使えるレベル」と評価を得ています。検索拡張生成を用いた提案商材の検索なども進めており、さらなる効果・利用の向上を図っています。 日本電気株式会社 (NEC) 様 でも、議事録作成に生成 AI を活用されています。既存の社内サービスでは基盤モデルの制約上 30 分以上の会議に対応できない課題がありましたが、長いコンテキストを扱うことができる Claude により分割の手間なく一括で要約できるようになり議事録作成にかかる時間を 3 割削減されています。 株式会社明電舎様 では、日々の議事録作成業務に課題を感じ GenU を導入、わずか 1 ヵ月で開発を完了しています。導入 2 ヵ月後の段階では 1 日平均 200 名 ( 5% ) が日常的に利用し高いフィードバックを得ています。議事録要約にとどまらず、GenU に収録されている翻訳やチャットなど 11 種類の機能を用い利用の拡大を図られています。 他の事例でも議事録作成の効果の高さを伺うことができます。株式会社 Poetics 様では商談の記録から文字起こし、要約まで一気通貫で行えるサービス JamRoll を提供しており、 生成 AI 要約機能の導入は成約率 1.5 倍を達成する 訴求力のある機能となっています。さらに、エピックベース株式会社様では議事録作成を簡単に行える議事録 SaaS「 スマート書記 」を提供しており、リアルタイムで文字起こしと基盤モデルによる補正・校正を実施したうえで文書内容をドラッグ&ドロップするだけで議事録が作成できるサービスを提供しています ( 画面イメージはぜひ特集ブログをご参照ください ) 。 議事録作成は生成 AI の利用を促すうえで効果的な機能の一つといえ、AWS にて GenU を立ち上げて頂くのはもちろん、 Poetics 様やエピックベース様のような AWS のお客様の SaaS を利用いただくことでも活用を促すことができます。 3. 組織間でのナレッジの共有 : 生成 AI 利用のスケール 部門内では資料のありかがわかる、 XX さんに聞けばわかる、とナレッジの共有は生成 AI の力を借りるまでもなく果たされているかもしれませんが、壁を隔てた組織間でのナレッジ共有となると一筋縄ではいきません。生成 AI は、この壁を乗り越えるために活用できます。 RIZAP グループ様 は ( 事例公開時 ) 約 1500 店舗まで拡大した chocoZAP 事業や約 60 社のグループ企業を包含しており、それらの従業員向け資料や手順書は膨大な量になります。グループ間、店舗間での知識共有を促すため、社内独自の RIZAP のトレーナー、従業員が見るマニュアル（店舗業務、ボディメイク、マシンメンテナンス、商品等、全店通達、福利厚生、研修）など約 3000 ファイルをナレッジとして蓄積した RAG (検索拡張生成) のシステムを構築し、月あたり約400 件 (平均対応時間 20 分/件) あった業務ヘルプへの問合せ時間の削減をされています (詳細は “ RIZAP が生成 AI と AWS で社内知識共有を革新 – AI チャットボットで業務効率と顧客満足度の向上を実現 ” もご参照ください)。事業 × 業務の数だけ文書が増えていく中、事業をまたいだ業務の知見を共有できる仕組みはグループ全体における “日常使い” につながるユースケースといえます。 鴻池運輸様 でも部門間の暗黙知を明らかにし、共有するために生成 AI を活用されています。グループ全体で約 24,000 名の従業員が所属し、国内外に多数の拠点を展開する中、拠点ごとに課題解決のため評価した自動化・省力化機器などの検証結果や費用対効果が散在しており、重複した検証をしコストがかさんでいる課題がありました。ナレッジの共通化の取り組みは進めていたものの、検索に 5 分程度かかり利用も月間で 150 件程度と落ち込んでいました。生成 AI を利用することで非構造化データの扱いが容易になり、社内ナレッジポータルへの月間アクセス数は 10~15 倍に向上しています ( 詳細は “ 鴻池運輸様におけるAWS生成AI事例：Amazon Bedrockによる社内ナレッジの共通知化 ” もぜひご参照ください )。 本セクションの最後に、有効なナレッジ共有のヒントとなる事例をご紹介します。 ケンブリッジ・テクノロジー・パートナーズ株式会社様 では RAG (検索拡張生成) のナレッジとして社内の知財ドキュメントだけでなく Slack や社員ブログなどちょっとしたアウトプットも取り込むことで回答精度を 20.5% 向上させています。私たちが日ごろ行うコミュニケーションの中で知識を獲得するように、口頭・ちょっとしたナレッジを蓄積しておくことが効果的であることを示す事例となっています。 情報の共有が有用であるとひとたび理解されれば、単一部門でのナレッジ共有の枠を超え利用者数は大きく拡大するでしょう。 4. 業務文書作成の効率化 : 作業時間を 60~90% 削減 企業では、様々な人が様々な文章を書いています。製品要求仕様書、設計書、テスト仕様書、発注書、見積書、会計報告から広報まで、専門知識を持つ担当者が過去の文章やガイドラインを参照しながら文章を執筆しています。こうした作業の効率化にも生成 AI が活用できます。 株式会社 PURPOM MEDIA LAB 様 は、ビジネスモデルキャンバスを自動で生成する機能を提供しています。ビジネスモデルキャンバスは名前の通りビジネスモデルを表現するのに役立つフレームワークで、新規ビジネスや事業を企画する際にステークホルダーと考慮すべき観点を議論するのに最適で、自動作成によりコミュニケーションコストの 80% 削減を達成されています ( 詳細は “ 株式会社 PURPOM MEDIA LAB 様の AWS 生成 AI 活用事例「Amazon Bedrock を活用したビジネスモデルジェネレータ開発」 ” もご参照ください ) 。 バリューキャンバスの作成、深堀ができる Value Discovery もビジネスアイデアを検証するのに役立つサービスです。AWS は Value Discovery を活用し生成 AI のユースケースを検討するイベントを何度が支援しており、関心ある方は M L Enablement Workshop のページ をご参照ください。 テクノブレイブ株式会社様 では、画像付きの運用保守マニュアル ( 手順書 ) の作成に生成 AI を活用し、作成時間を 最大 98%! も削減しています。実装は約 2 ヵ月、しかも担当は生成 AI 初心者のメンバー 3 名と困難な状況でも短期間でリリースを実現されています ( テクノブレイブ様のブログ では本機能のアーキテクチャを参照できます )。 共同ピーアール株式会社様 は国内最大規模の総合 PR 会社で、プレスリリース作成やメディアプロモート等のコンサルティング支援を行っています。プレスリリースは掲載先媒体の論調やテイストに合わせる必要があり、その調査とプレスリリース本体の作成に 10~30 時間を要していました。生成 AI を活用することで、論調分析は 60% 、リリース作成は 33% の工数削減に成功しています。 ビジネスモデル、手順書、プレスリリースと様々な媒体の作成効率化に生成 AI が利用できることを示しました。議事録という一定汎用的な文章から一歩踏み込み、業務独自の文章作成の支援に踏み込むことで日常的かつコア業務での利用につなげることができます。ソースコードは開発者にとって「業務独自文書」の極致であり、もちろんソースコードの開発・テストに生成 AI は役立ちます。 株式会社インサイトテクノロジー様 では、データベースからのデータ抽出・更新をするための SQL の修正提案機能を 1 ヵ月でリリースされています。本機能は東京海上日動システムズ株式会社さまがすでに利用し、 事例として公開されています 。 結論 本記事では生成 AI 活用の停滞を打破するユースケースとして 1) サポートデスク 2) 議事録要約 3) 組織間のナレッジ共有 4) 業務文書の作成補助の 4 点を扱いました。これらのユースケースのポイントとしては、 一定数のユーザーが一定頻度で必ず使う ユースケースである点です。複数この条件を満たすユースケースを発見できれば、それを重ねていくことでユーザーのカバー率が上がり、社員全体での活用が徐々に実現します。実際のお客様事例から得られた知見が、お役に立てば幸いです！

Enel は、32 か国に拠点を置き、82 GW の発電容量を持つ大手総合電力会社です。また同社は、7,600 万人の顧客に対して広大な送配電網を提供し、4,650 万台のスマートメーターを管理する大手送配電事業者としても極めて重要な役割を果たしています。Enel は 2014 年以来、Amazon Web Services (AWS) を使用した生成 AI の導入を促進する強力な社内ノウハウを開発することにより、人工知能 (AI) に多額の投資を行ってきました。この技術の進歩により、以前は手動で実行されていたタスクをシームレスに自動化することが可能になりました。 背景 Enel は ServiceNow をベースにした高度な IT サービスデスクを運営しており、ユーザーはビジネスアプリケーションのサポートなど、さまざまなニーズに対応するチケットを作成および追跡できます。ビジネスアプリケーションに関連するサービスデスクチケットは、ユーザーアカウントの作成や権限管理から、アプリケーションのエラーやパフォーマンスの問題まで、さまざまなトピックをカバーしています。これらの問題は、専任のアプリケーション管理サービス (AMS : Application Management Service) チームによって管理されます。 Enel は長年にわたり、特に標準的な問題や些細な問題について、必要な品質と顧客満足度のレベルで自動化が容易に達成できるチケット管理タスクを自動化してきました。ただし、ビジネスアプリケーションに関する非標準的な IT サービスデスクへのリクエストについても、その多くは反復的であり、文書化された手順に関連しているため、自動化することができます。通常、これらのチケットは AMS チームによって手動で分析および処理されるため、スタッフの労力を最適化したり、より複雑な問題に割り当てたりする必要があります。さらに、ワークロードのピーク時には、優先度の低いリクエストがキューに入れられるため、解決に時間がかかり、エンドユーザーの不満も高まります。 Enel は、生成 AI を使用して IT サービスデスクの効率を高める機会を特定しました。基本的なトラブルシューティングに関して自動化を重要なタスクにまで拡張し、人間の関与しない形で解決手順やチケットルーティングを提供できるようにすることで、IT サービスデスクの効率を高めることができると考えました。 Enel にとってこのプロジェクトの目標は、依頼者への指示を生成して自動的に要求に応えるか、または要求と作業メモを最も適切な対応グループにルーティングすることによって、ビジネスアプリケーションに関するチケットの一次対応を自動化することでした。立ち上げ当初の対象範囲は 3 つのビジネスアプリケーションに限定され、1 か月あたりのチケット数は合計 2,000 件でした。今後の目標は、このソリューションをビジネスアプリケーションのポートフォリオ全体に拡大することです。Enel は、一次対応を自動化することで、AMS サポートチームの作業負荷を軽減し、問題解決をスピードアップしながら、AMS スタッフをより複雑で価値の高いタスクに集中させることができます。 解決策 このソリューションは、検索拡張生成 (RAG : Retrieval Augmented Generation) アーキテクチャを中心に設計されており、 Amazon Bedrock を使用しています。Amazon Bedrock は、大手 AI 企業が提供する高性能な基盤モデル（FM）と、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションの構築に必要な幅広い機能を提供するフルマネージドサービスです。 このソリューションでは、Amazon Bedrock 専用のモデルファミリーである Amazon Titan を使用しています。具体的には、Amazon Titan Text Embeddings モデルを使用して Enel のナレッジベースからエンベディング (テキストのセマンティクスをキャプチャするベクトル) を生成します。ナレッジベースは、インシデントクラス、前提条件、根本原因、解決ステップ、およびアプリケーションに関するオペレーション情報を含む一連のランブックで構成されています。エンベディングは計算され、類似検索をサポートするベクトルデータベースインスタンス ( MongoDB Atlas Vector Search ) に保持されます。 次に、ソリューションは Anthropic Claude を使用して、チケットの説明と、ベクトルデータベース内の一致によって提供される追加のコンテキストに基づいて、最も適切なチケット応答を生成します。考えられる対応としては、問題を解決するための指示の提供、詳細情報の要求、作業メモの作成と適切な二次対応のサポートチームへのチケットのルーティング、チケットのクローズ、システムが利用できないことのユーザーへの通知などが含まれます。ソリューションを強化するために、Enel はアプリケーションをホストしているシステムの動作ステータスを確認するための包括的なヘルスチェックを実装しました。 Enel は複数の国と言語にまたがって事業を展開しているため、このソリューションは生成 AI を翻訳にも活用し、ケースの作成に使用された言語を使用して依頼者とやり取りをします。 Enel は、Enel Digital Platform (EDP) に統合されたマイクロサービスを通じてソリューションを開発しました。EDP では、コンテナオーケストレーションに Kubernetes のマネージドサービスである Amazon Elastic Kubernetes Service (Amazon EKS) を使用しています。これらのマイクロサービスは、一連のバッチプロセス (インデックス作成プロセス) とトランザクションユーザーインタラクションプロセス (解決プロセス) という 2 つの主要なプロセスをカバーします。以下の図 1 に示すバッチプロセスは、 Atlassian Confluence にホストされている Enel ナレッジベース (ランブック) からドメイン固有のデータを取得し、取得したデータをトークン化し、エンベディングを生成し、ベクトルデータベースインスタンスにエンベディングを保存または更新します。Orchestration Microservice は、インデックス作成バッチプロセスのさまざまなアクティビティをすべて調整します。 図 1: Enel Digital Platform におけるインデックス作成バッチプロセス トランザクションユーザーインタラクションプロセスを図 2 に示します。このプロセスでは、Enel はすでに ServiceNow と統合して使用しているため、新しいチケットが作成されるとすぐに解決プロセスがトリガーされ、まずトークン化されたチケットのテキストが Amazon Bedrock 経由で Amazon Titan Text Embeddings を使用して、エンベディングに変換されます。 前に説明したように、この初期段階では、ソリューションはビジネスアプリケーションのシステムヘルスチェックを実行します。ビジネスアプリケーションが正常に動作している場合、プロセスはベクトルデータベースから関連するコンテキストを取得し、Amazon Bedrock 経由で Anthropic Claude を使用して解決応答を生成します。生成されたテキストは ServiceNow のチケットに直接追加され、チケットは Runbook にリストされている解決手順に応じて、クローズされるか、ユーザーに返答されるか、適切な対応グループにルーティングされます。Orchestration Microservice は、マイクロサービスやヘルスチェックなど、インタラクティブな解決プロセスのさまざまなコンポーネントをすべて調整します。チケットリクエストのテキストが英語でない場合、このプロセスはさらに複雑になります。この場合、解決プロセスがトリガーされるとすぐにチケットのテキストが翻訳され、解決応答はチケット依頼者の言語で生成されます。 図 2: Enel Digital Platform におけるインタラクティブな解決プロセス ビジネスの成果 サービスデスクのチケットに対する生成 AI を活用したチケット解決の実装が成功した後、Enel は、ケースの解決に必要な時間が 1 日から 2 分未満に短縮されたことを確認しました（注記 1）。さらに、実装されたソリューションにより、チケットの約 15 % が人手を介さずに自動的に解決され、ユーザーへの初回応答に必要な時間が 9 時間から 1 分に短縮されました（注記 2）。これらの結果は Enel の期待に沿ったものであり、同社が次の目標とする、ソリューションの改良とより広範なビジネスアプリケーションポートフォリオへの拡張を後押しします。 長期的な目標 Enel は将来を見据えて、Amazon Bedrock を自社のプラットフォームにさらに深く統合することで、FM と大規模言語モデル (LLM) の使用を既存および将来の製品に拡大する予定です。 “Enel では、効率性の追求はプロセスの合理化とスタッフの生産性の向上から始まります。この取り組みに沿って、私たちは Amazon Bedrock の力を利用して、生成 AI を活用した支援機能のサービスサポートプラットフォームへの統合をテストしました。暫定的な結果から、ケースの解決に必要な労力の大幅な削減に向けた有望な道筋が示されました。” と Enel の ICT Industrial Delivery 責任者である Fabio Veronese 氏は述べています。 結論 この投稿では、エネルギー業界の大手企業である Enel が、生成 AI と Amazon Bedrock を活用して既存の確立された手動プロセスを最適化し、人的労力を軽減しながら主要業績評価指標 (KPI) を改善する取り組みについてご紹介しました。生成 AI を使用してプロセスを最適化し、既存のアプリケーションを変革する方法の詳細については、Amazon Bedrock をご覧ください。 注記 1. この結果は、生成 AI によって完全に解決されたチケットのみを対象としています。 2. これらの結果は、最初のサブセットとして選択された 3 つのアプリケーションに対するチケットについて計算しています。 本記事は、ソリューションアーキテクトの宮城 康暢が翻訳しました。原文は「 Improving staff productivity at Enel using Amazon Bedrock 」を参照してください。 <!-- '"` --> Angela Italiano Angela Italiano は、ENEL の Metering Billing および Credits Grids Delivery ユニットの責任者であり、配電ビジネスの特定のプロセス向けのデジタルソリューションとサービスの開発と実装を主導し、その信頼性を検証しています。Scuola Superiore Sant’Anna と Pisa 大学でビッグデータとソーシャルマイニングの修士号、コンピューターサイエンスとネットワークの国際修士号、コンピューターサイエンスとネットワークの国際修士号、コンピューターサイエンスの学士号を取得しており、これらすべてで、人工知能、生成 AI、データおよびソフトウェアアーキテクチャの分野で豊富な経験を積んでいます。Angela は、IT、プロジェクト管理、ビジネストランスフォーメーションの分野で 12 年の経験があります。 Federica Ferro Federica Ferro は、Enel Grids S.r.l. の Data Competence Center でデータサイエンティストを務め、2019年にストックホルム王立工科大学でシステム、制御、ロボット工学の理学修士号を取得しました。彼女はデジタルトランスフォーメーション、データサイエンス（生成 AI を含む）、人工知能、ビジネスオートメーションプロセスの分野で 5 年の経験があります。彼女は Data Competence Center の貴重なメンバーとしての専門知識を活かして、Enel Grids S.r.l. でこれらの分野のイノベーションに積極的に貢献しています。 Giacomo Tomolillo Giacomo Tomolillo は、AWS のエネルギーおよび公益事業担当のシニアソリューションアーキテクトであり、ソフトウェアソリューションの設計と構築における 10 年以上の経験を活かしています。テクノロジーに対する深い情熱を持つ Giacomo は、コンテナーとサーバーレスアーキテクチャを専門とし、AI と生成 AI テクノロジーの進歩を継続的に探求しています。彼の専門知識は、エネルギーおよび公益事業セクターの効率化とイノベーションを強化するための最先端の AI ソリューションの統合にまで及びます。 Paolo Romagnoli Paolo Romagnoli は、AWS のエネルギーおよび公益事業担当のシニアソリューションアーキテクトです。エンタープライズソリューションの設計と構築に数年の経験を持つ彼は、世界中のエネルギー分野のお客様と協力して、お客様のビジネスと技術のニーズを深く理解し、AWS クラウドと Amazon AI/ML スタックを最大限に活用するソリューションを設計しています。コンピュータービジョン、NLP、生成 AI など、幅広い AWS サービスが関わるさまざまな分野のプロジェクトに携わってきました。彼はテクノロジーと歴史に情熱を持っており、ランニングを楽しんでいます。

Amazon SageMaker Pipelines のビジュアルデザイナーを使用して、生成AIモデルのトレーニング、ファインチューニング、評価、登録、デプロイを行うエンドツーエンドのワークフローを作成できるようになりました。SageMaker Pipelines は、基盤モデルの運用 (FMOps) のために特別に構築されたサーバーレスワークフロー オーケストレーションサービスです。専門的なワークフローフレームワークを学ぶ必要なく、モデル開発やノートブックの大規模実行を自動化し、プロトタイプから本番環境までの 生成 AI ジャーニーを加速します。データサイエンティストや機械学習 (ML) エンジニアは、大規模言語モデル (LLM) の継続的なファインチューニングやスケジュールされたノートブックジョブワークフローなどのタスクにパイプラインを使用できます。パイプラインは、数万のワークフローを並列で実行するようにスケールアップし、ワークロードに応じて自動的にスケールダウンします。 あなたが、生成 AI ワークフローの効率化を目指すパイプラインを利用するのが初めてでも、もしくは経験豊富なユーザーでも、本記事にてステップバイステップで紹介するビジュアルデザイナーを使用して生産性を向上させ、複雑な AI/ML パイプラインの構築プロセスを簡素化することができます。具体的には、以下の内容を学びます。 Amazon SageMaker Studio の新しいビジュアルデザイナーへのアクセス方法。 ドラッグアンドドロップ機能を使用した LLM のファインチューニング用の完全な AI/ML パイプラインの作成。 新しいモデルの ファインチューニング 、モデルのデプロイ、 ノートブックとコードの実行 を含むパイプラインの ステップ の設定。 モデルのパフォーマンスに基づく意思決定を自動化するための条件付きロジックの実装。 合格したモデルを Amazon SageMaker Model Registry へ登録する方法。 Llama ファインチューニングパイプラインの概要 この記事では、 Meta 社の Llama 3.x モデル が金融アプリケーション向けに SEC ファイリング (翻訳者注: 米国証券取引委員会 (SEC) に提出が義務付けられている財務諸表やその他の正式文書のこと) の高品質な要約を提供できるように、LLM カスタマイズ (ファインチューニング) ワークフローを自動化する方法を説明します。ファインチューニングにより、ドメイン固有のタスクでパフォーマンスを向上させるようにLLMを設定できます。ファインチューニング後、Llama 3 8B モデルはアプリケーションユーザーに対して洞察に富んだ財務要約を生成できるようになります。ただし、LLM を 1 度だけファインチューニングするのみでは不十分です。最新の実世界データ (この場合は企業の最新の SEC ファイリング) に合わせて、定期的に LLM をチューニングする必要があります。新しいデータが利用可能になるたびに (例えば、四半期ごとの決算発表後) 、このタスクを手動で繰り返す代わりに、自動的にトリガーされる SageMaker Pipelines を使用した Llama 3 ファインチューニングワークフローを作成できます。これにより、正確性、一貫性、再現性を確保しながら、LLM が生成する財務要約の品質を向上させつづけることができます。 SEC ファイリングのデータセットは Amazon SageMaker JumpStart の S3 バケットを通じて公開されています。以下がパイプライン作成ステップの概要です。 SEC の金融データセットを使用して、SageMaker JumpStart から Meta Llama 3 8B モデルをファインチューニングします。 ファインチューニングした Llama 3 8B モデルを SageMaker Inference へデプロイをするための準備をします。 ファインチューニングした Llama 3 8B モデル を SageMaker Inference にデプロイします。 オープンソースの Foundation Model Evaluations (fmeval) ライブラリを使用して、ファインチューニングしたモデルのパフォーマンスを評価します。 条件ステップを使用して、ファインチューニングしたモデルが望ましいパフォーマンスを満たしているかどうかを判定します。満たしている場合は、ファインチューニングしたモデルを SageMaker Model Registry に登録します。ファインチューニングしたモデルのパフォーマンスが望ましい閾値を下回る場合、パイプラインの実行は失敗します。 前提条件 このソリューションを構築するには、以下の前提条件が必要です。 作業を行うための AWS アカウント。 SageMaker にアクセスするための AWS Identity and Access Management (IAM) ロール。IAM と SageMaker の連携について詳しくは、 Identity and Access Management for Amazon SageMaker をご覧ください。 SageMaker Pipelines ビジュアルエディタにアクセスするためのSageMaker Studio へのアクセス。まず、SageMaker ドメインとユーザープロファイルを作成する必要があります。詳しくは Guide to getting set up with Amazon SageMaker をご覧ください。 モデルをデプロイするための ml.g5.12xlarge インスタンスと、モデルをファインチューニングするための ml.g5.12xlarge トレーニングインスタンス。クォータの引き上げリクエストが必要な場合があります。詳細は Requesting a quota increase をご覧ください。 ビジュアルエディタへのアクセス SageMaker Studio コンソールのナビゲーションペインで Pipelines を選択し、右側の Create in visual editor を選択して、ビジュアルエディタにアクセスします。SageMaker Pipelines は複数のステップ同士を接続して構成されます。まずは、ビジュアルエディタがサポートする Step types の一覧が表示されていることを確認します。 この記事の手順を進める際、いつでもパイプラインの構築プロセスを中断し、進捗を保存して後で再開することができます。ビジュアルエディタの下部にある Export を選択して、パイプライン定義を JSON ファイルとしてローカル環境にダウンロードできます。後で Import ボタンを選択して JSON ファイルを再アップロードすることで、パイプラインの構築を再開できます。 ステップ #1: LLM のファインチューニング 新しいエディタでは、 Fine tune ステップを使用して SageMaker JumpStart からモデルを簡単にファインチューニングできます。 Fine tune ステップをエディタにドラッグし、以下の詳細を入力します: Model (input) セクションで Meta-Llama-3-8B を選択します。ウィンドウの下部までスクロールして EULA に同意し、 Save を選択します。 Model (output) セクションには、デフォルトの Amazon Simple Storage Service (Amazon S3) が自動的に入力されます。モデルアーティファクトを保存する場所を変更する場合は、S3 URI を変更します。 この例では、トレーニング用にデフォルトの SEC データセットを使用します。 Dataset (input) を変更することで、独自のデータセットを使用することもできます。 ml.g5.12x.large インスタンスを選択します。 ハイパーパラメータ設定はデフォルトのままにします。これらはユースケースに応じて調整できます。 (オプション) Details タブの Step display name でステップ名を更新できます。この例では、ステップ名を Fine tune Llama 3 8B に更新します。 ステップ #2: ファインチューニングした LLM のデプロイ準備 モデルをエンドポイントにデプロイする前に、モデル定義を作成します。これにはモデルアーティファクトとモデルをホストするために必要な Docker コンテナが含まれます。 Create model ステップをエディタにドラッグします。 ビジュアルエディタを使用して Fine tune ステップを Create model ステップに接続します。 Settings タブで以下の詳細を追加します。 必要な権限を持つ IAM ロールを選択します。 Model (input) : Step variable と Fine-tuning Model Artifacts を選択します。 Container: Bring your own container を選択し、 Location (ECR URI) に 763104351884.dkr.ecr.&lt;region_name&gt;. amazonaws.com/djl-inference:0.28.0-lmi10.0.0-cu124 (&lt;region_name&gt;をご利用のAWSリージョンに置き換え) を入力します。この例では Large Model Inference Containers (大規模モデル推論コンテナ) を使用します。最新の利用可能なディープラーニングコンテナについては、 GitHub で詳細を確認できます。 ステップ #3: ファインチューニングした LLM のデプロイ 次に、モデルをリアルタイム推論エンドポイントにデプロイします。 Deploy model (endpoint) ステップをエディタにドラッグします。 エンドポイント名として llama-fine-tune などの名前を入力します。 ビジュアルエディタを使用してこのステップを Create model ステップに接続します。 Model (input) セクションで、 Inherit model を選択します。 Model name で Step variable を選択すると、前のステップから Model Name 変数が引き継がれます。 Save を選択します。 Endpoint Type として ml.g5.12xlarge インスタンスを選択します。 ステップ#4: ファインチューニングした LLM の評価 LLM がカスタマイズされエンドポイントにデプロイされた後、現実世界のクエリに対するパフォーマンスを評価する必要があります。これには、 Execute code ステップタイプを使用して、 fmeval ライブラリ の 事実に基づく知識評価 を使用したモデル評価を実行するPythonコードを実行します。 Execute code ステップタイプは新しいビジュアルエディタと共に導入され、Jupyter ノートブック、Python 関数、Shell または Python スクリプトの 3 つの実行モードを提供します。 Execute code ステップタイプの詳細については、開発者ガイドを参照してください。この例では Python 関数を使用します。この関数は fmeval ライブラリをインストールし、評価用のデータセットを作成し、現実世界の事実を再現する能力についてモデルを自動的にテストします。 関数とすべてのインポートされたライブラリを含む 完全な Python ファイルをダウンロード してください。この Python ファイルには以下に示すモデル評価に関するコードが含まれます。 LLM 評価ロジックの定義 プロンプトでエンドポイントをテストするためのプレディクターを定義します。 # Set up SageMaker predictor for the specified endpoint predictor = sagemaker.predictor.Predictor( endpoint_name=endpoint_name, serializer=sagemaker.serializers.JSONSerializer(), deserializer=sagemaker.deserializers.JSONDeserializer() ) # Function to test the endpoint with a sample prompt def test_endpoint(predictor): # Test endpoint and convert the payload to JSON prompt = "Tell me about Amazon SageMaker" payload = { "inputs": prompt, "parameters": { "do_sample": True, "top_p": 0.9, "temperature": 0.8, "max_new_tokens": 100 }, } response = predictor.predict(payload) print(f'Query successful. \n\nExample: Prompt: {prompt} Model response: {response["generated_text"]}') output_format = '[0].generated_text' return output_format output_format = test_endpoint(predictor) エンドポイントの呼び出し: response = runtime.invoke_endpoint(EndpointName=endpoint_name, Body=json.dumps(payload), ContentType=content_type) result = json.loads(response['Body'].read().decode()) データセットの生成: # Create an evaluation dataset in JSONL format with capital cities and their regions capitals = [ ("Aurillac", "Cantal"), ("Bamiyan", "Bamiyan Province"), ("Sokhumi", "Abkhazia"), ("Bukavu", "South Kivu"), ("Senftenberg", "Oberspreewald-Lausitz"), ("Legazpi City", "Albay"), ("Sukhum", "Abkhazia"), ("Paris", "France"), ("Berlin", "Germany"), ("Tokyo", "Japan"), ("Moscow", "Russia"), ("Madrid", "Spain"), ("Rome", "Italy"), ("Beijing", "China"), ("London", "United Kingdom"), ] # Function to generate a single entry for the dataset def generate_entry(): city, region = random.choice(capitals) if random.random() &lt; 0.2: alternatives = [f"{region} Province", f"{region} province", region] answers = f"{region}&lt;OR&gt;" + "&lt;OR&gt;".join(random.sample(alternatives, k=random.randint(1, len(alternatives)))) else: answers = region return { "answers": answers, "knowledge_category": "Capitals", "question": f"{city} is the capital of" } # Generate the dataset num_entries = 15 dataset = [generate_entry() for _ in range(num_entries)] input_file = "capitals_dataset.jsonl" with open(input_file, "w") as f: for entry in dataset: f.write(json.dumps(entry) + "\n") fmeval を使用してモデル評価を設定および実行: # Set up SageMaker model runner model_runner = SageMakerModelRunner( endpoint_name=endpoint_name, content_template=content_template, output="generated_text" ) # Configure the dataset for evaluation config = DataConfig( dataset_name="capitals_dataset_with_model_outputs", dataset_uri=output_file, dataset_mime_type=MIME_TYPE_JSONLINES, model_input_location="question", target_output_location="answers", model_output_location="model_output" ) # Set up and run the factual knowledge evaluation eval_algo = FactualKnowledge(FactualKnowledgeConfig(target_output_delimiter="&lt;OR&gt;")) eval_output = eval_algo.evaluate(model=model_runner, dataset_config=config, prompt_template="$model_input", save=True) # Print the evaluation results print(json.dumps(eval_output, default=vars, indent=4)) LLM 評価ロジックのアップロード 新しい Execute code (Run notebook or code) ステップをエディタにドラッグし、設定パネルの Details タブを使用してステップ名を Evaluate model に更新します。 Execute code ステップの設定を行うには、 Settings パネルで以下の手順に従います: 先ほどダウンロードした python ファイルをアップロードします。 Code Settings で、 Mode を Function に変更し、 Handler を evaluating_function.py:evaluate_model に更新します。Handler 入力パラメータは、:(コロン)を挟んでファイル名を左側に、ハンドラー関数名を右側に配置して構成されます: file_name.py:handler_function Function Parameters (input) の中で、 Add をクリックし、Handlerに渡すパラメータである endpoint_name を parameter name に追加します。 parameter value には先ほど作成したエンドポイント名 (例: llama-fine-tune ) を設定します。 コンテナとインスタンスタイプの設定はデフォルトを保持します。 このステップを設定した後、ビジュアルエディタを使用して Deploy model (endpoint) ステップを Execute code ステップに接続します。 ステップ#5: 条件ステップ モデル評価コードを実行した後、 Condition ステップをエディタにドラッグします。条件ステップは、事実に基づく知識評価スコアが望ましい閾値を超えた場合に、ファインチューニングしたモデルを SageMaker Model Registry に登録します。モデルのパフォーマンスが閾値を下回った場合、モデルはモデルレジストリに追加されず、パイプラインの実行は失敗します。 Details タブで Condition ステップ名を Is LLM factually correct に更新します。 Register model ステップと Fail ステップをエディタにドラッグします。これらのステップの設定は次のセクションで行います。 Condition ステップに戻り、 Conditions (input) に条件を追加します。 最初の String に factual_knowledge を入力します。 テストとして Greater Than を選択します。 2 番目の String に 0.7 を入力します。評価は、データセット内の各プロンプトに対してバイナリ (0/1) で判定を行い、それらの判定結果の平均値を算出します。詳細については、 Factual Knowledge を参照してください。 Conditions (output) セクションで、 Then (execute if true) で Register model を選択し、 Else (execute if false) で Fail を選択します。 このステップを設定した後、ビジュアルエディタを使用して Execute code ステップを Condition ステップに接続します。 Register model ステップと Fail ステップの設定は次のセクションで行います。 ステップ#6: モデルの登録 モデルを SageMaker Model Registry に登録するには、モデルの S3 URI とイメージ URI を含むようにステップを設定する必要があります。 前のセクションで作成した Register model ステップに戻り、ファインチューニングしたモデルのモデルアーティファクトを継承するために、 Fine-tune ステップを Register model ステップに接続します。 ステップを選択し、 Model (input) の下の Add を選択します。 Image フィールドにイメージ URI 763104351884.dkr.ecr.&lt;region_name&gt;. amazonaws.com/djl-inference:0.28.0-lmi10.0.0-cu124 (&lt;region_name&gt;をリージョンに置き換え) を入力します。Model URI フィールドで Step variable を選択し、 Fine-tuning Model Artifacts を選択します。 Save を選択します。 Model group の名前を入力します。 ステップ#7: Fail ステップ キャンバス上の Fail ステップを選択し、モデルがモデルレジストリに登録できなかった場合に表示される失敗メッセージを入力します。例: Model below evaluation threshold. Failed to register. (日本語訳: モデルが評価閾値を下回りました。登録に失敗しました。) パイプラインの保存と実行 パイプラインの構築が完了したら、 Execute を選択し、実行の名前を入力してパイプラインを実行します。その後、パイプラインを選択して進行状況を確認できます。パイプラインの実行には 30 ～ 40 分かかります。 LLM カスタマイズを大規模に実行する この例では、UI から手動でパイプラインを 1 回実行しました。しかし、SageMaker API と SDK を使用することで、通常の CI/CD プロセスの一部として、さまざまなパラメータ (異なる LLM、異なるデータセット、異なる評価スクリプトなど) でこのパイプラインを複数かつ同時に実行できます。SageMaker Pipelines は、AWS アカウント内のパイプラインの数、パイプライン内のステップ数、パイプライン実行の数に基づいて自動的にスケールアップまたはダウンするため、基盤となるインフラストラクチャの容量を管理する必要はありません。Pipelines のデフォルトのスケーラビリティ制限とパフォーマンス向上のリクエストについては、 Amazon SageMaker のエンドポイントとクォータ を参照してください。 クリーンアップ 追加料金が発生しないように、SageMaker モデルエンドポイントを削除します。 まとめ この記事では、Amazon SageMaker Pipelines の新しいビジュアルエディタを使用して Llama 3 モデルをファインチューニングするソリューションを解説しました。LLM をファインチューニングするためのステップと、パイプラインステップで独自のコードを実行する Execute code ステップを紹介しました。ビジュアルエディタは、AI/ML ワークフローを作成および管理するためのユーザーフレンドリーなインターフェースを提供します。この機能を使用することで、大規模な本番環境で試行錯誤することなく、ワークフローを迅速に改善できます。この新機能の詳細については、 Create and Manage Pipelines を参照してください。ぜひお試しいただき、フィードバックをお寄せください！ 翻訳はソリューションアーキテクトの矢永が担当しました。原文は こちら です。 著者について Lauren Mullennex は AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。DevOps、インフラストラクチャ、機械学習の分野で10年の経験を持っています。MLOps/LLMOps、生成 AI、コンピュータビジョンを専門としています。 Brock Wade は Amazon SageMaker のソフトウェアエンジニアです。インフラストラクチャ、DevOps、クラウドサービス、SDK、UIにわたる経験を活かし、MLOps、LLMOps、生成 AI のソリューションを構築しています。 Piyush Kadam は、生成 AI 開発者向けのフルマネージドサービスである Amazon SageMaker のプロダクトマネージャーです。スタートアップや企業のお客様が基盤モデルの力を活用できるよう支援する製品の提供において、豊富な経験を持ちます。

(本記事は 2024/09/18に公開された Troubleshooting managed node issues in Systems Manager with SAW を翻訳した記事です。) はじめに AWS サポートでは、Systems Manager にマネージドノードとして登録されない Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに関する問題をお客様から報告されることがよくあります。これらの問題を解決するためにセキュリティグループ、ネットワーク設定、権限をチェックするのは時間がかかる場合があります。 AWS サポートエンジニアリングは AWS リソースの一般的な問題のトラブルシューティング、診断、修復を支援するために SAW を作成しました。SAW フレームワークは、通常必要となるマニュアルの操作を排除することでトラブルシューティングにかかる時間を短縮するのに役立ちます。 この記事では、SAW を使用してトラブルシューティングプロセスを自動化する方法を紹介します。また、Systems Manager のマネージドノードの問題を監視し自動的に分析するために SAW でアーキテクチャを構成する方法も紹介します。 ソリューションの概要 このソリューションの最初のパートでは、Systems Manager にマネージドノードとして登録されない EC2 インスタンスの問題をトラブルシューティングするために SAW ランブックを使用する方法について説明します。2 番目のパートでは、このトラブルシューティングプロセスを自動化し問題解決を加速するためにアーキテクチャを構成する方法を紹介します。 パート 1 – SAW で根本原因を特定する Systems Manager が Amazon EC2 のマネージドインスタンスを表示しない理由を特定するには、次の手順を実行します: 1. AWSSupport-TroubleshootManagedInstance ランブックを使用します。詳細については、re:Post 記事 How can I troubleshoot why Systems Manager doesn’t show an Amazon EC2 instance as a managed instance? を参照してください。 2. Automation が完了したら、詳細な結果については Outputs セクションを確認します。 例えば、AWS Identity and Access Management (IAM) インスタンスプロファイルに必要な権限がないことが原因で問題が発生している場合、 Outputs セクションには次の詳細が表示されます: 3.結果から特定した問題を修正します。 例えば、前述の問題を修正するには、IAM インスタンスプロファイルに必要な権限を追加します。次に、Systems Manager で EC2 インスタンスがマネージドノードとして登録されているかどうかを確認します。確認するには、AWS Command Line Interface (AWS CLI) コマンド describe-instance-information を実行します: $aws ssm describe-instance-information --filters "Key=InstanceIds,Values=${example-instance}" 上記コマンドの example-instance を EC2 インスタンスの ID に置き換えてください。 注意: AWS CLI コマンドの実行時にエラーが発生した場合は、 最新バージョンの AWS CLI を使用していることを確認してください 。コマンドが正常に実行され、インスタンスの詳細が取得できた場合、そのインスタンスは Systems Manager のマネージドノードとして表示されます。 パート 2 – SAW で問題検出を自動化する SAW を使用して、Systems Manager のマネージドノードの問題を自動的に検出し、根本原因を特定するようにアーキテクチャを構成できます。 以下の前提条件を満たしていることを確認してください: ローカルの開発ワークステーションに AWS SAM CLI をインストールし設定している。 通知設定が有効化されている。 通知設定は以下のいずれかの方法で有効にできます: 作成した Amazon Simple Notification Service (Amazon SNS) トピックに メールアドレスをサブスクライブする 。 Slack でウェブフックを使用してワークフローを構築 し、通知設定を有効にする。 Slack でウェブフックを使用してワークフローを構築する場合は、以下の手順でカスタム変数を設定します。 Starts when an app or service sends a web request の横にある Edit をクリックします。 Set up variables で Add Variable をクリックします。 Key に main と入力し、 Data type は text を選択します。 Add Variable をクリックします。 Key に thread と入力し、 Data type は text を選択します。 Save をクリックします。 Send this message to の横にある Edit をクリックします。 Send a message のページで、 Send this message to: に通知を受け取りたい Slack チャンネルを選択します。次に、 Insert a variable をクリックします。 Message text で main を選択し、 Save をクリックします。 Send this message to の横にある Edit をクリックします。 Send a message のページで、 Send this message to: に Message thread を選択します。次に、 Insert a variable をクリックします。 Message text で thread を選択し、 Save をクリックします。 このウォークスルーのサンプルコードを確認するには、GitHub ウェブサイトの AWS SAW Monitoring And Automatic Analysis Architecture を参照してください。 以下の図は、このソリューションのハイレベルなアーキテクチャを示しています。 このアーキテクチャには以下のコンポーネントが含まれています: モニタリング: Amazon EventBridge が EC2 インスタンスの起動を検出します。EventBridge では、イベントパターンが EC2 インスタンスの RUNNING ステータスと一致すると、AWS Step Functions のステートマシンを開始します。 # Event pattern { "detail-type": ["EC2 Instance State-change Notification"], "source": ["aws.ec2"], "detail": { "state": ["running"] } } EC2 インスタンスを起動した後、Systems Manager エージェントが起動するまでに最長 5 分かかる場合があります。そのため、ステートマシンは分析を実行する前に数分間待機します。 分析 : Step Functions は以下の手順を実行します: EC2 インスタンスがマネージドノードとして登録されていない場合、SAW ランブック AWSSupport-TroubleshootManagedInstance を実行します。 SAW 分析が完了したかどうかを確認するために、 DescribeAutomationExecutions API を定期的に呼び出します。 SAW 分析が完了した後、AWS Lambda 関数を呼び出します。 通知 : Lambda 関数は通知用の文字列をフォーマットします。その後、設定に基づいて Slack またはメールで通知を送信します。 ソリューションのウォークスルー このセクションでは、SAW を使用してマネージドノードの問題を自動的に検出するソリューションのウォークスルーについて説明します。ウォークスルーのサンプルコードを確認するには、GitHub ウェブサイトの aws-samples を参照してください。 1. 以下のコマンドを実行して、AWS Secrets Manager に SlackWebHookUrl を登録します: $ export SLACK_WEB_HOOK_URL="YOUR_SLACK_WEB_HOOK_URL" $ export SECRET_NAME="YOUR_SECRET_NAME" $ aws secretsmanager create-secret --name ${SECRET_NAME} --secret-string ${SLACK_WEB_HOOK_URL} 2. リポジトリをローカルの開発ワークステーションにクローンします: $ git clone https://github.com/aws-samples/introducing-monitoring-and-automatic-analysis-architecture-using-aws-saw.git $ cd introducing-monitoring-and-automatic-analysis-architecture-using-aws-saw/ 3. AWS SAM テンプレート template.yaml で定義されている Lambda 関数、EventBridge ルール、Step Functions ステートマシン、および関連する IAM ロールをビルドしてデプロイします。 注意: デプロイウィザードでパラメータを入力します。例えば、Amazon SNS トピックの ARN、Secrets Manager の SECRET_NAME、またはその両方です。SNS トピックを AWS Key Management System (AWS KMS) で暗号化した場合は、AWS KMS キーの ARN をパラメータとして指定します。 $ sam build $ sam deploy –guided Configuring SAM deploy ====================== Looking for config file [samconfig.toml] : Found Reading default arguments : Success Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: AWS Region [ap-northeast-1]: Parameter SecretsManagerNameForSlackWebHookUrl [SLACK_WEB_HOOK_URL]: Parameter TopicArn [arn:aws:sns:ap-northeast-1:&lt;ACCOUNT_ID&gt;:kms-topic]: Parameter TopicKmsKeyArn [arn:aws:kms:ap-northeast-1:&lt;ACCOUNT_ID&gt;:key/&lt;ID&gt;]: ・・・ 4. アーキテクチャをテストします。Systems Manager の権限がない IAM インスタンスプロファイルを持つ EC2 インスタンスを起動します。権限が不足しているため、Systems Manager はこの EC2 インスタンスをマネージドノードとして登録できません。 5. 設定に基づいて、以下の画像のように Slack またはメールで SAW 分析結果を受け取ったことを確認します。この例では、IAM インスタンスプロファイルの権限不足が問題の原因であることを示しています。問題を解決するには、分析結果に表示されているドキュメントリンクを確認してください。 クリーンアップ このチュートリアルで作成したリソースを削除するには、以下の手順を実行します: このチュートリアル用に起動した EC2 インスタンスを終了 します。 Secrets Manager で作成した シークレットを削除 します。 ウォークスルーで使用したサンプルをクリーンアップするには、AWS SAM CLI を使用して $ sam delete を実行し、AWS CloudFormation スタックを削除します。 まとめ この記事では、Systems Manager がマネージドノードとして登録されない EC2 インスタンスの問題をトラブルシューティングするために SAW を使用する方法を紹介しました。この記事で紹介したサンプルアーキテクチャを使用して、EC2 インスタンスを監視し、これらのインスタンスが適切に登録されていない場合に SAW ランブックを自動的に呼び出すことができます。これにより、インフラストラクチャの可視性を失うことを防ぎ、プロアクティブなトラブルシューティングを支援します。 この記事で説明した技術は、自動化された問題検出と修復を通じて、Systems Manager で EC2 インスタンスの正確なビューを維持するのに役立ちます。 詳細については、 AWS Support でのセルフサービスランブックの使用 と AWS Support Automation Workflows (SAW) を参照してください。 AWS サポートエンジニアとテクニカルアカウントマネージャー (TAM) は、AWS に関する一般的なガイダンス、ベストプラクティス、トラブルシューティング、および運用サポートを提供します。 プランと提供内容の詳細については、 AWS Support を参照してください。 著者について 古野 俊広 古野 俊広は、AWS デプロイメントサポートチームのシニアクラウドサポートエンジニアです。コンテナと継続的インテグレーション/継続的デリバリー (CI/CD) の使用をお客様に支援することに情熱を注いでいます。プライベートでは息子たちと遊ぶことを楽しんでいます。 翻訳は Tech Translator の泉 希が担当しました。

企業での生成 AI 活用が広まりつつも、比較的単純な業務への適用による「コスト削減」に効果が留まる事例は多いのではないでしょうか。日本は米国、欧州と比較すると雇用の流動性が相対的に低い傾向にあり、業務を効率化しても社員数が減らない以上、コスト削減の効果には限界があります。効率化された業務から人材を価値創出につながるビジネス企画等へシフトし事業のトップラインを向上させることが収益拡大において不可欠ですが、その実現は容易ではありません。IPA 発行の DX 白書 2023 によればデータ利活用による売上増加の効果を観測している企業は米国ではすべての産業領域で 6 割から 7 割半ばにのぼりますが、日本では 1 割半ばから 3 割弱と総じて低い状態です。さらに「成果を測定していない」割合が日本では 5 割前後となっており、成果の測定自体まだ浸透しているとは言い難い状況です。 DX 白書 2023 では DX の「D」、デジタル化は推進が進みつつも「X」、トランスフォーメーションはその意味からして理解されていないのが現状と述べており、企業がデジタル技術により既存の業務やビジネスを変容・進化させることがまだ道半ばであることを示唆しています。 本記事では、生成 AI を活用しサービスの利用増や売上増など、トップラインの拡大を実現した 4 つの事例を紹介することで効率化から先のステップをご提示したいと思います。海外では Adobe が Photoshop で実装した生成 AI 塗りつぶし機能が一般的な機能に比べて 10 倍 以上の使用率 となった事例がありますが、日本国内でも収益拡大を実現した事例が出てきています！ 事例 1. 商談要約機能の精度を高め成約率 1.5 倍を実現 ( 株式会社 Poetics ) Poetics 様は、オンライン会議の録画・解析・情報共有をサポートする商談解析 AI 、「 JamRoll 」を提供しています。商談の文字起こしにとどまらず、議事録作成や営業支援ツールへの登録、振り返りといった営業活動における様々な後続業務の体験改善に生成 AI を活用することで、商談後の作業工数は 70% 削減され結果として 成約率が 1.5 倍になったと成果を伝えています 。そして、この機能の実装は 2 人のエンジニアが 1 ヵ月で完了しています。 Poetics 様の事例は、商談というメインのソリューションターゲットから後続の業務までフォーカスを拡大し顧客の体験を改善することで、サービス全体の成約率が高まること、生成 AI を活用し迅速に価値が提供できることを示しています。 事例 2. 生成 AI による自動生成機能を実装、トライアル企業の導入率は 100% ( 株式会社フォワード ) フォワード様は、採用業務を AI でアップデートする SaaS 型サービス「 エースジョブ 」を提供しています。採用市場では新卒・中途共に人材不足が深刻で、採用担当者は自社の求人票データに合わせ迅速かつ的確に求職者へスカウトを送る必要があります。エンジニアの読者の方であれば的外れなスカウトメールに辟易したことがある方も多いと思います。スカウトに対するネガティブな経験は採用率を下げることはもちろん、時にソーシャルメディアでさらされる可能性もありリスクが高い業務です。この機微かつもちろんセキュリティも求められる機能を生成 AI (Claude) で達成した結果、スカウト返信率は最大 20 倍、業務負担は最大 80% 減、年間 2,000 万以上の採用コスト削減につながったというフィードバックも届くなど大きな結果を達成し、トライアル企業の 100% が導入をしています。 フォワード様の事例は、単純なジャストアイデア、生成 AI のストレートな適用では顧客のニーズを達成できないだけでなくリスクにもつながるユースケースについて、粘り強く精度の改善に取り組むことが顧客体験、サービスのブレークスルーにつながることを示しています。 事例 3. パーソナライズされた家計アドバイスにより売上の 19% 向上に貢献 ( スマートアイデア株式会社 ) スマートアイデア様は、500 万人以上のユーザーが利用する家計簿アプリ「 おカネレコ 」に収支をもとにユーザーにあったアドバイスを提供する機能を実装し、導入後の課金売上が前月比で 19% 向上する成果を確認されています。多様なユーザーそれぞれに固有な家計や支出のパターンにあったアドバイスは、ハイパーパーソナライゼーションの実現例といえます。そして、本機能にかかった時間は約 2 ヵ月と非常に短期間です。 スマートアイデア様の事例は、マスのデータに基づく推薦にとどまらず、個別ユーザーのミクロなデータを活用することでパーソナライゼーションのレベルを一段上げることで収益へのインパクトを創出できることを示しています。 事例 4. 組織的な営業提案・課題解決へのシフト&nbsp; (株式会社三菱 UFJ 銀行) 三菱 UFJ 銀行様では、個人のスキルや着眼点に依存していた提案活動を組織的なナレッジにより補完し「見逃し」のない課題解決アプローチの構築に取り組まれています。営業日報や議事録の作成といったルーチンワークの業務効率化から一歩進み、営業の「課題発見」や「提案内容」といった個人スキルに依存しがちかつ収益拡大に不可欠な領域まで踏み込んだ活用を進められています。さらに生成 AI 適用ファーストではなく、AI に与える情報を人間が見て人間が提案を作り、顧客に刺さるか検証してから生成 AI での半自動化を進められています。顧客への価値提供プロセスを組み上げてから効率化を進める「ビジネス効果駆動」での営業 DX の推進には AWS の ML Enablement Workshop を活用いただき 、ワークショップ終了から 3 ヵ月で提案の有効性と自動化の実現性の確認を完了されています。 三菱 UFJ 銀行様の事例は、人間がまずビジネスを作る、生成 AI をはじめとしたテクノロジーでビジネスを効率化する、という収益性ある事業創出に不可欠な順序と組織間連携の重要性を示しています。 結論 日本では特に業務効率化によるコスト削減には限界があるため、トップラインの向上を図ることが不可欠です。生成 AI は比較的単純な業務の効率化にとどまらず、トップライン向上につながる利用者数や売上にインパクトを与えることができる技術です。 Poetics 様の事例からは、商談の要約という個別タスクから、ナレッジ共有や営業支援システムへの登録といった後続タスクを含めた業務プロセスへスコープを拡大することで顧客体験を向上し成約率にインパクトを与えられることが学べます フォワード様の事例からは、顧客にとってインパクトもあるがリスクもある業務への生成 AI 適用を丹念・緻密に行うことで業務に必要不可欠なレベルの体験を届けられることが学べます スマートアイデア様の事例からは統計的・機械的アドバイスから一歩踏み込み 1 人 1 人の家計・支出のパターンに寄り添った体験を提供することで売上への直接的なインパクトが観測できることが学べます 三菱 UFJ 銀行様の事例からはビジネスをまず人間が作り技術がフォローすることで収益性ある事業が創出できること、そしてスタートアップなど小規模な会社でなくとも組織横断でのチーム組成により3 ヵ月という短いスパンで最初の成果を観測できることが学べます 本記事で紹介した事例は、 AI Day にて事例展示を行います 。後日、 生成 AI のポータルで提供している事例集 にも反映される予定ですが、いち早く事例を参照したい方はぜひ AI Day にご参加ください！ 事例からの学びを、ぜひ生成 AI によるトップラインの向上、事業創出に活用いただければ幸いです。プロダクトの成長につながる生成 AI のユースケースを、組織横断のチームで特定する ML Enablement Workshop はまさにそのための方法論であり、 資料はすべて GitHub で公開されています 。公開資料を自身で活用いただくことはもちろん、実施に関心がある方は AWS 担当までぜひお問い合わせください。本記事が、皆さんの組織の中で生成 AI の活用を効率化から一歩、二歩前進させるきっかけとなれば幸いです。

はじめに Amazon Connect の利用が拡大するにつれ、顧客は効率的にスケーリングを管理し、クォータ（制限）を超過することによるデプロイの失敗やサービスの中断を防ぐために、クォータの可視性が必要になります。 Amazon Connect は Service Quotas との統合により、Amazon Connect インスタンスのサービスクォータ管理が改善されています。 Service Quotas は、AWS マネジメントコンソールや AWS Command Line Interface(AWS CLI) を通じてアクセスできる、 AWS アカウント全体のクォータを効率的に管理し追跡するためのハブです。この統合によりアカウントとリソースのクォータ割り当てをナビゲートし最適化する上で、より広範な制御と柔軟性が実現されます。Service Quotas を使用することで、複数のソースにアクセスする必要なく、一つの場所で Connect のクォータを中央管理できます。またサポートされているクォータでは、 Amazon CloudWatch との統合により、設定可能なアラームを通じて積極的な管理も可能になり、指定されたクォータに近づくと適時アラートを提供します。 Service Quotas によるメリット Amazon Connect サービスクォータの一元管理 : Service Quotas を使用することで、Amazon Connect のクォータを一箇所で管理でき、複数のソースを参照したり独自のリストを維持する必要がなくなります。Service Quotas は AWS マネジメントコンソール 、またはプログラム的に API や AWS CLI を使用してアクセスできます。 クォータの可視性向上 : デフォルトのクォータ値を表示するだけでなく、リソース（Connect インスタンス）単位で適用されているクォータが確認できるようになりました。クォータが変更された場合、変更後のクォータを確認できます。 クォータ引き上げリクエストの簡素化 : コンソールまたは API を通じて、アカウントレベルのクォータとリソースレベルのクォータの両方を表示および管理できます。リソースレベルのリクエストでは、調整を適用する特定のインスタンス（リソース）を選択できます。また、リクエストのステータスを表示および追跡することもできます。 クォータ引き上げリクエストへの迅速な対応 : Amazon Connect はクォータの自動レビューと承認を実装しました。自動承認されるクォータリクエストの場合、完了までの時間が数分に短縮されます。リクエストが自動承認の基準を満たさない場合は、AWS サポートケースが自動的に生成されます。 プロアクティブなクォータ管理への道筋 : Service Quotas は CloudWatch と統合されており、しきい値に達したときにアラートを発し、クォータをプロアクティブに管理できるようにします。 AWS Organizations 内の新規アカウントのクォータリクエストの簡素化 : 組織内に作成した新規アカウントのクォータ引き上げは頻繁にリクエストされています。Service Quotas はこのプロセスを自動化することで、組織内の新規アカウントのクォータ引き上げリクエストにかかる時間を削減しつつ、すべてのアカウントがワークロードのニーズに応じて一貫して構成されるようにします。 概要 このブログ記事では、Service Quotas の管理コンソール、AWS CLI を通して、リソース管理できるようになった Amazon Connect のクォータについて詳しく説明します。さらに、管理者が特定の Amazon Connect リソースのクォータを設定および管理する方法についても示します。 実施する内容 Service Quotas コンソールを使用して Amazon Connect のクォータを確認し、クォータの引き上げをリクエストする Service Quotas コンソールを使用してクォータリクエスト履歴を確認する AWS CLI を使用してクォータの引き上げをリクエストする AWS CLI を使用してクォータリクエストのステータスを確認する Service Quotas コンソールを使用してクォータ使用量メトリクスを確認する Service Quotas コンソールを使用してクォータ使用量のアラートを設定する 前提条件 Amazon Connect インスタンス IAM 権限 : クォータの引き上げをリクエストするには、service-quotas:RequestServiceQuotaIncrease 権限が必要です。 AWS CLI バージョン : AWS CLI を使用して Amazon Connect のリソースレベルのクォータを表示および管理するには、バージョン 2.13.20 以上が必要です。 Service Quotas の利用 Julie は金融業の AnyCompany 社のコンタクトセンター管理者で、新しいローンチに向けて本番環境の Connect インスタンスをテストしています。Julie は自社のコンタクトセンターが高い可用性を保ち、問い合わせとエージェントの作業量の変化に柔軟に対応できるよう細心の注意を払っています。彼女の会社は複数の事業部門をサポートするために複数の Amazon Connect インスタンスを使用しています。最大規模である消費者向けのインスタンスに電話番号を追加する必要があるため、このインスタンスの Phone numbers per instance（インスタンスあたりの電話番号数） クォータを確認し、増やしたいと考えています。 Amazon Connect のクォータについて、Julie は AWS Management Console から Service Quotas にアクセスし、Amazon Connect のページに移動することでサービスの全体のクォータに関する情報を確認できます。 Julie はページを下にスクロールして利用可能なすべてのクォータの中から Phone numbers per instance を探します。追加の詳細を確認するために表示されたクォータ名をクリックします。 詳細ページで、Julie は自身のすべての Amazon Connect インスタンスのリストを見ることができ、各インスタンスに適用されているクォータ値も含まれています。ここから、Julie はクォータの引き上げが必要な適切な Amazon Connect インスタンスを選択し、 「リソースレベルでの引き上げをリクエスト」 を選択できます。 これにより、新しいクォータ値を入力してリクエストを送信できるダイアログウィンドウが表示されます。 Phone numbers per instance の詳細ページ に戻り、 「リクエスト履歴」 タブを選択すると、Julie は現在および過去のクォータリクエストのステータスを確認できます。新しいリクエストは 「保留中」 のステータスになります。ステータスをクリックするとリクエストの詳細が表示されます。クォータの引き上げを処理するために AWS サポートケースが必要な場合は、自動的に作成され、ステータス詳細ページに AWS サポートケースへのリンクが表示されます。 Service Quotas API を使用した Amazon Connect のクォータ引き上げリクエスト Service Quotas は、クォータ引き上げをリクエストするための API も提供しています。Julie は RequestServiceQuotaIncrease API を使用してクォータ引き上げのリクエストを送信できます。例えばこの例で Julie は、別の Amazon Connect インスタンスの Phone numbers per instance（インスタンスあたりの電話番号数） クォータを 10 から 11 に増やす必要があるとします。 Julie は AWS CLI を使用してリクエストを送信します リクエストが送信されると、Julie は GetRequestedServiceQuotaChange を利用してリクエストを追跡できます 新しいクォータが適用されたかどうかを GetServiceQuota を使用して確認できます。この AWS CLI リクエストの構文は次のとおりです : aws service-quotas get-service-quota –service-code connect –quota-code &lt;quota_code&gt; –context-id &lt;connect_instance_arn&gt; –region &lt;region&gt; クォータに対する使用状況のモニタリング Julie は、コンタクトセンターが StopContact API を頻繁に使用して、キューからコールバックを削除していることを理解しています。さらに、彼女はこの API のクォータに対する使用状況を可視化したいと考えています。 Service Quotas 内から、彼女は Amazon Connect 内の StopContact API リクエストのレート(Rate of StopContact API requests)を参照します。 ここから、彼女は 「モニタリング」 タブを選択して CloudWatch による使用率グラフを確認します。 Julie は、このメトリクスが 100 パーセントの使用率に近づいた場合に通知を受けたいと考えています。彼女は 「アラーム」 タブを選択し、 「アラームを作成」 をクリックします。 Julie はメトリクスが 80 パーセントの使用率に達した時に通知を受けたいので、しきい値を設定し、アラームの名前を入力して作成をクリックします。 追加の考慮事項 使用率 : 選択したサービスクォータの詳細を表示する際、表示される 使用率 の値は、CloudWatch によって可視化された適用されているクォータの使用率を表します。 Connect Public API の利用率が利用可能です。 Amazon Connect グローバルレジリエンス : Amazon Connect グローバルレジリエンス（ACGR）を活用しているお客様の場合、Amazon Connect インスタンスを 2 つ目のリージョンに初期レプリケーションする際にクォータの同期プロセスがあります。サービスクォータのリクエストはリージョン固有です。初期レプリケーション後、お客様は ACGR インスタンスを今後同期させ続けるために、各リージョンに対して個別にサービスクォータの引き上げを申請する必要があります。 クリーンアップ Amazon Connect インスタンスを作成して Amazon Connect のクォータ管理をテストした場合は、 ガイドに従って Amazon Connect インスタンスを削除 できます。 結論 Service Quotas を使用すると、1 つの中央の場所から AWS サービスのクォータを表示および管理できます。Service Quotas を使用すると、クォータ引き上げリクエストを簡単に申請、追跡することができるほか、AWS Organizations と統合することで、新しいアカウントのクォータを一貫した方法で設定し、時間と労力を節約できます。このブログ記事では、Service Quotas を使用して Amazon Connect リソースのクォータを設定および管理する方法を紹介しました。 詳細については、以下をご覧ください : Amazon Connect サービスクォータ CloudWatch を使用したインスタンスのモニタリング Service Quotas とは何ですか Amazon Connect でカスタマーサービス体験を変革する準備はできましたか ? お問い合わせください 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本ブログは 2023 年 10 月 10 日に公開された Amazon News “ 3 ways AWS is helping to make the internet more secure ” を翻訳したものです。 新種のサイバー攻撃からお客様を守るための Amazon Web Services の取り組みと、ビジネスをオンラインでより安全性を高めるための対策を説明します。 2023年 8 月末、AWS のセキュリティチームは、ユーザーを標的とする新種の HTTP リクエストフラッド攻撃を発見しました。HTTP リクエストフラッド攻撃は、分散型サービス妨害 (DDoS) 攻撃の一種で、ウェブサイトやアプリケーションをユーザーが利用できないようにすることを意図的に狙ったものです。このような攻撃は、残念ながらサイバーセキュリティチームが対処すべき一般的な問題となっています。しかし、今回の攻撃はこれまでとは異なっており、かつてない規模でした。 「DDoS 攻撃は進化しています。かつてに比べてずっと攻撃的かつ高レートでWebサーバーにリクエスト通信をする方法が見つかってます。」と AWS のVice President 兼 Distinguished Engineer である Tom Scholl 氏は述べています。「リクエストフラッド攻撃は、本質的にデータを要求することです。サーバーは要求されたデータを用意しますが、攻撃者はそれを受け取る気はありません。電話を無駄に掛け続けて、相手が出たらすぐ切るようなものです。一度に 1 億回以上のリクエストがあると、大量のリソースを消費し、通常のトラフィックの処理を妨げる可能性があります。この特別な攻撃は「HTTP/2 ラピッドリセット攻撃」として知られており、1 秒あたり 1 億 5500 万回以上のリクエストが発生していました。」 DDoS 攻撃が成功すると、企業に混乱を引き起こされ、コストが増大し、日常生活を送ろうとしている人々にも影響が及ぶ可能性があります。例えば、銀行振込ができなくなったり、医療機関の情報を見られなくなったり、お気に入りの番組を視聴できなくなるかもしれません。ゲームをする人は、ログインできなくなったり、プレイ中に突然切断されてしまったりする可能性があります。 AWS エンジニアの努力により、AWS のお客様はこの新しい DDoS 攻撃から迅速に保護されました。AWS は他のテクノロジー企業と協力して、さらなる対策の開発に取り組み、業界全体でこのような攻撃への対処方法の改善に取り組みました。 「私たちはこのような問題に対して、複数の角度からアプローチします」と Scholl 氏は言います。「社内のあらゆる専門知識を総動員して迅速に対策を講じると同時に、他の脆弱な可能性のある領域も特定します。新種の DDoS 攻撃が発生した場合、検証環境で攻撃者が行っていることを再現し、攻撃の仕組みをより深く理解し、私たちのシステムの耐性をテストします。」 Scholl 氏は、業界の専門家と最も効果的な技術的アプローチに関する知識を共有し、協力することも、攻撃を防ぐために不可欠だと述べています。 「最終的に私たちは、AWS のお客様だけでなく、世界中のすべての一般の Web ユーザーにとって、インターネットをより安全でより安心な場所にしようとしています。」と彼は述べました。 AWS が DDoS 攻撃を防止し、攻撃に使われているインフラストラクチャを無効化させるために行っている 3 つの方法を紹介します。 1. ボットネットの検出と特定 攻撃者は DDoS 攻撃を実行するために、しばしば「ボットネット」を使用します。ボットネットは、通常のシステム動作を妨害するように設計されたマルウェアやその他の破壊的なソフトウェアに感染したコンピューターのネットワークです。影響を受けた数万台に及ぶ可能性のあるマシンは、1 台のサーバーによって制御されています。サーバーは、システムに過負荷をかけようとする試みとして、同時に攻撃を実行するよう指示することができます。私たちの 脅威インテリジェンスツール MadPot を通じて、ボットネットを検出し特定することができ、ボットネットがどこから制御されているかを識別できます。その後、ドメインレジストラやホスティングプロバイダーと連携して、その制御ポイントを遮断します。これにより、ボットネット自体が攻撃に加わることができなくなります。 2. スプーフィングされた IP の送信元の特定 DDoS 攻撃者がよく使用する一般的な手法の 1 つに「IP スプーフィング」があります。これは、攻撃の一環としてメッセージを送信する際に、送信元の IP アドレスを偽装して、活動停止をさせにくくする手法です。歴史的に、IP スプーフィングは真の送信者の特定が非常に困難なため、セキュリティチームにとって対処が困難な課題となっていました。(1,000 個の異なる番号から同時に 1,000 件の電話がかかってきたと想像してみてください。各メッセージの送信元ネットワークを見つけるには、一つ一つ遡って追跡する必要があります。) AWS は大規模なグローバルネットワーク基盤を運用し、何千もの独自のネットワークと相互接続しているため、ピアネットワークと直接連携して攻撃を送信元まで追跡し、遮断することができます。私たちは、さまざまなネットワーク事業者と協力して、送信者の追跡を行い、このような種類の攻撃に使用されるインフラストラクチャを遮断しています。 3. オープンプロキシを介した HTTP リクエストフラッドのトレース 「プロキシサーバー」は、ユーザーとインターネットの間のゲートウェイのような役割を果たすコンピューターです。代表的な例として、Squid のようなソフトウェアパッケージがあります。DDoS 攻撃者は、誰でも利用できるオープンプロキシサーバーを悪用して、自身の攻撃送信元を隠蔽します。彼らは積極的にオープンプロキシをスキャンし、HTTP リクエストフラッド攻撃を生成する際にそれらを使用することで、ターゲットを攻撃する際に真の送信元を隠すことができます。ターゲットが攻撃を検出しても、実際の攻撃元ではなく、インターネット上の数千のプロキシサーバーから攻撃が来ているように見えます。私たちの 脅威インテリジェンスツール MadPot を使用することで、これらのプロキシに接続している実際の攻撃元を追跡し、上位のホスティングプロバイダーに働きかけて攻撃元の遮断をすることができます。 ビジネスをオンラインでより安全に保つための 3 つのヒントを紹介します。 1. 一人で抱え込まない セキュリティは協力して取り組む必要があるというのが Scholl 氏の考えです。Amazon CloudFront のようなサービスを使えば、スタートアップであれ、大企業であれ、どのような企業にも役立ちます。CloudFront のグローバルなフットプリント、DDoS 緩和システム、トラフィック管理システムは、大量のトラフィック (良いものも悪いものも) に対処できるよう設計されています。Scholl 氏は、CloudFront の働きを考えるうえでの有用なたとえとして、非常に強固で補強された玄関ドアのイメージを挙げています。誰かが重い石を投げつけても、わずかな傷をつけるられるかもしれませんが、玄関ドア自体は無事です。DDoS に特化して対処する AWS Shield サービスと組み合わせることで、お客様は DDoS 関連の脅威に対処するための適切なツールセットを手にできます。 2. 最新状態の維持 最新のセキュリティアップデートを確実に入手し、ビジネスが依存するソフトウェアに定期的にパッチを適用し、アップデートすることは、非常に重要です。これらのアップデートには、最新の既知の脆弱性への対応が盛り込まれています。HTTP/2 対応の Web サーバーを自社で運用しているお客様には、最近報告された攻撃の影響を受けるかどうかを Web サーバーベンダーに確認し、影響を受けている場合は、この問題に対処するためにベンダーから最新のパッチをインストールすることをお勧めします。 3. 多要素認証の使用 オンラインで自身とビジネスを保護する最良の方法の 1 つは、多要素認証 (MFA) です。これはセキュリティのベストプラクティスであり、ユーザー名とパスワードのサインイン認証情報に加えて、2 つ目の認証要素を必要とします。MFA は、権限のない個人がシステムやデータにアクセスすることを防ぐための追加の保護層となります。AWS のお客様は、MFA についてさらに詳しく知りたい場合、 こちらのブログ記事 をご覧ください。 AWS がお客様の安全をどのように守っているかについての詳細は、 AWS クラウドセキュリティウェブサイト をご覧ください。2023年 8 月の DDoS 攻撃をどのように阻止したかについてのより詳細な情報については、 AWS による DDoS イベントからのお客様の保護 をご覧ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事は、 QuickSight Demo Central に公開したサンプルダッシュボードを用いて、ゲームビジネスにおけるデータ分析基盤導入の課題と解決策を説明します。 はじめに – ゲームビジネスにおけるデータ分析の重要性 こんにちは、ゲーム業界のお客様を中心に支援を行っているテクニカルアカウントマネージャの坂本です。ゲーム業界のお客様からデータ分析基盤に関するご相談、お問合せを多くいただいています。近年のゲームビジネスでは、 Free-To-Play を基本としたオンラインゲームのように、リリース後もゲーム要素の追加やゲームバランス調整などのアップデートを継続的に行うゲームサービスとして提供することが一般的です。ゲームサービスをビジネスとして成功させる、運営を通して売れるゲームサービスにしていくためには、ゲームサービスを継続して改善し、ユーザーのニーズに応え続けることが必要です。この継続的な改善を迅速かつ的確に行うためには、ゲームデザイナーの勘や経験から導出された定性的な情報だけでなく、ゲーム内のユーザー行動を通して生成されたデータの分析結果という定量的な情報も必要です。データ分析基盤を構築し効率的にデータを収集、 BI（Business Intelligence） ツールを用いてデータを可視化することで、ユーザー行動のトレンドの変化を一目で確認できるようになり、実施した施策が売上や DAU（Daily Active User） などの KPI にどのように影響を与えたのか、仮説が正しかったのかを効率よく検証できます。加えて、可視化したデータを利用することで、ゲーム運営に携わる関係者が、ビジネス目標の達成状況や改善結果を効率よく共有、理解できるようになります。このように、定性的な情報に加えて、定量的なデータを可視化して活用することで、迅速かつ的確にゲームサービスの改善に向けた意思決定を行うことができます。本記事ではゲームビジネスにおけるデータ分析基盤導入の課題と解決策を、データ分析基盤のアーキテクチャ、および Amazon QuickSight によるサンプルダッシュボードを QuickSight Demo Central に公開しましたので、そのダッシュボードを用いてご説明します。 ゲームビジネスにおけるデータ分析の課題と解決策 お客様からご相談をいただく中で、先述のようなゲームビジネスにおけるデータ分析の重要性は感じられていますが、実際にはデータ分析基盤の導入まで至っていないことが多くあります。売上、DAUなどゲームビジネスの基本的なKPIはデータベースからデータを抽出し表計算ソフトで集計されているものの、あくまでビジネス状況を中心に表層的な把握に留まっており、ゲームサービスの運営における意思決定は勘や経験といった定性的な情報に基づいているという実情をよく伺います。このようにデータ分析の重要性は感じられていながらも、現実としてデータ分析の導入が進んでいない原因としては大きく２つの課題があると考えています。１つ目はゲームビジネスにおいてデータ分析基盤とBIツールを用いたデータ分析方法が一般的なナレッジとして普及していないという課題。２つ目はデータ分析基盤のスケーラビリティと導入の優先度を上げられないという課題です。 １つ目の課題について、お客様から Amazon QuickSight でゲームにおけるデータ分析のダッシュボードのテンプレートがあるかお問合せをいただくことが非常に多いことからも、ゲームビジネスでどのようにデータを可視化して分析を行えば良いのか悩まれるお客様が多いことが伺えます。背景にはゲームサービスに関わるドメイン知識と、データ分析の技術スキルの両方を兼ね備えた人材の獲得や育成が難しいことが挙げられます。本記事では、データ分析を専門分野とされていないお客様にも、効率よくデータ分析基盤を導入いただけるように、ゲームビジネスにおけるデータの可視化と分析の例を、 Amaozn QuickSight のデモを用いて説明します。詳細は後述しますが、 Amaozn QuickSight というクラウドネイティブなサーバーレスの BI ツールを用いることでデータ分析の専門知識を備えていないエンジニアやゲームの企画運営に関わる方でも簡単にデータの可視化を始めることができます。 2つ目の課題の背景としては、ゲームサービスは不確実性が高く、売上やユーザー数が変動するという性質があります。この性質により、データ分析基盤に必要なインフラの見積もりが困難になり、データ分析の導入が難しくなっています。この課題を解決し、データ分析基盤の費用対効果を最大限に高めるためには、ユーザー数やデータ量の変動に合わせて柔軟にスケールできる仕組みが必要です。他にデータ分析の導入に対する優先度を上げられない要因として、ゲームをリリースするまではゲーム開発にフォーカスしなければならずリリース前からデータ分析基盤を構築することに労力を割けないということが挙げられます。また、ゲームがリリースされた後でゲームサービスの本番環境に影響を与えないように分析用ログの追加・アプリケーションの変更を加えようとすると、リリース前にデータ分析基盤を構築するよりも多くの工数が必要になります。加えて、リリース後は運用業務のタスク量が多く、ゲームのユーザーに直接的に価値を提供できるタスクの優先度が高くなることから、ゲームのリリース後にデータ分析基盤を導入することは非常に難しいです。これらの理由から、お客様がデータ分析の必要性を理解されていてもゲームのリリース前、リリース後ともにデータ分析基盤の構築がなかなかできない状況であると考えています。この課題を解決するために、本記事では AWS が提供するサーバーレスサービスを組み合わせたデータ分析基盤の参考アーキテクチャをご紹介します。お客様はサーバーレスサービスを組み合わせるのみという少ない工数でデータ分析基盤を構築できます。加えて、サーバーレスサービスは使用量に応じた従量課金制のため、ゲームサービスの規模やご利用状況に合わせたリーズナブルな料金でご利用いただくことができ、トラフィックの増減に応じた柔軟なスケーラビリティも確保することができます。 ゲームのサーバーサイドとデータ分析基盤のアーキテクチャ ゲームにおけるデータ分析基盤のアーキテクチャをご紹介するにあたり、まずはゲームのサーバーサイドのアーキテクチャをおさらいします。ゲームのサーバーサイドは大きく分けて、インゲームとアウトゲームで構成されます。インゲームはRPGゲームにおけるクエストやアクションゲームにおけるバトルなどゲームの主体となる遊びの部分です。アウトゲームは認証、アイテム購入、キャラクター管理といったインゲームを支える周辺機能を指します。以下のアーキテクチャ図においては、インゲームはリアルタイムサーバーに代表されるようなゲームサーバーが担い、アウトゲームはゲームバックエンドがその処理を行います。ゲームバックエンドでは、アイテムの購入履歴など、データの一貫性と耐久性が必要なデータは Amazon Aurora などのリレーショナルデータベースに保存し、セッション情報や一時的に高頻度で使われるデータは Amazon ElastiCache などのインメモリデータベースにキャッシュすることが一般的です。一方で、これらのデータベースに保存しないゲームバックエンドのアクセスログや、ゲームサーバーで出力されるユーザーの行動ログ、およびアプリケーションが出力するエラーログといった様々なログはログ収集サービスを使用してログ保管用のストレージに蓄積します。リレーショナルデータベースに保存されているユーザーのプレイ状況やゲームの売り上げといったデータとログに記録されているユーザーの行動を組み合わせて分析するためには以下のアーキテクチャ図のようなデータ収集の仕組みが必要となります。 図1：ゲームのサーバサイドとデータ分析基盤のアーキテクチャ データ分析基盤は「データ収集」、「保管」、「分析」、「可視化」の4つのレイヤーで構成されます。 データ収集レイヤーでは、データベースなどのデータソースからデータを抽出して、分析レイヤーで分析がしやすいフォーマットに加工、圧縮を行います。このアーキテクチャでは、データベースのデータを、サーバーレスなデータ統合サービスである AWS Glue を使用して抽出、加工します。ゲームバックエンド、およびゲームサーバで生成されたログは Amazon CloudWatch 、またはログストリーミングしたデータをストレージや分析サービスに容易に連携できる Amazon Data Firehose を使用して収集します。 保管レイヤーでは、データ収集レイヤで抽出、加工したデータを&nbsp; Amazon S3 で保管します。 分析レイヤーでは、データの可視化や分析に使用するデータを作成するために、 Amazon Redshift Serverless を使用します。 Amazon Redshift Serverless はデータウェアハウスサービスである Amazon Redshift のServerlessオプションで、お客様にクラスタの管理をいただく必要はなく、処理を行った分だけお支払いをいただく料金モデルとなっています。 可視化レイヤーでは、分析レイヤーで集計されたデータをBIツールである Amazon QuickSight を使用します。 Amazon QuickSight はお客様にインフラを管理いただく必要はありません。 これらのサーバーレスなAWSのデータ分析サービスを組み合わせて、ご利用いただくことで、サービスの規模に応じた料金と柔軟なスケールメリットを享受することができ、データ分析基盤の効率的な実装と運用を実現することができます。 Amazon QuickSight について Amazon QuickSight は、クラウドネイティブなサーバーレスの BI ツールです。お客様による分析用サーバーのセットアップは必要なく、すぐに使いはじめて、お手元のデータを分析することが可能です。また、少人数での小規模利用から数万人規模の大規模活用まで、利用人数に応じた柔軟なスケーリングが可能です。他のAWS サービスとネイティブに統合されており、お客様に必要とされる堅牢なセキュリティを備えたデータ分析環境を迅速に構築することができます。詳細は、 Amazon QuickSight の特徴 やこちらの ブログ記事 にて解説されています。また、 Amazon QuickSight は月額課金となっており、ご利用いただくユーザー数に応じた従量課金で料金が発生します。そのため年単位でのライセンス契約などは必要なく、ご利用者数の増減に対して細やかに対応できます。 デモダッシュボード QuickSight Demo Centralのデモは以下のユースケースを元に作られています。 ユースケース ペルソナ – ダッシュボードの利用者 ゲームプロデューサー、ゲームディレクターなどゲームの企画運営に関わる方 ゲームバックエンドの開発・運用に関わる技術者の方で、チームにデータ分析を導入したいと考えている方 ストーリー ゲームパブリッシャーのA社では日本国内ユーザー向けの Free-To-Play のモバイルゲームを企画、開発、運用している。今まではゲームタイトルごとの月毎の売上、 DAU（Daily Active User）などの基本的な KPIデータの収集のみを行なっていた。ゲームのアップデート内容は、ゲームプロデューサーとゲームデザイナーが自身のアイデアや過去の経験などの定性的な情報のみに基づいて意思決定をしている。アップデートに対するユーザーの反響が良い場合も多々あったが、追加するゲーム要素、ゲームバランス調整などの改善の効果を計測することができず、意思決定が正しかったのかデータに基づいて定量的に検証することができない。また、想定していなかったキャラクターが流行した際には効果の測定と検証をする仕組みがないため流行した理由が分からず、反響の大きかった要因を分析して論理的に説明できないことも課題であった。昨今ではゲームからユーザーが早期離脱してしまい、ゲームタイトルがリリースから1年未満の短期間でサービス終了となることも珍しくない。ゲーム開発には数億円規模の投資がされており、投資資金の回収、計画した利益の創出といったビジネス目標の達成には、定常的なゲームサービスの状況把握、定量的なデータに基づいた仮説検証、および継続的な改善によるゲームサービスの長期運営が必要となる。 A社では新規タイトルとして得意領域であるマルチプレイヤーに対応したロールプレイングゲームの開発を決定した。このゲームの課金要素はゲーム内通貨のジェムである。ユーザーはこのジェムを使用してガチャを購入することで、ランダムに抽選された、武器または防具を入手できる。プレイヤーは戦闘で得た経験値でキャラクターのレベルを上げ、より強い武器と防具を使用することで、ゲームを有利に進めていくことができる。人気のあるアニメ作品や漫画とのコラボレーションによるイベントの開催も集客要素の一つとして計画した。このコラボレーションイベントに合わせた期間限定ガチャを提供することで、プレイヤーの購買意欲を高める戦略とした。 A社はビジネス目標を確実に達成するために、アイデアや過去の経験などの定性的な情報に加えて、データ分析基盤で収集した定量的なデータを用いて、ゲームサービスの状況把握と継続的な改善に取り組むこととした。 データの分析例 データ分析のポイントは２つあります。１つ目は可視化することでデータの変化を一目で確認できること、２つ目は売上や Active Users などの基本的なビジネスKPIとユーザー行動の両面で分析することです。可視化によって、ゲームのアップデートや施策をユーザーに提供したタイミングと、ユーザー行動やビジネスKPIの変化を時系列順に確認できます。これにより、あるアップデートや施策によって、ユーザー行動がどのように変化し、どれくらいKPIに影響があったかを効率よく確認することができます。 ではQuickSight Demo Centralの画面を見てみましょう。ゲームのKPI分析の例は[図2]のとおりです。このダッシュボードの一番上[図2(1)]にゲームの主要なKPIを表示しています。これらのKPIはすべて、ゲームビジネスの売上にかかわる指標です。主要KPIを表示することで、ビジネス目標の達成状況が一目でわかります。「売上合計」はある期間にゲームで売り上げた金額の合計です。これは、ゲームビジネスにおいて最も重要なKPIです。「Active User」 は指定した期間に遊んでくれたプレイヤーの数、「Average Revenue Per Paid User（ARPPU）」は課金しているプレイヤー１人あたりの平均売上金額、「新規ユーザ数（新規インストール数）」は指定した期間に新たにゲームに参加したプレイヤー数です。 図2：KPI分析シート/主要KPI・KPI時系列分析 このダッシュボードでは、[図2(2)]のそれぞれのグラフで、 KPI の日ごとの変化を時系列に一目で確認できます。これらのデータの推移と施策を実施したタイミングを照らし合わせて分析することで、実施した施策が各KPIにどのように影響したのか容易に確認できます。Free-To-Playにおいて課金/無課金プレイヤーは大きく異なり、ゲームビジネスを継続するためには、課金プレイヤーにいかに満足してもらいながら対価を支払ってもらえるかが重要です。 ARRPU の変動を分析することで、ゲームサービスがその対価を支払うに値し続けているかを確認することができます。ARRPUを上げることが必ずしも正解ではなく、一時的に上がった後に下がってしまった場合は、短期的に課金のプレッシャーが高まってしまい、ユーザエンゲージメントが下がってしまった可能性があります。ARRPUの変動と合わせて確認したいのが Conversion Rate（CVR） です。 Conversion Rate は、その日の Active User の中で課金したユーザの割合を示しています。新しい商品を追加した時に、ARPPUは変動させずに課金ユーザー数を増やしたいのか、既に課金しているユーザーの中でよりコアなユーザーに購入してもらいたいかなど、 ARPPU と CVR がどのように変動することが好ましいかは目的や状況によって異なります。 KPI の項目ではありませんが、[図2(3)]の7日間継続率も重要な指標の一つです。これは、ゲームに新規登録したプレイヤーのうち、7日後以降も継続しているユーザーの割合です。ゲームビジネスを長期的に運用していくためには、プレイヤーにゲームをインストールしてもらうだけでなく、日々継続して遊んでもらうことも必要です。一般的に新規登録から7日経過して継続して遊んでもらえていれば、そのプレイヤーは定着していると考えることが出来ます。7日間継続率が低いことを検知した場合、チュートリアルに離脱ポイントがないか、レベルデザインに問題があってある程度プレイヤーがゲームを進めたところで一気に難易度が上がり離脱に繋がっていないかなど、離脱要因の分析に繋げることができます。 以下の[図3]では課金要素であるガチャの売上推移を確認できます。ガチャはユーザーの課金要素であるため売上と密接な関係があります。ガチャの売上の推移とKPIの変化の両方を照らし合わせて確認することで、ゲームの改善内容やガチャで入手できるアイテムのアップデートが売上をはじめとする各KPIにどのように影響したのかを効率よく確認することができます。 図3：KPI分析シート/ガチャ回転数推移 以下の[図4]では、インゲームの要素であるイベントのエントリー人数の時系列の変化と合わせて確認することで、この例では実施したイベントが売上や DAU にどのような影響を与えたのか分析することがでます。またイベントごとの参加ユニークユーザ数を一目で確認することが出来ます。 図4：KPI分析シート/イベント分析 このようにゲーム内の施策がゲームビジネスにどのように影響しているかデータに基づいて計測し、当初の想定と比較することで改善点を導出して次の施策に繋げられていると、ゲームの企画運営にデータ分析を活用していると言えるのではないかと思います。 Amazon Quicksightの技術的なポイント このダッシュボードでは、 Amazon Quicksight の技術的なポイントが２点あります。１点目はKPIを計算フィールドを用いて算出していること、２点目は複数のデータセットに対してクロスデータセットフィルターを使用してダッシュボードを作成している点です。計算フィールドを用いることで、データの計算や集計処理したデータを準備することなく、ダッシュボードを作成するタイミングで実装することができ、変更も容易になります。このことにより、ゲームの機能開発が優先される中で後からデータ分析を導入する場合でも、データの前処理から可視化まで Amazon QuickSight で完結できます。また、クロスデータセットフィルターを使用することで、今回のダッシュボードのように複数のデータセットを組み合わせて使用するダッシュボードのフィルタ制御を単一のコントロールで行うことができます。ある施策がある期間にどのような影響を与えたか、ビジネスKPIからユーザー行動まで複数のデータセットに跨って分析をする必要があるため、それら複数のデータセットを単一のコントロールで制御できる機能はゲーム分析に適しています。 まとめ 本記事では、ゲームサービスにおけるデータ分析の重要性、データ分析基盤導入の課題と、その課題を解決しすぐにデータ分析を始めるための参考として Amazon QuickSight のデモをご紹介しました。ゲームサービスをビジネスとして成功させるためには、ゲームサービスを継続して改善しユーザーのニーズに応え続けることが求められます。この継続的な改善を迅速かつ的確に行うために、ゲームデザイナーの勘や経験から導出された定性的な情報だけでなく、定量的なデータを分析、可視化して組み合わせて活用することが重要です。 本記事がデータ分析基盤の導入、およびお客様のゲームビジネスの成功のお役に立てば幸いです。 著者/開発者紹介 坂本 達哉 アマゾン ウェブ サービス ジャパン合同会社 テクニカルアカウントマネージャ 2021年にAWSに入社し、テクニカルアカウントマネージャ（TAM）として、ゲーム業界のお客様を中心に、 AWS 活用支援を担当しています。 &nbsp; 渡邉 真太郎 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト モバイルゲームの開発会社2社でサーバーサイドエンジニアとして従事し現職。 普段はゲーム業界向けのソリューションアーキテクトとしてゲーム開発に携わるお客様をご支援しております。

本ブログは 2023 年 10 月 10 日に公開されたBlog “ How AWS protects customers from DDoS events ” を翻訳したものです。 Amazon Web Services (AWS) では、セキュリティが最優先事項です。セキュリティは私たちの文化、プロセス、システムに深く根付いており、私たちのあらゆる活動に浸透しています。これはお客様にとってどういった意味があるのでしょうか。AWSは、お客様に影響を与えるセキュリティインシデントの防止と緩和に向けた取り組みについて、お客様により深く理解していただくことが有益だと考えています。 2023 年 8 月下旬以降、AWS は新種の分散型サービス妨害 (DDoS) 攻撃を検出し、お客様アプリケーションを保護してきました。DDoS 攻撃とは、ウェブサイトやアプリケーションなどの対象システムの可用性を妨害し、正規ユーザーに対するサービスのパフォーマンスを低下させようとすることです。 DDoS 攻撃方法の例 には、HTTP リクエストフラッド、リフレクション攻撃(アンプ攻撃)、パケットフラッドなどがあります。今回 AWS が検出した DDoS 攻撃は、HTTP/2 リクエストフラッドの一種で、ウェブサーバーの能力を超える大量の不正なウェブリクエストを送って、正規のクライアントからのリクエストに応答できないようにする攻撃です。 2023 年 8 月 28 日から 29 日にかけて、AWS のプロアクティブな監視により Amazon CloudFront への HTTP/2 リクエストの異常な急増を検出しました。ピーク時には 1 秒あたり 1 億 5500 万リクエスト (RPS) を超えるリクエストを観測しました。AWS は数分以内にこの異常な活動の性質を特定し、CloudFront が新種の HTTP リクエストフラッド DDoS イベント（現在は HTTP/2 ラピッドリセット 攻撃と呼ばれています）を自動的に緩和していました。この 2 日間で、AWS は HTTP/2 ラピッドリセット攻撃について 10 件以上の 一連のイベントを観測し軽減しました。そして続く 9 月も、この新種の HTTP/2 リクエストフラッドが引き続き発生していたことを確認しています。Amazon CloudFront や AWS Shield などのサービスを使用して DDoS 耐性を施したアーキテクチャを構築していた AWS のお客様は、アプリケーションの可用性を維持することができました。 図1. 世界の 1 秒あたりの HTTP リクエスト数、9 月 13 日～16 日 HTTP/2 ラピッドリセット攻撃の概要 HTTP/2 では、1 つの HTTP セッション上で複数の異なる論理接続を多重化できます。これは、各 HTTP セッションが論理的に分かれていた HTTP 1.x からの変更点です。HTTP/2 ラピッドリセット攻撃は、リクエストとリセットを短時間に連続して行う複数の HTTP/2 接続で構成されます。例えば、複数のストリームに対する一連のリクエストが送信され、その後それぞれのリクエストに対するリセットが続きます。攻撃対象システムは各リクエストを解析して処理し、クライアントによってリセット（またはキャンセル）され、さらにリクエストのログも生成します。クライアントにデータを送り返す必要がなくても、システムはそれらのログを生成します。悪意のある攻撃者は大量の HTTP/2 リクエストを発行することで、このプロセスを悪用しウェブサイトやアプリケーションなどの攻撃対象システムのリソースを枯渇させることができます 重要なのは、HTTP/2 のラピッドリセット攻撃も、HTTP リクエストフラッドの新しい形態に過ぎないことです。このような種類の DDoS 攻撃から防御するには、不要なリクエストを特定して検出し、悪意のある HTTP リクエストを吸収してブロックするような、スケーリング可能なアーキテクチャを実装する必要があります。 DDoS 耐性のあるアーキテクチャの構築 AWS のお客様は、AWS のグローバルクラウドインフラストラクチャに組み込まれたセキュリティと、AWS サービスのセキュリティ、効率性、および回復力を継続的に改善するという当社のコミットメントの両方から恩恵を受けることができます。DDoS 耐性を向上させるための具体的なガイダンスとして、AWS は AWS Best Practices for DDoS Resiliency などのホワイトペーパーを公開しています。このドキュメントでは、アプリケーションの可用性を保護するためのガイドとして、DDoS 耐性を持つリファレンスアーキテクチャを説明しています。AWS サービスには複数の DDoS 緩和のための組み込み機能が自動的に含まれていますが、特定のサービスを使用した AWS アーキテクチャを採用し、ユーザーとアプリケーション間のネットワークフローの各部分に追加のベストプラクティスを実装することで、DDoS 耐性をさらに向上させることができます。 例えば、 Amazon CloudFront 、 AWS Shield 、 Amazon Route 53 、 Route 53 Application Recovery Controller などのエッジロケーションから運用される AWS サービスを使用して、既知のインフラストラクチャレイヤーへの攻撃に対する包括的な可用性保護を構築できます。これらのサービスは、世界中に分散したエッジロケーションからあらゆるタイプのアプリケーショントラフィックを提供する際に、アプリケーションの DDoS 耐性を向上させることができます。オリジンのアプリケーションは AWS 上でもオンプレミスであっても、これらの AWS サービスを使用して不要なリクエストがオリジンサーバーに到達するのを防ぐことができます。ベストプラクティスとして、アプリケーションを AWS 上で実行することで、アプリケーションエンドポイントが DDoS 攻撃にさらされるリスクを軽減し、アプリケーションの可用性を保護して、正規ユーザーに対するアプリケーションのパフォーマンスを最適化できます。Amazon CloudFront (HTTP キャッシュ機能を含む)、 AWS WAF 、Shield Advanced による自動アプリケーションレイヤー保護を使用すると、アプリケーションレイヤーの DDoS 攻撃中に不要なリクエストがオリジンに到達するのを防ぐことができます。 AWS のお客様のための知識を活かす AWS は、セキュリティ課題がお客様のビジネスに混乱をもたらすことを防ぐため、絶えず注意を払っています。AWS はサービスの設計方法だけでなく、エンジニアがサービスのあらゆる側面に対して深い責任感を持って積極的に取り組んでおり、そのことをお客様に共有することが重要だと考えています。インフラストラクチャとお客様のデータを守る取り組みの中で、お客様を自動的に保護する方法を常に模索しています。可能な限り、AWS セキュリティとそのシステムは、最も効果的な場所で脅威を阻止します。多くの場合、この作業は主に舞台裏で行われています。グローバル規模の脅威インテリジェンスとエンジニアリングの専門知識を組み合わせることで、悪意のある活動に対してサービスの耐性を高め、脅威を軽減するよう努めています。AWS は、Amazon CloudFront などのサービスで使用するプロトコルや、AWS WAF、AWS Shield、 Amazon Route 53 Resolver DNS Firewall などの AWS セキュリティツールなど、サービスの効率性とセキュリティの向上に常に取り組んでいます。 さらに、AWS の取り組みは、AWS 自体の範囲をはるかに超えて、セキュリティ保護と改善を拡大しています。AWS はコンピュータ緊急対応チーム (CERT)、インターネットサービスプロバイダー (ISP)、ドメインレジストラ、または政府機関などの幅広いコミュニティと定期的に連携し、特定された脅威を阻止するのを支援しています。また、セキュリティコミュニティ、他のクラウドプロバイダー、コンテンツデリバリーネットワーク (CDN)、および世界中の協力企業と密接に連携して、脅威アクターを隔離して排除しています。例えば、2023 年第 1 四半期には、130 万件以上のボットネットによる DDoS 攻撃を阻止し、23 万件の L7/HTTP DDoS 攻撃の発信源を追跡して外部機関と協力して解体しました。私たちの緩和戦略の有効性は、脅威インテリジェンスを迅速に捕捉、分析、行動に移す能力に大きく依存しています。こうした取り組みを通じて、AWS は一般的な DDoS 攻撃から防御するだけでなく、保護の範囲は AWS の範囲を越えて拡大しています。この取り組みの詳細については、 AWS 脅威インテリジェンスによる脅威アクターの阻止 をお読みください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 AWS セキュリティに関するニュースにご興味がある場合は、 X をフォローしてください。 Mark Ryland Mark は、バージニア州を拠点とする Amazon のセキュリティディレクターです。技術業界で 30 年以上の経験を持ち、サイバーセキュリティ、ソフトウェアエンジニアリング、分散システム、技術標準化、公共政策の分野でリーダーシップを発揮してきました。AWS で 12 年以上のキャリアを持ち、最初は AWS Worldwide Public Sector チームのソリューションアーキテクチャおよびプロフェッショナルサービスのディレクターとして勤務し、最近では AWS Office of the CISO を設立し、リードしました。 Tom Scholl Tom は AWS の Vice President 兼 Distinguished Engineer です。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

生成 AI のポテンシャルが幅広く認知される中、様々な業界で活用に向けた試行錯誤が続いています。そこで多くの組織が気づきはじめているのは、この最先端テクノロジーを 単に社内で使えるようにするだけでは不十分だ ということです。生成 AI は顧客体験の向上から内部プロセスの合理化まで、業務の様々な側面を革新する可能性を秘めています。しかし、顧客やビジネス知識がなければビジネスインパクト、技術の専門知識がなければ実現コストを評価できず、それぞれを評価できるメンバーが連携しなければ結果として ROI を正確に見積もることは困難です。つまり、組織横断の連携とそれを可能にする経営からの支援がなければ、生成 AI の導入効果は不透明で必要十分な投資を行うことはできないということです。 Gartner の “ 2025 年までに生成 AI プロジェクトの 3 分の 1 が停止する ” との予言は、まさに不透明な ROI に起因しています。 AWS の 100 を超える生成 AI の事例から得られる知見 でも、下図のように Technology 、生成 AI の活用には顧客起点文化を持つ People、小規模なチームや頻繁な実験といった迅速な仮説検証を可能にする Process が重要であるとしており組織とプロセス、それらを支える文化が生成 AI の活用に不可欠であることを示唆しています。 生成 AI の力を本当に活用するなら、経営戦略としてビジネス、技術、双方にかかわる組織から クロスファンクショナルなチームを組成することを最優先に行うべきです 。AWS が無償で公開する ML Enablement Workshop はまさにそのための方法論です。 ML Enablement Workshop は 1) 経営層の支持のもとプロダクトマネージャーなどのビジネスサイド、エンジニア・データサイエンティストなどの技術サイドのリーダー・メンバーを招集したチームを組成する、 2)&nbsp; Amazon のプロダクトづくりのプロセスに基づきプロダクト・サービスの持続的な成長につながる AI/ML のユースケースを特定する、3) 1~3 ヵ月で最初の効果を確認するためのロードマップを作成する 3 つのプロセスを短期で行うワークショップです。本ワークショップを通じお客様が成果を上げられる様子を見て、生成 AI の活用においてチームの組成が鍵であることに確信を持っています。本記事では、その気づきを共有すべく事例を中心にご紹介します。 事例 1 : 組織横断チームでの顧客体験分析 (株式会社ココペリ) ココペリ様の事例は、プロダクトマネージャー、開発者、カスタマーサクセスチーム、データサイエンティストを集め、顧客体験を全員で、全体にわたり分析することの重要性を示しています。 ML Enablement Workshop を通じ、中小企業向の DX 化を支援するプロダクト Big Advance における顧客体験を端から端まで分析し、生成 AI の有効なユースケースを特定。成功を測る KPI と実現に向けたタスクを整理し、ワークショップ終了直後からプロジェクトを始めることができました。 生成 AI は中小企業のビジネスマッチングに活用されており、その詳細は AWS Blog として公開されています 。中小企業ではまだ生成 AI の利用率が低い現状がありますが、Big Advance を通じ生成 AI が中小企業の事業機会の創出に貢献しています。 事例 2 : ビジネス効果駆動で営業 DX を実現&nbsp; (株式会社三菱 UFJ 銀行) 三菱 UFJ 銀行様の事例は、ビジネス部門が顧客への効果を確認し、技術部門が効果が確認された価値創出プロセスを生成 AI で効率化する ビジネス効果駆動での生成 AI の活用 を進められています。営業部門、データサイエンティスト部門を巻き込み ML Enablement Workshop を実施することで、DX 化された営業プロセスのあるべき姿と実現に向けたロードマップを策定しました。ワークショップ終了後 3 ヵ月で最初の顧客提案を行い提案そのものの有効性を確認し、並行してデータサイエンティストのチームが提案の作成の自動化プロセスを実現しています。この緊密な連携が、営業 DX 推進の鍵となっています。さらに、データサイエンティストのチームは、 AWS のプロトタイピング支援により部門職員が利用できるアプリケーション開発のスキルも獲得し、アジャイルな改善プロセスを内製化しています。 三菱 UFJ 銀行様のこの取り組みは、 日本の金融機関初の re:Invent 登壇 として re:Invent 2024 の金融トラックセッションで発表されます。ぜひご視聴ください！ FSI202 | Beyond productivity: Using generative AI to grow in financial services The present has caught up with the future in financial services. New generative AI capabilities have helped financial institutions automate labor-intensive tasks like extracting information from unstructured data sources, summarizing complex documents, and curating market intelligence. These investments in improving productivity have paved the way for the industry to focus on harnessing generative AI to create business value. Companies are engaging more meaningfully with their customers, identifying sales opportunities more efficiently, increasing lead conversion, and driving adoption of new products. Hear from industry leaders how they built and are running new growth-focused generative AI applications in production on AWS. John Kain, Head Financial Service Market Development, Amazon Web Services Tetsuo Horigane, Director, MUFG Bank, Ltd. Aaron Linsky, CTO – AIA Labs, AIA Labs @ Bridgewater Associates Sunny Fok, SVP, Head of AI Innovation Technology, Crypto.com 事例 3: 経営主導の迅速な意思決定と実装 (株式会社セゾンテクノロジー) セゾンテクノロジー様は、CTO 自ら主導してクロスファンクショナルなチームを組成し、生成 AI 活用を推進しています。ML Enablement Workshop では企画、営業、エンジニア、生成 AI 有識者からなるチームを結成し、競合を含めた生成 AI 活用事例をもとに最適なソリューションを検討、2 週間という短期間で経営陣の合意を得て修了後 3 ヵ月で HULFT Square への AI アシスタント機能の実装を完了しています。 セゾンテクノロジー様の取り組みは、 AI Day 2024 のまさに “生成AIを PoC の次のステップに進めるために” と題したトラックで発表頂きます。ぜひご視聴いだたければ幸いです！ 事例 4: 5 ヵ月で本番リリース、さらに特許出願へ (株式会社ペライチ) ペライチ様では、AWS の生成 AI 活用開始プログラムを通じ迅速なユースケースの決定とプロトタイピングを進め、 5 ヵ月という短期間で 本番リリース、プレスリリース、そしてコア機能の特許出願まで進まれています 。本プログラムでは、EC 業界に特化することで ML Enablement Workshop のユースケース決定のプロセスを短縮するとともに、プロトタイピングプログラムと組み合わせて実装面の支援、さらに AWS クレジットの支援という予算的な支援を複合することで生成 AI 活用における代表的な 3 つのブロッカー、「決まらない」「開発リソースがない」「予算がない」の 3 点をオールクリアしました。このプログラムを通じ、ペライチ様はウェブサイト制作時間を 10 営業日以上から 10 分と劇的に短縮する「 ペライチクリエイトアシスタント 」を開発・リリースされています。本プログラムでは オズビジョン様 、 ナビプラス様 も本番稼働、事例化しており AWS Blog で詳細を公開いただいています。本プログラムではビジネス、技術双方の意思決定者がプログラムに参加いただくよう依頼しており、組成されたクロスファンクショナルなチームが技術・予算の支援を受けるとインパクトのあるユースケースが短期間で実現することを示す実例となりました。 ペライチ様の取り組みもまた、 AI Day 2024 の “事例で学ぶ生成 AI 活用と気になる責任ある AI の実践ポイント” と題したトラックで発表を頂きます。ぜひご覧ください！ 結論 経営層の支持に基づくクロスファンクショナルなチームの構築は生成 AI 活用の第一歩にして最重要のプロセスです 。この基盤に、ユースケースを確定するためのワークショップ、プロトタイピング実装支援、予算面の支援といった AWS のプログラムリソースが加わることで劇的な速さで差別化につながる価値を創出できることを 4 つの事例を通じ示しました。 ぜひ、生成 AI の力を活用する第一歩として、自社の組織文化や構造を評価し、効果的なクロスファンクショナルチームの構築を検討いただければ幸いです。 ML Enablement Workshop はまさにそのための方法論であり、 資料はすべて GitHub で公開されています 。本資料を自身で活用いただくことはもちろん、実施に関心がある方は AWS 担当までぜひお問い合わせください。本記事が、皆さんの組織の中で生成 AI の活用を促進、あるいは停滞を解消する鍵となれば幸いです。