7月31日、 AWS Clean Rooms での Amazon Marketing Cloud (AMC) の一般提供について お知らせします 。これにより、広告主は自社シグナルを使用して、Amazon Ads 独自のシグナルと連携できるようになります。このコラボレーションにより、広告主は差別化されたインサイトの生成、新しいオーディエンスの発見、広告キャンペーンの計画立案、アクティベーション、測定ユースケースの作成を実現できるようになります。また、基盤となるシグナルを AWS アカウントの外に移動させる必要はありません。AMC on AWS Clean Rooms を使用すると、簡単にデータの準備、オーディエンスのマッチングと作成、カスタムインサイトを使用した Amazon Ads でのより関連性の高い広告キャンペーンのアクティブ化、広告費用対効果の測定を行うことができます。これらはすべて、現在利用できる最も安全なクラウドコンピューティング環境で実現できます。 広告主は新しいオーディエンスにリーチし、関連性の高いマーケティングキャンペーンを実施して、顧客との関わりを深めようと絶えず努力しています。しかし広告とマーケティングの環境は、シグナルの喪失や断片化など、根本的な変化を遂げつつあります。そのため、広告主とパートナーは連携して、さまざまなアプリケーションに保存されているシグナルを使用し、広告キャンペーンをパーソナライズする必要があります。しかし、企業が互いに協力してインサイトを収集するには通常、シグナルのコピーをパートナーと共有しなければなりません。これは多くの場合、組織のデータガバナンス、セキュリティとプライバシー、IT、法務チームのポリシーに沿っていません。その結果、多くの企業が自社シグナルの価値を最大限に引き出し、キャンペーンの計画、活性化、測定結果を改善する機会を逃しています。 AMC on AWS Clean Rooms を使用すると、広告主は Amazon Ads でより簡単かつスケーラブルに、自社シグナルを使用できるようになります。これには、イベントレベルのシグナル間のコラボレーションや、独自オーディエンスのモデリングなどが含まれます。そのため、基盤となるシグナルをクラウド環境外に移動させることなく、メディアプランニング、アクティベーション、成果を向上させることができます。 AMC on AWS Clean Rooms の前提条件 (環境設定) AWS Clean Rooms で AMC の使用を開始するには、AWS アカウントと、 Amazon Simple Storage Service (Amazon S3) バケットにオープンデータ形式 (CSV、Parquet、または Iceberg) で保存されたユーザー人口およびイベントレベルのデータを含むデータセットが必要です。次のステップは、 Amazon Ads チームにメールを送信 して、AMC インスタンスの作成をリクエストすることです。インスタンスが作成されると、Amazon Ads チームは AWS Clean Rooms コラボレーションを作成し、広告主をコラボレーションに招待します。 仕組み 1.AWS Clean Rooms コラボレーションに参加して、ID 名前空間を作成します。 2.テーブルを設定し、AMC コラボレーションに関連付けます。 3.ID マッピングワークフローを実行して、ID マッピングテーブルを作成および入力します。 4.AMC でクエリを実行します。 チュートリアル 1. AWS Clean Rooms コラボレーションに参加して、ID 名前空間を作成します。 広告主は、自分の AWS アカウントでメンバーシップを作成することで、コラボレーションの招待を受け入れます。コラボレーションが開始されると、AWS Clean Rooms コンソールにアクセスし、コラボレーションの作成時に生成された AWS Entity Resolution ID 名前空間 を選択して、そのデータを AWS Clean Rooms でのマッチングとコラボレーションに使用するプロセスを開始します。次に、 AWS Glue テーブルと関連するスキーママッピングを指定し、コラボレーションと同じ AWS リージョン内にある S3 バケットを選択して、処理中にデータを一時保存します。最後に、AWS Glue から入力されたデータを読み取り、広告主に代わって Amazon S3 に書き込む権限を付与します。 次のスクリーンショットに示す AirportLink コラボレーションでは、広告主 (メンバー AirportLink2) がメンバー AirportLink1 から送信されたコラボレーション招待を受け入れています。 2. テーブルを設定し、AMC コラボレーションに関連付けます。 コラボレーションに参加した後、広告主は購入データに基づいて構成済みのテーブルを作成し、カスタム分析ルールを追加して、設定されたテーブルをコラボレーションに関連付けます。 コラボレーション内で、広告主はコラボレーション分析ルールを設定し、関連するテーブルで実行されたクエリの結果を誰が受け取ることができるかを管理します。 3. ID マッピングワークフローを実行して、ID マッピングテーブルを作成および入力します。 ID 名前空間がコラボレーションに関連付けられたので、Amazon Ads チームは AWS Clean Rooms コンソールで ID マッピングテーブルを作成します。このステップでは、広告主 (ソース) と Amazon Ads チーム (ターゲット) の両方が、ID 名前空間リソースをコラボレーションに関連付ける必要があります。Amazon Ads は、マッピングと設定の方法の提供、ID マッピングテーブルに名前を付けるためのクエリ作成に向けた詳細の追加、AWS Clean Rooms の代替としての ID マッピングワークフロージョブの実行および追跡を行う権限の提供を行います。最後に、Amazon Ads チームは [作成して入力] を選択してマッピングワークフローを開始し、ステップ 2 で示したルールに基づいてマッチングされた、一般的なユーザーコホートをキャプチャした ID マッピングテーブルを生成します。 4. AMC でクエリを実行します。 広告主はテンプレートを使用するか、SQL クエリを作成して分析を実行し、クエリ結果を取得して、さらなる洞察を得ることができます。SQL クエリは次の方法で実行できます。 AMC データと広告主のデータを使用して SQL クエリを実行し、集計分析を使用して、結果を広告主の S3 バケットに返します。クエリの例としては、「私のメーリングリストに登録している顧客のうち、私が掲載している Amazon の広告を見た顧客は何人いますか?」などです。 SQL クエリを実行して広告主のデータにオーディエンスを作成するか、Amazon Ads の S3 バケットに結果を返す AMC シグナルを使用してオーバーラップします。クエリの例としては、「広告キャンペーンでターゲットに設定するオーディエンスを生成してください」などです。 Amazon Ads が設定済みのモデルを提供し、広告主がシードオーディエンスを提供する、 AWS Clean Rooms ML の類似モデリングジョブを実行 します。結果のセグメント (ユーザー広告 ID のリスト) が Amazon Ads に送信されます。 クエリを実行した後、広告主は AMC の [オーディエンス] タブに移動し、ルールベースのオーディエンスまたは類似のオーディエンスを使用して、オーディエンスを作成できます。オーディエンスクエリの出力は、 Amazon Demand Side Platform (DSP) に直接送信されます。次の表は、オーディエンスを作成する際に使用できるオプションを示しています。 目的 方法 あらかじめ用意されたオーディエンステンプレートを使用する ドロップダウンリストから [インストラクショナルクエリを使用して作成] を選択する カスタムオーディエンスクエリを作成する ドロップダウンリストから [新しいクエリを作成] を選択する 新しいクエリを作成する際、広告主は 名前 、 説明 、 日付調整 などのさまざまなオプションを設定します。また、次の 2 種類のオーディエンスタイプのいずれかを選択することもできます。 – ルールベースのオーディエンス – オーディエンスクエリに基づいてオーディエンスを作成します。 – 類似オーディエンス – オーディエンスクエリ由来のシードオーディエンス出力に基づいて、機械学習 (ML) ベースのオーディエンスを作成します。 今すぐご利用いただけます AMC on AWS Clean Rooms は米国東部 (バージニア北部) リージョンでご利用いただけます。今後の最新情報については、 詳細なリージョンリスト をご確認ください。AMC on AWS Clean Rooms の詳細については、AWS ドキュメントをご覧ください。 Amazon Ads チームにメールを送信して使用を開始 し、 AWS re:Post for AWS Clean Rooms にフィードバックを送るか、通常の AWS サポートの連絡先を通じてご感想をお聞かせください。 – Veliswa 原文は こちら です。

AWS の大規模なお客様にそれぞれの課題や懸念事項について話すとき、会話のトピックがマルチクラウドに変わることがよくあります。意図的であれ偶然であれ、これらのお客様は複数のクラウドプロバイダーからのサービスの利用を選択することがあります。時には、今もオンプレミスでホストされているアプリケーションやサービスと併せて利用することもあります。チームや部門レベルでボトムアップ的な選択を早急に行い、トップダウンの指示がないまま複数のベンダーからのクラウドサービスを選択するというケースもありました。また、別の組織を買収、または合併してから、よく似たマルチベンダー状況を発見したというお客様もいました。 その経緯にかかわらず、これらのお客様からは、クラウドリソースとオンプレミスリソースの多種多様なポートフォリオの監視と管理を簡素化して一元化したいという意向を伺っています。この「複数」の状況に期限があり、最終的には業務を一か所に統合する計画がある場合もあれば、お客様が多種多様なポートフォリオを保持することを計画している場合もあります。 AWS とマルチクラウド AWS の目標は、お客様がアーキテクチャ面でどのような選択をしたかを問わず、お客様に成功をもたらすことです。この記事では、AWS のアプローチの概要を説明し、AWS のお客様が長年にわたって使用してきた機能をいくつか紹介するとともに、最近のサービス発表と、お客様の成功に役立つガイダンスを提供するために AWS が作成したコンテンツに関する最新情報を提供したいと思います。 AWS のアプローチは、既存の運用機能と管理機能を拡張して、マルチクラウド環境やハイブリッド環境で機能するようにすることです。AWS は既存の機能を拡張するため、トレーニング、開発、スクリプト、およびランブックへの投資がそのまま維持されるだけでなく、他の (AWS 以外の) リソースにも適用されることから、実際には価値がより一層高くなります。例えば、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、オンプレミスで実行されているサーバー、および他のクラウドプロバイダーから提供されたサーバーへのパッチ適用と更新には、同一のサービス ( AWS Systems Manager ) を使用できます。同様に、 Amazon CloudWatch を使用して、これらすべての環境内のアプリケーション、コンピューティングリソース、およびその他のクラウドリソースを監視することもできます。これらは、AWS がお客様のためにそのアプローチを実践する方法の 2 つの例です。 ハイブリッドおよびマルチクラウド向けの AWS ソリューション ページには、新しい機能の追加に対する AWS の拡張ベースのアプローチに関する追加の例とともに、 Phillips 66 や Deutsche Börse など、新しい機能を導入したお客様からの成功事例も掲載されています。 AWS だけでの運用、またはマルチクラウド環境やハイブリッド環境での運用のどちらを選択するかにかかわらず、AWS を導入する主な理由の 1 つは、ワークロードの革新、構築、デプロイ、モニタリングを可能にする、AWS の幅広いサービスの選択肢です。最近ローンチされた、AWS 外に移行したい場合のための インターネットへの無料データ転送 (DTO) からもわかるように、AWS ではお客様が取るアプローチを問わず、お客様が成功を収めるための支援に全力を注いでいます。 AWS のアプローチを説明し、主なマルチクラウドサービスを紹介したところで、今度は最新のマルチクラウド機能とハイブリッド機能をいくつか見てみましょう。 マルチクラウドローンチ 2023 年初頭を皮切りに、AWS では既存の AWS サービスに 18 個の新しいマルチクラウド機能をローンチしてきました。そのうちの 15 個はデータおよび分析機能、1 つはセキュリティ機能、残り 2 つはアイデンティティ機能です。これらのローンチの多くは、それぞれのサービスの既存マルチクラウド機能を強化するものです。 AWS DataSync – このサービスは、ストレージサービス間でデータを転送します。Google Cloud Storage、Azure Files、おおよび Azure Blob Storage に対する既存のサポートに加えて、さらに 5 つのクラウドサービスプロバイダーとストレージサービスのサポートを追加しました。これには、 Oracle Cloud Storage と DigitalOcean Spaces ( 全リスト ) が含まれます。このサービスの詳細については、「 What is AWS DataSync? 」をお読みください。使用を開始するには、ソースロケーションを作成します。 AWS Glue – このデータ統合サービスは、あらゆる規模のデータのすべてを検出、準備、および統合するために役立ちます。このサービスを使用して、クラウドデータベースや分析サービスを含めた 80 を超えるさまざまなデータソースに接続できます。2023 年 10 月、AWS は Amazon Simple Storage Service (Amazon S3) と、 Azure Blob Storage または Azure Data Lake Storage ( 全リスト ) との間でのデータの双方向移動を可能にする 追加の新しいコネクタ を導入しました。また、 AWS Glue for Apache Spark 向けの 6 つのデータベースコネクタもローンチしました。これには、 Teradata 、 SAP HANA 、 Azure SQL 、 Azure Cosmos DB 、 Vertica 、および MongoDB (全リスト) が含まれます。AWS Glue の詳細については、「 What is AWS Glue? 」をお読みください。使用を開始するには、視覚的なジョブフローを作成します。 Amazon Athena – このサーバーレス分析サービスは、インタラクティブな SQL クエリを使用して、データのコピーや変換を行うことなく、ペタバイト規模のデータをその格納場所 (他のクラウドデータストアを含めた 25 を超える外部データソース ) で分析できるようにします。昨年は、Google Cloud Storage 内のデータをクエリできるようにする新しいデータソースコネクタを追加しました。Amazon Athena の詳細については、「 What is Amazon Athena? 」をお読みください。 Amazon AppFlow – Amazon AppFlow で利用できるコネクタを使用して、 Google BigQuery のデータと分析を活用することができます。Amazon AppFlow の使用を開始するには、フローを作成し、データソースを設定します。 Amazon Security Lake – このサービスは、セキュリティ体制に関するより完全な組織全体のビューの実現に役立ち、AWS 環境、SaaS プロバイダー、オンプレミス環境、クラウドソース (Azure および GCP) からのセキュリティデータを専用のデータレイクに一元化します。Security Lake は、昨年に 一般提供 が開始され、現在は Open Cybersecurity Schema Framework (OCSF) 標準をサポートする 80 を超えるソース ( 全リスト ) からのセキュリティデータの収集と分析をサポートしています。 AWS Secrets Manager – このサービスは、データベースの認証情報や API キーなどのシークレットを一元的に管理します。シークレットはセキュアな方法で暗号化され、一元的に監査することが可能です。また、ディザスタリカバリやマルチリージョンアプリケーションに役立つレプリケーションもサポートされています。AWS は昨年、 オンプレミスまたはマルチクラウドワークロード内のシークレットの保存と管理に AWS Secrets Manager を使用 できることを発表しました。詳細については、「 What is AWS Secrets Manager? 」をお読みください。 AWS Identity and Access Management (IAM) – AWS IAM アイデンティティセンターが、 Google Workspace からの自動ユーザープロビジョニング をサポートするようになりました。この統合は、管理者が複数のアカウント全体での AWS アクセス管理を簡素化するために役立つと同時に、サインインにはユーザーが使い慣れた Google Workspace エクスペリエンスを維持します。 Amazon CloudWatch – このサービスは、アプリケーション、AWS、オンプレミス、およびマルチクラウドといったあらゆるタイプのメトリクスをクエリし、視覚化して、アラームを発行できるようにします。re:Invent 2023 では、 ハイブリッド、マルチクラウド、およびオンプレミスのメトリクスの統合 に対し、さらなるサポートを追加しました。この新しい機能は、 Amazon Managed Service for Prometheus 、汎用 Prometheus 、 Amazon OpenSearch Service 、 Amazon RDS for MySQL 、 Amazon RDS for PostgreSQL 、 Amazon Simple Storage Service (Amazon S3) に保存されている CSV ファイル、および Microsoft Azure Monitor からデータを取得するコネクタを選択して設定することを可能にします。 マルチクラウドに関するコンテンツとガイダンス AWS の最近のマルチクラウドローンチについて理解できたので、次は私の同僚が作成したブログ記事やその他のコンテンツを見ていきましょう。 まず、ブログ記事をいくつか紹介します。 マルチクラウド戦略を策定するための実証済みのプラクティス Amazon CloudWatch で Azure と AWS のワークロードを同時に監視する Get custom data into Amazon Security Lake through ingesting Azure activity logs Set up AWS Private Certificate Authority to issue certificates for use with IAM Roles Anywhere データ転送を簡素化: Amazon AppFlow を利用した Google BigQuery から Amazon S3 への転送 Use AWS Secrets Manager to store and manage secrets in on-premises or multicloud workloads Enable external pipeline deployments to AWS Cloud by using IAM Roles Anywhere Train and deploy ML models in a multicloud environment using Amazon SageMaker How to view Azure costs using Amazon QuickSight Using AWS CloudFormation and AWS Cloud Development Kit to provision multicloud resources How to copy data from Azure Blob Storage to Amazon S3 using code AWS Systems Manager と Amazon CloudWatch を使用したハイブリッドおよびマルチクラウド環境の監視 Multicloud data lake analytics with Amazon Athena 次に、 AWS re:Invent 2023 からの最も人気のあるマルチクラウド動画をいくつか紹介します。 Centralize your operations (COP320) Centralize hybrid & multicloud management with AWS (COP324) Strategies for navigating multicloud decisions and difficulties (ENT217) 最後に、 ハイブリッドおよびマルチクラウド向けの AWS ソリューション ページもぜひブックマークしておいてください。 いつでもお手伝いします マルチクラウド環境で実行しており、簡素化と一元化を行う準備が整っているという場合は、AWS のアカウントマネージャー (AM)、またはテクニカルアカウントマネージャー (TAM) までご連絡ください。どちらのマネージャーも喜んでお手伝いします! – Jeff ; 原文は こちら です。

今日の急速に変化するビジネス環境において、優れた顧客体験を提供することは最重要課題です。顧客は、すべての接点で、シームレスでパーソナライズされたサポートを期待しており、これらの進化する要求に応えるため、企業は新しい方法を常に探し求めています。 AI を活用したクラウドコンタクトセンターソリューションである Amazon Connect は、業界を問わず企業が最新の技術の進歩を活用し、エージェントを支援し、顧客データから洞察を抽出し、エンドユーザーを喜ばせるオムニチャネルサポートを提供できるよう支援しています。このブログでは、 Customer Contact Week (CCW) で発表されたものを含め Amazon Connect の最新の機能、そしてお客様サービスの提供を革新的に変えている先進的な企業の事例をご紹介します。 より統合された体験によりコンタクトセンターのエージェントを支援 優れた顧客体験の基盤は、コンタクトセンターのエージェントの手にかかっています。そのため、Amazon Connect では、エージェントの体験をより直感的で効率的かつ力強いものにすることに注力しています。最近の主なアップデートの一つは、 Amazon Connect エージェントワークスペースのビジュアルの刷新 です。このリデザインにより、エージェントの利便性と応答性が向上し、 Amazon Q in Connect による生成 AI を活用したエージェント支援、ステップバイステップのガイダンス、 Amazon Connect Cases によるケース管理、 Amazon Connect Customer Profiles による顧客の統合ビューなどの機能にスムーズにアクセスできるようになります。 さらに、Amazon Connect では現在、 カスタムビルドまたは内部アプリケーションをエージェントワークスペースに直接統合 することができます。これにより、顧客がサポートを求めた際に、エージェントは問題を解決するために必要なすべての関連情報やツールにアクセスできるようになります。また、 Cloudscape Design System コンポーネントを使用することで、エージェントワークスペースと一貫した外観と操作性を持つサードパーティアプリケーションを簡単に構築し、埋め込むことができます。サードパーティアプリケーションのサポートについての詳細は、 サードパーティーアプリケーションのエージェントワークスペースとの統合 をご覧ください。 ヘルスケア業界のスタッフィングおよび人材ソリューションの主要プロバイダーである Experis も、Amazon Connect の統合されたエージェント体験のメリットを実際に体験しています。 Experis では、Amazon Connect Cases を使用してエージェント体験を一本化し、顧客レポートを簡素化する機会があると考えました。以前は、エージェントが Amazon Connect で対応を管理し、別のチケット発行システムを使用して患者の問題に対処する必要がありました。Amazon Connect Cases に移行することを決め、現在ではエージェントが Amazon Connect のエージェントワークスペースで、音声、チャット、メールなどのチャネルを横断して対応とケースを一元的に管理できるようになりました。パートナーの支援を得て、100 人を超えるエージェントに対して 90 日以内に本番環境でソリューションを立ち上げ、さらにエージェントと機能を追加し続けています」と、Experis Health Solutions の VP Managed Services である Josh Kitchen 氏は述べています。「例えば、エージェントは今やエージェントワークスペースでナレッジを検索し、より迅速に解決策を見つけることができます。Amazon Connect によりエージェントの生産性が 15% 向上し、手作業による報告作業が不要になったため、当社は高成長市場でより競争力を持てるようになりました。当社は、効率性と患者の満足度を常に向上させるべく努力しており、Amazon Connect を長期的なイノベーションパートナーと位置付けています。 コンタクトセンターのデータから洞察を得る 今日のデータ主導の世界において、コンタクトセンターは顧客体験の継続的な改善を推進するために活用すべき貴重な洞察の宝庫といえます。Amazon Connect は、このデータの価値を引き出すことをこれまでになく簡単にする、 Amazon Connect の分析データレイクを一般提供開始 しました。Amazon Connect はすでに、エージェント、スーパーバイザー、コンタクトセンターマネージャーのニーズを満たすための、 リアルタイムと履歴のレポートオプション を提供しています。新しい分析データレイクは、コンタクトセンターマネージャーがカスタムレポートを通じてより深い洞察を得ることを可能にし、CRM や ERP などの他のソースからの情報とコンタクトセンターデータを簡単に組み合わせることもできます。サードパーティのソースに対するクエリは、複雑なデータパイプラインではなく、 ゼロ ETL を使用します。これにより、高度な分析がサポートされ、コンタクトセンターマネージャーが隠れたトレンドと最適化の機会を発見することができます。 コンタクトセンターのスーパーバイザーにとってのもう 1 つの画期的な進歩は、Amazon Connect 内の最新の生成 AI 機能です。 Amazon Connect Contact Lens は、自動的に顧客との会話の文脈を含んだ要約を提供 し、スーパーバイザーの品質やコンプライアンスのレビューにかかる時間を節約します。さらに、Amazon Connect は、 エージェントの評価について生成 AI を活用した推奨事項 (プレビュー) を管理者に提供し、より深い行動の洞察とその評価の根拠を提供します。 2024 年 6 月 1 日から 2024 年 8 月 31 日まで、初めて Amazon Connect Contact Lens を利用されるお客様向けに、本番環境での利用に先駆けて、音声の会話分析機能 (例: 通話の書き起こし、感情分析、生成 AI による会話の要約) を無料で評価する限定の機会が設けられています。新しい Contact Lens 会話分析機能では、最初の 2 か月間、月間 100,000 分の音声通話に対して無料トライアルを利用できます。詳細については、 Amazon Connect 価格ページ の「分析、インサイト、最適化」タブを参照してください。 オーストラリアの主要な健康保険事業者である nib Group は、Amazon Connect 分析の力を活用して、より良い顧客成果を上げることができるようになりました。月に 10 万件を超える顧客の通話とチャットがあり、より良い成果につながる洞察を発見することが課題でした。今では、nib は Amazon Connect のコンタクトセンター分析を使用して、顧客との会話の奥深くに隠れたトレンドを探り、より良い顧客サービスを提供できるようになりました。 オムニチャネルかつセルフサービスの顧客サポートを提供 顧客は、音声、チャット、SMS、その他のデジタルチャネルなど、自分の好みのチャネルで企業とやりとりすることを求めています。Amazon Connect は、シームレスな オムニチャネル体験 を実現することで、この需要に応えています。 Amazon Connect は、 Apple Messages for Business との標準統合を提供しています。顧客は、iPhone、iPad、Mac デバイスの Apple Messages アプリケーションを使って簡単に企業と対話できます。セキュアなメッセージング、Apple Pay 統合、リッチメディアサポートにより、企業はパーソナライズされたサポート、予約のスケジューリング、効率的な取引処理を提供できます。これにより、コミュニケーションが迅速、便利、そして魅力的になり、顧客満足度とロイヤリティが向上します。 2023 年に、顧客の問題を自動的に特定し、エージェントが取るべき適切なアクションを推奨する、エージェントワークスペース用の Step-by-step ガイドを発表しました。最近では、 Step-by-step ガイドを使ってエンドユーザー向けのガイド付きチャット体験を提供する機能 をリリースし、インタラクティブなチャット体験の作成を容易にしました。カルーセル、ドロップダウンリスト、フォームなどの動的コンポーネントを設定することで、企業は顧客が問題をより早く解決でき、エージェントにエスカレーションする必要性を減らすことができます。チャットがエスカレーションされた場合、エージェントはセルフサービスインタラクションの内容を確認し、ガイド付きワークフローを継続できるため、よりパーソナライズされた効率的なサポートを提供できます。 英国の主要な銀行 NatWest Group は、Amazon Connect のセルフサービス機能を活用して顧客体験を革新しています。データ主導の洞察力を活用してセルフサービスを革新し、業務を効率化し、Amazon Connect によってエージェントがより多くの問い合わせを、顧客との最初のコンタクトで解決できるようになった方法をご覧ください。 ヨーロッパ最大の航空会社 Ryanair は、大規模に従業員およびお客様の優れた体験を提供するため、AWS の革新的な AI ソリューションを活用しました。Amazon Connect が顧客サービスセンターを合理化し、自動化の強化によりシームレスなサポートを提供した方法をご覧ください。 私たちと始めましょう 今日の競争の激しい環境下では、優れた顧客体験を提供できる企業が成功します。そして、Amazon Connect の最新の機能により、さまざまな業界の組織が、エージェントを支援し、データから洞察を得て、シームレスなオムニチャネルサポートを提供しています。つまり、顧客を喜ばせ、ビジネスの成功を促進するのです。 Amazon Connect を使い始めたい、顧客体験をさらに高いレベルに引き上げる方法を探索したい場合は、以下の追加リソースをご覧ください。 2024年6月3日から6日まで開催される Customer Contact Week にご参加ですか？ AWS ブースにお立ち寄りいただくか、イベントに参加する AWS の専門家とミーティングをご予約ください ※訳注: 本イベントはすでに終了しておりミーティングは申し込みできません Amazon Connect の最新情報をご覧になりたいですか ? AWS の新着情報 をご覧ください Amazon Connect の最新機能や、AWS のリーダー、Amazon Connect のお客様、業界の専門家からの情報を聞きたいですか? AWS Contact Center Day のオンデマンドセッション をご覧ください 今後の Amazon Connect イベントをご確認になりたいですか ? Customer Experience Workshops & Events をご覧の上、開催予定のイベントにご登録ください Amazon Connect で顧客サービス体験を変革したいですか ? お問い合わせ ください 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

