2025 年 11 月 12 日(水) ～ 11 月 15 日(土) の 4 日間、兵庫県姫路市のアクリエひめじにて 第 45 回医療情報学連合大会 が開催されました。大会テーマは「医療 DX がもたらす医療情報新時代」。参加登録者数は 3,800 名を超え、現地では 2,900 名が参加されました。AWS は本大会において、スポンサードセッション「生成AIとヘルステックの融合が拓く、次世代の医療サービス」と展示ブースでの情報提供を通じて、医療関係者・研究者の皆様と医療 DX と生成 AI 活用の最新動向を共有する機会をいただきました。本ブログでは、セッションの登壇内容と展示ブースでの取り組みについてご報告します。 生成AIとヘルステックの融合が拓く、次世代の医療サービス AWS のスポンサードセッションでは、はじめに AWS 公共部門 ヘルスケア事業本部 本部長の大場から、医療における生成 AI の展望と Agentic AI の可能性について説明しました。続いて、 株式会社メドレー 様から、医療現場での生成 AI 活用の実践事例をご紹介いただきました。 医療における生成 AI の展望と Agentic AI の可能性 AWS 公共部門 ヘルスケア事業本部 本部長　大場 弘之　登壇 [ slide ] AWS では、医療機関が安全かつ効率的に生成 AI を活用できるよう、Amazon Bedrock を中核とした包括的なサービスを提供しています。Bedrock では、お客様のデータが基盤モデルの学習に利用されることはなく、プライベートかつセキュアな利用が可能です。Claude Sonnet 4.5/ Claude Haiku 4.5 / Nova 2 Lite 等の一部のモデルでは 日本国内に限定したクロスリージョン推論 を提供しています。これらにより、お客様が医療情報ガイドラインをはじめとした、高いコンプライアンス要件に準拠するための実装をサポートしています。 セッションでは、生成 AI の進化の中でも特に注目される Agentic AI について説明しました。従来の Chatbot が単純な質問応答を行い、RAG（Retrieval-Augmented Generation）が組織固有の知識を活用した回答を提供するのに対し、Agentic AI は多様なツールやシステムと連携しながら、複雑なタスクを自律的に実行できる点が特徴です。医療現場では、この Agentic AI が診療記録の作成や検査オーダー、文書作成など、医療従事者の業務を包括的に支援する可能性を持っています。 AWS Japan は ヘルスケア・ライフサイエンス業界向けの生成 AI デモ・AI エージェントツール群として「 HealthData x Agent 」を 10月に公開しました。医療現場で Agentic AI がどのように活用できるのか、具体的なユースケースを通じて体験いただけます。AWS では、医療における AI エージェントの展開を支援するため、開発から本番環境への展開まで、段階に応じた多様なサービスを提供しています。AI エージェント開発のためのオープンソース SDK (Software Development Kit) の Strands Agent のほか、 Amazon Bedrock Agents ではエージェント開発からクラウドへのデプロイまでフルマネージドに利用できます。さらに Amazon Bedrock AgentCore を活用すれば、任意のフレームワークや基盤モデルで開発したエージェントを大規模かつ安全に運用できます。これらの強力なサービスを通じて、医療における AI エージェントの展開を推進してまいります。 AWS を活用されているお客様の最新事例は「 医療機関向け これから学ぶ AWS クラウド 」をご確認ください。 医療 AI の現在と未来：クラウド電子カルテが描く未来の世界観 株式会社メドレー 医療プラットフォーム本部 医科診療所プロダクト開発室長　佐藤 雄介 様　登壇 [ slide ] 医師の働き方改革が進む中、特に診療所では医療文書作成が多くの業務時間を占めており、医師が診療や患者との対話により注力できる環境の整備が急務となっています。2024 年 4 月に施行された「医師の働き方改革」により時間外労働の上限規制が適用され、医師の長時間残業は全体として減少傾向にありますが、診療所における経営者である医師の長時間労働は依然として常態化しています。こうした背景から、医療 AI 市場の成長が期待されています。次世代医療プラットフォームを提供する メドレーの佐藤様からは、人件費の AI 置換率が 5 年で 2.5%、10 年で 5% というベースケースを仮定した場合、生成 AI の技術革新により医療 AI 市場が 2035 年には約 1.5 兆円規模に達するとの予測を紹介いただきました。 セッションでは、医療現場での実証実験を通じて、生成 AI がカルテ作成や医療文書作成業務の効率化に貢献できることが紹介されました。診察中の発話をリアルタイムで文字起こしし、AI が自動要約する仕組みでは、SOAP 形式など複数のフォーマットに対応し、1 クリックでカルテに転記できます。これにより、医師が「メモを取ることに集中しなくてよい」という安心感を提供し、患者との対話により集中できる環境を実現します。 実際の医療機関での先行利用では、カルテ作成時間を約 11.3% 削減されることが確認されました。医師からは「1 日あたり 30 分〜 1 時間程度、カルテ入力にかかる時間が短縮している」との声があり「メモを取ることに集中しなくてよい」安心感が大きいとのフィードバックが得られています。患者からも「最新技術を取り入れている」「話したことをきちんと記録してもらえる」と好意的な反応が得られており、生成 AI は医療従事者の業務効率化だけでなく、患者体験の向上にも寄与することが示されました。詳細はメドレー様の プレスリリース をご参照ください。 セッション後半では、生成 AI が医療プロセスをどのように変革していくかというビジョンについてご発表いただきました。 まず、今後の展望として、主治医意見書作成のような個別業務において生成 AI がアシストする機能が拡張されていくとのお話がありました。さらに、AI エージェントが患者とコミュニケーションを行うことで、早期のリスク検出や診療前の事前準備が可能になるなど、エージェント技術が医療の質向上に貢献する可能性についてもご紹介いただきました。 具体的なユースケースと将来展望を交えたセッションの内容は、医療現場での AI 活用を検討される聴講者の皆様にとって、大変有益な示唆に富むものとなりました。 展示ブース 展示ブースでは、パネルとデモを通じて医療分野における生成 AI 活用についてご紹介しました。特に、デモ展示では包括的な生成 AI を活用したビジネスインテリジェンスプラットフォームの Amazon Quick Suite をはじめ、生成 AI 関連のサービスやソリューションを展示しました。データの可視化と自然言語によるデータ分析をテーマにデモンストレーションを実施し、来場者の皆様に実際にご覧いただき、操作も体験いただきました。会場では多くのご質問やフィードバックをいただきました。 パネル展示で特に注目を集めたのが、医療機関が直面する生成 AI 活用の課題を解決するための「 ANGEL Dojo 」という内製化支援プログラムです。ANGEL Dojo は参加組織から選出された 10 名程度のメンバーでチームを組み、約 3 ヶ月間でサービスの企画から開発までを行うトレーニングです。特徴としては、 AWS パートナーによる「共創型内製化」を実現する点にあります。2025 年 10 月に開催された ANGEL Dojo 2025 では、初めて医療機関からご参加いただき、2 つの病院から成果を上げられました。兵庫県立リハビリテーション中央病院様では、富士ソフト株式会社と協力し、スケジュール作成時間を 80% 短縮し、60% の自動化を実現されました。特筆すべき点として、IT 知識ゼロの総務部の方が、90 日間で AWS の上での開発におけるベストプラクティスである Well-Architected フレームワーク に則ったシステム構成を実装されました。熊本中央病院様では、キヤノン IT ソリューションズ株式会社と協力し、月 800 時間の文書作成時間削減を実現し、月 2,000 件以上の文書作成業務を効率化されました。看護師をはじめとした病院内の方々がチームを構成し、実用的なシステムを開発された点が特筆されます。両病院の取り組みの詳細については、ANGEL Dojo のブログ記事「 地方病院がシステムの内製化に挑戦!? IT 知識ゼロから始めた生成 AI による業務効率化への 90 日 」をご参照ください。 おわりに 第 45 回医療情報学連合大会を通じて、医療 DX における生成 AI の可能性と、それを実現するための具体的なアプローチについて、多くの医療従事者・研究者の皆様と議論を深めることができました。ANGEL Dojo の事例が示すように、IT 知識がない状態からでも、適切な支援とパートナーシップがあれば、医療機関自らが生成 AI を活用したシステムを構築することが可能です。 AWS は今後も、医療機関の皆様が安全かつ効率的に生成 AI を活用できるよう、包括的なサービスとサポートを提供してまいります。医療 DX や生成 AI 活用についてご関心がある方は、ぜひ AWS までお問い合わせください。本大会でお会いできた皆様、貴重なご意見をいただいた皆様に、この場を借りて御礼申し上げます。 Yohei Katayama 片山 洋平 は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

午前2時。携帯電話に緊急のアラートが届きます: 主要港湾の閉鎖、47件の入荷便への影響、そして72時間後に迫ったプロモーション開始。急いでノートパソコンを開き、在庫ダッシュボード、物流プラットフォーム、サプライヤーポータルといった十数個の異なるシステムを確認します。これらは今起きている状況の一部しか伝えておらず、必要な答えは得られません。市場シェアを競合他社に奪われる前に、どのように出荷を再ルーティングし、在庫を再配分し、プロモーションでコミットした出荷量を維持できるのでしょうか？ 主要港湾の閉鎖などの混乱がサプライチェーンに影響を与える場合、一分一秒が重要です。小売・消費財企業にとって、労働力不足、気象現象、予期しない港湾閉鎖によるサプライチェーンの混乱は、数百万ドルの収益損失とステークホルダーとの関係の悪化をもたらす可能性があります。これらの混乱を管理し対応を策定することは、現代的なデータ駆動型で相互接続されたサプライチェーンを持つ組織であっても手動プロセスのままです。そのため従来のシステムは、データの処理、複数のステークホルダー間の調整、重要な時間内での実行可能な推奨事項の策定といった対応に苦慮することになります。 サプライチェーンレジリエンスの課題 現代の小売・消費財企業のサプライチェーンは、グローバルサプライヤー、配送センター、輸送ネットワーク、小売拠点にまたがる複雑なネットワークです。混乱が発生すると、意思決定者はいくつかの重要な課題に直面します。 データの断片化: 在庫システム、物流プラットフォーム、サプライヤーデータベース、外部データソースに重要な情報の散在 時間的制約: 出荷の再ルーティングや在庫の再配分において時間が重要に 複雑性: 並行して最適化が必要な複数の相互依存する変数の存在 ステークホルダーの調整: サプライヤー、物流プロバイダー、社内チーム間で同期した対応の必要性 従来のアプローチは手動分析と順次処理の意思決定プロセスに依存しており、現代のサプライチェーンの混乱の速度と複雑さに単純についていけません。 マルチエージェント AI: サプライチェーンインテリジェンスの新しいパラダイム マルチエージェント AI アーキテクチャは、複雑なビジネス問題へのアプローチ方法における根本的な変化を表しています。問題のすべての側面を処理しようとする単一の AI システムの代わりに、専門化された AI エージェントが協調して作業し、それぞれが専門分野に焦点を当てながら、スーパーバイザーエージェントがその結果を統制します。 現在一般提供されている Amazon Bedrock AgentCore のマルチエージェント協調機能と最新の基盤モデルを組み合わせることで、専門エージェントが連携してサプライチェーンの混乱にリアルタイムで対処する本番対応システムを構築できます。 アーキテクチャ概要: 協調して動作する専門エージェント 私たちのデモンストレーションのアーキテクチャは、Amazon Bedrock が提供する基盤モデル、Amazon Bedrock AgentCore が提供するAIエージェント運用機能、マルチエージェント協調機能を活用して、回復力のあるサプライチェーン対応システムを構成します。アーキテクチャは以下で構成されます。 スーパーバイザーエージェント: サプライチェーンコーディネーター 受信した混乱アラートを分析 専門エージェントにタスクを委任 推奨事項を実行可能な提案に統合 全体の対応ワークフローにわたってコンテキストを維持 専門協力エージェント: 物流最適化エージェント 代替輸送ルートの評価 運送業者の利用可能性と輸送能力の評価 利用可能な輸送と詳細の調査 物流調整の推奨事項の検証 実行レポートの物流コンポーネントの生成 在庫エージェント 混乱イベントおよび他のエージェントからの入力の検証 提案された様々なソリューションの影響分析の実行 在庫不足と提案された輸送の結果の計算 プロモーションリスクエージェント 混乱の影響を受ける製品および提案されたソリューションに含まれる製品への影響の分析 混乱または提案された代替案に影響を与える可能性のある関連プロモーションデータの取得 他のエージェントへのプロモーションの詳細の提供 出荷追跡エージェント 提案された調整に影響を与える上流の出荷遅延に関する詳細の提供 実現可能性レビューを通じて出荷先オプションの検証 AWSサービスを使用した技術的実装 このアーキテクチャは、エンタープライズ規模の AI アプリケーション向けに設計されている AWS サービスの基盤に構築されています。 Amazon Bedrock AgentCore は、ランタイム、メモリ、アイデンティティ、可観測性、API 統合機能を含む、AI エージェントを安全かつ大規模に展開・運用するためのインフラストラクチャを提供します。Amazon Bedrock AgentCore Runtime に展開されたマルチエージェントアーキテクチャにより、各専門エージェントは以下のことが可能になります。 マルチステップワークフローを自律的に実行 ナレッジベースを通じてエンタープライズデータソースに安全に接続 リアルタイムデータアクセスのためにAPIとアクショングループの呼び出し 会話のコンテキストとメモリの維持 マルチエージェントコラボレーションにより、スーパーバイザーエージェントは以下のことが可能になります。 複雑な混乱シナリオを管理可能なタスクに分解 適切な専門エージェントに委任 エージェント間の情報フローの調整 出力を包括的な推奨事項に統合 主要技術機能 インラインエージェント: 柔軟な対応シナリオのための実行時のエージェントの役割の動的な調整 ペイロード参照: 転送オーバーヘッドを削減し応答時間を改善する効率的なデータ処理。これにより、混乱イベントによりエージェントがトリガーされます。サプライチェーン担当者は混乱を解決するために対応を開始する時点で、ビジネス目標に合致したデータ駆動型の検証可能な解決計画を手にすることができます。 強化されたトレーサビリティ: 各エージェントの思考、カスタマイズされたツール相互作用の結果、ビジネス整合性のために生成 AI のハルシネーションに左右されない決定論的最適化戦略を含む、本番運用のための包括的な監視とデバッグ機能。 デモウォークスルー: 港湾閉鎖シナリオ 入荷便に影響する主要西海岸港湾の閉鎖を例にとって、システムが実世界の混乱にどのように対応するかを見てみましょう。 ステップ 1: 混乱の検出 システムは港湾閉鎖に関するアラートを受信します。それには影響を受ける出荷、推定期間、影響を受ける SKU の情報が含まれています。 図1: 配送分析　港湾閉鎖: 台風がシンガポールに影響を与えると予想されます。 図 1 に示されるように、システムは小売ユースケースと港湾閉鎖を混乱として特定しました。このシナリオでは、台風がシンガポールに影響を与えることが予想されます。画面は分析プロセスの開始を促す混乱イベントのシミュレーションを示しています。 ステップ 2: スーパーバイザーエージェント分析 サプライチェーンオーケストレーターは混乱の範囲を分析し、対応計画を作成し、専門エージェントにタスクを委任します。 図2: 混乱への対応の戦略 図2は、マルチエージェントアプリケーションによって特定された具体的な混乱への対応の戦略を表示しています。2つの推奨事項が示されており、1つは港湾閉鎖によって遅延する出荷をカバーするために利用可能な在庫の完全な移転です。2つ目の推奨事項は、今後のプロモーションキャンペーンをカバーするための追加の移転の提案です。図は、提案された戦略を承認または拒否するオプションも示しており、人間のドメイン・エキスパートがプロセスに依然として関与していることを示しています。 ステップ 3: マルチエージェント最適化戦略 在庫インテリジェンス・エージェントは、在庫切れを最小限に抑えるために活用できる代替在庫を持つ関連配送センターを特定します。 在庫エージェントは、SKU 毎およびパレット毎の詳細、ならびに注文のタイムリーな影響と将来予測される在庫影響を取得・提供します。 プロモーションリスク・エージェントは、最適化戦略に影響を与える可能性のある関連プロモーションデータを決定するために、利用可能な製品を今後のプロモーションに関連付けます。 出荷追跡エージェントは、実世界の出荷データに対して最適化を検証するために、アクティブおよび提案された出荷を調査します。 図3: マルチエージェント連携 図 3 は、小売シナリオにおける相互作用戦略とともに、各専門エージェントとそれぞれのタスクを示しています。サプライチェーンコーディネーター・エージェント、ロジスティクス・エージェント、在庫エージェント、プロモーションリスク・エージェント、および出荷追跡エージェントが、マルチエージェント連携に含まれています。 ステップ 4: 統合推奨事項 スーパーバイザーエージェントは、このシナリオの調査結果を次の3つのデータ駆動型提案に統合します。 即座の再配分: 需要の少ない地域から既存在庫を再配分 代替ルーティング: 3日遅延でメキシコ湾岸港を通じて出荷を再ルーティング サプライヤー加速: 5日のリードタイムで重要SKUのバックアップサプライヤーを活用 各提案には、コストへの影響、タイムライン見積もり、リスク評価が含まれ、すべて初期の混乱アラートから数分以内に生成されます。 図 4: 承認に基づく影響の概要を示しています。 特定されたシナリオである港湾閉鎖に対する承認された戦略に基づく影響のサマリーが示されています。マルチエージェント・アプリケーションは、受け入れられた提案が輸送コストで-$4,275、確保できる総収益で$28,500の結果をもたらすと判断しました。また、注文番号、注文あたりの単位、アイテム ID、配送センター、到着日を含む両方の承認された移転注文も表示されています。 ビジネスインパクトと測定可能な成果 サプライチェーンの回復力のためにマルチエージェントAIアーキテクチャを実装する組織は、次の重要な利益を得ています。 速度: 複雑な混乱シナリオに対する応答時間を時間から分に短縮 精度: データ駆動型推奨事項が推測を排除し、コストのかかるエラーを削減 拡張性: 追加人員なしで複数の同時混乱を処理 透明性: コンプライアンスと学習のための意思決定プロセスの完全な監査証跡 マルチエージェントアプローチは継続的改善も可能にします。それぞれの混乱対応は、個別の長期記憶戦略として Amazon Bedrock Agent Core Memory に保持され、エージェントのパフォーマンスを改善し機能を拡張します。監査人とコンプライアンスは、エージェントプロセスをレビューし、意思決定方法を記録し、Amazon Bedrock AgentCore Policy を通じて既存のポリシーに従ってすべての決定が行われたことを確認するためにメモリをレビューすることができます。 Amazon Bedrock AgentCore は、組み込まれたセキュリティ、拡張性、可観測性を備えた、プロトタイプから本番環境への移行に必要な本番グレードのインフラストラクチャを提供します。 結論: サプライチェーンレジリエンスの未来 サプライチェーンの混乱は避けられないものですが、その影響は避けられないものである必要はありません。Amazon Bedrock AgentCore を基盤とするマルチエージェントAIアーキテクチャは、小売・消費財企業が複雑性と不確実性に対応する方法における根本的な進歩を表しています。 専門化された AI エージェントが複雑な問題に協力して取り組むことを可能にすることにより、組織はサプライチェーンの混乱を危機から、明確でデータ駆動型の対応のみちすじを持つ管理可能なイベントへと変化させることができます。 このテクノロジーは今日、本番環境で利用可能です。技術リーダーにとっての問題は、サプライチェーンの回復力のためにマルチエージェント AI を採用するかどうかではなく、次の混乱からビジネスを守るためにどれだけ迅速に実装できるかということです。 マルチエージェント AI をサプライチェーンに活用する準備はできていますか？ NRF 2026: Retail’s Big Show のブース 4438 にある AWS Industries Retail & Consumer Goods スペースを訪れて、実際のデモをご覧ください。また、本番環境対応のマルチエージェントシステムの構築について詳しく知るには、 Amazon Bedrock AgentCore のドキュメントをご確認いただくか、お客様固有のサプライチェーンの課題について話し合うために AWS アカウントチームにお問い合わせください。 著者について David Bounds David は AWS のエンタープライズソリューションアーキテクトで顧客が AWS 上で彼らのワークロードを加速することを支援しています。機械学習と生成 AI に焦点を当て、あらゆる種類、視点、経験レベルの顧客に技術支援を提供しています。David はロンドンに住み、天気を愛し、ボクサー犬の散歩、そして物語の収集を楽しんでいます。 Angel Goni Oramas Angel はアトランタを拠点とするプリンシパルソリューションアーキテクトで、金融サービス、小売、消費財業界にわたって15年以上の IT 経験を持っています。 本稿の翻訳は、ソリューションアーキテクトの斉藤大徳が担当しました。原文は こちら 。

本記事は 2025 年 12 月 9 日 に公開された「 Amazon CloudWatch RUM now supports mobile application monitoring 」を翻訳したものです。 Amazon CloudWatch RUM のモバイル対応を発表できることを嬉しく思います。これにより、AWS のリアルユーザーモニタリング (RUM) 機能が iOS および Android アプリケーションにも拡張されます。これまで Web アプリケーションでのみ利用可能だったモニタリングツールが、モバイル開発者にも提供されるようになりました。 モバイルデバイスが日常生活においてますます重要になる中、モバイルアプリの最適なパフォーマンスとユーザーエクスペリエンスを確保することがこれまで以上に重要になっています。しかし、モバイルアプリのモニタリングには、デバイス、オペレーティングシステム、アプリケーションバージョン、ネットワーク、ユーザーインタラクションの多様性により、独特の課題があります。モバイルアプリ開発者は、「テストでは完璧に動作するのに、実環境ではパフォーマンスの問題が発生する」という継続的な課題に直面しています。合成テストや従来のモニタリング手法は実世界のパフォーマンスに関する洞察を提供しますが、エンドユーザーエクスペリエンスを理解するために必要なデータが不足しています。そこで CloudWatch RUM Mobile の出番です。実際のユーザーの手の中でモバイルアプリがどのように動作しているかについて深い洞察を提供するメトリクスを収集できます。 モバイル向け Amazon CloudWatch RUM モバイル向け Amazon CloudWatch RUM は、エンドユーザーのモバイルアプリが使用される際に、非常に重要なパフォーマンスデータとユーザー行動メトリクスを収集するのに役立ちます。軽量な SDK を Android または iOS アプリに実装することで、アプリのパフォーマンス、ユーザーインタラクション、ユーザーエクスペリエンスに影響を与える潜在的な問題に関する豊富な情報をキャプチャできます。 開始するには、CloudWatch RUM コンソールで「アプリケーションモニター」を作成し、SDK をアプリに統合してデプロイするだけです。SDK はユーザーがアプリを操作する際にバックグラウンドで実行され、貴重なデータを RUM に送信して集約と分析を行います。このツールは単独で使用することも、 Amazon CloudWatch Application Signals や AWS X-Ray などの他の AWS サービスと組み合わせて使用することもでき、Web およびモバイルプラットフォーム全体でアプリケーションのパフォーマンスを包括的に把握できます。 開発プロセスを変革する主なメリット CloudWatch RUM Mobile は、開発チームがリアクティブなデバッグからプロアクティブな最適化へと移行できるようにします。実際のユーザーからリアルタイムのパフォーマンスメトリクスを収集し、ユーザー満足度に影響を与える前にパフォーマンスの問題を特定できます。システムは画面の読み込み時間を監視し、アプリのクラッシュ、Android の ANR (Application Not Responding) または iOS のアプリハングを完全なコンテキストとともに追跡し、これらすべてのデータを包括的なダッシュボードで視覚化します。 変革は即座に起こります。ユーザーからの苦情を待ったり、バグを再現しようとしたりする代わりに、ユーザーがアプリとやり取りするたびに何を経験しているかについて、明確で実用的な洞察が得られます。 はじめに: モバイルモニタリング強化への道 このブログでは、 Amazon CloudWatch RUM を Android および iOS モバイルアプリに統合する方法を学びます。モバイル向け CloudWatch RUM の使用を開始するには、以下の詳細な手順に従って、Android または iOS アプリのモニタリングをセットアップして実装します。 Android 用アプリケーションモニターのセットアップ 開始するには、まず「アプリケーションモニター」を作成する必要があります。これを行うには、 AWS CloudWatch コンソール を開き、 Application Signals に移動して RUM を選択します。次に「 Add app monitor 」をクリックします。 図 1: AWS CloudWatch コンソールからアプリモニターを作成 これで「Android」と「iOS」という 2 つの新しいオプションが表示されます。「App monitor name」の下でアプリモニターに名前を付け、プラットフォームとして「Android」または「iOS」のいずれかを選択して続行します (ここでは Android を選択します)。 図 2: アプリケーションモニターの作成 – Android と iOS のオプション 要件に基づいて有効にできるいくつかの「オプション」フィールドがあります。 RUM テレメトリ を Amazon CloudWatch Logs で利用できるようにする場合は、「Data Storage」オプションをチェックします リソースベースのポリシーを使用してアクセスを制御する場合は、「Attach a public Resource Based Policy」をチェックします スパン を X-Ray で利用できるようにする場合は、「Active tracing」オプションをチェックします 図 3: アプリケーションモニターの作成 – オプションフィールド Add app monitor をクリックして完了します。 コンソールは、データの収集を開始するために Android アプリケーションに追加する必要がある コードスニペット を提供します。コードは 「手動計装」 と 「ゼロコード計装」 の両方で提供されます。 スニペットを保存しましょう。これは、このブログの後半の「 Android アプリの計装 」セクションで使用します。 図 4: アプリモニターの作成 – 手動およびゼロコード計装用のコードスニペット Android アプリの計装: 実装パスの選択 アプリケーションモニターが作成されたので、テレメトリデータをアプリケーションモニターに送信するようにモバイルアプリを計装しましょう。上記で気づいたように、モバイルアプリを計装または設定するには、 ゼロコード計装 と 手動計装 の 2 つのオプションがあります。 まず、「 アプリケーションモニターのセットアップ 」セクションのコードスニペットを手元に用意してください。このセクションを完了するために必要になります。コードは https://github.com/aws-observability/aws-otel-android でも入手できます。それでは、これらの各オプションを確認しましょう。 オプション 1: ゼロコード計装 (エージェント) これには、まずアプリケーションの "app/build.gradle" ファイルにいくつかの依存関係を注入する必要があります。以下は Kotlin DSL の例です。 plugins { id("com.android.application") id("org.jetbrains.kotlin.android") } dependencies { // ADOT Android Agent - includes automatic instrumentation implementation("software.amazon.opentelemetry.android:agent:1.0.0") // Automated HTTP client instrumentation with byteBuddy (optional but recommended) byteBuddy("io.opentelemetry.android.instrumentation:okhttp3-agent:0.15.0-alpha")// if you are using OkHttp-3.0 byteBuddy("io.opentelemetry.android.instrumentation:httpurlconnection-agent:0.15.0-alpha") // if you are using URLConnection/HttpURLConnection /HttpsURLConnection } 次に、ゼロコード設定では、アプリケーションの "res/raw" ディレクトリの下に "aws_config.json" というファイルを作成し、以下のコードスニペットを記述する必要があります ( 各パラメータの値を必ず置き換えてください ) 。 { "aws": { "region": "<your-region>", // specify the AWS region your app monitor has been created in "rumAppMonitorId": "<your-app-monitor-id>", // replace with the ID of the app monitor created above }, // optional attributes that will be appended to all OpenTelemetry application spans and events " otelResourceAttributes ": { "service.name": "<your_app>", // Note: Update this with your application name "service.version": "1.0.0" // specifying service.version will allow you to filter telemetry on the RUM console based on your running app's version } } これで完了です! これは、Android エージェントを初期化し、CloudWatch RUM アプリケーションモニターへのテレメトリの収集を開始するために必要な最小限のものです。 オプション 2: 手動計装 クライアントをプログラムで設定するには、オプション 1 で使用した「agent」モジュールの代わりに、軽量な「core」モジュールを使用します。これには、アプリケーションの "app/build.gradle" ファイルに以下の SDK を追加しましょう。 plugins { id("com.android.application") id("org.jetbrains.kotlin.android") } dependencies { implementation("software.amazon.opentelemetry.android:core:1.0.0") // Automated HTTP client instrumentation with ByteBuddy (optional but recommended) byteBuddy("io.opentelemetry.android.instrumentation:okhttp3-agent:0.15.0-alpha") byteBuddy("io.opentelemetry.android.instrumentation:httpurlconnection-agent:0.15.0-alpha") } 次に、アプリケーションで AWS Distro for OpenTelemetry (ADOT) Android エージェントを初期化する必要があります。 class MyApplication : Application() { override fun onCreate() { super.onCreate() OpenTelemetryRumClient { androidApplication = this@MyApplication awsRum { region = "<your-region>" appMonitorId = "<your-app-monitor-id>" } otelResource = Resource.builder() .put("service.name", "MyApp") // Note: Update this with your application name .put("service.version", "1.0.0") // Note: Keep this updated with latest version .build() } } } 最後に、Application クラスがまだない場合は、この新しい「MyApplication」を Android マニフェストに登録する必要があります。 <application> android:name="com.example.MyApplication" <!-- All other attributes, activities, etc --> android:label="MyApplication"> </application> この後、アプリケーションを実行して、アプリケーションモニターへのテレメトリの受信を開始できるはずです。 iOS 用アプリケーションモニターのセットアップ iOS アプリケーション用の アプリケーションモニター を作成するプロセスは、上記で示した Android アプリケーションの場合と同じです。iOS 用のアプリモニターが作成されたら、テレメトリデータの送信を開始するためにアプリケーションを計装する方法を見てみましょう。iOS のコードも https://github.com/aws-observability/aws-otel-swift で入手できます。 オプション 1: ゼロコード計装 (エージェント) Android の「アプリケーションモニター」と同様に、「アプリケーションモニター」作成の最終ページで iOS アプリを計装するための「 コードスニペット 」を取得できます。これらの手順に基づいて、 Swift SDK の依存関係をアプリケーションの "Package.swift" ファイルに注入します。 // In your package dependencies: dependencies: [ .package(url: "https://github.com/aws-observability/aws-otel-swift.git", .upToNextMajor(from: "1.0.0")) ] // In your target dependencies: targets: [ .target( name: "<YourAppTarget>", dependencies: [ // Only for automatic initialization .product(name: "AwsOpenTelemetryAgent", package: "aws-otel-swift"), ] ) ] SDK は、「AwsOpenTelemetryAgent」モジュールがアプリにインポートされると自動的に初期化されます。アプリバンドルのルートディレクトリで "aws_config.json" という名前のファイルを探します (各パラメータの値を必ず置き換えてください) 。 { "aws": { "region": "<your-region>",// specify the AWS region your app monitor has been created in "rumAppMonitorId": "<your-app-monitor-id>" // replace with the ID of the app monitor created above }, "otelResourceAttributes": { "service.name": "<your-app>", // Note: Update this with your application name "service.version": "1.0.0" // Note: Keep this updated with latest application version } } オプション 2: 手動計装 クライアントをプログラムで設定するには、プロジェクトの "Package.swift" ファイルに以下の依存関係を追加します。 // In your package dependencies: dependencies: [ .package(url: "https://github.com/aws-observability/aws-otel-swift.git", .upToNextMajor(from: "1.0.0")) ] // In your target dependencies: targets: [ .target( name: "YourAppTarget", dependencies: [ .product(name: "AwsOpenTelemetryCore", package: "aws-otel-swift"), ] ) ] 次に、アプリケーションで ADOT Swift エージェントを初期化します。 import AwsOpenTelemetryCore class AppDelegate: UIResponder, UIApplicationDelegate { func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { AwsOpenTelemetryRumBuilder.create( config: AwsOpenTelemetryConfig( awsRum: AwsRumConfig( region: "<your-region>", appMonitorId: "<your-app-monitor-id>" ), otelResourceAttributes: [ "service.name": "<your-app>", // Note: Update this with your application name "service.version": "1.0.0" // Note: Keep this updated with latest application version ] ) )?.build() return true } } アプリのパフォーマンスの可視化: データが洞察に変わる場所 モバイル向け CloudWatch RUM がデータの収集を開始すると、CloudWatch RUM はモバイルパフォーマンスのコマンドセンターに変わり、生のパフォーマンスデータを実用的な洞察に変える複数の専門的なビューを提供します。 表示される RUM アプリケーションモニターのリストから、上記のセクションで作成したアプリケーションモニターを選択します。これにより、Performance、Errors、Sessions、Metrics、Configuration などのさまざまなタブを持つダッシュボードが表示され、画面、アプリバージョン、OS バージョン、デバイス、国、リージョン、地域によるフィルタリング機能が提供されます。 Performance タブ: 速度と応答性の詳細な分析 CloudWatch RUM コンソールの Performance タブは、モバイルアプリのパフォーマンスに関する洞察を提供します。この詳細ビューでは、画面読み込み時間を画面名、OS バージョン、アプリバージョン、デバイス、国別に分類して表示します。以前は見えなかったパターンが明確になります。特定の国ではネットワークインフラストラクチャの違いによりアプリのパフォーマンスが異なる、または特定のデバイスモデルが特定の機能で苦労しているなどです。チャート内の 画面読み込み時間のデータポイント をクリックすると、右側に診断パネルが開き、データポイントに関連する詳細な洞察 (最新の関連セッションなど) と、1 つまたは他の類似セッションのトラブルシューティングを行うための Sessions タブへのリンクが提供されます。 App Launch time ビューでは、アプリケーションの起動パフォーマンスを詳細に分析し、起動タイプ (コールド/ウォーム)、OS バージョン、アプリバージョン、デバイス、国別に起動時間を分類します。この詳細なビューは、パフォーマンスのボトルネックを特定するのに役立ちます。特定の OS バージョンでコールドスタートが遅い、または特定のデバイスモデルが初期化で苦労しているなど、最も影響力のあるユーザーセグメントに対して的を絞った最適化の取り組みを可能にします。 Locations タブは、アプリケーションパフォーマンスに関する地理的な洞察を提供し、国、リージョン、地域全体のメトリクスを表示して、場所ベースのパフォーマンスパターンを明らかにします。このビューは、地域のインフラストラクチャの課題、ネットワークレイテンシーの問題、またはユーザーがパフォーマンスの低下を経験している地理的エリアを特定するのに役立ちます。 図 5: AWS CloudWatch RUM – Performance タブ Errors タブ: デバッグの相棒 Errors タブは、エラー追跡を体系的な問題解決に変換します。アプリケーションの問題を 3 つのカテゴリに分類します: Network Errors、Crashes、ANRs/App hangs。Network Errors タブには、HTTP リクエストの折れ線グラフがあり、HTTP パフォーマンスメトリクスを表示し、左の Y 軸に失敗率 (HTTP エラー、HTTP フォールト、ネットワーク障害) を、右の Y 軸に HTTP レイテンシーを示します。この時系列データポイントにより、ユーザーはクリックして、診断パネルでトラブルシューティングのために関連するスパンとセッションを表示できます。下部のテーブルには、最も一般的な 100 のネットワークルートがリストされます。 同様に、 Crashes および ANRs/App hangs タブには、各エラーのカウントの折れ線系列が表示されます。下部のテーブルには、最も一般的な上位のクラッシュメッセージ/ANR スタックトレースが表示されます。エラーメッセージをクリックすると、クイックリファレンス用にスタックトレース全体がポップアップ表示されます。 図 6: AWS CloudWatch RUM – Errors タブ Sessions タブ: ユーザージャーニーの追跡 次に、 Sessions タブでは、詳細なウォーターフォール表示を使用して、アプリ内の個々のユーザージャーニーを追跡できます。これらの可視化は、ユーザーインタラクション中に時間がどこで費やされているか、ユーザーがどこで摩擦や遅延を経験しているかを正確に示します。このユーザー中心のビューは、技術的なパフォーマンスだけでなく、全体的なユーザーエクスペリエンスを最適化するのに役立ちます。 すべてのセッションをリストするテーブルがあり、時刻の降順にソートされています。下部には、選択したセッションのすべてのテレメトリを視覚化するウォーターフォールがあります。ウォーターフォールの各行を選択して、診断パネルを開くことができます。行が HTTP リクエストの場合、トレースコンソールにディープリンクされた traceId があります。例外、クラッシュ、または ANR/App hang を受信した HTTP リクエストの場合、診断パネルにはスタックトレースを表示する Exception タブもあります。ウォーターフォールの「View」ボタンは、ワンクリックで例外に直接移動する簡単な方法でもあります。 図 7: AWS CloudWatch RUM – Sessions タブ – ARN 図 8: AWS CloudWatch RUM – Sessions タブ – HTTP traceId Metrics タブ: アプリケーションヘルスのモニタリング Metrics タブは、レイテンシー、エラー、ボリューム、拡張メトリクスに関するアプリケーションのパフォーマンスに関するリアルタイムデータを視覚化するのに役立つ包括的なダッシュボードを提供します。 このタブには、右上に「 Add to dashboard 」というオプションもあり、このデータを他の CloudWatch ダッシュボードにエクスポートできます。 図 9: AWS CloudWatch RUM – Metrics タブ Configuration タブ: 継続的な管理 最後に、 Configuration タブは、アプリモニター設定とインストルメンテーションコードスニペットへのアクセスを容易にし、モニタリングのニーズが進化しても、継続的な管理と更新を容易に行えます。 図 10: AWS CloudWatch RUM – Configuration タブ まとめ モバイル向け Amazon CloudWatch RUM は、モバイルアプリケーションのオブザーバビリティをリアクティブなトラブルシューティングからプロアクティブな最適化に変革し、パフォーマンスモニタリングを通じてビジネスインパクトをもたらします。チームは、地域のクラッシュを引き起こすローカライゼーションのバグや、コールドスタートのパフォーマンスを低下させるサードパーティ SDK などの重要な問題を特定して解決できます。CloudWatch Application Signals とのシームレスな統合により、モバイルユーザーエクスペリエンスからバックエンドの依存関係までのエンドツーエンドのトレースが可能になります。 この機能は、CloudWatch RUM が動作するすべての商用リージョンで利用できます。この実装により、チームは既存の開発ワークフローを維持しながらパフォーマンスデータを収集でき、アプリケーションスタック全体でトレースされたユーザーセッションからのメトリクスを使用して、組織がモバイルアプリ開発にアプローチする方法を変えます。 この新機能の詳細については、 ドキュメント をご覧ください。また、 Android および iOS の入門ガイドもご覧ください。最後に、 料金 の詳細もご確認いただけます。 著者について Ruchika Modi Ruchika Modi は、Amazon Web Services (AWS) の Lead DevOps Consultant です。クラウドインフラストラクチャ、自動化、コンテナ化、CI/CD を専門としています。安全でスケーラブルかつ高可用性のクラウドネイティブアーキテクチャの構築において豊富な経験を持ち、DevOps 手法を使用した最先端のクラウドソリューションの設計と実装に関する深い理解と専門知識を持っています。仕事以外では、未開拓の新しい場所への旅行、ペットとの時間、Kindle での読書を楽しんでいます。 Siva Guruvareddiar Siva Guruvareddiar は、AWS の Senior Solutions Architect であり、お客様が高可用性システムを設計するのを支援することに情熱を注いでいます。マイクロサービス、コンテナ化、オブザーバビリティ、サービスメッシュ、クラウド移行を使用して、プラットフォームインフラストラクチャと内部アーキテクチャをモダナイズすることで、クラウドネイティブの採用を加速させます。LinkedIn で連絡できます: linkedin.com/in/sguruvar Vijay Kumar Vijay Kumar は、セキュリティとオブザーバビリティの領域で革新的な製品を提供してきた実績を持つ Senior Product Manager であり、深い技術的専門知識とユーザー中心の設計を活用しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Aya Hara がレビューしました。

