本ブログは北海道文化放送様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの村木です。 2024 年の AWS Summit では多くの生成 AI 事例が公開されており、生成 AI が世間に広がっていることを実感しております。製造業や金融業などの業界に特化したユースケースが数多く公開されていることが印象的でした。 そんな中、今回紹介するのは、北海道文化放送様で取り組んでいただいた Amazon Bedrock をはじめとしたマネージドサービスを活用し、ニュース原稿 / 動画の作成フローを効率化することで、ニュース動画配信数を増加した事例です。 「とりあえずやってみる」、「ダメだったらやめる」を意識して挑戦いただいていることが、良い結果につながったと考えています。スモールスタートが可能であり、運用費用も低コストなので予算がなくて業務改善に着手できないお客様にとってもぴったりな内容であると思います。また、各業務課題に対して適切なサービスを活用し業務効率化を行った良い例となりますので、生成 AI のみでなく業務改善の観点でもご参考になれば幸いです。 なお、本取り組みは AWS 事例 や AWS メディアセミナー でも紹介されているため、あわせて御覧ください。 事例概要 FAX で送付されたリリース情報を紙で保管しており管理コストの増加につながっている。また、ニュース原稿 / 動画作成に時間を要しており、数多くのニュースを視聴者に提供することができない。 Amazon Bedrock をはじめとしたマネージドサービスを活用することで紙媒体のデータ化、ニュース原稿 / 動画の作成フローの自動化を実施した。 資料管理コストの削減やニュース動画配信数の増加の効果が出ている。 お客様の状況と検証に至る経緯 北海道文化放送様は各市町村などから月に約 1,500 件ほど FAX で送付されるリリース情報を紙媒体で保存しています。それを元に原稿を作成し、文字とイメージ画像、地上波放送の切り抜き動画を Web 記事 として投稿していました。しかし、以下の課題が挙がっておりニュース動画の配信数に限界を感じていました。 紙媒体のアーカイブの手間と検索性の悪さ 記事作成担当の報道部員、動画作成担当の編集部員のリソース不足 動画作成負荷の重さ そこで、 Amazon Bedrock をはじめとしたマネージドサービスを活用し、ニュース原稿 / 動画の作成フローを効率化をするための検証をすることになりました。 ソリューション / 構成内容 本ソリューションはインフラストラクチャの管理、運用が少ないサーバーレスサービスで構成されており、低コストで運用可能です。主な機能は以下の 4 つであり、 Web アプリケーションを利用して一気通貫で管理することができます。 Amazon Polly を利用して記事の読み上げ音声生成 OCR した情報と追加の取材情報を元に Amazon Bedrock で要約し原稿を作成 AWS Lambda を利用した YouTube ショートや TikTok 用のタテ型動画の簡易生成 ※「タテ型動画の簡易生成」画像参照 送付された FAX を複合機で受信し OCR でテキスト化後、 Bedrcock で要約したテキスト情報を DB に格納 「ただ原稿生成するだけ」であれば Claude などの基盤モデルを直接利用することも一つの手段ですが 、AWS を利用することで生成 AI の回答精度を安定させたり、動画作成などの他機能との連携が容易になります。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(出展: 北海道文化放送株式会社) 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(出展: 北海道文化放送株式会社) 導入効果 システムをリリースした結果、手動で行っていた作業の大部分をシステム化することに成功しました。それに伴い、以下の効果を得ることができました。 検索性向上によるリリース情報の見逃防止、検索工数の削減  Amazon Bedrock による初稿作成、取材情報を取り入れた本稿作成の工数を削減 報道部員のみで原稿作成から動画含めたニュース投稿まで実施可能 地上波放送されていないニュースを動画配信可能となったことで、月間追加配信数が複数プラットフォーム（ YouTube 、 TikTok ）累計で 100~120 本に増加 低コストで大きな効果を得ていることが特徴です。サーバーレスサービスで構築されており従量課金であるため運用コストはおよそ $23 / 月 に抑えられています。構築も IT 担当者ではなく編成担当者がたった一人で構築しており、一つずつ業務改善に取り組み、結果的に一連のフローをすべてシステム化しました。予算が限られているがクラウドや生成 AI を利用して業務効率化に挑戦してみたいお客様にとってもハードルが低い事例となっています。 まとめ 今回は、北海道文化放送様で取り組んでいただいた Amazon Bedrock をはじめとしたマネージドサービスを活用し、YouTube や TikTok へ配信するニュース原稿 / 動画の作成フローを効率化することで、ニュース動画配信数を増加した事例を紹介しました。 冒頭でも触れたとおり「とりあえずやってみる」、「ダメだったらやめる」を意識して挑戦いただいており、従量課金である AWS ととても相性が良い進め方です。最終的な運用費用も安いので予算がなくて業務改善に着手できないお客様にとってもぴったりな内容であると思います。 また、本ソリューションは現在も改善を続けており、 OCR に Claude3 Haiku、文章生成に Claude3.5 Sonnet と基盤モデルを最新に切り替えしています。また、利用者からの要望を受けてリリース情報を受信したら、要約、タイトル、原稿、ジャンルをSlackに送信する機能を追加実装しており、好評を得ているそうです。利用者からの声を元に小さく構築と改善を続けていくことが最も早く効果を得られる方法の一つであるため参考にしていただければと思います。 本ブログから業務改善に取り組む方々が増えていただけるととても嬉しいので、ご興味をお持ちのお客様は、お気軽に AWS の担当者までご相談いただければと思います。 なお、作成された動画は北海道文化放送様の  YouTube や TikTok で配信されておりますのでこちらも是非確認いただけると幸いです。 ソリューションアーキテクト 村木 雄一

