企業はリアルタイムでデータをキャプチャして分析するために、Apache Kafka と Amazon Managed Streaming for Apache Kafka(Amazon MSK) を採用しています。 Amazon MSK は、Kafka のインフラ管理の専門知識や Apache Kafka を自分で設定して実行することに伴う複雑なオーバーヘッドへの対処なしに、Apache Kafka 上で本番アプリケーションを構築および実行できるよう支援します。 リリース当初から、Apache Kafka は Kafka ブローカーとトピックのメタデータを保存および複製するために Apache ZooKeeper に依存してきました。 Apache Kafka バージョン 3.3 から、Kafka コミュニティはメタデータ管理における ZooKeeper への依存性を置き換えるために、コンセンサスプロトコルである KRaft (Kafka on Raft) を採用しました。 将来的には、Apache Kafka コミュニティは ZooKeeper モードを完全に削除する計画です。 本日、バージョン 3.7 からの新しいクラスターで、Amazon MSK 上の KRaft のサポートを開始できることをうれしく思います。この投稿では、KRaft モードが ZooKeeper アプローチに比べてどのように役立つかの詳細を説明します。また、KRaft モードで MSK クラスターを作成するプロセスと、KRaft モードの MSK クラスターにアプリケーションを接続する方法もご紹介します。 ZooKeeper から KRaft モードへの置き換えられた理由 従来の Kafka アーキテクチャは、クラスタメタデータの信頼できるソースとして ZooKeeper に依存しています。ZooKeeper のメタデータへの読み書きアクセスは、単一の Kafka コントローラを通じて行われます。パーティション数が多いクラスタの場合、このアーキテクチャは、コントローラが 1 つであることに起因する、ブローカーの突然のシャットダウンやコントローラのフェイルオーバーといったシナリオでボトルネックを引き起こす可能性があります。 KRaft モードは、メタデータを Kafka クラスター自体内で管理することで、これらの制限を解決します。ZooKeeper クラスターに依存する代わりに、KRaft モードはクラスターメタデータを複数の Kafka コントローラーノード全体に保存および複製し、メタデータのクォーラムを形成します。KRaft コントローラーノードは、Kafka メタデータログを管理する Raft クォーラムで構成されます。メタデータ管理の責任を複数のコントローラーノード全体に分散することで、KRaft モードは、ブローカーの制御不能なシャットダウンやコントローラーのフェイルオーバーなどのシナリオでのリカバリー時間を改善します。 KRaft モードとその実装の詳細については、 KIP-500: セルフマネージドメタデータクォーラムで ZooKeeper を置き換える を参照してください。 次の図は、ZooKeeper モードと KRaft モードの 3 ノード MSK クラスター・アーキテクチャを比較したものです。 KRaft モードの Amazon MSK これまで、Amazon MSK はメタデータ管理に ZooKeeper に依存する Kafka クラスタをサポートしてきました。Amazon MSK の主なメリットの 1 つは、ZooKeeper クラスタの設定と管理の複雑さを追加料金なしで処理してくれることです。多くの組織が、数千のパーティションにトラフィックを分割する必要がある大規模なビジネスクリティカルなストリーミングアプリケーションを実行するために Amazon MSK を利用しています。Kafka クラスタのサイズが大きくなるにつれ、クラスタ内で生成されるメタデータの量は、パーティション数に比例して増加します。 Kafka クラスタがサポートできるパーティション数を決定する重要な 2 つのプロパティがあります。ノードごとのパーティション数制限と、クラスタ全体のパーティション制限です。以前述べたように、ZooKeeper ベースのメタデータ管理システムは、Apache Kafka のクラスタ全体のパーティション制限にボトルネックを課していました。しかし、Amazon MSK にバージョン 3.7 から KRaft モードが導入されたことで、Amazon MSK は現在、ZooKeeper モードのデフォルトクォータの 30 ブローカーに対して、最大 60 ブローカーを持つクラスタの作成を可能にしています。Kafka のスケーラビリティは、基本的にはより多くのノードを追加して全体的な容量を増やすことによってクラスタを拡大することによるものです。結果的に、クラスター全体のパーティション制限は、引き続き Kafka システム内のスケーラビリティの上限であり続けます。パーティション制限が、使用可能な各ノードに分散配置されるパーティションの最大数を決定するためです。 Amazon MSK は、追加費用なしで KRaft コントローラーノードを管理します。 KRaft モードの MSK クラスターの作成とアクセス KRaft モードで MSK クラスタを設定するには、次のステップを完了します: Amazon MSK console にて ナビゲーションペインから Clusters を選択します。 Create cluster を選択します。 Cluster creation method で Custom create を選択します。 Cluster name に任意の名前を入力します。 Cluster type で Provisioned を選択します。 Apache Kafka version で 3.7.x を選択します。 Metadata mode で KRaft を選択します。　 他の設定はそのままで、 Create cluster を選択します。 クラスターの作成が成功したら、クラスターに移動して　 View client information 　を選択できます。これにより、クラスターのブートストラップサーバーに関する詳細が提供されます。 KRaft モードの MSK クラスタへのアクセスのためのクライアントアプリケーションとツールの調整 Amazon MSK で KRaft モードが採用されたことにより、ZooKeeper に接続して MSK クラスタと対話するクライアントアプリケーションやツールを使用しているお客様は、アーキテクチャから ZooKeeper が削除されたことを反映するようにこれらを更新する必要があります。 バージョン 1.0 から、Kafka は ZooKeeper 接続文字列の代わりにブートストラップサーバー(ブローカー)を入力パラメータとして管理ツールが使用できるようにする機能を導入し、バージョン 2.5 から ZooKeeper 接続文字列の非推奨を開始しました。 この変更は、Kafka を ZooKeeper から切り離し、メタデータ管理のために最終的に ZooKeeper を KRaft モードで置き換えるための取り組みの一環でした。 ZooKeeper 接続文字列を指定する代わりに、クライアントは bootstrap.servers 設定オプションを使用して、Kafka ブローカーに直接接続する必要があります。 次の表は、これらの変更を要約したものです。 . ZooKeeper 利用時 KRaft 利用時 クライアントとサービス bootstrap.servers=broker:<port> または zookeeper.connect=zookeeper:2181 (非推奨) bootstrap.servers=broker:<port> 管理ツール kafka-topics --zookeeper zookeeper:2181 (非推奨) または kafka-topics —bootstrap-server broker:<port> … —command-config kafka-topics —bootstrap-server broker:<port> … —command-config 概要 この投稿では、Amazon MSK がメタデータ管理のための KRaft モードのサポートを開始したことについて説明しました。また、KRaft の動作と ZooKeeper との違いについても説明しました。 Amazon MSK で　KRaft モードを利用するためには、 AWS Management Console を使用して KRaft モードで新しいクラスターを作成してください。詳細は Amazon MSK デベロッパーガイド を参照してください。 著者について Kalyan Janaki はアマゾンウェブサービスのシニアビッグデータ&アナリティクススペシャリストです。 彼は、お客様が AWS 上で拡張性やパフォーマンスが高く、安全なクラウドベースのソリューションを設計および構築できるよう支援しています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

流通・小売・消費財業界に関わられている方々を主な対象として、2024 年 5 月 9 日に「流通・小売・消費財業界向け：クラウドと生成 AI による顧客接点改革」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログではセミナーの内容を簡単にご紹介します。 今回のセミナーでは進化を続ける「顧客接点」をキーワードに、2 つのテクノロジー「クラウド化されたコンタクトセンター（ Amazon Connect ）」「生成 AI」を取り上げて、お客様事例とデモをお届けしました。 セッション 1. オープニング アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ技術本部 流通小売・消費財グループ 本部長　五十嵐 建平 資料ダウンロード オープニングは、企業収益に直接的な影響を与える顧客接点においてテクノロジーによる新たな価値提供の可能性を示すところから始まりました。大丸松坂屋百貨店様の事例および AWS デモにおいて登場する AWS の提供するクラウドベースのコンタクトセンターサービスである、Amazon Connect の強み、そして Amazon Connect がどのように顧客体験 = Customer Experience (CX) の向上に貢献できるのかを簡単に紹介しています。またルームクリップ様、および AWS デモにおいて生成 AI の主題となっている画像について、企業の持つ画像から、生成 AI によって価値ある情報を引き出すことの重要性についてお話しました。 セッション 2.お客様事例 (1) Amazon Connect、Zendesk を連携したコンタクトセンターの対応品質改善 ～ 6 か月間のプロジェクト～ 株式会社 大丸松坂屋百貨店 経営戦略本部 DX推進部 デジタル事業推進担当　木村 崇文 様 資料ダウンロードリンク 株式会社大丸松坂屋百貨店 様では、新規事業領域から既存事業領域まで広くデジタルトランスフォーメーションを推進されています。その中のテーマの一つが「お客様との関係性の深化」、まさに顧客接点におけるトランスフォーメーションです。大丸松坂屋オンラインストアのコンタクトセンター刷新の 3 つの目的、つまりなぜこの取り組みが必要とされたのか、それを踏まえてプロジェクトを進めるにあたり取り入れた「顧客」「業務委託先」「大丸松坂屋百貨店」という 3 つの視点で、課題や KPI を具体的に示しつつ、ご紹介いただきました。その上で、お問い合わせのチャネルで電話の構成比が高いという百貨店様ならではという特性を考慮した上で、Amazon Connect、またこれと組み合わせてご利用いただける Zendesk 社サービスの採用のポイントとして信頼性や、柔軟なカスタマイズが可能であること、問い合わせチャネルの一元管理、分析集計機能への期待といったことを挙げて解説いただきました。プロジェクトは要件定義から約 6 か月という短期間でローンチし、これによって具体的なビジネス効果が上がっていらっしゃる点も具体的に共有され、今後の取り組み予定や期待で締めくくられました。 セッション 3. お客様事例 (2) Lambdaで動くプロンプトライクな物体検出システム ルームクリップ株式会社 CTO　平山 知宏 様 資料ダウンロードリンク 住生活の領域に特化した日本最大級のソーシャルプラットフォーム「 RoomClip 」では、ユーザーにより日々、家具や雑貨といったインテリア写真が投稿されています。写真を共有・閲覧するだけでなく、投稿された写真に写っているものを購入できるページを案内するなどのサービスも提供されており、そういったサービスのためには写真から物体を検出する必要があります。今回のセッションでは、ルームクリップ様のビジネスに必要とされる物体を柔軟に検出するために、様々な軽量動作検出モデルを試行された中で得られた知見、解決策をお話いただきました。画像からの物体検出の各種モデル、サービス、LLM などの得意領域を組み合わせることで、よりビジネスニーズに応えるシステムを検討し、「形式化されたフォーマットで、プロンプトによる運用中心の高速な微調整が可能な物体検出」を実現されました。さらに、コスト面でも軽量化をはかり、 AWS Lambda 上で動作させるアーキテクチャを採用されました。一つの技術だけでビジネス課題を解決できることは現実的には少なく、LLM であれ各技術の得意な領域を組み合わせていかに課題を解決していくのか、そこにこだわることでテクノロジーがビジネスに確実に貢献できるようにする、その重要性を改めて伝えていただきました。 セッション 4. 顧客接点にイノベーションをもたらすマルチモーダルな生成 AI の使い方 アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ技術本部 小売・消費財 第二ソリューション部 ソリューションアーキテクト　中島 佑樹 ＊配布資料はありません テキストのみならず、画像を含めた複数チャネルを入出力できる「マルチモーダル」な生成 AI の活用が広がりつつあります。このセッションでは、マルチモーダルな生成 AI を顧客接点改革につなげるいくつかのアイデアを紹介しました。生成 AI の基盤モデルを API 呼び出しできるフルマネージドな Amazon Bedrock を呼び出すだけのシンプルな構成で画像とテキストの 2 種類のデータを活用するアプリケーションを用意しました。このアプリケーションを使って「商品画像と商品説明文からユーザに訴求するメッセージを生成する」「商品の比較文を生成する」「画像やテキストを入力に柔軟な検索を行う」といった具体的なユースケースについてデモをお見せしました。 今回のデモのコードはは公開の準備が整いましたら別途ブログでご案内しますが、類似のアセットである Titan Multimodal Embeddings を用いた検索機能のサンプル や、マルチモーダルに限定せず幅広く AWS の生成 AI をお試しいただける生成 AI ユースケースデモ など既に公開されているものがありますのでご活用ください。 セッション 5. 顧客接点の変革を実現 – コンタクトセンターにおける生成 AI 活用術 アマゾン ウェブ サービス ジャパン合同会社 エンタープライズ技術本部 小売・消費財 第一ソリューション部 ソリューションアーキテクト　千代田 真吾 資料ダウンロードリンク 大丸松坂屋百貨店様の事例でもご紹介したクラウドベースのコンタクトセンターサービスである、Amazon Connect。Amazon Connectではこれまでにも AI/ML を組み込んだ機能が提供されています。このセッションでは、Amazon Connect に セッション 4 でも登場した Amazon Bedrock、エンタープライズナレッジ検索を実現する AI サービスの Amazon Kendra 、テキストから感情分析を行う自然言語処理 AI サービスの Amazon Comprehend を組み合わせ、「生成 AI による回答作成」「通話内容の自動要約」「お客様の感情分析」のデモを紹介しました。音声やテキストを扱うコンタクトセンター業務において、Amazon Connect と生成 AI や AI/ML サービスが技術的な親和性の高さだけでなく、エージェント業務の作業効率向上や生産性向上といった実用的な価値を生み出しやすいものであることがわかります。 デモでご紹介したソリューションのアーキテクチャやコードは公開されており、ブログ「 Amazon Bedrock と Amazon Connect によるコンタクトセンター向け生成系 AI ソリューションの構築手順 」の中で詳しくご紹介していますので、ご活用ください。 まとめ 今回のセミナーでは「顧客接点」をキーワードに、2 つのテクノロジー「クラウド化されたコンタクトセンター（Amazon Connect）」「生成 AI」を取り上げました。コンタクトセンターについては、顧客体験に対する利用者の期待に応えるため、大丸松坂屋百貨店様が取り組まれた Amazon Connect によるコンタクトセンター刷新のプロジェクトでどのような課題が解決できたのかをご紹介いただきました。もう一つのテーマである生成 AI については、企業にとっての宝である画像から価値を引き出すべく重ねられた工夫について、ルームクリップ様にお話いただきました。後半は AWS ソリューションアーキテクトから、マルチモーダル生成 AI で商品説明文生成やユーザーの検索を支援するユースケース、そして Amazon Connect と生成 AI を組み合わせたコンタクトセンター業務の実用的なデモをご紹介しました。事例、デモ、いずれも一つのソリューションで解決するのではなく、ビルディングブロックの組み合わせでビジネス課題を解決するものとなっており、まさに AWS の使いどころを感じていただけるものだったと思います。 2024 年 6 月 20、21 日に開催される AWS Summit Japan において、流通・小売・消費財業界向けの展示ブースをご用意します。今回ご紹介した生成 AI のデモをはじめ、店舗と e コマースをシームレスに繋ぐ新しい顧客のカスタマージャーニーや、次世代自動販売機などの物理デバイスなど「Accelerate Innovative Customer Journey」をテーマに展示いたしますのでぜひお立ち寄りください。 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しておりますのでご覧ください。 流通小売参考情報 [1] AWS ブログ ”流通小売” カテゴリー [2] AWS ブログ “消費財” カテゴリー [3] AWS 消費財・流通・小売業向け ソリューション紹介 ページ このブログは、ソリューションアーキテクト 杉中 が担当しました。

人生はいつも幸せだとは限らず、苦しいときもあります。それでも、私たちは歩みを共にする人たちと喜びや苦しみを分かち合うことができます。AWS コミュニティも例外ではありません。 Jeff Barr は、健康上の問題に直面している 2 人の AWS コミュニティメンバー を紹介しました。AWS コミュニティビルダーである Farouq Mousa は、脳腫瘍と闘っています。AWS サーバーレスヒーローである Allen Helton には、 白血病と闘う小さな娘 がいます。 Farauq と Allen の娘である Olivia への寄付を通じて、2 人が病を克服できるようにサポートしましょう。 5月27日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon EC2 ハイメモリ U7i インスタンス – 最大 32 TiB の DDR5 メモリと 896 個の vCPU を搭載したこれらのインスタンスは、カスタム第 4 世代インテル Xeon スケーラブルプロセッサ (Sapphire Rapids) 駆動のインスタンスです。これらのハイメモリインスタンスは、SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースをサポートするように設計されています。詳細については、 Jeff のブログ記事 をお読みください。 新しい Amazon Connect 分析データレイク – コンタクトレコード、エージェントパフォーマンス、Contact Lens インサイトなどを含めたコンタクトセンターデータに単一のソースを使用できるため、複雑なデータパイプラインを構築して維持する必要がなくなります。組織は、Amazon Connect データを使用して独自のカスタムレポートを作成したり、サードパーティソースからクエリされたデータを組み合わせたりすることができます。詳細については、 Donnie のブログ記事 をお読みください。 Amazon Bedrock Converse API – この API は、Amazon Bedrock モデルを呼び出すための一貫性のある手段を開発者に提供して、推論パラメータなどのモデル固有の違いを調整する複雑性を取り除きます。この API を使用すると、コードを一度記述するだけで、そのコードを Amazon Bedrock のさまざまなモデルでシームレスに使用することができます。詳細については、 使用を開始するための Dennis のブログ記事 をお読みください。 PartyRock の新しいドキュメントウィジェット – PartyRock を使用して、楽しむため、または個人的な生産性を向上させるための生成 AI 駆動のアプリケーションを構築、使用、共有することができます。PartyRock のウィジェットは、コンテンツの表示、入力の受け入れ、他のウィジェットとの接続、基盤モデルを使用したテキスト、画像、チャットなどの出力の生成を行います。これからは、新しいドキュメントウィジェットを使用して、ファイルやドキュメントからのテキストコンテンツを PartyRock アプリに直接統合できるようになります。 Amazon CloudWatch の 30 日間のアラーム履歴 – アラーム状態変化の履歴を最大 30 日前まで表示できます。これまで、CloudWatch は 2 週間のアラーム履歴を提供していました。この拡張履歴により、過去の動作の観察や、より長い期間にわたるインシデントの確認を簡単に実行できるようになります。詳細については、CloudWatch ドキュメントのアラームセクション をお読みください。 10 倍速くなった Amazon SageMaker Canvas の起動時間 – SageMaker Canvas を 1 分足らずで起動し、機械学習のための視覚的なノーコードインターフェイスの使用をこれまでよりも 10 倍速く開始できます。これからは、既存または新規の SageMaker ドメインで作成されたすべての新しいユーザープロファイルで、この迅速化された起動時間を経験できるようになります。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース こちらは、皆さんが興味を持つかと思われるその他のニュースと Twitch 番組です。 Let us manage your relational database! – Jeff Barr は、AWS の一部のお客様がクラウドでの独自のデータベースのホスティングを引き続き選択している理由をよりよく理解するためのアンケートを実施しました。アンケートの回答を起点として考えることにより、Jeff は AWS マネージドデータベースサービスが対処する 4 つの問題を取り上げました。独自のデータベースをホストする前に、ぜひこれらを検討してください。 Amazon Bedrock Serverless Prompt Chaining – このリポジトリは、プロンプトチェイニングを用いた複雑できわめてスケーラブルなサーバーレス生成 AI アプリケーションを構築するための、 AWS Step Functions および Amazon Bedrock の使用例を提供します。 AWS Merch Store スプリングセール – AWS ブランドの T シャツ、キャップ、バッグなどを購入しませんか? 今から 6 月 7 日まで、すべてのアイテムが 15% オフになります。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS World IPv6 Day – AWS エキスパートによるテクニカルプレゼンテーションの他、ワークショップやホワイトボードセッションが行われる、6 月 6 日開催の無料対面祝賀イベントにご参加ください。IPv6 の使用開始方法を学び、IPv6 導入ジャーニーを開始したお客様の話を聞くことができます。 サンフランシスコ 、 シアトル 、 ニューヨーク 、 ロンドン 、 ムンバイ 、 バンコク 、 シンガポール 、 クアラルンプール 、 北京 、 マニラ 、 シドニー のうち、お近くの都市のイベントをご確認ください。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください。日程は、 ストックホルム (6 月 4 日)、 マドリッド (6 月 5 日)、 ワシントン DC (6 月 26～27 日) です。 AWS re:Inforce – ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 10～12 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながるとともに、AWS のお客様と交流して、それぞれのセキュリティジャーニーについて学びましょう。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ニュージーランド (8 月 15 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) です。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 6月3日週はここまでです。6月10日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

