本ブログは、ルームクリップ株式会社と Amazon Web Services Japan が共同で執筆しました。また、今回の内容を含む講演動画 ( Lambda で動くプロンプトライクな物体検出システム ) も公開されていますので、興味をお持ちいただけましたら合わせてご覧ください。 ルームクリップ株式会社 は「日常の創造性を応援する」というミッションを掲げ、住生活の領域に特化した日本最大級のソーシャルプラットフォーム「RoomClip」を運営しています。同プラットフォームでは、ユーザーが投稿した「住生活の実例写真」から欲しいアイテムや好きなブランドと繋がることができます。 同社で投稿された部屋写真を自動で解析して類似商品のリンクを記載する機能を実装しました。これによりユーザーは投稿された写真に写る家具を取り扱う EC サイトに遷移したり、一部は Roomclip 内で直接購入できるため、シームレスな購買体験が得られます。この機能のコアとなる家具の検出システムに軽量な基盤モデルを採用し AWS Lambda 上で実行した事例を紹介いたします。 課題 家具の検出システムの実装には要件が 2 つあり、1) ある写真ではカーテンにリンクを付与するが、ある写真では付与しないというような、細やかな運用のドメイン知識を反映できること。2) 今までリンクが付けられていなかったコーヒーメーカーにもリンクを付与したいというような、追加のニーズに柔軟に対応できることが求められます。 まずは、家具検出システム構築に必要な要素であるセグメンテーション、家具の認識、座標の取得を、既存の仕組みを用いて検討しました。しかし、既存の API サービスを利用する場合、新たに検出したい家具を追加するには追加学習が必要で、ニーズに即座に応えるのが難しいこと。さらに過剰に家具を検出してしまうという課題があり、柔軟なリンク付与対象の調整が難しいことが分かりました。また、自社で機械学習モデルを開発する場合は GPU の利用コストと学習時間がかかるという課題がありました。 ソリューション ルームクリップ社では課題解決のために、軽量な基盤モデルを利用して自然言語で指定した家具のみを検出させる以下のようなアプローチを取りました。 FastSAM による物体のセグメンテーションと座標取得 基盤モデルの CLIP による自然言語で指定した家具の認識 FastSAM と CLIP を組み合わせた物体検出のフローを AWS Lambda 上で構築 FastSAM のセグメント範囲の大小を調整できるカスタム性と、CLIP を利用した自然言語で指定した家具のみを抽出するフィルターを組み合わせることで、細やかなビジネスニーズに応える柔軟な家具検出システムを実現しました。投稿された写真が Amazon Simple Storage Service (Amazon S3) に保存されたことをトリガーに AWS Lambda 上の家具検出システムが実行され、処理結果が Amazon Relational Database Service (Amazon RDS) に保存されるというシンプルな構成です。ここで注目すべきは家具検出システムは CPU で動作し、 AWS Lambda のメモリは 4 GB 程度で、写真 1 枚あたりの計算は 60 秒以下で完了する高速かつ低コストなシステムであることです。検出すべき家具が追加された場合でも、追加学習不要でプロンプトを変更するだけで対応可能です。 導入効果 生成 AI を活用したことにより独自のニーズに即座に応えられる家具検出システムの構築を実現しました。プロンプトで認識すべき家具を指定できるため、非エンジニアでも仕様を変更できる柔軟なシステムとなりました。新たに認識したい家具が増えた場合でも、追加学習不要でプロンプトの修正のみで対応可能です。ビジネス的な効果としては、導入前と比較して商品ページの閲覧数がおよそ 2 倍に増加する大きな効果が得られました。また基盤モデルを AWS Lambda 上で実行することで、コストと運用負荷を大幅に削減できました。ルームクリップ社は、今後も AI やクラウドサービスの活用を推進し、住生活の領域でイノベーションを続けていく考えです。 ソリューションアーキテクト　長友 健人

2024 年 6 月 20 日、21 日に AWS Summit Japan が開催され、その 1 日目に “ チームで課題解決型ハンズオンに挑戦！楽しく学ぶ「AWS Jam」 ” を実施しました。本イベントには、クラウドスキルの向上を目指す 112 名が 4 名ずつ 28 チームに分かれて参加し、熱戦が繰り広げられると同時にチーム内でのスキル共有や新たな発見に満ちた有意義な時間となりました。 このブログでは当日の様子を伝えつつ、AWS Jam がどのように AWS の学習やチームでのスキル共有などに役立てられるか、AWS Jam を実施したい場合の選択肢として AWS Skill Builder やクラスルームトレーニングを紹介します。 AWS Jam とは AWS Jam は、AWS のユースケースに沿って用意された様々なテーマの課題を解決しながら「AWS を楽しく学ぶ」実践型のイベントです。参加者は AWS やシステム開発の知識や経験を活用し、必要に応じてその場で情報を調べながら、与えられた複数の課題を AWS マネジメントコンソールなどを利用してクリアしていきます。AWS Jam では、課題ごとに獲得得点やヒントが設定されており、時間内にクリアした課題と使用したヒントを総合してチームの得点を競い合います。 AWS Jam には「 Play 」「 Learn 」「 Validate 」の3つのコンセプトがあります。 Play (遊ぶ) : 得点を競うゲーミング形式のイベントを通じて、楽しみながら課題解決に挑戦します。チーム内でのコミュニケーションの促進にもつながります。 Learn (学ぶ) : シナリオに沿った課題を解決することで、AWS サービスの知識やスキルを身につけていきます。普段扱っていない AWS のサービスや機能を新たに学んだり調べたりする機会にもなります。 Validate (検証する) : 課題解決を通して、参加者自身の AWS サービスに対するスキルや理解度を確認できます。 AWS Jam 実施前のハイライト 今回の AWS Jam では 4 人でチームを組みます。登録時点ではチームは決まっておらず、会場に入場する際にくじ引きでチームを決定しました。ランダムにチームを決定することで、個人で参加する人のハードルを下げ、平等性を保つことを目的としました。 AWS Jam 開場時のくじ引きと誘導 AWS Jam に参加するには、AWS Skill Builder のアカウントが必要です。開場からイベント開始までの時間を利用して、アカウントの準備を行なっていただきました。また、準備が完了したテーブルでは、チームメンバーと自己紹介や雑談をして交流を深めていました。 準備が整ったらオリエンテーション開始です。オリエンテーションでは、AWS Jam のプラットフォーム上でイベントとチームに参加していただき、AWS Jam の紹介とチャレンジへの取り組み方の説明を行いました。 AWS Jam では、チームでの取り組み方にプラットフォーム上の制約は無く、複数人で相談しながら 1 つずつチャレンジを進めるモブ型や、チーム内で 2 人 1 組になってチャレンジを進めるペア型、手分けして個人でチャレンジを進めるソロ型があります。 AWS Jam チーム内での分担 ただし、本イベントでは以下の理由によりペアワークまたはモブワークで進めていただくことにしました。 個人ではなく、チームで AWS Jam イベントを楽しんでいただきたいため AWS Jam は個人の学習だけではなく参加者同士のスキル共有にも役立つことを体験していただきたかったため また、ペアワークまたはモブワークをチャレンジに取り組む時のルールとして設定することは、昨年の AWS Summit でも行なっていました。ペアワークまたはモブワークの効果やうまく進めるための方法は AWS Jam 実施レポート @ AWS Summit Tokyo 2023 も確認ください。 AWS Jam 開始前にいくつかコツを伝えました。直前のことが一番記憶に残りやすいため、特に重要なことを開始直前のタイミングで伝えると効果的です。 AWS Jam うまく進めるためのコツ 特に最後の楽しむためのコツとして、チームで喜びを共有することを意識していただきました。チームで何かを達成したり、ポイントを獲得したりしたときには、チーム全員で拍手をすることで、チームの連帯感を高め、チームでイベントを楽しんでいただけるようにしました。 AWS Jam 実施中の様子 本イベントでチームで Jam に取り組む時間は 150 分でした。AWS Jam が始まると、チーム内でペアを決めたり、担当チャレンジを相談したりしていました。ペアワークやモブワークでは、画面を操作するドライバーと、指示やサポートを行うナビゲーターに分かれて協力しながらチャレンジに取り組んでいました。参加者の中にはペアワークやモブワークを初めて経験する方も多く、最初は上手に指示ができなかったり、指示の意図をうまく汲み取れなかったりする様子も見受けられましたが、積極的にコミュニケーションを取る中でチームでスキルを共有する姿が見られました。 また、ペアワークでチャレンジに取り組む中で行き詰まったときには、ホワイトボードを活用して考えを整理したり、チーム内の他のペアに相談したりすることで、チーム一丸となって課題解決に取り組んでいました。 AWS Jam 実施中の様子 1/4 AWS Jam 実施中の様子 2/4 AWS Jam 実施中の様子 3/4 AWS Jam 実施中の様子 4/4 結果発表 激戦の結果、優勝は「オオサカ」チーム、2 位が「Nara as the No.1」チーム、3 位が「サーティーワン」チームとなりました。各チームとも素晴らしいパフォーマンスを見せ、最後まで緊張感が漂う白熱した戦いを繰り広げました。おめでとうございます。 1 位「オオサカ」のみなさん 2 位「 Nara as the No.1 」のみなさん 3 位「サーティーワン」のみなさん 上位３チームのメンバー AWS Jam のコンソールでは、リーダーボードやスコアリングトレンドがリアルタイムで表示されるため、特に後半ではリーダーボードを見ながらチャレンジの優先順位を変更したり、ヒントを活用してチームで競い合う様子が確認できました。スコアリングトレンドからは、順位が何度も入れ替わる大接戦の様子がわかります。 AWS Jam では単純な技術力だけでなく、チームでの連携や戦略も順位に大きく影響します。特に、ヒントを使用したチームには最大獲得可能スコアの減少というペナルティがある中、ヒントを使ってでも学びとスコアを得るという戦略を選択したチームもありました。 AWS Jam リーダーボード AWS Jam スコアリングトレンド 実施後のアンケートでは、「楽しく学べて大変満足しました！」「ペアワークはお互いで教え合う仕掛けになっており、勉強になり、かつ楽しかったです！」「普段利用していなかったサービスかつ、設定したことのない設定ができたので、そこは今後の社内でのサービス検討時に利用できそうです。」といったコメントを多くいただきました。 また、「今後自分の組織でスキルアップをするために AWS Jam を使いたいと思いますか？」という項目では、96 %以上の参加者が肯定的な結果となりました。組織で AWS のスキルアップを考えられている場合には、ぜひ AWS Jam を活用してみてください。組織で AWS Jam を活用する方法は次にご紹介します。 AWS Skill Builder チームサブスクリプションで AWS Jam イベントを実施可能 AWS Skill Builder は AWS の無料の学習コンテンツとして、600 を超えるデジタルコースや AWS 認定公式練習問題を使用できるオンライン学習センターです。また、 チームサブスクリプション を利用すれば、今回の AWS Summit で実施した AWS Jam イベントをお客様が実施できるようになります。他にも 500 を超えるチャレンジ (2024/07/01 現在) から好みのチャレンジを選定し、組織内で回数制限なく自由にイベントを開催できます。 AWS Skill Builder サブスクリプションのご案内 のブログに詳細が記載されていますので、併せてご確認ください。 AWS Summit Japan 2024 で使われたチャレンジの一覧はこちらです。すでに組織で AWS Skill Builder チームサブスクリプションを契約されている場合は、「 AWS Summit Japan 2024 」 のチャレンジセットを使用して、ぜひご自身の組織で開催してみてください。 レベル タイトル AWSサービス Easy Protect my CloudFront Origin CloudFront, ELB Easy ARM64 your Databases RDS Medium Query operations in DynamoDB DynamoDB, Lambda Medium Use one ALB with multiple domains ELB, Route 53, VPC Medium Pull the Alarm! CloudWatch, EC2 Medium Mining in my cloud? CloudTrail, EC2, ELB Medium Trace with AWS Lambda Powertools Lambda, X-Ray, DynamoDB Medium Connect using RDS Proxy RDS, Lambda, IAM Hard A/B Testing Puzzle CloudFront, S3, Cognito, API Gateway, Lambda, DynamoDB, CloudWatch Hard Hash the Data Lake! Athena, S3, Lake Formation, Lambda AWS クラスルームトレーニングで AWS Jam を提供中 AWS クラスルームトレーニングに AWS Jam を追加したコースも提供しています (2024/07/01 時点では個社向けの開催のみです)。こちらを選択していただく利点として、クラスルームトレーニングを受けた後に AWS Jam を実施するため、 知識をインプットするだけでなく AWS Jam で実践することで、より理解を深めたりスキルとしての検証をしたりできる点があります。さらに、トレーニング企画時に AWS の担当者と相談しながら AWS Jam の実施方法を決めていけるので、以下のような要望も可能です。 Play / Learn / Validate のどのコンセプトを重視するか 知識やスキルの近いメンバーでチームを組むか、均等になるようにチームを組むか モブ型、ペア型、ソロ型など、どんな形式で進めるか また、AWS Summit と同様に AWS の認定インストラクターが実施準備や当日の進行をするため、AWS Jam の用意や進行をするのに不安があるお客様にもおすすめです。 AWS Jam を追加したクラスルームトレーニングはオンラインでもオンサイトでもどちらでも提供可能です。オンラインの利点を活かして、普段は交流の少ないグループ内企業や国際拠点の従業員との交流の場としたり、オンサイトで部署やチーム内のスキル共有の場としていただいています。どちらもトレーニングでの知識のインプットだけでなく、AWS Jam で実践することで、知識を深めスキルとして検証できたとお客様から満足いただけています。 組織での AWS Jam 活用に興味がある場合は、 AWS トレーニングと認定へのお問い合わせ からご連絡ください。(画面右上で「日本語」を選択し、日本語での問い合わせが可能です) 最後に AWS Jam は、楽しみながら実践的に AWS を学ぶことができるイベントです。今回の AWS Summit Japan でも、熱戦が繰り広げられるとともに、チーム内でのスキル共有や新たな発見に満ちた有意義な時間としていただけました。これからクラウドスキルの向上を目指す方、ただ知識をインプットするだけでなく実践力を鍛えたい方、組織や個人のスキルを検証したい方にとって AWS Jam は最適です。 AWS Jam をやってみたいと思った方は、AWS Skill Builder や AWS クラスルームトレーニング、AWS のイベント時に開催される機会を利用して AWS Jam に参加してみてください。 AWS Jam 実施後の集合写真 おまけ：本イベントでは、AWS トレーニングパートナー所属の AWS 認定インストラクターも運営メンバーとして加わっていました。当日運営をサポートいただいた AWS 認定インストラクターの方々、ありがとうございました。 AWS Jam 実施前のサポーター打ち合わせの様子 AWS Jam サポーターの集合写真 AKKODiSコンサルティング株式会社 藤原 靖士 NECビジネスインテリジェンス 吉田 薫 NTTデータ先端技術株式会社 田中 勇希 クラスメソッド株式会社 大前 諒祐 クラスメソッド株式会社 平野 文雄 トレノケート株式会社 久保玉井 純 トレノケート株式会社 山下 光洋 トレノケート株式会社 髙山 裕司 パナソニック コネクト株式会社 船橋 俊雄 株式会社f4samurai 酒井 幹士 株式会社アシスト 佐伯 竜輔 株式会社日立システムズ 藤巻 雄裕 著者について 西村 諄 (Nishimura Shun) AWS トレーニングサービス本部 テクニカルインストラクター

本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 これまでの記事は以下です。 第一回　適切なデータストアの選定とアーキテクチャの見直し 第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 第三回　クラウドを活用したテスト効率化 〜リリース前・リリース後に何をするべきか〜 1.はじめに 第三回では、Lemino のサービスリリース時にどんな検証をし、リリース後のデプロイサイクルでどのような確認をしているか、ご紹介します。 2.サービスリリース前のテスト Lemino のリリース前には、機能面のテスト・負荷テスト・異常時を想定した検証など様々な検証を行なっています。 開発に加えて、複数の観点の検証を並行して効率的に実施するために、開発・負荷試験・ステージング・商用環境を更に分割した8面で構成し、それぞれの環境を各開発チーム・試験チームに割り当てています。複数環境を運用するため、IaCツール(Terraform)で各環境のリソースを管理し、各環境で不用意な差分が発生しないように管理しつつ、プロビジョニングの作業を効率化しています。 機能面のテストは日々の開発の中でも実施するのですが、サービスリリース前のテストとして、ライブイベント時のピーク負荷を実際にかける検証をしています。Leminoでは同時視聴ユーザが数百万規模のライブに耐えうる基盤を作ることを想定しましたので、その負荷テストの中でどの部分を実際の負荷をかけて検証するかが課題になりました。 視聴開始に関連するアクセスなどピーク負荷が課題になる部分は、本番相当の負荷をかけて検証しました。 検証の際には以下に注意する必要があります。 全体として 1 分を越えて継続する、1Gbps (10 億ビット/秒) または 1Gpps (10 億パケット/秒) を超える検証についてはネットワーク負荷テストの申請が必要になります。（参考： Amazon EC2 Testing Policy ）ほとんどの場合、このネットワーク負荷に到達する試験が必要になるケースはありませんが、今回のような大規模トラフィックの場合、この申請が通る前に負荷試験を行うことはできないため、大規模な負荷試験の場合、十分なリードタイムをもって、負荷試験を行う計画をたてることが必要です。 負荷を発生させるためのアカウントで、想定負荷を出すためのリソース準備が必要になります。 ※Amazon EC2 Testing Policy を基準に、十分小規模な負荷テストであれば同一アカウントから、大規模な負荷試験の場合、負荷を発生させるためのアカウントを別途用意し、試験を実施 Lemino では、システムごとに異なる負荷試験のツールを使いましたが、たとえば、Grafana k6 はコンテナ実行可能なJavaScript ベースの負荷試験ツールでコードベースなのでGit での試験コード管理も可能です。EC2 からの軽微な負荷試験や 5000rps 程度の負荷試験であれば Docker がインストールされている環境から負荷試験が実施可能ですが、Kubernetes cluster からの大規模負荷及び 100万 rps 近い負荷試験を実施する場合は k6-operator を Kubernetes にデプロイすることで cluster が実行可能となります。eksctlでEKSを作成すれば30分程度で構築可能です。 負荷試験の前に、ピーク負荷を発生させるために必要なリソースと、ピーク負荷をかけた際にそれを処理するために必要となるリソースが問題なく起動できるか確認し、必要に応じて上限緩和申請を行う必要性があります。非常に大きなトラフィックを発生させようとした場合、通常は問題にならないことが課題になるケースがあります。例えば、ALB や Fargate がスケールするために必要とするIPアドレスが、既存の Subnet のIPレンジからでは払い出せない、などといったことがありえます。思いもよらない制限のために、本番当日にリソースが用意できない自体に陥らないよう、利用するサービスについてはすべての上限に当たる可能性を確認し、あらかじめ検証で本番ピーク相当にスケールアウトさせた上で、実際のピーク負荷をかけています。また、上限緩和申請についても十分なリードタイムを持って実施することが必要ですので、ネットワーク負荷テストの申請が必要になる程の一定以上大規模な試験を計画する場合には、あらかじめ入念な計画が必要です。 本番相当の負荷をかける試験に意味がある部分、ない部分を判断することも重要です。通常のトラフィック処理では、CDN を使っていれば、多数のクライアントに対して、地理的に分散されたエッジロケーションでリクエストを処理するため、処理は適切に分散します。 通常のトラフィック処理 例えば、CDN を経由して Live 配信の動画を視聴する検証を特定の AWS アカウントに擬似的に作った環境で再現しようとした場合、仮に下りの通信が1ユーザーあたり 1Mbps だったとしても、1000万同時視聴を想定すると 10Tbps になります。このトラフィックを受ける検証環境を用意することは技術的にもコスト面でも非常に難しく、また、全国のユーザーがアクセスする場合と1つのAWSアカウントのリージョンからアクセスするのでは接続する CDN の Edge ロケーションのトラフィックパターンも変わってしまいます。 アンチパターン：特定のクライアントからの負荷試験 特定のクライアントからの大量のリクエストは、一部のリソースだけにリクエストが集中するため、実際のトラフィックパターンとは異なった試験になり、キャッシュヒットやパフォーマンスの観点で検証にならない場合が多くあります。概ねどの程度CDN でキャッシュヒットするかなどの確認は、小規模なライブを開催し、過去の配信実績をベースにして試算します。大規模トラフィックについては机上でどの程度キャッシュヒットするか検討した上で、バックエンドにかかる負荷を試算し、その試算をベースに負荷を想定することも選択肢の一つです。 参考： CloudFront の負荷テスト 3.リリース後も継続するデプロイの中でのテスト リリース前の検証も大切ですが、機能面の検証は本番運用開始後も継続的に、楽にできるようにしておかなければ、開発のアジリティを向上することはできません。 Lemino でのデプロイ可能ブランチは一つのみ運用し、タグのPUSHを契機として単体テストから各環境へのデプロイ及び、エンドツーエンドテストまでGitlab-CI で自動化しています。またステージング環境から商用への展開、Blue-Green切替え、切戻しのタイミングだけ手動で指定できるように制御することで、品質とアジリティの両立を実現しています。CIで利用したエンドツーエンドテストのスクリプトは、外形監視でも流用するなどの効率化も行っています。 4.まとめ AWS では本番相当のテスト環境を一時的に作成し、テスト完了後に環境を破棄できるため、容易に本番環境をシミュレートできます。一方、その本番相当の検証が意味がないものにならないよう、十分計画する必要があります。リリース後も継続するCI/CD の中でのテストは自動化することで、開発のアジリティを向上しつつ品質を担保できます。 こうした Lemino での知見が皆様の今後の開発の役に立てば幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和﨑美希 通信業界のお客様を担当するソリューション アーキテクト。普段は通信業界のお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げるなど、幅広いAWS活用をご支援しています。