はじめに スマートビルやスマートファクトリーには、テレメトリーデータやシステム状態を継続的に収集するセンサーが何百、何千とあります。こうした施設はモニタリングとデータ収集によって、保全業務を「予期せぬ障害」へ事後対応するアプローチから予知保全のアプローチへシフトできるため、業務効率を上げ運用コストを下げることができます。 製造業の生産ライン、倉庫、工場などの産業設備における設備保全の管理者や技術者は、現場の停止時間を減らしたいと考えています。センサーおよびそれが収集する測定値は、メンテナンスを予測する上で貴重なツールです。しかしコンテキストがなければ、それらの情報が全体像を覆い隠してしまうかもしれません。ある 1 つのセンサーの測定値のみに注目するメンテナンス担当者は、無関係に見えかねない重要な関連性を見落とす可能性があります。産業設備を空間的に表示し、複数のセンサーからの測定値を統合した単一のビューを使用すれば、不具合の解決が簡素化され、予知保全が強化されます。 前回のブログ ( Amazon Monitron と Amazon Kinesis により予知保全のためのアクションにつながる洞察を得る方法 ) では、Amazon Monitron から得られた洞察 (人工知能 (AI) または機械学習 (ML) により測定値から得られる予測) を製造現場に取り込んだり作業指示を作成したりするソリューションを紹介しました。本ブログでは、テレメトリーを 3 次元 (3D) 空間に可視化できる AWS IoT TwinMaker と連携した、Amazon Monitron による予知保全のソリューションについて説明します。また、自然言語チャットボットを Amazon Bedrock で実装し、関連するメンテナンス文書や測定値からの洞察にアクセスする方法を紹介します。 ユースケースの概要 AWS IoT TwinMaker と Matterport を使えば、設備の管理者は稼働状況を 3D で可視化し、機器の状態を監視できます。AWS IoT TwinMaker と Matterport の統合により、開発者は Matterport のテクノロジーを利用して、さまざまなデータソースから得られる既存データと実世界のデータを組み合わせ、完全に統合されたデジタルツインを作成できるようになりました。情報を視覚的に提示することで、オペレーターの理解が深まりホットスポットを特定できるので、問題解決の時間を短縮できます。 このソリューションではAWS IoT TwinMaker と Matterport が使用されています。 AWS IoT TwinMaker は次のようなフルマネージド機能を提供することで、開発者が実世界のシステムのデジタルツインを作成するのを支援します。1/ 多様なソースからのデータにアクセス、2/ 物理システムを仮想的に表すエンティティを作成、そのエンティティ間の関係を定義し、データソースに接続、3/ 既存の 3D ビジュアルモデルを実世界のデータと組み合わせて、物理環境の対話的 3D ビューを構築。 Matterport は、実世界の環境をキャプチャ、スキャンし、没入型の 3D モデル (Matterport スペースとも呼ばれる) を作成するオプションを提供します。AWS IoT TwinMaker は Matterport 統合をサポートしており、Matterport スペースを AWS IoT TwinMaker シーンにインポートできます。AWS のお客様は今後、 AWS Marketplace から直接 Matterport にアクセスできるようになります。 ソリューションの概要 次の手順に従って、AWS IoT TwinMaker ワークスペースを作成し、Matterport スペースに接続します。その後、Matterport でタグ付けされたセンサーの位置を AWS IoT TwinMaker エンティティに関連付けます。AWS Lambda 関数を使って AWS IoT TwinMaker のカスタムデータコネクタを作成します。このデータコネクタにより、エンティティを Amazon Simple Storage Service (Amazon S3) データレイクに保存された Monitron のセンサーインサイトに関連付けます。最後に、 AWS IoT Application Kit を使用して、Monitron による予測結果を 3D 空間で可視化します。このブログでは、図 1 のアーキテクチャの “2. Digital twin – 3D Spatial Visualization” のセクションについて詳しく説明します。 図 1: ソリューションのアーキテクチャ概要 前提条件 アクティブな GitHub アカウントとログイン認証情報。 AWS アカウントと IAM ユーザー。 us-east-1 (バージニア北部) または eu-west-1 (アイルランド) リージョンの AWS IAM Identity Center (旧 AWS Single Sign-On)。 Amazon Monitron (センサーとゲートウェイ。詳細は Amazon Monitron の開始方法 を参照)。 iOS (iOS 14.0.0 以降) または Android (バージョン 8.0 以降) で、Monitron モバイルアプリ ( iTunes または Google Play ) がインストールされたスマートフォン。 AWS IoT TwinMaker 統合に必要な Enterprise プランの Matterport アカウントとライセンス。詳細は、 AWS IoT TwinMaker の Matterport 統合 の手順を参照してください。必要に応じて、Matterport のアカウント担当者に支援を求めてください。アカウント担当者がいない場合は、 Matterport and AWS IoT TwinMaker ページの問い合わせフォームを利用できます。 注意 : デプロイする全ての AWS リソースが同じ AWS リージョンにあることを確認してください。また、AWS マネジメントコンソールへのリンクは全て us-east-1 リージョンを指しています。他のリージョンを使用予定の場合は、マネジメントコンソールへのリンクをクリックした後、リージョンを切り替える必要があります。 Monitron のデータエクスポートの設定と ETL (Export, Transfer and Load) パイプラインの作成 このブログシリーズのパート 1 の手順に従って、Amazon Monitron のデータから IoT データレイクを構築してください。 Monitron のスキーマ定義については、 Amazon Monitron Kinesis データエクスポート v2 を参照してください。 注意 : 2023 年 4 月 4 日以降に有効化されたライブデータエクスポートは、Amazon Monitron Kinesis データエクスポート v2 です。この日付より前に有効化されたデータエクスポートは v1 です。このソリューションでは v2 の利用を推奨します。 データレイクの接続プロパティ 構築したデータレイクから以下の情報を記録しておいてください。これらは次のステップで必要になります。 データが保存されている Amazon S3 バケット名 AWS Glue データカタログのデータベース名 AWS Glue データカタログのテーブル名 AWS IoT TwinMaker データコネクタの作成 このセクションでは、デジタルツインとデータレイクのデータを接続する、AWS IoT TwinMaker のカスタムデータコネクタのサンプルについて説明します。AWS IoT TwinMaker を使用する前にデータを移行する必要はありません。このデータコネクタは、AWS IoT TwinMaker がデータレイクにアクセスするために呼び出す 2 つの Lambda 関数で構成されています。 TWINMAKER_SCHEMA_INITIALIZATION 関数は、データソースのスキーマを読み取るために使用されます。 TWINMAKER_DATA_READER 関数は、データを読み取るために使用されます。 注意 : このブログで参照しているすべてのコードは、 この GitHub リンク で入手できます。 Lambda 用の IAM ロールの作成 AWS Identity and Access Management (IAM) で Lambda に引き受けさせる IAM ロールを作成してください。同一の IAM ロールが両方の Lambda 関数で使用されます。このロールに IAM ポリシー を追加してください。 AWS IoT TwinMaker スキーマの初期化用 Lambda 関数の作成 このセクションでは、データレイクのスキーマを取得する Lambda 関数のサンプルコードを提供します。これにより、AWS IoT TwinMaker はデータソース内で利用可能になっている様々な種類のデータを特定できます。 関数名: TWINMAKER_SCHEMA_INITIALIZATION ランタイム: Python 3.10 以降 アーキテクチャ: arm64 (推奨) タイムアウト: 1 分 30 秒 Lambda 関数の ソースコード Lambda 関数の環境変数に、データレイクの接続プロパティを設定します。 キー 値 ATHENA_DATABASE <YOUR_DATA_CATALOG_DATABASE_NAME> ATHENA_TABLE <YOUR_DATA_CATALOG_TABLE_NAME> ATHENA_QUERY_BUCKET s3://<YOUR_S3_BUCKET_NAME>/AthenaQuery/ AWS IoT TwinMaker へのデータ取得用 Lambda 関数の作成 この章では、AWS IoT TwinMaker からのリクエストに基づいてデータレイクからデータを取得する Lambda 関数のサンプルコードを提供します。 Lambda 関数名: TWINMAKER_DATA_READER ランタイム: Python 3.10 以降 アーキテクチャ: arm64 (推奨) タイムアウト: 1 分 30 秒 Lambda 関数の ソースコード Lambda 関数の環境変数に、データレイクの接続プロパティを設定します。 キー 値 ATHENA_DATABASE <YOUR_DATA_CATALOG_DATABASE_NAME> ATHENA_TABLE <YOUR_DATA_CATALOG_TABLE_NAME> ATHENA_QUERY_BUCKET s3://<YOUR_S3_BUCKET_NAME>/AthenaQuery/ ストリームデータを取り込むための AWS IoT TwinMaker コンポーネントとエンティティの作成 AWS IoT TwinMaker のワークスペースをまだお持ちでない場合は、 ワークスペースの作成 の手順に従ってください。ワークスペースは、デジタルツインに関連するすべてのリソースを格納するコンテナです。 AWS IoT TwinMaker ワークスペースを設定する手順は以下の通りです。 TwinMaker コンソールに移動します。 Create workspace を選択します。 ワークスペースの名前 YOUR_WORKSPACE_NAME を入力します。 Create an Amazon S3 bucket を選択します。 実行ロールのドロップダウンから Auto-generate a new role を選択します。 Skip to review and create を選択します。 Next を選択します。 次に Skip to review and create を選択します。 Create Workspace を選択します。 図 2: AWS IoT TwinMaker でワークスペースを作成する IoT データレイクからストリームデータを取り込むには、独自の AWS IoT TwinMaker コンポーネントを作成します。詳細については、 コンポーネントタイプの使用と作成 をご覧ください。 次の JSON サンプルを使用して、AWS IoT TwinMaker がデータレイクからデータをクエリする権限とアクセスを許可するコンポーネントを作成してください。 AWS IoT TwinMaker ワークスペースを開きます。 ナビゲーションペインのメニューから Component Types を選択します。 Create Component Type を選択します。 GitHub リポジトリのファイル をコピーし、画面の Request 部分に貼り付けます。これですべてのフィールドが自動入力されます。 コンポーネントを作成した後は、Athena 経由で Amazon S3 のデータを問い合わせるための Lambda 関数を呼び出すように AWS IoT TwinMaker の実行ロールを設定します。 TwinMaker コンソールを開き、Workspaces area を開きます。 作成したワークスペースを選択します。 ワークスペースで使用されている実行ロールを特定します。 図 3: 実行ロールを特定 IAM コンソール を開きます。 Policies を選択し Create Policy を選択します。 JSON を選択し、 このコード を GitHub からペーストします。<AWS_REGION> と <AWS_ACCOUNT_NUMBER> を実際の値に置き換えます。 Next を選択します。 Review and create ページで、名前として DigitalTwin-TwinMakerLambda と入力します。 Create Policy を選択します。 Roles メニューを展開します。 twinmaker-workspace-YOUR_WORKSPACE_NAME-UNIQUEID を検索し、選択します。 Add permissions を展開し、 Attach policies を選択します。 図 4: ポリシーのアタッチ DigitalTwin-TwinMakerLambda を検索し、選択します。 Add permissions を選択します。 エンティティは、デジタルツインの要素の機能をキャプチャするデジタル表現です。ここでいう「要素」とは、物理的な機器またはプロセスです。エンティティには関連づけられたコンポーネントがあります。これらのコンポーネントは、関連するエンティティのデータとコンテキストを提供します。コンポーネントタイプを選択して、エンティティを作成できます (詳細は 最初のエンティティを作成する を参照してください)。 AWS IoT TwinMaker コンソール に移動します。 ワークスペースを開きます。 ナビゲーションペインで Entity を選択します。 Create を選択し、 Create Entity を選びます。 Create entity を選択します。 図 5: エンティティを作成 作成したエンティティを選択し、 Add Component を選択します。 名前として MonitronData と入力します。 タイプとして com.example.monitron.data を選択します。 Add Component を選択します。 エンティティのステータスが Active に変わったことを確認します。 図 6: コンポーネントのプロパティを追加 エンティティが Active になったら、MonitronData コンポーネントを選択します。利用可能なプロパティのリストが表示されるはずです。 物理環境の 3D デジタルツインの作成 AWS IoT TwinMaker でエンティティを作成したら、そこに Matterport タグを関連付けます (Matterport の使用方法の詳細は、 AWS IoT TwinMaker and Matterport についての Matterport ドキュメントを参照してください)。 AWS IoT TwinMaker Matterport 統合 のドキュメントに従って、Matterport スペースを AWS IoT TwinMaker にリンクしてください。 Matterport スペースを AWS IoT TwinMaker シーンへインポートする 接続された Matterport アカウントを選択し、Matterport スキャンをシーンに追加してください。以下の手順に従って、Matterport スキャンとタグをインポートします。 AWS IoT TwinMaker コンソール にログインします。 Matterport スペースを使用したい新しい AWS IoT TwinMaker シーンを作成するか、既存のシーンを開きます。 シーンが開いたら、 Settings に移動します。 Settings の 3rd party resources の下で、 Connection name を見つけ、 Matterport の認証情報を AWS Secrets Manager に保管する の手順で作成したシークレットを入力します。 次に、 Matterport space ドロップダウンリストを展開し、Matterport スペースを選択します。 図 7: Matterport スペースをインポートする Matterport のタグをインポートすると、Update tags ボタンが表示されます。AWS IoT TwinMaker で Matterport のタグを更新すると、Matterport アカウントの最新の変更が常に反映されます。 シーン内のタグを選択します。このタグにエンティティとコンポーネントを関連付けることができます (手順については、 モデルシェーダー拡張 UI ウィジェットをシーンに追加する のユーザーガイドに従ってください)。 図 8: タグにエンティティを関連付ける Matterport スペースを AWS IoT TwinMaker の Grafana ダッシュボードで表示する Matterport スペースを AWS IoT TwinMaker シーンにインポートすると、Amazon Managed Grafana ダッシュボードで Matterport スペースを含むシーンを表示できます。既に Amazon Managed Grafana を AWS IoT TwinMaker と統合している場合は、Grafana ダッシュボードを開いて、インポート済みの Matterport スペースを含むシーンを表示できます。 まだ AWS IoT TwinMaker を Amazon Managed Grafana 向けに設定していない場合は、そのプロセスを先に完了してください。 AWS IoT TwinMaker を Grafana と統合する際には、2 つの選択肢があります。セルフマネージドの Grafana 環境を使用するか、Amazon Managed Grafana を使用するかです。 次のドキュメントを参照して、Grafana のオプションと統合プロセスの詳細を確認してください。 AWS IoT TwinMaker の Grafana ダッシュボード統合 Amazon Managed Grafana セルフマネージドの Grafana Matterport スペースを AWS IoT TwinMaker Web アプリケーションで表示 AWS IoT Application Kit の Web アプリケーションで、Matterport スペースを含むシーンを表示できます。AWS IoT Application Kit の使用方法の詳細については、次のドキュメントを参照してください。 AWS IoT TwinMaker と AWS IoT Application Kit を使用する方法の詳細については、 AWS IoT TwinMaker UI コンポーネントを使用してカスタマイズされた Web アプリケーションを作成する を参照してください。 AWS IoT Application Kit の詳細については、 AWS IoT Application Kit GitHub ページを参照してください。 AWS IoT Application kit を使用して新しい Web アプリケーションを開始する方法については、 IoT App Kit 公式ドキュメントページを参照してください。 図 9: Matterport を使用した 3D 可視化によるデジタルツインのダッシュボード 図 9 は、AWS IoT Web アプリケーション内の Matterport スペースの 3D 可視化をするダッシュボードです。Amazon Monitron から収集したデータがアラーム状態とともにダッシュボードに表示されています。また、センサーの位置と状態が Matterport 3D 可視化に表示されます。これらの可視化により、現場の保全チームはダッシュボードから直接問題箇所を特定できます。 Amazon Bedrock による生成 AI チャットボットを使用したナレッジへのアクセス テレメトリーの取り込みに加えて、組織には数千ページにわたる標準操作手順、マニュアル、および関連文書が存在する可能性があります。メンテナンスイベントの発生中には、適切な指示を検索および特定するために貴重な時間が失われます。第 3 回のブログでは、生成 AI およびチャットボットなどのインターフェイスを使用することで、既存のナレッジベースの価値を引き出す方法を示す予定です。また、 Amazon Bedrock を使用して、ナレッジベースにより簡単にアクセスできるようにし、ニアリアルタイムな履歴データからの洞察や、Amazon Monitron によるメンテナンスに関する予測を含める方法についても説明予定です。 図 10: Matterport による 3D 可視化と AI アシスタントを備えたデジタルツイン 結論 このブログでは、Matterport の空間内で 3D 表現として視覚化されたテレメトリデータの統合ビューを作成するために、Amazon Monitron からのデータを接続する AWS IoT TwinMaker を使ったソリューションを概説しました。Amazon Monitron は予知保全のためのガイダンスを提供し、AWS IoT TwinMaker では 3D 空間でデータを可視化できます。このソリューションでは、データをコンテキストに応じた方法で提示することで、設備保全のオペレーション改善に役立ちます。デジタルツインの没入型の視覚化を活用したリアルな表現によって、設備保全チーム内のコミュニケーションとナレッジトランスファーも改善できます。また、設備保全チームが課題を特定し、解決策を見つけるプロセスを最適化することもできます。 この連載の最後のブログである「Amazon Monitron, AWS IoT TwinMaker, Amazon Bedrock を用いた予知保全のためのデジタルツインの構築 第 3 部: 生成 AI チャットボットでナレッジにアクセスしてデジタルツインを拡張」では、生成 AI インターフェース (チャットボット) を使用し、情報により簡単にアクセスできるようにします。 この記事はソリューションアーキテクトの中西 貴大が Garry Galinsky, Yibo Liang による記事 Optimize industrial operations through predictive maintenance using Amazon Monitron, AWS IoT TwinMaker, and Amazon Bedrock を翻訳したものです。

