本記事は 2025 年 3 月 11 日に公開された “ Take control of your code with Amazon Q Developer’s new context features ” を翻訳したものです。 このブログでは、開発者が自分の開発ワークフローを完全にコントロールできるようになる、 Amazon Q Developer の強力な新機能を紹介します。これらの機能は現在 Visual Studio Code で利用可能で、ワークスペースコンテキスト、明示的なコンテキスト指定、プロンプトライブラリ、プロジェクトルールの活用によるソフトウェアプロジェクトの効率化、コーディング標準の維持、生産性の向上を実現できます。他の IDE を使用している開発者向けにも、これらの機能のサポートは今後提供される予定です。経験豊富な開発者でも、これから始めようとしている方でも、これらの機能によって開発タスクへの取り組み方が大きく変わるはずです。 背景 過去 1 年にわたり、 Amazon Q Developer は統合開発環境 (IDE) におけるワークスペースコンテキストをサポートしてきました。この強力な機能により、Amazon Q Developer はコードファイル、設定ファイル、プロジェクト構成などを自動的に読み取り、インデックス化することで、AI を活用したアシスタントがアプリケーション全体にわたる包括的なコンテキストを把握できるようになります。 質問に @workspace 修飾子を追加することで、Amazon Q Developer はワークスペース内のコードから最も関連性の高い部分を自動的に追加コンテキストとして含めることができます。これにより、現在のファイルだけでなく、より広範なコードベースの理解が必要な質問に対しても、より正確で充実した回答を得ることができます。 この機能を説明するために、 AWS CDK Immersion Day Workshop のコードを使用してみます。たとえば、「Which resources are deployed by the workshop stack?（このワークショップスタックでデプロイされるリソースは何ですか？）」と Amazon Q Developer に質問したとします。通常であれば、アシスタントは IDE 上で開いている現在のファイルだけをコンテキストとして使用しますが、 @workspace を追加することで、Amazon Q Developer は、AWS Lambda 関数、 Amazon API Gateway 、 Amazon DynamoDB テーブルなど、プロジェクト内のすべてのリソースを含む、より完全なレスポンスを得られます。 この追加コンテキストにより、Amazon Q Developer はより包括的な回答を行うことができ、ワークショップスタックを構成するさまざまなリソースについて詳しく説明してくれます。 コンテキストの透明性 Amazon Q Developer は、大規模なプロジェクトのすべてのファイルをレビューすることはできません。すべてを読み込むには時間がかかりすぎるためです。アシスタントは、定期的に更新されるインデックスに基づいて関連性の高いファイルを判断しています。これは多くの場合うまく機能しますが、Amazon Q Developer がどのファイルを選んだのかを知りたい場合もあります。そんなときに役立つのが、新しく追加されたコンテキストの透明性の機能です。 Amazon Q Developerは、追加された各ファイルをリストアップし、レスポンスに直接コンテキスト情報を含めるようになりました。コンテキストの透明化機能により、アシスタントが回答を作成するために使用したファイルを正確に確認できます。以下の例では、Q Developer がプロジェクト内の 4 つのファイルを使用したことがわかります。 コンテキストセクションを展開することで、Amazon Q Developer が前回の回答を生成する際に使用したファイルを簡単に確認できます。これにより、アシスタントの意思決定プロセスについて、より深く理解することができます。 明示的なコンテキスト 通常、Amazon Q Developer は最適なファイルを自動で選択し、コンテキストを補強してくれますが、より細かくコントロールしたい場合もあります。そんなときに便利なのが、新しく追加された明示的なコンテキスト機能です。この機能を使えば、自分でコンテキストに含めたいファイルやフォルダを選択できます。 チャットで @ を入力すると、Amazon Q Developer はファイルやフォルダを選択できるユーザーインターフェースを表示します。これにより、質問に答えるために必要だと自分で把握している情報を、アシスタントに正確に渡すことができます。 前の例に戻ってみましょう。Q Developer はスタック内のリソースを正しく特定しましたが、DynamoDB テーブルが定義されている lib/hitcounter.ts はコンテキストに含まれていませんでした。回答としては正しいものの、私は Q Developer に HitCounter のソースも参照してほしいと考えています。そこで、以下の例では lib フォルダを明示的にコンテキストに追加しています。理由は、その中にリソース定義があると私自身が知っているからです。 Q にファイルの選択を任せるのではなく、自分でコンテキストに追加したいファイルやフォルダを明示的に指定することができます。以下の画像では、Q が今回も正しく質問に答えている様子が確認できます。ただし、両方のファイルのソースコードをコンテキストに含めたことで、前の例では抜けていた追加情報も含めることができました。たとえば、 HitCounterHandler には実行環境やバージョンに関する情報が新たに含まれていることがわかります。 コンテキストを明示的に指定できることで、Amazon Q Developer が使用する情報を自分のニーズに合わせて調整し、より関連性が高く正確な回答を得ることができます。 プロンプトライブラリ コンテキストをコントロールする機能に加えて、Amazon Q Developer では共通のプロンプトのライブラリを構築できるようになりました。これらのプロンプトは Markdown ファイルとして ~/.aws/amazonq/prompts フォルダに保存され、複数の会話やプロジェクト間で簡単に再利用できます。 たとえば、プロジェクトの README ファイルに図を追加したいとします。Amazon Q Developer の /doc 機能ではインフラストラクチャ図を生成できますが、頻繁に使う図として ER 図（Entity-Relationship 図）やシーケンス図などもあるかもしれません。そうしたプロンプトをライブラリに保存しておくことで、毎回プロンプトを入力し直すことなく、簡単にコンテキストに追加できます。以下の例では、シーケンス図を作成してみます。 前の画像では、保存済みのプロンプト「Create Sequence Diagram」に加えて、再び lib フォルダをコンテキストに追加している様子が確認できます。このように、必要に応じて複数の修飾子を組み合わせて、追加のコンテキストやプロンプトを柔軟に指定することができます。「Create Sequence Diagram」という保存済みプロンプトの内容は以下のとおりです。 Create a sequence diagram using Mermaid that shows the sequence of calls between resources. Ignore supporting resources like IAM policies and security group rules. ※日本語訳 Mermaid を使って、リソース間の呼び出しの流れを示すシーケンス図を作成してください。 IAM ポリシーやセキュリティグループのルールなどの補助的なリソースは無視してください。 Amazon Q Developer はこのプロンプトと、 lib フォルダ内の 2 つのソースコードファイルをもとに、以下のようなシーケンス図を生成しました。 プロンプトライブラリを使うことで、時間を節約でき、一般的な成果物を生成するときのミスの可能性も減らせます。その結果、より複雑で創造的な開発作業に集中できるようになります。 プロジェクトルール 最後に紹介する機能は「プロジェクトルール」です。プロンプトライブラリと同様、これらのルールは Markdown ファイルとして保存されます。プロンプトライブラリがユーザープロファイルに紐づくのに対し、プロジェクトルールはプロジェクト内の .amazonq/rules フォルダに保存されます。そのため、ソースコードを共有するすべての開発者にルールが適用されます。 これらのルールにより、チーム全体でコーディング規約やベストプラクティスを徹底できるようになります。たとえば、Python のコードには必ず型ヒントを付ける、Java のコードには Javadoc コメントを記述する、といったルールを設定できます。ルールをプロジェクトに保存することで、開発者の経験にかかわらず、コードの一貫性を保つことができます。 これを説明するために、若手の開発者が「Add an S3 bucket to the stack（スタックに S3 バケットを追加して）」とだけ Q に依頼したケースを考えてみましょう。このプロンプトはシンプルすぎて、私たちのベストプラクティスが反映されていません。 あいまいなプロンプトにもかかわらず、Q Developer の回答には「rules ファイル」に保存されたベストプラクティスへの言及が含まれていることに気づくかもしれません。また、プロンプトに修飾子を付けていないにもかかわらず、Q が cdk.md をコンテキストに追加していることにも注目してください。これこそがプロジェクトルールの強力さです。開発者が手動で追加するのを忘れても、自動的にコンテキストを補足してくれるのです。 .amazonq/rules/cdk.md には、次のような内容が記載されています。さらに、コンテキストの透明性の機能によって、そのルールがコンテキストに含まれていることが明確に表示され、開発者は適用されたルールが何かわかるようになっています。 All S3 Buckets must have encryption enabled, enforce SSL, and block public access. All DynamoDB Tables must have encryption enabled. All SNS Topics must have encryption enabled and enforce SSL. All SQS Queues must enforce SSL. ※日本語訳: すべての S3 バケットには暗号化を有効にし、SSL を強制し、パブリックアクセスをブロックすること。 すべての DynamoDB テーブルには暗号化を有効にすること。 すべての SNS トピックには暗号化を有効にし、SSL を強制すること。 すべての SQS キューには SSL を強制すること。 プロジェクトルールを活用することで、開発チーム全体でベストプラクティスやコーディングの一貫性を維持でき、コードベースの品質と保守性の向上につながります。 まとめ Amazon Q Developer の新機能により、ソフトウェア開発のワークフローを簡素化するための強力なツールを提供します。ワークスペースコンテキスト、明示的なコンテキスト、プロンプトライブラリ、プロジェクトルールを活用することで、AI アシスタントに正確で役に立つ回答を導くための情報を提供できるだけでなく、チーム全体でのベストプラクティスと標準の徹底も可能になります。 これらの機能を使い始めるには、 Amazon Q Developer の使用開始ガイド をご覧ください。開発をより効率的に、より優れたものにするためのさまざまな機能をぜひ体験してみてください。 翻訳はApp Dev Consultantの宇賀神が担当しました。

本ブログは 2025 年 3 月 21 日に公開された Blog “ Optimize your Amazon QuickSight implementation: a guide to usage analytics and cost management ” を翻訳したものです。 組織全体で Amazon QuickSight の利用状況を正確に把握し、最適化することは、コストを無駄なく管理し、BI への投資効果を最大化するためにとても重要です。QuickSight の導入が進み、さまざまな役割のユーザーが利用するようになるにつれて、「誰がどのように使っているか」を明確に可視化することの重要性が一層高まっています。 一方で、多くのお客様から、「ユーザーの利用状況を把握するのが難しい」というお声を頂いております。例えば、「過去90日間で追加された リーダープロ ライセンスの数は？」「セッションの利用パターンはどうなっているのか？」といった内容です。 こうしたニーズに応えるべく、QuickSight の利用状況を簡単に把握し、QuickSight のライセンスの棚卸しや最適化の意思決定をよりデータドリブンに行えるようにするソリューションをご紹介します。 AWS CloudFormation テンプレートを使って、以下のソリューションを簡単に導入できます。 AWS Glue と QuickSight API を活用して、QuickSight ユーザー情報を自動で抽出 Amazon Athena テーブルを作成し、QuickSight アカウントのユーザーデータや、 コストと使用状況レポート（AWS CUR） に基づいた集約ビューの作成 事前構築された QuickSight ダッシュボードをセットアップし、次のようなインサイトを提供 リーダーの利用状況と、非アクティブユーザーの特定 セッションの消費パターン（リーダー・匿名ユーザーの両方） SPICE（超高速インメモリ計算エンジン）、アラート、ピクセルパーフェクトレポート、Amazon Q の利用状況 コスト最適化に向けたインサイト 少人数のチームを管理している場合でも、企業全体に展開している場合でも、この分析ソリューションを活用することで、QuickSight の導入状況を把握し、データに基づいたライセンスの棚卸しが可能になります。さらに、今後予定されている価格変更への備えにもなります。 ソリューションの概要 このソリューションは、QuickSight と他の AWS サービスを組み合わせて、分析用データを作成します。導入をシンプルにするために、必要なリソースをすべて自動で作成する CloudFormation テンプレートを用意しています。 AWS Glue ジョブ： qs-usage-users-info という Python シェルスクリプトが毎日実行されるようにスケジューリングされており、QuickSight API を呼び出して、QuickSight アイデンティティリージョン内のユーザー情報を取得します。 S3バケット：Glue ジョブが取得した結果は、 qs-usage-{AWS::AccountId}-{AWS::Region} という名前の新しい Amazon Simple Storage Service (Amazon S3)  バケットに保存されます。 Athena テーブル・ビュー：上記の S3 データをもとに、Athena データベース qs-usage-db にテーブルが作成され、さらに AWS アカウント内の コストと使用状況レポート (CUR) データをベースにビューが作成されます。 QuickSight ダッシュボード：Athena のテーブルと ビュー を元にしたデータセットを使って、QuickSight ダッシュボードがデプロイされます。このダッシュボードが実際のデータを取り込み、視覚的なインサイトを提供します。 上記のアーキテクチャ図は、主に次の3つのステップで構成されています。 ETL（抽出・変換・ロード）ジョブによる QuickSight ユーザー情報の収集 AWS Glue が毎日 ETL ジョブを実行し、QuickSight アカウントに登録されているユーザー情報を収集します。これにより、常に最新の情報が意思決定者の手元に届くようになります。 Athena 上に集計ビューを作成し、QuickSight の利用傾向を可視化 既存の コストと使用状況レポート (CUR) データを元に、Athena に集計ビューを構築します。これにより、すべてのプロダクトグループを横断して、QuickSight の利用状況を俯瞰的に把握できます。 データを SPICE に取り込み、QuickSight Usage Analytics ダッシュボードで利用状況を分析 集めたデータを SPICE にインポートすることで、高速な分析が可能になります。QuickSight の使用状況を視覚的に分析できるダッシュボードを使って、利用パターンやコスト最適化のためのインサイトを得られます。 前提条件 この手順を進める前に、以下の準備が整っていることを確認してください。 AWS IAM（Identity and Access Management） の権限 CloudFormation を使って AWS リソースを作成するために、必要な IAM 権限を持っていることを確認してください。 コストと使用状況レポート (CUR) の設定 AWS Data Exports を使って AWS CUR を有効化してください。 ※ エクスポートタイプについては、 レガシーCUR エクスポート 、 標準データエクスポート のどちらの CUR でも対応可能ですが、本投稿で提示している手順はレガシーCUR エクスポートを前提としています。標準データエクスポートを利用される場合は、後述する Athena ビュー作成 SQL を修正頂く必要がございます。 詳細なデータを取得するために、リソースIDの出力を有効化しておくことが重要です。 CUR の Glue テーブル化 CUR ファイルを Amazon Simple Storage Service (Amazon S3) にエクスポートするジョブが作成されます。S3 に保存されたファイルは、AWS Glue の クローラ などを使ってカタログ化し、 Glue Data Catalog 上のテーブルとして利用できる状態にしておく必要があります。このテーブルは、後述のステップ2で使われる重要なデータソースとなります。 以下の AWS サービスにアクセス可能であること AWS CloudFormation AWS Glue Amazon QuickSight Amazon S3 Amazon Athena 導入 提供されているテンプレートを使えば、このソリューションは 次の3つのステップ で簡単にセットアップおよびデプロイできます。 ステップ 1: S3 バケットと Glue ETL ジョブの作成 この CloudFormation テンプレートを使用する際には、QuickSight のアイデンティティリージョン（アカウントが属するリージョン）を正しく指定することが重要です。このステップを適切に行うことで、QuickSight アカウント内のユーザー情報を正確かつ網羅的に取得できるようになります。 ※アイデンティティリージョンは必須であり、省略することはできません。 このテンプレートによって作成されるリソースは以下の通りです。 IAMロール: qs-usage-glue-role-{AWS::AccountId}-{AWS::Region} QuickSight と Amazon S3 にアクセスするための権限を持つ、AWS Glue ジョブ用の IAM ロール AWS Glue ジョブの Python シェルスクリプト: qs-usage-users-info QuickSight API を使用してユーザー情報を取得するスクリプト AWS Glue トリガー: QuickSightUsersExtractDailyTrigger 上記の Glue ジョブを米国東部時間（ET）で毎朝6時に自動実行するスケジュール設定 ※ こちらはデプロイ完了後に日本時間 (JST) でのスケジュール設定に変更をお願いいたします。 S3 バケット: qs-usage-{AWS::AccountId}-{AWS::Region} QuickSight ユーザー情報の抽出結果を保存するための専用バケット 以下、 「Launch Stack」 をクリックし、画面の指示に従ってこれらのリソースを作成してください。 QuickSight のアイデンティティリージョンを選択してください。 このパラメータは必須であり、QuickSight アカウントに登録されているユーザー情報を取得するために必要です。 「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」 にチェックを入れ、「Next (次へ)」を選択してください。 スタックの作成が完了したら、AWS Glue コンソールに移動し、ナビゲーションペインから 「ETL Jobs (ETL ジョブ)」 → 「Visual ETL」 を選択します。 次に、 qs-usage-users-info ジョブを選択し、 「Run job」 をクリックしてください。これにより、次回のスケジュール実行を待たずに、データセットをすぐに生成できます。 ETL ジョブの実行が完了すると、ユーザー情報が抽出され、 qs-users-info.csv というファイルとして、 S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} に保存されます。 S3 コンソールに移動し、該当のバケット内にデータファイルが正しく作成されていることを確認してください。 複数の AWS アカウントで QuickSight を管理している場合でも、このソリューションを使えば、自動化された ETL プロセスによりユーザー管理をシンプルに行えます。 それぞれのリンク済みアカウントにこのテンプレートをデプロイすることで、すべての QuickSight ユーザーデータを中央のアカウントに集約することができます。 このようにデータを一元管理することで、CUR（コスト＆使用状況レポート）との連携による包括的な分析が可能になり、QuickSight ダッシュボードを通じて全社レベルでの使用状況を可視化できます。 結果として、組織全体の利用傾向を把握しやすくなり、最適化やモニタリングが格段に効率化されます。 ステップ2: Athena テーブルを作成する 2つ目の CloudFormation テンプレートは、Athena に次の2つのオブジェクトを作成します。 Athena テーブル: qs_users_info このテーブルには、QuickSight のアイデンティティリージョンに存在するすべてのユーザープロファイルと、それぞれのロールが含まれています。 Athena 保存済みクエリ: qs_usage_cur_vw_query このクエリは、アカウント内の AWS CUR テーブル上に作成され、QuickSight のさまざまな機能（アラート、ピクセルパーフェクトレポート、Amazon Q、セッション消費など）の使用傾向を分析するのに役立ちます。 このクエリは、次のステップで Athena のビューを作成する際に利用します。 以下は、アカウント内で確認できる保存済みクエリの例です。 CREATE OR REPLACE VIEW "AwsDataCatalog"."qs-usage-db"."qs_usage_cur_vw" AS SELECT bill_payer_account_id, line_item_usage_account_id, concat(DATE_FORMAT(line_item_usage_start_date, '%Y-%m'), '-01') AS month_line_item_usage_start_date, line_item_usage_type, CASE WHEN LOWER(line_item_usage_type) LIKE 'qs-user-enterprise%' THEN 'Users - Enterprise' WHEN LOWER(line_item_usage_type) LIKE 'qs-user-standard%' THEN 'Users - Standard' WHEN LOWER(line_item_usage_type) LIKE 'qs-reader%' THEN 'Reader Usage' WHEN LOWER(line_item_usage_type) LIKE '%spice' THEN 'SPICE' WHEN LOWER(line_item_usage_type) LIKE '%alerts%' THEN 'Alerts' WHEN LOWER(line_item_usage_type) LIKE '%-q%' THEN 'QuickSight Q' WHEN LOWER(line_item_usage_type) LIKE '%-report%' THEN 'Paginated Reporting' WHEN LOWER(line_item_usage_type) LIKE '%-reader-pro%' THEN 'Reader PRO' WHEN LOWER(line_item_usage_type) LIKE '%-author-pro%' THEN 'Author PRO' WHEN LOWER(line_item_usage_type) LIKE '%-reader-enterprise%' THEN 'Reader Usage' ELSE line_item_usage_type END AS qs_usage_type, line_item_line_item_description, line_item_line_item_type, product_group, pricing_unit, line_item_resource_id, product_usagetype, line_item_unblended_rate, line_item_blended_rate, line_item_operation, SUM(CAST(line_item_usage_amount AS DOUBLE)) AS sum_line_item_usage_amount, SUM(CAST(line_item_unblended_cost AS DECIMAL(16, 8))) AS sum_line_item_unblended_cost, SUM(CAST(line_item_blended_cost AS DECIMAL(16, 8))) AS line_item_blended_cost FROM "billing"."cur" -- This is replaced by ${CURSourceTable} with your CUR database.table name provided as Input to a parameter WHERE (CAST(year AS INTEGER) >=2024 ) AND product_product_name = 'Amazon QuickSight' AND line_item_line_item_type IN ('DiscountedUsage', 'Usage') GROUP BY bill_payer_account_id, line_item_usage_account_id, DATE_FORMAT(line_item_usage_start_date, '%Y-%m'), 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 ORDER BY month_line_item_usage_start_date ASC, sum_line_item_unblended_cost DESC ORDER BY month_line_item_usage_start_date ASC, sum_line_item_unblended_cost DESC 以下、 「Launch Stack」 をクリックし、画面の指示に従ってこれらのリソースを作成してください。 このスタックをデプロイするには、AWS CUR のデータベース名とテーブル名を、 データベース名.テーブル名 の形式で指定する必要があります（※アカウント内で表示されている名称に従って入力してください。） スタックのデプロイが正常に完了すると、 qs-usage-db という名前のデータベースが作成されます。 このデータベースには、QuickSight アカウント内のすべてのユーザー情報を含む qs_users_info テーブルが作成されており、ユーザーの一覧とそのロールを確認できるようになります。 スタックによって Athena の保存済みクエリが作成されたら、次にビューを作成します。 Athena コンソールに移動し、ナビゲーションペインから 「Query editor（クエリエディタを起動）」 を選択します。 「Saved queries（保存したクエリ）」 タブを開き、 qs_usage_cur_vw_query という名前のクエリを選択してください。 クエリエディタで 「Run（実行）」 をクリックして、ビューを作成します。 クエリの実行が完了すると、 qs_usage_cur_vw という名前のビューが Athena に作成されます。このビューには、QuickSight ダッシュボードでの分析に必要な AWS CUR データがすべて含まれており、詳細な利用状況の把握に役立ちます。 Athena へのアクセスを有効にし、QuickSight に対して S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} へのアクセス権限を付与するため、以下の手順を実施します。 QuickSight コンソールにアクセスし、画面右上に表示されているユーザー名をクリックします。 ドロップダウンメニューから 「Manage QuickSight (QuickSight を管理)」 を選択します。 左側のナビゲーションペインから 「Security & Permissions（セキュリティとアクセス許可）」 をクリックします。 「管理」 をクリックし、Amazon Athena のチェックボックスを有効にします。 同様に 「Amazon S3」 をクリックし、CURが格納されているバケットにチェックを入れます。 ステップ3: QuickSight データセットとダッシュボードをデプロイする 3つ目の CloudFormation スタックでは、QuickSight に以下 3つのデータセットを作成します。 qs_usage_cur_vw ：Athena のビューに対応するデータセット qs_users_info ：Athena のテーブルに対応するデータセット qs-usage-custom-inactive ：Athena のテーブルとビューを参照して、QuickSight アカウント内の非アクティブなユーザーを特定するためのデータセット このデータセットの作成には、以下のようなサンプルクエリが使用されています。 SELECT u.userarn,u.username,u.useremail,u.userrole,u.useridentitytype,u.usernamespace,CAST(COALESCE(a.last_login, DATE '2020-01-01') AS DATE) as last_login FROM "AwsDataCatalog"."qs-usage-db"."qs_users_info" u LEFT JOIN ( SELECT line_item_resource_id, MAX(date_parse(month_line_item_usage_start_date, '%Y-%m-%d')) as last_login FROM "AwsDataCatalog"."qs-usage-db"."qs_usage_cur_vw" WHERE ( product_group = 'Reader Usage' OR product_group = 'Reader Subscription' ) AND LOWER(line_item_resource_id) NOT LIKE '%anonymous%' GROUP BY line_item_resource_id ) a ON u.userarn = a.line_item_resource_id WHERE u.userrole = 'READER' そして、3つのデータセットをもとに、テンプレートが 「QuickSight Usage Analytics Dashboard」 を自動的に作成し、リーダーアカウントのアクティビティなどを可視化します。このダッシュボードを活用することで、QuickSight アカウント内で非アクティブな リーダーアカウントを特定し、ライセンスの最適化などに役立てることができます。 以下、 「Launch Stack」 をクリックして、QuickSight のデータセットとダッシュボードをデプロイしてください。 その際、QuickSight 管理者ユーザーの ARNを以下の形式で指定する必要があります。 arn:aws:quicksight:us-east-1:12345678910:user/default/admin/xyz ※上記の例にある AWS アカウントID（12345678910）、リージョン（us-east-1）、および ユーザー名（admin/xyz） はダミー（プレースホルダー）です。ご自身の環境に合わせた実際の値に置き換えて入力してください。 3つのスタックのデプロイがすべて正常に完了すると、SPICE データセットの更新スケジュールをお好みの頻度で設定できるようになります。また、作成されたダッシュボードを、組織内の適切なメンバーと共有することも可能です。これにより、常に最新の利用状況を基にした分析や意思決定が行えるようになります。 このダッシュボードには 5つのシートがあり、シームレスに画面を行き来できる構成になっています。各シートをクリックするだけで、簡単に別のビューへ移動できます。 以下の図に示されているダッシュボードビューでは、QuickSight アカウント全体の主要な KPI（重要業績評価指標） や利用状況の概要を把握できます。 以下の図に示されているダッシュボードビューでは、リーダーセッションの利用状況（キャパシティ使用量）に関する詳細や、すべてのリンク済みアカウントのリソース情報を確認することができます。 以下の図に示されているダッシュボードビューでは、アラート、レポート機能、SPICE、PROユーザーなどの各種機能の利用状況を、より詳細に確認できます。さらに、すべてのリンク済みアカウントにおける該当リソースの情報もあわせて表示されます。 以下の図に示されているダッシュボードビューでは、QuickSight アカウント内に存在するすべてのユーザー一覧が表示されます。 以下の図に示されているダッシュボードビューでは、すべてのリンク済みアカウントにおける、アクティブな登録済みリーダーユーザーの情報が表示されます。この情報をもとに、非アクティブなリーダーアカウントの一覧が自動的に抽出され、必要に応じてどのユーザーを削除すべきか判断する際の参考として活用できます。 クリーンアップ このソリューションで作成されたすべてのリソースを削除する手順について 1. ダッシュボードスタックの削除 QuickSight の各種リソースをデプロイした CloudFormation スタック（デフォルト名は qs-usage-dashboard-stack 、またはデプロイ時に指定したカスタム名）を削除します。これにより、以下が削除されます。 QuickSight ダッシュボード: QuickSight Usage Analytics Dashboard 3つのデータセット: qs-usage-custom-inactive 、 qs-usage-cur-vw 、 qs-users-info QuickSight のテーマ: qs-usage-theme QuickSight の Athena データソース接続: qs-usage 2. Athena オブジェクトのスタックの削除 Athena リソースを作成した CloudFormation スタック（デフォルト名は qs-usage-athena-stack またはカスタム名）を削除します。これにより、以下のリソースが削除されます。 保存済みクエリ: qs_usage_cur_vw_query テーブル: qs_users_info ビュー: qs_usage_cur_vw Athena データベース: qs-usage-db 3. AWS Glue ジョブと S3 バケットのスタックの削除 まず、S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} の中身が空であることを確認してください。その後、Glue ジョブなどの基盤インフラを作成した CloudFormation スタック（デフォルト名は qs-usage-glue-stack またはカスタム名）を削除します。これにより、以下が削除されます。 Glue ジョブ qs-usage-users-info Glue トリガー QuickSightUsersExtractDailyTrigger IAM ロール qs-usage-glue-role-{AWS::AccountId}-{AWS::Region} S3 バケット qs-usage-{AWS::AccountId}-{AWS::Region} ※このクリーンアップ作業は、既存の AWS CUR の設定や QuickSight サブスクリプションには影響しません。 まとめ 本投稿では、Amazon QuickSight の利用状況を可視化し、特にリーダーアカウントに関するコスト最適化方法をご紹介しました。 コストと使用状況レポート (CUR) のデータを活用し、データ収集のプロセスを自動化することで、以下が可能になります。 リーダーの利用状況を把握し、活用されていないアカウントを特定 SPICE、アラート、Amazon Q、ピクセルパーフェクトレポートなど、QuickSight 機能ごとの使用傾向を分析 提供されている CloudFormation テンプレートを使えば、容易に本ソリューションを環境にデプロイでき、QuickSight の利用状況を 一元的に可視化 できるようになります。BI の導入規模が拡大する中で、こうした自動化された使用状況分析ツールは、コスト効率を保つためにますます重要な存在となってきています。 ご質問やご意見があれば、ぜひコメントをお寄せください。 また、さらに情報交換や質問をしたい場合は、 QuickSight コミュニティ もぜひご活用ください。 本ブログは プロフェッショナルサービス本部の 西澤 が翻訳しました。