OpenSearch は、オープンソースの分散型検索エンジンで、e コマース検索、エンタープライズ検索 (コンテンツ管理検索、ドキュメント検索、ナレッジ管理検索など)、サイト検索、アプリケーション検索、セマンティック検索など、幅広いユースケースに適しています。また、インタラクティブなログ分析、リアルタイムアプリケーションモニタリング、セキュリティ分析などを実行できる分析スイートでもあります。Apache Solr と同様に、OpenSearch はドキュメントセットに対する検索を提供します。OpenSearch にはデータの取り込みと分析を行う機能も含まれています。 Amazon OpenSearch Service は、AWS クラウドで OpenSearch のデプロイ、スケーリング、モニタリングを行うことができるフルマネージドサービスです。 多くの組織が Apache Solr ベースの検索ソリューションを OpenSearch に移行しています。主な要因は、総所有コストの低減、スケーラビリティ、安定性、発展した取り込みコネクタ ( Data Prepper , Fluent Bit , OpenSearch Ingestion など)、Zookeeper のような外部クラスタマネージャーの排除、レポーティングの強化、OpenSearch Dashboards によるリッチな可視化などです。 Solr から OpenSearch への移行は、検索ソリューションを OpenSearch 向けに最適化するために完全なリファクタリングを行うアプローチをお勧めします。Solr と OpenSearch はどちらも Apache Lucene をコアのインデックス作成とクエリ処理に使用していますが、システムの特性は異なります。計画を立て、実証実験を行うことで、OpenSearch から最良の結果を得ることができます。このブログ記事では、Solr から OpenSearch への移行に関わる戦略的考慮事項と手順について詳しく説明します。 主な違い Solr と OpenSearch Service は、Apache Lucene を通じて提供される基本的な機能を共有しています。しかし、用語や機能には以下のような主な違いがあります。 コレクションとインデックス: OpenSearch では、コレクションはインデックスと呼ばれます。 シャードとレプリカ: Solr と OpenSearch の両方で、シャードとレプリカという用語が使用されています。 API 駆動のインタラクション: OpenSearch ではすべてのインタラクションが API 駆動であり、手動でのファイル変更や Zookeeper の設定が不要です。OpenSearch インデックスを作成する際、マッピング (スキーマに相当) と設定 (solrconfig に相当) をインデックス作成 API 呼び出しの一部として定義します。 基本的な事項を説明したところで、4 つの主要コンポーネントについて、 Solr から OpenSearch に移行する方法を詳しく見ていきましょう。 コレクションからインデックスへ Solr のコレクションは、OpenSearch ではインデックスと呼ばれます。Solr のコレクションと同様に、OpenSearch のインデックスにもシャードとレプリカがあります。 シャードとレプリカの概念は両方の検索エンジンで類似していますが、この移行を機に、より良いシャーディング戦略を採用することができます。 シャード戦略のベストプラクティス に従って、OpenSearch のシャード、レプリカ、インデックスのサイズを決定してください。 移行の一環として、データモデルを再考してください。データモデルを検討することで、検索のレイテンシーとスループットを大幅に改善する可能性を見出すことができます。データモデリングが不適切だと、検索パフォーマンスの問題だけでなく、他の領域にも影響が及びます。例えば、特定の機能を実装するための効果的なクエリの実装が難しくなる場合があります。このような場合、解決策としてデータモデルの修正が求められる可能性があります。 違い : Solr では、プライマリシャードとレプリカシャードを同じノードに配置できます。OpenSearch では、プライマリとレプリカは同じノードに配置できません。さらに、OpenSearch Service は ゾーンアウェアネス により、シャードを自動的に異なる Availability Zone (データセンター) に分散させることで、回復力を高めることが可能です。 OpenSearch と Solr のレプリカの概念は異なります。OpenSearch では、 number_of_shards を使用してプライマリシャード数を定義し、データのパーティショニングを決定します。その後、 number_of_replicas を使用してレプリカ数を設定します。各レプリカはすべてのプライマリシャードのコピーです。つまり、 number_of_shards を 5 に設定し、 number_of_replicas を 1 に設定すると、10 個のシャード (5 個のプライマリシャードと 5 個のレプリカシャード) が生成されます。Solr で replicationFactor=1 を設定すると、データの 1 つのコピー (単一のプライマリのみ) が生成されます。 例えば、以下は Solr に対して、 test という名前のコレクションを 1 つのシャードと 0 個のレプリカで作成しています。 http://localhost:8983/solr/admin/collections? _=action=CREATE &maxShardsPerNode=2 &name=test &numShards=1 &replicationFactor=1 &wt=json 以下は、OpenSearch に対して、 test という名前のインデックスを 5 つのシャードと 1 つのレプリカで作成しています。 PUT test { "settings": { "number_of_shards": 5, "number_of_replicas": 1 } } スキーマからマッピングへ Solr の schema.xml または managed-schema には、フィールド定義、動的フィールド、コピーフィールドのすべてが、フィールドタイプ (テキストアナライザー、トークナイザー、またはフィルター) とともに含まれています。スキーマの管理には schema API を使用します。または、スキーマレスモードで実行することもできます。 OpenSearch には 動的マッピング があり、Solr のスキーマレスモードのように動作します。データを取り込むために事前にインデックスを作成する必要はありません。新しいインデックス名でデータをインデクシングすることで、OpenSearch マネージドサービスのデフォルト設定 (例: “number_of_shards”: 5, “number_of_replicas”: 1) と、インデクシングされたデータに基づくマッピング (動的マッピング) でインデックスが作成されます。 しかしながら、事前に定義された 厳密なマッピング を選択することを強くお勧めします。OpenSearch は、フィールドで最初に見た値に基づいてスキーマを設定します。実際には文字列フィールドであるものに、数値が最初の値として現れると、OpenSearch は不適切にそのフィールドを数値 (例えば整数) としてマッピングします。その後、そのフィールドに文字列値でインデクシングを試みると、不適切なマッピング例外で失敗します。データの内容とフィールドタイプを把握しているのであれば、マッピングを直接設定することにメリットがあります。 ヒント : サンプルデータを用いてインデックス作成を行い、初期マッピングを生成してください。その後、マッピングを修正・整理して実際のインデックスを正確に定義することを検討してください。このアプローチは、マッピングを最初から手動で構築するのを避けるのに役立ちます。 Observability ワークロードの場合は、 Simple Schema for Observability の使用を検討してください。Simple Schema for Observability (ss4o としても知られる) は、共通の統一された observability スキーマに準拠するための標準です。このスキーマを導入することで、Observability ツールはデータを取り込み、自動的に抽出し、集約してカスタムダッシュボードを作成し、システムをより高いレベルで理解しやすくします。 多くのフィールドタイプ (データタイプ)、トークナイザー、フィルターは Solr と OpenSearch の両方で同じです。どちらも Lucene の Java 検索ライブラリをコアとして使用しているからです。 例を見てみましょう。 <!-- Solr schema.xml スニペット --> <field name="id" type="string" indexed="true" stored="true" required="true" multiValued="false" /> <field name="name" type="string" indexed="true" stored="true" multiValued="true"/> <field name="address" type="text_general" indexed="true" stored="true"/> <field name="user_token" type="string" indexed="false" stored="true"/> <field name="age" type="pint" indexed="true" stored="true"/> <field name="last_modified" type="pdate" indexed="true" stored="true"/> <field name="city" type="text_general" indexed="true" stored="true"/> <uniqueKey>id</uniqueKey> <copyField source="name" dest="text"/> <copyField source="address" dest="text"/> <fieldType name="string" class="solr.StrField" sortMissingLast="true" /> <fieldType name="pint" class="solr.IntPointField" docValues="true"/> <fieldType name="pdate" class="solr.DatePointField" docValues="true"/> <fieldType name="text_general" class="solr.TextField" positionIncrementGap="100"> <analyzer type="index"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.ASCIIFoldingFilterFactory" preserveOriginal="false" /> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> <analyzer type="query"> <tokenizer class="solr.StandardTokenizerFactory"/> <filter class="solr.ASCIIFoldingFilterFactory" preserveOriginal="false" /> <filter class="solr.LowerCaseFilterFactory"/> </analyzer> </fieldType> PUT index_from_solr { "settings": { "analysis": { "analyzer": { "text_general": { "type": "custom", "tokenizer": "standard", "filter": [ "lowercase", "asciifolding" ] } } } }, "mappings": { "properties": { "name": { "type": "keyword", "copy_to": "text" }, "address": { "type": "text", "analyzer": "text_general" }, "user_token": { "type": "keyword", "index": false }, "age": { "type": "integer" }, "last_modified": { "type": "date" }, "city": { "type": "text", "analyzer": "text_general" }, "text": { "type": "text", "analyzer": "text_general" } } } } Solr と比較して OpenSearch で注目すべき点は以下の通りです。 _id は常に一意です。また、明示的に定義する必要はありません。指定されない場合は自動で採番されるためです。 マルチバリューを明示的に有効にする必要はありません。OpenSearch は、各フィールドに 0 個以上の値を含むことができます。 マッピングとアナライザーはインデックス作成時に定義されます。新しいフィールドを追加したり、特定のマッピングパラメータを後で更新したりすることはできますが、フィールドを削除することはできません。 ReIndex API でこの問題を解決できます。Reindex API を使用して、あるインデックスから別のインデックスにデータをインデクシング可能です。 デフォルトでは、アナライザーはインデックス時とクエリ時の両方に適用されます。一部のケースでは、クエリ時に異なるアナライザーを指定することができます。これにより、インデックスマッピングで定義されたアナライザーがオーバーライドされます。 インデックステンプレート も、事前定義されたマッピングと設定で新しいインデックスを初期化する優れた方法です。例えば、ログデータ といった任意の時系列データを継続的にインデクシングする場合、インデックステンプレートを定義して、すべてのインデックスが同じ数のシャードとレプリカを持つようにすることができます。また、動的マッピング制御やコンポーネントテンプレートにも使用できます。 検索ソリューションを最適化する機会を探してください。例えば、分析の結果、city フィールドが検索ではなくフィルタリングにのみ使用されていることが判明した場合、不必要なテキスト処理を削減するために、そのフィールドタイプを text から keyword に変更することを検討してください。もう一つの最適化として、user_token フィールドが表示目的でのみ使用される場合、 doc_values を無効にすることが考えられます。doc_values は text データタイプではデフォルトで無効になっています。 SolrConfig から OpenSearch の設定へ Solr では、solrconfig.xml がコレクション設定を担っています。インデックスの場所、フォーマット、キャッシング、コーデックファクトリ、サーキットブレーカー、コミット、トランザクションログから、スロークエリ設定、リクエストハンドラ、update processing chain に至るまで、あらゆる種類の設定が含まれています。 例を見てみましょう。 <codecFactory class="solr.SchemaCodecFactory"> <str name="compressionMode">`BEST_COMPRESSION`</str> </codecFactory> <autoCommit> <maxTime>${solr.autoCommit.maxTime:15000}</maxTime> <openSearcher>false</openSearcher> </autoCommit> <autoSoftCommit> <maxTime>${solr.autoSoftCommit.maxTime:-1}</maxTime> </autoSoftCommit> <slowQueryThresholdMillis>1000</slowQueryThresholdMillis> <maxBooleanClauses>${solr.max.booleanClauses:2048}</maxBooleanClauses> <requestHandler name="/query" class="solr.SearchHandler"> <lst name="defaults"> <str name="echoParams">explicit</str> <str name="wt">json</str> <str name="indent">true</str> <str name="df">text</str> </lst> </requestHandler> <searchComponent name="spellcheck" class="solr.SpellCheckComponent"/> <searchComponent name="suggest" class="solr.SuggestComponent"/> <searchComponent name="elevator" class="solr.QueryElevationComponent"/> <searchComponent class="solr.HighlightComponent" name="highlight"/> <queryResponseWriter name="json" class="solr.JSONResponseWriter"/> <queryResponseWriter name="velocity" class="solr.VelocityResponseWriter" startup="lazy"/> <queryResponseWriter name="xslt" class="solr.XSLTResponseWriter"/> <updateRequestProcessorChain name="script"/> Solr と比較して OpenSearch で注目すべき点は以下の通りです。 OpenSearch と Solr ともに、デフォルトのコーデックは BEST_SPEED (LZ4 圧縮アルゴリズム) です。また BEST_COMPRESSION を代替コーデックとして提供しています。さらに OpenSearch は zstd と zstd_no_dict を提供しています。各圧縮コーデックの ベンチマーク も活用できます。 ニアリアルタイム検索の場合、 refresh_interval を設定する必要があります。デフォルトは 1 秒で、ほとんどのユースケースで十分です。特にバッチインデックス作成の場合、インデックス作成の速度とスループットを向上させるために、refresh_interval を 30 秒または 60 秒に増やすことをお勧めします。 Max boolean clause は静的設定で、 indices.query.bool.max_clause_count 設定を使用してノードレベルで設定されます。 明示的な requestHandler は必要ありません。すべての検索は _search または _msearch エンドポイントを使用します。デフォルト値を持つ requestHandler を使用することに慣れている場合は、 検索テンプレート を使用できます。 /sql requestHandler の使用に慣れている場合、OpenSearch でも SQL 構文 を使用してクエリを実行できます。 Piped Processing Language も提供しています。 Spellcheck ( Did-you-mean )、 ハイライト はすべてクエリ実行時に利用可能です。明示的に検索コンポーネントを定義する必要はありません。 ほとんどの API レスポンスは JSON フォーマットで固定されています。 CAT API が唯一の例外です。Solr で Velocity や XSLT が使用されている場合、アプリケーション層で管理する必要があります。CAT API は JSON、YAML、または CBOR 形式で応答します。 updateRequestProcessorChain については、OpenSearch は インジェストパイプライン を提供しています。インデクシング前にデータの強化や変換を行うことができます。複数のプロセッサステージをチェーンしてデータ変換のパイプラインを形成できます。プロセッサには GrokProcessor、CSVParser、JSONProcessor、KeyValue、Rename、Split、HTMLStrip、Drop、ScriptProcessor などがあります。ただし、OpenSearch の外部でデータ変換を行うことを強くお勧めします。 OpenSearch Ingestion では、データ変換のための適切なフレームワークと様々な組み込みフィルターを提供しています。OpenSearch Ingestion は Data Prepper をベースに構成されているサーバーサイドのデータコレクターで、下流の分析と可視化のためにデータのフィルタリング、強化、変換、正規化、集約を行うことができます。 OpenSearch は、インジェストパイプラインに加えて、検索時の操作に特化した 検索パイプライン を提供しています。検索パイプラインを使用することで、OpenSearch 内で検索クエリと検索結果を簡単に変換できます。現在利用可能な検索プロセッサには、フィルタークエリ、ニューラルクエリエンリッチャー、正規化、フィールド名変更、スクリプトプロセッサ、パーソナライズ検索ランキングなどがあり、今後さらに追加される予定です。 以下の画像は、refresh_interval と slowlog の設定方法を示しています。また、他の可能な設定も示しています。 スローログは以下の画像のように設定できますが、クエリフェーズとフェッチフェーズに対して別々のしきい値を設定することもできます。 設定の移行前に、現在の検索システムの運用経験とベストプラクティスに基づき、設定の調整余地があるかを評価してください。例えば、前述の例では、1 秒のスローログのしきい値はログ記録にとって負荷が高い可能性があるため、再検討する必要があるかもしれません。同様に、max.booleanClauses も見直しにより削減される可能性があります。 違い : 一部の設定は、インデックスレベルではなく、クラスターレベルまたはノードレベルで行われます。これには、 最大ブール句 、 サーキットブレーカー設定 、 キャッシュ設定 などが含まれます。 クエリの書き換え クエリの書き換えについては、それだけでブログ記事を書けるほどの内容がありますが、ここでは OpenSearch Dashboards で利用可能なオートコンプリート機能を紹介します。これはクエリ作成を容易にするのに役立ちます。 Solr Admin UI と同様に、OpenSearch にも OpenSearch Dashboards と呼ばれる UI があります。OpenSearch Dashboards を使用して、OpenSearch クラスターを管理およびスケーリングできます。さらに、OpenSearch データの可視化、データの探索、可観測性のモニタリング、クエリの実行などの機能も提供しています。Solr UI のクエリタブに相当するものは、OpenSearch Dashboard の Dev Tools です。Dev Tools は開発環境で、OpenSearch Dashboards 環境のセットアップ、クエリの実行、データの探索、問題のデバッグなどを行うことができます。 では、以下を実行するクエリを構築してみましょう。 インデックス内で “shirt” または “shoe” を検索する。 ユニークな顧客数を見つけるためのファセットクエリを作成する。ファセットクエリは OpenSearch では 集約クエリ と呼ばれます。また、aggs クエリとしても知られています。 Solr クエリは以下のようになります。 http://localhost:8983/solr/solr_sample_data_ecommerce/select?q=shirt OR shoe &facet=true &facet.field=customer_id &facet.limit=-1 &facet.mincount=1 &json.facet={ unique_customer_count:"unique(customer_id)" } 以下の画像は、上記の Solr クエリを OpenSearch クエリ DSL に書き換える方法を示しています。 結論 OpenSearch は、エンタープライズ検索、サイト検索、アプリケーション検索、e コマース検索、セマンティック検索、可観測性 (ログ可観測性、セキュリティ分析 (SIEM)、異常検出、トレース分析)、分析など、幅広いユースケースをカバーしています。Solr から OpenSearch への移行は一般的なパターンになりつつあります。このブログ記事は、そのような移行に関するガイダンスを求めるチームのための出発点となることを考えて作成されています。 OpenSearch Playground で OpenSearch をお試しいただくことが可能です。AWS にて、 OpenSearch のマネージドサービスである Amazon OpenSearch Service を使い始めることもできます。 著者について Aswath Srinivasan iは、現在ドイツのミュンヘンを拠点とする Amazon Web Services のシニア検索エンジンアーキテクトです。様々な検索技術で 17 年以上の経験を持つ Aswath は、現在 OpenSearch に焦点を当てています。検索とオープンソースの愛好家であり、顧客や検索コミュニティの検索問題解決を支援しています。 Jon Handler カリフォルニア州パロアルトを拠点とする Amazon Web Services のシニアプリンシパルソリューションアーキテクトです。Jon は OpenSearch と Amazon OpenSearch Service と密接に連携し、AWS クラウドに移行したい検索およびログ分析ワークロードを持つ幅広い顧客に支援とガイダンスを提供しています。AWS に入社する前の Jon のソフトウェア開発者としてのキャリアには、大規模な e コマース検索エンジンの 4 年間のコーディングが含まれています。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号および博士号を取得しています。 本記事はソリューションアーキテクトの榎本が翻訳いたしました。原文は こちら です。

