「重要なものすべてが測定できるわけではなく、測定できるものすべてが重要であるわけでもない」この言葉は、成功を測定するための適切な指標とレポートを選択する難しさを表しています。これは、特にコンタクトセンターに当てはまります。コンタクトセンターを成功させるには、平均処理時間 (AHT) や離脱率などの標準指標を分析し、顧客生涯価値 (CLV) などの専門的な目標に合わせて指標をカスタマイズする必要があります。コンタクトセンターソリューションでは、独自のビジネス目標に沿って、従来の測定値と今後の測定両方を追跡する必要があります。 Amazon Connect は、スーパーバイザー、コンタクトセンターマネージャー、オペレーションマネージャーなどの役割を対象に、積極的かつ柔軟なアプローチでコンタクトセンターレポートを作成します。Amazon Connect は、ペルソナごとにリアルタイムデータと履歴データを組み合わせて提供し、さまざまなレベルの洞察を引き出すのに役立ちます。 Amazon Connect 分析データレイク など、Amazon Connect の最新のイノベーションの中には、標準レポートでは不十分なカスタムインサイトを引き出すのにも役立ち、最も重要なものを測定できるようにするものもあります。 コンタクトセンターチームのさまざまなメンバーが使用できるレポートをいくつか紹介します。 スーパーバイザー スーパーバイザーは、エージェントのグループのパフォーマンスの監視と管理、SLA の遵守の確認、コーチングとガイダンスの提供を担当するチームリーダーです。スーパーバイザーはチームを効果的に管理するため、レポートを必要としています。Amazon Connect では、サービスレベル、キューの待ち時間の長さ、エージェントのステータスなどを表示するダッシュボードをスーパーバイザーに提供しており、潜在的な問題をすばやく特定して解決できます。さらに、スーパーバイザーはエージェントパフォーマンス、キュー、およびコンタクト品質のレポートにアクセスして、エージェントと顧客のやりとりを監視および分析できます。これらの洞察により、コーチング、コンプライアンスチェック、継続的な改善が可能になります。 スーパーバイザーは、管理者ガイドでリアルタイムレポートと履歴レポートを確認できます。例としては、次のようなものがあります。 キューパフォーマンスダッシュボード エージェントアクティビティ監査レポート キューパフォーマンスダッシュボード コンタクトセンターマネージャー コンタクトセンターマネージャーは、人員配置、リソース配分、プロセスの最適化、カスタマーエクスペリエンス改善活動の推進など、コンタクトセンター全体を監督する戦略的リーダーです。Amazon Connect では、コンタクトセンターマネージャー向けに、履歴レポートとカスタマイズ可能なダッシュボードを包括的に提供しています。これらには、さまざまなチャネル (音声、チャット、タスクなど) にわたるサービスレベル、処理時間、放棄率、その他の主要な指標に関するデータが含まれます。マネージャーは、問い合わせの目的、言語、場所などのさまざまな属性に基づいてデータを細かく分類できます。このレベルのきめ細かな分析は、あらゆる規模の組織のデータ主導の意思決定と長期的な戦略計画に役立ちます。 コンタクトセンターマネージャーも、Amazon Connect 内の 効果的なスケジューリングと予測 に大きく依存しています。Amazon Connect に組み込まれたワークフォース管理機能には高度な予測機能があり、過去のコンタクトデータ、季節パターン、その他の要因を分析して将来の需要を正確に予測するのに役立ちます。これにより、 人員配置レベルを予測される問い合わせ量に合わせて、エージェントのスケジューリングを最適化することができます。さらに、Amazon Connect ではリアルタイムのスケジュール遵守性のモニタリングが可能で、スケジュールされたアクティビティに対するエージェントの現在の順守状況や、休憩やトレーニングなどの補助的な状態も表示されます。マネージャーとスーパーバイザーは、このリアルタイムの遵守性データをモニタリングツールとともに活用して、必要に応じて人員配置を調整し、チームメンバーがスケジュールに従って業務効率を維持できるようにすることができます。 コンタクトセンターマネージャーは、管理者ガイドでパフォーマンスレポートとダッシュボードを見ることができます。例には以下が含まれます。 履歴メトリクスレポート リアルタイムメトリクスレポート 予測の検査 スケジュール遵守性 Contact Lens 会話型分析ダッシュボード Amazon Connect Contact Lens 会話分析ダッシュボード コンタクトセンターの運営担当 コンタクトセンターの運営担当者は、コンタクトセンターの技術インフラストラクチャ、システム、およびプロセスが円滑に機能し、シームレスな顧客対応とエージェントの生産性を実現する舞台裏の担当者です。運用レベルでは、Amazon Connect は顧客ルーティングの有効性を測定するためのフローパフォーマンスなどの高度な分析機能を提供します。 2024 年 5 月、Amazon Connect は問い合わせレコード、エージェントパフォーマンス、 Contact Lens のインサイトなどのコンタクトセンターデータの単一ソースである 分析データレイク の一般提供を発表しました。コンタクトセンターの運営者は、Amazon Connect データを使用して独自のカスタムレポートを作成したり、ゼロ ETL を使用してサードパーティのソースからのクエリデータを組み合わせたりできます。Amazon Connect データレイクでは、過去のコンタクトセンターデータをすぐにクエリできるため、複雑なデータパイプラインを構築して維持する必要がなくなります。 Amazon Connect やサードパーティのデータにアクセスすることで、顧客生涯価値 (CLV) などの特殊な指標を作成できます。また、組織はデータレイクのデータを機械学習 (ML) モデルや人工知能 (AI) モデルと組み合わせて使用することで、コンタクトセンターの新たな最適化に役立つ情報を得ることができます。たとえば、エージェントとのやり取りが短くなる傾向は、セルフサービスの機会を表している可能性があります。Amazon Connect データレイクは、 Amazon QuickSight などのビジネスインテリジェンス (BI) ツールやその他のサードパーティのアプリケーションをサポートしており、レポートやダッシュボードをパーソナライズできます。これにより、運用のマネージャーは、選択したデータ視覚化ツールを使用して、重要なカスタマーエクスペリエンスの指標をモニタリングできます。 Amazon Athena などのクエリエンジンを通じて、Amazon Connect データレイク内の統合コンタクトセンターデータにアクセスできます。 Amazon Connect 管理者ガイド を参照して開始することができます。 Amazon QuickSight による Amazon Connect 分析データレイクのレポート例 まとめると、Amazon Connect のレポートと分析サービスは、コンタクトセンターに関わるさまざまなペルソナの多様なニーズに応えます。スーパーバイザーからマネージャー、運用チームまで、Amazon Connect はパフォーマンスの向上、運用の最適化、優れたカスタマーエクスペリエンスの提供に必要な洞察とツールを提供します。 6月3日から6日にラスベガスで開催された「Customer Contact Week」 のセッションもご覧ください。 Amazon Connect でカスタマーサービス体験を変革する準備はできていますか? お問い合わせください。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は、 Modernize your data observability with Amazon OpenSearch Service zero-ETL integration with Amazon S3 を翻訳したものです。翻訳は Solutions Architect の深見が担当しました。 私たちは、バージョン 2.13 以降のドメインでの Amazon OpenSearch Service の　 Amazon Simple Storage Service (Amazon S3) とのゼロ ETL 統合の 一般提供の開始を発表できることを喜ばしく思います。 この統合により、お客様は Amazon S3 と S3 ベースのデータレイクに格納されているオペレーショナルログを、ツールを切り替えることなくダイレクトクエリできるようになりました。 OpenSearch Service と S3 データセットにまたがってクエリを実行することで、運用とセキュリティイベントの包括的な分析を行うことができます。 OpenSearch Service との新しい統合により、AWS のゼロ ETL ビジョンが実現され、データの複製や複数の分析ツールの管理による運用の複雑さが軽減されます。 これにより、オペレーショナルデータへのダイレクトクエリを実行でき、コストと時間を削減できます。 OpenSearch は、Elasticsearch 7.10 から派生したオープンソース分散検索・分析スイートです。現在、OpenSearch Service には数万人のアクティブユーザーがおり、数十万のクラスターを管理し、毎月数兆件のリクエストを処理しています。 Amazon S3 は、業界をリードする拡張性、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。 あらゆる規模の企業やあらゆる業界が、データレイク、クラウド中心のアプリケーション、モバイルアプリなど、実質的にあらゆるユースケースに対して、無制限にデータを保存して保護できます。 コスト効率の高いストレージクラスとユーザーフレンドリーな管理機能により、コストを最適化し、データを整理し、ビジネス、組織、コンプライアンス要件に合わせて細かくアクセス制御を設定できます。 OpenSearch Service のこの興味深い新機能について詳しく見ていきましょう。 OpenSearch Service と Amazon S3 のゼロ ETL 統合を利用するメリット OpenSearch Service の Amazon S3 との ゼロ ETL 統合により、OpenSearch Service 外の Amazon S3 に格納されているクエリの頻度が低いデータに対して、OpenSearch Service SQL と PPL の高度な分析機能を直接利用できます。また、他の OpenSearch との統合とも連携しているため、事前にパッケージ化されたクエリと可視化を導入して、データを分析できます。すぐに利用を開始できるよう簡単に設定できます。 次の図は、OpenSearch Service が一般的な AWS ログタイプの、あまり頻繁にクエリされないログがもつ価値を引き出す方法を示しています。 OpenSearch Service の ダイレクトクエリ を使用すると、Amazon S3 のデータに対してクエリを実行できます。 OpenSearch Service は、Amazon S3 のオペレーショナルログやデータレイクを分析するための Amazon S3 とのダイレクトクエリ統合機能を提供しています。 これにより、サービス間の切り替えを行うことなく、クラウドオブジェクトストアのデータを分析し、同時に OpenSearch Service のオペレーショナル分析と可視化機能を利用できます。 多くのお客様は現在、お客様自身が提供するソリューションに関するイベントデータを Amazon S3 に保存しています。オペレーショナル分析の文脈では、Amazon S3 は通常、 VPC フローログ 、 Amazon S3 アクセスログ 、 AWS ロードバランサーログ 、および他の AWS サービスからのイベントソースの宛先として使用されています。お客様はまた、コンプライアンスと監査のニーズから、アプリケーションイベントのデータを直接 Amazon S3 に保存しています。Amazon S3 の 耐久性 と拡張性により、低コストで利用できる長期保存やアーカイブオプションを必要とする多くのお客様にとって、データの保存先として明快な選択肢になります。 これらのソースからのデータを、ホットストレージとウォームストレージ層に格納された OpenSearch Service に取り込むことは、生成されるイベントのサイズとボリュームのために、現実的ではないケースがあります。OpenSearch Service のインデックスに格納されるイベントソースの一部については、データに対して実行されるクエリの量がクラスターにデータを保持し続けるコストに見合わないものもあります。以前は、クラスターにプロビジョニングされたストレージに基づいて、OpenSearch Service に取り込むイベントソースを選択する必要がありました。他のデータにアクセスするには、 Amazon Athena などの別のツールを使用して、Amazon S3 上のデータを表示する必要がありました。 実際にこの新しい統合がどのように恩恵をもたらしたかを、Arcesiumの事例で見てみましょう。 “ Arcesiumは、金融サービス業界向けに高度なクラウドネイティブのデータ、オペレーション、分析機能を提供しています。当社のソフトウェア・プラットフォームは、1日に何百万件ものトランザクションを処理し、その過程で大量のログと監査記録を出力します。私たちが処理し、保存し、分析する必要のあるログデータの量は、私たちの保持とコンプライアンスのニーズを考慮すると、指数関数的に増加していました。Amazon OpenSearch Service の Amazon S3との新しいゼロ ETL 統合は、大規模でコストのかかる OpenSearch クラスタを維持したり、アドホックな取り込みパイプラインを構築したりする運用コストをかける代わりに、Amazon S3 にすでに保存されているクエリ頻度の低いログを分析できることで、私たちのビジネスのスケールに貢献しています。” – Kyle George, SVP & Global Head of Infrastructure at Arcesium. Amazon S3 へのダイレクトクエリにより、複雑な抽出、変換、ロード (ETL) パイプラインを構築する必要がなくなり、OpenSearch Service と Amazon S3 ストレージの両方にデータを複製するコストがかからなくなりました。 基本概念 ダイレクトクエリ接続を構成した後、OpenSearch Service Query Workbench を使用して AWS Glue Data Catalog 内にテーブルを作成する必要があります。ダイレクトクエリ接続は、Glue Data Catalog テーブル内のメタデータに依存する形で、Amazon S3 に格納されているデータを参照します。AWS Glue クローラーまたは Athena によって作成されたテーブルは、現在サポートされていないことに注意してください。 Data Catalog テーブルの構造、SQL インデックス技術、OpenSearch Service インデックスを組み合わせることで、クエリのパフォーマンスを加速し、高度な分析機能を解放し、クエリのコストを抑えることができます。 データを加速する方法の例をいくつか示します。 スキップインデックス – Amazon S3 に格納されているデータのメタデータのみを取り込み、インデックス化します。スキップインデックスを持つテーブルに対してクエリを実行すると、クエリプランナーがインデックスを参照し、すべてのパーティションとファイルをスキャンするのではなく、クエリを書き換えて効率的にデータの場所を特定します。これにより、スキップインデックスは分析に関連する格納データの特定の場所を素早く絞り込むことができます。 マテリアライズドビュー – マテリアライズドビューを使用すると、集計などの複雑なクエリを使ってダッシュボードの可視化を強化できます。マテリアライズドビューは、データの一部を OpenSearch Service のストレージに取り込みます。 カバリングインデックス – カバリングインデックスを使用すると、テーブル内の指定されたカラムからデータを取り込むことができます。これは 3 つのインデックスタイプの中で最も高性能です。OpenSearch Service が目的のカラムからすべてのデータを取り込むため、パフォーマンスが向上し、高度な分析を実行できます。OpenSearch Service は、カバリングインデックスデータから新しいインデックスを作成します。この新しいインデックスを使って、ダッシュボードの可視化や、異常検知や地理空間機能などの他の OpenSearch Service 機能を利用できます。 S3 バケットに新しいデータが入ると、マテリアライズドビューとカバリングインデックスのリフレッシュ間隔を設定して、Amazon S3 上の最新のデータにローカルでアクセスできるようにすることができます。 ソリューションの概要 VPC フローログをソースとして試してみましょう! 前述のように、多くの AWS サービスはログを Amazon S3 に出力します。VPC フローログは、 Amazon Virtual Private Cloud (Amazon VPC) の機能で、VPC 内のネットワークインターフェースの送受信 IP トラフィックに関する情報をキャプチャできます。 このウォークスルーでは、次の手順を実行します。 S3 バケットが未作成の場合は作成してください。 トラフィックが生じており、ログを Amazon S3 上に Parquet 形式で保存できる既存の VPC を使用して、VPC フローログを有効にしてください。 S3 バケットにログが存在することを確認してください。 データが格納されている S3 バケットと Data Catalog に対して、ダイレクトクエリ接続を設定してください。 VPC フローログ用の統合をインストールしてください。 S3 バケットの作成 既存の S3 バケットがある場合は、バケット内に新しいフォルダを作成することでそのバケットを再利用できます。バケットを新規作成する必要がある場合は、Amazon S3 コンソールに移動し、組織のポリシーに適したバケット名で Amazon S3 バケットを作成してください。 VPC フローログの有効化 VPC フローログを有効にするには、次の手順を実行してください。 Amazon VPC コンソールで、アプリケーショントラフィックからログを生成できる VPC を選択します。 フローログ タブで、 フローログを作成 を選択します。 フィルター では、 すべて を選択します。 最大集約間隔 を 1 分に設定します。 送信先 では、 Amazon S3 バケットに送信 を選択し、前に作成したバケットの S3 バケット ARN を入力します。 ログレコード形式 では、 カスタム形式 を選択し、 Standard attributes を選んでください。 この記事では、執筆時点で Amazon Elastic Container Service (Amazon ECS) の属性は OpenSearch との統合がまだ実装されていないため、選択しません。 ログファイル形式 では、 Parquet を選択してください。 Hive 互換 S3 プレフィックス では、 有効化 を選択してください。 時間にログをパーティション分割 を 1 時間ごと (60 分) に設定してください。 S3 バケットにログが受信されていることの確認 先ほど作成した S3 バケットに移動すると、データがそのバケットにストリーミングされていることがわかります。 ディレクトリ構造を掘り下げていくと、ログが 1 時間ごとのフォルダに配信され、1 分ごとに出力されていることがわかります。 VPC フローログを S3 バケットに流し込めるようになったので、次は Amazon S3 上のデータと OpenSearch Service ドメインの間に接続を設定する必要があります。 ダイレクトクエリデータソースの設定 このステップでは、Glue Data Catalog のテーブルと Amazon S3 のデータを使用するダイレクトクエリデータソースを作成します。このアクションにより、Hive メタストア (Glue Data Catalog のデータベースとテーブル、およびデータソースがアクセスするバケットとフォルダーの組み合わせに格納されている Amazon S3 のデータ) にアクセスするために必要なすべてのインフラストラクチャが作成されます。 また、セキュリティプラグインの きめ細かなアクセス制御 に適切な権限が組み込まれるため、開始時の権限を気にする必要はありません。 次の手順に従って、ダイレクトクエリデータソースを設定してください: OpenSearch Service ドメインで、ナビゲーションペインの ドメイン を選択します。 ドメインを選択します。 Connections タブで、 Create new connection を選択します。 Name には、 zero_etl_walkthrough のようにダッシュを含まない名前を入力します。 Description には、説明を入力します。 Data source type では、 Amazon S3 with AWS Glue Data Catalog を選択します。 IAM role では、初めての場合は、 Create a new role を選択して、ダイレクトクエリの設定で権限を処理させます。後で組織のコンプライアンスとセキュリティニーズに基づいて編集できます。この記事では、ロール名を zero_etl_walkthrough としています。 S3 buckets では、さきほど作成したバケットを使用します。 Grant access to all existing and new buckets という項目のチェックボックスは選択しないでください。 Checkpoint S3 bucket では、作成したバケットと同じものを使用します。チェックポイントフォルダは自動的に作成されます。 AWS Glue tables では、Data Catalog で作成したものがないため、 Grant access to all existing and new tables を有効にします。 VPC フローログの OpenSearch 統合では、Data Catalog 内にリソースが作成されるため、それらのリソースにアクセスする権限が必要になります。 作成 を選択します。 初期設定が完了したので、VPC フローログの OpenSearch 統合をインストールできます。 VPC フローログの OpenSearch 統合のインストール OpenSearch のインテグレーションプラグインには、さまざまなソースから生成されたデータを可視化し、操作するのを簡単にするための、事前構築済みのダッシュボード、ビジュアライゼーション、マッピングテンプレート、その他のリソースが多数含まれています。 Amazon VPC 向けのインテグレーションでは、Amazon S3 に保存された VPC フローログデータを表示するためのさまざまなリソースがインストールされます。 このセクションでは、最新の統合パッケージをインストールするための手順を説明します。次に、OpenSearch 統合のインストール方法を示します。マイナーバージョンまたはメジャーバージョンのリリース時点では、VPC フローログ、NGINX、HA Proxy、Amazon S3 (アクセスログ) などの最新の統合が含まれている場合がほとんどです。ただし、OpenSearch はオープンソースのコミュニティ主導のプロジェクトであり、現在の展開に含まれていない新しいバージョンや新しい統合が登場することが予想されます。 OpenSearch と Amazon VPC の統合の最新バージョンの検証 OpenSearch Service の以前のバージョンから 2.13 にアップグレードする必要があります。このポストの内容と、あなたのデプロイ状況が一致していることを確認しましょう。 OpenSearch Dashboards で Integrations タブに移動し、 Amazon VPC を選択します。インテグレーションのリリースバージョンが表示されます。 バージョン 1.1.0 以降がインストールされていることを確認してください。デプロイ環境にインストールされていない場合は、OpenSearch カタログから最新バージョンのインテグレーションをインストールできます。以下の手順を実行してください。 OpenSearch カタログ に移動します。 Amazon VPC Flow Logs を選択します。 amazon_vpc_flow_1.1.0 というラベルのリポジトリフォルダから、 1.1.0 Amazon VPC integration ファイルをダウンロードします。 OpenSearch ダッシュボードの Dashboards Management プラグインで、 Saved Objects を選択します。 Import を選択し、ローカルフォルダを参照します。 ダウンロードしたファイルをインポートします。 このファイルには、インテグレーションを作成するために必要なすべてのオブジェクトが含まれています。インストール後、Amazon VPC OpenSearch インテグレーションのセットアップ手順に進むことができます。 OpenSearch と Amazon VPC の統合設定 さっそく統合をインストールしましょう: OpenSearch Dashboards で、 Integrations タブに移動します。 Available タブに遷移し、 Amazon VPC の統合を選択します。 バージョンが 1.1.0 以降であることを確認し、 Set Up を選択します。 Display Name はデフォルトのままにします。 Connection Type では、 S3 Connection を選択します。 Data Source では、前の手順で作成したダイレクトクエリ接続の名前を選択します。この投稿では zero_etl_walkthrough を使用します。 Spark Table Name では、事前入力された amazon_vpc_flow のままにします。 S3 Data Location では、前の手順で設定した VPC Flow Logs によって作成されたログフォルダの S3 URI を入力します。この投稿では s3://zero-etl-walkthrough/AWSLogs/ を使用します。 S3 バケット名はグローバルに一意である必要があり、会社のコンプライアンスガイダンスに準拠したバケット名を使用することを検討する必要があります。 一意性を保証するには、UUID に説明的な名前を付けるのが良い選択肢です。 S3 Checkpoint Location では、定義したチェックポイントフォルダの S3 URI を入力してください。チェックポイントは、ダイレクトクエリ機能のメタデータを格納します。選択したバケットの空のパスまたは未使用のパスを選んでください。この記事では、前に作成したバケットの s3://zero-etl-walkthrough/CP/ を使用します。 Queries (recommended) と Dashboards and Visualizations for Flint Integrations using live queries を選択します。 「Setting Up the Integration – this can take several minutes. （インテグレーションのセットアップ – これには数分かかる場合があります）」というメッセージが表示されます。この特定のインテグレーションでは、Amazon S3 内のデータ上にスキップインデックスとマテリアライズドビューが設定されます。 マテリアライズドビューは、データをバッキングインデックスに集約し、すべてのデータを取り込んでその上に可視化を構築するよりも、クラスター内のデータ容量を大幅に小さくすることができます。 Amazon VPC 統合のインストールが完了すると、さまざまなアセットを利用できるようになります。インストール済みの統合を確認すると、Amazon S3 上のデータを使ってデータ探索を始められるクエリ、ビジュアライゼーション、その他のアセットが見つかります。この統合でインストールされるダッシュボードを見てみましょう。 コストはいくらですか？ OpenSearch Service のダイレクトクエリでは、ワークロードで消費されたリソースのみの料金が発生します。OpenSearch Service では、外部データを照会するために必要な計算リソースと、オプションで OpenSearch Service 内のインデックスを維持するための計算リソースのみが課金されます。計算容量は OpenSearch Compute Unit (OCU) で測定されます。クエリやインデックス作成が行われていない場合は、OCU は消費されません。次の表は、us-east-1 で HTTP ログを検索した場合の計算料金の例を示しています。 クエリごとにスキャンされるデータ (GB) クエリごとの OCU 価格 (USD) 1-10 $0.026 100 $0.24 1000 $1.35 料金は問い合わせごとに使用される OCU に基づいているため、このソリューションは頻繁に問い合わせされないデータ向けにカスタマイズされています。ユーザーがデータを頻繁に問い合わせする場合は、 OR1 インスタンス や UltraWarm などのストレージ最適化手法を活用し、OpenSearch Service への完全な取り込みを実施することが適切になります。 ゼロ ETL 統合で消費された OCU は、 AWS Cost Explorer にアカウントレベルで表示されます。 アカウントレベルで OCU 使用量を把握し、しきい値を設定して、しきい値を超えた際にアラートを出すことができます。 Cost Explorer でフィルタリングする使用量の種類の形式は、RegionCode-DirectQueryOCU (OCU 時間) です。 AWS Budgets を使用して予算を作成し、DirectQueryOCU (OCU 時間) の使用量が設定したしきい値に達したときにアラートを設定できます。 また、 Amazon Simple Notification Service (Amazon SNS) トピックと、ターゲットとして AWS Lambda 関数を使用してしきい値の条件を満たしたときにデータソースをオフにすることもできます。 サマリ ダイレクトクエリ接続機能、OpenSearch 統合、および OpenSearch Service の Amazon S3 との ゼロ ETL 統合がどのように機能するかの概要を理解いただけたら、この機能をご自身の組織のツールセットの一部として利用することを検討してください。 OpenSearch Service の Amazon S3 との ゼロ ETL 統合により、イベント分析の新しいツールが利用できるようになりました。 ホットデータを OpenSearch Service に取り込めば、リアルタイムに近い分析とアラートが可能になります。 主にイベント後の分析と相関分析に使用される頻繁にクエリされることのない大量のデータは、Amazon S3 上でクエリできるため、データを OpenSearch Service に移動する必要がありません。 データは、コスト効率の高い Amazon S3 に保存されたままで、分析のために OpenSearch Service にデータを移動するための追加インフラストラクチャを構築することなく、必要に応じてデータにアクセスできます。 詳細については、 Amazon S3 での Amazon OpenSearch Service のダイレクトクエリの操作 を参照してください。 著者について Joshua Bright は、Amazon Web Services のシニアプロダクトマネージャーです。Joshua は OpenSearch Service チームでデータレイク統合イニシアチブを主導しています。仕事以外では、Joshua は自然の中を散歩しながら鳥のさえずりを聞くのが好きです。 Kevin Fallis は、Amazon Web Services のプリンシパル スペシャリスト ソリューションアーキテクトです。お客様が適切な AWS サービスの組み合わせを活用して、ビジネス目標を達成できるよう支援することに情熱を注いでいます。仕事後の活動には、家族、DIY プロジェクト、大工仕事、ドラムを演奏すること、そして音楽全般が含まれます。 Sam Selvan は、Amazon OpenSearch Service の Principal Specialist Solution Architect です。

