お客様は、リポジトリのクローニング、ミラーリング、または特定のブランチの移行など、さまざまな方法を使用して AWS CodeCommit の リポジトリを他の Git プロバイダーに移行できます。このブログでは、リポジトリを一般的なプロバイダーにミラーリングする基本的なユースケースについて説明し、より具体的なプロバイダーにミラーリングする手順へのリンクを提示します。 リポジトリの種類や複雑さ、および移行対象と方法の決定によって、実際の手順は異なる可能性があります。このブログでは、Git リポジトリデータの移行方法のみを説明しており、プルリクエストなど、CodeCommit からの他のデータのエクスポートについては説明していません。 前提条件 CodeCommit リポジトリを別のプロバイダーに移行する前に、AWS Management Console と移行先のプロバイダーのアカウントの両方に必要な認証情報とアクセス許可があることを確認してください。GitHub や Gitlab に移行する場合は、 Git 認証情報を使用した HTTPS ユーザーのセットアップ で説明されているように、CodeCommit の静的認証情報（訳註：静的認証情報とは こちら に記載のある Git 認証情報用のユーザ名とパスワードのことです）を使用します。以下で説明する一般的な移行オプションのプロセスを選択する場合は、CodeCommit の任意の種類の認証情報を使用できます。AWS CodeCommit のアクセス制御のセットアップの詳細については、 AWS CodeCommit のセットアップ をご覧ください。 AWS CodeCommit コンソールで、移行するリポジトリのクローン URL を選択します。正しいクローン URL(HTTPS、SSH、または HTTPS(CRC)) は、使用する認証情報の種類とネットワークプロトコルによって異なります。 図 1: リポジトリのクローン AWS CodeCommit リポジトリを GitLab リポジトリに移行する CodeCommit のクローン URL と HTTPS Git リポジトリの認証情報を組み合わせて利用して、 URL によるリポジトリ から ソースコードをインポート するための GitLab ドキュメントのガイダンスに従ってください。 AWS CodeCommit リポジトリを GitHub リポジトリに移行する CodeCommit のクローン URL と HTTPS Git リポジトリの認証情報を利用して、 ソースコードをインポート するための GitHub のドキュメントのガイダンスに従って ください。 他のリポジトリプロバイダへの一般的な移行方法 1.    AWS CodeCommit リポジトリをクローンする Git を使用して、AWS CodeCommit からローカルマシンにリポジトリをクローンします。HTTPS を使用する場合は、次のコマンドを実行できます: git clone --mirror https://your-aws-repository-url your-aws-repository your-aws-repository-url を AWS CodeCommit リポジトリの URL に置き換えます。 your-aws-repository をこのリポジトリの名前に置き換えます。例 : git clone https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo my-demo-repo 2.    新しいリモートリポジトリを設定する クローンした AWS CodeCommit リポジトリのディレクトリに移動します。次に、新しいリポジトリプロバイダのリポジトリ URL をリモートとして追加します : git remote add <provider name> <provider-repository-url> <provider name> を任意のプロバイダ名に置き換えます ( 例 : gitlab) <provider-repository-url> を新しいリポジトリプロバイダのリポジトリ URL に置き換えます。 3.    ローカルリポジトリを新しいリモートリポジトリにプッシュする これにより、すべてのブランチとタグが新しいリポジトリプロバイダのリポジトリにプッシュされます。プロバイダ名は、ステップ 2 のプロバイダ名と一致している必要があります。 git push <provider name> --mirror 注意事項: リモートリポジトリは空である必要があります。 リモートリポジトリには、force push を許可しない保護されたブランチがある可能性があります。この場合、新しいリポジトリプロバイダに移動し、ブランチ保護を無効にして force push を許可します。 4.    移行を確認する プッシュが完了したら、すべてのファイル、ブランチ、タグが新しいリポジトリプロバイダに正常に移行されたことを確認します。これは、オンラインでリポジトリを参照するか、別の場所にクローンしてローカルで確認することができます。 5.    リモート URL を更新する 移行したリポジトリをローカルで引き続き使用する予定の場合は、リモート URL を更新して、AWS CodeCommit ではなく新しいプロバイダのリポジトリを指すようにすることをお勧めします。次のコマンドを使用してこれを行うことができます: git remote set-url origin <provider-repository-url> <provider-repository-url> を新しいリポジトリプロバイダのリポジトリ URL に置き換えます。 6.    CI/CD パイプラインと保護されたブランチを修正する GitLab、GitHub、AWS CodePipeline など、リポジトリと相互作用する CI/CD パイプラインが設定されている場合は、新しいリポジトリ URL を反映するように構成を更新します。ステップ 3 で保護されたブランチの許可を削除した場合は、メインブランチにこれらを再度追加することをお勧めします。 7.    チームに通知する 他の人が作業しているリポジトリを移行する場合は、移行について通知し、新しいリポジトリ URL を提供してください。 8.    移行済みの AWS CodeCommit リポジトリを削除する この操作は元に戻せません。AWS CodeCommit コンソールに戻り、“リポジトリの削除” ボタンを使用して移行したリポジトリを削除します。 図 2: リポジトリの削除 結論 このブログでは、既存の AWS CodeCommit リポジトリを別の Git プロバイダーに移行する方法をいくつか説明しました。移行後も現在の AWS CodeCommit リポジトリを引き続き使用することができますが、その場合は AWS CodeCommit と新しいリポジトリプロバイダー間で定期的な同期操作が必要になる可能性があります。リポジトリの移行に関する詳細については、以下のリソースを参照してください。 リポジトリを段階的に移行する – このガイドは、リポジトリを CodeCommit に段階的に移行することを目的として書かれていますが、他の Git プロバイダーにも使用できます。 本記事はソリューションアーキテクト松本が翻訳しました。原文は こちら です。

AWS を使ってビルドする場合、インフラストラクチャの管理、アプリケーションのデプロイ、問題のトラブルシューティングなど、AWS リソースとやり取りし、操作する必要があり、多くの AWS の顧客は現在、そのために AWS Cloud9 を使用しています。しかし、開発者はワークフローの無駄をなくして合理化し、慣れ親しんだツールを活用するために、独自の統合開発環境 (IDE) 内で AWS リソースを操作できることを望んでいます。また、AWS 管理コンソールでリソースを操作する際のセキュリティと柔軟性を求めているものの、 AWS Cloud9 を使うより、迅速にアクセスでき、さまざまなページ間で移動できることを望んでいるお客様もいます。このブログでは、 AWS IDE Toolkits と AWS CloudShell の 2 つのソリューションについて説明し、AWS Cloud9 からこれらのソリューションの 1 つに移行する理由を説明します。 概要 AWS IDE Toolkits は、Visual Studio Code、IntelliJ、PyCharmなどの一般的な IDE に AWS サービスを直接統合するオープンソースのプラグインセットです。これらのツールキットを使用すると、開発環境から離れることなく AWS リソースを管理し、アプリケーションをデプロイし、コードをデバッグすることができます。AWS IDE Toolkits の主な機能には、AWS サービスへのシームレスなアクセス、リソースの探索と管理、ローカルデバッグ機能、 AWS CloudFormation や AWS SAM などの AWS デプロイメントツールとの統合が含まれます。AWS IDE Toolkits を使えば、アカウントに AWS Cloud9 EC2 インスタンスをデプロイして管理する手間が省け、IDE のソースコードのコンテキストから AWS サービスと対話できます。 AWS CloudShell は、AWS 管理コンソール内で直接利用可能なブラウザベースのシェルで、AWS リソースとのやり取りを行うための事前に認証済みで構築済みの環境を提供します。 AWS CLI は AWS CloudShell 環境にすでにインストールされているため、 AWS CLI をローカルにインストールおよび構成する必要がなく、どこからでも AWS リソースとの対話が可能になります。 AWS CloudShell を使用して、構成ファイルを確認または調整したり、本番環境に素早く修正を加えたり、新しい AWS サービスや機能を試したりすることができます。何より、 AWS CloudShell の使用は無料です。 AWS 管理コンソール内のどこからでもアクセスできる CloudShell の利便性は、ローカルデスクトップでの操作に制限がある場合に、 Web からコマンドラインで AWS リソースとやり取りしたい時の理想的な選択肢となります。 開始方法 AWS IDE Toolkits を活用することに興味がある場合、簡単に利用を始めることができます。 Visual Studio Code などの一般的な IDEでは、 IDE の拡張機能マーケットプレースから AWS Toolkits 拡張機能をインストール し、AWS 認証情報を使って認証するだけで、すぐに AWS Toolkits の機能を利用できます。インストールの詳細については、 サポートされている各 IDE のオンボーディングステップ を参照できます。 AWS CloudShell を使い始めるには、 AWS マネジメントコンソールの CloudShell アイコンをクリックし、プロンプトに従ってシェル環境を起動するだけです。 CloudShell は、 AWS マネジメントコンソールセッションの認証情報を利用して、事前に認証されたシェル環境を提供します。また、ツールに慣れるために、 詳細なユーザーガイドやサンプルのユースケース を確認することもできます。 図 1 : CloudShell のアイコンをクリックする まとめ AWS IDE Toolkits と AWS CloudShell の両方とも、AWS リソースとのやりとりに強力な機能を提供しています。ローカル IDE 内で作業するか、 AWS マネジメントコンソール内のウェブベースのターミナルで作業するかを選択できます。これらのソリューションは、 AWS インフラストラクチャとアプリケーションを効率的に管理するためのシームレスな方法を提供します。これらのオプションを検討し、開発ワークフローを強化する方法を確認してください。最後に AWS Cloud9 EC2 インスタンスから移行した後は、不要な将来の費用が発生しないように削除することを忘れないでください。 本記事はソリューションアーキテクト紙谷が翻訳しました。原文は こちら です。