2024 年 5 月および 6 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 AWS Cost Explorer AWS Cost Explorer は、コストと使用状況を表示および分析するために使用できるサービスです。本セッションでは、AWS Cost Explorer の概要、基本的な利用方法およびユースケースについてご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Cost Explorer の概要・基本的な利用方法を知りたい方 サービスやメンバーアカウント別などのコストと利用量を分析したい方 FinOps やコスト最適化を推進したい方 本 BlackBelt で学習できること AWS Cost Explorer の概要、基本的な利用方法について学んでいただけます。 また、いくつかユースケースについても紹介します 実際の分析例などについても学んでいただけます。 スピーカー 加須屋 悠己 テクニカルアカウントマネージャー なぜ今コンテナなのか 新規サービスの8割近くがコンテナやサーバレスで構築されていることをご存知でしょうか？コンテナはセキュリティガードレールと、CI/CD と合わせて生産性を向上させるツールです。 AWS におけるコンテナ関連サービスは多岐にわたります。それらの概要を把握できるように紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 序論、あるいは直接 AWS は触らないが技術的方向を知っておきたい人 本 BlackBelt で学習できること なぜいまコンテナなのかと問われれば、生産性を上げるための必然的な選択と答えます。 コンテナ、セキュリティガードレール、CI/CD は、現代のソフトウェア開発とデプロイメントにおいて相互に補完し合う重要な要素です。コンテナ技術を活用することで、ガードレールを CI/CD パイプラインに統合し、セキュリティリスクを軽減しながら効率的で一貫性のあるデプロイメントを実現できます。これにより、組織は高品質でセキュアなソフトウェアを迅速に提供することが可能になります。 AWS コンテナ全体を少し詳しくなれる BlackBelt です。 スピーカー 荒木 靖宏 ソリューションアーキテクト Amazon Bedrock Overview 【Amazon Bedrock Series #01】 皆さん、生成 AI を活用していますか？ Amazon Bedrock は、基盤モデルを活用した生成 AI アプリケーションを簡単に構築できる AWS サービスです。Amazon Bedrock シリーズ第１回となる本動画では、Amazon Bedrock の概要や主な機能の全体像をご紹介します。 資料（ PDF ） | 動画（ YouTube ） 対象者 これから生成 AI の活用を始めたいと考えている方 Amazon Bedrock のことを初めて学ぶ方 Amazon Bedrock がもつ各種機能について知りたい方 本 BlackBelt で学習できること 生成 AI に関する AWS サービスである Amazon Bedrock について、概要や特徴、主要な各種機能など、サービスの全体像を掴んでいただくことができます。 スピーカー 森下 裕介 ソリューションアーキテクト Amazon Connect Forecasting, capacity planning, and scheduling dive deep Amazon Connect Forecasting, capacity planning, and scheduling を使用する事で、コンタクトセンターにおける人員の過剰配置を最小限に抑えながら運用上の目標を達成するために、問い合わせの量と到達率を予測し、予測結果から必要な人員配置を割り出し、適切な数のエージェントに日々のシフトを割り当てることができます。このセミナーでは、Amazon Connect 　 Forecasting, capacity planning, and scheduling の機能毎の設定ポイントやユースケースをデモを交えて解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect ご利用中のエンドユーザー/パートナーの方 これから Amazon Connect のご利用を検討されている方 コンタクトセンターにおける、予測、人員配置などの WFM（ワークフォースマネジメント）業務を行う担当者 本 BlackBelt で学習できること Amazon Connect の Forecasting, capacity planning, and scheduling を使用したコンタクトセンターのワークフォースマネジメント機能の理解 スピーカー 梅田 裕義 シニア Connect スペシャリスト ソリューション アーキテクト 今後の Black Belt オンラインセミナー また、現時点で予定されている今後の Black Belt オンラインセミナーについては以下の通りです。 公開月 タイトル 登壇予定者 2024-07 Amazon Location Service ソリューションアーキテクト 稲田大陸 2024-07 Amazon ElastiCache Serverless ソリューションアーキテクト 堤 勇人 2024-07 SaaS 成功のための基礎戦略と AWS 活用法　〜 SaaS 入門編〜 ソリューションアーキテクト 前田 進吾 2024-08 Amazon RDS ソリューションアーキテクト 塚井知之 2024-08 AWS Cloud Map 入門 ソリューションアーキテクト 多田 慎也 2024-08 AWS Application Migration Service (AWS MGN) プライベートネットワーク経由でサーバを Amazon EC2 へ移行する方法 ソリューションアーキテクト 鈴木 槙将 2024-08 Amazon ECS 入門 ソリューションアーキテクト 吉田 英史 2024-08 AWS Cost Anomaly Detection テクニカルアカウントマネージャー 加須屋悠己  

モノのインターネット (IoT) は、日々テラバイトの情報を流す数十億のデバイスがあり、前例のないほどのデータを生成しています。IoT データから貴重な分析情報を得ようとする企業や組織にに対して、AWS が強力な分析サービスを提供しています。 AWS IoT Analytics は、IoT 分析に着手する多くの顧客にとって出発点となります。このフルマネージドサービスでは、IoT データの高速な収集、処理、保存、分析が可能です。AWS IoT Analytics では、データを時系列データストアに保存する前に、フィルタリング、変換、加工を行うことができます。また、このサービスには Amazon QuickSight との統合が含まれており、ダッシュボードやビジュアライゼーションを作成して IoT データを効果的に把握できます。ただし、IoT の展開が進み、データ量が増加するにつれ、顧客はさらなる拡張性と柔軟性を必要とするようになり、分析要件の進化に対応できなくなります。このような場合に、Amazon Kinesis、Amazon S3、Amazon Athena などのサービスが役立ちます。これらのサービスは、それぞれ大規模なストリーミングデータ収集、耐久性と経済性に優れた保存、高速な SQL ベースのクエリ実行を目的として設計されています。 この投稿では、IoT 分析ワークロードを AWS IoT Analytics から Kinesis、S3、Athena に移行することのメリットを探ります。この移行により、最も要求の高い IoT ユースケースに対応できるよう分析ワークロードを拡張することが可能になることと、移行の計画と実行に役立つステップバイステップのガイドについて説明します。 移行オプション AWS IoT Analytics から移行することを検討する場合、この移行のメリットと理由を理解することが重要です。以下の表は、既存の AWS IoT Analytics 機能に対応する代替オプションを示しています。 AWS IoT Analytics 代替サービス 理由 収集 AWS IoT Analytics では、BatchPutMessage API を使用して AWS IoT Core やその他のソースからデータを簡単に取り込めます。この統合により、デバイスからアナリティクスプラットフォームまでのデータのシームレスなフローが確保されます。 Amazon Kinesis Data Streams または Amazon Data Firehose Amazon Kinesis は堅牢なソリューションを提供します。Kinesis はデータをリアルタイムでストリーミングするため、リアルタイムの分析や異常検知が必要なアプリケーションに不可欠な即座の処理と分析が可能です。Amazon Data Firehose は、ストリーミングデータを Amazon S3 に格納する前に、キャプチャと変換を簡素化してくれます。スループットに合わせて自動的にスケーリングします。 処理 AWS IoT Analytics でデータを処理する際は、クレンジング、フィルタリング、変換、外部ソースでの強化が行われます。 Managed Streaming for Apache Flink または Amazon Data Firehose Managed Streaming for Apache Flink は、高度な IoT 分析シナリオに不可欠なパターンマッチングや集約などの複雑なイベント処理をサポートしています。 Amazon Data Firehose はより単純な変換を処理し、カスタム処理には AWS Lambda 関数を呼び出すことができるので柔軟性があり、Flink ほど複雑ではありません。 保存先 AWS IoT Analytics では、データ保持ポリシーやアクセス管理などの機能を備えた、IoT データ向けに最適化された時系列データストアを使用しています。 Amazon S3 または Amazon Timestream Amazon S3 はスケーラブル、堅牢、低コストのストレージソリューションです。S3 と他の AWS サービスとの統合により、大規模データセットの長期保存と分析に最適です。 Amazon Timestream は、時系列データ向けに作られたデータベースです。 S3 からのバッチロード ができます。 分析 AWS IoT Analytics には、組み込みの SQL クエリ機能、時系列分析、ホストされた Jupyter Notebook のサポートがあり、高度な分析と機械学習を簡単に実行できます。 AWS Glue と Amazon Athena AWS Glue は ETL プロセスを簡素化し、データの抽出、変換、ロードを容易にします。また、Athena と統合されたデータカタログを提供し、クエリを容易にします。 Amazon Athena はさらに、インフラストラクチャを管理することなく、S3 に保存されたデータに対して直接 SQL クエリを実行できるようになります。 ビジュアライズ AWS IoT Analytics は Amazon QuickSight と統合されているので、視覚化とダッシュボードを作成できます。S3 などの選択した代替データストアに応じて、引き続き QuickSight を使用できます。 移行ガイド 現行のアーキテクチャでは、IoT データは IoT Core ルールを経由して IoT Core から AWS IoT Analytics に流れています。AWS IoT Analytics がデータの取り込み、変換、および格納を処理します。移行を完了するには、2 つのステップに従う必要があります。 ステップ 1: 継続的データ取り込みのリダイレクト ステップ 2: 以前インポートしたデータのエクスポート 図 1: AWS IoT Analytics による IoT データの取り込み用の現行のアーキテクチャ ステップ 1: 継続的データ取り込みのリダイレクト 移行の第一歩は、データの継続的な取り込みを新しいサービスへリダイレクトすることです。特定のユースケースに基づき、次の 2 つのパターンをお勧めします: 図 2: IoT データ取り込みのための提案アーキテクチャパターン パターン 1: Amazon Kinesis Data Streams と Amazon Managed Service for Apache Flink 概要 このパターンでは、まず AWS IoT Core にデータを公開することから始めます。これは Amazon Kinesis Data Streams と統合されており、大量の帯域幅のデータをリアルタイムで収集、処理、分析できます。 メトリクスとアナリティクス データの取り込み: IoT データは、リアルタイムで Amazon Kinesis Data Streams に取り込まれます。Kinesis Data Streams は、数百万の IoT デバイスからの高スループットのデータを処理でき、リアルタイム分析と異常検知が可能です。 データの処理: Amazon Managed Streaming for Apache Flink を使用して、Kinesis Data Stream からデータを処理、加工、フィルタリングします。Flink には、集計、結合、時間操作などの複雑なイベント処理のための堅牢な機能があります。 データの保存: Flink は処理済みのデータを Amazon S3 に出力し、保存と追加の分析に利用できます。このデータは Amazon Athena でクエリを実行したり、他の AWS の分析サービスと統合したりできます。 このパターンが適するケース アプリケーションがデータストリーミングなど帯域の大きいデータを扱い、パターンマッチングやウィンドウ処理といった高度な処理が必要な場合、このパターンが最適です。 パターン 2: Amazon Data Firehose 概要 このパターンでは、データがAWS IoT Coreに公開され、Amazon Data Firehoseと統合されるため、データを直接Amazon S3に保存できます。このパターンはまた、AWS Lambdaを使った基本的な変換もサポートしています。 メトリクスと分析 データの取り込み: IoT データはデバイスや IoT Core から直接 Amazon Data Firehose に取り込まれます。 データの変換: Firehose はデータの形式変換や拡張など、基本的な変換や処理を行います。Firehose のデータ変換機能を有効にすると、AWS Lambda 関数を呼び出して、データを出力先に送信する前に受信したソースデータを変換できます。 データの格納: 処理されたデータはほぼリアルタイムで Amazon S3 に送られます。Amazon Data Firehose は、受信データのスループットに合わせて自動的にスケーリングし、確実で効率的なデータ配信を実現します。 このパターンが適するケース とか？ これは基本的なデータ変換や処理が必要なワークロードに最適です。さらに、Amazon Data Firehose は、S3 に保存されたデータのデータバッファリングと動的パーティション分割の機能を提供することにより、処理プロセスを簡素化します。 アドホックなクエリのパターン IoT 分析のワークロードを Amazon Kinesis Data Streams や Amazon Data Firehose に移行する際、AWS Glue と Amazon Athena を活用することで、データ分析プロセスをさらにストリームライン化できます。AWS Glue はデータの準備と変換を簡素化し、Amazon Athena はサーバーレスでデータを素早く問い合わせできるようにします。あわせて、IoT データを分析するための、強力でスケーラブル、かつ費用対効果の高いソリューションを提供します。 図 3: 両パターンのためのアドホックなクエリ実行 ステップ 2: 以前インポートしたデータのエクスポート AWS IoT Analytics に取り込み、保存されているデータを Amazon S3 にエクスポートする必要があります。この手順を簡略化するために、CloudFormation テンプレートを使って、データエクスポートのワークフロー全体を自動化できます。スクリプトを使えば、一部 (時間範囲ベース) のデータを抽出できます。 図 4: CloudFormation を使用して以前にインジェストされたデータをエクスポートするためのアーキテクチャ S3 にデータをエクスポートするための CloudFormation テンプレート 以下の手順は、CloudFormation テンプレートを使用して同じ AWS IoT Analytics データストア内にデータセットを作成し、タイムスタンプに基づいて選択できるプロセスを示しています。これにより、ユーザーは希望する期間内の特定のデータポイントを取得できます。さらに、コンテンツ配信ルールが作成され、データを S3 バケットにエクスポートします。 ステップバイステップガイド CloudFormation テンプレートの準備: 提供された CloudFormation テンプレートをコピーし、YAML ファイル (例: migrate-datasource.yaml) として保存します。 # Cloudformation Template to migrate an AWS IoT Analytics datastore to an external dataset AWSTemplateFormatVersion: 2010-09-09 Description: Migrate an AWS IoT Analytics datastore to an external dataset Parameters: DatastoreName: Type: String Description: The name of the datastore to migrate. AllowedPattern: ^[a-zA-Z0-9_] +$ TimeRange: Type: String Description: | This is an optional argument to split the source data into multiple files. The value should follow the SQL syntax of WHERE clause. E.g. WHERE DATE(Item_TimeStamp) BETWEEN '09/16/2010 05:00:00' and '09/21/2010 09:00:00'. Default: '' MigrationS3Bucket: Type: String Description: The S3 Bucket where the datastore will be migrated to. AllowedPattern: (?!(^xn--|.+-s3alias $))^[a-z0-9][a-z0-9-] { 1,61 } [a-z0-9] $ MigrationS3BucketPrefix: Type: String Description: The prefix of the S3 Bucket where the datastore will be migrated to. Default: '' AllowedPattern: (^([a-zA-Z0-9.\-_] * \/)*$)|(^ $) Resources: # IAM Role to be assumed by the AWS IoT Analytics service to access the external dataset DatastoreMigrationRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: iotanalytics.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: AllowAccessToExternalDataset PolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Action: - s3:GetBucketLocation - s3:GetObject - s3:ListBucket - s3:ListBucketMultipartUploads - s3:ListMultipartUploadParts - s3:AbortMultipartUpload - s3:PutObject - s3:DeleteObject Resource: - ! Sub arn:aws:s3:::${ MigrationS3Bucket } - ! Sub arn:aws:s3:::${ MigrationS3Bucket }/${ MigrationS3BucketPrefix }* # This dataset that will be created in the external S3 Export MigratedDataset: Type: AWS::IoTAnalytics::Dataset Properties: DatasetName: ! Sub ${ DatastoreName } _generated Actions: - ActionName: SqlAction QueryAction: SqlQuery: ! Sub SELECT * FROM ${ DatastoreName } ${ TimeRange } ContentDeliveryRules: - Destination: S3DestinationConfiguration: Bucket: ! Ref MigrationS3Bucket Key: ! Sub ${ MigrationS3BucketPrefix }${ DatastoreName }/!{ iotanalytics:scheduleTime }/!{ iotanalytics:versionId }.csv RoleArn: ! GetAtt DatastoreMigrationRole.Arn RetentionPeriod: Unlimited: true VersioningConfiguration: Unlimited: true AWS IoT Analytics データストアを特定する: データをエクスポートする必要がある AWS IoT Analytics データストアを決定します。このガイドでは、「iot_analytics_datastore」という名前のサンプルデータストアを使用します。 データをエクスポートする S3 バケットを作成するか、特定してください。このガイドでは、”iot-analytics-export” バケットを使用します。 CloudFormation スタックを作成します AWS CloudFormation コンソールに移動します。 「Create stack」 をクリックし、「With new resources (standard)」 を選択します。 migrate-datasource.yaml ファイルをアップロードします。 スタック名を入力し、次のパラメータを指定してください: DatastoreName : 移行する対象の AWS IoT Analytics データストアの名前。 MigrationS3Bucket : 移行したデータを格納する S3 バケット。 MigrationS3BucketPrefix (オプション): S3 バケットのプレフィックス。 TimeRange (オプション): 指定された時間範囲に基づいて、エクスポートされるデータをフィルタリングする SQL WHERE 句により、ソースデータを複数のファイルに分割できます。 「Configure stack options」画面で「Next」をクリックしてください。 確認と作成ページのチェックボックスを選択して「Submit」をクリックしてください。 完了するまで、イベントタブでスタックの作成を確認してください。 スタックの作成が成功したら、AWS IoT Analytics → Datasets に移動し、移行したデータセットを確認してください。 生成されたデータセットを選択し、「Run now」をクリックしてデータセットをエクスポートします。 コンテンツは、データセットの「Content」タブで確認できます。 最後に、S3 コンソールの「iot-analytics-export」バケットを開いて、エクスポートされたコンテンツを確認できます。 考慮事項: コスト面での考慮点: データ移行に伴うコストについては、AWS IoT Analytics の 料金ページ を参照してください。完了後は不要なコストを避けるため、作成した新しいデータセットを削除することをお勧めします。 Full Dataset Export: 時間ベースでの分割なしにデータセット全体をエクスポートするには、AWS IoT Analytics コンソールを使用し、コンテンツ配信ルールを適宜設定することができます。 まとめ AWS IoT Analytics から Amazon Kinesis Data Streams、S3、および Amazon Athena に IoT 分析ワークロードを移行することで、大規模で複雑な IoT データを処理する能力が向上します。このアーキテクチャは、スケーラブルで永続的なストレージと強力な分析機能を提供し、リアルタイムで IoT データから深い洞察を得ることができます。 移行が完了した後に予期しないコストを避けるために、CloudFormation で作成したリソースをクリーンアップすることが不可欠です。 移行ガイドに従えば、データ取り込みとデータ処理パイプラインをシームレスに移行でき、継続的で信頼性の高いデータフローが確保されます。AWS Glue と Amazon Athena を活用することで、データ準備とクエリがさらに簡素化され、インフラストラクチャを管理することなく高度な分析を実行できます。 このアプローチにより、IoT 分析の取り組みを効果的にスケーリングでき、ビジネスの成長に合わせて柔軟に対応し、IoT データから最大の価値を引き出すことができます。 著者について Umesh Kalaspurkar Umesh Kalaspurkar は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。デジタルイノベーションとトランスフォーメーションプロジェクトの設計と提供に 20 年以上の経験を持ち、企業やスタートアップで活躍してきました。顧客が課題を特定し、それを克服するのを手助けすることにやりがいを感じています。仕事以外では、父親として、スキーと旅行を楽しんでいます。 Ameer Hakme Ameer Hakme はペンシルベニア州を拠点とする AWS のソリューションアーキテクトです。北東部のソフトウェアベンダーと協力し、AWS Cloud 上で拡張性と最新性に優れたプラットフォームを設計・構築するのを支援しています。プライベートでは、バイクに乗ったり家族と過ごすのを楽しんでいます。 Rizwan Syed Rizwan Syed は AWS のシニア IoT コンサルタントで、IoT、インダストリアル IoT、AI/ML、組み込み/リアルタイムシステム、セキュリティ、Reconfigurable Computingなど、さまざまな分野で 20 年以上の経験を持っています。顧客との共同作業で、ユースケースに合わせたユニークなソリューションを設計および開発してきました。仕事外では、Rizwan は父親として DIY 活動やコンピュータゲームに興じています。 この記事は Umesh Kalaspurkar, Ameer Hakme, Rizwan Syed によって書かれた Unlocking Scalable IoT Analytics on AWS の日本語訳です。この記事は ソリューションアーキテクト 松本敢大が翻訳しました。 松本 敢大 (Kanta Matsumoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。 好きな AWS サービスは AWS IoT Core。趣味はカメラで犬が好きです。