本記事は 2024年4月22日に AWS Machine Learning Blog で公開された “ The executive’s guide to generative AI for sustainability ” を翻訳したものです。 組織は、環境、社会、ガバナンス (ESG) の実践に加えて、持続可能性目標に対するますます高くなっていく要求に直面しています。 Gartner 社の調査 によると、87% のビジネスリーダーが今後 2 年間で組織の持続可能性への投資を増やすことを予想しています。この記事は、 生成 AI と サステナビリティ（持続可能性） の融合点を探る経営者のための出発点となります。持続可能性と ESG イニシアチブを加速するための生成 AI の活用事例とベストプラクティスを提供し、持続可能性における生成 AI の主な運用上の課題についての洞察を示しています。このガイドは、組織の目標と調整しながら、生成 AI を効果的にサステナビリティ戦略に統合するためのロードマップとして活用できます。 持続可能性のための生成 AI へのロードマップ 以下のセクションでは、持続可能性イニシアチブへの生成AIの統合に向けたロードマップを示します。 1. 持続可能性における生成 AI の可能性を理解する 生成 AI は、大量のデータを分析し、パターンを特定し、文書を要約し、翻訳を行い、エラーを修正し、質問に答えるなどの幅広い能力を備えており、 ビジネスのあらゆる部分 を変革する力を持っています。これらの能力は、組織のバリューチェーン全体を通じて付加価値を提供するために活用できます。図 1 は、バリューチェーン全体における持続可能性のための生成 AI の活用事例の一部を示しています。 図 1. 生成 AI のバリューチェーン全体でのサステナビリティユースケース例 KPMG の 2024 年 ESG 組織調査 によると、組織が ESG の影響、リスク、機会に関する情報開示の規制圧力に直面する中で、ESG ケイパビリティへの投資は経営陣にとって最優先事項の 1 つとなっています。このような状況において、生成 AI を活用することで、 組織の ESG 目標を推進 することができます。 典型的な ESG のワークフローは、それぞれが独自の課題を抱える複数のフェーズで構成されています。生成 AI はプロセス全体を通じてこれらの課題に対処する解決策を提供し、持続可能性への取り組みに貢献することができます。図 2 は、組織内の ESG ワークフローの各フェーズにおいて、生成 AI がどのような支援ができるかの例を示しています。これらの例には、市場動向分析の高速化、正確なリスク管理とコンプライアンスの確保、データ収集や報告書作成の促進が含まれます。ただし、ESG ワークフローは業種、組織の成熟度、法的枠組みによって異なる可能性があります。業界固有の規制、企業規模、地域の方針などの要因が ESG のワークフロー手順に影響を与えます。したがって、特定のニーズと状況に応じてユースケースを優先順位付けし、成功を測定するための明確な計画を策定することが、最適な効果を上げるために不可欠です。 図 2. ESG ワークフローに対する生成 AI の利点のマッピング 2. 持続可能性における生成 AI の運用上の課題を認識する 組織の持続可能性目標や ESG イニシアチブへの対応に生成 AI の可能性を活用しようとする組織にとって、生成 AI の実装における課題を理解し、適切に対処することが不可欠です。これらの対処方法には、高品質のデータの収集と管理、既存の IT システムへの生成 AI 統合、倫理的懸念への対処、スキルギャップの解消、責任あるシステム構築のため、最高情報セキュリティ責任者 (CISO) や最高財務責任者 (CFO) など主要ステークホルダーを早期に巻き込むことが含まれます。法的課題は、概念実証 (POC) から実稼働への移行を大きく妨げる要因となります。したがって、コンプライアンスを意識して構築するため、法務チームを早期に関与させることが不可欠です。図 3 は、持続可能性における生成AIの主な運用上の課題の概要を示しています。 図 3. 持続可能性における生成 AI の運用上の課題 3. 適切なデータ基盤を構築する 持続可能性の目標達成のために生成 AI を活用しようとする CEO として、 データが差別化の源泉 であることを覚えておく必要があります。高品質のデータにすぐにアクセスできない企業は、自社のデータで生成 AI モデルをカスタマイズできず、生成 AI の本格的なスケーリング可能性を実現し、競争優位を確保することができません。 多様で高品質 なデータセットの取得に投資して、ESG イニシアチブを強化・加速しましょう。 Amazon Sustainability Data Initiative や AWS Data Exchange などのリソースを活用すれば、包括的なデータセットの取得と分析を簡素化・迅速化できます。外部データの取得に加え、生成 AI の可能性を最大化し、組織データの分析と新たな洞察の発見に活用するため、内部データ管理を優先することが重要です。 運用の観点から、 Foundation Model Ops (FMOps) および Large Language Model Ops (LLMOps) を取り入れることで、持続可能性への取り組みがデータ主導かつスケーラブルになります。これには、データリネージの文書化、データのバージョン管理、データ処理の自動化、データ管理コストの監視が含まれます。 4. 高いインパクトが期待できる機会を特定する サステナビリティ戦略の中で、生成 AI が大きな影響を与えられる機会を見つけるために、 Amazon の Working Backwards の原則 を活用できます。組織内の主要分野で即座の改善が見込めるプロジェクトを優先しましょう。ESG は持続可能性の重要な側面ですが、 エネルギー 、 サプライチェーン 、 製造業、運輸、農業 などの業界固有の専門知識を活用することで、ビジネスアプリケーションに合わせた多様な持続可能性のための生成 AI のユースケースを発見できます。さらに、研究開発の改善、顧客自身によるサービス利用の実現、ビルでのエネルギー使用の最適化、 森林破壊の抑制 などの代替手段を探ることで、持続可能なイノベーションのための大きな機会が生まれる可能性があります。 5. 適切なツールを使用する 持続可能性のための生成 AI の活用において、適切なツールを使用しないと、複雑さが増し、セキュリティが損なわれ、効果が低下する可能性があります。適切なツールは、選択肢と柔軟性を提供し、特定のニーズと要件に合わせてソリューションをカスタマイズできるようにすべきです。 図 4 は、2023 年時点での AWS の生成 AI スタック を示しています。これは、すべての層にわたって選択肢、幅広さ、深さを備えた一連の機能を提供しています。さらに、データ中心のアプローチに基づいて構築されており、セキュリティとプライバシーを考慮して設計されています。 持続可能性イニシアチブを推進するために使用できるツールの例は次のとおりです。 Amazon Bedrock – 主要 AI 企業の高性能な基盤モデル (FM) に単一の API を通じてアクセスできる、完全マネージドサービス。持続可能性のユースケースに適したモデルを選択できます。 AWS Trainium2 – FM と LLM の高性能トレーニング向けに設計された専用チップで、Trainium2 は第1世代Trainium チップと比較して最大 2 倍のエネルギー効率(性能/ワット)を実現。 Inferentia2 ベースの Amazon EC2 Inf2 インスタンス – 同等の Amazon EC2 インスタンスと比べて最大 50% の性能/ワット向上。大規模な深層学習モデルを処理するよう設計されており、エネルギー効率の改善により、超大規模モデルを展開しながら持続可能性目標を達成できます。 図 4. AWS の生成 AI スタック 生成 AI は万能の解決策ではありません。持続可能性イニシアチブへの影響を最大化するには、適切なモダリティと最適化戦略を選択し、アプローチをカスタマイズすることが不可欠です。図 5 は、生成 AI モダリティの概要を示しています。 図 5. 生成 AI のモダリティ さらに、図 6 では、 プロンプトエンジニアリング 、 Retrieval Augmented Generation (RAG) 、 ファインチューニングまたは継続的事前トレーニング など、主な生成 AI 最適化戦略を示しています。 図 6. 生成 AI の最適化戦略 7. 生成 AI エージェントを使用してアプリケーション開発を簡素化する 生成 AI エージェント は、データ入力、顧客サポート問い合わせ、コンテンツ生成などの 様々な定型的・反復的タスクを自動化 する高度な機能を備えているため、持続可能性イニシアチブを前進させる独自の機会を提供します。さらに、タスクを小さな管理可能なステップに分割し、さまざまなアクションを調整し、 組織内のプロセスの効率的な実行 を行うことで、複雑な多段階のワークフローを調整できます。例えば、 Amazon Bedrock のエージェント を使って、運用全体のエネルギー使用パターンを監視・分析し、省エネ化の機会を特定するエージェントを構成できます。あるいは、持続可能性規制のコンプライアンスをリアルタイムで監視する専用エージェントを作成することもできます。 8. 評価のための堅牢なフィードバックメカニズムを構築する 生成 AI モデルの調整や目標の再定義を行うなど、戦略的な改善のためにフィードバックから得られる洞察を活用しましょう。これにより、持続可能性の課題への機敏性とアラインメントを確保できます。以下のガイドラインを検討してください。 リアルタイムモニタリングの実装 – 効率性と環境への影響に焦点を当て、持続可能性のベンチマークに対する生成 AI のパフォーマンスを追跡するモニタリングシステムを設定します。生成 AI イニシアチブの持続可能性への貢献に関する洞察を提供する メトリクスパイプライン を構築します。 ヒューマン・イン・ザ・ループ評価のためのステークホルダーの参加 – ヒューマン・イン・ザ・ループ監査 を行って、内部チーム、顧客、パートナーからの定期的なフィードバックを収集し、組織の持続可能性ベンチマークに対する生成 AI プロセスの影響を評価します。これにより、透明性が高まり、持続可能性へのコミットメントに対する信頼が醸成されます。 継続的改善のための自動テストの活用 – RAGAS や LangSmith などのツールを使えば、LLM ベースの評価を活用して不正確さやハルシネーションを特定・修正でき、持続可能性の目標に沿って生成 AI モデルを迅速に最適化できます。 9. 影響を測定し、持続可能性のための生成 AI からの投資対効果を最大化する 炭素排出量の削減などの環境への影響と コスト削減やビジネスの機敏性の向上 などの経済的な利益を捉える明確な主要業績評価指標 (KPI) を確立します。この２つのフォーカスを持つことにより、自組織による投資が環境の持続可能性に関するプログラムに貢献するだけでなく、持続可能性のビジネスケースを強化し、サステナビリティの実践におけるイノベーションと競争力の強化を後押しすることができます。内外に成功事例を共有して他者に刺激を与え、組織の持続可能性リーダーシップへのコミットメントを示しましょう。 10. 生成 AI のライフサイクル全体でリソース使用量を最小限に抑える 場合によっては、生成 AI 自体のエネルギーコストが高くなる可能性があります。最大の影響を与えるために、持続可能性イニシアチブに生成 AI を活用することのメリットと、その技術自体のエネルギー効率のトレードオフを検討する必要があります。反復的な生成 AI のライフサイクルを深く理解し、 各フェーズを環境に配慮して最適化 することが重要です。一般的に、生成 AI への取り組みは、特定のアプリケーション要件の特定から始まります。そこからモデルをゼロから学習させるか、既存のものを使うかを選択できます。ほとんどの場合、既存のモデルを使ってカスタマイズする方が望ましいでしょう。導入前に、この手順に従い、システムの徹底的な評価を行うことが不可欠です。 最後に、継続的な監視により、継続的な改善と調整が可能になります。このライフサイクル全体を通して、AWS Well-Architected Framework のベストプラクティスを実装することが推奨されます。生成 AI のライフサイクルの概要については、図 7 を参照してください。 図 7. 生成 AI のライフサイクル 11. リスクを管理し、責任を持って実装する 生成 AI には、組織の持続可能性目標の達成に大きな可能性がありますが、有害性やハルシネーションなどの 課題 もあります。イノベーションと生成 AI の責任ある使用のバランスを適切に保つことが、リスクを軽減し、責任ある AI イノベーションを可能にするための基本となります。このバランスには、品質、開示、報告などの要因に関する リスクアセスメント を考慮する必要があります。そのためには、特定の ツールと機能 を採用し、セキュリティチームの専門家と協力して セキュリティのベストプラクティス を採用することが必要不可欠です。生成 AI を安全かつ確実に拡大するには、使用事例に合わせてカスタマイズし、責任ある AI ポリシーに沿った ガードレールを設ける 必要があります。 12. チームの教育とトレーニングに投資する チームのスキルを継続的に向上させ、組織の持続可能性目標の達成に向けてイノベーションを起こし、積極的に貢献できるような能力を高めましょう。 持続可能性 と 生成 AI の両分野で必要なスキルを最新の状態に保つため、関連するリソースを特定してください。 まとめ この記事では、持続可能性と ESG の目標の両面に焦点を当て、経営者が生成 AI を持続可能性戦略に統合するためのガイドを提供しました。持続可能性への取り組みにおける生成 AI の採用は、単なる技術的なイノベーションにとどまるものではありません。それは、責任、イノベーション、継続的改善の文化を育むことです。高品質データを優先し、大きな影響が期待できる機会を特定し、関係者の参加を促進することで、企業は生成 AI の変革力を活用して、持続可能性目標を達成するだけでなく、それを上回ることができるのです。 AWS による支援 AWS ソリューションライブラリ を探索し、AWS 上でサステナビリティソリューションを構築する方法を発見してください。 AWS 生成 AI イノベーションセンター では、アイデア出し、戦略的なユースケース特定、実行、本番環境への拡大について、専門家のガイダンスを得ることができます。 Amazonが 2040 年までに温室効果ガス排出実質ゼロを達成するための 気候変動対策に関する誓約 (The Climate Pledge) コミットメントに向けて AI をどのように活用しているかをご覧いただけます。 AI を活用した Amazon の 7 つの持続可能な未来とビジネスの構築方法 をご覧ください。 著者について Dr. Wafae Bakkali は AWS のデータサイエンティストです。生成 AI の専門家として、Wafae は、生成 AI 技術を活用してお客様のビジネス課題を解決し、最大限の効率と持続可能性を確保するミッションの元に、お客様を支援し、生成 AI の力を存分に発揮できるよう尽力しています。 Dr. Mehdi Noori は AWS Generative AI Innovation Centerのシニアサイエンティストです。サステナビリティ分野で技術とイノベーションを橋渡しすることに情熱を持ち、AWS顧客が生成 AI の可能性を解き放ち、潜在的な課題を迅速な実験とイノベーションの機会に変えられるよう支援しています。スケーラブルで測定可能な先進 AI テクノロジーの実用的な活用に焦点を当て、本番環境への道筋を合理化することで、顧客が持続可能性の目標を達成できるよう手助けしています。 Rahul Sareen は AWS のサステナビリティソリューションおよび GTM (Go-to-Market) の GM です。Rahul は、持続可能性戦略家、GTM 専門家、テクノロジーアーキテクトから成る高いパフォーマンスを誇るチームを持っており、顧客の持続可能性目標 （二酸化炭素排出量の追跡、持続可能な包装やオペレーション、循環経済、再生可能エネルギーなど全般）に向けた優れたビジネス成果を生み出しています。Rahul のチームは、機械学習、ジェネレイティブ AI、IoT などの技術的な専門知識を提供し、持続可能性に関するユースケースの解決を支援しています。

はじめに 生成 AI を搭載したチャットボットは、様々なデータソースからの情報への瞬時のアクセスを可能にし、意思決定を加速し、応答時間を短縮することで、業界全体の生産性向上を推進しています。早いペースで変化する産業環境では、プロセスエンジニア、信頼性の専門家、メンテナンス担当者は、情報に基づいた意思決定を行い、最適なパフォーマンスを維持するために、正確なリアルタイムのオペレーションデータに素早くアクセスする必要があります。しかし、SCADA 、ヒストリアン、IoT (Internet of Things) プラットフォームなどの複雑で、しばしばサイロ化された産業用システムにおいてクエリを実行してデータを取得することは、特に、オペレーションデータがどのように構成され、どのようにアクセスできるかについての知識がない人にとっては困難で時間がかかる場合があります。 生成 AI 搭載のチャットボットにより、さまざまな業務システムや企業データソースから、リアルタイムのアセット情報に自然言語を用いてアクセスできるようになります。 対話型のインタラクションによってデータの取得を簡単にすることができ、生成 AI は作業員がデータ収集に費やす時間を減らし、産業の生産性向上のためにこれまでより多くの時間を使うことができるようになります。このユーザーフレンドリーなチャットボットは、業務システムや企業のさまざまなソースに散在する重要な情報へのアクセスを効率化し、作業員に価値のある運用上のインサイトを提供します。 産業分野でチャットボットを実装するには、産業用データストアから構造化データと非構造化データを参照し、関連する情報を取得するために大規模言語モデル (LLM) を支援するツールが必要になります。この役割を果たすのが、生成 AI で動作するエージェントです。エージェントは、問題を理解するために LLM を使用し、その解決策を立案し、API、データベース、その他のリソースを呼び出してその計画を実行する AI システムです。エージェントはユーザーと複雑なデータシステムとの間のインターフェースとなり、ユーザーが詳細のデータ表現を知らなくても自然言語で質問できるようにします。たとえば、作業現場の従業員は、データがどのように構造化されているかを知らなくても、直近の 1 時間でポンプの最高回転数 (RPM) について尋ねることができます。大規模言語モデル（LLM) 自体は複雑な計算を直接実行することはできませんが、エージェントが効率的なデータ処理向けに設計された産業システムにそれらの処理をオフロードすることで、既存のデータプラットフォームを活用しながら、エンドユーザーは自然言語にてレスポンスを受け取ることができます。 このブログ記事では、開発者に向けて、 Amazon Bedrock で AWS IoT SiteWise と対話可能な会話エージェントを作成するプロセスを紹介します。 AWS IoT SiteWise は、産業機器データを大規模に収集、保存、編成、監視するサービスです。 AWS IoT SiteWise の産業データモデリングと処理機能を活用することで、チャットボット開発者は、さまざまな役割のユーザーが自然言語で重要な運用データにアクセスできる強力なソリューションを効率的に提供することができます。 ソリューションの概要 Agents for Amazon Bedrock を活用し、ユーザーのリクエストを AWS IoT SiteWise 向けの検索に分解するエージェントを構築します。 これにより、クエリの構文やデータの格納方法を知らなくても自然言語でオペレーショナルデータにアクセスすることができるようになります。 たとえば、「 Turbine 1 の現在の RPM 値を教えてください」と質問するだけで、特別なツールやコーディングを行う必要はありません。 このエージェントでは、AWS IoT SiteWise のコンテキスト化レイヤーを利用して産業リソースを直感的に表現しています。 リソースのモデリングの詳細については、 AWS IoT SiteWise の仕組み をご覧ください。 チャットボットインターフェースから、ユーザーが産業用アセットデータにアクセスが必要な自然言語の質問をします。エージェントは、必要なデータを取得するための計画を立てるために、 OpenAPI 仕様 （item 1）を参照します。OpenAPI はエージェントが実行できるクエリを定義している アクショングループ （item 2）を使用し、AWS IoT SiteWise の ExecuteQuery API （item3）を使用する AWS Lambda 関数によって処理されます。 エージェントは、必要なデータを取得できるまで、例えばプロパティ名の問い合わせ、一致する名前の選択、最新の測定値の問い合わせなど、複数のアクションを呼び出します。 要求した運用データが提供されると、モデルは元の質問に対する回答を作成します（item4）。 エージェントの構築 前提条件 このソリューションでは Amazon Bedrock のエージェント を活用しています。現在サポートされているリージョンと基盤モデルのリストについては、 サポートされているリージョンとモデル をご参照ください。Anthropic Claude モデルへのアクセスを有効にするには、Amazon Bedrock で モデルアクセス を有効にする必要があります。このブログで説明されているエージェントは、Claude 3 Haiku に対して設計およびテストされています。 このエージェントでは SiteWise SQL エンジンを使用しており、AWS IoT SiteWise と AWS IoT TwinMaker が統合されている必要があります。AWS IoT SiteWise の ExecuteQuery API 用に AWS IoT TwinMaker ワークスペースを作成するには、 これらの手順 に従ってください。 このエージェントのソースコードは GitHub で入手可能です。 リポジトリをクローンするには、次のコマンドを実行します。 git clone&nbsp;https://github.com/aws-samples/aws-iot-sitewise-conversational-agent Step 1: AWS IoT SiteWise アセットのデプロイ このエージェントでは、AWS IoT SiteWise がデータの保存、モデリング、集約を管理し、Amazon Bedrock がユーザーがリクエストした情報を取得するために、複数のステップからなるアクションを調整して実行します。 はじめに、実際の産業アセットもしくはシミュレートされた産業アセットから AWS IoT SiteWise にデータをストリーミングする必要があります。 AWS IoT SiteWise の開始方法 に従って産業データを取り込み、モデル化を行うか、もしくは AWS IoT SiteWise デモ を使用して 4 基の風車のシミュレートされた風力発電所を起動してください。 Step 3 のインストラクションと Step 4 のサンプル質問は、シミュレートされた風力発電所向けに作成されています。もしご自身のアセットを使用する場合には、ご自身で独自のエージェントインストラクションとテスト質問をご用意ください。 Step 2: アクショングループの定義 Amazon Bedrock では、エージェントを作成する前に、エージェントが実行できるアクショングループを定義する必要があります。 このアクショングループでは、必要なデータを収集する際に、エージェントが AWS IoT SiteWise に対して実行できるそれぞれののクエリを指定します。 アクショングループには以下が必要です。 エージェントが呼び出せる API オペレーションを定義する OpenAPI スキーマ API オペレーションを入力とする Lambda 関数 Step 2.1 OpenAPI 仕様の設計 このソリューションでは、直近のオペレーションからデータを取得するために、エージェントが実行することのできるアクションを記述する、定義済みのパスを持つ API オペレーションを提供します。 たとえば、 GET /measurements/{AssetName}/{PropertyName} パスは、 AssetName と PropertyName をパラメータとして受け取ります。 エージェントがいつ、どのようにアクションを呼び出すのかの記述に注目してください。 開発者は、自身のユースケースにあったアクション (クエリ) を含む適切なパスを schema に追加することができます。 "paths": { "/measurements/{AssetName}/{PropertyName}": { "get": { "summary": "Get the latest measurement", "description": "Based on provided asset name and property name, return the latest measurement available", "operationId": "getLatestMeasurement", "parameters": [ { "name": "AssetName", "in": "path", "description": "Asset Name", "required": true, "schema": { "type": "string" } }, { "name": "PropertyName", "in": "path", "description": "Property Name", "required": true, "schema": { "type": "string" } } ] ファイルに含まれる OpenAPI 仕様を Amazon S3 にアップロードします。バケットとパスをコピーしてください。後の ステップ 3 で必要になります。 Step 2.2: AWS Lambda 関数のデプロイ エージェントのアクショングループは AWS Lambda 関数によって定義されます。 このリポジトリには、 Serverless Application Model (SAM) で構築されたサーバーレスアプリケーションを自動的にデプロイするためのテンプレートが付属しています。 ビルドおよびデプロイするには、 GitHub リポジトリ をクローンし、 template.yaml ファイルが格納されているメインディレクトリから以下のコマンドを実行してください。 sam build --use-container sam deploy --guided プロンプトの指示に従ってデプロイを完了してください。 lambda_handler 関数は、呼び出しから API パスを読み取り、リクエストに応じて次の関数のいずれかを呼び出します。 /measurements/{AssetName}/{PropertyName} パスに定義されているアクションの例を次に示します。ここでは get_latest_value 関数が呼び出され、SiteWise の ExecuteQuery API を使用してユーザー定義のプロパティに対する最新の観測値を取得します。 アクションは、成功および失敗の HTTP ステータスコードを返すように定義できること、エージェントがエラーコードを利用して会話を継続し、ユーザーに詳細を求めることができることを確認してください。 def lambda_handler(event, context): responses = [] try: api_path = event['apiPath'] logger.info(f'API Path: {api_path}') body = "" if api_path == "/measurements/{AssetName}/{PropertyName}": asset_name = _get_named_parameter(event, "AssetName") property_name = _get_named_parameter(event, "PropertyName") try: body = get_latest_value(sw_client, asset_name, property_name) except ValueError as e: return { 'statusCode': 404, 'body': json.dumps({'error': str(e)}) } このエージェントを拡張したい場合、Lambda 関数に新しいメソッドを作成して IoT SiteWise の ExecuteQuery API に自分のクエリを投げ、それらのメソッドを新しいパスにマップすることで拡張することができます。 ExecuteQuery API を使えば、開発者は現在のデータと過去のデータを使って複雑な計算 (集計、値のフィルタリング、メタデータのフィルタリングなど) を実行することも可能です。 Step 3: Amazon Bedrock によるエージェントの構築 Amazon Bedrock コンソールに移動し、 Orchestration の下にある Agents をクリックします。その後、 Create Agent をクリックしてください。 エージェントに分かりやすい名前 (例: industrial-agent ) を付け、モデル (例: Anthropic – Claude 3 Haiku) を選択します。 エージェント定義で最も重要なのは、エージェントにそれが何をするべきかと、どのようにユーザーと対話するべきかを指示するエージェントインストラクションです。エージェントインストラクションのベストプラクティスには次のようなものがあります。 事前に目的と機能を明確に定義する。 語調とフォーマリティレベルを指定する。 曖昧または不完全な質問の扱い方を指示する (例: 説明を求める)。 範囲外の質問に上手く対処する方法を指導する。 考慮すべき特定のドメイン知識やコンテキストを言及する。 AWS IoT SiteWise から風力タービンシミュレーションを Step 1 でデプロイした場合は、次のインストラクションに従うことをお勧めします。エージェントインストラクションは 必須 なので忘れずに実行してください。 You are an industrial agent that helps operators get the most recent measurement available from their wind turbines. You are going to give responses in human-readable form, which means spelling out dates. Use clear, concise language in your responses, and ask for clarification if the query is ambiguous or incomplete. If no clear instruction is provided, ask for the name of the asset and the name of the property whose measurement we want to retrieve.&nbsp;If a query falls outside your scope, politely inform the user Action Groups の下で、 Step 3 で作成した Lambda 関数を選択し、 Step 2.1 で作成した API スキーマを指す S3 URL を入力してください。 もしくは、Bedrock コンソールで直接 API スキーマのテキストを入力することも可能です。 Review and create に進んでください。 Step 4: エージェントのテスト Amazon Bedrock コンソールを使用すると、ユーザーは対話形式でエージェントをテストしたり、各インタラクションの考え方を確認したり、 Advanced prompts を利用して前のステップで自動的に生成された前処理およびオーケストレーションテンプレートを変更することができます。 Amazon Bedrock コンソールでエージェントを選択し、 Test ボタンをクリックしてください。 チャットウィンドウがポップアップ表示されます。 以下のような質問をエージェントを試してみてください: どの風車資産が利用可能ですか ? 風車 1 の特性は何ですか ? RPM の現在値は何ですか ? エージェントは SiteWise からのデータとチャット履歴を使用して推定することができ、正確な名前が与えられていなくても、アセットやプロパティを理解することができます。たとえば、 Turbine 1 を Demo Turbine Asset 1 と認識し、 RPM を RotationsPerMinute と認識します。これを実現するために、エージェントはプランを構築します。利用可能なアセットのリストアップ、プロパティのリストアップ、SiteWise に保存されたアセット名とプロパティ名に基づいてクエリを実行し、ユーザーのクエリと完全に一致しなくても対応できるようにしています。 エージェントからの返答は常に調整することが可能です。 Show trace ボタンをクリックすると、意思決定プロセスを分析し、エージェントの理由付けを理解することができます。 さらに、 Advanced prompts を使って、前処理、オーケストレーション、後処理のステップを編集することで、エージェントの動作を変更することも可能です。 エージェントのパフォーマンスに自信が持てたら、Amazon Bedrock コンソールでエイリアスを作成し、ドラフトバージョンをデプロイします。 Agent details で Create alias をクリックすると新しいバージョンを公開することができます。これによりチャットボットアプリケーションは、AWS SDK の InvokeAgent を使用してエージェントを プログラムで呼び出すことができます。 まとめ このブログで解説した生成 AI エージェントは、産業企業が自社の産業アセットからオペレーションデータと対話できるチャットボットを開発することを可能にしています。 AWS IoT SiteWise のデータコネクタとモデルを活用することで、このエージェントはオペレーションデータの取り込みを容易にし、生成 AI を産業向け IoT ワークロードに統合します。 この産業用チャットボットは、企業情報、機械データ、運用・保守マニュアルなどの専門的なエージェントやナレッジベースとあわせて使用することができます。 このインテグレーションにより、適切な情報を持った言語モデルが提供され、単一のユーザーフレンドリーなインターフェイスを通じて、ユーザーが重要なビジネス上の意思決定を行えるように支援することができます。 次のステップ エージェントの準備ができたら、次のステップは産業用チャットボットのユーザーインターフェースを構築することです。この GitHub リポジトリ を参照することで、生成 AI 対応チャットボットのコンポーネントについて学び、サンプルコードを参照することができます。 著者について Gabriel Verreault Gabriel は AWS のシニアマニュファクチュアリングパートナーソリューションアーキテクトです。グローバルな AWS パートナーと協業し、スマートマニュファクチャリング、OT、サステナビリティ、AI/ML に関するソリューションを定義、構築、普及させています。AWS 入社前は、OSIsoft と AVEVA に勤務し、産業用データプラットフォーム、予知保全、AI/ML と産業用ワークロードの組み合わせ方法に精通しています。 Felipe Lopez Felipe は AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。AWS 入社以前は、GE Digital と SLB に勤務し、産業用アプリケーションのモデリングと最適化に従事していました。 Avik Ghosh Avik は AWS Industrial IoT チームのシニアプロダクトマネージャーで、AWS IoT SiteWise サービスを担当しています。技術革新とプロダクトデリバリーにおいて 18 年以上の経験を持ち、産業用IoT、MES、Historian、大規模なインダストリー 4.0 ソリューションを専門としています。Avik はAmazon IoT サービスのコンセプト作成、リサーチ、定義、バリデーションに貢献しています。 この記事は Gabriel Verreault, Avik Ghosh, Felipe Lopez によって書かれた Querying industrial assets using natural language with AWS IoT SiteWise and Agents for Amazon Bedrock の日本語訳です。この記事は プロフェッショナルサービス本部 シニア IoT コンサルタントの小林が翻訳しました。 <!-- '"` -->

