本記事は、2026年1月12日に公開された ” Building Intelligent Network Operations Agent with Amazon Bedrock AgentCore ” を翻訳したものです。 深夜2時、バージニア北部 リージョン にてお客様のトランザクション処理が失敗したというアラートが、あなたのスマートフォンに届きました。Amazon Web Services (AWS)上で画像処理プラットフォームを管理するネットワーク運用者のあなたは、複雑なアーキテクチャのトラブルシューティングを迫られます。このネットワークは、複数の Amazon Virtual Private Cloud (Amazon VPC) が AWS Transit Gateway で相互接続されており、その上で多数のマイクロサービスが実行されています。根本原因の可能性は多岐にわたり、セキュリティグループの設定ミスからNetwork Access Control List (NACL) の問題、 AWS Network Firewall ルールが正当なトラフィックをブロックしているかもしれません。このようなシナリオは現在のクラウド環境においてますます一般的になっており、複雑なネットワークトポロジが復旧時間を長引かせる要因となっています。 今日のAWSユーザーが運用する環境は、複数のAWSリージョンにわたる数百ものVPCを含むことが珍しくありません。それぞれのVPCには独自のセキュリティ設定、Network Firewallポリシー、Transit Gatewayを介した複雑なルーティングが組み込まれています。接続障害が発生すると、運用チームは通常、 VPCフローログ 、 Amazon CloudWatch メトリクス、 AWS Reachability Analyzer の検出結果、アプリケーションログなど、膨大なデータソースを横断して調査しなければなりません。その結果、トラブルシューティングが長期化し、解決に向けたアプローチも担当者によってばらつきがちです。本記事では、 Amazon Bedrock AgentCore のAI機能をAWSのネットワーキングサービスと統合し、高度なネットワーク運用エージェントを構築する方法を解説します。セキュリティや運用水準を満たしながら、診断と修復を自動化する手法を探ります。 エージェントの構成要素 レゴブロックを組み合わせて複雑な構造を作るのと同様に、エージェントベースのソリューションも複数のモジュール化されたコンポーネントを組み合わせて構築されます。各モジュールには特定の役割があり、それらを適切に組み合わせることで、組織のニーズに合わせて適応・拡張できる、堅牢で柔軟なネットワーク運用システムが構築されます。図1に、このようなエージェントに必要な構成要素を示します。 図1: ネットワーク運用エージェントの構成要素 Interface＆Integration ブロックは、ユーザーとシステムを繋ぐ主要な接点として機能します。自然言語処理やマルチモーダル入力をサポートすると同時に、AWSサービスとのシームレスな連携を可能にします。具体的には、自然言語のクエリを構造化コマンドに変換し、 AWS SDKによる直接的なAPI連携 、 AWS Lambda 統合、 モデルコンテキストプロトコル(MCP)サーバーベースの統合 機能を介してサービス間接続を管理します。 Security＆Operations ブロックは、 Amazon Bedrock AgentCore Identity 、 AWS Identity and Access Management (IAM) ロール、 Prompt Engineering 、 Amazon Bedrock AgentCore Policies を用いて包括的な保護を実装します。同時に、 Amazon CloudWatch を通じて、モニタリング、アラート、自動修復を管理します。このブロックは、安全な運用とプロアクティブな問題検出を保証します。認証と認可からコンテンツフィルタリング、監査ログに至るまで、多層的なセキュリティコントロールを実装することで機能します。 Intelligence ブロックは、 Amazon Nova 、 Claude Sonnet 4 、 Llama などの 基盤モデル(FM) を利用した認知エンジンとして機能します。これには、高度なChain-of-Thought(思考の連鎖)プロンプティングと ReAct(Reason+Act)機能が組み込まれています。このブロックは、複雑なネットワーク運用に求められる、中核となる推論や意思決定能力を提供するために必要です。大規模言語モデル(LLM)機能とプランニング・コンポーネントを組み合わせ、短期的な運用のコンテキストと長期的に学習されたパターンの両方を維持しながら、複雑なタスクを管理可能なステップにまで細分化することができます。 Orchestration ブロックは、 Strands 、 LangGraph 、 CrewAI などのフレームワークを用いて、ワークフロー実行を調整し、異なるコンポーネント間の相互接続を管理します。このコンポーネントにより、複雑な多段ステップの処理を可能にしながら、様々なコンポーネント間をスムーズに連携できます。複数のエージェントが連携する必要がある場合は、タスクの分解、並列処理、エージェント間通信を管理することで実現します。 Memory ブロックは、エージェントの作業メモリとして機能し、短期的なセッションのコンテキストと、長期的に学習されたパターンの両方を保持します。これは、パーソナライズされ、かつ状況をくみ取った対話を実現するために必要です。 Agent Core Memory を利用した短期的・長期的なメモリ戦略を使い分けることで、複数のセッションにわたって関連する文脈を維持しながら、会話履歴やユーザーの好みを保存できます。これらの機能は、十分な情報に基づいた意思決定と、個々のユーザーに最適化された対話を行うために極めて重要です。 Deployment ブロックは、AgentCoreランタイムを介することで、組織のニーズに最適な実装アプローチを選択できます。フルマネージド型のインフラストラクチャや、カスタム実装ができる柔軟な基盤を提供します。 Evaluation ブロックは、パフォーマンスを評価するためのAI駆動型テスト フレームワーク を提供します。このブロックは内部的にLLMエージェント( evaluator) を実装しており、独自のエージェント( target) との会話をオーケストレーションして会話中の応答を評価します。このブロックは、様々なシナリオをシミュレートし、エージェントの応答を期待値と比較することで、品質を維持し、一貫した動作を保証します。 これらのビルティングブロックは、それぞれが独立しながらも、相互に連携できるように設計されています。まずは基本のブロックから始めて不可欠な機能を構築し、ニーズの拡大に合わせてより高度な要素を追加していくことが可能です。実装を成功させる鍵は、単に適切なブロックを揃えることだけではなく、それらをいかに組み合わせるかにあります。モジュールを選択・統合する際は、組織固有のニーズ、技術力、そして将来の成長計画を考慮して下さい。まずは最も差し迫った課題を解決するために必要最小限の要素から着手し、チームがシステムに慣れるにつれて、段階的に高度なモジュールを追加していくのが良いでしょう。重要なのは、各モジュール間のインターフェースをクリーンに保ちつつ、それらがシームレスに連携できるようにすることです。 ネットワーク運用エージェントの実装：理論から実践へ 本セクションでは、これまで述べてきた理論上の構成要素が、実際のシナリオを通じてどのように具体的な実装へ落とし込まれるかを説明します。対象シナリオは、図2に示す通り、バージニア北部リージョンでホストされている画像処理アプリケーションに影響を及ぼす、重大なネットワーク接続障害のトラブルシューティングです。 ExampleCorp の画像処理アプリケーション 図2: ExampleCorpの画像処理アプリケーション Amazon Route 53がDNSリクエストを処理します。画像処理アプリケーションのフロントエンドには、Application Load Balancer(ALB)を介してアクセスします。ALBは、バックエンドアプリケーションとして機能するサーバーレスのLambda関数にトラフィックを分散します。 Lambda関数は、ユーザーのリクエストに基づいてS3バケットから画像を取得し、レンダリングを行います。サーバーレスなアーキテクチャのため、手動によるスケーリングなしで、並列の画像レンダリング処理が可能です。 専用のDBサブネットに配置されたAmazon RDSには、利用データやプラットフォーム分析結果が保存されます。このデータベースは、プラットフォーム全体で画像がどのようにアクセスされ、利用されているかを追跡します。 レポートサーバーは、利用レポートやパフォーマンスメトリクスを生成します。適切なサブネットを経由したルーティングによりRDS内データに安全にアクセスし、基幹業務に影響を与えることなくプラットフォーム分析を行います。 ネットワーク構成にはVPC による分離を採用し、アプリケーションコンポーネントとレポートコンポーネントを切り離しています。AWS Transit GatewayがVPC 間のセキュアな通信を可能にし、専用サブネット(App、Reporting、DB)によって各サービス間に明確なセキュリティ境界を確立しています。 Amazon Bedrock AgentCore Runtimeによるトラブルシューティングの自動化 ワークフローは、図3に示す以下のステップに従います。 図3: Amazon Bedrock AgentCoreベースのアプローチ チャットクライアントはAmazon Cognito を介して認証され、ユーザーはJWTトークンを添えて質問を送信します。 AgentCoreランタイムはトークンを検証し、Claude 4.0 Sonnetモデルを活用して会話を処理します。 AgentCore Gatewayは、MCPプロトコルを通じてツールへの安全なアクセスを提供します。 AWS Lambda Targetは、適切な認証のもとでAWSサービスの操作を実行します。 AgentCore Identityは、ワークロードの認証とトークン交換を担います。 AgentCore Observabilityは、包括的なモニタリング、メトリクス、およびログ記録機能を提供します。 Amazon AgentCoreを使用したネットワーク接続トラブルシューティングのユースケースを実装するための詳細なデプロイ手順は、 sample-building-network-ops-agent-with-amazon-bedrock-agentcore にて公開されています。 まとめ Amazon Bedrockを搭載したインテリジェントなネットワーク運用エージェントの導入は、クラウドインフラストラクチャ管理への革新的なアプローチであり、大きなビジネス価値をもたらします。平均復旧時間 (MTTR)を数時間から数分に短縮し、24時間365日体制の自律診断を可能にすることで、運用コストを抑えつつビジネスを継続できます。 モジュール式のビルディングブロックを実装することで、組織がいかにAIを活用してネットワーク運用とインシデント解決を効率化できるかを示しました。これらのエージェントはAWSサービスと統合されており、Claude Sonnet 4などのFMを使用して複雑なネットワークシナリオを理解して診断を自動化し、堅牢なセキュリティ制御を維持しつつ状況に応じた推奨事項を提供します。 しかし、AIエージェントが常に最適なソリューションであるとは限りません。AIエージェントは、文脈の理解や自然言語での対話を必要とするような、複雑で多段階な操作には優れていますが、より日常的な運用タスクには従来のサーバーレスAPIベースのシステムの方が適している場合があります。例えば、セキュリティグループの定期的な更新や明確な入出力を持つスケジュールされたバックアップ操作は、直接のAPI呼び出しにより効率的に処理できるため、エージェントインフラストラクチャを使う場合のオーバーヘッドを回避できます。高度なトラブルシューティングシナリオにはエージェントを使用し、日常的な運用にはサーバーレス機能を維持するといったハイブリッドアプローチを採用することが、多くの組織の成功に繋がっています。 AIの機能は進化を続けていますが、導入を成功させるためには現実の状況に合わせる必要があります。まずはエージェントの機能が真に活かせる、具体的で価値の高いユースケースから始め、運用ニーズや複雑さに応じて段階的に拡張して下さい。このようなバランスの取れたアプローチを取ることで、組織はより回復力のある効率的なネットワーク運用を構築でき、チームはビジネス価値を高める戦略的な取り組みに集中できるようになります。 準備はいいですか？ 次にできることは以下の通りです： Amazon Bedrock AgentCore のドキュメント を確認する AWS GitHub リポジトリ でユースケースをチェックする Amazon Bedrock AgentCore や Strands Agents のワークショップで実践的に学ぶ （訳者注：リンク先システムの仕様が変更されています。 Builder Center のWorkshopsメニューより、キーワード検索にてご利用ください） 翻訳はSolutions Architectの田中が担当しました。原文は こちら です。

プロスポーツの世界では、わずかな差が勝敗を分けることが多いです。世界中のチームが、選手のパフォーマンス最適化、怪我の軽減、競争優位性の獲得のために、データを利用したインサイトに注目しています。 Catapult Sports は、プロチームがデータに基づいた意思決定を行えるよう支援するスポーツテクノロジー企業です。 AWS IoT サービスを活用することで、Catapult はチームがデータを収集・分析・活用する方法を変革しています。 Catapult は、プロチームが選手の健康を最適化し、怪我を減らし、人間運動科学に流用するために必要なデータ駆動型インサイトを提供しています。世界 24 拠点に 500 名以上のスタッフを擁し、 128 カ国 40 以上のスポーツにおいて 5,000 以上のプロチームにサービスを提供しています。これには NFL 、NHL 、イングランドプレミアリーグのトップフランチャイズも含まれます。 挑戦：エリートスポーツの要求に応える プロスポーツチームは高いプレッシャーの中で活動しています。試合や練習中にリアルタイムのインサイトを生成する選手モニタリング技術を利用しており、選手やコーチにパフォーマンス向上のための貴重な情報を提供しています。この技術を導入するにあたり、チームとしては、即座に導入できること、円滑なアップデート、国をまたいだリモート管理、そして重要な場面でのデバイス障害や設定ミスに対するゼロトレランス( 許容ゼロ ) つまり、重要な局面では必ず利用ができることを期待し導入します。 スポーツアナリティクスがますます高度化する中、チームは競争優位性をもたらす新機能、強化されたアルゴリズム、改善機能へのより迅速な利用も求められています。スポーツテクノロジープロバイダーにとっての課題は、迅速に革新するための俊敏性を維持しながら、エンタープライズグレードの信頼性を提供することです。 ソリューション：AWS IoT を基盤とした Vector 8 これらの厳しい要件を満たすために、Catapult は AWS IoT サービスを利用した次世代選手モニタリングソリューション「 Vector 8 」を開発しました。Vector 8 スイートは4つの主要コンポーネントで構成されています。 Vector 8 Tag : 選手がトレーニングや試合中に装着するコンパクトで頑丈なウェアラブルデバイスです。屋内外での精密な位置追跡、選手の動きやスポーツ固有のイベントのキャプチャ、サードパーティ Bluetooth センサーとの統合、超広帯域（UWB）通信をサポートします。バッテリー駆動時間は最大6時間です。 Vector 8 Dock : Vector 8 Tag を充電しデータを同期するために使用します。高速 Wi-Fi ダウンロードとクラウドへの直接データ同期を可能にし、30個の Vector 8 Tag の容量と並列アップロード機能により、データ取得までの時間を大幅に短縮します。 Vector 8 Receiver : Wi-Fi および Ethernet を通じて接続し、試合や練習セッション中のリアルタイム分析のためにデータをクラウドにストリーミングします。オンラインとオフラインの両方のワークフローをサポートし、パフォーマンス監視とトラブルシューティングのためのリアルタイム診断も提供します。 Vector 8 Relay : 400メートル範囲となる大規模施設にも適用範囲を広げ、複数の受信機が不要になります。そのため、展開を効率的かつコスト効果高くスケーラブルに実現できます。 リアルタイムパフォーマンスインサイト Vector 8 はコーチやスポーツサイエンティストに3種類のデータを提供します。 デバイスヘルスデータ – バッテリー状態や受信信号強度表示（RSSI）を含むライブテレメトリ、およびファームウェアバージョンなどのデバイス設定です。リアルタイムで送信され、重要な場面におけるデバイス故障前対応を可能にします。 ホットデータ – 10Hz でサンプリングされた試合中・練習中のライブデータです。加速度、速度、選手のポジショニング、心拍数モニタリングを含みます。コーチは iOS アプリで即座に可視化を確認でき、疲労した選手の交代や動きのパターンに基づく戦術調整など、その場での介入が可能です。 コールドデータ – 試合後の 100Hz でサンプリングされた生の慣性データです。ジャンプ、タックル、スローなどスポーツ固有の動きを自動検出するための機械学習（ML）推論に使用されます。 Catapult の AI 駆動アナリティクスは、1試合あたり選手1人につき 600 の特徴的な指標を生成でき、選手のパフォーマンス、ワークロード管理、怪我予防に関する深いインサイトを提供します。 Catapultのビデオ分析ソリューション との統合により、コーチは身体的出力データと実際の試合映像を連携させ、チームの分析・改善方法を変革できます。 AWS IoT アーキテクチャ Vector 8 の接続性の中核にあるのが AWS IoT Core です。AWS IoT Core は、認証、認可、転送中の暗号化、大規模なデバイス管理のためのスケーラブルで高可用性のクラウドエンドポイントを提供します。AWS IoT Core ルールエンジン は、高帯域幅・低遅延・堅牢なネットワークインフラストラクチャ上で、数千のデバイスからのデータを適切な AWS サービスにルーティングする統合ポイントとして機能します。 AWS IoT Greengrass は、Vector 8 のドックおよびVector 8 Receiver ソフトウェアアーキテクチャの基盤です。AWS IoT Greengrass は、Catapult が大規模なマルチプロセス IoT アプリケーションを構築、デプロイ、管理するのに役立つエッジランタイムとクラウドサービスの両方を提供します。 オープンソースのエッジランタイム は、コンポーネントのバージョニング、 依存関係の解決 、 ロギング 、 プロセス間通信 を処理しながら、Catapult の カスタムコンポーネント を AWS提供のコンポーネント 　と並行して管理します。 図1：Catapult Receiver によるデバイスヘルスデータとホットデータの取り込み Catapult は、リアルタイムデータストリーミングには Amazon Managed Streaming for Apache Kafka (Amazon MSK) を使用して、デバイスヘルステレメトリとライブ選手パフォーマンスデータをバッファリングおよび処理しています。 Amazon Elastic Container Service (Amazon ECS) では、バッテリーレベル、ファームウェアバージョン、その他の診断情報をリアルタイムで処理するコンテナ化されたアナリティクスサービスを実行します。 結果は Amazon API Gateway を通じて公開され、Catapult のウェブインターフェースやモバイルアプリに配信され、コーチや機器管理者がデバイスの状態を監視します。 図2：Catapult Dock によるコールドデータの取り込み 試合後のデータは Amazon Simple Storage Service (Amazon S3) に送信され、100Hz の Raw データが機械学習推論のために保存されます。30人の選手による2時間のセッションは30秒未満で Amazon S3 にアップロードできます。このデータ量は、典型的な NHL の試合における3,600万データポイントに相当します。 AWS IoT による主な利点と成果 シームレスなオンボーディング体験 Vector 8 は、チームが数分で稼働できるすぐに使える体験を提供します。Catapult のプリンシパルプロダクトマネージャーである Mike Lee は次のように説明いただきました。 「Vector 8 では、お客様は Catapult Vector iOS アプリをダウンロードし、ハードウェアを開封し、アプリ内のガイド付き登録フローに従うだけです。それだけで完了です。システム全体が10分以内に接続、設定、更新されます。」 この合理化されたセルフサービスのオンボーディング体験により、チームは機器を受け取ってから数分以内に選手の追跡を開始できます。技術サポートや複雑なセットアップは不要です。自動化されたプロセスがデバイスを正しく設定し、最新のファームウェアを即座に実行します。 高速なデバイスアップデート AWS IoT Greengrass デプロイメント による Over-the-Air（OTA）アップデートは、Catapult が顧客に新機能を提供する方法を変革しました。Mike Lee はこの改善事項を以下のように説明いただきました。 「Vector 8 における最大のゲームチェンジャーの一つは、アップデートの処理方法です。AWS IoT Greengrass による自動 OTA アップデートに移行することで、前世代と比較して最大32倍高速にデバイスを更新でき、お客様の時間と運用上の手間を大幅に節約しています。」 AWS IoT Greengrass デプロイメントを利用した自動アップデートに移行することで、Catapult は前世代では不可能だったフリート全体の一貫性を達成しました。また、Mike Lee はこの変化の重要性を以下のように説明いただきました。 「ウェアラブルデバイスフリートのほぼ全体が最新のファームウェアで稼働している状況は、これまでにありませんでした。これにより、数百件のサポートチケットを回避できるでしょう。」 このウェアラブルデバイスフリートの自動最新化手法は、すべての顧客が手動介入なしに、最新の機能、パフォーマンス改善、バグ修正の恩恵を自動的に受けられることを意味します。 迅速なイノベーションの実現 信頼性が高く高性能な Over-the-Air アップデート機能は、Catapult のファームウェアチームの運用方法を根本的に変えました。Mike Lee はこの変革を次のように説明いただきました。 「初めて、準備ができ次第、安全にデバイスに変更をプッシュできるようになりました。以前は顧客に届くまで数ヶ月かかっていたものが、数週間、あるいは数日で提供できるようになりました。特に新機能の反復やベータプログラムの実行時に顕著です。」 この加速により、Catapult は顧客のフィードバックに基づいて新機能を迅速に反復し、より速く価値を提供し、競合他社に先んじることができます。数ヶ月のリリースサイクルから週次、さらには日次のリリースへの移行は、同社のイノベーション方法における根本的な変化を表しています。 プロアクティブなデバイス管理と診断 AWS IoT セキュアトンネリング と AWS IoT Greengrass セキュアトンネリングコンポーネント の組み合わせにより、Catapult のサポートチームはワールドクラスのサービスを提供できます。サポートエンジニアは、利用顧客に同意いただければ、オンデマンドで Vector 8 Dock や Vector 8 Receiver への SSH セッションを確立できます。 AWS IoT Greengrass ログマネージャーコンポーネント により、デバイスログはほぼリアルタイムで Amazon CloudWatch に自動的に流れ、顧客が問題に気づく前にプロアクティブな問題の特定と解決を可能にします。 このリモートアクセス機能は、サポート業務をリアクティブなトラブルシューティングからプロアクティブなモニタリングへと変革します。以前は顧客とのアポイントメントのスケジューリングや複雑なファイル転送が必要だった問題が、数分で診断・解決できるようになりました。 インテリジェントな設定管理 AWS IoT Device Shadows により、Catapult は物理的な接続を必要とせずにクラウドからデバイス設定を管理できます。コーチが Catapult のモバイルアプリを通じて選手をデバイスに割り当てたり、パフォーマンスの閾値を更新したりすると、それらの設定変更は自動的にクラウドに同期され、登録されたすべてのVector 8 Dock に伝播されます。Vector 8 Tag いずれかのVector 8 Dock に置かれると、最新の設定を受信し、デバイスフリート全体の一貫性が確保されます。 この機能により、数千の手動デバイスステージング作業が不要になりました。交換デバイスは最初の接続時に正しい顧客設定を自動的に受信し、ハードウェアが交換された場合でもチームの運用を維持する真のホットスワップ機能を実現しています。 今後の展望 クラウド接続と自動デバイス管理の基盤が整ったことで、Catapult はいくつかの将来のイノベーションを検討しています。 クラウドへのライブデータストリーミング – 現在、10Hz のライブデータはサイドラインの iOS アプリにのみストリーミングされています。このデータをクラウドにストリーミングすることで、より多くの試合中アナリティクスが可能になり、コーチやスポーツサイエンティストのリモートアクセスが実現します。 エッジ機械学習推論 – 現在、ほとんどの ML 推論は試合後にクラウドで行われています。Catapult は、試合や練習セッション中により多くのリアルタイムインサイトを提供するために、Vector 8 Receiver や Vector 8 Tag 上でのエッジへの推論のシフトを調査しています。堅牢な OTA アップデートメカニズムにより、デプロイされたモデルのほぼ継続的な反復と強化が可能です。 AI 駆動のチームアナリティクス – チーム全体の Vector 8 Tag データを分析し、高度な AI モデルを使用してチームの動き、グループダイナミクス、戦術パターンを理解します。 自然言語ビデオ検索 – マルチモーダル埋め込みモデルなどの AI を使用して、 ビデオコンテンツの自然言語検索と理解 を可能にします。これにより、コーチが特定のプレーや状況を見つけるのに役立ちます。 まとめ Catapult の Vector 8 プラットフォームは、AWS IoT サービスがスポーツテクノロジー企業にエンタープライズグレードのソリューションをコンシューマーグレードのシンプルさで提供することを可能にする方法を実証しています。10分でのオンボーディング、32倍高速なアップデート、フリートの97%が最新ファームウェアで稼働という成果により、Catapult は選手モニタリング技術の新たな基準を打ち立てました。 これらの強化により、Catapult はトラブルシューティングを超えて戦略的な前進に向かうことができます。エンジニアリングチームは迅速に反復でき、サポートチームはより迅速に問題を解決でき、顧客は最も重要なこと、つまり選手のパフォーマンスの最適化と試合での勝利に集中できます。 プロスポーツがますますデータ駆動型になる中、Catapult の AWS IoT 搭載プラットフォームは、チームがトレーニング、競技、成功する方法の変革をリードし続けるための位置づけを確立しています。 詳細情報 AWS IoT サービスとそれがコネクテッドデバイスビジネスをどのように変革できるかについて詳しくは、 aws.amazon.com/iot .をご覧ください。Catapult について詳しくは、 catapult.com をご覧ください。 このユースケースをさらに深く知るには、「 AWS re:Invent 2025 – Peak Performance: IoT Innovation in Professional Sports (SPF301) 」の録画をご覧ください。 この記事は Greg Breen, Mike Garbuz, and Farzad Khodadadi, Mike Lee によって書かれた The data behind the win: How Catapult and AWS IoT are transforming pro sports の日本語訳です。この記事は ソリューションアーキテクトの川﨑が翻訳しました。 著者について Greg Breen Greg Breen Amazon Web Services のシニアIoTスペシャリストソリューションアーキテクト。オーストラリアを拠点に、アジア太平洋地域の顧客が IoT ソリューションを構築するのを支援しています。組み込みシステムの豊富な経験を持ち、製品開発チームがデバイスを市場に投入するのを支援することに特に関心があります。 Mike Garbuz Mike Garbuz Amazon Web Services のスポーツソリューションアーキテクト。オーストラリアを拠点に、オーストラリア全土のスポーツ顧客が AWS サービスを最大限に活用できるよう支援しています。機械学習およびデータ＆アナリティクスの経験を持ち、AWS サービスの活用を通じて顧客がデータを最大限に活用できるよう導いています。 Farzad Khodadadi Farzad Khodadadi Catapult のリードプリンシパルソフトウェアエンジニア。15年以上にわたりエンタープライズスケールのクラウドネイティブ技術ソリューションの提供と長期的なエンジニアリング戦略の策定に携わっています。入社以来、Catapult の IoT プラットフォームの設計と提供に技術的リーダーシップを発揮し、ビジョンをスケーラブルでビジネスに即した機能へと転換しています。IoT への情熱により、複数の製品やチームにわたる IoT の採用を加速させ、Catapult のより広範なデジタルおよび製品戦略を支えながら新たな価値の流れを実現しています。 Mike Lee Mike Lee Catapult のプリンシパルプロダクトマネージャー。オーストラリア・メルボルンを拠点としています。スポーツテクノロジーで14年以上、プロスポーツでスポーツサイエンティストとして5年間の直接的な経験を持ち、深いドメイン知識と製品リーダーシップを組み合わせて、チーム、選手、パフォーマンススタッフに実世界の価値を提供する技術を構築しています。 <!-- '"` -->