分析はコンタクトセンターの成功に不可欠です。顧客エクスペリエンスの各タッチポイントのインサイトを取得することで、パフォーマンスを正確に測定し、変化するビジネスニーズに適応することができます。一般的なメトリクスは Amazon Connect コンソールにありますが、ビジネス固有のニーズに基づいてレポートを作成するために、より詳細な情報やカスタム要件が必要な場合もあります。 5月31日より、Amazon Connect 分析データレイクの一般提供が開始されました。2023年、 プレビュー として発表された通り、この新しい機能を使用すると、複雑なデータパイプラインを構築して保守する必要がなくなります。Amazon Connect データレイクはゼロ ETL 対応なので、抽出、変換、ロード (ETL) は不要です。 Amazon Connect 分析データレイクの外観を以下に示します。 Amazon Connect で顧客エクスペリエンスを向上させる Amazon Connect 分析データレイクでは、顧客のコンタクトレコードやエージェントのアクティビティなど、さまざまなデータソースを 1 か所に統合することができます。中央の場所にデータを配置することで、複雑なデータパイプラインの実装に関連するコストを削減しながら、コンタクトセンターのパフォーマンスを分析してインサイトを取得できるようになります。 Amazon Connect 分析データレイクを使用すると、コンタクトトレースレコードや Amazon Connect Contact Lens データなどのコンタクトセンターデータにアクセスして分析を行うことができます。その結果として、 Amazon Athena でデータの準備と分析を行い、 Amazon QuickSight や Tableau などのビジネスインテリジェンス (BI) ツールを使用できる柔軟性が提供されます。 Amazon Connect 分析データレイクの使用を開始する Amazon Connect 分析データレイクの使用を開始するには、最初に Amazon Connect インスタンスをセットアップする必要があります。新しい Amazon Connect インスタンスは、「 Amazon Connect インスタンスを作成する 」ページの手順に従って作成できます。今回は、Amazon Connect インスタンスを既に作成しているので、Amazon Connect 分析データレイクの使用を開始する方法から説明します。 まず、Amazon Connect コンソールに移動してインスタンスを選択します。 次のページで、 [分析ツール] に移動して [データ共有を追加] を選択すれば分析データレイクを設定できます。 ポップアップダイアログが表示されます。最初にターゲットの AWS アカウント ID を定義する必要があります。このオプションを使用すると、一元的なアカウントをセットアップして、複数のアカウントで実行されている Amazon Connect インスタンスからのすべてのデータを受信できます。次に、 [データタイプ] で、ターゲット AWS アカウントと共有する必要のあるタイプを選択できます。Amazon Connect 分析データレイクで共有できるデータタイプの詳細については、「 分析データレイクにテーブルを関連付ける 」を参照してください。 完了すると、すべてのデータタイプを共有したすべてのターゲット AWS アカウント ID のリストが表示されます。 AWS マネジメントコンソールを使用することに加えて、 AWS コマンドラインインターフェイス (AWS CLI) を使用してテーブルを分析データレイクに関連付けることもできます。サンプルコマンドを以下に示します。 $> aws connect batch-associate-analytics-data-set --cli-input-json file:///input_batch_association.json ここで、 input_batch_association.json は、関連付けの詳細を含む JSON ファイルです。以下に例を示します。 { "InstanceId": YOUR_INSTANCE_ID, "DataSetIds": [ "<DATA_SET_ID>" ], "TargetAccountId": YOUR_ACCOUNT_ID } 次に、ターゲットアカウントの AWS Resource Access Manager (RAM) コンソールでリクエストを承認 (または拒否) する必要があります。RAM は、複数の AWS アカウント間でリソースを安全に共有することのできるサービスです。AWS RAM に移動し、 [自分と共有] セクションの [リソースの共有] を選択します。 次に、リソースを選択して [リソース共有を承認] を選択します。 この段階で、Amazon Connect から共有リソースにアクセスできます。これで、 AWS Lake Formation の共有テーブルからリンクテーブルの作成を開始できるようになりました。Lake Formation コンソールで [Tables] ページに移動し、 [Create table] を選択します。 共有テーブルへの リソースリンク を作成する必要があります。次に、詳細を入力し、使用可能な データベース と 共有テーブルのリージョン を選択します。 次に、 [Shared table] を選択すると、アクセスできるすべての共有テーブルが一覧表示されます。 共有テーブルを選択すると、 共有テーブルのデータベース と 共有テーブルの所有者 ID が自動的に入力されます。適切に設定できたら、 [Create] を選択します。 データに対するクエリを実行するために、Amazon Athena コンソールにアクセスします。以下は、実行したクエリの例です。 この設定では、特定の Amazon Connect データタイプにアクセスできます。 Amazon QuickSight と統合することで、データを視覚化することもできます。次のスクリーンショットは、Amazon Connect のデータを示す Amazon QuickSight ダッシュボードの一部のビジュアルを示しています。 お客様の声 プレビュー期間中、お客様から Amazon Connect 分析データレイクについて多くのフィードバックをいただきました。お客様の声を以下に紹介します。 Joulica は Amazon Connect や Salesforce などのソフトウェアのインサイトをサポートする分析プラットフォームです。Joulica の創設者で CEO の Tony McCormack 氏は、「当社は、中核事業として、すべての規模の Amazon Connect の顧客にリアルタイムおよび過去のコンタクトセンター分析を提供しています。以前は、複雑なデータパイプラインを頻繁にセットアップする必要がありましたが、現在は Amazon Connect 分析データレイクを使用して、共通の顧客に実践的なインテリジェンスを提供するプロセスを簡素化できるようになりました」と語っています。 知っておくべきこと 料金 — Amazon Connect 分析データレイクは、Amazon Connect で最大 2 年分のデータに対して追加料金なしで使用できます。支払う必要があるのは、データを操作するために使用するサービスの料金だけです。 可用性 — Amazon Connect 分析データレイクは、米国東部 (バージニア北部)、米国西部 (オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、ロンドン) の AWS リージョンで一般提供されています。 詳細 — 詳細については、 分析データレイク のドキュメントページを参照してください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

はじめに 最新の技術を採用し、イノベーションを起こす能力は、組織が継続的な成功を収めるために必須の要件で、贅沢品ではありません。数千社の顧客が Amazon Web Services (AWS) 上でビジネスにおいて重要な SAP ワークロードを実行しており、ビジネスオペレーションの強化のための革新的なソリューション作りに新しい方法を求めています。最近、主流になってきた生成 AI 技術の発展により、顧客は Amazon Bedrock などの Amazon 生成 AI サービスを利用して、受注から現金化、調達から支払い、採用から退職、設計から生産などのビジネスプロセスでイノベーションを加速することを期待しています。このため、先週 AWS と SAP は 戦略的パートナーシップの拡大 を発表しました。これには新しい生成 AI 機能も含まれています。Amazon Bedrock モデルが SAP AI Core の SAP 生成 AI Hub で利用可能になりました。これにより、SAP ERP を利用する企業は、 SAP Business Technology Platform (SAP BTP) と Amazon Bedrock の基盤モデル(FM) を利用して生成 AI 対応のアプリケーション拡張を構築できます。このようにコアシステムを維持しつつイノベーションを行えます。このブログでは、AWS と SAP の技術的ガイダンスとして、「ジョイントリファレンスアーキテクチャ」(JRA) を提供します。これは、SAP エコシステム内で Amazon Bedrock の FM を利用したいお客様向けのものです。 AWS の生成 AI による構築 ビジネスシーンでの生成 AI 活用を検討するお客様は、生成 AI が企業全体のモダナイゼーション戦略を実現する上での指針を求めると同時に、SAP ワークロードに対するセキュリティやインフラストラクチャの信頼性についても高い水準を期待しています。生成 AI 技術を活用したモダナイゼーション、自動化、イノベーションを支援するため、完全マネージドサービスである Amazon Bedrock を新たにリリースしました。Bedrock では、 Anthropic 、 AI21 Labs 、 Cohere 、 Stability AI 、 Mistral 、 Meta Llama 、 Amazon Titan など、有力 AI 企業による高性能な基盤モデルを幅広く提供しています。 Amazon Bedrock には、プライバシーとセキュリティを確保しつつ、生成 AI アプリケーションの開発を簡素化するための包括的な機能が備わっています。主な機能には、自社データの取り込みによるモデルカスタマイズ、特定タスクに対するファインチューニング、社内ナレッジベース活用による発話精度向上 (Retrieval Augmented Generation)、さらには企業システムとのインタラクションによるタスク自動化に対応したインテリジェントエージェントの構築などがあります。Amazon Bedrock には、データの暗号化と SOC、ISO などの規格準拠により、セキュアな環境が提供されるため、革新的な AI 活用アプリケーションの開発に最適なソリューションといえます。 AWS は、他の生成 AI サービスに AWS Trainium と AWS Inferentia のようなインフラストラクチャを提供し、お客様がクラウド上で AI モデルを効果的に低コストで学習・推論を実行できるようにしています。 さらに、開発者は Amazon Q Developer を活用し、自然言語でのコメントや統合開発環境 (IDE) 内の前のコードに基づいてリアルタイムにコード候補を生成することで、生産性を向上させることができます。 AWS と SAP のパートナーシップ SAP と AWS は、2008 年からパートナーシップを結び、お客様が SAP アプリケーションをより効率よく実行し、イノベーションをよりスピーディに行えるようサポートしてきました。 SAP と AWS は提携し、モダナイゼーションの傘下にある実務的なビジネスシナリオに対処するための一連のリファレンスアーキテクチャを提案し、お客様に SAP Business Technology Platform (SAP BTP) を通じて AWS サービスの力を提供しています。 クリーンコア モデルを採用することで、これらのジョイントリファレンスアーキテクチャ (JRA) は、アプリケーション開発のフレームワークと SAP S/4HANA への統合された拡張機能を提供し、ビジネスプロセスの自動化と最適化を実現します。 SAP と AWS が共同で構築したこの JRA は、新しいスケーラブルなアプリケーション、分析ダッシュボード、または機械学習モデルの構築に関して、お客様に専門家による指針を提供しています。 AWS と SAP は、将来 SAP と AWS から新しいサービスや機能がリリースされた際に、JRA を適応させる予定です。 Amazon Bedrock の生成 AI モデルを SAP と統合 – ジョイントリファレンスアーキテクチャの概要 SAP では早い段階から生成 AI 技術を採用しており、SAP BTP 上で Generative AI Hub をリリースしています。SAP AI Core の Generative AI Hub は、目的別の AI 開発ツール、主要な AI 基盤モデルに対するエンタープライズグレードのアクセス、AI 搭載アプリケーション作成のための堅牢なデータ管理機能を提供しています。SAP AI Core の Generative AI Hub を通じて、Amazon Bedrock の生成 AI モデルを統合することで、SAP のお客様は Anthropic Claude3 、 Amazon Titan などの基盤モデルにアクセスできます。このジョイントリファレンスアーキテクチャにより、SAP 顧客は生成 AI の採用を加速し、SAP ソリューションに基づく主要なビジネスプロセスをモダナイズできます。これらの革新的な機能は、RISE with SAP やインテリジェントシナリオライフサイクル管理機能の組み込みユースケースとして、または SAP BTP 上で直接統合コンポーネントやサイドバイサイドで利用できます。顧客は Generative AI Hub と AWS サービスを活用して、SAP のクラウドソリューションやアプリケーションポートフォリオ内でカスタム AI 機能を強化する生成 AI ソリューションを構築できます。これにより、財務、人事など、さまざまなビジネス機能で新たな洞察と最適化が可能になります。SAP と AWS は、SAP のクラウドソリューションとアプリケーションポートフォリオ内に AI 機能を組み込むため、Generative AI Hub における Amazon Bedrock 機能の活用を拡大する計画です。これには、財務やプロダクトライフサイクル管理など、さまざまな分野でのユースケースが含まれます。 より詳しくアーキテクチャと関係する様々なコンポーネントを見ていきましょう。 Amazon Bedrock : Amazon Bedrock では、API を通じて幅広い大規模言語モデル (LLM) から選択できます。この JRA では、AWS で大量のデータセットで事前学習された基盤モデル (FM) ファミリである Amazon Titan と Anthropic の Claude を利用しています。これらは様々なユースケースをサポートできるように設計された、強力で汎用的なモデルです。そのままでも使えますし、独自のデータで私的にカスタマイズしても利用できます。 SAP AI Core 内の Generative AI Hub: SAP AI Core サービスは、大規模な言語モデルなどの AI アセットを顧客に公開し、SAP BTP エコシステム上で実行される SAP アプリケーションに統一されたインターフェイスを提供します。このジョイントレファレンスアーキテクチャでは、SAP AI Core 内の Generative AI Hub を、Amazon Bedrock へのアクセスと、ライフサイクル管理レイヤーとして利用し、アプリケーションがファンデーションモデルを消費できるエンドポイントを提示しています。Generative AI Hub を通して、SAP は中央で、さまざまなコンテンツフィルタリング、SAP 特有のリスク軽減策、セーフティーガードレールなどを実施し、SAP 全体でのビジネス上、法的リスクに対するスケーラブルかつコンプライアンスを重視したアプローチを提供しています。 SAP AI Core の Generative AI Hub では、開発者が管理下の商用及び法的フレームワークを通じて、さまざまなプロバイダの幅広い大規模言語モデル (LLM) に即座にアクセスできるようになります。このアクセスにより、開発者は複数のモデルを編成できます。Generative AI Hub は、SAP HANA Cloud のベクトル機能にも接続されます。これにより、開発者はハルシネーションの問題を低減し、コンテキストデータを埋め込むことで、特定のユースケースに合わせてより適切な結果を提供できるようになります。 データの保存と取得 : SAP HANA Cloud はマルチモデル データベース管理システムで、インテリジェントなデータアプリケーションを大規模に構築およびデプロイするのに役立ちます。SAP HANA ベクトルエンジンは、Retrieval Augmented Generation (RAG) をサポートして、LLM からより良い結果を得られます。 アプリケーション開発 : Cloud Application Programming (CAP) モデルは、 SAP Build を利用してクラウドアプリケーションを開発するアプローチの 1 つです。 CAP は、データモデリングをより構造化され、シームレスなフレームワークにし、他のサービスとの統合を強化します。 CAP はオープンソースと SAP のフレームワークを開発者に提供し、加速度的なイノベーションを通して開発を合理化します。 この JRA では、CAP を SAP UI5 フロントエンドにフロントされたアプリケーションのエンティティ層として使用しています。 認証と識別 : 大規模言語モデルはできるだけ多くのデータが必要ですが、クエリ時のユーザー認証は無視されるため、統合が困難です。この問題を回避するため、SAP BTP と SAP Identity Provisioning サービス を使用して、モデルのプロンプトに SAP と非 SAP のアイデンティティライフサイクルを管理します。 これらのコンポーネントを統合して利用することで、お客様は Amazon Bedrock と SAP BTP サービスを活用してスケーラブルで信頼性の高い 生成 AI 対応の SAP アプリケーションをフルスタックで構築できるようになります。 この JRA パターンは、エンタープライズグレードの SAP ランドスケープ内のビジネスプロセス拡張に広く適用できるだけでなく、SAP が推奨するクリーンコアアプローチの維持にも役立ちます。 まとめ このブログでは、SAP と AWS がお客様に提供する Amazon Bedrock の生成 AI 機能を SAP BTP で使用するためのリファレンスアーキテクチャに関するガイダンスについて説明しました。このアーキテクチャを使うことで、SAP ワークロードにこれまで大規模言語モデル (LLM) とトランスフォーマーモデル機能を補完し、SAP データの力を発揮してコストを抑えながらインサイトと運用効率を向上できるようになります。SAP と AWS は現在、ビジネス問題を解決し、自動化とイノベーションを通じてカスタマーエクスペリエンスを改善するために、SAP BTP 経由で Amazon Bedrock の生成 AI 機能を活用できる特定のユースケースを特定する取り組みを行っています。 続報をお待ちください。 2022 年〜 2023 年に AWS 上の SAP ワークロードのジョイントリファレンスアーキテクチャに関して、共同チームが発行した以下のブログをご覧ください。 SAP と AWS – 活用と投資を最大化するためのジョイントリファレンスアーキテクチャ AWS と SAP – Amazon Monitron を使用した IoT シナリオのためのジョイントリファレンスアーキテクチャ AWS for SAP や Amazon Bedrock の詳細は、 AWS for SAP 、 Amazon Bedrock の AWS 製品ドキュメント をご覧ください。 さらに専門家からのガイダンスが必要な場合は、AWS アカウントチームに連絡して、地域の SAP 専門ソリューションアーキテクトまたは AWS プロフェッショナルサービスの SAP 専門チームに問い合わせてください。 SAP on AWS に関する議論に参加 お客様のアカウントチームや AWS サポートチャネルに加えて、AWS for SAP ソリューションアーキテクトチームが AWS for SAP トピックの議論や質問を定期的に監視し、お客様やパートナーを支援するために答えられるような質問に回答する場を re:Post でも設けています。 質問がサポート関連ではない場合は、re:Post での議論に参加して、コミュニティの知識ベースに貢献することを検討してください。 AWS で SAP を実行されている数千を超えるエンタープライズのお客様について詳しくは、 AWS for SAP ページ をご覧ください。 謝辞 AWS と SAP のパートナーシップによるジョイントリファレンスアーキテクチャは、SAP と AWS の組織の深い協力とコントリビューションの結果です。 以下のメンバーの専門知識、サポート、ガイダンスに感謝いたします。 Team AWS: Sunny Patwari, Yuva Athur, Ganesh Suryanarayanan, Spencer Martenson, Steve DiMauro and Soulat Khan. Team SAP: Madankumar Pichamuthu, Weikun Liu, Daniel Zhou, Sivakumar N and Anirban Majumdar. 翻訳は Partner SA 松本が担当しました。原文は こちら です。