本稿は、株式会社みずほフィナンシャルグループ／みずほリサーチ＆テクノロジーズ株式会社 服部 純一氏、畑山 洋平氏、浅香 樹氏、株式会社みずほフィナンシャルグループ 島浦 紳吾氏、翁 恒氏によって寄稿いただきました。 はじめに 企業のデジタル化が進み、クラウド活用の拡大を含め多くの業種で IT 予算、投資意欲が高まっています。 「企業 IT 動向調査報告書2024」によると、2023年度の IT 予算 DI 値(注1)は2011年度以降で最高値となっています。 IT 予算の重点領域として「セキュリティ強化」は「業務プロセスの効率化」に次いで高くなっていること、2022年度から割合を伸ばしていることからも企業のセキュリティに対する意識は高まっていると考えられます。 (注1) Diffusion Index ： IT 予算を「増加する」割合から「減少する」割合を差し引いた値 パブリッククラウドは、いまやビジネスに欠かせない IT インフラとなっています。アマゾン ウェブ サービス (AWS) は、俊敏性が高く、従量課金制で最先端のサービスを利用可能なため、アイデアをすぐにビジネスとして実現できイノベーションを加速できます。一方で、利便性が高いため、利用者は自身の管理領域の設定ミスなどによる情報漏洩などのリスクがあります。 そのため、責任共有モデルを正しく理解し、セキュリティ統制と対策を行う必要があります。 本ブログでは、AWS サービス利用時のセキュリティリスク評価とその対策として予防的統制と発見的統制の手法について紹介したいと思います。 AWS サービス利用時のセキュリティリスク評価の必要性と評価手法 パブリッククラウドは最先端のサービスを利用できる俊敏性が高い IT インフラです。一方で、設定や権限管理の不備に起因する事例も存在しています。 AWS を活用するうえで、責任共有モデルを前提としたセキュリティ・リスクマネジメントは不可欠となります。 <みずほ>では、 AWS サービスを安心・安全に活用するためのプロセスとして、(1) サービスを知る（ AWS ドキュメントや AWS Black Belt Online Seminar からサービスを把握する）、(2) リスクを知る（機密性・完全性・可用性それぞれの観点で整理する）、(3) 対策を練る（AWS Identity and Access Management (IAM) による権限管理や VPC エンドポイントでの通信経路の特定等）、(4) 対策を施す（予防的統制・発見的統制）を実施しています。 AWS サービス利用時のセキュリティリスク評価にあたり「利用シナリオと接続経路」、「セキュリティクライテリア」、「IAM アクション評価」を作成しています。 「利用シナリオと接続経路」は AWS サービスの使われ方を想定し、それぞれの利用者や関連するサービス、外部システムとの通信経路と通信方向を図示したものです。 「セキュリティクライテリア」は主要なリスクシナリオをベースにクラウド固有のリスクについて、AWS で実施可能な対策を整理したものです。機密性、完全性、可用性を観点として、セキュリティリスクに関する7評価観点19対策分類を定め、評価対象の AWS サービスで利用可能な予防的統制と発見的統制の情報を整理しています。 「IAM アクション評価」では、AWS サービスの IAM アクションを洗い出し、IAM アクションごとにセキュリティリスクを評価し、予防的統制と発見的統制を整理しています。 セキュリティリスク評価事例： AWS Lambda AWS ユーザーの多くの方が利用する AWS Lambda を題材にセキュリティリスク評価の手法をご紹介したいと思います。 利用シナリオと接続経路 金融機関は個人情報や決済情報など、多くの機密データを扱っています。想定外のインターネット経由の接続経路（例：外部 AWS アカウントからの不正なリモートアクセス経路など）が存在すると、不正アクセスによる機密情報の漏洩などにより業務停止を引き起こし、結果として顧客への影響や事業運営全体に深刻なリスクをもたらす可能性があります。 本観点では、AWS サービスの通信経路を洗い出し、どのようなアクセスがあるかを明らかにすることで、リスクとなる箇所を明確にすることを目的としています。 ネットワーク構成やセキュリティ要件を考慮しながら、AWS サービスを利用する場面で具体的な指針を示しています。 AWS Lambda では、 ①Lambda 関数の管理 と ②Lambda 関数の実行 という2つの主要な観点に基づいて構成されています。 以下は、そのうちの ①Lambda 関数の管理 の例です。 シナリオ番号 通信元 通信先 通信の目的 通信経路 考慮事項 1-① AWS 管理ユーザー AWS Lambda サービス Lambda 関数の管理 インターネット または AWS Direct Connect 経由で VPC エンドポイント経由のアクセス。 Lambda は VPC エンドポイントに対応しており、インターネット( Public )・VPC 内どちらのアクセスにも対応 1-② AWS サービス AWS Lambda サービス Lambda 関数の管理 AWS CodeBuild などの 各種 AWS サービスから Lambda サービスエンドポイントにアクセス。 AWS サービスによって、VPC エンドポイント経由で Lambda API エンドポイントにアクセス可否は異なる (例: CodeBuild は設定によってはビルド内処理から VPC 内リソースにアクセス可能、など) 1-③ ユーザー VPC AWS Lambda サービス Lambda 関数の管理 ユーザー VPC から VPC エンドポイント経由で Lambda サービスエンドポイントにアクセス。 同上 このように、通信元 / 通信先 / 通信の目的 / 通信経路 をもとに整理し可視化することで、アクセスルートに応じた権限や各種設定の具体的な考慮点を明らかにしています。 セキュリティクライテリア 本観点では、AWS サービスを運用する際に懸念されるセキュリティリスクを洗い出し、それに対する対策を整理することで、セキュリティ要件を満たしたシステム設計・運用に繋げることを目的としています。 以下の7評価観点・19対策分類で整理し、「予防的統制」と「発見的統制」の両側面から、具体的な設計・運用レベルでの対策を確認できるような構成としています。 No 大分類 評価観点 対策 1 機密性 (1) ポリシー/設定による保護 リソースベースポリシーによる保護 2 アイデンティティベースポリシーによる保護 3 サービスコントロールポリシー ( SCP )による保護 4 その他機能による保護 5 (2) 暗号化による保護 主データの暗号化 6 ログの暗号化 7 通信の暗号化 8 その他リソースの暗号化 9 (3) 閉域網での隔離による保護 VPC 機能による保護 10 VPC エンドポイント の保護 11 (4) サービス間連携機能の対策可否 リソース共有への対策 12 リソースコピーへの対策 13 データ連携への対策 14 独⾃ NW 経路敷設への対策 15 完全性 (5) 操作ログ取得 AWS API の操作ログ取得の確認 16 AWS API 以外の操作ログ取得の確認 17 サービス及びリソース設定のトレーサビリティの確認 18 可用性 (6) データバックアップ ユーザデータのバックアップ取得の確認 19 (7) 耐障害性 リソース障害への対策機能の有無の確認 以下は、そのうちの No.4 その他機能による保護 の例です。 対策 確認の目的 サービス機能 予防的統制 発見的統制 その他機能による保護 単体でセキュリティリスクがあり、運用上使用しない設定や機能の不正利用をサービス独自の機能で禁止する。 AWS Signer および Lambda 側コード署名設定との協調による制限が可能 (※ ZIP パッケージにのみ利用可能, コンテナイメージは未サポート)属性ベースアクセス制御(ABAC)による Lambda 関数のアクセス制御が可能 Lambda での属性ベースのアクセスコントロールの使用 関数 URL を利用する場合、アイデンティティベースのポリシー、リソースベースのポリシー設定に加えて、IAM ベースの認証による制限が可能。また、異なるドメインから関数 URL が呼び出される場合は、CORS 設定による制御が可能。 コード署名設定により、確認された ZIP パッケージのコードに基づく Lambda 関数のみにデプロイを制限する。 役割の変更や追加が頻繁にある場合には、ABAC によるタグを使用して Lambda 関数へのアクセスを制御する。 関数 URL は、Lambda 関数単位でのアイデンティティベースのポリシー、リソースベースの設定に加えて、IAM ベースでの認証を設定する( IAM ベース認証設定により、呼び出し時の SignV4 の署名が必須となる)。 認証設定を行わない( AuthType が NONE )場合には、Lambda 関数にて全ての認証・セキュリティの実装を行う。 また、異なるドメインから関数 URL が呼び出される場合は、CORS 設定により、呼び出し元やメソッド種別を制限する。 <設定の変更を検知> AWS Config での Lambda 関数リソース変更、 AWS CloudTrail での関連リソース・ IAM に関する更新系 API 呼び出しを検知 <AWS Signer 利用時> AWS Signer の発行する CloudWatch メトリクスで署名違反での関数作成試行を検知 <関数URL利用時> CloudTrail での関数 URL に関する更新系API呼び出しを検知 チェックリストのように評価観点とそれに対する予防的統制と発見的統制による対策を明らかにしています。 IAM アクション評価 本観点では、その時点における AWS サービスの IAM アクションを洗い出し、それぞれの具体的なリスクと統制内容を明らかにすることで、実装に繋げることを目的としています。 IAM アクションごとに、以下の観点で想定リスクを洗い出し、それに対するリスク低減方法を確認できるような構成としています。 [A] 権限が不正に利⽤され、データ持ち出しや破壊されるリスク [B] データの保管場所や伝送経路が危殆化した際にデータの持ち出しや破壊されるリスク [C] IP-NW 経由でのデータ持ち出しや破壊されるリスク [D] クラウドサービスの機能が悪⽤され、データ持ち出しや破壊されるリスク [E] 不正な操作やアクセスが検出ないしは記録されないリスク [F] 障害時にデータが失われるリスク [G] 障害時に業務継続性が失われるリスク [H] 多額の請求が発生するリスク( Savings Plans の契約など) [I] その他のリスク 以下の画像は、 AWS Lambda の IAM アクション一部抜粋です。 例えば lambda:CreateEventSourceMapping と lambda:CreateFunction であれば以下のようにリスクと対策をまとめています。 lambda:CreateEventSourceMapping 想定されるリスク [H] 高頻度のイベント発生など大きくリソース使用量を増加させるようなイベントソースのマッピングが作成され、それを処理する Lambda 関数が実行された場合に、多額の請求が発生するリスクがある リスク低減方法の例 [H] アイデンティティベースとリソースベース、または SCP によるセキュリティ設定を適切に統制すると共に、CloudTrail などで変更を検知する 参考 イベントソースの実行ロールを最小限の権限設定とするなど、イベントソース側の権限も適切に統制する lambda:CreateFunction 想定されるリスク [D] VPC アクセスを指定せずに Lambda 関数を作成した場合、インターネットへアウトバウンド通信する経路が Lambda 関数を経由して生成されるリスクがある 想定されるリスク [G] VPC アクセスを指定して Lambda 関数を作成した際に、複数の AZ で構成されるように複数のサブネットを指定しなかった場合、AZ (単一)障害時に、業務継続性が失われるリスクがある ※不適切あるいは悪意のあるコードを含む Lambda 関数が作成されるリスクがある。詳細は右記「参考」を参照 リスク低減方法の例 [D] ドキュメント の例のように VPC に接続された関数の作成のみを許可する AWS Config で Lambda 関数リソース、VPC リソースへの変更を検出、CloudTrail での関連API呼び出しを検知する VPC 設定により Lambda 関数のアウトバウンド通信を制限し適切に監視・制御する リスク低減方法の例 [G] VPC Lambda とする場合、複数のAZで構成されるように複数のサブネットを指定する サービスヘルスダッシュボードで、サービスの状態を確認する アプリケーションとしてのログ、CloudWatch メトリクスをモニタリングする 参考 不適切あるいは悪意のあるコードを含む Lambda 関数が作成され、その関数が実行された場合、以下のようなリスクが想定される 関数ハンドラにて、AWS リソースを使って、ユーザー所有データを破壊あるいは AWS 内外の不適切な場所に送信し持ち出す [A][B][C] Lambda 関数あるいは依存する Lambda レイヤー内のライブラリやコードにセキュリティ脆弱性を含むレイヤーバージョンが作成された場合、これを悪用されてデータの持ち出しや破壊されるリスクがある [D] 大きくリソース使用量を増加させ、多額の請求を発生させる[H] 関数ハンドラにて、外部サイトへの攻撃や犯罪行為などを行い、意図せず犯罪に巻き込まれ、法的責任を問われ、信用失墜や損害賠償請求などにより、ビジネスへの影響が生じる[I] <リスク低減方法の例> [共通] アイデンティティベースとリソースベース、または SCP によるセキュリティ設定を適切に統制すると共に、CloudTrail などで変更を検知する CI/CD パイプラインを導入するなど、第三者が介入できないコード作成、デプロイ自動化と承認のプロセスを確立し、アプリケーションの適切な開発・運用管理を行う 関数作成の IAM ポリシーの条件として、特定の署名コード設定付き関数しか作成できないよう制限する（ 参考ドキュメント ） Inspector を利用して、ワークロードに作成・変更時(初回作成、更新、CVE 公開)があったときに自動的に再スキャンするよう設定する[D] このように、IAM アクションごとにリスクの有無を整理することで、具体的な実装方法を明らかにしています。 セキュリティリスク評価による効果 セキュリティリスクの洗い出しやその対策を整理することで、各サービス利用時のリスク評価が可能になります。リスクとなる点は予防的統制による制限、発見的統制による検知の仕組みを導入します。一方で、相対的にリスクが低く評価される点については、権限移譲による利便性を高めることができ、より安心・安全にサービスを利用することが可能になります。 <みずほ>ではサービスごとのリスク評価に際して、本取り組みの内容をベースとし、セキュリティ基準を踏まえた評価を盛り込むことでサービスの評価として活用しています。また、実機検証や AWS サポートを活用し、セキュリティリスク評価と実装の精度を高める取り組みを取り入れています。 <みずほ>ではサービス評価のフェーズでは、アーキテクトだけでなくリスク管理部門といった2線部門(注2)とも連携を取りながら進めています。また、サービス評価完了後はシステムを所管するユーザー部門が設計・構築において参照したいといった要望挙がるなど、それぞれ異なる視点やニーズを持っています。本取り組みの成果物は、全員が共通理解を持つためのドキュメントとしても活用しています。 (注2)リスク管理・コンプライアンス所管部署：1線が行う自律的な統制活動を監視（モニタリング）・測定・評価するとともに、リスク管理・コンプライアンスの統制に係る基本方針等を策定・推進する責任を有する。 取り組み： AWS サービスリスク評価ワーキンググループについて AWS サービス利用時のセキュリティリスク評価を行うワーキンググループとして、現在11社、9金融グループ共同で評価する取り組み（セキュリティリスク評価ワーキンググループ）を行っています。 これまでの活動実績として2020年7月の第1回目以降、継続的に開催しており、2025年2月末時点で88回のワーキンググループを開催し、45の AWS サービス・シリーズについてリスク評価を実施してきました。また、AWS サービス利用時のリスク評価以外に、参加企業間での事例共有をテーマとした情報交換会も定期的に実施しています。 ワーキンググループでは、セキュリティリスク評価対象サービスについて参加企業各社のユースケースを共有し、AWS で「利用シナリオと接続経路」と「セキュリティクライテリア」を作成した後、参加企業各社がレビューを行います。参加企業によるレビューにより成果物をブラッシュアップし、質疑応答によりサービス仕様の理解を深めています。 セキュリティリスク評価について取り組み始めた頃は、これら全てを<みずほ>自身で実施していたため、多大な工数・期間を要していました。それが本取り組みにより、セキュリティリスク評価におけるベース部分の体力削減ができると共に、網羅性の観点でも高めることでき、より効率的にサービス評価が可能となりました。 AWS サービスリスク評価ワーキンググループの活用 ワーキンググループは、金融機関各社が個別に行っていたAWSサービス利用時のリスク評価を共同で実施することで、作業負荷の軽減と評価の網羅性向上を図る取り組みです。 これからサービス利用時のセキュリティリスク評価を行う参加企業ではリファレンスとして、既にセキュリティリスク評価が済んでいる企業では、評価の観点や判断軸を客観的に捉えることが出来るとの声があります。 ワーキンググループでは事例共有の場を設けており、自動化ツールや標準化の仕組み、IAM 設定などの具体的ノウハウを共有する場を定期的に設けています。AWS CloudFormation や AWS Service Catalog 等の活用事例、クロスアカウント間でのデータ連携など、各社の実運用で培った知見が共有されることで、セキュリティ水準の向上にも繋がっています。 まとめ AWS を含むパブリッククラウドは最先端のサービスを利用できる俊敏性が高い IT インフラです。一方で、設定ミスなどによる情報漏洩などのリスクも存在するため、責任共有モデルを正しく理解しセキュリティ統制と対策を行う必要があります。 金融機関でのセキュリティリスク評価共同化ワーキンググループのような手法は、多数の AWS サービス評価を効率的に進め、網羅性を高める有効な取り組みとして機能しています。 また、セキュリティリスク評価ワーキンググループの活動にご興味がありましたら、AWS 担当営業経由でご連絡ください。 免責文言 本稿は情報提供のみを目的として作成されたものであり、取引の勧誘を目的としたものではありません。本稿は、株式会社みずほフィナンシャルグループ／みずほリサーチ＆テクノロジーズ株式会社が信頼できると判断した各種データに基づき作成されておりますが、その正確性、確実性を保証するものではありません。本稿のご利用に際しては、ご自身の判断にてなされますようお願い申し上げます。また、本稿に記載された内容は予告なしに変更されることもあります。 執筆者情報 みずほリサーチ＆テクノロジーズ株式会社 先端技術研究部　技術企画チーム 株式会社みずほフィナンシャルグループ IT・システム統括部 クラウド統括チーム 服部 純一 みずほリサーチ＆テクノロジーズ株式会社 先端技術研究部　技術企画チーム 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 畑山 洋平 みずほリサーチ＆テクノロジーズ株式会社 先端技術研究部　技術企画チーム 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 浅香 樹 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 島浦 紳吾 株式会社みずほフィナンシャルグループ IT・システム統括部　クラウド統括チーム 翁 恒 参考情報 AWS Lambda 開発者ガイド AWS Lambda APIリファレンス

3 月 14 日に開催された第 5 回 AWS Pi Day に参加してくださった皆様、ありがとうございました。2021 年から開催されている AWS Pi Day は、データ管理、分析、AI におけるクラウドテクノロジーの変革のパワーをハイライトする主要なイベントへと成長し、2025 年は Amazon Simple Storage Service (Amazon S3) のリリース 15 周年を記念するイベントとなりました。 2025 年のバーチャルイベントでは、 Amazon Web Services (AWS) の製品チームとの綿密なディスカッションで分析と AI ワークロードの向けの堅牢なデータ基盤の構築を支援するための継続的なイノベーションが紹介されました。 ライブイベントを見逃してしまったとしても心配ありません。 イベントページで すべてのコンテンツにオンデマンドでアクセス できます。データレイクハウスの開発、AI モデルのトレーニング、生成 AI アプリケーションの作成、分析ワークロードの最適化など、進めている取り組みがどのようなものであっても、共有されたインサイトはデータの価値を最大化するのに役立ちます。 3 月 10 日週のリリース 3 月 10 日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 Amazon Bedrock がマルチエージェントコラボレーションをサポートするようになりました – Amazon Bedrock でのマルチエージェントコラボレーションを利用して、スーパーバイザーエージェントのガイダンスに従って、通信と調整を行う特殊なエージェントのネットワークを構築できます。連携して複雑なマルチステップワークフローを効率的に実行する AI エージェントのネットワークを構築、デプロイ、管理することができます。 Amazon Bedrock でフルマネージド型 DeepSeek-R1 モデルを利用できるようになりました – AWS は DeepSeek-R1 をフルマネージド型の一般提供モデルとして提供した最初のクラウドサービスプロバイダー (CSP) です。Amazon Bedrock で、このフルマネージド型サービスを通して、単一の API で DeepSeek-R1 の機能を生成 AI アプリケーションに使用できます。 Amazon SageMaker Unified Studio の一般公開が開始されました – 組織のすべてのデータを検索してアクセスし、特定のニーズに最適なツールを使用してデータで作業できる単一のデータおよび AI 開発環境として Amazon SageMaker Unified Studio を使用できるようになりました。簡素化された新しいアクセス許可管理により、既存の AWS リソースを統合スタジオで簡単に利用できます。データやモデルから生成 AI アプリケーションまで、チームのコラボレーションで分析と AI アーティファクトの安全な構築と共有を行いながら、組織のデータと AI アセットの検索、アクセス、クエリが可能になります。 Amazon SageMaker Unified Studio 内での Amazon Bedrock の機能の一般提供が開始されました – SageMaker Unified Studio で、Amazon Bedrock の一部の機能が SageMaker で利用できるようになります。 基盤モデル (FM) と、 Amazon Bedrock のナレッジベース 、 Amazon Bedrock ガードレール 、 Amazon Bedrock エージェント 、 Amazon Bedrock Flows などの高度な機能を使用して、迅速に生成 AI アプリケーションのプロトタイプ作成、カスタマイズ、共有を行って、要件と責任ある AI ガイドラインに沿ったカスタムソリューションを SageMaker 内で作成できるようになりました。 Amazon S3 Tables と Amazon SageMaker Lakehouse の統合の一般提供が開始されました – Amazon S3 Tables が Amazon SageMaker Lakehouse とシームレスに統合するようになったので、S3 データレイク、 Amazon Redshift データウェアハウス、サードパーティデータソースのデータでの S3 Tables のクエリと結合が簡単になりました。S3 Tables は、Apache Iceberg のサポートが組み込まれた初のクラウドオブジェクトストアを提供します。 Amazon S3 Tables で、Amazon Athena を使用して S3 コンソールからテーブルの作成とクエリの操作を直接行うことができるようになりました – Amazon S3 Tables で、S3 コンソールでのテーブルの作成とクエリのサポートが追加されました。この新しい機能では、Amazon Athena を使用して S3 コンソールからテーブルの作成、データの入力、クエリの実行を直接行うことができるようになるので、使用の開始と S3 テーブルバケット内のデータ分析がより簡単になります。 Amazon S3 での S3 オブジェクトのタグ付け料金が 35% 引き下げられました – Amazon S3 では、すべての AWS リージョンで S3 オブジェクトのタグ付け料金を 35% 引き下げられ、1 か月あたり 10,000 タグあたりの料金が 0.0065 USD になりました。オブジェクトタグは S3 オブジェクトに適用されるキーと値のペアで、オブジェクトの存続期間中いつでも作成、更新、削除できます。 Visual Studio Code で Serverless Land パターンが利用可能になりました – Serverless Land の豊富なアプリケーションパターンライブラリが Visual Studio Code (VS Code) IDE で直接利用できるようになり、開発者はサーバーレスアプリケーションを簡単に構築できるようになりました。この統合により、ビルド済みのサーバーレスパターンを VS Code IDE で直接参照、検索、実装できるようになるため、サーバーレスアーキテクチャを構築する際に開発環境と外部リソースの間での切り替えを行う必要がなくなります。 Amplify ホスティングが Skew Protection のサポートを発表しました – AWS Amplify ホスティング で、複数の デプロイにわたってバージョンの一貫性を保証する機能である Skew Protection が提供されるようになりました。この機能により、フロントエンドのリクエストは常に正しいサーバーバックエンドバージョンにルーティングされるため、バージョンの歪みがなくなり、デプロイの信頼性が向上します。 Amazon Route 53 トラフィックフローで、DNS ポリシーの編集を改善するための新しいビジュアルエディタが導入されました – Amazon Route 53 トラフィックフロー で、DNS トラフィックポリシーの編集を改善するためのユーザーインターフェイスが強化されました。今回のリリースでは、ビジュアルエディタの新機能を使用して、ユーザーとエンドポイント間のトラフィックのルーティング方法をより簡単に理解し、変更できるようになりました。 community.aws からの情報 community.aws からの私のお気に入りの記事をいくつかご紹介します。 AWS ビルダー ID を作成 して、有用な情報を共有し、他のビルダーとつながりましょう。ビルダー ID はユニバーサルログイン認証情報です。これにより、ユーザーは、 AWS マネジメントコンソール だけでなく、600 を超える無料トレーニングコース、コミュニティ機能、 Amazon Q Developer などのデベロッパーツールを始めとする AWS のツールやリソースにアクセスできます。 Seamless SQL Server Recovery on EC2 with AWS Systems Manager ( Greg Vinton ) – このガイドでは、 AWSEC2-RestoreSqlServerDatabaseWithVss 自動化ランブックを使用して、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上の Microsoft SQL Server データベースを復元する方法について説明します。 Secure Deployment Strategies in Amazon EKS with Azure DevOps ( Abhishek Nanda ) – Azure DevOps を使用して、コンテナ化されたアプリケーションをビルドして Amazon Elastic Kubernetes Service (Amazon EKS) にデプロイします。 Connect Your Favorite LLM Client to Bedrock ( Qinjie Zhang ) – 大規模言語モデル (LLM) モデルの使用を簡素化するために、 MSTY 、 Chatbox AI 、 LM Studio などのデスクトップアプリケーションを使用するのが一般的です。このブログでは、お気に入りのローカル LLM クライアントを Amazon Bedrock に接続する方法をステップごとに説明します。 From PHP to Python with the help of Amazon Q Developer ( Ricardo Sueiras ) – このブログ記事では、Ricardo が Amazon Q Developer CLI を使用して、あるプログラミング言語から別のプログラミング言語にコードをリファクタリングする方法を紹介します。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーが主導する技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とする、コミュニティ主導のカンファレンスにご参加ください: ミラノ (イタリア) (4 月 2 日)、 ベイエリア – セキュリティエディション (4 月 4 日)、 ティミショアラ (ルーマニア) (4 月 10 日)、 プラハ (チェコ共和国) (4 月 29 日)。 AWS Innovate: 生成 AI + データ – 生成 AI とデータイノベーションに焦点を当て、ラテンアメリカで 4 月 8 日に開催される無料のオンラインカンファレンスにご参加ください。 AWS Summits – AWS Summit の季節が近づいてきました! クラウドコンピューティングコミュニティがつながり、コラボレーションして、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市のイベントにご登録ください: パリ (4 月 9 日)、 アムステルダム (4 月 16 日)、 ロンドン (4 月 30 日)、 ポーランド (5 月 5 日)。 AWS re:Inforce (6 月 16～18 日) – AWS クラウドセキュリティに関するあらゆることに焦点を当てた毎年恒例の学習イベントがフィラデルフィア州ペンシルバニアで開催されます。登録の受付は 3 月に開始されます。5,000 人を超えるセキュリティビルダーやリーダーとともにご参加ください。 AWS DevDays は、デベロッパーがクラウドコンピューティングの極めてホットなトピックのいくつかについて学べる無料の技術イベントです。DevDays では、ハンズオンワークショップ、技術セッション、ライブデモ、AWS の技術エキスパートや同僚とのネットワーキングが提供されます。  登録してオンデマンドで AWS DevDays セッションにアクセス してください。 3 月 17 日週のニュースは以上です。3 月 24 日週の月曜日に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Prasad この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

