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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 &nbsp;や AWS Compute Optimizer を活用しています。なお AWS への移行により、柔軟にリソースを用意できるようになったり、ログの管理や収集がしやすくなったりするなどのメリットを感じられています。今後は、 AWS Systems Manager の活用、セキュリティ管理機能の強化、運用監視の一元化などを目指しています。 資料のダウンロードは こちら ⽣成 AI 失敗してみた 東海テレビ放送株式会社 デジタルビジネス局&nbsp;コンテンツ事業部 プロデューサー ⽇髙 丈尚 氏 東海テレビ放送株式会社では、生成 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 等を用いたサービスの一括立ち上げを検討しています。 資料のダウンロードは こちら 動画の視聴は こちら 報道素材クラウドアーカイブシステムの構築 株式会社毎⽇放送 報道情報局 報道業務部⻑ 寺下 智&nbsp;氏 株式会社毎⽇放送 総合技術局 制作技術センター 部次長 伊藤 亮介&nbsp;氏 株式会社毎日放送は、保管するメディアの増加による本社ライブラリーの不足、茨木市の倉庫からの取り寄せに時間がかかること、テープメディアのリスク、メディアのマイグレーションの必要性などの従来の報道ライブラリーの課題を解決すべく、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 &amp; Entertainment Blog (日本語) AWS Media &amp; 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:::&lt;S3-BUCKET-NAME&gt;", "arn:aws:s3:::&lt;S3-BUCKET-NAME&gt;/*" ] } ] } SAP 用の AWS Glue 接続先の作成 SAP コネクタは、CUSTOM ( SAP BASIC 認証) と OAUTH の両方の認証方式をサポートしています。この例では、BASIC 認証で接続します。 AWS マネジメントコンソール で AWS Secrets Manager サービスを開いて、 ODataGlueSecret という名前のシークレットを作成します。AWS Secrets Manager の詳細には、次のコードを含める必要があります。 &lt;your SAP username&gt; の部分にあなたの SAP システムのユーザー名を、 &lt;your SAP username password&gt; の部分にそのパスワードを入力します。 { "basicAuthUsername": " &lt;your SAP username&gt; ", "basicAuthPassword": " &lt;your SAP username password&gt; ", "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 行目に次のコードを追加します。 &lt;key of MaterialMasterAttributes node&gt; &nbsp;と&nbsp; &lt;entityName for Material Attribute&gt; は、既存の生成されたスクリプトの # Script generated for node Material Master Attributes コードに値が入っているのでそこからコピーできます。適切な値に置き換えてください。 key = "&lt;key of MaterialMasterAttributes node&gt;" 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": "&lt;entityName for Material Attribute&gt;", "ENABLE_CDC": "true" } connector_options = state_manager.get_connector_options(key) options.update(connector_options) Material Master Attributes ノードに生成された既存のスクリプトの前に # を付け加えてコメントアウトし、次の置換スニペットを追加します。 &lt;key of MaterialMasterAttributes node&gt; = glueContext.create_dynamic_frame.from_options(connection_type="sapodata", connection_options=options, transformation_ctx="&lt;key of MaterialMasterAttributes node&gt;") ダイナミックフレームからデルタトークンを読み取って、ジョブのタグに保存するには、スクリプトの最後の行 job.commit() の前に次のコードスニペットを追加します。 state_manager.update_state(key, &lt;key of MaterialMasterAttributes node&gt;.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 年以上の業界経験を持っています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。