2024年5月16日にオンラインセミナー「生成 AI の価値を最大限に引き出すためのデータ基盤」を開催いたしました。セミナーの開催報告として、ご紹介した内容や、当日の資料・収録動画などを公開いたします。 はじめに 生成 AI の力を最大限に引き出すためには、日頃生み出しているビジネスデータを格納した強力なデータ基盤が必要不可欠です。既存の生成 AI モデルをそのまま活用するだけでなく、組織内に蓄積された独自のデータを活用することで、他社との差別化を図り、意思決定や業務へのインサイトを深めることができます。 当セミナーでは、生成 AI での活用を見据えたデータ基盤に興味のある方、もしくは社内外向け生成 AI に取り組む企業の IT 部門の方に向けて、お客様のデータに基づいた生成 AI を効果的に実現するためのデータアーキテクチャ構築手法のご紹介を行いました 。 どうぞ皆様の事業のご参考に、各講演者の録画/資料をご活用下さい。 生成 AI 力を引き出すためのデータアーキテクチャ 登壇者： AWS シニアソリューションアーキテクト 程 家 動画 : https://youtu.be/1AP0Q4AoZeQ 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-1-AWS_Database_Services_for_GenAI.pdf 生成AIを実現するには十分な量のデータが不可欠です。 初めのセッションでは、豊富なデータから価値を最大限に引き出すために、エンドツーエンドのデータアーキテクチャを適切に構築することの重要性を解説いたしました。 私達と一緒に仕事をしてきた多くのお客様が生成 AI の力を認めており、生成 AI に関するビジョンも持っています。多くの人が、生成 AI の基盤モデルと、より広い意味では LLM に焦点を当てていると感じています。それは重要ですが、氷山の一角にすぎません。表面下には、これらのアプリケーションが効果的、効率的、倫理的であることを保証するデータの管理、分析、統合、ガバナンスなどの複雑なエコシステムがあります。 ビジネスニーズに合った独自の 生成 AI アプリケーションを構築したい場合、組織のデータが差別化要因となります。 どの企業も同じ基盤モデルにアクセスできますが、真のビジネス価値を持つ 生成AI アプリケーションの構築に成功する企業は、自社のデータを使用して構築する企業です。 生成 AI にデータを使用するには、独自のモデルを構築する以外にも、様々な方法があります。 生成 AI の力を引き出すためのデータアーキテクチャにはソース間のデータ統合を容易にするサービスや機能、データを一元管理するデータレイク、生成 AI にコンテキストデータを提供するデータストア、目的別データベースデータのカタログ化と管理のための仕組みが必要になります。 生成 AI データ基盤としての AWS マネージドデータベースサービス 登壇者: AWS シニアソリューションアーキテクト 程 家 動画 : https://youtu.be/5S3QE4Ewm0U 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-1-AWS_Database_Services_for_GenAI.pdf 本セッションでは、そのうちデータベースについて重点的に解説していただきました。データベースがデータアーキテクチャ全体において果たす重要な役割と、生成 AI の基盤としての位置付けなどをご説明いたしました。 生成 AI アプリケーションに重要なセマンティックコンテキストを効率よく保存し、LLM にデータ提供できるようにするには、それぞれのコンテキストにあったデータストアを用意する必要があります。AWS は、お客様が利用しているデータベースや分析のワークロードをクラウド上で利用できるよう、幅広いサービスを提供しています。 AWS が提供するマネージド型のデータベースや分析サービスを利用することで、お客様はアプリケーションの増加や急増によるパフォーマンスの変動に対応するために、インフラストラクチャを過剰に配置する必要がなく、必要に応じて適宜スケールアップやスケールダウンを行う事ができます。 また、インフラストラクチャを維持するために固定資産を管理する必要もありません。AWS を利用する事で、お客様の貴重な時間をインフラストラクチャやミドルウェアの管理ではなく、お客様のビジネスに直結する生成 AI アプリケーション開発に時間を費やせるようになります。 本セッションでは、お客様が管理している NoSQL データベースやインメモリデータベースを対応するマネージドデータベースとして MogoDB 互換の Amazon DocumentDB 、Amazon ElastiCache 、Amazon MemoryDB for Redis を、マネージド型リレーショナルデータベースのソリューションとして、Amazon RDS  や Amazon Aurora を紹介しました。特に、Aurora/RDS PostgreSQL、AmazonDocumentDB、Amazon MemoryDB for Redis は生成 AI アプリケーションにおけるベクトル検索に対応していることも説明しました。 生成 AI データ基盤としての AWS マネージドアナリティクスサービス 登壇者: AWS ソリューションアーキテクト 平井 健治 動画 : https://youtu.be/jh4Zs0MVARc 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-2-AWS-Analytics_Services_for_GenAI.pdf 本セッションでは、生成 AI を有効に活用するためのアナリティクス環境に必要な要件と、要件を実現する AWS マネージドアナリティクスサービスについてソリューションアーキテクトの平井より紹介いたしました。 紹介にあたっては、データレイクやデータウェアハウスといった蓄積、データソースからのデータ連携、品質チェックや権限制御といったガバナンス、データの活用を促進するコラボレーションの順に、それぞれについて求められることと AWS サービスを解説いたしました。 例えばコラボレーションいついて、データ活用の促進にあたっては、組織の境界を超えたガバナンスに加えて、ビジネスデータカタログの整理と使いやすいポータル画面が求められますが、Amazon DataZone によって実現できます。セッションでは、データポータルの画面や、生成 AI によるメタデータ生成の自動化といったビジネスデータカタログの充実化に役立つ機能について解説いたしました。 セッションのまとめとして、AWS のアナリティクスサービスは、あらゆるデータワークロードやユースケースに最適な価格パフォーマンス、Zero-ETLを含む簡単かつ豊富なデータ統合の選択肢、エンドツーエンドのデータガバナンスによる迅速なデータ活用の提供を通して、生成 AI データ基盤の実現に貢献できることを紹介いたしました。 生成 AI アプリケーションでデータを活用 登壇者: AWS ソリューションアーキテクト 黒澤 蓮 動画 : https://youtu.be/YLFlbLgWUAs 資料リンク : https://pages.awscloud.com/rs/112-TZM-766/images/20240516-AWS-DATA-3-Leveraging_Data_with_GenAI_Applications.pdf 最終セッションでは、これまでに構築したデータ基盤を活用し、具体的に社内のデータを生成 AI に活用していく方法について解説いたしました。顧客のニーズや目的に合わせて、データを適切に組み入れることでどのように付加価値を生み出せるかについて、実践的な事例を交えてご紹介いたしました。 自社データを生成 AI に活用するための方法はいくつかあります。基本的には実装な簡単な手法から試していただき、より複雑なタスクや、精度が必要な場合はモデルのカスタマイズなどにチャレンジいただくことを推奨します。 終わりに 今回のイベントでは生成 AI を活用するためのデータ基盤とアプリケーションについて詳しくご説明させていただきました。今回のセッションが皆様のデータ活用のお役に立てれば幸いです。データ基盤や生成 AI 活用に関してぜひとも AWS を活用いただければ幸いです。 セミナー中に回答させていただいたご質問と回答 [ご質問] RAG だとハルシネーションが防げる仕組みをもう少し知りたいです。 [回答] ご質問ありがとうございます。RAG の場合、ユーザの目的にあった高い精度のセマンティックコンテキストを提供できれば、ハルシネーションを回避できます。そのため、ベクトルストアに必要なデータをベクトル埋め込みして利用できるようにすることや状況コンテキストを使ってプロンプトを補強することが大事です。 [ご質問] データパターンの選択について教えてください。 初めて生成 AI アプリを開発する場合、どのパターンから始めるとよいでしょうか。 必要となる計算リソースの大小で比較すると、スモールスタートに適したパターンはどれでしょうか。 また、データが十分に収集蓄積できていない場合、一旦、生成 AI を利用せずにシステムをプロトタイピングしておいて、段階的に生成 AI を導入することは可能でしょうか。 [回答] 一番手軽に始められるのは RAG パターンになります。 LLM の再トレーニングは特定のドメインに関連する大量のデータがなければ、精度良よいモデルをトレーニングできません。LLM のファインチューニングでは少量のデータでも問題ないのですが、ラベル付きデータ（教師）を用意する必要があります。このラベル付きデータの準備が難しい場合があります。一方、RAG パターンは既存のデータをベクトル埋め込みするだけで利用できます。ベクトル埋め込みに必要な Embedding のための AI モデルも Amazon Bedrock 上で提供しています。 [ご質問] FT (ファインチューニング)モデルと RAG モデルの比較が知りたいです。 ハルシネーションの頻度やコスト感など。 [回答] コンテキストデータやトレーニングに使用するデータの精度、量、種類に依存すると思います。 LLM の再トレーニングは特定のドメインに関連する大量のデータがなければ、精度良よいモデルをトレーニングできません。LLM のファインチューニングでは少量のデータでも問題ないのですが、ラベル付きデータ（教師）を用意する必要があります。御社ですと担当チームがおりますので、更に詳細なご連絡ができるかと思います。後日ご登録いただいたご連絡先にご連絡させていただければと思います、どうぞよろしくお願いいたします。 [ご質問] Amazon Data Zone のポータルは AWS の複数アカウントの情報などを統合することができると理解しましたが、Amazon Data Zone のサービスを動かす AWS アカウントは必要で、かつビジネスユーザー向けのカタログやこのポータルにアクセスする際は各ユーザー毎に AWS アカウントが必要になるであっていますか。 [回答] Amazon DataZone の利用いただくためには Redshift など他のサービスと同様に AWS アカウントは必要となります。 DataZone を利用するユーザ（ユーザ管理）についてですが、AWS IAM ユーザや、AWS IAM Identity Center でユーザを作成してデータポータルにアクセスしてご利用いただけます。 [ご質問] 大量のログデータをS3に格納する場合のベストプラクティスを教えて下さい。利用頻度は 1 日 1 回程度のバッチ処理でつかう程度です。 [回答] 分析用途で使用する場合は、列指向の Parquet 形式、かつ I/O 量を少なくするための圧縮すると良いです。さらに、日付単位で S3 のディレクトリを分けて保存すると日付単位でデータをアクセスする際に、該当ディレクトリ（パーティション）のみにアクセスされるのでコストおよび性能の面でさらに効果的です。 [ご質問] ナレッジベースを利用した品番検索ツールを作成しているのですが、検索精度をさらに高めるために、これを入力したらこれを持ってくる。といった過去の正解データを学習させたいと考えています。 その場合、ファインチューニングが必要だと思うのですが、やはりファインチューニングなしと比較してコストがかなり高額になってしまうのでしょうか？ [回答] おそらくその場合では、モデルの精度を高めるよりも検索精度を高める必要があると思います。そのためにはより精度の高い Embedding モデルを使う、検索方法として字句一致やセマンティック検索など複数の方法を取っていただくと良いかと思います。 [ご質問] Database Freedom Workshop とはなんでしょうか？ [回答] Database Freedom Workshop は AWS のソリューションアーキテクトがお客様の既存のデータベースに対してアセスメントを行い、移行の難易度、パフォーマンス、コストの観点から最適な移行先を提案したり、移行方式を提案したり、お客様のデータベースの移行プロジェクトを支援する無償のプログラムになります。詳細について御社担当チームからもご案内が可能です、別途個別にご連絡させていただきますのでどうぞよろしくお願いいたします。 著者プロフィール 程 家 () 平井 健治 (Kenji Hirai) は AWS Japan のソリューションアーキテクトです。流通小売業界のお客様を中心に技術支援を行うと共に、アナリティクス関連の技術支援も行っています。 黒澤 蓮 (Ren Kurosawa) は AWS Japan のソリューションアーキテクトで、Web 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。データアナリティクスサービスや機械学習の領域を得意としています。将来の夢は宇宙でポエムを詠むことです。  

みなさん、こんにちは。ソリューションアーキテクトの杉山です。 今週も 週刊AWS をお届けします。 AWS Summit が 6/20-21 にかけて幕張メッセで開催されます。このイベントはたくさんのセッションがあり、その中でも QuizKnock によるブース展示やクイズ大会、ステージ登壇するものがあります。これに関連して、YouTube で QuizKnock が動画 を出しているので、ぜひこちらもチェックしてみてください。また、 JR東日本山手線で AWS Summit の電車広告が掲載中 です。山手線に乗る機会がある方は、ぜひ見つけてみてください。 AWS Summit の事前登録 や、カレンダーでスケジュール予定も忘れずに行いましょう！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年5月27日週の主要なアップデート 5/27(月) アップデートはありませんでした 5/28(火) New Oracle to PostgreSQL built-in system functions in DMS Schema Conversion AWS Database Migration Service の DMS Schema Conversion 機能で、Oracle から PostgreSQL へ変換作業を支援するために、5 つの生成 AI の技術を応用した組み込み関数を提供開始しました。移行元の Oracle Database で利用している関数が、移行先の PostgreSQL 上でサポートされていない場合、DMS Schema Conversion 拡張パックを適用することで、不足している関数をエミュレートすることが可能となります。 AWS Network Firewall increases quota for stateful rules AWS Network Firewall で、ステートフルルールに関する Service Quota の上限緩和の申請が可能になりました。デフォルトの制限は、リージョンごとのファイアウォールポリシーあたり 30,000 が上限になっています。これを、最大 50,000 まで申請が出来るようになりました。この緩和によって、AWS 様々なセキュリティの脅威に対して、幅広いルールを実装しやすくなりました。 5/29(水) Amazon SageMaker Canvas announces up to 10x faster startup time Amazon SageMaker Canvas で起動時間が最大 10 倍高速になりました。Canvas の起動を開始してから 1 分以内に起動するようになり、データの準備、機械学習モデルの構築、生成 AI を使った会話型チャットインターフェースの利用などを素早く行えるようになりました。この高速化機能は、新規のユーザプロファイルが対象となっており、既存のユーザープロファイルは対象外になっています。私の環境だと 40 秒ほどで Canvas が立ち上がるようになり、高速化を体感できました。 Introducing the Document widget for PartyRock PartyRock で、新たに手元のドキュメントをアップロードし、それに基づいたテキスト出力を行うドキュメントウィジェット機能が追加されました。PartyRock は、アカウント登録するだけで、簡単に生成 AI アプリを作成、利用、共有ができる無料のウェブサイトです。AWS アカウントが不要で、Google アカウント、Apple アカウント、Amazon アカウントとリンクすると利用ができます。ドキュメントは、PDF、マークダウン、テキスト、ワードファイル、HTML、CSVなどの一般的なファイル形式をサポートしています。12 万文字までの制限があります。 こちらのサイト から利用ができますので、ぜひ体験してみてください。 Introducing Amazon EC2 High Memory U7i Instances Amazon EC2 で、初の DDR5 メモリベースの 8 ソケット製品である U7i インスタンスを提供開始しました。これは、最大 32 TiB のメモリと 896 個の vCPU が搭載されているインスタンスです。SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースや、大規模言語モデルなどの計算集約型ワークロードに最適です。U7i インスタンスは、12 TiB、16 TiB、24 TiB、32 TiB のメモリが搭載される 4 つのインスタンスタイプが提供されます。ストレージボリュームに対して最大 100 Gbps の Elastic Block Storage (EBS) 帯域幅を提供し、既存の U-1 インスタンスと比較して最大 2.5 倍の高速な再起動時間を実現します。U7i インスタンスは最大 200Gbps のネットワーク帯域幅を提供し、ENA Express をサポートします。詳細は こちらのページ をご確認ください。 5/30(木) Amazon Bedrock announces new Converse API Amazon Bedrock で新しく Converse API を提供開始しました。Converse API は、Bedrock でモデルを呼び出す際に、推論パラメータなどの違いを平準化し、統一的な呼び出し方法を提供します。今までは、Claude 3 や Titan、Llama、Mistral といった各種モデルの違いを意識する必要がありましたが、Converse API によって、統一的な方法で呼び出すことができ、簡単にモデルの切り替えができるようになります。また、 Claude 3 などの一部のモデルは Tool use (function calling) をサポートしており、外部 API 呼び出しが必要なタスクを実現しやすくなりました。Converse API の詳細はこちらの ドキュメント や  Getting Started をご確認ください。Tool use (function calling) の詳細はこちらの ドキュメント をご確認ください。 Powertools for AWS Lambda (Python) adds support for Agents for Amazon Bedrock AWS Lambda (Python) 用のオープンソース開発者ライブラリ Powertools for AWS Lambda (Python) が、Agents for Amazon Bedrock の作成を簡単にする新機能をリリースしました。Powertools for AWS Lambda (Python) を利用すると、直接 OpenAPI スキーマを自動生成が出来、Agents for Amazon Bedrock からのリクエストとレスポンスを管理するために必要なボイラープレートコードの作成の負担を大幅に削減できます。 Amazon QuickSight launches multi column sorting for Tables Amzon QuickSight で、テーブルを利用した際に、複数の列を使ったソートができるようになりました。Author が Visual を作成する際や、Reader が Dashboard を閲覧する際に、複数列を指定したソートができるようになりました。第一優先は A 列、次に B 列、最後に C 列、といった形で指定できます。詳細はこちらの ドキュメント をご確認ください。画像付きで操作方法を紹介しており、わかりやすく理解できます。 5/31(金) Amazon Connect provides Zero-ETL analytics data lake to access contact center data Amazon Connect で、コンタクトレコード、エージェントのパフォーマンス、Contact Lens の洞察などのデータを分析しやすくするために、Zero-ETL の特徴を持つデータレイク機能の提供を開始しました。複雑なデータパイプラインを構築する負担が減り、素早くデータ活用を始められます。Amazon Connect でデータレイクを有効化すると、Athena を使った SQL クエリーでアクセスができるようになり、例えば QuickSight といった BI ツール上でデータの可視化ができます。詳細はこちらの ドキュメント をご確認ください。 Announcing AWS DMS Serverless improved Oracle to Redshift Full Load throughput AWS Database Migration Service Serverless で、Oracle Database から Amazon Redshift へ Full Load を実行する際のスループットが 2 倍 ~ 10 倍に向上しました。Full Load は、データ移行元のテーブル全体をスキャンしてデータを取得し、データ移行先にデータを移行する処理です。Oracle Database と Amazon Redshift 間で Full Load 操作が行われていると検出されると、Full Load パフォーマンス強化が自動的に適用されます。詳細はこちらの ドキュメント をご確認ください。 AWS Marketplace announces amendments for AMI annual agreements AWS Marketplace で購入した AMI 製品の年間契約を変更する機能を提供開始しました。これによって、AWS Marketplace で購入した AMI を利用している EC2 インスタンスについて、インスタンスタイプの変更がやりやすくなります。以前は、最初に選択した EC2 インスタンスタイプに対してのみ割引が提供され、さらにインスタンスを追加したり、より大きなインスタンスタイプに変更する場合は、オンデマンド料金を支払うか、追加の年間プランを購入する必要がありました。アップデートで、いつでも新しいインスタンスタイプを追加したり、別のインスタンスタイプに切り替えたりできるようになりました。新しいインスタンスタイプのコストが高くなる場合でも、元の割引を維持でき、AWS Marketplace が新しいインスタンスタイプの按分コストを自動的に計算します。詳細はこちらの ドキュメント をご確認ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 6月 20 日、21 日は AWS Summit Japan が幕張メッセで開催されます。様々な生成AI関係のコンテンツを用意していますので、色々と眺めて頂いて「これが自分達でもできたら嬉しいな」という気づきを探してみてください。生成AIも言ってみれば「やりたい事を実現するためのツール」なので、何を実現したいかをイメージできていると、前に進みやすいのではないでしょうか。AWS Summit Japanはそのための良い機会ですので、ぜひご活用ください。 そして、AWS Summit Japanでは様々な業界向けのブースを設定します。今日は製造業のお客様向けのブース展示内容を少しだけご紹介します。製造業では熟練の技術者のノウハウ継承がひとつの課題になっており、生成AIによる解決が期待されている領域です。それに向けた解決策のひとつのアイデアとして、AIによる技能継承のサポートのデモを実施します。 ブログ記事 にまとめていますので、ぜひチェックしてみてください。 それでは、5 月 27 日週の生成AI with AWS界隈のニュースをお届けしていきましょう。 さまざまなニュース AWSとSAPが戦略的協業の拡大を発表し、お客様の生成AI活用を支援 AWSとSAPは長年にわたる協業関係を持っていますが、生成AIに関してもその協業関係を拡大することを発表しました。SAP AI CoreにAmazon Bedrockが統合され、Bedrockで利用可能な様々な基盤モデルをベースとしてお客様のデータでカスタマイズされたアプリケーションが実現できます。また、AWSが開発したアクセラレータであるAWS TrainiumとAWS Inferentiaを、将来のSAP Business AI製品のトレーニングと推論に活用する予定であり、これらを利用して大規模言語モデル(LLM)のトレーニングとファインチューニングを2日で完了したと発表しています。ぜひ、 プレスリリースの原文 をご覧ください。現時点では英文ではありますが、 概要を紹介するブログ記事 も公開されています。 AWS生成AI国内事例ブログ: コネヒト株式会社様、高度な質問検索機能を1ヶ月で実現 「 ママリ 」というママ向けQ&Aアプリ/情報サイトを展開する コネヒト株式会社 様の事例解説ブログを公開しました。この事例では、 Amazon Bedrock と Amazon OpenSearchService による検索拡張生成(RAG)を1ヶ月で実現しています。検索拡張生成(RAG)のメリットですが、「誤字が含まれるキーワードによる検索」「文章による検索」を実行した場合、単純な全文検索と比較して、望ましい結果を応答できる可能性が高いことがわかりました。ユーザさんに対して、より意図に沿った検索体験を提供できる手応えを感じたというコメントを頂いています。「サービスのユーザ体験向上」という価値を生み出したい方にとっては、参考になる事例ではないでしょうか。 AWS生成AI国内事例ブログ: 第一興商様、ヘルプデスク業務負荷軽減のために生成AIを活用 株式会社第一興商 様が開発・展開するカラオケシステム「 DAM 」といえば、多くの人が一度はお世話になった事があるのではないでしょうか？DAMは業務用のカラオケ機器ですので、機器の不具合や状況確認に対応する業務は重要です。ヘルプデスクでは問い合わせ内容をCRMに記録するそうなのですが、その負荷と内容のばらつきに課題があり、その点を Amazon Bedrock を介して生成AIを活用することで解決しようと考えました。特筆すべきは、当初はBedrockでClaude 2を利用していたそうですが、Claude 3 Haikuの利用を想定した検証に着手されている事です。Claude 2よりもコストを90%以上削減、レスポンスまでの時間短縮を達成見込みとのことで、生成AIを組み込んだアプリケーション開発におけるBedrockの「良いモデルが出たら切り替えやすい」というメリットをご活用いただいています。 AWS生成AI国内事例ブログ: 三井物産様、生成AIによる入札書解析の完全自動化に挑戦 三井物産株式会社 様は三井物産グループ内における入札業務で活用できる、生成AIによるソリューションの開発に取り組んでいらっしゃいます。様々な入札案件に参加する場合、数百ページにおよぶ入札書を確認する必要があるそうです。ですが海外事業の場合、読み解くのに30-40時間を要する、正確な理解には業界知識が必要、担当者の異動で知見が引き継がれない場合がある、といった課題がありました。この解決のために、入札書をAmazon S3にアップロードすると自動で解析を行う仕組みを開発しました。入札書に含まれる情報抽出にはLegal-RoBERTa-largeというモデルを利用し、その情報をさらに細かく分割・整理するためにAmazon Bedockを介してJurassic-2 Ultraを活用。解析結果はWeb UIで担当者の方に参照いただく仕組みです。これにより入札書の解析時間を70%短縮、これは年間2,000時間の作業時間に相当します。またAWSのフルマネージドサービスを利用することで運用費削減・負荷に応じた柔軟なスケーリングが可能になったそうです。 サービスアップデート Amazon BedrockのConverse APIを発表 Amazon Bedrock のメリットのひとつは、統一されたAmzaon BedrockのAPIで様々な基盤モデルを呼び出せることです。今回、そのメリットを強化する Converse API が公開されました。基盤モデルには、推論時のパラメータをはじめモデル毎に固有の違いがあります。これまでBedrockを介して基盤モデルを呼び出す場合、モデル毎のパラメータの違いは開発者が考慮し対応する必要がありました。Converse APIはこの手間を省き、様々なモデルをシームレスに呼び出すことを可能にします。また、Converse APIは複数回の会話のやりとりを行うマルチターン対話や、モデルのツール呼び出し(関数呼び出し)にも対応しています。 PartyRockがドキュメントファイルの処理に対応 PartyRock は、Amazon Bedrockで稼働する基盤モデルを利用したアプリケーションを構築する方法をGUIで学び、試せるサービスです。今回、PartyRockにドキュメントヴィジェットが追加されました。ドキュメントヴィジェットはPDFやCSVを含むテキストファイル、Microsoft Wordなどのドキュメントに対応しており、他のヴィジェットと接続することでドキュメントの内容を要約したり、それに基づいた画像生成などが容易に実現できます。 OracleからPostgreSQLへの移行を生成AIで支援する新機能を発表 AWS Database Migration Serviceは異種データベースの移行を容易にするサービスです。今回、 DMS Schema Conversion という機能で、生成AIによるデータベース移行を支援できるようになりました。これは生成AIによるスキーマ変換支援機能で、移行先のデータベースでサポートされていないデータベース関数を利用している際に、それをエミュレートすることで移行作業の負荷を軽減するものです。生成AIによる支援機能を利用するには 拡張パックの有効化 が必要ですので、ご注意を。 Powertools for AWS Lambda(Python)がAgents for Amazon Bedrockをサポート オープンソースのライブラリ、 Powertools for AWS Lambda(Python) が Agents for Amazon Bedrock に対応しました。Agents for Amazon Bedrockは基盤モデルや外部システムとのAPIによる連携が必要な複雑なタスクを処理する自立型エージェントアプリケーションを開発するための仕組みです。Powertools for AWS Lambda(Python)を利用すると、OpenAPIのスキーマを自動生成し、Agents for Amazon Bedrockからのリクエストとそれに対する応答を構成することを容易にします。 Amazon SageMaker Canvasのスタートアップ時間が最大10倍高速に Amazon SageMaker Canvas はコーディング不要で機械学習技術による正確な予測を提供するサービスです。今回、サービスのスタートアップ時間が最大10倍高速になり、データ準備・カスタマイズ・機械学習や生成AIモデルのデプロイを高速に実行できるようになりました。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