今から 20 年前の 2006 年 3 月 14 日、 Amazon Simple Storage Service (Amazon S3) は、 「新着」 ページに掲載されたわずか 1 段落のシンプルな発表とともにひっそりとリリースされました: Amazon S3 はインターネットのためのストレージです。デベロッパーがウェブスケールコンピューティングをより簡単に利用できるように設計されています。Amazon S3 は、ウェブ上のどこからでも、いつでも、どのような量のデータでも保存および取得するために使用できるシンプルなウェブサービスインターフェイスを提供します。Amazon が自社のウェブサイトのグローバルなネットワークを運営するために使用している、スケーラビリティ、信頼性、高速性に優れた低コストのデータストレージインフラストラクチャを、すべてのデベロッパーが利用できるようにします。 Jeff Barr 氏のブログ記事 もわずか数段落で、カリフォルニアで開催されるデベロッパー向けイベントに向かう飛行機に乗る前に書かれたものでした。コード例はありませんでした。デモもありませんでした。大々的な宣伝もありませんでした。当時、このリリースが私たちの業界全体を形づくることになろうとは、誰も想像していませんでした。 初期段階: ただ機能するビルディングブロック S3 の中核には、オブジェクトを保存する PUT と、後でそれを取得する GET という、2 つのシンプルなプリミティブがあります。しかし、真のイノベーションは、その背後にある哲学にありました。すなわち、差別化につながらない手間のかかる作業を処理するビルディングブロックを作成することで、デベロッパーがより高度な作業に注力できるようにするということです。 S3 は、サービス開始当初から、今日でも変わっていない 5 つの基本原則をガイドとしてきました。 セキュリティ は、お客様のデータがデフォルトで保護されていることを意味します。 耐久性 は、イレブンナイン (99.999999999%) の可用性を実現するように設計されており、当社はロスレスになるように S3 を運営しています。 可用性 は、障害は常に存在しており、対処される必要があるという前提に基づき、あらゆるレイヤーに組み込まれるように設計されています。 パフォーマンス は、事実上あらゆる量のデータを劣化なく保存するために最適化されています。 伸縮性 とは、データの追加や削除に応じてシステムが自動的に拡張および縮小し、手動での介入が不要であることを意味します。 これらの原則が適切に機能することで、サービスは非常にわかりやすいものとなり、ほとんどのお客様はこれらの概念の複雑さについて考える必要はありません。 今日の S3: 想像を超えた成長 S3 は 20 年間にわたって、想像を絶する規模に成長を遂げながらも、その核となる基本理念を堅持してきました。 S3 が最初にリリースされたとき、3 つのデータセンターにまたがる 15 のラック内の約 400 のストレージノードで、合計約 1 ペタバイトのストレージ容量と合計 15 Gbps の帯域幅を提供していました。当社は、最大オブジェクトサイズを 5 GB として、数百億個のオブジェクトを保存できるようにこのシステムを設計しました。当初の料金は 1 ギガバイトあたり 15 セントでした。 S3 は現在、数百エクサバイト規模のデータを対象として、39 の AWS リージョン内の 123 のアベイラビリティゾーンで、数百万のお客様のために、500 兆個超のオブジェクトを保存し、世界中で毎秒 2 億件超のリクエストを処理しています。 最大オブジェクトサイズは 5 GB から 50 TB へと、1 万倍に増加しました。数千万台すべての S3 ハードドライブを積み重ねると、国際宇宙ステーションまで届き、ほぼ往復できるほどの高さになります。 S3 はこのような驚異的な規模を支えるまでに成長しましたが、お客様が支払う料金は低額になりました。今日、AWS が課金しているのは、 1 ギガバイトあたり 2 セント をわずかに上回る料金です。これは、2006 年のリリースから見ると、約 85% 低い料金です。同時に、ストレージ階層を使用してストレージにかかる支出をさらに最適化する方法も継続的に導入しています。例えば、 Amazon S3 Intelligent-Tiering を利用することで、 Amazon S3 Standard と比較して、お客様全体で合計 60 億 USD 超のストレージコストを削減しています。 過去 20 年間にわたって、 S3 API はストレージ業界全体で採用され、基準点として利用されてきました。現在、複数のベンダーが S3 互換のストレージツールとシステムを提供しており、同じ API パターンと慣例を実装しています。これは、S3 向けに開発されたスキルやツールが他のストレージシステムにも応用できることが多く、より広範なストレージ環境へのアクセスが容易になることを意味します。 このような成長や業界での普及にもかかわらず、おそらく最も注目すべき成果は、2006 年に S3 向けに作成したコードが、現在も変更されることなく機能していることです。お客様のデータは 20 年間のイノベーションと技術的な進歩を経てきました。当社は、複数世代のディスクとストレージシステムにわたって、インフラストラクチャを移行してきました。リクエストを処理するためのコードはすべて書き直されています。しかし、お客様が 20 年前に保存したデータは今日でも利用可能であり、当社は API の完全な後方互換性を維持しています。これは、常に「問題なく機能する」サービスを提供するという当社のコミットメントです。 規模を支えるエンジニアリング S3 をこれほど大規模に実現できるのはなぜでしょうか? その答えは、エンジニアリングにおける継続的なイノベーションです。 以下の内容のほとんどは、AWS の VP of Data and Analytics である Mai-Lan Tomsen Bukovec と、 The Pragmatic Engineer である Gergely Orosz 氏との対談に基づいています。 詳細なインタビュー では、より深く理解したい方のために、技術的な詳細をさらに掘り下げています。以下の段落では、いくつかの例をご紹介します: S3 の耐久性の中心にあるのは、フリート全体ですべてのバイトを継続的に検査するマイクロサービスのシステムです。これらの監査サービスはデータを監視し、劣化の兆候を検出した瞬間に修復システムを自動的にトリガーします。S3 はロスレスになるように設計されています。イレブンナインという設計目標は、レプリケーション係数と再レプリケーションフリートの規模を反映したものですが、システムはオブジェクトが失われないように構築されています。 S3 のエンジニアは、本番において 形式手法と自動推論 を用いて、数学的に正確性を証明しています。エンジニアがインデックスサブシステムにコードをチェックインすると、自動証明によって一貫性が損なわれていないことが検証されます。この同じアプローチは、 リージョン間レプリケーション や アクセスポリシー の正確性を証明します。 AWS は過去 8 年間にわたって、S3 リクエストパスのパフォーマンスクリティカルなコードを Rust で段階的に書き換えてきました。Blob の移動とディスクストレージは書き換えられ、現在は他のコンポーネントで作業が積極的に進められています。生のパフォーマンスだけでなく、Rust の型システムとメモリ安全性の保証により、コンパイル時にバグのクラス全体を排除できます。これは、S3 の規模と高い正確性の要件を満たす必要がある運用において不可欠な特性です。 S3 は「スケールはメリットである」という設計哲学に基づいて構築されています。 エンジニアは、スケールが拡大することで、すべてのユーザーにとって性能が向上するようにシステムを設計します。S3 の規模が大きくなるほど、ワークロード間の相関性が低下し、すべてのユーザーにとって信頼性が高まります。 今後の展望 S3 のビジョンは、単なるストレージサービスを超え、すべてのデータおよび AI ワークロードの普遍的な基盤となることです。当社のビジョンはシンプルです。すなわち、あらゆる種類のデータを S3 に一度保存すれば、専用システム間でデータを移動させることなく、直接そのデータを利用できる、というものです。このアプローチにより、コストが削減され、複雑さが解消され、同じデータの複数のコピーを作成する必要がなくなります。 近年の注目すべきリリースをいくつかご紹介します: S3 Tables – 時間が経過する中で、クエリ効率を最適化し、ストレージコストを削減する、自動メンテナンスを備えたフルマネージド Apache Iceberg テーブル。 S3 Vectors – セマンティック検索と RAG のためのネイティブベクトルストレージ。インデックスあたり最大 20 億のベクトルをサポートし、クエリレイテンシーは 100 ミリ秒未満です。わずか 5 か月間 (2025 年 7 月～12 月) で、25 万を超えるインデックスを作成し、400 億を超えるベクトルを取り込み、10 億件を超えるクエリを実行しました。 S3 Metadata – データの即時検出のための一元化されたメタデータ。カタログ化のために大規模なバケットを再帰的にリストする必要がなくなり、大規模データレイクに関するインサイトの取得までの時間を大幅に短縮します。 これらの各機能は S3 のコスト構造で利用できます。従来は高コストのデータベースや専用システムが必要だった複数のデータタイプを、大規模かつ経済的に処理できます。 1 ペタバイトから数百エクサバイトに。1 ギガバイトあたり 15 セントから 2 セントに。シンプルなオブジェクトストレージから、AI と分析の基盤へ。このような変化の中にあっても、当社の 5 つの基本原則、すなわち、セキュリティ、耐久性、可用性、パフォーマンス、伸縮性は変わっていません。そして、2006 年に書かれたお客様のコードは、今日も機能します。 Amazon S3 における次の 20 年間のイノベーションに祝意を表したいと思います。 – seb 原文は こちら です。

