こんにちは ! テクニカルインストラクターの室橋です。気持ちの上ではまだゴールデンウィークぐらいのつもりで生活していたのですが、いつの間にかもう年末が近くなってきてしまいました。今年も残りわずかですね。体調に気を付けつつ、年末まで頑張りましょう！ AWS Cloud Quest の「Serverless Developer」ロールが日本語化されました ! AWS クラウドをゲームベースで学習できるコンテンツである「 AWS Cloud Quest (以下 Cloud Quest)」はご利用いただいておりますでしょうか ? Cloud Quest は 「ゲーム内でストーリーに沿って出題されるソリューション構築に関する課題を、実際の AWS のアカウントを使用しながら解いていく、RPG テイストのコンテンツ」 です。学習に使用する AWS アカウントは、ゲーム内で用意されるものを一時的に使用できるため、サービスの使用料金などは気にせず、学習に集中してご利用いただけます。「Cloud Quest をまだ知らないよ」という方は、 こちらのブログ にて詳しくご案内しておりますので、是非ご確認ください。 Cloud Quest の中には、様々なカテゴリ (ロール) の課題が含まれているのですが、 この度、ご要望の声が多かった「 Serverless Developer 」ロールについて日本語対応を行いました。 Serverless Developer ロールには 24 の課題 (一部他ロールと重複する課題もあります) が用意されており、AWS Lambda や Amazon API Gateway をはじめとしたサービスを組み合わせながらソリューションを構築可能です。「今までサーバーレスの学習には手を出しづらかった」と言われる方も、この機会に是非チャレンジしていただければと思います。 AWS Cloud Quest Serverless Develpoer ロールの課題画面より さて、この度日本語化された Serverless Developer ロールの課題と、その中で触れられるサービスについて、一覧を掲載いたします。 ※ 2024 年 11 月 20 日現在、Cloud Quest 内の情報をそのまま掲載します。今後課題やサービスについては変更される可能性もあります。 課題名 主な学習内容 クラウドコンピューティングの基本 Amazon S3 クラウド、はじめの一歩 AWS, Amazon EC2 コンピューティングの基礎 Amazon EC2 クラウドのコスト見積り Amazon EC2, Cloud Economics ネットワークの概念 Amazon EC2, Amazon VPC リレーショナルデータベースの実装 Amazon Relational Database Service (RDS) セキュリティのコアコンセプト AWS Identity and Access Management (IAM), Amazon Relational Database Service (RDS), Amazon EC2 リソースモニタリング Amazon CloudWatch, Amazon EC2 クラウド上のファイルシステム Amazon EC2, Amazon Elastic File System サーバーレス基盤 AWS Lambda RESTful API のデプロイ Amazon API Gateway, AWS Lambda API とデータベース Amazon API Gateway, AWS Lambda, Amazon DynamoDB シングルページアプリケーション AWS Lambda, Amazon DynamoDB, Amazon API Gateway, Amazon S3, Amazon CloudWatch クラウド開発環境のセットアップ Amazon S3, Amazon SageMaker Amazon Q Developer を使用した迅速なアプリケーション構築 Amazon CodeWhisperer, Amazon S3, AWS Lambda サーバーレスアプリケーションのテンプレート化 SAM, AWS CloudFormation, AWS Cloud9 NoSQL データベースの設計 Amazon DynamoDB, Amazon EC2 トリガー – データの集約 Amazon DynamoDB, AWS Lambda サーバーレスアプリケーションの統合 AWS Lambda, Amazon SQS データの並列処理 Amazon SNS, AWS Lambda, Amazon CloudWatch Gen AI を使用して画像認識システムを構築 AWS Lambda, AWS Cloud9, Amazon CodeWhisperer サーバーレスワークフローのオーケストレーション Amazon Rekognition, AWS Lambda, Amazon DynamoDB, Amazon Comprehend, AWS Step Functions API の段階的デプロイ Amazon API Gateway, AWS Lambda, SAM, AWS Cloud9, AWS CodeDeploy 継続的デリバリーパイプライン AWS CodePipeline, AWS CodeCommit, AWS CodeBuild, AWS CloudFormation, AWS Cloud9 興味のある内容が見つかりましたら、是非 Skill Builder のページ にアクセスして、Cloud Quest の Serverless Developer ロール (要サブスクリプション) にチャレンジしてみてください。「いきなりサブスクリプションは敷居が高い」と思われる方には、 無料でプレイ可能な Cloud Practitioner ロール もご用意しておりますので、まずは無料で学習を始めてみてください ! Skill Builder 自体への登録は無料で、AWS アカウントをお持ちでない方も登録、利用が可能です 。 その他、サーバーレス関連コースを多数ご用意しております AWS Skill Builder では、上記の AWS Cloud Quest 以外にも、Serverless 関連のコースを多数ご用意しております。下記にいくつか関連コースをピックアップしてみましたが、その他にも様々なコースをご用意しております。皆様の知りたい内容やニーズに合ったトレーニングを探して、是非知識を深めてみてください。 ■動画コンテンツ: Getting into the Serverless Mindset (Japanese) この 20 分ほどのコースでは、サーバーレスアーキテクチャとアプリケーションの構築に役立つサーバーレスコンセプトのキーについて説明します。 サーバーレスコンピューティングとそのイベント駆動型の指向によって、アプリケーション開発、タスクの並列化、および環境管理をどのように実行するのかを学びます。本コースは無料で登録、受講が可能です。 ■動画コンテンツ: Introduction to Serverless Development (Japanese) このコースでは、サーバーレスアプリケーションの開発を開始するのに役立つ重要なサーバーレスコンセプトについて説明します。サーバーベースの開発で既に使用されている開発のベストプラクティスが、サーバーレス開発にどのように適用されるか、およびサーバーレスアプリケーション開発用に開発プロセスを調整する方法を学びます。本コースも無料で登録、受講が可能です。 ■学習プラン: Serverless Learning Plan (Japanese) Learning Plan (学習プラン) には、特定のロールまたはソリューション向けのトレーニングコンテンツがまとめられています。この学習プランは「開発者が AWS でサーバーレスソリューションを設計するのを支援すること」を目的としています。このプランに含まれるトレーニングでは、サーバーについて意識することなくアプリケーションを構築、実行する方法を説明します。 ■セルフペースラボ: Introduction to AWS Lambda (Japanese) AWS Lambda は、イベントに応じてコードを実行し、コンピューティングリソースを自動的に管理するコンピューティングサービスです。このサービスを使用すると、新しい情報にすばやく対応するアプリケーションを簡単に構築できます。このセルフペースラボでは、イベント駆動型の環境で Lambda 関数を作成するために必要なステップを説明します。このラボの所要時間は約 45 分で、Skill Builder のサブスクリプション登録によりご利用いただけます。 ■セルフペースラボ: Event Driven Architecture with Amazon API Gateway, Amazon EventBridge and AWS Lambda (Japanese) このセルフペースラボでは API Gateway、EventBridge、Lambda を使用してイベント駆動型のサーバーレスアーキテクチャを構築します。サーバーレスアーキテクチャは、インフラストラクチャを管理することなく、アプリケーションとサービスを構築、実行するための手法です。こちらのラボも所要時間は約 45 分で、Skill Builder のサブスクリプション登録によりご利用いただけます。 ■試験準備コース: Exam Prep Standard Course: AWS Certified Developer – Associate (DVA-C02) (Japanese) AWS Certified Developer – Associate (DVA-C02) 試験では、AWS クラウドベースのアプリケーションの開発、テスト、デプロイ、デバッグについて、受験者の習熟度を検証します。このコースでは、試験のトピックの分野と、試験の準備方法を学びます。本コースは無料でご利用いただくことが可能ですが、ハンズオンラボや公式模擬試験を含むコース全体については、 Exam Prep Enhanced Course: AWS Certified Developer – Associate (DVA-C02) をご覧ください。 AWS Skill Builder にまだ慣れていない方は … AWS Skill Builder の利用自体が初めて且つ「コースの効率良い探し方を知りたい」という場合は、 AWS Skill Builder Learner Guide という学習者用のガイドもご用意しております。Skill Builder の操作方法や、利用可能な様々なタイプのトレーニングについてご紹介しておりますので、利用が初めての方はご参照ください。 さて、今年も残すところあとわずかとなりました。是非今年の締めくくりに！来年の学習開始に！ AWS Skill Builder や AWS Cloud Quest を使ってクラウドの学習をお楽しみください。

本記事は 2024 年 10 月 14 日に公開された “ Improving Utility customer experience and field service efficiency using generative AI ” を翻訳したものです。 導入 公益事業者は、私たちの家庭、企業、地域社会に不可欠なサービスを提供しています。世界のデジタル化、電化、資源の制約がますます進む中、彼らは前例のない課題に直面しています。 3 つの主要な課題が浮上しています。 インフラのモダナイズと拡張: 公益事業者は、グリーンエネルギー源を組み込み、廃棄物を削減し、環境への影響を最小限に抑えながら、増大する需要に応える持続可能なインフラに投資する必要があります。 現場業務の最適化: 競争の激しい市場では、リソースを最適化し、コストを管理する必要性が最も重要になっています。これには、高度なテクノロジーを使用してデータ収集、データ分析、計画、自動化を改善し、合理化して効率を向上させるための新しいアプローチが必要です。 顧客エクスペリエンスの変革: 公益事業者は、デジタル チャネルを通じてパーソナライズされたサービス、直感的なインターフェイス、リアルタイムのフィードバックを提供し、より応答性と効果を高めることで、進化する顧客の期待に適応する必要があります。 このような変化と複雑さを背景に、公益事業者は業務効率、顧客満足度、規制順守の間の微妙なバランスを管理しながらイノベーションを起こすというプレッシャーが増大しています。 顧客体験とフィールドサービス体験の向上 公益事業者が直面している継続的な課題の 1 つは、リソース計画と現場業務 (これには計画、監督、請負業者のワークフローが含まれます) の効率を向上させながら、優れた顧客サービスを提供することにあります。インフラの老朽化、資産の場所の分散性、異常気象などの環境要因により、従来のワークフローに改善が求められています。その結果、公益事業者はパフォーマンスの期待を満たすのに苦労することがよくあります。これに、一方ではテクノロジーに精通した現代の顧客の期待の高まり、もう一方では熟練した現場労働者の不足が加わり、私たちは厳しい嵐のような状況に直面しています。 公益事業者がどれだけ効率的に顧客サービスを提供できるかを測定する重要な指標は、問題解決または新しいサービス要求に平均して必要な訪問回数 (いわゆるトラックロール数) を分析することです。 First-Time-Fix-Rate (FTFR) は、企業が最初の訪問でジョブを完了する能力を把握するためによく使用される指標です。残念ながら、ほとんどの組織は FTFR を 80% レベルに維持するのに苦労しています。これは、トラックロールの最大 20% が潜在的に回避可能であることを意味します。このような避けるべき訪問は、二酸化炭素排出量の大幅な増加は言うまでもなく、顧客満足度スコアに悪影響を及ぼし、さらなるコストと生産性の損失につながる可能性があります。 非同期ワークフローと生成 AI の使用 革新的な AI を活用したビデオ ワークフロー ソリューションの大手プロバイダーである Vyntelligence (Vyn®) は、最前線の活動の複雑さに取り組むための新しいアプローチを開発しました。この投稿では、Vyntelligence ソリューションが非同期オーディオビジュアル キャプチャ、ガイド付きワークフロー、高度な生成 AI、およびコンピューター ビジョン (CV) テクノロジーをどのように組み合わせて、顧客エクスペリエンスを変革し、現場業務を合理化するかを検討します。 Vyn のアプローチの中心には、重要な洞察があります。公共事業などの物理インフラを管理する組織では、不確実な状況によって最前線の活動が妨げられることがよくあります。こうした組織にとって計画は不可欠ですが、その有効性は、その基礎となるデータと、複雑なワークロードや状況に適応する従業員の能力によって決まります。したがって、これらの課題に対処するための戦略は、人材の有効活用とデータの強化に重点を置く必要があります。 Vyn SmartVideoNotes® テクノロジーは、公益事業者がモバイル ワークフローを簡単に導入できるようにすることで、計画された作業と実際の作業の間のギャップを埋め、顧客、現場担当者、請負業者が作業前、作業中、作業後に詳細なコンテキスト情報を取得できるようにします。非同期のガイド付きビデオ ワークフローにより、関係者は、リアルタイムの同期対話やアクティブなインターネット接続を必要とせず、標準化された直感的な方法で自分のペースでタスクやプロセスに貢献できます。この柔軟なアプローチにより、効率的なコラボレーションが可能になり、情報不足、スケジュールの矛盾、リソースの制約、地理的障壁によって引き起こされるボトルネックが軽減されます。次に、構造化されたビデオ、および関連する音声データとユーザー入力データが Vyn ソリューション上で非同期的に分析および処理され、タイムリーな洞察と状況認識が提供され、より適切な意思決定と所要時間の短縮が促進されます。 ケーススタディ 顧客が新しいヒートポンプの設置または水漏れの修理を必要とするシナリオを想像してください。従来は、連絡先の電話番号に電話し、状況をよりよく理解するために時間のかかる込み入った質問に案内されることで連絡を開始していました。そして、これらの応答は、場所とタスクに関する十分なコンテキスト情報なしで技術者を派遣することになります。技術者の準備に役立つデータの不足がもたらす、適切な部品の欠如、作業範囲の誤解、サイトへのアクセスの問題などにより、5 ～ 10% の作業で複数回の訪問が必要になります。一部の公益事業者は、見積もりや作業範囲を準備するために複雑なコンテキスト データが必要なサービス リクエストに対して、公益事業者の技術者または営業担当者による作業前/設置前調査の訪問をスケジュールすることで、この問題に対処しています。このアプローチは、技術者が適切に準備され、効率的に作業を完了するために必要な知識を備えていることを確認するのに役立ちますが、訪問回数が多くなります。 　図 1: Vyn を使用した強化されたカスタマー エクスペリエンスとフィールド サービス ワークフロー Vyn® カスタマー セルフサービス ソリューション は、顧客と現場チームの負担を同様に軽減するように設計されています。顧客は、携帯電話で (ユーティリティのアプリ上で、またはアプリを使用しない Web キャプチャ メカニズムを通じて) ユーティリティから最前線のサービス リクエストを行うことができます。この合理化されたアプローチにより、運用チームと計画チームはダッシュボードでリクエストをリアルタイムに把握できるようになり、当面の問題を包括的に理解できるようになります。これにより、サービス リクエストを 360 度把握できるようになり、派遣前に訪問や次善のアクションを適切にカスタマイズできるようになります。 実際の視覚データに基づいて構築された CV モデルを使用することにより、Vyn ソリューションは、緊急性、複雑さ、問題の種類などの重要な側面に基づいてサービス リクエストにフラグを付け、スコアを付けることができます。さらに、生成 AI により、顧客の要求の口頭説明をすぐに要約することができ、言及された重要な問題、一般的な次のステップ、顧客の緊急性などの有用な洞察を抽出できます。 Vyn® Field Service Proof-of-Work ソリューションを使用すると、現場担当者は、工事前、工事中、工事後の構造化されたビデオ ワークフローをキャプチャして、どのように現場を特定し、作業範囲を設定し、公益事業者の求める品質と安全基準に応じてタスクの完了を証明するかを示すことができます。単一のフレームワーク内で、公益事業者は複数の目的を達成できます。 労働者が規制および安全手順に従っていることを確認する 品質保証 (QA) プロセスを迅速化および自動化する 作業後に再度 QA を訪問する必要がなく、作業が満足に完了したという証拠に基づいて請負業者に迅速に支払う 公益事業者は、経験の浅い現場作業員をリモートで監督し、訓練するために経験豊富な専門家をより適切に活用できるように、従業員を再編成することもできます。最前線での作業中に詳細なビデオ メモや現場のニュアンスを記録できる Vyn ソリューションの機能により、組織は従業員の専門知識を収集し、検索可能なタグ付きビデオの Vyn® データベース上にナレッジ マネジメント機能を構築することが可能になります。 ソリューションアーキテクチャ Vyn は、信頼性が高く、スケーラブルで安全な Software-as-a-Service (SaaS) ソリューションであり、さまざまなクラウドネイティブでサーバーレスのアマゾン ウェブ サービス (AWS) を使用して、インテリジェントなマルチメディア データのキャプチャ、消費、分析を行います。 Vyn ソリューションは、従来の機械学習 (ML) モデルと新しい大規模言語モデル (LLM) を組み合わせて使用し、正確なフィールド評価と予測を生成します。 ガイド付きビデオプロセス エンドユーザーは、ウィザードに似たガイド付きビデオ プロセスに取り組み、コンテキスト固有の質問をし、ビデオを録画し、画像をキャプチャし、必要に応じて定性的および定量的データも取得します。このインタラクティブなプロセスにより、ユーザーの応答、ビデオ コンテンツ、音声録音、および関連するメタデータをカプセル化する「SmartVideoNote®」 (SVN) が作成されます。 サーバーレス予測パイプライン Vyn の人工知能 (AI) 機能の中核は、サーバーレス予測パイプラインです。このパイプラインは SVN を入力として受け入れ、統合分析に基づいて包括的な評価を提供します。次に、個々のコンポーネントとワークフローを詳しく調べます。 ガイド付きプロセスを使用して新しい SVN が記録されると、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを備えた AWS オブジェクト ストレージ サービスを使用して、組織固有の Amazon S3 バケットに保存されます。 S3 バケットでは暗号化がデフォルトで有効に設定されており、アップロードされたオブジェクトは AWS Key Management Service ( AWS KMS ) を使用して保存時に自動的に暗号化されます。 Vyn は、Bring Your Own Bucket (BYOB) 統合パターンを使用します。顧客ごとに、予測パイプラインによるさらなる処理のために SVN およびその他の関連データを保存する S3 バケットが登録されます。 新しい SVN が登録された S3 バケットの 1 つに到着すると、Configurator Lambda 関数がトリガーされ、Vyn 設定に基づいて入力 SVN を処理するワークフローが決定されます。これにより、実行時のコンテキストとワークフローに基づいて、受信 SVN に関連するモデルと構成を選択する際の高いレベルの柔軟性が提供されます。 図 2: Vyn サーバーレス予測パイプライン Vyn は AWS Step Functions を 使用して、ML パイプラインのステートマシンとして知られる高度なワークフローを定義して実行します。特定のステートマシンが開始されると、 AWS Lambda 関数と Amazon Elastic Container Service ( Amazon ECS ) タスクの両方を含む一連のステップが順次または並列で実行されます。 ML モデル推論 これらの Vyn ワークフローには、次の ML 機能が含まれています。 LLM 推論: Lambda 関数を使用して、 Amazon Bedrock API を通じて LLM を呼び出し、主要な AI スタートアップ企業や AWS による高性能基盤モデルにアクセスします。これにより、堅牢なセキュリティ、コンプライアンス、プライバシー、責任ある AI 実践を備えた最先端の生成 AI 機能に確実にアクセスできるようになります。 Amazon Bedrock は、ISO、SOC、GDPR などの一般的なコンプライアンス標準の対象にもなっています。 従来の ML 推論: Amazon ECS タスクは、コンピューター ビジョン用の ResNet-50/YOLO や他の自然言語処理タスク用の BERT/Sentence Transformers などの従来の ML モデルを呼び出すために使用されます。 モデル推論がどのように機能するかを説明するために、消費者が自宅または敷地からの水漏れを報告するシナリオを考えてみましょう。従来の CV モデルは、現場で水溜まりの兆候を自動的に検出し、漏水の原因が敷地内の水道メーターなのか、それとも別の水源なのかを特定できました。これらのモデルは、水漏れが敷地内で発生しているか、敷地外で発生しているかを識別することもできます。これを補完するものとして、Amazon Bedrock API を通じてアクセスされる生成 AI モデルでレポートをさらに分析し、問題の重大度と緊急性を評価することができます。次に、これらのモデルは、消費者のレポートで提供された特定の詳細とコンテキストを考慮して、修理ジョブに適切な優先レベルを推奨できます。 Amazon ECS タスクと Lambda 関数は、その出力 (証拠フレームなど) を「生成データ」と呼ばれる専用の S3 バケットに保存します。このバケットは、SVN 識別子によって一意に識別されます。 出力処理とバックエンド処理 ワークフロー内のステップが完了すると、実行中のステートマシンはさまざまなモデル出力を結合し、単一のメッセージとして Amazon Simple Queue Service ( Amazon SQS ) キューに入れます。 Vyn AI 予測パイプラインは、バックエンド パイプラインによってサポートされています。このバックエンド パイプラインは、これらの SQS メッセージを処理し、Vyn 製品によって提供されるマルチメディア アーティファクト、ワークフローの詳細、コラボレーション、およびダッシュボード機能の側面を処理する役割を果たします。 結論 公益事業部門は、リソース計画と現場運営の効率を高めながら、優れた顧客サービスを提供するという重大な課題に直面しています。従来のワークフローは、老朽化したインフラストラクチャ、分散した資産の場所、環境要因によってストレスを受けており、遅延、誤解、フラストレーションを引き起こしています。 これらのハードルを克服するために、Vyntelligence は AWS の堅牢な基盤上で生成 AI および CV テクノロジーを使用した探索的アプローチを開発しました。 Vyn® ソリューションは、従来の ML モデルと最先端の LLM を組み合わせることで、正確で状況に応じた洞察を提供し、組織が顧客満足度、現場の生産性、そして最終的にはエンドツーエンドのエクスペリエンスを向上できるようにします。 行動喚起 Vyntelligence SmartVideoNotes® テクノロジーとソリューションについて詳しく知りたい場合は、 そのサイトにアクセスしてください 。AWS がエネルギーおよび公益事業の変革にどのように役立つかについて詳しく知りたい場合は、 エネルギーおよび公益事業の AWS についてお読みください。 本稿は、ソリューションアーキテクトの橋井 雄介が翻訳しました。原文は “Improving Utility customer experience and field service efficiency using generative AI” を参照してください。 Mayank Sharma Mayank Sharma は、企業の作業保証のためのビデオ インテリジェンス プラットフォームである Vyntelligence の最高データ責任者です。この役割では、顧客が品質、効率、安全性、持続可能性に関するビジネス成果を実現できるよう支援することに重点を置き、データ、製品、ソリューション戦略を推進する責任を負っています。彼は、データ分析、機械学習、プロセス最適化の専門知識を持つ経験豊富な技術者です。以前は、IBM TJ Watson Research Center の研究スタッフ メンバー、および Raymond James のデータ サイエンス部門責任者/技術担当副社長を務めていました。彼はデリー工科大学の技術学士号と、スタンフォード大学の博士号を取得しています。彼は研究者として広く出版しており、20 件の特許を取得しています。 Arun Anand Arun Anand は、ヒューストン地域に拠点を置くアマゾン ウェブ サービスのシニア パートナー ソリューション アーキテクトです。彼はエンタープライズ アプリケーションの設計と開発において 25 年以上の経験があります。彼は、エネルギーおよび公共事業セグメントの AWS パートナーと協力して、新規および既存のソリューションに対するアーキテクチャとベストプラクティスの推奨事項を提供しています。仕事以外では、アルンは読書、散歩、友人や家族のためにカクテルを作ることを楽しんでいます。 Mohit Mehta Mohit Mehta は、ロンドンを拠点とするスケールアップ企業 Vyntelligence のテクノロジー リーダーであり、AI 部門を率いています。彼はテクノロジーを活用してビジネス変革を推進し、AI 分野で影響力のあるソリューションを作成することに情熱を注いでいます。 Vyntelligence は、機械学習と生成 AI を活用して、現場およびサービスの専門家に対してニュアンスを含んだデータ駆動型の洞察を提供します。 Mohit は、数学、コンピューター サイエンスの上級学位、および経営革新と戦略の博士号を取得しています。