本稿は、2023 年 2 月 28 日に AWS Cloud Operations & Migrations Blog で公開された “ A detailed overview of Trusted Advisor Organizational Dashboard ” を翻訳したものです。 Amazon Web Service (AWS) 上でビジネスが成長するにつれて、リソースを最適化し、AWS のベストプラクティスに従う必要性も高まります。 AWS Trusted Advisor は、セキュリティ、パフォーマンス、コスト最適化、耐障害性、運用上の優秀性、サービスの制限という 6 つの独自の柱に沿って AWS インフラストラクチャを改善する方法を特定します。 AWS Support API によって、お客様は個々のアカウントごとに Trusted Advisor のデータをプログラムで取得できます。また、Trusted Advisor の組織ビュー機能では、組織内のすべての AWS アカウントに関する Trusted Advisor のレコメンデーションの統合ビューを提供します。組織ビューレポートは、JSON または CSV 形式で利用できます。お客様は多くの場合、このレポートを使用する際に困難に直面し、また、実用的なインサイトを特定したり、組織内のリーダーやテクニカルチームと共有したり、毎月のトレンドを分析するためには、更なる労力を必要とします。さらに、複数の AWS Organizations を持つお客様では、すべての AWS アカウントを横断した Trusted Advisor チェックの全体的なビューが必要となります。 本ブログ投稿では、 Cloud Intelligence Dashboards フレームワーク の一部としてインタラクティブでカスタマイズ可能な Amazon QuickSight ダッシュボードテンプレートである Trusted Advisor Organizational (TAO) Dashboard を紹介します。統合された Trusted Advisor レポートを可視化することで、組織はすべての AWS アカウントにわたって、よりコスト効率の高い設定やより強固なセキュリティ体制、よりパフォーマンスに優れたアプリケーションに向けて最適化を行うことができます。 裏側の仕組み Trusted Advisor レポートは、Amazon QuickSight が Trusted Advisor のフラグ付きリソースを可視化するために使用するデータセットです。このダッシュボードをデプロイすると、表示されるデータはビジネスの多くの分野で役に立ち、カスタムダッシュボードの起点として使用できます。 TAO Dashboard の Well-Architected Labs では、 Optimization Data Collection Lab を使用して Trusted Advisor データの収集を自動化する方法など、TAO Dashboard のデプロイ方法を順を追って説明しています。TAO Dashboard では Amazon S3、AWS Lambda、Amazon Athena、Amazon QuickSight などのサーバーレスサービスが使われています。 図 1. AWS Trusted Advisor からのレポートは Amazon S3 バケットに保存される (1)。Amazon Athena テーブルとビューは S3 バケットからデータをクエリするために使用される (2)。Amazon QuickSight は Athena ビューをソースとして QuickSight の SPICE ストレージにデータをロードし、ダッシュボードでデータを可視化する (3)。TAO Dashboard は、組織内の様々なユーザーと共有することができ、組織全体にわたって Trusted Advisor のフラグ付きチェックに迅速かつ簡単にアクセスが可能となる (4) Trusted Advisor Organizational Dashboard TAO Dashboard は、Summary シート、5 つの Trusted Advisor カテゴリー (Security、Cost Optimization、Fault Tolerance、Performance、Service Limits) の個別カテゴリーシート※、Security Hub Checks シート、Well-Architected Reviews シートの 8 つのセクションで構成されています。Summary シートは、Trusted Advisor の各カテゴリーの全体的な概要で、各カテゴリーの様々なチェックによって構成されており、AWS リージョンごとの Trusted Advisor の結果や、Trusted Advisor チェックのフラグ数が最も多いアカウントの内訳を可視化します。カテゴリーシートには、個々のリソースを含むより詳細な内容が含まれているため、影響度に基づいて改善の優先順位を決めることができます。これに加えて、ダッシュボードには、そのチェックが何を求めているのか、なぜ確認することが重要なのか、そしてどう対処するのかについてのインサイトが含まれています。Security Hub Checks シートでは、AWS Security Hub が有効になっているアカウントの結果を確認できます。Organizations 内の Well-Architected Tool で Trusted Advisor 統合が有効になっている場合、TAO Dashboard の Well-Architected Reviews シートには、特定された高リスクの問題 (High Risk Issues, HRI) が簡潔に表示されます。このタブは、Trusted Advisor の結果を整理する別の方法を提供し、特定のワークロードに対する HRI の解決を追跡するのに役立ちます。 ※ 2024 年 5 月現在、運用上の優秀性カテゴリーは未対応 図 2. TAO Dashboard の Summary タブのサンプル。9 つのグラフがあり、毎月の傾向がハイライトされた様々な側面からから、フラグ付きリソースを把握することができる セキュリティチェックの詳細を確認 AWS ではセキュリティが最重要であり、TAO Dashboard の最初に表示される詳細なデータは Trusted Advisor のセキュリティチェックに関連するものになっています。Security タブでは、AWS Identity and Access Management (IAM) アクセスキーローテーション、IAM パスワードポリシー、ルートアカウントの MFA、漏洩したアクセスキーなど、Trusted Advisor が提供する最も重要なセキュリティ関連チェックの詳細データを確認できます。 多くのチェックは、複数のビジュアルとフラグ付きリソースの表で表示されます。これに該当するチェックの場合、各アカウントにおける毎月のフラグ付きリソース数を示すグラフや、リソースにフラグが付けられた理由のように別の要因を示す表は、組織全体の大まかな概要を提供します。詳細な表では、AWS アカウント、AWS リージョン、ステータスを含む多くの要因に基づいて結果を並べ替えて、詳細を掘り下げることができます。 IAM アクセスキーローテーションチェックを詳しく見てみると、詳細ビューには、アカウント ID、個々の IAM ユーザー、期間のしきい値 (> 90 日、> 2 年など)、アクセスキーの名前、最後にローテーションされた日付、アラートレベル (黄または赤)、Trusted Advisor によってリソースに最初にフラグが付けられた日付、およびこのリソースにそのチェックのフラグが付けられた最新の日付が含まれることがわかります。この表を使用すると、任意の列で並べ替えて、組織にとって最も重要なことに焦点を当てることができます。これは、最も重要なアカウントに焦点を当てることを意味するかもしれませんし、むしろ最も古いキーに最初に焦点を当てたいかもしれません。優先順位を決めるのはお客様次第ですが、TAO Dashboard では結果を簡単に並べ替えることができ、アクセスキーが誰のものなのか、キーが最後にローテーションされたのはいつなのかをすべての AWS 環境にわたって確認する方法を提供しています。 コスト最適化を簡素化 クラウド財務管理は、クラウドでワークロードを実行する企業にとって、ますます注目されるようになっています。不要なリソースが起動されたままになっていたり、ワークロードの廃止後に関連リソースが適切にクリーンアップされていなかったりすると、コストが増加する可能性があります。Cost Optimization タブでは、Trusted Advisor が提供する最も重要なコスト関連チェックの詳細データを確認でき、Amazon RDS アイドル状態の DB インスタンス、使用率の低い Amazon EC2 インスタンス、利用頻度の低い Amazon EBS ボリューム、関連付けられていない Elastic IP Address のようなアイドル状態のリソースを素早く特定できます。 TAO Dashboard の Cost Optimization エリアでは使用率の低いインスタンス、関連付けられていない Elastic IP、アイドル状態のロードバランサーなどが検出できます。各チェックに含まれるピボットテーブルを使用して、ビジネスにとって重要なものに基づいて並べ替えやフィルタリングをすることで、少ない労力で大きな効果が期待できます。例えば、バックエンドインスタンスが接続されていないアイドル状態のロードバランサーや、関連付けられていない Elastic IPは、通常、少ない労力でクリーンアップできますが、この方法で分類されたリソースの数によっては、多くの労力を必要とする可能性があります。 Trusted Advisor のコスト最適化チェックは未使用のリソースだけでなく、より多くの対象をカバーしています。TAO Dashboard の Cost Optimization シートにある他の結果の中には、アクションの前にさらに検討が必要なものもありますが、コスト削減に繋がる可能性があるため、取り組む価値が十分にあります。使用率の低い Amazon EC2 インスタンスやアイドル状態の Amazon RDS インスタンスは、そのリソースを機械的に削除できるというわけでなく、テスト環境や定期的に実行されないバッチオペレーションの可能性があります。このような場合、インスタンスサイズを変更するか、自動シャットダウンのルールを実装することで、使用率の低い環境のコストを最適化できます。 レジリエンスリスクをハイライト AWS の VP & CTO である Werner Vogels の有名な言葉 “Everything fails all the time” (故障しないものは無い) を耳にしたことがある人は多いでしょう。AWS のアベイラビリティゾーンやサービスでイベントが発生した時にも重要なワークロードを稼働し続けるためには、障害に備えた設計が必要です。Fault Tolerance シートは、AWS 全体のワークロードとデータのレジリエンスに焦点を当てています。ここには Trusted Advisor が提供する最も重要な耐障害性チェックのデータが含まれており、Amazon EBS スナップショット、Amazon RDS バックアップ、Amazon RDS マルチ AZ、Amazon EC2 アベイラビリティゾーンのバランスなどの冗長性を調べることができます。 ワークロードを可能な限りレジリエントなものにすることで、チームは緊急対応に費やす時間を減らし、アプリケーション自体やその運用の改善により多くの時間を充てることができます。企業はこのデータを使用して、重要な EBS ボリュームの古くなったスナップショットを特定し、重要な本番データベースが複数のアベイラビリティゾーンにデプロイされていることを確認し、バージョニングが有効になっておらずデータ損失の可能性がある重要な S3 バケットを発見することができます。 アプリケーションの最高パフォーマンスを維持 システムやアプリケーションが最高のパフォーマンスを発揮できない場合、不要なコストやユーザーへの影響、さらには収益の損失といった副作用が発生します。TAO Dashboard の Performance シートは、使用率の高いインスタンスやルールが多すぎるセキュリティグループ、あるいは高いレイテンシによって、パフォーマンスが低下している可能性があるリソースを特定することに焦点を当てています。ここには使用率の高い Amazon EC2 インスタンス、Amazon EC2 セキュリティグループルールの増大、Amazon Route 53 エイリアスリソースレコードセット、CloudFront ヘッダー転送とキャッシュヒット率、CloudFront コンテンツ配信の最適化など、Trusted Advisor が提供する最も重要なパフォーマンスチェックのデータが含まれています。 Performance シートのビジュアルを使用してワークロードを最適化してください。そうすれば、ワークロードが最高のパフォーマンスを発揮し、どのようなトラフィック量も処理できます。ユーザーベースがグローバルである場合、S3 バケットに直接アクセスする代わりに CloudFront を使用することを検討してください。これにより、コンテンツがエッジロケーションでキャッシュされ、エンドユーザーのパフォーマンスが向上します。セキュリティグループルールの合理化を図り、必要なアクセスのみをインバウンドで許可するようにします。これはセキュリティ関連の改善でもありますが、パフォーマンスにも影響します。システムのポートがインターネットに公開されていると、接続を試行される可能性があります。この増加したトラフィックが想定以上にリソースを消費し、正当なトラフィックに影響を与えます。 サービスクォータがイノベーションの障壁になることを回避 サービスクォータは、すべてのお客様が必要な AWS クラウドリソースにアクセスできるようにするのに役立ちます。しかし、チームがビジネス上の課題に対するソリューションを構築している最中は、これらの制限が障壁となる可能性があります。Trusted Advisor は、アカウントがプロビジョニングされたリソースの 80% 以上を使用しているサービスクォータにフラグを付けます。TAO Dashboard では、80% のしきい値に達した制限の概要と、AWS アカウントに対してフラグが付けられた制限の内訳が表示されるため、最初にリスクの高いアカウントを簡単に特定できます。また、Trusted Advisor によってフラグが付けられたすべてのサービスクォータの詳細な表も表示されます。この表を使用すると、アカウント ID、リージョン、またはチェック名でフィルタリングでき、AWS 環境全体にわたってサービス上限緩和申請を実行できます。サービスクォータの引き上げに先手を打つことで、チームは承認を待つことなく、AWS で開発できるようになります。 まとめ 本ブログ投稿では、TAO Dashboard を使用して、AWS リソースのセキュリティ、パフォーマンス、耐障害性を向上させる方法をいくつか紹介しました。また、TAO Dashboard が組織全体のコストとサービス制限の管理に役立つ方法についても学びました。 ライブのインタラクティブなデモダッシュボード を使用して、Cloud Intelligence Dashboards の全機能をより深く理解してください。Cloud Intelligence Dashboards を使用してコンピューティングコストを削減し、ビジネスの拡大を続けられた 事例をご覧ください 。TAO Dashboard を導入してワークロードの改善やコストの削減を実施した場合は、ぜひフィードバックをお寄せください！ 著者について: Meredith Holborn Meredith Holborn はイギリスのマンチェスターを拠点とする AWS のテクニカルアカウントマネージャーです。彼女の役割は、お客様のクラウドジャーニーを支援し、支持することです。クラウドのコストを簡単に管理できるようにすることに情熱を持っており、それが Cloud Intelligence Dashboards チームの一員となったきっかけです。 Yuriy Prykhodko Yuriy は、ルクセンブルクを拠点とするプリンシパルテクニカルアカウントマネージャーです。お客様が AWS 上でワークロードを実行する際に、信頼性とコスト効率の高いシステムを構築し、運用上の優秀性を実現できるよう支援しています。また、コスト最適化の SME であり、AWS の Cloud Intelligence Dashboards の責任者でもあります。 翻訳はテクニカルアカウントマネージャーの河野が担当しました。原文は こちら です。

AWS IAM アイデンティティセンター の最近導入された機能として、 信頼されたアイデンティティ伝播 に基づいた新しいユースケースが発表されました。 一般的に使用されているビジネスインテリジェンス (BI) アプリケーションである Tableau でエンドユーザーのアイデンティティを Amazon Redshift に伝播できるようになりました。これには 3 つのメリットがあります。エンドユーザーの サインインエクスペリエンスが簡素化 されます。データ所有者は 実際のエンドユーザーアイデンティティに基づいてアクセスを定義 できます。監査人は ユーザーによるデータアクセスを検証 できます。 信頼されたアイデンティティ伝播では、データを消費するアプリケーション ( Tableau 、 Amazon QuickSight 、 Amazon Redshift クエリエディタ 、 Amazon EMR Studio など) からデータを保存および管理するサービス ( Amazon Redshift 、 Amazon Athena 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon EMR など) にユーザーのアイデンティティとグループメンバーシップを伝播できます。信頼されたアイデンティティ伝播は IAM アイデンティティセンターの機能で、複数の分析アプリケーションにわたるサインインエクスペリエンスを向上させ、データアクセス管理と監査を簡素化します。エンドユーザーはシングルサインオンのメリットを利用できるので、システムに接続するために引き受ける IAM ロールを指定する必要がありません。 詳細を説明する前に、用語を確認しておきましょう。 ここでは、ユーザーアイデンティティとグループメンバーシップを保持するシステムを指すために「 ID プロバイダー 」という用語を使用します。これらは、ユーザーに認証情報の入力を要求し、認証を実行するシステムです。例えば、 Azure Directory 、 Okta 、 Ping Identity などがあります。 サポートされている ID プロバイダーの完全なリストを確認してください 。 「 ユーザー向けアプリケーション 」という用語は、データを消費するアプリケーション ( Tableau 、 Microsoft PowerBI 、QuickSight、 Amazon Redshift クエリエディタ など) を指します。 最後に、「 ダウンストリームサービス 」は、データの処理、データの保存、またはデータへのアクセスの管理を行う分析エンジンとストレージサービス ( Amazon Redshift 、Athena、S3、 EMR など) を意味します。 信頼されたアイデンティティ伝播のメリットを理解するために、5月29日までデータアクセスがどのように付与されていたかを簡単に説明しましょう。ユーザー向けアプリケーションがダウンストリームサービスのデータにアクセスすると、アップストリームサービスは、一般的な認証情報 (「 tableau_user 」など) を使用するか、 IAM ロールを引き受けることによってダウンストリームサービスに対する認証を行います。その結果、2 つの課題が生じます。 まず、ダウンストリームのサービス管理者にとって、リクエストを行う実際のユーザーに合わせて微調整されたアクセスポリシーを定義することが困難になります。ダウンストリームサービスから見ると、すべてのリクエストは、その共通のユーザーまたは IAM ロールから送信されます。例えば、Jeff と Jane の両者が BusinessAnalytics IAM ロールに割り当てられている場合、読み取り専用や読み取り/書き込みなど、それぞれに異なるレベルのアクセスを付与することはできません。さらに、Jeff が Finance グループにも属する場合、操作を行うロールを選択する必要があります。同じセッションで両方のグループからデータにアクセスすることはできません。 次に、データアクセスイベントをエンドユーザーに関連付ける作業には、差別化につながらない手間のかかる作業が伴います。リクエストが BusinessAnalytics という IAM ロールから送信された場合、そのアクションの背後にいるユーザーを識別するには追加の作業が必要です。 この例は非常にシンプルに見えるかもしれませんが、実際の組織には、数百のデータセットに対応する数百のユーザーと数千のグループがあります。これは、私たちにとって Invent and Simplify の機会でした。 新しい信頼されたアイデンティティ伝播の設定が完了すると、ユーザー向けアプリケーションがキーボードを操作する実際のユーザーに代わってデータにアクセスするための技術的メカニズムが提供されます。実際のユーザーアイデンティティを知ることによって、主に 3 つのメリットが生まれます。 まず、ダウンストリームのサービス管理者は、 実際のユーザーアイデンティティ 、所属グループ、またはこれら 2 つの組み合わせに基づいてアクセスポリシーを作成および管理できます。ダウンストリームサービスの管理者は、ユーザー、グループ、データセットの観点からアクセスを割り当てることができるようになります。これは、ほとんどのお客様がデータへのアクセスについて考える自然な流れです。このようなパターンを実現するために IAM ロールへの中間マッピングは必要なくなります。 次に、監査人は、 システムログ内の元のユーザーアイデンティティ にアクセスできるようになり、ポリシーが正しく実装されていること、および会社または業界レベルのポリシーのすべての要件に従っていることを確認できます。 第 3 に、BI アプリケーションのユーザーは、 複数のアプリケーション間のシングルサインオン のメリットを活用できます。エンドユーザーにとっては、会社の AWS アカウントと IAM ロールに関して理解する必要がなくなります。代わりに、作業で行う他の多くのことで使い慣れた企業のシングルサインオンを使用して EMR Studio などにサインインできます。 信頼されたアイデンティティ伝播の仕組み 信頼されたアイデンティティ伝播は、業界の標準メカニズム ( OAuth2 と JWT ) に依存します。OAuth2 は、アクセス委任のオープンスタンダードです。ユーザーは自分の認証情報を公開することなく、サードパーティのユーザー向けアプリケーションに他のサービス (ダウンストリームサービス) のデータへのアクセスを付与できます。JWT (JSON ウェブトークン) は、2 つのパーティ間で転送されるアイデンティティとクレームを表現するコンパクトで URL セーフな手段です。JWT は署名されているため、その整合性と真正性を検証できます。 信頼されたアイデンティティ伝播の設定方法 信頼されたアイデンティティ伝播を設定するには、IAM アイデンティティセンター、ユーザー向けアプリケーション、ダウンストリームサービスにエンドユーザーアイデンティティと連携するように指示する必要があるので、これらの個々のコンポーネントでの設定が必要です。詳細はアプリケーションごとに異なりますが、すべて次のパターンに従います。 AWS IAM アイデンティティセンターで ID ソースを設定します 。AWS では、ほとんどの ID プロバイダーがサポートしている自動プロビジョニングを有効にすることを推奨しています。自動プロビジョニングは、 SCIM 同期 標準に従って機能し、ディレクトリのユーザーとグループを IAM アイデンティティセンターに同期します。現在 IAM アイデンティティセンターを使用して AWS マネジメントコンソール で従業員のフェデレーションを行っている場合、この設定は既に完了していると思われます。これは 1 回限りの設定で、このステップを個々のユーザー向けアプリケーションで繰り返す必要はありません。 ID プロバイダーでユーザーを認証するようにユーザー向けアプリケーションを設定します。例えば、Okta を使用するように Tableau を設定します。 ユーザー向けアプリケーションとダウンストリームサービスの間の接続を設定します。例えば、Amazon Redshift にアクセスするように Tableau を設定します。場合によっては、 Redshift 用の ODBC または JDBC ドライバーを使用 する必要があります。 次に、信頼されたアイデンティティ伝播に固有の設定を行います。例えば、ID プロバイダーでユーザーを認証するユーザー向けウェブアプリケーションが組織で開発されていて、現在認証済みのユーザーに代わって AWS 内のデータにアクセスする場合を考えてみます。このユースケースでは、IAM アイデンティティセンターで 信頼されたトークン発行者 を作成します。この強力な新しいコンストラクトでは、アプリケーションの認証済みユーザーを IAM アイデンティティセンターのディレクトリユーザーにマップして、信頼できるアイデンティティ伝播を利用できるようになります。 私の同僚の Becky が、このようなアプリケーションを開発する方法を紹介するブログ記事を書いています 。この追加設定は、AWS の外部で認証される Tableau などのサードパーティアプリケーション (またはお客様が開発したアプリケーション) を使用する場合にのみ必要です。AWS が管理するユーザー向けアプリケーション (Amazon QuickSight など) を使用する場合、追加のセットアップは必要ありません。 最後に、ダウンストリームサービスの管理者は、ユーザーアイデンティティとグループメンバーシップに基づいてアクセスポリシーを設定する必要があります。正確な設定は、ダウンストリームサービスごとに異なります。アプリケーションが Amazon S3 でデータの読み取りまたは書き込みを行う場合、データ所有者は Amazon S3 コンソールで S3 Access Grants を使用して、ユーザーとグループに Amazon S3 内のプレフィックスへのアクセスを付与できます。アプリケーションが Amazon Redshift データウェアハウスにクエリを行う場合、データ所有者は Amazon Redshift コンソールで IAM アイデンティティセンターの信頼された接続を設定し、ID プロバイダーからのオーディエンスクレーム ( aud ) に一致させる必要があります。 設定の高レベルの概要が理解できたところで、最も重要な部分であるユーザーエクスペリエンスの詳細を確認しましょう。 エンドユーザーエクスペリエンス エンドユーザーの正確なエクスペリエンスはアプリケーションごとに異なるのは明らかですが、いずれの場合でも、従業員ユーザーにとっては以前よりもシンプルで使い慣れたものになります。ユーザーインタラクションは、リダイレクトベースの認証シングルサインオンフローから始まります。このフローでは、ユーザーは ID プロバイダーにリダイレクトされ、そこで認証情報や多要素認証などを使用してサインインできます。 信頼されたアイデンティティ伝達が設定されている場合にエンドユーザーが Okta や Tableau とどのようにやり取りするかを詳しく見ていきましょう。 以下にシステムとサービスの間のフローと主なインタラクションの図を示します。 この仕組みを以下に示します。 1.ユーザーとして Tableau にサインインを試みます。 2.Tableau がブラウザーベースのフローを開始し、Okta のサインインページにリダイレクトします。ユーザーは、このページでサインインの認証情報を入力できます。認証が成功すると、Okta は Tableau に認証トークン (ID とアクセストークン) を発行します。 3.Tableau が Amazon Redshift との JDBC 接続を開始し、接続リクエストにアクセストークンを含めます。Amazon Redshift JDBC ドライバーが Amazon Redshift を呼び出します。Amazon Redshift 管理者が IAM アイデンティティセンターを有効にしているので、Amazon Redshift はアクセストークンを IAM アイデンティティセンターに転送します。 4.IAM アイデンティティセンターがアクセストークンを確認して検証し、アクセストークンを アイデンティティセンター発行のトークンと交換します。 5.Amazon Redshift はアイデンティティセンターのトークンを解決し、対応するアイデンティティセンターユーザーを決定してリソースへのアクセスを許可します。認証が成功すると、ユーザーは Tableau から Amazon Redshift に接続できます。 認証が完了すると、いつものように Tableau を使い始めることができます。 Amazon Redshift クエリエディタに接続すれば、 sys_query_history テーブルを参照して、クエリを実行したユーザーが誰であるかを確認できます。Tableau からの接続に使用された Okta の E メールアドレスが awsidc:<email address> として正しくレポートされます。 この設定の詳細については、 Tableau のドキュメント を参照してください。 料金と利用可能なリージョン 信頼されたアイデンティティ伝達は、 現在 AWS IAM アイデンティティセンターを利用できる 26 の AWS リージョン で追加コストなしで提供されています。 信頼されたアイデンティティ伝播とダウンストリームサービスの設定の詳細については、以下を参照してください。 Simplify workforce identity management using IAM Identity Center and trusted token issuers Integrate Okta with Amazon Redshift Query Editor V2 using AWS IAM Identity Center for seamless Single Sign-On Simplify access management with Amazon Redshift and AWS Lake Formation for users in an External Identity Provider Bring your workforce identity to Amazon EMR Studio and Athena How to develop a user-facing data application with IAM Identity Center and S3 Access Grants (全 2 部) ご活用ください。 信頼されたアイデンティティ伝播では、分析システムを設定して、実際のユーザーアイデンティティ、グループメンバーシップ、属性を Amazon Redshift 、 Amazon Athena 、または Amazon S3 などの AWS のサービスに伝播できるようになります。その結果、これらのサービスのアクセスポリシーの管理が簡素化されます。また、監査人は、データにアクセスしているユーザーの実際のアイデンティティを把握する組織のコンプライアンス体制を検証できます。 今すぐ始めて、Amazon Redshift と Tableau の統合を設定してください。 — seb PS: AWS でのブログ記事の執筆は、常にチームとしての取り組みとなります。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、信頼されたアイデンティティ伝播の多くの微妙な点と技術的詳細の理解に関する多くの支援に対して Eva Mineva 、 Laura Reith 、 Roberto Migli に謝意を表します。 原文は こちら です。