2024 年 6 月 20 日、21 日に幕張メッセにて開催された AWS Summit Japan 2024 にご参加いただいた皆様、ありがとうございました。イベントはお楽しみいただけましたでしょうか。 本記事では、Day 2 に開催された、コスト最適化をテーマとした AWS GameDay ~ Frugality Fest（節約祭り！） ~ の開催概要と結果をご報告いたします。 AWS GameDay とは？ AWS GameDay は、ある課題に対して AWS サービスで解決するための対応力や実装スキルを試すことができる実践形式のワークショップです。3～4 名でチームを結成し、待ち受けるさまざまなトラブルやクエストをクリアしながら最終ミッションの達成を目指します。各クエストをクリアするごとにポイントが付与され、最も多くのポイントを獲得したチームが勝者となります。ゲーミフィケーションされた安全な環境で、楽しみながらさまざまなことを学ぶことができる機会を得られるワークショップです。 開催概要 今回の GameDay は総勢 32 チーム 128 名の方にご参加頂きました。昨年は 16 チーム 63 名での開催でしたので、今年は規模が 2 倍となり、会場は熱気にあふれておりました。当日のチームは、ご来場いただいた順番に 4 名で構成されるランダムなメンバーで編成されました。GameDay で高スコアを生み出す秘訣としてチームプレイ・連携が重要であることがアナウンスされ、ゲームの開始時間までにチームビルディングとして自己紹介、得意分野や経験領域の共有、名刺交換などが行われていました。 シナリオ概要 今回のゲームシナリオとして採用された “Frugality Fest” では、架空のテクノロジースタートアップであるユニコーンレンタル社（Unicorn.Rentals）が、業界で人気を占めていた競合会社である RentMyUnicorns の買収を完了し、ユニコーン業界で世界最大のユニコーン提供会社になったというアナウンスから始まりました。 図1 : オープニング説明の様子 しかし、買収した RentMyUnicorns は、非常に人気の高いサービスであったため、大量のトラフィックに対応するためにシステムの増強が必要でした。トラフィックが増加するにつれ、インフラコストも増大していきました。このインフラを最適化するためのチームも時間もなく、インフラコストは急激に上昇し、資金が食いつぶされている状況でした。この日、めでたくユニコーンレンタル社の優秀な新入社員としてご入社された参加者の皆様には、 本番環境を円滑に運営しながら総所有コスト（TCO）を削減する というミッションに取り組んでいただきました。 図2: 既存のアーキテクチャ 結果 結果は以下の通りでした。 第 1 位 Kurage（早川 裕志 氏, 福元 駿汰 氏, 白須 光 氏, 須賀 功太 氏) / スコア : 1,042,068 図3 : 第1位 Kurage のみなさま 第 2 位 CFCA（大橋 直弥 氏, 岡部 知樹 氏, 三﨑 和紀 氏, 藤井 皓平 氏) / スコア : 1,022,459 図4 : 第2位 CFCA のみなさま 第 3 位 GOOD TASTE（碇川 和聖 氏, 栗原 舜 氏, 浅見 則彦 氏, 前川 博志 氏) / スコア : 947,777 図5 : 第3位 GOOD TASTE のみなさま 上位に入賞されたチームの皆様、おめでとうございます。上位 3 チームの皆様には、Head of Developer Relations の Kris から、メダルとトロフィーが進呈されました。 図6 : 優勝チームへのトロフィー進呈の様子 今回の GameDay では、比較的よく使われている AWS サービスが多く採用されていたためか、序盤から順調にクエストをクリアしていくチームが目立ち、ランキングが目まぐるしく変わる白熱した対決となりました。残り 30 分の時点で首位に立っていた CFCA チームが逃げ切る展開と思われましたが、最後に Kurage チームが得点を稼ぎ、逆転優勝を遂げました。優勝チームからは、 「今回のゲームを通じて、これまで知らなかったコスト削減の方法を学ぶことができて勉強になった」 とのコメントをいただきました。その他の参加者の方々からも、 「コスト削減というどの組織でも直面するテーマでやりがいがあった」「経験のなかったサービスに触れられる良い機会になった」「今回の GameDay を機に Graviton への移行を検討したい」「Spot インスタンスの活用方法を体験する良い機会となった」 など、具体的な改善に繋げられそうだというコメントもいただき、楽しみながら学んでいただく良い機会になったのではないかと思います。また、 「周りの仲間に助けてもらってよかった」「他社のスーパーエンジニアの操作を見れて刺激になった」 など、当日ランダムで編成されたチームメンバーとのコミュニケーションが刺激になったというコメントも目立ちました。このような交流ができることも GameDay の醍醐味だと思います。ご参加いただいた皆様、ありがとうございました。 今回惜しくも入賞を逃したチームの皆様、もしくは参加してみたい！と思ったエンジニアの皆様、今後もさまざまなイベントで GameDay の開催を予定していますので、機会を見かけましたら奮ってご挑戦ください。 図7 : GameDay 開催中の様子 図8 : GameDay 終了後の集合写真 最後に 当日は、今回実施した GameDay ”Frugality Fest” の開発者である Anthony Kawamoto が来日しており、最後に皆様へメッセージを伝えさせていただききました。 「コスト最適化は皆様の長期的な成功のために重要であるという思いから、このシナリオを開発しました。今日学んだことを会社に持ち帰っていただき、1 つでも適用していただければ嬉しく思います。」 図9 : ”Frugality Fest” の開発者 Anthony Kawamoto それでは、また来年の AWS Summit Japanでお会いできることを楽しみにしています！ 著者について 松尾　亮（Ryo Matsuo） Senior Partner Solutions Architect

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 梅雨のはずですが、連日暑い日が続きますね・・・まだ気温に慣れておらず辛い日々が続きますが。みなさん、体調にお気をつけください。 それでは、先週の主なアップデートについて振り返っていきましょう。 今週は米国の祝日もありアップデートは少なめになっています。 2024年7月1日週の主要なアップデート 7/1(月) AWS Direct Connect announces native 400 Gbps Dedicated Connections at select locations AWS Direct Connectでネイティブ 400Gbpsの専用線接続が提供開始しました。機械学習や大規模言語モデルトレーニング、自動運転車のための先進運転支援システムなど、大規模なデータ転送が必要な場面で400Gbpsの大きな回線は有効です。400Gbpsの接続が可能なロケーションについては こちらの一覧 をご確認ください。 Amazon OpenSearch Ingestion adds support for ingesting data from self-managed sources Amazon OpenSearch Ingestionが自己管理型のOpenSearch, Elasticsearch, Apache Kafkaクラスターをサポートしました。これにより、たとえばLogstashなどの3rd Partyツールを利用せずにAmazon OpenSearch Serviceにデータ移行や複製が可能になります。この機能は、Amazon OpenSearch Ingestion が現在利用できる東京を含む15のリージョンで利用可能です。詳細については、Amazon OpenSearchの ドキュメント をご確認ください。 RDS for PostgreSQL supports PL/Rust crates serde, serde_json, regex, and url Amazon RDS for PostgreSQLのPL/Rust cratesにserdem serde_json, regex(正規表現), urlが追加されました。これらは全てのAWSリージョンでPostgreSQL 16.3-R2以上, 15.7-R2以上, 14.12-R2以上, 13.15-R2以上のRDS インスタンスで利用可能です。これらの追加以外にも、 Trusted Language Extensions for PostgreSQL (pg_tle)を使ってより多くの拡張を行うことも可能です。 Amazon S3 Access Grants now integrate with Amazon SageMaker Studio Amazon S3 Access GrantsがSageMaker Studioと統合されました。Amazon S3 Access GrantsはIdPやIAMなどでS3のデータへのアクセス権をマッピングし、データアクセスやガバナンス向上ができる機能です。今回の統合によりJupyterLab ノートブックからMLのトレーニングなどでアクセス権を管理しつつS3のデータ利用することがより簡易にできるようになります。この機能はSageMaker Studioが使えるすべてのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon S3 Access Grants now integrate with open source Python frameworks 一つ前のアップデートのSageMaker Studioに加え、AWS SDK for Python (Boto3)を使用してオープンソースの Python フレームワークに関してもAmazon S3 Access Grantsと統合されました。アプリケーションやSageMaker以外のJupyterLab ノートブックでDjango、TensorFlow、NumPy、PandasのPythonのオープンソースフレームワークを使う際もこの機能を利用することでより容易に安全を担保しながらS3上のデータを利用可能になります。この機能はIAM Identity Centerが使えるすべてのリージョンで利用可能です。詳細については同じく ドキュメント をご確認ください。 7/2(火) Elastic Fabric Adapter (EFA) now supports cross-subnet communication Elastic Fabric Adapter（EFA）が同じアベイラビリティーゾーン(AZ)内のサブネット間通信をサポートしました。ハイパフォーマンスコンピューティング(HPC)や機械学習など高速なネットワークを必要とするワークロードで、より柔軟なネットワーク設計が可能になります。この機能は、すべての AWS 商用リージョン、AWS GovCloud (米国) リージョン、Sinnet が運営する北京リージョン、および NWCD が運営する寧夏リージョンで利用で利用可能です。EFAの詳細については、 ドキュメント をご確認ください。 Amazon MQ now supports RabbitMQ version 3.13 Amazon MQでRabbitMQのversion 3.13がサポートされました。これまでのversionのバグの修正とパフォーマンスの向上がされているほか、ブローカーのパッチバージョンアップグレードを管理するようになりました。version 3.13以降の全てのブローカーはメンテナンスウィンドウに互換性のある最新の安全なバージョンに自動アップグレードされます。Amazon MQ for RabbitMQのversion 3.8, 3.9, 3.10のサポートはまもなく終了するため、これらのバージョン、またこれら以外のバージョンに限らず早めのアップデートをお勧めします。 RDS for Db2 now supports Private Offers on licensing through AWS Marketplace AWS Marketplace経由でAmazon RDS for Db2のライセンスを利用する際に、プライベートオファーを適用できるようになりました。これまで、AWS Marketplaceの公開価格、もしくはBYOLの二択でしたが、今回のアップデートにより、Marketplaveを通じてIBMに個別見積もりのリクエストが可能になります。AWS Marketplace ライセンスオプションの詳細については、 ドキュメント にアクセスして開始してください。 ※現時点では、日本のAWSアカウントからはまだRDS for Db2のライセンスをマーケットプレイスで購入できるようになっていないためご注意ください。 7/3(水) Amazon Q Developer is now generally available (GA) in the Visual Studio IDE AWS Toolkit extensionとして利用可能なVisual Studio IDEでのAmazon Q Developer利用がGAしました。Amazon Q Developerは技術的な質問への回答、コード生成、コード説明のほか、セキュリティ脆弱性(C#のみサポート)のスキャン等が可能です。使用するにはVisual Studio 2022に無料のAWS Toolkitをダウンロードしてください。詳細は ドキュメント をご確認ください。 AWS Launch Wizard now adds programmatic deployments through APIs and Cloudformation templates AWS Launch WizardがAPIやCloudFormationを使用したプログラムでのデプロイに対応しました。AWS Launch Wizardは、Microsoft SQL Server Always OnやHANAベースのSAPシステムなどのサードパーティアプリケーション用にAWSリソースのサイジング、設定、デプロイをガイド付きで行うことができるサービスです。今回のアップデートではAPI, CloudFormation対応のほか、アプリケーション仕様をプログラムで取得するAPIも導入され、デプロイ作業がより簡単になります。東京を含む29のリージョンで利用可能です。 詳細については Launch Wizard ユーザーガイド と API ページ をご覧ください。 Amazon DataZone introduces fine-grained access control Amazon DataZoneでデータ所有者が行レベル、列レベルでのデータ制御が可能になりました。これにより、地域に応じてアクセスできる行をフィルターすることや、個人を特定できる情報（PII）などの機密性の高いデータをフィルターするなど、subscribersに必要な情報のみアクセスさせることが可能です。この機能はAWS Lake Formation と Amazon Redshift双方に対して制御されます。行・列レベルのきめ細やかな制御は東京を含む１４のリージョンで利用可能です。詳細については ドキュメント をご覧ください。 7/4(木) アップデートはありませんでした 7/5(金) アップデートはありませんでした イベント情報がいくつか出ていますが、直近で AWS 初心者向けイベントである AWS Builders Online Series が7/18に開催されます。 「AWS 基礎」「生成 AI」「モダンアプリケーション開発」がテーマになっていますので、ぜひご参加ください。 また、先月開催された AWS re:Inforce 2024のre:Capイベント が7/26に開催されます。 AWS最大のセキュリティカンファレンスを日本語で振り返ることができる機会です。合わせてぜひ参加・ご活用いただけると幸いです。 それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本記事は、2024年7月2日に投稿された Improve productivity when processing scanned PDFs using Amazon Q Business を翻訳したものです。翻訳は Hiroaki Hattori が担当しました。 Amazon Q Business は、生成 AI 対話アシスタントであり、企業のデータソースに格納されたデジタルコンテンツだけでなくスキャンした PDF からも、事前のテキスト抽出をせずとも直接質問に答えたり、要約を作成したり、コンテンツを生成したり、インサイトを発見することが可能になりました。 金融、保険、ヘルスケア、ライフサイエンスなど、さまざまな業界の顧客は、領収書、ヘルスケアプラン、税務申告書などのさまざまな種類のドキュメントからインサイトを得る必要がありますが、これらのドキュメントは、 PDF でスキャンし保存していることが多いです。さらにそのドキュメント形式は、半構造化または非構造化されたフォーマットになっているため、Amazon Q Business でインデックス化する前に、ドキュメントからテキストを抽出する処理が必要でした。 Amazon Q Business のスキャンした PDF のサポート開始により、Amazon Q Business が対応する AWS リージョンにおいて、 AWS マネジメントコンソール や API を介し、さまざまな種類のドキュメント形式をシームレスに処理できるようになります。スキャンした PDF を含むドキュメントを、 サポートされるコネクタ を使用してデータソースから取り込み、インデックス化することで、企業のデータを安全に活用し、質問に回答したりコンテンツを生成できます。この機能により、Amazon Q Business とは別で対応が必要であったスキャンした PDF からテキストを抽出するための開発作業が不要となり、Amazon Q Business を使用した生成 AI アシスタントを作成する際の一連のドキュメント処理フローが改善されます。 この記事では、Amazon Q Business を使用し、スキャンした PDF ドキュメントを非同期でインデックス化、リアルタイムでクエリを実行する方法を説明します。 ソリューション概要 スキャンした PDF ドキュメントを Amazon Q Business で使うには、コンソール、 AWS SDK 、または AWS Command Line Interface (AWS CLI) のいずれかが利用できます。 Amazon Q Business は幅広いデータソースと統合できるデータコネクタを提供しており、最小限のセットアップと設定で生成 AI ソリューションを作成できます。詳細については、 生成 AI を使用して従業員の生産性向上を支援する Amazon Q Business の一般提供開始 &nbsp;をご覧ください。 Amazon Q Business アプリケーションを利用する準備ができたら、コンソールまたは API を使用して、スキャンした PDF ファイルを Amazon Q Business のインデックスに直接アップロードできます。Amazon Q Business はマルチデータソースコネクタを提供しており、複数のデータリポジトリのデータを 1 つのインデックスに統合・同期することができます。この記事では、ドキュメントを使用する 2 つのシナリオを例示します。1 つは直接ドキュメントをアップロードする方法、もう 1 つは Amazon Simple Storage Service (Amazon S3) コネクタを使用する方法です。他のデータソースからドキュメントを取り込む必要がある場合は、 サポートするコネクタ を参照して、追加のデータソースを接続する方法の詳細を確認してください。 ドキュメントのインデックス作成 この記事では、スキャンした PDF ドキュメントとして請求書、健康保険の概要、雇用確認書という 3 つのドキュメントといくつかのテキストドキュメントを使用します。 最初のステップは、これらのドキュメントをインデックス化することです。Amazon Q Business の直接アップロードする機能を使用してドキュメントをインデックス化するには、以下の手順を実行してください。この例では、スキャンした PDF ドキュメントをアップロードします。 Amazon Q Business コンソールで、ナビゲーションペインから Applications &nbsp;を選択し、アプリケーションを開きます。 Add data source &nbsp;を選択します。 Upload Files &nbsp;を選択します。 スキャンした PDF ファイルをアップロードします。 アップロードしたファイルは Data Sources タブで確認できます。 Upload Status は、 Received から Processing に変わり、最終的に Indexed または Updated になります。この時点で、ファイルが Amazon Q Business のデータストアに読み込まれたことになります。次のスクリーンショットは、正常に読み込まれた PDF の例を示しています。 以下のステップは、Amazon Q Business で Amazon S3 コネクタを使用してドキュメントを統合・同期する方法を示しています。この例では、テキストドキュメントをインデックス化します。 Amazon Q Business コンソールで、ナビゲーションペインから Applications を選択し、アプリケーションを開きます。 Add data source を選択します。 コネクタとして Amazon S3 を選択します。 Name、VPC 、security group setting、IAM ロール、 Sync mode &nbsp;の情報を入力します。 データソースを Amazon Q Business に接続するため、 Add data source を選択します。 コネクタの詳細ページの Data source details セクションにおいて、 Sync now を選択することで、Amazon Q Business がデータソースからのデータの同期 (クロールと取り込み) を開始できます。 同期ジョブが完了すると、データソースを利用できるようになります。次のスクリーンショットは、5 つのドキュメント (スキャンされた PDF、デジタル PDF、テキストファイル) がすべて正常にインデックス化されたことを示しています。 次のスクリーンショットは、直接アップロードしたドキュメントと、Amazon S3 コネクタを通して取り込まれたドキュメントという2 つのデータソースに関する情報を示しています。 それでは、Amazon Q Business を使って、データソースに対してクエリを実行してみましょう。 スキャンされた PDF の情報量が多く、非構造化であるドキュメントに対するクエリ スキャンした PDF ドキュメントが情報量が多く、構造化されていないとします。Amazon Q Business は、非常に情報が込み入ったテキストであってもドキュメントを認識し情報を抽出します。この例では、先ほどインデックス化した複数ページの健康保険プラン概要の PDF を使用します。次のスクリーンショットは、その 1 ページを示しています。 これは健康保険プラン概要の一例です。 Amazon Q Business Web UI では、「What is the annual total out-of-pocket maximum, mentioned in the health plan summary?（健康保険概要プランに記載されている年間自己負担上限総額はいくらですか?）」と質問しています。 Amazon Q Business はインデックス化されたドキュメントを検索し、関連する情報を検索して回答を生成し、その情報のソースを引用します。次のスクリーンショットにサンプル出力を示します。 スキャンした PDF が構造化されており、表形式であるドキュメントに対するクエリ ドキュメントには表形式の構造化データが要素として含まれる場合もあります。Amazon Q Business はスキャンした PDF から構造化データを自動的に特定、抽出し、ユーザーからの質問に正しく回答することができます。次の例では、事前にインデックス化した請求書 の PDF を使用しており、スクリーンショットはその PDFの 1 ページを示しています。 これは請求書の一例です。 Amazon Q Business Web UI では、「How much were the headphones charged in the invoice?（請求書でヘッドフォンの請求金額はいくらでしたか?）」と質問しています。 Amazon Q Business はインデックス化されたドキュメントを検索し、情報源となるドキュメントを参照して答えを取得します。次のスクリーンショットは、Amazon Q Business が請求書から課金情報を抽出した回答例を示しています。 半構造化されたフォームに対するクエリ ドキュメントには、キーと値のペアといったフォーム形式で半構造化データが含まれている可能性があります。Amazon Q Business では、クエリに関係する特定の項目や属性を取り出すことにより、これらのデータに関連するクエリに正しく回答することができます。次の例では雇用確認書の PDF を使用しており、スクリーンショットは、そのドキュメント例です。 これは雇用確認フォームの一例です。 Amazon Q Business Web UI では、「What is the applicant’s date of employment in the employment verification form?（雇用確認書にある求職者の雇用開始日はいつですか?）」と質問します。Amazon Q Business はインデックス化された雇用確認書を検索し、ソースドキュメントを参照しながら回答します。 AWS CLI を使用したドキュメントのインデックス作成 このセクションでは、AWS CLI を使用して、S3 バケットに格納されている構造化ドキュメントと非構造化ドキュメントを Amazon Q Business インデックスに取り込む方法を説明します。ドキュメントの詳細情報 (ステータスやインデックス作成中のエラーなど) をより早く取得できます。もし、PDF ファイルやその他のサポートされているファイル形式でインデックス化したドキュメントを保持する既存の Amazon Q Business ユーザ であり、スキャンしたドキュメントを再インデックス化したい場合は、以下の手順を実行してください。 それぞれのドキュメントのステータスを確認することで、ステータスが "DOCUMENT_FAILED_TO_INDEX" のような失敗したドキュメントを絞り込むことが出来ます。また、次のエラーメッセージに基づいてドキュメントを絞り込むことも可能です。 "errorMessage": "Document cannot be indexed since it contains no text to index and search on. Document must contain some text." 新しいユーザーでまだドキュメントをインデックスしていない場合は、このステップを省略できます。 以下は、 ListDocuments API を使用して、あるステータスのドキュメントとそのエラーメッセージを絞り込む例です: aws qbusiness list-documents --region &lt;region&gt; \ --application-id &lt;application-id&gt; \ --index-id &lt;index-id&gt; \ --query "documentDetailList[?status=='DOCUMENT_FAILED_TO_INDEX'].{DocumentId:documentId, ErrorMessage:error.errorMessage}" \ --output json 次のスクリーンショットは、AWS CLI の出力を示しており、エラーメッセージとともに失敗したドキュメントの一覧が表示されています。 今度はドキュメントをバッチ処理します。Amazon Q Business では、Amazon Q Business インデックスに 1 つまたは複数のドキュメントを追加できます。 BatchPutDocument API を使用して、S3 バケットに格納されている複数のスキャンされたドキュメントをインデックスに取り込みます。 aws qbusiness batch-put-document --region &lt;region&gt; \ --documents '[{ "id":"s3://&lt;your-bucket-path&gt;/&lt;scanned-pdf-document1&gt;","content":{"s3":{"bucket":"&lt;your-bucket&gt; ","key":"&lt;scanned-pdf-document1&gt;"}}}, { "id":"s3://&lt;your-bucket-path&gt;/&lt;scanned-pdf-document2&gt;","content":{"s3":{"bucket":" &lt;your-bucket&gt;","key":"&lt;scanned-pdf-document2&gt;"}}}]' \ --application-id &lt;application-id&gt; \ --index-id &lt;index-id&gt; \ --endpoint-url &lt;application-endpoint-url&gt; \ --role-arn &lt;role-arn&gt; \ --no-verify-ssl 次のスクリーンショットは、AWS CLI の出力を示しています。失敗したドキュメントのリストが空になっていることがわかります。 最後に、 ListDocuments API を再度使用して、すべてのドキュメントが正しくインデックス化されたかを確認してください: aws qbusiness list-documents --region &lt;region&gt; \ --application-id &lt;application-id&gt; \ --index-id &lt;index-id&gt; \ --endpoint-url &lt;application-endpoint-url&gt; \ --no-verify-ssl 次のスクリーンショットは、ドキュメントがデータソースでインデックス化されていることを示しています。 クリーンアップ 新しい Amazon Q Business アプリケーションを作成した後、それ以上使用する予定がない場合は、アプリケーションから割り当てられたユーザーを削除し、サブスクリプションを解除してアプリケーションを削除することで、AWS アカウントに追加コストが発生するのを防ぎます。また、インデックス化されたデータソースをこれ以上使用する必要がない場合は、 Managing Amazon Q Business data sources を参照し、インデックス化されたデータソースを削除する手順をご確認ください。 まとめ この投稿では、Amazon Q Business でスキャンされた PDF ドキュメントのタイプがサポートされていることを示しました。これによって、生成 AI と Amazon Q Business を使用して、スキャンした PDF を含むサポートするドキュメント形式に対して、同期、インデックス作成、クエリを実施する手順を確認しました。また、Amazon Q Business の Web UI と AWS CLI を使用して、構造化、非構造化、または半構造化の、マルチモーダル化されたスキャン済みドキュメントに対するクエリの例を示しました。 この機能の詳細については、 Amazon Q Business でサポートされるドキュメントの形式 を参照してください。今すぐ Amazon Q Business コンソール で試してみましょう! 詳細については、 Amazon Q Business と Amazon Q Business ユーザーガイド を参照してください。フィードバックは Amazon Q の AWS re:Post または通常の AWS サポート連絡先からお送りいただけます。 著者について Sonali Sahu&nbsp; は、AWS で 生成 AI スペシャリストソリューションアーキテクトチームをリードしています。彼女は著者、思想家、そして情熱的な技術者です。彼女の注力領域は AI と ML であり、世界中の AI と ML の会議やミートアップで頻繁に講演しています。彼女は技術と技術業界の両方で幅広く深い経験を持っており、医療、金融、保険などの業界の専門知識を持っています。 Chinmayee Rane&nbsp; は、AWS で生成 AI スペシャリストソリューションアーキテクトです。彼女は応用数学と機械学習に情熱を注いでいます。彼女は、AWS 顧客向けのインテリジェントドキュメント処理と Generative AI ソリューションの設計に注力しています。仕事以外では、サルサとバチャータダンスを楽しんでいます。 Himesh Kumar は、経験豊かなシニアソフトウェアエンジニアで、現在 AWS のAmazon Q Business に在籍しています。生成 AI および ML 分野の分散システムの構築に情熱を注いでいます。スケーラブルで効率的なシステムを開発し、高い可用性、パフォーマンス、信頼性を確保するのが得意分野です。技術的な能力に加えて、継続的な学習に努め、AI および機械学習における技術の最前線にいることを目指しています。 Qing Wei は、AWS の Amazon Q Business チームのシニアソフトウェア開発者であり、AWS テクノロジーを使用して最新のアプリケーションを構築することに注力しています。彼は、機械学習のホスティングと推論に関連するトピックについて、コミュニティ主導の学習と技術の共有に興味があります。現在は、RAG データ取り込みのためのサーバーレスおよびイベント駆動のアーキテクチャの構築に焦点を当てています。

本ブログは、株式会社セゾンテクノロジー データインテグレーションエンジニア 石原直樹氏 と アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 藤原、田原 が共同で執筆いたしました。 はじめに セゾンテクノロジー は、「世界中のデータをつなぎ、誰もがデータを活用できる社会を作る」というミッションを掲げています。自社製品である「HULFT（ハルフト）」は、国内外で広く活用されるデータ連携製品へと進化し、近年はポートフォリオをさらに拡充させています。昨今急速に進化をしている生成 AI は企業ミッションとも親和性が高く、セゾンテクノロジー内では個人やプロジェクト、チーム単位で活用方法を模索する動きが活発化していました。そこで、各部門に分散していた生成 AI の知見を集約し発展を加速させるため、全社横断的な研究会である LLM Mavericks を設置し、生成 AI の研究や活用に取り組んでいます。 本ブログでは、LLM Mavericks の活動の一環として、 Amazon Bedrock を活用した AI チャットボットを HULFT 製品のテクニカルサポートセンターに導入した事例について解説します。なお、本事例は 2024 年の AWS Summit Japan の基調講演でも取り上げられました。 導入背景 HULFT 製品のテクニカルサポートセンターでは、サポートエンジニアはお客様からの問い合わせに対し、数万ページにも渡るマニュアルや FAQ、及び、膨大な過去の問い合わせ履歴から必要な情報を検索して回答を作成しており、若手のサポートエンジニアのスキル育成や、回答作成時の心理的負担を軽減したいことから、検索の効率化を検討していました。 本課題を解決するために、セゾンテクノロジーは Amazon Bedrock を活用した Retrieval-Augmented Generation (RAG) の仕組みを構築しました。 これにより、RAGシステムが問い合わせ内容から自動的に関連情報を抽出し回答案を生成するため、エンジニアは複数のサイトを横断したり、適切な検索クエリを考えたりする負担が軽減されます。さらに、検索結果の内容を精査し回答を一から作成する必要がなくなるため、業務効率が向上し、エンジニアの心理的負担も軽減されると期待しました。 図1：RAGシステム導入前後のテクニカルサポート業務フロー比較 ソリューション / 開発における工夫 AWS を活用して RAG の仕組みを構築するには、下図に示すように複数のパターンを取ることができます。それぞれの手法で開発の自由度や開発の容易さ、運用の負荷などが変わってきますが、AWS はお客様のユースケースに応じて最適なサービスを選択できるように様々な選択肢を用意しています。 図 2: AWS サービスを活用した RAG の実装アプローチ 開発当初は、 Amazon Kendra や Knowledge Bases for Amazon Bedrock を活用し検証していましたが、サポートエンジニアから「質問への回答に関係のない情報が含まれる」というフィードバックがありました。分析の結果、Knowledge Bases for Amazon Bedrock のベクトル検索では、HULFT製品特有の単語や文章を、正しくベクトル検索できていないことが判明しました。一方、Amazon Kendraでは、日本語の分かち書きの精度が不十分であったり、また、検索結果の取得トークン数の制限により、文脈の断片化が起こるという課題がありました。 これらの問題に対処するため、ベクトル検索だけでなく、日本語の分かち書きが得意なsudachiトークナイザーを利用したキーワード検索も導入しました。さらに、検索対象のドキュメントを階層的にチャンク分割し、検索時には粒度の細かいチャンクを用いて高精度な検索を行い、その後関連する上位階層のチャンクを取得することで、文脈を保持する方式を採用しました。さらに、複雑な質問に対応するため、Large Language Model (LLM)によるクエリ拡張の手法を取り入れました。このように、フィードバックを元に段階的な改善を重ねながら開発を進めていきました。 現在のアーキテクチャは以下の図の通りで、サーバーレスアーキテクチャを採用しています。ドキュメントおよびアプリケーション、ライブラリは、すべてコンテナイメージとして Amazon Elastic Container Registry に格納しています。これらのイメージは AWS Lambda によってPullされ、実行環境として使用されます。 では、お客様からの問い合わせをきっかけに、RAGシステムがどのように回答を生成するかを見ていきましょう。お客様から問い合わせがあった際に、サポートエンジニアが Slack 上で AI チャットボットに質問内容をメンションします。投稿された質問文から、 Anthropic Claude 3 Haiku によりキーワードや類似語が抽出され、複数の検索クエリが生成されます（クエリ拡張）。生成されたクエリを元に、まずキーワード検索を行い、キーワードに関連するドキュメントをN件に絞り込みます。次に、階層化されたチャンク構造のベクトルDB（FAISS）に対して、ベクトル検索を実行し、意味的に関連するドキュメント上位K件に絞り込みます。最後に、絞り込まれたドキュメントを基に、Cohere Command R+ により回答が作成され、Slack で回答が返ってきます。 図 3:RAGシステムのアーキテクチャ図 このように、 Advanced RAG に分類される手法を導入しています。これらの処理の組み合わせにより、検索精度と文脈保持を両立し、Amazon Kendraを活用したRAGと比較して14%、Knowledge Bases for Amazon Bedrockと比較して22%の回答精度向上を達成しました。 複数モデルでの検証の結果、クエリの生成には、日本語の理解と生成に優れており、高速な応答性能を示した Anthropic Claude 3 Haiku を採用しました。回答の生成は、RAG の用途に最適化された機能を持つ Cohere Command R+ を採用したことで、開発時に複雑な処理を必要とせず、説明可能性が高い回答を得られるようになりました。 また、本事例の特徴として、 Guardrails for Amazon Bedrock の機能を組み込んで責任ある AI チャットボットを構築していることが挙げられます。具体的には、製品のシリアル番号などの特定の機密情報の入力を制限するルールを設定することで、AI チャットボットをより安全に活用できる環境を簡単に整備できました。 導入効果 本RAGシステム導入により、サポートエンジニアの回答作成時間は最大で 30 % 短縮されました。若手のサポートエンジニアだけではなく熟練したサポートエンジニアにも導入の効果があり、テクニカルサポートセンター全体でみると、導入前と比較して約 10 % 業務が効率化されています。さらに、サポートエンジニアの半数以上からは、回答作成時の心理的負担が軽減したといったフィードバックも得られています。 また、サーバーレスアーキテクチャを採用したことで、システムの運用負荷を大幅に削減し、かつ、サポートエンジニアからの質問 1,000 件あたり 30 ドル以下の低コストを実現しています。 まとめ 本ブログでは、セゾンテクノロジーによる、Amazon Bedrock を活用したRAGシステムの HULFT 製品のテクニカルサポートセンターへの適用事例について紹介しました。Amazon Bedrock では、複数の基盤モデルを用途に応じて選択できること、Guardrails for Amazon Bedrock でポリシーに基づいたデータの制御ができることなど、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供しています。本事例はそのような Amazon Bedrock のメリットを活かしており、これから生成 AI アプリケーションの構築を検討されるお客様のご参考になれば幸いです。 セゾンテクノロジーは、今後の展開としてAgents for Amazon Bedrockの導入を計画しています。この導入により、利用者からの質問内容を事前に分析して不適切な内容をブロックする機能や、必要に応じて利用者に追加の質問を行う機能を取り入れることで、より安全で正確な回答の生成を目指しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 7月になりましたので、AWS公式ウェブマガジン” builders.flash “で新しい記事が公開されましたので、今月も生成AIに関連するものをピックアップしてみましょう。 Amazon Bedrockを活用して3Dキャラクターと対話するサービスを構築する(ピクシブ株式会社様) ガーデニングの新時代!Amazon Bedrock で理想の庭を実現してみた ~GreenSnap株式会社による生成AI実装解説~(GreenSnap株式会社様) 生成AIで飲みニケーション対策!無料の生成AIプレイグラウンドPartyRockで新入社員がアプリを作ってみた! ひとつめの記事は ピクシブ株式会社 様に寄稿いただいたものです。ピクシブ株式会社様は3Dキャラクターと対話ができるサービス、「 ChatRoid 」を提供していますが、そのなかで Amazon Bedrock をご利用頂いています。この記事ではアーキテクチャとその選定理由が紹介されています。 ふたつめの記事は GreenSnap株式会社 様によるもので、 Amazon Bedrock を利用した画像加工の新サービス、「 gardenAI 」について紹介しています。このサービスは生成AI技術を利用して庭や外構をリアルにデザインするサービスで、実際の写真を加工することが可能だそうです。 Amazon Titan Image Generator G1 を画像生成に、プロンプト生成にAnthropicのClaude 3 Haikuを利用していますので、この利用例にも注目です。 みっつめの記事は、 PartyRock でアプリを作るというテーマですが、会話形式のストーリーにまとめられているので気軽に読んでいただけます。PartyRockは気軽に生成AIアプリケーションを作る体験ができるツールですが、どう使ったらいいかイメージが湧かないという方もいらっしゃいます。この記事を見ていただくと、PartyRockでアプリケーションを作る流れをつかめるので、ぜひどうぞ。 それでは、7 月 1 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: AI Inside株式会社様、セキュアな生成AI環境で対応可能な帳票の大幅な拡充に成功 AI Inside株式会社 様は、AIエージェント「 Heylix 」やAI-OCRサービス「 DX Suite 」に加え、それを支えるAIインフラ「 AnyData 」「 AI inside Cube 」を提供しています。これまで手入力が必要だった帳票処理をデジタル技術で効率化するのがAI-OCRを提供するDX Suiteですが、書類はフォーマットが統一されていないものも多く、モデル学習が必要になるケースがあり、その対応には約2,000万円の費用と1ヶ月以上の期間が必要という課題がありました。この課題に対してLLM(大規模言語モデル)による解決にチャレンジし、サービス開始から7年間の期間で13種類が提供されるにとどまっていた非定型帳票対応用のプリセットが、3ヶ月間で1,000種類を超えるという成果を上げています。これを支えたのは Amazon Bedrock です。推論データがモデル学習に再利用されない事に加えて、 Amazon EKS(Elastic Kubernetes Service) で稼働するアプリケーションから AWS PrivateLink でよりセキュアな接続が可能な点がポイントとなりました。 ブログ記事「Amazon Bedrock Claude 3.5 Sonnetを活用して大学レベルの専門知識を必要とする工学的問題を解く」を公開 AnthropicのClaude 3.5 Sonnetが発表され、 Amazon Bedrock でも用途に応じて選べるモデル選択肢のひとつとして、米国リージョンでご利用頂けるようになっています。この記事では、機械設計を例にとって機械力学・材料力学・熱力学・流体力学の知識が必要な問題をClaude 3.5 Sonnetを活用して解決することが可能な例をご紹介しています。生成AIは完全ではありませんので、問題が複雑になればなるほど誤答の可能性も高まります。ですがそれを前提に、熟練者に対して手がかりとなる参考情報を素早く与えてくれるという見方をすれば、日々の業務に活用できる部分もかなり存在するのではないでしょうか。 ブログ記事「生成AIを圧要して工場の稼働率低下の原因分析を行う」を公開 6月20日21日に開催した AWS Summit Japan では、生成AIの活用に向けたたくさんのアイデアを展示しました。その中でも人気があったもののひとつが、ミニチュア組立工場を動かしながらスマート工場における生成AIの活用ケースのデモです。このブログ記事では、このデモのなかから「工場の稼働率低下の原因分析を生成AIで実現」というトピックにフォーカスしてご紹介しています。コンセプトやアーキテクチャの詳細な解説をしていますので、みなさんの業務への応用のヒントになるのではないでしょうか。 ブログ記事「スマートシティ向けの早期火災検知設計モデル: AWS IoTおよびMLテクノロジーの活用」を公開 生成AI活用のど真ん中、という訳ではないのですが、生成AIを実生活に取り込む上でのヒントになりそうだなと思ったのでピックアップした記事です。このブログ記事は、AWS IoTを活用してデータを収集し分析することで火災の発生を早期に検知するとともに、データに基づいて機械学習モデルを利用することで火災予測を可能にするアイデアを解説しています。この記事は「スマートシティの火災」に焦点を当てていますが、交通網の改善や環境問題への対策など、同じ考え方を適用できる領域は多岐にわたります。もしかすると、ビルや工場の管理にも応用できるかも知れませんので、ご興味がありましたらぜひご一読ください。 ブログ記事「LLMの埋め込み情報ドリフトをAmazon SageMaker JumpStartから監視する」を公開 多くのお客様が取り組んでいる検索拡張生成(RAG)についての理解を深め、精度向上のための打ち手を考えるヒントに成り得るブログ記事です。RAGではドキュメントを埋め込みベクトル(Embeddings)で表現しデータベースに格納、ユーザからの問い合わせと関連性の高いものを検索します。そのため、埋め込みベクトルの変化(この変化をドリフトと呼びます)の有無を測定することで、より高精度なアプリケーションを実現するための打ち手の要否を判断する事につながります。実際に手元で試せるような構成になっていますので、ぜひ時間を取って試してみてください。 サービスアップデート Visual Studio IDEにおけるAmazon Q Developerが一般利用開始に Visual Studio IDEにおいて Amazon Q Developer が一般利用開始になりました。Amazon Q Developerは技術的な質問に答える、コードを生成する、既存コードを説明する、といった機能を通じてソフトウェア開発をシンプルにします。例えば、「Lambda関数をAWSにデプロイする前にローカルでデバッグする方法は？」「この関数に対するテストケースを生成して」といったリクエストに応えることができます(現時点では英語を正式サポート)。この機能はVisual Studio IDEの拡張機能であるAWS ToolkitにAmazon Q Developerが組み込まれている、という形で提供されます。 Amazon SageMaker StudioがAmazon S3 Access Grantsとの統合が可能に Amazon S3 Access Grants は、Active DirectoryをはじめとするIDプロバイダの情報や、AWS IAMのプリンシパル情報に基づいてAmazon S3のオブジェクトに対するアクセス権を自動的に付与する仕組みで、データアクセスのガバナンス向上に活用できる機能です。今回、Amazon SageMaker StudioからAmazon S3 Access Grantsを利用したデータアクセスができるようになり、データアクセスが容易になるとともに「最小権限の原則」を実装しやすくなります。 Amazon EKSがEC2 capacity blocks for MLをネイティブにサポート マネージド型ノードグループを利用している Amazon EKS のクラスタで、 EC2 capacity blocks for ML で確保されたインスタンスをネイティブに利用できるようになりました。EC2 capacity blocks for MLは機械学習ワークロード向けにGPUインスタンスを予約できる仕組みです。Kubernetesを利用してAI/MLワークロードを実行している方が、リソース確保とその利用をするのが容易になるアップデートです。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田と新澤です。 AWS Summit Tokyo が 2024 年 6 月 20 日（木）、21 日（金）の 2 日間、幕張メッセにて開催されました！ 大盛況のまま無事イベントを終えることができました！ 製造業向け展示ブースでどのようなデモが披露されたかについては以下の予告ブログもご参照ください。 AWS Summit Japan 製造業向け展示の見どころ紹介！ 今回はその中から、「製造現場の IoT データをパートナーとともに 小さく早く製造 DX を実現」というタイトルのブースの一部をご紹介します。このブースでは、ミニチュア組立工場を動かしながら AWS を活用したスマート工場の複数のユースケースのデモを行いました。この中から「 生成 AI を活用して工場の稼働率低下の原因分析を行う 」というユースケースにフォーカスして解説させていただきます。 デモ全体像 図1~3に ミニチュア組立工場 外観図や、全体における生成 AI を活用した工場の稼働率低下原因分析の位置付けを示しました。 図1 ミニチュア組立工場外観図 図2 「製造現場の IoT データをパートナーとともに小さく早く製造 DX を実現」ブースのユースケースオーバービュー 図3 「製造現場の IoT データをパートナーとともに小さく早く製造 DX を実現」ブースのアーキテクチャオーバービュー 生成 AI を活用して工場の稼働率低下の原因分析を行うユースケースシナリオ 図4 には生成AIを活用して工場の稼働率低下原因分析を行う際の想定ユースケースシナリオを示しました。 データを取得することはできているものの、統合的に組み合わせて有効な分析に繋げることができておらず、宝の持ち腐れになってしまっているといった課題はよくあるのではないかと思います。 既に取得できている他の関連データを Amazon S3 に集約して、そういった大量の実データをソースとして、生成 AI の RAG （検索拡張生成） 技術で稼働率の低下原因を分析することで、あるものを活用して小さく早く改善していこうというシナリオになっています。 図4 生成 AI を活用して工場の稼働率低下の原因分析を行う際の構成図とユースケース 図5 には、分析対象となる各種データと Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションのイメージの全体像を示しました。 4M とは、製造業での品質管理において重要な、Man（人）、Machine（機械）、Material（材料）、Method（方法）の4つの要素を指します。 4M 分析のフレームワークは、製造に関わる変更点を洗い出し、把握する手法の一つです。装置が計画外停止した際、その原因が装置そのものの不具合による場合もあれば、材料や部品の投入ミス、急なシフト変更に起因する作業者のオペレーションミス、工程変更が伝わっていなかったなどの情報伝達に起因するミス、厳しすぎる検査規格値など、様々な要因が考えられます。原因分析の際には、これらのどれかに固執することなく、抜け漏れなく要因を検証する必要があります。その際に有効なフレームワークです。 それぞれ、 Man : ERPから取得した作業者情報の csv ファイル Machine : タブレットから取得した日常設備点検簿の excel ファイル Material : 在庫管理システムから取得した csv ファイル Method : 工程管理システムから取得した csv ファイル として Amazon S3 にデータが集約されています。また、 AWS IoT Greengrass 、 AWS IoT SiteWise を介して取得されたデータを ”工場設備の稼働率 CSV” に変換し、それも S3 に格納します。これらの一連の CSV ファイルを RAG の分析対象として扱います。 図5 各種データと Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションイメージ 各種データ 図6~11では各種データの拡大画像およびデータの特徴を示しています。 図6 AWS IoT SiteWise からエクスポートされた raw データを csv に変換した設備稼働率ファイルイメージ 図7 Machine : タブレットから取得した日常設備点検簿の excel ファイル(正常な日)イメージ 図8 Machine : タブレットから取得した日常設備点検簿の excel ファイル(異常な日)イメージ 図9 Material : 在庫管理システムから取得した 4 月分の csv ファイルイメージ 図10 Method : 工程管理システムから取得した 4 月分の csv ファイルイメージ 図11 Man : ERPから取得した 4 月分の作業者情報の csv ファイルイメージ 各種データを見ると、まず設備稼働率 csv ファイルから、4/5 15:00 に稼働率が異常に低下していることがわかります。その日時の少し前に何か異変が見当たらなかったかを 4M ファイルで調べたところ、日常設備点検簿において、該当日時の少し前に空調設備異常があったことがわかります。その他のファイルでは特に異変はありませんでした。 取り扱うデータ量が多いほどこういった様々な事象を人間が分析するのは難しくなります。生成 AI のRAG 技術で効率的に分析してみましょう。 分析 Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションは、AWS が GitHub で提供しているこちらの Generative AI Use Cases JP よりデプロイしました。Generative AI Use Cases JP は、すぐに業務活用できるビジネスユースケース集付きの安全な生成 AI アプリ実装サンプルです。OSS として無償提供しており、生成AIの様々なユースケースを試すことができます。 図12 Knowledge Bases for Amazon Bedrock を取り入れた Web アプリケーションでの RAG チャットの様子 このアプリケーションを用いて、 Knowledge base for Amazon Bedrock と連携した Agents for Amazon Bedrock で RAG を実行します。 RAG （検索拡張生成） とは、ユーザーからの問い合わせに対して、例えば社内のデータソースなどから関連情報を検索し、取得された関連情報も含めてモデルに入力し回答を得るものになります。信頼できる情報源から知識を取り入れることで、生成される応答の事実性と正確性が向上します。単にモデルの出力に頼るのではなく、根拠となる情報を参照できます。 Knowledge base for Amazon Bedrock は、基盤モデルと自社データソースを組み合わせた RAG をフルマネージドで実現可能にします。Knowledge Bases for Amazon Bedrock の仕組みや操作方法の詳細については こちらのブログ をご参照ください。 あらかじめドキュメントデータ(今回の場合は CSV や EXCEL)を DB に検索可能な形（ベクトル表現）で格納しておきます。そして、ユーザーからの問い合わせから、内容の似たドキュメントを検索し、そのドキュメントの内容に基づいて基盤 Text モデルに回答させます。 図13 Knowledge base Amazon Bedrock の RAG のしくみ Amazon Bedrock は様々な種類・数のモデルを提供しており、お客様はユースケースに適したものを選択いただくことができます。今回はそんなモデルの中から、図13 の③、⑤の Embedding モデルには Amazon Titan Text Embeddings v2 を、Text モデルには Claude 3 Sonnet を選択して RAG を実行しています。 Agents for Amazon Bedrock は、API を呼び出しタスクを実行する Agent 機能をフルマネージドで提供しています。基盤モデルを使ってユーザのクエリを理解し、登録された情報を Knowledge Base から検索したり、タスク完了に必要なアクションを実行することができます。 分析を始めます。まず、図12 における一つ目の質問で稼働率が極端に低くなっている日時を抽出してもらいました。すると、図6 を見ても分かる通り、22.0 % と異常に低下した日時が的確に抽出されました。 次に、その日時よりも少し過去に発生した事象から、稼働率が極端に低くなった原因について考察をしてもらいました。参照するファイルについても明確に指定をしています。生成 AI プロンプトエンジニアリング（モデルに入力・指示する文字列であるプロンプトを工夫して書いて、望ましい出力を得るための工夫）について、なるべく曖昧にならないように、簡潔に、明確に、十分な情報を与えることが重要です。 その際、4M 変換点フレームワークを意識してMan（人）、Machine（機械）、Material（材料）、Method（方法）の４種類のデータを網羅的に参照するように指示をすることで 、より精度の高い返答を得られる可能性が高まります。 すると、日常設備点検簿から空調設備にエラーコード 123 が発生したことが原因だという考察を返してくれました。他に大きな異変が確認できないため、この回答も妥当であることがわかります。 ただし、質問内容や検索対象の情報が複雑になるほど RAG で得られる回答の品質は低下する傾向があります。期待通りの回答が得られない場合は、 こちらのブログ で紹介されているようなRAG のパフォーマンスを改善するための手法を試すなどして応答品質の向上を図りましょう。 まとめ このデモのように装置から生成される稼働情報が示す稼働率低下や、生産現場で日々発生する品質問題というのは、あくまで’結果’です。しかし、再発防止策を検討する際には、それらを引き起こした’原因’を突き止める必要があります。その原因は4M（人、機械、材料、方法）のどこかに含まれているだろうという考え方が、このデモの前提となっています。 一方で、実際の製造現場において、このデモのように綺麗に 1 ファイルごとに 4M のそれぞれの M が情報としてまとめられているケースは少ないかもしれません。それでも従来からのフレームワークである 4M 変化点を意識して、プロンプトに参照先を指定することで、より早く原因に辿り着けるのではないか、というのがこのデモの主旨になります。 生成 AI の RAG 技術を活用すれば、PDF や Word ファイルのような様々なデータを対象に、データに基づいて対話的に分析できます。今回は稼働率が極端に低くなっている日時を手動のプロンプト打ち込みで抽出しましたが、稼働率に閾値を設けて、それを下回った場合に自動的にアラートメールを流すようにして、それをキックに Amazon Bedrock に分析依頼をかけるようなパイプラインを構築して自動分析することも可能です。 AWS の様々なサービスと組み合わせてどんどん機能拡張させていくことが可能ですが、まずは初めの一歩として、本デモブースのテーマである「小さく早く製造 DX を実現」することを目標に、対象を小さく絞って PoC (概念実証)を実施し、小さな成功体験を積み重ねて大きな業務変革に繋げていただけますと幸いです。 著者プロフィール 山田 航司 (Koji Yamada) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。 &nbsp; &nbsp; &nbsp; &nbsp; 新澤 雅治 (Niizawa Masaharu) アマゾン ウェブ サービス ジャパン合同会社 IoT スペシャリスト ソリューションアーキテクト 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様のIndustrial IoT 関連案件の支援に携わる。

本稿では株式会社NTTドコモにおいて、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、全4回に分けてご紹介します。この取り組みについて概要をご覧になりたい方は 導入事例ページ もご覧ください。 前回の記事は以下です。 第一回　適切なデータストアの選定とアーキテクチャの見直し 第二回　アクセスの急増に対する対応策〜キャッシュ戦略とバックエンドの保護〜 1.需要予測の難しさとキャッシュ戦略・バックエンドの保護の必要性 システムを設計するにあたり、どの程度リソースを用意するべきか、正確に推測するのは容易なことではありません。ビジネス目標に対応したスケーラビリティを確保しようとするのは通常のことですが、例えば、ある Live 配信のビジネス目標とされる視聴ユーザー数が A人だった場合、それに対応したシステムを作るには何が必要でしょうか？ まず、ビジネスの観点での需要予測を、システムを設計するのに十分な粒度に落とし込む必要があります。システムを設計するのに必要な需要予測は機能別の API ごとの最大ピークアクセスが想定されるべきです。例えば、配信開始時間があらかじめ告知されている Live の場合は、配信開始時間の数分前に視聴開始が集中することが想像できます。そうした場合には視聴開始にまつわる API を視聴ユーザー数 A人が数分間、数秒間といった短い間に実行する可能性があり、そのピークに耐える必要があります。配信開始時間が正確にわからない場合、視聴ユーザーA人はまばらにアクセス開始するかもしれません。配信の特性を踏まえて、過去の同様の配信時の実績データなどを踏まえた知見から予測していくことになります。 また、視聴開始以外の API にスパイクアクセスは必ずしもこないことも考慮すべきです。アプリケーションを初回ダウンロードしてユーザー登録をするための API はライブを見たいユーザーのなかで初回にアプリにアクセスするユーザーだけが実行する処理となり、ライブ直前に行う必要がある処理ではありません。事前にアプリをダウンロードし登録を済ませてくれたユーザーが多ければ、その API についての秒単位の需要予測は必ずしも高くないかもしれません。配信を視聴するための契約をする API やアカウントを作成するAPIについても同様です。余剰のリソースを無駄に確保しないためにも本当に高いトランザクションを捌く必要があるAPIはどれか、認識しておくことが重要です。 例）視聴ユーザー数 A人でも視聴開始のアクセス数は分散する どの API がどの程度のスパイクアクセスに耐えるべきか、需要予測を適切に行うには過去の配信時の実績ベースのデータが有用です。過去の配信時の実績データを活かす仕組みが必要になります。これまでに行ったことがない配信を実施する場合、正確に需要予測をする難易度は上がります。 需要予測を正確に行うことができれば、多くのユーザーに最適なシステムリソースでサービス提供が可能になります。しかし、需要予測は必ず当たるとはかぎりません。急にその Live 配信が話題になり、視聴数が一気に跳ね上がる可能性があります。できるだけスケーラブルに、コスト効率よくサービス提供するためにはキャッシュ戦略が必要となり、需要予測が想定を超えた場合にビジネス影響範囲を小さくするためにはバックエンドの保護が必要になります。 2.キャッシュ戦略 キャッシュを活用することはバックエンドに何度も問い合わせることをしないため、より低レイテンシーでコスト効率よく、スパイク時の影響を最小限にすることにつながります。 AWS のサービスを活用するとデータ特性に応じた複数箇所でのCacheを作成することが可能で、Lemino では以下のように使い分けしています。 Amazon CloudFront エッジロケーションというグローバルのネットワークを経由してコンテンツを配信。 応答がユーザー情報に依存しない API はCDN（Contents Delivery Network）でキャッシュすることで負荷及び応答性能を大幅に改善 例）クライアント向けの作品情報の取得 Amazon DynamoDB Accelerator (DAX) 更新頻度が少なく、アプリケーションからの読み込みアクセスが多いレコード 例）アプリケーション内での映像情報の取得 Amazon DynamoDB DynamoDB に RDS と同一のデータを持たせ、キャッシュ用途のように、ユーザーの読み込みリクエストで活用することで、高い秒間の読込み性能が必要なデータをスケーラブルに、運用負荷少なく管理 例）購入情報等 ※RDS の Reader や ElastiCache を活用することも RDS の Read 性能を上げたい場合は選択肢ですが、ライブ配信開始時のような急激なスパイク負荷を想定する場合、インスタンス追加に伴うスケールアウト完了までの時間を許容できませんでした。その点、DynamoDB のオンデマンドキャパシティモードでは、該当テーブルの以前のピーク時のトラフィックの最大 2 倍まで即座にスケールできます。RDS の Reader や ElastiCache のノードの追加が流量の増加に間に合わなかった場合のサービスへの影響と運用の手間などを考慮し、DynamoDB に一部のデータを常に同期することを選択しています。 このほかに、アプリケーション側でも、ユーザに依存せず再利用可能なデータをローカルでキャッシュすることでデータストアの負荷を抑制しています。様々な場所で可能な限りキャッシュを活用することはバックエンドの保護につながっています。 3.バックエンドの保護 需要予測の精緻化とキャッシュの活用をしても、バックエンドに対して予測を上回るリクエストがくる可能性は0にはなりません。一部の API 負荷の想定外の高まりで、バックエンドの使用率が増えることでサービス全体に影響を与えることや、配信以外の共通基盤への影響は避けなければなりません。バックエンドの許容量やボトルネックとなる API の閾値をベースに、想定を超えるリクエストについてはスロットリングするか、待機させることが必要です。現在接続しているユーザーの処理を優先し、新規接続については仮想待合室などでコントロールを行えるようにする、等の工夫によりサービス全体への影響は避け、想定外のアクセス急増にも対応できるようにしておきます。 例えば、1分間でX回処理する性能と、1秒間でX回処理する性能では、当たり前ですが、事前に用意しておくべきシステムリソースが異なります。数秒待たせるだけで、必要なシステムリソースを抑え、スパイクアクセスに耐えきれないことによるサービス障害を抑えることが可能になるケースもあります。 そのアクセスはどの程度ならユーザー体験を損ねずに待たせることが可能か、どの程度時間があればリソースを追加することができるのかも検討しつつ、スパイクアクセスがサービス全面停止に繋がらないようにする必要があります。 Lemino のサービスでは大規模なスパイクアクセスが発生する場合には契約などの一部の導線に仮想待合室を設置しています。 仮想待合室のアーキテクチャは Virtual Waiting Room を参考にスケーラビリティを改良しています。 Lemino のサービスは複数のシステムが連携して動くため、dアカウントの認証などは別の担当チームがあり、自分たちのチームだけではスケールをコントロールできないことがあります。 最後の手段として、他システムも含めたバックエンドを保護するためにスロットリングさせることも選択肢です。 4.まとめ アクセスの急増に対する対応策として、まずは需要予測を精緻化し、事前に必要となるシステムリソースを認識することが大切です。それを上回るスパイクアクセスに備えて、キャッシュ戦略とバックエンドの保護が大切であることをお伝えしました。 アクセスの急増を想定し、想定外に備えるシステムを検討中の皆様の参考にしていただければ幸いです。 著者について 株式会社NTTドコモ 第一プロダクトデザイン部 映像サービス担当　松原拓也 株式会社NTTドコモで提供している映像配信サービス『Lemino』のアーキテクト及び、バックエンドシステムのリードエンジニア、プロジェクトマネージャーを担当。 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部　津和崎美希 通信業界のお客様を担当するソリューション アーキテクト。普段はお客様のAWS活用を支援していますが、ObservabilityについてはAWS社内でコミュニティ活動をしています。ここ数年、動画配信等、Media Serviceのご支援にも手を広げ、幅広いAWS活用をご支援しています。

みなさん、こんにちは。パブリックセクターでビジネス開発、マイグレーションプログラム推進をしている今井です。 アマゾン ウェブ サービス ジャパン（以下、AWS）では、AWSへの大規模なシステムの移行を実現し、ひいてはお客様のデジタルトランスフォーメーションをサポートする 「 AWS ITトランスフォーメーションパッケージ（ITX） 」を2021年に、2022年には内容を強化・拡大した「 AWS ITトランスフォーメーションパッケージ2.0（ITX2.0） 」をリリースしました。2023年にはITXパッケージ2.0をより包括的に進化させた「 AWS ITトランスフォーメーションパッケージ 2023 ファミリー（ITX 2023） 」をリリースし、2021年以来多くのお客様にご活用頂き、企業のITトランスフォーメーションを支援してきました。 今回のブログでは、2024年6月にリリースした最新版の「 AWS ITトランスフォーメーションパッケージファミリー（ITX） 」の中で新たに取り入れられた、公共のお客様に向けて開発されたAWS ITトランスフォーメーションパッケージ 公共版（以下、ITX for PS）についてご紹介します。（ 最新版のITX資料ダウンロードはこちらから ） 公共領域におけるITXに対するお客様からのご要望 日本の社会において労働人口の減少や高齢化などが進行する中、デジタル技術の活用による省力化・効率化が不可欠となっています。政府はこうした課題に対応すべく、行政は勿論の事、医療・教育も含め、国民一人ひとりの暮らしを豊かにするデジタル社会の実現を目指すための政策を推進しており、クラウドの活用もそうした目的を達成するための一つの手段として検討が進められています。例えば中央省庁や地方自治体におけるクラウドの検討状況に目を向けると、クラウド・バイ・デフォルト原則のもとに、今後中央省庁において約1100の政府情報システムのクラウド移行の検討が行われ、また地方においても約1700団体が20の標準業務のクラウド移行を2025年度末までに行う方針です。 こうした状況の中、国においてはデジタル庁が「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（以下基本方針）の中でクラウド利用のメリットを十分に享受するため、システム刷新に伴いマネージドサービスを活用したシステムのモダン化について言及するなど、スマートにクラウドを利用することを勧めています。 今後さらに公共の領域でもシステムのクラウドへの移行が行われていくことが考えられますが、クラウドのメリットを享受するために単純なクラウド移行ではなくシステムのモダン化の検討を効果的に行うことや、公共特有のNW構成といった基盤設計、各種ガイドラインへの準拠の必要性など、公共分野特有の要素に頭を悩ませるお客様の声も聞こえてきます。 今回、AWSへの大規模な移行を考える官公庁や医療、教育、NPOといった公共の分野のお客様向けに従来のITXの内容を拡張し、ITX for PSとしてリリースいたします。 ITX for PSとは？ ITX for PSでは公共領域においても求められるシステムのモダン化や公共分野特有の要素への対応を中心に、従来のITXを拡張する形で、１． システムのモダン化支援 、２． 公共専門分野支援 、３．システムをモダン化する際に鍵となる データ・生成AIの活用支援 を提供すると共に、公共分野で見られる調達のプロセスを考慮したパッケージ構成にしています。 １．システムのモダン化を進めるための支援 AWSへの移行に伴いシステムのモダン化を進めるための支援としては大きく３つのカテゴリを用意しています。移行における初期の企画・検討フェーズにおけるアセスメント支援、アセスメント後に要件の定義や仕様を検討する際に机上調査にとどまらないプロトタイプの支援やモダン化の体験をしてもらうモダン化開発支援、そして運用に入ったシステムのクラウド利用を最適化することによるコスト最適化の支援です。 システムのモダン化を進めるためには、次期システム検討の早い段階でモダン化による費用対効果の検証や、実現性の検証を行うことが重要になると考えられます。そうした検証を支援するために、次期システムの企画・移行検討のフェーズでシステムのモダン化を検討するための各種アセスメントを提供します。 運用生産性の向上など単純な利用コスト比較にとどまらないクラウド移行によるTCO分析を行う「クラウドエコノミクス」、特定業務システムのTo Beアーキテクチャーを検討してモダン計画のインプットとする「モダナイゼーションアセスメント」、移行対象システムを俯瞰的に分析しシステム特性に応じたクラウド移行パターンを推奨する「アプリケーションポートフォリオアセスメント」、マネージドなデーターベース移行を行うために必要な検証を支援する「データベースフリーダム」、システム環境を第3者機関により評価し、サードパーティーライセンスを最適化する「ライセンス評価・最適化プログラム」といった モダン化アセスメント を用意しています。 また、こうしたアセスメントを行ったうえで要件定義や仕様検討のフェーズでは、前フェーズで検討されたアーキテクチャーをもとにしたプロトタイプをAWSが開発する「プロトタイピング支援」や、実際にシステムをモダン化するパイロットプロジェクトを体験し開発チームにノウハウと成功体験を得て頂くための「体験型ワークショップ」といった、 モダン化開発支援 も提供いたします。 そしてAWSに移行したシステムに関し、運用・保守のフェーズでは、よりスマートにクラウドを活用することでコストの最適化を図るための コスト最適化支援 を提供します。 ２．公共専門の分野に関するクラウド活用支援 公共特有の要素に関するクラウド活用支援では、中央政府、自治体、教育機関、医療機関、研究機関など、公共のお客様の特有の専門知識、技術知識を持った技術チームがお客様の課題を解決支援します。また、公共のお客様の状況を踏まえたクラウド人材育成やクラウド推進組織の立ち上げに関する支援、公共調達のプロセスの中でAWSの提供するクレジット提供プログラムの活用支援といったものを提供します。 ITX for PSではシステムをクラウドに移行する際、公共分野での特有な要素に対する支援も用意しています。公共のお客様で見られる閉域網におけるネットワーク設計支援や、IaCが活用されるガバメントクラウドにおけるテンプレートの利用に対する支援、監督省庁等から出される各種ガイドラインに対応したクラウドの利用方法を検討するための支援など、 公共専門分野支援 を用意しています。 また、クラウドの活用において技術以外の要素で重要となる人材育成・組織の面に関しては、クラウドへの大規模移行に際し、組織的な準備ができているかを評価する「移行準備評価」、AWSに携わる要因のスキルギャップの特定とギャップ解消を支援する「スキルギャップ分析」、そうしたアセスメントの結果をもとに公共のお客様のクラウド推進組織（CCoE）の立ち上げ検討や人材育成の支援を行う 公共クラウド人材・組織育成支援 も提供いたします。 さらにAWSでは、移行時の経済的負担を軽減するMigration Acceleration Program（MAP）と呼ばれるAWSの利用料に対するクレジット提供プログラムを用意していますが、公共の調達プロセスの中でMAPを活用するタイミングを検討したり、分離調達の際にどのようなスキームにするとよいかといったご提案等、 公共調達におけるMAPの活用支援 も提供しております。 ３．データ・生成AIの活用支援 モダン化を含むシステムの刷新に際しては、業務改革（ビジネスプロセスリエンジニアリング、BPR）も併せて行うことがデジタル庁の基本方針の中でも推奨されています。業務改革を検討する際、システムの観点からはデータドリブンの意思決定に寄与するデータ基盤や、そのデータを用いた生成AIの活用が求められることも考えられます。 そうした状況にお応えするためにAWSの専門チームがお客様の現行データ基盤を分析し、モダナイゼーションのポイントや、To-Beアーキテクチャ案を提示する「データ基盤モダン化支援」、公共分野における生成AIの代表的なユースケースの実装支援テンプレートによる「生成AI活用検討支援」といった データ・生成AIの活用支援 を用意いたします。 ここに挙げたような支援プログラムを公共調達のサイクルの中で活用頂く事で、官公庁や医療、教育、NPOといった公共の分野のお客様は、クラウド移行を検討するための最適なプロセスを効果的に進めることができるようになります。 ITX for PSのリリースに際したお客様やパートナー様の声 デジタル庁 Chief Cloud Officer 山本教仁様 デジタル庁では、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の中でスマートなクラウドの利用を掲げており、マネージドサービスやIaC (Infrastructure as Code)を活用した自動化によるコスト削減等を説明しています。これら施策はガバメントクラウドの技術要件にも含まれ、採用したクラウドサービスプロバイダーにもその推進をご協力いただいています。 その中で、AWSからは、スマートなクラウド利用を支援する内容をわかりやすく1つのパッケージメニュー「ITX for PS」としてまとめていただき、提供いただきます。これを活用することで、スマートなクラウドの利用が促進され、クラウドに関するスキル育成、システム開発の短期間化や継続的な開発・改善の実現、そして、コスト削減とセキュリティの向上につながると考えてます。 日本政府のクラウド・バイ・デフォルト原則に基づいた、中央官庁および地方公共団体におけるクラウド移行の取り組みに対して、このような支援パッケージが用意されることを歓迎します。 PwCコンサルティング合同会社 執行役員 パートナー デジタルガバメント統括 林泰弘様 AWSは、デジタル庁が発足した2021年から、ガバメントクラウドやガバメントソリューションサービスの導入、自治体基盤システムの標準化および共通化を進めてこられました。これらを通じて蓄積されてきた知見、ノウハウが集約された「ITX for PS」は、中央省庁や自治体のデジタルシフトを加速するものと期待しています。PwCコンサルティングは「AWSコンサルティングパートナー」に認定されており、多くのクライアントに「ITトランスフォーメーションパッケージ」の導入を支援してきました。引き続き、AWSとともに、日本全体のデジタルシフトの推進に取り組んでいきたいと考えております。 ITX for PSの始め方 ITX for PSのご利用に向けて、入り口は2つあります。 1） Webフォーム からお問い合わせ頂く。あるいは 2）担当営業までご連絡ください。 AWSクラウドへの移行やモダナイゼーションにご関心をお持ちのお客様は、 AWSで移行とモダナイズ のページをご確認ください。AWSへの移行やモダナイゼーションに必要な情報が網羅されています。 ITX for PSにご興味をお持ちのお客様は、是非上記2つのいずれかよりAWSへお問合せください。 パブリックセクター統括本部 マイグレーション アドバイザー 今井 宏樹 パブリックセクター技術統括本部 CSM・パートナーソリューション本部 本部長 高田 智己 執行役員 パブリックセクター技術統括本部長 瀧澤 与一

本記事は 2024年2月2日に公開された ” Monitor embedding drift for LLMs deployed from Amazon SageMaker JumpStart ” を翻訳したものです。 生成 AI のワークロードで最も有用なアプリケーションパターンの 1 つが Retrieval Augmented Generation (RAG) パターンです。 RAG パターンでは、入力プロンプトに関連する参照コンテンツを探すために、埋め込みベクトル (テキスト文字列の数値表現) に対して類似検索を実行します。埋め込みはテキストの情報内容を捉え、自然言語処理 (NLP) モデルが言語を数値的に処理できるようにします。埋め込みは浮動小数点ベクトルであるため、3 つの重要な質問を用いて分析することができます。参照データは時間とともに変化するか、ユーザーが尋ねる質問は時間とともに変化するか、そして最後に、参照データが尋ねられている質問をどの程度カバーできているかです。 この記事では、埋め込みベクトル分析とドリフト検出の注意点について学びます。埋め込みは一般的な自然言語処理モデルと特に生成 AI ソリューションにおいて重要な入力データとなるため、時間の経過とともに埋め込みが変化 (ドリフト) するかどうかを測定する方法が必要です。このポストでは、 Amazon SageMaker JumpStart からデプロイされた大規模言語モデル (LLM) を用いてクラスタリング手法によりベクトル埋め込みのドリフトを検出する例を示します。また、後述するエンドツーエンドのサンプルアプリケーションを使用するか、あるいはその一部のみを使用して、これらの概念を実際に体験することができます。 RAG の概要 RAG パターン では、PDF ドキュメント、Wiki 記事、通話の書き起こしなどの外部ソースから知識を検索し、その知識を使って LLM に送られる指示のプロンプトを補強できます。これにより、LLM は応答を生成するときに、より関連性の高い情報を参照できます。例えば、LLM にチョコチップクッキーの作り方を尋ねた場合、自分のレシピライブラリから情報を含めることができます。このパターンでは、レシピのテキストが埋め込みモデルを使って埋め込みベクトルに変換され、ベクトルデータベースに保存されます。入力された質問も埋め込みベクトルに変換され、入力された質問と、類似検索で見つかった参照データが、LLM へのプロンプトに含められます。 埋め込みベクトルが生成される仕組みとそのベクトルについてドリフト分析を実行する方法について、詳しく確認していきましょう。 埋め込みベクトルの分析 埋め込みベクトルは、データの数値表現であり、これらのベクトルを分析することで、参照データの洞察が得られます。この洞察は、後にドリフトの兆候を検出するのに利用できます。埋め込みベクトルは、n 次元空間内の項目を表し、n は大きな値になることが多いです。例えば、この記事で使用されている GPT-J 6B モデルは、4096 次元のベクトルを生成します。ドリフトを測定するために、アプリケーションが参照データと入力プロンプトの両方の埋め込みベクトルをキャプチャすると仮定します。 まず主成分分析 (PCA) を使って次元削減を行います。PCA はデータの変動の大部分を残しつつ次元数を減らそうとします。この場合、分散の 95 % を保持する次元数を見つけることで、2 標準偏差の範囲内にあるものがすべて取り込まれるはずです。 次に、K-Means 法を用いてクラスタ中心の集合を同定します。K-Means 法は、各クラスタが密集している、またはまとまりが高くなるようにデータポイントをグループ化し、クラスタ間の距離が可能な限り遠くなるように試みます。 次の図に示されるクラスタリング出力に基づいて、以下の情報を計算します。 95 % の分散を説明する PCA の次元数 各クラスター中心点 (重心) の位置 さらに、次の図に示すように、各クラスタでサンプルの割合が高いか低いかを確認します。 最後に、この分析を使って以下の値を計算します。 慣性 (inertia) &nbsp;– 慣性は、クラスタ中心への 2 乗距離の和で、K-Means でデータがどの程度うまくクラスタリングされたかを測るものです。 シルエットスコア (silhouette score) &nbsp;– シルエットスコアは、クラスタ内の一貫性を検証する尺度で、-1 から 1 の範囲の値をとります。1 に近い値は、クラスタ内のデータポイントが同じクラスタの他のポイントに近く、別のクラスタのポイントから離れていることを意味します。クラスタ内外の集まり具合の指標の視覚的な表現が次の図に示されています。 これらの情報を定期的にキャプチャすれば、参照データとプロンプトの埋め込みスナップショットを得ることができます。この情報をから埋め込みのドリフトの兆候を分析できます。 埋め込みドリフトの検出 参照データの埋め込みとプロンプトの埋め込みを含むデータのスナップショットを通して、定期的に、クラスタリング情報を比較できます。まず、分散の 95 % を説明するのに必要な次元数、慣性、クラスタリングジョブのシルエットスコアを比較できます。次の表に示すように、ベースラインと比較して、最新の埋め込みのスナップショットでは分散を説明するのに 39 次元多くの次元が必要となり、データがより分散していることを示しています。慣性も上がっており、サンプルがクラスタ中心からより離れた位置にあることを示しています。さらに、シルエットスコアが下がっているため、クラスタが明確に定義されていないことを意味しています。プロンプトデータの場合、これはシステムに入ってくる質問の種類がより多くのトピックに及ぶためかもしれません。 次に、次の図では、各クラスターのサンプル割合がどのように経時的に変化したかを確認できます。これにより、新しい参照データが以前のデータとほぼ同様なのか、新しい領域をカバーしているのかがわかります。 最後に、クラスター中心が移動しているかを見ることで、クラスター内の情報がドリフトしているかを確認できます。次の表で示されています。 質問の対象となる参照データの範囲 参照データと受け付けた質問がどの程度整合しているかを評価することもできます。これを行うには、各プロンプトの埋め込みベクトルを参照データのクラスタに割り当てます。次に、各プロンプトからそのクラスタの中心までの距離を計算し、その平均、中央値、標準偏差を求めます。この情報を保存し、時間の経過に伴ってどのように変化するかを確認できます。 次の図は、プロンプトの埋め込みと参照データの中心間の距離を時間の経過とともに分析した例を示しています。 ご覧のとおり、プロンプトの埋め込みと参照データの中心の平均距離、中央値距離、標準偏差距離の統計は、最初のベースラインから最新のスナップショットにかけて減少しています。距離値そのものの意味を解釈するのは難しいものの、トレンドを使って参照データと質問の間の内容の類似性が時間とともに良くなっているのか悪くなっているのかを判断できます。 サンプルアプリケーション 前のセクションで説明した実験結果を収集するために、SageMaker JumpStart からデプロイされた RAG パターンに使われるモデルを使用して、RAG パターンを実装するサンプルアプリケーションを構築しました。 このモデルは、 Amazon SageMaker のリアルタイムエンドポイントでホストされています。 アプリケーションには以下の 3 つのコアコンポーネントがあります。 プロンプトをキャプチャするユーザーインターフェイスと、LangChain を使った RAG オーケストレーション層を含む対話型フローを使用しています。 データ処理フローは、PDF ドキュメントからデータを抽出し、 Amazon OpenSearch Service に保存される埋め込みを作成します。また、これらをアプリケーションの最終的な埋め込み偏差分析コンポーネントでも使用しています。 埋め込みは Amazon Kinesis Data Firehose 経由で Amazon Simple Storage Service (Amazon S3) でキャプチャされ、 AWS Glue の抽出、変換、ロード (ETL) ジョブと Jupyter ノートブックの組み合わせを実行して、埋め込み分析を行います。 次の図は、エンドツーエンドのアーキテクチャを示しています。 完全なサンプルコードは GitHub で公開されています。 提供されているコードは 2 つの異なるパターンで用意されています。 Streamlit フロントエンドを持つフルスタックのサンプルアプリケーション – Amazon Elastic Container Service (Amazon ECS) と AWS Fargate で実行される LangChain を使った RAG の連携層と Streamlit を使ったユーザーインターフェースを持つ、エンドツーエンドのアプリケーションを提供します。 バックエンドアプリケーション – フルアプリケーションスタックをデプロイしたくない場合は、 AWS Cloud Development Kit (AWS CDK) スタックのバックエンドのみをデプロイし、提供された Jupyter ノートブックを使って LangChain を使った Retrieval Augmented Generation (RAG) の連携を実行することができます。 提供されたパターンを作成するには、以下のセクションで説明されている複数の前提条件があり、まず生成モデルとテキストエンベディングモデルをデプロイした後、追加の前提条件に移ります。 SageMaker JumpStart によるモデルのデプロイ 両方のパターンでは、埋め込みモデルと生成モデルをデプロイすることを前提としています。このために、SageMaker JumpStart から 2 つのモデルをデプロイします。最初のモデル GPT-J 6B は埋め込み モデルとして使用し、2 つ目の Falcon-40b はテキスト生成に使用します。 これらのモデルは、 AWS マネジメントコンソール 、 Amazon SageMaker Studio 、またはプログラムによって SageMaker JumpStart からデプロイできます。詳細については、 JumpStart 基盤モデルの使用方法 を参照してください。デプロイを簡素化するために、SageMaker JumpStart によって自動的に作成されたノートブックから派生した 提供されているノートブック を使うことができます。このノートブックは、SageMaker JumpStart の ML ハブからモデルを取得し、2 つの別々の SageMaker リアルタイムエンドポイントとしてデプロイします。 サンプルノートブックには、クリーンアップ用のセクションもありますが、そのセクションは実行しないでください。実行すると今デプロイしたばかりのエンドポイントが削除されます。このハンズオンチュートリアルの最後に、クリーンアップを完了させます。 エンドポイントのデプロイが正常に完了したことを確認したら、サンプルアプリケーション全体をデプロイする準備が整います。ただし、バックエンドと分析用のノートブックのみを探索したい場合は、次のセクションで説明するように、そちらだけをデプロイすることもできます。 オプション 1: バックエンドアプリケーションのみのデプロイ このパターンでは、バックエンド ソリューションのみを展開し、Jupyter ノートブックを使ってソリューションと対話できます。UI の部分を構築したくない場合に、このパターンを使用します。 前提条件 次の前提条件を満たしている必要があります。 SageMaker JumpStart を使ってモデルエンドポイントのデプロイ – 上記で説明したように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントをデプロイします。 デプロイ時のパラメーター設定 – 次の情報を設定します。 テキストモデルエンドポイント名 – SageMaker JumpStart で展開したテキスト生成モデルのエンドポイント名 埋め込みモデルエンドポイント名 – SageMaker JumpStart で展開した埋め込みモデルのエンドポイント名 AWS CDK を使用したリソースのデプロイ 前のセクションで示したデプロイパラメータを使用して、AWS CDK スタックをデプロイしてください。AWS CDK のインストールについて詳しくは、 AWS CDK の概要 を参照してください。 AWS CDK のデプロイに使用するワークステーションで Docker がインストールされ、実行されていることを確認してください。詳しくは Get Docker を参照してください。 $ cd pattern1-rag/cdk $ cdk deploy BackendStack --exclusively -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; または、&nbsp; pattern1-rag/cdk ディレクトリの cdk.context.json というファイルにコンテキスト値を入力し、 cdk deploy BackendStack --exclusively を実行することもできます。 デプロイ時に、ノートブックを実行するために必要な情報が出力されます。次のセクションに示されているように、質問と回答をする前に参照ドキュメントの埋め込みを行う必要があります。 参照ドキュメントの埋め込み この RAG アプローチでは、まず参照ドキュメントをテキストエンベディングモデルで埋め込み、ベクトルデータベースに格納します。 このソリューションでは、PDF ドキュメントを取り込むパイプラインが構築されています。 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが作成され、そのインスタンスに Amazon Elastic File System (Amazon EFS) のファイルシステムがマウントされ、PDF ドキュメントを保存するための環境が構築されています。 AWS DataSync タスクが 1 時間ごとに実行され、EFS ファイルシステムパスで見つかった PDF ドキュメントを取得し、テキスト埋め込み処理用の S3 バケットにアップロードします。このプロセスは参照ドキュメントを埋め込み、その埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を通じて埋め込みアーカイブを S3 バケットに保存します。 参照ドキュメントを取り込むには、次の手順を実行します。 作成したサンプルの EC2 インスタンス ID (AWS CDK の出力から JumpHostId の値を参照) を取得し、 AWS Systems Manager の機能である Session Manager を使用して接続してください。手順については、 AWS Systems Manager Session Manager を使用して Linux インスタンスに接続する を参照してください。 EFS ファイルシステムがマウントされているディレクトリ /mnt/efs/fs1 に移って、まず mkdir ingest を実行して ingest というフォルダを作成します。次に cd ingest を実行して作成したフォルダに移動します。 $ cd /mnt/efs/fs1 $ mkdir ingest &amp; cd ingest ingest ディレクトリに参照する PDF ドキュメントを追加します。 DataSync タスクは、この埋め込みプロセスを開始するために、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするように設定されています。 DataSync タスクは 1 時間おきにスケジュールされて実行されます。オプションで、タスクを手動で開始して、追加した PDF ドキュメントの埋め込みプロセスを即座に開始することもできます。 タスクを開始するには、AWS CDK の出力から DataSyncTaskID のタスク ID を特定し、 デフォルト設定でタスクを開始 してください。 埋め込み作成後は、次のセクションで示すように Jupyter ノートブックから RAG の質問に答えることができます。 Jupyter Notebook を使った質問と回答 次の手順を完了してください。 AWS CDK の出力 NotebookInstanceName から SageMaker ノートブックインスタンス名を取得し、SageMaker コンソールから Jupyter Lab に接続します。 ディレクトリ fmops/full-stack/pattern1-rag/notebooks/ に移動します。 ノートブックインスタンス内でノートブック query-llm.ipynb を開き、実行して RAG を使って質問と回答を行います。 ノートブックでは conda_python3 カーネルを使用するようにしてください。 このパターンは、フルスタックアプリケーションに必要な追加の前提条件をプロビジョニングする必要なく、バックエンドのソリューションを検討するのに役立ちます。次のセクションでは、生成 AI アプリケーションとの対話用のユーザー インターフェイスを提供するため、フロントエンド部分も含めたフルスタック アプリケーションの実装について説明します。 オプション 2: Streamlit フロントエンドのフルスタックサンプルアプリケーションのデプロイ この手法により、質問と応答のユーザーフロントエンドインターフェイスを備えたソリューションをデプロイできます。 前提条件 サンプルアプリケーションをデプロイするには、次の前提条件を満たす必要があります。 SageMaker JumpStart を使ってモデルエンドポイントのデプロイ &nbsp;– 提供されたノートブックを使用して、前のセクションで説明されているように、SageMaker JumpStart を使用してモデルを SageMaker リアルタイムエンドポイントにデプロイします。 Amazon Route 53 ホストゾーン – このソリューションで使用するために、 Amazon Route 53 の パブリックホストゾーン を作成します。または、 example.com のように既存の Route 53 パブリックホストゾーンを使用することもできます。 AWS Certificate Manager 証明書 – Route 53 ホストゾーンドメイン名および適用対象のサブドメイン ( example.com および *.example.com など) 用に、 AWS Certificate Manager (ACM) の TLS 証明書をプロビジョニングします。手順については、 パブリック証明書のリクエスト を参照してください。この証明書は、 Amazon CloudFront およびロードバランサーのオリジンにおける HTTPS を構成するために使用されます。 デプロイ時のパラメーター設定 &nbsp;– 次の情報を設定します。 フロントエンドアプリケーションのカスタムドメイン名 – フロントエンドのサンプルアプリケーションにアクセスするためのカスタムドメイン名です。指定されたドメイン名は、フロントエンド CloudFront ディストリビューションを参照する Route 53 DNS レコードの作成に使用されます。たとえば、 app.example.com です。 ロードバランサーのオリジンとなるカスタムドメイン名 – CloudFront ディストリビューションのロードバランサーオリジン用のカスタムドメイン名です。指定されたドメイン名は、オリジンロードバランサーを参照する Route 53 DNS レコードの作成に使用されます。たとえば、 app-lb.example.com です。 Route 53 ホストゾーン ID – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン ID です。たとえば、 ZXXXXXXXXYYYYYYYYY です。 Route 53 ホストゾーン名 – 指定されたカスタムドメイン名をホストする Route 53 ホストゾーン名です。たとえば、 example.com です。 ACM 証明書 ARN – 指定されたカスタムドメイン名で使用される ACM 証明書の ARN です。 テキストモデルエンドポイント名 – SageMaker JumpStart でデプロイされたテキスト生成モデルのエンドポイント名です。 埋め込みモデルエンドポイント名 – SageMaker JumpStart でデプロイされた埋め込みモデルのエンドポイント名です。 AWS CDK を使用したリソースのデプロイ 前提条件でメモした展開パラメータを使用して、AWS CDK スタックをデプロイしてください。詳細については、 AWS CDK の使用開始 を参照してください。 Docker が AWS CDK のデプロイに使用されるワークステーションにインストールされており、実行中であることを確認してください。 $ cd pattern1-rag/cdk $ cdk deploy --all -c appCustomDomainName=&lt;Enter Custom Domain Name to be used for Frontend App&gt; \ -c loadBalancerOriginCustomDomainName=&lt;Enter Custom Domain Name to be used for Load Balancer Origin&gt; \ -c customDomainRoute53HostedZoneID=&lt;Enter Route53 Hosted Zone ID for the Custom Domain being used&gt; \ -c customDomainRoute53HostedZoneName=&lt;Enter Route53 Hostedzone Name&gt; \ -c customDomainCertificateArn=&lt;Enter ACM Certificate ARN for Custom Domains provided&gt; \ -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; 上の例のコードでは、-c は入力時に指定するコンテキスト情報を表しています。もしくは、 pattern1-rag/cdk ディレクトリにある cdk.context.json ファイルにコンテキスト情報を記述し、 cdk deploy --all を実行することもできます。 bin/cdk.ts ファイルでリージョンを指定していることに注意してください。ALB アクセスログを設定するには、リージョンを指定する必要があります。デプロイする前に、このリージョンを変更することができます。 デプロイ時に、Streamlit アプリケーションにアクセスする URL が出力されます。次のセクションで説明するように、質問に対して回答できるようにする前に、参照ドキュメントを組み込む必要があります。 参照ドキュメントの埋め込み RAG アプローチでは、まず PDF ドキュメントをテキスト埋め込みモデルで処理を行い、ベクトルデータベースに保存します。このソリューションでは、PDF ドキュメントを取り込むためのパイプラインが構築されています。 初回デプロイオプションで説明したように、PDF ドキュメントの取り込み用に EC2 インスタンスが作成され、PDF ドキュメントを保存するために EFS ファイルシステムが EC2 インスタンスにマウントされています。1 時間ごとに DataSync タスクが実行され、EFS ファイルシステムパス内の PDF ドキュメントを取得して、テキスト埋め込みプロセスを開始するために S3 バケットにアップロードされます。このプロセスは参照ドキュメントに埋め込みを行い、埋め込みを OpenSearch Service に保存します。また、後の分析のために、Kinesis Data Firehose を介して埋め込みデータのアーカイブを S3 バケットに保存します。 参照ドキュメントを取り込むには、次の手順を実行してください。 作成された EC2 インスタンスのサンプル ID を取得 (AWS CDK の出力 JumpHostId を参照) し、Session Manager を使って接続します。 EFS ファイルシステムがマウントされている /mnt/efs/fs1 ディレクトリに移動し、 ingest というフォルダを作成します。 $ cd /mnt/efs/fs1 $ mkdir ingest &amp;&amp; cd ingest ingest ディレクトリに、参照する PDF ドキュメントを追加します。 DataSync タスクは、このディレクトリ内のすべてのファイルを Amazon S3 にアップロードするよう設定されており、これによって埋め込み処理が開始されます。 DataSync タスクは 1 時間ごとに実行されます。追加した PDF ドキュメントの埋め込み処理を即座に開始したい場合は、手動でタスクを開始することもできます。 4. タスクを開始するには、AWS CDK 出力の DataSyncTaskID からタスク ID を特定し、 デフォルトでタスクを開始 します。 質問と回答 参照ドキュメントが埋め込まれた後、Streamlit アプリケーションにアクセスする URL にアクセスすることで、RAG の質問と回答をスタートできます。 Amazon Cognito 認証レイヤーが使用されているため、アプリケーションにはじめてアクセスする際は AWS CDK によってデプロイされた Amazon Cognito ユーザープール (ユーザープール名は AWS CDK の出力を参照) でユーザーアカウントを作成する必要があります。Amazon Cognito ユーザーを作成するための手順については、 AWS マネジメントコンソールで新規ユーザーを作成する を参照してください。 埋め込みドリフトの分析 このセクションでは、参照スデータ埋め込みとプロンプト埋め込みのベースラインを最初に作成してから、時間の経過とともにその埋め込みのスナップショットを作成することで、ドリフト分析を実行する方法を説明します。これにより、ベースラインの埋め込みとスナップショットの埋め込みを比較できます。 参照データとプロンプトの基準となる埋め込みベクトルの作成 参照データの埋め込み表現のベースラインを作成するには、AWS Glue コンソールを開き、ETL ジョブ embedding-drift-analysis を選択します。次のように ETL ジョブのパラメーターを設定し、ジョブを実行してください。 --job_type を BASELINE に設定します。 --out_table を参照埋め込みデータ用の Amazon DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力の DriftTableReference を参照してください。) --centroid_table を参照の重心データ用の DynamoDB テーブルに設定します。(テーブル名は AWS CDK 出力の CentroidTableReference を参照してください。) --data_path を S3 バケットとプレフィックスに設定します。例: s3:// &lt;バケット名で置換&gt; /embeddingarchive/ (バケット名は AWS CDK 出力の BucketName を参照してください。) 同様に、ETL ジョブ embedding-drift-analysis を使用して、プロンプト文章のベースラインの特徴ベクトルを作成します。ETL ジョブのパラメータを次のように設定してジョブを実行します。 --job_type を BASELINE に設定する --out_table をプロンプト文データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力 DriftTablePromptsName を参照) --centroid_table をプロンプト分類データの DynamoDB テーブルに設定する (テーブル名は AWS CDK の出力 CentroidTablePrompts を参照) --data_path を S3 バケットのプレフィックスに設定する 例: s3:// &lt;バケット名で置換&gt; /promptarchive/ (バケット名は AWS CDK の出力 BucketName を参照) 参照データとプロンプトの埋め込みスナップショットの作成 OpenSearch Service に追加情報を取り込んだ後、ETL ジョブ embedding-drift-analysis を再実行して、参照データのベクトルのスナップショットを作成します。前のセクションで示したように、参照データのベクトルを作成するために実行した ETL ジョブと同じパラメータを使用しますが、 --job_type パラメータを SNAPSHOT に設定する点が異なります。 同様に、プロンプトの埋め込みスナップショットを取得するには、ETL ジョブ embedding-drift-analysis を再実行します。前のセクションで示したプロンプトの埋め込みベースラインを作成するために実行した ETL ジョブと同じパラメータを使用しますが、 --job_type パラメータを SNAPSHOT に設定することを除きます。 ベースラインとスナップショットの比較 参照データとプロンプトについて、埋め込みベースラインとスナップショットを比較するには、提供されたノートブック pattern1-rag/notebooks/drift-analysis.ipynb を使用します。 参照データやプロンプトの埋め込みベクトルの比較を行うには、各ノートブックの実行ごとに、ノートブックの DynamoDB テーブル名の変数 ( tbl と c_tbl ) を、適切な DynamoDB テーブルに変更してください。 ノートブックの変数 tbl は、適切なドリフトテーブル名に変更する必要があります。ノートブックでこの変数を設定する場所の例を以下に示します。 テーブル名は以下のように取得できます。 参照埋め込みデータについては、AWS CDK の出力 DriftTableReference からドリフトテーブルの名前を取得します プロンプト埋め込みデータについては、AWS CDK の出力 DriftTablePromptsName からドリフトテーブルの名前を取得します また、ノートブックの変数 c_tbl は適切な重心テーブル名に変更する必要があります。ノートブック内でこの変数を構成する場所の例を以下に示します。 以下のようにしてテーブル名を取得できます。 参照埋め込みデータとは、参照するデータセットを埋め込んだデータのことです。AWS CDK の出力 CentroidTableReference から、参照データセットが格納されたテーブル名を取得します。 プロンプト埋め込みデータとは、質問文(プロンプト)を埋め込んだデータのことです。AWS CDK の出力 CentroidTablePrompts から、プロンプトが埋め込まれたデータが格納されたテーブル名を取得します。 プロンプト文と参照データの類似度分析 まず、AWS Glue ジョブ embedding-distance-analysis を実行します。このジョブは、参照データの埋め込みに対する K-Means 評価からどのクラスターに各プロンプトが属するかを見つけます。次に、各プロンプトが対応するクラスター中心までの距離の平均値、中央値、標準偏差を計算します。 pattern1-rag/notebooks/distance-analysis.ipynb ノートブックを実行すると、時間の経過に伴う距離メトリクスのトレンドを確認できます。これにより、プロンプト埋め込みベクトルの距離分布の全体的なトレンドを把握できます。 ノートブック pattern1-rag/notebooks/prompt-distance-outliers.ipynb では、外れ値を検出する AWS Glue ノートブックです。これは参照データとは無関係のプロンプトが増えていないか特定するのに役立ちます。 類似スコアのモニタリング OpenSearch Service から得られるすべての類似スコアは、 rag 名前空間の下にある Amazon CloudWatch にログ記録されます。 RAG_Scores ダッシュボードは、平均スコアおよび取り込まれたスコアの合計数を表示します。 クリーンアップ 必要以上の料金が発生しないように、作成したすべてのリソースを削除します。 デプロイした SageMaker モデルの削除 デプロイされた SageMaker JumpStart (Amazon の機械学習モデルを素早く構築・デプロイできるサービス) のモデルを削除したい場合は、 提供されている例のノートブック のクリーンアップセクションを参照するか、 Amazon SageMaker (AWS の機械学習サービス) のコンソール上でモデルを削除 することができます。 AWS CDK リソースの削除 cdk.context.json ファイルにパラメータを入力した場合は、次のように内容を消去してください。 $ cd pattern1-rag/cdk $ cdk destroy --all コマンド ライン上でパラメータを入力し、バックエンド アプリケーション (バックエンド AWS CDK スタック) のみをデプロイした場合、次のように削除してください。 $ cd pattern1-rag/cdk $ cdk destroy --all -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; コマンドラインでパラメータを入力し、フロントエンドとバックエンド AWS CDK スタック全体をデプロイした場合は、次のように削除します。 $ cd pattern1-rag/cdk $ cdk destroy --all -c appCustomDomainName=&lt;Enter Custom Domain Name to be used for Frontend App&gt; \ -c loadBalancerOriginCustomDomainName=&lt;Enter Custom Domain Name to be used for Load Balancer Origin&gt; \ -c customDomainRoute53HostedZoneID=&lt;Enter Route53 Hosted Zone ID for the Custom Domain being used&gt; \ -c customDomainRoute53HostedZoneName=&lt;Enter Route53 Hostedzone Name&gt; \ -c customDomainCertificateArn=&lt;Enter ACM Certificate ARN for Custom Domains provided&gt; \ -c textModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text generation model&gt; \ -c embeddingsModelEndpointName=&lt;Enter the SageMaker Endpoint Name for the Text embeddings model&gt; まとめ この記事では、生成 AI の RAG パターンにおける参照データとプロンプトの両方でベクトル埋め込みを取得するアプリケーションの実例を示しました。参照データやプロンプトでドリフトが発生しているかどうかを判断するためのクラスタリング分析の実行方法と、参照データがユーザーの質問の種類をどの程度カバーしているかを示しました。ドリフトを検出できれば、環境が変化し、モデルが最適化されていない新しい入力を受け取っていることを示す兆候となります。これにより、変化する入力に対する現在のモデルの積極的な評価が可能になります。