生成系人工知能 (AI) アシスタントである Amazon Q Developer は、AWS でのアプリケーション開発を加速するのに役立ちます。 Amazon Q を統合開発環境 (IDE) で使用する場合、ソフトウェア開発を支援します。 Amazon Q では、コードに関するチャット、インラインコード補完、新しいコードの生成、コードのセキュリティ脆弱性スキャン、言語の更新、デバッグ、最適化などのコードのアップグレードや改善を行うことができます。 Amazon DynamoDB は、大規模環境で 1 桁ミリ秒単位のパフォーマンスを実現するサーバーレス NoSQL データベースサービスです。 DynamoDB は、 AWS マネジメントコンソール またはプログラムで操作できます。 プログラムで作業する場合の一般的なアプローチは、 AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの infrastructure as code (IaC) ツールを使用してテーブルを管理し、プログラミング言語 SDK を使用してテーブルにデータを読み書きする方法です。 Amazon Q はこれら両方を支援して、開発のスピードを向上させます。 本記事では、IaC を使用して DynamoDB テーブルを作成し、 Python and Boto3 を使用してテーブルに対して作成、読み取り、更新、削除 (CRUD) オペレーションを実行します (本記事の最後には、JavaScript と Java に関するその他の注意点も記載しています)。 Amazon Q がこれらのタスクの開発速度をどのように向上させるかを説明します。 (本記事は 2024/09/12に投稿された Faster development with Amazon DynamoDB and Amazon Q Developer を翻訳した記事です。) Amazon Q とのやり取り 今回のデモンストレーションでは、 Amazon Q Developer プラグインを IDE にインストール しました。 Amazon Q とやりとりする方法は次の 2 つです。 IDE の チャットパネル 。テキストバーに自然言語のリクエストを入力し、その応答を評価します。 IDE での インライン候補 。 編集中のソースコードファイルに自然言語コメントを追加し、Amazon Q が提供する提案を評価します。 Amazon Q で使用されるすべてのプロンプトが用意されているため、さらに詳しく説明できます。 生成 AI アシスタントは非決定的です。この演習を自分で繰り返しても、例と同じ出力が得られない場合がありますが、Amazon Q は引き続き有益であると確信しています。 自分で書いたコード (提案された Amazon Q コードも含む) の所有権はお客様にあります。 コードの提案を受け入れる前に必ず確認レビューを行う必要があります。また、コードが意図したとおりに動作するように編集が必要がある場合もあります。 DynamoDB テーブルの作成 AWS CloudFormation を使用してソリューションを作成していますが、このプロセスは AWS Serverless Application Model (SAM) CLI または AWS CDK でも機能します。 YAML CloudFormation テンプレートに DynamoDB テーブルを作成します。 このテーブルには、IoT デバイスからの温度値が格納されます。 Amazon Q に IDE のチャットパネルでこれを生成するように依頼しています。 チャットのリクエストと応答は、次のスクリーンショットに示されています。 推奨されたコードは理想的ですが、テーブルに IotDynamoDBTable という名前を付ける要件を忘れていました。 チャットパネルは会話形式で、以前のやりとりを記憶しているので、この追加要件を依頼できます。 提供されたソリューションは私たちが望むものなので、IDE のテキストファイルにコピーして受け入れます。 これにより、CloudFormation YAML を生成する時間を節約できました。 テキストファイルは好きなように編集できます。 global secondary index (GSI) や stream を追加するなどしてテーブルをさらに拡張したい場合は、次の 2 つの方法のいずれかを使用できます。 Amazon Q チャットパネルで会話を続ける テキストファイルにコメントを追加してAmazon Q からインラインレスポンスを受け取る この例では、Amazon Q がインライン候補を提供できるように、コメントを追加して、テキストファイルに既にある内容を拡張してみます。 提案が良ければ、受け入れて続けることができます。 このやりとりは次のアニメーションで確認できます。 CRUD オペレーションの実行 このセクションでは、Amazon Q の助けを借りて DynamoDB テーブルで CRUD オペレーションを実行する例を紹介します。 Create AWS Lambda 関数で実行されるコードのサンプルを作成し、イベントからすべてのレコードを読み取って DynamoDB テーブルに書き込みます。 イベントのレコードは Amazon Simple Queue Service (Amazon SQS) キューから生成されました。 チャットパネルに戻って始めましょう。 リクエストには、イベントの記録に関する詳細は記載されていませんでした。 この詳細がないため、Amazon Q は提案を作成しましたが、私たちが望んでいたものとはまったく異なります。 繰り返しますが、次の 2 つの選択肢があります。 チャットパネルで会話を続け、リクエストを明確にする コードをテキストエディターにコピーし、手動で変更を加える 変更が簡単なため、2番目のオプションを選択しました。 結果は次のスクリーンショットに示されています。 この修正を含めても、Amazon Q でこの関数を作成するほうが、手動で作成した場合よりも早くなります。 Read 今度は、テーブルから項目を読み込むようにコードを拡張します。 deviceId と readingTime の値がわかっているので、プライマリキーを使用して直接検索できます。 必要なものを説明するコメントを Lambda 関数コードに追加し、Amazon Q に推奨コードを提供させます。 これは次のアニメーションで確認できます。 Amazon Q の提案を受け入れました。 これには、更新する必要のあるプレースホルダー、つまり deviceID の値が含まれています。 これは簡単な変更で、テーブルから項目を読み込む方法を調べるために IDE を離れる必要はありませんでした。 Update 繰り返しになりますが、あるアイテムの deviceId と readingTime の値がわかっているので、それを更新したいと考えています。温度の値が 150 より大きい場合に限り、 badReading という値に true という属性を追加します。 テキストファイルにコメントを追加し、Amazon Q にサンプルを提供させます。 これは次のアニメーションで確認できます。 提案には更新用のプレースホルダーが含まれています。 これは間違いなく時間の節約になります。特に、この操作のドキュメントや例を調べる必要がある場合はなおさらです。 提案を受け入れ、 deviceId の値を更新して完成させます。 Delete 削除したい deviceId と readingTime の値がわかっています。 このリクエストをさらに詳しく説明するために、この操作が消費した容量と、削除前のアイテムの状態を返すように操作する必要があります。 テキストファイルにコメントを追加し、Amazon Q にサンプルを提供させます。 この結果は次のスクリーンショットで確認できます。 サンプルを受け入れ、プレースホルダーを更新してコードを完成させます。 クエリ操作の実行 DynamoDB クエリ オペレーションは非常に強力です。1 回のオペレーションで、パーティションキー値は同じでソートキー値が異なる一連の項目を取得したり、キー以外の属性でフィルタリングしたり、ソートしたり、制限したりできます。 これらは、これまで見てきた CRUD 操作よりも実装が複雑です。 この例では、特定の deviceId で昨日発生した温度測定値が 10 ～ 20 度のすべてのアイテムを返すクエリを実行したいと考えています。 対象となるのは、その条件を満たす最新の 5 つのアイテムだけです。 Amazon Q には、すばやく反復処理できる複数のサンプルが用意されています。 仕事を続けるための基盤として、最も良いと感じるものを選びます。 これは次のスクリーンショットで確認できます。 KeyConditionExpression は正しいですが、 readingTime には定数値があります。 これを手動で改善するか、コメントを改善して再試行するか、問題を分解して Amazon Q に1つずつ解決してもらうことができます。 ヒントとして、 time モジュールと datetime モジュールのインポートをファイルの先頭に追加します（Amazon Q はインポートステートメントをコンテキストとして重視しており、それらを使用する提案を優先します）。 次に、問題を分解し、Amazon Q に問題を解決させます。 次のスクリーンショットの各コメントは、Amazon Q に解決を依頼した問題の一部であり、そのコードが選択された提案です。 次のコメントを書く前に、Amazon Q に問題を解決させます。 JavaScript と Java を使った作業 JavaScript を使った実験から、開発者のエクスペリエンスはこの記事ですでに示したPythonのものとほぼ同じであることがわかりました。 SDK を使用して DynamoDB を操作するには、 v1 (非推奨)、 v2 、 拡張クライアント など、複数のアプローチがあるため、Java のエクスペリエンスは少し変わりやすくなります。 Amazon Q では、プロジェクト内の既存のコードを、どのアプローチを使用するかのコンテキストとして使用します。 既存のプロジェクトを変更する場合、他のプロジェクトと同じアプローチでサンプルを受け取る可能性があります。 プロジェクトが新しい場合は、現在編集中のファイルの先頭に関連する import ステートメントを追加することで、最初の提案でどのアプローチを使用するかを強く決定できます。 チャットパネルとインラインの両方が、これらのインポートステートメントをコンテキストとして使用します。 以下は、2 つの SDK オプションのインポート例です。 v2 — import software.amazon.awssdk.services.dynamodb.* 拡張クライアント — import software.amazon.awssdk.enhanced.dynamodb.mapper.annotations.* 追加のサポートコードの生成 完全に機能するソリューションを構築するには、追加のサポートコードが必要です。 たとえば、CloudFormation テンプレートには Lambda 関数と関連する AWS Identity and Access Management (IAM) role が必要です。 Amazon Q を使用してこのコードを生成することもできます。 Amazon Q が DynamoDB の運用にどのように役立つかに焦点を当ててきましたが、私たちの経験から言うと、Amazon Q はこれらのリソース (およびその他) を生成する際の時間の節約にも非常に効果的です。 結論 この投稿では、IaC を使用して DynamoDB テーブルを作成し、Amazon Q を使用して CRUD オペレーションを実行する方法を示しました。Amazon Q では、ニーズに応じて自然言語で表現されたサンプルコードを提供することで、DynamoDB を使用する際の時間を節約できます。 提案に少し変更を加えたり、大きくて複雑なリクエストを小さく分割したりすることで、Amazon Q の支援なしにコードを書く場合よりも速く動作するコードを作成できます。 Amazon Q は、計画からメンテナンスまで、ソフトウェア開発ライフサイクル全体をサポートできます。 Amazon Q が各段階でどのようにサポートできるかについては、「 Accelerate your Software Development Lifecycle with Amazon Q 」を参照してください。 Amazon Q の詳細については、 Amazon Q Developer Guide を参照してください。 また、 Best Practices for Prompt Engineering with Amazon CodeWhisperer | AWS… 　でプロンプト (Amazon Q が提案を生成するために使用する自然言語のコメント) をベストプラクティスに合わせる方法を学ぶこともできます。 DynamoDB の詳細については、 Amazon DynamoDB Developer Guide を参照してください。 作者情報 Chris Gillespie は英国を拠点とするシニアソリューションアーキテクトです。 彼は仕事のほとんどを、変化の速い「born in cloud」の顧客と過ごしています。 仕事以外では、家族との時間を充実させ、体調を整えるよう努めています。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 11 月 15 日に、「生成AI Frontier Meet Up」というイベントを開催しました。このイベントは「AWSジャパン生成AI実用化推進プログラム」の一環として開催したもので、様々な課題を独自のモデル開発によって解決しようとするお客様、公開モデルを利用することで解決しようとするお客様の両方に登壇をいただき、取り組みの概要や現在のチャレンジについて共有をいただきました。また、このイベントには経済産業省が展開するGENIAC(Generative AI Accelerator Challenge)に採択された企業の方もお招きし、同様に取り組みの内容を共有いただいています。 開催概要とレポートをブログにまとめています ので、ぜひご覧ください。 「 AWSジャパン生成AI実用化推進プログラム 」のお申し込みも引き続き募集しています。締め切りを延長し11月22日までとしていましたが、多くのお客様から「もっと時間がほしい」というご相談をいただいています。お客様の熱い声にお応えする形で、2025 年 2 月 14 日まで申し込み締め切りを延長することにしました。3月末までに開発完了するというスケジュール感は同じですので、興味のある方はお早めにお知らせくださいね。 それでは、11 月 18 日週の生成AI with AWS界隈のニュースを見ていくのですが、さすがre:Invent直前ということもありすごい物量です。でもこれはまだ序の口。re:Invent期間中は（まだ私も知らないのですが、きっと）すごいアップデートが生成AI関係はもちろん、それ以外にも発表される見込みです。ぜひ AWS Blackbelt Online Seminer re:Invent特集号 で、一気にキャッチアップしてください。今年はYoutubeの仕組みを使って登録不要でご覧いただけますが、「通知を受け取る」をクリックしてお見逃しないようにご注意を。 さまざまなニュース AmazonとAnthropicの戦略的コラボレーションの深化を発表 昨年9月に発表したAmazonとAnthropicの戦略的コラボレーションですが、今回これをさらに深めるという発表を行いました。これに伴ってAmazonはAnthropicに追加で40億米ドルの投資を行い、AnthropicはAmazonをPrimary Training partnerと位置づけて最大規模の基盤モデルをAWS Trainiumを利用してトレーニング・デプロイするという計画が発表されています。詳細についてはぜひリンク先でご確認ください。 ブログ記事「 Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス」を公開 この記事では、Amazon Bedrock Agentsを利用して生成AIアプリケーションを構築するためのベストプラクティスを解説します。生成AIアプリケーションにおいて注目されているのがエージェントです。解決のために複数のステップが必要な複雑なタスクを処理できるようにするものですが、それを開発するためにはいくつかの留意点があります。この記事ではエージェントの開発のために必要なポイントを解説していますので、ぜひご覧ください。(2部構成になっています。 第2部はこちら ) ブログ記事「臨床生成 AI ワークフローの AWS Step Functions による オーケストレーション」を公開 生成AI技術の応用が期待されている分野のひとつとして、医療分野があります。生成AIを活用することで患者さんによりよいケアを提供したり、臨床業務を効率化することが期待されています。このブログ記事では、臨床現場で利用する生成AIアプリケーションをAWS Step Functionsによるオーケストレーション機能を利用して開発する方法について解説しています。 サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション AWS Management ConsoleにおけるAmazon Q Developerでコンテキストを考慮した応答が可能に AWS Management ConsoleにはAmazon Q Developerが組み込まれており、ユーザはいつでもAIアシスタントに質問することが可能です。今回、このAmazon Q Developerの機能が強化され、現在表示しているページに基づいて、コンテキストに応じた応答を返せるようになりました。つまり、ユーザの関心事により適した応答が得られるようになったということですので、ぜひ一度試してみてください。 Amazon Q Businessがドキュメントに埋め込まれた表の情報に基づく回答に対応 Amazon Q Businessがドキュメントに埋め込まれた表(テーブル)に含まれる情報からの回答をサポートしました。ドキュメントには価格表や製品仕様表など、表形式で重要なデータが表現されている場合があります。今回のアップデートにより、Amazon Q Businessが表の情報を適切に収集・整理して、ユーザからの問い合わせの回答に利用できるようになりました。 Amazon Q Businessがユーザ対応において過去にアップロードされたファイルの再利用に対応 Amazon Q Businessでは、ユーザの求めに応じてアップロードされたファイルの要約や回答を行うことが可能です。今回のアップデートで、過去にアップロードしたファイルを新しい会話セッションの中で再利用できるようになりました。あるやりとりが完結した後に、改めて同じファイルに対して質問する場合に再度アップロードすることなく、AIアシスタントとの対話を開始することが可能です。 Amazon Q Businessのブラウザ拡張機能が利用可能に Amazon Q Businessのブラウザ拡張機能が利用できるようになりました。Google Chrome, Mozilla Firefox, Microsoft Edgeが対象になっており、Webページの要約やコンテンツに対する質問など、大規模言語モデルの活用をブラウザ内から直接実行できるようになります。 Amazon Q BusinessでGoogle Calnederとのインテグレーション機能のプレビューを開始 Amazon Q BusinessでGoogleカレンダーへのコネクタが利用できるようになりました。今回のアップデートによって、従来からサポートされていたGoogleドライブやGmailに加えてカレンダーについてもAmazon Q Businessでカバーできるようになりました。 Amazon Q BusinessでAsanaとのインテグレーション機能のプレビューを開始 Amazon Q BusinessでAsanaへのコネクタを利用できるようになりました。ご存じの方も多いかもしれませんが、Asanaはエンタープライズ企業で多く利用されるタスク管理プラットフォームで、Amazon Q BusinessがAsanaのデータについてもインデックス化して、プロジェクトのコンテキストに基づいた質問への回答や要約の生成が可能になります。 Amazon Q BusinessのSmartsheet向けコネクタが一般利用開始に Amazon Q BusinessでSmartsheetと連携するためのコネクタが一般利用開始になりました。Smartsheetは作業管理プラットフォームで、このコネクタを利用することでAmazon Q BusinessがSmartsheetで管理されるプロジェクトやタスクに関する情報に基づいて応答できるようになります。 Amazon Q Developer in AWS Chatbotが一般利用開始に Amazon Q Developer in AWS Chatbotが一般利用開始になりました。この機能を利用するとSlackやMicrosoft TeamsでAWSリソースに関する質問に回答できます。例えば、「@aws show ec2 instances running state in us-east1(us-east1で稼働中のEC2インスタンスを表示してください)」といったクエリを、チャットツールの中で実行して結果を得ることができます。 Amazon Q Developer Chat Customizationsが一般利用開始に Amazon Q Developerのチャットカスタマイズ機能が一般利用開始になりました。Amazon Q Developerをプライベートなコードベースと安全に接続することにより、組織内のAPIやライブラリ、クラス、メソッドなどを考慮したより適切な応答を得ることができるようになります。 AWS App Studioが一般利用開始に AWS App Studioが一般利用開始になりました。生成AIの技術を活用することによって、自然言語で必要なビジネスロジックやUIを指示するとApp Studioがそれを解釈してアプリケーションを作成することができるサービスです。Amazon S3やAmazon AuroraをはじめとするAWSのサービスや、SalesforceやZendeskなどと連携するコネクタも用意されており外部とのデータ連携も容易に実現できるのもポイントです。 AWS Console Mobile AppでAmazon QによるAWS Account Resource chatが利用可能に AWS Console Mobile AppでもAmazon Q Developerが提供するアカウントのリソースに関するチャット機能がご利用いただけるようになりました。デバイスの音声入出機能と組み合わせて利用することも可能です。モバイルアプリから利用する場合、Amaozn Qはモバイルデバイスでも見やすい形式でデータを出力するようになっていますので、ぜひ試してみてください。 サービスアップデート – アプリケーション開発のためのツール Amazon Bedrockのプロンプト最適化機能のプレビューを開始 Amazon Bedrockのプロンプト最適化機能のプレビュー開始を発表しました。基盤モデルから適切な応答を得るためには、適切なプロンプトを与えることが必要です。プロンプトは利用するモデルごとにベストプラクティスやガイドラインが用意されており、最良の結果をえるにはそれに従う必要があります。Bedrockのプロンプト最適化機能は、利用する基盤モデルの種類に応じてプロンプトを書き換えることでモデルに応じた最適化を実行します。元のプロンプトと最適化後のものは容易に比較することができ、アプリケーションで再利用できるように保存することが可能です。 Amazon BedrockのTitan Text EmbeddingsがBinary Embeddingsに対応 Amazon Titan Text Embeddings v2がBinary Embeddingsをサポートしました。Titan Text Embeddingsは入力されたデータを1,024/512/256次元のベクトル値に変換します。ベクトル値を構成する各次元のデータを小数ではなく0/1のバイナリで表現することでデータ量を削減することで、検索拡張生成(RAG)をはじめとする生成AIアプリケーションで利用されるベクトルデータベースへの負荷を軽減し、コスト効率の向上が期待できます。 Amazon Bedrock Knowledge BasesがBinary Bector EmbeddingsによるRAGをサポート Amazon Bedrock Knowledge BasesでTitan Text Embeddings V2とCohere Embedを利用したバイナリの埋め込み形式データを利用して、RAGを構築できるようになりました。特に大規模なユースケースにおいて、ストレージ効率や応答速度、スケーラビリティの向上によるメリットが期待できる選択肢となります。 Amazon Bedrock Flowsが一般利用開始になり2つの機能追加を発表 Amazon Bedrock Flows(Prompt Flowsから名前が変わりました)が一般利用開始になるとともに、2つの重要な機能追加が行われました。Amazon Bedrock Flowsを利用すると基盤モデルを中心とし、プロンプトやエージェント、ナレッジベースなど様々なAWSサービスが関与する生成AIワークフローをビジュアルビルダーで素早く開発できます。今回の機能追加でGuardrailsによる保護と、追跡可能性の強化が行われています。詳細は ブログ記事 をご確認ください。 Amazon Bedrock Model Evaluationがソウルのリージョンでもご利用可能に Amazon Bedrockのモデル評価機能がアジアパシフィック(ソウル)のリージョンでもご利用いただけるようになりました。 サービスアップデート – 生成AI開発のためのインフラストラクチャー Amazon EC2 G6eインスタンスが東京リージョンでも利用可能に Amazon EC2 G6eインスタンスが東京・フランクフルト・スペインのリージョンでご利用いただけるようになりました。G6eはNVIDIA L40S Tensor Core GPUを搭載し、G5と比較して2.5倍の性能を発揮するとともに、P4dと比較して20%安価に推論ワークロードを実行可能です。 サービスアップデート – その他関連アップデート Amazon OpenSearch Serverlessがコスト節約を可能にするBinary VectorとFP16をサポート Amazon OpenSerach Serverlessでメモリ要求量を減らすことで費用の節約につながる、Binary vectorとFP16をサポートしました。費用の節約と同時にレイテンシーの削減も期待できます。生成AIを組み込んだアプリケーションではベクトルデータベースを必要とするケースがありますが、蓄積する情報量が多くなればなるほどベクトルデータベースの費用が増加します。検索精度とのトレードオフな部分はありますが、この機能を利用することで用途に応じてコストと精度のバランスを調整することが可能になるのがポイントです。 Amazon OpenSearch ServiceのベクトルエンジンがUltraWarmをサポート Amazon OpenSearch ServiceのUltraWarmは、大量のデータを削除することなくアクセス可能な状態でコスト効率高く保存するためのウォームストレージです。今回、k-NNインデックスのデータをUltraWarmに保存できるようになりました。ウォームストレージは通常の(ホットな)ストレージと比較してパフォーマンスは落ちますが保管コストが大幅に安価になるので、頻繁に使わない(でも保存しておいて必要に応じて即時アクセスしたい)データを格納するのに最適です。 AWS Glueで生成AIによるApache Sparkのアップグレード機能をプレビュー開始 AWS Glueはサーバレスなデータ統合サービスでいわゆるETL処理を容易に実行することができます。ETLジョブはSparkを利用して実行することも可能なのですが、今回新たに生成AIの技術を活用して古いバージョンのSparkジョブを自動的に最新バージョン向けにアップグレードできるようになりました。 AWS Glueで生成AIによるApache Sparkのトラブルシュート機能をプレビュー開始 AWS GlueでApache SparkによるETLジョブに対して、生成AIを活用してトラブルシュートを行う機能が利用できるようになりました。Sparkジョブで発生した問題の原因分析と、解決のための推奨事項を自動的に提示することで、問題解決を加速します。 AWS AmplifyのAI Kit for Amazon Bedrockを発表 AWS Amplify AI Kit for Amazon Bedrockを発表しました。これは開発者の方が、チャットや会話型検索、要約などの機能を備えたアプリケーションを素早く開発できるようにする仕組みです。JavaScript, TypeScritと、React, Node.jsなどの知識があれば機械学習に関する専門知識がなくとも、アプリケーションにAIベースのエクスペリエンスを容易に追加することができます。 AWS re:Post PrivateがAmazon Bedrockとインテグレーションされコンテキストにそった知識を組織内に展開可能に AWS re:Post Privateは、AWSに関する情報やQ&Aが可能なコミュニティサイトのプライベート版です。今回このre:Post PrivateがAmazon Bedrockとインテグレーションされました。組織内の情報とAWSに関するナレッジを重ね合わせて、組織ごとのルールや慣習をふまえた回答を生成するようになるため、組織内の知見の有効活用にもつながることが期待できます。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 AWS re:Invent 2024 が近づくにつれて、注目の大型アップデートが続々と発表されています。同時に、実用的な機能追加やサービス改善も数多く行われています。今回は数が多いため、各アップデートについて要点を絞って簡潔に紹介させていただきます。また、生成 AI に関するアップデートは、基本的には 週刊生成AI with AWS で取り上げていますので、こちらもご覧ください。本番の re:Invent でどのような発表があるのか、今から非常に楽しみですね。re:Invent はオンラインの視聴が可能なので、ぜひ こちら から登録のうえご視聴ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年11月18日週の主要なアップデート 11/18(月) Amazon ECS で VPC Lattice を利用した接続をサポート  Amazon ECS で VPC Lattice を利用した接続をサポートしました。ALB を経由することなく、ECS サービスを VPC Lattice のターゲットグループに直接関連付けることができるようになりました。詳細は こちらのブログ をご確認ください。 AWS Lambda が Python と .NET で SnapStart をサポート AWS Lambda で、Python および .NET のマネージドランタイムを使用する関数で Lambda SnapStart を利用できるようになりました。遅延に敏感なアプリケーションでは、コールドスタートとして知られる起動時間の遅延がユーザー体験に影響を出してしまう場合があります。Lambda SnapStart は、事前に初期化された実行環境のスナップショットをキャッシュすることで、起動にかかる時間を短縮できます。 Amazon DynamoDB、属性ベースのアクセス制御の一般提供を発表 DynamoDB のテーブルとインデックスに対する属性ベースのアクセス制御 (ABAC) をサポートしました。ABAC は、ユーザー、ロール、および AWS リソースに付加されたタグに基づいてアクセス権限を定義できます。これまでプレビューだったものが、一般提供となった形です。 AWS IoT SiteWise、新しい生成 AI 搭載の産業用アシスタントを提供開始 AWS IoT SiteWise は、産業用機器データの大規模な収集、整理、監視を簡素化するマネージドサービスです。IoT SiteWise に、生成 AI が搭載されたアシスタント機能が追加され、自然言語による問い合わせができるようになりました。「アラームが出ているアセットは何か？」や「風力タービンの RPM が低い問題を修正するにはどうすればよいか？」といった自然言語で質問ができるようになり、蓄積データの分析が簡単にできるようになります。 Amazon Aurora MySQL 3.08 (MySQL 8.0.39互換) が一般提供開始 Amazon Aurora で MySQL 3.08 (MySQL 8.0.39 互換) をサポートしました。複数のセキュリティ強化とバグ修正に加えて、大量のテーブルを処理する際のデータベースの可用性が向上し、redo ログやインデックス処理に関連する InnoDB の問題を軽減する機能強化が含まれています。 11/19(火) Amazon OpenSearch Serverless が Binary Vector と FP16 によるコスト削減機能をサポート Amazon OpenSearch Serverless で、メモリの使用容量を削減し、OCU コスト低減に役立つ、Binary Vector と FP16 をサポートしました。データをメモリ上で扱う際に、バイナリ形式や 16 ビット浮動小数点といった形式でデータを保持でき、従来の 32 ビット浮動小数点と比べて、必要なメモリリソースの削減を可能とする仕組みです。 Amazon VPC で Block Public Access (BPA) を提供開始 VPC で Block Public Access を提供開始しました。これは、ネットワークおよびセキュリティ管理者が VPC のインターネットトラフィックを確実にブロックできる、新しい集中型の宣言的制御機能です。VPC BPA は他のすべての設定より優先され、組織のセキュリティとガバナンスポリシーに準拠して、VPC リソースがインターネットアクセスから保護されることを保証します。詳細は こちらのブログ をご覧ください。 Amazon ECS でソフトウェアバージョンの一貫性に関する動作を無効に設定可能 Amazon ECS は、ECS サービスを新規作成や更新した際に、コンテナイメージタグをイメージダイジェスト (SHA256 ハッシュ) で解決します。この動作により、サービス内のすべてのタスクで同一のイメージを利用することを保証します。今回のアップデートで、この動作を無効化できるようになりました。コンテナイメージタグに Latest を指定して、順次最新のイメージを利用する、そういったユースケースに対応しやすくなりました。 Amazon EFS がクロスアカウントレプリケーションに対応 Amazon EFS が、AWS アカウント間のクロスアカウントレプリケーションに対応しました。EFS レプリケーションを使用することで、別の AWS アカウントの指定した AWS リージョンに、ファイルシステムの最新のレプリカをコピーできます。 Amazon Bedrock の Titan Text Embeddings V2 モデルでバイナリ埋め込みをサポート Amazon Bedrock で提供されている Titan Text Embeddings V2 が、バイナリ埋め込みをサポートしました。通常の埋め込みでは、1,024（デフォルト）、512、256 次元のベクトルとして表現されます。バイナリ埋め込みでは、各次元を単一のバイナリ値（0 または 1）にエンコードされた Binary Vector としてデータを持ちます。これによりメモリやストレージといったリソースを削減できます。このアップデートは、Binary Vector をサポートした OpenSearch Serverless や Knowledge Bases と組み合わせた利用も可能です。 Amazon OpenSearch Serverless で point in time search をサポート Amazon OpenSearch Serverless で point in time search をサポートしました。特定の時点で固定されたデータセットに対して複数のクエリを実行できるようになりました。データが変更され続けている場合でも一貫した検索結果を維持することができ、深いページ切換えや複数のクエリにわたって、データの表示を保持するアプリケーションに特に有用です。 AWS Glue でエンタープライズアプリケーション向けに 19 のネイティブコネクタを追加 AWS Glue で、新たに 19 個のコネクタが追加されました。Facebook Ads、Google Ads、Google Analytics 4、Google Sheets、Hubspot、Instagram Ads、Intercom、Jira Cloud、Marketo、Oracle NetSuite、SAP OData、Salesforce Marketing Cloud、Salesforce Marketing Cloud Account Engagement、ServiceNow、Slack、Snapchat Ads、Stripe、Zendesk、Zoho CRM のコネクタが追加されました。 Amazon OpenSearch Service でディスク最適化ベクトルエンジンが利用可能に Amazon OpenSearch Service のバージョン 2.17 で、検索アプリケーションを 3 分の 1 のコストで実行できるようになる、ディスクモードを提供開始しました。バイナリ量子化などの技術を使用してインデックスが圧縮され、比較的少ないメモリの環境の動作に最適化されます。 11/20(水) Amazon CloudFront で VPC オリジンをサポート Amazon CloudFront は、VPC のプライベートサブネットでホストされているアプリケーションからコンテンツを配信できる新機能、Virtual Private Cloud (VPC) オリジンをサポートしました。お客様は ALB、NLB、EC2 インスタンスをプライベートサブネットに配置し、CloudFront ディストリビューションを通じてアクセスを提供できます。 ALB と NLB の Load Balancer Capacity Unit 予約機能をサポート ALB と NLB が、既存のトラフィックパターンに基づく自動スケーリング機能に加えて、ロードバランサーの最小容量を事前に設定できる Load Balancer Capacity Unit (LCU) 予約機能をサポートしました。突然の高トラフィックなスパイクが予想される際に、事前にそのスパイクに対応できるリソースを用意したい場合などにご利用いただけます。 Amazon ECS で平均復旧時間を短縮する AZ リバランシングをサポート Amazon ECS は、Fargate および EC2 環境において、AZ 間のリバランシング機能をサポートしました。これまで、AZ レベルの障害による影響を最小限に抑えるため、タスクは複数の AZ に分散して配置されていました。しかし、AZ の停止などのインフラストラクチャーイベントにより、AZ 間でタスクの配置バランスに偏りが出ている場合がありました。新しい AZ リバランシング機能により、タスクの配置を自動的に AZ 間で再分配することが可能となり、アプリケーションの高可用性をより維持できるようになりました。 Amazon RDS や Amazon Aurora で AWS Advanced NodeJS Driver が一般提供開始  RDS と Aurora の PostgreSQL、MySQL 互換のデータベースクラスターで、AWS Advanced NodeJS Driver が一般提供開始になりました。より高速なスイッチオーバーとフェイルオーバー、IAM 認証の提供、Federated Authentication 機能、といった特徴があります。 Amazon Aurora Serverless v2 がゼロキャパシティへのスケーリングをサポート Amazon Aurora Serverless v2 が、0 Aurora Capacity Units (ACUs) へのスケーリングをサポートするようになりました。この新機能により、データベース接続のアクティビティがない期間が続いた後、データベースが自動的に一時停止するようになり、コストの削減が可能です。 Amazon OpenSearch Serverless で SQL API をサポート Amazon OpenSearch Serverless で、REST API、Java Database Connectivity (JDBC)、およびコマンドラインインターフェース (CLI) を通じて、OpenSearch SQL と OpenSearch Piped Processing Language (PPL) を使用したデータのクエリが可能になりました。 Amazon CloudFront で gRPC 配信をサポート開始 Amazon CloudFront で gRPC アプリケーションの配信をサポートしました。gRPC で構築されたアプリケーションは、効率的な双方向ストリーミングや、 Protocol Buffers と呼ばれるバイナリメッセージフォーマットを使用でき、レイテンシーを改善できるメリットがあります。 Amazon RDS Blue/Green Deployments がストレージボリュームの縮小をサポート Amazon RDS Blue/Green Deployments で、RDS データベースインスタンスのストレージボリュームを縮小できるようになりました。RDS のインスタンスは直接ストレージの容量を縮小することはできないので、新規にストレージが小さい RDS インスタンスを作成してデータ移行を行うことがありました。これを、Blue/Green Deployment で実行できるようになり、作業負担を軽減できるメリットがあります。Amazon RDS for PostgreSQL メジャーバージョン 12 以上、RDS for MySQL メジャーバージョン 5.7 以上、Amazon RDS for MariaDB メジャーバージョン 10.4 以上で利用できます。 Amazon CloudFront がアクセスログの新しいログ形式と出力先をサポート CloudFront アクセスログを、新たに 2 つの出力先 (Amazon CloudWatch Logs と Amazon Data Firehose) に直接配信できるようになりました。また、JSON や Apache Parquet といったログ出力形式を選択できるようになりました。さらに、S3 に配信されるログの自動パーティション分割の有効化、特定のログフィールドの選択、ログに含まれるフィールドの順序設定が直接可能になりました。 AWS DMS で EC2 上で動かしているデータベースを RDS へ自動移行する機能をサポート Amazon RDS コンソールの 1-click move to managed 機能を使用することで、Amazon EC2 サーバー上で実行されているデータベースを、マネージド型の Amazon RDS または Aurora データベースに自動移行できるようになりました。 Amazon CloudFront が Anycast Static IP をサポート開始 Amazon CloudFront が Anycast Static IP をサポートし、世界中の CloudFront エッジロケーションへアクセスする際に、専用の静的な IP アドレスリストを利用できます。通常、CloudFront はトラフィックの処理に動的な IP アドレスを使用しますが、Anycast Static IP を利用することで、ワークロード用の専用の静的 IP アドレスリストを利用できます。Anycast Static IP を利用すると、 追加で $3000 の月額料金 が発生します。 11/21(木) Amazon ECS サービスの予測スケーリングのサポート Amazon ECS で予測スケーリングをサポートしました。高度な機械学習アルゴリズムを活用して Amazon ECS サービスを需要の急増に先立って事前にスケーリングすることで、過剰なプロビジョニングのコストを削減しながら、アプリケーションのパフォーマンスや可用性を向上できます。 Amazon API Gateway がプライベート REST API のカスタムドメイン名をサポート Amazon API Gateway で、private.example.com のような独自の DNS 名を使用して、プライベート REST API を設定できるようになりました。 Amazon Polly が新たに 7 個の generative voice をサポート Amazon Polly が新たに 7 個の generative voice をサポートしました。2 つの女性音声 (インド英語、イタリア語) と 5 つの新しい男性音声 (米国スペイン語、メキシコスペイン語、ヨーロッパスペイン語、ドイツ語、フランス語) が追加されました。 AWS Management Console のビジュアルアップデートをプレビュー AWS Management Console で見た目が新しくなるビジュアルアップデートのプレビューを開始しました。現在は一部のサービスで提供されており、今後すべてのサービスに拡張される予定です。 Amazon EC2 で G6e インスタンスが東京を含む追加のリージョンで利用可能 NVIDIA L40S Tensor Core GPU を搭載した Amazon EC2 G6e インスタンスが Asia Pacific (Tokyo) および Europe (Frankfurt, Spain) リージョンで利用可能になりました。G6e インスタンスは、幅広い機械学習および空間コンピューティングのユースケースに使用できます。 11/22(金) Amazon QuickSight で Highcharts ビジュアルのプレビュー開始 Amazon QuickSight は、Highcharts Core ライブラリを使用してカスタムビジュアライゼーションを作成できる Highcharts ビジュアルを提供開始しました。この新機能により、QuickSight の標準チャートで表現しきれないことが表現できるようになり、例えば、サンバーストチャート、ネットワークグラフ、3D チャートなど、独自のチャートを作成できるようになりました。詳細は、 こちらのブログ や Highcharts のデモサイト をご覧ください。Highcharts のサンプルがいくつか確認いただけます。 Amazon QuickSight でフォントカスタマイズが可能に Amazon QuickSight で、Analysis 全体に対する、フォントのカスタマイズが可能になりました。フォントサイズ、フォントファミリー、色、太字、斜体、下線などを設定できます。 Amazon QuickSight がイメージコンポーネントの提供開始 Amazon QuickSight がイメージコンポーネントの提供を開始しました。ダッシュボード、分析、レポート、ストーリーに画像をアップロードできるようになりました。企業ロゴやブランディング、背景画像などの用途で利用が可能です。 AWS Lambda で Node.js 22 をサポート AWS Lambda が Node.js 22 を使用したサーバーレスアプリケーションの作成をサポートしました。マネージド型ランタイム、コンテナベースイメージの両方で利用可能です。Node.js 22 は Node.js の最新の長期サポート (LTS) リリースであり、2027 年 4 月までセキュリティとバグ修正のサポートが提供される予定です。 Amazon Connect Email を提供開始 Amazon Connect Email を提供開始しました。Amazon Connect Email を使用すると、ビジネスアドレスに顧客から送信されたメール、またはウェブサイトやモバイルアプリのウェブフォームを通じて送信されたメールを受信し、応答することができます。 AWS Outposts における EC2 インスタンスストアを使用した静的安定性の提供 AWS Outposts は、EC2 インスタンスストアを使用した Amazon EC2 インスタンスの静的安定性を提供します。Outposts は通常、AWS リージョンに接続された状態で実行されますが、新しい静的安定性機能により、AWS リージョンへの接続が利用できない場合でも、EC2 インスタンスストアを使用する EC2 インスタンス上で実行されているワークロードは電源障害から復旧できます。 AWS Step Functions が変数とJSONata データ変換のサポート Step Functions で、変数と、JSONata データ変換の 2 つの新機能をサポートしました。変数機能により、開発者はとあるステートで変数にデータを割り当て、後続のステートでその変数を参照できます。JSONata は、JSON データのための軽量なクエリおよび変換を行う言語です。例えば、Step Functions の中で、ユーザーから入力されたメールアドレスを、正規表現を使って正しい形式か確認する Lambda 関数があるとします。これを JSONata のクエリーで実現でき、Lambda 関数を置き換えることが可能です。詳細は こちらのブログ をご参照ください。 Amazon Cognito でパスワードレス認証をサポート Amazon Cognito で、パスキー、メール、テキストメッセージを含むパスワードレス認証によってアプリケーションへのユーザーアクセスを保護できるようになりました。例えば、ユーザーがパスキーでログインを選択した場合、Apple MacBook の Touch ID や PC の Windows Hello 顔認証などの組み込み認証機能を使用してログインできます。 クロスゾーン有効化をした Application Load Balancer が zonal shift と zonal autoshift をサポート クロスゾーン有効化をした ALB が、zonal shift と zonal autoshift をサポートしました。クロスゾーン有効化は、複数の AZ を利用している環境で一般的な設定です。この機能のアップデートにより、お客様はクロスゾーンが無効化されたロードバランサーと同様に、障害が発生した際、AZ からトラフィックを移動できるようになりました。 Amazon Cognito がリッチなブランディングをサポートする Managed Login を提供開始 Amazon Cognito が Managed Login を提供開始しました。いままで提供されていた Hosted UI の改良版となり、サインアップやサインインのための新しい Web 画面、多要素認証、レスポンシブデザインなどに加えて、Managed Login の画面を外観をカスタマイズできるブランディングデザイナーが提供されています。また、日本語のローカライズも提供されており、日本のお客様に便利にご利用いただけます。また、料金の Tier として、Lite、Essentials、Plus と分けられ、利用する機能に合わせて最適な Tier を選択できるようになりました。詳細は こちらのブログ や ドキュメント をご参照ください。 Amazon EC2 Auto Scaling が高応答性のスケーリングポリシーを導入 EC2 の Auto Scaling の Target Tracking Policy で、1 分未満の間隔で公開されている、秒レベルのデータポイントを持つ高解像度 Cloud Watch メトリクスをサポートしました。最小 10 秒の間隔でメトリクスをモニタリングするように設定でき、従来と比べてより素早いスケーリングが可能になります。バージニア、オレゴン、シンガポールアイルランドリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