7月23日、 Llama 3.1 モデルが Amazon Bedrock で利用可能になったことをお知らせします。Llama 3.1 モデルは、これまでで最も先進的かつ高性能な Meta のモデルです。8B、70B、405B のパラメータサイズモデルのコレクションであり、幅広い業界ベンチマークで最高のパフォーマンスを示し、生成人工知能 ( 生成 AI ) アプリケーションに新機能を提供します。 すべての Llama 3.1 モデルは、 Llama 3 モデル の 16 倍の容量を持つ 128K コンテキスト長 (Llama 3 と比較してトークンが 12 万個増加) をサポートします。また、英語、ドイツ語、フランス語、イタリア語、ポルトガル語、ヒンディー語、スペイン語、タイ語の 8 言語での多言語ダイアログユースケースの推論が改善されました。 このたび Amazon Bedrock で、Meta による次の 3 つの新しい Llama 3.1 モデルを使用して、生成 AI のアイデアを構築して試し、責任を持ってスケールできるようになりました。 Meta によると、 Llama 3.1 405B (プレビュー) は、 一般公開されている世界最大の大規模言語モデル (LLM) です。AI の新しい基準を打ち立てるこのモデルは、企業レベルのアプリケーションと研究開発 (R&D) に最適です。モデルの出力を使用して、より小規模な Llama モデルや モデルの蒸留 を改善し、405B モデルからより小規模なモデルに知識を伝達する、 合成データ生成 などのタスクに適しています。このモデルは、一般知識、長文テキスト生成、多言語翻訳、機械翻訳、コーディング、数学、ツールの使用、コンテキスト理解の強化、高度な推論と意思決定に秀でています。詳細については、 Llama 3.1 405B を使用してモデル蒸留用の合成データを生成する方法 に関する AWS 機械学習ブログをご覧ください。 Llama 3.1 70B は 、コンテンツ制作、会話型 AI、言語理解、研究開発、エンタープライズアプリケーションに最適です。このモデルは、テキストの要約と正確さ、テキストの分類、感情分析とニュアンスの推論、言語モデリング、対話システム、コード生成、指示に従うことに優れています。 Llama 3.1 8B は、計算能力とリソースが限られている場合にお勧めです。このモデルは、低レイテンシーの推論が求められるテキストの要約、テキスト分類、感情分析、言語翻訳に優れています。 Meta は、幅広い言語と広範囲にわたる人間の評価を含む 150 以上のベンチマークデータセットで、Llama 3.1 のパフォーマンスを測定しました。次のグラフからわかるように、Llama 3.1 はすべての主要なベンチマークカテゴリで Llama 3 を上回っています。 Llama 3.1 の機能の詳細については、Meta の Llama 3.1 モデルカード および AWS ドキュメントの Llama モデル をご覧ください。 Llama 3.1 の 責任ある AI 機能と Amazon Bedrock のデータガバナンスおよびモデル評価機能を組み合わせることで、自信を持って安全かつ信頼性の高い生成 AI アプリケーションを構築できます。 Guardrails for Amazon Bedrock – 特定のユースケースに合わせたさまざまな構成のガードレールを複数作成し、ユースケースおよび責任ある AI ポリシーに合わせてカスタマイズした安全対策を実装することで、Guardrails を使用してユーザーと生成 AI アプリケーション間の安全な対話を促進できます。 Guardrails for Amazon Bedrock では、ユーザー入力を継続的に監視および分析し、顧客が定義したポリシーに違反する可能性のある応答のモデル化、企業データに基づかないモデル応答やユーザーのクエリと無関係なモデル応答のハルシネーションの検出、カスタムモデルやサードパーティーモデルを含むさまざまなモデルでの評価を実行できます。利用を開始するには、AWS ドキュメントの「 ガードレールの作成 」をご覧ください。 Amazon Bedrock でのモデル評価 – 自動評価または人間による評価を使用して、わずか数ステップでユースケースに最適なラマモデルを評価、比較、選択できます。 Amazon Bedrock でのモデル評価 では、精度、堅牢性、毒性などの定義済みのメトリクスによる自動評価を選択できます。また、関連性、スタイル、ブランドボイスとの整合性などの主観的指標やカスタム指標について、人間による評価ワークフローを選択することも可能です。モデル評価では、組み込みの厳選されたデータセットを使用するか、独自のデータセットを取り込むことができます。利用を開始するには、AWS ドキュメントの「 モデル評価の使用開始 」をご覧ください。 AWS でデータとアプリケーションを安全かつプライベートに保つ方法の詳細については、 Amazon Bedrock のセキュリティとプライバシー のページをご覧ください。 Amazon Bedrock での Llama 3.1 モデルの使用開始 Meta の Llama モデルを初めて使用する場合は、 Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択します。Meta から最新の Llama 3 モデルにアクセスするには、 Llama 3.1 8B Instruct 、 Llama 3.1 70B Instruct 、または Llama 3.1 405B Instruct へのアクセスを個別にリクエストします。 Amazon Bedrock の Llama 3.1 405B のプレビュー版へのアクセスをリクエストするには、AWS アカウントチームに連絡するか、 AWS マネジメントコンソール でサポートチケットを送信してください。サポートチケットを作成するときに、 [カテゴリ] の [サービスとモデル] で [Amazon Bedrock] を選択します。 Amazon Bedrock コンソールで Meta の Llama 3.1 モデルをテストするには、左側のメニューペインの [プレイグラウンド] で [テキスト] または [チャット] を選択します。次に、 [モデルを選択] を選択し、カテゴリで [Meta] を選択して、モデルで [Llama 3.1 8B Instruct] 、 [Llama 3.1 70B Instruct] 、または [Llama 3.1 405B Instruct] を選択します。 次の例では、Llama 3.1 405B Instruct モデルを選択しました。 また、 [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。 meta.llama3-1-8b-instruct-v1 、 meta.llama3-1-70b-instruct-v1 、または meta.llama3-1-405b-instruct-v1 などのモデル ID を使用できます。 AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id meta.llama3-1-405b-instruct-v1:0 \ --body "{\"prompt\":\" [INST]You are a very intelligent bot with exceptional critical thinking[/INST] I went to the market and bought 10 apples.あなたの友達にリンゴを 2 個、ヘルパーに 2 個あげました。その後、リンゴをさらに 5 個買って 1 個食べました。リンゴはいくつ残っているでしょうか? 一歩ずつ考えてみましょう。\",\"max_gen_len\":512,\"temperature\":0.5,\"top_p\":0.9}" \ --cli-binary-format raw-in-base64-out \ --region us-east-1 \ invoke-model-output.txt AWS SDK を使用する Amazon Bedrock の Llama モデルのコード例 を利用すると、さまざまなプログラミング言語でアプリケーションを構築できます。次の Python コード例は、テキスト生成用の Amazon Bedrock Converse API を使用して Llama にテキストメッセージを送信する方法を示しています。 import boto3 from botocore.exceptions import ClientError # Create a Bedrock Runtime client in the AWS Region you want to use. client = boto3.client("bedrock-runtime", region_name="us-east-1") # Set the model ID, e.g., Llama 3 8b Instruct. model_id = "meta.llama3-1-405b-instruct-v1:0" # Start a conversation with the user message. user_message = "Describe the purpose of a 'hello world' program in one line." conversation = [ { "role": "user", "content": [{"text": user_message}], } ] try: # Send the message to the model, using a basic inference configuration. response = client.converse( modelId=model_id, messages=conversation, inferenceConfig={"maxTokens": 512, "temperature": 0.5, "topP": 0.9}, ) # Extract and print the response text. response_text = response["output"]["message"]["content"][0]["text"] print(response_text) except (ClientError, Exception) as e: print(f"ERROR: Can't invoke '{model_id}'.Reason: {e}") exit(1) Amazon SageMaker JumpStart では、Llama 3.1 のすべてのモデル (8B、70B、405B) を使用することも可能です。 Amazon SageMaker Studio で数回クリックするか、SageMaker Python SDK を使用してプログラムで、Llama 3.1 モデルを見つけてデプロイできます。 SageMaker パイプライン 、 SageMaker Debugger 、または仮想プライベートクラウド (VPC) コントロール下のコンテナログなどの SageMaker 機能を使用してモデルを操作できるため、データのセキュリティを確保できます。 Amazon Bedrock と Amazon SageMaker JumpStart の Llama 3.1 モデルの微調整は間もなく行われる予定です。SageMaker JumpStart で微調整されたモデルを作成して、Amazon Bedrock に カスタムモデルをインポート することも可能です。詳細については、AWS 機械学習ブログの「 Meta Llama 3.1 モデルが Amazon SageMaker JumpStart で利用できるようになりました 」をご覧ください。 基盤となるリソースの柔軟性と制御を強化するために、自己管理型の機械学習ワークフローを通じて AWS に Llama 3.1 モデルをデプロイしたいお客様は、 AWS Trainium と AWS Inferentia を搭載した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用して、高パフォーマンスかつ費用対効果の高い方法で Llama 3.1 モデルを AWS にデプロイできます。詳細については、AWS 機械学習ブログの「 AWS の Meta Llama 3.1 モデルで高性能かつ低コストを実現する AWS AI チップ 」をご覧ください。 このリリースを記念して、Meta の Business Development Manager である Parkin Kent 氏が、Meta と Amazon のコラボレーションの力について語り、両社が協力して生成 AI の可能性の限界を押し広げていることを強調しました。 企業が Amazon Bedrock で Llama モデルを使用し、生成 AI の力を活用している方法をご覧ください。30 の国と地域にまたがるグローバルな金融サービスグループである野村ホールディングスは、Amazon Bedrock の Llama モデルを使用して、組織全体で生成 AI を民主化しています。 今すぐご利用いただけます Meta の Llama 3.1 8B および 70B モデルは一般公開されています。また、Llama 450B モデルは本日、米国西部 (オレゴン) 地域の Amazon Bedrock でプレビューできるようになりました。Amazon Bedrock の Llama 3.1 405B のプレビュー版へのアクセスをリクエストするには、AWS アカウントチームに連絡するか、サポートチケットを送信してください。今後の最新情報については、 詳細なリージョンリスト をご確認ください。詳細については、 Amazon Bedrock での Llama 製品ページ と Amazon Bedrock の料金 ページをご覧ください。 Amazon Bedrock コンソール で Llama 3.1 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 community.aws サイト にアクセスすると、詳細な技術コンテンツを検索することや、ビルダーコミュニティがソリューションで Amazon Bedrock をどのように使用しているかを調べることができます。Amazon Bedrock で Llama 3.1 を使用して何を構築しているのか、ぜひ教えてください。 – Channy 原文は こちら です。

7月15日週、世界中の AWS ヒーロー たちが Global AWS Heroes Summit に集結し、AWS ヒーロープログラムの 10 周年を祝いました。ヒーロープログラムは、開発者コミュニティ内での知識の共有とインパクトの実現において、期待以上の活躍を見せた選り抜きの AWS エキスパートたちの功績を認めるプログラムです。 AWS の CEO であり、長年におよぶ開発者コミュニティサポーターでもある Matt Garman がヒーローたちとの質疑応答セッションに特別参加し、彼らのフィードバックに耳を傾け、質問に答えました。 こちらは、AWS Heroes Summit で撮影されたごきげんな写真です。 Matt が Linkedin の投稿 で述べているとおり、「AWS の創設以来、開発者コミュニティは私たちが行ってきたすべての事柄の中核を成してきました」。 ヒーローの皆さん、いつも本当にありがとうございます。道中お気をつけてお帰りください。 7月15日週のリリース 7月15日週のリリースのうち、私が注目したいくつかのリリースをご紹介します。 Amazon Corretto への 2024 年 7 月更新の発表 – OpenJDK の Corretto ディストリビューションに対する最新の更新が利用可能になりました。これには、長期サポート (LTS) バージョンと機能 (FR) バージョン向けのセキュリティ更新と重要な更新が含まれます。 Amazon Aurora および RDS 向けの新しいオープンソース Advanced MYSQL ODBC Driver の提供開始 – 新しい AWS ODBC Driver for MYSQL は、より高速なスイッチオーバーおよびフェイルオーバー時間に加えて、 AWS Secrets Manager および AWS Identity and Access Management (IAM) の認証サポートを提供することから、 Amazon RDS や Amazon Aurora の MySQL 対応エディションデータベースに接続するためのより効率的でセキュアなオプションになります。 SageMaker Canvas からの微調整された基盤モデルの本番化 – Amazon SageMaker Canvas で、微調整された基盤モデル (FM) の SageMaker リアルタイム推論エンドポイントへのデプロイが可能になりました。これにより、SageMaker Canvas ワークスペース外のアプリケーションへの生成 AI 機能の統合が容易になります。 AWS Lambda が ARM64 アーキテクチャを使用する Java 関数向けの SnapStart のサポートを開始 – ARM64 アーキテクチャ上にある Java 関数向けの Lambda SnapStart は、x86 と比較して最大 10 倍速い関数起動パフォーマンスと最大 34% 優れたコストパフォーマンスを実現するため、AWS Lambda を使用して応答性とスケーラビリティに優れた Java アプリケーションを構築することが可能になります。 Amazon QuickSight がコントロールのパフォーマンスを改善 – Amazon QuickSight でコントロールのパフォーマンスが改善されました。このため、リーダーは関連するすべてのコントロールが再読み込みされるのを待つことなく、すぐさまコントロールを操作できるようになります。この機能強化は、リーダーが経験する読み込み時間を短縮します。 Amazon OpenSearch Serverless がスマートキャッシュ機能のスピードと効率性をレベルアップ – Amazon OpenSearch Serverless でのインデックス作成のための新しいスマートキャッシュ機能は、データを自動的に取得して管理するため、データ取得の高速化、ストレージの効率的な使用、およびコスト削減につながります。 欧州 (ロンドン) リージョンでのベース容量が少ない Amazon Redshift Serverless の提供開始 – 欧州 (ロンドン) リージョンで、Amazon Redshift Serverless の使用を 8 Redshift Processing Unit (RPU) という少ないデータウェアハウスベース容量で開始することが可能になりました。これは、大小さまざまなワークロードにより柔軟でコスト効率性に優れたオプションを提供します。 AWS Lambda が 5 つの新しいリージョンで Amazon MQ for ActiveMQ と Amazon MQ for RabbitMQ のサポートを開始 – AWS Lambda が 5 つの新しいリージョンで Amazon MQ for ActiveMQ と Amazon MQ for RabbitMQ のサポートを開始し、Amazon MQ メッセージブローカーに投稿されたメッセージに基づいて呼び出される Lambda 関数を使用したサーバーレスアプリケーションの構築が可能になりました。 community.aws より community.aws から、私が個人的に最も気に入っている 5 つの記事をご紹介します。 Suman Debnath による「 A Developer’s Guide to Advanced Chunking and Parsing with Amazon Bedrock 」 Mehdi Nemlaghi による「 Enhancing Document Analysis with Embedding Adapters on AWS 」 Kasun de Silva による「 De-Bugging with Amazon Q and Generative AI 」 Ricardo Sueiras による「 Using Amazon Q Developer to update Valkey client code 」 Derek Bingham による「 Software coding practices in an AI assistant world 」 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください。日程は、AWS Summit 台北 (7 月 23～24 日)、AWS Summit メキシコシティ (8 月 7 日)、および AWS Summit サンパウロ (8 月 15 日) です。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。近日開催される AWS Community Day は、 アオテアロア (8 月 15 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日)、 ベルファスト (9 月 6 日) です。 近日開催されるすべての 対面イベント と 仮想イベント を閲覧できます。 7月22日週のニュースは以上です。7月29日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! –  Donnie この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は 2024年7月9日に公開された “ Introducing Valkey GLIDE, an open source client library for Valkey and Redis open source ” を翻訳したものです。 2024年7月9日、私たちは Valkey General Language Independent Driver for the Enterprise (GLIDE) を発表しました。これは、オープンソースでパーミッシブライセンス (Apache 2.0 ライセンス) の Valkey クライアントライブラリです。Valkey は、キャッシュ、セッションストア、リーダーボード、メッセージキューなど、さまざまなワークロードをサポートする高性能のキーバリュー型データストアを提供する、オープンソースで寛容な BSD ライセンスのソフトウェアです。Valkey GLIDE は Valkey の公式クライアントライブラリの 1 つで、すべての Valkey コマンドをサポートしており、 GitHub リポジトリ は valkey.io プロジェクトの下にあります。GLIDE は Valkey 7.2 と Redis オープンソース 6.2、7.0、7.2 をサポートしており、今後の Valkey リリースにも対応し続けます。アプリケーションプログラマーは、GLIDE を使用して、アプリケーションを Valkey と Redis OSS 互換のサービスにセキュアかつ安定して接続できます。Valkey GLIDE は、AWS によって設計および構成されており、10 年以上にわたる数十万人のお客様に使用されている Redis OSS 互換サービスの運用から学んだベストプラクティスが組み込まれています。共通のコアと言語固有のラッパーとして実装されている GLIDE は、アプリケーションプログラミング言語間で一貫した機能とサービス品質を提供します。 この投稿では、Valkey GLIDE の利点について説明します。 エンドツーエンドの運用上の優秀性への課題 クラウドとオンプレミス環境で、データベースとキャッシングワークロードを実行しているお客様は、最適な接続性とクライアントライブラリとサービス間の通信に焦点を当てた、エンタープライズグレードの信頼性と、シームレスな運用上の優秀性を求めています。AWS のインメモリデータベースチームは、13 年以上にわたり数十万人のお客様にサービスを提供する中で、お客様の停止を引き起こす運用上の問題の多くは、クライアント側の障害に起因することを発見しました。たとえば、不適切なエラー処理、不適切な再試行ロジックによる接続管理、不適切なデフォルト設定などが、運用上の問題を引き起こしたり、悪化させたりします。さらに、いくつかのクライアントライブラリはパフォーマンスが最適化されていないか、完全な互換性がありません。たとえば、レプリカからの読み取りをサポートしていないものがあり、クライアント側の読み取り待ち時間に大きな影響を与えます。最後に、マイクロサービスやさまざまなプログラミング言語のアプリケーションを実行しているお客様は、別の課題に直面しています。それは、動作が異なる別々のクライアントライブラリを使用する必要があり、それぞれのクライアントライブラリ用にカスタムコードと設定を個別に開発および保守する必要があるということです。 Valkey GLIDE の紹介 Valkey GLIDE を使えば、開発者は Valkey と Redis OSS ベースのレジリエントなアプリケーションを構築し、一貫したクライアント体験を提供できます。これにより、重大な運用イベントの発生頻度が低減し、発生時の対処が簡素化されます。Valkey GLIDE は AWS によってスポンサーされ、サポートされています。GLIDE は Valkey と Redis OSS のすべてのコマンドをサポートし、信頼性を重視して設計されており、ベストプラクティスに基づいて事前設定されています。たとえば、最適化された DNS 設定と接続処理ロジックにより、ノード障害、クラスタートポロジーの変更、接続の再確立に適切に対応します。 開発とオペレーションの一貫性を実現するため、Valkey GLIDE は Rust で記述されたコアドライバーフレームワークを使用して実装され、サポートされているプログラミング言語向けの拡張機能が提供されています。この設計により、複数の言語での新機能の提供期間が短縮されます。このリリースでは、GLIDE が Java と Python 向けに提供されており、今後さらに多くのプログラミング言語がサポートされる予定です。サポートされている言語のバージョンと前提条件の詳細については、 GitHub リポジトリ を参照してください。 Valkey GLIDE クライアントライブラリの設計 Valkey GLIDE は、Rust で記述されたコアエンジンを基盤とし、ラッパーと呼ばれる言語固有のバインディングと、それらをつなぐ通信層で構成されています。GLIDE の Rust コアは、Rust の代表的な Redis OSS クライアントライブラリである redis-rs に基づいています。Rust は、メモリ安全性と高性能が備わっているため採用しました。次の図は、高レベルの設計を示しています。 Rust コアは、Valkey または Redis OSS との通信を担当し、接続処理、トポロジー調整、エラー管理、RESP プロトコルの解析、メッセージのカプセル化などの機能をカバーしています。言語ラッパーは軽量に設計されており、コアに対する言語固有のインターフェースとして機能します。通信層は、コアとラッパー間のリクエストとレスポンスのシームレスな送受信を提供します。このデザインにより、さまざまなプログラミング言語で一貫したクライアント動作と統一されたインターフェースが実現されます。これは、さまざまな言語で書かれた Valkey または Redis OSS に接続するアプリケーションがある場合に重要で、開発者は同様のクライアント体験ができます。 機能の概要 Valkey GLIDE は、すべての Valkey および Redis OSS コマンドと互換性があり、サポートしています。GLIDE は、ベストプラクティスと業界標準に従って実装された高度な機能をサポートしています。以下はその一例です。 クラスタートポロジー変更の検出による可用性の向上 – Valkey クラスタートポロジーは時間とともに変化する可能性があります。新しいノードが追加または削除され、特定のスロットを所有するプライマリノードが変更される可能性があります。Valkey GLIDE は、Valkey がスロットの所有権の変更を示す場合、ベストプラクティスに従ってクラスタートポロジーを自動的に再検出します。GLIDE は、複数のノードを照会して多数決アルゴリズムを使用し、新しいクラスタートポロジーを判断します。これにより、CLUSTER コマンドの嵐 (レイテンシーを増加させる可能性がある) を回避し、潜在的なダウンタイムを減らし、スプリットブレインネットワークエラーを回避します。さらに、GLIDE は定期的なチェックを実行して、プロアクティブにトポロジー変更を特定します。これらの機能により、GLIDE がクラスタートポロジーと同期し続けることが保証されます。 レプリカからの読み取りによるレイテンシー低減 – データベースのレプリカから読み取ることで、読み取りパフォーマンス、スケーラビリティ、高可用性が向上し、プライマリインスタンスからの読み取り負荷がオフロードされます。デフォルトでは、Valkey GLIDE は古いデータを読み取る可能性を回避するため、特定のスロットを所有するプライマリノードに読み取りコマンドを送信します。これはほとんどのクライアントライブラリと一致しています。最終的な整合性を許容でき、読み取りスループットを優先するアプリケーションの場合、GLIDE はレプリカノードへの読み取りルーティングのオプションを提供します。GLIDE は、特定のユースケースに合わせて選択できる以下のような読み取りレプリカ設定をサポートしています。 PRIMARY (デフォルト) – 常にプライマリから読み取り、最新のデータを取得します。 PREFER_REPLICA – リクエストをすべてのレプリカに対してラウンドロビン方式で分散します。利用可能なレプリカがない場合は、リクエストをプライマリにルーティングします。 ステートフル接続による自動 pub/sub 再購読 – Valkey GLIDE の pub/sub チャネルはステートフルです。切断時や、スケールイン/アウトなどのトポロジー更新時に、GLIDE は自動的に新しいノードへの接続を再購読します。この利点は、アプリケーションコードが単純化され、再接続時に新しいノードへの再購読を処理する必要がないことです。 これらの機能に加えて、GLIDE は Lua スクリプト、非同期 API、トランザクションサポート、タイムアウトや指数関数的バックオフなどの接続処理のベストプラクティスをサポートしています。Valkey GLIDE はすべての OSS コマンドをサポートしています。 使い方 Valkey GLIDE は Java と Python で利用でき、標準のパッケージマネージャーを使ってダウンロードできます。 Python の場合は、pip を使って GLIDE をインストールするには以下のコードを使用してください。 $ pip install valkey-glide GLIDE を Python アプリケーションに統合する方法を示すコードは次のとおりです。 import asyncio from glide import GlideClusterClient, GlideClusterClientConfiguration, NodeAddress async def main(): addresses = [NodeAddress("127.0.0.1", 6379)] config = GlideClusterClientConfiguration(addresses=addresses) client = await GlideClusterClient.create(config) await client.set("test_key", "Hello, Valkey GLIDE!") value = await client.get("test_key") print(value) # Output: "Hello, Valkey GLIDE!" asyncio.run(main()) Java の場合、maven を使用して Valkey GLIDE をインストールするには、 GitHub リポジトリ に記載された手順に従ってください。 次は Java のコード例です: /** Copyright Valkey GLIDE Project Contributors - SPDX Identifier: Apache-2.0 */ package glide.examples ; import glide.api.GlideClusterClient ; import glide.api.models.configuration.GlideClusterClientConfiguration ; import glide.api.models.configuration.NodeAddress ; import java.util.concurrent.ExecutionException ; public class ExamplesApp { // main application entry point public static void main(String[] args) { String host = "127.0.0.1"; Integer port = 6379 ; GlideClusterClientConfiguration config = GlideClusterClientConfiguration.builder() .address(NodeAddress.builder().host(host).port(port).build()).build(); try { GlideClusterClient client = GlideClusterClient.createClient(config).get(); client.set("test_key", "Hello, Valkey GLIDE!").get(); var value = client.get("test_key").get(); System.out.println(value); } catch (ExecutionException | InterruptedException e) { System.out.println("GLIDE example failed with an exception: "); e.printStackTrace(); } } } まとめ クラウドとオンプレミス環境にまたがってデータベースとキャッシングワークロードを実行しているお客様は、エンタープライズグレードの信頼性と運用上の優秀性を求めています。Valkey GLIDE は、これらの目標を達成するのに役立つクライアント体験を提供するように設計されています。AWS がサポートしており、ベストプラクティスが事前設定されています。このリリースでは、GLIDE は Java と Python で利用可能で、他の言語のサポートも積極的に開発中です。Valkey GLIDE はオープンソースで、パーミッシブライセンス (Apache 2.0 ライセンス) が適用されており、バージョン 6.2、7.0、7.2 に対応する Valkey 互換または Redis OSS 互換の配布物であれば、 Amazon ElastiCache や Amazon MemoryDB を含め、どの配布物でも使用できます。主要なオープンソースパッケージマネージャーからダウンロードして始められます。詳細は Valkey GLIDE GitHub リポジトリ で確認でき、コントリビューションも受け付けています。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。

6 月 20 日と 21 日の 2 日間にわたり、幕張メッセにおいて 13 回目となる AWS Summit Japan が「AWSと創る次の時代」をテーマに開催され、会場では 3 万人以上、オンラインも合わせると過去最高となる 5 万人超の方の参加者を記録しました。 流通・小売・消費財業界担当チームでは「Accelerate Innovative Customer Journey（加速するカスタマージャーニーのイノベーション）」をテーマに展示を行い、多くのお客様に足を運んでいただきました。デモをご体験いただいたお客様から多くのフィードバックをいただき、私たちもまた新しいアイデアを考えることができました。このブログでは、流通・小売・消費財業界ブースの展示内容をダイジェストでご紹介します。展示内容に使われている AWS サービスやアーキテクチャの紹介については個別の解説ブログも発行しており、本ブログの中からそれらのブログもご案内しています。 流通・小売・消費財業界ブース　「Accelerate Innovative Customer Journey」 今年のブース展示ではカスタマージャーニーをコンセプトの中心に置き、「ユニファイドコマース」、「生成 AI」、「次世代 IoT 自販機」の 3 つのテーマでのデモ、そしてお客様事例を展示しました。終日、ご来場者が途切れることなく、展示の説明を担当したメンバーは午後には声が枯れてくるほどでした。3 つのテーマでの展示を通して、実店舗を意識した物理デバイスを活用しつつもイマーシブな（没入感のある）体験をご提案します。デモで使ったアプリケーションには特別なものはありません。それぞれのアプリケーションのデザインや実装についてブースでも解説していましたが、その内容を以下のテーマごとに個別のブログでもご紹介していきます。AWS のサービスを組み合わせることで、皆さまのビジネスにもすばやく取り入れることができるものばかりですので、ぜひご活用ください。 1)ユニファイドコマース: 実店舗と e コマースの融合による新たなカスタマージャーニーの実現 Web での閲覧時／来店時／購買時などで異なるチャネルをシームレスに繋ぐ「ユニファイドコマース」を、カスタマージャーニーに沿って体験してもらうことのできるデモをご用意しました。 まずお客様（デモ体験者）は「e コマースサイトで商品を下見」をします。e コマースサイトには、これまでにも何度かご紹介している Retail Demo Store（ こちらのブログ で解説しています） を活用しており、購買履歴に基づくものや検索キーワード連動など Amazon Personalize  の提供する複数のレコメンデーションを確認することができます。 Retail Demo Store 画面イメージ 商品や購入用途によって「実物を見てから購入するかどうか決めたい」、ということは多々あると思います。そうして店舗を訪れたのに目当ての商品の在庫がない…といった体験はないでしょうか。色やサイズなどカスタマイズ可能な商品では、すべてのパターンを店舗に置くことが現実的に難しいという場合もあります。AR/VR などを活用して仮想空間上で見てもらうようなアイデアもあると思いますが、今回は 3D ホログラフィックディスプレイ「 Proto M 」で商品をご覧いただけるようにしました。Proto は今年の 1月の NRF における AWS 展示ブースでも紹介されたデバイスです（ AWS re:Invent Recap インダストリー編「NRF 2024 現地 レポート」 ）。まるで実物がそこにあるかのようなリアルな演出の可能なディスプレイで、拡大縮小回転も思いのまま。よりリアルに、実店舗におけるエンドレスアイルを実現することができます。 商品が決まれば購入です。クレジットカードでお支払いをし、ポイントカードを提示してポイントを付与してもらう、そんな当たり前のレジでの行動も今回のデモでは新しい体験をしていただけるようにしました。 Day 2 基調講演より Day 2 基調講演冒頭でも紹介された、昨年の re:Invent 2023 でプレビューとなったばかり、注目の手のひら認証のための新サービス、 Amazon One Enterprise （2024 年 7 月 24 日時点 Preview）です。ブースでは、Amazon One Enterprise でまずは手のひら情報の登録（顧客 ID との紐づけ）をしていただき、次に購入のタイミングで Amazon One Enterprise に手をかざして手のひら画像をスキャン、登録済みの手のひら認証による会員情報認証を行います。そして、あらかじめ会員情報として登録してあった Amazon Pay で支払いを行います。ブースで Amazon One Enterprise を体験された皆さまからは、「早い」「直感的に使いやすい」といったご感想をいただきました。 ユニファイドコマースは、オムニチャネルのコンセプトをさらに進め、オフラインとオンラインの融合やフリクションレスな購買体験、イマーシブな顧客体験を目指すものです。今回の展示では、オンライン体験（e コマースや Amazon Pay）、店舗体験（3D ディスプレイや Amazon One Enterprise）がどのように繋がるのか、そのアイデアの一例をデモの形でご提案しました。オンラインではデータを活用した顧客インサイトをもとにパーソナライズされたサービス提供が当たり前になっていますが、これを店舗ユースケースにも拡げ、店舗でも手のひら一つで「あなたのためだけの」サービスが提供され、煩わしい「あのクレジットカード出して、このポイントカード見せて」といったことからも解放されます。店舗での購買履歴はオンラインにフィードバックされ、次にアプリにログインしたときにはさらに「あなたの行動や嗜好を理解した」サービスが提供されるようになるでしょう。 この「ユニファイドコマース」で使われているサービスや実現するためのアーキテクチャについては、ブログ「 Amazon One Enterprise の機能とユニファイドコマースの実現 」「 e コマースと店舗を繋ぐ – Immersive Commerce とその店舗への拡張 」で解説しています。 2) 生成 AI が切り開く新たな顧客体験 日本の e コマース市場は拡大している一方で、顧客体験向上と業務効率化がその拡大に追いついていないと言われています。e コマース業務担当者の 2 割が「運用リソース、サポート不足」を課題に感じており、4 割が「リソース不足で CRM 施策を実行できていない」との 調査結果 もあります。ブース展示、2 つ目のテーマにはグローバルトレンドとなった生成 AI を取り上げました。新たな顧客体験／従業員体験として、商品開発のアイディエーション、商品説明文や商品背景画像の生成、ショップアシスタント等の具体的デモや事例でご紹介します。 この展示は e コマースを展開されている企業を想定し、Amazon.com を含めた国内外事例から、生成 AI が課題解決に効果的に使われているユースケースに注目し、「商品企画」「商品登録」「広告」「販売」の4つの領域を特にホットなものとして選定しました。生成 AI には様々なモデルが存在し、業務において実現したいことに合わせてモデルを使い分ける、組み合わせるといったことが必要です。デモを通じて、ユースケースに応じて異なるモデルが利用されていることを体験いただけるようになっています。 まず商品企画段階では、生成 AI によりデザイン案を生成します。デザイナーは多くのスケッチを作りながら構想を重ねるのが一般的です。生成 AI によりデザイナーの言葉を解釈したスケッチの素案を一度にいくつも生成し、その中からイメージに近いものを選んで洗練させていくといったことがより簡単にできるようになります。 新たな商品につける商品説明文の準備も、素材や利用シーン、ターゲットセグメントへのアピールポイントなどを生成 AI に渡せば、生成 AI が支援してくれます。e コマースサイトでは魅力的な商品画像で顧客を惹きつけることも重要です。スタジオを用意し、イメージに合う背景やセットを選択することなしに、言葉で指示するだけで商品背景画像を生成することができます。このような一般に「ささげ業務」と言われる e コマース業務の領域では、生成 AI によって顧客体験を高めつつ、同時に業務効率を図ることができるようになります。 商品販売のシーンにおいても生成 AI は活躍します。自分の探す商品をキーワード検索でぴったり引き当てることはなかなか難しいものです。生成 AI がアシスタントとなり、探しものを手伝ってくれます。 このデモでは、 Amazon Bedrock を使用しています。Amazon Bedrock は、主要な AI スタートアップや Amazon が提供する高パフォーマンスな基盤モデル (FM) を、統合 API を通じて利用できるようにするフルマネージド型サービスです。さまざまな基盤モデルから選択して、ユースケースに最適なモデルを見つけることができます。 今回の展示デモで利用されている基盤モデルや、使いこなすためのプロンプトの工夫などは、個別ブログ「 生成 AI で加速する e コマースの変革 その 1 – EC 業界における 4 大ユースケース紹介 」「 生成 AI で加速する e コマースの変革 その 2 – AWS Summit Japan 2024 で展示した Amazon Bedrock デモの解説 」で詳細に解説しています。 3) 新価格体験を実現する次世代自販機 展示テーマの 3 つ目は、IoT サービスを活用する次世代自販機です。全国の自動販売機は飲料自販機だけでも 220 万台（2023年末時点）で、スーパー 23,000 店や、コンビニ 56,000 店よりはるかに多く、最大の顧客接点と言えます。消費財企業にとって重要な D2C (Direct to Consumer) の販売チャンネルである自動販売機の技術は進化して多様化が進み、飲料にとどまらず、お菓子や冷凍食品、様々な商品が売られるようになっています。空き店舗や店舗の空きスペースでも自販機を活用できると考えられます。自販機は無人店舗のソリューションとして消費財メーカー、小売業の両方において、いろいろな場所で、いろいろなものを販売する試みがなされています。 そんな自販機を題材に、今回は、在庫や周囲環境の状況に合わせて販売価格を最適化する、ダイナミックプライシングのアイデアをデモ用自販機で実演しました。 前述のように最大の D2C チャネルでありながら、自販機は、小売店舗での販売よりも収益向上のための施策の実施が困難だと言われてきました。これは、価格が固定のためにキャンペーンなどによる収益向上が難しい、商品販売以外の新しいビジネスモデルが生まれない、補充するために長距離の訪問が必要となり、また訪問計画の最適化も難しいのでコスト負担になりがちといった要因が挙げられます。近年、センサーなどの技術進化とネットワークの充足により、自動販売機がオンライン化されつつあります。それによって例えばキャッシュレス決済や在庫のリアルタイム把握など、双方向通信などが実現されることによる、デジタルサイネージやロイヤルティプログラムの展開などのアイデアが生まれています。高度な在庫管理に基づいた訪問計画が実現できれば、在庫がもう 1 日は持ちそうな自販機に急いで補充に向かう必要がありません。デジタルサイネージによって広告という新たな収入源を増やすことができたり、自社製品の認知度向上につなげることができます。定価サブスクリプションや特価と連動するロイヤルティプログラムによって、お客様に「意識的に」「優先的に」自社の自販機を選んでもらうことができるようになります。 今回展示する自販機（メンバーお手製です！）には、気温、混雑状況、機内在庫、倉庫在庫の加重平均に基づき動的に販売価格を決定する、ダイナミックプライシングが実現されています。搭載したカメラで混雑状況を把握、内蔵センサーで機内在庫を管理、気温だけは Summit 会場という事情もありセンサー測定ではなく疑似値を利用していますが、リアルタイムデータを収集し、クラウド側で維持する倉庫在庫情報などと組み合わせることで価格を変動させます。ダイナミックプライシングにより、例えば、イベント会場には価格を上げてイベントのない日には安くする、寒い日には冷たい飲み物は価格を下げてみるといった販売戦略をとることで収益向上を図ることができます。 AWS の IoT サービスを駆使したこのようなダイナミックプライシングのアイデア、今回は「自販機」を接点チャネルとして採用しましたが、このデモで実現している「カメラの前の人通り」や「設置場所の温度」によって売値を変える、いわゆる「ダイナミックプライシング」のアイデアは、自販機に限定されるものではありません。店舗内で人の多い・少ないを判断して広告を出し分けるリテールメディアネットワーク、時間帯や温度で値引き品を変えたり特売の判断を行うなど、ベースとなる仕組みは同じです。 利用されている AWS サービスや詳細アーキテクチャは個別ブログ「 【開催報告】 オンライン化によって進化する次世代自販機のご紹介 」で解説しています。 4) お客様事例展示：サントリーグローバルイノベーションセンター株式会社様 最後に、お客様事例のご紹介です。サントリーグローバルイノベーションセンター（以下、SIC）は、サントリーグループ様の基盤研究を担う会社です。サントリーグループ様は飲料食品だけでなくセサミンなどのウエルネス事業でもビジネスを展開されていますが、そこに AI や IoT といった先端テクノロジーを組み合わせたヘルステックの領域でも次々と新しい試みを進められています。テクノロジーによって目には見えない身体の状態が可視化さることで、人々がより健康的な生活を送るためのアドバイスなどが可能になり、それを通して行動変容が起こりやすくなります。そんな研究を進めている、SIC が開発した腸活サポートアプリ「 腸 note 」。今回の展示ブースでは、この腸 note アプリを展示いただきました。 腸 note アプリ画面イメージ（公式サイトより） アプリをインストールしたスマホをおなかにあてるだけで腸の音を取得し、独自開発した AI がその音を解析して腸の健康状態を判断し、おすすめの腸活など健康管理についてのアドバイスを受けられるヘルスケアアプリです。サントリーグループ様は消費財メーカーとして必要とされる 基幹システムの領域でも大規模に AWS を活用 いただいていますが、この腸 note アプリのように、顧客と共に “研究” する新たなビジネスの創造にも力を入れられており、このような領域では新しいアーキテクチャを積極的に取り入れられていらっしゃいます。 腸 note アプリは AWS 上で稼働するサービスで、今回はそのアーキテクチャもご紹介いただきました。 腸 note アプリのアーキテクチャ図（SIC 様提供） サーバーレスアプリケーションとなっていて、 Amazon API Gateway 、 AWS Lambda 、 Amazon DynamoDB という鉄板と言える構成です。腸音を解析するモデル、この軽量モデルはコンテナで動作するのですが、このランタイムには Amazon Elastic Container Service (ECS) ではなく、AWS Lambda を利用されています（参考記事: 「 コンテナランタイムとしての AWS Lambda 」）。堅牢さや安定性を重視する基幹システムのアーキテクチャから、腸 note アプリケーションのようなモダンアーキテクチャまで、そしてそれらのアーキテクチャどうしを繋げるためのデータレイクもまた AWS のモダンデータアーキテクチャを採用と、サントリー様が AWS を「使いこなして」いらっしゃることの一端が垣間見られる展示になっていました。 私ももちろんアプリをインストールして腸活に勤しんでいます。今日の腸活レベルはランク A…。アドバイスに従ってランク S を目指します！ まとめ このブログでは、AWS Summit Japan 2024 流通・小売・消費財業界ブースの展示内容をご紹介しました。ブース展示以外にも、Summit では、基調講演に加えて 2 日間で 150 を超えるセッションが行われました。次のブログではお客様セッションから 5 つ、AWS セッションから 1 つ、流通・小売・消費財業界向けのものをピックアップし、ダイジェストでご紹介する予定です。 流通・小売・消費財業界におけるテクノロジーによるイノベーションは急速に多様化しつつあります。新しい技術を次々と取り込まなくては行けないように思われるかもしれませんが、今回のデモではそれだけでなく、これまでに皆さまの中に蓄積されてきた知識と経験があればすぐに始めていただけるアイデアを考えました。AWS サービスを使えば簡単に実装、展開できる！と実感いただけたのではないでしょうか。ご参加いただけなかった皆さまでも「試してみたい！」と思われた方は、すぐに AWS アカウントチームにご相談ください。来年の Summit でまた、お会いしましょう。 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開していきますのでご覧ください。 流通小売業界向け参考情報 [1] AWS ブログ  ”流通小売” カテゴリー [2] AWS ブログ  “消費財” カテゴリー [3] AWS 消費財・流通・小売業向け ソリューション紹介ページ このブログは、ソリューションアーキテクト 杉中 が担当しました。