はじめに 全米消防協会は、毎年 100 万件を超える火災を記録しています。これらの火災は、米国における都市の安全を脅かす最大の危険のひとつと位置づけられています。現在、消防署は主に在宅用の煙探知機、火災通報ボックス、および電話による通報といった従来の火災検知システムによる警報に頼っています。しかしこれらのシステムでは、火災の範囲、規模、場所などの追加情報が不足する可能性があります。モノのインターネット (IoT) は、都市のインフラを合理化し、火災を事前に検知し、公共の安全性を向上させるための重要な技術です。 火災関連の事故を減らし、迅速かつ効果的に火災に対応するため、IoT センサーと高度なデータ分析 (機械学習など) を統合することができます。環境条件と煙レベルを監視する IoT デバイスは、ほぼリアルタイムでデータをクラウドに送信でき、そこでさらに処理が行われ、潜在的な火災の危険性が特定されます。そうすることにより、事態が悪化する前に実用的な対策を講じることができます。 このブログ記事では、早期警告システムを緊急時対応者に構築するためのデータを接続、収集、活用するにあたり、AWS のサービス群をどのように使用するかを学びます。全体のシステムアーキテクチャについて説明し、データを収集するセンサーやデバイス、AWS IoT サービスを使ったデータ処理と分析、 Amazon SageMaker を使ったローコードな ML モデルによる火災予測についても見ていきます。 全体アーキテクチャ このソリューションでは、 AWS IoT Core &nbsp;を使用して、温度、気圧、ガス、湿度、風速、土壌湿度などさまざまなセンサーからデータを大規模にクラウドに安全に取り込みます。使用する IoT デバイスのタイプに応じて、 AWS IoT SDK &nbsp;は、AWS IoT Core とデバイスを安全に接続し、認証するために必要なライブラリと API を提供します。 ただし、一部のデバイスは Wi-Fi やセルラーネットワークが途切れ途切れになるところに配置される可能性があります。そのような場合、 AWS IoT Core for Amazon Sidewalk &nbsp;（注記：2024/06時点で日本国内ではサービス未提供）が優位性を発揮します。 Amazon Sidewalk は、互換性のある Amazon Echo や Ring デバイスなどの Amazon Sidewalk Gateway を使用し、IoT エンドポイントデバイスにクラウド接続を提供するセキュアなコミュニティネットワークです。Amazon Sidewalk は、Bluetooth Low Energy を使った近距離通信と、900MHz の周波数で LoRa および FSK 無線プロトコルを使った長距離通信により、家の中や外でも低帯域幅の長距離接続を実現します。IoT デバイスは、Sidewalk Gateway を介して AWS IoT Core と安全に対話でき、データの発行やコントロールメッセージの受信ができます。この統合により、IoT デバイスの全体的な接続性と機能性が強化されます。Amazon Sidewalk は、接続性のギャップを埋めることで、スマートシティの実装において AWS IoT Core の範囲を広げ、遠隔の地域でも本当に市内全域をカバーするネットワークを可能にします。この通信範囲の拡大により、IoT とエッジコンピューティングがスマートシティのインフラ内でより効果的で信頼性の高いものになります。 AWS IoT Rules Engine &nbsp;は、ストリーミングデータを分析および処理し、AWS IoT Core に到着するメッセージを下流の AWS サービスにルーティングできるようにします。受信データに基づいて条件を指定するルールを作成できます。IoT デバイスからのメッセージがルールの条件に一致すると、ルールエンジンがアクションをトリガーします。このソリューションでは、このアクションによってメッセージが&nbsp; Amazon Simple Notification Service (Amazon SNS) に転送され、指定された通信チャンネルで対応チームに通知されます。 受信データは Amazon Timestream にもルーティングされ、ニアリアルタイムの監視のために保存されます。Amazon Timestream は高速、スケーラブル、完全マネージド型の時系列データベースで、時系列データの保存と分析を簡単に行えます。Timestream の目的別クエリエンジンを使えば、データの場所を指定することなく、最新のデータと過去のデータにアクセスして分析できます。AWS IoT で定義されたルールにより、着信メッセージからのデータが Timestream に直接投入され、AWS IoT Core が SQL リファレンスを使って結果のアクションを解析します。 Amazon Managed Grafana &nbsp;を使用して、何百万ものリアルタイムイベントを監視および分析する動的なダッシュボードを通じて、即座にインサイトを得ることができます。Amazon Managed Grafana は、 Amazon Timestream と統合されたフルマネージドで、安全なデータ可視化サービスです。Amazon Managed Grafana を使用すると、複数のソースからの遠隔測定データを即座に照会、相関、可視化できます。Amazon&nbsp;Timestream と&nbsp;Amazon Managed Grafana&nbsp;を使用すると、ダッシュボードからほぼリアルタイムのインサイトを導き出す運用ダッシュボードを構築し、何百万ものイベントを分析して監視し、警告することができます。これらのダッシュボードは、ステークホルダーや対応チームに、センサーのメトリクスや異常検知に関する即時の可視性を提供します。また、スマートシティ内の火災につながる潜在的な脅威の早期発見にも役立ちます。 長期的な分析と履歴参照のために、すべての生のセンサーデータは Amazon Simple Storage Service (Amazon S3) のデータレイクに配信されます。これは、ストリーミングデータをキャプチャ、変換、ロードする Amazon Data Firehose に渡されます。Amazon S3 に過去データを保存することは、このシステムの機能を高める上で重要な役割を果たします。これがマシンラーニングモデル開発の基盤となり、 Amazon SageMaker によって支援されます。SageMaker を利用すれば、この過去のデータセットを使って効率的にマシンラーニングモデルをトレーニングできます。過去データからのインサイトで強化されたこれらのモデルには、火災リスクを含む環境条件を正確に予測する能力があります。 Amazon Athena を使えば、これらのインサイトを直感的に分析・可視化でき、データ主導の意思決定が容易になります。Athena はサーバーレスかつインタラクティブなクエリサービスで、Amazon S3 に保存されたデータを分析し、結果を Amazon QuickSight で可視化できます。Amazon QuickSight はこの高度なデータを活用し、インタラクティブで分かりやすいダッシュボードを生成します。 ニアリアルタイムの監視、予測分析、高度な可視化を組み合わせることで、変化する環境条件に対して積極的に対応できます。この積極的な対応により、潜在的な脅威の迅速な検知と、タイムリーな緊急対応が可能になります。 他のユースケース 上記のアーキテクチャは、スマートシティにおける火災に関するセンサーデータを収集、分析、表示するための柔軟な基盤として機能します。このアーキテクチャは、山火事のような環境問題への対処にも応用できます。山火事は、人里離れた森林から発生し、郊外や都市部まで到達することが多くあります。森林地帯、公園、緑地帯、都市と山林の境界などで IoT センサーを使用することで、都市は火災を早期に発見し、封じ込めることができます。 このアーキテクチャは火災検知以外にも応用できます。交通、廃棄物管理、エネルギー使用、洪水リスク、大気の質を監視することで、スマートシティの運営を最適化することができます。このアーキテクチャの核となる機能は、センサーデータを市当局、緊急対応者、市民にとって有用な情報に変換し、都市をより安全で住みやすく、持続可能なものにすることにあります。 まとめ このブログでは、スマートシティ向けのスケーラブルな早期火災検知システムを設計するためのリファレンスアーキテクチャについて説明しました。AWS IoT を活用することで、このソリューションは市内の数千ものセンサーからのデータ取り込みと、ほぼリアルタイムの検知および警報をサポートします。このようなデータ取り込みにより、迅速な対応、事前の被害軽減、最適なリソース配分が可能になります。このアーキテクチャの汎用性により、交通管理、大気汚染監視、洪水予測などの他のIoTユースケースにも適用できます。最先端のテクノロジーと賢明な都市設計を組み合わせることで、都市は市民にとってより強靭で安全なものになる大きな一歩を踏み出せるでしょう。 この記事は Ahmed Alkhazraji, Ankur Dang, Marouane Hail&nbsp;によって書かれた Early Fire Detection Design Model for Smart Cities: Using AWS IoT and ML Technologies の日本語訳です。翻訳は、プロフェッショナルサービス本部 IoT コンサルタントの 宮本 篤 が担当しました。 著者について Ahmed Alkhazraji は、AWS で AI/ML および汎用 AI に注力するシニアソリューションアーキテクトです。革新的なソリューションを構築することと、AWS 導入の初期段階にあるお客様とともに働くことに情熱を注いでいます。仕事の合間には、ハイキング、サッカー、旅行を楽しんでいます。 Ankur Dang は Amazon Web Services(AWS) でソリューションアーキテクトを務めています。テクノロジーに情熱を注ぎ、お客様の問題解決とアプリケーションのモダナイゼーションの支援に取り組んでいます。特に AWS IoT サービスを活用したシステム設計に興味があり、モノのインターネット (IoT) ソリューションに熱心に取り組んでいます。仕事以外では、航空宇宙の進歩を研究したり、ドローン写真でユニークな空撮を楽しむなど、趣味を追求しています。 Marouane Hail は、クラウドオペレーションを専門とするソリューションアーキテクトです。お客様のために安全かつスケーラブルなソリューションを構築することに情熱を注いでいます。仕事以外では、サッカーをするのが好きで、テクノロジーについても学習を続けています。 以下のAWS リソースも併せてご確認ください。 [1] Tutorial: Connecting a device to AWS IoT Core by using the AWS IoT Device SDK [2] Tutorial: Connecting Sidewalk devices to AWS IoT Core for Amazon Sidewalk [3] Tutorial: AWS IoT Rule to Send an Amazon SNS notification [4] Tutorial: AWS IoT Rule to send incoming data to Amazon Timestream [5] Tutorial: Visualize your time series data and create alerts using Grafana [6] Blog: Ingesting enriched IoT data into Amazon S3 using Amazon Kinesis Data Firehose [7] Blog: Analyze and visualize nested JSON data with Amazon Athena and Amazon QuickSight <!-- '"` -->