「金融リファレンスアーキテクチャ日本版」 では、2022 年の初版公開以来、継続的にコンテンツの拡充を進めています。その中で、「ミッションクリティカル (勘定系) 」や「顧客チャネル」など、金融業界固有のワークロードに応じたリファレンスアーキテクチャが AWS CDK サンプルコードと共に公開されています。例えば「ミッションクリティカル (勘定系) 」は勘定システムだけでなく、一般的なOLTPシステムでご利用できます。 一方で、具体的なシステム特性を踏まえた上で、より詳細な考慮点やアーキテクチャ上の決定根拠を知りたいというニーズは以前からありました。そこで今回、国内のみならずグローバルも含めた先進事例を分析し、アーキテクチャ上の重要ポイントを整理したドキュメントとして公開しました。 今回公開されたのは以下3つのユースケースです。 証券会社における OMS (Order Management System) クレジットカードのイシュアシステム 保険業界におけるデータ分析システム これらの各ユースケースごとに、アーキテクチャの目的や特徴に関する解説と、想定されるFAQも併せて記載しています。本記事では各ユースケースの概要について解説します。 証券会社における OMS (Order Management System) 証券会社の注文管理システム (OMS) をクラウド環境で構築する際のリファレンスアーキテクチャを公開しました。従来オンプレミスやメインフレームで運用されてきた証券会社の基幹システムを、低レイテンシー・高スケーラビリティ・高可用性のバランスを取りながらクラウドネイティブに構築するための指針を、国内外で稼働している複数の事例を踏まえて示しています。 実装上のポイントとして以下のような内容を解説しています Amazon ElastiCache for Redis によるインメモリメッセージングで低レイテンシーなコンポーネント間通信を実現 マイクロサービス化により各コンポーネントの独立したスケーリングを実現し、寄り付き時などの予測可能なピーク負荷にも対応 AWS Outposts を活用した取引所近接配置により、EMS との通信レイテンシーを最小化 詳細は本文： 金融ワークロードアーキテクチャ解説 資本市場 OMS をご覧ください。 クレジットカードのイシュアシステム クレジットカードのイシュアシステムをオンプレミスから AWS に段階的に移行・構築運用する際のリファレンスを公開しました。キャンペーン等に起因した決済需要による高トラフィック処理やリアルタイム承認要件への対応、決済技術や業界標準の導入／金融規制要件の変更への対応、業務継続性を支えるための高可用性の担保等、クレジットカード業界に求められる様々な要素を実現するためのアーキテクチャをお客様の先行事例を元に示しています。 Authorization（承認）および Reconciliation（クリアリングファイルと承認済みデータの突合せ）の機能を AWS 上に構築し、Settlement（資金精算）をオンプレミスで構築するアーキテクチャパターンを示しています。 その他、実装上のポイントとして以下のような内容を解説しています マルチリージョンでのActive – Active 構成を採用し、カード番号、顧客ID 等のデータ内容ごとにオンプレミスからどちらのリージョンに振り分けるかを判定することで各リージョンごとに処理対象を分離し、整合性と可用性の両立を実現 マイクロサービスアーキテクチャを採用うぃ各機能の独立したスケールアウトを実現 リクエストヘッジを導入したDynamoDB のパフォーマンス担保 詳細は本文： クレジットカードのイシュアシステム をご覧ください。 保険業界におけるデータ分析システム 保険業務に必要なデータ処理を実現するデータプラットフォームをAWS上に構築・運用する際のリファレンスを公開しました。データ量急増による処理能力不足とコスト増大、レガシーシステムの機能制約による多様化ニーズへの対応困難、セキュリティ境界の曖昧さによるコンプライアンス対応の課題など、保険業界に求められる様々な要素を実現するためのアーキテクチャをお客様の先行事例を元に示しています。 統合データレイクを中心としたデータプラットフォームにより、保険業務における契約者情報、健康情報、財務データの取り込みから分析機能をクラウド上でシステム化しています。マルチアカウント戦略を採用し、データ取り込み、データレイク、データ変換、データウェアハウス、データ分析の処理ごとに分離されたアカウントで実行することで、 PII / PHI データの完全な分離とセキュリティ境界の明確化を実現しています。 実装上のポイントとして以下のような内容を解説しています Amazon Aurora をメタデータリポジトリとして活用し、AWS Glue フレームワークによるメタデータ駆動型ジョブ自動生成で異なるソースからの統一的なデータ取り込みを実現 Amazon Redshift Data Sharing による計算分離アーキテクチャで、プロビジョニングクラスターでの ETL / ELT 処理とサーバーレスクラスターでの分析処理を完全分離し、パフォーマンス競合を回避 AWS Organizations によるマルチアカウント戦略と IAM クロスアカウントロールにより、 PII / PHI データの完全分離と最小権限アクセス制御を実現 詳細は本文： 保険ワークロード：データ分析基盤 をご覧ください。 まとめ 今回の「金融リファレンスアーキテクチャ日本版」におけるアップデートでは、従来ご提供してきたワークロードごとのリファレンスアーキテクチャに加え、実際のお客様事例をもとにした特定ユースケースにおける詳細なアーキテクチャの解説文書を公開しました。これにより、同様のユースケースで AWS を活用いただく際のアーキテクチャ検討に役立てていただくことを目指しています。内容に関するフィードバックやご質問は、 GitHub 上の issue としてご登録いただけます。皆様からのフィードバックをお待ちしております。 本ブログ記事は、AWS のソリューションアーキテクトである 樋口 健人、武方 総、髙木 香里、吉澤 稔、松本 耕一朗が執筆いたしました。

本稿は 2025 年 12 月 23 日に AWS Machine Learning Blog で公開された “ AWS AI League: Model customization and agentic showdown ” を翻訳したものです。 複雑な実務タスクに対応できるインテリジェントな AI エージェントを構築するのは、容易なことではありません。また、大規模な事前学習済み基盤モデルだけに頼るのではなく、企業は自社の特定ユースケースでより高いパフォーマンスを発揮できるよう、小規模で専門性の高いモデルをファインチューニングし、カスタマイズする必要がある場合も多いです。AWS AI League は、エージェンティック AI とモデルカスタマイゼーションの分野でイノベーションを促進する、エキサイティングなコンペティションを通じて、企業が高度な AI 能力を構築する際の課題を克服できるよう支援する革新的なプログラムを提供しています。 2025 年、初回の  AWS AI League コンペティション は、世界中の開発者、データサイエンティスト、ビジネスリーダーの注目を集めました。彼らは最新の AI ツールとテクニックを使用して喫緊の課題解決に取り組みました。AWS re:Invent 2025 のグランドフィナーレは、参加者たちの創意工夫とスキルを披露する、エキサイティングなイベントとなりました。主要企業の部門横断チームが直接対決し、効果的なプロンプトの作成、モデルのファインチューニング、そして強力な AI エージェントの構築能力を実証しました。 2025 年 AWS AI League チャンピオンの皆様、おめでとうございます！激戦の末、これら 3 名の優秀な構築者が勝利を収め、総額 $25,000 の賞金を分け合いました： 1 位：Cisco 所属の Hemanth Vediyera 2 位：Aqfer 所属の Ross Williams 3 位：Capital One 所属の Deepesh Khanna 図1: 左から順に Ross, Hemanth, Deepesh この記事では、AWS AI League プログラムを使用して AI コンペティションを開催する方法について説明します。 このプログラムにより、参加者はモデルカスタマイゼーションやエージェント構築の概念を体験し、それらを実際のビジネス課題解決に応用し、ゲーム形式の魅力的なフォーマットで革新的なソリューションを披露することができます。新たに導入されたエージェンティック AI とモデルカスタマイゼーションのチャレンジでは、企業が AWS クレジットを利用して社内トーナメントを主催したり、開発者が AWS イベントで競い合うことが可能です。 開始するには、 AWS AI League 製品ページ をご覧ください。 AWS AI League は、AWS エキスパートが主導する 2 時間のハンズオンワークショップから始まり、その後自分のペースでの実験が続きます。この旅路は、緊急のビジネス課題に対処する AI 作品とソリューションを披露する、魅力的なゲームショースタイルのグランドフィナーレで頂点に達します。以下の図は、これら 3 つのステップを示しています。 図2: AWS AI League チャンピオンシップのステップ 2025 年プログラムの成功を基盤として、 AWS AI League 2026 チャンピオンシップ の開始を発表できることを嬉しく思います。今年のコンペティションでは、参加者がAIスキルを真に試せる、2つの新しいチャレンジが導入されます。 エージェンティック AI チャレンジでは、 Amazon Bedrock AgentCore  を使用してインテリジェントエージェントを構築します。競技者は実世界のビジネス問題に取り組むためにカスタマイズされたエージェントアーキテクチャを作成します。 モデルカスタマイゼーションチャレンジはエージェンティック AI チャレンジを補完し、 SageMaker Studio  の最新のファインチューニングレシピを使用して特定のユースケース向けにモデルをカスタマイズします。 2026 AI League チャンピオンシップ では、賞金総額が $50,000 に倍増し、初心者から上級実践者まで、異なるスキルレベルの開発者に対応するトラックが用意されています。 AWS AI League には、Amazon Bedrock AgentCore を使用してインテリジェントなエージェントを構築し、ダイナミックなゲーム形式の競技で複雑な問題を解決する、エキサイティングなエージェンティック AI チャレンジが新たに加わりました。このチャレンジでは、エージェントが迷路のようなグリッド環境を進み、宝箱を目指しながら様々な課題に遭遇します。これらの課題は実際のユースケースを反映しており、不適切なコンテンツへの対処、コード実行、ブラウザ操作など、エージェントの能力が試されます。 エージェントには制限時間が設けられており、その間にマップを移動し、ポイントを集め、障害物を乗り越えて宝箱に到達しなければなりません。獲得ポイントが多いほど、リーダーボードでの順位が上がります。Amazon Bedrock AgentCore のプリミティブを使用してエージェントを完全にカスタマイズできるため、本番レベルのエージェントをより安全に拡張・管理することが可能です。また、スーパーバイザーやサブエージェントに特定のモデルを選択したり、 Bedrock Guardrails 、 AgentCore Memory 、 AWS Lambda  関数などのカスタムツールを作成して、エージェントが課題を乗り越えるのを支援できます。以下の図は、エージェントが宝箱に到達するまでに克服しなければならない障害物を示しています。 図3: AWS AI League エージェンティック AI チャレンジ AWS AI League は、ユーザーがインテリジェントなエージェントソリューションを構築するための完全な UI (ユーザーインターフェース)を提供しています。このノーコード UI を使用して、マルチエージェントアーキテクチャやツールを構築し、カスタム Lambda 関数やツールをインタラクティブにコーディングするための  Amazon SageMaker Studio CodeEditor  などの様々なコンポーネントを統合できます。これにより、環境を離れることなく、AWS AI League のウェブサイト内でエージェントベースのソリューションを完全に開発・カスタマイズすることが可能です。 以下のスクリーンショットは、AWS AI League のウェブサイト内で完結するエージェント構築体験を示しています。 図4: AWS AI League エージェントツール 図5: AWS AI League マルチエージェントアーキテクチャ 競技中、ユーザーはエージェントのパフォーマンスに関するリアルタイムフィードバックを受け取ります。LLM (大規模言語モデル)による評価システムが客観的な評価を提供し、改善のための反復作業を支援します。以下の画像は、チャレンジ中にエージェントがどのように評価されるかを示しています。 図6: AWS AI League エージェントチャレンジにおける評価 グランドフィナーレでは、上位のファイナリストがステージに上がり、ライブのゲームショー形式でエージェントの能力を披露します。これにより、複雑なマルチステップ問題を解決するエージェンティック AI の強力さと汎用性が実証されます。評価基準には、時間効率、チャレンジの解決精度、エージェントの計画能力、そしてトークン消費効率が含まれます。以下のスナップショットは、re:Invent 2025 でのグランドフィナーレ最終ラウンドの様子を示しています。 図7: AWS AI League re:Invent 2025 グランドフィナーレ AWS AI League の モデルカスタマイゼーションチャレンジ では対象範囲が拡大され、 最新のファインチューニング技術を活用できるようになりました。 Amazon SageMaker Studio  内で新しいモデルカスタマイゼーション体験にアクセスでき、強力な新しいトレーニングレシピを使用できます。目標は、より大規模な参照モデルのパフォーマンスを上回る、高度に効果的でドメイン特化型のモデルを開発することです。 チャレンジは、モデルカスタマイゼーションスキルを磨くことから始まります。学習したツールやテクニックを使用して、高度なファインチューニング手法を適用し、モデルのパフォーマンス向上を目指します。モデルのカスタマイズが完了すると、真の試練が始まります。カスタマイズしたモデルはリーダーボードに提出され、参照モデルと比較してパフォーマンスが評価されます。自動評価システムが、あなたのカスタマイズモデルの応答が参照モデルの出力よりも正確で包括的であると判断するたびに、ポイントが獲得できます。高度なスキルを披露し、リーダーボードのトップに上り詰め、組織にとって新たな機会を切り開く可能性があります。 チャレンジ中、リーダーボードに提出すると、自動評価システムからモデルのパフォーマンスに関するリアルタイムフィードバックを受け取ります。リーダーボードは競技期間を通じて、参照データセットに対して提出物を評価し、精度に関する即座のフィードバックを提供することで、ソリューションの反復改善を支援します。以下の画像は、カスタマイズされたモデルを評価するために AI による評価がどのように使用されるかを示しています。 図8: AWS AI League モデルカスタマイゼーションの評価 グランドフィナーレでは、上位のファイナリストがライブのゲームショー形式でモデルの能力を実証し、プロンプトエンジニアリングのスキルを披露します。ゲームショーでは、ドメインエキスパートとライブ観客がリアルタイム投票に参加し、どの AI ソリューションが実際のビジネス課題を最もよく解決するかを判断する専門家評価が得点に含まれます。以下の画像は、グランドフィナーレ中の参加者のプロンプトエンジニアリング画面を示しています。 図9: AWS AI League モデルカスタマイゼーショングランドフィナーレ参加者ビュー 本記事では、新しい AWS AI League のチャレンジと、それが組織の AI 開発アプローチをどのように変革しているかを紹介しました。AWS では、イノベーションを促進する最も効果的な方法は競争であることを学んできました。AWS AI League により、開発者は AI スキルを披露し、競い合い、イノベーションを解き放つことができるようになりました。 組織内で AWS AI League を開催する方法について詳しく知りたい場合は  AWS AI League  をご覧ください。また、インテリジェントなエージェントの構築や AI モデルのカスタマイゼーションについてより深く学ぶには、 AWS Skill Builder  の  AWS AIトレーニングカタログ をご活用ください。 本記事の翻訳はソリューションアーキテクトの大前遼が担当しました。 Marc Karp は、Amazon SageMaker Serviceチームの MLアーキテクトです。彼は、お客様が大規模なMLワークロードの設計、デプロイ、管理を支援することに重点を置いています。余暇には、旅行や新しい場所の探索を楽しんでいます。 Natasya K. Idries は、AWS AI/MLゲーミフィケーション学習プログラムのプロダクトマーケティングマネージャーです。彼女は、先進技術と実用的なビジネス実装の間のギャップを埋める魅力的で実践的な教育イニシアチブを通じて、AI/MLスキルの民主化に情熱を注いでいます。学習コミュニティの構築とデジタルイノベーションの推進における彼女の専門知識は、インパクトのあるAI教育プログラムの作成へのアプローチを形作り続けています。仕事以外では、Natasyaは旅行、東南アジア料理の調理、自然散策路の探索を楽しんでいます。

本ブログは株式会社サンブリッジ様と Amazon Web Services Japan が共同で執筆いたしました。 ※ サンブリッジ様の Website でも本事例を技術コラムとして公開されています。詳細はそちらも併せてご参照ください。 みなさん、こんにちは。AWS で営業を担当している垣見です。本記事では、採用担当者の育成効率化という社内課題に対し、生成 AI を活用して大きな成果を上げている株式会社サンブリッジ様（以下、サンブリッジ様）の取り組みをご紹介します。 株式会社サンブリッジ様 は、企業のビジネスモデルに合わせて AWS や Salesforce をはじめ、お客様の課題解決において最適なクラウドサービスを用いたビジネス分析や導入、運用までをワンストップでトータルコーディネートし、ビジネス拡大・業務改善を支援する企業です。同社では、採用担当者が未経験者であることに起因する CEO の育成負荷や、面接同席が困難な場合に CEO 視点での適切な回答ができないといった課題を抱えていました。これらの課題を解消するため、同社は Amazon Bedrock を活用して 採用担当向け育成 AI コーチを構築し、育成業務の自動化と品質向上を実現しました。 背景と課題 サンブリッジ様では、事業拡大に伴って採用活動が活発化する中、採用担当者の育成に関する課題が顕在化していました。特に、採用担当者の経験が浅い場合、面接準備や候補者対応における判断軸を CEO が直接指導する必要があり、育成に大きな時間を割かざるを得ない状況でした。また、CEO が面接に同席できない場面では、採用担当者だけでは CEO の視点に基づいた回答が難しく、候補者に対して一貫した質の高い説明を行うことが困難になることもありました。 採用面接は年間 720 回にのぼり、その半数以上に CEO が関与していたため、負担の軽減と育成プロセスの仕組み化が急務となっていました。育成ノウハウも CEO 個人に蓄積される傾向が強く、組織として採用力を高めるためには、知見の共有とプロセスの標準化が求められていました。 ソリューション構築のアプローチ こうした課題に対して、サンブリッジ様は Amazon Bedrock を中心に据えた「採用担当向け育成 AI コーチ」の構築に取り組みました。採用担当者が日常的に抱く疑問を即座に解消できるよう、Bedrock の大規模言語モデルを活用した対話型チャットボットを開発し、CEO が普段重視している判断ポイントや候補者との向き合い方を学習させることで、担当者がいつでも CEO の視点に近い回答を得られるようにしました。 あわせて、ナレッジの最新化を継続するために Slack と連携し、運用メンバーが日々の気づきや更新情報を手軽に蓄積できる環境を整備しました。また、採用業務に必要な基礎理解を確認できるよう、 RAG （Retrieval-Augmented Generation） を利用したテスト機能も実装し、問題作成から採点、フィードバック生成までを自動化しました。これにより、育成の進捗や理解度を定量的に把握することが可能になりました。 さらに、開発プロセスには AI コーディングアシスタントを活用し、新人エンジニア 1 名でわずか 2 週間という短期間でシステム全体を構築することに成功しました。アジャイルに試行錯誤できる環境が整ったことで、現場が求める機能を迅速に形にする体制が実現しました。 導入効果 育成 AI コーチの導入後、面接同席にかかる CEO の負担は大きく軽減されました。年間 720 回の面接のうち、これまで CEO の同席が必要とされていた場面の半数が AI による育成支援で対応可能となり、年間で 360 時間の削減につながりました。これは採用活動全体の効率化に大きく貢献しています。 また、面接中の質問対応についても、AI が CEO の視点を補完することで、年間280回の質問機会で社長視点で候補者へ回答することができるようになり、安定した回答品質を確保できるようになりました。採用担当者が CEO の意図を正確に理解するための情報提供が強化され、人によって対応がばらつくといった属人化の課題も解消に向かっています。加えて、RAG を活用したテスト機能により、担当者の理解度を把握しながら継続的にスキル向上を支援できるようになり、育成そのものの質も向上しました。 今後の展望とまとめ サンブリッジ様は生成 AI コンテストという外部イベントに参加することで、育成AIコーチのアイデアを短期間で具体化し、さらに実際の業務上の課題を解決する段階まで速やかに移行できました。今回構築した育成 AI コーチを基盤として、採用業務以外の領域への展開も視野に入れています。Slack を軸にしたナレッジ運用の仕組みは他部門でも活用可能であり、AI による判断支援の仕組みを組織全体へ広げていくことで、さらなる生産性向上が期待されています。 「AWS が提供する豊富な AI 関連ソリューションとアクセスしやすいインターフェイスの Slack を組み合わせることにより、弊社の育成課題の解決に繋がりました。継続的にアップデートしていきたいと考えています。」と語るのは株式会社サンブリッジ 代表取締役社長 兼 CEO の梶川 拓也氏です。今回の取り組みは、属人化した知見を AI によって標準化し、限られたリソースでも高い品質の育成と採用活動を実現するモデルケースとなりました。AWS を活用した迅速な開発と運用の仕組みが、今後の採用戦略における重要な基盤となっていくと考えられます。 垣見　健一 | Kakimi Kenichi 広域事業統括本部　広域営業本部　第一営業部

