2024 年 7 月 10 日水曜日に開催される、1 年に 1 度の弊社最大のイベントの 1 つである ニューヨーク市での AWS Summit の興奮に備えましょう。実地での参加は満席ですが、基調講演を視聴するための登録はまだ受け付けています。基調講演では、AWS VP for AI Products である Matt Wood 博士が、AWS の最新のリリースと技術的なイノベーションを発表します。その後、このページでは、お客様が見逃すことのないように、極めてエキサイティングな製品ニュースの役立つまとめをお届けします。 基調講演のライブストリームを視聴するには、こちらからご登録ください。 (この記事の最終更新日時:2024 年 7 月 9 日午後 2 時 45 分 (PST))。 2024 年 7 月 9 日の AWS からのお知らせ Integrate your data and collaborate using data preparation in AWS Glue Studio AWS Glue の新しいビジュアルインターフェイスを使用すると、データチームは共同で ETL パイプラインを構築し、直感的で共有可能なキャンバスを通じてアナリストとエンジニアの間のギャップを埋めることができます。 原文は こちら です。

7月9日、 AWS Glue Studio Visual ETL でのデータ準備オーサリングの一般提供を開始することをお知らせします。これは、ビジネスユーザーとデータアナリスト向けの新しいノーコードデータ準備ユーザーエクスペリエンスで、スプレッドシートスタイルの UI を備えており、AWS Glue for Spark でデータ統合ジョブを大規模に実行します。新しいビジュアルデータ準備エクスペリエンスにより、データアナリストとデータサイエンティストは、データをクリーンアップして変換し、分析と機械学習 (ML) 用に準備することが容易になります。この新しいエクスペリエンスでは、数百の事前構築済みの変換から選択して、データ準備タスクを自動化できます。コードを記述する必要はありません。 ビジネスアナリストは、データエンジニアと協力してデータ統合ジョブを構築できるようになりました。データエンジニアは、Glue Studio のビジュアルフローベースのビューを使用して、データへの接続を定義したり、データフロープロセスの順序を設定したりできます。ビジネスアナリストは、データ準備エクスペリエンスを使用して、データ変換と出力を定義できます。さらに、既存の AWS Glue DataBrew データクレンジングおよび準備「レシピ」を新しい AWS Glue データ準備エクスペリエンスにインポートできます。この方法では、引き続き AWS Glue Studio で直接オーサリングし、レシピをスケールアップして、 AWS Glue ジョブのためにより低い料金ポイント でペタバイト単位のデータを処理できます。 ビジュアル ETL の前提条件 (環境設定) ビジュアル ETL には、 AWS Glue にアクセスするユーザーとロールにアタッチされた AWSGlueConsoleFullAccess IAM マネージドポリシー が必要です。 このポリシーは、AWS Glue へのフルアクセスと、 Amazon Simple Storage Service (Amazon S3) リソースへの読み取りアクセスを、これらのユーザーとロールに付与します。 高度なビジュアル ETL フロー 適切な AWS Identity and Access Management (IAM) ロール許可が定義されたら、AWS Glue Studio を使用してビジュアル ETL をオーサリングします。 抽出 [ソース] のリストから Amazon S3 ノードを選択して、Amazon S3 ノードを作成します。 新しく作成したノードを選択し、S3 データセットを参照します。ファイルが正常にアップロードされたら、 [スキーマを推測] を選択してソースノードを設定すると、ビジュアルインターフェイスに .csv ファイルに含まれるデータのプレビューが表示されます。 私は以前、AWS Glue ビジュアル ETL と同じリージョンに S3 バケットを作成し、視覚化するデータを含む .csv ファイルである visual ETL conference data.csv をアップロードしました。 前のステップで詳しく説明したように、S3 バケットを読み取るためのアクセスを AWS Glue に付与するロール許可を設定することが重要です。このステップを実行しないと、エラーが発生し、最終的にデータプレビューが表示されなくなります。 変換 ノードが設定されたら、データ準備レシピを追加して、データプレビューセッションを開始します。このセッションの開始には通常約 2～3 分かかります。 データプレビューセッションの準備ができたら、 [レシピをオーサリング] を選択してオーサリングセッションを開始し、データフレームが完成したら変換を追加します。オーサリングセッション中は、データの表示、変換ステップの適用、変換されたデータのインタラクティブな表示が可能です。ステップを元に戻したり、やり直したりできるほか、ステップの順序を変更することもできます。列のデータ型と各列の統計プロパティを視覚化できます。 [ステップを追加] を選択して、小文字から大文字への形式変更、並べ替え順序の変更など、データへの変換ステップの適用を開始できます。すべてのデータ準備ステップはレシピで追跡されます。 南アフリカで開催される会議のビューが必要だったため、 [場所] 列の値が「South Africa」と等しく、 [コメント] 列に値が含まれているという条件でフィルタリングする 2 つのレシピを作成しました。 ロード インタラクティブにデータを準備したら、データエンジニアと作業内容を共有できます。データエンジニアは、より高度なビジュアル ETL フローとカスタムコードを使用してその作業内容を拡張し、本番データパイプラインにシームレスに統合できます。 今すぐご利用いただけます AWS Glue データ準備オーサリングエクスペリエンスは、AWS Data Brew が利用可能なすべての商用 AWS リージョン で一般提供されています。詳細については、 AWS Glue にアクセスしてください。 詳細については、「 AWS Glue デベロッパーガイド 」にアクセスしてください。また、 AWS re:Post for AWS Glue または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Veliswa 原文は こちら です。