こんにちは。元自動車メーカー生産技術出身でAWSへ転身した、変わり種ソリューションアーキテクトの岩根です。 さて、ものづくりの DX が叫ばれて久しい昨今、「データドリブンな意思決定」という言葉を聞く機会も増えていると思います。AWS の製造業に携わるメンバーでも、お客様とデータドリブンについてディスカッションすることが多いです。私個人としてもそれはテーマとなっており、例えば 「 Amazon QuickSight で製造サプライチェーンのデータドリブンな意思決定を実現する 」でご紹介したような可視化の考え方や、「 製造現場でデータドリブンとクラフトマンシップは交わるのか？ 」で考察したような実装のためのアプローチなど、至らないながらも様々な発信をしてきました。 今回は原点に立ち戻って、データドリブンな意思決定の進め方について考察してみたいと思います。 製造業のデータは宝の山 こちら の調査 によれば、製造業は年間約 1,812 ペタバイト(PB)のデータを生み出しており、通信、金融、小売業などほかの産業よりも多いことがわかっています。また、過去 20 年間のデジタル情報の急増により意思決定プロセスが複雑化したため、製造業者はデータパターンの発見や従来予期できなかった問題への対応に、デジタル技術を活用して情報をより効率的に処理、活用しようとしています。総じて言えることは、データ活用が十分に進んでいない製造事業者は、膨大なデータという宝の山の上にいると言えます。一方で、同じ調査の中の中国を対象にした調査によると、データ活用の一環としての AI 活用において、91 %のプロジェクトが期待通りの効果や投資額を達成できていないことを伝えています。このことから、製造業が抱える膨大なデータは、ビジネススピードの飛躍的改善による競争力強化につながるポテンシャルがあるものの、その手段として様々な意思決定をデータドリブンに変革することは決して簡単ではなく、一朝一夕にはなし得ないものであると言えます。 データドリブンの「鶏・卵問題」 製造業において、データドリブンな意思決定を、会社の各階層、すなわち製造現場だけでなく、工場などの現場マネジメント層、経営層に至るまでで行うためには、必要なデータを一元化し、分析・可視化できる環境を整える必要があります。ここではそれを「データ基盤」と呼びます。ここでくせ者なのが「必要なデータを」という部分です。必要かどうかは何によって決まるのでしょう？そう、「ユースケース」です。では以下のうち、アプローチとして正しいのはどちらでしょうか？ どのようなデータが「必要なデータ」かを網羅的に見積もることは不可能だから、取れるデータはすべて取ってデータ基盤を整え、あとからユースケースを考える 不要なデータを集めるリスクを最小化するために、ユースケースを網羅的に調査して、すべての必要なデータを洗い出してからデータ基盤を整える いじわるな質問ですが、どちらも「不正解」だと私は考えます。いつわりの「鶏・卵問題」に惑わされてしまっている状態とも言えます。また、製造業においては、何らかの実体のあるモノを作る、という特性上、計画駆動の文化が根強く、上記の罠にはまりやすいのではないかと思います。結果として、使われないデータ基盤が誕生したり、永遠に終わらない「検討」を続ける、といったアンチパターンに陥ってしまいます。ではどのように進めればよいのでしょうか？それは仮説検証プロセスを導入して、ユースケースを生み出す連鎖を設計することです。次の章で詳しく説明します。 仮説検証プロセスによるユースケースの連鎖 前項で述べたいじわるな質問の回答 1 と 2 は、どちらも共通する問題点があります。それは「正解」を「何かをする前から」探そうというアプローチで、ビッグバンスタートとも呼ばれるものです。何もかも決めきってからスタートする、というのは、その対象によっては正しいアプローチであることもあります。しかし「データドリブン経営」という、社内で誰も経験していない、未知のことをなすときに正しいアプローチとは言えません。一寸先は闇、ではないですが、やってみないとわからない、というのが現実ではないでしょうか。 仮説検証アプローチが必要 そこで、仮説検証プロセスを導入しましょう、というわけです。若干ニュアンスは異なりますが、敢えて製造業のみなさまに慣れ親しんだ言葉に置き換えると、PDCA サイクルを「小さく早く」回す、となります。そうする理由としては、「わからないことは学習しながら探っていく」「そうすることで失敗リスクを最小化する」ところにあります。具体的な手順は以下です。 達成したいビジネス成果とユースケースの仮説を立てる 仮説を検証するために、必要最小限のデータを取る 仮説の確からしさをユースケースで検証する 仮説を棄却するか、改善するかを決め、必要に応じて1に戻る 当たり前のように感じるかもしれませんが、各ステップに落とし穴があるのでステップごとに解説していきます。最初に達成したいビジネス成果の仮説を立てるのが非常に大事です。「手元に XXX のデータがある。何に使えるか考えよう」という発想だとうまくいかないことが多いです。その重要性は、一般にゴールデンサークル理論という思考プロセスと共通します。ゴールデンサークル理論でいう Why、How が、データ活用においてはビジネス成果とユースケースに該当することになります。 ゴールデンサークル理論 次に、2の「仮説を検証するために、必要最小限のデータを取る」ですが、ここで2つのハードルが待っています。1つ目はコストです。例えば PLC からのデータが必要であれば、PLC のデータを収集するためのエッジ装置や、ソフトウェアを導入する必要があります。ここでお勧めしたいアプローチが、 代替手段でコストをかけずに収集できないか？ ということです。詳しくは後述します。2つ目は、データのオーナーの理解と協力です。PLC の例でいうと、データのオーナーは製造現場となります。日本では、データ基盤を整えて事業部門に提供する役割を負うのは、DX 推進部門や IT 部門であることが多いです。製造現場から見ると遠い存在の部門から「XXX のデータを取らせてもらえないか？」と言われると、現場側から断られることも多いです。私は前職時代、実際に断られたことがあります。それは、製造現場の役割と密接に絡みます。製造現場は、製品を安定した品質で、安定した数量、安全に製造し続けることが使命です。そのため、変化に対して敏感になる傾向があります。実際、製造現場では「変化点管理」を徹底して、設備の消耗品交換などのメンテナンス履歴や原材料のロットなど、変化が宿命的に発生する事項に対して、後追いができるように記録することが当たり前に行われています。そんな中に、手ぶらで「XXX のデータを取らせてもらえないか？」と言っても、断られるのは道理というものです。現場の納得感を高めるために、1 の仮説「達成したいビジネス成果とユースケース」を訴えたとしても、現場現物を大事にする製造現場側の納得を得られないこともあるでしょう。 ただ、ここを乗り越えて「役に立つユースケース」がいくつか生まれてくると、様々な部門からアイディアが溢れてくる、「ユースケースの連鎖」が期待できます。過日の re:Invent reCap インダストリー編 製造業向けウェビナー で触れた Volkswagenの事例 は、まさにその連鎖が起きている状態だと思います。 泥臭いアプローチも有効となる 製造現場の納得と協力を得られないなか、仮説検証サイクルの「ひとまわし目」を回せるようにするにはどうしたら良いのでしょうか？DX 推進部門や IT 部門に所属していると、ソフトウェアや自動化されたプロセスでのデータ収集にとらわれがちです。それは最終的には正しいのですが、「仮説の確からしさを検証する」ことと「製造現場の理解・協力」を両立させるステージでは、それが最適とは限りません。前述した 代替手段でコストをかけずに収集できないか？ がここで登場します。製造現場の安定生産志向に不安を持たせないために、PLC のラダーに手を加えず、ネットワークにも繋がず、データを取る方法はないのでしょうか？実際に私が見聞きした事例をいくつか挙げます。 課題：複雑な自動機の組み合わせのラインにおける、ステーションごとの稼働状態の把握 対応：人が張り付いてストップウォッチにより計測し、稼働状況を把握 課題：異音検査工程の検査方法が、人による官能検査で非効率 対応：市販のマイクとラズパイを用いて簡易検査機を開発、効果測定 課題：数千秒のサイクルで多品種少量生産をするときの習熟期間をモデル化したい 対応：企画メンバーが自分たちで実際にトレーニング用の製品で繰り返し作業し、結果をモデル化 これらは私個人が見聞きした例ですが、いずれも製造現場の制御系統に手を加えることなく、仮説を検証できた例と言えます。製造現場との距離感はまちまちなので、ここまで極端な手段を選ぶ必要はないですが、「必ずしも電子的・自動的にデータが取れなくても良い」のは確かなのかなと思います。 仮説検証でデータ駆動を進めていくための産業データファブリック 最後に、仮説検証プロセスでデータドリブンを進めていくために必要な要素をお話します。それは、「スケーラビリティ（拡張可能性）」です。仮説検証で小さく始めて育てていく、というアプローチを採り、その結果狙い通りに「ユースケースの連鎖」が起きた場合に、それらを支えるバックボーンのスケーラビリティ不足はボトルネックになりかねません。そういったスケーラビリティの問題や、サイロ化されたデータを統合する課題を解決するために AWS が提唱しているアーキテクチャフレームワークが、産業データファブリック（IDF）です。細かくは こちらのリンク や ブログ記事 に譲りますが、仮説検証のサイクルが回り始めた暁には、このフレームワークを元にスケーラブルな基盤を構築できます。AWS での中核となるサービスは AWS IoT SiteWise で、エッジからの様々な産業用プロトコルによるデータ取り込みに対応しています。また、 パートナーソリューション も増えてきています。これらも参考にしていただき、スケーラブルな仕組みを、仮説検証が何サイクルか回り、役立つユースケースが社内で認知されてきたタイミング（＝予算がつけられるタイミング）で検討するとよいかと思います。 産業データファブリック まとめ 本ブログでは、データドリブンを進めるために重要な要素として、以下を挙げました。 仮説検証プロセスを採用すること ゴールデンサークル理論に則って、Why から始めること ユースケースの連鎖に備えて、スケーラブルなアーキテクチャを早い段階で導入すること 既にデータ基盤を整え始めているみなさまには、ブログの表題である「その製造データ、ユースケースは決まってますか？」に対して「No」や「わからない」とならないか点検してみると、新たな気づきがあるかも知れません。 アポロ 11 号のアームストロング船長は、月面に降り立ったとき「これはひとりの人間にとっては小さな一歩だが、人類にとっては偉大な一歩である」と名言を残しました。ぜひともみなさんが、自社のものづくり DX に向けて偉大な一歩目を踏み出すことを願います。 著者紹介 岩根 義忠 (Yoshitada Iwane) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 自動車メーカーの生産技術開発部門を経て AWS Japan に入社し、エンタープライズ事業本部でソリューションアーキテクトとして活動中。前職でソフトウェア開発のアジャイル/スクラムに出逢い、自部門での導入やスケールを主導したことにより、モダンな開発手法やクラウドに目覚める。 趣味はバイクの他にギター演奏、自分の部屋の飾り付けなど。二児の父だが二人とも実家を出ているため、現在は妻と気楽な二人暮らし。栃木県那須塩原市在住。  

北半球の天候が良くなるにつれて、学びやつながりの機会が増えます。3 月 10 日週、私はサンフランシスコにいました。 AWS GenAI Loft での Nova Networking Night でお会いしましょう。そこでは、ライブデモや実際の実装を通じて、 Amazon Nova 基盤モデル (FM) の世界を詳しく見ていきます。 AWS Pi Day は、今では毎年恒例のイベントとなっています。このイベントは、2021 年に Amazon S3 の 15 周年を記念して始まりました。今年は、統合されたシームレスなエクスペリエンスを実現するためにデータ基盤を構築し、分析と AI ワークロードのためのデータを管理および使用する方法について、AWS の製品チームと詳細に議論します。 オンラインで参加して、ハンズオンデモを通じて最新のイノベーションについて学びましょう 。また、インタラクティブなライブストリームではご質問いただくことも可能です。 3 月 3 日週のリリース 3 月 3 日週も忙しかったですね。私が注目したリリースをいくつかご紹介します。 Amazon Q Developer – 強化されたエージェントを Amazon Q コマンドラインインターフェイス (CLI) 内で使用できるようになりました。これにより、より動的な会話が可能になり、ローカルでのファイルの読み取りと書き込み、AWS リソースのクエリ、コードの作成が容易になります。この強化された CLI エージェントは、 Anthropic のこれまでで最もインテリジェントなモデルである Claude 3.7 Sonnet を使用します。 このエージェントコーディングエクスペリエンスの詳細と、その試用方法についてお読みください 。Nathan Peck による、 Amazon Q CLI の新機能のビジュアルデモ はこちらです。 Amazon Q Business – 音声と動画のデータの取り込みがサポート されるようになりました。この機能は、マルチメディアコンテンツを、テキストベースのドキュメントと同程度に検索可能でアクセスしやすくすることで、情報検索を効率化し、知識の共有を強化して、意思決定プロセスを改善します。 Amazon Bedrock – Bedrock Data Automation の一般提供が開始され、ドキュメント、画像、動画、音声ファイルなどの非構造化マルチモーダルコンテンツからの有益なインサイトの生成を自動化できるようになりました。 詳細とコード例については、私のブログ記事をご覧ください 。 Amazon Bedrock ナレッジベース の GraphRAG のサポートの一般提供も開始されました 。GraphRAG は、グラフデータを組み込むことで 検索拡張生成 (RAG) を強化し、データ内の関係を活用してより包括的で関連性が高く説明可能な応答を提供して、生成 AI アプリケーションが情報を取得および合成する方法を改善する機能です。 Amazon Nova – Amazon Nova Pro 基盤モデル は、 Amazon Bedrock 上のプレビューでレイテンシー最適化推論をサポートするようになりました。これにより、生成 AI アプリケーションの応答時間の短縮と応答性の向上を実現できます。 AWS Step Functions – キャンバス上でワークフローを作成するために使用できるビジュアルビルダーである Workflow Studio for VS Code が利用可能になりました。バックグラウンドでワークフロー定義を生成して、ローカル開発環境でワークフローを作成できます。 この強化されたローカル IDE エクスペリエンスの詳細についてお読みください。 AWS Lambda – VS Code で Amazon CloudWatch Logs Live Tail をサポート するようになりました。当社は以前、Lambda ログをリアルタイムで表示および分析する方法を簡素化するために、 Lambda コンソールで Live Tail のサポートを導入しました 。現在では、VS Code 開発環境内にとどまりながら、Lambda 関数のログをリアルタイムでモニタリングできるようにもなりました。 AWS Amplify – Amazon Cognito のマネージドログインを使用する場合、サーバーレンダリングされた Next.js アプリケーション用の HttpOnly Cookie がサポート されるようになりました。HttpOnly 属性を持つ Cookie には JavaScript によってはアクセスできないため、アプリケーションはクロスサイトスクリプティング (XSS) 攻撃に対する追加の保護レイヤーを備えることができます。 Amazon Cognito – マシンツーマシン (M2M) フローのためにアクセストークンをカスタマイズできるようになりました 。これにより、アプリケーション、API、ワークロードにきめ細かな認可を実装できます。M2M 認可は、スケジュールされたデータ同期タスク、イベントドリブンワークフロー、マイクロサービス通信、システム間のリアルタイムデータストリーミングなどの自動化されたプロセスでよく使用されます。 AWS CodeBuild – コンテナ化なしでの、ホストオペレーティングシステム上における、Linux x86、Arm、Windows オンデマンドフリートを使用した直接ビルドをサポート するようになりました。これにより、ホストシステムリソースに対する直接アクセスが必要なビルドコマンドや、コンテナ化を困難にする特定の要件があるビルドコマンドを実行できるようになりました。例えば、これは、デバイスドライバーの構築、システムレベルのテストの実行、またはホストマシンへのアクセスが必要なツールの使用に役立ちます。CodeBuild は、Linux x86、Arm、Windows、macOS プラットフォームで Node 22、Python 3.13、Go 1.23 のサポートも追加しました 。 Bottlerocket – コンテナ専用に構築されたオープンソースかつ Linux ベースのオペレーティングシステムが、 NVIDIA のマルチインスタンス GPU (MIG) をサポート するようになりました。これは、Kubernetes ノード上の複数の GPU インスタンスに NVIDIA GPU をパーティショニングして GPU リソースの使用率を最大化するのに役立ちます。Bottlerocket はまた、 AWS Neuron アクセラレーテッドインスタンスタイプをサポート し、システムセットアップタスクを簡素化する デフォルトのブートストラップコンテナイメージを提供 するようになりました。 Amazon GameLift – Amazon GameLift Streams をご紹介します。これは、WebRTC 対応ブラウザを使用する任意のデバイスに、最大 1080p の解像度と 60 フレーム/秒でゲームをストリーミングするためにデベロッパーが使用できる新しいマネージド機能です。詳細については、 Donnie のブログ記事をご覧ください 。 Amazon FSx for NetApp ONTAP – 2025 年 3 月 5 日より、 SnapLock ボリュームに保存されたデータについての SnapLock ライセンス料金が廃止され 、コスト効率が高まりました。 AWS の他のニュース その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します: Accelerate AWS Well-Architected reviews with Generative AI – この記事では、Well-Architected Framework Reviews (WAFR) プロセスを効率化する生成 AI ソリューションについて説明します。アーキテクチャドキュメントを分析し、ベストプラクティスに基づいてインサイトに富んだレコメンデーションを生成する、インテリジェントでスケーラブルなシステムを構築する方法をご紹介します。 Build a Multi-Agent System with LangGraph and Mistral on AWS – この記事でご紹介した Multi-Agent City Information System は、エージェントベースのアーキテクチャが、高度で適応性に優れ、非常に高性能な AI アプリケーションを生み出す可能性を示しています。 Evaluate RAG responses with Amazon Bedrock, LlamaIndex and RAGAS – AI システムを評価および最適化し、特定のニーズに整合する、より正確な、コンテキストを踏まえた応答を可能にする実用的な手法を用いて、検索拡張生成 (RAG) 実装を強化する方法。 community.aws からの情報 community.aws からの私のお気に入りの記事をいくつかご紹介します。 AWS ビルダー ID を作成 して、有用な情報を共有し、他のビルダーとつながりましょう。ビルダー ID はユニバーサルログイン認証情報です。これにより、ユーザーは、 AWS マネジメントコンソール だけでなく、600 を超える無料トレーニングコース、コミュニティ機能、 Amazon Q Developer などのデベロッパーツールを含む AWS のツールやリソースにアクセスできます。 Optimize AWS Lambda Costs with Automated Compute Optimizer Insights ( Zechariah Kasina ) – AWS Lambda メモリ設定を最適化してコスト効率を高め、パフォーマンスを改善する、自動化されたスケーラブルな方法。 Optimize AWS Costs: Auto-Shutdown for EC2 Instances ( Adeleke Adebowale Julius ) – Amazon CloudWatch アラームを使用して、非アクティブ状態に基づいてインスタンスを動的にシャットダウンします。 The Evolution of the Developer Role in an AI-Assisted Future ( Aaron Sempf ) – AI がソフトウェア開発を変革している一方で、人材育成の必要性は依然として重要です。 Amazon Q Developer CLI – More coffee, less remembering commands ( Cobus Bernard ) – ターミナルから直接 Amazon Q Developer を利用してファイルを操作できるようになったので、便利なオートメーションをいくつか追加しましょう。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう: AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーが主導する技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とする、コミュニティ主導のカンファレンスにご参加ください: ミラノ (イタリア) (4 月 2 日)、 ベイエリア – セキュリティエディション (4 月 4 日)、 ティミショアラ (ルーマニア) (4 月 10 日)、 プラハ (チェコ共和国) (4 月 29 日)。 AWS Innovate: 生成 AI + データ – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンスにご参加ください。このカンファレンスは、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日) の複数の地域で開催されます。 AWS Summits – AWS Summit の季節が近づいてきました! クラウドコンピューティングコミュニティがつながり、コラボレーションして、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市のイベントにご登録ください: パリ (4 月 9 日)、 アムステルダム (4 月 16 日)、 ロンドン (4 月 30 日)、 ポーランド (5 月 5 日)。 AWS re:Inforce (6 月 16～18 日) – AWS クラウドセキュリティに関するあらゆることに焦点を当てた、毎年恒例の学習イベントです。今年はペンシルベニア州フィラデルフィアで開催されます。登録の受付は 3 月に開始されます。5,000 人を超えるセキュリティビルダーやリーダーとともにご参加ください。 AWS DevDays は、デベロッパーがクラウドコンピューティングの極めてホットなトピックのいくつかについて学べる無料の技術イベントです。DevDays では、ハンズオンワークショップ、技術セッション、ライブデモ、AWS の技術エキスパートや同僚とのネットワーキングが提供されます。 ぜひご登録いただき、オンデマンドで AWS DevDays セッションにアクセスしてください 。 3 月 3 日週のニュースは以上です。3 月 10 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Danilo この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! – ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