本ブログは「 Transition your Amazon Forecast usage to Amazon SageMaker Canvas 」を翻訳したものです。 Amazon Forecast  は、統計および機械学習（ML）アルゴリズムを使用して非常に正確な時系列予測を提供するフルマネージドサービスです。2019年8月にリリースされ、 Amazon SageMaker Canvas  よりも前に登場しました。Amazon SageMaker Canvasは、時系列予測モデルを含むMLモデルの構築、カスタマイズ、およびデプロイを行うための人気のローコード/ノーコードAWSツールです。 Amazon SageMaker Canvasを使用すると、 より迅速なモデル構築 、コスト効率の高い予測、モデルリーダーボードやアルゴリズム選択などの高度な機能、そして透明性の向上が得られます。また、コードを書くことなくMLの専門知識がなくてもモデルを構築およびデプロイできるビジュアルインターフェースを提供するSageMaker Canvas UI、またはプログラムから操作するための AutoML API  を使用することができます。 この投稿では、Amazon SageMaker Canvasが提供する利点の概要と、Amazon Forecast ユーザーがどのようにして Amazon SageMaker Canvas にユースケースを移行できるかについて詳述します。 Amazon SageMaker Canvasの利点 Amazon Forecastをご利用いただいていたお客様は、より高い透明性、低コスト、迅速なトレーニング、および時系列 ML モデルの構築における強化されたコントロールを求めてきました。このフィードバックに応じて、Amazon SageMaker Canvas は次世代の時系列予測機能を提供しています。Amazon SageMaker Canvas は、データの準備、MLモデルの構築およびデプロイのための堅牢なプラットフォームを既に提供しています。予測機能の追加により、回帰、マルチクラス分類、コンピュータビジョン（CV）、自然言語処理（NLP）、生成AIなどの広範なモデルタイプに対するエンドツーエンドの ML 機能にアクセスできるようになりました。 Amazon SageMaker Canvasは、さまざまなベンチマークデータセットにおいて、 Amazon Forecastと比較して時系列モデルの構築パフォーマンスが最大50％高速化され、予測が平均で最大45％迅速化されます 。予測の生成は、 Amazon SageMaker  のコンピュートリソースに基づいて コストが計算される ため、Amazon Forecast よりもはるかにコスト効率が高くなります。Amazon SageMaker Canvas は、トレーニング済みモデルへの直接アクセスを提供し、選択した場所にデプロイできる優れたモデルの透明性を提供します。また、検証データ、モデルおよびアイテムレベルのパフォーマンスメトリクス、トレーニング中に使用されたハイパーパラメータなど、さまざまなモデルインサイトレポートにアクセスできます。 Amazon SageMaker Canvas には、Amazon Forecast で見られる主要な機能が含まれており、統計およびニューラルネットワークアルゴリズムを使用して予測モデルのアンサンブルをトレーニングすることができます。各アルゴリズムのベースモデルを生成し、そのパフォーマンスを評価し、最もパフォーマンスの高いモデルをアンサンブルに組み合わせることで、データセットに最適なモデルを作成します。このアプローチは、さまざまなモデルの強みを活用して、より正確で堅牢な予測を生成します。モデル作成のために 1 つまたは複数のアルゴリズムを選択し、予測精度に対するモデル機能の影響を評価する機能もあります。Amazon SageMaker Canvas は、欠損値の補完などの自動化ソリューションを提供し、データ準備を簡素化します。また、国別の祝日などの外部情報を簡単なUIオプションやAPI設定を通じて統合するアウトオブザボックスの統合も可能です。さらに、 データフロー 機能を活用して、 外部データプロバイダーの API と接続し、気象情報などのデータをインポートする こともできます。加えて、SageMaker Canvas UI 上で What-If 分析を実施し、さまざまなシナリオが結果にどのように影響するかを探索することができます。 私たちは、SageMaker Canvasを通じて、レイテンシの低減、トレーニングおよび予測コストの削減、精度の向上など、最先端で業界をリードする予測機能を提供し続けます。これには、サポートする予測アルゴリズムの範囲を拡大し、モデル構築および予測体験をさらに向上させる新しい高度なアルゴリズムを組み込むことが含まれます。 Amazon Forecast から Amazon SageMaker Canvasへの移行 Amazon Forecast から Amazon SageMaker Canvas への移行を支援するための2つのリソースを含む移行パッケージをリリースします。最初のコンポーネントには、Amazon SageMaker Canvas UI および API を使用してAmazon Forecast から Amazon SageMaker Canvas への移行方法を学ぶためのハンズオンワークショップが含まれています。また、既存の Amazon Forecast トレーニングデータセットをAmazon SageMaker Canvas 形式に変換する方法を示す Jupyter ノートブックも提供します。 Amazon Forecastの入力データセットを使用して Amazon SageMaker Canvas で予測モデルを構築する方法を学ぶ前に、Amazon Forecast とAmazon SageMaker Canvas のいくつかの重要な違いを理解しましょう： データセットの種類：  Amazon Forecastは、ターゲット時系列、関連時系列（オプション）、およびアイテムメタデータ（オプション）など複数のデータセットを使用します。これに対して、Amazon SageMaker Canvasは1つのデータセットのみを必要とし、複数のデータセットを管理する必要がありません。 モデルの呼び出し： Amazon SageMaker Canvas では、UI および API を使用して、単一のデータセットまたはバッチのデータセットに対してモデルを呼び出すことができます。Amazon Forecastとは異なり、まず予測を作成してからそれをクエリする必要はなく、UI または API を使用してモデルがデプロイされているエンドポイントを直接呼び出して予測を生成します。SageMaker Canvas UIでは、モデルを SageMaker のリアルタイムエンドポイントにデプロイするオプションも提供しています。数回のクリックで、アプリケーション内から呼び出すことができるHTTPSエンドポイントを受け取ることができます。 以下のセクションでは、データの変換、モデルの構築、およびSageMaker Canvasを使用してモデルをデプロイするための高レベルの手順について説明します。 SageMaker Canvas UIを使用したモデルの構築とデプロイ データソースを再編成して、Amazon SageMaker Canvas で使用する単一のデータセットを直接作成することをお勧めします。Amazon SageMaker Canvas で予測モデルを構築するための入力データセットの構造については、「 Amazon SageMaker Canvasでの時系列予測 」を参照してください。ただし、Amazon Forecast で使用している複数のデータセットを引き続き使用したい場合は、以下のオプションを使用して、それらをAmazon SageMaker Canvas がサポートする単一のデータセットにマージすることができます： SageMaker Canvas UI: SageMaker Canvas UIを使用して、ターゲット時系列、関連時系列、およびアイテムメタデータのデータセットを1つのデータセットに結合します。以下のスクリーンショットは、SageMaker Canvas で3つのデータセットを1つの SageMaker Canvas データセットにマージするために作成されたデータフローの例を示しています。 （訳者追記：上記の SageMaker Canvas UI では、 Amazon SageMaker Canvas に統合された Amazon SageMaker Data Wrangler を利用します。 Amazon SageMaker Data Wrangler はコーディングなしでデータの前処理、特徴量エンジニアリングを簡素化できるほか、探索的データ分析（EDA）を行えるサービスです。上図のとおり、日本語を含む自然言語でのデータ分析・加工も可能なサービスとなっています。） Pythonスクリプト：Pythonスクリプトを使用してデータセットをマージします。複数のForecastデータセットをSageMaker Canvas用の1つのデータセットに変換するためのサンプルコードとハンズオン体験については、 こちらのワークショップ を参照してください。 データセットが準備できたら、SageMaker コンソール上の SageMaker Canvas UI を使用してデータセットをSageMaker Canvas アプリケーションにロードします。Amazon SageMaker Canvas は AutoML を使用してモデルをトレーニング、構築、およびデプロイし、推論を行います。 ワークショップ では、データセットのマージ方法と予測モデルの構築方法を示しています。 モデルが構築された後、予測を生成および利用する方法は複数存在します。 アプリ内での予測の実行 – SageMaker Canvas UI を使用して予測を生成し、組み込みの統合機能を使用して Amazon QuickSight  にエクスポートするか、予測ファイルをローカルデスクトップにダウンロードできます。また、モデルアーティファクト、データセット、およびその他のアプリケーションデータをAmazon SageMaker Canvas が保存するように設定した  Amazon Simple Storage Service（Amazon S3） から、Amazon SageMaker Canvas で生成した予測結果にアクセスすることもできます。Amazon SageMaker Canvas が使用する Amazon S3 については、「 Amazon S3 ストレージの設定 」を参照してください。 モデルを SageMaker エンドポイントにデプロイ – SageMaker Canvas UI から直接モデルを SageMaker リアルタイムエンドポイントにデプロイできます。これらのエンドポイントは、開発者がアプリケーション内で数行のコードを使用してクエリできます。既存のアプリケーションのコードを更新して、デプロイされたモデルを呼び出すことができます。詳細については、ワークショップを参照してください。 SageMaker Canvas（Autopilot）APIを使用したモデルの構築とデプロイ GitHub リポジトリのノートブック に提供されているサンプルコードを使用して、ターゲット時系列データ、関連時系列データ、およびアイテムメタデータを含むデータセットを SageMaker Canvas API で必要とされる単一のデータセットに処理します。 次に、 SageMaker AutoML APIを使用して時系列予測 を行い、データを処理し、MLモデルをトレーニングし、プログラム的にモデルをデプロイします。時系列モデルをトレーニングし、モデルを使用して予測を生成する方法の詳細な実装については、 GitHubリポジトリのサンプルノートブック を参照してください。 （訳者追記： 訳者が作成した GitHub リポジトリのサンプルノートブック は、 Amazon SageMaker Python SDK を用いて SageMaker Canvas (Autopilot) API を利用する実装方法を日本語で記載しています。こちらのノートブックもご参照ください。） ハンズオンについては、 こちらのワークショップ を参照してください。 結論 この投稿では、Amazon Forecast からの移行手順、Amazon SageMaker Canvas で時系列 ML モデルを構築する手順、およびデータ変換ノートブックとワークショップを通じた具体的なガイダンスを提供しました。移行後は、よりアクセスしやすい UI 、コスト効率の向上、および Amazon SageMaker Canvas の AutoML API の高い透明性の恩恵を受けることができ、組織内での時系列予測を民主化し、モデルのトレーニングとデプロイにかかる時間とリソースを節約できます。 Amazon SageMaker Canvas は SageMaker コンソールからアクセスできます。Canvas を使用した時系列予測は、Amazon SageMaker Canvas が利用可能なすべてのリージョンで利用できます。AWSリージョンの利用可能性の詳細については、「 リージョン別AWSサービス 」を参照してください。 リソース 詳細については、以下のリソースを参照してください： Amazon SageMaker Canvas を使った時系列予測の実現方法については、 ワークショップ を参照してください。 SageMaker Canvas UI を使って時系列予測を実現する際の詳細情報については、「 Amazon SageMaker Canvasでの時系列予測 」を参照してください。 APIを使用した時系列予測の情報については、「 APIを使用した時系列予測のためのAutoMLジョブの作成 」を参照してください。 （訳者追記： 訳者が作成した GitHub リポジトリのサンプルノートブック は、 Amazon SageMaker Python SDK を用いて SageMaker Canvas (Autopilot) API を利用する実装方法を日本語で記載しています。こちらのノートブックもご参照ください。） AutoML APIを使用して時系列モデルをトレーニングし、予測を生成するサンプル実装を示すノートブックについては、「 GitHubのAmazon SageMaker Autopilotを使用した時系列予測 」を参照してください。 予測モデルに気象データを含める方法については、「 Amazon SageMaker Canvasを使用して気象データを予測に活用する 」を参照してください。 予測モデルの精度ドリフトを監視し、ドリフトしきい値に基づいてモデルを自動的に再トレーニングする方法については、「 GitHubのAmazon SageMaker Autopilotを使用した自動時系列パフォーマンス監視と再トレーニング 」を参照してください。 著者について Nirmal Kumar は Amazon SageMaker サービスのシニアプロダクトマネージャーです。AI/MLへのアクセスの拡大に取り組み、ノーコードおよびローコードのMLソリューションの開発を指揮しています。仕事以外では、旅行やノンフィクションの読書を楽しんでいます。     Dan Sinnreich は Amazon SageMaker のシニアプロダクトマネージャーで、ノーコード/ローコードサービスの拡大に注力しています。彼は、機械学習とジェネレーティブAIをより身近なものにし、それらを適用して困難な問題を解決することに専念しています。仕事以外では、ホッケー、スキューバダイビング、サイエンスフィクションを読んだりしています。 Davide Gallitelliは、EMEA地域のAI/MLのスペシャリストソリューションアーキテクトです。彼はブリュッセルに拠点を置き、ベネルクス全域の顧客と緊密に連携しています。彼は幼い頃から開発者であり、7歳でコーディングを始めました。大学後期に AI/ML を学び始め、それ以来 AI/ML に夢中になっています。     Biswanath Hore は、アマゾンウェブサービスのソリューションアーキテクトです。AWS 導入の早い段階でお客様と協力し、お客様のビジネスニーズに対応するクラウドソリューションの導入を支援しています。彼は機械学習に情熱を注いでおり、仕事以外では家族と過ごす時間が大好きです。     翻訳はソリューションアーキテクト辻浩季が担当しました。原文は こちら です。

Amazon Web Services (AWS) コミュニティメンバーの才能と情熱、特にテクノロジーコミュニティにおける多様性、公平性、インクルージョンを高めるための取り組みにはいつも驚かされます。 7月22日週、 Natalie が率いる AWS ユーザーグループウィメンベイエリア のミートアップで講演する機会がありました。このグループは、女性のエンパワーメントとつながりを促進し、クラウドコンピューティングの探求を支援する環境を提供しています。ラテンアメリカでは最近、10 か国における 12 の女性が主導する AWS ユーザーグループ による 2 つの地域の AWSome Women Community Summit の開催を支援しました。これらのサミットには 800 名以上の女性のビルダーが参加しました。やるべきことはまだまだありますが、このようなイニシアチブは、包括的かつ多様なテクノロジー環境を促進する上でのコミュニティの力を浮き彫りにしています。 それでは、7月22日週の AWS に関するその他のエキサイティングなニュースを見てみましょう。 7月22日週のリリース 私が注目したいくつかのリリースをご紹介します。 Meta Llama 3.1 モデル – Llama 3.1 モデルは、これまでで最も先進的かつ高性能な Meta のモデルです。8B、70B、405B のパラメータサイズモデルのコレクションであり、幅広い業界ベンチマークで最高のパフォーマンスを示し、生成人工知能 (生成 AI) アプリケーションに新機能を提供します。Llama 3.1 モデルを、 Amazon Bedrock (「 Amazon Bedrock での Meta の Llama 3.1 405B、70B、8B モデルを発表 」を参照) と Amazon SageMaker JumpStart (「 Llama 3.1 モデルで、Amazon SageMaker JumpStart で利用可能に 」を参照) でご利用いただけるようになりました。 私の同僚の  Tiffany  と  Mike  は、先週の「 Build On Generative AI 」ライブストリームのエピソードで、Llama 3.1について調べました。 フルエピソードはこちらでご視聴 いただけます。 Mistral Large 2 モデル – Mistral Large 2 は Mistral Large の最新バージョンです。Mistral AI によると、多言語機能、数学、推論、コーディングなどにおいて大幅な改善がなされています。Mistral AI の Mistral Large 2 基盤モデル (FM) を、 Amazon Bedrock でご利用いただけるようになりました。詳細については、「 Mistral Large 2 が Amazon Bedrock で使用可能に 」をご覧ください。コード例は、 Mistral-on-AWS リポジトリ と Amazon Bedrock ユーザーガイド に記載されています。 生成 AI モデルの自動スケーリングの高速化 – Amazon SageMaker 推論の新機能を使用すると、生成 AI モデルが自動的にスケーリングされるまでの時間を短縮できます。1 分未満のメトリクスを使用して、生成 AI モデルの全体的なスケーリングレイテンシーを大幅に削減できるようになりました。この機能強化により、需要の変動に対する生成 AI アプリケーションの反応を向上させることができます。詳細については、「 Amazon SageMaker 推論が生成 AI モデルの自動スケーリングを高速化 」をご覧ください。 AWS Step Functions がカスタマーマネージドキーのサポートを開始 – AWS Step Functions は、 AWS Key Management Service (AWS KMS) を使用したカスタマーマネージドキーの使用のサポートを開始し、Step Functions ステートマシンとアクティビティリソースを暗号化できるようになりました。この新機能により、独自の暗号化キーを使用してワークフロー定義と実行データを暗号化することができます。詳細については、 AWS Step Functions ドキュメント と AWS KMS ドキュメント をご覧ください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 AWS 認定: 新しい試験問題タイプの追加 – AWS 認定 AI プラクティショナー または AWS 認定機械学習エンジニア – アソシエイト 試験を近日中に受験する予定がある場合は、「 AWS 認定: 新しい試験問題タイプの追加 」をご覧ください。これらの試験では、順序付け、照合、ケーススタディという 3 つの新しい問題タイプが初めて導入されます。この投稿では、新しい質問タイプに関する洞察を紹介し、準備に役立つ情報を提供しています。 Amazon EC2 での Apache Spark から Ray へのエクサバイトスケールの移行 – Amazon Retail の Business Data Technologies (BDT) チームは、データ処理にかかる時間とコストの両方を削減するために、大規模な本稼働環境ビジネスインテリジェンス (BI) データセットの管理を Apache Spark から Ray に内々で移行することを決定しました。また、Ray のオープンソースの DeltaCAT プロジェクト に、自分たちの取り組みの重要な要素 ( The Flash Compactor ) を寄稿しました。詳細については、「 Amazon EC2 での Apache Spark から Ray への Amazon のエクサバイトスケールの移行 」をご覧ください。 community.aws より community.aws から、私が個人的に最も気に入っている 3 つの記事をご紹介します。 Elizabeth Fuentes による RAG PostgreSQL を使用した旅行サポートエージェント Ricardo Sueiras による Converse API を使用して Hacker News のコメントを読む時間を削減 Ricardo Ferreira による Amazon Q Developer 向けカスタマイズ入門 今後の AWS イベント カレンダーを確認して、これらの AWS イベントにサインアップしましょう。 AWS Summit – 2024 年の AWS Summit シーズンが終わりを迎えようとしています。 クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市のイベントにご登録ください: メキシコシティ (8 月 7 日)、 サンパウロ (8 月 15 日)、 ジャカルタ (9 月 5 日)。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 ニュージーランド (8 月 15 日)、 コロンビア (8 月 24 日)、 ニューヨーク (8 月 28 日)、 ベルファスト (9 月 6 日)、 ベイエリア (9 月 13 日) です。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます。 7月29日週はここまでです。8月5日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください。 –  Antje この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