7月9日、 re: Invent 2023 からプレビュー版として 提供されていた新しい AWS Graviton4 ベースの Amazon Elastic Compute Cloud (Amazon EC2) R8g インスタンスが一般公開されたことをお知らせします。AWS は、150 種類以上の AWS Graviton 搭載の Amazon EC2 インスタンスタイプを世界中で大規模に提供し、200 万個以上の Graviton プロセッサを構築してきました。また、5 万社を超えるお客様が AWS Graviton ベースのインスタンスを使用して、アプリケーションで最高のコストパフォーマンスを実現しています。 AWS Graviton4 は、AWS がこれまで設計した中でも最も強力かつエネルギー効率の高いプロセッサであり、Amazon EC2 で実行される幅広いワークロードにご使用いただけます。他のすべての AWS Graviton プロセッサと同様、AWS Graviton4 は 64 ビットの Arm 命令セットアーキテクチャを採用しています。AWS Graviton4 ベースの Amazon EC2 R8g インスタンスは、AWS Graviton3 ベースの Amazon EC2 R7g インスタンスと比較して、最大 30% 優れたパフォーマンスを提供します。これにより、高性能データベース、インメモリキャッシュ、リアルタイムのビッグデータ分析など、要求の厳しいワークロードのパフォーマンスを向上させることができます。 re: Invent 2023 でのプレビュー版の発表以来、Epic Games、SmugMug、Honeycomb、SAP、ClickHouse を含む 100 社以上のお客様が、AWS Graviton4 ベースの R8g インスタンス でワークロードをテストし、同等のインスタンスと比較してパフォーマンスが大幅に向上していることを確認しました。SmugMug では、画像とデータの圧縮操作において、AWS Graviton4 ベースのインスタンスを使用した場合、AWS Graviton3 ベースのインスタンスと比較してパフォーマンスが 20～40% 向上しました。Epic Games は、AWS Graviton4 インスタンスがこれまでにテストした中で最速の EC2 インスタンスであることを確認しました。Honeycomb.io は、4 年前に使用していた非 Graviton ベースのインスタンスと比較して、vCPU あたりのスループットが2倍以上になったと報告しています。 新しいインスタンスにおける改善点をいくつか見てみましょう。R8g インスタンスは、R7g インスタンスと比較して最大 3 倍の vCPU (最大 48xl)、3 倍のメモリ (最大 1.5 TB)、75% 増のメモリ帯域幅、2 倍の L2 キャッシュを備え、より大きいインスタンスサイズを提供します。これにより、大量のデータの処理、ワークロードのスケールアップ、結果が出るまでの時間の短縮、TCO の削減を実現します。また、Graviton3 ベースのインスタンスが最大 30 Gbps のネットワーク帯域幅と最大 20 Gbps の EBS 帯域幅を提供するのに対して、R8g インスタンスは、最大 50 Gbps のネットワーク帯域幅と最大 40 Gbps の EBS 帯域幅を提供します。 R8g インスタンスは、2 つのベアメタルサイズ (metal-24xl と metal-48xl) を提供する初の Graviton インスタンスです。インスタンスを適切なサイズに設定し、物理リソースへの直接アクセスからメリットを得るワークロードをデプロイできます。R8g インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ ネットワーク帯域幅 EBS 帯域幅 r8g.medium 1 8 GiB 最大 12.5 Gbps 最大 10 Gbps r8g.large 2 16 GiB 最大 12.5 Gbps 最大 10 Gbps r8g.xlarge 4 32 GiB 最大 12.5 Gbps 最大 10 Gbps r8g.2xlarge 8 64 GiB 最大 15 Gbps 最大 10 Gbps r8g.4xlarge 16 128 GiB 最大 15 Gbps 最大 10 Gbps r8g.8xlarge 32 256 GiB 15 Gbps 10 Gbps r8g.12xlarge 48 384 GiB 22.5 Gbps 15 Gbps r8g.16xlarge 64 512 GiB 30 Gbps 20 Gbps r8g.24xlarge 96 768 GiB 40 Gbps 30 Gbps r8g.48xlarge 192 1,536 GiB 50 Gbps 40 Gbps r8g.metal-24xl 96 768 GiB 40 Gbps 30 Gbps r8g.metal-48xl 192 1,536 GiB 50 Gbps 40 Gbps 二酸化炭素排出量の削減と持続可能性の目標達成に役立つ、よりエネルギー効率の高いコンピューティングオプションを探している場合、R8g インスタンスは EC2 のメモリ集約型ワークロードに最適なエネルギー効率を提供します。さらに、これらのインスタンスは AWS Nitro System に構築されており、CPU の仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードして、ワークロードのパフォーマンスとセキュリティを強化します。Graviton4 プロセッサは、すべての高速物理ハードウェアインターフェイスを完全に暗号化することにより、セキュリティを強化します。 R8g インスタンスは、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Container Registry (Amazon ECR) 、Kubernetes、Docker、および C/C++、Rust、Go、Java、Python、.NET Core、Node.js、Ruby、PHP などの一般的なプログラミング言語で記述されたアプリケーションを使用して構築された、マイクロサービスベースのコンテナ化されたアプリケーションを含む、すべての Linux ベースのワークロードに最適です。AWS Graviton4 プロセッサは、AWS Graviton3 プロセッサと比較した場合、ウェブアプリケーションでは最大 30%、データベースでは 40%、大規模な Java アプリケーションでは 45% 高速です。詳細については、 AWS Graviton テクニカルガイド をご覧ください。 アプリケーションを Graviton インスタンスタイプに移行する際に役立つ一連の Graviton リソース をご覧ください。また、 AWS Graviton Fast Start プログラムにアクセスして Graviton の導入を開始することもできます。 今すぐご利用いただけます R8g インスタンスは現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト) の AWS リージョンでご利用いただけます。 R8g インスタンスは、リザーブドインスタンス、オンデマンド、スポットインスタンス、または Savings Plans でご購入いただけます。詳細については、 Amazon EC2 の料金 をご覧ください。 Graviton ベースのインスタンスの詳細については、 AWS Graviton プロセッサ または Amazon EC2 R8g インスタンス をご覧ください。 – Esra 原文は こちら です。