はじめに あなたの IoT の取り組みは、これから始めようとしている段階かもしれませんし、すでに数千台のデバイスを運用している段階かもしれません。また、IoT ビジネスアプリケーションを開発したばかりで、これからデバイス群へのデプロイを検討している方もいるでしょう。多くの方が、IoT デバイスの制御、更新、監視、そしてセキュリティ保護の実現方法を模索されていることと思います。そこで AWS は皆様の IoT の取り組みをサポートするため、「Get Started with AWS IoT (英語版)」の提供を開始することをお知らせいたします。 こちらをクリックしてワークショップにアクセスしてください。 &nbsp; このハンズオンワークショップでは、AWS IoT Device Client を使用した IoT プロジェクトの概念実証 (PoC) を、ステップバイステップで解説します。3 時間のワークショップを通じて、以下の内容を学んでいただけます。 IoT デバイスをインターネットに安全に接続し、 AWS IoT Core で登録、オンボーディングします AWS IoT Device Management を使用してデバイスをリモート制御します。 AWS IoT ジョブ を使ってシンプルな Over-The-Air (OTA) リモート操作を実行し、セキュアトンネリングを使って SSH アクセスを設定してトラブルシューティングを行います AWS IoT Device Defender を使用して、毎日セキュリティ監査を設定し、デバイスの「ハートビート」のような健全性メトリクスを監視します AWS IoT Device&nbsp;Client&nbsp;は C++ で記述されたオープンソースであり、 GitHub で入手可能です。 組み込み Linux ベースの IoT デバイスでコンパイルしてインストールすれば、AWS IoT Core、AWS IoT Device Management、AWS IoT Device Defender の利用を開始できます。 前提条件 このワークショップを完了するには、次のものが必要です。 管理者権限のある AWS アカウント、または Event Engine の詳細情報。 新しい AWS アカウントをここで作成 できます。 最新のブラウザ (Firefox や Chrome など) がインストールされたコンピュータ Linux の基本的な知識 (ディレクトリの作成、ファイルパーミッションの設定など) とプログラミング (コードのコンパイル) の知識 AWS IoT Device&nbsp;Client&nbsp;の使用シナリオ ユースケースの例 AWS IoT Device&nbsp;Client&nbsp;は、リファレンス実装であり、IoT の概念実証 (PoC) を作成する最も簡単な方法です。デバイスフリートをインターネットに簡単に接続し、IoT データを AWS に転送できます。デフォルトでは、AWS IoT サービスを使用して、フリートを運用、管理、制御したり、脅威から保護したりできます。オープンソースなので、ビジネスニーズに合わせて変更したり、ビジネスアプリケーションを AWS IoT の機能を利用できるように接続したり、PoC から本番環境へのスケールアップ時にリソース活用を最適化したりできます。AWS IoT Device&nbsp;Client&nbsp;が解決するユースケースの例は次のとおりです。 [ 最初の接続とプロビジョニング ] 本番デバイスのフリートをプロビジョニングし、インターネットに接続したいと考えています。 IoT Device&nbsp;Client&nbsp;を使えば、デバイスが自動的に AWS&nbsp;IoT Core に接続し、 IoT Core Identity サービスから安全な個別の ID を取得し、 IoT Core デバイス レジストリ に自身を登録できます。 IoT ソリューション向けのカスタムビジネスアプリケーションを作成しました。IoT Device&nbsp;Client&nbsp;は、そのアプリケーションに機能の基盤を提供します。 [ メッセージング ] MQTT を利用して、アプリと通信データ、状態、コントロールメッセージをやり取りしたいと考えています。 IoT Device&nbsp;Client&nbsp;を使えば、デバイスが MQTT 経由で AWS IoT Core デバイス ゲートウェイ に接続でき、その接続をアプリと共有できます。デバイスに簡単な設定を行うだけで、 AWS IoT Core メッセージ ブローカー を介してカスタム MQTT トピックを Publish/Subscribe できます。また、アプリから AWS IoT Core ルール エンジン に直接 Basic Ingest でデータを公開することで、メッセージングコストを削減できます。 [ コントロール ] デバイスの状態やアプリの設定を読み書きしたいと考えています。 IoT Device&nbsp;Client&nbsp;を使えば、アプリが AWS IoT Core デバイス シャドウ と対話できるので、デバイスが長期間オフラインでも、デバイスの状態やアプリの設定を取得/設定できます。 [ 運用とアップデート ] アプリの新バージョンに移行したり、ファームウェア /OS のアップデートをデプロイしたり、フリート全体をリモートで再起動したいと考えています。 IoT Device&nbsp;Client&nbsp;を使えば、 AWS IoT Device Management ジョブ を直接利用でき、対象のデバイスへのデプロイ、デプロイの速度制御、ステータス追跡が可能で、デバイスが一時的にオフラインになる環境でも対応できます。 [ トラブルシューティングとアクセス ] デバイスのトラブルシューティング、ログの取得、Secure Shell (SSH) によるメンテナンスへのアクセスを行いたいと考えています。 IoT Device&nbsp;Client&nbsp;を使えば、デバイスから AWS IoT Device Management セキュアトンネル 機能を利用し、管理者権限で Admin コンソールへの同期アクセスが可能です。 [ モニタリングとセキュリティ ] 不審な振る舞いを検出し、フリートを侵害から守るため、開放されているポートやデータ入出力量などのデバイス側のヘルス メトリクスをハートビートとして送信したいと考えています。 IoT Device&nbsp;Client&nbsp;を使えば、デバイスがメトリクスを定期的に MQTT 経由で AWS IoT Device Defender サービスに自動送信できます。 AWS IoT Device Client のアーキテクチャの概要&lt; 互換性 AWS IoT Device&nbsp;Client&nbsp; [ GitHub ] は現在、一般的なマイクロプロセッサ (x86_64、ARM、MIPS-32 アーキテクチャ) および Linux ソフトウェア環境 (Debian、Ubuntu、RHEL) 上で動作します。 また、制約のあるデバイスや特定の目的で作られたデバイス向けに、Yocto Linux ディストリビューションにビルドできる AWS IoT Device&nbsp;Client&nbsp;の meta-aws レシピ も提供しています。 まとめ AWS IoT Device&nbsp;Client&nbsp;を使用して AWS IoT の利用を開始する場合は、この ワークショップ をお試しください。&nbsp; AWS IoT Device&nbsp;Client&nbsp; を使うと、IoT プロジェクトの概念実証 (PoC) を簡単に実施できます。 接続、管理、IoT フリートのセキュリティ確保に関わる一般的な重労働の大部分を AWS IoT Device&nbsp;Client&nbsp;が肩代わりします。これにより、IoT プロジェクトの初期投資を削減できます。 あとは IoT のビジネスロジックとアプリの開発に集中できます。 AWS は、AWS IoT Device&nbsp;Client&nbsp;を実用的なツールとしてサポートし続けます。 このツールには、運用およびセキュリティのベストプラクティスが組み込まれた参照実装です。 新しい AWS IoT の機能が一般に利用可能になるとともに、IoT のベストプラクティスが確立されれば、当社はこのソフトウェアを適切に更新し、それらをサポートしていきます。 この記事は Syed Rehan , Shantanu Sathe &nbsp;によって書かれた&nbsp; Build a proof-of-concept IoT solution in under 3 hours with the AWS IoT Device Client の日本語訳です。プロフェッショナルサービス本部 シニア IoT コンサルタントの宮本 篤が翻訳しました。 著者について Syed Rehan サイバーセキュリティ、クラウド技術、IoT に関する深い専門知識を活かし、セキュリティの専門家、開発者、意思決定者と協力して、AWS セキュリティサービスとソリューションの導入を推進しています。AWS 入社前は、Vodafone、FICO、Rackspace、Nokia、Barclays Bank、Convergys などの企業でミッションクリティカルなシステムの設計・開発に従事していました。また、AWS IoT、ML、サイバーセキュリティに関する書籍の著者でもあり、執筆や講演を通じて知見を共有しています。 Shantanu Sathe Shantanu Sathe は、AWS IoT のシニアプロダクトマネージャー（テクニカル）として、IoT フリート管理および監視ソリューションの構築に注力しています。 <!-- '"` -->

世界中で年間約&nbsp; 395 万人 の労働者が非致死的な負傷を負っているため、企業は統合的で予防的な安全対策の必要性を認識するようになってきました。企業は全体的に安全な作業環境を提供し、事故やケガのリスクを軽減し、従業員の健康を向上させることを目指しています。従来の縦割り方式では、全体的な問題の可視性が制限されるため、重要な洞察が見落とされ、企業の事故の根本原因の究明、安全対策の立案、改善点の理解が難しくなります。また、政府による環境と安全に関する規制が強化されたことから、企業の事業活動全体で環境・健康・安全 (EHS) ソリューションの導入が進んでいます。 この投稿では、職場の安全をより統合された戦略へと変革するトレンドを探り、業界における特定の課題にフォーカスし、「設計段階でのリスク予防」を起点とした統合的なアプローチにより、Amazon がいかに安全を中核に組み込んでいるかを説明します。 安全性の傾向と課題 企業が直面する重要な課題の 1 つは、様々な作業環境、さらには同じ現場や機能の中でもさまざまな労災リスクが存在することです。例えば、建設現場では、高所からの転落や機器関連の怪我などの労災があります。製造施設では、化学物質への曝露や機械関連の事故のリスクに注意する必要があります。危険度の高い発電所での目視検査は危険を伴います。業界を問わず、侵入検知や標準的な運用手順に準拠していないことは、従業員の安全性を脅かすことにつながります。これらは従来、特定の問題のみを対処する狭い範囲のソリューションを展開することしかできず、1 つのリスク分野から得られた知見を他のリスク分野の理解に活用することはできませんでした。 一方で、IoT (モノのインターネット)、コンピュータビジョン (CV)、機械学習 (ML)、仮想現実 (VR)、生成 AI などの技術が、作業安全の新しい可能性を生み出しました。例えば、CV による作業環境や機器の継続監視、安全事故やリスク発生時の迅速な検知、没入型 VR シミュレーションによる従業員の教育などです。企業は従業員の身体的安全性のみならず、ウェルビーイングの重要性も認識するようになっています。適切なツールを従業員に提供することで、生産性が向上し、ストレスが軽減され、ウェルビーイングを促進する職場環境を育むことができます。 もう一方で、特定の使用ケースのみを導入するのではなく、より広範な安全管理の枠組みに基づいて実施し、それぞれのユースケースから得られる知見を統合・関連付けて中央の安全データモデルに集約することで、安全データの収集、分析、活用の最適化が可能になります。この統合的アプローチにより、意思決定の精度が向上し、組織全体におけるより良い協力とコミュニケーションが可能になります。 本ブログでは、実世界のデータと視覚的なナビゲーションオーバーレイを組み合わせることで、Amazon がどのように統合的な安全管理アプローチを構築しているのかを詳しく紹介します。本アプローチにより、従業員が職場の安全上の課題を包括的に理解し、対応を加速できるよう支援しています。 例: 建設・エンジニアリング業界 – 統合された安全アプローチを積極的に検討している業界が建設・エンジニアリング業界です。この業界では、安全と効率が成功プロジェクトの基盤となります。危険には、高所作業や重機の運転から、複数の協力業者の管理や現場の安全確保まで、様々なものがあります。着工から引き渡しに至るまでの各建設フェーズでは、工期やプロジェクト予算に直接影響する様々な懸念事項があります。そこで、建設安全の多面的な性質に対処するため、統合された安全フレームワークとソリューションがとても重要になります。インシデントに対処するためだけでなく、予防を目的として、現場の継続的な監視、従業員の訓練、コンプライアンス管理を、シームレスなデータモデルに統合するよう設計されています。 IoT センサーにより、構造上の危険、機器の故障を監視し、許可されたスタッフのみがサイトにいることを確認しながら、サイトのあらゆる場所の運用状況を可視化できます。このような制御と監視により、安全対策が単に準備されているだけでなく、積極的に施行されることが保証されます。また、どのようなソリューションであっても、安全規制の順守を効率化する必要があります。特に建設業界のように、規制が厳しいだけでなく常に変化している分野では、なおさら重要です。この分野の企業は、最新の研修と自動化されたコンプライアンス報告で、基準を満たすだけでなくそれを上回るレベルを保証しなければなりません。業界全体で統一された安全設計を導入することは、稼働停止時間の短縮、生産性の向上につながり、何より重要なのは、より安全で効率的な環境を実現することです。 例: 半導体業界 – もう一つ、作業者の安全性において特有の課題を抱える業界が半導体業界です。この分野では、精密さと安全性の両立が不可欠とされています。クリーンルームや半導体製造施設では、わずかなミスも許されない環境で作業が行われます。汚染管理は、従業員を化学物質への暴露や機器の危険から守ることと同じくらい重要です。ここでも、これらの業界特有の課題に対処するためには統合されたアプローチが不可欠です。統合されたアーキテクチャにより、環境を継続的に監視し、早期に危険を検知することができます。没入型環境での包括的な従業員教育を、半導体製造ならではの独自のプロトコルに合わせてカスタマイズできます。これにより、汚染を予防的に防ぎ、迅速に事故対応でき、製品の完全性と従業員の安全性の両方を確保できます。 IoT 技術を使えば、クリーンルームの環境を連続的に監視し、粒子、ガス、その他の汚染物質を厳しい制限内に抑えることができます。さらにコンピュータビジョンを使えば、個人用保護具の着用状況を管理できます。また、化学物質の流出や機械の事故への安全対策を行え、半導体製造に求められる厳格な基準を維持できます。 AWS を活用した労働安全対策ソリューション AWS の&nbsp; Workforce Safety &nbsp;ソリューションは、モジュール型でありながら統合された安全管理の枠組みを導入することで、顧客の労働災害を減らすのに役立ちます。これらのソリューションにより、企業は安全な作業環境を実現し、安全プロトコルの順守を改善し、安全性のコンプライアンスと監査のニーズに効果的に対応するための洞察を得ることができます。 これらのソリューションは、AWS の IoT、AI/ML、コンピュータビジョン、データモデリングの機能に基づいたスケーラブルなアーキテクチャを構築できるようにし、統合された専門パートナーのソリューションと連携して労働安全のあらゆる側面に対応します。これにより、お客様は、コンピュータビジョンを使用した非準拠の検出や、生成&nbsp;AI を使用した複数の標準運用手順、安全マニュアル、ガイドの検索、または機器の運用リスクの検出など、特定の課題に対処できます。さらに、この知見を中央の安全データモデルに取り入れることもできます。これにより、お客様は、労災リスクを軽減するための複数のワークフローを作成し、低レイテンシーの監視とアラートを設定し、機械学習ベースのモデルを使用して運用全体での潜在的なインシデントを検出できるようになります。 以下は、統合された安全データモデルに導入および統合できるユースケースの例です: 安全パターンと傾向を発見する&nbsp; — ビジュアル方式でデータのパターンと傾向を監視し、リスクを特定し、安全プロトコルの改善、コンプライアンスと監査のニーズに対処します。 過去のデータを使って施設の危険エリアを特定する — 安全管理者やサイト設計者向けに、過去の安全データと事故データを没入型ビジュアル環境に重ね合わせ、危険エリアを特定し、事故のリスクを軽減する施設設計を行います。 危険な作業環境を特定し対応する — ウェアラブルデバイスと安全センサーを使用して、作業者に危険な作業環境を通知し、直ちに対応できるようにします。 中央集約型の報告を可能にする — 中央集約型の報告と文書化を実現し、規制要件の順守状況の把握と対応を容易にします。 作業者の訓練を強化する — リスクのない仮想環境で、最新の標準作業手順 (SOP) に基づいた訓練を作業者に実施し、教育時間を短縮し、作業者の安全性を高めます。 現地での点検の必要性を削減する — IoT センサーからリアルタイムの運用データを収集することで、現地での点検の必要性を削減し、安全問題の解決を迅速化します。 作業者が安全プロトコルを守っていることを確認する — コンピュータビジョンベースの AI モデルを使用して、個人用保護具 (PPE) を着用していない作業者など、安全規定違反を検出し、安全プロトコルの遵守を確認します。 今後の展望 組織の労働者の安全性を高めるために、リスク観測や記録が数百ページから数千ページにも及ぶ可能性があります。バーチャル視察中は、適切なデータソースを検索して特定するのに貴重な時間を費やす場合があります。マニュアル、研修資料、その他のコンテンツとは別に、センサーは潜在的な事故 (温度、ガス漏れ、振動など) の継続的なデータを収集します。また、AI/ML のコンピュータビジョンモデルを搭載したビデオカメラは、インシデント (PPE の不備や違反の検知など、規定に準拠していない場合) を検出して警告を出すことができます。データに基づく洞察がなく、全ての安全上の懸念を一元的に把握できない場合、さまざまなインシデントを理解し対応するには時間がかかります。また、影響力のある改善を定義するのは難しくなります。そこで、関連する全てのデータソースを統合し、AI/ML と共に AR/VR を活用して、ナレッジベースを構築し、組織内のチームがすぐに利用できるようにすることをお勧めします。 作業者の安全を守るためのソリューションガイダンス AWS は、企業が従業員の安全性に関するベストプラクティスに従えるよう、 ソリューションガイダンス を開発しました。このガイダンスには、次の内容に関するリファレンスアーキテクチャが含まれます。1) データの取り込み、2) データのストリーミングおよび処理、3) データの可視化および通知です。 データの取り込み: IoT、ビデオ、PLC、文書から現場でのデータ取り込みを可能にし、CV およびロボティクス機能のためのエッジコンピューティングを提供します。 データのストリーミングおよび処理: 産業機器、ビデオフィード、IoT デバイスからの運用データをエッジ上で取り込み、処理します。その後、データを整形し、中央集約型のデータレイクにストリーミングします。 AWS IoT SiteWise &nbsp;およびデータレイクからデータを取り込み、作業者の健康と安全指標を監視するためのダッシュボード、3D 可視化、リスクマッピングを提供します。また、キュレーションされたデータセットから直接データの探索と分析を可能にします。 AWS Workforce Safety ソリューションガイダンス 導入事例: Amazon 労働者の健康と安全 Amazon の信頼性と保守エンジニアリング (RME) および労働者の健康と安全 (WHS) は、AWS サービス (例えば&nbsp; AWS IoT TwinMaker ) およびパートナー企業の Matterport を利用することで、Amazon のフルフィルメントサイトでの潜在的な安全上のリスクを特定し、これに対処する「設計段階でのリスク予防」プログラムを実施しています。過去の安全データを組み込んだ実際の作業環境のデジタルレプリカを作成することで、WHS は事故や怪我につながりかねない設計上の欠陥を突き止めることができます。例えば、現場のメンテナンス担当技術者のアクセスに関する問題を特定し、現場設計の段階でその問題に事前に対処することができます。このプログラムにより、WHS は Amazon 従業員の安全と健康を確保し、将来的な継続的な改善に向けた道筋をつけることができます。 Amazon WHS は、施設の詳細なデジタルツインの作成に Matterport の技術を活用しました。Matterport と AWS のパートナーシップと、AWS IoT TwinMaker などの AWS サービスとの統合により、顧客は Matterport の 3D モデルに運用データを “バインド” し、ダイナミックに接続された最新のデジタルツインを作成できる無駄のないワークフローが実現しました。 “Amazon の拠点において、作業空間のデジタルレプリカを作成し、設計段階でのリスク予防 (Prevention through Design) を実施することで、潜在的な安全性やメンテナンスアクセスの課題を特定し、対策を講じる能力が向上します。実際の作業環境をシミュレーションし、過去の安全データを組み込むことで、これまでメンテナンス作業の妨げとなっていた設計上の欠陥を特定し、解決することが可能になりました。これにより、技術者の安全を最優先し、設計の見直しや改善の機会を提供できます。さらに、この技術は設計上の欠陥による危険箇所の特定にも役立ち、職場全体の安全性を大幅に向上させています。また、遠隔でのリスク評価やオンラインでの運用管理が可能になり、コスト削減と業務効率化の両面で大きな効果をもたらしています。” – Shreya Hegde, シニアプロダクトマネージャー（テクノロジー）, Amazon Reliability and Maintenance Engineering (RME) Matterport と AWS IoT TwinMaker を活用した施設のデジタルツイン Matterport と AWS IoT TwinMaker を活用した施設のデジタルツイン 上の画像は、インタラクティブな Matterport 3D デジタルツインのスナップショットを表示しています。AWS IoT TwinMaker と統合されると、これらの Matterport モデルはセンサーやその他のデータにリンクできるため、施設の監視や労働者の健康と安全のための強力なプラットフォームになります。 Matterport について Matterport の空間データプラットフォームは、AWS IoT TwinMaker と統合されており、企業が健康と安全プロトコルを改善するのを大きく支援できます。この統合ソリューションは、IoT センサーからのリアルタイムデータを組み込んだ詳細な 3D デジタルツインを提供することで、リモートでの継続的な監視とバーチャルな詳細な検査が可能となり、危険な環境への実際の立ち入りを最小限に抑えることができます。さらに、環境状態のリアルタイムアラートと分析情報を提供することで、予防的な労災管理を支援します。また、没入型の仮想トレーニングプログラムを提供し、従業員を実際のリスクにさらすことなく、緊急事態への備えや作業空間の把握ができるようにします。事故の際には、詳細なビジュアルデータと文書化により、徹底した調査と分析を可能にします。さらに、規制順守と報告を合理化し、健康と安全基準の遵守を確実にするとともに、安全チーム、マネジメント、外部監査担当者間での意思決定とコミュニケーションを改善します。 まとめ この記事では、複数の安全活用事例に対する統合的アプローチの重要性と、統合された労働者の安全改革の一部となるキーテクノロジーについて説明しました。また、Amazon の RME と WHS がデジタルツインのアプローチで「設計段階でのリスク予防」など、さまざまなユースケースを解決していることにも触れました。デジタルツインの没入型可視化は、「私が見ているものを見せる」ことで、運用チーム内でのコミュニケーションとナレッジ共有を改善できます。これにより、問題を特定し、より効果的に解決するプロセスを最適化することもできます。 デジタルツインに関するサービスやパートナーシップの詳細については、 労働者の安全ガイダンス をご覧ください。 AWS IoT TwinMaker &nbsp;や&nbsp; AWS IoT SiteWise についての情報へアクセスすることもできますし、AWS と Matterport のパートナーシップについてさらに深く知ることもできます。Matterport のソリューションについて直接問い合わせたい場合は、Matterport に連絡してください。 著者について Yibo Liang は、AWS においてエンジニアリング、建設、不動産業界を支援するインダストリー・スペシャリスト・ソリューションアーキテクトです。IoT、データ分析、デジタルツインに強い関心を持っています。 Pallavi Chari は、AWS において 産業向け IoT アプリケーションとデジタルツインの Go-To-Market をリードしています。18年以上にわたり、世界有数のテクノロジー企業とともに製品戦略や提案業務に携わってきました。IoT、エッジコンピューティング、5G 接続、AI/ML などの技術を活用し、産業分野の顧客やパートナーの変革を支援し、ビジネス価値を創出してきました。経済学の学位を持ち、経営学修士（MBA） を取得しています。 Jon Olmstead は、Amazon の開発チームと緊密に連携し、職場の健康と安全に特化した AWS の主要顧客を支援しています。AWS に入社する前は、Caesars Entertainment のデジタルマーケティングエグゼクティブを務め、Zappos では複数の Web 開発チームを率いた経験を持っています。現在は ワシントン州のベインブリッジ島に在住し、家族との充実した時間を大切にしながら、島内のトレイルランニングを楽しんでいます。 Shreya Hegde は、Amazon RME のシニアプロダクトマネージャー（テクノロジー） として、AWS、職場の健康・安全、そしてピープルエクスペリエンスチームと連携しています。ソフトウェア開発者としてキャリアをスタートし、スケーラブルなエンタープライズ製品の構築に対する情熱からプロダクトマネジメントへ転向しました。過去 17 年間で、航空業界、ヘルスケア系スタートアップ、収益管理企業、米国政府プログラム向けの技術製品を手がけてきました。また、女性のテクノロジー分野での活躍を支援する強い信念を持ち、Austin の Lean In（非営利団体）のサークルリーダーとしても活動しています。 Katie Lameti は、Matterport において グローバル AWS パートナーシップを統括しています。AWS 内のチームや Amazon Partner Network 内のさまざまな組織と連携 し、Go-To-Market 戦略を策定。顧客がデジタルツインソリューションを構想し、調達・導入・スケールできるよう支援し、ビジネス価値の創出を促進しています。 この記事は&nbsp; Delivering an integrated approach to safety: How AWS workforce safety solutions make work safer の日本語訳です。IoT Consultant の正村 雄介が翻訳しました。

本ブログは岩崎電気株式会社様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの瀧田です。 2024 年から2025 年にかけて、多くのお客様に生成 AI の活用にチャレンジいただきました。製造業のお客様においても、生成 AI を活用した新しい製品・サービス開発の取り組みが増えてきています。 今回は、照明の専門メーカーとして80年以上の歴史を持つ 岩崎電気株式会社様 が AWS の生成 AI サービスである Amazon Bedrock を活用して、カメラ付き照明による冠水検知システムを開発した事例をご紹介します。 岩崎電気様の状況と経緯 岩崎電気様は安心、安全、快適な社会を支える 路面冠水警報表示システム というサービスを提供しています。このサービスは、冠水しやすい場所に水位検知器を設置し、しきい値を超える水位を検知すると近くの警報表示板に「冠水通行止」などの警告を表示します。ゲリラ豪雨による突発的な道路冠水時に注意喚起を行うことができます。またカメラ付きの照明を設置することで遠隔での状況確認をすることができます。 しかし、冠水を自動で検知するためには依然としてセンサーが必要でした。カメラ映像だけでは、実際に冠水しているかどうかを人の目で確認する必要があり、センサーを設置できない場所では自動での冠水検知が困難でした。 そんな中、日本最大の ” AWS を学ぶイベント” 「 AWS Summit Japan 」に岩崎電気様が来場されました。このイベントは、技術者だけでなく、あらゆる業種の方々がクラウドイノベーションについて学び、交流できる場です。岩崎電気様はカメラを使った新たなアイデアを探していたところ、製造業向け展示の「 生成 AI によるカメラ映像からの危険判別 」ブースにお立ち寄りいただきました。 AWS のエキスパートとの対話を通じて、岩崎電気様は生成 AI で課題解決できるのではないかという着想を得られました。 AWS Summit Japan 終了後、岩崎電気様は早速カメラ映像から自動で冠水を検知できるシステムの検証に着手されました。 ビジネス検証 / ソリューションと構成 従来の AI/ML だと学習コストがかかり、導入までのハードルが高く、かつ成果が出るかも分からない状況でした。生成 AI を使うことで事前学習なしで検知できる可能性を感じ、 AWS と GenU を活用し、迅速に実現可能性を検証できる環境を構築しました。 早速冠水画像を入れてみたところ、思いの外精度良く判定してくれることに気が付きこれは生成 AI の指示 (プロンプト) を検証していくことで十分製品化できると判断することができました。 ビジネス検証のイメージ ビジネス検証は GenU を使い以下のように実施していきました。 初めは冠水画像を入れて単純に生成 AI に「道路が冠水しているか簡潔に教えて」という質問をしてみるところからスタートしています。その後、様々なモデルを選択しながら生成 AI への指示を工夫し、精度やコストを検証しています。 その結果、コスト効率を考慮して、安価な Claude 3 Haiku で大部分の判定処理を行い、判断が難しいケースのみ高性能な Claude 3 Sonnet で最終判断を行うアーキテクチャを採用しました。このような使い分けにより、ほとんどの処理を Haiku で効率的に行いながらも、精度が必要な場面では Sonnet の高い判断能力を活用することで、コストパフォーマンスに優れた商品化レベルのシステムを実現できました。 ( GenU の検証画面 – 初期検証 プロンプト調整前) ・Generative AI Use Cases JP ( GenU ) とは https://aws-samples.github.io/generative-ai-use-cases-jp/ AWS 環境にデプロイしてセキュアに利用できる、生成 AI のビジネスユースケースを検証できるアプリケーション ソリューションと構成 1分間隔でカメラ画像を元に、生成 AI が冠水しているかをチェックし、冠水していると判断した場合利用者へ通知を行います。システムは AWS のサーバーレスアーキテクチャを中心とした構成で構築され、コスト効率の高いシステムとなりました。 開発は非常にスピーディーに進み、企画から約2ヶ月でプロトタイプが完成しました。 (ソリューションのイメージ) (構成のイメージ – 概略) 構築を支援したパートナー企業 開発にあたっては、AWS パートナーである 株式会社 Benjamin（ベンジャミン）様 にご協力いただきました。ベンジャミン様は AWS やサーバーレスアーキテクチャに精通しており、今回の Amazon Bedrock を使った追加機能開発もスムーズに行うことができました。 導入効果 Amazon Bedrock を利用したアプリケーションの導入により、以下の効果が得られました： 1. AI 技術により 24 時間リアルタイムかつ幅広い状況の道路監視を自動化 ・常時監視が不要になり、監視員の監視労力を 80% 削減 ・データ活用による道路・排水路計画など都市開発へも貢献 2. 遠隔での状況確認が可能に さらに、実証実験を行っているお客様からは、生成 AI を活用したシステムに高い関心が寄せられています。 特に暗所での冠水検知は難しかったが、カメラ＋照明が一体となっていることで鮮明なカメラ画像を取得することができ、生成AIを活用したことにより効率的に検知できるようになりました。 お客様の声 ・岩崎電気様の声 AWS はスモールスタートできる環境が揃っており、新しい技術でもすぐに低コストでビジネス検証できる点が魅力的でした。 GenU を使うことでセキュアな環境で手元の画像を使ってすぐに生成 AI の価値を試せたという点も良かったです。 ・エンドユーザ様の声 生成 AI を活用することで、自動で冠水していることを教えてくれるようになりました。監視業務に非常に負荷がかかっていたため助かっています。 今後の展望 岩崎電気様では、本システムのさらなる進化を目指しています。具体的には以下の点に取り組む予定です： 1. 通知方法の拡充（電話、LINE など） 2. 検知対象の拡大（火災、交通事故など） 3. 従来型 AI と生成 AI の使い分けによる精度向上 まとめ 本事例は、製造業の企業が自らの得意分野であるモノ（照明）に対して、生成 AI を活用してコト（自動検知）を追加し、新製品開発を加速させた好例です。岩崎電気様の新技術への積極的な姿勢と、AWS が提供する使いやすい生成 AI サービス、そしてパートナー企業との柔軟な協力関係が、短期間での開発成功につながりました。 生成 AI を活用した新製品開発、業務の効率化、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 岩崎電気株式会社: 大脇 理 様（中央） Amazon Web Services Japan : アカウントマネージャー Wenjia Liu（右）、ソリューションアーキテクト 瀧田 直斗（左） ソリューションアーキテクト 瀧田 直斗