みなさん、こんにちは。現在メインフレームを利用されている方の中で、メインフレームシステム上の業務データを活用することで、ビジネス意思決定の高度化や新たなビジネス創出を行い、ビジネス価値を向上させる方法を検討されている方はいらっしゃいますでしょうか。こちらの検討をされている方は、多くのケースにおいて以下のような課題に直面されているのではないでしょうか。 メインフレームの処理能力が限界に近づいており、現行処理に影響しないようにデータ分析やデータ加工を行うことは難しい。 メインフレームからデータをエクスポートしたいが、データ構造や型変換に手間と時間がかかりデータ鮮度を高められない。 本ブログでは、これらの課題に対する一つの解決策である Precisely を用いたニアリアルタイムのデータ同期をご紹介します。この方法を使うことでデータ構造や形式を変換しながら、メインフレーム上の様々なデータソースから AWS 環境上のデータストアへ、ニアリアルタイムの同期を行うことで、外部システム上で鮮度の高いデータを用いてデータ活用を行うことが可能です。 Precisely を使用した AWS Mainframe Modernization Data Replication とは AWS Mainframe Modernization Data Replication は、Precisely 社の Change Data Capture (以下、CDC) テクノロジーを活用した、メインフレームのデータを AWS クラウドへ同期するためのソリューションです。メインフレーム上の様々なデータソースから AWS 環境上のデータストアへ、ニアリアルタイムのレプリケーションを実現します。 このソリューションの特徴としては、以下のようなものがあります。 CDC によるニアリアルタイムのレプリケーションの実現 メインフレームのデータソースへの負荷の配慮 Db2、IMS、VSAM などメインフレーム上の様々なデータソースへの対応 Amazon Managed Streaming for Apache Kafka (以下、MSK) と統合することによる、AWS サービスを直接ターゲットとするレプリケーションの実現 このソリューションは、以下のような様々なデータ利活用のユースケースに適用可能です。 AWS クラウド上のデータレイクやデータウェアハウスに同期したメインフレームデータを使った、BI による可視化や AI/ML による新たなデータの活用 AWS クラウド上のデータストアにニアリアルタイムで同期されたメインフレームデータに対する、新規ビジネスアプリケーションからのデータ参照 メインフレームのダウンタイムを最小化しながら、メインフレームアプリケーションおよびデータを AWS クラウドに移行する アーキテクチャ概要 実際にメインフレームからAWS クラウド上にデータを同期する際の、推奨する基本構成は以下のようになります。 このアーキテクチャは、Amazon EC2 インスタンスでデプロイされた Precisely Apply Engine を境目として、メインフレーム側と AWS クラウド側に分けられます。メインフレーム側から送信されたデータは、Apply Engine で処理・変換され、後続の AWS サービスに送られます。メインフレーム側にはログ収集用のエージェントがインストールされており、データを一定量蓄積した上でのバッチ送信またはログストリームのニアリアルタイム送信が可能です。AWSクラウド側には Apply Engine を構成することで、ホストから送信されたデータを後続のサービスで利用しやすい形式に加工しながら連携することが可能です。MSK と組み合わせることで、Amazon Redshift、Amazon S3、Amazon RDS、Amazon Aurora、AWS Lambda など、様々なサービスに対してニアリアルタイムなデータ連携が可能です。本ブログ上では、S3 と Redshift に連携するための構成方法を扱います。 データの活用シナリオ例 多くのメインフレーム上には、顧客情報、取引履歴、在庫データ、売上データなど、企業の基幹業務で扱われる重要な情報が含まれているかと思います。これらのデータを活用する例として、以下のようなシナリオを想定しながら今回の環境構築方法を紹介していきます。シナリオ例1としては、データの長期保存や機械学習での活用を主な目的として S3 にデータを格納する構成をご紹介します。シナリオ例2としては、より即時性を重視したニアリアルタイム分析やダッシュボード表示を可能とする Redshift にデータを格納する構成をご紹介します。 シナリオ例1）月次の監査実施タイミングで取引データや顧客行動データを個別抽出して不正取引を検出している金融機関が存在する。この状況に対して、Precisely を用いて当該データをニアリアルタイムで抽出し S3 に蓄積するよう変更を行うことで、日々の最新データを用いて不正取引検出を行い、迅速に自動アラートを発信することが可能になる。 シナリオ例2）製造ラインの各工程で生成される品質データや稼働データをメインフレームに蓄積し、日次レポートで品質傾向を把握している製造業企業が存在する。この状況に対して、Precisely を用いて、製造工程での品質データ・稼働データ生成と同時に Redshift に格納するよう変更を行うことで、品質異常や設備故障の兆候を数分以内に検知し、生産ライン停止前の予防保全を実現できるようになる。 詳細な設定方法 Precisely Connect Apply Engine の準備 Precisely の Apply Engine を利用するための最も簡単な方法は AWS マーケットプレイスに準備された、 Precisely Connect のアプライエンジンを構成するための EC2 の AMI を利用することです。この AMI には、「インストール済みのソフトウェアスタック」「作成・初期化済みのレプリケーションインスタンス」「Amazon CloudWatch と統合済みのプロセスとマーケットプレイスと統合済みのレプリケーションサービス」が導入済みのため、EC2 インスタンス起動後にすぐに利用を開始することができます。マーケットプレイスから「AWS Mainframe Modernization – Data Replication for IBM z/OS」を検索し、サブスクライブを行うことで、該当の AMI を利用した EC2 インスタンスを起動できるようになります。 上記 AMI を用いて EC2 インスタンスを起動した後には、インスタンスにログインを行い、レプリケーションを行うための構成を行います。構成のための詳細手順は、 Precisely Connect の構成手順のドキュメント を参照してください。 本ブログでは、Apply Engine 以降の処理の確認に焦点を当てるため、メインフレーム環境は使用せずに、EC2 インスタンス上に配置したサンプルファイルをデータソースとして、後続のターゲットに対してレプリケーションを行うアプライスクリプトをご紹介します。 [売上明細のサンプル (CSV)] データソースとして使用した CSV の各列の意味は store_id: 店舗ID, product_id: 商品ID, amount: 数量, unit_price: 単価, total_price: 合計金額, timestamp: 売上日時 であり、実際のファイルは以下となります。 3,1008,6,1000,credit,2024-04-01 09:39:00,6000 3,1005,2,200,mobile,2024-04-01 14:00:00,400 2,1004,3,2000,credit,2024-04-03 11:19:00,6000 5,1001,9,200,mobile,2024-04-03 12:17:00,1800 4,1009,8,500,cash,2024-04-03 17:29:00,4000 4,1007,10,100,debit,2024-04-03 20:24:00,1000 1,1004,4,100,mobile,2024-04-04 13:22:00,400 2,1006,1,200,mobile,2024-04-05 14:02:00,200 4,1002,8,1500,mobile,2024-04-05 15:55:00,12000 4,1001,1,1000,cash,2024-04-05 17:35:00,1000 ... [サンプルのアプライスクリプト] 実際に使用したアプライスクリプトは以下の通りです。 JOBNAME sales_test_job; REPORT ./SALES_TEST_JOB.rpt; BEGIN GROUP SOURCE; DESCRIPTION SQLDDL /+ CREATE TABLE SALES ( STORE_ID INTEGER, PRODUCT_ID INTEGER, AMOUNT DECIMAL(10), UNIT_PRICE DECIMAL(10), TOTAL_PRICE DECIMAL(10), SALES_DATETIME TIMESTAMP ) +/ AS SALES; END GROUP; BEGIN GROUP TARGET; DESCRIPTION SQLDDL /+ CREATE TABLE T_SALES ( STORE_ID INTEGER, PRODUCT_ID INTEGER, AMOUNT DECIMAL(10), UNIT_PRICE DECIMAL(10), TOTAL_PRICE DECIMAL(10), SALES_DATETIME TIMESTAMP ) +/ AS T_SALES; END GROUP; DATASTORE ./input.csv OF DELIMITED COLDEL('\x2C') RECDEL('\x0A') ASCII AS FILE_IN DESCRIBED BY GROUP SOURCE; DATASTORE kafka:///<topic名> OF DELIMITED COLDEL('\x2C') RECDEL('\x0A') ASCII AS FILE_OUT DESCRIBED BY GROUP TARGET; PROCESS INTO FILE_OUT SELECT { REPLICATE(FILE_OUT) } FROM FILE_IN; MSK の準備 次に、Apply Engine から送信されたデータを処理する MSK 部分を構築します。構築の最初のステップは、マネジメントコンソールで、MSK のコンソール画面に移動して、MSK クラスターを作成することから始まります。Apply Engine と MSK クラスターが安全に通信するために、今回は同じ VPC 内に両者が存在する構成を採用します。クラスタータイプは Provisioned を選び、Apply Engine の VPC へ配置していきます。Apache Kafka バージョンは要件によって変わりますが、今回は特殊要件は想定しないため最新版を選びます。 ブローカーは Standard を選択し、ブローカーサイズは、後続処理として VPC プライベート接続が必要な Amazon Data Firehose を利用するため、VPC プライベート接続が利用可能な m5.large インスタンスを利用します。ブローカーのゾーン数は配置先の VPC と合わせて数を選択します。今回は 2 を利用します。ゾーンあたりのブローカー数は、1つを選択します。要件に応じて一つのゾーン (AZ) に複数のブローカーを配置することも可能です。今回は、クラスターのストレージはデフォルト値を利用します。 続いて、ネットワーク設定を行います。まずは対象として Apply Engine が展開された VPC を選択します。そして「最初のゾーン」として、指定した AZ それぞれに対応するサブネットを選択します。セキュリティグループについては、Apply Engine ホストと EC2 の両方に同一なセキュリティグループを使用するか、Kafka が利用するポートが開放され接続・疎通が可能なセキュリティグループを準備して指定してください。 関連するリソースが MSK にアクセスできるように、必要な権限設定を許可します。今回は以下の設定を使用します。 Apply Engine との接続はユーザー名とパスワードを用いるため、SASL/SCRAM 認証を有効にする。 MSK から Data Firehose へ接続するため、IAM ロールベースの認証を有効にする。 次にモニタリングに関する設定をして、クラスターをデプロイします。クラスターの立ち上げは 数十分程度かかる場合があります。立ち上げが完了してから、接続許可の変更および Apply Engine からデータを連携するために、MSK のトピックを作成し設定します。 MSK でトピックを作成する方法はいくつかありますが、今回は Amazon MSK のDeveloper Guide に従って、クライアントとして利用している EC2 インスタンスから Kafka を操作する方法を採用します。詳細の設定手順は同 Developer Guide の こちら を参考してください。必要な作業ステップ概要は以下となります。ここで作成したトピック情報は、後続の送受信設定で使用します。 MSK クラスターを操作する権限のある IAM ロールを作成する。 上記操作権限を持つロールが付与された EC2 インスタンスを立ち上げる。MSK クラスターと疎通できるように、セキュリティグループなどを設定する。（Apply Engine がホストされた EC2 で代用可能） EC2 にログインして、MSK クラスターで展開された Kafka のバージョンに対応した Kafka パッケージをダウンロードして設定する。 疎通を確認してから、MSK クラスターの BootstrapServer に対して、Apply Engine の出力連携用のトピックを作成する。 最後に、以下図のようにMSK クラスターのネットワーク設定でマルチ VPC 接続を有効にして、クラスターポリシーでも Data Firehose からの接続を許可します。 Apply Engine から MSK への接続 MSK クラスターの設定の後には、実際に Apply Engine から MSK の間でデータ送受信の確認を行います。具体的には、Apply Engine の設定時に利用したデータ変換スクリプトを書き換えて実際の通信を行います。設定変更のポイントは、送信先を指定する TARGET DATASTORE のセクションで、DATASTORE の部分をトピック名（ kafka:///<topic名> ）に指定することです。実際のスクリプト例は以下となります。なお、今回はデータのフォーマット変換は行わず、直接 MSK へ送信します。 DATASTORE kafka:///<topic名> OF DELIMITED COLDEL('\x2C') RECDEL('\x0A') ASCII AS FILE_OUT DESCRIBED BY GROUP TARGET; 次に、MSK 側にて Apply Engine の認証設定を行います。Apply Engine が利用するユーザー名とパスワードを以下図のように Secrets Manager に保管します。暗号化にはカスタムキーによる暗号化を利用します。カスタムキーは AWS Key Management Service (KMS) を用いて作成できます。AWS マネージドキーを利用すると MSK では関連付けできませんのでご注意ください。具体的にはシークレットを作成してから、以下図のように、MSK クラスターのセキュリティ設定で関連付けを行います。なお、シークレットを作成するとき、命名ルールとして、AmazonMSK_のプレフィックスが必須です。 最後に、Apply Engine がホストされたインスタンスで、Apply Engine の設定を変更します。Apply Engine のワーキングディレクトリ上で、データ送信用の設定ファイル ( sqdata_kafka_producer.conf ) を、作成した環境に合わせて以下のように書き換えます。 builtin.features=SASL_SCRAM security.protocol=SASL_SSL sasl.mechanism=SCRAM-SHA-512 sasl.username=<シークレットで保管された username> sasl.password=<シークレットで保管された password> metadata.broker.list=<MSK クラスターの broker URL> その後 Apply Engine でデータ変換スクリプトを以下のコマンドでコンパイルして実行すれば、MSK トピックに対してデータ送信が行われます。 sqdparse <JOB_SCRIPT>.sqd <JOB_SCRIPT>.prc sqdata <JOB_SCRIPT>.prc Data Firehose を通した S3 への接続（シナリオ例1） ここまでの作業により、メインフレームのデータが MSK トピックにニアリアルタイムで送信されるようになりました。後段の構成としてまずは、シナリオ例1を実現するために、MSK で受信されたデータを、Data Firehose を通して S3 データレイクに連携する構成方法をご紹介します。MSK から直接 S3 サービスへデータを連携することもできますが、今回は S3 に格納するデータを柔軟に加工できることを重視して Data Firehose に接続した上で S3 に連携する構成を利用します。Data Firehose を利用することで自動的なデータの圧縮、暗号化、パーティション分割を実現することが可能です。 IAM ロールとポリシーの作成 Data Firehose が MSK からイベントを取得するために、まずは MSK クラスター、トピック、グループへアクセスできる IAM ロールとポリシーを作成します。同時に、送信先である S3 バケットへのアクセス権限を付与します。IAM ロール例は以下となります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kafka-cluster:Connect", "kafka-cluster:AlterCluster", "kafka-cluster:DescribeCluster" ], "Resource": "arn:aws:kafka:region:012345678901:cluster/cluster-name/*" }, { "Effect": "Allow", "Action": [ "kafka-cluster:*Topic*", "kafka-cluster:WriteData", "kafka-cluster:ReadData" ], "Resource": "arn:aws:kafka:region:012345678901:topic/cluster-name/*" }, { "Effect": "Allow", "Action": [ "kafka-cluster:AlterGroup", "kafka-cluster:DescribeGroup" ], "Resource": "arn:aws:kafka:region:012345678901:group/cluster-name/*" }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket", "s3:ListBucketMultipartUploads", "s3:GetBucketLocation", "s3:AbortMultipartUpload" ], "Resource": [ "arn:aws:s3:::your-bucket-name", "arn:aws:s3:::your-bucket-name/*" ] } ] } MSK クラスターポリシーの設定 MSK 側のクラスターポリシーでも Data Firehose からのアクセスを許可しておく必要があります。具体的な設定方法は、 Amazon MSK の Firehose 統合 、 Amazon MSK のソース設定を構成する を参照ください。 Data Firehose の作成 次に、データソースを MSK クラスター、送信先を S3 バケットとした Data Firehose の作成を行います。手順は以下の通りです。 Amazon Data Firehose コンソールで「Create delivery stream」を選択 Source として「Amazon MSK」を選択 MSK クラスター、トピック名、開始位置を指定 Destination として「Amazon S3」を選択 S3 バケット名とプレフィックスを設定 作成した IAM ロールを指定 設定の完了後に状態がアクティブになれば、Apply Engine から MSK と Data Firehose を経由して S3 へのデータ送信が可能になります。Apply Engine でデータ送信を実施すれば、送信先の S3 バケットで新オブジェクトが作成されることを確認可能です。 Redshift への直接接続（シナリオ例2） 次に、シナリオ例2を実現するために、MSK で受信されたデータを Amazon Redshift に直接連携 (ストリーミング統合) する構成方法をご紹介します。この場合、Redshift のマテリアライズドビューを使用してニアリアルタイムデータ取り込みを実現します。 IAM ロールとポリシーの作成 まず準備として、Redshift 用の MSK クラスター、トピック、グループにアクセスしてデータを取得する権限を持つ IAM ポリシーが付与された IAM ロールを作成します。IAM ロール例は以下となります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kafka-cluster:Connect", "kafka-cluster:AlterCluster", "kafka-cluster:DescribeCluster" ], "Resource": "arn:aws:kafka:region:012345678901:cluster/cluster-name/*" }, { "Effect": "Allow", "Action": [ "kafka-cluster:*Topic*", "kafka-cluster:WriteData", "kafka-cluster:ReadData" ], "Resource": "arn:aws:kafka:region:012345678901:topic/cluster-name/*" }, { "Effect": "Allow", "Action": [ "kafka-cluster:AlterGroup", "kafka-cluster:DescribeGroup" ], "Resource": "arn:aws:kafka:region:012345678901:group/cluster-name/*" } ] } Redshift クラスターの作成 次に作成したロールを適応済みの、拡張された VPC ルーティングを有効にした Redshift クラスターを作成して、利用可能な状態にします。Redshift クラスターの作成の詳細については Amazon Redshift 管理ガイド を参照してください。 スキーマとマテリアライズドビューの作成 Redshift が利用可能な状態になってから、送信されたデータの受け皿となるデータベースを作成します。クエリエディターなどで作成したデータベースへアクセスして、データを受け入れる外部スキーマを例えば以下の SQL で作成します。 CREATE EXTERNAL SCHEMA msk_schema FROM MSK IAM_ROLE 'arn:aws:iam::012345678901:role/MSK_access_role' AUTHENTICATION IAM URI 'b-1.<clustername>.123456.c2.kafka.<region>.amazonaws.com:9098,b-2.<clustername>.123z8u.c2.kafka.<region>.amazonaws.com:9098' 次に、受信したデータを集約するマテリアライズドビューを作成します。AUTO REFRESH を有効にすることで、MSK からの新しいデータが自動的に反映されます。ここまでできれば MSK と Redshift の間でデータ連携を行うことが可能です。 CREATE MATERIALIZED VIEW realtime_data_view AUTO REFRESH YES AS SELECT * FROM msk_schema."<topic_name>"; データ変換とビジネス分析用ビューの作成 実際にデータ連携を行うと、作成したビューの中では、kafka_value のカラムに受信したレコードのデータがそのまま保管されていることがわかるかと思います。このままではビジネス分析に必要なデータ参照がやりにくいため、受信したデータを整形処理したマテリアライズドビューを改めて作成します。今回のサンプルデータで売上データを集計するために、以下のような変換を行います。 CREATE MATERIALIZED VIEW sales_data_view DISTKEY(store_id) SORTKEY(product_id) AS SELECT NULLIF(TRIM(SPLIT_PART(kafka_value::VARCHAR, ',', 1)), '')::INT AS store_id, NULLIF(TRIM(SPLIT_PART(kafka_value::VARCHAR, ',', 2)), '')::INT AS product_id, NULLIF(TRIM(SPLIT_PART(kafka_value::VARCHAR, ',', 3)), '')::INT AS amount, NULLIF(TRIM(SPLIT_PART(kafka_value::VARCHAR, ',', 4)), '')::INT AS unit_price, NULLIF(TRIM(SPLIT_PART(kafka_value::VARCHAR, ',', 5)), '')::INT AS total_price, TRIM(SPLIT_PART(kafka_value::VARCHAR, ',', 6)) AS timestamp FROM msk_schema."<topic_name>" WHERE kafka_value IS NOT NULL AND kafka_value::VARCHAR != '' 実際にビューとして確認できるデータ内容は以下の通りです。 ニアリアルタイム分析の実行 その上で、作成したビューを使用して、ニアリアルタイムでの売上分析や異常検出クエリを実行できます。 -- 直近1時間の店舗別売上集計 SELECT store_id, SUM(total_price) as hourly_sales FROM sales_data_view WHERE timestamp >= DATEADD(hour, -1, GETDATE()) #基準日を'2024-04-01 00:00:00'のようにも指定できる GROUP BY store_id ORDER BY hourly_sales DESC; この構成により、メインフレームでの取引発生から数分以内に Redshift での分析結果を取得でき、Amazon Quick Sight などの BI ツールと連携してニアリアルタイムダッシュボードを構築することも可能です。 構成の使い分け ここで、代表的な2種類の構成を紹介しましたが、それぞれに適したユースケースは次のようにります。 Data Firehose を経由した S3 への連携構成 長期保存、機械学習、大容量データ処理が必要な場合 Redshift への直接連携構成 ニアリアルタイム分析、ダッシュボード表示、即座の意思決定支援が必要な場合 用途に応じて両方の連携先を同時に設定することも可能で、包括的なデータ活用基盤を構築できます。MSK と Redshift についてより詳細に知りたい方は、以下のドキュメントを参照してください。 Amazon Managed Streaming for Apache Kafka デベロッパーガイド: Amazon MSK の Amazon Redshift ストリーミングデータインジェスト Amazon Redshift データベース開発者ガイド: マテリアライズドビューへのストリーミング取り込み Amazon Redshift データベース開発者ガイド: Amazon Kinesis Data Streams からストリーミング取り込みを開始する方法 おわりに 本ブログでは、Precisely を用いた AWS Mainframe Modernization Data Replication により、メインフレームデータを AWS クラウドへニアリアルタイムで同期する方法をご紹介しました。この構成により、従来の日次バッチ処理では実現できなかった迅速なデータ活用が可能になり、S3 データレイクでの機械学習活用から Redshift でのニアリアルタイム分析まで、多様なユースケースに対応できます。メインフレームへの影響を最小限に抑えながら、クラウドの柔軟性とスケーラビリティを活用したデータドリブンな意思決定を実現することで、ビジネス価値の向上に貢献することが可能です。より詳細なご相談や具体的な実装支援については、AWS Professional Services までお気軽にお問い合わせください。 参考情報 AWS marketplace – precisely software Precisely 公式ドキュメント 著者について 安藤 亮一 (ANDO Ryoichi) 安藤 亮一は、AWS Japan プロフェショナルサービスチームのデリバリコンサルタントです。データプラットフォームの構築を検討されているお客様の構想策定の支援や、生成 AI のためのデータプラットフォームの構想策定・設計構築の支援などを行っています。データ基盤の構築や利活用でお困りのことがあれば、ぜひご相談ください。 賀 雲剣 (Yunjian He) 賀 雲剣は、AWS Japan プロフェショナルサービスチームのデリバリコンサルタントです。AWS認定試験全取得でゴールデンジャケットを保持しています。 高エネルギー物理学分野で博士（理学）の学位を取得、大規模データの分析で悩んでいた過去の自身のようなお客様に役立ちたいと思ってAWSに入社しました。最近は生成AI利活用のプラットフォーム構築支援プロジェクトに参画し、データに関わる側面でお客様の支援を行っています。 北川 裕介 (KITAGAWA Yusuke) 北川 裕介は、AWS Japan プロフェショナルサービスチームのデリバリコンサルタントです。主にメインフレームの活用や移行に関する活動を支援しています。

AWS の AI を活用したカスタマーエクスペリエンスソリューションである Amazon Connect 、そのコアに、フローとモジュールがあります。フローはカスタマージャーニーを定義し、モジュールは運用を合理化する再利用可能な要素として機能します。 フローとモジュールに関して、これまで以上に強力で柔軟性があり、保守性を高める 3 つの新機能を発表しました。これらの機能強化により、コンタクトセンターアーキテクトが直面するフローとモジュール間のデータのやり取りの管理の一般的な課題に対処し、コンタクトセンターの設計に前例のない柔軟性と明確性をもたらします。 カスタムブロックでモジュールの柔軟性を変革 フローモジュールの最新の機能アップグレードであるカスタムブロックで、コンタクトセンター運用を簡素化、強化しましょう。この強力な機能は、業界標準の JSON スキーマ v4 構文を実装し、入力および出力オブジェクトを正確に制御します。これにより、ブロックレベルでの動的なエクスペリエンスが可能になります。 この機能が変革的である理由は、コンタクトフローアーキテクチャを合理化する方法にあります。チームは指定された出力パスを作成し、カスタムブランチ名を設定できるようになり、従来のデータ受け渡しメカニズムの複雑さを解消できます。この体系的なアプローチにより、開発コストを抑えながら、フローの作成と管理をより直感的に実現できます。 UI コンポーネントを使用してモジュールのカスタム入力および出力パラメータを設定 モジュールのカスタムブランチを設定 バージョニングとエイリアシングでデプロイメントの信頼性を向上 本番環境でのモジュール更新の管理は常に課題でしたが、新しい包括的なバージョニングとエイリアシング機能により、これが大きく変わります。変更されないモジュールの固定バージョンを作成できるため、デプロイメント時の一貫性を保ちながら、安全にテストを行い、継続的な改善が可能になります。 エイリアス管理システムこそが特に素晴らしい部分です。エイリアスを新しいバージョンを指すように更新すると、その変更はコンタクトセンター実装全体でそのエイリアスを参照しているすべての場所に自動的に適用されます。つまり、単一のエイリアス参照を変更するだけで、予約ロジック、カスタマーサービスワークフロー、またはその他のビジネスプロセスのすべての実装を更新できます。これはデプロイメントプロセスに非常に大きな安心感をもたらします。 新しいバージョンを公開 バージョンタブですべてのバージョンを表示し、以前のバージョンを選択して読み取り専用モードで設定を表示 エイリアスを作成し、エイリアスを特定のバージョンに関連付け ツールとしてモジュールを活用し、従来のフローを超えた拡張を実現 3 つ目のエキサイティングな機能は、フローモジュールが独立した実行単位として様々なシステムによってフロー外で呼び出せるようになったことです。これにより、AI エージェントがカスタマーサービスのやり取り中に支払いワークフロー、自動化されたタスク、その他のビジネスロジックを実行するためのツールとしてモジュールを使用でき、確立された自動化ツールでの新しいユースケースが開かれます。 このアプローチにより、ビジネスロジックをモジュールとして一度定義すれば、複数のチャネルとコンテキストで実行できます。音声通話、チャットのやり取り、自動化されたプロセスのいずれを処理している場合でも、信頼性の高い同じモジュールを呼び出すことができ、開発オーバーヘッドを削減しながら一貫性を確保できます。モジュールタブで新しいツールモジュールを直接作成するか、「ツールとして保存」オプションを使用して既存のモジュールを変換できます。すべてのブロックがツールモジュールでサポートされているわけではないことに注意してください。 モジュールタブで新しいツールモジュールを作成でき、ブロックライブラリで利用可能なブロックを使用してこれらのモジュールを使用できます。 フローモジュールをツールとして作成 ツールとして保存 実際の例: 旅行業界のユースケース 顧客が常にホテル予約の予約、キャンセル、変更を必要とする旅行会社を運営していると想像してください。様々なコンタクトセンターでこれらのリクエストを別々に管理する代わりに、すべてを標準化する単一の強力な予約モジュールを作成できます。 このモジュールを中心的なコントロールセンターと考えてください。顧客が予約について電話をかけてきたとき、ニューヨークまたはロンドンの誰かと話しているかに関係なく、同じ効率的なプロセスが展開されます。システムは各リクエストタイプの処理方法を正確に把握し、一貫したルールと手順に従います。 真の力は変更が必要なときに現れます。数十の場所で指示を更新する代わりに、単純に 1 つのバージョンを変更してエイリアスを更新するだけです。これは、すべてのドアを自動的に開くことができるマスターキーを変更できるようなものです。すべてのコンタクトセンターが即座に新しいバージョンで動作し、すべての顧客が同じ高品質のサービスを受けることを保証します。 実装の実践 実際の動作は次のとおりです。異なるシナリオを処理するための明確な指示を含む予約モジュールを構築します。顧客は電話をかけると、まずシンプルなメニューを通じてニーズを選択できます。予約リクエストは専用モジュールを通じて流れ、その他のサポートのニーズはエージェントに直接接続されます。システムは顧客の入力を読み取り、適切なチャネルを通じて処理し、毎回一貫した結果を提供します。 この方法は何よりも、管理が簡単です。本番稼働前に別のバージョンで新機能をテストでき、異なるリクエストの処理方法を正確に定義でき、わかりやすいデータ構造を通じてすべての予約情報にアクセスできます。つまり、チームは本当に重要なこと、優れたカスタマーサービスの提供に集中でき、技術仕様による複雑なプロセスに悩まされることはありません。 新機能の使用 これらの例は、Amazon Connect フローとモジュールの実用的な知識を前提としています。これらのサービスで基本的な管理タスクを実行する方法の詳細については、以下を参照してください。 Amazon Connect 管理ガイド Amazon Connect の再利用可能な機能のためのフローモジュール * これらのスクリーンショットはデモンストレーション目的のみであり、エンドツーエンドで完全にテストされていない部分的なフローの例であることにご注意ください。これらの例を出発点として使用し、特定のユースケースに合わせてカスタマイズしてご利用ください。 予約操作モジュールの作成 設定タブで予約操作モジュールの入力、出力、カスタムブランチを定義できます。 入力 出力 ブランチ モジュールの設計 予約操作モジュールは、定義した入力パラメータに基づいて異なる運用ボットにリクエストをルーティングすることで、それぞれのビジネスニーズに適応できます。各予約操作は、「戻る」ブロックを通じてカスタマイズされた出力を返すことができ、異なるシナリオの処理方法を完全に制御できます。このモジュラーアプローチにより、新しい予約タイプの追加、追加サービスの統合、既存のワークフローの変更が必要な場合でも、モジュールのロジックを拡張し、各新しい操作に適切な出力パスを設定するだけで、時間の経過に応じて予約機能を簡単に拡張できます。 シンプルな予約の例 モジュールの入力と出力の操作 モジュール内では、モジュールの名前空間を通じて入力パラメータにアクセスでき、パラメータ値がモジュールの入力スキーマ定義と一致するよう定義できます。「戻る」ブロックを設定する際、呼び出し元のフローへの応答を処理するカスタムブランチを柔軟に選択できます。定義する出力データは、モジュールの出力スキーマで指定した構造に準拠する必要があり、フローとモジュール間で予測可能で信頼性の高いデータのやり取りを提供します。 入力と出力管理へのこの構造化されたアプローチにより、どのデータが利用可能で、コンタクトセンターソリューションの異なる部分間で受け渡される際にどのようにフォーマットされるかを正確に把握して、自信を持ってモジュールを構築できます。 入力 出力 モジュールの統合による予約フローの構築 予約フローは、顧客がサポートを必要とするとき、コンタクトセンターと自然にやり取りできる方法を示します。顧客が電話をかけてきたとき、新しい予約の作成、既存の予約の変更、旅行計画のキャンセルなど、必要なサポートの種類を選択するよう案内するプロンプトが聞こえます。4 番目のオプションは、人間の支援を必要とするより複雑な問い合わせ向けで、顧客をエージェントに直接接続します。 このアプローチが強力である理由は、フローが自動化されたサポートと人間のサポートの間をいかにシームレスに移行するかです。顧客が予約関連のオプションのいずれかを選択すると、フローは初期のやり取り中に収集された情報を使用して、予約操作モジュールを自動的に呼び出します。これにより、メインフローが全体的なカスタマーエクスペリエンスを調整しながら、モジュールが専門的な予約操作を処理できます。 フローは、モジュールで定義したブランチを通じ、異なる目的をインテリジェントに管理します。この例では、成功した予約操作は通話を自動的に終了しますが、複雑な変更やエラー条件など追加の支援を必要とするシナリオでは、以前のやり取りの完全なコンテキストを持つ人間のエージェントと接続できるキューに顧客をスムーズに移行します。 この設計により、顧客は可能な場合は効率的な自動化されたサービスを受け、必要に応じてパーソナライズされた人間のサポートのオプションも維持し、各顧客の特定の状況に適応するシームレスな体験を作成します。 モジュールの統合によるフロー シームレスな統合のためのモジュール入力の設定 モジュール呼び出しブロックを設定する際、予約操作モジュールがコンタクトフローとどのように統合されるかを完全に制御できます。正確な制御のために特定のバージョンでモジュールを参照するか、モジュールの進化に適応する柔軟なデプロイメント管理のためにエイリアスを使用するかを選択できます。設定プロセスにより、特定のユースケースでアクティブにするカスタムブランチを定義し、モジュールに渡される正確な入力パラメータを指定できます。 この構造化されたアプローチにより、顧客が期待する整合性と信頼性を維持しながら、コンポーネント間でデータがシームレスに流れるよう設計でします。入力データタイプは自動的にモジュールのスキーマ定義と一致し、統合がすべてのコンタクトセンター運用で一貫した動作を実現できます。 JSON パスを使用したモジュール出力へのアクセス モジュール属性の JSON パスを使用して、モジュールの出力データに直接アクセスできます。パス $.Modules.ResultData は、モジュールの出力スキーマで定義されたのと同じデータ構造に従います。この例では、 $.Modules.ResultData は、モジュール出力で定義された 2 つのプロパティ bookingId と confirmation を含む JSON オブジェクトです。 テストと検証 実装のテストは、コンタクトフローに電話番号を割り当てて、プロンプトに従って電話をかけるのと同じくらい簡単です。顧客が異なる予約操作のトーン信号を入力すると、対応する予約操作モジュールが呼び出され、予約 ID のプロンプトに続いて確認メッセージを受け取ります。これは、カスタム定義された入力、出力、ブランチのシームレスな統合によるものです。 予約操作で機能する同じフレームワークは、SMS 送信、残高確認、パスワードリセット、およびコンタクトセンター運用全体で標準化して再利用する必要があるその他のビジネスプロセスを含む、他の様々なユースケースに適用できます。 今日からコンタクトセンター運用を変革しましょう Amazon Connect フローモジュールへのこれら 3 つの強力な機能強化は、単なる新機能以上のものを表しています。より保守しやすく、スケーラブルで、インテリジェントなコンタクトセンター運用への根本的な変化です。カスタムブロックはフローとモジュール間のデータのやりとりの複雑さを排除し、バージョニングとエイリアシングはコンタクトセンターのアーキテクチャにエンタープライズグレードの信頼性のあるデプロイメントをもたらします。モジュールをツールとして使用する機能は、AI 駆動のカスタマーサービス自動化への全く新しい可能性を開きます。 ここまで見てきた旅行業界の例は、これらの機能の 1 つの実装例を示していますが、可能性はすべての業界とユースケースに及びます。金融取引、医療問い合わせ、小売サポート、またはその他の顧客とのやり取りシナリオを管理している場合でも、これらの機能強化は、ビジネスニーズとともに進化するコンタクトセンターソリューションを構築するための基盤を提供します。 これらの機能強化を活用して Amazon Connect 実装を変革する事例を見られることを楽しみにしています。改善されたモジュールの柔軟性、デプロイメントの信頼性、拡張された自動化機能の組み合わせにより、これまで不可能だった機会が生まれます。今すぐこれらの新機能をお試しください。コンタクトセンター運用を簡素化しながらカスタマーエクスペリエンスを向上させる方法を発見してください。 始める準備はできましたか？詳細な実装ガイドとベストプラクティスについては Amazon Connect のドキュメント にアクセスし、次世代のカスタマーエクスペリエンスの構築を開始しましょう。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

