本稿は、2025 年 6 月 9 日に AWS Migration & Modernization Blog で公開された “ Announcing the public preview of Amazon Elastic VMware Service (Amazon EVS) ” を翻訳したものです。 2024 年の AWS re:Invent で Amazon Elastic VMware Service (Amazon EVS) を発表 した際、多くのお客様から、既存の VMware ツールやスキル、ライセンスへの投資を活かしつつ、AWS のスケーラビリティ、堅牢性、パフォーマンスを組み合わせる新しい方法について高い関心が寄せられました。この 6 か月間で、数多くのパートナーやお客様と協力し、サービスの機能強化に取り組んできました。そして本日、Amazon EVS のパブリックプレビューを通じて、より多くのお客様にサービスを提供できることを嬉しく思います。 VMware ユーザーへの長年のコミットメントを基盤に このパブリックプレビューは、AWS 上で VMware ベースのワークロードを実行できるようにするという、私たちの長年のコミットメントの延長線上にあります。これまで、数千もの企業が Broadcom の VMware Cloud on AWS マネージドサービスを利用し、オンプレミスデータセンターの拡張やクラウドベースのディザスタリカバリ、クラウド移行の加速を実現してきました。Amazon EVS では新しいケーパビリティとして、お客様の Amazon Virtual Private Cloud (Amazon VPC) 内で、VMware Cloud Foundation (VCF) をネイティブに実行できるようになっています。 Amazon EVS は プリミティブサービス 、すなわちオンプレミス同様にワークロードを実行したり、パートナーがマネージドサービスや移行サービスを構築するための基盤となるサービスと位置付けています。そのため AWS パートナーネットワーク (APN) コミュニティとも緊密に連携し、各社のサービスやテクノロジーソリューションを Amazon EVS と統合しています。パートナー各社が Amazon EVS 向けに提供内容の構築や検証に尽力していただいていることに感謝するとともに、今後さらなる情報をお届けできることを楽しみにしています。 パブリックプレビューによる提供範囲の拡大 パブリックプレビュー期間中は、以下 5 つのリージョンで Amazon EVS を用いて VMware ベースのワークロードを展開できます。 米国東部 (バージニア北部) 米国東部 (オハイオ) 米国西部 (オレゴン) アジアパシフィック (東京) 欧州 (フランクフルト) この期間中、お客様は VCF ライセンスのポータビリティ資格を利用し、本番環境以外のワークロードを Amazon EVS へ移行 することができます。一般提供 (GA) 時と同等の機能とユーザー体験を備えており、主な特徴は以下の通りです。 リプラットフォームやハイパーバイザーの変更なしでワークロードを移行可能 AWS コンソール上のステップバイステップのワークフローで環境をプロビジョニングおよび構成可能 AWS 上に完全な機能を持つ VCF 環境を自動デプロイ Amazon FSx for NetApp ONTAP などの外部ストレージを含む、使い慣れた VCF ツールや好みのストレージソリューションを活用し、仮想化スタックを最適化 パブリックプレビューおよび一般提供の開始時点で、VCF 5.2.1 および i4i.metal インスタンスをサポートしています。今後、対応する VCF バージョン、ライセンス、インスタンスタイプの拡張を予定しています。 Amazon EVS の利用を開始するには Amazon EVS にご興味がある場合は、AWS のアカウントチームと連携し、現行の VMware 環境とお客様の移行要件を確認して、最適な移行戦略を策定することをおすすめします。 機能や料金などの詳細は Amazon EVS のページ 、または AWS コンソールから Amazon EVS にアクセスしてご確認ください。 今後も、お客様にとって最も包括的で革新的なクラウドソリューションを提供し続けます。今後の情報にご期待ください。 Steven Jones EC2 Commercial Applications のゼネラルマネージャーとして、AWS 上での SAP、VMware、Red Hat OpenShift のプロダクト戦略、エンジニアリングの実行、カスタマーサクセスをリードしています。これらの事業領域は、エンタープライズが最も要求の厳しいワークロードをクラウド上で実行できるようにするものです。AWS で 13 年の経験を持ち、革新的なソリューションの提供、パフォーマンスのスケーリング、複数のセグメントや業界にわたる成長の推進において確かな実績があります。AWS を最もお客様中心のクラウドプラットフォーム、そしてビジネスクリティカルなワークロードを実行するための最適な場所にすることに情熱を注いでいます。AWS における SAP 技術戦略の推進役であり、ハイパースケールプラットフォーム上での SAP ワークロードの一般サポートや、大容量メモリ SAP HANA ワークロードを支えるクラウドネイティブなインフラストラクチャなど、業界初の取り組みを数多く市場に送り出してきました。また、VMware ビジネスも統括し、お客様が VMware ベースの環境をシームレスに AWS へ移行および拡張できるよう支援しています。創造的なアイデア、抽象化、システムパフォーマンスに関するスキルを活かし、お客様、パートナー、AWS に価値をもたらしています。 Andy Reedy EC2 Commercial Applications のプロダクトマネジメント シニアマネージャーとして、VMware、SAP、Red Hat OpenShift ワークロードに注力するチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェア分野で 25 年以上の経験を持ち、ビジネスクリティカルなアプリケーションの移行やモダナイズをお客様が実現できるよう支援することに情熱を注いでいます。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。

本ブログは、KDDIスマートドローン株式会社 PF事業部 PFシステム開発リーダー 山澤 開氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 新谷 が共同で執筆しました。 KDDIスマートドローン株式会社 （以下、KDDIスマートドローン）は、最先端のドローン技術を活用し、さまざまな産業分野におけるソリューションを提供する企業であり、通信技術とドローン技術を融合させることで、新しい価値を創造し、社会の発展に貢献することを目指しています。同社は AWS 上でドローンの運航に関わる運航管理システムや空域管理システムを構築していますが、同時にドローンの空撮映像に対する AI 解析により点検ソリューションの提供を行うなど、データ活用を通じた課題解決にも積極的に取り組んでいます。 本ブログでは KDDIスマートドローン の寄稿により、ドローンによる監視ソリューションにおいて Amazon SageMaker AI を活用して夜間監視業務の支援を行った事例をご紹介します。 課題と背景 近年、銅の価格が高騰しており、5 年前と比較し約 2 倍になっています。 これに伴い、関東地方を中心として太陽光発電施設での銅線ケーブルの盗難事件が多発しています。太陽光発電施設は広大な敷地で警備が難しいという点、また多くの施設が山の中にあり人目につきにくい場所にあるという点から、犯行グループに狙われやすい状況です。施設内には監視カメラや機械警備としての赤外線センサなどが設置されている場合もありますが、知能的な犯行には気づくこと自体が難しかったり、警備員などによる巡回警備は発電事業者のコスト面から対応することが難しい状況となっています。 そこで、KDDIスマートドローンは遠隔運航で広範囲をカバーできるドローンを活用した監視システムを開発し、これらの課題を解決することを目指しました。特に、夜間監視においては、サーマルカメラ搭載のドローンを用いることで、視認性の低い環境でも不審者を検知することが可能です。これにより、夜間巡回の警備に要する運用負担や人的コストの緩和と、監視業務の効率化が期待されます。 ソリューションの概要 KDDIスマートドローンは、AWS の先進的な技術を活用し、夜間のサーマルドローン映像から不審者を検知する AI 解析機能を開発しました。不審者検知の AI モデルは、KDDIグループである 株式会社ARISE analytics の協力により実現しています。 本ソリューションでは、映像のリアルタイム配信、写真映像管理、AI 解析などの機能を提供しています。 以下、ソリューション活用の流れを解説します。 飛行計画とイベントタイプの登録 まず、ドローンを遠隔運航させて定期的な監視や点検等を行いたいエリアにドローンポートを設置します。利用者が飛行計画を登録すると、ドローンは計画に沿って自律的にポートから発着陸を行います。現在、ある太陽光発電施設では、夜間に定期的な巡回飛行を行っています。夜間であっても、現地で人手による目視監視や操縦を必要としない遠隔運航は、業務の効率化や高度化の観点で大きなメリットです。また、イベントタイプを登録することで、リアルタイムに空撮画像を AI で解析し、人物検知などのユースケースに沿ったイベントの発生を利用者に通知することが可能です。 イベントタイプとスケジュールの登録画面 太陽光発電施設における銅線ケーブルの盗難防止に向けては、夜間の不審者検知イベントを通知可能な AI モデルを利用可能にしています。今後、ユースケースを拡充し、現場やドローン機体に合わせてイベントタイプを選択できるよう AI モデルも拡張していく予定です。 ドローン空撮画像のリアルタイム解析 ドローンの映像は、リアルタイムに Web アプリケーションに配信され、遠隔でモニタリングが可能です。Skydio や DJI のサーマルカメラ付きドローンにより夜間の太陽光発電施設であっても、映像をクリアに配信し、AI モデルによる不審者の検知と通知が可能です。 サーマルカメラ付きドローンによる夜間監視と不審者検知の様子 ドローン空撮映像/画像の管理 ドローンの飛行が終わると、空撮映像と画像は自動的に AWS 上に保存されます。利用者は、マップビューワーを照合しながら位置情報や日時とともに、見たい画像をすぐに確認することが可能です。保存された空撮画像に対しても、3 次元復元や生成 AI 連携などの高度な活用を今後検討しています。 マップビューワーによる空撮画像の確認 アーキテクチャ 本システムは Amazon SageMakaer AI をはじめとした AWS マネージドサービスをフル活用して開発しました。 不審者検知の AI 解析を実現しているアーキテクチャは以下の通りです。 アーキテクチャ 不審者検知のために YOLOX をベースにトレーニングした AI モデルは、SageMaker AI の リアルタイム推論 エンドポイントにデプロイします。ドローンがポートから離陸して自律飛行を開始すると、空撮画像は AWS クラウド上にリアルタイムでストリーミング配信されます。受信した映像は、 AWS Fargate のコンテナアプリケーションで OpenCV による画像処理を行い、静止画への切り出しを行なった上で、Amazon S3 に保存します。静止画の保存後に、AWS Fargate から、Amazon API Gateway と AWS Lamdbda で実装した API を実行し、SageMaker AI の推論エンドポイントにリクエストを送信します。推論の結果、人物が検知された場合はフロントエンド画面に対してイベントを通知します。 推論 API は、今後のユースケース拡大や外部公開を見据え、スケーラビリティの観点から Amazon API Gateway により実装しています。SageMaker AI のリアルタイム推論では、g5 インスタンスを使用しました。リアルタイム推論では、同時に飛行するドローンの機体が増えて推論リクエストが増加しても、負荷に応じてキャパシティをオートスケーリングできる点が利点です。今回のユースケースでは、夜間飛行がメインの利用となることから、日中帯のインスタンス数を削減しコストを最適化するために SageMaker AI の Scale Down to Zero 機能によりインスタンス数を 0 にする検証や、予約スケジュールに基づき推論エンドポイントを立ち上げる運用も検討しています。また、今後のリクエスト増によりエラーレートが高くなるなどの課題が発生してきた際は、SageMaker AI の 非同期推論 の導入も視野に入れています。 効果と今後の展望 本システムにより、太陽光発電施設の広範囲を効率的に監視できるようになり、監視業務のコスト削減と迅速な対応が可能になりました。ドローンポートから遠隔飛行で運航可能なドローンと、AI 解析を備えた監視システムを用いることで運航者が複数のドローン機体を運航することが可能となり、また目視による不審者の検知漏れを削減することが期待されます。 今後も、AI モデルによる異常検知の精度向上やユースケース拡大に向けてさらなる開発を進めていく予定です。今回開発した不審者検知の AI モデルの他にも様々なモデルを SageMaker AI の推論エンドポイントにホスティングすることで、利用シーンや場所に応じて適切な AI 解析機能の使い分けを実現することができます。例えば、不審車両の滞留検知や、リアルタイムな地上の人物検知をドローン運航の安全性に活かしていく活用方法なども考えられます。 KDDIスマートドローンは AWS の技術を活用することで、ドローンによる監視システムの可能性を広げ、持続可能な社会の実現に貢献してまいります。そして、AWS とのパートナーシップを通じて、今後も革新的なソリューションを提供していくことを目指していきます。 まとめ 本ブログでは、KDDIスマートドローン株式会社による、ドローンと AWS を活用した太陽光発電施設の監視ソリューションをご紹介しました。広大な太陽光発電施設の夜間警備という課題に対し、ポートから自律的に発着陸して遠隔飛行が可能なドローンで巡回監視を実現しています。ドローンの空撮映像と、SageMaker AI 等の AWS マネージドサービスを組み合わせることで、リアルタイムな不審者検知も可能にしました。本事例での AWS 活用が皆様のビジネスにおけるカメラ映像活用や AI 導入の検討に参考になれば幸いです。 著者 山澤 開 KDDIスマートドローン株式会社 PF事業部 PFシステム開発リーダー 新谷 歩生 アマゾンウェブサービスジャパン合同会社 技術統括本部 通信グループ シニアソリューションアーキテクト  

この記事は Scaling Rufus, the Amazon generative AI-powered conversational shopping assistant with over 80,000 AWS Inferentia and AWS Trainium chips, for Prime Day (記事公開日 : 2024 年 10 月 10 日) の翻訳です。翻訳は Annapurna Labs の常世が担当しました。 Amazon Rufus は、 生成AIを活用したショッピングアシスタント です。Amazon の商品情報やウェブ上の様々な情報を活用して回答を作成し、お客様のよりスマートなお買い物をサポートします。Rufus を使えば、Amazon の商品に精通した AI アシスタントと一緒にショッピングを楽しむことができます。また、ウェブ上の幅広い情報も組み合わせることで、より確かな商品選びができるようになります。 Amazon が世界中の幅広いお客様にサービスを提供するにあたり、Rufus には数十億のパラメータを持つ大規模言語モデル（LLM）を、低コストかつ低レイテンシーで処理できる安定性の高い推論基盤が必要でした。低レイテンシーにより、ユーザーは Rufus とスムーズにやり取りでき、1 秒以内に回答が表示され始めます。これを実現するために、Rufus チームは AWS の様々なサービスや、 AWS Trainium と AWS Inferentia といった専用 AI チップを活用しています。 Inferentia と Trainium は、AWS が開発した専用 AI チップで、深層学習ワークロードを高性能かつ低コストで実現します。これらのチップを活用することで、Rufus は顧客への低レイテンシーを維持しながら、他の検討していたソリューションと比べて コストを 約 4.5 分の 1 に抑えることができました。この記事では、AWS AI チップを使った Rufus の推論システムの導入について、そして年間で最も負荷の高いイベントの 1 つである Amazon Prime Day をどのように実現できたのかについて詳しく紹介します。 ソリューション概要 Rufus の基盤となっているのは、Amazon の商品カタログとウェブ全体の情報を学習した LLM です。LLM を実用化する際には、モデルの規模や精度、処理性能などのバランスを取る必要があり、これが大きな課題となっています。一般的に、モデルが大きいほど知識や推論の能力は向上しますが、必要な計算量も増え、レイテンシーも増加するため、コストが上昇してしまいます。Rufus は Amazon Prime Day のようなアクセスが集中する時期にも対応できるよう、デプロイとスケーリングを行う必要がありました。この規模でのサービス提供には、必要な性能の確保はもちろん、消費電力上昇による環境への影響やシステム運用のコストなども考慮しなければなりません。これらの課題を解決するため、Rufus は以下の AWS ソリューションを組み合わせて活用しました：Inferentia2 と Trainium、 Amazon Elastic Container Service （Amazon ECS）、 Application Load Balancer （ALB）です。また、Rufus チームは NVIDIA とも協力し、NVIDIA の Triton Inference Server（推論を効率化するために NVIDIA が開発したオープンソースの推論サーバー）を使って AWS チップを活用したソリューションを構築しました。 Rufus は、検索拡張生成（RAG : Retrieval Augmented Generation）システムを採用しており、お客様の質問に応じて Amazon の検索結果から商品情報などを取得し、より充実した回答を提供します。この仕組みにより、LLM は信頼性が高く、質の高い正確な回答を確実に生成できるようになっています。 Prime Day を万全の体制で迎えるため、Rufus チームは Inferentia2 と Trainium を活用し、複数の AWS リージョンをまたいだハイブリッドな推論システムを構築しました。複数のリージョンでシステムを展開することで、Rufus は2つの重要なメリットを得ることができました。1 つ目は、アクセスが集中する時期に備えた追加の処理能力の確保、2 つ目は、システム全体の安定性の向上です。 Rufus チームは Inferentia2 を搭載した Amazon EC2 Inf2 インスタンス（以下、Inf2 ）と Trainium を搭載した Amazon EC2 Trn1 インスタンス（以下、Trn1） という 2 種類のインスタンスタイプを利用しました。両者は同じ AWS Neuron SDK を使用しているため、どちらのインスタンスでも同じ Rufus モデルを動かすことができました。設定で調整が必要だったのは、テンソル並列度（Inf2 が 24、Trn1 が 32）だけでした。より高性能な Trn1 インスタンスを使用することで、Inf2 と比べてレイテンシーが 20% 削減され、スループットも向上しました。 次の図はソリューションアーキテクチャを示しています。 複数のリージョンをまたぐリアルタイムのトラフィックルーティングを実現するため、Rufus は革新的なトラフィックオーケストレーターを構築しました。 Amazon CloudWatch を使ったモニタリングを基盤とし、トラフィックパターンの変化に応じて 15 分以内にリージョン間のトラフィック配分を調整できるようにしました。このタイプのオーケストレーションにより、必要に応じて他のリージョンへリクエストを振り分けることが可能になりました。その際、最初のトークンまでにわずかなレイテンシーが生じることはありますが、Rufus のストリーミングアーキテクチャとリージョン間の高速な AWS ネットワークにより、エンドユーザーが体感するレイテンシーは最小限に抑えられています。 これらの取り組みにより、Rufus は 3 つのリージョンで 80,000 以上の Trainium と Inferentia2 チップまでスケールしました。その結果、Prime Day 中も顧客への初回応答までの P99 レイテンシーを 1 秒未満に保ちながら、1 分間に平均 300 万トークンを処理することができました。さらに、これらの専用チップの採用により、他の検討済みのソリューションと比べてワットあたりの性能が 54% 向上し、チームが目標としていた省エネルギー基準もクリアすることができました。 推論性能とホスト利用率の最適化 Rufus では Amazon ECS を使って推論システムを運用し、Inferentia2 と Trainium チップを搭載したインスタンスを管理しています。ECS がインフラストラクチャの管理を担当することで、Rufus チームは必要なコンテナと設定を ECSタスク として定義するだけで済むようになりました。各コンテナでは、Python バックエンドを持つ NVIDIA Triton Inference Server を採用し、Neuron SDK を利用して vLLM を実行しています。vLLM は、高スループットのために最適化されたメモリ効率の高い推論・サービングエンジンです。また、Neuron SDK の採用により、チームは簡単に AWS チップを利用でき、PyTorch Lightning をはじめとする様々なライブラリやフレームワークも使用できるようになりました。 Neuron SDK は、Trainium と Inferentia チップ向けに最適化された、深層学習推論および学習用の SDK で、使いやすい LLM 向け分散推論および分散学習ライブラリを提供し、様々な種類の Transformer ベースの LLM アーキテクチャに対応しています。レイテンシーを削減するため、Rufus は AWS Annapurna チームと協力して、INT8（重みのみ）量子化、vLLM を使用した連続バッチング (continuous batching)、Neuron コンパイラとランタイムでのリソース、計算、メモリ帯域幅の最適化など、さまざまな最適化を開発しました。これらの最適化は現在 Rufus の本番環境にデプロイされており、Neuron SDK 2.18 以降で利用可能です。 お客様が Rufus の応答をより早く見られるようにするため、チームは推論のストリーミングアーキテクチャを開発しました。LLM 推論では大量の計算処理とメモリを必要とするため、質問に対する完全な回答の生成には数秒かかることがあります。ストリーミングアーキテクチャを採用することで、Rufus は生成した内容をリアルタイムで返せるようになりました。この改善により、お客様は 1 秒以内に応答を見始めることができます。さらに、複数のサービスが gRPC 接続を通じて連携し、ストリーミング形式の応答をリアルタイムでスマートに統合・強化しています。 以下の図に示すように、Rufus の応答には画像とリンクが組み込まれており、お客様はそれらを使ってさらに詳しい情報を探ることができます。 スケールアップ 最高の顧客体験のために低レイテンシーを維持する必要がありますが、同時にハードウェアリソースを効率的に使用してサービスのスループットを向上させることも重要です。ハードウェアの稼働率を上げることで、高性能な機器が無駄にアイドル状態になることを防ぎ、コスト増加を抑えられます。システム全体のスループットを最適化するため、チームは個々のサーバーのスループットと、複数のサーバー間での負荷分散の効率の両方を改善しました。 LLM 推論の負荷分散は、以下の課題があるため複雑です。まず、1 台のホストで同時に処理できるリクエスト数に限りがあります。次に、1 つのリクエストの処理完了までにかかる時間（エンドツーエンドのレイテンシー）は、LLMの生成する応答の長さによって数秒単位で変動する可能性があります。 これらの課題に対処するため、チームは個々のサーバーのスループットと、負荷分散を使った複数サーバー全体でのスループットの両方を考慮して最適化を行いました。 チームは ALB の最小未処理リクエスト（LOR : least outstanding requests）ルーティングアルゴリズムを採用し、以前の基準と比べてスループットを 5 倍に向上させました。これにより、各サーバーは同時に多数のリクエストを受け取っても処理しきれなくなることなく、現在処理中のリクエストを適切に扱い、gRPC 接続を使って応答をストリーミング形式で返す十分な時間を確保できます。さらに Rufus は AWS と vLLM チームと協力し、Neuron SDK と NVIDIA Triton Inference Server を使用した vLLM 統合により、一台のサーバーでの同時実行性を改善しました。 図 1. ECS タスクは水平方向にスケールし、Triton Inference Server と 依存関係をホスティングします この統合により、Rufus は重要な最適化である継続的バッチング（continuous batching）を活用できるようになりました。継続的バッチングにより、1 台のホストのスループットを大幅に向上させることができます。また、継続的バッチングは静的バッチング（static batching）などの従来のバッチ処理技術とは異なる特長があります。たとえば、静的バッチングでは、最初のトークンが生成されるまでの時間（TTFT : time to first token）がバッチ内のリクエスト数に比例して長くなります。一方、継続的バッチングでは LLM 推論のプリフィルステージ (Prefill stage : 入力されたプロンプト全体を初期処理) を優先することで、同時実行されるリクエスト数が増えても TTFT を一定に保つことができます。この仕組みにより、Rufus は最初の応答を低レイテンシーで返せるようになり、快適な体験を提供しながら、1 台のホストのスループットも改善し、サービスのコストも抑制できるようになりました。 結論 この記事では、Rufus が Neuron SDK や Inferentia2、Trainium チップ、そして AWS の各種サービスを活用して、数十億のパラメータを持つ LLM を安定的にデプロイし、運用する方法をご紹介しました。Rufus は、生成 AI の技術進歩とお客様からのフィードバックを取り入れながら進化を続けています。皆様もぜひ Inferentia と Trainium をご活用ください。 Amazon の生成 AI 分野でのイノベーションについて、さらに詳しくは こちら をご覧ください。