AWS では、常に顧客の変化するニーズに応えるためにサービスを革新し進化させています。この記事では、 Amazon CloudSearch と Amazon OpenSearch Service の違いを理解し、OpenSearch Service への移行方法を説明します。 Amazon CloudSearch と Amazon OpenSearch Service の比較 CloudSearch は、ウェブサイトやアプリケーション向けの検索ソリューションを簡単に設定、管理、スケーリングできるクラウドの完全マネージドサービスです。CloudSearch を使用すると、ウェブページ、ドキュメントファイル、フォーラム投稿、製品情報などの大規模なデータコレクションを検索できます。検索の専門家になったり、ハードウェアのプロビジョニング、セットアップ、メンテナンスを心配したりすることなく、検索機能を迅速に追加できます。データ量やトラフィックが変動しても、CloudSearch はニーズに応じてスケーリングします。CloudSearch は内部的にカスタマイズされた Apache Solr バージョンを使用しており、全文検索、ブーリアン検索、プレフィックス検索、タームブースティング、ファセット、ヒットハイライト、オートコンプリート候補などの機能をサポートしています。 OpenSearch Service は、ポピュラーなオープンソース検索・分析エンジンである OpenSearch のデプロイ、運用、スケーリングをシームレスに行えるマネージドサービスです。OpenSearch はベストな検索機能を提供し、CloudSearch のすべての検索機能に加えて、ベクトル埋め込みのセマンティック検索をサポートするベクトルエンジン、密ベクトルと疎ベクトルの両方のサポートを提供します。さらに、OpenSearch Service では、きめ細かなアクセス制御による高度なセキュリティ、オブザーバビリティとセキュリティのためのログデータの保存と分析、ダッシュボードとアラート機能が利用できます。CloudSearch のすべての機能とそれ以上のものが得られます。 OpenSearch Serverless では、改良された、すぐに使える、ハンズフリーの運用が可能です。CloudSearch と同様に、OpenSearch Serverless では REST エンドポイントを通じて OpenSearch をデプロイして使用できます。ドキュメントを OpenSearch Serverless に送信すると、OpenSearch REST API を使用して検索用にインデックスが作成されます。コストと遅延の最適化のためにインフラストラクチャをより深く制御したい場合は、OpenSearch Service のマネージドクラスターデプロイメントオプションを選択できます。マネージドクラスターでは、使用したいインスタンス、インデックス作成とデータシャーディング戦略などをきめ細かく制御できます。OpenSearch Service は、オープンソースの柔軟性と拡張性をもたらし、強力なクエリと分析機能を提供し、成長するワークロードに対してコスト効率の良いスケーラビリティを実現し、高可用性と耐久性を備えています。OpenSearch Service の機能と利点の詳細については、 Amazon OpenSearch Service をご覧ください。 OpenSearch Service への移行 CloudSearch から OpenSearch Service に移行する際は、データを OpenSearch Service に再取り込みしてインデックスを作成する必要があります。OpenSearch Service は REST API を使用するため、ドキュメントのインデックス作成には多数の方法があります。 curl のような標準クライアントや、HTTP リクエストを送信できるプログラミング言語を使用できます。さらに、プロセスを簡素化するために、OpenSearch Service には多くのプログラミング言語用の クライアント があります。データの取り込みには Amazon OpenSearch Ingestion の使用をお勧めします。OpenSearch Ingestion は、OpenSearch Service ドメインまたは OpenSearch Serverless コレクションにデータをルーティングできる、OpenSearch Service 向けに構築された完全マネージドのデータコレクターです。OpenSearch Ingestion は、 Amazon Simple Storage Service (Amazon S3) バケットや HTTP エンドポイントなど、さまざまなソースからデータを取り込むことができ、最も複雑なデータ変換ニーズに対応する豊富な組み込みプロセッサーのエコシステムを持っています。OpenSearch Ingestion はサーバーレスな性質を持ち、最も要求の厳しいワークロードの要件を満たすために自動的にスケールし、複雑なデータパイプラインの管理の複雑さを抽象化しながら、ビジネスロジックに集中できるようサポートします。OpenSearch Ingestion を使用して OpenSearch Serverless コレクションまたはマネージドクラスターにドキュメントを取り込む方法の詳細については、 Amazon OpenSearch Ingestion の使用開始 をご覧ください。OpenSearch Ingestion を使用して OpenSearch Service にデータを取り込む詳細情報については、 Amazon OpenSearch Ingestion を参照してください。 まとめ AWS は引き続き CloudSearch をサポートしており、セキュリティと可用性の改善に投資しています。しかしながら、OpenSearch の進歩による最新の検索機能を利用し、機械学習時代にユーザーが期待する急速な検索体験の進化に対応するためには、OpenSearch Service の検討をお勧めします。 About the Authors Arvind Mahesh は、Amazon Web Services の Amazon OpenSearch Service の Senior Manager-Product です。Analytics、Search、Cloud、Network Security、Telecom など、さまざまな分野で約 20 年の技術経験を持っています。 Jon Handler は、カリフォルニア州パロアルトを拠点とする Amazon Web Services の Senior Principal Solutions Architect です。Jon は OpenSearch と Amazon OpenSearch Service と密接に連携し、AWS クラウドに検索およびログ分析ワークロードを移行したいと考えている幅広い顧客にヘルプとガイダンスを提供しています。AWS に入社する前は、ソフトウェア開発者としてのキャリアで 4 年間、大規模な e コマース検索エンジンのコーディングに携わりました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号と博士号を取得しています。 本投稿はソリューションアーキテクトの榎本が翻訳いたしました。原文は こちら です。