はじめに コンタクトセンターの運用チームがよく直面する課題として、従来のアプローチでは日常的な変更を行う際に開発者の支援とコード変更が必要になることによる遅延があげられます。Amazon Connect Data Tables は、管理者がノーコードインターフェースを通じて運用データを管理できるようにすることで、この課題に対処し、一般的なタスクの俊敏性を向上させ、実装時間を短縮します。 このブログ記事では、 Amazon Connect Data Tables を活用してコンタクトセンター運用を効率化する方法を解説します。実際のユースケースをテーマに、機能の実装に関するステップバイステップのガイドを提供し、運用効率と顧客満足度を向上させるためにデータテーブルを使う利点について説明します。 ソリューション概要 Amazon Connect Data Tables により、コンタクトセンターチームは、コードを書くことなく、直接コンタクトフロー内で運用データを作成、管理、参照できます。管理者は、休日スケジュール、緊急ルーティングフラグ、エージェント内線マッピング、場所固有のプロンプトなどの構造化された情報をカスタマイズ可能なテーブルに保存できます。コンタクトフローからこのデータにリアルタイムでアクセスすることで、動的なルーティング決定とパーソナライズされた顧客体験を推進します。 この機能により、日常的に発生する運用変更において、従来まで開発者に依存していた業務を解消できます。ユーザーは Amazon Connect UI で直接データテーブルを管理し、API を介してプログラム的に管理できるため、手動更新と自動化されたワークフローの両方に柔軟性を提供します。チームは、エージェント内線マッピング、緊急フラグ、機能フラグの切り替え、またはルーティングパラメータを即座に変更でき、設定変更にかかる時間を数日から数分に短縮できます。 ウォークスルー データテーブルの利点を説明するために、いくつかの実際のユースケースを見てみましょう。 ユースケース 1: 直通電話番号内線システム 資産管理会社では、富裕層の顧客を各担当ファイナンシャルアドバイザーに効率的に誘導することが重要です。以前は、企業は外部データソースと Lambda 関数とのカスタムコード統合を構築して、顧客にそのようなパーソナライズされたサービスを提供する必要がありました。データテーブルを使用すると、企業は、顧客がコールフロー中にアドバイザーの内線番号を入力するだけのノーコードインターフェースを備えた直通電話番号内線システムを実装できます。システムは以下を行います： アドバイザー電話番号内線マッピングを保存 アドバイザーの割り当てが変更されてもコード変更なしで即座にルーティング可能 ユースケース 2: 季節性のサイト閉鎖フラグ 小売企業は、冬季にサイト閉鎖フラグを更新し、プレミアム顧客の通話を処理するためには専門エージェントを割り当てる必要がありました。従来、これには IT チームへの変更依頼が必要で、遅延が発生していました。Amazon Connect Data Tables により、コンタクトセンターの管理者は、ノーコードインターフェースを通じてこれらの変更を独立して管理できるようになりました。システムは以下を行います： 冬季が始まったときにサイト閉鎖フラグを自動的に更新 プレミアム顧客の通話を処理するために専門エージェントをマッピング 反映時間を数日から数分に短縮 ユースケース 3: 季節性のワクチン接種キャンペーン 医療保険プロバイダーは、コンタクトセンターを通じて季節性のワクチン接種キャンペーンを促進する必要がありました。コンタクトセンターの管理者は、通常のコールフローを中断することなく、秋の期間だけカスタマイズされたワクチン接種リマインダーメッセージを再生したいと考えています。データテーブルを使用して、システムは以下を行います： 季節性のあるプロンプトを保存し、これらのメッセージを自動的にトリガーする日付ベースのルールを設定 管理者が IT のサポートを必要とせずにメッセージの内容とアクティベーション日を更新可能 前提条件 AWS アカウント 既存の Amazon Connect インスタンス データテーブル、キュー、エージェント、コンタクトフローなどを設定するための Amazon Connect 管理者アクセス 実装手順 以下のセクションでは、Amazon Connect Data Tables を使用した電話番号内線による直接エージェントルーティングの実装について説明します。同じソリューションを、上記にリストされた他のすべてのシナリオに拡張できます。 ステップ 1: Amazon Connect Data Tables を有効化 AWS コンソールで Amazon Connect に移動 インスタンスを選択してログイン 「 ユーザー 」の下の「 セキュリティプロファイル 」に移動 更新するセキュリティプロファイルを選択 「 アクセス許可 」セクションで、このセキュリティプロファイルのユーザーに対して「 データテーブル 」アクセスが有効になっていることを確認します。 ステップ 2: 各ユースケース用のデータテーブルを作成 実装を計画している各ユースケースに対してデータテーブルを作成します。以下では、エージェント内線ユースケース用のデータテーブルの作成について説明します。 Amazon Connect 管理 UI の「 ルーティング 」の下の「 データテーブル 」に移動 「 新しいデータテーブルを追加 」を選択して新しいデータテーブルを作成 名前とオプションの説明を入力 タイムゾーンを選択 (例: US/Eastern) ロックレベルを選択 (例: プライマリの値) (ロックレベルは同時レコード更新を制御します – 「プライマリの値」は変更中にプライマリキーフィールドのみをロックします) 「 属性を追加 」を選択して列の詳細を入力 列の名前を入力 (例: Extension、AgentName、AgentARN) 列のデータ型を選択 (例: Text) 必要に応じてプライマリ属性のチェックボックスを選択 検証が必要な場合は最小および最大テキスト長を入力 コレクション検証が必要かどうかを定義 3 つの属性を作成した後、以下に示すような空のテーブル構造が表示されます 「 レコードを追加 」を選択して、エージェントとその内線マッピングでテーブルを入力 Extension(内線番号)、AgentARN、AgentName などのエージェントの詳細を入力 同様に、他のシナリオ (例: 緊急閉鎖フラグ、カスタムプロンプトなど) に必要な新しいテーブル、列、レコードを作成します。閉鎖フラグのサンプルテーブル構造を以下に示します。 ステップ 3: 各ユースケース用のコンタクトフローを作成 シナリオを処理するため、それぞれのコンタクトフローを作成します。 エージェント内線ルーティングコンタクトフロー Amazon Connect コンソールで、「 ルーティング → フロー → フローを作成 」を選択 「 Agent Extension Routing 」という名前の新しいコンタクトフローを作成 「 ログ記録動作の設定 」と「 記録と分析の 動作を設定 」ブロックを追加 内線入力をキャプチャするために「 顧客の入力を保存する 」ブロックを追加。エンドカスタマーが架電し内線をダイヤルするとき、ここでデータ入力がキャプチャされます 「 データテーブル 」ブロックをコンタクトフローに追加 以下のスクリーンショットに従って「 データテーブル 」ブロックでクエリ設定を定義。クエリ設定は、作成したデータテーブルを検索し、必要な情報を取得します 訳注: データテーブルからの読み込み > データテーブルを評価 > 手動で設定 からクエリを設定します 以下のスクリーンショットに従って、エージェント内線ルーティング用の「 作業キューの設定 」ブロックを追加 訳注: エージェント別 > 動的に設定 > データテーブル 非内線ルーティング用の「 作業キューの設定 」ブロックを追加 「 キューへ転送 」ブロックを追加 最後に「 切断 」ブロックを追加 すべてのブロックを適切に接続し、コンタクトフローを「 保存 」および「 公開 」 (コンタクトフローは以下のスクリーンショットのようになります) カスタムメッセージング付き緊急ルーティングコンタクトフロー Amazon Connect コンソールで、「 ルーティング → フロー → フローを作成 」を選択 「 Emergency Routing 」という名前の新しいコンタクトフローを作成 「 ログ記録動作の設定 」と「 記録と分析の動作を設定 」ブロックを追加 ウェルカムメッセージを再生するために「 プロンプトの再生 」ブロックを追加 新しい「 データテーブル 」ブロックをコンタクトフローに追加 以下のスクリーンショットに従って「 データテーブル 」ブロックでクエリ設定を定義 緊急フラグ値が「 true 」かどうかを確認するために「 コンタクト属性を確認する 」ブロックを追加 フラグ値が「 true 」の場合に緊急閉鎖のカスタムプロンプトを再生するために「 プロンプトの再生 」ブロックを追加 非緊急ルーティング用の「 作業キューの設定 」ブロックを追加 「 キューへ転送 」ブロックを追加 最後に「 切断 」ブロックを追加 すべてのブロックを適切に接続し、コンタクトフローを「 保存 」および「 公開 」 (コンタクトフローは以下のスクリーンショットのようになります) ステップ 4: このソリューションを検証する方法 エージェント内線ルーティング検証： 電話番号を取得し、新しく作成したコンタクトフローに電話番号を関連付け 取得した電話番号に電話をかけ、作成したデータテーブルにマッピングされた有効な内線を入力 通話が内線用に設定されたエージェントにルーティングされます カスタムプロンプト付き緊急フラグルーティング検証： 電話番号を取得し、新しく作成したコンタクトフローに電話番号を関連付け 取得した電話番号に電話をかけると、緊急メッセージが再生されます データが変更された際の体験を検証するために、データテーブルのレコードを異なる値で更新してみましょう。 クリーンアップ これらの機能をテストし終わり、リソースをクリーンアップしたい場合： このブログの一部として作成されたサンプルまたはテスト用のデータテーブルを削除 コンタクトフローをアーカイブ キューを削除 ルーティングプロファイルとユーザーを削除 注意 ：常に開発環境でクリーンアップ手順をテストしてください。本番環境での誤った削除を避けるために、すべての本番リソースの設定状況を記録してください。 まとめ このブログ記事では、Amazon Connect のデータテーブル機能と運用データを管理するためのノーコードインターフェースについて概説しました。コンタクトセンター管理者がこの機能を使用して日常的な更新を合理化する方法を説明し、エージェント内線ルーティング、緊急閉鎖フラグ、季節に応じたメッセージングを含む実際のユースケースを通じて実装プロセスを確認しました。 こちら をクリックして管理者ガイドからさらに詳しい情報を確認し、コンタクトセンターでデータテーブルの実装を開始しましょう。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

このブログは、 “ AWS re:Invent 2025: A transformative moment for healthcare and life sciences ” の翻訳です。 今年で14回目を迎える AWS re:Invent には、6万人を超える経営陣、開発者、業界のリーダーがラスベガスに集結し、最先端のデータ・AI イノベーションを体験しました。数十の新サービス発表、数百のデモンストレーション、数千のセッションが開催される中、ヘルスケア・ライフサイエンス分野の企業が注目の的となりました。これらの企業は実際の活用事例を紹介し、Amazon Web Services（AWS）のソリューションを使って創薬を加速し、臨床業務を効率化し、患者体験を革新する取り組みを実演しました。 本記事では、AWS ヘルスケア・ライフサイエンスチームが厳選した注目セッション、重要な発表、顧客事例をご紹介します。 注目セッション re:Invent では、ヘルスケア・ライフサイエンス企業が数多くのセッションに登壇しました。特に印象的だったセッションをご紹介します： ライフサイエンス分野におけるリアルワールドエビデンス創出の加速化 臨床時間を取り戻す：Veradigm の AI 活用による業務変革 ノバルティスの次世代データプラットフォームがAI創薬を実現 UC San Diego Health、Amazon Connect で患者エンゲージメントを刷新 研究室から市場へ：アストラゼネカの全社的 AI 成功ストーリー ヘルスケアの変革：生成 AI が描く未来像 EHR の枠を超えて – AWS で実現する臨床・運用への最大インパクト 基調講演 Matt Garman の年次基調講演では、 Lila Sciences 、Bristol Myers Squibb、Cohere Health、Pfizerといったヘルスケア・ライフサイエンス企業が、イノベーションを牽引する業界リーダーの事例として紹介されました。開発者を「AWS の心臓部」と位置づけ、「発明の自由」を重視する Matt のメッセージは、20年間変わらない AWS の根本理念を表しています。 Swami Sivasubramanian のAI基調講演は、Allen Institute の取り組みから始まりました。同研究所が開発した、単一細胞マルチモーダル脳細胞データを解析する高度なニューラルネットワークモデルが紹介されました。Swami は講演の中で、特定の患者アウトカムを予測するモデルの学習や、分子構造とタンパク質相互作用を深く理解する AI モデルの開発など、複数のヘルスケア事例を取り上げました。 Peter DeSantis と Dave Brown は、AWS が追求し続ける6つの基本要素 – セキュリティ、可用性、パフォーマンス、弾力性、コスト効率、俊敏性 – について改めて強調しました。AI 時代においては、これらのクラウド基盤要素がこれまで以上に重要になっています。Dave Brown は、これらの要素を大規模に実現する Graviton と AWS のカスタムシリコン技術革新を紹介しました。 Werner Vogels は14年間の最後の基調講演で、「ルネサンス開発者」という概念を提唱しました。これは好奇心旺盛で、システム思考を持ち、効果的なコミュニケーション能力を備えた開発者像です。AI と開発者の進化について語った彼のメッセージは多くの共感を呼びました：「AI は私の仕事を奪うのか？そうかもしれない。AI は私を時代遅れにするのか？進化し続ける限り、決してそうはならない。」彼は開発者がオーナーシップを持つことの重要性を強調しました：「成果物はあなたのものであり、ツールのものではない。あなたが作り、あなたが責任を持つ。」 重要な発表 ヘルスケア組織のデジタル変革が進む中、今年の発表は業界が直面する根深い課題に正面から取り組むものでした：データプライバシー、臨床ワークフローの効率化、専門特化 AI 開発、セキュアなインフラ構築。 また、ライフサイエンス企業では、バリューチェーン全体で AI エージェントの活用が拡大しています。新サービスは、標的探索から個別化患者エンゲージメントまで、効率性を大幅に向上させながら市場投入までの時間短縮を実現します。 今週発表された数十の新サービス、機能、アップデートの中から、ヘルスケア・ライフサイエンス関係者が最もインパクトの大きいイノベーション領域を厳選しました。 データプライバシー・セキュリティの革新 セキュリティは最優先課題であり続けており、顧客がデータを安全に保護し、コンプライアンスを維持しながらイノベーションを推進できる複数の新サービス・アップデートを発表しました。中でも最もインパクトの大きい発表は、 AWS Clean Rooms の機能拡張で、プライバシー強化合成データセット生成が可能になりました。 この新機能により、組織とパートナー企業は共有データから回帰・分類機械学習（ML）モデル学習用のプライバシー強化合成データセットを生成できます。ヘルスケア・ライフサイエンス組織にとって、このアップデートは患者情報や機密データを公開することなく、より精密で用途に特化したモデル構築を可能にします。統計的妥当性を保ちながら設定可能なプライバシー保護を追加する合成データセット生成機能は、ヘルスケア業界最大の課題の一つ – データ活用とプライバシー要件のバランス – に直接的な解決策を提供します。例えば、研究機関は HIPAA に準拠しながら統計パターンを保持する合成データセットを生成することで、希少疾患研究での協力が可能になります。また、創薬チームは患者健康情報（PHI）を公開することなく、複数の臨床データセットでモデルを学習できます。 その他の重要な発表 ： データ主権： AWS AI Factories により、ヘルスケア・ライフサイエンス組織は業界規制・コンプライアンス要件を満たしながらAIの力を活用できます。機密患者データのローカル処理が可能になり、コンプライアンス体制が強化され、PHI 要件への準拠が実現します。例えば、ヘルスケア組織は病院内や自社のデータセンター内に AWS AI インフラを導入できるようになりました。 プロアクティブなアプリケーションセキュリティ： AWS Security Agent は、PHI を扱うヘルスケアアプリケーションに不可欠な積極的セキュリティ開発・監視を実現します。Security Agent は継続的セキュリティ評価を通じて HIPAA・GxP コンプライアンスの維持を支援し、患者・機密データに影響が及ぶ前にセキュリティ問題を特定します。 脅威検出： Amazon GuardDuty Extended Threat Detection は、ヘルスケア組織全体で統一されたセキュリティ可視性を提供します。多様なヘルスケアワークロード全体で患者データを標的とする高度な攻撃を特定できます。この新機能は複雑なヘルスケア IT 環境のセキュリティ監視を簡素化し、HIPAA 等の規制監査用包括的セキュリティレポート生成を支援します。 セキュリティハブ： AWS Security Hub は重要セキュリティ問題の優先順位付けと大規模対応を支援し、応答時間を改善します。ヘルスケア組織はほぼリアルタイム分析でダウンタイム中断を最小化し、問題優先順位付け・コンプライアンスチェックを自動化できます。 AI 技術の進歩 2025年を通じて、AWS はあらゆる組織が AI の力を活用しやすくする Amazon Bedrock AgentCore などの新サービス開発に継続投資してきました。re:Invent では、この流れが数多くの発表とともに加速しました。 特に注目すべき発表： Amazon Connect の患者エンゲージメント向け新機能 を発表。電子健康記録（EHR）との安全なリアルタイム統合により、患者・介護者のセルフサービス認証が可能になり、予約が最新かつ正確な情報でスケジュールされることを確認できます。Nova Sonic の高度音声モデルを活用した AI エージェントは、複数言語・アクセントに対応し、適切なペース・トーン・理解力で自然で人間らしい会話を実現します。 AWS は業界最高水準の価格性能で推論機能を提供する次世代汎用モデル、Amazon Nova 2 を発表しました。 Speech-to-speech： Amazon Nova 2 Sonic は音声間変換モデルで、開発者が音声アプリケーションを構築するための業界最高水準の会話品質、価格設定、音声理解機能を提供します。患者インタラクション・アクセシビリティ向上のため、Sonic はより自然な多言語会話と遠隔医療サービス・遠隔監視向けリアルタイム翻訳を実現します。ライフサイエンス分野では、研究者が音声でデータソースを調査し、仮説を立て、手動入力に代わって音声で実験作業を記録することで、時間節約と生産性向上を支援します。 マルチモーダルデータ： Amazon Nova 2 Lite (*)と Nova 2 Omni は拡張推論機能を備えた費用対効果の高い AI を提供します。強力な機能の一つがマルチモーダルデータ統合で、医用画像、テキストレポート、研究文献、患者データの統合解析を可能にします。100万トークンのコンテキストウィンドウにより、Lite は患者の全履歴を処理してより的確な推奨を提供できます。臨床試験・遠隔監視では、ウェアラブルから在宅監視機器まで複数のデータストリームを処理できます。 (* 訳者注：Nova 2 Lite は現在、日本国内に限定したクロスリージョン推論に対応しています。) 専門ドメインモデル開発： Amazon Nova Forge は専門ドメイン向けモデル開発を簡素化します。分子特性を予測する創薬アシスタント開発から、放射線学・病理学・ゲノミクス向けカスタムモデル構築でドメイン専門知識を深く組み込むヘルスシステム支援まで、ヘルスケア・ライフサイエンス業界で特に有用です。 反復作業の自動化： Amazon Nova Act は、電子カルテデータ入力、請求処理、フォローアップ調整などの反復的ワークフローの安全な自動化を実現します。 AWS EC2 Trainium3 と P6e UltraServers は、専門的ヘルスケア・ライフサイエンスモデル訓練のための価格性能向上オプションを提供します。医用画像、ゲノミクス、デジタル病理学などの複雑で大規模なデータセットでの訓練時に特に効果を発揮します。 データ管理・分析 安全でスケーラブルなデータ基盤は、AI 成功の原動力であり続けています。re:Invent で AWS は数多くのデータ管理・分析サービスを発表しました。ヘルスケア・ライフサイエンス顧客向けの注目機能は、ベクトルスケーラビリティとレプリケーションです。 Amazon S3 Vectors は、ベクトル保存・クエリのネイティブサポートを持つ初のクラウドオブジェクトストアで、Amazon S3 に保存されたコンテンツの AI エージェント、AI 推論、セマンティック検索向けに目的特化・コスト最適化されたベクトルストレージを提供します。ゲノム解析では、研究者はコストを抑えながら数十億のゲノムベクトルを効率的に保存・クエリできます。医用画像分野では、S3 Vectors は膨大な画像リポジトリ全体での高速類似性検索を可能にします。創薬では、類似分子構造の迅速特定により化合物スクリーニングを加速できます。 Amazon S3 Tables レプリケーションサポート は、データレジデンシー要件・災害復旧のコンプライアンスを簡素化します。マルチリージョンコンプライアンスでは、ヘルスケア企業が多様な規制要件を満たすためにリージョン間で患者データを簡単に同期維持できます。研究者にとっては、一貫したガバナンスを維持しながら研究拠点間でのデータ共有が簡素化されます。 戦略的提言 re:Invent での業界向け発表を踏まえ、ヘルスケア・ライフサイエンス組織のリーダーは以下の検討を開始しましょう： データ戦略の見直し： AWS Clean Rooms と S3 Vectors がプライバシーを維持しながら新たな共同研究イニシアチブをどう実現できるかを評価 AIロードマップの加速： Nova Forge と Nova 2 による専門モデルが特定の臨床・研究ドメインをどう変革できるかを検討 業務プロセス自動化の機会： Nova Act の自動化機能から恩恵を受ける大量管理プロセスを特定 インフラ計画： AWS AI Factories が、これまで AI 導入を制限していたデータ居住・推論レイテンシの懸念に対処できるかを評価 セキュリティ強化： 機密ヘルスケアアプリケーション・データ保護強化のため新しい AWS Security Agent を導入 まとめ AWS re:Invent 2025 は、ヘルスケア・ライフサイエンス組織にとって大きな転換点となりました。プライバシー保護協力、専門 AI モデル開発、ワークフロー自動化、セキュアインフラへの注力は、業界が直面する最も差し迫った課題に直接対応しています。既に AWS を活用しているヘルスケア組織には、患者ケア向上、研究加速、運用効率改善の即座の機会を提供します。クラウド導入初期段階の組織には、AWS がヘルスケア・ライフサイエンス固有のプライバシー、セキュリティ、専門ドメイン専門知識要件にどう具体的に対応しているかを説得力を持って示しました。 タグ: re:invent Stephanie Dattoli Stephanie Dattoli は、Amazon Web Services（AWS）のライフサイエンス・ゲノミクスマーケティング部門のワールドワイドヘッドです。ライフサイエンスとクラウド技術の融合領域を専門とし、過去10年間にわたって主要ライフサイエンス組織の新製品市場投入と市場拡大を支援してきました。スタンフォード大学で遺伝学の大学院修了証明書を取得し、ビジネスと戦略マーケティングの学部二重学位を保有しています。 Brian Loyal Brian Loyal は、Amazon Web Services のグローバルヘルスケア・ライフサイエンスチームでシニア AI/ML ソリューションアーキテクトを務めています。バイオテクノロジーと機械学習分野で16年以上の経験を持ち、顧客のゲノミクス・プロテオミクス課題解決支援に情熱を注いでいます。プライベートでは友人・家族との料理と食事を楽しんでいます。 Jennifer Rouse Jennifer Rouse は、AWS のヘルスケアマーケティング部門でワールドワイドヘッドを務めています。IBM、Ciscoなどの大企業や2つのクラウドベーススタートアップでリーダーシップを発揮し、直近では Forrester Research/Sirius Decisions でグローバルアナリスト兼アドバイザーを務めました。キャリアの大部分を、公共部門など従来十分なサービスを受けていない業界に変革をもたらす企業で過ごしました。公共部門での経験により、ヘルスケア、公共安全、教育、行政分野で人生を変える多くの技術プログラムに携わってきました。 Nadeem Bulsara Nadeem Bulsara は、ゲノミクス・ライフサイエンス専門の AWS プリンシパルソリューションアーキテクトです。13年以上のバイオインフォマティクス、ソフトウェアエンジニアリング、クラウド開発スキルと、研究・臨床ゲノミクス・マルチオミクス経験を活かし、世界中のヘルスケア・ライフサイエンス組織を支援しています。人々の長く健康な人生を実現するという業界使命に強く動機づけられています。 このブログは、Senior Solutions Architect の松永が翻訳しました。