生成 AI は、Amazon の Rufus や Amazon Seller Assistant などの AI チャットボットを含む様々なアプリケーションを通じて、ビジネス運営に革命をもたらしています。 一方で、最も影響力のある生成 AI アプリケーションの中には、バックグラウンドで自律的に動作するものもあり、これは企業が業務、データ処理、コンテンツ作成を大規模に変革するために不可欠な機能です。 これらの非会話型の実装は、多くの場合 大規模言語モデル (LLM) を活用したエージェント型ワークフローの形で、ユーザーとの直接的な対話なしに、業界を問わず特定のビジネス目標を実現します。 非会話型である場合、リアルタイムで応答する必要はなく、バッチ処理が可能、キャッシュも活用できるといった独自の利点がありますが、その自律的な性質により、リアルタイムのユーザーフィードバックと監視の恩恵を受ける会話型アプリケーションと比較して、より強力なガードレールと徹底的な品質保証が必要となります。 この投稿では、Amazon.com における生成 AI アプリケーションの 4 つの多様な事例を紹介します。 Amazon.com の商品リスト作成とカタログデータ品質の向上 – LLM が販売パートナーと Amazon.com の高品質なリストを大規模に作成するのにどのように役立っているかを紹介しています Amazon Pharmacy での処方箋処理 – 厳しい規制が課された環境での実装とエージェント型ワークフロー向けのタスク分解を紹介しています レビューハイライト – 大規模なバッチ処理、従来の 機械学習 (ML) との統合、小規模 LLM(SLM) の使用、そして大規模でのコスト効率の良いソリューションを解説しています Amazon Ads のクリエイティブ画像と動画生成 – クリエイティブな取り組みにおけるマルチモーダル生成 AI と責任ある AI のプラクティスを取り上げています 各事例では、技術的なアーキテクチャから運用上の考慮事項まで、非会話型の生成 AI アプリケーションを実装する際に必要なことをさまざまな観点で知ることができます。 これらの例を通じて、 Amazon Bedrock や Amazon SageMaker を含む 包括的な AWS サービスが成功の鍵であることを学ぶことができます。 最後に、これらのユースケース全体で共通している主要な学びを列挙します。 Amazon.com での高品質な商品リストの作成 包括的な詳細情報を含む高品質な商品リストを作成することで、お客様は十分な情報に基づいた購入決定を行うことができます。 従来、販売パートナー (Amazon で商品を出品し販売する事業者) は商品ごとに数十の属性を手動で入力していました。 2024 年に発表された新しい生成 AI ソリューションは、ブランドの Web サイトやその他のソースから積極的に商品情報を取得することで、このプロセスを変革し、数多くの商品カテゴリにわたって顧客体験を向上させます。 生成 AI は、URL、商品画像、スプレッドシートなどさまざまな形式での情報入力を可能にし、これを必要な構造とフォーマットに自動的に変換することで、販売パートナーの顧客体験を簡素化します。 90 万以上の販売パートナーがこの機能を利用しており、生成された出品原稿の約 80% が最小限の編集で受け入れられています。 AI が生成したコンテンツは、明確さと正確さに役立つ包括的な製品詳細を提供し、お客様の検索における商品の見つけやすさに貢献します。 新規出品の場合、ワークフローは販売パートナーが初期情報を提供することから始まります。 システムはその後、タイトル、説明、詳細な属性など、複数の情報源を使用して包括的な出品情報を生成します。 生成された出品情報は販売パートナーと共有され、承認または編集されます。 既存の商品の場合、システムは追加データで拡充できる製品を特定します。 多様な出力データのためのデータ統合と処理 Amazon チームは、Amazon Bedrock やその他の AWS サービスを使用して LLM フレンドリーな API を備えた内部および外部ソース向けの堅牢なコネクタを構築し、Amazon.com のバックエンドシステムにシームレスに統合しました。 主な課題は、テキストと数値の両方を含む 50 以上の属性にわたって、多様なデータを一貫性のあるリストに統合することです。 LLM は、このような複雑で多様なデータに対して最適なパフォーマンスを発揮できない可能性があるため、e コマースの概念を正確に解釈するための特定の制御メカニズムと指示が必要です。 例えば、LLM はナイフブロックの「容量」を収納できる数ではなく寸法として誤解したり、「Fit Wear」をブランド名ではなくスタイルの説明と勘違いしたりする可能性があります。 これらのケースに対処するために、プロンプトエンジニアリングとファインチューニングが広範囲に使用されました。 LLM による生成と検証 生成された商品リストは完全かつ正確である必要があります。これを実現するために、このソリューションでは属性の生成と検証の両方に LLM を使用するマルチステップのワークフローを実装しています。この二つの異なる LLM を組み合わせるアプローチは、特に安全上の危険性や技術仕様を扱う際に重要となるハルシネーションを防止するのに役立ちます。チームは、生成プロセスと検証プロセスが効果的に補完し合うことを確実にするための高度な self-reflection (自己検証) テクニックを開発しました。 次の図は、LLM によって実行される生成プロセスと検証の両方を示しています。 図 1. 商品リスト作成ワークフロー 人間のフィードバックによる多層的な品質保証 人間のフィードバックは、ソリューションの品質保証の中心となっています。このプロセスには、初期評価のための Amazon.com の専門家と、承認または編集のための販売パートナーの意見が含まれています。これにより、高品質な出力が提供され、AI モデルの継続的な改善が可能になります。 品質保証プロセスには、ML、アルゴリズム、または LLM ベースの評価を組み合わせた自動テスト方法が含まれています。 不合格となった出品情報は再生成され、合格した出品情報はさらなるテストに進みます。 因果推論モデル を使用して、出品情報のパフォーマンスに影響を与える根本的な特徴量セットと、改善の余地を特定します。 最終的に、品質チェックに合格し、販売パートナーの承認を得た出品情報が公開され、お客様が正確で包括的な製品情報を受け取れるようにしています。 次の図は、出品情報生成のテスト、評価、モニタリングを含む本番環境への移行ワークフローを示しています。 図 2. 出品情報作成のテストとヒューマンインザループのワークフロー 精度とコストのためのアプリケーションレベルのシステム最適化 高い精度と完全性の基準を満たすため、チームは自動最適化システムを備えた包括的な実験アプローチを採用しました。このシステムは、さまざまな LLM、プロンプト、プレイブック、ワークフロー、AI ツールの組み合わせを探索し、コストを含むビジネス指標の向上のために反復します。 継続的な評価と自動テストを通じて、商品情報生成ツールはパフォーマンス、コスト、効率性のバランスを効果的に取りながら、新しい AI の発展に適応し続けています。 このアプローチにより、お客様は高品質な商品情報の恩恵を受け、販売パートナーは効率的に商品情報を作成するための最先端ツールを利用できるようになります。 Amazon Pharmacy における生成 AI を活用した処方箋処理 前述の出品情報の例で説明した人間と AI のハイブリッドワークフローを基に、Amazon Pharmacy は、これらの原則が 医療保険の携行性と責任に関する法律 (HIPAA) で規制されている業界にどのように適用できるかを示しています。 Amazon Pharmacy が Amazon SageMaker を使用して LLM ベースのチャットボットを作成した方法を学ぶ という投稿で患者ケア専門家向けの会話型アシスタントを紹介しましたが、今回は自動処方箋処理に焦点を当てます。 詳細は Amazon Pharmacy における処方箋のライフサイクル と、以下の Nature 誌の研究論文 で読むことができます。 Amazon Pharmacy では、調剤技師が処方箋をより正確かつ効率的に処理できるよう支援するため、Amazon Bedrock と Amazon SageMaker (訳註: Amazon SageMaker AI は Amazon SageMaker に統合されています) を基盤とした AI システムを開発しました。 このソリューションは、患者への服薬指示の精度を高めるために、作成と検証の役割において人間の専門家と LLM を統合しています。 医療の精度向上のためのエージェント型ワークフロー設計 処方箋処理システムは、人間の専門知識 (データ入力技術者と薬剤師) と指示の提案やフィードバックを提供する AI サポートを組み合わせています。次の図に示すワークフローは、 Amazon DynamoDB の処方箋テキストを標準化する薬局の知識ベースを活用した前処理プロセッサーから始まり、その後 Amazon SageMaker 上のファインチューニングされた SLM が重要なコンポーネント (投与量、頻度) を特定します。 (a) (b) (c) 図 3. (a) 2 つの生成 AI モジュールを使用したデータ入力技術者と薬剤師のワークフロー、(b) 提案モジュールのワークフロー、(c) フラグ付けモジュールのワークフロー このシステムは、データ入力技術者や薬剤師などの専門家をシームレスに統合し、生成 AI が全体のワークフローを補完することで、俊敏性と正確性を向上させ、患者により良いサービスを提供します。安全性を確保した指示生成システムが、データ入力技術者向けに提案モジュールを通じて入力形式の指示を作成するためのガイダンスを生成します。フラグ付けモジュールはエラーにフラグを立てたり修正したりして、データ入力技術者へのフィードバックとしてさらなる安全対策を実施します。技術者は高精度で安全な入力指示を完成させ、薬剤師はそれに対してフィードバックを提供するか、下流サービスへの指示を実行することができます。 このソリューションの特筆すべき点の一つは、タスク分解の活用です。これにより、エンジニアやサイエンティストは全体のプロセスを、サブステップで構成された個々のモジュールを持つ多数のステップに分解することができます。チームはファインチューニングされた SLM を広範囲に使用しました。さらに、このプロセスでは 固有表現認識 (NER) や 回帰モデル による最終的な信頼度の推定など、従来の ML 手法も採用しています。このように明確に定義された手順において、SLM と従来の ML を使用することで、特定のステップに適切なガードレールが組み込まれるため、厳格な安全基準を維持しながら処理速度を大幅に向上させることができました。 このシステムは複数の明確に定義されたサブステップで構成されており、各サブプロセスは専門化されたコンポーネントとして、全体的な目標に向けてワークフロー内で半自律的かつ協調的に動作しています。 各段階で特定の検証を行うこの分解されたアプローチは、エンドツーエンドのソリューションよりも効果的であることが証明され、ファインチューニングされた SLM の使用を可能にしています。 チームは既存のバックエンドシステムへの統合を考慮し、 AWS Fargate を使用してワークフローをオーケストレーションしました。 製品開発の過程で、チームは Amazon Bedrock に目を向けました。Amazon Bedrock は、生成 AI アプリケーション向けに調整された使いやすい機能を備えた高性能な LLM を提供しています。SageMaker AI はさらに多様な LLM の選択肢、より深いカスタマイズ性、そして従来の ML 手法を可能にしました。この技術についてさらに詳しく知るには、 タスク分解と小規模 LLM が AI をより手頃にする方法 をご覧いただくか、 Amazon Pharmacy のビジネスケーススタディ をお読みください。 ガードレールと ヒューマンインザループ (HITL) による信頼性の高いアプリケーションの構築 HIPAA 標準に準拠し患者のプライバシーを保護するため、厳格なデータガバナンス慣行を実装するとともに、Amazon Bedrock API を使用したファインチューニングされた LLM と Retrieval Augmented Generation （ RAG ）を Amazon OpenSearch Service で組み合わせたハイブリッドアプローチを採用しました。 この組み合わせにより、特定のサブタスクに対して高い精度を維持しながら効率的な知識検索が可能になります。 医療において重要な LLM のハルシネーションを管理するには、大規模データセットでのファインチューニングだけでは不十分でした。私たちのソリューションでは、 Amazon Bedrock Guardrails を基盤とした領域固有のガードレールを実装し、システムの信頼性を高めるためにヒューマンインザループ (HITL) による監視を補完しています。 Amazon Pharmacy チームは、リアルタイムの薬剤師フィードバックと処方箋フォーマット機能の拡張を通じて、このシステムを継続的に強化しています。 イノベーション、ドメイン専門知識、高度な AI サービス、そして人間による監視という、このバランスの取れたアプローチは、運用効率を向上させるだけでなく、AI システムが医療専門家を適切に支援して最適な患者ケアを提供できることを可能にしています。 生成 AI を活用したカスタマーレビューのハイライト 前の例では、Amazon Pharmacy が処方箋処理のリアルタイムワークフローに LLM を統合する方法を紹介しましたが、次のユースケースでは、同様の手法（ SLM、従来の ML、綿密なワークフロー設計）を大規模での オフラインバッチ推論 にどのように適用できるかを示します。 Amazon は、年間 2 億件以上の製品レビューと評価を処理するために AI 生成のカスタマーレビューハイライト を導入しました。 この機能は、共有されたお客様の意見を簡潔な段落にまとめ、製品とその特徴に関するポジティブ、中立、ネガティブなフィードバックを強調します。 買い物客は、関連するカスタマーレビューへのアクセスを提供し、元のレビューを利用可能な状態に保つことで透明性を維持しながら、素早く全体的な評価を把握できます。 このシステムは、お客様が特定の機能（ Fire TV の画質、リモコン機能、設置のしやすさなど）を選択してレビューのハイライトを探索できるインターフェースを通じて、ショッピングの意思決定を強化します。機能は、肯定的な評価には緑色のチェックマーク、否定的な評価には橙色のマイナス記号、中立には灰色で視覚的にコード化されています。これにより、購入者は確認済みの購入レビューに基づいて製品の強みと弱みを素早く把握できます。 以下のスクリーンショットは、ある製品の騒音レベルに関するレビューのハイライトを示しています。 図 4. 製品のレビューハイライトの例 オフラインユースケースにおける LLM の費用対効果の高い使用法 チームは、従来の ML 手法と特化した SLM を組み合わせた費用対効果の高いハイブリッドアーキテクチャを開発しました。 このアプローチでは、感情分析とキーワード抽出を従来の ML に割り当て、複雑なテキスト生成タスクには最適化された SLM を使用することで、精度と処理効率の両方を向上させています。 次の図は、従来の ML と LLM が連携して全体的なワークフローを提供する様子を示しています。 図 5. ワークフローにおける従来の ML と LLM の使用 この機能は非同期処理のために SageMaker AI バッチ変換 を採用しており、リアルタイムエンドポイントと比較してコストを大幅に削減します。ほぼゼロの待ち時間を実現するために、このソリューションは既存のレビューと共に抽出されたインサイトを キャッシュ し、待ち時間を短縮し、追加の計算なしで複数のお客様が同時にアクセスできるようにします。このシステムは新しいレビューを段階的に処理し、完全なデータセットを再処理することなくインサイトを更新します。最適なパフォーマンスとコスト効率を実現するために、この機能はバッチ変換ジョブに Amazon Elastic Compute Cloud (Amazon EC2) Inf2 インスタンス を使用し、 代替手段と比較して最大 40% 優れた価格性能比を提供します 。 この包括的なアプローチに従うことで、チームはレビューと製品の膨大な規模を処理しながらコストを効果的に管理し、ソリューションが効率的でスケーラブルな状態を維持できるようにしました。 Amazon Ads の AI を活用したクリエイティブ画像と動画の生成 これまでの例では主にテキスト中心の生成 AI アプリケーションを探索してきましたが、ここでは Amazon Ads のスポンサー広告向けクリエイティブコンテンツ生成 によるマルチモーダル生成 AI に目を向けます。このソリューションには 画像 と 動画 の生成機能があり、その詳細をこのセクションで共有します。共通点として、このソリューションの中核には Amazon Nova クリエイティブコンテンツ生成モデルが使用されています。 お客様のニーズから逆算すると、2023 年 3 月の Amazon の調査では、キャンペーンの成功に苦戦している広告主の約 75% がクリエイティブコンテンツの生成を主な課題として挙げています。多くの広告主、特に社内リソースやエージェンシーのサポートがない広告主は、質の高いビジュアルを制作するための専門知識やコストにより大きな障壁に直面しています。Amazon Ads ソリューションは、ビジュアルコンテンツ作成を民主化し、さまざまな規模の広告主にとってアクセスしやすく効率的なものにしています。その影響は大きく、 Sponsored Brands キャンペーンで AI 生成画像を使用した広告主は、約 8% の クリック率 (CTR) を達成し、非利用者と比較して 88% 多くのキャンペーンを提出しています。 昨年、AWS Machine Learning ブログでは、 画像生成ソリューションの詳細 に関する投稿を公開しました。 それ以降、Amazon は Amazon Nova Canvas をクリエイティブな画像生成の基盤として採用し、テキストや画像プロンプトからプロフェッショナルグレードの画像を作成し、テキストベースの編集機能や配色とレイアウト調整のためのコントロール機能を提供しています。 2024 年 9 月、Amazon Ads チームは製品画像から ショートフォーム動画広告 を作成する機能を追加しました。この機能は、 Amazon Bedrock で利用可能な基盤モデル を使用して、自然言語を通じてビジュアルスタイル、ペース、カメラの動き、回転、ズームをコントロールする機能をお客様に提供します。エージェント型のワークフローを使用して、最初にビデオのストーリーボードを説明し、その後ストーリーのコンテンツを生成します。 以下のスクリーンショットは、Amazon Ads での製品背景のクリエイティブな画像生成の例を示しています。 図 6. 製品の広告画像生成例 元の投稿で説明したように、 責任ある AI はソリューションの中心であり、Amazon Nova クリエイティブモデルには、ウォーターマークやコンテンツモデレーションなど、安全で責任ある AI 利用をサポートするための組み込みコントロールが備わっています。 このソリューションでは、 AWS Step Functions と AWS Lambda 関数を使用して、画像と動画の生成プロセスをサーバーレスでオーケストレーションしています。 生成されたコンテンツは Amazon Simple Storage Service (Amazon S3) に保存され、メタデータは DynamoDB に格納されます。 また、 Amazon API Gateway がお客様に生成機能へのアクセスを提供します。 このソリューションでは、追加の安全性チェックのために様々なステップで Amazon Rekognition と Amazon Comprehend の統合を維持しながら、Amazon Bedrock Guardrails も採用しています。 以下のスクリーンショットは、Amazon Ads キャンペーンビルダーでの AI 生成動画の例を示しています。 図 7. 製品の広告動画生成 大規模な高品質広告クリエイティブの作成は複雑な課題を伴いました。生成 AI モデルは、多様な製品カテゴリーや広告コンテキスト全体で魅力的でブランドに適した画像を生成する必要がありましたが、同時に技術的な専門知識に関係なくすべての広告主がアクセスできる必要がありました。 品質保証と改善は、画像と動画の生成機能の両方において基本的な要素です。 このシステムは Amazon SageMaker Ground Truth によって実現された広範な ヒューマンインザループ (HITL) プロセスを通じて継続的に強化されています。 この実装により、広告主のクリエイティブプロセスを変革し、多様な製品カテゴリーやコンテキスト全体で高品質な視覚的コンテンツの作成をより簡単にする強力なツールが提供されています。 これは、Amazon Ads が生成 AI を活用して広告主が広告目標を達成するために必要なコンテンツを作成できるようにする取り組みの始まりに過ぎません。 このソリューションは、 クリエイティブ制作の障壁を減らすことで、責任ある AI 利用の高い基準を維持しながら、広告活動を直接的に増加させることを示しています。 主要な技術的学びと議論 非会話型アプリケーションは、処理の多少の遅延が許されるため、バッチ処理やキャッシングを可能にしますが、自律的な性質のため、堅牢な検証メカニズムとより強力なガードレールが必要です。これらの洞察は、非会話型と会話型の AI 実装の両方に適用されます： タスク分解とエージェントワークフロー – 複雑な問題をより小さなコンポーネントに分解することは、様々な実装において価値があることが証明されています。ドメインエキスパートによるこの意図的な分解により、Amazon Pharmacy の処方箋処理のように、特定のサブタスク向けに特化したモデルが可能になります。この例では、ファインチューニングされた SLM が投与量の識別などの個別タスクを処理します。この戦略により、明確な検証ステップを持つ特化したエージェントが実現し、信頼性が向上し、メンテナンスが簡素化されます。Amazon 商品リストのユースケースは、生成と検証プロセスを分離したマルチステップワークフローでこれを示しています。さらに、レビューハイライトのユースケースでは、前処理や LLM タスクに関連する部分に従来の ML を使用することで、コスト効率が良く制御された LLM の使用方法を示しています。 ハイブリッドアーキテクチャとモデル選択 – 従来の ML と LLM を組み合わせることで、純粋な LLM アプローチよりも優れた制御とコスト効率が得られます。従来の ML は、レビューハイライトシステムでの感情分析や情報抽出のような、明確に定義されたタスクに優れています。Amazon チームは要件に基づいて大小の言語モデルを戦略的に展開し、Amazon Pharmacy の実装のようなドメイン固有のアプリケーションに効果的な RAG とファインチューニングを統合しています。 コスト最適化戦略 – Amazon チームは、バッチ処理、大量操作のためのキャッシュメカニズム、 AWS Inferentia や AWS Trainium などの特殊なインスタンスタイプ、最適化されたモデル選択を通じて効率性を達成しました。レビューハイライトは、増分処理によって計算ニーズを削減する方法を示し、Amazon Ads は Amazon Nova 基盤モデル (FM) を使用してコスト効率よくクリエイティブコンテンツを作成しました。 品質保証と制御メカニズム – 品質管理は、Amazon Bedrock Guardrails を通じたドメイン固有のガードレールと、自動テストと人間による評価を組み合わせた多層検証に基づいています。生成と検証のための二つの異なる LLM を組み合わせるアプローチは、Amazon 商品リストでのハルシネーションを防ぎ、 self-reflection (自己検証) テクニックは精度を向上させます。Amazon Nova のクリエイティブ FM は本質的に責任ある AI 制御を提供し、継続的な A/B テストとパフォーマンス測定によって補完されています。 ヒューマンインザループ (HITL) 実装 – HITL アプローチは、薬剤師による専門家評価から販売パートナーによるエンドユーザーフィードバックまで、複数の層にわたります。Amazon チームは、特定のドメイン要件とリスクプロファイルに基づいて、自動化と人間の監視のバランスを取った構造化された改善ワークフローを確立しました。 責任ある AI とコンプライアンス – 責任ある AI の実践には、規制環境向けのコンテンツ取り込みガードレールと HIPAA などの規制の遵守が含まれます。Amazon チームは、ユーザー向けアプリケーションのコンテンツモデレーションを統合し、ソース情報へのアクセスを提供することでレビューハイライトの透明性を維持し、品質とコンプライアンスを促進するためのモニタリングを伴うデータガバナンスを実装しました。 これらのパターンは、品質と責任の基準を維持しながら、スケーラブルで信頼性が高く、コスト効率の良い生成 AI ソリューションを実現します。 これらの実装は、効果的なソリューションには高度なモデルだけでなく、AWS サービスと確立されたプラクティスによってサポートされるアーキテクチャ、運用、ガバナンスへの細心の注意が必要であることを示しています。 次のステップ この投稿で共有された Amazon.com の事例は、生成 AI が従来の会話型アシスタントを超えた価値をどのように創出できるかを示しています。これらの例に従うか、独自のソリューションを作成して、生成 AI があなたのビジネスや業界をどのように再創造できるかを発見することをお勧めします。アイデア創出プロセスを開始するには、 AWS 生成 AI ユースケースページ をご覧ください。 これらの事例は、効果的な生成 AI の実装では、異なるタイプのモデルとワークフローを組み合わせることが多くの場合有益であることを示しました。AWS サービスでサポートされている FM について学ぶには、 Amazon Bedrock でサポートされている基盤モデル と Amazon SageMaker JumpStart 基盤モデル を参照してください。また、ワークフロー構築への道を容易にする Amazon Bedrock Flows の探索もお勧めします。さらに、Trainium と Inferentia アクセラレーターがこれらのアプリケーションで重要なコスト削減をもたらすことも覚えておいてください。 事例で示したように、エージェント型ワークフローは特に価値があることが証明されています。エージェントを活用したワークフローを迅速に構築するには、 Amazon Bedrock Agents の検討をお勧めします。 成功する生成 AI の実装はモデル選択だけにとどまらず、実験からアプリケーションのモニタリングまでの包括的なソフトウェア開発プロセスを表しています。 これらの重要なサービス全体にわたる基盤構築を始めるために、 Amazon QuickStart をぜひご覧ください。 まとめ これらの例は、生成 AI が会話型アシスタントを超えて、業界全体でイノベーションと効率性を推進する方法を示しています。 成功は、AWS サービスと優れたエンジニアリング手法、そしてビジネスへの理解を組み合わせることから生まれます。 最終的に、効果的な生成 AI ソリューションは、高品質と責任ある基準を維持しながら、実際のビジネス課題の解決に焦点を当てています。 Amazon が AI をどのように活用しているかについて詳しく知るには、Amazon News の Artificial Intelligence を参照してください。 本ブログは「 Going beyond AI assistants: Examples from Amazon.com reinventing industries with generative AI 」 を翻訳したものです。翻訳は Solutions Architect 三好 雄登 が担当しました。 著者について Burak Gozluklu は、マサチューセッツ州ボストンを拠点とする AWS の Amazon.com のプリンシパル AI/ML スペシャリストソリューションアーキテクトおよびリード GenAI サイエンティストアーキテクトです。 彼は戦略的顧客が AWS テクノロジー、特に生成 AI ソリューションを採用してビジネス目標を達成するのを支援しています。 Burak は METU で航空宇宙工学の PhD を取得し、システム工学の MS、そしてマサチューセッツ州ケンブリッジの MIT でシステムダイナミクスのポストドクターを取得しています。 彼は MIT の研究員として学術界とのつながりを維持しています。 仕事以外では、Burak はヨガの愛好家です。 Emilio Maldonado は Amazon のシニアリーダーで、プロダクトナレッジを担当しています。e コマースカタログのメタデータを拡張するシステムの構築、すべての製品属性の整理、そして出品者と購入者が製品とやり取りするための正確な情報をするための生成 AI の活用に取り組んでいます。 彼はダイナミックなチーム開発とパートナーシップ構築に情熱を持っています。 モンテレイ工科大学 (ITESM) でコンピュータサイエンスの理学士号を、ペンシルベニア大学ウォートンスクールで MBA を取得しています。 Wenchao Tong は、カリフォルニア州パロアルトの Amazon Ads でシニアプリンシパルテクノロジストとして、クリエイティブ構築とパフォーマンス最適化のための GenAI アプリケーションの開発を先導しています。 彼の仕事は、革新的な AI テクノロジーを活用してクリエイティブのパフォーマンスと品質を向上させることで、お客様が製品とブランドの認知度を高め、売上を促進できるよう支援しています。 Wenchao は同済大学でコンピュータサイエンスの修士号を取得しています。 仕事以外では、ハイキング、ボードゲーム、家族との時間を楽しんでいます。 Alexandre Alves は Amazon Health Services のシニアプリンシパルエンジニアで、ML、最適化、分散システムを専門としています。健康を重視した医療体験の提供を支援しています。 Puneet Sahni は Amazon のシニアプリンシパルエンジニアです。Amazon カタログで利用可能なすべての製品のデータ品質向上に取り組んでいます。製品データを活用してカスタマーエクスペリエンスを向上させることに情熱を注いでいます。インド工科大学 (IIT) ボンベイ校で電気工学の修士号を取得しています。仕事以外では、幼い子供たちと過ごしたり旅行したりすることを楽しんでいます。 Vaughn Schermerhorn は Amazon のディレクターで、ショッピングの発見と評価部門を率いています。この部門はカスタマーレビュー、コンテンツモデレーション、Amazon のグローバルマーケットプレイス全体のサイトナビゲーションを担当しています。 彼は、スケーラブルな ML モデル、マルチモーダル情報検索、リアルタイムシステムアーキテクチャを通じて信頼性の高い顧客インサイトを提供することに焦点を当てた、応用科学者、エンジニア、プロダクトリーダーからなる学際的な組織を管理しています。 彼のチームは、毎日数十億のショッピング決定を支える大規模な分散システムを開発・運用しています。Vaughn は Georgetown University と San Diego State University の学位を持ち、米国、ドイツ、アルゼンチンで生活と仕事をしてきました。仕事以外では、読書、旅行、家族との時間を楽しんでいます。 Tarik Arici は Amazon Selection and Catalog Systems (ASCS) のプリンシパル応用科学者で、GenAI ワークフローを使用したカタログ品質向上に取り組んでいます。 ジョージア工科大学で電気・コンピュータ工学の PhD を取得しています。 仕事以外では、水泳とサイクリングを楽しんでいます。