Amazon Timestream for LiveAnalytics は、高速でスケーラブルなサーバーレス時系列データベースであり、1 日に数兆件のイベントを簡単かつコスト効率よく保存および分析する事ができます。Timestream for LiveAnalytics は、数億の IoT デバイス、産業機器の監視や、ゲームセッション、ストリーミングビデオセッション、金融、ログ分析などのユースケースに使用できます。Timestream for LiveAnalytics を使用すると、高可用性を実現しながら、1 分あたり数十ギガバイトの時系列データを取り込み、数秒でテラバイトの時系列データに対する SQL クエリを実行できます。 現在、様々な組織が、時間に敏感なデータのリアルタイムの洞察を提供することで、競争上の優位性を獲得しようとしていますが、データストリームを使用したリアルタイムデータの取り込みをサポートし、それを Timestream for LiveAnalytics で処理して保存するデータパイプラインが必要となります。時系列データをサポートしている AWS ソースから Timestream for LiveAnalytics に転送するには、Apache Flink アダプターなどのすぐに使えるアダプター、またはカスタマイズされた専用のコードが必要になる場合がありました。 時系列データの取り込みを簡素化する為、 Amazon EventBridge Pipes と Timestream for LiveAnalytics の統合機能が今回使えるようになりました。EventBridge Pipes を使用して、 Amazon DynamoDB 、 Amazon Kinesis Data Streams 、 Amazon MQ 、 Amazon Simple Queue Service (Amazon SQS) などのさまざまなソースから Timestream for LiveAnalytics にデータを取り込めるようになりました。本リリースにより、Timestream for LiveAnalytics にデータを取り込むための、柔軟なローコード・ノーコード (LCNC) 構成ベースのソリューションが利用可能となります。 EventBridge Pipes は、サポートされている ソース と ターゲット 間のポイントツーポイント統合を目的としており、高度な 変換 、 エンリッチメント 、 フィルター 処理をサポートしています。EventBridge Pipes は、イベント駆動型アーキテクチャを開発する際の専門知識と統合コードの必要性を軽減し、企業のアプリケーション間の一貫性を促進します。 本投稿では、Timestream for LiveAnalytics が Kinesis Data Streams からデータを取り込めるように EventBridge Pipes を設定する方法を紹介します。 ソリューションの概要 以下の図は、EventBridge Pipes を利用して Kinesis Data Streams からデータを取り込む為のアーキテクチャを示しています。EventBridge Pipes がサポートしているその他の統合を調べるには、 Amazon EventBridge Pipes sources を参照してください。 次の JSON でサンプル車両データを生成し、 Amazon Kinesis Data Generator (KDG) を使用して Kinesis Data Streams にストリーミングします。 Kinesis Data Streams から Timestream for LiveAnalytics にデータを取り込むためのパイプを以下で設定していきます。 { "connectionTime": "{{date.now("YYYY-MM-DD HH:mm:ss.SSS")}}", "vehicle_id": "CAR_{{random.number({"min":1, "max":100})}}", "driver_id": "USER_{{random.number({"min":1, "max":1000})}}", "engine_status": "{{random.number({"min":0, "max":1})}}", "miles": "{{random.number({"min":0, "max":1000})}}.0" } 前提 本投稿では、 データベース VehicleMetricsDB と テーブル VehicleMetrics を作成しました。カーディナリティの高い列を持ち、テーブルのクエリで述語として頻繁に使用されるディメンションに基づいてパーティションキーを選択することをお勧めします。これにより、データがパーティション間で均等に分散され、パフォーマンスに関する問題を回避する事ができます。本投稿では、 顧客定義のパーティションキー として vehicle_id を持つ車両から生成されたデータを使います。またデータストリーム vehicle-metrics-stream についても 作成 しました。 注意: このソリューションでは、アカウントにコストが発生する AWS リソースが作成されます。本投稿の一部として作成したリソースは、完了したら必ず削除して下さい。 EventBridge pipe を作成する EventBridge Pipes のコンソール画面を開く Create pipe を選択 Pipe name として作成するパイプ名を指定する Description として説明を入力する (オプション) Build pipe タブの Source に Kinesis を選択し、適切なストリームを選択する Additional setting で要件に応じて、 バッチサイズや多重度の値 を設定する On partial batch item failure – AUTOMATIC_BISECT を選択する事を推奨します。各バッチは自動的に半分に分割され、すべてのレコードが処理されるか、失敗したメッセージのみがバッチ内に残るまで、半分ずつ再試行されます。 Batch size – デフォルトの 100 を選択しましょう。尚、Amazon SQS がソースの場合は最大のバッチサイズは 10 になります。 Build pipe タブの Target を選択 このデモでは、 フィルタリング と エンリッチメント のオプションは必要ないため、ターゲットを直接設定しますが、要件に基づいてフィルタリングとエンリッチメントの適用を選択できます。エンリッチメントレイヤーを追加すると、 さまざまなサービスがさまざまなレベルのバッチ処理をサポート します。 Details の Target service で、ターゲットとして Timestream for LiveAnalytics を選択し、対象のデータベースとテーブルを選択します。 データが有効な JSON の場合、入力テンプレートまたはターゲットパラメーターの JSON パスは コンテンツを直接参照 できます。たとえば、 &lt;$.data.someKey&gt; を使用して変数を参照できます。 Time field type には、$.data.connectionTime をデフォルトの 時間 として TIMESTAMP_FORMAT ( yyyy-MM-dd HH:mm:ss.SSS ) を使用します。要件によっては、 EPOCH 形式も選択できます。 Version value を指定する事で、最新の値を使用してデータポイントを 更新 できます。各 Kinesis レコードには、 ApproximateArrivalTimestamp という値が含まれており、ストリームがレコードを正常に受信して保存したときに設定されます。本投稿では、更新を処理するためにバージョン値を $.data.approximateArrivalTimestamp に設定しました。そのため、最新の ApproximateArrivalTimestamp でメジャーが変更され、同じディメンションと時間の値が更新されます。 次のステップでは、Timestream for LiveAnalytics のデータモデル ( ディメンション、メジャー、メジャー名 、および必要な列の データ型 ) を構成します。この構成では、ビジュアルビルダーまたは JSON エディターのいずれかを使用できます。 データモデリングのベストプラクティス に従う事で、効果的なデータモデリングを実現します。 JSON エディター を利用して以下の情報を提供します DimensionValue (ディメンジョン)として、 vehicle_id と driver_id を使います。 MeasureValue (メジャー)としては、マイル数と engine_status を使います。 MultiMeasureName (メジャー名) には、’metric’ という固定値を使用します。要件に基づいて特定のソース列をメジャー名として選択できますが、 8,192 個の個別の値 を超えないようにしてください。 { "DimensionMappings": [ { "DimensionValue": "$.data.vehicle_id", "DimensionValueType": "VARCHAR", "DimensionName": "vehicle_id" }, { "DimensionValue": "$.data.driver_id", "DimensionValueType": "VARCHAR", "DimensionName": "driver_id" } ], "MultiMeasureMappings": [ { "MultiMeasureName": "metric", "MultiMeasureAttributeMappings": [ { "MeasureValue": "$.data.miles", "MeasureValueType": "DOUBLE", "MultiMeasureAttributeName": "miles" }, { "MeasureValue": "$.data.engine_status", "MeasureValueType": "BIGINT", "MultiMeasureAttributeName": "engine_status" } ] } ] } Visual Builder を使用してデータモデルをセットアップすることもできます。以下のスクリーンショットは、Visual Builder を使ったディメンションの設定例です。 MULTI_MEASURE_NAME と MULTI_MEASURE_VALUE に対しても同様に設定することができます。 これで、パイプの詳細設定 (アクセス許可、再試行ポリシー、 Amazon CloudWatch logs) ができるようになりました。 Pipe settings タブの Permission セクションで、新しい AWS Identity and Access Management (IAM) ロールを定義するか、既存のロールを使用できます。初めてパイプを作成する場合は、 Create a new role for specific resource を選択します。 Kinesis データストリームまたは DynamoDB ストリームをパイプのソースとして指定した場合は、オプションで再試行ポリシーとデッドレターキュー (DLQ) を設定できます。指定した保存期間より古いレコードを破棄し、失敗した場合の再試行回数を指定できます。 Retry policy では、 イベントの最大経過時間 として、少なくとも 30 分以上を使用することが推奨されます。このデモでは、30 分に設定したため、30 分より古いレコードは処理されず、DLQ に直接移動されます。 Retry attempts は 10 回に設定します。これは、一時的な問題に対処するための推奨値です。永続的な問題の場合は、再試行後にレコードが DLQ に移動され、残りのストリームのブロックが解除されます。 設定ミスによるデータ損失を避けるために、パイプの DLQ を構成することを強くお勧めします。 DLQ で Kinesis イベントのシーケンス番号を参照してレコードを修正し、Timestream に再送信できます。 DLQ を有効にするには、以下の Dead-letter queue の箇所を ON とし、使用するキューまたはトピックを選択します。このデモでは、Amazon SQS を使用し、同じ AWS アカウントと AWS リージョン内のキューを選択します。 Log destination で、ログレコードの配信先を選択します。ここでは、 CloudWatch Logs を選択します。 Log level では、EventBridge がログレコードに含める 情報のレベル を選択します。デフォルトでは、 ERROR ログレベルが選択されています。ここでは、詳細を確認できるように、 Log Level を ERROR から INFO に変更します。 ターゲットが Timestream for LiveAnalytics の場合は、 include execution data オプションを選択することをお勧めします。これにより、EventBridge はイベントのペイロード情報、サービスの要求／応答情報をログレコードに含めることができます。 EventBridge Pipes の実行データは、トラブルシューティングとデバッグに役立ちます。ペイロードフィールドには、バッチに含まれる各イベントの実際のコンテンツが含まれているため、個々のイベントを特定のパイプ実行に関連付けることができます。ただし、受信データには機密情報が含まれている可能性があり、このオプションを有効にすると、実際のイベントデータが選択したすべての宛先に記録されるため、データの機密性に基づいて正しい決定を下すようにしてください。 Create pipe を選択してパイプを作成します。 EventBridge コンソールで作成した特定のパイプに移動し、パイプが Running 状態になるまで待ちます。 ソリューションの検証 サンプルアーキテクチャの箇所で説明したように、KDG を使用してデータをストリーミングしました。この取り込みを検証するには、 Amazon Timestream for LiveAnalytics のクエリエディター を開き、次の SQL クエリを実行します。 SELECT * FROM "VehicleMetricsDB"."VehicleMetrics" limit 5 以下はクエリの結果を示しています。 要件に応じて、Timestream のクエリ言語を使用して様々な クエリ を実行できます。 考慮事項 AWS Command Line Interface (CLI) (AWS CLI)、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK) を使用して、EventBridge Pipes のパイプを作成することもできます。 また、 CloudWatch メトリクス を使用して、取り込みの進行状況の監視が可能で、EventBridge コンソールの Monitoring タブでは呼び出しと失敗を視覚化できます。トラブルシューティングについては、 Log Amazon EventBridge Pipes を参照してください。 クリーンアップ 料金の発生を回避するには、 AWS マネジメントコンソール を使用して、このデモの為に作成したリソースを削除します。 Timestream のコンソールで Timestream のデータベースとテーブルを削除 します。 EventBrdige のコンソールで作成したパイプを選択して削除します。 Kinesis Data Streams のコンソールで作成したストリームを削除します。 CloudFormation コンソールで、KDG 用に作成した CloudFormation スタックを削除 します。 結論 本投稿では、EventBridge Pipes を統合して Kinesis Data Streams からデータを Timstream for LiveAnalytics に取り込む方法を説明しました。この新しい統合は、時系列データの取り込みを簡素化するのに役立ちます。 詳細については、次のリソースを参照してください。 Amazon EventBridge Pipes error handling and troubleshooting Data Modeling Best Practices to Unlock the Value of your Time-series Data Monitoring Amazon Kinesis Data Streams 本投稿へのフィードバックについては、 Amazon Timestream の AWS re:Post に送信して下さい。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本ブログは、AI inside 株式会社と Amazon Web Services Japan が共同で執筆しました。 AI inside 株式会社 は、生成AI・LLM や自律型 AI をはじめとした最先端テクノロジーの研究開発と社会実装を行うテックカンパニーです。AI エージェント「Heylix」や AI-OCR サービス「DX Suite」に加え、それらを支える AI インフラ「AnyData」と「AI inside Cube」を、政府機関・地方公共団体・民間企業へ広く提供しています。提供する AI サービスは既に、5 万人を超えるお客様に累計 72 億回以上ご利用いただいています。 直面していたビジネス上の課題 AI inside が提供する「 DX Suite 」は、これまで手入力で行っていた帳票のデジタル化を効率的に実現する AI-OCR サービスです。多くのお客様にご利用頂いていますが、OCR 対象の書類はフォーマットが統一されていない非定型帳票も多く、フォーマット毎に AI モデルの学習が必要となるケースがあり、その対応には約 2000 万円というコストと 1 ヵ月以上の時間が発生するというビジネス上の課題がありました。 この課題を解決するために、LLM を活用した「 学習不要であらゆる帳表の読み取りを実現する機能 」の実装を進めていました。本機能を「DX Suite」を利用するユーザーに提供するためには、精度・スループット・人件費含むコスト最適化に加え、エンタープライズのお客様が望む高い水準のセキュリティを満たす LLM 環境が必要でした。 ソリューション Amazon Bedrock は、単一の API を介して AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、および Amazon といった大手 AI 企業からの高性能な基盤モデルを選択できるフルマネージドサービスです。セキュリティ、プライバシー、責任ある AI を備えた生成 AI アプリケーションを構築するために必要な幅広い機能を提供します。 AI inside は Amazon Bedrock を活用することで、精度・スループット・コストにおいて他社モデルと同等以上の水準を確保しながら、Amazon Bedrock の特徴である豊富なモデルのラインナップや最新モデルへの対応などの高い柔軟性を獲得しました。 また、セキュリティの観点からも Amazon Bedrock を採用することによってメリットがありました。「DX Suite」は Amazon Elastic Kubernetes Service (Amazon EKS) 上で稼働しており、 AWS PrivateLink を活用することで AWS 内に閉じられたネットワークで Amazon Bedrock を利用することが可能です。また Amazon Bedrock は入力情報やトレーニングに使用するデータを学習しないため、推論データの追加学習が行われないセキュアな LLM 環境を実装できます。 導入効果 AI モデルの学習に必要だった約 2000 万円の費用と 1 ヵ月以上の時間が不要になり、「DX Suite」サービス開始から 7 年間で 13 種類だった非定型帳票プリセットが、わずか 3 ヵ月で 1000 種類を超えました。また Amazon Bedrock を活用した LLM 環境を実装することによって、エンタープライズレベルの顧客が求める水準でのサービス提供が出来るようになりました。 まとめ Amazon Bedrock を活用した LLM 環境の実装によって、安価かつ短期間での多様な帳票フォーマットへの対応を実現し、エンタープライズレベルの顧客が求める水準でのサービス提供が出来るようになりました。 AI inside では、生成AIエージェント「Heylix」などの新サービスにおいても AWS の先進的なテクノロジーを活用し、高付加価値かつセキュアなサービス提供を目指します。