タップル は、好きなことから恋の相手を見つけることができるマッチングアプリです。 株式会社サイバーエージェント のグループ会社である 株式会社タップル が運営する、日本国内最大規模のマッチングアプリになります。 タップルは主に、恋活中の若い人たちが使っています。 アンケート調査 でも利用満足度が最も高く、累計会員数は1,900万人を超え、累計マッチング成立数は5億組を超えています。さらに、毎日40万組以上のマッチングが成立し、毎月10,000人のカップルが誕生しています。 Amazon OpenSearch Service は、インタラクティブなログ分析、リアルタイムのアプリケーション監視、ウェブサイト検索などを簡単に実行できるサービスです。 OpenSearch は、 Elasticsearch から派生したオープンソースの分散型検索および分析ソフトウェアです。Amazon OpenSearch Serviceは、OpenSearchの最新バージョンを提供し、Elasticsearch（バージョン7.10まで）もサポートしているほか、OpenSearch DashboardsとKibanaを利用したビジュアライズ機能も提供しています。Amazon OpenSearch Serviceには現在、何万ものアクティブなお客様がいて、数十万のクラスターが管理されており、毎月何兆ものリクエストを処理しています。 タップルは、監視業務の一部に独自のアプリケーションログ基盤を使用してきました。この基盤には、タップルユーザーがマッチングアプリを操作するたびに記録されるアプリケーションログが保存されるため、タップルのエンジニアはサービスで発生する問題の修正に役立つログにすぐにアクセスすることができます。しかし、マッチングアプリが人気を獲得したことで、このアプリケーションログ基盤にスケーリング上の課題が発生しました。既存のソリューションのままでは、ログが増えるにつれて、インフラが肥大化して管理コストが増加するという課題が生まれたのです。そこで、この課題を解消するために、タップルはAmazon OpenSearch Ingestion と OR1 インスタンスを採用することに決めました。 この投稿では、タップルがOpenSearchソリューションに関連する安定性の向上、肥大化の解消、コストの削減に取り組み、マッチングアプリの顧客体験を向上させるために行った取り組みを振り返ります。 既存のアプリケーションログ基盤の課題 タップルは、マッチングアプリの初期デプロイ時からAmazon OpenSearch Serviceを利用しています。アプリケーションログ基盤は、直近1か月のデータを保持するAmazon OpenSearch Serviceドメインと、データを長期間アーカイブする Amazon S3 と Amazon Athena で構成されています。既存のソリューションでは、コンテナホストからそれらに Fluent Bit エージェントでログを直接書き込むよう構成されていました。 以前のアーキテクチャ タップルが人気を得るとともにユーザーベースが拡大しました。そして、その成長を支えるべく、スケーラビリティ向上のためにモノリシックアーキテクチャからマイクロサービスアーキテクチャへ移行しました。ユーザーの増加と、サービスの成長に応じて既存ソリューションの構成を見直したことによりログを記録する振る舞いの数が増加したことで、ログの量も増加しました。タップルは、ロギング処理の影響をOpenSearchクラスターのスケーリングへの影響から切り離して、成長に対応する方法を必要としていました。 このアプリケーションログ基盤は、タップルユーザーがアプリを操作するたびに、マイクロサービスからアプリケーションログを継続的に直接受信していました。そして、その主な用途は、タップルのエンジニアがサービスに問題が発生した場合にOpenSearch Dashboardsからログを照会して調査することです。全体として、Amazon OpenSearch Serviceドメインの負荷は、ユーザーの行動による継続的なインデックスと、エンジニアの操作による時折の検索クエリであるため、書き込みが多いという特徴があります。目標は、書き込みの多い特性を考慮して、インデックス・検索（書き込み・読み取り）の性能を維持しながら、コストを削減し、安定性を向上させることでした。 通常、このような問題が発生した場合は、トラフィックの急増を防ぎ、Amazon OpenSearch Serviceに送信されるペイロードのサイズを管理するのに役立つバッファを導入します。 また、一般的に、ビジネスが成長して規模が拡大するにつれて、Fluent BitからAmazon OpenSearch Serviceに直接書き込むことが課題になります。アプリケーションのロギングをサポートするためにエージェントの数が増えるにつれて、複数のエージェントから発生する小さな取り込みペイロードの非効率性が、安定性のアンチパターンをもたらし、その結果、書き込まれるデータの量に対応できるようにOpenSearchクラスターを拡張する必要が発生します。 Fluent Bitエージェントはそれぞれ独立して動作します。たとえば、各エージェントが数十個程度のドキュメントのペイロードを送信し、他のエージェントも同様に送信した場合、それらの小さなペイロードがOpenSearchの取り込みキューをいっぱいにすることがあり得ます。このような懸念に対処するために、通常はOpenSearchクラスターをスケールアップまたはスケールアウトしますが、これが肥大化やコストの問題の一因となります。 さらなる成長と持続可能な事業を実現するために、タップルはサービスのバックエンドを構成するAWSリソースを見直しました。構成の見直しの過程で、アプリケーションログ基盤のAmazon OpenSearch Service部分に改善の余地があることがわかりました。 一方、Amazon S3とAmazon Athenaによるアーカイブに関して特に問題はなかったので、タップルはAmazon OpenSearch Serviceドメインの改善に注力しました。 ソリューションの概要 AWSとともに検討を進めたところ、タップルは Amazon OpenSearch Ingestion を利用してスパイクに対処し、より一貫性のあるペイロードサイズを作成して、クラスターの健全性を促進できることに気付きました。さらに、タップルの規模ではコストが懸念されることから、AWSはお客様に、比較的新しくリリースされた Amazon OpenSearch OR1インスタンス の使用を検討するよう提案しました。このインスタンスでは、アクティブに書き込まれていないインデックスにレプリカを作成する必要はありません。 OR1インスタンスは実際にはレプリカをAmazon S3に保存します。データを長期間保持し、コストを重視する多くのお客様にとって、OR1インスタンスは「ホットレプリカ」を必要としないため、データのコストを大幅に削減するのに役立ちます。耐久性のためにレプリカをAmazon S3に保存し、データノードに異常が生じた場合、そのレプリカはAmazon S3から引き戻され、障害が発生したデータノードが保持していたデータを再構成するために使用されます。これは結果的にコスト削減とデータの耐久性に寄与することを意味します。 Amazon OpenSearch Ingestion まず初めに、タップルは Amazon OpenSearch Ingestion を導入しました。 Amazon OpenSearch Ingestonはフルマネージド型のサーバーレスデータコレクターで、リアルタイムのログなどをAmazon OpenSearch Serviceドメインに配信します。 タップルは、サービス開始当初はモノリシックアーキテクチャだったバックエンドを、サービスの成長に合わせてマイクロサービスアーキテクチャに変更しました。マイクロサービスへの移行の過程で、タップルを構成する各マイクロサービスは、Fluent Bitを使用してAmazon OpenSearch Serviceドメインに個別に直接書き込むようになりました。 今回の見直しによって、タップルは、これらの複数の直接インデックス経路を単一の集約経路に変更し、Amazon OpenSearch Ingestonを介してすべてのイベントストリームをドメインに書き込むことにしました。 さらに、Amazon OpenSearch Ingestionの採用に伴い、イベントストリームをAmazon OpenSearch ServiceドメインとAmazon S3バケットに直接二重に書き込むことをやめました。二重に書き込む代わりに、Amazon S3バケットをソースとしてAmazon OpenSearch Ingestionの前に置き、 OpenSearch Ingestion Pipeline を1つにしました。 結果的に、インデックス経路をAmazon OpenSearch Ingestionに集約することで、Amazon OpenSearch Serviceドメインが受信するHTTPリクエストの数を30分の1に減らしました。 Amazon OpenSearch OR1インスタンス 今一度、本件のアプリケーションログ基盤の特徴を振り返ると、いくつかの明確な要件を確認できます。 Amazon OpenSearch Serviceドメインの負荷は、継続的に発生するアプリケーションログをインデックスし続ける必要があるため、書き込みによる影響が大きい。 クエリの実行頻度は非常に低いものの、ひとつひとつの検索クエリには高い応答速度が求められます。これは、サービスに問題が発生した場合に状況をすぐに確認する必要があるためです。 Amazon OpenSearch Serviceドメインに保持されるデータは、直近1か月のデータのみです。 タップルは、これらの特性が Amazon OpenSearch OR1インスタンス に適していると考え、新たなインスタンスとして採用しました。 OR1はAmazon OpenSearch Serviceのインスタンスで、大量のデータを費用対効果の高い方法で保存できます。OR1インスタンスのあるドメインは、Amazon EBS gp3またはio1ボリュームをプライマリストレージとして使用し、データはOpenSearchセグメントレプリケーションを使用してAmazon S3に同期的にコピーされます。このストレージ構造により、耐久性の高いインデックス（書き込み）スループットが可能になります。OR1インスタンスは、障害発生時の自動データ復旧もサポートしています。OR1の仕組みの詳細な説明については、 こちらのAWS Big Data Blogの記事 を参照してください。他にも、AWSは、 こちらのAWS Big Data Blogの記事 でor1.largeとr6g.largeを比較したパフォーマンスベンチマークの結果も公開しています。一般的な比較として参考にしてください。 上述の要件とAmazon OpenSearch Ingestionの導入による効果を考慮して、データノード用のAmazon OpenSearch Serviceドメインのインスタンスタイプとサイズは、以前はr6g.largeを使用していたところを、or1.2xlargeとしました。 さらに、OR1の採用に伴い、OpenSearchのシャードレプリカ設定も見直し、シャードサイズを最適化し、シャード数を減らしました（3分の1に削減）。この変更は、ストレージ構造と自動データ復旧によるOR1の耐久性と障害耐性を頼りにしています。インスタンスタイプ、インスタンスサイズ、シャード設定を変更することで、以前と同じインデックス・検索性能を維持しながら、Amazon OpenSearch Serviceドメインをスリム化することに成功しました。これは、タップルのアプリケーションログ基盤の性能要件も満たしています。 Amazon OpenSearch Ingestionの導入による効果に加えて、Amazon OpenSearch Serviceドメインを構成するインスタンスをOR1に変更し、さらにシャードを最適化することで、インスタンス数は90%以上削減されました。 導入効果 ここまで述べてきたように、Amazon OpenSearch Serviceの設定を最適化した結果は一目瞭然です。 インデックス経路を Amazon OpenSearch Ingestionに集約することで、Amazon OpenSearch Serviceドメインが受信するHTTPリクエストの量を劇的に減らすことができました。具体的には、リクエストの数が以前のレベルの30分の1に減りました。さらに、OR1インスタンスを使用するようにドメインを構成するインスタンスタイプを変更し、シャード構成を最適化することで、必要なインスタンスの総数が90%以上削減されました。 全体として、Amazon OpenSearch Serviceドメインのランニングコストを約45%削減しました。結果的に、タップルのアプリケーションログ基盤の性能要件を満たすのに十分コンパクトで費用対効果の高いAmazon OpenSearch Serviceドメインを獲得したのです。 株式会社タップル SRE 赤野 裕喜 氏 「Amazon OpenSearch Serviceクラスターの肥大化と管理コストの増大が課題でしたが、コスト削減と安定性向上を実現できました。」 最後に 読者の皆様の多くは、タップルが達成したように、安定性を損なうことなくコストを最適化することに深い関心を持っていると思います。IngestionやOR1インスタンスなどのAmazon OpenSearch Serviceの機能は、これらの目標を達成するのに役立ちます。 このような機能をどのように活用できるかについて詳しくは、AWSの ドキュメント をご覧ください。また、必要に応じて、 AWSアカウントチーム に連絡して、Amazon OpenSearch Serviceの機能を活用して最適化するための具体的なサポートを受けてください。 最後に、この最適化に関わったすべての方々に感謝の意を表したいと思います。ありがとうございます。 このブログの著者 半場 光晴（Mitusharu Hamba） アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト

はじめに アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの山本です。 先日、AWS re:Invent 2024 の主要なアップデートや、物流・建設・不動産・交通業向けのアップデート及び事例をご紹介する Recap (振り返り) ウェビナーを開催しました。今回のウェビナーでは、AWS ジャパンで業界特化でお客様を支援するソリューションアーキテクトが厳選した情報を、業界の最新動向も交えてご紹介しました。 本ブログ記事では、セッション内容のサマリと、セッションの資料・動画へのリンクをまとめてお届けします。 資料一括ダウンロード アーカイブ Video（全編） re:Invent 2024 キーノートおよび技術アップデート – 堀 竜慈 アマゾンウェブサービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 サービスグループ トラベル・交通・物流ソリューション部 ソリューションアーキテクト このセッションでは、本セッションの後に続く、各業界別事例セッションを視聴する上での前提知識として、re:Invent 2024 の概要と、AWS のリーダーによるメッセージをお伝えする基調講演のご紹介を行いました。また、それに加えて、どの業界でも共通で注目を浴びている生成AIに関するサービスのアップデートについてお伝えしました。本セッションを通して、AWSがどのようにセキュリティを最優先に掲げつつ、イノベーションによる価値をお客様に届けてきたかをご説明しています。セキュリティとイノベーションの双方が重要視される皆様の業界に価値を届ける、AWSの取り組みをご覧ください。生成AIに関するサービスのご紹介では、数多くのアップデートの中から、皆様のソリューションに組み込むことができる多機能な推論コンポーネントとしての Amazon Bedrock、レガシーな環境をモダナイゼーションするための Amazon Q Developer 機能、データとAIと分析の全て包括したサービスとしての次世代の SageMaker についてお届けしました。AWS が提供する多様な生成 AI サービスを知っていただき、各業界共通の課題である担い手不足の対策、ビジネスモデル変化の対応等にお役立ていただければと思います。 物流業界関連セッションのサマリ – 山本 大貴 アマゾンウェブサービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ソーシャルソリューション＆サービスグループ トラベル・交通・物流ソリューション部 ソリューションアーキテクト 本セッションでは物流業界が抱える、労働力不足、需要の変化、ビジネスモデルの変化、脱炭素といった課題に対するヒントとして、自動化、サプライチェーン管理、サステナビリティというテーマごとにおすすめセッション及び関連情報を紹介しています。AI/ML や データ管理を中心に、AWS が提供する技術を物流の実務にどのように適用可能なのか、また適用するにあたって AWS がどのようにお客様を支援できるのか、参考にしていただけるセッションと思います。 建設・不動産関連セッションのサマリ – 山中 真人 アマゾンウェブサービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 サービスグループ 建設・不動産ソリューション部 シニアソリューションアーキテクト 建設・不動産業界向けのセッションでは、業界が直面する生産性向上、デジタルトランスフォーメーション、サステナビリティなどの課題に対するAWSの活用事例を紹介しています。IoTやデジタルツイン技術を活用した建物運営の効率化、衛星画像分析による地理空間データの活用、ロボット技術の応用など、幅広い技術革新の可能性を示しています。また、従来型のAI/MLから生成AIへと発展し、画像、テキスト、3Dモデルなどを統合的に扱うマルチモーダルの活用事例も数多く紹介しています。 交通業界関連セッションのサマリ – 寺山 怜志 アマゾンウェブサービス ジャパン合同会社 技術統括本部 エンタープライズ技術本部 ストラテジックサービスソリューション部 ソリューションアーキテクト 次世代の担い手不足、移動需要の変化、「移動」の多様化、安心・安全に対する脅威の増大のように交通業界を取り巻く環境は少しずつ変化しています。こうした変化に対応するために、デジタル技術を効果的に取り込むことが解決策の1つとして期待されています。本セッションの中では、「顧客体験の改善」、「サービス提供者の業務変革」、「データ活用の推進」、「ビジネスプラットフォームの再構築」という4つのテーマに分類して、re:Invent 2024 の交通業界を中心としたお客様事例と関連するサービスアップデートを紹介しました。今後、交通事業者様がデジタル技術を効果的に取り込む際の参考にしていただければと思います。 まとめ AWS re:Invent Recap 2024 建設・不動産・物流・交通業向けでご紹介した、各セッションの概要をご紹介いたしました。セミナーにご参加いただいた方、誠にありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考になりましたら幸いです。内容に関して、ご質問やご要望がございましたら、お問い合わせページ、もしくは担当営業までご連絡をお願いします。 本ブログはソリューションアーキテクトの堀 竜慈 、山中 真人 、寺山 怜志 、山本 大貴が執筆しました。

※ この記事はお客様に寄稿いただき AWS が加筆・修正したものとなっています。 本稿は株式会社 NTT ドコモ モバイル空間統計 における AWS Glue を活用したリアルタイムストリーミング処理の取り組みについてご紹介します。取り組みのご紹介は全二回となっており、第二回となる本編では Glue を新規採用する際の開発面での課題と Glue ストリーミングジョブのパフォーマンス改善の取り組みについてご紹介します。 第一回は コスト削減の取り組み についてご紹介していますので、こちらも併せてご覧ください。 以下、本システムにおける構成図を再掲します。 Glue のパフォーマンス課題 Glue ジョブパフォーマンス改善のアプローチ モバイル空間統計では大量に流れ込む位置情報データを遅延なくリアルタイムに処理し続けられることが求められます。今回 Glue へ移行するにあたり、Spark アプリケーションとして実装し直して既存と変わらないパフォーマンスを出せるかという点が最も重要な課題となっていました。 パフォーマンスの改善には、まずプロファイルを取ることが重要です。Python にはいくつかのプロファイラが存在しており、それらを利用してプロファイルを取得し、パフォーマンス改善やデバッグを進めることができますが、 Spark では同じ方法で取得することは出来ません。今回私たちが採用した手段は以下の 2 点です。 1. Spark History Server(Spark UI)による Glue ジョブ実行状況、ノード稼働状況の可視化 Glue ジョブの詳細や各ノードの状況を把握するための方法としては Spark History Server(Spark UI) ※1 を利用できます。Job details で実行時にログを出力する設定を行えば、ジョブ実行後に指定の S3 にログが出力されます。ブラウザ上で Spark UI にこのログを読み込ませ、ジョブ実行内容を可視化します。この Spark UI は Docker イメージ が公開されていますので、ローカルマシン上で簡単にコンテナ実行することで利用可能です。また、AWS マネジメントコンソールからもワンクリックで起動することもできます。主に以下の目的でパフォーマンス改善に活用しました。 使用効率の観点から、各ワーカーが均等に稼働できているか(executor ごとに処理対象のデータ量に偏りはないか)を把握する。 Spark における各ジョブ(Glue ジョブではないことに注意)の処理時間を確認し、どの処理がボトルネックとなっているかを特定する。 （※1）Spark UI を利用することで、各ワーカーノードでのタスクの分散状況を可視化することができます。これにより、効率的な分散処理が行われているかどうかを確認し、行われていない場合はワーカーノードの数を調整できます。 以下の図は Spark UI のスクリーンショットで、ワーカーノードのCPU上で動作したあるタスクの実行時間を示す棒グラフです。この例では、 2vCPU のワーカーノードで動作させた際に分散処理がうまく働いていないことがわかります。タスクが終了したのちに新たなタスクが始まっている様子が図の赤枠の部分で確認できます (緑色の線が一度途切れた後、新たな線=タスクが始まっています)。これは、処理が並列で行われていないことを示しています。この現象は、タスク数(入力データの分割数)に対して Glue 側の vCPU コア数が足りていないことが原因です。このような状況を改善するために、ワーカーノードの台数やワーカータイプの変更を検討します。 以下の図は改善結果です。ワーカータイプを 2vCPU(G.025X) から 4vCPU (G.1X)に変更し、最大ワーカー数もタスク数に合わせて増やしました。その結果、上図では一部のCPUが複数回タスクを処理する非効率な状態でしたが、下図では全てのCPUがそれぞれタスクを1回で並列に処理する効率的な分散処理の状態に改善できました。 2. Glue ジョブメトリクスによるジョブのパフォーマンス計測 Glue の Job details にはジョブメトリクスを集計する設定があり、これを有効にすると、メトリクスが集計されます。今回ストリーミングジョブのパフォーマンスを評価するため、特に把握したかったのはマイクロバッチ処理ごとの処理時間です。ウィンドウサイズ(マイクロバッチが 1 回あたりで処理するストリーミングデータの時間枠)に対して、それよりも短い時間(理想は 70% 未満の時間)でバッチ処理が完了していれば、リアルタイムに対して遅延なく処理ができていると判断できます。Glue ジョブメトリクスの中に batchProcessingTimeInMs があり、マイクロバッチごとの処理時間(ms)が分かります。これをもとにして、ウィンドウサイズに対するマイクロバッチの処理時間の比率を示すメトリクス(Process rate という名前をつけています)を算出し、これを評価することにしました。 Process Rate = batchProcessingTimeInMs * 1000 / windowSize(s) この Process Rate が 1.0 を超えない状態で安定稼働するかどうかを判断基準としてパフォーマンス改善を進めました。 Spark アプリケーションのパフォーマンスの改善 Spark アプリケーションとしてのパフォーマンスチューニング PySpark というライブラリを用いれば、 Python で Spark アプリケーションを実装できます。ただし、Pythonと同じ感覚で実装するだけではパフォーマンスが向上せず、Spark の特性(遅延評価の仕組み、変換とアクション、シャッフルとステージなど)を理解することが重要です。 Glue のパフォーマンスチューニングについては、 AWS が公開している Spark のチューニングに関するガイドなどに従って、内部設計の改善を進めました。このように、Spark UI でジョブの実行状況を可視化し、パフォーマンスを詳細に把握した上で試行錯誤を通じてパフォーマンス改善を進める必要がありました。 Kinesis Data Streams のシャード数に応じた Glue のワーカータイプ、ワーカー数の検討 今回 Glue ストリーミングジョブが接続する入力元は Amazon Kinesis Data Streams です。Glue のワーカータイプやワーカー数を設定する際には、Kinesis Data Streams のシャード数を考慮する必要があります。Spark アプリケーションとして効率的な分散処理をするため、全ての Executor ノードにデータが均等に行き渡る状態が求められます。全てのCPUコアを余すことなく利用するためには少なくとも Executor ノードの数(=Glue ワーカーごとの vCPU コア数の総数)以上にデータが分割された状態である必要があります。このデータの分割数(以下パーティション数)は、 Kinesis Data Streams のシャード数と一致 します。一方でパフォーマンス効率の観点では全てのパーティションを１並列で処理するために Glue 側では、Executor ノードの合計 vCPU コアが Kinesis Data Streams のシャード数以上となるように準備する必要があります。これによって必要なワーカー数が決定されますが、どのワーカータイプを選定するのが適切かという検討も必要です。ワーカータイプの選定に関しては、以下を考慮しました。 DPU あたりの vCPU コア数(G.025X は他のインスタンスタイプと比べて、vCPU/Memory の比率が高く、コア数が多くメモリが少ない) ワーカータイプは Driver ノードと Executor ノードで別々に指定できないため、Driver ノードが過剰に高スペックとならないような考慮 これらの要素をもとに、最適なワーカータイプを決定しました。今回のワークロードではストリーミングデータ処理を行うため、個々のデータサイズが非常に小さく、メモリ量よりも CPU コア数の確保を優先すべきと判断し、G.025X のワーカータイプを候補として選定しました(G.025X は、ストリーミングジョブを想定したワーカータイプとして用意されています)。しかしながら、実際に G.025X で動作検証をしたところ、Driver 側で動く Python プロセスが使用するメモリが不足する問題が発生したため、最終的にはワーカータイプは G.1X を採用しました。もちろん G.2X でも動きますが、Driver のスペックとしてはオーバースペックとなり、ワーカー 1 台あたりの vCPU コア数も多くなり(G.2X の vCPU コア数は 8)、必要以上にコア数を確保して余らせてしまうことになる可能性が高く、コストが無駄にかかって非効率なため、このワーカータイプの選定は非常に重要です。 ※2 (※2) Glue の ワーカータイプ は G.025X が2vCPU, 4GB メモリと 1:2 の比率になりますが、G.1X 以上のサイズのワーカータイプは 1:4 の比率となります。 まとめ 本記事では AWS Glue への移行に伴うパフォーマンス問題とその対応についてご紹介しました。 Glue 上で動作する Spark の特性を把握し、Spark UI によるジョブ実行状況を詳しく可視化することでパフォーマンスの改善を進めることができました。また、Kinesis Data Streams のシャード数、Spark がデータを読み込む際のデータ分割数との関係を考慮し、Glue のワーカータイプや最大ワーカー数を適切に決定できました。 コスト削減においては Glue と S3 の二つのサービスに対して効率的なコスト削減を実施しました。以上のような取り組みにより、リアルタイムで膨大なデータ処理を継続的に行うために必要なパフォーマンスをAWS Glueにて実現することができました。 今後の取り組み 今回のシステムではメンテナンス性・オートスケール機能の観点で AWS Glue を選び、クラウドへの移行・ビッグデータ処理の改善を進めることができました。また、 EMR on EC2 でスポットインスタンスを使い、コスト削減の検証を進めています。今後もメンテナンス性を維持しながら、さらなる運用コストの削減を目指していきます。 総括 第一回 と本記事で「モバイル空間統計」における AWS Glue への移行を進めていく中での課題と解決策・ポイントについてご紹介しました。 AWS Glue により運用効率とスケーラビリティを両立したシステム運用が可能となりました。 本事例がAWS Glue を活用したリアルタイムストリーミング処理を検討している皆様への参考になれば幸いです。 著者 株式会社 NTT ドコモ コンシューマサービスカンパニー 第一プロダクトデザイン部 マーケティングイノベーション・カスタマーサクセス 土屋 慶和 株式会社NTTドコモでクライアントサーバシステムやspモード ® の大規模NWのアーキテクト検討や スーパー販促プログラム ® の立ち上げ・プロジェクトマネージャーを担当し、現在は モバイル空間統計 ・ di-PiNK ® DMP のプロジェクトマネージャーとして従事しています。 NTT コムウェア株式会社 NTT IT 戦略事業本部 DigitalDesign&amp;DevelopmentCenter DataManagementPartner部門 データビジネス担当 市川 大助 NTT コムウェアにて IT アーキテクトを中心にフルスタックエンジニアとしてシステムの開発、更改、運用に従事してきました。現在はマネージャーとして、ドコモグループの様々なデータ分析業務チームを統括しています。 NTT テクノクロス株式会社 IOWN デジタルツインプラットフォーム事業部 第二ビジネスユニット 岳野裕也 NTT テクノクロスにて、Python エンジニアとしてデータ分析システムの PoC・開発等に従事してきました。現在はモバイル空間統計関連システムの開発リーダー兼リードエンジニアとしてチーム管理や技術面の課題解決等を担当しています。 アマゾン ウェブ サービス ジャパン合同会社 平川大樹 ソリューション アーキテクトとして通信業界のお客様の AWS 活用 を支援しています。

