みなさん、こんにちは。流通・小売・消費財業界のお客様を中心に技術支援を行っているソリューションアーキテクトの千代田と吉田です。 AWS Summit Japan が 2024 年 6 月 20 日、21 日の 2 日間、幕張メッセにて開催されました。 今回はその中から、「新価格体験を実現する次世代自販機」というタイトルの展示内容をご紹介します。この展示では、消費財企業にとって重要な D2C (Direct to Consumer) の販売チャンネルである自動販売機 (以下、自販機) をオンライン化することによって進化させて、在庫や周囲環境の状況に合わせて販売価格を最適化するダイナミックプライシングのアイデアを紹介しました。本記事ではその内容を解説させていただきます。 自販機から生まれる新たな価値 全国の自販機は飲料自販機だけでも 220 万台（2023年末時点）で、スーパー 23,000 店や、コンビニ 56,000 店よりはるかに多く、最大の顧客接点と言えます。消費財企業にとって重要な D2C の販売チャンネルである自販機は技術進化して多様化が進み、無人店舗のソリューションとして消費財メーカー、小売業の両方において、いろいろな場所で、いろいろなものを販売する試みがなされています。一方で、自販機は最大の D2C チャネルでありながら、小売店舗での販売よりも収益向上のための施策の実施が困難だと言われてきました。これは、価格が固定のためにキャンペーンなどによる収益向上が難しい、商品販売以外の新しいビジネスモデルが生まれない、補充するために長距離の訪問が必要となり、また訪問計画の最適化も難しいのでコスト負担になりがちといった要因が挙げられます。近年、センサーなどの技術進化とネットワークの充足により、自販機がオンライン化されつつあります。それによって例えばキャッシュレス決済や、在庫のリアルタイム把握など双方向通信などが実現されることによるデジタルサイネージやロイヤルティプログラムの展開などのアイデアが生まれています。 今回展示する自販機では、気温、混雑状況、機内在庫、倉庫在庫に基づき動的に販売価格を決定する、ダイナミックプライシングが実現されています。ダイナミックプライシングにより、例えば、イベント会場ではイベントのある日は価格を上げるがイベントのない日は安くする、寒い日には冷たい飲み物は価格を下げてみるといった販売戦略をとることで収益向上を図ることができます。今回は「自販機」を接点チャネルとして採用しましたが、いわゆる「ダイナミックプライシング」のアイデアは、自販機に限定されるものではありません。店舗内で人の多い・少ないを判断して広告を出し分けるリテールメディアネットワーク、時間帯や温度で値引き品を変えたり特売の判断を行うなど、今回の展示と同様の仕組みでさまざまなアイデアに応用することができます。 展示内容 会場では自販機本体と、各種データを可視化するダッシュボードを展示してお客様にご覧いただきました。 写真のオレンジ色の箱が自販機本体になります。自販機では周辺の気温（展示では温度センサーではなくダミーで生成した値を使用）、混雑状況（カメラ画像で人物の数をカウント）、自販機内の商品在庫数を取得して、インターネット経由でデータを AWS Cloud へ送信しています。これらのデータを元にクラウド側で販売価格を算出し、自販機の販売画面に表示された価格に反映しています。自販機に販売画面を搭載することで、商品価格の変更だけでなく取り扱い商品の変更も柔軟に行うことができ、さらにはデジタルサイネージによる情報発信の媒体としての活用も考えられます。 写真右上のダッシュボードでは、自販機から送信された気温、混雑状況、自販機内の商品在庫数、および算出した販売価格をリアルタイムに表示しています。自販機で商品を購入すると、ダッシュボード上の在庫数が変化するなど、各種値がリアルタイムに変化する様子を確認可能です。実際の運用においては、多数の自販機から得られる情報をダッシュボードで集約し可視化することで、遠隔地の自販機の状況を一元的に把握することが可能になります。 デモ自販機の構成 次に、デモの構成について説明していきます。全体構成図は次のようになっています。 構成は、大きく分けると 1) 自販機側の処理と、2) AWS Cloud 側での処理に大別されます。以降ではそれぞれについて説明していきます。 1) 自販機内のエッジデバイスによる処理 まず、図の左側のグレー枠で囲われた「1) 自販機」と書かれている部分が、自販機およびその中に構成されたエッジデバイスを表しています。今回のデモでは自販機の中に、 AWS IoT Greengrass をインストールした Raspberry Pi を配置し、自販機内の在庫管理、センサーデータの収集やクラウドへの送信、表示価格の更新を行うようなカスタムコンポーネントを実行しています。 また、自販機の設置された現場に行かずともコンポーネントのログ収集や、デバイスへの SSH ログインができるように、あらかじめ用意されたパブリックコンポーネントである、 ログマネージャーコンポーネント や、 セキュアトンネリングコンポーネント を合わせてデプロイしています。 自販機からクラウドに送信されるデータには、自販機の周囲の気温、カメラで撮影された混雑状況、そして自販機内の現在の商品在庫数、それぞれの商品の現在の販売価格が含まれています。 自販機の周囲の気温 一般的に、気温によって売れる飲料の種類は異なります。例えば、炭酸飲料は気温が低い時より高い時の方が売れ行きは良くなります。今回のデモでは、果汁飲料、お茶、炭酸飲料などそれぞれの飲料タイプ毎に、気温に対する需要の分布を仮定し、価格に反映しています。今回の会場では気温が大きく変わることはないため、デモでは三角関数で模擬しました。 カメラで撮影された混雑状況 自販機の周辺に人が多ければ、それだけ購買の機会が増加します。そのためカメラで撮影した画像の中にたくさんの人が写っていれば、需要が高まっているとみなし価格に反映しています。画像中にどれだけの人が写っているか判定する処理には、オープンソースの物体検出モデルを使用しました。なお、画像からの混雑度推定処理をエッジデバイス上で行うことで、クラウドへの画像送信や画像保存を行わず、通信量の削減だけでなく個人情報取扱いへの配慮も実現しています。 自販機内の商品在庫数 商品在庫数は最大個数を 12 個とし、購入ボタンが押される毎に減算しています。在庫数が少なくなったものは需要が高まっていると判断し、価格に反映しています。今回のデモでは、商品を出すコントローラーデバイス (図中上部) にて在庫数管理を行い、センサーロジックデバイス (図中下部) にてその他の処理を行いました。 表示価格の更新 後述する処理でクラウド側から通知された新しい販売価格は、自販機の画面に反映されます。ただし、実際のシチュエーションを考慮すると、いつでも画面を更新して良いわけではないでしょう。例えば、自販機の前でどの飲料を買おうか迷っている人がいる場合や、コインが投入され今まさに買おうとしているシーンでは、価格が更新されるとユーザ体験がよくありません。 そこで今回のデモでは、先述したカメラでの人検出を利用し、カメラの前に規定以上の大きさで人が写っている場合には価格更新を行わないガード処理を実装しています。この仕組みは、人が自販機の前にいない場合は商品画面ではなく広告表示するなどデジタルサイネージのコントロールにも応用が考えられます。 2) クラウドでの処理 図の右側の黒枠で囲まれた「2) AWS Cloud」と書かれている部分がクラウド上での構成を表しています。クラウドの構成は大きく3つのパートに分けることができます。a. 可視化、b. ダイナミックプライシング、c. 商品画像生成です。 a. 可視化 自販機から送信されたデータは、 AWS IoT Core で mqtt メッセージとして受信します。このメッセージを AWS IoT Rules を使用して AWS Lambda に渡し、時系列データベースである Amazon Timestream に格納します。今回のデモでは、同じタイミングで取得された複数のセンサーデータを一つのテーブルに書き込む方針を取りました。そのため AWS Lambda では、受信したデータを マルチメジャーレコード に変換して、Amazon Timestream に格納しています。シングルメジャーレコードで格納したい場合には AWS IoT Rules から直接 Amazon Timestream に格納することも可能です。Amazon Timestream のデータモデルについて詳細は こちら をご参照ください。 可視化のダッシュボードには、 Amazon Managed Grafana を使用しました。これはオープンソースの分析プラットフォームである Grafana 向けのフルマネージドサービスで、サーバーを意識することなく簡単に始めることが可能です。Amazon Managed Grafana には Amazon Timestream と接続するためのプラグインが用意されており、Amazon Timestream のデータを簡単にクエリ、可視化することができます。 実際にデモで使用した自販機 VM001 号機のダッシュボードを示します。図中の各パネルは、次の 4 つの情報を表示しています。 ① 気温の推移と現在の値 ② 自販機前の混雑度の推移と現在の値 ③ 自販機内の商品在庫推移と現在の個数 ④ 販売商品の価格推移と現在の価格 b. ダイナミックプライシング 動的な価格の計算には、上述した Amazon Timestream に格納されている情報とは別に、倉庫在庫情報に見立てた Amazon DynamoDB のテーブルデータを使用します。従ってエッジデバイスから通知された、気温、混雑状況、自販機内在庫情報に加えて、倉庫内在庫情報をもとに新しい価格を計算しています。ここには様々なアルゴリズムを適用する余地がありますが、今回のデモではシンプルに加重平均で計算しました。 この計算は AWS Lambda 上に実装され、今回のデモでは 2 分おきに Amazon EventBridge Scheduler をトリガーに実行されます。算出された価格は、 AWS IoT Device Shadow に登録され、エッジデバイスに反映されます。実際のユースケースでは、日次や月次などより長い間隔での価格算出や、何かのイベントをトリガーに算出することが想定されますが、こうした場合にも Amazon EventBridge は対応が可能です。 c. 商品画像生成 今回のデモを作成するにあたり、手作りの自販機を一目で自販機だとわかってもらう必要がありました。そこで、少しでもリアルに見せるため、 Amazon Bedrock 上から画像生成 AI の Amazon Titan Image Generator G1 モデル を呼び出し、商品の缶画像を生成しています。 生成された缶画像の例を示します。 この時、全て同じ形、大きさの缶として画像を生成する必要があったので、初めに基準となる無地の缶画像を生成しています。その無地の缶画像からマスク画像を作成し、缶のラベル領域に対して Titan Image Generator のインペイント機能を使って、それぞれの商品画像を生成しています。例えば、左の緑の缶画像は下記のプロントで生成しました。 A beverage can of green tea, the majority label color of the can is light green. まとめ 本記事では、2024 年 6 月 20 日、21 日 に開催された AWS Summit Japan の、流通・小売・消費財業界ブースにて展示を行ったダイナミックプライシングを実現する次世代自販機の詳細についてご説明いたしました。 デモは非常に好評で、お客様と多くの可能性について議論することができました。今回のデモではダイナミックプライシングのロジックとしてシンプルに加重平均での価格算出を行いましたが、売り上げデータに基づく AI/ML モデルを活用するアイデアや、クラウドと連携したデジタルサイネージのアイデア、在庫情報と組み合わせた AI/ML による在庫補充計画の最適化アイデアなどが考えられます。こうした取り組みについてご興味がありましたら、AWS からご支援させていただくことが可能ですので、 「AWS に問い合わせする」 までご連絡ください。 また、本記事に関連するブログをご紹介いたします。ご興味ありましたらこちらもぜひ併せてご覧ください。 (近日公開)【開催報告】AWS Summit Japan 2024 流通・小売・消費財業界向けブース展示 AWS Summit 2024で見たIoTの進化！多数のセッションと展示が語るIoTの真価と深化！（IoTプロダクト編） 著者 千代田 真吾 は、アマゾンウェブサービスのソリューションアーキテクトです。現在は、エンタープライズの小売・消費財業界のお客様が AWS を用いてビジネスを拡大するのを支援しています。特に AI/ML 領域に関心があり、お客様のビジネスにおける AI/ML 活用を積極的に支援しています。 吉田 英史 は、東海地方を中心に小売・消費財業界のお客様を支援しているアマゾンウェブサービスのソリューションアーキテクトです。 かつては製造業で製品の組み込みソフトウェア開発や工場 IoT 構築などに従事してきました。身の回りの生活に欠かせない様々なビジネスをクラウドで加速するお手伝いができることを、何より嬉しく感じています。

この記事は How Slack adopted Karpenter to increase Operational and Cost Efficiency (記事公開日: 2024 年 5 月 3 日) を翻訳したものです。 Bedrock – Slack の内部 Kubernetes プラットフォーム Slack は人々、会話、アプリ、システムを 1 つの場所につなぐ AI を活用した業務用のプラットフォームです。Slack は、コンテナのデプロイや管理をシンプルにするために、”Bedrock” というコードネームの内部コンピューティングオーケストレーションプラットフォームを Amazon Elastic Kubernetes Service (Amazon EKS) を採用して構築しました。Bedrock は、単一の YAML ファイルでビルド、デプロイ、ランタイム環境を処理することで、Slack 内部の開発者の複雑さを大幅に軽減しています。また、Jenkins、FQDN サービスディスカバリー、 Nebula overlay network などのツールを活用して効率的な運用を実現しています。Slack のアプリケーションの 80% 以上が Bedrock で稼働しており、テストの精度が向上し、インフラストラクチャの管理が洗練されたことで、開発者はより効率的に作業できるようになりました。 この投稿では、Slack がどのようにして Amazon EKS でコンテナプラットフォームをモダナイズし、Karpenter を活用してどのようにコスト削減と運用効率の改善を実現したかについて詳しく説明します。 運用効率向上の必要性 Karpenter を利用する前は、Amazon EKS のコンピューティングをオートスケーリングするための別のソリューションを利用していました。しかし内部チームのニーズが高まるにつれて制限に直面しました。アプリケーションの増加と、インスタンスタイプやインスタンスニーズの増加に伴い、複数の Auto Scaling Group (ASG) を管理する必要がありました。Slack には厳しいコンプライアンス要件があり、数千のワーカーノードを持つ複数の EKS クラスターを頻繁に更新する必要がありました。これらの頻繁な更新と複数の ASG の管理が重なり、全体的なアップグレードのペースが遅くなっていました。また、現行の設定では単一レプリカのアーキテクチャを使用していたことを懸念していました。Slack にはノードの起動を高速化し、高可用性を実現し、より優れた cluster bin packing を提供できる堅牢なオートスケーラーが必要でした。 ソリューション概要 前述した運用上の課題を克服するため、Slack はスケジューリングできない Pod に応答して新しいノードを自動的にプロビジョニングするオープンソースのクラスタオートスケーラーである Karpenter の使用を決定しました。Karpenter は、保留中の Pod の集約リソース要件を評価し、それらを実行するための最適なインスタンスタイプを選択します。非 DaemonSet の Pod が無いインスタンスを終了またはスケールインして無駄をなくします。また、 Pod を積極的に移動させ、より安価なノードに置き換えてクラスターコストを削減する統合機能をサポートしています。 これらの機能すべてが Slack の課題に対処し、AWS チームの支援を得て、Bedrock の環境で Karpenter の検証に成功しました。前述の機能に加えて、Karpenter が Amazon Elastic Compute Cloud (Amazon EC2) のフリート API に直接呼び出しを行うことで、遅延なしに適切なコンピューティングリソースを確保できる点が重要でした。 私たちは入念な 2 段階のフェーズで旅を始めました。 第 1 フェーズでは、コアとなる Deployment とアプリケーションとともに、マネージドノードグループ上に Karpenter を展開しました。Karpenter はアプリケーションの一部についてのみ検証され、この段階では統合機能は無効化されていました。 第 2 フェーズでは、Karpenter 自身を Karpenter が管理するノード上で実行したくなかったため、Karpenter Controller のワークロードを専用の ASG に移行しました。すべてのユースケースについて徹底的な試験と慎重な検討を行った後、最終的に数千以上のワーカーノードを実行する 200 を超える EKS クラスター全体に Karpenter を展開しました。また、 Slack はコスト削減を実現するため Karpenter の統合機能も有効にしました。 Karpenter の段階的ロールアウトにより、Karpenter を有効化するクラスターを制御できました。これにより、Karpenter でワークロードのパフォーマンスを検証し、問題が報告された場合は迅速にロールバックを行うことができました。ワークロードに適切な request / limits の設定がない場合、Karpenter は小さなインスタンスを割り当てるか、大きなインスタンスの一部分しか割り当てられず、負荷が増加すると Pod の頻繁な作成と削除が起きていました。Karpenter は Slack がこの点を発見するのを助け、サービス所有者と協力して Pod が適切なノードに割り当てられるよう要件を設定する形で Slack のプラットフォームを改善することができました。特定のインスタンスタイプが必要なワークロードについては、Slack が NodePool のカスタムリソースを調整し、Karpenter の Well-known labels を使って Pod を特定のインスタンスタイプに固定できました。 Slack Bedrock における EKS クラスターのアーキテクチャ 得られた成果 フリート全体に Karpenter をロールアウトした後、ASG ノードに taint を適用し、アプリケーションを Karpenter が管理するインスタンスに移行するプロセスを開始しました。この取り組みから得られた成果は、大きく、定量化可能なものでした。 Karpenter の助けにより、Slack は保留中の Pod がリクエストしたリソースに基づいて、8xlarge から 32xlarge までの幅広いインスタンスタイプを活用し、アプリケーションを適切に bin packing することができました。この結果、クラスターの使用率が上がり、コスト削減に繋がりました。特定のインスタンスを要求しないワークロードは、利用可能なリソースを効率的に活用するようになりました。さらに、Karpenter の統合機能により、以前のソリューションのように複数の アベイラビリティーゾーン (AZ) にまたがる最小の ASG サイズとしてアイドル状態のインスタンスを維持するのではなく、アイドルインスタンスの削除が確実に行われるようになりました。加えて、Karpenter の迅速なスケーリング判断により、ノードのプロビジョニング時間が短縮されたことを確認しています。 成果についてまとめると、 Pod のリソース要求に基づくインスタンスの動的選択と、EKS クラスターを管理する Terraform ファイルにインスタンスタイプをハードコードしないことで、 Pod の起動が高速化されました。また、アップグレード手順中にノードをスムーズに削除・ローテーションできるため、Slack のシステムアップグレードに関する懸念も解消されました。Karpenter が 直接 Amazon EC2 のフリート API と対話できること、およびリトライ機構の改善により、AZ の障害発生時の復旧も高速になりました。アプリケーションは、AWS で利用可能な容量までインスタンスをスケールアウトできるため、ASG の管理オーバーヘッドが少なく、Slack ユーザーの体験も向上しています。Slack は現在、ミッションクリティカルなアプリケーションのバースト的なスケーリング活動に備えて、カスタムのオーバープロビジョニングで Karpenter を運用しています。 Slackは、Helm のテンプレート機能を活用して、Karpenter の Helm チャートをカスタマイズし、200 を超える EKS クラスター全体で単一の NodePool と EC2NodeClass を使用しています。 Karpenter が提供するインスタンスファミリーには幅広いインスタンスタイプが用意されているため、Slack の技術チームは動的スケジューリングの制約を使用する際に、簡単にインスタンスタイプを切り替えられることが便利だと感じています。これにより、インフラストラクチャチームの RTB の負担が軽減され、ASG 設定を維持する際に見られたようなインスタンスタイプ変更のリスクも低減されました。Karpenter を活用することで、Slack は EKS のコンピューティングコストを 12% 削減できました。 今後の機能強化 Slack は現在、運用をさらに改善しコスト削減を進めるため、Karpenter の設定の合理化に取り組んでいます。ロードマップには以下の機能が含まれています: Kubelet のカスタマイズ: Infrastructure-as-a-Code (IaC) ソリューションを介してではなく、Karpenter の EC2NodeClass 内で kubelet フラグを使用することで、インスタンスの起動時間を改善します。 Warmpool/minimum: Karpenter がオープンソース化されたことを受け、Amazon EC2 フリート API コールを発行するのではなく、Karpenter がウォームプールからインスタンスを選択することで起動時間を短縮する方法について、Slack は貢献を検討しています。 Disruption control: Slack は、統合によって発生する障害を制御し、アプリケーションの可用性への影響を制限するために、障害制御機能を活用しています。 まとめ この投稿では、Slack の Bedrock チームが Karpenter の実装により Amazon EKS クラスターの運用とコスト削減をどのように改善したかについて説明しました。AWS と Slack の協力体制が Karpenter の成功裏の展開と Slack の Amazon EKS 環境のモダナイズに不可欠でした。また、Slack が Karpenter を EKS クラスターのオートスケーラーとして活用することで、アップグレードのペースを改善し、さらなるコスト削減を実現できたことも取り上げました。今後は Slack が新機能への貢献と活用を通じて Karpenter 環境をさらに最適化し、Amazon EKS 上に堅牢なプラットフォームを構築することに注力していきます。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

この記事は Announcing software version consistency for Amazon ECS services (記事公開日: 2024 年 7 月 11 日) の翻訳記事です。 概要 コンテナイメージタグは、様々なバージョンのコンテナイメージを管理および追跡するためのユーザーフレンドリーな方法を提供します。しかし、コンテナイメージの可変性 (mutability) は、組織にセキュリティリスクをもたらします。 適切な予防策 を実施しない場合、コンテナイメージリポジトリにおいて、全く別のコンテナイメージを参照するようにコンテナイメージタグが変更されてしまう恐れがあります。そのため、ワークロード定義時に指定したコンテナイメージと、ワークロード実行時に使用されるコンテナイメージが異なる状況が発生します。 本日より、 Amazon Elastic Container Service (ECS) は、アプリケーションのソフトウェアバージョンの一貫性を保証するようになりました。この新機能では、 ECS サービス の各バージョン ( デプロイメント ) において、Amazon ECS がコンテナイメージタグをコンテナイメージダイジェストに解決します。これにより、デプロイメントライフサイクル全体で同一のコンテナイメージが使用されることを保証し、ECS サービスとしてデプロイされたアプリケーションのセキュリティと一貫性を向上させることができます。 背景 ECS サービスは、Web や API ワークロードなど、長時間実行されるアプリケーションで使用される同一のタスクのグループです。Amazon ECS では、ECS サービスの デプロイメント という形で ECS サービスのバージョンと タスク定義 リビジョンを紐付けることで、サービス内のすべてのタスクが同一であることを保証します。ただし、タスク定義リビジョン内で (コンテナイメージダイジェストではなく) コンテナイメージタグを使用した場合、この一貫性が損なわれる可能性があります。 コンテナイメージはイミュータブル (不変) です。コンテナイメージをビルドすると、コンテナイメージダイジェスト (sha256 ダイジェスト) が作成されます。このイメージダイジェストは、コンテナイメージの中身のチェックサムを元に作成されるため、そのコンテナイメージを象徴するメタデータの 1 つとなります。しかし、イメージダイジェストを用いてコンテナイメージを参照することはあまりなく、多くの場合、イメージタグを用いて参照します。 コンテナイメージタグはイミュータブル (不変) ではなく、ミュータブル (可変) です。ある時点でイメージタグが特定のコンテナイメージダイジェストを参照していたとしても、その後、別のコンテナイメージダイジェストを参照するように更新される可能性があります。これは latest イメージタグを使用する場合にありがちです。latest という名前のイメージタグを使用し、ソフトウェアの新しいバージョンがリリースされる度に latest タグを新しいコンテナイメージに紐付け直しているプロジェクトをよく見かけます。 Amazon ECR のタグイミュータビリティ のように、コンテナイメージレジストリがイメージタグの変更を防ぐ機能を実装している場合もありますが、未だに多くのプロジェクトで latest タグを用いた運用が採用されています。 Amazon ECS におけるソフトウェアバージョンの一貫性 本日より、 ECS デプロイメントコントローラー (ローリングアップデート) を使用する ECS サービスは、タスク定義リビジョンがコンテナイメージタグを参照していても、デプロイメントライフサイクル全体で同一のコンテナイメージダイジェストを使用することが保証されます。Amazon ECS は、最初のタスクのデプロイ時にコンテナランタイムがイメージタグを解決する際、イメージダイジェストを保存しておきます。そして、そのデプロイメントにおける他のすべてのタスクは、保存したイメージダイジェストを参照する形になります。 これまで Amazon ECS では、それぞれのタスクのコンテナランタイムが独立してイメージタグをイメージダイジェストに解決していました。そのため、特定のデプロイメントにおいて頻繁にスケールインまたはスケールアウトが発生し、その間にコンテナイメージタグが新しいコンテナイメージダイジェストを参照するように更新された場合、同一の ECS サービスのデプロイメント内で異なるコンテナイメージが実行される可能性がありました。 今後、ECS サービスのデプロイメント (新規サービスの作成または既存サービスの更新) では、最初のタスクのデプロイ後、コンテナイメージタグがコンテナイメージダイジェストに変換、保存されます。ECS サービスのデプロイメントは、以下の順番で実施されます。 ユーザーが ECS サービスを新規作成または更新します。 Amazon ECS は、ECS サービスの desiredCount に関わらず、まず 1 つのタスクをスケジューリングします。 このタスクが実行状態になると、タスク内で実際に使用されたすべてのコンテナイメージダイジェストが確認され、Amazon ECS に報告されます。 このデプロイメントにおける他のすべてのタスクは、コンテナイメージタグではなく、コンテナイメージダイジェストを用いてスケジューリングされます。これにより、このデプロイメントに含まれるすべてのタスクが同じコンテナイメージを使用することが保証されます。 注 : タスク定義でコンテナイメージタグを使用せず、各コンテナイメージをダイジェストで参照している場合、この新しいデプロイメントの仕組みに従いません。この場合、すべてのタスクを同時にスケジューリングする従来の ECS の動作が適用されます。 ウォークスルー ECS サービスにおけるソフトウェアバージョンの一貫性は、既存の ECS サービスにおいて新しくデプロイメントを開始することで確認できます。新しく ECS サービスを作成する場合は、 Amazon ECS 開発者ガイド が参考になります。既存の ECS サービスを利用する場合は、 aws ecs update-service コマンドで新しくデプロイメントを開始できます。 $ aws ecs update-service --cluster $CLUSTER --service $SERVICE --force-new-deployment 新しくデプロイメントが作成されたら、 DescribeTask API を使用してタスクを検証し、コンテナイメージタグが解決されていることを確認できます。まず、ECS サービスで実行中のタスクの一覧を取得します。 $ TASK_ARNS=$(aws ecs list-tasks --cluster $CLUSTER --service $SERVICE --query 'taskArns[]' --output text) 次に、タスクの詳細を出力して --query フラグで解析すると、ある 1 つのタスクではコンテナイメージタグが使用されている一方で、その他のすべてのタスクではコンテナイメージダイジェストが使用されていることを確認できます。 $ aws ecs describe-tasks --tasks $TASK_ARNS --query 'tasks[*].{taskArn:taskArn,containerName:containers[0].name,containerImage:containers[0].image}' [ { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/279034d4f56b40239e72881c19acc58f", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440" }, { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/e1174f0425ab435fb5abb1a661e6fd9c", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx@sha256:ac96a05e4b3dd2c57c9ca2637012f4fa17b11d5fdd2ce856c2f937bd843f0440" }, { "taskArn": "arn:aws:ecs:eu-west-1:111222333444:task/default/199bd6a195f645a7ab1b503e3598e5c4", "containerName": "containerone", "containerImage": "public.ecr.aws/docker/library/nginx:stable" } ] また、 DescribeService API を使用して、デプロイメントのイベントを表示してみます。この出力では、コンテナイメージダイジェストを取得するために 1 つのタスクを起動し、その後で他のタスクを開始する、新しいデプロイメントのパターンを確認できます。このとき、古いイベントが下の方に表示されることに注意してください。 $ aws ecs describe-services --cluster $CLUSTER --services $SERVICE --query 'services[0].events' [ { "id": "bf43bbc6-ad78-4316-9a8c-6b561a0c035a", "createdAt": "2024-06-07T14:22:31.089000+00:00", "message": "(service fargate-service-demo) has reached a steady state." }, { "id": "4c3f3830-6291-47e0-a0d6-ee19f43076f8", "createdAt": "2024-06-07T14:22:31.088000+00:00", "message": "(service fargate-service-demo) (deployment ecs-svc/4506290861204002986) deployment completed." }, { "id": "350e8c3c-890e-428c-846f-f900d964f234", "createdAt": "2024-06-07T14:22:13.171000+00:00", "message": "(service fargate-service-demo) registered 2 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)" }, { "id": "985ce76c-ade8-4103-9569-82dca19f95af", "createdAt": "2024-06-07T14:21:24.685000+00:00", "message": "(service fargate-service-demo) has started 2 tasks: (task 569abf2a0c1f4694882c643194278919)." }, { "id": "290cdfd3-513a-4477-83d9-690352865bc6", "createdAt": "2024-06-07T14:21:18.138000+00:00", "message": "(service fargate-service-demo) registered 1 targets in (target-group arn:aws:elasticloadbalancing:us-west-2:111222333444:targetgroup/defaulttgtss/74939c377ec7273a)" }, { "id": "63bfc91d-8ad6-4764-9c35-149fdfa668e9", "createdAt": "2024-06-07T14:20:33.898000+00:00", "message": "(service fargate-service-demo) has started 1 tasks: (task 08738ec750d84695ae2e12800d7a31df)." } ] CodeDeploy または External デプロイメントコントローラー を使用する ECS サービスなど、コンテナイメージタグがコンテナイメージダイジェストに解決されない場合もあります。例外事項の詳細については、 Amazon ECS ドキュメント を参照してください。 まとめ ソフトウェアバージョンの一貫性のリリースにより、ECS サービスとして実行されるすべてのタスクが、同一かつイミュータブルなコンテナイメージを使用することを保証できるようになりました。この機能追加によって、Amazon ECS 上で実行されるコンテナアプリケーションの信頼性とセキュリティが大幅に向上します。タスクが意図せずに異なるコンテナイメージを使用するリスクを排除することで、開発者はワークロードの一貫性と予測可能性に対して自信を持つことができます。この機能の利用方法や Amazon ECS の他の機能の詳細は、 Amazon ECS ドキュメント を参照してください。AWS コンテナサービスの ロードマップ にて、フィードバックや提案をお待ちしています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 先週の AWS 初心者向けイベント、 AWS Builders Online には多くの方にご参加いただきまして、ありがとうございました。私はキーノートを担当したのですが、キーノートからたくさんの質問をいただいて、オンラインながら熱気を感じるイベントでした。オンデマンドで視聴可能になっていますので、ご興味ある方はぜひご覧ください。 – AWS 初心者向けイベント AWS Builders Online Series | アーカイブ公開中 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年7月15日週の主要なアップデート 7/15(月) Amazon OpenSearch Serverless levels up speed and efficiency with smart caching – AWS Amazon OpenSearch Serverless に新たにスマートキャッシュ機構が追加されました。これによりキャッシュが効果的に管理される事に加え、Indexing OCU がデータ量ベースではなくデータの取り込み速度ベースでスケールするようになりました。これによってデータ登録時のOCUが削減され、コスト削減につながります。 Amazon RDS for MariaDB supports Long-Term Support version 11.4 in Amazon RDS Database Preview Environment – AWS Amazon RDS for MariaDB は RDS データベースプレビュー環境でバージョン 11.4 をサポートし、最新の長期サポートリリース(LTS)を評価できるようになりました。RDS データベースプレビュー環境は、テスト・評価用に一般リリース前（プレビュー）のRDSを利用することができる環境です。 AWS Elemental MediaConnect supports individual output stopping capability – AWS AWS Elemental MediaConnect フローの個々の出力を無効にして、データの送信を一時的に停止できるようになりました。これにより設定をしなおさなくても、ライブ配信を一時停止し、再開できるようになりました。 AWS Security Hub launches 24 new security controls – AWS AWS Security Hub で 24 の新しいセキュリティコントロールが追加されました。今回の追加で Amazon Inspector、Amazon Data Firehose、AWS Service Catalog 等があらたに追加され、サポートコントロールの数は合計 418 になりました。 Amazon QuickSight improves controls performance – AWS Amazon QuickSight でコントロール（フィルタ操作用のGUI）のロードがバックグラウンドで実行されるようになりました。これにより、他のコントロールがロードし終わるのを待つ必要なく、すぐにコントロールを操作できるようになりました。これはコントロールを多数使用しているダッシュボードの操作性を改善します。 7/16(火) （この日はブログで取り上げる発表がありませんでした） 7/17(水) Announcing the July 2024 updates to Amazon Corretto – AWS Open JDK ディストリビューションの、Amazon Corretto で四半期リリースが公開されました。それぞれ 22.0.2, 21.0.4, 17.0.12, 11.0.24, 8u422 が利用可能になっています。 Correttoのホームページ からダウンロード可能です。 7/18(木) New open-source Advanced MYSQL ODBC Driver now available for Amazon Aurora and RDS – AWS Amazon Web Services (AWS) ODBC Driver for MYSQL が Amazon RDS for MySQL および Amazon Aurora MySQL-compatible edition 用として一般提供開始（GA）になりました。このOSSのドライバーは、スイッチオーバ―を高速に実行することができ、フェイルオーバー時のダウンタイムを短くすることが可能です。ドライバーは Githubからダウンロード可能 です。 AWS Private CA now supports ARM architecture in Kubernetes – AWS AWS Private Certificate Authority (ライベート認証局) は、Kubernetes の ARM アーキテクチャサポートを発表しました。これにより、プライベート証明書を使用してAmazon EKS 等で稼働する Kubernetes アプリケーションに TLS 経由の安全な接続を実現することが可能になります。 AWS Lambda now supports SnapStart for Java functions that use the ARM64 architecture – AWS AWS Lambda SnapStart が ARM64 命令セットアーキテクチャを使用する Java Lambda Function で使用できるようになりました(x64アーキテクチャではすでに利用可能です)。SnapStart for Java は、追加コストなしでLambda関数の起動速度を最大 10 倍に高速化する仕組みです。 AWS IAM Identity Center adds independent 90-days session duration for Amazon Q Developer – AWS AWS IAM Identity Center で Amazon Q Developer 向けのセッション時間を、他のAWSアプリケーションへのセッションとは別に設定できるようになりました。これにより、例えばAWS管理コンソールへのアクセスを短めに設定しつつ、IDEからの Q Developerへのセッションは長くすることで頻繁な再認証を避けるといった構成が可能になります。 7/19(金) Productionize Fine-tuned Foundation Models from SageMaker Canvas – AWS Amazon SageMaker Canvas は SageMaker リアルタイム推論エンドポイントに対して、ファインチューンされた Foundation Model (FM) のデプロイがサポートされるようになりました。これにより、 SageMaker Canvas で構築された生成 AI モデルを Canvas のワークスペース外で利用することが容易になりました。 Amazon Connect launches search API for agent status – AWS Amazon Connect に、名前、ID、タグ、またはその他の条件でエージェント（対応者）ステータスを検索する API が提供されるようになりました。このステータスはエージェントが休憩中・不在などの理由で、エージェントがコンタクトに対応できるかどうかを示すもので、検索のAPIを使うことでこういった状態に対応した自動化が可能になります。 最後に１つイベントのお知らせです。 AWS re:Inforce 2024 re:cap が今週、26 日 (金) に開催されます。AWS 最大のセキュリティカンファレンスを日本語で振り返るセッションですので、ご興味がある方はぜひご覧ください。 – AWS re:Inforce 2024 re:cap それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