みなさん、こんにちは！製造業のお客様を中心に技術支援を行っているソリューションアーキテクトの山田です。 Anthropic の Claude 3.5 Sonnet が発表され、バージニアリージョンの Amazon Bedrock にてご利用頂けるようになりました。 Claude 3.5 Sonnet は Claude 3 Opus よりも高いベンチマークスコアを記録する高い能力を発揮すると同時に、Opus よりも 80 %安価に、2 倍の動作速度でご利用頂けるとされています。 Claude 3.5 Sonnet は、学部レベルの専門知識 (MMLU)、大学院レベルのエキスパート推論 (GPQA)、数学の問題解決 (MATH) などの新しい業界ベンチマークを記録しました。 このブログでは、製造業で設計開発業務に取り組まれている R&amp;D (Research and Development：研究開発) エンジニアの方を想定ユーザーとして設定させていただき、大学レベルの専門知識が問われる工学的な問題を解く際に、Claude 3.5 Sonnet を活用するポイントについて解説させていただきます。 設計開発業務において工学的な問題を解く際の課題 例えば機械の設計を行う際、この形状で強度的に問題はないかや、適切に放熱できているかなどを計算して確認する業務は頻繁に生じます。その際、機械4大力学と言われる「機械力学」「材料力学」「熱力学」「流体力学」といった専門知識を駆使して、問題の事象を捉えてモデル化し、計算を行うことになりますが、範囲が広く難解なため、何も頼らないで自分の頭だけで解けるケースはそう多くありません。大学の教科書を参照したり、該当分野に詳しい同僚に教えを請うたりしながら解いていくことになります。 しかし、問題は複雑で様々な要素が絡んでいることも多く、教科書の中の該当する箇所を問題から逆引きして見つけ出すことは難しかったり、時間がかかったりします。該当分野に詳しい同僚に教えを請う場合でも、相談にあたって時間を取ってしまいますし、専門分野が細分化されているような問題の場合は複数人に相談する必要がでてきてしまいます。 そこで、冒頭に紹介した、学部レベルの専門知識など様々な新しい業界ベンチマークを記録した Claude 3.5 Sonnet の出番です。高いベンチマークスコアを記録したからといって、万能で全ての問題を解けるというわけではないのですが、本ブログではそういった不完全な部分もある AI との向き合い方のコツについても解説させていただきます。 Claude 3.5 Sonnet を活用した問題解決の実践 Amazon Bedrock で Claude 3.5 Sonnet のような基盤モデルを有効化して、チャットのやり取りを行うための準備手順については、こちらの Amazon Bedrockの生成系AIテクノロジーを活用して設計開発業務を進化させよう というブログをご参照ください。 今回は以下のような大学レベルの流体力学の問題に直面したエンジニアのシナリオで、 プロンプト を打ち込み、どのような回答が返ってくるかを見てみます。 【プロンプト】 あなたは熟練の機械設計エンジニアです。以下の問題を解いてください。 水平に置かれた内径 d1 =20cmの管が内径 d2 = 10 cm の菅に滑らかに接続されています。内径 d1 の管内を空気が毎分 4.71 m^3 の流量で流れています。接続部の内径 d1 側における圧力 p1 は 2.00 気圧でした。接続部の内径 d2 側における流速と圧力を教えてください。ただし、摩擦による損失を無視し、空気の密度を 1.23 kg / m^3とします。 Step by Step で考えてください。 最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください。 【Claude 3.5 Sonnet からの回答】 はい、この問題を Step by Step で解いていきましょう。 Step 1 : 与えられた情報を整理します。 – d1 = 20 cm = 0.2 m – d2 = 10 cm = 0.1 m – Q (流量) = 4.71 m³/min = 0.0785 m³/s – p1 = 2.00 気圧 = 202,650 Pa (1気圧 = 101,325 Pa) – ρ (空気密度) = 1.23 kg/m³ Step 2 : d1 側の流速 v1 を計算します。 A1 = π(d1/2)² = π(0.2/2)² = 0.0314 m² v1 = Q/A1 = 0.0785/0.0314 = 2.5 m/s Step 3 : 連続の式を使用して d2 側の流速 v2 を計算します。 A1v1 = A2v2 v2 = (A1/A2)v1 = (d1/d2)²v1 = (0.2/0.1)² × 2.5 = 10 m/s Step 4 : ベルヌーイの定理を適用します。 p1 + (1/2)ρv1² = p2 + (1/2)ρv2² Step 5 : p2 を解きます。 p2 = p1 + (1/2)ρv1² – (1/2)ρv2² &nbsp; &nbsp;= 202,650 + (1/2)×1.23×2.5² – (1/2)×1.23×10² &nbsp; &nbsp;= 202,650 + 3.84375 – 61.5 &nbsp; &nbsp;= 202,592.34375 Pa ≈ 1.9994 気圧 結果: – d2 側の流速: v2 = 10 m/s – d2 側の圧力: p2 ≈ 1.9994 気圧 自信度評価: 9/10 この計算は基本的な流体力学の原理に基づいており、与えられた条件下で正確であると考えられます。ただし、実際の状況では摩擦や乱流の影響があるため、完全に現実を反映しているわけではありません。そのため、10点満点ではなく9点としました。 チャットやり取りの内容解説 まず Claude 3.5 Sonnet からの回答は正解です（人間の専門家が検証しました。Claude 3.5 Sonnet が最後に言及している通り摩擦や乱流の影響などの細かい要素を無視した場合においてです）。論理立て、計算結果、いずれも流石のベンチマークスコアを感じさせる品質でした。 プロンプトには、良い回答を返してもらうための工夫として、「あなたは熟練の機械設計エンジニアです」や「Step by Stepで考えてください」といった表現が盛り込まれています。こういった Claude へプロンプトを書く際のコツについては こちら もご参照ください。 特に、「最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください」といったような、自信度合いを問うことは、こういった難解な質問を投げかける際には重要になります。例えば以下のような簡単な質問だとどのような回答が返ってくるかを見てみましょう。 【プロンプト】 5 × 10 + 3 – 4 = ? Step by Stepで考えてください。 最終的に、正しい計算ができたかの自信度合いを10段階で評価して提示してください。 【Claude 3.5 Sonnet からの回答】 分かりました。ステップバイステップで解説し、最後に自信度合いを10段階で評価します。 &nbsp; ステップ 1 : 5 * 10 を計算します 5 * 10 = 50 ステップ 2 : 50 に 3 を足します 50 + 3 = 53 ステップ 3 : 53 から 4 を引きます 53 – 4 = 49 したがって、最終的な答えは 5 * 10 + 3 – 4 = 49 となります。 自信度合い: 10/10 この計算は非常に基本的なものなので、確信を持って正しい答えが出せたと思います。ステップバイステップで丁寧に解いたので、間違いはないはずです。 このような簡単な質問だと満点の10点で回答を返してくれました。しかし問題が難解になるほど、間違えてしまう可能性も増してきます。 そういった100%の正解が返せない場合においても、今回の流体力学の問題の例のように、自信度合いを聞いて、完全に正しいとは限らないと認識した上で、Step by Step でどのように論理立てて問題を解こうとしているかを参考にして思考の検討材料とすることは有益になると考えます。 学校の試験問題などとは異なり、現実の物理現象を扱う工学的な問題では正しい回答はどこにも存在しないケースが多々あります。手掛かりとなる参考情報を素早く与えてくれるだけで、役立つ存在となってくれることでしょう。 まとめ Claude 3.5 Sonnet は今回のケースにおいて、大学レベルの流体力学の問題を正しく解くことができました。問題が難解になるほど、間違えてしまう可能性も増してきますが、完全に正しいとは限らないと認識した上で、参考にできる情報を検討材料としてうまく活用することで、設計開発業務に役立てられるイメージを掴んでいただきました。 著者プロフィール 山田 航司&nbsp;(Koji Yamada @yamadakj) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 製造業のお客様を中心にクラウド活用の技術支援を担当しています。好きな AWS のサービスは Amazon Bedrock です。 愛読書は「大富豪トランプのでっかく考えて、でっかく儲けろ」です。