本記事は 2026 年 3 月 16 日 に公開された「 Securely connect Kafka clients running outside AWS to Amazon MSK with IAM Roles Anywhere 」を翻訳したものです。 AWS 外 (オンプレミス環境や他のクラウド) で動作する Kafka クライアントは、コードベースやサーバー設定に長期 IAM ユーザーのアクセスキーを含める必要があります。長期認証情報が漏洩すると、AWS アカウントへの不正アクセスにつながるリスクがあります。 本記事では、 AWS IAM Roles Anywhere を使用して、X.509 証明書によるクライアントアプリケーションの一時的な AWS セキュリティ認証情報を取得し、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) クラスターとセキュアに通信する方法を紹介します。本記事のソリューションは、Amazon MSK Provisioned と Serverless の両方のクラスターに対応しています。 AWS IAM Roles Anywhere の概要 AWS Identity and Access Management (IAM) Roles Anywhere を使用すると、サーバー、コンテナ、アプリケーションなど AWS 外で動作するワークロードに対して、IAM の一時的なセキュリティ認証情報を取得できます。 IAM Roles Anywhere を使用すると、AWS アプリケーションと同じ IAM ポリシーとロールを AWS 外のワークロードでも利用できます。AWS 外で動作する Kafka クライアントの長期認証情報を管理する必要がなくなります。プロファイルに 1 つ以上のロールを関連付け、IAM Roles Anywhere でそのロールを引き受けられるようにすると、認証局 (CA) が発行したクライアント証明書で AWS へのリクエストを安全に開始できます。アプリケーションは一時的な認証情報を取得し、AWS 環境にアクセスできるようになります。 Amazon MSK の IAM アクセスコントロールを使用すると、追加コストなしで Amazon MSK クラスターの認証と認可の両方を管理できます。認証と認可に別々のメカニズムを使用する必要がなくなります。mutual TLS や SASL/SCRAM 認証/認可を使用する特別な要件がない限り、Amazon MSK では IAM アクセスコントロールの使用をお勧めします。 以降では、AWS IAM Roles Anywhere で MSK クラスターに接続するセキュアな Kafka クライアントマシンの実装手順を説明します。 ソリューションの概要 ソリューションのアーキテクチャを次の図に示します。 アーキテクチャのフローは次のとおりです。 クライアントマシンが X.509 証明書を使用して AWS IAM Roles Anywhere エンドポイントにセッショントークンをリクエストします。 IAM Roles Anywhere が証明書を検証し、STS から一時的なセッショントークンを取得してクライアントマシンに返します。 Amazon MSK Provisioned の場合、MSK クライアントマシンは AWS VPN または AWS Direct Connect 経由で VPC 内の AWS Transit Gateway または AWS Network Load Balancer に接続します。詳細については、 Amazon MSK へのセキュアな接続パターン を参照してください。 Amazon MSK Serverless の場合、MSK クライアントマシンは AWS VPN または AWS Direct Connect 経由で VPC 内の インターフェイス VPC エンドポイント に接続します。詳細については、 オンプレミスネットワークから Amazon MSK Serverless に接続する を参照してください。 Amazon MSK Serverless では、インターフェイスエンドポイントはアカウント内のプライベート IP アドレスを持つ 1 つ以上の Elastic Network Interface の集合です。MSK Serverless サービスへのトラフィックのエントリポイントです。 前提条件 本記事では、MSK Serverless クラスターとクライアントマシンの作成に慣れていることを前提としています。以下のタスクが完了していることを想定しています。 Amazon MSK Serverless クラスターの作成 または Amazon MSK Provisioned クラスターの作成 オンプレミスのデータセンターまたは別の AWS アカウントの VPC に MSK クライアントマシンを作成 オンプレミスと Amazon MSK Serverless クラスター間のネットワーク接続の確立 、または オンプレミスと Amazon MSK Provisioned クラスター間のネットワーク接続の確立 AWS IAM Roles Anywhere の設定 オンプレミスの Kafka クライアントマシンで IAM Roles Anywhere を有効にするには、トラストアンカーとプロファイルの 2 つを設定する必要があります。トラストアンカーは、Roles Anywhere と認証局間の信頼関係を確立します。証明書認証で IAM ロールの認証情報を取得する際に使用されます。プロファイルは、Roles Anywhere での認証成功後に適用される権限セットです。 ステップ 1: CA の生成 X.509 証明書は、クライアントマシンと Roles Anywhere 間の通信に不可欠です。任意の公開鍵基盤 (PKI) プラットフォームで認証局 (CA) を構築できます。 独自の X.509 クライアント証明書を生成する場合は、 外部認証局を使用した IAM Roles Anywhere の手順を参照してください。 この例では、簡略化のため AWS Private CA を使用します。 AWS Private CA コンソール に移動します。 ルート CA の作成 CA タイプ オプションで Root を選択し、組織名と組織単位名を入力します。 キーアルゴリズムに デフォルトの RSA 2048 を選択します。 Create CA ボタンを選択してプライベート CA を生成し、証明書をインストールします。 下位 CA の作成 CA タイプオプションで Subordinate を選択します。 キーアルゴリズムに デフォルトの RSA 2048 を選択します。 Create CA ボタンを選択します。 下位 CA から CSR を取得し、ルート CA で署名します。 この CA は、IAM Roles Anywhere への証明書発行に使用します。 よりセキュアで自動更新される AWS Private CA の生成については、 CA の作成手順 と CA 階層の構築方法 を参照してください。 ステップ 2: アンカーの設定 Roles Anywhere コンソールに移動し、 Create a trust anchor ページを開きます。 トラストアンカーの名前を入力し、ステップ 1 で作成した プライベート CA を選択します。独自の外部 CA を使用する場合は、 External certificate bundle オプションを選択し、必要な証明書バンドルを指定します。 create a trust anchor ボタンを選択してプロセスを完了します。 ステップ 3: IAM Roles Anywhere を信頼するロールの作成と設定 IAM Roles Anywhere での認証後にオンプレミスの Kafka クライアントマシンが引き受けるロールを作成します。 ロールの信頼ポリシーには以下を含める必要があります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "rolesanywhere.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:SetSourceIdentity", "sts:TagSession" ], "Condition": { "StringEquals": { "aws:PrincipalTag/x509Subject/CN": "specific-certificate-common-name" } } } ] } このデモでは、以下のポリシーを作成してロールにアタッチします。 { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kafka-cluster:Connect", "kafka-cluster:AlterCluster", "kafka-cluster:DescribeCluster" ], "Resource": [ "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:cluster/&lt;Cluster-name&gt;/&lt;Cluster-identifier&gt;" ] }, { "Effect": "Allow", "Action": [ "kafka-cluster:CreateTopic", "kafka-cluster:DescribeTopic", "kafka-cluster:WriteData", "kafka-cluster:ReadData", "kafka-cluster:AlterGroup", "kafka-cluster:DescribeGroup" ], "Resource": [ "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:cluster/ &lt;Cluster-Name&gt;/&lt;Cluster-identifier&gt;", "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:topic/msk-&lt;Cluster-Name&gt;/&lt;Cluster-Identifier&gt;/&lt;Topic-Name&gt; ", "arn:aws:kafka:&lt;Region&gt;:&lt;Account-ID&gt;:group/&lt;Cluster-Name&gt;/&lt;Cluster-Identifier&gt;/&lt;Group-Name&gt;" ] } ] } ステップ 4: プロファイルの設定 Roles Anywhere コンソール に戻ります。 Profiles で Create a profile を選択します。 プロファイルの名前を入力します。 ステップ 3 で作成したロールを選択し、Roles Anywhere プロファイルを作成します。 ステップ 5: クライアントマシンのテスト トラストアンカーとプロファイルを作成して Roles Anywhere のセットアップが完了したので、次はクライアントマシンと Roles Anywhere の通信をテストします。セッショントークンを取得し、MSK ブローカーとの通信を確立します。 ステップ 1 で作成した CA から プライベート証明書をリクエスト し、クライアントマシンで使用する クライアント証明書をエクスポート します。 .pem ファイルを作成し、すべての証明書の内容をファイル (例: private_key.pem) にコピーして、以下のコマンドで復号化した証明書を生成します。 openssl rsa -in private_key.pem -out decrypted_private_key.pem 認証情報ヘルパーをダウンロード し、署名ヘルパーツールでクライアントマシンからの動作を確認します。Roles Anywhere のトラストアンカーとプロファイルの ARN、および IAM で作成したロールの ARN を指定します。 ./aws_signing_helper credential-process \ --certificate /path/to/certificate.pem \ --private-key /path/to/decrypted_private_key.pem \ --trust-anchor-arn &lt;TA_ARN&gt; \ --profile-arn &lt;PROFILE_ARN&gt; \ --role-arn &lt;Roles_ARN&gt; \ --region &lt;Region&gt; IAM Roles Anywhere からセッション認証情報を正常に取得できるはずです。 セットアップの成功を確認したら、 ~/.aws/config ファイルを更新または作成します。オンプレミスサーバーの無人アクセスを有効にするため、署名ヘルパーを credential_process として追加します。 [default] credential_process = ./aws_signing_helper credential-process --certificate /path/to/certificate.pem --private-key /path/to/decrypted_private_key.pem --trust-anchor-arn &lt;TA_ARN&gt; --profile-arn &lt;PROFILE_ARN&gt; --role-arn &lt;Roles_ARN&gt; --region &lt;Region&gt; すべてのステップが完了すると、Kafka クライアントが MSK ブローカーと通信できるようになります。 ./kafka-topics.sh --create \ --bootstrap-server &lt;BOOTSTRAP_SERVER&gt; \ --command-config &lt;Command Config File&gt; \ --replication-factor &lt;Replication Factor&gt; \ --partitions &lt;Number of Partitions&gt; \ --topic &lt;Topic Name&gt; クリーンアップ 不要なコストを避けるには、IAM ロール、プロファイル、トラストアンカー、ポリシー、ACM でリクエストした証明書、AWS Private CA で作成した証明書を削除してください。 aws delete-role --role-name &lt;value&gt; aws delete-profile --profile-id &lt;value&gt; aws delete-trust-anchor --trust-anchor-id &lt;value&gt; aws acm delete-certificate --certificate-arn &lt;value&gt; aws acm-pca revoke-certificate --certificate-authority-arn &lt;value&gt; --certificate-serial &lt;value&gt; --revocation-reason &lt;value&gt; aws acm-pca delete-certificate --certificate-authority-arn &lt;value&gt; --certificate-serial &lt;value&gt; まとめ 本記事では、AWS IAM Roles Anywhere を使用して、AWS 外のクライアントマシンから MSK ブローカーにアクセスするための一時的なセッショントークンを生成する方法を紹介しました。IAM Roles Anywhere の導入により、AWS 外から MSK に接続する Kafka クライアントのセキュリティ体制が強化され、厳格なセキュリティ要件があるお客様も安心して MSK を導入できます。 ご質問は、 AWS re:Post で新しいスレッドを作成するか、 AWS サポート にお問い合わせください。 著者について Ankit Mishra Ankit は、Amazon Web Services のシニアソリューションアーキテクトです。セキュアでスケーラブル、信頼性が高く、コスト効率の良いクラウドソリューションの設計と構築を支援しています。仕事以外では、妻と幼い娘と過ごす時間を楽しんでいます。 Tony Anastasio Tony は、AWS の Global Healthcare チームのシニアソリューションアーキテクトマネージャーです。データの相互運用性、AI ソリューション、セキュアなクラウド基盤にわたるイノベーションを推進するアーキテクトチームをリードし、業界最大級のヘルスケア組織を支援しています。余暇には、妻と 2 人の子供と過ごす時間を楽しんでいます。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデータ &amp; アナリティクススペシャリストです。高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースのソリューションの設計と構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。直前のご案内になりますが、3 月 25 日（水）に「 AWS での Claude Code の買い方・使い方 」という Claude Code を AWS 上で活用する手段や買い方をご紹介するイベントが開催されます。また翌日の 3 月 26 日（木）には「 Amazon Quick で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。ご興味がある方はぜひご参加ください！ 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集中ですのでよろしくお願いします。 それでは 3月 9 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI事例ブログ「 寄稿： 三菱電機が挑む製造業の商談変革 – AWS で実現した商談支援サービス「Memory Tech」 」 三菱電機 名古屋製作所が、製造業の商談現場で発生する口頭コミュニケーションの認識齟齬という課題を解決するために、AI を活用した商談支援サービス「Memory Tech」を AWS 上で開発した事例が紹介されています。Memory Tech は Web ブラウザやスマートフォンで商談の音声を録音するだけで、Amazon Bedrock の生成 AI が 2 分以内に構造化された議事録を自動生成するサービスで、AWS Amplify Gen 2 を中核としたサーバーレスアーキテクチャにより、少人数のチームでも迅速な開発と 1,000 名超のユーザーに対応する安定運用を実現しています。生成 AI を活用するユーザーにとっては、Amazon Bedrock 上で Anthropic Claude と Amazon Nova を用途に応じて使い分けることでコスト最適化と応答速度を両立しており、現場の業務習慣を変えずに AI の力で業務改善を図る実践的な活用事例として参考になります。 AWS生成AI事例ブログ「 【寄稿】「12時間で PoC が完成」― サミット株式会社の情報システム部門が AI コーディングアシスタント Kiro で実現した、圧倒的スピードの内製開発 」 スーパーマーケットチェーンのサミット株式会社が、AI コーディングアシスタント「Kiro」を活用して情報システム部門による内製開発を加速させた事例が紹介されています。従来であれば外部委託で 3 か月・数百万円規模のコストがかかる店舗データ分析ダッシュボードの PoC を、Kiro の Spec-driven Development 機能を活用して一人の担当者がわずか 12 時間で完成させるなど、開発スピードの大幅な向上を実現しました。生成 AI を活用した開発に取り組むユーザーにとっては、セッション情報の管理やステアリングの設定といった Kiro を効果的に使いこなすための実践的なノウハウに加え、レガシーシステムのリバースエンジニアリングやパートナーとの協業モデルの変革など、AI コーディングアシスタントの活用範囲を広げるヒントが得られる内容です。 ブログ記事「 「フィジカル AI 開発支援プログラム by AWS ジャパン」キックオフイベントを開催しました 」 AWS ジャパンが、フィジカル AI の開発を支援する約 6 ヶ月間のプログラムのキックオフイベントを開催し、採択企業によるピッチや Amazon Robotics の事例紹介が行われた様子を報告しています。このプログラムでは、ソリューションアーキテクトによる技術支援、AWS クレジットの提供に加え、プロトタイピングを専門とする Prototyping &amp; Cloud Engineering（PACE）チームが開発する Physical AI Scaffolding Kit（PASK）によるトレーニング環境のサンプル提供など、データ収集からモデル学習・実機デプロイまでの一連のパイプライン構築を包括的にサポートします。生成 AI を活用するユーザーにとっては、Vision-Language-Action（VLA）モデルなどのロボット基盤モデル開発を Amazon SageMaker HyperPod 上で実行する具体的なアプローチや、日本のものづくりの強みと生成 AI を融合させるフィジカル AI エコシステムの最新動向を知ることができる内容です。 ブログ記事「 月刊 AWS 製造 2026年3月号 」 今月の月刊 AWS 製造では「Agentic AI × 製造業」を特集しており、BMW Group が Amazon Bedrock AgentCore と Strands Agents を活用してペタバイト規模のデータからインサイトを抽出する品質管理の事例や、Amazon Bedrock AgentCore による調達ワークフローの自動化、メック株式会社が Amazon Bedrock AgentCore Runtime と Amazon S3 Vectors で研究業務を効率化した事例など、製造業の各領域で Agentic AI を実践的に活用するコンテンツが充実しています。さらに、Toyota Motor Europe が Amazon Bedrock でレガシーメインフレームのドキュメント自動生成に取り組んだ事例や、三菱電機が Kiro と GitLab で開発ワークフローを標準化した事例など、生成 AI を活用した製造業の業務改善事例も多数紹介されています。製造業に関わる方にとって、生成 AI の具体的な活用パターンをまとめて把握できる内容ですので、ぜひご覧ください。 ブログ記事「 エンタープライズガバナンス：MCP サーバーとモデルの制御 」 AI コーディングアシスタント「Kiro」に、エンタープライズ向けの 2 つの新しいガバナンス機能がリリースされました。1 つ目は MCP サーバーレジストリで、管理者が承認済みの MCP サーバーを JSON 形式の許可リストとして定義し、開発者が接続できるサーバーを一元管理できるようになります。2 つ目はモデルガバナンス機能で、組織内の開発者が利用できる AI モデルを管理者が制御でき、特にデータレジデンシー要件がある場合にグローバルクロスリージョン推論を使用する実験的モデルを無効化するといった対応が可能になります。生成 AI を活用した開発を組織的に推進するユーザーにとっては、セキュリティ・コンプライアンス要件を満たしながら AI コーディングツールの導入を拡大するための具体的なアプローチとして参考になる内容です。 サービスアップデート Kiro IDE 0.11 のリリース Kiro IDE 0.11 がリリースされました。エンタープライズチーム向けに MCP サーバーアクセスとモデル利用のガバナンス機能が追加され、管理者が承認済みの MCP サーバーや利用可能な AI モデルを一元管理できるようになりました。また、チャットにドキュメント添付機能が追加され、PDF、CSV、DOC、XLSX、HTML、Markdown など多様なフォーマットのファイルをチャット入力にドラッグ＆ペーストして、1 メッセージあたり最大 5 ファイルまでテキストや画像と組み合わせて AI に読み込ませることができます。生成 AI を活用した開発に取り組むユーザーにとっては、ドキュメントを直接チャットに渡して内容を推論させられるようになったことで、仕様書やデータファイルを参照しながらのコーディング作業がより効率的になるアップデートです。 AI アシスタントによる構成管理を実現する新しい LZA MCP サーバー Landing Zone Accelerator on AWS（LZA）の構成管理を AI アシスタントとの自然言語の対話で行える MCP サーバーがオープンソースとして公開されました。この LZA MCP サーバーは 20 種類の専用ツールを備えており、複数の LZA バージョンにまたがるドキュメント検索、構成管理、パイプライン監視、デプロイ失敗時の原因分析といった、これまで手作業で時間のかかっていた作業を効率化できます。Kiro、Amazon Q Developer、Claude Code などの IDE と互換性のあるコンテナ化された MCP エンドポイントとして動作するため、生成 AI を活用した開発環境を構築しているユーザーにとっては、マルチアカウント環境のガバナンス設定を自然言語で対話しながら管理できる実用的なツールとして活用が期待できます。 Amazon Bedrock AgentCore Memory が長期メモリのストリーミング通知をサポート Amazon Bedrock AgentCore Memory に、長期メモリのストリーミング通知機能が追加されました。長期メモリはエージェントとのやり取りからインサイトを抽出し、次回以降のインタラクションでパーソナライズされた体験を提供する機能ですが、これまでメモリの変更を検知するにはポーリング処理を自前で実装する必要がありました。今回のアップデートにより、メモリレコードの作成・変更時に Amazon Kinesis へプッシュ通知がストリーミングされるようになり、後続のワークフロー起動やアプリケーション状態の更新、メモリ変更の監査を自動化できるようになります。生成 AI エージェントを開発するユーザーにとっては、ポーリングロジックの実装が不要になることでアーキテクチャが簡素化され、よりリアルタイム性の高いパーソナライズ体験の構築が可能になるアップデートです。本機能は東京リージョンを含む 15 の AWS リージョンで利用可能です。 Amazon Bedrock が初回トークンレイテンシーとクォータ消費のオブザーバビリティをサポート Amazon Bedrock に 2 つの新しい Amazon CloudWatch メトリクスが追加されました。TimeToFirstToken はストリーミング API でリクエスト送信から最初のトークン受信までのレイテンシーを測定するメトリクスで、クライアント側の実装なしにレイテンシー劣化の監視や SLA ベースラインの設定が可能になります。EstimatedTPMQuotaUsage はキャッシュ書き込みトークンや出力バーンダウン乗数を含む Tokens Per Minute（TPM）のクォータ消費量を追跡するメトリクスで、クォータ上限に達する前にアラームを設定してレート制限を事前に回避できます。生成 AI アプリケーションを運用するユーザーにとっては、追加費用や API 変更なしに Amazon CloudWatch で推論パフォーマンスとクォータ使用状況を可視化できるようになり、本番環境の安定運用に役立つアップデートです。 Amazon Connect が AI を活用したマネージャーアシスタント機能を発表（プレビュー） Amazon Connect に、コンタクトセンターのマネージャーが自然言語で業務に関する質問をすると即座に回答を得られる、AI を活用したアシスタント機能がプレビューとして発表されました。エージェントのスケジューリング、セルフサービス体験、パフォーマンス評価を含む 150 以上の Amazon Connect メトリクスに対して自然言語でクエリでき、これまで手作業で数時間かかっていたデータ収集を数秒で完了できるようになります。さらに、サービスレベル目標の達成が危ぶまれるキューの特定や具体的な改善アクションの提案など、根本原因の診断も行えるため、生成 AI を活用してカスタマーサービスの品質向上に取り組むユーザーにとって、運用の意思決定を加速させる実用的なアップデートです。 Amazon Quick Suite がチャットパーソナライゼーションのためのユーザー設定機能をリリース Amazon Quick Suite に、チャット体験をユーザーごとにカスタマイズできるユーザー設定（User Preferences）機能が追加されました。チャットパネルのレイアウト設定、デフォルトのチャットエージェントやナレッジスコープの事前選択に加え、自分の呼び名や業務の注力領域を登録することで、AI がその情報をもとにレスポンスをパーソナライズしてくれるようになります。これまでセッションをまたいでチャット設定やエージェント選択、個人のコンテキストを保持する手段がなかったため、生成 AI を業務で日常的に活用するユーザーにとっては、毎回の設定の手間が省かれ、最初のやり取りからパーソナライズされた体験が得られるようになる便利なアップデートです。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

みなさん、こんにちは。Amazon Connect ソリューションアーキテクトの坂田です。 2026年2月に発表された Amazon Connect のアップデートをまとめてお届けします。今月は、エージェントの通話品質を向上させる音声強化機能や、タスクの AI 概要・推奨アクション、ダッシュボードのきめ細かいアクセス制御、Amazon Connect Cases の複数の機能拡張、スケジューリングやアウトバウンドキャンペーンの運用改善など、合計 13件のアップデートが発表されました。加えて、AWS Contact Center Blog では AI エージェントの活用やコンタクトセンター移行のベストプラクティスなど 4件のブログ記事が公開されています。以下、カテゴリごとにご紹介します。 目次 注目のアップデートについて 2026年2月のアップデート一覧 エージェント体験の向上 AI・分析機能の強化 Amazon Connect Cases の機能強化 スケジューリングとアウトバウンドキャンペーン AWS Contact Center Blog のご紹介 まとめ 1. 注目のアップデートについて 今月の注目アップデートは以下の 3つです! 注目 1: Amazon Connect が騒音環境向けのオーディオ拡張機能を導入 ひとつめは、2月4日に発表された Audio Enhancement 機能 です。これは、エージェント側の音声をリアルタイムで処理し、エンドカスタマーが聞く音声品質を向上させるものです。コンタクトセンターではしばしば、他のエージェントの会話やネットワーク機器から発せられる騒音など、周囲の雑音が気になることがあります。今回のアップデートは、こうした環境で業務を行うエージェントにとって特に有用な機能です。 この機能には 2つのモード が用意されています。 ノイズ抑制（Noise Suppression）モード : バックグラウンドノイズを低減します。有線・無線ヘッドセット、ヘッドセットなしのいずれの構成でも利用可能です。 音声分離（Voice Isolation）モード : ノイズ低減に加え、コンタクトセンター内で複数の人が話している環境でもエージェントの音声を分離します。有線ヘッドセット使用時のみ推奨されます。 有効化方法 : 管理者がユーザー管理画面から対象エージェントの Phone type を Soft phone に設定し、Audio Enhancement のモードを選択します。設定変更は次の通話から適用されます。セキュリティプロファイルの「コンタクトコントロールパネル (CCP)」権限の「オーディオデバイスの設定」を有効にすると、エージェント自身が CCP 上でモードを切り替えることも可能です。 API サポート : CreateUser / UpdateUserConfig API の VoiceEnhancementConfigs パラメータ、Amazon Connect Streams API の agent.setVoiceEnhancementMode() 、ConnectSDK の Voice API に対応しています。 前提条件 : ソフトフォンユーザーのみ対象。最低 4コア CPU（仮想マシンは 4 vCPU）が必要。VDI 環境ではローカルブラウザアクセス方式のみサポート（Amazon Connect audio optimization 方式は非対応）。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョン 関連リソース : Amazon Connect でエージェントのオーディオ強化を有効にする 注目 2: タスクの AI 概要と推奨アクション 概要 : Amazon Connect にタスクの AI 概要と推奨アクション機能が追加されました。エージェントがタスクを受け取った際に、AI が過去のアクティビティを要約し、次に取るべきアクションを提案します。例えば、オンラインフォームから送信された返金リクエストのタスクを受け取った場合、注文詳細の確認、返品資格のチェック、支払い方法の確認といった過去のアクティビティが要約され、返金を完了するための推奨ステップが提示されます。この機能を有効にするには、タスクがエージェントに割り当てられる前のフローに コネクトアシスタント フローブロックを追加します。ナレッジベースを追加することで、推奨内容をさらにガイドすることも可能です。 利用可能リージョン : Amazon Connect のリアルタイムエージェントアシスタンスが利用可能なすべての AWS リージョン 関連リソース Amazon Connect のフローブロック: Connect Assistant 注目 3: Agent Workspace での通知機能 概要 : Amazon Connect Agent Workspace に通知機能が追加されました。ワークスペースのヘッダーに通知が表示され、どのページからでも確認できるため、エージェントやビジネスユーザーは現在の作業を中断することなく、緊急のアップデートやポリシー変更、アクションアイテムなどの重要な情報を受け取ることができます。新しい通知 API を使用することで、組織内の特定のオーディエンスに対してプログラムからターゲットメッセージを送信することが可能です。パブリック API および AWS CloudFormation にも対応しています。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : ワークスペースヘッダーの通知機能 通知の設定方法 通知の作成・送信はすべて API 経由で行います。Amazon Connect の Notifications API として以下の8つのアクションが提供されています。 CreateNotification : 新しい通知を作成し、指定した受信者に配信します UpdateNotificationContent : 既存の通知内容を更新します DeleteNotification : 通知を削除します DescribeNotification / ListNotifications / SearchNotifications : 通知の詳細取得・一覧・検索を行います ListUserNotifications : 特定ユーザーの通知一覧を取得します UpdateUserNotificationStatus : ユーザーの通知ステータス（既読/未読）を更新します 通知を作成する際の主なパラメータは以下の通りです。 Content : ロケールコード（ ja_JP 、 en_US など 11言語）をキーとしたマップ形式で、各言語の通知テキストを指定します（1言語あたり最大 500文字）。リンクの埋め込みにも対応しています。 Recipients : 受信者のユーザー ARN を配列で指定します（最大 200件）。インスタンス ARN を指定すると、インスタンス内の全ユーザーに送信できます。 Priority : HIGH または LOW を指定します。高優先度の通知は低優先度より上に表示されます。 ExpiresAt : 通知の有効期限をタイムスタンプで指定します。未指定の場合、デフォルトで作成から1週間後に自動的に非表示になります。 Tags : タグベースアクセス制御（TBAC）に使用するタグを付与できます。 アクセス制御 通知の受信には追加の権限は不要ですが、通知の作成・編集・削除・送信済み通知の閲覧には API 権限が必要です。タグベースアクセス制御（TBAC）により、管理者は自身に割り当てられたタグと一致する通知のみを管理でき、一致するタグを持つユーザーにのみ送信できます。階層ベースアクセス制御（HBAC）では、管理者は自身の階層レベル以下のユーザーにのみ通知を送信できます。 2. 2026年2月のアップデート一覧 2.1. エージェント体験の向上 エージェントパフォーマンス評価の異議申し立てワークフロー （2026年2月3日） 概要 : エージェントがパフォーマンス評価に対して異議を申し立てるための統合ワークフローが追加されました。エージェントは評価に同意できない場合、Connect UI 上から理由を添えて異議を申し立てることができます。指定されたマネージャーには自動メール通知が送信され、異議の確認と解決を行います。マネージャーは異議が申し立てられた評価の一覧やステータスを追跡でき、タイムリーな解決が可能です。 利用可能リージョン : Amazon Connect が提供されているすべてのリージョン 関連リソース : 評価の異議申し立て Audio Enhancement（音声強化）によるエージェント通話品質の向上 （2026年2月4日） 注目 1 を確認してください! チャット・タスク・Eメール・コールバックの自動応答（Auto-Accept）設定 （2026年2月5日） 概要 : チャット、タスク、Eメール、コールバックの各チャネルに対して、エージェントの自動応答（Auto-Accept）を設定できるようになりました。自動応答を有効にすると、着信コンタクトがエージェントの手動承認を待たずに自動的に接続されるため、顧客への迅速な対応が可能になります。これまでこの設定はインバウンド音声通話に対してのみ利用可能でしたが、今回のアップデートでチャネルごとに個別に設定できるようになりました。例えば、タスクには自動応答を有効にしつつ、音声通話では無効のままにするといった運用が可能です。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : 自動応答の有効化 チャネル別の後処理（ACW）タイムアウト設定 （2026年2月11日） 概要 : チャット、タスク、Eメール、コールバックの各チャネルに対して、エージェントの後処理（After Contact Work）タイムアウトを設定できるようになりました。ACW タイムアウトにより、エージェントが後処理に費やせる時間を制限し、タイムアウト後は自動的に対応可能状態に戻ります。これは、エージェントごと、チャネルごとに異なるタイムアウトを設定でき、例えばEメールには短い ACW タイムアウトを設定しつつ、音声通話には次の顧客対応に備えるためのクールダウン時間として長めのタイムアウトを維持するといった運用が可能です。 利用可能リージョン : Amazon Connect が提供されているすべての AWS リージョン 関連リソース : エージェントの設定 Agent Workspace 内の通知機能の追加 （2026年2月13日） 注目 3 を確認してください! 2.2. AI・分析機能の強化 音声インタラクションのテスト・シミュレーション API （2026年2月） 概要 : コンタクトセンターの体験をシミュレーションするテストを構成・実行するための API が追加されました。発信者の電話番号やカスタマープロファイル、通話理由（「注文状況を確認したい」など）、期待される応答（「リクエストが処理されました」など）、営業時間外やキュー満杯といったビジネス条件をプログラムで設定できます。CI/CD パイプラインへの統合、複数テストの同時実行、デプロイサイクルの一部としての自動回帰テストが可能になり、ワークフローの変更を迅速に検証して本番環境へ自信を持ってデプロイできます。 利用可能リージョン : アジアパシフィック（ムンバイ、ソウル、シンガポール、シドニー、東京）、アフリカ（ケープタウン）、欧州（フランクフルト、ロンドン）、米国東部（バージニア北部）、米国西部（オレゴン）、カナダ（中部） 関連リソース : Amazon Connect API リファレンス タスクの AI 概要と推奨アクション （2026年2月13日） 注目 2 を確認してください! ダッシュボードのきめ細かいアクセス制御 （2026年2月12日） 概要 : Amazon Connect ダッシュボードにきめ細かいアクセス制御機能が追加されました。リソースタグを適用することで、特定のエージェント、キュー、ルーティングプロファイルなどのリソースに対するメトリクスの表示権限を制御できます。タグを使用してメトリクスをフィルタリングし、同じタグを共有するエージェントやキューの集計メトリクスを表示することも可能です。例えば、エージェントに「Department:Customer Service」タグを付与することで、カスタマーサービスチームのマネージャーのみがダッシュボードメトリクスを閲覧できるよう制限できます。 利用可能リージョン : Amazon Connect が提供されているすべての AWS 商用リージョンおよび AWS GovCloud (US-West) 関連リソース : ダッシュボードのタグベースアクセス制御 2.3. Amazon Connect Cases の機能強化 依存フィールドオプションをマッピングするための CSV アップロードをサポート （2026年2月6日） 概要 : Amazon Connect Cases のケースフィールドに設定する依存フィールドドロップダウンメニューを CSV ファイルのアップロードで一括設定できるようになりました。依存フィールドオプションは、カスケードドロップダウンメニューを作成します。1 つのフィールド (ターゲットフィールド) で使用可能な選択肢は、別のフィールド (ソースフィールド) で選択された値によって異なります。CSV ファイルは「Parent Field Name」「Child Field Name」「Parent Value」「Child Value」の4列フォーマットで、各行が1つの親子関係を表します。1つの CSV ファイルに複数のフィールドペアを含めることも可能です。地理的な階層構造（国 → 都道府県 → 市区町村）や製品カテゴリの分類（カテゴリ → サブカテゴリ）など、複雑な階層データの設定作業を大幅に効率化できます。なお、ソースフィールドとターゲットフィールドはいずれも単一選択型である必要があります。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : 依存フィールドオプション 依存フィールドオプションの CSV アップロード ケーステンプレートでの複数行テキストフィールドのサポート （2026年2月17日） 概要 : ケーステンプレートで複数行テキストフィールドがサポートされるようになりました。この新しいフィールドタイプは、複数の段落に対応して縦方向に拡張されるため、エージェントは根本原因分析、取引の詳細、調査結果などの詳細な自由記述ノートや構造化データをケース内に直接記録できます。これまでの単一行テキストフィールドでは記録しきれなかった詳細情報を、ケースに直接紐づけて管理できるようになり、ケース管理の質が向上します。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases でケースフィールドを作成する AWS Service Quotas との統合 （2026年2月18日） 概要 : Amazon Connect Cases が AWS Service Quotas に対応しました。管理者は Service Quotas コンソールから、適用されているクォータの確認、使用率のモニタリング、およびクォータの引き上げリクエストを一元的に行えるようになりました。対象となるクォータの引き上げリクエストは手動介入なしで自動承認されるため、予期しないサービス制約に遭遇することなくケースワークロードをスケールできます。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : Amazon Connect Cases のサービスクォータ 2.4. スケジューリングとアウトバウンドキャンペーン ドラフトスケジュールでのエージェント休暇リクエスト表示 （2026年2月17日） 概要 : 承認済みのエージェント休暇リクエストがドラフトスケジュール内に表示されるようになりました。スケジュール管理者は、特定の日にエージェントがスケジュールされなかった理由を容易に確認でき、スケジュールを公開する前にカバレッジのギャップを特定して調整することが可能になります。これにより、スケジュール作成時の可視性が向上し、人員配置の最適化に役立ちます。 利用可能リージョン : Amazon Connect のエージェントスケジューリングが利用可能なすべての AWS リージョン 関連リソース : 休暇管理 アウトバウンドキャンペーンのダイヤルモード動的切り替え （2026年2月26日） 概要 : アウトバウンドキャンペーンにおけるダイヤルモードの動的切り替え機能が発表されました。コンタクトセンターの管理者は、アクティブなキャンペーン実行中にプレビューモードと非プレビューモード（プログレッシブダイヤルなど）を切り替えることができます。従来はキャンペーン開始後にダイヤルモードを変更するにはキャンペーンの停止と再起動が必要でしたが、今回のアップデートによりキャンペーンを中断することなくリアルタイムで切り替えが可能になりました。例えば、高優先度のコンタクトに対応する際にプログレッシブダイヤルからプレビューモードに切り替え、追加のコンテキストを確認した後、通常のトラフィックパターンに戻った際に元のモードに復帰させるといった運用が可能です。 利用可能リージョン : 米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、欧州 (フランクフルト、ロンドン)、アジアパシフィック (ソウル、シンガポール、シドニー、東京)、アフリカ (ケープタウン) 関連リソース : アウトバウンドキャンペーンの設定 3. AWS Contact Center Blog のご紹介 2026年2月には、AWS Contact Center Blog において Amazon Connect に関連する 4件のブログ記事が公開されました。機能アップデートの発表とは別に、AI エージェントの活用方法やコンタクトセンター移行のベストプラクティスなど、実践的な知見が共有されています。 AI エージェントによるハイパーパーソナライゼーション （2026年2月2日） Amazon Connect Customer Profiles と Amazon Personalize を組み合わせ、顧客対応中にリアルタイムでパーソナライズされた商品レコメンデーションを提供する方法を解説しています。「おすすめ商品」「類似アイテム」「よく一緒に購入される商品」「人気商品」「トレンド商品」の5つのレコメンデーションユースケースが紹介されており、AI エージェントのガードレールやプロンプトのカスタマイズによるブランド一貫性の確保方法も説明されています。さらに、アウトバウンドキャンペーンを活用したプロアクティブな Web 通知の配信についても触れられています。 CX 業界予測 2026 （2026年2月3日） 2026年のカスタマーエクスペリエンス（CX）業界の展望をまとめたソートリーダーシップ記事です。AVOA、Cavell、IDC、Constellation Research などのアナリストの見解を集約し、「オーケストレーション（断片的な AI 導入から統合的なマルチエージェント体験へ）」「トラスト（AI ガバナンスフレームワークの構築）」「スケール（AI 成果の測定可能なビジネスアウトカムへの転換）」の3つのテーマで整理されています。 Amazon Connect への移行ベストプラクティス （2026年2月26日） 既存のコンタクトセンターから Amazon Connect への移行における「人」の側面に焦点を当てた包括的なガイドです。オペレーションチーム（エージェント、スーパーバイザー、QA アナリスト、ワークフォースマネージャー）、インフラストラクチャチーム（テレフォニーエンジニア、ACD 管理者、ネットワークスペシャリスト）、アプリケーションチーム（CX 開発者、エージェントデスクトップ開発者、ルーティング開発者）の3カテゴリに分けて、レガシーロールから Amazon Connect ロールへのトレーニングパスが詳細に解説されています。 Kiro を活用した AI エージェント開発の高速化 （2026年2月27日） AI コーディングアシスタント Kiro を使用して、15 のバックエンド API を統合した Amazon Connect AI エージェントをわずか3日間で構築した事例を紹介しています。通常 2〜3週間かかる POC 開発を大幅に短縮し、Kiro によるアーキテクチャ設計、Lambda 関数のコード生成、CloudWatch ログ分析によるデバッグ、MCP ツールスキーマの作成といった開発プロセスが解説されています。Amazon Bedrock Agents、AWS Lambda、Amazon DynamoDB、Amazon Bedrock AgentCore Gateway を活用した統合パターンが示されています。 4. まとめ 2026年2月は、エージェント体験の向上（Audio Enhancement、チャネル別設定、Agent Workspace 内の通知機能）、AI・分析機能の強化（タスクの AI 概要・推奨アクション、ダッシュボードのきめ細かいアクセス制御）、Amazon Connect Cases の機能強化（CSV 一括設定、複数行テキスト、Service Quotas 統合）、そしてスケジューリングとアウトバウンドキャンペーンの運用改善と、幅広い領域にわたる13件の機能アップデートが発表されました。 特に、Audio Enhancement によるエージェントの通話品質向上、タスクの AI 概要・推奨アクションによるエージェント生産性の向上、そしてアウトバウンドキャンペーンのダイヤルモード動的切り替えは、日々のコンタクトセンター運用に直接的なメリットをもたらす注目のアップデートです。 また、AWS Contact Center Blog では、AI エージェントによるハイパーパーソナライゼーション、CX 業界の 2026年予測、Amazon Connect への移行ベストプラクティス、Kiro を活用した AI エージェント開発の高速化の 4件のブログ記事が公開されました。機能アップデートと合わせて、これらのブログ記事もぜひご確認ください。 今後も最新の Amazon Connect のアップデート情報は AWS の What’s New ページ や Amazon Connect のリリースノート 、そして AWS Contact Center Blog で確認できます。引き続き最新情報をチェックしてみてください。 シニア スペシャリスト ソリューションアーキテクト/Amazon Connect, 坂田 陽一郎

2026 年 3 月 12 日、 Amazon Simple Storage Service (Amazon S3) の新機能を発表しました。この機能を使用すると、独自のアカウントのリージョン名前空間に汎用バケットを作成でき、データストレージの規模や用途の拡大に伴うバケットの作成および管理を簡素化できます。複数の AWS リージョンにまたがる汎用のバケット名を作成すると、希望するバケット名をいつでも使用できることが保証されます。 この機能を使用すると、リクエストしたバケット名にアカウント固有のサフィックスを追加することで、自分のアカウントのリージョナル名前空間に予測どおりの名前を付けて汎用バケットを作成できます。たとえば、アカウントのリージョナル名前空間にバケット mybucket-123456789012-us-east-1-an を作成できます。 mybucket は指定したバケット名のプレフィックスです。次に、リクエストされたバケット名にアカウントのリージョナルサフィックス -123456789012-us-east-1-an を追加します。別のアカウントが私のアカウントのサフィックスを使用してバケットを作成しようとすると、そのアカウントのリクエストは自動的に拒否されます。 セキュリティチームは、 AWS Identity and Access Management (AWS IAM) ポリシーと AWS Organizations サービスコントロールポリシーを使用して、従業員が新しい s3: x-amz-bucket-namespace 条件キーを使用してアカウントのリージョナル名前空間にのみバケットを作成するように強制できます。これにより、チームが組織全体でアカウントのリージョナル名前空間を採用しやすくなります。 アカウントのリージョナル名前空間を実際に使って S3 バケットを作成する 開始するには、 Amazon S3 コンソール で [バケットを作成] を選択します。アカウントのリージョナル名前空間にバケットを作成するには、 [アカウントのリージョナル名前空間] を選択します。このオプションを選択すると、アカウントとリージョンに固有の任意の名前でバケットを作成できます。 この設定は、グローバル名前空間の汎用バケットと同じ機能をすべてサポートします。唯一の違いは、アカウントのサフィックスが付いたバケット名を使用できるのはそのアカウントのみであるという点です。バケット名のプレフィックスとアカウントのリージョナルサフィックスを合わせた長さは、3～63 文字以内にする必要があります。 AWS コマンドラインインターフェイス (AWS CLI) を使用して、 x-amz-bucket-namespace: account-regional リクエストヘッダーを指定し、互換性のあるバケット名を指定することで、アカウントのリージョナル名前空間のバケットを作成できます。 $ aws s3api create-bucket --bucket mybucket-123456789012-us-east-1-an \ --bucket-namespace account-regional \ --region us-east-1 AWS SDK for Python (Boto3) を使用すると、 CreateBucket API リクエストを使用してアカウントのリージョナル名前空間を持つバケットを作成できます。 import boto3 class AccountRegionalBucketCreator: """アカウントリージョナル名前空間機能を使用して S3 バケットを作成します。""" ACCOUNT_REGIONAL_SUFFIX = "-an" def __init__(self, s3_client, sts_client): self.s3_client = s3_client self.sts_client = sts_client def create_account_regional_bucket(self, prefix): """ 指定されたプレフィックスを持つアカウントリージョナルの S3 バケットを作成します。 STS GetCallerIdentity API を使用して発信者の AWS アカウント ID を取得します。 フォーマット: ---an """ account_id = self.sts_client.get_caller_identity()['Account'] region = self.s3_client.meta.region_name bucket_name = self._generate_account_regional_bucket_name( prefix, account_id, region ) params = { "Bucket": bucket_name, "BucketNamespace": "account-regional" } if region != "us-east-1": params["CreateBucketConfiguration"] = { "LocationConstraint": region } return self.s3_client.create_bucket(**params) def _generate_account_regional_bucket_name(self, prefix, account_id, region): return f"{prefix}-{account_id}-{region}{self.ACCOUNT_REGIONAL_SUFFIX}" if __name__ == '__main__': s3_client = boto3.client('s3') sts_client = boto3.client('sts') creator = AccountRegionalBucketCreator(s3_client, sts_client) response = creator.create_account_regional_bucket('test-python-sdk') print(f"Bucket created: {response}") AWS CloudFormation などの Infrastructure as Code (IaC) ツールを更新すると、アカウントのリージョナル名前空間にバケットを簡単に作成できます。AWS CloudFormation には AWS:: AccountId と AWS::Region という疑似パラメータが用意されているため、アカウントのリージョナル名前空間バケットを作成する CloudFormation テンプレート を簡単に構築できます。 次の例は、既存の CloudFormation テンプレートを更新して、アカウントのリージョナル名前空間にバケットの作成を開始する方法を示しています。 BucketName: !Sub "amzn-s3-demo-bucket-${AWS::AccountId}-${AWS::Region}-an" BucketNamespace: "account-regional" または、 BucketNamePrefix プロパティを使用して CloudFormation テンプレートを更新することもできます。 BucketNamePrefix を使用すると、バケット名の顧客定義部分のみを指定でき、リクエスト元の AWS アカウントと指定されたリージョンに基づいて、アカウントのリージョナル名前空間サフィックスが自動的に追加されます。 BucketNamePrefix: 'amzn-s3-demo-bucket' BucketNamespace: "account-regional" これらのオプションを使用すると、カスタム CloudFormation テンプレートを構築して、アカウントのリージョナル名前空間に汎用バケットを簡単に作成できます。 知っておくべきこと 既存のグローバルバケットの名前をアカウントのリージョナル名前空間のバケット名に変更することはできませんが、アカウントのリージョナル名前空間に新しい汎用バケットを作成することはできます。また、アカウントのリージョナル名前空間は汎用バケットでのみサポートされています。S3 テーブルバケットとベクトルバケットはアカウントレベルの名前空間にすでに存在し、S3 ディレクトリバケットはゾーン名前空間に存在します。 詳細については、Amazon S3 ユーザーガイドの「 汎用バケット用の名前空間 」を参照してください。 今すぐご利用いただけます Amazon S3 のアカウントのリージョナル名前空間に汎用バケットを作成できるようになりました。これは、AWS 中国、AWS GovCloud (米国) リージョンを含む 37 の AWS リージョンで利用可能です。アカウントの リージョナル名前空間に汎用バケットを追加費用なしで作成できます。 Amazon S3 コンソール で 今すぐお試しいただき、 AWS re:Post for Amazon S3 宛てに、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

本稿は、2026 年 3 月 9 日に AWS migration-and-modernization Blog で公開された Microsoft and VMware workloads on AWS: Your complete AWS re:Invent 2025 playlist を翻訳したものです。 AWS 上で Microsoft および VMware ワークロードを移行およびモダナイズするには、適切な戦略、ツール、実際の検証が必要です。このプレイリストは、AWS re:Invent 2025 のトップセッションをまとめたもので、 AWS Transform によるエージェント型 AI を活用した自動化、AWS 上でのネイティブな VMware の実行、大規模に実施した顧客からの教訓を取り上げ、クラウドジャーニーのあらゆる段階における実践的なガイダンスを提供します。 大規模な移行とモダナイゼーションのためのエージェンティック AI AWS Transform は、大規模な移行のために特別に構築された初のエージェント型 AI サービスです。これは、検出、依存関係マッピング、ウェーブプランニング、サーバー移行といった、以前は数か月の手作業を必要としたタスクを自動化します。これらのセッションでは、VMware と .NET モダナイゼーションの両方のシナリオで AWS Transform がどのように機能するかを示します。 AWS Transform for VMware によるエージェンティック AI を使用した VMware 移行 | MAM202 | Level: 200 Amazon EC2 への大規模な VMware 移行のための初のエージェンティック AI サービスである AWS Transform をご紹介します。アプリケーション検出、依存関係マッピング、ネットワーク変換、ウェーブプランニング、最適化された EC2 インスタンス選択によるサーバー移行を自動化する方法のライブデモをご覧ください。ライセンスの課題とベンダーロックインを克服しながら、VMware インフラストラクチャをクラウドネイティブアーキテクチャにモダナイズし、より迅速で確実な移行を可能にする方法を学びます。 AWS 移行ジャーニー: Microsoft ワークロードのための 2025 年の旅程 | MAM309 | Level: 300 Active Directory およびファイルサーバーの移行戦略、インフラストラクチャの変革、SQL Server データベースの移行手法、.NET アプリケーションモダナイゼーションアプローチを含む、Microsoft エコシステム専用に設計された画期的な移行ツールをご紹介します。これらのサービスとソリューションが複雑な移行を合理化し、手作業を削減し、移行ジャーニーを加速する方法を直接学びます。 AWS 上でネイティブに VMware ワークロードを実行 Amazon Elastic VMware Service (Amazon EVS) を使用すると、リプラットフォームやリファクタリングなしで VMware ワークロードを AWS に移行できます。既存の VMware ツール、スキル、投資を維持しながら、AWS インフラストラクチャ、スケール、サービスを利用できます。これらのセッションでは、開始方法から高度なアーキテクチャパターンまですべてをカバーします。 Amazon EVS の完全ガイド: VMware ワークロードのための AWS スケールを解放 | MAM201 | Level: 200 Amazon EVS は、リプラットフォームやリファクタリングの手間なく、VMware ワークロードを AWS に移行するシームレスな方法を提供します。このサービスを使用すると、既存の VMware への投資と専門知識を保護しながら、AWS の堅牢なインフラストラクチャを活用できます。自己管理を選択するか、AWS パートナーと協力するかにかかわらず、Amazon EVS は、統合されたストレージ、バックアップ、ディザスタリカバリ機能を備えた仮想環境をカスタマイズするための柔軟なオプションを提供します。プラットフォームの直感的なデプロイプロセスと継続的なイノベーションにより、クラウドジャーニーを最適化するために必要なツールと柔軟性が確保されます。 FSx for ONTAP による Amazon EVS のストレージコスト最適化 (NetApp 提供) | MAM101 | Level: 100 Amazon EVS は、リプラットフォームなしで VMware ワークロードを AWS にシームレスに移行できるようにします。 Amazon FSx for NetApp ONTAP と組み合わせると、高い TCO や複雑なデータ操作などの一般的な移行の課題に対処します。この統合により、オンプレミスソリューションで通常見られるエンタープライズ機能である、シームレスなデータ移行、自律的なランサムウェア保護、ストレージ利用率の最適化など、エンタープライズグレードのデータ管理機能が提供されます。AWS パートナーの NetApp によるプレゼンテーションです。 お客様の成功事例 これらのセッションでは、大規模な移行とモダナイゼーションを完了した顧客が、結果を推進した戦略、ツール、教訓を共有します。 VMware ワークロード – 移行とモダナイゼーションの実現 AWS への VMware マイグレーション: 成功方法、ロードマップと戦略 | MAM203 | Level: 200 VMware 環境を AWS へ成功裡に移行した IT リーダーが、クラウドジャーニーの経験を共有します。移行の計画と実行中に使用された実証済みのツール、戦略、学んだ教訓から学びます。これらのグローバル組織は、モダナイゼーションのロードマップとイノベーション戦略に関する洞察を共有し、開始したばかりでも課題をナビゲートしている場合でも、独自のクラウド変革のための貴重なガイダンスを提供します。 エージェンティック AI による改革の先駆け: CSL VMware および SAP モダナイゼーション | MAM346 | Level: 300 CSL Behring が、 AWS Transform for VMware のエージェンティック AI を使用して 4,000 台を超える VMware サーバーを移行し、SAP システムを統合することでインフラストラクチャを変革した方法を紹介します。彼らの戦略は、技術的負債とライセンスコストを削減しながら、検出とプランニングプロセスを 10 倍高速化しました。 RISE with SAP on AWS を通じて ERP ランドスケープを統合し、エンタープライズ全体のデータ標準を確立した方法を学びます。このケーススタディは、組織の変革ジャーニーに適用できる技術的ガイダンスと実践的な洞察を提供します。 Microsoft ワークロード – 移行とモダナイゼーションの実現 AWS Transform による DMV システムのモダナイズ: Idemia の .NET 成功事例 | MAM410 | Level: 400 米国全土の 48 の DMV (車両管理局) にサービスを提供している Idemia が、 AWS Transform を使用してレガシー .NET Framework アプリケーションをモダナイズし、25 年間の技術的負債に対処した方法を学びます。カスタマイズされたモダナイゼーションのためのコンポーザブル変換、パートナーツールのシームレスな統合、変革中のビジネス継続性を維持するための戦略を探ります Grupo Tress Internacional の AWS Transform による .NET モダナイゼーション | MAM320 | Level: 300 Grupo Tress Internacional が、 AWS Transform for .NET を使用して .NET Framework から .NET 8 に移行しながら、モダナイゼーションの労力を 70% 削減した方法をご紹介します。 Amazon Elastic Container Service (Amazon ECS) および AWS Fargate を使用したコンテナ化、 AWS Lambda を使用したサーバーレス実装、.NET アプリケーションのための DevOps 方法論、生成 AI ツールによる開発者のエンパワーメントに関する実践的な戦略について学びます。 EC2 から EKS へ: Tipalti の AWS 上の Windows コンテナへの変革 | MAM339 | Level: 300 Tipalti が従来の Windows アプリケーションをモダンなコンテナ化されたソリューションに変革し、50% のパフォーマンス向上を達成したジャーニーをたどります。プロセス管理の課題の克服、Windows ワークロードのオートスケーリングの実装、Windows コンテナのベストプラクティス、Windows アプリケーションのモダナイズのための実践的な知識について学びます。 Thomson Reuters のエージェンティック AI によるスケールモダナイゼーション | MAM334 | Level: 300 Thomson Reuters が AWS Transform for .NET を活用して月間 500 万行のコードをモダナイズし、開発速度を 4 倍加速した方法を学びます。このセッションでは、アプリケーション変革を数か月から単一のスプリントに短縮し、運用コストを 30% 削減し、大規模な並列モダナイゼーションを実装した方法を紹介します。また、AI を活用したエージェントが、セキュリティとパフォーマンスを維持しながら技術的負債を削減した方法も紹介します。 ライセンスとコスト最適化 ソフトウェアライセンスの管理は、Microsoft および VMware ワークロードを AWS に移行する際の最も複雑な側面の 1 つです。このセッションでは、適切なサイジング、ライセンスコストの削減、AWS ツールを使用したコンプライアンスの維持とクラウド投資の最大化のための戦略を取り上げます。 AWS におけるエンタープライズソフトウェアライセンスと最適化 | MAM315 | Level: 300 このセッションでは、Microsoft ワークロードとコスト最適化戦略に焦点を当てて、AWS における商用ソフトウェアライセンスについて詳しく説明します。 Microsoft Optimization and Licensing Assessment (OLA) スペシャリストが、クラウドライセンスの複雑さの管理に関する専門的な洞察を共有します。このセッションでは、新しいセルフサービス AWS Transform Assessments を含む、さまざまなデプロイシナリオのための完全に無償の OLA オファリングを取り上げます。これらのツールが、クラウド投資効果を最大化するために AWS サービス全体で重要となる最適なサイジングの推奨事項をどのように提供するかをご覧ください。 チョークトーク re:Invent 2025 の以下のチョークトークは、移行計画、.NET モダナイゼーション、SQL Server、ライセンス、Amazon EVS アーキテクチャに関するインタラクティブで詳細なコンテンツを提供します。 スライドはこちらでご覧いただけます。 エージェンティック AI による AWS 上の SQL Server モダナイゼーションの加速 | MAM304 | Level: 300 AWS におけるライセンス管理と最適化 | MAM321 | Level: 300 .NET クラウドジャーニー: 移行とモダイゼーション戦略 | MAM317 | Level: 300 突然 SQL Server データ管理者になった人のための AWS 基礎 | MAM308 | Level: 300 VMware から AWS への準備: 移行前の基本的な決定事項 | MAM357 | Level: 300 Amazon EVS ディーブダイブ: 高度なネットワークとストレージアーキテクチャ | MAM401 | Level: 400 Amazon EVS ディープダイブ: 戦略的な移行計画 | MAM305 | Level: 300 まとめ AWS re:Invent 2025 は 1 つのことを明確にしました。Microsoft および VMware ワークロードをクラウドに移行することは、これまで以上に現実的になっています。エージェンティック AI により、.NET モダナイゼーションと VMware 移行の手作業が数か月から数週間に短縮されます。専用に設計構築されたインフラストラクチャオプションにより、リプラットフォームの障壁が取り除かれ、適切なライセンス戦略を導入することで、コストを管理しながらより迅速に移行できます。 Thomson Reuters から CSL まで、多くのお客様が、適切なツールと明確な移行戦略を組み合わせ、結果を達成しています。セッションをご覧になり、チョークトークのスライドを確認し、AWS での移行の計画を開始してください。 全ての移行とモダナイゼーションのプレイリストは、 YouTube の全プレイリスト をご覧ください。 <!-- '"` --> Suhail Fouzan Suhail Fouzan は、IT 業界で 15 年以上の経験を持つ Amazon Web Services (AWS) のスペシャリストソリューションアーキテクトです。Microsoft ワークロード、移行サービス、AWS Systems Manager による運用管理を専門とし、Suhail はお客様がインフラストラクチャを AWS に正常に移行できるよう支援しています。仕事以外では、Suhail はクリケットをプレーしたり、家族と過ごしたりすることを楽しんでいます。 Bianca Velasco Bianca Velasco は、AWS 上の VMware ベースのワークロードの移行と変革に焦点を当てた AWS のプロダクトマーケティングマネージャーです。マーケティングとテクノロジーで 7 年以上の経験があり、複雑なテクノロジーを意味があり親しみやすいものにするナラティブを作成することに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 この投稿の翻訳は Solutions Architect の田澤が担当させていただきました。原文記事は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの古屋です。今週も 週刊AWS をお届けします。 4月14日（火）14:00-17:00 にオンラインセミナー 「これから始める AWS のコンテナサービス活用」 が開催されます。お客様とお話しする中で、「運用負担を抑えつつある程度カスタマイズもしたい」「オンプレミスでもコンテナ環境を構築する必要がある」といったお声をいただくことがあります。本セミナーでは、そうしたお客様のニーズにお応えする形で、コンテナの意義やメリット、開発・設計の考え方、AWS コンテナサービスの特徴や実践的な活用方法などを幅広くご紹介します。これからコンテナを始める方にも、すでにご利用中で改めて情報をキャッチアップしたい方にもお役立ていただける内容です。詳細・お申し込みは こちら をご参照ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年3月9日週の主要なアップデート 3/9(月) Amazon SageMaker Unified Studio が Visual ETL でより高速なデータプレビューをサポート Amazon SageMaker Unified Studio の Visual ETL で、新しいデータプレビュー v2.0 が提供開始されました。従来は Spark セッションが必要で時間とコストがかかっていましたが、今回ブラウザ内エンジンでの処理により約 1 秒で結果を表示できるようになり、追加のコンピューティングコストも不要です。データエンジニアやアナリストが ETL ジョブを構築・修正する際の反復作業が劇的に高速化されます。詳細は こちらのドキュメントをご参照ください。 Amazon Quick がチャットパーソナライゼーション用のユーザー設定を開始 Amazon Quick で User Preferences 機能が提供開始されました。これまではチャットパネルの設定やエージェントの選択がセッション間で保持されず、毎回設定し直す必要がありましたが、今回のアップデートでチャットパネルのレイアウト（展開・折りたたみ）やデフォルトエージェントの選択などを事前に設定できるようになりました。メモリ機能により、Quick が過去のやり取りから学んだ内容の確認・管理も可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Route 53 Global Resolver が一般提供開始 Amazon Route 53 Global Resolver が一般提供開始となりました。このサービスは、組織内の認可されたクライアントに対して、どこからでも安全で信頼性の高い DNS 解決を提供します。30 の AWS リージョンで利用可能で、IPv4 および IPv6 の DNS クエリトラフィックをサポートし、悪意のあるドメインをブロックする DNS クエリフィルタリング機能や一元化されたクエリログ機能を備えています。企業のセキュリティ強化と DNS 管理の効率化に役立ちます。詳細は こちらのドキュメントをご参照ください。 3/10(火) Amazon Bedrock が First Token Latency と Quota Consumption の可観測性をサポート Amazon Bedrock で新たに 2 つの CloudWatch メトリクスが利用可能になりました。TimeToFirstToken はストリーミング API での初回トークン受信までの遅延時間を測定し、レスポンス性能の監視やアラーム設定が可能です。EstimatedTPMQuotaUsage は 1 分あたりのトークンクォータ使用量を追跡し、制限到達前の事前アラートやクォータ管理に活用できます。これまでクライアント側での実装が必要だった性能監視が、標準機能として利用できるようになり運用負荷が軽減されます。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Runtime がステートフル MCP サーバー機能をサポート開始 Amazon Bedrock AgentCore Runtime で、stateful MCP (Model Context Protocol) サーバー機能のサポートが開始されました。この機能により、従来の単純なリクエスト・レスポンス処理を超えて、ユーザーとの対話的な情報収集 (elicitation)、AI による文章生成依頼 (sampling)、長時間処理のリアルタイム進捗通知が可能になります。例えば、フライト検索時の進捗表示や、ユーザー設定に基づく個別推薦など、複雑なエージェントワークフローを構築できます。東京リージョンを含む 14 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 3/11(水) Amazon Neptune Database が空間データのネイティブサポートを追加 Amazon Neptune Database で空間データサポートが開始されました。従来は別途空間データベースを用意する必要がありましたが、今回のアップデートで Neptune 単体で位置情報を含むグラフデータを扱えるようになりました。ISO 13249-3 標準に準拠した 11 の空間関数により、近接分析やルート追跡、地理的パターン分析が可能です。地図サービスや配車アプリ、物流会社、スマートシティ開発などで活用でき、追加料金なしで全リージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Connect で送信メール時に異なる From メールアドレスを選択可能に Amazon Connect でメール送信時の 送信元 ( From ) のアドレスを選択できる機能が追加されました。従来は固定の送信者アドレスでしたが、今回のアップデートにより、管理者がキューごとに複数の送信者アドレスを設定し、エオペレーターが適切なアドレスを検索・選択できるようになります。複数のブランドや事業部門を一つの Amazon Connect インスタンスで運用するコンタクトセンターにとって、顧客とのやり取りで正しいブランドアイデンティティを保持できる重要な機能です。東京を含む 10 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 3/12(木) Amazon S3 が汎用バケット向けアカウントリージョナル名前空間を導入 Amazon S3 で新機能「アカウントリージョナル名前空間」が登場しました。従来は S3 バケット名をグローバルで一意にする必要があり、希望する名前が既に使われていることがありましたが、この機能により自分のアカウントとリージョンに紐づいた専用の名前空間内でバケットを作成できるようになりました。バケット名にはアカウント ID とリージョンを含むサフィックスが付与され、顧客やチーム毎にバケットを分ける際も、予測可能で一貫した名前を複数リージョンで使用可能です。37 リージョンで追加料金なしで利用できます。詳細は こちらの Blog 記事をご参照ください。 Amazon WorkSpaces が Microsoft Windows Server 2025 をサポート開始 Amazon WorkSpaces で Microsoft Windows Server 2025 がサポートされ、Personal と Core の両プランで利用可能になりました。最新バージョンでは Trusted Platform Module 2.0 ( TPM 2.0 ) や UEFI Secure Boot などの強化されたセキュリティ機能を活用できます。これにより、Microsoft 365 Apps for enterprise など新しい Windows バージョンが必要なアプリケーションも問題なく動作します。管理済みバンドルをそのまま使うか、要件に合わせたカスタムバンドルの作成も選択でき、WorkSpaces が利用可能な全リージョンで提供されています。 OpenSearch UI が OpenSearch ドメインへのクロスアカウントデータアクセスをサポート Amazon OpenSearch Service で、異なる AWS アカウントの OpenSearch ドメインに単一の UI からアクセスできるクロスアカウントデータアクセス機能が追加されました。これまでは複数アカウントのデータを分析する際、データを統合したり高コストなパイプラインを維持する必要がありましたが、今回のアップデートでデータを移動させることなく統合分析が可能になります。組織横断の監視やセキュリティ分析において、各アカウントのアクセス制御を維持しながら効率的な運用を実現できます。詳細は こちらのドキュメントをご参照ください。 3/13(金) Amazon EC2 Hpc8a インスタンスがアジアパシフィック (東京) と AWS GovCloud (US-West) で利用可能になりました Amazon EC2 Hpc8a インスタンスが東京リージョンと AWS GovCloud (US-West) で利用開始されました。第 5 世代 AMD EPYC プロセッサを搭載し、従来の Hpc7a と比較して最大 40% の性能向上と 25% のコスト効率改善を実現しています。気象予報や流体力学計算などの HPC ワークロードで威力を発揮し、メモリ帯域幅も最大 42% 向上したことで大規模シミュレーションがより高速に実行できます。詳細は こちらの Blog 記事をご参照ください。 Amazon EC2 R8a インスタンスがアジアパシフィック (東京) リージョンで利用可能になりました Amazon EC2 R8a インスタンスが東京リージョンで利用開始されました。5th Gen AMD EPYC プロセッサを搭載し、従来の R7a インスタンスと比べて最大 30% のパフォーマンス向上と 19% の価格性能比改善を実現します。第六世代のNitroカードを使用して構築されたR8aインスタンスはメモリ帯域幅も 45% 向上し、データベースやインメモリキャッシュ、リアルタイム分析など高パフォーマンスでメモリを大量に消費するワークロードに最適です。詳細は こちらをご参照ください。 新しい SAM Kiro power でサーバーレスアプリケーション開発を加速 AWS が AWS Serverless Application Model (SAM) Kiro power を発表しました。Kiro で AI エージェントがサーバーレスアプリケーション開発を支援する機能で、SAM プロジェクトの初期化やビルド・デプロイ、Lambda 関数のローカルテストなどの開発ワークフローをガイドします。EventBridge や SQS などのイベント駆動パターンにも対応し、セキュリティのベストプラクティスも自動で適用されるため、初心者でも安心してサーバーレスアプリケーション開発を始められます。Kiro IDE からワンクリックでインストールして利用開始できます。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 古屋 楓 (Kaede Koya) / @KaedeKoya35328 AWS Japan のソリューションアーキテクトとして、多種多様な業界のお客様をご支援しています。特定の技術やサービスに偏らず、幅広い分野のご相談に対応し、技術相談会や各種イベントにて登壇しています。好きな AWSサービスは Amazon Lightsail と Kiro で、シンプルかつ柔軟にクラウドの力を活用できる点がお気に入りです。休日は愛犬 2 匹と静かに過ごしています。

Amazon Relational Database Service (Amazon RDS) for SQL Server は、マルチ AZ 配置におけるブロックレベルレプリケーションによる高可用性を導入することで、SQL Server 2022 Web Edition を強化しました。以前は、高可用性機能は Always On 可用性グループやデータベースミラーリングなどの技術を通じて、Enterprise Edition と Standard Edition に限定されていました。この新しい機能により、Web ホスターや Web 付加価値プロバイダー (VAP) がパブリックでインターネットアクセス可能な Web ページ、Web サイト、Web アプリケーション、Web サービスをホストするために設計された SQL Server Web Edition に、エンタープライズグレードの可用性がもたらされます。 このリリースにより、運用オーバーヘッドを大幅に削減しながら、高可用性データベースを迅速にセットアップし、維持することができます。この投稿では、ブロックレベルレプリケーションの利点と開始方法について説明します。詳細については、 Amazon RDS での Microsoft SQL Server のライセンス をご覧ください。 ソリューション概要 Amazon RDS のマルチ AZ 配置は、同期されたスタンバイデータベースインスタンスを維持することで高可用性を実現します。Amazon RDS for SQL Server は従来から様々なレプリケーション技術をサポートしてきましたが、この新しいソリューションは特にブロックレベルレプリケーションを活用して、プライマリインスタンスとスタンバイインスタンス間でストレージを同期します。このアプローチにより、データベースの冗長性を維持するためのより合理化された効率的な方法が提供されます。 SQL Web edition のマルチ AZ がサポートされているバージョンは次の通りです。 SQL Server 2022: Web Edition 16.00.4215.2.v1 または、それ以上のバージョン Microsoft SQL Server Web Edition について、ブロックレベルレプリケーションを使用したマルチ AZ 配置が可能なのは、16.00.4215.2.v1 以上のバージョンで新規作成またはアップグレードされた DB インスタンスのみであることに注意してください。 最新のバージョンサポートについて最新情報を得るには、 RDS ドキュメント を参照してください。 マルチ AZ 配置では、Amazon RDS が異なるアベイラビリティーゾーンに同期スタンバイレプリカを自動的にプロビジョニングし、維持します。フェイルオーバーが完了するまでの時間は、プライマリ DB インスタンスが利用できなくなった時点でのデータベースアクティビティやその他の条件によって異なります。フェイルオーバー時間は通常 60 ～ 120 秒です。ただし、大規模なトランザクションや長時間の復旧プロセスにより、フェイルオーバー時間が長くなる場合があります。 プライマリインスタンスのデータは、ブロックレベルでスタンバイインスタンスに同期的にレプリケートされ、サーバーレベルのオブジェクトや設定を含む完全なデータ冗長性を提供します。計画外のサービス中断が発生した場合、Amazon RDS は自動的にスタンバイインスタンスにフェイルオーバーします。フェイルオーバープロセス全体を通じて同じ DNS エンドポイントが維持されるため、アプリケーションの接続文字列を再設定する必要がなくデータベース操作を最小限の中断で再開できます。 AWS Management Console 、 AWS Command Line Interface (AWS CLI)、または AWS SDK を使用して、マルチ AZ オプション付きの新しい RDS SQL Server Web Edition データベースインスタンスを作成したり、既存の Web Edition データベースインスタンスをシングル AZ からマルチ AZ に変更したりできます。 前提条件 開始するには、以下のリソースが必要です： 適切な権限 を持つ AWS アカウント SQL Server Management Studio (SSMS) がインストールされ、Amazon RDS との通信を許可するセキュリティグループルールが設定された Windows EC2 インスタンス (オプション) AWS CLI の インストールと設定 このソリューションには新しい AWS リソースが必要で、コストが発生します。実装前に AWS 料金 を確認してください。 本番環境以外の環境でこの設定をテストし、本番環境への適用前に完全な検証を実行することを強く推奨します。 マルチ AZ の DB インスタンス作成 DB インスタンスを作成する前に、AWS リージョンとバージョン の可用性を確認して、RDS インスタンスをホストしたいリージョンで SQL Server エディションとバージョンの組み合わせが有効になっていることを確認してください。 マルチ AZ の Amazon RDS インスタンスを作成するには、以下の手順を実行してください： Amazon RDS コンソールで、ナビゲーションペインの「データベース」を選択します。 「データベースの作成」を選択します。 「標準作成」を選択します。 基本設定を構成します： エンジンタイプで「Microsoft SQL Server」を選択します。 データベース管理タイプで「Amazon RDS」を選択します。 エディションで「SQL Server Web Edition」を選択します。 バージョンで「16.00.4215.2.v1」を選択します。 インスタンス識別子に、インスタンスの名前を入力します。 設定で、以下を構成します： プライマリユーザー名とパスワードを入力します。 必要に応じて DB インスタンスクラスを指定します。 ストレージタイプとサイズを設定します。 可用性と耐久性で、マルチ AZ 配置について「はい (ブロックレベルレプリケーション)」を選択します。 接続の設定で、仮想プライベートクラウド (VPC) とサブネットグループを選択します。 パブリックアクセスについては、「いいえ」を選択します。 VPC セキュリティグループについては、既存を選択し、作成したセキュリティグループを選択します。 「データベースの作成」を選択します。 Amazon RDS が マルチ AZ Amazon RDS インスタンスをプロビジョニングするまで待機します。 または、AWS CLI を使用して マルチ AZ インスタンスをデプロイすることもできます。Windows 上で AWS CLIを 使用してSQL Server Web edition の RDS インスタンスを作成するには、次のコマンドを使用します： aws rds create-db-instance ^ --db-instance-identifier sqlserver-web-demo ^ --engine sqlserver-web ^ --engine-version 16.00.4215.2.v1 ^ --license-model license-included ^ --master-username master ^ --master-user-password password ^ --db-instance-class db.m5d.4xlarge --allocated-storage 16000 ^ --storage-type io2 --iops 64000 ^ --multi-az ^ --storage-encrypted ^ --region us-east-1 Code MacOS/Linux で AWS CLI を使用して SQL Server Web edition の RDS インスタンスを作成するには、以下のコマンドを使用してください： aws rds create-db-instance \ --db-instance-identifier sqlserver-web-demo \ --engine sqlserver-web \ --engine-version 16.00.4215.2.v1 \ --license-model license-included \ --master-username master \ --master-user-password password \ --db-instance-class db.m5d.4xlarge \ --allocated-storage 16000 \ --storage-type io2 \ --iops 64000 \ --multi-az \ --storage-encrypted \ --region us-east-1 Code 接続と設定確認 設定を確認するために、以下の手順を完了してください： Session Manager を使用して Amazon EC2 インスタンスに接続します。 SSMS を起動し、以下の情報で接続します： サーバー名：Amazon RDS for SQL Server インスタンスのエンドポイント 認証：SQL Server 認証 ログイン資格情報：作成時に指定したもの 新しいクエリウィンドウを開き、以下のクエリを実行してデータベースとテーブルを作成します： USE master ; GO CREATE DATABASE MAZDB ; GO USE MAZDB ; GO CREATE TABLE dbo . test ( ID int identity ( 1 , 1 ) primary key , [ Desc ] char ( 100 ) ) GO INSERT INTO dbo . test VALUES ( 'RDS MAZ' ) GO 50 SELECT COUNT ( * ) FROM dbo . test ; GO SQL データベースが作成され、50 件のレコードがテーブルに挿入されるのを確認できます。 フェイルオーバーの実行 コンソールを使用してフェイルオーバー機能をテストできます。フェイルオーバープロセスは、セカンダリノードを新しいプライマリインスタンスに昇格させます。プライマリのアベイラビリティーゾーンが変更されたことも確認できます。以下の手順を実行してください： Amazon RDS コンソールで、インスタンスを選択します。 アクションメニューで、再起動を選択します。 フェイルオーバーありで再起動を選択します。 再起動を確認します。 フェイルオーバーを伴う再起動操作により、短時間のダウンタイムが発生します。アプリケーションへの影響を最小限に抑えるため、オフピーク時間帯にスケジュールしてください。 または、AWS CLI を使用してフェイルオーバーを開始することもできます： aws rds reboot-db-instance \ --db-instance-identifier sqlserver-web-demo \ --region us-east-1 \ --force-failover Code フェイルオーバー後のステータス確認 フェイルオーバープロセスが完了したら、新しいプライマリインスタンスに接続して、以前に作成されたデータベースが利用可能な状態にあり、クエリを実行できることを確認できます。以下の手順を実行してください： Windows EC2 インスタンスにリモートデスクトップ接続します (以前の接続が切断されている場合)。 検索ウィンドウで SSMS を検索し、「接続」を選択して「データベースエンジン」を選択します。 サーバー名には、RDS for SQL Server のエンドポイントを入力します。 RDS for SQL Server インスタンスを作成する際に指定したログインとパスワードの詳細を入力します。 「接続」を選択します。 新しいクエリウィンドウを開いて、データアクセシビリティを確認してください： USE MAZDB ; GO SELECT COUNT ( * ) FROM dbo . test ; GO SQL 50 行が返されることを確認してください。 コンソールに新しいアベイラビリティーゾーンが反映されるまで数分かかります。 制限事項 このソリューションの制限事項の詳細については、 Microsoft SQL Server DB インスタンスの制限事項 を参照してください。 クリーンアップ 継続的な課金を避けるために、この投稿の一部として作成したリソースを削除してください： RDS インスタンスを削除する 。 EC2 インスタンスを削除する 。 結論 この投稿では、SQL Server Web Edition の マルチ AZ RDS インスタンスをセットアップし、フェイルオーバーテストを通じてその高可用性機能を検証する方法を紹介しました。 この新機能により、運用オーバーヘッドを削減しながら、データベースの高可用性を実装するプロセスが簡素化されます。手動での設定とメンテナンスの必要性を最小限に抑えることで、事業継続性とアプリケーションの可用性要件をより適切に満たすことができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Ram Yellapragada Ram は、Amazon RDS チームのシニアデータベースエンジニアです。彼は AWS に 5 年以上在籍しています。RDS 製品の開発に従事し、特に マルチ AZと耐久性機能に注力しています。それ以前は、様々な業界のお客様と協力し、AWS クラウドにおける複雑なデータベースソリューションの設計、開発、展開に関する豊富なコンサルティング経験を持っています。 Nirupam Datta Nirupam は、AWS のシニアテクニカルアカウントマネージャーです。彼は AWS に 5 年以上在籍しています。データベースエンジニアリングとインフラアーキテクチャにおいて 13 年以上の経験を持ち、Amazon RDS コアシステムと Amazon RDS for SQL Server のスペシャリストでもあります。彼はお客様に技術支援を提供し、AWS クラウドでの移行、最適化、そして導入の道のりをガイドしています。 Shirin Ali Shirin は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。お客様のアーキテクトに対してデータベースソリューションを AWS に移行することを支援しています。AWS 入社以前は、エネルギーおよび教育業界セグメントにおいて、本番環境およびミッションクリティカルなデータベース実装をサポートしていました。

こんにちは。AWS シニアソリューションアーキテクトの崔 祐碩です。首都圏を中心に 125 店舗のスーパーマーケットを展開する サミット株式会社 （以下、サミット）では、DX 推進の一環として AI コーディングアシスタント「 Kiro 」を活用し、情報システム部門が自らの手で業務アプリケーションを素早く形にする取り組みを進めています。本ブログでは、サミット 情報システム部 企画・開発グループの小池様に、Kiro 導入の背景や具体的な活用事例、今後の展望について伺いました。 サミット株式会社について サミット株式会社は、東京・神奈川・埼玉・千葉の 1 都 3 県で 125 店舗を展開するスーパーマーケットチェーンです。1963 年の設立以来、「嘘の無い仕事」を経営理念に掲げ、売上高約 3,488 億円（2025 年 3 月期）、従業員数約 18,000 名の規模で事業を展開しています。「サミットが日本のスーパーマーケットを楽しくする」という事業ビジョンのもと、お客様一人ひとりに寄り添う店舗づくりとリテイル DX の推進に取り組んでいます。 Kiro との出会い ― 「これは運命でした」 DX 推進における課題 ― 「作りたいもの」が形にならない AWS： そうした課題を抱える中で、 Kiro とはどのように出会われたのでしょうか？ 小池様： もともとはコードエディタを使って、チャットボットの画面でコードを書いてはコピー＆ペーストする、というループでコーディングをしていました。他の AI コーディングツールも使っていましたが、当時の生成 AI が読み込めるコンテキスト量と、出力されるコードの品質には限界がありました。 様々な AI コーディングツールが出てきた中で、AWS の担当者からの紹介もあり、 Amazon Q Developer を試していたところ、ちょうど Kiro がリリースされたんです。自然な流れでたどり着いた、まさに運命的な出会いでしたね。 AWS： 他のツールと比較して、Kiro を選ばれた決め手は何でしたか？ 小池様： 開発ツールの選択は好みの問題になりがちですが、企業として使っていく上での条件を考えると、Kiro が最もリスクが少なく安心できるものでした。ポイントは大きく 3 つあります。 シンプルさと展開のしやすさ： Kiro はインストールしてログインすれば、すぐに使い始められます。初期設定の手間が少なく、環境の再現性が高いため、チームへの展開もスムーズです。 ガバナンス： Kiro はログインしないと使えない。これは企業利用において非常に重要です。拡張性が適切に管理されていることも、ガバナンスの観点ではメリットになります。何でもできてしまう環境は、統制が効かなくなるリスクがあります。 クラウドとの統合： AWS のバックエンドと統合したプロダクトを作ることを考えると、Kiroを使っておけば開発環境からクラウドまで一貫した体験が得られるという安心感があります。 つまり、「王道」のやり方ができるツールだと感じました。スタンダードで、シンプルで、ガバナンスが効く。企業の情報システム部門が安心して採用できるツールだと思います。 Kiro で作ったもの 事例 ① ：店舗クラスター分析ダッシュボード ― 12 時間で PoC を実現 AWS： 具体的に Kiro で開発されたものを教えてください。 小池様： 最初の事例は、リテイル DX チームからの依頼で作った店舗データの分析ダッシュボードです。店舗の従業員に対して、クラスター分析の結果を可視化して見せたい、PoC をやってみたいという要望がありました。 当初はBIツールなどを導入する話もありましたが、PoCの段階では新たなツールの導入には時間とコストがかかります。費用対効果が見えない中での意思決定にも時間を要するため、まずは自分の手で素早く形にしてみようと考えました。 AWS： 実際にどのくらいの時間で完成したのでしょうか？ 小池様： 初期バージョンは約 12 時間で完成しました。HTML ベースで Excel データを読み込んで表示するダッシュボードです。Kiro の Spec-driven Development の機能を活用して、要件から設計、実装までを一気に進めました。 店舗データ分析 BI ツール AWS： DX チームの反応はいかがでしたか？ フィードバックからすぐ改善 小池様： 「こんなにすぐできたの？」という驚きの声がありましたね。フィードバックを受けて修正する作業も、5 時間程度で何回かのイテレーションを回せました。しかも、別の打ち合わせをしながら、Kiro にプロンプトを投げて結果を待つ間に会議に参加する、という並行作業ができたんです。 フィードバックの内容も、機能を減らしたいとか、表示するタブやグラフの切り替え、初期データの自動読み込みといった調整レベルのもので、設定の切り替えで対応できるものがほとんどでした。 AWS： 従来のアプローチだと、同等のものを作るのにどのくらいかかると見積もられますか？ 小池様： 通常、このような PoC を外部に依頼する場合、要件定義からパートナーとの契約、見積もり、稟議、発注というプロセスだけで 1〜2 か月はかかります。開発自体も 1〜2 人月程度は見込まれ、全体では少なくとも 3 か月、費用も数百万円単位になることが一般的です。それが Kiro を使うことで、一人の担当者が 12 時間 + フィードバック対応 5 時間で実現できたというのは、非常に大きなインパクトです。 事例 ② ：3D インタラクティブプレゼンテーション ― 外部発表資料を 1 日で AWS： 他にも Kiro で作られたものはありますか？ 小池様： Vibe コーディングの事例を外部に発表する機会がありました。外部への発表ですから、それなりにクオリティの高い資料が求められる場です。 最初は HTML ベースで資料を作り始めたのですが、途中で「せっかくなら 3D 効果を入れてみよう」と思い立ち、Three.js を使った 3D インタラクティブなプレゼンテーションに仕上げました。聴衆が自由に 3D 空間を動き回れるよ うな体験型の資料です。 AWS： 制作時間はどのくらいでしたか？ 小池様： 他の作業と並行しながらも、約 8 時間で完成しました。3D 効果を入れずにシンプルなスライドにするなら 1〜2 時間で終わったと思いますが、外部発表の場ということもあり、表現にこだわりました。 3Dバーチャル展示会を回遊しながら楽しむプレゼンテーション 通常、外部向けの発表資料は、構成の検討からデザインの調整まで含めると 1 週間程度かかることも珍しくありません。それが Kiro を活用することで 1 日で完成し、さらに 3D インタラクティブという新しい表現も実現できました。 この経験から、社内の部会資料や共有資料も HTML ベースで作れるようになるといいなと考えています。議事録やメモをマークダウンで書いて、Kiro でスライド化する。そういう文化が社内に根付けば、資料作成の負担は大幅に減る はずです。社内の便利ツールとしても展開していきたいですね。 事例 ③ ：店舗エリア分析マップ ― 国土地理院 API を活用した地図アプリ AWS： 最後にもう一つ、事例をご紹介いただけますか。 小池様： マーケティング業務で使う地図ベースのエリア分析ツールを Kiro で作りました。店舗番号を入力すると、国土地理院の API から市区町村のデータを取得して、対象エリアを地図上に可視化するものです。 例えば、特定のエリアに何人住んでいるのか、商圏の人口分布はどうなっているのか、といったことを視覚的に確認できます。 AWS： こちらの制作時間は？ 小池様： これも 12 時間未満ですね。もともとコードエディタでベースを作っていたものを Kiro で作り直したのですが、モデルも良くなっているので、かなり実用的なものに仕上がりました。外部 API との連携や地図の描画処理など、自分でゼロから調べてコーディングしようとすると相当な時間がかかる部分を、Kiro が一気にやってくれます。 店舗エリア分析マップ これからの夢 ― リバースエンジニアリングと、パートナーとの新しい協業 AWS： 今後、Kiro を使ってどのようなことに取り組みたいとお考えですか？ ① レガシーシステムのリバースエンジニアリングと刷新 小池様： 一番やりたいのは、レガシーシステムのリバースエンジニアリングです。 多くの企業で、過去に作られたシステムが「なぜ動いているか分からない」状態で残っていると思います。担当者が変わり、ドキュメントも残っていない。コードだけが正しい、という状況です。 Kiro を使えば、既存のコードからドキュメントを自動生成できます。実際に私はすでにこれを始めていて、コードを Kiro に読み込ませてリバースエンジニアリングでドキュメントを作らせています。 AWS： そこから先の展望も見えてきますね。 小池様： はい。まず、今まで見える化すらできなかったレガシーコードの中身が、ドキュメントとして可視化される。これだけでも大きな一歩です。そして、そのドキュメントをチームでレビューして内容を正しく整理したら、今度はそれをスペック（要件定義）として Kiro に渡して、要件に合った新しいシステムを AI で作り直す。 つまり、古いコード → ドキュメント化 → スペック整理 → 新規開発 という流れです。 今までは、このドキュメント化の工程自体が膨大な手作業で、現実的に手が付けられなかった。それが Kiro によって一気に可能になる。ドキュメントさえできれば、そこからメンテナンスもしやすくなりますし、新しいメンバーへの引き継ぎも格段に楽になります。 ② パートナーとの協業を「動くもの中心」に変える 小池様： もう一つの夢は、パートナーとの協業モデルを根本的に変えることです。 実は一部の案件で、Kiro で実際に動くモックアップ ― 単なる画面イメージではなく、実データを読み込んで画面遷移も動作もするレベルのもの ― を作って開発パートナーに渡すという試みを始めています。パートナーがその意図を正しく理解できた場合は、こちらの期待の 120% のものが返ってくることもあり、手応えを感じています。 これを全面的に展開していきたい。Kiro は Spec-driven Development なので、モックアップを作る過程で仕様書（ Spec ）も自動的に生成されます。つまり、動くモックアップと仕様書をセットでパートナーに渡せる。パートナーはコードと仕様書の両方を参照しながら本番実装を進め、レビュー会では動くものを見ながらその場で修正する。1〜2 回のイテレーションで最終版に近づけて、完成後はレビューを通じて更新された仕様書に加え、運用ドキュメントなども Kiro で追加生成する。 Kiro を活用した新しいアプローチ 従来はドキュメントだけが共通言語でしたが、新しいアプローチでは動くコードと Kiro が生成した仕様書の両方が共通言語になる。要件定義をドキュメントから始めるのではなく、動くものと仕様書を同時に作り、開発・レビューを経てドキュメントも一緒に育てていく。日本の IT 業界に根付いたウォーターフォール文化を、もう少しアジャイルに変えていけるのではないかと思っています。 Kiro を使うコツ ― セッション管理とステアリング AWS： Kiro を効果的に使うためのコツがあれば教えてください。 小池様： 一番大事なのは、セッション情報の管理です。AI コーディングツール全般に言えることですが、長時間の開発ではコンテキストの引き継ぎが重要になります。Kiro ではこれを効率的に管理する仕組みがあり、私はそれを積極的に活用しています。 私はプロジェクトごとにセッション情報を記録するルールを設けていて、Kiro に「このタイミングでセッション情報を保存して」と指示しています。再開時には、最新のセッション情報とプロジェクトメモリーを参照するようにルールで定義しています。 もう一つのポイントは、 Steering &nbsp;の活用です。ステアリングには、プロジェクトごとの統制ルールや、セッション再開時に参照すべき情報、コーディング規約などを定義しています。例えば「セッション再開時はプロジェクトごとの最新セッション情報とプロジェクトメモリーを必ず参照すること」といったルールです。 さらに、Steering&nbsp;の内容自体も Kiro との対話を通じて作成できます。「こういうルールをステアリングに追加して」と指示すると、Kiro が内容を整理して記録してくれるため、開発環境の設定も対話の中で完結します。 今後の展望 AWS： 最後に、今後についてお聞かせください。 小池様： 私は Kiro を活用した AI 開発によって、コードの品質向上や開発スピードの改善を実感しています。この流れをチーム全体に広げていきたいと考えています。 そのためにも、Kiro が Web 経由でクラウド環境から利用できるようになることや、AWS のサービスとの連携がより深まっていくことに期待しています。ローカル PC への環境構築が不要になれば、開発経験が浅いメンバーでもすぐに使い始められます。チーム全員が統一された環境で AI 支援を受けながら開発できるようになれば、社内での活用をさらに拡大していけると考えています。 著者について 小池 朋昭（こいけ ともあき）の紹介 サミット株式会社 情報システム部にて、ハイブリッドクラウド化やレガシー刷新をPM／テックリードとして推進。データスチュワードとして全社データの活用基盤整備も主導。現在はVibe コーディングによる内製開発やアジャイル 開発体制の構築に取り組み、業務・IT・データを横断した全社DXを牽引している。 崔 祐碩 （Woosuk Choi）は AWS Japan Senior Solution Architect としてエンタープライズ・商社のお客様を担当し、データ分析基盤やプライベートクラウドの構築、DevOps/SREの運用経験を活かして、クラウド導入やData/AIソリューションの実装を支援しています。

Amazon Relational Database Service（以下、RDS）や Amazon Aurora（以下、Aurora）のリザーブドインスタンス（RI）は、オンデマンド料金と比較して大幅なコスト削減が可能です。しかし、RDS の RI には Amazon EC2 の RI とは異なり開始日時を指定した予約購入の機能がなく、購入 API を実行した時点で即座に課金が開始されます。そのため、大量の RI を短時間で正確に購入するには手動オペレーションでは負荷が高く、お客様にとって購入のハードルが高い状況となっています。 なお、第 7 世代以降のインスタンスで利用可能になった Database Savings Plans では予約購入が可能ですが、旧世代のインスタンスを利用されている場合は引き続き RI での購入が必要です。 本記事では、公共機関における RI 購入の制約を例に、RDS / Aurora の RI を効率的に一括購入するサンプルスクリプトをご紹介します。公共機関以外のお客様でも、大量の RI を正確に購入したいケースで参考にしていただけます。 背景 公共機関ではデータ保管場所や予算執行の都合により購入方法が限定されることが一般的です。例えば、次のような制約があります。 日本リージョン（東京・大阪）のみ 前払いなし（No Upfront）のみ利用可能 購入タイミングは 4/1 09:00:00〜09:59:59（JST） ※会計年度を1時間でもまたがないようにする場合 この制約のもとでは、限られた時間内に正確な購入を完了する必要があり、事後に間違いに気づいても購入を止めることが出来ません。そして、多数のアカウントが同じ時間帯に一斉に RI を購入する必要があることを考えると、手動オペレーションでは品質・工数の両面で課題があります。 この課題に対応するため、AWS CloudShell 上で動作する RDS RI 一括購入のサンプルスクリプトを用意しました。AWS CloudShell はブラウザからアクセスできるシェル環境で、AWS CLI や jq（JSON 処理ツール）などの主要ツールがプリインストールされているため、実行環境の準備を別途行う必要がありません。AWS マネジメントコンソールにログインできれば、すぐにスクリプトを実行できます。 前提条件 AWS CloudShell 環境（AWS CLI、jq がプリインストール済みのため、追加のセットアップは不要） IAM ロールに以下の権限が付与されていること rds:DescribeReservedDBInstancesOfferings rds:PurchaseReservedDBInstancesOffering rds:DescribeDBInstances sts:GetCallerIdentity 1アカウントあたり同一リージョンで保有可能なRIはデフォルト40件まで（ 参考 ）。超過する場合は事前にサービスクォータの引き上げを申請してください （参考）AWS CloudShell VPC environment を利用する場合 CloudShell VPC environment ではシェルが指定した VPC のサブネット内で動作するため、スクリプトが呼び出す AWS API（RDS、STS）へのネットワーク到達性を確保する必要があります。具体的には、以下のいずれかを構成してください。 AWS PrivateLink（VPC エンドポイント）による RDS API および STS API へのアクセス NAT Gateway を経由したインターネットアクセス（ご利用環境のシステム要件やセキュリティポリシーを確認のうえ実施してください） ネットワーク構成が不十分な場合、API 呼び出しがタイムアウトしスクリプトが正常に動作しません。 ※ 本記事執筆時点では、デジタル庁が提供するガバメントクラウド環境で AWS CloudShell を利用するには CloudShell VPC environment の構成が必要です。 （参考）CloudShellを使わずローカル端末から実行する場合 AWS CloudShell を使用せず、お手元のローカル端末から実行することも可能です。その場合、以下の点にご注意ください。 シェルスクリプト実行環境が必要です。Linux や macOS ではデフォルトシェルである bash や zsh が利用できます。Windows の場合は WSL（Windows Subsystem for Linux）上で実行してください。 AWS CLI（バージョン2推奨）および jq を事前にインストールしてください。 AWS 認証情報の設定が必要です。aws configure 、IAM Identity Center（aws sso login）、 aws login 等で、スクリプト実行前に認証情報を構成してください。 スクリプトはタイムゾーン Asia/Tokyo を使用して購入タイミングの判定を行います。OS のタイムゾーンデータが正しくインストールされていることを確認してください。 Linux：“cat /etc/timezone” 等 macOS：“sudo systemsetup -gettimezone” 等 準備 入力ファイル（input.csv）を準備してください（フォーマットは後述）。次に、rds-ri-launchpad.sh を CloudShell へアップロード、または GitHub から直接取得し、実行権限を付与してください。 GitHub から直接取得する場合の例 curl -O https://raw.githubusercontent.com/aws-samples/sample-rds-ri-bulk-purchase-script/main/rds-ri-launchpad.sh chmod +x rds-ri-launchpad.sh スクリプトの特徴 スクリプトは「ドライラン（検証）モード」と「購入モード」の 2 段階で動作します。ドライランモードでは実際の購入を行わず、入力内容の検証のみを実施します。 ドライランモード（デフォルト） ./rds-ri-launchpad.sh input.csv 前述のとおり、RDS の RI には開始日時を指定した予約購入の機能がありません。そのため、本スクリプトではドライランモードを用意し、購入直前までの検証を事前に実施できるようにしています。以下のチェックを実施できます。 日本リージョン（ap-northeast-1 / ap-northeast-3）のみであること 前払いなし（No Upfront）のみであること インスタンスクラス形式の妥当性（db.xxx.xxx 形式） エンジン名の許可リスト検証 DescribeReservedDBInstancesOfferings API による Offering（購入可能な RI の条件と価格の組み合わせ）の存在確認 実際に稼働中のインスタンスとの突合（購入数量が稼働数を超過していないかの警告） 購入は一切実行されないため、実際のRI購入日である 4/1 より前に安全に事前確認が可能です。 購入モード ./rds-ri-launchpad.sh --purchase input.csv --purchase オプションを指定することで、実際の購入を実行します。購入時にはドライラン時のチェック項目に加えて、以下の制御が行われます。 購入タイミングの確認 — 4/1 09:00:00〜09:59:59（JST）の範囲外の場合はアラートを発行し、続行するかの確認プロンプトを表示 最終確認プロンプト — 購入実行前に yes/no の確認を要求 入力ファイル CSV 形式で購入情報を定義します。1 行目のヘッダー行はスクリプトが自動的にスキップします。 こちらはサンプルファイルです。 region,db_type,instance_class,engine,multi_az,quantity,duration,payment_option ap-northeast-1,RDS,db.t3.medium,mysql,yes,2,1,No Upfront ap-northeast-1,Aurora,db.r5.large,aurora-mysql,no,3,1,No Upfront フィールド 説明 許容値 region リージョン ap-northeast-1, ap-northeast-3 db_type DB 種別 RDS, Aurora instance_class インスタンスクラス db.xxx.xxx 形式 engine エンジン aurora-mysql, aurora-postgresql, mysql, postgresql, mariadb, oracle-se2, sqlserver-ex multi_az Multi-AZ yes, no（Aurora の場合は無視） quantity 購入数量 1 以上の整数 duration 期間（年） 1, 3 payment_option 支払いオプション No Upfront（他の文字列の場合はエラー） セキュリティ上の考慮 基本的なパストラバーサル対策 — 入力ファイルパスに .. が含まれる場合は即座に終了 入力値の許可リスト検証 — エンジン名、リージョン、支払いオプションを許可リストで検証 ロックディレクトリ機構 — 同時実行を防止し、二重購入を回避 結果ファイルのパーミッション制限 — chmod 600 で所有者のみ読み取り可能 エラー出力のサニタイズ — アカウント ID や ARN をマスクして表示 set -euo pipefail — 未定義変数やパイプエラーを即座に検出 エラーハンドリング スクリプトは「行単位の継続処理」を採用しています。ある行でバリデーションエラーや Offering 取得失敗が発生した場合でも、該当行をスキップして次の行の処理を継続します。AWS 認証エラーなど回復不能なエラーの場合のみスクリプトを終了します。 実行結果は ri_purchase_result_YYYYMMDD_HHMMSS.txt に自動出力され、成功・失敗・スキップの件数と各行の詳細が記録されます。一部の処理が失敗した場合は、 失敗した行のみを記載した新しいCSVファイルを作成し、再実行することで手動リトライが可能です。 本スクリプトは1回の実行あたり10〜100行程度の入力を想定しています。大量の入力（100行超）を処理する場合、AWS APIのスロットリングが発生する可能性があります。その場合はCSVファイルを分割し、複数回に分けて実行してください 。 ダウンロード サンプルスクリプトは以下リンクよりダウンロード可能です。 sample-rds-ri-bulk-purchase-script まとめ 本スクリプトは、限られた購入時間枠の中で大量の RDS / Aurora の RI を安全かつ効率的に一括購入するためのサンプルです。ドライランモードで事前に購入内容を検証し、購入モードで実行するという 2 段階のアプローチにより、オペレーションミスのリスクを低減します。 免責事項 本記事で紹介するスクリプトはサンプルコードであり、AWS サポートの対象外です。本番環境での使用前に、必ずテスト環境で十分な動作確認を行ってください。 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。本ブログや添付資料は AWS サービスの変更・追加などにより今後修正される場合があります。本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン合同会社は一切の責任を負いません。上記ご了承の上、ご利用ください。 筆者について Hidenori Hiroki 廣木 秀典（Hidenori Hiroki）は、公共部門担当のTechnical Account Manager（TAM）。ポストフェーズにおけるお客様の課題解決をご支援しています。コスト最適化やセキュリティ設計など、お客様のクラウド活用を日々サポートしています。 Kazuki Fujimoto 藤本 一樹（Kazuki Fujimoto）は、パブリックセクターの自治体担当のソリューションアーキテクトです。自治体の基幹システムのクラウド移行やそれに伴うコスト最適化とモダナイゼーション、生成 AI の活用支援などをおこなっています。

本記事は 2026 年 3 月 11 日 に公開された「 Amazon Redshift DC2 migration approach with a customer case study 」を翻訳したものです。 この記事は、AWS パートナーである Classmethod のソリューションアーキテクト、石川&nbsp;覚氏によるゲスト投稿です。 2025 年 4 月、AWS は Amazon Redshift DC2 インスタンスの廃止を発表し、Redshift RA3 インスタンスまたは Redshift Serverless への移行を推奨しました。Redshift RA3 インスタンスと Serverless はストレージとコンピューティングを分離する設計を採用しており、 データ共有 、書き込みの 同時実行スケーリング 、 zero-ETL 、 クラスターリロケーション などの新機能を提供します。 本記事では、あるお客様が DC2 から RA3 インスタンスへ移行した事例を紹介します。小売業の大手企業であるこのお客様は、BI と ETL ワークロード向けに 16 ノードの dc2.8xlarge クラスターを運用していました。データ量の増加とディスク容量の制約に直面し、Blue-Green デプロイメントアプローチで RA3 インスタンスへの移行に成功。ETL クエリパフォーマンスの向上とストレージ容量の拡大を、コスト効率を維持しながら実現しました。 Amazon Redshift のアーキテクチャタイプ Amazon Redshift には 2 つのデプロイオプションがあります。Provisioned モードではインスタンスタイプとノード数を選択し、必要に応じてリサイズを管理します。Redshift Serverless はデータウェアハウスのキャパシティを自動的にプロビジョニングし、基盤リソースをインテリジェントにスケーリングします。次の図は、これら 2 つのアーキテクチャタイプを比較したものです。 Provisioned クラスターはクラスターサイズを事前に決定する必要がありますが、リザーブドインスタンス (RI) の購入や一時停止・再開のスケジューリングでコストを最適化できます。Serverless は必要に応じてリソースを自動プロビジョニングし、消費したコンピューティングリソースに対してのみ課金される従量課金モデルです。両サービスとも相互移行をサポートし、SQL、zero-ETL、Federated Query などの同じ機能を提供します。料金の詳細は Amazon Redshift の料金 をご覧ください。 Provisioned クラスターは大規模で予測可能なワークロードに適しており、キューイングに基づく自動スケーリングを提供します。Serverless は変動するワークロードに対して管理不要の自動スケーリングを提供し、ワークロードの複雑さとデータ量に基づいてスケーリングする AI 駆動の最適化 を備えています。詳細は Amazon Redshift Serverless とプロビジョニング済みデータウェアハウスの比較 をご覧ください。 お客様事例：DC2 インスタンスからの移行 このセクションでは、お客様の Amazon Redshift DC2 から RA3 インスタンスタイプへの移行について説明します。 Blue-Green デプロイメント アプローチを採用し、ダウンタイムを最小限に抑えながらコスト最適化とパフォーマンス向上の両方を達成しました。 お客様のワークロードには以下の特徴がありました。 ユースケース お客様の Amazon Redshift の主なユースケースは以下のとおりです。 営業時間中の BI ツールによるクエリ 大量の読み取りクエリ 月曜日と月初にアクセスがピークに達する 早朝のデータ処理 データロードと変換のための書き込みクエリが集中 定常的なワークロード特性 1 日 16 時間以上クエリを実行 要件 お客様の Amazon Redshift 移行における主な要件は以下のとおりです。 パフォーマンス ピークアクセス時に自動スケーリング (同時実行スケーリングなど) を使用 データサイズ ディスク容量の拡張が必要 コスト管理 予算の予測と管理が容易であること 長期利用向けの割引サービスを活用 互換性 既存のアプリケーションと BI ツールとの互換性を維持 エンドポイントの変更を回避 可用性 移行中の最大ダウンタイムは 8 時間まで許容 ネットワーク 既存の 2 アベイラビリティーゾーン (AZ) サブネット構成を変更しない 移行タイミング 負荷の低い日時に実施 8 時間以内の計画ダウンタイムが可能 システム設計、実装、運用における主な検討事項は、長時間の運用、予算の予測と管理の容易さ、リザーブドインスタンス (RI) によるコスト最適化、既存システムとの互換性維持 (エンドポイント変更の回避) でした。お客様は Amazon Redshift Serverless も評価しました。従量課金モデル、自動スケーリング機能、変動するワークロードに対するより良い価格性能比など、魅力的な機能を備えていました。Redshift Serverless と Provisioned クラスターのどちらもワークロードパターンを効果的にサポートできましたが、お客様は Provisioned 環境での長年の運用経験、既存の RI 戦略、確立されたキャパシティプランニングアプローチを活かし、RA3 ノードの Provisioned モデルを選択しました。 RA3 インスタンスタイプの特徴 AWS Nitro System 上に構築された RA3 インスタンスは、マネージドストレージを備え、コンピューティングとストレージを分離するアーキテクチャを採用しています。各コンポーネントを独立してスケーリングでき、課金も個別に行われます。ホットデータには高性能 SSD、コールドデータには Amazon S3 を使用し、使いやすさ、コスト効率の高いストレージ、高速なクエリパフォーマンスを実現します。詳細は Amazon Redshift RA3 instances with managed storage をご覧ください。 移行の前提条件 お客様の移行の前提条件は以下のとおりです。 16 ノードの dc2.8xlarge 構成の Redshift クラスターを使用していました。 移行には Blue-Green デプロイメントアプローチを採用し、スナップショットから RA3 インスタンスタイプにリストアすることで、必要に応じて迅速にロールバックできるようにしました。 クラスター識別子のローテーションによるエンドポイント切り替えで、クラスターの切り替えとロールバックを実装しました。 さらに、高い同時実行性でのパフォーマンス向上のため、トランザクション分離レベルを SERIALIZABLE ISOLATION から SNAPSHOT ISOLATION に移行しました。 クラスター移行方法 移行には Elastic Resize と Classic Resize の 2 つのオプションがありました。 Amazon Redshift の Classic Resize 機能が強化 され、RA3 インスタンスタイプへのリサイズにおいて書き込み不可期間が大幅に短縮されました。PoC テストの結果、リサイズ開始後、クラスターのステータスが modifying になってから利用可能になるまで 16 分でした。この結果を踏まえ、お客様は Classic Resize アプローチで進めました。 クラスターサイジング サイジングでは、移行先のインスタンスタイプとノード数を決定しました。CPU 集約型 (高 CPU 使用率のクエリ)、I/O 集約型 (データ読み書きが多いクエリ)、またはその両方といったワークロード特性を考慮しました。DC2 インスタンスタイプからの移行では、ワークロード要件に応じて追加ノードが必要になる場合があります。必要なクエリパフォーマンスに応じたコンピューティング要件に基づいてノードを増減しました。 インスタンスサイズとノード数でクラスターコストが同等の構成を比較すると、 dc2.8xlarge 16 ノードクラスターの推奨構成は ra3.16xlarge 8 ノード でした。東京リージョンでのコスト比較は以下のとおりです。 推奨構成：dc2.8xlarge 16 ノードクラスター =&gt; ra3.16xlarge 8 ノードクラスター $97.52/h (6.095/h * 16 ノード) =&gt; $122.776/h (15.347/h * 8 ノード) コスト重視：dc2.8xlarge 16 ノードクラスター =&gt; ra3.16xlarge 6 ノードクラスター $97.52/h (6.095/h * 16 ノード) =&gt; $92.082/h (15.347/h * 6 ノード) 今回の移行では、既存の予算制約内に収めるため、コスト効率の高い 6 ノードの ra3.16xlarge クラスターで進めました。ただし、このノード数では特定の時間帯にスループットの制約が生じる可能性があるため、RA3 インスタンスタイプの同時実行スケーリングを有効にしてスパイクアクセスに対応しました。 同時実行スケーリングは、アクティブなクラスターごとに 1 日最大 1 時間の無料クレジットを提供し、最大 30 時間まで蓄積できます。この無料枠を超えるとオンデマンド料金が適用されます。お客様は同時実行スケーリングの導入を選択しましたが、ピーク負荷時に一時的にノードを増やす Elastic Resize も検討されました。しかし、追加ノードのオンデマンドコストと切り替え時の短時間の切断が発生するため、採用を見送りました。 マネージドストレージのコスト RA3 インスタンスは Redshift Managed Storage (RMS) を使用し、固定の GB 月額料金で課金されます。お客様の約 2 TB のデータについて、ストレージコストを見積もりに含める必要がありました。料金の詳細は Amazon Redshift の料金 をご覧ください。 DC2 から RA3 への移行手順 DC2 クラスターのスナップショットから RA3 クラスターを作成した後、クラスター識別子を入れ替えました。次の図はこのプロセスを示しています。 現在の DC2 クラスターのスナップショットを取得します。 異なるクラスター識別子でスナップショットから RA3 クラスターをリストアします (Classic Resize)。 現在の DC2 クラスターと新しい RA3 クラスターのクラスター識別子を入れ替えます。 クラスター切り替え後に問題が発生した場合、元の DC2 クラスターのクラスター識別子を元に戻すことで迅速にロールバックできます。 注：スナップショットからのリストア 操作ミスを最小限に抑え、再現性を確保するため、CLI コマンドでリストア操作を実行することを推奨します。以下はサンプルコマンドです。 aws redshift restore-from-cluster-snapshot \ --cluster-identifier for-ra3-20250207 \ --snapshot-identifier cm-cluster-for-ra3-20250207 \ --cluster-subnet-group-name cm-cluster \ --vpc-security-group-ids sg-1234567a sg-2345678b sg-3456789c \ --cluster-parameter-group-name cm-cluster \ --node-type ra3.16xlarge \ --number-of-nodes 6 \ --port 5439 \ --no-publicly-accessible \ --enhanced-vpc-routing \ --availability-zone ap-northeast-1a \ --preferred-maintenance-window sat:17:00-sat:17:30 \ --automated-snapshot-retention-period 14 \ --iam-roles 'arn:aws:iam::123456789012:role/AmazonRedshift-CommandsAccessRole' 'arn:aws:iam::123456789012:role/AmazonRedshift-Spectrum' \ --maintenance-track-name current 本番移行の所要時間 リストアと Classic Resize の所要時間は、データ量とターゲットクラスターの仕様によって大きく異なります。お客様は事前にリハーサルを実施し、実際の所要時間を計測しました。 テスト結果 本番移行の前に、お客様はスナップショットを RA3 インスタンスタイプにリストアしてテストクラスターを作成しました。通常、ワークロードテストには Redshift Test Drive が有用ですが、このお客様には固有の制約がありました。本番クラスターで監査ログを有効にするには、設定変更、クラスター再起動、厳格な変更管理ポリシーに基づく複雑な承認プロセスが必要でした。この課題に対応するため、Amazon Redshift のシステムビュー ( SYS_QUERY_HISTORY と SYS_QUERY_TEXT ) を使用してワークロードパターンをキャプチャする独自の負荷テストツールを開発しました。これらのシステムビューは 7 日間のクエリ履歴を保持しています。このツールで 55,755 件の過去のクエリを 50 並列で DC2 と RA3 の両クラスターに対してリプレイし、クエリ実行時間、CPU 使用率、ディスク I/O などのメトリクスを比較しました。正確な比較のため、テスト中はクエリ結果のキャッシュを無効にしました。 BI クエリパフォーマンス BI クエリは前述の独自の負荷テストツールでテストしました。結果は、55,755 件のクエリを 50 並列で実行した 15 回のテストの平均実行時間です。同時実行スケーリングなしの場合、dc2.8xlarge 16 ノードクラスターの平均はクエリあたり 45.82 秒、ra3.16xlarge 6 ノードクラスターの平均は 91.30 秒でした。最適化なしの直接移行では、RA3 インスタンスは短・中程度のクエリで実行時間が長くなることが分かりました。しかし、同時実行スケーリングを有効にすると RA3 クラスターのパフォーマンスは段階的に改善しました。同時実行スケーリングを最大 2 クラスターで有効にした場合、ra3.16xlarge 6 ノードクラスターの平均はクエリあたり 72.48 秒となり、スケーリングなしの構成から 21% 改善しました。 ノードタイプ / ノード数 平均クエリ時間 ra3.16xlarge 6 ノードクラスター 72.48 秒 ETL クエリパフォーマンスの比較 長時間実行される ETL クエリ (実行時間 10 分以上) では、RA3 クラスターは DC2 クラスターよりも優れたパフォーマンスを示しました。これらの結果は、最適化を適用していないお客様のワークロードの直接移行によるものです。 大規模データロードワークロード 1 では、ra3.16xlarge クラスターは dc2.8xlarge クラスターより 28% 高速にクエリを完了しました (41 分 vs. 57 分)。 複雑な変換ワークロード 1 では、ra3.16xlarge クラスターは 23% 高速でした (1 時間 1 分 vs. 1 時間 20 分)。 これらの結果から、RA3 ノードタイプは時間のかかるデータロードや変換タスクでより高いパフォーマンスを発揮することが分かりました。RA3 クラスターの CPU 使用率が高い値を示したことは、コンピューティングリソースをより効果的に活用していることを示唆しています。 ノードタイプ / ノード数 平均クエリ時間 MAXCPU% ra3.16xlarge 6 ノードクラスター 41 分 09 秒 11.45 dc2.8xlarge 16 ノードクラスター 57 分 07 秒 10.85 ノードタイプ / ノード数 平均クエリ時間 MAXCPU% ra3.16xlarge 6 ノードクラスター 1 時間 01 分 33 秒 74.23 dc2.8xlarge 16 ノードクラスター 1 時間 20 分 36 秒 53.58 パフォーマンスチューニング テスト結果から、RA3 は短・中程度の BI クエリでは DC2 より実行時間が長くなる一方、長時間実行される ETL クエリでは高速であることが分かりました。全体的なパフォーマンスを最適化するため、遅いクエリと頻繁に参照されるテーブルを特定し、影響の大きい最適化を優先しました。 パフォーマンスチューニング戦略 お客様は RA3 のアーキテクチャ上の利点を活かすため、いくつかの最適化戦略を検討しました。主要な戦略の 1 つは、アドホックな短・中程度のクエリワークロードを低負荷時間帯に事前処理し、結合、集約、フィルタリング、射影を繰り返し実行するクエリ向けに事前処理テーブルやマテリアライズドビューを作成することでした。RA3 のコンピューティングとストレージを分離したアーキテクチャと、コスト効率の高い大容量ストレージがこのアプローチを支えました。 通常のビューからマテリアライズドビューへの変換 遅いクエリを分析したところ、ビュー内で結合が使用されており、頻繁に参照されるテーブルがこれらのビューを通じて複数回アクセスされていることが判明しました。対策として、頻繁に使用される通常のビューをマテリアライズドビューに置き換え、不要なデータ範囲と冗長なカラムを削除しました。 Amazon Redshift は REFRESH MATERIALIZED VIEW コマンドによるマテリアライズドビューの増分更新をサポートしており、効率的なデータ更新が可能です。 マテリアライズドビューとクエリリライト 通常のビューをマテリアライズドビューに変換すると、クエリプランナーが提供する「クエリリライト」機能により、既存のクエリが自動的に最適化される場合があります。詳細は マテリアライズドビューを使用した自動クエリリライト をご覧ください。 AutoMV による自動チューニング DC2 クラスターではディスク使用率が常に 80% を超えており、ディスク容量不足のため AutoMV 機能が無効になっていました。RA3 のストレージ拡張により、AutoMV による自動チューニングが可能になり、さらなるパフォーマンス改善につながりました。AutoMV の詳細は マテリアライズドビューを使用するための自動クエリ書き換え &nbsp;をご覧ください。 パフォーマンスチューニングの結果 これらの最適化を適用した結果、お客様は以下を達成しました。 コスト増加を抑えながら既存のパフォーマンスを維持 スループットを維持しながら CPU 使用率を向上 同時実行スケーリングの自動スケーリングにより、ピーク負荷時の動的なスループットを強化 まとめ 本記事では、小売業の大手企業が Amazon Redshift DC2 インスタンスから RA3 インスタンスへ移行した事例を紹介しました。Blue-Green デプロイメントアプローチにより、迅速なロールバック機能を備えた安全な移行を実現しました。RA3 のコンピューティングとストレージを分離したアーキテクチャは、増加するデータ量に対応する柔軟性を提供しました。RA3 インスタンスは短い BI クエリで DC2 インスタンスと異なるパフォーマンス特性を示しましたが、長時間実行される ETL クエリでは大幅な改善を達成しました (データロードで最大 28% 高速化、複雑な変換で 23% 高速化)。マテリアライズドビューや AutoMV などの RA3 インスタンス固有の機能を活用し、リザーブドインスタンスと同時実行スケーリングによるコスト効率を維持しながら、全体的なクエリパフォーマンスを最適化しました。 RA3 インスタンスへの移行の詳細については、 Best practices for upgrading from Amazon Redshift DC2 to RA3 and Amazon Redshift Serverless と Resize Amazon Redshift from DC2 to RA3 with minimal or no downtime をご覧ください。 著者について Satoru Ishikawa (石川&nbsp;覚) Satoru は、データ分析と AI コンサルティングを専門とし、Amazon SageMaker やマルチクラウドに注力しています。また、Classmethod の「Members」のバックエンド開発にも携わり、高度なデータと AI の活用を通じてデジタルトランスフォーメーションを推進しています。 Junpei Ozono (大薗 純平) Junpei は、データと AI ソリューションのテクニカルマーケット開発を推進し、グローバルチームと連携してスケーラブルな GTM 戦略を構築しています。Data Mesh、Data Lakehouse、AI などのモダンデータアーキテクチャを専門とし、お客様の AWS によるクラウドトランスフォーメーションの加速を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Junpei Ozono がレビューしました。

Fiti (スワヒリ語のスラングで「最高」) AWS Student Community Kenya! 2026年 3 月 2 日週は、ケニア全国でさまざまなミートアップ、ハンズオンワークショップ、キャリアディスカッションが開催された目まぐるしくもすばらしい一週間でした。そのフィナーレを飾ったのが Meru University of Science and Technology での AWS Student Community Day です。ここでは、私の同僚の Veliswa と Tiffany による基調講演に加えて、GitOps からクラウドネイティブエンジニアリングにおよぶ多種多様なセッションと、多数の AI エージェント構築セッションが行われました。 JAWS Days 2026 は世界最大の AWS Community Day で、3 月 7 日の参加者は 1,500 人を超えました。このイベントは、AI ドリブンな開発チームの構築に関する Jeff Barr の基調講演で始まり、100 を超える技術セッションとコミュニティ体験セッション、ライトニングトーク、そして Game Days、Builders Card Challenges、ネットワーキングパーティーなどのワークショップが行われました。 それでは、2026年 3 月 9 日週の AWS ニュースを見ていきましょう。 2026年 3 月 2 日週のリリース 2026年 3 月 2 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 ヘルスケア向けに構築されたエージェンティック AI、Amazon Connect Health の導入 – ヘルスケア専用の 5 つの AI エージェント (患者確認、予約管理、患者インサイト、アンビエントドキュメンテーション、医療コーディング) を備えた Amazon Connect Health の一般提供が開始されました。すべての機能は HIPAA に準拠しており、既存の臨床ワークフローに数日間で導入できます。 Amazon Bedrock AgentCore ポリシーの一般提供開始 – エージェントコード外で行われるエージェントとツールのやりとりに対し、一元的できめ細かなコントロールを利用できるようになりました。セキュリティチームとコンプライアンスチームは、AWS のオープンソースポリシー言語である Cedar に自動変換される自然言語を使用して、ツールアクセスルールと入力検証ルールを定義できます。 自律型プライベート AI エージェントを実行するための OpenClaw の Amazon Lightsail への導入 – 組み込みのセキュリティコントロール、サンドボックス化されたエージェントセッション、ワンクリック HTTPS、デバイスのペアリング認証機能を備えた独自のクラウドインフラストラクチャでプライベート AI アシスタントをデプロイできます。Amazon Bedrock がデフォルトのモデルプロバイダーとして機能し、Slack、Telegram、WhatsApp、Discord に接続できます。 AWS が VPC 暗号化コントロールの料金を発表 – 2026 年 3 月 1 日から、VPC 暗号化コントロールが無料プレビューから有料機能に移行します。リージョンに存在する VPC 内と VPC 間におけるすべてのトラフィックフローの転送時の暗号化を監査および強制でき、モニタリングモードでは暗号化されていないトラフィックが検知され、強制モードでは暗号化されていないトラフィックが阻止されます。 Database Savings Plans が Amazon OpenSearch Service と Amazon Neptune Analytics のサポートを開始 – 1 年間のコミットメントにより、対象のサーバーレスインスタンスとプロビジョニングされたインスタンスの使用に対する料金を最大 35% 節約できます。Savings Plans は、エンジン、インスタンスファミリー、サイズ、AWS リージョンに関わらず、自動的に適用されます。 AWS Elastic Beanstalk が AI 駆動の環境分析の提供を開始 – 環境状態が劣化した場合に、Elastic Beanstalk が最近のイベント、インスタンス状態、ログを収集し、Amazon Bedrock に送信できるようになりました。Amazon Bedrock はそれらを分析し、現行の環境状態に合わせてカスタマイズされたステップバイステップトラブルシューティングの推奨事項を提供します。 AWS がサービスワークフローでの IAM ロールの作成と設定を簡素化 – 新しいコンソール内パネルを使用することで、IAM コンソールに切り替えなくても、サービスワークフロー内で直接 IAM ロールの作成と設定を行えるようになりました。この機能は Amazon EC2、Lambda、EKS、ECS、Glue、CloudFormation などをサポートしています。 新しい Kiro power で Lambda 永続関数の開発を加速 – Kiro の AI エージェント支援開発を使用して、レジリエントで長期間実行されるマルチステップアプリケーションと AI ワークフローをより迅速に構築できるようになりました。この Kiro power は、リプレイモデル、ステップ操作と待機操作、同時実行パターン、エラー処理、およびデプロイのベストプラクティスに関するガイダンスを動的にロードします。 Amazon GameLift Servers が DDoS 保護の提供を開始 – アクセストークンを使用してクライアントトラフィックを認証し、プレイヤーごとのトラフィック制限を適用するコロケーションリレーネットワークを使用することで、DDoS 攻撃からセッションベースのマルチプレイヤーゲームを保護できるようになりました。GameLift Servers のお客様に対する追加コストはありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS コミュニティからの記事 私が個人的に気に入っている AWS コミュニティと同僚の記事をご紹介します。 I Built a Portable AI Memory Layer with MCP, AWS Bedrock, and a Chrome Extension – MCP、Amazon Bedrock、セッションとアプリケーション全体にコンテキストを提供する Chrome 拡張機能を使用して、AI エージェント用の永続メモリレイヤーを構築する方法を学びましょう。 When the Model Is the Machine – Mike Chambers は、AI エージェントが単一のプロンプトからランタイム時に完全かつインタラクティブなウェブアプリケーションを生成する実験的なアプリを構築しました。これには、コードベースもフレームワークも永続的な状態もありません。モデルがランタイムになるときに何が起こるのかを考えさせられる考察です。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Community GameDay Europe – AWS に関する知識がありますか? 3 月 17 日に開催される AWS Community GameDay Europe でその知識を実証しましょう。このゲーム型学習イベントでは、AWS サービスを使って現実世界の技術的課題を解決するためにチームが競い合います。 AWS at NVIDIA GTC 2026 – 2026 年 3 月 16～19 日に米国サンノゼで開催される NVIDIA GTC 2026 で、AWS のセッション、ブース、デモ、付帯イベントに参加しましょう。AWS 経由でイベントパスの 20% 割引を受け、GTC での 1 対 1 ミーティングをリクエストできます。 AWS Summit – 2026 年の AWS Summit にご参加ください。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスです。今後のイベントには、 スロバキア (3 月 11 日）、 プネ (3 月 21 日)、および メキシコシティ で開催される AWSome Women Summit LATAM (3 月 28 日) などがあります。 こちらのリンクから、今後開催される AWS 主導の対面および仮想イベント 、 スタートアップイベント 、 デベロッパー向けのイベント をご覧ください。 2026年 3 月 9 日週のニュースは以上です。2026年 3 月 16 日週の Weekly Roundup もお楽しみに! – seb 原文は こちら です。

本記事は 2026/03/11 に公開された “ From Pilot to Production: Scaling Industrial AI with AWS at Hannover Messe 2026 ” を翻訳し、 日本のお客様向けの補足情報 を追加したものです。 Hannover Messe 2026 がまもなく開催されます。今年注目の話題は工場フロアでの AI の活用です。世界有数の産業技術展示会である Hannover Messe の中心は、製造、エネルギー、物流の業界リーダーや実務者が一堂に会し、世界の産業が直面する重要な課題に取り組みます。今年のイベントは 4 月 20 日から 24 日までドイツのハノーバーで開催され、約 123,000 人の来場者、4,000 以上の出展者、そして数千もの製品やソリューションが集まります。AWS は、製造業の企業が AI を大規模に展開するための実用的なソリューションを提供します。Hannover Messe 2026 では今年も、ホール 15、ブース D76 の AWS ブースにご来訪ください。そこでは、AWS と AWS パートナーのソリューションを通じて、フィジカル AI、エージェンティック AI、エッジからクラウドへの連結性、インテリジェントなデータ基盤の最新情報を展示します。これらはすべて、製造業者が変革を加速し、測定可能なビジネス成果を促進するのに役立つように構築されています。 なぜ Hannover Messe 2026 に参加するのか 最新技術を学び、関係づけ、体験したいなら、Hannover Messe はまさにその機会です。以下の内容にご期待ください： 展示会： 4,000 以上の出展者が広大なホールに集まり、Hannover Messe はスマート製造、デジタルエコシステム、産業向けエネルギーにまたがるソリューションを紹介しています。AWS はデジタルエコシステムホールの中心、ホール 15、ブース D76 にあります。到着前に イベントレイアウト を確認しルートを計画してください。 カンファレンス： Hannover Messe のカンファレンスプログラムでは、C レベルの幹部、業界のビジョナリー、技術実務家によるプレゼンテーションが満載の専門ステージが特徴です。今年のアジェンダでは、フィジカル AI、エージェンティック AI、自律型製造、エッジからクラウドへの機器への接続、デジタル主権を取り上げます。AWS のスピーカーが週を通してステージに立ち、産業用 AI を大規模展開するための知見を共有します。スケジュールは以下のとおりです： 基調講演: AWS の自動車・製造部門のゼネラルマネージャーである Ozgur Tohumcu が、Volkswagen Group の Florian Lechner と共に、「 試験運用から本番へ：AWS とフォルクスワーゲングループで産業用 AI を大規模展開 (From Pilot to Production: Realizing Industrial AI at Scale with AWS and Volkswagen Group)」と題した基調講演を行います。このセッションは 4 月 21 日火曜日 午後 1:15–1:45 にセンターステージで行われます。Volkswagen Group が AWS を利用したデジタル生産プラットフォームを世界中の 40 以上の施設にどのようにスケールしているかを学びます。 成果のために: AIによる再産業化 (Build to Win: AI-driven Re-industrialization) – 4 月 20 日（月）午前10:20, Hall 26, Booth E43 – Spotlight Stage (Solution Lab Automation &amp; Digitalization) デジタル主権の複雑さを乗り越える (Navigate digital sovereignty complexity) – 4 月 20 日（月）午後3:10, Hall 26, booth E43 – Expert Stage 1 (Solution Lab Automation &amp; Digitalization) 製造のエージェントユースケースを初めて動かす:ライブマルチエージェントシステムデモ (Run Your First Manufacturing Agentic Use Case: Live Multi-Agent System Demo) – 4 月 21 日（火）午前11:15, 午前10:20 in Hall 26, Booth E43 – Spotlight Stage (Solution Lab Automation &amp; Digitalization) AI による製造業のバリューチェーンにおける脱炭素化と排出量モデリング (From Data to Decarbonization: AI-Powered Emissions Modeling Across Manufacturing Value Chains) – Hall 12, Stand F56 – Expert Stage (Solution Lab Energy &amp; Industry Infrastructure) マスタークラス： さらに深く学びたい人のために、Hannover Messe では、ライブ Q&amp;A を含む最大 60 分のインタラクティブな実務者によるセッションを提供します。AWS は今年、主要な産業用 AI トピックをカバーする 3 つのマスタークラスセッションを開催します。お早めに申し込んで、席を確保してください。 エージェントを活用したデータ探索によるデータ分析の加速(Accelerate data insights with agentic data exploration) – 4 月 20 日月曜日、午後 3:30、Solution Lab Automation &amp; Digitalization (Hall 26 Booth E43), Masterclass Room 1 エージェントベースの AI による在庫再調整の自動化 (Automate inventory rebalancing with Agentic AI)– 4 月 21 日火曜日、午後 4:45、Hall 12, Solution Lab (F56) Masterclass Room ショップフロア制御からフィジカル AI への移行：産業接続性とインテリジェントオートメーションの架け橋 (From Shop Floor Control to Physical AI: Bridging Industrial Connectivity and Intelligent Automation) – 4 月 23 日木曜日、午前 11:00、Solution Lab Automation &amp; Digitalization (Hall 26 Booth E43), Masterclass Room 1 ネットワーキング： Hannover Messe は、業界リーダーとつながる世界最大のグローバル産業イベントの 1 つです。展示フロア以外でも、AWS は週を通して様々なイベントを開催します。エグゼクティブ、顧客、パートナーが集まり、有意義なディスカッションを行います。AWS の専門家とのより深い個別ディスカッションをご希望の場合は、 ミーティングをリクエスト してください。ミーティングはブース内のミーティングルームで開催されます。 また、AWS パートナーのプラチナスポンサーが主催するブース内のイブニングレセプションも開催されます。ドリンクや軽食を楽しみながら、AWS のトップパートナーやその幹部とネットワーキングし、交流する機会をお楽しみいただけます。 4 月 20 日（月）午後 5:30 – 午後 7:00、 Zoomlion 提供のイブニングレセプション 4 月 21 日（火）午後 5:30 – 午後 7:00、 Siemens 提供のイブニングレセプション 4 月 22 日（水）午後 5:30 – 午後 7:00、 QAD Redzone がスポンサーのイブニングレセプション ホール 15 での AWS 展示内容 AWS は、ホール 15 のブース D76 に 1,400m² の展示スペースを設置します。ここでは、エンジニアリング・開発、スマート製造・サプライチェーン、スマート製品・サービスの 3 つのソリューション領域を紹介します。 今年の AWS ブースのハイライトは、 AI 駆動の製品ジャーニー です。これは製造工程を最初から最後まで実体験できる展示です。 参加者は自分でカスタムの金属製ドリンクコースターをデザインし、プロセスの最初から最後まで自律的に製造されるのを 確認 します。この体験は 3 つの領域全てにまたがります。 エンジニアリング &amp; 開発トンネル： ジェネレーティブデザイン、CAD AI エージェント、デジタルスレッドによるナレッジアシスタント、AI 駆動シミュレーションのライブデモンストレーションをご覧ください。 自律型製造セル： 自律移動ロボット（AMR）、協働ロボット（コボット）、ヒューマノイドロボットが、AWS を使用してオーケストレーションされたレーザー彫刻生産ラインを実行するためにリアルタイムで協力する様子をご覧ください。 フィジカル AI ステーション： AWS が提供するスケーラブルで統合されたエッジ to クラウドへのソリューションを通じて、製造業者は、合成データの生成、分散モデルトレーニング、写実的なシミュレーション、フリートの導入、物理ロボットとスマート製造システムのための高度なエージェントタスクを速やかに実現できます。これら&nbsp;5 つの柱となるプロセスを通じて、フィジカル AI の導入が可能になります。 今年の新展示 Amazon から学ぶ では、AWS が Amazon のフルフィルメントと物流を内側から支えているかを紹介します。ブース内のその他のキオスクでは、 Amazon Bedrock AgentCore 、 Amazon Nova Forge 、 Amazon Quick 、 AWS Transform に焦点を当てています。これらのキオスクでは、サプライチェーン最適化、データ探索、OT モダナイゼーション、組み込みソフトウェア開発、スマートマシンのためのエージェンティック AI ソリューションを 取り上げて います。 AWS のブースには 24 のスポンサーパートナー が参加し、プラチナスポンサーには QAD Redzone、Siemens、Zoomlion が含まれます。当社の 製造および産業パートナーネットワーク は、クラウドの旅のあらゆる段階で比類のない専門知識と選択肢をお客様に提供します。パートナーキオスクを探索して、幅広い製造のユースケース向けに AWS 上に構築された協調的なソリューションを発見してください。また、AWS Business Outcomes Xcelerator（BOX）プログラムについても学べます。このプログラムでは AWS と AWS パートナーが協力して、運用の近代化、生産プロセスの最適化、ビジネスの成長を促進します。 ブース体験をさらに豊かなものにする 50 以上のブース内シアターセッション が開催されます。ここでは、AWS の専門家、パートナー、顧客が実世界のストーリーを共有します。 セッションは、工場現場のフィジカル AI から、サプライチェーンのエージェントソリューションやインテリジェントなデータ基盤まで、幅広いトピックに及びます。AWS シアターセッションのスケジュールをチェックして、参加をご計画ください。 AWS が産業 AI をどのように支えているか AWS は、製造業の企業が AI でパイロットから本番環境へ移行するためのサポートを提供します。Hannover Messe 2026 では、AWS が産業変革における最重要課題にどのように取り組んでいるかを探ってみましょう： フィジカル AI と自律型製造： 工場フロアは急速に変化しています。フィジカル AI により、ロボット、コボット、自律システムが物理世界を認識、推論、行動します。AWS は、これらのソリューションを大規模に展開するための柔軟なエッジからクラウドまでのインフラストラクチャを提供します。シミュレーションやモデルトレーニングからエッジでのリアルタイム推論まで、AWS は製造業にフィジカル AI をもたらすのに役立っています。自律型製造セルでその様子をご覧ください。 サプライチェーンのためのエージェンティック AI： サプライチェーンは複雑で動的であり、迅速な意思決定を困難にします。AWS は製造業の企業のエージェンティック AI ソリューションの導入を支援し、お客様が計画を自律的に最適化し、混乱を予測し、意思決定を加速することを支援します。これらのソリューションは、産業グレードのインフラストラクチャによって実現されいてます。サプライチェーンキオスクを確認したり、Amazon Bedrock AgentCore でできることについてさらに学んでください。 インテリジェントデータ基盤とデジタルスレッド： サイロ化されたデータは、産業 AI の採用の大きな障壁です。AWS は、製造業者が統一されたデータ基盤を構築します。この基盤には、検索可能なナレッジグラフや製品デジタルスレッドソリューションが含まれ、製品ライフサイクル全体にわたって情報を接続します。この基盤により、生成 AI、エージェンティック AI、フィジカル AI をスケールすることが可能になります。ブースのエンジニアリングおよび開発エリアでさらに詳しく探ってみてください。 エッジからクラウドへの接続： 工場フロアの資産をクラウドに接続する際、既存のインフラストラクチャを丸ごと取り除く必要はありません。AWS IoT SiteWise Edge は、250 以上のデバイスのネイティブ産業プロトコルをサポートし、製造業務全体でデータをシームレスに収集、コンテキスト化、分析します。ブースのスマート製造エリアに立ち寄り、エッジからクラウドへの接続ソリューションをご覧ください。 運用レジリエンスとデジタル主権： 国境を越えて事業を展開する製造業者は、どこで事業を行っても、データの安全性、コンプライアンス準拠、レジリエンスに自信を持つ必要があります。AWS は、運用レジリエンスとデジタル主権のための目的別ソリューションを提供しており、欧州主権クラウドも含まれています。これらのソリューションにより、製造業者はイノベーションを遅らせることなく規制要件を満たすことができます。ブースの欧州主権クラウドの展示にお越しいただき、さらに詳しく学んでください。 ブースにお越しください Hannover Messe 2026 では、ホール 15、ブース D76 の AWS ブースへお越しください。クラウド技術における最新の産業イノベーションをご覧ください。AI による製品の旅を体験し、AWS の専門家と会い、ガイド付きブースツアーに参加するか、シアターセッションに参加して、AWS が製造業者の産業 AI 変革をどのように支援し加速させているかについてさらに学んでください。 イベントの前に AWS の担当者に連絡してミーティングを予約してください。最新の情報については、 Hannover Messe 2026 イベントページ を訪れ、LinkedIn で AWS for Manufacturing をフォローしてください。 日本のお客様に向けた情報 日本からのお客様向けには、ハノーバー現地において、AWS の日本メンバーによる日本語でのブースのご案内や、個別ミーティング等を実施しています。上記リンクまたは担当の営業経由でお申し込みください。また、現地でも日本人スタッフにお気軽にお声がけください。 <!-- '"` --> 翻訳は、ソリューションアーキテクトの山本が行いました。 Emily O’Kelly Emily は AWS のインダストリープロダクトマーケティングマネージャーです。彼女は産業および製造部門でのイノベーションとデジタル変革を推進することを専門としています。Emily は、明確で差別化されたメッセージング、説得力のあるユースケースの作成、サービスと機能を位置づけるために協力して働くことで、業界の変革を推進するインパクトのある瞬間を作り出すことに熱心です。Emily はロードアイランド大学で産業システム工学の学位を取得し、サザンニューハンプシャー大学で MBA を取得しています。

月刊 AWS 製造 2026年3月号 みなさん、こんにちは。AWS のソリューションアーキテクトの山田です。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 先月号は こちら です。未読の方はあわせてご覧ください。 今月は、ピックアップコンテンツとして製造業における Agentic AI の活用を特集します。 ピックアップトピック – Agentic AI × 製造業 Agentic AI（エージェンティック AI）は、人間の指示に基づいて自律的にタスクを計画・実行し、ツールを活用しながら目標を達成する AI システムです。2月には Amazon と OpenAI の 戦略的パートナーシップ が発表され、OpenAI モデルを活用した Stateful Runtime Environment を共同開発し、Amazon Bedrock を通じてユーザーに提供することが明らかになりました。AWS 上で利用可能な AI モデルのエコシステムがさらに拡充される中、製造業においても Agentic AI の具体的な適用事例が急速に増えています。今月はその中から 4 つのコンテンツをご紹介します。 品質管理：BMW Group — AWS 上の Agentic Search でペタバイト規模のデータからインサイトを抽出 BMW Group unlocks insights from petabytes of data with agentic search on AWS は、BMW Group が AWS Professional Services と協力して構築した Agentic Search ソリューションの事例です。20 PB のデータを保有する Cloud Data Hub に対し、Amazon S3 Vectors によるセマンティック検索、Amazon Athena による SQL フィルタリング、LLM による網羅的分類を組み合わせた 3 つの検索アプローチを AI エージェントが自動的に使い分けます。エージェントのオーケストレーションには Amazon Bedrock AgentCore と AWS のオープンソースフレームワーク Strands Agents を使用しており、技術スキルに関係なく自然言語でデータインサイトを抽出できる仕組みです。製品品質データの分析を例に、製造業におけるデータ駆動型意思決定の実践例として注目の内容です。 調達：Amazon Bedrock AgentCore を使用した AI エージェントによる調達ワークフローの自動化 Automate Procurement Workflows with AI Agents using Amazon Bedrock AgentCore は、製造業の調達プロセスに Agentic AI を適用した実践的なブログ記事です。Amazon Bedrock AgentCore を活用して、コンプライアンス検証、サプライヤー推薦、財務分析、RFQ（見積依頼）管理といった複雑なマルチステップの調達タスクを自律的に処理する AI エージェントの構築方法を解説しています。 研究開発：メック株式会社の事例 — Amazon Bedrock AgentCore で研究業務を効率化 メック株式会社の事例 では、AI エージェントを活用した研究業務の効率化が紹介されています。Amazon Bedrock AgentCore Runtime と Amazon S3 Vectors を利用し、ベテラン社員の検索ノウハウを AI エージェントとして実装することで、経験年数に関わらず高品質な情報アクセスを実現しています。AWS 主催のハッカソンをきっかけに約 3 週間で PoC を構築した点も注目です。 物流・SCM：Agentic AI でサプライチェーン ロジスティクスを変革 Agentic AI でサプライチェーン ロジスティクスを変革 は、シンガポールの A*STAR（科学技術研究庁）と AWS ProServe が共同開発した物流エージェントの事例を中心に、AI エージェントが ERP・TMS・WMS などの複数システムからリアルタイムデータを集約し、手動検索の作業負荷を最大 50% 削減する効果が紹介されています。複数の専門エージェントが協調するアーキテクチャは、製造業のサプライチェーン管理に直接適用できる内容です。 製造関連の主要なアップデート 2/12 Amazon EC2 M8azn インスタンスの一般提供開始 第5世代 AMD EPYC プロセッサを搭載し、最大 5 GHz のクロック周波数を実現する M8azn インスタンスが一般提供開始となりました。M5zn と比較して最大 2 倍のコンピューティング性能、4.3 倍のメモリ帯域幅、10 倍の L3 キャッシュを提供します。東京リージョンを含む 4 リージョンで利用可能で、製造業における CAE シミュレーションや設計最適化のワークロードに大きな恩恵をもたらすインスタンスタイプです。 2/17 Amazon EC2 Hpc8a インスタンスの一般提供開始 同じく第5世代 AMD EPYC プロセッサを搭載する Hpc8a インスタンスが一般提供開始となりました。192 コア、768 GiB メモリ、300 Gbps の Elastic Fabric Adapter（EFA）ネットワーキングを備え、前世代 Hpc7a と比較して最大 40% 以上の性能向上を実現します。 こちらのブログ でインスタンスの詳細が説明されています。また、 CAE アプリケーションを含むパフォーマンスの技術詳細ブログ も公開されており、ANSYS Fluent で約 50〜59%、Siemens StarCCM+ で約 36〜44%、ANSYS Mechanical で約 45%、LS-DYNA で約 51% の性能向上（いずれも Hpc7a 比）が報告されています。計算集約型のシミュレーション、エンジニアリングワークロード、密結合 HPC アプリケーションに最適です。 2/27 Amazon と OpenAI が戦略的パートナーシップを発表 Amazon が OpenAI に 500 億ドルを投資し、OpenAI モデルを活用した Stateful Runtime Environment を共同開発し、Amazon Bedrock を通じてユーザーに提供する戦略的パートナーシップが発表されました。ピックアップトピックでもご紹介した通り、Agentic AI の基盤がさらに強化されます。 直近で開催予定のイベント・セミナー AWS re:Invent 2025 re:Cap 製造業界編（オンデマンド配信中） re:Invent 2025 で発表された製造業関連のアップデートを日本語で解説する AWS Black Belt Online Seminar の re:Cap が公開されています。2部構成で、Part 1 では全体動向・スマート製造・サプライチェーン、Part 2 では製品設計・スマート製品を取り上げています。 Part 1（全体、スマート製造、サプライチェーン）： 動画 ｜ 資料 Part 2（製品設計、スマート製品）： 動画 ｜ 資料 NVIDIA GTC 2026（3/16〜19、サンノゼ） NVIDIA GTC 2026 が3月16日から19日にかけてサンノゼで開催されます。AWS は Booth #921 にて、フィジカル AI アプリケーションや Agentic AI など 6 つのドメインにわたる展示を行います。 Hannover Messe 2026（4/20〜24、ドイツ・ハノーバー） 世界最大級の産業技術展示会 Hannover Messe 2026 が4月20日から24日にドイツ・ハノーバーで開催されます。約 4,000 社の出展者が自動化、デジタル化、エネルギーシステムにわたる産業変革を展示する予定です。AWS もスマート生産やフィジカル AI に関する 展示 を行います。開催に先立ち、ブログでの事前情報公開も予定しています。また、日本人スタッフも現地に参加し、展示内容のご紹介を行いますので、ご来場予定の方はぜひお立ち寄りください。 AWS re:Invent 2026（11/30〜12/4、ラスベガス） AWS re:Invent 2026 が11月30日から12月4日にラスベガスで開催されることが発表されています。 事例のご紹介 製造業に関連する事例や、ブログによる技術詳細説明です。ピックアップトピックでご紹介した BMW Group の Agentic Search 事例 や メック株式会社の AI エージェント事例 もあわせてご覧ください。 日産が AWS と協業し SDV 開発を加速 日産自動車が AWS 上に構築した Nissan Scalable Open Software Platform による Software-Defined Vehicle（SDV）開発の加速について紹介されています。車両ソフトウェアのテスト実行時間を 75% 短縮し、世界中の 5,000 人以上の開発者を統一された開発エコシステムで接続しています。自動車産業における次世代ソフトウェアプラットフォームの構築事例として、製造業全般にも示唆に富む内容です。 Toyota Motor Europe が Amazon Bedrock でメインフレームモダナイゼーションを加速 Toyota Motor Europe が Deloitte および AWS Generative AI Innovation Center と連携し、Amazon Bedrock を活用して保証処理用レガシーメインフレームアプリケーションのソースコードからドキュメントを自動生成する取り組みが紹介されています（英語記事）。製造業では長年稼働してきたレガシーシステムの近代化が共通の課題であり、生成 AI を活用したアプローチとして参考になります。 製造関連ブログのご紹介 今月もたくさんのブログが公開されました。 1/28 AWS Well-Architected Modern Industrial Data Lens で製造ワークロードを加速 製造業のデジタルトランスフォーメーションを加速するための新しい AWS Well-Architected Modern Industrial Data Lens が公開されました（英語記事）。モダンな産業データアーキテクチャ（MIDA）基盤の構築、産業データカタログの実装、データメッシュアーキテクチャ、ナレッジグラフによるデジタルスレッド、コンピュータービジョンによる品質検査の 5 つのシナリオをカバーしています。 ホワイトペーパー もあわせてご参照ください。 2/6 VAMS における NVIDIA Isaac Lab を使用した GPU アクセラレーション型ロボットシミュレーショントレーニング AWS が提供するオープンソースの Visual Asset Management System（VAMS）は、3D モデルやシミュレーション環境などのビジュアルアセットをクラウド上で一元管理するためのソリューションです。今回、NVIDIA Isaac Lab との統合により GPU アクセラレーテッドな強化学習に対応しました。AWS Batch でスケーラブルな GPU コンピューティングを活用し、ロボットアセットのシミュレーショントレーニングからポリシー取得までをシームレスに実行できます。先月号で特集したフィジカル AI の実践的な開発基盤として注目のコンテンツです。 2/18 AWS で NVIDIA Cosmos world foundation models を実行 自律走行車、ロボティクス、スマートファクトリー向けのフィジカル AI 開発に必要な合成データを大規模に生成するための NVIDIA Cosmos ワールドファウンデーションモデル（WFM）を AWS 上でデプロイする方法を解説した日本語ブログです。Amazon EKS を使用したリアルタイム推論と AWS Batch を使用したバッチ推論の 2 つの本番環境向けアーキテクチャが紹介されています。製造業におけるフィジカル AI のデータパイプライン構築に参考になる内容です。 2/19 「導入しても使われない」を解決する ― 三菱電機 電力ICTセンターが Kiro と GitLab で実現した開発ワークフローの標準化 三菱電機 電力システム製作所 電力ICTセンターが、AI コーディングアシスタント Kiro と GitLab を組み合わせて開発ワークフローの標準化に取り組んだ事例です。Kiro の Steering（常時適用のグラウンドルール）、Powers（動的に呼び出されるワークフロー定義）、MCP（外部ツール連携）の 3 層構造を活用し、「ドキュメントを読まなくても、AI に聞けばワークフローに沿った開発ができる」仕組みを実現しています。製造業のソフトウェア開発効率化に関心のある方にぜひご覧いただきたい内容です。 2/25 Agentic AI でサプライチェーン ロジスティクスを変革 ピックアップトピックで詳しくご紹介しています。Agentic AI によるサプライチェーン物流の変革について、マルチエージェントアーキテクチャの設計パターンを含めて解説したブログです。 3/3 三菱電機のエンジニア 33 名が 3 日間で体感した AI 駆動開発の可能性 — AI-DLC Unicorn Gym 座談会 三菱電機 電力システム製作所 電力ICTセンターで開催された「AI-DLC Unicorn Gym」の座談会記事です。33 名のエンジニアが 3 日間にわたり、AI 駆動開発ライフサイクル（AI-DLC）を体験。5 チームがそれぞれ実際の業務課題（既存業務システム改良、IoT プラットフォーム改善、ダッシュボード開発など）に取り組み、AI を開発の中心的な協力者として活用する手法を実践しました。製造業における AI 駆動開発の組織的な導入事例として参考になります。 3/4 コネクテッドモビリティワークロードの DR 戦略 パート 1: バックアップとリストア コネクテッドモビリティ（CM）のワークロードにおける災害復旧（DR）戦略について解説するシリーズの第 1 弾です。車両接続、データ取り込み、可視化コンポーネントに対するバックアップとリストアの DR 戦略を、AWS Connected Mobility Reference Architecture に基づいて詳述しています。自動車製造業のお客様にとって、コネクテッドカーサービスのレジリエンス確保に役立つ内容です。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？今月は Agentic AI の製造業への適用を中心に、幅広いアップデートをお届けしました。このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 山田 航司 (Koji Yamada) AWS のソリューションアーキテクトとして、製造業のお客様を中心にクラウド活用の支援を行っています。製造業における業務課題解決や新規ビジネスにおけるクラウド活用の可能性をお客様と一緒に探求しています。

　 本稿は、三菱電機株式会社 名古屋製作所が新たに開発した AI を活用した商談支援サービス「 Memory Tech 」について、これを主導された三菱電機株式会社 名古屋製作所 江口 貴紀様、的場 祐弥様より寄稿いただきました。 はじめに 背景・課題 　 三菱電機株式会社 名古屋製作所 (以下、当製作所) は、FA (Factory Automation) 機器の開発・製造を手がける拠点です。シーケンサをはじめとする制御機器は製造業の現場で広く使われており、当製作所はこれまで製品の品質向上や機能強化を通じてお客様の課題解決に取り組んできました。 　 しかし、製品そのものの改善だけではお客様の課題を全て解決できるわけではありません。当製作所では、従来の製品起点のアプローチから一歩踏み出し、お客様の業務プロセス全体に目を向ける取り組みを開始しました。製造業のお客様に対して、商談から納品までの全工程を対象に「どこに課題があるのか」を徹底的にヒアリングしました。設計者、営業、調達部門といった職種を問わず、経営層から担当者まで幅広くアンケートやインタビューを実施しています。当製作所としてこのような顧客起点のヒアリングを体系的に実施するのは初めての試みでした。 　 その結果、コミュニケーションの齟齬による手戻りが深刻な課題であることが明らかになりました。手戻りによるコスト的なロスは数百万円から、最大で数億円に達するケースもあり、回答者の過半数が手戻りを課題として挙げています。さらに齟齬の原因を掘り下げたところ複数の要因が特定され、その中でも「口頭による認識齟齬」が最も優先的に解決すべき課題として浮かび上がりました。 　 FA の商談現場では、億単位の高額装置であれば仕様書を作成するものの、比較的安価な装置の場合は口頭でのやり取りで済ませてしまうケースが多くあります。この習慣を変えることは現実的ではないと判断し、「現場の習慣を一切変えずに課題を解決する」という方針を立てました。喋るという行為は必ず発生するため、喋った内容をいかに正確に記録するかという発想から、商談支援サービスの開発に至っています。 　 なお、競合サービスの存在も検討しましたが、多くの方が課題と認識しているにもかかわらず既存のツールが使われていないという事実から、市場にはまだ十分に浸透していないと判断しました。展示会に出展した際にも「こんなことができるのか」という驚きの反応が多く、この領域にはまだ大きな可能性があると確信しています。 開発体制 　 Memory Tech の開発は、当製作所にとって複数の「初めて」が重なるチャレンジでした。アジャイル開発、Web プログラミング、クラウドネイティブなサービス開発。いずれも従来の製品開発とは異なる領域です。しかし、お客様の課題を迅速に解決するためには、従来のウォーターフォール型ではなく、仮説検証を素早く繰り返せるアジャイル開発が不可欠でした。当製作所はこの機会を、顧客課題の解決だけでなく、組織としての開発力を根本から強化する契機と位置づけています。 　 開発体制はスクラムを採用しました。プロダクトオーナー (PO) を江口が務め、スクラムマスターは社内メンバーが担当しています。テックリードには KDDI アジャイル開発センター株式会社 (以下、KAG) のエンジニアに担当いただき、技術面でのリードとスクラム運営のサポートをお願いしました。特筆すべきは、KAG との協業を単なる開発委託ではなく、スキルトランスファーの場として設計した点です。KAG のエンジニアとペアプログラミングを行いながら社内エンジニアの育成を並行して進め、将来的に自社メンバーだけで開発を回せる体制を見据えています。実際に、スクラムマスターがコードも書く「半々」のスタイルで実践力を高めており、少人数でも自律的に開発を進められるチームへと成長しています。 　 また、AWS からは初めてのクラウド活用ということもあり、技術選定の段階から手厚いサポートをいただきました。サーバーレスアーキテクチャの設計方針やコスト最適化に関する助言をいただき、少人数のチームでも安心してクラウドネイティブな開発に踏み出すことができました。 ソリューション概要 システム要件 　 PO からの要件は明確でした。特別な機材の購入は不要とし、営業担当者が普段使っている Web ブラウザやスマートフォンだけで録音から議事録生成までを完結できること。そして、録音終了後 2 分以内に議事録を確認できること。この「その場で確認できる」というスピード感は、商談直後にお客様と内容を確認し合うために不可欠な要件でした。 採用方針 　 社内エンジニアは Web 開発やクラウド、インフラ運用の経験を持っていなかったため、インフラの管理・メンテナンスに工数を割くことなく、アプリケーション開発に集中できる環境が必要でした。また、成功するかどうかまだ未知数のサービスだからこそ、スモールスタートで始めて必要に応じてスケールできるクラウドのメリットを最大限に活かす方針としました。これらを踏まえ、AWS のマネージドサービスを最大限に活用したサーバーレス構成を採用しています。コスト面でも、サーバーレス構成による従量課金モデルにより、サービス開始当初の月額コストは数万円程度に抑えられました。また、初めてのクラウド活用ということもあり、AWS から手厚い技術サポートをいただけた点も大きな後押しとなりました。 要件に対応したソリューションの特徴 　 中核となるのは AWS Amplify Gen 2 です。AWS Amplify はフロントエンドからバックエンドまでをマネージドに提供するフルスタックの開発プラットフォームであり、AWS Amplify Gen 2 では AWS Cloud Development Kit (AWS CDK) ベースでインフラを定義できます。これにより、少ないコード量でバックエンド全体を構築でき、最初の議事録生成機能は約 1 ヶ月で PoC を開始できる状態に仕上がりました。KAG に AWS Amplify の豊富な実績があったことも、この技術選定を後押ししています。認証には Amazon Cognito を採用し、セキュリティの基盤を AWS に委ねることで、少人数のチームでも安全なサービスを提供できています。 　 バックエンドの処理フローは、 AWS Step Functions で構築したワークフローが中心です。録音データがアップロードされるとイベント駆動でバックエンド処理が開始され、文字起こしの結果が Amazon Bedrock に渡されて生成 AI が議事録を自動生成します。AWS Step Functions と AWS Lambda 、そして AWS Amplify のストレージやデータ機能を組み合わせ、全て Infrastructure as Code (IaC) で管理しています。この構成により、「ブラウザだけで完結」「2 分以内に議事録を確認」という PO の要件を実現しています。 　 Amazon Bedrock の採用は、AWS のエコシステム内で全てを完結できる点が大きなメリットでした。インフラ管理なしで生成 AI の機能を呼び出せるだけでなく、ストリーミングレスポンスにも対応しているため、ユーザーへの応答速度も確保できています。さらに、Amazon Bedrock が提供する複数の基盤モデルを柔軟に切り替えられる点も重要です。実際に Anthropic Claude のバージョンアップに合わせてモデルを切り替えたり、入力トークンが大きくなるフィラー削除処理には Amazon Nova を採用してコストを最適化するなど、用途に応じたモデルの使い分けを行っています。 図 1 : Memory Tech アーキテクチャ図 アプリケーション紹介 　 Memory Tech は、Web ブラウザまたはスマートフォンから利用できる、AI を活用した商談支援サービスです。ユーザーは商談や打ち合わせの音声をブラウザ上で録音するだけで、録音終了後 2 分以内に議事録が自動生成されます。特別な機材やアプリケーションのインストールは不要で、営業担当者が普段使っているデバイスだけで完結します。 　 生成される議事録は、単なる文字起こしではありません。Amazon Bedrock の生成 AI が会話の要点を抽出し、構造化された議事録として出力します。商談直後にその場でお客様と内容を確認できるため、「後から送っても見てもらえない」という従来の課題を解消しています。 図 2 : Memory Tech アプリケーション画面 ビジネス成果 　 Memory Tech は PoC の段階から非常に高い評価を得ています。社内外合わせて多くの方が PoC に参加し、アンケートのフィードバック結果も好評でした。無償 PoC に参加いただいた企業の多くがそのまま有償に移行しており、積極的なマーケティングは行わず、口コミベースでの展開にもかかわらず着実に契約数を伸ばしています。 　 社内利用はさらに急速に拡大しています。日々新たなユーザーが増加し、利用部門も FA 以外の事業部門にも広がっています。B2B の SaaS モデルとして解約率は極めて低く、安定的な収益基盤となることが期待されています。 　 技術面では、1,000 名を超えるユーザーが利用する状況においても、録音や議事録生成といったコア機能はスケーリングの問題なく安定稼働しています。少数精鋭の体制で、インフラの運用管理を意識することなくサービスを提供できている点は、AWS のマネージドサービスを全面的に採用した設計方針の成果といえます。1,000 人がアクセスしても問題なく動いていることに、開発した我々自身が一番驚いています。 　 また、Memory Tech はこれまで FA の主要顧客であった製造業の設計・生産技術部門だけでなく、営業や調達といった幅広い職種、さらには製造業以外の業界にも展開できる商材です。既存の取引先への新たな接点としても機能しており、当製作所の事業領域を広げるドアオープナーとしての役割も果たしています。 まとめと今後の展望 　 Memory Tech は、製造業の現場で長年見過ごされてきた「口頭コミュニケーションによる認識齟齬」という課題に対し、現場の習慣を変えることなく AI の力で解決するサービスです。AWS Amplify を中核としたサーバーレスアーキテクチャにより、少人数のチームでも迅速な開発と安定した運用を実現しました。 　 当製作所にとって、Memory Tech の開発はアジャイル開発や Web プログラミング、クラウドネイティブなサービス開発への初めての挑戦でもありました。KAG との協業によるスキルトランスファーを通じて社内の開発力を着実に高めており、この経験は今後の新規サービス開発の基盤となっています。 　 今後の展望として、まず海外リージョンでの SaaS 提供を視野に入れています。さらに、Memory Tech を単なる議事録ツールから「ビジネス支援プラットフォーム」へと進化させる構想があります。蓄積された会話データを活用し、商談におけるアドバイスの提供や、過去のナレッジを組織横断で活用できる仕組みなど、会話データを起点とした新たな価値創出を目指しています。 　 先行者として、ユーザーの声を取り入れながら AWS の開発スピードを活かし、常に一歩先を走り続けたいと考えています。 執筆者 江口 貴紀 三菱電機株式会社 名古屋製作所 ソフトウエアシステム部 エンジニアリングソフトウエア戦略グループ。Memory Tech の開発プロジェクトではプロダクトオーナー (PO) を務める。趣味の一つは旅行で、訪れた土地ならではのお酒や食事を楽しむことが大好き。 的場 祐弥 三菱電機株式会社 名古屋製作所 ソフトウエアシステム部 エンジニアリングソフトウエア戦略グループ。初めて触った AWS サービスである AWS Amplify Gen 2 に魅了される。FA (ファクトリーオートメーション) 業界の課題解決に取り組む新規事業企画に従事。Memory Tech を中核としたフルスタックエンジニアとして、企画立案からプロトタイプ、実装、運用まで一貫して担当。

本投稿は、 2025 年 10 月 21 日に公開された記事 「 Restore self-managed Db2 Linux databases in Amazon RDS for Db2 」を翻訳したものです。 より多くの組織がセルフマネージドの Db2 on Linux ワークロードを Amazon Relational Database Service (Amazon RDS) for Db2 へ移行するにつれ、移行チームは「準備こそがプロジェクト遅延を防ぐ鍵」であることを学んでいます。よくある障壁として、移行プロセス中に表面化する古いデータベースバージョン、無効なオブジェクト、不適切なストレージ設定などが挙げられます。本記事では、これらの問題をスケジュールに影響を与える前に検出する Db2 移行前提条件検証ツール (Db2 Migration Prerequisites Validation Tool) を紹介します。このツールは徹底的な移行前検証を実施し、セルフマネージド Db2 on Linux から Amazon RDS for Db2 への移行に必要な準備をガイドします。 ソリューション概要 Db2 移行前提条件検証ツールは、移行準備状況を確認するため、さまざまな検証カテゴリにわたって包括的な移行前評価を実施します。不整合が検出された場合、ツールは修正のための具体的かつ実行可能な推奨事項を提示します。これらの詳細な情報により、データベース管理者や移行チームが潜在的な問題に体系的に対処できます。特定された問題は、Amazon RDS for Db2 へのリストアに使用される最終的なオンプレミス Db2 バックアップを作成する前に解決する必要があります。 このプロアクティブなアプローチにより、障害を減らし、Amazon RDS for Db2 へのスムーズな移行を実現します。セルフマネージド Db2 データベースを Linux から Amazon RDS for Db2 へ移行するステップバイステップのガイダンスについては、 Amazon RDS for Db2 の Linux から Linux への移行 を参照してください。 以下の図は、オンプレミスのセルフマネージド Db2 データベース（Linux）から Amazon RDS for Db2 への正常なリストアを実現するための一般的なプロセスフローを示しています。 ツールの主な機能は以下のとおりです： クロスプラットフォームサポート： Linux on x86、Linux on POWER に対応 古い bash バージョン (訳注: bash 3.1 以降) との互換性あり 標準 Unix ツール以外の外部依存関係なし Linux 以外のプラットフォームやその他の移行オプションには Db2 Migration Tooling （Db2MT）の使用を検討 移行の詳細については Migrate from self-managed Db2 to Amazon RDS for Db2 using AWS DMS および Amazon RDS for Db2 へのデータマイグレーション戦略 を参照 複数の操作モード： インタラクティブモード – ユーザープロンプトによるガイド付き操作 非インタラクティブモード – スクリプト向け自動実行 リモートモード – リモート Db2 データベースへの接続と検証 包括的なレポート： カラーコード付きコンソール出力 タイムスタンプ付き詳細ログファイル 各チェックの PASS/FAIL/WARNING ステータス 失敗時の実行可能な推奨事項 インベントリ分析： 完全なデータベースオブジェクトインベントリ 移行準備状況の健全性チェック タイプ別オブジェクト数サマリー ツールは以下のシナリオで使用できます： 移行前計画 – 潜在的な問題を早期に特定し、修正のための時間を確保するため 移行準備状況評価 – Amazon RDS for Db2 への移行プロセス開始前の最終検証のため Fix Pack(s) 適用後 – Db2 Fix Pack 適用後にデータベースを検証し、適切な更新完了を確認するため 最終 Db2 バックアップ前 – Amazon RDS for Db2 へのリストア前に準備完了を確認する（クリーンな出力はリストアの失敗を防ぐセーフガードとなる）ため。データベースバックアップコマンドの使用に関する一般的なガイダンスは後述します。 ツールの使い方 前提条件 開始前に、以下の前提条件と制限事項を確認してください： ローカルモード Db2 インスタンスが起動・アクセス可能であること SYSADM 権限を持つ Db2 サーバー上でツールを実行すること Db2 環境が適切に source されていること（ . ~/sqllib/db2profile ） Db2 インスタンスユーザー（例：db2inst1）として実行すること リモートモード Db2 クライアントがインストール・設定済みであること リモート Db2 サーバーへのネットワーク接続があること DBADM または SYSMAINT 権限を持つ有効な Db2 ユーザー認証情報があること データベースがカタログ済み、または db2dsdriver.cfg ファイルに DSN エントリが存在すること インタラクティブフローでは、ツールは以下の手順を実行します： Db2 バージョン情報を表示する 利用可能なインスタンスを一覧表示する 検証対象の現在のインスタンスを特定する 現在のインスタンス内のローカルデータベースを検出する Db2 サーバー上でスクリプトを実行できない場合はリモートデータベースを検証する 検証対象データベースを選択する 包括的な検証チェックを実行する 詳細レポートを生成する 以下のコマンドはインタラクティブ実行のコードです。 ツールの直接実行 curl -sL https://bit.ly/precheckdb2migration | bash ダウンロードして実行 curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh chmod +x db2_migration_prereq_check.sh ./db2_migration_prereq_check.sh リモートモード – 直接実行 export DB2USER=myuser export DB2PASSWORD=mypassword export DBNAME=mydatabase curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose リモートモード – ダウンロードして実行 curl -sL https://bit.ly/precheckdb2migration -o db2_migration_prereq_check.sh chmod +x db2_migration_prereq_check.sh export DB2USER=myuser export DB2PASSWORD=mypassword export DBNAME=mydatabase # リモートデータベースに対して検証を実行 ./db2_migration_prereq_check.sh --verbose 注意：リモート接続に使用する DBNAME 環境変数は、ローカルにカタログされたリモートデータベース名、または db2dsdriver.cfg ファイルで使用される DSN エントリ名である必要があります。 以下のコマンドは、Db2 サーバー上でローカル実行する非インタラクティブモードのコードです。 特定インスタンスの検証 DB2_INSTANCES=db2inst1 \ ./db2_migration_prereq_check.sh カスタムレポート出力先を指定 DB2_INSTANCES=db2inst1 \ REPORT_FILE_PATH=/opt/reports/db2_check.log \ ./db2_migration_prereq_check.sh 注意：「db2_inventory」プレフィックスのレポートは、スクリプトを起動したディレクトリに生成されます。 デバッグ用の詳細出力 DB2_INSTANCES=db2inst1 \ ./db2_migration_prereq_check.sh --verbose 複数インスタンスの実行では、各インスタンスで個別にツールを実行できます。以下のサンプルコードを参照してください： #!/bin/bash # 複数インスタンスの検証 INSTANCES=("db2inst1" "db2inst2" "db2inst3") REPORT_DIR="/var/log/db2_migration_checks" mkdir -p "$REPORT_DIR" for instance in "${INSTANCES[@]}"; do echo "Validating instance: $instance" su - "$instance" -c " . ~/sqllib/db2profile export REPORT_FILE_PATH='$REPORT_DIR/${instance}_migration_check.log' /path/to/db2_migration_prereq_check.sh " done ツール出力の理解 ツールをローカルで実行するか Db2 クライアント経由で実行するかによって、動作が若干異なります。 ローカル実行 以下のコマンドを実行すると、スクリプト db2_migration_prereq_check.sh がダウンロードされ即座に実行されます。 curl -sL https://bit.ly/precheckdb2migration | bash -s -- --verbose Db2 インスタンス上でローカル実行した場合、すべてのローカルデータベースを特定し、それらに対して検証を実施します。 出力には Db2 バージョン、検出されたローカルデータベース数、検証結果、データベースサイズ、インベントリ分析が表示されます。 リモート実行 リモート実行の場合、スクリプト実行前に DB2USER、DB2PASSWORD、DBNAME の3つの環境変数をエクスポートする必要があります。検証は一度に1つのデータベースに対してのみ実施されます。 検証チェックの内容 以下の表はさまざまなカテゴリのチェック内容を示しています。ツールはデータベースインベントリ分析も実施し、結果を db2_inventory_yyyymmdd_hhmmss.json としてローカルに保存します。 カテゴリ チェック内容・推奨事項・修正方法 db2updv115 最新の Amazon RDS for Db2 ソフトウェアを使用して RDS for Db2 インスタンスを作成していることを確認してください。IBM は db2updv115 ツール使用時に Db2 インスタンスクラッシュを引き起こす 既知の問題 を文書化しており、修正は Amazon RDS for Db2 ソフトウェアの最新リリースで提供されています。 これは RDS Db2 リストア失敗の最も一般的な原因の一つです。 db2updv115 ツールがデータベースで実行されたかどうかを検証する良い方法はありません。 推奨： db2updv115 -d &lt;DBName&gt; InDoubt Transaction（未確定トランザクション） 未確定トランザクションとは、準備済みだがまだコミットもロールバックもされていないトランザクションです。 すべてのトランザクションをコミットまたはロールバックする必要があります。 推奨： db2 list indoubt transactions with prompting Invalid Objects（無効オブジェクト） すべての無効オブジェクトを再検証またはドロップする必要があります。 推奨： db2 "call SYSPROC.ADMIN_REVALIDATE_DB_OBJECTS()" （複数回実行が必要な場合あり） Tablespace Check（テーブルスペースチェック） すべてのテーブルスペースが Normal 状態である必要があります。 推奨： テーブルスペースの状態は 20 種類以上あります。状態に応じて適切な対処を行ってください。IBM の ドキュメント の各テーブルスペース状態の説明を参照してください。 Non-Fenced Routines（ fenced でないルーティン） すべてのルーティンは fenced である必要があります。 推奨： fenced ではないルーティンは Amazon RDS for Db2 では許可されていません。すべてのルーティンを fenced に変換してください。 Automatic Storage（自動ストレージ） Amazon RDS for Db2 へのリストア失敗の一般的な原因です。少なくとも1つのストレージグループが存在する必要があります。 推奨： db2 "CREATE STOGROUP &lt;name&gt; ON '&lt;PATHname&gt;'" Database Config（データベース設定） 以下のパラメータが No である必要があります： Backup pending Rollforward pending Restore pending Upgrade pending Database Config（データベース設定） 循環ログの場合、ログファイル数は254以下であること。 アーカイブログの場合、ログファイル数は4096以下であること。 Database Sizing（データベースサイジング） Amazon RDS for Db2 のサイジング時は、データベースとログスペースの合計を考慮してください。 推奨： db2_migration_prereq_report_yyyymmdd_hhmmss.log の RDS_SIZING_TIER 変数を参照してください。 Federation（フェデレーション） すべての DBMS へのフェデレーションは Amazon RDS for Db2 でサポートされていません。サポートされていない DBMS へのフェデレーションがあっても Amazon RDS for Db2 へのリストア失敗は発生しませんが、アプリケーションがサポートされていない DBMS へのフェデレーションに依存している場合は機能が失われます。 推奨： サポートされているライブラリは libdb2drda.so と libdb2rcodbc.so です。 Java stored procedures（Java ストアドプロシージャ） データベースに JAR ファイルが定義されている場合（sysibm.sysjarcontents）、必要に応じて RDS for Db2 インスタンスに JAR ファイルを追加してください。 推奨： インストール： call sqlj.install_jar('jar-url', 'jar-id') → 例： call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 置換： call sqlj.replace_jar('jar-url', 'jar-id') → 例： call sqlj.install_jar('file:/home/rdsdb/Common.jar', 'COMMON') 削除： db2 "sqlj.remove_jar('jar-id') → 例： call sqlj.remove_jar('COMMON') レポートの読み方と対応 以下の表は生成されるレポートをまとめたものです。 レポート名 詳細 db2_migration_prereq_report_yyyymmdd_hhmmss.log スキャンされたすべてのデータベースのチェック、推奨事項、修正方法を含むレポート。 db2_inventory_detail_ yyyymmdd_hhmmss.txt スキャンされた各データベースのテーブルスペース数、テーブル数、ビュー数、インデックス数などのインベントリ詳細。 db2_inventory_summary_ yyyymmdd_hhmmss.txt スキャンされたすべてのデータベースのインベントリ情報サマリー。 db2_inventory_ yyyymmdd_hhmmss.json スキャンされた各データベースのインベントリ詳細（JSON形式）。 DATABASE READINESS ステータスを確認するには DATABASE SUMMARY セクションに移動してください： ========================================== DATABASE SUMMARY: DB2DB ========================================== Checks performed: 15 Passed: 15 Warnings: 0 Failed: 0 Informational: 48 ========================================== DATABASE READINESS: READY Database DB2DB passed all checks ========================================== 移行準備レベルは以下のとおりです： READY FOR MIGRATION（移行準備完了）： すべてのチェックが合格（PASS ステータス） 重大な問題なし データベースのバックアップおよび Amazon RDS for Db2 へのリストア準備完了 REVIEW REQUIRED（要確認）： 一部の警告あり 推奨事項の手動確認が必要 考慮事項はあるが移行は可能 NOT READY FOR MIGRATION（移行不可）： 重大な失敗あり 移行前に失敗したチェックへの対処が必須 移行を進めるべきではない ベストプラクティス 以下のベストプラクティスを考慮してください： 早期かつ頻繁に実行する： 移行計画フェーズ中に実行する データベース変更後に再実行する バックアップ作成直前に検証する 問題に体系的に対処する： まず FAIL 項目を修正する（ブロッキング問題） WARNING 項目を潜在的リスクとして確認する INFO 項目を参考情報として文書化する 複数データベースの自動化： 自動化には非インタラクティブモードを使用する マルチインスタンス環境向けスクリプトを作成する 定期的な検証実行をスケジュールする ドキュメントの維持： 監査証跡として検証レポートを保管する 実施した修正アクションを文書化する 検証履歴を時系列で追跡する 高度な使用シナリオ 以下のコードは継続的インテグレーションのシナリオを示しています： #!/bin/bash # CI/CD パイプライン統合 DB_VALIDATION_EXIT_CODE=0 for instance in $(db2ilist); do su - "$instance" -c " . ~/sqllib/db2profile /path/to/db2_migration_prereq_check.sh " || DB_VALIDATION_EXIT_CODE=1 done if [ $DB_VALIDATION_EXIT_CODE -ne 0 ]; then echo "db2 validation failed - blocking deployment" exit 1 fi 以下のコードは定期監視のシナリオを示しています： #!/bin/bash # 定期検証用 Cron ジョブ # 0 2 * * 1 /path/to/weekly_db2_validation.sh REPORT_DIR="/var/log/db2_weekly_checks" mkdir -p "$REPORT_DIR" DATE=$(date +%Y%m%d) for instance in $(db2ilist); do su - "$instance" -c " . ~/sqllib/db2profile export REPORT_FILE_PATH='$REPORT_DIR/${instance}_${DATE}.log' /path/to/db2_migration_prereq_check.sh " done # サマリーメールを送信 mail -s "Weekly db2 Validation Report" admin@company.com &lt; "$REPORT_DIR/summary_${DATE}.txt" よくある問題のトラブルシューティング 以下の表はよくある問題とトラブルシューティングのヒントを示しています。 問題 トラブルシューティング db2 コマンドが見つからない # db2 環境をソースする . ~/sqllib/db2profile # Db2 インストールを確認 which db2 echo $DB2INSTANCE Db2 インスタンスが見つからない # インスタンスが起動しているか確認 db2ilist # ユーザー権限を確認 whoami id データベースに接続できない # データベースディレクトリを確認して手動接続を試みる db2 list db directory db2 connect to &lt;dbname&gt; 接続に時間がかかりすぎる # データベースをアクティベート db2 activate db &lt;dbname&gt; db2 list active databases 権限エラー # Db2 インスタンスユーザーとして実行していることを確認 su - db2inst1 # 権限を確認 db2 "SELECT * FROM TABLE(SYSPROC.AUTH_LIST_AUTHORITIES_FOR_AUTHID('DB2INST1'))" データベースバックアップコマンドの一般的なガイダンス データベースバックアップコマンドを使用する際は、以下のベストプラクティスを考慮してください： Amazon RDS for Db2 は Amazon Simple Storage Service （Amazon S3）のストリーミング機能を使用して並列ストリームでデータベースをリストアします。S3 ストリーミングはマルチパートファイルのバックアップイメージで最も効果的です。例えば、 db2 backup database &lt;dbname&gt; to /backup コマンドは単一イメージを生成しますが、パフォーマンス面で最適ではありません。代わりに db2 backup database to /backup, /backup, /backup, /backup, /backup のように複数のロケーションを指定してください。この例では、バックアップ操作が並列実行され、データベースイメージが .001 、 .002 、 .003 、 .004 、 .005 の5つのパートに分割されます。 小規模データベースでもマルチパートバックアップの使用を検討してください。Linux マシンの CPU とメモリ能力に基づいてロケーション数を決定します。不明な場合は20ロケーションの使用を推奨します。 セルフマネージド Db2 から AWS リージョンのネットワークへの接続がある場合、Amazon S3 への直接バックアップを検討してください。データベースのマルチパートイメージを Amazon S3 にコピーするには、必要な権限を持つバケットをアカウントに作成し、そのバケットを使用して db2 ストレージアクセスエイリアス を作成します。 ストレージエイリアス作成時の考慮事項： Db2 on EC2 を使用する場合、Amazon S3 バケットへのアクセスに適切な IAM ロールを付与し、ストレージエイリアス作成コマンドに USER 、 PASSWORD 、 TOKEN を指定しないでください。 コマンド例 db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER https://s3.&lt;region&gt;.amazonaws.com" CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt; セルフマネージド Db2 を使用する場合、AWS CLI 認証情報を取得してストレージエイリアスを作成できます。 長期認証情報を使用する場合： db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER s3.&lt;region&gt;.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt;" 短期認証情報を使用する場合： db2 "CATALOG STORAGE ACCESS ALIAS &lt;aliasName&gt; VENDOR S3 SERVER s3.&lt;region&gt;.amazonaws.com USER $AWS_ACCESS_KEY_ID PASSWORD $AWS_SECRET_ACCESS_KEY CONTAINER &lt;container-name&gt; DBUSER &lt;masterUserName&gt; TOKEN $AWS_SESSION_TOKEN" バックアップコマンドでストレージエイリアスを使用して、データベースバックアップイメージを Amazon S3 に直接書き込みます。例えば、作成したストレージエイリアスが db2S3 の場合、以下のコマンドを使用します： db2 backup database &lt;dbname&gt; to DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3, DB2REMOTE://db2S3 このコマンドにより、データベースのマルチパートイメージが S3 バケット内で5つのパートに分割されます。 データベースリストアコマンドの一般的なガイダンス データベースリストアコマンドを使用する際は、以下のベストプラクティスを考慮してください： データベースバックアップのマルチパートコピーが保存された S3 バケットへのアクセスに適切な AWS Identity and Access Management （IAM）ロールを持つ RDS for Db2 インスタンスの Amazon S3 統合 を有効にしていることを確認してください。 ストアドプロシージャ rdsadmin.set_configuration を使用して RESTORE_DATABASE_NUM_BUFFERS 、 RESTORE_DATABASE_PARALLELISM 、 RESTORE_DATABASE_NUM_MULTI_PATHS などのパフォーマンスパラメータを設定してください。 パラメータ USE_STREAMING_RESTORE を TRUE に設定して、Amazon S3 から Amazon RDS for Db2 への直接 S3 ストリーミングを有効にしてください。 Amazon RDS for Db2 は rdsadmin.restore_database ストアドプロシージャを使用してマルチパートバックアップイメージをリストアするための Db2 ストレージエイリアスを自動的に作成します。 rdsadmin.restore_database ストアドプロシージャで使用する s3_prefix 変数に注意してください。このプレフィックスは .001、.002 などの拡張子を除いたマルチパートバックアップイメージの共通部分です。 オンラインバックアップイメージを使用する場合、Db2 アーカイブログファイルを Amazon S3 にコピーし続け、 rdsadmin.rollforward_database ストアドプロシージャを実行してアーカイブログを適用する必要があります。すべてのログファイルを適用するまでこのプロセスを繰り返してください。各操作には異なるプレフィックスを使用してください。 すべてのログファイルを適用後、 rdsadmin.complete_rollforward ストアドプロシージャを実行して RDS for Db2 データベースを接続可能な状態にしてください。 手動手順の代わりにオンラインリストアの自動化には Db2MT ツール の使用を検討してください。 ツールの機能拡張 このツールのソースコードは以下の GitHub リポジトリ で公開されています。機能拡張のリクエストは Issue を登録 するか、変更提案は Pull Request として送信してください。 追加リソース Amazon RDS for Db2 と移行戦略の詳細については、以下のリソースを参照してください： Amazon RDS for Db2 ユーザーガイド Amazon RDS for Db2 へのデータマイグレーション戦略 AIX、Windows 上のセルフマネージド型 Db2 から Amazon RDS for Db2 へ IBM Q レプリケーションを使用してほぼゼロのダウンタイムで移行 セルフマネージド Db2 から Amazon RDS for Db2 へのフルロードおよび継続的レプリケーションタスクのパフォーマンス最適化 IBM Db2 for z/OS から Amazon RDS for Db2 へのテーブル移行 まとめ Db2 移行前提条件検証ツールは、一般的な問題を移行スケジュールに影響を与える前に特定・対処することで、移行失敗を大幅に削減します。このツールを移行ワークフローに組み込むことで、以下を実現できます： 移行リスクの低減 – プロセスの早期に問題を特定 時間の節約 – リストア失敗やトラブルシューティングを回避 成功率の向上 – データベースが適切に準備されていることを確認 ドキュメントの維持 – 詳細な検証記録を保持 Db2 のメンテナンスおよび移行プロセスの一部としてこのツールを定期的に使用することで、Amazon RDS for Db2 へのスムーズで成功した移行を実現できます。 このアプローチをご自身の環境で試しましたか？どのように機能したか、またはツールへの機能拡張要望があればぜひお知らせください。 著者について Vikram S Khatri Vikram は Amazon RDS for Db2 のSr. DBE です。Db2 において20年以上の経験を持ちます。ゼロからの新製品開発を楽しんでいます。余暇には瞑想を実践し、ポッドキャストを聴くことを楽しんでいます。 Umair Hussain Umair は Amazon RDS for Db2 のシニアデータベースエンジニアです。Db2 において20年以上の経験を持ちます。 Rajib Sarkar Rajib は Amazon RDS for Db2 のシニアデータベースエンジニアです。Db2 において20年以上の経験を持ちます。 この記事はクラウドサポートエンジニアの Shota Miyazaki が翻訳しました。

本記事は 2026 年 3 月 9 日 に公開された「 Kinesis On-demand Advantage saves 60%+ on streaming costs 」を翻訳したものです。 Amazon Kinesis Data Streams は、あらゆる規模のストリーミングデータをキャプチャ、処理、保存できるサーバーレスのストリーミングデータサービスです。2025 年 11 月 4 日、 Amazon Kinesis Data Streams に On-demand Advantage モードが導入されました。オンデマンドストリームで瞬時にスループットを増加させ、安定したストリーミングワークロードのコストを最適化できる機能です。従来はキャパシティを手動管理するプロビジョンドモードか、自動スケーリングするオンデマンドモードのどちらかを選ぶ必要がありましたが、On-demand Advantage の導入によりストリームタイプを意識する必要がなくなりました。 本記事では、使用パターンが異なる 3 つのシナリオを比較し、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながらストリーミングコストを最適化する方法を紹介します。正確に比較するため、2 つの AWS アカウントでシミュレーションを実施しました。1 つは On-demand Standard モード、もう 1 つはアカウントレベルで On-demand Advantage モードを有効にしたアカウントです。両方のデプロイで同一のストリーム構成、シャード割り当て、取り込みパターンを維持し、以下のシナリオで課金への影響を比較しました。 本記事に記載されている料金はすべて us-east-1 リージョンのものです。 On-demand Advantage の節約効果の内訳 前回の記事 では、ウォームスループット機能と、On-demand Advantage モードでストリームをウォームアップしてギガバイト単位や毎秒数百万レコードを処理する方法を紹介しました。次に、On-demand Advantage モードでパフォーマンスと柔軟性を維持しながら、さまざまなストリーミングユースケースがどのようにコスト効率よく運用できるかを説明します。 アカウントレベルで On-demand Advantage モードを有効にすると、On-demand Standard と比較して多くの面でコスト削減が得られます。主なポイントは以下のとおりです。 AWS リージョンで最低 25 MiBps の使用量をコミットすることで、60% 以上の節約が得られます。最低コミットメントは、AWS バージニア北部リージョンの 公開料金 に基づき 1 日あたり約 100 ドルです。 Enhanced Fan Out コンシューマーの料金が 68% 低くなり、ストリームあたり最大 50 まで利用可能です (On-demand Advantage なしでは 20)。 24 時間を超えるデータ保持の料金が 77% 低くなります。 ストリームごとの最低固定料金がないため、コスト増加なしに必要な数のストリームを利用できます。 Kinesis On-demand Advantage を選ぶ理由: 60% 以上の節約 Amazon Kinesis Data Streams の On-demand Standard モードと Advantage モードの両方を評価するため、10 個のストリームをデプロイし、全ストリームで合計 100 MiBps の持続的な取り込みスループットを生成しました。EC サイトがユーザーのクリックストリームデータをストリーミングしてリアルタイムインサイトを生成するケースをモデル化しています。シミュレーションは異なるモードの 2 つの AWS アカウントで 2 日間実施しました。1 日目は 100 MiBps の安定した取り込みレートを維持しました。2 日目は、ホリデーセールイベントに備えて 10 個すべてのストリームのウォームスループットキャパシティを 10 倍に増加させ、実際の取り込みレートは 100 MiBps のまま維持しました。各ストリームは 10 MiBps を取り込み、全オンデマンドストリームで合計 100 MiBps です。 2 日目に、On-demand Advantage モードを設定したアカウントで 100 MiBps のウォームスループットを有効にしました。ウォームスループットを使えば、トラフィック急増に備えてストリームを事前にスケールアップできます。 On-demand Standard の Cost Explorer: On-demand Advantage モードの Cost Explorer: シナリオ 1 で On-demand Advantage のコスト効率が高い理由は、安定したデータスループットと複数ストリームの利用にあります。Advantage モードではストリーム時間料金がゼロですが、On-demand Standard モードではストリーム時間あたり $0.04 の料金が発生します。さらに、Advantage モードの受信バイト料金は GB あたり $0.032 で、On-demand Standard は GB あたり $0.08 です。On-demand Standard 構成では 48 時間で合計 $2,071.75 のコストが発生し、1 日あたり $1,037、年間 $378,505 になります。同じワークロードを On-demand Advantage モードで実行すると、同じ 48 時間で $823.44、1 日あたり約 $412、年間コスト $150,380 です。On-demand Advantage ではウォームスループットの追加料金もかかりません。60% のコスト削減に相当し、このワークロードだけで年間 $228,125 の節約になります。 シナリオ 2: 1 アカウントで 10 ストリーム、15 MiBps スループットと延長保持 ある医療企業では、データの再処理に備えて 2 日間のデータ保持期間が必要であり、規制要件により異なる種類のデータを別々のストリームに保存する必要があります。シナリオ 2 の再現として、On-demand Standard モードと Advantage モードの両方で、48 時間の延長保持期間を設定した 10 個の Amazon Kinesis Data Streams をデプロイしました。延長保持により、ダウンストリームシステムはデータを再処理し、一時的な障害から復旧できます。複数ストリームと保持期間を利用するため、On-demand Advantage モードでコスト効率が高いと予想されます。コスト内訳を見ていきましょう。 コストを評価するため、10 ストリームに分散した 15 MiBps の安定した取り込みトラフィックを 48 時間生成しました。On-demand Standard モード: On-demand Advantage モード有効時: Cost Explorer のスクリーンショットで、On-demand Standard モードと Advantage モードの料金を並べて比較できます。On-demand Standard の 1 日あたりのコストは $176 で、年間 $64,240 です。On-demand Advantage の 1 日あたりのコストは $104 で、年間コストは $37,960 です。15 MiBps のスループットと延長保持を利用しても、Advantage モードで 41% の節約を達成しました。Standard モードでは 24 時間を超え 7 日間までのデータ保存に GB あたり $0.10 の追加料金がかかります。Advantage モードでは 24 時間を超え 365 日間までのデータ保存に GB 月あたり $0.023 の追加料金となり、データストレージのコストが最適化されます。シナリオ 2 の結果は、Advantage モードがより幅広いワークロードでコストメリットをもたらすことを示しています。Advantage モードを有効にすると、最低 25 MiBps の使用量にコミットすることになります。しかし、15 MiBps スループットのシミュレーションでも大幅なコスト削減を達成しました。Advantage モードでは、10 MiBps 以上を取り込んでいれば、25 MiBps のしきい値にコミットしていても Standard モードより低コストになります。 シナリオ 3: 1 つの Kinesis Data Stream と 10 個の Enhanced Fan-Out コンシューマー マイクロサービスアーキテクチャでは、複数のサービスが同じデータストリームから同時に低レイテンシーで読み取る必要がある場合があります。システムの進化に伴い、新しい分析ユースケースをサポートし、ストリーミングデータパイプラインからより深いインサイトを得るために、Enhanced Fan-Out (EFO) コンシューマーが追加されることがあります。 次に、マイクロサービスアーキテクチャで On-demand Advantage モードを使用した EFO コンシューマーのコスト比較を評価します。24 時間にわたり、標準の 24 時間保持を設定した 1 つの Amazon Kinesis Data Stream に、EFO コンシューマーとして設定した 10 個の AWS Lambda 関数を接続してテストしました。 複数の EFO コンシューマーが同じストリームに同時にアクセスした場合のコスト影響を評価するため、評価期間を通じて 25 MiBps の安定した取り込みレートを生成しました。以下のチャートは、25 MiBps ペイロードの Enhanced Fan-Out コンシューマーを持つ Kinesis Data Stream を示しています。 以下のチャートは、On-demand Standard モードと On-demand Advantage モード有効時のコスト差を示しています。 Cost Explorer の分析から、複数の EFO コンシューマーを使用しても、On-demand Advantage モードの方が On-demand Standard モードより全体コストが低いことがわかります。On-demand Standard のコストは $1,266 で、Advantage モードのコストは $419 でした。同じワークロード特性で約 67% の節約を達成し、年間 $309,155 の節約になります。イベント駆動型アーキテクチャで複数のサービスがストリーミングデータへの独立したリアルタイムアクセスを必要とする組織にとって、EFO のコスト削減効果は特に大きいといえます。Enhanced Fan-Out のデータ取得料金は、Advantage モードではコンシューマーあたり GB あたり $0.016 で、Standard モードの $0.05 と比較して大幅に低くなっています。一方、持続スループットが低い (10 MiBps 未満) スパイクが大きく予測不可能なワークロードは、On-demand Standard の候補として推奨されます。スループット使用量をコミットせずに、ストリームのスループットキャパシティを自動スケーリングさせられます。 On-demand Advantage とプロビジョンドモードの比較: On-demand Standard モードと On-demand Advantage モードの両方が利用可能になったことで、プロビジョンドモードに頼る必要がなくなりました。キャパシティを手動管理する必要がなく、オンデマンドストリームならシンプルな料金モデルで運用できます。さらに、多数のストリームを運用したり、延長保持や Enhanced Fan-Out などの機能を使用しているプロビジョンドワークロードのお客様は、On-demand Advantage への移行を強く検討すべきです。データストリームはどのモードを選択しても同じ基盤インフラストラクチャを使用するため、On-demand Advantage とプロビジョンドの間で可用性や信頼性に違いはありません。 ウォームスループットに追加料金がかからないため、瞬時スケーリングが必要な場合は On-demand Advantage がプロビジョンドモードより適しています。 Gbps 規模でも、On-demand Advantage は実際のデータ使用量に基づく課金で競争力のある料金です。 On-demand Advantage は、EFO (マイクロサービスのような高ファンアウトニーズ向け) と延長保持の利用コストが大幅に低くなっています。 比較の参考として、Kinesis コンソールを使用して、アカウントの上位 200 のプロビジョンドストリームが On-demand Advantage に適しているかどうかを確認できます。 まとめ 本記事では、Amazon Kinesis Data Streams の On-demand Advantage モードがパフォーマンスと柔軟性を維持しながら大幅なコスト削減を実現する 3 つの実際のシナリオを紹介しました。On-demand Advantage は大規模ワークロードで優れたパフォーマンスを発揮し、On-demand Standard と合わせて、Kinesis Data Streams はさまざまなストリーミングユースケースにシンプルかつコスト効率の高いソリューションを提供します。ワークロードが安定して 10 MiBps 以上をストリーミングする場合、2 つ以上のコンシューマーにファンアウトする場合、24 時間を超えてデータを保持する場合、または数百のストリームを運用する場合は、On-demand Advantage が最もコスト効率の高いモードです。それ以外のワークロードには、On-demand Standard モードが適しています。多様なプロデューサーからコンシューマーへ毎秒数百万レコードやギガバイト単位のデータをストリーミングする場合でも、Kinesis Data Streams で対応できます。ぜひ Kinesis Data Streams On-demand Advantage を活用して、リアルタイムインサイトを組織やプロセスに取り入れてみてください。 著者について Sandhya Khanderia Sandhya は、AWS のシニアテクニカルアカウントマネージャー兼データ分析スペシャリストです。分析およびデータサービスの深い専門知識を持ち、パフォーマンス、スケーラビリティ、コスト効率に優れたクラウドアーキテクチャの最適化を支援しています。 Pratik Patel Pratik は、AWS のシニアテクニカルアカウントマネージャー兼ストリーミング分析スペシャリストです。AWS のお客様と連携し、ベストプラクティスに基づくソリューションの計画と構築を支援するとともに、お客様の AWS 環境の運用状態を健全に保つための継続的なサポートと技術ガイダンスを提供しています。 Varsha Palepu Varsha は、AWS のソリューションアーキテクトとして、中小企業のイノベーションと AWS 上での構築を支援しています。ストリーミングチームに所属し、技術コンテンツの作成やお客様のクラウド上での目標達成を支援しています。 Kalyan Janaki Kalyan は、Amazon Web Services のシニアビッグデータ＆分析スペシャリストです。高いスケーラビリティ、パフォーマンス、セキュリティを備えたクラウドベースソリューションの設計と構築を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Takayuki Enomoto がレビューしました。

2026 年 3 月 3 日、アマゾン ウェブ サービス ジャパン合同会社（以下、AWS ジャパン）は、「フィジカル AI 開発支援プログラム by AWS ジャパン」のキックオフイベントを東京の AWS 目黒オフィスにて開催しました。本プログラムは 2026 年 1 月 27 日に発表 し、応募受付を開始したもので、多数の応募の中から厳正な選考を経て採択された皆さまをお迎えし、約 6 ヶ月間にわたる開発支援の幕開けとなりました。 フィジカル AI の可能性 フィジカル AI とは、物理世界で動作する AI の総称です。ロボットや自動運転車、ドローンなど、現実世界のセンサー情報を理解し、自律的に判断・行動する AI 技術を指します。近年、大規模言語モデル（LLM）の急速な進化を背景に、言語だけでなく視覚情報と行動を統合的に扱う Vision-Language-Action（VLA）モデルをはじめとしたロボット基盤モデルの研究開発が世界的に加速しています。 日本は製造業やロボティクスにおいて世界をリードしてきた歴史があります。この強みと、生成 AI の最新技術を掛け合わせることで、日本発のフィジカル AI イノベーションが生まれる大きな可能性があると私たちは考えています。 AWS ジャパンは 2023 年の LLM 開発支援プログラムを皮切りに、生成 AI 実用化推進プログラムや経済産業省 GENIAC へ参画するお客様の支援など、これまでに 300 を超える企業・団体の生成 AI 開発を支援してきました。本プログラムは、その知見と実績をフィジカル AI 領域に展開するものです。 プログラム概要 本プログラムは、AWS 上でロボット基盤モデル等を開発する日本の企業・団体を包括的に支援するもので、データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築をカバーします。 技術支援 : ソリューションアーキテクト（SA）によるアーキテクチャガイダンス、Prototyping &amp; Cloud Engineering（PACE）チームによるサンプルコード提供、生成 AI イノベーションセンター（GenAIIC）によるロボット基盤モデル開発支援 コスト最適化支援 : AWS クレジットの提供（計算リソースおよびデータ保管等の利用を支援） コミュニティ形成 : フィジカル AI コミュニティ Powered by AWS として、技術勉強会・ワークショップの開催、エンジニア間の交流促進、業界横断の知見共有 GTM 支援 : モデル開発企業と製造業などロボット導入企業とのマッチング機会の提供、実証環境の提供支援、スタートアップ間の技術連携促進 支援期間は 2026 年 3 月から約 6 ヶ月間で、成果発表会を予定しています。プログラムの詳細は 発表時のブログ記事 をご覧ください。 キックオフイベントの様子 キックオフイベントは、採択企業の皆さまと AWS の支援チームが一堂に会する初めての機会となりました。 ご挨拶 イベントの冒頭では、アマゾン ウェブ サービス ジャパン合同会社 代表執行役員社長の白幡 晶彦よりプログラムに対するビジョンについてお話しさせていただきました。 Amazon Robotics の取り組みについて 続いて、アマゾンジャパン合同会社 オペレーション技術統括本部 技術開発本部長 ダイレクターの内田 昌宏より、Amazon Robotics の取り組みについて講演いたしました。 Amazon のフルフィルメントセンター（FC）では、商品の入荷から出荷までの一連のオペレーションにおいて、AI とロボティクスの融合が進んでいます。講演では、自動レシーブ、AI による在庫配置最適化、Amazon Robotics の自動倉庫システム、そして触覚センサーをもつ棚入れ・棚出しロボット Vulcan など、実際の物流現場で稼働するフィジカル AI の事例をご紹介しました。 特に、Vision と深層学習で作業者の手の動きをトラッキングしてロケーションデータを自動確定する Intent Detection System（IDS）や、ML と Vision を活用して在庫の過不足を自動検出する Visual Bin Inspection（VBI）といった、現場の課題を AI で解決する具体的な取り組みをお伝えしました。さらに、ML アルゴリズムによる最小梱包の自動指定や、生成 AI を活用したオペレーションマネジメントなど、AI が物流オペレーション全体に浸透している様子を共有いたしました。 白幡 晶彦 内田 昌宏 Amazon は世界各国の物流拠点で 100 万台を超えるロボットを運用しており、こうした大規模な実践から得られた知見を、本プログラムを通じて日本のフィジカル AI 開発者の皆さまと共有していきます。 プログラム支援内容の紹介 続いて、プログラムの具体的な支援内容、支援チームのメンバー紹介、今後の進め方についてご説明しました。 本プログラムの技術支援の柱のひとつとして、 Physical AI Scaffolding Kit（PASK） が紹介されました。PASK は、PACE チームが開発するフィジカル AI 開発者向けのツールキットで、開発ライフサイクル全体の課題を体系的に解決することを目指しています。 フィジカル AI の開発は、データ収集・前処理からモデル学習、シミュレーション、実機デプロイまで、多くのステップにまたがります。各ステップで必要となるインフラ構築やパイプライン設計に多大な時間を費やし、本来注力すべきモデル開発やアルゴリズム改善に十分なリソースを割けないという課題を、多くの開発者が抱えています。 PASK の第一弾として、Amazon SageMaker HyperPod 上で VLA のトレーニングを実行する環境のサンプルが 3 月後半に提供予定です。Physical Intelligence の openpi（π0）や NVIDIA Isaac GR00T のファインチューニングサンプルも含まれる予定で、プログラム参加企業へのヒアリングを通じて継続的にフィードバックを取り込み、PASK を進化させていきます。 また、PACE チームによるプロトタイピング支援も提供されます。参加企業が実現したいフィジカル AI システムのプロトタイプを、AWS 上に共同で開発するプログラムで、トレーニング可能な標準化されたデータパイプラインの構築や、スケーラブルなトレーニング環境の整備、Sim2Real 等の技術的ブロッカーの解決を支援します。 さらに、 GenAIIC は、世界中の生成 AI エキスパートの知見に基づくベストプラクティスを共有し、VLA 開発の支援実績を活かしてソリューションの構築・展開を支援します。 採択企業によるピッチ キックオフのメインセッションとして、採択企業の皆さまによるピッチが行われました。会場に参加いただいた企業を中心に、それぞれが取り組むフィジカル AI の課題とビジョンを共有しました。 ロボットメーカー、AI スタートアップ、製造業、大学研究機関など、多様なバックグラウンドを持つ企業・団体が集まり、産業用ロボットの知能化、自律移動ロボット、マニピュレーション、ヒューマノイドなど、幅広い領域のプロジェクトが紹介されました。参加者同士が互いの取り組みを知り、刺激を受け合う貴重な機会となりました。 なぜコミュニティが重要なのか – 日本のフィジカル AI エコシステムの構築に向けて キックオフイベントの後半では懇親会が開催され、採択企業の皆さまと AWS チームが活発に交流しました。この「つながり」こそが、本プログラムが最も大切にしている要素のひとつです。 日本のフィジカル AI 業界の現状と課題 フィジカル AI の開発には、ソフトウェアだけの AI 開発とは異なる固有の課題があります。 データ収集の困難さ : ロボット基盤モデルの学習には、現実世界での大量の行動データが必要です。しかし、実機でのデータ収集はコストと時間がかかり、一社単独で多様なデータを網羅的に集めることには限界があります。シミュレーション環境の構築や合成データの生成といった技術的アプローチが重要性を増しており、本プログラムでもこうした取り組みを支援していきます。 ハードウェアとソフトウェアの融合 : フィジカル AI は、AI モデルの開発だけでなく、センサー、アクチュエーター、制御系、通信といったハードウェア領域との密接な連携が不可欠です。日本にはロボティクスや製造業で培われた優れたハードウェア技術がありますが、最新の生成 AI 技術との統合には、異なる専門領域をつなぐ人材やコミュニティが必要です。 研究と社会実装のギャップ : 大学や研究機関で生まれた先端技術を、実際の産業現場で使えるレベルまで引き上げるには、エンジニアリング、ビジネス、規制対応など多面的な取り組みが必要です。研究者と事業者が直接対話し、課題を共有できる場が不足しています。 計算資源へのアクセス : VLA モデルをはじめとするロボット基盤モデルの学習には、大規模な GPU コンピューティングリソースが必要です。特にスタートアップや大学研究室にとって、これらのリソースへのアクセスは大きなハードルとなっています。 コミュニティがもたらす価値 こうした課題は、一社や一組織だけで解決できるものではありません。だからこそ、本プログラムでは「コミュニティ形成」を 4 つの支援柱のひとつとして位置づけています。 知見の共有と相互学習 : 異なる領域で活動する企業・研究者が集まることで、技術的なブレークスルーや失敗からの学びを共有できます。キックオフイベントのピッチセッションでも、各社の発表に対して活発な質疑応答が行われ、分野を超えた知見の交換が始まっています。 エコシステムの形成 : ロボットメーカー、AI 開発企業、部品サプライヤー、エンドユーザー企業、大学研究機関 — フィジカル AI の社会実装には、これらのプレイヤーが有機的につながるエコシステムが必要です。本プログラムは、その核となるコミュニティを日本に作ることを目指しています。 日本の強みを活かしたグローバル競争力 : 日本のものづくりの精度、品質管理のノウハウ、そして産業用ロボットの豊富な運用実績は、フィジカル AI の開発において大きなアドバンテージです。これらの強みを生成 AI と融合させ、日本発のフィジカル AI ソリューションを世界に発信していくためには、国内のプレイヤーが連携し、互いの強みを補完し合うことが重要です。 コミュニティイベントの開催予定 本プログラムでは、キックオフイベントに続き、支援期間中に定期的なコミュニティイベントを開催していきます。技術的なディープダイブセッション、参加企業同士のコラボレーションワークショップ、外部有識者を招いた勉強会など、参加者の皆さまのニーズに応じた多様なプログラムを計画しています。 今後のスケジュール 時期 タイトル 内容 2026 年 3 月 24 日（火）午後 Physical AI on AWS アーキテクチャ勉強会 Physical AI 開発に必要なアーキテクチャの解説と PASK（preview）のご紹介 2026 年 4 月 3 日（金）16:30〜 フィジカル AI 開発支援プログラム Community Meetup #1 AWS Startup Loft Tokyo にて開催予定（内容調整中） 2026 年 4 月 9 日（水） 基盤モデル開発 Deep Dive AWS を活用した大規模モデルの学習から推論までを包括的に扱う終日セッション。午前は AWS ParallelCluster での分散トレーニングハンズオン、午後は SageMaker HyperPod アーキテクチャ、大規模 MoE モデルの推論最適化、AWS Trainium による基盤モデル構築、Physical AI モデル学習のスケーリングパスなどを解説 2026 年 4 月中 ロボット勉強会 AI 開発者がロボット業界に入っていく上で知っておくべき知識の共有（内容・日程調整中） 2026 年 6 月 25-26 日 Demo Day（中間報告会） AWS Summit Tokyo 2026（幕張メッセ） 2026 年 7 月下旬 最終成果報告会 AWS 麻布台ヒルズ オフィス 予定 おわりに キックオフイベントを通じて、日本のフィジカル AI の未来を担う多様なプレイヤーが一堂に会し、熱気あふれるスタートを切ることができました。ロボティクスと生成 AI の融合は、製造業、物流、農業、医療、インフラなど、あらゆる産業に変革をもたらす可能性を秘めています。 AWS ジャパンは、本プログラムを通じて日本のフィジカル AI エコシステムの発展に貢献してまいります。採択企業の皆さまの挑戦と、成果発表会をどうぞご期待ください。 関連リンク: フィジカル AI 開発支援プログラム by AWS ジャパン（発表ブログ） 木村 公哉（Kimura, Koya） アマゾン ウェブ サービス ジャパン合同会社 シニアスタートアップソリューションアーキテクト。2023 年よりディープテックスタートアップを担当。支援プログラムの立ち上げなどに尽力し、2025 年よりフィジカル AI をはじめとしたロボティクス関連領域にも支援を拡大。2026 年 1 月に「フィジカル AI 開発支援プログラム by AWS ジャパン」を発足。VC・政府とのディスカッションを通じ、フィジカル AI・ディープテック領域のエコシステム形成にも取り組んでいる。