2024 年 5 月 17 日に開催したウェビナーでは、2024 年 4 月にラスベガスで開催された NAB Show 2024 の AWS の出展内容の振り返りと、Amazon Bedrock で生成 AI を活用した北海道文化放送様の具体的なユースケースを紹介しました。 NAB Show 2024 では、次の 6 つのソリューションエリアで、AWS が提供するメディア & エンターテインメント向けソリューションの最新アップデートや機能強化と共にデモ展示を行いました。 [コンテンツ制作]  クラウドベースの一連の制作ワークフロー [放送・ライブ制作]  クラウドニュースルーム”NAB Show Live” に加え、ライブ制作関連の展示 [メディアサプライチェーン & アーカイブ] AI やクラウドツールによるコンテンツ制作~配信~収益化までのプロセス効率化、コスト削減、付加価値創出 [Direct to Consumer & ストリーミング] 配信機能、視聴体験向上、広告挿入、多様なコンテンツ形式( ライブ/ VOD / FAST )、モニタリング/可観測性 [Monetization – 収益化] 広告販売、測定、次世代広告フォーマット、プライバシー保護下でのデータ活用、Amazon 各サービスとの連携 [データサイエンス & 分析]  AI データ分析を活用したメディアワークフローの構築メリットと適用例 セミナーのアジェンダ: NAB Recap – コンテンツ制作 – NAB Recap – 放送とメディアサプライチェーン – NAB Recap – D2C & ストリーミング、データサイエンス & 分析、収益化 – 報道用の業務改善における AWS と 生成 AI の活用事例 NAB Recap – コンテンツ制作 – アマゾン ウェブ サービス ジャパン合同会社 / Visual Compute 事業開発 / 菊地 蓮 [ 資料 ] コンテンツ制作への取り組みを、先日発表した新サービス AWS Deadline Cloud と共に紹介しました。 NAB Recap – 放送とメディアサプライチェーン – アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 井村 紀彦 [ 資料 ] クラウドニュースルーム、ライブクラウドプロダクション、放送の監視とオブザーバビリティ(可観測性)、メディアサプライチェーンへの取り組みについて紹介しました。 NAB Recap – D2C & ストリーミング、データサイエンス & 分析、収益化 – アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 本多 和幸 [ 資料 ] 次世代のマネタイズ手法、AIML を活用したデータ分析手法、コンテンツ活用手法、動画配信における End to End ワークフローについて紹介しました。 報道用の業務改善における AWS と 生成 AI の活用事例 北海道文化放送株式会社 / 編成局 編成部 兼 メディア局 デジタル戦略室  /杉本 歩基 様 [ 資料 ] 北海道文化放送様では、ニュース動画のネット配信における制作コストの低減に取り組んでいます。AWS のサービスである、Amazon Bedrock や Amazon Polly を活用し、ニュース原稿の自動生成や動画制作の効率化を図っています。これにより、素早く一定品質の初稿原稿の作成が可能となったほか、SNS 等への動画の配信数の増加を実現しています。この一連の取り組みを少人数かつ低コストで開発・運用を行っている実例をご紹介いただきました。 おわりに 本ブログでは、2024 年 5 月 17 日に開催されたメディアセミナーについて紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 —- 参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは BD 山口が担当いたしました。

こんにちは。ソリューションアーキテクトの齋藤です。三井物産株式会社(以下、三井物産) デジタル総合戦略部 デジタルテクノロジー戦略室では、先端技術の調査・検証、および、先端技術をてこにした新規事業の企画や事業性検討（R&D）を行っております。また、本 R&D 活動の中で創出されたソリューションやプロダクトを、事業本部と連携して社内外へ展開しています。本ブログは、三井物産がどのように AWS 上で生成 AI を活用し、三井物産グループ内における入札業務に活用可能なソリューションの開発につなげたか、三井物産 デジタル総合戦略部 デジタルテクノロジー戦略室 伊藤友貴 氏 から寄稿していただいたものです。 背景 AWS : 入札書解析業務に生成 AI を活用するに至った際の背景を教えてください。 三井物産 伊藤様 : 三井物産は総合商社ということもあり、国内公共事業、大規模プロジェクト（都市開発, 風力発電など）海外事業の入札案件に参加することが頻繁にあり、このとき数百ページにおよぶ入札書の内容を確認しますが、ここにビジネスとして下記の課題がありました。 海外事業での入札の場合、入札仕様書が英語記載のため担当者が理解するのに熟練者でも 30 〜 40 時間がかかる。 正確に案件を理解するために、入札書に記載されている事業の業界知見が必要になる。 担当者が 3〜5 年周期で異動があり、知見が引き継がれないケースがある。 元々、三井物産では上記ビジネス課題を解決するために、自然言語処理を用いたソリューション開発に関する取り組みをしていました。最初の顧客として、弊社グループ企業である三井物産スチール株式会社の協力を得て、継続的フィードバックをもらいながら取り組んでおり、本プロジェクトの、いちツールとして生成 AI を活用しています。 AWS : どのような要件が、ユーザー（入札担当者）から上がりましたか ? 三井物産 伊藤様 : 商社の業務として、公共入札に参加することがあります。発注者から入札広告が行われたら、担当者は数百ページにおよぶ入札書類を読み込み、その内容を社内外の関係者に確認します。その後、発注者へのカウンター（回答）案を作成必要があります。通常入札書類の読み込みには 30 〜 40 時間程度必要とします。担当者は、入札書類から必須で確認すべき項目（金額, 契約期間, 納品日, 条件など）を把握することができて、抽出された項目が入札書類のどの文書を参照して抽出されたかを自身で把握できるようにしたいと要望が上がりました。 AWS : 三井物産様のような総合商社が入札するプロジェクトは、公共事業など数 10 億円から数 100 億円になる大規模案件になる場合が多いと予想しています。さっそくではありますが、入札書解析システムのソリューションについて説明していただいてもよろしいでしょうか ? 三井物産 伊藤様 : 全体アーキテクチャは下記の通りです。 入札書解析システム アーキテクチャ ソリューション 三井物産 伊藤様 : 入札書解析システムは、AWS のフルマネージド型のサービス を中心としたアーキテクチャで構成されています。対象の入札書を Amazon S3 にアップロードすると、自動で解析業務が実行されます。AWS Fargate は、Amazon S3 に格納されている入札書を取得し、大規模言語モデルの Legal-RoBERTa-large を用いて、入札業務に必要な項目を抽出します。Legal-RoBERTa-large で抽出された項目は、そのままでは使用することが出来ず、さらに細かく分割する必要があります。これに、AI21 Labs が開発した大規模言語モデルである、Jurassic-2 Ultra を、Amazon Bedrock 上で使用しています。分割された項目は Amazon DynamoDB に保存されます。 担当者は、WEB UI を通じて、入札書の解析結果を確認することができます。 入札書解析システム UI 本システムで工夫した点は以下です。 入札書から抽出された項目で、契約期間日、引渡日、特記事項など、入札担当者が必ず確認する必要がある項目にフラグを指定することができます。 Legal-RoBERTa-large で抽出した項目が多数あるので、AWS Fargate から、Amazon Bedrock が提供する API を通じて Jurassic-2 Ultra を並列で呼び出し、入札書解析の処理時間を短くすることができます。 なお、本取り組み成果にの一部ついては、2024 年 5 月に開催の Web データマイニング分野のトップ会議、 The Web Conference 2024 の DEMO Track にて発表されました。 Why AWS ? AWS : 入札書解析システムに、AWS が採用された決め手を教えてください。 三井物産 伊藤様 : まず、AWS 技術者の数です。他社と比較して、使える技術者の多さ、学習教材の多さもポイントです。これは、構築委託をする場合、パートナー選定時における幅広い選択肢につながりました。又、Amazon Bedrockを採用することで、複数 LLM の試行錯誤を簡単に実施することが可能です。最終的に、Jurassic-2 Ultra を採用しましたが、Claude を初めとする他 LLM の検証も並行して実施しました。 導入効果と今後の展望 AWS : 入札書解析システムの導入効果および今後の展望について教えてください。 三井物産 伊藤様 : 導入効果として大きく 3 つあります。 システム導入後には入札書の解析時間が、今までより 70 % 短縮することに成功しました。これは年間で 2,000 時間分の作業時間になります。 33 時間 → 21.2 時間、約 12 時間削減（入札業務 経験豊富） 96 時間 → 30.4 時間、約 65 時間削減（入札業務 経験少なめ） AWS のフルマネージド型のサービス を採用することにより、OS やミドルウェアの開発・保守などの運用費削減にもつながりました。 AWS のフルマネージド型のサービス を採用することにより、システム全体に拡張性を持たせられるので、使用量に応じて柔軟にスケーリングが可能です。 今後の展望として、まずは三井物産事業部内に横展開、その後は社外への販売を検討しています。既存の仕組みを継承しつつ、顧客の要件に応じてフロントエンドをカスタマイズすることで、開発コストおよび期間が 10 分の 1 になり、より価値あるサービスを顧客へ提供していくことを目指しています。 著者について 伊藤 友貴 2020年東京大学大学院工学系研究科博士後期課程修了。博士（工学）。 大学院では主にAI・テキストマイニング・解釈可能な AI に関する研究に従事。この研究は AI およびデータ解析分野のトップ会議 AAAI や ICDM 等にに採択。 博士課程終了後、三井物産に入社。入社後は新規事業立上げを見据えた自然言語処理に関する R&D や社会実装に従事。本取組成果の一部は Web 分野のトップ会議 WWW に採択。

re:Invent 2023 で プレビュー として発表された、最大 32 TiB の DDR5 メモリと 896 個の vCPU を搭載する Amazon Elastic Compute Cloud (Amazon EC2) U7i インスタンスが利用可能になりました。カスタム第 4 世代インテル Xeon スケーラブルプロセッサ (Sapphire Rapids) 駆動のこれらのハイメモリインスタンスは、SAP HANA、Oracle、SQL Server などの大規模なインメモリデータベースをサポートするように設計されています。仕様はこのようになっています。 インスタンス名 vCPU メモリ (DDR5) EBS 帯域幅 ネットワーク帯域幅 u7i-12tb.224xlarge 896 12,288 GiB 60 Gbps 100 Gbps u7in-16tb.224xlarge 896 16,384 GiB 100 Gbps 200 Gbps u7in-24tb.224xlarge 896 24,576 GiB 100 Gbps 200 Gbps u7in-32tb.224xlarge 896 32,768 GiB 100 Gbps 200 Gbps 新しいインスタンスは、大規模なインメモリワークロードに対して最高のコンピューティングコストパフォーマンスを実現し、大手クラウドプロバイダーのどの SAP 認定仮想インスタンスよりも高いメモリ容量とコンピューティング能力を提供します。 AWS Nitro System のおかげで、インスタンスのメモリを余すことなく使用できます。こちらは 32 TiB インスタンスの例です。 前世代 の EC2 ハイメモリインスタンスと比較すると、U7i インスタンスは 135% を超えるコンピューティングパフォーマンス、最大 115% のメモリパフォーマンス、および 2.5 倍の EBS 帯域幅を提供します。拡大された帯域幅により、1 時間以下で 30 TiB のデータを EBS からメモリに転送できるため、データのロードとキャッシュ更新がこれまでにない速さで行われるようになります。インスタンスは、フローあたりの帯域幅を 25 Gbps にする ENA Express もサポートしており、インスタンス間の P99.9 レイテンシーを 85% 削減します。 各 U7i インスタンスは、最大 128 の汎用 (gp2 および gp3) またはプロビジョンド IOPS (io1 および io2 Block Express ) EBS ボリュームのアタッチメントをサポートします。io2 Block Express ボリュームは、それぞれ最大 64 TiB まで拡張でき、最大 32 Gbps で最大 256,000 IOPS を提供できるため、U7i インスタンスに最適です。 インスタンスは、本番環境で Business Suite S/4HANA、Business Warehouse on HANA (BW)、SAP BW/4HANA を実行するための SAP 認定を受けています。詳細については、 Certified and Supported SAP HANA Hardware および SAP HANA to AWS Migration Guide を参照してください。 AWS Launch Wizard for SAP を読むこともお勧めします。 知っておくべきこと 以下は、新しいインスタンスについて知っておきたい事柄です。 リージョン – U7i インスタンスは、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびアジアパシフィック (ソウル、シドニー) の各 AWS リージョンでご利用いただけます。 オペレーティングシステム – サポートされているオペレーティングシステムには、Amazon Linux、Red Hat Enterprise Linux、SUSE Linux Enterprise Server、Ubuntu、Windows Server が含まれます。 より大規模なインスタンス – お客様のニーズに応えるため、AWS では、より優れたコンピューティング能力を備えたさらに大規模なインスタンスの年内提供にも取り組んでいます。 – Jeff ; 原文は こちら です。

本ブログはコネヒト株式会社様と Amazon Web Service Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの瀬高です。 昨今、生成 AI が盛り上がりを見せていますが、特にユースケースとして多い RAG (Retrieval Augmented Generation) に関する事例をご紹介します。 RAG とは生成 AI モデルと外部の独自情報をかけ合わせる技術となっており、ビジネスで既に活用しているデータやドキュメントを活かした回答精度の向上や、事実に基づかない回答をする「ハルシネーション」のリスク軽減ができる点から注目されています。(RAG の詳細は こちら ) この記事では 2023 年 12 月に コネヒト株式会社様 で取り組んでいただいた Amazon Bedrock と Amazon OpenSearch Service を活用し、質問検索の体験向上について 1 ヶ月という短い期間で検証をしていただいた事例となります。 本取り組みは コネヒト株式会社様による開発者ブログ にて、詳細に解説いただいています。あわせて御覧ください。 お客様の状況と検証に至る経緯 コネヒト株式会社様は、 ママリ というママ向け Q&A アプリ/ 情報サイトを AWS 上で実装、運営しており、2022年より Amazon OpenSearch Service を利用したサービス内質問の検索機能を提供していました。 その中でも、プレミアムユーザー向けの機能である、質問の人気順ソート機能が大きな加入要因となっている点から、利用者の検索体験をより良いものにすることで、プレミアム会員の価値向上を目指したいという考えがあり、生成 AI とのかけ合わせによる検索体験の向上を検証することになりました。 今回の検証について 今回は Amazon OpenSearch Service を利用した全文検索システムを提供しているという点を活かし、実際に利用しているデータのベクトル化を行い、ベクトル検索と全文検索を1ヶ月という短期間で比較検証を行い、ベクトル検索の優位な点を検証されていました。 ベクトル検索を実行するために必要なベクトルデータは Amazon Bedrock の埋め込みモデルによって生成しています。Amazon Bedrock から利用できるモデルの中には単語やテキスト、画像などを AI や言語モデルが使いやすい数値ベクトルへ変換するために用いられる「埋め込みモデル」と言われるモデルがあります。今回はコンテキスト長や対応言語の観点から、 Titan Embeddings を利用してベクトル化を行っています。 次にベクトルデータを格納する Amazon OpenSearch Service 内に全文検索とベクトル検索、両方に対応したインデックスを作成しました。 インデックスを作成する前にドメインを作る必要があります。ドメインの作成方法については こちら をご参照ください。 検証では opensearch-py というライブラリを用いて Python でインデックスを作成しており、bulk 関数を用いてデータを登録しています。 データの登録が終わり、下記の 5 つのケースについて検証を実施しています。 ケース1. クエリが一つの単語で構成される場合 ケース2. クエリが複数の単語で構成される場合 ケース3. クエリに固有名詞を含む場合 ケース4. クエリに誤字を含む場合 ケース5. クエリに文章を使用した場合 検証結果としては、固有名詞を含むクエリなどは苦手とする一方、 誤字を含むクエリでは本来入力しようとした情報を踏まえた検索結果の返却や、文章をクエリとする検索では全文検索以上にユーザーが求める検索結果が返る可能性がある ことがわかりました。 検証の結果と今後について マネージドサービスである Amazon OpenSearch Service の活用や、Amazon Bedrock による API を通した既存テキストデータの埋め込みデータへの変更、全文検索とベクトル検索の比較という内容を1ヶ月という短期間で構築、検証結果を得ることができました。 検証結果については、全文検索にも固有名刺を含むケースや単語が確実に含まれている質問を出したいケースなど優れた点がありつつも、誤字や曖昧表現にも強く自然言語などをもとに高い精度で検索ができる、ベクトル検索の特徴を活かした検索ができる場面があることがわかりました。 コネヒト株式会社様は 全文検索とベクトル検索の検索スコアを統合し、両者のメリットを活かすハイブリッド検索のプロトタイピングにも取り組んでいくとのことで、今後更に検索体験の向上に向けた取り組みを行っていくとのことです。 CTO の永井様からは “Amazon Bedrock と Amazon OpenSearch Service を利用することでよりユーザの意図に沿った検索結果を返すことができ、検索体験の改善につながる手応えがありました” とのコメントもいただいたいます。 他の RAG 実装アプローチについて コネヒト株式会社様は RAG を実装するために、既存のデータを埋め込みモデルを利用してベクトルデータに変換するアプローチを採用されました。 それ以外にも、AWS では RAG を実装する方法がいくつかございますので、その整理をしてこの記事を結びたいと思います。 今回は2番の方法に該当しますが、Amazon OpenSearch Service 以外にも Amazon RDS for PostgreSQL や Amazon Aurora (PostgreSQL 互換) をデータストアに使うこともできます。1、 3、4番のように検索サービスやマネージドのレベルが高い Amazon Kendra や ナレッジベース 、 Amazon Q Business という仕組みを活用していく手段も用意されており、データやドキュメントを用意するだけで RAG 環境を構築することが可能な方法もあります。(Amazon Q Business は 2024 年 5 月執筆時点で日本語に未対応です。) プロダクトの検索体験向上にご興味があり、どの方法が良いかわからない場合は、ご支援させていただきます。担当営業までお気軽にお問い合わせください。 まとめ 今回は既存の OpenSearch 上のデータと生成 AI を組み合わせることで、利用者の検索体験向の向上を目指したお客様の挑戦についてご紹介いたしました。 全文検索の仕組みだけでなく、新たなユーザーの検索体験につながる結果も得られており、今後の生成 AI 活用も期待ができると思われます。 また、今回のようなベクトル DB を構築する以外にも AWS 上で RAG を構築する方法が複数ある点についても触れさせていただきました。 構築方法でご不明な点があればお問い合わせいただければと思います。ぜひお試しください。 ソリューションアーキテクト 瀬高 拓也 (X – @stktky )