※ この記事はお客様に寄稿いただき、AWS が加筆・修正したものとなっています。 本稿は株式会社 NTT ドコモ モバイル空間統計 における AWS Glue を活用したリアルタイムストリーミング処理の取り組みについてご紹介します。取り組みのご紹介は全二回となっており、第一回の本編ではモバイル空間統計で Glue が採用された背景とストリーミング ETL アプリにおけるコスト削減についてご紹介します。 第二回では Glue Streaming ジョブのパフォーマンス改善 についてご紹介します。 はじめに NTTドコモは「つなごう。驚きを。幸せを。」をブランドスローガンとして掲げながら、通信事業、金融決済サービス、動画・音楽・電子書籍等配信サービス、マーケティングソリューション、あんしん系サポートなど多岐にわたる事業を展開しています。 本記事ではその中から「モバイル空間統計®」 ※1 での取り組みを紹介します。 「 モバイル空間統計 」とは、ドコモの携帯電話ネットワークのしくみを使用して作成される人口の統計情報です。1 時間ごとの人口を、24 時間 365 日把握することができます。また、「性別」「年代」「居住エリア」「国・地域」などの切り口から人口を分析することができます。エリアの特徴（分布）や人々の動き（移動）を、時間帯ごと（推移）に継続して把握できるのが最大の特徴です。具体的には、携帯電話の基地局がエリア内に存在する携帯電話の位置を周期的に把握し、その情報をもとに推計される人口統計データを生成します。この仕組みにより、特定エリアの人口や人の流れを明らかにすることが可能です。また、国内居住者だけでなく、訪日外国人の動向も把握できます。 ドコモが提供する「モバイル空間統計」は、大きなサンプルサイズによって高い信頼性を誇り、プライバシーにも配慮された安全な統計情報として評価されています。そのため、官公庁、自治体、研究機関、民間企業など、幅広い分野でマーケティングや防災計画のために活用されています。 ※1 モバイル空間統計は株式会社 NTT ドコモの登録商標です。 システム概要 モバイル空間統計は、オンプレミスとクラウド(国内リージョンを利用)を融合させたハイブリッド型システムです。モバイル空間統計は集団の人数のみをあらわす人口統計情報であるため、お客様個人を特定することはできません。お客様のプライバシーを保護するために、個人識別性を除去する「非識別化処理」、ドコモの携帯電話普及率を加味して人口を拡大推計する「集計処理」、さらに少人数を除去する「秘匿処理」を適切に実施しています。上記の処理では、ビッグデータ（国内居住者については約 8900 万台 ※2 、訪日外国人に関しては約 1200 万台 ※3 の運用データ ※4 ）を活用しています。 モバイル空間統計では、日本全国の携帯電話ネットワークの運用データをモバイル空間統計の統計作成システムへ高い信頼性でリアルタイムに取り込んでおり、その処理には、オンプレミスサーバーを活用してきました。今回の取り組みでは、クラウドシフトの試金石として、国内居住者の分布統計等で利用するデータを統計システムへ取り込む部分（下図参照）について、PoC（概念実証）の一環としてマネージドサービスを活用することを検証しました。 処理のイメージは下図の通りです。大量の位置情報データ（ストリームデータ）を Amazon Kinesis Data Streams で取り込み、AWS Glue でリアルタイムにストリーミングデータを変換し、 Amazon S3 を経由して各種統計処理システムに取り込みます。 ※2 2024 年 3 月（本台数より法人名義の契約データ等を除去して推計） ※3 2019 年実績 ※4 携帯電話をいつでも接続可能な状態に保つために必要なデータ 現状認識とクラウドシフトにおけるアーキテクチャ選定について 昨今のハードウェアと電気代の高騰により、オンプレミスの利用はコストリスクとなっています。データ処理の需要増が予想される中、安価にスケーラビリティを確保するため、クラウドへの移行を検討しています。特に、マネージドサービスを利用することで、メンテナンスの手間を省きながら、スケーラビリティを高めつつコストの削減が可能と考えています。マネージドサービスの選定において、他の選択肢（ Amazon EMR 、 AWS Lambda 等）含めて検討した結果、最終的に AWS Glue Streaming（以下 Glue） ※5 を選びました。 （※5）AWS Glue Streaming は Apache Spark Streaming フレームワークを活用した、ストリーミングデータを大規模に分散処理可能なサーバレスサービスです。Kinesis Data Streams や Amazon MSK といったデータソースからストリーミングデータの ETL 処理を行い、Amazon S3 や Amazon Redshift 、 Amazon Aurora など様々なデータターゲットにデータの取り込みが可能になっています。 選択理由はいくつかありますが、まず、Kinesis Data Streams からのデータの取り込みに加えて、データ変換処理を実施する必要があったことから AWS Glue Streaming が有力と考えました。その上で、メンテナンス性については Glue はフルマネージドのサーバレスサービスで、インフラ管理の負担を大幅に軽減できる点が魅力でした。また、オートスケール機能についても Glue は処理負荷の変動に合わせて自動的にリソースの調整を行い、コストを抑えることができるため、長期で利用するのに適していると判断しました。 既存のプラットフォームから AWS Glue への移行を進める中でいくつかの課題が発生しました。ここではコスト削減の取り組みについて説明します。 コスト削減 Glue ストリーミングジョブにおけるコスト削減には「Glue ストリーミングの Auto Scaling の活用」と「S3のコスト削減」の二つのアプローチを取りました。それぞれについて説明します。 Glue ストリーミングの Auto Scaling 機能の活用 Glue の課金体系と Auto Scaling Glue は 東京リージョンで 1時間・1DPU あたり 0.44 USDのコスト (2025 年 3 月時点) がかかる時間従量制の課金体系となっています。そのため、処理負荷に応じて必要以上の DPU を使用しないようにすることでコスト削減につながります。Glue ストリーミングジョブにもこのようなコスト削減の要望に答えてくれる Auto Scaling 機能が備わっていますので、これを採用できるか検証を行いました。Glue ストリーミングジョブの Auto Scaling は、Job details 画面にてスケールアウトする最大のワーカー数を指定するだけで、後は Glueが自動で処理状況を見ながらスケーリングを実行します。 負荷環境における Auto Scaling の検証、効果確認 Auto Scalingが処理対象のストリームからのデータ流入量の変動に応じて適切にスケーリングするかどうかは、実際に稼働させて検証しました。商用環境相当の負荷がなければ、実際の運用において必要なDPUを見極めることが難しく、実際のスケーリングの挙動が把握することができないため、スモールデータではなく商用環境相当の負荷のある環境下で検証を実施しました。Active なワーカー数の推移は Glue のジョブメトリクスから把握できるため、ストリーミングジョブを実行中にこれを確認します。傾向としては、起動時に最大数のワーカーが立ち上がり（下図赤枠①緑線)、その後負荷状況に応じてスケールイン・スケールアウト（下図赤枠②緑線）していく形でした。 Auto Scaling の内部的な仕組みとそれを意識した対応 Glue Streaming では、ジョブメトリクスの一つである batchProcessingTimeInMs でマイクロバッチの処理時間が取得可能です。自動スケールでは設定された windowSize （マイクロバッチの起動間隔）内でジョブが完了しているかどうかを判断し 自動スケーリングに活用しています。 Spark アプリケーションのパフォーマンスを改善すると batchProcessingTimeInMs が短くなるため結果的に必要なワーカー数が少なくなり、コスト削減に繋がります。 そこからは 第二回の記事 で述べるパフォーマンスの改善を進め、稼働時間に対する平均的な単位時間あたりの DPU(DPU hours を稼働時間で割った値) が減少することを確認しました。 S3 のコスト削減 コスト削減ポイント S3 の料金には、ストレージ容量とリクエスト数が大きく影響します。そのほかにもデータ転送量も従量課金の対象ですが、今回はこれらの要素のうち、 ストレージ容量とリクエスト数に焦点を当ててコスト削減に取り組みました。今回のシステムにおいて S3 コストが増加する原因は、S3 へ書き込むファイル数が膨大となっていることでした。このため、 PUT リクエスト数が増加し、多くの小さいファイルがストレージ容量を使用するため、データのオーバーヘッドが大きくなりました。ファイル数が膨れ上がっているのは、Spark でデータ処理をしており、出力データも分散された状態で出力されるからです。 具体的な対応内容 今回の対応では、分散されたデータを事前に結合し、出力ファイル数を減らしました。具体的には、Spark の API である coalesce() や repartition() を用いて、分割されたデータを出力直前に結合し直す対応を行いました。ファイルの結合数に関する検証を複数のパターンで行いましたが、結合数が多すぎると、結合処理自体にかかる時間が増加し、その結果マイクロバッチ処理時間が延長され 、DPUの消費量が増大することが判明しました。パフォーマンスに影響しない範囲で出力ファイル数を適切にコントロールし、S3 のストレージ容量と PUT リクエスト数を減らすことが重要です。今回の S3 コスト削減では、分割されたままのデータを書き出していた時の S3 リクエストコストに対して repartition() を用いた結合を行うことにより検証当初と比較して 約 9 割ものコスト削減 が達成できることが確認されました。 まとめ 本記事では AWS Glue への移行に伴うコスト削減の課題と、Glue と S3 の二つのサービスでコスト削減の対応についてご紹介しました。 Glue については、実行時間ベースの料金体系と Auto Scaling の仕組みを利用することで、パフォーマンスの向上がコスト削減につながりました。また、Glue のマネージドサービスとしての強みを活かし、データの流入量に応じてワーカー数が自動で最適な数にコントロールされてランニングコストの最小化を行うことができ、Kinesis Data Streams からのデータ流入量の増減に対する十分な柔軟性を確保することができました。 S3 については、ストレージ容量とPUT リクエスト回数の削減のため、Spark アプリケーションから分散データを結合して出力することで約 9 割のコスト削減に成功しました。 第二回では Glue ストリーミング のパフォーマンス改善 についてご紹介します。 著者 株式会社 NTT ドコモ コンシューマサービスカンパニー 第一プロダクトデザイン部 マーケティングイノベーション・カスタマーサクセス 土屋 慶和 株式会社NTTドコモでクライアントサーバシステムやspモード ® の大規模NWのアーキテクト検討や スーパー販促プログラム ® の立ち上げ・プロジェクトマネージャーを担当し、現在は モバイル空間統計 ・ di-PiNK ® DMP のプロジェクトマネージャーとして従事しています。 NTT コムウェア株式会社 NTT IT 戦略事業本部 DigitalDesign&amp;DevelopmentCenter DataManagementPartner部門 データビジネス担当 市川 大助 NTT コムウェアにて IT アーキテクトを中心にフルスタックエンジニアとしてシステムの開発、更改、運用に従事してきました。現在はマネージャーとして、ドコモグループの様々なデータ分析業務チームを統括しています。 NTT テクノクロス株式会社 IOWN デジタルツインプラットフォーム事業部 第二ビジネスユニット 岳野裕也 NTT テクノクロスにて、Python エンジニアとしてデータ分析システムの PoC・開発等に従事してきました。現在はモバイル空間統計関連システムの開発リーダー兼リードエンジニアとしてチーム管理や技術面の課題解決等を担当しています。 アマゾン ウェブ サービス ジャパン合同会社 平川大樹 ソリューション アーキテクトとして通信業界のお客様の AWS 活用 を支援しています。

AWS Cloud Development Kit (CDK) は、開発者が使い慣れたプログラミング言語でクラウドインフラストラクチャを定義できるオープンソースのフレームワークです。さらに CDK は高レベルの抽象化 ( Constructs ) を提供し、AWS 上でのシステム構築における AWS サービスの定義と統合に必要な複雑さを軽減します。CDK はまた、 CDK Assets のなどのコア機能も提供しており、ユーザーはアプリケーションアセットを CDK アプリケーションにバンドルすることができます。これらのアセットには、ローカルファイル (main.py)、ディレクトリ (python_app/)、または Docker イメージ (Dockerfile) を含めることができます。CDK Assets は、 CDK bootstrapping 時に作成される Amazon Simple Storage Service (Amazon S3) バケットまたは Amazon Elastic Container Registry (Amazon ECR) リポジトリに保存されます。 アセットを大規模に活用する CDK 開発者は、時間の経過とともにブートストラップされたバケットやリポジトリに古いデータや使用されていないデータが蓄積されることに気付くかもしれません。ユーザーが自分でこのデータをクリーンアップしようとしても、CDK は安全に削除できるデータを判断する明確な方法を提供していませんでした。この問題を解決するために CDK Garbage Collection のプレビュー版リリースを発表できることを嬉しく思います。これは、ブートストラップされた Amazon S3 バケットと Amazon ECR リポジトリ内の古いアセットを自動的に削除する CDK の新機能で、ユーザーの時間とコストを節約します。この機能は AWS CDK バージョン 2.165.0 から利用可能です。 CDK Garbage Collection により、お客様の CDK の使用体験を損なうことなく、関連するストレージコストを削減できるでしょう。 クイックスタート CDK Garbage Collection は、 gc という名前の CDK CLI コマンドとして提供されています。デフォルト設定で CDK Garbage Collection を使用するには、CDK アプリケーションのターミナルで次のコマンドを実行します。 cdk gc --unstable=gc --unstable フラグは、CDK Garbage Collection がプレビューモードであることを認識するためのものです。これは、この機能のスコープと API がまだ変更される可能性があることを示していますが、それ以外の点では、この機能は一般的に本番環境での使用が可能で、完全にサポートされています。 手順 CDK Garbage Collection は環境レベルで動作するため、 cdk gc を呼び出した AWS アカウントおよびリージョンにある孤立した (どこからも参照されていない) アセットを削除しようとします (翻訳者補足: CDK における環境 (Environment) は、アカウントとリージョンの組み合わせによって識別されます。詳しくは こちら のドキュメントを参照してください。)。このチュートリアルではカスタムの修飾子を使用して環境を再ブートストラップすることで、準備が整う前に孤立したアセットが削除されることを防ぎます。 cdk bootstrap --qualifier=abcdef --toolkit-stack-name=CDKToolkitDemo CDKToolkitDemo という名前の新しいブートストラップテンプレートと、それに関連するブートストラップリソースが作成されました。次に、Amazon S3 と Amazon ECR のアセットを含む CDK アプリケーションをセットアップします。 mkdir garbage-collection-demo &amp;&amp; cd garbage-collection-demo cdk init -l typescript app 次のステップでは、 lib/garbage-collection-demo-stack.ts の既存のコードを、以下の CDK スタックに置き換えます。 import * as path from 'path'; import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as lambda from 'aws-cdk-lib/aws-lambda'; export class GarbageCollectionDemoStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const fn1 = new lambda.Function(this, 'my-function-s3', { code: lambda.Code.fromAsset(path.join(__dirname, '..', 'lambda')), runtime: lambda.Runtime.NODEJS_LATEST, handler: 'index.handler', }); const fn2 = new lambda.Function(this, 'my-function-ecr', { code: lambda.Code.fromAssetImage(path.join(__dirname, '..', 'docker')), runtime: lambda.Runtime.FROM_IMAGE, handler: lambda.Handler.FROM_IMAGE, }); } } これにより、2 つの AWS Lambda 関数が作成されます。1 つは Amazon S3 アセットをソースコードとして使用し、もう 1 つは Amazon ECR イメージをソースコードとして使用します。参照されているアセットを CDK アプリケーションに追加する必要があります。 lambda/index.js にシンプルな Lambda 関数を追加します： exports.handler = async function(event) { const response = require('./response.json'); return response ; }; そして docker/Dockerfile にシンプルな Docker イメージを追加します。 FROM public.ecr.aws/docker/library/alpine:latest これで cdk deploy を実行して、CDK アプリケーションを AWS アカウントにセットアップすることができます。 cdk deploy \ --toolkit-stack-name=CDKToolkitDemo \ --context='@aws-cdk/core:bootstrapQualifier=abcdef' この時点で、ブートストラップされた Amazon S3 バケットと Amazon ECR リポジトリにアセットが正しく追加されていることを確認できます： 最初の AWS CDK デプロイ後、ブートストラップされた Amazon S3 バケットには 2 つのオブジェクトが存在します。 最初の AWS CDK デプロイ後、ブートストラップされた Amazon ECR リポジトリには 1 つのイメージが存在します。 出力には、両方のブートストラップされたリソースに期待どおりのデータが含まれていることが示されています。Amazon S3 バケットには、cdk deploy を実行したときに生成された AWS CloudFormation テンプレートの json ファイルも保存されます。 これで、両方のアセットを更新して、一般的な CDK 開発サイクルをシミュレートできます。 lambda/index.js にある Amazon S3 アセットに小さな変更を追加します： exports.handler = async function(event) { console.log('hello world'); const response = require('./response.json'); return response ; }; 同じことを docker/Dockerfile 内でも行います： FROM public.ecr.aws/docker/library/alpine:latest CMD echo 'Hello World' cdk deploy を再度実行すると、両方のアセットが新しいハッシュの下で再アップロードされるはずです。 2 回目の AWS CDK デプロイ後、ブートストラップされた Amazon S3 バケットには 4 つのオブジェクトが存在します。 2 回目の AWS CDK デプロイ後、ブートストラップされた Amazon ECR リポジトリには 2 つのイメージが存在します。 この出力から新しいアセットが追加されたことが確認できます。新しくブートストラップされたリソースを使用しているため、どのリソースが現在孤立しているか、そうでないかを判断できます。現時点では、 50f409b9 というプレフィックスが付いた ZIP ファイルのみが AWS CloudFormation で参照されており、Amazon ECR では a5801b5b というプレフィックスが付いたイメージのみが参照されています。つまり、他のすべてのアセット（Amazon S3 の 3 つのオブジェクトと Amazon ECR の 1 つのオブジェクト）は孤立しており、削除できます。 ローカルアセットではない追加のファイルが Amazon S3 にあることに注目してみましょう。これらは AWS CloudFormation テンプレートで、AWS CloudFormation に送信される前の中間ステップとして Amazon S3 にアップロードされたものです。これらのファイルはコピーされた後は不要であり、CDK Garbage Collection による削除の最適な候補です。 ここで CDK Garbage Collection の出番です。適切なパラメータを設定することで、アクティブに使用されているアセットに触れることなく、孤立したオブジェクトをクリーンアップすることができます。 cdk gc \ --unstable=gc \ --bootstrap-stack-name=CDKToolkitDemo \ --rollback-buffer-days=0 \ --created-buffer-days=0 アセットをすぐに削除したい場合（後で削除するためのタグ付けをするのではなく）は、 rollback-buffer-days を 0 に設定してください。また、作成されたばかりのアセットも削除したい場合は、 created-buffer-days も 0 に設定するようにしてください。created-buffer-daysのデフォルト値は1です。 ⏳ Garbage Collecting environment aws://912331974472/us-east-1... Found 3 objects to delete based off of the following criteria: - objects have been isolated for &gt; 0 days - objects were created &gt; 0 days ago Delete this batch (yes/no/delete-all)? CDK Garbage Collection が Amazon S3 から削除すべき3つのアセットを検出しました。これは想定通りの動作です。削除を確認するよう促されるので、削除したい場合は yes と入力してください。すると、次のような応答が表示されます： [100.00%] 4 files scanned: 0 assets (0.00 MiB) tagged, 3 assets (0.02 MiB) deleted. さらに以下のように続きます: Found 1 image to delete based off of the following criteria: - images have been isolated for &gt; 0 days - images were created &gt; 0 days ago Delete this batch (yes/no/delete-all)? 再度確認が促されますが、これは Amazon ECR のアセット削除のための質問なので、もう一度 yes と入力します。すると、次のような応答が表示されます： [100.00%] 2 files scanned: 0 assets (0.00 MiB) tagged, 1 assets (3.90 MiB) deleted. これで CDK Garbage Collection は完了です。 詳細 CDK Garbage Collection は、シナリオに応じて動作をカスタマイズするためのパラメータを提供しています。これらのオプションは、ガベージコレクションをどの程度積極的に行いたいかを決定するのに役立ちます。 rollback-buffer-days: アセットが削除の対象となるために、孤立した状態としてマークされていなければならない日数 created-buffer-days: アセットが削除の対象となるために、作成日から経過しなければならない日数 rollback-buffer-days は、 cdk deploy を使用せず、パイプラインのようにテンプレートのみで動作するデプロイメント方法を使用している場合に検討しましょう。パイプラインが CDK CLI を介さずにロールバックできる場合、このパラメータはアセットが早すぎるタイミングで削除されないようにするのに役立ちます。これを使用すると、 cdk gc は未使用のオブジェクトを削除する代わりに、現在の日付でそれらにタグ付けします。以降の cdk gc の実行では、このタグをチェックし、指定されたバッファ日数よりも長くタグ付けされている場合にのみアセットを削除します。 created-buffer-daysは、アップロードされたばかりのアセットについて特に安全を期したい場合に検討しましょう。これを使用すると、 cdk gc は作成後にその日数が経過していないアセットを除外します。ただし、これには複数の CDK アプリ間で共有されているアセットが含まれない場合があることに注意してください。CDK はアセットを再利用するため、最近デプロイされたCDKアプリでも、それよりも以前にアップロードされたアセットを参照している可能性があります。 例えば、1ヶ月以上経過し、かつ1週間孤立したものとしてマークされていたアセットのみを削除したい場合は、次のように指定できます： cdk gc --unstable=gc --rollback-buffer-days=7 --created-buffer-days=30. アセットがガベージコレクション対象として監査される際の判断フロー図です。 CDK Garbage Collection の制限事項 CDK Garbage Collection の実行中には、どのアセットが使用中かを確認するために、すべてのスタックのテンプレートを収集します。アセットのアップロードとスタックのデプロイメントの間にガベージコレクションが実行される場合、最新のスタックデプロイメントを検出できないが最新のアセットは検出するという状況が発生する可能性があります。このシナリオでは、CDK Garbage Collection がそれらのアセットを削除してしまう可能性があります。 CDK Garbage Collection の実行中にスタックをデプロイすることはお勧めしません。避けられない場合は、 --created-buffer-days を設定することで、最近作成されたアセットがガベージコレクションによって削除されるのを防ぐことができます。万が一デプロイに失敗した場合は、再デプロイすることで対処できます。アセットのアップロードステップで不足しているアセットを再アップロードできるためです。実際には、この競合状態は特定のエッジケースでのみ発生し、起こる可能性は低いです。しかし、私たちはこの競合状態のリスクを軽減するために、CDK アセットを保存する新しい方法に取り組んでいます。この作業はこの Issue で追跡されています。 まとめ CDK Garbage Collection は、ユーザーが AWS アカウント内の使用されていない CDK アセットのライフサイクル管理を支援します。ユーザーが CDK の活用規模を拡大し続ける中、CDK Garbage Collection のようなツールは、クリーンで効率的、かつコスト効果の高いクラウド環境を維持する上で重要な役割を果たします。CDK ユーザーの皆様には、ぜひこの機能を試し、 フィードバック を提供し、AWSリソース管理を最適化するためにワークフローに組み込んでいただけると嬉しいです。 本記事は 2025/2/21 に投稿された Announcing CDK Garbage Collection を翻訳したものです。翻訳は Solutions Architect : 国兼 周平 (Shuhei Kunikane) が担当しました。