生成 AI アプリケーションの構築には、適切な日本語大規模言語モデル (LLM) の選定と活用が不可欠です。AWS では Amazon Bedrock , Amazon SageMaker JumpStart , AWS Marketplace でさまざまな基盤モデル (Foundation Model; FM) および大規模言語モデル (Large Language Model; LLM) を提供しています。最近、日本のスタートアップ企業である ELYZA の日本語 LLM が SageMaker JumpStart に掲載され、AWS 環境へワンクリックで簡単にデプロイできるようになりました。 今回、 ELYZA Japanese Llama 2 7B の 2つのモデルが SageMaker JumpStart で公開されました。JumpStart に掲載された ELYZA-japanese-Llama-2-7b-chat , ELYZA-japanese-Llama-2-7b-fast-chat いずれも Meta Llama 2 をベースとし、OSCAR や Wikipedia といった日本語コーパスを用いて継続事前学習を行っています。さらに、ELYZA の高品質データを用いた事後学習 (ファインチューニング) が施されています。後者の ELYZA-japanese-Llama-2-7b-fast-chat モデルでは日本語の語彙を取り込むことで辞書を拡張しており、日本語テキスト内のトークン数を 55% 削減、生成速度が 1.82 倍に向上しています。これらのモデルは独自データ ELYZA Tasks 100 によっても評価され、当初モデルがアナウンスされた2023年8月時点では日本語モデルの中でも高い性能を示していました。なお、モデルの性能評価など詳細については モデル公開時のブログ をご参照ください。 ELYZA はその後も、Llama 2 ベースで 13B モデルの公開 [ Announcement , Hugging Face ] と、70B モデルの発表・デモ公開 [ Announcement , Demo ] を行いました。Llama 2 ベースのモデルは Amazon EC2 Inf2 インスタンスを活用してコスト・パフォーマンス良く推論することが可能で [ Blog ]、特に ELYZA Llama 2 70B で Speculative Decoding という高速化手法を用いた Inf2 上での推論が技術ブログで解説されています [ Blog ]。現在 AWS 上では、SageMaker を用いたデプロイの他に、Meta Llama 2 などのアーキテクチャをベースとした公開済みのモデルを Amazon Bedrock に取り込む Custom Model Import (preview) [ Docs ] という機能も提供されています。このように、様々な方法で ELYZA のモデルを活用することができます。 SageMaker JumpStart でのデプロイ方法は、すでに JumpStart に掲載されいてる rinna , CyberAgent や Stability AI による日本語 LLM の手順を参照してください。 著者について 針原 佳貴 (Yoshitaka Haribara) は AWS Japan のスタートアップソリューションアーキテクトです。最近は生成 AI 基盤モデル・大規模言語モデル開発などのワークロードを中心に担当しています。趣味はドラムです。 久保 隆宏 (Takahiro Kubo) は AWS Japan の機械学習領域のデベロッパーリレーションを担当しており、「機械学習をするなら AWS 」と感じて頂くべくコンテンツの作成とフィードバックの収集による AWS サービスの改善を行っています。

この投稿はネットアップ合同会社 Zhao Mandy 氏に、Amazon FSx for NetApp ONTAP によるイミュータブルバックアップの取得について寄稿いただいたものです。 こちらは、サイバーレジリエンスブログシリーズの第 2 回です。本ブログシリーズでは、サイバーレジリエンスについて組織の重要な資産である「データ」の観点で 3 回に亘って基礎からご紹介していきます。 第 1 回ブログでは、「サイバーレジリエンス」に関する基礎的な内容を解説 しましたが、今回はデータ保護の観点から脅威となっているランサムウェアへの対策を中心にイミュータブルバックアップについてご紹介していきます。 データ紛失と改ざんは企業にとって深刻な影響をもたらす可能性があります。従来のバックアップ手段はデータ損失を防止しますが、バックアップ自体が攻撃され、障害になる可能性もあります。そのため、バックアッププロセスにもデータセキュリティの補強が必要です。 イミュータブル (変更不可) バックアップとは、あらかじめ設定された期間中に削除・改ざんできないバックアップファイルやデータコピーのことです。イミュータブルバックアップは、従来のバックアップと同じくプライマリーサーバー障害時にデータ損失を防止する役割だけでなく、ランサムウェアからのデータ保護にも役立ちます。 ランサムウェアは、データを標的にして暗号化し、身代金を支払うまで所有者がアクセスできないようにするサイバー攻撃の手法です。従来のバックアップ手段は効果的ですが、万全な対策ではありません。最近のランサムウェアはバックアップそのものを暗号化するように設計されており、ランサムウェアによるバックアップサイトにも被害が発生した場合、データを復旧することはさらに難しくなります。 ランサムウェア対策の観点でイミュータブルバックアップの存在意義は、いつでもファイルを復元できるということであり、復元しようとしたときにファイルが壊れていたり暗号化されていたりして、バックアップ・ソフトウェアが実際に正しく動作するかどうかを心配する必要がないということです。 ただし、イミュータブルバックアップの不変性には他のリスクを伴う可能性があります。イミュータブルバックアップの保存期間を長く設定すると、ストレージ容量を大量に消費するため、データ保存のコストが増加する可能性があります。また、ポリシー設計や運用管理によるストレージ管理者の負荷が高くなります。逆に、保存期間が短すぎると、組織が重要なデータを復旧できなくなる危険性があります。イミュータブルバックアップを運用する時、あらかじめバックアップの設計に工夫が必要です。 Amazon FSx for NetApp ONTAP イミュータブルバックアップソリューションの紹介 スナップショットは、データの可用性、信頼性、セキュリティを確保するための強力なデータ保護技術です。 Amazon FSx for NetApp ONTAP (FSx for ONTAP) は、フルマネージドの Snapshot と管理機能を提供します。FSx for ONTAP ファイルシステムを作成すると、Snapshot 機能はデフォルトで有効になっています。 FSx for ONTAP の Snapshot 機能により、Point in Time 方式でボリュームのデータコピーを作成します。Point in Time 方式は、データに変更が行われた時にデータブロックをそのままコピーするのではなく、ブロックへのポインタだけを変更するため、変更が発生してもほぼ瞬時にスナップショットが作成されます。余計な読み書きが発生しないため、スナップショット取得時のパフォーマンスオーバーヘッドが少ないです。ファイルデータとスナップショットは同じ場所で保存されますが、変更された部分に対してのみストレージ容量を消費するため、従来の Copy on Write 方式より容量効率が優れています。Snapshot 機能を活用してローカルまたはバックアップサイトでデータコピーを作成することで、ランサムウェア攻撃からデータの保護と迅速な復旧が実現できます。 最近のランサムウェア攻撃は元データをターゲットするだけではなく、スナップショットコピーも攻撃のターゲットとして暗号化されたり、削除されたり、バックアップ先が攻撃されるケースも増えています。バックアップデータが読み取り専用に設定しても、ランサムウェアの被害に気づくのが遅れると、ランサムウェアによる暗号化されたバックアップデータが暗号化前の正常なバックアップデータを食いつぶしてしまう可能性があります。 このような攻撃に対する保護対策として、FSx for ONTAP では「Tamperproof Snapshot」という機能が提供されています。Tamperproof Snapshot 機能を使用すると Snapshot コピーが指定した期間でロックされ、有効期限まで改ざん・削除できなくなります。この機能により、ランサムウェアの攻撃を防止することができます。また、管理者権限の漏洩や内部の不正な管理者による Snapshot の削除も防ぐことが可能です。ボリュームがランサムウェアによる被害を受けた場合、ロックされた Tamperproof Snapshot を使用してデータを復元できます。 FSx for ONTAP で Snapshot の作成と管理 ここからは ONTAP CLI を使って Snapshot を作成・管理する方法をご紹介します。 管理エンドポイントに ssh でログインしてファイルシステムの状態を確認します。FSx for NetApp ONTAP の管理エンドポイントは指定した IP アドレス範囲に自動作成されるもので、AWSコンソールから確認することができます。 >ssh fsxadmin@management_endpoint_ip 図 1: アクセス時のコンソール画面 ファイルシステムに ssh で接続すると、SVM の状態が確認できます。volume show コマンドで Volume の一覧情報を確認できます。 >volume show 下記のコマンドで Snapshot Policy の確認ができます。デフォルトの Snapshot 取得ポリシーでは、合計 10 個の Snapshot が定時的に保存されます。 >snapshot policy show -policy policyName 図 2: Snapshot Policy の確認 hourly、daily、weekly という 3 種類のスケジュールが有効になっており、それぞれ毎時 6 世代、日次 2 世代、週次 2 世代というスケジュールで Snapshot を取得しています。デフォルトのポリシーを利用しない場合、ユーザー自身で Snapshot Policy をカスタマイズすることも可能です。 取得時間の詳細を確認することもできます。下記のように、 job schedule cron show コマンドで 1 時間ごとの Snapshot は何分で取得するか、1 日ごとの Snapshot は何時何分で取得するか、1 週間ごとの Snapshot は何曜日の何時何分で取得するか、詳しく確認することができます。 図 3: Snapshot 取得スケジュールの確認 スケジュールされたタイミングを待たずに手動で Snapshot を取得することもできます。 下記のコマンドでボリューム volad の Snapshot を手動で作成します。 >volume snapshot create 図 4: 手動での Snapshot 作成 Snapshot 作成後、下記のコマンドとオプションで Volume のスペース配分を確認します。 >volume show volName -fields percent-snapshot-space, snapshot-space-used, snapshot-reserve-available Volume の容量のうち 5 %が Snapshot 用に snapshot-reserve として予約されています。 図 5: 作成した Snapshot の確認 このようにスケジュール通りで作成される Snapshot は SnapMirror というストレージレベルでのレプリケーション機能を活用してデータをプライマリサイトからリモートサイトに転送すると、よりセキュアなバックアップ環境を構築することが可能です。また、ファイルがランサムウェアによって暗号化されても、Snapshot コピーから一瞬でデータをリストアしてデータ損失のリスクを最小限に抑えられます。 FSx for ONTAP の Tamperproof Snapshot 機能 ここからは ONTAP CLI を使って Tamperproof Snapshot を作成・管理します。 新規ボリューム/既存ボリュームに対して Tamperproof Snapshot を設定できます。ONTAP CLI を使用して、 volume create および volume modify に -snapshot-locking-enabled オプションを指定します。 > volume modify -vserver vserverName -volume volumeName -snapshot-locking-enabled 図 6: 既存ボリュームへの Tamperproof Snapshot の設定 下記のコマンドを使って、手動で Tamperproof Snapshot の保持期限を設定/確認します。 >volume snapshot modify-snaplock-expiry-time -vserver vserverName -volume volumeName -snapshot snapshotName -expiry-time “mm/dd/yyyy HH:MM:SS” 図 :7 Tamperproof Snapshot 保持期限の設定と確認 snapshot delete コマンドを使って、Tamperproof Snapshot が削除できないことを確認します。 図 8: Tamperproof Snapshot 削除試行 留意点として、Tamperproof Snapshot は通常の Snapshot と異なり、保持世帯数より保持期間が優先されます。保持期間が終わっていない場合、指定した保持数を超えても Snapshot が残ります。例えば、1 日毎に Snapshot を作成するといったような Snapshot Policy を設定しました。Snapshot の保持数を 5、保持期間を 1 か月に設定した場合、1 か月経った時点で Snapshot の保持数は 5 を超えて 30 または 31 になります。 まとめ バックアップやスナップショットのリカバリポイントを標的にするランサムウェアによる攻撃が増えていますが、FSx for ONTAP の Tamperproof Snapshot 機能を使用して改ざん防止スナップショットを作成すれば、プライマリシステムもバックアップシステムもランサムウェア攻撃を防ぐことができます。ペタバイト級のデータを数秒で復旧できるため、組織のダウンタイムを最小限に抑えることができます。さらに、Tamperproof Snapshot コピーは、ランサムウェアの攻撃者や不正な管理者が削除したり変更したりできないため、攻撃が発生しても大切なデータを保護できます。このようなイミュータブルバックアップにより、クリーンなコピーでデータを保護することで、お客様のランサムウェア対策強化に役立ちます。

本稿は株式会社ナウキャスト データ & AI ソリューション事業部 事業責任者 片山 燎平様と Amazon Web Services Japan ソリューションアーキテクト 宮﨑の共同執筆です。LLM の業務活用に取り組まれる方の参考となれば幸いです。また、今回内容を含む 講演動画 も公開されておりますので、ご興味をお持ち頂けましたらあわせてご覧ください。 == 株式会社ナウキャスト では POS データやクレジットカードの決済データといった「オルタナティブデータ」を解析し、リアルタイムな経済統計の開発、生活者の消費行動や企業活動をより早く正確にとらえるデータソリューションの提供に取り組んでいます。POS データやクレジットカードなどの決済データ、ニュースや SNS 投稿のテキストデータといったオルタナティブデータを解析し、経済統計のリアルタイム化や企業の経営戦略の見える化を行い、国内外 250 社以上の金融機関、シンクタンク、政府、政府系金融機関、海外ヘッジファンド等の資産運用、経済調査業務を支援しています。 現在ナウキャストでは、国内外の資産運用会社と生成 AI / 大規模言語モデル (LLM) を活用した業務効率化システムの開発を推進しています。当該業務では資産運用における判断・意志決定のために膨大な適時開示資料から人力でデータ抽出を行っており、データの正確性は担保しつつ、データ抽出処理を効率化する仕組みの構築が求められていました。 本稿では、弊社における LLM によるデータ抽出効率化の取り組みの一例として、適時開示資料である決算短信からセグメント別売上情報を抽出する処理の実装とその成果についてご紹介します。 セグメント別売上情報抽出業務：現行課題 （図1. セグメント別売上情報抽出 – 手動） セグメント別売上情報抽出の業務では、適時開示資料をもとに、Excel などにデータを転記していく作業を行います。こちらの作業は (1) 対象銘柄の決算短信を探し、(2) セグメント別売上情報の記載個所を探し、(3) 該当箇所からセグメント名と各数値をコピー＆ペーストで埋めていく、といった流れになっており、一社当たり平均 2～3 分を要します。この業務は日々多くの会社の情報を取り扱う会社において、転記そのものの時間に加えチェックの負荷もあり、業務上大きな負担となっていました。 課題解決に向けた検討 皆様も既にご存じの通り、現状の LLM は課題に対する万能の解決方法ではありません。例えば、不適切な入出力を防止するためのガードレールの構築と維持、企業独自の知識を LLM で利用するためのデータソースの管理、適切なアクセス権限の制御など、プロトタイピングを超えて本番運用を見据えた場合、LLM の運用にあたっては多くのハードルがあります。 そのためナウキャストでは、課題解決の検討に LLM の利用を含める場合、LLM での解決が適しているかの見極めを実施しています。特に、LLM を万能の AI アシスタントとしてとらえるのではなく、自然言語の処理技術としてシステムに組み込むことが可能か、という視点で捉えなおし、以下の観点を一例として LLM に適したタスクかどうかの判断を行っています。 LLM アプリケーション開発に向いたタスク：観点例 (1) 正解が簡単に判断できる、もしくは正解がないタスク 人間が実施する場合でも難しい複雑なタスクは LLM にも難しいため、答えの決まりやすいタスクを対象とする (2) 深いドメイン知識が必要ない、もしくはそのドメインに関する知識が世に広く出回っているタスク RAG にも限界があるため、できるだけドメイン知識に依存しないか、一般的なドメイン知識の業務を対象とする (3) 終了に必要なコンテキストが少なく、かつコンテキストの言語化が容易なタスク 複数のコンテキストが絡み合う内容は LLM では精度を出すことが難しいため、シンプルなものを対象とする (4) ユーザーがプロンプトを入力しないタスク 業務ユーザーがプロンプトを扱うにはユーザー側・システム側双方の負荷が高いため、ユーザー入力をプロンプトに反映する必要のない業務を対象とする 今回のセグメント別売上情報抽出業務は上記 (1) ～ (4) の観点を満たすタスクとなっており、また、処理の実装により人間の作業コストを大きくカットできると見込まれることから LLM での適用に適したタスクと判断し、検証を実施することにしました。 解決策 （図2.セグメント情報抽出のフロー） 今回のフローでは、決算短信データ (PDF) から財務データ抽出を行う業務特性に照らし、大量の書類を扱う事に長けた Anthropic Claude 2 (100K) (*1) が利用可能な Amazon Bedrock を採用しました。また、LLM による情報抽出の精度が 100% になることはないため、オペレーターの目検チェックを運用に組み込んだ Human in the loop (*2) のシステムとする事で、ハルシネーションのリスクを最小化するようフローを設計しています。 (*1) 検証時点の最新モデル (*2) 人がループ（システム処理フロー）の中に参加する事で、プロセスの効率性と透明性を高める取り組み LLM データ抽出システム：実装イメージ ここまでの課題・解決策をもとに実装した LLM データ抽出システムのアーキテクチャーおよびポイントは以下の通りです。 アーキテクチャー （図3. LLM 抽出システム：アーキテクチャー） ポイント 基盤モデル Amazon Bedrock では複数の基盤モデルが提供されています。今回はデータ抽出の対象とする決算短信を分割せずに入力可能であることを重視し、Anthropic Claude 2 (100K) モデルを採用しました。 プラットフォーム LLM の業務導入では、LLM 単体の開発ではなく、業務システムとの統合を前提とした開発を行うことが重要になります。アプリケーションや業務システム統合を念頭に置いた場合、LLM に留まらず多くのサービスを提供する AWS を選択することで柔軟に業務システムを開発することが可能になると判断しています。 アプリケーション Amazon Bedrock と 他の AWS サービスを組み合わせてアプリケーションを実装しています。 Amazon ECS 上に Streamlit (*3) を用いたデータ整形のアプリケーションを実装 認証は Amazon Cognito を採用し、セキュリティと利便性を実現 決算短信の PDF データは ECS で定期的に取得し、データを S3 に保存 (*3) Python で簡易的な WEB アプリケーションを実装できるライブラリ セグメント別売上情報抽出業務：解決後業務イメージ （図4. セグメント別売上情報抽出 – LLM データ抽出システム） LLM データ抽出システム実装により、担当者の業務が改善されました。担当者が銘柄コードを入力するだけで、該当銘柄の適時開示資料におけるセグメント別売上情報のページ、およびそこから自動的に抽出されたセグメント別売上情報のテーブルがされるようになっています。担当者は表示された内容のチェックを行うだけでよく、情報を探索する手間や、転記ミスのリスクも低減されました。 ビジネス効果 LLM データ抽出システムの実装により、以下の成果を得ることができました。 (1) LLM による抽出精度 90% を達成 日本の上場株式約 100 銘柄を対象に検証した結果として、90% 以上の精度で正しく財務データの抽出に成功しました。また、今回失敗したケースについてもプロンプトのカスタマイズ等の対応によりさらなる改善が見込める状況です。 (2) 情報抽出のオペレーション工数を 50% 削減 従来資産運用会社のアナリストが Excel 等を用いてマニュアルで実施していた財務情報の検索と抽出が自動化された事により、情報抽出のオペレーションコストを 50% 削減しました。さらに副次的効果として、転記の際のコピー＆ペーストが削減され、ヒューマンエラーの削減にもつながっています。 (3) Streamlit で短期間のアプリケーション開発を実現 今回のシステムにおいては、AWS のマネージドサービスを活用するとともに、アプリケーション側の実装においてはローコード開発ツールである Streamlit を活用しました。それにより LLM アプリケーション開発担当 1 名のリソースにもかかわらず、短期間でのアプリケーション開発と効果検証を実現することができました。 今後の展望 今回の検証を踏まえ、今後さらに以下の展開を図っていくことを予定しています。 (1) 決算資料など対象業務の拡大 今回構築した仕組みをもとに、決算短信に加え、決算説明資料・有価証券報告書・大量保有報告書など様々な企業の開示資料に対象を拡大していきます。 (2) 全上場銘柄を対象にオペレーションを拡大 現状対象としている 100 社だけでなく、全銘柄を対象にすることでデータ単体でのマネタイズを目指します。また、オペレーション拡大に伴うデータ品質確保も図っていきます。 (3) オペレーションを他業種のデータにも拡大 適時開示資料をベースとしたシステム構築のノウハウを他業種にも展開し、データを拡充します。また、今回の調査オペレーション自体をカスタマイズし、クライアントへの提供を目指します。 まとめ 今回の検証により、Amazon Bedrock と AWS サービスを活用することで LLM アプリケーションを短期間で構築できることが実証できました。それにより、ビジネス適用時の業務検証 PDCA サイクルが高速化され、今後さらに幅広い領域へのビジネス展開ビジネスへの適用・拡張容易性向上が可能であるといった知見が得られました。 ナウキャストでは、データエンジニアリングと生成 AI 活用に強みを持っています。生成 AI に限らず、データ基盤構築やデータ利活用推進もあわせてご相談頂くことが可能です。データ活用や生成 AI 活用でお困りごとがございましたら、「株式会社ナウキャスト」で検索頂き、「デモリクエスト」よりお問い合わせを頂けますと幸いです。 == カスタマープロフィール：株式会社ナウキャスト ( Nowcast Inc. ) 株式会社ナウキャストは.、東京大学経済学研究科渡辺努研究室における「東大日次物価指数（現：日経CPINow）」プロジェクトを前身として設立された、オルタナティブデータのリーディングカンパニーです。