7月1日週の月曜日以来の AWS ニュースは 21 件しかなく、そのほとんどは既存のサービスと機能のリージョンレベルの拡張に関するものでした。比較的静かな 1 週間をお過ごしいただけたのではないでしょうか。7月8日週はたくさんお知らせすることがあります。 7月8日週は、7 月 10 日 (水) に Jacob Javits Convention Center で開催される AWS Summit New York にお客様とパートナーをお迎えします。公開する準備が整った AWS ニュースのブログ記事の数から判断すると、お知らせが続々と発表されるでしょう。 私は、7月15日週の土曜日に カメルーンのドゥアラで開催される AWS Community Day に参加する予定であり、その荷造りをする直前にこの記事を書いています。お客様、パートナー、学生の皆さん、そして AWS コミュニティ全体にお会いできるのが待ちきれません。 しかしとにかく今は、7月1日週の新しいお知らせを見てみましょう。 7月1日週のリリース 私が注目したいくつかのリリースをご紹介します。 Amazon Simple Storage Service (Amazon S3) Access Grants が、 Amazon SageMaker およびオープンソース Python フレームワーク と統合するようになりました – Amazon S3 Access Grants は、Active Directory や AWS Identity and Access Management (IAM) プリンシパルなどのディレクトリ内の ID を、S3 のデータセットにマッピングします。機械学習 (ML) のための Amazon SageMaker Studio との統合 は、S3 の機械学習 (ML) データセットに ID をマッピングするのに役立ちます。 AWS SDK for Python (Boto3) プラグイン との統合により、データ許可の管理に必要なカスタムコードが置き換えられるため、 Django 、 TensorFlow 、 NumPy 、 Pandas などのオープンソース Python フレームワークで S3 Access Grants を使用できます。 AWS Lambda が、Lambda 関数のログの検索、フィルタリング、集約を容易にする新しいコントロールを導入 – 独自のログ記録ライブラリを使用せずに、 Lambda ログを JSON 構造化形式でキャプチャできるようになりました 。また、コードを変更せずに、Lambda ログのログレベル (ERROR、DEBUG、INFO など) を制御することもできます。最後に、Lambda がログを送信する Amazon CloudWatch ロググループを選択できます。 Amazon DataZone がきめ細かなアクセスコントロールを導入 – Amazon DataZone はきめ細かなアクセスコントロールを導入しました 。これにより、データ所有者は行レベルと列レベルでデータをきめ細かく制御できます。 Amazon DataZone を利用すると、ガバナンスとアクセスコントロールを使用して、組織の境界を越えて大規模にデータをカタログ化、検出、分析、共有、管理できます。データ所有者は、データセット全体へのアクセスを付与する代わりに、特定のデータレコードへのアクセスを制限できるようになりました。 AWS Direct Connect が特定の場所でネイティブの 400 Gbps 専用接続を提案 – AWS Direct Connect は、AWS とお客様のデータセンター、オフィス、またはコロケーション施設間のプライベートな高帯域幅接続を提供します。 ネイティブの 400 Gbps 接続は、リンクアグリゲーショングループで複数の 100 Gbps 接続を管理する運用オーバーヘッドなしで、より高い帯域幅を提供します 。400 Gbps 接続によって提供されるキャパシティの増加は、ML および大規模言語モデル (LLM) トレーニングや自動運転車の高度な運転支援システムなど、大規模なデータセットを転送するアプリケーションに特に役立ちます。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS の他のニュース 興味深い他のニュース項目をいくつかご紹介します。 今後立ち上げ予定の AWS European Sovereign Cloud リージョンで立ち上げ時に利用可能なサービスのリストを公開 – 新しい AWS European Sovereign Cloud リージョンで立ち上げ時から利用可能な AWS サービスのリスト を共有しました。リストには標準的なサービスが含まれています。セキュリティ、ネットワーキング、ストレージ、コンピューティング、コンテナ、人工知能 (AI)、サーバーレスのサービスが立ち上げ時から利用可能になります。当社は、規制の厳しい業界の公共部門の組織やお客様に、独自のデジタル主権要件、厳格なデータレジデンシー、運用の自律性、回復力の要件を満たすためのさらなる選択肢を提供するために、 AWS European Sovereign Cloud を構築 しています。これは 78 億 EUR (約 84.6 億 USD) の投資です。新しいリージョンは 2025 年末までに利用可能になる予定です。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、 AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください: ニューヨーク (7 月 10 日)、 ボゴタ (7 月 18 日)、 台北 (7 月 23〜24 日)。 AWS Community Days  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催予定の AWS Community Day は、 カメルーン (7 月 13 日)、 アオテアロア (8 月 15 日)、 ナイジェリア (8 月 24 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 今週はここまでです。7月15日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

AWS Summit New York まであと 10 日です。新しい発表と 170 以上のセッションをとても楽しみにしています。サミット終了後、 A Night Out with AWS イベントが開催されます。このイベントは、 Amazon Web Services (AWS) の既存のお客様、またはビジネスで AWS クラウドサービスを利用することに強い関心を持っているメディア、エンターテインメント、ゲーム、スポーツ業界の専門家を対象としています。リラックスしたり、コラボレーションしたり、AWS のリーダーや業界の仲間と新しいつながりを築いたりする機会です。 では、6月24日週の新しい発表を見てみましょう。 6月24日週のリリース 私が注目したリリースを以下に記載しました。 AI21 Labs の Jamba-Instruct が Amazon Bedrock で利用可能に – AI21 Labs の Jamba-Instruct は、安心して商用に使用できる、指示準拠型の大規模言語モデル (LLM) です。コンテキストとサブテキストを理解し、自然言語の指示を受けてタスクを完了し、長い文書や財務書類から情報を取り込む機能を備えています。強力な推論機能を持つ Jamba-Instruct では、複雑な問題の分類、関連情報の収集、構造化された出力を行うことができます。これにより、電話での質疑応答、文書の要約、チャットボットの構築などが可能になります。詳細については、 Amazon Bedrock の AI21 Labs と Amazon Bedrock ユーザーガイド をご覧ください。 Amazon WorkSpaces の新機能、Amazon WorkSpaces Pools – Amazon WorkSpaces を使用して非永続的な仮想デスクトップのプールを作成し、ログインのたびに新しいデスクトップを受け取るユーザー間で共有することで、コストを節約できるようになりました。WorkSpaces Pools は、トレーニングラボやコンタクトセンターなどの共有環境を柔軟にサポートします。また、 Amazon Simple Storage Service (Amazon S3) や Amazon FSx といった中央ストレージリポジトリに保存されているブックマークやファイルなどの一部のユーザー設定を保存して、パーソナライゼーションを向上させることができます。 AWS Auto Scaling を使用すると、使用状況メトリクスまたはスケジュールに基づいて、仮想デスクトップのプールを自動的にスケールできます。料金情報の詳細については、 Amazon WorkSpaces の料金 ページを参照してください。 Amazon DataZone の API 主導の OpenLineage 対応データリネージビジュアライゼーション (プレビュー) – Amazon DataZone で、データがソースから消費されるまでの流れを組織全体で視覚化できる、新しいデータ系統機能をご利用いただけるようになりました。このサービスでは、OpenLineage 対応システムから、または API を介してリネージイベントをキャプチャし、データ変換を追跡します。データ利用者はアセットの発生元に対する信頼を得ることができ、作成者は包括的な系統ビューを通じてデータの使用状況を把握して、変更の影響を評価できます。さらに、Amazon DataZone ではイベントごとに系統をバージョン管理して、任意の時点の系統を視覚化したり、アセットやジョブの履歴全体にわたる変換を比較したりできます。詳細については、 Amazon DataZone にアクセスし、 私のニュースブログ投稿 を確認して、 データリネージのドキュメント をご覧ください。 Amazon Bedrock のナレッジベースでオブザーバビリティログの提供を開始 – Amazon CloudWatch 、S3 バケット、または Amazon Data Firehose ストリームを通じてナレッジ取り込みのログをモニタリングできるようになりました。これにより、ドキュメントが正常に処理されたか、取り込み中にエラーが発生したかをより明確に把握できます。このような包括的な洞察が可能になると、文書がいつ使用できる状態になるかを効率的に判断できます。これらの新機能の詳細については、 Amazon Bedrock のナレッジベース ドキュメントを参照してください。 AWS Well-Architected フレームワークとレンズカタログの更新および拡張 – 安全で耐障害性のあるクラウドワークロードを構築するためのアーキテクチャのベストプラクティスに関するガイダンスと推奨事項を拡張するため、AWS Well-Architected フレームワークとレンズカタログの更新を発表しました。この更新によって重複が削減され、リソースとフレームワーク構造の一貫性が強化されます。レンズカタログに新しく 金融サービス業界レンズ を追加し、 合併と買収レンズ を更新しました。また、「 クラウドの変革イネーブルメント 」ホワイトペーパーでも重要な更新を行いました。更新された Well-Architected フレームワークとレンズカタログを使用して、現在のベストプラクティスに従うと、お客様固有の要件に合わせて最適化されたクラウドアーキテクチャを設計できます。 Amazon SageMaker Model Registry でのクロスアカウント機械学習 (ML) モデル共有のサポート – Amazon SageMaker Model Registry が AWS Resource Access Manager (AWS RAM) と統合され、AWS アカウント間で ML モデルを簡単に共有できるようになりました。これにより、データサイエンティスト、ML エンジニア、ガバナンス担当者は、開発、ステージング、本番などのさまざまなアカウントのモデルにアクセスできます。AWS RAM コンソールでモデルを指定し、他のアカウントへのアクセスを許可すると、Amazon SageMaker Model Registry でモデルを共有できます。この新機能は、GovCloud リージョンを除く SageMaker Model Registry が利用可能なすべての AWS リージョン でご利用いただけます。詳細については、 Amazon SageMaker デベロッパーガイド をご覧ください。 AWS CodeBuild、AWS Graviton3 を使用する Arm ベースのワークロードをサポート – AWS CodeBuild では、追加の設定なしで、AWS Graviton3 プロセッサでの Arm ワークロードのネイティブビルドとテストのサポートを開始しました。これにより、以前の Graviton プロセッサと比較してパフォーマンスが最大 25% 向上し、エネルギー使用量は 60% 削減されます。CodeBuild による Arm のサポートの詳細については、 AWS CodeBuild ユーザーガイド をご覧ください。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon RDS は、AWS GovCloud (米国) リージョンで AWS Secrets Manager との統合のサポートを開始しました 。RDS を AWS Secrets Manager と統合すると、データベース作成のワークフロー中に RDS マスターユーザーのパスワードが管理者やエンジニアにプレーンテキストで表示されないようにすることで、データベースのセキュリティを向上させることができます。 Amazon OpenSearch Serverless をカナダ (中部) リージョンで利用できるようになりました 。OpenSearch Serverless は Amazon OpenSearch Service のサーバーレスデプロイオプションです。複雑なインフラストラクチャ管理を必要とすることなく、検索と分析のワークロードを簡単に実行できます。 Amazon Redshift 同時実行スケーリングを AWS ヨーロッパ (スペイン、チューリッヒ) および中東 (UAE) リージョンで利用できるようになりました 。Amazon Redshift 同時実行スケーリングは、クエリ処理能力を自動的かつ柔軟にスケーリングし、数百の同時クエリに対して一貫して高速なパフォーマンスを提供します。 Amazon ElastiCache は、Graviton3 ベースの M7g および R7g ノードファミリーのサポートを、次の AWS リージョンで開始しました: 米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン、北カリフォルニア)、カナダ (中部)、南米 (サンパウロ)、ヨーロッパ (フランクフルト、アイルランド、ロンドン、パリ (M7g のみ)、スペイン、ストックホルム)、アジアパシフィック (ハイデラバード、ムンバイ、ソウル) 。これらの新しいノードでは、Graviton2 ノードと比較してスループットが最大 28％、P99 レイテンシが 21％、ネットワーク帯域幅が 25％ 向上し、価格パフォーマンスが改善されています。 Amazon EC2 C6a インスタンスをアジアパシフィック (香港) リージョンで利用できるようになりました 。C6a インスタンスは、最大周波数が 3.6 GHz の第 3 世代 AMD EPYC プロセッサを搭載しています。また、同等の C5a インスタンスと比較した場合、最大 15% 優れた価格パフォーマンスを提供します。 ベースキャパシティが小さい Amazon Redshift Serverless を、 アジアパシフィック (ムンバイ) 、 欧州 (ストックホルム)、米国西部 (北カリフォルニア) リージョンで利用できるようになりました。Amazon Redshift Serverless の最小基本容量を、32 RPU から 8 RPU に削減しました。1 秒あたりに支払われる RPU で容量を測定することにより、コストパフォーマンス要件に基づいて、小規模から大規模までさまざまなワークロードをより柔軟にサポートできるようになりました。 Amazon Athena のプロビジョンドキャパシティを南米 (サンパウロ) と欧州 (スペイン) のリージョンで利用できるようになりました 。Provisioned Capacity は Athena の機能の 1 つです。完全マネージド型の専有サーバーレスリソースで、SQL クエリを固定料金で実行できます。長期契約は必要ありません。 Amazon CloudWatch Logs アカウントレベルのサブスクリプションフィルターを、AWS GovCloud (米国東部、米国西部) リージョン、イスラエル (テルアビブ)、カナダ西部 (カルガリー) リージョンで利用できるようになりました 。この新機能により、Amazon CloudWatch Logs に取り込まれたリアルタイムのログイベントを Kinesis Data Streams データストリーム、Amazon Data Firehose 配信ストリーム、または AWS Lambda 関数に配信し、単一のアカウントレベルのサブスクリプションフィルターを使用して、カスタム処理、分析、または他の宛先への配信を行うことができます。 Amazon Route 53 Application Recovery Controller (Route 53 ARC) のゾーン自動シフトを AWS GovCloud (米国東部、米国西部) リージョンで一般的に利用できるようになりました 。この機能を使用すると、AWS がアベイラビリティーゾーンに影響する可能性のある障害を特定したときに、そのアベイラビリティーゾーンからアプリケーションのトラフィックを安全かつ自動的に移行できます。 Amazon S3 の AWS Backup サポートを AWS カナダ西部 (カルガリー) リージョンで利用できるようになりました 。AWS Backup は、ポリシーベースで費用対効果の高い、完全マネージド型のソリューションです。AWS Backup を使用すると、Amazon S3 のデータ保護と、他の (コンピューティング、ストレージ、データベースにまたがる) AWS サービスおよびサードパーティアプリケーションのデータ保護を一元化および自動化できます。 3 TiB のメモリを搭載した Amazon EC2 High Memory インスタンスをアジアパシフィック (香港) リージョンで利用できるようになりました 。新しい High Memory インスタンスは、オンデマンドおよび Savings Plan の購入オプションで使用を開始できます。 AWS のその他のニュース 興味深いと思われるその他のニュース項目をいくつかご紹介いたします。 Amazon Bedrock で生成 AI アプリケーションを構築およびスケールする主な理由 – Jeff Barr の動画 をご覧ください。迅速な価値とビジネスの成長を実現する生成人工知能 (生成 AI) アプリケーションの構築とスケーリングに、お客様が Amazon Bedrock を選ぶ理由について説明されています。Amazon Bedrock はその機能、革新性、可用性、セキュリティにより、生成 AI の構築とスケーリングに適したプラットフォームになりつつあります。さまざまな業界をリードする組織が Amazon Bedrock を使用して、インテリジェントな仮想アシスタント、クリエイティブデザインソリューション、文書処理システムなどの作成など、生成 AI の取り組みを加速させています。 AWS がインフラストラクチャをエンジニアリングして生成 AI を強化する 4 つの方法 – AWS では、モデルトレーニングを高速化するための低レイテンシーかつ大規模なネットワークの提供、データセンターのエネルギー効率の継続的な改善、インフラストラクチャ設計全体にわたるセキュリティの優先、コンピューティングパフォーマンスを向上させつつコストとエネルギー使用量を削減するための AWS Trainium などのカスタム AI チップの開発などのイノベーションを通じて、生成 AI を大規模にサポートできるように、インフラストラクチャを引き続き最適化しています。 AWS が生成 AI のインフラストラクチャをエンジニアリングしている 方法についての新しいブログ投稿をご覧ください。 AWS re:Inforce 2024 re:Cap – 毎年恒例のクラウドセキュリティ学習イベント、AWS re:Inforce 2024 から 2 週間が経ちました。 Wojtek が作成した イベントの概要 をご覧ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。今後の AWS Summit イベントの詳細については、 AWS Summit ページをご覧ください。最寄りの都市のイベントにご登録ください: ニューヨーク (7 月 10 日)、 ボゴタ (7 月 18 日)、 台北 (7 月 23〜24 日)。 AWS Community Days  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される コミュニティ主導のカンファレンス に参加しましょう。近日開催予定の AWS Community Day は、 カメルーン (7 月 13 日)、 アオテアロア (8 月 15 日)、 ナイジェリア (8 月 24 日) です。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 今週はここまでです。7月8日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