AWS re:Invent 2024 が間近に迫っています。 Amazon Connect チームは 12月2日から6日までラスベガスで世界中のお客様をお迎えできることを楽しみにしています。AWS や他のお客様からの話を聞いたり、刺激的なブレイクアウトセッション、チョークトーク、ビルダーズセッション、ワークショップに参加して実践的な学びを得ることができます。コンタクトセンターとカスタマーエクスペリエンス戦略をどのように変革できるかの参考にしていただくため、 アジェンダを作成するためのガイド をご用意しました。 re:Invent 基調講演 での発表に加えて、お薦めしたいセッションをご紹介します： BIZ221-INT | Innovation Talk | Generative AI for customer service (カスタマーサービスのための生成 AI) 12月2日 (月) | 10:30 AM – 11:30 AM PST (最新の日時情報は ライブカタログ を参照) 生成 AI は顧客とのやり取りに革命をもたらし、自動化、コスト効率、応答性の新時代の到来を告げると期待されています。しかし、この変革を実現するには、人、プロセス、テクノロジーを調和させる総合的なアプローチが必要です。お客様の成功事例と AWS の最新イノベーションのデモを通じて、Amazon Connect の Vice President である Pasquale DeMaio から、カスタマーサービスにおける生成 AI の運用に関する洞察をお話します。これから始める場合でも、すでに着手している場合でも、このトークを通じて顧客とのやり取りやエージェントエクスペリエンスなどに AI の変革力を活用するための知識とツールをご紹介します。 スピーカー： Pasquale DeMaio , Vice President & General Manager of Amazon Connect, AWS BIZ213 | Breakout Session | How Amazon.com powers customer-obsessed service with Amazon Connect (Amazon.com が Amazon Connect で顧客志向のサービスを実現する方法) 12月4日 (水) | 2:30 PM – 3:30 PM PST (最新の日時情報は ライブカタログ を参照) Amazon.comでは、顧客第一主義を貫くことがカスタマーサービスのあらゆるやり取りを通じて信頼を得るための鍵となります。このセッションでは、Amazon Connect の最大の世界規模の顧客であるAmazon カスタマーサービスが、Amazon Connect を使用して顧客とのやり取りを年間数十億件にまで拡大し、便利でパーソナライズされた顧客体験をどのように提供しているかを学びます。世界中の複雑な顧客サポートニーズに包括的に対応するカスタマーサービスを強化するために、Amazon がどのように生成 AI に投資しているかを聞くことができます。 スピーカー： John Chao , Director, Customer Engagement, Amazon.com Customer Service Jeff Christenson , Sr Manager, Customer Engagement, Amazon.com Customer Service Lauren Dickerson , Manager, Worldwide Specialist for Amazon Connect, AWS BIZ218 | Breakout Session | How Frontdoor, Inc. boosts agent productivity with Amazon Connect (Frontdoor, Inc. が Amazon Connect でエージェントの生産性を向上させる方法) 12月3日 (火) | 4:00 PM – 5:00 PM PST (最新の日時情報は ライブカタログ を参照) コンタクトセンターのエージェントはカスタマーサービスの提供に欠かせない存在です。AWS と米国最大の住宅保証プロバイダーである Frontdoor, Inc. から、Amazon Connect の統合された生成 AI 搭載ワークスペースを使用してエージェントを強化し、生産性を向上させる方法についてお話します。このワークスペースは、エージェントが顧客にパーソナライズされたサービスを提供するために必要な機能を提供します。複雑な顧客の問い合わせに対するエージェントの対応を改善し、どんなエージェントでも最高のエージェントにする方法について、新しいアイデアを得ることができます。 スピーカー： Scott Brown , SVP Customer Experience, Frontdoor Trevor Bloking , Sr Manager, Product Management for Amazon Connect, AWS 全てのセッションリストについては、re:Invent の カスタマーエクスペリエンスガイド をダウンロードしてください。 カスタマーエクスペリエンスレセプションにご参加ください 12月3日 (火) に The Bellagio の Mayfair Supper Club で開催されるカスタマーエクスペリエンスレセプションにご参加いただくと、AWS のコンタクトセンターエキスパートや他のお客様と交流する機会が得られます。一日の終わりにお立ち寄りいただき、美味しい軽食、楽しいカクテル、ライブエンターテイメント、そして CX を中心とした魅力的なディスカッションをお楽しみください。 ご登録はまだ間に合います！re:Invent 2024 でお会いできるのを楽しみにしています。 翻訳は Amazon Connect スペシャリストソリューションアーキテクト清水が担当しました。原文は こちら です。

高エネルギー加速器研究機構（以下、KEK）は、クライオ電子顕微鏡(Cryo-EM)の単粒子解析法に関わるコンピューティング環境の最適化の研究をAWSを利用して実施されています。今回この取り組みが英国科学誌 Nature の姉妹紙である Communications Biology に論文として掲載されました。これに関連する KEK プレスリリースは こちら となります。KEK と AWS は研究DX加速のため連携強化を 2022年に発表 しており、今回の論文掲載はその成果の一つとなります。この論文では、GoToCloud の全体アーキテクチャだけでなく、単粒子解析の各ステップでのCPUおよびGPU搭載インスタンスでの性能評価や、セキュリティ上の考慮点についても述べられており、GoToCloud の利用者だけでなくクラウド上で同様の解析を行う方々にとって参考になる内容です。 Cryo-EM は、膜タンパク質を含む多くの創薬のターゲットとなる物質（タンパク質などの生体高分子）の3D構造を原子分解能で可視化するために広く用いられている手法です。しかしながら構造ベースの創薬(SBDD：Structure-Based Drug Design)に必要なスループットが達成されておらず、検出器の技術や画像取得方法の急速な進歩により、データ解析が大きなボトルネックとなっていました。KEK は Cryo-EM における高度なデータ解析と管理のためにクラウドコンピューティングベースのプラットフォームである「GoToCloud」プロジェクトを実施しています。各処理ステップごとに最適な並列計算を選択することで、コンピューティングリソースを最適化し、スループットを高めつつ、コストの最適化を行うことができます。GoToCloud では、インスタンスの選択などを含めた並列処理設定や必要な目標分解能が、処理時間とコストパフォーマンスに大きな影響を与えることが実証されています。Cryo-EM SBDD を加速する有望なプラットフォームの1つとして GoToCloud の利用があげられます。 KEK の GoToCloud 環境では、AWS ParallelCluster を利用しています。この AWS ParallelCluster はハイパフォーマンスコンピューティング(HPC)のクラスタ環境を構築、構成、管理ができるもので、必要に応じてコンピューティングリソースを増減させて効率的に使うことが可能です。この GoToCloud 環境では、AWS上で複雑な処理環境の構築とセットアップの手順を自動化し3つの手順にまで簡略化しています。Cryo-EM 単粒子解析用のソフトウェアの実行を、各ステップごとに最適なインスタンス(主に GPU 搭載の有無)で行うため、RELION（Cryo-EM 構造解析のためのソフトウェアパッケージ） の実行ファイルを複数種類用意して利用しています。これまで解析環境の準備や運用に課題があり個別の解析環境を持つことが出来なかったユーザにとって、この GoToCloud 環境を使うことで、データ処理ソフトウェアの保守や最適化など技術的な面を気にすることなく、データ解析作業に集中できるようになります。Cryo-EM 施設側でセットアップした環境を個別のユーザが利用、各ユーザ自身のAWSアカウントに GoToCloud 環境を構築して利用のどちらの形も可能となっており、既に製薬企業や他の研究機関でもご活用いただいております。 図 GoToCloud 構成図(KEK公開事例より) KEK は継続して各ステップごとに最適なインスタンスタイプの割り出しやスポットインスタンスを利用したトータルコスト削減、処理時間の削減に取り組んでいます。またクラウドサービスを有効的に活用することで、GoToCloud において Cryo-EM 単粒子解析をサポートするより高度なシステムへの拡張を目指しています。複数の Cryo-EM 施設をインターネットを介してクラウドに接続する IoT化や、機械学習などを用いたアルゴリズムの開発など高度な自動化を進めていく予定です。このように AWS を利用していただくことで、解析環境を柔軟に構築、利用ができ、コスト最適化をしながら、AWS の様々なサービスと組み合わせていただくことで、システムの機能拡張の取り組みをさらに加速していただくことが可能となります。 アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 パブリックセクター統括本部長 宇佐見 潮は、次のように述べています。「AWS は、これまでにも高エネルギー加速器研究機構とは HPC（ハイパフォーマンスコンピューティング）分野において深く連携を図ってきました。今回の「GoToCloud」プロジェクトは飽くなき探求心が生んだ成果だと考えております。クラウドコンピューティングの可能性を最大限に生かし、研究開発の新たな地平を切り開く取り組みを支援できることを大変光栄に思います。AWS はその架け橋となることで、日本の研究分野における無限の可能性に貢献していきます。」 ■ KEKプレスリリース : 　 「クラウドコンピューティング環境の活用で加速する タンパク質立体構造に基づく新しい創薬デザイン！ ～「GoToCloud プラットフォーム」の開発～」 ・ 高エネルギー加速器研究機構について 高エネルギー加速器研究機構 (KEK) は、電子や陽子などを加速する粒子加速器と呼ばれる装置を使う加速器科学の世界的拠点の一つです。国内外の研究者と共同研究を行うとともに、共同利用の場を提供する大学共同利用機関法人として、素粒子、原子核の謎の探究や物質、生命現象の理解に取り組んでいます。ノーベル賞との関わりも深く、ここで行われた実験による成果で、物理学賞と化学賞が生まれています。前身の旧文部省高エネルギー物理学研究所は 1971 年に創設され、現在、茨城県つくば市と東海村に拠点を持っています。詳細については以下の URL をご覧ください。 https://www.kek.jp/ ・クライオ電子顕微鏡 (Cryo-EM)について 精製したタンパク質などの生体高分子を溶かした液体を急速に凍らせ、液体窒素で-200℃ぐらいの低温に保ったまま、透過型電子顕微鏡（TEM）を用いて撮影した 2D 画像から、コンピューターによる画像処理で生体高分子の立体構造を決定します（この技術を開発した 3 名は 2017 年、ノーベル化学賞を共同受賞しています）。タンパク質は、電子顕微鏡内部の高真空にさらされると干からびて形が変わってしまいますが、薄い氷の中に閉じ込めて保護・固定して観察します。歴史の長いX線によるタンパク質の構造解析では、良質な結晶が必須で作成する負担が大きいですが、Cryo-EM ではその必要がないため、結晶化が困難な巨大なタンパク質やその複合体の構造解析に力を発揮しています。ただ氷の中のタンパク質の向きはまちまちであるため、別々に撮影した膨大な数の 2D 画像からそれぞれのタンパク質粒子像の三次元的な撮影方向を推定することでうまく重ね合わせて立体構造を再現する複雑な計算をしなければなりません。そのため、膨大な計算資源が必要になります。 【日本の高等教育機関および研究機関向け お問合せ窓口】 AWSのご相談全般に関しては「aws-jpps-er@amazon.com」までご連絡ください。。 ＊ ＊ ＊ ＊ 本記事は、パブリックセクターシニアソリューションアーキテクト櫻田が執筆しました。