この記事は、 Building a Credit Card Payment Processing Platform on AWS を翻訳したものです。 金融サービス業界（FSI）は大きな変革のただ中にあり、デジタル化が果たす重要な役割を考慮すると、電子決済はこの変革の中心的存在です。決済のキャッシュレス化が進展する中、業界がインクルージョン（包摂性）を促進する役割は重要な優先事項となっています。デジタル経済の革新と発展は、世界経済の安定した基盤として機能する決済によって支えられています。カード決済取引の裏側では多くの処理が行われており、クレジットカード処理の仕組みを明確に理解することは、企業が業務をより効果的に管理する上で役立ちます。本ブログ記事では、AWS上でクレジットカード決済処理プラットフォームを構築する方法を解説します。また、クレジットカード決済のオーソリゼーションにおけるアクワイアリング側とイシュアリング側の2つの高レベルなリファレンスアーキテクチャを紹介します。 ベネフィット 決済処理システムをクラウド上でモダナイズすることで、以下の目的が達成されます： 季節的な需要急増に対応するための迅速かつ効率的なスケーリング 高可用性を維持しつつ、年々増加するスループットをサポートし、厳格なセキュリティ要件に対応 データ居住要件や規制要件を遵守しながら市場へ展開し、グローバルビジネスを支援 新製品開発のための迅速なプロトタイピングを実現 クレジットカード決済処理では、金融機関が高可用性とスループットのSLAを満たすと同時に低遅延を実現する必要があります。 AWSは、 Amazon API Gateway 、 Amazon Managed Streaming for Apache Kafka (MSK) 、 Amazon DynamoDB などのツールとサービスを提供し、クラウド上で最新の分散型決済処理プラットフォームを構築し、毎秒数千件のトランザクションにスケールアップしたいお客様を支援します。AWSのお客様は、コンテナ化を強力な技術として活用し、アプリケーションの依存関係を持ち運び可能な方法で分離・管理することで、決済処理システムの可用性を大幅に向上させています。 組織が Amazon Elastic Kubernetes Service（EKS） を活用すると、需要やリソース可用性に応じてコンテナ化ワークロードのスケーリングと管理を自動化できます。また、AWSのネットワークセキュリティサービスと統合することで、さらに高い可用性と回復力を実現できます。さらに、自動化された監視・アラートツールをコンテナオーケストレーションプラットフォームと統合することで、決済処理システムの健全性とパフォーマンスをリアルタイムに可視化し、ユーザーに影響が出る前に先制的に問題へ対応することが可能になります。 AWSクラウドは、厳格なセキュリティ要件を満たすID管理を備えた、多層的なセキュリティを提供します。また、潜在的なセキュリティ設定ミス、脅威、または予期せぬ動作を特定するための脅威検知および対応サービスが利用可能です。AWSは、 Amazon Virtual Private Cloud（VPC） や AWS PrivateLink などの最新のネットワーク機能を提供し、メッセージがパブリックインターネットを経由せずに決済事業者間で通信することを可能にします。グローバルな顧客は、複数のAWSアベイラビリティゾーンおよびリージョンを使用して新規市場に拡大することができます。さらに、顧客は AWS Artifact のコンプライアンスレポートや認証、ベンダーデューデリジェンスメカニズムを活用し、AWSが責任を負う統制を理解・立証できます。また、AWSのサービスやリソースを活用して堅牢な統制環境を構築することで、現地市場におけるコンプライアンス要件への準拠を実証することが可能です。 開発者は、AWSのツールやサービスを活用することで、コンプライアンス、セキュリティ、インフラストラクチャ・アズ・コードの標準化と自動化を実現できます。また、技術プロダクトマネージャーは開発チームと連携して顧客と迅速にプロトタイプを作成し、新たなユースケースの解決に役立てます。AWS DevOpsは開発者が新機能を迅速にリリースできるようにし、運用チームがアプリケーションを本番環境に投入するまでの時間を短縮します。 AWS Config Rules 、 Service Catalog （ガバナンス・アズ・コード、セキュリティおよびIAMポリシー、バックアップ保持ポリシー、ロギング・モニタリングポリシー）、 CloudFormation Guard などのツールにより、中央管理チームは分散開発チームを容易に統制でき、コンプライアンスとクラウドのベストプラクティスを維持しながら迅速な開発を実現します。 クレジットカード決済処理の構成要素 クレジットカード決済は通常、3つの主要なステップで構成されるメッセージ取引として処理されます。最初のステップは取引の「オーソリゼーション（信用照会）」です。オーソリゼーションはリアルタイムで行われ、発行銀行に照会してカード所有者の口座に資金が存在することを確認します。また、発行銀行は取引を承認するか拒否するかの判断も提供します。第2のステップは取引の「決済」です。決済では、オーソリゼーション済み取引をまとめて発行銀行に送付し、照合が行われます。第3段階である「清算」では、資金を加盟店の銀行口座へ移動します。 次に、クレジットカード決済における主要なプレイヤーの概要を見ていきましょう。これにより、クレジットカード決済のバリューチェーンの一部を説明し、アクワイアラー処理と発行者処理のリファレンスアーキテクチャを提示します。 加盟店には、企業、起業家、個人事業主およびその間のあらゆるタイプの事業者が含まれます。加盟店が決済取引プロセスにおいて基盤的な役割を果たすのはカード決済受入ツールを活用するためです。具体的には、カード取引用のクレジットカード端末またはPOSシステム、決済ゲートウェイを備えた安全なe コマースウェブサイト、あるいは拡大を続けるアプリケーション群に統合された決済手段などがあります。 決済ゲートウェイは、決済ポータル（ウェブサイト、携帯電話、音声応答サービスなど）と決済処理業者（アクワイアラー）間の情報転送を通じて、決済取引を仲介します。 決済処理業者は、加盟店およびその取引銀行に代わってクレジットカード・デビットカード取引を処理する企業です。クレジットカードライフサイクルに関わるすべての関係者を結びつける決済処理業者は、単なる処理機能を超え、事業成長を支援する包括的な決済関連サービスを提供するように進化しています。 アクワイアラー（加盟店契約会社または加盟店管理会社）は、加盟店口座を開設・管理する機関です。加盟店口座とは、企業が電子決済カード取引を受け付け処理できるビジネス口座の一種です。クレジットカードやデビットカード決済を受け付けるすべての企業は、アクワイアラー銀行や独立系販売組織（ISO）などの機関を通じて加盟店口座を開設できます。また、決済代行業者などを通じて、サブ加盟店口座（別の企業が代わりに加盟店口座を提供する形態）を開設することも可能です。カード決済取引中、アクワイアラーまたはその処理業者は、加盟店とカードネットワーク間で取引リクエストと認証データをやり取りします。 カードネットワーク（ブランドネットワーク）は、顧客、加盟店、発行銀行、アクワイアラーを結びつけます。カードネットワークは、決済処理の統括機関として機能し、主要なカードネットワークには、アメリカン・エキスプレス、ディスカバー、マスターカード、銀聯（ユニオンペイ）、VISAなどがあります。カードネットワークはインターチェンジ料率を設定し、イシュアーとアクワイアラー間を仲介し、安全で迅速かつ効率的な決済を促進することに努めています。 イシュアー（カード発行銀行またはカード発行会社）は、クレジットカードを発行する機関であり、消費者を金融システムに接続して事業者への取引資金調達を促進するという、重要なサービスを提供しています。この資金調達プロセスは、事業者が存続し繁栄するための財務的な原動力となっています。 消費者（カード保有者）は、対面（カード提示）または非対面（カード非提示）の方法で支払い認証情報を提供し、カード取引を開始します。取引金額は金融機関に記録され、口座の種類に応じて貸方または借方として処理されます。カード決済取引のライフサイクルはさまざまな要因で変動しますが、オーソリゼーション・決済・清算という基本プロセスは固定されています。本稿ではカード取引ライフサイクルの第1段階である「オーソリゼーション」について、イシュアーとアクワイアラー双方のリファレンスアーキテクチャを用いて解説します。 オーソリゼーション クレジットカードライフサイクルの最初のステップはオーソリゼーションです。顧客は、対面または安全な通信を通じて加盟店に支払いカードの認証情報を提示します。カード提示取引の場合、カードの詳細情報は、カードチップの挿入、タッチ決済、カードのスワイプ、または手動でのカード入力などの方法を通じてPOS端末に伝達されます。物理的なPOS取引では、EMVカードまたはデジタルウォレットと端末間で通信する際に、アプリケーション識別子（AID）とカード所有者認証方法（CVM）が決定されます。カード非提示取引では、カード情報が加盟店プラグインや利用可能な決済ウォレットなどの複数のオプションを通じて提供されます。決済サービスプロバイダー（PSP）は、チェックアウト時にカード情報をトークン化する機能を提供し、加盟店によるカード認証情報の保存を防止します。カード情報は、適切な決済処理業者へルーティングするために、暗号化されて決済ゲートウェイに送信されます。決済処理業者はカードBIN（カード番号の最初の6 桁または8 桁）または口座情報を確認して、取引に適用すべきサービス（不正スコアリングやアカウント更新サービスなど）を決定します。アカウント更新サービスは、カード紛失・盗難時にカードライフサイクルにおける最新カード番号を非対面取引向けに提供するために利用されます。プロセッサーは決済スイッチと連携して取引をルーティングすべきカードネットワークを決定します。また、ネットワーク送信前に適切なメッセージ形式（ISO 8583、ISO 20022など）とレイアウトに変換する責任を負います。 Acquiring Processor Authorization Flow カードネットワークがネットワークメッセージを受信すると、必要に応じて支払い情報をデトークン化し、カードの種類・取引タイプ・支払いチャネルに応じて、不正利用のスコアリングや支出管理、データ変換、デジタル認証、その他の検証サービスといった関連する代行サービスを実行します。 Issuer Processor Authorization Flow カードネットワークは、発行銀行またはプロセッサーにメッセージを送信し、承認または拒否の応答を返す前に、リスク管理・カード制御・残高・チップ・住所・利用頻度・ポリシー・その他の必要なチェックを実行します。応答メッセージには承認の場合は「0-承認」などの理由コード、拒否の場合は「05-承認不可」または「62-制限付きカード」などの理由コードが提供されます。カードまたはトークンの種類および各取引のチャネルに応じて、カードネットワークまたは発行者はカード取引用に一意に生成される動的情報を検証します。 AWS におけるオーソリゼーションのためのリファレンスアーキテクチャ 以下のアーキテクチャ概要図は、AWS 上に構築されたオーソリゼーションシステムの主要コンポーネントと、異なるチャネルおよび各種スキーム間の通信モデルを示しています。 フローは、さまざまなチャネルが暗号化されたカード情報を、セキュアな通信回線を通じて Amazon API Gateway に送信するところから始まります。 AWS WAF を有効化することで、SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃といった一般的なWeb攻撃からAPI Gateway APIを保護できます。API Gatewayは Amazon Cognito と統合されているため、許可されたユーザーのみがAPIにアクセスでき、リソースを不正アクセスから保護できます。 承認済み決済トランザクションは、ネットワークロードバランサー経由で Amazon Managed Streaming for Apache Kafka（MSK） に送信されます。PCIではカード所有者データの転送中と保存時における暗号化が義務付けられています。Amazon MSKはデフォルトでTLS 1.2を使用し、MSKクラスターのブローカー間で転送されるデータを暗号化するために、TLS 1.3の使用を推奨しています。 転送中のTLS暗号化（クライアント-ブローカー間、ブローカー間）、 TLSベースの証明書認証 、 SASL/SCRAM認証 は、 AWS Secrets Manager の支援によって実現できます。Kafkaトピック内のトランザクションは、AWS Fargateコンテナによってリアルタイムで消費されます。 AWS Fargate は Amazon ECS と組み合わせて使用できます。これにより、Amazon EC2インスタンスのサーバーやクラスターを管理せずにコンテナを実行できます。 Amazon ECR プライベートリポジトリを使用すれば、Amazon ECSタスクがプルするコンテナイメージやアーティファクトをホストできます。 コンテナはデータを決済用HSM（ハードウェア・セキュリティ・モジュール）に渡し、復号化されたデータを受け取ります。決済用HSMは、新たに提供が開始されたAWSのフルマネージド型決済HSMサービスである「 AWS Payment Cryptography 」を通じてプロビジョニングできます。また、 DynamoDBクライアントサイド暗号化ライブラリ を使用すれば、原文を暗号化して、その暗号テキストを暗号されているデータベースに保存できます。トークン応答は、内部アプリケーション操作のためにアプリケーションデータベースに保存されます。 Amazon ElastiCache for Redis 上のサブミリ秒レイテンシのインメモリデータキャッシュを使用することで、カードネットワークからのカード利用可能リクエストに即座に対応できます。トークン化された情報を、 AWS Step Functions を使用して様々なビジネスフローに適用すると、カードと取引タイプに基づくBINチェック、リスクチェック、アカウントチェック、不正検知チェック、その他の付加価値サービスを検証できます。検証後、応答はISO形式にフォーマットされ、消費のためにイグレスAmazon MSKに送信されます。複数のKafkaリスナーがカードネットワークに接続できます。 AWSにおけるイシュアーオーソリゼーションのリファレンスアーキテクチャー イシュアー処理フローにおいて、カードネットワークはソケット接続を介してペイロードを送信し、発行銀行またはプロセッサー（IBP）へオーソリゼーションリクエストを中継します。オンプレミスまたはコロケーション施設に設置された決済ネットワークインターフェースプロセッサー（PNIP）は、カードネットワークからのTCP/IPトラフィックを受信します。IBPは AWS Direct Connect を利用して内部ネットワークから標準イーサネット光ファイバーケーブル経由で、AWS Direct Connectロケーションに接続できます。AWS Direct Connectと AWS Transit Gateway の組み合わせは、複数のVPCとオンプレミスネットワークを接続するネットワークトランジットハブを構築するのを支援します。 オーソリゼーションリクエストのトラフィックは、AWS Transit Gateway経由でNetwork Load Balancerを介してトークナイゼーションVPCにルーティングされます。Network Load Balancerは接続レベル（レイヤー4）で動作し、IPプロトコルデータに基づいて顧客VPC内のターゲットコンテナへ接続をルーティングします。トークナイゼーションVPCは機密カード情報をトークン化します。カードデータに対する検証や確認といった暗号処理は、AWS Payment Cryptographyのようなスケーラブルで耐障害性の高いサービス上で実行する必要があります。情報は暗号化されたデータベースに保存されますが、データベースに依存せずAmazon ElastiCacheから取得することができます。 リクエストはオーソリゼーション決済処理VPCに転送され、さらに処理されます。オーソリゼーションコンテナは Amazon Elastic Kubernetes Service（EKS） と統合でき、アプリケーションをデプロイすることができます。 オーソリゼーションコンテナは、カード種別に基づくビジネス検証チェックのため、承認リクエストに追加情報を付加します。ビジネスプロセスワークフローエンジンは、カード種別に応じた不正検知・リスク・取引頻度・口座情報およびチップ・PIN・トークン・限度額・現金取引などのさまざまなポリシーに基づく複数のチェックを実行します。ビジネス検証応答は Amazon Managed Streaming for Apache Kafka (MSK) のトピックにストリーミングされます。オーソリゼーションコンテナが応答を処理して、 Amazon DynamoDB に情報を保存します。その後、IBPはオーソリゼーション応答（承認または拒否応答など）をカードネットワークに送信します。この応答は、アクワイアリングプロセッサーを経由して最終的に加盟店端末に戻ります。 決済事業者は、貴重な顧客データを保有しています。このデータは、 Amazon Comprehend を使用して、感情分析や商品レビュー分析といった顧客インサイト導出に活用できます。また、 Amazon Personalize を活用すれば、商品ランキングや特定商品の推奨、カスタマイズされたダイレクトマーケティングといった、リアルタイムなパーソナライズドレコメンデーションを実現できます。 まとめ クレジットカードは、店頭決済と非対面決済の両方において重要な決済手段であり続けています。キャッシュバックやカード特典、航空会社のポイントなどは、顧客がクレジットカードで支払う理由の一部でしかありません。2022年、米国の大手クレジットカード発行会社では、旅行・娯楽支出の増加に伴い、クレジットカードの利用が大幅に増加しました。また、クレジットカード分野では、デジタルファーストのクレジットソリューションによる革新も進んでいます。この革新により、顧客の申し込みが承認されるとすぐに仮想カードやトークンが利用可能になり、カード情報をデジタルウォレットに即座に追加できるようになります。 顧客はクレジットカード決済が数秒で処理されることを期待しています。本稿では、AWSのサービスを活用し、安全かつリアルタイムに処理でき、高い耐障害性を備え、ピーク時の決済量急増にも対応可能なクラウド決済処理ソリューションの構築方法について説明しました。また、クラウドベースの決済システムでは、AWSのツールとサービスを用いて PCI DSS に準拠した堅牢なセキュリティ対策を実現できます。フィンテック企業により、加盟店が自社ブランド（別名プライベートラベル）クレジットカードを容易に発行し、顧客セグメントの独自のニーズやライフスタイルに基づいた報酬をカスタマイズできるようになったことで、イノベーションはクレジットカード市場を活性化し続けています。 AWSとの連携方法や、世界中の決済顧客が決済処理を実行するのを当社がどのように支援しているかについての詳細は、AWSアカウントマネージャーにお問い合わせいただくか、 AWS Financial Services – Payments をご覧ください。 免責事項： 本投稿におけるリファレンスアーキテクチャに関する記述は、説明を目的とした参考情報であり、公開時点での情報に基づいています。記載の手順や推奨事項は教育目的および初期概念実証を意図したものであり、企業全体向けの完全なソリューションではありません。組織に適したアーキテクチャ設計についてはお問い合わせください。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

 株式会社ダイレクトマーケティングエージェンシー （以下、DMA）は、2006年の創業以来、ECビジネス支援エージェンシーとして自社開発にこだわり、ITとBPOソリューションを提供してきました。近年のEC市場では、顧客行動の多様化やチャネルの増加により、データ活用の重要性が一層高まっています。DMAはこうした背景を受け、データレイクおよびAI機能を実装したEC基盤「D-Sales ECクラウド」を開発・提供してきました。 本ブログでは、DMAがAmazon Bedrock AgentCoreを中核に据えて開発した、 AIオートパイロット型CRMプラットフォーム「リピートMAX」 の開発事例をご紹介します。 背景と課題 多くのEC事業者は、CRM運用において以下のような構造的な課題を抱えています。 1. CRM運用の属人化問題 従来のCRM運用では、施策の立案から実行まで、担当者の経験とスキルに大きく依存していました。優秀な担当者の異動や退職により、それまで築き上げてきたノウハウが失われてしまうリスクが常にありました。また、担当者によって施策の質にばらつきが出てしまうことも大きな課題でした。 2. 短期的施策への偏重 四半期ごとの売上目標達成を優先するあまり、タイムセールや一時的な割引施策に依存し、顧客の購買サイクルや中長期的な関係構築を考慮したCRM設計が十分に行われていないケースも少なくありませんでした。特に、初回購入から2回目・3回目の購入につながらないことが、LTV最大化の大きな障壁となっていました。 3. データ統合・活用の複雑さ EC運営の現場では、複数のマーケティングツールが併用され、データが分散していることが一般的です。その結果、顧客行動の全体像を把握することが難しく、ツール間連携やデータ統合に大きな運用負荷がかかっていました。 ソリューションの概要 DMAは、単なるツール統合やルールベースの自動化では上述の課題解決が難しく、課題を根本から解決するために顧客行動を文脈として理解し、状況に応じて判断を変えるAIの活用が不可欠と考えました。そこで、Amazon Bedrock AgentCoreを中核とした次世代CRMプラットフォーム「リピートMAX」の開発に着手しました。「リピートMAX」に搭載されているAIオートパイロットが売上予測に基づいた最適なCRM施策を提案します。「ターゲティングからクリエイティブ/売上予測/事後検証」まで全てのCRMプロセスを対話形式で選択していきます。目的に応じた提案施策を選択するだけで最適CRM施策によるLife Time Valueの最大化を実現します。 図 1: リピートMAXについて 以下が「リピートMAX」のシステム概要になります。 図2:リピートMAXのシステム概要図 「リピートMAX」の処理の流れは以下です。 ECサイト運営者はWebブラウザ上のWidgetを通じて、 売上予測、クリエイティブ生成、AIチャットなどの機能を選択し、必要な情報を入力する フロントエンドが入力された内容をAPI Layerに送信する API Layer は入力内容に応じて、対象者抽出、売上予測、クリエイティブ、AIチャットを行う 3 の処理を行う際、必要に応じて Amazon Bedrock AgentCore を利用したり、Amazon Redshift Serverless、Amazon Aurora 、Amazon S3から顧客データや過去の購買履歴を取得する ユーザーの操作ログ等の分析のため、外部連携も行う システムはユーザーの入力に応じて以下のアウトプットを生成・提供する ・対象顧客セグメントの抽出結果 ・売上予測データとレポート ・マーケティング用のクリエイティブ素材 ・AIチャットによる質問への回答 Amazon S3およびAmazon Redshift Serverlessに蓄積された顧客行動データを基に、AgentCore上のAIエージェントが推論を行い、その結果を再びデータレイクへフィードバックする循環型アーキテクチャを構築しています。また、「リピートMAX」は、以下の観点でAWSサービスを選定しています。 日本国内リージョンでの運用による セキュリティ確保 豊富なAIサービスによる 開発効率の向上 Amazon Bedrock AgentCore、Amazon S3、Amazon Redshift Serverless、AWS Lambda といったサーバーレスなサービスの採用による 初期投資の最小化 代表取締役の芦塚氏は、AWS のサービス選定理由をこう話します。 ” 従来のCRMの枠を超えた、真にインテリジェントなCRMを実現したいと考えました。そのため、データの統合と活用、コスト最適化、そして施策の自動化という点に重点を置きました。また、セキュリティ面では顧客データの取り扱いに特に慎重な取引先も多く、東京リージョンに閉じた環境を構築できる点が決め手でした。” 開発の体制とプロセスについて DMAの開発責任者岡本氏および福田氏は、開発体制とプロセスについて、以下のように述べています。 ”外部からAWS開発経験のあるエンジニア2名を採用し、アジャイル開発手法を採用してプロジェクトを推進しました。しかし、Amazon Bedrock AgentCoreという新技術の導入において、十分なリファレンスやベンチマークが存在しない中で、試行錯誤を重ねながら設計・実装を進めました。経験者を見つけることは困難で、一度ゼロから再構築しました。この過程を通じて、新技術開発に適したエンジニアの特性やプロジェクト管理の知見を獲得し、Amazon Bedrock AgentCoreの特性理解やデータレイク構築における既存システムとの統合やAI活用最適化のノウハウを蓄積しました。テスト段階では、機能ベースの○×判定に加え、AIチャットの回答精度を評価するシナリオテストを重視し、自社ECプラットフォームの実データを活用した検証や、顧客との協働による分析結果の妥当性確認を実施することで、実用性の高いソリューション開発を実現しました。” 導入効果と今後の展開 AIオートパイロット型CRMプラットフォーム「リピートMAX」を導入された大手百貨店 EC サイトにおいて、以下の効果が得られています。 リピート購入率が125%向上 離脱予兆顧客のCVRが150%以上改善 CRM運用の工数が大幅に削減され、約1時間まで効率化 顧客は AIによる最適なターゲティングとタイミングの自動化により、従来は見逃していた顧客接点を効果的に活用できるようになったと評価しています。 DMAは、このプロジェクトを通じて得られた知見を基に、以下のような機能拡張を計画しています。 より高度なAI予測モデルの導入 クリエイティブ提案機能の強化 まとめ AIオートパイロット型CRMプラットフォーム「リピートMAX」の事例は、技術革新とビジネスニーズの適切な統合を意識しつつ、いかにバランスを取りながら実践的な価値を生み出せるかが分かる好例です。この取り組みが、EC業界におけるDX推進の重要なベンチマークとなること、今後も機能拡充してより多くのEC事業者のビジネス成長に貢献していくことを期待します。 また、内製化でソフトウェアに生成AIや新技術を組み込む上での課題および解決方法は多くの方に参考になるのではないでしょうか。AWSのサービスを活用した本事例は、クラウドネイティブな開発アプローチの有効性を実証する好例です。AI活用をご検討の企業様は、ぜひAWSまでご相談いただければと思います。

本記事は、2025 年 11 月 25 日に公開された How Rivian and Volkswagen Technology Group Built Real-Time Vehicle Security with Amazon Kinesis Video Streams を翻訳したものです。 このブログ記事では、Rivian と Volkswagen Group Technologies (Rivian) が AWS と提携し、Rivian の Gear Guard 機能強化を通じて車両のセキュリティ向上に役立てた方法をご紹介します。 Amazon Kinesis Video Streams (KVS) を使用することで、Rivian はより洗練されたリアルタイムビデオストリーミングソリューションを構築し、車両所有者が Rivian モバイルアプリケーションから車載カメラのライブ映像をより即座にアクセスできるようになりました。 はじめに Rivian は、R1T ピックアップトラック、R1S SUV、Electric Delivery Vans(EDVs) で知られる先駆的な電気自動車メーカーで、自動車ソリューションを絶えず革新しています。Rivian の中核的な製品の 1 つである Gear Guard は、オーナーが不在の際に車両とその内容物を保護するための包括的な機能群です。当初の Gear Guard は、車載カメラと AI アルゴリズムを使用して、不審な人的活動を検知し、ビデオを記録し、Rivian モバイルアプリでオーナーに通知するものでした。これらのビデオと記録は、車両のローカルに保存されていました。この重要なセキュリティ機能の自然な進化として、車両からリアルタイムのライブビデオストリーミングを Rivian モバイルアプリに直接導入することになりました。これにより、オーナーは検知された事象中に即座に視覚的にアクセスできるようになりました。 図1 Rivian Gear Guard キャラクター ライブ動画ストリーミングのビジネス要件と技術要件 Gear Guard のライブビデオストリーミングを実装するには、重要な機能、パフォーマンス、セキュリティ要件に対応できるより堅牢なソリューションが必要でした。このシステムの主な目的は、車両所有者が認証済みのモバイルデバイスから Gear Guard のセキュリティカメラのライブビデオストリームを遠隔で視聴できるようにすることです。車両所有者は、オンデマンドでこのライブビューを開始したり、車両が駐車中、施錠中、無人の状態でも、Gear Guard のアラームシステムからの通知に応じてライブビューを開始したりできます。 Rivian がこの新しいライブ動画ストリーミングサービスを開発する際の主な機能要件は以下のとおりでした: トラックベッドカメラを含む、車両のカメラからのリモート映像の視聴。 特定のカメラを選択するか、カメラの映像を切り替えて表示するモードを選択できる機能。 アラームやモーション検知時にモバイル通知を生成し、最も関連性の高いカメラストリームを選択するボタンとサムネイルガイダンスを表示。 イベントの同時ライブストリーミングと車内ストレージへの録画。 さまざまな携帯通信会社や Wi-Fi ネットワークプロバイダー、モバイル端末に対応。 Rivian が応答性の高いユーザーエクスペリエンスを実現するために重要だった主なパフォーマンス基準は以下の通りです: アクティベーション時間: リクエストからストリーム表示までの時間は 5 秒未満。 ストリーム遅延: カメラキャプチャからモバイル表示までの時間は 1 秒未満。 カメラ切り替え時間: カメラ選択から表示までの時間は 1 秒未満。 Rivian の主なプライバシーとセキュリティの要件は次のとおりでした: エンドユーザーのプライバシーは、Rivian にとって設計プロセス全体を通して最重要の関心事でした。プライバシーの閾値分析とセキュリティ脅威分析が行われました。たとえば、Gear Guard アプリケーションは、サラウンドビューの校正への干渉や望まれないビデオトリガーを防ぐため、工場モードでは無効になっています。さらに、Rivian はストーカー行為への悪用を防ぐため、1 セッションおよび 1 日あたりの使用制限を設けました。 Amazon Kinesis Video Streams の選定理由 複数のオプションを評価した結果、Rivian は機能、パフォーマンス/スケーリング、セキュリティ/プライバシーの要件をすべて満たしていたため、ビデオストリーミングサービスとして Amazon KVS を選択しました。意思決定プロセスで重要だった Kinesis Video Streams の主な機能は次のとおりです。 複数のストリーミングおよびメッセージングプロトコル (Web リアルタイム通信 (WebRTC)、リアルタイムストリーミングプロトコル (RTSP)、ストリーム伝送制御プロトコル (SCTP)) をサポートします。 堅牢なシグナリングインフラストラクチャ – フルマネージドシグナリング、自動スケーリングとコミュニケーション用のチャネルの動的作成をサポートする STUN および TURN サーバー。 包括的な監視機能 – サーバーの正常性と稼働時間のリアルタイム監視、コスト監視、メトリクスとアラートのための Amazon CloudWatch との統合、パフォーマンス追跡用のカスタムダッシュボード作成機能。 セキュリティ – Rivian のセキュリティモデルと適切に統合される AWS セキュリティとその他ネイティブサービスとの組み込み統合。 拡張性 – オープンな標準 API をサポート (例: V4 signer URL を生成して、有効な署名付き一時 URL を生成し、Rivian の IoT およびモバイルデバイスでベンダーニュートラルな機能を許可)。複数の言語でアルゴリズム、クライアント側の実装、およびリファレンス SDK が利用可能です。 パフォーマンス – Native WebRTC は、サブ秒レイテンシーのストリーミングをサポートし、同時に数百万のストリームをサポートするための自動スケーリングと、最適なパフォーマンスのための地域展開をサポートします。 深い技術的コラボレーション – Amazon Kinesis Video Streams サービスチームとの緊密なパートナーシップにより、SDK 統合と SigV4 デバッグ機能が実現し、開発の加速と複雑な実装課題の解決が可能になりました。 システムアーキテクチャ Gear Guard のライブカメラアーキテクチャは、WebRTC を中心に構築されています。WebRTC は低レイテンシーを実現し、双方向のオーディオ/ビデオをサポートしているため、将来的にクライアントから車両への音声インタラクションを可能にする助けとなります。 図2 Gear Guard のテクニカルアーキテクチャ ストリーミングシーケンスを開始 1 認証済みでペアリングされたモバイルアプリケーションのインスタンスがリモートトリガーを開始します。このリモートトリガーはモバイルゲートウェイを経由してクラウド上のリモートコマンドプロセッサに渡され、車両に送信されます。 2 モバイルと車両はそれぞれ、クラウドサービスから署名付きシグナリングサーバーの URL と TURN サーバーの詳細を要求し、Amazon KVS インフラストラクチャに接続できるようになります。 3 Amazon KVS シグナリングチャネルは、車両とモバイルアプリケーション間のピア間 IP アドレスの対話型検索を含む ICE を容易にし、Amazon KVS WebRTC TURN サーバーを経由した接続にフォールバックします。車両のカメラストリーミングとモバイルビューアーアプリケーションは、SDK ハンドシェイクで開始され、直接または間接的な接続を介して送信されるビデオストリームのパラメータを確立するのに役立ちます。 4 車両は WebRTC SRTP (暗号化) チャネルを介して RTSP ビデオストリームをモバイルに転送します。モバイルは WebRTC データチャネルを介してコマンドを送信し、別の SVS カメラから RTSP ストリームを選択できます。 主要な実装の概要 モバイルと車両間のメトリクスとイベントの交換にデータチャネルを使用する。 WebRTC データチャネルを利用することで、モバイルアプリケーションと車両間の情報のより堅牢な双方向の交換が可能になりました。これには、モバイルアプリケーションから車両へのカメラ切り替え要求などのリモートコマンドの送信が含まれ、ユーザーが異なるカメラビューを選択できるようになりました。逆に、ストリーミングセッションの終了を示すセッション終了要求が車両からモバイルアプリケーションに送信されました。さらに、データチャネルはストリーミング開始までの時間などの重要なメトリクスの送信を容易にし、パフォーマンスの監視と最適化を可能にしました。より効率的で構造化された通信を確保するため、このチャネルを介して送信されるすべてのデータは、プロトコルバッファ (protobuf) を使用してフォーマットされました。 シグナリングサーバーの資格情報を配信するための、車両証明書ベースの認証 Go プログラミング言語ベースのクラウドサービスが、一時的な資格情報を持つ SigV4 署名付き URL、TURN と STUN 接続の詳細を車両とモバイルアプリケーションに認証して提供します。これにより、SDP オファーを開始し、ICE 候補を確立できます。リクエストの順序は関係ありませんが、SDP オファーは 5 秒以内に開始する必要があります。車両はサービスに対して mTLS で認証され、その ID は証明書に埋め込まれています。モバイルアプリケーションのリクエストは oauth2 JWT で認証され、ユーザーが要求された車両にプロビジョニングされているかどうかを確認します。 このサービスは、車両の信号チャネルが存在するかどうかを確認するために、マルチリージョン Amazon DynamoDB テーブルを使用し、その後、車両に新しい Amazon Kinesis Video Streams 信号チャネルを提供するか、既存のものを再利用します。Amazon DynamoDB レコードは、30 日間の有効期限を設定するのに役立ち、リクエストごとに更新されます。 Amazon DynamoDB のレコード有効期限切れイベントが Lambda 関数をトリガーし、30 日間使用されていない場合にシグナリングチャネルを削除するのに役立ちます。これにより、Gear Guard サービスのアクティブユーザーを追跡し、プロビジョニングされたリソースのコストを削減するのに役立ちます。wss エンドポイントは SDP オファーを送信するために使用されます。SigV4 署名付き URL には、ChannelARN、ClientId、有効期限、セキュリティトークンなどが埋め込まれています。このサービスには、STUN サーバーと TURN サーバー (UDP、セキュア UDP、TCP) と資格情報も含まれています。 図3 Gear Guard ライブカメラフィード AWS リージョンベースのシグナリングサーバーと TURN サーバーの割り当て: ピア間接続で TURN サーバーを使用する場合、車両の位置と同じ AWS リージョンにシグナリングと TURN サーバーを割り当てたいと思います。これは、米国西海岸に車両とモバイルアプリケーションがあり、シグナリングチャネルが米国東海岸にプロビジョニングされる可能性を回避するためです。組み合わせは次のとおりです。 図4 Gear Guard の地域展開 最適化された実装では、AWS Elastic Kubernetes Service (Amazon EKS) 上で us-east-1 および us-west-2 の両リージョンにデプロイされているクラウドサービスが、カスタムの地理位置情報サービスを使用して、車両がカンザス州レバノン (39°50′N 98°35′W) の東側か西側のどちらに位置するかを特定するのに役立ちます。AWS と Rivian は、この地点を米国の中心地と特定しています (図 4 の破線で示されています)。このサービスは、車両が存在するリージョンに共存するアプリケーションの Kinesis Video Streams シグナリングチャネルをプロビジョニングするのに役立ちます。上記の例 (図 4) では、モバイルデバイスが東海岸または西海岸のどちらにあるかに関係なく、car-01 は us-west-2 にシグナリングチャネルが設定されます。同様に、car-02 は us-east-1 リージョンに設定されます。 プロダクション環境での学び (1 年間の振り返り) 1 年間の運用を経て、以下の重要な知見が得られました。 レイテンシ: WebRTC の選択は、HTTP Live Streaming (HLS) などの他のストリーミングプロトコルよりも低レイテンシストリーミングを実現するのに効果的でした。 複数の視聴者に対するスケーラビリティ: WebRTC のピア・ツー・ピア方式の主な設計上の課題は、各クライアントが一意の暗号化キーを使用した個別の SRTP/SRTCP ストリームを必要とすることです。つまり、2 番目のクライアントが同じ車両からストリームを要求した場合、新しいストリームを開始する必要があり、単一の車両ストリームを複数のピアで直接共有することが制限されます。現在の設計は、ライブ視聴用の 1 つのピア・ツー・ピア接続に最適化されており、シグナリングチャネルごとに最大 10 人の参加者がサポートされています。 コスト管理: 接続サービスを介したユーザー要求に応じたシグナリングチャネルのプロビジョニングと削除の最適化。これにより、機能を使用していないエンドユーザーにシグナリングチャネルが事前にプロビジョニングされることがなくなります。 課題と解決策: ネットワークインターフェースへのバインディング: AWS SDK for C ++ では、ソケット接続に特定のネットワークインターフェースをバインドすることができませんでしたが、Rivian のストリーミング APN はデフォルトのネットワークインターフェースとは異なるため、これは不可欠でした。しかし、SDK はオープンソースなので、Rivian はネットワークバインディングのパッチを作成し、ストリーミングインターフェースにバインドすることができました。 車両のウェイクアップ時間: スリープ中の車両がモバイルコマンドに応答し、ストリーミングを開始するまでの時間を最適化することが、重要なパフォーマンス要件でした。 機能強化と今後の計画 Rivian は、Gear Guard ライブカメラ機能を進化させ続け、次の機能強化を計画しています: ユーザーインターフェースの次世代アップデートには、接続の異なる段階でのユーザーの可視性の向上や、ストリーミング中の車両ネットワーク状況の可視化が含まれます。 適応ビットレートと ICE 再起動などの最適化により、セッション成功率 (この機能の最も重要な KPI) の向上を含め、成功したセッションを強化します。AWS WebRTC SDK はメディアチャネルの TWCC をサポートしており、これを適応ビットレート実装に使用できます。また、SDK は restartIce() をサポートしており、これを使って接続の切断/ネットワークの切り替え時に再接続する予定です。 結論 Rivian の Amazon Kinesis Video Streams を使用した Gear Guard ライブカメラの実装は、所有者のプライバシーを最優先にしながら (Rivian のインフラストラクチャや AWS クラウドにビデオ録画が保存されない)、車両のセキュリティ強化を支援するより高度なソリューションを示しています。WebRTC の低レイテンシと双方向通信機能、Kinesis Video Streams との密接な統合による堅牢なシグナリングと安全な資格情報管理を戦略的に活用することで、Rivian はパワフルなリアルタイムビデオストリーミング体験を実現しました。 Anirban Kundu Anirban Kundu は、Rivian および Volkswagen Technology Group において、データプラットフォーム部門の IoT およびストリーミングのディレクターを務めています。分散型コンピューティングとビッグデータ処理、特にデータ収集とストリーム処理に情熱を注いでいます。過去にはゲノム解析や三次分析、産業用インターネットなど、世界をより良くするという利他的な目標に向けた取り組みに携わってきました。 Adam Arsenault Adam Arsenault は、Rivian および Volkswagen Technology Group のプリンシパルソフトウェアエンジニアである。Rivian 車両と連携する iOS および Android モバイルアプリケーションのエンドツーエンドアーキテクチャと開発に注力している。25 年以上の経験を持つアダムは、顧客を魅了する階層化され信頼性が高くスケーラブルな分散アプリケーションの構築、およびデータとメトリクスを用いた情報に基づいた意思決定に尽力している。 Aditya Purohit Aditya Purohit は、Rivian および Volkswagen Technology Group のスタッフソフトウェアエンジニアであり、スケーラブルでインテリジェントなコネクテッドカーシステムの開発に注力している。組み込みソフトウェアとデータ処理の深い専門知識を活かし、車載コンピューティングとクラウドベースの知見を連携させ、より豊かでリアルタイムなコネクテッドカー機能を実現する取り組みを行っている。EV 技術とエッジ AI の進化に情熱を注ぐアディティアは、車両の知能性、効率性、プライバシー、安全性を高めるシステムの設計を楽しんでいる。仕事以外では、ハイキングやアウトドア探索、新しいスポーツに挑戦する時間を過ごしている。 Asif Khan Asif Khan は、Amazon Web Services のプリンシパルソリューションアーキテクトとして、自動車業界の企業顧客を支援している。自動車産業向けに革新的でコスト効率が高くスケーラブルなソリューションを設計・構築・提供することに情熱を注いでいる。仕事以外では、若手プロフェッショナルのメンタリングや、プロトタイプ構築を通じて新興技術トレンドを把握することを楽しんでいる。 Ajay Paknikar AWS のプリンシパルカスタマーソリューションマネージャーである Ajay Paknikar は、グローバルな自動車顧客をサポートしています。アジャイは、AWS の優れた機能を活用して成功したビジネス成果を確保し、企業の AWS 導入プロセスを導くことに情熱を注いでいます。クライアント経営陣への戦略的アドバイザーとして、クラウド導入とクラウド成熟度の向上に注力しています。 本記事は Senior Solutions Architect の 長谷川 仁志 が翻訳しました。