このブログは、6月20日と21日に開催された&nbsp;AWS Summit Japan&nbsp;における IoT 関連出展を紹介するものです。「プロダクト IoT 編」と「インダストリアル IoT 編」の二部構成で、今回は「インダストリアル IoT 編」についてお伝えします。（プロダクト IoT 編の記事は こちら です） 今年の AWS Summit Japan では、インダストリアル関連の IoT サービスを活用した多数のブース出展やセッションが行われました。どのコンテンツも、設備からのデータ取得だけでなく、取得したデータを様々なシーンで活用する方法を示しており、現場の課題解決に役立つ実用的な内容となっていました。ブース内で来場者との活発な質疑を交わす場面も多く見られ、実用フェーズに進んでいることが感じられました。このブログはインダストリアル IoT 編として、展示やセッションの一部をご紹介します。 カスタマーセッション 東海旅客鉄道株式会社 基調講演：ビルダーとテクノロジーが加速する次のイノベーション Breakout Session ： リニア中央新幹線における設備 IoT 化に向けて～データドリブンによる徹底的な省人化の実現～ 東海旅客鉄道株式会社のリニア開発本部では、リニア中央新幹線の運営に向けてデータ分析プラットフォームを構築しています。山梨リニア実験線での「保守用車リアルタイム状態監視」と「開閉器動作音による異常検知」の2テーマについて、 AWS プロトタイピングプログラムを活用した取り組みを、基調講演とブレイクアウトセッションの２回にわたりご紹介いただきました。 IoT サービスを活用したデータドリブン運営に向けたステップがよくわかり、リニア中央新幹線開通への期待感がますます高まる内容となっていました。 基調講演： 東海旅客鉄道株式会社 中央新幹線推進本部 リニア開発本部 副本部長&nbsp;水津 亨 氏（ オンデマンド配信 ） Breakout Session：東海旅客鉄道株式会社 中央新幹線推進本部 リニア開発本部&nbsp;宮本 真樹 氏 と藤原 海渡 氏（ オンデマンド配信 ）　 株式会社 竹中工務店、日本タタ・コンサルタンシー・サービシズ株式会社 「建設デジタルプラットフォーム」によるデジタルデータと最新技術活用の取組み&nbsp; 日本タタ・コンサルタンシー・サービシズ株式会社 長谷川 隆一 氏と、株式会社 竹中工務店 デジタル室 先進デジタル技術グループ グループ長 丘本 道彦 氏により「「建設デジタルプラットフォーム」によるデジタルデータと最新技術活用の取組み&nbsp;」というタイトルで発表頂きました。 Building4.0 の取り組みとして、 AWS IoT TwinMaker を活用したデジタルツインの検証内容について、「作業進捗管理」や「 IoT デバイスと連携した熱中症対策」などの具体例を元にご紹介いただきました。建設事業のデジタル変革が目指すビジョンがよくわかる内容となっていました。詳細は こちらの資料 をご覧ください。 AWSセッション AWS IoT SiteWise を活用したスマート工場の実現&nbsp; アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 IoT スペシャリスト ソリューションアーキテクトの新澤 雅治がプレゼンテーションを行いました。主に製造業のお客様に向けて、スマート工場の実現に向けた手段を整理し 、 AWS IoT SiteWise の re:Invent 2023 で発表された新機能を含む具体的な活用方法を、お客様事例を交えて紹介しました。また、食品工場における生成AIアシスタントのデモにより、生成AIがどのように生産効率を向上させるかをご紹介しました。詳細は オンデマンド配信 をご覧ください。 物流業におけるデジタルツイン構築の勘所&nbsp; アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ソリューションアーキテクトの戸塚 智哉がプレゼンテーションを行いました。デジタルツインは現実世界をデジタル空間に再現し、リアルタイムな監視やシミュレーションを可能にする技術ですが、現実世界のデータをどのようにクラウドで扱うのか、物流倉庫などの利用シーンをベースに、 AWS IoT サービスを使ったデザインパターンをご紹介しました。また、生成 AI と合わせることでより効果的なデジタルツインの実現についても勘所もご紹介しました。詳細は オンデマンド配信 をご覧ください。 再エネ時代のエネルギーシフトに向けたエネルギー基盤を支える AWS サービスの活用 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 エネルギー&amp;ユーティリティ部 ソリューションアーキテクト の 岩下 高志朗 がプレゼンテーションを行いました。 グローバルウォーミング、カーボンニュートラルは世界中の国々、企業が取り組んでいる社会テーマとなっております。この来るべき再エネ時代は小規模の分散電源が大量に配置されるため、再エネ発電設備の最適化、電力需要供給のバランス調整、送配電設備の拡充計画などが重要となってきます。このようなニーズに対して、必要な業務機能群を整理し、そのような領域で活用できる AWS サービスの紹介と活用例を紹介しました。 詳細は オンデマンド配信 をご覧ください。 展示ブース 東海旅客鉄道株式会社/東海交通機械株式会社 AWS Village での東海旅客鉄道株式会社/東海交通機械株式会社様の共同ブースでは、 IoT を活用した鉄道機械設備のリモートモニタリングの展示が行われていました。設備が古く遠隔監視ができない機械や設備に対して、改修工事が不要な可搬式の電流センサー、温度センサーなどを設置し、 AWS IoT Greengrass を使って Amazon S3 へのデータ収集、 Amazon QuickSight による可視化を行うことで、遠隔地にある機械や設備のデータを事務所内で確認できることが実機とともに展示・紹介されていました。その他、 IoT で収集したデータを予兆保全につなげる事例など、鉄道機械設備における AWS の実活用事例が紹介されていました。 &nbsp;AWS 展示：クラウドで進化する鉄道機械保守 AWS Village の鉄道業向け AWS ブースでは、 IoT を使った鉄道機械設備管理システムのデモが行われていました。このデモでは、架空の駅の改札機やエレベーターなどを模擬した設備データを AWS IoT SiteWise で収集し、そのデータを基にしたアラーム監視や保全方法のリコメンドを Amazon Bedrock から受ける場面が再現されていました。また、遠隔地にある複数の駅のデータを構造化して保存し、横断的に可視化するダッシュボードなどがデモされており、クラウド利用の価値を実感できる内容となっていました。 &nbsp;AWS 展示：スマート X サステナビリティ ビル管理&nbsp; AWS&nbsp; IoT サービスを活用したスマート サステナビリティビル管理&nbsp;「サステナビリティを意識したミニチュア倉庫のデモを作ってみた !」 AWS IoT を活用し、持続可能性のソリューションライブラリの一つである 「Guidance for Smart and Sustainable Buildings on AWS」 を参考に、可視化したデータから省エネルギー化の洞察を得て、電力、費用及び温室効果ガス ( GHG ) 排出量の削減を実現するソリューションの実装例のデモを展示致しました。 「サステナビリティを意識したミニチュア倉庫のデモを作ってみた !」 でもご紹介している、 Amazon の倉庫を模したミニチュアモデルおいて、室温や空気の質をデータに基づいて適切に管理することで省エネルギーにつながる過程をご紹介しました。 AWS 展示：小さく早く始める効率化 – 製造現場の IoT データをパートナーとともに　 小さく早く製造 DX を実現 スマート工場の様々なユースケースをミニチュア工場を使って表現したデモが展示されました。 PLC のデータを AWS IoT SiteWise に集約し、構造的にデータを保持することで、他の様々なソリューションが活用しやすくなっています。工場内のオペレータ向けの稼働可視化ダッシュボードだけでなく、 Salesforce Field Service やパトライトの ネットワーク制御信号灯 などの AWS パートナーソリューションを活用したアーキテクチャも紹介されました。また、 4M 変化点情報を生成 AI の元データとして使用することで、生成AI の効果を発揮できる可能性についても提示しました。 AWS 展示：小さく早く始める効率化 – 製造業の課題に挑む AI ソリューション 工場における「外観検査モデル立ち上げ」と「生産設備のリアルタイム監視と障害対応」の2つのユースケースを、生成 AI を用いて効率化するデモを展示しました。このデモでは、外観検査の機械学習モデル作成に必要な学習画像を準備できないという課題を、生成 AI を用いて画像生成することで解決しています。また、チャットに対して設備状態を問い合わせると、リアルタイムな設備の使用状況や設備の仕様やプログラム、障害対応手順に基づいて生成AIを用いたレスポンスを受けることができています。生成 AI を用いることで、生産現場のさらなる効率化の可能性を見ることができました。 東京ガス 株式会社 東京ガス 株式会社 のブースでは、 OT データをクラウドに集約し、最適制御や予知保全などのデータ活用を可能にするソリューションが展示されていました。当社が提供する国内トップシェアの SCADA ソフトである JoywatcherSuite と JoyCloudConnect に、 AWS IoT Core との MQTT 通信機能をプラグインすることで実現しています。 AWS 専用の接続設定があらかじめ準備されているため、短時間で AWS との接続が完了します。プラントデータのクラウド接続方法がわからずに悩んでいるユーザーにとって、有効な選択肢となりそうです。 アイレット株式会社 アイレット株式会社のブースでは、本物の6軸ロボットを使用した生産状況可視化とトラブル分析の効率化を実現するデモが展示されていました。 AWS IoT SiteWise の稼働データと Kinesis Video Streams のカメラ映像を 1 枚のダッシュボードで統合的に表示し、異常が検知された前後の映像を自動で記録することで、後で遡って原因分析を行うことができます。トラブル発生前後の動画とデータを使って原因分析を行うことで、復旧までの時間短縮につながります。トラブルの原因究明に多くの時間をかけているユーザーにとって有効なソリューションとなりそうです。 富士ソフト株式会社 富士ソフト株式会社のブースでは、カメラ映像と IoT データを組み合わせた、クラウド型設備管理ソリューションのデモが展示されていました。現場の３次元画像と IoT データを統合したダッシュボードでAmazon Bedrockにより、自然言語で会話的に設備についての質問ができます。「エラーが一番多い場所に移動したい」、「ナースコールが鳴っている場所に移動したい」、「○○センサーの単位は？」など、日本語による会話で設備の現在の状態について問い合わせたり、見たい場所に移動することができます。まさにデジタルツインを体現したデモとなっていました。また、森田 和明氏による著書、 AWSの生成AIサービスを体系的に解説した入門書として&nbsp; Amazon Bedrock 生成AIアプリ開発入門 [AWS深掘りガイド] &nbsp; も出版されています。 スマート工場のための収集・可視化・分析 SCSK株式会社 SCSK 株式会社では、製造現場の可視化・分析のためのソリューション“Duetics（デュエティクス）“を工場を模した模型に接続して展示されていました。AWSでも同じ模型を使ってデモをしていますが、こちらの展示では PLC を国内でシェアの高い三菱電機製に交換したり、クラウド側での大規模な分析ソリューションと接続し、日本のお客様にスマート工場のデータ収集・可視化・分析をすぐにでも導入できるような内容となっていました。 オムロン株式会社: 汎用性の高い技術で構築された IoT 端末可視化 オムロン株式会社のブースでは、 IoT の可視化環境をテンプレート化することにより、様々なお客様にむけた環境構築を効率的に進められるというご紹介をされていました。これによりビル管理や、加工機械等の工場の装置を遠隔監視する仕組みを多数のお客様に提供されています。工場等において、OT ネットワークとの接続が難しい場合にはセルラー回線と組み合わせたり、ビル等の工場以外では、オムロン株式会社独自のセンサーと通信モジュールを組み合わせた最適なソリューションを提供するというセンサーメーカーならではの展示をされていました。 AWS:&nbsp; AIによるプラント保守 – 生成AI・映像・音声と外付けセンサーによるプラント保守支援&nbsp; この展示では、プラント管理における技術継承を題材に、プラントを模した流体回路にセンサーを設置して AWS IoT Core で情報収集し、異常を発生させ、機器のエラー番号からのトラブルシュートを生成AIで行うデモを展示しました。 PLC から受け取ったエラーコードをもとに、過去の報告書から Bedrockが「想定される原因」「過去の対応策」「推奨作業事項」を提示しており、シアター形式で行われて大人気を博しました。詳細は こちらのブログ からご覧いただけます。 AWS: 小さく早く始める効率化 – Software Defined Factory システムインテグレータや、企業内の DX 部門は、工場の DX 化のための OT へのアクセスが簡単ではなく、一方で早く完成イメージを提示し活動を推進したいというジレンマを抱えています。この展示では、OT に見立てたクラウド上の仮想ネットワーク ( Amazon VPC ) 上で、機器をシミュレートするプログラムを動かし、AWS CDK を使って OT とクラウドのソリューション構築を自動化することで、OT にアクセスする前に可視化ソリューションを構築するアプローチを提示しました。 まとめ AWS Summit Japan 2024のインダストリアルIoTのコンテンツは、データの可視化だけでなく、デジタルツインや生産性向上など、IoTが実際の業務に直結する段階に進んでいることが感じられました。また、新しい流れとして、IoT と生成 AI を組み合わせたソリューションのアイデアも多く出展されており、今後のさらなる発展が楽しみです。AWS では、今後も IoT の可能性とビジネスを追求するカスタマの支援を加速していきます！ 著者 山本 直志 Industry Specialist Solutions Architect 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 新澤　雅治 IoT Specialist Solutions Architect 製造業、 IT ベンダーを経て AWS に 入社。現在は IoT スペシャリストソリューションアーキテクトとして、主に製造業のお客様のIndustrial IoT 関連案件の支援に携わる。