組織は、請求処理、在庫追跡、プロジェクト承認などの分野において、ビジネス上の問題解決に苦労することがよくあります。カスタムビジネスアプリケーションはこれらの問題を解決し、組織をより効果的に機能させるソリューションを提供できますが、構築と保守には専門の開発チームが必要とされてきました。しかし、多くの場合、開発能力が不足していたり費用がかかりすぎたりするため、企業は非効率的なツールやプロセスを使用し続けていました。 7月10日、 AWS App Studio のパブリックプレビューについてお知らせします。App Studio は生成人工知能 (AI) を活用したサービスです。ソフトウェア開発のスキルがなくても、自然言語を使用してエンタープライズグレードのアプリケーションを数分で作成できます。 ここでは App Studio でできることを簡単に紹介します。 App Studio にサインインした後、 CREATE A NEW APP から Generate an app with AI を選択します。その後、プロジェクト承認アプリが必要だと説明すると、App Studioがユーザーインターフェイス、データモデル、ビジネスロジックを備えたアプリを生成してくれます。アプリ生成プロセス全体が数分で完了します。 注:上記のアニメーションは、デモンストレーション用に早送りをしています。またデモの中で入力しているプロンプトは以下の通りです。皆さんもぜひお試しください。 Create a project approvals app for my team to submit projects for approval through a form. The form will accept detailed information and allow users to upload related files. この記事を書いているうちに、App Studio がさまざまな技術者の役に立つことがわかりました。App Studio を使用すると、IT プロジェクトマネージャー、データエンジニア、エンタープライズアーキテクトは、安全なビジネスアプリケーションを数日ではなく数分で作成および管理できます。App Studio は組織によるエンドツーエンドのカスタムアプリケーションの構築に役立ちます。App Studio には主に次の 2 つのユーザーロールがあります。 Builder – このグループのメンバーはアプリケーションを作成、構築、共有できます。アプリケーション構築の過程に興味がある方は、後述する “ Builder として AWS App Studio を利用する : アプリケーションの作成 ” をご覧ください。 Admin – このグループのメンバーはグループとロールの管理、コネクタの作成と編集、組織内で作成された他のアプリの可視性を維持できます。これらの権限に加えて、Admin は独自のアプリケーションを作成できます。App Studio の有効化と設定方法や管理者として可能な操作については、後述する “ AWS App Studio の利用を開始する ” をご覧ください。 Builder として AWS App Studio を利用する : アプリケーションの作成 Builder は App Studio の生成 AI を搭載したローコード構築環境を使用し、安全なアプリケーションを作成できます。まず「Build an application to review and process invoices.」（請求書を確認して処理するアプリケーションを構築する）など、必要なアプリケーションを自然言語で記述します。次に App Studio がデータモデル、ビジネスロジック、複数の画面からなる UI を含むアプリケーションを生成します。 ここから楽しい時間の始まりです。App Studio でアプリを構築する時がやってきました。 Builder hub ページで、 Create app を選択します。 アプリケーションの作成方法には 2 つの選択肢があります。 AI を使ったアプリケーションの生成 (Generate an app with AI) または、 一からアプリケーションを作成する (Start from scratch) かです。ここでは AI を使ったアプリケーションの生成 (Generate an app with AI) を選択します。 次のページでテキストボックスにアプリケーションへの要求を入力するだけで、アプリケーションの作成を開始できます。また、右側のパネルにあるサンプルプロンプトも選択可能です。 その後、App Studio がアプリの要件を準備してくれます。プロンプトを絞り込み、更新された要件を確認することで、アプリケーションの計画を改善できます。満足のいく結果が得られたら、 Generate app を選択すると、App Studio がアプリケーションを生成します。 App Studio のアプリケーション作成は私にとって良い経験でした。App Studio に搭載された生成 AI 機能により、わずか数分でアプリケーションが生成されました。他のツールを使用すると、同じ結果を得るのに何時間も、あるいは何日もかかっていたでしょう。 数分後、アプリの準備が完了します。また、App Studio には、さまざまな機能を操作して理解するための簡単なチュートリアルが用意されていることもわかりました。 App Studio には主に 3 つの領域があります。 Pages、Automations、Data です。最初にデータモデルを定義することからアプリケーション作成に着手したいので、 Data セクションに移動しましょう。 Data セクションでは DynamoDB によって提供されるマネージドデータストアまたは、利用可能なデータコネクタを使用してアプリケーションデータをモデル化できます。このアプリケーションは AI が生成したため、すべてのデータエンティティが自動的に定義されています。手動で行う場合、アプリケーションのさまざまなデータテーブルとフィールドタイプを表すエンティティを作成する必要があります。 データエンティティに満足したら、ビジュアルページを作成します。ここでは、ユーザー向けの UI を作成できます。テーブル、フォーム、ボタンなどのコンポーネントを追加および配置して、エンドユーザーに合わせたエクスペリエンスを作成できます。 アプリの構築中に Preview を選択すると、ライブプレビューが表示されます。これはアプリケーションのレイアウトと機能をテストするのに役立ちます。 しかし、この 3 つの領域でのハイライトは Automations です。Automations はルール、ワークフローに加え、アプリケーションのビジネスロジックを拡張するアクションを定義できます。このアプリケーションは App Studio の生成 AI アシスタントで構築したため、処理に必要な複数の Automations が自動的に作成され、アプリケーションに配置されました。 たとえば、新しいプロジェクトが申請されるたびに、プロジェクトを作成して通知メールを送信するアクションが呼び出されます。 API の呼び出し、 AWS Lambda 、その他の AWS サービスの呼び出しによってビジネスロジックを拡張できます。たとえば、プロジェクトを作成するだけでなく、プロジェクトをフラットファイル形式で S3 バケットにアーカイブしたいとの要求です。そのためにはいくつかの処理を行う必要がありますが、既存の Lambda 関数を利用可能です。Lambda 関数を利用する場合の事前準備は Connect to AWS Lambda をご覧ください。 Connector 作成などの Lambda 関数を利用する準備が完了した後、一つ前のスクリーンショット右側の Actions タブの API Actions から Invoke Lambda を選択し、フローの中に配置します。次に Properties タブで Connector、Function name、 そして既存の Lambda 関数に渡す Function event payload を設定します。 最後にすべての UI ページ、データエンティティ、Automations に満足したら、 Publish を選択してアプリケーションを公開できます。アプリケーションの公開先は テスト環境（Testing） と 本番環境（Production） が存在します。テスト環境は本番環境にアプリケーションを公開する前のテストに役立ちます。 ここまでは Builder の視点から見たアプリケーション構築体験を説明しましたが、App Studio の設定および管理は Builder とともに Admin にとっても重要な責任です。App Studio を使い始める方法は次のとおりです。 AWS App Studio の利用を開始する AWS App Studio は AWS IAM Identity Center と統合されており、既存のシングルサインオン (SSO) や Lightweight Directory Access Protocol (LDAP) との統合を柔軟に行えるため、アクセス保護が容易です。また App Studio がアプリケーションのデプロイと運用を管理するため、アプリケーションの運用にかかる時間と負担を省くことができます。それにより、アプリケーションに機能を追加したり、ユーザーのニーズに合わせてカスタマイズしたりすることに、より多くの時間を費やすことができます。 App Studio を使用してアプリケーションを作成する前に、サービスを有効にする必要があります。管理者が App Studio インスタンスを設定する方法は次のとおりです。 まず、App Studio 管理コンソールに移動して Get started を選択します。 前述のとおり、App Studio は IAM Identity Center と統合されており、IAM Identity Center での既存の組織インスタンスの有無を自動的に検出します。IAM Identity Center の組織インスタンスとアカウントインスタンスの違いについては Manage organization and account instances of IAM Identity Center をご覧ください。 本日ご紹介する既存の組織インスタンスが存在しないケースでは、App Studio が IAM Identity Center でアカウントインスタンスを作成する手順をガイドしてくれます。ここでは、 Create an account instance for me を選択します。 次のセクション Create users and groups and add them to App Studio では Admin グループと Builder グループの両方を定義する必要があります。このセクションでは、自分自身を管理者として Admin グループに追加し、後で Builder グループにユーザーを追加します。 オンボーディングプロセスの最後は Acknowledgment の確認です。記載内容を確認してからチェックボックスをオンにし、 Set up を選択します。 オンボーディングプロセスが完了すると Account ページで App Studio のステータスが Active になり、利用可能になります。この時点で一意の App Studio インスタンス URL が発行され、アクセスが可能になります。 このオンボーディングシナリオでは、IAM Identity Center に既存の組織インスタンスが存在しないケースご紹介しています。既存の IAM Identity Center インスタンスを使用する方法については Creating and setting up an App Studio instance for the first time をご覧ください。 App Studio が IAM Identity Center のアカウントインスタンスを作成したため、App Studio へのサインイン手順が記載された E メールが届きました。リンクを選択し、アカウントのパスワードを作成し、多要素認証（MFA）を定義してアカウントのセキュリティ体制を強化する必要があります。 これで、App Studio にサインインできるようになります。 ユーザーの追加 (オプション) App Studio は AWS IAM Identity Center を使用してユーザーとグループを管理します。つまり App Studio インスタンスに追加のユーザーを招待する場合、IAM Identity Center で招待する必要があるということです。 たとえば、これがユーザーのリストです。 Add user を選択すると、さらにユーザーを追加できます。ユーザーの追加が完了すると、アカウントを有効にする手順が記載されたメールがユーザーに届きます。 追加のグループを作成する必要がある場合は Groups ページで Create group を選択します。次のスクリーンショットは IAM Identity Center のアカウントインスタンス用に定義したグループを示しています。 管理者として AWS App Studio を使用する App Studio に切り替えて、管理者としてサインインします。ここには2つの主要なセクションがあります。 Admin hub と Builder hub です。 管理者として Roles セクションで既存のユーザーグループをロールに関連付けることで、ユーザーに App Studio へのアクセス権を付与できます。 IAM Identity Center で作成したグループをマッピングするには、 Add group を選択し、 Group identifier と Role を選択します。設定できるロールは、Admin、Builder、App User の3つです。各ロールの違いについては Managing access and roles in App Studio をご覧ください。 管理者としてコネクタを使用して App Studio にさまざまなデータソースを組み込むことができます。App Studio には Amazon Aurora 、 Amazon DynamoDB 、 Amazon Simple Storage Service (Amazon S3) などの AWS サービスと統合するための組み込みコネクタが用意されています。また、Salesforce 用の組み込みコネクタやサードパーティのサービスと統合するための汎用 API および OpenAPI コネクタも備えています。 今回は Generate an app with AI を選択してアプリケーションを作成したため、App Studio が自動的に DynamoDB コネクタを作成してくれました。また Create connector を選択して追加のコネクタを作成することもできます。 このページでは AWS サービスへの他のコネクタを作成できます。他の AWS サービスが必要な場合は Other AWS services を選択します。コネクタの IAM ロールを定義する方法は Connect App Studio to other services with connectors をご覧ください。 プレビューにご参加ください AWS App Studio は現在プレビューとして米国西部（オレゴン）リージョンにて利用可能です。なお App Studio で作成するアプリケーションは他の AWS リージョンのデータにも接続できます。 AWS App Studio を使用して、安全かつスケーラブルでパフォーマンスの高いカスタムビジネスアプリケーションを構築し、ミッションクリティカルなタスクを最新化および合理化しましょう。すべての特徴や機能の詳細については、 AWS App Studio ドキュメント ページをご覧ください。また AWS Developers Slack ワークスペースの #aws-app-studio チャンネルで会話にご参加ください。 Happy building, –  Donnie 原文は こちら です。

