はじめに 株式会社ウェザーニューズは世界最大規模の民間気象情報会社として、気象データやコンテンツの提供、気象コンサルティングサービス、気象ソリューションの開発・提供などを手がけています。民間気象会社の先駆けとして高精度の気象予測モデルや解析技術を開発し、様々な業界向けにサービスを提供していますが、本投稿は株式会社ウェザーニューズの Son Junho (孫俊鎬) 氏により、同社が手がける船舶の航海データを提供するサービス基盤に AWS を活用いただいている取り組みについて寄稿いただいたものです。 システムの概要 船舶気象情報サービスは、日々リアルタイムに更新される船舶の識別情報や位置情報、針路、速度といったデータや気象情報から得られた分析データを、乗船員や運行管理者にリアルタイムに提供するものです。これらデータを活用することで例えば燃料消費量の削減を図ることや、台風、高波といった警報情報を確実に通知することで船舶の安全運行をサポートしています。このサービスは現在約37万を超える船舶のデータを、AWS の様々なサービスを活用して蓄積、分析したデータをユーザーに提供しています。 従来システムの課題 従来のシステムにおける課題は、大きく分けてデータ品質、システム連携、開発環境、およびデータベースの性能に関する問題が存在していました。 データ品質に関しては、SPIRE AIS における通信エラーにより、最長で40分から数時間にも及ぶデータの遅延や欠損が発生し、安定的なサービス提供に影響を及ぼしていました。加えて、船舶の対地速度 (SOG) や対地進路 (COG) 、航行状態 (STATUS) などの AIS データ（AIS: Automatic Identification System：船舶自動識別装置）について、従来システムではデータの粒度が荒く、分析のためにより詳細なデータ精度（最長でも10分間隔）が要求されていました。また、過去の航行実績確認などの長期的な AIS データの分析ニーズに対して、従来のシステムでは適切な対応が困難であり、事業判断に必要となる長期的な傾向分析に支障が生じていました。 システム連携においては、各 AIS データベンダーが独自のデータ構造や精度基準を採用していたため、システム間連携の際に項目名の標準化や値の精度変換など、複雑な対応が必要となっていました。これらの個別対応は開発コストの増加を招くとともに、不具合発生のリスク要因となっていました。 開発環境の面では、開発者全員が AIS データに効率的にアクセスできる環境が整備されておらず、開発効率の低下や作業の重複が発生している状況でした。 データベースの性能面ではデータ量の増加に伴う性能面での課題が顕在化していました。具体的には、索引付与やスケールアップ、パッチ適用などの対応に多大な工数を要していました。 これらの複合的な課題に対して、システムの改善および最適化に向けた検討が急務となっていました。 アーキテクチャ AWS でのアーキテクチャは以下の通りです。 SPIRE の AIS（船舶自動識別装置、Automatic Identification System) からのデータを AWS の様々なサービスを組み合わせて、リアルタイムに処理、分析基盤に蓄積、各種集計データを提供するアーキテクチャとなっています。 AWS Fargate 上で動作する Spire Receiver と FluentBit が、 SPIRE から送付された TCP Feed データを受信します。このデータは Amazon Kinesis Data Streams を経由して Kinesis Firehose に渡されます。ここでデータの一次加工が行われ、Amazon S3 にファイル形式で保存されます。 次に S3 から AWS Lambda により SQS/FIFO キューを介して Amazon Timestream にデータを蓄積します。その後、Timestream 上で集計処理を行い、結果をデータマートの位置付けであるAurora MySQLに蓄積しています。 さらに地理空間データを活用するために、Aurora MySQL のデータを AWS Lambda 上で GeoJSON データに加工し、 S3 に蓄積しています。 プロジェクト期間 本システムの開発は2人体制で進め、構想から設計、構築、テストの実施まで約1年のプロジェクトとなりました。 本システムは扱うデータ量が膨大であるだけでなく、AIS データは一定の遅延が存在するため AIS データの連続性や整合性を確認するためのテストが必要不可欠ですが、限られた人員の中でデータの仕様策定からテストまで、サービスの品質担保のため各工程を丁寧に進めた結果と言えます。一方で実際の開発作業期間に関しては前述のように AWS のサーバーレスの特徴を有するサービスを活用したことで、約1ヶ月という短期間で構築することができました。 一部 Timestream のストレージレイヤーの保管期間の調整など慣れていなかった点で試行錯誤をしましたが、その他は特に問題なくスムーズに使い始めることができました。 AWS利用による運用上の利点および課題 システムを設計する過程で、ベンダー毎に異なるデータ構造を項目名や値の粒度を統一し、各種 AIS データ群を共通管理することで、各システムに対して統一した方法でデータを提供できるようになりました。さらにデータのリアルタイム収集を可能にしたことでより細かな粒度のデータ取得を実現し、利便性が向上しました。 性能テストにおいては、Fluent Bit のスレッド数の増加に対し、それぞれのサービスで期待するスループットを維持することができました。また特別なチューニングをせずとも一定のレスポンスを実現しています。 運用面では、CloudWatch 監視を基点とした自動化を実施し、Slack 通知に加えて、社内配信データの自動生成やコンポーネントの自動再起動などを実装することで、運用・保守に関わる人件費を含めた運用コストを80%削減することに成功しました。 まとめ AWS の各種サービスを適材適所に活用したシステムを構築したことで、従来システムと比較してより多くの機能を提供できるようになっただけでなく、運用コストの大幅な削減も実現しました。管理対象となる船舶数も3.2万隻から37万隻へと大幅に増加し、データ更新頻度の向上と合わせて、製品品質の向上、販売範囲の拡大、売上の向上にも寄与しています。 著者について Son Junho （孫俊鎬） : 株式会社ウェザーニューズ Sea Planning Service Meun 開発部 Products Manager