Amazon WorkSpaces を使用して非永続的な仮想デスクトップのプールを作成し、グループのユーザー間で共有できるようになりました。デスクトップ管理者は、1 つの GUI、コマンドライン、または API を利用したツールセットを使用して、永続的仮想デスクトップと非永続的仮想デスクトップのポートフォリオ全体を管理できます。ユーザーは、 ブラウザ 、 クライアントアプリケーション (Windows、Mac、Linux)、または シンクライアントデバイス を使用してこれらのデスクトップにログインできます。 Amazon WorkSpaces プール (非永続デスクトップ) WorkSpaces プールを使うことで、各ユーザーは同じアプリケーションを使用し、同じエクスペリエンスを得られるようになります。ユーザーがログインすると、管理者が一元管理するプールの最新の設定に基づいた新しい WorkSpaces にいつでもアクセスできます。管理者がプールのアプリケーション設定の永続化を有効にすると、ユーザーはブラウザのお気に入り、プラグイン、UI のカスタマイズなど、特定のアプリケーション設定を行えます。ユーザーは、デスクトップの外部にある永続ファイルまたはオブジェクトストレージにもアクセスできます。 このようなデスクトップは、リモートワーカー、タスクワーカー (共有サービスセンター、財務、調達、人事など)、コンタクトセンターの従業員、学生など、さまざまなタイプのユーザーやユースケースに最適です。 プールの管理者は、ユーザーが利用できるアプリケーションセットを含め、コンピューティングリソース (バンドルタイプ) とプール内のデスクトップの初期設定を完全に制御できます。既存のカスタム WorkSpaces イメージを使用することも、新しいイメージを作成することも、標準のイメージを使用することもできます。また、エンタープライズ向け Microsoft 365 アプリケーションをイメージに含めることもできます。ユーザーベースの規模と作業時間に合わせてプールを設定できます。また、オプションで組織のドメインとアクティブディレクトリにプールを追加することもできます。 開始方法 プールを設定してユーザーを招待するプロセスを見ていきましょう。WorkSpaces コンソールを開き、 [Pools] (プール) を選択して開始します。 プールがないので、 [Pools] (プール) タブの [Create WorkSpaces] (Workspaces の作成) を選択して、プールの作成プロセスを開始します。 コンソールがワークスペースのオプションを勧めてくれたり、必要なものを選択したりできます。非永続デスクトップのプールを作成するには、 [Recommend workspace options…] (推奨ワークスペースオプション…) を選択したままにし、 [No – non-persistent] (いいえ – ノンパーシステント) を選択します。次に、メニューからユースケースを選択し、オペレーティングシステムをクリックし、 [Next] (次へ) を選択して続行します。 ユースケースメニューには、次のようにたくさんのオプションがあります。 次のページでは、まず WorkSpace オプションを確認して、プールに名前を割り当てます。 次に、下にスクロールして、バンドルを選択します。パブリックバンドルまたは独自のカスタムバンドルを選択できます。バンドルは WSP 2.0 プロトコルを使用する必要があります。カスタムバンドルを作成して、ユーザーにアプリケーションへのアクセスを提供したり、必要なシステム設定を変更したりできます。 次に進むと、各ユーザーセッションの設定をカスタマイズできます。また、アプリケーション設定の永続化を有効にして、セッション間でユーザーごとにアプリケーションのカスタマイズと Windows 設定を保存することもできます。 次に、プールの容量を設定し、オプションで日付や時刻を考慮して 1 つ以上のスケジュールを設定します。スケジュールにより、ユーザーのリズムやニーズに合わせてプールのサイズ (またそれに従ったコスト) を調整することができます。 同時使用量がより動的で、スケジュールに沿っていない場合は、手動のスケールアウトとスケールインのポリシーを使用してプールのサイズを制御できます。 プールにタグを付けて、 [Next] (次へ) を選択して続行します。 最後のステップは、WorkSpaces プールディレクトリを選択するか、 次の手順 に従って新しいディレクトリを作成することです。次に、 [Create WorkSpace pool] (WorkSpace プールの作成) を選択します。 プールを作成して起動したら、登録コードをユーザーに送信して WorkSpace にログインできます。 コンソールからプールのステータスを監視できます。 知っておくべきこと WorkSpaces プールについて知っておきたい事柄には、次のようなものがあります。 プログラムによるアクセス – 上で示したセットアッププロセスは、 CreateWorkSpacePool 、 DescribeWorkSpacePool 、 UpdateWorkSpacePool などの関数、または同等の AWS コマンドラインインターフェイス (CLI) コマンドを使用して自動化できます。 リージョン – WorkSpaces プールは、イスラエル (テルアビブ)、アフリカ (ケープタウン)、中国 (寧夏) を除き、WorkSpaces Personal が利用可能なすべての商用 AWS リージョンでご利用いただけます。今後の更新については、 リージョンの完全なリスト を参照してください。 料金 – 料金情報の詳細については、 Amazon WorkSpaces の料金 ページを参照してください。 詳細については、 Amazon WorkSpaces プール をご覧ください。 – Jeff ; 原文は こちら です。