みなさんお久しぶりです！ 猫が大好きな Solutions Architect の服部です。昨年の AWS Summit Tokyo でご好評いただいた Chaos Kitty がパワーアップして AWS Summit Japan に帰ってきました！ この記事では、2024 年の AWS Summit Japan の Developer Zone 内で展示される、「 Chaos Kitty で楽しくインシデント対応ゲームをしよう！ 」についてご紹介します。本展示は、システムを構築する上でも重要なレジリエンスやセキュリティをゲームを通じて楽しく学ぶことができる体験型コンテンツです。システムのレジリエンスやセキュリティを強化したい全ての方に本記事を読んでいただき、実際に AWS Summit Japan の会場まで足を運んで体験いただけると幸いです。開催期間は 2024 年 6 月 20 日 (木) と 21 日 (金) の 2 日間で、会場は幕張メッセになります。まだ登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Village の Developer Zone の中にあります。詳細は こちら 。 Chaos Kitty とは？ Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、障害対応の体験学習ができるソリューションです。以下の 3 つの主要機能を備えています。詳細は、 昨年の記事 も合わせてご確認ください！ 1. IoT 電球によるリアルタイムの状態可視化 物理的なブロックと電球で表現された Web 3 層 アプリケーションのアーキテクチャにおいて、各コンポーネント (EC2, RDS, S3 など ) の状態が IoT 電球の色で示されます。電球は、正常な場合には緑、何か異常がある場合には赤で点灯する設定になっており、設定に異常が検出された場合には、電球が緑から赤に変わる仕組みとなっています。これにより AWS 上のアプリケーションの状況をリアルタイムで監視でき、異常をすぐに検知することができます。 2. 障害挿入機能による対応訓練 付属のボタンを押すと AWS での設定に意図的に設定ミスを注入し、IoT 電球の色が赤に変わります。ユーザーは AWS コンソールを使ってこの設定ミスを特定・修復し、電球を緑に戻すゲームを行います。修復が完了すれば、修復にかかった時間が表示され、手動での対応の難しさを体感できます。 3. 自動修復機能による対応の効率化 注入された設定変更に対して、自動修復するスクリプトを実行する物理的なボタンが用意されています。マネジメントコンソールを使用した手動修復と比べた自動化の優位性と、クリティカルなワークロードでの損失抑制の重要性を実感できます。 図 1 : Chaos Kitty 外観 図 2 : Web 3 層アプリケーション画面 パワーアップした Chaos Kitty とは？ 2023年までの Chaos Kitty のシナリオはセキュリティが中心でしたが、今年の Chaos Kitty はレジリエンスのシナリオを新たに追加し、実際にアプリケーションの障害と復旧をゲーム内で体感いただける内容となっております。レジリエンスを実現するためには、一部のコンポーネントに障害が発生しても稼働し続け、かつ自動で復旧するアーキテクチャを取ることが重要です。また、障害が発生した際に、素早く検知して復旧させるための調査の仕組みも必要となります。 Chaos Kitty ではゲームとしてわかりやすくするために、アプリケーションの問題箇所を電球で可視化していますが、実際のシステムではそう簡単にはいきません。実システムでは、ユーザ影響がある障害が発生しているかどうか、すぐに確認・分析できるようにするためのダッシュボードによる可視化が有効です。今回の Chaos Kitty では、レジリエンスのシナリオを通してシステムの状態を把握する必要性を実感いただくために、リソース稼働状況を一目で確認できるよう Amazon CloudWatch を活用したダッシュボードを用意しています。Amazon CloudWatch Synthetics を使ってリクエストの状態やレスポンスタイムを測定し、アプリケーションの稼働状況を監視したり、システム内のどこに障害が発生しているか把握するために AWS X-Ray を利用してトレース情報を取得し、ダッシュボードに表示するようにしています。本ゲームを通じて、レジリエンスのあるシステムの開発にご興味を持っていただけると幸いです。 図 3 : ダッシュボード画面 終わりに Chaos Kitty は実際の障害を模擬する形でサービスの稼働状況を電球やブロックを使ってわかりやすく表現しております。日頃クラウドサービスに慣れ親しむ機会が少ない方でも、運用における障害対応を気軽に体験いただけます。AWS Summit Japan 2024 で、皆様にお会いできることを楽しみにお待ちしております！ 服部 一成 自動車および製造業界向けビジネスユニットのソリューションアーキテクト。IoTの技術コミュニティに所属。 第二種電気工事士。最近の趣味は車の配線いじりとアウトドアグッズのウィンドショッピング。 Choas Kitty は AWS Japan ソリューションアーキテクトの高野 翔史、堀 貴裕、津郷 光明、宋 子豪、河角 修、服部 一成が中心となって運営しております。

本記事は 2024年6月12日に公開された “ Use Amazon DynamoDB incremental exports to drive continuous data retention ” を翻訳したものです。 Amazon DynamoDB は、 Amazon Simple Storage Service (Amazon S3) への 増分エクスポート に対応しており、さまざまなユースケースでの、ダウンストリームのデータ保持や利用を実現しています。 このブログでは、初期にフルエクスポートを行った後に、継続的な増分エクスポートを実行していくことで、エクスポートされたテーブルデータを継続的に更新していく方法を説明します。このソリューションはDynamoDB Continuous Incremental Exports (DCIE 、 GitHub でオープンソースにて提供) と呼ばれ、データが最新の状態に保たれた DynamoDB データのエクスポートを実現します。 DCIE のユースケースの一つは、DynamoDB テーブルに対するオフライン分析です。テーブルサイズが大きくなると、繰り返しフルエクスポートを行うよりも、一度フルエクスポートした後に増分エクスポートを行う方がコスト効率が良くなります。この方法を使えば、例えば Apache Iceberg テーブルを最新の状態に保つ ことができます。 DCIE の別のユースケースは、1 つの DynamoDB テーブルから別の DynamoDB テーブルへの変更を反映することです。 まず、新しいテーブルをフルエクスポートに基づいてブートストラップします。その後、新しいテーブルが最新になるまで、一連の増分エクスポートを進めていきます。新しいテーブルは、同じ AWS アカウント内の別のテーブル、別の AWS アカウント内のテーブル、さらには別の AWS リージョン内にあるテーブルでも構いません。 DCIE は一連のエクスポートを作成するのみであり、このブログではこれらのエクスポートを Iceberg テーブルに取り込んだり、別の DynamoDB テーブルに読み込むことには触れません。 継続的なエクスポート この節では、ワークフローの動作方法について説明します。まず、Amazon S3 へのフルエクスポートを実行します。これにより、特定の時点でのテーブル内容をキャプチャすることができます。次の図は、最近の時点 ( t = 0 と呼ばれる) で行われたフルエクスポートを示しています。 その後、デフォルトでは 15 分ごとに定期的な増分エクスポートを実行します。増分エクスポートごとに、2 つの時間の間(つまり、全エクスポートの終了から 15 分後まで)に発生した変更をキャプチャします。増分エクスポートは、コーディング時に差分表示される diff に似ています。その後、新しいエクスポートは、定期的に実行されます。 時間範囲が正確に一致していないと、期間にギャップが生じてしまいます。フルエクスポートの終了時刻は最初の増分エクスポートの開始時刻と一致している必要があります。また、最初の増分エクスポートの終了時刻は次の増分エクスポートの開始時刻でなければなりません。このようにすることで、テーブル全体の内容が一連のエクスポート結果に確実に反映されます。 次の図に示すように、 t = 1 で開始した増分エクスポートは完了までにしばらく時間がかかり、 t = 2 の後に完了する可能性があります。これは問題ありません。2 つの エクスポートは同時に実行できます。DynamoDB のエクスポートにはメタデータが含まれているため、エクスポートが正常に完了したかどうかを判断できます。また、エクスポートメタデータにより、ダウンストリームのコンシューマーは正常なエクスポートのみを正しい時系列順に処理できます。 ソリューションの概要 DCIE は Amazon EventBridge Scheduler を使用してワークフローを定期実行するスケジューリングを行い、ワークフロー内の調整を AWS Step Functions で管理しています。Step Functions を使用することで、このような分散アプリケーションを簡単にデザイン、カスタマイズ、実行、可視化、管理、再試行、そして視覚的にデバッグできます。 ワークフローのデプロイには、5 つのパラメータが必要です。複数のDynamoDB テーブルに複数回デプロイを行えるようにするためのスタック名、ソースとなる DynamoDB テーブル名、テーブルとインフラストラクチャの簡単なマッピングを可能にするデプロイエイリアス、エクスポート成功時の通知を受け取るメールアドレス、エクスポート失敗時の通知を受け取るメールアドレスです。Step Functions ステートマシンは、 Parameter Store を使用して状態を維持します。これは AWS Systems Manager の機能の 1 つです。 DCIE を AWS Cloud Development Kit (AWS CDK) を使ってデプロイすることができ、カスタマイズに上記のパラメータを設定するだけで済みます。また、カスタム S3 バケット、S3 プレフィックス、増分エクスポートの時間間隔をデフォルトの 15 分よりも長くする、エクスポートが完了したかを確認する間隔をデフォルトの 10 秒より長くまたは短くするなどのオプション設定も行えます。 Step Functions のワークフローは、まず事前チェックを行い、指定されたテーブルが存在し、 ポイントインタイムリカバリー (PITR) が有効になっているかを確認します。PITR は、S3 エクスポートに必須となります。 このワークフローには 2 つの主要なツリーがあります。最初にフルエクスポートを実行するツリーと、後続の増分エクスポートを実行するツリーです。それぞれのツリーは作業を開始し、定期的に完了やエラーを確認します。エラー時には状態の更新やメール送信を行います。特定のニーズがある場合は、ワークフローを自分で変更できます。次の図は、ワークフローの簡略化された論理的な表現です。 DCIE のデプロイの詳細については、GitHub リポジトリの README をご覧ください。 コストの管理 DCIE をデプロイするコストには以下が含まれます: PITR を有効にするための継続的な料金 (テーブルのサイズに基づきます) 初回 フルエクスポート の費用 (テーブルのサイズに基づきます) 各 増分エクスポート の費用 (処理するデータ量に応じ、また時間ウィンドウ内の変更数に比例します) Amazon S3 を使うために発生するコスト (オブジェクト書き込み、データストレージのコストは時間と共に増加します) AWS Lambda 、 Amazon Simple Notification Service (Amazon SNS)、 Amazon CloudWatch Logs の利用コスト まとめ DynamoDB の新しい Amazon S3 への増分エクスポート機能により、DynamoDB テーブル内のデータをダウンストリームのデータ コンシューマへ簡単にエクスポートできます。 このブログでは、最初にフルエクスポートを行い、その後、継続的な増分エクスポートのシリーズを生成することで、S3 バケットを継続的に更新するためのオープンソースソリューションを紹介しました。 これを利用することで、ダウンストリームの Iceberg テーブルにデータを供給したり、別の DynamoDB テーブルにデータを供給したり、または、リモートの S3 バケットにコピーして、リモートリージョンでテーブルを再作成するためのディザスターリカバリープランの一部として使用したりできます。 DynamoDB から S3 へのエクスポートの詳細については、 ドキュメントガイド を参照してください。 本ブログはソリューションアーキテクトの堤が翻訳しました。原文は こちら 。

この記事は Diving into Red Hat OpenShift Service on AWS (ROSA) with Hosted Control Planes (HCP) (記事公開日: 2024 年 1 月 22 日) を翻訳したものです。 はじめに 2015年に AWS で初めてリリースされて以来、Red Hat OpenShift は似たようなアーキテクチャを持ってきました。OpenShift 3 、 OpenShift 4 、自己管理の OpenShift Container Platform (OCP) か、マネージドサービスの ROSA  かを問わず、お客様はこれまで自身の AWS アカウント内に存在するコントロールプレーンについて、関連するコストを相殺して投資対効果 (ROI) を最大化する方法を検討してきました。これに応えるべく Red Hat は OpenShift 向けに Hosted Control Plane (HCP) をリリースしました。 この記事では、OpenShift における Hosted Control Plane の利点に詳しく掘り下げます。最近の変更点に注目し、従来のアーキテクチャと比較します。そして、これらの変更がユーザーに与える利点を明らかにします。 翻訳の時点(2024年6月13日)で、アジアパシフィック (東京) とアジアパシフィック (大阪)を含む多くのリージョンで Hosted Control Plane を備えた ROSA をご利用いただけます。 ROSA classic のアーキテクチャ OpenShift on AWS は、AWS とRed Hat OpenShift の高可用性モデルを組み合わせてきました。OpenShift コントロールプレーンと OpenShift API を提供する 3 つのコントロールプレーンノード、つまり Amazon Elastic Cloud Compute (Amazon EC2) インスタンスと、OpenShift ルーティングレイヤーとその他のクラスター関連機能を提供する 3 つのインフラストラクチャノードと、コンピューティングレイヤーであるワーカーノードがあります。これら全てがお客様のアカウントに存在し、複数の アベイラビリティーゾーン (AZ)  に配置されます。ROSA はマネージドサービスであるため、Red Hat Site Reliability Engineering (SRE) チームがお客様のアカウントに存在する OpenShift 環境を AWS PrivateLink 経由でアクセスしてお客様の代わりに管理・メンテナンスします。 従来の OpenShift on AWS アーキテクチャ ROSA を検討するお客様から尋ねられることの多い質問に、「他の AWS サービスの場合はコンピューティングノードのみですが、なぜ ROSA の場合はコントロールプレーンが私のアカウントにあるのですか?」「コントロールプレーンのリソースコストを削減するためのインセンティブプログラムとコスト管理オプションのベストプラクティスは何ですか?」「AZ 間のデータ転送コストの原因は何ですか?」があります。 ROSA の Hosted Control Plane (HCP) Red Hat が発表した OpenShift の hosted control plane により、お客様は多くの利点を得ることができます。 Hosted Control Plane ではコントロールプレーンノードが他の AWS サービスと同じようにお客様のアカウントから Red Hat のサービスチームアカウントへと移動されます。これにより、 Amazon EC2 や Amazon Elastic Block Store (Amazon EBS)  といった、お客様のアカウントにおける AWS サービスのコストが削減されます。また、OpenShift の Kubernetes レイヤーにおける etcd データベースがコントロールプレーンノードに存在することから、高可用性のための etcd レプリケーションに関する AZ 間のデータ転送コストもお客様のアカウントから取り除かれます。 Red Hat Site Reliability Engineering (SRE) チームがサービスチームアカウントから OpenShift クラスターを直接管理・メンテナンスします。お客様のアカウントにある AWS PrivateLink エンドポイントは、ワーカーノードがサービスチームアカウントのコントロールプレーンに接続するために用いられます。 3つの OpenShift インフラストラクチャノードもまた、お客様のアカウントから除去され、そのサービスはコントロールプレーンノードかワーカーノードに移行されます。ただし、OpenShift ルーティングレイヤーはワーカーノードに移動されることに留意してください。 このアプローチにより、コントロールプレーンノードとインフラストラクチャノード、および etcd 関連の AZ 間データ転送に関する Amazon EC2 と Amazon EBS の AWS サービスコストが削減されます。Hosted Control Plane には、コントロールプレーンノードとワーカーノードが並列的にプロビジョニングされるため、プロビジョニング時間が短縮される利点もあります。 HCP を備えた ROSA クラスターのデプロイ 既存の ROSA クラスターを Hosted Control Plane アーキテクチャへアップグレードまたは変換することはできません。HCP を備えた ROSA を活用するには新しいクラスターを作成する必要があります。 前提条件 デフォルト設定を使い、 AWS Identity and Access Management (AWS IAM)  リソースを自動作成すれば、HCP を備えた ROSA クラスターのデプロイは容易になります。ROSA CLI の rosa を使ってクラスターのデプロイを開始できます。HCP を備えた ROSA クラスターを rosa で作成する前に、アカウント全体のロールとポリシー、operator ロールを事前に準備しておく必要があります。 HCP を備えた ROSA クラスターを作成するために必要な重要なコンポーネントについて説明します。HCP を備えた ROSA クラスターを作成するには、次の項目が必要です。 設定済の Virtual Private Cloud (VPC) アカウント全体のロール OpenID Connect (OIDC) の設定 Operator ロール Virtual Private Cloud (VPC) Hosted Control Plane は既存の Virtual Private Cloud (VPC) にデプロイする必要があります。ほとんどのお客様は、既存の VPC を何らかの Infrastructure as Code (IaC) の形式で管理しています。VPC は手動で作成したり、 Terraform テンプレートを使って作成したりできます。Terraform はテンプレートを使ってさまざまなリソースを作成するためのツールです。VPC を Terraform テンプレートを使って構築する詳細なドキュメントは こちら です。 アカウント全体の STS ロールとポリシー セキュリティに関して、ROSA の異なるコンポーネントにアタッチされる AWS IAM ポリシーに変更があります。最小特権の原則に沿って、より限定的な AWS IAM ポリシーの使用が進められています。アカウント全体のロールの作成を再実行する必要があり、各 OpenShift operator ごとにより細かいロールが新たに必要になるといった変更があります。 HCP を備えた ROSA クラスターでは、そのデプロイメント向けに特別に設計された重要な AWS IAM ロールを事前に準備する必要があります。クラスターの operator はこれら operator ロールを使ってクラスター操作を行うための一時的な権限を取得します。 HCP を備えた ROSA クラスターは AWS Security Token Service (AWS STS)  による認証のみをサポートします。AWS STS は、ユーザーに対する一時的で権限の限られた認証情報を要求できるサービスです。 AWS PrivateLink ROSA classic アーキテクチャでは、 AWS PrivateLink  によって Red Hat SRE チームがお客様に代わってOpenShift クラスターに接続して環境を管理できるようになっていました。HCP アーキテクチャでは Red Hat SRE チームがサービスアカウントからお客様の環境を管理し、AWS PrivateLink はワーカーノードがコントロールプレーンに接続するために使われます。 プロビジョニング 以下に示すコマンドを使ってアカウントロール、operator ロール、OpenID Connect の設定を作成し、クラスターをデプロイします。詳細については、ドキュメントの「 デフォルトのオプションを使用した ROSA with HCP クラスターの作成 」もしくは「 Getting started with ROSA with HCP using the ROSA CLI in auto mode 」を参照してください。 アカウント全体のロール: 次のコマンドを使って必要な AWS IAM アカウントロールとポリシーを作成します。 $ rosa create account-roles --force-policy-creation OpenID Connect の設定: 次のコマンドを使って OIDC の設定と AWS リソースを作成します。 $ rosa create oidc-config --mode=auto --yes operator ロール: 次のコマンドを使って operator ロールを作成します。 $ rosa create operator-roles --hosted-cp --prefix <prefix-name> --oidc-config-id <oidc-config-id> クラスターのデプロイ: 次のコマンドのいずれかを使って HCP を備えた ROSA クラスターをデプロイします。 $ rosa create cluster --private --cluster-name=<cluster_name> --sts --mode=auto --hosted-cp --subnet-ids=<private-subnet-id> $ export REGION=<region_name> $ export ROSA_VERSION=<rosa_version> $ rosa create cluster --cluster-name <cluster_name> --multi-az --hosted-cp --mode=auto --sts --region $REGION --version $ROSA_VERSION --enable-autoscaling --min-replicas <minimum_replicas> --max-replicas <maximum_replicas> --compute-machine-type <instance_type> --host-prefix <host_prefix> --private --subnet-ids <subnet_id_1>,<subnet_id_2>,<subnet_id_3> --operator-roles-prefix <prefix-name> --oidc-config-id <oidc-config-id> 例: $ export REGION=us-west-2 $ export ROSA_VERSION=4.14.27 $ rosa create cluster --cluster-name my-cluster --multi-az --hosted-cp --mode=auto --sts --region $REGION --version $ROSA_VERSION --enable-autoscaling --min-replicas 3 --max-replicas 3 --compute-machine-type m5.2xlarge --host-prefix 23 --private --subnet-ids subnet-0aed73cfa77880167,subnet-07b78438a58648748,subnet-051e2679837a4cc42 --operator-roles-prefix rosa-hcp --oidc-config-id 2bp1mhs3fcbhq1vi40u0mh9vh17f3fm8 クリーンアップ ROSA クラスターと AWS STS リソースを削除する手順については、ドキュメントの「 ROSA with HCP クラスターの削除 」もしくは「 Delete a cluster and AWS STS resources 」を参照してください。 ROSA classic をご利用のお客様のための移行パス 現時点では、ROSA HCP クラスターをプロビジョニングし、その後アプリケーションワークロードを移行する必要があります。 ROSA classic から ROSA HCP へのインプレースアップグレードはできません。移行を考えているお客様は、 Red Hat Migration Toolkit for Containers の活用を検討してください。これはアップストリームの Konveyor  プロジェクトに基づいています。 まとめ この記事では、OpenShift における Hosted Control Plane の利点について解説しました。変更点に注目し、従来のアーキテクチャと比較しました。Hosted Control Plane (HCP) は OpenShift on AWS のデプロイと管理に新しい時代を切り開きます。この革新的な変更はコスト削減、運用の高可用性とセキュリティ強化、クラスターのプロビジョニングに要する時間の改善をもたらします。お客様のビジネスにおいて、HCP を備えた ROSA クラスターの新しい可能性と利点を検討することをお勧めします。 翻訳の時点(2024年6月13日)で、アジアパシフィック (東京) とアジアパシフィック (大阪)を含む 多くのリージョン で HCP を備えた ROSA をご利用いただけます。 追加情報 HCP を備えた ROSA クラスターのインストールについては、「 ROSA with HCP クラスターのインストール 」を参照してください。 ROSA のクイックスタートガイドについては「 Red Hat OpenShift Service on AWS クイックスタートガイド 」を参照してください。 アーキテクチャとネットワークの詳細については、「 ROSA: Architecture and Networking 」を参照してください。 Migration toolkit for containers の詳細については、「 Ask an OpenShift Admin (E68) | Migration toolkit for containers 」を参照してください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

