はじめに アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの山本です。 先日、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&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&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 && 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 > 0 days - objects were created > 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 > 0 days - images were created > 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） 出力形式の指定（<think></think>, <answer></answer>） 異常画像検知システムの性能検証 本検証では、大規模マルチモーダル 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  を翻訳したものです。 時系列予測は、様々な業界で重要な意思決定を行う際に欠かせません。交通量の予測から売上予測まで、正確な予測によって組織は情報に基づいた決断を下し、リスクを軽減し、効率的にリソースを配分することができます。しかし、従来の機械学習アプローチでは、データに合わせた細かい調整やモデルのカスタマイズが広範囲に必要となり、開発に長い時間とリソースを要することがしばしばありました。 そこで登場したのが 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 で確認できます。   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 のソフトウェア開発エンジニアです。詳細ページでの商品レコメンデーション向けの機械学習パイプラインとレコメンデーションシステムを構築しています。仕事以外では、ゲーム開発とロッククライミングを楽しんでいます。   Maria Masood は AWS Commerce Platform でデータパイプラインとデータ可視化の構築を専門としています。自然言語処理、コンピュータビジョン、時系列分析をカバーする機械学習の専門知識を持っています。心からのサステナビリティ愛好家である Maria は、休日にガーデニングと愛犬との遊びを楽しんでいます。   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 プロンプトを更新したりすることがより容易にできるようになりました。 サービスアップデート – アプリケーション開発のためのツール  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 エージェントに注目しています。好きなうどんは’かけ’です。

2024 年 12月 13 日（金）に、メディア業界のお客様向けに AWS 勉強会を開催いたしました。放送局のお客様にご登壇いただき、 AWS の活用事例についてご紹介いただきました。登壇者の所属部署および肩書きは登壇当時のものとなります。 AWS メディア業界向け勉強会 #6 （2024 年 12 月 13 日開催） VMware ESXi サーバー環境の棚卸しと最適化：クラウド移⾏とオンプレ活⽤の戦略 株式会社毎⽇放送 経営戦略局 DX推進部 主事 ⽥中 淳史 氏 株式会社毎⽇放送 コンテンツ戦略局 ITビジネス部 主事 村⽥ 博司 氏 株式会社毎日放送では、2019年に購入した VMware ESXi の基盤サーバ上のワークロードの AWS への移行を進めています。移行の対象となるサーバは4ノード構成で、イントラネットワークの管理サーバ、ファイルサーバ、Web サーバ、会議システム、ログ管理サーバ、メールサーバなどをホスティングしていました。AWS が推奨する 7R（7つの移行戦略） を参考に、コストと効果のバランスを考慮して移行作業を進めています。 具体的な移行手法として、DNS サーバを BIND から Amazon Route 53 へと切り替えたり、Web サーバを Amazon EC2 、 Amazon RDS 、 Amazon Aurora など用いて再構築したりするなどの、オンプレミスから AWS への移行と、クラウドネイティブ化、一部ワークロードのオンプレミス間の移行、不要なサーバの廃止などを行っています。また、AWS とオンプレミスとの間に専用線の AWS Direct Connect を導入したり、 AWS Security Hub 、 AWS CloudTrail などを用いてセキュリティの強化などしたりすることも同時に行われました。コスト削減のためには、 AWS Cost Explorer  や AWS Compute Optimizer を活用しています。なお AWS への移行により、柔軟にリソースを用意できるようになったり、ログの管理や収集がしやすくなったりするなどのメリットを感じられています。今後は、 AWS Systems Manager の活用、セキュリティ管理機能の強化、運用監視の一元化などを目指しています。 資料のダウンロードは こちら ⽣成 AI 失敗してみた 東海テレビ放送株式会社 デジタルビジネス局 コンテンツ事業部 プロデューサー ⽇髙 丈尚 氏 東海テレビ放送株式会社では、生成 AI の導入に向けた取り組みを行っています。当初作成した AI チャットに対してのスタッフからの反応が芳しくなかったため、 Generative AI Use Cases JP を導入するなど、実用的なユースケースを見つけるための試行錯誤を繰り返しました。結果、一部の社員がドラマや見逃し配信の PR 制作に活用していることが分かりました。例えば、過去のシーズンの台本を読み込ませて名ゼリフをピックアップすることで、新しいシーズンのPRを作成したり、放送中に X で投稿された感想を読み込んで要約することで、見逃し配信の PR 動画に活用するなどの取り組みです。この方法により、当該動画の再生回数は大幅に増加しました。 この取り組みの中で、生成AIの基盤モデルは妥協しないことが重要であるとの知見も得られました。 Amazon Bedrock にて、Claude 3 Sonnet から Claude 3.5 Sonnet に変更したところ正確性が大幅に向上し、スタッフからの反応が大きく変わりました。今回の取り組みでは、現場のニーズを想像してツールを作るのではなく、生成 AI などの新しいツールを積極的に活用しようとする各部署のキーパーソンを見つけ、各部署の課題に沿ったユースケースを特定することが重要であるという知見も得ることができました 資料のダウンロードは こちら ねったまくんじゃんけんをサーバーレス化！機器制約に直⾯した苦悩と学びの記録 朝⽇放送グループホールディングス株式会社 DXMD 局 橋本 隼佑 氏 朝⽇放送テレビ株式会社 放送技術センター放送実施グループ 宮川 陸 氏 「ねったまくんじゃんけん」は、高校野球中継にて視聴者がリモコンの色ボタンでじゃんけんの手を選ぶと、ランキングが生成され、商品がもらえるというデータ放送のコンテンツです。しかし、毎年、新しい担当者に運用が引き継がれその度に担当者が試行錯誤を繰り返すことや、PHP を用いたレガシーな構成を長年使用していたために処理速度が遅いなどの問題がありました。また、高校野球中継が無い時間帯にもシステムが稼働し続けていたために、コストが掛かり続けるとの課題もありました。 そこで AWS Site-to-Site VPN と Amazon VPC を用いてプライベートな通信を確立するとの従来の構成は維持したまま、 AWS Lambda と Amazon DynamoDB を組み合わせたサーバレスアーキテクチャに移行しました。さらに、PHP から Python へのコードの移行も行っています。データ放送コンテンツからの通信には HTTP を用いていますが、AWS で処理できる HTTPS へと変換をするために、 Amazon API Gateway と Amazon CloudFront を使用しています。今回のシステムの再構築により費用は 83% も削減され、処理速度も10秒程度まで改善されました。今後は、 AWS CloudFormation 等を用いたサービスの一括立ち上げを検討しています。 資料のダウンロードは こちら 動画の視聴は こちら 報道素材クラウドアーカイブシステムの構築 株式会社毎⽇放送 報道情報局 報道業務部⻑ 寺下 智 氏 株式会社毎⽇放送 総合技術局 制作技術センター 部次長 伊藤 亮介 氏 株式会社毎日放送は、保管するメディアの増加による本社ライブラリーの不足、茨木市の倉庫からの取り寄せに時間がかかること、テープメディアのリスク、メディアのマイグレーションの必要性などの従来の報道ライブラリーの課題を解決すべく、AWS 上に報道素材クラウドアーカイブシステムを構築しました。このシステムでは、素材は NV センターのサーバーに一度収録され、マザー素材とオンエア素材の両方がオンプレミス上のニアラインサーバに一定期間保存されるとともに、 AWS 上の Amazon S3 Glacier Deep Archive にこれらの素材が無期限に保存されます。AWS 上でオンエア素材は XDCAM MPEG HD 422（映像レート 50Mbps）で保存され、マザー素材は XAVC（25Mbps）で保存されます。システムの構築時点では 1.5 PB の過去素材が存在し、2026年9月にはこれらの AWS への移行が全て完了する予定です。利用者は、報道支援システムを使用して素材を検索し、低解像度の映像を見ながら必要な部分を選択することが可能です。システムは選択した素材をニアラインサーバー、もしくは Amazon S3 Glacier Deep Archive から取得します。 本システムの特徴としては、日本国外の 米国東部 (バージニア北部)リージョン を利用することで、東京や大阪のリージョンと比べて約半分の利用料を実現している点です。また、データアーカイブ専用に設計されている Amazon S3 Glacier Deep Archive を利用することも、コスト圧縮に一役買っています。また、 AWS Elemental MediaConvert を用いて必要な素材のみを切り出すことで、ダウンロードコストの圧縮も実現しています。今後の予定としては、承認フローのオンライン化を検討しており、一部残っている紙ベースによる申請を廃止します。また、素材を取り出せるライブラリー端末を社内各所に配布することも検討しています。 在阪局で⼀緒に取り組めることを考えてみた 讀賣テレビ放送株式会社 技術局 制作技術担当 番組編集 藤井 一也 氏 株式会社毎⽇放送 総合技術局 制作技術センター 部次長 伊藤 亮介 氏 朝日放送テレビ株式会社 技術局 放送技術センター 放送情報グループ チーフ 兼 技術戦略部 荒木 優 氏 テレビ大阪株式会社 技術局 システム開発部 部長 野口 新一 氏 関西テレビ放送株式会社 DX推進局 DX戦略部 主任 石井 克典 氏 クラウドサービス等の普及によって、同一のシステムを複数の放送局で共用することのできる環境が整ってきたことから、在阪5局の担当者が集まり AWS の提案に乗る形で共通のシステムの検討やガイドラインの策定を試みました。例えば、放送番組や CM を正確に送出するためのマスターシステムを現在は各局が保有していますが、個別にシステムを構築していくことは運用コストやメンテナンスの負担が大きいとの課題があり、本検討会でも共用利用についての検討を行いました。また、これらのシステムをクラウドに移行するにあたっては、セキュリティに関する検討も重要となります。 そこで本プロジェクトでは、3つの試みにチャレンジしました。1つ目は共通のセキュリティガイドラインの策定です。AWS をはじめとするクラウドを共通で利用するにあたっては、各放送局が同程度の水準のセキュリティ対策を講じることが不可欠です。このため、AWS が用意したセキュリティリファレンスを基に作成したガイドラインにより、各放送局が AWS を利用する際の最低限のセキュリティ対策を統一し、コストの削減とセキュリティの強化が図れることが期待されています。2つ目のチャレンジは Amazon GuardDuty の導入です。先述のセキュリティリファレンスにも記載されている Amazon GuardDuty は、不正アクセスやマルウェアの検出が可能で、これを有効化することにより各放送局のセキュリティをより強化することが可能です。最後はシステムの共用化の検討です。システムの共用化は、同一地域の放送局同士で行う場合と系列局の枠組みで行う場合が考えられます。 本プロジェクトは今後も活動を継続予定で、クラウドを利用する際のセキュリティに関する検討と並行して、2025年はクラウドマスターに関する取り組みを本格化させる予定です。 資料のダウンロードは こちら 動画の視聴は こちら まとめ メディア業界向け勉強会の開催概要をご紹介させていただきました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきますので、どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