こんにちは、AWS ソリューションアーキテクトの上野です。2025年4月11日、5月28日に、記念すべき第1回 AWS DEVCRAFT を開催いたしましたので、その取り組みについてご紹介させていただきます。 DEVCRAFT が目指すもの AWS DEVCRAFT は、AWSのサービスを活用してお客様の実際のビジネス課題を解決する機能を開発するハッカソンイベントです。通常のハンズオンとは異なり、短期集中型の支援を通じて実務で即活用できる機能開発を実現し、お客様のビジネスを加速させることを目指しています。 イベントの進め方 DEVCRAFT は2日間のイベントを軸に進めていきます。初日となる Day 1 では、まず開発で利用する AWS サービスの基礎を学んでいただき、その後、実際に開発する機能の要件整理や設計に取り組んでいきます。AWS のエキスパートが終日同じテーブルについて一緒に考え、技術面でのアドバイスを提供させていただきます。 Day 1 で整理した内容を持ち帰っていただいた後は、実際の開発フェーズに入ります。開発中に疑問点や課題が出てきた際には、随時技術相談会を開催し、スムーズな開発をサポートさせていただきます。 締めくくりとなる Day 2 では、参加者の皆様に開発した機能についてご発表いただきます。技術的な工夫だけでなく、開発中の試行錯誤など、貴重な経験の共有の場となっています。 参加企業様の素晴らしい取り組み 株式会社アンドゲート様からは、生成AIとMCPサーバーを組み合わせた画期的なセキュリティチェックシステムをご紹介いただきました。複数のツールに散らばる情報を一度の会話で集約できる機能は、業務効率を大きく向上させる可能性を感じさせるものでした。 協栄産業株式会社様は、建築業界の長年の課題に挑戦されました。建築図面からの自動データ抽出システムは、なんと作業時間を95%も削減することに成功。生成AIと AWS Step Functions の見事な組み合わせで、画期的な業務改革を実現されています。 それではここからは、ご参加いただいた企業様のご登壇の様子をご紹介していきます。 株式会社アンドゲート 鈴木　勘久郎 氏（写真右）、田村　祥 氏（写真左）らは、セキュリティチェックを効率化する機能および、PM 補佐機能を生成 AI と MCP サーバー連携を活用することで開発されました。MCPサーバーの活用により一度の会話で、複数ツールに散らばる情報を集約できるようになった点が特徴となります。MCP サーバーとの連携は、今回のイベントの中では唯一の実装例でしたが、開発期間中の生成 AI 関連のアップデートの早さにより、開発方針を大きく変えたという開発秘話についてもお話いただきました。今後は機能のブラッシュアップを進めながら、AI による業務改革を進めていくというお言葉で締めくくっていただきました。 協栄産業株式会社 IT ソリューション部 田中 秀弥 氏らは、建築工程の積算を担うシステムにおいて、積算に必要なデータを図面から自動で読込みする機能を開発されました。生成 AI を活用して画像から必要な値を読み取り、システムにインプットできる形に加工する一連の流れを AWS Step Functions で組み上げております。プロンプトの試行錯誤により、読取精度95%、データ読み取りの作業時間が従来の95%短縮されており、今後は対象範囲を広げ積算・見積業務における業務改善を進めていくご計画とのことです。 株式会社ファイン開発本部 ゼネラルマネージャー 雑賀 崇 氏らは、建築パースに関連度の高い商品をレコメンドする機能を開発されました。同社では、商談の場面で建築パースからイメージを膨らませたお客様に、床、タイルなどの実際の商品をご提案する際に、建築パースのイメージに近い商品になかなかたどり着けないという課題のもと、今回の開発に取り組まれております。同社で開発したモデルによる部位検出、生成 AI による特徴量抽出などの処理フローを AWS Step Functions で実装されており、今後は精度や検索パフォーマンス、スケーラビリティの向上に向けてブラッシュアップを進めていくご予定とご説明いただきました。 株式会社フレイ・スリー 開発部 リードエンジニアの青木　諭 氏らは、同社が提供する動画マーケティングサービスである「1ROLL」 の新機能として、視聴データの評価及び、課題に応じた解決策を提案する機能を開発されました。動画をインプットにして、構成情報の取得や視聴データの評価を行うフローが進み、これらの情報をもとに、解決策を提示するという一連の流れを AWS Step Functions でスピーディーに実装されています。今回の機能を動画活用のPDCAに取り込み、より良い動画活用を自動で提案、顧客自身で解決できるようなシステムを目指しますというお言葉で締めくくっていただきました。 ソウ・エクスペリエンス株式会社 システムチームの竹谷　哲也 氏（写真左）、松岡　奈々 氏（写真右）は、FAXの画像データの取得とそのデータを画像解析システムへ送信する処理フローを既存の仕組みから AWS Step Functions に置き換えられました。同社は、体験ギフトのサービスを展開されており、体験ギフトのECサイト、申し込み用のサイト、体験施設向けの管理サイトなどを運営されており、その中ではFAXデータを取り扱う業務が存在します。Step Functions での開発を試行錯誤いただき、移行後のコスト予想では90%以上の削減が見込まれています。今後は、その他の機能においても Step Functions への置き換えを検討されているとのことです。 心に残る成果と将来への期待 今回の AWS DEVCRAFT では、参加された全てのお客様が、実務で使える機能を見事に開発されました。「対面でのディスカッションで素早く方向性が定まった」「期間が決まっていることで集中して取り組めた」など、うれしい声を多数いただきました。特に印象的だったのは、このイベントをきっかけに、AWS サービスの新しい活用方法を見出されたお客様が多かったことです。今回の経験を今後の開発にも活かしていただけるとのお話もいただき、私たちとしても大変心強く感じています。AWS DEVCRAFT は、これからもお客様のビジネスの発展により一層貢献できるよう、内容の改善を重ねてまいります。 本記事公開時点では、AWS DEVCRAFTは招待制のイベントとなります。AWS側の担当者がお客様の状況を鑑みてご案内差し上げておりますので、予めご了承ください。 著者について 上野　涼平 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。好きな AWS サービスは AWS Systems Manager です。プライベートでは最近、辛い物の耐性が弱まってきたのでリハビリ中です。 佐藤　雄太 AWS Japan のソリューションアーキテクトとして普段はスタートアップのお客様を担当しています。好きなサービスは AWS Lambda, AWS Amplify, AWS Support です。最近興味があるのはデザインの勉強です。