この投稿はネットアップ合同会社 岩井 陽太郎 氏に、サイバーレジリエンスの解説と AWS における実装ポイントについて寄稿いただいたものです。 皆様はサイバーレジリエンスという言葉に聞き覚えはありますか？企業のデジタル化が進む中、ビジネスにおける IT 部門の担う責任は日々重くなってきています。これまではサイバーセキュリティの考え方に則った、被害をどう防いでいくかに焦点を当てた「防御」の考え方に大きく注目が集まっていましたが、際限のない投資が必要なことから「セキュリティ疲れ」とも呼ばれる反動が起きています。そこで昨今では「防御」だけではなく、被災することを前提としてそこからいかに迅速に「回復」・「復旧」するかという「サイバーレジリエンス」という考え方が注目を集めています。 本ブログシリーズでは、サイバーレジリエンスについて組織の重要な資産である「データ」の観点でご紹介していきます。第 1 回ブログでは、「サイバーレジリエンス」に関する基礎的な内容を解説します。 組織を取り巻く様々な事業継続リスク 皆様を取り巻く環境には、ビジネスの継続を困難にする多くのリスクが存在しています。特に日本では、大規模な自然災害のリスクと常に隣り合わせにあります。南海トラフ地震のような予測不可能な災害に備えなければならなかったり、地球温暖化による台風の大型化/強大化も懸念されています。また、昨今猛威を振るうランサムウェア攻撃に対して防御策を講じることや、年々規制が厳しくなっているコンプライアンスや法令違反のリスクへの備えも重要です。これらの事業継続リスクについて、もう少し掘り下げていきます。 自然災害リスク 自然災害には地震、津波、土砂災害、台風、豪雨、感染症の流行などさまざまな種類があり、どれも大きな脅威です。このような大規模な災害が発生した場合、ビジネスを継続させるためには復旧作業だけでなく、限られた人員での運用や予期せぬ業務にも対応する必要があります。 地震を例に挙げて説明します。まず被害として、建物の倒壊、機材の破損などが想定されます。物理的な修復作業はもちろん必要ですが、被災時には予想外の業務が頻繁に発生します。たとえば市役所の場合、地震が発生すると住民に対して罹災証明書を発行するという通常は行わない業務が一時的に必要になります。これらの業務は、被災した社員や職員自身が行わなければならないため、非常に困難な作業となります。 サイバー攻撃リスク 特に最近では、国内外でサイバー攻撃による被害が増加しており、多くの企業が重大な事業継続リスクとして認識しています。特に近年では、ランサムウェアによる被害が拡大しており、関心が高まっています。かつて、コンピュータウイルスが広まった時代には、「誰でもいいから困らせたい」という愉快犯的な行為が主流でしたが、現在ではダークウェブ上でのランサムウェア攻撃がビジネスとして成立してしまっており、ランサムウェアを使った身代金を要求する犯罪が組織的に行われています。具体的には、ランサムウェアを開発するグループや、攻撃対象となる組織の認証情報を盗むアクセスブローカー、彼らからランサムウェアや有効な認証情報を購入し、実際に攻撃を実行するグループなど、分業体制が確立されています。 コンプライアンスの遵守や法令違反のリスク General data Protection Regulation (GDPR) という規制をご存知でしょうか？GDPR は、欧州連合 (European Union: EU) におけるデータ保護に関する規則で、世界で最も厳しいとされており、罰金の金額は増加傾向にあります。このような規制には、ヨーロッパ在住のユーザーに対してサービスを提供している場合や、現地法人を持ち、現地の従業員が働いている場合など、本社が海外にあったとしてもヨーロッパに関連する事業に対して適用されるという注意点があります。実際、2022 年には日本の大手システムインテグレーターが現地法人によるデータ漏洩の違反で罰金を支払うケースがありました。 また、日本国内でもデータに関する規制は厳しくなっており、大きく二つの法改正が行われています。一つは個人情報保護法の改正です。2020 年に改正され、法人による報告や通知の義務化、措置命令違反や不正流用に対する罰則が強化されました (改正前は 30 万円以下、改正後は 1 億円以下) 。もう一つは、2022 年に改正された電子帳票保存法です。この改正により、電子取引に関する情報を紙ではなく電磁気的に記録することが義務化されました。データの活用が進む中で、プライバシーやコンプライアンスに関する規制もより厳しくなっています。このような規制の改正は、ビジネスにおいて金銭的および社会的な大きなリスクとなる可能性があるため、注意が必要です。 そしてサイバーレジリエンスの考え方へ 企業は、さまざまな事業継続リスクに対して対策を策定する必要があります。しかし、攻撃者にとっては一度でも攻撃が成功すればよく、防御側は常に守り続けなければなりません。そのため、際限のない投資が必要となるのと同時に、コストをかけても効果が保証されるわけではありません。また、そのような投資は事業利益を直接的に生み出すわけではなく、被害が起こらなければ投資対効果を定量的に示すことが難しい場合もあるかもしれません。このような状況から、組織は慢性的な「セキュリティ疲れ」に悩まされることが増えており、対応を後回しにすることもあります。 数年前より欧米を中心に、サイバーレジリエンスという「復元力」に焦点を当てたアプローチが注目されています。様々なリスクによる被害を受けないよう有効な防御策を講じることは重要ですが、サイバーレジリエンスの考え方は、「被災することを前提として、そこからいかに迅速に回復・復旧するか」に焦点を当てます。こうしたシステムを守るための考え方について、アメリカ国立標準技術研究所 (National Institute of Standards and Technology: NIST) は 2014 年に「レジリエンス」の考え方を盛り込んだ、Cybersecurity Framework (CSF) の 1.0 版を公開しました。この CSF では、以下の 5 つの機能をフレームワークの「コア」として定義しています。 Identify [識別]: リスクの特定と評価 Protect [防御]: 適切な保護対策の実施 Detect [検知]: セキュリティイベントの発生の識別 Response [対応]: 関係者間調整や分析、影響緩和や改善の実施 Recover [復旧]: システムや資産の復旧 これら 5 つの機能を分類すると、「識別」と「防御」は防御力に焦点を当てた従来の「サイバーセキュリティ」に関する部分にあたるのに対し、後半の「検知」「対応」「復旧」では万が一被災した場合に変化する状況に適応しながら迅速にシステムを復旧させる「復元力：レジリエンス」に焦点を当てた機能という事が読み取れます。 サイバーレジリエンスの手法と取り組み方 CSF の内容は汎用的なフレームワークであり、サイバーレジリエンスの概念や体制を包括的にまとめています。さらに、個別のテーマに応じた具体的な手法や手順をまとめている 「 SP800-160 Vol.2 : Developing Cyber-Resilient Systems: A Systems Security Engineering Approach 」 (以下、ガイドライン) があり、「サイバーレジリエンス」に関連する取り組みの「目的」「目標」「手法」について解説しています。 図 1: サイバーレジリエンスの「目的」「目標」「手法」 これら手法の定義はやや抽象的な表現が用いられていますが、このガイドラインでは、より実装に近い「取り組み方」についても提案しています。各手法の詳細な解説は省略しますが、データの観点での「復元力」に関連する以下の 3 つの手法について掘り下げてみます。 権限の制限 データの外部からの保護機能が充実していても、ユーザーにおける対策が不十分だと、リスクを未然に防ぐことはできません。具体的には「最小権限の原則」に従い、特権ユーザーである「root」や「Administrator」を共有せず、役割に応じて必要最小限の特権を個々のユーザーに与える「ロールベースのアクセス制御」や、場所や時間帯によるアクセス制限、パスワード漏えい・詐取による不正ログインに対して耐性を高めるための多要素認証 (Multi-Factor Authentication: MFA) などが挙げられます。また、管理者権限を持つ悪意のあるユーザーや偶発的な誤操作によるリスクを防ぐためには、「複数管理者認証機能」など、特定の操作に他の管理者の承認が必要な仕組みも効果的です。 分析的な監視 最近では、データを破壊する攻撃だけでなく、データの窃盗も頻繁に発生しています。このような被害を防ぐ手段としては、監査ログの取得と保全、複数の事象からの合的な攻撃検出、そして異常な振る舞いの検知などが挙げられます。監査ログは、攻撃の検出や原因究明だけでなく、被害範囲の特定とピンポイントな復元のためにも重要です。また、内部者によるデータの持ち出しなどの操作は、気づかれずに行われることが多いです。通常と異なるデータへのアクセスの仕方を検出してアクセスを自動的に遮断し、管理者に通報すると同時に、その時点でのデータバックアップを即座に取得するなどの仕組みも効果的です。 冗長化 最後に、データの観点でのレジリエンスにおいて最もイメージしやすく、非常に重要となってくるのがこの「冗長化」ではないでしょうか。 NIST が公開してるガイドラインには、「冗長化」への取り組み方が ３ つ示されています。 余剰容量（surplus capacity） 複製（replication） 保護されたバックアップとリストア（protected backup and restore） 具体的には、システムにおける性能・容量を余剰容量として換算し、安全マージンを施した設計・設定で運用したり、クラウドを活用した一時的な拡張によるクラウドバースト、サーバーの冗長化、サービス提供ロケーション（アベイラビリティゾーン）の冗長化、データのバックアップなどが当てはまります。特に重要な経営資源となる「データ」は、一度失うと復旧は容易ではなく影響が大きなものとなるため、バックアップつまりは「データの冗長化」が必要になります。 データの冗長化、言い換えると、データのバックアップ取得の必要性については、AWS が公開している データバックアップとは何ですか?  で整理されていますので引用したいと思います。 データのバックアップが重要なのはなぜですか? あらゆる組織はシステムが常に想定どおりに動作することを望んでいますが、分離されたシステムコンポーネントでは障害が発生する可能性があり、実際に障害が発生しています。まれにではありますが、システム全体での障害が発生する可能性もあります。データバックアップとは、障害が発生したときに復元できるように、組織のデータをコピーするインフラストラクチャ、テクノロジー、プロセスをいいます。これには、適切なデータバックアップ戦略とソリューションを含むディザスタリカバリ計画が含まれます。 効果的なデータバックアップにより、災害時におけるデータとシステムの損失を防ぎます。これは、想定外の状況であっても、ビジネスの継続性と中断のないサービスを実現するのに役立ちます。重要なビジネスシステムは、ビジネスに対する影響を最小限に抑えながら、運用を迅速に開始できます。 適切なデータのバックアップと復旧がなければ、システムは数時間、数日、または数週間にわたってオフラインになる可能性があります。状況によっては、エキスパートのデジタルフォレンジックの助けを借りても、まったく復旧できない場合があります。 データの冗長化（バックアップ）実践 データの冗長化（バックアップ）として良く知られた考え方として、「3-2-1 ルール」があります。この 3-2-1 ルールについても AWS が公開している データバックアップとは何ですか? から引用してご紹介します。 このルールは、どのような種類の障害が発生しても最大限の復旧可能性を得るためには、2 つの異なる種類のメディアに少なくとも 3 つのデータコピーが必要であり、1 つはオフサイトコピーである必要があるという旨を規定するものです。多くの組織は、3-2-1 ルールに従うことを選択しています。 バックアップを取得する際には、更に「バックアップしたデータの保護」についても留意すべきです。昨今のランサムウェア攻撃では、オリジナルデータを暗号化・改ざん・削除するだけでなく、バックアップからの復元を妨げるためにバックアップデータも破壊する事例も登場しています。特権ユーザーによる悪意のある操作でバックアップデータが破壊された事例もあり、削除できない保護されたバックアップ（Immutable Backup）を取得する必要があります。 また、バックアップデータからの復旧の「しやすさ」についても考慮しておく必要があります。特にランサムウェア攻撃からのデータ復旧では、「最新のバックアップデータを利用して、すべてのデータをリストアする」といった単純なものではなく、「暗号化されたファイルやフォルダはなにか」「どのユーザーや経路から攻撃されたのか」といった解析を行うデジタルフォレンジックをシステム・サービスの復旧と並行で行う必要があります。 このため「暗号化されてしまったデータを攻撃される前のバックアップデータを利用して、別の安全な環境にリストアすることでシステム・サービスを復旧する」といった復旧のしやすさが重要になります。 AWS でどのように実装するか 皆様が抱えている事業継続のリスクに応じ、サイバーレジリエンスの考え方に基づきシステムを迅速に復旧させる仕組みを実装していかなければなりません。現在、多くのお客様がオンプレミスとクラウド両方の環境をお持ちであることを考慮し、まずは変更や機能の追加が迅速かつ容易なクラウド環境から取り組み始めてはいかがでしょうか？ クラウドサービスを利用する上で事業者 (AWS) とお客様の間で様々な責任を共有することになるため、利用者は自身の責任範疇を明確に理解する必要があります。AWS では、一般的なクラウド上でのベストプラクティスを述べた AWS Well-Architected Framework を公開しています。その中でも、レジリエンスに関連する「信頼性の柱」について説明している 回復に関する責任共有モデル を参照するとよいのではないでしょうか。クラウドの回復性：サービスを実行するインフラストラクチャの回復性に責任を持つ AWS と、クラウド内での回復性：利用するサービスごとに適切な設定を実行する責任を持つお客様でお互いの責任を理解し、ベストプラクティスに則った信頼性の高いインフラの構築にお役立てください。 まとめ これまで IT の世界では、いかに脅威や災害からシステムを「防御」するかについての対策が取られてきました。しかし、サイバー攻撃手法の多様化や災害大国という立地から、すべての被害を防ぎきることが難しくなりつつあります。「防御」だけでなく、被害からいかに迅速に「復旧」するか、つまり「サイバーレジリエンス」を考えることが重要です。NIST が発表している CSF や SP-800 シリーズといったドキュメントを読み解き、どのようにデータの「復元力」を実現するか本ブログシリーズを通してご紹介していきます。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 いよいよ今週は AWS Summit Japan です！たくさんのセッションをはじめとする、学びの機会をご用意すべくAWS Japanのスタッフ一同で力を注いできました。もちろん生成AIに関するコンテンツも充実しています。私自身は特定のブースに立っているわけではないのですが、会場を歩き回っている予定ですので見かけたらぜひお声がけくださいね。 それでは、6 月 10 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: レアジョブテクノロジーズ様、英会話レッスンレポートのさらなる充実に生成AIを活用 レアジョブグループ 様が展開する「 レアジョブ英会話 」では、PCやスマホで様々な講師と英会話レッスンが受講できます。従来、英会話の講師がメモを残し、受講者に対してフィードバックを作成する作業を行っており、講師側の負担になっていたそうです。それを生成AIで解決する事を狙い、Amazon Bedrockを活用した生成AIによる「AIレッスンレポート」を開発されました。現時点では一部のお客様に限定して展開しているそうですが、利用者からは好意的な反応が得られているそうです。 builders.flashにも記事が出ています ので、こちらもあわせてご覧ください。builders.flashのほうはブログ記事よりももう少し技術的な詳細に踏み込んでいますので、両方見ていただくと理解が深まります。 AWS生成AI国内事例ブログ: ファーストトレード様、海洋情報APIとAmazon Bedrockで海況自動文書化を実現 ファーストトレード株式会社 様は「 なみある？ 」というサーフィンを楽しむ方に向けた波情報アプリを提供していらっしゃいます。これまで、手作業で海況情報を作成していましたが、作業の非効率性や品質のばらつき、情報入手コストの高騰が課題になっていました。これに対してAmazon Bedrockで生成AIを組み込むことで、海況情報文書の自動作成による課題解決に取り組みました。これによって、手作業が自動化され無人による文書生成、波情報のリアルタイム更新が可能になりました。また、AIによる高品質な波情報の提供が可能になるとともに、文書化のコストが80%削減されるという結果を確認されています。 AWS生成AI国内事例ブログ: KDDIアジャイル開発センター株式会社様、Amazon Bedrock統合によるチャットボットをグループ4社に展開 KDDIアジャイル開発センター株式会社 様では、日常業務への生成AIの積極活用を推進していらっしゃいますが、同時にセキュリティやシャドーITなどのコンプライアンスに関する懸念がありました。これを解決することを目的に、社内で利用しているSlackをインタフェースとしてセキュアに利用できる生成AI環境をAmazon Bedrockを利用して開発されました。セキュリティを担保するために全ての履歴とログを保存するとともに、サーバ側との通信にはパブリックなエンドポイントを経由しない通信方式を採用することで社内のセキュリティ監査で認められ、業務情報にも活用できる環境を構築できたとのことです。現在、KDDI Digital Divergence Holdingsグループ4社の約1,200名に展開しており、非エンジニアの方の利用も広がっているそうです。 AWS生成AI国内事例ブログ: JFEエンジニアリング株式会社様、建設業における業務効率化に生成AIを活用 JFEエンジニアリング株式会社 様は、生成AIを活用したプラットフォーム「Pla’cello xChat」を開発し、建設業における見積もり等の業務の効率化に取り組んでいらっしゃいます。2023年9月にリリースされたPla’cello xChatですが、11月に実業務に役立つユースケースの特定に着手され、PoCを通じて効果が確認できたものをアプリケーションとして実装する作業を進めていらっしゃいます。その一例が、見積書からのデータ抽出です。ある事業部では年間5,000時間を要しているそうです。今回、OCRと生成AIを組み合わせる事で高い精度でのデータ抽出が実現され、実際に使用した事業部のユーザーによれば見積もり比較業務の時間を数十パーセント削減できることが期待できるとのことです。 ブログ記事「誰でも簡単に生成AIを活用！AWS Japanメンバーが作ったPartyRockアプリ集」を公開 AWSが提供する「 PartyRock 」は画面操作と自然言語による指示だけで簡単に生成AIを組み込んだアプリを作成し、URL共有により誰でもアクセスできるようにする仕組みです。6/20-21に開催される AWS Summit Japan にむけて、AWS JapanのメンバーがPartyRockで開発したアプリをブログで公開しました。PartyRockはこの記事を執筆した時点ではAWSアカウントもクレジットカードも不要で、無料でご利用頂けますのでぜひトライしてみてください。AWS Summit Japanでは、AWS Villageの生成AIコーナーでPartyRockのブースも用意していますので、こちらもお見逃しなく。 ブログ記事「生成AIのマーケティング戦略への適用: 入門編」を公開 生成AIは様々な分野への応用が期待されていますが、そのひとつにマーケティング分野があります。このブログ記事は「生成AIのマーケティング戦略への適用」というシリーズを構成するひとつで、AI主導のコンテンツ生成と効果的なコンテンツ配信のためのマーケター向けポータルの構築について解説しています。 サービスアップデート Amazon SageMaker Canvasで利用した基盤モデルの本番環境への転用が容易に Amazon SageMaker Canvasから、基盤モデルをSagaMakerのリアルタイム推論エンドポイントにデプロイできるようになりました。SageMaker Canvasは様々な基盤モデルをもとに、検索拡張生成(RAG)によるモデルの応答のカスタマイズや、基盤モデルの微調整が可能です。SageMaker Canvasで作業した成果を、Amazon SageMakerのリアルタイム推論エンドポイントにデプロイする事で、本番で利用するアプリケーションに容易に組み込みが可能です。リアルタイム推論エンドポイントはフルマネージドで負荷に応じてスケーリングしますので、運用の手間も最小化できます。 Amazon CloudWatchで自然言語によるクエリ生成が可能に Amazon CloudWatch は、収集されたログとメトリクスを分析することで潜在する問題や改善箇所の発見を容易にします。今回のアップデートで、生成AIの技術を活用することによって自然言語でログやメトリクスを分析するクエリを生成できるようになりました。現時点では英語に対応する形ですが、例えば「過去24時間で最も遅かったLambdaへのリクエストを表示して」「最もスロットリングが発生しているDynamoDBのテーブルは？」といった質問に対して、蓄積されたデータに基づいた応答を返します。 AWS CloudTrail Lakeで自然言語によるクエリ生成が可能に AWS CloudTrail はユーザアクティビティとAPIの使用状況をログとして記録するサービスで、 AWS CloudTrail Lake はその情報に対してSQLライクの言語でクエリが可能な仕組みです。今回、生成AIの技術によって自然言語を利用した問い合わせが可能になりました。現時点では英語に対応しており「過去一週間のエラー数とその原因は？」「昨日マネジメントコンソールでログインしたユーザを一覧表示して」といったリクエストに応答してくれます。 AWS Audit Manager generative AI best practicesの対象サービスにAmazon SageMakerを追加 AWS Audit Manager はAWSの使用状況を継続的にチェックし、リスクとコンプライアンスの評価を容易にするサービスです。責任あるAIの利用は重要なテーマですが、AWS Audit Managerは生成AIに関する ベストプラクティスをまとめたフレームワーク を提供しています。発表当初はAmazon Bedrockが対象となっていましたが、今回Amazon SageMakerが対象に含まれました。このツールを利用することでBedrockやSageMakerを介した生成AIアプリケーションのベストプラクティス準拠状況の把握や、監査に必要な情報収集が容易になります。 ブログ記事 もご確認ください。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 いよいよ、日本最大の “AWS クラウドを学ぶイベント” 、 AWS Summit Japan が今週、木曜・金曜日に幕張メッセで開催されます。私たちもより良い内容でお届けできるよう、最後の準備をしているところです。以下のサイトより事前登録が可能です。私は初日の14:50～「オンプレミス上のデータを AWS クラウドの分析基盤に取り込む手法の整理」での登壇と、それ以外にも両日AWSのブース等に居る予定です。ぜひ当日は幕張でお会いしましょう！ – AWS Summit Japan | 2024 年 6 月 20 日（木）, 21 日（金） 幕張メッセ会場とライブ配信で同時開催 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年6月10日週の主要なアップデート 6/10(月) AWS IAM Access Analyzer now offers recommendations to refine unused access – AWS AWS Identity and Access Management (IAM) Access Analyzer で、未使用のアクセス（権限）を削減するための推奨事項が提供されるようになりました。権限の設定、検証、調整するためのツールが追加され、最小限の権限しか与えないベストプラクティスにそった設定がより容易に実現できるようになりました。 Amazon CloudWatch Application Signals, for application monitoring (APM) is generally available – AWS Amazon CloudWatch の OpenTelemetry（OTel）互換のアプリケーションパフォーマンスモニタリング（APM）機能である Amazon CloudWatch Application Signals の一般提供が発表されました。これにより、AWS上のアプリケーションのサービスレベル目標（SLO）に対するパフォーマンスの計測や追跡が容易になります。CloudWatch Application Signalsでは、重要なメトリクス（ボリューム、可用性、レイテンシー、障害、エラー）を示すダッシュボードも提供されるため、ユーザー側でダッシュボードを構築する必要がなく、手作業でダッシュボードを構築する必要がありません。 AWS CloudFormation accelerates dev-test cycle with adjustable timeouts for custom resources – AWS AWS CloudFormation で、サービスタイムアウトと呼ばれるカスタムリソース用の新しいプロパティが利用可能になりました。これによりカスタムリソースでのプロビジョニングロジックの実行の最大タイムアウトを個別に設定できるようになるため、例えば開発/テストサイクルにおけるフィードバックループを速くすることが可能になります。 Amazon CloudWatch announces AI-Powered natural language query generation – AWS Amazon CloudWatch で、生成AI を利用した自然言語クエリ生成の一般提供を発表しました。この機能により、ログやメトリックスデータに関連するクエリを平易な言葉をもとに生成できるようになりました。例えば”Which DynamoDB table is most throttled”(最もスロットルされた DynamoDB テーブルはどれですか)というような形で指示を出すことができます。これにより、クエリ言語に関する知識がなくても、観測したデータからインサイトを集めることが可能になります。この機能は現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京) リージョンで利用可能です。 6/11(火) AWS Identity and Access Management now supports passkey as a second authentication factor – AWS AWS Identity and Access Management (IAM) で、パスキーが2つ目の認証要素（多要素認証）としてサポートされました。パスキー(Passkeys)は FIDO 標準で規定された認証技術のひとつです。これにより、スマートフォン、Apple MacBook の Touch ID や Windows Hello など、機器に組み込まれたパスキー対応の認証システムを使って、安全にIAM認証を行うことが可能になります。 Detect malware in new object uploads to Amazon S3 with Amazon GuardDuty – AWS Amazon GuardDuty Malware Protection for Amazon S3 (Amazon S3 向けの Amazon GuardDuty マルウェア対策) の一般提供が発表されました。この機能は、Amazon S3 バケットに新しくアップロードされたオブジェクトをスキャンして、潜在的なマルウェア、ウイルス、その他の疑わしいアップロードがないかスキャンします。また、スキャンした結果によりタグが付けられるので、それを使ったアクセス制御を実行したり、 Amazon EventBridge 経由で通知を受け取って追加のアクションを実行することが可能です。 詳細はこちらのブログ をご覧ください。 AWS CloudTrail Lake announces AI-powered natural language query generation (preview) – AWS AWS CloudTrail Lake で AI を活用した自然言語クエリ生成機能がプレビューで利用可能になりました。CloudTrail Lake は CloudTrail のデータを蓄積し、SQLライクなクエリ言語で分析を可能にするサービスですが、このクエリを自然言語、例えば “Show me all users who logged in using console yesterday” (昨日コンソールを使用してログインしたすべてのユーザーを表示) といった形で指示を出すことで、クエリを生成することが可能です。 6/12(水) Productionize Foundation Models from SageMaker Canvas – AWS Amazon SageMaker Canvasから、基盤モデル (FM) をSagaMakerのリアルタイム推論エンドポイントにデプロイできるようになりました。SageMaker Canvasは様々な基盤モデルをもとに、検索拡張生成(RAG)によるモデルの応答のカスタマイズや、基盤モデルの微調整が可能です。SageMaker Canvasで作業した成果を、Amazon SageMakerのリアルタイム推論エンドポイントにデプロイする事で、より迅速な開発が可能になります。 Amazon OpenSearch Serverless now supports Internet Protocol Version 6 (IPv6) – AWS Amazon OpenSearch Serverless で、OpenSearch Serverless collectio のエンドポイントに Internet Protocol Version 6 (IPv6) が利用可能になりました。現在、東京リージョンを含む11のリージョンで利用可能です。 Amazon ElastiCache Serverless now supports snapshot and restore for Memcached – AWS Amazon ElastiCache Serverless に、Memcached のデータを自動的にバックアップ、リストアする機能が追加されました。保存されたスナップショットはサービス復旧時に有用なだけでなく、Amazon ElastiCache Serverless に複製を作成するためにも利用可能です。 6/13(木) （この日は、本ブログで取り上げる発表がありませんでした） 6/14(金) Cross-region failover now available in AWS Elemental MediaPackage – AWS AWS Elemental MediaPackage Live で、Amazon CloudFront 等のコンテンツ配信ネットワーク (CDN) を経由して配信している構成において、CDNと複数の AWS リージョンにある AWS Elemental MediaPackage Live オリジン間で透過的にフェイルオーバーできるようになりました。プライマリのストリームが古くなったり不完全だったりした場合に、ユーザーの視聴を中断することなくシームレスにバックアップオリジンにフェイルオーバーする構成が実現可能です。 最後に1つお知らせを。以前より何度か紹介していますが、 Aurora MySQL-Compatible Edition version 2 の標準サポート終了が今年の10月31日に迫ってきています。まだ V2 をご利用の方は以下の記事等を参考に Aurora MySQL-Compatible Edition version 3 への更新を検討してください。更新が10月末に間に合わない場合は RDS Extended Support での一時的な保守の延長も合わせてご検討ください。 – Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート 1 – Amazon Aurora MySQL バージョン 2 (MySQL 5.7 互換) からバージョン 3 (MySQL 8.0 互換) へのアップグレードのチェックリスト、パート2 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