顧客にとって、買う前に試すことができるということは重要です。e コマース（以下 EC）と店舗のどちらにおいても、顧客の購入を後押しするためには、商品について十分な情報を提供する必要があります。その手段として近年注目されている技術の一つが、VR/AR/3D をはじめとする Spatial Computing 技術です。特にオンラインショッピングにおける Spatial Computing 技術の活用は Immersive Commerce とも呼ばれ、 Amazon.com をはじめとした EC サイトで実装されています。この記事では、このような EC サイト上での 3D モデルによる購入前体験によって得られるビジネス上のメリットに加えて、ホログラフィックディスプレイのような物理デバイスを利用して、このメリットを店舗に拡張する方法をご提案します。 購入前体験における課題 顧客は、自分が今まで買ったことのない商品を購入するにあたり、その商品について十分な情報を得たいと考えています。流通・小売業界では、店舗で実物に触れるようにすることはもちろん、EC サイト上で写真やテキストでの商品説明、他の顧客による商品レビューを掲載することで顧客に商品の情報を伝えています。しかし、すべての商品タイプでこのような従来の手法による情報提供が十分だとは言えないでしょう。たとえば高額商品では店舗に実物を展示することで盗難等のリスクが懸念される場合がありますし、装飾品など繊細なデザインに価値がある商品の場合は EC 上の写真では詳細まで伝えきれないことがあります。もし受注生産でカスタマイズができる場合、カスタマイズの結果生まれる無数のパターンの在庫を店舗で保持することは在庫管理コストを考えると現実的ではありません。 EC における 3D モデルの活用 そのため、近年の EC サイトでは 3D 技術を活用して、商品を 360 度から詳細に確認することができる機能が取り入れられています。特に Amazon.com では Web AR 技術を活用して、 Virtual Try-On として靴とアイウェア（眼鏡やサングラス）をカメラを通してバーチャルに試着する機能が利用できます。このような Immersive Commerce によるオンラインショッピングの体験向上は、EC サイトで先行して発展してきました。 https://www.amazon.com/b?node=23595320011 デジタルディスプレイを活用した店舗流入と Proto Hologram スマートフォンや PC 等の端末で体験から購入までを完結できることは顧客体験の観点でとても良いことです。これに加えて、顧客が店舗に足を運ぶ機会を増やすことができればさらなる展開が見込めます。例えば店員の接客を通して、もともと購入しようとしていた商品との組み合わせで他の商品も併せて購入することもありますし、店舗における展示が新たな購買のきっかけとなることもあるでしょう。そこで、前述の 3D による商品情報の提供を店舗にも拡張することを考えてみます。 3D による商品情報の提供を行うためには店舗に物理的なデバイスを設置する必要がありますが、もしそのデバイスが一般的なディスプレイよりも 3D 展示に特化し、より実物らしい印象を与えることができれば購買促進の効果は高いです。EC を家庭用のデバイスで見ても十分な情報が得られないときに、専用のデバイスでデジタルに商品詳細を確認できることにより店舗への来店を促すことができます。このような用途に使えるデバイスとしては、頭に被るタイプのデバイス（ヘッドマウントディスプレイ）のほか、ホログラフィックディスプレイなどの立体表示効果をもつ平面ディスプレイがあります。 AWS パートナー Proto Hologram はホログラフィックディスプレイを提供する企業の一つです。OBJ フォーマットなどの 3D ファイルを表示することができるだけでなく、2D のビデオファイルもディスプレイのホログラフィック効果（これをProto は Holoportl 効果と呼んでいます）により立体的に表示されます。ゴーグルやヘッドマウンドディスプレイと異なりデバイスを頭に被るなどの事前準備なしに手軽に、かつ複数の人に同じビジュアルを見せることができると言う特長は、流通・小売業界の店舗に訪れる顧客に対して店員が商品の説明をするというユースケースに合致します。また、商品の展示という用途に使う場合は、複数のデバイスに対して複数のコンテンツを配信する上での管理の簡単さが求められますが、Proto は Proto Cloud というポータルサイトを提供しており、保有する Proto デバイスを複数登録した上で、2D ビデオファイルや 3D モデルファイルの一覧を管理し、それぞれのデバイスにどのコンテンツを配信するかを一括で管理することができます。 流通・小売業界の顧客が新しく Proto のようなデバイスを利用して店舗体験の向上を始める際、コンテンツをどのように準備するかと言う点もポイントです。既存の商品の 3D モデルを準備するためには、複数の角度から商品の画像を撮影した写真を合成して3D モデルを作成するフォトグラメトリや、CAD データから 3D モデルへの変換、もしくは専門のベンダーに手動のモデル作成を依頼するなどの方法が考えられます。フォトグラメトリや CAD データからの変換ソフトウェアで作成を行う場合、自動化のパイプラインは AWS Batch や Amazon Elastic Container Service（Amazon ECS） 、 AWS Step Functions  等を用いてスケーラブルに実現することができます。また、AWS パートナー Hexa は AWS Marketplace 上で 3D コンテンツの作成サービス を提供しています。インタラクティブな体験を提供するアプリケーションとして、 babylon.js 等の Web ベースの 3D エンジンを利用して 3D Web サイトを作成し、 Amazon Simple Storage Service（Amazon S3） でホストするという構成が可能です。 しかし、これらの 3D コンテンツ作成には少なからずコストがかかります。Proto では 2D ビデオを立体的に表示できるという機能によって導入の障壁が下がるため、手持ちの 2D ビデオによって試験的に導入を開始し来店顧客の体験向上の効果を確認した上で、3D モデルの作成やよりインタラクティブな体験、たとえばディスプレイをタッチしながら商品のカスタマイズを行う専用のアプリケーション開発への投資を行うという進め方も可能です。 ブランドのイメージを伝え、店舗内外の顧客の興味を引くためのコンテンツを用意する用途では、生成 AI を利用することもできます。AWS の生成 AI ソリューションである Amazon Bedrock を利用して Amazon Titan Image Generator モデルによって、ブランドのイメージを記載したテキストから画像を生成し、さらに Stability AI Developer Platform API を通して Stability AI’s Stable Video Diffusion を利用して画像から 2D ビデオを生成して Proto ディスプレイで立体的に再生する様子は AWS ブログ テキストからホログラムへーAWS の生成 AI とProto ホログラムで創造性を解き放つ（英語） をご覧ください。 AWS Summit Japan 2024 EXPO 流通・小売・消費財業界向けブースにおける展示内容の紹介 2024 年 6 月に幕張メッセで開催された AWS Summit Japan 2024 では、流通・小売・消費財業界向けブースにおいて上記のユースケースをイメージしていただくためのデモを展示しました。 会場では aws-samples として GitHub で公開 されている EC サイトのリファレンス実装である リテールデモストア をベースにした EC サイトの上で、受注生産のジュエリーが出品されている例を示しました。今回、ジュエリーは店舗に置く上でセキュリティ上の懸念がある高額商品であり、かつ全パターンの組み合わせを在庫として店舗に保持することが難しいカスタマイズ品の例として取り上げました。 そして、ECサイトで興味を持った顧客がより実物に近いものを購入前に確認するために来店した際にお見せする例として、前述の AWS パートナー Proto 社によるホログラフィックディスプレイの卓上モデル Proto M を用いて、EC サイトの上で出品されているものと同じジュエリーの高解像度 3D モデルを展示しました。タッチディスプレイによって自由に拡大・回転ができ、EC サイトでは見ることができなかったジュエリーの裏側の意匠や細部の質感を確認することができます。また、Proto M のWebブラウザ機能を利用して 3D Web サイト経由での表示を行うことで、ジュエリーのカスタマイズ、今回は例として指輪の宝石の種類を変更することができるようになっており、カスタマイズ商品において全パターンを在庫として店舗で確保するというコストをかけずに顧客に十分な情報を提供することができます。 3D Web サイトは今回 Amazon S3 の静的 Web サイトホスティング機能を利用して実現しました。Web ベースで 3D モデルをレンダリングすることができるライブラリ babylon.js を用いて、 React で作成した Web サイトで 3D モデルを表示しています。ジュエリーの宝石の色を変更するといった 3D モデルの制御についても React で実現しています。 まとめ 本記事では、流通・小売業界における顧客体験の向上の手段としての Spatial Computing 技術に焦点を当て、一例として EC における 3D モデルの活用、さらにホログラフィックディスプレイを利用して EC 上の 3D 体験を店舗に拡張するユースケースをご紹介しました。 AWS は、流通・小売業界における Spatial Computing 技術の活用について、ユースケースの特定から実装サポートまで一貫したご支援を提供しています。今回 AWS Summit Japan 2024 で展示した AWS パートナーの Proto など、AWS における Spatial Computing 技術のエコシステムも活用してぜひ貴社の顧客体験の向上を実現してください。 このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWS 担当営業もしくは こちらの窓口 までご連絡ください。 以下本記事に関連するブログをご紹介いたします。ご興味ありましたらこちらもぜひ併せてご覧ください。 地球環境を救う：Hexa on AWS による大規模な没入型店舗体験の実現 没入型テクノロジーが小売業界にもたらす変革 著者について 阿南 麻里子は、アマゾンウェブサービスのソリューションアーキテクトです。エンタープライズの流通・小売・消費財業界のお客様を支援しています。また、技術領域としては AR/VR/3D 等の Spatial Computing 領域を担当し、Immersive Commerce や店舗における Spatial Computing 技術を活用した顧客体験向上を日本の流通・小売・消費財業界のお客様に実現していただくための活動をしています。

Amazon One Enterprise は、Amazon Web Services (AWS) の新たな生体認証サービスとして昨年 2023 年 11 月に発表され、AWS Summit Japan 2024 では日本で初めて実機を展示しました。この Amazon One Enterprise は、手のひらと静脈の画像を組み合わせて生体認証を行うことで、99.9999 ％の高い精度を実現しています。また、高度な暗号化方式を使用し、AWS 規格に従って手のひらデータをクラウド上に保存しており、安全に利用できる非接触型生体認証サービスとなっています。 Amazon One Enterpriseとは Amazon One Enterpriseは、手のひらと静脈の画像を ID にリンクすることで、ID を正確に認証できる非接触型 ID 認証サービスです。これによりバッジやパスコードなしで、建物、企業資産、企業システム、店舗システムへのセキュアなアクセスが可能になります。これまでは、 Amazon One が、Amazon Go、Amazon Fresh、旅行小売店、スポーツ・エンターテインメント会場、コンビニエンスストア、食料品店などで、ロイヤリティ識別、支払い、入場、年齢確認などの様々な小売/商業利用シナリオで利用されてきました。2024 年 7 月現在、Amazon One は 全米 Wholefoods 500 店 舗以上 で導入されています。そして今回ご紹介する Amazon One Enterprise により、この機能が AWS プラットフォーム上のすべての企業に拡張されました。 Amazon One Enterprise の機能 Amazon One Enterprise で使用されている Amazon One デバイスは登録モードと認証モードの２種類となり、登録モードのデバイスにて、手のひらと静脈の画像データから一意の手のひら署名ベクトルを作成、ID と連携されます。 認証モードのデバイスにおいては、登録されているベクトル情報と正確に照合することで安全な認証を行い、該当の手のひら署名ベクトルと連携されている ID を返します。ID と手のひら署名ベクトルデータは Amazon One デバイスには保存されず、AWS クラウド上に暗号化され、アカウント単位で保護・保存されます。データ管理は、AWS アカウントを持つお客様の責任です。なお米国では、 モバイルアプリからの登録方法 も開始されており、店頭における登録作業の省力化も可能となります。 Amazon One Enterprise のセキュリティ Amazon One Enterprise によって生成された、手のひら署名ベクトルは複製や偽造することはできません。Amazon One Enterprise には複数のセキュリティ対策が施されており、不正な改ざんを検知した場合はデバイスを無効化する機能があります。Amazon One デバイスで手のひらを読み取ると、手のひらと静脈の画像はすぐに暗号化され、Amazon One Enterprise 専用の非常に安全な AWS クラウド環境に送信されます。そこで固有の手のひら署名ベクトルが作成、保存されます。このクラウド環境へのアクセスは厳しく制限されており、AWS 上にある ID 、手のひら署名ベクトルデータを、政府機関やその他機関に共有することはありません。Amazon One Enterprise は、法的に有効で拘束力のある命令に従う必要がある場合を除き、いかなる状況でも第三者とデータを共有することはありません。データプライバシーの詳細については、 こちらのリンク を参照してください。 Amazon One Enterprise の精度 Amazon One Enterprise は 99.9999 ％という高い精度を持ち、虹彩認識の 100 倍の精度を持ちます。これは手のひらと静脈の画像を組み合わせることで生体認証の水準を引き上げたためで、この精度を実現するために Amazon One のトレーニングには生成 AI を使った合成データを活用しています。さまざまな照明条件、手の位置、さらにはバンドエイドの有無など、微妙な変化を反映した多量の合成した手のひら画像と皮下の血管画像を使って Amazon One をトレーニングしたことで、システムの精度を高めることができており、精度の維持とさらなる向上を目指して継続して研究と改善を進めています。Amazon One において生成AIをどのように活用しているか、 ぜひこちら を参照してください。 Amazon One Enterprise の接続方式とユースケース Amazon One Enterprise では各モードごとにサポートする接続方式があります。登録モードにおいては QR コードスキャンもしくは USB 接続したバッジスキャナーからの ID の入力と手のひら署名ベクトルの連携ができます。 認証モードにおいては以下３つの通信方式に対応しています。Amazon One Enterprise のユーザーガイドは こちら を参照してください。なお、登録および認証イベントをお客様の Amazon EventBridge と連携することも可能なため、お客様の都合に合わせて出力をさらにカスタマイズすることができます。 OSDP (Open Supervised Device Protocol) ／ Wiegand プロトコルでの接続 アクセスコントロールのための通信方式で、認証とドア開閉コントローラーと組み合わせることで、入退館、入退室に利用されるプロトコルになります。この通信方式でドア開閉コントローラーと連携することで、制限エリアにおける入室、ビルの入館、データセンターへの入館等で、バッジの代わりに非接触による入退室が可能になり、カードの紛失や盗難の心配がなくなります。また、ホテルの厨房からの入退室時にバッジを触ることなく、非接触での入退室ができることで手洗いの手間を省くといった利用も可能です。 WebAuthn Authenticatorとしての接続 Amazon One デバイスは、WebAuthn Authenticator として機能し、準拠したブラウザやオペレーティングシステムで認証を行うことができます。これにより、薬品棚やホテルの受付など、共有端末で実行されるソフトウェアでユーザーを特定した形で安全に、パスワードレスログインを行うことができます。このように、生体認証によりセキュリティを高め、パスワード共有などによる共有端末の不正使用を防ぐことができます。 柔軟な USB 出力と認証後 ID との連携 Amazon One Enterprise の認証結果に基づき、認証された ID を接続デバイスに USB 通信で出力することができます。この ID はAmazon One Enterprise によるセキュアな認証の結果送信されるため、このメンバー ID を受け取った後、ID に対してのビジネスワークフローを実行できます。例えば、認証されたメンバー ID に対する決済処理を、POS などの店舗システムと連携して行うことが可能になります。これにより、すでに会員向け支払い処理を持っている場合には、会員 ID との連携を行うことで既存支払処理を活用したフリクションレス購買が実現できます。AWS Summit Japan 2024 では、EC サイトで持つ会員 ID と仮想 POS 端末との Amazon One Enterprise を利用した連携によるフリクションレス購買体験のデモを行いました。 Amazon One Enterprise を用いた 非接触型生体認証によるユニファイドコマースの実現 顧客の購買行動は、Web での閲覧時、来店時、購買時などで分かれて実施され、購買体験としてシームレスな経験を提供することは難しいと考えられてきました。今回 AWS Summit Japan 2024 において、日本初登場となる Amazon One Enterprise 実機を用いて、店舗と e コマースをシームレスに繋ぎ、実用的な体験を提供することを目指しました。ここでは、EC サイトで持つ会員 ID と Amazon One Enterprise による生体認証連携、仮想 POS 端末での会員 ID による購買を手のひらで実施することで顧客購買情報の統合を実現し、デモとして展示しました。仮想 POS 端末での会員向け支払処理には Amazon Pay を使った形としています。 AWS Summit Japan 2024 デモにおける構成 登録モードの Amazon One Enterprise と EC サイトの会員 ID取り込み 仮想 POS 端末と認証モードの Amazon One Enterprise 店舗購買情報が含まれた EC サイトでの履歴イメージ 連携した Amazon Pay での支払い完了の様子 Amazon Pay と Amazon One Enterprise の連携 また、会員 ID と Amazon One Enterprise の組み合わせにより、Amazon Pay を用いて店舗システムでの決済処理を実現することができます。上記の AWS Summit Japan 2024 で実現した連携は以下になります。 対象ECサイトで Amazon Pay を使い Amazon アカウントでログインします。 EC サイトの会員情報と Amazon アカウント情報を紐づけた後、支払い方法を Amazon Pay に設定します。 設定後、アカウント情報が紐づいた QR コードが発行されるので保存します。 発行された QR コードと手のひら（決済を行う手）を 対象店舗に設置されている 専用端末 ( Amazon One Enterprise ) でそれぞれ登録し、アカウント情報と手のひらの情報を紐づけます 以降、対象店舗での決済時、 登録した手のひらを端末にかざすだけで、 一般的なタッチ決済のように Amazon Pay による決済が実現できます。Amazon Pay についての詳細な情報は こちら をご参照ください。 まとめ 今回、AWS Summit Japan 2024 で日本で初めて実機展示となった Amazon One Enterprise についての機能とユースケースのご紹介、また、Amazon One Enterprise を用いた、EC サイト・店舗の異なる購買チャネルにおける顧客体験の統合の実現例をご紹介しました。Amazon One は非接触型生体認証サービスとして 2020 年に登場以来、AWS 規格に従ってデータ・セキュリティとプライバシーを守るとともに、常に改善し、高い精度を持っています。同時に認証の高速性、利便性についても追求を続けることで非接触型生体認証サービスとして高く評価され、2023 年 11 月には Amazon One Enterprise として、店舗における決済だけでなくビルや企業資産、企業システムや店舗システムへのセキュアなアクセスを実現するサービスとして登場し、企業はますます Amazon One ／Amazon One Enterprise を導入しています。あらたな顧客体験、従業員体験を提供する、EC サイト・実店舗での顧客購買行動を統合することもできる、実用的かつ革新を実現するサービスとなっています。ぜひ皆様の課題解決にご検討ください。 本ブログは AWS Japan のソリューションアーキテクト 山下 智之 が執筆しました。