多くのお客様がSAP のソースデータと SAP 以外のソースデータを組み合わせて活用したいと考えています。このようなデータ分析のユースケースは、データウェアハウスやデータレイクを構築することで実現できます。お客様は AWS Glue の SAP OData コネクタを使用して、SAP からデータを抽出できます。SAP OData コネクタは、オンプレミス又はクラウド (ネイティブと SAP RISE) で稼働しているシステムの両方をサポートしています。 AWS Glue の SAP OData コネクタを使用すると、AWS Glue と Apache Spark で効率的な処理のためにデータをシームレスに分散処理できます。AWS Glue は、サーバーレスのデータ統合サービスで、分析、機械学習 (ML)、アプリケーション開発などに対し、複数のソースからデータを検索、準備、移動、結合することが簡単になります。 AWS Glue の SAP OData コネクタは、データ抽出のために SAP ODP フレームワークと OData プロトコルを使用します。このフレームワークは、プロバイダ・サブスクライバモデルで動作し、SAP システムと SAP 以外のターゲット間のデータ転送を実現しています。ODP フレームワークは、Operational Delta Queues (ODQ) メカニズムを通じて、フルデータ抽出と差分データキャプチャをサポートしています。SAP のデータ抽出のソースとして、SAP データエクストラクタ、ABAP CDS ビュー、SAP BW・BW/4 HANA ソース、SAP ABAP ソースの HANA Information ビュー、または ODP 対応の他のデータソースを使用できます。 SAP のソースシステムには履歴データが保持されており、常に更新があります。このため、ソースの変更を増分処理できるようにすることが必要です。このブログでは、SAP からデータを抽出し、SAP ODP フレームワークとデルタトークンを使用して SAP ソースからの増分データ抽出を実現する方法を説明します。 ソリューションの概要 SAP ソース システムに保存されている製品データを分析したいと考えている例になります。お客様は、現在提供している製品ラインナップ、特に各品目グループに含まれる製品の数を把握したいと考えています。それには、SAP 品目マスターと SAP システムの品目グループ データ ソースからのデータを結合する必要があります。SAP 品目マスター データは増分抽出で使用できますが、SAP 品目グループはフル ロードでのみ使用できます。これらのデータ ソースを結合し、分析のためにクエリできるようにする必要があります。 前提条件 このブログで紹介したソリューションを実装するには、まず次の前提条件のステップを実施してください。 SAP システムの SAP Gateway で、ODP データソースを使って SAP OData サービスを設定します。 SAP データを保存するための Amazon Simple Storage Service (Amazon S3) バケットを作成します。 AWS Glue Data Catalog で、 sapgluedatabase という名前のデータベースを作成します。 AWS Glue の抽出、変換、ロード (ETL) ジョブで使用する AWS Identity and Access Management (IAM) ロールを作成します。このロールには、Amazon S3 と AWS Secrets Manager を含むすべての必要なリソースへのアクセス権限を付与する必要があります。このブログのソリューションでは、このロールを GlueServiceRoleforSAP と名付けます。以下のポリシーを使用します。 AWS 管理ポリシー: AWSGlueServiceRole SecretsManagerReadWrite インラインポリシー: { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObjectAcl", "s3:GetObject", "s3:GetObjectAttributes", "s3:ListBucket", "s3:DeleteObject", "s3:PutObjectAcl"], "Resource": [ "arn:aws:s3:::<S3-BUCKET-NAME>", "arn:aws:s3:::<S3-BUCKET-NAME>/*" ] } ] } SAP 用の AWS Glue 接続先の作成 SAP コネクタは、CUSTOM ( SAP BASIC 認証) と OAUTH の両方の認証方式をサポートしています。この例では、BASIC 認証で接続します。 AWS マネジメントコンソール で AWS Secrets Manager サービスを開いて、 ODataGlueSecret という名前のシークレットを作成します。AWS Secrets Manager の詳細には、次のコードを含める必要があります。 <your SAP username> の部分にあなたの SAP システムのユーザー名を、 <your SAP username password> の部分にそのパスワードを入力します。 { "basicAuthUsername": " <your SAP username> ", "basicAuthPassword": " <your SAP username password> ", "basicAuthDisableSSO": "True", "customAuthenticationType": "CustomBasicAuth" } SAP OData データソースを選択して、AWS Glue で SAP への接続先 GlueSAPOdata を作成します。 SAP ソースの適切な値を使用して接続を構成します。 アプリケーションホスト URL : ホストには、SAP ホスト名を認証するための SSL 証明書が必要 アプリケーションサービスパス: /sap/opu/odata/iwfnd/catalogservice;v=2; ポート番号 : SAP ソースシステムのポート番号 クライアント番号 : SAP ソースシステムのクライアント番号 ログオン言語 : SAP ソースシステムのログオン言語 認証 セクションで、 認証タイプ に CUSTOM を選択します。 前の手順で作成した シークレット SAPODataSecret を選択します。 ネットワークオプション セクションで、SAP システムへ接続するための VPC 、 サブネット 、 セキュリティグループ を入力します。SAP システムへの接続の詳細については、 ETL ジョブ用の VPC を構成する を参照してください。 SAP からデータを取り込むための ETL ジョブの作成 AWS Glue コンソールで、新しいビジュアルエディターでジョブを作成します。 AWS Glue コンソールにアクセスします。 ナビゲーションペインの ETL ジョブ の下にある Visual ETL を選択します。 Visual ETL を選択して、ビジュアルエディターでジョブを作成します。 ジョブ名をデフォルトの名称から Material Master Job に編集し、 保存 を選択します。 ビジュアルエディターキャンバス上で、SAP ソースを選択します。 Visual タブを選択し、プラス記号をクリックして Add nodes メニューを開きます。SAP を検索し、SAP OData Source を追加します。 追加したノードの名前を Material Master Attributes に設定します。 SAP OData connection では、 GlueSAPOData 接続先を選択します。 SAP ソースから製品マスタ、サービス、エンティティセットを選択します。 Entity Name と Sub Entity Name では、SAP ソースの SAP OData エンティティを選択します。 Fields から、 Material、Created on、Material Group、Material Type、Old Matl number、GLUE_FETCH_SQ、DELTA_TOKEN、DML_STATUS を選択します。 フィルターに limit 100 と入力し、プレビューの表示にかかる時間を制限します。 この OData サービスは差分抽出をサポートしているため、 増分転送 オプションがデフォルトで選択されています。 AWS Glue サービスロールの詳細を選択した後、データプレビューが使用可能になります。プレビューで表示されるように、次の 3 つの新しいフィールドを含めることができます。各フィールドの意味は下記の通りです。 glue_fetch_sq : これはシーケンスフィールドで、レコードが受信された順序の EPOC タイムスタンプから生成され、各レコードで持つユニークの値です。ソースシステムの変更順序を確認する必要がある場合に使用できます。 delta_token : 最後に抽出されたレコードのみに値が含まれ、それ以外のすべてのレコードには空白になります。これは変更されたレコード (CDC) をキャプチャするための ODQ トークン値です。このレコードはソースからのトランザクションデータレコードではなく、デルタトークン値を渡す目的だけで存在します。 dml_status : これは、ソースから新規挿入および更新されたレコードに対して UPDATED、ソースから削除されたレコードに対して DELETED と表示されます。 デルタ対応の抽出では、最後に抽出されたレコードに DELTA_TOKEN の値が含まれ、上記のように delta_token フィールドが埋められます。 ビジュアルキャンバスに別の SAP ODATA ソース接続を追加し、このノードを Material Group Text と名付けてください。 SAP ソースから製品グループの OData サービスとエンティティセットを選択します Entity Name と Sub Entity Name については、SAP ソースの SAP OData エンティティを選択します この サービスはフル抽出のみをサポートしているため、 完全転送オプション がデフォルトで選択されています。また、このデータセットをプレビュー表示することもできます。 データをプレビューで表示するときは、 language key に注目してください。フィルタがなければ SAP はすべての言語を渡すようになるため、 SPRAS = 'E' というフィルターを追加して、英語のみを抽出します。ここのフィルタ―の値はフィールドの SAP 内部書式の値を使います。 Material Group Text の後に、キャンバスに Change Schema 変換ノードを追加します。 target key で、製品グループフィールドの名前を matkl2 に変更します。これにより、最初のソースとは異なる名前になります。 Drop チェックボックスで、 spras 、 odq_changemode 、 odq_entitycntr 、 dml_status、delta_token 、 glue_fetch_sq を選択します。 キャンバスに Join 変換ノードを追加し、両方のソースデータセットを結合します。 Node parents で Material Master Attributes と Change Schema 両方が選択します。 Join type として Left join を選択します。 各ソースのキーフィールドを Join conditions として設定します。 Material Master Attributes では matkl を選択します Change Schema では matkl2 を選択します 出力をプレビューして、正しくデータが読み込まれていることを確認できます。これで結果を保存する準備ができました。 キャンバスにターゲットの S3 バケットを追加します。 ノードの親が Join に指定します。 フォーマット では、 Parquet を選択します。 S3 ターゲットロケーション では、前提条件の章で作成した S3 バケットを参照し、 materialmaster/ を S3 ターゲットロケーション に追加します。 データカタログ更新オプション では、 Create a table in the Data Catalog and on subsequent runs, update the schema and add new partitions を選択します。 データベース では、前に作成した AWS Glue データベース sapgluedatabase の名前を選択します。 テーブル名 には materialmaster と入力します。 保存ボタン をクリックしてジョブを保存します。ジョブは次の図のようになります。 ETL ジョブのクローンして差分対応実施 ETL ジョブを作成したら、デルタトークンを使用してインクリメンタルデータ処理を含めるためのクローンの準備が整います。 これを行うには、ジョブスクリプトを直接修正する必要があります。スクリプトを修正して、最後のデルタトークン (ジョブタグに格納される) を取得するステートメントを追加し、デルタトークン値をリクエスト (またはジョブの実行) に追加します。これにより、次回のジョブ実行時にデータを取得する際に、デルタ対応の SAP OData サービスが有効になります。 最初のジョブの実行では、タグにデルタトークン値がないため、呼び出しは初回実行となり、その後デルタトークンがタグに格納されて、将来の実行に使用されます。 AWS Glue コンソールに移動します。 ナビゲーションペインの ETL Jobs の下にある Visual ETL を選択します。 Material Master Job を選択し、 Actions を選んで Clone job を選択します。 ジョブの名前を Material Master Job Delta に変更し、 Script タブを選択します。 各ジョブ実行時のデルタトークンの保存と取得を行うための追加の Python ライブラリを追加する必要があります。これを行うには、 Job Details タブに移動し、下にスクロールして Advanced Properties セクションを展開します。 Python library path に次のパスを追加します。 s3://aws-blogs-artifacts-public/artifacts/BDB-4789/sap_odata_state_management.zip 次に Script タブを選択し、右上の Edit script を選択します。Confirm を選択して、ジョブがスクリプトのみであることを確認します。 デルタトークンを有効にするには、スクリプトに次の変更を加えてください。 ステップ 5 で追加した SAP OData ステート管理ライブラリクラスをインポートするため、次のコードを 8 行目に追加します。 from sap_odata_state_management.state_manager import StateManagerFactory, StateManagerType, StateType 次の数ステップでは、デルタトークンをジョブタグに取得して永続化し、後続のジョブ実行からアクセスできるようにします。デルタトークンは SAP ソースへの要求に追加され、増分変更が抽出されます。 トークンが渡されない場合、ロードは初回ロードとして実行され、トークンが次回の実行用に永続化されます。その次の実行はデルタロードになります。 sap_odata_state_management ライブラリを初期化するため、接続オプションを変数で定義して、ステートマネージャーでその変数の値を定義します。これを行うには、 job.init ステートメントの後 16 行目に次のコードを追加します。 <key of MaterialMasterAttributes node>  と  <entityName for Material Attribute> は、既存の生成されたスクリプトの # Script generated for node Material Master Attributes コードに値が入っているのでそこからコピーできます。適切な値に置き換えてください。 key = "<key of MaterialMasterAttributes node>" state_manager = StateManagerFactory.create_manager( manager_type=StateManagerType.JOB_TAG, state_type=StateType.DELTA_TOKEN, options={"job_name": args['JOB_NAME'], "logger": glueContext.get_logger()} ) options = { "connectionName": "GlueSAPOData", "entityName": "<entityName for Material Attribute>", "ENABLE_CDC": "true" } connector_options = state_manager.get_connector_options(key) options.update(connector_options) Material Master Attributes ノードに生成された既存のスクリプトの前に # を付け加えてコメントアウトし、次の置換スニペットを追加します。 <key of MaterialMasterAttributes node> = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="<key of MaterialMasterAttributes node>") ダイナミックフレームからデルタトークンを読み取って、ジョブのタグに保存するには、スクリプトの最後の行 job.commit() の前に次のコードスニペットを追加します。 state_manager.update_state(key, <key of MaterialMasterAttributes node>.toDF()) 最終的にスクリプトは次のようにになるイメージです。 import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.job import Job from awsglue.dynamicframe import DynamicFrame from sap_odata_state_management.state_manager import StateManagerFactory, StateManagerType, StateType args = getResolvedOptions(sys.argv, ['JOB_NAME']) sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) key = "MaterialMasterAttributes_node1730873953236" state_manager = StateManagerFactory.create_manager( manager_type=StateManagerType.JOB_TAG, state_type=StateType.DELTA_TOKEN, options={"job_name": args['JOB_NAME'], "logger": glueContext.get_logger()} ) options = { "connectionName": "GlueSAPOData", "entityName": "/sap/opu/odata/sap/ZMATERIAL_ATTR_SRV/EntityOf0MATERIAL_ATTR", "ENABLE_CDC": "true" } # Script generated for node Material Group Text MaterialGroupText_node1730874412841 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options={"ENABLE_CDC": "false", "connectionName": "GlueSAPOData", "FILTER_PREDICATE": "SPRAS = 'E'", "ENTITY_NAME": "/sap/opu/odata/sap/ZMATL_GROUP_SRV/EntityOf0MATL_GROUP_TEXT"}, transformation_ctx="MaterialGroupText_node1730874412841") # Script generated for node Material Master Attributes #MaterialMasterAttributes_node1730873953236 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options={"ENABLE_CDC": "true", "connectionName": "GlueSAPOdata", "FILTER_PREDICATE": "limit 100", "SELECTED_FIELDS": "MATNR,MTART,MATKL,BISMT,ERSDA,DML_STATUS,DELTA_TOKEN,GLUE_FETCH_SQ", "ENTITY_NAME": "/sap/opu/odata/sap/ZMATERIAL_ATTR_SRV/EntityOf0MATERIAL_ATTR"}, transformation_ctx="MaterialMasterAttributes_node1732755261264") MaterialMasterAttributes_node1730873953236 = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="MaterialMasterAttributes_node1730873953236") # Script generated for node Change Schema ChangeSchema_node1730875214894 = ApplyMapping.apply(frame=MaterialGroupText_node1730874412841, mappings=[("matkl", "string", "matkl2", "string"), ("txtsh", "string", "txtsh", "string")], transformation_ctx="ChangeSchema_node1730875214894") # Script generated for node Join MaterialMasterAttributes_node1730873953236DF = MaterialMasterAttributes_node1730873953236.toDF() ChangeSchema_node1730875214894DF = ChangeSchema_node1730875214894.toDF() Join_node1730874996674 = DynamicFrame.fromDF(MaterialMasterAttributes_node1730873953236DF.join(ChangeSchema_node1730875214894DF, (MaterialMasterAttributes_node1730873953236DF['matkl'] == ChangeSchema_node1730875214894DF['matkl2']), "left"), glueContext, "Join_node1730874996674") # Script generated for node Amazon S3 AmazonS3_node1730875848117 = glueContext.write_dynamic_frame.from_options(frame=Join_node1730874996674, connection_type="s3", format="json", connection_options={"path": "s3://sapglueodatabucket", "compression": "snappy", "partitionKeys": []}, transformation_ctx="AmazonS3_node1730875848117") state_manager.update_state(key, MaterialMasterAttributes_node1730873953236.toDF()) job.commit() 変更を保存するには、 保存 ボタンを選択します。 実行 をクリックしてジョブを実行します。この時点は、ジョブの詳細タブにはタグがありません。 ジョブの実行が正常に完了するまで待ちます。ステータスは 実行 タブで確認できます。 ジョブの実行が完了すると、 ジョブの詳細の タブでタグが追加されたことがわかります。次のジョブの実行では、このトークンを読み取り、デルタロードが実行されます。 SAP からのデータに対するクエリ AWS Glue ジョブの実行により、Data Catalog にエントリが作成されたので、すぐにデータをクエリすることができます。 Amazon Athena コンソールを開きます。 Launch Query Editor を選択します。 適切なワークグループが割り当てられていることを確認するか、必要に応じて ワークグループを作成 します。 sapgluedatabase を選択し、次のようなクエリを実行してデータの分析を開始します。 select matkl, txtsh, count(*) from materialmaster group by 1, 2 order by 1, 2 ; クリーンアップ 追加料金が発生しないよう、このブログで使用した AWS リソースを削除します。削除するリソースは、AWS Glue ジョブ、SAP OData 接続先、Glue データカタログエントリ、Secrets Manager のシークレット、IAM ロール、S3 バケットに保存しているファイル、S3 バケットです。 結論 このブログでは、サーバーレスで複数の SAP データソースからのデータ抽出と差分抽出プロセスを作成する方法を説明しました。この方法では、AWS Glue を使用して SAP ODP デルタトークンを利用し、SAP ソースからデータを差分で抽出し、Amazon S3 にデータをロードしました。 AWS Glue はサーバーレスのサービスなので、インフラストラクチャの管理は不要で、ジョブの実行中に使用されたリソースに料金が発生します (データ保存先のストレージコストも発生します)。組織がますますデータドリブンになるにつれ、この SAP コネクタは、SAP ソースデータをビッグデータの分析やコストに効果的で高性能、且つセキュアに取り込むことができます。詳細は AWS Glue をご覧ください。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。 著者について Allison Quinn はメルボルン (オーストラリア) に拠点を置く Sr. ANZ Analytics Specialist Solutions Architect で、同地域の金融サービス顧客と密接に協力しています。Allison は SAP 製品で 15 年以上の経験があり、現在は AWS ネイティブサービスに分析技術の専門性を集中させています。データに関するすべてのことに情熱を持ち、あらゆる種類の顧客がビジネス上の利益を得られるようデータの民主化を目指しています。 Pavol は、AWS のイノベーションソリューションアーキテクトで、EMEA 地域における SAP クラウド導入を専門としています。20 年以上の経験を持ち、グローバル顧客の AWS への SAP システムの移行と最適化を支援しています。Pavol は、AWS のアジリティ、レジリエンシー、パフォーマンスを活用して、SAP 環境をクラウドに移行するための戦略を立案しています。顧客に対して、AWS の AI/ML、データ分析、アプリケーションサービスを利用して SAP ランドスケープを近代化し、インテリジェンス、自動化、パフォーマンスを向上させるのを支援しています。 Partha Pratim Sanyal は、カナダのバンクーバーにある AWS Glue のソフトウェア開発エンジニアで、データ統合、分析、接続に特化しています。豊富なバックエンド開発の専門知識を持ち、顧客中心のインパクトのある優れたソリューションを作ることに尽力しています。ユーザーがデータを簡単に分析・理解できるような機能を構築することに重点を置いています。Partha は、複雑なユーザーニーズに対処し、データのアクセシビリティと洞察力を高めるための直感的で価値のある体験を創出することに熱心です。 Diego は、SAP テクノロジーに 20 年以上の経験を持つエンタープライズソリューションアーキテクトで、SAP のイノベーション、データ分析に特化しています。パートナーとしても顧客としても働いた経験があり、システムと組織を販売、実装、運用するために必要なことを完全に理解しています。テクノロジーとイノベーションに情熱を持ち、顧客の成果とビジネス価値の提供に重点を置いています。 Luis Alberto Herrera Gomez は、バンクーバーの AWS Glue でソフトウェア開発エンジニアを務めています。バックエンドエンジニアリング、マイクロサービス、クラウドコンピューティングに特化しています。Amazon と AWS に入社する前に複数のスタートアップでバックエンドおよびフルスタック開発者を経験し、7 〜 8 年の経験があります。Luis は、スケーラブルで効率的なクラウドベースのアプリケーションの開発に注力しています。AWS テクノロジーに関する専門知識を活かし、複雑なデータ処理タスクを処理できる高性能システムを設計しています。Luis は、クラウドコンピューティングを活用して、難しいビジネス課題を解決することに情熱を持っています。

この記事は Build a Unified Patient Index Using AWS Entity Resolution (記事公開日: 2025 年 2 月 14 日) を翻訳したものです。 医療機関や公衆衛生機関は、膨大な量の患者データを扱っています。複数の、場合によっては接続されていないデータソースにわたって機密性の高い患者情報を正確に管理し、リンクすることは、医療の連携、研究、そして公衆衛生活動にとって極めて重要です。正確な統合患者インデックスを構築することで、医療提供者は包括的な患者履歴にアクセスでき、研究者は堅牢なデータセットを構築でき、公衆衛生当局は疾病の傾向や結果について洞察を得ることができます。 しかし、データ入力の不整合は、正確な患者識別に重大な課題をもたらす可能性があります。これらの問題は、名前の綴りやフォーマットの違いだけでなく、ニックネームや敬称の使用、複数の接点における連絡先情報の不一致、住所の項目や略語の標準化の不一致にまで及びます。様々なデータ入力の不整合は、患者レコードの断片化につながり、潜在的に医療の質や患者の安全性を損なう可能性があります。これらの課題は以下のような結果をもたらす可能性があります： 不完全な患者レコード 患者ケアにおける、データに基づかない意思決定 公衆衛生の課題への対応の困難さ 効果的な研究の障壁 非効率な医療連携 医療費の増加 患者満足度の低下 マスター患者インデックス (MPI) の構築は、これらの課題の解決にも役立ちます。なぜなら、MPI は個人に関連するレコードに割り当てられた個人ベースの永続的な識別子を持つ、一元化されたレジストリとして機能するためです。インデックス化された患者レコードに部分的なレコードをマッチングすることで、統合され、継続的に進化する患者のビューを作成することができ、これによってダウンストリームの消費者アプリケーション間での効果的な医療連携と研究が可能になります。 HIPAA に適格な AWS サービスを使用することで、医療機関は AWS Entity Resolution で患者レコードを処理し、 Amazon Connect Customer Profiles でメンバー情報を統合し、 Amazon Q in Connect の機能を活用して、パーソナライズされたタイムリーな患者ケアを提供することができます。 AWS Entity Resolution を使用することで、企業や組織は、複数のアプリケーション、チャネル、データストアに存在する関連する顧客または医療記録を照合、リンク、および強化することができます。このサービスは、ルールベース、機械学習 (ML) 駆動、およびデータサービスプロバイダーによる柔軟で設定可能なマッチング技術を提供し、データの正確性を向上させ、顧客のビジネスニーズに基づいて関連レコードを強化するのに役立ちます。AWS Entity Resolution を使用すると、顧客はエンティティマッチング技術を設定でき、手動データ入力や低品質データに関連する課題を組織が克服するのに役立ちます。このサービスは、データの移動を最小限に抑えることで、医療データアーキテクチャのセキュリティ体制を改善します。Amazon Simple Storage Service (Amazon S3) や AWS Glue など、広く普及している AWS サービスを活用することで、既存の医療データアーキテクチャパターンとシームレスに統合されます。 AWS Entity Resolution を使用して患者レコードを処理した後、ヘルスケア企業は Amazon Connect の機能を活用して、プロアクティブなサービスを提供し、患者ケアのニーズを予測することができます。 Amazon Connect Customer Profiles を使用することで、医療機関は必要な患者の同意を得た上で、複数のソースからメンバーや患者の情報を統合することができます。 Amazon Q in Connect を Amazon Connect Customer Profiles と統合することで、ヘルスケア企業はリアルタイムで患者のニーズを検出し、タイムリーでパーソナライズされた患者ケアを提供することができます。 このブログでは、独立系ソフトウェアベンダー (ISV) 、医療提供者、および保険支払機関が、一般に公開されている人工的に生成されたデータセットを使用して、AWS Entity Resolution を活用して関連する患者レコードを特定、およびマッチングする方法をデモンストレーションします。 図 1 – ハイレベルアーキテクチャ図 患者データセット このソリューション例では、 小児肥満データイニシアチブ (CODI) プロジェクト用に作成された合成データセットを使用しています。合成患者の医療履歴をモデル化するオープンソースの合成患者生成ツールである Synthea を使用して、一部の個人について複数の分割レコードを生成しました。これらの分割レコードでは、実際のシステムで想定されるように、人口統計情報が様々な形で変化する可能性があります。例えば、あるレコードでは名前が「John」であり、別のレコードでは「Johnny」というように表記が異なる場合があります。 患者データセットの構造 この例で使用している患者データは、分析のために FHIR フォーマットから CSV に変換されています。このデータセットには約 6,300 件のレコードが含まれており、データセット全体で患者のマッチングに必要な個人識別情報 (PII) を含む列があります。 以下の表は、患者データの構造を説明しています。データには、州名 (statename) 、郵便番号 (postalcode) 、住所 (address) 、国名 (countryname) 、市区町村名 (cityname) 、生年月日 (birthdate) 、固有 ID (uniqueid) 、名 (firstname) 、ミドルネーム (middlename) 、姓 (surname) 、リソースタイプ (resourcetype) 、電話番号 (phonenumber) などのフィールドが含まれています。これらのフィールドは、同一人物を参照するレコードをリンクするエンティティ解決プロセスで一般的に使用されます。データに含まれるフィールドの規模と多様性は、潜在的なエンティティマッチング技術を実証するのに適しています。 図 2 – 合成データセットのサンプルデータ AWS Entity Resolution ワークフローを実行するために、与えられた患者データを Amazon S3 バケットにアップロードしました。その後、AWS Glue クローラーがファイルを処理して、自動的にスキーマを判断し、AWS Glue Data Catalog のテーブルとしてメタデータを更新します。次に、AWS Entity Resolution コンソール画面に移動します。 AWS Entity Resolution コンソール で、メニューから「スキーママッピング」オプションを選択し、「スキーママッピングの作成」をクリックします。スキーママッピングは、解決に使用される元データとそれに含まれる属性について、サービスに情報を提供します。 図 3 – AWS Entity Resolution のスキーママッピング作成画面 「スキーママッピングの作成」画面で、ソースデータを表す AWS Glue データベースとテーブルを選択します。この記事では、患者データを含む「patientdata」テーブルを持つ、「demodb」という名前のデータベースを使用しました。このデータベースは、患者データを格納した Amazon S3 バケットで AWS Glue クローラーを実行した際に作成されました。 図 4 – AWS Entity Resolution のスキーママッピング設定画面 次に、ドロップダウンからユニーク ID (Unique ID) を選択します。ユニーク ID カラムは、データの各行を一意に参照するものでなければなりません – これはデータベースの主キーカラムのようなものと考えてください。この場合、CSV ファイルの「uniqueid」がそれに該当します。 図 5 – AWS Entity Resolution スキーママッピングの作成、ユニークID選択 次に、下にスクロールして解決 (マッチング、リンク) に必要な入力フィールドを選択します (図 6 参照) 。この場合、firstname (名) 、middlename (ミドルネーム) 、surname (姓) 、statename (州名) 、countryname (国名) 、homeaddress (自宅住所) など、患者の人口統計情報を示す列が選択されています。 図 6 – AWS Entity Resolution スキーママッピング、マッチング列の選択 さらに、解決には必要ないものの、最終的な出力ファイルに必要な列は、パススルーフィールドセクションで選択できます。この例では、birthdate (生年月日) 、cityname (市区町村名) 、contactemailaddress (連絡先メールアドレス) 、contactfamilyname (連絡先姓) 、contactname (連絡先名) 、gender (性別) 、linkid (リンク ID) 、maritalstatus (婚姻状態) 、phonenumber (電話番号) 、postalcode (郵便番号) 、resourceid (リソース ID) を選択しました。これらの列はマッチングプロセスには参加しませんが、出力の一部として表示されます。 図 7 – AWS Entity Resolution スキーママッピング、パススルー列の選択 スキーママッピング作成の次のステップでは、選択した入力フィールドを適切なデータタイプとマッチキーにマッピングします。入力タイプ (名前、メール、住所など) を指定することで、AWS Entity Resolution は各列のデータをどのように解釈するか、そして必要に応じて特定の列にどの正規化ルールを適用できるかを理解します。 マッチキー は、どのフィールドが類似しており、マッチングプロセス中に単一のユニットとして考慮する必要があるかを決定します。 注 ：個人識別情報 (PII) ではないフィールドを解決に使用する必要がある場合、それらのフィールドを「入力フィールド」として選択することができます。入力タイプとして「Custom String」を選択し、適切なマッチキー名を設定してください。Custom String のサポートは、ルールベースのマッチング技術でのみ利用可能で、機械学習ベースのマッチングでは無視されます。 図 8 – AWS Entity Resolution スキーママッピング、入力フィールドを入力タイプへマッピング 「次へ」をクリックしてグループを作成します。グループとは、First Name (名) 、Middle Name (ミドルネーム) 、Last Name (姓) のような関連する入力フィールドを単一の「Name (氏名) 」列にまとめたセットです。これにより、AWS Entity Resolution は、マッチングと類似性の計算の際に、個々のフィールドを個別に比較するのではなく、まとめて比較することができ、より正確なマッチングが可能になります。 図 9 – AWS Entity Resolution スキーママッピング、名前のグループ定義 名前フィールドのグループ化と同様に、「住所」フィールドのグループも作成し、入力フィールドとして statename (州名) 、countryname (国名) 、homeaddress (自宅住所) を選択します (図 10 参照) 。 図 10 – AWS Entity Resolution スキーママッピング、住所のグループ定義 グループ設定が完了したら、「次へ」をクリックして、確認と作成画面に進みます。すべての設定を確認し、「スキーママッピングの作成」をクリックします。これによりスキーママッピングが作成されます。 スキーママッピングが作成されたら、次のステップはマッチングワークフローの作成です。マッチングワークフローは、ソース間でレコードをマッチングおよびリンクするために必要な、関連するマッチング技術、ルール、または機械学習の入力を定義するのに役立ちます。マッチングワークフローを作成するには、左側のメニューのワークフローのドロップダウンから「マッチング」を選択し、「マッチングワークフローの作成」ボタンをクリックします (図 11 参照) 。 図 11 – AWS Entity Resolution マッチングワークフローの作成 マッチングワークフロー画面で、名前と説明を入力してワークフローの作成を開始します。この例では、「patient-data-matching-workflow」という名前を付けました。 図 12 – AWS Entity Resolution マッチングワークフロー作成：名前と説明の定義 次に、適切な AWS Glue データベース、AWS Glue テーブル、および先ほど作成した対応するスキーママッピングを選択します。このステップにより、AWS Entity Resolution サービスにソースデータの場所を知らせ、スキーママッピング定義を使用してデータを解析し理解する方法を指示します。 図 13 – AWS Entity Resolution マッチングワークフロー作成：入力ソースの定義 AWS Entity Resolution に必要なアクセス権限を提供します。このサービスを初めて実行する場合は、「新しいサービスロールの作成と使用」を選択します。このオプションにより、サービスは自動的に IAM ロールを作成し、入出力用に指定された Amazon S3 バケットと、生データの入力ソースである AWS Glue データベース / テーブルへのアクセス権限を付与します。サービスロール名は自動生成されますが、必要に応じて編集することができます。IAM ロールの作成に関する詳細は、 ユーザーガイド で確認できます。 図 14 – AWS Entity Resolution マッチングワークフロー作成：IAMロールの選択 最適な IAM ロールオプションを選択した後、「次へ」をクリックして次のページに進みます。このページでは、ソースデータの解決を実行するために、ルールベースと機械学習ベースのマッチングの間から適切なマッチング技術を選択します。この場合、同一患者に属するレコードを確定的に識別するために、ルールベースのマッチング技術を選択します。 図 15 – AWS Entity Resolution マッチングワークフロー作成：ルールベースマッチング技術の選択 マッチングルール では、 ルール名 を入力し、そのルールの マッチキー を選択します。最大 15 個のルールを作成でき、ルール全体で最大 15 個の異なるマッチキーを適用してマッチング基準を定義できます。 比較タイプ については、「 複数入力フィールド 」オプションを選択します。これにより、データが同じ入力フィールドにあるか異なる入力フィールドにあるかに関係なく、複数の入力フィールドに保存されているデータをマッチングすることができます。 「次へ」をクリックして次のページに進みます。このページでは、サービスが結果を書き込む出力用 Amazon S3 バケットの場所を設定します。出力データ形式として「正規化データ」を選択します。このオプションでは、ダウンストリームでの迅速な利用のために、特殊文字や余分なスペースを削除し、すべての値を小文字に整形することでレコードを正規化します。必要に応じて、「 AWS Entity Resolution 向け正規化ライブラリのカスタマイズガイダンス 」に従って、正規化ライブラリをカスタマイズすることができます。 図 16 – AWS Entity Resolution マッチングワークフロー作成：出力設定 ワークフローを作成する前の最終ステップとして、すべての設定内容を確認し、マッチング要件を正確に反映していることを確認してから、「作成して実行」をクリックします。これによりマッチングワークフローが作成され、最初のジョブが実行されます。 ジョブの完了を待つと (図 17 参照) 、ジョブメトリクスに入力レコード数と生成された一意のマッチング ID 数が表示されます。出力は設定された Amazon S3 バケットに書き込まれます。指定された出力用 Amazon S3 バケットへ移動し、出力ファイルをダウンロードして結果を分析することができます。 図 17 – AWS Entity Resolution マッチングワークフロー実行統計 出力データ (図 18 参照) では、各レコードに元の一意の ID (uniqueid カラム) と新しく割り当てられた matchid が含まれています。同じ患者に関連するマッチングレコードには、同じ matchid が付与されています。matchrule フィールドは、マッチしたレコードセットを生成した際に適用されたルールを説明しています。 図 18 – AWS Entity Resolution マッチング済みデータ出力 このマッチング済みデータは、医療機関や公衆衛生機関にとって貴重な資産となり得ます。予防接種情報システム (IIS) 、疾病監視プラットフォーム、人口動態記録システムなどの医療システムに、AWS Entity Resolution の出力から特定されたマッチを取り込むことができます。これらのシステムは、マッチング済みデータを活用して潜在的なマッチを特定し、ユーザーに提示することができます。これにより、医療スタッフは潜在的なマッチを確認、統合、解決することができ、患者データの正確性と完全性を向上させることができます。 マッチング済みデータを活用することで、組織はより良い介入を促進し、健康状態の改善につながる分析を強化することができます。例えば、異なるデータセット間でデータをリンクすることで、予防接種データ、病院の退院データ、疾病監視データを連携させ、重症 COVID-19 のリスク要因をより良く特定することができます。 まとめ AWS Entity Resolution は、断片化されたレコード、データに基づかない意思決定、研究の障壁、不正確なデータによるケア連携の不一致、コスト増加といった課題の解決に役立ちます。この例で示されたように、医療機関や研究者は、AWS Entity Resolution を使用して、複数の多様なデータソースから患者レコードを効果的にリンクおよびマッチングすることができます。これにより、個人の健康履歴と結果について包括的で長期的なビューを作成することが可能になり、結果としてより良い全体的なケアにつながる可能性があります。 貴社のビジネスの加速にどのように貢献できるか、 AWS の担当者 にお問い合わせください。 参考文献 AWS Entity Resolution Resources ヘルスデータのための AWS Entity Resolution AWS Entity Resolution: 複数のアプリケーションとデータストアからの関連レコードを照合してリンクする AWS Entity Resolution Workshops 著者について Venkata Kampana Venkata は、カリフォルニアを拠点とする Amazon Web Services (AWS) 健康・福祉サービスチームのシニアソリューションアーキテクトです。彼は AWS 上の優れたアーキテクチャのソリューションを通じて、公共部門の顧客がミッション目標を達成できるよう支援しています。 Jim Daniel Jim は、Amazon Web Services (AWS) の公衆衛生部門のリーダーです。それ以前は、米国保健福祉省 (HHS) で約 10 年間、公衆衛生イノベーション部長や公衆衛生コーディネーターなどの職務を歴任しました。政府での勤務以前は、マサチューセッツ州公衆衛生局の最高情報責任者 (CIO) を務めていました。 Punit Shah Punit は、Amazon Web Services のシニアソリューションアーキテクトで、顧客のクラウド上でのデータ分析戦略の構築支援に注力しています。現在の役割では、AWS Entity Resolution や Amazon Connect などの AWS サービスを使用して、強固なデータ基盤層の構築を顧客に助言しています。大規模なデータレイクの構築において 15 年以上の業界経験を持っています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

このブログは 2025 年 1 月 25 日に Matt Williams と Felix Guglielmi によって執筆された内容を日本語化したものです。原文は こちら を参照して下さい。 AWS では、可能な限り環境に配慮した方法で事業を運営することに尽力しています。また、お客様がクラウドの利点を活用して、IT インフラストラクチャをより効果的に監視し最適化できるよう支援しています。「 Amazon Web Services への移行による炭素削減の機会 」で報告されているように、AWS のインフラストラクチャは、米国の一般的な企業データセンターの中央値と比較して 3.6 倍のエネルギー効率を誇ります。さらに、AWS に移行することで、同じタスクに対するワークロードの炭素排出量を 88% 削減することができます。 持続可能性は、AWS とお客様の間で共有される責任です。AWS は、クラウドの持続可能性を最適化する責任を負っています。これには、効率的な共有インフラストラクチャの提供、水資源の管理、再生可能エネルギーの調達が含まれます。一方、お客様は、クラウド内の持続可能性に責任を負います。これには、ワークロードとリソース利用の最適化、およびワークロードに必要な総リソースの最小化が含まれます。 お客様の持続可能性目標の達成を支援するため、AWS は様々なツールを提供しています。その中には、AWS 使用量から生成される炭素排出量を追跡・測定する AWS Customer Carbon Footprint Tool が含まれます。AWS は、 AWS Well-Architected Framework の持続可能性の柱 を作成し、ワークロードの持続可能性目標達成に使用できる設計原則、運用ガイダンス、ベストプラクティスを提供しています。また、AWS は、アーキテクチャにおける持続可能性の改善を可能にするサービスの提供を続けています。例えば、Amazon EC2 でのエネルギー使用のワットあたり最高のパフォーマンスを提供するように設計された AWS Graviton インスタンス などがあります。 Amazon EC2 スポットインスタンス を使用すると、大幅なコスト削減の恩恵を受けながら、AWS のデータセンター利用率の向上にも貢献できます。 このブログでは、お客様が AWS Config を使用して、AWS Well-Architected Framework の 持続可能性の柱 のベストプラクティスに照らした AWS リソースの大規模に評価、監査、評価する方法について説明します。 AWS Config AWS Config はマネージドルールとカスタムルールを作成する機能を提供し、両方ともクラウドリソースの構成をプロビジョニングの前後で評価することができます。さらに、Config コンフォーマンスパック を使用すると、お客様は Config ルールとその修復アクションのコレクションを単一のユニットにパッケージ化することができます。コンフォーマンスパックは AWS Organizations とも統合されています。これにより、お客様は組織全体にわたってコンフォーマンスパックをデプロイでき、AWS アカウントやワークロード全体でリソースのコンプライアンスを確保するためのスケーラブルで効率的な方法を提供します。 持続可能性のベストプラクティスの評価 AWS Well-Architected Framework の持続可能性の柱は、クラウドにおける持続可能性の ベストプラクティス に関するガイダンスを提供します。これらのベストプラクティスは、リソースの使用率を高め、必要なリソースの総数を減らすことにより、お客様のワークロードを最適化するのに役立ちます。 持続可能性の柱を利用することで、お客様は改善の目標を特定し、推奨されるベストプラクティスを実行して持続可能性の目標を達成できます。 この例では、持続可能性の柱のベストプラクティスをいくつか選択し、AWS Config ルールを使用してお客様がこれらのベストプラクティスを組織全体に確実に実装できるようにする方法を示します。私たちは、データライフサイクル管理、コードの最適化、ネットワークパフォーマンスといった多くのアーキテクチャに共通するベストプラクティスを意図的に選択しました。このアプローチは、リソースの消費量を削減し、節約効果を得る機会を提供するのに役立ちます。ベストプラクティスの例は次の通りです。 SUS04-BP03 : ポリシーを使用してデータセットのライフサイクルを管理する SUS03-BP03 : 時間やリソースを最も多く消費するコード領域を最適化する SUS04-BP07 : ネットワーク間でのデータ移動を最小限に抑える 持続可能性のための AWS Config ルール SUS04-BP03: ポリシーを使用してデータセットのライフサイクルを管理する このベストプラクティスでは、ストレージ全体の使用量を最小限に抑えるために、未使用のデータを自動削除することをお勧めします。ビジネス要件を満たすためにデータ保持のニーズは組織全体で異なる場合があり、データを削除するために手動のアプローチを採用することはすぐに非現実的になる可能性があります。 Amazon S3 などの AWS のサービスを使用すると、ライフサイクル設定によって S3 オブジェクトを低コストのストレージへ移行、そして最終的にはオブジェクトの削除を自動化することができます。 AWS Config 内でルールを使用すると、ライフサイクル設定が Amazon S3 バケット全体に確実に適用されます。 # Rule-intent: Rule checks that lifecycle policies are configured for Amazon S3 bucket # # Expectations: # a) COMPLIANT when S3 bucket lifecycle is configured # b) NONCOMPLIANT when S3 bucket lifecycle is not configured # c) NOTAPPLICABLE when there is no S3 bucket rule checkBucketVersioningEnabled { supplementaryConfiguration.BucketLifecycleConfiguration exists <<Amazon S3 bucket lifecycle is not configured.>> } Plain text SUS03-BP03: 時間やリソースを最も多く消費するコード領域を最適化する 効率的なコードを使用すると、リソースの使用量が最小限に抑えられ、パフォーマンスが向上します。環境を監視して、改善の機会を特定し、バグやアンチパターンを除去する必要があります。 Amazon RDS の場合、 Performance Insights を使用してデータベースの負荷の原因を特定できるため、SQL クエリの影響を判断し、パフォーマンスを向上させるためにクエリを調整できます。Performance Insights は、 無料利用枠と有料利用枠の両方のオプション が提供されています。 以下の AWS Config ルールは、Performance Insights が RDS データベースに対して有効であることをチェックするため、データベースを監視して継続的な改善を図ることができます。 # Rule-intent: Rule checks that performance insights are enabled # # Expectations: # a) COMPLIANT when performance insights is enabled for RDS DBCluster or RDS DBInstance # b) NONCOMPLIANT when performance insights is not enabled for RDS DBCluster or RDS DBInstance ##Check whether performance Insights is enabled. rule rds_cluster_iam_authentication_enabled { configuration.performanceInsightsEnabled == true << Database cluster does not have performance insight enabled >> } Plain text SUS04-BP07: ネットワーク間でのデータ移動を最小限に抑える ネットワーク全体のデータ移動を最適化することで、ワークロードに必要なネットワークリソースの総量を削減し、環境への影響を軽減できます。このベストプラクティスを実装する際の考慮事項の 1 つは、API のデータ圧縮機能を有効にすることです。これにより、各リクエストで送信されるデータが削減され、ネットワーク全体でのデータの移動が削減されます。（データ圧縮によりデータの移動は最小限に抑えられますが、その代償としてデータを解凍するためにより多くのコンピューティング能力が必要になる可能性があることに注意してください。企業ではベストプラクティスの推奨事項をテストして、コンピューティングのトレードオフと比較したネットワーク使用量のレベルを判断し、どのアプローチが最も持続的に有益であるかを特定することをお勧めします。） このサンプルルールは、 Amazon API Gateway Rest API に対して圧縮機能が有効になっているかどうかをチェックします。 # Rule-intent: Rule checks compression is enabled for a Rest API # # Expectations: # a) COMPLIANT when compression is enabled # b) NONCOMPLIANT when compression is not enabled rule rest_api_compression_exists { configuration.minimumCompressionSize exists } Plain text 持続可能性ルールを大規模に導入する お客様は適合パックを使用して、上記の例のような AWS Config ルールを組織全体にデプロイし、持続可能性の目標に向けて取り組むことができます。Config ルールの使用を高速化するために、 適合パックの例 を作成しました。このパックには、持続可能性の柱の多くのベストプラクティスをサポートする次の 9 つの Config ルールが含まれており、 AWS Config コンソール または AWS コマンドラインインターフェイス を通じてデプロイできます。 サービス Config ルールの説明 持続可能性の柱のベストプラクティス API Gateway REST API の圧縮が有効になっているかをチェックします SUS04-BP07 CloudFront 圧縮が有効になっているかをチェックします (このルールは us-east-1 にデプロイする必要があることに注意してください) SUS04-BP07 EBS インスタンス終了時の EBS 削除が有効になっているかをチェックします SUS02-BP03 EC2 EC2 セキュリティグループに SSH 用のポート 22 が開いていないことをチェックし、代わりにセッションマネージャーを使用します SUS05-BP03 EFS EFS ライフサイクル管理が有効になっているかをチェックします SUS04-BP03 Lambda Lambda 関数が AWS Graviton ベースのプロセッサを使用しているかをチェックします SUS05-BP01 RDS RDS インスタンスが AWS Graviton ベースのプロセッサを使用しているかをチェックします SUS05-BP02 RDS Performance Insights が有効になっているかをチェックします SUS03-BP03 S3 Amazon S3 バケットのライフサイクル設定が存在するかをチェックします SUS04-BP03 * 上記の Config ルールは、実装手順とともに ここ にある適合パックに含まれています。 お客様は、この一連のサンプルルールを拡張して改善目標に合わせた追加の 持続可能性のベストプラクティス と照らし合わせてワークロードを評価することができます。お客様はこれらのルールを適応させて、環境内のリソースに対して Config カスタムルールを作成 できます。その後、適合パックを使用して組織全体に新しいルールを適用することができます。 まとめ このブログでは、 AWS Well-Architected Pillar for Sustainability に沿った AWS Config ルールを実装する方法を示し、そこには開始するための サンプル適合パック も含まれています。企業固有の持続可能性ポリシーに従ってこれらのルールを拡張または調整して持続可能性の目標を達成するために、さらにルールを追加できます。適合パックを介してこれらのルールを実装すると、リソースを効率的かつ大規模に評価できます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。 TAGS: aws config custom conformance packs , AWS Config Rules , AWS Well Architected Framework

概要 AWS PrivateLink は、複数の VPC やアカウント間でサービスを安全かつ簡単に共有・アクセスする方法を提供します。すべてのトラフィックはパブリックインターネットを経由せずに AWS ネットワーク上に留まります。これまで、プロバイダーとコンシューマーは同じ AWS リージョン内に存在する必要がありましたが、 AWS PrivateLink のネイティブなクロスリージョン接続のサポート開始 により、異なるリージョン間で VPC エンドポイントサービスを共有・アクセスできるようになりました。これにより、サービスプロバイダーは単一のリージョンから世界中の顧客に SaaS ソリューションをプライベートに提供できるようになります。コンシューマーは、同一リージョン内のサービスと同じように、インターフェースエンドポイントを使用してクロスリージョン対応のサービスに簡単に接続できます。PrivateLink を介したクロスリージョン接続は、シンプルで安全であり、さまざまなユースケースに合わせてカスタマイズ可能です。 本ブログでは、AWS PrivateLink を介したクロスリージョン接続の仕組みと、グローバルデータの境界線を保護するための制御方法を紹介します。その後、エンドツーエンドの接続を確立する方法を示し、アーキテクチャの選択に役立つ考慮事項とベストプラクティスについて詳しく説明します。以降、本ブログでは簡潔さのため、VPC エンドポイントサービスを「サービス」、インターフェイス VPC エンドポイントを「エンドポイント」、AWS リージョンを「リージョン」と呼びます。 クロスリージョンアーキテクチャ 今日、多くのプロバイダーは特定のリージョンでサービスを提供していますが、世界中にコンシューマーを抱えています。 この新機能のリリース 前は、コンシューマーが別リージョンのサービスにアクセスしたい場合、リージョン間の VPC ピアリングや Transit Gateway (TGW) ピアリングを設定する必要がありました。彼らは自分のネットワークに CIDR 重複がないことを確認し、ネットワークの信頼境界を保護するためのガードレールを確立する必要がありました。あるいは、プロバイダーが拠点を他のリージョンに拡大したい場合、各リージョンに追加のインフラストラクチャをプロビジョニングする必要がありました。これにより、サービスプロバイダーとコンシューマーの両方にコストと複雑さが増していました。 図1. 新機能以前のネイティブなクロスリージョンサポートがないトポロジー図 図1 は、これまでコンシューマーがリージョン外でホストされているサービスにどのようにアクセスしていたかを示しています。ネットワークの信頼境界は、プロバイダーとコンシューマー間の分離を示しています。これは VPC やアカウント、または組織の境界である場合があります。サービスにアクセスするために、コンシューマーはプロバイダーのリージョンのトランジット VPC へのリージョン間の VPC ピアリングまたは TGW ピアリング接続を確立する必要がありました。そして、トランジット VPC 内の Availability Zones (AZ) をプロバイダーと一致させる必要がありました。 この新機能リリースにより、PrivateLink はこれらの複雑さをすべて抽象化し、コンシューマーとプロバイダーに対してシンプルでネイティブなリージョン間接続体験を提供します。プロバイダーは、クロスリージョン接続を有効にするだけで、任意のリージョンのコンシューマーがそのサービスにアクセスできるようになります。コンシューマーは、リージョン内のサービスに接続するのと同じように、エンドポイントを使用してこれらのリモートサービスに接続できるようになります。 図2 は、クロスリージョン PrivateLink のアーキテクチャ例を示しています。図1 で示した、リージョン内のエンドポイントパスによる連鎖的なピアリングとは対照的に、クロスリージョン接続ではサービスプロバイダーとコンシューマー間の AZ の整合性は必要ありません。プロバイダーは、サービスリージョンで AWS Network Load Balancer (NLB) を固定するために最低 2 つの AZ を使用する必要があります。コンシューマーは必要に応じて、複数 AZ にインターフェースエンドポイントを作成することができますが、高可用性のために 2 つ以上の AZ を使用することを推奨してます。これにより、いずれかのリージョンで AZ 障害イベントが発生した場合、PrivateLink はプロバイダーとコンシューマーに対して透過的に、正常な AZ へトラフィックを動的に振り分けることができます。 図2. クロスリージョン PrivateLink を使用して簡略化されたアーキテクチャ例 クロスリージョンのアクセス制御 PrivateLink のクロスリージョン接続は、セキュリティを最優先に設計されており、多層防御を提供します。コンシューマー側とプロバイダー側の両方が、クロスリージョンでサービスを共有およびアクセスするための適切な権限が設定されていることを確認する必要があります。 クロスリージョン PrivateLink 接続をオプトイン: これまでのすべての PrivateLink アクションは ec2 名前空間に含まれていましたが、クロスリージョンのアクションは新しい vpce:AllowMultiRegion (アクセス許可のみ) アクションで制御されます。この許可をオプトインしないと、リージョン内の PrivateLink 接続は中断されずに維持されますが、リージョン間でのサービスの共有やアクセスは失敗します。 サービスとエンドポイントのクロスリージョンアクセスを制御: サービスプロバイダーまたはコンシューマーとして、ec2:VpceMultiRegion boolean 型キーは、サービスがリージョン間接続を有効にしているか、または VPC エンドポイントが別のリージョンの PrivateLink サービスに接続されているかを示します。例えば、このステートメントはローカルリージョンでのサービスの共有とアクセスを許可します。また、サービスへのリージョン間アクセスを有効にすることも可能ですが、リモートサービスへのエンドポイントの作成は拒否します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowserviceshareandcreateendpoint", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:ModifyVpcEndpointServiceConfiguration", "vpce:AllowMultiRegion", "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint" ], "Effect": "Allow", "Resource": "*" }, { "Sid": "denycrossregionendpoint", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint" ], "Effect": "Deny", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringEquals": { "ec2:VpceMultiRegion": "true" } } } ] } JSON プロバイダー側でサービスにアクセスできるリージョンを定義: サービスプロバイダーとして、 ec2:VpceSupportedRegion キーは、リモートアクセスを有効にできるリージョンを制限するのに役立ちます。例えば、このステートメントは、バージニア北部とアイルランドリージョン以外でのサービス共有を防ぎます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "limitserviceshare", "Action": [ "ec2:CreateVpcEndpointServiceConfiguration", "ec2:DeleteVpcEndpointServiceConfigurations", "ec2:DescribeVpcEndpointServiceConfigurations", "ec2:ModifyVpcEndpointServiceConfiguration", "vpce:AllowMultiRegion" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:vpc-endpoint-service/*", "Condition": { "ForAllValues:StringLike": { "ec2:VpceSupportedRegion": [ "us-east-1", "eu-west-1" ] } } } ] } JSON コンシューマー側でサービスにアクセスできるリージョンを定義: コンシューマーとして、 ec2:VpceServiceRegion キーは、エンドポイントを介してアクセスできるリモートサービスリージョンを定義するのに役立ちます。例えば、このステートメントは東京やアイルランドでホストされているサービスへのアクセスをブロックします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "allowcrossregionendpoints", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoints", "ec2:DescribeVpcEndpoints", "ec2:ModifyVpcEndpoint", "vpce:AllowMultiRegion" ], "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Effect": "Allow" }, { "Sid": "denyselectedregions", "Action": [ "ec2:CreateVpcEndpoint" ], "Effect": "Deny", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringLike": { "ec2:VpceServiceRegion": [ "ap-northeast-1", "eu-west-1" ] } } } ] } JSON オプトインリージョン: ほとんどのリージョンはデフォルトで AWS アカウントにおいてアクティブですが、2019年3月20日以降にローンチされたリージョンは、手動で選択した場合にのみアクティブ化されます。これらは オプトインリージョン と呼ばれます。オプトインリージョンからサービスへのアクセスを有効にする際、サービスプロバイダーはこれらのリージョンをオプトインする必要があります。同様に、コンシューマーがオプトインリージョンでホストされているサービスにアクセスしたい場合、まずそのリージョンをオプトインする必要があります。このガードレールは、アカウントで許可されていないリージョンへの、またはリージョンからの不測のアクセスを防ぐのに役立ちます。 これらの制御を組み合わせることで、あなたや組織は強固なセキュリティ境界を確立することができます。既存のリージョン内の PrivateLink 操作に影響を与えることなく、クロスリージョン間接続を選択したり、選択解除したりすることができます。これにより、管理された方法で機能を展開でき、データローカライゼーションに関する法的およびビジネス上のニーズに対応できます。 ステップバイステップのセットアップ このセクションでは、バージニア北部リージョンでサービスを作成し、オレゴンリージョンからアクセスする手順を説明します。これらの手順は、ポリシーにて vpce:AllowMultiRegion と必要な AWS PrivateLink アクション が許可されていることを前提としています。 サービスプロバイダーのセットアップ ステップ1: PrivateLink サービスの作成 新規または既存の NLB ベースのサービスに対して、クロスリージョンアクセスを有効にすることができます。この設定では、NLB と NLB ターゲットがすでに稼働していることを前提としています。バージニア北部リージョンの AWS VPC コンソールで、エンドポイントサービスを選択し、「エンドポイントサービスの作成」をクリックします。NLB のロードバランサータイプとして「ネットワーク」を選択します。利用可能なロードバランサーの中から、適切な NLB を選択します。ここでの「my-xrpl-svc」は、バージニア北部リージョンの4つのアベイラビリティーゾーンにわたって作成されています。 ステップ2: サポートリージョンの設定 サポートリージョンのドロップダウンを使用して、コンシューマーがサービスにアクセスできるリージョンを選択してください。オレゴン、シンガポール、アイルランドのリージョンからこのサービスへのアクセスを有効にします。この例では、簡略化のため、追加設定で「承認が必要」の選択を解除し、「IPv4」を選択しています。NLB と VPC の構成によって選択項目が異なる場合があります。 ステップ3: サービスの共有 サービスが作成されると、各サポートリージョンの状態が「保留中」から「利用可能」に変わるまで数分かかる場合があります。ここで生成されたサービス名をコンシューマーと共有して、サービスの発見を支援してください。PrivateLink サービスのセットアップおよび共有の残りの手順は、 このブログ で説明されているものと同じです。Application Load Balancer (ALB) を使用してサービスを構築している場合は、 こちら に手順が用意されています。 サービスコンシューマーのセットアップ ステップ1: PrivateLink サービスの発見 コンシューマーとして、サポートされているどのリージョンからでも、共有されたサービスにアクセスできます。AWS. VPC コンソールで、オレゴンリージョンに切り替えます。次に、PrivateLink and Lattice の下で、エンドポイントをクリックし、「エンドポイントの作成」を選択します。「NLB と GWLB を使用するエンドポイントサービス」を選択します。なお、クロスリージョン接続は現在、NLB ベースのサービスのみをサポートしており、AWS や Marketplace のサービスはサポートしていません。 サービスリージョンの下のボックスにチェックを入れて「クロスリージョンエンドポイントを有効にする」を選択し、サービスがホストされているバージニア北部リージョンを指定します。上記のサービスプロバイダーのセットアップ内のステップ3で生成されたサービス名を入力し、「サービスの検証」をクリックします。指定されたリージョンに提供された名前のサービスが存在し、アクセスが許可されている場合、「サービス名が検証されました」というメッセージが表示されます。ここでは、バージニア北部リージョンのサービスに接続するために、オレゴンリージョンに「my-xrpl-consumer」とタグ付けされた VPC エンドポイントが作成されます。 ステップ2: インターフェイスエンドポイントの作成 VPC エンドポイントを作成する VPC とサブネットを選択する必要があります。リージョン内の PrivateLink では、コンシューマーがサービスプロバイダーがサポートする AZ にのみエンドポイントを作成できますが、クロスリージョン接続では、AZ の整合性は必要ありません。必要な信頼性に応じて任意の数の AZ を選択でき、ニーズに最も適したサブネットを選択できます。 エンドポイントが作成され、「利用可能」状態になると、クロスリージョン接続が正常に確立されます。以下のように設定の詳細を確認することができます。 複数のエンドポイント DNS 名が生成されていることに注目してください。最初の DNS エントリはリージョナル DNS 名で、その後に各エンドポイントの AZ の DNS 名のエントリが続きます。この例では2つの AZ を使用しているため、合計3つの DNS 名があります。アプリケーションにはより高い可用性と回復性のため、リージョナル DNS 名の使用が推奨されます。また、エンドポイントでプライベート DNS 名を有効にすることで、プロバイダーのサービスにアクセスするためのカスタム名を使用することもできます。プライベート DNS　やサブネット、AZ に関する詳細については、 AWS PrivateLink ユーザーガイド を参照してください。 考慮事項 プロバイダー サービスへのアクセスを有効にできるリージョン数に制限はありません。ただし、同じ パーティション 内のリージョンからのアクセスのみを有効にすることができます。 クロスリージョンアクセスを有効にできるのは、NLB ベースのサービスのみです。現時点では、AWS サービスや Marketplace サービスはサポートされていません。 サポートリージョンのリストからリモートリージョンを削除することで、そのリージョンからのサービスへのアクセスを取り消すことができます。これにより、削除されたリージョンから新しいエンドポイントがサービスにアクセスすることを防げますが、既存のエンドポイントは維持されます。必要に応じて、これらのエンドポイントを手動で拒否する必要があります。 コンシューマー クロスリージョン接続は、インターフェイスタイプの VPC エンドポイントでのみサポートされています。 ローカルリージョンまたはリモートリージョンのサービスへの VPC エンドポイントは、いずれも「VPC ごとのインターフェイス VPC エンドポイント」クォータにカウントされます。詳細の確認とクォータ引き上げの申請は こちら で行えます。 まとめ AWS のグローバル展開に伴い、AWS PrivateLink のクロスリージョンサポートにより、SaaS サービスを1つのリージョンから世界中のカスタマーへシームレスに接続することができます。プロバイダーとコンシューマーの両方が、同じリージョンにインフラを設置することなく、互いにプライベートにアクセスすることを選択できます。 VPC コンソールのエンドポイントサービスとエンドポイントのオプションを使用して、AWS PrivateLink の利用を始めましょう。詳細については、 AWS PrivateLink ユーザーガイド とホワイトペーパー「 AWS PrivateLink を介したサービスへの安全なアクセス 」を参照してください。 本稿は、2024年12月11日に Networking & Content Delivery で公開された “ Introducing Cross-Region Connectivity for AWS PrivateLink ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

Amazon OpenSearch Service は、オープンソースの全文検索エンジン OpenSearch および可視化・分析ツールの OpenSearch Dashboards を、安全かつスケーラブルな形で提供するマネージドサービスです。 この度、日本語で検索技術について学べる Amazon OpenSearch Service のハンズオンコンテンツ「 Amazon OpenSearch Service 検索ワークショップ 」を公開したことをお知らせいたします。 ワークショップの概要 検索ワークショップは、OpenSearch の基本から最新の検索機能まで、段階的に学習することが可能なコンテンツです。Jupyter Notebook 形式で提供される「ラボ」を実行していくことで、OpenSearch を使用した検索機能の使い方を無理なく身に付けることができます。 日本語にフォーカスしたワークショップであることも大きなポイントです。ラボのコンテンツは日本語の特性を考慮した内容になっており、使用するデータや ML モデルも全て日本語に対応しています。 ワークショップに必要な AWS リソースは AWS CloudFormation を利用して素早く展開することが可能です。 ラボの紹介 ワークショップ内に現在実装されているラボは以下の通りです。ラボは随時追加、アップデートを行っていきます。 事前にラボの詳しい内容を確認したい場合は、「 JupyterLab のセットアップ 」ページ内の 「ワークショップアセットのダウンロードと展開」セクションに記載された URL を参考に、ノートブックのアーカイブファイルをローカル環境にダウンロードしてください。ローカル環境上の JupyterLab や Visual Studio Code といった .ipynb ファイルに対応したツールより、実行コードも含めたワークショップの内容をご確認いただけます。 OpenSearch の基本概念・検索の基礎 OpenSearch をはじめとした検索エンジンに初めて触れる方をターゲットとしたラボです。リレーショナルデータベースと検索エンジンとの違いを知りたい方にも最適です。本ラボでは、検索エンジン固有の概念の解説に始まり、データの管理方法や基本的な検索クエリを網羅的に試すことができます。本ラボで獲得したスキルは、システムにおける検索エンジンの採用要否の判断、使用するクエリの選定に役立ちます。 日本語全文検索の実装 日本語テキストの全文検索の実装を検討されている方、精度改善を検討されている方をターゲットとしたラボです。本ラボでは、表記ゆれといった日本語検索固有の課題を解消するための OpenSearch の機能や、日本語の形態素解析器である Kuromoji および Sudachi の利用方法を解説しています。本ラボで獲得したスキルは、日本語検索のチューニングに役立てることができます。 サジェスト機能の実装 サジェストは、ユーザーが検索窓に入力した文字列を元に適切なクエリの候補を返却する機能です。オートコンプリートなどとも呼ばれており、ユーザー体験向上や、ゼロ件ヒット削減に役立ちます。本ラボでは、日本の住所サンプルデータを使用し、プレフィクスベースのサジェスト機能を実装していきます。またサジェストを実装する上で、日本語固有の考慮事項についてもフォローしています。本ラボで獲得したスキルは、サジェストの実装に役立てることができます。 AI-powered search 本ラボは、従来型の全文検索では対応が難しい曖昧な文章による意味的検索や、文書の類似検索といった高度な検索要件を実現する手がかりを探している方をターゲットとしています。また、ベクトル検索などの最新の検索技術に興味がある方にも適しています。ベクトル検索をはじめとした機械学習モデルと連携した検索機能の実装方法を、手を動かしながら学習することができます。このラボは、以下のサブモジュールから構成されています。 ベクトル検索 ベクトル検索は、ある意味的に類似性のあるアイテムを検索する際に有用です。「暖かい服」で検索して 「セーター」の結果を得たいようなケースで役に立ちます。また、テキストだけではなく、画像や音声といった非構造データも扱うことが可能です。本モジュールでは、従来の全文検索では解決できない課題を、ベクトル検索を使って解決することを通してベクトル検索の有用性を確認していきます。また、OpenSearch のコネクタと呼ばれる機能についても学習します。コネクタを使用することで、テキストベースのクエリを機械学習モデルと連携してベクトルベースのクエリに変換し検索を行う、ニューラル検索を実装することができます。類似検索の実装方法を知りたい方にとって有用です。 スパース検索 スパース検索は、スパースエンコーディングモデル (単語の出現頻度に基づく疎なベクトル表現を生成するモデル) を活用した検索です。従来のベクトル検索と比較して、少ないリソースで類似検索を実装することができます。本ラボでは日本語に対応した SPLADE モデル (Sparse Lexical and Expansion Model) を用いて、ベクトル検索とは異なるアプローチで類似検索を実装していきます。ベクトル検索に加えて、異なる選択肢も検討したい方にお勧めです。 ハイブリッド検索 ハイブリッド検索は、複数の検索クエリの結果を組み合わせて、より精度の高い検索結果を提供するための機能です。テキスト検索・ベクトル検索のどちらが精度が出るかは対象のデータだけでなく、検索クエリにも依存します。ハイブリッド検索でベクトル検索と全文検索の組み合わせ検索を行うことで、様々な検索クエリに対して適切な結果を返すことが可能となります。本ラボでは、OpenSearch のハイブリッド検索機能を実際に試すことができます。ハイブリッド検索の実装を検討されている方にお勧めです。 リランキング リランキングは、一段階目の検索結果に対して、特定のロジックに基づき並べ替えを行うアプローチです。本ラボでは、ドキュメントとクエリ間の類似度を計算するクロスエンコーダーモデルを使用した、意味的類似度に基づくリランキングの実装方法を学ぶことができます。モデルによるリランキングの効果を確かめたい方にお勧めです。 ワークショップの開始方法 本ワークショップは AWS がホストするイベントでの提供の他、ご自身の AWS アカウントを利用して実行することもできます。AWS CloudFormation 用のテンプレートを使用することで、ワークショップに必要な以下のリソース群を素早く作成し、ラボを開始することができます。 詳しい始め方については、ワークショップ内の 準備作業 をご確認ください。 ご自身の AWS アカウントでワークショップを実行する場合、デプロイされたリソースに応じて料金が発生します。不要な料金発生を抑制するために、必ずワークショップ終了後は クリーンアップ 手順に沿ってワークショップリソースの削除を行ってください。 まとめ OpenSearch は柔軟性の高い強力な検索エンジンです。基本的なテキスト検索から最新のベクトル検索、ハイブリッド検索まで幅広い検索機能を提供しています。ワークショップを通して、OpenSearch の可能性を探ってみてください。 Amazon OpenSearch Service について更に詳しく知りたい方は、 Amazon OpenSearch Service 開発者ガイド および AWS Black Belt 資料をご覧ください。 ソリューションアーキテクト 榎本 貴之 (X: @tkykenmt )

毎年 3 月 14 日 (3.14) に開催される AWS Pi Day では、データの管理と利用に役立つ AWS のイノベーションを重点的に取り上げます 。2021 年に Amazon Simple Storage Service (Amazon S3) のリリース 15 周年を記念して始まったこのイベントは、現在ではクラウドテクノロジーがデータ管理、分析、AI をどのように変革しているのかに重点を置くイベントに成長しました。 2025 年の AWS Pi Day は、AWS 上の統合データ基盤を使用した分析と AI のイノベーションの加速に焦点を当てて開催されます。ほとんどのエンタープライズ戦略で AI が登場し、分析と AI のワークロードがますます相互に関連し、多くの同じデータとワークフローを使用するようになる中で、データ環境は大きな変革を遂げています。すべてのデータにアクセスし、単一の統合エクスペリエンスですべてのお好みの分析および AI ツールを使用するための簡単な方法が求められています。2025 年の AWS Pi Day では、統合データエクスペリエンスの構築に役立つ一連の新機能をご紹介します。 次世代の Amazon SageMaker: すべてのデータ、分析、AI の中心 re:Invent 2024 では、すべてのデータ、分析、AI の中心となる 次世代の Amazon SageMaker を発表しました 。 SageMaker には、データの探索、準備、統合、ビッグデータ処理、高速 SQL 分析、 機械学習 (ML) モデルの開発とトレーニング、 生成 AI アプリケーション開発に必要なほぼすべてのコンポーネントが含まれています。この新世代の Amazon SageMaker では、 SageMaker Lakehouse がデータへの統合アクセスを提供し、 SageMaker Catalog がガバナンスとセキュリティの要件を満たすのをサポートします。詳細については、同僚の Antje が書いた リリースに関するブログ記事 をお読みください。 次世代の Amazon SageMaker の中核となるのは、 SageMaker Unified Studio です。これは、分析と AI のためにすべてのデータとツールを使用できる単一のデータおよび AI 開発環境です。 SageMaker Unified Studio の一般提供が開始されました 。 SageMaker Unified Studio は、データ、分析、AI ワークフロー、およびアプリケーションに取り組むデータサイエンティスト、アナリスト、エンジニア、およびデベロッパー間のコラボレーションを容易にします。データ処理、SQL 分析、ML モデル開発、生成 AI アプリケーション開発など、AWS の分析および 人工知能と機械学習 (AI/ML) サービスの使い慣れたツールを単一のユーザーエクスペリエンスで使用できるようにします。 また、 SageMaker Unified Studio は、 Amazon Bedrock からの特定の機能を SageMaker で使用できるようにします。。 基盤モデル (FM) と、 Amazon Bedrock のナレッジベース 、 Amazon Bedrock ガードレール 、 Amazon Bedrock エージェント 、 Amazon Bedrock Flows などの高度な機能を使用して、迅速に生成 AI アプリケーションのプロトタイプを作成したり、生成 AI アプリケーションをカスタマイズおよび共有したりして、お客様の要件と、責任ある AI ガイドラインに整合する、カスタマイズされたソリューションを、すべて SageMaker 内で作成できるようになりました。 最後に、 Amazon Q Developer の 一般提供が SageMaker Unified Studio で開始されました 。Amazon Q Developer は、データと AI 開発のために、生成 AI を活用したサポートを提供します。SQL クエリの記述、抽出、変換、ロード (ETL) ジョブの構築、トラブルシューティングなどのタスクでお客様をサポートし、既存のサブスクライバーは 無料の階層と Pro の階層 で利用できます。 同僚の Donnie が最近書いたブログ記事で、 SageMaker Unified Studio の詳細をご覧いただけます。 re:Invent 2024 では、次世代の SageMaker の一部として Amazon SageMaker Lakehouse もリリースしました。SageMaker Lakehouse は、Amazon S3 データレイク、 Amazon Redshift データウェアハウス、サードパーティーおよびフェデレーテッドデータソース全体ですべてのデータを統合します。データの単一コピーを使用して強力な分析および AI/ML アプリケーションを構築するのに役立ちます。SageMaker Lakehouse は、 Apache Iceberg 互換のツールとエンジンを使用して、データにインプレースでアクセスしてクエリを実行する柔軟性を提供します。さらに、ゼロ ETL 統合により、 Amazon Aurora および Amazon DynamoDB などの AWS データソースや、 Salesforce 、 Facebook Ads 、 Instagram Ads 、 ServiceNow 、 SAP 、 Zendesk 、 Zoho CRM などのアプリケーションから SageMaker Lakehouse にデータを取り込むプロセスが自動化されます。 統合の詳細なリストは、「SageMaker Lakehouse に関するよくある質問」でご覧いただけます 。 Amazon S3 を利用したデータ基盤の構築 データ基盤の構築は、分析と AI ワークロードを加速するための基礎であり、組織があらゆる規模でデータアセットをシームレスに管理、検出、活用できるようにします。Amazon S3 は、事実上無制限の規模でデータレイクを構築するのに最適な場所であり、この変革に不可欠な基盤を提供します。 私は Amazon S3 の運用規模を知るたびに驚かされます。現在、Amazon S3 は 400 兆を超えるオブジェクト、エクサバイト規模のデータを保持しており、1 秒あたり 1 億 5,000 万件という驚異的な数のリクエストを処理しています。わずか 10 年前は、S3 に 1 ペタバイト (PB) を超えるデータを保存しているお客様の数は 100 にも届いていませんでした。今日では、何千ものお客様が 1 PB のマイルストーンを超えています。 Amazon S3 はエクサバイト規模の表形式データを保存し、1 秒あたり平均 1,500 万件を超える、表形式データに対するリクエストを処理しています。S3 バケットで表形式データを管理する際の、付加価値を生まない手間のかかる作業を軽減するのに役立つよう、 当社は AWS re:Invent 2024 で Amazon S3 Tables を発表しました 。S3 Tables は、Apache Iceberg のサポートが組み込まれた初のクラウドオブジェクトストアです。S3 テーブルは分析ワークロード向けに特別に最適化されており、セルフマネージドテーブルと比較して、クエリスループットが最大 3 倍高速になり、1 秒あたりのトランザクション数が最大 10 倍になります。 3 月 14 日、 弊社は、 Amazon S3 Tables と Amazon SageMaker Lakehouse の統合の 一般提供の開始 を発表しました。 Amazon S3 Tables が Amazon SageMaker Lakehouse と統合するようになったため、Amazon Redshift、 Amazon Athena 、 Amazon EMR 、 AWS Glue などの AWS の分析サービスや、Apache Spark や PyIceberg などの Apache Iceberg 互換エンジンから S3 Tables に簡単にアクセスできるようになりました。SageMaker Lakehouse を利用すると、S3 Tables や他のソースについてのきめ細かなデータアクセス許可を一元的に管理し、すべてのエンジンで一貫して適用できます。 サードパーティーのカタログを使用しているお客様、カスタムカタログ実装があるお客様、または単一のテーブルバケット内の表形式データに対する基本的な読み取りおよび書き込みアクセスのみを必要とするお客様のために、 当社は、 Iceberg REST Catalog 標準 と互換性のある 新しい API を追加しました 。これにより、Iceberg 互換のアプリケーションは、S3 テーブルバケット内のテーブルをシームレスに作成、更新、一覧表示、削除できます。すべての表形式データ、データガバナンス、およびきめ細かなアクセスコントロールにわたる統合データ管理のために、SageMaker Lakehouse で S3 Tables を使用することもできます。 S3 Tables にアクセスしやすくするために、 AWS マネジメントコンソール で更新の提供を開始しました 。Amazon Athena を利用して、テーブルを作成し、データを入力して、S3 コンソールから直接クエリを実行できるようになりました。これにより、使用を開始して、S3 テーブルバケット内のデータを分析するのがより簡単になりました。 次のスクリーンショットは、S3 コンソールから直接 Athena にアクセスする方法を示しています。 [Athena を利用してテーブルをクエリ] または [Athena を利用してテーブルを作成] を選択すると、適切なデータソース、カタログ、データベースで Athena コンソールが開きます。 re:Invent 2024 以降、当社は速いペースで S3 Tables に新しい機能を追加し続けています。例えば、 CreateTable API にスキーマ定義のサポートを追加 しました。これにより、 S3 テーブルバケットに最大 10,000 個のテーブルを作成できるようになりました 。また、S3 Tables は 8 つの追加の AWS リージョン でもリリースされました。最新のリリースは 3 月 4 日のアジアパシフィック (ソウル、シンガポール、シドニー) であり、今後も他のリージョンでリリースされる予定です。現在 S3 Tables が利用可能な 11 のリージョンのリストについては、ドキュメントの S3 Tables の AWS リージョン のページをご覧ください。 Amazon S3 Metadata ( re:Invent 2024 で発表 ) は、 1 月 27 日から一般提供が開始 されています。これは、ほぼリアルタイムで更新される、自動化された簡単にクエリできるメタデータを使用して、S3 データを検出して理解するのに役立つ極めて迅速かつ簡単な方法です。S3 Metadata は S3 オブジェクトタグと連携して機能します。タグは、IAM ポリシーを適用してきめ細かなアクセスを提供したり、タグベースのフィルターを指定してオブジェクトのライフサイクルルールを管理したり、データを別のリージョンに選択的にレプリケートしたりするなど、さまざまな理由でデータを論理的にグループ化するのに役立ちます。S3 Metadata が利用可能なリージョンでは、オブジェクトタグとして保存されているカスタムメタデータをキャプチャしてクエリできます。S3 Metadata を使用する際にオブジェクトタグに関連して発生するコストを削減するために、 Amazon S3 は、すべてのリージョンで S3 オブジェクトタグ付けの料金を 35% 引き下げました 。これにより、カスタムメタデータの使用コストが削減されます。 AWS Pi Day 2025 長年にわたって、AWS Pi Day では、クラウドストレージとデータ分析における主要なマイルストーンをご紹介してきました。2025 年の AWS Pi Day 仮想イベントでは、デベロッパーや技術的な領域における意思決定者、データエンジニア、AI/ML 実践者、IT リーダー向けに設計されたさまざまなトピックを取り上げます。主なハイライトには、この記事で説明したすべてのサービスと機能に関する詳細な説明、ライブデモ、エキスパートによるセッションが含まれます。 このイベントに参加することで、分析と AI のイノベーションを加速する方法を学ぶことができます。ネイティブの Apache Iceberg サポートおよび S3 Metadata とともに S3 Tables を使用して、従来の分析と新しい AI/ML ワークロードの両方に対応するスケーラブルなデータレイクを構築する方法を学びます。また、すべてのデータ、分析、AI の中心となる次世代の Amazon SageMaker についても学びます。これは、データレイク、データウェアハウス、サードパーティーまたはフェデレーテッドデータソースに保存されているすべてのデータにアクセスできる使い慣れた AWS ツールを使用して、チームが統合スタジオからコラボレーションし、より迅速に構築するのに役立ちます。 クラウドに関する最新のトレンドを先取りしたいお客様にとって、 AWS Pi Day 2025 は見逃せないイベントです 。データレイクハウスの構築、AI モデルのトレーニング、生成 AI アプリケーションの構築、分析ワークロードの最適化など、進めている取り組みがどのようなものであっても、共有されたインサイトはデータの価値を最大化するのに役立ちます。 今すぐ視聴 して、クラウドデータイノベーションに関する最新情報をご覧ください。データ、分析、AI の未来を形作る AWS のエキスパート、パートナー、お客様とつながる機会をお見逃しなく。 3 月 14 日のバーチャルイベントを見逃したお客様もご安心ください。いつでも イベントページ にアクセスして、すべてのコンテンツをオンデマンドでご視聴いただけます! – seb ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

本記事は 2025 年 3 月 6 日に公開された “ Announcing support for upgrades to Java 21 in Amazon Q Developer ” を翻訳したものです。 2 月 14 日、Amazon Q Developer は Java 21 へのアップグレード対応を発表 しました。Java 開発者として、この新機能にはとても興奮しています。これにより、アプリケーションを最新の状態に保ち、最新の言語機能やパフォーマンス向上を活用しやすくなります。さらに、最新バージョンの Amazon Q Developer は、アップグレードプロセスを簡素化し、結果に対する信頼性を高めるために、要約と推奨機能が改善されています。 Amazon Q Developer は、エンタープライズアプリケーションのモダナイゼーションを加速させるのに役立つ生成 AI を活用したアシスタントです。レガシーコードの分析、依存関係のマッピング、移行・モダナイゼーションワークフローの実行など、複雑なタスクを処理できます。Amazon Q Developer により、チームは Java アプリケーションのアップグレードといった手間のかかる作業に追われることなく、より戦略的な取り組みに集中できるようになります。 新しいリリースごとに、重要なセキュリティ修正、パフォーマンスの強化、新しいフレームワークやライブラリのサポートが行われるため、Java のバージョンを最新の状態に保つことは非常に重要です。しかし、大規模な Java コードベースを手動で移行するのは非常に負担の大きい作業です。そこで Amazon Q Developer が大きな役割を果たします。退屈で労力のかかるアップグレード作業をオフロードすることで、チームはより迅速に重要な更新を提供でき、システムへの影響も最小限に抑えることが可能になります。 Java 21 の利点 Java 21 へのアップグレード機能の追加により、Amazon Q Developer は Java 8、11、17 から Java 17 または 21 へのアプリケーションのアップグレードをサポートするようになりました。私が特に期待している Java 21 の主な利点には以下があります。 仮想スレッド: 仮想スレッド は Java 19 で導入された新しい並行処理の仕組みであり、高スループットな並行アプリケーションの開発、保守、デバッグの負担を軽減します。これにより、アプリケーションのパフォーマンスが大幅に向上します。 パフォーマンスの改善: Java 21 では、 Sequenced Collections 、 Record Patterns 、 Pattern Matching などのさまざまな言語機能が強化されており、処理速度と効率性の向上が期待できます。 メモリ管理の向上: Java 21 の Z Garbage Collector の強化により、ガベージコレクションの一時停止時間がより予測しやすくなり、メモリ使用量も削減されます。これにより、アプリケーションの安定性と応答性が向上します。 Amazon Q Developer を活用してチームの Java アプリケーションを Java 21 にアップグレードすることは、大きな変革となります。これにより、すべての Java コンポーネントを手作業で移行するために必要だった膨大な時間を節約できます。 Amazon Q Developer によるアップグレードプロセスの簡略化 Amazon Q Developer を使用すれば、Java アプリケーションを Java 21 に簡単にアップグレードできます。プロジェクトの設定を行い、必要な 前提条件 を満たしたら、統合開発環境 (IDE) の Amazon Q Developer チャットウィンドウで /transform コマンドを 実行 するだけです。以下のスクリーンショットは VS Code のものですが、Q Developer は IntelliJ IDEA を含む JetBrains の IDE や qct コマンドライン にも対応しています。 Amazon Q Developer はコードベースを分析し、Java 21 へのアップグレードに必要な変更を特定します。その後、詳細な差分を提供するため、変更内容をレビューし、適用することができます。これにより、時間を節約できるだけでなく、すべての Java アプリケーションに対して一貫性のある高品質なアップグレードを実現できます。 最新バージョンの Amazon Q Developer では、Java 21 へのアップグレード対応に加えて、変換完了後に提供される要約と推奨事項も強化されています。Java 21 へのアップグレードが完了すると、Amazon Q Developer は非推奨 API の削除や、新しい Java 機能を活用するためのコードのリファクタリングなど、変更内容の詳細なサマリーを生成します。さらに、Java 21 の機能を最大限に活用するためのカスタマイズされた推奨事項も提供されます。たとえば、Amazon Q Developer はロギングフレームワークのアップグレードや、パターンマッチングの導入によるコードの簡潔化を提案しました。これらの要約と推奨の機能により、スムーズで包括的なアップグレードプロセスを実現できます。 最後に、Q は Java 21 へのアップグレードにとどまらず、アプリケーションのさらなる改善に向けた推奨事項も提供します。たとえば、Q は以下のような推奨を行いました。 要約と推奨の機能により、スムーズで包括的なアップグレードを実現できます。開発者は詳細な変更内容をレビューし、その背景を理解した上で、提案された最適化を選択的に適用することができます。これにより、Java 21 の利点を最大限に活用できるようになります。Amazon Q Developer の透明性とガイダンスにより、アップグレードプロセスが大幅に簡素化され、最終的なコードベースに対する信頼性も向上します。 まとめ まとめると、Amazon Q Developer の新しい変換機能により、Java 21 へのアップグレード作業の負担が大幅に軽減されます。Amazon Q Developer が提供する詳細なサマリーとカスタマイズされた推奨事項により、スムーズかつ包括的なアップグレードが可能になり、プロセス全体が効率化されます。この機能を活用し、チームの時間をより価値の高い業務に充てられることを楽しみにしています。Java 開発者の方には、ぜひ Amazon Q Developer を試してみることをおすすめします。始めるには、 Amazon Q Developer の使用を開始するページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。

3 月 13 日、 Amazon SageMaker Unified Studio の一般提供について発表します。Amazon SageMaker Unified Studio は、組織内のすべてのデータを検索してアクセスし、ほとんどすべてのユースケースの業務で適切なツールを使用してデータを利用できる単一のデータおよび AI 開発環境です。AWS re:Invent 2024 で プレビューとして紹介 され、私の同僚の Antje は次のように記しています。 SageMaker Unified Studio (プレビュー) は単一のデータおよび AI 開発環境です。現在の Amazon Athena 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA )、既存の SageMaker Studio の幅広いスタンドアロンの「スタジオ」、クエリエディタ、ビジュアルツールの機能とツールがまとめられています。 Amazon SageMaker Unified Studio の機能を示す動画を以下に紹介します。 SageMaker Unified Studio は、データやツールのサイロを解消し、データエンジニア、データサイエンティスト、データアナリスト、ML 開発者、その他のデータプラクティショナーに単一の開発エクスペリエンスを提供します。開発時間が節約され、アクセス制御管理が簡素化されるため、データプラクティショナーは自分にとって本当に重要なタスクであるデータ製品と AI アプリケーションの構築に集中することができるようになります。 この投稿では、私たちが共有できることを嬉しく思っているいくつかの重要な発表にフォーカスします。 SageMaker Unified Studio 内の Amazon Bedrock の新機能 – 今回の統合により、Anthropic の Claude 3.7 Sonnet や DeepSeek-R1 などの新しい基盤モデル (FM) のサポート、ナレッジベースの作成を目的としたプロジェクト内の Amazon Simple Storage Service (Amazon S3) フォルダからのデータソーシング、そしてフローへのガードレール機能の拡張が実現し、複数の Amazon Web Services (AWS) アカウントにわたるモデルガバナンスを管理するドメイン管理者向けの合理化されたユーザー管理インターフェイスが提供されます。 SageMaker Unified Studio 内での Amazon Q Developer の一般提供開始 – ソフトウェア開発用の最も高機能な生成 AI アシスタントである Amazon Q Developer は、SQL クエリの記述、ETL ジョブの構築、トラブルシューティング、リアルタイムでのコード提案の生成などのタスクを簡素化する自然言語での会話型インターフェイスを提供することで Amazon SageMaker Unified Studio での開発を能率化します。 使用を開始するには、 Amazon SageMaker コンソール にアクセスして SageMaker Unified Studio ドメインを作成します。詳細については、AWS ドキュメントの「 Create a Amazon SageMaker Unified Studio domain 」を参照してください。 SageMaker Unified Studio 内の Amazon Bedrock の新機能 Amazon SageMaker Unified Studio 内の Amazon Bedrock の機能は、開発者が生成 AI アプリケーションを迅速に作成してカスタマイズするための統制されたコラボレーション環境を提供します。この直感的なインターフェイスは、あらゆるスキルレベルの開発者に対応しており、Amazon Bedrock で提供される高性能 FM や、カスタマイズされた生成 AI アプリケーションを共同開発するための高度なカスタマイズツールにシームレスにアクセスできます。 プレビュー版のリリース以降、Amazon Bedrock で利用できるようになった Anthropic の Claude 3.7 Sonnet や DeepSeek-R1 などの新しい FM は SageMaker Unified Studio と完全に統合されています。これらのモデルは、生成 AI アプリの構築と SageMaker Unified Studio のプレイグラウンドでのチャットに使用できます。 プロジェクトでのモデル選択で Anthropic の Claude 3.7 Sonnet を選択する方法を以下に示します。 ナレッジベースを作成する際に、プロジェクト内の S3 フォルダからデータまたはドキュメントを指定し、特定の FM を選択することもできます。 ユースケースと責任ある AI ポリシーに基づいて Amazon Bedrock アプリケーションのセーフガードを実装 できるよう、プレビュー中に Amazon Bedrock ガードレールが導入されました。現在、この一般提供のリリースにより、Amazon Bedrock ガードレールが Amazon Bedrock Flows に拡張されました。 さらに、関連付けられたアカウントの生成 AI セットアップが SageMaker Unified Studio の新しいユーザー管理インターフェイスによって合理化さるので、ドメイン管理者は、関連付けられたアカウント管理者にモデルガバナンスプロジェクトへのアクセス許可を簡単に付与できるようになりました。この機能強化により、コマンドラインの操作が不要になり、複数の AWS アカウントにわたる生成 AI 機能の設定プロセスが能率化されます。 これらの新機能により、生成 AI 開発プロセスにおけるデータ、ツール、ビルダーの間の障壁が排除されます。Amazon Bedrock の強力なすべての生成 AI 機能を同じワークスペースに組み込むことで、チームは統合された開発エクスペリエンスを利用できます。 SageMaker Unified Studio 内での Amazon Q Developer の一般提供開始 Amazon SageMaker Unified Studio 内での Amazon Q Developer の一般提供が開始され、データプロフェッショナルは、データと AI 開発ライフサイクル全体にわたって生成 AI を活用したアシスタンスを利用できるようになりました。 Amazon Q Developer は、データ処理、SQL 分析、機械学習モデル開発、生成 AI アプリケーション開発を始めとする SageMaker Unified Studio 内の AWS 分析と AI/ML ツールとサービスの完全なスイートと統合し、コラボレーションを促進して、チームがデータおよび AI 製品をより迅速に構築することを可能にします。使用を開始するには、Amazon Q Developer のアイコンを選択します。 SageMaker Unified Studio の新規ユーザーにとって、Amazon Q Developer は非常に貴重なオンボーディングアシスタントとしての役割を果たします。ドメインやプロジェクトなどのコアコンセプトの説明や環境の設定に関するガイダンスに加えて、ユーザーの質問に対する回答が提供されます。 Amazon Q Developer では、自然言語による SageMaker Catalog との強力な対話を介したデータの検出と理解が可能になります。この実装は、Amazon Q Developer が AWS 分析と AI/ML サービスに関する幅広い知識をユーザーのコンテキストと組み合わせてパーソナライズされたガイダンスを提供することによって強力な機能を提供します。 会話型インターフェイスからデータ資産に関するチャットを行って「支払いに関連するすべてのデータセットを表示してください」などの質問をすることができます。複雑なメタデータ構造をナビゲートする必要はありません。 Amazon Q Developer では、SageMaker Unified Studio で使用可能な組み込みのクエリエディタとの統合を介して SQL クエリを生成できます。さまざまなスキルレベルのデータプロフェッショナルが自然言語で分析ニーズを表現し、適切な形式の SQL クエリを受け取ることができるようになりました。 例えば、「年齢層と地域ごとの支払い方法の好みを分析してください」と依頼すると、Amazon Q Developer は複数のテーブルにわたる適切な結合を含む適切な SQL を生成します。 さらに、Amazon Q Developer は、ETL ジョブの構築に加えて、SageMaker Unified Studio Jupyter Notebook でのトラブルシューティングとリアルタイムでのコード提案の生成で開発者を支援することもできます。 今すぐご利用いただけます 利用可能なリージョン – Amazon SageMaker Unified Studio は現在、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、アジアパシフィック(ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン)、南米 (サンパウロ) の AWS リージョンでご利用いただけます。これらの機能の可用性の詳細については、 サポートされているリージョンのドキュメント ページを参照してください。 Amazon Q Developer サブスクリプション – Amazon Q Developer の無料利用枠はデフォルトで SageMaker Unified Studio で使用できます。追加のセットアップや設定は必要ありません。既に Amazon Q Developer Pro ティアのサブスクリプションをお持ちの場合は、これらの機能強化を SageMaker Unified Studio 環境で使用できます。詳細については、 ドキュメントのページ を参照してください。 Amazon Bedrock の機能 – Amazon SageMaker Unified Studio 内の Amazon Bedrock の機能の詳細については、 ドキュメントページ を参照してください。 Amazon SageMaker Unified Studio での構築を今すぐ開始してください。詳細については、 Amazon SageMaker Unified Studio のページを参照してください。 構築がうまくいきますように。 – Donnie Prakoso – ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。

re:Invent 2024 では、表形式データの保存を大規模に効率化する組み込みの Apache Iceberg サポートを備えた初のクラウドオブジェクトストアである Amazon S3 Tables と、オープンで安全な統合データレイクハウスで分析と AI を簡素化する Amazon SageMaker Lakehouse をリリースしました。また、 Amazon Athena 、 Amazon Data Firehose 、 Amazon EMR 、 AWS Glue 、 Amazon Redshift 、 Amazon QuickSight を利用して S3 Tables データをストリーミング、クエリ、視覚化できるように、 Amazon Web Services (AWS) 分析サービスとの S3 Tables の統合もプレビューしました。 お客様は、Apache Iceberg ストレージの管理と最適化を簡素化したいと考えており、それが S3 Tables の開発につながりました。お客様は同時に、SageMaker Lakehouse を利用して、分析のコラボレーションとインサイトの生成を妨げるデータサイロを解消することに取り組んでいました。AWS の分析サービスとの組み込み統合に加えて、S3 Tables と SageMaker Lakehouse を組み合わせると、分析と機械学習 (ML) ワークフローの両方を可能にする複数のデータソースへのアクセスを統合する包括的なプラットフォームが得られます。 3 月 13 日、さまざまな分析エンジンとツールで S3 Tables の統合データアクセスを提供する Amazon S3 Tables と Amazon SageMaker Lakehouse の統合 の一般提供の開始をお知らせします。SageMaker Lakehouse には、AWS の分析および AI/ML サービスの機能とツールを統合した単一のデータおよび AI 開発環境である Amazon SageMaker Unified Studio からアクセスできます。SageMaker Lakehouse と統合されたすべての S3 テーブルデータは、SageMaker Unified Studio や、Amazon Athena、Amazon EMR、Amazon Redshift、Apache Iceberg 互換エンジン ( Apache Spark や PyIceberg など) などのエンジンからクエリできます。 この統合により、S3 Tables を読み書きしたり、Amazon Redshift データウェアハウスやサードパーティーおよびフェデレーテッドデータソース ( Amazon DynamoDB や PostgreSQL など) のデータと結合したりできる、安全な分析ワークフローの構築を簡素化できます。 また、S3 Tables のデータと SageMaker Lakehouse の他のデータに対するきめ細かいアクセス許可を一元的に設定および管理し、すべての分析エンジンとクエリエンジンに一貫して適用することもできます。 S3 Tables と SageMaker Lakehouse の統合の実際の動作 開始するには、 Amazon S3 コンソール に移動して、ナビゲーションペインから [テーブルバケット] を選択し、 [統合を有効にする] を選択して、AWS の分析サービスからテーブルバケットにアクセスします。 これで、SageMaker Lakehouse と統合するテーブルバケットを作成できます。詳細については、AWS ドキュメントの「 S3 Tables の開始方法 」にアクセスしてください。 1.Amazon S3 コンソールで Amazon Athena を利用してテーブルを作成する Amazon Athena を利用して、わずか数ステップでテーブルを作成し、データを入力して、Amazon S3 コンソールから直接クエリできます。テーブルバケットを選択して [Athena でテーブルを作成] を選択するか、または既存のテーブルを選択して [Athena でテーブルをクエリ] を選択します。 Athena を利用してテーブルを作成する場合は、まずテーブルの 名前空間 を指定する必要があります。S3 テーブルバケット内の名前空間は AWS Glue のデータベースに相当し、テーブルの名前空間を Athena クエリのデータベースとして使用します。 名前空間を選択し、 [Athena でテーブルを作成] を選択します。Athena コンソールの [クエリエディタ] に移動します。S3 テーブルバケット内にテーブルを作成したり、テーブル内のデータをクエリしたりできます。 2.SageMaker Unified Studio で SageMaker Lakehouse を利用してクエリする SageMaker Unified Studio から直接、S3 データレイク、Redshift データウェアハウス、SageMaker Lakehouse 内のサードパーティーおよびフェデレーテッドデータソース全体の統合データにアクセスできるようになりました。 開始するには、 SageMaker コンソール に移動し、サンプルプロジェクトプロファイル Data Analytics and AI-ML model development を私用して、SageMaker Unified Studio ドメインとプロジェクトを作成します。詳細については、AWS ドキュメントの「 Create an Amazon SageMaker Unified Studio domain 」にアクセスしてください。 プロジェクトが作成されたら、プロジェクトの概要に移動し、プロジェクトの詳細まで下方向にスクロールして、プロジェクトロールの Amazon リソース名 (ARN) を書き留めます。 AWS Lake Formation コンソール に移動し、 AWS Identity and Access Management (IAM) ユーザーとロールに許可を付与します。 [プリンシパル] セクションで、前の段落で書き留めた <project role ARN> を選択します。 [LF タグまたはカタログリソース] セクションで [名前付きデータカタログリソース] を選択し、 [カタログ] のために作成したテーブルバケット名を選択します。詳細については、AWS ドキュメントの「 Overview of Lake Formation permissions 」にアクセスしてください。 SageMaker Unified Studio に戻ると、プロジェクトページの左側のナビゲーションペインにある [データ] メニューの [Lakehouse] の下にテーブルバケットプロジェクトが表示されます。 [アクション] を選択すると、Amazon Athena、Amazon Redshift、または JupyterLab Notebook でテーブルバケットデータをクエリする方法を選択できます。 [Athena でクエリ] を選択すると、自動的に [クエリエディタ] に移動し、Athena を利用して S3 テーブルに対してデータクエリ言語 (DQL) およびデータ操作言語 (DML) クエリを実行します。 Athena を利用したサンプルクエリを次に示します: select * from "s3tablecatalog/s3tables-integblog-bucket”.”proddb"."customer" limit 10; Amazon Redshift を利用してクエリするには、データクエリ分析のために Amazon Redshift Serverless コンピューティングリソースを設定する必要があります。その後、 [Redshift でクエリ] を選択し、 [クエリエディタ] で SQL を実行します。JupyterLab Notebook を利用する場合は、 Amazon EMR Serverless で新しい JupyterLab スペースを作成する必要があります。 3.他のソースのデータと S3 Tables データを結合する SageMaker Lakehouse で S3 Tables データを利用できるようになったことで、データウェアハウス、リレーショナルまたは非リレーショナルデータベースなどのオンライントランザクション処理 (OLTP) ソース、Iceberg テーブル、他のサードパーティーソースのデータと結合して、より包括的で深いインサイトを得ることができるようになりました。 例えば、 Amazon DocumentDB 、Amazon DynamoDB、Amazon Redshift、PostgreSQL、MySQL、Google BigQuery、Snowflake などのデータソースへの接続を追加し、抽出、変換、ロード (ETL) スクリプトを使用せずに SQL を使用してデータを結合できます。 クエリエディタで SQL クエリを実行して、S3 Tables のデータと DynamoDB のデータを結合できるようになりました。 Athena と DynamoDB を結合するサンプルクエリを次に示します: select * from "s3tablescatalog/s3tables-integblog-bucket"."blogdb"."customer", "dynamodb1"."default"."customer_ddb" where cust_id=pid limit 10; この統合の詳細については、AWS ドキュメントの「 Amazon S3 Tables integration with Amazon SageMaker Lakehouse 」にアクセスしてください。 今すぐご利用いただけます S3 Tables と SageMaker Lakehouse の統合は、 S3 Tables が利用可能な すべての AWS リージョンで一般提供が開始されました。詳細については、 S3 Tables の製品ページ と SageMaker Lakehouse のページ にアクセスしてください。 今すぐ SageMaker Unified Studio で S3 Tables をお試しいただき、 AWS re:Post for Amazon S3 および AWS re:Post for Amazon SageMaker に、または通常の AWS サポートの連絡先を通じて、フィードバックをぜひお寄せください。 Amazon S3 のリリース の毎年恒例のお祝いとして、Amazon S3 と Amazon SageMaker のすばらしいリリースをさらにご紹介する予定です。詳細については、 3 月 14 日に開催される AWS Pi Day イベント にご参加ください。 – Channy – ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載されているとおりにお客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません) 原文は こちら です。