複数の拠点に工場やプラントを持つ企業において、何千もあるモーターやポンプなど設備の保全タイミング管理は操業品質とコストに影響する重要な課題です。 AWS Japan ソリューションアーキテクトチームに所属する執筆者は、この課題に対するソリューションのデモを開発し、来る 2024 年 6 月 20 日、 21 日に開催する “ AWS Summit 2024 Japan “ にデモ展示します。デモは産業設備の予知保全サービス Amazon Monitron と AWS IoT SiteWise などのさまざまな AWS サービスを統合し、多拠点にある工場設備群の不良予知状況を可視化・スコア化して、 設備の健全性を一元管理するダッシュボードの展示です。このデモは、 Monitron が検知する設備の不良予兆状態を収集・蓄積し、拠点毎の健全性を評価します。そして保全が必要なタイミングで信号灯を点灯し、チャットアプリに通知して点検作業員を割り当てます。 このブログではこのデモで解決したい課題とユースケース、実現手法を二回に分けて解説します。 Part 1 では、主に開発したソリューションが解決する課題とデモの内容を解説します。 Part 2 ではデモの中で利用している各サービスの役割を解説します。 このブログを読んでいただきたい読者 工場、物流拠点、プラントを操業する企業の方、モーター・ベアリング・ポンプ・ファンなど多くの設備を稼働し、その保守・点検を改善することに課題をお持ちの方、そして、自社製の設備や製品の予知保全に関心を持つ方を想定しています。 本デモのユースケースと背景 本デモの想定するユースケースと背景は、AWS ブログ「 産業設備の予知保全サービス Amazon Monitron の紹介と、多拠点・大規模な設備群における保全効率化への取り組み 」にて説明しておりますので、御覧ください。 開発したデモが目指すもの 今回私達は、前述の大規模運用計画を支援するダッシュボードの概念を実際にデモンストレーションとして実演し、Amazon Monitron の予知保全機能が他のサービスや EAM (Enterprise Asset Management: 設備資産管理) システムと連携し、大規模な工場やプラントなど多拠点の設備保守に後付で予知保全機能を組み込めること、そして現場と全体管理者がコラボレーションして復旧に当たる運用を改善できることを示すことを目指しました。これにより、デモを見たユーザーは Monitron を活用した大規模な設備保全の効果、統合の難易度、運用への影響を理解し、より深く、検討をすすめることができます。 AWS Summit 2024 Japan イベントでは 3 種類のミニチュアファクトリーデモを展示します。そこで、私達はそれらのミニチュアファクトリーが日本の３箇所の離れた地域に存在すると想定して、全拠点の設備に Monitron センサーを配備し、各拠点の設備稼働状況を１つのダッシュボードで可視化・分析するソリューションを作ることにしました。 神奈川県川崎市：プロセス工場 大阪府：検査センター 山形県：組立工場 (図: 日本の 3 拠点に分散した工場を表現) さらに、私達は Amazon Monitron が設備保全タイミングを検知したことを視覚的に表現することで、現場での保全のイメージを具体化したいと考えました。そこで、拠点の健全性スコアが低くなったときに信号灯とチャットツールという２つの通知手段と連携するユーザーストーリーを考えました。 デモの内容 アクター (登場人物) として拠点全体を遠隔地から一元管理する「全体管理者」と各拠点に勤務し拠点の保全業務を行う「保全担当」を定義しました。ユーザーストーリーでは「全体管理者」と「保全担当」がソリューション実装を通じてお互いに情報を連携し、保全業務にあたることをストーリーを想定しました。下の図が、登場人物、設備、サービス全体の役割と行動を示したストーリーボードです。 (図: 多拠点工場群設備保全のストーリーボード)  多拠点・大規模な産業設備群の保全には多数の機器状態の効率的な把握や作業員との連携、 EAM と協調した機器交換計画の管理が必要になる場合があります。例えば、多数ある設備ごとに保全にかけつけるのは非効率的ですので、拠点ごとに現在保全が必要な機器数を知り、保全要員のスケジュールを決定したり、過去の保全履歴から不良の原因を分析し、保全マニュアルを改善したり機器交換のタイミングを計画します。また、予知保全により実際の不全より前に兆候を予知できる場合、保全作業に緊急性はなく、複数の作業をまとめることができます。 設備群管理ダッシュボード 多拠点にある多数の設備群を一元的に管理するためのダッシュボードには Amazon Managed Service for Grafana (AMG) を採用しました。AMG は時系列データをもとにした美しいダッシュボードを簡単・柔軟に提供できます。 過去の状況を確認できるよう、Grafana の GUI で表示期間を変更できるようにしました。 (図: 設備群管理ダッシュボードの画面) (図: ダッシュボードに表示する設備状態の項目) ダッシュボードのレイアウトは大きく 3 つの階層にわけました。管理者は画面の上から順に下に向かって視線を移動することで、より詳細な情報を分析できます。 プロジェクトビュー 上の階層は「プロジェクトビュー」として全拠点の健全性と過去の設備不良原因や対処内容の統計を表示します。左には地図があり、拠点の位置を表示します。中央には全拠点の健全性を表すスコアとスコアの時系列変化を示すグラフを表示します。右側には４つの円グラフがあります。この円グラフはそれぞれ、「拠点の状態の内訳」と、保守員が過去に Monitron アプリを使って報告した「障害モード」「障害の原因」「保守員が実行したアクション」の統計を表示します。スコアはサイトビュー各拠点の状態から計算式に基づいて算出します。スコアが一定値を下回ると、「複数の機器に異常の兆候が見られるため、メンテナンス作業の実施が必要」と判定し、保全要員への通知アクションを発生します。デモでは信号灯を点灯させ、チャットアプリへ保全要請を投稿します。 EAM と統合している場合は、 EAM でチケットを上げることができるでしょう。拠点に緊急の保全を要する設備がある場合はスコアが大きく下がり、より緊急性を要求する通知アクションを発生します。 サイトビュー 2 段目の階層は「サイトビュー」として各拠点の健全性と設備状態の分布を表示します。拠点ごとに 2 つの棒グラフと 1 つの円グラフがあります。 2 つの棒グラフは現在の拠点への保全の必要性を表しています。拠点内で一定数以上の設備で不良の予兆を検知した場合、棒グラフが黄色に変化します。円グラフは拠点内の全設備の状態の割合を表示します。すべてが正常であれば円グラフは緑色になります。 Monitron が設備の不具合予兆を検知していたり、すでに検知した後メンテナンス状態としたものは別の色で表示します。これにより、全体管理者は拠点の設備保全状態を確認できます。 設備ビュー 3 段目の階層は「設備ビュー」として、全拠点の全設備の状態と履歴を表示します。画面には 2 つの表があります。左の表は現在正常でない設備を表示します。例えば「不具合の予兆を検知 (Warning) 」「すぐに保全が必要 (Alarm) 」「メンテナンス中 (Need Maintenance) 」などです。右の表はこれまで発生した設備状態の変化の履歴を表示します。表示期間を変更したり、「拠点名」「設備名」といった表の項目でフィルタリングも可能です。 不具合箇所を特定したら、保守要員は Amazon Monitron アプリを用いてより詳細は設備状態 (振動や温度のグラフ、 Monitron が発生した不具合情報) を確認し現場で保全します。 デモンストレーション：拠点単位の保全推奨タイミングの判定と通知 イベント会場で私達は「検査センターにある複数の設備で不良予兆が検知された」というストーリーに基づいたデモを行います。具体的には以下のステップを再現します。 STEP 1 : はじめはすべての設備が正常状態で稼働しています。 STEP 2 : 検査センターにある複数の設備で “Warning” (不良の予兆を検知) が発生します。これにより、プロジェクトビューのスコアが低下します。その後、信号灯が点灯し、さらにチャットツールに保全を推奨するメッセージが投稿されます。監視者や保全要員はサイトビューや設備ビューを確認し、保全対象設備を特定します。 STEP 3 : 保全要員の担当者が決定すると、その保全要員はチャットアプリにある「私が担当します！」ボタンを押し、チームに保全を開始したことを知らせます。保全要員は Monitron アプリの「確認」ボタンを押します。これにより、ダッシュボードの設備は「NEED MAINTENANCE (保全中)」状態に変化します。 STEP 4 : 保全要員が現場で設備を点検し、適切な対処後に、 Monitron アプリに保全結果のフィードバックを入力し送信します。 フィードバックを受け取った Amazon Monitron は設備が正常な状態になったと解釈して状態を「正常 (Healthy) 」に変更し予知保全を再開します。 ダッシュボードは Monitron からの状態変化に連動してスコアを上げ、サイトビュー、プロジェクトビューの状態を変更するとともに、信号灯を消灯し、チャットアプリへ正常への変化を通知します。 Part 1 のおわりに このブログでは、2 部構成の Part 1として、主に開発したソリューションが解決する課題とデモの内容を解説しました。 このあとに続く Part 2 では開発したデモの中で利用している各サービスの役割を解説します。 より詳しく知るには この記事では、大規模・多拠点の設備を有する産業に向けた、設備群の不良予兆検知ダッシュボードとその実装構成について、 AWS Summit 2024 Japan で展示するデモンストレーションの内容を解説しました。 製造業を始めとする産業での AWS 利用について、実際の事例やリファレンスアーキテクチャを知りたい方は、 AWS の製造業に対する取り組み を御覧ください。 今回のデモで用いた各 AWS サービスの詳細はサービスの紹介ページを御覧ください。 Amazon Monitron (産業設備の不良予知保全) AWS IoT SiteWise (IoT データコレクター及びインタプリタ) Amazon Managed Service for Grafana (運用メトリクス、ログ、トレースのためのスケーラブルで安全なデータ視覚化) AWS IoT Events (イベントを検出し、対応) AWS Chatbot (チームチャットチャンネルから AWS のリソースを関し及び操作) AWS Lambda (イベント発生時にサーバーレスで処理を実行) Amazon Kinesis Data Streams (リアルタイム分析向けストリーミングデータサービス) AWS サービスについてより詳しく学びたい方は、 サービス毎のオンデマンドセミナー を公開しています。 パトライト社製品に関するご質問は、 パトライト社 のサイトからお問い合わせください。 今回のソリューションについて、自社の現場への導入にご興味のある方は、「 AWS に問い合わせする 」からお問い合わせください。 このブログについて このブログの内容は AWS Japan のソリューションアーキテクト 吉川晃平 、安田京太 、梶山 政伸 、三好史隆 、秦将之 、大井友三 が開発し、吉川晃平 が執筆しました。

アセットマネジメント業務において、ポートフォリオマネージャーは、リスクと機会を把握し投資判断を導くために、投資対象企業を綿密に監視する必要があります。決算報告書や信用格下げのような直接的なイベントを追跡することは簡単で、企業名を含むニュースに関する通知を設定することができます。しかし、サプライヤー、顧客、パートナー、あるいは企業のエコシステム内の他のエンティティでのイベントから生じる二次的・三次的な影響を検知することは難しいのが現状です。 例えば、主要ベンダーでサプライチェーンの混乱が発生すると下流の製造業者に悪影響を及ぼす可能性があります。また、主要クライアントで最大の顧客を失うとサプライヤーにとってデマンドリスクになります。このような出来事は、直接影響を受ける企業に注目が集まるほどの大きな出来事ではない場合が多い一方で注意を払う必要はあります。このブログでは、リアルタイムニュースとリレーションシップマップを照合するための、ナレッジグラフと 生成 AI (Generative AI) を組み合わせた自動化ソリューションを示します。 このソリューションには大きく 2 つのステップがあります。第一に、企業 (顧客、サプライヤー、取締役) 間の複雑な関係をナレッジグラフに構築します。第二に、このナレッジグラフと生成 AI を用いてニュースイベントがもたらす二次的・三次的な影響を検知します。このソリューションによって、例えばポートフォリオ内の自動車メーカーでサプライヤーのパーツ遅延が生産ラインへ影響を与える可能性があることを、直接の言及がなくても明らかにする事ができます。 AWS では、このソリューションをサーバーレス、スケーラブル、完全にイベント駆動なアーキテクチャでデプロイできます。このブログでは、グラフによる知識表現と自然言語処理に適した 2 つの主要な AWS サービス ( Amazon Neptune と Amazon Bedrock ) を使用した概念実証システムを紹介します。Amazon Neptune は、高度に接続されたデータセットで動作するアプリケーションを簡単に構築して実行できる、高速で信頼性の高いフルマネージド型のグラフデータベースサービスです。Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon などの主要な AI 企業の高性能な基盤モデル (Foundational Model: FM) を単一の API で提供するフルマネージドサービスで、セキュリティ・プライバシー・責任ある AI に配慮しながら生成 AI アプリケーションを構築するための幅広い機能を備えています。 全体として、このプロトタイプはナレッジグラフと生成 AI によって実現可能な技術、つまりさまざまな要素を結びつけてシグナルを導き出すことができることを示しています。これは、ノイズを避けて重要な情報の進展に常に注目できるという点において専門家にとって重要です。 知識グラフの構築 このソリューションの第一歩はナレッジグラフを構築することです。ナレッジグラフにとって価値があるが、しばしば見過ごされているデータソースが企業の年次報告書です。公式の企業出版物は発行前に精査されるため、その中に含まれる情報は正確で信頼できるものと考えられます。しかし、年次報告書は人間が読むことを想定した非構造化形式で書かれているため、機械で処理するにはふさわしくありません。この潜在力を引き出すには、その中に含まれる豊富な事実と関係性を体系的に抽出し、構造化する方法が必要になります Amazon Bedrock のような生成 AI サービスを使うことで、この処理を自動化できるようになりました。年次報告書を取り込み、小さな単位（チャンク）に分割し、自然言語処理を適用して重要なエンティティとリレーションシップを抽出する処理パイプラインを実行できるようになります。 例えば、「[ 企業 A] は [ 企業 B] から 1,800 台の電気バンを発注し、ヨーロッパでの電気配送車両の拡大を図った」という文章があれば、Amazon Bedrock は以下の情報を特定できます。 [企業 A] が顧客であること [企業 B] が供給者であること [企業 A] と [企業 B] との間がサプライヤー関係にあること 「電動配達バンのサプライヤー」というサプライヤー関係の詳細 非構造化文書から構造化データを抽出するには、企業や人物などのエンティティと、顧客やサプライヤーなどのリレーションシップを、テキストから抽出できるように適切に作成されたプロンプトを大規模な言語モデル (LLM) に対して与える必要があります。プロンプトには、注目すべき点と出力データの構造についての明確な指示が含まれています。この処理を年次報告書全体にわたり繰り返すことで、関連するエンティティとリレーションシップを抽出し、情報が豊富なナレッジグラフを構築できます。 ただし、抽出した情報をナレッジグラフに記録する前にまずエンティティの曖昧さを解決する必要があります。例えば、ナレッジグラフに既に別の「[企業 A]」エンティティがあっても、同名の別の組織を表している可能性があります。Amazon Bedrock では、ビジネスの重点領域・業界・収益を生む業界・他のエンティティとの関係などの属性の推論と比較によって、2 つのエンティティが実際に別物かを判断します。これにより、無関係の企業を 1 つのエンティティとして誤って統合することを防ぎます。 曖昧さの解決が完了すると、Amazon Neptune に格納されているナレッジグラフにエンティティとリレーションシップを追加して、年次報告書から抽出された事実によってナレッジグラフの持つ情報を拡充できます。時間が経つにつれて、信頼性の高いデータの取り込みや信頼性の高いデータソースの統合によって包括的なナレッジグラフが構築され、グラフクエリや分析によって重要な洞察が得られるようになります。 この生成 AI による自動化によって数千もの年次報告書を処理することが可能になり、手作業では非常に多大な労力が必要なために活用されなかったであろうナレッジグラフキュレーションのための非常に貴重な資産を活用できるようになります。 次のスクリーンショットは、 Graph Explorer ツールを使用して Amazon Neptune グラフデータベースで可能なビジュアル探索の例を示しています。 ニュース記事の処理 ソリューションの次のステップは、ポートフォリオマネージャのニュースフィードを自動的に充実させ、彼らの関心や投資に関連する記事を強調することです。ニュースフィードについては、ポートフォリオマネージャは AWS Data Exchange からサードパーティのニュースプロバイダやその他のニュース API を利用することができます。 ニュース記事がシステムに入ると、コンテンツを処理するためのデータ取り込みパイプラインが呼び出されます。年次報告書の処理と同様の手法を使用して、Amazon Bedrock はニュース記事からエンティティ、属性、リレーションシップを抽出します。その後、抽出された情報についてナレッジグラフに対して曖昧さを解決し、ナレッジグラフ内の対応するエンティティを特定します。 ナレッジグラフには企業と人物のリレーションシップが存在するので、記事内のエンティティを既存のノードにリンクさせることでポートフォリオマネージャーが着目している企業が 2 ホップ以内に含まれているかを特定できます。このようなリレーションシップが見つかるということは、記事がポートフォリオマネージャーに関連する可能性があることを意味します。また、基となるデータがナレッジグラフで表現されているため、ポートフォリオマネージャーがこの関連性の理由や仕組みを理解しやすいよう可視化することもできます。さらに、Amazon Bedrock を使えば、参照されているエンティティの感情分析も行えます。 最終的な出力は、ポートフォリオマネージャの関心分野や投資に影響を与えると思われる記事を表示するよう強化されたニュースフィードです。 ソリューション概要 ソリューション全体のアーキテクチャは次の図のようになります。 ワークフローは以下のステップで構成されています。 ユーザーが公式報告書 (PDF 形式) を Amazon Simple Storage Service (Amazon S3) バケットにアップロードします。ナレッジグラフに不正確なデータを含めないために、公式に発行された報告書である事が望ましいです (ニュースや週刊誌とは対照的です)。 S3 イベント通知が AWS Lambda 関数を呼び出し、S3 バケットとファイル名を Amazon Simple Queue Service (Amazon SQS) キューに送信します。First-In-First-Out (FIFO) キューを使用すると、報告書の受信処理が順次行われるため、ナレッジグラフに重複データが含まれる可能性が低くなります。 Amazon EventBridge の時間ベースのイベントが毎分実行され、非同期で AWS Step Functions ステートマシンの実行を開始します。 Step Functions ステートマシンは、一連のタスクを実行してアップロードされた文書から重要な情報を抽出し、ナレッジグラフに挿入します。 Amazon SQS からキューメッセージを受信します。 Amazon S3 から PDF レポートファイルをダウンロードし、複数の小さな文章チャンク (約 1,000 語) に分割し、それらの文章チャンクを Amazon DynamoDB に保存します。 Anthropic の Claude v3 Sonnet on Amazon Bedrock を使用して、最初のいくつかの文章チャンクを処理し、報告書が参照する主なエンティティと関連する属性 (業界など) を特定します。 DynamoDB から文章チャンクを取得し、各チャンクで Lambda 関数を呼び出して、Amazon Bedrock を使用してエンティティ (企業や個人など) とそのエンティティが主なエンティティとの関係 (顧客、サプライヤー、パートナー、競合相手、ディレクターなど) を抽出します。 抽出された全ての情報を統合します。 Amazon Bedrock を使用して、ノイズや無関係なエンティティ (「消費者」などの一般的な用語) を除去します。 Amazon Bedrock を使用して、抽出された情報とナレッジグラフ内の類似エンティティのリストを照合し、推論によって曖昧さを解決します。エンティティが存在しない場合は新規にインサートし、そうでない場合はナレッジグラフ内の既存のエンティティを使用します。抽出された全てのリレーションシップをインサートします。 クリーンアップとして、SQS キューメッセージと S3 ファイルを削除します。 ユーザーは React ベースの Web アプリケーションにアクセスし、エンティティ、感情、接続パスの情報を補足したニュース記事を表示します。 Web アプリケーションを使用して、ユーザーは監視する接続パスのホップ数 (デフォルト N = 2) を指定します。 Web アプリケーションを使用して、ユーザーは追跡するエンティティのリストを指定します。 フィクションのニュースを生成するには、ユーザーは Generate Sample News を選択して、ニュース受信プロセスに送信するランダムなコンテンツを持つ 10 件のサンプル金融ニュース記事を生成します。コンテンツは Amazon Bedrock を使用して生成され、完全に架空のものです。 実際のニュースをダウンロードするには、ユーザーは Download Latest News を選択して、本日のトップニュース (NewsAPI.org で提供) をダウンロードします。 ニュースファイル (TXT 形式) が S3 バケットにアップロードされます。手順 8 と 9 では、ニュースを自動的に S3 バケットにアップロードしますが、お好みのニュースプロバイダー (AWS Data Exchange やサードパーティのニュースプロバイダなど) との統合を構築して、ニュース記事をファイルとして S3 バケットにドロップすることもできます。ニュースデータファイルのコンテンツは <date>{dd mmm yyyy}</date><title>{title}</title><text>{news content}</text> の形式にする必要があります。 S3 イベント通知が S3 バケットまたはファイル名を Amazon SQS (標準) に送信し、複数の Lambda 関数を呼び出してニュースデータを並列で処理します。 Amazon Bedrock を使用して、ニュース内で言及されたエンティティとそれに関連する情報、リレーションシップ、感情を抽出します。 Amazon Neptuneに格納されているナレッジグラフを参照し、Amazon Bedrock を使用して曖昧さを解決します。ニュースとナレッジグラフからの情報を利用して推論し、対応するエンティティを特定します。 エンティティが特定された後、ナレッジグラフ内の INTERESTED = YES とマークされたエンティティへの N = 2 ホップ以内の接続パスを検索し、返します。 Web アプリケーションは 1 秒ごとに自動的に最新の処理済みニュースセットを取得し、Web アプリケーションに表示します。 プロトタイプのデプロイ プロトタイプのソリューションをデプロイして、自分で検証を始めることができます。プロトタイプは GitHub から入手でき、以下の詳細が含まれています。 デプロイの前提条件 デプロイのステップ クリーンアップのステップ 概要 このポストでは、ポートフォリオマネージャーがモニタリングしている企業への直接の言及がされていないニュースイベントによる 2 次リスクや 3 次リスクを検出するための概念実証ソリューションを紹介しました。Amazon Neptune に格納されている複雑な企業関係のナレッジグラフと、Amazon Bedrock を使ったリアルタイムのニュース分析を組み合わせることで、サプライヤーの問題による生産遅延などの影響の連鎖を明らかにすることができます。 このソリューションはプロトタイプにすぎませんが、ナレッジグラフと言語モデルが様々な要素を結びつけてシグナルを導き出す可能性を示しています。これらの技術は、リレーションシップのマッピングと推論により、専門家がリスクをより早く発見することを支援します。全体として、このソリューションは投資分析と意思決定を補助するための検証が必要なものの、グラフデータベースと AI の有望な応用例となっています。 この金融サービスにおける生成 AI の例がビジネスにとって興味深いものであれば、またはそれと同様のアイデアがあれば、AWS アカウントマネージャーにご連絡ください。 本ブログはソリューションアーキテクトの三厨が翻訳しました。原文は こちら 。 著者について Xan Huang はシンガポールを拠点とするAWSのシニアソリューションアーキテクトです。主要な金融機関と協力し、クラウド上で安全で、拡張性が高く、高可用性のソリューションを設計および構築しています。仕事の合間には、ほとんどの自由時間を家族と過ごし、3歳の娘に振り回されています。 Xan の  LinkedIn はこちら。