AWS は常に最新のテクノロジーと実践的なスキルを提供することに力を入れています。そして、お客様自身が実際に手を動かし、AWS の理解を深めていただくため、日本語ハンズオンやワークショップを「 JP Contents Hub 」に一覧化して纏めております。本ブログでは JP Contents Hub の中から Media & Entertainment 業界向けの 3 つのワークショップをご紹介します。。3つのワークショップは業界トレンドや AWS サービスの機能増に合わせ、2025 年上旬にアップデートされました。 1. AWS で動画配信をはじめよう 概要: AWS Elemental Media Services を活用した動画配信の基礎から応用までを学べるワークショップです。ライブストリーミング配信、ビデオオンデマンド (VOD) 配信、そして FAST(Free Ad-Supported Streaming TV) チャンネルまで、手を動かしながら学習できます。 学べること: クラウドベースの動画配信システムの構築方法 様々な配信形態に対応するための AWS Elemental Media Services の活用法 高品質な視聴体験を提供するための設定とベストプラクティス FAST チャンネルの構築方法 こんな方におすすめ: 放送局やコンテンツ制作会社の技術担当者 動画配信プラットフォームの技術担当者 企業の広報・マーケティング部門でライブ配信を担当する方 従来のオンプレミス配信から、クラウドベースの配信への移行を検討している方 2. Cloud Production with vMix on EC2 概要: Amazon Elastic Compute Cloud (Amazon EC2) 上でライブミキシングスイッチャーソフトウェアの vMix を実行し、AWS Elemental Media Services または Amazon Interactive Video Service と連携させて、クラウドベースのライブプロダクションおよびライブストリーミング配信の実施を学べるワークショップです。2025 年 3 月に AWS Elemental MediaConnect で対応した NDI (Network Device Interface) 出力機能の設定も含まれております。 学べること: リモート環境からでも高品質なライブ制作が可能なクラウド環境の構築方法 vMix と AWS サービスを組み合わせたライブ配信ワークフローの最適化 地理的に分散したチームでの効率的なライブ制作の実現方法 スケーラブルで柔軟性の高いライブクラウドプロダクションの設計 こんな方におすすめ: イベント配信やライブストリーミングの制作担当者 リモートワーク環境でのライブ制作を模索している放送・制作会社の担当者 企業のコミュニケーション部門やイベント担当者 教育機関でのオンライン講義や配信を担当する技術担当者 3. Deadline Cloud Workshop 概要: AWS Deadline Cloud を活用したスケーラブルなレンダーファームの構築、運用を学ぶワークショップです。Digital Content Creation (DCC) ツールからのジョブサブミット、そしてジョブモニタリングからコスト監視まで学びます。2025 年に日本語版ワークショップが作成されました。 学べること: クラウドレンダーファームの構築方法 スポットインスタンスを用いた効率的なレンダーファームの運用 Web ベースのインターフェースを通じたジョブ管理と監視の手法 クラウドリソースの最適化とコスト管理方法 こんな方におすすめ: VFX スタジオやアニメーション制作会社のテクニカルディレクター ゲーム開発会社のレンダリングパイプライン担当者 建築・製品デザイン企業の 3DCG レンダーファーム管理者 オンプレミスのレンダーファームからクラウドへの移行を検討している IT 管理者 まとめ これらのワークショップは、手を動かしながら AWS サービスの活用方法を学べる日本語コンテンツです。動画配信、ライブプロダクション、レンダリングのいずれの分野においても、クラウドの柔軟性とスケーラビリティを最大限に活かしたソリューションの構築方法を習得できます。 各ワークショップは、初心者から経験者まで幅広いレベルに対応しており、ビジネスシナリオに基づいた実践的な内容となっています。ぜひこの機会にメディア制作・配信ワークフローの次世代化に向けたスキルを身につけてください。 注意：ワークショップ終了時には、不要なコストが発生しないように作成したリソースを削除してください。リソースの削除方法は各ワークショップの最後の手順をご覧ください。 参考リンク AWS for Media & Entertainment AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは SA 金目、小林、濵野、加藤が担当いたしました。