本記事は 2025 年 11 月 12 日 に公開された「 From 2D to 3D: Building a Scalable Human Mesh Recovery Pipeline with Amazon SageMaker AI 」を翻訳したものです。 コンピュータグラフィックスとアニメーションの絶えず進歩する分野において、動画データから現実的な 3D ヒューマンアニメーションを自動生成する技術は、デジタルコンテンツの作成方法を変革する可能性があります。没入型フィットネス体験から最先端の映画制作まで、正確で生き生きとしたデジタルヒューマン表現への需要はこれまでになく重要になっています。しかし、現実世界の人間の動きを詳細な 3D メッシュデータに変換するプロセスは、従来から時間がかかりリソース集約的な作業であり、多くの場合、専用ハードウェアと複雑なソフトウェアパイプラインが必要でした。 組織が高度なコンピュータビジョン技術の活用をますます求める中、堅牢な 3D ヒューマンデジタル化ソリューションへの需要は高まり続けています。この記事では、エンタープライズレベルの信頼性とパフォーマンスを維持しながら、大量の動画データを処理できるスケーラブルなヒューマンメッシュリカバリ (HMR) パイプラインをAWSで構築する取り組みについて説明します。 ヒューマンメッシュリカバリの概要 ヒューマンメッシュリカバリは、画像や動画などの視覚データから人体の 3D ポーズと形状を再構築することを目的とするコンピュータビジョン技術です。HMR は、 Skinned Multi-Person Linear (SMPL) などのパラメトリック人体モデルを使用してモデルパラメータを推定します。パラメトリック人体モデルは、ポーズと形状パラメータによって定義されるメッシュとして人体を表現します。 HMR の困難な性質のため、これは継続的な研究トピックであり、新しく革新的なアプローチが定期的に発表されています。HMR の主な課題の 1 つは、人体が他のオブジェクトによって遮蔽されている、異常なポーズをとっている、または最適な背景や照明条件を提供しない環境にある画像や動画から人間の形を正確に検出することです。もう 1 つの課題は、詳細な 3D メッシュの再構築が計算量が多く時間のかかるプロセスであることです。特に入力データのすべてのフレームに人間が含まれる動画の場合はなおさらです。データニーズの削減、効率の向上、入力データからの人間の識別は、HMR 研究の主要な焦点です。 最近の HMR の進歩により、実際の人物が他のオブジェクトや人々によって遮蔽されている場合でも、単一の画像や動画から正確なデジタル 3D ヒューマンを構築することが可能になりました。HMR 技術は、拡散モデルなどの新しい AI モデルを使用して動画内の将来の時点での人間のポーズと形状を計画し、時間を通じた人間の動きを予測する研究を進歩させました。これらの技術により、HMR は 3D ヒューマンアニメーションに適用可能になります。 スコアガイド付き HMR (ScoreHMR) の概要 私たちのソリューションの中核には、3D ヒューマンポーズと形状再構築への独自のアプローチである スコアガイド付きヒューマンメッシュリカバリ (ScoreHMR) があります。従来の最適化技術とは異なり、ScoreHMR は拡散モデルを使用して入力画像から人体パラメータをキャプチャし再構築します。この高度なアプローチにより、正確な単一フレームモデルフィッティング、カメラキャリブレーションなしのマルチビュー再構築、シームレスな動画シーケンス再構築が可能になります。ScoreHMR の主な利点は、画像データを効果的に活用することで困難なデータセットで強力なパフォーマンスを達成し、従来の最適化ベースのモデルフィッティング手法を上回ることです。拡散モデル技術により、以前の回帰ベース手法と比較して多様な人間のポーズの分布をキャプチャできます。 ScoreHMR はラトガース大学の研究グループによって発表されました。彼らの研究についての詳細は、 Score-Guided Diffusion for 3D Human Recovery という論文を参照してください。この投稿の著者と本文で議論される研究は、ラトガース大学や以前の研究者とは一切関係ありません。 AWS での ScoreHMR のスケーリング 人体の 3D 表現を抽出するために大量の動画データを処理することは、計算集約的なタスクであり、特にデータ量が増加するにつれて迅速にボトルネックになる可能性があります。ここで AWS が活躍し、要求の厳しいワークロードを処理するためのスケーラビリティとパワーを提供します。 このスケーラブルなヒューマンメッシュリカバリパイプラインは、 AWS Lambda 、 Amazon S3 、 Amazon SQS 、 Amazon SageMaker AI を含む複数の AWS サービスを活用するサーバーレスアーキテクチャとして設計されています。この強力な組み合わせにより、ソリューションは容易にスケールし、パフォーマンスや効率を損なうことなく任意の量の動画データを処理できます。 図 1 – 処理用の元動画 – フットボール選手 Amazon S3 は、パイプラインで処理する必要がある元動画データを保存するためのデータ取り込みソースとして使用されます。新しい動画ファイルが S3 バケットにアップロードされると、Amazon SQS へのイベント通知をトリガーして処理リクエストをキューに入れます。AWS Lambda 関数はパイプラインの複数の段階で使用されます: AWS Lambda 関数は Amazon SQS キューによってトリガーされ、Amazon S3 から動画データを前処理し、ScoreHMR モデルでの推論用に準備します。 この AWS Lambda 関数は、前処理されたデータで Amazon SageMaker AI 非同期エンドポイントを呼び出し、ScoreHMR モデルを使用して推論を実行します。 AWS Lambda 関数は、Amazon SageMaker AI からの成功/失敗通知を処理し、それに応じて Amazon DynamoDB のメタデータを更新するためにも使用されます。 Amazon SageMaker AI は ScoreHMR モデルを実行するためのインフラストラクチャをホストし管理します。モデルは非同期エンドポイントとしてデプロイされ、数分かかる可能性がある大きな動画ペイロードの処理を可能にします。Amazon SageMaker AI エンドポイントは受信リクエストをキューに入れ、トラフィックに基づいてコンピュートリソースを自動的にスケールします。 図 2 – 処理済み動画 – フットボール選手の 3D 再構築 非同期推論は Amazon SageMaker AI の機能で、受信リクエストをキューに入れて非同期で処理します。このオプションは、大きなペイロードサイズ (最大 1GB)、長い処理時間 (最大 1 時間)、準リアルタイムレイテンシ要件を持つリクエストに最適です。非同期推論により、処理するリクエストがない場合にエンドポイントインスタンス数をゼロに自動スケールしてコストを節約できるため、エンドポイントがリクエストを処理している時のみ料金を支払います。 現在、ScoreHMR と Amazon SageMaker AI は、1GB 以上、または 1 時間以上の長さの動画のような大きなペイロードを分割する機能を提供していません。この課題への対応として、マルチモーダル Amazon Nova 基盤モデルを使用した Amazon Bedrock Data Automation を使用して、入力ビデオのシーン変化を検出し、より小さな動画クリップに分割することができます。その後、 Amazon S3 Event Notifications などのイベント駆動アプローチを使用して SageMaker エンドポイントを呼び出すことができます。 図 3 – 3D レンダリング – フットボール選手の 3D 再構築 処理が完了すると、ScoreHMR モデルは、トラッキングされた人間の 3D メッシュ、ベクトルキーポイントデータ、トラッキングされたカメラポーズと方向、生成されたメッシュがオーバーレイされた動画ファイルなど、複数のファイルタイプを出力します。出力データは Amazon S3 バケットに保存され、SageMaker エンドポイントは Amazon SNS を使用してトピックを公開します。この場合、モデルの実行が成功すると Lambda 関数が呼び出され、DynamoDB テーブルのメタデータが出力データで更新されます。これにより、生成された 3D メッシュとキーポイントデータを任意の 3D アプリケーションで使用し、入力動画に映っている人間の動きを再現できるようになります。 ソリューション概要 図 4_AWS リファレンスアーキテクチャ スケーラブルなヒューマンメッシュリカバリパイプラインは、最先端の AI/ML 技術を活用して動画データから 3D ヒューマンポーズと形状を再構築します。このソリューションの中核では、3D ヒューマンメッシュリカバリにおける逆問題を解決するための最先端アプローチである Score-Guided Human Mesh Recovery (ScoreHMR) モデルを利用しています。AWS サーバーレスアーキテクチャ上に構築されたこのパイプラインは、AWS Lambda、Amazon S3、Amazon DynamoDB、Amazon SageMaker を含む様々な AWS サービスをシームレスに統合します。この強力な組み合わせにより、ソリューションは容易にスケールし、パフォーマンスや効率を損なうことなく任意の量の動画データを処理できます。 AWS Web Application Firewall (AWS WAF) は、アプリケーションを一般的な Web 攻撃やボットから保護し、可用性の低下、セキュリティ侵害、リソースの過剰消費を防ぎます。 Amazon Cognito は、ユーザーアクセス制御を追加し、サインインとサインアウトプロセスを処理します。サインインすると、ユーザーはバックエンドへのリクエストを行うことが承認されます。 Amazon API Gateway は、バックエンドアプリへのフロントドアとして機能するように設定されています。API は、データにアクセスするためのユーザーリクエストをルーティングします。 AWS Lambda は、リクエストパラメータに基づいてクエリをルーティングし、バックエンド操作を実行します。 Amazon S3 は、元動画と画像データを保存する取り込みデータソースとして使用されます。 新しいファイルが Amazon S3 にアップロードされると、イベント通知が Amazon SNS をトリガーして Lambda 呼び出しをキューに入れます。 Invoke SageMaker Endpoint Lambda 関数 がトリガーされ、Amazon SageMaker 非同期エンドポイントに推論リクエストを行います。 Amazon SageMaker AI は ScoreHMR モデルをホストし、非同期エンドポイントを使用して利用可能にします。SageMaker は AWS でこの AI モデルを実行するためのインフラストラクチャを管理します。 成功した場合、SageMaker エンドポイントは AWS Lambda を使用して成功メッセージを送信する Amazon SNS トピックを呼び出します。このシーケンスは、 モデル呼び出しの成功について Amazon DynamoDB のメタデータも更新します。 失敗した場合、SageMaker エンドポイントは AWS Lambda を使用してエラーメッセージを送信する Amazon SNS トピックを呼び出します。このシーケンスは、モデル呼び出しの失敗について Amazon DynamoDB のメタデータも更新します。 AWS Identity and Access Management (AWS IAM) は、AWS サービスとリソースへのアイデンティティ管理とアクセス制御を安全に行います。 Amazon CloudWatch は、リソースの監視、ログ記録、オブザーバビリティを提供します。 AWS X-Ray は、アプリケーション全体でトレースされたリクエストの全体像を提供します。 AWS サービスのスケーラビリティ、パフォーマンス、コスト効率性を活用することで、このスケーラブルなヒューマンメッシュリカバリパイプラインの実装は大規模な動画処理ワークロードを効率的に処理でき、正確な 3D ヒューマンメッシュリカバリを必要とする幅広いアプリケーションに適しています。 今後の可能性 画像や動画データから 3D ヒューマンを正確に生成する能力は、幅広い業界にわたって大きな可能性を秘めています。エンターテインメントとゲームにおいて、ヒューマンメッシュリカバリのスケーラブルなパイプラインは、ユーザー体験を向上させる現実的なヒューマンアニメーションの作成に使用できます。スポーツ分野では、このパイプラインは動きの詳細な 3D 表現を提供することで、コーチやトレーナーが改善すべき点を特定できるようにし、アスリートのトレーニングとパフォーマンス分析を大きく変える可能性があります。この技術は、トレーニング計画の最適化を支援し、アスリートのパフォーマンス向上と怪我の予防を実現します。応用範囲は、患者の動きの監視がリハビリテーションと遠隔ケアを支援できる医療などの領域にまでさらに広がります。 図 5 – 処理済み動画 – グループブレイクダンスの 3D 再構築 AWS クラウドサービスと ScoreHMR などの最先端 AI モデルの統合により、3D ヒューマンメッシュアニメーション用の堅牢な自動化ソリューションの作成が可能になります。最先端の AI 技術と AWS プラットフォームのスケーラビリティを融合した効率的なパイプラインにより、3D アニメーション制作の複雑なプロセスがよりアクセスしやすく効率的になります。この自動化パイプラインは、エンターテインメント、スポーツ、ファッションなど、人間の動作解析を必要とする多様な業界にとって非常に価値があることが証明できます。プロジェクトの範囲や複雑さに関係なく、ワークフローを最適化し、高品質でスケーラブルな結果を提供する可能性があります。 図 6 – 処理済み動画 – バスケットボール選手の 3D 再構築 独自の 3D ヒューマンメッシュアニメーションパイプラインを始める準備はできましたか？ Amazon SageMaker AI ドキュメント で非同期 AI ワークフローについて詳しく学び、 ScoreHMR リソース で今日からソリューションの構築を始めましょう！ 著者について Kellan Cartledge Kellan Cartledge は、AI/ML、生成 AI、クラウドインフラストラクチャ、リアルタイムグラフィックス、没入型 AR/VR 技術にわたる変革的ソリューションの設計と実装において 10 年以上の経験を持つ、AWS Prototyping and Cloud Engineering チームのシニアプロトタイピングアーキテクトです。Kellan は複雑な課題の解決と、新興技術で可能性の境界を押し広げるチームの支援に情熱を注いでいます。 翻訳はプロフェッショナルサービス小林知幾が担当しました。原文は こちら です。

本記事は 2025 年 4 月 1 日 に公開された「 Build an Immersive Virtual Reality Experience of Amazon Fulfillment Center Tour 」を翻訳したものです。 はじめに 倉庫効率、在庫計画、サプライチェーン管理の急速に進化する環境において、Amazon はフルフィルメントセンター (FC) モデルで革新を続けています。Amazon では、顧客の注文準備の背後にある人々、テクノロジー、プロセスを紹介するため、世界各地の選ばれた拠点で無料の対面およびバーチャルツアーを提供しています。Amazon Tour では、顧客がさまざまなタイプのロボットの動作を見て、それらがフルフィルメントプロセスをより効率的にする方法を説明できます。ロボットは、一緒に働く人々の歩く距離を短縮することで利益をもたらすだけでなく、より多くの在庫を保持し、注文をより迅速に処理できるようにすることで、顧客のショッピング体験も向上させます。従来のオンサイト FC ツアーは有益ですが、業界のパーソナライゼーション、リソースと対応能力の制約、スケーラビリティに制限があります。これらの課題に対処するため、私たちは Treedis と Matterport を使用した Amazon フルフィルメントセンターの没入型バーチャルリアリティ (VR) ツアーを展開し、24 時間 365 日の完全に没入型の体験を提供しています。主な目標は、最新の VR テクノロジーを活用して、FC のリアルで魅力的なバーチャルウォークスルーを顧客に提供することです。この技術ブログでは、プロジェクトの目的、ソリューションコンポーネント、および多様な業界の AWS 顧客が自社の運用に向けて没入型でインタラクティブな VR 体験を開発する手法について詳しく説明します。 目的 VR FC ツアープロジェクトには、Amazon がフィジカル AI と AWS サービスを使用して毎日数百万のパッケージを処理する方法を AWS のお客様に実証することを目的とした複数の観点の目標があります。このプロジェクトの包括的な目標は以下の通りです。 技術とプロセスの紹介 FC で使用される革新的なテクノロジーと AWS サービスを学べます。このバーチャルツアーは、Amazon が機械学習、コンピュータビジョン、ロボティクスを AWS サービスと統合して運用効率を達成する方法について、AWS 顧客に詳細な視点を提供します。 すべての AWS のお客様向けの Amazon FC ツアーのスケーリング AWS のお客様が Amazon FC の運用プロセスを理解できる、没入型でインタラクティブ、カスタマイズ可能なバーチャル環境を開発します。このバーチャル環境は、ユーザーを FC 運用の中心へと導き、複雑なプロセスとテクノロジーを直接体験できるようにします。FC ツアー体験をスケーリングすることで、多様な業界の AWS 顧客が自社の運用に対する貴重な洞察とインスピレーションを得ることができます。 新たなアイデアの創出 強化されたインタラクティブディスプレイ、業界固有のオーバーレイ、パーソナライズされたナレーションなどのソリューションの主要要素は、顧客に運用哲学、持続可能性イニシアチブ、Amazon FC の全体的な効果についてより深い理解を提供します。さらに、この没入型体験は顧客の間で新しいアイデアの生成を促進し、AWS サービスを使用して独自のビジネスニーズに合わせた予知保全、作業者トレーニングと安全ソリューション、倉庫自動化を構築するよう彼らにインスピレーションを与えます。 これらの目標を達成することで、VR FC ツアープロジェクトは Amazon の運用力を紹介し、AWS 顧客が自社の運用を再構想できるよう支援します。この革新的なアプローチは、AWS と物理 AI テクノロジーの力を活用した最先端ソリューションのコラボレーション、知識共有、探索を促進します。 ソリューション概要 このプロジェクトの構築において、私たちは AWS、Matterport、Treedis のテクノロジーを統合して、Amazon FC ツアーのエンドツーエンドの没入型バーチャルリアリティ体験を提供しました。以下では、各アーキテクチャコンポーネントについて詳しく説明します。 Amazon FC ツアー VR 体験のアーキテクチャ図 没入型体験の構築 没入型 VR FC ツアー体験を作成するため、私たちは Treedis ノーコードプラットフォームを活用し、カスタムブランドのデジタルツイン、ハイブリッド体験を作成し、バーチャル環境を簡単にナビゲートできるようにしました。コーディングの必要なく、ユーザーフレンドリーなソリューションを活用して、独自のバーチャル体験を構築しました。Treedis の高度なワークフロークリエーター「Flows」は、フルフィルメントセンターをステップバイステップのオンボーディングプロセスに変換し、ユーザーがガイド付きトレーニングフローを簡単に設計し、自分の裁量で特定の経路を探索できるようにしました。これにより、開発者以外でも重要な知識と専門知識を体験に貢献できるようになりました。 もう一つのノーコードソリューションである Digital Twin Studio により、私たちは FC 施設のデジタルツインモデルをシームレスな柔軟性でカスタマイズおよびレンダリングできました。 ナビゲーションタグ 機能は非常に重要で、ツアー内の特定の場所への経路を表示するバーチャルバブルを通じて自動ユーザーガイダンスを可能にしました。没入型体験をさらに向上させるため、私たちは 3D Editor を使用して、ビデオやワークフロー画像などの顧客メディアを組み込み、パッケージやロボットなどの 3D アセットを配置して FC 運用を実演しました。さらに、私たちはグリーンスクリーン機能を使用して、FC 運用の各段階をナレーションする実際の人物を統合し、バーチャル体験に本物のタッチを追加しました。 Treedis はまた、デジタルデバイスと VR デバイスの両方にすべての拡張機能を適用するパイプラインを構築し、将来の使用に向けて AR 対応を利用可能にして、あらゆるプラットフォームでシームレスで没入型の体験を保証しています。Treedis の強力なツールにより、私たちはデジタル世界と物理世界を融合し、施設の内部動作を詳しく見ることができる、非常にユニークで有益な VR FC ツアー体験を作成しました。Treedis サービスとサブスクリプションの詳細については、 AWS Marketplace をご覧ください。 3D モデリングとシミュレーション Amazon FC 施設の没入型で正確な表現を作成するため、私たちは Matterport の SaaS、3D カメラ、プロフェッショナルキャプチャーサービスの強力な機能を活用しました。これらのツールにより、物理空間をナビゲート可能で写実的、寸法的に正確なデジタルレプリカに変換できました。完全マネージド型ソリューションである Matterport Capture Services により、私たちは FC 施設の実物そっくりのデジタルツインを簡単にキャプチャできました。その後、これらのデジタルツインを Matterport の 3D データプラットフォームでホストし、SaaS ソリューションを利用してシームレスなアクセスと統合を保証しました。 Matterport API を活用して、私たちは Treedis システムをプログラムで接続し、Matterport プラットフォームでホストされている FC モデルへの直接アクセスを可能にしました。この統合により、高度に詳細で正確なデジタルレプリカを VR 体験に組み込むことができ、没入感と臨場感を向上させ、顧客の時間を節約し、約 1 マイルの歩行を不要にしました。Matterport のサービスとサブスクリプションオプションをさらに詳しく知りたい方は、直接お問い合わせいただくか、包括的な情報と価格詳細を見つけることができる AWS Marketplace をご覧ください。 アプリケーションホスティングとアクセス Amazon FC VR ツアーを探索するユーザーにシームレスでアクセス可能な体験を提供するため、私たちは React ベースのウェブサイトのホスティングに AWS Amplify を活用しています。アプリケーションは、バーチャル体験にアクセスするための VR とデスクトップブラウザ間の相互運用性体験を提供します。大規模な安全なアクセスとユーザー管理を提供するため、私たちはアプリケーションを顧客 ID とアクセス管理のための堅牢なソリューションである Amazon Cognito と統合しました。 生成 AI 統合 インタラクティブな VR 体験を作成するため、私たちはリモートコラボレーションと知識共有のために Amazon Bedrock を統合し、Treedis の VR 機能を追加で使用しました。バーチャル環境の Q&A ボットにより、顧客は FC プロセスに慣れ親しむことができます。Amazon Bedrock を搭載した Q&A ボットは、一般的な質問と詳細なプロセス情報の包括的なリポジトリでトレーニングされました。このトレーニングにより、ユーザーは自然言語を使用して質問でき、直感的で会話的な体験を保証します。このアプローチを通じて、私たちは没入型バーチャルツアーを提供するだけでなく、リアルタイムの知識共有とコラボレーションも促進しました。顧客はバーチャル FC 環境を探索しながら、同時に Q&A ボットと関わり、貴重な洞察を得て、その場で疑問を解決できました。 エンドユーザー体験 新規または既存の AWS 顧客、潜在的なパートナー、または物流の専門家を目指す方であっても、Amazon FC Tour VR 体験は FC 運用を変革するための印象的な洞察を得ることができ、大規模なフルフィルメントセンターを効率的に運営するための AWS サービスとフィジカル AI の役割を学ぶのに役立ちます。VR デバイスまたはワークステーションを使用して、施設運用のための複雑なプロセスとテクノロジーを明らかにできます。 Amazon FC ツアー VR 体験のエンドユーザー体験 まとめ Amazon フルフィルメントセンターバーチャルリアリティ体験プロジェクトは、顧客と組織が AWS とフィジカル AI を活用して倉庫効率を高めるための重要な一歩を表しています。この画期的な体験は re:Invent 2024 New to AWS Expo ブースで開始され、Treedis と Matterport も発表に参加し、顧客の関心を集め、さまざまな分野で同様のソリューションを活用する革新的なアイデアを生み出しました。作業者トレーニングソリューションの合理化とシームレスなサイト運用から、工場計画プロセス、予知保全、不動産マーケティングの加速まで、このテクノロジーの潜在的な応用は広大で広範囲に及びます。参加者からの圧倒的にポジティブな反応は、この VR 体験が業界全体で持つ変革的な影響を強調しました。Amazon フルフィルメントセンターのこの VR ツアーを直接体験することに興味がある場合は、 Experience Amazon Fulfillment Center (FC) Virtual Reality Experience リンクからお問い合わせください。特定の業界ニーズに合わせたカスタマイズされたソリューションを開発したい場合は、AWS Marketplace で Treedis と Matterport をご確認ください。 著者について Abhishek Srivastav Abhishek Srivastav は AWS のシニアソリューションアーキテクトです。顧客のクラウド導入加速を支援することに情熱を注いでいます。IoT 愛好家であり、NoSQL データベース、アナリティクス、AI/ML テクノロジーに深い専門知識を持っています。これらのテクノロジーの深い理解を活用して複雑な問題の答えを見つけることに情熱を注いでいます。AWS 入社前は、さまざまなエンタープライズ顧客で NoSQL Center of Excellence の主導的な役割を担っていました。 Johanna Albarran Johanna Albarran は Amazon Web Services のソリューションアーキテクトです。AWS での生成 AI と機械学習の活用において顧客をサポートすることに情熱を注いでいます。クラウドネイティブアーキテクチャの専門知識により、企業の規模拡大と運用の効率的な変革を支援する革新的なソリューションを設計できます。Johanna は San Diego State University で経営情報システム学の学士号を取得し、現在 Virginia Polytechnic Institute and State University (Virginia Tech) で情報技術の修士号を取得中です。 Gabriele Biagini Gabriele Biagini は Amazon Web Services のソリューションアーキテクトです。サーバーレステクノロジーと生成 AI を専門とし、革新的なイベント駆動アーキテクチャとクラウドネイティブソリューションを通じて組織のクラウド導入プロセスを加速することを支援しています。技術コミュニティへの積極的な貢献者として、実装パターンを定期的に共有し、技術カンファレンスで講演しています。AWS 入社前は、さまざまなテクノロジー企業でクラウドエンジニアリングチームを率いていました。 翻訳はプロフェッショナルサービス小林知幾が担当しました。原文は こちら です。