2024 年 4 月 11 日にデプロイ手順を更新しました。 この記事では、 Amazon Route 53 のレイテンシーに基づくルーティングと Amazon CloudFront を使用して、複数リージョンにまたがるアクティブ – アクティブなアプリケーション構成の AWS でのネットワーク層の設定方法について説明します。 これにより、ユーザに低レイテンシーで信頼性の高い環境を提供することができます。 AWS のネットワーキングサービスを使ってアクティブ – アクティブなアーキテクチャを構築することで、アプリケーションのレジリエンスとパフォーマンスが向上します。 ただし、コストと複雑さにはトレードオフがあるため、アーキテクチャの考慮事項と、アプリケーションの機能性、レジリエンス、パフォーマンスへの影響について検討するためのガイダンスも提供しています。 マルチリージョンのアクティブ – アクティブアーキテクチャのメリットとは？ マルチリージョンアクティブ – アクティブアーキテクチャは、地理的に離れた 2 つ以上の AWS リージョンでアプリケーションを実行するデプロイのことです。 両方(またはすべて)のリージョンに必要なコンポーネントとデータがあり、エンドユーザーとの近接性に基づいてリクエストに積極的に応答します。 あるリージョンでアプリケーションに障害が発生した場合、別のリージョンが自動的にユーザートラフィックを引き継ぎ、グローバルユーザーにダウンタイムを発生させることなく運用を継続できます。 どのような場合にマルチリージョンのアクティブ – アクティブアーキテクチャを採用すべきか？ マルチリージョンでアクティブ – アクティブなアーキテクチャを検討すべきなのは、アプリケーションの障害単位が AWS リージョン単位である場合のみです。 アクティブ – アクティブアーキテクチャでは、コストが高くなる可能性と複雑さの増大を慎重に検討する必要があります。リージョン間でデータレプリケーションが必要なステートフルなアプリケーションの場合は、データの不整合、高いレイテンシー、パフォーマンスの低下も考慮に入れる必要があります。 ビジネスの要求事項 厳しい目標復旧時間 (RTO) / 目標復旧点 (RPO) の要件: アクティブ – アクティブアーキテクチャを選択する理由の 1 つは、アクティブ – パッシブ、ウォームスタンバイ、パイロットライト構成などの他の ディザスタリカバリ（DR） 戦略では対応できないほど厳しい SLA 要件を満たすためです。また、事業継続の最小単位がリージョン単位になり、RTO を秒または分単位で測る必要がある場合にも、アクティブ – アクティブアーキテクチャを検討する可能性があります。 法的およびコンプライアンスの理由: 地方政府が施行するデータ主権に関する法律や規制により、エンドユーザーの近くにデータを物理的に保管する必要がある場合があります。データ主権の要件を満たすため、ユーザーの地理的な位置に基づいて、複数の AWS リージョンにアプリケーションを展開することがあります。 レイテンシと性能の改善 地理的に分散したユーザーベースに動的コンテンツを提供する場合、パフォーマンスを改善するためにアクティブ – アクティブ アーキテクチャを採用することがあります。 この場合、アクティブ – アクティブでは動的なデータを処理して提供できるため、長距離のネットワーク転送によるオーバーヘッドなしでレイテンシーを低減できます。 マルチリージョンアクティブ – アクティブアーキテクチャで使用される AWS ネットワークサービス アクティブ – アクティブアーキテクチャでは、アプリケーションをマルチリージョン構成でデプロイした際のレイテンシを改善するために、Amazon CloudFront と A WS Global Accelerator を使用できます。Global Accelerator は、AWS のグローバルネットワークインフラストラクチャを利用することで、インターネットユーザーのパフォーマンスと可用性を改善できるネットワークサービスです。 Global Accelerator は、静的なエニーキャスト IP アドレスや瞬時の AWS リージョン障害から復旧が必要なユースケースに適していますが、コンテンツのキャッシングやエッジでの処理をサポートしていません。 そのため、アプリケーションによっては、このブログ記事で説明されているように、アーキテクチャの中で CloudFront を使用することをお勧めします。 CloudFront は、キャッシュ可能なコンテンツ (画像やビデオなど) と動的コンテンツ (API の高速化やウェブサイトの動的配信など) の両方のパフォーマンスを向上させます。 CloudFront には次のような追加の利点もあります。 セキュリティ アクセス制御: CloudFront の 地理的制限機能 を使うと、CloudFront で配信されるコンテンツへのアクセスを、特定の地理的位置のユーザーに対して制限できます。 エッジコンピューティング CloudFront は AWS Lambda@Edge および CloudFront Functions を通じて、プログラム可能かつセキュアなエッジ CDN コンピューティング機能を提供します。 Lambda@Edge: AWS Lambda@Edge は、エッジで実行される幅広い計算ニーズとカスタマイズをサポートするサーバーレスのコンピューティングサービスです。 CloudFront Functions: CloudFront Functions は、HTTP ヘッダー操作、URL の書き換え/リダイレクト、キャッシュキーの正規化などのサブミリ秒のスケーラブルなコンピューティング操作に最適です。 ソリューションの概要 図 1: クライアントブラウザからリージョン内のオリジンサービスへのユーザーフロー 図 1 に示したダイアグラムは、アクティブ – アクティブアーキテクチャにおいてエンドユーザーからの API 呼び出しがどのように流れているかを概説しています。ユーザーリクエストが最も近い AWS エッジロケーション [1] に到着し、CloudFront [2] を通じて Amazon API Gateway [3] に渡されます。CloudFront は、 Elastic Load Balancing ロードバランサー、 Amazon Elastic Compute Cloud (Amazon EC2) サーバー、または Amazon Simple Storage Service (Amazon S3) バケットなど、他のオリジンも使用できます。 この処理フローで CloudFront の代わりに Global Accelerator を使っていた場合、エッジロケーションからアプリケーションまでの最適なパスを探索し、必要に応じて AWS リージョンを自動的にフェイルオーバーします。現時点では、CloudFront には、アクティブ・アクティブのマルチリージョンアーキテクチャで別の AWS リージョンにフェイルオーバーさせるための既製のソリューションはありません。このブログ投稿の後の節で、Global Accelerator と同様のフェイルオーバー機能をどのように設計し実装するかを説明します。Route 53 のレイテンシーベース ルーティングを使用したアクティブ・アクティブ構成により、このリージョン間のフェイルオーバー機能を実現します。 全体の仕組み マルチリージョンのアクティブ – アクティブ設定を実装する際は、次の 2 点に特に注意が必要です。 クライアントがアプリケーションにアクセスするためのカスタムドメインの SSL/TLS (Secure Sockets Layer/Transport Layer Security) 証明書 クライアントのリクエストを AWS リージョンへルーティングする、レイテンシーに基づくルーティングロジック 先ず SSL/TLS 証明書の設定方法をご説明します。その後、クライアントのトラフィックを AWS リージョンにルーティングするロジックについて解説します。 SSL/TLS 証明書で AWS ウェブサイトおよびアプリケーションを保護する マルチリージョン構成で転送中のトラフィックを暗号化するには、アプリケーションをデプロイする各リージョンで一致する SSL/TLS 証明書が利用可能である必要があります。この項では、AWS でこれを実現する方法について説明します。 アプリケーションをデプロイする各リージョンで、同じ SSL/TLS 証明書を作成する必要があります。 証明書は、マルチリージョン環境下で、トラフィックを暗号化して転送できるようにします。これにより、AWS のウェブサイトとアプリケーションを保護できます。 AWS Certificate Manager (ACM) を使用して証明書を作成できます。 ACM は、AWS サービスや内部接続リソースで使用するためのパブリックおよびプライベートの SSL/TLS 証明書を簡単にプロビジョニング、管理、デプロイできるサービスです。 SSL/TLS 証明書は、インターネット上のウェブサイトおよびプライベートネットワークのリソースの身元を確認し、ネットワーク通信を保護するために使用されます。 ACM が AWS でホストされるウェブサイトやアプリケーションを保護するためには、AWS サービスが通信の暗号化を行う各リージョンで証明書は存在する必要があります。たとえば、カスタムドメイン名のリージョンエンドポイントタイプを使用して、API Gateway を米国東部(オハイオ) と米国西部 (オレゴン) の両リージョンにデプロイする場合、両リージョンの ACM に証明書を作成またはインポートしなければなりません。ACM についてさらに詳しくは、 AWS Certificate Manager とは をご覧ください。 CloudFront はグローバルサービスであり、リージョナルサービスではないため、証明書は ACM で米国東部（バージニア北部）リージョンで発行される必要があります。 Route 53 は高可用性かつスケーラブルな Domain Name System (DNS) ウェブサービスです。Route 53 を使って、ドメインの登録、DNS ルーティング、 ヘルスチェック の 3 つの主要な機能性を任意の組み合わせで実行できます。Route 53 Traffic Flow を使うと、さまざまなルーティングタイプを使って世界中のトラフィックを管理できます。この投稿では、Latency ルーティングポリシーに焦点を当てます。サポートされているすべてのルーティングタイプの詳細については、 ルーティングポリシー の選択をご覧ください。 図 2: カスタムドメインを使用した DNS 解決とリクエスト フロー 図 2 の図に示されているように、ユーザーリクエストの流れを見てみましょう。 Route 53 のエイリアスレコードを作成し、カスタムドメイン example.com を、CloudFront ディストリビューションのデフォルトのドメイン名に向けます。Route 53 のエイリアスレコードと CNAME について詳しくは、エイリアスレコードの値をご覧ください。 CloudFront で代替ドメイン名 (CNAME) を設定し、米国東部 (バージニア北部) リージョンの ACM 上の証明書をインポートします。Route 53 のエイリアスレコードと CNAME について詳しくは、代替ドメイン名を追加して、カスタム URL を使用するをご覧ください。 リージョナル AWS サービス用の Route 53 レコードセットを設定します。この例では、api.example.com という同じドメイン名で 2 つのレコードを作成し、ルーティングポリシーを latency に設定します。同時に複数のリージョンでアクティブな設定では、レイテンシーを最小限に抑えるために、トラフィックはラウンドトリップ時間の短いリージョンに誘導されます。レイテンシーに基づくルーティングポリシーについて詳しくは、ルーティングポリシーの選択をご覧ください。 パブリックに公開されている AWS サービスがあるそれぞれのリージョンで、ACM 上にパブリック証明書を発行します。この例では、リージョン 1 と リージョン 2 の ACM で証明書を発行する必要があります。 また、オリジンとして Application Load Balancer を使用することもできます。上記のステップは S3 以外のすべての AWS オリジンに適用できます。 クライアントリクエストを AWS リージョンにルーティングするためのルーティングロジック 提案された流れでは、リクエストが API Gateway によって処理される前に、2 回の DNS 解決が行われます: クライアントのブラウザで、ドメイン名を CloudFront の IP アドレスに解決します。 CloudFront のエッジロケーションで、API Gateway または Application Load Balancer のカスタムドメイン名を解決します (オリジンの種類に依存)。 図 3 は、CloudFront と Route 53 を使用したマルチリージョンアクティブ – アクティブレイテンシベースのルーティングを示しています。 図 3: CloudFront と Route 53 を使用したマルチリージョンのアクティブ – アクティブレイテンシベースのルーティング 上の図に示されているように、DNS 解決のフローを見ていきましょう。 クライアントが example.com ドメインに HTTPS リクエストを行います。Route 53 サービスがドメインを解決します。 クライアントは、クライアントに最も近い CloudFront ポイント・オブ・プレゼンス (PoP) 拠点にリクエストを行います。 CloudFront は AWS のグローバルネットワークを通じて、コンテンツを最も効率的に配信できるエッジロケーションにリクエストを転送することで、コンテンツの配信を高速化します。通常はユーザーに最も近い CloudFront エッジサーバーがコンテンツを配信します。 CloudFront PoP 拠点は、Route 53 サービスにオリジンドメイン名 example.com の DNS リクエストを行います。このドメイン名には、Route 53 サービスでレイテンシーに基づくルーティングポリシーが設定されているため、CloudFront PoP 拠点に最も近い地域の API Gateway の IP アドレスが返されます。この例では、オリジンとして API Gateway を使用していますが、他のオリジンタイプ ( Amazon Simple Storage Service を除く) を使用しても、データフローは同じです。 CloudFront PoP 拠点は、最も近い地域の対象のオリジン (API Gateway や Application Load Balancer など) に HTTP リクエストを転送します。 デプロイ手順 デプロイ手順は 4 ステップのアプローチに従います。パート 1 ではオリジンと DNS レジストラのセットアップを行い、パート 2 では Route 53 のパブリックホストゾーンと AWS ACM の設定を紹介します。パート 3 では Route53 のパブリックホストゾーンにカスタムドメインを追加し、最後のパート 4 では CloudFront ディストリビューションのセットアップを行います。 パート 1 – API Gateway/Application Load Balancerのデプロイ、レジストラへのドメインの登録、Route 53 レコードの構成 Web サイト www.example.com をホストする各リージョンのバックエンドサーバを設定してください。 上記の 2 つのリージョンで 2 つの API Gateway を 作成 するステップに従ってください。動的ウェブサイトのパフォーマンスとセキュリティを向上させるための AWS エッジサービスのセットアップ方法については、 このブログ を参照してください。 Application Load Balancer をオリジンとして使う予定の場合は、上記の 2 つのリージョンで 2 つの Application Load Balancer (ALB) を 作成 するステップに従ってください。 パート2 – Route 53 で独自ドメインのパブリックホストゾーンを作成し、公開証明書を追加する Route 53 を使用してインターネット向けのドメイン名 (例: example.com ) の パブリックホストゾーン を作成します。ドメイン名を登録するには、Route 53 または他のドメインレジストラを使用できます。ただし、DNS 管理に Route 53 を使用する場合は、サードパーティーレジストラのウェブサイトで DNS サーバーを更新する必要があります。 登録したドメイン名に対して、バージニア北部リージョン (us-east-1) で 公開証明書をリクエスト します。重要: リソースが他のリージョンにあっても、ACM のコントロールプレーンが us-east-1 にあるため、us-east-1 で公開証明書を要求することが重要です。 パート3 – カスタムオリジンドメインの Public Hosted ゾーンへの A レコードの追加 カスタムオリジンドメインのパブリックホストゾーンへの A レコードを追加する手順について説明します。 アクティブ – アクティブ構成のアーキテクチャはカスタムドメイン名から構成されるので、パブリックホストされたゾーンでカスタムオリジンドメインの A レコードを追加してください。上記の例に従えば、CloudFront ディストリビューションのオリジンとして機能するカスタムオリジンドメイン (例: api.example.com ) 用に 2 つの A レコードが必要になります。 2 つのAPI Gateway/Application Load Balancerに対してレイテンに基づくルーティングを使用し、2 つの A レコードを作成してください: パブリックホストゾーン example.com で、[ レコードの作成 ] を選択します。 レコード名を api として追加し、レコードタイプで A レコードを選択します。 エイリアスをオンにし、トラフィックのルーティング先の下で使用している適切なオリジンを選択します。 リージョン us-east-1 (現在の例の場合 を選択し、設定されたオリジンを選択します。 ルーティングポリシーでレイテンシーを選択し、設定を行います。 別のレコードを追加し、上記の手順を繰り返して 2 番目のリージョン us-west-2 (現在の例の場合) を設定します。 完了したら、レコードを作成します。 パート 4 – API Gateway/Application Load Balancer をオリジンとして CloudFront ディストリビューションをセットアップする カスタムドメイン名の A レコードをパブリックホストゾーンに追加したら、CloudFront ディストリビューションでオリジンとして設定します。 AWS コンソールから Amazon CloudFront のナビゲーションペインに移動し、「ディストリビューションを作成」を選択します。 CloudFront ディストリビューション を作成する手順に従います。 Origin domain では、カスタムサブドメイン api.example.com を追加します。 ビューワープロトコルポリシーでは、「Redirect HTTP to HTTPS」(あるいは適用可能な他のポリシー) を選択します。 キャッシュキーとオリジンリクエストの下で、Cache policy and origin request policy (recommended) を選択し、次に適切なキャシュポリシーを Cache policy から選択します。 ※ テストを行う場合は CachingDisabled にしてください。 設定セクションの下で、代替ドメイン名 (CNAME) を選択し、次に Part 2 で設定したドメイン名 ( www.example.com ) を 項目を追加の下に追加します。 Custom SSL certificate では、パート 2.2 で作成したドメインの ACM 証明書を選択します。 「ディストリビューションを作成」を選択します。 ディストリビューションがデプロイされた後、ディストリビューションのオリジンタブに移動し、オリジンを選択して Edit をクリックします。選択されているプロトコルが HTTPS のみになっていることを確認します。 レイテンシーに基づくルーティングのテスト 異なる地理的位置からのクライアントをシミュレートするため、サンプルアプリケーションをデプロイした AWS リージョン (us-east-1 と us-west-2) に Amazon EC2 インスタンスを 2 つ起動します。 それぞれのインスタンスから、アプリケーションにアクセスするために使用するドメイン名に対して curl を実行します。 今回の演習では、 us-east-1 リージョンのインスタンス 172-31-56-168 と、us- west-2 リージョンのインスタンス 172-31-16-193 からそれぞれ、次のコマンドを実行します。 図 4: クライアントリクエストが最も近い地域から応答される 両方のリージョンが正常に動作して通信を受け入れていたため、それぞれのクライアントリクエストは近くのリージョンから処理されました。 リージョナルフェイルオーバーのテスト ここで、us-east-1 のアプリケーションがメンテナンス中になり、容量に制限のある状況を想定しましょう。テスト目的のため、この リージョンへの通常のトラフィックを別の場所に振り向けるために、ヘルスチェック ステータスを「メンテナンス中」に変更して示しています。 172-31-16-193 から curl リクエストを実行しても結果は同じですが、 us-east-1 リージョンの 172-31-56-168 インスタンスからリクエストすると、異なる応答が得られます。 図 5: 最も近い Region が利用できない場合は、次に近い Region へクライアント リクエストが転送される us-east-1 リージョンがリクエストを処理できないため、リクエストは最も近いリージョンに転送されます。 この例では、サンプルアプリケーションは 2 つのリージョンにしかデプロイされておらず、リクエストは 2 番目のリージョンで処理されています。 3 つ以上のリージョンで構成される環境では、使用できないリージョンからのトラフィックは、エンドユーザーに次に近いリージョンに転送されます。 リージョン間のフェイルオーバーを機能させるには、ヘルスチェックが正しく動作することが不可欠です。つまり、アプリケーション層での信頼できるヘルスチェックのみが、アプリケーションが期待どおり動作し、クライアントリクエストに対応できることを保証します。 最大の信頼性と障害許容性を確保するために、フェイルオーバーメカニズムのデータプレーン機能を活用するよう設計することをお勧めします。 たとえば、ホストゾーンの DNS レコードの更新やヘルスチェック設定 (コントロールプレーン機能) ではなく、Route 53 ヘルスチェックを利用するメカニズム (データプレーン機能) を選択してください。 Route 53 ヘルスチェックを使ってフェイルオーバーシナリオに対処する方法の詳細については、 Amazon Route 53 を使用した災害復旧メカニズムの作成 をご覧ください。 まとめ この投稿では、 CloudFront と Route 53 を使用してマルチリージョンのアクティブ – アクティブアーキテクチャを設計する方法について学びました。 CloudFront は AWS のグローバルネットワークを活用し、セキュリティ、エッジ機能、可用性など他の利点も兼ね備えた高速なコンテンツ配信に使用されます。 Route 53 は、ユーザーの場所から最も近接したリージョンにアプリケーションがデプロイされているレイテンシーに基づくルーティングを設定するために使用されます。 マルチリージョンのアクティブ – アクティブアーキテクチャにこれらのサービスを組み合わせることで、ユーザーに低レイテンシーのエクスペリエンスを提供するのに役立ちます。 開始するためには、 Route 53コンソールを使用したレコードの作成 と CloudFrontディストリビューションの作成 をご覧ください。 本記事は、「 Using latency-based routing with Amazon CloudFront for a multi-Region active-active architecture 」と題された記事の翻訳となります。 翻訳は Solutions Architect の長谷川 純也が担当しました。

本稿は、2023年11月27日に AWS Cloud Operations & Migrations Blog で公開された “ Expand the depth of Well-Architected Reviews with the new Lens Catalog Feature ” を翻訳したものです。 AWS Well-Architected Tool (WA Tool) は、最新の AWS のアーキテクチャの ベストプラクティス に基づいて ワークロード を定義し、 レビュー することを支援します。これにより、ワークロードの強みと改善点を特定することができます。 AWS Well-Architected Review では、AWS WA Tool を利用してアーキテクチャを評価するための 質問 に答え、発見された 高リスクまたは中リスクの問題 の詳細と、リスクを除去しワークロードを最適化するための対応手順がまとめられた 改善計画 を受け取ります。 2021 年には、 カスタムレンズ が AWS WA Tool の新機能として導入されました。カスタムレンズを使えば、業界、業務計画、社内プロセスに応じて、既存の AWS Well-Architected Framework に独自のベストプラクティスを追加できます。カスタムレンズにより、外部のスプレッドシートやサードパーティのシステムに依存することなく、AWS でのワークロードを計測し改善する一貫した方法と、統合されたビューが得られます。 しかし、技術やベストプラクティスは進化し続けるため、お客様はワークロードの改善を進めるうえで、業界や新しい技術に関するベストプラクティスガイダンスを求めるようになってきました。 AWS WA Tool のレンズカタログでは、業界や新しい技術に特化した AWS のベストプラクティス (レンズ) を検索し、ワークロードに適用できます。ビジネスにとって最も重要なトピックに基づいてレビューをカスタマイズできるように、より広範な業界やテクノロジーを提示します。AWS は新しい技術が登場するたびにレンズを追加し続けるので、お客様は常に最新のトレンドに対応できます。 このブログでは、レンズカタログと AWS WA Tool でレンズカタログがどのように動作するのかをご紹介します。 レンズカタログのご紹介 ここから、新しいレンズカタログからレンズをワークロードに適用する方法、レンズを使ってワークロードをレビューする方法、既存のワークロードにレンズを適用する方法について順を追って紹介します。 新しいワークロードにレンズを適用する 1. まず、AWS マネジメントコンソールに移動し、 AWS Well-Architected Tool コンソール を開いて「 ワークロードの定義 」を選択します。 2. ワークロードの定義の手順に従って、ワークロードの必須プロパティを指定し、「 次へ 」を選択します。 3. プロファイル を利用して、組織の特定の優先事項に基づいて Well-Architected Framework Review (WAFR) をカスタマイズすることができます（任意の手順）が、今回は何も設定せず「 次へ 」を選択します。 4. レンズを適用 ページでは、 カスタムレンズ と レンズカタログ が表示されます。 レンズ名で検索 したり、カタログを見てレンズを見つけて選択することができます。その後、「 ワークロードの定義 」を選択します。 レンズカタログで、AWS 公式のレンズのコレクションから、ワークロードに適用できるレンズを探せます。例えば、ヘルスケアサービスを構築する組織は、カタログからヘルスケア業界のレンズを選択して、ワークロードが業界のベストプラクティスに適合しているかレビューすることができます。 5. ワークロードが作成されたら、画面左側のナビゲーションペインでどのレンズが適用されているかを確認できます。また、ワークロード概要ページを下にスクロールすることでも、適用されているレンズを確認できます。 レンズを使ってワークロードをレビューする 1. ワークロードの定義ができた後、ヘルスケア業界のレンズを使ってレビューを開始します。ワークロードページで、「 レビューを開始 」のドロップダウンリストから「 Healthcare Industry Lens 」を選択します。 2. ワークロードのレビュー を使って、レンズの各柱の質問に答えていきます。 3. ベストプラクティスの横にある「 情報 」を選択すると、そのベストプラクティスに関する説明文が表示されます。 4. レンズとワークロードを比較し、各質問でワークロードがベストプラクティスに適合しているかチェックすることができます。選択したレンズの質問に答え終えたら、レンズの概要ページに移動して、特定されたリスクを確認できます。 5. レビュー後、Well-Architected Tool から改善計画が生成され、不足しているベストプラクティスの実装方法に関するガイダンスが提供されます。「 改善計画 」を選択してください。 スクロールダウンすると、リスクレベルや柱でフィルタできる「 改善項目 」が表示され、改善項目毎に「 推奨される改善項目 」にリスクを軽減するための手引きが示されます。 既存のワークロードにレンズを適用する 既存のワークロードの場合も、レンズカタログからレンズを適用できます。 1. ワークロードから対象のワークロード を開き、 レンズ セクションまでスクロールダウンして、「 編集 」を選択します。 2. レンズを適用 ページで、このワークロードにさらに適用したいレンズをレンズカタログから選択します。その後、「 保存 」を選択してください。 例えば、組織が機械学習を使って金融文書を自動処理するワークロードを持っている場合、Amazon Machine Learning Lens を活用して、そのワークロードが AWS のベストプラクティスに沿っているかを確認できます。 3. 更新が完了すると、選択したすべてのレンズがワークロードに適用されたことを確認できます。 この例では、レンズカタログからのさまざまなレンズを活用することで、業界要件、技術の特性、特定のサービスコンポーネントについて、レビューの範囲を広げることができます。 まとめ このブログでは、 AWS Well-Architected Tool のレンズカタログという新機能について説明しました。レンズカタログには業界固有および技術に特化したレンズが含まれており、お客様が自社のビジネスにとって最も重要なトピックに焦点を当ててレビューをカスタマイズできるようにします。この知識を活用して、AWS Well-Architected Tool のレンズカタログを使い、ワークロードの健全性を評価できます。質問やコメントがあれば、クラウドアーキテクトとテクノロジープロフェッショナルが集まり成長中のコミュニティである、 AWS re:Post の一員になりましょう。 著者について Jun-Tin Yeh (Bob) Jun-Tin (Bob) Yeh はアジア太平洋地域の AWS Well-Architected チームの Geo Solutions Architect です。彼はお客様とともに迅速にアーキテクチャを進化させ、クラウドのユーザー体験を改善するために　Well-Architected に関連するあらゆる領域に深く入り込むことを楽しんでいます。 Phong Le Phong Le は、AWS Well-Architected チームの Solutions Architect です。AWS Well-Architected チームの一員としての Phong　の役割は、AWS　のお客様と AWS パートナーネットワーク (APN) パートナーと協力し、それらの組織内で AWS のベストプラクティスの採用を推進することです。 翻訳はソリューションアーキテクトの村田が担当しました。

本ブログは北海道文化放送様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの村木です。 2024 年の AWS Summit では多くの生成 AI 事例が公開されており、生成 AI が世間に広がっていることを実感しております。製造業や金融業などの業界に特化したユースケースが数多く公開されていることが印象的でした。 そんな中、今回紹介するのは、北海道文化放送様で取り組んでいただいた Amazon Bedrock をはじめとしたマネージドサービスを活用し、ニュース原稿 / 動画の作成フローを効率化することで、ニュース動画配信数を増加した事例です。 「とりあえずやってみる」、「ダメだったらやめる」を意識して挑戦いただいていることが、良い結果につながったと考えています。スモールスタートが可能であり、運用費用も低コストなので予算がなくて業務改善に着手できないお客様にとってもぴったりな内容であると思います。また、各業務課題に対して適切なサービスを活用し業務効率化を行った良い例となりますので、生成 AI のみでなく業務改善の観点でもご参考になれば幸いです。 なお、本取り組みは AWS 事例 や AWS メディアセミナー でも紹介されているため、あわせて御覧ください。 事例概要 FAX で送付されたリリース情報を紙で保管しており管理コストの増加につながっている。また、ニュース原稿 / 動画作成に時間を要しており、数多くのニュースを視聴者に提供することができない。 Amazon Bedrock をはじめとしたマネージドサービスを活用することで紙媒体のデータ化、ニュース原稿 / 動画の作成フローの自動化を実施した。 資料管理コストの削減やニュース動画配信数の増加の効果が出ている。 お客様の状況と検証に至る経緯 北海道文化放送様は各市町村などから月に約 1,500 件ほど FAX で送付されるリリース情報を紙媒体で保存しています。それを元に原稿を作成し、文字とイメージ画像、地上波放送の切り抜き動画を Web 記事 として投稿していました。しかし、以下の課題が挙がっておりニュース動画の配信数に限界を感じていました。 紙媒体のアーカイブの手間と検索性の悪さ 記事作成担当の報道部員、動画作成担当の編集部員のリソース不足 動画作成負荷の重さ そこで、 Amazon Bedrock をはじめとしたマネージドサービスを活用し、ニュース原稿 / 動画の作成フローを効率化をするための検証をすることになりました。 ソリューション / 構成内容 本ソリューションはインフラストラクチャの管理、運用が少ないサーバーレスサービスで構成されており、低コストで運用可能です。主な機能は以下の 4 つであり、 Web アプリケーションを利用して一気通貫で管理することができます。 Amazon Polly を利用して記事の読み上げ音声生成 OCR した情報と追加の取材情報を元に Amazon Bedrock で要約し原稿を作成 AWS Lambda を利用した YouTube ショートや TikTok 用のタテ型動画の簡易生成 ※「タテ型動画の簡易生成」画像参照 送付された FAX を複合機で受信し OCR でテキスト化後、 Bedrcock で要約したテキスト情報を DB に格納 「ただ原稿生成するだけ」であれば Claude などの基盤モデルを直接利用することも一つの手段ですが 、AWS を利用することで生成 AI の回答精度を安定させたり、動画作成などの他機能との連携が容易になります。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(出展: 北海道文化放送株式会社) 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　(出展: 北海道文化放送株式会社) 導入効果 システムをリリースした結果、手動で行っていた作業の大部分をシステム化することに成功しました。それに伴い、以下の効果を得ることができました。 検索性向上によるリリース情報の見逃防止、検索工数の削減  Amazon Bedrock による初稿作成、取材情報を取り入れた本稿作成の工数を削減 報道部員のみで原稿作成から動画含めたニュース投稿まで実施可能 地上波放送されていないニュースを動画配信可能となったことで、月間追加配信数が複数プラットフォーム（ YouTube 、 TikTok ）累計で 100~120 本に増加 低コストで大きな効果を得ていることが特徴です。サーバーレスサービスで構築されており従量課金であるため運用コストはおよそ $23 / 月 に抑えられています。構築も IT 担当者ではなく編成担当者がたった一人で構築しており、一つずつ業務改善に取り組み、結果的に一連のフローをすべてシステム化しました。予算が限られているがクラウドや生成 AI を利用して業務効率化に挑戦してみたいお客様にとってもハードルが低い事例となっています。 まとめ 今回は、北海道文化放送様で取り組んでいただいた Amazon Bedrock をはじめとしたマネージドサービスを活用し、YouTube や TikTok へ配信するニュース原稿 / 動画の作成フローを効率化することで、ニュース動画配信数を増加した事例を紹介しました。 冒頭でも触れたとおり「とりあえずやってみる」、「ダメだったらやめる」を意識して挑戦いただいており、従量課金である AWS ととても相性が良い進め方です。最終的な運用費用も安いので予算がなくて業務改善に着手できないお客様にとってもぴったりな内容であると思います。 また、本ソリューションは現在も改善を続けており、 OCR に Claude3 Haiku、文章生成に Claude3.5 Sonnet と基盤モデルを最新に切り替えしています。また、利用者からの要望を受けてリリース情報を受信したら、要約、タイトル、原稿、ジャンルをSlackに送信する機能を追加実装しており、好評を得ているそうです。利用者からの声を元に小さく構築と改善を続けていくことが最も早く効果を得られる方法の一つであるため参考にしていただければと思います。 本ブログから業務改善に取り組む方々が増えていただけるととても嬉しいので、ご興味をお持ちのお客様は、お気軽に AWS の担当者までご相談いただければと思います。 なお、作成された動画は北海道文化放送様の  YouTube や TikTok で配信されておりますのでこちらも是非確認いただけると幸いです。 ソリューションアーキテクト 村木 雄一

はじめに スマートビルやスマートファクトリーには、テレメトリーデータやシステム状態を継続的に収集するセンサーが何百、何千とあります。こうした施設はモニタリングとデータ収集によって、保全業務を「予期せぬ障害」へ事後対応するアプローチから予知保全のアプローチへシフトできるため、業務効率を上げ運用コストを下げることができます。 製造業の生産ライン、倉庫、工場などの産業設備における設備保全の管理者や技術者は、現場の停止時間を減らしたいと考えています。センサーおよびそれが収集する測定値は、メンテナンスを予測する上で貴重なツールです。しかしコンテキストがなければ、それらの情報が全体像を覆い隠してしまうかもしれません。ある 1 つのセンサーの測定値のみに注目するメンテナンス担当者は、無関係に見えかねない重要な関連性を見落とす可能性があります。産業設備を空間的に表示し、複数のセンサーからの測定値を統合した単一のビューを使用すれば、不具合の解決が簡素化され、予知保全が強化されます。 前回のブログ ( Amazon Monitron と Amazon Kinesis により予知保全のためのアクションにつながる洞察を得る方法 ) では、Amazon Monitron から得られた洞察 (人工知能 (AI) または機械学習 (ML) により測定値から得られる予測) を製造現場に取り込んだり作業指示を作成したりするソリューションを紹介しました。本ブログでは、テレメトリーを 3 次元 (3D) 空間に可視化できる AWS IoT TwinMaker と連携した、Amazon Monitron による予知保全のソリューションについて説明します。また、自然言語チャットボットを Amazon Bedrock で実装し、関連するメンテナンス文書や測定値からの洞察にアクセスする方法を紹介します。 ユースケースの概要 AWS IoT TwinMaker と Matterport を使えば、設備の管理者は稼働状況を 3D で可視化し、機器の状態を監視できます。AWS IoT TwinMaker と Matterport の統合により、開発者は Matterport のテクノロジーを利用して、さまざまなデータソースから得られる既存データと実世界のデータを組み合わせ、完全に統合されたデジタルツインを作成できるようになりました。情報を視覚的に提示することで、オペレーターの理解が深まりホットスポットを特定できるので、問題解決の時間を短縮できます。 このソリューションではAWS IoT TwinMaker と Matterport が使用されています。 AWS IoT TwinMaker は次のようなフルマネージド機能を提供することで、開発者が実世界のシステムのデジタルツインを作成するのを支援します。1/ 多様なソースからのデータにアクセス、2/ 物理システムを仮想的に表すエンティティを作成、そのエンティティ間の関係を定義し、データソースに接続、3/ 既存の 3D ビジュアルモデルを実世界のデータと組み合わせて、物理環境の対話的 3D ビューを構築。 Matterport は、実世界の環境をキャプチャ、スキャンし、没入型の 3D モデル (Matterport スペースとも呼ばれる) を作成するオプションを提供します。AWS IoT TwinMaker は Matterport 統合をサポートしており、Matterport スペースを AWS IoT TwinMaker シーンにインポートできます。AWS のお客様は今後、 AWS Marketplace から直接 Matterport にアクセスできるようになります。 ソリューションの概要 次の手順に従って、AWS IoT TwinMaker ワークスペースを作成し、Matterport スペースに接続します。その後、Matterport でタグ付けされたセンサーの位置を AWS IoT TwinMaker エンティティに関連付けます。AWS Lambda 関数を使って AWS IoT TwinMaker のカスタムデータコネクタを作成します。このデータコネクタにより、エンティティを Amazon Simple Storage Service (Amazon S3) データレイクに保存された Monitron のセンサーインサイトに関連付けます。最後に、 AWS IoT Application Kit を使用して、Monitron による予測結果を 3D 空間で可視化します。このブログでは、図 1 のアーキテクチャの “2. Digital twin – 3D Spatial Visualization” のセクションについて詳しく説明します。 図 1: ソリューションのアーキテクチャ概要 前提条件 アクティブな GitHub アカウントとログイン認証情報。 AWS アカウントと IAM ユーザー。 us-east-1 (バージニア北部) または eu-west-1 (アイルランド) リージョンの AWS IAM Identity Center (旧 AWS Single Sign-On)。 Amazon Monitron (センサーとゲートウェイ。詳細は Amazon Monitron の開始方法 を参照)。 iOS (iOS 14.0.0 以降) または Android (バージョン 8.0 以降) で、Monitron モバイルアプリ ( iTunes または Google Play ) がインストールされたスマートフォン。 AWS IoT TwinMaker 統合に必要な Enterprise プランの Matterport アカウントとライセンス。詳細は、 AWS IoT TwinMaker の Matterport 統合 の手順を参照してください。必要に応じて、Matterport のアカウント担当者に支援を求めてください。アカウント担当者がいない場合は、 Matterport and AWS IoT TwinMaker ページの問い合わせフォームを利用できます。 注意 : デプロイする全ての AWS リソースが同じ AWS リージョンにあることを確認してください。また、AWS マネジメントコンソールへのリンクは全て us-east-1 リージョンを指しています。他のリージョンを使用予定の場合は、マネジメントコンソールへのリンクをクリックした後、リージョンを切り替える必要があります。 Monitron のデータエクスポートの設定と ETL (Export, Transfer and Load) パイプラインの作成 このブログシリーズのパート 1 の手順に従って、Amazon Monitron のデータから IoT データレイクを構築してください。 Monitron のスキーマ定義については、 Amazon Monitron Kinesis データエクスポート v2 を参照してください。 注意 : 2023 年 4 月 4 日以降に有効化されたライブデータエクスポートは、Amazon Monitron Kinesis データエクスポート v2 です。この日付より前に有効化されたデータエクスポートは v1 です。このソリューションでは v2 の利用を推奨します。 データレイクの接続プロパティ 構築したデータレイクから以下の情報を記録しておいてください。これらは次のステップで必要になります。 データが保存されている Amazon S3 バケット名 AWS Glue データカタログのデータベース名 AWS Glue データカタログのテーブル名 AWS IoT TwinMaker データコネクタの作成 このセクションでは、デジタルツインとデータレイクのデータを接続する、AWS IoT TwinMaker のカスタムデータコネクタのサンプルについて説明します。AWS IoT TwinMaker を使用する前にデータを移行する必要はありません。このデータコネクタは、AWS IoT TwinMaker がデータレイクにアクセスするために呼び出す 2 つの Lambda 関数で構成されています。 TWINMAKER_SCHEMA_INITIALIZATION 関数は、データソースのスキーマを読み取るために使用されます。 TWINMAKER_DATA_READER 関数は、データを読み取るために使用されます。 注意 : このブログで参照しているすべてのコードは、 この GitHub リンク で入手できます。 Lambda 用の IAM ロールの作成 AWS Identity and Access Management (IAM) で Lambda に引き受けさせる IAM ロールを作成してください。同一の IAM ロールが両方の Lambda 関数で使用されます。このロールに IAM ポリシー を追加してください。 AWS IoT TwinMaker スキーマの初期化用 Lambda 関数の作成 このセクションでは、データレイクのスキーマを取得する Lambda 関数のサンプルコードを提供します。これにより、AWS IoT TwinMaker はデータソース内で利用可能になっている様々な種類のデータを特定できます。 関数名: TWINMAKER_SCHEMA_INITIALIZATION ランタイム: Python 3.10 以降 アーキテクチャ: arm64 (推奨) タイムアウト: 1 分 30 秒 Lambda 関数の ソースコード Lambda 関数の環境変数に、データレイクの接続プロパティを設定します。 キー 値 ATHENA_DATABASE <YOUR_DATA_CATALOG_DATABASE_NAME> ATHENA_TABLE <YOUR_DATA_CATALOG_TABLE_NAME> ATHENA_QUERY_BUCKET s3://<YOUR_S3_BUCKET_NAME>/AthenaQuery/ AWS IoT TwinMaker へのデータ取得用 Lambda 関数の作成 この章では、AWS IoT TwinMaker からのリクエストに基づいてデータレイクからデータを取得する Lambda 関数のサンプルコードを提供します。 Lambda 関数名: TWINMAKER_DATA_READER ランタイム: Python 3.10 以降 アーキテクチャ: arm64 (推奨) タイムアウト: 1 分 30 秒 Lambda 関数の ソースコード Lambda 関数の環境変数に、データレイクの接続プロパティを設定します。 キー 値 ATHENA_DATABASE <YOUR_DATA_CATALOG_DATABASE_NAME> ATHENA_TABLE <YOUR_DATA_CATALOG_TABLE_NAME> ATHENA_QUERY_BUCKET s3://<YOUR_S3_BUCKET_NAME>/AthenaQuery/ ストリームデータを取り込むための AWS IoT TwinMaker コンポーネントとエンティティの作成 AWS IoT TwinMaker のワークスペースをまだお持ちでない場合は、 ワークスペースの作成 の手順に従ってください。ワークスペースは、デジタルツインに関連するすべてのリソースを格納するコンテナです。 AWS IoT TwinMaker ワークスペースを設定する手順は以下の通りです。 TwinMaker コンソールに移動します。 Create workspace を選択します。 ワークスペースの名前 YOUR_WORKSPACE_NAME を入力します。 Create an Amazon S3 bucket を選択します。 実行ロールのドロップダウンから Auto-generate a new role を選択します。 Skip to review and create を選択します。 Next を選択します。 次に Skip to review and create を選択します。 Create Workspace を選択します。 図 2: AWS IoT TwinMaker でワークスペースを作成する IoT データレイクからストリームデータを取り込むには、独自の AWS IoT TwinMaker コンポーネントを作成します。詳細については、 コンポーネントタイプの使用と作成 をご覧ください。 次の JSON サンプルを使用して、AWS IoT TwinMaker がデータレイクからデータをクエリする権限とアクセスを許可するコンポーネントを作成してください。 AWS IoT TwinMaker ワークスペースを開きます。 ナビゲーションペインのメニューから Component Types を選択します。 Create Component Type を選択します。 GitHub リポジトリのファイル をコピーし、画面の Request 部分に貼り付けます。これですべてのフィールドが自動入力されます。 コンポーネントを作成した後は、Athena 経由で Amazon S3 のデータを問い合わせるための Lambda 関数を呼び出すように AWS IoT TwinMaker の実行ロールを設定します。 TwinMaker コンソールを開き、Workspaces area を開きます。 作成したワークスペースを選択します。 ワークスペースで使用されている実行ロールを特定します。 図 3: 実行ロールを特定 IAM コンソール を開きます。 Policies を選択し Create Policy を選択します。 JSON を選択し、 このコード を GitHub からペーストします。<AWS_REGION> と <AWS_ACCOUNT_NUMBER> を実際の値に置き換えます。 Next を選択します。 Review and create ページで、名前として DigitalTwin-TwinMakerLambda と入力します。 Create Policy を選択します。 Roles メニューを展開します。 twinmaker-workspace-YOUR_WORKSPACE_NAME-UNIQUEID を検索し、選択します。 Add permissions を展開し、 Attach policies を選択します。 図 4: ポリシーのアタッチ DigitalTwin-TwinMakerLambda を検索し、選択します。 Add permissions を選択します。 エンティティは、デジタルツインの要素の機能をキャプチャするデジタル表現です。ここでいう「要素」とは、物理的な機器またはプロセスです。エンティティには関連づけられたコンポーネントがあります。これらのコンポーネントは、関連するエンティティのデータとコンテキストを提供します。コンポーネントタイプを選択して、エンティティを作成できます (詳細は 最初のエンティティを作成する を参照してください)。 AWS IoT TwinMaker コンソール に移動します。 ワークスペースを開きます。 ナビゲーションペインで Entity を選択します。 Create を選択し、 Create Entity を選びます。 Create entity を選択します。 図 5: エンティティを作成 作成したエンティティを選択し、 Add Component を選択します。 名前として MonitronData と入力します。 タイプとして com.example.monitron.data を選択します。 Add Component を選択します。 エンティティのステータスが Active に変わったことを確認します。 図 6: コンポーネントのプロパティを追加 エンティティが Active になったら、MonitronData コンポーネントを選択します。利用可能なプロパティのリストが表示されるはずです。 物理環境の 3D デジタルツインの作成 AWS IoT TwinMaker でエンティティを作成したら、そこに Matterport タグを関連付けます (Matterport の使用方法の詳細は、 AWS IoT TwinMaker and Matterport についての Matterport ドキュメントを参照してください)。 AWS IoT TwinMaker Matterport 統合 のドキュメントに従って、Matterport スペースを AWS IoT TwinMaker にリンクしてください。 Matterport スペースを AWS IoT TwinMaker シーンへインポートする 接続された Matterport アカウントを選択し、Matterport スキャンをシーンに追加してください。以下の手順に従って、Matterport スキャンとタグをインポートします。 AWS IoT TwinMaker コンソール にログインします。 Matterport スペースを使用したい新しい AWS IoT TwinMaker シーンを作成するか、既存のシーンを開きます。 シーンが開いたら、 Settings に移動します。 Settings の 3rd party resources の下で、 Connection name を見つけ、 Matterport の認証情報を AWS Secrets Manager に保管する の手順で作成したシークレットを入力します。 次に、 Matterport space ドロップダウンリストを展開し、Matterport スペースを選択します。 図 7: Matterport スペースをインポートする Matterport のタグをインポートすると、Update tags ボタンが表示されます。AWS IoT TwinMaker で Matterport のタグを更新すると、Matterport アカウントの最新の変更が常に反映されます。 シーン内のタグを選択します。このタグにエンティティとコンポーネントを関連付けることができます (手順については、 モデルシェーダー拡張 UI ウィジェットをシーンに追加する のユーザーガイドに従ってください)。 図 8: タグにエンティティを関連付ける Matterport スペースを AWS IoT TwinMaker の Grafana ダッシュボードで表示する Matterport スペースを AWS IoT TwinMaker シーンにインポートすると、Amazon Managed Grafana ダッシュボードで Matterport スペースを含むシーンを表示できます。既に Amazon Managed Grafana を AWS IoT TwinMaker と統合している場合は、Grafana ダッシュボードを開いて、インポート済みの Matterport スペースを含むシーンを表示できます。 まだ AWS IoT TwinMaker を Amazon Managed Grafana 向けに設定していない場合は、そのプロセスを先に完了してください。 AWS IoT TwinMaker を Grafana と統合する際には、2 つの選択肢があります。セルフマネージドの Grafana 環境を使用するか、Amazon Managed Grafana を使用するかです。 次のドキュメントを参照して、Grafana のオプションと統合プロセスの詳細を確認してください。 AWS IoT TwinMaker の Grafana ダッシュボード統合 Amazon Managed Grafana セルフマネージドの Grafana Matterport スペースを AWS IoT TwinMaker Web アプリケーションで表示 AWS IoT Application Kit の Web アプリケーションで、Matterport スペースを含むシーンを表示できます。AWS IoT Application Kit の使用方法の詳細については、次のドキュメントを参照してください。 AWS IoT TwinMaker と AWS IoT Application Kit を使用する方法の詳細については、 AWS IoT TwinMaker UI コンポーネントを使用してカスタマイズされた Web アプリケーションを作成する を参照してください。 AWS IoT Application Kit の詳細については、 AWS IoT Application Kit GitHub ページを参照してください。 AWS IoT Application kit を使用して新しい Web アプリケーションを開始する方法については、 IoT App Kit 公式ドキュメントページを参照してください。 図 9: Matterport を使用した 3D 可視化によるデジタルツインのダッシュボード 図 9 は、AWS IoT Web アプリケーション内の Matterport スペースの 3D 可視化をするダッシュボードです。Amazon Monitron から収集したデータがアラーム状態とともにダッシュボードに表示されています。また、センサーの位置と状態が Matterport 3D 可視化に表示されます。これらの可視化により、現場の保全チームはダッシュボードから直接問題箇所を特定できます。 Amazon Bedrock による生成 AI チャットボットを使用したナレッジへのアクセス テレメトリーの取り込みに加えて、組織には数千ページにわたる標準操作手順、マニュアル、および関連文書が存在する可能性があります。メンテナンスイベントの発生中には、適切な指示を検索および特定するために貴重な時間が失われます。第 3 回のブログでは、生成 AI およびチャットボットなどのインターフェイスを使用することで、既存のナレッジベースの価値を引き出す方法を示す予定です。また、 Amazon Bedrock を使用して、ナレッジベースにより簡単にアクセスできるようにし、ニアリアルタイムな履歴データからの洞察や、Amazon Monitron によるメンテナンスに関する予測を含める方法についても説明予定です。 図 10: Matterport による 3D 可視化と AI アシスタントを備えたデジタルツイン 結論 このブログでは、Matterport の空間内で 3D 表現として視覚化されたテレメトリデータの統合ビューを作成するために、Amazon Monitron からのデータを接続する AWS IoT TwinMaker を使ったソリューションを概説しました。Amazon Monitron は予知保全のためのガイダンスを提供し、AWS IoT TwinMaker では 3D 空間でデータを可視化できます。このソリューションでは、データをコンテキストに応じた方法で提示することで、設備保全のオペレーション改善に役立ちます。デジタルツインの没入型の視覚化を活用したリアルな表現によって、設備保全チーム内のコミュニケーションとナレッジトランスファーも改善できます。また、設備保全チームが課題を特定し、解決策を見つけるプロセスを最適化することもできます。 この連載の最後のブログである「Amazon Monitron, AWS IoT TwinMaker, Amazon Bedrock を用いた予知保全のためのデジタルツインの構築 第 3 部: 生成 AI チャットボットでナレッジにアクセスしてデジタルツインを拡張」では、生成 AI インターフェース (チャットボット) を使用し、情報により簡単にアクセスできるようにします。 この記事はソリューションアーキテクトの中西 貴大が Garry Galinsky, Yibo Liang による記事 Optimize industrial operations through predictive maintenance using Amazon Monitron, AWS IoT TwinMaker, and Amazon Bedrock を翻訳したものです。

AWS では、常に顧客の変化するニーズに応えるためにサービスを革新し進化させています。この記事では、 Amazon CloudSearch と Amazon OpenSearch Service の違いを理解し、OpenSearch Service への移行方法を説明します。 Amazon CloudSearch と Amazon OpenSearch Service の比較 CloudSearch は、ウェブサイトやアプリケーション向けの検索ソリューションを簡単に設定、管理、スケーリングできるクラウドの完全マネージドサービスです。CloudSearch を使用すると、ウェブページ、ドキュメントファイル、フォーラム投稿、製品情報などの大規模なデータコレクションを検索できます。検索の専門家になったり、ハードウェアのプロビジョニング、セットアップ、メンテナンスを心配したりすることなく、検索機能を迅速に追加できます。データ量やトラフィックが変動しても、CloudSearch はニーズに応じてスケーリングします。CloudSearch は内部的にカスタマイズされた Apache Solr バージョンを使用しており、全文検索、ブーリアン検索、プレフィックス検索、タームブースティング、ファセット、ヒットハイライト、オートコンプリート候補などの機能をサポートしています。 OpenSearch Service は、ポピュラーなオープンソース検索・分析エンジンである OpenSearch のデプロイ、運用、スケーリングをシームレスに行えるマネージドサービスです。OpenSearch はベストな検索機能を提供し、CloudSearch のすべての検索機能に加えて、ベクトル埋め込みのセマンティック検索をサポートするベクトルエンジン、密ベクトルと疎ベクトルの両方のサポートを提供します。さらに、OpenSearch Service では、きめ細かなアクセス制御による高度なセキュリティ、オブザーバビリティとセキュリティのためのログデータの保存と分析、ダッシュボードとアラート機能が利用できます。CloudSearch のすべての機能とそれ以上のものが得られます。 OpenSearch Serverless では、改良された、すぐに使える、ハンズフリーの運用が可能です。CloudSearch と同様に、OpenSearch Serverless では REST エンドポイントを通じて OpenSearch をデプロイして使用できます。ドキュメントを OpenSearch Serverless に送信すると、OpenSearch REST API を使用して検索用にインデックスが作成されます。コストと遅延の最適化のためにインフラストラクチャをより深く制御したい場合は、OpenSearch Service のマネージドクラスターデプロイメントオプションを選択できます。マネージドクラスターでは、使用したいインスタンス、インデックス作成とデータシャーディング戦略などをきめ細かく制御できます。OpenSearch Service は、オープンソースの柔軟性と拡張性をもたらし、強力なクエリと分析機能を提供し、成長するワークロードに対してコスト効率の良いスケーラビリティを実現し、高可用性と耐久性を備えています。OpenSearch Service の機能と利点の詳細については、 Amazon OpenSearch Service をご覧ください。 OpenSearch Service への移行 CloudSearch から OpenSearch Service に移行する際は、データを OpenSearch Service に再取り込みしてインデックスを作成する必要があります。OpenSearch Service は REST API を使用するため、ドキュメントのインデックス作成には多数の方法があります。 curl のような標準クライアントや、HTTP リクエストを送信できるプログラミング言語を使用できます。さらに、プロセスを簡素化するために、OpenSearch Service には多くのプログラミング言語用の クライアント があります。データの取り込みには Amazon OpenSearch Ingestion の使用をお勧めします。OpenSearch Ingestion は、OpenSearch Service ドメインまたは OpenSearch Serverless コレクションにデータをルーティングできる、OpenSearch Service 向けに構築された完全マネージドのデータコレクターです。OpenSearch Ingestion は、 Amazon Simple Storage Service (Amazon S3) バケットや HTTP エンドポイントなど、さまざまなソースからデータを取り込むことができ、最も複雑なデータ変換ニーズに対応する豊富な組み込みプロセッサーのエコシステムを持っています。OpenSearch Ingestion はサーバーレスな性質を持ち、最も要求の厳しいワークロードの要件を満たすために自動的にスケールし、複雑なデータパイプラインの管理の複雑さを抽象化しながら、ビジネスロジックに集中できるようサポートします。OpenSearch Ingestion を使用して OpenSearch Serverless コレクションまたはマネージドクラスターにドキュメントを取り込む方法の詳細については、 Amazon OpenSearch Ingestion の使用開始 をご覧ください。OpenSearch Ingestion を使用して OpenSearch Service にデータを取り込む詳細情報については、 Amazon OpenSearch Ingestion を参照してください。 まとめ AWS は引き続き CloudSearch をサポートしており、セキュリティと可用性の改善に投資しています。しかしながら、OpenSearch の進歩による最新の検索機能を利用し、機械学習時代にユーザーが期待する急速な検索体験の進化に対応するためには、OpenSearch Service の検討をお勧めします。 About the Authors Arvind Mahesh は、Amazon Web Services の Amazon OpenSearch Service の Senior Manager-Product です。Analytics、Search、Cloud、Network Security、Telecom など、さまざまな分野で約 20 年の技術経験を持っています。 Jon Handler は、カリフォルニア州パロアルトを拠点とする Amazon Web Services の Senior Principal Solutions Architect です。Jon は OpenSearch と Amazon OpenSearch Service と密接に連携し、AWS クラウドに検索およびログ分析ワークロードを移行したいと考えている幅広い顧客にヘルプとガイダンスを提供しています。AWS に入社する前は、ソフトウェア開発者としてのキャリアで 4 年間、大規模な e コマース検索エンジンのコーディングに携わりました。Jon はペンシルベニア大学で文学士号を、ノースウェスタン大学でコンピューターサイエンスと人工知能の理学修士号と博士号を取得しています。 本投稿はソリューションアーキテクトの榎本が翻訳いたしました。原文は こちら です。

はじめに コネクティッド・カー・プラットフォームを活用すれば、フリートオペレーターは車両の位置情報、使用状況、ステータスについてニアリアルタイムのデータを取得できます。このようなデータをすぐに利用できることは、フリートオペレーターがより効率的にフリートを管理、運用コストを削減、ドライバーのパフォーマンスを改善し、車両のダウンタイムを短縮できます。コネクティッド・カー・プラットフォームは、自動車メーカー (OEM) にとっても、自社の遠隔操作ソリューションを、優れた付加価値サービスとして法人顧客に提供する機会をもたらします。しかし、コネクティッド・カー・プラットフォームの構築には課題もあります。独自のデバイス・ソフトウェアを構築し、いつ、どのような条件でデータを収集かを指示するオーケストレーション機能を開発し、データを復号および処理し、最後にデータを整理してお客様に有用な分析情報を提供する必要があります。 AWS IoT FleetWise のような AWS サービスは、このような課題に伴う大きな負荷を軽減し、ソリューションを迅速に構築できます。 Volta Trucks は、イギリスのロンドンに本社を置く商用の電気トラックメーカーです。最近では、都市部での走行を想定した完全電気式の 16 トントラック Volta Zero を発表し、2024 年後半から納車を開始する予定です。Volta Trucks は、車両の予知保全、ルート最適化、パフォーマンス管理を提供するデジタル・カー・プラットフォームの立ち上げも控えています。このプラットフォームでは、データ収集とガバナンスを実現し、コストを削減、そして車両の運用を迅速に調整・改善できるデータ主導型の機能を提供します。リアルタイムのデータ分析により、Volta Trucks は生成 AI 機能を活用し、車両の稼働率、フリートマネージャーの生産性、ドライバーの快適性向上を図ります。 図 1: Volta Zero は、走行距離が最大 200km (125 マイル)、最高時速が 90 km/h (56 マイル/時) の電気トラック。 「当社の顧客は運送会社、フリートマネージャー、ドライバーで、柔軟性と個別化への要求はそれぞれ異なります。AWS IoT FleetWise を使えば、必要なデータに焦点を当てたデータ収集キャンペーンを構築し、顧客と車両ユーザー向けにカスタマイズした分析と機能を提供できます。必要な時に必要なデータだけを収集することで、新しいソリューションを構築し、ドライバーのミッション、コンテキスト、要求に合わせて車両を AI 化できるサービスを開発できるのです。」 –  Volta Trucks 最高技術責任者 兼 最高情報責任者 Martin Hofmann ソリューションの概要 Volta Trucks は、必要となる様々なデータポイントを車両から収集するコネクティッド・カー・プラットフォームを構築し、社内外の顧客のためにフリート全体の洞察を抽出する基盤を整えました。プラットフォームを構築する上での課題は、トラックから生成される膨大なデータの転送およびストレージコストを削減しながら、顧客に対して意味のあるニアリアルタイムの洞察を提供する方法を決定することでした。 Volta Trucks は、AWS の IoT FleetWise をプラットフォームの基盤としています。このプラットフォームでは、ルールベースのデータ収集が可能で、特定の車両タイプの温度や速度の変化などのパラメーターに基づいて、クラウドにデータを転送するためのルールやイベントを Volta Trucks が定義できます。Volta Trucks の顧客は、コネクティドカープラットフォームをアセット追跡に活用することが多く、電気トラック Volta Zero の重要な車両テレメトリと位置情報をニアリアルタイムで追跡する必要があります。 EV ラリー – ロンドンからジュネーブへ 機能のデモンストレーションとして、AWS IoT FleetWise 対応のコネクティッド・カー・プラットフォームに接続された Volta Zero は、ロンドンからジュネーブへ 2,000 km を超える往復の旅に成功しました。このイベントは、ゼロエミッションカーと技術の限界を試すために作られた EV ラリー  の一環として、6 月 22 日から 24 日まで行われました。以下の画像は、レース中に有効化された機能と、収集されたデータのタイプを示しています。例として、位置情報、気温、バッテリー残量などです。 図 2: 車両の地理位置情報。 図 3: 外気温、ブレーキと加速。 図 4: 充電状態 (SoC) のリアルタイム洞察とデータ収集。 ソリューションの手順 車両ドメインでは、Volta Trucks 社が Linux ベースの車載制御ユニット (TCU) 上に、AWS IoT FleetWise 用の Edge Agent を導入しました。同社の Edge Agent は オープンソース C ++ ライブラリのセット で、車両がクラウドに接続し、どのデータをどのような条件で収集するか、クラウドからの指示を受け取ります。 Volta Trucks の技術者は、クラウド上で AWS IoT FleetWise API を使用して、車両のナレッジグラフを作成し、車両全体でシグナル、センサー、アクチュエータの標準化されたデータディクショナリー (300 以上のデータポイント) を提供します。さらに、これらのデータポイントに対する復号ルールを設定し、それらを車両ドメインに渡すことで、AWS IoT FleetWise が生の バイトデータを人間が読めるデータに変換できるようになりました。最後に、時間ベースとイベントベースの両方のキャンペーンを使って GPS 位置情報、走行距離計の読み取り値、バッテリーの状態などのデータを定期的に収集するため、 AWS IoT FleetWise を使用しました。 一つずつ手順を見ていきましょう: Volta の AWS IoT FleetWise Edge エージェントが車両にデプロイされます。 AWS IoT Core を使用して車両と AWS 間の接続が確立されます。 AWS IoT FleetWise は、AWS IoT Core の接続を使用して、データキャンペーンと復号情報を車両にプッシュします。クラウド上で、AWS IoT FleetWise はキャンペーンや車両識別子と、タイムスタンプ情報を追加することでデータを強化します。 AWS IoT FleetWise は、  Amazon CloudWatch にサービス・メトリクスとログを自動的に収集することで、チームが必要に応じて簡単にトラブルシューティングを行えるようにしています。 収集された車両データは、 Amazon Timestream と Amazon S3 へ送信されます。その後、データに対して自社の分析と洞察のプラットフォームで問い合わせ及び分析を行います。 Volta チームは、トラックが切断され、再接続したタイミングを追跡するための簡単なアラートシステムも設定しています。このアラートでは、AWS IoT Core の ライフサイクルイベント を使用し、これらのイベントを ルール を使って Amazon SNS トピックにパブリッシュしています。オペレーターは、このトピックをサブスクライブできるため、車両が長時間接続されていない場合に適切な対応ができます。 Volta は ARM ベースの Graviton インスタンス に、テスト目的で AWS IoT FleetWise エージェントをデプロイし、車両をシミュレートすることで開発のフィードバックサイクルの短縮を可能にしています。 まとめ Volta Trucks は、 AWS IoT FleetWise を活用することでコネクテッド・カー・プラットフォームを構築し、商用車両の顧客に対して、ニアリアルタイムで車両の追跡、運転手の行動監視、車両の状態と健全性の評価などの機能を提供することができるようになりました。 Volta Trucks は、 AWS のサービスを活用することで、このような機能を迅速に開発することができ、スケーラビリティを実現するために開発を繰り返し行うことで、市場投入までの時間を短縮することができました。詳しくは、 AWS IoT FleetWise サイトをご覧ください。皆様からのご意見・ご質問をお待ちしています。 About the Authors Akshay Tandon は、Amazon Web Services のAWS IoT FleetWise チームのプリンシパル・プロダクト・マネージャーです。あらゆる自動車とプロダクトに情熱を持っており、顧客の声に耳を傾け、ニーズを満たすための革新的な製品やサービスを構想することに喜びを感じています。 Amazon では、Akshay は Alexa による AI/ML 分野と、Amazon Transportation Services によるフリート管理分野での製品イニシアチブを主導してきました。 10 年以上の製品管理の経験があります。 Nuno Seco は、AWS を活用することでスタートアップ企業の成長を加速できるよう支援するシニア・ソリューション・アーキテクトです。 25 年以上のソフトウェア エンジニアリング経験を持つ彼は、様々なトレードオフを理解し、スタートアップ企業が十分な情報に基づいて適切な意思決定が行えるよう支援しています。 Marco Massara は、AWS 自動車および製造業ビジネスユニットのプリンシパル・ビジネス・デベロップメント・マネージャーであり、ソフトウェア・デファインド・ビークルとコネクテッド・モビリティに関する主要な取り組みで EMEA の自動車顧客を支援しています。 この記事は Akshay Tandon, Nuno Seco, Marco Massara によって書かれた How Volta Trucks built a connected vehicle platform using AWS IoT FleetWise の日本語訳です。この記事は 広域事業統括本部 ソリューションアーキテクト 久次米が翻訳しました。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 みなさん他国のAWS Summitはチェックされていますか？先日行われたAWS Summit New York 2024ではAmazon BedrockやAmazon Qに関連した多くの生成AI機能が発表されました。そこで発表された機能をいくつかのデモを交えてご紹介するセミナーが予定されています。ご都合つけばぜひご参加ください。 2024年8月1日 10:00-11:00 – AWS の生成 AI 最新機能をキャッチアップ！ それでは、先週の主なアップデートについて振り返っていきましょう。 2024年7月22日週の主要なアップデート 7/22(月) Amazon VPC IPAM now supports BYOIP for IPs registered with any Internet Registry Amazon VPC IPAMが任意のインターネットレジストリに登録されたIPアドレスのBring Your-Own-IPをサポートしました。BYOIP を設定する際、AWS は、お客様が AWS に持ち込む IP アドレス空間をお客様が管理していることを検証しますが、これまでIPAMは登録データアクセスプロトコル（RDAP）による検証のみをサポートしていましたが、すべてのインターネットレジストリがサポートしているわけではありませんでした。DNS レコードを使用してIPアドレスが自分のものであることを確認できるようになったためJPNIC、LACNIC、AFRINICなど、これまでサポートされていなかったインターネットレジストリでもBYOIPが可能になります。この機能は中国を除くすべてのAWSリージョンで利用できます。詳細はIPAMの ドキュメント をご確認ください。 Amazon MQ now supports quorum queues for RabbitMQ 3.13 Amazon MQがquorum queuesをサポートしました。quorum queuesはRabbitMQが提供するデータ一貫性と耐障害性に優れたキューのタイプで、従来のmirrored queuesと比較して最大2倍、スループットが向上します。Amazon MQでquorum queuesのサポートはRabbitMQ 3.13以降のみで、Amazon MQが利用可能なすべてのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Connect Contact Lens now provides generative AI-powered summaries within seconds after a contact ends Amazon Connect Contact LensのAIを活用した問い合わせ後の概要生成が、これまでの数分から数秒へとパフォーマンス向上しました。これにより連絡後にスムーズにアフターコールの作業に取り掛かれる他、APIやKinesis Data Streamsを介してCRMシステムとの連携も可能です。この機能は米国西部（オレゴン）および米国東部（バージニア北部）の2つのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon DocumentDB announces improvements to document compression Amazon DocumentDB(MongoBD互換)がクラスターの既存のコレクションへの圧縮や、コレクションごとの圧縮閾値の設定など機能強化されました。これまでは新しい圧縮コレクションを作成し移行する必要がありましたが、今回のアップデートによりそれをせずとも既存のコレクションを圧縮し、最大7倍のサイズ縮小を行うことでストレージコスト、I/Oコストの削減、クエリパフォーマンス向上が見込めます。これらの機能向上はDocumentDBが利用可能なすべてのリージョンのDocumentDB 5.0 インスタンスベースのクラスターでサポートされます。詳細については ドキュメント をご確認ください。 Amazon DocumentDB now supports change streams on reader instances Amazon DocumentDB(MongoBD互換)がリーダーインスタンスでの変更ストリームをサポートするようになりました。これによりライターインスタンスの負荷を軽減できます。変更ストリームはリーダー、ライター間で共有できるため、クラスターフェイルオーバーやメンテナンス中は任意のDocumentDBインスタンスから変更ストリームを再開できます。このアップデートはAmazon DocumentDB 5.0インスタンスベースのクラスターと、Amazon DocumentDB がサポートされているすべてのリージョンにあるグローバルクラスターで利用できます。 詳細は ドキュメント をご確認ください。 7/23(火) Meta Llama 3.1 generative AI models now available in Amazon Bedrock Meta社のLlama 3.1がBedrockで利用できるようになりました。Llama 3.1には8B, 70B, 405Bのパラメーターサイズのモデルがあり、405Bは現時点で公開される中で最高かつ最大の基礎モデルの1つです。Llama 3.1はLlama 3の16倍の128Kのコンテンツ長をサポートしておりより複雑なコンテキストを前提とした会話に対応できる他、8つの言語での多言語対話の推論が改善されています。Llama 3.1モデルは、米国西部 (オレゴン) リージョンでご利用いただけます。405Bは当初はプレビューでしたが、現在はGAしています。（7/26のアップデートも参照）詳細については ドキュメント と ブログ をご確認ください。 Meta Llama 3.1 generative AI models now available in Amazon SageMaker JumpStart 一つ前で紹介のAmazon Bedrockと同様にAmazon SageMaker JumpStartでもLlama 3.1が利用できるようになりました。SageMaker Studioから数クリックで、またはSageMaker Python SDKでプログラム経由でデプロイして利用することも可能です。SageMaker JumpstartでのLlama 3.1は米国東部 (オハイオ)、米国西部 (オレゴン)、および米国東部 (バージニア北部)の３つのリージョンで利用可能です。詳細は ドキュメント と ブログ をご確認ください。 Amazon EKS introduces new controls for Kubernetes version support policy Amazon EKSのKubernetes バージョンポリシーの新しいコントロールが発表されました。これによりEKSの延長サポートを利用するかどうかをクラスター単位で設定できるようになり、延長サポートを適用したくないクラスターは標準サポート終了時に自動的にアップグレードの対象になるよう設定することが可能です。これによりコスト最適化が可能です。この機能はすべてのAWSリージョンで利用できます。詳細は ドキュメント をご確認ください。 AWS Mainframe Modernization Code Conversion with mLogica is now generally available AWS Mainframe ModernizationのmLogicaによるコード変換が一般提供開始されました。mLogicaとAWS M2の連携は昨年のre:Inventで発表されていましたが、mLogicaはアセンブラで記載されたレガシーコードをCOBOLに自動変換するプロダクトです。多くのメインフレーム環境にはCOBOLに限らず保守が難しく費用がかかるアセンブラコードが含まれており、この機能追加によりメインフレームモダナイゼーションにおけるブロッカーを排除することが可能です。詳細は ドキュメント をご確認ください。 7/24(水) AWS Signer open sources Notation plugin for container image signing コンテナイメージの署名に利用するNotation用のAWS Signerプラグインがオープンソース化され公開されました。これによりAWS Signerを利用してどのようにコンテナイメージの署名、検証がされているのか確認できるようになりました。オープンソースとして公開されたことで、たとえばGoLangライブラリとして追加することで実行ファイルとしてインストールして呼び出す必要がなくなります。AWS Signer プラグインはApache 2.0 ライセンスとして管理されます。詳細は GitHubのリポジトリ や ブログ をご確認ください。 Mistral Large 2 foundation model now available in Amazon Bedrock Mistral Large 2（24.07） foundation modelがAmazon Bedrockで一般提供開始されました。このモデルはMistral AIの主力モデルの最新バージョンであり、英語、フランス語、ドイツ語、スペイン語、イタリア語、中国語、日本語、韓国語、ポルトガル語、オランダ語、ポーランド語、アラビア語、ヒンディー語など、数十の言語で情報をシームレスに処理できます。コンテキストウィンドウも前バージョンの32kから128kに拡大され、より多くの情報を処理することが可能です。Mistral Large 2は米国西部 (オレゴン) リージョンの Amazon Bedrock でご利用いただけます。詳細については、 ローンチブログ もご確認ください。 AWS DataSync expands support for agentless cross-region data transfers to include opt-in regions AWS DataSyncがリージョン間でのクロスリージョンデータ転送をエージェントレスで実行できるようになりました。DataSyncはデータ転送にあたりエージェントをデプロイ・管理する必要がありましたがそれが不要になり、オペレーションを簡素化することができます。また、対象のリージョンにはオプトインリージョンも含まれます。この機能はData Syncが利用可能なすべてのAWSリージョンで利用可能です。詳細は ドキュメント もご確認ください。 7/25(木) Announcing 24 months support for Amazon EMR Amazon EMRのリリースバージョンサポートについてアナウンスがありました。今後、EMRはリリース日から24ヶ月間の標準サポート対象となります。この期間はセキュリティ、バグ、データ破損などの関連する重大な問題に対して、アップストリームの修正取り込みに90日以内の目標が設定されます。24ヶ月を過ぎたバージョンは12ヶ月間のサポート終了段階(EoS)に入ります。EoSの期間は、クラスターへのアクセスは引き続き可能ですが、テクニカルサポートやアップストリームの取り込みに関して制約があります。EoS終了後にサポート終了(EoL)となります。特に現在稼働するバージョンなど例外的な期間が設定されている場合がありますので、ライフサイクルの詳細や各バージョンの時期一覧などは ドキュメント の記載をご確認ください。 AWS Step Functions now supports Customer Managed Keys AWS Step Functionsが、KMSで管理する顧客鍵を使ったステートマシンとアクティビティリソースの暗号化に対応しました。ワークフロー定義や実行データを暗号化できるため、より機微なシステムにおいてもご活用いただけるようになります。昨日の詳細については Step Funitonsのドキュメント と KMSのドキュメント をご確認ください。 Amazon SageMaker launches faster auto-scaling for Generative AI models Amazon SageMaker Inferenceが生成AIのモデル呼び出し需要に応じてこれまでより高速にオートスケールできるようになりました。この機能はCloudWatchのメトリクス（モデルごとの同時リクエストと、モデルコピーあたりの同時リクエスト数）を元にします。10秒間隔で出力されるこのメトリクスを元に、オートスケーリングポリシーで定義した閾値に達した場合1分以内にインスタンスまたはモデルコピーの追加を開始します。この機能は中国とAWS GovCloud (米国)を除く Amazon SageMaker Inference が利用可能なすべての AWS リージョンのアクセラレータインスタンスファミリー (g4dn、g5、g6、p2、p3、p4d、p4、p5、inf1、inf2、trn1n、trn1) で利用可能です。詳細は ブログ もご確認ください。 AWS Clean Rooms launches new capabilities for entity resolution, ML modeling, privacy, and analysis controls AWS Clean Roomsで AWS Entity Resolution の一般提供、データ分析のプライバシー管理機能の追加、分析結果を受け取るコラボレーターを設定する機能、SQLを使用して類似モデリング用のシードデータを生成する機能の４つのアップデートがありました。AWS Entity Resolutionの統合により複数データソースのレコード照合や重複排除が容易になる他、SQLの特定の出力列の制御や、分析結果を受け取るコラボレーターを簡単に選択可能になるなどプライバシー管理機能の強化によりセキュアな情報を保護しながらより柔軟に使用できるようになりました。詳細に関しては ブログ をご確認ください。 7/26(金) Meta Llama 3.1 405B now generally available in Amazon Bedrock Meta社のLlama 3.1 405BがBedrockで一般提供が開始されました。7/23(火)の時点では405Bのモデルはプレビューとしてアクセスリクエストが必要でしたが、正式に一般提供がされた形です。他のLlama 3.1モデル同様、提供リージョンは米国西部（オレゴン）となっています。詳細については ローンチブログ もご確認ください。 最後に、冒頭に紹介したAWS の生成 AI 最新機能をキャッチアップ！8月8日に「最新事例からはじめる生成AI活用」が開催されます。金融から製造まで様々な業種の事例やデモをご紹介予定です。よかったらこちらもチェックしてみてください。 2024年8月8日 14:00-16:00 – 最新事例からはじめる生成AI活用 それでは、また来週！ 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本ブログは、RIZAP テクノロジーズ株式会社と Amazon Web Services Japan が共同で執筆しました。 RIZAP グループ は、現在約 1500 店舗まで拡大した chocoZAP 事業や、約 60 社のグループ企業を持つ RIZAP グループの各事業において、従業員向けの資料や手順書が膨大な量になっていたことから、ドキュメントやマニュアルの所在を探すのが難しく、現場業務の効率化が課題となっていました。 そこで同社は、社員が自身で質問できる「社内問い合わせ検索システム( AI チャットボット)」の開発を決めました。このシステムでは、生成 AI を活用し、従業員からの質問に対して対話形式で分かりやすい回答を自動生成します。 具体的な利用方法は、従業員がチャットボットに質問を入力すると、生成 AI モデルがその質問に対する最適な回答を社内文書から探し出し、自然な文章として出力します。   写真 1 : ライザップ店舗 システム構成について この AI チャットボットのシステム構成は、以下のようになっています。 フロントエンド側では、 Amazon Route 53 、 Amazon CloudFront 、 AWS WAF などを用いてウェブアプリケーションを構築し、 AWS Certificate Manager による SSL/TLS 証明書の発行や DNS 設定も行っています。 バックエンド側では、 Amazon API Gateway と AWS Lambda を経由して、 Amazon Kendra が Amazon S3 のデータソースや FAQ を参照しながら自然な回答を生成します。さらに、一部のプロンプトに対しては Amazon Bedrock が動作するようになっています。 図 1 : 全体アーキテクチャ   また、社内の業務データを保存している Microsoft SharePoint から S3 にアップロードされたファイルは、Lambda と SharePoint API を使って S3 に自動で転送されるようになっています。社内の閉じられた環境の中で保有しているデータを活用した RAG( Retrieval Augmented Generation: 検索拡張生成 )の構成で構築しており、社内独自の RIZAP のトレーナー、従業員が見るマニュアル（店舗業務：ボディメイク、マシンメンテナンス、商品等、全店通達、福利厚生、研修）など約 3000 ファイルが検索対象のデータとなっています。そのデータは PDF、Word、Excel、PowerPoint など様々な形式がありますが、そのまま S3 に保管するだけでよく、あとは定期的に Kendra がクロールする仕組みを設定しているのみです。 こうした構成により、RIZAP グループの業務効率化が実現されています。一次問い合わせをチャットボットで処理することで、従業員が情報へのアクセスに要する時間を大幅に削減できます。さらに、新人社員やアルバイトの立ち上がり工数の削減にも役立っています。従来は上司や先輩に質問する必要がありましたが、「社内問い合わせ検索システム( AI チャットボット)」を使えば自力で情報を得られるようになりました。 写真 2 : ライザップジム内写真 このシステムの導入によって業務の効率化が進み、月あたり約400 件(平均対応時間 20 分/件)あった業務ヘルプへの問い合わせが削減され、顧客満足度の向上にもつながったと評価しています。必要な情報にすばやくアクセスできるようになり、より質の高いサービスを提供できるようになったからです。 開発を手がけた同社のプロダクト開発統括 2 部 部長の永嶋義憲氏は「AWS との協業により、AWS Associate レベルの開発者 2 名が約 1 か月で開発を完了できました」と語っています。生成 AI と AWS の各種サービスを組み合わせることで、短期間で革新的なソリューションを構築できたことがうかがえます。 生成 AI ソリューションの運用について 現在は RIZAP の実証実験の対象店舗でトレーナー向けに利用を開始しており、業務部門 3 名、IT 部門 3 名で体制を組み、全社展開に向けて週次で精度改善を行っています。入力ワードを週単位でリスト化し、そのワードに対して適切な返答ができているかを確認し、不足している情報があれば、追加でデータを補完することを店舗責任者とともに継続的に行っています。導入しておしまいではなく、日々変わっていくビジネスにも追随させていくことも生成 AI ソリューションには必要になります。店舗責任者と密な連携が取れており、常にフィードバックを得ながら情報連携し、精度改善だけでなく、機能の改善をしているところが、成功の要因と考えています。 追加機能として、回答に対する評価が入力できるような、Like/Dislike ボタンや、精度に関する運用ダッシュボードについても検討しています。 今後の展望 現在 RIZAP 店舗の全国 120 店舗への本ソリューション展開にむけて、対象店舗での導入が始まり、日々精度改善を行いながら機能拡張を行っています。次のステップとしては、RIZAP グループのアパレルを扱う JEANS MATE （ジーンズメイト）や、インテリア雑貨を扱う HAPiNS （ハピンズ）などの店舗においても、本生成 AI ソリューション導入を計画しています。これから対象店舗拡張に伴う、本ソリューションの耐久性やコスト増についても対応を進めており、Claude３への切り替えも視野にいれています。 さらにデータソースの拡充を予定しており、社内システムや各種ツールからのデータ連携の開発を予定しています。 図2 : 効果と注意点スライド   また現在は、社内業務改善での生成 AI の活用をしていますが、今後は chocoZAP などの一般利用者を対象として生成 AI ソリューションも検討をしています。 まとめ RIZAP の取り組みは、生成 AI がビジネスの課題解決に貢献できる有力なテクノロジーであることを示した好例と言えるでしょう。生成 AI を活用したイノベーションにより、業務効率化と顧客サービス向上を同時に実現できることが実証されました。今後も、さまざまな業界や分野で生成 AI の活用事例が増えていくことが期待されます。フィットネスに限らず、店舗ビジネスに共通した課題の解決に役立つ仕組みになっており、生産性の向上と顧客満足度の改善に寄与することができます。企業は、このテクノロジーを積極的に取り入れ、競争力の強化につなげていくことが重要だと考えています。 著者について 戸塚 智哉 戸塚智哉は、飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 先週の月曜日、7 月 22 日に発表した「 AWSジャパン生成AI実用化推進プログラム 」ですが、たくさんのお客様に興味を持って頂いています。ありがとうございます。 Webページ のフォームから意思表明をしていただくこともできますが、AWSのお客様担当がついている場合は、担当に声をかけていただく形でもOKです。最初にどういう課題の解決を目指すのかをクリアにして、その上で最適なアプローチを考える仕組みになっていますので、ぜひご検討ください。 また、8 月 8 日には「 最新事例からはじめる生成AI活用 」というイベントを開催します。生成AIの活用に取り組む際は、なにをどう解決するかが最も重要です。その助けになるのは事例で、事例をベースにしつつ自分達の目標を定めるやり方は、有効なアプローチのひとつです。 それでは、7 月 22 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AWS Trainium、AWS Inferentia が AWS 上の Llama 3.1 モデルに高性能と低コストを提供」を公開 AWSが機械学習のために開発したアクセラレータLlama 3.1モデルのファインチューニングや推論に対応しています。この記事ではLlama 3.1をトレーニング用のAWS Trainiumと、推論用のAWS Inferentiaで稼働させる方法を解説します。以前の記事ではLlama 3をTrainium/Inferentiaのインスタンスにデプロイする方法を説明しましたが、今回はLlama 3.1です。各種サンプルコードも用意していますので、ぜひ触ってみてください。 ブログ記事「AWS Step Functions ワークフローによる Amazon Bedrock モデルカスタマイズの自動化」を公開 Amazon Bedrock では用途に応じて様々な基盤モデルを選択して利用することができますが、独自のデータを利用して基盤モデルの応答をカスタマイズすることで、さらに目的に沿った出力を得ることができるようになります。このブログ記事は、分散アプリケーションのワークフローを制御する AWS Step Functions を利用し、Bedrockで稼働するモデルのカスタマイズを自動化する方法を解説しています。サンプルコードもついていますので、実際に動かしてみることもできますのでぜひ試してみてください。 連作ブログ「生成 AI で加速する e コマースの変革」を公開 eコマース業界のお客様でも、生成AIの利活用はホットなトピックになっています。この連作ブログは「 その1 」として典型的な課題とその解決案を整理し、「 その2 」で解決策の実装サンプルとしてAWS Summit Japanで展示したデモの解説を行っています。差別化につながらない作業の削減と、顧客体験のパーソナライズがテーマとして取り上げられていますので、eコーマス業界以外の方にも参考になるかもしれませんので、ピンときたらぜひご一読を。 ブログ記事「【開催報告】生成AI ユースケース創出 Boot Camp in 大阪」 6月末にAWSジャパンの大阪オフィスで「生成AIユースケース創出 Boot Camp」というイベントを開催しました。このブログはそのイベントのレポートです。AWSから情報共有を行うセッションはもちろん、お客様による事例登壇やハンズオンなど盛りだくさんのコンテンツでお送りました。一部のセッションについては資料も公開されていますので、ぜひごらんください。 サービスアップデート Amazon BedrockでMeta Llama 3.1が利用可能に Amazon BedrockでMeta社のLlama 3.1をオレゴンリージョンにてご利用頂けるようになりました。Llama 3.1は8B、70B、405Bのモデルが用意されており、用途に応じて最適なものを選択して利用することができます。Meta社によるとLlama 3.1は一般的な知識の解答、数学、ツールの利用、多言語翻訳に必要な機能を提供するとされています。 ブログ記事 もあわせてどうぞ。ちなみに発表当日は405Bについては限定プレビューでしたが、現時点では 一般利用開始 になっています。 Amazon SageMaker JumpStartにてMeta Llama 3.1が利用可能に トレーニング済みのモデルを即座に起動し、開発や利用を素早くはじめられるAmazon SageMaker JumpStartでもMeta社のLlama 3.1をご利用頂けるようになりました。リージョンはバージニア、オレゴン、オハイオとなります。 ブログ記事はこちら です。 Amazon BedrockでMistral Large 2が利用可能に Mistral AIのMistral Large 2(24.07)モデルをAmazon Bedrockでご利用頂けるようになりました。このモデルは日本語や英語をはじめとする数十の言語の処理に対応し、会話、コーディング、推測、指示に応じた動作の精度が向上しているとのことです。Mistral Large 2(24.07)はオレゴンのリージョンでご利用頂けます。 ブログ記事はこちら をご覧ください。 Amazon SageMakerの推論エンドポイントにおいて素早くオートスケーリングを発動可能に Amazon SageMakerで2つのメトリクスの情報取得頻度が詳細化され、これによって推論リクエストに応じたインフラストラクチャの自動スケーリングをより素早く実行できるようになりました。負荷の増加が発生すると、1分以内に新しいインスタンスの起動やモデルのコピーを開始し、負荷に対応できるリソースを準備します。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 本日 7 月 22 日に、 2つのウェブサイトを公開しました。 日本の生成AI活用を支援 このウェブサイトは、生成AIの利活用に取り組む方のための情報ポータルで、日本国内の事例やユースケース、サービスアップデート情報、ベストプラクティスなどをまとめます。生成AIに関するワンストップの情報源としてご利用頂けるものです。 AWSジャパン生成AI実用化推進プログラム こちらは 6 月 20 日、21 日に開催した AWS Summit Japan の基調講演で予告した、生成AIによってビジネス課題解決に取り組むお客様を支援するためのプログラムのサイトです。プログラム概要とともに、参加希望を表明するためのフォームもご用意していますのでぜひご覧ください。 また、AWS ブログでは 7 月 10 日、11 日に開催した AWS Summit New York のアップデートに関するブログ記事の翻訳が各種出そろっています。先週概要をご紹介したので改めてピックアップするのはやめておきますが、 「AWS Summit New York」のカテゴリ で絞り込んでいただくと一覧できますので、こちらもあわせてどうぞ。 それでは、7 月 15 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 丸紅株式会社様、社内生成AIプラットフォームアプリで業務時間削減と業務高度化を実現 丸紅株式会社 様は、社内生成AIプラットフォームアプリ(Marubeni Chatbot)を展開しています。Marubeni Chatbotはファイルチャットアプリ、音声認識チャットアプリ、カスタムボットアプリなど複数の機能を提供し、社内で既に7,500名以上のユーザが利用しているそうです。内部的にRAG(検索拡張生成)を活用しているのですが、精度や一貫性を保つための工夫として、WordやPDFで記載された文書をMarkdown形式に自動変換する工夫をしていることや、LangChainを利用せず自社開発の抽象化レイヤーを用いている点がユニークです。導入効果については、業務ごとにばらつきはありますが25%-65%の時間削減効果があり、業務の内容が高度化したというフィードバックが得られています。今後、経営判断の高度化に活用することを目指した機能拡充を進めているとともに、AIを使い倒す企業文化の醸成をすすめているそうです。 AWS生成AI国内事例ブログ: jinjer株式会社様、ユーザ体験向上のための人事問い合わせAI機能を3ヶ月で開発 jinjer株式会社 様は、人事関連業務の効率化を支援する「 ジンジャー 」というSaaSサービスを展開しています。カスタマーサクセスのチームがお客様からヒアリングしたところ、従業員が必要な情報を探す手間がかかる、情報が見つからない場合は人事担当者が対応するがその工数が少なくない、という課題があることがわかりました。その解決のため、生成AIによる問い合わせ対応機能の開発を決断されました。Amazon BedrockとAmazon KendraによるRAG(検索拡張生成)の仕組みですが、3ヶ月という短期間での開発に成功し、AIによる問い合わせ対応機能により80%の工数削減を見込んでいます。また、フルマネージドサービスの活用による保守運用負荷の軽減もひとつのポイントです。今後の計画として、マルチモーダルなモデルを活用した新機能の開発に取り組んでいらっしゃるとのことです。 ブログ記事「生成AIアプリケーションのデータベース選択における重要な考慮事項」を公開 生成AIを搭載したアプリケーション、特に検索拡張生成(RAG)を活用する場合は、何らかのデータベースが必要不可欠です。AWSでは様々なデータベースサービスでベクトル検索の機能をご提供しています。この記事では、今現在AWSでご利用可能なベクトル検索機能を備えたデータベースサービス群について、動作とパフォーマンスの差異を整理することで、お客様のワークロードに最適なサービスを選択するための情報を提供しています。 ブログ記事「製造イノベーションの強化：AI と生成 AI の Centers of Excellence (CoE) がモダナイゼーションを推進する方法」を公開 製造業のお客様向けの翻訳記事を公開しました。製造業におけるAI導入への課題を整理し、AIによってビジネスの変革を導くためにリーダーシップチームに求められる役割、AI CoE(AI導入の推進チーム)がいかにして組織としてのAI活用に貢献できるかをご説明しています。 ブログ記事「GENIAC における計算リソース提供者として AWS が選定されました」を公開 7月16日に公募が開始された、経済産業省と国立研究開発法人新エネルギー・産業技術総合開発機構 (NEDO)が推進するGENIAC(Generative AI Accelerator Challenge)のリソース提供者としてAWSが選定されました。今回の選定についてのAWSの思いや、AWSに対して頂いたコメントを掲載しています。 サービスアップデート Amazon SageMaker Canvasでファインチューニングした基盤モデルを本番環境で活用可能に Amazon SageMaker Canvasはコーディング不要で、機械学習による正確な予測や生成AIの機能を活用できるサービスです。SageMaker CanvasではAmazon Titan ExpressやFalcon-7B-Instructなどのモデルに対して、Amazon BedrockとAmazon SageMaker JumpStartを介した基盤モデルのファインチューニングができるようになっています。今回、SageMaker Canvasでファインチューニングを行った基盤モデルについて、SageMakerの推論エンドポイントにデプロイができるようになりました。これによりSageMaker Canvasで作業した成果を、他のサービスで実行されるアプリケーションに組み込むことが容易になりました。 AWS IAM Identity CenterでAmazon Q Developerのセッション時間を他と独立した値に設定可能に AWS IAM Identity CenterでAmazon Q Developerのユーザ認証に適用されるセッションの持続時間を、他のサービスからのセッション持続時間とは独立して設定できるようになりました。例えば、Amazon Q Developerには90日間のセッション持続時間を、他のサービスには15分間を、という個別の設定ができるようになり、ユーザ体験の最適化が可能です。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

お客様は、リポジトリのクローニング、ミラーリング、または特定のブランチの移行など、さまざまな方法を使用して AWS CodeCommit の リポジトリを他の Git プロバイダーに移行できます。このブログでは、リポジトリを一般的なプロバイダーにミラーリングする基本的なユースケースについて説明し、より具体的なプロバイダーにミラーリングする手順へのリンクを提示します。 リポジトリの種類や複雑さ、および移行対象と方法の決定によって、実際の手順は異なる可能性があります。このブログでは、Git リポジトリデータの移行方法のみを説明しており、プルリクエストなど、CodeCommit からの他のデータのエクスポートについては説明していません。 前提条件 CodeCommit リポジトリを別のプロバイダーに移行する前に、AWS Management Console と移行先のプロバイダーのアカウントの両方に必要な認証情報とアクセス許可があることを確認してください。GitHub や Gitlab に移行する場合は、 Git 認証情報を使用した HTTPS ユーザーのセットアップ で説明されているように、CodeCommit の静的認証情報（訳註：静的認証情報とは こちら に記載のある Git 認証情報用のユーザ名とパスワードのことです）を使用します。以下で説明する一般的な移行オプションのプロセスを選択する場合は、CodeCommit の任意の種類の認証情報を使用できます。AWS CodeCommit のアクセス制御のセットアップの詳細については、 AWS CodeCommit のセットアップ をご覧ください。 AWS CodeCommit コンソールで、移行するリポジトリのクローン URL を選択します。正しいクローン URL(HTTPS、SSH、または HTTPS(CRC)) は、使用する認証情報の種類とネットワークプロトコルによって異なります。 図 1: リポジトリのクローン AWS CodeCommit リポジトリを GitLab リポジトリに移行する CodeCommit のクローン URL と HTTPS Git リポジトリの認証情報を組み合わせて利用して、 URL によるリポジトリ から ソースコードをインポート するための GitLab ドキュメントのガイダンスに従ってください。 AWS CodeCommit リポジトリを GitHub リポジトリに移行する CodeCommit のクローン URL と HTTPS Git リポジトリの認証情報を利用して、 ソースコードをインポート するための GitHub のドキュメントのガイダンスに従って ください。 他のリポジトリプロバイダへの一般的な移行方法 1.    AWS CodeCommit リポジトリをクローンする Git を使用して、AWS CodeCommit からローカルマシンにリポジトリをクローンします。HTTPS を使用する場合は、次のコマンドを実行できます: git clone --mirror https://your-aws-repository-url your-aws-repository your-aws-repository-url を AWS CodeCommit リポジトリの URL に置き換えます。 your-aws-repository をこのリポジトリの名前に置き換えます。例 : git clone https://git-codecommit.us-east-2.amazonaws.com/v1/repos/MyDemoRepo my-demo-repo 2.    新しいリモートリポジトリを設定する クローンした AWS CodeCommit リポジトリのディレクトリに移動します。次に、新しいリポジトリプロバイダのリポジトリ URL をリモートとして追加します : git remote add <provider name> <provider-repository-url> <provider name> を任意のプロバイダ名に置き換えます ( 例 : gitlab) <provider-repository-url> を新しいリポジトリプロバイダのリポジトリ URL に置き換えます。 3.    ローカルリポジトリを新しいリモートリポジトリにプッシュする これにより、すべてのブランチとタグが新しいリポジトリプロバイダのリポジトリにプッシュされます。プロバイダ名は、ステップ 2 のプロバイダ名と一致している必要があります。 git push <provider name> --mirror 注意事項: リモートリポジトリは空である必要があります。 リモートリポジトリには、force push を許可しない保護されたブランチがある可能性があります。この場合、新しいリポジトリプロバイダに移動し、ブランチ保護を無効にして force push を許可します。 4.    移行を確認する プッシュが完了したら、すべてのファイル、ブランチ、タグが新しいリポジトリプロバイダに正常に移行されたことを確認します。これは、オンラインでリポジトリを参照するか、別の場所にクローンしてローカルで確認することができます。 5.    リモート URL を更新する 移行したリポジトリをローカルで引き続き使用する予定の場合は、リモート URL を更新して、AWS CodeCommit ではなく新しいプロバイダのリポジトリを指すようにすることをお勧めします。次のコマンドを使用してこれを行うことができます: git remote set-url origin <provider-repository-url> <provider-repository-url> を新しいリポジトリプロバイダのリポジトリ URL に置き換えます。 6.    CI/CD パイプラインと保護されたブランチを修正する GitLab、GitHub、AWS CodePipeline など、リポジトリと相互作用する CI/CD パイプラインが設定されている場合は、新しいリポジトリ URL を反映するように構成を更新します。ステップ 3 で保護されたブランチの許可を削除した場合は、メインブランチにこれらを再度追加することをお勧めします。 7.    チームに通知する 他の人が作業しているリポジトリを移行する場合は、移行について通知し、新しいリポジトリ URL を提供してください。 8.    移行済みの AWS CodeCommit リポジトリを削除する この操作は元に戻せません。AWS CodeCommit コンソールに戻り、“リポジトリの削除” ボタンを使用して移行したリポジトリを削除します。 図 2: リポジトリの削除 結論 このブログでは、既存の AWS CodeCommit リポジトリを別の Git プロバイダーに移行する方法をいくつか説明しました。移行後も現在の AWS CodeCommit リポジトリを引き続き使用することができますが、その場合は AWS CodeCommit と新しいリポジトリプロバイダー間で定期的な同期操作が必要になる可能性があります。リポジトリの移行に関する詳細については、以下のリソースを参照してください。 リポジトリを段階的に移行する – このガイドは、リポジトリを CodeCommit に段階的に移行することを目的として書かれていますが、他の Git プロバイダーにも使用できます。 本記事はソリューションアーキテクト松本が翻訳しました。原文は こちら です。

AWS を使ってビルドする場合、インフラストラクチャの管理、アプリケーションのデプロイ、問題のトラブルシューティングなど、AWS リソースとやり取りし、操作する必要があり、多くの AWS の顧客は現在、そのために AWS Cloud9 を使用しています。しかし、開発者はワークフローの無駄をなくして合理化し、慣れ親しんだツールを活用するために、独自の統合開発環境 (IDE) 内で AWS リソースを操作できることを望んでいます。また、AWS 管理コンソールでリソースを操作する際のセキュリティと柔軟性を求めているものの、 AWS Cloud9 を使うより、迅速にアクセスでき、さまざまなページ間で移動できることを望んでいるお客様もいます。このブログでは、 AWS IDE Toolkits と AWS CloudShell の 2 つのソリューションについて説明し、AWS Cloud9 からこれらのソリューションの 1 つに移行する理由を説明します。 概要 AWS IDE Toolkits は、Visual Studio Code、IntelliJ、PyCharmなどの一般的な IDE に AWS サービスを直接統合するオープンソースのプラグインセットです。これらのツールキットを使用すると、開発環境から離れることなく AWS リソースを管理し、アプリケーションをデプロイし、コードをデバッグすることができます。AWS IDE Toolkits の主な機能には、AWS サービスへのシームレスなアクセス、リソースの探索と管理、ローカルデバッグ機能、 AWS CloudFormation や AWS SAM などの AWS デプロイメントツールとの統合が含まれます。AWS IDE Toolkits を使えば、アカウントに AWS Cloud9 EC2 インスタンスをデプロイして管理する手間が省け、IDE のソースコードのコンテキストから AWS サービスと対話できます。 AWS CloudShell は、AWS 管理コンソール内で直接利用可能なブラウザベースのシェルで、AWS リソースとのやり取りを行うための事前に認証済みで構築済みの環境を提供します。 AWS CLI は AWS CloudShell 環境にすでにインストールされているため、 AWS CLI をローカルにインストールおよび構成する必要がなく、どこからでも AWS リソースとの対話が可能になります。 AWS CloudShell を使用して、構成ファイルを確認または調整したり、本番環境に素早く修正を加えたり、新しい AWS サービスや機能を試したりすることができます。何より、 AWS CloudShell の使用は無料です。 AWS 管理コンソール内のどこからでもアクセスできる CloudShell の利便性は、ローカルデスクトップでの操作に制限がある場合に、 Web からコマンドラインで AWS リソースとやり取りしたい時の理想的な選択肢となります。 開始方法 AWS IDE Toolkits を活用することに興味がある場合、簡単に利用を始めることができます。 Visual Studio Code などの一般的な IDEでは、 IDE の拡張機能マーケットプレースから AWS Toolkits 拡張機能をインストール し、AWS 認証情報を使って認証するだけで、すぐに AWS Toolkits の機能を利用できます。インストールの詳細については、 サポートされている各 IDE のオンボーディングステップ を参照できます。 AWS CloudShell を使い始めるには、 AWS マネジメントコンソールの CloudShell アイコンをクリックし、プロンプトに従ってシェル環境を起動するだけです。 CloudShell は、 AWS マネジメントコンソールセッションの認証情報を利用して、事前に認証されたシェル環境を提供します。また、ツールに慣れるために、 詳細なユーザーガイドやサンプルのユースケース を確認することもできます。 図 1 : CloudShell のアイコンをクリックする まとめ AWS IDE Toolkits と AWS CloudShell の両方とも、AWS リソースとのやりとりに強力な機能を提供しています。ローカル IDE 内で作業するか、 AWS マネジメントコンソール内のウェブベースのターミナルで作業するかを選択できます。これらのソリューションは、 AWS インフラストラクチャとアプリケーションを効率的に管理するためのシームレスな方法を提供します。これらのオプションを検討し、開発ワークフローを強化する方法を確認してください。最後に AWS Cloud9 EC2 インスタンスから移行した後は、不要な将来の費用が発生しないように削除することを忘れないでください。 本記事はソリューションアーキテクト紙谷が翻訳しました。原文は こちら です。