本稿は、2024 年 6 月 14 日に公開された “ Improve your industrial operations with cloud-based SCADA systems ” を翻訳したものです。 導入 現代の産業現場では、毎分数千から数百万のデータポイントが生成されるのが一般的です。産業分野やエネルギー分野で IIoT (Industrial Internet of Things) の利用が増加するにつれ、生成されるデータ量はさらに増加すると予想されています。 エネルギーおよび公共事業分野では、SCADA (監視制御およびデータ収集) システムが、地理的に広く分散したシステムを中央拠点からほぼリアルタイムで監視するのに有用です。産業用制御システムやその他の運用技術 (ICS/OT) は現場に設置され、データ通信ネットワークを介して SCADA システムに接続されています。SCADA は効率性と生産性を向上させ、コストと無駄を削減し、分散したシステムに対するより広範な制御を提供します。 SCADA システムは重要な運用をほぼリアルタイムで行うため、24 時間 365 日利用可能で稼働していることが期待されます。従来、SCADA システムはオンプレミスシステムとして設計され、外部ネットワークとの接続なしに産業およびエネルギープロセスを安全かつ確実に運用するためのものでした。しかし、ビジネスの俊敏性を高め、運用を改善し、コストを削減するために、SCADA などの OT システムはビジネスネットワークやクラウドインフラストラクチャにより統合されるようになってきています。 クラウドベースの SCADA システムには、高価なサーバーハードウェアやソフトウェアをオンプレミスで設置・維持する必要性を減らし、産業データをいつでもどこでも利用可能にするなど、いくつかの利点があります。クラウドベースの SCADA システムは、IIoT やインダストリー 4.0 において、プロセスや運用を改善するために必要な自動化、データ収集、分析、アナリティクス、機械学習、接続性を提供するため、ますます重要になっています。クラウドベースの SCADA システムにより、顧客はデータにより簡単にアクセスでき、クラウドサービスを使用して大規模にデータを管理・分析することができます。 クラウドベースの SCADA システムは多くの利点を提供する一方で、外部ネットワークやクラウドサービスへの依存度が高まることによる可用性、安全性、セキュリティ、およびパフォーマンスに関する新たな課題も生じます。このブログでは、クラウドベースの SCADA システムの一般的なユースケースとアーキテクチャ、そして Amazon Web Services (AWS) 上でのクラウドベース SCADA システムのベストプラクティスについて議論します。 エネルギーおよび公共事業分野では、クラウドベースの SCADA システムが特に注目されています。これは、エネルギーおよび公共事業の運用が地理的に分散しており、時には遠隔地に位置しているためです。これらの産業の事業者は、自社のサイトを全体的に把握する必要がありますが、通常、遠隔地に SCADA システムを運用するための専門の OT チームは配置されていません。クラウドベースの SCADA システムを導入することで、中央拠点にいる少人数のチームで大規模かつ分散した運用を行うことが可能になります。   クラウドベースの SCADA システムのためのアーキテクチャーパターン 1. クラウドデータ統合と複合サイトビュー クラウドベース SCADA システムの導入を始める最適な方法の一つは、クラウド上でのマルチサイトデータの可視化と分析です。このシナリオでは、各サイトで主要な SCADA システムをオンプレミスで運用し続けながら、クラウドを使用して複数サイトにわたるデータの統合、民主化、分析、可視化を行います。このアプローチにより、クラウドサービスやアプリケーションとの統合が容易になり、通常オンプレミスでは利用できない他のユースケースを安全かつスケーラブルな方法で実現することができます。このプロセスは「オープンループ」操作と呼ばれることが多く、オンプレミスの SCADA からクラウドへの一方向の通信が行われます。多くの場合、エッジゲートウェイを介して行われ、クラウドから産業用オートメーションおよび制御システム (IACS) へコマンドを送り返すことはありません。すべての制御機能はローカルのオンプレミス SCADA システムによって実行されます。(以下の図 1 を参照) 図 1. クラウドデータの統合と複数サイトビューのアーキテクチャ このソリューションでは、エッジで AWS サービスを使用します。例えば、 AWS IoT SiteWise Edge (オンプレミスで産業機器データを収集、処理、監視するためのサービス) や、 CirrusLink MQTT module などのサードパーティソリューションを利用して、データを AWS IoT Core (デバイスをクラウドに簡単かつ安全に接続するサービス) や AWS IoT SiteWise (産業機器データを大規模に収集、保存、整理、監視するマネージドサービス) に送信します。データが取り込まれると、 AWS IoT Rules Engine (デバイスが AWS サービスと対話する能力を提供) を使用して、ペイロードを他の AWS サービスにルーティングし、データレイクに保存できます。最終的に、ユーザーは他の AWS サービスを組み込んで、ダッシュボードの作成、機械学習 (ML) モデルの実行、監視と可観測性の提供を行うことができます。 2. AWS 上のIgnition® by Inductive Automation SCADA Ignition は Inductive Automation が提供する SCADA システム向けの統合ソフトウェアプラットフォームです。 Inductive Automation パートナーソリューション は、AWS パートナーである Inductive Automation のソリューションである Ignition を AWS クラウドにデプロイします。このパートナーソリューションは、SCADA アプリケーションの可用性、パフォーマンス、可観測性、および回復力を向上させます。Amazon EC2 Linux インスタンス上で Ignition のスタンドアロンおよびクラスターデプロイメントオプションを提供します。両オプションとも、セキュリティ、ネットワークゲートウェイ接続、データベース接続のベストプラクティスに基づいて設計され、安全で高可用性を備えています。 このデプロイメントアプローチでは、AWS が基盤となるインフラストラクチャを管理し、顧客がローカル環境と AWS クラウド環境の両方で SCADA システムとアプリケーションを構築、運用、保護、維持するための安全で信頼性の高いプラットフォームを提供します。顧客は Inductive Automation の永続ライセンスを使用でき、消費した AWS サービスに対してのみ支払いを行います。 これは、Ignition を実行するために必要な AWS リソース (データベース、ネットワーキング、 Amazon EC2 インスタンスなど) のセットアップ、設定、管理が、利用者の責任であることを意味します。Amazon EC2 は、クラウド内の安全で拡張性の高いコンピューティング能力を提供し、事実上あらゆるワークロードに対応します。パートナーソリューションはより多くの制御と柔軟性を提供しますが、より多くの IT 専門知識も必要とします。 スタンドアロンデプロイメントは少数のクライアントに適していますが、クラスターアーキテクチャは Application Load Balancer (高度なリクエストルーティングを備えた HTTP および HTTPS トラフィックのロードバランサー) を含み、バックエンドとフロントエンドのゲートウェイを分離することで、パフォーマンスを向上させる層を追加し、クライアントトラフィックをより効率的に管理できます。 スタンドアロンアーキテクチャでは、パートナーソリューションは以下のコンポーネントをデプロイします (以下の図 2 を参照)： 2 つのアベイラビリティーゾーンにまたがる高可用性アーキテクチャ AWS の セキュリティベストプラクティス に従って、パブリックサブネットとプライベートサブネットで構成された仮想プライベートクラウド (VPC) AWS およびオンプレミスのリソースとアプリケーションを監視・観察するための Amazon CloudWatch 、および CloudWatch アラームがトリガーされたときに通知するための完全マネージドメッセージングサービスである Amazon Simple Notification Service (Amazon SNS) パブリックサブネットには以下が配置されます： プライベートサブネット内のリソースがアウトバウンドインターネットアクセスを可能にするマネージドネットワークアドレス変換 (NAT) ゲートウェイ プライベートサブネット内の Amazon EC2 インスタンスとクラウド向けに構築されたリレーショナルデータベース管理システム (RDBMS) であるAmazon Aurora へのセキュアシェルアクセス (SSH) を可能にする Linux 踏み台サーバー  2 つの別々のアベイラビリティーゾーンにある一次および二次 Ignition ゲートウェイ プライベートサブネットには以下が配置されます： 書き込み操作をサポートするプライマリ Amazon Aurora データベース 読み取り操作をサポートするレプリカデータベース 図 2. Ignition のスタンドアロンデプロイメントアーキテクチャ クラスターアーキテクチャでは、パートナーソリューションは同様のコンポーネントをデプロイしますが、バックエンドとフロントエンドのゲートウェイを分離してクライアントワークロードをフロントエンドサーバーに振り分けることで、Ignition ゲートウェイのパフォーマンスを向上させます。これをサポートするために、クラスターデプロイメントでは Amazon SSL 証明書 で構成された Application Load Balancer も作成され、プライベートサブネット内の Ignition のフロントエンドサーバーにトラフィックをルーティングします。(図 3 を参照) 図 3. Ignitionのクラスターデプロイメントアーキテクチャ Ignition のデプロイメントガイドの詳細については、Ignition の デプロイメントガイド を参照してください。 3. AWS Outposts 上のIgnition Inductive Automation の Ignition® は、 AWS Outposts 上にデプロイすることができます。AWS Outposts は、ローカルデバイスと SCADA システム間で超低レイテンシーと高帯域幅を必要とする顧客向けに、AWS インフラストラクチャとサービスを事実上あらゆるオンプレミスまたはエッジロケーションに提供する、完全管理型ソリューションのファミリーです。AWS Outposts 上の Ignition を使用することで、顧客はネイティブ AWS API を持つ完全管理型インフラストラクチャの利点を得ることができます。AWS Outposts を使用しない顧客は、SCADA ソリューションを実行するためのハードウェアとソフトウェアスタックを調達、管理、サポート、セキュア化、維持する必要があります。 AWS Outposts は、オンプレミス環境と AWS クラウドを橋渡ししたい組織にとって価値ある解決策を提供し、クラウドコンピューティングの利点を活用しながら、ローカルリソースへの制御と低レイテンシーアクセスを維持することを支援します。特に、オンプレミスとクラウドベースのリソースの組み合わせが必要なハイブリッドクラウドシナリオで有用です。 AWS Outposts は、コンピューティング、ストレージ、ネットワーキングコンポーネントを含む AWS インフラストラクチャハードウェアで構成され、物理的にお客様のサイトに配置されます。AWS Outposts は、専用の高速接続を通じて最寄りの AWS リージョン に接続されます。この接続は、AWS への専用ネットワーク接続を作成するために使用される AWS Direct Connect か、オンプレミスネットワークとリモートワーカーをクラウドに接続するために使用される AWS Virtual Private Network (AWS VPN) を使用して確立されます。どちらのサービスを使用するかは、要件とネットワーク設定によって異なります： AWS Direct Connect は、AWS Outposts と AWS リージョン間の専用かつプライベートなネットワーク接続を提供します。低レイテンシー、高スループットの接続を提供し、AWS サービスへの一貫性のある信頼性の高いアクセスが必要なシナリオに適しています。  AWS VPN は、パブリックインターネット経由で安全な VPN 接続を確立するのに役立ちます。AWS Outposts と AWS リージョン間の暗号化された通信を提供します。AWS Direct Connect と比較してわずかに高いレイテンシーがある可能性がありますが、より柔軟でコスト効率の高いオプションです。 AWS Outposts 上の Ignition には、多くのアーキテクチャオプションが利用可能です： 標準アーキテクチャ 冗長性を備えた標準アーキテクチャ スケールアウトアーキテクチャ 冗長性を備えたスケールアウトアーキテクチャ Ignition の最も一般的なアーキテクチャは、総所有コストに最適化された、管理が容易なリレーショナル・データベース・サービスである Amazon Relational Database Service (AmazonRDS） に接続された単一のオンプレミス Ignition サーバー、PLC、クライアントで構成されます。 別の一般的な Ignition アーキテクチャは、SQL データベース (Amazon RDS)、PLC、およびクライアントに接続された単一のオンプレミス Ignition サーバー (冗長サーバーを含む) で構成されています。 スケールアウトアーキテクチャは、複数の Ignition ゲートウェイをリンクして分散型システムを形成します。Ignition の入出力 (I/O) をフロントエンドから簡単に分離し、それぞれを独立して拡張することができます。 冗長性を備えたスケールアウト・アーキテクチャーは、複数の Ignition ゲートウェイ (冗長サーバー付き) をリンクして分散型システムを形成します。Ignition の I/O とフロントエンドを簡単に分離し、それぞれを独立して拡張することができます。 AWS Outposts 上の Ignition は、組織が AWS インフラストラクチャとサービスをオンプレミスで使用しながら、環境を AWS クラウドに安全に接続し、データ分析、予知保全、機械学習の分野への旅を始めるのに役立ちます。(図 4 を参照) 図 4. AWS Outposts と AWS IoT Service を利用したオンプレミス Ignition との統合 4. Ignition Cloud Edition Ignition Cloud Edition は、AWS 上でホストされる Ignition プラットフォームのクラウド版です。Ignition Cloud Edition では、ソフトウェアが AWS 上でホストされ、ユーザーは基盤となるインフラストラクチャを管理する必要なしにアクセスできます。これにより、ユーザーの運用負担が軽減され、代わりに Ignition プラットフォームの設定と使用に集中できます。Ignition Cloud Edition では、ユーザーはソフトウェアの設定、バックアップ、アップグレードを担当します。 Ignition Cloud Edition は従量制モデルを提供し、すでにインストールされライセンスされたモジュールのバンドルが付属しています。各モジュールの使用料を支払う代わりに、Ignition Cloud Edition の使用量に応じて支払います。産業機器接続用のドライバーは含まれていませんが、Ignition Cloud Edition には MQTT と Gateway Network 機能が含まれており、標準の Ignition または Ignition Edge インストールとの接続が可能です。そのため、オンプレミスデータを簡単にクラウドに拡張し、様々なクラウドサービスと接続できます。 Ignition Cloud Edition には、Ignition Core モジュール (Perspective、Reporting、SQL Bridge、OPC UA、Enterprise Administration Module (EAM)、Tag Historian、Alarm Notification) が付属しています。また、Web Development、Twilio Notification、Voice Notification モジュール、および Cirrus Link Solutions の MQTT Engine、MQTT Distributor、MQTT Transmission モジュールも含まれています。MongoDB Module というクラウドコネクターモジュールも含まれており、Ignition Cloud Edition ユーザーは新しいクラウドコネクターモジュールが利用可能になると入手できます。 Ignition Cloud Edition を使用することで、顧客は高価なサーバーを購入・管理する必要がなく、ストレージ、機械学習、分析などのクラウドサービスをより簡単に利用できます。 クラウドベース SCADA の課題、セキュリティ上の考慮事項、および推奨事項 クラウドベース SCADA の採用は、集中データ管理の改善、資本および運用・保守費用の削減、セキュリティの向上をもたらす可能性がありますが、クラウドで SCADA を実装することには固有のリスクがあります。顧客はここで説明する新たなリスクをいくつか考慮する必要があります。 クラウドベース SCADA は、ネットワーク接続とクラウドサービスの可用性とパフォーマンスなどのリスクをもたらします。インターネットに依存する場合は、ネットワークの遅延を考慮する必要があります。 クラウドベースの SCADA システムは外部ネットワークとクラウドサービスとの依存を生じさせることもあり、リスクを最小限に抑え、軽減するには、慎重な検証が必要です。さらに、一部の産業およびエネルギー用途には適していますが、すべてに適しているわけではなく、リスク評価、適切なソリューション設計、構成、継続的な監視が必要です。 クラウドベース SCADA システムのセキュリティ推奨事項 サイバーセキュリティリスク評価 ：リスク、ギャップ、脆弱性を完全に理解し、積極的に管理できるようにするため、サイバーセキュリティリスク評価を実施します。 ネットワークセグメンテーション ：産業用非武装地帯 (IDMZ) を確立し、ファイアウォールと一方向ゲートウェイを使用してゾーン間のトラフィックを制御します。 クラウドへの安全なネットワーク接続 ：ネットワークトラフィックをプライベートかつ暗号化して保持します。パブリックインターネットを使用する場合、トラフィックは暗号化する必要があります。 OT およびクラウド運用の可視性と監視 ：OT、IIoT、クラウド全体にセキュリティ監査および監視メカニズムを展開し、セキュリティアラートを中央で管理します。 多層防御 (DiD) 戦略 ：セキュリティポリシー、認証と認可、ファイアウォール制御、パッチ管理、マイクロネットワークセグメンテーション、冗長通信ネットワーク、グレースフルデグラデーション、バックアップと復旧手順などの DiD アプローチを適用します。 SCADA ベンダーの推奨事項 ： Ignition Security Hardening Guide など、SCADA ベンダーのセキュリティガイダンスに従います。 セキュリティ標準 ： ISA/IEC 62443 などの IACS セキュリティ標準に従います。これらの標準は、 IIoT とクラウドサービス の使用をサポートするように進化しており、一般的な IT システムのセキュリティに関する確立された標準 (例： ISO/IEC 27000 シリーズ ) に基づいています。 グローバル OT/IT ネットワークの保護 ：複数のリモートサイトを複数のエッジ構成でクラウドに接続する際は、 この AWS ガイダンス に従います。 加えて、 IIoT ソリューションのための 10 のセキュリティゴールデンルール で説明されている AWS の多層セキュリティアプローチと、 製造 OT のための AWS セキュリティベストプラクティス に従ってください。 結論 このブログでは、AWS におけるクラウドベース SCADA システムの複数の設計考慮事項と使用方法を紹介しました。現代の産業システムが進化し、より大量のデータを生成し、自動化レベルが向上するにつれて、産業界はクラウド SCADA が提供する最新の SCADA アプローチから恩恵を受けることができます。可用性、レイテンシー、パフォーマンス、セキュリティ要件に対応するクラウドベース SCADA ソリューションを設計し、ネットワークのダウンタイムや障害に備えたバックアッププランと緊急措置を用意してください。AWS は、クラウドベース SCADA のための幅広いサービス、ガイダンス、ソリューションを提供しており、クラウドコンピューティングの利点を享受しながら、ニーズに最適なソリューションを選択することができます。 エネルギーおよび公共事業分野におけるクラウドベース SCADA システムの使用は、運用効率の向上、ほぼリアルタイムの監視、シームレスな統合をもたらします。その拡張性は変化する需要に適応し、リソースを最適化してダウンタイムを最小限に抑えます。強化されたサイバーセキュリティは重要インフラの保護を改善します。クラウドベース SCADA の採用は、業界のダイナミックで相互接続された環境を乗り切るために不可欠です。 本稿は、ソリューションアーキテクトの林 隆太郎が翻訳しました。原文は “ Improve your industrial operations with cloud-based SCADA systems ” を参照してください。 Ryan Dsouza Ryan Dsouza は、AWSのプリンシパル産業用 IoT (IIoT) セキュリティソリューションアーキテクトです。ニューヨーク市を拠点とし、顧客が AWS の幅広い機能を活用して、より安全で拡張性が高く革新的な IIoT ソリューションを設計、開発、運用し、測定可能なビジネス成果を達成できるよう支援しています。Ryan は、デジタルプラットフォーム、スマート製造、エネルギー管理、ビルおよび産業オートメーション、OT/IIoT セキュリティなど、多様な産業分野で 25 年以上の経験を持っています。すべての接続デバイスにセキュリティをもたらし、すべての人にとってより良く、より安全で、より回復力のある世界を構築するチャンピオンになることに情熱を注いでいます。AWS に入社する前は、Accenture、SIEMENS、General Electric、IBM、AECOM で働き、顧客のデジタルトランスフォーメーションに貢献していました。 Oscar Salcedo Oscar Salcedo は、AWS の IoT およびロボティクス専門ソリューションアーキテクトです。スマート製造、産業オートメーション、ビルオートメーション、および多様な産業における IT/OT システムで 20 年以上の経験を持っています。AWS の深さと幅広さを活用して、スケーラブルで革新的なソリューションを設計・開発し、顧客に測定可能なビジネス成果をもたらしています。

11 月 21日、 AWS CloudTrail Lake の新しいアップデートを発表できたことを嬉しく思います。AWS CloudTrail Lake は、監査、セキュリティ調査、運用上のトラブルシューティングのために、 AWS CloudTrail で記録されたイベントの集約、不変の保存、クエリに使用できるマネージド型データレイクです。 CloudTrail Lake の新しいアップデートは以下のとおりです。 CloudTrail イベントのフィルタリングオプションの強化 イベントデータストアのクロスアカウント共有 生成 AI 自然言語クエリ生成の一般的利用可能性 AI を活用したクエリ結果の要約機能のプレビュー AI を活用したインサイトを含む高レベルの概要ダッシュボード (AI を活用したインサイトはプレビュー中)、さまざまなユースケースに対応する 14 種類の事前作成済みダッシュボード、定期的な更新を伴うカスタムダッシュボードの作成機能など、包括的なダッシュボード機能 新機能を1つずつ見ていきましょう。 イベントデータストアに取り込まれた CloudTrail イベントのフィルタリングオプションが強化されました イベントフィルタリング機能の強化により、どの CloudTrail イベントがイベントデータストアに取り込まれるかをより細かく制御できるようになりました。これらの強化されたフィルタリングオプションにより、AWS アクティビティデータをより厳密に制御できるようになり、セキュリティ、コンプライアンス、運用調査の効率と精度が向上します。さらに、新しいフィルタリングオプションを使用すると、最も関連性の高いイベントデータのみを CloudTrail Lake イベントデータストアに取り込むことができるため、分析ワークフローのコストを削減できます。 eventSource 、 eventType 、 eventName 、 userIdentity.arn 、 sessionCredentialFromConsole などの属性に基づいて、管理イベントとデータイベントの両方をフィルタリングできます。 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake の下の [ イベントデータストア ] を選択します。[ イベントデータストアの作成 ] を選択します。最初のステップでは、[ イベントデータストア名 ] フィールドに名前を入力します。このデモでは、他のフィールドはデフォルトのままにします。ニーズに合った価格設定とリテンションオプションを選択できます。次のステップでは、 CloudTrail イベントの下の [ 管理イベント ] と [ データイベント ] を選択します。必要なすべてのオプションを CloudTrail イベント に含めることができます。また、取り込みオプションを選択することもできます。 Ingest イベント を選択すると、作成時にインジェストが開始されます。イベントデータストアがイベントを取り込むのを停止するために、 Ingest イベント オプションの選択を解除したい場合があります。たとえば、トレイルイベントをイベントデータストアにコピーしていて、イベントデータストアに今後のイベントを収集させたくない場合があります。組織内のすべてのアカウントで統合を有効にするか、イベントデータストアに現在のリージョンのみを含めるかを選択することもできます。 次の例は、AWS サービスによって開始された管理イベントを除外する、すぐに使えるフィルタリング用のテンプレートを示しています。 管理イベント の下で [ 高度なイベントコレクション ] を選択します。[ ログセレクターテンプレート ] ドロップダウンから [ AWS サービス開始イベントを除外 ] を選択します。 JSON ビュー を展開して、フィルターが実際にどのように適用されるかを確認することもできます。 次の例では、 データイベント の下に、特定のユーザーによって開始された DynamoDB データイベントを含めるフィルターを作成しています。これにより、IAM プリンシパルに基づいてイベントをログに記録できます。 リソースタイプ として DynamoDB を選択しました。 ログセレクターテンプレート として [ カスタム ] を選択します。 アドバンストイベントセレクター で、 フィールド として userIdentity.arn を選択し、 オペレーター として [ 同等 ] を選択します。 ユーザーの ARN を 値 として入力します。最後のステップで [ 次へ ] を選択し、[ イベントデータストアの作成 ] を選択します。 これで、取り込まれた CloudTrail データをきめ細かく制御できるイベントデータストアができました。 このフィルタリングオプションの拡張セットにより、セキュリティ、コンプライアンス、および運用上のニーズに最も関連性の高いイベントのみをより選択的にキャプチャできるようになります。 イベントデータストアのクロスアカウント共有 イベントデータストアのクロスアカウント共有機能を使用して、組織内の共同分析を強化できます。リソースベースポリシー (RBP) を通じて、選択した AWS プリンシパルとイベントデータストアを安全に共有できます。この機能により、権限のあるエンティティは、作成されたのと同じ AWS リージョン内の共有イベントデータストアにクエリを実行できます。 この機能を使用するには、 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake の下の [ イベントデータストア ] を選択します。リストからイベントデータストアを選択し、その詳細ページに移動します。[ リソースポリシー ] セクションで [ 編集 ] を選択します。次のポリシー例には、アカウント 111111111111、222222222222、333333333333 のルートユーザーが、アカウント ID 999999999999 が所有するイベントデータストアでクエリを実行し、クエリ結果を取得することを許可するステートメントが含まれています。[ 変更を保存 ] を選択してポリシーを保存します。 CloudTrail Lake での生成 AI を活用した自然言語クエリ生成が一般利用できるようになりました 6 月に、CloudTrail Lake 向けのこの機能を プレビュー 版として発表しました。今回の発表により、自然言語の質問を使用して SQL クエリを生成し、SQL の技術的な専門知識がなくても、AWS アクティビティログ (管理、データ、ネットワークアクティビティイベントのみ) を簡単に調べて分析できます。この機能では、生成 AI を使用して自然言語の質問を、CloudTrail Lake コンソールで直接実行できる、すぐに使用できる SQL クエリに変換します。これにより、イベントデータストアを探索し、エラー数、使用頻度の高いサービス、エラーの原因などの情報を取得するプロセスが簡素化されます。この機能には、 AWS コマンドラインインターフェイス (AWS CLI) からもアクセスできるため、コマンドライン操作を好むユーザーにさらに柔軟に対応できます。 プレビューブログ投稿 では、CloudTrail Lake の自然言語クエリ生成機能の使用を開始する方法を段階的に説明しています。 CloudTrail Lake 生成 AI を活用したクエリ結果の要約機能のプレビュー 自然言語クエリ生成機能を基盤として、AWS アカウントアクティビティの分析プロセスをさらに簡略化するために、AI を活用した新しいクエリ結果要約機能をプレビューで導入します。この機能を使用すると、クエリ結果のキーポイントを自然言語で自動的に要約することで、AWS アクティビティログ (管理、データ、ネットワークアクティビティイベントのみ) から貴重な洞察を簡単に抽出でき、情報を理解するのに必要な時間と労力を削減できます。 この機能を試すには、 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake で [ クエリ ] を選択します。CloudTrail Lake クエリのイベントデータストアを、 [Event data store] (イベントデータストア) のドロップダウンリストから選択します。集計は、クエリが手動で作成されたものか、生成 AI によって生成されたものかに関係なく使用できます。この例では、自然言語クエリ生成機能を使用します。 クエリジェネレーター では、自然言語を使用して [プロンプト] フィールドに次のプロンプトを入力します。 過去 1 か月間に各サービスで記録されたエラーの数と、各エラーの原因は何でしたか? 次に、 [Generate query] (クエリを生成) を選択します。次の SQL クエリが自動的に生成されます。 SELECT eventsource, errorcode, errormessage, count(*) as errorcount a0****** から WHERE eventtime >= '2024-10-14 00:00:00' AND eventtime <= '2024-11-14 23:59:59' AND ( errorcode IS NOT NULL OR errormessage IS NOT NULL ) GROUP BY 1, 2, 3 ORDER BY 4 DESC; [Run] (実行) を選択して結果を得ます。集計機能を使用するには、[ クエリ結果 ] タブの [ 結果の要約 ] を選択します。CloudTrail はクエリ結果を自動的に分析し、重要な洞察を自然言語で要約します。要約できるクエリ結果には、1 か月あたり 3 MB の割り当てがあることに注意してください。 この新しい要約機能により、主要な調査結果の有意義な要約が自動的に生成されるため、AWS アクティビティデータを理解する時間と労力を節約できます。 包括的なダッシュボード機能 最後に、AWS 環境全体の可視性と分析を強化する CloudTrail Lake の新しいダッシュボード機能について説明します。 1 つ目は ハイライト ダッシュボードで、CloudTrail Lake 管理でキャプチャされたデータと、イベントデータストアに保存されたデータイベントの概要を簡単に確認できます。このダッシュボードでは、API コールの失敗回数が多い回数、ログイン試行の失敗回数の傾向、リソース作成の急増など、重要なインサイトを簡単に特定して把握できます。データ内の異常や異常な傾向を明らかにします。 AWS CloudTrail コンソール に移動し、ナビゲーションペインの Lake の下の [ ダッシュボード ] を選択して、 ハイライト ダッシュボードを確認します。まず、[ 同意してハイライトを有効にする ]を選んでハイライトダッシュボードを有効にします。 データが入力されたら、ハイライトダッシュボードをチェックします。 新しいダッシュボード機能に 2 つ目に追加されたのは、14 種類の組み込みダッシュボードのスイートです。これらのダッシュボードは、さまざまなペルソナやユースケース向けに設計されています。たとえば、セキュリティに重点を置いたダッシュボードは、上位のアクセス拒否イベント、コンソールログイン試行の失敗、多要素認証 (MFA) を無効にしたユーザーなど、主要なセキュリティ指標を追跡および分析するのに役立ちます。また、運用監視用の既定のダッシュボードもあり、スロットリングエラーのある上位APIやエラーのある上位ユーザーなど、エラーや可用性の問題の傾向が強調表示されます。Amazon EC2 や Amazon DynamoDB などの特定の AWS サービスに焦点を当てたダッシュボードを使用することもできます。これらのダッシュボードは、特定のサービス環境におけるセキュリティリスクや運用上の問題を特定するのに役立ちます。 独自のダッシュボードを作成し、必要に応じて更新スケジュールを設定できます。このレベルのカスタマイズにより、CloudTrail Lake 分析機能を AWS 環境全体の正確なモニタリングや調査のニーズに合わせて調整できます。 マネージドとカスタムダッシュボード に切り替えて、カスタムダッシュボードとビルド済みダッシュボードを確認します。 私は、IAM アクティビティ全体を観察するために、 IAM アクティビティダッシュボード 構築済みダッシュボードを選択します。[ 新しいダッシュボードとして保存 ] を選択して、このダッシュボードをカスタマイズできます。 カスタムダッシュボードを最初から作成するには、ナビゲーションペインの [ Lake ] の [ ダッシュボード ] に移動し、[ 独自のダッシュボードを作成 ] を選択します。[ ダッシュボード の名前を入力 ] フィールドに名前を入力し、[ 権限 ] でイベントデータストアを選択して、イベントを視覚化します。 次に、[ ダッシュボードを作成 ] を選択します。 これで、ダッシュボードにウィジェットを追加できます。ダッシュボードは複数の方法で柔軟にカスタマイズできます。[ サンプルウィジェットの追加 ] を使用して事前に作成されたサンプルウィジェットのリストから選択するか、[ 新しいウィジェットの作成 ] を使用して独自のカスタムウィジェットを作成できます。ウィジェットごとに、折れ線グラフ、棒グラフ、またはデータを最もよく表すその他のオプションなど、好みの視覚化のタイプを選択できます。 今すぐご利用いただけます AWS CloudTrail Lake の新機能は、包括的な監査ロギングおよび分析ソリューションの提供における大きな進歩を表しています。これらの機能強化により、より深い理解を得てより迅速に調査を実施できるようになり、AWS 環境全体にわたる予防的な監視とより迅速なインシデント処理が可能になります。 米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、カナダ (中部)、欧州 (ロンドン) の AWS リージョン の CloudTrail Lake で、生成 AI を活用した自然言語クエリ生成 の使用を開始できるようになりました。 CloudTrail Lake の生成 AI を利用したクエリ結果の 要約機能 は、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびアジアパシフィック (東京) リージョンでプレビュー版として利用できます。 強化されたフィルタリングオプション 、 イベントデータストアと ダッシュボード のクロスアカウント共有は、 CloudTrail Lake が利用可能 なすべてのリージョンで利用できます。ただし、Highlights ダッシュボードの生成 AI による要約機能は、米国東部 (バージニア北部)、米国西部 (オレゴン)、およびアジアパシフィック (東京) リージョンでのみ利用できます。 クエリを実行すると、CloudTrail Lake のクエリ料金が発生します。料金の詳細については、 AWS CloudTrail の料金表 をご覧ください。 – Esra 原文は こちら です。

2023 年 11 月、 Amazon EKS 、 Amazon ECS 、 Amazon EC2 でホストされているアプリケーションの分散システムのパフォーマンスのモニタリングに伴う複雑さを解決することを目的とした AWS 組み込みのアプリケーションパフォーマンスモニタリング (APM) ソリューション Amazon CloudWatch Application Signals が発表 されました。Application Signals は、複数のメトリクス、トレース、ログにわたってテレメトリを自動的に相関させることでトラブルシューティングをスピードアップし、アプリケーションの中断を軽減します。Application Signals は、アプリケーションのコンテキストでパフォーマンスを分析するための統合エクスペリエンスを提供することで、最も重要なビジネス機能をサポートするアプリケーションに焦点を当てて生産性を向上させます。 11 月 21 日、AWS Lambda 用 Application Signals for Lambda の提供を発表しました。これにより、関数のアプリケーションの正常性を評価するために必要な手動セットアップの複雑さやパフォーマンスの問題が排除されます。お客様は、 Lambda 用 CloudWatch Application Signals を使用してアプリケーションのゴールデンメトリクス (リクエストの送受信量、レイテンシー、障害、エラー) を収集できるようになりました。 AWS Lambda は基盤となるインフラストラクチャの複雑さを無視するので、サーバーの正常性をモニタリングする必要なくアプリケーションの構築に集中できます。これにより、アプリケーションのパフォーマンスと状態のモニタリングにフォーカスを移して、最高のパフォーマンスと可用性でアプリケーションを運用することができます。そのためには、重要なビジネスオペレーションやアプリケーションプログラミングインターフェイス (API) のトランザクション量、レイテンシの急上昇、可用性の低下、エラーなどのパフォーマンスに関するインサイトの高度な視覚化が必要になります。 以前は、異常の根本原因を突き止めるために、複数のツールにわたって分散したログ、メトリクス、トレースを相互に関連付けるのに多くの時間を費やす必要があり、平均修復時間 (MTTR) と運用コストが増大していました。さらに、カスタムコードまたはオープンソース (OSS) ライブラリを使用した手動インストルメンテーションでの独自の APM ソリューション構築には多くの時間がかかり、複雑である上に多くの運用コストが生じ、大量の Lambda 関数を管理する場合にコールドスタート時間が長くなり、デプロイの課題が発生することがありました。現在、Application Signals を使用して、アプリケーション開発者が手動でインストルメンテーションを行ったり、コードを変更したりすることなく、サーバーレスアプリケーションの正常性とパフォーマンスの問題をシームレスにモニタリングしてトラブルシューティングを行うことができるようになりました。 仕組み Application Signals の組み込み済みの標準化されたダッシュボードを使用すると、重要なビジネスオペレーションや API のパフォーマンスメトリクスをドリルダウンして分析することで、数回のクリック操作だけでパフォーマンス異常の根本原因を特定できます。これにより、関数とその依存関係の間の相互作用を示すアプリケーショントポロジを視覚化できます。さらに、アプリケーションに サービスレベル目標 (SLO) を定義して、最も重要な特定のオペレーションをモニタリングできます。SLO の例には、28 日のローリング間隔でウェブページを 99.9% の精度で 2000 ミリ秒以内にレンダリングするという目標の設定などがあります。 Application Signals は、拡張 AWS Distro for OpenTelemetry (ADOT) ライブラリを使用して Lambda 関数の自動インストルメンテーションを行います。これにより、コールドスタートのレイテンシー、 メモリ消費量、関数呼び出し時間が削減されてパフォーマンスが向上するので、アプリケーションをすばやくモニタリングできます。 ここでは、既存の Lambda 関数 appsignals1 を使って説明します。Lambda コンソールで Application Signals を設定して、このアプリケーションのさまざまなテレメトリを収集します。 関数の [設定] タブで [モニタリングおよび運用ツール] を選択して、 [アプリケーションシグナル] と [Lambda service traces] の両方を有効にします。 この Lambda 関数が リソースとしてアタッチ されているアプリケーション myAppSignalsApp があります。最も重要な特定の複数のオペレーションをモニタリングするためにアプリケーションに SLO を定義しました。アプリケーションが 1 日のローリング間隔で 99.9% の精度で 10 ミリ秒以内に実行されるという目標を定義しました。 Application Signals を呼び出してから関数が検出されるまでに 5～10 分かかることがあります。そのため、サービスを表示するには [サービス] ページを更新する必要があります。 [サービス] ページには、Application Signals によって検出されたすべての Lambda 関数のリストが表示されます。送信されたすべてのテレメトリはここに表示されます。 その後、 [サービス] マップからアプリケーショントポロジ全体を視覚化し、リクエストの量、レイテンシー、障害、エラーの新しく収集されたメトリクスを使って、サービスの個々のオペレーションや依存関係にわたって異常をすばやく見つけることができます。トラブルシューティングを行うために、任意のアプリケーションメトリクスグラフの任意の時点をクリックして、そのメトリクスに関連する相関トレースとログを検出し、エンドユーザーに影響を与える問題が個々のタスクまたはデプロイに分離されているかどうかをすばやく特定できます。 今すぐご利用いただけます 一般提供が開始された Lambda 用 Amazon CloudWatch Application Signals は、Lambda と Application Signals が利用可能なすべての AWS リージョンで今すぐ使用を開始できます。現在、Application Signals は Python と Node.js のマネージドランタイムを使用する Lambda 関数で使用できます。近い将来、他の Lambda ランタイムのサポートが追加される予定です。 詳細については、 AWS Lambda 開発者ガイド と Application Signals 開発者ガイド を参照してください。ご質問は AWS re:Post for Amazon CloudWatch 、または通常の AWS サポート窓口までお送りください。 – Veliswa 原文は こちら です。

11 月 21 日、 AWS マネジメントコンソール のプレビュー版のビジュアルアップデートを発表しました。このアップデートは、直感的かつ包括的で、意義のある AWS エクスペリエンスを大規模に構築するために使用される Amazon Web Services (AWS) の設計システム、 Cloudscape の最新バージョンを使用して展開されます。 この投稿では、ビジュアルアップデートが、使い慣れた一貫性のある AWS マネジメントコンソールのエクスペリエンスを維持しながら、コンテンツのスキャン、重要な情報へのフォーカス、探しているもののより効率的な発見を容易にする方法について説明します。 読みやすさの向上 タイポグラフィのスケールが見直され、見出しの処理が改善されたため、視覚的な階層が強化され、データをより簡単に見つけて理解できるようになりました。テキストエレメント全体でよりきめ細やかに色と太さを使用することで、重要な情報をすばやく区別できるようになりました。例えば、フォームフィールドのラベルがより目立つようになり、確認が容易になりました。キーと値のペアのキーや、サービスナビゲーション、展開可能な要素、タブなどのコンポーネント間のセクションも同様です。 カラーパレットを改善し、より鮮やかにして、インタラクティブ要素のカラー処理を簡略化しました。例えば、多数のインターフェイス要素のサブボタン、リンク、トークン、インタラクティブ状態が青色になったため、画面上のコンテンツを操作しやすくなり、タスク効率の向上につながります。 ライトモードとダークモードでのフォーカスの改善 視覚的な複雑さを軽減することで、ユーザーの集中力を高めることができます。カード、パネル、コンテナなどのメインコンテンツラッパーのドロップシャドウを新しく細いストロークに置き換え、コンポーネント全体でボーダースタイルの使用を統一しました。これにより、視覚的なノイズが減り、レイアウト内のスペースが最適化されます。シャドウは、特定のインタラクティブ要素や一時的な要素に重点を置くためにのみ使用されるようになりました。これにより、視覚的な奥行きがシンプルになり、コンテンツ全体の階層が改善されます。 また、ページ上の要素をより明確に区別する必要性に対応するため、ダークモードのアップデートもリリースしました。これらの変更には、カラーランプのアップデートや、コンポーネント間のインタラクティブ状態間のコントラストの改善が含まれます。 モダナイズされたインターフェイス AWS 全体で、予測可能かつわかりやすいエクスペリエンスを引き続き提供するために、使い慣れたインターフェイスを維持しながらモダナイズを実現しました。より丸みを帯びた形状や、より明るい色を使用し、レイアウト処理を改善したことで、より目にやさしいユーザーエクスペリエンスを実現しました。これらのアップデートにより、よりスムーズかつ自然な外観になり、インターフェイスが見やすくなりました。 より楽しい体験を提供し、視覚的なストーリーテリングをサポートするために、最高のアクセシビリティ基準を維持しながら、まったく新しいイラストとモーションのコレクションも導入しました。 情報密度の向上 未使用スペースを減らすことで情報密度を最適化し、より多くのコンテンツを画面に表示できるようにしました。関連データがより近くに表示されるようになり、視覚的なグループ化が強化されました。カードやコンテナなどのコンテンツラッパー内のスペースが最小限に抑えられたため、一度により多くの情報を消費できます。新しいレイアウトは中央に配置され、幅が広くなり、以前よりも大きな画面サイズに対応できるようエクスペリエンスが最適化されています。ビジュアルアップデートによって、情報を簡単に利用できるようになり、AWS マネジメントコンソールの操作性が向上し、使いやすくなりました。 さらに、コンテキストツールや機能を操作したりアクセスしたりするための新しい方法であるツールバーを導入しました。これにより、画面に表示されるコンテンツの量を最大化しながらタスクを実行できます。 一貫性の向上 インターフェイスがより特徴的かつ一貫性のあるものになりました。刷新された色、アイコン、図形は、よりダイナミックで表現力豊かな体験を提供すると同時に、すべての AWS エクスペリエンスにわたって統一された総合的なジャーニーを強化します。 今すぐご利用いただけます AWS マネジメントコンソール にアクセスすると、すべての AWS リージョン の特定のコンソールで、今すぐビジュアルアップデートを体験できます。今後、アップデートをすべてのサービスに拡張していきます。新しいビジュアル処理により、より読みやすく直感的な操作が可能になり、全体的なタスク効率の向上にもつながります。 原文は こちら です。

Amazon CloudFront 仮想プライベートクラウド (VPC) オリジンのリリースを紹介します。これは、 Amazon Virtual Private Cloud (Amazon VPC) 内のプライベートサブネットでホストされているアプリケーションからのコンテンツ配信を可能にする新機能です。この機能を使用すると、ウェブアプリケーションの保護が容易になり、CloudFront を使用してセキュリティを強化し、高性能でグローバルなスケーラビリティを維持しながら、ビジネスの成長に集中できます。 Amazon Simple Storage Solution (Amazon S3) 、 AWS Elemental Services 、 AWS Lambda 関数 URL からコンテンツを提供しているお客様は、オリジンアクセスコントロールをマネージドソリューションとして使用してオリジンを保護し、CloudFront をアプリケーションへの唯一の入口にすることができます。ただし、 Amazon Elastic Compute Cloud (Amazon EC2) でホストされているアプリケーションやロードバランサーを使用するアプリケーションでは、同じ結果を得るために独自のソリューションを作成する必要があったため、これを実現するのは困難でした。エンドポイントが CloudFront 専用であることを確認するには、 アクセスコントロールリスト (ACL) の使用、ファイアウォールルールの管理、ヘッダー検証などのロジックやその他のいくつかの手法の使用など、複数の方法を組み合わせて使用する必要があります。 CloudFront VPC オリジンでは、CloudFront ディストリビューションをプライベートサブネット内の Application Load Balancer (ALB) 、 Network Load Balancer (NLB) 、または EC2 インスタンスに直接ポイントできるマネージドソリューションを提供することで、このような差別化されていない作業を行う必要がなくなります。その結果、最小限の設定作業で CloudFront をこれらのリソースの唯一のイングレスポイントとすることができます。パブリック IP アドレスの必要性も排除されるので、パフォーマンスが向上し、コスト削減の機会が得られます。 クラウドフロント VPC オリジンの設定 CloudFront VPC オリジンは追加費用なしで利用できるため、すべての AWS のお客様が利用できるオプションとなっています。これは、Amazon CloudFront コンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して新規または既存の CloudFront ディストリビューションと統合できます。 ALB を経由して前面に配置された AWS Fargate for Amazon ECS でプライベートにホストされているアプリケーションがあるとします。プライベートサブネット内で直接 ALB を使用する CloudFront ディストリビューションを作成しましょう。 まず CloudFront コンソールに移動し、新しいメニューオプションである [VPC origins] を選択します。 新しい VPC オリジンの作成は簡単です。必要な操作は、いくつかのオプションから選択することだけです。 [Origin ARN] では、プライベートサブネットでホストされている利用可能なリソースを検索するか、直接入力することができます。目的のリソースを選択し、VPC オリジンのわかりやすい名前といくつかのセキュリティオプションを選択して、設定を確認します。リリース時点では、VPC オリジンリソースは CloudFront ディストリビューションと同じ AWS アカウントに存在する必要がありますが、すべてのアカウントにわたるリソースのサポートが間もなく開始される予定です。 作成プロセスが完了すると、VPC オリジンがデプロイされて使用する準備が整います。 そのステータスは [VPC origins] ページで確認できます。 プライベートサブネットでホストされているリソースからコンテンツを直接提供する CloudFront ディストリビューションを数回のクリック操作だけで作成できました。 VPC オリジンが作成されたら、ディストリビューションウィンドウに移動し、ドロップダウンから ARN を選択するか、ARN を手動でコピーして貼り付けることで、VPC オリジンをディストリビューションに追加できます。 ただし、ウェブエクスプロイトからの保護を提供する AWS ウェブアプリケーションファイアウォール (WAF) や、マネージド DDoS 保護を提供する AWS Shield などのサービス、フルスペクトルの保護を実現するその他のサービスなどを使用してアプリケーションのセキュリティを引き続き階層化することが重要であることを忘れないでください。 まとめ CloudFront VPC オリジンは、CloudFront ディストリビューションがプライベートサブネット内でホストされているリソースから直接コンテンツを提供できるようにすることで、組織が安全で高性能なアプリケーションを配信するための新しい方法を提供します。これにより、アプリケーションを安全に保ちながら、公開オリジンを管理する複雑さとコストが軽減されます。 詳細については、 入門ガイド を参照してください。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

11 月 20 日より、弊社のグローバルコンテンツ配信ネットワーク (CDN) である Amazon CloudFront を gRPC API エンドポイントの前にデプロイできるようになりました。 gRPC は API を構築するための効率的なモダンフレームワークで、言語に依存しません。 インターフェイス定義言語 (IDL) として Protocol Buffers (protobuf) を使用しているため、プラットフォームに依存しない方法でサービスとメッセージタイプを定義できます。gRPC では、HTTP/2 を介した軽量で高性能なリモートプロシージャコール (RPC) を通じてサービス間の通信が実現されます。サービス間の効率的で低遅延の通信が促進されるので、マイクロサービスアーキテクチャに最適です。 gRPC は、双方向ストリーミング、フロー制御、 さまざまなプログラミング言語 用の自動コード生成などの機能を提供します。これは、高性能、効率的な通信、リアルタイムのデータストリーミングが必要なシナリオに最適です。アプリケーションが大量のデータを処理する必要がある場合や、クライアントとサーバー間の低レイテンシー通信が必要な場合は、gRPC を選択することを検討してください。ただし、gRPC は REST に比べて習得が難しい場合があります。例えば、gRPC は protobuf シリアル化形式に依存するので、デベロッパーはデータ構造とサービスメソッドを .proto ファイルで定義する必要があります。 gRPC API エンドポイントの前に CloudFront をデプロイすることには 2 つのメリットがあります。 まず、クライアントアプリケーションと API 実装の間のレイテンシーを短縮できます。 CloudFront は、最も近いエッジへのインテリジェントなルーティング機能を備えた 600 以上のエッジロケーションで構成されたグローバルネットワークを提供します。エッジロケーションは TLS ターミネーションに加えて、静的コンテンツのキャッシュ (オプション) を提供します。 CloudFront は、フルマネージド型、低レイテンシー、高帯域幅のプライベート AWS ネットワークを介してクライアントアプリケーションのリクエストを gRPC オリジンに転送します。 次に、トラフィックの暗号化、 AWS Web アプリケーションファイアウォール による HTTP ヘッダーの検証、 分散型サービス拒否 (DDoS) 攻撃 に対する AWS Shield Standard 保護など、エッジロケーションにデプロイされた追加のセキュリティサービスをアプリケーションで利用できるというメリットがあります。 実際の動作を見てみましょう このデモを開始するために、 公式の gRPC コードリポジトリ にある gRPC route_guide デモ を使用します。デプロイを簡単にするために、このサンプルアプリケーションをコンテナにデプロイします (他のデプロイオプションもサポートされています)。 この Dockerfile を使用します。 FROM python:3.7 RUN pip install protobuf grpcio COPY ./grpc/examples/python/route_guide . CMD python route_guide_server.py EXPOSE 50051 また、 AWS Copilot コマンドライン を使用して Amazon Elastic Container Service (Amazon ECS) にコンテナをデプロイします。Copilot コマンドを実行すると、コンテナーのビルドとデプロイに必要な情報を収集するように求められます。次に、 ECS クラスター 、 ECS サービス 、 ECS タスク が自動的に作成されます。また、TLS 証明書とロードバランサーも作成されます。ロードバランサーリスナーエンドポイントの DNS 名を使用するように 122 行目 を変更して、 クライアントアプリケーション をテストします。また、ロードバランサーがアプリケーションに HTTPS エンドポイントを提供するので、 grpc.insecure_channel の代わりに grpc.secure_channel を使用するようにクライアントアプリケーションのコードを変更します。 API が正しくデプロイされて動作していることが確認できたら、 CloudFront を設定します。 まず、 AWS マネジメントコンソール の CloudFront セクションで [ディストリビューションを作成する] を選択します。 [オリジン] で、 オリジンドメイン として gRPC エンドポイントの DNS 名を入力します。 [プロトコル] として [HTTPS のみ] を有効にして、HTTPS ポートはそのまま (443) にしておきます。次に、ディストリビューションの [名前] を選択します。 [ビューワー] で、 [ビューワープロトコルポリシー] として [HTTPS のみ] を選択します。次に、 [許可された HTTP メソッド] として [GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE] を選択します。 [Allow gRPC requests over HTTP/2] で [有効化] を選択します。 [キャッシュキーとオリジンリクエスト] で、 [オリジンリクエストポリシー] として [AllViewer] を選択します。 デフォルトのキャッシュポリシーは [CacheOptimized] ですが、gRPC はキャッシュ可能な API トラフィックではありません。そのため、 [キャッシュポリシー] として [CachingDisabled] を選択します。 AWS WAF は、可用性に影響する可能性、セキュリティを侵害する可能性、リソースを過剰に消費する可能性のある一般的なウェブエクスプロイトやボットからユーザーを保護するのに役立ちます。gRPC トラフィックの場合、AWS WAF を使用して、リクエストの HTTP ヘッダー を検査し、 アクセスコントロール を適用することができます。protobuf 形式のリクエスト本文は検査されません。 このデモでは、AWS WAF を使用しません。 [ウェブアプリケーションファイアウォール (WAF)] で、 [Do not enable security protections] を選択します。 他のすべてのオプションはデフォルト値のままにします。HTTP/2 のサポートはデフォルトで選択されています。 これは gRPC に必要なので無効にしないでください 。 最後に、 [ディストリビューションを作成] を選択します。 通常の設定に加えて gRPC を有効にするスイッチは 1 つだけです。HTTP/2 と HTTP POST が有効な状態でオンにすると、 CloudFront は gRPC クライアントトラフィックを検出し、それを gRPC オリジンに転送します。 数分後、ディストリビューションの準備が完了します。 CloudFront ディストリビューションのエンドポイント URL をコピーして貼り付けます。クライアント側のアプリケーションを変更して、以前に作成したロードバランサーの代わりに CloudFront をポイントします。 再度テストすると、アプリケーションが動作します。 料金と利用可能なリージョン gRPC オリジンは、追加料金なしで 600 以上のすべての CloudFront エッジロケーションで利用できます。通常のリクエストとデータ転送の料金が適用されます。 今すぐ、 CloudFront オリジンで gRPC エンドポイントをポイントしてください。 — seb 原文は こちら です。

本ブログは2024年10月21日に公開された「 Best practices for building robust generative AI applications with Amazon Bedrock Agents – Part 2 」を翻訳したものです。 この連載の 第 1 部 では、 Amazon Bedrock Agents を使用して正確で信頼性の高いエージェントを作成するためのベストプラクティスを探りました。Amazon Bedrock Agents は、複数ステップのタスクをオーケストレーションすることで、生成 AI アプリケーションの開発を加速するのに役立ちます。エージェントは、基盤モデル (FM) の推論能力を利用して、問題を複数のステップに分解する計画を立てます。また、開発者が提供した指示とモデルを組み合わせてオーケストレーション計画を作成し、その計画を実行します。さらに、エージェントは企業の API や、検索拡張生成 (RAG) を通じて外部の知識を利用することができます。 この第 2 部では、堅牢で拡張性が高く、セキュアなインテリジェントエージェントを構築するのに役立つ、アーキテクチャ上の考慮事項と開発ライフサイクルのプラクティスについて詳しく説明します。会話型 AI の世界を探索し始めたばかりの方も、既存のエージェントのデプロイメントを最適化したい方も、この包括的なガイドは長期的に価値のある洞察と実践的なヒントを提供し、目標達成の助けとなるでしょう。 包括的なログ記録とオブザーバビリティの実現 エージェント開発の初期段階から、徹底的なログ記録とオブザーバビリティの実現を行う必要があります。これはエージェントのデバッグ、監査、トラブルシューティングに不可欠です。包括的なログ記録を実現する第一歩は、 Amazon Bedrock モデル呼び出しログ を有効にして、プロンプトとレスポンスをアカウントで安全に取得することです。 Amazon Bedrock Agents は、 トレース も提供します。ここでは、エージェントがオーケストレーションしているステップ、 FM の呼出し元となるプロンプト、ナレッジベースから返される参照結果、エージェントによって生成されるコードの概要が示されます。トレースイベントはリアルタイムでストリーミングされるため、エンドユーザーにリクエストの進捗状況を通知するための UX キューをカスタマイズできます。エージェントのトレースをログに記録し、エージェントを追跡、およびトラブルシューティングすることができます。 エージェントアプリケーションを本番環境に移行する際は、ログを継続的に分析するためのモニタリングワークフローを設定することがベストプラクティスです。カスタムソリューションを作成するか、 Bedrock-ICYM などのオープンソースソリューションを使用することができます。 Infrastructure as Code (IaC) の利用 他のソフトウェア開発プロジェクトと同様に、反復的で信頼性の高いデプロイを容易にするために、Infrastructure as Code (IaC) を使用する必要があります。これにより、繰り返し可能で本番環境に対応したエージェントを作成し、簡単に再現、テスト、監視できるようになります。Amazon Bedrock Agents では、 AWS CloudFormation 、 AWS Cloud Development Kit (AWS CDK)、または Terraform で IaC コードを記述できます。また、 Agent Blueprints コンストラクトを使用して始めることをお勧めします。Amazon Bedrock Agents の最も一般的な機能のブループリントテンプレートを提供しており、単一の AWS CDK コマンドでデプロイと更新ができます。 アクショングループ を使用するエージェントを作成する場合、 関数定義を JSON オブジェクト としてエージェントに指定するか、 OpenAPI スキーマ 形式の API スキーマを提供できます。すでにアプリケーション用の OpenAPI スキーマがある場合は、それを出発点にするのがベストプラクティスです。エージェントが各関数をいつ使うべきかを理解するために、関数には適切な自然言語の説明を付けることが重要です。既存のスキーマがない場合、エージェントにツールのメタデータを提供する最も簡単な方法は、シンプルな JSON 関数定義を使うことです。いずれの場合も、Amazon Bedrock コンソールを使って、アクションやツールの実装を始めるためのデフォルトの AWS Lambda 関数を素早く作成できます。 エージェントの開発を拡大し始めると、エージェントのコンポーネントの再利用性を検討する必要があります。IaC を使用すると、 Amazon Bedrock Guardrails を使用して事前に定義されたガードレール、 Amazon Bedrock Knowledge Bases を使用したナレッジベース、複数のエージェントで再利用可能なアクショングループを作成できます。 タスクを実行するエージェントを構築するには、関数定義と Lambda 関数が必要です。このコードの開発とメンテナンスを加速するためのもう 1 つのベストプラクティスは、生成 AI を活用することです。これは、Amazon Bedrock の invoke model 機能を直接使用するか、 Amazon Q Developer のサポートを利用するか、あるいはアクショングループのメタデータに基づいて Lambda 関数のフレームワークを作成する AWS PartyRock アプリケーションを作成することで実現できます。生成 AI を使用して、関数定義と Lambda 接続を使用したエージェントを作成するために必要な IaC を直接生成できます。選択したアプローチに関わらず、IaC を検証して実行するテストパイプラインを作成することで、エージェントソリューションを最適化するのに役立ちます。 エージェントの追加コンテキストに SessionState を利用 SessionState を使用して、エージェントに追加のコンテキストを提供することができます。 SessionAttribute を使用してアクショングループ内の Lambda 関数でのみ利用可能な情報を渡し、 SessionPromptAttribute を使用してプロンプトで利用可能にすべき情報を渡すことができます。例えば、アクションで使用するユーザー認証トークンを渡したい場合は、 SessionAttribute に設定するのが最適です。一方、大規模言語モデル (LLM) が推論時に必要とする情報として、現在の日付やタイムスタンプなどを渡したい場合は、 SessionPromptAttribute に設定するのが最適です。これにより、エージェントは基盤となる LLM モデルの推論機能を使って、次の支払い期日までの日数や注文からの経過時間などを推測できるようになります。 コストとパフォーマンスのためのモデル選択の最適化 エージェントを構築するプロセスの重要な部分は、エージェント (または各サブエージェント) の基盤となる FM を選択することです。コスト、レイテンシー、精度の要件に基づいて、利用可能な FM を試し、アプリケーションに最適なものを選択してください。評価指標を収集するための自動化されたテストパイプラインを実装することで、データに基づいたモデル選択の意思決定が可能となります。このアプローチにより、シンプルなエージェントには Amazon Bedrock 上の Anthropic の Claude 3 Haiku のような高速で低コストのモデルを使用し、より複雑なアプリケーションには Anthropic の Claude 3.5 Sonnet や Anthropic の Claude 3 Opus のような高度なモデルを使用できます。 堅牢なテストフレームワークの実装 エージェントまたは生成 AI システムの評価を自動化すると、開発プロセスを加速し、お客様によりよいソリューションを提供できるようになります。エージェントのコスト、レイテンシー、精度など、複数の側面で評価を行いましょう。 Agent Evaluation  のようなフレームワークを使用して、事前に定義された基準に対するエージェントの動作を評価してください。Amazon Bedrock のエージェントバージョニングとエイリアス機能を使用すると、デプロイの段階で A/B テストを実行できます。フォーマルまたはインフォーマルな HR アシスタントの口調など、エージェントの動作の異なる側面を定義し、ユーザーグループの一部でテストすることができます。その後、初期デプロイ時に各グループで異なるエージェントバージョンを利用可能にし、各グループのエージェントの動作を評価できます。Amazon Bedrock Agents には、このテストの重要な部分を支援するための バージョニング機能 が組み込まれています。次の図は、テストと評価のフェーズの後に HR エージェントが更新され、モデル呼び出し用に選択されたエージェントバージョンを指す、新しいエイリアスが作成される方法を示しています。 テストケース生成への LLM の活用 エージェントの期待するユースケースにおけるテストケースを生成するために 、LLM を活用できます。ベストプラクティスとして、テストデータを生成する LLM は、エージェントを実行している LLM とは異なるものを選択することをお勧めします。このアプローチにより、包括的なテストスイートの構築が大幅に加速し、潜在的なシナリオを徹底的にカバーできます。例えば、従業員の休暇予約を支援する HR アシスタントエージェントのテストケースを作成するために、次のようなプロンプトを使用できます。 従業員と従業員アシスタントエージェントの間の会話のやりとりを生成してください。 従業員は休暇を予約しようとしています。 エージェントは、従業員の利用可能な休暇を確認する機能、休暇を予約・更新する機能、 新しい休暇予約が完了したことを通知する機能にアクセスできます。 以下は、休暇予約に関する従業員と従業員アシスタントエージェントの間の会話例です。 あなたの会話には、エージェントと従業員の間に少なくとも3回のやりとりを含める必要があります。 従業員は「こんにちは」から始めます。 強固な確認とセキュリティメカニズムの設計 エージェントのワークフローにおいて、重要なアクションに対しては強固な確認メカニズムを実装することが重要です。特にデータを変更したり、機密性の高い操作を実行する関数については、ユーザーの確認を求めるよう、エージェントの指示に明確に記述してください。このステップは、 PoC やプロトタイプの段階を超えて、本番環境でエージェントが確実に動作することを検証するのに役立ちます。例えば、次のエージェントへの指示では、データベースを更新する前に、休暇申請アクションを実行するかどうかをユーザーに確認させています。 あなたは人事部門のエージェントで、従業員を支援しています ... [簡潔にするため、その他の指示は省略]... 休暇申請の作成、編集、削除を行う前に、あなたの行動についてユーザーの確認を求めてください。 その際、実行される行動が明確になるよう、十分な情報を含めてください。 関数名そのものは提供せず、一般的な言葉で説明してください。 関数スキーマ定義の requireConfirmation フィールド、または API スキーマ 定義の x-requireConfirmation フィールドを使用して、新しいアクションの作成時にAmazon Bedrock Agents の組み込み機能を有効にし、アクショングループ内のアクションを呼び出す前のユーザー確認要求を行うこともできます。 柔軟な認証と暗号化の実装 エージェントのリソースを暗号化するには、 カスタマーマネージドキー を提供する必要があります。また、 AWS Identity and Access Management (IAM) の権限が最小特権の原則に従っていることを確認し、エージェントが必要なリソースとアクションにのみアクセスできるように制限してください。アクショングループを実装する際は、 sessionState の sessionAttributes パラメータを活用して、ユーザーの役割と権限に関する情報を提供し、アクションが細かい権限制御を実装できるようにします ( サンプルコード を参照)。もう 1 つのベストプラクティスは、 sessionState の knowledgeBaseConfigurations パラメータを使用して、ナレッジベースに追加の設定を提供することです。それは例えば、 ナレッジベースのメタデータフィルタリング を通じて、ユーザーがアクセスできるドキュメントを定義するユーザーグループなどです。 責任ある AI の実践の統合 生成 AI アプリケーションを開発する際は、倫理的で透明性が高く、説明責任のある方法でシステムを構築するために、責任ある AI の実践を適用する必要があります。Amazon Bedrock の機能は、責任ある AI の実践をスケーラブルな方式で開発するのに役立ちます。エージェントを作成する際は、Amazon Bedrock Guardrails を実装して、機密情報を避け、ユーザー入力とエージェント出力から有害なコンテンツをフィルタリングし、ユーザープライバシーを保護するために機密情報を編集する必要があります。複数の生成 AI アプリケーションで再利用できる組織レベルのガードレールを作成することで、一貫した責任ある AI の実践を維持できます。ガードレールを作成したら、Amazon Bedrock Agents の組み込みガードレール統合( サンプルコード を参照) を使用してエージェントに関連付けることができます。 再利用可能なアクションカタログの構築と段階的な拡張 最初のエージェントのデプロイが成功した後、アクショングループ、ナレッジベース、ガードレールなどの共通機能を他のアプリケーションで再利用する計画を立てることができます。Amazon Bedrock Agents は、 AWS Management Console を使った手動でのエージェント作成、エージェント API で利用可能な SDK を使用したコーディング、CloudFormation テンプレート、AWS CDK、または Terraform テンプレートを使った IaC での作成をサポートしています。機能を再利用するためのベストプラクティスは、IaC を使ってそれらを作成およびデプロイし、コンポーネントをアプリケーション間で再利用することです。次の図は、HR アシスタントと銀行アシスタントの 2 つのエージェント間で、ユーティリティアクショングループを再利用する例を示しています。 クロール・ウォーク・ランでエージェントの利用を拡大 最後に強調したいベストプラクティスは、クロール・ウォーク・ランの方法論に従うことです。まず内部アプリケーションから始め (クロール)、次に小規模で制御された外部ユーザー向けにアプリケーションを展開し (ウォーク)、最終的にはすべての顧客向けにアプリケーションを拡大 (ラン) し、マルチエージェントコラボレーションを活用します。このアプローチは、ミッションクリティカルなビジネス運用をサポートする信頼性の高いエージェントを構築しつつ、新しいテクノロジーの導入に伴うリスクを最小限に抑えることができます。このプロセスを以下に示します。 結論 これらのアーキテクチャと開発ライフサイクルのベストプラクティスに従うことで、ユーザーに効果的にサービスを提供し、既存のシステムとシームレスに統合できる、堅牢で拡張性が高く、セキュアなエージェントを作成する準備が整います。 具体的な始め方として、 Amazon Bedrock サンプルリポジトリ をチェックしてください。Amazon Bedrock Agents の詳細を学ぶには、 Amazon Bedrock ワークショップ と、より深く掘り下げた Amazon Bedrock Agents ワークショップ を始めてみてください。さらに、AWS re:Invent 2023 からのサービス 紹介ビデオ もチェックしてください。 著者について Maira Ladeira Tanke は、AWS の Senior Generative AI Data Scientist です。機械学習の経験を持ち、10 年以上にわたり、さまざまな業界の顧客向けに AI アプリケーションのアーキテクチャ設計と構築を行ってきました。テクニカルリードとして、Amazon Bedrock 上の生成 AI ソリューションを通じて、顧客のビジネス価値の実現を加速させるのを支援しています。プライベートでは、旅行、猫と遊ぶこと、家族と温かい場所で過ごすことを楽しんでいます。 Mark Roy は、AWS のプリンシパル機械学習アーキテクトで、顧客が生成 AI ソリューションを設計・構築するのを支援しています。2023 年初頭から、 Amazon Bedrock のローンチに向けたソリューションアーキテクチャの取組を主導しています。保険、金融、メディア・エンターテインメント、ヘルスケア、公益事業、製造業を支援してきました。AWS 入社前は、25 年以上にわたってアーキテクト、開発者、テクノロジーリーダーを務め、うち 19 年間は金融業界でした。 Navneet Sabbineni は、AWS Bedrock のソフトウェア開発マネージャーです。ソフトウェア開発者およびマネージャーとして 9 年以上の業界経験があり、Amazon Bedrock Agents のような生成 AI サービスや Amazon Lex のような対話 AI サービスなど、AWS のスケーラブルな分散サービスの構築と保守に携わってきました。仕事以外では、家族や友人と一緒に太平洋北西部を旅行したり探索したりするのが好きです。 Monica Sunkara は、AWS の Senior Applied Scientist で、Amazon Bedrock Agents に従事しています。10 年以上の業界経験があり、そのうち 6 年間は AWS で勤務しています。Monica は、Alexa 音声認識、Amazon Transcribe、Amazon Lex ASR などの AI および ML の取り組みに貢献してきました。最近では、Amazon Titan テキストモデルに関数呼び出し機能を追加する作業に携わりました。Monica は、2018 年に Amazon に入社する前、Andrew Gordon Wilson 教授の指導の下、Cornell 大学でオブジェクト検出に関する研究を行い、学位を取得しています。 本連載の第1部は「 Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 1 」です。 翻訳は AWS プロフェッショナルサービスの相川遼介が担当しました。原文は こちら です。

本ブログは2024年10月2日に公開された「 Best practices for building robust generative AI applications with Amazon Bedrock Agents – Part 1 」を翻訳したものです。 ユーザーのクエリを正確に理解して応答できる、インテリジェントなエージェントの構築には、複数ステージにわたる慎重な計画と実行が必要です。カスタマーサービスチャットボットや仮想アシスタントを開発する場合、エージェントの範囲と機能を定義することから、堅牢で拡張性のあるインフラストラクチャを設計することまで、多くの点に留意する必要があります。 この 2 部構成のシリーズでは、 Amazon Bedrock Agents を使用して生成 AI アプリケーションを構築するためのベストプラクティスを探ります。エージェントは、マルチステップタスクを調整することで、生成 AI アプリケーション開発を加速するのに役立ちます。また、基盤モデル (FM) の推論能力を利用して、エージェントはユーザーからのリクエストに回答するための複数のタスクに分割します。さらに、開発者が提供した指示を使用して、オーケストレーションプランを作成し、そのプランに従って企業の API を呼び出したり、検索拡張生成 (RAG) を使用してナレッジベースにアクセスしたりして、ユーザーのリクエストに対する回答を提供します。 パート 1 では、正確で信頼できるエージェントの作成に焦点を当てます。パート 2 では、アーキテクチャの考慮事項と開発ライフサイクルの実践について説明します。 基礎の構築: 正解データの収集 優れたエージェントの基盤となるのは、高品質な正解データです。つまり、モデル、アルゴリズム、システムのパフォーマンスを評価するための基準となる、現実世界の正確な観測データです。エージェントアプリケーションを構築する前に、エージェントのライフサイクル全体を推進する一連の正解となる対話や受け答えを収集することが不可欠です。このデータにより、エージェントに接続されている既存の API、ナレッジベース、ガードレールとの対話に対して、エージェントの振る舞いとして期待される基準が得られます。これにより、正確なテストと評価が可能になり、エッジケースや潜在的な問題点を特定するのに役立ちます。 堅牢な正解データセットを構築するには、さまざまなユーザーの意図やシナリオをカバーする多様なシナリオに焦点を当てることが重要です。データセットには、単純な対話と複雑な対話の両方について、入力と期待される出力を含める必要があります。さらに、ユーザーの行動について理解を進めると共に、データセットを定期的に更新、拡張することが重要です。実際のユースケースに沿った顧客との対話に基づいてデータを構築しますが、データの匿名化と非識別化を確実に行ってください。 次の表は、銀行アシスタントエージェントのために収集された正解データの一部を示しています。このエージェントは、 check_account_balance と book_appointments の API と連携し、検索拡張生成のナレッジベースとして bankingFAQ を使用し、ガードレール BlockInvestmentAdvice に接続されています。この例では、エージェントをテストするために使用されたクエリのごく一部のみを示しています。これには、他のシステムから使用されたセッション情報で、 sessionAttributes を使ってエージェントに渡されたものが含まれます。また、プロダクションシステムでエージェントに共有される追加情報を収集することも、ベストプラクティスです。これには、アクショングループ実行関数にのみ共有されるセッション属性、プロンプトを補強するために使用される情報 (プロンプトセッション属性)、およびナレッジベースで使用される情報 (ナレッジベース構成) が含まれます。 ユーザークエリ セッション属性 プロンプトセッション属性 期待される回答 呼び出される API 、 ナレッジベース、ガードレール 私の口座残高はいくらですか？ なし なし 残高を確認したい口座番号をお教えいただけますか？ なし 口座1234の残高はいくらですか？ user id 111 なし あなたの残高は X です アクショングループ: check_account_balance(111, 1234) 口座を開設するにはどうすればよいですか？ なし なし ANY_BANK株式会社で新しい銀行口座を開設するには、以下の情報と書類を準備する必要があります：1. 有効な政府発行の身分証明書（運転免許証、パスポートなど）2. 住所証明（公共料金の請求書、賃貸契約書など）3. 社会保障番号または個人納税者識別番号（ITIN）4. 初回入金額（必要な場合）その後、オンラインまたはANY_BANK株式会社の支店で直接申込書に記入できます。承認されたら、初回入金を行い、新しい口座の使用を開始できます。 ナレッジベース:  bankingFAQ ビットコインに投資すべきですか？ なし なし 申し訳ありませんが、お客様のお問い合わせは当社の利用規約に違反しています。当社は投資アドバイスを提供しておりません。現在の状況に最適な投資アドバイスについて話し合うには、(XXX) XXX-XXXXまでお電話ください。喜んでサポートさせていただきます。 ガードレール:  BlockInvestmentAdvice 明日の午後2時に予約を入れていただけますか？ user id 111 Today: 09/03/2024 かしこまりました。明日、2024年9月4日の午後2時にご予約を承りました。あなたの予約IDはXXXXです。 アクショングループ: book_appointment(111, 09/04/2024) スコープと対話サンプルの定義 正解データを用意できたので、次は各エージェントのスコープを明確に定義します。これには、エージェントが処理すべきタスクと処理すべきでないタスクを含め、想定されるユーザーとのやり取りの具体例が含まれます。このプロセスでは、主要な機能と能力、制限事項と範囲外のタスク、想定される入力形式と種類、そして出力形式とスタイルを特定します。 例えば、HR アシスタントエージェントを検討する場合、以下のようなスコープが考えられます。 主要機能： – 会社のHR方針に関する情報提供 – 休暇申請と休暇管理の支援 – 基本的な給与に関する質問への回答 スコープ外： – 機密性の高い従業員データの取り扱い – 採用や解雇の決定 – 法的アドバイスの提供 想定される入力： – HR方針に関する自然言語での質問 – 休暇や休暇情報に関する要求 – 基本的な給与に関する問い合わせ 期待される出力： – 方針に関する質問への明確で簡潔な回答 – 休暇申請のための順序に沿ったガイダンス – 新しい休暇申請、過去の申請情報の取得、編集、削除タスクの完了 – 複雑な問題に対する適切なHR担当者への紹介 – エージェントが対応できない質問に対するHRチケットの作成 エージェントの範囲を明確に定義することで、境界線と期待値を明確にし、開発プロセスを円滑にし、焦点を絞った信頼できる AI エージェントの開発につながります。 ソリューションのアーキテクチャ設計: 相互に作用する小規模で集中したエージェントの構築 エージェントのアーキテクチャに関しては、「分割統治（divide and conquer）」の原則が当てはまります。私たちの経験では、単一の大規模なモノリシックエージェントを構築するよりも、相互に作用する小さな専門的なエージェントを構築する方が効果的であることが証明されています。このアプローチは、モジュール性とメンテナンス性の向上、簡単なテストとデバッグ、特定のタスクに異なる基盤モデルを使用する柔軟性、スケーラビリティと拡張性の強化をもたらします。 例えば、組織内の従業員をサポートする HR アシスタントと、給与チームの従業員をサポートする給与チームアシスタントを考えてみましょう。両方のエージェントには、給与ポリシーに関する質問に答えたり、従業員間の会議をスケジューリングするなどの共通機能があります。機能は似ていますが、スコープと権限は異なります。たとえば、HR アシスタントは社内で利用可能な知識に基づいて質問に回答できますが、給与エージェントは給与従業員のみが利用できる機密情報も処理できます。さらに、HR エージェントは従業員と割り当てられた HR 担当者との間で会議をスケジューリングできますが、給与エージェントは給与チーム内の従業員間の会議をスケジューリングします。単一エージェントアプローチでは、これらの機能がエージェント自体で処理されるため、次の図に示すように、各エージェントで利用可能なアクショングループが重複します。 この例では、ミーティングアクショングループ（ Action Group: handle meetings ）に変更があった場合、その変更を各エージェントに伝播させる必要があります。 ここで、マルチエージェントコラボレーションのベストプラクティスを適用すると、 HR と給与チームのエージェントは、それぞれの範囲に特化した小さなタスク指向のエージェントをオーケストレーションします。そして、それぞれのエージェントは独自の指示を持ちます。そのような場合、ミーティングアクショングループは次の図に示すように、2 つのエージェントで再利用される単独のエージェントによって処理されるようになります。 ミーティングアシスタントエージェントに新機能が追加された場合、 HR エージェントと給与チームエージェントはその機能を処理できるように更新する必要があるだけです。このアプローチはアプリケーションでも自動化でき、エージェントソリューションのスケーラビリティを高めることができます。スーパーバイザーエージェント ( HR エージェントと給与チームエージェント) は、アプリケーションのトーンを設定し、エージェントの各機能 (ナレッジベースまたはサブエージェント) の使用方法を定義することができます。これには、エージェントアプリケーションの一部として、ナレッジベースフィルターとパラメーター制約の実施が含まれます。 ユーザー体験の作り込み: エージェントのトーンの計画 エージェントの個性は、ユーザーとの対話全体の雰囲気を左右します。エージェントの口調を慎重に計画することが、一貫性のあり魅力的なユーザー体験を作り出すために重要です。ブランドの声とパーソナリティ、ターゲット層の好み、フォーマリティのレベル、文化的な配慮など、さまざまな要因を考慮する必要があります。 例えば、フォーマルな HR アシスタントの場合は、敬称と名字を使用してユーザーに丁寧に話しかけ、会話全体を通して専門的で礼儀正しいトーンを維持するよう指示されるかもしれません。一方で、フレンドリーな IT サポートエージェントの場合は、下の名前でユーザーに話しかけ、適切な絵文字やテクノロジー関連のジョークを交えながら、カジュアルで明るいトーンを使用して、会話を軽快で魅力的にするかもしれません。 以下は、フォーマルな HR アシスタントのプロンプト例です。 あなたは人事AIアシスタントです。 従業員が会社の方針を理解し、福利厚生を管理するのを支援します。 常にユーザーに対して敬称（様など）と苗字を使用し、フォーマルに対応してください。 会話全体を通して、プロフェッショナルで丁寧な態度を維持してください。 以下は、フレンドリーな IT サポートエージェントへのプロンプト例です。 あなたはITバディです。技術的な問題の解決をサポートします。 カジュアルで明るい話し方を使い、ユーザーのファーストネームで呼びかけてください。 会話を軽快で楽しいものにするために、適切な絵文字やIT関連のジョークを自由に使ってください。 エージェントのトーンがブランドアイデンティティと一致し、さまざまな対話で一貫していることを確認してください。複数のエージェントでコラボレーションする場合は、アプリケーション全体でトーンを設定し、サブエージェントに対しても強制するとよいでしょう。 明確さの維持: 明確な指示と定義の提供 明確なコミュニケーションは、効果的な AI エージェントの礎となります。指示、関数、ナレッジベースとの対話を定義する際は、誤解を招かない明確な言葉遣いを心がけてください。複雑な概念については、簡潔で直接的な言葉を使い、具体例を示してください。類似した機能の間に明確な境界線を設け、重要なアクションには確認のメカニズムを実装してください。次の例は、明確な指示と曖昧な指示の違いを示しています。 以下は曖昧なプロンプト例です。 ユーザーに利用可能な休暇があるかどうかを確認し、可能であれば予約してください。 以下は明確なプロンプト例です。 1. ユーザーの利用可能な休暇残高を確認するために、`checkTimeOffBalance` 関数を使用します。 2. 要求された休暇が利用可能な場合、`bookTimeOff` 関数を使用して予約します。 3. 休暇が利用できない場合は、ユーザーに通知し、代替日を提案します。 4. 休暇の予約を確定する前に、必ずユーザーに確認を取ります。 明確な指示を与えることで、エラーの可能性を減らし、エージェントが予測可能で信頼できる動作をするようになります。 アクショングループの関数を定義する際も同じアドバイスが当てはまります。曖昧な関数名や定義は避け、パラメータの説明を明確にしてください。次の図は、関数が実際に返す内容とユーザー ID の予想される値のフォーマットに基づいて、ユーザーの詳細情報を取得する 2 つの関数の名前、説明、パラメータを変更する方法を示しています。 最後に、ナレッジベースの説明には、ナレッジベースに何が含まれているか、ユーザーのクエリに答えるためにいつ使用するべきかを明確に記載する必要があります。 以下は曖昧なプロンプト例です。 Knowledge Base 1: このナレッジベースを使用して文書から情報を取得する 以下は明確なプロンプト例です。 Knowledge Base 1: 保険契約と内部文書を含むナレッジベース。 ユーザーが契約条件や内部システムについて質問した場合、このナレッジベースを使用してください 組織の知識活用: ナレッジベースの統合 エージェントに企業の知識を提供できるよう、組織の既存のナレッジベースと統合することが重要です。これにより、エージェントは膨大な情報を活用し、より正確で状況に応じた応答を提供できるようになります。最新の組織データにアクセスすることで、エージェントは応答の正確性と関連性を高め、信頼できるソースを引用し、頻繁なモデル更新の必要性を減らすことができます。 Amazon Bedrock と知識ベースを統合する際は、次の手順を実行してください。 Amazon Bedrock Knowledge Bases を使って、ドキュメントに対してベクトルデータベースのインデックスを作成します。 エージェントが対話中にナレッジベースにアクセスできるように設定します。 レスポンスで参照元のドキュメントを引用するメカニズムを実装します。 ナレッジベースを定期的に更新し、エージェントが最新の情報に一貫してアクセスできるようにしましょう。これは、 StartIngestionJob API と Amazon EventBridge ルール を使用して、定期的、あるいはナレッジベースの Amazon Simple Storage Service (Amazon S3) バケット内のファイル更新で呼び出されるイベントベースの同期を実装することで達成できます。 Amazon Bedrock Knowledge Base をエージェントに統合すると、アプリケーションにセマンティック検索機能を追加できます。 InvokeAgent リクエスト時に、エージェントの SessionState の knowledgeBaseConfigurations フィールドを設定することで、必要な結果数やフィルタを指定し、エージェントがナレッジベースとどのように対話するかを制御できます。 成功の定義: 評価基準の設定 AI エージェントの効果を測定するには、具体的な評価基準を定義することが不可欠です。これらの指標を使用すると、パフォーマンスを評価し、改善が必要な領域を特定し、時間の経過に伴う進捗状況を追跡できます。 次の主要な評価指標を検討してください。 応答の正確性 – あなたの応答が基準データとどの程度一致しているかを測定します。応答が正しいかどうか、エージェントのパフォーマンスと品質が良好かどうかなどの情報を提供します。 タスク完了率 – エージェントの成功率を測定します。この指標の基本的な考え方は、エージェントが要求されたタスクを問題なく完了し、ユーザーの意図を満たすことができた会話やユーザー インタラクションの割合または比率を測定することです。 レイテンシーまたは応答時間 – タスクの実行にかかった時間と応答時間を測定します。入力やクエリを受け取ってから、エージェントが応答または出力を提供するまでの時間を測定します。また、システムで最適化が必要なステップを特定するために、各ステップの実行時間を中間的な指標として採用するのもよいでしょう。 会話の効率性 – 会話が必要な情報を効率的に収集できたかどうかを測定します。 エンゲージメント – エージェントがユーザーの意図を理解し、関連性があり自然な応答を提供し、双方向の会話の流れを維持できるかどうかを測定します。 会話の一貫性 – 応答間の論理的な進行と連続性を測定します。セッション中のコンテキストと関連性が維持されているか、適切な代名詞と参照が使用されているかをチェックします。 さらに、エージェントがあなたのユースケースのタスクをどの程度満たしているかを判断する、ユースケース固有の評価指標を定義する必要があります。例えば、HR のユースケースでは、カスタム指標として、作成されたチケット数を指標にすることができます。エージェントが質問に自力で答えられない場合、チケットが作成されるためです。 堅牢な評価プロセスを実装するには、以下が必要です。 正解データに基づいて包括的なテストデータセットを作成 定量的な指標を測定するための自動評価スクリプトを開発 異なるエージェントのバージョンや構成を比較するための A/B テストを実装 定性的な要因の人的評価を定期的に実施 評価は継続的なプロセスです。エージェントのパフォーマンスとユーザーニーズについて、より多くのことが明確になることに合わせて、評価基準と測定方法を継続的に改善していきましょう。 人間による評価の利用 自動化された指標は価値がありますが、人間による評価は AI エージェントのパフォーマンスを評価し改善する上で重要な役割を果たします。人間の評価者は、自然言語の理解と生成の評価、コンテキストに応じた応答の適切性の評価、潜在的なバイアスや倫理的懸念の特定、ユーザーエクスペリエンスと満足度への洞察など、自動化では定量化が難しい側面について、ニュアンスのあるフィードバックを提供できます。 人間による評価を効果的に活用するには、以下のベストプラクティスを検討してください。 異なる視点からの多様な評価観点を作成する 明確な評価ガイドラインと評価基準を作成する 専門性の高い評価者 (業界有識者など) と、代表的なエンドユーザーの組み合わせを使用する 定量的な評価と定性的なフィードバックを収集する トレンドと改善の余地を特定するために、定期的に評価結果を分析する 継続的改善: テスト、反復、改良 効果的な AI エージェントを構築するには反復的なプロセスが必要です。動作するプロトタイプができたので、徹底的なテストを行い、フィードバックを収集し、エージェントの性能を継続的に改善することが重要です。このプロセスには、正解データセットを使用した包括的なテスト、ベータグループを使用した実環境でのユーザーテスト、エージェントのログと会話トレースの分析、指示、関数定義、プロンプトの定期的な更新、様々な基盤モデルにおける性能比較が含まれます。 徹底的なテストを行うには、AI を使用して多様なテストケースを生成することを検討しましょう。以下は、HR アシスタントのテストシナリオを生成するためのプロンプト例です。 従業員とHR AIアシスタントの間の10の多様な会話シナリオを生成してください。 一般的な要求（例：休暇予約、規約に関する質問）とエッジケース（例：複雑な状況、範囲外の質問）を組み合わせて含めてください。 各シナリオについて、以下を提供してください： 1. 初期ユーザークエリ 2. 期待されるエージェントの応答 3. 潜在的なフォローアップ質問 4. 望ましい最終結果 テストフェーズの最高のツールの 1 つは、 エージェントトレース ( agent trace ) です。トレースにより、エージェントのオーケストレーション中に実行された各ステップでエージェントが使用したプロンプトが提供されます。エージェントの思考の連鎖 ( Chain of thought ) とリーズニングプロセスの洞察が得られます。テストプロセス中の InvokeAgent 呼び出しでトレースを有効にし、エージェントが検証された後に無効にすることができます。 正解データセットを収集した次のステップは、エージェントの動作を評価することです。まず、エージェントの動作を評価するための基準を定義する必要があります。HR アシスタントの例では、エージェントが提供した結果と、休暇データベースを直接クエリした結果を比較するテストデータセットを作成できます。その後、人間による評価を使用してエージェントの動作を手動で評価するか、 Agent Evaluation などのエージェント評価フレームワークを使用して評価を自動化できます。モデル呼び出しログが有効になっている場合、Amazon Bedrock Agents は Amazon CloudWatch のログも提供します。これらのログを使用して、エージェントの動作を検証し、予期しない出力をデバッグし、エージェントを適宜調整できます。 エージェントのテスト段階の最後のステップは、デプロイ段階で A/B テストグループを計画することです。フォーマルな HR アシスタントのトーンや非フォーマルなトーンなど、ユーザーグループの一部で検証できるエージェントの振る舞いの異なる側面を定義する必要があります。その後、初期デプロイ時に各グループに異なるエージェントバージョンを提供し、各グループのエージェントの振る舞いを評価できます。Amazon Bedrock Agents には、このテストの重要な部分を支援するための バージョニング機能 ( AgentVersion API ) が組み込まれています。 結論 これらのベストプラクティスに従い、継続的にアプローチを改善することで、Amazon Bedrock を使用して強力で正確かつユーザー指向の AI エージェントを開発することに大きく貢献できます。このシリーズの第 2 部では、アーキテクチャの考慮事項、セキュリティのベストプラクティス、および本番環境での AI エージェントのスケーリング戦略について探ります。 これらのベストプラクティスに従うことで、Amazon Bedrock を使用して、セキュリティ、正確性、スケーラビリティ、責任ある生成 AI アプリケーションを構築できます。はじめるための例については、 Amazon Bedrock Agents GitHub リポジトリ をご覧ください。 Amazon Bedrock Agents の詳細については、 Amazon Bedrock ワークショップ と、より深く掘り下げた Amazon Bedrock Agents ワークショップ で学習を始めることができます。さらに、AWS re:Invent 2023 からの サービス紹介ビデオ もご覧ください。 著者について Maira Ladeira Tanke は、AWS の Senior Generative AI Data Scientist です。機械学習の経験を持ち、10 年以上にわたり、さまざまな業界の顧客向けに AI アプリケーションのアーキテクチャ設計と構築を行ってきました。テクニカルリードとして、Amazon Bedrock 上の生成 AI ソリューションを通じて、顧客のビジネス価値の実現を加速させるのを支援しています。プライベートでは、旅行、猫と遊ぶこと、家族と温かい場所で過ごすことを楽しんでいます。 Mark Roy は、AWS のプリンシパル機械学習アーキテクトで、顧客が生成 AI ソリューションを設計・構築するのを支援しています。2023 年初頭以降、AWS の主力生成 AI 製品である Amazon Bedrock のローンチに向けたソリューションアーキテクチャの取り組みを主導しています。保険、金融サービス、メディア・エンターテインメント、ヘルスケア、公益事業、製造業の企業を支援してきました。AWS に入社する前は、25 年以上にわたってアーキテクト、開発者、テクノロジーリーダーを務めており、そのうち 19 年間は金融サービス業界でした。  Navneet Sabbineni は、AWS Bedrock のソフトウェア開発マネージャーです。ソフトウェア開発者およびマネージャーとして 9 年以上の業界経験があり、Amazon Bedrock Agents のような生成 AI サービスや Amazon Lex のような対話 AI サービスなど、AWS のスケーラブルな分散サービスの構築と保守に携わってきました。仕事以外では、家族や友人と一緒に太平洋北西部を旅行したり探索したりするのが好きです。 Monica Sunkara は、AWS の Senior Applied Scientist で、Amazon Bedrock Agents に従事しています。10 年以上の業界経験があり、そのうち 6 年間は AWS で勤務しています。Monica は、Alexa 音声認識、Amazon Transcribe、Amazon Lex ASR などの AI と ML の様々なイニシアチブに貢献してきました。最近では、Amazon Titan テキストモデルに関数呼び出し機能を追加する作業に携わりました。Monica は、2018 年にアマゾンに入社する前、Andrew Gordon Wilson 教授の指導の下、Cornell 大学でオブジェクト検出に関する研究を行い、学位を取得しています。 本連載の第2部は「 Amazon Bedrock Agents を使用して堅牢な生成 AI アプリケーションを構築するためのベストプラクティス – Part 2 」です。 翻訳はプロフェッショナルサービスの相川遼介が担当しました。原文は こちら です。

本記事は 2024年2月23日に公開された “Coca-Cola Andina Boosts Operational Visibility with Thanos on AWS” を翻訳したものです。 飲料会社の Coca-Cola Andina は、生産性、効率性、顧客満足度を向上させるために、データからより良い洞察を引き出すには、クラウドが鍵であることに気付きました。そのため、同社はオンプレミスのデータストア全体を、アマゾンウェブサービス（AWS）に新しく構築したデータレイクに移行しました。 その後、Coca-Cola Andina は、過去のデータの可視性を高め、分析に活用するためのカスタムアプリケーションである Thanos を作成しました。このソリューションにより、業務効率を向上させることができ、海外事業の可視性が高まり、従業員の生産性が向上しました。 AWS 上に構築した社内用ツール Thanos による業務効率化 ラテンアメリカを拠点とする Coca-Cola Andina は、チリ、アルゼンチン、ブラジル、パラグアイに 10 の生産工場と約 100 の流通センターを保有し、Coca-Cola やその他のメーカー向けの製品を包装・販売しています。包装・販売における業務プロセス、従業員の作業、トラック車両に関する大量のデータを収集し、保存しています。 Coca-Cola Andina はこれらのデータに簡単にアクセスし、事業強化に活用するためのより良い方法を求めていました。オンプレミス上のインフラストラクチャでは、1 日に 1 回しかデータが更新されないため、短期的な業務改善のための意思決定を行うことができませんでした。 Coca-Cola Andina は、知見を得るまでの時間を短縮するためにデータストレージを AWS に移行しました。具体的には、ERPから運用に関するデータを Amazon Simple Storage Service (Amazon S3) 上に取り込んでいます。(Amazon S3 は、任意の量のデータをどこからでも取得できるように設計されたオブジェクトストレージサービスです)。 Coca-Cola Andina は、既存データと毎日生成される新しいデータの両方を保存するためにクラウド上の Amazon S3 を利用し、データをより迅速に分析できるようにしています。AWS 上の基盤で、すべての業務プロセスと配送の管理システムとして機能する社内ツール Thanos を構築しました。 ニアリアルタイムのインサイトを引き出す Thanos は、製品の流通を最初の注文から支払と配送トラックの返却まで包括的に監視するプラットフォームです。また、Coca-Cola Andina のインフラストラクチャ上で稼働するさまざまなアプリケーションでも使用されており、例えば B2B プラットフォームや通知サービスといった顧客の注文を追跡するためにも使用されています。Thanos は AWS 上で動作し、Amazon S3 と Amazon Relational Database Service (Amazon RDS) からデータを取得します。Amazon RDS は、複数のマネージドサービスで構成されているためクラウド上でデータベースを容易にセットアップ、運用、スケーリング可能です。 また、Thanos はサーバーレスのイベント駆動型コンピューティングサービスである AWS Lambda を利用して分析しています。日付別およびカテゴリ別の販売状況、配送センターが処理できる総量とピッキング能力の比較、各ステージでの注文状況、配送予定日から前倒しして配送する機会、従業員一人当たりの生産性など、会社の業務に関する 25 種類のビューを提供します。 このような詳細なビューにより、同社は積極的な意思決定を行うことができます。例えば、注文量がピッキング能力を超えた場合、Coca-Cola Andina はトラックを移動したり、リソースや従業員を追加したり、施設間で顧客の需要を調整することで、滞りを回避することができます。 Coca-Cola Andina が AWS 上のインフラストラクチャで実現しているのは、このような実用的な分析結果です。データへの迅速なアクセスと流通チェーン全体の可視性が向上したことで、業務を改善するためのインテリジェントな意思決定を行っています。Coca-Cola Andina は、DX の過程で AWS から貴重なサポートを受けています。Coca-Cola Andina の社内業務デジタル化担当コーポレートマネージャーであるPablo Sereno 氏は、「私たちと AWS の使用との関係は、Thanos にとどまりません。AWS は我々のデジタル戦略にも耳を傾け、私たちの施設を訪問して改善の機会を探りました」と述べています。 モニタリングの改善と生産性の向上 Coca-Cola Andina は、最新のデータを活用して、業務改善のためのより良いインサイトや機会を増やしています。これまで、データは 1 日に 1 回更新されていましたが、現在、Thanos は 15 分ごとにデータを更新しています。ニアリアルタイムの情報により、Coca-Cola Andina は Thanos を利用して在庫と出荷を綿密にトラックすることで 、在庫切れの頻度を 0.2% 削減しました。さらに、トラックの積載率を 1% 向上し、従業員の全体的な生産性を向上させ、生産に遅れが生じる可能性のある箇所を監視しました。 Coca-Cola Andina が Thanos から得たインサイトのもう1つの活用例は、顧客が注文を受け取れない可能性が高いタイミングを予測するためのアルゴリズムです。「トラックが到着しても、顧客が休みだったり、コンテナを持っていなかったり、支払いができなかったりして、注文が受け取られないことがあります。それは私たちにとってコストになります」と Sereno 氏は述べています。Thanos の導入により、このような事態がいつ起こるかを正確に予測し、この問題を回避するために注文を調整できるようになり、受け取られなかった注文の割合を 0.3％ 削減しました。 分析機能を拡張しコストを削減を図る ビジュアライゼーションビューと分析モデルの両方で Thanos を使用することで、Coca-Cola Andina は流通プロセスの可視性の向上と継続的な強化により、大幅なコスト削減を短期間で実現しました。しばしば、トラックが配達から戻ってくる際の在庫量が、予想よりも多かったり少なかったりすることがあります。Coca-Cola Andina はデータを利用して、顧客の過去の行動を分析する機械学習モデルをトレーニングしています。あらゆるユースケースの機械学習モデルの構築、トレーニング、デプロイに使用されるフルマネージド型サービスである Amazon SageMaker を利用して、これらの例外を軽減または仮想的に除去する方法を特定しています。 Thanosを導入した最初の1年で、Coca-Cola Andina は生産性を向上させ、効率性を高め、コストを最適化しました。また、ポートフォリオに含まれる SKU の数を 2 倍に増やし、顧客に対しより幅広い商品カテゴリを提供できるようになりました。さらに、AWS での拠点を拡大し続け、業務の効率化を進める計画です。「私たちは AWS で高度な分析ソリューションを開発しており、すでに素晴らしい成果を上げています。次に、これらのソリューションから生じるタスクを自動化する方法を模索しています」と Sereno 氏は述べています。 詳細については、 こちら の Coca-Cola Andina についての事例をご覧ください。 翻訳は、ソリューションアーキテクト 本田 光来が担当しました。 Kate Wiley Kate Wiley は、AWSの小売業界マーケティング責任者です。AWS 入社以前は、Dick’s Sporting Goods、Reebok、Drybar、Jenny Craig などの小売企業でマーケティングを担当していました。Kate は小売業界のマーケティング責任者として、クラウドを使用してブランドと消費者との関係を深め、オペレーションを最適化し、AWS を使用して DX を加速する方法について、小売業者をサポートし教育する責任を担っています。

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」は、生成 AI 基盤の「モデル開発」支援に加え、既存「モデル利用」したビジネス課題解決も支援対象としています。 2024 年 11 月 15 日、生成 AI 実用化推進プログラムの参加者やGENIAC ( Generative AI Accelerator Challenge ) 関係者、生成 AI に関心のある企業が一堂に会する「生成 AI Frontier Meet Up」イベントが開催されました。 イベントは二部構成で、第一部では AWS スピーカーによる最新トレンドのセッションと参加者間の情報交換が行われました。第二部では開発者モデルの紹介とビジネスマッチングの場が設けられ、活発な交流が見られました。 参加者からは「各社の具体的な取り組み発表に刺激を受けた」「多用な立場の参加者から新しい視点を得られた」「一緒に取り組みたい企業と出会うことができた」との声が上がり、生成 AI 技術の実用化を加速させる重要な機会となりました。 多くのお客様にご活用いただいている生成 AI 実用化推進プログラムは、 好評につき申請締め切りを 2025 年 2 月 14 日まで延長いたしました。 現在検討中の方はもちろん、このブログで初めてプログラムをお知りになった方も、 ぜひこの機会にご参加をご検討ください。申し込みは こちら 。 ここからはイベントレポートをお届けします。 第一部 ご挨拶 AWS ジャパン 常務執行役員 サービス & テクノロジー統括本部 統括本部長 安田 俊彦 AWS ジャパン 常務執行役員 サービス & テクノロジー統括本部長の安田俊彦が開会の挨拶を行いました。安田は生成 AI 実用化におけるユーザーコミュニティの重要性を強調し、本イベントを通じて参加者が新たな学びや繋がりを得て、革新的なアイデアが生まれることへの期待を述べました。 AWSスピーカーによるセッション AWS ジャパン 機械学習ソリューションアーキテクト 卜部 達也 AWS ジャパンの機械学習ソリューションアーキテクト、卜部達也が、生成 AI の取り組みとトレンド、実用化への課題、そして AWS のソリューションについて講演しました。2024 年を「生成 AI 実用化元年」と位置づけ、AWS ジャパンは生成AI実用化推進プログラムを通じて企業の本格導入を支援しています。Amazon の 25 年以上にわたるAI技術投資の成果を活かし、インフラからアプリケーション開発、実際の利用まで幅広くサポートします。業界の主要トレンドとして、特化モデルへの移行や複数モデルの活用が挙げられました。実用化に向けては、セキュリティ、コスト管理、スケーラビリティなどの課題に対し、AWS は責任ある AI の実現を重視し、新機能を次々と導入しています。実例として、レアジョブテクノロジーズのレッスンレポート自動化や iSmart Technologies の生産現場データ解析効率化が紹介されました。 プログラム参加者によるライトニングトーク 生成 AI 実用化推進プログラムに参加している 5 社の企業代表者が登壇し、それぞれの取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長の小林正人と、AWS シニア スタートアップ ML ソリューションアーキテクトの針原佳貴がモデレーターを務め、登壇者に質問を投げかけることで、参加企業の取り組みについて理解を深める機会となりました。 AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長 小林 正人 (写真右） AWS シニア スタートアップ ML ソリューションアーキテクト 針原 佳貴（写真左） アライズイノベーション株式会社 代表取締役社長 CEO 清水 真 氏 「モデル開発者」として参加するアライズイノベーション株式会社の代表取締役社長 CEO、清水真氏が革新的 AI-OCR プロジェクトについて紹介しました。自社開発の既存システム「 AIRead 」に生成AI技術を組み合わせ、文書のデジタル化プロセスの効率を劇的に向上させることを目指しています。従来の AI-OCR と新たに調整されたVision-Language Model ( VLM ) を組み合わせることで、OCR 結果の検証作業を最大 80% 削減できる可能性があるとのことです。特に年間数百万枚の文書を処理する金融機関にとって、この技術は革命的な変化をもたらすと期待されています。オープンソース VLM を基にしたカスタムモデルの採用により、オフライン環境での使用、コスト管理の容易さ、顧客固有データでの調整が可能になります。金融業界を皮切りに幅広い分野での採用が期待されています。 Anti-pattern 代表取締役 CEO 兼 VPoE 小笹 佑京 氏 2社目は「モデル利用者」のAnti-pattern 社、代表取締役CEO 兼 VPoE 小笹佑京氏が登壇しました。同社が開発した SaaSus Platform は、SaaS 開発を効率化するツールで、最新の生成 AI 活用 API Gateway 機能により、API の自動生成や管理が可能になりました。 このプラットフォームはテナント管理、認証、請求などの SaaS 共通機能を提供し、開発者がコア機能に集中できる環境を整えます。新機能により、ソースコードのアップロードと簡単な設定だけで API の公開が可能になりました。SaaSus Platform は新規開発から既存システムの SaaS化まで幅広く対応し、AWS サービスとの連携で高度な機能を実現。これにより、SaaS 開発の障壁が低くなり、多くの企業の SaaS ビジネス参入を促進することが期待されます。 株式会社 NTT データ テクノロジーコンサルティング事業本部 デジタルサクセスコンサルティング事業部 主任 鯨田 連也 氏 3社目は「モデル利用者」のNTT データ デジタルサクセスコンサルティング事業部主任、鯨田連也氏が登壇し、AI Agent による広告生成ソリューションを紹介しました。このソリューションは生成 AI と AI エージェントを活用し、広告作成プロセスを半自動化。非専門家でも高品質な広告を迅速かつ低コストで作成できることを目指しています。 AI エージェントが各ステップを管理しつつ、ユーザー入力を取り入れることで、品質と柔軟性を確保しています。訴求ポイントの生成から広告画像の作成まで、ユーザーフィードバックを交えながらプロセスを進行。技術面では、Amazon Bedrock を活用し、AWS Cloud Development Kit (AWS CDK) で IaC化することで、堅牢性と展開性を高めています。このソリューションは広告作成の属人化解消とコスト削減の解決策として期待されています。 株式会社三陽商会 経営統括本部 システム部 花輪 俊夫 氏 4 社目は「モデル利用者」の株式会社三陽商会 経営統括本部 システム部の花輪俊夫氏が登壇し、アパレル企業ならではの生成 AI 活用について紹介しました。三陽商会は人間の創造性拡張を目的とした生成 AI 導入を戦略的に進めており、全従業員向け AI アシスタントの導入、商品画像やウェブコンテンツの定性的分析の高度化、そしてクリエイティブプロセスへの AI 適用を主な取り組みとしています。実施アプローチは段階的で、AI チャットアシスタント導入から始め、徐々に高度な分析や創造的プロセスへ展開していく予定です。社内文書の RAG 適合性の低さ、従業員の AI 不慣れ、既存業務文化との調和などの課題がありますが、これらに対処しながら進めていく方針です。この取り組みは、技術革新と従業員の適応、既存業務文化のバランスを取りつつ、段階的に推進されます。 株式会社昭栄美術 営業開発室 室長 榎本 光孝 氏 5 社目は「モデル利用者」の株式会社昭栄美術 営業開発室長、榎本光孝氏が登壇し、リアルイベントや展示会におけるデータ活用の革新的な取り組みを紹介しました。コロナ後のリアル回帰を捉え、物理的イベントでのデータ収集・分析に注力しています。AWS の各種サービスを駆使し、来場者データの収集から高度な分析までをシームレスに行う環境を構築しています。大学との産学連携も進め、AI による分析結果と従来の手作業分析を比較検証し、精度向上を図っています。今後は市場環境やターゲットニーズ、アクセスデータなどの付加情報を分析に組み込み、より深い洞察を目指します。また、イベント主催社側が出展社集客のため、出展した場合のRoIを示すデータの提供をすることで集客率アップを目指すような取り組みも進めています。 第一部参加者交流会 登壇者への質問を希望する参加者が列を作るなど、積極的な交流が見られました。 第二部 ご挨拶 AWSジャパン　Data&AI事業開発本部 本部長　瀧川 大爾 第二部の開始にあたり、AWSジャパン Data & AI 事業開発本部長の瀧川大爾が開会の挨拶を行い、本イベントへの期待と、生成 AI 実用化推進プログラムが多くの顧客に活用されていることを改めて強調しました。 開発者のモデルご紹介 生成AI実用化推進プログラムの「モデル開発者」として応募した企業、2023年の LLM 開発支援プログラムに参加し、GENIAC にも採択された企業の方々が、開発したモデルについて紹介しました。第一部と同様、モデレーターの小林と針原が登壇者に質問を投げかけ、参加者の理解を深める形式で進行しました。 株式会社リワイア 生成 AI プロダクトマネージャー 八百 俊哉 氏 プログラム「モデル開発者」の株式会社リワイア 生成 AI プロダクトマネージャー、八百俊哉氏が安全な基盤モデルによるオーダーメイド画像生成 AI について発表しました。リワイアが開発したGenerright は、生成 AI の信頼性と公平性を確立し、クリエイティブの持続可能な発展を目指しています。許諾データのみで構築した安全な基盤モデルと IP 所有企業との協業により、炎上リスクを回避しつつ新コンテンツの活用を可能にします。さらに、トレーサビリティ確保のためのメタ情報付与や、コンテンツの来歴情報付与（C2PA）により、国際基準を用いた審議判定や、メタデータを保持した画像編集が可能になります。これらの機能により、AI による画像生成の信頼性と透明性が大幅に向上します。 カラクリ株式会社　取締役CPO　中山 智文 氏 LLM 開発支援モデル参加者かつ GENIAC 採択者のカラクリ株式会社 取締役 CPO、中山智文氏が「日本のカスタマーサポートのための高品質 AI エージェントモデルの開発」について発表しました。東京大学発の AI スタートアップであるカラクリは、カスタマーサポート業界向けの特化型 AI エージェントモデル開発に着手。これは人材不足や生産性向上の課題に対する革新的ソリューションとして注目されています。同社はオープンソースの「 KARAKURI LM 」シリーズで高精度の日本語モデルを実現し、今回のプロジェクトではカスタマーサポート特有のデータセットとベンチマークを作成。「 Tool use 」と「 Computer use 」という 2 つの革新的アプローチを採用し、ハルシネーションリスクの低減と高度なセキュリティを目指しています。開発成果をオープンソース化することで業界全体のAI導入加速を目指すカラクリの取り組みは、カスタマーサポート業界の生産性向上とプロフィットセンター化への有望な解決策として期待されています。 株式会社リコー　AI インテグレーションセンター 所長　梅津 良昭 氏 LLM 開発支援プログラム参加者かつ GENIAC 採択者の株式会社リコー AI インテグレーションセンター所長、梅津良昭氏が「 AI エージェントやりませんか？」と題して発表しました。リコーは 2023 年 4 月の 7B パラメータ LLM 発表から 1 年で GPT-4 に匹敵する 70B モデルまで進化させ、AI エージェントとデジタルヒューマンの開発に注力しています。リコーカップの AI CM が YouTube で 28 万回以上再生されるなど、成果を上げています。同社は AI エージェントが製品やサービスの評価を左右する重要要素になると予測し、24 時間多言語対応可能なボイスエージェントの例を挙げてその重要性を強調しています。 課題である日本企業の技術マニュアルの難解さに対し、マニュアル専用言語モデル（ LMM ）の開発を計画。すべての日本企業への AI エージェント提供を目指し、共同開発パートナーや参加企業を募集しています。 ストックマーク株式会社　取締役 CTO　有馬 幸介 氏 最後に、LLM 開発者支援プログラム参加者かつ GENIAC 採択者のストックマーク株式会社 取締役 CTO、有馬幸介氏が「ドキュメント読解 LLM とナレッジグラフ」について発表しました。2016 年創業のストックマークは、自然言語処理AIを活用した情報収集・資料作成支援サービスを提供し、日経 225 企業の 30% を含む 300 社以上に導入されています。同社の技術チームは、複雑なビジネス文書を効率的に解析する深層学習技術を開発。多様なレイアウトや図表が混在する文書を自動構造化し、検索可能なデータに変換します。また、社内文書から自動的にナレッジグラフを生成し、企業固有の知識を活用した AI による高度な回答生成を可能にしています。特に文書のレイアウト解析と要素間の関係抽出の精度が高く、競合他社の API より正確に文書要素をグルーピングできます。この技術は製造業の R&D 部門や新規事業開発チームに重宝され、市場調査や技術情報収集、社内外の情報統合に活用されています。 全体交流会の様子 全体交流会では、開発者モデルを紹介した 4 社のブースへの質問、AWS よろず相談コーナーでの相談、プログラム参加企業の紹介スライドの閲覧など、参加者が積極的に学びを深める姿が見られました。会場全体で活発な意見交換が行われ、このイベントを通じて多くの新たなつながりが生まれたことが感じられ、主催者としても大変うれしく思っています。 最後に 今回初めての Meet up イベント開催で至らない点もありましたが、参加者の皆様が各セッションに熱心に耳を傾け、積極的に交流される姿が見られ、非常に活気のあるイベントとなりました。「次回はいつですか？」というお問い合わせも多く、嬉しく思います。第二回は2025年に開催を予定していますので、ぜひご参加ください。

本記事は、2024/11/15 に公開された Enrich your AWS Glue Data Catalog with generative AI metadata using Amazon Bedrock を翻訳したものです。翻訳は Solutions Architect の渡邉が担当しました。 メタデータは、データ資産を使用してデータ主導の意思決定を行う際に非常に重要な役割を果たします。多くの場合、データ資産のメタデータの生成は手作業であり時間がかかります。生成 AI を活用することで、ドキュメントに基づいたデータ資産の包括的なメタデータ生成を自動化し、AWS クラウド環境内のデータディスカバリー、データ理解、全体的なデータガバナンスを強化できます。本記事では、 Amazon Bedrock 上の基盤モデル (FM) とデータドキュメントを使用し動的メタデータによって AWS Glue Data Catalog を強化する方法を説明します。 AWS Glue は、分析ユーザーが複数のソースからデータを簡単に検出、準備、移動、統合できるようにするサーバーレスデータ統合サービスです。 Amazon Bedrock は、単一の API を介して AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった大手 AI 企業からの高性能な FM を選択できるフルマネージドサービスです。 ソリューションの概要 このソリューションでは、Amazon Bedrock を通じて大規模言語モデル (LLM) を使用し、データカタログ内のテーブル定義のメタデータを自動的に生成します。はじめに、LLM がドキュメントなしで要求されたメタデータを生成するコンテキスト内学習のオプションを模索します。次に、検索拡張生成 (RAG) を使用して LLM プロンプトにデータドキュメントを追加し、メタデータの生成を改善します。 AWS Glue Data Catalog 本記事では、さまざまなデータ ソースにわたるデータ資産の一元的なメタデータリポジトリである AWS Glue Data Catalog を使用します。AWS Glue Data Catalog は、データ形式、スキーマ、ソースに関する情報を保存およびクエリするための統合インターフェイスを提供します。これは、データソースの場所、スキーマ、およびランタイムメトリクスへのインデックスとして機能します。 データカタログにデータを追加する最も一般的な方法は、データソースを自動的に検出してカタログ化する AWS Glue クローラー を使用することです。クローラーを実行すると、指定したデータベースまたはデフォルトのデータベースに追加されるメタデータテーブルが作成されます。各テーブルは単一のデータストアを表しています。 生成 AI モデル LLM(大規模言語モデル) は膨大な量のデータでトレーニングされ、数十億のパラメータを使用し質問への回答、言語の翻訳、文章の完成などの一般的なタスクの出力を生成します。メタデータ生成などの特定のタスクに LLM を使用するためには、期待する出力を生成するようにモデルをガイドするアプローチが必要です。 この投稿では、次の 2 つの異なるアプローチでデータの説明的なメタデータを生成する方法を説明します。 コンテキスト内学習 検索拡張生成 (RAG) このソリューションでは Amazon Bedrock で利用可能な 2 つの生成 AI モデル (テキスト生成タスク用と Amazon Titan Embeddings V2 用) を使用します。 次のセクションでは、Python を使用した各アプローチの実装の詳細について説明します。付属のコードは GitHub リポジトリ にあります。 こちらは Amazon SageMaker Studio や JupyterLab、またはご自身の環境で段階的に実装できます。 SageMaker Studio を初めて使用する場合は、デフォルト設定で数分で起動できる クイックセットアップ を確認してください。このコードは AWS Lambda 関数または独自のアプリケーションでも使用することができます。 アプローチ1: コンテキスト内学習 このアプローチでは、LLM を使用してメタデータの説明を生成します。プロンプトエンジニアリングを使用して、LLM に生成させたい出力を指示します。このアプローチは、テーブルの数が少ない AWS Glue データベースに最適です。コンテキストウィンドウ (ほとんどの Amazon Bedrock モデルが受け入れる入力トークンの数) を超えることなく、データカタログからテーブル情報をプロンプトのコンテキストとして送信できます。以下の図が、そのアーキテクチャとなります。 アプローチ2: 検索拡張生成(RAG) 数百のテーブルがある場合、すべてのデータカタログ情報をコンテキストとしてプロンプトに追加すると、LLM のコンテキストウィンドウを超えるプロンプトが表示される可能性があります。場合によっては、出力を生成する前に FM に参照してもらいたいビジネス要件ドキュメントや技術ドキュメントなどの追加コンテンツもあります。そのようなドキュメントは数ページに及ぶこともあり、通常ほとんどの LLM が受け入れられる入力トークンの最大数を超えます。そのため、そのままではプロンプトに含めることができません。 解決策として RAG アプローチの使用が挙げられます。RAG を使用すると 応答を生成する前に学習データソース以外の権威あるナレッジベースを参照し LLM の出力を最適化できます。RAG はモデルをファインチューニングすることなく、LLMを特定のドメインまたは組織内部のナレッジベースに拡張します。これは LLM の出力を改善するための費用対効果の高いアプローチであり、LLM は様々なコンテキストにおいて適切かつ正確で有用なものとなります。 RAG を用いると LLM はメタデータを生成する前に、データに関する技術的なドキュメントやその他の情報を参照することができます。その結果、生成される説明はより豊かで正確なものになることが期待されます。 本記事の例では、公開されている Amazon Simple Storage Service (Amazon S3): s3://awsglue-datasets/examples/us-legislators/all からデータを取り込みます。このデータセットには、米国の議員に関するJSON形式のデータと彼らが米国下院と米国上院で保持した議席が含まれています。データドキュメントは Popolo ( http://www.popoloproject.com/ ) から取得しました。 以下のアーキテクチャ図は、RAG アプローチを示しています。 流れは以下の通りです。 データドキュメントから情報を取り込みます。ドキュメントには様々な形式があり得ます。本記事ではドキュメントはウェブサイトになります。 データドキュメントのHTMLページのコンテンツをチャンクします。データドキュメントのベクトル埋め込みを生成し、保存します。 データカタログからデータベーステーブルの情報を取得します。 ベクトルストアで類似検索を行い、最も関連性の高い情報をベクトルストアから取得します。 プロンプトを構築します。メタデータの作成方法を指示し、取得した情報とデータカタログのテーブル情報をコンテキストとして追加します。今回は6つのテーブルを含むかなり小規模なデータベースであるため、データベースに関するすべての情報を含めます。 LLM にプロンプトを送信し応答を取得して、データカタログを更新します。 前提条件 本記事の手順に従って、ご自身の AWS アカウントにソリューションをデプロイする場合は、 GitHub リポジトリ を参照してください。 以下のリソースが必要となります: AWSアカウント Python と boto3 AWSGlueServiceRole ポリシーまたは同等のポリシーを含む、 AWS Glue クローラー 用の AWS Identity and Access Management（IAM） ロールと、本記事で使用するデータが保存されている S3 バケットにアクセスできるインラインポリシー 本記事では環境構築の一環として、 aws-gen-ai-glue-metadata-<random_sequence> という名前で新しいS3バケットを作成します。以下はインラインポリシーの例です。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": [ "arn:aws:s3:::aws-gen-ai-glue-metadata-*/*" ] } ] } ノートブック環境のIAMロール。IAMロールは、AWS Glue、Amazon Bedrock、Amazon S3 に対して適切な権限を持つ必要があります。以下はポリシーの例です。ご自身の環境に合わせて、さらに条件を追加して制限をかけることができます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "GluePermissions", "Effect": "Allow", "Action": [ "glue:GetCrawler", "glue:DeleteDatabase", "glue:GetTables", "glue:DeleteCrawler", "glue:StartCrawler", "glue:CreateDatabase", "glue:UpdateTable", "glue:DeleteTable", "glue:UpdateCrawler", "glue:GetTable", "glue:CreateCrawler" ], "Resource": "*" }, { "Sid": "S3Permissions", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:CreateBucket", "s3:ListBucket", "s3:DeleteObject", "s3:DeleteBucket" ], "Resource": "arn:aws:s3:::<bucket_name>" }, { "Sid": "IAMPermissions", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::<account_ID>:role/GlueCrawlerRoleBlog" }, { "Sid": "BedrockPermissions", "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-sonnet-20240229-v1:0", "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0" ] } ] } Amazon Bedrock における Anthropic の Claude 3 と Amazon Titan Text Embeddings V2 への モデルアクセス 。 how_to_generate_metadata_for_glue_data_catalog_w_bedrock.ipynb のノートブック リソースと環境のセットアップ 以上が前提条件となり、次のステップを実行するためにノートブック環境に切り替えます。ノートブックのセットアップの手順では最初にノートブックが必要とする以下のリソースが作成されます。 S3 バケット AWS Glue データベース AWS Glue クローラー(自動的に実行され AWS Glue データベーステーブルを自動生成する) セットアップが完了すると、 legislators という AWS Glue データベースが作成されています。 クローラーは以下のメタデータテーブルを作成します。 persons memberships organizations events areas countries これは議員と彼らの経歴を含む半正規化されたテーブルの集合です。 ノートブックの残りの手順に従って環境のセットアップを完了させてください。数分で完了します。 データカタログの検査 セットアップが完了したら、データカタログを検査し、データカタログとメタデータを確認します。AWS Glueのコンソールで、ナビゲーションペインの Databases を選択し、新しく作成した legislators データベースを開きます。以下のスクリーンショットのように、6つのテーブルが含まれているはずです。： テーブルを開いて詳細を確認できます。テーブルの説明とそれぞれのカラムに対するコメントは、AWS Glue クローラーによって自動的に補完されないため、空白になっています。 AWS Glue API を使用して、各テーブルの技術的なメタデータにプログラムでアクセスすることができます。以下のコードスニペットは、AWS SDK for Python (Boto3) で AWS Glue API を使用して選択したデータベースのテーブルを取得し、検証のために画面へ表示します。本記事のノートブックにある以下のコードは、データカタログ情報をプログラムで取得するために使用されます。 def get_alltables(database): tables = [] get_tables_paginator = glue_client.get_paginator('get_tables') for page in get_tables_paginator.paginate(DatabaseName=database): tables.extend(page['TableList']) return tables def json_serial(obj): if isinstance(obj, (datetime, date)): return obj.isoformat() raise TypeError ("Type %s not serializable" % type(obj)) database_tables = get_alltables(database) for table in database_tables: print(f"Table: {table['Name']}") print(f"Columns: {[col['Name'] for col in table['StorageDescriptor']['Columns']]}") 以上で AWS Glue データベースとテーブルを詳しく知ることができましたので、次のステップでは生成 AI を使ってテーブルのメタデータの説明を生成します。 Amazon Bedrock と LangChain を使い Anthropic Claude 3 でテーブルのメタデータ記述を生成する このステップでは、AWS Glue データベースに存在する選択したテーブルの技術的なメタデータを生成します。この記事では persons テーブルを使用します。まず、データカタログ から全てのテーブルを取得し、プロンプトの一部として含めます。このコードは1つのテーブルのメタデータを生成することを目的としていますが、LLM に外部キーを検出させたいため幅広い情報を与えることが有効です。ノートブック環境にLangChain v0.2.1をインストールします。以下のコードを確認してください。： from langchain_core.output_parsers import StrOutputParser from langchain_core.prompts import ChatPromptTemplate from botocore.config import Config from langchain_aws import ChatBedrock glue_data_catalog = json.dumps(get_alltables(database),default=json_serial) model_kwargs ={ "temperature": 0.5, # You can increase or decrease this value depending on the amount of randomness you want injected into the response. A value closer to 1 increases the amount of randomness. "top_p": 0.999 } model = ChatBedrock( client = bedrock_client, model_id=model_id, model_kwargs=model_kwargs ) table = "persons" response_get_table = glue_client.get_table( DatabaseName = database, Name = table ) pprint.pp(response_get_table) user_msg_template_table=""" I'd like you to create metadata descriptions for the table called {table} in your AWS Glue data catalog. Please follow these steps: 1. Review the data catalog carefully 2. Use all the data catalog information to generate the table description 3. If a column is a primary key or foreign key to another table mention it in the description. 4. In your response, reply with the entire JSON object for the table {table} 5. Remove the DatabaseName, CreatedBy, IsRegisteredWithLakeFormation, CatalogId,VersionId,IsMultiDialectView,CreateTime, UpdateTime. 6. Write the table description in the Description attribute 7. List all the table columns under the attribute "StorageDescriptor" and then the attribute Columns. Add Location, InputFormat, and SerdeInfo 8. For each column in the StorageDescriptor, add the attribute "Comment". If a table uses a composite primary key, then the order of a given column in a table’s primary key is listed in parentheses following the column name. 9. Your response must be a valid JSON object. 10. Ensure that the data is accurately represented and properly formatted within the JSON structure. The resulting JSON table should provide a clear, structured overview of the information presented in the original text. 11. If you cannot think of an accurate description of a column, say 'not available' Here is the data catalog json in <glue_data_catalog></glue_data_catalog> tags. <glue_data_catalog> {data_catalog} </glue_data_catalog> Here is some additional information about the database in <notes></notes> tags. <notes> Typically foreign key columns consist of the name of the table plus the id suffix <notes> """ messages = [ ("system", "You are a helpful assistant"), ("user", user_msg_template_table), ] prompt = ChatPromptTemplate.from_messages(messages) chain = prompt | model | StrOutputParser() # Chain Invoke TableInputFromLLM = chain.invoke({"data_catalog": {glue_data_catalog}, "table":table}) print(TableInputFromLLM) 前述のコードでは、データカタログ更新 API が期待する TableInput オブジェクトに適した JSON レスポンスを提供するように LLM に指示しました。以下はレスポンスの例です。： { "Name": "persons", "Description": "This table contains information about individual persons, including their names, identifiers, contact details, and other relevant personal data.", "StorageDescriptor": { "Columns": [ { "Name": "family_name", "Type": "string", "Comment": "The family name or surname of the person." }, { "Name": "name", "Type": "string", "Comment": "The full name of the person." }, { "Name": "links", "Type": "array<struct<note:string,url:string>>", "Comment": "An array of links related to the person, containing a note and URL." }, { "Name": "gender", "Type": "string", "Comment": "The gender of the person." }, { "Name": "image", "Type": "string", "Comment": "A URL or path to an image of the person." }, { "Name": "identifiers", "Type": "array<struct<scheme:string,identifier:string>>", "Comment": "An array of identifiers for the person, each with a scheme and identifier value." }, { "Name": "other_names", "Type": "array<struct<lang:string,note:string,name:string>>", "Comment": "An array of other names the person may be known by, including the language, a note, and the name itself." }, { "Name": "sort_name", "Type": "string", "Comment": "The name to be used for sorting or alphabetical ordering." }, { "Name": "images", "Type": "array<struct<url:string>>", "Comment": "An array of URLs or paths to additional images of the person." }, { "Name": "given_name", "Type": "string", "Comment": "The given name or first name of the person." }, { "Name": "birth_date", "Type": "string", "Comment": "The date of birth of the person." }, { "Name": "id", "Type": "string", "Comment": "The unique identifier for the person (likely a primary key)." }, { "Name": "contact_details", "Type": "array<struct<type:string,value:string>>", "Comment": "An array of contact details for the person, including the type (e.g., email, phone) and the value." }, { "Name": "death_date", "Type": "string", "Comment": "The date of death of the person, if applicable." } ], "Location": "s3://<your-s3-bucket>/persons/", "InputFormat": "org.apache.hadoop.mapred.TextInputFormat", "SerdeInfo": { "SerializationLibrary": "org.openx.data.jsonserde.JsonSerDe", "Parameters": { "paths": "birth_date,contact_details,death_date,family_name,gender,given_name,id,identifiers,image,images,links,name,other_names,sort_name" } } }, "PartitionKeys": [], "TableType": "EXTERNAL_TABLE" } また、生成された JSON は AWS Glue API が期待するフォーマットに準拠しているか検証することもできます。： from jsonschema import validate schema_table_input = { "type": "object", "properties" : { "Name" : {"type" : "string"}, "Description" : {"type" : "string"}, "StorageDescriptor" : { "Columns" : {"type" : "array"}, "Location" : {"type" : "string"} , "InputFormat": {"type" : "string"} , "SerdeInfo": {"type" : "object"} } } } validate(instance=json.loads(TableInputFromLLM), schema=schema_table_input) これでテーブルとカラムの説明が生成されたので、データカタログを更新することができます。 データカタログのメタデータを更新する このステップでは、AWS Glue API を使用してデータカタログを更新します。： response = glue_client.update_table(DatabaseName=database, TableInput= json.loads(TableInputFromLLM) ) print(f"Table {table} metadata updated!") 以下のスクリーンショットは、 persons テーブルのメタデータとその説明を示しています。 以下のスクリーンショットは、テーブルのメタデータとしてカラムの説明を表示しています。 以上でデータカタログに保存されている技術的なメタデータが充実したので、さらに外部ドキュメントを追加して説明を改善します。 RAG で外部のドキュメントを追加しメタデータの説明を改善する このステップでは、より正確なメタデータを生成するために外部のドキュメントを追加します。私たちのデータセットのドキュメントは HTML としてオンラインで見つけられます。HTML の読み込みには LangChain HTML ローダーを使います。： from langchain_community.document_loaders import AsyncHtmlLoader # We will use an HTML Community loader to load the external documentation stored on HTLM urls = ["http://www.popoloproject.com/specs/person.html", "http://docs.everypolitician.org/data_structure.html",'http://www.popoloproject.com/specs/organization.html','http://www.popoloproject.com/specs/membership.html','http://www.popoloproject.com/specs/area.html'] loader = AsyncHtmlLoader(urls) docs = loader.load() ドキュメントをダウンロードしたら、チャンクに分割します。： text_splitter = CharacterTextSplitter( separator='\n', chunk_size=1000, chunk_overlap=200, ) split_docs = text_splitter.split_documents(docs) embedding_model = BedrockEmbeddings( client=bedrock_client, model_id=embeddings_model_id ) 次に、ドキュメントをベクトル化してローカルに保存し、類似検索を実行します。本番ワークロードでは Amazon OpenSearch Service のようなベクトルストアのマネージドサービスや、 Amazon Bedrock Knowledge Bases のような RAG アーキテクチャを実装するためのフルマネージドソリューションを使用することができます。 vs = FAISS.from_documents(split_docs, embedding_model) search_results = vs.similarity_search( 'What standards are used in the dataset?', k=2 ) print(search_results[0].page_content) 次に、より正確なメタデータを生成するためにカタログ情報をドキュメントとともに含めます。： from operator import itemgetter from langchain_core.callbacks import BaseCallbackHandler from typing import Dict, List, Any class PromptHandler(BaseCallbackHandler): def on_llm_start( self, serialized: Dict[str, Any], prompts: List[str], **kwargs: Any) -> Any: output = "\n".join(prompts) print(output) system = "You are a helpful assistant. You do not generate any harmful content." # specify a user message user_msg_rag = """ Here is the guidance document you should reference when answering the user: <documentation>{context}</documentation> I'd like to you create metadata descriptions for the table called {table} in your AWS Glue data catalog. Please follow these steps: 1. Review the data catalog carefully. 2. Use all the data catalog information and the documentation to generate the table description. 3. If a column is a primary key or foreign key to another table mention it in the description. 4. In your response, reply with the entire JSON object for the table {table} 5. Remove the DatabaseName, CreatedBy, IsRegisteredWithLakeFormation, CatalogId,VersionId,IsMultiDialectView,CreateTime, UpdateTime. 6. Write the table description in the Description attribute. Ensure you use any relevant information from the <documentation> 7. List all the table columns under the attribute "StorageDescriptor" and then the attribute Columns. Add Location, InputFormat, and SerdeInfo 8. For each column in the StorageDescriptor, add the attribute "Comment". If a table uses a composite primary key, then the order of a given column in a table’s primary key is listed in parentheses following the column name. 9. Your response must be a valid JSON object. 10. Ensure that the data is accurately represented and properly formatted within the JSON structure. The resulting JSON table should provide a clear, structured overview of the information presented in the original text. 11. If you cannot think of an accurate description of a column, say 'not available' <glue_data_catalog> {data_catalog} </glue_data_catalog> Here is some additional information about the database in <notes></notes> tags. <notes> Typically foreign key columns consist of the name of the table plus the id suffix <notes> """ messages = [ ("system", system), ("user", user_msg_rag), ] prompt = ChatPromptTemplate.from_messages(messages) # Retrieve and Generate retriever = vs.as_retriever( search_type="similarity", search_kwargs={"k": 3}, ) chain = ( {"context": itemgetter("table")| retriever, "data_catalog": itemgetter("data_catalog"), "table": itemgetter("table")} | prompt | model | StrOutputParser() ) TableInputFromLLM = chain.invoke({"data_catalog":glue_data_catalog, "table":table}) print(TableInputFromLLM) 以下は LLM からのレスポンスです。： { "Name": "persons", "Description": "This table contains information about individual persons, including their names, identifiers, contact details, and other personal information. It follows the Popolo data specification for representing persons involved in government and organizations. The 'person_id' column relates a person to an organization through the 'memberships' table.", "StorageDescriptor": { "Columns": [ { "Name": "family_name", "Type": "string", "Comment": "The family or last name of the person." }, { "Name": "name", "Type": "string", "Comment": "The full name of the person." }, { "Name": "links", "Type": "array<struct<note:string,url:string>>", "Comment": "An array of links related to the person, with a note and URL for each link." }, { "Name": "gender", "Type": "string", "Comment": "The gender of the person." }, { "Name": "image", "Type": "string", "Comment": "A URL or path to an image representing the person." }, { "Name": "identifiers", "Type": "array<struct<scheme:string,identifier:string>>", "Comment": "An array of identifiers for the person, with a scheme and identifier value for each." }, { "Name": "other_names", "Type": "array<struct<lang:string,note:string,name:string>>", "Comment": "An array of other names the person may be known by, with language, note, and name for each." }, { "Name": "sort_name", "Type": "string", "Comment": "The name to be used for sorting or alphabetical ordering of the person." }, { "Name": "images", "Type": "array<struct<url:string>>", "Comment": "An array of URLs or paths to additional images representing the person." }, { "Name": "given_name", "Type": "string", "Comment": "The given or first name of the person." }, { "Name": "birth_date", "Type": "string", "Comment": "The date of birth of the person." }, { "Name": "id", "Type": "string", "Comment": "The unique identifier for the person. This is likely a primary key." }, { "Name": "contact_details", "Type": "array<struct<type:string,value:string>>", "Comment": "An array of contact details for the person, with a type and value for each." }, { "Name": "death_date", "Type": "string", "Comment": "The date of death of the person, if applicable." } ], "Location": "s3:<your-s3-bucket>/persons/", "InputFormat": "org.apache.hadoop.mapred.TextInputFormat", "SerdeInfo": { "SerializationLibrary": "org.openx.data.jsonserde.JsonSerDe" } } } 1つ目のアプローチと同様に、出力が AWS Glue API に適合しているか確認するための検証をすることができます。 新しいメタデータでデータカタログを更新する これでメタデータが生成されたので、データカタログを更新できます。 response = glue_client.update_table(DatabaseName=database, TableInput= json.loads(TableInputFromLLM) ) print(f"Table {table} metadata updated!") 生成された技術的なメタデータを確認します。 persons テーブルのデータカタログに新しいバージョンが表示されているはずです。スキーマのバージョンには AWS Glue コンソールからアクセスできます。 今回の persons テーブルの説明を確認してください。その前に入力された説明と若干異なっているはずです。 コンテキスト内学習によるテーブルの説明 – “This table contains information about persons, including their names, identifiers, contact details, birth and death dates, and associated images and links. The ‘id’ column is the primary key for this table.” RAG によるテーブルの説明 – “This table contains information about individual persons, including their names, identifiers, contact details, and other personal information. It follows the Popolo data specification for representing persons involved in government and organizations. The ‘person_id’ column relates a person to an organization through the ‘memberships’ table.” LLM は、LLM に提供されたドキュメントの一部である Popolo の仕様に対する知識を表現しました。 クリーンアップ 以上、本記事でご紹介したステップが完了しましたら無駄なコストがかからないように、 ノートブック の Clean Up で提供されたコードを使って忘れずにリソースを削除してください。 まとめ 本記事では生成 AI、特に Amazon Bedrock FM を使用しデータカタログを動的メタデータで充実させ、既存のデータ資産のデータディスカバリーとデータ理解を向上させる方法を探りました。私たちが実演した2つのアプローチ、コンテキスト内学習と RAG は、このソリューションの柔軟性と汎用性を示しています。コンテキスト内学習はテーブル数が少ない AWS Glue データベースに対して有効であるのに対し、RAGアプローチはより正確で詳細なメタデータを生成するために外部ドキュメントを使用するため、より大規模で複雑なデータランドスケープに適しています。このソリューションを導入することで新たなレベルのデータインテリジェンスを開放し、組織におけるより多くのデータに基づいた意思決定、データドリブンなイノベーションの推進、そしてデータの価値を最大限に引き出すことができます。この記事でご紹介したリソースや推奨事項をご確認いただき、データマネジメントの実践を強化することにお役立ていただければ幸いです。 著者について Manos Samatas は、AWS のデータ・AI 部門のプリンシパルソリューションアーキテクトです。英国の政府、非営利団体、教育、ヘルスケアのお客様とデータおよび AI のプロジェクトに携わり、AWS を使ったソリューションの構築を支援しています。ロンドン在住。余暇は読書、スポーツ観戦、ビデオゲーム、友人との交流を楽しんでいます。     Anastasia Tzeveleka は、AWS の GenAI/ML のシニアスペシャリストソリューションアーキテクトです。彼女は仕事の一環として EMEA 全域のお客様が AWS サービスを使用して FM (基盤モデル)を構築し、スケーラブルな生成 AI と機械学習のソリューションを作成することを支援しています。

10 月 31 日、 Amazon Aurora の新しいサーバーレス水平スケーリング (シャーディング) 機能である Amazon Aurora PostgreSQL Limitless Database の一般提供についてお知らせします。Aurora PostgreSQL Limitless Database を使用すると、データベースワークロードを複数の Aurora ライターインスタンスに分散しながら、単一データベースとして使用する機能を維持することで、書き込みスループットとストレージに関する既存の Aurora の制限を超えて拡張できます。 AWS re:Invent 2023 で Aurora PostgreSQL Limitless Database をプレビューしたとき、DB シャードグループ内の複数のデータベースノード (ワークロードに基づいてスケールするルーターまたはシャード) で構成される 2 層アーキテクチャを使用していることを説明しました。 ルーター – クライアントからの SQL 接続を受け入れ、SQL コマンドをシャードに送信し、システム全体の一貫性を維持して、結果をクライアントに返すノード。 シャード – テーブルのサブセットとデータの完全なコピーを保存し、ルーターからのクエリを受け付けるノード。 データを含むテーブルには、シャード、参照、標準の 3 種類があります。 シャードテーブル – このテーブルは複数のシャードに分散されています。データは、シャードキーと呼ばれるテーブル内の指定された列の値に基づいてシャード間で分割されます。アプリケーションの中で最も大きく、最も入出力量の多いテーブルをスケールするときに役立ちます。 参照テーブル – このテーブルでは、すべてのシャードのデータを完全にコピーするため、不要なデータ移動がなくなり、結合クエリをより高速に実行できます。製品カタログや郵便番号など、あまり変更されない参照データによく使用されます。 標準テーブル – これらのテーブルは通常の Aurora PostgreSQL テーブルに似ています。標準テーブルはすべて 1 つのシャードにまとめられるため、不必要なデータ移動がなくなり、結合クエリをより高速に実行できます。標準テーブルから、シャードテーブルと参照テーブルを作成できます。 DB シャードグループ、シャードテーブル、参照テーブルを作成したら、大量のデータを Aurora PostgreSQL Limitless Database にロードし、標準の PostgreSQL クエリを使用して、それらのテーブルのデータをクエリできます。詳細については、Amazon Aurora ユーザーガイドの「 Limitless Database アーキテクチャ 」を参照してください。 Aurora PostgreSQL Limitless Database の利用開始 AWS マネジメントコンソール と AWS コマンドラインインターフェイス (AWS CLI) から始めて、Aurora PostgreSQL Limitless Database を使用する新しい DB クラスターを作成し、クラスターに DB シャードグループを追加して、データをクエリすることができます。 1.Aurora PostgreSQL Limitless Database クラスターの作成 Amazon Relational Database Service (Amazon RDS) コンソール を開き、 [データベースを作成] を選択します。 エンジンオプション では、 [Aurora (PostgreSQL 互換)] と [Aurora PostgreSQL と Limitless Database (PostgreSQL 16.4 互換)] を選択します。 Aurora Limitless Database には、DB シャードグループの名前と、すべてのルーターとシャードの Aurora キャパシティユニット (ACU) によって測定された最小容量および最大容量の値を入力します。DB シャードグループ内のルーターとシャードの初期数は、この最大容量によって決まります。Aurora PostgreSQL Limitless Database は、現在の使用率が低すぎて負荷を処理できない場合、ノードをより高い容量にスケールアップします。現在の容量が必要以上に多い場合は、ノードをより低い容量にスケールダウンします。 DB シャードグループのデプロイ では、DB シャードグループのスタンバイ (コンピューティングの冗長性なし) を作成するか、別のアベイラビリティーゾーンに 1 つのコンピューティングスタンバイを作成するか、2 つの異なるアベイラビリティーゾーンに 2 つのコンピューティングスタンバイを作成するかを選択します。 残りの DB 設定を好きなように設定し、 [データベースを作成] を選択します。DB シャードグループが作成されると、 データベース ページに表示されます。 DB シャードグループの接続、再起動、削除、または容量の変更、シャードの分割、DB シャードグループへのルーターの追加を実行できます。詳細については、Amazon Aurora ユーザーガイドの「 DB シャードグループの使用 」を参照してください。 2.Aurora PostgreSQL Limitless Database テーブルの作成 前述のように、Aurora PostgreSQL Limitless Database には、シャード、参照、標準の 3 つのテーブルタイプがあります。標準テーブルをシャードテーブルまたは参照テーブルに変換して、既存の標準テーブルを分散または複製したり、新しいシャードテーブルや参照テーブルを作成したりできます。 テーブル作成モードを設定すると、変数を使用してシャードテーブルと参照テーブルを作成できます。作成したテーブルは、別のモードを設定するまでこのモードを使用します。次の例は、これらの変数を使用してシャードテーブルと参照テーブルを作成する方法を示しています。 例えば、 item_id 列と item_cat 列で構成されるシャードキーを使用して、 items という名前のシャードテーブルを作成するとします。 SET rds_aurora.limitless_create_table_mode='sharded'; SET rds_aurora.limitless_create_table_shard_key='{"item_id", "item_cat"}'; CREATE TABLE items(item_id int, item_cat varchar, val int, item text); 次に、 item_id 列と item_cat 列で構成されるシャードキーを使用した item_description という名前のシャードテーブルを作成し、それを items テーブルとコロケーションします。 SET rds_aurora.limitless_create_table_collocate_with='items'; CREATE TABLE item_description(item_id int, item_cat varchar, color_id int, ...); colors という名前の参照テーブルを作成することもできます。 SET rds_aurora.limitless_create_table_mode='reference'; CREATE TABLE colors(color_id int primary key, color varchar); Limitless Database テーブルに関する情報は、 rds_aurora.limitless_tables ビューを使用して確認できます。このビューには、テーブルとそのタイプに関する情報が含まれています。 postgres_limitless=> SELECT * FROM rds_aurora.limitless_tables; table_gid | local_oid | schema_name | table_name | table_status | table_type | distribution_key -----------+-----------+-------------+-------------+--------------+-------------+------------------ 1 | 18797 | public | items | active | sharded | HASH (item_id, item_cat) 2 | 18641 | public | colors | active | reference | (2 rows) 標準テーブルをシャードテーブルまたは参照テーブルに変換できます。変換中、データは標準テーブルから分散テーブルに移動され、ソース標準テーブルは削除されます。詳細については、Amazon Aurora ユーザーガイドの「 標準テーブルから無制限テーブルへの変換 」を参照してください。 3.Aurora PostgreSQL Limitless Database テーブルのクエリ Aurora PostgreSQL Limitless Database は、クエリ用の PostgreSQL 構文と互換性があります。 psql または PostgreSQL で動作するその他の接続ユーティリティを使用して、Limitless Database をクエリできます。テーブルをクエリする前に、 COPY コマンドまたは データロードユーティリティ を使用して、 Aurora Limitless Database テーブルにデータをロード できます。 クエリを実行するには、「 Aurora Limitless Database DB クラスターへの接続 」に示されているように、クラスターエンドポイントに接続します。PostgreSQL SELECT クエリはすべて、クライアントがクエリを送信する先のルーターと、データが保存されているシャードで実行されます。 高度な並列処理を実現するために、Aurora PostgreSQL Limitless Database では、シングルシャードクエリと分散クエリという 2 つのクエリ方法を使用しています。これらの方法で、クエリがシングルシャードか分散クエリかを判断し、それに応じてクエリを処理します。 シングルシャードクエリ – クエリに必要なすべてのデータが 1 つのシャードに存在するクエリ。生成された結果セットを含め、すべての操作を 1 つのシャードで実行できます。ルーターのクエリプランナーがこのようなクエリに遭遇すると、プランナーは対応するシャードに SQL クエリ全体を送信します。 分散クエリ – ルーターと複数のシャードで実行されるクエリ。クエリーはルーターの 1 つで受信されます。ルーターは、参加しているシャードに送信される分散トランザクションを作成して管理します。シャードはルーターから提供されたコンテキストを使用してローカルトランザクションを作成し、クエリが実行されます。 シングルシャードクエリの例では、次のパラメータを使用して EXPLAIN コマンドの出力を設定します。 postgres_limitless=> SET rds_aurora.limitless_explain_options = shard_plans, single_shard_optimization; SET postgres_limitless=> EXPLAIN SELECT * FROM items WHERE item_id = 25; QUERY PLAN -------------------------------------------------------------- Foreign Scan (cost=100.00..101.00 rows=100 width=0) Remote Plans from Shard postgres_s4: Index Scan using items_ts00287_id_idx on items_ts00287 items_fs00003 (cost=0.14..8.16 rows=1 width=15) Index Cond: (id = 25) Single Shard Optimized (5 rows) EXPLAIN コマンドの詳細については、PostgreSQL ドキュメントの「 EXPLAIN 」を参照してください。 分散クエリの例として、 Book と Pen という名前の新しい項目を、 items テーブルに挿入できます。 postgres_limitless=> INSERT INTO items(item_name)VALUES ('Book'),('Pen') これにより、2 つのシャードで分散トランザクションが行われます。クエリを実行すると、ルーターはスナップショット時間を設定し、そのステートメントを Book と Pen を所有するシャードに渡します。ルーターは両方のシャードにわたってアトミックコミットを調整し、その結果をクライアントに返します。 Aurora PostgreSQL Limitless Database 全体の PostgreSQL ログ内のクエリをトレースして関連付けるツールである分散クエリトレーシングを使用できます。詳細については、Amazon Aurora ユーザーガイドの「 Limitless Database のクエリ 」を参照してください。 一部の SQL コマンドはサポートされていません。詳細については、Amazon Aurora ユーザーガイドの「 Aurora Limitless Database リファレンス 」を参照してください。 知っておくべきこと この機能について知っておきたい事柄には、次のようなものがあります。 コンピューティング – DB クラスターあたり 1 つの DB シャードグループのみを持つことができ、DB シャードグループの最大容量を 16～6,144 ACU に設定できます。6,144 個以上の ACU が必要な場合は、お問い合わせください。ルーターとシャードの初期数は、DB シャードグループの作成時に設定した最大容量によって決まります。DB シャードグループの最大容量を変更しても、ルーターとシャードの数は変わりません。詳細については、Amazon Aurora ユーザーガイドの「 ルーターとシャードの数の表 」を参照してください。 ストレージ – Aurora PostgreSQL Limitless Database は Amazon Aurora I/O-Optimized DB クラスターストレージ設定のみをサポートします。各シャードの最大容量は 128 TiB です。参照テーブルでの DB シャードグループ全体のサイズ制限は 32 TiB です。データをクリーンアップしてストレージスペースを再利用するには、PostgreSQL の バキュームユーティリティ を使用できます。 モニタリング – Amazon CloudWatch 、 Amazon CloudWatch Logs 、または Performance Insights を使用して、Aurora PostgreSQL Limitless Database をモニタリングできます。また、モニタリングや診断に使用できる Aurora PostgreSQL Limitless Database 用の 新しい統計関数やビュー 、 待機イベント もあります。 今すぐご利用いただけます Amazon Aurora PostgreSQL Limitless Database は、PostgreSQL 16.4 との互換性を使用して、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (香港)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の AWS リージョンでご利用いただけるようになりました。 Amazon Aurora コンソール で Aurora PostgreSQL Limitless Database を試してみてください。詳細については、「 Amazon Aurora ユーザーガイド 」をご覧ください。また、 AWS re:Post for Amazon Aurora 宛てに、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

Amazon VPC Lattice は、リリース以来、複雑なネットワーキングタスクを効率化してきました。その結果、最新のマルチサービスアプリケーションの構築および接続方法に関する私の見方が変わりました。同僚の Danilo は、VPC Lattice の一般提供の開始を発表した 記事 で次のように書いています。 「VPC Lattice を使用して、インスタンス、コンテナ、サーバーレスコンピューティングを一貫してサポートすることで、アプリケーションロジックに集中し、生産性とデプロイの柔軟性を向上させることができます」 11 月 18 日、Amazon VPC Lattice の Amazon Elastic Container Service (Amazon ECS) 向けの組み込みサポートを発表しました。この新しい組み込み統合により、中間ロードバランサーを必要とせずに、Amazon ECS サービスを VPC Lattice ターゲットグループに直接関連付けることができるようになりました。 Amazon ECS サービスの作成中に Amazon VPC Lattice 統合を見つける方法を簡単に説明します。 Amazon VPC Lattice と Amazon ECS の統合は、サービス内の ECS タスクの IP アドレスを、VPC Lattice ターゲットグループのターゲットとして登録および登録解除することによって機能します。サービスのために ECS タスクが起動されると、Amazon ECS はそれらのタスクを VPC Lattice ターゲットグループに自動的に登録します。 さらに、ECS タスクが VPC Lattice ヘルスチェックに失敗した場合、Amazon ECS はタスクを自動的に置き換えます。また、タスクが終了またはスケールダウンした場合、そのタスクはターゲットグループから削除されます。 Amazon VPC Lattice 統合の使用 この新しい統合の使用方法を説明します。次のデモでは、ECS サービスとして実行されるシンプルなアプリケーションサーバーをデプロイし、VPC Lattice との統合を設定します。その後、Amazon ECS で追加のロードバランサーを設定することなく、VPC Lattice ドメイン名に接続することによってアプリケーションサーバーをテストします。 この統合を開始する前に、ターゲットを VPC Lattice に登録および登録解除するために必要な許可が Amazon ECS に付与されていることを確認する必要があります。詳細については、「 Amazon ECS インフラストラクチャ IAM ロール 」ドキュメントページにあくせすしてください。 VPC Lattice との統合を使用するには、少なくとも 1 つのコンテナと 1 つのポートマッピングを含むタスク定義を定義する必要があります。これは私のタスク定義の例です。 { "containerDefinitions": [ { "name": "webserver", "image": "public.ecr.aws/ecs-sample-image/amazon-ecs-sample:latest", "cpu": 0, "portMappings": [ { "name": "web-80-tcp", "containerPort": 80, "hostPort": 80, "protocol": "tcp", "appProtocol": "http" } ], ... *redacted for brevity* } その後、ECS クラスターに移動して、 [作成] を選択します。 次に、タスク定義を選択し、サービス名を割り当てる必要があります。 VPC Lattice 統合セクションで、 [VPC Lattice をオンにする] を選択して、VPC Lattice のターゲットグループの設定を開始します。VPC Lattice を使用するため、ロードバランサーを指定する必要はありません。デフォルトでは、VPC Lattice はラウンドロビンルーティングアルゴリズムを使用して、正常なターゲットにリクエストをルーティングします。 これで、VPC Lattice で ECS サービスの統合の定義を開始できます。まず、Amazon ECS のインフラストラクチャロールを選択します。それから、サービスを実行する仮想プライベートクラウド (VPC) を選択する必要があります。その後、トラフィックを受信する [ターゲット グループ] を定義する必要があります。VPC Lattice 統合を使用してサービスの設定が完了したら、このサービスを作成します。 数分後、ECS サービスの準備が整います。サービスに移動し、 [設定とネットワーキング] を選択します。 [VPC Lattice] セクションまで下方向にスクロールすると、作成された VPC Lattice ターゲットグループが表示されます。 このターゲットグループの詳細を取得するために、ターゲットグループ名を選択すると、VPC Lattice ターゲットグループページにリダイレクトされます。ここで、Amazon ECS が実行中のタスクの IP アドレスを正常に登録したことを確認できます。 ここで、VPC Lattice サービスとサービスネットワークを作成する必要があります。個人的な好みとして、VPC Lattice サービスを作成し、後で VPC Lattice サービスネットワークに関連付ける方法を常に採用しています。そのため、今回はその方法で進めましょう。 [VPC Lattice] セクションで [サービス] を選択し、 [サービスを作成] を選択します。 VPC Lattice サービスを作成するために必要なすべての詳細を入力し、 [次へ] を選択します。 その後、リスナーを追加し、 [リスナーのデフォルトアクション] の [ターゲットグループに転送] で、新しく作成したターゲットグループを選択します。 次のページでは、後で VPC Lattice サービスネットワークを作成するため、このステップをスキップして [次へ] を選択し、設定を確認してサービスを作成します。 VPC Lattice サービスが作成されたので、次は VPC Lattice サービスネットワークを作成します。 [VPC Lattice] セクションの [サービスネットワーク] に移動して、 [サービスネットワークを作成] を選択します。 まず、VPC Lattice サービスネットワーク名を入力します。 その後、 [サービスの関連付け] ページで、作成したサービスを選択します。 このサービスネットワークを VPC とセキュリティグループに関連付けます。 このデモをシンプルにするために、 [認証 タイプ] で [なし ] を設定しました。ただし、 IAM を使用して VPC Lattice へのアクセスを管理する方法 についてお読みいただくことを強くお勧めします。その後、 [サービスネットワークを作成] を選択します。 この段階で、この統合のセットアップはすべて完了しています。これで、VPC Lattice サービスネットワークが、VPC Lattice サービスと VPC に関連付けられました。 すべてのセットアップが完了したら、VPC Lattice サービスページから [ドメイン名] をコピーします。 その後、サービスにアクセスするには、同じ VPC 内のインスタンスにログインし、VPC Lattice のドメイン名を使用してサービスを呼び出します。 [ec2-user@ ~]$ curl http://service-a-XYZ.XYZ.vpc-lattice-svcs.XYZ.on.aws "Hello there! I'm Amazon ECS." なお、Amazon ECS ワークロードへのトラフィックを受信していない場合は、「 Control traffic in VPC Lattice using security groups 」ドキュメントページの説明に従ってセキュリティグループを確認してください。 私は個人的に、この統合に期待を寄せています。なぜなら、この統合は、アプリケーションアーキテクチャを合理化し、システム全体の信頼性を高めながら、さまざまな可能性を解き放つものだからです。現在、 すべての AWS コンピューティングタイプが VPC Lattice で本質的にサポートされているため 、すべての ECS クラスター、AWS アカウント、および VPC でサービスを統合できます。 知っておくべきこと ここで、重要な点をいくつかご紹介します。 利用可能なリージョン – Amazon VPC Lattice と Amazon ECS の統合 は、Amazon VPC Lattice と Amazon ECS が利用可能な AWS リージョンでご利用いただけるようになりました。 互換性 – この統合は、 Amazon Elastic Compute Cloud (Amazon EC2) や AWS Fargate を含む、すべての ECS 起動タイプをサポートしています。 料金 – 標準の VPC Lattice および Amazon ECS の料金が適用されます。この統合の使用には追加料金はかかりません。 Amazon VPC Lattice のモニタリング – Amazon VPC Lattice サービスネットワーク、サービス、ターゲットグループ、および VPC の接続をモニタリングする方法については、「VPC Lattice ユーザーガイド」の「 Monitoring Amazon VPC Lattice 」をご覧ください。 今すぐ Amazon VPC Lattice のこの新しい機能を試して、Amazon ECS で実行されているコンテナアプリケーション通信を合理化できるかどうかをご確認ください。 構築がうまくいきますように。 – Donnie Prakoso 原文は こちら です。