この投稿は東日本旅客鉄道株式会社(以下、JR東日本)、 Deutsche Bahn AG（以下、ドイツ鉄道）、DB Systel GmbH、株式会社JR東日本情報システム（以下、 JEIS ）が、車両外観検査で撮影された画像の AI 活用に取り組む事例について寄稿いただいたものです。 JR東日本とドイツ鉄道は、 1992 年から技術分野における交流を続けている。本稿では、両社の技術交流における生成 AI の利活用事例について紹介する。両社は、労働力不足の軽減、検査時間の短縮、検査支援を目的にコンピュータビジョンを活用したプロジェクトを進めているが、従来の教師あり学習手法では、異常画像検知システムの開発に必要な学習データの準備が難しいという共通の課題があった。 上記課題を解決するため、 JEIS は JR東日本の協力のもと、大規模マルチモーダル AI を用いた異常画像検知システムの可能性に着目し、実現性の検証を実施した。なお、実際の異常画像の準備が難しいことから、本検証の性能評価用のテストデータとしては、画像生成 AI で生成した異常画像を使用することとした。 従来の機械学習モデルによる異常画像検知システムの開発には、ドメイン知識を持つユーザーが設備ごとにデータを収集し、専門知識を持つ技術者が適切なアーキテクチャの設計・開発を行う必要がある。しかし、高度な人的資源の確保は難しく、実用化が進まないのが現状である。 一方で大規模マルチモーダル AI を活用することで、これらの課題を克服できる可能性がある。大規模マルチモーダル AI とは、テキスト、画像、音声など複数の異なるデータ形式を統合的に処理することを目的に、大規模かつ多様なデータセットで学習された AI モデルである。この特性により、高い汎用性を持ち、画像だけでなくテキストやセンサーデータなどを統合的に解析することが可能で、ドメイン知識が限られている状況でも高精度な推論が期待される。 本稿で提案する大規模マルチモーダル AI による異常画像検知システムが実用化されれば、高度な人的資源に依存せずに AI の導入が可能になると期待される。検証結果は、同様の課題を抱える事業者への知見共有を目的として、 JR東日本およびドイツ鉄道の許可を得たうえで公開することとした。 本稿が、異常画像検知システムの実用化に向けた一助となることを期待する。 異常の定義 ドイツ鉄道では日々の検査のため、車両外観検査装置を用いて車両屋根を撮影している。この画像には、稀に落下物が写ることがあるが、この落下物は列車の運行に影響を与える可能性があるため、 AI を使用して、落下物を素早く発見して取り除く必要がある。以下に、過去に実際に発見された落下物の例を示す。車両屋根には落下物以外にも、部品の欠損やケーブルの緩みといった異常が発生する可能性があるが、本検証では対象外とした。 表 1 落下物の例 異常種別 説明 1. Branch 運行途中で車両屋根に落ちた枝 2. Roll メンテナンス作業員が置き忘れたテープ 3. Rag メンテナンス作業員が置き忘れた掃除用の布巾 4. Plastic Bottle 誰かによって投げ捨てられたペットボトル 5. Handbag 誰かによって投げ捨てられたハンドバッグ 6. Banana 誰かによって投げ捨てられたバナナの皮 7. Jacket 誰かによって投げ捨てられたジャケット 8. Paint 誰かによって投げ込まれたペイントによる汚れ 9. Bird 鳥の死骸 ジャケットやハンドバッグといった落下物は、一見すると非現実的に感じるが、これらの異常は全て実際に発生した事象であり、深刻なリスクを引き起こす可能性がある。しかし、こうした異常の多くは年に数回しか発生しないため、十分な異常画像を収集することが難しく、従来の手法による異常画像検知システムの開発が困難となる。そのため、大規模マルチモーダル AI によりこれらの異常画像検知が可能であるかを検証することとした。あわせて、大規模マルチモーダル AI の検証に十分な量の評価データを準備するにあたり、画像生成AIにより異常画像を生成する方法を提案する。 異常画像生成 画像生成には、生成の方向性をガイドするための「プロンプト」と、特定の要素を含めないようにするための「ネガティブプロンプト」が存在する。汎用的に高品質な画像生成に有効なプロンプトはあるものの、鉄道車両の異常画像を作成する前例は少なく、試行錯誤が必要である。以下は、 Amazon Titan Image Generator v1 を用いて、車両屋根上にバナナの皮を生成するためのプロンプトの例を示す。本検証では、このプロンプトを活用し、正常画像の一部領域に異常を生成することで、実際の異常に近い画像の生成に成功した。 ## プロンプト "raw photo,photo realistic, a solo yellow banana peel lying on a gray surface, weathered, dirty, nearly dead, old, shadows, detailed, angle from above" ## ネガティブプロンプト "low quality, out of focus, blurry, painting, sketch, monochrome, grayscale, fantasy, text, signature, stamp" 図 1 車両屋根上画像（左：正常画像、右：画像生成AIによる異常画像） 自動化プログラムの作成と検証 画像生成 AI は必ずしもプロンプトの記述通りの画像を生成するとは限らない。そのため、本物に近い異常画像を大量に生成するための自動化プログラムを実装した。このプログラムは、異常画像を繰り返し生成し、実際の異常画像に近い画像のみを選択することで、効率的に大量の異常画像データセットを作成することを可能にする。 図 2 自動化プログラムのフロー 自動化プログラムのフローは以下の通りである。異常画像の生成は、基となる正常画像と、異常種別ごとに用意したプロンプトリストを用いて実行する。 マスク画像の生成 正常画像に対して、異常を配置する座標（x, y）とマスク画像の大きさ（width, height）をプロンプトリストの条件に従って決定し、ランダムにマスク画像を生成する。 画像生成 正常画像とマスク画像を Amazon Titan Image Generator v1 （API）に入力して異常画像を生成する。 生成された異常画像の自動判定 生成された画像と異常種別の類似度が 20% 以上であることを確認する。 生成された画像と正常画像の類似度が 75% 以下であることを確認する。 上記の判定条件を 両方満たした場合、異常画像として保存する。 判定条件を満たさない場合、①に戻り再生成 する。 人手による画像の選別 保存された異常画像の中から、目視により異常画像を選別する。 図 3 生成した異常画像の例 （左上からBranch, Roll, Rag, Plastic Bottle, Handbag, Banana, Jacket, Paint, Bird） 本検証で用いた画像生成 AI による異常画像生成は、過去にドイツ鉄道が実施した画像処理ソフトを用いた異常画像生成と比較した結果、遠近法、オブジェクトのサイズ、影や反射の処理といった複雑な要素をより適切に処理できることが明らかになった。 大規模マルチモーダル AI による異常画像検知システムの検証 本検証では、大規模マルチモーダル AI として、 Amazon Bedrock から簡単に利用できる Anthropic Claude 3.5 Sonnet を活用することとした。 Anthropic Claude 3.5 Sonnet に対して、検査対象の画像とその画像に関する質問を入力し、画像解析の結果を出力させた。 図 4 大規模マルチモーダル AI による異常画像検知システムのイメージ 大規模マルチモーダル AI のプロンプト設計 大規模マルチモーダル AI から望ましい出力を得るためには、適切な指示（プロンプト）を設計するスキルが重要である。この技術は プロンプトエンジニアリング と呼ばれ、 AI に対して適切な問いかけや指示を与えることで、より正確で有用な回答を引き出すことができる。 例えば、 AI に複雑な問題を解かせる際に、「Let’s think step by step」という一文をプロンプトに加える手法がある。これにより、 AI は問題を小さなステップに分けて考えるようになり、論理的かつ構造化された回答をしやすくなる。 図 5 プロンプトの例 大規模マルチモーダル AI による異常画像検知システムでは、プロンプトを以下のような構造で設定している。 ロールの設定 1（You are Pro-mechanic） ロールの設定 2（If there are anomalies anywhere in the image, answer with True） 構造化された回答の要求（Let’s think step by step） 出力形式の指定（&lt;think&gt;&lt;/think&gt;, &lt;answer&gt;&lt;/answer&gt;） 異常画像検知システムの性能検証 本検証では、大規模マルチモーダル AI を用いた異常画像検知システムの性能を評価した。評価には、正常画像 50 枚および 9 種類の異常画像をそれぞれ 50 枚ずつ、合計 500 枚の画像データを使用した。検証結果を下記に示す。 表 2 異常種別ごとの正解率 異常種別 True False 正解率 1. Branch 50 0 100% 2. Roll 31 19 62% 3. Rag 49 1 98% 4. Plastic Bottle 50 0 100% 5. Handbag 50 0 100% 6. Banana 50 0 100% 7. Jacket 50 0 100% 8. Paint 50 0 100% 9. Bird 50 0 100% 10. Normal 48 2 96% 用語説明 True: AI が “異常” を正しく判定した枚数。 False: AI が “正常” と誤って判定した枚数。 Normal: 正常画像、 AI が “正常” と正しく判定した場合を True 、誤って “異常” と判定した場合を False とする。 正解率: (True / (True + False)) × 100 で計算された割合。 全異常種別の平均正解率は 95.6% 。正常画像の正解率は96%、適合率は99.5% 、再現率は 95.5% 、 F 値は 97.4％ を達成した。 適合率は AI が異常と判定した画像のうち、実際に異常であった割合を示している。つまり、誤って正常な画像を異常と判定することが少ないことを意味する。一方、再現率は実際に存在する異常画像のうち、 AI が正しく異常と認識した割合を示し、異常の見逃しが少ないことを表している。 これらのバランスを示す F 値が 97.4% と非常に高いことから、大規模マルチモーダル AI を用いた異常画像検知システムは、実用性があると判断できる。 ハルシネーション（幻覚） 大規模マルチモーダル AI が事実に基づかない情報を生成する現象をハルシネーション（幻覚）と呼ぶ。これは、文章生成の原理として、ある単語の次に来る可能性が最も高い言葉を順次出力する仕組みに起因する。本検証においても、稀に前後の文脈が不自然になるケースが確認された。以下の図は、大規模マルチモーダル AI による異常画像検知システムの出力結果の一例（異常種別：バナナ）である。このケースでは、大規模マルチモーダル AI が黄色の物体を検出しているにもかかわらず、「異常なし」と誤判定している。 本例では、異常判定の過程において、最初の 1 箇所目の検査で異常を検出したものの、その後の 7 箇所では異常が検出されなかった。このため、大規模マルチモーダル AI がテキスト生成の過程で最も確率の高い次の単語を予測する際に、「異常なし」と出力した可能性があると考えられる。 この問題を防ぐために、検査箇所ごとの出力結果を分析する別の言語モデルと併用し、「 1 箇所でも異常が検出された場合は異常と判定するアルゴリズム」を導入することで、誤判定を抑制できると考えられる。 図 6 大規模マルチモーダルAIの出力結果の例 実用化に向けた課題 近年、実証実験（PoC）による異常画像検知システムの検証が進んでいるが、PoC の段階を超えられない「 PoC 疲れ」が生じていると指摘されている。その要因の一つとして、従来の機械学習モデルをベースとした異常画像検知システムの開発には、ドメイン知識と高度な技術力を持つ人的資源が必要であり、さらに、 AI 導入による効率化を上回る保守コストが発生することが挙げられる。 例えば、設備 A と設備 B の異常画像検知システムを開発する場合、それぞれの設備画像を収集する必要がある。しかし、通常業務と並行して AI 導入のために新規のデータを収集することは容易ではない。特に、異常画像の撮影を目的として列車運行に影響を与えることは現実的に不可能である。仮に十分なデータが収集できたとしても、機械学習モデルの構築にはデータの前処理技術、適切なアーキテクチャの選定、機械学習モデルの開発に必要なプログラミング能力など、高度な専門知識を持つ技術者が求められる。さらに、異常画像検知システムの構築後には、システム化のための導入費や保守費が発生する。 これらの要因を総合的に考慮した結果、多くの企業が実用化を見送り、その結果として「 PoC 疲れ」が発生している。この状況を打開するためには、データ収集やモデル構築のプロセスを効率化し、導入および保守コストを削減するための新たなアプローチが求められる。 図 7 実用化に向けた課題 大規模マルチモーダル AI による異常画像検知システム 大規模マルチモーダル AI を活用した異常画像生成と、それを評価データとする異常画像検知システムは、上記の実用化に向けた課題の一部を解決する可能性がある。従来の機械学習に必要だったデータ収集コストを削減できるうえ、特定のタスクに応じたカスタマイズが比較的容易になる。また、本検証で示したように、プロンプトを適切に設計・調整することで、それぞれの設備に応じた異常画像検知が可能となる。 図 8 大規模マルチモーダルAIによる異常画像検知システム おわりに 大規模マルチモーダル AI の利用にあたっては、法的リスクや倫理的リスクを十分に考慮し、システム導入前にこれらの課題をクリアにする必要がある。例えば、 EU の「 AI Act 」では、 AI システムのリスクレベルに応じた厳格な規制が求められており、高リスクに分類される AI には透明性、説明責任、データガバナンスの確保が義務付けられている。特に、異常画像検知システムのような分野では、誤検知や判断のバイアスが社会的影響を及ぼす可能性があるため、倫理的側面を考慮した設計・運用が不可欠である。 一方で、本検証結果が示すように、大規模マルチモーダル AI の活用は、異常画像検知システムの精度向上や運用負担の軽減にも寄与する可能性が高い。今回の検証結果を踏まえ、鉄道事業における大規模マルチモーダル AI 活用のグランドデザインを策定し、異常画像検知システムの開発・保守の最適化を図ることで、安全性と経済性の両立を実現し、新たな価値創造の機会を拡大することができる。 大規模マルチモーダル AI の導入と活用を通じて、より安全で効率的な鉄道運行を支え、持続可能な未来を共に築いていきたい。 著者略歴 Stanford University US-Asia Technology Management Center 客員研究員　方志　卓朗（株式会社JR東日本情報システムから出向） 所長 Richard Dasher 東日本旅客鉄道株式会社 フロンティアサービス研究所 研究員　稲森　真由 株式会社JR東日本情報システム　テクノロジー応用研究センター エキスパート　齊藤　良太 Deutsche Bahn AG AI Specialist Philipp Skudlik 謝辞 東日本旅客鉄道株式会社 フロンティアサービス研究所 主幹研究員 小西 勇介 副主幹研究員 小林 郁生 研究員　姜　小楠 DB Systel GmbH Product Owner Peco Elenchevski

このブログは Time series forecasting with LLM-based foundation models and scalable AIOps on AWS&nbsp; を翻訳したものです。 時系列予測は、様々な業界で重要な意思決定を行う際に欠かせません。交通量の予測から売上予測まで、正確な予測によって組織は情報に基づいた決断を下し、リスクを軽減し、効率的にリソースを配分することができます。しかし、従来の機械学習アプローチでは、データに合わせた細かい調整やモデルのカスタマイズが広範囲に必要となり、開発に長い時間とリソースを要することがしばしばありました。 そこで登場したのが Chronos です。これは大規模言語モデル（ LLM ）のアーキテクチャを活用して、これらの障壁を打破する最先端の時系列モデルファミリーです。Chronos は基盤モデルとして、大規模で様々なデータセットを使って事前学習を行っており、多くの分野で使える汎用的な予測能力を持っています。この革新的なアプローチにより、Chronos はゼロショット予測（対象データセットに特化した訓練なしで行う予測）において優れた性能を発揮します。Chronos はベンチマークされたほとんどのデータセットにおいて、タスク特化型モデルを上回る性能を示しています。 Chronosは、大規模言語モデル（LLM）と時系列予測の両方が、「将来を予測するために連続的なパターンを理解する」という共通の目的を持っているという重要な発見から生まれました。この類似性により、時系列データを既存の transformer アーキテクチャによってモデル化された「言語」として扱うことができます。これを実現するために、Chronos は連続的な時系列データを「言語」として扱えるよう、次の 2 段階で離散的な「言語」に変換します。まず時系列の絶対平均でスケーリングし、次にスケーリングされたデータを一定数の均等な区間に分けて量子化します。この処理によって、連続的な数値データが LLM で処理できる離散的な「言語」に変換されます。 このブログ記事では、売上予測を例にテスト用に作成した合成データを使って Chronos を Amazon SageMaker Pipeline に統合するプロセスを案内します。これにより、最小限のデータで正確かつ効率的な予測が可能になります。ファインチューニングからデプロイメントまでの全ワークフローをオーケストレーションする機能の使い方を学びます。この解説を通じて、開発プロセスを合理化し、Chronos をあらゆる時系列データに適用して、予測アプローチを変革する準備が整います。 前提条件 SageMaker ドメイン へのアクセスと必要な IAM 権限 ：必要なリソースを作成・管理するために、適切な AWS Identity and Access Management（IAM） 権限を持つ SageMaker ドメインへのアクセスが必要です。ノートブックの作成、モデルのデプロイ、およびこの記事で説明するその他のタスクを実行するための権限があることを確認してください。 SageMaker ドメイン のセットアップ手順については、Amazon SageMaker AI のクイックセットアップをご参照ください。実際に試すには、 GitHub のコード をご覧ください。 こちらをクリックしてAWSコンソールを開き、操作を続けてください。 SageMaker Pipelines の概要 私たちは、トレーニングと評価の実験をオーケストレーションするために SageMaker Pipelines を使用しています。Amazon SageMaker Pipelines を使用すると、以下のことが可能になります： 複数の実験イテレーションを同時に実行し、全体の処理時間とコストを削減 Studio との統合により、各実験実行のパフォーマンスを監視および視覚化 さらなる分析、デプロイメント、またはモデル選択のためのダウンストリームワークフローを呼び出し 学習パイプライン データの生成 自然言語処理（NLP）分野で利用可能な広範囲で高品質なテキストデータセットと比較すると、公開されている時系列データの可用性と品質は限られています。この問題は特に、ゼロショット予測（事前の学習なしで予測を行うこと）を目指すモデルの学習において大きな課題となります。このような予測には大規模で多様な時系列データが必要であるからです。そこで、事前学習済みの Chronos モデルをファインチューニングするため、私たちは合成的に生成された小規模なデータセットのみを使用します。 多様な時系列パターンを生成するために、パイプラインの最初のステップでは基本となる時系列パターンを組み合わせて、合成したデータセットを作成します。これらの基本カーネルには、直線的な増減傾向、緩やかに変化する波形、季節ごとの周期的な変動など、時系列データの基本的な要素が含まれています。これらの基本パターンを足し算や掛け算などのランダムな演算で組み合わせることで、現実のデータに近い複雑な合成時系列データを作成します。このアプローチにより、シンプルな基本要素から出発して、多種多様で複雑な時系列パターンを効率的に生成できます。 この SageMaker Processing Job で実行されるデータ処理ジョブ は PyTorchProcessor を使用して実行され、SageMaker によって管理されるコンテナ内で PyTorch コード（ generate_data.py ）を実行します。データやデバッグ用のその他の関連アーティファクトは、SageMaker アカウントに関連付けられたデフォルトの Amazon Simple Storage Service（Amazon S3） バケットに配置されます。パイプラインの各ステップのログは Amazon CloudWatch で確認できます。 &nbsp; base_job_name = f"{pipeline_name}/data-generation-step" script_processor = PyTorchProcessor( command=['python3'], role=role, instance_count=1, instance_type="ml.c5.2xlarge", base_job_name=base_job_name, sagemaker_session=pipeline_session, framework_version='1.13', py_version='py39' ) ハイパーパラメータの探索 データ生成の後、事前学習済みの Chronos モデルをファインチューニングします。ファインチューニングにより、事前学習データでは十分に表現されていない可能性がある特定のユースケースに特化させることができます。この記事では amazon/chronos-t5-small を使用していますが、適切と思われる任意のモデルを使用することができます。以下の表は、利用可能なモデルを示しています。 Model Parameters Based on chronos-t5-tiny 8M t5-efficient-tiny chronos-t5-mini 20M t5-efficient-mini chronos-t5-small 46M t5-efficient-small chronos-t5-base 200M t5-efficient-base chronos-t5-large 710M t5-efficient-large 最適な出力を得るために、ハイパーパラメータチューニングを通じてモデルの最良のバージョンを見つける自動モデルチューニングを使用します。このステップは SageMaker Pipelines に統合されており、事前に定義したハイパーパラメータの範囲内で様々な手法を試しながら、複数のトレーニングジョブを同時に実行できるようになっています。私たちのパイプラインでは、モデルのパフォーマンスを最適化するために特に学習率をチューニングしています。SageMaker のハイパーパラメータチューニング機能を活用することで、対象タスクにおいてモデルの精度と汎用性を同時に高める可能性を向上させています。 estimator = PyTorch( role=role, instance_type=pipeline_parameters['training_instance_type'], output_path=f"s3://{bucket_name}/{pipeline_name}/models/", instance_count=1, source_dir='model', image_uri=train_image_uri, entry_point=model_name + ".py", base_job_name = f"{pipeline_name}/training/job", ) hyper_ranges = { 'learning-rate': ContinuousParameter(1e-5, 1e-4), } objective_name = "logloss" metric_definitions = [{"Name": objective_name, "Regex": "'loss': ([0-9\\.]+),"}] tuner_log = HyperparameterTuner( estimator, objective_name, hyper_ranges, metric_definitions, max_jobs=pipeline_parameters['max_jobs'], max_parallel_jobs=pipeline_parameters['max_parallel_jobs'], objective_type="Minimize", base_tuning_job_name=f"{pipeline_name}/HPTuning/{model_name}", random_seed=10 ) Amazon SageMaker Model Registry 選択されたモデルは、その後 SageMaker Model Registry にアップロードされます。このレジストリは本番環境に向けたモデルの管理において重要な役割を果たします。モデルを保存し、モデルのバージョンを整理し、コンテナイメージなどの重要なメタデータやアーティファクトを記録し、各モデルの承認状態を管理します。このレジストリを使用することで、アクセス可能な SageMaker 環境へのモデルのデプロイを効率的に行い、モデルのバージョン管理の基盤を確立することができます。 registration_steps = {} register_args = best_model.register( content_types=["text/csv"], response_types=["text/csv"], inference_instances=[instance_type], transform_instances=[instance_type], model_package_group_name=model_package_group_name, domain="MACHINE_LEARNING", description="Chronos", task="REGRESSION", framework="PYTORCH", image_uri=inference_image_uri ) registration_steps = ModelStep( name=model_name, step_args=register_args ) 推論 トレーニングパイプラインの完了後、モデルは SageMaker ホスティングサービスを使用してデプロイされます。これにより、 リアルタイム予測 のための推論エンドポイントが作成されます。このエンドポイントはアプリケーションやシステムとのシームレスな統合を可能にし、安全な HTTPS インターフェースを通じてモデルの予測機能にオンデマンドでアクセスできるようにします。リアルタイム予測は、株価予測やエネルギー需要予測などのシナリオで活用できます。 endpoint_name = "chronos-endpoint-" + time.strftime("%Y-%m-%d-%H-%M-%S", time.gmtime()) print(f"EndpointName: {endpoint_name}") model.deploy( initial_instance_count=1, instance_type="ml.p3.2xlarge", serializer=JSONSerializer(), deserializer=JSONDeserializer(), endpoint_name=endpoint_name ) predictor = Predictor(endpoint_name=endpoint_name) payload = {"inputs": input_data} jstr = json.dumps(payload) p = predictor.predict( jstr, initial_args={ "ContentType": 'application/json' } ) サンプルの予測結果 以下の図は、Chronos エンドポイントから得られたサンプル予測を示しています。 Chronos パフォーマンスのベンチマーク 上のグラフは、Chronos モデルのトレーニングに使用されていない 27 のデータセットに基づいた、様々な時系列予測モデルのパフォーマンス評価を示しています。このベンチマークでは、Chronos モデルのゼロショットパフォーマンスを、ローカル統計モデル、タスク特化型モデル、事前学習済みモデルと比較評価しています。評価には、確率的予測（WQL）と点予測（MASE）の 2 つの指標が使用されており、どちらも季節性を考慮したナイーブベースラインを用いて正規化されています。結果は幾何平均によって集計されています。なお、上記に示されている事前学習済みモデルの一部は、このベンチマークで使用されているデータセットに対して事前に学習済みであったことが指摘されています。 ゼロショットの結果は「 Chronos: Learning the Language of Time Series 」から引用されています。 まとめ このブログ記事では、LLM アーキテクチャに基づく強力な時系列予測モデルである Chronos をデプロイするために、Amazon SageMaker MLOps 機能をどのように活用するかを紹介しました。SageMaker Pipelines を使用することで、高度な予測モデルを大規模に構築、トレーニング、デプロイするための包括的なアプローチを示しました。この実装は、モデル開発の効率性、スケーラビリティ、合理化された AIOps、リアルタイム推論機能、およびコスト効率の良さを提供します。Chronos と SageMaker の統合により、様々な業界の企業は、社内に広範な機械学習の専門知識を持たなくても、高度な時系列予測を実装できる新たな可能性を手に入れることができます。AI と機械学習が進化し続ける中、Amazon SageMaker 上の Chronos のようなソリューションは、高度な予測技術をより身近で実用的なものにする重要な一歩であり、業界全体でより情報に基づいた意思決定と運用効率の向上につながる可能性があります。 参照 Chronos forecasting Adapting language model architectures for time series forecasting Robust time series forecasting with MLOps on Amazon SageMaker ご意見やご質問がございましたら、お気軽にコメントをお寄せください！ 著者 Alston Chan は Amazon Ads のソフトウェア開発エンジニアです。詳細ページでの商品レコメンデーション向けの機械学習パイプラインとレコメンデーションシステムを構築しています。仕事以外では、ゲーム開発とロッククライミングを楽しんでいます。 &nbsp; Maria Masood は AWS Commerce Platform でデータパイプラインとデータ可視化の構築を専門としています。自然言語処理、コンピュータビジョン、時系列分析をカバーする機械学習の専門知識を持っています。心からのサステナビリティ愛好家である Maria は、休日にガーデニングと愛犬との遊びを楽しんでいます。 &nbsp; Nick Biso は AWS プロフェッショナルサービスの機械学習エンジニアです。データサイエンスとエンジニアリングを活用して、複雑な組織的・技術的課題を解決しています。さらに、AWS クラウド上で AI/ML モデルの構築とデプロイを行っています。彼の情熱は、旅行と多様な文化体験への嗜好にも表れています。