Hello Builders の皆様もしくは Builders の卵の皆様、こんにちは！機械学習ソリューションアーキテクトの呉( @kazuneet )です。 2024 年 2 回目の 7/18(木)の Builders Online Series が近くなってきました。 前回のブログ では最初のセッション群の「AWS 基礎 – 90 分で学ぶ！AWS 超入門 2024」を紹介しましたが、この記事では 2 番目のセッション群の「生成 AI 実践入門」について紹介します。 >> AWS Builders Online Series のお申し込みはこちらから 「生成 AI 実践入門」では、Amazon Bedrock という生成 AI サービスを通じて、Builder の皆様がアプリケーションの構築のイメージをつかめることを目指します。 全部で４セッションあり、Amazon Bedrock に触れたことがない方が「完全に理解した（※）」を目標として順番でご視聴いただくことを想定しております。 ※ダニング=クルーガー効果でいうところの最初の山の到達地点。イメージとしてはチュートリアルを一通り行いなんでもできるようになった気持ちの状態。その後自分で手を動かして行くと「何もわからない」という状態を通じて「チョットデキル」の状態になっていく。 どんなセッションかイメージしやすいよう、少しだけ登壇資料をチラ見せしつつ紹介いたします。 11:50 – 12:20 BOS-04: 生成 AI コワクナイヨ！AWS マネジメントコンソールで始める Amazon Bedrock Amazon Bedrock の全体像の解説と、基本機能である生成 AI の呼び出しを AWS マネジメントコンソールから行うデモをお見せします。 生成 AI の課題とは・・・ Bedrock から扱えるモデルはいっぱいあります。 セキュリティって大事ですよね・・・ 12:30 – 13:00 BOS-05: Builder なら API で Amazon Bedrock を使ってみよう！超簡単 API コールの手ほどき 生成 AI をシステムに組み込むには API で Amazon Bedrock を呼び出す必要がありますが、Amazon Bedrock の API は簡単に呼び出せます。その呼び出し方をレクチャーします。 Amazon Bedrock をアプリに組み込む場合はどうすれば・・・ AWS のサービスを呼び出すには API を呼び出せばいい・・・？SDK もある・・・？ AWS CloudShell というすぐに利用できるコードの実行環境からデモを行います。 13:10 – 13:40 BOS-06: 明日からすぐに使える自分で作る生成 AI アプリケーション〜Chat with your document〜 生成 AI は単品で使うだけでなく、自分が持っているドキュメントと組み合わせることでできることの幅が広がります。その例えばを紹介いたします。 生成 AI のハルシネーションって困りますよね・・・ RAG というのを使えばハルシネーションを抑制できる・・・？ さらにデータベースを用意しなくてもRAGができる・・・？ 13:50 – 14:20 BOS-07: 業務で利用できる生成 AI ソリューションのデプロイと実装を一緒に覗いてみよう 生成 AI をアプリに組み込んだ例をとその実装を紹介するセッションです。 チャットってなんでもできるけど必ずしも便利ではないですよね・・・ GenU という無償で使えるチャット以外も使えるソリューションがあるんですね。 コードの中身も紹介します。 このように生成 AI の第一歩からアプリケーション構築まで一気に学べるコンテンツをご用意しておりますので、ぜひご参加ください！ >> AWS Builders Online Series のお申し込みはこちらから