お客様から Amazon Elastic Container Service (Amazon ECS) に AWS CodeDeploy を使用して ブルー/グリーン デプロイを実装するための支援がしばしば求められます。 お客様のユースケースは通常、クロスリージョンおよびクロスアカウント間でのデプロイシナリオが含まれます。 これらの要件だけでも十分に難しいのですが、さらに CodeDeploy を使用する際には特定の設計上の決定が必要となります。 具体的には CodeDeploy の設定方法、CodeDeploy リソース (アプリケーションやデプロイグループなど) の作成時期と方法、アカウントとリージョンの任意の組み合わせにデプロイできるコードの書き方が含まれます。 本日は、そうした設計上の決定について詳細に説明し、 CDK Pipelines を使用してアカウントとリージョンをまたぐシナリオで Amazon ECS へサービスをデプロイする self-mutation パイプラインを実装する方法について説明します。このブログ記事では、 AWS Cloud Development Kit (AWS CDK) を使用したクラウドインフラストラクチャの開発とデプロイのための ベストプラクティス に従っている Java 製の デモアプリケーション も紹介します。記事中で言及されるコードはデモアプリケーションの実装です。 パイプラインの概要 CDK Pipelines は、さまざまな デプロイエンジン でパイプラインを構築するために使用されるコンストラクトライブラリです。 クロスリージョンやクロスアカウントのパイプラインを実装する際に、開発者やインフラストラクチャエンジニアが解決する必要がある実装の詳細を抽象化しています。 例えば、クロスリージョンのシナリオでは、 AWS CloudFormation はターゲットリージョンに複製されたアーティファクトを必要とします。 そのため、 AWS Key Management Service (AWS KMS) キー、 Amazon Simple Storage Service (Amazon S3) バケット、ポリシーをセカンダリリージョンに作成する必要があり、リージョン間でアーティファクトを移動できるようになります。 また、クロスアカウントのシナリオでは、CodeDeploy は構成ファイルの暗号化に使用される KMS キーへのアクセス権を持つクロスアカウントロールを必要とします。 これらはお客様が手作業で対処したくないものの一例です。 AWS CodeDeploy は、さまざまなシナリオでアプリケーションのデプロイを自動化するデプロイサービスです。Amazon EC2 インスタンス、オンプレミスインスタンス、 Lambda 関数、または Amazon ECS サービスにデプロイします。 AWS Identity and Access Management (AWS IAM) と統合して、アプリケーションをデプロイする際のアクセス制御を実装できます。 ブルー/グリーン型のデプロイでは、Amazon CloudWatch Alarms を使ってデプロイのロールバックを自動化できます。 CDK Pipelines は、AWS CloudFormation のデプロイを自動化するように設計されました。 AWS CDK を使用すると、これらの CloudFormation デプロイでは、インスタンスやコンテナへのアプリケーションのデプロイを含めることができます。 ただし、一部のお客様は、アプリケーションのデプロイに CodeDeploy を使用することを好みます。 この AWS ブログ記事では、CloudFormation ではなく CodeDeploy を使用した CDK Pipelines のデプロイを紹介します。 設計上の考慮事項 この記事では、CodeDeploy を使用してサービスをアカウント (シングルアカウントまたはクロスアカウント) およびリージョン (シングルリージョンまたはクロスリージョン) の任意の組み合わせにデプロイするための、さまざまなユースケースに CDK Pipelines を活用することを検討します。 具体的には、以下の 4 つの問題を解決する必要があります。 CodeDeploy の設定 CodeDeploy を使ってブルー/グリーンデプロイタイプを実装するための最も一般的なオプションは、 AWS::CodeDeployBlueGreen マクロ を使うか、CodeDeploy コンストラクトを使うことです。この記事では後者の方法を採用します。同じ問題をカスタムリソースを使って解決しているお客様もいますが、この方法はカスタムリソースを使わない柔軟な方法です。パイプラインは実行のたびにコンテナを Amazon Elastic Container Registry (ECR) にプッシュし、タグを作成します。CodeDeploy はその情報をコンテナのデプロイに使います。 ここで推奨したいのは、AWS CDK クラウドアセンブリをスキャンし、リポジトリとタグ情報を取得するためにパイプラインアクションを作成することです。同じアクションで CodeDeploy 設定ファイルの作成を行うこともできます。CodeDeploy を設定するには、 appspec.yaml 、 taskdef.json 、 imageDetail.json の 3 つの設定ファイルが必要です。 このパイプラインアクションは、CodeDeploy デプロイアクションの前に実行する必要があります。 appspec.yaml と taskdef.json のテンプレートファイルを作成し、 次のスクリプト をパイプライン内で実行することで3つの設定ファイルを作成することができます。 ## #!/bin/sh # # AWS CodeDeploy の設定を行うアクション # template-appspec.yaml と template-taskdef.json を元に環境に応じた設定ファイルを作成します # # Account = The Account Id # AppName = Name of the application # StageName = Name of the stage # Region = Name of the region (us-east-1, us-east-2) # PipelineId = Id of the pipeline # ServiceName = Name of the service. It will be used to define the role and the task definition name # # Primary output directory is codedeploy/. All the 3 files created (appspec.json, imageDetail.json and # taskDef.json) will be located inside the codedeploy/ directory # ## Account=$1 Region=$2 AppName=$3 StageName=$4 PipelineId=$5 ServiceName=$6 repo_name=$(cat assembly*$PipelineId-$StageName/*.assets.json | jq -r '.dockerImages[] | .destinations[] | .repositoryName' | head -1) tag_name=$(cat assembly*$PipelineId-$StageName/*.assets.json | jq -r '.dockerImages | to_entries[0].key') echo ${repo_name} echo ${tag_name} printf '{"ImageURI":"%s"}' "$Account.dkr.ecr.$Region.amazonaws.com/${repo_name}:${tag_name}" &gt; codedeploy/imageDetail.json sed 's#APPLICATION#'$AppName'#g' codedeploy/template-appspec.yaml &gt; codedeploy/appspec.yaml sed 's#APPLICATION#'$AppName'#g' codedeploy/template-taskdef.json | sed 's#TASK_EXEC_ROLE#arn:aws:iam::'$Account':role/'$ServiceName'#g' | sed 's#fargate-task-definition#'$ServiceName'#g' &gt; codedeploy/taskdef.json cat codedeploy/appspec.yaml cat codedeploy/taskdef.json cat codedeploy/imageDetail.json ツールチェーンの利用 効果的な戦略は、パイプラインをツールチェーンにカプセル化して、さまざまなアカウントやリージョンへのデプロイ方法を抽象化することです。これにより、パイプラインの作成方法、CodeDeploy の設定方法、および別のアカウントやリージョンへの展開方法など、実装の詳細を切り離すことができます。パイプラインを作成するには、 デモアプリケーション 内の Toolchain スタックをデプロイします。これは必要に応じて別の環境を追加できるようになっています。要件によってはコンポーネントごとに異なる Stage や Wave を反映するように、パイプラインをカスタマイズする必要があります。より詳細な情報は、 安全なハンズオフデプロイの自動化 とその リファレンス実装 を参照してください。 Toolchain スタックは、Java 用 CDK 全体で使われている Builder パターンに従っています。これは、1 つの文で複雑なオブジェクトを作成できる便利な機能です。 Toolchain.Builder.create(app, Constants.APP_NAME+"Toolchain") .stackProperties(StackProps.builder() .env(Environment.builder() .account(Demo.TOOLCHAIN_ACCOUNT) .region(Demo.TOOLCHAIN_REGION) .build()) .build()) .setGitRepo(Demo.CODECOMMIT_REPO) .setGitBranch(Demo.CODECOMMIT_BRANCH) .addStage( "UAT", EcsDeploymentConfig.CANARY_10_PERCENT_5_MINUTES, Environment.builder() .account(Demo.SERVICE_ACCOUNT) .region(Demo.SERVICE_REGION) .build()) .build(); 上記では、CDパイプラインが TOOLCHAIN_ACCOUNT と TOOLCHAIN_REGION で作成されています。 このパイプラインには、Apache Maven を使ってソースコードをビルドし、Java アーカイブ (JAR) を作成するステージが実装されています。 その後、パイプラインは JAR ファイルを含む Docker イメージを作成します。 UAT ステージでは、 CANARY_10_PERCENT_5_MINUTES のデプロイ設定を使用して、サービスを SERVICE_ACCOUNT と SERVICE_REGION にデプロイします。 つまり、最初に 10% のトラフィックが新しいアプリケーションに移行され、残りの 90 % が 5 分後にデプロイされます。 追加のデプロイステージを作成するには、 ステージ名 、CodeDeploy の デプロイ設定 、そしてサービスをデプロイすべき 環境 が必要です。先に述べたように、このパイプラインはデフォルトで自身を変更する Self-mutation パイプラインです。たとえば、 Prod ステージを追加するには、 Toolchain オブジェクトを作成する CDK コードを更新し、この変更をコードリポジトリに送信します。パイプラインが実行され、 UAT ステージの後に Prod ステージが追加されてパイプライン自身が更新されます。次に示すのは、新しい Prod ステージを追加するコードです。新しいステージは UAT 環境と同じアカウントおよびリージョンにデプロイされます。 ... .addStage( "Prod", EcsDeploymentConfig.CANARY_10_PERCENT_5_MINUTES, Environment.builder() .account(Demo.SERVICE_ACCOUNT) .region(Demo.SERVICE_REGION) .build()) .build(); 上記の文では、 Prod ステージが CodeDeploy の デプロイ構成 CANARY_10_PERCENT_5_MINUTES を使用して、新しいバージョンのサービスをデプロイします。 つまり、最初に 10 % のトラフィックが新しいバージョンのアプリケーションに移行され、5 分後に残りのトラフィックが新しいバージョンに移行されるということです。 ビジネスアプリケーションの分離と管理のベストプラクティスについては、 複数のアカウントを使用した AWS 環境の構成 ホワイトペーパーを参照してください。 一部のお客様は、このアプローチに興味を持たれ、アプリケーション開発チームへの抽象化されたソリューションとして提供することを決定するかもしれません。 その場合、そのようなパイプラインを構築するコンストラクトを作成することをお勧めします。コンストラクトを使うと、さらにカスタマイズできます。 例えば、品質保証を促進するステージや、災害復旧シナリオでサービスをデプロイするステージなどです。 この実装では、ツールチェーンスタックと、各デプロイステージ用のスタックを作成します。たとえば、 UAT という単一のデプロイステージでツールチェーンが作成された場合を考えましょう。 正常に実行されると、次の画像のように DemoToolchain および DemoService-UAT スタックが作成されます。 CodeDeploy アプリケーションとデプロイグループ CodeDeploy の構成には、アプリケーションとデプロイグループが必要です。ユースケースによっては、ツールチェーン (パイプライン) と同じアカウントあるいは別のアカウントでこれらを作成する必要があります。パイプラインには、ブルー/グリーンデプロイを実行する CodeDeploy デプロイアクションが含まれています。 私の推奨は、CodeDeploy アプリケーションとデプロイグループをサービススタックの一部として作成することです。 このアプローチにより、CodeDeploy アプリケーションとデプロイグループのライフサイクルを関連するサービススタックインスタンスと合わせることができます。 CodePipeline を使うと、存在しない CodeDeploy アプリケーションとデプロイグループを参照する CodeDeploy デプロイアクションを作成できます。 これにより、以下のアプローチを実装できます。 ツールチェーンスタックは、存在しない CodeDeploy アプリケーションとデプロイグループを参照するデプロイアクションでパイプラインをデプロイします パイプラインが実行されると、まず関連する CodeDeploy アプリケーションとデプロイグループを作成するサービススタックがデプロイされます 次のパイプラインアクションでデプロイアクションが実行されます。パイプラインがデプロイアクションを実行する段階では、必要な CodeDeploy アプリケーションとデプロイグループが（前のステップで作成されたため）存在しています。 以下は、(最初は存在しない) CodeDeploy アプリケーションおよびデプロイグループを参照するパイプラインコードです。 private IEcsDeploymentGroup referenceCodeDeployDeploymentGroup( final Environment env, final String serviceName, final IEcsDeploymentConfig ecsDeploymentConfig, final String stageName) { IEcsApplication codeDeployApp = EcsApplication.fromEcsApplicationArn( this, Constants.APP_NAME + "EcsCodeDeployApp-"+ stageName, Arn.format(ArnComponents.builder() .arnFormat(ArnFormat.COLON_RESOURCE_NAME) .partition("aws") .region(env.getRegion()) .service("codedeploy") .account(env.getAccount()) .resource("application") .resourceName(serviceName) .build())); IEcsDeploymentGroup deploymentGroup = EcsDeploymentGroup.fromEcsDeploymentGroupAttributes( this, Constants.APP_NAME + "-EcsCodeDeployDG-"+ stageName, EcsDeploymentGroupAttributes.builder() .deploymentGroupName(serviceName) .application(codeDeployApp) .deploymentConfig(ecsDeploymentConfig) .build()); return deploymentGroup ; } これを機能させるには、パイプラインで CodeDeploy デプロイアクションを作成するときと、サービススタック (Amazon ECS インフラストラクチャがデプロイされている) で CodeDeploy アプリケーションとデプロイグループを作成するときで、同じアプリケーション名とデプロイグループ名の値を使用する必要があります。 このアプローチが必要な理由はサービススタック内で作成したリソースを参照して CodeDeply デプロイアクションを設定すると循環依存エラーが発生するためです。 以下は、サービススタックコンストラクト ID を使用して CodeDeploy アプリケーションとデプロイグループに名前を付けるコードです。 パイプラインで CodeDeploy デプロイアクションを作成する際に使用したのと同じ名前をサービススタックのコンストラクト ID に設定しています。 // configure AWS CodeDeploy Application and DeploymentGroup EcsApplication app = EcsApplication.Builder.create(this, "BlueGreenApplication") .applicationName(id) .build(); EcsDeploymentGroup.Builder.create(this, "BlueGreenDeploymentGroup") .deploymentGroupName(id) .application(app) .service(albService.getService()) .role(createCodeDeployExecutionRole(id)) .blueGreenDeploymentConfig(EcsBlueGreenDeploymentConfig.builder() .blueTargetGroup(albService.getTargetGroup()) .greenTargetGroup(tgGreen) .listener(albService.getListener()) .testListener(listenerGreen) .terminationWaitTime(Duration.minutes(15)) .build()) .deploymentConfig(deploymentConfig) .build(); CDK Pipelines のロールと権限 CDK Pipelines は、さまざまなシナリオ (リージョンやアカウントなど) においてデプロイを実行するためのロールとアクセス許可を作成します。 CodeDeploy を別のアカウントで実行する際、CDK Pipelines はクロスアカウントのサポートスタックをデプロイします。このサポートスタックは、CodeDeploy アクションのためのパイプラインアクションロールを作成します。 このクロスアカウントのサポートスタックは JSON ファイルに定義されており、対象アカウントの AWS CDK の Assets バケットにアップロードする必要があります。 パイプラインで self-mutation 機能が有効 (デフォルト) の場合、UpdatePipeline ステージでは cdk deploy を実行し、パイプラインへの変更をデプロイします。 クロスアカウントのシナリオでは、このデプロイにはクロスアカウントのサポートスタックのデプロイ/更新も含まれます。 このため、UpdatePipeline ステージの SelfMutate アクションは、リモートアカウントで CDK の ファイル公開 と デプロイ のロールを引き受ける必要があります。 UpdatePipeline ステージを実行する AWS CodeBuild プロジェクトに関連付けられている IAM ロールには、デフォルトではこれらのアクセス許可がありません。 CDK Pipelines は、クロスアカウントスタックに必要なアクセス許可の情報は AWS CDK アプリの合成が終わった後でしか利用できないため、これらのアクセス許可を自動的に付与することはできません。その時点では、パイプラインのアクセス許可がすでにロックされています。 したがって、クロスアカウントのシナリオでは、ツールチェーンがパイプラインの UpdatePipeline ステージのアクセス許可を拡張して、 ファイル公開 と デプロイ のロールを含める必要があります。 クロスアカウント環境では、これらのアクセス許可を手動で UpdatePipeline ステージに追加することが可能です。そのためには、 Toolchain スタックを使用して、このような実装の詳細を隠すことができます。最終的には、以下のようなメソッドを使用して、不足しているアクセス許可を追加できます。パイプライン内の各異なるステージとアカウントのマッピングについて、ターゲットアカウントがパイプラインがデプロイされているアカウントと異なるかどうかを検証します。条件を満たした場合は、UpdatePipeline ステージに対して、ターゲットアカウントの CDK ブートストラップロールを引き受ける権限を付与する必要があります (キー aws-cdk:bootstrap-role で、タグ値は file-publishing または deploy )。以下の例は、UpdatePipeline ステージにアクセス許可を追加する方法を示しています。 private void grantUpdatePipelineCrossAccoutPermissions(Map stageNameEnvironment) { if (! stageNameEnvironment.isEmpty()) { this.pipeline.buildPipeline(); for (String stage : stageNameEnvironment.keySet()) { HashMap condition = new HashMap&lt;&gt;(); condition.put( "iam:ResourceTag/aws-cdk:bootstrap-role", new String[] {"file-publishing", "deploy"}); pipeline.getSelfMutationProject() .getRole() .addToPrincipalPolicy(PolicyStatement.Builder.create() .actions(Arrays.asList("sts:AssumeRole")) .effect(Effect.ALLOW) .resources(Arrays.asList("arn:*:iam::" + stageNameEnvironment.get(stage).getAccount() + ":role/*")) .conditions(new HashMap() {{ put("ForAnyValue:StringEquals", condition); }}) .build()); } } } デプロイステージ UAT という単一のデプロイステージがあるパイプラインを考えてみましょう。 UAT ステージでは DemoService をデプロイします。それには 4 つのアクション: DemoService-UAT (準備とデプロイ)、ConfigureBlueGreenDeploy 、そして Deploy が必要です。 DemoService-UAT.Deploy アクションは ECS リソースと CodeDeploy アプリケーションとデプロイグループを作成します。ConfigureBlueGreenDeploy アクションは CDK クラウドアセンブリ から ECR リポジトリやコンテナイメージのタグ情報を読み取ります。パイプラインはこの情報をデプロイアクションに送り、CodeDeploy を使ったデプロイが開始されます。 ソリューションの概要 利便性のため、これらすべての課題を解決し、リファレンス実装として使える Java アプリケーション を作成しました。 このアプリケーションのデプロイは、アカウントやリージョンでのすべてのデプロイシナリオで同じ 5 つのステップに従い、次の設計に表されているシナリオも含まれます。 結論 この投稿では、アカウントとリージョンの様々な組み合わせで CodeDeploy を使用して Amazon ECS にサービスをデプロイするパイプラインを作成する際に伴う課題を特定、説明、解決しました。 また、これらの推奨事項を実装するデモアプリケーションを紹介しました。 サンプルコードを拡張して、自動テスト、自動デプロイロールバック、障害復旧など、より複雑なシナリオを実装できます。 あなたの変革の旅がうまくいくことを願っています。 Luiz Decaro Luiz は、アマゾンウェブサービス (AWS) のプリンシパルソリューションアーキテクトです。彼は金融サービス業界のお客様がクラウドで成功できるよう支援することに重点を置いています。Luiz はソフトウェアエンジニアリングの修士号を取得しており、2005 年に最初の継続的デプロイパイプラインを立ち上げました。 本記事は、 Luiz Decaro による “Blue/Green deployments using AWS CDK Pipelines and AWS CodeDeploy” を翻訳したものです。翻訳はソリューションアーキテクトの平川 大樹が担当しました。