時間の経過とともにパフォーマンスに対する要求が高まるファイルベースのワークロードをサポートすることは、組織にとって継続的な課題です。データセットが拡大するにつれ、静的なインフラストラクチャは変化のペースに追いつくために苦戦し、その結果、新しいインフラへの移行が混乱を招く可能性があります。組織は、将来の要件にシームレスに適応しながら、現在の規模に応じた速度を実現する、拡張性の高いファイルストレージを必要としています。 Amazon FSx for NetApp ONTAP は、Amazon Web Services (AWS) でネイティブにフルマネージド型の ONTAP ファイルシステムを提供しています。変動するワークロードに特化して設計されており、中断することなくパフォーマンスとストレージを拡張できます。FSx for ONTAP の第 2 世代ファイルシステムでは、第 1 世代ファイルシステムの最大 18 倍のパフォーマンスにスケールアップできる機能強化を発表できることを嬉しく思います。 この記事では、第 2 世代ファイルシステムを詳しく説明します。まず、FSx for ONTAP のパフォーマンススケーラビリティの背景から説明します。次に、第 2 世代ファイルシステムが前世代のファイルシステムよりも強化されたパフォーマンス、スケーラビリティ、柔軟性について紹介し、第 2 世代ファイルシステムが提供する 2 つの新機能を紹介します。1/ データバックアップからファイルに迅速にアクセスする機能、2/ iSCSI ブロックストレージの近代化され、簡素化され、高速な代替手段として NVMe-over-TCP プロトコルを使用する機能です。最後に、第 2 世代ファイルシステムの作成と更新方法について説明します。 Amazon FSx for NetApp ONTAP のパフォーマンスとスケーラビリティに関する背景 これまで、FSx for ONTAP ファイルシステムは 2 つの種類、1/ スケールアップと 2/ スケールアウトファイルシステムで提供されていました。第 1 世代のスケールアップファイルシステムは、単一のハイアベイラビリティ (HA) ペアのファイルサーバー上で最大 4 GBps のスループットと 192 TiB のプロビジョニング済みソリッドステートドライブ (SSD) ストレージをサポートしていました。第 1 世代のスケールアウトファイルシステムは、最大 12 の HA ペアのファイルサーバーにワークロードを自動的に分散させることで、複数のファイルシステムのパフォーマンスを 1 つに統合し、最大 72 GBps のスループットと最大 1 PiB の割り当て済み SSD ストレージを実現しました。 スケールアップファイルシステムは、現在、一般的なファイル共有、アプリケーション、データベースなどほとんどのワークロードの要件を満たしています。しかし、規模拡大や顧客のデータ利用の増加に伴い、ワークロードのパフォーマンス要件が高まる傾向があります。より大規模で要求の厳しいワークロードにはスケールアウトファイルシステムが適していますが、これまでパフォーマンス要件が既存のファイルシステムが提供できる範囲を超える場合、データを新しいファイルシステムに移行する必要がありました。これは、既存のファイルシステムの HA ペアに HA ペアを追加したり、HA ペアのスループットを変更したりすることができなかったためです。 第 2 世代ファイルシステムの導入 第 2 世代のファイルシステムでは、最大 6 GBps のスループット (第 1 世代から 50% 増) と 512 TiB の SSD ストレージ (第 1 世代から 160 % 増) を実現する単一の HA ペアでファイルシステムを作成できるため、単一の HA ペア内でワークロードを拡張する余地がさらに広がります。既存の HA ペアよりも高いパフォーマンスが必要な場合は、新しい HA ペアを単一のアベイラビリティーゾーン (AZ) ファイルシステムに追加できます。また、複数の HA ペアを持つファイルシステムのスループットは、いくつかの選択肢で変更できるため、ファイルシステムがワークロードに追従することがこれまでよりも簡単になります。 複数ペアから構成される第 2 世代ファイルシステム の FSx for ONTAPは、あわせて最大 72 GBps のスループットをサポートします。電子設計自動化 (EDA) 、ビジュアルエフェクト (VFX) レンダリング、機械学習トレーニングパイプライン、ペタバイト規模のデータベースなど、最も要求の厳しいワークロードにも対応可能です。さらに、HA ペアあたりのベースラインスループットが 50 % 向上 (4 GBps から 6 GBpsに) して、バースト能力も最大 300 % 向上 (ネットワークスループットバースト : 6.2 GBps 対 1.5 GBps、ディスクスループットバースト : 3.1 GBps 対 1.2 GBps）したことで、変動するワークロードが急増しても、スムーズに十分な余裕をもって処理することができます。 以下の仕様表は、第 1 世代と第 2 世代のファイルシステムを比較しています : ファイルの復旧時間を短縮し、ほぼ即時アクセス可能なバックアップ復旧を実現 第 2 世代のファイルシステムでは、FSx for ONTAP はファイルのバックアップ復旧時間を短縮する新機能を導入しました。従来、FSx for ONTAP のボリュームバックアップを復旧する際は、データセット全体が復旧完了するまで、その中のデータにアクセスできませんでした。現在、第 2 世代ファイルシステム上でバックアップを復元すると、復元を開始してからおよそ数分でボリュームへの読み取りアクセスが可能になり、第 1 世代ファイルシステムでのバックアップ復元と比較して最大 17 倍の速度でバックアップデータセット全体を読み取ることができます。 この強化された復元機能により、誤って削除してしまった場合でも、完全な復元を待たずに重要なファイルをすばやく取り出すことができます。たとえば、復元を開始し、そこから必要なデータを転送し、復元をキャンセルすることで、ボリューム全体が復元されるのを待たずに (復元が完了する前であっても) 1 つのファイルまたはディレクトリ全体を復元できるようになりました。 NVMe-over-TCP プロトコルでブロックストレージを高速化 第 2 世代のファイルシステムには、新しいブロックストレージプロトコル「NVMe-over-TCP」も用意されています。iSCSI ブロックストレージに代わる NVMe-over-TCP は、最新でシンプルな使用感を提供します。たとえば、iSCSI では、クライアントがファイルシステムのファイルサーバー間でフェールオーバーできるようにファイルシステムノード間のマルチパスを管理する必要がありますが、NVMe-over-TCP ではプロトコルに組み込まれています。また、効率的なネットワークスタックにより、一部のワークロードではレイテンシーが低くなり、iSCSI よりもパフォーマンスが向上します。 第 2 世代ファイルシステムの作成 Amazon FSx for ONTAP ファイルシステムの第 2 世代 FSx は、 AWS マネジメントコンソール 、 AWS Command Line Interface (AWS CLI) 、または Amazon FSx の CreateFileSystem 関数を呼び出すコードを作成することで作成できます。マネジメントコンソールを使用する場合、 図 : 1 に示すように、 Amazon FSx for NetApp ONTAP を選択します。 図 : 1 – ファイルシステムタイプの選択 第 2 世代ファイルシステムは、 図 : 2 に示すように、 クイック作成 または スタンダード作成 のいずれかを選択して作成できます。 クイック作成では 、すべての利用可能なリージョンにおいて、第 2 世代ファイルシステムがデフォルトのファイルシステムタイプとして設定されています。 スタンダード作成 では、第 2 世代または以前の世代のデプロイを選択できます。 簡単に設定するには、 クイック作成 を選択します。次に名前を入力し、デプロイタイプは シングル AZ を選択し、必要な SSD ストレージ容量を入力します。スループット容量については、(SSD ストレージに基づいて) 推奨される値をそのまま使用するか、希望する値を入力することができます : 図 : 2 – 作成方法 スループットを指定する場合、 図 : 3 に示すように、希望するスループットに最も近い利用可能なオプションの一覧が表示されます。 図 : 3 – スループットキャパシティオプション 希望する値によっては、コンソールには異なる数の HA ペアで構成される複数のスループットオプションが表示されます。ワークロードに適した構成を選択する際のガイドラインは以下の通りです : 低いスループット – 単一の HA ペアは、最も低いスループット容量 (384 MBps、768 MBps) と最小 SSD ストレージ容量 (1 TiB) を提供します。ワークロードのライフタイムを通じて最大 6 GBps のスループットしか必要としない場合、単一の HA ペアを選択することでコストを最適化できます。&nbsp; 高いスループット – ファイルシステムが持つ HA ペアの数が増えるにつれ、総スループットと SSD ストレージのスケーラビリティが向上します。第 2 世代ファイルシステムではいつでも HA ペアを追加できますが、ワークロードのライフサイクル全体で必要とする最大スループットにスケールできるように、HA ペアの数を最初に決定することで、時間の経過に伴うワークロードのスケーリングが簡素化されます。HA ペアを追加する際はファイルシステム内のデータを移動する必要がありますが、既存の HA ペアのスループットやストレージをスケールアップする際は移動不要です。例えば、現在のワークロードが 6 GBps のスループットしか必要としないが、将来的に最大 24 GBps が必要になると予想される場合、 4 ペア構成を選択することで、最初に 6,144 MBps のスループット (1 HA ペアあたり 1,536 MBps) で開始し、ワークロードの成長に応じて 12,288 MBps (1 HA ペアあたり 3,072 MBps) にスケールアップし、さらに 24,576 MBps (1 HA ペアあたり6,144 MBps) にスケールアップできます。&nbsp; ブロックストレージ – ONTAP は、最大 6 HA ペアに対応するファイルシステムで iSCSI および NVMe-over-TCP プロトコルをサポートしています。これらのプロトコルをベースにワークロードを構築する予定の場合、最大 6 HA ペアまでのファイルシステム構成を選択してください。iSCSI と NVMe-over-TCP へのアクセスを失うことなくファイルシステムを 6 HA ペア以上に拡張することはできない点に注意してください。&nbsp; クイック作成 では、ファイルシステムの Virtual Private Cloud (VPC) を選択し、最初に作成されるボリュームに対してストレージ効率を有効にするかどうかを選択します。選択後、 次へ をクリックして設定を確認し、 ファイルシステムを作成 をクリックします。FSx がファイルシステムを作成するまで、通常約 20 分かかります。 パフォーマンスとストレージの継続的な更新 ファイルシステムが作成された後、コンソール、CLI、または SDK を使用して、スループット、ストレージ、プロビジョンド IOPS、ファイルシステムがシングル AZ の場合 HA ペアを更新できます。コンソールを例にすると、ファイルシステムを選択すると、 図 : 4 に示されるように各項目を更新するオプションが表示されます。 図 : 4 – パフォーマンスの更新 リソースのクリーンアップ ファイルシステムを作成した後、不要な料金が発生しないよう、FSx for ONTAP ユーザーガイドの「 Cleaning up resources 」セクションに記載された手順に従って、リソースの削除を行うことができます。 まとめ 第 2 世代のファイルシステムは、第 1 世代のファイルシステムに比べて最大 18 倍のパフォーマンススケーラビリティを提供します。各 HA ペアのファイルシステムのスループットを最大 6 GBps までスケールアップできるだけでなく、最大 12 HA ペアでファイルシステムを作成または拡張できます。さらに、バックアップからの復元時のデータアクセスが高速化し、NVMe-over-TCP プロトコルを通じてブロックストレージワークロード向けの iSCSI に代わる簡素化された選択肢も利用できます。これらの強化により、これまで以上に要求の厳しいワークロードをサポートすることが可能になります。第 2 世代ファイルシステムは、2025 年 6 月現在、以下の AWS リージョンで利用可能です：US East (N. Virginia、Ohio) 、US West (Oregon、 N. California) 、Europe (Ireland、 Stockholm、Frankfurt) 、Asia-Pacific (Sydney、 Tokyo、Mumbai、Singapore) 。詳細については、 FSx for ONTAP ユーザーガイド をご覧ください。 このブログは 2024 年 7 月 9 日に Charles Inglis (Senior Product Manager) によって執筆された内容を 2025 年 5 月の東京リージョンでの利用可能開始に伴い日本語化したものです日本語化したものです。原文は こちら を参照してください。 <!-- '"` --> Ed Laura Charles Inglis は、Amazon FSx のテクニカル担当シニア・プロダクト・マネージャーです。彼は、新機能の構築から、さまざまな業界のあらゆる規模のお客様が ONTAP のデータ管理機能を活用してデータをさらに活用できるよう支援することまで、Amazon FSx for NetApp ONTAP のあらゆる側面に携わっています。Charles はバーベキュー、ゲーム、旅行が大好きです。 &nbsp;

本記事は、株式会社 Nint 様と Amazon Web Services Japan 合同会社が共同で執筆しました。 みなさん、こんにちは。AWS ソリューションアーキテクトの渡辺です。 この記事では、最近よく耳にする「AI エージェント」に関連する事例として、株式会社 Nint 様が取り組まれた「 Amazon Bedrock エージェント を用いたデータの分析・可視化の自動化」についてご紹介します。 ビジネスの背景と課題 株式会社 Nint は「データで世界を自由にする」というミッションのもと、日本、中国、および東南アジアにおいて大手 EC モールのデータ分析サービス「Nint ECommerce」を提供しています。このサービスは、EC モールのデータ分析 SaaS として多くの顧客に利用されている一方で、データ分析業務には高度な知識や経験が必要とされるため、いくつかの課題を抱えていました。 主な課題 データ分析には高度な知識や経験が必要とされるため、未経験者には敷居が高い データ分析スキルの獲得には、多くの時間 (1-2 ヶ月) を要する データ分析の経験者であっても、優れたインサイトを得るための分析作業には時間がかかる これらの課題を解決し、より多くのユーザーが効率的にデータ分析を実施できるようにするため、AI エージェントを活用したソリューションの開発に取り組みました。 ソリューション 株式会社 Nint では、Amazon Bedrock エージェントを活用し、対話形式でデータ分析を可能にする AI 機能「Nint AI」を開発しました。このソリューションでは、ユーザーは自然言語で分析作業をリクエストすることで、AI エージェントが自律的に必要な作業を行い、分析結果やインサイトを提示、視覚的に説明するためのグラフや図表を描画します。 図 1 : AI エージェントが自律的に情報を取得し、回答を生成する様子 図 2 : AI エージェントが自律的に情報を取得・可視化する様子 AI エージェントと呼ばれる技術を用いると、人間が設定した目標に対して、その目標を達成するために最適なアクションを AI エージェントが自律的に選択してくれます。Nint AI では、例として以下のようなアクションを AI エージェントに実行させています。 質問のカテゴリーを判断 質問内容から、対象となる商品またはその関連商品を特定 商品の詳細情報を取得 グラフ生成用のデータおよび質問への回答を生成 AI エージェントの実装に利用可能なツールはいくつかありますが、 AWS CDK を使って簡単に実装・デプロイが可能であること 使用可能なアクションを AWS Lambda 関数を使用して表現可能なため、習得済みのスキルを活用しやすいこと データやアプリケーションを保護するためのセキュリティが備わっていること などの理由から、Amazon Bedrock エージェントを採用しました。 図 3 : Amazon Bedrock エージェントを活用したデータ分析ソリューション 導入効果 Amazon Bedrock エージェントを活用したソリューションの導入により、以下の効果が得られました。 分析業務の簡易化 : 自然言語での指示や質問を通じて分析作業が可能なため、経験や経歴が浅い担当者であっても分析業務をすぐに実施できるようになりました。 作業効率の向上 : 熟練者が分析業務を行う場合においても、欲しい分析結果を取得する際にかかる時間を最大 80% 節約できるようになりました。 開発効率の向上 : Amazon Bedrock エージェントを含めたマネージドな機能を活用することで、環境の構築・運用に気を取られることがなくなり、機能要件の開発に集中できるようになりました。 株式会社 Nint プロダクト Div. ユニットリーダーのデンショウイツ様からは「Amazon Bedrock の機能をフルに活用することで、自社 SaaS の価値をさらに向上できたと感じます」とコメントをいただいています。 まとめ 本事例は、EC モールのデータ分析という専門性の高い領域において、生成 AI を活用することで業務の効率化と品質向上を実現した素晴らしい事例となっています。Amazon Bedrock エージェントを活用したソリューションを導入することで、専門知識がなくてもデータ分析が可能になり、熟練者の作業効率も大幅に向上しました。 また、AWS のマネージドサービスを活用することで、インフラの構築・運用に気を取られることなく機能開発に集中でき、短期間で高品質なサービスをリリースすることができました。 生成 AI を活用したビジネスの効率化や、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、ぜひお気軽に AWS までお問い合わせください。

本稿は、2025 年 6 月 9 日に AWS Migration &amp; 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システム開発リーダー 新谷 歩生 アマゾンウェブサービスジャパン合同会社 技術統括本部 通信グループ シニアソリューションアーキテクト &nbsp;

この記事は 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&amp;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 を通じたアプリケーションのコンテナ化のデモなどを紹介しています。 ブログ記事「【開催報告&amp;資料公開】九州ローカルミーティング AI Agent ワークショップ」を公開 2025 年 5 月 29 日に「九州ローカルミーティング AI Agent ワークショップ」というイベントを開催しました。本ブログではイベントの概要の紹介と、イベント内で登壇者が発表に使用した資料を公開しています。公開資料を用いて、ぜひ皆様も AI Agent のユースケースの発掘にトライしてみてください！ ブログ記事「【開催報告 &amp; 資料公開】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つの対応言語が追加 &nbsp; 顧客サービス向けの生成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 の会話分析とパフォーマンス評価を利用する場合には、別途料金がかかります。 &nbsp;関連リンク 外部音声転送 – 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 ペア&nbsp;のみとなります。 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&nbsp;ファイルを 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 アカウント。 アセットテーブルの読み取り権限を持つ&nbsp;system-only user&nbsp;の 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 プレフィックス:&nbsp; cmdb_ot_entity 、ServiceNow オブジェクト: OT Asset。 フロー名と Amazon S3 プレフィックス:&nbsp; 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&nbsp; を選択してください。 図 7: Crawler の properties Add an S3 data source を選択します。 Add an S3 data source&nbsp; ダイアログボックスで (図 8 を参照)、以下の手順に従います。 データソース として S3 を選びます。 S3 path として &lt;your_bucket_name&gt; を入力します。 Add an S3 data source&nbsp; を選択します。 図 8: Crawler data source Next を選択します。 IAM ロールの項目で、 Create new IAM role を選択してください (図 9 を参照)。 図 9: Crawler IAM Role ロールの名前を決めます。この例では AWSGlueServiceRole-ServiceNowCrawler を使用します。 Next &nbsp;を選択します。 ターゲットデータベースの下で、AWS Glue データベースを選択します。この例ではデフォルトのデータベースを使用しています。 図 10: AWS Glue データベースの選択 Next &nbsp;を選択します。 Create を選択します。 クロールを実行します。完了するのに約 2 分かかります。 ServiceNow の Parquet データは、Amazon S3 にインポートされました。 JSON ファイルの変換 このセクションでは、AWS Glue ジョブを設定して parquet ファイルを AWS IoT SiteWise に適した JSON 形式に変換し、データを AWS IoT SiteWise にインポートします AWS Glue ジョブを作成 AWS Glue コンソールに移動します。 左側のメニューから、 ETL Jobs &nbsp;の下にある&nbsp; Visual ETL を選択します。 Create Job で、 &nbsp;Visual ETL&nbsp; を選択します。 図 11: AWS Glue Studio Source ノードを作成します。青い プラス (+) ボタンを選択し (図 12 参照)、 Amazon S3&nbsp; を選択してください。 図 12: Visual&nbsp;ETL Name &nbsp;では、図 13 のようにノードの名前を任意につけてください。ここでは cmdb_ot_entity とします。 S3 source type&nbsp; では、&nbsp; Data Catalog table &nbsp;を選択してください。 Database &nbsp;では、前に AWS Glue Crawler のセットアップ時に選択したターゲットデータベースを選んでください。 Table &nbsp;では、最初の表 cmbd_ot_entity を選択してください。この手順を cmdb_ci_ot と cmdb_ot_entity_type の各テーブルについて繰り返してください 。 &nbsp;図 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 に次のクエリをコピー &amp; ペーストしてください。 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 に次のクエリをコピー &amp; ペーストしてください。 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&amp;amp;lt;struct&amp;amp;lt;dataType:string,externalId:string,name:string,type:struct&amp;amp;lt;attribute:struct&amp;amp;lt;defaultValue:string&amp;amp;gt;&amp;amp;gt;,unit:string&amp;amp;gt;&amp;amp;gt;' ) 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」 &nbsp;を使用します。 Node parents には、Source ノード assets と assetModels を選択します。 Input sources と SQL aliases には、図 16 のように assets と assetModels を使用します。 図 16: assetModelHierarchy 変換 SQL Query に次のクエリをコピー &amp; ペーストしてください。 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 ジョブ&nbsp;の結果を AWS IoT SiteWise にインポートするために使用するよう、変換のターゲットを追加しましょう。 変換のターゲットを追加する 図 12 に示されている青い 「+」 ボタンを選択して、新しいソースノードを作成します。 新しいノード Transform を追加し、ターゲットから Amazon S3 を選択します。 Name は何でも構いません。この例では Amazon S3 を使用しています。 Node Parents &nbsp;は、ソースノード assetModelHierarchy を選択します。 Format &nbsp;は JSON を選択します。 Compression Type は None を選択します。 S3 Target Location &nbsp;は &lt;your_destination_bucket&gt; &nbsp;を選択します。 図 17: ターゲットノードの追加 完了すると、図 18 に示すような ETL を確認できるはずです。 Save を選択してください。 それから Run を選択し、完了するまで待ちます。 図 18: アセットの階層 AWS IoT SiteWise への取り込み このセクションでは、Amazon S3 内の JSON ファイルの作成を確認し、AWS IoT SiteWise に ServiceNow のアセットをインポートします。 まず、次の操作を行って JSON ファイルが作成されたことを確認します。 &nbsp;Amazon S3 コンソールを開きます。 &lt;your_destination_bucket&gt; を選択します。 run-&lt;timestamp&gt;-part-r-00000&nbsp; ファイルを選択後、 アクション をクリック。 オブジェクトの名前変更を選択し、 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 に &lt;your_destination_bucket&gt; を選択し sitewise-import.json ファイルを指定します。 図 20: S3 import Import &nbsp;を選択し、インポートが完了するまで待ちます。 作業の検証 図 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&nbsp;、ジョブ、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 &nbsp;をご覧ください。 この記事は Mariaと Brent によって書かれた&nbsp; Integrating ServiceNow OT Asset Workspaces with AWS IoT SiteWise Asset Models &nbsp;の日本語訳です。この記事はソリューションアーキテクトの服部が翻訳しました。 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）をホストするための公開リポジトリを作成する &nbsp; 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 &gt; '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 &lt;ユーザー ID に置き換え&gt; --instance-id &lt;インスタンス ID に置き換え&gt; 図 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 &gt; '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 &lt;ユーザー ID に置き換え&gt; --instance-id &lt;インスタンス ID に置き換え&gt; 図 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 &amp;gt; '2024-06-26 00:00:00' 上記のクエリの結果は、インスタンス ID 内に関連付けられた電話番号 ID と、フローの変更を行ったユーザーの ARN を提供します。（前のセクションと同様） 図 6：フローと電話番号の関連付けを調査するためのクエリ結果 PhoneNumberId がどの電話番号に対応しているかを確認するには、CloudShell ターミナルに移動し、以下のコマンドを実行します。 aws connect describe-phone-number --phone-number-id &lt;PhoneNumberIdで置き換え&gt; 図 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 戦略、そして変革です。複雑な実世界のビジネス課題を解決するためにクラウドテクノロジーを適用することに情熱を注いでいます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。