Amazon DataZone は、組織内のデータプロデューサーとコンシューマーの間でデータをカタログ化、検出、分析、共有、管理するためのデータ管理サービスです。エンジニア、データサイエンティスト、製品マネージャー、アナリスト、ビジネスユーザーは、統合データポータルを使用して組織全体のデータに簡単にアクセスして、データ駆動型のインサイトを検出および使用したり、そのようなインサイトを得るためにコラボレーションしたりできます。 Amazon DataZone の API 駆動型で OpenLineage 互換の新しいデータリネージ機能のプレビューを発表します。この機能は、時間の経過に合わせたデータ移動のエンドツーエンドのビューを提供します。データリネージは Amazon DataZone 内の新しい機能であり、ユーザーによるデータの出自の視覚化および理解、変更管理の追跡、データエラーが報告された際の根本原因分析の実行、ソースからターゲットへのデータ移動に関する質問への準備に役立ちます。この機能は、Amazon DataZone のカタログから自動的にキャプチャされたリネージイベントと、Amazon DataZone の外部でプログラムによってキャプチャされた他のイベントをつなぎ合わせてアセットとしてまとめた包括的なビューを提供します。 組織内で関心のあるデータがどのように生成されたかを検証する必要がある場合、手動のドキュメントや関係者への確認に依拠することがあります。この手動プロセスは時間がかかり、不整合が生じる可能性があるため、データの信頼性が直接的に低下します。Amazon DataZone のデータリネージは、データの生成元、変更方法、および時間の経過に伴う利用を把握できるようにすることで、信頼性を高めることができます。例えば、データリネージは、 Amazon Simple Storage Service (Amazon S3) で生のファイルとしてキャプチャされた時点から、 AWS Glue を利用した ETL 変換を経て、 Amazon QuickSight などのツールで利用された時点までのデータを表示するようにプログラムで設定できます。 Amazon DataZone のデータリネージを使用すると、データアセットとその関係のマッピング、パイプラインのトラブルシューティングと開発、およびデータガバナンスプラクティスのアサーションにかかる時間を短縮できます。データリネージは、API を使用してすべてのリネージ情報を 1 か所に集約して、データユーザーの生産性を高め、データ駆動型のより適切な意思決定を行い、データの問題の根本原因を特定するためのグラフィカルビューを提供するのに役立ちます。 Amazon DataZone でデータリネージの使用を開始する方法を説明します。その後、データアセットがどのように作成されたかというつながりを視覚的に表示し、そのデータアセットを検索または使用する際に十分な情報に基づいた意思決定を行えるようにすることで、データリネージが Amazon DataZone データカタログエクスペリエンスをどのように強化するのかを説明します。 Amazon DataZone でのデータリネージの開始方法 プレビューでは、 Amazon DataZone API を使用してリネージノードを直接作成するか、既存のパイプラインコンポーネントから OpenLineage 互換イベントを送信して Amazon DataZone の外部で発生するデータの移動または変換をキャプチャすることにより、プログラムで Amazon DataZone にリネージ情報をハイドレートすることから開始できます。カタログ内のアセットに関する情報については、Amazon DataZone は、アセットの状態 (すなわち、インベントリや公開状態など) とサブスクリプションのリネージを自動的にキャプチャします。これは、データエンジニアなどのプロデューサーにとっては、自分が作成したデータを誰が利用しているかを追跡するのに役立ち、データアナリストやデータエンジニアなどのデータコンシューマーにとっては、分析に利用しているのが適切なデータであるかどうかを把握するのに役立ちます。 情報が送信されると、Amazon DataZone はリネージモデルへの入力を開始し、API を通じて送信された識別子を、既にカタログ化されているアセットにマッピングできるようになります。新しいリネージ情報が送信されると、モデルはバージョンの作成を開始し、特定の時点でアセットのビジュアライゼーションを開始しますが、以前のバージョンに移動することもできます。 このユースケースでは、事前設定された Amazon DataZone ドメインを使用します。Amazon DataZone ドメインを使用して、データアセット、ユーザー、プロジェクトを整理します。 Amazon DataZone コンソール に移動し、 [ドメインを表示] を選択します。ドメイン [Sales_Domain] を選択し、 [データポータルを開く] を選択します。 ドメインには 5 つのプロジェクトがあります。1 つはデータプロデューサー用 ( [SalesProject] )、4 つはデータコンシューマー用 ( [MarketingTestProject] 、 [AdCampaignProject] 、 [SocialCampaignProject] 、 [WebCampaignProject] ) です。「 Amazon DataZone Now Generally Available – Collaborate on Data Projects across Organizational Boundaries 」を参照して、独自のドメインとすべてのコアコンポーネントを作成できます。 [アセットを検索] バーに「Market Sales Table」と入力し、 [Market Sales Table] アセットの詳細ページに移動します。 [リネージ] タブを選択して、上流ノードと下流ノードのリネージを視覚化します。 これで、アセットの詳細、プロセス、それらのアセットにつながるジョブ、それらのアセットからつながるジョブを詳しく知ることができ、列レベルのリネージを詳しく確認できます。 データリネージを使用したインタラクティブなビジュアライゼーション Amazon DataZone を定期的に操作し、データリネージ機能の恩恵を享受するさまざまなペルソナを使用して、グラフィカルインターフェイスをご紹介します。 まず、私がマーケティングアナリストであり、自信をもって分析で利用できるよう、データアセットのオリジンを確認する必要があるとします。 [MarketingTestProject] ページに移動し、 [リネージ] タブを選択します。リネージには、Amazon DataZone の内外で発生するアセットに関する情報が含まれていることがわかります。 [カタログ化済み] 、 [公開済み] 、および [アクセスをリクエスト済み] のラベルは、カタログ内のアクションを表します。データの出自を確認するには、 [market_sales] データセット項目を展開します。 これで、データアセットのオリジンがわかり、分析を開始する前にそれが自分のビジネス目的と一致していることを確信できます。 次に、私がデータエンジニアだとします。意図しない変更を避けるために、自分の作業内容が依存オブジェクトに及ぼす影響を理解する必要があります。データエンジニアとして、システムに加えられた変更によって下流のプロセスが中断されることがあってはなりません。リネージを参照することで、誰がサブスクライブしており、アセットにアクセスできるのかを明確に確認できます。この情報を使用して、パイプラインに影響を及ぼす可能性のある喫緊の変更についてプロジェクトチームに通知できます。データの問題が報告された場合、各ノードを調査し、そのバージョン間を移動して、時間が経過する中で何が変わったのかを詳しく確認し、問題の根本原因を特定して適時に修正できます。 最後に、データの保護、ビジネス分類の標準化、データ管理プロセスの実施、および一般的なカタログ管理を担当する管理者またはスチュワードである場合について考えてみましょう。データのソースに関する詳細を収集し、その過程で発生した変換を理解する必要があります。 例えば、監査人からの質問に回答しようとしている管理者として、グラフを上流にたどってデータの出自を確認し、データがオンライン販売と店舗内販売という 2 つの異なるソースから来ていることに気づきました。これらのソースには、パイプラインが合流するポイントに到達するまで、独自のパイプラインがあります。 リネージグラフを適切に操作しながら、列を展開して、変換プロセス中に機密性の高い列が削除されるようにしたり、詳細について監査人に適時に回答したりできます。 プレビューにご参加ください データリネージ機能は、 Amazon DataZone が一般提供されているすべてのリージョンでプレビューとして利用できます。Amazon DataZone ドメインをプロビジョニングできるリージョンの一覧については、「 AWS サービス (リージョン別) 」にアクセスしてください。 データリネージのコストは、ストレージ使用量と API リクエストによります。これらは Amazon DataZone の料金モデルに既に含まれています。詳細については、「 Amazon DataZone の料金 」にアクセスしてください。 Amazon DataZone のデータリネージの詳細については、「 Amazon DataZone ユーザーガイド 」にアクセスしてください。 – Esra 原文は こちら です。