自然災害、アプリケーション障害、サービス障害、人為的ミス、またはランサムウェアによる災害は、ビジネスアプリケーションのダウンタイムだけでなく、データ損失と収益への影響も引き起こします。潜在的な障害に備えるため、オンプレミスで VMware を実行している企業は、ハイブリッドクラウド戦略に VMware Cloud on AWS を取り入れることが増えています。災害発生時のビジネスの継続性を確保するために、災害復旧 (DR) もその戦略の重要な部分です。 VMware Cloud on AWS を使用すると、AWS 上で実行されている VMware マネージド Software-Defined Data Center (SDDC) に VMware ワークロードを素早く移行できます。アプリケーションを再構築または再設計することなく、オンプレミスのデータセンターを拡張することができます。また、AWS のグローバルインフラストラクチャ上で VMware の SDDC をデプロイし、vSphere ワークロードをマネージドサービスとして利用できます。 SDDC の 仮想マシン　(VM) でネイティブの AWS サービスを使用することで、運用オーバーヘッドを削減し、総所有コスト　(TCO) を下げながら、ワークロードの俊敏性とスケーラビリティを高めることができます。 AWS Elastic Disaster Recovery (DRS) を使用すると、新しい DR 計画を迅速かつ簡単に実装したり、既存の DR 計画を AWS に移行したりできます。ソースサーバーは、 AWS 上またはお客様の既存の物理/仮想データセンター、プライベートクラウド、他のパブリッククラウド、VMware Cloud on AWS などのハイブリッドクラウド環境上にデプロイすることができます。 Elastic Disaster Recovery は、必要なときまでアイドル状態になるオンプレミスの DR インフラストラクチャに投資することなく、AWS を伸縮自在なリカバリサイトとして利用できるようサポートしています。また、時間単位での支払いも可能で、長期契約や一定数のサーバーにコミットする必要がないため、オンプレミスまたはデータセンターリカバリソリューションよりも利点があります。 この投稿では、 VMware Cloud on AWS にコスト効果の高い DR ソリューションを提供しながら、お客様がダウンタイムとデータ損失を最小限に抑えられるように、 AWS ネイティブソリューションとして Elastic Disaster Recovery を使用する方法を実証します。 VMware Cloud on AWS のソースマシンからリカバリリージョンの Amazon Elastic Compute Cloud (Amazon EC2) ターゲットへのフェイルオーバーの手順を段階的に説明します。次に、VMware Cloud on AWS への完全リカバリを完了するために、Elastic Disaster Recovery を使った Amazon EC2 からのフェイルバックを実演します。 ソリューションの概要 VMware Cloud on AWS を設定する際に必要なアカウントは2つあります。1つ目は、 VMware Cloud SDDC アカウントです。これは SDDC または VMware Cloud on AWS リソースを実行する AWS アカウントで、VMware が所有し運用しています。2つ目の必要なアカウントは、 AWS のお客様が所有するアカウントです。このアカウントを SDDC に正常に接続するには、そのアカウント内に少なくとも 1 つの Amazon Virtual Private Cloud (Amazon VPC) が必要です。これを Connected VPC と呼びます。 VMware Cloud on AWS SDDC の展開手順 に従って VMware Cloud SDDC アカウントをプロビジョニングする際、この Connected VPC 内に AWS Elastic Network Interfaces (ENI) が設定され、この VPC 内の AWS サービスへの高帯域幅かつ低レイテンシのアクセスが提供されます。 VMware Cloud SDDC アカウントと Connected VPC アカウントのセットアップから始めます。 Elastic Disaster Recovery ターゲットアカウントで、 VPC を設定し、 Connected VPC から AWS Resource Access Manager (AWS RAM) を使用して AWS Transit Gateway アタッチメント を介してVPC と共有されている AWS Transit Gateway に接続します。この　Transit Gateway は、VMware が提供するホワイトラベル化された Transit Gateway である VMware Transit Connect とピアリングされています。このピアリングにより、 Elastic Disaster Recovery ターゲットアカウントの VPC が VMware Cloud SDDC に接続されます。 VMware Cloud SDDC 内のソース VMware Cloud on AWS の VM に Elastic Disaster Recovery agent をデプロイします。次に、 Elastic Disaster Recovery ターゲットアカウントで実行されている Elastic Disaster Recovery に接続します。このセットアップにより、 SDDC 内のソース VM からのブロックストレージボリュームを低コストのステージングエリアに継続的にレプリケートできるようになります。これは、ターゲット Elastic Disaster Recovery アカウントの VPC 内に展開された Amazon EC2 で構成されます。災害発生時は、Elastic Disaster Recovery コンソールから、数分でフルプロビジョニング状態の VMware Cloud on AWS 上のソース VM にフェイルバックできます。 フェイルバックとは、リカバリシステムからプライマリシステム (ソースサーバー) へのトラフィックのリダイレクトを意味します。 Elastic Disaster Recovery では、 DRS Mass Failback Automation client (DRSFA) を使って、AWS 上の リカバリ EC2 インスタンスからソースサーバー VM へのデータのレプリケーションにより、 VMware vCenter に対するスケーラブルなフェイルバックを実行できます。この投稿では、 DRSFA client によるワンクリックフェイルバックを使用して、フェイルオーバー時に使用したソースサーバーとは異なる VMware Cloud on AWS SDDC VM (ソースサーバー) へのフェイルバックを検証します。 以下の図は、前述のとおり VMware Cloud on AWS SDDC での Elastic Disaster Recovery の全体的なセットアップを示しています。 図1: Elastic Disaster Recovery サービスを使った VMware Cloud on AWS マルチリージョン DR 前提条件 次の前提条件を満たす必要があります。 AWS アカウントで Connected VPC を設定し、VMware Cloud on AWS を有効化するために、 これらの展開手順 に従ってください。 VMware Cloud on AWS の購入プロセスでは、 AWS に提出する注文フォームで、 組織 の電子メール連絡先を指定します。購入が処理された後、 AWS は指定された電子メールアドレスにウェルカムメールを送信します。そこに記載されている手順に従って、 VMware Cloud on AWS を有効化し、VMware Cloud on AWS コンソールにアクセスしてください。 Deploying VMware Cloud on AWS SDDC で説明されている手順に従って SDDC を導入し、 AWS アカウントに接続して Connected VPC をセットアップします。VMware の VMware Transit Connect – Simplifying Networking for VMware Cloud on AWS の投稿で説明されている手順に従って、 VMware Transit Connect と SDDC グループを使った SDDC 間の接続モデルを構成します。次に、 VMware の Getting Started with VMware Transit Connect Intra-Region Peering for VMware Cloud on AWS の投稿で説明されている手順に従って、 Connected VPC 内のネイティブ Transit Gateway との Transit Connect の同一リージョン内のピアリングを設定します。 外部 Transit Gateway がピアリングされている Connected VPC アカウントに移動し、 こちらの手順 に従って AWS RAM を使用してリソース共有を作成し、外部アカウントとの共有を許可します。 Elastic Disaster Recovery ターゲットアカウントから Connected VPC の Transit Gateway の リソース共有を承認 します。 セットアップ 1. Transit Gateway が共有されたのと同じリージョンの Elastic Disaster Recovery ターゲットアカウントで VPC を作成します。 AWS CloudFormation コンソール に移動し、 aws-vpcsetup-v1.yml CloudFormation テンプレートを使用して スタックを作成 します。このテンプレートは、最低2つのアベイラビリティーゾーン (AZ) にパブリックサブネットとプライベートサブネットで構成される VPC を設定します。また、Elastic Disaster Recovery replication agent の設定に必要な AWS Identity and Access Management (IAM) ユーザーもプロビジョニングします。プライベートサブネットは NAT Gateway 経由でインターネットアウトバウンド接続を持ちます。テンプレートにはパラメータはありません。テンプレートの起動が成功したら、左側のパネルで Stacks を選択します。 aws-vpcsetup-v1.yml テンプレートを選択し、 Outputs タブを選択します。 a. DRSUserAccessKeyId と DRSUserSecretAccessKey の値を確認します。これらは、セットアップセクションで Elastic Disaster Recovery replication agent をインストールするために必要になります。 2. 手順 に従って、Elastic Disaster Recovery ターゲットアカウントの VPC に、Connected VPC から共有された Transit Gateway への Transit Gateway アタッチメントを作成します。各 AZ で Transit Gateway がトラフィックをルーティングするために使用するサブネット (例: vpc1_sn_A1 および vpc1_sn_B1) を1つ選択します。 3. ルートテーブルにルートを追加するための 手順 に従い、 vpc1_sn_A1 に関連付けられているルートテーブルにルートを追加します。宛先に SDDC と Connected VPC のプライベート IP アドレスを含む プレフィックスリスト を使用し、ルートのターゲットに共有された Transit Gateway を指定します。 SDDC と Connected VPC のネットワーキングとセキュリティの詳細を確認するには、 こちらの手順 に従います。 4. Elastic Disaster Recovery ターゲットアカウントの Elastic Disaster Recovery コンソール に移動します。ソースの VMware Cloud on AWS の VM に Elastic Disaster Recovery replication agent をインストールしたときに、 Elastic Disaster Recovery でデフォルトで適用される構成を設定します。 a. Set default replication settings を選択します。 Replication server configuration で、 Staging area subnet に vpc1_sn_A1 を、 Replication server instance type に small を選択します。 b. Next を選択し、 Volume and security groups で Amazon Elastic Block Store (Amazon EBS) ボリュームタイプ、 Amazon EBS 暗号化、セキュリティグループのデフォルトオプションを使用します。 c. Next を選択し、 Data routing and throttling タブと Point in time (PIT) policy でデフォルトオプションを使用します。 d. Next を選択し、 Create default を選択してデフォルトのレプリケーション構成を保存します。 5. こちら から VMware Cloud Services にログインし、 Inventory を選択して SDDC に移動します。 Open vCenter を選択し、デフォルトの資格情報を使って vCenter Web client にログインします。 こちらの手順 に従って、 VMware vSphere 7.0 で新しい VM を作成するか、 Elastic Disaster Recovery でサポートされているオペレーティングシステム を使った既存の VM を使用します。この例では、次の図に示すように Ubuntu Server 20.04 LTS (HVM) を使用しています。 図 2: ソースマシンとして使用される VMware on Cloud SDDC VM VM にログインして Elastic Disaster Recovery replication agent をインストールします。 a. Elastic Disaster Recovery agent インストーラーをダウンロードします: wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py b. Elastic Disaster Recovery agent インストーラーを実行します: sudo python3 aws-replication-installer-init.py c. agent のインストールプロセスでプロンプトが表示されたら、以下の情報を入力します。プロンプトに応答すると、インストールが成功したことが表示されます。 i. AWS Region Name : ターゲット Elastic Disaster Recovery アカウントの Elastic Disaster Recovery サービスのある　AWS リージョン (この場合は us-east-1) を入力します。 ii. AWS Access Key ID : 前提条件のセクション 1a の DRSUserAccessKeyId の値を入力します。 iii. AWS Secret Access Key : 前提条件のセクション 1a の DRSUserSecretAccessKey の値を入力します。 iv. Choose the disks you want to replicate プロンプトが表示されたら、Enter キーを押してすべてを選択します。 VMware 環境に VMware ユーザーを作成します。このユーザーは、DRSFA client によって使用され、フェイルバックに必要な VMware アクションを自動化します。 ここに記載 されている (前提条件の #16) 許可を持つ役割を vSphere で割り当てることで、このユーザに許可を与えます。この手順は、この VMware ビデオ または vSphere Client 7.0 での役割と許可の割り当て方法を説明した VMWare vSphere 7.0 ドキュメント に詳しく記載されています (‘ DRSFA ‘ は次の図のように表示されます)。 図 3: Elastic Disaster Recovery failback client が使用する VMware on Cloud SDDC ロールとパーミッション 最新の Elastic Disaster Recovery failback client をダウンロードし、次の図に示すように VMware Cloud on AWS SDDC データストア (‘ WorkloadDatastore → drsfa-lab ‘ の場合) にアップロードします。 図 4: Elastic Disaster Recovery failback client が使用するVMware on Cloud SDDC VM データストア (クライアントが使用する ISO ファイルを含む) テストと実行 このセクションでは、まず VMware Cloud on AWS ソースマシンからリカバリリージョンのターゲット Amazon Elastic Compute Cloud (Amazon EC2) へのフェイルオーバーを実演し、次に Elastic Disaster Recovery を使用して Amazon EC2 からの VMware Cloud on AWS へのフルリカバリーのためのフェイルバックを実演します。 フェイルオーバー us-east-1 リージョンの Elastic Disaster Recovery コンソール に戻ります。左側のパネルで Source servers を選択します。初期同期プロセスを確認するために、VMware Cloud on AWS の VM に対応するソースサーバーを選択できるはずです。初期同期には複数のタスクで構成されています。いつでも Elastic Disaster Recovery コンソールに戻ってデータレプリケーションの進捗状況を監視できます。初期同期が完了すると、ここの Data replication status が Healthy と表示されます。 初期同期プロセスが完了した後、 us-east-1 リージョンの Elastic Disaster Recovery コンソール で、左側のパネルから Source servers を選択します。 VMware Cloud on AWS VM ソースサーバーを選択し、 Launch settings を選択します。 a. General launch settings タブで、 Edit を選択し、 Instance type right sizing を ‘ None ‘ に設定して保存します。 b. EC2 launch template タブで、 Edit を選択して Amazon EC2 起動テンプレートを変更します。 i. Template version description に ” VMware Cloud on AWS launch template ” の説明を入力します。 ii. Instance Type タブで、 Manually select instance type を選択し、 c5.large を選択します。 iii. Network settings タブの Subnet セクションで、’ vpc1_sn_A2 ‘ プライベートサブネットを選択します。 Firewall セクションで、 Select existing security group を選択し、’ SG_BASTION ‘ セキュリティグループを選択します。 iv. 下にスクロールして Create template version を選択します。 v. 成功の通知ボックスで、作成したテンプレートバージョンへのリンクを選択します。 Actions を選択し、 Set Default Version を選択します。 Template version に ” vmwarecloudonawslaunchtemplate ” を入力し、 Set as default version ボタンを選択します。 Elastic Disaster Recovery を使用して、 VMware Cloud on AWS SDDC VM サーバーを Elastic Disaster Recovery ターゲットアカウントの us-east-1 にあるターゲットサーバーにフェイルオーバーを実行します。 a. us-east-1 リージョンの Elastic Disaster Recovery コンソール に移動します。左側のパネルで Source servers を選択します。 VMware Cloud on AWS の VM ソースサーバー (vmc-drs-vm) を選択し、右上のパネルから Initiate recovery job と Initiate Drill を選択します。 b. Select a point in time ページの Points in time で Use most recent data を選択します。下にスクロールして Initiate drill を選択します。 c. Elastic Disaster Recovery コンソールの左側のパネルから Recovery job history を選択して、ジョブログを監視し、起動が成功したことを確認します。 図 5: VMware Cloud on AWS の VM の復旧プロセスの詳細を示す Elastic Disaster Recovery のフェイルオーバージョブログ d. リカバリが完了したら、 VMware Cloud on AWS の VM ソースサーバーのリカバリプロセスの最終ステータスを確認できます。 図 6: VMware Cloud on AWS の VM のリカバリステータスを示す Elastic Disaster Recovery のリカバリダッシュボード フェイルバック vCenter Web client を使用して、手順に従って新しい VM を作成します。または、 DRSFA client の前提条件 で概説されているように、サポートされている Ubuntu Server 20.04 LTS オペレーティングシステムを使用する既存の VMware Cloud Services VM を使用します。 VM インスタンスが設定され、準備ができたら、 こちらの手順 に従って VM に DRSFA failback client をインストールし、前提条件と同じデータストアを使用します。 a. 手順の Generating IAM credentials and configuring CloudWatch logging セクションで、マネージドポリシー AWSElasticDisasterRecoveryFailbackPolicy を AWSElasticDisasterRecoveryFailbackInstallationPolicy に置き換えます。 b. 手順の Running the DRSFA client セクションで、 DRSFA client をインストールするために使用した環境変数を次に示します。データストアパスの構文と failback client および seed iso ファイルの相対パスに注意してください。 図 7: DRSFA failback client のインストールに使用した変数を示す VMware Cloud on AWS の VM シェル c. failback client を実行します: 図 8: Amazon EC2 リカバリインスタンスからのフェイルバックの開始準備ができたことを示す VMware Cloud on AWS の VM シェル failback client が正常にインストールされ、 Elastic Disaster Recovery とペアリングされたので、フェイルバックを実行します。 us-east-1 リージョンの Elastic Disaster Recovery コンソール に移動します。左側のパネルから Recovery instances を選択し、 VMware Cloud on AWS の VM ソースサーバー (vmc-drs-vm) に対応する Instance ID を選択します。 Failback state が Ready で Data replication status が Healthy であることを確認します。 図 9: Failback state が‘ Ready ’、Data replication status が‘ Healthy ’であることを確認しながら、 Elastic Disaster Recovery コンソールで Amazon EC2 リカバリインスタンスを選択してフェイルバックを実行 データレプリケーションプロセスを監視して、ソース VM が停止され、リカバリ EC2 インスタンスへの変換プロセスが開始されたこと、 Failback state が In Progress 、 Data replication status が Finalizing sync であることを確認します。これによりフェイルバックプロセスが完了し、ソース VM にレプリカインスタンスが作成されます。 図 10: フェイルバックの進捗状況を示し、 Failback state が ‘ In Progress ‘、Data replication status が ‘ Finalizing sync ‘ と表示されている Elastic Disaster Recovery コンソール フェイルバックが完了すると、ソース VM 上の failback client にフェイルバックが正常に完了したことが表示されます。 図 11: フェイルバックが正常に完了し、 Failback state が ‘ Completed ‘、Data replication status が ‘Completed’ と表示されているElastic Disaster Recovery コンソール クリーンアップ この投稿で概説したソリューションを試した後に継続的に課金されないように、アカウントをクリーンアップするには、以下の手順を実行します。 Elastic Disaster Recovery ターゲットアカウントの us-west-2 リージョンで、フェイルオーバー DR 環境を実行している EC2 インスタンスを終了するための手順 に従ってください。 Elastic Disaster Recovery ターゲットアカウント (BYOVPC VPC を含むアカウント) の us-west-2 リージョンで、 aws-vpcsetup-v1 テンプレートの CloudFormation スタックを削除 します。 まとめ この投稿では、 Elastic Disaster Recovery を使用して、 VMware Cloud on AWS に対してダウンタイムとデータ損失を最小限に抑え、コスト効率の高い DR ソリューションを提供する AWS ネイティブソリューションを実演しました。まず、 VMware Cloud on AWS ソースマシンからリカバリリージョンの Amazon EC2 ターゲットへのフェイルオーバーの手順を説明しました。次に、 VMware Cloud on AWS への完全なリカバリのために、 Elastic Disaster Recovery を使用した Amazon EC2 からのフェイルバックを実演しました。 オンプレミスで VMware を実行しているお客様は、潜在的な停止に備えて、ハイブリッド クラウド戦略に VMware Cloud on AWS を組み込むことが増えています。 VMware Cloud on AWS への移行のメリットは、アプリケーションを再構築またはリファクタリングすることなく、 VMware ワークロードを AWS 上で VMware マネージドの SDDC に迅速に移行できることですが、このブログ投稿では、お客様が Elastic Disaster Recovery を AWS ネイティブの DR ソリューションとして使用し、 VMware Cloud on AWS 環境での災害発生時にビジネス継続性を提供するという重要な検討事項をサポートする方法についても説明しました。 この投稿をお読みいただきありがとうございます。 翻訳はソリューションアーキテクト　澤が担当しました。原文は こちら です。

2024 年 1 月 4 日、データベースの講義で知られる CMU の Andy Pavlo 教授が 2023 年のデータベースレビュー を公開しました。主にベクトルデータベースの台頭に焦点を当てたものです。こうした革新的なデータストレージソリューションが注目を集めています。生成人工知能 (AI) モデルの人気が高まり続ける中、ベクトルストレージと検索機能を備えたデータベースに関心が寄せられています。ベクトルデータベースは、基盤モデル (FM) の機能を拡張するための費用対効果の高い仕組みを提供します。分散コンピューティング、クラウドベースのアーキテクチャ、特殊なハードウェアアクセラレータの進歩により、ベクトル検索機能をもつデータベースはさらに強力でスケーラブルになる可能性を秘めています。 本投稿では、生成 AI アプリケーションのデータベース選択において鍵となる要素について解説します。解説にあたっては、現在 AWS で利用可能なベクトル検索機能を備えたフルマネージドデータベースに関連する、高レベルの考慮事項とサービス特性に焦点を当てています。各データベースにおける動作とパフォーマンス面の差異を確認し、特定の要件に基づいて情報に基づいた決定を行う方法についてのガイダンスを提供していきます。これらの本質的な側面を理解することで、生成 AI ワークロードに最適なデータベースを選択し、最適なパフォーマンス、スケーラビリティ、および実装の容易さを達成するための準備を整えることができます。 Retrieval Augmented Generation Retrieval Augmented Generation (RAG) は、大規模言語モデル (LLM) の出力を最適化するプロセスで、応答を生成する前にトレーニングデータソース外の信頼できるナレッジベースを参照します。データベースは、モデルを再トレーニングする必要なく、LLM が持つ既存の強力な機能を、特定のドメインや組織内部のナレッジベースに拡張できます。RAG は、LLM の出力を様々な文脈で関連性、正確性、有用性を維持しながら改善する費用対効果の高いアプローチです。 以下の図は RAG ワークフローを示しています。 RAG ワークフローの主要なステップは以下の通りです。 処理されたデータソースからドキュメントチャンクが作成されます。テキストは埋め込みモデル ( Amazon Titan Text Embeddings V2 など) を介して、数値表現である 埋め込み に変換されます。これらの埋め込みはテキストの意図を含んでおり、元のドキュメントチャンクと共にベクトル検索に最適化されたデータベースに格納されます。 ユーザー入力は同じ埋め込みモデルを使用して埋め込みに変換されます。ユーザー入力埋め込みをクエリベクトルとして使用することで、データベース上でセマンティック検索が実行され、ベクトル空間での近さに基づいて上位 k 個の最も関連性の高いドキュメントチャンクが取得されます。取得されたチャンクは、後続の生成ステップのコンテキストとして機能します。 ユーザー入力はプロンプトとして使用されます。取得されたドキュメントチャンクはプロンプト拡張に使用されます。拡張されたプロンプトは基盤モデル ( Amazon Bedrock 上の Anthropic Claude 3 など) に送られ、事前トレーニングされた知識とデータベースから提供されたコンテキストに基づいて応答を生成します。生成された応答は、取得された情報により基づいた、文脈に沿った適切なものとなります。 RAG のデータベースを選択する際にはじめに考慮することの 1 つは、ユースケースに適したデータベースを決定することです。データベースと生成 AI に関する議論は広範かつ多面的であるため、本投稿では議論を簡略化し、主にベクトル検索機能を持つどのデータベースが適しているかの意思決定プロセスに焦点を当てています。LLM に関するガイダンスが必要な場合は、 Generative AI with LLMs を参照してください。 AWS のベクトル検索 このポストの公開時点で、AWS はベクトルストレージ、取得、インデックス、検索を含む完全なベクトル機能スイートを備えた以下のデータベースを提供しています。AWS はまた、 Knowledge Bases for Amazon Bedrock と統合されたデータベースも提供しています。 Amazon Aurora PostgreSQL-Compatible Edition と Amazon Relational Database Service (Amazon RDS) for PostgreSQL は、オープンソースの  pgvector  によるベクトル検索拡張機能を備えたフルマネージドリレーショナルデータベースです。Aurora PostgreSQL は Amazon Aurora Serverless v2 デプロイメントでもベクトル検索をサポートしています。 Amazon OpenSearch Service は、オープンソースの検索エンジンおよび分析スイートである OpenSearch を実行するためのフルマネージドサービスです。OpenSearch は、マネージドクラスターとサーバーレスコレクションの両方でベクトルエンジンによるベクトル検索をサポートしています。OpenSearch Service は Amazon OpenSearch Serverless デプロイメントオプションでもベクトル検索を利用可能です。 Amazon Neptune Analytics は、グラフアルゴリズムとベクトル検索を備えた分析グラフデータベースエンジンで、GraphRAG といったグラフと RAG の組み合わせを利用することができます。 Amazon DocumentDB (MongoDB 互換) のベクトル検索は、Amazon DocumentDB 5.0 インスタンスベースのクラスターで利用可能です。 Amazon MemoryDB の ベクトル検索 は、AWS 上の一般的なベクトルデータベースの中で最速のベクトル検索パフォーマンスを最高のリコール率で提供するインメモリデータベースです。MemoryDB は、最高レベルのリコールでも、一桁ミリ秒のベクトル検索・更新レイテンシーを実現します。 Amazon DynamoDB と OpenSearch Service のゼロ ETL 統合 は、 Amazon DynamoDB 上のデータに対して、全文検索やベクトル検索などの高度な検索機能を提供します。 以降のセクションでは、生成 AI アプリケーションに適したデータベースを選択するために役立つ主要な考慮事項について解説していきます。 親和性 実装の容易さ スケーラビリティ パフォーマンス 親和性 慣れ親しんだ技術を選択することが可能であれば、最終的に開発者の時間を節約し、複雑さを軽減できます。開発チームが特定のデータベースエンジンに既に精通している場合、ベクトル検索に同じデータベースエンジンを使用することで、既存の知識を活用してスムーズな体験を実現できます。新しいスキルセットを学ぶ代わりに、開発者は現在のスキル、ツール、フレームワーク、プロセスを活用して、既存のデータベースエンジンの新機能を含めることができます。 例えば、データベースエンジニアのチームが Aurora PostgreSQL でホストされている 100 のリレーショナルデータベースのセットを既に管理している場合、アプリケーションのベクトル検索要件をサポートする新しいデータベースを検討する際には、まず既存の Aurora PostgreSQL データベースで pgvector 拡張機能を評価することから始めるとよいでしょう。 同様に、チームがグラフデータを扱っている場合は、既存の AWS インフラストラクチャとシームレスに統合し、強力なグラフクエリと視覚化機能を提供する Neptune Analytics の使用を検討できます。 チームが JSON ドキュメントを扱い、スケーラブルでフルマネージドのドキュメントデータベースが必要な場合、Amazon DocumentDB は互換性のある馴染みのある MongoDB エクスペリエンスを提供し、既存のスキルと知識を活用できます。 チームが Redis OSS に精通しており、リアルタイムアプリケーション用の高度にスケーラブルなインメモリデータベースが必要な場合は、MemoryDB の使用を検討してください。MemoryDB は馴染みのある Redis OSS 互換インターフェースを提供し、チームは既存の Redis OSS の知識とクライアントライブラリを使用しながら、MemoryDB のフルマネージド、耐久性、スケーラブルな機能の恩恵を受けることができます。 これらの例では、データベースエンジニアリングチームは新しいデータベースソフトウェアを導入する必要がなく、より多くの開発者ツールや統合を追加する必要もありません。代わりに、彼らの専門分野内で新しい機能を有効にすることに集中できます。開発のベストプラクティス、運用、クエリ言語は同じままであり、成功の方程式における新しい変数の数を減らします。既存のデータベースを使用することのもう 1 つの利点は、セキュリティ、可用性、スケーラビリティ、信頼性、パフォーマンスに関するアプリケーションの要件に合致することです。さらに、データベース管理者は馴染みのある技術、スキル、プログラミングツールを使用できます。 現在の技術スタックにベクトル検索のサポートがない場合は、サーバーレスオファリングを活用してベクトル検索のニーズのギャップを埋めることができます。例えば、Amazon Bedrock コンソールでの クイック作成 エクスペリエンスを備えた OpenSearch Serverless を使用すると、クラスターを作成または管理する必要なく開始できます。この場合、新しい技術の導入は避けられませんが、サーバーレスを選択することで管理のオーバーヘッドを最小限に抑えることができます。 実装の容易さ 親和性以上に、実際にデータベースを実装する際に予期されるプロセスは、評価プロセスにおける次の主要な考慮事項となります。シームレスな統合プロセスは、中断を最小限に抑え、データベースの価値実現までの時間を短縮できます。このセクションでは、ベクトル化、管理、アクセス制御、コンプライアンス、インターフェースなどのコア実装の焦点領域にわたってデータベースを評価する方法を探ります。 ベクトル化 実装における最も重要な考慮事項は、ベクトル埋め込みでデータベースを投入するプロセスです。データがベクトルとして表現されていない場合、埋め込みモデルを使用してベクトルに変換し、ベクトルに対応したデータベースに格納する必要があります。例えば、OpenSearch Service を Amazon Bedrock のナレッジベース として使用する場合、生成 AI アプリケーションは Amazon Simple Storage Service (Amazon S3) に格納された非構造化データを取り、テキストチャンクとベクトルに変換し、自動的に OpenSearch Service に格納できます。 管理性 日々の管理性に対する要求は、全体実装における考慮事項となります。既存のチームのデータベース管理ワークロードに過度の負担をかけないデータベースを選択する必要があります。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージドデータベースの管理オーバーヘッドを負担することに代えて、Aurora Serverless v2 や OpenSearch Serverless などのベクトル検索をサポートするサーバーレスデータベースを選択することができます。 アクセス制御 既存のインフラストラクチャにベクトル検索を統合する際、アクセス制御は重要な考慮事項となります。現在のセキュリティ標準を遵守するために、潜在的なデータベースが提供するアクセス制御メカニズムを徹底的に評価する必要があります。例えば、非ベクトルの Amazon DocumentDB 実装に対して堅牢な ロールベースのアクセス制御 (RBAC) を有しているのであれば、ベクトル検索に Amazon DocumentDB を選択することは理想的といえます。既に確立されたアクセス制御要件に合致しているためです。 コンプライアンス コンプライアンス認証は、データベース選定における重要な評価基準です。データベースがアプリケーションの本質的なコンプライアンスニーズを満たさない場合、候補となりえません。AWS は 300 以上のセキュリティ、コンプライアンス、およびガバナンスサービスと機能を備えた深いクラウドセキュリティツールセットに支えられています。さらに、AWS は PCI-DSS、HIPAA/HITECH、FedRAMP、GDPR、FIPS 140-2、NIST 800-171 を含む 143 の セキュリティ基準とコンプライアンス認証 をサポートしており、世界中のほぼすべての規制機関のコンプライアンス要件を満たすのに役立ち、データベースがセキュリティ・コンプライアンス要求を満たすことを実現します。 インターフェース 生成 AI アプリケーションがデータベースと対話する方法は、実装におけるもう一つの考慮事項です。これはデータベースの一般的な使いやすさに影響を与える可能性があります。データベースへの接続方法と対話方法を評価し、ニーズを満たすシンプルで直感的なインターフェースを持つオプションを選択する必要があります。例えば、Neptune Analytics は API 呼び出しとストアドプロシージャを通じてベクトル検索を簡素化しており、合理化されたユーザーフレンドリーなインターフェースを優先する場合に魅力的な選択肢となります。詳細については、 Neptune Analytics でのベクトル類似性の操作 を参照してください。 統合 Knowledge Bases for Amazon Bedrock との統合は、データ取り込みとランタイムオーケストレーションワークフローを自動化したい場合に重要です。 Aurora PostgreSQL-Compatible と OpenSearch Service の両方が Knowledge Bases for Amazon Bedrock と統合されており、さらに多くの統合が予定されています。同様に、 Amazon SageMaker との統合により、ベクトル類似性検索、パーソナライズされた推奨、またはその他のベクトルベースの操作に依存するアプリケーションを構築するための、シームレスで、スケーラブルで、カスタマイズ可能なソリューションが提供されます。これは機械学習 (ML) と AWS 環境の力を活用しています。Aurora PostgreSQL と OpenSearch Service に加えて、 Amazon DocumentDB と Neptune Analytics も SageMaker と統合されています。 さらに、 LangChain や LlamaIndex などのオープンソースフレームワークは、LLM アプリケーションの構築に役立ちます。これらは強力なツール、抽象化、ユーティリティのセットを提供し、開発プロセスを簡素化し、生産性を向上させ、開発者が付加価値の高い機能の作成に集中できるようにします。LangChain は様々な AWS データベース、ストレージシステム、外部 API と シームレスに統合 されており、Amazon Bedrock とも統合されています。この統合により、開発者は LangChain フレームワーク内で AWS データベースと Bedrock のモデルを簡単に使用できます。LlamaIndex は Neptune Analytics をベクトルストアとグラフデータベースとしてサポートし、 GraphRAG アプリケーションの構築をサポートしています。同様に、 Hugging Face は BERT、GPT、T5 を含む幅広い事前トレーニング済みモデルを提供するポピュラーなプラットフォームです。Hugging Face は AWS サービスと統合 されており、AWS インフラストラクチャ上でモデルをデプロイし、OpenSearch Service、Aurora PostgreSQL-Compatible、Neptune Analytics、または MemoryDB などのデータベースと共に使用できます。 スケーラビリティ スケーラビリティは、プロダクションアプリケーションが中断なく効率的に実行できるようにするための、データベース評価における重要な要素です。ベクトルデータベースのスケーラビリティは、高次元ベクトルと膨大な数の埋め込みをサポートする能力と結びついています。各データベースは、リソース使用量の増加に対応するために異なるスケーリングメカニズムを持っています。例えば、Aurora PostgreSQL のスケーリングメカニズムとエンジニアリングは、OpenSearch Service や MemoryDB のスケーリングとは異なります。データベースのスケーリングメカニズムを理解することは、アプリケーションの継続的な成長を計画するために不可欠です。急速に成長する音楽推奨エンジンを構築しようとしている音楽会社の例を考えてみましょう。OpenSearch Service は、スケールアウト分散インフラストラクチャを提供することで、レコメンデーションエンジンのスケーラビリティを容易に制御可能なものにしています。同様に、グローバルな金融サービス企業は Amazon Aurora Global Database を使用して、パーソナライズされた投資推奨のためのスケーラブルで耐障害性のあるベクトル検索ソリューションを構築できます。1 つの AWS リージョンにプライマリデータベースをデプロイし、複数のセカンダリリージョンに複製することで、企業は高可用性、災害復旧、最小限のレイテンシーでのグローバルアプリケーションアクセスを提供しながら、世界中の顧客に正確でパーソナライズされたレコメンデーションを提供することができます。 AWS データベースは、多様なスケーリングメカニズムを備えた幅広いデータベースエンジンを提供し、ほぼすべての生成 AI 要件のスケーリング要求を満たすことに貢献します。 パフォーマンス もう 1 つの重要な考慮事項は、データベースのパフォーマンスです。組織が膨大な量の高次元ベクトル データから貴重な洞察を抽出しようと努めるにつれて、複雑なベクトル検索と操作を大規模に実行する機能は最も重要な要素となります。 スループット – 1 秒で処理できるクエリの数 再現率 – 取得されたベクトルの関連性と完全性、正確な応答の提供 インデックス構築時間 – ベクトルインデックスの構築に必要な時間 スケール・コスト – 数十億のベクトルを効率的にスケールしながら処理しつつ、コストパフォーマンスを維持する能力 p99 レイテンシ – リクエストの 99% の最大レイテンシ、応答時間の期待を満たす ストレージ使用量 – 高次元ベクトルのストレージがどれほど効率的に使用されるか、特に高次元ベクトルの場合に重要 例えば、金融商品のリアルタイム推奨エンジンを構築しているグローバルバンクは、確立されたエンドツーエンドのレイテンシ予算内に留まりながら、数万の同時ユーザーに対して一桁ミリ秒のレイテンシで高度に関連性のあるベクトル検索結果とエクスペリエンスを提供する必要があります。このシナリオでは、MemoryDB が正しい選択となります。インデックス作成技術の選択も、クエリパフォーマンスに大きな影響を与えます。 Hierarchical Navigable Small World (HNSW) や inverted file with flat compression (IVFFlat) などの近似最近傍 (ANN) ベースの技術は、他の k-NN 技術に比べて検索パフォーマンスとのトレードオフを行い、最も関連性の高い結果を返します。これらのインデックス作成方法を理解することは、特定のユースケースとパフォーマンス要件に最適なデータベースを選択するために不可欠です。例えば、 HNSW インデックスを使用した NVMe キャッシングによる Aurora Optimized Reads は、Optimized Reads を使用しないインスタンスと比較して、平均クエリスループットを最大 9 倍向上させることができます。 AWS は、アプリケーションのベクトル検索パフォーマンス要求を満たすために有用なデータベースを提供しています。これらのデータベースは、様々なパフォーマンス最適化技術と高度な監視ツールを提供し、組織がベクトルデータ管理ソリューションを微調整し、パフォーマンスのボトルネックに対処し、スケールで一貫したパフォーマンスを達成できるようにします。AWS のデータベースを使用することで、企業はベクトル検索要件の全ポテンシャルを解放し、リアルタイムの洞察、パーソナライズされたエクスペリエンス、成長とイノベーションを推進する革新的な AI および ML アプリケーションを実現できます。 高レベルのサービス特性 Well-Architected Framework の柱によってサポートされる、ベクトルワークロードを実行するための AWS のフルマネージドデータベースを選択することには、大きなメリットがあります。AWS インフラストラクチャのスケーラビリティ、セキュリティ、信頼性と、管理に関する運用の優秀性とベストプラクティスを組み合わせ、企業が確立されたデータベース技術を使用しながら、合理化された運用、軽減されたオーバーヘッド、ニーズの変化に応じてシームレスにスケールする能力の恩恵を受けられるからです。以下の特徴は、データベース評価プロセスにおいて重要であることが確認されたものです。 セマンティック検索 – セマンティック検索は、検索クエリの意味とコンテキストを理解し、より関連性の高い正確な結果を提供する情報検索技術です。セマンティック検索は、現在 AWS で提供されているベクトル検索機能をサポートする多くのデータベースでサポートされています。 サーバーレス – ユーザーの管理がほとんど、あるいは全く必要なく、効率的に需要を満たすようにデータベースが弾力的にスケールする能力です。サーバーレスは現在、OpenSearch Service と Aurora PostgreSQL で利用可能であり、両方とも完全に管理された RAG ワークフローを提供する Amazon Bedrock のナレッジベースと統合されています。 次元数 – 多くの AWS の顧客は、幅広い次元数にわたるオープンソースまたはカスタム埋め込みモデルを採用しています。例えば、Amazon Bedrock 上の Cohere Embed English v3 の 1,024 次元や、256、512、または 1,024 次元を選択できる Amazon Titan Text Embeddings V2 などのモデルがあります。ベクトル検索をサポートする AWS データベースは、これらのモデルのすべてでこれらの次元数をサポートしており、スケーラビリティと機能の新しい標準を提供するために継続的にイノベーションを行っています。 インデックス作成 – 顧客ベースの中で最も広く採用されているインデックス作成アルゴリズムは HNSW であり、ベクトル検索をサポートするすべての AWS データベースサービスが HNSW をサポートしています。IVFFlat インデックス作成方法も、これらのデータベースサービスのサブセットでサポートされています。 10 億スケールのベクトルワークロード – 2024 年から 2025 年にかけて、ベクトルワークロードがエンタープライズアプリケーションをサポートするために成長するにつれて、当社のデータベースサービスは 10 億スケールのベクトルワークロードを処理する準備が整っています。 関連性 – ユースケースによってアプリケーションを最適化するには、再現率によって測定されるベクトル検索結果の関連性も確認する必要があります。ベクトル検索をサポートするすべての AWS データベースサービスは、何らかの形で設定可能な再現率をサポートしています。 ハイブリッド検索と事前フィルタリング – 多くの顧客は、特定の製品カテゴリ、地理的領域、またはその他のデータサブセクションに焦点を当てるために、ベクトル検索クエリを事前および事後にフィルタリングする方法を考慮しています。AWS データベースサービスは、ハイブリッド検索または事前フィルタリング機能のレイヤーを提供しています。Aurora PostgreSQL、Amazon RDS for PostgreSQL、MemoryDB、OpenSearch Service など、いくつかのサービスは、一歩進んだ全文検索とハイブリッド検索機能を提供しています。 まとめ 生成 AI アプリケーションに適したデータベースの選択は、成功の鍵です。親和性、実装の容易さ、スケーラビリティ、パフォーマンスなどの要因が重要ですが、この急速に進化する分野でより具体的なガイダンスの必要性を認識しています。AWS マネージドデータベースポートフォリオにおける現状の認識と利用可能なオプションに基づき、以下の通り推奨事項を列挙します。 すでに OpenSearch Service、Aurora PostgreSQL、RDS for PostgreSQL、DocumentDB、または MemoryDB を使用している場合は、既存のデータに対して既存データベースが持つベクトル検索機能を利用してください。 グラフベースの RAG アプリケーションの場合は、Amazon Neptune を検討してください。 データが DynamoDB に格納されている場合、ゼロ ETL 統合を使用したベクトル検索には OpenSearch が優れた選択肢となります。 判断に迷う場合は、Amazon Bedrock のデフォルトのデータベースエンジンである OpenSearch Service をご検討ください。 生成 AI を取り巻く環境は流動的で、急速に進化し続けています。特定のデータセットと ML アルゴリズムを使用して異なるデータベースサービスをテストし、時間の経過とともにデータがどのように成長するかを考慮することをお勧めします。これにより、ワークロードに合わせてソリューションがシームレスにスケールできるようになります。 AWS は、それぞれ独自の強みを持つ多様なデータベースオプションを提供しています。AWS の強力なエコシステムを活用することで、組織はベクトルストレージと検索機能を備えた効率的でスケーラブルなデータベースでアプリケーションを強化し、イノベーションと競争優位性を推進できます。AWS はこの旅路をナビゲートするお手伝いをすることをお約束します。生成 AI の最適な進路を設計する上でさらに質問がある場合や支援が必要な場合は、 エキスパート チームにお問い合わせください。 著者について Shayon Sanyal は、プリンシパルデータベーススペシャリストソリューションアーキテクトであり、Amazon のフラッグシップリレーショナルデータベースである Amazon Aurora の SME (Subject Matter Expert) です。彼はリレーショナルデータベースと分析ワークロードの管理に 15 年以上の経験を持っています。Shayon は顧客成功への飽くなき献身を以て、顧客がスケーラブルで安全かつ堅牢なクラウドネイティブアーキテクチャを設計するのを支援しています。Shayon はまた、生成 AI などの先駆的な機能の設計と提供においてサービスチームを支援しています。 Graham Kutchek は、Amazon のすべてのデータベース製品にわたる専門知識を持つデータベーススペシャリストソリューションアーキテクトです。彼はメディアとエンターテインメント業界の専門家であり、世界最大のメディア企業の一部がスケーラブルで効率的かつ信頼性の高いデータベースデプロイメントを実行するのを支援しています。Graham は特にグラフデータベース、ベクトルデータベース、AI 推奨システムに焦点を当てています。 翻訳はソリューションアーキテクトの榎本が担当いたしました。原文は こちら です。

このブログは 2023 年 11 月 22 日に Neelima Kadirisani, Nidhi Gupta, and Pavel Shilov によって執筆された内容を翻訳したものです。原文は こちら を参照して下さい。 2022 年 11 月に報告された Gartner 社 の調査によると、87% の経営者が今後 2 年間で組織の持続可能性への投資を増やす予定であることが明らかになりました。このブログは、情報技術 (IT) チームに必要なリソースを提供し、経営陣と対話を始め、IT トランスフォーメーションを通じた炭素排出量削減の機会を強調する説得力のあるビジネスケースを準備することを目的としています。 組織は、温室効果ガス (GHG) 排出量の削減とカーボンニュートラルの達成に向けて真剣に持続可能性戦略に取り組んでいます。IT 組織が GHG 排出量削減の機会を探る中で、クラウドへの移行はこの目標に貢献する興味深い特徴的な展望として浮上しています。IT の炭素排出量の削減などのマイルストーンは、組織の持続可能性への取り組みにとって重要なものとなり得ます。Microsoft Windows Server と Linux は、世界中で最も広く使用されているサーバー向けのオペレーティングシステムです。このブログでは、Windows サーバーと Linux サーバーの炭素排出量削減に着目します。組織は同様の手順を適用して、他の種類のワークロードの炭素排出量削減も検討することができます。IT トランスフォーメーションの目標を達成するために、持続可能性に関する経営陣との議論では、以下の 4 つのステップをお勧めします。 第 1 ステップ – IT トランスフォーメーションの重要性の理解 温室効果ガス排出量削減に向けた第一歩は、自社の IT インフラのカーボンフットプリントがどの程度の大きさなのかを理解し、現在の温室効果ガス排出量レベルを測定することで基準を設定することです。 世界経済フォーラム の記事によると、データセンターのカーボンフットプリントは航空業界 (2.1%) よりも大きく、人為的な二酸化炭素排出量の 2.5% を占めています。組織の総カーボンフットプリントに対する IT の寄与は、業界、市場、バリューチェーンにおける位置づけなどの要因により 5〜10% の範囲で変動しますが、保険会社のような組織では 45% に達する可能性があります。 第 2 ステップ – 削減機会の探索 現在の排出量と排出源を把握した上で、オンプレミスのデータセンターのエネルギー効率向上を目指した取り組みを行うことが、二酸化炭素排出量削減への第一歩となり、電力使用効率 (PUE) が良好なコロケーションプロバイダーを選択することにつながります。しかし、オンプレミスのデータセンターは、Amazon Web Services (AWS) などの大手クラウドサービスプロバイダー (CSP) が享受している規模の経済性を備えていないことが多くあります。クラウドに関するビジネス・リーダーとの会話に使えるデータを探しているならば、再生可能エネルギー、エネルギー効率、新しいプロセッサーへの投資に関するお客様事例を以下に紹介します。 Bloomberg New Energy Finance によると、AWS は 2020 年以降、企業による再生可能エネルギーの最大の購入者の地位を維持しています。2022 年には、100% 再生可能エネルギー を利用した AWS リージョンは 19 になります。2022 年に世界中で、AWS は低炭素コンクリートを使用した 16 のデータセンターと、低炭素鋼を使用した 10 のデータセンターの建設を完了しました。 国際アナリスト企業である 451 Research による調査 では、オンプレミスのワークロードを AWS に移行することで、ワークロードのカーボンフットプリントを少なくとも 80% 削減できることが示されています。この数値は、AWS が 2025 年までに100% 再生可能エネルギーの目標を達成すれば、96% にまで上がる可能性があります。AWS のインフラストラクチャは、調査対象の米国企業データセンターの中央値よりも 3.6 倍エネルギー効率が高く、EU・アジア地域の平均よりも最大 5 倍効率的であることが示されています。クラウドが持つ動的にコンピューティングリソースを割り当てる機能により、需要に応じてサーバーをシームレスにスケールアップ・ダウンできるため、最適なエネルギー利用が可能になります。 IBM、Accenture、Deloitte、ATOS などのお客様が、クラウドへの移行を促すモチベーションとして、持続可能性が重要になってきていることを確認しています。ライフサイエンスツールやシステムの主要な開発・製造・販売会社である Illumina は、 最近のケーススタディ で、AWS を利用することで、炭素排出量を 89% 削減し、データストレージコストを削減できたと述べています。 AWS の持続可能性へのコミットメントには、より優れた価格性能と低エネルギー消費を実現するプロセッサの設計への投資が含まれます。 Graviton3 ARM プロセッサ を搭載した Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、同等のEC2 インスタンスと比較して最大 60% のエネルギーを節約できます。 AWS Inferentia の機械学習チップは最大 50% のエネルギー効率が高く、同等のインスタンスと比較して最大 90% のコスト削減が可能です。 上記の内容は、コロケーションプロバイダーや個別の組織が、大手クラウドプロバイダーと同様の競争力のある価格で再生可能エネルギーを調達し、持続可能なシリコンインフラストラクチャの構築に大規模に投資することが難しい可能性があることを示しています。オンプレミスまたはコロケーションのワークロードに対して、継続的な炭素排出量の最適化のみに依存しても、現在または将来的に大幅な炭素排出量の削減につながらない可能性があるため、AWS などのクラウドサービスへの移行が、IT オペレーションの持続可能性と効率性を高める上で、ますます魅力的なオプションになっています。 第 3 ステップ – カーボンフットプリントを計算するツールの評価 オンプレミスのサーバー台数を入力するだけで、炭素排出量の削減見積もりを生成できる炭素排出量削減計算ツールを見かけたことがあるかもしれません。しかし、そのような計算ツールの欠点は過度の単純化にあります。サーバーの実際の利用状況を考慮していないため、一般的な方向性しか示されません。移行後に予測された炭素排出量の削減が実現するという保証はありません。これらの計算ツールは、平均的な世界の炭素排出強度値に基づいて削減見積もりを提示しています。そのため、経済面と炭素排出量の両面で最適化するためのサーバー台数の調整に関する適切なガイダンスが得られない可能性があります。 AWS は、実際の消費量に基づいて IT 資産の炭素排出量削減とコスト削減に関するビジネスケースを構築するための自動化ツールを開発しました。 AWS Migration Evaluator (ME) は、お客様の実際の IT リソースの利用データを使用する無料のサービスとして提供されるアセスメントツールです。各アセスメントでは、オンプレミスまたはプライベートクラウドのワークロードを AWS に移行する際の予想コスト削減額が示され、既存のソフトウェアライセンスを再利用してさらにコストを削減できるインサイトが提供されます。 Migration Evaluator (ME) のビジネスケースに「持続可能性評価」が含まれるようになりました ( 成果物の例はこちら )。Microsoft、Linux、その他のワークロードを AWS に移行する場合、炭素排出削減量の見積もりが得られます。これにより、現在のオンプレミスと AWS 上の適切なサイズのワークロードの年間推定炭素排出量を比較することができます。オンプレミスのデータセンターの炭素排出量をすでに把握している場合、この評価ではお客様のデータを使用して、ワークロードの炭素排出量と移行による予測削減量を提供します。これにより、IT トランスフォーメーションによる節約率を比較・計算する自信がつきます。Migration Evaluator Directional ビジネスケースは、オンプレミスのワークロードをクラウドに移行することで得られる削減効果について、ビジネスの意思決定者に提示する際に使用できるビジュアルを提供します （下図参照）。 二酸化炭素排出削減量の計算に使用した方法 オンプレミスの炭素排出量を計算するには、CPU の使用率やハードウェアの仕様など、お客様データセンターの情報が使用されます。次に、ネットワークデバイスやストレージデバイスを考慮して、すべてのデバイスの総 IT 電力消費量が算出されます。冷却や照明などのデータセンター建物の負荷を考慮するために、業界標準の効率指標である電力使用効率 (PUE) が適用されます。その結果得られた電力消費量を年間エネルギーに換算し、外部ソースから地理的な特定の排出係数 (kg CO2 換算 /kWh) を乗じることで、お客様のオンプレミスのカーボンフットプリントが推定されます。 AWS の予測される炭素排出削減量の評価には、公式の AWS Customer Carbon Footprint Tool ( Carbon Methodology ) が採用している方法と同じ方法を用いて評価を行います。AWS Customer Carbon Footprint Tool の炭素排出データは、 温室効果ガス (GHG) プロトコル および ISO 規格に準拠しています。AWS 使用量のカーボンフットプリント推定には、スコープ 1 (直接事業からの排出) およびスコープ 2 (電力生産からの排出) のデータが含まれます。炭素排出についての詳細は、EPA の Scope 1 and Scope 2 Inventory Guidance を参照してください。 最後のステップ – 二酸化炭素排出削減のビジネスケースの作成 オンプレミスのワークロードをクラウドに移行することで二酸化炭素排出量を削減するには、現在の二酸化炭素排出量のベースラインを把握し、クラウドへの移行やモダナイゼーションによって削減できる見込み量を計算する必要があります。AWS Migration Evaluator アセスメントは、経営陣の意思決定に役立つ数字とストーリーを提供し、IT プロジェクトのサポートを得ることができます。どのクラウドサービスプロバイダーに移行するかに関わらず、このアセスメントではデータセンターの推定カーボン排出量が提供されます。 無料の AWS Migration Evaluator アセスメントは、 アセスメントリクエスト ページまたは AWS アカウントマネージャーからリクエストできます。AWS パートナーは、 AWS パートナーポータル からお客様のアセスメントをリクエストすることができます。 近年、多くの企業がオンプレミスのワークロードをクラウドコンピューティングに移行しており、さまざまな業界のお客様は、クラウド上での移行とモダナイゼーションにより、IT ワークロードの環境負荷を軽減する恩恵を受けています。AWS に移行する大きな利点の 1 つは、お客様の持続可能性への取り組みを加速できる可能性があり、これは環境への影響を懸念するエンドユーザを惹きつけ、維持する上で重要な要因となる可能性があります。このブログでは、持続可能な IT トランスフォーメーションへの取り組みを始めるためのステップバイステップのアプローチを紹介しました。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 利用可能なリソース AWS page to request business case AWS Migration Evaluator Modernization to facilitate energy customers building secure, scalable, and sustainable business AWS Customer Carbon Footprint Tool AWS Well-Architected Framework Sustainability Pillar 著者について Neelima Kadirisani Neelima Kadirisani は現在、Amazon Web Services (AWS) でシニア・サステナビリティ・ビジネス開発マネージャーを務めています。彼女は、ヨーロッパ、中東、アフリカ全域でクラウドテクノロジーを活用し、公共部門のお客様が持続可能な開発を加速するのを支援しています。Neelima は、さまざまな業界でサステナビリティのリーダーシップを経験しており、炭素排出量の削減、循環型経済のソリューション、環境・社会的な製品ライフサイクルアセスメントに精通しています。 Nidhi Gupta Nidhi Gupta は Amazon Web Services (AWS) のグローバル Go-to-Market 戦略のリーダーで、AWS における Microsoft ワークロードのモダナイゼーションに特化しています。AWS に加わる前は、SLB (旧シュルンベルジェ) で 13 年間、ベーカーヒューズ /GE デジタルで 3 年間の豊富な業界経験を積んでいました。また、シリコンバレーでゼロから収益性のある起業を 5 年間行い、技術面での経験も持っています。ニディは、デリーのインド工科大学 (IIT) で化学工学の学士号を取得し、シリコンバレーのスタートアップリーダーシッププログラムのフェローでもあります。ニディは持続可能性に情熱を持ち、お客様第一主義を信じ、技術とビジネスの専門知識を活かして AWS でクラウドの恩恵を最大化するよう組織を支援しています。 Pavel Shilov Pavel Shilov は Amazon Web Services (AWS) の EMEA 地域のサステナビリティ大使であり、ヨーロッパ、中東、アフリカ地域の公共機関向けの Go-to-Market ストラテジーの開発をリードしています。彼は、コストと持続可能性の観点からクラウド移行のビジネスケースを公共機関のお客様に支援し、IT マネージャーに対して経営陣との節約に関する対話の仕方をコーチングしています。AWS に加わる前は、セキュリティベンダーとマイクロソフトで Go-to-Market ストラテジーの開発を担当していました。Pavel はコンピューター科学の修士号を持ち、CEO やビジネス開発責任者からエンジニアリングチームまで、あらゆる層の人々と円滑にコミュニケーションを取ることができます。

本ブログは jinjer 株式会社様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの呉です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。本記事では、 Amazon Bedrock と Amazon Kendra を活用した、RAG (Retrieval Augmented Generation) の事例をご紹介します 。 RAG は、大規模言語モデル (LLM) の既に強力な機能を、モデルを再トレーニングすることなく、特定の分野や組織の内部ナレッジベースに拡張します。ビジネスで既に活用しているデータやドキュメントを活かし、回答精度の向上やハルシネーション（事実に基づかない回答）のリスクを軽減できる点から注目されています。(RAG の詳細は こちら ) この記事では jinjer 株式会社様がユーザーの体験向上に役立つ機能を 3 ヶ月という短い期間で開発された事例をご紹介いたします。 お客様の状況と検証に至る経緯 jinjer 株式会社は、人事労務・勤怠管理・給与計算・ワークフロー・経費精算など、人事関連業務の効率化を支援するクラウドサービス「ジンジャー」シリーズを SaaS 型で提供されています 。 カスタマーサクセス部門がジンジャーを利用する企業からヒアリングした結果、下記のような課題が見えてきました。 ・従業員が人事制度を確認する際に、就業規則から該当する情報を探す手間がかかる ・見つからない場合、それを人事担当者への問い合わせすることになるが、このような対応に少なくない工数がかかっている 前述の課題を解決するための機能を提供することで、ジンジャーを利用するユーザー体験の向上に繋げられると考え、 人事問い合わせ AI 機能 の開発をスタートしました。 ソリューション／構成 人事問い合わせ AI 機能はインフラストラクチャの管理、運用負荷の少ないマネージドサービスで構成されています。 （出展: jinjer 株式会社） 同機能の流れは以下です。 1. ジンジャーを利用する企業の管理者はジンジャーアプリ上で就業規則等のデータをアップロードする 2. 従業員からの就業規則等に関する質問を入力として Amazon Kendra へセマンティック検索でクエリする 3. 2 で得られた就業規則ドキュメント群を元にプロンプトを生成する 4. 3 のプロンプトを利用して Bedrock で回答文を生成する 上述の 2 で、就業規則ドキュメントを検索する際、検索対象を以下の条件に絞り込む必要があります。 ユーザーが属する企業のドキュメントのみ ユーザーが参照権限のあるドキュメントのみ この要件を満たすために、Amazon Kendra の Custom Document Enrichement 機能 を活用します。具体的には、下記のようなメタデータに企業情報などを追加しておくことで、検索クエリーにメタデータの条件を指定して検索対象ドキュメントを絞り込むことができるようになります。 return { "version" : "v0", "s3ObjectKey": <str>, "metadataUpdates": MetadataUpdates: [ { "name": "COMPANY", "value": { "stringValue": "c1234567" } }, { "name": "DEPARTMENT", "value": { "stringListValue": [ "department-1", "department-2" ] } }, { "name": "USER", "value": { "stringValue": "u9876543" } } ] } 導入効果 人事問い合わせ AI 機能のリリース後、以下の効果が得られると考えています。 AI を活用した人事業務の効率化により、従業員が自身で疑問を解決するための手間と、人事担当者が問い合わせに対応する手間を合わせて、80%の工数を削減見込み フルマネージドサービスの活用による保守運用負荷の軽減 なお、人事問い合わせ AI 機能の他にも、生成 AI のマルチモーダルを活用した新機能の開発も進められており、今後もユーザーの利便性向上のために生成 AI の活用の加速が見込まれます。 まとめ 今回は、人事 SaaS における各企業の就業規則やその他規程に関するデータを Amazon Bedrock と Amazon Kendra を活用して、SaaS 利用ユーザーの業務効率化を実現したお客様事例をご紹介いたしました。 本ソリューションは「社内のドキュメントを活用した人的コスト削減」という観点で同様な課題をお持ちのお客様に役立てていただけると思います。他にも、お客様からのお問い合わせ窓口、社内サポートデスクなどにご活用いただけます。ご関心のあるお客様は、ぜひ AWS までお問い合わせいただければと思います。 jinjer 株式会社 : 小原 拓実様（左から 2 番目）、安東 聡一郎様(右から 2 番目) Amazon Web Services Japan : アカウントマネージャー 稲葉 治樹（右端）、ソリューションアーキテクト 呉 敏禎（左端） ソリューションアーキテクト 呉 敏禎 ( X – @ kkam0907 )

本記事は、2024 年 7 月 5 日に公開された記事「 Empowering Manufacturing Innovation: How AI & GenAI Centers of Excellence can drive Modernization 」を翻訳したものです。 はじめに 機械学習（ML）、人工知能（AI）、生成 AI（GenAI）などのテクノロジーは、労働力を強化しながら、効率的で持続可能な製造業の新時代を切り開きます。AI を製造業に適用できる領域には、予知保全、欠陥検出、サプライチェーンの可視化、需要予測、製品設計などがあります。メリットとして、稼働時間と安全性の向上、無駄とコストの削減、業務効率の改善、製品と顧客体験の向上、市場投入までの時間の短縮などがあります。多くのメーカーが AI の導入を開始しています。 Georgia-Pacific はコンピュータビジョンを使用して、紙の破れを減らし、品質を向上させ、利益を数百万ドル増やしています。 Baxter は AI を利用した予知保全によって、1 つの施設だけで 500 時間のダウンタイムを防ぐことができました。 しかし、組織とテクノロジーの基盤が脆弱なため、多くの企業は AI を十分に活用できずにいます（最近の 世界経済フォーラムの調査 による）。その理由には、スキル不足、変化への抵抗、高品質なデータの不足、テクノロジー統合における課題などがあります。AI プロジェクトは パイロット段階で行き詰まり 、実稼働用に展開されないことがよくあります。AI と生成 AI テクノロジーをうまく活用するには、技術的な専門知識に加えて、文化的、組織的な側面からの総合的なアプローチが必要です。この記事では、AI Center of Excellence (AI CoE) が、AI と生成 AI の導入を通じてモダナイゼーションを加速するための包括的なアプローチをどのように提供するかについて説明します。 製造業における AI 導入の課題 製造業は、従来の物理的な世界（オペレーショナルテクノロジー、OT）とデジタルの世界（情報技術、IT）を融合させる必要があるため、AI 導入において特有の課題に直面しています。その課題には、文化的規範、組織構造、技術的制約が含まれます。 工場の担当者はミッションクリティカルな OT システムを扱っています。彼らは稼働時間と安全性を優先し、変化をリスクと認識しています。システムは（オープンなネットワークである）インターネットから分離されているため、サイバーセキュリティの優先度は高くありません。伝統的な工場のオペレーターは、長年の運用上の意思決定を通じて得た経験を頼りにしています。AI システムがどのように意思決定に至るかを理解することは、彼らの信頼を獲得し、導入の障壁を克服するために極めて重要です。工場のチームはサイロ化され、自律的で、現場のリーダーシップの下で運営されているため、AI の導入は困難です。AI システムとインフラへの初期投資は、アプローチによっては 多額の費用 がかかる可能性があり、多くのメーカーは費用を正当化するのに苦労する可能性があります。 AI は膨大な量の高品質データに依存しますが、多くの製造業では、このようなデータは断片化されていたり、古くなっていたり、アクセスできなかったりする場合があります。製造業におけるレガシーシステムは、ベンダー依存の独自ソフトウェアで実行されることが多く、標準以外のプロトコルやデータ形式を使用しているため、AI との統合が課題となっています。遠隔地ではインターネット接続が限られており、正確で信頼性の高いリアルタイムの応答に依存している製造システムはレイテンシーの課題を克服する必要があります。たとえば、AI システムは、製品が製造ラインを進むにつれて欠陥を特定するために、センサーデータとカメラ画像をリアルタイムで処理する必要があります。欠陥の検出がわずかでも遅れると、不良品が品質管理を通過する可能性があります。さらに、製造 AI システムは厳格な規制要件と業界標準を満たす必要があり、AI の開発および導入プロセスが複雑になります。AI の分野はまだ発展途上であり、ツール、フレームワーク、方法論の標準化をさらに進める必要があります。 リーダーシップの役割 変革的な AI の導入には、OT と IT の両方の上位層や意思決定者（以後、リーダー）のコミットメントと連携が必要です。OT リーダーは、接続されたスマートな産業オペレーションによって稼働時間、安全性、セキュリティ、信頼性を損なうことなく作業が簡素化されることを認識することでメリットを得られます。同様に、IT リーダーは、製造現場の要件の独自性を理解することで、AI テクノロジーを通じてビジネス価値を発揮できます。実際、OT は IT によって実現されるビジネス機能と見なすことができます。OT と IT の視点を統合することは、収益の増加、新製品、生産性の向上など、AI のビジネス価値を実現するために極めて重要です。リーダーシップは、AI を戦略目標に結び付ける明確なビジョンを策定し、機能的および文化的変革を推進するための協調的な文化を醸成する必要があります。 ビジョンは AI 導入の「理由（WHY）」を示しますが、AI 導入を成功させるにはビジョンを行動に移す必要があります。AI CoE はビジョンと行動のギャップを埋めることができます。 AI CoE による AI 導入とビジネス成果の加速 概要：AI CoE は、AI と製造分野に情熱を注ぐ専門家（Subject Matter Expert、SME）から構成される、複数の専門分野にまたがって責任ある AI 導入を推進するチームです。人間中心の AI を促進し、ベストプラクティスを標準化し、専門知識を提供し、従業員のスキルを向上させ、ガバナンスを確保します。エッジコンピューティングと最新のデータプラットフォームに重点を置いたモダナイゼーションロードマップを作成します。AI CoE は 2 ～ 4 人の小規模なメンバーから始め、必要に応じて規模を拡大することができます。AI CoE が成功するには、経営陣の支援と自律的に行動する能力が必要です。図 1 は、AI CoE の中核的な能力の概要を示しています。 図 1 AI CoE の能力 説明可能な AI AI CoE は、安全性と稼働時間が極めて重要な製造業において、説明可能な AI を推進する必要があります。たとえば、AI モデルが機器の故障を予測した場合、「故障の可能性が高い」または「故障の可能性は低い」などの二値的な AI 出力だけでは、工場の担当者の信頼を得ることはできません。代わりに、「ベアリングセンサーで検出された振動が 15% 増加したため、故障の可能性が高い。これは、過去のベアリング故障パターンに似ている」といった出力があれば、担当者は AI のアドバイスを信頼する可能性が高くなります。AWS は、 AI モデルの説明可能性 を高める複数の方法を提供します。 スキルの有効化、信頼の構築、透明性 AI CoE は、人事部門や経営陣と連携し、既存のスキルを活用するキャリアパスやトレーニングプログラムを開発することで、AI を活用した職場でスタッフのスキルを向上させる必要があります。生成 AI ソリューションは、AI が従業員の専門知識を補完する方法を示すことで、 スキル ギャップを埋めるのに役立ちます 。リーダーは、AI を活用することで、複雑な問題の解決や AI の洞察の解釈に費やす時間をどのように節約できるかを強調する必要があります。たとえば、 日立、エリクソン、そして AWS は、欠陥を検出するために手動検査よりも 24 倍多くのコンポーネントを同時に検査できるプライベート 5G ワイヤレスネットワークを活用して、コンピュータービジョンを実証しました。 ビジネス成果からの逆算（Working Backwards）、コラボレーション、サイロの打破 AI CoE は、AI ソリューションビルダーと工場のドメインエキスパート間のコラボレーションと共同決定権を確保、維持します。両者は協力してビジネス目標から逆算し、サイロを取り払い、AI ソリューションに収束し、望ましい結果を達成します。さらに CoE は、データの可用性、迅速な成功の可能性、ビジネス価値などの要素を評価して、インパクトのある AI ユースケースを特定するハブとして機能します。たとえば、繊維工場では、AI CoE はデータ分析を活用してエネルギー集約型のプロセスを最適化し、コスト削減と持続可能性のメリットを実現できます。AWS AI ユースケースエクスプローラー でその他のユースケースを調べてください。 ガバナンスとデータプラットフォーム ガバナンスとデータプラットフォームは、製造 AI の拡張に不可欠です。CoE は、データガバナンスやモデルライフサイクル管理など、責任ある安全で倫理的な AI の使用に関するポリシー、標準、プロセスを確立します。AWS は、 責任を持って AI ソリューションを構築およびデプロイするためのツール をいくつか提供しています。CoE は、さまざまなソースを接続し、リアルタイム分析、スケーラブルな AI を実現し、規制遵守を達成するための安全なデータプラットフォームを開発しています。このデータ基盤は、より広範な AI 導入の基盤となります。これは、 AWS 上の Merck の製造データおよび分析プラットフォーム によって実証されており、パフォーマンスが 3 倍になり、コストが 50% 削減しました。 AI テクノロジー、ツール、自動化 AI CoE は、製造のニーズ、要件、ベストプラクティスに基づいて、AI および GenAI のテクノロジー、ツール、ベンダーを評価および標準化します。AWS は、顧客体験を改革するソリューションを構築、デプロイ、管理するための包括的な AI および 生成 AI サービスのセットを提供します。AI の拡張には自動化が必要です。AI CoE は、手作業とエラーを減らし、市場投入までの時間を短縮する自動化されたデータおよびデプロイパイプラインを設計します。トヨタは、AWS サービスを使用して数百万台の車両からのデータを処理し、緊急時にリアルタイムで対応できるようにすることで、 大規模な AI 導入の例を示しています 。 CoEの効果測定 AI CoE の価値はビジネスの観点から測定する必要があります。そのためには、ハードメトリクスとソフトメトリクスの両方を組み合わせた総合的なアプローチが必要です。測定基準には、ROI、顧客体験の向上、効率性、製造業務の生産性向上などのビジネス成果を含める必要があります。社内調査では、従業員と利害関係者の AI に対する見方や態度、受け取り方を測定できます。これらの測定基準は、利害関係者が AI CoE と投資の価値を理解するのに役立ちます。 AI CoE の開始 図 2 AI CoE 基盤を構築するためのステップ AI CoE の設立には、図 2 に示すように段階的なアプローチが必要です。最初のステップは、OT と IT の両方のリーダーシップから経営陣のサポートを確保することです。次のステップは、現場の従業員と AI IT の専門家で構成される多様な専門家チームを編成することです。チームは AI のトレーニングを受けており、CoE の目的を定義します。彼らはパイロットユースケースを特定して提供し、価値を実証します。同時に、ガバナンスフレームワークを開発および強化し、トレーニングを提供し、コラボレーションを促進し、フィードバックを収集し、継続的な改善を繰り返します。生成 AI を統合すると、CoE のコンテンツ作成と問題解決能力がさらに強化され、企業全体で AI の導入が加速します。AI CoE は時間の経過とともに進化します。初期の段階では、専門知識を構築し、標準を設定し、パイロットプロジェクトを開始するなど、実践的な役割を担います。やがて、トレーニングを提供し、コラボレーションを促進し、成功指標を追跡するアドバイザーの役割に移行します。これにより、企業の労働力が強化がされ、長期的な AI 導入が保証されます。 終わりに AI および生成 AI テクノロジーは、革新的で新しい製品設計を生み出し、前例のないレベルの製造生産性を推進し、サプライチェーンアプリケーションを最適化する可能性があります。これらのテクノロジーを採用するには、技術的、組織的、文化的な課題に対処する総合的なアプローチが必要です。AI CoE は、ビジネスニーズと責任ある AI ソリューションのギャップを埋める触媒として機能します。そして、コラボレーション、トレーニング、データソリューションを促進して、工場の現場で効率を最適化し、コストを削減し、イノベーションを促進します。 追加資料 産業向け機械学習 AWS Industrial Data Platform (IDP) AWS Cloud Adoption Framework for Artificial Intelligence, Machine Learning, and Generative AI The organization of the future: Enabled by gen AI, driven by people Deloitte: 2024 manufacturing industry outlook World Economic Forum: Mastering AI quality for successful adoption of AI in manufacturing Harnessing the AI Revolution in Industrial Operations: A Guidebook Managing Organizational Transformation for Successful OT/IT Convergence The Future of Industrial AI in Manufacturing Digital Manufacturing – escaping pilot purgatory 著者： Nurani Parasuraman は AWS のカスタマーソリューションチームの一員です。人、プロセス、テクノロジーを横断する大規模なクラウドトランスフォーメーションへの基本的な移行を推進することで、企業が成功し、クラウド運用による大きなメリットを実現できるよう支援することに情熱を注いでいます。AWS に入社する前は、複数の上級管理職を歴任し、ファイナンスサービス、小売、通信、メディア、製造におけるテクノロジーの提供と変革を主導していました。財務のMBAと機械工学の理学士号を取得しています。 Saurabh Sharma は、AWS のテクニカルおよびストラテジック・シニアカスタマーソリューションマネージャー（CSM）です。彼は企業顧客のクラウド変革を支援するアカウントチームの一員です。この役割において、Saurabh はお客さまと協力してクラウド戦略と運用を推進し、クラウドへの迅速な移行に役立つワークロードの移行とモダナイズ方法についてソートリーダーシップを発揮し、イノベーションの文化を推進します。 Matthew は、北米の自動車・製造部門のカスタマーソリューション部門を率いています。彼と彼のチームは、人、プロセス、テクノロジーにわたる顧客の変革を支援することに重点を置いています。AWS に入社する前、マシューは、自動化と AI/ML テクノロジーを使用してオペレーションプロセスを変革する多くの組織の取り組みを主導していました。 翻訳は、カスタマーソリューションマネージャーの山泉が担当しました。

2024年7月16日、 開発事業者の公募が開始 された「 GENIAC (Generative AI Accelerator Challenge) 」における計算リソース提供者として、AWS が選定されました。 GENIAC は、 経済産業省 と 国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO) が推進する取り組みで、日本国内の生成 AI 基盤モデル開発力を底上げし、企業等の創意工夫を促すことを目的とするものです。今回の事業の助成額は245億円以内、 計算リソースの利用料等について、スタートアップ企業含む中小企業や学術機関等は2/3の、その他の企業・団体は1/2の助成が行われます。開発に必要な GPU リソース確保の方法は、「(1) 提案者が計算リソース提供事業者と個別に調整し直接確保」と「(2) 経済産業省が計算リソース提供事業者から一括で確保し提案者に提供」の2種類が設定されており、今回 AWS が選定されたのは (2) についてとなります。 今回の選定に関して、AWS に対してコメントを頂いていますのでご紹介します。 自民党が今年発表した「AI ホワイトペーパー 2024」で示したとおり、日本は「世界一 AI フレンドリーな国」を目指すべきと考えています。すなわち、世界で最も AI に理解があり、AI の研究開発・実装がしやすい国を、官民をあげて実現することです。日本の競争力を強化するためにも、高度な人材やインフラを基に、AI 研究開発力の強化と AI の利活用促進を一体的かつグローバルな視点で進めていく必要があります。GENIAC における計算リソースの提供を通じて、AWS が日本での AI イノベーションの推進に貢献することを大いに期待しています。 — 衆議院議員 自由民主党 デジタル社会推進本部 AIの進化と実装に関するPT 座長 平 将明 様 GENIAC における計算資源の提供支援（2サイクル目）では、より社会実装を見据えた生成 AI 開発を支援していきます。開発と利活用の好循環を迅速に生み出していくことが重要です。こうした中、計算資源提供の世界的企業であり、独自に生成 AI 開発企業への支援プログラムも展開されている AWS 様に、GENIAC への計算資源提供をコミットいただき、感謝いたします。計算資源活用のサポートのほか、GENIAC コミュニティ活動へのご貢献も期待しております。 — 経済産業省 商務情報政策局 情報処理基盤産業室長 渡辺 琢也 様 生成 AI の利活用を進めていくだけでなく、生成 AI のエンジンである基盤モデル自体の開発力を上げていくことは、日本全体として大変重要な課題です。そのために、経産省と NEDO が進めている GENIAC の取り組みに AWS が選定され、国内のさまざまな組織の開発力の強化のためにご尽力いただけることを大変嬉しく思っています。 — 東京大学大学院工学系研究科 技術経営戦略学専攻／人工物工学研究センター 教授 松尾 豊 様 AWS ではお客様からのご要望にお応えする形で様々なサービスの拡充に注力しており、生成 AI の活用に関するサービスも同様です。6月20-21日に開催された AWS Summit Japan の基調講演では、多数のお客様が本番運用という形で生成 AI による価値創造を開始していることを発表いたしました。なお、これはロゴ掲載に賛同いただいたお客様をご紹介したもので、他にも多くのお客様が、生成 AI による課題解決に取り組んでいらっしゃいます。 また、2023年に実施した AWS LLM 開発支援プログラム による国内の基盤モデル開発の支援や、生成 AI に取り組もうと考えるお客様を支援する AWS パートナー企業の拡充もすすめています。 GENIAC は基盤モデルの開発力向上と生成 AI の社会実装を目的としており、今回 AWS は前述 (2) の確保方法に向けて、 Amazon EC2 P5 インスタンス (p5.48xlarge) を提供することとなりました。Amazon EC2 P5 インスタンスは、NVIDIA H100 Tensor Core GPU を8基、GPU メモリを合計640GB (HBM3)、合計30 TB のローカル NVMe SSD ストレージ、Elastic Fabric Adapter (EFA) および NVIDIA GPUDirect RDMA (リモートダイレクトメモリアクセス) をサポートする 3,200 Gbps のネットワーク帯域幅を備えており、ますます複雑化する基盤モデルのトレーニングやデプロイに最適な計算リソースです。 AWS としては前述 (2) の確保方法への計算リソース提供と開発事業者の支援のみならず、前述 (1) の個別調整による直接確保する方法によって基盤モデルの開発に取り組む企業・団体についても、生成AIの開発・活用によるビジネス課題解決という目的を達成に資する、下記をはじめとする支援を提供します。 GPU 搭載インスタンスの提供はもちろん、(1) の確保方法においては AWS が開発した機械学習向けのアクセラレータである AWS Trainium , AWS Inferentia を搭載したインスタンスもご利用頂けます。加えて基盤モデル構築のための最適なインフラストラクチャをマネージド型で提供することにより、開発者がインフラストラクチャの構築・管理ではなく開発作業に注力できるようにする Amazon SageMaker HyperPod もご用意しています。 また、AWS は計算リソースの提供にとどまらず、分散学習環境や技術やノウハウを学習する機会の提供、生成 AI による課題解決のためのガイダンス提供、生成 AI ソリューションの事業化支援、お客様同士の情報交換の活性化などの活動を一層加速していく計画です。 GENIAC への参加・申請を考えるお客様は、下記よりお問い合わせください。 AWS ジャパン GENIAC 支援チーム (画像形式になっていますので、大規模視覚言語モデルでの読み取りや手打ちをお願いします) 参考: AWS の生成 AI に対する考えとアプローチ AWS は、生成 AI が新しい体験の創造、生産性の向上、データからの洞察の獲得など、様々なビジネス上の価値につながるポテンシャルを持っていると考えています。AWS はお客様からのフィードバックに基づき開発する機能の決定や優先順位付けを行っています。ゆえにお客様の生成 AI に対する関心の高まりを受けて、生成 AI による課題解決・ビジネス価値創出に取り組むお客様のためのサービス・機能の開発に注力しています。 AWS が提供する生成 AI 関連サービスは、3つのレイヤーに分けて整理し、お客様にご提供しています。 お客様は、どういった価値を実現したいか、どの程度の規模の開発作業が可能か、などの要素に基づいて最適なサービスを選択して利用することができます。図中で上段に表されているのが、生成 AI の技術を組み込んだ完成品のアプリケーションとして提供されるサービスで、 Amazon Q がそれにあたります。中段に位置するのが、お客様のアプリケーションやシステムに生成 AI を支える基礎技術である基盤モデル (Anthropic Claude や Meta Llama などの大規模言語モデル含む) を容易に組み込むことができるツールである、 Amazon Bedrock です。そして、下段が基盤モデル自体のトレーニングや推論に利用されるインフラストラクチャーのサービス群です。 また、生成 AI によってビジネスや社会の課題を解決するためには、戦略策定や生成 AI を組み込んだアプリケーション全体のコスト最適化、サービス提供企業・団体の事業化などの要素が必要不可欠だと考えています。そのため、提供サービスの拡充・強化だけでなく真に生成AIが利用され、価値を生んでいくために必要な支援を提供します。 アマゾン ウェブ サービス ジャパン合同会社