AWS の Amazon Elastic Kubernetes Service (Amazon EKS) を使用してアプリケーションをモダナイズする際、ユーザーはしばしばスケールに伴う IPv4 アドレス空間の枯渇という深刻な問題に直面します。ユーザーは、運用の複雑さを増やすこと無く、EKS 上の Pod に割り当てられた VPC の CIDR とサブネットをできる限り活用したいと考えています。IPv6 アドレス空間の利用が、スケーラブルなネットワークソリューションを構築するための長期的な解決策になると考えられています。しかし、他のネットワークコンポーネントやアプリケーションの IPv6 サポートの制約から、Amazon EKS ユーザーは IPv4 環境を強いられている可能性もあります。そこで、Amazon EKS ではネットワーク設定を合理化し、運用の複雑さを増やすことなく IPv4 ベースのクラスターをスケーリングできるように、拡張サブネットディスカバリーのサポートを導入しました。 どのように機能するか EKS クラスターの各 Amazon Elastic Compute Cloud (Amazon EC2) ワーカーノードに Amazon VPC Container Network Interface (CNI) プラグイン がデプロイされています。このプラグインは、ワーカーノードに Elastic Network Interface (ENI) を作成して接続するとともに、EKS クラスター内の各 Pod に VPC CIDR からプライベート IPv4、IPv6 アドレスを割り当てます。デフォルトでは、VPC CNI はワーカーノードのプライマリ ENI と同じサブネットから Pod に IP アドレスを割り当てます。これは時々、「利用可能なサブネット」と呼ばれます。追加の設定を行わない場合、ワーカーノードは EC2 インスタンスが起動された「利用可能なサブネット」から ENI を接続できます。VPC CNI の新しい機能により、「利用可能なサブネット」の範囲が拡張されました。拡張サブネットディスカバリーを有効にすると、利用対象としてタグ付けされた VPC 内のすべての提供可能なサブネット/CIDR から Pod の IP アドレスが自動的に割り当てられるようになります。 新しいサブネットを作成して、「kubernetes.io/role/cni」という特定のタグを付与することで、既存のネットワーク設定にシームレスに統合されます。この機能により、継続的な運用の中断を最小限に抑えつつ、アプリケーションを効果的にスケーリングできるようになります。 前提条件 この機能を利用するための前提条件は以下の通りです。 AWS アカウント バージョン 1.25 以降の EKS クラスター (ウォークスルーでは v1.29 を利用) バージョン 1.18.0 以降の Amazon VPC CNI 利用しているデバイスにインストール済みの最新バージョンの AWS Command Line Interface (AWS CLI) 、または AWS CloudShell eksctl – EKS クラスターの作成と管理を簡単に行うことができる CLI ツール (バージョン 0.165.0 以降) セットアップ export AWS_REGION= #Replace with your AWS Region export AWS_ACCOUNT= #Replace with your AWS Account number export CLUSTER_NAME=eks-enhsubsel-demo #Replace with your EKS cluster name このウォークスルーでは、/24 の CIDR ブロック (256 個の IP アドレス) を持つ Amazon VPC を作成し、IP アドレス枯渇のシナリオをシュミレーションします。この VPC は、3 つのパブリックサブネットと 3 つのプライベートサブネットに分かれており、それぞれ /27 の CIDR ブロック (28 個の IP アドレス) が割り当てられています。これは、次の図のような構成になります。VPC の CIDR ブロック内の IP アドレスが枯渇した後、VPC にセカンダリ CIDR を関連付けます。その後、「kubernetes.io/role/cni」タグを付与した VPC サブネットを作成します。これにより、VPC CNI が新しいサブネットを自動的に検出し、 Pod に IP アドレスの割り当てができるようになります。 図 1: Amazon VPC のセットアップ 次に、バージョン 1.18.0 の VPC CNI がインストールされた EKS クラスターを作成します。 cat << EOF > cluster.yaml apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: ${CLUSTER_NAME} region: ${AWS_REGION} version: "1.29" vpc: cidr: 10.0.0.0/24 addons: - name: vpc-cni version: 1.18.0 - name: coredns - name: kube-proxy managedNodeGroups: - name: ${CLUSTER_NAME}-mng instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 5 EOF eksctl create cluster -f cluster.yaml クラスターの作成が完了するのを待ち、vpc-cni アドオンがクラスター内で実行されていることを確認します。 aws eks describe-addon --addon-name vpc-cni --cluster-name $CLUSTER_NAME --region $AWS_REGION { "addon": { "addonName": "vpc-cni", "clusterName": "eks-enhsubsel-demo", "status": "ACTIVE", "addonVersion": "v1.18.0-eksbuild.1", .... } } サブネットには /27 の CIDR が割り当てられているため、プライベートサブネットでは利用可能な IP アドレスがほとんどまたは全くないことに注目します。 aws ec2 describe-subnets --region $AWS_REGION \ --filters Name=tag:Name,Values="eksctl-eks-enhsubsel-demo-cluster/SubnetPrivate*" \ --query "Subnets[].{VPC:VpcId,SubnetId:SubnetId,AvailableIPs:AvailableIpAddressCount}" \ --output table ----------------------------------------------------------------------- | DescribeSubnets | +--------------+----------------------------+-------------------------+ | AvailableIPs | SubnetId | VPC | +--------------+----------------------------+-------------------------+ | 16 | subnet-08411e385d62f29da | vpc-07f75e9b1d954689a | | 7 | subnet-0755097835150b642 | vpc-07f75e9b1d954689a | | 0 | subnet-0975a78066e7e76d6 | vpc-07f75e9b1d954689a | +--------------+----------------------------+-------------------------+ サンプルアプリケーションをデプロイし、EKS クラスター内で IP アドレス枯渇のシナリオをシュミレーションします。 cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata: name: inflate spec: replicas: 50 selector: matchLabels: app: inflate template: metadata: labels: app: inflate spec: terminationGracePeriodSeconds: 0 containers: - name: inflate image: public.ecr.aws/eks-distro/kubernetes/pause:3.7 resources: requests: cpu: 50m EOF サブネット内の IP アドレスが不足しているため、Amazon VPC CNI が IP アドレスを割り当てることができず、多くの Pod が「ContainerCreating」状態であることに注目します。次に、VPC CNI の拡張サブネットディスカバリーの機能を使って、割り当て可能な IP アドレススペースを持つ新しい VPC サブネットを自動検出し、Pod に IP アドレスを割り当てる方法を確認します。 Amazon VPC は最大 5 つのセカンダリ CIDR ブロックをサポートしており、これにより VPC の IP アドレススペースを拡張できます。まず、Amazon EKS を作成した VPC にセカンダリ CIDR ブロック「10.1.0.0/16」を追加します。 export EKS_VPC_ID=$(aws eks describe-cluster --name $CLUSTER_NAME \ --region $AWS_REGION --query "cluster.resourcesVpcConfig.vpcId" --output text) aws ec2 associate-vpc-cidr-block --vpc-id $EKS_VPC_ID \ --cidr-block "10.1.0.0/16" --region $AWS_REGION { "CidrBlockAssociation": { "AssociationId": "vpc-cidr-assoc-06515a22930a5d6e9", "CidrBlock": "10.1.0.0/16", "CidrBlockState": { "State": "associating" } }, "VpcId": "vpc-07f75e9b1d954689a" } セカンダリ CIDR ブロックの関連付けが完了するのを待ってから、セカンダリ CIDR ブロックから新しい VPC サブネットを作成します。また、VPC CNI がこれらのサブネットを自動検出できるように、サブネットに「kubernetes.io/role/cni=1」タグを付与します。 aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"a --cidr-block 10.1.0.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"b --cidr-block 10.1.32.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" aws ec2 create-subnet --vpc-id $EKS_VPC_ID --region $AWS_REGION \ --availability-zone "$AWS_REGION"c --cidr-block 10.1.64.0/19 \ --tag-specifications "ResourceType=subnet,Tags=[{Key=kubernetes.io/role/cni,Value=1}]" デフォルトの設定では、VPC CNI は Amazon EKS ワーカーノードのプライマリ ENI に関連付けられた VPC サブネットから、ENI のプライマリ IP アドレスとセカンダリ IP アドレスの両方を割り当てます。 aws ec2 describe-network-interfaces --region $AWS_REGION \ --query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \ --filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \ --output table -------------------------------------------------------------------------------------- | DescribeNetworkInterfaces | +-------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +-------------------------------------------+-------------------------+--------------+ | ip-10-0-0-155.us-west-2.compute.internal | eni-07f66d0e6b2408fc7 | 10.0.0.155 | +--------------------------------------------+------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.155 || || 10.0.0.136 || || 10.0.0.140 || || 10.0.0.141 || || 10.0.0.145 || || 10.0.0.150 || || 10.0.0.135 || || 10.0.0.151 || || 10.0.0.148 || || 10.0.0.149 || |+-----------------------------------------------------------------------------------+| ......... |+----------------------------------------------------------------------------------+| | DescribeNetworkInterfaces | +--------------------------------------------+-------------------------+-------------+ | DNSName | ID | PrimaryIP | +--------------------------------------------+-------------------------+--------------+ | ip-10-0-0-102.us-west-2.compute.internal | eni-087692b80786865e0 | 10.0.0.102 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.102 || || 10.0.0.105 || || 10.0.0.110 || || 10.0.0.126 || || 10.0.0.124 || || 10.0.0.125 || || 10.0.0.118 || || 10.0.0.100 || || 10.0.0.116 || || 10.0.0.117 || |+-----------------------------------------------------------------------------------+| Amazon VPC CNI アドオンの環境変数「ENABLE_SUBNET_DISCOVERY」を確認して、新しい拡張サブネットディスカバリーの機能が有効になっているか確認します。kubectl を利用してこれを確認します。 kubectl describe ds aws-node -n kube-system | grep ENABLE_SUBNET_DISCOVERY ENABLE_SUBNET_DISCOVERY: true この記事の執筆時点では、拡張サブネットディスカバリーの機能は バージョン 1.18.0 以降のAmazon VPC CNI でデフォルトで有効になっています。環境変数が true に設定されていない場合は、kubectl または AWS CLI を使って設定することができます。 kubectl set env daemonset aws-node -n kube-system ENABLE_SUBNET_DISCOVERY=true \ -c aws-node または、 aws eks update-addon --cluster-name $CLUSTER_NAME --region $AWS_REGION \ --addon-name vpc-cni \ --configuration-values '{"env":{"ENABLE_SUBNET_DISCOVERY":"true"}}' この機能を有効にすると、VPC CNI は「kubernetes.io/role/cni」タグが付与された割り当て可能な IP アドレススペースを持つ VPC サブネットを探します。そして、それらのサブネットから追加の ENI を Amazon EKS ワーカーノードに接続し、Pod に IP アドレスを割り当てられるようにします。ウォークスルーでは、多くの Pod が「ContainerCreating」の状態だったため、VPC CNI は /19 の CIDR である新しいサブネットを自動的に検出し、既存のワーカーノードにそれらを接続しました。次のコマンドでこれを確認します。 kubectl get pods -o wide | grep ContainerCreating <<EMPTY OUTPUT>> ワーカーノードに接続されている ENI を確認すると、セカンダリ CIDR サブネットから追加の ENI が接続されており、Pod に 10.1.x.x の IP アドレス範囲が割り当てられていることがわかります。 aws ec2 describe-network-interfaces --region $AWS_REGION \ --query "NetworkInterfaces[*].{ID:NetworkInterfaceId,DNSName:PrivateDnsName,PrimaryIP:PrivateIpAddress,SecondaryIPs:PrivateIpAddresses[].PrivateIpAddress}" \ --filters Name=tag:cluster.k8s.amazonaws.com/name,Values=$CLUSTER_NAME \ --output table -------------------------------------------------------------------------------------- | DescribeNetworkInterfaces | +-------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +-------------------------------------------+-------------------------+--------------+ | ip-10-0-0-152.us-west-2.compute.internal | eni-0525ae09d044a6688 | 10.0.0.152 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.0.0.152 || || 10.0.0.144 || || 10.0.0.154 || || 10.0.0.147 || || 10.0.0.133 || || 10.0.0.157 || || 10.0.0.153 || || 10.0.0.158 || || 10.0.0.146 || || 10.0.0.132 || |+-----------------------------------------------------------------------------------+| | DescribeNetworkInterfaces | +--------------------------------------------+-------------------------+--------------+ | DNSName | ID | PrimaryIP | +--------------------------------------------+-------------------------+--------------+ | ip-10-1-79-53.us-west-2.compute.internal | eni-0b2632fa77e9fbf68 | 10.1.79.53 | +--------------------------------------------+-------------------------+--------------+ || SecondaryIPs || |+-----------------------------------------------------------------------------------+| || 10.1.79.53 || || 10.1.78.231 || || 10.1.75.23 || || 10.1.81.171 || || 10.1.95.26 || || 10.1.86.60 || || 10.1.76.92 || || 10.1.65.140 || || 10.1.75.174 || || 10.1.94.30 || |+-----------------------------------------------------------------------------------+| クリーンアップ AWS アカウントで継続的に課金が発生するのを避けるため、作成した EKS クラスターのリソースを必ず削除しておきます。 # Delete EKS cluster resources eksctl delete cluster -f cluster.yaml 留意すべき考慮事項 共有サブネット この機能を複数の AWS アカウントに跨るシナリオ (VPC とサブネットを中央の AWS アカウントで作成し、参加者の AWS アカウントと共有して EKS クラスターをデプロイする) 場合、クラウターを起動する参加者の AWS アカウントでサブネットにタグを付与する必要があります。詳しいクォークスルーについては、「 Use shared VPC subnets in Amazon EKS 」を参照してください。 カスタムネットワーキング IP アドレスの枯渇問題への対応として、Amazon VPC CNI の機能であるカスタムネットワーキングを利用することで、セカンダリ VPC の IP アドレス範囲から Pod に IP アドレスを割り当てることができます。VPC CNI でカスタムネットワーキングを有効にすると、セカンダリ VPC CIDR から作成された代替となるサブネット CIDR 範囲を含む ENIConfig というカスタムリソースで定義されたサブネット内に、セカンダリ ENI を作成することができます。VPC CNI は ENIConfig カスタムリソースで定義された CIDR 範囲から Pod に IP アドレスを割り当てます。さらに、Pod はノードのプライマリ ENI とは異なるセキュリティグループを利用できます。そのため、異なるネットワークと異なるセキュリティグループで Pod を実行する必要がある場合、カスタムネットワーキングを検討する価値があります。一方、拡張サブネットディスカバリーは、ENIConfig カスタムリソースの作成を必要としないため、設定のオーバーヘッドが少なく済みます。VPC CNI で両方の機能が有効になっている場合は、カスタムネットワーキングが優先されます。 Pod ネットワーキングのユースケース この機能は、「 Pods の SNAT 」、「 Pods のセキュリティグループ 」、「 Kubernetes ネットワークポリシーのクラスターを構成する 」、「 Amazon EC2 ノードで使用可能な IP アドレスの量を増やす 」といった、他の VPC CNI のユースケースと組み合わせて利用できます。詳細な比較については、「 Pod ネットワークのユースケースの選択 」を参照してください。 まとめ この記事では、Amazon VPC CNI ベースのサブネットディスカバリーの機能が運用オーバーヘッドを抑えながら、EKS クラスターの成長に合わせた IPv4 アドレスの割り当てに対する拡張性と柔軟性をどのように提供できるのか紹介しました。この機能が、どのようにクラスターサイズの変化に適応でき、昨今の IT 環境の動的なニーズをサポートしながらIP アドレスの管理を簡素化するか実演しました。EKS クラスターを安全にスケーリングするための推奨事項と追加の検討事項については、「 Amazon EKS ベストプラクティスガイド 」を参照してください。 Amazon VPC CNI のインストール手順については、 Amazon EKS ユーザーガイド を参照してください。GitHub の AWS Containers Roadmap にコメントするか Issue を作成することで、 Amazon VPC CNI プラグイン へフィードバックを提供できます。 本記事は、 Amazon VPC CNI introduces Enhanced Subnet Discovery (2024 年 4 月 4 日公開) を翻訳したものです。翻訳は、ソリューションアーキテクトの鈴木が担当しました。

はじめに 昨今、生成 AI の進化が目覚ましく、さまざまなコンテンツを生成できるようになってきました。このような生成 AI の活用シーンを、誰でも簡単にアプリケーション化して共有できるようになったのが、AWS の新しいツール「 PartyRock 」です。PartyRock では、自然言語による画面操作だけで生成 AI を組み込んだアプリを作成し、URL を共有するだけで誰とでも利用できます。そして PartyRock は 2024 年 6 月 13 日現在、AWS アカウントやクレジットカード登録が一切不要で、誰でも無料で利用することができます。エンジニアだけでなく、プログラミング未経験の方でも気軽に生成 AI を活用できます。PartyRock のより詳細な説明は 「PartyRock : 誰でも生成系 AI のアプリケーションを作成し共有できるサービス」 からご確認ください。 本記事では、PartyRock のサンプルアプリをご紹介し、誰でも簡単に生成 AI アプリを作成できることをお伝えします。アプリ紹介の中では、アプリを作った AWS Japan メンバーへのインタビューも掲載しています！PartyRock で作成したアプリは URL を用いて共有することができ、本記事で紹介するサンプルアプリも後述の URL から簡単に試すことができます。楽しく直感的に生成 AI アプリを作ることができる PartyRock をぜひ試してみてください！ AWS Summit Japan PartyRock ブースの紹介 日本最大の “AWS を学ぶイベント” AWS Summit Japan が 2024年 6月 20 日 (木)、21 日 (金) の二日間に渡り幕張メッセで開催されます。クラウドコンピューティングコミュニティが一堂に会して、アマゾン ウェブ サービス (AWS) に関して学習し、ベストプラクティスの共有や情報交換ができる、クラウドでイノベーションを起こすことに興味がある全ての皆様のためのイベントです。基調講演・150 を超えるセッション、250 を超える EXPO コンテンツがあり、その中には PartyRock のブースもあります。AWS アカウント不要の生成 AI プレイグラウンド PartyRock を体験しませんか？専門知識がなくても大丈夫！あなたのアイディアをその場でアプリ化してみましょう！ 場所：AWS Village・生成 AI コーナー ブース名：あなたのアイディアをその場でアプリ化！生成 AI プレイグラウンド PartyRock AWS Summit Japan は下記からご登録できます。PartyRock のブース以外にも数多くのブース・セッションがあります。皆様のご登録・ご来場をお待ちしています！ https://aws.amazon.com/jp/summits/japan/ サンプルアプリ ビデオ書き起こし要約アプリ 作成者：Shintaro Okamoto ソリューションアーキテクト アプリ説明 このアプリでは、ビデオの書き起こし文を入力すると、要約文の自動生成および内容に関する質問回答を行なってくれます。PartyRock を用いるとこのような実用的なアプリも簡単に素早く作成することができます。 このアプリは「Video Transcript」「Video Summary」「Ask About Video」の 3 つのウィジェットから構成されています。「Video Transcript」にビデオの書き起こし文をアップロードすると、「Video Summary」にビデオの内容の要約が生成されます。もしビデオの内容について何かわからないことがある場合は、「Ask About Video」で生成 AI にビデオの内容を聞くこともできます。 「Ask About Video」で会話できる生成 AI は「Video Transcript」と「Video Summary」の内容を知った上で会話してくれるのがポイントです。「Ask About Video」の右上の設定アイコンからプロンプト (生成 AI に与えられる入力) を見てみると、「Video Transcript」と「Video Summary」を参照しているのがわかります。 PartyRock ではどのようなアプリを作りたいかをテキストで入力するだけでアプリが作成されますが、作成された後に編集を行うこともできます。ウィジェットの出力が英語でされてしまう場合は、このプロンプトの最後のように「日本語で出力して」と付け足すだけで、日本語で出力してくれるようになることがあります。 書き起こし文ファイルのアップロードは 2024 年 5 月に追加された Document ウィジェットで行っています。Document ウィジェットを用いると、PDF や DOCX などの一般的なファイルやドキュメントのテキストコンテンツを PartyRock アプリに直接統合することができます。以前までの PartyRock では、このようなユースケースではファイルからテキストを手作業で抽出する必要がありましたが、Document ウィジェットの活用により、より効率的に作業を行うことができるようになりました。今回は書き起こし文としてテキストファイルをアップロードしています。 作成者へのインタビュー 著者 > Okamotoさん、普段は AWS でどんな仕事をされているんですか？ Okamoto > AWS を利用している・これから利用されるお客様に対し技術支援を行っています。 著者 > PartyRock を使ってみた感想を教えてください。 Okamoto > 生成 AI といえばチャットボットを思い浮かべる方が多いと思いますが、実際にはチャット以外の多様なユースケースに活用できる技術です。PartyRock は様々なデータ処理に生成 AI を利用できることをすぐに実感できるプレイグラウンドだと感じました。特に、IT の知識不要ですぐにアイディアを形にできるところが優れていると思います。 著者 > 確かにチャット以外の活用例を見られるのは参考になりますね。普段開発される際と比べると PartyRock はどうでしょうか? Okamoto > 私は普段お客様とお話する際に、お客様が取り組みたい生成 AI 活用テーマをその場でデモすることがしばしばあります。PartyRock は事前準備なしで、ご要望に合わせて様々なデモをその場で行いながら、お客様のイメージを形にしていくツールとして使い勝手がよいものだと考えています。 著者 > なるほど、目に見えるものがその場ですぐにできるのは非常に便利ですね。ありがとうございました！ PartyRock は自然言語で作りたいアプリケーションアイデアを入力するだけで、 ビデオ書き起こし要約アプリ のような実用的なツールを簡単に素早く作成することが可能です。 Document ウィジェットが利用できるようになり、ますます PartyRock を活用できる幅が広がっています。 生成 AI モデル 比べるくん 作成者：Ritaro Kasai 営業担当 アプリ説明 このアプリでは、Amazon Bedrock で使える複数の生成 AI モデルの出力を見比べることができます。PartyRock を使うと手軽に Amazon Bedrock のモデルを試すことができます。 上記のスクリーンショットには 4 つのウィジェットが写っており、左上のウィジェットにアプリ説明、左下に生成 AI への入力、右側の 2 つに生成 AI の出力が表示されています。実際のアプリではもっと多くの生成 AI モデルの出力を見ることができます。 左下の「入力欄：生成 AI への質問を入れてみよう」に生成 AI に与えたいプロンプトを入れると、その内容に対する生成 AI の回答が右側出力用ウィジェットに表示されます。右側のそれぞれのウィジェットにはそれぞれ異なる生成 AI モデルが設定されています。例えば「Claude 3 Sonnet モデルによる出力」の設定を見てみると、 Claude 3  Sonnet がモデルとして指定されていることがわかります。 プロンプトを見てみると、ユーザーの入力がそのまま右側のウィジェットに渡されるという構成になっていることも確認できます。 作成者へのインタビュー 著者 > Kasai さん、普段は AWS でどんな仕事をされているんですか? Kasai > 私は「手触り感」のある生成 AI の可能性をお客様に説いて回る仕事をしています。人材不足と高齢化が差し迫る日本で、おもてなし感のある温かいサービスを 10 年後も維持するには、生成 AI が機械とヒトとの接点を担う部分が激増すると信じているんです。しかし、どこまで使えるのか具体的に考え抜けている人がマーケットには少ないので、その伝道師活動が日本のための使命だと感じています。 著者 > なるほど、生成 AI の実用化に向けて大切な役割を担われているんですね。どうして比べるくんをお作りになられたのですか？ Kasai > 生成 AI モデルが数多くあるよと言われても、その違いがわかりにくかったからです。だから同じお題に対して、違うモデルが一気に回答する「比べるくん」を作ってみました。すると Claude 3 最軽量モデルの Claude 3 Haiku がより高精度なモデルの Claude 3 Sonnet よりも本当に 返答が早いことや、難しい文脈を扱わないものなら十分だな、とか直感的に見えてきて、私も勉強になりました。 著者 > PartyRock の魅力はなんでしょうか? Kasai > AI や IT のエンジニアではない私でもの人でも作れるアプリ！自由度と簡単さのバランスが良かったです。直感的に、プログラミング不要で、PC でもスマホでもアプリが作れたことに感動しました。「ちょっとしたアイデア」があるときに考えるより先に作って、周りの人の感想を聞いてから具体的に考えられる。そんなパラダイム・チェンジが起こせる存在だと思いました。 著者 > 確かに、アイデアを形にしてからブラッシュアップできるのは大きなメリットですね。ありがとうございました！ PartyRock は AI や IT の専門知識をお持ちでない方にとっても、自然言語で作りたいアプリケーションアイデアを入力するだけで、このように形にしやすい点はお客様から評価いただけるポイントです。また、PartyRock では複数の基盤モデルを使用でき、用途に合わせて最適なモデルを選べることが評価される点です。 生成 AI モデル 比べるくん のようなモデルの違いを可視化できるようなアプリケーションを、生成 AI の検討段階に使ってみてはいかがでしょうか。 気分に合わせて格言をお届けします 作成者：Yuri Kinoshita 営業担当 アプリ説明 このアプリでは、今の気持ちを入力するとそれに合わせた格言を生成 AI が考えてくれます。自分では思ってもみなかった視点を生成 AI が与えてくれるかもしれません。PartyRock ではこのように人生を豊かにしてくれるようなちょっとしたツールが簡単に作れます。 「今日のあなたに贈る格言！」に今日の気分を入力すると、その内容に合わせた格言と画像が「どうなるかな…」と「イメージ」にそれぞれ表示されます。 「イメージ」のプロンプトを見ると、「今日のあなたに贈る格言！」の内容から画像を生成していることがわかります。 PartyRock では、このように Image Generation ウィジェットを用いることで画像生成を行うこともできます。 「どうなるかな…」のプロンプトを見てみると、実際の格言の例がプロンプトに入っていることがわかります。 （中略） このようなカスタマイズを試すことにより思い通りの出力に近づけられることもあります。プロンプトをカスタマイズしたい場合には、 Amazon Bedrock  の プロンプトエンジニアリングガイドライン をご参照ください。PartyRock で使われている生成 AI モデルは Amazon Bedrock により提供されています。 作成者へのインタビュー 著者 > Kinoshita さん、普段は AWS でどんな仕事をされているんですか？ Kinoshita > 私は首都圏を中心としたお客様に対して AWS の導入・活用支援を行っております。 著者 > このアプリを思いついたきっかけを教えてください。 Kinoshita > 実際に生成 AI に触ってもらう際に誰でもわかりやすいアウトプットは何だろうと考えた時、占い的な要素があるととっつきやすいのではと思ったんです。普段お客様と会話する際に生成 AI を活用したいが自社にはまだ早すぎる、と仰る方々も多いので、まずは気兼ねなく触ってもらえる遊びの要素を取り入れたアプリを作りました。実際自分たちならどう活用できるかな? とアイデアにつなげる第一歩として使ってもらえると嬉しいです！ 著者 > なるほど、生成 AI に親しんでもらうきっかけ作りですね。PartyRock を使ってみてどうでしたか？ Kinoshita > エンジニア経験はない私が、10 分ほどでアプリを作れたので簡単さに感動しました！サンプルとして、実際の格言データをいくつか入れているのですが、自社のデータに置き換えてまずは試してみる、がすぐにできるのが PartyRock の醍醐味だと感じました。 著者 > 確かに、無料で気軽にアレンジを試せるのが魅力ですよね。ありがとうございました！ PartyRock は遊びの要素も持ち合わせることから、誰でも生成 AI を気軽に体験できるツールとして利用でき、生成 AI に親しむきっかけになりそうです。 各アプリのタイトルをクリックすると、アプリをご自身でお試しいただけます。 気分に合わせて格言をお届けします のような簡単に遊べるツールを体験して Party に参加してみませんか。PartyRock の Remix 機能を使って既存のアプリをカスタマイズしたり、独自に作成したりすることも可能です。 まとめ PartyRock を使えば、機械学習やプログラミングの経験がなくても生成 AI を搭載したアプリを手軽に作ることができます。 サンプルアプリと作成者の生の声から、 PartyRock で生成 AI の幅広い活用方法を見つけられる可能性を感じていただけましたでしょうか。生成 AI に興味がある方は、ぜひ PartyRock で気軽にアプリ作りに挑戦してみてください。 本ブログは、ソリューションアーキテクトの石岡とプロフェッショナルサービスの若田が執筆し、ソリューションアーキテクトの松本が監修しました。 著者について 若田佳菜子 (Kanako Wakata) アマゾンウェブサービスジャパン合同会社 プロフェッショナルサービスコンサルタント 2024 年 4 月入社のプロフェッショナルサービスコンサルタントです。 趣味は旅行とスノーボード、最近はフィルムカメラとアコースティックギターにはまっています。 石岡陸 (Riku Ishioka) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2024 年 4 月入社のソリューションアーキテクトです。 ゲームと開発が趣味です。 松本 敢大 (Kanta Matsumoto) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 普段は小売業のお客様を中心に技術支援を行っています。 好きな AWS サービスは AWS IoT Core。趣味はカメラで、犬が好きです。