はじめに コネクティッド・カー・プラットフォームを活用すれば、フリートオペレーターは車両の位置情報、使用状況、ステータスについてニアリアルタイムのデータを取得できます。このようなデータをすぐに利用できることは、フリートオペレーターがより効率的にフリートを管理、運用コストを削減、ドライバーのパフォーマンスを改善し、車両のダウンタイムを短縮できます。コネクティッド・カー・プラットフォームは、自動車メーカー (OEM) にとっても、自社の遠隔操作ソリューションを、優れた付加価値サービスとして法人顧客に提供する機会をもたらします。しかし、コネクティッド・カー・プラットフォームの構築には課題もあります。独自のデバイス・ソフトウェアを構築し、いつ、どのような条件でデータを収集かを指示するオーケストレーション機能を開発し、データを復号および処理し、最後にデータを整理してお客様に有用な分析情報を提供する必要があります。 AWS IoT FleetWise のような AWS サービスは、このような課題に伴う大きな負荷を軽減し、ソリューションを迅速に構築できます。 Volta Trucks は、イギリスのロンドンに本社を置く商用の電気トラックメーカーです。最近では、都市部での走行を想定した完全電気式の 16 トントラック Volta Zero を発表し、2024 年後半から納車を開始する予定です。Volta Trucks は、車両の予知保全、ルート最適化、パフォーマンス管理を提供するデジタル・カー・プラットフォームの立ち上げも控えています。このプラットフォームでは、データ収集とガバナンスを実現し、コストを削減、そして車両の運用を迅速に調整・改善できるデータ主導型の機能を提供します。リアルタイムのデータ分析により、Volta Trucks は生成 AI 機能を活用し、車両の稼働率、フリートマネージャーの生産性、ドライバーの快適性向上を図ります。 図 1: Volta Zero は、走行距離が最大 200km (125 マイル)、最高時速が 90 km/h (56 マイル/時) の電気トラック。 「当社の顧客は運送会社、フリートマネージャー、ドライバーで、柔軟性と個別化への要求はそれぞれ異なります。AWS IoT FleetWise を使えば、必要なデータに焦点を当てたデータ収集キャンペーンを構築し、顧客と車両ユーザー向けにカスタマイズした分析と機能を提供できます。必要な時に必要なデータだけを収集することで、新しいソリューションを構築し、ドライバーのミッション、コンテキスト、要求に合わせて車両を AI 化できるサービスを開発できるのです。」 –  Volta Trucks 最高技術責任者 兼 最高情報責任者 Martin Hofmann ソリューションの概要 Volta Trucks は、必要となる様々なデータポイントを車両から収集するコネクティッド・カー・プラットフォームを構築し、社内外の顧客のためにフリート全体の洞察を抽出する基盤を整えました。プラットフォームを構築する上での課題は、トラックから生成される膨大なデータの転送およびストレージコストを削減しながら、顧客に対して意味のあるニアリアルタイムの洞察を提供する方法を決定することでした。 Volta Trucks は、AWS の IoT FleetWise をプラットフォームの基盤としています。このプラットフォームでは、ルールベースのデータ収集が可能で、特定の車両タイプの温度や速度の変化などのパラメーターに基づいて、クラウドにデータを転送するためのルールやイベントを Volta Trucks が定義できます。Volta Trucks の顧客は、コネクティドカープラットフォームをアセット追跡に活用することが多く、電気トラック Volta Zero の重要な車両テレメトリと位置情報をニアリアルタイムで追跡する必要があります。 EV ラリー – ロンドンからジュネーブへ 機能のデモンストレーションとして、AWS IoT FleetWise 対応のコネクティッド・カー・プラットフォームに接続された Volta Zero は、ロンドンからジュネーブへ 2,000 km を超える往復の旅に成功しました。このイベントは、ゼロエミッションカーと技術の限界を試すために作られた EV ラリー  の一環として、6 月 22 日から 24 日まで行われました。以下の画像は、レース中に有効化された機能と、収集されたデータのタイプを示しています。例として、位置情報、気温、バッテリー残量などです。 図 2: 車両の地理位置情報。 図 3: 外気温、ブレーキと加速。 図 4: 充電状態 (SoC) のリアルタイム洞察とデータ収集。 ソリューションの手順 車両ドメインでは、Volta Trucks 社が Linux ベースの車載制御ユニット (TCU) 上に、AWS IoT FleetWise 用の Edge Agent を導入しました。同社の Edge Agent は オープンソース C ++ ライブラリのセット で、車両がクラウドに接続し、どのデータをどのような条件で収集するか、クラウドからの指示を受け取ります。 Volta Trucks の技術者は、クラウド上で AWS IoT FleetWise API を使用して、車両のナレッジグラフを作成し、車両全体でシグナル、センサー、アクチュエータの標準化されたデータディクショナリー (300 以上のデータポイント) を提供します。さらに、これらのデータポイントに対する復号ルールを設定し、それらを車両ドメインに渡すことで、AWS IoT FleetWise が生の バイトデータを人間が読めるデータに変換できるようになりました。最後に、時間ベースとイベントベースの両方のキャンペーンを使って GPS 位置情報、走行距離計の読み取り値、バッテリーの状態などのデータを定期的に収集するため、 AWS IoT FleetWise を使用しました。 一つずつ手順を見ていきましょう: Volta の AWS IoT FleetWise Edge エージェントが車両にデプロイされます。 AWS IoT Core を使用して車両と AWS 間の接続が確立されます。 AWS IoT FleetWise は、AWS IoT Core の接続を使用して、データキャンペーンと復号情報を車両にプッシュします。クラウド上で、AWS IoT FleetWise はキャンペーンや車両識別子と、タイムスタンプ情報を追加することでデータを強化します。 AWS IoT FleetWise は、  Amazon CloudWatch にサービス・メトリクスとログを自動的に収集することで、チームが必要に応じて簡単にトラブルシューティングを行えるようにしています。 収集された車両データは、 Amazon Timestream と Amazon S3 へ送信されます。その後、データに対して自社の分析と洞察のプラットフォームで問い合わせ及び分析を行います。 Volta チームは、トラックが切断され、再接続したタイミングを追跡するための簡単なアラートシステムも設定しています。このアラートでは、AWS IoT Core の ライフサイクルイベント を使用し、これらのイベントを ルール を使って Amazon SNS トピックにパブリッシュしています。オペレーターは、このトピックをサブスクライブできるため、車両が長時間接続されていない場合に適切な対応ができます。 Volta は ARM ベースの Graviton インスタンス に、テスト目的で AWS IoT FleetWise エージェントをデプロイし、車両をシミュレートすることで開発のフィードバックサイクルの短縮を可能にしています。 まとめ Volta Trucks は、 AWS IoT FleetWise を活用することでコネクテッド・カー・プラットフォームを構築し、商用車両の顧客に対して、ニアリアルタイムで車両の追跡、運転手の行動監視、車両の状態と健全性の評価などの機能を提供することができるようになりました。 Volta Trucks は、 AWS のサービスを活用することで、このような機能を迅速に開発することができ、スケーラビリティを実現するために開発を繰り返し行うことで、市場投入までの時間を短縮することができました。詳しくは、 AWS IoT FleetWise サイトをご覧ください。皆様からのご意見・ご質問をお待ちしています。 About the Authors Akshay Tandon は、Amazon Web Services のAWS IoT FleetWise チームのプリンシパル・プロダクト・マネージャーです。あらゆる自動車とプロダクトに情熱を持っており、顧客の声に耳を傾け、ニーズを満たすための革新的な製品やサービスを構想することに喜びを感じています。 Amazon では、Akshay は Alexa による AI/ML 分野と、Amazon Transportation Services によるフリート管理分野での製品イニシアチブを主導してきました。 10 年以上の製品管理の経験があります。 Nuno Seco は、AWS を活用することでスタートアップ企業の成長を加速できるよう支援するシニア・ソリューション・アーキテクトです。 25 年以上のソフトウェア エンジニアリング経験を持つ彼は、様々なトレードオフを理解し、スタートアップ企業が十分な情報に基づいて適切な意思決定が行えるよう支援しています。 Marco Massara は、AWS 自動車および製造業ビジネスユニットのプリンシパル・ビジネス・デベロップメント・マネージャーであり、ソフトウェア・デファインド・ビークルとコネクテッド・モビリティに関する主要な取り組みで EMEA の自動車顧客を支援しています。 この記事は Akshay Tandon, Nuno Seco, Marco Massara によって書かれた How Volta Trucks built a connected vehicle platform using AWS IoT FleetWise の日本語訳です。この記事は 広域事業統括本部 ソリューションアーキテクト 久次米が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 みなさん他国のAWS Summitはチェックされていますか？先日行われたAWS Summit New York 2024ではAmazon BedrockやAmazon Qに関連した多くの生成AI機能が発表されました。そこで発表された機能をいくつかのデモを交えてご紹介するセミナーが予定されています。ご都合つけばぜひご参加ください。 2024年8月1日 10:00-11:00 – AWS の生成 AI 最新機能をキャッチアップ！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年7月22日週の主要なアップデート 7/22(月) Amazon VPC IPAM now supports BYOIP for IPs registered with any Internet Registry Amazon VPC IPAMが任意のインターネットレジストリに登録されたIPアドレスのBring Your-Own-IPをサポートしました。BYOIP を設定する際、AWS は、お客様が AWS に持ち込む IP アドレス空間をお客様が管理していることを検証しますが、これまでIPAMは登録データアクセスプロトコル（RDAP）による検証のみをサポートしていましたが、すべてのインターネットレジストリがサポートしているわけではありませんでした。DNS レコードを使用してIPアドレスが自分のものであることを確認できるようになったためJPNIC、LACNIC、AFRINICなど、これまでサポートされていなかったインターネットレジストリでもBYOIPが可能になります。この機能は中国を除くすべてのAWSリージョンで利用できます。詳細はIPAMの ドキュメント をご確認ください。 Amazon MQ now supports quorum queues for RabbitMQ 3.13 Amazon MQがquorum queuesをサポートしました。quorum queuesはRabbitMQが提供するデータ一貫性と耐障害性に優れたキューのタイプで、従来のmirrored queuesと比較して最大2倍、スループットが向上します。Amazon MQでquorum queuesのサポートはRabbitMQ 3.13以降のみで、Amazon MQが利用可能なすべてのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Connect Contact Lens now provides generative AI-powered summaries within seconds after a contact ends Amazon Connect Contact LensのAIを活用した問い合わせ後の概要生成が、これまでの数分から数秒へとパフォーマンス向上しました。これにより連絡後にスムーズにアフターコールの作業に取り掛かれる他、APIやKinesis Data Streamsを介してCRMシステムとの連携も可能です。この機能は米国西部（オレゴン）および米国東部（バージニア北部）の2つのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon DocumentDB announces improvements to document compression Amazon DocumentDB(MongoBD互換)がクラスターの既存のコレクションへの圧縮や、コレクションごとの圧縮閾値の設定など機能強化されました。これまでは新しい圧縮コレクションを作成し移行する必要がありましたが、今回のアップデートによりそれをせずとも既存のコレクションを圧縮し、最大7倍のサイズ縮小を行うことでストレージコスト、I/Oコストの削減、クエリパフォーマンス向上が見込めます。これらの機能向上はDocumentDBが利用可能なすべてのリージョンのDocumentDB 5.0 インスタンスベースのクラスターでサポートされます。詳細については ドキュメント をご確認ください。 Amazon DocumentDB now supports change streams on reader instances Amazon DocumentDB(MongoBD互換)がリーダーインスタンスでの変更ストリームをサポートするようになりました。これによりライターインスタンスの負荷を軽減できます。変更ストリームはリーダー、ライター間で共有できるため、クラスターフェイルオーバーやメンテナンス中は任意のDocumentDBインスタンスから変更ストリームを再開できます。このアップデートはAmazon DocumentDB 5.0インスタンスベースのクラスターと、Amazon DocumentDB がサポートされているすべてのリージョンにあるグローバルクラスターで利用できます。 詳細は ドキュメント をご確認ください。 7/23(火) Meta Llama 3.1 generative AI models now available in Amazon Bedrock Meta社のLlama 3.1がBedrockで利用できるようになりました。Llama 3.1には8B, 70B, 405Bのパラメーターサイズのモデルがあり、405Bは現時点で公開される中で最高かつ最大の基礎モデルの1つです。Llama 3.1はLlama 3の16倍の128Kのコンテンツ長をサポートしておりより複雑なコンテキストを前提とした会話に対応できる他、8つの言語での多言語対話の推論が改善されています。Llama 3.1モデルは、米国西部 (オレゴン) リージョンでご利用いただけます。405Bは当初はプレビューでしたが、現在はGAしています。（7/26のアップデートも参照）詳細については ドキュメント と ブログ をご確認ください。 Meta Llama 3.1 generative AI models now available in Amazon SageMaker JumpStart 一つ前で紹介のAmazon Bedrockと同様にAmazon SageMaker JumpStartでもLlama 3.1が利用できるようになりました。SageMaker Studioから数クリックで、またはSageMaker Python SDKでプログラム経由でデプロイして利用することも可能です。SageMaker JumpstartでのLlama 3.1は米国東部 (オハイオ)、米国西部 (オレゴン)、および米国東部 (バージニア北部)の３つのリージョンで利用可能です。詳細は ドキュメント と ブログ をご確認ください。 Amazon EKS introduces new controls for Kubernetes version support policy Amazon EKSのKubernetes バージョンポリシーの新しいコントロールが発表されました。これによりEKSの延長サポートを利用するかどうかをクラスター単位で設定できるようになり、延長サポートを適用したくないクラスターは標準サポート終了時に自動的にアップグレードの対象になるよう設定することが可能です。これによりコスト最適化が可能です。この機能はすべてのAWSリージョンで利用できます。詳細は ドキュメント をご確認ください。 AWS Mainframe Modernization Code Conversion with mLogica is now generally available AWS Mainframe ModernizationのmLogicaによるコード変換が一般提供開始されました。mLogicaとAWS M2の連携は昨年のre:Inventで発表されていましたが、mLogicaはアセンブラで記載されたレガシーコードをCOBOLに自動変換するプロダクトです。多くのメインフレーム環境にはCOBOLに限らず保守が難しく費用がかかるアセンブラコードが含まれており、この機能追加によりメインフレームモダナイゼーションにおけるブロッカーを排除することが可能です。詳細は ドキュメント をご確認ください。 7/24(水) AWS Signer open sources Notation plugin for container image signing コンテナイメージの署名に利用するNotation用のAWS Signerプラグインがオープンソース化され公開されました。これによりAWS Signerを利用してどのようにコンテナイメージの署名、検証がされているのか確認できるようになりました。オープンソースとして公開されたことで、たとえばGoLangライブラリとして追加することで実行ファイルとしてインストールして呼び出す必要がなくなります。AWS Signer プラグインはApache 2.0 ライセンスとして管理されます。詳細は GitHubのリポジトリ や ブログ をご確認ください。 Mistral Large 2 foundation model now available in Amazon Bedrock Mistral Large 2（24.07） foundation modelがAmazon Bedrockで一般提供開始されました。このモデルはMistral AIの主力モデルの最新バージョンであり、英語、フランス語、ドイツ語、スペイン語、イタリア語、中国語、日本語、韓国語、ポルトガル語、オランダ語、ポーランド語、アラビア語、ヒンディー語など、数十の言語で情報をシームレスに処理できます。コンテキストウィンドウも前バージョンの32kから128kに拡大され、より多くの情報を処理することが可能です。Mistral Large 2は米国西部 (オレゴン) リージョンの Amazon Bedrock でご利用いただけます。詳細については、 ローンチブログ もご確認ください。 AWS DataSync expands support for agentless cross-region data transfers to include opt-in regions AWS DataSyncがリージョン間でのクロスリージョンデータ転送をエージェントレスで実行できるようになりました。DataSyncはデータ転送にあたりエージェントをデプロイ・管理する必要がありましたがそれが不要になり、オペレーションを簡素化することができます。また、対象のリージョンにはオプトインリージョンも含まれます。この機能はData Syncが利用可能なすべてのAWSリージョンで利用可能です。詳細は ドキュメント もご確認ください。 7/25(木) Announcing 24 months support for Amazon EMR Amazon EMRのリリースバージョンサポートについてアナウンスがありました。今後、EMRはリリース日から24ヶ月間の標準サポート対象となります。この期間はセキュリティ、バグ、データ破損などの関連する重大な問題に対して、アップストリームの修正取り込みに90日以内の目標が設定されます。24ヶ月を過ぎたバージョンは12ヶ月間のサポート終了段階(EoS)に入ります。EoSの期間は、クラスターへのアクセスは引き続き可能ですが、テクニカルサポートやアップストリームの取り込みに関して制約があります。EoS終了後にサポート終了(EoL)となります。特に現在稼働するバージョンなど例外的な期間が設定されている場合がありますので、ライフサイクルの詳細や各バージョンの時期一覧などは ドキュメント の記載をご確認ください。 AWS Step Functions now supports Customer Managed Keys AWS Step Functionsが、KMSで管理する顧客鍵を使ったステートマシンとアクティビティリソースの暗号化に対応しました。ワークフロー定義や実行データを暗号化できるため、より機微なシステムにおいてもご活用いただけるようになります。昨日の詳細については Step Funitonsのドキュメント と KMSのドキュメント をご確認ください。 Amazon SageMaker launches faster auto-scaling for Generative AI models Amazon SageMaker Inferenceが生成AIのモデル呼び出し需要に応じてこれまでより高速にオートスケールできるようになりました。この機能はCloudWatchのメトリクス（モデルごとの同時リクエストと、モデルコピーあたりの同時リクエスト数）を元にします。10秒間隔で出力されるこのメトリクスを元に、オートスケーリングポリシーで定義した閾値に達した場合1分以内にインスタンスまたはモデルコピーの追加を開始します。この機能は中国とAWS GovCloud (米国)を除く Amazon SageMaker Inference が利用可能なすべての AWS リージョンのアクセラレータインスタンスファミリー (g4dn、g5、g6、p2、p3、p4d、p4、p5、inf1、inf2、trn1n、trn1) で利用可能です。詳細は ブログ もご確認ください。 AWS Clean Rooms launches new capabilities for entity resolution, ML modeling, privacy, and analysis controls AWS Clean Roomsで AWS Entity Resolution の一般提供、データ分析のプライバシー管理機能の追加、分析結果を受け取るコラボレーターを設定する機能、SQLを使用して類似モデリング用のシードデータを生成する機能の４つのアップデートがありました。AWS Entity Resolutionの統合により複数データソースのレコード照合や重複排除が容易になる他、SQLの特定の出力列の制御や、分析結果を受け取るコラボレーターを簡単に選択可能になるなどプライバシー管理機能の強化によりセキュアな情報を保護しながらより柔軟に使用できるようになりました。詳細に関しては ブログ をご確認ください。 7/26(金) Meta Llama 3.1 405B now generally available in Amazon Bedrock Meta社のLlama 3.1 405BがBedrockで一般提供が開始されました。7/23(火)の時点では405Bのモデルはプレビューとしてアクセスリクエストが必要でしたが、正式に一般提供がされた形です。他のLlama 3.1モデル同様、提供リージョンは米国西部（オレゴン）となっています。詳細については ローンチブログ もご確認ください。 最後に、冒頭に紹介したAWS の生成 AI 最新機能をキャッチアップ！8月8日に「最新事例からはじめる生成AI活用」が開催されます。金融から製造まで様々な業種の事例やデモをご紹介予定です。よかったらこちらもチェックしてみてください。 2024年8月8日 14:00-16:00 – 最新事例からはじめる生成AI活用 それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本ブログは、RIZAP テクノロジーズ株式会社と Amazon Web Services Japan が共同で執筆しました。 RIZAP グループ は、現在約 1500 店舗まで拡大した chocoZAP 事業や、約 60 社のグループ企業を持つ RIZAP グループの各事業において、従業員向けの資料や手順書が膨大な量になっていたことから、ドキュメントやマニュアルの所在を探すのが難しく、現場業務の効率化が課題となっていました。 そこで同社は、社員が自身で質問できる「社内問い合わせ検索システム( AI チャットボット)」の開発を決めました。このシステムでは、生成 AI を活用し、従業員からの質問に対して対話形式で分かりやすい回答を自動生成します。 具体的な利用方法は、従業員がチャットボットに質問を入力すると、生成 AI モデルがその質問に対する最適な回答を社内文書から探し出し、自然な文章として出力します。   写真 1 : ライザップ店舗 システム構成について この AI チャットボットのシステム構成は、以下のようになっています。 フロントエンド側では、 Amazon Route 53 、 Amazon CloudFront 、 AWS WAF などを用いてウェブアプリケーションを構築し、 AWS Certificate Manager による SSL/TLS 証明書の発行や DNS 設定も行っています。 バックエンド側では、 Amazon API Gateway と AWS Lambda を経由して、 Amazon Kendra が Amazon S3 のデータソースや FAQ を参照しながら自然な回答を生成します。さらに、一部のプロンプトに対しては Amazon Bedrock が動作するようになっています。 図 1 : 全体アーキテクチャ   また、社内の業務データを保存している Microsoft SharePoint から S3 にアップロードされたファイルは、Lambda と SharePoint API を使って S3 に自動で転送されるようになっています。社内の閉じられた環境の中で保有しているデータを活用した RAG( Retrieval Augmented Generation: 検索拡張生成 )の構成で構築しており、社内独自の RIZAP のトレーナー、従業員が見るマニュアル（店舗業務：ボディメイク、マシンメンテナンス、商品等、全店通達、福利厚生、研修）など約 3000 ファイルが検索対象のデータとなっています。そのデータは PDF、Word、Excel、PowerPoint など様々な形式がありますが、そのまま S3 に保管するだけでよく、あとは定期的に Kendra がクロールする仕組みを設定しているのみです。 こうした構成により、RIZAP グループの業務効率化が実現されています。一次問い合わせをチャットボットで処理することで、従業員が情報へのアクセスに要する時間を大幅に削減できます。さらに、新人社員やアルバイトの立ち上がり工数の削減にも役立っています。従来は上司や先輩に質問する必要がありましたが、「社内問い合わせ検索システム( AI チャットボット)」を使えば自力で情報を得られるようになりました。 写真 2 : ライザップジム内写真 このシステムの導入によって業務の効率化が進み、月あたり約400 件(平均対応時間 20 分/件)あった業務ヘルプへの問い合わせが削減され、顧客満足度の向上にもつながったと評価しています。必要な情報にすばやくアクセスできるようになり、より質の高いサービスを提供できるようになったからです。 開発を手がけた同社のプロダクト開発統括 2 部 部長の永嶋義憲氏は「AWS との協業により、AWS Associate レベルの開発者 2 名が約 1 か月で開発を完了できました」と語っています。生成 AI と AWS の各種サービスを組み合わせることで、短期間で革新的なソリューションを構築できたことがうかがえます。 生成 AI ソリューションの運用について 現在は RIZAP の実証実験の対象店舗でトレーナー向けに利用を開始しており、業務部門 3 名、IT 部門 3 名で体制を組み、全社展開に向けて週次で精度改善を行っています。入力ワードを週単位でリスト化し、そのワードに対して適切な返答ができているかを確認し、不足している情報があれば、追加でデータを補完することを店舗責任者とともに継続的に行っています。導入しておしまいではなく、日々変わっていくビジネスにも追随させていくことも生成 AI ソリューションには必要になります。店舗責任者と密な連携が取れており、常にフィードバックを得ながら情報連携し、精度改善だけでなく、機能の改善をしているところが、成功の要因と考えています。 追加機能として、回答に対する評価が入力できるような、Like/Dislike ボタンや、精度に関する運用ダッシュボードについても検討しています。 今後の展望 現在 RIZAP 店舗の全国 120 店舗への本ソリューション展開にむけて、対象店舗での導入が始まり、日々精度改善を行いながら機能拡張を行っています。次のステップとしては、RIZAP グループのアパレルを扱う JEANS MATE （ジーンズメイト）や、インテリア雑貨を扱う HAPiNS （ハピンズ）などの店舗においても、本生成 AI ソリューション導入を計画しています。これから対象店舗拡張に伴う、本ソリューションの耐久性やコスト増についても対応を進めており、Claude３への切り替えも視野にいれています。 さらにデータソースの拡充を予定しており、社内システムや各種ツールからのデータ連携の開発を予定しています。 図2 : 効果と注意点スライド   また現在は、社内業務改善での生成 AI の活用をしていますが、今後は chocoZAP などの一般利用者を対象として生成 AI ソリューションも検討をしています。 まとめ RIZAP の取り組みは、生成 AI がビジネスの課題解決に貢献できる有力なテクノロジーであることを示した好例と言えるでしょう。生成 AI を活用したイノベーションにより、業務効率化と顧客サービス向上を同時に実現できることが実証されました。今後も、さまざまな業界や分野で生成 AI の活用事例が増えていくことが期待されます。フィットネスに限らず、店舗ビジネスに共通した課題の解決に役立つ仕組みになっており、生産性の向上と顧客満足度の改善に寄与することができます。企業は、このテクノロジーを積極的に取り入れ、競争力の強化につなげていくことが重要だと考えています。 著者について 戸塚 智哉 戸塚智哉は、飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 先週の月曜日、7 月 22 日に発表した「 AWSジャパン生成AI実用化推進プログラム 」ですが、たくさんのお客様に興味を持って頂いています。ありがとうございます。 Webページ のフォームから意思表明をしていただくこともできますが、AWSのお客様担当がついている場合は、担当に声をかけていただく形でもOKです。最初にどういう課題の解決を目指すのかをクリアにして、その上で最適なアプローチを考える仕組みになっていますので、ぜひご検討ください。 また、8 月 8 日には「 最新事例からはじめる生成AI活用 」というイベントを開催します。生成AIの活用に取り組む際は、なにをどう解決するかが最も重要です。その助けになるのは事例で、事例をベースにしつつ自分達の目標を定めるやり方は、有効なアプローチのひとつです。 それでは、7 月 22 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AWS Trainium、AWS Inferentia が AWS 上の Llama 3.1 モデルに高性能と低コストを提供」を公開 AWSが機械学習のために開発したアクセラレータLlama 3.1モデルのファインチューニングや推論に対応しています。この記事ではLlama 3.1をトレーニング用のAWS Trainiumと、推論用のAWS Inferentiaで稼働させる方法を解説します。以前の記事ではLlama 3をTrainium/Inferentiaのインスタンスにデプロイする方法を説明しましたが、今回はLlama 3.1です。各種サンプルコードも用意していますので、ぜひ触ってみてください。 ブログ記事「AWS Step Functions ワークフローによる Amazon Bedrock モデルカスタマイズの自動化」を公開 Amazon Bedrock では用途に応じて様々な基盤モデルを選択して利用することができますが、独自のデータを利用して基盤モデルの応答をカスタマイズすることで、さらに目的に沿った出力を得ることができるようになります。このブログ記事は、分散アプリケーションのワークフローを制御する AWS Step Functions を利用し、Bedrockで稼働するモデルのカスタマイズを自動化する方法を解説しています。サンプルコードもついていますので、実際に動かしてみることもできますのでぜひ試してみてください。 連作ブログ「生成 AI で加速する e コマースの変革」を公開 eコマース業界のお客様でも、生成AIの利活用はホットなトピックになっています。この連作ブログは「 その1 」として典型的な課題とその解決案を整理し、「 その2 」で解決策の実装サンプルとしてAWS Summit Japanで展示したデモの解説を行っています。差別化につながらない作業の削減と、顧客体験のパーソナライズがテーマとして取り上げられていますので、eコーマス業界以外の方にも参考になるかもしれませんので、ピンときたらぜひご一読を。 ブログ記事「【開催報告】生成AI ユースケース創出 Boot Camp in 大阪」 6月末にAWSジャパンの大阪オフィスで「生成AIユースケース創出 Boot Camp」というイベントを開催しました。このブログはそのイベントのレポートです。AWSから情報共有を行うセッションはもちろん、お客様による事例登壇やハンズオンなど盛りだくさんのコンテンツでお送りました。一部のセッションについては資料も公開されていますので、ぜひごらんください。 サービスアップデート Amazon BedrockでMeta Llama 3.1が利用可能に Amazon BedrockでMeta社のLlama 3.1をオレゴンリージョンにてご利用頂けるようになりました。Llama 3.1は8B、70B、405Bのモデルが用意されており、用途に応じて最適なものを選択して利用することができます。Meta社によるとLlama 3.1は一般的な知識の解答、数学、ツールの利用、多言語翻訳に必要な機能を提供するとされています。 ブログ記事 もあわせてどうぞ。ちなみに発表当日は405Bについては限定プレビューでしたが、現時点では 一般利用開始 になっています。 Amazon SageMaker JumpStartにてMeta Llama 3.1が利用可能に トレーニング済みのモデルを即座に起動し、開発や利用を素早くはじめられるAmazon SageMaker JumpStartでもMeta社のLlama 3.1をご利用頂けるようになりました。リージョンはバージニア、オレゴン、オハイオとなります。 ブログ記事はこちら です。 Amazon BedrockでMistral Large 2が利用可能に Mistral AIのMistral Large 2(24.07)モデルをAmazon Bedrockでご利用頂けるようになりました。このモデルは日本語や英語をはじめとする数十の言語の処理に対応し、会話、コーディング、推測、指示に応じた動作の精度が向上しているとのことです。Mistral Large 2(24.07)はオレゴンのリージョンでご利用頂けます。 ブログ記事はこちら をご覧ください。 Amazon SageMakerの推論エンドポイントにおいて素早くオートスケーリングを発動可能に Amazon SageMakerで2つのメトリクスの情報取得頻度が詳細化され、これによって推論リクエストに応じたインフラストラクチャの自動スケーリングをより素早く実行できるようになりました。負荷の増加が発生すると、1分以内に新しいインスタンスの起動やモデルのコピーを開始し、負荷に対応できるリソースを準備します。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 本日 7 月 22 日に、 2つのウェブサイトを公開しました。 日本の生成AI活用を支援 このウェブサイトは、生成AIの利活用に取り組む方のための情報ポータルで、日本国内の事例やユースケース、サービスアップデート情報、ベストプラクティスなどをまとめます。生成AIに関するワンストップの情報源としてご利用頂けるものです。 AWSジャパン生成AI実用化推進プログラム こちらは 6 月 20 日、21 日に開催した AWS Summit Japan の基調講演で予告した、生成AIによってビジネス課題解決に取り組むお客様を支援するためのプログラムのサイトです。プログラム概要とともに、参加希望を表明するためのフォームもご用意していますのでぜひご覧ください。 また、AWS ブログでは 7 月 10 日、11 日に開催した AWS Summit New York のアップデートに関するブログ記事の翻訳が各種出そろっています。先週概要をご紹介したので改めてピックアップするのはやめておきますが、 「AWS Summit New York」のカテゴリ で絞り込んでいただくと一覧できますので、こちらもあわせてどうぞ。 それでは、7 月 15 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 丸紅株式会社様、社内生成AIプラットフォームアプリで業務時間削減と業務高度化を実現 丸紅株式会社 様は、社内生成AIプラットフォームアプリ(Marubeni Chatbot)を展開しています。Marubeni Chatbotはファイルチャットアプリ、音声認識チャットアプリ、カスタムボットアプリなど複数の機能を提供し、社内で既に7,500名以上のユーザが利用しているそうです。内部的にRAG(検索拡張生成)を活用しているのですが、精度や一貫性を保つための工夫として、WordやPDFで記載された文書をMarkdown形式に自動変換する工夫をしていることや、LangChainを利用せず自社開発の抽象化レイヤーを用いている点がユニークです。導入効果については、業務ごとにばらつきはありますが25%-65%の時間削減効果があり、業務の内容が高度化したというフィードバックが得られています。今後、経営判断の高度化に活用することを目指した機能拡充を進めているとともに、AIを使い倒す企業文化の醸成をすすめているそうです。 AWS生成AI国内事例ブログ: jinjer株式会社様、ユーザ体験向上のための人事問い合わせAI機能を3ヶ月で開発 jinjer株式会社 様は、人事関連業務の効率化を支援する「 ジンジャー 」というSaaSサービスを展開しています。カスタマーサクセスのチームがお客様からヒアリングしたところ、従業員が必要な情報を探す手間がかかる、情報が見つからない場合は人事担当者が対応するがその工数が少なくない、という課題があることがわかりました。その解決のため、生成AIによる問い合わせ対応機能の開発を決断されました。Amazon BedrockとAmazon KendraによるRAG(検索拡張生成)の仕組みですが、3ヶ月という短期間での開発に成功し、AIによる問い合わせ対応機能により80%の工数削減を見込んでいます。また、フルマネージドサービスの活用による保守運用負荷の軽減もひとつのポイントです。今後の計画として、マルチモーダルなモデルを活用した新機能の開発に取り組んでいらっしゃるとのことです。 ブログ記事「生成AIアプリケーションのデータベース選択における重要な考慮事項」を公開 生成AIを搭載したアプリケーション、特に検索拡張生成(RAG)を活用する場合は、何らかのデータベースが必要不可欠です。AWSでは様々なデータベースサービスでベクトル検索の機能をご提供しています。この記事では、今現在AWSでご利用可能なベクトル検索機能を備えたデータベースサービス群について、動作とパフォーマンスの差異を整理することで、お客様のワークロードに最適なサービスを選択するための情報を提供しています。 ブログ記事「製造イノベーションの強化：AI と生成 AI の Centers of Excellence (CoE) がモダナイゼーションを推進する方法」を公開 製造業のお客様向けの翻訳記事を公開しました。製造業におけるAI導入への課題を整理し、AIによってビジネスの変革を導くためにリーダーシップチームに求められる役割、AI CoE(AI導入の推進チーム)がいかにして組織としてのAI活用に貢献できるかをご説明しています。 ブログ記事「GENIAC における計算リソース提供者として AWS が選定されました」を公開 7月16日に公募が開始された、経済産業省と国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO)が推進するGENIAC(Generative AI Accelerator Challenge)のリソース提供者としてAWSが選定されました。今回の選定についてのAWSの思いや、AWSに対して頂いたコメントを掲載しています。 サービスアップデート Amazon SageMaker Canvasでファインチューニングした基盤モデルを本番環境で活用可能に Amazon SageMaker Canvasはコーディング不要で、機械学習による正確な予測や生成AIの機能を活用できるサービスです。SageMaker CanvasではAmazon Titan ExpressやFalcon-7B-Instructなどのモデルに対して、Amazon BedrockとAmazon SageMaker JumpStartを介した基盤モデルのファインチューニングができるようになっています。今回、SageMaker Canvasでファインチューニングを行った基盤モデルについて、SageMakerの推論エンドポイントにデプロイができるようになりました。これによりSageMaker Canvasで作業した成果を、他のサービスで実行されるアプリケーションに組み込むことが容易になりました。 AWS IAM Identity CenterでAmazon Q Developerのセッション時間を他と独立した値に設定可能に AWS IAM Identity CenterでAmazon Q Developerのユーザ認証に適用されるセッションの持続時間を、他のサービスからのセッション持続時間とは独立して設定できるようになりました。例えば、Amazon Q Developerには90日間のセッション持続時間を、他のサービスには15分間を、という個別の設定ができるようになり、ユーザ体験の最適化が可能です。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

お客様は、リポジトリのクローニング、ミラーリング、または特定のブランチの移行など、さまざまな方法を使用して 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 クラウドの真のポテンシャルを引き出すことができるようサポートしています。 本ブログはソリューションアーキテクトの銭 敏娟が翻訳しました。原文は こちら です。