注記: お客様は自身の GitHub ランナーを管理する必要がなくなりました。AWS CodeBuild を使用すると、管理された GitHub Actions セルフホストランナーを利用できるようになり、強力なセキュリティ境界と低い起動レイテンシーを備えた一時的でスケーラブルなランナー環境を提供します。CodeBuild を使えば、独自のインフラストラクチャを維持したり、スケーリングロジックを構築する必要がありません。すべてが CodeBuild によって完全に管理されます。開始するには、単に Webhook を作成して、 CodeBuild で GitHub Actions ジョブ を自動的にトリガーするだけです。 概要 GitHub Actions は、ワークロードのビルド、テスト、デプロイ活動を自動化できる継続的インテグレーションおよび継続的デプロイプラットフォームです。 GitHub セルフホステッドランナー は、GitHub Actions パイプラインを実行するための柔軟でカスタマイズ可能なオプションを提供します。これらのランナーを使用すると、独自のインフラストラクチャ上でビルドを実行でき、コードのビルド、テスト、デプロイ環境を制御できます。これにより、セキュリティリスクとコストを削減し、GitHub ホステッドランナーでは利用できない特定のツールやテクノロジーを使用できるようになります。このブログでは、AWS 環境に GitHub セルフホステッドランナーをデプロイする際に考慮すべきセキュリティ、パフォーマンス、コストのベストプラクティスを探ります。 ベストプラクティス あなたのセキュリティにおける責任を理解する GitHub のセルフホステッドランナーは、設計上、ワークフロースクリプトやリポジトリのビルドプロセスを通じて、 GitHub リポジトリ内で定義されたコードを実行します。 AWS ランナー実行環境のセキュリティは、 GitHub の実装のセキュリティに依存することを理解する必要があります。 GitHub のセキュリティの完全な概要は本ブログの範囲外ですが、 GitHub の環境を AWS の環境と統合する前に、少なくとも以下の GitHub のセキュリティ設定を確認し、理解することをお勧めします。 GitHub のユーザーを連携し、ディレクトリを通じてアイデンティティのライフサイクルを管理します。 GitHub リポジトリの管理特権を制限し、権限を管理できるユーザー、リポジトリへの書き込み、リポジトリ設定の変更、GitHub アプリのインストールを制限します。 セルフホステッドランナーの登録と、グループ設定への制御を制限します。 GitHub ワークフローへの制御を制限し、 サードパーティのアクションを使用する際は GitHub の推奨事項に従います 。 パブリックリポジトリからセルフホステッドランナーへのアクセスを許可しません。 一時的なAWS 認証情報を使用してセキュリティリスクを軽減する できるだけ一時的な認証情報を使用してください 。デフォルトで1時間以内に期限切れになり、ローテーションさせたり明示的に取り消す必要はありません。一時的な認証情報は、 AWS Security Token Service (STS) によって作成されます。フェデレーションを使用してAWSアカウントにアクセスする場合、 assume role 、または Amazon EC2 インスタンスプロファイルや Amazon ECS タスクロールを使用する場合は、すでに STS を使用しています。 ほとんどの場合、 AWS で「実行」されないサービスでも、一時的でない AWS Identity and Access Management (IAM) 認証情報 (アクセスキー) は必要ありません。 AWS の外部のワークロードに IAM ロールを拡張でき、長期的な認証情報を管理する必要がなくなります。 GitHub Actions では、 OpenID Connect (OIDC) を使用することをお勧めします。 OIDC は分散型認証プロトコルで、 sts:AssumeRoleWithWebIdentity を使って STS によってネイティブにサポートされています。 GitHub やその他の多くのプロバイダーもサポートしています。 OIDC を使えば、個々の GitHub リポジトリとそれらの対応するアクションに最小特権の IAM ロールを作成できます。 GitHub Actions はこの目的で利用できる OIDC プロバイダーを各アクションの実行に公開 しています。 一時的な AWS 認証情報と GitHub セルフホステッドランナー 個別にロールを付与したいリポジトリが多数ある場合、単一のアカウントでの IAM ロールの数に制限に達する可能性があります。私は マルチアカウント戦略でこの問題を解決 することを提案しますが、かわりに以下に挙げるアプローチで拡張することもできます: 属性ベースのアクセス制御 (ABAC) を使用して、GitHub トークン内の要求 (リポジトリ名、ブランチ、またはチームなど) を AWS リソースタグと照合する。 GitHub のリポジトリをチームまたはアプリケーションに論理的にグループ化することで、役割のサブセットを少なくするための役割ベースのアクセス制御 (RBAC) を使用します。 GitHub ワークフローに提供されたIDに基づいて、 ID ブローカーパターン を使用して認証情報を動的に提供します。 エフェメラルランナーを使用する GitHub Action のランナーを「エフェメラル」モードで実行するように設定します。これによりジョブごとに要求に応じて個別の一時的な実行環境が作成 (および破棄) されます。この短い環境の存続期間とビルドごとの分離により、マルチテナントの継続的インテグレーション環境であっても基盤となるホストで各ビルドジョブが他のジョブから分離されているため、データ漏洩のリスクが軽減されます。 ジョブごとに新しい環境がオンデマンドで作成されるためアイドル状態のランナーを待つ必要がなく、auto-scalingが簡単になります。オンデマンドでランナーをスケーリングできるため、ビルドインフラストラクチャを不要な時 (例えば営業時間外) に停止する必要がなくコスト効率の良い設定が可能です。さらに最適化するには、開発者がワークフローにインスタンスタイプタグを付けて、それぞれのワークフローに最適なインスタンスタイプを起動できるようにすることを検討してください。 エフェメラルランナーを使用する際には、いくつかの考慮事項があります: ジョブはランナー EC2 インスタンスが起動し、準備が整うまでキューに残されます。これには最大 2 分かかる場合があります。このプロセスを高速化するには、前提条件がすべてインストールされた最適化された AMI を使用することをご検討ください。 各ジョブが新しいランナーで起動されるため、ランナーでキャッシングを利用することはできません。例えば、 Docker イメージやライブラリは常にソースから取得されます。 ランナーグループを使用しセキュリティ要件に基づいてランナーを分離する 単一の GitHub ランナーグループでエフェメラルランナーを使用すると、そのランナーグループを共有するすべてのリポジトリで使用される同じ AWS アカウントのリソースプールを作成することになります。組織のセキュリティ要件により、実行環境をリポジトリごとやデプロイ環境 (開発、テスト、本番など) ごとにさらに分離する必要がある場合があります。 ランナーグループを使うと、リポジトリごとにワークフローを実行するランナーを定義できます。複数のランナーグループを作成すると、さまざまな種類のコンピューティング環境を提供できるだけでなく、ワークフローの実行を相互に分離された AWS の場所に配置できます。たとえば開発ワークフローを1つのランナーグループに、テストワークフローを別のランナーグループに配置することができ、それぞれのエフェメラルランナーグループは別の AWS アカウントにデプロイされます。 ランナーとは、 GitHub ユーザーに代わってコードを実行するものです。 最低限、エフェメラルランナーグループを AWS アカウントに含め、この AWS アカウントの組織の他のリソースへのアクセスを最小限に抑えることをお勧めします。 組織のリソースへのアクセスが必要な場合は、 OIDC による IAM ロールの引き受けを通じて、リポジトリごとに付与できます。そしてこれらのロールには、必要なリソースに対する最小特権アクセスのみを与えることができます。 Amazon EC2 ウォームプールを使用してランナーの起動時間を最適化する エフェメラルランナーは、強力なビルド分離、シンプルさ、セキュリティを提供します。ランナーは必要に応じて起動されるため、ジョブはランナーの起動と GitHub への登録を待つ必要があります。通常 2 分以内に行われますが、この待ち時間はある状況では許容できない可能性があります。 事前に登録されたエフェメラルランナーのウォームプールを使用すると、待ち時間を短縮できます。これらのランナーは、 GitHub ワークフローイベントの受信を積極的に待ち受け、ワークフローイベントが発生するとすぐに、登録済みの EC2 ランナーのウォームプールでピックアップされます。 ウォームプールを管理するための複数の戦略がありますが、 AWS Lambda を使ってエフェメラルランナーをスケールアップ・ダウンする以下の戦略をお勧めします: GitHub セルフホステッドランナーのウォームプールの流れ GitHub ワークフローイベントは、マスターリポジトリへのコードのプッシュやプルリクエストのマージなどのトリガーで作成されます。このイベントは、Webhook と Amazon API Gateway エンドポイントを介して Lambda 関数をトリガーします。Lambda 関数は、GitHub ワークフローイベントペイロードの検証とオブザーバビリティ用のイベントログ、メトリクスの構築に役立ちます。オプションで、ウォームプールの補充にも使用できます。ウォームプールの EC2 インスタンスを起動、スケールアップ、スケールダウンするための別の バックエンド Lambda 関数があります。EC2 インスタンス (ランナー) は起動時に GitHub に登録されます。登録されたランナーは、GitHub の内部ジョブキューを使って着信の GitHub ワークフローイベントをリッスンし、ワークフローイベントがトリガーされるとすぐに、ウォームプールの 1 つのランナーにジョブの実行が割り当てられます。ジョブが完了すると、ランナーは自動的に登録解除されます。ジョブは、GitHub ワークフローで定義されたビルドやデプロイリクエストです。 ウォームプールを導入することで、待ち時間が 70〜80% 短縮されることが期待されます。 考慮事項 ランナーのオーバープロビジョニングの可能性があるため、複雑さが増します。これは、ランナーの EC2 インスタンスが起動して準備完了状態に達するまでの時間と、スケールアップ Lambda が実行される頻度に依存します。例えば、スケールアップ Lambda が 1 分ごとに実行され、 EC2 ランナーの起動に 2 分かかる場合、スケールアップLambdaは 2 つのインスタンスを起動します。これを軽減するには、 Auto Scaling グループを使用して EC2 ウォームプールと所望の容量を管理し、 GitHub ワークフローイベント(ビルドジョブリクエストなど)に基づく予測スケーリングポリシーを関連付けます。 この戦略は、Windows または Mac ベースのランナーをサポートする場合、起動時間が変わる可能性があるため、修正する必要があるかもしれません。 GitHub セルフホステッドランナーの起動を高速化するために最適化された AMI を使用する Amazon Machine Images (AMI) は、ランナーの EC2 インスタンスを起動するために使用できる、事前構成され最適化されたマシンイメージを提供します。AMI を使用することで、依存関係とツールがすでにインストールされているため、新しいランナーの起動時間を短縮できます。すべてのインスタンスが同じバージョンの依存関係とツールを実行するため、ビルド間の一貫性が保証されます。マシンイメージはランナーインスタンスとして使用される前にテストおよび承認されるため、ランナーは安定性と セキュリティコンプライアンスの向上の恩恵を受けることができます。 GitHub のセルフホステッドランナーとして使用する AMI を構築する際には、以下の点に留意する必要があります: ビルドに適切な OS ベースイメージを選択します。これはご利用されている技術スタックとツールセットに依存します。 イメージの一部として GitHub ランナーアプリをインストールします。ランナーの管理オーバーヘッドを減らすために、自動ランナー更新を有効にしてください。特定のランナーバージョンを使用する必要がある場合は、テストされていない変更を回避するために ランナーの自動更新を無効 にすることができます。無効にした場合、新しいバージョンが利用可能になった後 30 日以内にランナーを手動で更新する必要があることに注意してください。 信頼できるソースからビルドツールと依存関係をインストールします。 ランナーログがキャプチャされ、選択した SIEM (Security Information and Event Management )に転送されることを確認します。 ランナーには GitHub にアクセスするためのインターネット接続が必要です。これには、ネットワーク設定に応じてインスタンスでプロキシ設定を構成する必要がある場合があります。 ランナーが必要とするあらゆるアーティファクトリポジトリを構成します。これにはソースと認証が含まれます。 EC2 Image Builder などのツールを使用して、AMI の作成を自動化し、一貫性を実現します。 スポットインスタンスを利用してコストを削減する ランナーのスケーリングアップおよびホットプールの維持に関連するコストは、オンデマンド価格と比較して最大 90% の節約につながる スポットインスタンス を使用することで最小限に抑えることができます。ただし、 2 分間の通知でスポットインスタンスが終了することを許容できない、長時間実行されるビルドやバッチジョブが必要となる場合があります。そのため、そのようなジョブはオンデマンド EC2 インスタンスにルーティングし、その他のジョブはスポットインスタンスで処理するという、インスタンスの混合プールを持つことが適切なオプションとなります。これは、ランナーの起動 / 登録時に ラベルを割り当てる ことで実現できます。その場合オンデマンドインスタンスが起動され、コスト削減のために Savings Plans を適用することができます。 Amazon CloudWatch を使用して、監視のためのランナーメトリクスを記録する EC2 ベースの GitHub セルフホステッドランナーのメトリクスを生成することは、全体的なプラットフォームの可観測性にとって非常に重要です。GitHub ランナーのメトリクスの例としては、1 分間に待機中または完了した GitHub ワークフロー イベントの数、ウォームプールで起動して利用可能な EC2 ランナーの数などがあります。 トリガーされたワークフローイベントとランナーログを Amazon CloudWatch に記録し、 CloudWatch の組み込みメトリクス を使用して、キューイングされたワークフローイベント数、進行中のイベント数、完了したイベント数などのメトリクスを収集できます。ワークフローイベントペイロードの一部である “started_at” と “completed_at” のタイミング要素を使用すると、ビルド待ち時間を計算できます。 例として、以下は Amazon Cloud Watch Logs に記録された GitHub ワークフローイベントのサンプルです。 { "hostname": "xxx.xxx.xxx.xxx", "requestId": "aafddsd55-fgcf555", "date": "2022-10-11T05:50:35.816Z", "logLevel": "info", "logLevelId": 3, "filePath": "index.js", "fullFilePath": "/var/task/index.js", "fileName": "index.js", "lineNumber": 83889, "columnNumber": 12, "isConstructor": false, "functionName": "handle", "argumentsArray": [ "Processing Github event", "{\"event\":\"workflow_job\",\"repository\":\"testorg-poc/github-actions-test-repo\",\"action\":\"queued\",\"name\":\"jobname-buildanddeploy\",\"status\":\"queued\",\"started_at\":\"2022-10-11T05:50:33Z\",\"completed_at\":null,\"conclusion\":null}" ] } 上記のログから \”status\”:\”queued\”,\”repository\”:\”testorg-poc/github-actions-test-repo\c, \”name\”:\”jobname-buildanddeploy\” ,and workflow \”event\” の要素を取り込んでメトリクスを使用するには、選択した言語に基づいた CloudWatch メトリクスクライアントライブラリを使用して、アプリケーションコードまたは メトリクスを送信するための Lambda を利用して埋め込みメトリクスを構築できます。( クライアントライブラリを使用した埋め込みメトリクス形式でのログの作成 ) 原則それらのライブラリの 1 つが内部で行うのは、ログイベントから要素をディメンションフィールドにマップすることで、CloudWatch がそれを読み取りメトリクスを生成することができるようになります。 console.log( JSON.stringify({ message: '[Embedded Metric]', // Identifier for metric logs in CW logs build_event_metric: 1, // Metric Name and value status: `${status}`, // Dimension name and value eventName: `${eventName}`, repository: `${repository}`, name: `${name}`, _aws: { Timestamp: Date.now(), CloudWatchMetrics: [{ Namespace: `demo_2`, Dimensions: [ ['status', 'eventName', 'repository', 'name'] ], Metrics: [{ Name: 'build_event_metric', Unit: 'Count', }, ], }, ], }, }) ); サンプルアーキテクチャー GitHub Webhook イベントの処理 CloudWatchメトリクスは、要件に基づいてダッシュボードに公開したり、外部ツールに転送したりできます。メトリクスを取得できれば、CloudWatchアラームと通知を構成して、プールの枯渇を管理できます。 まとめ このブログ記事では、AWS の EC2 セルフホステッドランナーを使用する際のセキュリティ、スケーラビリティ、コスト効率性に関するベストプラクティスをいくつか説明しました。一時的な認証情報とエフェメラルランナーを組み合わせることで、セキュリティとビルド汚染のリスクを軽減できることを説明しました。また、AMI と EC2 ウォームプールを使用することで、ランナーの起動とジョブ実行を高速化できることも示しました。最後に、適切なシナリオでランナーにスポットインスタンスを使用することで、コスト効率を最大化できることを説明しました。 リソース: Use IAM roles to connect GitHub Actions to actions in AWS Integrating with GitHub Actions – CI/CD pipeline to deploy a Web App to Amazon EC2 Creating logs in embedded metric format using the client libraries – Amazon CloudWatch GitHub – awslabs/aws-embedded-metrics-node: Amazon CloudWatch Embedded Metric Format Client Library GitHub – philips-labs/terraform-aws-github-runner: Terraform module for scalable GitHub action runners on AWS 本ブログはソリューションアーキテクトの紙谷が翻訳しました。原文は こちら です。

予想されていたとおり、 AWS Summit ニューヨーク では、たくさんのエキサイティングなリリースやアップデートが発表されました。 AWS Summit ニューヨーク 2024 年注目の発表 のハイライトをご覧ください。 私の同僚で、AWS ニュースブログのライター仲間でもある Veliswa Boya と Sébastien Stormacq は、先週 AWS Community Day カメルーン に出席しました。クラウドテクノロジーについて積極的に学び、意見交換を楽しむ素晴らしい専門家、メンター、学生と出会い、素敵な時間を過ごしたとのことです。 動画再生にアクセス すると、その場の雰囲気を感じ、講演の一部を視聴することができます。 7月8日週のリリース ニューヨーク Summit でのリリースに加えて、私が注目したものをいくつかご紹介します。 Amazon Bedrock の高度な RAG 機能ナレッジベース – これには、お客様が独自のチャンキングコードを Lambda 関数として記述できるようにするカスタムチャンキングオプション、テーブルなどの複雑なデータから情報を抽出するスマート解析、クエリをより単純なサブクエリに分割して、それぞれに関連する情報を取得し、その結果を最終的な包括的な回答にまとめるクエリ再定式化が含まれます。 Amazon Bedrock Prompt Management と Prompt Flows – 開発者とプロンプトエンジニアが各々のユースケースについて基盤モデルから最適なレスポンスを得るのに役立つ、Prompt Management のプレビュー版です。Prompt Flows では、直感的なビジュアルビルダーを使用して、ワークフローの作成、テスト、デプロイを加速できます。 Amazon Bedrock での Anthropic の Claude 3 Haiku の微調整 (プレビュー) – 独自のタスク固有のトレーニングデータセットを提供して、 Claude 3 Haiku を微調整およびカスタマイズし、モデルの精度、品質、一貫性を高め、生成 AI をビジネスに合わせてさらに調整できます。 Amazon Q Developer チャットでの IDE ワークスペースコンテキスト認識 – Q Developer のチャットメッセージに @workspace を追加して、現在 IDE で開いているプロジェクトのコードについて質問できるようになりました。Q Developer は、すべてのコードファイル、構成、プロジェクト構造を自動的に取り込んでインデックスを作成し、IDE 内のアプリケーション全体におよぶ包括的なコンテキストをチャットに提供します。 Amazon Q Business の新機能 – Amazon Q Business の新しいパーソナライゼーション機能 が自動的に有効になります。企業の従業員プロファイルデータを使用して、ユーザーエクスペリエンスを改善できます。OCR を前処理やテキスト抽出に使用することなく、 スキャンした PDF のテキストコンテンツや PDF 文書に埋め込まれた画像から回答を得る ことができるようになりました。 AWS Graviton4 を搭載した Amazon EC2 R8g インスタンスの一般提供 – Amazon EC2 R8g インスタンスは、データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、メモリを大量に消費するワークロードに適しています。これらは AWS Graviton4 プロセッサを搭載しており、AWS Graviton3 ベースのインスタンスと比較してパフォーマンスが最大 30% 向上しています。 Amazon MemoryDB のベクトル検索の一般提供 – MemoryDB のベクトル検索により、リアルタイムの機械学習 (ML) と生成 AI アプリケーションが可能になります。1 桁ミリ秒単位のクエリで数百万ものベクトルを保存し、99% 以上のリコール率かつ最高レベルのスループットでレイテンシーを更新できます。 Valkey および Redis オープンソース用のオープンソースクライアントライブラリ、Valkey GLIDE のご紹介 – Valkey は、キャッシュやメッセージキューなどのさまざまなワークロードをサポートする、オープンソースの key-value データストアです。Valkey GLIDE は Valkey の公式クライアントライブラリの 1 つで、すべての Valkey コマンドをサポートしています。GLIDE は Valkey 7.2 以降と Redis オープンソース 6.2、7.0、7.2 をサポートしています。 Amazon OpenSearch Service の強化 – Amazon OpenSearch Serverless は、 時系列収集のワークロードを最大 30 TB までサポートするようになり 、より大量のデータを扱うユースケースが可能になりました。また、データを自動的に取得してスマートに管理する 革新的なキャッシュメカニズム が、データ取得の高速化、ストレージの効率的な使用、コスト削減につながります。 Amazon OpenSearch Service では、 OpenSearch Dashboards Log Explorer に AI を活用した自然言語クエリ生成のサポートが追加 されました。これにより、PPL に習熟していなくても、ログ分析をすぐに開始できます。 Secrets Manager Agent for AWS Secrets Manager のオープンソースリリース – Secrets Manager Agent は、言語にとらわれないローカル HTTP サービスで、コンピューティング環境にインストールして使用すると、Secrets Manager からシークレットを読み取ってメモリにキャッシュすることができます。ネットワーク呼び出しを行う代わりに、Secrets Manager からシークレットを読み取り、メモリにキャッシュできます。 Amazon S3 Express One Zone が AWS CloudTrail のすべてのイベントのログ記録のサポートを開始 – S3 Express One Zone に対して API コールを行ったユーザーと API コールが行われた日時に関する詳細を取得できるため、データの可視性が向上し、ガバナンス、コンプライアンス、運用監査が容易になります。 Amazon CloudFront がウェブアプリケーションのマネージドキャッシュポリシーを発表 – これまで、Amazon CloudFront のお客様にはマネージドキャッシュポリシーにおいて 2 つの選択肢があり、それ以外の場合はカスタムキャッシュポリシーを作成する必要がありました。新しいマネージドキャッシュポリシーでは、CloudFront はオリジンから返された Cache-Control ヘッダーに基づいてコンテンツをキャッシュし、ヘッダーが返されない場合はデフォルトでキャッシュを行いません。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 既存のサービスがさらに多くのリージョンでご利用いただけるようになりました。 Amazon Relational Database Service (Amazon RDS) Data API for Aurora PostgreSQL を、 さらに 10 の AWS リージョンでご利用いただけるようになりました 。 Amazon Managed Workflows for Apache Airflow (MWAA) を さらに 9 つの AWS リージョンでご利用いただけるようになりました 。 Amazon Simple Notification Service (Amazon SNS) のお客様は、 カナダ西部 (カルガリー) リージョンでアプリケーションをホスト し、200 を超える国と地域の消費者にテキストメッセージ (SMS) を送信できるようになりました。 Apache HBase テーブルのバックアップと復元の Amazon EMR サポートは、 アジアパシフィック (ソウル) リージョンでご利用いただけます。 Amazon Cognito が カナダ西部 (カルガリー) および アジアパシフィック (香港) リージョンで利用できるようになりました。 AWS の他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 コンテキストウィンドウのオーバーフロー: 障壁を打ち破る – このブログ記事では、生成人工知能 (AI) モデルの複雑な仕組みについて紹介し、CWO (コンテキストウィンドウオーバーフロー) の制限を理解して軽減することが重要な理由を詳しく説明します 。 Agents for Amazon Bedrock を使用して、インフラストラクチャをコードとしてインタラクティブに生成する – このブログ記事では、 Agents for Amazon Bedrock を使用して、アップロードされたアーキテクチャ図から、組織標準に準拠するカスタマイズされた IaC スクリプトを直接生成する方法について説明します。 AWS Step Functions ワークフローを使用した Amazon Bedrock のモデルカスタマイズの自動化 – このブログ記事では、反復可能かつ自動化されたワークフローのオーケストレーションによる Amazon Bedrock モデルのカスタマイズと、 AWS Step Functions がモデルカスタマイズの主な課題の克服に役立つ方法について説明します。 AWS オープンソースのニュースと更新 – 同僚の Ricardo Sueiras が AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Ricardo のページ で最新情報をご確認ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、 AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください: ボゴタ (7 月 18 日)、 台北 (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 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 7月15日週はここまでです。7月22日週の Weekly Roundup もお楽しみに! — Abhishek この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

7月10日、 Amazon MemoryDB のベクトル検索 の一般提供についてお知らせします。これは、インメモリパフォーマンスとマルチ AZ 耐久性を備えたリアルタイム機械学習 (ML) および 生成人工知能 (生成 AI) アプリケーションの開発用の新機能で、ベクトルの保存、インデックス作成、取得、検索に使用できます。 今回のリリースにより、Amazon MemoryDB は、Amazon Web Services (AWS) で人気の高いベクトルデータベースの中で、最も高いリコール率での最速のベクトル検索パフォーマンスを実現しました。従来、緊張関係にあったスループット、リコール、レイテンシーのトレードオフを行う必要はもうありません。 1 つの MemoryDB データベースを使用して、アプリケーションデータと数百万のベクトルを保存できるようになりました。最大リコールレベルでのクエリと更新の応答時間は、1 桁ミリ秒です。これにより、生成 AI アプリケーションアーキテクチャを簡素化すると同時に、最高のパフォーマンスを実現し、ライセンスコスト、運用上の負担、データに関する洞察を提供するための時間を削減することができます。 Amazon MemoryDB のベクトル検索では、既存の MemoryDB API を使用して、 検索拡張生成 (RAG) 、異常 (不正) 検出、ドキュメント検索、リアルタイムレコメンデーションエンジンなどの生成 AI ユースケースを実装できます。また、 Amazon Bedrock や Amazon SageMaker などの人工知能や機械学習 (AI/ML) サービスを使用してベクトル埋め込みを生成し、それらを MemoryDB に保存することもできます。 MemoryDB のベクトル検索のメリットが最も大きいユースケースはどれですか? MemoryDB のベクトル検索は、次の特定のユースケースに使用できます。 1.検索拡張生成 (RAG) 用のリアルタイムのセマンティック検索 ベクトル検索を使用すると、大規模なデータコーパスから関連する箇所を取得して、大規模言語モデル (LLM) を拡張できます。これは、ドキュメントコーパスを取り出して個別のテキストバケットにまとめ、 Amazon Titan Multimodal Embeddings G1 モデル などの埋め込みモデルを使用してチャンクごとにベクトル埋め込みを生成し、これらのベクトル埋め込みを Amazon MemoryDB に読み込むことによって行われます。 RAG と MemoryDB を使用すると、リアルタイム生成 AI アプリケーションを構築して、項目をベクトルとして表現することで類似の製品やコンテンツを見つけたり、テキスト文書を意味的な意味を捉えた密度の高いベクトルとして表現してドキュメントを検索したりできます。 2.低レイテンシーかつ高耐久性のセマンティックキャッシュ セマンティックキャッシュは、基盤モデル (FM) の以前の結果をメモリに保存することで計算コストを削減するプロセスです。以前に推論された回答を質問のベクトル表現と一緒に MemoryDB に保存し、LLM から別の回答を推論する代わりに、それらを再利用できます。 ユーザーのクエリが、定義済みの類似性スコアに基づいて前の質問と意味的に類似している場合、MemoryDB は前の質問に対する回答を返します。このユースケースにより、生成 AI アプリケーションが FM に新たなリクエストを行うことで、より低いコストでより迅速に応答できるようになり、顧客により速いユーザーエクスペリエンスを提供できます。 3.リアルタイムの異常 (不正) 検出 ベクトルで表されるトランザクションデータと、それらのトランザクションが不正または有効のどちらとして識別されたかどうかを表すメタデータを保存することで、ベクトル検索を使用して異常 (不正) を検出し、ルールベースの機械学習プロセスやバッチ機械学習プロセスを補完できます。 機械学習プロセスでは、正味の新規取引が不正取引を表すベクトルとの類似度が高い場合に、ユーザーの不正取引を検出できます。MemoryDB のベクトル検索を使用すると、バッチ ML モデルに基づいて不正なトランザクションをモデル化し、通常のトランザクションと不正なトランザクションを MemoryDB にロードして、主成分分析 (PCA) などの統計的分解手法を使用してベクトル表現を生成することで、不正を検出できます。 インバウンドトランザクションがフロントエンドアプリケーションを通過するときに、PCA を介してトランザクションのベクトル表現を生成することで、MemoryDB に対してベクトル検索を実行できます。また、トランザクションが過去に検出された不正トランザクションと非常に似ている場合は、1桁ミリ秒以内にトランザクションを拒否して、不正のリスクを最小限に抑えることができます。 Amazon MemoryDB でのベクトル検索の開始方法 MemoryDB でベクトル検索を使用して、簡単なセマンティック検索アプリケーションを実装する方法を見てみましょう。 ステップ 1.ベクトル検索をサポートするクラスターを作成する MemoryDB クラスターを作成して、 MemoryDB コンソール 内でベクトル検索を有効にすることができます。クラスターを作成または更新するときに、 [Cluster settings] (クラスター設定) で [Enable vector search] (ベクトル検索を有効にする) を選択します。ベクトル検索は、MemoryDB バージョン 7.1 およびシングルシャード構成で使用できます。 ステップ 2.Amazon Titan 埋め込みモデルを使用してベクトル埋め込みを作成する Amazon Titan Text Embeddings やその他の埋め込みモデルを使用してベクトル埋め込みを作成できます。この埋め込みは Amazon Bedrock で利用できます。AWS サービスと統合された LangChain ライブラリ を備えた単一の API を使用して PDF ファイルを読み込んだり、テキストをチャンクに分割したり、ベクトルデータを取得したりできます。 import redis import numpy as np from langchain.document_loaders import PyPDFLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import BedrockEmbeddings # Load a PDF file and split document loader = PyPDFLoader(file_path=pdf_path) pages = loader.load_and_split() text_splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "\n", ".", " "], chunk_size=1000, chunk_overlap=200, ) chunks = loader.load_and_split(text_splitter) # Create MemoryDB vector store the chunks and embedding details client = RedisCluster( host=' mycluster.memorydb.us-east-1.amazonaws.com', port=6379, ssl=True, ssl_cert_reqs="none", decode_responses=True, ) embedding = BedrockEmbeddings ( region_name="us-east-1", endpoint_url=" https://bedrock-runtime.us-east-1.amazonaws.com", ) #Save embedding and metadata using hset into your MemoryDB cluster for id, dd in enumerate(chucks*): y = embeddings.embed_documents([dd]) j = np.array(y, dtype=np.float32).tobytes() client.hset(f'oakDoc:{id}', mapping={'embed': j, 'text': chunks[id] } ) Amazon Titan Text Embeddings モデルを使用してベクトル埋め込みを生成したら、MemoryDB クラスターに接続し、MemoryDB HSET コマンドを使用してこれらの埋め込みを保存できます。 ステップ 3.ベクトルインデックスを作成する ベクトルデータをクエリするには、 FT.CREATE コマンドを使用してベクトルインデックスを作成します。ベクトルインデックスも、MemoryDB キースペースのサブセット上でコンストラクトおよび管理されます。ベクトルは JSON または HASH データ型で保存でき、ベクトルデータへの変更はすべてベクトルインデックスのキースペースで自動的に更新されます。 from redis.commands.search.field import TextField, VectorField index = client.ft(idx:testIndex).create_index([ VectorField( "embed", "FLAT", { "TYPE": "FLOAT32", "DIM": 1536, "DISTANCE_METRIC": "COSINE", } ), TextField("text") ] ) MemoryDB では、数値フィールド、タグフィールド、テキストフィールド、ベクトルフィールドの 4 種類のフィールドを使用できます。ベクトルフィールドは、フラット検索 (FLAT) と Hierarchical Navigable Small Worlds (HNSW) アルゴリズムを使用した、固定サイズのベクトルの K-最近傍検索 (KNN) をサポートしています。この機能は、ユークリッド、コサイン、内積などさまざまな距離計量をサポートしています。ここでは、ベクトル空間の 2 点間の角距離の尺度であるユークリッド距離を使用します。ユークリッド距離が小さいほど、ベクトルは互いに近づきます。 ステップ 4.ベクトル空間を検索する FT.SEARCH コマンドと FT.AGGREGATE コマンドを使用してベクトルデータをクエリできます。各演算子は、インデックス内の 1 つのフィールドを使用して、インデックス内のキーのサブセットを識別します。MemoryDB のベクトルフィールドと、事前定義されたしきい値 ( RADIUS ) に基づくクエリベクトルとの間の距離によって、フィルタリングされた結果をクエリして見つけることができます。 from redis.commands.search.query import Query # Query vector data query = ( Query("@vector:[VECTOR_RANGE $radius $vec]=>{$YIELD_DISTANCE_AS: score}") .paging(0, 3) .sort_by("vector score") .return_fields("id", "score") .dialect(2) ) # Find all vectors within 0.8 of the query vector query_params = { "radius": 0.8, "vec": np.random.rand(VECTOR_DIMENSIONS).astype(np.float32).tobytes() } results = client.ft(index).search(query, query_params).docs 例えば、コサイン類似度を使用する場合、 RADIUS 値の範囲は 0～1 で、値が 1 に近いほど、検索中心に近いベクトルが見つかります。 クエリベクトルの 0.8 以内のすべてのベクトルを検出した結果の例を次に示します。 [Document {'id': 'doc:a', 'payload': None, 'score': '0.243115246296'}, Document {'id': 'doc:c', 'payload': None, 'score': '0.24981123209'}, Document {'id': 'doc:b', 'payload': None, 'score': '0.251443207264'}] 詳細については、RAG と MemoryDB をベクトルストアとして使用した 生成 AI アプリケーションのサンプル をご覧ください。 GA での新機能 re: Invent 2023 では、MemoryDB のベクトル検索の プレビュー 版をリリースしました。お客様からのフィードバックに基づいて、現在ご利用いただけるようになった新機能と改善点は次のとおりです。 VECTOR_RANGE により、MemoryDB を低レイテンシーで耐久性のあるセマンティックキャッシュとして動作させることができるようになり、生成 AI アプリケーションのコスト最適化とパフォーマンスの向上が実現します。 SCORE を使用すると、ベクトル検索を行う際の類似度によるフィルタリングが改善されます。 メモリ内のベクトルが重複しないようにするための共有メモリ。ベクトルは MemoryDB キースペース内に格納され、ベクトルへのポインタはベクトルインデックスに格納されます。 高いフィルタリングレートでのパフォーマンスの向上により、最もパフォーマンスが高い生成 AI アプリケーションを実現します。 今すぐご利用いただけます ベクトル検索は、MemoryDB が現在利用可能なすべてのリージョンでご利用いただけます。詳しくは、AWS ドキュメントの Amazon MemoryDB のベクトル検索 をご覧ください。 MemoryDB コンソール をお試しいただけましたら、 AWS re:Post for Amazon MemoryDB または通常の AWS サポート窓口までフィードバックをお寄せください。 – Channy 原文は こちら です。

はじめに 技術の進歩が進む中で、次のイノベーションの重要な要素としてSpatial Computingがあげられます。ゲーム、メディア、製造業や建築業に至るまで様々な業界の企業がSpatial Computingの導入や活用に取り組んでいます。最近のSpatial Computing領域での最も大きなニュースはAppleからVision Proが発売されたことでしょう。Vision Proを利用することでSpatial Computingの世界で、より直感的なインタラクティブかつ没入的な体験をすることが可能になります。 Amazon Web Services（AWS）ではSpatial Computingに関連した施策として NVIDIA Omniverseの活用 や、 Visual Assets Management System(VAMS) などの取り組みがありますが、本記事ではVision Pro向けUnityアプリケーションのビルド方法について解説していきます。 AWSを利用したビルドパイプライン 以前の記事で、UnityモバイルアプリのビルドパイプラインをAWS上に実装する方法を、実際にデプロイできるコードとともに紹介しました: Unityモバイルアプリのビルドパイプラインを実装する 元記事からの再掲にはなりますが、AWSでビルドパイプラインを構築する利点は以下のとおりです: レジリエンス : AWS上のビルドパイプラインは耐障害性が高く、無停止で動き続けることができます。 スケーラビリティ : 開発のフェーズに合わせてキャパシティを柔軟に調整できます。 セキュリティ : AWSでは多くのセキュリティサービスが利用でき、パイプラインに統合することでシステムの信頼性を高め、お客様の制作物を保護します。 Vision Proのアプリケーション開発においても、安定したビルドパイプラインの存在は重要でしょう。iOSアプリビルドの環境はVision Proアプリのビルドにも利用できるため、本記事でも上記記事のパイプライン実装をそのまま利用することができます。 アーキテクチャ あらためて、今回のビルドパイプラインのアーキテクチャをおさらいしましょう。GitHub に本アーキテクチャを実装したサンプルを公開しています: Unity Build Pipeline with Jenkins and EC2 Mac このサンプルには以下が含まれます: ECS Fargate 上の Jenkins マスター EC2 Linux spot インスタンスと EC2 Mac インスタンス上の Jenkins エージェント Linux 上では Docker エージェントも利用可能 EC2 Linux 上 の Unity Accelerator (オプショナル) ビルドキャッシュをスポットインスタンス間で共有する仕組み ( 記事 を参照) AWS CDK による自動化されたデプロイ 上記はご利用の AWS アカウントにデプロイしてすぐに試せるようになっていますので、ぜひご確認ください。 またUnityビルドにおいて必要となることも多い、Unity のフローティングライセンス管理サーバーを AWS 上に構築するIaC実装も合わせて公開しています。こちらも合わせてご確認ください: Unity Build Server with AWS CDK 実際にビルドしてみよう それでは上記のアーキテクチャを利用してVision Proアプリケーションをビルドする手順を簡単に紹介します。 なお、ビルドパイプラインは構築できているものとしますが、構築のための詳細な方法はこちらをご参照ください: ビルドパイプラインのCDKプロジェクトのデプロイ手順 。AWS CDKを利用してデプロイでき、2〜3個のCLIコマンド実行だけでデプロイが完了します。 今回は、ビルド対象のVisionOSプロジェクト例として、こちらを利用します: aws-samples/unity-vision-os-sample-app 上記をローカルに git clone し、Unityでプロジェクトを開くと、以下のようなプロジェクトであることが分かります。 今回のJenkinsパイプラインでは、以下の手順でビルドします: EC2 Linux (spot)上のUnityでUnityプロジェクトからXcodeプロジェクトを生成する 1のプロジェクトをS3にコピー EC2 Mac上に2をコピーし、Xcodeでビルドする まず、1の準備をします。Unityを含むコンテナイメージとして、 game-ci/docker が利用可能です。しかしながら、2024年7月現在において、VisionOS向けのモジュールを含むイメージは Docker Hub に公開されていません。このワークアラウンドとして、自分でイメージをビルドし、Amazon ECRレポジトリにイメージをプッシュすることができます。下記はイメージをビルドするためのコマンド例です: git clone https://github.com/game-ci/docker.git cd docker/images/ubuntu/editor # Unityのversionは適宜変更してください docker build --build-arg="module=visionos" --build-arg="version=2022.3.31f1" --platform linux/amd64 . イメージがビルドできたら、ECRレポジトリにプッシュしましょう。上記のCDKプロジェクト内でレポジトリを作成するため、そのレポジトリにプッシュすることをお勧めします。Jenkinsからイメージを利用するために必要なクレデンシャルも、そのレポジトリ向けにすでに設定されているためです。 また、3のためにEC2 Macをセットアップする必要があります。具体的には、以下の操作です: Xcodeのインストール provisioning profileや証明書の設定 EC2 MacにはVNC経由で接続でき、通常のMac端末と同じGUIで操作することが可能です。EC2 Macインスタンスに接続するための手順は、こちらを参照してください: EC2 Macインスタンスのセットアップ 。provisioning profileなどの設定は会社により方法が異なると思われるため、本手順では割愛します。検証用の手順としては、こちらが参考になるかもしれません: AWS Game tech workshop これで準備ができました。あとはJenkinsのGUIからパイプラインを作成するだけです。サンプルのJenkinsfileは先程のリポジトリに同梱されています: aws-samples/unity-vision-os-sample-app ポイントは以下のとおりです: カスタムのgame-ciコンテナイメージを利用 : 以下のagentブロックで、先ほどビルドしたコンテナイメージを参照しています。 registryCredentialsId や $ECR_REPOSITORY_URL などは、CDKデプロイ時に設定された値です。 agent { docker { label 'linux' image "${ECR_REPOSITORY_URL}:latest" args '-u 0 --entrypoint= ' registryCredentialsId "ecr:${AWS_REGION}:ecr-role" registryUrl "$ECR_REGISTRY_URL" } } UnityのビルドターゲットをVisionOSに設定 : executeMethodによるビルド実行時に、ターゲットをVisionOSに設定しています unity-editor \ -quit \ -batchmode \ -nographics \ -executeMethod ExportTool.ExportXcodeProject \ -projectPath "./" ExportTool.cs XcodeのSDKをVisionOSに設定 : xcodebuildコマンド呼び出し時に -sdk xros オプションを指定します xcodebuild -scheme Unity-VisionOS -sdk xros ... 公開されたリポジトリを使って、下図のように直接Jenkinsパイプラインを試すこともできます: ビルドが完了したら、Jenkinsからアーティファクトをダウンロードして確認することができます。 なお、今回はスケーラビリティやコスト効率のためにEC2 Linux スポットインスタンスを活用していますが、より小規模なワークロードなどでは、EC2 Macのみ使うこともできます。EC2 Mac上にUnityエディタをインストールし、Xcodeプロジェクトの生成からビルドまで完結させる方法です。どの種類のEC2インスタンスをJenkinsエージェントとしてデプロイするかは、 bin/jenkins-unity-build.ts  から設定できますので、そちらもご確認ください。 まとめ この記事では、EC2 MacやEC2 Linuxスポットインスタンスを利用したJenkinsパイプラインを構築し、Vision OSアプリケーションをビルドする方法を紹介しました。本方法により、パイプラインのリジリエンス・スケーラビリティ・セキュリティを高く実現することができます。いくつかの簡単なコマンドを実行するだけで本パイプラインをデプロイできるようになっているので、ぜひお試しください。

AWS では 2024 年 4 月に Amazon Q Business をリリースした際、 Amazon Q Apps のプレビュー版 もリリースしました。 Amazon Q Apps は、組織のデータに基づいて生成人工知能 (生成 AI) を利用したアプリケーションを作成するための、Amazon Q Business 内の機能です。ユーザーは自然言語を使用してアプリを構築し、それを組織のアプリライブラリに安全に公開して、誰もが使用できるようにすることができます。 プレビュー中にフィードバックや提案を収集してきましたが、7月10日、Amazon Q Apps を一般公開しました。Amazon Q Apps の API や、個々のカードレベルでデータソースを指定する機能など、プレビュー中には使用できなかった新機能もいくつか追加しています。 新機能については後ほど詳しく説明しますが、まず Amazon Q Apps の使用を開始する方法を見てみましょう。 会話を再利用可能なアプリに変える Amazon Q Apps では、Amazon Q Business との会話からアプリを生成できます。Amazon Q Apps は会話のコンテキストをスマートにキャプチャして、特定のニーズに合わせたアプリを生成します。実際の動作を見てみましょう。 この記事を書き始めたとき、Amazon Q Business の協力を得て、Amazon Q Apps の製品概要を生成することを考えました。結局のところ、Amazon Q Business は従業員の生産性を高めるために存在しているからです。そこで、製品メッセージドキュメントを Amazon Simple Storage Service (Amazon S3) バケットにアップロードし、 Amazon Q Business 用の Amazon S3 コネクタ を使用して、データソースとして追加しました。 次のプロンプトから会話を始めます。 私は、Amazon Q Apps のリリースに関する記事を書いています。 製品の簡単な説明は次のとおりです。従業員は、幅広い Amazon Q Business アプリケーション環境内で、軽量かつ特定の目的のための Amazon Q Apps を作成できます。 製品の概要と主な機能の一覧表示を生成してください。 会話を開始してみて、製品の説明を記載した製品概要を作成することは、組織内の他のメンバーにとっても役立つことに気付きました。 [Create Amazon Q App] (Amazon Q App を作成) を選択して、再利用および共有可能なアプリを作成します。 Amazon Q Business では、Amazon Q App を作成するプロンプトが自動生成され、必要に応じて確認と編集を促すプロンプトが表示されます。 Q にとって既知の製品/サービスに関するデータを利用して、製品またはサービスの短い説明を取り込み、その製品/サービスの概要と、主要機能の一覧を出力するアプリを構築します。 [Generate] (生成) を選択してアプリの作成を続行します。4 枚のカード (ユーザー入力を取得する 2 枚の入力カードと、製品の概要および主要機能を表示する 2 枚の出力カード) を含む Product Overview Generator アプリを作成します。 カードのサイズを変更したり移動したりすることで、アプリのレイアウトを調整できます。 また、個々のテキスト出力カードのプロンプトが自動的に生成されるので、これらを表示したり編集したりできます。 [Product Overview] (製品概要) カードの編集アイコンを選択すると、サイドパネルにプロンプトが表示されます。 サイドパネルでは、テキスト出力カードのソースを選択し、大規模言語モデル (LLM) の知識または承認されたデータソースのいずれかを使用して、出力を生成することもできます。承認されたデータソースについては、この Amazon Q Business アプリケーション用に設定されているデータソースを 1 つ以上選択できます。このアプリを作成するために設定した マーケティング (Amazon S3) データソースを選択します。 お気付きかもしれませんが、基本プロンプトや個々のテキスト出力カードのプロンプトを変更することなく、会話自体から完全に機能するアプリを生成しました。 [Publish] (公開) を選択すると、このアプリを組織のアプリライブラリに公開できます。しかし、アプリを公開する前に、Amazon Q アプリを作成する別の方法を見てみましょう。 自然言語を使用して生成 AI アプリを作成する Amazon Q Business での会話を起点としてアプリを作成する代わりに、 [Apps] (アプリ) を選択し、作成したいアプリを自分の言葉で説明することができます。または、事前に設定された例のいずれかのプロンプトを試してみることもできます。 目的に合わせてプロンプトを入力し、 [Generate] (生成) を選択してアプリを作成できます。 チームとアプリを共有する レイアウトとプロンプトの両方に満足し、アプリを共有する準備が整ったら、一元化されたアプリライブラリにアプリを公開して、この Amazon Q Business アプリケーション環境のすべてのユーザーがアクセスできるようにします。 Amazon Q Apps は Amazon Q Business の強固なセキュリティとガバナンスコントロールを継承しており、データソース、ユーザー権限、ガードレールを確実に維持します。そのため、他のユーザーがアプリを実行すると、基礎となるデータソースでアクセスできるデータに基づく回答のみが表示されます。 作成した Product Overview Generator アプリでは、 [Publish] (公開) を選択します。アプリのプレビューが表示され、最大 3 つのラベルを選択できます。ラベルは、組織内の部門やその他のカテゴリ別にアプリを分類するのに役立ちます。ラベルを選択したら、プレビューポップアップでもう一度 [Publish] (公開) を選択します。 アプリはすぐに Amazon Q Apps ライブラリで利用可能となり、他のユーザーが使用、コピー、ビルドできるようになります。 [Library] (ライブラリ) を選択して Amazon Q Apps ライブラリを閲覧すると、作成した Product Overview Generator アプリが見つかります。 特定のニーズに合わせてアプリライブラリ内のアプリをカスタマイズする Amazon Q Apps では、共有アプリを特定のニーズに合わせてカスタマイズおよび調整することで、個人またはチームの生産性をすばやく向上できます。ゼロから始める代わりに、既存のアプリを確認したり、そのまま使用したり、アプリを変更して独自のバージョンをアプリライブラリに公開したりできます。 アプリライブラリを閲覧して、カスタマイズするアプリを見つけましょう。 [General] (一般) というラベルを選択して、そのカテゴリのアプリを検索します。 ドキュメントをレビューして文法上の間違いを修正する、 Document Editing Assistant (ドキュメント編集アシスタント) アプリを見つけました。新しいバージョンのアプリを作成して、ドキュメントの概要も含めたいとします。その方法について説明します。 [Open] (開く) を選択するとアプリが開き、 [Customize] (カスタマイズ) オプションが表示されます。 [Customize] (カスタマイズ) を選択すると、アプリのコピーが作成され、変更を加えられるようになります。 アプリタイトルの編集アイコンを選択して、アプリの タイトル と 説明 を更新します。 このアプリの生成に使用された元の アプリプロンプト が表示されます。プロンプトをコピーして、同様のアプリを作成する際の出発点として使用できます。これにより、追加したい機能の説明を含め、Amazon Q Apps Creator に処理を任せることができます。または、このアプリのコピーの変更を続行することもできます。 既存のカードを編集または削除するオプションがあります。例えば、カードの編集アイコンを選択すると、 [Edited Document] (編集済みドキュメント) のテキスト出力 カードのプロンプトを編集できます。 機能をさらに追加するには、ユーザー入力、テキスト出力、ファイルアップロード、または管理者が事前設定したプラグインなどのカードを追加できます。例えば、ファイルアップロードカードを使用して、質問への回答を絞り込んだり、微調整したりするための別のデータソースとしてのファイルを提供できます。プラグインカードを使用すると、フォローアップとして実行する必要のあるアクションアイテムの Jira チケットの作成などを行えます。 [Text output] (テキスト出力) を選択して、ドキュメントを要約する新しいカードを追加します。タイトルを「Document Summary (ドキュメント概要)」とし、次のようなプロンプトを入力します。 @Upload ドキュメントに数行で要点を要約してください これで、このカスタマイズしたアプリを新しいアプリとして公開し、組織内の全員と共有できるようになりました。 プレビュー後の追加機能 前述のとおり、プレビュー期間中にお寄せいただいたフィードバックや提案を基に、新しい機能を追加しました。追加した新機能は次のとおりです。 カードレベルでのデータソースの指定 – アプリ作成時に示したように、出力の生成元となるデータソースを指定できます。応答の精度を向上させるためにこの機能を追加しました。 Amazon Q Business インスタンスでは、複数のデータソースを設定できます。ただし、アプリを作成する際、ユースケースによってはこれらのデータソースのサブセットのみが必要となる場合があります。この機能によって、アプリ内のテキスト出力カードごとに特定のデータソースを選択できるようになりました。また、必要に応じて、データソースを使用する代わりに LLM ナレッジを使用するようにテキスト出力カードを設定できます。 Amazon Q Apps API – アプリ、アプリライブラリ、アプリセッションを管理するための API を使用して、Amazon Q Apps をプログラムで作成および管理できるようになりました。これにより、Amazon Q Apps のすべての機能を、お好みのツールやアプリケーションに統合できます。 留意点 リージョン – Amazon Q アプリは現在、Amazon Q Business が利用できるリージョン、つまり米国東部 (バージニア北部) リージョンおよび米国西部 (オレゴン) リージョンで一般的にご利用いただけます。 価格 – Amazon Q APps は、Amazon Q Business Pro サブスクリプション (ユーザーあたり月額 20 USD) で利用可能で、ユーザーは Amazon Q Business のすべての機能にアクセスできます。 学習リソース – 詳細については、 Amazon Q Business ユーザーガイドの Amazon Q Apps をご覧ください。 –  Prasad 原文は こちら です。

7月10日、 Amazon Q Developer (IDE 内) のカスタマイズ機能をインラインコード補完で一般利用できるようにし、チャットのカスタマイズ機能のプレビューをローンチしました。 Amazon Q をカスタマイズして、IDE コードエディタとチャットにおいて、プライベートコードリポジトリから特定の推奨コードを生成できるようになりました。 Amazon Q Developer は人工知能 (AI) コーディングコンパニオンです。既存のコメントやコードから導き出された推奨コードを統合開発環境 (IDE) で提供することで、ソフトウェアデベロッパーがアプリケーション開発を迅速に行えるようにします。 Amazon Q では、Amazon およびオープンソースプロジェクトの何十億行ものコードでトレーニングされた大規模言語モデル (LLM) を舞台裏で使用しています。 Amazon Q は IDE で利用でき、 JetBrains 、 Visual Studio Code 、および Visual Studio (プレビュー中) の拡張機能をダウンロードできます。IDE テキストエディタでは、入力時にコードが提案されるか、入力したコメントから関数全体が記述されます。また、Q Developer とチャットして、特定のタスク用のコードを生成するように依頼したり、発見したコードベースのコードスニペットを説明したりすることもできます。 新しいカスタマイズ機能により、デベロッパーは組織の内部ライブラリ、API、パッケージ、クラス、メソッドに基づいた、より適切なコードのレコメンデーションを受け取ることができるようになりました。 例えば、金融機関に勤務するデベロッパーが、ある顧客の ポートフォリオ 総額を計算する関数を書くことを任されているとしましょう。これで、デベロッパーはコメントで意図を説明したり、 computePortfolioValue(customerId: String) などの関数名を入力したりでき、 Amazon Q は、組織のプライベートコードベースから学習した例に基づいて、その関数を実装するためのコードを提案します。 デベロッパーはチャットで組織のコードについて質問することもできます。上の例では、デベロッパーがチームに初めて入社し、顧客 ID を取得する方法がわからないとします。チャットで平易な英語を使って、「データベースに接続して特定の顧客の customerId を取得するにはどうすればいいですか?」と質問できます。 Amazon Q チャットは、「データベース接続 XYZ を利用して、顧客の苗字と名前から得られた customerId を取得する関数を見つけました」と答えてくれるかもしれません。 管理者は、社内の Git リポジトリ (GitHub、GitLab、BitBucket など) または Amazon Simple Storage Service (Amazon S3) バケットから構築されたカスタマイズを作成します。これは、 Amazon Q が意図を理解し、タスクに最も適した内部 API とパブリック API を判断し、推奨コードを生成するのに役立ちます。 Amazon Q のカスタマイズ機能は、お客様が AWS にかける強力なデータプライバシーとセキュリティの期待事項に応えるものです。 Amazon Q と共有するコードベースは、お客様の組織には公開されません。基盤モデルのトレーニングには使用しません。カスタマイズがデプロイされると、推論エンドポイントは組織内のデベロッパー専用になります。自分のコードに基づいたレコメンデーションは、他社のデベロッパー IDE には表示されません。どのデベロッパーが個々のカスタマイズにアクセスできるかを決定し、メトリクスに従ってデプロイしたカスタマイズのパフォーマンスを測定できます。 Amazon Q のカスタマイズ機能は、 検索拡張生成 (RAG) などの主要な技術手法に基づいて構築されました。この非常に詳細なブログ記事では、 Amazon Q カスタマイズ機能の背後にある科学について詳しく説明しています 。 昨年 10 月 17 日にプレビューを開始して以来、カスタマイズを更新する機能と、IDE でチャットをカスタマイズする機能という 2 つの新機能が追加されました。 組織のコードベースは絶えず進化しているので、 Amazon Q には常に最新のコードスニペットを提案してもらいたいと考えていらっしゃることでしょう。 Amazon Q 管理者は、 AWS マネジメントコンソール で更新プロセスをワンステップで開始できるようになりました。管理者はコードリポジトリの最新のコミットに基づいて定期的な更新をスケジュールし、デベロッパーが常に非常に正確なコード提案を受けられるようにすることができます。 新しいチャットのカスタマイズ (プレビュー中) では、組織内のデベロッパーが IDE でコードの一部を選択してチャットに送信し、選択したコードが何をするのか説明を求めることができます。デベロッパーは、「データベースに接続して特定の顧客の customerId を取得する方法を教えてください」など、組織のコードベースに関連する一般的な質問をすることもできます。 では、その使用方法を見てみましょう このデモでは、現在一般的に利用できる新しいカスタマイズ更新機能に焦点を当てることにしました。カスタマイズの作成方法、有効化の方法、デベロッパーへアクセス権を付与する方法を簡単に学ぶには、 同僚の Donnie の素晴らしい投稿をお読みください 。 既存のカスタマイズを更新するには、 Amazon Q コンソールページの「 カスタマイズ 」セクションに移動します。更新したいカスタマイズを選択します。次に、 [Actions] (アクション) と [Create new version] (新しいバージョンを作成) を選択します。 カスタマイズを作成したときと同じように、ソースコードリポジトリを選択して [Create] (作成) を選択します。 新しいバージョンのカスタマイズの作成には、取り込むコードの量によって異なるため、しばらく時間がかかる場合があります。準備が整うと、 [Versions] (バージョン) タブに新しいバージョンが表示されます。新しいバージョンの 評価 スコアを以前のバージョンと比較し、デベロッパーが利用できるようにアクティブ化することを決定できます。以前のバージョンに戻すこともいつでもできます。 アクティブカスタマイズで気に入っている点の 1 つは、その効果をモニタリングして組織のデベロッパーの生産性を向上させることができることです。 [Dashboard] (ダッシュボード) ページでは、 ユーザーのアクティビティ を追跡します。 日単位のアクティブユーザーの数 、生成された コード行 の数、実行された セキュリティスキャン の数などを追跡できます。私のように、過去に Amazon CodeWhisperer Professional を使用したことがある場合は、現在使用すると、一部のページに CodeWhisperer という名前が残っていることがあります。Amazon Q Developer という新しい名前に徐々に置き換えられる予定です。 Amazon Q はより多くのメトリクスを生成し、 Amazon CloudWatch に公開されます。CloudWatch ダッシュボードを作成して、デプロイしたカスタマイズのパフォーマンスを監視できます。例えば、これはコード提案の ブロック 承認率 と ライン承認率 をプログラミング言語ごとに分類して監視するカスタム CloudWatch ダッシュボードです。 サポート対象プログラミング言語 現在、Java、JavaScript、TypeScript、Python で記述されたコードベースに基づいて Amazon Q レコメンデーションをカスタマイズできます。C#、Go、Rust、PHP、Ruby、Kotlin、C、C++、シェルスクリプト、SQL、Scala など、 Amazon Q がサポートする他の言語で作成されたファイルは、カスタマイズを作成したり、IDE でカスタマイズされたレコメンデーションを提供したりするときには使用されません。 料金と利用可能なリージョン Amazon Q は AWS リージョンに依存せず、世界中のデベロッパーが利用できます。 Amazon Q は現在、米国東部 (バージニア北部) でホストされています。 Amazon Q 管理者は、他のリージョンに AWS IAM アイデンティティセンター がある場合は、 Amazon Q を認可されたクロスリージョンアプリケーションとして設定できます。 Amazon Q カスタマイズ機能は、 Amazon Q Developer プロフェッショナルサブスクリプション 内で追加料金なしで利用できます。AWS アカウントごとに最大 8 つのカスタマイズを作成し、最大 2 つのカスタマイズをアクティブに保つことができます。 さあ、構築に取り掛かって、 Amazon Q のカスタマイズを組織のデベロッパーに提案してみましょう 。 — seb 原文は こちら です。

Agents for Amazon Bedrock を使用すると、 生成人工知能 (AI) アプリケーションはさまざまなシステムやデータソースにわたって多段階のタスクを実行できます。数か月前、エージェントの 作成と設定を簡素化しました 。7月10日、フルマネージド型の 2 つの新機能をプレビューで紹介します。 複数のインタラクションにわたってメモリを保持 – エージェントは各ユーザーとの会話の概要を保持できるようになり、特にユーザーとのやり取りや、フライトの予約や保険金請求の処理などのエンタープライズオートメーションソリューションといった複雑なマルチステップタスクで、スムーズで適応性の高いエクスペリエンスを提供できるようになりました。 コード解釈のサポート – エージェントは、安全なサンドボックス環境内でコードスニペットを動的に生成して実行できるようになり、データ分析、データ視覚化、テキスト処理、方程式の解決、問題の最適化などの複雑なユースケースに対応できるようになりました。この機能をより使いやすくするために、ドキュメントをエージェントに直接アップロードする機能も追加しました。 これらの新機能の仕組みを詳しく見ていきましょう。 複数のインタラクションにわたるメモリの保持 メモリを保持することで、時間をかけて各ユーザーの固有のニーズや好みを学習し、それに適応するエージェントを構築できます。永続的なメモリを保持することで、エージェントはユーザーが中断したところからすぐに再開でき、特に複雑な複数ステップのタスクにおいて、会話やワークフローをスムーズに進めることができます。 ユーザーがフライトを予約するとします。メモリを保持できるため、エージェントは旅行の好みを把握し、その情報を利用してその後の予約リクエストを効率化し、パーソナライズされた効率的なエクスペリエンスを実現できます。例えば、ユーザーに適切な座席を自動的に提案したり、ユーザーが以前に選択したものと同様の食事を提案したりできます。 メモリ保持を利用してコンテキストを把握しやすくすると、ビジネスプロセスの自動化も簡単になります。例えば、企業が顧客フィードバックを処理するために使用するエージェントは、カスタムインテグレーションを処理しなくても、同じ顧客との過去および進行中のやり取りを認識できるようになりました。 各ユーザーの会話履歴とコンテキストは、固有のメモリ識別子 (ID) の下に安全に保存され、ユーザー間で完全に分離されます。メモリを保持することで、時間の経過とともに継続的に改善される、シームレスで適応性のあるパーソナライズされたエクスペリエンスを提供するエージェントを簡単に構築できます。これが実際にどのように機能するかを見てみましょう。 Amazon Bedrock のエージェントでメモリ保持を使用する Amazon Bedrockコンソール で、ナビゲーションペインの [Builder Tools] (ビルダーツール) セクションから [Agents] (エージェント) を選択し、エージェントの作成を開始します。 エージェントについては、名前として agent-book-flight を使用し、説明としてこれを使用します。 フライトの予約を手伝ってあげましょう。 次に、エージェントビルダーで、 Anthropic の Claude 3 Sonnet モデルを選択し 、次の指示を入力します。 フライトを予約するには、出発地と目的地の空港、およびフライトの離陸日時を知っておく必要があります。 追加設定 では、 ユーザー入力 を有効にして、エージェントが明確な質問をして必要な入力を取り込めるようにしています。これは、フライトの予約リクエストで、出発地と目的地、フライトの日時などの必要な情報が不足している場合に役立ちます。 新しい [Memory] (メモリ) セクションでは、各セッションの終了時にメモリを有効にしてセッション概要を生成して保存し、メモリ持続時間はデフォルトの 30 日間とします。 次に、フライトを検索して予約するためのアクショングループを追加します。名前と次の説明として、「 search-and-book-flights 」を使用しています。 特定の日に 2 つの目的地間のフライトを検索し、特定のフライトを予約します。 次に、関数の詳細を含むアクショングループを定義し、新しい Lambda 関数を作成します。Lambda 関数は、このアクショングループのすべての関数のビジネスロジックを実装します。 このアクショングループに 2 つの関数を追加します。1 つはフライトを検索する関数、もう 1 つはフライトを予約する関数です。 最初の関数は search-for-flights で、次のような説明があります。 特定の日付の 2 つの目的地間のフライトを検索します。 この関数のすべてのパラメータは必須で、型は文字列です。パラメータの名前と説明は次のとおりです。 origin_airport – 出発地の IATA 空港コード destination_airport – 目的地の IATA 空港コード date – YYYYMMDD 形式のフライトの日付 2 つ目の関数は book-flight で、次のような記述を使います。 特定の日時に 2 つの目的地間のフライトを予約します。 繰り返しますが、すべてのパラメータは必須で、タイプは文字列です。パラメータの名前と説明は次のとおりです。 origin_airport – 出発地の IATA 空港コード destination_airport – 目的地の IATA 空港コード date – YYYYMMDD 形式のフライトの日付 time – HHMM 形式のフライトの時間 エージェントの作成を完了するには、 [Create] (作成) を選択します。 Lambda 関数のソースコードにアクセスするには、 search-and-book-flights アクショングループを選択し、次に [View] (表示) ( Lambda 関数の選択 設定の近く) を選択します。通常は、この Lambda 関数を使用して、旅行予約プラットフォームなどの既存のシステムと統合します。ここでは、このコードを使用してエージェントの予約プラットフォームをシミュレートします。 import json import random from datetime import datetime, time, timedelta def convert_params_to_dict(params_list): params_dict = {} for param in params_list: name = param.get("name") value = param.get("value") if name is not None: params_dict[name] = value return params_dict def generate_random_times(date_str, num_flights, min_hours, max_hours): # Set seed based on input date seed = int(date_str) random.seed(seed) # Convert min_hours and max_hours to minutes min_minutes = min_hours * 60 max_minutes = max_hours * 60 # Generate random times random_times = set() while len(random_times) < num_flights: minutes = random.randint(min_minutes, max_minutes) hours, mins = divmod(minutes, 60) time_str = f"{hours:02d}{mins:02d}" random_times.add(time_str) return sorted(random_times) def get_flights_for_date(date): num_flights = random.randint(1, 6) # Between 1 and 6 flights per day min_hours = 6 # 6am max_hours = 22 # 10pm flight_times = generate_random_times(date, num_flights, min_hours, max_hours) return flight_times def get_days_between(start_date, end_date): # Convert string dates to datetime objects start = datetime.strptime(start_date, "%Y%m%d") end = datetime.strptime(end_date, "%Y%m%d") # Calculate the number of days between the dates delta = end - start # Generate a list of all dates between start and end (inclusive) date_list = [start + timedelta(days=i) for i in range(delta.days + 1)] # Convert datetime objects back to "YYYYMMDD" string format return [date.strftime("%Y%m%d") for date in date_list] def lambda_handler(event, context): print(event) agent = event['agent'] actionGroup = event['actionGroup'] function = event['function'] param = convert_params_to_dict(event.get('parameters', [])) if actionGroup == 'search-and-book-flights': if function == 'search-for-flights': flight_times = get_flights_for_date(param['date']) body = f"On {param['date']} (YYYYMMDD), these are the flights from {param['origin_airport']} to {param['destination_airport']}:\n{json.dumps(flight_times)}" elif function == 'book-flight': body = f"Flight from {param['origin_airport']} to {param['destination_airport']} on {param['date']} (YYYYMMDD) at {param['time']} (HHMM) booked and confirmed." elif function == 'get-flights-in-date-range': days = get_days_between(param['start_date'], param['end_date']) flights = {} for day in days: flights[day] = get_flights_for_date(day) body = f"These are the times (HHMM) for all the flights from {param['origin_airport']} to {param['destination_airport']} between {param['start_date']} (YYYYMMDD) and {param['end_date']} (YYYYMMDD) in JSON format:\n{json.dumps(flights)}" else: body = f"Unknown function {function} for action group {actionGroup}." else: body = f"Unknown action group {actionGroup}." # Format the output as expected by the agent responseBody = { "TEXT": { "body": body } } action_response = { 'actionGroup': actionGroup, 'function': function, 'functionResponse': { 'responseBody': responseBody } } dummy_function_response = {'response': action_response, 'messageVersion': event['messageVersion']} print(f"Response: {function_response}") return function_response エージェントをコンソールでテストできるように準備し、次の質問をします。 2024 年 7 月 20 日にロンドンのヒースロー空港からローマのフィウミチーノ空港まで運航しているフライトはどれですか? エージェントは時刻表を記載して返信します。エージェントが私の指示をどのように処理したかについての詳細情報を表示するには、 [Show trace] (トレースを表示) を選択します。 [Trace] (トレース) タブでは、エージェントのオーケストレーションで使われた思考の連鎖を理解するためのトレースステップを調べます。例えば、エージェントが Lambda 関数を呼び出す前に空港名からコードへの変換 (ロンドンのヒースロー空港の場合は LHR、ローマのフィウミチーノ空港の場合は FCO) を処理したことがわかります。 新しい [Memory] (メモリ) タブに、メモリの内容が表示されます。コンソールは特定のテストメモリ ID を使用します。アプリケーションでは、ユーザーごとにメモリを分離しておくために、ユーザーごとに異なるメモリ ID を使用できます。 フライトのリストを見て、予約するように頼みます。 午後 6 時 2 分の便を予約してください。 エージェントは予約を確認する返信をします。 数分後、セッションの期限が切れると、 [Memory] (メモリ) タブに会話の概要が表示されます。 ほうきアイコンを選択して新しい会話を開始し、それだけではエージェントに完全なコンテキストを提供できない質問をします。 フライト当日に利用できる他の便はありますか? エージェントは、前回の会話で予約したフライトを思い出します。回答するために、エージェントがフライトの詳細を確認するよう求めてきています。Lambda 関数は単なるシミュレーションであり、どのデータベースにも予約情報を保存していないことに注意してください。フライトの詳細はエージェントのメモリから取得しました。 これらの値を確認して、その日の出発地と目的地の同じ他のフライトのリストを取得します。 はい、お願いします。 メモリ保持の利点をよりよく示すために、 AWS SDK for Python (Boto3) を使用してエージェントを呼び出してみましょう。そのためには、まずエージェントエイリアスとバージョンを作成する必要があります。エージェント ID とエイリアス ID は、エージェントを呼び出すときに必要になるため、書き留めておきます。 エージェント呼び出しでは、メモリを使用するための新しい memoryId オプションを追加します。このオプションを含めると、次の 2 つのメリットが得られます。 その memoryId に保持されているメモリ (ある場合) は、エージェントが応答を改善するために使用されます。 現在のセッションの会話の概要は、別のセッションで使用できるように、その memoryId に保持されます。 AWS SDK を使用すると、特定の memoryId のメモリのコンテンツを取得したり、削除したりすることもできます。 import random import string import boto3 import json DEBUG = False # Enable debug to see all trace steps DATE_FORMAT = "%Y-%m-%d %H:%M:%S" AGENT_ID = 'URSVOGLFNX' AGENT_ALIAS_ID = 'JHLX9ERCMD' SESSION_ID_LENGTH = 10 SESSION_ID = "".join( random.choices(string.ascii_uppercase + string.digits, k=SESSION_ID_LENGTH) ) # A unique identifier for each user MEMORY_ID = 'danilop-92f79781-a3f3-4192-8de6-890b67c63d8b' bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', region_name='us-east-1') def invoke_agent(prompt, end_session=False): response = bedrock_agent_runtime.invoke_agent( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, sessionId=SESSION_ID, inputText=prompt, memoryId=MEMORY_ID, enableTrace=DEBUG, endSession=end_session, ) completion = "" for event in response.get('completion'): if DEBUG: print(event) if 'chunk' in event: chunk = event['chunk'] completion += chunk['bytes'].decode() return completion def delete_memory(): try: response = bedrock_agent_runtime.delete_agent_memory( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, memoryId=MEMORY_ID, ) except Exception as e: print(e) return None if DEBUG: print(response) def get_memory(): response = bedrock_agent_runtime.get_agent_memory( agentId=AGENT_ID, agentAliasId=AGENT_ALIAS_ID, memoryId=MEMORY_ID, memoryType='SESSION_SUMMARY', ) memory = "" for content in response['memoryContents']: if 'sessionSummary' in content: s = content['sessionSummary'] memory += f"Session ID {s['sessionId']} from {s['sessionStartTime'].strftime(DATE_FORMAT)} to {s['sessionExpiryTime'].strftime(DATE_FORMAT)}\n" memory += s['summaryText'] + "\n" if memory == "": memory = "<no memory>" return memory def main(): print("Delete memory? (y/n)") if input() == 'y': delete_memory() print("Memory content:") print(get_memory()) prompt = input('> ') if len(prompt) > 0: print(invoke_agent(prompt, end_session=False)) # Start a new session invoke_agent('end', end_session=True) # End the session if __name__ == "__main__": main() ラップトップから Python スクリプトを実行します。現在のメモリを削除して (今のところ空のはずですが)、特定の日に朝のフライトを予約するように依頼します。 Delete memory? (y/n) y Memory content: <no memory> > 2024 年 7 月 20 日の LHR から FCO への朝のフライトを予約してください。 2024 年 7 月 20 日 06:44 時のロンドンのヒースロー空港 (LHR) 発ローマのフィウミチーノ空港 (FCO) 行きの午前便を予約しました。 2、3 分待ってから、スクリプトを再実行します。このスクリプトは、実行されるたびに新しいセッションを作成します。今回は、メモリを削除せず、同じ memoryId での以前のやりとりの概要が表示されます。次に、私のフライトがいつ予定されているかを尋ねます。これは新しいセッションであっても、エージェントはメモリの内容から以前の予約を見つけます。 Delete memory? (y/n) n Memory content: Session ID MM4YYW0DL2 from 2024-07-09 15:35:47 to 2024-07-09 15:35:58 ユーザーの目標は、2024 年 7 月 20 日に LHR から FCO への午前中のフライトを予約することでした。アシスタントは、2024 年 7 月 20 日の希望日に、LHR から FCO への午前 6 時 44 分のフライトを予約しました。アシスタントは、ユーザーのためにリクエストされた午前中のフライトを正常に予約しました。ユーザーは、2024 年 7 月 20 日にロンドンのヒースロー空港 (LHR) からローマのフィウミチーノ空港 (FCO) への午前中のフライト予約をリクエストしました。アシスタントは、指定されたルートと日付の午前 06 時 44 分発のフライトを予約しました。 > 私のフライトの出発便は何日ですか? 前回の会話から、2024 年 7 月 20 日にロンドンのヒースロー空港 (LHR) 発ローマのフィウミチーノ空港 (FCO) 行きの午前の便を予約したと記憶しています。2024 年 7 月 20 日のこの日付が、照会しているフライトと合致するかどうかを確認してください。 はい、それが私のフライトです。 ユースケースにもよりますが、メモリ保持機能を使うと、同じユーザーからの以前のインタラクションや好みを追跡し、セッションをまたいでシームレスなエクスペリエンスを提供できます。 セッション概要には、一般的な概要と、ユーザーとアシスタントの視点が含まれます。このセッションのように短いセッションでは、繰り返しが発生する可能性があります。 コード解釈サポート Agents for Amazon Bedrock はコード解釈をサポートするようになったため、エージェントは安全なサンドボックス環境でコードスニペットを動的に生成して実行できるようになり、データ分析、視覚化、テキスト処理、方程式解決、最適化問題などの複雑なタスクを含め、対処できるユースケースが大幅に広がりました。 エージェントは、CSV、XLS、YAML、JSON、DOC、HTML、MD、TXT、PDF など、さまざまなデータタイプと形式の入力ファイルを処理できるようになりました。コード解釈により、エージェントはチャートも生成できるため、ユーザーエクスペリエンスが向上し、データ解釈が容易になります。 コード解釈は、大規模言語モデル (LLM) が特定の問題をより正確に解決するのに役立つと判断した場合にエージェントによって使用され、ユーザーが任意のコード生成を要求するシナリオでは設計上サポートされていません。セキュリティ上の理由から、各ユーザーセッションには分離されたサンドボックス化されたコードランタイム環境が用意されています。 簡単なテストを行って、これがエージェントが複雑なタスクを処理するのにどのように役立つかを見てみましょう。 Amazon Bedrock のエージェントでコード解釈を使用する Amazon Bedrock コンソール で、前のデモ ( agent-book-flight ) と同じエージェントを選択し、 [Edit in Agent Builder] (エージェントビルダーで編集) を選択します。エージェントビルダーでは、 [Additional Settings] (追加設定) で [Code Interpreter] (コードインタープリター) を有効にして保存します。 エージェントを準備し、コンソールで直接テストします。まず、数学的な質問をします。 最初の 10 個の素数の合計を計算してください。 数秒後、エージェントから回答が届きます。 最初の 10 個の素数の合計は 129 です。 正確です。トレースを見て、エージェントはこの Python プログラムをビルドして実行し、私が尋ねたことを計算しました。 import math def is_prime(n): if n < 2: return False for i in range(2, int(math.sqrt(n)) + 1): if n % i == 0: return False return True primes = [] n = 2 while len(primes) < 10: if is_prime(n): primes.append(n) n += 1 print(f"The first 10 prime numbers are: {primes}") print(f"The sum of the first 10 prime numbers is: {sum(primes)}") さて、 agent-book-flight エージェントの話に戻りましょう。長い期間にわたって利用できるフライトの全体像を把握したいと思います。そのためには、まず同じアクショングループに新しい関数を追加して、特定の日付範囲で利用できるすべてのフライトが得られるようにします。 新しい関数に get-flights-in-date-range という名前を付けて、次の説明を使います。 特定の日付範囲でそれぞれの日の、2 つの目的地間の全フライトを取得してください。 すべてのパラメータは必須で、文字列タイプです。パラメータ名と説明は次のとおりです。 origin_airport – 出発地の IATA 空港コード destination_airport – 目的地の IATA 空港コード 開始日 – YYYYMMDD 形式のフライトの開始日 終了日 – YYYYMMDD 形式のフライトの終了日 前に紹介した Lambda 関数コードを見ると、このエージェント関数は既にサポートされていることがわかります。 エージェントが 1 回の関数呼び出しでより多くの情報を抽出できるようになったので、エージェントにフライト情報データをチャートで視覚化するように依頼します。 2024 年 8 月の最初の 10 日間の JFK から SEA への毎日のフライト数をチャートにしてください。 エージェントの返信には次のようなチャートが含まれています。 コンピュータに画像をダウンロードするためのリンクを選択します。 正解です。実際、Lambda 関数のシミュレーターは、チャートに示されているように 1 日に 1～6 回のフライトを生成します。 添付ファイルでコード解釈を使用する コード解釈により、エージェントはデータから情報を処理して抽出できるため、エージェントを呼び出すときにドキュメントを含める機能を導入しました。例えば、さまざまなフライトで予約したフライトの数が記載された Excel ファイルがあります。 出発地 目的地 フライト数 LHR FCO 636 FCO LHR 456 JFK SEA 921 SEA JFK 544 テストインターフェイスのクリップアイコンを使用して、ファイルを添付して質問します (エージェントは 太字 で返信します)。 一番人気の路線はどれですか? そして、一番人気のない路線は? 分析によると、最も人気のある路線は 921 件の予約がある JFK->SEA で、最も人気のない路線は 456 件の予約がある FCO-> LHR です。 合計でいくつのフライトが予約されていますか? 全路線の予約便の総数は 2557 便です。 これらの路線で予約されたフライトの割合を合計数と比較したチャートを作成してください。 トレースを見ると、ファイルから情報を抽出してエージェントに渡すために使用された Python コードを確認できます。複数のファイルを添付して、さまざまなファイル形式を使用できます。これらのオプションは AWS SDK で利用可能で、エージェントはアプリケーションのファイルを使用できます。 知っておくべきこと メモリ保持は、 Amazon Bedrocks のエージェント および Anthropic の Claude 3 Sonnet または Haiku (プレビュー中にサポート対象のモデル) が利用できるすべての AWS リージョン でプレビュー版としてご利用いただけます。コード解釈は、米国東部 (バージニア北部)、米国西部 (オレゴン)、および欧州 (フランクフルト) リージョンでプレビュー版としてご利用いただけます。 プレビュー中にエージェントでメモリ保持とコード解釈を使用しても、追加料金はかかりません。エージェントをこれらの機能とともに使用する場合、通常のモデル使用料が適用されます。メモリ保持が有効になっている場合は、セッションの要約に使用されたモデルの料金が発生します。詳細については、 Amazon Bedrock の料金 ページをご覧ください。 詳細については、 ユーザーガイドの「Amazon Bedrock のエージェント」セクション を参照してください。詳細な技術コンテンツや、他の企業が自社のソリューションで生成 AI をどのように使用しているかを知るには、 community.aws にアクセスしてください。 – Danilo 原文は こちら です。

Guardrails for Amazon Bedrock を使用すると、お客様はアプリケーション要件と会社の責任ある人工知能 (AI) ポリシーに基づいて、保護措置を実装できます。望ましくないコンテンツの防止、プロンプト攻撃 (プロンプトインジェクションやジェイルブレイク) の防止、プライバシー保護のための機密情報の削除に役立ちます。複数のポリシータイプを組み合わせて、さまざまなシナリオに合わせてこれらのセーフガードを設定し、 Amazon Bedrock の基盤モデル (FM) だけでなく、Amazon Bedrock 以外のカスタムおよびサードパーティーの FM にも適用できます。Guardrails は、 Amazon Bedrock のエージェント や Amazon Bedrock のナレッジベース と統合することもできます。 Guardrails for Amazon Bedrock は、FM が提供するネイティブ保護に加えて、カスタマイズ可能な追加の保護手段を提供し、業界でもトップクラスの安全機能を提供します。 有害なコンテンツを 85% もブロック お客様が 1 つのソリューション内で安全性、プライバシー、信頼性の保護手段をカスタマイズして適用可能に RAG および要約ワークロードの 75% を超える幻覚応答をフィルタリング Guardrails for Amazon Bedrock は re:Invent 2023 で最初にプレビュー版としてリリースされ、コンテンツフィルターや拒否トピックなどのポリシーをサポートします。 2024 年 4 月に一般公開された時点で 、Guardrails は拒否トピック、コンテンツフィルター、機密情報フィルター、単語フィルターの 4 つの保護手段をサポートしていました。 MAPFRE はスペイン最大の保険会社で、世界 40 か国で事業を展開しています。「MAPFRE は、Mark.IA (RAG ベースのチャットボット) が当社の企業セキュリティポリシーと責任ある AI 慣行に確実に沿っているようにするために、Guardrails for Amazon Bedrock を実装しました」と MAPFRE のアーキテクチャ担当副ディレクターである Andres Hevia Vega 氏は述べています。 「MAPFRE は Guardrails for Amazon Bedrock を使用して、有害なコンテンツにコンテンツフィルタリングを適用し、許可されていないトピックを拒否し、企業のセキュリティポリシーを標準化し、個人データを匿名化して最高レベルのプライバシー保護を維持しています。Guardrails は、アーキテクチャエラーを最小限に抑え、API 選択プロセスを簡素化して、セキュリティプロトコルを標準化するのに役立ちました。AI 戦略を進化させ続ける中で、Amazon Bedrock とその Guardrails 機能は、より効率的で革新的、安全かつ責任ある開発プラクティスに向けた道のりにおいて非常に貴重なツールであることが証明されています」。 7月10日、さらに次の 2 つの機能を発表しました。 コンテキストグラウンディングチェックは、参照ソースとユーザークエリに基づいて、モデル応答中のハルシネーションを検出します。 ApplyGuardrail API は、すべての FM (Amazon Bedrock 上の FM、カスタムおよびサードパーティーの FM を含む) の入力プロンプトとモデル応答を評価します。これにより、すべての生成 AI アプリケーションにわたって一元的なガバナンスを実現できます 。 コンテキストグラウンディングチェック – ハルシネーションを検出する新しいポリシータイプ お客様は通常、会社のソースデータに基づいて根拠のある (信頼できる) 応答を生成するために、FM の固有の機能を利用しています。ただし、FM は複数の情報を混同して、誤った情報や新しい情報を生成し、アプリケーションの信頼性に影響を与える可能性があります。コンテキストグラウンディングチェックは、企業データに基づいていなかったり、ユーザーのクエリとは無関係だったりするモデル応答でハルシネーションを検出できるようにする、5 番目の新たな保護手段です。これは、RAG、要約、情報抽出などのユースケースでの応答品質を向上させるために使用できます。例えば、Amazon Bedrock のナレッジベースでコンテキストグラウンディングチェックを使用して、企業データに基づいていない不正確な応答をフィルタリングすることで、信頼できる RAG アプリケーションをデプロイできます。エンタープライズデータソースから取得した結果は、モデル応答を検証するためのコンテキストグラウンディングチェックポリシーによって参照ソースとして使用されます。 コンテキストグラウンディングチェックには、次の 2 つのフィルタリングパラメータがあります。 グラウンディング – これは、グラウンディング対象となるモデル応答の最小信頼スコアを表す グラウンディングしきい値 を指定することで可能になります。つまり、参照元で提供されている情報に基づくと事実的に正しいものであり、参照元以外の新しい情報は含まれていません。定義されたしきい値よりも低いスコアのモデル応答がブロックされ、設定されたブロックメッセージが返されます。 関連性 – このパラメータは、ユーザーのクエリに関連するモデル応答の最小信頼スコアを表す 関連性しきい値 に基づいて機能します。定義されたしきい値を下回るスコアが低いモデル応答はブロックされ、設定されたブロックメッセージが返されます。 グラウンディングしきい値と関連性しきい値のスコアが高いほど、ブロックされる回答が多くなります。特定のユースケースの精度の許容範囲に基づいてスコアを調整してください。例えば、金融分野の顧客向けアプリケーションでは、不正確なコンテンツに対する許容度が低いため、高いしきい値が必要になる場合があります。 コンテキストグラウンディングチェックのインの動作 コンテキストグラウンディングチェックの例をいくつかご紹介します。 Amazon Bedrock の AWS マネジメントコンソール に移動します。ナビゲーションペインから [Guardrails] (ガードレール) を選択し、次に [Create guardrail] (ガードレールを作成) を選択します。コンテキストグラウンディングチェックポリシーを有効にしてガードレールを設定し、グラウンディングしきい値と関連性しきい値を指定します。 ポリシーをテストするには、 Guardrail の概要 ページに移動し、 テスト セクションを使用してモデルを選択します 。これにより、ソース情報とプロンプトのさまざまな組み合わせを簡単に試して、モデル応答のコンテキスト上の根拠と関連性を検証できます。 この例のテストでは、次のコンテンツ (銀行手数料について) をソースとして使用します。 • 当座預金口座の開設に伴う手数料はありません。 • 当座預金口座の維持費は月額 10 USD です。 • 国際送金には 1% の取引手数料がかかります。 • 国内送金には手数料はかかりません。 • クレジットカード請求書の支払い遅延に関連する料金は 23.99% です。 次に、 [Prompt ] (プロンプト) フィールドに次のように順に質問を入力します。 「 当座預金口座に関連する手数料はいくらですか? 」 実行するには [Run] (実行) を選択し、詳細にアクセスするには [View Trace] (トレースを表示) を選択します。 モデルの回答は事実上正しく、関連性がありました。グラウンディングスコアと関連性スコアの両方が設定されたしきい値を上回っていたため、モデル応答をユーザーに送り返すことができました。 次に、別のプロンプトを試します。 「 クレジットカードに関連する取引手数料はいくらですか? 」 ソースデータには、クレジットカードの延滞請求についてのみ記載されており、クレジットカードに関連する取引手数料については記載されていません。したがって、モデル応答は (取引手数料に関連して) 関連性がありましたが、事実上正しくありませんでした。その結果、グラウンディングスコアが低くなり、スコアが設定されたしきい値である 0.85 を下回ったため、応答がブロックされました。 最後に、次のプロンプトを試しました。 「 当座預金口座を使用する場合の取引手数料はいくらですか？ 」 この場合、ソースデータには当座預金銀行口座の月額料金が記載されているため、モデルの回答は根拠がありました。ただし、クエリは取引手数料に関するもので、応答は月額料金に関するものだったため、関連性がありませんでした。その結果、関連性スコアが低くなり、設定されたしきい値である 0.5 を下回ったため、応答がブロックされました。 AWS SDK for Python (Boto3) を使用して、 CreateGuardrail API によりコンテキストグラウンディングを設定する方法の例を次に示します。 bedrockClient.create_guardrail( name='demo_guardrail', description='Demo guardrail', contextualGroundingPolicyConfig={ "filtersConfig": [ { "type": "GROUNDING", "threshold": 0.85, }, { "type": "RELEVANCE", "threshold": 0.5, } ] }, ) コンテキストグラウンディングチェックを使用してガードレールを作成したら、Amazon Bedrock のナレッジベースや Amazon Bedrock のエージェントに関連付けることも、モデル推論中に参照することもできます。 しかし、それだけではありません。 ApplyGuardrail – Amazon Bedrock 以外で利用可能な FM を使用してアプリケーションを保護 これまで、Guardrails for Amazon Bedrock は主に、モデル推論中のみ、Amazon Bedrock で利用できる FM 用の入力プロンプトとモデル応答の評価に使用されていました。 Guardrails for Amazon Bedrock は、設定されたセーフガードに合わせてすべてのユーザー入力とモデル応答を評価する新しい ApplyGuardrail API をサポートするようになりました。この機能により、基盤となるインフラストラクチャに関係なく、セルフマネージド (カスタム) またはサードパーティーの FM を使用して構築されたすべての生成 AI アプリケーションに、標準化された一貫した保護手段を適用できます。要するに、Guardrails for Amazon Bedrock を使用することで、Amazon Bedrock で利用可能な FM、他のサービス ( Amazon SageMaker など) で利用可能な FM、 Amazon Elastic Compute Cloud (Amazon EC2) などのインフラストラクチャ、オンプレミスデプロイ、および Amazon Bedrock 以外のその他のサードパーティーの FM の入力プロンプトとモデル応答に同じ保護手段のセットを適用できるようになりました。 さらに、 ApplyGuardrail API を使用して、生成 AI アプリケーションのさまざまな段階でユーザー入力とモデル応答を個別に評価できるため、アプリケーション開発の柔軟性が高まります。例えば、RAG アプリケーションでは、ナレッジベースで検索を実行する前に、ガードレールを使用して有害なユーザー入力を評価およびフィルタリングできます。その後、FM からの取得 (検索) と生成ステップを完了した後に、出力を個別に評価できます。 アプリケーションで ApplyGuardrail API を使用する方法を説明します。次の例では、 AWS SDK for Python (Boto3) を使用しました。 まず、拒否されたトピックのセットを含む新しいガードレールを作成し ( create_guardrail 関数を使用) 、新しいバージョンを作成しました ( create_guardrail_version 関数を使用)。 import boto3 bedrockRuntimeClient = boto3.client('bedrock-runtime', region_name="us-east-1") bedrockClient = boto3.client('bedrock', region_name="us-east-1") guardrail_name = 'fiduciary-advice' def create_guardrail(): create_response = bedrockClient.create_guardrail( name=guardrail_name, description='Prevents the model from providing fiduciary advice.', topicPolicyConfig={ 'topicsConfig': [ { 'name': 'Fiduciary Advice', 'definition': 'Providing personalized advice or recommendations on managing financial assets in a fiduciary capacity.', 'examples': [ 'What stocks should I invest in for my retirement?', 'Is it a good idea to put my money in a mutual fund?', 'How should I allocate my 401(k) investments?', 'What type of trust fund should I set up for my children?', 'Should I hire a financial advisor to manage my investments?' ], 'type': 'DENY' } ] }, blockedInputMessaging='I apologize, but I am not able to provide personalized advice or recommendations on managing financial assets in a fiduciary capacity.', blockedOutputsMessaging='I apologize, but I am not able to provide personalized advice or recommendations on managing financial assets in a fiduciary capacity.', ) version_response = bedrockClient.create_guardrail_version( guardrailIdentifier=create_response['guardrailId'], description='Version of Guardrail to block fiduciary advice' ) return create_response['guardrailId'], version_response['version'] ガードレールが作成されたら、評価対象のテキストと、作成したばかりのガードレールの ID とバージョンを含む apply_guardrail 関数を呼び出しました。 def apply(guardrail_id, guardrail_version): response = bedrockRuntimeClient.apply_guardrail(guardrailIdentifier=guardrail_id,guardrailVersion=guardrail_version, source='INPUT', content=[{"text": {"inputText": "How should I invest for my retirement? I want to be able to generate $5,000 a month"}}]) print(response["output"][0]["text"]) 使用したのは次のプロンプトです。 退職後のためにどのように投資すべきですか? 月に 5,000 USD 稼げるようになりたいです ガードレールのおかげで、メッセージはブロックされ、事前に設定された応答が返されました。 申し訳ありませんが、受託者として金融資産の管理について、個別のアドバイスやレコメンデーションを提供することはできません。 この例では、ソースを INPUT に設定しています。つまり、評価されるコンテンツはユーザー (通常は LLM プロンプト) からのものです。モデル出力を評価するには、 ソース を OUTPUT に設定する必要があります。 今すぐご利用いただけます コンテキストに基づくグラウンディングチェックと ApplyGuardrail API は現在、Guardrails for Amazon Bedrock が利用可能な すべての AWS リージョン でご利用いただけます。 Amazon Bedrock コンソール でお試しいただき、 AWS re:Post for Amazon Bedrock に、または通常の AWS 担当者を通じて、フィードバックをぜひお寄せください。 Guardrails の詳細については、 Guardrails for Amazon Bedrock の製品ページと Amazon Bedrock の料金 ページにアクセスして、ガードレールポリシーに関連する費用をご確認ください。 また、 community.aws サイトに忘れずにアクセスすると、ソリューションの技術的な内容を詳しく見たり、ビルダーコミュニティが自らのソリューションで Amazon Bedrock をどのように利用しているかを学んだりすることもできます。 — Abhishek 原文は こちら です。

Amazon Bedrock のナレッジベース を使用すると、基盤モデル (FM) とエージェントは、検索拡張生成 (RAG) のために会社のプライベートデータソースからコンテキスト情報を取得できます。RAG は、FM がより適切で正確かつカスタマイズされた回答を提供するのに役立ちます。 過去数か月にわたって、モデル、ベクトルストア、および FM をナレッジベースに埋め込む選択肢を継続的に追加してきました。 7月10日、 Amazon Simple Storage Service (Amazon S3) に加えて、ウェブドメイン、Confluence、Salesforce、SharePoint をデータソースとして RAG アプリケーション (プレビュー中) に接続できるようになったことを発表しました。 ウェブドメイン、Confluence、Salesforce、SharePoint 用の新しいデータソースコネクタ ウェブドメインを含めることで、RAG アプリケーションに会社のソーシャルメディアフィードなどの公開データへのアクセスを許可し、ユーザー入力への応答の関連性、適時性、包括性を高めることができます。新しいコネクタを使用して、Confluence、Salesforce、SharePoint の既存の企業データソースを RAG アプリケーションに追加できるようになりました。 これがどのように機能するかを見ていきましょう。以下の例では、ウェブクローラーを使用してウェブドメインを追加し、Confluence をデータソースとしてナレッジベースに接続します。Salesforce と SharePoint をデータソースとして接続する場合も、同様のパターンに従います。 ウェブドメインをデータソースとして追加 試してみるには、 Amazon Bedrock コンソール に移動してナレッジベースを作成してください。名前や説明などのナレッジベースの詳細を入力し、関連する AWS Identity and Access Management (IAM) 許可を持つ新しいサービスロールを作成するか、既存のサービスロールを使用してください。 次に、使用するデータソースを選択します。 [Web Crawler] (ウェブクローラー) を選択します。 次のステップでは、ウェブクローラーを設定します。ウェブクローラーデータソースの名前と説明を入力します。次に、ソース URL を定義します。このデモでは、自ら執筆したすべての記事を一覧表示する AWS ニュースブログの著者ページの URL を追加します。クロールしたいウェブサイトのシード URL またはスタートポイント URL を最大 10 個追加できます。 オプションで、カスタム暗号化設定と、データソースが削除されたときにベクトルストアデータを保持するか削除するかを定義するデータ削除ポリシーを設定できます。ここでは、デフォルトの詳細設定をそのまま使用します。 同期スコープセクションでは、使用する同期ドメインのレベル、1 分あたりにクロールする URL の最大数、特定の URL を含めるか除外する正規表現パターンを設定できます。 ウェブクローラーデータソースの設定が完了したら、埋め込みモデルを選択し、任意のベクトルストアを設定して、ナレッジベースのセットアップを完了します。作成後にナレッジベースの詳細を確認して、データソースの同期ステータスを監視できます。同期が完了したら、ナレッジベースをテストして、ウェブ URL を引用として含む FM 応答を確認できます。 データソースをプログラムで作成するには、 AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK を使用できます。 コード例については、 Amazon Bedrock ユーザーガイド をご覧ください。 Confluence をデータソースとして接続する それでは、ナレッジベース設定のデータソースとして Confluence を選択しましょう。 Confluence をデータソースとして設定するには、データソースの名前と説明を再度入力し、ホスティング方法を選択して Confluence URL を入力します。 Confluence に接続するには、ベース認証と OAuth 2.0 認証のどちらかを選択できます。このデモでは、ユーザー名 (Confluence ユーザーアカウントの E メールアドレス) とパスワード (Confluence API トークン) を入力する 基本認証 を選択します。関連する認証情報を AWS Secrets Manager に保存し、シークレットを選択します。 注 : シークレット名が「AmazonBedrock-」で始まり、ナレッジベースの IAM サービスロールに Secrets Manager でこのシークレットにアクセスする許可があることを確認してください。 メタデータ設定では、正規表現の包含パターンと除外パターンを使用してクロールするコンテンツの範囲を制御したり、コンテンツのチャンクと解析の戦略を設定したりできます。 Confluence データソースの設定が完了したら、埋め込みモデルを選択し、任意のベクトルストアを設定して、ナレッジベースのセットアップを完了します。 作成後にナレッジベースの詳細を確認して、データソースの同期ステータスを監視できます。同期が完了したら、ナレッジベースをテストできます。このデモでは、Confluence スペースに架空の会議メモをいくつか追加しました。ある会議のアクションアイテムについて聞いてみましょう。 Salesforce と SharePoint をデータソースとして接続する方法については、 Amazon Bedrock ユーザーガイド をご覧ください。 知っておくべきこと 包含フィルターと除外フィルター – すべてのデータソースが包含フィルターと除外フィルターをサポートしているため、特定のソースからどのデータをクロールするかをきめ細かく制御できます。 ウェブクローラー – ウェブクローラーは、自分のウェブページまたはクロール権限のあるウェブページでのみ使用する必要があることに注意してください。 今すぐご利用いただけます 新しいデータソースコネクタは、Amazon Bedrock のナレッジベースが利用できるすべての AWS リージョンで現在ご利用いただけます。詳細と今後の更新については、 リージョンリスト を確認してください。ナレッジベースの詳細については、 Amazon Bedrock 製品ページ をご覧ください。料金の詳細については、 Amazon Bedrock の料金ページ を参照してください。 今すぐ Amazon Bedrock コンソール で新しいデータソースコネクタを試して、フィードバックを AWS re:Post for Amazon Bedrock または通常の AWS 担当者に送信し、生成 AI ビルダーコミュニティ ( community.aws ) にご参加ください。 –  Antje 原文は こちら です。