本稿は、JFE エンジニアリング株式会社による生成 AI を活用した業務効率化の取り組みについて、プラットフォーム開発をリードされた 上野 晶鋭 様、 武内 数馬 様より寄稿いただきました。 イントロダクション JFE エンジニアリング株式会社 (以降、当社） は、エネルギー、環境、社会インフラ、産業機械など幅広い分野でプラントや構造物のEPC（設計・調達・建設）、製造、運営事業を展開しています 。また、 AI や IoT を活用したプラント運営の最適化、デジタルツイン技術によるプロセス可視化、データ解析プラットフォーム Pla’cello® や遠隔監視システム GRC の運営など、多岐にわたるデジタルトランスフォーメーションを実行しています。 今回はそれらの取り組みの中で、生成 AI を活用したプラットフォーム「 Pla’cello xChat 」 (以下 xChat) を開発し、建設業における見積りなどの業務を効率化した事例をご紹介します。ブログの中では、プロジェクトの背景、開発体制、 AWS の活用方法についても解説します。 導入経緯 当社では生成 AIでどのようなビジネス価値を創出できるのかを検証するために、 2023 年 5 月より生成 AI 活用のプラットフォームを開発するプロジェクトを開始し、同年 9 月に生成 AI プラットフォーム「 Pla’cello xChat 」をリリースしました。独自のセキュリティ対策と利用ガイドラインを整備し情報漏洩リスクを最小限に抑えた安全な利用環境を提供しており、現在弊社内で 1,000 名以上がこのサービスを利用しています。そして、さらなる利便性向上のために、同年 11 月に事業部メンバーを対象として実際の業務に役立つユースケースを議論するイベントを開催し、そこで集まった 10 件の有望なユースケースについて 3 ヶ月間で PoC を実施し効果検証を行いました。効果のあったユースケースについては、アプリケーションとして xChat への組み込みを進めています。 開発体制・開発フロー方針 生成 AI 活用による成果を素早くかつ確実に挙げるために、適切な分業を行う開発体制・開発フロー・アーキテクチャを整えました。 具体的には、プラットフォームとしての xChat の開発は AWS に詳しい「プラットフォーム開発チーム」が担当し、xChat を使用した生成 AI 活用のユースケースの効果検証は生成 AI に詳しい「データサイエンスチーム」と業務知見を持つ「事業部メンバー」が実施できる体制を作りました。 xChat には PoC を実施するための API を用意しているため、データサイエンスチームと事業部メンバーはすぐにユースケースの効果検証を始めることができます。また、 API を使用することで PoC ごとにプラットフォーム開発チームが xChat の UI などを追加開発する必要がないため、最低限の実装コストで効果検証が行えるようになっています。そして、効果のあるユースケースについては事業部メンバーが実業務で使いやすい形になるように、プラットフォーム開発チームが UI を実装して提供します。以上のような開発フローにより効率良くかつ確実に生成 AI 活用の成果を挙げることが可能となり、利用ユーザーの幅も広がっています。 図 1 開発フロー図 ソリューションの概要 生成 AI による業務効率化を実現するために、xChat において 以下 3 つのコンポーネントを開発しています。 1 つ目は API です。PoC は業務知見をもつ事業部メンバーと生成 AI の知見を持った社内のデータサイエンスチームが共同で実施します。その際、効果検証をすぐに開始できるよう、プラットフォーム開発チームはAPI を公開しました。 2 つ目はユーザーインタフェース (UI) です。PoC の結果、効果があると判断されたユースケースを簡単かつ便利に利用できるようにするために、UI を開発して提供しています。 3 つ目は社内データ検索の仕組みです。実業務に役立つ情報を生成 AI で出力するためには、業務に関連する「社内文書」、「過去のプロジェクトデータ」、「技術資料」などの社内データ参照が不可欠です。これらのデータを検索して生成 AI に読み込ませることで、生成 AI が持つ知識を補い、回答の質や精度の向上が期待できます。当社では Retrieval-Augmented Generation (RAG) の技術を利用して、社内データを検索する仕組みを構築しています。しかし、セキュリティの観点から部署間で検索できるデータ範囲を制限する必要があります。当社では Amazon OpenSearch Service へのクエリ発行時にフィルタを利用することで、部署ごとに検索できるデータの分離を実現しました。 上記 3 つのコンポーネントを表したものが「システムアーキテクチャ図」です。また、「 AWS アーキテクチャ図」のとおり、生成 AI サービスには Amazon Bedrock を採用し、 AWS Lambda をはじめとしたフルサーバレス構成を採用しています。 図 2 システムアーキテクチャ図 図 3 AWS アーキテクチャ図 具体的な成果事例 PoC を経て実装されたユースケースの具体例として見積書からのデータ抽出があります。これまで見積書を比較検討する際、各取引業者で違ったフォーマットの見積書から手作業でデータを抽出する必要がありました。ある事業部ではこの作業に年間 5,000 時間もかかっていると言われており、過去には OCR でのデータ抽出自動化を試みましたが、フォーマットが異なるため抽出したデータの比較が難しく業務効率化を実現できませんでした。本課題を解決するために、OCR の文字読取り機能と生成 AI の文章補正を組み合わせ、より精度の高い見積書からのデータ抽出を実現しました。実業務では各社の見積書を xChat にアップロードするだけで、データ抽出と統一フォーマットでの出力を生成 AI が行ってくれるため、事業部メンバーは効率的に見積りの比較が行えます。実際に事業部ユーザーに使用していただいたところ、見積り比較業務を数十 ％ 削減できるとのフィードバックを得ることができました。 まとめと今後の展望 当社は建設業における業務効率化に生成 AI を活用して取り組んでいます。これまでは、素早くかつ確実に生成 AI 活用の成果を挙げるために開発体制・フロー・アーキテクチャを整備し、AWS 上で生成 AI のアプリケーションを構成することで、ビジネス上の効果を得ることができました。今後は xChat を活用して更なるユースケースの拡大や横展開を継続していきます。また、RAG を用いた社内データ連携の強化やマルチモーダルなデータの取り込み、 Agents for Amazon Bedrock などを活用し、事業部メンバーがより便利に xChat を利用できるよう、更なるプラットフォームの機能拡張も継続していきます。 執筆者 上野晶鋭 JFE エンジニアリング株式会社 DX 本部 ICT センター データプラットフォーム開発部 Pla’cello 開発室 主幹 大学卒業後、通信業界、小売業界、製薬業界のサービス・システム開発リーダー、システムアーキテクトとして従事後、2022 年に JFE エンジニアリングに入社。入社後はデータ解析プラットフォーム （Pla’cello®） の開発を担当し、現在は生成AI活用基盤 （Pla’cello xChat） の開発・活用を推進。 武内数馬 JFE エンジニアリング株式会社 DX 本部 ICT センター データプラットフォーム開発部 Pla’cello 開発室 主任 情報通信企業、AI ベンチャーを経て 2021 年に JFE エンジニアリングに入社。ソフトウェアエンジニアとして、データ解析プラットフォーム （Pla’cello®） におけるローコード ETL ツール、生成 AI 活用基盤 （Pla’cello xChat） の開発を担当。好きな AI は「月は無慈悲な夜の女王」のマイク。

世界の核融合エネルギー（フージョンエネルギー）研究を支える核融合科学研究所では大型ヘリカル装置(LHD)の実験データを大規模に保有しており、今回AWSの基盤にてオープンデータとして公開した 核融合科学研究所は、大型ヘリカル装置(LHD)の実験データの25年分 約2PB（ペタバイト）をオープンデータとしてアマゾン ウェブ サービス（以下、AWS）の クラウド上で公開しました。学術研究基盤LHDは、核融合科学研究所が、25年にわたって世界最大級の超伝導プラズマ閉じ込め装置として実験研究しているものです。学術研究基盤LHDでは、超高温プラズマを安定に生成し、多様な高精細計測装置を用いてプラズマの内部構造を計測することによって、核融合に限らず宇宙、天体プラズマにも共通する様々な複雑現象の原理に迫り、超高温、極低温、放射線などの極限環境における材料科学などの分野においても革新的な進歩が期待できます。またグリーンイノベーションとして、太陽と同じ核融合を地上でエネルギー源として利用する核融合発電の実現に必要な要素の一つである超高性能プラズマの定常保持の実証を行っています。日本政府の科学技術・イノベーション戦略でも、新たなムーンショット型研究開発制度が始まっており、核融合エネルギー（フュージョンエネルギー）もその目標の中にあります。 核融合科学研究所では、学術研究基盤LHDを国内外の共同研究者に利便性高く利用可能としており、標準化されたデータの公開を進めていました。25年にわたるデータアーカイブがありかつ大規模データであるため、公開用のストレージとデータ提供基盤、データ転送に関わるネットワークに課題がありました。オープンデータとして公開するデータは約2PBにもなり、この規模のストレージを長期的に維持していくことが必要です。保守期限を迎えるとその入れ替えに手間や時間がかかることが想定されており、データを利用するユーザーとしては大容量のデータとなるため転送にも時間がかかりすぐに解析等処理ができないことが課題となっていました。また今後LHDのデータ利用が進み大量のデータのダウンロード行われていくと研究所の対外接続用ネットワークの帯域が占有されてしまう可能性があり通常業務への影響も懸念されていました。これらの理由などから、核融合科学研究所ではオープンデータを安定的に提供する基盤を探していました。 AWSオープンデータスポンサーシッププログラム には、数百以上のデータセットが集められ、AWS アカウントの有無にかかわらず、これらのオープンデータを誰でも検索して見つけることができ、誰でもが利用することが可能です。クラウドでの利用に向いた高価値データセットのストレージコストを AWS が負担することによってコミュニティの研究や開発の加速に寄与するオープンデータスポンサーシッププログラム をデータプロバイダーと協力して実施しています。 このたび核融合科学研究所は、AWSオープンデータスポンサーシッププログラムを利用し、学術研究基盤LHD の25年分にわたる実験データをオープンデータとして公開しました。データは AWS のオープンデータプログラム上で提供されるため、先に触れましたように、AWS アカウントの有無にかかわらず利用可能です。核融合科学研所がAWSを採用した理由は、スケーラビリティや耐久性の高さからAmazon Simple Storage Service (Amazon S3)へのデータ格納に価値を見出していた結果です。また、AWS 上で解析をする場合には、利用者にとってデータ転送にかかる手間を減らしてクラウド上ですぐにデータを解析できる環境を提供することができるようになります。AWS の基盤からのデータの配信となるため、核融合科学研究所のネットワークへの負荷も無く、研究所内のシステムと切り離した形でデータ提供も実現できました。 AWS 上へのデータ移行に関しては、AWS が SINET6 向けに SINET クラウド接続サービス内で提供している回線を利用し、平均 10Gbps 以上の伝送速度で核融合科学研究所から AWS 上へ伝送が行われ、データ伝送が比較的短期間で実施できたことも核融合科学研究所から評価いただけました。 今後 AWS 上で今回のデータを使って解析をする簡単な手順や、ワークショップなどを核融合研究所で実施されていく予定となっております。 アマゾン ウェブ サービス ジャパン合同会社 執行役員 パブリックセクター 統括本部長 宇佐見 潮は、次のように述べています。「核融合科学研究所様との連携により、フージョンエネルギーの活用に弊社が貢献できること、大変嬉しく思います。国内の学術研究分野にとどまらず、全世界の産業界からこの オープンデータが活用され、様々な科学分野において技術革新が進むことを期待します。」 詳細について、核融合科学研究所のプレスリリースをご覧ください。 https://www.nifs.ac.jp/news/collabo/240614.html 大学共同利用機関法人 自然科学研究機構 核融合科学研究所(NIFS)について 核融合科学研究所(NIFS: National Institute for Fusion Science)は、大学共同利用機関法人自然科学研究機構を構成する研究所の1つであり、1989年に核融合科学分野における国立の研究所として設置されました。大学共同利用機関として国内外の研究機関から研究施設の共同利用が行われています。総合研究大学院大学をはじめとして大学院の学生に対する教育も実施しています。日本政府の科学技術・イノベーション戦略でも、新たなムーンショット型研究開発制度が始まっており、フュージョンエネルギーもその目標の中にあります。詳細については以下の URL をご覧ください。 https://www.nifs.ac.jp/ 大型ヘリカル装置(LHD)について 大型ヘリカル装置(LHD:Large Helical Device)は核融合科学研究所により、25年にわたって世界最大級の超伝導プラズマ閉じ込め装置として実験研究されています。LHDでは、超高温プラズマを安定に生成し、多様な高精細計測装置を用いてプラズマの内部構造を計測することによって、核融合に限らず宇宙、天体プラズマにも共通する様々な複雑現象の原理に迫り、超高温、極低温、放射線などの極限環境における材料科学などの分野においても革新的な進歩が期待できます。この規模の実験装置は世界的にも簡単には製作できず実験も大がかりなものとなるため、実験によって計測されたデータは様々な研究機関や企業にとって貴重な研究材料となります。現在も実験が行われていますが、これまでも25年にわたって様々なデータをとり続け、現在約2PBもの大規模データとなっています。

本稿は、2021 年 12 月 2 日に AWS Developer Tools Blog で公開された “ Increasing development speed with CDK Watch ” を翻訳したものです。 AWS Cloud Development Kit (CDK) の CLI に導入されている操作モード cdk watch 、および cdk deploy のフラグ --hotswap と --no-rollback を紹介します。 cdk watch はコードとアセットの変更を監視し、ファイル変更が検出されるたびに最適な形式のデプロイを自動的に実行することで、開発を効率化できます。これにより、CDK アプリケーションに変更を加えるたびに cdk deploy を実行する必要がなくなります。 cdk watch では --hotswap フラグが使用できる変更の場合は使用され、 AWS CloudFormation でのフルデプロイを行わずにインプレースで更新されます。 AWS Lambda ハンドラーコード、 Amazon ECS コンテナイメージ、 AWS Step Functions ステートマシンなどの CDK アセットでは、CDK CLI が各 AWS サービスの API を使用して直接更新します。それ以外のアセットでは、CloudFormation のフルデプロイが実行されます。また、 --no-rollback フラグを使用することで CloudFormation の更新失敗時にロールバックが行われないようになるため、デプロイ失敗時に再実行するまでの時間を短縮できます。 以下の手順を実行することで、 cdk watch および --hotswap 、 --no-rollback フラグの動きを確認できます。この記事では TypeScript で CDK を使用しますが、 watch は CDK でサポートされているすべての言語で機能します。最初に空の CDK アプリケーションを作成し、TypeScript と Express を使用したシンプルなコンテナアプリケーションを追加します。次に、アプリケーションをデプロイするために必要なインフラストラクチャを作成する CDK スタックを記述します。最後に、 cdk watch を使用してアプリケーションコードに繰り返し変更を加えていきます。 前提条件 AWS アカウントを持っていること ローカルに CDK がインストールされていること セットアップ CDK CLI V2 がインストールされていることを確認してください ( cdk watch は V1 でも動作しますが、この記事ではすべて V2 を使用しています)。まだインストールしていない場合は、 AWS CDK 開発者ガイド の手順を参照してインストールしてください。インストールが正しく行われたことを確認するには、ターミナルで cdk --version コマンドを実行します。次のように出力されれば問題ありません。 ※ 本ブログ記事では、CDK CLI バージョン 2.141.0 で動作確認しています。他のバージョンでは挙動が異なる可能性があるので、ご注意ください。 cdk --version 2.X.X (build XXXXXXX) 最初に、ターミナルで次のコマンドを実行し、TypeScript の CDK アプリケーションを作成します。 mkdir cdk-watch cd cdk-watch cdk init --language=typescript アプリケーションコード cdk-watch ディレクトリ上で、Docker イメージをビルドするために必要なディレクトリとファイルを作成します。 mkdir docker-app 次に、アプリケーションの依存関係を宣言する package.json を作成する必要があります。記載する必要がある依存関係は Express のみです。TypeScript はアプリケーションデプロイ前に JavaScript にコンパイルされるため、依存関係として宣言する必要はありません。 docker-app/package.json のファイルを作成し、次の内容を追加してください。 { "name": "simple-webpage", "version": "1.0.0", "description": "Demo web app running on Amazon ECS", "license": "MIT-0", "dependencies": { "express": "^4.17.1" }, "devDependencies": { "@types/express": "^4.17.13" } } 次に、ウェブページとして表示させるための HTML ファイルを作成する必要があります。 docker-app/index.html のファイルを作成し、次の内容を追加してください。 <!DOCTYPE html> <html lang="en" dir="ltr"> <head> <meta charset="utf-8"> <title>Simple Webpage </title> </head> <body> <div align="center"> <h2>Hello World</h2> <hr width="25%"> </div> </body> </html> 作成した HTML ファイルが、サイトにアクセスした際に表示されるようにするための Express コードを作成します。 docker-app/webpage.ts のファイルを作成し、次のコードを追加してください。 import * as express from 'express'; const app = express(); app.get("/", (req, res) => { res.sendFile(__dirname + "/index.html"); }); app.listen(80, function () { console.log("server started on port 80"); }); 最後に、アプリケーションを起動する Dockerfile を作成します。 docker-app/Dockerfile のファイルを作成し、次のコードを追加してください。 FROM node:alpine RUN mkdir -p /usr/src/www WORKDIR /usr/src/www COPY . . RUN npm install --production-only CMD ["node", "webpage.js"] インフラストラクチャコード 次に、Web ページをホストするインフラストラクチャを定義する CDK スタックを作成します。 aws_ecs_patterns モジュールの ApplicationLoadBalancedFargateService コンストラクトを使用することで、スタックを大幅に単純化できます。 lib/cdk-watch-stack.ts を次の例のように修正してください。 import { Stack, StackProps, aws_ec2 as ec2, aws_ecs as ecs, aws_ecs_patterns as ecs_patterns, } from 'aws-cdk-lib'; import { Construct } from 'constructs'; export class CdkWatchStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 2, natGateways: 1, }); new ecs_patterns.ApplicationLoadBalancedFargateService(this, 'EcsService', { vpc, taskImageOptions: { image: ecs.ContainerImage.fromAsset('docker-app'), containerPort: 80, }, }); } } cdk.json の build キーで指定されたコマンドは、 cdk watch 実行時を含むすべてのデプロイ時に、synthesis ステップの前に実行されます。今回作成した TypeScript アプリケーションは JavaScript にコンパイルする必要があるので、 cdk.json の "app" キーと同じ階層に以下のコードを追加してください。 "build": "cd docker-app && npm install && tsc", これにより、完全にサーバーレスな Docker アプリケーションが作成されます。これらの変更を行ったら、次のコマンドを実行してください。 yarn install # お好みで "npm install" をお使いください cdk deploy デプロイが完了すると、以下のように出力されるはずです。 Bash ✅ CdkWatchStack Outputs: CdkWatchStack.EcsServiceLoadBalancerDNS6D595ACE = CdkWa-EcsSe-18QPSCKV5G8XP-xxxxxxxxxx.us-east-2.elb.amazonaws.com CdkWatchStack.EcsServiceServiceURLE56F060F = http://CdkWa-EcsSe-18QPSCKV5G8XP-xxxxxxxxxx.us-east-2.elb.amazonaws.com Stack ARN: arn:aws:cloudformation:us-east-2:xxxxxxxxxxxx:stack/CdkWatchStack/1b15db20-428a-11ec-b96f-xxxxxxxxxxxx Outputs セクションの 2 行目に記載されているリンクを開いてください。「Hello World」と書かれたページが表示されるはずです。 アプリケーションコードの変更 アプリケーションをデプロイしたら、 cdk watch を使用して変更を加えていくことができます。ターミナルで cdk watch を実行すると、以下のような出力が表示されます。 'watch' is observing directory '' for changes 'watch' is observing the file 'cdk.context.json' for changes 'watch' is observing directory 'bin' for changes 'watch' is observing directory 'docker-app' for changes 'watch' is observing directory 'lib' for changes 'watch' is observing the file 'bin/cdk-watch.ts' for changes 'watch' is observing the file 'lib/cdk-watch-stack.ts' for changes 'watch' is observing the file 'docker-app/Dockerfile' for changes 'watch' is observing the file 'docker-app/index.html' for changes 'watch' is observing the file 'docker-app/package.json' for changes 'watch' is observing the file 'docker-app/webpage.ts' for changes アプリケーションコードを変更する場合、 cdk watch を使用することでデプロイを高速化できます。以下の変更を index.html に加え、動作を確認してみましょう。 <!DOCTYPE html> <html lang="en" dir="ltr"> <head> <meta charset="utf-8"> <title> Simple Webpage </title> </head> <body> <div align="center"> <h2>Hello World</h2> <hr width="25%"> <p>A paragraph</p> </div> </body> </html> ターミナルを見ると、 cdk watch が変更を検知してデプロイする様子が確認できます。 Detected change to 'docker-app/index.html' (type: change). Triggering 'cdk deploy' ⚠ The --hotswap flag deliberately introduces CloudFormation drift to speed up deployments ⚠ It should only be used for development - never use it for your production Stacks! この警告メッセージは、今回の変更がホットスワップでデプロイされることを意味しています。つまり、このデプロイは更新対象のリソースが提供しているサービス API を直接実行することで行われ、CloudFormation がバイパスされます。このため、CloudFormation テンプレートとデプロイされたアプリケーションコードの間にドリフトが発生します。このようなドリフト発生を回避するため、本番環境では絶対にホットスワップを使用してはいけません。ホットスワップにより高速なデプロイができますが、CloudFormation のように安全にデプロイできる機能ではないため、ホットスワップは高速なコーディング・コンパイル・テストのループを回す必要がある開発環境での使用に最適です。 watch 実行中にホットスワップを無効にしたい場合は、 watch 実行時に --no-hotswap フラグを指定してください。CloudFormation とアプリケーション間のドリフトを完全に取り除く必要がある場合は、 cdk deploy を実行することで CloudFormation フルデプロイが行われます。 cdk watch を実行せずにホットスワップデプロイを行いたい場合は、 cdk deploy --hotswap を実行してください。 デプロイが完了したら、ページを更新してください。Hello World のページが以下のように更新されているはずです。 インフラストラクチャコードの変更 すべてのリソース変更がホットスワップできるわけではありません。Lambda 関数のコード変更、ECS サービスのコンテナ定義変更、Step Functions のステーマシン定義変更などがホットスワップに対応しています。他のリソースに変更が入った場合は、ホットスワップデプロイではなく CloudFormation フルデプロイを行う必要があります。この動作を確認するために、 lib/cdk-watch-stack.ts のコードを以下のように変更してください。 import { Stack, StackProps, aws_ec2 as ec2, aws_ecs as ecs, aws_ecs_patterns as ecs_patterns, } from 'aws-cdk-lib'; import { Construct } from 'constructs'; export class CdkWatchStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Fargate does not work with default VPCs const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 2, // ALB requires 2 AZs natGateways: 2, //changing this property does not trigger a hotswap, and a full deployment occurs instead }); new ecs_patterns.ApplicationLoadBalancedFargateService(this, 'EcsService', { vpc, taskImageOptions: { image: ecs.ContainerImage.fromAsset('docker-app'), containerPort: 80, }, }); } } ターミナルウィンドウを確認してください。アセットの公開が完了すると、次のメッセージが出力されます。 ⚠ The following non-hotswappable changes were found. To reconcile these using CloudFormation, specify --hotswap-fallback logicalID: VpcPrivateSubnet2DefaultRoute060D2087, type: AWS::EC2::Route, rejected changes: NatGatewayId, reason: This resource type is not supported for hotswap deployments これは、ホットスワップデプロイができない変更が含まれていたことを意味しています。通常、アプリケーションのインフラストラクチャに対する変更はホットスワップできませんが、アプリケーションで使用されるアセットに対する変更はホットスワップ可能です。今回行った変更は vpc で使用されている natGateways の数を増やすもので、インフラストラクチャの変更に該当するためホットスワップができません。デフォルトでは、ホットスワップに対応していない変更が入った場合には、 watch はデプロイを行いません。 --hotswap-fallback のフラグを付けることで、ホットスワップに対応していない変更が入った場合に CloudFormation フルデプロイを実行するようフォールバックする動作となります。 ロールバックの無効化 デフォルトでは、 cdk watch は --no-rollback を使用しません。ロールバックを無効化する前に、 cdk watch を実行しているターミナルウィンドウで ^C ( Ctrl + C ) を入力し、その後ターミナルで cdk deploy コマンドを実行してください。 cdk deploy まずは CloudFormation フルデプロイを実行し、前の手順で行った変更を反映させます。これらの変更は CloudFormation によって「置き換えが必要な変更」とみなされ、 --no-rollback フラグがサポートされません。なぜなら、 ApplicationLoadBalancedFargateService を構成するリソースの 1 つに対する削除と作成を必要とするためです。デプロイが完了したら、次のコマンドを実行します。 cdk watch --no-rollback --hotswap-fallback 最初に cdk watch を実行したときと同じ内容が出力されるはずです。実行したら、 lib/cdk-watch-stack.ts を以下のように変更してください。 import { Stack, StackProps, aws_ec2 as ec2, aws_ecs as ecs, aws_ecs_patterns as ecs_patterns, } from 'aws-cdk-lib'; import { Construct } from 'constructs'; export class CdkWatchStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Fargate does not work with default VPCs const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 2, // ALB requires 2 AZs natGateways: 2, }); new ec2.CfnVPC(this, 'mycfnvpc', { cidrBlock: '10.0.0/16', //intentionally incorrect code }); new ecs_patterns.ApplicationLoadBalancedFargateService(this, 'EcsService', { vpc, taskImageOptions: { image: ecs.ContainerImage.fromAsset('docker-app'), containerPort: 80, }, }); } } この変更では、無効な cidrBlock を指定していることに注意してください。今回はインフラストラクチャの変更なのでホットスワップができず、CloudFormation フルデプロイになることが予想されます。 cdk watch が実行されているため、以下のようなエラーメッセージが表示されます。 Could not perform a hotswap deployment, as the stack CdkWatchStack contains non-Asset changes Falling back to doing a full deployment CdkWatchStack: creating CloudFormation changeset... 3:17:02 PM | CREATE_FAILED | AWS::EC2::VPC | mycfnvpc Value (10.0.0/16) for parameter cidrBlock is invalid. This is not a valid CIDR block. (Service: AmazonEC2; Status Code: 400; Error Code: InvalidParameterValue; Request ID: 4b670ce5-32bd-46dd-88de-33765f18d479; Proxy: null) ❌ CdkWatchStack failed: Error: The stack named CdkWatchStack failed to deploy: UPDATE_FAILED (The following resource(s) failed to create: [mycfnvpc]. ) at Object.waitForStackDeploy (/usr/local/lib/node_modules/aws-cdk/lib/api/util/cloudformation.ts:309:11) at processTicksAndRejections (internal/process/task_queues.js:95:5) at prepareAndExecuteChangeSet (/usr/local/lib/node_modules/aws-cdk/lib/api/deploy-stack.ts:337:26) at CdkToolkit.deploy (/usr/local/lib/node_modules/aws-cdk/lib/cdk-toolkit.ts:194:24) at CdkToolkit.invokeDeployFromWatch (/usr/local/lib/node_modules/aws-cdk/lib/cdk-toolkit.ts:594:7) at FSWatcher.<anonymous>(/usr/local/lib/node_modules/aws-cdk/lib/cdk-toolkit.ts:310:9) --no-rollback を指定したことで、CloudFormation によるロールバックは行われませんでした。では以下のように変更し、 cidrBlock を有効な値にしてみましょう。 import { Stack, StackProps, aws_ec2 as ec2, aws_ecs as ecs, aws_ecs_patterns as ecs_patterns, } from 'aws-cdk-lib'; import { Construct } from 'constructs'; export class CdkWatchStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Fargate does not work with default VPCs const vpc = new ec2.Vpc(this, 'Vpc', { maxAzs: 2, // ALB requires 2 AZs natGateways: 2, }); new ec2.CfnVPC(this, 'mycfnvpc', { cidrBlock: '10.0.0.0/16', //corrected code }); new ecs_patterns.ApplicationLoadBalancedFargateService(this, 'EcsService', { vpc, taskImageOptions: { image: ecs.ContainerImage.fromAsset('docker-app'), containerPort: 80, }, }); } } cdk watch が変更を検知し、以下のようなメッセージを出力して自動的にデプロイが成功するはずです。 Could not perform a hotswap deployment, as the stack CdkWatchStack contains non-Asset changes Falling back to doing a full deployment CdkWatchStack: creating CloudFormation changeset... ✅ CdkWatchStack Outputs: CdkWatchStack.EcsServiceLoadBalancerDNS6D595ACE = CdkWa-EcsSe-T2ZOAGRO8LGP-xxxxxxxxx.us-east-2.elb.amazonaws.com CdkWatchStack.EcsServiceServiceURLE56F060F = http://CdkWa-EcsSe-T2ZOAGRO8LGP-xxxxxxxxx.us-east-2.elb.amazonaws.com Stack ARN: arn:aws:cloudformation:us-east-2:xxxxxxxxxxxx:stack/CdkWatchStack/95d784f0-4d73-11ec-a8b8-xxxxxxxxxxxx クリーンアップ デプロイしたスタックとアプリケーションを削除するには、CDK プロジェクトのルートディレクトリで cdk destroy コマンドを実行してください。 cdk destroy まとめ cdk watch を使用することで、可能な場合はホットスワップにより CloudFormation がバイパスされ、より迅速にスタックの更新を行うことができます。すべてのリソースの変更がホットスワップ可能なわけではありません。ホットスワップデプロイが実行できない場合は、 watch が CloudFormation フルデプロイにフォールバックするフラグ --hotswap-fallback を追加することもできます。ホットスワップによって意図的なドリフトが発生するため、本番環境では使用しないでください。必要に応じて --no-hotswap フラグを追加することで、ホットスワップを無効にすることもできます。 --no-rollback フラグを追加して cdk watch を実行すると、更新失敗時のロールバックが無効になります。ただし、置換タイプの更新では --no-rollback フラグがサポートされておらず、フラグを追加した状態でデプロイしようとするとエラーになるので、ご注意ください。