概要 これは、AWS の SAP 環境における End-to-End 監視の概要に関するブログシリーズの第 2 回目です。 第 1 回は こちら をご覧ください。 ネットワークのパフォーマンスは、通常、企業のビジネスプロセスを実行する SAP のようなエンタープライズアプリケーションにとって重要です。SAP ブログ “ SAP Netweaver ABAP のネットワークパフォーマンス分析 ” では、SAP の 3 層ソフトウェアアーキテクチャ (つまり、プレゼンテーション層、アプリケーション層、データベース層) が、プロトコルと API の組み合わせを使用して相互に通信する方法について説明されています。 ネットワークのパフォーマンスが遅いと、データの処理に大幅な遅延が生じ、ユーザーへのレスポンスタイムも遅くなります。ネットワークトラフィックの混雑により、パケットロスが発生し、階層間の通信が完全に失敗する可能性があります。これにより、データの損失や破損が発生し、SAP アプリケーションとそのユーザーに深刻な影響を及ぼす可能性があります。一般的に高速なデータベースの応答時間は 100 マイクロ秒程度ですが、ネットワークの応答時間は約 300 マイクロ秒となります。つまり、ネットワーク時間が応答時間全体の 75 % を占めることになります。 AWS クラウド内で SAP のネットワークパフォーマンスを最適化および監視する方法について説明します。まず、SAP サーバ間のネットワークパフォーマンスから始めましょう (図 1 の赤い枠線の部分)。 SAP サーバ間のネットワークパフォーマンス SAP はクライアントとサーバーのエンタープライズアプリケーションで、ユーザーが日々の業務を実行するためにログインする SAP アプリケーションサーバーと、SAP データを格納するデータベースなど、複数のコンポーネントで構成されています。 以下の図は、顧客のネットワーク (オンプレミス) の SAP ユーザーが、サイト間 VPN や AWS Direct Connect と呼ばれる専用リンクなどの WAN (広域ネットワーク) 接続を通して、AWS Cloud 上で実行されている SAP アプリケーションにアクセスする様子を示しています。 図 1 : AWS クラウドで実行されている SAP アプリケーションへのオンプレミス接続を示すアーキテクチャ図 ミッションクリティカルワークロード向けの AWS グローバルインフラストラクチャ はじめに、 AWS のグローバルインフラストラクチャ について理解しましょう。 AWS には、リージョンという概念があります。リージョンとは、データセンターを集約させた世界中の物理的な場所を指します。 論理的なデータセンターのグループを Availability Zone (AZ) と呼びます。 各 AWS リージョンは、地理的な区域内に最低 3 つの、独立した、物理的に分離された AZ で構成されています。 他のクラウドプロバイダーが 1 つのデータセンターを 1 つのリージョンとして定義することが多いのとは異なり、すべての AWS リージョンにはマルチ AZ 設計が備わっており、お客様に優れた利点があります。各 AZ には、独自の電源、冷却システム、物理的セキュリティが備わっており、冗長化された超低レイテンシーのネットワークで接続されています。ワークロードが AZ 間で分割されている場合、お客様はさまざまな問題 (停電、落雷、トルネード、地震など) から保護され、より高い絶縁性が確保されます。AZ は互いに数キロメートル離れた場所にあり、距離の上で十分に分離されていますが、それでもすべての AZ が 100 km 以内にあります。高可用性を求める AWS のお客様は、さらに高い耐障害性を備えるため、複数の AZ 上で実行されるようにアプリケーションを設計することができます。その上、AWS インフラストラクチャの各リージョンは、セキュリティ、コンプライアンス、データ保護に関する最高レベルの要件を満たしています。 AWS のリージョンとアベイラビリティーゾーンのモデルは、 Gartner から高可用性が必要なエンタープライズアプリケーションを実行するための推奨アプローチとして認められています。 SAP のネットワークレイテンシ要件 最適なパフォーマンスを得るために、SAP はネットワークに関する推奨事項を示しています。 SAP アプリケーションサーバーとデータベースサーバー間のネットワーク レイテンシは、 SAP Note 1100926 で示されているとおり、0.7 ミリ秒 (ms) 未満である必要があります。 データロスゼロ (セロ) を実現するために必要な、データの同期レプリケーションによる HANA システムレプリケーションのネットワーク レイテンシは、 1 ms 未満 である必要があります。 SAP は、ローカルの SAP システムで使用されているネットワーク インフラストラクチャの健全性を測定するツールとして、 NIPING を提供しています。 NIPING はクライアント/サーバー ツールとして実行され、ネットワーク レイテンシと帯域幅を測定するために使用できます。 上記を踏まえて、AWS の北バージニア リージョン (us-east-1) の 6 つの AZ 間 (AZ 間) および同じ AZ 内 (AZ 内) のネットワークレイテンシを見てみましょう。 各 AZ に 1 つずつ、計 6 つの EC2 インスタンスを作成し、NIPING を使ってテストを実行します。AZ1 をベースラインとします。 図 2 : NIPING を使用したネットワーク待ち時間の測定に使用した EC2 インスタンス NIPING の結果は、AZ1 から AZ2-AZ6 までの AZ 間のネットワーク遅延を 0.7 ms の閾値に対して相対的に示しています。 AZ1 内の AZ 内ネットワーク遅延も 0.7ms の閾値を下回っています。 図 3 : AWS バージニア北部リージョン (us-east-1) における NIPING を使用したネットワーク待ち時間 ( 2023 年 7 月 ) 上記のように、NIPING ツールを使用すると、AZ 間および AZ 内のネットワーク遅延を監視および測定できます。ただし、EC2 インスタンスを複数実行する必要があります。そこで、AWS Network Manager を使用すれば、この測定の代替手段となります。 AWS Network Manager – Infrastructure Performance AWS Network Manager は、AWS でのネットワーク管理と監視を助けるツールと機能を提供します。 Network Manager は、接続管理、ネットワーク監視とトラブルシューティング、IP 管理、ネットワークセキュリティとガバナンスを簡単に行えるようにします。 特に、 AWS Network Manager – Infrastructure Performance に注目したいと思います。 インフラストラクチャパフォーマンスを使用すると、ほぼリアルタイムと過去 45 日間の AWS リージョン間、AZ 間、または AZ 内の AWS グローバルネットワークパフォーマンスを、指定された期間のネットワーク待ち時間で監視できます。 ネットワーク待ち時間を最大 5 分間隔で監視でき、過去 45 日間のトレンドも確認できます。 さらに、これらの待ち時間メトリクスを Amazon CloudWatch に公開し、さらなる監視、分析、アラートを行うこともできます。 これにより、ネットワークのパフォーマンスが SAP やその他の実行中のアプリケーションに影響を与えるかどうかを容易に評価できます。 インフラストラクチャパフォーマンスの利用は無償であり、EC2 インスタンスのプロビジョニングも必要ありません。 AWS の北バージニア (us-east-1) リージョンを使用し、アベイラビリティーゾーン (AZ) 間 (Inter-AZ) および同一 AZ 内 (Intra-AZ) のネットワーク遅延を分析してみましょう。 AWS コンソールから Network Manager を選択し、Infrastructure Performance を選択してください: 図 4 : AWS Network Manager – Infrastructure Performance サービス ネットワーク遅延監視をセットアップするのは簡単で手軽です。「Inter-Availability Zone」を選択し、以下の例では AZ1 を基準として、他の 5 つのアベイラビリティーゾーンを選択します。 図 5 : Inter-Availability Zoneと監視対象の各 us-east-1 AZ の選択 次に、適切な期間 (この例では 1 週間) と監視間隔 (5 分) を選択します。 : 図 6 : 監視期間の選択 AZ1 (use1-az1) から他の 5 つのアビリティーゾーンへの AZ 間レイテンシーは、上記の NIPING の結果と一致しています: 図 7 : AZ 間ネットワークレイテンシモニタリング 同様に、6 つのすべての Availability Zone 内で Intra-AZ ネットワーク待ち時間のテストを繰り返し、平均ネットワーク待ち時間が 0.3 ms 未満であり、0.7 ms の閾値をはるかに下回っていることを示しています。 図 8 : AZ 間ネットワークレイテンシモニタリング 上の例では、AZ1 をベースラインとして使用しました。AZ2 をベースラインとして、その後 AZ3 などと、他の AZ ペア間で上記の遅延テストを繰り返し、推奨事項を満たす AZ を特定してください。 リージョン間のネットワークレイテンシについてはどうでしょうか? AWS バージニア北部リージョン (us-east-1) と他の米国内の AWS リージョン、オハイオ (us-east-2)、北カリフォルニア (us-west-1)、オレゴン (us-west-2) とを比較してみましょう。 図 9 : リージョン間ネットワークレイテンシモニタリング この場合、地理的な距離が短いため、us-east-1 (バージニア北部) と us-east-2 (オハイオ) 間のネットワーク遅延が最も低いことが観測されます。 Amazon CloudWatch による AZ レイテンシのモニタリング 以下の手順に従って、「AggregateAWSNetworkPerformance」CloudWatch メトリクスをサブスクライブし、AZ 間の待ち時間監視用のダッシュボードを作成してください。 CloudWatch ダッシュボードの作成 ネットワーク待ち時間が特定のしきい値を超えた場合に、アラートも作成して送信できます。AWS Network Manager – Infrastructure Performance は無料でご利用いただけますが、CloudWatch 監視には料金がかかります。料金については Amazon CloudWatch 料金 をご確認ください。 図 10 : AZ 間モニタリング用の CloudWatch ダッシュボード Infrastructure Performance では、トランジットゲートウェイ、NAT ゲートウェイ、VPC エンドポイント、Elastic Load Balancing、Amazon EC2 ネットワークインターフェイスなど、VPC ネットワーキングリソースを通過するパスのパフォーマンス指標は考慮されません。 また、SAP アプリケーション/オペレーティングシステム/データベースのオーバーヘッドの影響があるため、SAP アプリケーションから観測されるネットワークレイテンシーも Infrastructure Performance では考慮されません。 詳しくは、 AWS ドキュメント の Infrastructure Performance に関する説明をご確認ください。 信頼性と可用性を考慮した SAP の設計 複数のサーバー (つまり、複数の SAP アプリケーションサーバー、SAP Web ディスパッチャー) がある場合、信頼性と可用性を高めるため、これらのサーバーを可用性ゾーン間で分散することをお勧めします。これにより、追加のネットワーク待ち時間の影響を上回ります。 SAP を高可用性で設計する場合 (つまり、データベースの複製を行う場合)、最適なパフォーマンスを確保するには、ネットワーク待ち時間が他より短いアベイラビリティーゾーンのペアを選択してください。ネットワーク待ち時間は時間の経過とともに変化し、リージョンとアビラビリティーゾーンのペアによっても異なることに注意してください。 パフォーマンス要件が極めて高いバッチジョブの場合は、データベースサーバーと同じアベイラビリティーゾーン内の SAP Application Server で実行するようにスケジュールすることをお勧めします。 クロスリージョン災害復旧 (DR) の要件がある場合、AWS リージョン間のネットワークレイテンシーと対応する地理的距離を考慮して、DR の二次リージョンを決めてください。 詳細については、 SAP Lens AWS ウェルアーキテクトフレームワーク ドキュメント を参照してください。 RISE with SAP では、AWS は、すべての AWS リージョンで Short-Range DR と Long-Range DR の両方をサポートする初めての クラウドプロバイダーです。Short-Range DR は 1 つのリージョン内の 2 つの AZ 間での DR を提供し、Recovery Point Objective (RPO) はゼロ、つまりデータロスはありません。これは、地理的に離れた AZ 間の高速で低レイテンシのネットワーク リンクによるシンクロナスなデータレプリケーションをサポートする AWS のマルチ AZ インフラストラクチャに対する SAP の確信の証しです。 長距離 DR とは、2 つの AWS リージョン間でのディザスタリカバリであり、RPO は 30 分です。お客様は、DR オプションを選択するか、短距離 DR と長距離 DR の両方を SAP RISE の構成の一部として組み合わせることができます。 オンプレミスユーザーと AWS Cloud 間のネットワークパフォーマンス 図 11 : オンプレミスと AWS 間の WAN 接続 オンプレミスと AWS Cloud 間の WAN 接続は、顧客が SAP システムにアクセスできることを確保する上で重要です。 WAN 接続の信頼性、可用性、パフォーマンスを維持するには、監視が重要な部分を占めます。 Amazon CloudWatch は、サイト間 VPN 接続と AWS Direct Connect の両方の監視を提供します。サイト間 VPN の場合、少なくとも VPN トンネルの状態、送受信されたデータ量を監視することをおすすめします。使用可能な監視指標の詳細は、AWS ドキュメント サイト間 VPN 接続の監視 と CloudWatch での Direct Connect の監視 を参照してください。 RISE with SAP SAP RISE on AWS を実行している場合、ユーザーを AWS Cloud に接続するための WAN 接続が必要になります。この場合、次の図のように、あなたの AWS アカウントと SAP RISE によって管理される AWS アカウントを AWS Transit Gateway で接続できます。詳細とその他の接続オプションについては、AWS ドキュメント SAP RISE on AWS Connectivity を参照してください。 図 12 : AWS 上の SAP RISE 顧客のための WAN 接続例 AWS グローバルアクセラレータによるネットワークレイテンシの削減 地理的に分散したリモートユーザーが SAP システムにアクセスしようとする場合はどうでしょうか。例えば、ヨーロッパのユーザーがインターネットを介して AWS シンガポールリージョンの SAP システムにアクセスすると、ネットワークのパフォーマンスが予測できず、ユーザー体験が低下する可能性があります。 1 つの選択肢は、 AWS Global Accelerator を利用することです。AWS Global Accelerator は、トラフィックを AWS のグローバルネットワークバックボーンを通すことで、アプリケーションの可用性とパフォーマンスを向上させます。ユーザーが AWS Global Accelerator に接続すると、トラフィックは自動的にネットワークレイテンシーが最も低い最適な AWS エンドポイントにルーティングされます。さらに、 Accelerated Site-to-Site VPN を利用することで、AWS Global Accelerator も使用しながらデータを暗号化することができ、ユーザーに対して最適なセキュリティとネットワークパフォーマンスを提供することができます。 図 13 : AWS アクセラレーテッドサイト間 VPN 経由で SAP にアクセスするリモートユーザー リモートの SAP ユーザーに AWS Global Accelerator が有益かどうかを判断するには、 AWS Global Accelerator Speed Comparison ツールを使用して様々な AWS リージョンへのネットワーク待ち時間を測定できます。このツールを SAP ユーザーの場所で実行すると、AWS Global Accelerator がネットワークトラフィックを最も近い AWS エンドポイントに向けるため、既存のインターネット接続と待ち時間を比較できます。複数回テストを実行すると結果が異なる場合があることに注意してください。ダウンロード時間は、お使いの最終回線ネットワークの品質、容量、距離など、Global Accelerator 以外の要因によって変動する可能性があります。 図 14: AWS Global Accelerator を使用した場合と使用しない場合のネットワーク遅延の比較 Amazon CloudFront を使用した SAP Fiori のパフォーマンスの向上 Amazon CloudFront は、コンテンツ配信ネットワークサービスで、SAP Fiori などの Web コンテンツを、エッジロケーションのグローバルネットワーク全体にキャッシュすることで低遅延と高速の転送が可能です。CloudFront にキャッシュされた SAP Fiori のコンテンツをユーザーがリクエストすると、CloudFront はリクエストを最も近いエッジロケーションにルーティングし、そこからコンテンツを直接ユーザーに配信します。これにより遅延が減り、ユーザーエクスペリエンスが向上します。 SAP Fiori を使用したグローバルな SAP システムを運用し、地理的に分散したユーザーが利用している場合は、Amazon CloudFront を利用するメリットがあります。 AWS Global Accelerator と Amazon CloudFront の詳細な比較については、この AWS ブログ を参照してください。 結論 ネットワークのパフォーマンスチューニングと監視は、時間のかかる作業です。AWS Network Manager – Infrastructure Performance を使えば、リージョン間、アベイラビリティーゾーン内外を問わず、AWS のグローバルインフラストラクチャのネットワーク待ち時間を簡単に監視できます。 この情報を使うことで、AWS Cloud 上で SAP アプリケーションの最大のネットワークパフォーマンスを引き出すための最適な配置を決められ、ミッションクリティカルな SAP ワークロードを継続的に監視し、問題が発生したときにはトラブルシューティングが行えます。 Amazon CloudWatch を使うと、SAP にとって重要なネットワーク コンポーネントを単一の観点から監視できます。 AWS Network Manager と Amazon CloudWatch を組み合わせると、AZ 間、AZ 内のネットワーク レイテンシーと、お客様のネットワークから AWS クラウドへの WAN 接続を監視できます。 AWS Cloud へのエンドユーザー接続を改善するため、AWS Global Accelerator または Amazon CloudFront を検討できます。 前者はルーティング機能により、後者はキャッシュ機構により、それぞれアプリケーションの可用性とパフォーマンスを改善します。 AWS 製品ドキュメント https://docs.aws.amazon.com/index.html から、 AWS 上の SAP 、 Network Manager – Infrastructure Performance 、 Amazon CloudWatch 、 AWS Global Accelerator 、 Amazon CloudFront の詳細を確認できます。 クレジット Derek Ewell と Spencer Martenson のブログへの貢献に感謝いたします。 翻訳はPartner SA 松本が担当しました。原文は こちら です。