この記事は Accelerating application development with the Amazon EKS MCP server (記事公開日: 2025 年 5 月 29 日) を翻訳したものです。 はじめに 本日、 Amazon Elastic Kubernetes Service (Amazon EKS) 向けのオープンソース Model Context Protocol (MCP) サーバーの提供開始を発表できることを嬉しく思います。この新機能により、 Amazon Q Developer CLI 、 Cline 、 Cursor などの AI コーディングアシスタントが標準化された方法で EKS クラスターとシームレスに連携できるようになります。Amazon EKS MCP Server は AI アシスタントにコンテキストデータを提供し、EKS および Kubernetes リソースを管理できるようにします。その結果、開発者は開発ライフサイクル全体を通じてカスタマイズされたガイダンスを受け取り、アプリケーション開発プロセスを効率化して加速することができます。 大規模言語モデル (LLM) は開発者のコード作成方法に革命をもたらし、Model Context Protocol (MCP) サーバーのような革新的なソリューションによってその機能がさらに強化されています。LLM はトレーニングデータに基づいた一般的なコーディング支援を提供することに優れていますが、MCP サーバーは外部ツールやデータソースへのリアルタイムアクセスを可能にすることでその機能を拡張します。これは Kubernetes のような複雑な環境で特に価値があります。オープンスタンダードとして、MCP は LLM が最新のコンテキスト情報を活用できる標準化されたインターフェースを作成し、特定のアプリケーション開発ユースケースをサポートする上でさらに強力で正確なものにします。LLM と MCP のこの相乗効果は、AI 支援の開発における重要な進歩を表しています。 Amazon EKS MCP Server は AI コードアシスタントに Amazon EKS クラスターに関するリソース管理ツールと最新のコンテキスト情報を提供します。これにより、コードアシスタントは初期セットアップから本番環境の最適化やトラブルシューティングまで、アプリケーションライフサイクル全体を通じてより正確でカスタマイズされたガイダンスを提供できます。Amazon EKS MCP Server を開発ワークフローに統合することで、アプリケーション開発のさまざまな段階で大幅な強化が得られます。開始フェーズでは、必要な前提条件がすべて自動的に作成され、ベストプラクティスが適用されたガイド付きクラスター作成を提供します。開発フェーズでは、アプリケーションのデプロイとクラスター管理のための高レベルワークフローを提供し、EKS を意識したコードとマニフェストを生成することで、EKS と Kubernetes の学習曲線を緩やかにします。デバッグとトラブルシューティングでは、Amazon EKS MCP Server はトラブルシューティング支援とナレッジベースへのアクセスを提供することで、問題解決を加速します。これらの機能は現在、AI コードアシスタント内での自然言語によるやり取りを通じてアクセスでき、開発者が EKS とやり取りする方法を変革し、複雑な Kubernetes 操作をより直感的かつ効率的にします。 機能 Amazon EKS MCP Server はいくつかの MCP ツールを提供しており、それぞれが AI アシスタントによって呼び出されて API やナレッジベースなどの外部システムとやり取りすることができます。 Amazon EKS MCP Server が提供するツールは、次の 3 つのカテゴリに分類できます。 1) Kubernetes リソース管理: Kubernetes コマンドに依存せずに EKS クラスター内の Kubernetes リソースを操作および管理します。これらのツールには EKS クラスターのシームレスな認証が含まれており、kubeconfig ファイルを管理する必要なく複数のクラスターにわたって効率的な操作が可能です。 list_k8s_resources – 特定の種類の Kubernetes リソースを一覧表示 list_api_versions – 利用可能なすべての Kubernetes API バージョンを一覧表示 manage_k8s_resource – 個々の Kubernetes リソースの作成、更新、または削除 apply_yaml – YAML オブジェクトの適用 get_k8s_events – 特定の Kubernetes リソースに関連するイベントの取得 get_pod_logs – 特定の Pod のログを取得 2) EKS クラスター管理: AWS CloudFormation を通じて EKS Auto Mode を活用した EKS クラスターを便利に作成および管理します。 manage_eks_stacks – EKS クラスター用の CloudFormation スタックの生成、デプロイ、削除 3) トラブルシューティング: ログやメトリクスなどの包括的なテレメトリデータを提供することで、問題解決を効率化します。リアルタイムのクラスターインサイトと一般的な障害シナリオに対する厳選されたトラブルシューティングプレイブックを組み合わせることで LLM の機能を強化し、より迅速かつ正確な問題の診断と解決を可能にします。 search_eks_troubleshoot_guide – トラブルシューティング情報について Amazon EKS ナレッジベースを検索 get_cloudwatch_logs – Pod または EKS クラスターコントロールプレーンのログを Amazon CloudWatch から取得 get_cloudwatch_metrics – コンテナ、Pod、ノード、またはクラスターの CloudWatch メトリクスを取得 その他のツールも含まれています。詳細については、 ドキュメント をご確認ください。 ウォークスルー Amazon EKS MCP Server の機能を実証するために、以下のセクションでは例となるシナリオを紹介します。 ワークロードのデプロイ このセクションでは、Amazon EKS MCP Server が Amazon EKS でのワークロードの実行をどのように加速できるかを示します。ここでは、新しいアプリケーションを作成し、Amazon EKS にデプロイする準備ができたコンテナとしてパッケージ化します。これにはコーディングが含まれるため、VS Code 用の自律型エージェントである Cline を使用できます。 IAM 権限を含む前提条件をインストールするには、 こちら の Amazon EKS MCP Server のドキュメントに従ってください。Cline で Amazon EKS MCP Server を使用するための設定は、 こちら の Cline のドキュメントに従ってください。 cline_mcp_settings.json ファイルは次の例のようになります。 インストールが成功すると、次の図に示すように、Cline にインストールされた MCP サーバーのリストに Amazon EKS MCP Server が確認できるはずです。 図 1: Cline での Amazon EKS MCP Server の設定 図 2: Cline に MCP が正常にインストールされた状態 Amazon EKS にデプロイするアプリケーションが必要です。そのために、Cline と設定されている LLM モデルを用います。まだ Amazon EKS MCP Server に頼る必要はありません。新しい Cline タスクに次のプロンプトを入力します。 Express を使用して API を提供する Node.js アプリケーションで現在のディレクトリをブートストラップ してください。アプリケーションは「Welcome to the Amazon EKS MCP server」というテキストで応答 する単一のパス「/demo」を提供する必要があります。また、アプリケーションのヘルスチェックに使用される 「/health」というヘルスエンドポイントも提供する必要があります。 このアプリケーションをコンテナとしてパッケージ化するために使用できる Dockerfile を作成してください。 現在の長期サポートバージョンである Node.js バージョン 22 を使用してください。ファイルが作成された後、 「docker build」を使用してコンテナイメージをビルドし、「eks-mcp-demo」というタグを付けてください。 コンテナがビルドされたら、「docker run」で実行し、エンドポイントをテストしてください。コンテナは x86_64 と ARM64 の両方をサポートするマルチアーキテクチャイメージとしてビルドされていることを 確認してください。 このイメージを AWS アカウントの「eks-mcp-demo」という名前の Amazon ECR リポジトリにプッシュして ください。完了したら、イメージ URL を提供してください。 このプロンプトを分解すると、 人気のある Express フレームワークを使用する Node.js アプリケーションを構築するよう、アシスタントに依頼しています。アクセスできるいくつかのスターターエンドポイントが必要です。 Dockerfile が必要なので、アシスタントに作成を依頼します。 次に、コンテナイメージをビルドするようアシスタントに依頼し、複数の CPU アーキテクチャ用にビルドされていることを確認します。また、基本的な機能が正しいことを確認するために、イメージをローカルで迅速にテストします。 最後に、Amazon EKS にデプロイできるように、コンテナイメージを Amazon Elastic Container Registry (Amazon ECR) にプッシュするようアシスタントに依頼します。 作成されたアプリケーションリポジトリは次のようになります。 図 3: 生成されたアプリケーションのファイル構造 コンテナイメージがビルドされ、Amazon ECR にプッシュされ、次の図のように出力されます。 図 4: Cline でのアプリケーションブートストラップタスクの完了 次に、アシスタントにアプリケーションを Amazon EKS にデプロイするよう依頼します。 このアプリケーションを Amazon EKS にデプロイしてください。アプリケーション用に新しいクラスターを 作成してください。パブリックインターネット経由でアプリケーションをテストしたいと思います。 内部的には、コードアシスタントは次の図に示すように、Amazon EKS MCP Server の manage_eks_stacks ツールを使用してクラスターのプロビジョニングプロセス全体を自動化します。ユーザーからの入力は一切必要なく、VPC、サブネット、 AWS Identity and Access Management ロールなど、クラスター構築に必要な前提条件をすべて自動的に作成します。Amazon EKS MCP Server のツールはインフラストラクチャのセットアップを効率化するだけでなく、合理化されたクラスター管理のための EKS Auto Mode の有効化など、Amazon EKS の推奨事項をクラスターに自動的に適用します。 図 5: Cline が Amazon EKS MCP Server のスタック管理ツールを呼び出す様子 クラスターの作成には数分かかります。その後、アシスタントは次の図に示すように、Amazon EKS MCP Server の apply_yaml ツールを使用して Kubernetes マニフェストを生成してデプロイします。 図 6: Cline が YAML マニフェストを適用するために Amazon EKS MCP Server のツールを呼び出す様子 マニフェストがデプロイされると、アシスタントは次の図に示すように、Amazon EKS MCP Server の list_k8s_resources や manage_k8s_resources などのツールを使用して Pod のステータスを確認できます。 図 7: Cline が Kubernetes リソースを一覧表示するために Amazon EKS MCP Server のツールを呼び出す様子 最後に、アシスタントはアプリケーションの URL を取得して、デプロイされて実行されていることを確認します。次に図を示します。 図 8: Cline がアプリケーションを Amazon EKS に正常にデプロイした様子 このウォークスルーでは docker を使用しましたが、ユーザーの多様なコンテナ管理ニーズをサポートするために Finch MCP Server も開発しました。Finch はコンテナ操作に対して安全で標準化されたアプローチを提供し、堅牢なセキュリティコントロールを維持しながら AWS サービスとシームレスに統合します。これは、さまざまなユーザー要件を満たす柔軟でエンタープライズグレードのソリューションを提供するという私たちのコミットメントを反映しています。 トラブルシューティング Amazon EKS MCP Server が AI アシスタントに価値あるコンテキストを提供できるもう一つの領域は、問題の特定と修正です。MCP サーバーの移植性を実証するために、ツールとプロンプトのための MCP サーバーをサポートする Amazon Q Developer CLI の使用に切り替えます。 Amazon Q Developer CLI をインストール した後、 mcp.json ファイルを 設定 することで Amazon EKS MCP Server を追加できます。 { "mcpServers": { "awslabs.eks-mcp-server": { "command": "uvx", "args": [ "awslabs.eks-mcp-server", "--allow-write", "--allow-sensitive-data-access" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR" }, "autoApprove": [], "disabled": false } } } CLI が読み込まれると、 /tools コマンドを使用して追加されたツールを確認できます。 awslabseks_mcp_server (MCP): - awslabseks_mcp_server___add_inline_policy * not trusted - awslabseks_mcp_server___apply_yaml * not trusted - awslabseks_mcp_server___generate_app_manifest * not trusted - awslabseks_mcp_server___get_cloudwatch_logs * not trusted - awslabseks_mcp_server___get_cloudwatch_metrics * not trusted - awslabseks_mcp_server___get_k8s_events * not trusted - awslabseks_mcp_server___get_pod_logs * not trusted - awslabseks_mcp_server___get_policies_for_role * not trusted - awslabseks_mcp_server___list_api_versions * not trusted - awslabseks_mcp_server___list_k8s_resources * not trusted - awslabseks_mcp_server___manage_eks_stacks * not trusted - awslabseks_mcp_server___manage_k8s_resource * not trusted - awslabseks_mcp_server___search_eks_troubleshoot_guide * not trusted ここで、Amazon EKS MCP Server が AI アシスタントをサポートできる 2 つのシナリオを見てみましょう。 Pod のトラブルシューティング この状況では、起動に失敗している 2 つの Pod があります。 NAMESPACE NAME READY STATUS RESTARTS AGE default nginx-deployment-6ccc9899c-nhbrf 0/1 ImagePullBackOff 0 17s default nginx-deployment-6ccc9899c-wq5ls 0/1 ImagePullBackOff 0 17s AI アシスタントにトラブルシューティングを依頼し、問題を直接修正してみるよう依頼します。 nginx-deployment Deployment の Pod が起動していません。問題を診断して修正してください。 マニフェストではなく直接修正を適用してください。デプロイメントが正常になったら、特定された問題と 適用された修正の簡単な要約を提供してください。 アシスタントはこのタスクのいくつかの部分に Amazon EKS MCP Server を使用できます。例えば、次の図に示すように、Amazon EKS MCP Server の get_pod_logs と get_k8s_events を使用してログとイベントを取得することができます。 図 9: Amazon Q Developer CLI が Kubernetes イベントを取得するために Amazon EKS MCP Server のツールを呼び出す様子 次の図に示すように、Amazon EKS MCP Server の manage_k8s_resources を使用して Deployment リソースを更新することで、問題を直接修正できます。 図 10: Amazon Q Developer CLI が Kubernetes リソースを更新するために Amazon EKS MCP Server のツールを呼び出す様子 最後に、次の図に示すように、特定され修正された複数の問題の要約が得られます。 図 11: Amazon Q Developer CLI がトラブルシューティングの問題と修正を要約する様子 インフラストラクチャのトラブルシューティング ユーザーが Amazon EKS 環境のトラブルシューティングを行う場合、Kubernetes リソースだけでなく、クラスターの作成に使用される AWS リソース、および VPC ネットワークや IAM などの関連リソースも考慮する必要があります。 この例では、前のシナリオと同様の状況から始マリますが、この場合、Pod は Pending 状態であり、EKS ワーカーノードにスケジュールできないことを示しています。 NAMESPACE NAME READY STATUS RESTARTS AGE default nginx-deployment-5559f849f6-ccg6l 0/1 Pending 0 4m default nginx-deployment-5559f849f6-w9bs6 0/1 Pending 0 4m AI アシスタントに問題の解決を手伝ってもらうよう依頼できます。 EKSクラスタを eks-cluster-template.yaml ファイルから作りました。 そのクラスタに配置した Deployment の nginx-deployment から作成される Pod が起動していません。 エラーの内容を確認して、問題を診断し、修正方法を提案してください。 アシスタントは問題の診断を開始するために、前のシナリオと同様のアクションを取る可能性が高く、Deployment と Pod のステータスを確認し、Kubernetes イベントを取得します。ただし、この場合、次の図に示すように、Amazon EKS MCP Server の search_eks_troubleshoot_guide ナレッジベースツールを使用して、Amazon EKS に関連する専門的なトラブルシューティング知識を得ることもできます。 図 12: Amazon Q Developer CLI が Amazon EKS ナレッジベースを検索するために Amazon EKS MCP Server のツールを呼び出す様子 Amazon EKS トラブルシューティングツールは、アシスタントのクエリに関連した的確なアドバイスと、さらなる調査に使用できる関連リファレンスドキュメントを提供します。例えば、 { "answer": "This can occur if the compute configuration associated with the EKS Auto Mode cluster does not include either a general purpose or system node group, or if required IAM permissions for Auto Mode have been deleted from the associated role, or if the trust policy for the role is incorrect.", "symptoms": [ "Pod remains in 'Pending' state for an extended period", "kubectl describe pod shows '0/0 nodes are available' or similar scheduling errors", "No nodes are listed in 'kubectl get nodes' output for the EKS Auto Mode cluster", "Events indicate scheduling failures due to lack of available nodes" ], "references": [ "https://docs.aws.amazon.com/eks/latest/userguide/auto-cluster-iam-role.html" ] } このドキュメントは、アシスタントが問題と解決策を特定するために必要なコンテキストを提供します。この場合、次の図に示すように、EKS クラスターに権限を提供するために使用される IAM ロールの問題を正しく特定できました。 図 13: Amazon Q Developer CLI が特定された問題と修正手順を要約する様子 結論 Amazon EKS 向けのオープンソース MCP サーバーは、ユーザーに Kubernetes 環境とやり取りするエキサイティングな新しい方法を提供します。 この MCP サーバーにより、次のことが可能になります。 AI 支援のガイダンスによる Kubernetes リソースのデプロイと管理 会話型 AI を使用した EKS クラスターの問題のトラブルシューティング 組織がコンテナ化されたアーキテクチャを採用し続けるにつれて、管理を効率化し認知負荷を軽減するツールがますます価値を持つようになります。Amazon EKS MCP Server は、Amazon EKS ユーザーが期待するパワーと柔軟性を維持しながら、Kubernetes をよりアクセスしやすくするという私たちのコミットメントを示しています。 AWS では、ロードマップはお客様のフィードバックに大きく影響されています。新機能の提案、課題の報告、または AI 支援がより効果的になる可能性のあるワークフローの強調など、どのようなものでも構いませんので、Amazon EKS MCP Server へのフィードバックをお寄せください。日々の開発パターン、問題点、強化された自動化やガイダンスが必要な領域に関するお客様の洞察は、このツールの将来の機能を形作る上でとても貴重です。 AWSLabs MCP Servers Github リポジトリ で新しい Issue を作成することで、フィードバックを提供できます。 Amazon EKS MCP Server のドキュメント に今すぐアクセスして、AI 支援による Kubernetes 管理の未来を私たちと共に形作りましょう。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本記事は 2025 年 5 月 29 日に AWS Machine Learning Blog で公開された Text-to-image basics with Amazon Nova Canvas を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 ブログ翻訳時点（2025 年 6 月）では、Amazon Nova Canvas は英語のみをサポートしており、プロンプトは英語で記載する必要があります。本記事では理解の助けになるよう、英文プロンプトに和訳を併記しています。 AI による画像生成は、近年最も革新的な技術の一つとして注目を集め、ビジュアルコンテンツの作成や活用方法を大きく変えています。Amazon Nova Canvas は、 Amazon Nova クリエイティブコンテンツ生成モデル の一つで、簡単なテキスト入力から、リアルで創造性に富んだ画像を生成することができます。 この記事は、Amazon Nova Canvas の使い方を学ぶ初心者向けガイドです。まず、 Amazon Bedrock のセットアップ手順を説明します。Amazon Bedrock は、テキスト、コード、画像生成、要約、質問応答などのさまざまなユースケース向けに業界をリードする最新の基盤モデル (FM) を提供するフルマネージドサービスです。また、ファインチューニングや検索拡張生成 (RAG) を含むカスタムユースケースにも対応しています。この記事では、米国の AWS リージョンで利用可能な Amazon Nova 画像生成モデルである Amazon Nova Canvas モデルを紹介します。具体的には、拡散モデル (diffusion-based model) による画像生成プロセスの概要と、Amazon Nova Canvas を使用したテキストからの画像生成に必要な入力パラメータについて詳しく解説します。 Amazon Bedrock で画像生成をはじめよう Amazon Nova Canvas と Image playground にアクセスできるようにするには、以下の手順を完了させてください： AWS アカウント をお持ちでない場合は、新規作成してください。 AWS Identity and Access Management (IAM) 管理者または適切な IAM ユーザーとして、Amazon Bedrock コンソールを開きます。 Amazon Nova Canvas モデルが利用可能な リージョン のいずれか ( 例：米国 ( バージニア北部 )) を選択します。 ナビゲーションペインで、 Bedrock configurations の下にある Model access ( モデルアクセス ) を選択します。 What is Model access ( モデルアクセスとは ?) の下で、 Modify model access ( モデルアクセスを変更 ) または まだ有効化されていない場合は、 Enable specific models ( 特定のモデルを有効にする ) を選択します。 Nova Canvas を選択し、 Next ( 次へ ) をクリックします。 Review and submit ( 確認して送信 ) ページで、 Submit ( 送信 ) を選択します。 Base models ( ベースモデル ) を更新します。 Amazon Nova Canvas モデルが Access Granted ( アクセスが付与されました ) のステータスで表示されていれば、次の手順に進む準備ができています。 ナビゲーションペインで、Playgrounds ( プレイグラウンド ) の下にある Image / Video を選択します。 Select model ( モデルを選択 ) を選び、 Amazon と Nova Canvas を選択します。その後、 Apply ( 適用 ) を選択します。 これで、Amazon Bedrock で Amazon Nova Canvas を使用して画像生成を始める準備が整いました。以下のスクリーンショットは、プレイグラウンドの例を示しています。 画像生成のプロセスを理解しよう Amazon Nova Canvas は画像生成に 拡散モデル (diffusion-based model) を使用しています： 初期状態 – 画像生成プロセスはランダムな値からなるノイズ画像 ( 完全なノイズ画像 ) から始まります。 反復的なノイズ除去 – モデルは、ユーザーが入力したプロンプトを参考にしながら、段階的にノイズを除去していきます。各ステップでどのくらいノイズを除去すべきかは、事前のトレーニングで学習された知識に基づいています。例えば、モデルが猫の画像を生成するためには、複数の猫の画像でトレーニングされ、それらの画像に徐々にノイズを挿入して完全なノイズ状態にする過程を学習します。各ステップで追加するノイズの量を学習することで、モデルは逆のプロセスを実行できるようになり、ノイズの多い画像から始めて徐々にノイズを取り除き、猫の画像を作り出します。 テキストによる条件付け – テキストプロンプトは、どのような画像を生成するかの方向づけの役割を担います。プロンプトは数値ベクトルとしてエンコードされ、学習済みのテキスト-画像の 埋め込み空間 との類似ベクトルと照合されます。これらのベクトルを使用して、ノイズの多い画像から徐々に入力プロンプトの内容を表現する画像へと変換させていきます。 画像による条件付け – Amazon Nova Canvas はテキストプロンプトの入力だけでなく、画像の入力にも対応しています。 安全性と公平性 – ユーザーが入力したプロンプトと、モデルが生成した画像の両方が安全性と公平性の基準を満たしているかを確認するためのフィルター処理が行われます。どちらも問題がないと判断された場合にのみ、最終的な画像がユーザーに提供されます。 プロンプト作成の基本 画像生成を成功させるには、まず効果的なプロンプト作成が重要です。プロンプト作成とは、求める画像をモデルに生成してもらうための的確な言葉選びの技術です。優れたプロンプトには、被写体に関する具体的な特徴、スタイル、照明、視点、雰囲気、構図の要素が含まれています。また、命令文や会話調ではなく、画像の説明文として構成すると効果的です。例えば、“generate an image of a mountain（ 山の画像を生成して )” と言うよりも、より効果的なプロンプトは “a majestic snow-capped mountain peak at sunset with dramatic lighting and wispy clouds, photorealistic style ( 夕暮れ時の雄大な雪をかぶった山頂、ドラマチックな照明と薄い雲がある写実的なスタイルの画像 )” のようになります。プロンプト作成についてさらに詳しく知りたい場合は、 Amazon Nova Canvas prompting best practices を参照してください。 以下のプロンプト要素について、それぞれが最終的な出力画像にどのような影響を与えるのか見てみましょう： 被写体の説明 ( 画像に何 / 誰が映っているか ) – この例で使用しているプロンプトは “a cat sitting on a chair ( 椅子に座る猫 )” です。 スタイル参照 ( 写真、油絵、3D レンダー ) – この例で使用しているプロンプトは、”A cat sitting on a chair, oil painting style ( 椅子に座る猫、油絵スタイル )” と “A cat sitting on a chair, anime style ( 椅子に座る猫、アニメスタイル )” です。 構図要素と技術的仕様 ( 前景、背景、視点、照明 ) – この例で使用しているプロンプトは “A cat sitting on a chair, mountains in the background ( 椅子に座る猫、背景に山々 )” と “A cat sitting on a chair, sunlight from the right low angle shot ( 椅子に座る猫、右側から差し込む日光の低アングル撮影 )” です。 負のプロンプト ( ネガティブプロンプト ) メインプロンプトは、モデルに含めるべき要素を指示します。これらは、最終的な画像に表現したい要素、スタイル、特徴です。プロンプトの中で “no”, “not”, “without” などの否定語の使用は避けてください。Amazon Nova Canvas は画像とキャプションのペアでトレーニングされていますが、キャプションは通常、画像に存在しないものについては記述しません。そのため、モデルは否定の概念を学習していません。代わりに、出力から除外したい要素を指定するために負のプロンプトを使用してください。 負のプロンプトは画像に含めたくない要素を指定します。一般的な負のプロンプトには “blurry ( ぼやけた )”, “distorted ( 歪んだ )”, “low quality ( 低品質 )”, “poor anatomy (不自然な体の構造)”, “bad proportions ( 不均衡な比率 )”, “disfigured hands ( 変形した手 )”, “extra limbs ( 余分な手足 )” などがあり、これらはモデルが画像生成時によく起きる問題を防ぐのに役立ちます。 以下の例では、最初の例では “An aerial view of an archipelago (群島の空中写真)” というプロンプトを使用し、次の例では、メインプロンプトを “An aerial view of an archipelago ( 群島の空中写真 )”, 負のプロンプトを“Beaches ( ビーチ )” として調整しています。 通常のプロンプトと負のプロンプトをバランスよく組み合わせることで、モデルの創作範囲が適切に定まり、結果としてより予測可能で望ましい画像が得られるようになります。 画像のサイズとアスペクト比 Amazon Nova Canvas は 正方形 (1:1)、縦長、横長の解像度でトレーニングされています。画像生成タスクでは、最大出力解像度は 419 万ピクセル ( 例えば 2048×2048 や 4096×1024 など ) となっています。画像編集タスクについては、画像の最長辺が 4,096 ピクセル以内で、アスペクト比が 1:4 から 4:1 の間であること、そして総ピクセル数が 419 万以下であることが求められます。これらの制限を理解しておくと、特に細部にこだわったレイアウトや構図が必要な場面で、画像の歪みや不自然な引き伸ばしを防ぐことができます。 Classifier-free guidance スケール Classifier-free guidance (CFG) スケールは、モデルがプロンプトにどれだけ忠実に従うかを制御するパラメータです： 低い値 (1.1–3) – AI により多くの創造的自由を与え、美的に優れた結果が得られる可能性がありますが、コントラストが低くプロンプトへの忠実度も低くなります 中間の値 (4–7) – バランスの取れたアプローチで、ほとんどの画像生成において推奨される範囲です 高い値 (8–10) – プロンプトに厳密に従い、より正確な結果を生成できますが、時に自然な美しさが損なわれ、色の彩度が上がりすぎることがあります 以下の例では、“Cherry blossoms, bonsai, Japanese style landscape, high resolution, 8k, lush greens in the background. ( 桜、盆栽、日本風の風景、高解像度、8K、背景の豊かな緑 )” というプロンプトを使用しています。 1 枚目の画像 ( CFG 値 2) は桜と盆栽の要素をある程度捉えています。2 枚目の画像 (CFG 値 8) はプロンプトにより忠実で、鉢植えの盆栽、より強調された桜の花、背景の豊かな緑が表現されています。 CFG スケールとは、プロンプトをどれだけ忠実に反映するか、あるいはどれだけ自由な創作性を加えるかを調整する機能だと考えるとよいでしょう。 シード値と再現性 画像を生成する際には、必ずランダム化シード ( 初期条件を決める数値 ) が使われます： シードは通常、長い整数 ( 例えば、 1234567890 ) として表現されます シード値、プロンプト、パラメータの条件が同じなら、毎回完全に同じ画像が生成されます 成功した画像生成のシード値を記録しておけば、後でその画像を正確に再現したり、その有望な結果をもとに微調整されたバリエーションを作成したりすることが可能です シード値そのものに優劣はなく、単に異なる生成起点として機能するものです シード値を活用した再現性は、専門的な制作プロセスに欠かせません。同じシード値を使うことで、全く異なるランダムな画像が生成されるのではなく、プロンプトや設定値だけで微調整し、その変更がもたらす影響を正確に比較検討できるようになります。下の画像は、シード値と他のすべてのパラメータを同じにしたまま、プロンプトだけを “A portrait of a girl smiling ( 微笑んでいる少女の肖像画 )” と “A portrait of a girl laughing ( 笑っている少女の肖像画 )” に変えて生成したものです。 この記事に掲載されているこれまでの画像はすべて、Amazon Bedrock InvokeModel API を通じて利用できる Amazon Nova Canvas のテキストから画像への変換 ( TEXT_IMAGE ) 機能を使って生成されています。以下は、画像生成に関する API リクエストとレスポンスの構造です： #Request Structure { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": string, #Positive Prompt "negativeText": string #Negative Prompt }, "imageGenerationConfig": { "width": int, #Image Resolution Width "height": int, #Image Resolution Width "quality": "standard" | "premium", #Image Quality "cfgScale": float, #Classifer Free Guidance Scale "seed": int, #Seed value "numberOfImages": int #Number of images to be generated (max 5) } } #Response Structure { "images": "images": string[], #list of Base64 encoded images "error": string } コード例 ここで紹介するソリューションは、Python スクリプトまたは Jupyter ノートブックを使って、ローカルでテストすることもできます。この記事では、Python (v3.12) を使用した Amazon SageMaker AI ノートブックを使用しています。詳細については、 Run example Amazon Bedrock API requests using an Amazon SageMaker AI notebook をご覧ください。SageMaker ノートブックインスタンスのセットアップ手順については、 Create an Amazon SageMaker notebook instance を参照してください。インスタンスが、Amazon Nova Canvas アクセスが有効になっている同じリージョンでセットアップされていることを確認してください。 この記事では、Amazon Nova Canvas が有効になっているリージョン (us-east-1) と一致するようにリージョン変数を作成します。別のリージョンでモデルを有効にしている場合は、この変数を変更する必要があります。以下のコードは、Amazon Bedrock を使用して Amazon Nova Canvas v1.0 モデルを呼び出すことによるテキストから画像への生成を示しています。さまざまな種類の生成の API リクエストとレスポンス構造、パラメータ、およびその他のコード例については、 Generating images with Amazon Nova を参照してください。 import base64 #For encoding/decoding base64 data import io #For handling byte streams import json #For JSON processing import boto3 #AWS SDK for Python from PIL import Image #Python Imaging Library for image processing from botocore.config import Config #For AWS client configuration #Create a variable to fix the region to where Nova Canvas is enabled region = "us-east-1" #Setup an Amazon Bedrock runtime client client = boto3.client(service_name='bedrock-runtime', region_name=region, config=Config(read_timeout=300)) #Set the content type and accept headers for the API call accept = "application/json" content_type = "application/json" #Define the prompt for image generation prompt = """A cat sitting on a chair, mountains in the background, low angle shot.""" # 椅子に座る猫、背景に山々、低アングル撮影 #Create the request body with generation parameters api_request= json.dumps({ "taskType": "TEXT_IMAGE", #Specify text-to-image generation "textToImageParams": { "text": prompt }, "imageGenerationConfig": { "numberOfImages": 1, #Generate one image "height": 720, #Image height in pixels "width": 1280, #Image width in pixels "cfgScale": 7.0, #CFG Scale "seed": 0 #Seed number for generation } }) #Call the Bedrock model to generate the image response = client.invoke_model(body=api_request, modelId='amazon.nova-canvas-v1:0', accept=accept, contentType=content_type) #Parse the JSON response response_json = json.loads(response.get("body").read()) #Extract the base64-encoded image from the response base64_image = response_json.get("images")[0] #Convert the base64 string to ASCII bytes base64_bytes = base64_image.encode('ascii') #Decode the base64 bytes to get the actual image bytes image_data = base64.b64decode(base64_bytes) #Convert bytes to an image object output_image = Image.open(io.BytesIO(image_data)) #Display the image output_image.show() #Save the image to current working directory output_image.save('output_image.png') クリーンアップ ソリューションのテストが完了したら、使用していないリソースによる課金を防ぐため、以下のリソースをクリーンアップしてください： SageMaker ノートブックインスタンス内の Jupyter ノートブックをバックアップしましょう SageMaker ノートブックインスタンスをシャットダウンし、削除してください コストに関する考慮事項 AWS にデプロイしたソリューションでは、以下の費用が発生します： Amazon Bedrock での生成 AI 推論に対する料金が発生します。詳細は Amazon Bedrock の料金 を参照してください。 SageMaker ノートブックインスタンスの使用料が発生します。詳細は Amazon SageMaker AI の料金 を参照してください。 まとめ この記事では、AI を使った画像生成について紹介し、Amazon Bedrock で利用可能な画像モデルへのアクセス方法の概要を説明しました。さらに、Amazon Nova Canvas を使用した画像生成プロセスと重要なパラメータについて例を交えながら解説しました。この記事で紹介したコードテンプレートとコード例は、Amazon Nova Canvas の基本を理解し、Amazon Bedrock で実際に AI による画像生成を始めるための第一歩となることを目指しています。 Amazon Nova Canvas のテキストからの画像生成機能やその他の機能の詳細については、 Generating images with Amazon Nova をご覧ください。ぜひお試しいただき、ご感想をお聞かせください。 著者について Arjun Singh は、Amazon のシニアデータサイエンティストとして活躍中で、人工知能、機械学習、ビジネスインテリジェンスの分野に精通しています。視覚的思考を得意とし、コンテンツ作成における生成 AI 技術に強い関心を持っています。顧客と協力して、顧客の目標達成に向けた機械学習および AI ソリューションの構築に取り組んでいます。シンシナティ大学にて情報システムの修士課程を修了。仕事以外では、テニスや筋トレ、新しいスキルの習得を趣味としています。

はじめに 製造業では、モノ（ハードウェア）を中心とした売り切り型のビジネスから、スマートな製品、すなわちモノを起点に顧客と繋がり、コト（サービス）を提供するビジネスへの転換が叫ばれています。各企業は、ビジネスモデルの転換、ソフトウェアへのこれまで以上の注力、顧客との直接接点、販売開始後の継続的改善などのまったく新しい取り組みを進めることが喫緊の課題となっています。 急速に進歩する生成 AIは、こうした取り組みを推進する強力なテクノロジーであり、顧客に合わせた体験を提供することで製品そのものを差別化し、ソフトウェアの開発に活用することで、生産性やスピードを大きく向上することができます。 本ブログでは、 AWS Summit Japan 2025 の 製造 EXPO において AWS のソリューションアーキテクトが開発したデモを題材に、生成 AI が製造業のスマート製品開発をどのように変えていくのかを論じます。 本ブログは２部構成になっており、１部ではスマート製品の課題と、生成 AI のスマート製品における利用者・運営者への価値について記述し、第２部では開発加速について記載します。 製造業におけるスマート製品の価値と課題 従来のビジネスモデルでは、製造業の企業は既存市場に対して長い開発サイクルで製品を提供し、最終的な利用者よりも販売・流通に製品を大量の一括供給することで収益を得てきました。 図: スマート製品（コト売り）における価値 一方、スマート製品においては、小さなプロダクトを素早く世の中に出し、顧客の支持を得て継続的な収益を元にビジネスを拡大していきます。ユーザーの満足度がビジネス成果に直結するため、個客に合わせたサービスの提供、市場の声に基づく修正や機能追加などを継続的に行う必要があります。そのため、サービスの利用状況のデータを積極的に収集し、それを元にビジネスの改善や、製品の継続的・短周期の更新を実現するメカニズムを新たに作る必要があります。 利用者の視点 パーソナライズされた機能提供 製品機能の継続的な改善・拡充 運営者の視点 加入（サブスクリプション）の管理、会員管理、支払いなど 顧客の声や利用状況など、サービスの状況の把握 ビジネス目標 (KPI) の達成状況の把握 開発者の視点 ソフトウェアの遠隔更新 製品への組み込みを含むソフトウェア開発・テストの効率化 (DevOps) スマート製品文脈での生成 AI の進歩とクラウドの価値 生成 AI の進歩はスマート製品に大きな影響を与えつつあります。ほんの1年ほど前には、モデルの知識や既存文書を元にした Q&A のアプリケーションが主流でした。昨今、モデルとの情報の授受が標準化されてユーザーのデータを生成AIで分析することが容易になり、システムに組み込まれた複数の生成AI機能を統合してユーザーに提供するマルチエージェント技術が登場しました。これらによりパーソナライズされたアドバイスや顧客体験を実現する方法が進化しています。 また、ライブコーディングへの応用によりソフトウェア開発を大きく加速する強力なテクノロジーとしても進化し続けています。 これまでも、調達の速さ、従量課金、超大規模なシステムへの拡張性、また様々な SaaS 製品との組み合わせが容易であるといった AWS クラウドの特性は、スマート製品の実現に最適でした。さらに、生成 AI の時代においては、 1) 生成AIが活用する様々な種類・拠点・開発プロセスのデータを集約できること、 2) 進歩し続ける生成AI技術をすぐに試し、活用できることが、更に重要な要素になってきています。 今回、 AWS Summit における製造 EXPO の展示テーマである e-Bike (電動自転車)をスマート製品と見立て、 AWS クラウドと生成 AI が顧客価値・開発加速の両方をご提案する２つのソリューションデモを作成しました。 生成 AI を活用した顧客価値: 顧客体験向上とビジネス判断の迅速化 ２つのデモは、 e-Bike を製造しサブスクリプションサービスを運営する企業を題材に、製品の利用者顧客がパーソナライズされた提案をリアルタイムに受ける「 e-Bike プロダクトデモ」と、 e-Bike のビジネスの運営者へ生成 AI を活用した管理アプリがサービス運営と経営計画に対する価値提案を行う「 e-Bike サービスダッシュボード」です。 いずれも、デモの開発には設計・コーディング等に生成AIをフル活用しており、その詳細については後編でご紹介します。 ソリューションデモ１: AI エージェントが実現するスマート製品の新体験 「 e-Bike プロダクトデモ」は、 AWS クラウドとエッジコンピューティングを融合させた次世代のスマート製品体験を提案します。デモでは、複数の AI エージェントがライダーをリアルタイムでサポートし、顧客体験を最大化します。 e-Bike に搭載される 7インチタッチスクリーン HMI (表示機器) に、 AWS IoT Greengrass を搭載して、取得したセンサーデータや外部データを元に、 Amazon Bedrock によりパーソナライズされたアドバイスや UI の提供を実現しています。 １-１. AI エージェントによる顧客体験の改善 e-Bike でより快適な走行体験を実現するためには、ライダーの状況に応じた適切なアドバイスとタイミングの良い情報提供が不可欠です。従来のシステムでは、センサーデータに基づく数値的な異常検知や、事前に定義されたルールに基づくアラートは可能でした。しかし、ライダーの経験レベルや目的、その時々の体調、天候といった複雑な状況を総合的に判断し、個々のライダーにパーソナライズされたアドバイスを提供することは技術的に困難でした。また、 HMI の情報提供内容についても、例えば効率的なサイクリングに集中したいと考えた時にケイデンスやトルクといった必要情報を柔軟に表示させるためには走行を中断して手動で設定を変更する必要があり、シームレスな体験を妨げていました。 このデモでは、 e-Bike から取得したテレメトリーデータを複数の特化型 AI エージェントが分析・連携し、環境、ライダー、機器の状態を総合的に判断することで、個々のライダーの状況に応じたアドバイスの生成と画面表示の自動最適化を行います。 図: デモストーリー 状況に応じたアドバイス : e-Bike からケイデンス（走行距離）、速度、ペダリングのトルク、ギアレベルといった走行データをリアルタイムに AWS クラウドへ送信し、生成 AI エージェントが分析を行います。ライダーの興味やリクエストに基づいて、これらの走行データに加え、天候や健康情報なども考慮した適切なアドバイスを提供します。例えば、ライダーから「効率的なペダリングフォームをアドバイスして」というリクエストを受けた場合、システムは直近のテレメトリーデータを分析します。右足のペダリングトルクが左足より大きくなっているような非効率な状況を検知した場合、 AI エージェントは「右足のトルクを少し抑えてみましょう」といった具体的なアドバイスを提供します。 このデモは、 Amazon Bedrock Agents のマルチエージェントコラボレーション機能を活用しています。システムの中核となるスーパーバイザーエージェントは、ライダーから予め設定されたリクエスト（プロンプト）とテレメトリーデータを分析し、必要に応じて適切な専門エージェント (コーチングエージェント、健康エージェント、天候エージェント、メンテナンスエージェント) へタスクをルーティングします。これにより、状況に応じて最適化されたアドバイスを実現しています。 状況に応じた表示の自動最適化 : 本システムでは、 AI のアドバイス内容に応じて HMI 表示を自動的に最適化することで、ライダーは走行を中断することなく必要な情報をリアルタイムで確認できるようになります。例えば、「左右のペダリングのトルク差があるので、均一にトルクをかけると効率が良いですよ」とアドバイスされた場合、「右トルク」と「左トルク」をテレメトリーに出してくれます。 この仕組みは、 Model Context Protocol (MCP) を活用して HMI と生成 AI モデルを接続することで実現され、プログラム等を開発しなくても HMI 表示を自動的に最適化することができています。具体的には、 Amazon Bedrock によるアドバイス内容に基づき、状況に適したテレメトリー表示の指定と HMI 表示の自動制御を行っています。同じ仕組みを用いて、アシストレベルの調整といった応用も可能です。 図: HMI 画面 図: デモ１のアーキテクチャ ソリューションデモ２ : AI が導くスマートフリート管理とビジネス改善 ソリューションデモの２つめはサービス運営に焦点を当てています。「 e-Bike サービスダッシュボード」は、サブスクリプションモデルで運営される e-Bike フリート管理と経営改善アドバイスをするデモです。各 e-Bike の位置とステータスを一目で把握できるとともに、 AI がデータドリブンな意思決定をサポートします。このダッシュボードによりサービス管理者はサービス品質の向上と収益性の最適化を同時に実現できます。 図: e-Bikeサービスダッシュボードのしくみ ２-１. 生成 AI を活用したサービス運営・経営の改善 スマート製品フリートを一元管理することでサービスの運営状況を一目で把握できます。また、生成 AI がスマート製品の利用状況や各種 KPI を元にビジネス状況を分析し改善施策をレポートします。サービスダッシュボードは以下の機能を持ちます。 デバイスフリートの管理 : ダッシュボードは e-Bike 全体の稼働状況を一目で把握できます。総台数、稼働中、充電中、メンテナンス中の台数をダッシュボードに表示し、個々の e-Bike の詳細情報も一覧で確認できます。多様な条件でのフィルタリングやソートが可能なため、効率的なフリート管理が可能です。また、地図上に e-Bike の現在位置を表示するマップビューで、空間的な状況を把握できます。ステータスに応じたマーカーを確認し、詳細情報もクリックひとつで表示できるので、バッテリー残量やメンテナンス状況を即座に把握できます。さらに、充電ステーションの位置も地図上に表示されるため、 e-Bike 配置の最適化にも活用できます。このように、フリート管理コンソールは、 e-Bike の利用状況を一元的に管理し、迅速な判断と効率的な運用を可能にします。 ビジネス指標の可視化 : ビジネス KPI を一目で把握できるダッシュボードは、意思決定の中心となります。稼働率、平均利用時間、顧客満足度など 8 つの重要指標をコンパクトなカード形式で表示し、目標達成状況をプログレスバーで視覚化します。複合時系列グラフでは、稼働率・退会率・新規入会率を重ね合わせて表示し、ビジネストレンドの相関関係を把握できます。さらにカスタマーボイスの傾向やテレメトリデータの統計も一目で確認することが可能です。 AI 分析による改善施策能 : Amazon Bedrock を活用した AI 分析機能は、現在のデータをもとにビジネス目標達成のための改善策を自動生成します。この処理は定期的に AWS Lambda が起動して Amazon S3 上に HTML 形式の分析レポートを出力します。データ更新時と定期実行（１日１回）により、常に最新の分析結果を確認できます。この機能については次の章で詳しく解説します。 図: デバイスフリート管理(開発中のものです) ２-２. 生成 AI によるビジネス改善レポートの仕組み e-Bike サービスダッシュボードの中核機能である生成 AI によるビジネス分析レポートは、 Amazon Bedrock を活用してスマート製品のビジネス状況を自動的に分析し、データに基づいた改善提案を生成するデモです。下の例のように、個々の運営者の現在の状況に合わせ洞察に富んだ分析内容を提供します。 図: AI 分析によるビジネス改善レポート(開発中のものです) e-Bike フリートから収集される様々なデータを統合的に分析します。リアルタイムテレメトリーデータ、顧客の利用パターン、機器の稼働状況、バッテリー状態、位置情報といった IoT データに加えて、カスタマーボイス、サブスクリプション状況、収益データなどのビジネスメトリクスを組み合わせて包括的な分析を実施します。 図: AI分析機能のしくみ AI エージェントは、これらの構造化データと非構造化データを同時に処理し、ビジネス目標である KPI 達成に向けた課題の特定と改善施策の提案を行います。例えば、稼働率の低下傾向が検出された場合、同時期の利用者フィードバック、気象データ、競合サービスの動向などを関連付けて分析し、根本原因の推定と効果的な対策案を自動生成します。 e-Bike サービスダッシュボードは、リアルタイムデータ分析、地理空間情報の可視化、 AI による改善提案を統合することで、フリート管理者はデータドリブンな意思決定を行い、事業者に対してパーソナライズされたアドバイスを提供し、サービス品質向上と収益性最適化を達成できます。 第一部のまとめと第二部の紹介 このブログでは、製造業における生成 AI ( Amazon Bedrock と Amazon Q Developer ) を活用したスマート製品開発の新しい形について、 AWS Summit Japan 2025 の製造 EXPOで展示された e-Bike デモを題材に解説しました。 第二部では、生成 AI を活用した製品開発ライフサイクルの改善手法とその効果について、このデモ開発で培った知識と経験を紹介します。 このブログは AWS Japan のソリューションアーキテクト 吉川晃平、村松 謙、山本 直志、西田 光彦が共同で執筆しました。ソリューションデモは執筆者たちと中西 貴大が開発しました。

AWS 上では、 Amazon RDS を利用することで、OSSのデータベースだけでなく、各種商用データベースを運用負荷を下げて利用することが可能です。 昨今は、Oracle Database @ AWS といった新しいオファリングがアナウンスされたり、RDS for SQL Server でマルチAZを活用した AlwaysOn が構成できるようになったり、 IBM Db2 が新たに利用可能になる等、より多様な選択肢が提供されるようになっています。 一方で、「オンプレミス（自社環境）上で動いている商用データベースを AWS にマイグレーションしたいが、どのような選択肢を利用すれば良いか分からない」でるとか「すでに保持しているライセンスをどのように AWS 上に持ち込むのか分からない」といったご相談を受けることもあります。 そこで今回、 AWS の基本的な考え方や商用データベースを稼働させる基本的なメリットから説明した後に、各種商用データベース( Oracle, SQL Server, IBM Db2 ) を AWS 上で動かす際の選択肢、ライセンス等の関連知識や注意点をまとめてご説明する、以下のWebセミナーを実施することにしました。 AWS オンライン セミナー：商用データベースを AWS で活用する 日時：2025 年 7 月 17 日 (木) 10:00 – 12:00 申し込み： https://pages.awscloud.com/eib-db-250717-reg.html 内容： AWSのDB関連基本サービスの説明と、活用パターン : データベースを AWS 上で動かす際にしっておいた方が良い、 AWS の基本概念と、押さえておいた方が良い、データベース関連の各種サービスの基本情報をコンパクトに説明します。 Oracle database on AWS ：OracleデータベースをAWS上で稼働させる選択肢として、RDS for Oracleに加え、今後リリースが予定されているOracle Database@AWSについてもご説明いたします。また、OracleライセンスのAWS上での取り扱いについても説明します。 SQL Server on AWS ：マイクロソフトテクノロジーをAWS上で活用するための基本知識に加え、SQL ServerをAWS上で稼働させる際の選択肢や、AlwaysOnの利用方法、ライセンスの考え方等を説明します。 IBM Db2 on AWS ： IBM ソフトウェアライセンスを AWS 上で利用する際の考え方に加えて、 RDS for Db2 の機能概要、および既存Db2からのデータ移行ツール等について説明します。 午前の 2 時間でクイックに基本を把握できる内容になっていますので、上記内容にご興味がある場合はぜひ こちらよりお申込み ください。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 最近は、2 週間後に迫っている AWS Summit Japan 2025 の準備に AWS 社員一同奮闘しています。ぜひ現地にお越しいただけると嬉しいです！ 6 月に入りましたので今月の builders.flash の記事の中から生成 AI に関係するものをピックアップしてみます。 Cline with Amazon BedrockとBlender MCP で3Dモデルを生成してみた !（AWS） 生成AIで物体検出 ! Amazon Novaでバウンディングボックスを描画しちゃおう（AWS） Amazon Bedrock+Dify+αで AI エージェントとデータ利活⽤を⺠主化する（株式会社Speee様） いずれも話題の技術やツールに関する読み応えのある記事ですね（AWS 社員は猫ちゃんわんちゃん好きが多いんでしょうか！？）。 4 月に発表した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、6 月 2 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「【寄稿】生成 AI 活用によるガバメントクラウド環境運用管理補助業務の効率化」を公開 株式会社大崎コンピュータエンヂニアリング様は、自治体様のガバメントクラウド導入案件の支援・構築に携わっています。令和 7 年度より本番システムが順次稼働する中、限られた人数で業務を実施する必要がありました。そこでセキュリティ関連の運用業務の効率化に向けて生成 AI の導入を検討しました。 Amazon Bedrock を活用し、JSON 形式のアラートログから要約文を作成する『アラート要約機能』と、CloudTrail ログの検索・要約を行う『ログ要約機能』を開発しました。その結果、これまで全てのインシデントをエスカレーションしていた監視チームにて 84.6 % のインシデントを一時対応できるようになりました。またインシデント調査を行う運用チームでは、これまで 19 分かかっていた判断が 8.3 分に短縮されたとのことです。今回 AWS を採用したのは、 Amazon Bedrock 含む AWS サービスが ISMAP などの政府認証を取得しており安心して使える点が挙げられていました。 ブログ記事「Amazon ECS、Amazon EKS、AWS Serverless MCP サーバーで AI 支援の開発を強化」を公開 2025 年 5 月 29 日に、 Amazon ECS 、 Amazon EKS 、 AWS Serverless 向けの専用 Model Context Protocol (MCP) サーバーが、 AWS ラボ GitHub リポジトリ で利用できるようになりました。これらのソリューションを使用することで、各サービスの機能を深く理解したコード生成や開発支援を行うことが可能になります。本ブログでは、Amazon Q CLI を使用して各 MCP サーバーと接続しながらアプリケーションを構築・デプロイするデモを紹介しています。 ブログ記事「Amazon ECS MCP Server を用いたコンテナデプロイメントの AI 支援と自動化」を公開 Amazon ECS MCP Server を使用することで、アプリケーションを自動的にコンテナ化し、 AWS Fargate と Application Load Balancer (ALB) を活用しながら、Amazon ECS へのデプロイメントを管理できるようになります。この記事では Amazon ECS MCP Server が持つツールの概要や Amazon Q Developer を通じたアプリケーションのコンテナ化のデモなどを紹介しています。 ブログ記事「【開催報告&資料公開】九州ローカルミーティング AI Agent ワークショップ」を公開 2025 年 5 月 29 日に「九州ローカルミーティング AI Agent ワークショップ」というイベントを開催しました。本ブログではイベントの概要の紹介と、イベント内で登壇者が発表に使用した資料を公開しています。公開資料を用いて、ぜひ皆様も AI Agent のユースケースの発掘にトライしてみてください！ ブログ記事「【開催報告 & 資料公開】AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜」を公開 2025 年 5 月 22 日に「AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜」と題したオンラインセミナーを開催しました。注目が高い技術領域ということで非常に多くの方にご参加いただきました。本ブログでは、セッション内容の紹介と発表資料・録画の公開をしています。AI コーディングエージェントの仕組みや活用方法、組織への導入方法について知りたい方はぜひご覧ください。 サービスアップデート AWS マネジメントコンソールおよびチャットアプリケーションにおける Amazon Q Developer Chat のエージェント機能の導入 AWS マネジメントコンソール、Microsoft Teams、および Slack における新しく改良された Amazon Q Developer のエージェント機能を発表しました。これまで、Amazon Q Developer は質問に対し、AWS の基本的なガイダンスを回答してきました。本アップデートにより、複数ステップの推論機能と AWS API を使用して、より複雑なクエリに回答できるようになりました。例えば、「決済処理 Lambda 関数から 500 エラーが発生するのはなぜ？」と質問すると、関連する CloudWatch ログを自動的に収集し、関数の構成とアクセス許可を調査し、API Gateway などの接続されたサービスをチェックして分析を行います。これらの新機能は、Amazon Q Developer が利用可能なすべての AWS リージョンでアクセスできます。詳細は こちらのブログ を参照ください。 Amazon Q Developerがお客様のAWSコスト最適化を支援する機能を提供開始 Amazon Q Developerがお客様のコスト削減機会を特定するための、パーソナライズされたコスト最適化の推奨事項の提供を開始しました。この新機能により、「AWS の請求額を下げるにはどうすればよいですか？」などの質問をして通じて、インスタンスの最適化、Savings Plans やアイドル状態のリソースの終了などの機会を見つけて実装することができます。この機能は米国東部（バージニア北部）リージョンで利用可能で、中国リージョンとAWS GovCloud（米国）を除くすべてのリージョンに対して推奨事項を提供します。 Amazon Q Developer エージェント型コーディング体験が JetBrains と Visual Studio で利用可能に Amazon Q Developer は JetBrains および Visual Studio IDE 内でのエージェント型コーディング体験のサポートを発表しました。エージェント機能はすでに Visual Studio Code と Amazon Q Developer CLI で利用可能でしたがサポートする対象が広がりました。これらの IDE を利用されている方はこの機会に是非 Amazon Q Developer をお試しください。 Amazon Q Developer Eclipse IDE プラグインが一般提供開始 Amazon Q Developer プラグインが Eclipse IDE 向けに一般提供を開始しました。このローンチにより、開発者は Eclipse IDE 内で、Amazon Q Developer のエージェント型コーディング体験を利用して、複雑なワークフローをシームレスに実行できるようになりました。 無料の Amazon Q Developer プラグイン for Eclipse をダウンロードして始めましょう。 Amazon Q Developer CLI が Claude Sonnet 4 をサポート Amazon Q Developer CLI が Anthropic の Claude Sonnet 4 をサポート開始しました。Claude Sonnet 4 により、強化されたコーディングと推論能力を通じて日常の開発タスクを最適化できます。また開発者は 「/model」コマンドを使用して、Q Developer CLI でタスクを実行する際に特定の Claude Sonnet モデルを選択できるようになりました。これによりユースケースに合ったモデルの選択ができるようになりました。 NVIDIA GPU を搭載した Amazon EC2 インスタンスの料金および使用モデルの更新 Amazon EC2 P5 および P5en インスタンス、Amazon EC2 P4d および P4de インスタンスの料金引き下げを発表しました。P5 は最大 45 %、P5en は最大 26%、P4d および P4de は最大 33% 引き下げとなります。2025 年 6 月 1 日からのオンデマンド料金と、2025 年 6 月 4 日以降に有効となる Savings Plans 購入に適用されます。料金の詳細は、 EC2 料金ページ をご覧ください。また EC2 Capacity Blocks for ML を通じてのみ利用可能だった Amazon EC2 P6-B200 インスタンス向けの Savings Plans の提供を開始しました。どちらもコスト削減をお客様に直接還元するという AWS らしい嬉しいアップデートですね。 Amazon SageMaker AI トレーニングジョブが NVIDIA B200 GPU を搭載した P6-B200 インスタンスの一般提供を発表 Amazon SageMaker AI は、NVIDIA B200 GPU を搭載した Amazon EC2 P6-B200 インスタンスのトレーニングジョブでの一般提供を発表しました。Amazon EC2 P6-B200 インスタンスは、AI トレーニングにおいて P5en インスタンスと比較して最大 2 倍のパフォーマンスを提供します。Amazon SageMaker AI と組み合わせて利用することで、パフォーマンスとコストの最適化を図ることができます。米国西部（オレゴン）AWS リージョンの SageMaker HyperPod フレキシブルトレーニングプラン を通じて利用することができます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

こんにちは、Amazon Connect ソリューションアーキテクトの清水です。 2025年4月のアップデートまとめ はご覧いただけましたでしょうか。6月25日/26日には AWS Summit Japan 2025 が開催予定となっており、 AWS Expo では Amazon Connect に関する出展を行います。SA 一同、皆様とお会いできることを楽しみにしています。 今月はアップデート 情報に加え、AWS Summit の Amazon Connect 関連セッションに関する情報をお届けします。皆様のお役に立つ内容があれば幸いです！ 注目のアップデートについて AWS Summit Japan 2025 : Amazon Connect 関連セッション 2025年5月のアップデート一覧 AWS Contact Center Blog のご紹介 1. 注目のアップデートについて ＃1 Amazon Q in Connectのプロアクティブな推奨機能に6つの対応言語が追加   顧客サービス向けの生成AI搭載アシスタントである Amazon Q in Connect の言語対応が拡大しました。エージェントは英語に加えて、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語での推奨事項を受け取ることが可能になりました。Amazon Qin Connect は、会話分析と自然言語理解 (NLU) を使用して、音声やチャットでのやり取りの中で顧客の意図を検出し、エージェントにリアルタイムでの生成型レスポンスと推奨アクションを提供することで、顧客の問題を迅速かつ正確に解決します。これまで英語のみで利用可能だったプロアクティブな推奨機能が、現在では全7言語で利用できるようになりました。 日本語の会話に対して推奨を出力するには、「回答の推奨」に設定しているエージェントのロケールが Japanese であることを確認した上で、日本語に対応したプロンプトを割り当てる必要があります。また、コールフローで「Amazon Q in Connect」ブロックを設定すること、エージェントに「Amazon Q Connect」を許可したセキュリティプロファイルを割り当てる必要があります。 関連リンク 管理者ガイド Amazon Connect の機能でサポートされている言語 2. AWS Summit Japan 2025 : Amazon Connect 関連セッション AWS Summit Japan 2025 では、今年も Amazon Connect のお客様導入事例や、ユースケースを元にした最新機能のご紹介についてのセッションを行います。皆様のコンタクトセンター改革のヒントとなる情報をご提供いたしますので、是非ご参加ください。最新の情報、およびご登録については AWS Summit Japan ページ をご覧下さい。 時刻 タイトル 6/25(水) 12:40～13:10 かんぽ生命のコンタクトセンターを AWS 技術で刷新。安定した WebRTC を追求し、フルクラウド化に挑戦 6/25(水) 13:50～14:30 Amazon Connect で実現するカスタマーセルフサービスの新しいカタチ 6/25(水) 14:50～15:30 コールセンターだけじゃない！エネルギー業界に学ぶ、Amazon Connect の活用パターン 6/26(金) 12:50～13:05 (ミニブースセッション) カスタマーサービスの最前線、コンタクトセンターから学ぶ ウェルビーイングのための生成 AI の活用 3. 2025年5月のアップデート一覧 Amazon Q in Connectのプロアクティブな推奨機能が6つの言語に拡大 – 2025/05/29 「 注目のアップデート1 」をご覧下さい AWS service changes – 2025/05/20 各サービスの具体的なサポート終了日と移行パスをご確認ください。 特に Amazon Connect に関連の深いサービス Amazon Pinpoint Amazon Connect Voice ID Amazon Connect で Omnissa クラウドデスクトップのオーディオ最適化のサポートを開始 – 2025/05/09 Amazon Connect で、Omnissa 仮想デスクトップインフラストラクチャ (VDI) 環境での高品質の音声体験を簡単に提供できるようになりました。Amazon Connect は、エージェントのローカルデスクトップから Connect にメディアをリダイレクトし、エージェントエクスペリエンスを簡素化し、ネットワークホップを減らすことで音質を向上させることにより、音声を自動的に最適化します。エージェントは、Omnissa リモートデスクトップアプリケーション (Omnissa Horizon など) にログインするだけで、 Amazon Connect オープンソース JavaScript ライブラリ の API を使用して、カスタムエージェントのユーザーインターフェイス (カスタムの Contact Control Panel など) を使用して通話の受付を開始できます。 関連リンク 管理者ガイド Amazon Connect の外部音声の料金の変更 – 2025/05/08 Amazon Connect に、外部音声転送と外部音声システム付きコンタクトレンズの新しい料金モデルが追加されました。新しい料金モデルでは、外部音声コネクタと外部音声通話分に対して個別の料金が適用され、2025 年 5 月 1 日よりすべてのお客様に対して有効となります。 外部音声転送では、Amazon Connect から別の音声システムに音声通話とメタデータが直接転送されるため、Amazon Connect テレフォニーと音声自動応答 (IVR) を使用してカスタマーエクスペリエンスを向上させることができます。現在、外部転送コネクタはそれぞれ月額 3,100 USD、外部音声転送は 1 分あたり 0.005 USD です。 外部音声対応の Contact Lens では、既存の音声システムを使用して、Amazon Connect Contact Lens の通話記録、通話録音、リアルタイムおよび通話後の分析、エージェント評価を利用可能になり、顧客体験とエージェントのパフォーマンスの向上に役立ちます。現在、外部音声コネクタはそれぞれ月額 3,100 USD、外部音声通話分は 1 分あたり 0.012 USD です。Contact Lens の会話分析とパフォーマンス評価を利用する場合には、別途料金がかかります。  関連リンク 外部音声転送 – Amazon Connect 管理者ガイド 外部音声対応 Contact Lens – Amazon Connect 管理者ガイド Amazon Connect の料金 Amazon Connect Contact Lens のリアルタイムダッシュボードが AWS GovCloud (米国西部) で利用可能に – 2025/05/05 Amazon Connect Contact Lens のリアルタイムのキューとエージェントのパフォーマンスダッシュボード、およびフローパフォーマンスダッシュボードが、政府および公共部門のお客様向けに設計された安全なクラウド環境である AWS GovCloud (米国西部) で利用できるようになりました。新しいダッシュボードでは、1 つのインターフェイスから数回クリックするだけで、エージェントのアクティビティをリアルタイムで監視し、お問い合わせのリッスン、お問い合わせへの割り込み (引き継ぎ)、エージェントの状態の変更などのアクションをすぐに実行できます。ダッシュボードでは、ウィジェットレベルのフィルターとグループを定義したり、列を並べ替えたりサイズを変更したり、新しいメトリクスを削除または追加したりできるようになりました。これらのダッシュボードを使用すると、カスタム定義の期間 (週ごとなど)、概要グラフ、時系列グラフなどを使用して、リアルタイムおよび履歴の集計パフォーマンス、傾向、インサイトを表示および比較できます。たとえば、エージェントがエラー状態の場合は自動的に赤色で強調表示し、ステータスを利用可能に戻すために追加の支援が必要なエージェントをすばやく視覚的に示すことができます。 関連リンク 管理者ガイド Amazon Connect for WhatsApp Business メッセージングと SMS が新しい AWS リージョンで利用可能に – 2025/05/05 Amazon Connect は WhatsApp Business メッセージングの提供範囲を、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (シドニー)、カナダ (中部)、アフリカ (ケープタウン) の 5 つの新しい AWS リージョンに拡大しました。さらに、Amazon Connect SMS がアフリカ (ケープタウン) で利用できるようになりました。これらの拡大により、Amazon Connect の統合コンタクトセンター機能を活用してシームレスなオムニチャネル体験を提供しながら、好みのメッセージングチャネルを通じてお客様とやり取りできるようになります。今回のリリースにより、Amazon Connect for WhatsApp Business メッセージングおよび Amazon Connect SMS は、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (フランクフルト)、欧州 (ロンドン) およびアフリカ (ケープタウン) で利用可能です。 関連リンク 管理者ガイド Amazon Connect アウトバウンドキャンペーンでポーランドがサポートされるように – 2025/05/05 Amazon Connect は、欧州 (フランクフルト) および欧州 (ロンドン) リージョンでポーランドへのアウトバウンドキャンペーン通話をサポートするようになり、配達通知、マーケティングプロモーション、予約通知、債権回収などのユースケースで、音声、SMS、メールを使って簡単にプロアクティブにコミュニケーションできるようになりました。アウトバウンドキャンペーンは、顧客プロファイルからの統合された顧客データと、キャンペーン管理、ターゲティング、分析のための直感的な UI を使用して、リアルタイムのオーディエンスセグメンテーションを提供します。複雑な統合や AWS コンソールへの直接アクセスが不要になります。アウトバウンドキャンペーンは AWS Connect コンソール内で有効にできます。アウトバウンドキャンペーンにより、Amazon Connect は、単一のビジネスフレンドリーなアプリケーションで、音声チャネルとデジタルチャネルのインバウンドとアウトバウンドの両方のエンゲージメントをネイティブでシームレスにサポートする唯一の CCaaS プラットフォームになります。 関連リンク 管理者ガイド(リージョン別の Amazon Connect 機能の可用性) Amazon Connect、アウトバウンドキャンペーンに 5 つの新しいメトリクスとダッシュボードのドリルダウン機能を追加 – 2025/05/01 Amazon Connect アウトバウンドキャンペーンでは、受信者とキャンペーン実行に関するレポート機能が追加され、進捗状況の追跡やトラブルシューティングを行うための追加メトリクスが利用できるようになりました。これらの機能は Contact Lens ダッシュボードで利用でき、対象となる受信者の総数に対するアウトリーチ総数を追跡することで、キャンペーンのエンゲージメントを簡単にモニタリングできます。キャンペーンを詳しく掘り下げて、各キャンペーン実施時のパフォーマンスデータを調べることができます。例えば、1 か月間毎週キャンペーンを実施する場合は、各週のキャンペーンのパフォーマンスの詳細を表示できます。また、各キャンペーンの配信に関する問題を特定して解決することもできます。例えば、配信に関する 20 件の問題のうち、12 件は対象外のタイムゾーンが原因で、残りの 8 件は通信制限のしきい値に達したことが原因であるといった分析が行えます。リアルタイムのキャンペーンダッシュボードには、ターゲットにした受信者の数からリーチした数まで、キャンペーンの経過が表示されます。新しいメトリクスはすべて、カスタムレポートや他のデータソースとの統合のために、 GetMetricDataV2 API および Zero-ETL データレイク からも利用できます。 関連リンク 管理者ガイド Amazon Connect Contact Lens が、新しいリアルタイム遵守ダッシュボードをリリース – 2025/05/01 Amazon Connect Contact Lens に、エージェント遵守メトリクスのフィルタリングと並べ替えをサポートする、事前設定済みのエージェント遵守ウィジェットが追加されました。このリリースにより、スーパーバイザーは日々の遵守管理をより効率的に行うことができます。また、遵守状況、期間、割合に基づいてフィルターを適用したり、期間または割合で並べ替えたり、キューおよびエージェントのパフォーマンスダッシュボードのエージェント遵守ウィジェットに条件付き書式を適用したりすることもできます。例えば、予定より 5 分以上遅れているエージェントを強調表示して、違反を迅速に特定し、それに応じてエージェントに通知することが可能になります。このウィジェットを使用することで、スーパーバイザーは遵守状況のモニタリングプロセスを簡素化し、生産性を向上させ、遵守に関する問題への対応時間を短縮することができます。 関連リンク 管理者ガイド 4. AWS Contact Center Blog のご紹介 Amazon Connect, Amazon Lex, Amazon Bedrock Knowledge Bases を活用してコンタクトセンターに音声とチャットの生成 AI エージェントをデプロイする (日本語記事) DoorDash は、Dasher として知られる契約配達員からの大量の電話対応で大きな課題に直面していました。2023 年末時点で 3,700 万人以上のアクティブな消費者と月間 200 万人のアクティブな Dasher を抱える同社は、 効率的なセルフサービス体験を提供することでエージェントの負担を軽減する必要がありました。この課題に対処するため、DoorDash のコンタクトセンターチームは、高水準の問題解決と顧客満足度を維持しながら、迅速かつ大規模に解決策を提供するために 生成 AI の力を活用したいと考えました。DoorDash は AWS Generative AI Innovation Center と協力してわずか 2 か月で、Dasher に低遅延のセルフサービス音声体験を提供するソリューションを構築しました。このソリューションは 1 日数十万件の電話に対応し、2.5 秒以内に Dasher の質問に回答しています。また、自動テスト、会話分析、監視と可観測性、LLM ハルシネーションの防止と検出を含む運用機能も提供しています。この記事では、AWS サービスを使用してコンタクトセンターに生成 AI エージェントをデプロイする方法を紹介します。 Customer contact week 2025: Transform your contact center with AI-powered innovation (英語記事) AWS は 2025年6月9日から12日にラスベガスで開催される Customer Contact Week (CCW) のスポンサーとして参加します。このイベントでは、生成 AI とインテリジェント自動化による顧客体験の変革に焦点が当てられ、AWS は Amazon Connect を活用した顧客対応の革新的な取り組みを紹介する予定です。6月10日には富士通の事例を交えた AI 搭載カスタマーエクスペリエンスの実践的なワークショップを開催し、6月11日のメインステージでは、コスト予測可能性を維持しながらカスタマージャーニー全体で AI を最大限活用する方法についてのパネルディスカッションが行われます。また、6月11日から12日にかけて開催されるパビリオンセッションでは、ユナイテッド航空によるデータ統合事例や TELUS のデジタル変革成功事例など、実際の導入事例を中心とした講演が予定されています。本イベントを通じて、AI と分析技術を活用したコンタクトセンターの最適化、オムニチャネルでのカスタマーエクスペリエンス向上など、顧客対応の未来像を描くための具体的な知見を得ることができます。 Unlocking the full potential of Amazon Connect (英語記事) 現代の消費者は高い期待を持っており、あなたの顧客も例外ではありません。すべての企業が、サービスを改善し、コストを削減し、戦略的な成長を支援できる最新の技術革新で先を行こうとしています。 Amazon Connect はこうしたソリューションの1つで、AWS のテクノロジーと AI の力を活用した、現代的でスケーラブルなソリューションです。しかし、導入プロセスを適切に実施しないと、期待される投資効果を十分に得られない可能性があります。この記事では、的を絞ったチェンジマネジメントの実践が投資を保護するだけでなく、さらなる効果を生み出せる分野について詳しく見ていきます。具体的には、注意すべきリスク、真の違いを生み出すことができる指標、そして限られた時間とリソースを最も効果的な変革に活用する方法について説明します。 Proven migration patterns for accelerating Amazon Connect deployments (英語記事) 企業のコンタクトセンターは、個別の IT チームと運用チームを持つ複数の事業部門 (LOB) のサポートに苦心しています。ビジネスプロセスアウトソーシング (BPO) 企業は、独自の要件を持つ何百もの顧客を管理することで、この複雑さをさらに増大させています。コンタクトセンターの移行パターンは、これらの課題に対応し、展開を加速し、運用を簡素化します。この記事では、中規模から大規模なコンタクトセンター移行の確固たる基盤を作る、実証済みの5つのパターンについて説明します。これらのパターンの実装には初期投資が必要ですが、全体的な移行タイムラインを加速することができます。 Wisconsin DOR cuts contact center costs by 66% and boosts performance with ScaleCapacity and Amazon Connect (英語記事) ウィスコンシン州歳入局 (DOR) は、州の所得税・事業税法の管理、固定資産税評価の監督、アルコールとタバコの販売規制、納税者の本人確認、州宝くじの運営、地方自治体への税収分配を行っています。約500人のエージェントが年間70万件の電話に対応するコンタクトセンターは、複数の異なるテクノロジーに依存しており、頻繁な停止、非効率なワークフロー、時間のかかる文書作成、最新機能の不足などの問題を抱え、顧客体験に悪影響を及ぼしていました。シンプルで現代的、かつスケーラブルなソリューションを求め、ウィスコンシン州 DOR は AWS パートナー の ScaleCapacity と提携し、コンタクトセンターを Amazon Web Services に移行しました。わずか4ヶ月で移行を完了し、テクノロジーコストを66%削減、システム停止をなくし、顧客サービス部門での待ち時間を60%削減しました。 Priceline leverages generative AI in Amazon Connect to streamline the customer experience (英語記事) Priceline は、革新的なサービスと価格交渉を組み合わせ、航空券、ホテル、レンタカー、クルーズの最高級の取引を顧客に提供するオンライン旅行業界のリーダーです。オンライン旅行代理店として、Priceline は世界中の信頼できる旅行サプライヤーの広大なネットワークと協力し、顧客に幅広い商品を提供しています。実際、Priceline は世界116カ国以上で120万以上の宿泊施設を提供しています。Priceline は Amazon Connect を活用した顧客体験の近代化の取り組みによる利点について、広く共有してきました。これらの取り組みは、 パンデミック期間中の急激な通話量の増加 に端を発し、その対応のために最新のクラウドベースのコンタクトセンターが必要となりました。その後も Priceline は顧客ニーズの変化に適応し続け、AWS を活用してこれらの機能をさらに発展させています。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 AWS Summit Japan 2025 にもぜひご登録の上、ご来場ください。会場でお待ちしています！ シニア Amazon Connect ソリューションアーキテクト 清水 幸典

　 みなさんこんにちは！ どちらかというと猫より犬が好きな Solutions Architect の高野です。一昨年、昨年の AWS Summit Japan でご好評いただいた Chaos Kitty がさらにパワーアップして AWS Summit Japan 2025 に帰ってきました！ 　 この記事では、2025 年の AWS Summit Japan の AWS Builders’ Fair 内の初日に展示される「Chaos Kitty で楽しくインシデント対応の基本を学ぼう！ 」についてご紹介します。本展示は、システムを構築する上でも重要なレジリエンスやセキュリティをゲームを通じて楽しく学ぶことができる体験型コンテンツです。システムのレジリエンスやセキュリティを強化したい全ての方に本記事を読んでいただき、実際に AWS Summit Japan の会場まで足を運んで体験いただけると幸いです。 　 AWS Summit Japan 2025 の開催期間は 2025 年 6 月 25 日 (水) と 26 日 (木) の 2 日間で、会場は幕張メッセになります。 本展示は初日の 6 月 25 日 (水) のみになりますのでご注意ください。 まだ AWS Summit Japan 2025 に登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Expo の AWS Builders’ Fair の中にあります。詳細は こちら 。 Chaos Kitty とは？ 　 Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層の Web アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応の体験が行うことができます。詳細は 以前のブログ を確認下さい。 1. IoT 電球によるリアルタイムの状態可視化 　 物理的なブロックと電球で表現された Web 3 層アプリケーションのアーキテクチャにおいて、各コンポーネント (Amazon EC2、Amazon RDS、Amazon S3 など) の状態が IoT 電球の色で示されます。電球は、正常な場合には緑、何か異常がある場合には赤で点灯する設定になっており、設定に異常が検出された場合には、電球が緑から赤に変わる仕組みとなっています。これにより AWS 上のアプリケーションの状況をリアルタイムで監視でき、異常をすぐに検知することができます。 2. 障害挿入機能による対応訓練 　 IoT デバイス を操作すると AWS での設定に意図的に設定異常を注入し、IoT 電球の色が赤に変わります。ユーザーは AWS コンソールを使ってこの設定異常を特定・修復し、電球を緑に戻すゲームを行います。修復が完了すれば、修復にかかった時間が表示され、手動での対応の難しさを体感できます。 3. 自動修復機能による対応の効率化 　 注入された設定異常に対して、自動修復するスクリプトを実行する機能が用意されています。マネジメントコンソールを使用した手動修復と比べた自動化の優位性を実感できます。 図 1 : AWS Summit Tokyo 2025 版 Chaos Kitty 外観 図 2 : 障害注入対象の Web 3 層アプリケーション画面 新機能紹介 　 3 回目となる今回は、 できる限り多くの方に簡単にお試しいただけるように 以下パワーアップを行っておりますので、1 つずつご紹介します。 1. IoT 機器なしで設定異常注入・検知ができるように、Web アプリケーション機能追加 2. AWS Cloud Development Kit (AWS CDK) を活用してインフラストラクチャのコード化 (Infrastructure as Code (IaC)) を実装し、デプロイメントプロセスを標準化・自動化 3. 電子工作なしで本ソリューションが利用できるように IoT 関連のアーキテクチャ刷新 4. アプリケーション監視用のモニタリングダッシュボードに Amazon CloudWatch Application Signals を採用 IoT 機器なしで設定異常注入・検知ができるように、Web アプリケーション機能追加 　 今までの Chaos Kitty は IoT 機器での操作を前提としたソリューションとなっており、実際に皆様の環境にデプロイして利用いただくにはハードルが高いところがありました。そこで、今回は、今までのインシデント発生から修正までの時間測定だけ行なっていたWebアプリケーションを改修し、設定異常注入機能と、異常箇所検知・可視化機能を追加しました。これにより、IoT 機器なしで、本ソリューションをデプロイいただくだけで、インシデント対応を学習することができるようにしました。 　 Chaos Kitty はセキュリティ的に問題のある設定を注入する Security シナリオと、アプリケーション自体に障害を注入し利用不可にする Resilienency シナリオがあります。それぞれ 1 つだけ異常を発生させる Easy モードと複数の異常を発生させる Hard モードがあります。図 3 のような画面になっていまして、画面中央のゲームスタートボタンを押下すると、図 4 のように、タイマーがスタートし、Web 3 層アプリケーションの異常発生箇所 (図 4 の例では ALB の Security Group) が点灯し、異常箇所が分かるようになります。参加者の方はこれをヒントに AWS コンソール にログインして異常箇所の修正にチャレンジいただきます。是非タイムアタック No.1 を目指して頑張ってください！ 図 3 : Chaos Kitty Web アプリケーション画面 図 4 : 障害発生時の Chaos Kitty Web アプリケーション画面 AWS CDK を活用したインフラストラクチャのコード化 (IaC) 　 AWS Summit Japan にご来場いただく方に限らず、本ソリューションをご利用いただけるように、アーキテクチャを一部改修し、AWS CDK を活用した IaC 化を行い、AWS Samples として公開する予定です。これにより、利用したい方はコマンド数回で本ソリューションが簡単にデプロイできるようになります。個人での学習や、社内のシステム運用者教育等のイベントにご活用いただけますと幸いです。できる限り、AWS Summit Japan 2025 開催前、遅くとも 7 月中には AWS Samples で公開を予定しておりますので、ご期待下さい！ 図 5 : AWS Summit Japan 2025 版 Chaos Kitty アーキテクチャ概要 電子工作なしで本ソリューションが利用できるように IoT 関連のアーキテクチャ刷新 　 今まで Chaos Kitty を利用するには、Raspberry Pi に様々なソフトウェアをインストールして設定を行う必要がありました。この作業が非常に煩雑で大変なため、多くのお客様に利用いただくのが困難でした。そこで今回、IoT 回りの構成を刷新し、Echo デバイスからボタン一つで IoT 電球の色を変更できるようにアーキテクチャを刷新しました。裏側の仕組みは Alexa Skill と連携することで実現しています。本設定方法の詳細は、別途ブログにて詳しくご紹介する予定ですので、ご期待下さい！ アプリケーション監視用のモニタリングダッシュボードに Amazon CloudWatch Application Signals を採用 　 Chaos Kitty はインシデント対応を学習するためのものであり、ゲームとしてわかりやすくするために、アプリケーションの問題箇所を電球で可視化していますが、実際のシステムではそう簡単にはいきません。実システムでは、ユーザ影響がある障害が発生しているかどうか、すぐに確認・分析できるようにするためのダッシュボードによる可視化が有効です。前回の展示では、Amazon CloudWatch dashboards を使って必要なメトリクスやログ、トレースを表示するようにダッシュボードをカスタマイズして展示していました。今回は、Amazon CloudWatch Application Signals を使った標準的なダッシュボードを使い、サービスとして重要な指標を取得して可視化できるようにしています。監視対象アプリケーションには、 AWS Distro for OpenTelemetry を組み込み CloudWatch Agent と連携することで、必要なデータを取得して、Amazon CloudWatch Application Signals のダッシュボードで表示しております。是非、最新のモニタリング機能をご体感下さい！ 図 6 : CloudWatch Application Signals ダッシュボード画面 　 この他にも当日は、生成 AI を利用した障害分析効率化を図る AIOps を体感いただくために、AWS Japan の Solutions Architect が開発した障害分析ソリューション Failure Analysis Assistant (FA2) との連携デモをお見せします。生成 AI を活用することでどのように日々のシステム運用が効率化できるのかご体感下さい！ さいごに 　 Chaos Kitty は実際のインシデントを模擬する形でサービスの稼働状況を電球やブロックを使ってわかりやすく表現しております。日頃クラウドサービスに慣れ親しむ機会が少ない方でも、運用におけるインシデント対応を気軽に体験いただけます。AWS Summit Japan 2025 で、皆様にお会いできることを楽しみにお待ちしております！ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 高野 翔史 Choas Kitty は AWS Japan ソリューションアーキテクトの服部 一成、堀 貴裕、佐々 拓也、津郷 光明、河角 修、鈴木 陽三、黒木 琢央、高野 翔史が中心となって開発しております。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いきなりですが、 Amazon Q を使われていますでしょうか？いつも使っているという方も、まだという方にも、「 Amazon Q CLI でゲームを作ろう 」キャンペーンのお知らせです。タイトルにありますように、AIコーディングアシスタントである Amazon Q CLI を使って、ゲームを作ってみようという学習機会のキャンペーンです。6 月 20 日まで実施されており、参加いただいた方はもれなく T シャツを Get できます！参加のための ガイダンスブログ が出ておりますので、ご確認いただき、ぜひこの機会に Amazon Q CLI に触れてみてください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月2日週の主要なアップデート 6/2(月) Amazon DataZone launches upgrade domain to SageMaker Amazon DataZoneとAmazon SageMaker は、DataZoneドメインを Amazon SageMaker にアップグレードして使用できる新しいユーザーインターフェース(UI) 機能を発表しました。これにより、既存の Amazon DataZone で作成・管理されたアセット、メタデータフォーム、用語集、サブスクリプションなどのすべてのコンテンツは、アップグレードすることで Amazon SageMaker Unified Studio の環境内で新しい SQL 分析、データ処理、AIのユースケースに拡張して利用できるようになります。アップグレードに関する詳細は、 こちらのドキュメント をご確認ください。 Second-generation Amazon FSx for NetApp ONTAP now available in the AWS Mumbai and Tokyo Regions Amazon FSx for NetApp ONTAP の第２世代ファイルシステムが、東京リージョンを含む２リージョンで利用可能となりました。第２世代ではFSx for ONTAP のスケールアウト構成が利用できること、そして最大 12 の高可用性（HA）ペアのファイルサーバーを作成または拡張が可能なため、第1世代と比較してより優れたスケーラビリティと柔軟性を提供します。なお、マルチ AZ 構成は 1 HA ペア のみとなります。 Introducing agentic capabilities for Amazon Q Developer Chat in the AWS Management Console and chat applications AWS Management Console、Microsoft Teams、Slack において Amazon Q Developer は複雑なクエリに対応ができる新しいエージェント機能を提供します。今回のリリースで、Amazon Q Developerは、基本的なAWSに関する質問に答え、専門的なガイダンスを提供するだけでなく、AWSの深い専門知識と新しいマルチステップ推論機能を組み合わせることで、複雑なクエリを解決することが可能です。例えば、「支払い処理のLambda関数から500エラーが発生するのはなぜですか？」と質問すると、自動的に関連するCloudWatchログを収集し、関数の設定と権限を確認し、API Gateway や DynamoDB などの接続されたサービスをチェックし、直近の変更に関する分析して、効率的な解決に導きます。 6/3(火) Amazon Q Developer now helps customers optimize AWS costs Amazon Q Developer が個別のコスト最適化の推奨事項を提供するようになりました。この新機能により、「AWS の請求額を下げるにはどうすればよいですか？」などの質問を Amazon Q Developer にすることで、インスタンスの適切なサイジング、Savings Plans や Reserved Instances の購入、アイドル状態のリソースの終了など、パフォーマンスリスクに基づいて優先順位付けされた推奨事項を受け取ることができます。また、「この推奨事項はどのように計算したのですか？」などの詳細なフォローアップ質問をすることもでき、メトリクス、構成、カスタマイズオプションを含む説明を受け取ることができます。この機能は米国東部（バージニア北部）リージョンで利用可能で、すべての商用 AWS リージョンにわたるコスト最適化の推奨事項を提供します。 Amazon API Gateway introduces routing rules for REST APIs Amazon API Gateway が、カスタムドメイン名を使用した REST API のルーティングルールをサポートするようになりました。この新機能により、HTTP ヘッダーの値、URL ベースパス、またはその両方に基づいて、受信リクエストを動的にルーティングすることが可能になります。API Gateway 内で直接ルーティングロジックを実装することで、プロキシレイヤーや複雑な URL 構造を排除しながら、API トラフィックに対する詳細なルーティング制御を維持できます。この機能はパブリックおよびプライベートの両方の REST API でサポートされており、既存の API マッピングとも互換性があります。 Amazon Athena announces managed query results to streamline analysis workflows Amazon Athena でマネージドクエリ結果という新機能を発表しました。マネージドクエリ結果は、一時的なクエリ結果ストレージを提供することで分析と管理のワークフローを効率化します。例えば、実行する分析のために新しいワークグループを作成する場合、Athenaに結果データを管理させることを選択することで、クエリ結果の S3 の場所を最初に指定することなくクエリを実行でき、結果が暗号化されることを保証し、さらに不要になった後のクエリ結果の保存にかかるコストを回避できます。 6/4(水) Amazon Redshift now supports increased concurrency for vacuum operations Amazon Redshiftは、データウェアハウス内のテーブル間での同時実行性を高めるため、バキューム処理を機能強化しました。バキューム処理は、テーブルデータの並べ替えと、削除された行からのディスク領域の再利用という2つの重要な機能を実行することで、最適なクエリパフォーマンスを維持します。Redshift はすでに、手動メンテナンスの必要性を最小限に抑えるための自動バキューム処理を提供していますが、今回の機能強化により、これらの処理は Redshift によって、より高い同時実行性で実行されるようになりました。さらに、ユーザーは異なるテーブルで複数の手動バキューム処理をセッション間で同時に実行することも可能になりました。 Amazon Lex extends custom vocabulary feature to additional languages Amazon Lexが、中国語、日本語、韓国語、ポルトガル語、カタルーニャ語、フランス語、ドイツ語、スペイン語において、カスタム語彙のサポートを拡張しました。この機能強化により、より広範な言語で、特定分野の専門用語、固有名詞、稀少語の音声認識精度を向上させることが可能となります。例えば、「Cognito」などの技術用語や「支払能力」などの業界固有の語彙が、ボットとのやり取りの中で正確に文字起こしされるようになり、一貫性のある音声認識機能を提供することができます。 Announcing Amazon RDS for PostgreSQL Extended Support versions R2 11.22-rds.20250508 and 12.22-rds.20250508 Amazon RDS for PostgreSQL にて、PostgreSQL データベースの重要なセキュリティアップデートとバグ修正を含む、延長サポートの マイナーバージョン11.22-rds.20250508および12.22-rds.20250508 を提供しました。Amazon RDS 延長サポートは、ビジネス要件を満たすために新しいメジャーバージョンへのアップグレードまでの期間を最大3年間延長することができます。延長サポート期間中、コミュニティがメジャーバージョンのサポートを終了した後も、Amazon RDS は RDS for PostgreSQL データベースに対して重要なセキュリティ修正とバグ修正を提供します。 6/5(木) Amazon OpenSearch Serverless now available in Asia Pacific (Hyderabad) and Asia Pacific (Osaka) regions Amazon OpenSearch Serverless が アジアパシフィック（大阪）リージョンで利用可能になりました。OpenSearch Serverlessは、Amazon OpenSearch Serviceのサーバーレスデプロイメントオプションで、インフラストラクチャ管理の複雑さを伴うことなく、検索および分析ワークロードを実行することができます。 Pricing and usage model updates for Amazon EC2 instances accelerated by NVIDIA GPUs Amazon EC2 P6-B200 インスタンスで Savings Plans が利用可能になりました。また同時に、Amazon EC2 P5 インスタンスで最大 45% 、P5en インスタンスで最大 26% 、P4dとP4deのインスタンスで最大 33% の価格引き下げとなりました。価格引き下げは、2025年6月1日からのオンデマンド価格と2025年6月4日以降の Savings Plan 購入分に適用されます。この新価格は、先進的なGPUコンピューティングをより利用しやすくするとともに、コスト削減分を直接お客様に還元するというAWSのコミットメントを反映しています。更新された価格の詳細については、 EC2 の価格ページ をご確認ください。 Amazon EC2 now enables you to delete underlying EBS snapshots when deregistering AMIs Amazon EC2で、Amazon Machine Images（AMI）の登録解除時に、関連する Amazon EBS スナップショットを自動的に削除できるようになりました。これまでは、AMIの登録を解除する際、関連するEBSスナップショットを別途削除する必要があり、追加の手順が必要でした。今回の機能により、AMIの登録解除時にEBSスナップショットを自動的に削除でき、ストレージコストの管理とAMIクリーンアップワークフローが簡素化されます。 6/6(金) AWS KMS launches on-demand key rotation for imported keys AWS Key Management Service (KMS)は、インポートされたキーマテリアルを持つ 対称暗号化KMSキー のオンデマンドローテーションをサポートしました。この新機能により、Bring Your Own Keys (BYOK)キーのキー識別子（キーARN）を変更することなく、暗号化キーマテリアルをローテーションすることができます。キーのローテーションにより、定期的なキーローテーションを義務付けるコンプライアンス要件とセキュリティのベストプラクティスを満たすことができます。 Amazon EFS and AWS Backup is now available in AWS Asia Pacific (Taipei) Region 台北リージョン(ap-east-2) がオープンとなりました。Amazon Elastic File System (Amazon EFS)、AWS Backup などのサービスも利用可能となっております。台北リージョンのオープンに関する詳細は こちらのブログ を、そして利用可能なサービスは こちら をご確認ください。 今月はいよいよ AWS Summit Japan が開催されます。参加予定の皆様には楽しみにしていただいているとは思いますが、少し先のこともあります。実は、12月1日から5日に ラスベガスで開催される AWS re:Invent 2025 の登録がすでに開始しております！AWS Summit Japan の情熱をそのままに、AWS re:Invent への参加もぜひご計画ください！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

現在のデジタル企業環境において、組織はますます資産管理ソリューションに依存して業務を合理化しています。企業は、複数の IT システムや運用技術 (OT) システムで同じ物理資産を管理する必要に直面することがよくあります。IT チームが企業の IT 資産を追跡・管理するのに役立つサービスの 1 つが ServiceNow です。このサービスは、ハードウェアやソフトウェアの在庫管理、サービス要求、ライセンスコンプライアンス、テクノロジーリソースの完全なライフサイクルを一元的に扱います。一方、OT 向けの AWS IoT SiteWise は、企業が産業機器のデータを大規模に収集、体系化、分析できる管理サービスです。このサービスでは、ライブおよび過去の運用データを統合リポジトリにまとめることができるため、組織は生産効率の向上と資産保守の最適化に役立つデータ駆動型の意思決定ができます。 ServiceNow と AWS IoT SiteWise を一緒に使う際に組織が直面する一般的な課題は、システム間で資産情報を一貫して維持することです。ServiceNow で資産階層が更新されると、運用チームは AWS IoT SiteWise でこれらの変更を手動で複製する必要があり、重複した作業や整合性が損なわれる可能性があります。このプロセスは時間がかかり、エラーが発生しやすく、両環境で同じ資産を管理する無駄が生じます。このブログ記事では、ServiceNow と AWS IoT SiteWise 間で資産データを同期する手法を紹介します。この統合パターンを実装することで、手動による更新を排除し、エラーを減らし、IT と OT プラットフォームで資産階層を一貫して維持できます。 ソリューション概要 このソリューションでは、AWS のサービスを使用して、ServiceNow と AWS IoT SiteWise の間の自動統合を実現しています。 ServiceNow の資産管理システムで変更があった場合、自動的に AWS IoT SiteWise に反映されるため、両システムの同期が維持されます。 図 1: アーキテクチャ 図 1 は 2 フェーズのデータフローを示しています。最初のフェーズ (Ingest) では、データが ServiceNow から Amazon AppFlow を経由して Amazon Simple Storage Service (Amazon S3) に移動します。2 番目のフェーズ (Import) では、データは AWS Glue を経由し、AWS IoT SiteWise に到達する前に Amazon S3 に戻ります。 両方のフェーズでは異なる目的がサービスされています。 インジェストフェーズ Amazon AppFlow は、ServiceNow のテーブル (Operations Technology (OT)、OT Entity、OT Entity Type) からアセットデータを取得します。 そのデータは、その後 Amazon S3 に parquet 形式 で格納されます。 インポートフェーズ AWS Glue は、Parquet ファイルを AWS IoT SiteWise がインポートできる JSON 形式 に変換します。 変換された JSON ファイルは、Amazon S3 に保存されます。 AWS IoT SiteWise は、アセット情報をインポートしてアセットモデルと階層を作成または更新します。 実装の概要 この投稿では、この統合を実装するための以下の段階を提示しています: Amazon AppFlow で ServiceNow コネクタを構成し、アセットデータを Amazon S3 に取り込みます。 AWS Glue ジョブを作成し、データを parquet 形式から JSON 形式に変換して、AWS IoT SiteWise インポートの必須フォーマットに一致させます。 Amazon S3 から AWS IoT SiteWise へのアセットインポートを設定します。 前提条件 このソリューションを実装する前に、次のものが必要です。 アセットテーブルへのアクセス権を持つ ServiceNow インスタンス。この例では、次のものを使用します。 Operations Technology (OT) ( cmdb_ci_ot ): ServiceNow からのOTデバイスレコード。これらのレコードには、名前、シリアル番号、モデル番号、メーカー、および場所情報などの基本的な属性が含まれます。 OT Entity ( cmdb_ot_entity ): OT エンティティインスタンスとそれらの関係を定義したレコードが含まれています。また、運用階層でデバイスがどのように接続されているかを表しています。 OT Entity Type ( cmdb_ot_entity_type ): OT エンティティ (Area、Process Cell、Unit、Equipment Module など) のタイプまたはカテゴリを定義したレコードが含まれています。また、運用階層内で許可される親子関係も定義します。 3 つのテーブルがそれぞれの役割を連携して、OT アセットの全体像を提供します。 cmdb_ci_ot は物理デバイス情報 (構成項目) を処理します。 cmdb_ot_entity はこれらのデバイスのインスタンスと関係性を管理します。 cmdb_ot_entity_type は階層構造のルールとカテゴリを定義します。 Amazon AppFlow、Amazon S3、AWS Glue、AWS IoT SiteWise を使用するための権限を持つ AWS アカウント。 アセットテーブルの読み取り権限を持つ system-only user の ServiceNow 認証情報。 実装 ServiceNow コネクタの構成 このセクションでは、Amazon AppFlow を設定して ServiceNow からデータを取り込み、AWS Glue でデータをカタログ化します。 Amazon AppFlow で ServiceNow コネクタを作成する Amazon AppFlow コンソールに移動します。 左側のメニューから、 Connections の下の ServiceNow をコネクタのドロップダウンから選択します。 Create connection を選択します。 Connect to ServiceNow のポップアップで、図 2 を参照し、次の情報を入力します。 必要に応じて Basic Auth または OAuth2 を選択します。 ユーザーガイド に従って必要な情報を入力します。 OAuth2 を選択した場合は、ServiceNow インスタンスの Client ID、Client secret、Instance URL を入力します。 Basic Auth を選択した場合は、ServiceNow インスタンスの Username、Password、Instance URL を入力します。 すべての情報を入力したら、 connect をクリックします。 図 2: ServiceNow に接続する 各テーブルごとにフローを作成します Amazon AppFlow コンソールに移動します。 左側のメニューで、 Flows の下にある Create flow を選択します。 Flow Name (例: cmdb_ci_ot ) を入力し、図 3 を参照の上、 Next を選択します。 図 3: フローを作成する 「ソース詳細」ダイアログボックスで (図 4 参照)、次の内容を入力します: 「ソース名」では、 ServiceNow を選択します。 「前に作成した接続が ServiceNow コネクタ の下で選択されていることを確認してください。参照名は、お使いの ServiceNow インスタンス名になります。この例では “dev287617” を使用しています。 ServiceNow オブジェクト では、 Operational Technology (OT) を選択します。 宛先詳細 ダイアログボックス (図 4 参照) に移動し、次の内容を入力します: 宛先名 では、 Amazon S3 を選択します。 バケット詳細 の下で、宛先のバケットを選択するか、 新しく作成 ( Amazon S3 コンソール から)します。この例ではバケットプレフィックス cmdb_ci_ot を使用しています。 Next を選択します。 図 4: フローのソースと送信先 ソース から 宛先 へのフィールド マッピング ダイアログボックスで (図 5 参照)、以下の作業を行います。 ソース フィールド名 の下で、 すべてのフィールドを直接マップする を選択します。 Next を選択し、続けて Next を選択します。 最後に フローを実行 を選択して完了します。 図 5: 実行フロー すべてのテーブルに対してフローを作成する “Create flows for each table” の手順を繰り返し、他の ServiceNow オブジェクトとの接続を作成してください: フロー名と Amazon S3 プレフィックス:  cmdb_ot_entity 、ServiceNow オブジェクト: OT Asset。 フロー名と Amazon S3 プレフィックス:  cmdb_ot_entity_type 、ServiceNow オブジェクト: OT Asset Type。 AWS Glue Crawler をセットアップし、スキーマを特定するために実行 AWS Glue コンソールに移動します。 左のメニューから Data Catalog の下にある Crawlers を選択します。 Crawlers ダイアログボックス (図 6 参照) で、 Create crawler を選択します。 図 6: AWS Glue Crawlers Crawler 名 には ServiceNow Crawler を使い、 Next  を選択してください。 図 7: Crawler の properties Add an S3 data source を選択します。 Add an S3 data source  ダイアログボックスで (図 8 を参照)、以下の手順に従います。 データソース として S3 を選びます。 S3 path として <your_bucket_name> を入力します。 Add an S3 data source  を選択します。 図 8: Crawler data source Next を選択します。 IAM ロールの項目で、 Create new IAM role を選択してください (図 9 を参照)。 図 9: Crawler IAM Role ロールの名前を決めます。この例では AWSGlueServiceRole-ServiceNowCrawler を使用します。 Next  を選択します。 ターゲットデータベースの下で、AWS Glue データベースを選択します。この例ではデフォルトのデータベースを使用しています。 図 10: AWS Glue データベースの選択 Next  を選択します。 Create を選択します。 クロールを実行します。完了するのに約 2 分かかります。 ServiceNow の Parquet データは、Amazon S3 にインポートされました。 JSON ファイルの変換 このセクションでは、AWS Glue ジョブを設定して parquet ファイルを AWS IoT SiteWise に適した JSON 形式に変換し、データを AWS IoT SiteWise にインポートします AWS Glue ジョブを作成 AWS Glue コンソールに移動します。 左側のメニューから、 ETL Jobs  の下にある  Visual ETL を選択します。 Create Job で、  Visual ETL  を選択します。 図 11: AWS Glue Studio Source ノードを作成します。青い プラス (+) ボタンを選択し (図 12 参照)、 Amazon S3  を選択してください。 図 12: Visual ETL Name  では、図 13 のようにノードの名前を任意につけてください。ここでは cmdb_ot_entity とします。 S3 source type  では、  Data Catalog table  を選択してください。 Database  では、前に AWS Glue Crawler のセットアップ時に選択したターゲットデータベースを選んでください。 Table  では、最初の表 cmbd_ot_entity を選択してください。この手順を cmdb_ci_ot と cmdb_ot_entity_type の各テーブルについて繰り返してください 。  図 13: ソースノードの追加 アセットを AWS IoT SiteWise のインポート形式にマップする 図 12 に示されている青い「+」ボタンを選択して、新しい Source ノードを作成してください。 Transform ノードを追加し、 SQL Query を選択してください。 Name には「 assets」 を使用してください。 Node parents には、ソースノード cmdb_ot_entity と cmdb_ci_ot を選択してください。。 Input sources と SQL Aliases には、図 14 に示すように、それぞれ cmdb_ot_entity と cmdb_ci_ot を選択してください。 図 14: アセットの変換 SQL Query に次のクエリをコピー & ペーストしてください。 SELECT DISTINCT parent.sys_id as assetExternalId, parent.name as assetName, parent.ot_asset_type as assetModelExternalId, COLLECT_LIST( CASE WHEN child.sys_id IS NOT NULL THEN STRUCT( array_join(array(parent.ot_asset_type, child.ot_asset_type), '-') as externalId, child.sys_id as childAssetExternalId ) END ) as assetHierarchies, ( CASE WHEN ot.sys_id IS NOT NULL THEN array( STRUCT('name' as externalId, ot.name as attributeValue), STRUCT('serial_number' as externalId, ot.serial_number as attributeValue), STRUCT('manufacturer' as externalId, ot.manufacturer as attributeValue), STRUCT('model_number' as externalId, ot.model_number as attributeValue), STRUCT('firmware_version' as externalId, ot.firmware_version as attributeValue), STRUCT('hardware_version' as externalId, ot.hardware_version as attributeValue), STRUCT('asset_tag' as externalId, ot.asset_tag as attributeValue), STRUCT('category' as externalId, ot.category as attributeValue), STRUCT('environment' as externalId, ot.environment as attributeValue), STRUCT('short_description' as externalId, ot.short_description as attributeValue) ) ELSE array() END ) as assetProperties FROM cmdb_ot_entity as parent LEFT JOIN cmdb_ci_ot as ot ON parent.ot_asset = ot.sys_id LEFT JOIN cmdb_ot_entity as child ON parent.sys_id = child.parent GROUP BY parent.sys_id, parent.name, parent.ot_asset_type, ot.sys_id, ot.name, ot.serial_number, ot.manufacturer, ot.model_number, ot.firmware_version, ot.hardware_version, ot.asset_tag, ot.category, ot.environment, ot.short_description asset model をマッピングする 図 12 に示されている青い「+」ボタンを選択して、新しい Source ノードを作成します。 新しい Transform ノードを追加し、 SQL Query を選択します。 Name には「 assetModels 」を使用します。 Node Parents では、ソースノード cmdb_ot_entity_type を選択します。 Input sources と SQL Aliases では、図 15 に示されているように、それぞれ cmdb_ot_entity_type を使用します。 図 15: assetModel 変換 SQL Query に次のクエリをコピー & ペーストしてください。 SELECT DISTINCT parent.sys_id as assetModelExternalId, parent.label as assetModelName, ( CASE WHEN parent.ot_table IS NOT NULL THEN from_json( '[{"dataType":"STRING","externalId":"name","name":"Name","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"serial_number","name":"Serial Number","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"manufacturer","name":"Manufacturer","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"model_number","name":"Model Number","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"firmware_version","name":"Firmware Version","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"hardware_version","name":"Hardware Version","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"asset_tag","name":"Asset Tag","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"category","name":"Category","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"environment","name":"Environment","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"short_description","name":"Short Description","type":{"attribute":{"defaultValue":"-"}},"unit":"-"}]', 'array<struct<dataType:string,externalId:string,name:string,type:struct<attribute:struct<defaultValue:string>>,unit:string>>' ) ELSE array() END ) as assetModelProperties, COLLECT_LIST( CASE WHEN child.sys_id IS NOT NULL THEN STRUCT( array_join(array(parent.sys_id, child.sys_id), '-') as externalId, child.name as name, child.sys_id as childAssetModelExternalId ) END ) as assetModelHierarchies FROM cmdb_ot_entity_type as parent LEFT JOIN cmdb_ot_entity_type as child ON parent.sys_id = child.parent_type GROUP BY parent.sys_id, parent.name, parent.label, parent.ot_table assetsと asset model を組み合わせる 図 12 に示されているように、青色の 「+」 ボタンを選択して新しい Source ノードを作成します。 新しい Transform ノードを追加し、 SQL Query を選択します。 Name には 「assetModelHierarchy」  を使用します。 Node parents には、Source ノード assets と assetModels を選択します。 Input sources と SQL aliases には、図 16 のように assets と assetModels を使用します。 図 16: assetModelHierarchy 変換 SQL Query に次のクエリをコピー & ペーストしてください。 SELECT ( SELECT COLLECT_LIST(STRUCT(assetModels.*)) as assetModels FROM assetModels ) as assetModels, ( SELECT COLLECT_LIST(STRUCT(assets.*)) as assets FROM assets ) as assets AWS Glue ジョブ の結果を AWS IoT SiteWise にインポートするために使用するよう、変換のターゲットを追加しましょう。 変換のターゲットを追加する 図 12 に示されている青い 「+」 ボタンを選択して、新しいソースノードを作成します。 新しいノード Transform を追加し、ターゲットから Amazon S3 を選択します。 Name は何でも構いません。この例では Amazon S3 を使用しています。 Node Parents  は、ソースノード assetModelHierarchy を選択します。 Format  は JSON を選択します。 Compression Type は None を選択します。 S3 Target Location  は <your_destination_bucket>  を選択します。 図 17: ターゲットノードの追加 完了すると、図 18 に示すような ETL を確認できるはずです。 Save を選択してください。 それから Run を選択し、完了するまで待ちます。 図 18: アセットの階層 AWS IoT SiteWise への取り込み このセクションでは、Amazon S3 内の JSON ファイルの作成を確認し、AWS IoT SiteWise に ServiceNow のアセットをインポートします。 まず、次の操作を行って JSON ファイルが作成されたことを確認します。  Amazon S3 コンソールを開きます。 <your_destination_bucket> を選択します。 run-<timestamp>-part-r-00000  ファイルを選択後、 アクション をクリック。 オブジェクトの名前変更を選択し、 sitewise-import.json に変更する。AWS IoT SiteWise にインポートするためには、ファイル名に .json の拡張子を付ける必要があります。 AWS IoT SiteWise にインポートするには、AWS IoT SiteWise コンソールを開きます。 ナビゲーションペインで Bulk Operations を選択します。 New Import を選択します。 図 19: AWS IoT SiteWise bulk operations Import metadata からS3 URI に <your_destination_bucket> を選択し sitewise-import.json ファイルを指定します。 図 20: S3 import Import  を選択し、インポートが完了するまで待ちます。 作業の検証 図 21 に示されているように、さまざまなモデルとモデルプロパティを表示できるようになりました。また、図 22、23、24 に示されているように、さまざまなアセットとアセットプロパティも表示できます。あなたの ServiceNow 階層が AWS IoT SiteWise に正常に複製されました。 図 21: AWS IoT SiteWise モデル 図 22: AWS IoT SiteWise のモデルプロパティ 図 23: AWS IoT SiteWise アセット 図 24: AWS IoT SiteWise のアセットプロパティ クリーンアップ このブログで説明した作業をクリーンアップするには、Amazon AppFlow コンソールに移動し、フローと ServiceNow コネクタを削除します。ServiceNow で作成したユーザーとユーザー認証情報を削除します。AWS Glue では、Crawler 、ジョブ、AWS Glue データカタログからテーブルを削除します。AWS IoT SiteWise からアセットとアセットモデルを削除します。最後に、Amazon S3 バケットからParquetと JSON 形式のファイルの両方を削除します。 まとめ このブログでは、ServiceNow のアセットデータと AWS IoT SiteWise を統合するプロセスを紹介しました。 このプラクティスにより、組織は IT と OT のアセット管理ソリューション間で一貫したアセット情報を保持できます。 この統合を完全に自動化するには、Amazon AppFlow のフローに定期的に実行するようにスケジューリングし、AWS Glue ジョブにスケジュールのトリガーを設定します。 AWS Glue ジョブを設定する際、ETL スクリプト経由で出力ファイルに ‘.json’ 拡張子を付与することもできます。 これらの 2 つのソリューションにより、手動でのデータ入力を排除し、IT システムと OT システム間の整合性が保たれます。 AWS IoT SiteWise の詳細を知りたい場合は、 AWS IoT SiteWise Developer Guide  をご覧ください。 この記事は Mariaと Brent によって書かれた  Integrating ServiceNow OT Asset Workspaces with AWS IoT SiteWise Asset Models  の日本語訳です。この記事はソリューションアーキテクトの服部が翻訳しました。 About the authors Maria El Khoury : AWS のソリューションアーキテクト。製造業のデジタルトランスフォーメーションを支援し、IoT やコンピュータビジョンの経験を活かし、産業用 IoT やサプライチェーン分野への AWS 適用に注力。 Brent Van Wynsberge : AWS のソリューションアーキテクト。エンタープライズ顧客のクラウド導入を支援し、 IoT や DevOps 、データ分析、コンテナ技術にも関心を持つ。 Kazunari Hattori 自動車業界担当のソリューションアーキテクト。CCoE 立ち上げや工場 IoT の導入、クラウド活用の推進に注力。AWS の IoT の技術コミュニティに所属。 第二種電気工事士。今春キャンピングカーをレンタルして秩父にキャンプに行きました。

このブログは 2024 年 9 月 11 日 に Roberto Moreno、 Jeremy Schiefer によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 この投稿では、 AWS Private CA Connector for Active Directory が、 Amazon AppStream 2.0 および Amazon WorkSpaces の証明書ベースの認証（CBA）の構成をどのように簡素化し、加速するかについて説明します。このコンテキストにおける AWS Private Certificate Authority と Active Directory Certificate Service の概要を提供します。Active Directory Certificate Service の代替としてAWS Private CA を使用する利点について説明し、構成手順を含めています。 SAML 2.0 アイデンティティプロバイダー (IdP) を AppStream 2.0 または Amazon WorkSpaces で使用している場合、CBA を使用してログインユーザーエクスペリエンスを向上させることができます。CBA は Active Directory ドメインパスワードのユーザープロンプトを排除します。これにより、SAML 2.0 IdP から AppStream 2.0 インスタンスまたは Amazon WorkSpaces へのシングルサインオンが可能になります。CBA の詳細については、「 WorkSpaces 用の CBA の構成方法 」および「 AppStream 2.0 用の CBA の構成方法 」をご覧ください。 概要 AWS Private CA と Active Directory 証明書サービスの役割 AppStream 2.0 および WorkSpaces でのCBAは、ユーザー証明書と仮想スマートカードの組み合わせに依存しています。これにより、Active Directory ドメインのメンバーである Windows マシンへのパスワードレス認証が可能になります。これを実現するために必要な重要なインフラストラクチャコンポーネントは2つあります。 AWS Private CA は、ユーザー証明書の発行と管理に使用されます。AppStream 2.0 と WorkSpaces サービスは、セッション認証プロセス中に AWS Private CA からユーザー証明書を自動的に要求します。その後、証明書がプロビジョニングされた仮想スマートカードを使用して、ユーザーは Active Directory に対して認証されます。AWS Private CA は、必要な CA 階層に応じて、証明書チェーンのルート CA または下位 CA として使用できます。 Active Directory Certificate Service (AD CS) は、Active Directory ドメインで仮想スマートカードログインを可能にするものです。具体的には、Active Directory Certificate Service は公開鍵基盤 (PKI) を提供し、Active Directory integrated Certificate Authority (またはエンタープライズCA) も含まれています。証明機関は、ドメインコントローラー証明書の発行と管理に使用されます。これらの証明書により、Key Distribution Center (KDC) は、CBA や仮想スマートカードログインに必要なドメインの他のメンバーに対して自身の ID を証明することができます。 DC / Kerberos 証明書は、AD CS での証明書自動登録を通じて、すべてのドメインコントローラーに自動的に発行およびインストールされます。 AWS Private CA は、AD CS ルート CA に対する下位 CA として構成されています。AWS Private CA 証明書は、その後手動で AD RootCA および NTAuthCA ストアに公開されます。 CA 証明書チェーンは、AD を介してすべてのドメインマシンに自動的に複製されます。 ユーザーは SAML 2.0 プロバイダーで認証されます。 フェデレーションユーザーは AppStream 2.0 / WorkSpaces リソースへのアクセスが許可されます。 SAML アサーションの属性に基づいて、WorkSpaces / AppStream2.0 には AWS プライベート CA によって署名されたユーザー証明書が発行されます。 AppStream 2.0 / WorkSpaces サービスは、ユーザー証明書を Windows マシンに公開されます。 AppStream 2.0 / WorkSpaces エージェントは、ユーザー証明書を使用して Active Directory にユーザーをシームレスに認証されます。 Active Directory 証明書サービスの代替としての AWS Private CA Connector for AD AD 用コネクタにより、AWS Private CA は Active Directory 統合エンタープライズ CA の役割を担うことができます。これは Active Directory Certificate Services をデプロイして、Active Directory 内のマシンに必要な証明書テンプレートと登録サービスを提供します。このアプローチにより、Active Directory Certificate Services のインフラストラクチャをデプロイする必要がなくなり、実装の労力が大幅に簡素化されます。また、運用オーバーヘッドを削減し、CA の秘密鍵が FIPS 140-2 レベル 3 認定のハードウェアセキュリティモジュール (HSM) に保存されることでセキュリティが向上します。 AWS Private CA を設定、コネクタを介して AD と統合されています。エンタープライズ CA として、その CA 証明書は自動的に AD RootCA および NTAuthCA ストアに公開されます。DC / Kerberos 証明書は、AWS Private CA による証明書自動登録を通じて、ドメインコントローラーに自動的に発行およびインストールされます。 CA 証明書チェーンは、AD を介してすべてのドメインマシンに自動的に複製されます。 ユーザーは SAML プロバイダーで認証されます。 フェデレーションユーザーは AppStream 2.0 / WorkSpaces リソースへのアクセスが許可されます。 SAML アサーションの属性に基づいて、AppStream 2.0 / WorkSpaces には AWS Private CA によって署名されたユーザー証明書が発行されます。 AppStream 2.0 / WorkSpaces サービスは、ユーザー証明書を Windows マシンに公開します。 AppStream 2.0 / WorkSpaces エージェントは、ユーザー証明書を使用して Active Directory にユーザーをシームレスに認証します。 Walkthrough このウォークスルーでは、 AWS Private CA 、 Active Directory 用の AWS Private CA コネクタ、および AppStream 2.0 または WorkSpaces の証明書ベースの認証を設定します。 前提条件 使用する AWS サービスのコマンドを実行するために必要な IAM 権限を持つ AWS コンソール。 SAML 2.0 ID プロバイダーと統合された機能的な AppStream 2.0 または WorkSpaces のデプロイメント SAML アサーションで https://aws.amazon.com/SAML/Attributes/PrincipalTag:UserPrincipalName 属性を設定します。この属性は CBA に必要であり、Active Directory の ユーザープリンシパル名 （UPN）にマッピングする必要があります。詳細については、「 SAML 認証レスポンスのアサーションを作成する 」を参照してください。 SAML 2.0 設定で使用する IAM ロール信頼ポリシーに、まだ存在しない場合は、 sts:TagSession 権限を追加してください。この権限は証明書ベースの認証を使用するために必要です。詳細については、「 SAML 2.0 フェデレーション IAM ロールを作成する 」を参照してください。 セルフマネージド Active Directory AWS Managed Microsoft AD はサポートされていません。 AWS Directory Service AD Connector WorkSpaces ディレクトリで構成された既存のコネクタを使用するか、この目的のために新しいコネクタを作成することができます。 注： Active Directory サービスアカウントには、以下の「ステップ3： AD 用 PCA コネクタの作成」に記載されている 追加の権限 が必要になります。 ニーズに基づいて認証局 (CA) 階層を計画・設計する 注: このブログに含まれる構成手順は、簡略化のために1レベルの CA 階層を想定しています。単一の AWS Private CA インスタンスが 有効期限の短い証明書 でデプロイされ、ルート CA として機能し、証明書を発行します。 本番環境にデプロイする際、個別の管理制御と完全な信頼チェーンが必要な場合は、 AWS Private CA のドキュメント を参照してください。 有効期限の短い証明書 は、特に AppStream 2.0 および WorkSpaces CBA での使用が推奨されています。 設定手順 ステップ1：証明書失効リスト（CRL）をホストするための公開リポジトリを作成する   Amazon Simple Storage Service (Amazon S3) バケットを作成して ACL を無効に設定し、すべてのパブリックアクセスをブロックします。 CloudFront ディストリビューションを作成します： Amazon CloudFront コンソールに移動します。 ディストリビューションを作成します。 オリジンドメインには、最初のステップで指定したオリジンドメインとして作成された S3 バケットを選択してください。 オリジンアクセスには、オリジンアクセスコントロール設定（推奨）を選択してください。 コントロール設定の作成を選択してください。 ディストリビューションを作成します。 S3 バケットポリシーを作成します： Amazon S3 コンソール に移動します。 このステップの最初に作成した S3 バケットを選択してください。 アクセス許可タブを選択します。 バケットポリシーを選択し、編集を選択します。 次のように入力してください。 S3-BUCKET-NAME 、 AWS-ACCOUNT-NUMBER 、および CLOUDFRONT-DISTRIBUTION をあなたの値に置き換えてください。その後、保存を選択します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "acm-pca.amazonaws.com" }, "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::S3-BUCKET-NAME/*", "arn:aws:s3:::S3-BUCKET-NAME" ], "Condition": { "StringEquals": { "aws:SourceAccount": "AWS-ACCOUNT-NUMBER" } } }, { "Sid": "AllowCloudFrontServicePrincipal", "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::S3-BUCKET-NAME/*", "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::AWS-ACCOUNT-NUMBER:distribution/CLOUDFRONT-DISTRIBUTION" } } } ] } ステップ2：AWS Private CA を作成する ca_config.txt ファイルを作成し、以下の情報でフォーマットして、太字の情報をあなたの組織の情報に置き換えてください： { "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Country":"YOUR-COUNTRY", "Organization":"YOUR-ORG", "OrganizationalUnit":"YOUR-OU", "State":"YOUR-STATE", "Locality":"YOUR-LOCALITY", "CommonName":"CA-NAME" } } revoke_config.txt ファイルを作成し、以下の情報でフォーマットしてください。太字のプレースホルダーを置き換えてください 注意： CustomCnameにHTTPS を含めないようにしてください。 { "CrlConfiguration":{ "Enabled":true, "ExpirationInDays":7, "S3BucketName":"YOUR-S3-BUCKET-NAME", "S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL", "CustomCname":"CLOUDFRONT-DISTRIBUTION-FQDN" } } 短期間のルート AWS プライベート CA を作成するには、次の AWS CLI コマンドを入力してください。ターミナル環境として AWS CloudShell を使用することができます。 注意：これらの値は必須であり、変更してはいけません。コマンドを実行する前に、 ca_config.txt と revoke_config.txt ファイルを AWS CloudShell にアップロードしてください。 aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=euc-private-ca,Value= \ --usage-mode SHORT_LIVED_CERTIFICATE ステップ3：AD の PCA コネクタを作成する AWS マネジメントコンソールを使用してコネクタを作成および設定するには、次の手順に従ってください。 AWS CLI create-connector コマンドまたは CreateConnector API アクションを使用することもできます。 AWS Private CA Connector for Active Directory コンソールに移動します。 初回サービスのランディングページまたは Active Directory 用コネクタのページで、[コネクタの作成]を選択します。 「Select your Active Directory type」の下で、「On-premises Active Directory with AWS AD Connector」を選択します。 「ディレクトリを選択」の下で、リストからあなたのディレクトリを選択してください。 VPC エンドポイントのセキュリティグループを選択で、リストからセキュリティグループを選択するか、新しいセキュリティグループを作成します。 前提条件では、PowerShell スクリプトをダウンロードして実行し、サービスアカウントに権限を委任してください。必要な権限の詳細については、 前提条件 を参照してください。 プライベート認証局セクションで、リストからプライベート CA を選択してください。 必要な情報を提供して選択内容を確認した後、[コネクタの作成] を選択します。これにより、Active Directory 用コネクタの詳細ページが開き、コネクタの作成進行状況を確認できます。 証明書登録ポリシーサーバーのエンドポイント URL を記録してください。これは以下のステップ4で使用します。 ステップ4：Active Directory ポリシーを構成する グループポリシーは、ドメインコントローラーの証明書自動登録設定を構成するために使用され、AWS Private CA Connector エンドポイントに到達するための URL も含まれます。AWS Private CA のドキュメントに記載されている グループポリシーの設定手順 に従ってください。 ステップ5：証明書テンプレートを作成する PCA コネクタには、AD アプリケーションに使用される一般的な証明書テンプレートが含まれています。Kerberos 認証証明書テンプレートは、仮想スマートカードと CBA ログオンを許可するドメインコントローラー向けの最新の証明書テンプレートです。 AWS Private CA Connector for Active Directory コンソールに移動します。 Active Directory のコネクタリストから作成したコネクタを選択し、[詳細を表示] を選択します。 コネクタの詳細ページで、テンプレートセクションを見つけ、「テンプレートの作成」を選択します。 テンプレート作成ページで、テンプレート作成方法セクションにて、定義済みテンプレートから開始（デフォルト）を選択し、リストから Kerberos 認証を選んでください。 テンプレート設定セクションで、以下の情報を提供してください： テンプレート名：Kerberos 認証 テンプレートスキーマバージョン：テンプレートバージョン2 クライアント互換性: Windows 8以降 / Windows Server 2016 以降 証明書設定セクションでは、デフォルト設定を使用します。 注意：AWS Private CA を 有効期間の短い証明書 で使用する場合、有効期間と更新期間を一致させるように設定する必要があります。 有効期間：7日間 更新期間：1日 グループとアクセス許可のセクションで、「新しいグループとアクセス許可を追加」をクリックして、必要なグループと登録設定を必要に応じて構成します。以下の例では、特定のドメイン内のすべてのドメインコントローラーが AWS Private CA から証明書をリクエストすることを許可しています。注：セキュリティ識別子（SID）の値はドメインに固有です。ドメインコントローラーで PowerShell コマンド Get-ADGroup -Identity “Domain Controllers” を実行して SID を取得できます。 表示名: ドメインコントローラー セキュリティ識別子: S-1-5-##-##########-##########-##########-516 登録：許可 自動登録：許可 他のすべてのセクションにはデフォルト設定を使用してください。 テンプレートを作成を選択してください。 ステップ6：AWS Private CA と Active Directory の統合を検証する 新しいコネクタが作成されると、Active Directory に AWS Private CA 用の新しい certificationAuthority オブジェクトが作成されます。 Active Directory サイトとサービスの管理コンソールを開きます。 表示メニューで、サービスノードの表示を選択します。 サービスを展開し、公開鍵サービスを展開してから、証明機関を選択します AWS PCA のオブジェクトが acm-pca-ID として表示されることを確認してください。 PCA ルート証明書はドメインの信頼されたルート証明機関に追加されます。 ドメイン参加済みのマシンで、ローカルコンピュータ用の証明書管理コンソール（certlm.msc）を開きます。 信頼されたルート証明機関を展開して証明書を選択してください 共通名に基づいて AWS PCA 証明書を見つけて開きます。 認証パスタブを選択し、証明書のステータスが「この証明書は問題ありません」であることを確認します。 ドメインコントローラー証明書は自動登録によってインストールされます。 ドメインコントローラーでローカルコンピューターの証明書管理コンソールを開きます。 個人を展開して証明書を選択してください ドメインコントローラーの FQDN に基づいて証明書を特定し、それが AWS PCA によって発行され、Kerberos 認証テンプレートを使用していることを確認します。 証明書を開き、証明書パスタブを選択し、証明書のステータスが「この証明書は正常です」であることを確認します。 注意：証明書の自動登録は、ドメインレプリケーション、グループポリシー、その他のプロセスなどの様々な要因に基づいて時間がかかります。場合によっては、8時間以上かかることがあります。 ステップ7：WorkSpaces または AppStream 2.0 の CBA を有効にする AWS Private CA が Active Directory ドメイン内のエンタープライズ CA になった今、 AppStream 2.0 または WorkSpaces で証明書ベースの認証を有効にするための管理ガイドに従ってください。 AWS CloudTrail は、AppStream 2.0 または WorkSpaces サービスが AWS Private CA からユーザー証明書をリクエストしていることを確認するために使用されます。 CloudTrail のイベント履歴 では、EcmAssumeRoleSession ユーザー名によって行われた acm-pca.amazonaws.com イベントソースからの GetCertificate および IssueCertificate イベント名を確認できます。これらのイベントは、WorkSpaces または AppStream 2.0 の証明書ベースの認証リクエストごとに記録されます。 クリーンアップ このブログに従って作成したリソースが不要になった場合は、以下の手順に従ってください。 AppStream 2.0 または WorkSpaces コンソールで、ディレクトリ設定の証明書ベースの認証を無効にします。 AWS Private CA Connector for Active Directory コンソール で、ステップ3で作成されたコネクタを削除します。 ステップ4で作成された Active Directory の GPO を削除します。 ドメインコントローラーに発行された PCA 上の証明書を取り消し ます。 ドメインコントローラーにインストールされた AWS Private CA によって発行された証明書を削除します。 Active Directory から certificationAuthority オブジェクトを削除 します。 AWS Private CA コンソール で、ステップ2で作成した プライベート認証局を削除 します。 CloudFront コンソール で、ステップ 1 で作成した CloudFront ディストリビューションを削除 します。 S3コンソールで、ステップ1で作成した S3 バケットを削除してください。 まとめ この投稿では、AWS Private CA Connector for Active Directory を使用して、AppStream 2.0 および WorkSpaces での CBA 設定を簡素化する方法について学びました。このユースケースでコネクタを使用する主な利点は、Active Directory 証明書サービスの展開と管理を回避できることです。 ブログで言及されているサービスについて詳しく知るには、 AD 用コネクタ 、 AWS Private CA 、 CA のベストプラクティス 、および AWS Directory Services のドキュメント を参照してください。AWS Management Console を使用して、AWS Private CA で CA の作成を始めることができます。

コンタクトセンター運営における包括的な監査証跡の取得と一元的な可視性の維持は、セキュリティ、コンプライアンス、および運用のベストプラクティスの観点で重要です。以前のブログ記事「 AWS CloudTrail と Amazon Athena による組織内の Amazon Connect API アクティビティの調査 」では、お客様が AWS CloudTrail と Amazon Athena を活用して、Amazon Connect のコンタクトセンター環境の中で行われる様々な API 呼び出しの可視性と監査可能性を実現する方法について説明しました。これは、組織がコンタクトセンター運営の監視および調査をできるようにするための重要な第一歩でした。 Amazon Connect は、さらに一歩進んだ AWS CloudTrail サポートとして、 Amazon Connect コンソールのフロー管理ページのアクティビティに対応 しました。これは、ユーザーがフローを追加、更新、または削除するたびに、そのアクティビティの記録が CloudTrail ログに取得されることを意味します。この新機能により、コンタクトセンターチームはさらなる可視性、レポーティング、およびコンプライアンスの利点を得ることができます。 この続編となるブログ記事では、お客様が AWS 環境全体で Amazon Connect のフロー管理のアクティビティを一元的に分析および監査する方法について、より詳しく説明します。AWS CloudTrail と Amazon Athena の機能を組み合わせることで、組織は以下のような重要な質問に答えることができます： この重要なフローを最後に更新したのは誰ですか？ このフローが最後に保存または削除されたのはいつですか？ 様々な AWS アカウントとリージョンで、どのようなフロー管理のアクティビティが発生していますか？ ソリューションの概要 新しく Amazon Connect のフロー管理が CloudTrail に対応したことにより、組織は複数のアカウントとリージョンを横断し、アクティビティを一元的に監査できます。詳細な記録を取得することで、顧客はフローに対して誰が、いつ、どこから変更を加えたかを追跡できます。CloudTrail ログの有効化は良い第一歩ですが、複数の AWS アカウントとリージョンにわたる環境を管理する場合、記録だけでは不十分です。組織は Amazon Athena を使用して CloudTrail ログをクエリし、 AWS Organization 全体にわたるフローマネジメントのアクティビティを分析できます。 前提条件 Amazon Conenct パブリック API の基本的な理解 AWS CloudTrail で 組織の証跡 を作成できること ユースケース 1. フローのライフサイクル管理の監査 シナリオ: コンタクトセンター運用チームは、時間の経過とともに行われる、フローの作成、変更、削除を追跡したいと考えています。 ソリューション: CloudTrail ログにより、CreateContactFlow や DeleteContactFlow などのフローのライフサイクルイベントを追跡、記録します。 Athena を使用して Amazon S3 に保存された CloudTrail ログを参照することで、フローのライフサイクルイベントの包括的なビューを得ることができます。手順は以下の通りです： Athena コンソールに移動し、クエリエディタを選択します。右側のペインで、クエリエディタを使用してクエリを入力し実行します。 特定の時間以降に作成されたすべてのフローとその作成者を確認するには、クエリエディタで以下のクエリを実行します： (訳注: クエリ最後の ‘2024-06-26 00:00:00’ を監査対象となる期間の開始時間に移動することをお勧めします) SELECT json_extract_scalar(responseelements, '$.ContactFlowId') as ContactFlowId, json_extract_scalar(requestparameters, '$.InstanceId') as InstanceId, userIdentity.arn, eventtime FROM "default"."cloudtrail_logs" WHERE userIdentity.arn IS NOT NULL AND eventName='CreateContactFlow' AND eventTime > '2024-06-26 00:00:00’ クエリ結果には、対応するフローを作成したユーザーの Amazon Resource Names (ARNs) と、その時刻が表示されます。 図 1: フローのライフサイクル管理監査のクエリ結果 結果の ARN フィールドから Amazon Connect の一意のユーザー ID(UUID) を取得できるようになりました。UUID は上の画像のように、ARN の最後のセグメントにあります。これらのユーザー ID を使用して、 DescribeUser API を呼び出すことでユーザーに関する情報を取得できます。 これを行うため、AWS Management Console に移動し、検索ボックスに CloudShell と入力して CloudShell を選択し、 AWS CloudShell を起動します。 図 2: CloudShell サービスへのアクセス CloudShell ターミナル内で DescribeUser API を呼び出すことで、Amazon Connect のユーザー詳細を確認できます。 aws connect describe-user --user-id <ユーザー ID に置き換え> --instance-id <インスタンス ID に置き換え> 図 3: describe-user のクエリ結果 2. 重要なフローへの不正な変更の検出 シナリオ: コンタクトセンターのマネージャーが、特定のフローを更新したユーザーを特定したいと考えています ソリューション: 不正な更新を行ったユーザー、時間、詳細を以下の方法で特定します Athena コンソールに移動し、クエリエディタを選択します。右側のペインで、クエリエディタを使用してクエリを入力し実行します。 特定のフローを更新したユーザーを特定するために、以下のクエリをクエリエディタで実行します。 (訳注: クエリ最後の ‘2024-06-26 00:00:00’ を監査対象となる期間の開始時間に移動することをお勧めします) SELECT json_extract_scalar(requestparameters, '$.InstanceId') as InstanceId, json_extract_scalar(requestparameters, '$.ContactFlowId') as ContactFlowId, userIdentity.arn, eventTimeFROM "default"."cloudtrail_logs" WHERE userIdentity.arn IS NOT NULL AND eventName='UpdateContactFlowContent' AND eventTime > '2024-06-26 00:00:00' クエリ結果には、インスタンス ID とともに、対応するフローを更新したユーザーの Amazon Resource Name (ARN) が表示されます。 図 4: 重要なフローへの不正な変更のクエリ結果 ARN のカラムには、ユーザー ID が長い文字列として表示されます。上記の結果に示されているように、ARN フィールドから Amazon Connect の一意のユーザー ID（UUID）を取得できます。UUID は ARN の最後のセグメントにあります。 これらのユーザー ID を使用して、 DescribeUser API を呼び出すことでユーザーに関する情報を取得できます。 Amazon Connect のユーザー詳細を確認するには、CloudShell ターミナルに移動し、以下のコマンドを実行します。 aws connect describe-user --user-id <ユーザー ID に置き換え> --instance-id <インスタンス ID に置き換え> 図 5: describe-user のクエリ結果 3. フローと電話番号の関連付けの調査 シナリオ: コンタクトセンターのマネージャーは、どの電話番号がどのフローに関連付けられているか、およびこれらの関連付けの変更を追跡したいと考えています ソリューション: CloudTrail ログで AssociatePhoneNumberContactFlow API コールを使用して、これらのフローと電話番号のマッピングを監視および監査します。手順は以下の通りです : Athena コンソールに移動し、クエリエディタを選択します。右側のペインで、クエリエディタを使用してクエリを入力し実行します。 どの電話番号がどのフローに関連付けられているかを確認するには、クエリエディタで以下のクエリを実行します。 (訳注: クエリ最後の ‘2024-06-26 00:00:00’ を監査対象となる期間の開始時間に移動することをお勧めします) SELECT json_extract_scalar(requestparameters, '$.InstanceId') as InstanceId, json_extract_scalar(requestparameters, '$.PhoneNumberId') as PhoneNumberId, userIdentity.arn, eventTimeFROM "default"."cloudtrail_logs" WHERE userIdentity.arn IS NOT NULL AND eventName='AssociatePhoneNumberContactFlow'AND eventTime > '2024-06-26 00:00:00' 上記のクエリの結果は、インスタンス ID 内に関連付けられた電話番号 ID と、フローの変更を行ったユーザーの ARN を提供します。（前のセクションと同様） 図 6：フローと電話番号の関連付けを調査するためのクエリ結果 PhoneNumberId がどの電話番号に対応しているかを確認するには、CloudShell ターミナルに移動し、以下のコマンドを実行します。 aws connect describe-phone-number --phone-number-id <PhoneNumberIdで置き換え> 図 7：describe-phone-number のクエリ結果 まとめ このブログ記事では、新しくサポートされた AWS CloudTrail による Amazon Connect フロー管理ページの証跡が、組織のコンタクトセンター運用の一元的な分析と監査にどのように役立つかを探りました。CloudTrail と Amazon Athena の強力な組み合わせを活用することで、顧客は重要なフローに対する変更を誰が行い、いつ変更が行われ、どの AWS アカウントまたはリージョンから行われたかについて、いままでになかった可視性と監査可能性を得ることができます。 この記事全体を通じて、この一元化された監査ソリューションの価値を示すいくつかの重要なユースケースを取り上げました。 フローのライフサイクル管理の監査: CloudTrail ログを参照することで、組織はフローの作成、変更、削除を含むライフサイクルを完全に追跡できます。これにより、コンタクトセンター運用チームに価値ある洞察を提供します。 重要なフローへの不正な変更の検出: 顧客が CloudTrail と Athena を使用して、機密な顧客データを扱うフローへの不正な更新を誰が行ったかを調査する方法を示し、コンタクトセンターのセキュリティとコンプライアンスの確保を支援します。 フローと電話番号の関連付けの調査: 顧客は CloudTrail で記録された追加の API コールを活用して、フローと電話番号間のマッピングなどの重要な関連付けを監視および監査し、これらの関連付けが適切に管理されていることを確認できます。 AWS 環境全体で Amazon Connect フロー管理のアクティビティを一元的に分析する機能により、組織はコンタクトセンター運用の可視性、セキュリティ、およびコンプライアンスを大幅に改善できます。このブログ記事で説明したガイダンスによって、お客様はこの強力な監査ソリューションを迅速に実装し、より適切な意思決定を行い、顧客により良いサービスを提供するために必要な洞察を得ることができます。 筆者について Guy Bachar Guy Bachar は、ニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。彼はキャピタルマーケットのお客様のクラウドへの移行を支援しています。ID管理、セキュリティ、ユニファイドコミュニケーションに情熱を注いでいます。 Pranjal Gururani Pranjal Gururani は、シアトルを拠点とする AWS のシニアソリューションアーキテクトです。Pranjal はさまざまなお客様とビジネス上の課題に対処するクラウドソリューションを構築しています。ハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。 Agasthi Kothurkar Agasthi Kothurkar は、ボストンを拠点とする AWS のプリンシパルソリューションアーキテクトです。Agasthi は、クラウドを採用してビジネスを変革する企業のお客様と協力して働いています。彼の専門分野は、クラウドネイティブアプリケーションアーキテクチャ、クラウドマイグレーション、IT 戦略、そして変革です。複雑な実世界のビジネス課題を解決するためにクラウドテクノロジーを適用することに情熱を注いでいます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

このブログは、2025 年 3 月 25 日に Marcelo Baptista、Lucia Maria de A. Drummond、Luan Teylo、Alan L. Nunes、Vinod Rebello、Cristina Boeres によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 大手総合エネルギー企業の一つである Petrobras は、複雑な課題に取り組み、新たな機会を切り拓くために、ハイパフォーマンスコンピューティング（HPC）の変革におけるポテンシャルを信じて、長年取り組んできました。同社は、地震データ処理、貯留層シミュレーション、その他の石油・ガス関連ワークロード向けに設計された強力な HPC インフラストラクチャに多額の投資を行ってきました。 これまで、Petrobras は主にオンプレミスソリューションを使用して HPC アプリケーションを実行していました。従来の HPC の制限を克服するため、 フルミネンセ連邦大学 （UFF）の Cloud+HPC ラボと共同で、オンプレミスとクラウドリソースを組み合わせたハイブリッドシステムを開発する研究プロジェクトを立ち上げました。 AWS ParallelCluster と Amazon EC2 スポットインスタンス を活用することで、Petrobras は事実上無制限のコンピューティングパワーを獲得し、複雑なシミュレーションの効率性を向上させ、可用性と最も重要な 生産性 を高めることができました。 本日は、これを可能にするために彼らが作成したフレームワーク Sim@Cloud について説明します。Petrobras はこれを使用して、パフォーマンスを最大限に維持しながら、43 % から 90 % のコスト削減を達成しました。Sim@Cloud は待ち時間を最小限に抑え、適切なインスタンスを選択し、インスタンスの稼働を管理します。 AWS の活用による待ち時間の最小化 需要がピークを迎える時期には、Petrobras はジョブ実行の長い待ち時間に直面していました。これはプロビジョニングにおけるよくあるジレンマですが、簡単にまとめると次の通りです。 オーバープロビジョニング: リソースがピーク需要に合わせてスケーリングされると、需要の低い期間に不必要な費用とエネルギーの無駄が発生します。 アンダープロビジョニング: リソースが十分にプロビジョニングされておらず、ピーク時の需要を満たせない場合、ジョブ実行の遅延が発生し、会社の意思決定に影響を与え、高度な資格を持つ高給の専門家の時間と生産性を妨げ、非効率による潜在的な財務損失をもたらす可能性があります。 このオーバープロビジョニングとアンダープロビジョニングのトレードオフは難しく、どちらの場合もリソースの無駄につながります。図 1 は、Petrobras の実際のデータを使用してこのシナリオを示しています。データは典型的な 1 週間の経過を示しており、オンプレミスのリソースは需要を満たしているものの、アイドル状態のリソースがあることがわかります。特定の日には、使用率が会社の計算能力の 100 % に達します。この時点（緑色の線で表示）で、ジョブがキューに入り、エンジニアのフラストレーションの原因となります（フラストレーションを抱えたエンジニアを見たことがありますか？私はあります）。 したがって、私たちは自問しなければなりません：これを管理する最も効果的な方法は何でしょうか？ 図 1 – Petrobras のオンプレミスインフラにおける 1 週間のジョブ実行状況。100 %（緑色の線）を超える曲線はピーク需要を表し、その結果、ワークロードがクラウドに手動でシフトされます（オレンジ色で表示）。 このような状況において、AWS のネイティブな弾力性が解決策を提供します。日常的なタスクにはオンプレミスリソースを割り当て、ピーク時の要求をクラウドに移行します。これはまさに Petrobras が UFF の Cloud+HPC ラボとのパートナーシップと Sim@Cloud によって実現していることです。 コストの検討 Petrobras のワークロードは通常、完了までに数日から数週間かかり、数百のコンピューティングノードを使用します。クラウドへの移行において彼らの主な懸念はコストでした。これに対処するため、Lúcia Drummond 教授が率いる UFF の Cloud+HPC ラボは、AWS で HPC ワークロードを実行するコストを最適化し削減することに焦点を当てたプロジェクトを立ち上げました。 プロジェクトの最初の 2 年間で、Petrobras はピーク需要期間中に AWS に移行する最初のワークロードとして CMG の貯留層シミュレーションを選択しました。このアプリケーションは、同社のワークロードの大部分を占め、ネイティブで軽量なチェックポイントとリスタート機能を備えていることが特徴です。 チェックポイントとリスタート機能により、エンドユーザーに対する透明性を確保しながら、Amazon EC2 スポットインスタンスを使用してコストを可能な限り低く抑えることができます。ユーザーの視点からは、シミュレーションのバッチを Slurm に送信して結果を待つプロセスは、オンプレミスで実行する場合も AWS Cloud で実行する場合も同じです。 1 人のユーザーのワークロードは、300 を超えるシミュレーションジョブで構成されることがあります。各ジョブは、一度に 100 以上のインスタンスを要求することがあります。適切なインスタンス、適切なタイミング、適切な AWS リージョンを見つけることが、HPC ワークロードを実行し、コストを最適化する鍵となります。 これらの課題を解決するために、プロジェクトは Sim@Cloud を開発しました。これは Slurm や BR-Kalman などの他の Petrobras 内部ツールとネイティブに統合されています。 Sim@Cloud Sim@Cloud は、シミュレーション実行に適したインスタンスと料金モデル（スポットまたはオンデマンド）の選択をサポートすることで課題に対処します。また、スポットインスタンスの中断を管理できるよう実行を監視します。 Sim@Cloud には、 Launcher と Execution Manager という 2 つの主要コンポーネントがあり、それぞれがシミュレーション実行中の特定の管理手順を担当します。フレームワークの動作を説明するために、図 2 はアーキテクチャとステップバイステップの実行例を示しています。 図 2 – Cloud+HPC ラボと Petrobras によって開発された Sim@Cloud フレームワークのアーキテクチャ まず、ユーザーはクラスタージョブスケジューラ（Slurm）にシミュレーションリクエストを送信します。ユーザーは、コア数、実行用のバッチファイル、出力ディレクトリなど、実行のためのパラメータを定義します。 これらのパラメータを使用して、Slurm はヘッドノードで Launcher を起動します。Launcher は、Slurm の機能のみに基づいてシミュレーションの実行時間を推定する機械学習コンポーネントである ML-Predictor を呼び出します。次に、Launcher は Instance-Selector モジュールを呼び出します。推定時間、アプリケーションの特性、チェックポイントのオーバーヘッドなどの環境要因を考慮して、シミュレーションタスクに最適な Amazon EC2 インスタンスタイプ、購入オプション、およびリージョンが決定されます。この決定により、シミュレーションジョブが Slurm に送信され、選択されたインスタンスが割り当てられ、ジョブが開始されます。 Execution Manager モジュールは、 Dynamic-Predictor モジュールを通じてシミュレーションの進行状況を監視します。シミュレータのログに基づいて残りの実行時間を予測します。この情報を使用して、EC2 がスポットインスタンスを中断した場合にシミュレーションを再開するための新しいインスタンスを選択します。 スポットインスタンスで実行する場合、Execution Manager は Checkpoint-Recorder モジュールを使用して定期的にチェックポイントを作成します。必要に応じて、このモジュールは利用可能な最新のチェックポイントからアプリケーションを再起動します。Execution Manager は AWS のインスタンスメタデータからスポットインスタンスの中断通知を受け取ります。中断通知は、スポットインスタンスが中断される 2 分前に送信されます。通知を受け取った後、Checkpoint-Recorder はシミュレーションの現在の進行状況を保存するための最終チェックポイントを開始します。スポットインスタンスが中断された場合、Instance-Selector は Dynamic-Predictor によって予測された残り時間を使用して、シミュレーションを再開するのに最適なインスタンスを決定します。 このプロセスはシミュレーションが完了するまで繰り返されます。Launcher は実行情報を History-Database（実行履歴データベース） に保存し、ユーザーに通知します。データベースには、AWS リージョン、購入オプション、インスタンスタイプ、価格履歴、シミュレーションの実行時間など、シミュレーション実行に関連する情報が保存されます。これにより、実行パフォーマンスとコストのさらなる評価が容易になります。 Sim@Cloud は中断の回数も制限しています。制限に達すると、利用可能なオンデマンドキャパシティを使用してジョブを再開します。 Sim@Cloud は、オンプレミスのクラスターで共有ファイルシステムを使用し、異なる AWS リージョンごとにキャッシュを使用します。Amazon FSx for NetApp ONTAP は、シミュレーションを実行可能な各 AWS リージョンをリンクします。このキャッシュアーキテクチャにより、データは別のリージョンにコピーされ、可用性が向上し、シミュレーションの実行に関連するデータへの迅速なアクセスが可能になります。これは、組織がプライマリデータのホスティング環境としてデータ主権要件を遵守するのにも役立ちます（例えば、ブラジル政府のクラウドサービスのデータ処理とセキュリティに関する規則の遵守など）。 実験結果 スポットインスタンスの中断に対する 2 分前の通知をシミュレートし、Sim@Cloud を使用した場合のコストと総実行時間における効果を調査しました。 AEMM（ AWS EC2 Metadata Mock ）を使用して、スポットインスタンスの中断をシミュレートする別のツールを開発しました。ポアソン分布を使用してインスタンスの中断時間を計算し、インスタンスのメタデータを更新して終了アラートを含め、スポットインスタンスをシャットダウンします。この離散確率分布は、スポットインスタンスの中断タイミングを含む、特定の期間内でのイベント発生を予測するのに適しています。 1 時間あたりの平均中断回数を表すパラメータ λ を使用してポアソン分布からサンプリングし、結果に 3,600 秒を掛けることで終了時間を決定し、τ をインスタンスの利用可能時間として定義します。このツールはインスタンスの稼働時間を追跡し、秒単位で終了アラートを生成します。 評価では、(λ) – 0.1, 0.5, 0.8, 1.0 の 4 つの中断頻度を考慮しました。λ 値が増加するにつれて、スポットインスタンスが早期に終了する確率も高くなり、λ = 1 の場合は最初の 1 時間以内にスポットインスタンスが中断される確率が高いことを示します。 テストでは、 プレソルト（Pre-salt） と呼ばれる 半合成貯留層（semisynthetic reservoir） シミュレーションモデルのワークロードを使用しました。これは、Petrobras によって探査されたブラジル沖合の複雑なプレソルト貯留層の代表的なワークロードです。時間と予算を節約するため、50 年ではなく 20 年のシミュレーションを実行するバージョンを作成しました。この記事の残りの部分では、これらのモデルをそれぞれ Pre-Salt および Short-Pre-Salt と呼びます。これらのモデルは、通常、合成貯留層シミュレータ CMG GEM を使用して本番環境でシミュレートされます。これにより、ブラジルのプレソルトの複雑さに対してより良い結果が得られます。しかし、この調査では、テストの目的に合わせて高速化するため、常に 40 スレッドを使用して CMG IMEX ブラックオイルシミュレータを使用してシミュレーションを実行することを選択しました。 Sim@Cloud は、SA-EAST-1 リージョンのベースラインとなるオンデマンドインスタンスと比較して、様々なシナリオでコストを削減し、実行時間を短縮しました。図 3a、3b、3c は、中断頻度（λ）ごとに 3 回実行した Sim@Cloud のインスタンス選択スキームにおける平均メイクスパン（統合プロセス内でメッセージが処理されるまでの所要時間）とコストを表示しています。これを Short-Pre-Salt および Pre-Salt シミュレーションモデルについて示しています。メイクスパンは、統合プロセス内でメッセージが処理されるまでの時間を計算するパフォーマンス指標です。 図 3a – Short-Pre-Salt モデルの初回の実行時のコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。 図 3b – Short-Pre-Salt モデルの 2 回目の実行のコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。 図 3c – 完全な Pre-Salt モデルの実行におけるコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。 最悪のシナリオ（λ = 1）においても、コスト削減は Short-Pre-Salt モデルの 2 回目の実行（図 3b）で最大 43.87 %、Short-Pre-Salt モデルの初回実行（図 3a）で最大 90.39 % に達しました。前者のケースでは、スポットインスタンスを使用する際にチェックポイントが必要なため、処理時間が 9.28 % 増加する代わりにこれを達成しました。対照的に、Short-Pre-Salt モデルの初回実行では、処理時間が平均 10.42 % 短縮されました。スポットインスタンスの中断から回復するプロセスには、代替インスタンスの選択、初期化、シミュレーションの再開など、回収と再起動のためのオーバーヘッドが含まれます。図 3b が示すように、中断頻度（λ）の上昇に伴い、メイクスパンも増加しました。λ = 0.5 および λ = 0.8 の場合、Short-Pre-Salt モデルの 2 回目の実行におけるコスト削減はそれぞれ 81.78 % と 81.46 % で、メイクスパンはそれぞれ 0.70 % と 2.48 % 増加しました。初回実行におけるコスト削減はさらに良好で、それぞれ 90.13 % と 90.07 % となり、メイクスパンは 13.52 % と 18.35 % 短縮されました。 λ = 0.1 のシナリオでも顕著な改善が見られました。コスト削減は初回実行で最大 91.58 %、2 回目の実行で 85.74 % に達し、メイクスパンはそれぞれ 15.97 % と 3.92 % 短縮されました。このシナリオでは、選択ヒューリスティックにより、ベースラインのインスタンスよりも低価格で性能の良いスポットインスタンスが得られました。Short-Pre-Salt の実行時間が短いため、スポットインスタンスの中断は発生せず、シミュレーションを移行するための追加のオーバーヘッドを回避できました。選択ヒューリスティックは、スポットインスタンスの購入においてコスト効率の良いリソースを検索する方法を示しています。 Pre-Salt モデルについては、図 3c に示す結果は Short-Pre-Salt モデルの結果と類似しています。このシナリオでは、コストとメイクスパンの両方で削減が達成されました。 実行時間は、ジョブ送信時のリージョンにおけるスポットインスタンスの可用性によっても影響されることに注意してください。スポットインスタンスの価格は実行中に変動する可能性がありますが、λ = 1.0 の両方のシナリオでコストが増加した主な原因は、許可されたスポットインスタンスの中断制限を超えた後に、Sim@Cloud がシミュレーションを完了させるためにオンデマンドインスタンスを選択したことでした。 ベネフィット この調査は有益であり、HPC ワークロードの管理方法に新たな可能性をもたらし、Amazon EC2 スポットインスタンスがコスト最適化の鍵となることを示しました。スポットインスタンスを使用することで、オンデマンド料金と比較して EC2 コストを大幅に削減できます。 FlexCache を搭載した Amazon FSx for NetApp ONTAP を使用して効率的なキャッシュを実現したことで、ストレージ費用を削減し、優れたパフォーマンス指標でクラウド内でのデータアクセスを容易にする重要な変化をもたらしました。Sim@Cloud のようなソリューションは、スポットインスタンスの中断という固有の性質があっても、ワークロードの整合性を損なうことなく大幅なコスト削減を実現できることを示しています。 クラウドベースのソリューションは、エンドユーザーに透明性を提供し、技術的な障壁を減らし、ユーザー（科学者やエンジニア）にピーク需要時に必要となる追加のキャパシティを提供することで、HPC アプリケーションのアクセシビリティを向上させます。 結論 このプロジェクトとその良好な成果は、UFF、Petrobras、AWS の三者による緊密な連携とサポートによって実現されました。結果から分かるように、Sim@Cloud はシミュレーションの実行時間に関係なく、全体的なコストの削減に効果的です。中断頻度（λ）が高くても、より長いシミュレーションモデルは低コストで短いメイクスパンを達成できます。 これらの結果は、AWS が HPC ワークロードの処理において成熟していることを示しています。Petrobras のような大企業は、この結果と AWS の規模とキャパシティの恩恵を受けることで、典型的なプロビジョニングの問題だけでなく、特殊なプロビジョニングの問題も解決できます。 AWS は Petrobras と UFF と緊密に連携しました。この緊密な関係は、環境を理解するだけに使われるはずの時間を節約し、研究やソリューションに取り組むことができるため有益でした。これはプロジェクトの成功と Sim@Cloud の開発に不可欠であり、潜在的なバグを回避し、プロジェクトを最良の決断へと導きました。 謝辞 この研究は多くのエンジニアとアナリストによって実施されました。彼らに深く感謝いたします： Alan L. Nunes (UFF), Cristina Boeres (UFF), Daniel B. Sodré (UFF), Felipe A. Portella (Petrobras), José Viterbo (UFF), Luan Teylo (INRIA/Bordeaux), Lúcia M. A. Drummond (UFF), Maicon Dal Moro (Petrobras), Marcelo Baptista (AWS), Paulo F. R. Pereira (Petrobras), Paulo J. B. Estrela (Petrobras), Renzo Q. Malini (Petrobras), Vinod E. F. Rebello (UFF). 出版物 このプロジェクトについて詳しく知りたい場合は、以下の論文リストをご参照ください。 Sim@Cloud – ​Experimental Evaluation MScheduler: Leveraging Spot Instances for High-Performance Reservoir Simulation in the Cloud , IEEE CloudCom 2023: 99-106 Prediction of Reservoir Simulation Jobs Times Using a Real-World Slurm Log , XXIV Simpósio em Sistemas Computacionais de Alto Desempenho 2023: 49-60 A. L. Nunes&nbsp; et al ., “ A Framework for Executing Long Simulation Jobs Cheaply in the Cloud ,”&nbsp; 2024 IEEE International Conference on Cloud Engineering (IC2E) , Paphos, Cyprus, 2024, pp. 233-244, doi: 10.1109/IC2E61754.2024.00033. High Performance Computing in Clouds: Moving HPC Applications to a Scalable and Cost-Effective Environments, Springer, 2023 https://www.amazon.com/High-Performance-Computing-Clouds-Cost-Effective-ebook/dp/B0BYN665C2/ <!-- '"` --> 翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの宮城が担当しました。 Marcelo Ferreira Baptista Marcelo Baptista は、30 年以上の IT 経験を持つ AWS のソリューションアーキテクトです。DevOps、コンピューティング、HPCを専門とし、お客様の技術的なチャレンジを支援しています。 Alan L. Nunes Alan L. Nunes は、フルミネンセ連邦大学（UFF、ブラジル）とボルドー大学（UB、フランス）の博士課程の学生です。関心のあるトピックには、ハイパフォーマンスコンピューティング、クラウドコンピューティング、分散システム、フェデレーションラーニング、MapReduce などがあります。 Cristina Boeres Cristina Boeres は、フルミネンセ連邦大学計算科学研究所の准教授であり、エディンバラ大学（イギリス）でコンピューターサイエンスの博士号を取得しました。 Felipe Portella Felipe Portella は、ブラジルのエネルギー会社 Petróleo Brasileiro S.A.（PETROBRAS）の IT コンサルタントで、石油貯留層シミュレーションの HPC を専門としています。ブラジルの PUC-Rio で情報学の学位（2003 年）とコンピューターサイエンスの修士号（2008 年）を取得しました。2024 年には、スペインのバルセロナスーパーコンピューティングセンターと提携して UPC-Barcelona Tech でコンピューターアーキテクチャの博士号を取得しました。 Luan Teylo Luan Teylo は、フランスの INRIA Bordeaux の終身研究員です。2021 年からは TADaaM チームで働き、主に HPC プラットフォームに関連する I/O 問題に焦点を当てています。フルミネンセ連邦大学（UFF）でコンピューターサイエンスの修士号と博士号を取得しました。彼の研究テーマには分散アルゴリズム、クラウドコンピューティング、スケジューリング問題が含まれます。 Lucia Maria de A. Drummond Lucia Maria de A. Drummond は、1994 年にリオデジャネイロ連邦大学でシステム・コンピューター工学の博士号を取得しました。ブラジルで最初の並列コンピューターの開発チームに参加し、論文の主要記事は、ブラジル科学アカデミーによる科学技術省とコンパックコンピュータからの研究奨励賞を獲得しました。現在は、ブラジルのフルミネンセ連邦大学の教授であり、ハイパフォーマンスコンピューティングとクラウドコンピューティングの研究に関心を持っています。 Paulo Estrela Paulo Estrela は、2008 年からブラジルの国営石油会社 Petrobras の HPC システムエンジニアとして、石油貯留層シミュレーション用のスーパーコンピューターの構築と管理を行っています。最近では、クラウドコンピューティングリソースを使用して Petrobras のスーパーコンピューターに弾力性を与え、オンプレミスのキャパシティを補完することに取り組んでいます。これらのスーパーコンピューターの一部は、top500.org 機関によって世界で最も強力な 100 台のコンピューターにリストされています。 Vinod Rebello Vinod Rebello は、1996 年にエディンバラ大学（イギリス）でコンピューターサイエンスの博士号を取得しました。現在は、ブラジルのフルミネンセ連邦大学コンピューターサイエンス学科の准教授です。彼の研究は、自律コンピューティング、科学アプリケーション、リソース管理、スケジューリングとフォールトトレランス、サイバーセキュリティなど、グリッドとクラウドにおける並列および分散コンピューティングのさまざまな側面に焦点を当てています。

AWS Summit のシーズンがやってきました! AWS Summit は世界中の主要都市で開催される無料の対面イベントで、クラウドの専門知識を地域コミュニティに紹介しています。各 AWS Summit では、最新のイノベーションに焦点を当てた基調講演、技術セッション、ライブデモ、 Amazon Web Services (AWS) エキスパートによるインタラクティブなワークショップを実施します。先週は、 AWS Summit Tel Aviv と AWS Summit Singapore が開催されました。 AWS Summit Tel Aviv での満員の基調講演の写真をご紹介します。 お近くの AWS Summit を検索 して、クラウドジャーニーの次の一歩を踏み出している何千もの AWS のお客様やクラウドプロフェッショナルと一緒にご参加ください。 5 月 26 日週、私が最も興味を持ったのは、re:Invent 2024 でプレビュー版が紹介された Amazon Aurora DSQL の一般提供 に関する発表でした。Aurora DSQL は最速のサーバーレス分散 SQL データベースです。事実上無制限のスケーラビリティと最高の可用性を活用して、インフラストラクチャ管理なしで常に利用可能なアプリケーションを構築できます。 Aurora DSQL のアクティブ-アクティブ分散アーキテクチャは、単一リージョン 99.99%、マルチリージョン 99.999% の可用性を実現するように設計されており、単一障害点がなく、障害復旧が自動化されています。つまり、リージョンのクラスターエンドポイントに接続できないというまれな状況でも、アプリケーションは強固な一貫性で読み取りと書き込みを継続することができます。 さらに興味深いのは、Aurora DSQL の構築の舞台裏での過程です。これは、エンジニアリングの効率性を追求するテクノロジーだけにとどまらない物語です。ワーナー ヴォゲルス博士によるブログ記事「 とにかくスケールしよう: Aurora DSQL の物語 」で、全文をお読みいただけます。 5 月 26 日週のリリース 私が注目したその他のリリースをいくつかご紹介します。 AWS サーバーレスとコンテナ向けの新しいモデルコンテキストプロトコル (MCP) サーバーの発表 – MCP サーバーが AWS Lambda、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、Finch で利用できるようになりました。MCP サーバーでは、お使いの AWS サービスを正しく操作する方法に関する最新のフレームワークに AI アシスタントがアクセスできるようにすることで、アイデアから本番環境までの時間を短縮できます。オープンソース MCP サーバーをダウンロードして試すには、 aws-labs GitHub リポジトリ にアクセスしてください。 Amazon FSx for Lustre Intelligent Tiering の一般提供の発表 – FSx for Lustre Intelligent-Tiering は、アクセスパターンに基づいてコールドデータを適切な低コストストレージ階層に階層化することで、コストを自動的に最適化します。また、低レイテンシーであることが極めて重要なワークロードのパフォーマンスを向上させるオプションの SSD 読み取りキャッシュが含まれています。 Amazon FSx for NetApp ONTAP が ONTAP FlexCache ボリュームのライトバックモードのサポートを開始 – ライトバックモードは、複数の AWS リージョンとオンプレミスのファイルシステムに分散されている、書き込みの多いワークロードのパフォーマンスを向上させるのに役立つ新しい ONTAP 機能です。 AWS Network Firewall が複数の VPC エンドポイントのサポートを追加 – AWS Network Firewall は、1 つのファイアウォールのアベイラビリティーゾーンごとに最大 50 の Amazon Virtual Private Cloud (Amazon VPC) エンドポイントの設定のサポートを開始しました。この新機能により、一元化されたセキュリティポリシーを使用して、Network Firewall のデプロイを複数の VPC にスケールするための選択肢が増えました。 Cost Optimization Hub が Savings Plans と予約設定のサポートを開始 – 請求とコスト管理コンソールの機能である Cost Optimization Hub を使用して、希望の Savings Plans、予約期間、支払いオプションを設定できるようになりました。これにより、結果として得られる推奨事項と、希望のコミットメントに基づく潜在的な節約額を確認できます。 AWS Neuron が NxD Inference GA、新機能、改善されたツールを導入 – Neuron 2.23 のリリースにより、NxD Inference ライブラリ (NxDI) はベータ版から一般提供版に移行し、すべてのマルチチップ推論のユースケースで推奨されるようになりました。Neuron 2.23 では、コンテキスト並列処理や Odds Ratio Preference Optimization (ORPO) などの新しいトレーニング機能も導入され、PyTorch 2.6 と JAX 0.5.3 のサポートも追加されています。 AWS 料金見積りツールが一般提供を開始し、割引や購入コミットメントをサポート – AWS コンソールで AWS 料金見積りツールの一般提供を開始したことが発表されました。ワークロードのコスト見積もりと AWS 請求の全額見積もりという 2 種類のコスト見積もりを提供することで、より正確かつ包括的なコスト見積もりを作成できるようになりました。また、コスト見積もりを作成する際に、過去の使用量をインポートしたり、正味の新規使用量を作成したりすることも可能です。さらに、価格割引と購入コミットメントの両方を含む新しい料金設定により、コストシナリオにおける潜在的な節約額とコスト最適化をより明確に把握できます。 AWS CDK Toolkit Library の一般提供を開始 – AWS CDK Toolkit Library は、スタックの合成、デプロイ、破棄などの AWS CDK のコア機能へのプログラムのアクセスを提供します。このライブラリを使用すると、CDK 操作をアプリケーション、カスタム CLI、自動化ワークフローに直接統合できるため、インフラストラクチャ管理の柔軟性と制御性が向上します。 Red Hat Enterprise Linux for AWS の発表 – RHEL 10 以降の Red Hat Enterprise Linux (RHEL) for AWS の一般提供が開始され、Red Hat のエンタープライズグレードの Linux ソフトウェアとネイティブの AWS 統合が組み合わされました。RHEL for AWS は、AWS 上で実行される RHEL の最適なパフォーマンスを実現するように構築されています。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AI on EKS の紹介: Amazon EKS を使用したスケーラブルな AI ワークロードの強化 – AI on EKS は、Amazon EKS で AI/ML ワークロードをデプロイ、スケール、最適化できるように設計された、AWS の新しいオープンソースイニシアチブです。AI on EKS リポジトリには、分散トレーニング、LLM 推論、生成 AI パイプライン、マルチモデルサービス、エージェント AI、GPU および Neuron 固有のベンチマーク、MLOps ベストプラクティスのデプロイ準備が整ったブループリントが含まれています。 AWS の地理空間基盤モデルによる地球観測の革命 – 地理空間データ用の新しいトランスフォーマーベースのビジョンモデル (地理空間基礎モデル (GeoFM) とも呼ばれる) は、大陸規模で地球の表面をマッピングするための新しい強力なテクノロジーを提供します。この投稿では、Amazon SageMaker で大規模な推論と微調整を行うために、Clay Foundation の Clay Foundation Model をデプロイする方法について説明します。 すぐにデプロイできるコードサンプル を使用して、AWS の独自のアプリケーションに GeoFM をデプロイし、すぐに開始できます。 AI アシスタントの枠を超える: 生成 AI を使用して業界を刷新した Amazon.com の例 – 非会話型アプリケーションには、より高いレイテンシー耐性、バッチ処理、キャッシュなどの独自の利点がありますが、自律型であるため、リアルタイムのユーザーフィードバックと監視の恩恵を受ける会話型アプリケーションと比較した場合、より強力なガードレールと徹底的な品質保証が必要です。この投稿では、非会話型生成 AI アプリケーションの 4 つの多様な Amazon.com の例を紹介します。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。お近くの都市でご登録ください: ストックホルム (6 月 4 日)、 シドニー (6 月 4 日～5 日)、 ハンブルク (6 月 5 日)、 ワシントン (6 月 10～11 日)、 マドリード (6 月 11 日)、 ミラノ (6 月 18 日)、 上海 (6 月 19 日～20 日)、 ムンバイ (6 月 19 日)。 AWS re:Inforce – 6 月 16日～18 日には、ペンシルバニア州フィラデルフィアで AWS re:Inforce が開催されます。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される、コミュニティ主導のカンファレンスにご参加ください。開催地は、 米国ミルウォーキー (6 月 5 日)、 メキシコ (6 月 14 日)、 ケニアのナイロビ (6 月 14 日)、 コロンビア (6 月 28 日) です。 6 月 2 日週のニュースは以上です。6 月 9 日週にお届けする次回の Weekly Roundup もお楽しみに! – Prasad 原文は こちら です。

こんにちは！AI/ML スペシャリストソリューションアーキテクトの近藤です。 2025年5月22日に「AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜」と題したオンラインセミナーを開催しました。AI によるコーディング技術が急速に発展し、ソフトウェア開発の生産性を劇的に向上させる可能性を秘めたこの革新的技術について、多くの方にご参加いただきました。本ブログでは、そのセッション内容を簡単にご紹介しつつ、発表資料と録画を公開いたします。 セッションの紹介 Keynote : AIエージェント時代のソフトウェア開発 アマゾンウェブサービスジャパン シニアソリューションアーキテクト 高野 賢司 [資料] [動画] 最初のセッションでは、高野より、AIコーディングエージェントの仕組みや背景について解説しました。ソフトウェア開発の歴史を振り返りながら、AIコーディングエージェントがどのように登場し、どのように機能するのかを説明しました。また、AI駆動開発の特徴や、組織への導入方法についても触れ、エンジニアとしてAIと共に開発していくための心構えについても言及しました。 Amazon Q Developer で始めるAIコーディングエージェント アマゾンウェブサービスジャパン ソリューションアーキテクト 国兼 周平 [資料] [動画] 2つ目のセッションでは、国兼より、Amazon Q Developerを使ったAIコーディングエージェントの始め方を解説しました。Amazon Q Developerの概要から、特にCLIでのエージェント型コーディング体験に焦点を当て、実際のデモを交えながら紹介しました。デモでは、カスタマーサーベイアプリケーションの開発を通じて、Amazon Q Developer CLIがどのように自律的にコードを生成し、問題を解決していくかを示しました。また、MCPサーバーを活用したイラスト生成やウェブ検索の機能も紹介され、AIコーディングエージェントの可能性の広さを感じられる内容となりました。 Cline with Amazon Bedrock で始めるAIコーディングエージェント アマゾンウェブサービスジャパン ソリューションアーキテクト 黒澤 蓮 [資料] [動画] 3つ目のセッションでは、黒澤より、Clineと呼ばれるオープンソースのAIコーディングエージェントツールと、Amazon Bedrockを組み合わせた活用方法について解説しました。Clineの特徴として、エージェント主導型の開発が可能であること、既存の統合開発環境に簡単に組み込めること、そして裏側で好きなモデルを利用可能であることなどが挙げられました。デモではVS Code上でClineを使ってテトリスアプリを短時間で作成する様子を紹介し、その効率性を示しました。また、組織でClineを導入する際の課題と対応策についても詳しく解説され、セキュリティとコンプライアンス、トークン消費とAPI制限、コスト管理といった観点からの考慮点が示されました。 お客様事例 LT：合同会社DMM.com「ソフトウェア品質特性、意識してますか？ AIの真の力を引き出す活用事例」 合同会社DMM.com エンジニア ミノ駆動 氏 [資料] [動画] 4つ目のセッションでは、DMM.comのミノ駆動氏より、ソフトウェア品質特性に基づいたAIコーディングエージェントの活用事例が紹介されました。ソフトウェア開発においてAIの力を引き出すには、ソフトウェア品質測定に基づいて指示する必要があるという視点から、変更容易性と機能適合性という2つの品質特性に焦点を当てた活用事例が紹介されました。特に「バグサーチャー」と呼ばれる負債分析用のプロンプトエンジンと、契約による設計を踏まえたテストコード生成の事例が詳細に解説され、AIを活用することで人間の10倍以上の生産性で高品質な分析やテストコードの作成が可能になることが示されました。 お客様事例 LT：株式会社プロトソリューション「Amazon Q Developer 活用事例 in ベトナム」 株式会社プロトソリューション ソリューション開発オフショア 課長 Sankame 氏 [資料] [動画] 5つ目のセッションでは、プロトソリューションのSankame氏より、ベトナムオフショア開発拠点でのAmazon Q Developerの活用事例が紹介されました。従来型のオフショア開発からの脱却を目指し、AIによって少数精鋭の高生産性体制へのシフトを進めている状況が説明されました。Amazon Q Developer IDE版の導入により、炎上気味だったプロジェクトが納期に間に合い、リリース後のバグもほとんど発生しなかった成功事例や、保守プロジェクトでの工数削減効果（約20〜30%）などが紹介されました。また、AIエージェント中心の開発フローの構築や、MCPサーバーを活用したE2Eテストの効率化など、先進的な取り組みについても詳しく解説されました。 AIコーディングエージェントを実際に現場で使うためには？ アマゾンウェブサービスジャパン AI/ML スペシャリストソリューションアーキテクト 近藤 健二郎 [資料] [動画] 最後のセッションでは、近藤より、AIコーディングエージェントを実際に現場で使うための考慮点について解説しました。主に開発チームのプロジェクトマネージャーや意思決定者の視点から、AIコーディングエージェント導入時のリスク管理、コスト管理、ログ管理、権限管理、コード品質管理などの観点について具体的な方法が紹介されました。特に、リスクベースアプローチの考え方に基づき、リスクがあるからといって禁止するのではなく、どう安全に活用していくかという方向性が強調されました。また、組織的な活用に向けた次のステップとして、ツールの選定、用途の明確化、各種管理方法の検討などのポイントが示されました。 まとめ AIコーディングエージェントは、ソフトウェア開発の方法を根本から変える可能性を秘めた技術です。本セミナーを通じて、その仕組みや活用方法、組織への導入方法について多角的に理解を深めていただけたのではないかと思います。 AWSでは、Amazon Q DeveloperやAmazon Bedrockなど、AIコーディングエージェントを安全かつ効率的に活用するためのサービスを提供しています。また、お客様事例からも分かるように、すでに多くの企業がこれらのツールを活用して開発効率の向上を実現しています。今回のセミナーがきっかけとなり、皆様の組織でもAIコーディングエージェントの活用が進むことを願っています。 AWS では、生成AIを活用したビジネス活動創造を支援する 「実用化推進プログラム」 も実施しておりますので、ご興味のある方はぜひご検討ください。 2025年6月25、26日に開催される AWS Summit Japan でもコーディングエージェントに関連したセッションやブースを用意しております。本セミナーのKeynoteで話した高野からは 「AI Agent時代のソフトウェア開発の型 ~ Everything as Code で叡智を伝える ~」 というセッションを予定しております。ぜひご参加ください。 最後に、本セミナーにご参加いただいた皆様に心より感謝申し上げます。今後もAWSは、最新のAI技術を活用したソリューションの提供を通じて、お客様のビジネス成長をサポートしてまいります。 アマゾン ウェブ サービス ジャパン合同会社 AI/ML スペシャリストソリューションアーキテクト 近藤 健二郎

このブログは、 “ Highlights from the 2025 AWS Life Sciences Symposium’s Drug Discovery track ” の翻訳です。 5月6日、ニューヨークで開催された第7回AWS ライフサイエンスシンポジウム には、 400を超える組織から1,000名以上のライフサイエンス業界のリーダー が集いました。「AIがもたらすブレークスルー：製薬バリューチェーンの革新」をメインテーマに掲げ、39名の専門家による26のセッションが開催され、ライフサイエンス分野におけるAI活用の成功事例や課題について、活発な議論が交わされました。シンポジウムを通じて浮かび上がった明確なメッセージ。それは、生成AIがもはや未来の技術ではなく、すでに医薬品の発見から開発、提供方法に至るまで、製薬業界全体を変革する原動力となっているという事実です。特に創薬分野のセッションでは、AIの活用により研究が加速し、科学的精度が向上し、コストが削減され、結果として新しい治療法をより迅速に患者のもとへ届けられるようになっている具体例が次々と紹介されました。 創薬プロセスの抜本的な見直しに向けて 私たちは今、科学、データ、テクノロジーが融合して全く新しい治療法の地平を切り開く、バイオメディカルイノベーションの黄金期にいます。しかし、創薬プロセスは依然として時間がかかり、高コストで、成功の見通しも不確実なままです。医薬品候補の約90%が臨床試験で失敗し、1つの治療薬を市場に送り出すまでに10年以上を要することもあります。巨額の投資が行われているにもかかわらず、多くの疾患に対して効果的な治療法が見つかっていないのが現状です。 この課題の根本にあるのは、生物学そのものが持つ驚くべき複雑さです。私たちの体内には数千種類の細胞、2万を超える遺伝子が存在し、それらの間で起こる分子レベルの相互作用は個人によって千差万別です。研究者たちは、10⁶⁰もの低分子と、20³²にも及ぶ治療用抗体の候補という、ほぼ無限とも言える可能性の中から最適な選択を迫られています。さらに、研究に不可欠なデータは、学術誌やデータベース、各社の独自システムに散在し、体系化されていない状態で存在しています。従来のR&amp;Dツールは確かに優れたものですが、このような規模と複雑さ、そしてスピードへの要求に十分に応えられる設計にはなっていません。 経済面での課題も深刻です。製薬会社は今後数年間で、特許切れ（LOE）により推定2,500億ドルもの収益が失われるリスクに直面しています。イノベーションギャップは広がる一方であり、外部からの資産取得は一時的な解決策にはなりますが、長期的な成功のカギは社内での改革にあります。 このような状況を打開するため、製薬業界にはAIを中心に据えた新しいR&amp;D戦略が必要です。これは単に試行回数を増やすだけでなく、個々の取り組みをより迅速に、より正確に、そしてより成功の可能性が高いものにすることを目指しています。 この変革は、段階的な改善ではなく、パラダイムシフトと呼べるものです。そして、シンポジウムの講演者たちが示したように、この変革はすでに現実のものとなっているのです。 Lab in a Loop：GenentechのAI主導型研究ビジョン Genentech の機械学習による創薬部門バイスプレジデント、 Rich Bonneau 氏が同社がAIを研究の中核に据えて、初期段階の研究プロセスを刷新している取り組みについて紹介しました。 その中心となるのが「 lab in a loop 」という概念です。これは、実験データと臨床データで学習したAIモデルが予測を行い、その結果に基づいて実験室での研究が進められるという、緊密に統合された反復サイクルを指します。新たな実験結果はモデルにフィードバックされ、予測の精度が継続的に向上していきます。このサイクルにより、研究者たちはより正確な予測のもと、広大な化学空間を効率的に探索し、複数の治療特性を同時に最適化することが可能になり、発見のプロセスが劇的に加速されています。 このような革新を支えているのは、Genentechが数十年にわたる研究・臨床活動を通じて構築してきた、質の高い大規模データセットです。これらのデータは、かつては対応が困難と考えられていた課題に取り組むAIモデルの重要な基盤となっています。さらに同社は、生成AIを研究ワークフローに直接組み込む取り組みも進めています。 AWSとの協力により開発された gRED Research Agent は、その代表例です。Amazon Bedrock Agents上で動作するAnthropic社のClaude Sonnet 3.5を搭載したこの知的アシスタントは、科学文献や構造化データベースの調査など、時間のかかる作業を自動化することで、科学者たちがより創造的で影響力の高い研究に注力できる環境を実現しています。 その効果は目覚ましく、これまで数週間を要していたプロセスが数分で完了できるようになりました。例えば、バイオマーカーの検証作業だけでも、43,000時間以上の工数削減が見込まれています。 しかし、これは単なる作業の高速化にとどまりません。科学研究そのものを、かつてない規模で展開できる新たな段階へと押し上げているのです。 セッション録画を視聴する | プレゼンテーションにアクセスする BioFMを活用した分子設計：AbbVieの包括的アプローチ 次に議論は、創薬におけるもう一つの重要課題である 低分子設計 に移りました。 AbbVie のR&amp;Dデータ分析部門バイスプレジデントの Jennifer Van Camp 氏と、グローバルリード兼主任機械学習サイエンティストの Abhishek Pandey 氏が、生物学的基盤モデル（BioFMs）を活用した革新的なアプローチについて発表しました。彼らは生物学を優先した大胆な手法で、イノベーションを推進しています。 AbbVieは画期的な成果として、ヒトゲノム全体の薬剤化可能性スコアの算出に成功しました。これは、どのタンパク質が低分子医薬品の標的として適しているかを予測するものです。この網羅的な評価は、従来のように化合物（リガンド）の特性のみに注目するアプローチからの大きな転換点となりました。AbbVieは、 EvolutionaryScale が開発したESM-2などのbioFMモデルを活用し、タンパク質とリガンドの特性、およびそれらの相互作用パターンを包括的に分析する手法を採用しています。 この生物学的な複雑さを予測可能な形に変換するため、AbbVieはESMの埋め込み技術をリガンドデータと組み合わせ、AffinityNetを開発しました。このシステムは、タンパク質、リガンド、それらの相互作用の特性を階層的に分析するグラフアテンションネットワークを用いた深層学習モデルで、結合親和性を極めて高い精度で予測することができます。これにより、生物学的な知見に基づいた、データ駆動型の低分子探索が可能になりました。 AWSのインフラストラクチャ、拡張性の高い計算能力、そして Amazon Bedrock を通じたBioFMsへのアクセスを活用することで、AbbVieは膨大な生物学的データを、かつてないスピードで実用的な知見へと変換できるようになりました。 セッション録画を視聴する | プレゼンテーションにアクセスする AIエージェント：研究者の役割の新たな形 バイオテックスタートアップのOwkinとBioptimusは、AIを活用した科学研究の新しい協働の形を提示し、生物学の理解をさらに深める取り組みを紹介しました。 Owkin のR&amp;D最高責任者の Jean-Philippe Vert 氏と製品部門VPの Thea Backlar 氏、は、生物学者が生物学者のために開発したAI搭載コパイロット「 K Navigator 」を発表しました。このシステムは高度なエージェントシステムを基盤とし、腫瘍学分野で世界最大の空間オミクスデータセットである MOSAIC Window をはじめとする膨大なデータに接続しています。研究者は自然言語での指示により、多様なデータの探索、分析、視覚化が可能になり、科学的直感を増強し、作業の効率を高め、複雑な問いを実用的な知見へと変換できます。これにより、創薬ターゲットの特定、患者グループの特性評価、既存薬の新たな用途発見などが促進されます。 研究者は現在、3,500万件を超える科学論文へのアクセス、臨床試験の設計、患者データの調査を、単一のインターフェースから行うことができます。しかし、K Navigatorは単なる効率化ツール以上の存在です。これは、人間とAIが協力して新たな知見を生み出し、これまで到達できなかった科学的領域を探索するための新しいパラダイムを示しています。すでにアカデミアで利用可能なこのプラットフォームについて、Owkinは 生物学的人工超知能 （BASI）への足がかりとして位置づけています。これは、AIが人間の発見能力を大規模に拡張する協働システムとなることを目指しています。 一方、フランスのスタートアップ Bioptimus は、生物学特有の多面的な性質に着目したアプローチを展開しています。シンポジウムでは、共同創業者兼主任研究員の Zelda Mariet 氏が、数百万枚の病理画像スライドで学習させた基盤モデル「 H-optimus-1 」について発表しました。このモデルは、がんの種類の分類、腫瘍の段階評価、バイオマーカーの検出、デジタルスライドの品質管理など、主要な診断・研究領域で最高水準の性能を実現しています。生物学における異なるスケール間の関係性を学習することで、より深い洞察を可能にしているのです。 現在、AWS Marketplaceで利用可能 となったこのモデルにより、ヘルスケア・ライフサイエンス分野のお客様は、Bioptimusの最先端病理モデルを自社の安全なクラウド環境に素早く導入し、AWSベースのワークフローにシームレスに統合することができます。これにより、病理学や生物医学研究における知見の獲得が迅速化され、業務効率が大幅に向上します。 しかし、これはほんの始まりに過ぎません。Bioptimusは現在、ゲノミクス、分子データ、イメージング、臨床記録を統合した次世代マルチモーダルモデル「 M-optimus 」の開発を進めています。このモデルは、生命現象のあらゆる複雑さを学習対象とするよう設計されています。彼らの野心的な目標は、生物学における世界初の汎用AIファンデーションモデルの創出です。 セッション録画を視聴する | プレゼンテーションにアクセスする 未来のラボの構築 Deloitte のヘルスケアおよびライフサイエンス部門のマネージングディレクターの Raveen Sharma 氏は、「 未来のラボ 」についての斬新なビジョンを提示しました。それは、計算科学と実験科学が完璧に調和したデジタル統合型のAI駆動エコシステムです。このシステムでは、ドライラボとウェットラボがリアルタイムデータと自動化技術によって緊密に連携し、継続的かつインテリジェントなループを形成することで、科学的発見のプロセスを加速させます。 このモデルにおいて、ドライラボはAIモデルの訓練、調整、改良を担当し、計算機上で実験をシミュレートします。一方、ウェットラボは実際の実験を通じて仮説を検証し、高品質な実験データをシステムにフィードバックします。このデータは FAIR 原則（Findable：見つけやすい、Accessible：アクセスしやすい、Interoperable：相互運用可能、Reusable：再利用可能）に基づいて管理されることで、ループ全体の自己改善が促進され、研究のスピードと科学的厳密性の両立が図られます。 DeloitteとAWSは、このビジョンを実現するため、データの取り込み、統合、ガバナンスを自動化するクラウドネイティブなモジュール型ソリューションを開発しました。これにより、従来は断片化していた研究室のデータを FAIR な資産へと転換することが可能になります。DeloitteのLab of the Futureアクセラレータは、物理的な研究機器とデジタルインフラの間のギャップを埋め、 AWS DataSync 、 AWS IoT Greengrass 、 Amazon S3 、 Amazon DataZone など、実績あるAWSサービスを活用しています。そして、これらすべてを AWS Control Tower で一元管理する仕組みを構築しています。 この新しいアプローチがもたらす影響は大きく、科学者たちはデータ管理に費やす時間を大幅に削減し、本質的な研究活動により多くの時間を充てることができるようになります。結果として、より質の高い治療候補の開発が加速され、革新的な治療法をより迅速に患者のもとへ届けることが可能となるのです。 セッション録画を視聴する | プレゼンテーションにアクセスする データの壁を打ち破る：連合学習による安全な協力体制 科学の進歩は協力があってこそ最も加速します。この原則は、特に創薬の分野で顕著です。 現代の創薬におけるAI活用の最大の課題の一つは、効果的なモデルの学習に不可欠な高品質なタンパク質とリガンド構造データへのアクセスです。確かに公共データベースは存在しますが、困難な創薬ターゲットに対する薬剤設計に必要な、構造的な多様性や分子間相互作用に関する深い知見が不足しています。製薬企業は、これらの相互作用を捉えるための独自のデータセット構築に多額の投資を行ってきましたが、データの機密性が企業間の協力を妨げ、結果として個々の進歩を遅らせる要因となってきました。 連合学習は、こうした壁を打ち破りつつあります。活発な議論が交わされたパネルディスカッションでは、 Johnson &amp; Johnson のIn Silico Discovery部門VP Justin Scheer 氏、AbbVieの計算創薬部門長 John Karanicolas 氏、そして Apheris の共同創業者兼CEO Robin Röhm 氏が、 AI Structural Biology（AISB）コンソーシアム の取り組みを紹介しました。このコンソーシアムは、連合学習を活用することで、各社の機密データを公開することなく、分散したデータセット全体でAIモデルを協調的に学習させることに成功しています。この手法により、知的財産を保護しながら、薬剤の特異性向上や分子間相互作用の最適化、より効果的な治療法の開発加速に向けた知見の共有が可能となっています。 AIモデルの構造予測精度がX線結晶構造解析と同等のレベルに達しつつある今、連合学習は安全で協調的な創薬の新時代を切り開いています。これにより、業界全体の知見を結集し、精密医療における画期的な進展を加速することが可能になってきているのです。 セッション録画を視聴する 発見の新時代 わずか10年前、AIが私たちの移動手段、買い物、音楽鑑賞、ニュース消費の方法を根本から変えることになるとは、ほとんど誰も想像していませんでした。 そして今、同様の変革が創薬の現場で起きています。AIはもはや実証実験の段階を超え、研究開発の全工程において実質的な進歩をもたらしています。科学者たちは、AIの支援を受けながら疾病の生物学的メカニズムを解明し、より効果的な治療法をこれまでにないスピードで設計できるようになっています。これにより、長年にわたって治療法の確立が困難とされてきた疾患に対しても、新たな希望がもたらされています。 2025年のAWSライフサイエンスシンポジウムで明らかになったのは、AIがもはや研究の補助的なツールではないということです。基盤モデル、マルチモーダルデータ、AIエージェント、クラウドネイティブインフラストラクチャーを通じて、研究そのものを根本から変革しているのです。創薬の未来は遠い将来の話ではありません。その変革は、まさに今ここで進行しているのです。 AWSは、お客様がより遠くへ、より速く進むことをサポートできることを誇りに思っています。 世界の大手製薬会社トップ10社のうち9社が、生成AIと機械学習戦略の実現にAWSを選択している という事実は、私たちへの信頼の表れだと考えています。 次のステップを加速するための方法について、詳しくはAWSの担当者までお問い合わせください。 参考資料： 第7回AWS Life Sciences Symposium： 基調講演のハイライト | 基調講演のダイジェスト動画を視聴する ライフサイエンスのイノベーションをAWSのAIエージェントで加速 臨床開発セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 製造セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム コマーシャルセッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム <!-- '"` --> Oiendrilla Das Oiendrilla DasはAWSのライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリードです。ライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。マーケティングのMBA学位を取得しており、MBA取得前にはバイオテクノロジーの工学を修了しています。 このブログは、Senior Solutions Architectの松永が翻訳しました。

このブログは、 “ Highlights from the 2025 AWS Life Sciences Symposium’s Clinical Trials track ” の翻訳です。 5月6日、ニューヨークで第7回AWS ライフサイエンスシンポジウム が開催され、 400を超える組織から1,000名以上の業界リーダー が参加しました。「AIがもたらすブレークスルー：製薬バリューチェーンの革新」をテーマに、39名の専門家による26のセッションが行われ、創薬から医薬品提供までの一連のプロセスにおけるAI活用の実践例が紹介されました。 このシンポジウムで明らかになったのは、生成AIがもはや未来の技術ではなく、すでに製薬業界の現場で活用され、新薬の発見から開発、提供方法まで、さまざまな場面で変革をもたらしているという事実です。特に 臨床開発分野 では、治験実施計画書の作成から実施施設の選定、被験者の登録、規制当局へのデータ提出に至るまで、AIによる効率化の効果が顕著に表れています。 臨床試験の変革期 臨床試験を取り巻く環境は、今まさに大きな転換点を迎えています。新薬開発には平均6～7年、費用にして最大26億ドルもの膨大なリソースが必要とされます。特に深刻な課題が被験者の募集で、全体の時間とコストの3分の1を占めているにもかかわらず、8割の試験で目標被験者数を確保できず、85%で参加者の継続的な確保に苦心しています。さらに、試験の複雑化とグローバル化が進む中、従来の手作業中心のプロセスでは、もはや効率的な運営が困難になっています。 このような課題に対し、AIは画期的な解決策を提供します。組織内のデータとリアルワールドエビデンスを効果的に活用することで、臨床試験のあり方そのものを革新できます。試験デザインの最適化や被験者募集の予測から、最適な被験者とのマッチング、さらには自動データ収集や異常検知によるリアルタイムモニタリングまで、データを基盤とした迅速かつ柔軟な試験運営が可能となります。 今こそ、行動を起こすべき時です。FDAをはじめとする規制当局が、臨床開発におけるAI活用のガイドラインを明確化し始めています。この時期に先駆的な取り組みを行う企業には、業界標準の確立と次世代イノベーションをリードする貴重な機会が開かれています。迅速に行動を起こすことで、開発スピードの向上、コストの効率化、データ品質の改善、より幅広い患者層の包含という面で、大きな優位性を確保することができます。 この期待感と変革への意欲は、臨床開発ブレイクアウトトラックでも強く感じられました。先進的な組織各社が、AIを活用した臨床研究の革新的な取り組みを次々と発表。その主な事例をご紹介します。 アストラゼネカの挑戦：AIによる臨床試験の効率化 アストラゼネカ は、画期的なツール 「Development Assistant」 を発表しました。AWS上で稼働するこの生成AI搭載システムは、臨床データの利用効率を大幅に向上させ、意思決定プロセスを迅速化します。同社の患者安全性担当上級ディレクター、 Vaishali Goyal 氏は、このツールを使用することで、臨床開発チームが自然言語で構造化・非構造化データを自由に検索でき、エビデンスに基づく知見をリアルタイムで得られる仕組みを解説しました。 アストラゼネカは、 Amazon Bedrock を基盤としたプラットフォームを開発し、検索拡張生成（RAG）技術とtext-to-SQL機能を組み込みました。この革新的な組み合わせにより、同社の持つ膨大なデータ資産から、必要な情報を瞬時に抽出することが可能になりました。システムが提供する情報には必ず出典が明記され、追跡可能性が確保されています。これにより、被験者募集や治験実施施設の選定といった業界の重要課題に対して、透明性と信頼性を保ちながら、作業の自動化による効率化を実現しています。 Development Assistantの成功を支えているのは、アストラゼネカが築き上げた堅固なデータ基盤です。同社は、電子研究ノート（ELN）やラボ情報管理システム（LIMS）、臨床システムなど、様々なデータソースを厳選して整備し、FAIR原則（検索可能、アクセス可能、相互運用可能、再利用可能）に準拠したデータプロダクトへと転換しました。これらのデータは、拡張性の高いマルチモーダルAIアプリケーションの重要な資源となっています。 2024年半ばに試験的に導入されたDevelopment Assistantは、わずか6ヶ月で厳格なサイバーセキュリティ基準とAIガバナンス要件をクリアし、実用最小限の製品（MVP）として本番環境での運用を開始しました。複数のAIエージェントを組み合わせた設計により、増加し続けるユーザーのニーズやデータの複雑化にも柔軟に対応できる拡張性を備えています。 アストラゼネカは2025年までに、ユーザー数を1,000人以上に拡大し、より豊富なデータソースとの連携を強化するとともに、部門を越えたシームレスな協働を実現する計画を進めています。Development Assistantは、同社における次世代のAI主導型臨床開発の礎となっています。 セッション録画を視聴する | プレゼンテーションにアクセスする Facultyが提唱するAIエージェント導入の実践的アプローチ アストラゼネカの発表に続いて、 Faculty のチーフテクノロジーオフィサー、 Andy Brookes 氏が登壇し、 組織がAIエージェントを効果的に導入・活用するための実践的なフレームワーク を提示しました。Brookes氏は、AIエージェントの成功を支える3つの重要な要素として、「役割の明確な定義」「ビジネスコンテキストの理解」「パフォーマンス管理」を挙げました。 特に強調されたのが、AIエージェントの役割定義です。同氏は、OUDA（観察・理解・決定・行動）モデルを用いてタスクを決定ループとして構造化することを提案しました。この方法により、AIエージェントは単なる汎用アシスタントではなく、特定のビジネスニーズに応える目的特化型のツールとして機能します。複雑性とリスクを抑えながら、確実な成果を上げることが可能になります。 また、AIエージェントを組織の業務環境に効果的に統合する重要性も指摘されました。Faculty社が「プライベートワールドモデル」と呼ぶこのアプローチは、組織固有の方針やプロセス、制約事項をデジタルシミュレーションとして再現します。これにより、AIエージェントは組織の実態に即した判断が可能になり、本格展開前の安全なテストや、誤作動リスクの低減が実現します。 さらに、パフォーマンス評価においては、処理速度や精度だけでなく、信頼性や判断過程の透明性など、定量・定性両面からの総合的な評価の重要性を説きました。 Brookes氏は、AIエージェントの発展段階を以下の4つのレベルで整理しました： スカウト：情報収集と発見 アナリスト：状況分析と提案 オペレーター：人間の監督下での業務実行 オートパイロット：定められた範囲内での自律的な業務遂行 同氏は、組織がこれらのレベルを段階的に導入することで、即座に価値を生み出しながら、より大規模なシステム変革へと着実に歩を進めることができると提言しました。 セッション録画を視聴する | プレゼンテーションにアクセスする ノバルティス：適応型AI戦略による臨床試験の加速 ノバルティスのデジタルイノベーション、戦略、プログラム＆ポートフォリオオペレーション部門ディレクターであるNoah Hoh氏は、同社が医薬品開発の期間短縮を目指し、R&amp;Dパイプライン全体でAIとデータサイエンスを戦略的に活用している取り組みについて説明しました。 ノバルティスは開発期間を短縮するために3つの重要なイニシアチブを展開しています： Fast-to-IND：治療領域全体で治験薬申請までの期間を12ヶ月短縮 Enhanced Operations：効率性の改善と革新的な試験デザインにより1-2年の時間短縮を実現 AI-Enabled R&amp;D：R&amp;Dライフサイクル全体で予測モデリングとAIシミュレーションを活用し、サイクルタイムを6ヶ月以上短縮 これらのイニシアチブを統合的に推進することで、医薬品開発の総期間を最大19ヶ月短縮することが可能となります。 この変革の中核となっているのは、ノバルティスの適応型AI戦略です。画一的なアプローチを避け、各開発段階に最適な機能を適合させる的確なAI戦略を採用しています。臨床試験における主要な活用領域には、プロトコル設計、実施施設の選定、臨床業務の最適化、文書作成の自動化、意思決定支援システムなどが含まれます。 AWS上に構築されたIntelligent Decision System（IDS）は、このアプローチを具現化したものです。IDSはデジタルツインを活用して臨床試験のワークフローをシミュレートし、実施前に様々な戦略のテストや結果予測を可能にします。これによりリスクを最小限に抑えながら、運用効率を大幅に向上させています。 ノバルティスは段階的な実装アプローチを採用し、R&amp;D全体でのAI統合に向けて着実に歩を進めながら、即座に効果を実感できる施策を展開しています。この実践的で段階的なアプローチにより、現場のスタッフが日々の業務でAIの恩恵を実感しながら、将来的なAI活用の基盤を築いています。その戦略は明確です：即座に測定可能な成果を生み出しながら、長期的な変革に向けた取り組みを着実に進めていくことです。 セッション録画を視聴する | プレゼンテーションにアクセスする メルク：スケーラブルな最新の臨床データプラットフォームの構築 生成AIを活用する競争が加速する中で変わらない真実があります。それは、AIの効果はそれを支えるデータの質に大きく依存するということです。現在の臨床試験は、分断されたシステムとサイロ化されたデータという課題に直面しており、これらが複雑なアーキテクチャを生み出し、イノベーションと規制遵守の障壁となっています。 メルク は、VeevaのDevelopment Data Platformを搭載したAWSベースの最新の臨床データプラットフォームを通じて、この課題に取り組んでいます。メルクのエグゼクティブディレクターである Gopi Gopinath 氏と、Clinical and RWE ITのAVPである Marjorie Waters 氏は、この変革が統一されたメタデータ駆動型アーキテクチャを通じて臨床業務を効率化する方法を共有しました。このプラットフォームは、分断された臨床、運用、規制、安全性データを単一の信頼できるソースに統合し、データの整合性を維持しながらより迅速な試験の実施を可能にします。 このプラットフォームは、内部システムと外部パートナー間のデータを1つの統一されたリポジトリに統合し、Study Data Tabulation Model（SDTM）標準化、自動化された第三者データ取り込み、データマスキングとロールベースのアクセスを含む強化されたセキュリティ機能、中央化されたメタデータ管理、セルフサービス分析ツールといった主要な機能を提供します。統合された分析と可視化ツールにより、このプラットフォームは試験計画、患者登録、サイトパフォーマンス、リスクベースのモニタリングに関する重要な洞察を提供し、運用の負荷を軽減し、予防的な意思決定を可能にします。 新しいアーキテクチャはまた、プロトコルとレポートの作成のための生成AI活用、試験成功のための予測モデリングの実装、プロトコル最適化のためのシミュレーションツールの開発、合成対照群の作成など、高度なAIアプリケーションの基盤を確立します。 クラウドネイティブでプラットフォームベースのアプローチを採用することで、メルクは試験インフラを近代化するだけでなく、臨床開発における生成AIの可能性を完全に実現するために必要なデジタル基盤を構築しています。 セッション録画を視聴する | プレゼンテーションにアクセスする より迅速なデータ駆動型臨床試験の洞察のためのリアルワールドデータとエビデンスの活用 リアルワールドデータ（RWD）は現代のヘルスケアにおける意思決定を推進しています：2019-2021年のFDA承認の85%が実世界エビデンス（RWE）に依存していました。しかし、この貴重なデータは医療提供者、保険会社、医療レジストリ間に散在したままです。研究者たちは分析を開始する前にデータの収集と整理に数ヶ月を費やすことがよくあります。現在のデータサイロ、プライバシー要件、複雑なデータベースクエリは、この貴重な情報源に対するAIツールの潜在的な活用を制限しています。 AWSのWorldWide Real World Dataリードである Praveen Haridas 氏と、 Datavant のプレジデントおよびGMである Arnaub Chatterjee 氏は、この課題に対する解決策を提示しました。 AWS Clean Rooms 上に構築された新しいプラットフォーム、 Datavant Connect は、保護された健康情報（PHI）を公開することなく、研究者がリンクされた患者データを分析することを可能にします。このプラットフォームは、従来4ヶ月かかっていた発見プロセスを2週間に短縮し、同時にデータ所有者のコントロールを維持します。これには医療保険の相互運用性と説明責任に関する法律（HIPAA）準拠とガバナンス機能が組み込まれています。つまり、スピードのためにプライバシーが犠牲にされることはありません。 製薬業界のリーダーたちは、すでにこれらの機能を活用しています。 ベーリンガーインゲルハイム のRWEセンター・オブ・エクセレンスのエグゼクティブディレクター兼グローバルヘッドである Paul Petraro 氏は、ベータブロッカーの有効性評価を例に挙げ、治療効果と経済的アウトカムをより良く理解するために、 組織がこのプラットフォームを使用してRWE戦略をスケールアップする方法 を共有しました。 さらにAWSは、データから得られる知見をより活用しやすくするため、新たなインテリジェントエージェントを導入しました。これにより、研究者はプログラミングの専門知識がなくても、自然な言葉で複雑なデータセットを検索・分析できるようになり、実世界データ（RWD）の利用がより身近なものとなりました。このエージェントは、医学文献、臨床データ、規制文書との連携機能を備えており、ユーザーの役割に応じた適切なアクセス権限の管理や、操作履歴の追跡も可能です。さらに、厳格なコンプライアンスとデータセキュリティも確保されているため、安心して利用することができます。 リリー のRWD担当シニアディレクター、 Greg Cunningham 氏は、AWS上に構築された Real World Data（RWD）Insights Agent を紹介しました。このシステムは、データ分析にかかる時間を劇的に短縮し、従来は日単位で行われていた洞察の抽出を分単位で可能にしています。この「仮想アナリスト」の特筆すべき点は、技術的な専門知識を持たないユーザーでも、SQLのような専門的なクエリ言語を使わずに、自然言語で複雑なデータセットを探索できることです。 Amazon Bedrock を基盤に構築されたこのシステムは、複数のAIエージェントを駆使してメタデータの発見やコホートの定義を管理し、同時に厳格な監査証跡とコンプライアンスの維持を実現しています。さらに、人間の監督を適切に組み込んだ責任あるフレームワークの中で、新たなデータソースの迅速な統合や組織のニーズに応じた柔軟な拡張が可能となっています。 このプレゼンテーションは、AWSが業界のリーダー企業とのコラボレーションを通じて、医療データ分析の変革に真摯に取り組んでいることを如実に示しました。より迅速なエビデンスの生成と、それに基づく患者アウトカムの改善を目指す同社の姿勢が明確に伝わってきました。 参加者たちは、AWSがDatavantのようなパートナー企業と協力し、多様なデータ提供者のネットワークからRWDを容易に発見、評価、購読できるプラットフォームを構築している様子を目の当たりにしました。さらに、購読したRWDから有意義な洞察を導き出すための、ユーザー中心の革新的なツールについても紹介されました。特に注目を集めたのは、技術的な専門知識を持たないユーザーでも、自然言語のクエリを使って複雑な医療データを分析できる、クラウドネイティブなエージェント型AIアプリケーションでした。 セッション録画を視聴する | プレゼンテーションにアクセスする | 詳細を読む 未来を見据えた今日の取り組み 生命科学分野における生成AI投資の約70%が臨床試験に向けられている現在、スピード、精度、拡張性への要求はかつてないほど高まっています。 臨床試験の分野で次々と新たなAI活用事例が登場する中、一つだけ変わらないものがあります。それは、スケーラブルで安全なデータ基盤の必要性です。この基盤があってこそ、組織は将来のどのような技術革新にも柔軟に適応し、進化し、さらなる発展を遂げることができるのです。 私たちは、この革新的な取り組みに参加してくださったすべてのパートナー、顧客、そして参加者の皆様に心からの感謝を申し上げます。これまでの成果を誇りに思うと同時に、さらなる飛躍が期待される未来に大きな期待を寄せています。 AWSの担当者に連絡する か、ライフサイエンス分野におけるイノベーションの新時代を切り開くためにAWSパートナーネットワークをぜひご活用ください。私たちと共に、医療の未来を築いていきましょう。 参考資料： 第7回AWS Life Sciences Symposium： 基調講演のハイライト | 基調講演のダイジェスト動画を視聴する ライフサイエンスのイノベーションをAWSのAIエージェントで加速 創薬研究セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 製造セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム コマーシャルセッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム <!-- '"` --> Oiendrilla Das Oiendrilla DasはAWSのライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリードです。ライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。マーケティングのMBA学位を取得しており、MBA取得前にはバイオテクノロジーの工学を修了しています。 このブログは、Senior Solutions Architectの松永が翻訳しました。