Amazon Monitron は産業設備の予知保全を行うためのデバイス、アプリケーションが一体となったエンドトゥエンドのサービスです。このブログでは産業設備予知保全の課題と Amazon Monitron によるソリューション、2024年現在のアップデート、利用方法の学び方、大規模設備への適用方法などをこれまでに公開された資料をもとに紹介します。 この記事を読んでいただきたい読者 生産工場、物流拠点、プラントを操業する企業の方、モーター・ベアリング・ポンプ・ファンなど多くのコンポーネントを持つ設備を稼働し、その保守・点検を改善することに課題を持つ生産部門の方、あるいは自社製の設備や製品の予知保全に関心を持つ方を想定しています。 産業における設備保全の課題 製造工場やプラント、物流倉庫など、産業の現場には、膨大な数の機器が存在します。そして、機器の故障は、生産活動の停止を意味します。これらの産業現場において計画外のダウンタイムはメンテナンスにコストがかかり、生産効率の低下による機会ロスにもつながります。 定期的に交換する消耗品などは、余裕を見て交換のサイクルを短縮すれば良いという考えもあると思います。設備保全において、故障後に交換する事後型、寿命に応じて交換時期を決め、計画的に交換する計画型のアプローチが一般的です。一方で、コストの観点から、可能な限り壊れる直前まで寿命一杯使いたいものです。ただ、使い方によっては想定よりも早く摩耗し、結果として機器の故障に繋がるので交換タイミングを適切に予想する必要があります。これは予測型のアプローチ（予知保全）と言えます。 予測型アプローチでは、継続的なモニタリング、データ分析による予測、必要なタイミングでのアクションが組み合わされています。これにより、設備保全のチームは、実際の機器の状態に基づいて、必要なときにだけ機器を修理することができます。予知保全は主に大規模・高価な装置や工場・プラント全体の監視に多く導入されています。しかしながら、モーター、ファン、ベアリング、ポンプといったコンポーネントには高価なセンサーや複雑な検知システムを導入することが難しく、多くの機器が事後保全や計画保全を中心に運用されている現状があります。 (図: 産業メンテナンス戦略) 産業設備の予知保全サービス Amazon Monitron とは Amazon Monitron は、産業設備の予知保全ソリューションで、アプリケーションからセンサーデバイスまでを一貫して提供します。Amazon Monitron には、振動や温度データを取得するセンサーデバイス、データを AWS クラウドに転送するゲートウェイデバイス、データを ML で異常解析する Amazon Monitron サービス、設備の潜在的な故障を確認するための専用モバイルアプリが含まれています。お客様の保全者は、このアプリを使用して、産業設備の診断や保全計画を立てることができます。 (図: Amazon Monitron による設備予知保全) Amazon Monitron は安価なセンサーと統合されたアプリケーションを組み合わせたサービスで、これまで保全ソリューションの導入が困難だったモーター、ギアボックス、ベアリング、ポンプ、ファン、コンプレッサといった回転部分を有するコンポーネントに予知保全を導入することを目的としています。これらのコンポーネントは単純ですが、工場などの現場には大量に存在し、計画外の稼働停止が発生すると時には工場・プラント全体の操業に影響を与え大きなビジネス損失を生む可能性があります。 Amazon Monitron は小型の Amazon Monitron センサーを対象設備へ貼り付けることで予知保全を実現します。センサーは３軸の振動センサーと温度センサーを持ち、またバッテリーを内蔵することで5年間バッテリー交換や充電の手間なく稼働することが可能です。センサーは電源や通信ケーブルを必要とせずに機器に取り付けることができます。これにより、長年稼働している古い設備やセンサーとの接続手段をもたない機器へ「後付で予知保全」を実現することが可能です。 (図: Amazon Monitron センサー ) Amazon Monitron は Web アプリケーションとスマートフォン用のモバイルアプリケーション( Monitron アプリ)を提供します。 Monitron アプリは利用ユーザー管理、設備（アセット）とMonitron センサーの関連付け、設備毎の状態表示、不具合の通知といった機能を持ち、は AWS の知識がなくても Monitron アプリだけで完結して保全を行うことが可能です。 Monitron アプリでは取り付けたセンサーから送られたデータをグラフ表示し、不具合の可能性を検知した場合にスマートフォンアプリから保守員へ通知します。保守員はアプリの「確認」ボタンをおして設備を「メンテナンス」状態に設定します。「メンテナンス」状態では Monitron アプリは予知保全による通知を一時停止します。 (図: ML と ISOをベースにした分析) 不具合の予兆を知った保守員は現場へ赴き設備の調査を行います。結果、問題があれば交換や調整などの適切な対応を行います。ユーザーは Monitron アプリに「障害モード」「障害の原因」「保守員が実行したアクション」の３項目を入力し対策したことをMonitronへ送信します。その後、Monitron はその設備が正常になったことを認識して予兆検知を再開します。 (図: Amazon Monitron アプリ上での問題の解決) Amazon Monitron デバイスの 日本発売と2023〜2024年の機能アップデート Amazon Monitron デバイス (センサー、ゲートウェイ）は各国の法規に基づき、認定を取得し動作可能な国・地域で販売されています。日本では 2023年8月にAmazon Monitron デバイスが販売開始されました。その後も様々な機能のアップデートが行われています。2023年から2024年までの Amazon Monitron サービスアップデートは AWS ブログ 「 Amazon Monitron (産業設備の異常予兆検知) 2023-2024年アップデートのまとめ 」を御覧ください。 多拠点・大規模な設備群における保全の効率化の課題と取り組み 前述したように Amazon Monitron は産業設備の予知保全に必要な機能を備えていますが、多拠点・大規模な産業設備群の保全には多数の機器状態の効率的な把握や作業員との連携、設備構成管理システムと協調した機器交換計画の管理が必要になる場合があります。例えば、拠点ごとに現在保全が必要な機器数を知り、保全要員のスケジュールを決定したり、過去の保全履歴から不良の原因を分析し、保全マニュアルを改善したり機器交換のタイミングを計画することができます。 現場の保守員の観点では、保全が必要なタイミングで保全の必要性を通知し、作業員のスケジュールを確保し、作業にかかる時間を短縮する仕組みが必要で、これらを実現するには既存の保全管理システムとの連携が必要です。 これらを実現する手段として、Amazon Web Services ブログ「 Amazon Monitron と Amazon Kinesis により予知保全のためのアクションにつながる洞察を得る方法 」 で Amazon Monitron のデータを他サービスと連携する機能「データエクスポート」を使用して、Infor EAM 、 SAP Asset Management 、 IBM Maximo などの Enterprise Asset Management (EAM: エンタープライズ設備管理) システムと連携できること、その実例として、収集したデータを Amazon S3 に蓄積し、 AWS Glue や Amazon Athena といった分析サービスを使うことで大規模運用計画を支援するダッシュボードを構築できることをご紹介していますので御覧ください。 より詳しく知るには この記事では Amazon Monitron の概要を説明し、大規模・多拠点の設備を有する産業に向けた、設備群の不良予兆検知ダッシュボードとその実装構成について、 Amazon Monitron によるソリューションとその活用を紹介しました。 製造業を始めとする産業での AWS 利用について、実際の事例やリファレンスアーキテクチャを知りたい方は、 AWS の製造業に対する取り組み を御覧ください。 今回のデモで用いた各 AWS サービスの詳細はサービスの紹介ページをごらんください。 Amazon Monitron (産業設備の不良予知保全) AWS サービスについてより詳しく学びたい方は、 AWS Black Belt Online セミナーにてサービス毎のオンデマンドセミナー を公開しています。Amazon Monitron は基本編、設定編、サービス連携編の３つのオンデマンドセミナーを提供しています。 Amazon Monitron Part 1 （基本編） Amazon Monitron Part 2 （設定編） Amazon Monitron Part 3 （サービス連携編） 今回のソリューションについて、自社の現場への導入にご興味のある方は、「 AWS に問い合わせする 」からお問い合わせください。 このブログについて このブログの内容は AWS Japan のソリューションアーキテクト 吉川晃平 が執筆しました。

はじめに このシリーズの前回の記事で、私たちは「 生成 AI のマーケティング戦略への適用: 入門編 」でマーケティング戦略に対する 生成 AI の変革的な影響を検討し、「 From Prompt Engineering to Auto Prompt Optimisation 」で Amazon Bedrock などのサービスを使用してマーケティングコンテンツの作成を強化するプロンプトエンジニアリングの複雑さを掘り下げました。 また、大規模言語モデル (LLMs) を利用して顧客との効果的なエンゲージメントのためのプロンプトを改善する可能性についても探りました。 この記事では更に掘り下げて、 Amazon Bedrock 、 Amazon Personalize 、 Amazon Pinpoint を活用した AI 主導のコンテンツ生成と、コンテンツをパーソナライズして効果的に配信するマーケターポータルを構築する方法を説明します。 目的は、マーケティングコンテンツを効率的に作成、パーソナライズ、配信するシステムを展開するための明確なブループリントを提供することです。 このブログでは、このようなサービスの実用的な活用方法を紹介しながら、展開プロセスを説明します。 ユースケースとデモを通して、AI ドリブンのソリューションでマーケティングにおけるパイプラインを強化する具体例を見ていきます。 マーケティングにおけるコンテンツ生成の課題 多くの企業は、マーケティング業務を効率的に合理化することに難しさを感じています。マーケティング業務の各段階で障害に直面するためです。以下では、パイプラインの主要な 3 つの段階 (コンテンツ生成、コンテンツパーソナライゼーション、コンテンツ配信) における課題を列挙します。 コンテンツ生成 高品質で魅力的なコンテンツを作成することは、現実的に実現することが難しいことがよくあります。企業は、製品だけでなくターゲット層も理解したスキルのある編集者やコンテンツクリエイターに投資する必要があります。適切な人材がいても、そのプロセスは時間がかかり、コストがかかります。さらに、品質を維持し、業界規制に準拠しながら大規模にコンテンツを生成することが、本番環境で生成 AI 技術を採用することを検討している多くの企業の主な障壁となっています。 コンテンツのパーソナライズ コンテンツを作成したら、次の課題はパーソナライゼーションです。デジタル時代の今日、一般的なコンテンツではめったに注目されることはありません。 顧客は、自分のニーズや好み、行動に合わせたコンテンツを期待しています。 しかし、コンテンツをパーソナライズすることは簡単ではありません。 顧客データを深く理解する必要があり、そのようなデータは分散したデータベースに存在することが多いため、顧客の全体像を描くのが難しくなります。 コンテンツの配信 最後に、たとえ魅力的で個人に最適化されたコンテンツでも、適切なユーザーに適切なタイミングで届かなければ効果がありません。 企業は、E メールや SNS、モバイルプッシュ通知など、コンテンツの配信チャネルの選択で苦労することがよくあります。 さらに、コンテンツがさまざまな規制に準拠し、迷惑フォルダに入らないよう配慮する必要もあり、配布フェーズはより複雑になります。 大規模な配信では、到達可能性、セキュリティ、信頼性に注意を払う必要があり、マーケターにとって大きな課題となることがよくあります。 これらの課題に対処することで、企業はマーケティングの運用を大幅に改善し、マーケティング担当者がより効果的に活動できるようになります。しかし、どうすればこれを効率的かつ大規模に実現できるでしょうか? 次のソリューションで説明するように、Amazon Bedrock、Amazon Personalize、Amazon Pinpoint を活用することがその答えとなります。 ソリューションのアプローチ 詳細な実装に入る前に、リンクされた デモ動画 で、最終的な結果を確認しましょう。 ユースケース1: 銀行/金融サービス業界におけるユースケース あなたが架空の企業 AnyCompany Bank の消費者金融部門で勤務するリレーションシップマネージャーと仮定します。特定のグループの顧客が割り当てられており、そのグループのすべてのメンバーに対して、希望のチャネルで個人に合わせたターゲティングされたコミュニケーションメッセージを送信したいと考えています。 この裏の仕組みとして、マーケターは Amazon Pinpoint を利用してターゲットにしたい顧客層のセグメントを作成しています。その顧客情報とマーケターの指示は、 Amazon Bedrock に送られ、マーケティングコンテンツが生成されます。そのコンテンツは Amazon Pinpoint を使って SMS とE メールで顧客に送信されます。 Prompt Iterator  ページでは、「プロンプトエンジニアリング」と呼ばれるプロセスを利用して、プロンプトを最適化し、マーケティングキャンペーンの効果を最大化することができます。プロンプトエンジニアリングの手順と、自動プロンプト生成に別の LLM モデルを適用する方法については、 こちらのブログ を参照してください。はじめに、このページでプロンプトエンジニアリングプロセスを経たサンプルの銀行業向けプロンプトをコピーしてみてください。 次に、.csv ファイルをアップロードして顧客グループをインポートする方法 (セグメントのインポート) か、Amazon Pinpoint を使って事前に定義された条件に基づいて現在の顧客データベースから顧客グループを指定する方法のいずれかを選択できます。 例: スクリーンショットには ManagementOrRetired という名前の、管理職または退職者のみを対象とするフィルターされたセグメントのサンプルが表示されています。 作業が完了したら、マーケターポータルにログインして、Amazon Pinpoint コンソール内で作成した関連セグメントを選択できます。 次に、Amazon Pinpoint のカスタマーデータベースに保管されているお客様情報をプレビューで確認きます。内容を確認できたら、お客様向けのコンテンツを生成する準備が整います。 1:1 Content Generator タブをクリックすると、最初のお客様向けのコンテンツが自動的に生成されます。ここでは、お客様を 1 人ずつサイクルさせ、そのお客様の希望言語とチャネルに応じて、希望言語のメールまたは SMS が自動的に生成されます。 例: 英語で生成された SMS 例: プロンプトエンジニアリングが適切に機能して、否定的なコンテンツを生成していることを示す例です。マーケティングコンテンツジェネレーターが出力するのに適さないデータを挿入しようとした場合、こういった状況になります。この例では、分割払い方式の融資の広告を 6 歳児に対して出力することを拒否しています。 最後に、「Send with Amazon Pinpoint」をクリックすると、生成したコンテンツが Amazon Pinpoint で送信されます。バックエンドでは、Amazon Pinpoint が適切なチャネルを通じてメール / SMS の送信を調整します。 もし自動生成されたコンテンツがまだ要件を満たさない場合は、 再試行 することができます。 ユースケース2: 旅行と宿泊業でのユースケース ある航空会社のオンライン航空券代理店の営業マネージャーとして仕事をしていると仮定します。シンガポールから香港までのフライトを、プロモーションする課題を任されました。まずこの区間のフライトに適した顧客を特定し、ハイパーパーソナライズされたメッセージを送る必要があります。 この裏の仕組みとして、 Amazon Pinpoint を使って手動でセグメントを定義するのではなく、今回のマーケティング担当者は Amazon Personalize の AI/ML 機能を活用して、特定の航空便を推奨するための最適な顧客グループを定義しています。上記のユースケースと同様に、顧客情報と LLM プロンプトが Amazon Bedrock に入力され、最終的に Amazon Pinpoint を通じて送信されるマーケティングコンテンツが生成されます。 上記のユースケースと同様に、LLM モデルが生成するコンテンツが関連性があり、使用する上で安全であることを確認するため、プロンプトエンジニアリングのプロセスを経る必要があります。すばやく始めるには、 Prompt Iterator ページに移動し、 サンプルの航空会社のプロンプト を使って、それをベースに試行錯誤することができます。 あなたの会社は多くの異なる航空便を、さまざまな航空会社から集約して提供しています。まず、左側の フィルター を使って、推奨したい航空便を絞り込みます。この例では、シンガポール (SRCCity) を出発地とし、香港 (DSTCity) を目的地とする、AnyCompany が運航する便をフィルタリングしています。 次に、生成したいお客様の数を選択し、バッチセグメント化のジョブを開始するよう選択します。 バックグラウンドで、Amazon Personalize は過去の同様の航空券の予約履歴から、この便に関心が高そうなお客様のグループを生成します。 セグメント化ジョブが完了したら、推奨されたお客様グループを取得し、最初のユースケースと同様にすぐにコンテンツ生成を開始できます。 セットアップの手順 セットアップ手順とデプロイの詳細は、リンクの GitHub で確認できます。 まとめ このブログでは、Amazon Bedrock、Amazon Personalize、Amazon Pinpoint を統合することで、マーケティング運用における一般的な課題に対処できる可能性を見ていきました。 Amazon Bedrock でコンテンツ生成を自動化し、Amazon Personalize でパーソナライズをスケールし、Amazon Pinpoint で正確なコンテンツ配布を確実にすることで、企業はマーケティングプロセスを効率化するだけでなく、顧客体験も向上できます。 明確なメリット: 自動化による時間の節約、オペレーション効率の向上、パーソナライズされた顧客体験による顧客満足度の向上です。この統合ソリューションにより、マーケターは戦略と創造性に集中できるようになり、手間がかかる部分は AWS の堅牢な AI と ML サービスに任せられます。 次のステップに進む準備ができた方に、このソリューションを実装するための包括的なガイドとリソースを用意しています。 セットアップ手順に従い、提供されたプロンプトを起点として活用することで、このソリューションをデプロイし、マーケターポータルをビジネスのニーズに合わせてカスタマイズし始めることができます。 今後の展開 コンテンツの生成、パーソナライゼーション、配信の課題にとらわれるのではなく、マーケティングの可能性を最大化してください。今すぐ Generative AI Marketer Portal をデプロイし、ニーズに合わせてカスタマイズした上で、マーケティング業務の変革を体験しましょう。ハンズオンで始めるには、詳しい手順を確認できる GitHub リポジトリ をご覧ください。 著者について Tristan (Tri) Nguyen Tristan (Tri) Nguyen は、AWS のシニア・スペシャリスト・ソリューション・アーキテクトです。データサイエンス、マーテック、カスタマーデータプラットフォームの深い専門知識を持ち、機械学習と生成 AIの活用を専門とし、アジア太平洋地域の顧客のためにスケーラブルな顧客エンゲージメント戦略とアーキテクチャソリューションを構築している。ジョージア工科大学でコンピュータサイエンスの修士号を取得し、AWS テクノロジーに関する豊富な実務経験を有し、12 の AWS 認定資格をすべて取得している。余暇にはトライアスロン、大きな山でのハイキング、大きな岩でのクライミングを楽しんでいます。 Philipp Kaindl Philipp Kaindl は AWSのシニア人工知能・機械学習ソリューションアーキテクトでデータサイエンスと機械工学のバックグラウンドを持ちます。 データサイエンスと機械工学のバックグラウンドを持つ彼は、AI の助けを借りて顧客が永続的なビジネスインパクトを生み出せるようにすることにフォーカスしています。仕事以外では、3D プリンターいじり、セーリング、ハイキングを楽しんでいます。 Bruno Giorgini Bruno Giorgini は、Pinpointと SES を専門とするシニア・ソリューション・アーキテクトです。IT 業界で20年以上の経験を持つブルーノは、あらゆる規模の顧客の目標達成を支援することに専念してきました。顧客のために革新的なソリューションを構築していないときは、妻と息子と一緒にSFベイエリア周辺の風光明媚なハイキングコースを散策し、充実した時間を過ごしています。 この記事は、 Building a generative AI marketing portal on AWS を翻訳したものです。 翻訳は Solution Architect の 中村 達也 が担当しました。