2025 年 12 月 2 日、Google、Moonshot AI、MiniMax AI、 Mistral AI 、NVIDIA、 OpenAI 、 Qwen のフルマネージドオープンウェイトモデルが Amazon Bedrock でさらに18種類の一般販売されることを発表しました。これには、新しい Mistral Large 3 および Mistral 3 の3B、8B、14B モデルが含まれます。 今回の発表により、Amazon Bedrock は 100 近くのサーバーレスモデルを提供し、主要な AI 企業による幅広く幅広いモデルを提供するようになりました。これにより、お客様は独自のニーズに最適な機能を正確に選択できます。AWS は、お客様のニーズと技術の進歩の両方を注意深くモニタリングすることで、お客様のニーズと技術進化に基づいて 厳選されたモデルのセレクション を定期的に拡大し、業界で定評のあるモデルに加えて、有望な新しいモデルも含めるようにしています。 この高性能で差別化されたモデルオファリングのこの継続的な拡大は、お客様が AI イノベーションの最前線に留まるのに役立ちます。Amazon Bedrock のこれらのモデルには、統合 API を通じてアクセスでき、アプリケーションを書き換えたり、インフラストラクチャを変更したりすることなく、新しいモデルを評価、切り替え、採用できます。 新しい Mistral AI モデル Amazon Bedrock では現在、次の 4 つの Mistral AI モデルがまず利用可能です。それぞれ異なるパフォーマンスとコスト要件に合わせて最適化されています: Mistral Large 3 — このオープンウェイトモデルは、ロングコンテキスト、マルチモーダル、および命令の信頼性を考慮して最適化されています。長い文書理解、エージェントとツールの使用ワークフロー、エンタープライズナレッジワーク、コーディング支援、数学やコーディングタスクなどの高度なワークロード、多言語分析と処理、ビジョンを備えたマルチモーダル推論に優れています。 Ministral 3 3B — Ministral 3 ファミリーの中で最小の製品で、強力な言語機能とビジョン機能を備え、シングル GPU デプロイ向けにエッジ最適化されています。画像キャプション、テキスト分類、リアルタイム翻訳、データ抽出、ショートコンテンツ生成、およびエッジデバイスや低リソースデバイスでの軽量リアルタイムアプリケーションにおいて優れたパフォーマンスを発揮します。 Ministral 3 8B — テキストとビジョン向けのクラス最高の Ministral 3 モデルは、シングル GPU デプロイ向けにエッジ最適化されており、高性能で設置面積が最小限に抑えられています。このモデルは、制約のある環境でのチャットインターフェイス、画像や文書の記述と理解、特化したエージェントのユースケース、ローカルシステムや組み込みシステムのバランスの取れたパフォーマンスに最適です。 Ministral 3 14B — 最も高性能な Ministral 3 モデルは、シングル GPU デプロイ用に最適化された最先端のテキストおよびビジョンパフォーマンスを提供します。高度な機能がハードウェアの実際の制約を満たしている場合には、高度なローカルエージェンシーのユースケースやプライベート AI のデプロイを使用できます。 その他のオープンウェイトモデルオプション これらのオープンウェイトモデルは、さまざまな業界の幅広いユースケースに使用できます。 モデルプロバイダー モデル名 内容 ユースケース Google Gemma 3 4B ラップトップ上でローカルに実行される効率的なテキストおよび画像モデル。デバイス上の AI アプリケーションの多言語サポート。 モバイルおよびエッジアプリケーション向けのオンデバイス AI、プライバシーに配慮したローカル推論、多言語チャットアシスタント、画像のキャプションと説明、軽量コンテンツ生成。 Gemma 3 12B ワークステーション用のバランスの取れたテキストと画像モデル。多言語を理解し、プライバシーに敏感なアプリケーションをローカルにデプロイできます。 ワークステーションベースの AI アプリケーション、企業向けのローカルデプロイ、多言語文書処理、画像分析、Q&A、プライバシーに準拠した AI アシスタント。 Gemma 3 27B エンタープライズアプリケーション向けの強力なテキストおよび画像モデル。多言語サポートによるローカルデプロイメントによるプライバシーと制御 エンタープライズローカルデプロイ、高性能マルチモーダルアプリケーション、高度な画像理解、多言語カスタマーサービス、データセンシティブ AI ワークフロー。 Moonshot AI Kimi K2 Thinking ツールを使いながら考える深層推論モデル。リサーチ、コーディング、および何百ものシーケンシャルアクションを必要とする複雑なワークフローを処理します。 計画、多段階ワークフロー、データ分析と計算、リサーチを伴う長文コンテンツの作成を必要とする複雑なコーディングプロジェクト。 MiniMax AI MiniMax M2 コーディングエージェントと自動化向けに構築されています。複数ファイルの編集、ターミナル操作、長いツール呼び出しチェーンの効率的な実行に優れています。 コーディングエージェントと統合開発環境 (IDE) の統合、マルチファイルコード編集、ターミナルオートメーションと DevOps、ロングチェーンツールオーケストレーション、エージェンティックソフトウェア開発。 Mistral AI Magistral Small 1.2 数学、コーディング、多言語タスク、マルチモーダル推論に優れ、効率的なローカルデプロイのためのビジョン機能を備えています。 数学とコーディングのタスク、多言語の分析と処理、そしてビジョンを備えたマルチモーダル推論。 Voxtral Mini 1.0 トランスクリプション、多言語サポート、Q&A、要約、関数呼び出しを備えた高度な音声理解モデル。 音声制御アプリケーション、高速音声テキスト変換、オフライン音声アシスタント。 Voxtral Small 1.0 クラス最高のテキストパフォーマンスを備えた最先端のオーディオ入力を搭載し、音声の書き起こし、翻訳、理解に優れています。 企業向け音声文字起こし、多言語カスタマーサービス、音声コンテンツ要約。 NVIDIA NVIDIA Nemotron Nano 2 9B ハイブリッドトランスフォーマー Mamba 設計の高効率 LLM は、推論とエージェントタスクに優れています。 推論、ツール呼び出し、数学、コーディング、指示の順守。 NVIDIA Nemotron Nano 2 VL 12B ビデオ理解とドキュメントインテリジェンスのための高度なマルチモーダル推論モデルで、検索拡張生成 (RAG) およびマルチモーダルエージェンティックアプリケーションを強化します。 複数の画像や動画の理解、視覚的な Q&A、要約。 OpenAI gpt-oss-safeguard-20b カスタムポリシーを適用するコンテンツ安全モデル。有害なコンテンツを、信頼と安全のワークフローを説明して分類します。 コンテンツモデレーションと安全性の分類、カスタムポリシーの適用、ユーザー生成コンテンツのフィルタリング、信頼と安全のワークフロー、および自動コンテンツトリアージを行います。 gpt-oss-safeguard-120b 複雑なモデレーションのための大規模コンテンツ安全性モデル。企業の信頼および安全性チームに詳細な理由を記載したカスタムポリシーを適用します。 大規模なエンタープライズコンテンツモデレーション、複雑なポリシーの解釈、多層的な安全性分類、規制遵守チェック、ハイステークスコンテンツレビュー。 Qwen Qwen3-Next-80B-A3B 超長文書向けのハイブリッドアテンションによる高速推論。RAG パイプライン、ツール使用、エージェンティックワークフローに最適化されており、迅速な対応が可能です。 長いドキュメントを含む RAG パイプライン、ツール呼び出しを伴うエージェンティックワークフロー、コード生成とソフトウェア開発、拡張コンテキストでのマルチターンの会話、多言語コンテンツ生成。 Qwen3-VL-235B-A22B 画像や動画を理解します。ドキュメントからテキストを抽出し、スクリーンショットを作業コードに変換し、インターフェイスのクリックを自動化します。 画像や PDF からのテキストの抽出、UI デザインやスクリーンショットの作業コードへの変換、アプリケーションでのクリックやナビゲーションの自動化、動画の分析と理解、チャートや図の読み込み。 公開されているモデルを実装する場合は、本番稼働環境でデータプライバシー要件を慎重に考慮し、出力のバイアスがないか確認して、データセキュリティ、 責任ある AI 、 モデル評価 の観点から結果をモニタリングしてください。 Amazon Bedrock の エンタープライズグレードのセキュリティ機能 にアクセスし、 Amazon Bedrock のガードレール を使用して、アプリケーション要件と責任ある AI ポリシーに合わせてカスタマイズされた安全策を実装できます。また、 Amazon Bedrock モデル評価ツール を使用してモデルを評価および比較し、ユースケースに最適なモデルを特定することもできます。 開始するには、 Amazon Bedrock コンソール のプレイグラウンドでいくつかのプロンプトを入力するだけで、これらのモデルをすばやくテストできます。また、任意の AWS SDK を使用して Bedrock InvokeModel および Converse API へのアクセスを組み込むこともできます。また、これらのモデルは、Amazon Bedrock をサポートする任意のエージェンティックフレームワークで使用でき、 Amazon Bedrock AgentCore と Strands Agents を利用してエージェントをデプロイできます。詳細については、「Amazon Bedrock ユーザーガイド」の「 AWS SDK を使用する Amazon Bedrock のコード例 」を参照してください。 今すぐご利用いただけます 新しいモデルの提供状況や今後の更新については、 全リージョンリスト を確認するか、 AWS Capabilities by Region の [AWS CloudFormation] リソースタブでモデル名を検索してください。詳細については、 Amazon Bedrock 製品ページ と、 Amazon Bedrock の料金ページ を参照してください。 Amazon Bedrock コンソール でこれらのモデルを今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

本ブログは 2025 年 2月 21 日に公開された AWS Public Sector ブログ「 NATO’s march to multi-domain operations: Transforming the alliance with hyperscale cloud 」を翻訳したものです。 脅威は今日も急速に進化し続けています。この状況に対抗するために、高度なテクノロジーソリューションを絶えず近代化することは NATO の 32 の加盟国すべてにとって急務となっており、同盟のデジタルトランスフォーメーションの戦略的重要性は 強まっています 。この近代化の取り組みには、優位性を維持するためのスピード、規模、セキュリティ、そしてグローバルなイノベーション能力が必要です。Amazon Web Services (AWS) のようなテクノロジーリーダーと協力することで、イノベーションを加速し、既知の脅威や新たな脅威に対抗するためのミッション対応ソリューションを提供する NATO の能力を高めることができます。 NATO のデジタルトランスフォーメーション実施戦略 は、同盟国同士が高度に接続されたクラウドベースのインフラストラクチャへと移行する方法を概説しています。2030 年までに、NATO は相互運用性、リアルタイム分析、データドリブンな意思決定を備えたマルチドメインオペレーション (MDO) 対応の同盟関係を構想しています。この変革は、脅威の軽減、意思決定の強化、 セキュアかつアジャイルで即応性に優れた同盟の維持 に寄与します。 物理的環境とサイバースペースの両方にわたって MDO を実施し、敵対勢力に対する技術的優位性を維持する NATO の能力には、ハイパースケールクラウドコンピューティングが必要です。この複雑な状況で成功するには、膨大な量のデータを管理し、分析を適用し、迅速に意思決定を行うための、高度な人工知能 (AI) と機械学習 (ML) テクノロジーが不可欠です。 次世代の防衛 地政学的状況の変化を背景に、NATO 加盟国間の足並みを揃えることがこれまで以上に重要になっています。情報システムと、それらに関連するすべての標準とポリシーは、あらゆる環境、あらゆる機密区分において、常に相互運用可能で安全でなければなりません。そして、予測不可能な需要に対応するために柔軟にスケールできるインフラストラクチャによって支えられている必要があります。 政府機関のお客様から信頼をいただいているクラウドである AWS は、政府機関向けに最も包括的で、信頼性が高く、安全で、目的に特化したクラウド機能を提供しています。当社のコアインフラストラクチャは、軍、情報機関、民間機関、そして NATO のような高度な機密性を持つ組織のミッションの達成と厳格な要件の充足を支援するために構築されています。現在、AWS は、世界で 7,500 を超える政府機関における最重要ミッションの遂行、レガシー IT のモダナイズ、変革の加速、市民向けサービス提供の革新を支えています。 NATO の目標達成を支える AWS は、AI、ML、分析、シミュレーションなどの高度なクラウド機能を費用対効果の高い方法で使用することにより、NATO の最も差し迫った課題に対処するソリューションを構築しています。例えば、AWS と選定されたパートナーは、 NATO Edge Conference でシニアリーダーと会談し、NATO のデジタルトランスフォーメーションを支援し、適切なスピードでのデータドリブンな意思決定を可能にする最新のイノベーションとテクノロジーを紹介しました。 当社は、ハイパースケールクラウドが組織のミッション成功の実現にどのように役立つかをより深く理解するために、NATO と積極的に連携しています。過去 1 年間、AWS はヨーロッパで 3 つの戦略的イベントを共催し、NATO が新興テクノロジーを活用して同盟の能力を強化する際に抱く期待と直面する課題について、直接話を聞きました。Aspen Strategy Group、 Concordia 、 Atlantic Council とのこれらのイベントは、NATO のミッションとクラウド要件、そして AWS がそれらの達成をどのように支援できるかを議論するプラットフォームを提供しました。 NATO のための高度なクラウド機能 AWS は NATO と連携し、そのデジタルトランスフォーメーション目標を推進するクラウド機能を提供すると同時に、欧州の防衛関連企業やイノベーターによる同盟向けの能力近代化を支援しています。防衛分野での豊富な経験を持つ主要なクラウドプロバイダーとして、AWS は NATO がレジリエンシー、セキュリティ、相互運用性、強化されたコラボレーションの要件を満たすことを支援することに尽力しています。これらの機能は、NATO の 変革戦略 と直接的に整合しています。 回復性（レジリエンシー）: 同盟国は、ハードウェア障害、自然災害、サイバー攻撃、その他の中断に直面した場合でも、ミッションシステムとデータが常にアクセス可能で運用可能であることを確保する必要があります。AWS は、すべてのクラウドプロバイダーの中で最高のネットワーク可用性を提供し、すべてのリージョンで 3 つ以上のアベイラビリティーゾーン (AZ) を提供する唯一のクラウドプロバイダーであり、より高い冗長性と問題を封じ込めるためのより優れた分離を実現しています。 セキュリティ: AWS クラウドは、同盟国がスピードと自信を持って運用できるようにする実証済みのセキュリティ機能を提供します。最も安全なクラウドコンピューティング環境となるように設計されたインフラストラクチャを通じて、同盟国は重要な資産に対する堅牢な保護を獲得します。セキュリティの自動化により、人的エラーが削減され、防御の有効性が最大化されます。また、組み込みのセキュリティコントロールとガイダンスにより、同盟国は包括的なエンドツーエンドの保護対策を実装できます。これらの機能は、機密データとシステムの保護を支援し、より安全なミッション機能の迅速な展開を可能にします。 相互運用性: AWS クラウドは、標準化されたインターフェイスと共通のプラットフォームを通じて NATO 加盟国間のシームレスな通信を可能にし、同盟国間の情報共有と運用統合を合理化します。 強化されたコラボレーション: クラウドベースのプラットフォームは、NATO 加盟国間での共同計画と MDO を可能にし、より迅速で協調的な同盟国の対応を促進する安全な脅威インテリジェンス共有を実現します。共有データリポジトリと通信プラットフォームにより、同盟国は同じリアルタイム情報にアクセスでき、新たな脅威への対応における意思決定を加速できます。 ミッションスピードでの前進 AWS は、国家安全保障と防衛のお客様への支援において揺るぎない姿勢を持ち、安全でミッションクリティカルな運用を支える実証済みの機能を提供しています。今日の変化する安全保障環境において、NATO のデジタルトランスフォーメーションは、集団的抑止と防衛を通じてグローバルな安定性を維持するために不可欠です。AWS は、ミッション成功のためのイノベーションを支援し、NATO のデジタルトランスフォーメーションを加速する準備ができています。 関連情報 Trusted Secure Enclaves on AWS で国家安全保障と防衛任務のデータを保護する方法 AWS 活用で実現する同盟国間の防衛機密情報と技術共有 IdentityE2E Seamless Migration of NATO School Oberammergau (NSO) Website to AWS LZA Platform NATO’s Deputy Secretary General visits Amazon’s Development Centre in Iași, Romania 執筆協力: Chris Bailey, GM, global national security and defense, AWS Worldwide Public Sector 著者について David Appel David Appel は、AWS のグローバル政府、国家安全保障、防衛ビジネスを統括しています。彼とそのチームは、お客様がテクノロジーの可能性を実現し、組織を変革してミッションを達成できるよう支援しています。この役割において、彼はお客様のクラウド導入の取り組みに伴走し、最先端のテクノロジーを活用することで、エンドユーザーに効率性と迅速性をもたらす能力向上を実現します。David は、プログラムリーダーシップ、ビジネスオペレーション、財務、ビジネス開発、戦略的計画において幅広い経験を持っています。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。

本記事は、” Achieve a high-speed InnoDB purge on Amazon RDS for MySQL and Amazon Aurora MySQL ”  を翻訳したものです。 パージ は、MySQL データベースにおけるハウスキーピング操作です。InnoDB ストレージエンジンは、 マルチバージョン同時実行制御 (MVCC) やロールバック操作のために不要となった、 undo ログ や削除マークの付いたテーブルレコードのクリーンアップを、この操作に依存しています。私たちのアプリケーションは、元より最高の書き込みスループットを提供することを目的としたデータベース設計を追求していますが、同様にパージがバックグラウンドでタイムリーに実行できることを確認することも重要です。大量のデータ変更とパージの進行のバランスが崩れると、データベースのパフォーマンスが低下する可能性があります。 この投稿では、 Amazon Relational Database Service (Amazon RDS) for MySQL DB インスタンス、及び Amazon Aurora MySQL 互換エディション DB クラスターにおける、高速なパージのための一連の設計およびチューニング戦略の概要を説明します。まず、MySQL データベースの内部構造について私たちの理解を活用して、パージの仕組みを簡単に紹介します。次に、パージの課題となる一般的な要因と、使用できる最適化手法について説明します。この記事は MySQL 8.0 に基づいており、ほとんどの推奨事項は一般的な MySQL データベースに適用可能です。また、Amazon マネージドデータベースサービスに特有の考慮事項も示します。 パージの仕組みを理解する 他の多くの主流のリレーショナルデータベース管理システム (RDBMS) と同様に、MySQL は MVCC を実装して、データにアクセスするための読み取りと書き込みの同時操作を可能にしています。MVCC の核となる考え方は、トランザクションによってテーブルレコードが更新されたときに、データベースエンジンにテーブル内の新しいバージョンのデータを作成させることです。古いデータのバージョンは物理的には削除されず、削除済みとマークされます。クエリは望ましい分離レベルで、適切なデータバージョンを選択してデータベースの独自のビューを構築できます。そうすることの大きな利点は、読み取りと書き込み間でのブロッキングが発生する状況を回避することです。読み取りは常に古いデータバージョンにアクセスできますが、書き込みは新しいバージョンで実行されます。テーブルレコードの複数のバージョンを保持できるので、データベースエンジンがトランザクション内またはクラッシュリカバリ中にロールバック操作を実行することも容易になります。 スケーラブルなソリューションとして、MVCC には固有の制約があります。削除マークが付いたテーブルレコードはガベージコレクションにより処理される必要があるということです。さまざまなデータベースエンジンに、独自のバージョントラッキングとガベージコレクションメカニズムが備わっています。一般的な課題は、大量のトランザクションにより古いデータバージョンが速く生成され過ぎ、ガベージコレクションが追いつけない場合です。その結果、テーブル構造に古いデータバージョンが大量のバックログとして蓄積されることがあります。表面的には、これはスペース使用量の予想外の増加を直接引き起こします。その裏で、古いバージョンをチェックして読み取り操作を実行するには、追加の I/O 操作を行う必要があります。この I/O 消費量の増加は、システムリソースを奪い合い、データベース全体のパフォーマンスを低下させる可能性があります。 MySQL データベースでは、InnoDB は MVCC とロールバック操作をサポートするための主要なデータ構造として undo ログを使用します。テーブルレコードが変更されると、古いデータバージョンは undo ログに保存されます。同じテーブルレコードに関連するすべての undo ログはリンクされ、バージョンチェーンを形成します。その裏返しとして、パージはガベージコレクションのことです。undo ログだけでなく、それらが参照する削除マークの付いたテーブルレコードもクリーンアップします。本質的に、パージは InnoDB トランザクションシステムの不可欠な部分と見なされます。 次のグラフは、InnoDB パージの高レベルの設計アイデアと 3 段階のワークフローを示しています。 トランザクションが開始されると、 ロールバックセグメント が割り当てられます。ロールバックセグメントは、 undo テーブルスペース 内の多数の undo ログページで構成されます。テーブルレコードが保存されるデータページのように、undo ログページを読み書きするには InnoDB バッファプールにロードする必要があります。 トランザクションによってテーブルデータが変更されると、undo ログレコードが作成されます。undo ログレコードには、テーブル ID、クラスタ化インデックス、変更前の古いデータバージョンなど、テーブルレコードに行われた変更をロールバックするために必要な関連情報が含まれています。INSERT、DELETE、UPDATEステートメント用に、異なる種類の undo ログレコードがあります。後でパージする必要があるかどうかに応じて、それらは別々の undo ログにグループ化されます。 コミット中、トランザクションはトランザクションシリアル番号 (trx_no) を取得し、それを undo ログに書き込みます。パージする必要のある undo ログが存在する場合、それらは trx_no 順に並べられた ロールバックセグメント履歴リスト に追加されます。InnoDB トランザクションシステムは trx_no を使用して、コミットされたすべてのトランザクションの順序を追跡します。その意味では、履歴リストはデータベース全体でグローバルなリストです。 パージはマルチスレッド操作です。パージスレッドの数は、 innodb_purge_threads を使用して設定されます。通常、1 つのパージコーディネーターといくつかのワーカースレッドが存在します。これらのスレッドは、3 つのステップを含むパージ操作を継続的に繰り返します。 パージコーディネータースレッドは、パージできる undo ログがあるかどうかをチェックします。そのような undo ログが見つかったらひとまとめに取り出し、undo レコードを解析して、テーブル ID でソートします。次に、処理を行うため各グループをワーカースレッドに割り当てます。 パージワーカースレッドは、undo ログレコードをテーブル ID ごとに並行して処理します。undo ログレコード中の情報を使用して、クラスタ化インデックス、セカンダリインデックス、BLOB 列など、削除マークの付いたレコードを識別して削除します。クリーンアップ後にデータページ内のデータが少なすぎる場合は、ストレージを最適化するために別のページにマージされます。 いくつかの undo ログのまとまった単位が処理された後、パージコーディネータスレッドはそれらをロールバックセグメント履歴リストから削除して、ロールバックセグメントを解放します。MySQLには、undo テーブルスペースを自動的に切り捨てる innodb_undo_log_truncate というオプションが用意されています。これは、undo テーブルスペースが innodb_max_undo_log_size で指定されたサイズ制限を超え、内部に含まれるすべてのロールバックセグメントが解放されたときに、物理ストレージスペースを縮小するためのものです。このステップが完了すると、パージコーディネータースレッドは別のパージサイクルを開始します。 undo テーブルスペースの自動切り捨てオプションは、Aurora MySQL 互換 バージョン 3.06.0 以降で使用できます。 読み取りと書き込みのワークロードのバランスを取る トランザクションがレコードを変更するために INSERT、DELETE、UPDATEなどのデータ操作言語 (DML) ステートメントを使用するとき、InnoDB は異なる種類の undo ログレコードを作成します。ただし、すべての種類の undo ログレコードをパージする必要はありません。INSERT ステートメントにより生成された undo ログには古いデータバージョンが含まれていないため、トランザクションがコミットされた直後に削除され、ロールバックセグメント履歴リストには追加されません。 DELETE 及び UPDATE ステートメントによって生成された undo ログレコードには、テーブルレコードが削除または更新される前の古いデータバージョンが保存されているため、パージ操作の対象となります。他の並行した SELECT クエリやオープントランザクションは、MVCC の目的で 一貫した読み取り を構築するために、それらにアクセスする必要があるかもしれません。InnoDB は、アクティブなクエリとトランザクションのために undo ログの可視性を追跡するメカニズムとして、 読み取りビュー を使用しています。また、パージコーディネータースレッドが undo ログを安全に削除できるかどうかを判断するためにも使用されます。 undo ログの作成と使用の両方を行うデータベースワークロードは、パージスレッドの動作に直接影響します。undo ログは、ロールバックセグメント履歴リストから trx_no の昇順で削除されます。undo ログをパージできない場合、trx_no が大きい他の undo ログは、別のテーブルに属していてもパージされなくなります。つまり、パージはデータベース全体でグローバルな操作であり、1 つの長時間実行されたクエリまたはトランザクションにより、それより後に開始された全てのトランザクションの undo レコードのクリーンアップがブロックされます。パージが常に懸念事項となる MySQL データベースでは、データベースワークロードのタイミング、同時実行性、およびトランザクション特性を確認することをお勧めします。 1つの戦略は、DELETE よりも DROP PARTITION または DROP TABLE ステートメントを選択することです。これらのステートメントは undo ログを生成しないからです。次の図に示すように、DROP PARTITION を使用してデータのサブセットを削除できるようにテーブルをパーティション化すれば、パージを回避できます。テーブルから大量のデータを削除したい場合は、新しいテーブルを作成し、データをコピーして、古いテーブルを削除するという方法をいつも検討する価値があります。 もう 1 つの戦略は、大量の DELETE または UPDATE ステートメントが実行されている間、読み取りビューが undo ログを保持しパージをブロックする可能性がある、長時間実行される SELECT クエリを避けることです。 max_execution_time を使用して最大制限時間を設定することで、実行時間が長すぎる SELECT クエリを自動的に停止できます。トランザクションの分離レベルを、 REPEATABLE READ から READ COMMITTED に切り替えることもできます。これにより、SQL ステートメントによって作成される読み取りビューの範囲が狭まり、undo ログのパージがブロックされる可能性が低くなります。 Aurora MySQL は、1 つ以上の DB インスタンスで構成されるクラスター化されたデータベースであり、すべての DB インスタンスが同じ共有されたクラスターストレージボリュームを使用します。InnoDB のパージの実装は、そのクラスタリングトポロジーの影響を受けます。Aurora MySQL DB クラスターを使用する場合、Amazon RDS for MySQL DB インスタンスと比較すると、次のような違いがあります。 パージがデータベース全体のグローバルな操作であるという概念は、Aurora MySQL のデータベースアーキテクチャ全体で一貫しています。パージはプライマリ (ライター) DB インスタンスで実行されます。ただし、Auroraレプリカ DB インスタンス上の SELECT クエリが読み取りビューを作成するため、パージがブロックされる可能性があります。 Aurora Global Database においても、セカンダリ DB クラスター上の SELECT クエリがプライマリ DB クラスターのパージをブロックする可能性があります。 Aurora レプリカ DB インスタンスでは、 READ COMMITTED 分離レベルは、長時間実行される SELECT クエリがパージスレッドに与える影響を軽減するように最適化されており、Aurora MySQL 固有の動作をします。クエリの結果は、プライマリDBインスタンスで MySQL のネイティブの READ COMMITTED レベルを使用する場合とは少し異なる場合がありますが、それでも ANSI SQL 標準に準拠しています。この機能を有効にするには、DBクラスターパラメータグループ、またはセッションレベルで aurora_read_replica_read_committed を ON に設定します。 テーブルとインデックスの構造を最適化する undo ログに加えて、InnoDB テーブルで削除済みとマークされたテーブルレコードもパージ操作の対象になります。一般的な意味では、テーブルレコードとは、クラスター化インデックス、セカンダリインデックス、 InnoDB の行フォーマット に従って外部に保存された可変長列など、テーブルの行データを格納または示すさまざまなデータ構造を参照します。undo ログレコードにはテーブル ID とクラスタ化インデックスしか含まれていないため、パージスレッドは削除マークの付いた他の関連するテーブルレコードを識別し、存在する場合は削除する必要があります。これは、パージ操作で最も負荷の高い部分になる可能性があります。 セカンダリインデックスがパージ操作に与える影響の例を考えましょう。次のグラフは、2 つの Aurora MySQL DB クラスターの Amazon CloudWatch メトリック RollbackSegmentHistoryListLength を比較しています。どちらのクラスターにも r7g.2xlarge プライマリ (ライター) DB インスタンスがあり、 Sysbench の oltp_write_only.lua prepare ワークロードを使用して 80 GB のデータを含む 1 つのテーブルをロードします。1 つのクラスター (クラスターA) では、 oltp_update_non_index.lua ワークロードを実行して、セカンダリインデックスでカバーされていない列を更新します。他のクラスター (クラスターB) では、 oltp_update_index.lua ワークロードを実行して、その上にセカンダリインデックスが構築されている列を更新します。どちらの Sysbench ワークロードも、 --rate を使用して同じレートでトランザクションを生成します。 次のことを観察できます。 DMLThroughput は両方のクラスターで同じパターンを示し、同じ数の UPDATE ステートメントを実行していることを示しています。 oltp_update_index.lua ワークロードを実行するクラスターでは、 RollbackSegmentHistoryListLength がピーク時に 300 万を超えます。しかし、他のクラスターではゼロに近いままです。これは、セカンダリインデックスを含むundo ログを処理すると、パージスレッドが大幅に遅くなる可能性があることを示しています。セカンダリインデックスの使用は必ずしも問題ではありません。両方のクラスターのテーブル構造は同じで、どちらのテーブルにもセカンダリインデックスがあります。セカンダリインデックスは、データベースのワークロードによって変更された場合にのみ、パージスレッドに課題をもたらします。 11:52 の縦線は、クラスター B のセカンダリインデックスをいつ削除したかを示しています。セカンダリインデックスを削除すると、パージによりセカンダリインデックスのレコードを検索してクリーンアップする必要がなくなるため、パージ操作がすぐにスピードアップします。セカンダリインデックスを削除してから数分で RollbackSegmentHistoryListLength がゼロに下がることがわかります。SYS スキーマの schema_unused_indexes ビューを使用して、使用されていないセカンダリインデックスを特定し、必要かどうかを評価できます。 MySQL 8.0 以降、パージワーカースレッドは、削除マークの付いたテーブルレコードをクリーンアップするために、異なるテーブルで並行して動作するように設計されています。並列処理の効率は、いくつかの要因によって決まります。次のグラフは、パージワーカースレッドの数と、パージされるのを待機している undo ログを保持するテーブルの数との相関関係の例を示しています。 データは、前の 2つの Aurora MySQL DB クラスターでの別のテストから収集されました。1 つのクラスター (クラスターB) は 80 GB のデータを持つ 1 つのテーブルを引き続き使用し、もう 1 つのクラスター (クラスターA) は合計 80 GB のデータを、それぞれ 8 GB のデータを持つ 10 個のテーブルに分散させています。どちらのクラスターも Sysbench oltp_update_index.lua ワークロードを実行し、 --rate を使用して同じレートでトランザクションを生成します。両方のクラスターの DB インスタンスは r7g.2xlarge なので、 innodb_purge_threads はデフォルトで 3 に設定されています。つまり、2 つのパージワーカースレッド (及びパージコーディネーター) を同時に実行できます。 次のことを観察できます。 DMLThroughput は両方のクラスターで同じパターンを示し、同じ数の UPDATE ステートメントを実行していることを示しています。 RollbackSegmentHistoryListLength は、1 つのテーブルがロードされたクラスター A では 300 万ですが、10個のテーブルを持つクラスター B ではピーク時に約 50 万に達します。パージ速度が速いのは、2 つのワーカースレッドが並行して動作することと、作業する各ワーカースレッドにとってテーブルサイズが小さいことの 2 つの要因によるものです。一度に 1 つのテーブルを消去できるワーカースレッドは1つだけです。並列処理を最大限に活用するには、パージワーカースレッドよりも多いか同数のテーブルに対し、データ変更を均等に分散するのが理想的です。 innodb_purge_threads は、パージ操作のスピードに影響する要因です。他の要因が作用している場合、パージスレッドをスピードアップするのに役立つかもしれません。 適切なインスタンスクラスを選択する 設計上、パージは非干渉的です。パージスレッドはバックグラウンドで実行され、ユーザートランザクションとは非同期に動作します。妥当な遅延時間でジョブを終わらせるために、システムリソースの消費を最小限に抑えることが期待されています。MySQL では、 innodb_purge_threads の最大値を 32 と定義しています。つまり、MySQL データベースには最大 32 のパージスレッドを設定できます。このような設定は、負荷の高い本番データベースに何千ものユーザー接続を同時に許可する max_connections と比較して、パージスレッドに競争上の優位性をもたらすことを意図したものではありません。 パージスレッドが undo ログや削除マークの付いたテーブルレコードを処理する際、undo ログページと InnoDB バッファプールのデータページからデータを読み取る必要があります。それらのデータページがバッファプールに存在しない場合は、I/O コールを発行してストレージから取得します。RDS DB インスタンスの CPU、メモリ、IO 帯域幅などのシステムリソースが、パージ操作の速度に大きな影響を与える可能性があります。 高速なパージ操作には、パージスレッドだけでなく、データベース全体のワークロードについてもキャパシティプランニングが必要です。リソースが不足している、またはユーザートランザクションによるシステムリソースの使用率が高い DB インスタンスでは、リソースの競合によりパージスレッドが遅くなり、パージの遅延が予期せず現れることがあります。次のグラフは、この状況の例を示すために、r7g.2xlarge のプライマリ (ライター) DB インスタンスを持つ Aurora MySQL DB クラスターで実施したテストの結果です。 テストは、2 つの異なる Sysbench データセットを順番にロードすることから始まります。まず、クラスターにはそれぞれ 8 GB のデータを含む 10 個の Sysbench テーブルがロードされ、次に、34 GB のデータの別のテーブルがロードされます。データをロードした後、テストは 34 GB のテーブルに対して oltp_read_only.lua ワークロードを実行します。 innodb_buffer_pool_size はデフォルトで 42 GB に設定されているため、この 34 GB のテーブルデータは InnoDB バッファプールに完全にキャッシュされます。同時に、他の 10 個のテーブルのほとんどのデータはバッファプールから削除されます。読み取り専用ワークロードが完了する前に、テストは他の 10 個のテーブルで oltp_update_index.lua ワークロードを開始します。 次のことを観察できます。 SelectThroughput と DMLThroughput は、2つの異なるタイプのワークロードが、自身のデータセットをロードするために InnoDB バッファプールをめぐって競合していることを示しています。 oltp_update_index.lua ワークロードの終了時、 RollbackSegmentHistoryListLength が 500 万を超えました。これは前のテストと比較すると想定外です。そのテストでは、10 個のテーブルで同じ oltp_update_index.lua ワークロードをより高いレート ( 1 万 5 千対 1 万) で実行したところ、 RollbackSegmentHistoryListLength は約 50 万でした。 oltp_update_index.lua ワークロードが開始されると、バッファプールの競合が原因で、 BufferCacheHitRatio が急激に低下します。ワークロードが完了した後も低いままです。これは、パージスレッドが undo ログやテーブルレコードをバッファプールに取り込むときに、I/O パスでボトルネックになっていることを示しています。 InnoDB バッファプールへの適切なメモリ割り当ては、パージ操作の速度に大きな影響を与える可能性があります。必要な undo ログやテーブルデータがバッファプールにない場合、パージスレッドのパフォーマンスは IO レイテンシーと相関します。 MySQL データベースでは、 innodb_purge_threads パラメーターを変更することで、パージスレッドの数を設定できます。RDS for MySQL を使用する場合、MySQL コミュニティエディションと同じくデフォルト値は 1 で、DB パラメータグループで変更できます。Aurora MySQL を使用する場合、デフォルトは、DB インスタンスのサイズが大きくなるにつれて増加し、 DB クラスターパラメータグループ で変更できます。次の表は、r7g インスタンス~タイプのデフォルト式に基づいた、パージ関連の設定の有効値を示しています。 RDS インスタンスタイプ vCPU メモリ (GiB) innodb_buffer_pool_size (GiB) innodb_purge_threads innodb_purge_batch_size db.r7g.large 2 16 7.76 1 600 db.r7g.xlarge 4 32 19.36 1 600 db.r7g.2xlarge 8 64 42.59 3 1800 db.r7g.4xlarge 16 128 89.11 3 1800 db.r7g.8xlarge 32 256 182.06 6 3600 db.r7g.12xlarge 48 384 275.11 12 7200 db.r7g.16xlarge 64 512 368.13 12 20000 Aurora Serverless V2 インスタンスタイプでは、この設定はインスタンスのスケールアップまたはスケールダウン時に自動的に設定され、パラメータグループでは変更できません。 監視とアラーム InnoDB のパージを監視するためのよく知られたメトリックは、パージラグとも呼ばれるロールバックセグメント履歴リストの長さです。これは、パージされるのを待機している undo ログの数を示します。MySQL データベースでは、 SHOW ENGINE INNODB STATUS を実行して、 History list length を直接確認できます。Aurora MySQL は、すべての 3.0 リリースで RollbackSegmentHistoryListLength を CloudWatch メトリックとして提供しています。Amazon RDS for MySQL では、 Performance Insights にて trx_rseg_history_len というメトリックを提供しており、それを CloudWatch に公開 できます。 パージラグがはるかに遅れ、データベースのパフォーマンス上の問題を引き起こす可能性がある状況を検出するために、このメトリックに CloudWatch アラーム を設定することをお勧めします。アラームのしきい値は、データベースがこれまでに到達した過去の正常値と、アラームがトリガーされたときに取るアクション項目に基づいて設定できます。 データベースワークロードによって、パージスレッドが十分に速く処理仕切れないほどの undo ログが生成され、パージラグが増加していることに気付いた場合は、データベースインスタンスのサイズを増やして、パージスレッドに割り当てるシステムリソースを確保してください。または、 データベースシャーディング アーキテクチャを使用して、複数のデータベースシャードにワークロードを分散することもできます。MySQLには、ロールバックセグメント履歴リストの長さの閾値を設定するための innodb_max_purge_lag も用意されています。違反すると、INSERT、DELETE、UPDATE ステートメントに対し内部のスロットリングが開始され、最大 innodb_max_purge_lag_delay までの遅延が発生します。これらのオプションをテストして、どれが自分のユースケースに最適かを確認できます。 まとめ InnoDB のパージ効率を向上させるには、ワークロードの最適化、データベースのキャパシティプランニング、および設定を組み合わせる必要があります。この記事では、RDS for MySQL DB インスタンス、Aurora MySQL DB クラスター、またはその他の種類の MySQL データベースでそれを実行するために役立つガイドラインを提供します。 著者について Lei Zeng は AWS のデータベースエンジニアです。 本記事の翻訳はクラウドサポートエンジニアの野沢が担当しました。