本記事は 2023/09/11に投稿された Introducing the Advanced JDBC Wrapper Driver for Amazon Aurora を翻訳した記事です。 翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。 現代のモダンアプリケーションには、スケーラビリティと耐障害性が求められています。その中でも最も重要なのがスケーラビリティで、アプリケーションの規模によっては、数百万人のユーザーにオンデマンドで対応できる能力が必要とされます。 e コマース、金融サービス、ゲームなどのステートフルアプリケーションでは、高可用性のデータベースが不可欠です。 2015年の Amazon Aurora リリース以降、お客様は Aurora クラスターでリレーショナルデータベースを実行できるようになりました。このクラスターは1つのライターノードと最大15個の低レイテンシーなリーダーノードで構成されています。これにより、アプリケーションは読み取りを大幅にスケーリングできるようになりました。 しかし、マルチインスタンスをサポートするデータベースと同様に、開発者は特別なイベントに対処するため、スイッチオーバーやフェイルオーバーなどの複雑なアプリケーションロジックを構築する必要がありました。 複雑なエンドポイントロジックをアプリケーションに実装する代わりに、スイッチオーバーやフェイルオーバーなどを処理する機能が、 Advanced JDBC (Java Database Connectivity) Wrapper Driver に用意されています。さらに、このドライバーは AWS Secrets Manager または AWS Identity and Access Management (IAM) を使った認証処理も統合しています。 Advanced JDBC Wrapper Driver は Apache 2.0 ライセンスのオープンソースプロジェクトとしてリリースされています。プロジェクトの詳細は GitHub で確認できます。 この記事では、Advanced JDBC Wrapper Driver のいくつかの機能の使い方について詳しく説明します。 Advanced JDBC Wrapper Driver の機能 Advanced JDBC Wrapper Driver は、ネイティブの PostgreSQL または MySQL の JDBC ドライバーを”ラップ”し、基盤となるドライバーへの関数呼び出しの前にフェイルオーバーと認証の機能を追加します。API の実行にネイティブドライバーを使用することで、コードの複雑さを減らし、機能追加に集中できます。 Aurora は単一インスタンスではなく、DB インスタンスのクラスターを提供します。各接続は特定の DB インスタンスによって処理されます。Aurora クラスターに接続する際、指定するホスト名とポートは、エンドポイントと呼ばれる仲介ハンドラーを指します。Aurora はこのエンドポイント機構を使ってこれらの接続を抽象化しています。 以下のセクションでは、このドライバーが軽減するいくつかの課題について説明します。 スイッチオーバー スイッチオーバーとは、リーダーがライターに昇格することを指します。これは、ライターの設定変更によりライターが再起動する必要がある場合に発生します。 クライアントには、クラスターのライターエンドポイントまたはリーダーエンドポイントに接続するオプションがあります。通常はライターエンドポイントに接続します。このエンドポイントは現在のライターインスタンスを指しています。クラスターのパラメーター変更やフェイルオーバーによりクラスターが再起動すると、リーダーの1つが新しいライターに昇格します。この際、クラスターライターエンドポイントが更新され、DNS でインスタンスエンドポイントが新しいライターを指すよう変更されます。DNS の伝播に時間がかかるため、この変更に最大30秒かかる可能性があります。通常、アプリケーションにはデータベースが一時的に利用できなくなった後の再接続ロジックが必要です。Advanced JDBC Wrapper Driver には、自動的に検出して接続を新しいライターに切り替える機能が組み込まれています。Aurora データベース内のトポロジー情報を利用することで、ドライバーは約6秒で切り替えを行えます。 IAM との統合 IAM を使うと、AWS でどのユーザがサービスとリソースにアクセスできるかを管理し、細かいアクセス許可を一元管理でき、AWS 全体のアクセスを分析して許可を最適化できます。IAM はトークン(パスワード)を自動的に定期的に変更することで、セキュリティを強化します。 アプリケーション内で IAM トークンの取得と使用のロジックを記述することも全く問題ありませんが、トークンの取得とキャッシングを扱う必要があるためアプリケーションが複雑になります。このドライバーにはその機能が組み込まれているので、スイッチオーバー時でも、アプリケーションはこれらの複雑さを考慮する必要がありません。IAM ポリシーの作成と、IAM データベースアクセス用の使い方の詳細については、「 IAM データベースアクセス用の IAM ポリシーの作成と使用 」を参照してください。 Secrets Manager との統合 Secrets Manager を使えば、資格情報をまとめて保存・管理できます。資格情報を管理することで、セキュリティ要件に応じて定期的に資格情報を更新(ローテーション)できます。Secrets Manager には、接続認証に使うユーザー名とパスワードを保存できます。この機能を有効にすると、ドライバーは Secrets Manager から資格情報を取得し、接続認証に使用します。 ソリューションの概要 Advanced JDBC Wrapper を使わない場合、データベースに接続してクエリを実行する典型的な Java コードは以下のようになります。 while(true) { try (Connection connection = DriverManager.getConnection(DB_URL, DB_USERNAME, DB_PASSWORD)) { try (PreparedStatement preparedStatement = connection.prepareStatement("SELECT SUM(a) FROM IntegerOverflowTest;")) { try (ResultSet resultSet = preparedStatement.executeQuery()) { resultSet.next(); long l = resultSet.getLong(1); System.out.println("sum(a) -> " + l); } }catch (SQLException ex){ /* * catch exceptions relative to the select and handle them  * if the exception is connection closed then reconnect and try again */ } }catch (SQLException ex){ /* * catch and handle connection errors here */ } スイッチオーバーが原因で接続に失敗した場合、新しいライターがオンラインになるまで接続は失敗します。Advanced JDBC Wrapper Driver を使わない場合、DNS の伝播を待つ必要があり、アプリケーションはおよそ30秒間ライターに接続できなくなります。 一方、Advanced JDBC Wrapper Driver を使えば、再接続を自動で試みます。初期接続時に、ドライバーはクラスターのトポロジーを読み取り、インスタンスエンドポイントを取得します。そのため、接続が失敗した場合でも、ドライバーはクラスター内の全インスタンスの IP アドレスを認識しています。ユーザーアプリケーションで接続が失敗すると、ドライバーはインスタンスをポーリングし、接続を試みます。接続が確立されると、新しいトポロジーを読み取り、新しいライターの IP アドレスを取得して接続します。この一連の処理がドライバー内で行われるため、ユーザーアプリケーションは接続の切断や失敗を認識することはありません。ドライバーは例外をスローし、接続が新しいサーバーに切り替わったことをユーザーアプリケーションに通知します。処理中のトランザクションで障害が発生した場合、トランザクションは失敗し、リトライする必要がある事を示す例外がユーザアプリケーションに投げられます。その為、ユーザーアプリケーションではこの例外を適切に特定し、処理するための小さな変更が必要になります。 接続 URL は、PostgreSQL JDBC ドライバーの場合は jdbc:aws-wrapper:postgresql: 、MySQL JDBC ドライバーの場合は jdbc:aws-wrapper:mysql: となります。Advanced JDBC Wrapper Driver は jdbc:aws-wrapper で始まる部分を受け取り、次の部分からラップする基盤ドライバーを判別します。 以下のコードは、Aurora PostgreSQL クラスターに接続し、フェイルオーバーを設定する方法を示しています。 properties.setProperty(PropertyDefinition.PLUGINS.name, "auroraConnectionTracker,failover,efm"); while( true ) { try (Connection connection = DriverManager.getConnection("jdbc:aws-wrapper:postgresql://" + WRITER + "/read_db", properties)) { try (Statement statement = connection.createStatement()) { try (ResultSet rs = statement.executeQuery("select 1")) { while (rs.next()) ; } } catch (FailoverSuccessSQLException ex) { /* we can safely ignore this error the connection was re-established create the statement again and execute the query. */ } catch (TransactionStateUnknownSQLException ex) { // ignore this as well since we aren't really in a transaction } } catch (FailoverFailedSQLException ex) { /* At this point the driver was unable to re-establish the connection so just loop and get a new connection. */ } catch (SQLException ex) { /* any number of exceptions above, handle as normal */ } try { Thread.sleep(1000); } catch (InterruptedException e) { //ignore } } インスタンスエンドポイントを使って新しいライターを探索し、通常はドライバーが障害を検知してから約6秒で再接続できます。DNS キャッシュを待つ必要がないので、はるかに高速な再接続が可能になっています。 前提条件 Advanced JDBC Wrapper Driver は、 Java Proxy Pattern を利用して実装されています。つまり、ネイティブの PostgreSQL または MySQL ドライバーを依存関係として追加する必要があります。 Advanced JDBC Wrapper Driver を使用するアプリケーションの作成 次のセクションでは、Advanced JDBC Wrapper Driver を使用するアプリケーションを作成するための手順を説明します。 Maven の依存関係追加 Maven を使ってビルドする場合は、pom.xml ファイルに以下の Maven の依存関係を追加してください。 <dependency> <groupId>org.postgresql</groupId> <artifactId>postgresql</artifactId> <version>42.6.0</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.31</version </dependency <dependency> <groupId>software.amazon.jdbc</groupId> <artifactId>aws-advanced-jdbc-driver</artifactId> <version>2.2.3</version> </dependency> IAM プラグインを使用したい場合は、以下も追加する必要があります。 <dependency>     <groupId>software.amazon.awssdk</groupId>     <artifactId>rds</artifactId>     <version>2.20.49</version> </dependency> Secrets Manager プラグインを使用したい場合は、以下も追加してください。 <dependency>     <groupId>software.amazon.awssdk</groupId>     <artifactId>secretsmanager</artifactId>     <version>2.20.88</version>     </dependency> <dependency>     <groupId>com.fasterxml.jackson.core</groupId>     <artifactId>jackson-databind</artifactId>     <version>2.15.2</version>     </dependency> コードを更新する 正しい依存関係を追加した後、Advanced JDBC Wrapper Driver を使うためにアプリケーションにいくつかの変更が必要です。 接続 URL は、PostgreSQL の場合は jdbc:aws-wrapper:postgresql 、MySQL の場合は jdbc:aws-wrapper:mysql にする必要があります。URLの最初の部分で AWS Advanced JDBC Wrapper がロードされ、2番目の部分でどの基盤ドライバーをロードしてプロキシ(Java Proxy Pattern)するかを指示します。 ドライバー機能を指定する 使用したいドライバーの機能を決定します。Advanced JDBC Wrapper Driver はプラグインを使って JDBC メソッドを実行します。プラグインは、JDBC メソッド呼び出しの前後に追加のロジックを加えるための拡張可能なコードモジュールと考えられます。Advanced JDBC Wrapper Driver には、いくつかの組み込みプラグインがあります。これは、 wrapperPlugins ドライバープロパティで設定します。詳細は「 Connection Plugin Manager Parameters 」を参照してください。デフォルト設定は auroraConnectionTracker,failover,efm です。 auroraConnectionTracker プラグインは、フェイルオーバー発生時に障害ノードへのオープン接続をすべて閉じるようにします。failover プラグインは、実際のフェイルオーバーの検知と再接続を処理します。efm プラグインは、フェイルオーバー時の再接続時間を減らすため、積極的にホストを監視します。 Secrets Manager との統合 AWS には Secrets Manager というサービスがあり、秘密情報を安全に保存できます。Advanced JDBC Wrapper Driver にはプラグインが用意されており、ユーザー名とパスワードの値を Secret に保存し、認証時に USER と PASSWORD の値として取得することができます。 必要な設定は、 REGION_PROPERTY 、 SECRET_ID_PROPERTY 、 PLUGINS の3つのプロパティのみです。 以下のコードブロックが例となります: public static void main(String[] args) throws SQLException {     /* Set the AWS Secrets Manager Connection Plugin parameters and     the JDBC Wrapper parameters.     */     final Properties properties = new Properties();     REGION_PROPERTY.set(properties, "us-east-2");     SECRET_ID_PROPERTY.set(properties, "secretId");     // Enable the AWS Secrets Manager Connection Plugin.     PLUGINS.set(properties, "awsSecretsManager");     // Try and make a connection:     try (final Connection conn = DriverManager.getConnection(CONNECTION_STRING, properties);          final Statement statement = conn.createStatement();          final ResultSet rs = statement.executeQuery("SELECT * FROM employees")) {       while(rs.next()){         System.out.println(rs.getString()...);       }     }   } IAM 認証の統合 Advanced JDBC Wrapper Driver は、 IAM 認証 をサポートしています。IAM データベース認証を使用する場合、ホスト URL はカスタムドメインや IP アドレスではなく、有効な Amazon エンドポイントでなければなりません。例: db-identifier.cluster-XYZ.us-east-2.rds.amazonaws.com IAM 認証には AWS Java SDK RDS v2.x が CLASSPATH に別途含まれる必要があります。AWS Java SDK RDS はランタイム依存関係であり、解決されなければなりません。AWS SDK を使う場合は、 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY を設定して認証する必要があります。 IAM データベース認証は、特定のデータベースエンジンに限定されています。制限事項と推奨事項の詳細については、「 MariaDB、MySQL、および PostgreSQL の IAM データベース認証 」を参照してください。 IAM 認証の設定 IAM 認証を設定するには、以下の手順を実行します。 Amazon RDS コンソールで、 既存のデータベース もしくは 新規作成のデータベース に対して IAM データベース認証を有効化 します。 IAM データベース認証用の IAM ポリシーを設定します。 IAM データベース認証を使ってデータベースアカウントを作成します。選択したプライマリ DB インスタンスに接続します。 MySQL データベースの場合、以下のコマンドで新しいユーザーを作成します。 CREATE USER example_user_name IDENTIFIED WITH AWSAuthenticationPlugin AS 'RDS'; PostgreSQL データベースの場合、以下のコマンドで新しいユーザーを作成します。 CREATE USER db_userx; GRANT rds_iam TO db_userx; Advanced JDBC Wrapper Driver で IAM 認証を使うには Advanced JDBC Wrapper Driver で IAM 認証を使う場合のサンプルコードは次の通りです: public class AwsIamAuthenticationPostgresqlExample {   public static final String POSTGRESQL_CONNECTION_STRING =       "jdbc:aws-wrapper:postgresql://db-identifier.XYZ.us-east-2.rds.amazonaws.com:5432/employees";   private static final String USERNAME = "john_smith";   public static void main(String[] args) throws SQLException {     final Properties properties = new Properties();     // Enable AWS IAM database authentication and configure driver property values     properties.setProperty(PropertyDefinition.PLUGINS.name, "iam");     properties.setProperty(PropertyDefinition.USER.name, USERNAME);     // Attempt a connection     try (Connection conn = DriverManager.getConnection(POSTGRESQL_CONNECTION_STRING,     properties);         Statement statement = conn.createStatement();         ResultSet result = statement.                     executeQuery("select aurora_db_instance_identifier()")) {       System.out.println(Util.getResult(result));     }   } } クリーンアップ この記事を通して作成した Aurora クラスターの IAM 認証情報、Secrets Manager の認証情報がある場合は、必ず削除するようにしてください。 まとめ Advanced JDBC Wrapper Driver は、AWS の IAM や Secrets Manager と Aurora が提供するクラスター構成を利用して、認証とフェイルオーバーのソリューションを実現しています。さらに、Aurora の機能を活用することで、フェイルオーバー時間を大幅に短縮できます。このドライバーにはまだ多くの機能があり、今後の投稿で紹介していく予定です。続報をお待ちください！ それまでの間、この投稿に対するコメントをお寄せいただき、 GitHub プロジェクト を訪れて詳細と例を確認してください。 著者について Dave Cramer はAmazon Web Services のシニアソフトウェアエンジニアです。また、PostgreSQL JDBC ドライバのメンテナーとして、PostgreSQL の主要な貢献者でもあります。彼の情熱はクライアントインターフェースとクライアントとの連携にあります。

5月20日週、 Amazon Web Services (AWS) の VP for AI Products である Matt Wood 博士が、ロサンゼルスの AWS Summit で基調講演を行いました。Matt とゲストスピーカーは、生成 AI、開発者ツール、基盤となるインフラストラクチャにおける最新の進歩について話し、これらが一体となってビルダーが実現できる事柄を変えていく方法を紹介しました。 この基調講演は YouTube で視聴 できます。 LA Summit での発表には、2025 年までに世界中の 200 万人に無料の AI スキルトレーニングを提供するという Amazon’s AI Ready イニシアティブ の一環としての 2 つの新しい Amazon Q  コースが含まれていました。これらのコースは Amazon Q 学習プラン の一部になっています。しかし、5月20日週の出来事はこれだけではありません。 5月20日週のリリース 私が注目したいくつかのリリースをご紹介します。 LlamaIndex による Amazon Neptune のサポート – Amazon Neptune に保存されたナレッジグラフと、 Amazon Bedrock で利用できる大規模言語モデル (LLM) のような LLM を使用してアプリケーションを構築するための人気のオープンソースフレームワークである LlamaIndex を組み合わせることで、Graph Retrieval Augmented Generation (GraphRAG) アプリケーションを構築できるようになりました。詳細については、 Amazon Neptune Graph Store に関する LlamaIndex ドキュメント をお読みください。 AWS CloudFormation が DeleteStack API 向けに DeletionMode と呼ばれる新しいパラメータをローンチ – スタックとスタックリソースの削除には、 AWS CloudFormation DeleteStack API を使用することができます。しかし、空ではない Amazon Simple Storage Service (Amazon S3) バケットを削除しようとするときなど、特定のスタックリソースが原因で DeleteStack API が正常に完了しない場合があります。このようなシナリオでは、DeleteStack API が DELETE_FAILED 状態になる可能性があります。このローンチにより、新しい DeletionMode パラメータに FORCE_DELETE_STACK 値を渡して、こういったスタックを削除できるようになりました。詳細については、 DeleteStack API ドキュメント をお読みください。 Amazon Bedrock での Mistral Small の提供開始 – Amazon Bedrock で Mistral AI からの Mistral Small 基盤モデル (FM) の一般提供が開始されました。これは、最近行われた 3 月の Mistral 7B と Mixtral 8x7B、4 月の Mistral Large の発表に続くものです。Mistral AI が開発した Mistral Small は、大規模かつ低レイテンシーの言語ベースのタスク向けに最適化された、きわめて効率的な大規模言語モデル (LLM) です。詳細については、 Esra の記事 をお読みください。 エジプト、カイロの新しい Amazon CloudFront エッジロケーション – この新しい AWS エッジロケーションにより、 Amazon CloudFront が提供するすべてのメリットを利用できるようになります。CloudFront は、低レイテンシーと優れたパフォーマンスで静的/動的コンテンツ、API、ライブ/オンデマンド動画を配信する、高度に分散されたセキュアでスケーラブルなコンテンツ配信ネットワーク (CDN) です。エジプトのお客様は、新しいエッジロケーションを通じて配信されるデータのレイテンシーが、平均で最大 30% 改善されることを期待できます。AWS エッジロケーションの詳細については、 CloudFront エッジロケーション をご覧ください。 Amazon S3 との Amazon OpenSearch Service ゼロ ETL 統合 – この Amazon OpenSearch Service 統合は、Amazon S3 データレイク内にある運用ログをクエリするための新しい効率的な方法を提供することで、データを分析するためにツールを切り替える必要をなくします。これは、Amazon VPC フローログ、AWS WAF ログ、Elastic Load Balancing (ELB) といった AWS ログタイプ向けの追加設定不要なダッシュボードをインストールすることで開始できます。詳細については、 Amazon OpenSearch Service 統合ページ と Amazon OpenSearch Service Developer Guide を参照してください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース こちらは、皆さんが興味を持つかと思われるその他のニュースと Twitch 番組です。 Build On Generative AI – twitch.tv/aws で、毎週木曜日の午後 2 時 (米国太平洋時間) に配信中です。私の同僚である Tiffany と Mike が生成 AI のさまざまな側面に関するディスカッションを行い、デモを紹介するゲストスピーカーをお招きします。 ショーノートとエピソードの完全なリストについては、community.aws をご覧ください 。 Amazon Bedrock Studio ブートストラッパスクリプト – 皆さんのフィードバックにお応えしました! Amazon Bedrock Studio の使用を開始するために必要な AWS Identity and Access Management (IAM) のロールとアクセス許可のセットアップで苦労したことがあるならば、これからは Bedrock Studio ブートストラッパスクリプト を使用して、アクセス許可の境界、サービスロール、プロビジョニングロールの作成を自動化できるようになります。 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summits – AWS Summit シーズンがやってきました! クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市でご登録ください。日程は、 ドバイ (5 月 29 日)、 バンコク (5 月 30 日)、 ストックホルム (6 月 4 日)、 マドリッド (6 月 5 日)、 ワシントン DC (6 月 26～27 日) です。 AWS re:Inforce – ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 10～12 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。セキュリティツールを構築している AWS チームとつながるとともに、AWS のお客様と交流して、それぞれのセキュリティジャーニーについて学びましょう。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ニュージーランド (8 月 15 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) です。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 5月27日週はここまでです。6月3日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

5月24日は、 Amazon Bedrock で Mistral AI からの Mistral Small 基盤モデル (FM) の一般提供が開始されたことをお知らせします。これは、最近行われた 3 月の Mistral 7B と Mixtral 8x7B 、4 月の Mistral Large の発表に続くものです。これからは、Amazon Bedrock で Mistral AI からの 4 つの高性能モデルである Mistral Small、Mistral Large、Mistral 7B、および Mixtral 8x7B にアクセスできるようになり、モデルの選択肢がさらに広がります。 Mistral AI が開発した Mistral Small は、大規模かつ低レイテンシーの言語ベースのタスク向けに最適化された、きわめて効率的な大規模言語モデル (LLM) です。Mistral Small は、分類、カスタマーサポート、テキスト生成など、一括で実行できる単純なタスクに最適です。このモデルは、コスト効率性に優れた価格で、非常に優れたパフォーマンスを提供します。 以下は、知っておく必要がある Mistral Small の主要機能です。 検索拡張生成 (RAG) 特化 – Mistral Small は、最大 32,000 トークンに拡張できるロングコンテキストウィンドウでさえも、重要な情報が保持されることを確実にします。 コーディング能力 – Mistral Small は優れたコード生成、レビュー、およびコメント能力を備えており、主要コーディング言語をサポートしています。 多言語機能 – Mistral Small は、英語に加えて、フランス語、ドイツ語、スペイン語、およびイタリア語でもトップクラスのパフォーマンスを提供します。これ以外にも、その他数多くの言語をサポートしています。 Mistral Small の使用開始方法 Mistral Small の使用を開始するには、まずこのモデルにアクセスする必要があります。 Amazon Bedrock コンソール に移動して、 [モデルアクセス] 、 [モデルアクセスを管理] の順に選択します。 [Mistral AI] セクションを展開し、 [Mistral Small] を選択してから、 [変更を保存] を選択します。 これで、Mistral Small モデルにアクセスし、Amazon Bedrock で使用を開始できるようになりました。 [ベースモデル] テーブルを更新して、現在のステータスを表示します。 以下のテンプレートを使用してモデルに対するプロンプトを構築し、準最適出力を取得します。 <s>[INST] Instruction [/INST] <s> は文字列の先頭 (BOS) に置く特別なトークンで、 [INST] と [/INST] は標準文字列であることに留意してください。 分類例を表示するために、以下のプロンプトを試してみます。 プロンプト: <s>[INST] Classify the following email to determine if it is spam or not.Only respond with the exact words "Spam" or "Not spam". 🎉 Limited time offer! Buy 2, Get 1 Free! Offer ends today! Don't miss out the CHANCE TO SAVE, please click on the link below: https://bit.ly/buy-2-get-1-free [/INST] Mistral 7B、Mixtral 8x7B、および Mistral Large はすべて、この E メールを「Spam」として分類します。 Mistral Small も、大規模なモデルと同様にこのメールを正確に分類できます。テキストプロンプトからの Bash スクリプトの生成、ヨーグルトを作るためのレシピの生成など、同じようなタスクをいくつか試してみましたが、これらからも良い結果が得られました。このため、こういったタスクには、Mistral Small が Amazon Bedrock 内の Mistral AI モデルの中で最も効率的でコスト効率性に優れたオプションになります。 Mistral Small は多言語タスクにも長けています。英語に加えて、フランス語、ドイツ語、スペイン語、イタリア語でも優れたパフォーマンスを発揮します。サステナビリティに関する文章を 2 つ提供するように依頼して、ドイツ語に対するモデルの理解度をテストします。 プロンプト: <s>[INST] Geben Sie mir zwei Sätze zum Thema Nachhaltigkeit. [/INST] 出力: 1.Nachhaltigkeit bedeutet, die Bedürfnisse der heutigen Generation zu befriedigen, ohne die Möglichkeiten künftiger Generationen zu gefährden. 2.Ein nachhaltiger Lebensstil umfasst den bewussten Umgang mit Ressourcen, wie Wasser, Energie und Rohstoffen, sowie den Schutz von Umwelt und Klima. Diese Sätze sollten Ihnen einen guten Überblick über das Thema Nachhaltigkeit geben. Mistral Small のプログラム的な操作 Amazon Bedrock API を用いて Mistral Small をプログラム的に操作するには、 AWS コマンドラインインターフェイス (AWS CLI) と AWS Software Development Kit (SDK) を使用できます。Python で以下のコードを使用します。このコードは、AWS SDK を使って Amazon Bedrock Runtime API を操作するもので、「空の色は何色ですか?」とたずねています。 import argparse import boto3 from botocore.exceptions import ClientError import json accept = "application/json" content_type = "application/json" def invoke_model(model_id, input_data, region, streaming): client = boto3.client('bedrock-runtime', region_name=region) try: if streaming: response = client.invoke_model_with_response_stream(body=input_data, modelId=model_id, accept=accept, contentType=content_type) else: response = client.invoke_model(body=input_data, modelId=model_id, accept=accept, contentType=content_type) status_code = response['ResponseMetadata']['HTTPStatusCode'] print(json.loads(response.get('body').read())) except ClientError as e: print(e) if __name__ == "__main__": parser = argparse.ArgumentParser(description="Bedrock Testing Tool") parser.add_argument("--prompt", type=str, help="prompt to use", default="Hello") parser.add_argument("--max-tokens", type=int, default=64) parser.add_argument("--streaming", choices=["true", "false"], help="whether to stream or not", default="false") args = parser.parse_args() streaming = False if args.streaming == "true": streaming = True input_data = json.dumps({ "prompt": f"<s>[INST]{args.prompt}[/INST]", "max_tokens": args.max_tokens }) invoke_model(model_id="mistral.mistral-small-2402-v1:0", input_data=input_data, region="us-east-1", streaming=streaming) すると、以下の出力が得られます。 {'outputs': [{'text': ' The color of the sky can vary depending on the time of day, weather,', 'stop_reason': 'length'}]} 今すぐご利用いただけます 現在、Mistral Small モデルは米国東部 (バージニア北部) リージョンの Amazon Bedrock でご利用いただけます。 詳細については、 Mistral AI in Amazon Bedrock 製品ページ をご覧ください。料金の詳細については、 Amazon Bedrock の料金ページ を参照してください。 Amazon Bedrock で Mistral Small の使用を開始するには、 Amazon Bedrock コンソール にアクセスし、「 Amazon Bedrock User Guide 」を参照してください。 — Esra 原文は こちら です。

はじめに 自動車アプリケーションをクラウドに接続して IoT (モノのインターネット)データを交換することで、自動車に多くの利点をもたらすことができます。安全に認証を行なった接続は、リアルタイムの診断や予防保全のためにクラウドに継続的な遠隔計測データを送信して車両の監視を行う OEM メーカーにとって不可欠です。ソフトウェア、インフォテイメント、マップなどの車載ナビゲーションサービスへの OTA アップデートを OEM が提供できると、車両を修理工場に持って来てもらわなくとも最新の状態に保つのに役立ちます。さらに、クラウドからリアルタイムの交通渋滞や駐車情報などのナビゲーションデータにアクセスすることで、利用者は最適な経路を選択でき、より良い運転体験を得られます。したがって、車載アプリとクラウド間で安全にデータを交換するメカニズムを持つことが、利用者と自動車 OEM の両方にとって重要です。 概要 このブログでは、IoT デバイスからデータを送受信するために、iOS アプリを AWS IoT Core に安全に接続する方法を紹介します。AWS IoT での認証方法はさまざまで、 AWSMobileClient と統合された AWS Cognito ユーザープール の利用や、 X.509 証明書の使用などが可能です。しかし、グローバルに展開されたユーザー数が多数になるアプリケーションの場合、これらの認証方式では現実的ではなくなる可能性があります。Cognito ユーザープールではユーザー毎のプロビジョニングが必要になるため、スケーラビリティの問題が生じるかもしれません。一方、X.509 証明書の場合は、大規模な環境でキーの配布と更新が課題となります。したがって、グローバルなアプリデプロイのためには、他の大規模展開に適した認証方式を評価する必要があります。 従来、車両モジュールでは Bluetooth Low Energy (BLE) を使用してモバイルアプリにテレメトリデータを送信していました。ここから、テレメトリデータの分析のためにクラウドハイパースケーラーに安全に接続する必要があります。これは、 AWS IoT SDK for iOS を使用して実現できます。この SDK には、iOS アプリから AWS IoT Core と簡単に対話できるようサポートするライブラリセットが含まれています。このブログでは、MQTT over WebSocket プロトコルを使って iOS アプリを AWS IoT に接続する方法について説明します。これにより、ユーザーはアプリを配布する際に個別の X.509 証明書を発行する必要がなくなります。 AWS IoT Core は、自動車業界の顧客が IoT アプリケーションの開発と管理で幅広く利用されている、多機能で強力なサービスです。AWS IoT Core には、自動車業界の顧客に次のことを支援する機能がいくつかあります。1/ AWS IoT Jobs を使用した車両向けの Over-The-Air ファームウェアやソフトウェアのアップデート、2/ 車両の診断データの収集と分析、3/ 接続された車両、アプリケーション、顧客のデータを保護するための認証と認可機能。Amazon Cognito Identity Pools は、モバイルや Web アプリケーションが特定の AWS リソースにアクセスするためのゲストユーザーアクセスを提供することを目的としています。これにより、非認証ユーザーに限定的なアクセスを許可できます。具体的に、Cognito Identity Pools は、アプリケーションがユーザー認証を必要とせずに、許可されたリソースに事前に定義された権限でアクセスできるように一時的な AWS 認証情報を取得できるようにすることで、ゲストアクセスをサポートしています。このようなゲストアクセスに、顧客が実装するボット検出などの制御を組み合わせることで、より機密性の高いデータや機能へのアクセスは制限しつつ、アプリケーションの一部をログインしていないゲストでも利用できるようになります。全体として、ゲストユーザーアクセスは Identity Pools の重要な機能であり、アプリケーションのアクセシビリティとセキュリティを両立させるのに役立ちます。 前提条件 ブログで説明する認証ソリューションの前提条件は以下の通りです。 動作する iOS アプリケーション Amazon Cognito および AWS IoT Core の基本的な知識 Amazon Cognito で作成されたユーザープール ソリューション概要 図 1 – iOS アプリを AWS IoT サービスに認証および接続するためのハイレベルアーキテクチャ 手順 Amazon Cognito ユーザープールの初期設定については、 新しいユーザープールを作成する のステップ 7 までを参照してください。ユーザープールを作成したら、以下の手順に従って iOS アプリケーションを統合できます。 ステップ 1: アプリを Amazon Cognito に統合する 1.1 ユーザープールの名前 (図 2 を参照) セットアップガイドで作成したユーザープールを参照してください。このブログ記事では example-user-pool を使用します。 図 2: 作成したユーザープールにアプリを統合 1.2 ホストされた認証ページ (図 3 参照) ユーザー登録/ログインフローには、 Cognito が提供する UI と OAuth 2.0 サーバー を使用できます。この機能を有効にすると、Cognito が提供する UI と OAuth 2.0 エンドポイントのドメインを構成できるドメインペインが表示されます。 このシナリオでは、独自のカスタムフロントエンド UI を使用するため、チェックボックスを選択を外した状態のままにします。この項目は、ユーザープール名のテキストボックスの下にあります。下図を参照してください。 図 3: ホストされた認証ページ 1.3 初期アプリクライアント （図 4 を参照） OAuth 2.0 標準では、Public と Confidential の 2 種類のクライアントタイプが定義されています。アプリのクライアントに最適な設定は、作成するアプリの種類によって異なります。Public client または Confidential client のデフォルト設定を選択できます。あるいは、必要に応じて設定をカスタマイズすることもできます。 この例では、「Public client」を利用します。 アプリクライアント名には、example-app-client を利用します。 クライアントシークレットについては、この例のアプリケーションでは認証を使用する必要がないため、デフォルトの Don’t generate a client secret  オプションを選択したままにします。 図 4: app clientの設定 次のデプロイステップに進む準備ができたら、 Next を選択してください。 ステップ 2: レビューと作成 選択内容を確認し、すべて正しければ (図 5 を参照) 、ページの下部にある Create user pool を選択します。 図 5: ユーザープールの確認と作成 Amazon Cognito の ユーザープールページ内で、作成したユーザープールを確認できます （図 6 を参照） 。 図 6: User pool 注意: ユーザープールの作成後は、「user pool ID」と「app Client ID」を次のセクションのステップ 2 で利用するために保存してください。ID の見つけ方については、この 資料 を参照してください。 AWS IoT との iOS 統合 次のステップは、テレメトリデータを送信するために iOS アプリを AWS IoT に接続することです。このサンプルでは、Xcode v15.1 で Swift プログラミング言語 (v5.9.2) を使用して、 AWS SDK for iOS で AWS IoT に接続します。 Step 1: 開発 IDE に AWS IoT モジュールをインストールする iOS プロジェクトに AWS IoT フレームワークを追加するには、 CocoaPods を利用するか、AWS IoT モジュールを手動でインストールしてください。 これで、AWS IoT に接続するためのクライアントライブラリが追加されます。 関数ヘッダに import 文を追加してください。 Import AWSIoT Step 2: AWS 認証情報を Amazon Cognito Identity Pool と AWSIoTDataManager を使用して初期化する AWS Cognito で Identity Poolを作成し、pool ID を取得します。 Amazon Cognito コンソールで、左側のパネルから Identity pools を選択し、 Create identity pool を選びます。 認証済みアクセスのボックスをチェックしてください。 Authentication provider の項目を開き、 Cognito タブを選択して進んでください。 Create a new IAM role を選択してください。注記: 初期の最小限の許可と identity poolとの信頼関係を持つIAM ロールを作成します。ID プールを作成した後、IAM コンソールで許可を追加します。 前の手順で作成した ユーザープール ID と アプリケーションクライアント ID を入力してください。 Identity プール名 に testpool と入力し、 次へ をクリックしてください。 Create Identity Pool を選択します。 Edit identity pool を選択します。ID プールの ID を控えてください (例: us-east-1:xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx)。 AWS Mobile SDK の CognitoCredentialsProvider クラスを使用して、認証情報プールから AWS の認証情報を取得します。 let session = try await Amplify.Auth.fetchAuthSession() if let identityProvider = session as ? AuthCognitoIdentityProvider { let identityId = try identityProvider.getIdentityId().get() print("Identity ID: \(identityId)") } Step 3: AWS IoT で認証するためのクライアント ID の取得 AWS IoT にクライアントを識別するための一意のクライアント ID を生成します。 これは、 getIdentityId() メソッドを使用して AWSCredentialsProvider オブジェクトから取得できます。 Step 4: 前のステップで取得した認証情報を使用して AWSIoTDataManager のインスタンスを作成します。このマネージャーが MQTT 接続を処理します。 let iotEndPoint = AWSEndpoint( urlString: "wss://a123456789012-ats.iot.us-west-2.amazonaws.com/mqtt" ) let iotDataConfiguration = AWSServiceConfiguration( region: AWSRegionType.uswest2, endpoint: iotEndPoint, credentialsProvider: CredentialsProxy() ) AWSIoTDataManager.register(with: iotDataConfiguration !, forKey: "MyAWSIoTDataManager") let iotDataManager = AWSIoTDataManager(forKey: "MyAWSIoTDataManager") Step 5: WebSocket を使用して AWS IoTにMQTT 接続を作成 AWSIoTDataManager を使用して、AWS IoT プラットフォームエンドポイントへの WebSocket 接続を作成します。 エンドポイントは、利用している AWS リージョンに依存します。たとえば、xxxxxxxxxx- ats.iot.us-east-1.amazonaws.com エンドポイント情報は IoT Core コンソールの設定ページから取得できます (図 7 を参照)。 図 7: IoT コンソールのデバイスデータエンドポイントの位置 AWS IoT のパブリッシュとサブスクライブ機能を利用するには、AWS IoT コンソールで必要な IAM ポリシーを作成し、Amazon Cognito Identity にアタッチする必要があります。次の手順を参照してください。 IoT ポリシーを作成するには、IoT Core コンソールに移動し、左側のナビゲーションペインから [Secure] を選択してから、ドロップダウンメニューから [Policies] を選択します。次に [Create] をクリックします。以下の myIOTPolicy ポリシーは、すべてのトピックに対する完全なアクセス権を許可します。 図 8: publishとsubscribeを許可するIoT Policy Cognito ID にポリシーをアタッチするには、まず AWSMobileClient から Cognito Identity Id を取得します。 AWSMobileClient.default().getIdentityId(); 次に、次の AWS CLI コマンドで、 myIOTPolicy ポリシーをユーザーの Cognito Identity Id に割り当てる必要があります。 aws iot attach-principal-policy --policy-name 'myIOTPolicy' --principal '<YOUR_COGNITO_IDENT Step 6: テスト トピックへのパブリッシング/サブスクリプション (オプション) AWS IoT コンソールページの MQTT テストクライアントで、 トピックにパブリッシュするセクション に移動し、モバイルアプリにメッセージをパブリッシュします。 メッセージを受信するために、MQTT のトピックに購読します。 AWS IoT コンソールを開きます。 ナビゲーションペインで [Test] を選択してください。 「Subscribe to a topic」で「#」を入力すると、すべてのトピックに購読できます。 Subscribe を選択してください。 この時点で、テレメトリ接続のための iOS アプリと IoT の統合を設定しました。 クリーンアップ 本ブログで説明した推奨ソリューションに従った場合、AWS アカウントへの不要な課金を避けるため、以下のステップを実行してください。 Amazon Cognito ユーザープール example-user-pool とクライアントアプリ example-app-client を削除します。 Amazon Cognito > Userpools > ユーザープールを削除 をクリックします。これによりクライアントアプリとユーザープールが削除されます。 identity poolの  testpool を削除します。 Amazon Cognito > identity pools > 対象の identity poolを選択 > delete AWS IAM ロール testrole を削除する IAM > ロールに移動し、作成したロールを削除します 利点 この解決策のお客様へのメリットは以下のようなものが含まれます。 このソリューションは、iOS アプリケーション、特に自動車業界のアプリケーションを AWS IoT Core に接続する際に、スケーラブルかつシンプルな認証を可能にします。個別のユーザープロビジョニングや X.509 証明書の管理が大規模な場合は困難になりますが、この必要性を回避します。 代わりに、 Amazon Cognito Identity Pools を利用して、ログインなしで一時的かつ限定的なゲストアクセスを提供します。 このソリューションは、iOS アプリのための総合的で安全な IoT 統合を提供するため、いくつかの AWS サービスを使用しています。 AWS IoT SDK for iOS は、AWS IoT Core とシームレスに対話するためのライブラリを提供します。 この解決策は、自動車メーカーが IoT のユースケース、例えば車両のソフトウェアアップデート、使用状況に基づく保険モデル、車両の診断、接続された車両、アプリケーション、ユーザーデータのセキュリティ確保に役立つために利用できます。 まとめ 自動車アプリケーションをクラウドに安全に接続することは、自動車メーカーがリモート診断、OTA (Over-the-Air) アップデート、より正確な車両ナビゲーションなどの最新の自動車機能を実現するための重要な課題です。このブログ記事では、自動車メーカーが AWS Cognito Identity Pools を使用して AWS IoT Core に接続する iOS アプリに、よりスケーラブルかつ安全な認証メカニズムを実現する方法を示しました。この記事では、Cognito Identity Pools と iOS アプリを統合する方法、WebSocket 経由で AWS IoT Core との MQTT 接続を確立する方法、IoT トピックのパブリッシュ/サブスクライブに適切な IAM ポリシーを設定する方法を説明しています。全体として、このアーキテクチャにより、自動車用の iOS アプリと AWS クラウドの間で双方向に IoT データを交換するためのセキュアでスケーラブルな接続が実現できます。Amazon Cognito の実践的な経験を積むには、 このワークショップ を参照してください。また、AWS IoT Core に接続するエンドツーエンドのモバイル iOS アプリを構築するには、 このガイド を参照してください。 Chirayu Parikh Chirayu Parikhはペンシルベニア州コレッジビルに拠点を置くシニアテクニカルアカウントマネージャーです。彼はAWSエンタープライズサポートの自動車戦略産業組織に所属し、大手自動車メーカーのクラウドジャーニーをサポートしています。AWSに入社する前は、10年以上にわたってエンタープライズネットワーキングソリューションの顧客をサポートしていました。 Vanshaj Kochar Vanshaj Kocharは、自動車および製造業界向けビジネスユニットのソリューションアーキテクトであり、AWSクラウド上で安全で、スケーラブルで、堅牢なクラウドソリューションを構築するお客様をサポートしています。電子工学および組み込み工学の経験を持ち、自動車およびIoT技術分野のコミュニティにも積極的に貢献しています。また、AWSEducateイニシアチブにも関わり、カナダの大学生にクラウドスキルを身につけてもらう活動も行っています。 この記事は Chirayu Parikh と Vanshaj Kochar によって書かれた Connecting and Authenticating Automotive iOS App to AWS IoT Core の日本語訳です。 この記事は シニア プロトタイピング ソリューション アーキテクトの市川 純が翻訳しました。

株式会社第一興商 は、業務用カラオケシステム「DAM」の開発・運用を手掛けています。グループ全体で 3,300 名ほどの従業員が所属しています。通信カラオケ機器は各市場向けのモデルとして BOX 向け、ナイト店向け、ホテル向け、エルダー向けなど多くの機種をサポートしております。 同社では、このようなカラオケ機器に関する問い合わせ対応のために、営業向けの社内ヘルプデスクを設置しています。ヘルプデスクは 日勤交代制の 12 名体制で、機器の不具合や状況確認に関する 1 日平均 300 件の問い合わせに対応しています。 一方でヘルプデスクでは、問い合わせ内容を手作業で CRM に入力する必要があり、作業負荷と内容のばらつきが課題となっていました。具体的には、実際のカラオケ機器を操作しながら問い合わせに回答するため、リアルタイムにメモを取ることができません。そして受電を優先しているため CRM への記録が後回しとなり、結果として録音データを聞き直して入力する場合もあります。加えて、記録内容は個人の文章能力に依存しており、必要な情報が含まれていないこともありました。 検証内容 このような課題を解決するため、第一興商では AWS のサービスを活用した以下の検証を実施しました。 ヘルプデスクの録音データを Amazon Simple Storage Service (Amazon S3) にアップロード Amazon Transcribe を使用して文字起こし Amazon Bedrock の Claude 2 を使用して通話内容を要約   そして、要約された内容とヘルプデスク担当者が手動で入力した内容を比較し、①修正なし、②少量の修正が必要、③修正が必要、の 3 段階で評価、①と②を合格として検証しました。 また今回の検証は、入社 1 ヶ月の社員を中心に実施しました。AWS を利用するのは初めてのメンバーでしたが、約 3 週間で検証作業を完了することができました。 検証結果 その結果として、検証データ 58 件のうち 約 90 % が「一定の要約品質基準を満たす」という良好な結果が得られました。少量の修正が必要な箇所はあったもの、作業負荷の大幅な軽減が期待できます。第一興商の執行役員である関澤様からは「AWS の技術が『多種多様の問い合わせを行う営業現場とヘルプデスクの会話』を見事に要約し、精度に驚きを実感した」とコメントをいただきました。 また今回の検証にあたって、複数部署に対して現状の運用をヒアリングした上で、多くの録音データを聞く必要がありました。結果として、他部署の業務内容や発生する不具合を知ることができるという、新入社員にとっても思わぬメリットもありました。 今後の展望 第一興商では今回の検証結果を受けて、ヘルプデスク業務における生成 AI 機能の導入が進んでいます。今後はこの要約内容を FAQ システムと統合し、さらなる業務の効率化を図っていく予定です。 並行して、Amazon Bedrock に関する 2 つの検証を続けています。1 つ目が入力 Prompt の改良です。Prompt に詳細な情報を追加することで、精度は 95 % を超え、また出力形式を指定することが可能になりました。これによりシステム連携が容易になります。2 つ目に Claude 3 Haiku の検証です。Claude 2 よりも料金を 90 % 以上削減しながらレスポンスまでの時間を短縮できる見込みです。 またこの技術を活用してヘルプデスクの文字起こしだけでなく、会議の議事録などに生成 AI を導入し、時間を節約していきたいと考えています。これにより、本業であるカラオケの開発や企画などに、一層力を注ぐことができます。 まとめ 今回の検証を通して、Amazon Bedrock と Amazon Transcribe を使用した通話音声要約ソリューションが、ヘルプデスクの作業軽減に繋がることを確認できました。第一興商では、今後も AWS の先進的なテクノロジーを活用し、本業であるカラオケ機器の開発や企画により一層注力していく考えです。