顧客とエージェントのチャット対話中にファイルを共有できる機能は、全体的な顧客体験を大幅に向上させる重要な利点があります。顧客がチャットセッション中に文書、画像、スクリーンショットなどのファイルを共有できるようにすることで、より明確なコミュニケーションが可能になり、顧客の問題をより包括的に理解できます。これにより、問題の解決が早まり、より顧客にパーソナライズした対応ができます。エージェントは添付ファイルを使用して、製品ガイド、トラブルシューティングの手順、または必要な情報を共有することで、提供するサポートをより充実させることができます。さらに、関連する視覚情報を送信できることで、複雑な概念の説明が容易になり、誤解を減らし、顧客満足度を高めることができます。例えば、エージェントが最近のホテルの請求書のコピーを送信したり、顧客が破損した製品の写真を共有したりできます。 添付ファイルの送受信機能を有効にすることは対話の強化に重要ですが、同時にマルウェア、ウイルス、ランサムウェア、トロイの木馬に感染したファイルや不適切な画像など、悪意のあるファイルに晒されるリスクを高めることになります。悪意のあるファイルは、顧客とエージェントの両方のデータを危険にさらす重大な脅威となる可能性があります。これは受信者のシステムにのみ影響を与えるだけでなく、企業の評判に対してもリスクがあり、企業が顧客と収益を失う原因にもなります。 Amazon Connect では、顧客とエージェントがチャットでファイルを共有したり、エージェントが Amazon Connect Cases を使用してケースにファイルをアップロードすることができます。チャットのシナリオでは、添付ファイルがチャット記録に含まれるため、コンタクトが別のエージェントに転送された場合でも、その会話の完全な文脈を理解することができます。ファイルはAmazon Simple Storage Service (S3) バケットに保存されるため、顧客関係管理 (CRM) システムやケース管理システムなど、他のシステムからもアクセスできます。 ソリューションの概要 このソリューションでは、 Amazon Rekognition のコンテンツモデレーション を使用して、一般的または業界固有の基準やプラクティスに基づき、画像内の不適切、不要、または攻撃的なコンテンツを特定します。例えば、 Amazon Rekognition ベースのスキャナーは機械学習を使用して露骨なコンテンツを検出します。これにより、安全なユーザー体験を推進し、顧客にブランドの安全性を保証し、地域およびグローバルな規制に準拠することができます。 AWS Lambda 関数 “ConnectAttachmentScanner” を作成し、指定された JPEG または PNG 形式の画像に露骨な内容がないかを検出する Amazon Rekognition DetectModerationLabels API を呼び出します。この Lambda 関数は、スキャンが必要な画像の場所に関する情報を渡す役割を担います。Lambda 関数から返される応答には、画像スキャンプロセスの承認ステータスが含まれます。この例では、Lambda 関数の応答に 1 つ以上の ラベルカテゴリ が存在する場合に、画像が拒否されます。 Amazon Connect との添付ファイルスキャナー統合をセットアップするには、 CreateIntegrationAssociation API を使用して AWS Lambda の Amazon リソースネーム (ARN) を指定し、integration type パラメーターを “FILE_SCANNER” に設定します。 アーキテクチャ お客様が Amazon Connect によってホストされている コミュニケーションウィジェット を使ってウェブサイトからチャットを開始するか、 Amazon Connect Chat SDK を使ってモバイルアプリケーションからチャットを開始します チャットの対話が、 Amazon Connect のフロー 設定に基づいて、応対可能なエージェントにルーティングされます お客様またはエージェントがチャットで 添付ファイル を送信すると、そのファイルが Amazon S3 バケットにアップロードされます Amazon Connect インスタンスが、ファイルのスキャンを処理する添付ファイルスキャナーである AWS Lambda 関数を呼び出します スキャナー Lambda 関数が S3 バケットからファイルを取得します スキャナー Lambda 関数が Amazon Rekognition DetectModetationLabel API を呼び出します Amazon Connect は、Lambda の応答ステータスに基づいて、添付ファイルを APPROVED または REJECTED にマークします。結果が REJECTED の場合、S3 内の添付ファイルは、一時的な保存場所と最終的な保存場所の両方から自動的に削除されます 手順 この手順では、 AWS Serverless Application Model (SAM) を使用して、画像ファイルのスキャナーを作成する方法を示します。SAM アプリケーションをデプロイし、スキャナーを実装するために必要なインフラストラクチャを構築します。次に、デプロイされた画像ファイルスキャナーを Amazon Connect インスタンスに統合し、Amazon Connect コンソール内で利用可能なテストチャットユーティリティを使用してソリューションをテストし、最後にデプロイしたソリューションをクリーンアップします。 前提条件 この手順を実施するには、以下の前提条件を満たす必要があります: AWS アカウント プログラムによるアクセスが可能な IAM ユーザー 添付ファイルが有効 になっている既存の Amazon Connect インスタンス ユーザー、ポリシー、ロールを作成する権限を持つ AWS IAM ローカルにインストールされた AWS SAM CLI と、 AWS CLI の使用経験 チャットの添付ファイルが保存される Amazon S3 バケット名。詳細については、Amazon Connect 管理者ガイドの データストレージの更新 を参照してください ステップ 1: IAM ユーザーアカウントにアクセス許可を割り当て AWS Management Console を使用して、ID (ユーザー、ユーザーグループ、ロール) にアクセス許可を追加できます。これを行うには、アクセス許可を制御する管理ポリシーを割り当てるか、 アクセス許可境界 として機能するポリシーを指定します。インラインポリシーを埋め込むこともできます。 ユーザーまたはロールにインラインポリシーを埋め込むには (コンソール) AWS Management Console にサインインし、 IAM コンソール ( https://console.aws.amazon.com/iam/ ) を開きます ナビゲーションペインで ユーザー を選択します リストから、ポリシーを埋め込むユーザーの名前を選択します 許可 タブを選択します 許可を追加 ドロップダウンから インラインポリシーを作成 を選択します ポリシーエディター セクションで JSON オプションを選択し、以下のポリシーを貼り付けます { "Version": "2012-10-17", "Statement": [ { "Sid": "0", "Effect": "Allow", "Action": [ "iam:GetRole", "iam:PassRole", "iam:DetachRolePolicy", "iam:CreateRole", "iam:DeleteRole", "iam:AttachRolePolicy", "iam:PutRolePolicy", "iam:DeleteRolePolicy" ], "Resource": "arn:aws:iam::111122223333:role/sam-app-LambdaRole-*" }, { "Sid": "1", "Effect": "Allow", "Action": [ "connect:CreateIntegrationAssociation" ], "Resource": "arn:aws:connect:aa-example-1:111122223333:instance/a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa/integration-association/*" }, { "Sid": "2", "Effect": "Allow", "Action": [ "lambda:AddPermission", "lambda:RemovePermission", "lambda:CreateFunction", "lambda:TagResource", "lambda:GetFunction", "lambda:DeleteFunction", "lambda:PutFunctionConcurrency" ], "Resource": "arn:aws:lambda:aa-example-1:111122223333:function:sam-app-ConnectAttachmentScanner-*" } ] } 貼り付けたポリシー内を以下の通り変更します: aa-example-1 を AWS リージョンに置き換えます 111122223333 を使用する AWS アカウント ID に置き換えます a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa を Amazon Connect インスタンス ID に置き換えます。 Amazon Connect のインスタンス ID/ARN を見つける方法については、Amazon Connect 管理者ガイドをご覧ください ポリシー名を入力し、 ポリシーの作成 をクリックします ステップ 2: SAM アプリケーションのビルド・デプロイ このステップでは、 Amazon Rekognition による画像ファイルスキャナーのサーバーレスアプリケーションを作成する SAM アプリケーションをデプロイします。AWS SAM CLI の使用に慣れていない場合は、AWS Serverless Application Model 開発者ガイドの「 AWS SAM の使用方法 」に移動して、AWS SAM CLI のインストールとセットアップ方法を確認してください。 Git を使用して、GitHub からリポジトリをクローンします git clone https://github.com/aws-samples/safeguard-your-environment-and-reduce-reputational-risk-using-amazon-connect-attachment-scanning リポジトリがダウンロードされたディレクトリに移動します cd safeguard-your-environment-and-reduce-reputational-risk-using-amazon-connect-attachment-scanning SAM でソリューションをビルドします sam build ソリューションをデプロイします。対話型のフローでは、AWS SAM CLI がアプリケーションのデプロイ設定を構成するためのオプションを求めます。 S3BucketName を Amazon Connect チャット添付ファイル S3 バケットに置き換えてください 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]: ENTER AWS Region [eu-west-2]: ENTER or provide the desired region Parameter ConnectBucketName []: S3BucketName #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [Y/n]: ENTER #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: ENTER #Preserves the state of previously provisioned resources when an operation fails Disable rollback [y/N]: ENTER Save arguments to configuration file [Y/n]: ENTER SAM configuration file [samconfig.toml]: ENTER SAM configuration environment [default]: ENTER Previewing CloudFormation changeset before deployment ====================================================== Deploy this changeset? [y/N]: y Successfully created/updated stack - sam-app in aa-example-1 ステップ 3: デプロイされたアプリケーションの表示・確認 デプロイされたアプリケーションを表示するには、以下の手順を実行します。 URL https://console.aws.amazon.com/cloudformation で AWS CloudFormation コンソールを直接開きます スタック を選択します アプリケーション名でスタックを特定し、選択してリソースを表示します sam-app-ConnectAttatchmentScanner-021345abcdef6789 のような名称の Lambda 関数をクリックし移動します Lambda 関数の ARN をコピーします。この情報は次のステップで必要になります ステップ4: Amazon Connect インスタンスを添付ファイルスキャナーと統合 AWS CLI を使用して、次のようにコマンドを実行します。 aws connect create-integration-association \ --instance-id a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa \ --integration-type FILE_SCANNER \ --integration-arn arn:aws:lambda:aa-example-1:111122223333:function:sam-app-ConnectAttachmentScanner-021345abcdef6789 Successful response: { "IntegrationAssociationId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "IntegrationAssociationArn": "arn:aws:connect:aa-example-1:111122223333:instance/a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa/integration-association/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } 前述のコマンドを実行する際は、以下の操作を行います。 a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa を Amazon Connect インスタンス ID に置き換えます arn:aws:lambda:aa-example-1:111122223333:function:sam-app-ConnectAttachmentScanner-021345abcdef6789 を添付ファイルスキャナーの AWS Lambda 関数の ARN に置き換えます ソリューションのテスト このセクションでは、Amazon Connect でホストされたコミュニケーションである、チャットウィジェットを使用して、添付ファイルスキャナーソリューションをテストします。Amazon Connect 管理ウェブサイト内で利用可能な テストチャット ユーティリティを使用して、添付ファイルスキャナーの機能を検証することもできます。 シナリオ マリア ガルシアは AnyCompany 社の顧客です。2 日前、フィットネスの目標をトラックするため、新しいスマートウォッチを受け取りました。ウォッチを開封した後、マリアは血中酸素濃度を測定する機能がないことに気づきました。そこで、返品を要求するため AnyCompany アカウントにログインし、Web アプリケーションを介してチャットを開始しました。 AnyCompany の経験豊富なエージェント、ジョン スタイルズがチャット対応を受け付けました。ジョンはマリアに挨拶をし、返品要求に関する支援を申し出ました。ジョンは、マリアに返品したいスマートウォッチの購入証明書のアップロードを求めました。マリアはクリップのアイコンを選択して必要な文書を添付しようとしましたが、誤って写真フォルダに保存されていた処方薬の写真をアップロードしてしまいました。薬物関連のコンテンツをブロックするよう設定されたスキャナーによって、その処方薬の画像は拒否されました。 顧客体験 その後マリアは新しいスマートウォッチの購入証明書をアップロードしました。添付ファイルスキャナーがファイルを受け入れ、ジョンに表示されました。 エージェント体験 ジョンは返金リクエストのガイドラインに従い、AnyCompany Retail の返品ポリシーをマリアと共有します。このドキュメントで、マリアはリクエストの予想される処理時間などの有用な情報を知ることができます。彼女はまた、印刷して荷物に貼り付けることができる発送ラベルも受け取りました。 エージェント体験 顧客体験 クリーンアップ 継続的な課金を避けるためには、プロジェクトのルートフォルダに移動し、次のコマンドを実行してください: sam delete Are you sure you want to delete the stack sam-app in the region aa-example-1 ? [y/N]: y Are you sure you want to delete the folder sam-app in S3 which contains the artifacts? [y/N]: y これにより、Amazon S3 にパッケージングおよび展開されたアーティファクトを含む AWS CloudFormation スタックが削除され、AWS SAM アプリケーションが削除されます。 Amazon Connect インスタンスから添付ファイルスキャナーの関連付けを削除するには、次のコマンドを実行します: aws connect delete-integration-association \ --instance-id a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa\ --integration-association-id a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 前述のコマンドを実行する際は、ステップ 3 から取得した値を使用して以下を行ってください: a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa を Amazon Connect インスタンス ID に置き換えます。 a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 を添付ファイルスキャナー統合関連付け ID に置き換えます。 結論 この投稿では、添付ファイルスキャナーソリューションと Amazon Connect を統合する方法について説明しました。この機能を使用すると、以下のことができます。 既存の脅威スキャンソリューションを Amazon Connect と連携する お客様を悪意のある活動から保護し、安全な環境を運用する 評判リスクを軽減し、顧客体験を向上させる Amazon Connect と添付ファイルスキャンのセットアップの詳細については、Amazon Connect 管理者ガイドをご覧ください。 Amazon Connect で顧客サービス体験を変革する準備はできましたか ? ぜひ お問い合わせ ください。 Marwan Bassyouni  は、AWS WWSO Applications のカスタマーエクスペリエンススペシャリストソリューションアーキテクトAmazon Connect に特化し、様々な業界の組織がカスタマーエクスペリエンスソリューション (CX) とデジタルトランスフォーメーションを通じてビジネス目標を達成できるよう支援しています。プライベートでは、家族と一緒にビーチに行って良い時間を過ごしたり、ジムで限界に挑戦したりしています。熱心なマンチェスターユナイテッドのサポーターでもあり、最新の試合や移籍のニュースについて議論する準備が常にできています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

システムやサービスを提供する上で、障害はつきものです。障害を迅速に分析し対処することがユーザビリティやサービス信頼性を向上し、結果顧客満足度につながります。一方で近年システムは複雑さを増しており、障害特定が従来に比べて難しくなっています。したがって障害分析の効率化や高度化が重要になっています。 従来の手動による障害分析では、膨大なログデータの中から問題の根本原因を特定するのに多大な時間と労力を要し、ダウンタイムの長期化やサービス品質の低下につながる可能性がありました。そこで注目されているのが、人工知能 (AI) や機械学習 (ML) を活用した障害分析です。 AI/ML による高度な分析技術を用いることで、障害の早期発見、迅速な原因特定、さらには予防的な対策まで可能になりつつあります。 本記事では、汎用的に利用できる大規模言語モデル (Large Language Models 、以下 LLM) を活用した障害分析の高度化についてご紹介します。障害分析の課題から LLM で障害を分析するメリット、 AWS サービスを利用した障害分析サポートソリューションの紹介、そして導入に向けた課題と対策について詳しく解説します。障害分析にまだ慣れていない方から、障害分析プロセスの効率化を検討しているアーキテクトや SRE(Site Reliability Engineer) の方々まで、幅広い読者を対象としています。 従来の障害分析の課題 従来の障害分析では、以下のような課題がありました。 膨大なログデータの処理に時間がかかる 複雑な障害パターンの把握が困難 人的リソースへの依存度が高い 分析結果の再現性や一貫性の確保が難しい これらの課題により、障害対応の遅延や見落としが発生し、結果としてサービスの信頼性低下につながる可能性があります。 LLM を活用した障害分析 LLM による障害分析の概要 ここでいう LLM を活用した障害分析とは、ログやトレース、メトリクスなどシステムから取得できるテレメトリデータを LLM に渡すことで、LLM がテレメトリデータを元に分析を行い、分析結果を自然言語でユーザーにフィードバックすることを指します。これにより、複数のテレメトリデータを元にシステムがどういった状態になっているのか、いつ、なにが、どうして起こったのかを、自然言語で理解することができるようになります。 LLM による障害分析の特徴 LLM を活用した障害分析では、以下のような特徴を持ちます。 大量のデータを高速に処理 パターン認識による異常の検出 人間には気づきにくい微細な変化の検出 これらの特徴により、従来の手法では困難だった高度な障害分析を行うことができます。 LLM を活用した障害分析のメリット LLM を障害分析に導入することで、以下のようなメリットが期待できます。 1. 障害特定の迅速化 LLM を利用することで、膨大なログデータやメトリクスを短時間で解釈し、状態や事象の因果関係、障害の有無について分析し、自然言語で表現することができます。これにより、人間による分析では見逃しがちな微細な変化や、複雑な相関関係を素早く分析することができます。 例えば、ネットワークトラフィック、CPU使用率、メモリ消費量など、複数の指標を同時に監視し、それらの相関関係から異常を検出し、原因を特定することができます。 2. 属人化からの脱却 従来の障害分析では、ノウハウが暗黙知になったり、学習機会が少なく初心者の立ち上げが難しいなど、分析の効率や速度が属人化している状況にありました。 LLM を利用して膨大なデータを瞬時に分析し、自然言語で要約することができるため、これまで障害分析の経験がない初心者でも短時間で分析が可能となります。 3. 様々なシステムで利用できる 過去の障害に関するデータを元にモデルを作成することで、そのシステムに適した障害分析の高度化を実現することができますが、多くの時間と労力を要します。一方で LLM を利用した障害分析であれば、必要なものはテレメトリデータと一般的な LLM のみで分析することができます。したがって様々なシステムやサービスで今すぐ活用することが可能です。 AWSサービスを活用した LLM による障害分析ソリューション ここからは AWS を利用し LLM によって障害分析を行う方法を紹介します。 概要 AWS では LLM を利用するためのサービスが複数ありますが、今回は Amazon Bedrockを利用します。大枠の流れとしては、まずチャットから AWS Lambda を起動します。このLambdaの中で、下図③のテレメトリデータ（ログ、トレース）の収集、 下図④の収集したテレメトリデータをプロンプトに埋め込み Amazon Bedrock を利用して要約、の順で処理を行います。ユーザーにはチャット上で障害の概要や各テレメトリデータを読み取った結果、それらを踏まえ障害の根本原因として考えられる事象を確認することができるものとなっています。また利用しているサービスは全てサーバレスで提供されるものを利用しており、サーバの管理、運用は必要ありません。 利用サービス Amazon Bedrock サーバーレスな API サービスで基盤モデルを使用し、生成 AI アプリケーションを構築することができます。サービスの詳細については こちら をご確認ください。 今回は収集したテレメトリデータを要約し、自然言語で障害発生時の事象や障害の根本原因について要約する際に利用します。 AWS Lambda サーバーをプロビジョニングまたは管理することなくアプリケーションを構築するために使用できるコンピューティングサービスです。サービスの詳細については こちら をご確認ください。 今回はチャットアプリケーションによって起動され、ログを Amazon CloudWatch Logs 、 Amazon Simple Storage Service (Amazon S3) 、トレースを AWS X-Ray から取得し、それらを Amazon Bedrock を利用して要約する一連の流れを実行します。 構築手順 ソースコードは、 Failure Analysis Assistant (FA2) にあるので、ご利用ください。 またこちらは、 AWS Summit Japan 2024 のブースで展示されていた、「 AIOps で障害分析を効率化してみよう 」のソースコードとなります。Summit 期間中気になっていた方は、ぜひこちらのサンプルをお試しください。 1. パラメータ設定 parameter.sample.ts をコピーし、 parameter.ts を作成、利用したい環境に合わせ、値を変更します。 CloudWatch のロググループは利用に必須です。しかし、S3 に保存される ALB のアクセスログや CloudTrail のログ、X-Ray のトレースは任意の設定項目となります。 // 例: Slack App 版で、Claude 3 Sonnet を利用し、CloudWatch Logs、Athena、X-Ray、を検索対象とした場合の設定 export const devParameter: AppParameter = { env: { account: "123456789012", region: "us-east-1", }, language: "ja", envName: "Development", clientType: "SLACKAPP", modelId: "anthropic.claude-3-sonnet-20240229-v1:0", cwLogsLogGroups: [ "ApiLogGroup", "/aws/ecs/containerinsights/EcsAppCluster/performance" ], cwLogsInsightQuery: "fields @message | limit 100", databaseName: "athenadatacatalog", albAccessLogTableName: "alb_access_logs", cloudTrailLogTableName: "cloud_trail_logs", xrayTrace: true, }; 2. CDKデプロイ 通常の CDK のデプロイと同じようにデプロイします。 $ npm install $ npx cdk bootstrap --profile {your_profile} $ npx cdk deploy --all --profile {your_profile} --require-approval never 3. Slack App の設定 FA2 の Slack App を設定します。細かくはGithubのREADME.mdを参照いただければと思いますが、行うことは以下のようなタスクです。 Slack App を利用したいワークスペースへ登録 API Gateway のエンドポイントを Slack App のエンドポイントとして設定 Slack App の Token と Signing Secret をコピーし、parameter.ts を更新 Slack 上で動作させるために必要な権限を付与 利用手順 アラート受信後に表示される FA2 のフォームに、[ アラートの概要 ]、[ ログの取得開始日時 ]、[ ログの取得終了日時 ]を入力し、ボタンをクリックします リクエストが受け付けられると表示が変わるので、少し待ちます テレメトリデータ（ログ、トレース）の収集とLLMによる推論を終えると、回答が表示されます 構築および LLM を利用した障害分析を始めるにあたっての Tips 1. ログの設計が重要 ログ設計が正しく行われていないと、LLM も理解することができません。適切なログ設計が解析のポイントとなります。 例：誤ったログレベルで出力している、適切なログメッセージになっていない、フォーマットが統制されていない、分析に必要な情報が出力されていない 2. 障害分析のトリガーとなるアラームは必須 アラームによる通知から、イベントの発生時間を判断し必要なログやトレースの収集を行うことになります。アラームや通知がない場合にはテレメトリデータの収集を行えないため、アラームと通知は必須です。 3. 取得するテレメトリデータの種類は様々であり試行錯誤が必要 ログだけで見ても、アプリケーションログ、CloudFront、ALB が出力するアクセスログ、 CloudTrail のログ、セキュリティサービスの検知結果など、障害分析に向けて利用できるものは多くあります。どのログを利用するか、どのログを利用することで障害を特定することができるかはシステムによって異なるため、適したログを選択する必要があります。 追加のテレメトリデータが必要になった場合でも、AWS では API や SDK を利用することで容易に追加で取得することができます。 4. 大きなコンテキストウィンドウを持つ LLM の利用を推奨 プロンプトとして LLM に渡すテレメトリデータが多くなる傾向になるため、コンテキストウィンドウが大きい LLM が必要になります。 例えば、Claude モデルは 200,000 トークンのコンテキストウィンドウを持ちます。 Amazon Bedrock を利用することで、大きなコンテキストウィンドウの新しい LLM が出た際にも簡単に LLM を切り替えることができます。 LLM を活用した障害分析の導入に向けた課題と対策 LLM を活用した障害特定で考えられる主な課題とその対策について解説します。 1. 誤った分析結果の提供 課題 : 現時点での LLM ではハルシネーションのリスクがあり、分析結果が必ずしも正しくない可能性があるの現状です。 対策 : LLM を利用した障害分析はあくまで支援ツールであり、最終判断は人間が行うという原則を徹底する ログ検索に利用したクエリを回答メッセージの補足に含め、最終判断をしやすくする 今回は利用していませんが、さまざまなメトリクスをダッシュボードとして表現し、 LLM の出力結果とダッシュボードとの比較を行い、妥当性を判断する 定期的に分析結果を元に LLM の精度や性能を評価し、モデルの切り替えを検討する 2. データの質と量の確保 課題 : 利用する LLM の性能に加えて、プロンプトとして渡すログやトレースの量と品質によって、分析の精度が大きく影響します。十分な量の高品質なデータがなければ、精度の高い分析は困難です。 対策 : ログ、メトリクス、トレースなど、多様なデータソースを統合する データクレンジングや正規化のプロセスを設け、データの品質を向上させる 3. プライバシーとセキュリティの確保 課題 : 障害データには機密情報が含まれる可能性があり、データの取り扱いには注意が必要です。 対策 : データの匿名化や暗号化を徹底する アクセス権限の厳格な管理を行う LLM を活用した障害分析ソリューションのさらなる拡張 上記ソリューションではチャットをインターフェースとし、人が分析条件を定義してきましたが、機能を拡張することによってさらに高度化することができます。 1. マルチクラウド・ハイブリッド環境での統合分析 クラウド、オンプレミス、エッジコンピューティングなど、環境を跨いだログやトレースを収集することで、複雑化するIT環境全体を統合的に分析するシステムを構築することができます。これにより、環境の違いを超えた一貫性のある障害分析と対応を実現することができます。 2. 自然言語処理によるインタラクティブな対応 上記ソリューションでは単一の AWS Lambda を利用してログやトレースの取得を行いましたが、 Agents for Amazon Bedrock を導入し異なる処理を行う複数の AWS Lambda の使い分けを LLM に委ねることによって、より柔軟な障害分析をシームレスに進められるようになります。これにより、LLM の分析結果から追加で質問を投げることによってより詳細に分析するなど、高度な分析が可能となり、迅速な意思決定につながります。 3. 将来的な自己修復システムの実現 障害を検知し、その原因を特定するだけでなく、適切な修復アクションを自動的に実行する「自己修復システム」の実現が期待されています。これにより、人間の介入なしに多くの障害が自動的に解決され、システムの可用性が飛躍的に向上する可能性があります。現時点では LLM の要約を人が判断し、復旧に向けたアクションを定義する必要がありますが、今後 LLM や AI/ML の精度が向上することでより自動化の範囲を広げることができると考えられます。 結論 AI/ML を活用した障害分析は、ITシステムの複雑化と大規模化に伴う課題に対する強力なソリューションとなります。迅速な障害検知、効率的な根本原因分析、予知保全の実現など、多くのメリットをもたらす一方で、データの質と量の確保、プライバシーとセキュリティの問題、人材育成など、導入に向けてはいくつかの課題も存在します。 しかし、これらの課題に適切に対処することで、AI/ML は障害分析の強力な味方となり、システムの信頼性向上と運用コストの削減に大きく貢献します。さらに、将来的には自己修復システムの実現など、さらなる進化が期待されています。 すでに取得を開始しているログやトレースを LLM を使って分析するだけでも障害分析を効率化、高度化することは可能です。事前学習やサーバ管理など不要な手段で今すぐ取り掛かっていただければと思います。 著者 鈴木 陽三 (Yozo Suzuki) アマゾン ウェブ サービス ジャパン合同会社 プロトタイプ ソリューション アーキテクト 好きなAWSのサービスは、AWS CDKとIAM Identity Center 趣味は、マンガとカメラで娘の写真を撮ること 津郷 光明 (Mitsuaki Tsugo) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト SIerにて金融系システム開発、企画を経て AWS Japan へ入社。 好きな技術分野は Observability と Infrastructure as Code

本投稿は Implementing multi-Region failover for Amazon API Gateway (記事公開日: 2024 年 7 月 8 日) を翻訳したものです。 本投稿は、プリンシパルソリューションアーキテクト Marcos Ortiz と、シニアソリューションアーキテクト Khubyar Behramsha によって書かれています。 この投稿では、AWS コントロールプレーンの操作に依存することなく、信頼性の高いフェイルオーバー メカニズムを使用して、単一リージョンの API Gateway アーキテクチャからマルチリージョンのアーキテクチャに進化する方法を学びます。AWS Well-Architected ベストプラクティスは、リカバリ中は データプレーンに依存し、コントロールプレーンに依存しない ことです。フェイルオーバーコントロールは、 プライマリリージョンに依存しない ように機能する必要があります。このパターンは、共有パブリック API の背後にデプロイされた個々のサービスに依存せずにフェイルオーバーする方法を示しています。さらに、 GitHub で公開されているオープンソースコード を使用して、提案されたアーキテクチャをデプロイおよびテストする方法について順を追って解説します。 多くの組織にとって、 AWS Well-Architected のベストプラクティスに沿って構築されたリージョナル Amazon API Gateway エンドポイントを使うことで、レジリエンス、シンプル性、および経済性のバランスが適切に保たれます。ただし、ビジネスの重要性、規制要件、または災害復旧目標によっては、一部の組織はマルチリージョンアーキテクチャを使用してAPIを展開する必要があります。 ビジネスクリティカルなアプリケーションを扱う際、組織は通常、フェイルオーバーをトリガーする方法とタイミングを完全に制御したいと考えます。手動でトリガーされるフェイルオーバーでは、依存関係を特定の順序でフェイルオーバーさせることができます。承認プロセスに沿ったフェイルオーバーの実施は、準備ができていないレプリカへのフェイルオーバーや、一時的な障害による フラッピング 問題を防ぐのに役立ちます。フェイルオーバーアクションやトリガーには人の判断を挟む要素がありますが、その後の処理はできるだけ自動化することが推奨されます。このアプローチにより、アプリケーションの所有者は、一時的な問題が発生した場合にフェイルオーバーを実行できるなど、フェイルオーバープロセスを制御できます。 概要 お客様にとって一般的なアプローチは、 カスタムドメイン名 を使用したパブリックリージョナル API をデプロイし、ユーザーにとってより直感的な URL を提供することです。バックエンド側では、 API マッピング を使用して、複数の API ステージをカスタムドメインに接続します。このアプローチにより、サービス所有者は同一最上位 API ドメイン名を共有しながら、独立してサービスをデプロイできます。このパターンに従った典型的なアーキテクチャは次のとおりです。 リージョナルエンドポイントとマッピング しかし、この構成をマルチリージョンアーキテクチャに進化させようとすると、組織は各サービスを個別にフェイルオーバーさせることに苦労することが多くあります。前述のアーキテクチャをそのままの形で 2 つのリージョンにデプロイした場合、API Gateway の背後にあるすべてのサービスを一気にフェイルオーバーするか、まったくフェイルオーバーを行わないかの、all-or-nothing シナリオになります。 マルチリージョンアーキテクチャへの進化 各チームが独立してサービスを管理およびフェイルオーバーできるようにするには、マルチリージョンアーキテクチャにこの新しいアプローチを実装できます。各サービスには独自のサブドメインが割り当てられ、 API Gateway HTTP 統合 を使用してリクエストを特定のサービスにルーティングします。この仕組みによって、各サービスのサービス API を使って個別にフェイルオーバーを実施するか、あるいは共有パブリック API を使って一括でフェイルオーバーを実施するかという柔軟性が得られます。 マルチリージョンアーキテクチャ 下記がサービスへのリクエストフローです: ユーザーは、URL サフィックスを使用してパブリック共有 API ドメイン名を介して特定のサービスにアクセスします。たとえば、service1 にアクセスするには、エンドユーザーは http://example.com/service1 にリクエストを送信します。 Amazon Route 53 には、プライマリおよびセカンダリ フェイルオーバーレコード が登録されたトップレベルドメイン example.com があります。これにより、リクエストがプライマリリージョン (us-east-1) の API Gateway 外部 API エンドポイントにルーティングされます。 API Gateway は HTTP 統合 を使用して、リクエストを https://service1.example.com の service1 に転送します。 Amazon Route 53 には、プライマリおよびセカンダリ フェイルオーバーレコード が登録されたドメイン service1.example.com があります。これにより、正常な場合はリクエストがプライマリリージョン (us-east-1) の API Gateway service1 API リージョナルエンドポイントにルーティングされ、異常な場合はセカンダリリージョン (us-west-2) の service1 API リージョナルエンドポイントにルーティングされます。 Amazon Route 53 で構成された service1 のプライマリルートを表します。 Amazon Route 53 で構成された service1 のセカンダリルートを表します。 このソリューションでは、各サービスAPIをプライマリリージョン(us-east-1)とセカンダリリージョン(us-west-2)の両方にデプロイする必要があります。両リージョンで同じカスタムドメイン構成が使用されます。プライマリリージョンでは、各サービスのプライマリDNSレコードがリージョナルAPIゲートウェイディストリビューションエンドポイントを指します。セカンダリリージョンでは、各サービスのセカンダリDNSレコードがセカンダリリージョンのリージョナルAPIゲートウェイディストリビューションエンドポイントを指します。 Route 53 レコード アクティブ/パッシブ手動フェイルオーバー ここで紹介する例は、Amazon Route 53 の コントロールプレーン に依存しない、信頼性の高いフェイルオーバーメカニズムを可能にします。 5 つの異なる AWS リージョンにまたがる 5 つのリージョナルエンドポイントを持つクラスターを提供する Amazon Route 53 Application Recovery Controller (Route 53 ARC) を使用しています。フェイルオーバープロセスではこれらのエンドポイントを使用し、コントロールプレーン操作であるAmazon Route 53 DNSレコードの手動編集は行いません。Route 53 ARC の ルーティングコントロール により、プライマリリージョンからセカンダリリージョンへのトラフィックのフェイルオーバーが行われます。 Route 53 ARC ルーティングコントロール ルーティング コントロールは、トラフィックをワークロードの 1 つのインスタンスから別のインスタンスに転送可能とする on/off スイッチです。トラフィックの再ルーティングは、関連する DNS ヘルスチェックを正常または異常に設定した結果です。 Route 53 ARC の on/off 切り替え サンプルアプリケーションのデプロイ 前提条件 Amazon Route 53 に登録されたパブリックドメイン (example.com) が必要です。 ドメインを登録する方法 の手順に従ってドメインを登録してください。また、 Amazon Route 53 を DNS サービスとして構成する 手順に従ってAmazon Route 53 を構成してください。 プライマリリージョンとセカンダリリージョンの両方で、サンプル API をデプロイする予定のドメイン名 (*.example.com) に対する AWS Certificate Manager 証明書が必要です。 Amazon Route 53 ARC スタックのデプロイ まず、Amazon Route 53 ARC スタックをデプロイし、クラスターと API のフェイルオーバーを可能にするルーティング制御を作成します。 Amazon Route 53 Application Recovery Controller (ARC) スタックをデプロイする に記載されている詳細手順に従ってAmazon Route 53 ARC スタックをデプロイしてください。 プライマリリージョンとセカンダリリージョンへの Service1 API のデプロイ 各リージョンにAPI Gateway リージョナルエンドポイントをデプロイし、リクエストを処理するサービス名と現在のAWSリージョンを返す AWS Lambda 関数を呼び出します。 {"service": "service1", "region": "us-east-1"} 下記は Lambda 関数のソースコードです: import json import os def lambda_handler(event, context): return { "statusCode": 200, "body": json.dumps({ "service": "service1", "region": os.environ['AWS_REGION']}), } service1 のスタックをデプロイ にある詳細手順に従ってデプロイしてください。 プライマリリージョンとセカンダリリージョンへの Service2 API のデプロイ このスタックはservice1と似ていますが、ドメイン名が異なり、サービス名としてservice2を返します。 {"service": "service2", "region": "us-east-1"} service2 スタックをデプロイ にある詳細手順に従ってデプロイしてください。 プライマリリージョンとセカンダリリージョンへの共有パブリック API のデプロイ この手順では、example.com/service1 または example.com/service2 を呼び出したときに、service1 と service2 のために設定した各自のパブリック DNS レコードにリクエストをルーティングするように HTTP エンドポイントを構成します。 外部 API スタックをデプロイ にある詳細手順に従ってデプロイしてください。 フェイルオーバーテスト デプロイされたサンプルアプリケーションをテストするには、提供されているテストスクリプトを変更して実行してください。 test.sh ファイルの 3 行目から 5 行目を、APIs 用に設定したドメイン名を参照するように更新してください。 実行権限を付与してスクリプトを実行します: chmod + x ./test/sh ./test.sh このスクリプトは5秒ごとに3つのエンドポイントそれぞれにHTTPリクエストを送信します。Amazon Route 53 ARCを使用すると、サービスを個別にフェイルオーバーでき、異なるリージョンからのレスポンスを確認できます。 最初は、すべてのサービスがトラフィックを us-east-1 リージョンにルーティングしています。 初期ルーティング 次のコマンドで、service1 の 2 つのルーティングコントロールを更新 し、プライマリリージョン (us-east-1) のヘルスチェック状態を off に、セカンダリリージョン (us-west-2) のヘルスチェック状態を on に設定します。 aws route53-recovery-cluster update-routing-control-states \ --update-routing-control-state-entries \ '[{"RoutingControlArn":"arn:aws:route53-recovery-control::111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/abcdefg1234567","RoutingControlState":"On"}, {"RoutingControlArn":"arn:aws:route53-recovery-control:: 111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/hijklmnop987654321","RoutingControlState":"Off"}]' \ --region ap-southeast-2 \ --endpoint-url https://abcd1234.route53-recovery-cluster.ap-southeast-2.amazonaws.com/v1 数秒後、スクリプトターミナルに service1 が us-west-2 にトラフィックをルーティングしていることが表示されますが、他のサービスは引き続き us-east-1 リージョンにトラフィックをルーティングしています。 service1 をセカンダリリージョンに切り替えている service1 を us-east-1 リージョンにフェイルバックするには、次のコマンドを実行し、service1 のプライマリリージョン (us-east-1) のヘルスチェック状態を on に、セカンダリリージョン (us-west-2) のヘルスチェック状態を off に設定します。 aws route53-recovery-cluster update-routing-control-states \ --update-routing-control-state-entries \ '[{"RoutingControlArn":"arn:aws:route53-recovery-control::111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/abcdefg1234567","RoutingControlState":"Off"}, {"RoutingControlArn":"arn:aws:route53-recovery-control:: 111122223333:controlpanel/0123456bbbbbbb0123456bbbbbb0123456/routingcontrol/hijklmnop987654321","RoutingControlState":"On"}]' \ --region ap-southeast-2 \ --endpoint-url https:// abcd1234.route53-recovery-cluster.ap-southeast-2.amazonaws.com/v1 数秒後、スクリプトターミナルに service1 が他のサービスと同様に us-east-1 リージョンにトラフィックをルーティングしていることが表示されます。 ルーティングの復旧 クリーンアップ 作業が完了したら、GitHub の クリーンアップ手順 に従ってクリーンアップを実施してください。 結論 このソリューションは、API Gateway を使用してクリティカルワークロードを管理するチームに制御権を取り戻すのに役立ちます。フロントエンドとバックエンドを分離することによって、このソリューションは Amazon Route 53 ARC を使用してサービスレベルでフェイルオーバーを細かく制御し、コントロールプレーンアクションへの依存関係を排除することで、組織に粒度の細かい制御を与えます。 また、説明したパターンでは、シングルリージョンからマルチリージョンアーキテクチャに移行する際に、同じパブリック API とトップレベルドメインを使用できるため、サービス利用者への影響も軽減されます。 より多くの AWS レジリエンスについて学ぶには、 AWS Architecture ブログ – レジリエンス をご覧ください。 サーバーレスの学習をさらに深めたい方は、 Serverless Land をご覧ください。 本ブログはソリューションアーキテクトの銭 敏娟が翻訳しました。原文は こちら です。

本投稿は Automating model customization in Amazon Bedrock with AWS Step Functions workflow (記事公開日: 2024 年 7 月 11 日) を翻訳したものです。 大規模言語モデルは、幅広いビジネスユースケースにおいて知的で的確な応答を生成するのに必須となっています。しかし、企業は独自のデータやユースケースを持っており、大規模言語モデルをそのままの状態で使うだけでは不十分で、カスタマイズが必要になる場合があります。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon などの主要な AI 企業から、単一の API を通じて高性能な基盤モデル(FMs)を選択できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能も提供しています。 Amazon Web Services (AWS) は、AWS re:Invent 2023 で Amazon Bedrock でモデルをカスタマイズする 機能をサポートすることを発表しました。これにより、お客様は独自の専有データを使って選択したモデルを事前学習し、モデルのレスポンスを自社のビジネス環境に合わせてカスタマイズできるようになります。カスタムモデルの品質は、トレーニングデータの品質と、モデルをカスタマイズするために使用されるハイパーパラメータなど、複数の要因に依存します。そのため、お客様の要件に最適なカスタマイズモデルを開発するために、複数の反復作業を行う必要があります。 この課題に対処するため、AWS は Amazon Bedrock と AWS Step Functions の間のネイティブ統合を 発表しました 。これにより、お客様は Amazon Bedrock モデルをカスタマイズするための、反復処理可能で自動化されたワークフローをオーケストレーションできるようになります。 この投稿では、Step Functions がモデルカスタマイズにおける主な課題や問題点の解消にどのように役立つかをデモンストレーションします。モデルの学習、評価、モニタリングをオーケストレーションするサンプルワークフローの構成方法を学びます。反復可能なフレームワークを通じてこれらの複雑なタスクを自動化することで、開発期間を短縮し、企業の固有ニーズに合わせて Amazon Bedrock の真価を発揮させることができます。 アーキテクチャ このデモでは、Amazon Bedrock の Cohere Command Light Model を使用した要約のユースケースを利用します。ただし、このワークフローは、ベースモデル ID と必要な ハイパーパラメータ を渡し、ワークフローでモデル固有の軽微な変更を加えることで、他のモデルの要約ユースケースにも使用できます。カスタマイズがサポートされているモデル一覧については、Amazon Bedrock の ユーザーガイド を参照してください。必要なすべてのインフラストラクチャは、 AWS Serverless Application Model (SAM) を使用してデプロイされます。 以下は、このアーキテクチャの機能概要です。 ユーザーは、JSON Line 形式のトレーニングデータを Amazon Simple Storage Service (Amazon S3) のトレーニングデータバケットにアップロードし、検証用および推論用の参照データを検証データバケットにアップロードします。このデータは JSON Line 形式でなければなりません。 Step Function  CustomizeBedrockModel ステートマシンは、カスタマイズするモデル、ハイパーパラメータ、トレーニングデータの場所および本投稿の後半で説明するその他のパラメータなどの入力パラメータで開始されます。 ワークフローは、Amazon Bedrock の CreateModelCustomizationJob API を同期的に呼び出し、S3 バケットからのトレーニングデータと渡されたハイパーパラメータを使用してベースモデルをファインチューニングします。 カスタムモデルが作成された後、ワークフローは Amazon Bedrock の CreateProvisionedModelThroughput API を呼び出し、コミットメントなしでプロビジョニングされたスループットを作成します。 親ステートマシンは、子ステートマシンを呼び出し、カスタムモデルの性能をベースモデルと比較して評価します。 子ステートマシンは、S3 検証バケットからの同じ検証データを使用してベースモデルとカスタムモデルのプロビジョニングされたスループットを呼び出し、推論結果を推論バケットに格納します。 AWS Lambda 関数が呼び出されてカスタムモデルとベースモデルによる要約の品質を BERTScore メトリックで評価します。カスタムモデルがベースモデルよりも性能が悪い場合、プロビジョニングされたスループットは削除されます。 結果を通知するメールが送信されます。 前提条件 AWSアカウントを持っていない場合は AWS アカウントを作成 します。 AWS マネジメントコンソールと AWS Command Line Interface (AWS CLI) を使用して AWS アカウントにアクセスできる必要があります。使用する AWS Identity and Access Management (IAM) ユーザーには、必要なAWSサービスの呼び出しとこの投稿で言及されているAWSリソースの管理を行う権限が与えられている必要があります。IAM ユーザーに権限を付与する際は、 最小特権原則 に従ってください。 Git がインストールされている必要があります。 AWS Serverless Application Model (AWS SAM) がインストールされている必要があります。 Docker がインストールされ、実行状態になっている必要があります。 AWS SAM テンプレートを実行する AWS リージョンの Amazon Bedrock コンソールで、Cohere Command Light Model アクセスを有効にする必要があります。このデモでは、モデルをカスタマイズします。ただし、このワークフローは、他のサポートされているモデルのカスタマイズにも、モデル固有の軽微な変更を加えることで拡張できます。カスタマイズに対応するモデル一覧については、Amazon Bedrock ユーザーガイド を参照してください。このデモを実行するには、ベースモデルに対してモデルユニットの確約予約がない必要があります。 デモ準備 このデモンストレーションのリソースは、米国東部 (バージニア北部) AWS リージョン (us-east-1) にプロビジョニングされます。モデルのカスタマイズワークフローを実装するために必要な下記のフェーズについて順を追って説明します。 AWS SAM テンプレートを使用してソリューションをデプロイします 独自のトレーニングデータを S3 バケットにアップロードします Step Functions ワークフローを実行し、モニタリングします ベース基盤モデルのトレーニング結果を確認します クリーンアップを行います ステップ 1:AWS SAM テンプレートを使用したソリューションのデプロイ 最新の手順については GitHub リポジトリを参照してください。Step Functions ワークフローをデプロイするには、AWS SAM テンプレートを使用してください。以下の手順に従ってください。 ターミナルで新しいディレクトリを作成し、そのディレクトリに移動して GitHub リポジトリをクローンします: git clone https://github.com/aws-samples/amazon-bedrock-model-customization.git ソリューションディレクトリに移動します: cd amazon-bedrock-model-customization build.sh を実行してコンテナイメージを作成します。 bash build.sh プロンプトが表示されたら、次のパラメータ値を入力してください: image_name=model-evaluation repo_name=bedrock-model-customization aws_account={your-AWS-account-id} aws_region={your-region} コマンドラインから、AWS SAM を使用して template.yml ファイルで指定されているパターンに必要な AWS リソースをデプロイします: sam deploy --guided プロンプトが表示されたら、以下の入力を提供してください: Enter a stack name. Enter us-east-1 or your AWS Region where you enabled Amazon Bedrock Cohere Command Light Model. Enter SenderEmailId - Once the model customization is complete email will come from this email id. You need to have access to this mail id to verify the ownership. Enter RecipientEmailId - User will be notified to this email id. Enter ContainerImageURI - ContainerImageURI is available from the output of the `bash build.sh` step. Keep default values for the remaining fields. SAM デプロイプロセスからの出力に注目してください。これらには、後続のステップで使用されるリソース名や ARN が含まれています。 ステップ 2: 独自のトレーニングデータを S3 バケットにアップロードする 独自のトレーニングデータは、前のステップで作成された専用の S3 バケットにアップロードされ、Amazon Bedrock Cohere Command Light モデルのファインチューニングに使用されます。トレーニングデータは、 JSON Line 形式で、1 行ごとに問題文と応答の 2 つの要素を持つ有効な JSON が含まれている必要があります。 HuggingFace の このパブリックデータセット を使用し、JSON Line 形式に変換しました。 次のコマンドを使用して、用意されたトレーニングデータファイルを S3 バケットにアップロードします。 TrainingDataBucket は sam deploy --guided から出力された値に置き換えてください。 your-region は SAM テンプレートを実行したときに指定したリージョンに更新してください。 aws s3 cp training-data.jsonl s3://{TrainingDataBucket}/training-data.jsonl --region {your-region} validation-data.json ファイルを sam deploy --guided から出力された ValidationDataBucket の値を指定して、以下のコマンドを使用して S3 バケットにアップロードしてください。 your-region は SAM テンプレートを実行したときに指定したリージョンに更新してください。 aws s3 cp validation-data.json s3://{ValidationDataBucket}/validation-data.json --region {your-region} reference-inference.json ファイルを、次のコマンドを使って S3 バケットにアップロードします。 ValidationDataBucket は sam deploy --guided から出力された値に置き換えてください。 your-region は SAM テンプレートを実行したときに指定したリージョンに更新してください。 aws s3 cp reference-inference.json s3://{ValidationDataBucket}/reference-inference.json --region {your-region} 送信者メールIDを確認するためのメールも受信されているはずです。メールに記載の手順に従ってメールIDを確認してください。 ステップ 3: ステップ関数ワークフローの実行とモニタリング Step Functions ステートマシンを開始し、直前のステップで S3 バケットにアップロードされたトレーニングデータに基づいて、Amazon Bedrock 上の Cohere Command Light モデルをファインチューニングします。また、ハイパーパラメータも渡します。必要に応じて変更してください。 次の AWS CLI コマンドを実行して、Step Functions ワークフローを開始します。 StateMachineCustomizeBedrockModelArn と TrainingDataBucket の値は、 sam deploy --guided から出力された値に置き換えてください。 UniqueModelName と UniqueJobName は各々一意の値に置き換えてください。ハイパーパラメータの値は選択したモデルに基づいて変更してください。 your-region はSAM テンプレートを実行したときに指定したリージョンに更新してください。 aws stepfunctions start-execution --state-machine-arn "{StateMachineCustomizeBedrockModelArn}" --input "{\"BaseModelIdentifier\": \"cohere.command-light-text-v14:7:4k\",\"CustomModelName\": \"{UniqueModelName}\",\"JobName\": \"{UniqueJobName}\", \"HyperParameters\": {\"evalPercentage\": \"20.0\", \"epochCount\": \"1\", \"batchSize\": \"8\", \"earlyStoppingPatience\": \"6\", \"earlyStoppingThreshold\": \"0.01\", \"learningRate\": \"0.00001\"},\"TrainingDataFileName\": \"training-data.jsonl\"}" --region {your-region} 出力例: { "executionArn": "arn:aws:states:{your-region}:123456789012:execution:{stack-name}-wcq9oavUCuDH:2827xxxx-xxxx-xxxx-xxxx-xxxx6e369948", "startDate": "2024-01-28T08:00:26.030000 + 05:30" } 基盤モデルのカスタマイズと評価には、完了するまでに 1 時間から 1.5 時間かかります。カスタマイズが完了したら、通知メールが届きます。 次のいずれかを実行します。 AWS Step Functions コンソール にサインインして、Step Functions ワークフローのステータスを確認します。ワークフローが正常に完了するのを待ちます。前のステップの出力から executionArn を置き換え、 your-region を更新してください。 aws stepfunctions describe-execution --execution-arn {executionArn} --query status --region {your-region} ステップ 4:ベース基盤モデルのトレーニング結果の確認 AWS Step Functions のワークフローが正常に完了すると、カスタマイズモデルの品質の結果がメールで送信されます。カスタマイズモデルがベースモデルよりも優れていない場合、プロビジョニング済みのリソースが削除されます。以下はサンプルのメールです。 推論レスポンスの品質が満足できない場合は、更新されたトレーニングデータまたはハイパーパラメータに基づいて、ベースモデルを再トレーニングする必要があります。 ModelInferenceBucket には、ベース基盤モデルとカスタマイズモデルの両方から生成された推論結果が格納されています。 ステップ 5: クリーンアップ PoC(概念実証)やデモンストレーションの後、コストを最適化し、セキュリティポスチャを強化するための重要なベストプラクティスは、プロビジョニングされたAWSリソースを適切に廃棄することです。この投稿の前半でデプロイしたインフラストラクチャコンポーネントを削除するには、次の手順を実行します。 カスタムモードのAmazon Bedrockプロビジョニングスループットを削除します。誤って削除されないように、正しい ProvisionedModelArn を指定してください。また、 your-region を使用するリージョンに更新してください。 aws bedrock delete-provisioned-model-throughput --provisioned-model-id {ProvisionedModelArn} --region {your-region} Amazon Bedrock カスタムモデルを削除します。意図しない削除を避けるために、正しい CustomModelName を指定し、 your-region を更新してください。 aws bedrock delete-custom-model --model-identifier {CustomModelName} --region {your-region} 次のコマンドを使用して、S3 バケット内のコンテンツを削除してください。誤ったバケット名を指定すると、データが失われる可能性があるため、正しいバケット名を指定していることを確認してください。 aws s3 rm s3://{TrainingDataBucket} --recursive --region {your-region} aws s3 rm s3://{CustomizationOutputBucket} --recursive --region {your-region} aws s3 rm s3://{ValidationDataBucket} --recursive --region {your-region} aws s3 rm s3://{ModelInferenceBucket} --recursive --region {your-region} AWS SAM を通じて AWS アカウントにデプロイされたリソースを削除するには、次のコマンドを実行してください: sam delete 結論 この投稿では、AWS Step Functions をオーケストレーションエンジンとして使用して、Amazon Bedrock モデルをカスタマイズするエンドツーエンドのワークフローを概説しました。自動ワークフローは、カスタマイズされたデータで基盤モデルを訓練し、ハイパーパラメータを調整します。次に、カスタマイズされたモデルの性能をベース基盤モデルと比較して、トレーニングの有効性を評価します。完了すると、ユーザーにはメールで学習結果が通知されます。 大規模言語モデルをカスタマイズするには、専門的な機械学習の知識とインフラストラクチャが必要です。Amazon Bedrock や Step Functions などの AWS サービスは、これらの複雑さを抽象化することで、企業が独自のデータとユースケースに集中できるようになります。カスタマイズと評価のための自動化されたワークフローを持つことで、お客様は運用負荷を軽減して、より迅速にニーズに合わせてモデルをカスタマイズできます。 参考文書 Amazon Bedrock ユーザーガイド AWS Step Functions ユーザーガイド Amazon Bedrock モデルのカスタマイズについての AWS ブログ 著者について Biswanath Mukherjee は、Amazon Web Services のシニアソリューションアーキテクトです。AWS の大規模な戦略的顧客に対し、AWS クラウドへのアプリケーションの移行とモダナイズのための技術的ガイダンスを提供しています。クラウドアーキテクチャと移行に関する豊富な経験を活かし、顧客と協力して、AWS のスケーラビリティ、信頼性、アジリティを活用したイノベーティブなソリューションを開発し、顧客のビジネスニーズを満たしています。その専門知識は、さまざまな業界やユースケースに及び、顧客が AWS クラウドの真のポテンシャルを引き出すことができるようサポートしています。 本ブログはソリューションアーキテクトの銭 敏娟が翻訳しました。原文は こちら です。

Amazon RDS Performance Insights は Amazon Relational Database Service (Amazon RDS) の強力な機能で、データベースのパフォーマンスに関するリアルタイムおよび過去のインサイトを提供します。パフォーマンスボトルネックのトラブルシューティング、遅いクエリの特定、システムの最適化など、どのような目的でも Performance Insights は役に立ちます。Performance Insights を使用するとデータベースの動作をより深く理解できます。Performance Insights は既存の Amazon RDS モニタリング機能を拡張したもので、データベースのパフォーマンスを示し、分析するのに役立ちます。 Performance Insights ダッシュボード では、RDS DB インスタンスの負荷をアプリケーション、データベース、待機イベント、SQL ステートメント、ホスト、またはユーザーごとに細分化して視覚化することができます。 この投稿では、最近リリースされた Performance Insights の新機能について説明します。 SQL ダイジェストと SQL 統計 Performance Insights for SQL Server によるクエリ実行プラン SQL ダイジェストと SQL 統計 これらの新機能について説明する前に、一般的な SQL ダイジェストについて説明しましょう。SQL ダイジェストは、構造的には似ていてもリテラル値が異なる可能性がある複数の実際のクエリを組み合わせたものです。ダイジェストは SQL クエリのバインド値を疑問符に置き換えます。たとえば、ダイジェストは SELECT * FROM emp WHERE lname=? というような場合があります。このダイジェストには次の子クエリが含まれる場合があります。 SELECT * FROM emp WHERE lname = 'Sanchez' ; SELECT * FROM emp WHERE lname = 'Olagappan' ; SELECT * FROM emp WHERE lname = 'Wu' ; SQL ダイジェスト内のリテラル SQL ステートメントを表示するには、クエリを選択し、プラス記号を選択して詳細を展開します。次の例では、選択されたクエリはダイジェストです。 ただし、SQL Server はオープンソースエンジンのようなダイジェストをサポートしていません。ダイジェストテキストは、どのような種類のクエリがデータベースのパフォーマンスに最も大きな影響を与えているかを理解するのに役立ちます。SQL Server では、各ダイジェストは特定の query_hash に関連付けられています。 クエリで計算された query_hash またはバイナリハッシュ値は、同様のロジックを持つクエリを識別するために使用されます。 query_hash を使用すると、リテラル値のみが異なるクエリのリソース使用量の合計を判断できます。 query_hash は、リテラル値に関係なく、クエリを指す計算値です。例を次に示します。 SQL Text : select col1 , 1 , col2 from table1 where col345465757e <> 456 ; DIGEST_TEXT: select col1 , ? , col2 from table1 where col345465757e <> ? SQL Amazon RDS for SQL Server は、上位の SQL クエリについて、ステートメントレベルとダイジェストレベルの両方で SQL 統計を収集します。詳細については、「 SQL Server の SQL 統計 」を参照してください。 クエリ実行プラン Performance Insights は、推定されたクエリ実行プランのみをキャプチャします。キャプチャされたプランには、すべてのプランノードと統計が含まれます。詳細については、「 Performance Insights ダッシュボードを使用した実行プランの分析 」を参照してください。 キャプチャされた実行プランは、次の 2 つの形式で表示できます。 表形式 – プランノードと統計情報をすばやく把握できる ダウンロード可能な XML 形式 – SQL Server Management Studio のようなツールを使用して詳細な調査を行う Performance Insights が収集する実行プランの詳細は、次のことに役立ちます。 上位の SQL クエリでどのプランが使用されているかを調べる 同じクエリで異なるプランを比較する クエリがいつ新しいプランに切り替わったかを調べる コストが最も高いプランの特定の演算子を絞り込む ソリューション概要 以下のセクションでは、Performance Insights ダッシュボードを使用して RDS DB インスタンスに接続し、データベースを準備して SQL Server 実行プランを分析する方法を示します。 前提条件 開始する前に、次の前提条件を完了していることを確認してください。 RDB DB インスタンスを作成します。 Performance Insights を有効にします 。 Performance Insights のアクセスポリシーを構成します 。 SQL Server Management Studio (SSMS) がインストールされた Amazon Elastic Compute Cloud (Amazon EC2) Windows インスタンスを用意します。 RDS DB インスタンスに接続し、データベースを準備する まず、サンプルデータベースとテーブルを作成します。以下のステップを完了します。 SSMS を開きます。 RDS for SQL Server データベースインスタンスに接続します。 「新しいクエリ」を開きます。 次のクエリを入力し、「実行」をクリックします。 -- Create database CREATE DATABASE testDB Go -- Create Customers table CREATE TABLE Customers ( CustomerID INT PRIMARY KEY , CustomerName NVARCHAR ( 100 ) ) ; -- Insert ten thousand rows into Customers table DECLARE @CustomerCounter INT = 1 ; WHILE @CustomerCounter <= 10000 BEGIN INSERT INTO Customers ( CustomerID , CustomerName ) VALUES ( @CustomerCounter , 'Customer' + CAST ( @CustomerCounter AS NVARCHAR ( 10 ) ) ) ; SET @CustomerCounter = @CustomerCounter + 1 ; END ; -- Create Products table CREATE TABLE Products ( ProductID INT PRIMARY KEY , ProductName NVARCHAR ( 100 ) , UnitPrice DECIMAL ( 10 , 2 ) ) ; -- Insert ten thousand rows into Products table DECLARE @ProductCounter INT = 1 ; WHILE @ProductCounter <= 10000 BEGIN INSERT INTO Products ( ProductID , ProductName , UnitPrice ) VALUES ( @ProductCounter , 'Product' + CAST ( @ProductCounter AS NVARCHAR ( 10 ) ) , RAND ( ) * 100 ) ; SET @ProductCounter = @ProductCounter + 1 ; END ; -- Create Orders table CREATE TABLE Orders ( OrderID INT PRIMARY KEY , CustomerID INT , OrderDate DATE ) ; -- Insert ten thousand rows into Orders table DECLARE @OrderCounter INT = 1 ; WHILE @OrderCounter <= 10000 BEGIN INSERT INTO Orders ( OrderID , CustomerID , OrderDate ) VALUES ( @OrderCounter , ( ABS ( CHECKSUM ( NEWID ( ) ) ) % 1000000 ) + 1 , DATEADD ( DAY , - ( @OrderCounter % 365 ) , GETDATE ( ) ) ) ; SET @OrderCounter = @OrderCounter + 1 ; END ; -- Create OrderDetails table CREATE TABLE OrderDetails ( OrderDetailID INT PRIMARY KEY , OrderID INT , ProductID INT , Quantity INT ) ; SQL 次のステートメントを使用して SHOWPLAN_XML を有効にします。 -- Display XML execution plan for a query SET SHOWPLAN_XML ON ; GO SQL デモで使用するサンプルクエリは次のとおりです。 Where 句を使用している QUERY 1 SELECT Orders . OrderID FROM Orders WHERE Orders . OrderDate BETWEEN '2023-01-01' AND '2023-12-31' SQL join を使用している QUERY 2 SELECT Orders . OrderID , Customers . CustomerName , SUM ( OrderDetails . Quantity * Products . UnitPrice ) AS TotalPrice FROM Orders JOIN Customers ON Orders . CustomerID = Customers . CustomerID JOIN OrderDetails ON Orders . OrderID = OrderDetails . OrderID JOIN Products ON OrderDetails . ProductID = Products . ProductID WHERE Orders . OrderDate BETWEEN '2023-01-01' AND '2023-12-31' GROUP BY Orders . OrderID , Customers . CustomerName HAVING SUM ( OrderDetails . Quantity * Products . UnitPrice ) > 1000 ; SQL Performance Insights ダッシュボードを利用した SQL Server のクエリ実行プラン分析 SQL Server のクエリ実行プランを分析するには、次の手順を実行します。 Amazon RDS コンソールのナビゲーションペインで、「Performance Insights」を選択します。 SQL Server DB インスタンスを選択します。 その DB インスタンスのパフォーマンスインサイトダッシュボードが表示されます。 [データベース負荷] セクションで、「分類方法」の横のドロップダウンメニューで「プラン」を選択します。 データベース負荷チャートには、上位の SQL ステートメントで使用されるプランと、それらのプランによってデータベースで発生した負荷が表示されます。プランのハッシュ値は、色分けされた四角形の右側に表示されます。各ハッシュ値はプランを一意に識別します。 歯車アイコンを選択し、[Total elapsed time/exec]、[Rows processed/sec]、[Plans count (unique)] など、関心のあるフィールドを選択します。 「トップSQL」セクションで、「SQL テキスト」タブを選択して SQL ステートメント全体を表示します。 「プラン」タブを選択して、クエリ実行プランを分析します。 この記事の例は、実行プランの比較を深く掘り下げることを意図したものではありません。むしろ、これらのプランを分析するための Performance Insights ダッシュボードの機能を紹介することを目的としています。私たちのアプローチは、基本的な機能を強調するために意図的に単純化しています。 結論 モニタリングは、Amazon RDS 上の SQL Server データベースの信頼性、可用性、パフォーマンスを維持する上で重要です。データベース管理者は、データベースエンジンがクエリをどのように処理するかを理解するために、常に SQL Server の統計とクエリ実行プランの分析に頼ってきました。Performance Insights ダッシュボードに SQL Server の統計情報と実行プランが表示されるため、データベース管理者は SQL Server のパフォーマンスを微調整して、データベース運用を最適化し、システム全体の効率を高めることができるようになりました。この投稿では、実行プランごとにデータベース負荷を分析し、特定のクエリのさまざまなプランを比較する方法を紹介しました。 Performance Insights を使い始めるには、「 Amazon RDS での Performance Insights を使用した DB 負荷のモニタリング 」を参照してください。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sudarshan Roy は、AWS のシニアデータベーススペシャリストクラウドソリューションアーキテクトです。お客様向けの大規模なデータベース移行とモダナイゼーションの取り組みをリードし、データベースのワークロードを AWS クラウドに移行しながら複雑な移行の課題を解決することに注力しています。 Sudhir Amin は、アマゾンウェブサービスのシニアソリューションアーキテクトです。ニューヨークを拠点にしてさまざまな業種のお客様にアーキテクチャの指導と技術支援を提供し、クラウドの採用を加速させています。彼はスヌーカー、ボクシングや UFC などの格闘技の大ファンで、野生生物保護区が豊富な国へ旅行をして世界で最も雄大な動物を間近で見ることが好きです。

特にオンプレミスのデータセンター環境から移行する場合、時間的制約のあるシナリオでは、 リフト & シフトまたはリホスト 移行アプローチを採用するのが現実的な選択肢となります。ただし、クラウドネイティブアーキテクチャの長期的なメリットを実現するには、選択した移行戦略が組織全体のクラウド導入戦略と一致していることを確認することが重要です。多くのアプリケーションでは、リフト & シフトと、 リプラットフォームやリファクタリング などの他の移行アプローチを組み合わせると、最適な結果が得られる場合があります。各ワークロード移行プロジェクトを慎重に評価し、アプリケーションと組織の要件と制約に基づいて最も適切な戦略を決定する必要があります。 組織では、インフラストラクチャ管理と運用上のオーバーヘッドの負担を軽減するために、SQL Server ワークロードを Amazon Relational Database Service (Amazon RDS) for SQL Server などのマネージドデータベースサービスに移行することがよくあります。Amazon RDS には、自動バックアップ、高可用性、スケーラビリティなどいくつかの利点があり、SQL Server ワークロードの管理の複雑さを大幅に軽減します。この記事では、SQL Server の移行アセスメント段階で遭遇する一般的な課題の概要を説明し、このプロセスを迅速に進めるための効果的なソリューションを提案します。特に、Amazon RDS for SQL Server や Amazon RDS Custom for SQL Server などのマネージドプラットフォームに移行する場合に役立ちます。 移行アセスメントの課題 SQL Server の移行を評価する手作業と時間のかかるプロセスが課題の 1 つです。Amazon RDS と互換性のあるすべての機能を特定することが不可欠です。Amazon RDS では、 サポートされていない機能 と限定的にサポートされている機能が明記されています。アセスメント段階では、お客様の環境で使用されている SQL Server 機能の包括的なインベントリが不可欠です。サポートされていない機能やサポートが限定されている機能を認識することは、データベース管理者にとってもシステム管理者にとっても重要なステップです。 もう 1 つの課題は、適切な Amazon RDS のコンピューティングタイプとストレージタイプの選択です。Amazon RDS には、データベースのパフォーマンスや容量のさまざまな要件に対応できるようにさまざまな インスタンスタイプ と ストレージオプション が用意されています。適切な RDS DB インスタンスを選択するには、オンプレミスの SQL Server インスタンスの CPU とメモリのスペックをあわさせる必要があります。Amazon RDS が提供する多様な選択肢には柔軟性がありますが、効果的なコスト管理には SQL Server ワークロードの適切なサイジングが不可欠です。このプロセスでは、パフォーマンス要件を正確に判断するために、現在のワークロード、特にリソースのピーク使用率と平均使用率を分析する必要があります。 RDSTools RDSTools は、SQL Server を AWS に移行する際のサイジングとコストの最適化を目的として設計された PowerShell ベースのプランニングツールスイートです。RDSTools では、CPU やメモリの使用状況などの SQL Server 環境の詳細なインベントリを作成し、特に Amazon RDS for SQL Server の場合の互換性とサイジングのアセスメントを行います。 このソリューションは、以下のタスクを自動化することでアセスメントと計画を迅速化します。 仮想プロセッサ、メモリ、ストレージの仕様など、詳細な SQL Server インベントリを取得。 Amazon RDS 互換性アセスメントを実施し、サポートされていない機能をレポート。 Amazon RDS、RDS Custom、 Amazon Elastic Compute Cloud (Amazon EC2) など、アセスメントされたリソースに基づいて適切なプラットフォームを推奨。 SQL Server の使用状況メトリックスに基づいて、適切な RDS DB インスタンスタイプを提案。 Amazon ElastiCache の推奨事項について、個々のデータベースの読み取り / 書き込みを分析。Amazon Elasticache はフルマネージドのインメモリデータストアで、頻繁にアクセスされるデータをキャッシュすることでウェブアプリケーションのパフォーマンスを大幅に向上させることができます。Elasticache は、プライマリデータベースから読み書き操作をメモリ内キャッシュにオフロードすることで、データベースへの負荷を軽減し、応答時間を改善するのに役立ちます。 RDSTools では、SQL Server 2008 以降の SQL Server のすべてのバージョンとエディションをサポートしています。 このツールには SQL Server システム管理者のログイン認証情報が必要であり、軽量で運用環境への影響を最小限に抑えるように設計されていることに注意してください。 このツールは、RDS Discovery と SQLServerAssessment という 2 つの主要コンポーネントで構成されています。 RDS Discovery RDS Discovery Tool は、オンプレミスの SQL Server または EC2 インスタンス群をスキャンする機能を提供する軽量ツールです。20 を超える機能を自動的にアセスメントし、有効になっている機能と Amazon RDS との互換性を確認し、包括的なレポートを作成します。これにより、Amazon RDS で有効になっている機能のサポート性が検証され、Amazon RDS、RDS Custom、または Amazon EC2 への移行に関する推奨事項が記載されたレポートが生成されます。 RDS Discovery を使用して初期アセスメントを実行できます。 SQL Server のバージョン、エディション、機能、および FCI や Always On 可用性グループなどの高可用性構成を含む詳細な SQL Server インベントリを収集します。 Amazon RDS との互換性をアセスメントします。 使用している SQL Server エンタープライズエディションの機能を特定します。 SQLServerAssessment SQLServerAssessment Tool (SSAT) を使用すると、オンプレミスの SQL Server ワークロードの評価を効率化して、Amazon RDS で適切なサイジングを行うために必要なシステム使用率を特定できます。SSAT は、指定された期間における CPU、メモリ、IOPS、スループットの使用量を効率的に測定し、AWS 上で 適切なサイズを選択するための提案を行います。この汎用性の高いツールは、単一の SQL Server インスタンスと複数の SQL Server インスタンスの両方をアセスメントできます。 SSAT を使い始める前に、ツールが SQL Server とどのように連携するかをよく理解しておくことが重要です。その主な目的は、Amazon RDS for SQL Server への円滑な移行に必要なシステム使用率を測定することです。SSAT は、CPU 使用率、メモリ使用量、IOPS、スループットなど、さまざまなパフォーマンスメトリクスをすべて所定の期間内に収集します。その後、このデータを使用して Amazon RDS for SQL Server インスタンスに合わせた推奨事項が策定されます。 これを実現するために、SSAT は動的管理ビュー（DMV）を採用しています。これは、特にデータベースレベルで幅広いメトリクスをキャプチャするための堅牢な機能です。このアプローチにより、焦点を絞った正確なアセスメントが可能になり、サーバーレベルでデータを収集する際に発生しうるノイズを最小限に抑えることができます。 次の表は、ツールがメトリクスを収集するために使用する DMV の詳細な説明を示しています。 Metrics DMV Columns Comments/Notes CPU sys.dm_os_ring_buffers SQLServerCPUUtilization SystemIdLe OtherProCpuUT SQL Server CPU 使用率 % System アイドル % CPU 以外のプロセス % Memory sys.dm_os_performance_counters sys.dm_os_sys_memory sys.dm_os_sys_info PLE Committed_KB committed_target_kb total_physical_memory_kb available_physical_memory_kb ページの平均寿命 SQL Server メモリマネージャー内でコミットされたメモリ SQL Server のメモリマネージャーが消費できるメモリ オペレーティングシステムで使用可能な物理メモリの総容量 (KB) 現在使用可能な物理メモリのサイズ (KB) Disk IOPS dmv sys.dm_io_virtual_file_stats Read Write Bread Bwrite 読み込みと書き込みの IOPS 読み込みと書き込みの バイト数 パフォーマンス使用率メトリクス アセスメントツールは、初回実行時にパフォーマンスメトリクスの取得専用のエージェントジョブを作成します。このジョブは、MSDB のステージングテーブルに一時的に格納されます。データ収集フェーズが完了すると、ツールはステージングテーブルから CSV ファイルにデータを出力します。このプロセスの主な設定は収集時間で、デフォルトは 60 分です。ただし、収集したメトリクスをより詳細に分析するには、実行時間を 4 ～ 7 日に延長することをおすすめします。このツールは、エージェントジョブを 1 分間隔で開始し、指定された収集時間に達するまでこの頻度を維持するように設計されています。 この収集プロセス中に、収集されたメトリックを格納する次の 5 つのテーブルが MSDB データベースに作成されます。 Sql_CollectionStatus – このテーブルには、開始時刻、終了時刻、ステータスなど、収集ジョブに関する情報が保持されます。 Sql_CPUCollection – このテーブルでは、SQL Server の CPU 使用率、システムアイドル状態、その他のプロセス使用率という 3 つの重要なメトリクスが収集されます。3 つのメトリクスはすべてパーセンテージとして取得されます。 Sql_MemCollection – このテーブルには、SQL Server のメモリ使用量、SQL の最大メモリターゲット、OS の合計メモリ、OS の使用可能なメモリ、ページの平均寿命など、さまざまなメモリ関連のメトリクスが格納されます。 Sql_DBIO – このテーブルには、各収集時間におけるユーザーデータベースの IOPS とスループットのメトリクス、特に差分の変化が記録されます。 Sql_DBIOTotal – ここでは、ツールは読み取り操作と書き込み操作の両方を含むユーザーデータベース I/O の合計をキャプチャします。 このデータを専用のテーブルにまとめることで、ツールは効率的な保存と重要なパフォーマンスメトリクスへの直接アクセスを確保し、SQL Server 環境を効果的に分析および最適化できるようにします。 エージェントジョブのライフサイクルは、さまざまなスイッチを使用するツールによって管理されます。これらのスイッチの詳細については、 GitHub リポジトリ を参照してください。 アセスメント後のステップ アセスメントで検討できる実行可能なステップは次のとおりです。 ベストプラクティスに従う – SQL Server のベストプラクティスに従っていることを確認してください。詳細については、「 SQL Server を使用するためのベストプラクティス 」を参照してください。 適切なサイジングによるコストの最適化 – リソースの使用率を評価して、SQL Server のデプロイがワークロードに適したサイズになっていることを確認します。詳細については、「 適切なサイジングのヒント 」を参照してください。 ElastiCache を使用してパフォーマンスを最適化 – ElastiCache でキャッシュ戦略を実装してアプリケーションのパフォーマンスを向上させましょう。詳細については、「 ASP.NET コアウェブアプリケーションの分散キャッシュに AWS サービスを利用する 」を参照してください。 統合によるコストの最適化 – さらにオーバーヘッドを削減し、リソース利用率を向上させるために可能な場合は SQL Server インスタンスとデータベースを 1 つの RDS DB インスタンスに統合することを検討することもできます。 結論 この投稿では、SQL Server の移行アセスメント段階で遭遇する一般的な課題を取り上げ、このプロセスを合理化および迅速化するための効果的なソリューションを提供しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Bachar Rifai は、AWS のデータベースを専門とするシニアパートナーソリューションアーキテクトです。Bachar は AWS パートナーと協力して、データベースプロジェクトに関する専門的なアドバイスや技術サポートを提供しています。AWS テクノロジーを活用したソリューションの有効性と価値を高めることに注力しています。 Sudhir Amin は、アマゾンウェブサービスのシニアソリューションアーキテクトです。ニューヨークを拠点にしてさまざまな業種のお客様にアーキテクチャの指導と技術支援を提供し、クラウドの採用を加速させています。彼はスヌーカー、ボクシングや UFC などの格闘技の大ファンで、野生生物保護区が豊富な国へ旅行をして世界で最も雄大な動物を間近で見ることが好きです。 Sudarshan Roy は、AWS のシニアデータベーススペシャリストクラウドソリューションアーキテクトです。お客様向けの大規模なデータベース移行とモダナイゼーションの取り組みをリードし、データベースのワークロードを AWS クラウドに移行しながら複雑な移行の課題を解決することに注力しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 AWS Summit New Yorkが開催され、生成AIに関係するサービスアップデートだけでも19件の新機能・新サービスが発表されました。ひととおりピックアップしたのですが、「さすがに読みづらいかな……」と思い、今回は3つのカテゴリに整理してお届けします。AWSではみなさんが実現したいテーマや価値を、現実のものにするための方法論として様々なサービス群を提供していますが、それらを3種類に分類して説明しています。今回の週刊生成AI with AWSでは、それに準拠してみようと思います。（ちなみに、カテゴリから外れるけれども生成AIで活用できるサービスもありますので、それは「その他」にしたいと思います） それでは、7 月 8 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: ルームクリップ株式会社様、軽量基盤モデルによる画像内の家具の検出を実現 ルームクリップ株式会社 様は、住生活の領域に特化したソーシャルプラットフォーム「 RoomClip 」を運営していらっしゃいます。家具の検出システムには2つの要件があり、細かな運用に関するドメイン知識を反映すること、追加のニーズに柔軟に対応できることが求められていました。その解決策として軽量な基盤モデルを利用して、自然言語で指定した家具を検出させるアプローチを採用することとし、最終的に低コストかつ充分な処理能力を実現することに成功しました。導入前と比較して商品ページの閲覧数が2倍に増加しているというビジネス効果もでているそうです。注目すべきはAWS Lambdaを処理基盤として利用している点です。Lambdaで実行可能な軽量なモデルによる課題解決を行うことで、コストと運用負荷を大きく削減できたとのことで、目的に応じて適切なモデルを上手に使う好例といえます。 サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション AWS App Studioのプレビューを開始 生成AIを活用し、自然言語によってエンタープライズグレードのアプリケーションを作成できるサービス、AWS App Studioのプレビューを開始しました。AWS App Studioでは、複数のページから構成されるユーザインタフェースやデータモデル、ビジネスロジックを含む複雑なアプリケーションを開発できます。Amazon AuroraやAmazon DynamoDB, Amazon S3などのAWSサービスや、Salesforceなどの外部サービスをデータソースとして利用したり、APIコネクタを介してサードパーティサービスと連携することも可能です。ユーザはソースコードやそれを実行するインフラストラクチャを意識する必要はなく、作って使うだけ、というのもポイントです。 Amazon Q Businessでユーザ毎にパーソナライズされた応答が可能に Amazon Q Buisnessがユーザプロファイルに基づいた応答を返せるようになりました。AWS IAM Identity Center経由で連携するIDプロバイダーに蓄積されたユーザの物理的な所在地、所属部門、役割などといった情報を利用することによって、生成AIの応答をカスタマイズすることで、よりユーザが求める答えと関連性の高い回答ができるようになります。 Amazon Q BusinessでPDFファイルのテキストや画像の情報に基づく応答が可能に 企業や団体が保有するデータには、たくさんのPDF形式のファイルが含まれることがあります。今回Amazon Q Businessが、PDFファイルに含まれたテキストや、画像の情報に基づいた回答を返すことができるようになりました。これまではOCRでテキストを抽出してからAmazon Qに取り込む必要がありましたが、今後はPDFファイルをそのまま取り込めば自動的に情報検索が可能になります。 Amazon Q Appsが一般利用開始に Amazon Q Appsは、Amazon Q Businessの一部として提供される機能で、Amazon Q Buisnessとの会話を通じて得られた結果や、実現したい内容を自然言語で説明することによって、アプリを簡単に構築する機能です。4月にプレビューを開始したAmazon Q Appsですが、今回一般利用開始になりました。Amazon Q Businessからユーザ権限やアクセス制御等を継承しますので、安全なデータ共有やデータ活用が可能です。 Amazon Q Developerでコード推奨機能のカスタマイズと、IDE内でのチャット機能のプレビューを開始 Amazon Q Developerでは開発者の方がプログラムコードを記述する際に推奨事項を提示します。今回、新たに推奨事項の内容を組織のリポジトリに接続することで組織内のAPIやライブラリ、クラス、メソッド等を意識した推奨事項を出力できるようになりました。また、統合開発環境(IDE)の中でAmazon Qに質問できるチャット機能が提供され、組織のコードに基づいて特定の関数やライブラリが利用されている場所や呼び出され方、その機能等について質問し回答を得ることができるようになりました。組織として開発を行っている場合、一般的な推奨事項だけではなく組織ごとのルールや共通機能などを考慮する必要があり、それを考慮した推奨事項を提示できるようになったというのがポイントです。 Amazon Q DeveloperがAmazon SageMaker Studioで利用可能に 機械学習に関する開発のための統合開発環境がAmazon SageMaker Studioです。今回、SageMaker StudioからAmazon Q Developerをご利用頂けるようになりました。SageMakerの機能への質問はもちろん、コード生成、トラブルシューティングなどを支援してくれるので、作業の効率化が期待できます。 Amazon Q DeveloperのAWSリソースに関する対話機能が一般利用開始に Amazon Q Developerで、AWSアカウント内で保有するリソースに関するチャットによる問い合わせ機能が一般利用開始になりました。例えば「S3バケットを一覧表示」「インスタンスidがxxxについて関連するリソースはあるか？」といった質問を投げると、実情に応じて回答を返してくれます。CLIやAPIでも同様の作業は実現できますが、自然言語でやりたい事を伝えるだけでOKになるのは便利ですね。(Amazon Q Developerは日本語のやりとりが可能な場合もありますが、正式にサポートされている言語は英語になります。その点はご注意ください) Amazon Q Developerのチャット機能でIDEに関するコンテキスト認識が可能に Amazon Q Developerのチャット機能において、ユーザがIDE(統合開発環境)で開いているプロジェクトのコードに関する質問に対応できるようになりました。これまでは今現在開いているファイルに関する質問にのみ対応していましたが、新たに全てのコードファイルやプロジェクト構造などをふまえて、包括的な情報を応答します。 PartyRockのプレイリストページ機能を発表 PartyRockは生成AIを組み込んだアプリケーションを誰でも簡単に作成し、共有できるサービスです。今回新たにPartyRockで利用できるプレイリストページ機能が発表されました。PartyRockで作ったアプリをキュレーションして、お気に入りのアプリを集めたショウケースとしてご利用頂けます。 サービスアップデート – 生成AIを組み込んだアプリ開発のためのツール Amazon BedrockにおけるAnthropic Claude 3 Haikuのファインチューニングがプレビュー可能に Amazon Bedrockは、基盤モデルからの応答を用途に応じてカスタマイズする様々な機能を提供しています。その手法のひとつに少数の教師ありデータで追加学習を行うファインチューニングが利用できます。今回、新たにAnthropic Claude 3 Haikuについて、Amazon Bedrockを解してファインチューニングを実行できるようになりました。人気のあるClaude 3についても、応答カスタマイズの自由度が広がります。 Amazon Bedrockのプロンプトマネジメント機能とプロンプトフロー機能のプレビューを開始 生成AIを組み込んだアプリケーションでは、プロンプトの作成や管理が重要なテーマになります。今回発表された プロンプトマネジメント機能 では、プロンプトの作成・評価・バージョン管理・共有を可能にする仕組みで、登録されたプロンプトはAPIで呼び出すことが可能です。また、 プロンプトフロー機能 ではGUIによってプロンプトの呼び出し、Knowledge Baseへの問い合わせ、Lambda関数の呼び出しなどのワークフローをデザインすることが可能です。詳細については ブログ記事 をご覧ください。 Knowledge Bases for Amazon BedrockでWebデータソースと外部データソースへの接続機能のプレビューを開始 Knowledge Bases for Amazon BedrockがWebデータソースに対応し、Webページの情報を蓄積し生成AIの応答に利用できるようになりました。また、外部のデータソースとしてAtlassian Confluence, Microsoft SharePoint, Salesforceに接続するためのデータコネクタが利用できるようになり、これらに蓄えられた情報を検索拡張生成(RAG)に利用することが容易になりました。 Knowledge Bases for Amazon Bedrockが高度な検索拡張生成(RAG)機能に対応 Knowledge Bases for Amazon Bedrockで検索拡張生成(RAG)を高度化する2つの機能が利用できるようになりました。ひとつめの機能は、カスタムチャンキングです。RAGでは長いドキュメントをチャンクと呼ばれる小さいブロックに分割し処理しますが、Lambda関数で記述されたカスタムのチャンク化アルゴリズムを適用できるようになりました。LangChainやLlamaIndexなどのコンポーネントを利用することも可能です。ふたつめの機能はスマートパースです。Amazon Bedrockで稼働する基盤モデルを活用し、取り込み対象のドキュメントに含まれる表形式の情報をはじめとする複雑なデータを解析・抽出することが可能です。いずれの機能も、精度向上につながりうるもので、RAGを実装したアプリケーションがよりユーザの期待に添った応答を返すようにするために活用いただけます。 Agents for Amazon Bedrockでユーザとの対話におけるメモリ保持機能のプレビューを開始 Agents for Amazon Bedrockが、複数回にわたるユーザとの対話を必要とするユースケースについて、過去のやりとりを記憶しそれに基づいた応答を返すことができるようになりました。例えば、航空券の予約を処理するアプリケーションにおいて、過去のユーザとのやりとりからユーザの好みを記憶し、次回の対応時にその好みに沿った提案を行うことができるようになります。ユーザ毎にパーソナライズされた対応が可能になることで、ユーザ体験のさらなる向上が期待できます。 Agents for Amazon Bedrockでコード解釈(code interpretation)機能のプレビューを開始 Agents for Amazon Bedrockでコード解釈という新機能が発表されました。この機能を利用すると、生成AIアプリケーションが安全なサンドボックス内でコードを動的に生成して、実行できます。これによって、データ分析や可視化、最適解の探索など複雑なタスクにも対応できるようになります。例えば基盤モデル自体が対応していないフォーマットやデータ型のファイルを扱ったり、ユーザにとってわかりやすいグラフを生成させる、といった高度な処理を実現可能です。 Guardrails for Amazon Bedrockによる保護機能の強化を発表 Guardrails for Amazon Bedrockで2つの新機能が発表されました。ひとつめはContextual grounding checksで、対話型アプリケーションや検索拡張生成(RAG)で生成された応答をデータソースと照らし合わせることで正しいかどうかを検証し、ハルシネーション(幻覚)のリスクを軽減することに利用できるものです。ふたつめはApplyGuardrail APIです。GuardrailsはAmazon Bedrockで稼働するモデルへの問い合わせと応答をチェックするものでしたが、ApplyGuardrail APIを利用するとBedrock以外で稼働するモデルを利用しているアプリケーションでも、APIを呼び出すことでGuardrailsによるチェックを適用できます。これによって、事実上すべての生成AIアプリケーションにGuardrailsによる追加の安全機構を導入できるようになります。詳細については ブログ記事 をご覧ください。 サービスアップデート – 生成AIを支える基盤モデルのトレーニングと推論のためのインフラストラクチャー　 Amazon SageMakerで生成AIの推論ワークロードの最適化が可能に Amazon SageMakerでLlama 3, Mistral, Mixtralなどの生成AIモデルの推論ワークロードを最適化することで、同じリソースで最大2倍のスループットを発揮できるようになります。これはつまり、最大50%のコストを削減できると言うことを意味します。詳細については ブログ記事 をご覧ください。 Flash AttentionをサポートしたAWS Neuron 2.19をリリース AWSがAI/MLワークロードに向けて開発した専用設計のアクセラレータがAWS InferentiaとTrainiumです。AWS Neuronはこれらを利用するためのSDKで、PyTorchなど一般的なMLフレームワークと統合されています。今回、AWS Neuron 2.19がリリースされ、Flash Attentionという手法がサポートされました。より長いシーケンス長によるトレーニングと推論が実行可能になるとともに、Llama 3の推論に対応するなど機能拡張が多数含まれています。詳細については リリースノート をぜひご覧ください。 サービスアップデート – その他の関連サービス Amazon MemoryDBのベクトル検索機能が一般利用開始に オープンソースのRedisと互換性をもつインメモリデータベースのサービス、Amazon MemoryDBのベクトル検索機能が一般利用開始になりました。Amazon MemoryDBのベクトル検索機能は1桁ミリ秒のレイテンシで数百万のベクトルデータに対する更新・問い合わせが可能で、生成AIのアプリケーションで良く利用されるベクトル埋め込み形式(Embeddings)データを扱うユースケースに対応できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさんこんにちは。シニアソリューションアーキテクトの堀内です。私は、日頃 e コマース(以下 EC ) 業界の企業様を支援しております。 本ブログでは以下 2回に分けて、EC業界における生成AI活用ユースケースについて解説をしています。 その 1：EC 業界における課題と生成 AI ユースケースによる解決案の整理 その 2：ユースケースの実装例として AWS Summit Japan 2024 で展示した Amazon Bedrock デモの解説 今回は前回ご紹介した EC 業界における代表的な生成 AI ユースケースについて、Amazon Bedrock を利用した具体的な実装例として AWS Summit Japan 2024 で展示したデモの解説を行います。 代表的な生成 AI ユースケースが解決する業界課題背景に興味のある方は、以下その 2 のブログリンクをご覧ください。 https://aws.amazon.com/jp/blogs/news/aws-summit-2024-retail-cpg-ec-genai-usecases-and-solutions/ AWS Summit Japan 2024 EXPO 流通小売消費財ブースでデモ展示したサンプル実装 前回 ご紹介したユースケースについて、お客様実装の加速していただくために、Amazon Bedrock を利用したユースケース実装をソリューションアーキテクトにて作成し、AWS Summit Japan 2024 のEXPO 流通小売消費財ブースにてデモ展示を実施しました。 結果として多くの方に足を止めていただき、非常に関心が高い事項であると実感しました。 図2 AWS Summit Japan 2024 流通小売消費財ブースの様子 展示したデモは、上述した 4 つのユースケースを Amazon Bedrock で提供される多様なモデルを利用したシンプルな参照実装です。 画面上で 4 つのユースケースを切り替えて、生成 AI によるユースケースを体感することが可能です。 ※こちらのデモ実装については現在公開を予定して準備をしています。公開までお待ちいただければ幸いです。 図3 Amazon Bedrock による EC 業界 ユースケースデモ アーキテクチャ このデモのアーキテクチャは非常にシンプルで、Amazon ECS 上に Steamlit で実装された簡易的な Web アプリケーションがデプロイされており、HTTP/S にてアクセスが可能です。 Steamlit 上の Python スクリプトにより、Amazon Bedrock の API を呼び出し、各種生成 AI のプロンプト実行と結果の取得を行います。 モデルは、画像生成には Amazon Titan Image Generator G1 、テキスト処理の LLM には Anthropic Claude 3 Haiku 、検索時のベクトル化（Embedding）には、 Amazon Titan Multimodal Embeddings G1 を Amazon Bedrock の API から利用しています。 図4 Amazon Bedrock による EC ユースケースデモ 各機能の実装解説 1. 製品デザイン案生成 新たな製品のデザインをする際のネタとなる商品画像と、デザイン案のイメージをプロンプトとして渡すことで、製品デザイン案を複数生成する実装です。 以下の例では白いスニーカーを元画像として、「カラフルな革靴、白い紐、ハートロゴ」というデザイン案のイメージを渡すことでデザイン案を複数生成させています。 図5 製品デザイン案生成のデモ画面（左がインプット、右がアウトプット） 利用モデル ： Amazon Titan Image Generator G1 仕組み マスク画像の自動生成 Titan Image Generator の inpaint によって投稿された画像の一部領域のみを再生成します。 inpaint 機能では maskPrompt でプロンプトとして修正する領域を指示することも可能ですが、輪郭を正確にマスクすることは難しいため、 rembg という Python ライブラリを使用してマスク画像（0/1表現の白黒画像）を生成し、商品部分である白い部分を再生成するように2値変換し Titan Image Generator にパラメーターとしてリクエストします。 日本語プロンプトへの対応 プロンプトを Amazon Bedrock に渡す際に Amazon Translate を利用して英訳しています。そのため、日本語プロンプトを入力しても問題なく動作します。 画像生成 Amazon Bedrock の Titan Image Generator モデルを使用して、ユーザーが入力したプロンプトに基づいて画像を編集 − Inpaint を利用することで、マスク部分以外の画像生成を行います 2. 商品説明文生成 商品画像、商品名、商品の特徴（自由入力で素材や季節、生地の厚さ等を入力）を元にその商品の分析を行い、商品説明文に含めたいトピックとして指定した項目にしたがい商品説明文を生成する実装です。 合わせて、商品カテゴリやインスタグラムに対する投稿原稿も生成します。 図6 商品説明文生成のデモ画面（左がインプット、右がアウトプット） 利用モデル ： Anthropic Claude 3 Sonnet / Haiku （切り替え可能） 仕組み 商品画像、商品名、商品の特徴（自由入力で素材や季節、生地の厚さ等を入力）をインプットにその商品の分析を Claude3 で実施するプロンプトを実行しています <your role>あなたは、Eコマースにおける売場づくりのプロフェッショナルです。</your role> <instruction> 新商品 {focus_item}の販売促進のために、Eコマースサイトでユーザーが思わず購入したくなるような魅力的な商品説明を考えてください。 あなたが読み込んだ画像は{focus_item}の写真です。 {focus_item}の色や種類を分析し、この商品を具体的に説明してください。商品の特徴が feature に記載されます。 説明文の提案は step に則って作成してください。 </instruction> <step> ステップ1: 商品の基本情報を確認する ステップ2: ターゲット層を設定する ステップ3: ターゲット層に合わせた言葉遣いやトーンを決める ステップ4: 概要を書く ステップ5: 埋めるべき各項目を書く ステップ6: 全体を通して推敲する </step> <feature> {feature} </feature> <topic> {topic} </topic> <constraint> アウトプットは topic に記載された項目に沿って記載してください。 最後に推奨ターゲット層とそれに合わせた販売チャネルについて提案してください。 なお、XMLタグは出力しないでください。 </constraint> ここでは以下複数の Claude に関するプロンプトテクニックを利用しています Claudeに役割を与える ：E コマースにおける売場づくりのプロフェッショナル という役割を与えています XMLタグを使用する ：UI により与えられる素材等の情報を タグ内に配置することで構造化します Chain of Thought(CoT) ：商品説明文に含まれる要素を分解可能であれば、思考ステップとして定義することでより具体的な文面生成が可能です ※詳しくは こちら の Anthropic 公式プロンプトエンジニアリングガイドを参照ください。 3. 商品背景画像生成 元商品画像をアップロードしイメージを指示することで、商品画像や広告画像を用意する際の背景生成案を複数生成する実装です。 以下の例ではワインボトルを元画像として、以下のようなイメージを渡すことで背景生成案を複数生成させています。 プロのカメラマンが撮影した商品画像、大理石のテーブルの上に、たくさんの果物が置かれている、背景は少しボケている 図7 商品背景画像生成のデモ画面（左がインプット、右がアウトプット） 利用モデル ： Amazon Titan Image Generator G1 仕組み マスク画像の自動生成 Titan Image Generator の inpaint によって投稿された画像の一部領域のみを再生成します。 inpainnt 機能では maskPrompt でプロンプトとして修正する領域指示も可能ですが、輪郭を正確にマスクすることは難しいため、 rembg という Python ライブラリを使用してマスク画像（0/1表現の白黒画像）を生成し、商品部分である白い部分を再生成するように2値変換し Titan Image Generator にパラメーターとしてリクエストします。 ※「1. 製品デザイン案生成」と同様の実装ですが、マスク画像を2値化する際に、背景か商品かどちらを 0 にするかのみが異なります。 日本語プロンプトへの対応 プロンプトを Amazon Bedrock に渡す際に Amazon Translate を利用して英訳しています。そのため、日本語プロンプトを入力しても問題なく動作します。 画像生成 Amazon Bedrock の Titan Image Generator モデルを使用して、ユーザーが入力したプロンプトに基づいて画像を編集 − Inpaint を利用することで、マスク部分以外の画像生成を行います 4. 商品検索/比較アシスタント 商品説明文や商品画像をベクトル DB にベクトルとして格納し、商品検索時に入力したテキストや画像と意味的に近いものを取得できる、マルチモーダル検索/セマンティック検索の実装です。 加えて、商品検索結果について、検索者のペルソナに合わせて説明文をパーソナライズして生成します。 図8 商品検索/比較アシスタント（左がインプット、右がアウトプット） ※「健康でヘルシーなご飯」に意味合いの近い、和食やそばが検索結果上位に来ており、セマンティックサーチができていることがわかります 利用モデル ： Anthropic Claude 3 Haiku , Amazon Titan Multimodal Embeddings G1 仕組み 事前データ投入 商品説明文、商品画像についてAmazon Titan Multimodal Embeddings G1 モデルによりベクトルが計算され、ベクトル DB である FAISS に格納されます 商品検索 検索時に検索ワードや投稿画像をAmazon Titan Multimodal Embeddings G1でベクトル化し、あらかじめ格納されている商品のベクトルと比較した際のコサイン類似度をもとに、類似度の降順に並べられた商品一覧をFAISSから取得します 商品一覧が表示される際には、検索窓に入力されたテキストと検索者のペルソナ（年齢や性別、趣味等）情報を考慮して Amazon Bedrock Claude 3 Haiku がユーザへのメッセージを生成、表示します 商品比較 検索窓に入力されたテキストと検索者のペルソナ（年齢や性別、趣味等）の情報を考慮して Amazon Bedrock Claude 3 Sonnet が商品一覧トップの商品と他の商品との比較説明を生成、表示します 図9 商品検索/比較アシスタントの処理の流れ 今すぐ生成 AI の自社適用を始めましょう 本ブログでは AWS が日頃支援活動する中で得られたインサイトから、 EC における生成 AI ユースケースを整理し、それらユースケースの実装例として AWS Summit Japan 2024 で展示したデモの解説を行いました。 これらのユースケースは、御社の課題解決に役立つ可能性があります。 ユースケースの中から御社に適したものを特定し、明日からでも生成 AI の活用を始めることができます。 AWS は、本ブログでご紹介した、サービス / Workshop / デモ を含め、ユースケース特定から実装サポートまで、一貫したサービスやご支援を提供しています。 生成 AI は、EC ビジネスに大きな変革をもたらす可能性を秘めています。 その恩恵を御社でも享受するため、今すぐ一歩を踏み出しましょう。 このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWS担当営業もしくは こちらの窓口 までご連絡頂ければと思います。 AWS のエキスパートチームが、全力でサポートいたします。 ブログ著者とデモ作者 本ブログ著者： 堀内 保大 (Yasuhiro Horiuchi) / @ka_shino_ki アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト Web系の特にEコマース関連のお客様をビジネス起点から技術面まで横断的に支援しています。 好きなサービスは、AWS Fargate でコンテナに関連したサービスに興味があります。趣味は旅行とスノーボードです。 また、本ブログにて紹介したデモは AWS Japan のソリューションアーキテクト 堀内 保大、中島 佑樹、小林 大樹、長谷川 大、長友 健人 が開発しました。

みなさんこんにちは。シニアソリューションアーキテクトの堀内です。私は、日頃 e コマース(以下 EC ) 業界の企業様を支援しております。 EC におけるトレンドについてよくお客様とディスカッションをしますが、2024 年は生成 AI の関連の話題が多くトレンドになっています。 NRF2024 や re:Invent 2 023 等グローバルの動きを見ると EC 業界で具体的な業務改善や顧客体験向上として生成 AI の活用が始まっており、日本でも多くの企業様が興味を持ち始めています。 AWS では本業界におけるユースケースの整理とその実装を支援しております。 その一環として AWS Summit Japan 2024 のブースでは、活動を通して得られた代表的なユースケースに対して、Amazon Bedrock を利用したサンプル実装のデモを展示し、多くの方に足を止めていただきました。 本ブログでは以下 2回に分けて、EC業界における生成AI活用ユースケースについて解説をしていきます。 その 1：EC 業界における課題と生成 AI ユースケースによる解決案の整理 その 2：ユースケースの実装例として AWS Summit Japan 2024 で展示した Amazon Bedrock デモの解説 具体的な Amazon Bedrock による実装デモの解説に興味がある方は、以下その 2 のブログリンクを御覧ください。 https://aws.amazon.com/jp/blogs/news/aws-summit-2024-retail-cpg-ec-genai-bedrock-demo-architecture/ EC 業界における課題と生成 AI による解決 国内外の取り組みを整理すると、生成 AI を利用して解決すべき課題の方向性は大きく2通りです。 A. 差別化に繋がらない労働の削減 B. 顧客体験のパーソナライズ これら 2 つの方向性について、実際の EC 業界の業務フローにおける課題を整理し、 Amazon.com を含めた国内外事例から 生成 AI がどのように課題を解決するのかを整理しました。 図1 EC 業界における実績のある生成 AI ユースケース A. 差別化に繋がらない労働の削減 EC 市場は拡大をしている 中、商品の企画から販売に至るまでの負荷が大きな作業は効率化が求められます。 EC 業務担当者の 2 割が「運用リソース、サポート不足を課題に感じ」ており、4 割が「リソース不足で CRM 施策を実行できていない」との 調査結果 もあります。 例えば EC 業界において“撮影”、“採寸”、“原稿（商品説明用）”の頭文字をとった、通称「ささげ」と言われる業務がありますが、アパレル業界を中心にささげ業務は負荷が大きく効率的な実施が重要であると言われています（アパレル業界では特に色やサイズでSKUが異なる等商品種類が膨大かつ、シーズンに応じても種類が増減するため）。（※1） 企画から販売に至るまでの現場の課題の中で以下 3 つのユースケース解決が生成 AI で取り組まれ始めています。 1. 製品デザイン案生成 製品デザインのプロセスでは、アイデアの具現化に膨大な時間と労力を要し、アイデア発想から実際の製品デザインに落とし込むまでの試行錯誤の繰り返しは、コスト増大にもつながります。また、市場ニーズの急速な変化に対応しきれず、競合他社に後れを取るリスクも高まっています。 生成 AI を活用することで、デザイナーは瞬時に多様なアイデアを視覚化し、迅速な意思決定を行えるようになってきています。さらに、生成 AI に対して、自社で持つ独自のデータで学習することで、自社の特徴を反映した革新的なデザインの創出も可能になっています。これにより、製品開発サイクルが大幅に短縮され、市場投入のスピード向上が期待できます。また、AI が提案する予想外のデザインが、デザイナーの創造性をさらに刺激する効果も見られています。 2. 商品説明文生成 私は日頃多くの EC 業界の企業様とお話をしていますが、上述の「ささげ業務」の作業負荷に悩まれているお客様は非常に多いです。商品説明文がメーカー仕入れ商品で不足していたり、EC サイトに出品するのに必要なタグやカテゴリ情報が不足していたりし、そこを補足する作業に多くの工数が割かれます。扱う商材/SKU数が増えていくことで作業負担は増加し、販売開始まで時間を要してしまうことで機会損出にも繋がります。 LLM（大規模言語モデル）により、商品画像やタイトル, 素材情報等の今ある情報と、商品情報として用意した項目や過去のサンプルを指定することで、商品説明文の生成が可能になります。 Amazon.com でも 販売者向けに商品説明文自動生成ツールを発表 を行っています。 3. 商品背景画像生成 同様に商品の出品時の画像、あるいは広告画像やキャンペーンサイトのランディングページ等、商品販売に際し画像を用意する必要があり、そのためのスタジオや撮影者の確保、デザイナー工数や作成までのリードタイム等、画像の用意にも課題があります。これはシーズンごとやキャンペーンごとに違った画像を用意したい要望がある場合もあり影響が大きいです。 画像生成モデルの既存画像の一部のみを修正する技術（inpaint）により、商品画像の背景部分のみを修正し、季節やキャンペーンのコンセプトに合わせた商品画像生成が可能です。 また、HTML等のコンテンツファイル作成も LLM により可能なので、ランディングページも含めた生成も可能です。 Amazon Ads でも 商品広告画像の背景生成ツール を発表 しています。 B. 顧客体験のパーソナライズ レコメンドエンジンや Marketing Automation 等により取り組まれている方も多いかもしれませんが、ただ商品を売るだけでなく多様なチャネルでユーザーに適切にアプローチし、顧客の購買体験をパーソナライズすることで、ユーザーの継続的な利用を促すことができます。 マッキンゼーによると 、「71％の消費者は、企業がパーソナライズされたインタラクションを提供することを期待している」とのことですし、 Baymard Institute によると、「全 EC サイトのうち 61％ が、 ユーザーの検索語句にそぐわない検索結果を表示している」ため、従来のキーワード検索だけでない購買体験が求められています。（※2,3） 4. 商品検索/比較アシスタント 生成 AI を利用することで、商品カタログやユーザーペルソナを踏まえた商品の提案や比較が可能ですし、画像含めたマルチモーダル検索やセマンティック検索（意味合い検索）の実装も比較的用意になっています。これにより従来の検索ベースでの購買体験をパーソナライズされた体験に変革していくことが可能です。 Amazon.com でも Rufus というショッピングアシスタントを発表しており、ショッピングのニーズ、製品、比較に関する顧客の質問に答え、コンテキストに基づいて推奨事項を作成すると紹介されています。 自社や利用者の課題に照らして、生成 AI ユースケースを特定しましょう 上記 4 つのユースケースは既に AWS 上で取り組まれているお客様も数社いらっしゃり、実際にプロダクトローンチまで3ヶ月で取り組まれた事例（※4）もあります。 どこから始めるか悩んでいらっしゃるお客様は、まずはこれらのユースケースについてご検討されることをお勧めしております。 これらのユースケースの中から、自社や利用者の課題を解決するユースケースを特定することが難しいと感じられる方がいらっしゃるかもしれません。 そういったお客様のために、 AWS が無償でユースケースを特定する Workshop （ML Enablement Workshop）を公開しています。この Workshop はお客様自身で実行可能なものとなっています。ぜひ一度ご参照ください。 https://github.com/aws-samples/aws-ml-enablement-workshop このブログをご覧になってもう少し内容を詳しく聞きたいというお客様がいらっしゃいましたら、AWS担当営業もしくは こちらの窓口 までご連絡頂ければと思います。 — ※1: p31 ささげ業務 : 経済産業省「令和元年度 内外一体の経済成長戦略構築にかかる 国際経済調査事業」 https://www.meti.go.jp/meti_lib/report/2019FY/030619.pdf ※2: 自然言語処理で e コマースサイトにおける検索精度を向上させ収益改善に繋げる https://aws.amazon.com/jp/blogs/news/revive-lost-revenue-from-bad-ecommerce-search-using-natural-language-processing/ ※3: Amazon Personalizeと生成系AIでマーケティングソリューションを高度化する https://aws.amazon.com/jp/blogs/news/elevate-your-marketing-solutions-with-amazon-personalize-and-generative-ai/ ※4: ポイントモール「ハピタス」で生成AIを活用した次世代広告検索機能をリリース | 株式会社オズビジョン https://www.oz-vision.co.jp/news/835/ 生成AIを活用した次世代広告検索機能を2024年7月1日にリリース アマゾン ウェブ サービス（AWS）からの生成AI活用のためのユースケース確定ワークショップや、プロトタイピングのためのワークショップなどの支援を受け機能実装を行いました。 次回はデモ解説です 次回のブログでは、今回ご紹介した EC 業界における代表的な生成 AI ユースケースについて、Amazon Bedrock を利用した具体的な実装例として AWS Summit Japan 2024 で展示したデモの解説を行います。 ぜひこちらもご参照いただければ幸いです。 https://aws.amazon.com/jp/blogs/news/aws-summit-2024-retail-cpg-ec-genai-bedrock-demo-architecture/ ブログ著者 本ブログ著者： 堀内 保大 (Yasuhiro Horiuchi) / @ka_shino_ki アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト Web系の特にEコマース関連のお客様をビジネス起点から技術面まで横断的に支援しています。 好きなサービスは、AWS Fargate でコンテナに関連したサービスに興味があります。趣味は旅行とスノーボードです。

国内最大規模の学習型ITカンファレンスである AWS Summit Japan が、6 月 20 日（木）、21 日（金）の二日間に渡り幕張メッセで開催されました。今年は昨年よりもブース展示が拡充され、ヘルスケア・ライフサイエンス（HCLS）ブースでは、大きく製薬、ゲノミクス、医療業界の 3 つのカテゴリーに沿って展示を行い、お陰様で大勢のお客様にご来場いただきました。展示内容としては、お客様の大きな関心事である生成AIを活用した業務効率化、自動化に加えて、業界特化型サービスである AWS HealthOmics や医用画像管理ソリューションなどを盛り込んだ最新デモをご紹介しました。 展示したデモ内容 製薬業界向けソリューション(臨床以外の事業領域でも生成AI活用をご支援いたします) ①生成AIを活用した臨床開発におけるプロトコルのドラフト作成支援 – 先行研究調査 ②生成AIを活用した臨床開発におけるプロトコルのドラフト作成支援 – 対象集団デザイン ゲノミクスユースケース向けソリューション ③解析ワークフローの便利な実行 ④オミクスデータの分析 ⑤ワークフローの開発 医療業界向けソリューション ⑥医用画像管理とDICOMwebアクセスによるデータ二次利用 ⑦生成AIを活用した電子カルテ情報から退院サマリー作成 以下のセクションより、各ソリューションの詳細を説明します。 製薬業界向けソリューション：製薬向け生成 AI (創薬/臨床開発/製造) [ Slide ] 製薬向け生成 AI ブースでは、 Amazon Bedrock を利用した、製薬企業における各業務に⽣成AIを組み込むことでプロセスの短縮、効率化および新たなインサイトの抽出することをイメージしていただくためのデモを展示しました。 ヘルスケア・ライフサイエンス領域は、生成 AI の活用が最も期待される領域の一つであり、研究開発、臨床開発、製造からマーケティング・営業まで様々な業務部門で高いビジネス効果が期待されています。詳細は、次のAWSブログを参照ください。生成系 AI が拓くイノベーション:大規模言語モデル (LLM) を活用した製薬企業の業務改善 Part 1 , Part 2 , Part 3 。一方で、製薬企業における各業務は非常に専門性が高く、基盤モデル (FM) を単純なチャットボットや RAG (Retrieval Augmented Generation) と呼ばれる手法に応用しただけではビジネス効果を期待できないケースがあります。そのため、基盤モデルの特性をよく理解した上で、各業務のプロセス全体を俯瞰し、組み合わせるデータを検討した上でアプリケーションのアーキテクチャおよびそれを組み込んだ業務プロセスを模索する必要があります。一方で、特に普段データ分析やアプリケーション開発を専門としない業務部門にとっては、業務プロセスに基盤モデルを組み込んだアプリケーションを素早く作成し、業務に適用して改善のループを迅速に回すことに課題がありました。そこで、製薬企業における基盤モデルを組み込んだ業務デザイン素早く検証するための様々なユースケースのプロトタイピング実装が Generative AI Starter Apps for Pharma Workload (GASA for Pharma) です。 GASA for Pharma では、現在は主に臨床開発のユースケースを中心に、各業務プロセスに合わせて基盤モデルを活用したプロセスの短縮、効率化および新たなインサイトの抽出を体感いただけるシナリオを実装しています。これらのユースケースを実際に触っていただくことで、基盤モデルをどのように皆さんの業務に活用するかを具体的に想像していただけることを期待しています。また、各ユースケースのバックエンドのロジックはAmazon Bedrockの基盤モデルを呼び出す形で AWS Lambda の関数や AWS Step Functions のワークフローとして実装されているため、この実装を参考に素早く皆さんの業務やデータに合わせたシナリオを検証することが可能です。 今回のAWS Summit Japan 2024では、GASA for Pharma に現在実装されている、臨床開発向けの2つのユースケースを中心に紹介しました。 ①臨床開発におけるプロトコルのドラフト作成支援 – 先行研究調査 1つ目のユースケースは、クリニカルサイエンスや臨床開発のPMロールといった方々が横断的な先行研究調査を行うシナリオを想定したもので、基盤モデルによるクエリ生成や文章要約により、幅広い情報を素早く収集して可視化するデモとなっています。このデモでは、臨床開発の方々が慣れ親しんだ自然言語のフォーマットで調べたい先行研究の情報を入力すると、臨床研究のオンラインデータベースである ClinicalTrials.gov から情報を取得し、ビジュアルを含む全体の要約や各 Study の要約、および元となったデータソースへのリンクを確認することができます。 ②臨床開発におけるプロトコルのドラフト作成支援 – 対象集団デザイン 2つ目のユースケースは臨床試験の対象集団をデザインするために必要な情報を収集シナリオを想定したものです。データソースは1つ目のユースケースと同様 ClinicalTrials.gov ですが、違いはデータの深掘りをテーマとしている点です。このデモでは、入力するフォーマットは1つ目のユースケースと同様ですが、出力には Inclusion Criteria, Exclusion Criteria, Publication の情報のサマリーをすることで、必要な情報を素早く確認することができます。また、要約された各 Study から関心のあるものを選択することで、それらの複数の Study の横断的な要約を生成して確認することができます。このように人間の判断を介在させる Human-in-the-Loop と呼ばれる手法は機械学習モデルの業務活用において重要な考え方ですが、このデモでは基盤モデルを駆使した検索および要約生成に活用するケースを体感いただくことができます。 ゲノミクスユースケース向けソリューション：臨床/研究者のマルチオミクス解析の⾃動化 [ Slide ] AWS HealthOmics は、ヘルスケア・ライフサイエンス領域のお客様をご支援する業界特化型のサービスで、2022年末の re:invent で発表されました。AWS HealthOmics を利用することで、ゲノムデータ、トランスクリプトームデータ、その他のオミクスデータを保存、検索、分析し、そのデータから健康の改善と科学的発見の促進につながるインサイトを生み出すことに役立てることが可能です。 今回のデモは AWS HealthOmics を軸に以下 3 つの要素から構成されています: ③解析ワークフローの便利な実行 、 ④オミクスデータの分析 、 ⑤ワークフローの開発 。③に関しては AWS に詳しくない方でも HealthOmics ワークフローをより簡単に操作することが可能な Web アプリ を、④に関しては HealthOmics Analytics に取り込んだバリアント・アノテーションデータを Amazon SageMaker ノートブック や Amazon QuickSight を使って可視化や分析を行うデモをご紹介しました。また今回のデモは昨年の AWS Summit におけるデモ を拡張したコンテンツとなっているため、本記事では新しいコンテンツの 3 点についてご説明します。 まずワークフロー実行(③)に関するアップデートとして、リリース当初の AWS HealthOmics ワークフローはユーザーがワークフローの定義をアップロードして実行する形式（プライベートワークフロー）のみのサポートでしたが、事前定義済みのワークフローからすぐに解析を開始できる Ready2Run ワークフローという選択肢が追加されました。Sentieon、NVIDIA Parabricks、Element Biosciences といったパートナー各社のパイプラインに加え、GATK ベストプラクティス、nf-core scRNAseq、タンパク質予測のための AlphaFold や ESMFold を含むオープンソースパイプラインを含め、現在 36 種類のパイプラインが利用可能です。こちらの機能は前述の WebApp からも既に利用可能です。 また、ワークフロー実行(③)を自動化するという観点のデモをご紹介しました。内容としては、シーケンスデータが Amazon Simple Storage Service (Amazon S3) にアップロードされたことをトリガーにして、Ready2Run ワークフローの GATK BP Fastq2Vcf が実行され、さらにそちらが完了するとプライベートワークフローとして定義された Variant Effect Predictor (VEP) ワークフローが実行され、最終的に結果ファイルが Amazon S3 に出力されます。こちらは過去の ブログ の内容を元に作成されたものであり、自動実行を実現するサンプルコードが Github 上でも公開されています。 最後に、ワークフローの開発フェーズ(⑤)における AWS Step Functions 活用についてのデモです。背景として、オミクス解析のワークフローは複数の「タスク」から構成されており、実行に時間がかかることも多いため、例えば最後の部分でエラーが出た場合でも最初からやり直しが必要になってしまうといった開発面での課題があります。今回はデモを通して、この課題への対処として AWS Step Functions を利用するアプローチを紹介しておりました。AWS Step Functions はデベロッパーが AWS のサービスを利用して様々なデータを扱うパイプラインを構築できるようにするビジュアルワークフローサービスです。全体のワークフローの中の、特定のタスクのみを実行できることや( TestState )、途中失敗したタスクからの再実行( RedrivingExecution )といった機能を持っているため、上述した課題を解決しながらワークフロー開発でお役立ていただけるのではないかと考えています。 医療業界向けソリューション：医療機関向けHealthAI (医用画像管理／文書生成) [ Slide ] ⑥医用画像管理と DICOMweb アクセスによるデータ二次利用 医用画像管理において、画像の解像度の向上や画像枚数の増加によるストレージ容量の不足やサーバのスケーリングにおける課題解決のためにクラウド活用が進むと予想されます。その時にどのような AWS サービスを組み合わせて画像サーバを構築することができるのか、実際に動くソリューションを紹介しました。 医用画像は放射線画像や病理画像ともに国際標準である DICOM （Digital Imaging and Communications in Medicine）という国際標準に基づいて、ファイル形式や通信プロトコルが定められています。DICOM の特徴はピクセルデータ（画像）だけではなく、患者情報や検査情報といった文字情報を含めて、1つのファイルになっていることです。オープンソースの Orthanc は DICOM に準拠したサーバーソフトウェアです。Orthanc では、その DICOM ファイルを取り込み、タグの文字情報を検索可能なデータベースに、画像ファイルはストレージに保管します。 通常、検査種や検査数に応じて、画像の占有サイズからストレージ容量を見積ったり、データベースもレプリケーション（複製）やバックアップを取ったり、要求に対応したアプリケーションのスケーリングも必要になりますが、 Amazon S3 や Amazon RDS 、 AWS Fargate といったマネージドなサービスをインフラとして、 DICOM の規格に準拠した画像サーバをクラウドで構築できます。その環境構築をスクリプトで実行する AWS CDK を用いた Orthanc CDK Deployment をお使いいただけます。ブースでは同じくオープンソースの DICOM Viewer である Stone Viewer で放射線画像を、 WSI Viewer で病理画像をブラウザでの表示するデモを展示しました。 今回のデモにより、既存の撮影装置やアプリケーションで採用されている DICOM 標準の用画像サーバを AWS インフラで稼働させ、ウェブブラウザから画像を検索し参照するイメージを掴んでいただけたと思います。ウェブ経由で画像をアクセスできる DICOMweb は主要なプログラミング言語から利用可能な REST API を採用しているので、 Python で医用画像を機械学習に活用やスマホアプリやウェブアプリなど、様々なユースケースでお使いいただけます。会場では増え続ける医用画像の無制限のストレージやデータベースのバックアップや運用でお困りのお客様からは強い関心をもっていただきました。 ⑦生成AIを活用した電子カルテ情報から退院サマリー作成 退院サマリーは入院患者が病院を退院する時に作成される、病歴や身体所見、検査所見や入院中の医療内容（検査、投薬、治療等）の記録で、退院後の他の診療科や医療機関への外来診療などで治療を継続できるために医師の責任で書かれる文書です。その記録のために、患者に関連する電子カルテや部門システムの情報にアクセスし、決められた形式で担当医師が書くことにかなりの労力と時間がかかっています。その課題を解決するために、生成AIのサービスである Amazon Bedrock と Anthoropic Claude （最新の3.5を含む）による退院サマリー生成アシスタントのプロトタイプを開発しました。 患者 ID を入力し、医師記録や看護記録といったシステムが持っている患者に関する情報を横断的に収集し、膨大な情報を元に、退院サマリーとして求められる病歴や治療経過などを定型のフォーマットで生成することができます。 Prompt engineering で GenAI が推測文書を書くことを抑止し、各システムが持つ記録のみに基づいて、文書が生成されるようにしています。医師はこのアシスタントにより、収集された一次データを確認しつつ、生成された退院サマリーの雛形を手直しすることで、ゼロから退院サマリーを書くよりも、時間を患者のために有効に使うことができるようになります。プロトタイプについて関心を持たれたら、 弊社営業担当もしくはAWS 問い合わせ窓口へお問い合わせください。 著者について 原田 裕平 (Yuhei Harada) エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト: AWSでは主にヘルスケア・ライフサイエンス業界のお客様を支援をしているソリューションアーキテクトです。 鳥羽 祐輔 (Yusuke Toba) エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト: 現在はライフサイエンスのお客様向けにクラウド活用に関する技術的なご支援を行っています。またバイオインフォマティクスやゲノミクスの領域でクラウドを活用いただくことでお客様の研究活動・ビジネスを加速させることに興味があり、AWS HealthOmics をはじめとする AWS ソリューションのご提案や技術支援を行っています。 窪田 寛之 (Hiroyuki Kubota) エネルギー・ヘルスケアライフサイエンスソリューション部 ソリューションアーキテクト: HL7やDICOMの標準化活動の経験から、医療情報・医用画像を扱うお客様のクラウド利用に関する技術支援をしています。最近は新しい医療データ標準のHL7 FHIRを格納するAmazon HealthLakeなどを提案しています。 片岡 勇人 (Yuto Kataoka) ヘルスケア・ライフサイエンス事業開発部 シニア事業開発マネージャー: クラウドに対する日本のお客様固有の要件にお応えするために、AWS グローバルチームとも連携し、ヘルスケア・ライフサイエンス領域のお客様の取組みをご支援しております。

多くの組織が Amazon Connect を利用してコンタクトセンターを運営し、 Connect API によりカスタムアプリケーションを統合しています。これらの API は、エージェントの状態管理、リアルタイムメトリクスの取得、コンタクトセンターのプロセス自動化、特定のビジネス要件を満たすための全体的な顧客体験のカスタマイズなど、コンタクトセンター運用のさまざまな側面を合理化およびカスタマイズするために使用されます。しかし、通話量が多い際には、これらの API 統合によって大量のリクエストが発生する可能性があります。API の使用量がプロビジョニングされた容量を超えると、顧客のリクエストがスロットリングされ、コンタクトセンターのパフォーマンスに影響を与えます。 このブログ記事では、お客様が Amazon CloudWatch を活用して Amazon Connect コンタクトセンター API の使用状況をアクティブに監視し、API の使用量が定義された容量制限に近づいたときにアラートを受け取る方法について説明します。これにより、アプリケーションの最適化や容量の追加など、パフォーマンスの問題が発生する前に対処できます。この処理は、 AWS Cloud Development Kit (CDK) を用いて、効率的にプログラムによる CloudWatch アラームの作成および管理が可能です。Amazon Connect API の使用状況の包括的な監視とアラート設定を行うことで、企業はコンタクトセンターの運用を常に円滑かつ効率的に行え、ボトルネックの発生を未然に防ぎ、最適なパフォーマンスを維持できます。 ソリューションの概要 このソリューションでは、Amazon Connect API の 1 つ DescribeQueue を監視するための Amazon CloudWatch アラームの作成方法を説明します。アラームを作成する 3 つの異なる方法を紹介しますので、ご利用のユースケースに合わせていずれか 1 つを使用して下さい。 A. Amazon CloudWatch からアラームを作成 B. Service Quotas からアラームを作成 C. AWS Cloud Development Kit (CDK) を使用してアラームを作成 前提条件 このソリューションでは、次のリソースを理解し、アクセスできることを前提としています。 AWS アカウント Amazon Connect インスタンス AWS CDK のインストール Amazon SNS トピック ソリューションのデプロイ Amazon Connect API を監視するアラームを作成するために、まず CloudWatch Metric Math を作成して、 DescribeQueue API の現在の使用状況を SERVICE QUOTA のパーセンテージとして表示します。アラームを作成したい他の API を選択することもできます。API またはそのメトリクスが表示されない場合は、その API が呼び出されていないことを意味します。DescribeQueue API のメトリクスを生成するには、Amazon Connect インスタンスにログインし、ルーティングの下のキューを選択し、BasicQueue または他のキューをクリックします。 A) Amazon CloudWatch コンソールからアラームを作成する手順 CloudWatch コンソール ( https://console.aws.amazon.com/cloudwatch/ ) を開きます 左側のナビゲーションペインから メトリクス を選択します すべてのメトリクス をクリックし、 使用 を選んでから AWS リソース を選びます。サービスクォータ使用状況メトリクス の一覧が表示されます 検索ボックスに API 名である DescribeQueue を入力し、チェックボックスをクリックします。または、サービス名である Connect を入力し、結果リストから API を選択することもできます。グラフには、その API の現在の使用状況が表示されます 現在の使用状況をクォータの割合で確認するには、以下の手順を実行します グラフ化したメトリクスタブ を選択します ドロップダウンメニュー 数式を追加 をクリックし 空の式で始まる を選択します。新しい行の 詳細 の下に、 m1/SERVICE_QUOTA(m1)*100 と入力し、 適用 をクリックします サービスクォータに近づいた場合に通知するアラームを設定するには、以下の手順を実行します m1/SERVICE_QUOTA(m1)*100 の行で、 アクション の下にあるベルのようなアラームアイコンを選択します。アラーム作成ページが表示されます 期間 を 1 分 または 5 分 に設定します 条件 の下で、 しきい値の種類 が 静的 になっており、 式 1 が次の時… が 以上 に設定されていることを確認します。 … より もの下に 80 と入力します。これにより、使用量がクォータの 80% 以上になった場合に ALARM 状態になるアラームが作成されます その他の設定 の下で、 アラームを実行するデータポイント を 3/3 または要件に応じた値に指定し、 欠落データの処理 で 欠落データを見つかりませんとして処理 を選択して、 次へ を選択します 次のページで、 通知 の下にある アラーム状態トリガー で アラーム状態 が選択されていることを確認し、 既存の SNS トピックを選択 を選んで SNS トピックを選択するか、 新しいトピックの作成 を選んで一意のトピック名を入力し、通知を受け取る電子メールのエンドポイントを指定します。また、 トピック ARN を使って他のアカウントに通知 を選んで 次へ をクリックすることもできます。選択したトピックは、アラームが ALARM 状態になったときに通知されます 次のページで、 アラーム名 に DescribeQueueAlarm と入力し、 次へ を選択します アラームの作成 を選択します B) Service Quotas から アラームを作成する手順  別の方法として、Service Quotas からアラームを作成することもできます。 Service Quotas コンソール ( https://console.aws.amazon.com/servicequotas/ ) にアクセスします 左側のナビゲーションペインで、 AWS のサービス を選択します サービスのリストから Amazon Connect を検索し、選択します サービスクオータ の下から DescribeQueue を検索します。クォータ名 Rate of DescribeQueue API requests が表示されます。詳細と下にあるさまざまなタブを確認するため、クォータ名をクリックします アラーム タブを選択し、 作成 をクリックします アラームのしきい値 を 適用されたクォータ値の 80% に設定します アラーム名 を DescribeQueueAlarm と入力し、 作成 をクリックします アラームを編集するには、アラーム名 DescribeQueueAlarm をクリックしてアラームページを表示し、 アクション からの 編集 を選択します。ここで期間やアラームのデータポイントを更新し、既存の Amazon SNS トピックを選択したり、新しいトピックを作成できます C) AWS CDK を使用してアラームを作成する方法 Amazon Connect API を監視するための CloudWatch Alarm を自動的に作成したい場合は、 AWS Cloud Development Kit (CDK) を使用することができます。 Python AWS CDK を使用して、Amazon CloudWatch の Alarm を設定します。 アプリを作成します $ mkdir DescribeQueueAlarm $ cd DescribeQueueAlarm アプリを初期化します cdk init app --language python アプリの Python 仮想環境を有効化し、AWS CDK のコアの依存関係をインストールします source .venv/bin/activate python -m pip install -r requirements.txt 次の例を describe_queue_alarm/describe_queue_alarm_stack.py に貼り付けて、Amazon CloudWatch アラームを追加します。コード内のサンプル SNS トピックは、前提条件として作成した SNS トピックに置き換えてください from aws_cdk import ( Stack, ) from constructs import Construct from aws_cdk import aws_cloudwatch as cloudwatch class DescribeQueueAlarmStack(Stack): def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None: super().__init__(scope, construct_id, **kwargs) cfn_alarm = cloudwatch.CfnAlarm(self, "DescribeQueueAlarm", alarm_name="DescribeQueueAlarm", alarm_description="Alarm to monitor Describe Queue API Usage", comparison_operator="GreaterThanOrEqualToThreshold", evaluation_periods=3, datapoints_to_alarm=3, metrics=[cloudwatch.CfnAlarm.MetricDataQueryProperty( id="m1", label="Describe Queue", metric_stat=cloudwatch.CfnAlarm.MetricStatProperty( metric=cloudwatch.CfnAlarm.MetricProperty( namespace="AWS/Usage", metric_name="CallCount", dimensions=[cloudwatch.CfnAlarm.DimensionProperty( name="Resource", value="DescribeQueue" ), cloudwatch.CfnAlarm.DimensionProperty( name="Service", value="Connect" ), cloudwatch.CfnAlarm.DimensionProperty( name="Type", value="API" ), cloudwatch.CfnAlarm.DimensionProperty( name="Class", value="None" )] ), period=60, stat="Average" ), return_data=False), cloudwatch.CfnAlarm.MetricDataQueryProperty( id="e1", expression="(m1/SERVICE_QUOTA(m1))*100", label="describe_queue_pct_utilisation", return_data=True )], threshold=80, treat_missing_data="missing", #Replace SNS topic with the one you created as prerequisite alarm_actions=['arn:aws:sns:us-east-1:1234567890:SnsTopic'] ) AWS CloudFormation テンプレートを合成します cdk synth AWS CloudFormation に CDK スタックをデプロイします cdk deploy クリーンアップ CloudWatch アラームを削除するには : CloudWatch コンソール ( https://console.aws.amazon.com/cloudwatch/ ) を開きます 左側のナビゲーションペインで すべてのアラーム を選択します アラームのリストから DescribeQueueAlarm を選択します アクション から 削除 を選択し、アラームを削除します SNSトピックを作成した場合は、以下の手順で削除します : SNS コンソール ( https://console.aws.amazon.com/sns/home ) を開きます 左側のナビゲーションペインで トピック を選択します トピック ページで、CloudWatch アラーム作成時に使用したトピックを選択し、 削除 を選択します トピックの削除ダイアログボックスに これを削除 と入力し、 削除 を選択します Service Quotas から作成したアラームを削除する場合も、上記と同様の手順で行います。AWS CDK を使用して CloudWatch アラームを作成した場合は、以下のコマンドで AWS CloudFormation スタックとそれに関連付けられたすべてのリソースを削除できます。 cdk destroy 結論 この記事では、Amazon CloudWatch アラームと Amazon Simple Notification Service を使用して、Amazon Connect API の使用状況を監視し、使用量がしきい値を超えた場合に通知を受け取る方法について説明しました。また、AWS Cloud Development Kit (CDK) を使用して、API 使用状況を監視する Amazon CloudWatch アラームの作成を自動化する方法についても紹介しました。 CloudWatch に API 使用状況メトリクス をレポートするサービスのリストの詳細については、AWS API 使用状況メトリクスをご覧ください。 筆者について Naseer Sayyad は、Amazon Web Services のシニアテクニカルアカウントマネージャーです。Naseer は、AWS のエンタープライズ顧客と協力し、クラウド移行ジャーニーで成功するためのサポートをしています。彼はクラウドコンピューティングと自動化に情熱を持っています。仕事以外では、旅行と写真撮影を楽しんでいます。LinkedIn のアカウントは @naseersayyad です。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本日、 AWS Trainium と AWS Inferentia による Llama 3.1 モデルのファインチューニングと推論のサポートを発表できることを嬉しく思います。Llama 3.1 ファミリーは、8B（80億）、70B（700億）、405B（4,050億）サイズの事前学習およびインストラクションチューニング済みの多言語大規模言語モデル（LLM）のコレクションです。 以前の投稿 では、 Amazon SageMaker JumpStart で AWS Trainium と Inferentia ベースのインスタンスに Llama 3 モデルをデプロイする方法について解説しました。今回の投稿では、AWS AI チップ上で そのコストパフォーマンスの利点と共に Llama 3.1 ファミリーのモデルのファインチューニング及びデプロイを実現する方法について概説します。 Llama 3.1 モデルの概要 Llama 3.1 ファミリーの多言語 LLM は、8B、70B、405B サイズの事前学習およびインストラクションチューニング済みの生成モデルのコレクションです（テキスト入力/テキストおよびコード出力）。すべてのモデルは長いコンテキスト長（128k）をサポートし、グループ化されたクエリアテンション（GQA）をサポートしているため、推論が高速です。 Llama 3.1 インストラクションチューニング済みモデル（8B、70B、405B）は多言語対話ユースケース向けに最適化されており、 一般的な業界ベンチマークで多くの公開されているチャットモデルを上回るパフォーマンス を示します。これらは検索、画像生成、コード実行、数学的推論などの特定のツールのツールコールを生成するよう訓練されています。さらに、ゼロショットのツール使用もサポートしています。 Llama 3.1 405B は、Meta によると世界最大の公開利用可能な LLM です。このモデルは人工知能（AI）の新しい基準を設定し、エンタープライズレベルのアプリケーションや研究開発に理想的です。合成データ生成のようなタスクに適しており、モデルの出力をファインチューニング後に小規模な Llama モデルの改善に使用したり、405Bモデルから小規模モデルへの知識転移のためのモデル蒸留（distillations）に使用したりできます。このモデルは、一般知識、長文テキスト生成、多言語翻訳、機械翻訳、コーディング、数学、ツール使用、強化された文脈理解、高度な推論と意思決定において優れています。 アーキテクチャ的には、Llama 3 と Llama 3.1 のコア LLMは 同じ密（dense）なアーキテクチャです。これらは最適化されたトランスフォーマーアーキテクチャを使用する自己回帰言語モデルです。ファインチューニングされたバージョンは、有用性と安全性に関する人間の選好に合わせるために、教師ありファインチューニング（SFT : supervised fine-tuning ）と人間のフィードバックによる強化学習（RLHF : einforcement learning with human feedback）を使用しています。 Meta の責任ある使用ガイド は、モデルをカスタマイズし最適化するために必要な追加のファインチューニングを、適切な安全性対策とともに実装する際に役立ちます。 AWS Trainium が Amazon Bedrock と Amazon SageMaker で Llama 3.1 を強化 AWS で Llama 3.1 を始める 最速の方法は、目的に特化した AI インフラストラクチャ（AWS Trainium を含む）を利用するAmazon Bedrock です。完全に管理された API を通じて、 Amazon Bedrock は目的に特化した AI インフラストラクチャの利点を提供し、これらの強力なモデルへのアクセスを簡素化するため、差別化された AI アプリケーションの構築に集中できます。 基盤となるリソースをより細かく制御する必要がある場合は、 SageMakerでLlama 3.1モデルをファインチューニングおよびデプロイ できます。SageMaker JumpStart での Llama 3.1 の Trainium サポートは近日公開予定です。 AWS Trainium と AWS Inferentia2 が Llama 3.1 モデルの高性能と低コストを実現 トレーニングと推論のための独自の ML パイプラインを構築して、より高い柔軟性と制御を得たい場合は、 Amazon Elastic Compute Cloud （Amazon EC2）Trn1 および Inf2 インスタンスを使用して AWS AI チップ上で Llama 3.1 を開始できます。 AWS Neuron SDK を使用して新しい Llama 3.1 8B/70B モデルを開始する方法を見てみましょう。 Trainium 上で Llama 3.1 をファインチューニング Llama 3.1 8B または Llama 3.1 70B のファインチューニングを開始するには、 NeuronX Distributed ライブラリを使用可能です。NeuronX Distributed は、より一般的な分散トレーニングおよび推論技術の実装を提供します。 ファインチューニングを開始するには、以下のサンプルを使用できます： Training Llama 3.1 8B Training Llama 3.1 70B 両方のサンプルは、Trainium クラスターインフラストラクチャを管理する AWS ParallelCluster と、ワークロード管理のためのSlurm の上に構築されています。以下は Llama3.1 70B のトレーニングを開始するための Slurm コマンドの例です： sbatch --exclusive \ --nodes 32 \ --cpus-per-task 128 \ --wrap="srun bash $(pwd)/run_llama3_70B_tp_pp.sh" Slurm スクリプト内で、クラスター上で分散トレーニングプロセスを起動します。ランナースクリプトでは、Metaが提供する事前学習済みの重みと設定をロードし、トレーニングプロセスを開始します： torchrun $DISTRIBUTED_ARGS run_llama_nxd.py \ --train_batch_size $BS \ --use_meta_device_init 1 \ --training_dir $DATA_PATH \ --training_config $SCRIPT_DIR/${MODEL_SIZE}config_llama${LLAMA_VERSION} \ --max_steps $max_steps \ --seq_len $SEQ_LEN \ --pipeline_parallel_size $PP_DEGREE \ --tensor_parallel_size $TP_DEGREE \ --num_microbatches $NUM_MICROBATCHES \ --lr 0.000015 \ --min_lr 1e-06 \ --beta1 0.9 \ --beta2 0.95 \ --weight_decay 0.1 \ --warmup_steps 2000 \ --constant_steps 0 \ --use_zero1_optimizer 1 \ --use_selective_checkpoint 1 \ --use_flash_attention 1 \ --qkv_linear 1 \ --kv_replicator 4 \ --pretrained_weight 1 \ --save_load_xser 1 \ --checkpoint_dir "/shared/llama${LLAMA_VERSION}${MODEL_SIZE}/" \ --checkpoint_freq $checkpoint_freq \ --num_kept_checkpoint -1 \ --loading_step -1 \ --tb_dir $tb_dir |& tee $LOG_PATH/log exit ${PIPESTATUS[0]} Inferentia2 上で Llama 3.1 をデプロイ モデルのデプロイ準備ができたら、以前の Llama 3 8B Neuron サンプルコードでモデルIDを更新することでデプロイできます。 model_id = "meta-llama/Meta-Llama-3.1-8B" neuron_model = LlamaForSampling.from_pretrained(model_id, neuron_config=neuron_config, batch_size=1, tp_degree=24, amp='bf16', n_positions=4096) neuron_model.to_neuron() 同様のサンプル推論コードを使用できます： tokenizer = AutoTokenizer.from_pretrained(model_id) prompt = "Hello, I'm a language model and I like to" input_ids = tokenizer.encode(prompt, return_tensors="pt") # run inference with top-k sampling with torch.inference_mode(): start = time.time() generated_sequences = neuron_model.sample(input_ids, sequence_length=2048, top_k=50) elapsed = time.time() - start generated_sequences = [tokenizer.decode(seq) for seq in generated_sequences] print(f'generated sequences {generated_sequences} in {elapsed} seconds') ステップバイステップの詳細については、新しい Llama 3.1 のサンプルを参照してください： Meta Llama 3.1 8B Meta Llama 3.1 70B Meta Llama 3.1 8B 32k Meta Llama 3.1 405B on Trainium は近日公開予定です また、Hugging Face の Optimum Neuron ライブラリを使用して、Hugging Face Model Hub から SageMaker を通じて直接モデルをすばやくデプロイすることもできます。Llama 3.1 モデルカードハブから、「 Deploy 」（デプロイ）を選択し、次に「 SageMaker 」を選び、最後に「 AWS Inferentia & Trainium 」を選択します。サンプルコードを SageMaker ノートブックにコピーし、「 Run 」（実行）を選択します。 import json import sagemaker import boto3 from sagemaker.huggingface import HuggingFaceModel, get_huggingface_llm_image_uri try: role = sagemaker.get_execution_role() except ValueError: iam = boto3.client("iam") role = iam.get_role(RoleName="sagemaker_execution_role")["Role"]["Arn"] # Hub Model configuration. https://huggingface.co/models hub = { "HF_MODEL_ID": "meta-llama/Meta-Llama-3.1-8B", "HF_NUM_CORES": "2", "HF_AUTO_CAST_TYPE": "fp16", "MAX_BATCH_SIZE": "8", "MAX_INPUT_LENGTH": "3686", "MAX_TOTAL_TOKENS": "4096", "HF_TOKEN": "<REPLACE WITH YOUR TOKEN>", } assert hub["HF_TOKEN"] != "<REPLACE WITH YOUR TOKEN>", "Please replace '<REPLACE WITH YOUR TOKEN>' with your Hugging Face Hub API token" # create Hugging Face Model Class huggingface_model = HuggingFaceModel( image_uri=get_huggingface_llm_image_uri("huggingface-neuronx", version="0.0.23"), env=hub, role=role, ) # deploy model to SageMaker Inference predictor = huggingface_model.deploy( initial_instance_count=1, instance_type="ml.inf2.xlarge", container_startup_health_check_timeout=1800, volume_size=512, ) # send request predictor.predict( { "inputs": "What is is the capital of France?", "parameters": { "do_sample": True, "max_new_tokens": 128, "temperature": 0.7, "top_k": 50, "top_p": 0.95, } } ) さらに、vLLM を使用してモデルをデプロイしたい場合は、 continuous batching ガイド を参照して環境を作成できます。環境を構築した後、vLLM を使用して AWS Trainium または Inferentia に Llama 3.1 8B/70B モデルをデプロイできます。以下は Llama 3.1 8B をデプロイする例です： from vllm import LLM, SamplingParams # Sample prompts. prompts = [ "Hello, my name is", "The president of the United States is", "The capital of France is", "The future of AI is", ] # Create a sampling params object. sampling_params = SamplingParams(temperature=0.8, top_p=0.95) # Create an LLM. llm = LLM( model="meta-llama/Meta-Llama-3.1-8B", max_num_seqs=8, # The max_model_len and block_size arguments are required to be same as max sequence length, # when targeting neuron device. Currently, this is a known limitation in continuous batching # support in transformers-neuronx. max_model_len=128, block_size=128, # The device can be automatically detected when AWS Neuron SDK is installed. # The device argument can be either unspecified for automated detection, or explicitly assigned. device="neuron", tensor_parallel_size=8) # Generate texts from the prompts. The output is a list of RequestOutput objects # that contain the prompt, generated text, and other information. outputs = llm.generate(prompts, sampling_params) # Print the outputs. for output in outputs: prompt = output.prompt generated_text = output.outputs[0].text print(f"Prompt: {prompt!r}, Generated text: {generated_text!r}") 結論 AWS Trainium と Inferentia は、Llama 3.1 モデルのファインチューニングとデプロイを高性能かつ低コストで提供可能です。これらの強力なモデルと目的に特化した AI インフラストラクチャを使用して、差別化された AI アプリケーションを構築する方法を見るのが楽しみです。AWS AI チップの使用開始方法の詳細については、AWS Neuron ドキュメントの モデルサンプルとチュートリアル を参照してください。 翻訳は Annapurna Labs の常世が担当しました。原文は こちら です。