本稿は、2024 年 11 月 7 日に公開された “ Securing PartyRock: How we protect Amazon Bedrock endpoints using AWS WAF ” を翻訳したものです。 PartyRock は、 Amazon Bedrock をベースとした直感的で実践的な生成 AI アプリ構築プレイグラウンドです。それは、ユーザーが生成 AI テクノロジーを実験でき、 クイズジェネレーター や レジュメオプティマイザー などコーディングなしで楽しいアプリケーションを構築できます。無料のオンライン生成 AI プレイグラウンドを開発者に提供することは非常に大きな価値があることですが、それは重要なセキュリティ面での課題も存在します。 この投稿では、 AWS WAF を利用して分散型サービス拒否 (DDoS) 攻撃や Wallet 拒否攻撃 (DoW) のような潜在的な脅威から PartyRock を保護した方法を探求します。また、オンラインアプリケーションに生成 AI 機能をインテグレーションしている開発者は、同様の脅威からそのアプリケーションを保護する具体的な AWS WAF の基本テクニックについて学ぶことができます。 セキュリティの課題 ここで述べている 2 つの脅威は、私たちの無料の生成 AI プレイグラウンドの機能やユーザー体験に影響を与えます。 分散型サービス拒否 (DDoS) 攻撃 : DDoS 攻撃は、大量のトラフィックであなたのリソースを圧倒して、あなたのサービスをオフラインにする可能性があります。PartyRock は評価を落とし、その可用性を損なう、評判を傷つける、または身代金を要求しようとする攻撃者によって標的にされる可能性があります。 サービス悪用: 悪意のある攻撃者が、汎用的な生成 AI のコンピュート能力の転売など意図されていない目的でプラットフォームを悪用しようと試みる可能性があります。攻撃者は、PartyRock 上で大量のアプリ実行を生成することにより、私たちのユースケースにおいてクラウドサービスのリソース自動スケーリング機能(クラウドの弾力性)を悪用します。PartyRock での平均的なアプリ実行では、Bedrock 上の Anthropic Sonnet 3 モデルを使用して 2000 個の入力トークンと 400 個の出力トークンを消費するため、1000 回のアプリ実行ごとに約 12 ドルのコストがかかります。アプリ実行の悪用を放置すると、予期しない、そして潜在的に重大なクラウド請求が発生する DoW (Wallet 拒否攻撃)につながり、悪意のある攻撃者がクラウドの柔軟性を PartyRock に対して悪用することを可能にしてしまいます。 これらの課題に対処するため、私たちは最初から堅牢なセキュリティ制御を実装し、AWS WAF が私たちの防御戦略において中心的な役割を果たしています。 PartyRock のサーバーレスアーキテクチャ セキュリティ対策について詳しく説明する前に、 AWS Cloud Development Kit (AWS CDK) を使用してデプロイした PartyRock のサーバーレスアーキテクチャを確認します。 Amazon CloudFront : PartyRock のエントリーポイントとして機能し、キャッシュとダイナミック API コールの高速化を通じて、より良いユーザー体験を提供します。CloudFront エッジにおいて、Bot Control ルールなどの AWS WAF による保護を実装しています。 Amazon S3 : PartyRock の静的フロントエンドをホストします。 AWS Lambda : Amazon Cognito や Bedrock などの他のインフラストラクチャコンポーネントと統合し、アプリケーションロジックを実行することで、私たちの React アプリケーションと API を動作させています。レイテンシとコストを削減するため、CloudFront 経由で Lambda 関数を利用可能にしています。Lambda URL を直接 CloudFront のオリジンとして設定しています。私たちのケースでは、API は通常 API ゲートウェイが提供する高度な機能を必要としないため、必要な構成要素を少なくしてアーキテクチャをシンプルに保つことができ、より安価で高速にすることが可能です。さらに、 CloudFront ディストリビューションのみが Lambda URL と通信できるよう、CloudFront の機能である Origin Access Control を使用して Lambda URL を設定しています。Bedrock とのインターフェースを担当する Lambda 関数は、Bedrock のレスポンスをユーザーにストリーミングで返すため、レスポンスストリーミングで設定されています。 Amazon Cognito : Google、Amazon、Apple などのソーシャルアイデンティティプロバイダーを通じてユーザー認証を管理します。 Amazon Aurora Serverless : PostgreSQL データベースとして機能し、豊富な機能と自動スケーリングを提供します。Amazon Aurora Serverless はオンデマンド型のマネージドデータベースで、重い作業を軽減し、機能に集中して迅速に反復開発することを可能にします。 Amazon CloudWatch RUM : クライアントサイドのパフォーマンスとエラーを分析します。 図 1 : PartyRock のアーキテクチャの概要 AWS WAF を用いた多層防御の構築 多層防御は、インフラストラクチャを保護するために複数のセキュリティ制御を採用するサイバーセキュリティ戦略です。単一のセキュリティ対策に依存するのではなく、このアプローチは様々な防御メカニズムの組み合わせを使用します。この考え方は、セキュリティの一つの層が失敗したり侵害されたりした場合でも、他の層が代わりに攻撃を検出、防止、または軽減するというものです。私たちは、PartyRock を保護するために、認証ステップと組み合わせた AWS WAF ルールの組み合わせを使用しました。 IP reputation 私たちは、Amazon の内部脅威インテリジェンスに基づくマネージドルールグループである、 Amazon IP 評価リスト を設定しました。これは、典型的なボットやその他の脅威に関連する IP アドレスをブロックしたい場合に有用です。このリストには 3 つのルールが含まれています： AWSManagedIPReputationList : 悪意のある活動に積極的に関与していると特定された IP アドレスを検査します。 AWSManagedReconnaissanceList : AWS リソースに対して偵察活動を行っている IP アドレスからの接続を検査します。 AWSManagedIPDDoSList : DDoS 活動に積極的に関与していると特定された IP アドレスを検査します。 実際の影響 : 2024 年 2 月、AWSManagedIPReputationList ルールにより、ユーザーの体験に影響を与えることなく、悪意のある活動に関連する 20 万件のリクエストを数十分で特定してブロックすることができました。 Rate limiting レートベースルールは、短時間内の大量のリクエストによって Web アプリケーションが圧倒されることを防ぐように設計されています。これは特に、DDoS 攻撃、ボット攻撃、悪意のあるトラフィックを軽減するのに有用です。このルールは定義された基準に従ってリクエストを集約し、ルールの評価ウィンドウ、リクエスト制限、およびアクション設定に基づいて、集約されたグループに対してレート制限を適用します。 私たちは、アプリケーションが圧迫されることを防ぐために、複数のレートベースルールを実装しました: 単一のソース IP が Web サイトを圧倒することを防ぐための包括的なレート制限。 使用する IP アドレスに関係なく、単一のユーザーセッションが Web サイトを圧倒することを防ぐためのCookieベースのレート制限。 実際の影響 : 2024 年 6 月、両方のルールにより、PartyRock のインフラストラクチャを圧迫しようとする数百万件の悪意のあるリクエストをブロックすることができました。 図 2 : レート制限ルールを利用してブロックしたリクエスト数 カスタム緩和ルール 私たちは、AWS WAF で手動対応が必要な DDoS 攻撃に迅速に対応するためのカスタムルールをいくつか作成しました。これらのルールは、私たちが定義した値のリストと一致する特定の属性(例: IP や TLS フィンガープリント (JA3) )を持つリクエストをブロックするように設定されています。通常の状況では、これらのルールにはマッチング文が含まれていないため、どのリクエストもブロックしません。DDoS 攻撃に手動で対応する必要がある場合、まず CloudWatch Logs Insights を使用して攻撃を分析し、トップトーカー(例: 攻撃に最も寄与する JA3 シグネチャ)を特定します。その後、作成したカスタムルールに対応するマッチング文を追加します。これにより、脅威により迅速に対応することができます。 実際の影響 : 2024 年 1 月、私たちは JA3 ベースのカスタムルールを使用して、1 時間あたり数百万件のリクエストを生成する継続的な HTTP フラッド攻撃をブロックしました。 図 3 : カスタム JA3 シグネチャーを利用してブロックしたリクエスト数 CAPTCHA による登録ステップのセキュリティ強化 PartyRock のセキュリティにとって登録ステップは重要です。悪意のある攻撃者が偽のアカウントを作成すると、私たちの無 料の生成 AI 計算能力を悪用される可能性があります。 PartyRock を無料にするトレードオフとして、私たちは 3 つのプロバイダー (Amazon、Apple、Google) からの連携アイデンティティのみを使用した登録を限定的に許可することにしました。登録ステップでは、まずこれらのアイデンティティプロバイダーのいずれかを通じてログインし、それらの認証ステップを経て、PartyRock が必要な情報にアクセスすることを認可する必要があります。最後に、PartyRock でユーザーアカウントを作成する前に、AWS WAF のカスタムルールがさらなる認証ステップとして CAPTCHA を提示します。 CAPTCHA Javascript API を使用して、PartyRock ウェブアプリケーション内で CAPTCHA フォームを表示するようにフロントエンドコードを変更し、登録体験をよりスムーズにしました。CAPTCHA 統合について詳しくは、この Amazon Networking の投稿 をお読みください。 自動化されたボットトラフィックの高度な管理 AWS WAF で設定したセキュリティの最後のレイヤーは Bot Control です。私たちの目標は、匿名ユーザーからのトラフィックかログインユーザーからのトラフィックかに関係なく、自動化されたボットトラフィックを識別し管理することです。Bot Control のマネージドルールグループは 2 つのレベルの保護を提供します。 自己識別型のボットにラベルを追加し、一般的に望ましいボットを検証し、高信頼度のボットシグネチャを検出する、基本となる Common インスペクションレベル 自己識別しない高度なボットを検出する Targeted インスペクションレベル 実際の影響 : 次のグラフを見ると、Bot Control の Common インスペクションレベルが一年を通して異なるHTTPフラッド攻撃を防いだ実績を確認することができます。 Bot Control の Targeted インスペクションは、ブラウザ検査、フィンガープリンティング、行動ヒューリスティックなどの技術に基づいた高度な検出機能を提供し、悪意のあるボットトラフィックを識別します。これらの検出機能には、クライアント側で実行される AWS WAF Javascript Challenge が必要です。 このため、私たちはページに Bot Control Javascript SDK を統合しました。ページが読み込まれると、SDK はユーザー体験に影響を与えないよう非同期で Javascript チャレンジを実行します。チャレンジが正常に解決されると、SDK は暗号化されたトークンを Cookie に配置します。このトークンはユーザーセッションからのすべてのリクエストで AWS WAF に送信され、ユーザーの行動を分析できるようになります。トークンには自動化されたブラウザの検出されたフィンガープリントも含まれています。さらに、SDK はユーザーのナビゲーション中にテレメトリを収集し、検出と緩和ロジックをさらに強化します。 これは非同期であるため、有効なトークンを持たない最初のリクエストも許可する必要があります。Bot Control の TGT_ VolumetricIpTokenAbsent ルールによって、アプリケーションがトークンなしで単一の IP から大量のリクエストを受信した場合、AWS WAF は JavaScript チャレンジペイロードを使用してチャレンジを強制実行し、チャレンジをサイレントに完了してから元のページにリダイレクトします。 前述したように、Bot Control は JavaScript チャレンジの正常な解決後に取得される暗号化トークンを使用して、ユーザーセッ ションの行動を分析します。これにより、通常よりも多くのリクエスト量を持つセッションを特定し、CAPTCHA レスポンスでチャレンジすることができました。 実際の影響 : 以下のグラフは、2024 年を通じて PartyRock へのセッション毎のトラフィックレベルの上昇により、CAPTCHAでチャレンジされたリクエストを示しています。 図 12 : トラフィックレベルが上昇したセッションからのリクエストに対し、CAPTCHA でチャレンジ まとめ 生成 AI の実験的なオープンで創造的な環境を維持しながら、潜在的な脅威や悪用から保護するために、私たちは PartyRock に堅牢な多層防御を構築しました。AWS WAF を使用して、高レベルで以下のルールを実装しています。 DDoS 攻撃のような悪意ある活動に関連した IP からのリクエストをブロックする IP 評価ルールベースのルール 単一の IP やセッションが PartyRock のインフラストラクチャを圧迫することを防ぐための様々な種類のレートベース インシデント対応中に特定された疑わしい属性に基づいてリクエストをブロックするカスタムルール ユーザー登録のワークフローでさらなる認証ステップのための CAPTCHA ルール ボットネットからの自動化されたトラフィックを識別し、適切に管理する Bot Control マネージドルール この AWS WAF 設定は固定的なものではありません。アプリケーションログの継続的な監視と分析を通じて、日常業務で観察される新たな脅威やパターンに対処するため、定期的にルールセットを改良し拡張しています。 私たちはまた、別の AWS WAF ルールセットを使用して Cognito User Pools も保護しました。AWS WAF を使用した Cognito User Pools の保護について詳しくは、 ドキュメント で学ぶことができます。 AWS WAF を始めるには、この ショートビデオ をご覧ください。より詳細な情報は AWS WAF ドキュメント で確認できます。 大規模言語モデル (LLM) アプリでコスト高なトラフィックを回避するための AWS WAF の使用方法について詳しく学ぶには、re:Inforce 2024の この講演 をご覧ください。 Andre Guelfi Torres Andre は AWS のソフトウェア開発エンジニアとして約 4 年間勤務しており、2023 年 8 月の開始時から PartyRock チームに所属しています。それ以前は、コンサルティング、フィンテック、決済など他の業界で働いていました。 Achraf Souk Achraf Souk は EMEA のエッジスペシャリストソリューションアーキテクトチームをリードしています。このチームは、AWS エッジサービスを使用して企業や開発者のウェブアプリケーションのセキュリティと高速化を支援しています。エッジテクノロジー (CDN、パフォーマンス、DDoS、ボット、WAF) に興味がある専門家、ソリューションアーキテクトとしてのスキルを開発したい方、またはリーダーシップ経験からの洞察を求めている方は、LinkedIn でフォローしてください。 翻訳は、パートナーセールスソリューションアーキテクトの小林が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 AWS re:Invent 2025 に現地参加し、これが初めての投稿です。会場では Builders Fair エリアにて「Command a Robot with Amazon Bedrock」というブースを出展しました。多くの日本のお客様にお越しいただき、ありがとうございました。ブースでは Bedrock を活用し、ロボットを自然言語で操作するデモを実装しました。ほかにも AI 搭載ロボットの展示が複数あり、フィジカル AI に関する関心が高いと感じました。デモの詳細は今後ブログやアセットとして公開予定です。フィジカル AI に興味のある方は、 こちらのブログ もご参照ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年12月15日週の主要なアップデート 12/15(月) AWS Billing and Cost Management でダッシュボードの PDF エクスポートと CSV データダウンロードをサポート開始 AWS Billing and Cost Management のダッシュボードで、PDF エクスポートと CSV データダウンロード機能が利用可能になりました。これまでスクリーンショットで対応していたダッシュボードの共有が、PDF として直接エクスポートできるようになり、会議や戦略企画での資料作成が効率化されます。また、個別のウィジェットデータを CSV でダウンロードできるため、スプレッドシートでの詳細分析も可能です。追加コストは不要で、中国リージョンを除く全ての商用リージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 ユーザー属性を使用したコスト配分の発表 ユーザー属性を使った新しいコスト配分機能を発表しました。これまで部署やプロジェクトごとの AWS 利用コストを把握するのは困難でしたが、今回の機能により Amazon Q Business や Quick Suite などのアプリケーションの利用料金を、コストセンターや部門といったユーザー属性で自動的に分類できるようになります。経理担当者や FinOps チームが Cost Explorer で詳細なコスト分析を行い、どの部署がどの程度 AWS を利用しているかを簡単に把握できる点が大きなメリットです。詳細は こちらのドキュメントをご参照ください。 Amazon Connect が評価フォームで複数選択と日付の質問をサポート Amazon Connect の評価フォームで複数選択と日付の質問タイプが新たに利用できるようになりました。これまでは単一選択のみでしたが、営業会話で顧客が興味を示した複数の商品を選択できたり、ローン申請日や承認日といった具体的な日付を記録できるようになります。マネージャーは人間と AI エージェントのパフォーマンスをより詳細に分析でき、顧客対応の品質向上に活用できます。詳細は こちらのドキュメントをご参照ください。 12/16(火) Amazon Quick Suite でチャットエージェントのメモリ機能をサポート開始 Amazon Quick Suite のチャットエージェントにメモリ機能が追加されました。この機能により、過去の会話内容や設定した好みを記憶し、パーソナライズされた応答が可能になります。従来は毎回同じフォーマット設定やダッシュボード設定を繰り返す必要がありましたが、今回のアップデートでその手間が解消されます。ユーザーは記憶された内容を確認・削除でき、プライベートモードでの利用も選択できます。バージニア北部リージョンとオレゴンリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 カーボンフットプリントデータの公開時間を 21 日以内に短縮 AWS のカーボンフットプリントデータの公開が大幅に高速化されました。従来は最大 3 か月かかっていたデータ公開が、21 日以内に短縮されています。毎月 15 日から 21 日の間に前月分のデータが確認できるため、アプリケーションの配置や運用方法をより迅速に見直せます。環境負荷削減とコスト最適化の両方を同時に実現でき、過去 38 か月分のデータで長期トレンドも把握可能です。詳細は こちらのドキュメントをご参照ください。 AWS Security Incident Response が Slack との統合を導入 AWS Security Incident Response が Slack との統合に対応しました。これまではセキュリティインシデント対応時に複数のツールを行き来する必要がありましたが、今回の統合により Slack 上で直接ケースの作成や更新が可能になります。各インシデントケースが専用の Slack チャンネルとして作成され、コメントや添付ファイルがリアルタイムで同期されるため、セキュリティチームの迅速な対応と効率的なコラボレーションを実現できます。 AWS IoT Device Management Commands が動的ペイロードをサポート AWS IoT Device Management Commands で動的ペイロード機能が利用できるようになりました。これまではデバイスごとに個別のコマンドを作成する必要がありましたが、今回のアップデートによりテンプレート化されたコマンドを作成し、実行時にパラメータを指定できます。例えばスマートサーモスタットの温度設定では、温度値ごとに別々のコマンドを用意する代わりに、温度をプレースホルダーにしたテンプレート 1 つで対応可能です。パラメータ検証機能も追加され、実行前に値の妥当性をチェックします。詳細は こちらのドキュメントをご参照ください。 12/17(水) AWS Marketplace で必須の発注書とカスタムメッセージングをサポート開始 AWS Marketplace で購買注文書の必須化とカスタムメッセージ機能が利用開始されました。これまで組織の調達ルールを徹底するのが困難でしたが、管理者が購買時に注文書の提出を必須にしたり、調達ページにポリシーや連絡先などのメッセージを表示できるようになります。Private Marketplace との組み合わせで、承認済み製品のカタログ管理も強化され、コンプライアンス遵守と購買の俊敏性を両立できます。詳細は こちらのドキュメントをご参照ください。 AWS のデータベースが Vercel Marketplace で利用可能になりました AWS のデータベースサービスが Vercel Marketplace で利用できるようになりました。Amazon Aurora PostgreSQL、Amazon Aurora DSQL、Amazon DynamoDB を Vercel から数秒で直接作成・接続できます。これまで複雑だったデータベース設定が大幅に簡素化され、Web アプリ開発者にとって画期的なアップデートです。新規アカウント作成時には 100 ドルのクレジットが付与され、6 ヶ月間利用可能です。 12/18(木) AWS Direct Connect が AWS Fault Injection Service による耐障害性テストをサポート AWS Direct Connect が AWS Fault Injection Service (FIS) での耐障害性テストに対応しました。これまでは本番環境での障害時の動作確認が困難でしたが、今回のアップデートにより BGP セッションの中断を意図的に発生させ、冗長化された Virtual Interface への自動切り替えをテスト可能になりました。ネットワーク接続の継続性が重要なシステムでの事前検証に活用できます。詳細は こちらの製品ページをご参照ください。 Amazon SES がメール検証機能を発表 Amazon SES でメールアドレスの事前検証機能が追加されました。メール送信前にアドレスの有効性をチェックし、バウンス率を下げて送信者の評判を保護できます。API での個別検証や、コード変更不要の自動検証が可能で、構文チェックや DNS レコードの詳細な検証情報も取得できます。従来はメール送信後にバウンスで判明していた無効なアドレスを事前に特定できるため、メールリストの品質向上や配信成功率の改善が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS IoT Core が HTTP ルールアクションにメッセージバッチング機能を追加 AWS IoT Core の HTTP ルールアクションに、複数の IoT メッセージを 1 つのバッチにまとめて処理する機能が追加されました。従来は各メッセージを個別に HTTP エンドポイントに送信していましたが、今回のアップデートにより複数のメッセージをまとめて送信できるようになり、コストとスループットの負荷を削減できます。例えば、複数のスマートホームデバイスからのデータを 1 つのバッチにまとめて処理できるため、より効率的な IoT システムの構築が可能です。詳細は こちらの開発者ガイドをご参照ください。 12/19(金) Amazon WorkSpaces Applications が Microsoft Windows Server 2025 をサポート開始 Amazon WorkSpaces Applications で Microsoft Windows Server 2025 をサポート開始しました。最新のセキュリティとパフォーマンス向上により、エンドユーザーに Windows 11 デスクトップ体験を提供できます。従来のサーバー OS では実現できなかった最新機能を活用し、ビジネス重要アプリケーションやリモートアクセス環境をより安全で高性能に構築できます。AWS 提供の標準イメージまたは Image Builder でカスタムイメージの作成も可能で、全リージョンで利用開始できます。 Amazon Bedrock Data Automation がドキュメントブループリント向けの指示最適化機能を開始 Amazon Bedrock Data Automation で blueprint instruction optimization 機能が登場しました。従来はドキュメントからの情報抽出精度を上げるのにモデル訓練が必要でしたが、今回のアップデートで最大 10 個のサンプルドキュメントを用意するだけで自動的に指示文を最適化し、本番レベルの精度を実現できます。請求書の項目抽出や契約条件の分析、医療請求コードの識別など、様々なビジネスシーンで活用可能です。詳細は こちらのドキュメントをご参照ください。 AWS IoT が可観測性コストの最適化を支援するイベントベースログ機能を提供開始 AWS IoT でイベントベースロギング機能が新たに利用開始となりました。従来は全てのイベントを同じログレベルで記録していましたが、今回のアップデートでイベントの種類や重要度に応じて個別にログレベルを設定できるようになります。例えば、証明書関連のイベントは INFO レベル、接続イベントは ERROR レベルのみといった具合に細かく制御可能です。これにより Amazon CloudWatch のログコストを大幅に削減しつつ、必要な情報の可視性は維持できます。AWS IoT コンソールや CLI、API から設定でき、AWS IoT がサポートされている全てのリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。