本ブログは株式会社サンブリッジ様と Amazon Web Services Japan が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの杉山です。 生成 AI の活用シーンが急激に増えてきており、今この瞬間に時代が変化しているのだと感じる毎日です。本日は、社内の業務効率化における生成 AI の活用事例として、株式会社サンブリッジ様 (以下、サンブリッジ様) の取り組みをご紹介します。わずか 2 週間という短期間で構築された社内向け AI チャットボットが、どのように業務改革を実現したのか、その導入プロセスから具体的な成果までをお伝えしていきます。 株式会社サンブリッジ 様は、企業のビジネスモデルに合わせて AWS や Salesforce をはじめとした、お客様の課題解決において最適なクラウドサービスを用いてビジネス分析や導入、運用までをワンストップでトータルコーディネートし、お客様のビジネス拡大・業務改善を支援する企業です。今回、サンブリッジ様は AWS Japan が主催する「生成 AI コンテスト」に参加したことをきっかけに、Amazon Bedrockや Amazon Kendra といった AWS のサービスを組み合わせて、わずか 2 週間で社内向けの AI チャットボットを構築しました。Slack とのシームレスな連携によって問い合わせ対応を集約し、1 週間で累計 1,750 分もの業務時間削減を実現しています。 背景と課題 サンブリッジ様では、企業成長とともに社員数および社内ドキュメントの量が増大してきました。ドキュメントはクラウドストレージやファイルサーバなどに分散しており、アクセス方法も保管場所も統一されていない状態が続いていました。このため、必要な文書へアクセスするだけで大きな手間が発生し、対応に時間がかかる場面が日常的に見受けられました。さらに、部署やプロジェクトによってチャットツールが異なるなど、問い合わせチャネルが複数存在していたことも問題となり、同じような質問が部署ごとに何度も繰り返されるケースが生じていました。結果として特定の社員に問い合わせが集中し、問い合わせを受ける側は「同じ回答を繰り返す」「一貫した回答をするために最新の資料を探す」などの作業に時間を費やす状況になっていました。 ソリューション構築のアプローチ こうした課題を解消するため、サンブリッジ様は AWS Japan 主催の「生成 AI コンテスト」に参加し、社内向けの AI チャットボットを構築するプロジェクトに取り組みました。プロジェクトの進め方としては、まずコンテスト期間という明確な締め切りがあるため、短期間で検証から実装・運用開始まで走り切ることを目標に設定しました。チャットボットには Amazon Bedrock を活用し、大規模言語モデル (LLM) が柔軟かつ安全に応答を生成できるようにしています。さらに Amazon Kendra を組み合わせることで、高精度な検索結果を得られる仕組みも導入されました。これによりチャットボットが回答を生成する際に、質問と関連性の高い文書やナレッジを素早く検索し、根拠のある回答を提示できるようになりました。 接続されるチャットツールとしては Slack を採用し、既に社員が日常的に使っている環境へスムーズに組み込みました。短期間のプロジェクトであることからスコープは最小限に絞り、PoC (概念実証) レベルで AI チャットボットのコア機能を作り込んだうえで、本番環境でのクローズドテストを実施して精度向上や機能追加を行う手法を採用しました。社内文書はおよそ 9,000 件をKendra に登録し、Retrieval-Augmented Generation (RAG) の手法で回答と一次情報 (文書ソース) を紐付ける仕組みも取り入れることで、回答の信頼性を高めています。 導入後の成果 この AI チャットボットは約 80 名の従業員を対象に早期からテスト稼働が行われました。稼働開始から 1 週間で、250 回以上の問い合わせと回答が Slack 内でやりとりされ、従来の問い合わせ対応が抱えていた課題の大部分が解消されています。 1 回の問い合わせに要していた時間は平均 7 分程度であると計算されており、チャットボットを導入して 1 週間の間に対応業務が累計 1,750 分 (約 29 時間) 削減できたという試算が得られました。これは、以前は担当者がドキュメントを探したり他部門と連携を図ったりして回答していた手間を省けるようになったことが大きく寄与しています。回答の根拠となる文書 URL も自動で提示されるため、回答の信頼性が向上しただけでなく、「どこを参照すればよいのか」が明示されることで、社員の情報リテラシー向上や文書の管理意識の再確認といった副次的効果も生まれています。 今後は AWS Glue を活用したコンテンツ収集・登録の自動化を視野に入れており、より多くの社内文書を継続的に Kendra へ取り込むことで、回答の網羅性を高める計画です。サンブリッジ様はこれによって、累計で 50,000 分 (5人月以上) に相当する工数を削減できる可能性を見込んでいます。 今後の展望とまとめ サンブリッジ様は生成 AI コンテストという外部イベントに参加することで、AI チャットボット導入のアイデアを短期間で具体化し、さらに実際の業務上の課題を解決する段階まで速やかに移行できました。今回導入したチャットボットは、すでに問い合わせ集約と回答の一元化による効果を示しており、その成功を踏まえて今後はさらなる機能拡張に着手する方針です。 例えば社内で利用する他のチャットツールや CRM (Salesforceなど) とも連携し、問い合わせの履歴や回答内容をスムーズに共有するなどのアイデアが検討されています。RAG の高度化やユーザーインターフェイスの改善によって、回答の精度向上や使い勝手の向上を追求していく計画です。 サンブリッジ様の取り組みは、わずか 2 週間でチャットボットを立ち上げ、1 週間で 1,750 分の業務効率化を実現するという成果をあげています。こうした成功の背景には、Amazon Bedrock やAmazon Kendra といった AWS のサービスを柔軟に組み合わせ、既存のコミュニケーション基盤である Slack と連携させるという、精度・実用性・導入ハードルを両立する設計上の工夫があります。 「AWS が主催する生成 AI コンテストに参加することで、ユースケース選定からサービス実装までを短期間で実現することができました」と語るのは、株式会社サンブリッジ 執行役員の山﨑 秀樹氏です。その言葉の通り、本事例は生成 AI を業務改善に役立てたいと考えている企業にとって、多くの示唆を与えるものと言えるでしょう。 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

この記事は2025 年 3 月 7 日に公開された「 Introducing an enhanced local IDE experience for AWS Step Functions 」を翻訳したものとなります。 本記事は、シニアソリューションアーキテクトの Ben Freiberg が執筆しました。 AWS Step Functions は、ステートマシンの構築をより簡単にするために、ローカル IDE 機能がより強化されました。これにより、Workflow Studio が AWS Toolkit 拡張機能を通じて Visual Studio Code (VS Code) で利用できるようになりました。 開発者は AWS コンソールと同じ強力な視覚的な編集機能を使用して、ローカル IDE でステートマシンを作成および編集できます。 Step Functions は、開発者が AWS サービスを使用して分散アプリケーションの構築、プロセスの自動化、マイクロサービスのオーケストレーション、データや機械学習 (ML) パイプラインの作成を支援するビジュアルワークフローサービスです。 お客様は、 AWS Lambda 、 AWS Fargate 、 Amazon Bedrock 、 HTTP API 統合 など、複数のサービスを含むワークフローを構築するために Step Functions を選択しています。開発者は、 Workflow Studio を使用して AWS コンソールから、または JSON ベースのドメイン固有言語である Amazon States Language (ASL) を使用してコードとして、これらのワークフローをステートマシンとして作成します。開発者は、アプリケーションやインフラストラクチャ (IaC) コードと共にワークフローの定義を管理します。今や、開発者は AWS コンソールと同じ体験で、VS Code でワークフローを構築およびテストするためのさらなる機能を利用できるようになりました。 ローカルワークフロー開発の簡素化 統合された Workflow Studio により、開発者は自身のローカル IDE 内で Step Functions ワークフローを円滑に構築できます。開発者は AWS コンソールで使用するのと同じキャンバスを使用して、ステートをドラッグ＆ドロップしてワークフローを構築できます。ワークフローを視覚的に修正すると、ASL 定義が自動的に更新されるため、構文ではなくビジネスロジックに集中できます。 Workflow Studio の統合により、作業環境を切り替えることなく、AWS コンソールと同じ直感的で視覚的なステートマシンの設計アプローチを提供します。 はじめに 更新された IDE の操作性を使用するには、VS Code 拡張機能として AWS Toolkit のバージョン 3.49.0 以上がインストールされていることを確認してください。 図 1: AWS Toolkit の更新 AWS Toolkit 拡張機能をインストールした後、ステートマシン定義を開いて Workflow Studio でビルドを開始できます。 ローカルワークスペースの定義ファイルを使用するか、 AWS Explorer を使用してクラウドから既存のステートマシン定義をダウンロードできます。 VS Code の統合機能は、JSON 形式と YAML 形式の ASL 定義をサポートしています。 (注: Workflow Studio が自動的にファイルを開くためには、ファイルの拡張子が .asl.json 、 .asl.yml 、または .asl.yaml である必要があります。) YAML ファイルを使用する場合、Workflow Studio は編集のために定義を JSON に変換し、保存前に YAML に再変換します。 図 2: Workflow Studio のデザインモード VS Code の Workflow Studio は、デザインモードとコードモードの両方をサポートしています。デザインモードでは、ワークフローの構築と確認のためのグラフィカルインターフェイスを提供します。 コードモードでは、統合されたコードエディタを使用して、ワークフローの Amazon States Language (ASL) 定義を表示および編集できます。 次の画面に示すように、Workflow Studio の右上にある Return to Default Editor リンクを選択することで、いつでもテキストベースの編集に戻ることができます。 図 3: Workflow Studio のコードモード VS Code で Workflow Studio を手動で開くには、ワークフロー定義ファイルの上部にある「 Open with Workflow Studio 」アクションを使用するか、エディターペインの右上にあるアイコンを使用します。 以下の画面では、両方のオプションが強調表示されています。 また、ファイルエクスプローラーペインからファイルのコンテキストメニューを使用して Workflow Studio を開くこともできます。 図 4: エディターへの Workflow Studio の統合 Workflow Studio で行った編集は、未保存の変更として元の ASL ファイルに自動的に同期されます。 変更を保存するには、Workflow Studio またはファイルエディタから変更を保存する必要があります。 同様に、ローカルファイルに加えた変更は、保存時に Workflow Studio に同期されます。 Workflow Studio は Definition Substitutions に対応しているため、 AWS CloudFormation や AWS Cloud Development Kit (CDK) などの IaC ツールと統合されたワークフローも編集できます。 Definition Substitutions は CloudFormation の機能で、IaC テンプレートで提供する値への動的な参照をワークフロー定義に追加できます。 AWSTemplateFormatVersion: "2010-09-09" Description: "State machine with Definition Substitutions" Resources: MyStateMachine: Type: AWS::StepFunctions::StateMachine Properties: StateMachineName: HelloWorld-StateMachine DefinitionS3Location: Bucket: amzn-s3-demo-bucket Key: state-machine-definition.json DefinitionSubstitutions: TableName: DemoTable その後、ステートマシンの定義で定義の代替を使用できます。 "Write message to DynamoDB": { "Type": "Task", "Resource": "arn:aws:states:::dynamodb:putItem", "Next": "Remove message from SQS queue", "Arguments": { "TableName": "${TableName}", "Item": { ... omitted for brevity ... } }, "Output": "{% $states.input %}" } このコードは、putItem オペレーションを使用して DynamoDB にメッセージを書き込む Step Functions のタスクステートを定義しています。 ${TableName} という置換構文により、ステートマシンの実行時にパラメータとして渡される動的な DynamoDB テーブル名を使用できます。 テストとデプロイ Workflow Studio の統合により、Step Functions の TestState API を使用して単一のステートをテストできます。 TestState API を使用すると、ステートマシンを作成したり、既存のステートマシンを更新したりすることなく、ローカルの IDE からクラウド上のステートをテストできます。 このにより、ステートマシン全体を呼び出すことなく、個々のステートの変更の作成とデバッグができます。 たとえば、IDE を離れることなく、入出力の処理を改善したり、Choice ステートの条件ロジックを更新したりできます。 状態のテスト Workflow Studio で任意のステートマシン定義ファイルを開きます キャンバスまたはコードタブから State （日本語: 状態）を選択します 右側のインスペクターパネルが開いていない場合は開きます 図 5 ：個別のステートの引数 上部の Test state ボタン（日本語: テスト状態）を選択します IAM ロールを選択し、入力を追加します。 TestState API を使用するために必要な権限 がロールに付与されていることを確認してください。 ステートに Definition Substitutions が含まれている場合、特定の値に置き換えることができる追加セクションが表示されます Start Test （日本語: テストを開始）を選択します 図 6: 定義の置換を含むテストステートの設定 テストが成功したら、AWS Toolkit を使用して IDE からワークフローを公開 できます。 また、 AWS Serverless Application Model 、AWS CDK、CloudFormation などのインフラストラクチャーをコードで管理するためのツールを使用してステートマシンをデプロイすることもできます。 まとめ Step Functions は、VS Code IDE と AWS Toolkit を使用したワークフローの開発を簡素化するため、強化されたローカル IDE 環境を導入しています。 これにより、コーディング、テスト、デプロイ、デバッグのサイクルが効率化され、開発者は Workflow Studio をスムーズに統合できます。 ビジュアルなワークフローデザインと充実した機能を備えた IDE のパワーを組み合わせることで、開発者はより効率的に Step Functions のワークフローを構築できるようになりました。 まず、 AWS Toolkit for Visual Studio Code をインストールし、Workflow Studio の統合に関する ユーザーガイド をご覧ください。 AWS サーバーレスに関する実践的な例、ベストプラクティス、有用なリソースは Serverless Land でご覧いただけます。 翻訳は技術統括本部 ソリューションアーキテクトの 菅原太樹 が担当し、一部を加筆修正しました。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 さて、今年のAWS Summit Japanは6月25日、26日に予定されていますが、 Webサイト がすでにオープンしています。申し込みはまだ先ですが、イベント情報のお知らせ登録もできるので是非ご活用ください。 また、直近で4月に「Tokyo NoSQL Day 2025」というイベントが開催されます。DynamoDBをはじめとする多くのNoSQLデータベースソリューションを学べる機会なのでご活用ください。 — Tokyo NoSQL Day 2025 ～デベロッパーのためのNoSQL入門と実践～ 2025年 4月 9日（水）9:30 – 18:00 場所：目黒セントラルスクエア 21F 申し込みは こちら — それでは、先週の主なアップデートについて振り返っていきましょう。 2025年3月17日週の主要なアップデート 3/17(月) Amazon RDS Custom for SQL Server supports new minor version in February 2025 Amazon RDS Custom for SQL ServerでMicrosoft SQL ServerのDeveloper、Web、Standard、Enterprise の各エディションの最新マイナーバージョンが利用可能になりました。新しいマイナーバージョンは SQL Server 2022 CU17 16.0.4175.1 で、パフォーマンスの向上とセキュリティの修正が提供されます。このマイナーバージョンは、Amazon RDS Custom for SQL Server データベースが利用可能なすべてのAWS商用リージョンで利用可能です。 Amazon Redshift Serverless now supports Current and Trailing Tracks for release updates Amazon Redshift ServerlessがCurrent TrackとTrailing Trackという２つの異なるリリースサイクルでの利用をサポートしました。Current Trackは最新の機能、セキュリティアップデート、パフォーマンス強化を含む最新の認定バージョンが提供され、Trailing Trackは以前の認定リリースを利用します。例えば開発・評価環境はCurrent Trackにより最新版を利用し、ミッションクリティカルなワークロードが動く本番環境はTrailing Trackを使い評価検証を行ってから適用することが可能になります。この機能はAmazon Redshift Serverlessが利用可能なすべての商用AWSリージョンおよびAWS GovCloud（US）リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Configure Amazon Q in Connect directly from Connect Admin Website コンタクトセンターの為のAI支援アシスタントであるAmazon Q in ConnectのAIエージェントの設定やカスタムプロンプトの作成、編集をAmazon Connect管理者ウェブサイト内から実行できるようになりました。Amazon Q in Connectは東京を含む9つのリージョンで利用可能です。具体的なリージョンに関しては こちら をご確認ください。 Salesforce Contact Center with Amazon Connect is now generally available Salesforce Contact Center with Amazon ConnectがGAしました。この統合によりSalesforceをご利用するお客様はService Cloudの機能を通じてAmazon Connectの音声、デジタルチャネル、ルーティング機能とシームレスに連携が可能です。この機能はAmazon Connectが利用可能なすべてのAWSリージョンで利用可能です。詳細については Salesforce Contact Center with Amazon Connect のドキュメント をご確認ください。 3/18(火) AWS announces the next generation of Amazon Connect where powerful AI improves every customer interaction 強力なAIによってすべての顧客接点を向上させる、次世代のAmazon Connectが発表されました。Amazon Connectではこれまでも25言語以上に対応したAI搭載のセルフサービス応答や、エージェント支援、会話分析と品質管理、キャパシティプランニングなどAmazon Q in Connectを始めAIを活用したソリューションを提供していますが、全てのチャネルに対して将来のAI機能の継続的なサポートと、”定額制AI価格”の料金体系がこのアップデートのポイントです。この次世代のAmazon Connectは東京を含む９つのリージョンでワンクリックで有効化でき、 新しい料金の選択肢(現時点では英語のみ反映) にはAI機能の無制限使用が含まれています。機能や料金体系に関してローンチブログが出ているので、 こちら をご確認ください。 AWS WAF now supports URI fragment field matching AWS WAFがこれまでサポートされていたURIパスに加えて、URIフラグメントに対するマッチングをサポートしました。URIフラグメントマッチングは「#」記号の後にあるURLの一部で、例えば、「foo://login.aspx#myFragment」のような動的フラグメントを持つログインページがある場合、「myFragment」フラグメントを持つリクエストのみを許可し、他をすべて拒否するルールを作成できます。これにより、機密領域へのアクセスのブロック、不正アクセスの試みの検出、悪意のある行為者が使用するフラグメントパターンの分析による強化されたボット検出の実装など、対象を絞ったセキュリティ制御が可能になります。この機能に追加の費用はかかりませんが、標準のWAF料金が引き続き適用されます。詳細については ドキュメント をご確認ください。 Amazon Bedrock Guardrails announces policy based enforcement for responsible AI Amazon Bedrock GuardrailsがIAMポリシーベースを強制する機能を発表しました。IAMポリシーで使用できる新しい条件キー bedrock:GuardrailIdentifier をすべてのBedrock Invoke および Converse APIに適用し、モデル推論呼び出しに特定のガードレールを適用することが可能です。Bedrock Guardrailsは、望ましくないコンテンツを検出・フィルタリングする設定可能な保護機能、特定のトピックを定義・禁止するトピックフィルター、個人識別情報（PII）を編集する機密情報フィルター、特定の単語をブロックする単語フィルター 他多様なガードレールを設定できる機能で、これを強制できることでより安全な生成AIアプリケーションを構築することが可能です。この機能はBedrock GuardrailsがサポートされているすべてのAWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon CloudWatch RUM now supports monitoring multiple domains with a single App Monitor Amazon CloudWatch RUMで単一のApp Monitorを使用して複数のトップレベルドメイン(TLD)とセカンドレベルドメイン(SLD)を監視できるようになりました。これまでは、例えばexample.comとanother.comなど各ドメインに対して個別のモニターを作成する必要がありました。今回のアップデートによりこれらを1つのApp Monitorで監視でき、複数のドメインからアクセスされるアプリケーションの可観測性の仕組みを簡素化することができます。この機能はCloudWatch RUM が利用可能なすべてのAWS商用リージョンで利用できます。詳細については ドキュメント をご確認ください。また、CloudWatch RUMの使い方を学びたい方は、 One Observability ワークショップ をご活用ください！ 3/19(水) Amazon Nova expands Tool Choice options for Converse API Converse APIの Tool Choice オプションはモデルがどのようなツールを呼び出すかを決定する方法を指定できるものです。Amazon Novaではこれまでツールを呼び出すかテキストを返すかモデルに判断を委ねる「Auto」モードしか選択できませんでした。今回、ツールを少なくとも１つ呼び出す「Any」と特定のツールを呼び出す「Tool」の２つのモードもサポートされました。詳細は ドキュメント もご確認ください。 3/20(木) AWS Network Firewall introduces new flow management feature AWS Network Firewallの新しいフロー管理機能が発表されました。アクティブなフローのpoint-in-time スナップショットを可能にする「フローキャプチャ」と特定の接続を選択し終了できる「フローフラッシュ」という２つの主要機能が追加され、送信元/送信先IPアドレス、ポート、プロトコルなどの基準に基づいてアクティブなフローを表示および管理できるようになりました。この新機能は、AWS Network Firewallがサポートされているすべてのリージョンで追加の費用なしで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Bedrock Model Evaluation LLM-as-a-judge is now generally available Amazon Bedrock Model EvaluationのLLM-as-a-judge機能がGAしました。この機能はAmazon Bedrockで利用可能な複数のLLMから審判を選択し評価を行うことで、より短い時間で、人が行うより低コストに、人間よる判断に近い評価を行うことを可能にします。GAにあたり、評価ジョブの入力プロンプトデータセットに既に取得済みの推論レスポンスを取り込むことで、Amazon Bedrock外でホストされている任意のモデルやアプリケーションでも評価できるようになりました。詳細については ドキュメント をご確認ください。 Amazon Bedrock now supports RAG Evaluation (generally available) Amazon Bedrock RAG 評価がGAしました。この機能では、情報検索のみ、または検索と回答生成の両方を評価することができます。評価は LLM-as-a-Judge テクノロジーによって実行され、開発者は評価モデルを選択することができます。検索評価では、コンテキストの関連性やカバレッジなどの指標、検索と回答生成の評価では、正確性、忠実性（ハルシネーション検出）などの品質指標や、有害性、回答拒否などの責任ある AI 指標から選択ができます。また、GAに際してAmazon Bedrock Knowledge Basesに加え、個別に構築したRAGシステムも評価が可能になりました。詳細についてはこちらの ドキュメント をご確認ください。 IonQ Forte Enterprise now available on Amazon Braket Amazon BraketにIonQの最新の36-qubit Forte Enterprise quantum processing unit (QPU)が追加されました。この新しいデバイスは物理的にスイスに設置されていますが、すべての顧客トラフィックは米国東部（バージニア北部）リージョンを経由してBraket SDKとAPIを経由してアクセス、評価が可能です。Amazon Braketの詳細は ドキュメント をご確認ください。 3/21(金) Amazon SES announces Vade advanced email security Add On for Mail Manager Amazon SES Mail Managerに送受信メッセージに対して高度なコンテンツフィルターを提供するVade Add Onの機能が追加されました。HornetSecurityの協力により開発されたこのAdd Onは行動分析、ヒューリスティック、機械学習を組み合わせてスパムやフィッシング攻撃、マルウェアなどの脅威に対する保護が可能です。この機能は東京、大阪を含む16のリージョンで利用可能です。詳細については ドキュメント をご確認ください。 最後に、以前「 週刊AWS – 2024/11/25週 」で紹介したBedrock EngineerがAWSのサンプルプログラムを紹介するGithubリポジトリの aws-samples に正式に公開されました。生成AIの活用方法のアイディアとしてぜひご活用ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 最近はコーディングする際に AI エージェントがもう手放せなくなってきています。 さて、6 月 25 日（水）、26 日（木）に開催される AWS Summit Japan 2025 の ウェブサイト がオープンしました！最新情報を受け取る登録ができるので是非ご覧ください。 それでは、3 月 17 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Amazon Q Developer CLI での超高速な新しいエージェント型のコーディング体験」を公開 Amazon Q Developer は、インタラクティブなコーディング環境を提供する新しい CLI エージェントを 3 月 6 日に発表しました。本記事では、アプリの構築と Git への commit をエージェントに実行させるデモを通じて、CLI エージェントの使い方を解説しています。開発スタイルが大きく変わるような便利機能です。ぜひお試しください！ ブログ記事「Amazon Q Developer は Java 21 へのアップグレード対応を発表」を公開 Amazon Q Developer は、2 月 14 日に Java 21 へのアップグレード対応を発表 しました。本記事では、Java アプリケーションを Java 21 に簡単にアップグレードする様子を紹介しています。アップグレード後には、変更内容の詳細なサマリーとさらなる改善に向けた推奨事項も提供されるようになっています。 ブログ記事「一般提供が開始された Amazon SageMaker Unified Studio でのより迅速なコラボレーションと構築」を公開 これまでプレビューだった Amazon SageMaker Unified Studio の一般提供が 3 月 13 日に発表されました。Amazon SageMaker Unified Studio は、データ管理やモデル開発を 1 つの環境で実現する統合プラットフォームです。Amazon Bedrock や Amazon Q Developer との統合機能といった新機能について主に紹介をしています。 ブログ記事「Amazon OpenSearch Service による検索ワークショップ(日本語版)のご紹介」を公開 Amazon OpenSearch Service の新しいハンズオンコンテンツ「 Amazon OpenSearch Service 検索ワークショップ 」が公開されました。生成 AI の文脈だと RAG (検索拡張生成) で使われることが多い Amazon OpenSearch Service ですが、ベクトル検索、スパース検索、ハイブリッド検索、リランキングなど複数の検索手法が体験できる内容となっています。 サービスアップデート サービスアップデート – 生成AIを組み込んだ構築済みアプリケーション Amazon Q Business ブラウザ拡張機能の新機能を発表 Amazon Q Business ブラウザ拡張機能に関する複数の新機能を発表しました。新機能では、企業ナレッジへのアクセスや、画像などのマルチモーダルファイルの添付がサポートされ、幅広いデータソースからの質問に対応できるようになりました。また、コンテキストウィンドウが拡大し、より大きなウェブページやファイルを受け取ることができるようになりました。 Amazon Q Business が AWS ヨーロッパ（アイルランド）リージョンで利用可能に Amazon Q Business が AWS ヨーロッパリージョン（アイルランド）で利用可能になりました。 Amazon Connect 管理者ウェブサイトから直接 Amazon Q in Connect を設定可能に カスタマーサービス向けの生成 AI 搭載アシスタントである Amazon Q in Connect を、Amazon Connect 管理者ウェブサイトから簡単に設定できるようになりました。これにより、コンタクトセンター管理者が新製品発売時に AI プロンプトを更新したりすることがより容易にできるようになりました。 サービスアップデート – アプリケーション開発のためのツール &nbsp;Amazon Bedrock Guardrailsが、責任あるAIのためのポリシーベースの強制機能を発表 Amazon Bedrock Guardrails にて、Identity and Access Management (IAM) ポリシーベースの強制機能が発表されました。IAM ポリシーの新しい条件キー bedrock:GuardrailIdentifier を設定することで Amazon Bedrock のモデル呼び出し時に Amazon Bedrock Guardrails の利用を強制することができます。これにより大規模に安全な生成 AI アプリケーションを構築しやすくなりました。現在 Bedrock Guardrails がサポートされているすべてのリージョンで利用可能です。 Amazon NovaにてConverse APIのToolChoiceオプションを拡張 Amazon Nova は、Converse API における ToolChoice パラメータのオプションを拡張しました。ToolChoice とは Tool Use (Function Calling) にて Tool の選択方法を制御するためのパラメータです。既存の「Auto」モードに加えて、いずれかのToolが呼び出される「Any」モードと、特定のツールを指定する「Tool」モードがサポートされています。システム間の連携時に出力形式を強制するのに特に役に立つアップデートとなっています。 Amazon Bedrock Model Evaluation LLM-as-a-judge 機能が一般提供開始 ユースケースに適したモデルの評価を行う Amazon Bedrock Model Evaluation にて、LLM-as-a-judge 機能が一般提供開始されました。LLM-as-a-judge 機能は、 人間の代わりに LLM がモデル評価を行うことで、モデル評価にかかるコストと時間を削減する機能です。また今回の一般提供開始に伴い「独自の推論レスポンスの持ち込み (bring your own inference responses)」に対応し、Amazon Bedrock 以外のモデルの評価もできるようになりました。 Amazon Bedrock が RAG Evaluation 機能を一般提供開始 RAG の評価を行う RAG Evaluation 機能が一般提供開始されました。RAG Evaluation 機能では、Amazon Bedrock Knowledge Bases やその他の RAG に対し正確性や忠実性（ハルシネーション検出）などの評価が可能です。また前述した LLM-as-a-judge 機能と同様に「独自の推論レスポンスの持ち込み (bring your own inference responses)」にも対応しており、Bedrock Knowledge Base の呼び出しをせずとも評価ができるようになりました。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。