Amazon CodeCatalyst が、 GitHub との既存の統合 に加えて、 GitLab と BitBucket という人気が高い 2 つのコードリポジトリとも統合することをお知らせします。現在 CodeCatalyst と GitHub との統合で使用しているのと 同じ機能セット を GitLab.com と Bitbucket Cloud でもご利用いただけます。 Amazon CodeCatalyst は、統合型のソフトウェア開発および配信サービスです。Amazon CodeCatalyst を使用すると、ソフトウェア開発チームは Amazon Web Services (AWS) 上でアプリケーションを迅速かつ簡単に計画、開発、コラボレーション、構築、配信できるよううになり、開発ライフサイクル全体でフリクションが軽減されます。 CodeCatalyst 用の GitHub、GitLab.com、Bitbucket Cloud のリポジトリ拡張機能を活用すると、開発ワークフローの管理が簡単になります。この拡張機能では、CodeCatalyst 内で外部リポジトリを直接表示および管理できます。また、ワークフロー定義ファイルをコードと一緒に外部リポジトリに保存して管理すると同時に、CodeCatalyst 開発環境からリンクされたリポジトリ内のファイルを作成、読み取り、更新、削除することもできます。さらに、この拡張機能はコードがプッシュされたとき、およびプルリクエストを開いたり、マージしたり、閉じたりしたときに、CodeCatalyst ワークフローの自動実行をトリガーします。しかも、リンクされたリポジトリのソースファイルを直接利用し、CodeCatalyst ワークフロー内でアクションを実行できるため、プラットフォームを切り替える必要がなく、効率を最大化できます。 それだけではありません。6月27日より、 ブループリントからの GitHub、GitLab.com、または Bitbucket Cloud リポジトリでの CodeCatalyst プロジェクトの作成 、これら 3 つのシステムのいずれかのリポジトリにある既存のコードベースへのブループリントの追加、GitHub、Gitlab.com、または Bitbucket Cloud でホストされている外部リポジトリに保存されるカスタムブループリントの作成ができるようになりました。 CodeCatalyst ブループリント は開発のスピードアップに役立ちます。これらの事前作成済みテンプレートには、ソースリポジトリ、サンプルコード、継続的インテグレーションと継続的デリバリー (CI/CD) ワークフロー、統合問題追跡機能が備わっているため、すぐに作業を開始できます。ブループリントはベストプラクティスに従って自動的に更新され、コードを最新の状態に保ちます。IT リーダーは、テクノロジー、アクセス制御、デプロイ、テスト方法を指定して、チームの開発を標準化するカスタムブループリントを作成できます。さらに、コードが GitHub、GitLab.com、または Bitbucket Cloud にある場合でも、ブループリントを使用できるようになりました。 CodeCatalyst スペースを Git リポジトリのホスティングサービスとリンクする これら 3 つのソースコードリポジトリプロバイダーのどれでも、簡単に使用を開始できます。 CodeCatalyst スペース の管理者として、拡張機能を設定するスペースを選択します。次に、 [Settings] (設定) を選択し、 [Installed extensions] (インストールされている拡張機能) セクションで [Configure] (構成) を選択して、CodeCatalyst スペースを GitHub、GitLab.com、または Bitbucket Cloud アカウントにリンクします。 これは CodeCatalyst スペースごとに 1 回限りの操作ですが、スペースを複数のソースプロバイダーのアカウントに接続したいとします。 GitHub を使用するときは、個人の CodeCatalyst ユーザーを自分の GitHub ユーザーにリンクする必要もあります。画面右上の個人メニューで [My settings] (設定) を選択します。次に、 [Personal connections] (パーソナル接続) セクションに移動します。 [Create] (作成) を選択して、指示に沿って GitHub で認証し、2 つの ID をリンクします。 これは CodeCatalyst スペースの各ユーザーにおいて 1 回限りの操作です。GitHub をブループリントで使用している場合にのみ必要となります。 ブループリントからプロジェクトを作成し、GitHub、GitLab.com、Bitbucket Cloud でホストする ブループリントから外部リポジトリにプロジェクトを作成し、後ほどこのプロジェクトに他のブループリントを追加する方法について説明します。CodeCatalyst がサポートする 3 つの Git ホスティングプロバイダーのいずれかを使用できます。このデモでは、GitHub を使用します。 API を実装するための新しいプロジェクトを作成したいとします。まず、 Python と AWS サーバーレスアプリケーションモデル (AWS SAM) を使用して API を実装するブループリントから始めます。このブループリントでは、CI ワークフロー と 問題 管理システムも作成されます。 プロジェクトコードを GitHub でホストしたいとします 。これにより、GitHub のリポジトリにあるソースファイルを直接使用し、CodeCatalyst ワークフロー内でアクションを実行できるようになるため、プラットフォームを切り替える必要がなくなります。 まず、CodeCatalyst スペースのページで [Create project] (プロジェクトを作成) を選択します。 [Start with a blueprint] (ブループリントを使用して開始) を選択し、使用する CodeCatalyst ブループリント または Space ブループリント を選択します。その後、 [Next] (次へ) を選択します。 プロジェクトの名前を入力します。 [Advanced] (詳細設定) セクションを開き、 [Repository provider] (リポジトリプロバイダー) として GitHub を選択し、 GitHub アカウント を選択します。GitHub [Connect a GitHub account] (GitHub アカウントを接続) を選択すると、GitHub への追加接続を設定できます。 残りの設定は、選択したブループリントによって異なります。今回は、言語バージョン、プロジェクトをデプロイする AWS アカウント、 AWS Lambda 関数、 AWS CloudFormation スタックの名前を選択しました。 プロジェクトが作成された後、GitHub アカウントに移動すると、新しいリポジトリが作成されたことがわかります。ブループリントのコードとリソースが含まれています。 既存の GitHub、GitLab.com、または Bitbucket Cloud プロジェクトにブループリントを追加する 1 つのプロジェクトに複数のブループリントを適用して、既存の CodeCatalyst プロジェクトに機能コンポーネント、リソース、ガバナンスを組み込むことができます。プロジェクトは、個別のブループリントでそれぞれ管理される、さまざまな要素をサポートできます。 サービスドキュメントは、既存のプロジェクトのブループリントを使用して、ライフサイクル管理について詳しく学ぶのに役立ちます 。 これで、外部のソースコードリポジトリにある既存のプロジェクトにブループリントを追加できるようになりました。バックエンド API プロジェクトが作成されたので、プロジェクトにウェブアプリケーションを追加します。 左側のメニューの [Blueprints] (ブループリント) セクションに移動し、画面の右上にあるオレンジ色の [Add blueprint] (ブループリントを追加) ボタンを選択します。 [Single-page application] (1 ページのアプリケーション) のブループリントを選択し [Next] (次へ) を選択します。 次の画面では、プロジェクトを作成したときと同じように、必ず GitHub 接続を選択します。この特定のテンプレートに必要な情報も入力します。画面の右側で、提案された変更を確認します。 同様に、 CodeCatalyst Enterprise Tier を使用する場合、 独自のカスタムブループリントを作成 して、チームメイトや組織内の他のグループと共有できます。簡潔にするため、この記事では手順を追って説明しません。詳細については、ドキュメントの「 Standardizing projects with custom blueprints 」を参照してください。 CodeCatalyst が新しいブループリントのインストールを完了すると、GitHub に 2 つ目のリポジトリが表示されます。 単一または複数のリポジトリ戦略 コードを整理するときは、すべてが詰まったツールボックスのような単一の大きなリポジトリを使用するか、整理しやすい小さな専用リポジトリに分割するかを選択できます。単一リポジトリは、緊密にリンクされたプロジェクトの依存関係管理を簡素化しますが、大規模になればなるほど煩雑になる可能性があります。リポジトリが複数あると、整理がしやすくなり、セキュリティが向上しますが、個別のプロジェクト間の依存関係を管理する計画を立てる必要があります。 CodeCatalyst を使用すると、プロジェクトに最適な戦略を使用できます。詳細については、ドキュメントの「 Store and collaborate on code with source repositories in CodeCatalyst 」を参照してください。 前に示した例では、私が選択したブループリントから、2 番目のブループリントを GitHub の別のリポジトリとして適用することが提案されました。選択したブループリントによっては、別のリポジトリを作成するか、既存のリポジトリに新しいコードをマージすることを、ブループリントが提案する場合があります。後者の場合、ブループリントはリポジトリにマージするためのプルリクエストを送信します。 リージョンと利用状況 この新しい GitHub 統合は、公開時点で Amazon CodeCatalyst が利用可能な 2 つの AWS リージョン、米国西部 (オレゴン) と欧州 (アイルランド) で、追加料金なしで利用できます。 今すぐお試しください — seb 原文は こちら です。

本ブログは、ルームクリップ株式会社と 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 関連案件の支援に携わる。