みなさん、こんにちは。AWS のインダストリーソリューションアーキテクトの山本です。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 先月号は こちら です。未読の方はあわせてご覧ください。 今月は、ピックアップコンテンツとして昨年ごろから大きな潮流となりつつあるフィジカル AI を特集します。 ピックアップトピック – フィジカル AI フィジカル AI は物理システムの制御方法をこれまでのプログラムやルール、アルゴリズムベースからデータやモデルによって制御するという大きな転換に当たり、その方向性やもたらす価値について境界のない議論が行われています。 2026/1/27に AWS Japan が提供する フィジカル AI についての開発支援プログラム がアナウンスされました。VLA/VLM などのモデル開発について、技術支援やクラウド使用料クレジットの提供、さらにコミュニティ形成や GTM の支援を提供する取り組みで、お客様やパートナー様から大きな反響をいただいています。 フィジカル AI に関連するブログ・動画のご紹介 昨年後半からコンテンツが増加しているフィジカル AI についての有用なブログ記事を 5 本、日本語に翻訳しました。一部の記事については英語版を先月号で共有しています。前半の 3 本のブログはAWS がフィジカル AI をどの様に捉えるか、お客様がどの様にこれを活用しているかについてです。 2 本のブログと Youtube 動画は AWS を活用して NVIDIA の提供するモデルやシミュレータを動かすための実践的な内容です。 フィジカル AI: 自律型インテリジェンスに向けた次なる基盤を築く AWS のフィジカル AI フレームワークについての解説記事です。物理世界を認識、理解、推論、学習し、相互作用するハードウェアとソフトウェアのシステムとしてフィジカル AI を定義し、6 つの関連する機能からなる包括的なフレームワークを提示しています。クラウドでのトレーニングループとエッジでの自律ループを統合した二重ループアーキテクチャにより、継続的な学習サイクルを実現し、自律経済への移行を支援します。 AI による物理的な現実世界の進化 : インテリジェントな自動化の最前線 このブログは、AI と物理システムが融合したフィジカル AI のもたらす変革について解説しています。 4 段階のレベルの分類と、製造業における 25% の効率向上や医療での合併症 30% 減少といった成果、2034 年における AI ロボット市場が 1,242 億ドル、デジタルツイン技術市場が 3,790 億ドルといった予測が述べられています。AWS は MassRobotics、NVIDIA と共同で立ち上げた Physical AI Fellowship を通じて、次世代ロボティクスと自動化ソリューションを開発する 8 社のスタートアップを支援しています。 フィジカル AI の実践: 人間と機械の相互作用を支える技術基盤 このブログは、フィジカル AI の実践的な技術基盤について解説しています。人間と機械の相互作用を支える完全な開発ライフサイクルとして、データ収集・準備、強化学習や模倣学習などのモデルトレーニング、量子化や蒸留による最適化、エッジでの運用までを詳述しています。Diligent Robotics の Moxi ロボットを事例に、病院環境で 120 万回以上の配達と 60 万時間近くのスタッフ時間節約を実現した成果を紹介し、ガバナンス、安全性、倫理的配慮の重要性も強調しています。 AI を具現化するブログ: パート1 AWS Batch でロボット学習を開始する AWS Batch を使用して NVIDIA Isaac GR00T N1.5 3B モデルをファインチューニングするためのスケーラブルな基盤の構築方法を解説します。ロボット学習の最新技術である模倣学習や強化学習のフレームワークを紹介し、AWS CDK を用いた自動デプロイメント、Amazon EFS による共有ストレージ、Amazon DCV を活用したシミュレーション評価環境の構築手順を詳しく説明しています。クラウドの弾力性と NVIDIA の先進的なロボット学習スタックを組み合わせることで、開発サイクルを加速し、大規模なデータセットを効率的に管理できます。 知的なフィジカル AI 構築: Strands Agents、Bedrock AgentCore、Claude4.5、NVIDIA GR00T、および Hugging Face LeRobot によるエッジからクラウドへ Strands Agents、Amazon Bedrock AgentCore、Anthropic Claude 4.5、NVIDIA GR00T、Hugging Face LeRobot を活用した、エッジからクラウドまでの知的なフィジカル AI の環境構築について解説しています。エッジでのミリ秒レベルの応答性と、クラウドでの高度な推論を組み合わせ、ロボットが物理世界で認知・判断・行動するハイブリッドアーキテクチャを実現します。SO-101 ロボットアームや Boston Dynamics Spot での実装例により、VLA モデルによる直接的な物理制御と SDK ベースの制御の両方を紹介し、継続的な学習と改善を実現するアプローチを提供しています。 How to Build Physical AI Agents: Natural Language for Real-World Robotics 上記のブログと対応した内容の AWS Show and Tell シリーズの動画です。O-101 3D (印刷可能なロボットアーム)を Jetsonエッジデバイスに接続し、ファインチューニングされたNVIDIA GR00T VLAモデルを用いて、ハードウェア統合用の Hugging Face LeRobot を接続しています。Strands Agents フィジカル AI エージェントを自然言語でインテリジェントにオーケストレーションします。 Physical AI Unleashed: Teaching Humanoid Robots to Pick, Place & Inspect この動画では、NVIDIA GR00t N1.5とUnitree G1を搭載したヒューマノイドロボットが、リアルタイムの品質検査を行いながら精密なピックアンドプレース操作を実行できるようにする現実世界のアプリケーションを構築します。コンピュータービジョン、生成 AI、ロボティクスを組み合わせて、物体を動かすだけでなく、その処理内容を理解するインテリジェントなシステムを構築します。自然言語による指示から、在庫確認 → ナビゲーション → ピック＆パック → 配送 → 帰還という一連の作業の自律的な実行も実現しています。 Revolutionizing warehouse automation with scientific simulation Amazon Science のブログ記事で、Amazon Robotics の ID チーム（AR-ID）が開発した Sensor Workbench について述べています。これは倉庫内のセンサー配置を最適化するための革新的なシミュレーションプラットフォームで、CAD で記述された詳細な倉庫モデルをシミュレーション用の 3D アセットに変換し、OpenUSD をシミュレーションプロセス全体のデータ基盤として活用、NVIDIA の Isaac Sim をベースにしたシミュレータにより、物理ベースのセンサーモデリングと高精度な 3D 環境を組み合わせたシミュレーションが可能です。 AWS re:Invent 2025 – Train, Simulate, Deploy: Building NVIDIA-Powered Physical AI on AWS (AIM117) re:Invent 2025 のセッション動画で、NVIDIA のソリューションによるフィジカル AI を AWS クラウド上で実行する方法について解説しています。Amazon EC2 GPU インスタンスや、 AWS Batch および NVIDIA Isaac Lab を活用して大規模に実行する方法について紹介しています。 ガイダンス: ロボティクスのためのフィジカル AI on AWS 12月の本ブログで紹介済みですが、フィジカル AI を AWS クラウド上で実現するためのリファレンスアーキテクチャとガイダンスです。 CES 2026 2026年1月6日～9日に開催された CES では、Alexa Plus や Amazon Leo などの 最新のプロダクト、テクノロジーの展示 とともに、 Amazon Robotics と共同で、フィジカルAI によるアームロボットのピック作業をデモを展示しています。Siemens Xcelerator / NVIDIA Omniverse を活用した工場のデジタルツインや Snlowflake を活用した予防保守も統合されています。 デモ動画リンク (要Linked In アカウント) 製造関連の主要なアップデート 12/8 空間データのインサイトを加速させる Spatial Data Management on AWS を発表 本日、AWS は、ユーザーに空間データの大規模な保存、強化、接続を可能にするソリューションである Spatial Data Management on AWS (SDMA) を発表しました。SDMA を使用すると、お客様は物理アセット (3D、地理空間、行動、時系列データ) を表すマルチモーダル空間データを、安全で一元化されたクラウド環境に保存できるようになります。 1/8 Amazon EC2 G7e インスタンスの一般提供開始(NVIDIA RTX PRO 6000 Blackwell Server Edition GPUs) 大規模言語モデル (LLM)、エージェンティック AI モデル、マルチモーダル生成 AI モデル、物理 AI モデルのデプロイにも適した最新の NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載する G7e インスタンスが一般提供開始になりました。 こちらのブログ で詳細が説明されています。 1/8 Amazon MQ が RabbitMQ ブローカーで相互 TLS を使用した証明書ベース認証をサポート Amazon MQ の RabbitMQ ブローカーで、mTLS を利用した X.509 クライアント証明書による認証機能が追加されました。従来のユーザー名とパスワード認証に加えて、より安全な証明書ベース認証が利用可能になり、企業システムでよく使われる PKI 基盤との連携が簡単になります。RabbitMQ 4.2 以上と M7g インスタンスで利用でき、設定ファイルを編集するだけで有効化できます。詳細は こちらのドキュメントをご参照ください。 2/2 Amazon SageMaker JumpStartでNVIDIA NIMsモデルが利用可能に Amazon SageMaker JumpStartで、バイオサイエンスとフィジカルAI向けに構築された4つのNVIDIA NIMsモデル（ProteinMPNN、Nemotron-3.5B-Instruct、MSA Search NIM、Cosmos Reason）がワンクリックデプロイ可能になりました。Cosmos ReasonはフィジカルAIとロボティクス向けのオープンでカスタマイズ可能な推論ビジョン言語モデルです。 直近で開催予定のイベント re:Invent製造領域 re:Cap 昨年12月に開催された re:Invent 2025 の製造領域の日本語による振り返り(reCap)セッションを、本年は Black Belt オンラインセミナーとして提供予定です。コンテンツはこちらの Youtube Playlist で公開される予定です。 事例のご紹介 製造業に関連する事例や、ブログによる技術詳細説明です。 JFE スチールが挑むインテリジェント製鉄所への道 – Amazon SageMaker AI による CPS 開発実行基盤の構築 JFE スチール株式会社による CPS (Cyber Physical System)開発実行基盤の構築について、これを主導された JFE スチール株式会社 庄村 啓様、JFE システムズ株式会社 杉田 朋晃様、原 洋平様、髙山 翔伍様より寄稿いただきました。 smart EuropeがAmazon Bedrockでカスタマーサポート業務を変革した方法 smart Europe が Amazon Bedrock を活用してカスタマーサポート業務を変革した事例を紹介しています。AI による問い合わせケースの自動タグ付けと、ナレッジベースに基づくインサイト生成により、問い合わせ解決時間を 40% 短縮し、ファーストコンタクトによる解決率を 20% 向上させました。サーバーレスアーキテクチャを採用し、10,000 件以上の問い合わせを処理しながら、当初予算から 30% のコスト削減を実現しています。 製造関連ブログのご紹介 今月もたくさんのブログが公開されました。 12/26 回復力のあるサプライチェーンの構築: Amazon Bedrock を活用した小売・消費財向けマルチエージェント AI アーキテクチャー このブログは、Amazon Bedrock を活用したマルチエージェント AI アーキテクチャによる、回復力のあるサプライチェーン構築について解説しています。港湾閉鎖などの混乱時に、 Amazon Bedrock AgentCoreを用いた エージェントが物流最適化、在庫管理、プロモーションリスク、出荷追跡の各専門エージェントを調整し、数分以内にデータ駆動型の対応策を提案します。小売・消費財業界向けに書かれていますが、製造業にも適用できる内容です。 1/7 「AWS IoT Greengrass と Strands Agents を使用した Small Language Model の大規模デプロイ」 AWS IoT GreengrassとStrands Agentsを使用して、Small Language Model（SLM）をエッジデバイスに大規模デプロイする方法を解説しています。製造業のOPC-UAプロトコルを例に、リアルタイムの機械データをローカルで処理しながら、複雑な分析はクラウドで実行するハイブリッドアプローチを実現します。SLMは軽量でありながら、制約のあるハードウェア上で動作し、オペレーターに即座の洞察を提供できます。 1/7 Amazon Kinesis Video Streams の warm ストレージ階層で長期動画保存コストを最適化 このブログは、Amazon Kinesis Video Streams の新しい Warm ストレージ階層について解説しています。従来の Hot 階層と比較して最大 67% のコスト削減を実現し、長期的な動画保存に最適化されています。高解像度ビデオでより大きなコスト削減効果が得られ、30 日以上の保存期間で特に効果を発揮します。耐久性と可用性を維持しながら、物理セキュリティや監視システムでの大規模なカメラネットワークの運用コストを大幅に削減できる実践的なソリューションを提供しています。 1/15 AUMOVIO Boosts Software Development with an Agentic Coding Assistant Powered by Amazon Bedrock Continental からスピンオフした AUMOVIO による自動車業界向けのコーディングアシスタントについてのブログ記事です。AUMOVIOのソリューションは、複数のAIモデルを利用してさまざまな開発ライフサイクルのステップを加速すると同時に、AUTOSAR, MISRA-C/C++ といった自動車業界標準との整合性の確保や、独自のコーディング規約を順守するのに役立ちます。コードの再利用を最大化し、必要な変更を最小限に抑えることで、アシスタントは他の V-model ステップの労力を大幅に軽減します。 1/25 re:Invent 2025 自動車・製造reCap Blog 日本語訳 1月にご紹介した自動車・製造領域のまとめブログを日本語化しました。 2/3 【開催報告】第9回鉄道技術展2025 AWS出展報告 2025年11月26日から29日に開催された「第9回鉄道技術展2025（Mass-Trans Innovation Japan 2025）」に AWSが出展した際の報告ブログ記事です。展示内容としてクラウドとAIを活用した鉄道保全システムのソリューションをご紹介しており、製造業における設備保全の観点でも参考になる内容です。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 山本 直志 (Tadashi Yamamoto) 製品開発エンジニアから、組み込み開発のアーキテクトやエンジニアリング支援を経て、エレクトロニクスや自動車産業のお客様を長年支援し、AWS では製造業のスペシャリストソリューションアーキテクトとして活動しています。製造業における業務課題解決や新規ビジネスにおけるクラウド活用の可能性をお客様と一緒に探求しています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 11 月・ 12 月合併号 はお読みいただけましたでしょうか。2026 年のアップデートをお届けする最初のブログ更新となります。本年も Amazon Connect の最新情報や有益な情報をお届けできるよう努めてまいります。皆さんのお役に立つ内容があれば幸いです！ 今月は 以下の内容でアップデート情報をお届けします。 Amazon Connect Starter Kit のご紹介 2026 年 1 月のアップデート一覧 AWS Contact Center Blog のご紹介 1. Amazon Connect Starter Kit のご紹介 Amazon Connect で AI エージェントを活用したコンタクトセンターをすぐに構築・体験できるスターターキット( sample-amazon-connect-starter-kit-japan )をご紹介します。本パッケージの最大の特徴は、デプロイするだけで AI エージェントを活用したコンタクトセンター環境が即座に利用可能になる点です。Amazon Connect AI エージェントを中心に、音声・チャットの複数チャネルに対応した環境が自動的に構築されます。複雑な設定作業は不要で、付属のデプロイメントガイドに従うだけで環境が完成します。 最新の AI エージェント機能を体感 Amazon Connect の AI エージェントは、従来の Amazon Q in Connect から進化した、より高度な自律型 AI です。顧客は「Connect アシスタント」と呼ばれる会話型インターフェイスを通じて AI エージェントとやり取りし、複雑でオープンエンドな問い合わせにも対応できます。ナレッジベースを参照した自動応答、複数の意図を含む問い合わせへの対応、コンテキストを維持した会話など、最新の Agentic AI 機能を実際に体験できます。 Amazon Connect では 最新のAgentic AI エージェントだけでなく、従来のAmazon Lex でのインテントベースの決定論的 AI も引き続き利用可能です。AI エージェントが複雑でオープンエンドなやり取りを処理する一方、決定論的 AI は事前定義されたインテントや特定の会話フローを処理します。この組み合わせにより、従来の決定論的 AI と自律的な Agentic AI の両方の長所を活用したセルフサービス体験を提供できます。 日本語・日本リージョン対応 us-east-1(バージニア北部)と ap-northeast-1(東京)の両リージョンでのデプロイに対応しています。また、日本語での利用を前提とした設定やドキュメントが含まれており、日本のコンタクトセンター環境ですぐに活用できます。 2. 2026 年 1 月のアップデート一覧 Amazon Connectが待ち時間予測の精度を向上 – 2026/01/31 Amazon Connect では、キューおよびキューに入っているコンタクトに対する待ち時間予測メトリクスが改善されました。これにより、コンタクトセンターは顧客に正確な待ち時間を伝えられるようになり、待ち時間が長い場合にはコールバックなどの便利なオプションを提供したり、複数のキュー間で業務負荷を効果的に分散したりできるようになります。改善された待ち時間予測メトリクスを活用することで、コンタクトセンターはキュー間でより戦略的なルーティング判断を行えるようになり、リソース計画のための可視性も向上します。たとえば、ピーク時に請求に関する問い合わせで15分の待ち時間が発生している場合、2分で対応可能なクロストレーニングされたチームにシームレスに転送することで、顧客は問題を繰り返し説明することなく、より早くサポートを受けられます。このメトリクスは、ルーティング条件やエージェントの習熟度設定とシームレスに連携します。 関連リンク 管理者ガイド Amazon Connect Cases に対するきめ細かなアクセス制御をサポート – 2026/01/28 Amazon Connect では、ケースに対してタグベースのアクセス制御を適用できるようになり、管理者はケースデータの閲覧と管理をより詳細に制御できるようになりました。この機能により、ケーステンプレートにタグを関連付け、セキュリティプロファイルを設定することで、特定のタグが付いたケースにアクセスできるユーザーを制御できます。たとえば、不正行為に関連するケースにタグを付け、不正対策のセキュリティプロファイルが割り当てられたユーザーのみがそれらのケースを閲覧または編集できるようにアクセスを制限することが可能です。これにより、社内統制の強化やデータアクセスポリシーの徹底が実現できます。 関連リンク 管理者ガイド Amazon Connect のステップバイステップガイドに条件分岐ロジックとリアルタイム更新機能が追加 – 2026/01/23 Amazon Connect のステップバイステップガイドが強化され、マネージャーはより動的で柔軟性の高いガイド体験を構築できるようになりました。ユーザーの操作に応じて変化する条件付きユーザーインターフェースを作成できるため、ワークフローの効率が向上します。たとえば、マネージャーはドロップダウンメニューを設定し、前の項目への入力内容に基づいて、フィールドの表示・非表示を切り替えたり、デフォルト値を変更したり、必須項目を調整したりすることができます。これにより、さまざまなシナリオに合わせたカスタマイズされた体験を提供できます。さらに、ステップバイステップガイドは、フローモジュールなどの Connect リソースから指定した間隔でデータを自動的に更新できるようになり、エージェントは常に最新の情報を使って業務を行えるようになりました。 関連リンク 管理者ガイド Amazon Connect が評価目的でのエージェントのコンタクトのランダムサンプルの自動選択を開始 – 2026/01/21 Amazon Connect において、エージェントの評価を目的としたコンタクトのランダムサンプリング機能が追加されました。この機能により、マネージャーはエージェントに対して適正なコーチングとフィードバックを提供できるようになります。マネージャーは、労働協約や社内ガイドラインに従って、エージェントごとに確認が必要なコンタクト数を指定できます。指定した数のコンタクトは、設定した期間からランダムに抽出されます。たとえば、先週の期間からエージェント 1 人あたり 3 件のコンタクトを自動的に選択することが可能です。さらに、新しいフィルター機能を使用することで、評価に適したコンタクトを確実に選択できます。音声録音、画面録画、トランスクリプトが含まれるコンタクトに絞り込んだり、過去に評価済みのコンタクトを除外したりすることができます。これにより、マネージャーは効率的かつ公平にエージェントのパフォーマンスを評価し、質の高いフィードバックを提供できるようになりました。 関連リンク 管理者ガイド Amazon Connect がデータレイクでのエージェントのスケジューリングメトリクスの提供を開始 – 2026/01/15 Amazon Connect がデータレイク内でエージェントのスケジューリングメトリクスを提供するようになり、このデータからレポートやインサイトを簡単に生成できるようになりました。たとえば、来月のスケジュール公開後に、Connect の分析データレイク内で、予測される人数、スケジュールされた人数、予想されるサービスレベルなど、15 分または 30 分間隔のメトリクスにアクセスできます。ビジネスユニット全体(予測グループ)の集計メトリクスを利用したり、特定の需要セグメント(需要グループ)別に分類したりすることが可能です。その後、Amazon QuickSight または任意の BI ツールでこのデータを可視化して、人員過剰や人員不足になっている期間を特定するなど、さらに詳細な分析を行えます。これにより、エージェントのスケジュールを手動で確認する必要がなくなり、スケジューラとスーパーバイザーの生産性が向上します。 関連リンク 管理者ガイド Amazon Connect で営業時間の定期的なオーバーライドの簡単な管理が可能に – 2026/01/14 Amazon Connect で、日、月、または年単位で一目で確認できるカレンダー表示を使用して、休日、メンテナンス期間、プロモーション期間などの定期的なイベントに応じたコンタクトセンターの営業時間を簡単に管理できるようになりました。毎週、毎月、または隔週の金曜日に自動的に有効になる定期的なオーバーライドをセットアップすることで、カスタマーエクスペリエンスをパーソナライズできます。すべての設定は自動的に適用されるため、手動で再確認する必要はありません。たとえば、エージェントの稼働状況を確認することなく、毎年 1 月 1 日に自動的に顧客へ「新年あけましておめでとうございます」という挨拶を送り、特別なホリデーメッセージに誘導できます。1 月 2 日には自動的にコンタクトセンターが通常業務に戻ります。 関連リンク 管理者ガイド Amazon Connect Cases が AWS CloudFormation のサポートを開始 – 2026/01/13 Amazon Connect Cases で AWS CloudFormation のサポートが開始され、Infrastructure as Code として Cases のリソースをモデル化、プロビジョニング、管理できるようになりました。今回のリリースにより、管理者は CloudFormation テンプレートを作成して、Amazon Connect インスタンス全体にわたって Cases の設定(テンプレート、フィールド、レイアウトなど)をプログラムによってデプロイおよび更新できます。これにより、手動でのセットアップ時間を短縮し、設定エラーを最小限に抑えることができます。 関連リンク 管理者ガイド Amazon Connect でエージェント画面録画の状況を追跡する機能の提供を開始 – 2026/01/13 Amazon Connect では、Amazon EventBridge を使用して CloudWatch でエージェントの画面録画の状況をほぼリアルタイムで表示できるようになりました。スーパーバイザーは画面録画を使用することで、顧客との通話を聞いたり、チャットの文字起こしを確認したりするだけでなく、問い合わせを処理する際のエージェントのアクション(音声通話、チャット、タスクなど)を監視できます。これにより、エージェントにコーチングが必要な領域(たとえば、ビジネスプロセスの違反など)を特定できます。Amazon EventBridge を使用すると、成功・失敗のステータス、失敗コードとその説明、インストールされているクライアントのバージョン、エージェントのウェブブラウザのバージョン、エージェントのオペレーティングシステム、画面録画の開始と終了の時刻など、各エージェントの画面録画の状況を CloudWatch から確認できます。Amazon EventBridge イベントバスの「Screen Recording Status Changed」イベントタイプにサブスクライブすることで、Amazon Connect 画面録画の状況追跡機能の使用を開始できます。 関連リンク 管理者ガイド ネストされた JSON オブジェクトとループ配列を格納する機能が Amazon Connect で提供される – 2026/01/03 Amazon Connect では、複雑なデータ構造をフローに保存して処理できるようになったため、社内のビジネスシステムから返される豊富な情報を使用する動的な自動化エクスペリエンスを簡単に構築できます。ネストされた JSON オブジェクトやリストを含む完全なデータレコードを保存し、JSON 形式で返された注文のリストから、特定の注文など、その中の特定の要素を参照できます。さらに、カスタマーサービスフロー内の項目のリストを自動的にループ処理して、ループ内の現在の位置を追跡しながら、各エントリを順番に処理できます。これにより、アイテムレベルの詳細に簡単にアクセスし、関連情報をエンドカスタマーに提示できます。たとえば、旅行代理店は、1 回のリクエストで顧客の旅程をすべて取得し、電話をかけてきた顧客に各予約を案内して、予約を確認または更新することができます。銀行も同様に、システムから安全に取得したデータを使用して、最近の取引を1つずつ顧客に説明できます。これらの機能により、ビジネスシステムを繰り返し呼び出す必要がなくなり、ワークフローの設計が簡単になり、ビジネス要件の変化に適応する高度な自動エクスペリエンスの提供が容易になります。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 テスト時間を最大 90% 削減 – Amazon Connect のテストとシミュレーション機能 (日本語翻訳) コンタクトセンター管理者は、本番環境を中断することなくコンタクトフローを効率的にテストする課題に直面してきました。従来は手動でシステムに電話をかけたり、カスタム検証ツールを構築したり、サードパーティソリューションに投資する必要があり、時間とコストがかかっていました。Amazon Connect は、このような課題を解決するネイティブコールシミュレーション機能の一般提供を開始しました。この機能により、外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、検証時間を最大 90 %削減できます。テストフレームワークは、イベント駆動型モデルと直感的なビジュアルインターフェースを採用しており、技術者以外のチームメンバーでも簡単にテストを作成できます。「X が発生したら Y を実行する」という自然な観点でテストを記述し、Observe (観察)、Check (検証)、Action (アクション)の 3 つのブロックを組み合わせてテストシナリオを構築します。専用のテストダッシュボードでは、テスト実行履歴や成功率、失敗の詳細な洞察が得られ、継続的な改善を推進できます。本ブログ記事では、Amazon Connect の新しいネイティブテストとシミュレーション機能を活用して、コンタクトセンターの検証を自動化する方法について紹介しています。 Amazon Connect の裏側: イノベーターとしての進化 (日本語翻訳) Amazon Connect は、2007 年に Amazon の内部カスタマーサービスチームが3つのコンタクトセンターベンダーを置き換えるために構築した統合ソリューションから始まりました。従来の方法では 300 万ドルの前払い投資が必要でしたが、内部ソリューションはより安価で、Amazon のミッションを体現するものでした。Audible や Zappos など新たに買収された企業も熱心に採用し、年間推定 6,000 万ドルの節約を実現しました。2017 年のパブリックローンチ後、Capital One、Hilton、GE などの大企業が、従来 1 年間かかっていた構築プロセスを週末のプロジェクトに変えるクラウドネイティブなアーキテクチャに魅力を感じ、急速に採用が進みました。2019 年に AI を活用した会話分析や感情分析をローンチし、2023 年には Forrester と Gartner の主要レポートでリーダーシップポジションを獲得しました。生成 AI の出現により、自動エージェントラップアップや通話要約などの機能を提供し、2024 年 12 月には 60 億分、2025 年には 120 億分の顧客とのやり取りを AI で最適化しました。先週の Q3 2025 年決算報告では、年間換算売上高 10 億ドルのペースを達成したことが発表されました。本ブログ記事では、Amazon の内部ソリューションから AI のパイオニアへと進化した Amazon Connect のストーリーと、今後のエージェンティック AI への展望について紹介しています。 How NatWest Simplified Contact Center Analytics with Amazon Connect analytics data lake (英語記事) 英国の大手金融機関 NatWest Group は、2019 年に Amazon Connect を導入しましたが、当初はカスタム ETL パイプラインを使用したデータ処理に大規模なメンテナンスと定期的な更新が必要で、運用の複雑さとコストの増加に直面していました。2024 年、NatWest は Amazon Connect 分析データレイクの Zero ETL アーキテクチャを採用し、データアクセスと分析を大幅に簡素化しました。この移行により、従来 2 か月かかっていた CTR パイプラインの構築がわずか1週間で完了するようになり、通話完了から 1 時間以内にデータが利用可能になることで、タイムリーな意思決定が可能になりました。Zero ETL アプローチにより、センチメント分析や通話結果などの事前処理されたメトリクスに即座にアクセスでき、IVR パフォーマンスダッシュボードや会話品質分析ダッシュボードを通じて顧客インタラクションに関する多次元的な洞察を得られるようになりました。本ブログ記事では、NatWest が Amazon Connect 分析データレイクを活用してコンタクトセンター分析を簡素化し、データドリブンな顧客サービスを実現した事例について紹介しています。 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は 2026 年 2 月 9 日 に公開された「 Using Amazon SageMaker Unified Studio Identity center (IDC) and IAM-based domains together 」を翻訳したものです。 Amazon SageMaker Unified Studio で、2 種類のドメイン構成が利用できるようになりました。ガバナンス機能が充実した Amazon SageMaker Unified Studio Identity Center (IDC) ベースドメインと、開発者の生産性を高める Amazon SageMaker Unified Studio IAM ベースドメインです。 本記事では、AWS Identity and Access Management (IAM) ロールの再利用と属性ベースのアクセス制御を使って、Amazon SageMaker Unified Studio の両方のドメイン構成を併用する方法を紹介します。 各構成での認証の仕組み Amazon SageMaker Unified Studio IDC ベースドメイン は、AWS IAM Identity Center のシングルサインオンでユーザーを認証し、セッション全体を通じて個々のユーザー ID を保持します。ID ベースの認可、ユーザー間のきめ細かなアクセス制御、承認プロセスを含む Publisher/Subscriber (Pub/Sub) データ共有ワークフローによるカタログ管理など、ガバナンス面で優れた機能を備えています。ID 管理、コンプライアンス追跡、ID ベースの監査証跡が求められるエンタープライズ環境に適しています。 Amazon SageMaker Unified Studio IAM ベースドメイン は、フェデレーテッド IAM ロールで認証し、プロジェクトにアクセスするすべてのユーザーが同じロール権限を共有します。サーバーレス Notebook、Athena Spark 統合、縦型ナビゲーションによる使いやすいインターフェース、組み込みの AI アシスタントなど、開発者の生産性を重視した最新ツールを提供します。効率的なアクセスと高度な分析機能が必要な開発チームに適しています。 IDC ベースドメインを既に使用している組織は、既存のガバナンスフレームワークを維持しながら、IAM ベースドメインでチームに最新の開発機能を提供できます。新しくリリースされた IAM ベースドメインのみを使用したい場合は、そのまま利用できます。どちらを選ぶかは、組織のニーズ次第です。 本記事の執筆時点では、IAM ベースドメインは 信頼された ID の伝播 をサポートしていません。本記事のソリューションでは、 プロジェクト実行ロール でデータアクセスを設定します。 課題 データスチュワード の Sam は、IDC ベースドメインを使用してデータアクセスポリシーの定義、データカタログの管理、サブスクリプションリクエストの承認を行い、コンプライアンスと適切なデータガバナンスを確保しています。 一方、 データエンジニア の Sarah は、IDC ベースドメインのガバナンス機能 (SageMaker Catalog など) と、IAM ベースドメインの新しい サーバーレス Notebook を使ってデータパイプラインの構築、高度な分析、開発サイクルの短縮を行いたいと考えています。Sarah は IDC ベースドメインでデータへのアクセスをリクエストし、Sam が承認すると、IAM ベースドメインのサーバーレス Notebook でそのデータにアクセスできるようになります。 ソリューションの概要 この統合では、IAM ロールの再利用、 AWS Lake Formation の属性ベースのアクセス制御 (ABAC)、Amazon SageMaker Catalog の Pub/Sub モデルを活用して、IDC ベースドメインの権限を IAM ベースドメインに自動的に引き継ぎます。適切に設定すると、IDC ベースドメインの Pub/Sub モデルで管理されるデータサブスクリプションが IAM ベースドメインのプロジェクトですぐに利用可能になり、統一されたデータアクセス体験を実現します。 本記事で実装するソリューションでは、IDC コンシューマープロジェクトと同様の IAM ベースドメインプロジェクト (同じチームメンバー、ユースケースなど) を作成し、実行ロールを設定してロールの再利用を有効にします。既存のサブスクリプションワークフローを維持しながら、IAM ベースドメインのメリットを活用できます。以下の図にアーキテクチャの全体像を示します。 ソリューションアーキテクチャの構成要素: 既存の IDC ベースドメイン : Pub/Sub モデルによるデータ共有が確立されたプロデューサーおよびコンシューマープロジェクトを含む IAM ベースドメイン : 最新の開発ツール向けにフェデレーテッドロールと実行ロールが設定された新しいプロジェクト IAM Identity Center : フェデレーテッドアクセスとアクセス許可セットを管理 属性ベースのアクセス制御 : 実行ロールのタグにより権限の自動継承を実現 このソリューションには 2 つのオプションがあります。オプション 1: IDC ベースドメインのプロジェクトロール再利用は、最もシンプルな統合パスです。IDC ベースドメインの既存のコンシューマープロジェクト IAM ロールを、IAM ベースドメインの実行ロールとしてそのまま再利用します。主なメリットは、ポリシー変更のみで済むセットアップの簡素化 (詳細は後述)、管理するロールが 1 つ少なくなる管理負荷の削減、実績のある既存ロールを活用するため設定ミスのリスクが低いことです。オプション 1 は、最速の実装パスが必要な場合、ロールの増加を最小限に抑えたい場合、データアクセス権限が既に設定された IDC ベースドメインロールがある場合、または IAM の専門知識が限られたチームで複雑なタグ設定を避けたい場合に適しています。 オプション 2: IAM ベースドメインプロジェクト用に新しい実行ロールを作成し、IDC ベースドメインのプロジェクト ID でタグ付けして属性ベースのアクセス制御 (ABAC) を使用します。主なメリットは、2 つの異なるロール (IDC ベースドメイン用と IAM ベースドメイン用) による監査性の向上、CloudTrail ログでどのドメインからリクエストが発生したかを明確に区別できること、IDC ベースドメインの運用に影響を与えずに IAM ベースドメイン固有の権限をカスタマイズできる柔軟性、2 つのドメインタイプ間のセキュリティ分離の向上です。 AmazonDatazoneProject タグにより 属性ベースのアクセス制御 が有効になり、ロール ID は個別に維持されます。オプション 2 は、ドメインタイプを区別する詳細な監査証跡が必要な場合、コンプライアンスポリシーでガバナンス環境と開発環境の責務分離が求められる場合、各ドメインのコストを個別に追跡・帰属させたい場合、またはコンプライアンスレポートでどのドメイン (ガバナンス vs. 開発) が特定のデータリソースにアクセスしたかを示す証拠が必要な場合に適しています。 以下は、両方のオプションで ID とドメインエンティティがどのようにマッピングされるかの概要図です。 前提条件 本記事の手順を実施するには、以下が必要です。 Amazon SageMaker Unified Studio IDC ベースドメイン が設定済みの AWS アカウント Amazon SageMaker Unified Studio IDC ベースドメインに既存のプロデューサーおよびコンシューマー プロジェクト Pub/Sub モデルで公開・サブスクライブ済みの データアセット Amazon IAM Identity Center への管理者アクセス プロジェクト、環境、IAM ロールなど Amazon SageMaker Unified Studio の概念への理解 管理者として作成済みの Amazon SageMaker Unified Studio IAM ベースドメイン 本記事のデモでは、Sales プロデューサープロジェクトと、そのテーブルをサブスクライブする Marketing コンシューマープロジェクトを使用します。 現在の IDC ベースドメインの構成を理解する まず、既に運用中の Amazon SageMaker Unified Studio IDC ベースドメインの構成を確認します。 Sales プロデューサープロジェクト pipeline テーブルと sales テーブルを含むデータベースがある データスチュワードの Sam がデータアセットの作成と公開を管理 専用のプロジェクト IAM ロールを持つ Marketing コンシューマープロジェクト データエンジニアの Sarah が IDC ドメインプロジェクトを通じて公開データをサブスクライブして管理 専用のプロジェクト IAM ロールを持つ IDC ベースドメインのインターフェースでサブスクライブ済みデータのクエリに成功 各プロジェクトにはデータアセットへのアクセスを制御する IAM ロールが関連付けられており、Pub/Sub モデルがサブスクリプションワークフローと権限を管理します。 アクセス許可セットによるフェデレーテッドロールの設定 アクセス許可セット によるフェデレーテッドロールは、AWS IAM Identity Center を通じて IAM ベースドメインへのコンソールアクセスをユーザーに認証・提供するために使用されます。プロジェクト内のすべてのユーザーが同じロール権限を共有します。アクセス許可セットを割り当てると、IAM Identity Center は AWS アカウントに対応する IAM Identity Center 管理の IAM ロールを作成し、アクセス許可セットで指定されたポリシーをそのロールにアタッチします。 IAM ベースの SageMaker Unified Studio ドメインにより、ガバナンスを維持しながら最新の開発ツール (サーバーレス Notebook、Athena Spark、AI アシスタント) への効率的なアクセスが可能になり、重複するアクセス承認なしにドメイン間で権限が自動的に伝播され、チームメンバーのオンボーディングが簡素化されます。IAM ベースドメインへのアクセスには任意の IAM ロールを使用できます。本記事では、AWS IAM Identity Center (IDC) を使用したフェデレーテッドロールオプションを使用します。 IAM ベースドメイン用にデータエンジニアグループへのアクセスを付与する 1) AWS IAM Identity Center でフェデレーテッドロールを設定する AWS マネジメントコンソールで IAM Identity Center (IDC) に移動し、以下の手順を実行します。 IDC のアクセス許可セットセクションに移動します。 Marketing-federated-role という新しいアクセス許可セットを作成し、[Attach policy] を選択します。 既存のポリシー名リストから SageMakerStudioUserIAMConsolePolicy を検索し、リストから SageMakerStudioUserIAMConsolePolicy を選択します。SageMaker IAM ドメインのプロジェクトにアクセスするには、マネージドポリシー SageMakerStudioUserIAMConsolePolicy をアタッチするか、同等の権限を別のポリシーで追加する必要があります。 IDC の AWS アカウントセクションに移動します。 作成したアクセス許可セットを AWS アカウントに割り当てます。 本記事では、アクセス許可セットを marketing グループに割り当てました。ベストプラクティスとして、個々のユーザーではなくグループにアクセスを設定・付与してください。 Sarah を marketing グループに追加します。 この設定で、Sarah が IAM ベースドメインにアクセスするフェデレーテッドロールが作成されます。フェデレーテッドロールはアカウント内の IAM ロールとして表示され、コンソールアクセスのエントリポイントとなります。 IAM ベースドメインの実行ロールの設定 IAM ベースドメインプロジェクトの実行ロールの設定には 2 つのオプションがあります。実行ロールはフェデレーテッドロールと 1 対 1 でマッピングされます。 オプション 1 – IDC ベースドメインのプロジェクトロール再利用 新しい実行ロールを作成してタグ付けする代わりに、IDC ベースドメインのコンシューマープロジェクト IAM ロールを IAM ベースドメインプロジェクトの実行ロールとして直接再利用できます。コンシューマープロジェクト IAM ロールのポリシー変更のみで対応できます。IDC ベースドメインのコンシューマープロジェクト IAM ロールを確認するには: Amazon SageMaker Unified Studio IDC ベースドメインポータルに移動します。 Marketing コンシューマープロジェクトを開きます。 プロジェクト概要ページからプロジェクトロール ARN をコピーします。 この実行ロールのポリシーを変更する必要があります。詳細な手順は後述します。 オプション 1 の IAM ベースドメインプロジェクトの設定 既存の IDC ベースドメインの権限と統合する IAM ベースドメインプロジェクトを作成するには、以下の手順を実行します。 IAM ベースドメインの管理者として AWS コンソールにログインします。 コンソール内の Amazon SageMaker ページに移動します。 [Open] を選択します。 IAM ベースドメインに管理者としてログインしたら、[Manage projects] を選択します。 次に、[Create project] をクリックします。 プロジェクト名に「Marketing Consumer Project」と入力します。 プロジェクト作成時に、以下のロールを選択して [Create Project] を選択します。 プロジェクト IAM ロール : 上記の IAM Identity Center で作成した marketing フェデレーテッドロール。メンバーアカウント内のロール名のサフィックスが AWSReservedSSO のロールです。 プロジェクトロール : オプション 1 でコピーしたデータエンジニア用のプロジェクトロールを選択します。 SageMaker Unified Studio UI ページの指示に従って、このプロジェクトロールに ポリシー 変更を行います。 オプション 2 – 独自の実行ロールを持ち込む 既存の IDC ベースドメインの権限と統合する IAM ベースドメインプロジェクトを作成するには、権限の伝播のために実行ロールにタグを付ける必要があります。Amazon SageMaker Catalog と AWS Lake Formation は属性ベースのアクセス制御を使用しており、リソースタグに基づいて権限を継承できます。オプション 2 では、コンシューマープロジェクト ID が必要です。IDC ベースドメインのコンシューマープロジェクト ID を確認するには: Amazon SageMaker Unified Studio IDC ベースドメインポータルに移動します。 Marketing コンシューマープロジェクトを開きます。 プロジェクト詳細からプロジェクト ID をコピーします。 オプション 2 の IAM ベースドメインプロジェクトの設定 以下の手順を実行します。 管理者としてログインした状態で、IAM ベースドメインに「Marketing Consumer Project 2」という名前の別のプロジェクトを作成します。 プロジェクト作成時に、以下のロールを選択します。 フェデレーテッドロール : 上記の IAM Identity Center で作成した marketing フェデレーテッドロール。 実行ロール : オプション 2 の実行ロールを選択します。 指示に従って、この実行ロールにポリシー変更を行います。 次に、IAM コンソールに移動し、IAM ベースドメインのコンシューマープロジェクト用に作成した実行ロールを見つけます。 以下のタグを追加します。タグの追加は、サブスクリプションの projectId を使用した ABAC ポリシーに依存しています。 Key : AmazonDatazoneProject Value : Amazon SageMaker Unified Studio IDC ベースドメインのコンシューマープロジェクトのプロジェクト ID タグを設定すると、IDC ベースドメインのコンシューマープロジェクトから IAM ベースドメインプロジェクトの実行ロールへのデータアクセス権限が付与されます。 IAM ベースドメインでのデータアクセスの検証 実行ロールにタグを付けた後、権限が正しく設定されていることを確認します。以下の手順を実行します。 SSO URL を使用して、Sarah として SSO Identity Center にログインします。 フェデレーテッドロールの設定セクションで作成したフェデレーテッドロールを使用して AWS コンソールを開きます。 Amazon SageMaker に移動します。 Amazon SageMaker Unified Studio IAM ベースドメインオプションを選択します (フェデレーテッドロールでプロジェクトが既に作成されている場合に表示されます)。 Amazon SageMaker Unified Studio IAM ベースドメインプロジェクトで、[Data] タブに移動します。オプション 1 とオプション 2 の両方の実行ロールで 2 つのプロジェクトを作成した場合、2 つのプロジェクトが表示され、どちらにもログインしてデータアクセスを検証できます。 コンシューマーデータベースとサブスクライブ済みテーブルが表示されることを確認します。 新しいサーバーレス Notebook の作成と使用 権限が正しく設定されたら、IAM ベースドメインのサーバーレス Notebook などの機能を使用できます。以下の手順を実行します。 Amazon SageMaker Unified Studio IAM ベースドメインプロジェクトで、[Data] タブからテーブルを選択します。 [Create notebook] を選択します。 Notebook が Athena SQL をデフォルトのセルタイプとして開きます。 サブスクライブ済みデータに対してクエリを記述して実行します。 Notebook は実行ロールの権限で動作し、IDC ベースドメインでサブスクライブしたすべてのデータにアクセスできます。 この統合の主なメリット この統合には次のメリットがあります。 既存の投資を活用 IDC ベースドメインのガバナンスとカタログを引き続き使用できる 確立された Pub/Sub ワークフローを維持できる 既存のデータアセットの移行が不要 最新の機能を利用 開発者に新しいサーバーレス Notebook を提供 高度な分析のための Athena Spark にアクセス ユーザーエクスペリエンスとナビゲーションが向上 権限管理の簡素化 単一のサブスクリプションワークフローで両方のドメインのアクセスを管理 ロールの再利用と属性ベースのアクセス制御による一貫したデータアクセス 重複するアクセスリクエストや承認が不要 統一されたデータ体験 開発者が 1 つのインターフェースからすべてのサブスクライブ済みデータにアクセス ドメイン間で一貫したデータカタログ 新しいチームメンバーのオンボーディングを簡素化 クリーンアップ 作成したリソースを削除するには、以下の手順を実行します。 IAM ベースドメインプロジェクトで作成したサーバーレス Notebook を削除します。 IAM ベースドメインプロジェクト (Marketing Consumer Project と Marketing Consumer Project 2) を削除します。 IAM Identity Center で marketing グループからアクセス許可セットの割り当てを削除します。 IAM Identity Center で Marketing-federated-role アクセス許可セットを削除します。 実行ロールからタグ (AmazonDatazoneProject) を削除します (オプション 2 を使用した場合)。 IAM ベースドメイン用に作成した実行ロールを削除します (オプション 2 を使用し、IDC ベースドメインのプロジェクトロールを再利用していない場合)。 IDC ベースドメインのコンシューマープロジェクト IAM ロールに加えたポリシー変更を元に戻します (オプション 1 を使用した場合)。 IAM ベースドメインが不要になった場合は、削除します。 IDC ベースドメインでテスト用のデータサブスクリプションを作成した場合は、削除します。 まとめ 本記事では、ロールの再利用と属性ベースのアクセス制御を使って、Amazon SageMaker Unified Studio の IDC ベースドメインと新しい IAM ベースドメインを連携させる方法を紹介しました。この構成により、データエンジニアは両方のメリットを享受できます。新しいサーバーレス Notebook、Athena Spark 統合、組み込みの AI アシスタントなどの最新開発ツールにアクセスしながら、IDC ベースドメインで確立されたカタログ管理とセキュリティ制御によるガバナンスを維持できます。既存のデータガバナンス、サブスクリプションワークフロー、アクセス制御はそのまま機能するため、Amazon SageMaker Unified Studio IAM ベースドメインを安心して導入できます。 Amazon SageMaker Unified Studio で、ガバナンスと最新の開発ツールを組織で活用してみませんか？詳細は Amazon SageMaker Unified Studio のドキュメントをご覧ください。 著者について Praveen Kumar Praveen は、AWS のプリンシパルアナリティクスソリューションアーキテクトです。クラウドベースのサービスを使用した最新のデータおよび分析プラットフォームの設計、構築、実装を専門としています。サーバーレステクノロジー、データガバナンス、データドリブン AI アプリケーションに関心があります。 Durga Mishra Durga は、AWS のプリンシパルデータ & AI ソリューションアーキテクチャストラテジストです。仕事以外では、新しいものを作ることや家族と過ごすことを楽しんでいます。アパラチアントレイルでのハイキングや自然の中で過ごすことが好きです。 Joel Farvault Joel は、AWS のプリンシパルスペシャリスト SA (アナリティクス) です。エンタープライズアーキテクチャ、データガバナンス、アナリティクスの分野で 25 年の経験があります。その経験を活かして、お客様のデータ戦略とテクノロジー基盤についてアドバイスしています。 Satish Sarapuri Satish は、AWS のシニアデータアーキテクト (Data Mesh/Data Lake/Gen AI) です。エンタープライズレベルのお客様が AWS 上で生成 AI、データメッシュ、データレイク、分析プラットフォームソリューションを構築し、データドリブンな意思決定とビジネスへのインパクトを実現できるよう支援しています。余暇にはトレイルランニングや家族との時間を楽しんでいます。 Leonardo Gomez Leonardo は、AWS のプリンシパルアナリティクススペシャリストソリューションアーキテクトです。データ管理の分野で 10 年以上の経験があり、世界中のお客様のビジネスおよび技術ニーズに対応しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenji Hirai がレビューしました。

本記事は 2026 年 02 月 09 日 に公開された “Simplify cross-account stream processing with AWS Lambda and Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/simplify-cross-account-stream-processing-with-aws-lambda-and-amazon-dynamodb/ 組織は、セキュリティと分離のためにマルチアカウントアーキテクチャを使用することがよくあります。しかし、 Amazon DynamoDB テーブルが 1 つのアカウントにある場合、そのストリームイベントを別のアカウントで処理する必要があるかもしれません。最近まで、これは Amazon Kinesis Data Streams を経由するか、クロスアカウント AWS Identity and Access Management (IAM) ロールを使用したカスタムリレーインフラストラクチャを構築することを意味し、不要な複雑さが追加されていました。 Amazon DynamoDB Streams の リソースベースポリシー により、これらの回避策を避けることができるようになりました。 AWS Lambda 関数は、カスタムインフラストラクチャを必要とせずに、アカウント間でストリームを直接消費できます。 DynamoDB は、サーバーレスでフルマネージドな分散 NoSQL データベースであり、大規模環境でも 1 桁ミリ秒のパフォーマンスを実現します。インフラストラクチャを管理することなく、最新の高性能アプリケーションを構築できます。その主要な機能の 1 つが DynamoDB Streams で、ほぼリアルタイムでデータの変更をキャプチャします。この機能は、監査ログ、検索インデックス作成、クロスリージョンレプリケーション、異常検出、リアルタイム分析などのユースケースをサポートします。 Lambda は、サーバーのプロビジョニングや管理なしでコードを実行できるサーバーレスコンピューティングサービスです。Lambda は DynamoDB Streams と統合されているため、テーブルの更新に応じて関数を自動的にトリガーできます。この統合は、データレプリケーション、マテリアライズドビュー、分析パイプライン、イベント駆動型アーキテクチャなどのユースケースに役立ちます。 この記事では、DynamoDB Streams でリソースベースポリシーを使用して、クロスアカウント Lambda 消費を有効にする方法を探ります。アプリケーションワークロードが分離されたアカウントに存在し、ストリーム処理が集中化されたアカウントまたは分析アカウントで行われる一般的なパターンに焦点を当てます。 DynamoDB Streams を使用したクロスアカウント Lambda のメリット DynamoDB Streams のリソースベースポリシーを使用すると、ある AWS アカウントの Lambda 関数に、別のアカウントの DynamoDB ストリームから読み取る直接アクセスを許可できます。カスタムリレーインフラストラクチャは必要ありません。 この機能により、マルチアカウントイベント駆動型アーキテクチャを簡素化し、セキュリティを向上させ、運用負担を軽減できます。Lambda は、同じアカウントの イベントソースマッピング と同様に、取り込み、フィルタリング、配信、再試行、エラー処理を管理します。 SaaS サービスを運用している場合、集中化された分析パイプラインを実行している場合、または開発、ステージング、本番環境用に分離された環境を管理している場合など、別の AWS アカウントで DynamoDB ストリームイベントを処理したい理由はたくさんあります。DynamoDB Streams のリソースベースポリシーサポートにより、強力なアクセス制御を維持しながら、これらのパターンを簡単に実装できます。 この機能により、いくつかのアーキテクチャパターンが可能になります。 集中データ処理 – 複数のアプリケーションアカウントからのストリームを、Lambda 関数が集約、変換、データウェアハウスへのロードを実行する中央分析またはデータレイクアカウントにルーティングします。 共有サービス – 組織全体のテーブルからストリームを消費する、専用アカウントで再利用可能な監査ログ、コンプライアンス監視、または通知サービスを構築します。 マルチテナントアーキテクチャ – 分離されたアカウント内のテナント固有の Lambda 関数が、集中化された DynamoDB テーブルからデータを処理できるようにし、イベント駆動型ワークフローをサポートしながらセキュリティ境界を維持します。 ソリューションの概要 クロスアカウントアクセスモデルは、2 つのコンポーネントを使用します。 DynamoDB ストリームのリソースベースポリシー（ソースアカウント内） – 消費アカウント内の Lambda 実行ロールに権限を付与します IAM 実行ロール（消費アカウント内） – Lambda 関数がストリームから読み取ることを許可します Lambda 関数とクロスアカウント DynamoDB ストリーム間のイベントソースマッピングを構成すると、ストリームのリソースポリシーと Lambda 関数の実行ロールの組み合わせた権限を使用してアクセスが許可されます。ストリームのリソースベースポリシーは Lambda 実行ロールを承認し、実行ロールはストリームレコードの読み取りと処理に必要な特定の権限を提供します。 これがどのように機能するかを説明するために、企業顧客にドキュメント処理サービスを提供する SaaS プロバイダーを考えてみましょう。各顧客は、分離とセキュリティの向上のために専用の AWS アカウントで運用されています。ドキュメントが処理されると、テナントは DynamoDB Streams が有効になっている DynamoDB テーブルにレコードを書き込みます。SaaS サービスチームは、請求と分析のために、これらのレコードを中央 AWS アカウントに集約したいと考えています。クロスアカウント Lambda と DynamoDB Streams を使用すると、この統合は簡単でフルマネージドになります。 次の図は、アーキテクチャを示しています。 この記事では、アカウント B のテーブルからの DynamoDB ストリームイベントを処理するために、アカウント A に Lambda 関数を設定します。最初に Lambda 実行ロールを作成し、次にストリームを使用して DynamoDB テーブルを設定し、クロスアカウント権限を構成し、最後にイベントソースマッピングでそれらを接続します。 次のコマンドは、変数を使用してセットアップを再利用可能にし、ステップ間での Amazon リソースネーム (ARN) の手動コピーを削減します。 前提条件 このソリューションをデプロイするには、2 つの AWS アカウントと必要なリソースを作成する権限が必要です。このソリューションは AWS コマンドラインインターフェイス (CLI) を使用します。これは これらの手順 を使用してインストールできます。 変数の定義 次のコードを使用して変数を定義します。 # AWS Region REGION=us-east-1 # Resource names TABLE_NAME=Orders ROLE_NAME=CrossAccountStreamProcessor FUNCTION_NAME=ProcessOrders アカウント A で Lambda 実行ロールを作成 アカウント A で、Lambda 実行ロールとして機能する IAM ロールを作成します。 ROLE_ARN="$(aws iam create-role \ --role-name "$ROLE_NAME" \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Principal": {"Service": "lambda.amazonaws.com"}, "Action": "sts:AssumeRole" }] }' \ --query 'Role.Arn' \ --output text)" aws iam attach-role-policy \ --role-name "$ROLE_NAME" \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole echo "Role ARN: $ROLE_ARN" アカウント A で Lambda 関数を作成 Lambda 関数コードを作成します。 cat > index.py << 'EOF' import json def handler(event, context): print(json.dumps(event, indent=2)) return {'statusCode': 200} EOF コードをパッケージ化します。 zip function.zip index.py Lambda 関数を作成します。 aws lambda create-function \ --function-name "$FUNCTION_NAME" \ --runtime python3.12 \ --role "$ROLE_ARN" \ --handler index.handler \ --zip-file fileb://function.zip \ --region "$REGION" アカウント B でストリームを使用した DynamoDB テーブルを作成 アカウント B で、ストリームが有効になっている DynamoDB テーブルを作成します。 STREAM_ARN="$(aws dynamodb create-table \ --table-name "$TABLE_NAME" \ --attribute-definitions AttributeName=OrderId,AttributeType=S \ --key-schema AttributeName=OrderId,KeyType=HASH \ --billing-mode PAY_PER_REQUEST \ --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \ --region "$REGION" \ --query 'TableDescription.LatestStreamArn' \ --output text)" echo "Stream ARN: $STREAM_ARN" アカウント B でストリームにリソースベースポリシーをアタッチ アカウント B で、DynamoDB ストリームにリソースベースポリシーをアタッチします。まず、JSON ポリシーを作成します。 cat > stream-policy.json << EOF { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowCrossAccountStreamAccess", "Effect": "Allow", "Principal": { "AWS": "$ROLE_ARN" }, "Action": [ "dynamodb:DescribeStream", "dynamodb:GetRecords", "dynamodb:GetShardIterator" ], "Resource": "*" } ] } EOF 次に、ポリシーを適用します。 aws dynamodb put-resource-policy \ --resource-arn "$STREAM_ARN" \ --policy file://stream-policy.json \ --region "$REGION" アカウント A でイベントソースマッピングを作成 アカウント A で、Lambda 関数とクロスアカウントストリーム間のイベントソースマッピングを作成します。 aws lambda create-event-source-mapping \ --function-name "$FUNCTION_NAME" \ --event-source-arn "$STREAM_ARN" \ --starting-position LATEST \ --region "$REGION" 考慮事項 このソリューションをデプロイする際は、以下の点に留意してください。 DynamoDB テーブルと Lambda 関数の両方が同じ AWS リージョンにある必要があります 標準の DynamoDB Streams および Lambda の料金が適用されます。クロスアカウントアクセスに対する追加料金はありません ストリームのリソースベースポリシーは、きめ細かいアクセス制御のためにプリンシパルとして Lambda 実行ロール ARN を使用します ストリームのリソースベースポリシーは、条件やポリシー変数を含む標準の IAM ポリシー機能をサポートします ポリシーに次の必須アクションを含めるようにしてください： dynamodb:DescribeStream 、 dynamodb:GetRecords 、 dynamodb:GetShardIterator この機能は、ストリームが有効になっている新規および既存の DynamoDB テーブルの両方で機能します この機能は Amazon マネージドキー をサポートしていません クリーンアップ 今後の料金の発生を避けるために、このウォークスルーで作成したリソースを削除します。 アカウント A で、作成したリソースを削除します。 aws lambda list-event-source-mappings \ --function-name "$ProcessOrders" \ --region "$REGION" aws lambda delete-event-source-mapping \ --uuid <UUID-from-previous-command> \ --region "$REGION" Lambda 関数を削除します。 aws lambda delete-function \ --function-name "$ProcessOrders" \ --region "$REGION" IAM ロールを削除します。 aws iam detach-role-policy \ --role-name "$ROLE_NAME" \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaDynamoDBExecutionRole aws iam delete-role \ --role-name "$ROLE_NAME" アカウント B で、DynamoDB テーブルを削除します。 aws dynamodb delete-table \ --table-name "$TABLE_NAME" まとめ DynamoDB Streams のリソースベースポリシーサポートにより、AWS アカウント境界を越えてイベント駆動型システムを構築する強力な新しい方法が提供されます。この機能により、カスタム統合ロジックを記述することなく、安全でスケーラブルなパイプラインを作成できます。このソリューションは、SaaS サービスを実行している場合、ログを統合している場合、または変更データを集中的に処理している場合に役立ちます。 Lambda を使用した DynamoDB Streams は、リアルタイムストリーム処理のためのマネージドで信頼性の高いパスを提供します。今すぐ クロスアカウント Lambda と DynamoDB Streams を使用して構築を開始し、イベント駆動型アーキテクチャを簡素化しましょう。 著者について Lee Hannigan Lee は、アイルランドのドニゴールを拠点とする Amazon DynamoDB シニアデータベースエンジニアです。彼は、ビッグデータと分析技術の強固な基盤を持つ分散システムの豊富な専門知識をもたらします。彼の役割では、Lee は DynamoDB のパフォーマンス、スケーラビリティ、信頼性の向上に焦点を当てながら、顧客と社内チームがその機能を最大限に活用できるよう支援しています。

Amazon DynamoDB のグローバルセカンダリインデックス (Global Secondary Index、GSI) のキャパシティを Terraform の外部で調整したことがある方なら、Terraform がドリフトを検出して望ましくない復元を強制する様子をご存知でしょう。Terraform の新しい aws_dynamodb_global_secondary_index リソースを使用すれば、この問題に対処できます。 新しい aws_dynamodb_global_secondary_index リソースは、各 GSI を独自のライフサイクル管理を持つ独立したリソースとして扱います。この機能を使用して、Terraform の外部で GSI とテーブルのキャパシティ調整を行うことができます。 この記事では、Terraform の新しい aws_dynamodb_global_secondary_index リソースを使用して、GSI のドリフトを選択的に管理する方法を実演します。現在のアプローチの制限事項を説明し、ソリューションの実装方法をガイドします。 問題: Terraform のドリフトと GSI 管理 ソリューションに入る前に、インフラストラクチャ管理における ドリフト の意味を確認しましょう。Infrastructure as Code (IaC) において、ドリフトは、インフラストラクチャの実際の状態が Terraform 設定で定義されている内容と異なる場合に発生します。Terraform は、望ましい状態（ .tf 設定ファイル）、最後に既知の状態（ terraform.tfstate に保存）、実際の状態（AWS からクエリ）を比較することでドリフトを検出します。これらが一致しない場合、Terraform はドリフトを報告し、差異を調整するための変更を提案します。 DynamoDB の GSI は、さまざまな運用上の理由でキャパシティ調整が必要になることがよくあります。負荷テスト、キャパシティプランニング、緊急のパフォーマンス要件、またはウォームスループットの管理などです。DynamoDB のキャパシティは、オートスケーリングイベントによっても変更される可能性があります。Terraform の外部でこれらの変更を行うたびに、Terraform の設定と AWS の実態との間にドリフトが発生します。 例えば、分析チームが GSI に対して大量のクエリを実行する日次レポートを実行しているとします。レポートは午前 2 時に実行され、50 リードキャパシティユニット (Read Capacity Units、RCU) が必要ですが、通常時間帯は 5 RCU で十分です。運用チームは、負荷に対応するためにレポート実行前に手動でキャパシティを増やします。 午前 1 時 50 分に、運用チームは AWS コマンドラインインターフェイス (AWS CLI) を使用してキャパシティを 5 から 50 に増やします。レポートは午前 2 時から 3 時まで高いキャパシティで実行されます。その日の後半、無関係な変更をデプロイするために terraform plan を実行すると、実際のキャパシティ (50) が設定 (5) と一致しないため、Terraform はドリフトを検出します。Terraform はキャパシティを 5 に戻そうとしますが、これは運用上のキャパシティ管理に干渉することになります。 一般的な回避策とその制限事項 一般的な回避策は、テーブルのライフサイクルブロックで ignore_changes = [global_secondary_index] を使用することです。これにより、Terraform がキャパシティのドリフトを検出しなくなります。ただし、このアプローチは範囲が広すぎます。キャパシティだけでなく、すべての GSI の変更を無視します。 global_secondary_index は複雑なネストされた型であるため、 ignore_changes はトップレベルでのみ機能し、個々の属性では機能しません。誰かが誤って GSI を削除したり、キースキーマを変更したりしても、Terraform は検出しません。意図的なキャパシティチューニングと偶発的な GSI の削除を区別できません。 ソリューション: 個別の GSI リソース 新しい aws_dynamodb_global_secondary_index リソースは、各 GSI を独自のライフサイクル管理を持つ独立したリソースとして扱います。これにより、各 GSI に対してどの属性を無視するかをきめ細かく制御できると同時に、削除やスキーマ変更などの重要な変更を検出できます。 前提条件 開始する前に、以下があることを確認してください。 DynamoDB テーブルを作成および管理する権限を持つ AWS アカウント（例で使用するテストリソースを作成するために必要） DynamoDB 権限を持つ AWS Identity and Access Management (IAM) ロールを使用して Amazon Linux を実行している Amazon Elastic Compute Cloud (Amazon EC2) インスタンス AWS コマンドラインインターフェイス (AWS CLI) がインストールおよび設定されていること AWS Terraform Provider バージョン 6.28.0 以降（ aws_dynamodb_global_secondary_index リソースは v6.28.0 で導入されました） aws_dynamodb_global_secondary_index リソースは、現在 Terraform AWS プロバイダー で 実験的 としてマークされています。これは、スキーマや動作が予告なく変更される可能性があり、プロバイダーの下位互換性保証の対象ではないことを意味します。 この実験的リソースを有効にするには、環境変数 TF_AWS_EXPERIMENT_dynamodb_global_secondary_index を設定する必要があります。この環境変数がないと、 aws_dynamodb_global_secondary_index を使用しようとしたときに Terraform がエラーを返します。Terraform コマンドを実行する前に設定してください。 export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 本番環境で使用する前に、非本番環境で十分にテストしてください。 GitHub Issue #45640 でフィードバックを提供することを歓迎します。 AWS Provider v5.x から v6.x にアップグレードする場合は、続行する前に v6.0.0 アップグレードガイド で破壊的変更を確認してください。 Amazon Linux に Terraform をインストール: # システムを更新 sudo yum update -y # yum-config-manager をインストール sudo yum install -y yum-utils # HashiCorp リポジトリを追加 sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo # Terraform をインストール sudo yum -y install terraform # インストールを確認 terraform --version 新しいリソースの使用 新しい個別リソース方式を使用して、2 つの GSI を持つプロビジョニングされたキャパシティテーブルを作成します。テーブルと GSI が独立したリソースとして定義される main.tf を作成します。 テーブルと GSI のキー: リソース ハッシュキー レンジキー キャパシティ Table id timestamp 5/5 StatusUserIndex status user_id 5/5 TimestampIndex timestamp – 3/3 設定: terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.28" } } } provider "aws" { region = "us-east-1" } # GSI ブロックのない DynamoDB テーブル（GSI は個別に管理） # テーブルキー（hash_key/range_key）として使用される属性のみを定義 # GSI 属性は個別の aws_dynamodb_global_secondary_index リソースで定義 resource "aws_dynamodb_table" "test_table" { name = "GSITestTable" billing_mode = "PROVISIONED" read_capacity = 5 write_capacity = 5 hash_key = "id" range_key = "timestamp" attribute { name = "id" type = "S" } attribute { name = "timestamp" type = "N" } tags = { Name = "GSITestTable" Environment = "test" Purpose = "Testing new GSI resource" } } # 個別リソースとしての GSI resource "aws_dynamodb_global_secondary_index" "status_index" { table_name = aws_dynamodb_table.test_table.name index_name = "StatusUserIndex" # プロビジョニングされたスループット設定 provisioned_throughput { read_capacity_units = 5 write_capacity_units = 5 } # key_schema に attribute_type が含まれるようになりました（新しいリソースで必須） key_schema { attribute_name = "status" attribute_type = "S" key_type = "HASH" } key_schema { attribute_name = "user_id" attribute_type = "S" key_type = "RANGE" } # プロジェクション設定 projection { projection_type = "ALL" } # 新しい個別リソースでは、GSI ごとに特定の属性を無視できるようになりました lifecycle { ignore_changes = [provisioned_throughput] } } # 複数の独立した GSI をテストするための 2 番目の GSI resource "aws_dynamodb_global_secondary_index" "timestamp_index" { table_name = aws_dynamodb_table.test_table.name index_name = "TimestampIndex" # プロビジョニングされたスループット設定 provisioned_throughput { read_capacity_units = 3 write_capacity_units = 3 } key_schema { attribute_name = "timestamp" attribute_type = "N" key_type = "HASH" } # プロジェクション設定 projection { projection_type = "KEYS_ONLY" } # この GSI は Terraform によって完全に管理されます（ignore_changes なし） } リソースをデプロイします: # 必要な環境変数を設定 export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 terraform init terraform plan terraform apply StatusUserIndex （ ignore_changes を持つもの）のキャパシティを手動で変更して、選択的な ignore_changes をテストします: aws dynamodb update-table \ --table-name GSITestTable \ --region us-east-1 \ --global-secondary-index-updates '[{ "Update": { "IndexName": "StatusUserIndex", "ProvisionedThroughput": { "ReadCapacityUnits": 10, "WriteCapacityUnits": 10 } } }]' # 更新が完了するまで待機 sleep 30 terraform plan を実行すると、 StatusUserIndex のキャパシティが AWS で 10/10 に変更されたにもかかわらず、 No changes と表示されます。これは ignore_changes = [provisioned_throughput] のために発生します。 TimestampIndex （ ignore_changes のないもの）を手動で変更して、ドリフト検出が機能することを確認します: aws dynamodb update-table \ --table-name GSITestTable \ --region us-east-1 \ --global-secondary-index-updates '[{ "Update": { "IndexName": "TimestampIndex", "ProvisionedThroughput": { "ReadCapacityUnits": 8, "WriteCapacityUnits": 8 } } }]' # 更新が完了するまで待機 sleep 30 terraform plan を実行すると、ドリフトが検出され、 TimestampIndex のキャパシティを 8 から 3 に戻すことが提案されます。これにより、以下が実証されます: StatusUserIndex は変更なし（意図したとおりキャパシティが無視される） TimestampIndex はドリフト検出（キャパシティの変更が検出される） 各 GSI は独立したライフサイクル管理を持つ GSI ごとに特定の属性を選択的に無視できる Terraform は ignore_changes のない GSI の重要な変更を検出する 従来の方法との主な違いは、テーブルがテーブル自体で使用される属性（ id 、 timestamp ）を定義するのに対し、GSI 固有の属性（ status 、 user_id ）は個別の GSI リソースの key_schema ブロックで attribute_type （新しいリソースで必須）とともに定義されることです。GSI がテーブル属性を再利用する場合、その属性はテーブルの attribute ブロックに残ります。GSI は独自のライフサイクルを持つ個別のリソースです。 新しいリソースの利点 新しいリソースモデルにはいくつかの利点があります。他の GSI に影響を与えることなく、GSI の特定の属性を無視できるようになりました。自動化されたスクリプトは、Terraform のドリフトを作成することなく、トラフィックパターンに基づいてキャパシティを調整できます。キースキーマの変更などの重要な変更を追跡し、偶発的な GSI の削除や再設定がないことを確認できます。Terraform の状態は GSI 構造の信頼できる情報源のままであり、DynamoDB API は実際のランタイムキャパシティを示します。 各 GSI は独自のライフサイクルルールを持つことができ、独立した管理が可能です。新しいリソースモデルは、各リソースが 1 つの論理インフラストラクチャコンポーネントを管理し、依存関係がリソース参照を通じて明示的であり、状態管理がより簡単になるという Terraform のベストプラクティスに従っています。 新しいリソースは、 オンデマンドテーブルのウォームスループット設定 を完全にサポートしています。ウォームスループットは、オンデマンドテーブルのベースラインキャパシティを指定するために使用できる DynamoDB の機能で、パフォーマンスとコストをより予測可能に管理するのに役立ちます。以下はテスト方法です。 ondemand.tf を作成します: resource "aws_dynamodb_table" "ondemand_test" { name = "OnDemandGSITest" billing_mode = "PAY_PER_REQUEST" hash_key = "id" attribute { name = "id" type = "S" } } resource "aws_dynamodb_global_secondary_index" "category_index" { table_name = aws_dynamodb_table.ondemand_test.name index_name = "CategoryIndex" key_schema { attribute_name = "category" attribute_type = "S" key_type = "HASH" } # プロジェクション設定 projection { projection_type = "ALL" } # ウォームスループット設定（ブロックではなく属性） warm_throughput = { read_units_per_second = 13000 write_units_per_second = 5000 } lifecycle { # 手動でのウォームスループットチューニングを許可 ignore_changes = [warm_throughput] } } デプロイしてテストします: # まだ設定されていない場合は、必要な環境変数を設定 export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 terraform apply # ウォームスループットを手動で変更 aws dynamodb update-table \ --table-name OnDemandGSITest \ --region us-east-1 \ --global-secondary-index-updates '[{ "Update": { "IndexName": "CategoryIndex", "WarmThroughput": { "ReadUnitsPerSecond": 14000, "WriteUnitsPerSecond": 5100 } } }]' # 更新を待機 sleep 30 # terraform plan を実行 terraform plan ウォームスループットの変更は期待どおり無視されるため、Terraform は No changes を表示します。 次のセクションに進む前に、オンデマンドテストリソースを破棄します: terraform destroy 移行の例 新しいリソースの動作を確認したので、既存のインフラストラクチャの完全な実践的な移行を見ていきましょう。従来のネストされた GSI アプローチを使用するテーブルから始めて、ダウンタイムなしで新しい個別リソース方式に移行します。 ステップ 1: 従来の方法でインフラストラクチャを作成 従来のネストされたブロックアプローチを使用して、GSI を持つ DynamoDB テーブルを作成します。 migration-old.tf というファイルを作成します: terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.28" } } } provider "aws" { region = "us-east-1" } # 従来のアプローチ: GSI がネストされたブロックとして定義 resource "aws_dynamodb_table" "products" { name = "ProductsTable" billing_mode = "PROVISIONED" read_capacity = 5 write_capacity = 5 hash_key = "ProductId" attribute { name = "ProductId" type = "S" } attribute { name = "Category" type = "S" } # GSI がネストされたブロックとして定義（従来の方法） global_secondary_index { name = "CategoryIndex" hash_key = "Category" projection_type = "ALL" read_capacity = 3 write_capacity = 3 } tags = { Name = "ProductsTable" Environment = "migration-demo" } } このインフラストラクチャをデプロイします: terraform init terraform plan terraform apply テーブルと GSI が作成されたことを確認します: aws dynamodb describe-table --table-name ProductsTable --region us-east-1 \ --query 'Table.GlobalSecondaryIndexes[0].IndexName' 出力: CategoryIndex ステップ 2: 移行の準備 移行する前に、Terraform の状態をバックアップします: terraform state pull > backup-before-migration.tfstate 必要な環境変数を設定します: export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 ステップ 3: Terraform 設定を更新 更新された設定で migration-new.tf という新しいファイルを作成します。今のところ両方のファイルを保持します。インポート後に古いファイルを削除します。 terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 6.28" } } } provider "aws" { region = "us-east-1" } # 更新されたテーブル: GSI ブロックを削除 resource "aws_dynamodb_table" "products" { name = "ProductsTable" billing_mode = "PROVISIONED" read_capacity = 5 write_capacity = 5 hash_key = "ProductId" # テーブル自身のキーで使用される属性のみを定義 attribute { name = "ProductId" type = "S" } tags = { Name = "ProductsTable" Environment = "migration-demo" } } # 新規: 個別リソースとしての GSI resource "aws_dynamodb_global_secondary_index" "category_index" { table_name = aws_dynamodb_table.products.name index_name = "CategoryIndex" # プロビジョニングされたスループット設定 provisioned_throughput { read_capacity_units = 3 write_capacity_units = 3 } key_schema { attribute_name = "Category" attribute_type = "S" key_type = "HASH" } # プロジェクション設定 projection { projection_type = "ALL" } # 運用チームが Terraform による復元なしでキャパシティを調整できるようにする lifecycle { ignore_changes = [provisioned_throughput] } } ステップ 4: 古い設定を削除 古いファイルを削除または名前変更します: mv migration-old.tf migration-old.tf.backup この時点で terraform plan を実行すると、Terraform がテーブルから GSI を削除し（ネストされたブロックがなくなったため）、新しい個別の GSI リソースを作成しようとすることがわかります。 まだ適用しないでください。 これによりダウンタイムが発生します。代わりに、既存の GSI をインポートします。 ステップ 5: 既存の GSI をインポート 既存の GSI を新しいリソースの状態にインポートします: # インポート形式: 'table_name,index_name' terraform import aws_dynamodb_global_secondary_index.category_index \ 'ProductsTable,CategoryIndex' 出力: aws_dynamodb_global_secondary_index.category_index: Importing from ID "ProductsTable,CategoryIndex"... aws_dynamodb_global_secondary_index.category_index: Import prepared! Prepared aws_dynamodb_global_secondary_index for import aws_dynamodb_global_secondary_index.category_index: Refreshing state... [id=ProductsTable,CategoryIndex] Import successful! ステップ 6: 移行を確認 terraform plan を実行して確認します: terraform plan 期待される出力: aws_dynamodb_table.products: Refreshing state... [id=ProductsTable] aws_dynamodb_global_secondary_index.category_index: Refreshing state... [id=ProductsTable,CategoryIndex] No changes. Your infrastructure matches the configuration. No changes と表示された場合、移行は成功しています。GSI は個別のリソースとして管理されるようになりました。 移行の概要 移行を完了するには、従来のネストされた GSI 設定から始め、 terraform import を使用してダウンタイムなしで個別の GSI リソースに移行しました。その後、 terraform plan で No changes が表示されることで移行を確認し、新しいリソースモデルへの移行に成功しました。 重要なポイント: 移行には terraform import を使用 AWS リソースは変更または再作成されない GSI は移行中も存在し続け、ダウンタイムはゼロ 移行後、 ignore_changes で無視する内容をきめ細かく制御できる 移行プロセスは安全で元に戻すことができる 移行に関する考慮事項 aws_dynamodb_global_secondary_index リソースを aws_dynamodb_table の global_secondary_index ブロックと組み合わせないでください。そうすると、競合、永続的な差異、GSI の上書きが発生する可能性があります。 移行する際は、以下の手順に従ってください: 状態をバックアップ : terraform state pull > backup.tfstate 環境変数を設定 : export TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 設定を更新 : テーブルから GSI ブロックを削除し、新しい GSI リソースを作成 既存の GSI をインポート : terraform import <resource> 'table_name,index_name' 確認 : terraform plan を実行し、 No changes と表示されることを確認 テスト : キャパシティを手動で変更し、Terraform が変更を無視することを確認 terraform import を使用して正しく行えば、移行中にダウンタイムは発生しません。GSI は移行中も AWS に存在し続けます。 terraform import コマンドは Terraform の状態ファイルのみを更新し、AWS リソースは変更しません。 テーブルに複数の GSI がある場合は、一度に 1 つずつ移行します: 最初の GSI をインポートし、 terraform plan で確認 2 番目の GSI をインポートし、 terraform plan で確認 すべての GSI が移行されるまで続ける これによりリスクが軽減され、トラブルシューティングが簡素化されます。 比較: 従来の方法と新しい方法 以下の表は、従来のネストされたブロックアプローチと新しい個別リソース方式の主な違いをまとめたものです: 側面 従来の方法（ネストされたブロック） 新しい方法（個別リソース） リソースの有効化 環境変数は不要 TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 が必要 きめ細かい ignore_changes サポートされていない サポートされている 独立した GSI 管理 すべての GSI が一緒に管理される 各 GSI が独立して管理される ドリフト検出 全部か無か GSI ごとに選択的 ライフサイクルルール すべての GSI に適用 GSI ごとのライフサイクルルール 状態管理 複雑なネストされた状態 簡単なフラットな状態 キャパシティ設定 トップレベル属性（ read_capacity 、 write_capacity ） ブロック構文（ provisioned_throughput ブロック） プロジェクション設定 トップレベル属性（ projection_type ） ブロック構文（ projection ブロック） ウォームスループットのサポート 限定的 完全サポート（属性構文: warm_throughput = { } ） 移行の複雑さ N/A インポートプロセスが必要 下位互換性 既存の方法 従来の方法と混在できない 安定性 安定 実験的（スキーマが変更される可能性あり） クリーンアップ 今後の料金の発生を避けるために、このウォークスルーで作成したリソースを削除します: # Terraform で管理されているすべてのリソースを破棄 terraform destroy # プロンプトが表示されたら削除を確認 # 続行するには 'yes' と入力 テスト中に手動で作成したリソースがある場合は、今後のコストの発生を避けるために、AWS マネジメントコンソールまたは AWS CLI を通じてそれらも削除してください。 まとめ この記事では、新しい aws_dynamodb_global_secondary_index リソースが、Terraform での DynamoDB GSI ドリフト管理という長年の課題をどのように解決するかを示しました。ネストされた global_secondary_index ブロックを無視する全部か無かの性質は、運用の柔軟性とインフラストラクチャガバナンスの間にギャップを生み出していました。 GSI をファーストクラスのリソースとして扱うことで、特定の GSI 属性に対する選択的な ignore_changes によるきめ細かい制御、各 GSI が独自のライフサイクルルールを持つ独立した管理、運用上の調整を許可しながら重要な変更を追跡するより良いドリフト検出、テーブルとインデックス設定の関心の分離によるより簡単なアーキテクチャを獲得できます。 aws_dynamodb_global_secondary_index リソースは現在 実験的 としてマークされていることを覚えておいてください。GSI ドリフトを管理するための強力な機能を提供しますが、以下の点に注意してください: スキーマや動作は将来のプロバイダーバージョンで変更される可能性がある このリソースを有効にするには、環境変数 TF_AWS_EXPERIMENT_dynamodb_global_secondary_index=1 を設定する必要がある プロバイダーの下位互換性保証の対象ではない このリソースを同じテーブルの従来の global_secondary_index ブロックと混在させることはできない 常に非本番環境で十分にテストし、プロバイダーのリリースノートで更新を監視してください。フィードバックがある場合は、 GitHub Issue #45640 で提供して、この機能の将来を形作るのに役立ててください。 本記事は 2026 年 02 月 09 日 に公開された “New in Terraform: Manage global secondary index drift in Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/new-in-terraform-manage-global-secondary-index-drift-in-amazon-dynamodb/ 著者について Vaibhav Bhardwaj Vaibhav は、AWS シンガポールを拠点とするシニア DynamoDB スペシャリストソリューションアーキテクトです。19 年の経験を持つサーバーレス愛好家で、DynamoDB を使用した高性能、スケーラビリティ、信頼性を要求するアプリケーションのアーキテクチャを設計するために顧客と協力することを好みます。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 フィジカル AI 開発支援プログラム by AWS ジャパン の募集を開始しました。本プログラムは AWS 上で Vision-Language-Action (VLA) をはじめとしたロボット基盤モデル等を開発する、日本に法人または拠点を持つ企業・団体を支援するものです。データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築を支援し、AI のロボティクスへの活用を推進することを目指します。2/13 までに応募締め切りなので、我こそはという方はぜひお申込みください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2026年2月2日週の主要なアップデート 2/2(月) Amazon CloudFront がオリジンに対する相互 TLS サポートを発表 Amazon CloudFront が オリジンサーバーに対する相互 TLS 認証 (mTLS) をサポート開始しました。これまで CloudFront からのリクエストかどうかを検証するには、共有シークレットヘッダーや IP 許可リストなどのカスタム認証が必要でした。新機能により TLS 証明書による標準的な認証が可能になり、より簡単にセキュリティ向上が出来る機能です。詳細は こちらのドキュメントをご参照ください。 AWS Multi-party approval でワンタイムパスワード認証による投票が必要になりました AWS Organitzaions の中に含まれる AWS Multi-party approval という機能で、承認者の投票時にワンタイムパスワード (OTP) 検証が必須になりました。これまで IAM Identity Center の管理者が承認者を偽装して承認を回避できる問題がありましたが、この機能により確実に本人確認ができるようになります。投票時に 6 桁のコードがメールで送信され、10 分以内に入力することで投票が完了します。全リージョンで追加料金なしで利用可能です。 AWS STS が Google、GitHub、CircleCI、OCI からの特定のアイデンティティプロバイダー固有のクレームの検証をサポート AWS STS で Google や GitHub などの外部認証プロバイダーからの詳細情報を使った、より細かいアクセス制御が可能になりました。従来は基本的な認証情報のみでしたが、今回のアップデートでプロバイダー固有のクレーム情報を IAM ポリシーの条件として利用できるようになります。例えば GitHub のリポジトリ名や Google のドメイン情報などを条件に含めることで、セキュリティを強化しながら柔軟な権限管理が実現できます。 Amazon Lightsail でメモリ最適化インスタンスバンドルの提供開始を発表 Amazon Lightsail で最大 512 GB メモリを搭載したメモリ最適化インスタンスの提供が開始されました。従来の Lightsail では高メモリが必要なワークロードの実行が難しかった場合があり、EC2 を選択していたこともあったと思います。今回のアップデートでインメモリデータベースやリアルタイム分析など、より多くのメモリが必要なワークロードを実行しやすくなりました。7 つのサイズ (512, 384, 256, 128, 64, 32, 16 GB) から選択でき、Linux と Windows の両方に対応しています。 DeepSeek OCR、MiniMax M2.1、および Qwen3-VL-8B-Instruct モデルが SageMaker JumpStart で利用可能になりました Amazon SageMaker JumpStart で DeepSeek OCR、MiniMax M2.1、Qwen3-VL-8B-Instruct の 3 つの新しい AI モデルが利用可能になりました。DeepSeek OCR は請求書や複雑な文書から構造化された情報を抽出でき、MiniMax M2.1 は多言語でのソフトウェア開発を自動化し、Qwen3-VL-8B-Instruct は高度な視覚認識と推論機能を提供します。これらのモデルにより、文書処理から自動コーディング、画像解析まで幅広い AI アプリケーションの構築が可能になります。詳細は こちらのドキュメントをご参照ください。 2/3(火) AWS IAM Identity Center が複数の AWS リージョンでのアカウントアクセスとアプリケーション利用を可能に AWS IAM Identity Center で複数リージョンでのアカウントアクセスが可能になりました。従来はプライマリリージョンのみでの利用でしたが、今回のアップデートで追加リージョンへの複製が可能となり、リージョン障害時でも継続してアクセスできるようになります。Okta などの外部 ID プロバイダーと連携した組織で、17 の商用リージョンで利用できます。災害対策やデータ居住性要件への対応、ユーザーに近いリージョンでのアプリケーション展開など、ビジネス要件に合わせた柔軟な運用が実現できます。詳細は こちらのドキュメントをご参照ください。 AWS マネジメントコンソールのナビゲーションバーにアカウント名を表示し、アカウント識別を容易にする機能が利用可能に AWS マネジメントコンソールのナビゲーションバーにアカウント名が表示されるようになりました。従来はアカウント番号のみで識別していましたが、開発環境と本番環境など複数のアカウントを使い分けている場合でも、名前でひと目で判別できます。全パブリックリージョンで無料利用可能で、管理者が機能を有効化する必要があります。 Amazon DynamoDB グローバルテーブルが複数の AWS アカウント間でのレプリケーションをサポート Amazon DynamoDB グローバルテーブルが複数の AWS アカウント間でのデータレプリケーションに対応しました。これまでは同一アカウント内のリージョン間のみでしたが、アカウントをまたいだレプリケーションが可能になります。複数アカウント戦略を採用する組織では、セキュリティ分離やビジネス単位での管理を維持しながら、災害復旧や高可用性を実現できます。詳細は こちらのドキュメントをご参照ください。 2/4(水) Amazon EC2 と VPC でセキュリティグループの関連リソースが表示されるようになりました Amazon EC2 と VPC コンソールで、セキュリティグループの「Related resources」タブが利用可能になりました。これまでセキュリティグループを変更や削除する前に、EC2 インスタンスや RDS データベースなど複数のサービスを個別に確認する必要がありましたが、今回のアップデートで依存関係のあるリソースを一箇所で確認できるようになりました。大規模な環境でセキュリティグループが多数のリソースに紐づいている場合に特に有効で、変更の影響範囲を素早く把握できるため、作業効率が大幅に向上します。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock で構造化出力が利用可能になりました Amazon Bedrock で 構造化出力が利用可能になりました。これまで JSON 形式のレスポンスを得るためにプロンプトで指定し、アプリケーション側で追加チェックが必要でしたが、今回のアップデートで JSON スキーマを定義するだけで一貫性のある機械読み取り可能な応答を取得できるようになりました。API やツールを使用するワークフローで、小さなフォーマットエラーが下流システムを壊すリスクを大幅に削減し、カスタム検証ロジックの必要性を減らすことでプロダクション環境での信頼性が向上します。詳細は こちらのドキュメントをご参照ください。 2/5(木) Claude Opus 4.6 が Amazon Bedrock で利用可能になりました Amazon Bedrock で Claude Opus 4.6 が利用可能になりました。Anthropic 社の最新かつ最も高性能な AI モデルで、複雑なコーディングや企業向けタスクに優れています。200K から 1M トークンまでの長文処理が可能で、大規模なドキュメントやコードベースの分析ができます。詳細は こちらのリリース記事をご参照ください。 Amazon WorkSpaces が Graphics G6、Gr6、G6f バンドルを開始 Amazon WorkSpaces で新たに Graphics G6、Gr6、G6f バンドルが利用可能になりました。これらは GPU を活用したグラフィック集約的な作業に特化したバンドルです。CAD や 3D レンダリング、機械学習モデルの訓練など、従来の WorkSpaces では性能不足だった高負荷な作業が快適に行えるようになります。G6f バンドルでは部分的な GPU 利用も可能で、コストを抑えながら GPU 性能を活用できる点が魅力です。東京リージョンを含む 13 リージョンで提供されています。 2/6(金) AWS Network Firewall が新たな料金削減を発表 AWS Network Firewall で価格改定が実施され、コスト削減につながる 2 つの改善が行われました。従来はプライマリエンドポイントのみ対象だった NAT Gateway 割引が、セカンダリエンドポイントでも適用されるようになり、複数 VPC を保護する際の運用コストを削減できます。また、暗号化通信を検査する Advanced Inspection 機能の追加データ処理料金 (最大 0.009/GB) が廃止され、TLS インスペクションをより低コストで実装可能になりました。詳細は こちらの料金ページをご参照ください。 Amazon Bedrock AgentCore Browser がブラウザプロファイルをサポート開始 Amazon Bedrock AgentCore Browser でブラウザプロファイル機能がサポートされました。これにより、一度ログインした認証状態を複数のブラウザーセッション間で再利用でき、これまで毎回ログインが必要だった作業が軽減できます。企業での大量自動化処理において、セッション開始時間が数分から数十秒に短縮される大きなメリットがあります。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

CO2 排出量可視・削減サービス「e-dash」化を支えるサーバーレスアーキテクチャと IaC 戦略 こんにちは、AWS ソリューションアーキテクトの松本 敢大です。 本日は、三井物産発の環境系スタートアップである e-dash 株式会社様が提供する CO2 排出量可視化・削減サービスプラットフォーム「e-dash」のシステム構築事例をご紹介します。e-dash 株式会社 プロダクト開発部部長の佐藤様、プロダクト開発部の伊藤様、竹内様に、AWS を活用したモダンなアプリケーション開発の取り組みについてお話を伺いました。 e-dash 株式会社について e-dash 株式会社は、「脱炭素を加速する」をサービスミッションとして掲げ、CO2 排出量の現状把握・報告・削減を一気通貫で行うサービスプラットフォーム「e-dash」を開発・運営しています。手間なく正確に CO2 排出量の可視化が叶うクラウドサービスと伴走型のコンサルティングサービスを組み合わせ、企業や自治体の CO2 排出量削減への取り組みを総合的に支援しています。また、サプライチェーンにわたり脱炭素の対話を持つための「e-dash Survey」や、製造した製品自体の環境負荷を算出する「e-dash CFP」も提供し、幅広い脱炭素経営のニーズに応えています。 「e-dash」サービスの特徴 AWS: まず 、 「e-dash」のサービス概要について教えていただけますか? e-dash 佐藤: 「e-dash」は、企業が電気や都市ガスなどのエネルギー使用量の請求書をアップロードするだけで、その使用量が自動的にデータ化され、グラフ形式で CO2 排出量が計算されるサービスです。従来の CO2 排出量管理サービスでは、エネルギー使用量を手動で入力する必要がありましたが、 「e-dash」では請求書をアップロードするだけで自動的にデータ化されるため、入力作業の負担を大幅に削減しながら、請求書を証票とした正確なデータ蓄積ができます。可視化も削減も専門家がお客さまに伴走しながら、継続的に成果を生み出す改善プロセスを構築します。また環境省が公表する排出係数を自社データベースに取り込み、当該係数に基づいた正確な CO2 排出量算定を行っています。 AWS: カーボンフットプリント（CFP）への対応状況について教えてください。 e-dash 佐藤: 「e-dash CFP」という製品を提供しています。製品・サービスのライフサイクル全体で発生する排出量を可視 化できます。原材料調達から製造、流通、廃棄まで、多岐にわたる工程を一元的に管理できるため、企業の脱炭素戦略における基盤として活用いただけます。 AWS: Scope 3 の算定は可能ですか？ e-dash 佐藤: 可能です。「e-dash」は Scope 1・2 はもちろん、Scope 3 も網羅的に算定できる設計になっています。環境省・経済産業省のガイドラインに準拠した算定ロジックを採用しており、サプライチェーン全体の排出量を正確に把握できます。 AWS: 省エネ法報告機能について教えてください。 e-dash 佐藤: 省エネ法については、「e-dash」で収集・算定したデータをそのまま報告に活用できる仕組みを提供しています。必要な数値を自動で整理できるため、これまで煩雑だった報告作業の負担を大幅に軽減できます。 AWS を活用したシステムアーキテクチャ AWS: システム構築の背景について教えていただけますか? e-dash 伊藤・竹内: スタートアップとして短期間で本番稼働が求められるなか、 外部委託から内製化へと移行 し、 制度改正や機能追加 への即応性を高める必要がありました。2024 年 4 月にリリースした「e-dash」は、それまで運用していたシステムを全面リプレイスしたもので、約 12 ヶ月の開発期間をかけて 10 名体制で再構築しました。現在は 3 名で運用を行っており、新規サービスや 追加機能の開発についても、通常 2 週間程度で完了 できる体制を構築しています。 AWS: インフラは基本的に AWS で構築されているとのことですが、その理由を教えていただけますか? e-dash 伊藤・竹内: AWS を選択した理由は大きく 3 つあります。 第一に、情報量の豊富 さです。AWS は情報の数が多いので、トラブルが起きても簡単に解決できます。ドキュメントやコ ミュニティの情報が充実しているため、問題解決のスピードが速いです。 第二に、チームの経験 です。私たちのチームメンバーも AWS を使った構築経験が豊富で、使い慣れたサービスを活用できることは大きなメリットでした。 第三に、サポートの質の高さ です。他のクラウドベンダーとは異なり、AWS のサポートは非常にレベルが高いと感じています。単純な調査だけでなく、私たちの目線で支援していただいていると実感しています。また、コミュニティ活動が盛んで、他社の AWS ユーザーと情報交換しやすい環境も魅力です。 サーバーレスを基本としたアーキテクチャ設計 AWS: 具体的なアーキテクチャについて教えていただけますか? e-dash 伊藤・竹内: 「e-dash」のインフラは基本的に AWS で構築しています。スタートアップとして限られた人数で運用する必要があるため、 フルマネージドサービスを積極的に採用 し、インフラ管理の負担を最小限に抑えています。アーキテクチャの基本は Amazon ECS on Fargate と Amazon Aurora を利用しています。フロントエンドとバックエンドのアプリケーション実行基盤として ECS on Fargate を採用しています。CSV のエクスポート処理などは AWS Batch 、アップロード処理は AWS Lambda を利用しています。 AWS: データベースの使い分けについて、もう少し詳しく教えていただけますか? e-dash 伊藤・竹内: はい。 Amazon Aurora は、フルマネージドサービスとしての運用性の高さと、フェイルオーバー機能による高可用性を評価して採用 しました。本番環境ではライターとリーダーのマルチ AZ 構成でフェイルオーバーを実現しています。管理負荷が低いので基本的にフルマネージドサービスを使うようにしています。 Amazon DynamoDB は企業名管理など、単純な構造のデータ管理に活用しています。高いパフォーマンスが求められないサービスでも、可用性の高さおよびコストの安さから特定のマスタデータ管理に利用しています。 Amazon ElastiCache は、分単位で更新が必要なリアルタイム性の高いサービスで活用しています。揮発しても問題ない一時的な計算データを格納し、パフォーマンスの最適化を図っています。 AWS: イベント駆動アーキテクチャについても教えていただけますか? e-dash 伊藤・竹内: 請求書処理フローでは、イベント駆動アーキテクチャを採用しています。Amazon ECS on Fargate から Amazon S3 へ請求書データがアップロードされると、S3 イベント通知をトリガーとして AWS Lambda が起動し、OCR 処理へと連携します。 開発速度を支える IaC 戦略 AWS: 開発速度を向上させるための工夫について教えていただけますか? e-dash 伊藤・竹内: 私たちは、 Infrastructure as Code (IaC) を徹底的に推進 しています。 AWS Organizations 、 AWS Identity Center を含むすべての AWS リソースを Terraform で管理し、モジュールの共有により新規サービスの展開を迅速化しています。通常、新規サービスの構築には約 2 週間を要しますが Terraform モジュールの活用により、サービスの拡大に合わせて継続的にリアーキテクトしながらも、この期間を維持できています。 AWS: 権限管理についても自動化されているとお聞きしました。 e-dash 伊藤・竹内: はい。工夫している点として、GitHub と AWS のアカウント権限管理もすべてコード化されています。開発メンバーが Devin (AI アシスタント) に依頼すると、プルリクエストが自動生成され、SRE メンバーがレビュー・承認するだけでユーザーの追加・削除が完了する仕組みを構築しています。 直面した課題と解決 AWS: システム構築において直面した課題はありますか? e-dash 伊藤・竹内: 当初は外部委託でシステムを構築していましたが、スタートアップとして短期間で本番稼働が求められるなか、制度改正や機能追加への即応性を高める必要がありました。そこで、内製化へと移行し、AWS のマネージドサービスを積極的に活用することで、限られたリソースでも高品質なサービスを迅速に展開できる体制を整えました。特に、Terraform による徹底した IaC 管理により、新規サービスの構築期間を約 2 週間に短縮できたことは大きな成果です。 今後の展望 AWS: 今後の技術的な展望について教えていただけますか? e-dash 伊藤・竹内:請求書アップロード機能においては、OCR の精度向上を継続的なテーマとして推進していきます。また、開発チームでは AI の活用を積極的に進め、開発フロー全体の効率化を図ります。定常的な業務を AI で自動化・半自動化することで、エンジニアがより価値の高い領域に集中できる体制を整備していきます。 著者について e-dash 株式会社様 佐藤 孝明（さとう たかあき）の紹介 新卒で野村総合研究所に入社し、システムエンジニアとして証券会社向けのバックオフィスシステムの開発・運用を担当。その後スタートアップ企業にてプロダクトマネージャとして、新規プロダクトの立ち上げ、組織開発を経験し、日産自動車にてコネクティドカーサービスのスマホアプリのプロダクトオーナーとして、プロダクトロードマップおよび KGI/KPI の策定と実行などの業務を行いコネクティド事業の収益拡大に寄与。2022 年 10 月から e-dash にプロダクトマネージャーとしてジョイン。 伊藤 明彦（いとう あきひこ）の紹介 新卒で野村総合研究所に入社し、様々な業界の IT システムの基盤設計・構築・運用を推進。その後スタートアップ企業にて開発リードとして、新規プロダクトの設計・開発・運用を担当。2024 年 9 月から e-dash にジョイン。現在は SRE チームのリーダーを担当。 竹内 克史（たけうち かつし）の紹介 バックエンドエンジニアとして複数サービスの開発に従事した後、現在は SRE としてインフラストラクチャの設計・運用を担当している。AWS を活用した信頼性向上施策、パフォーマンス改善、監視基盤の整備、自動化基盤の構築など、サービスの安定稼働を支える技術領域を幅広く推進している。2023 年 6 月に e-dash にジョイン。 アマゾンウェブサービスジャパン合同会社 松本 敢大 (Kanta Matsumoto) ソリューションアーキテクトとして、商社業界のお客様を中心に技術支援を行っています。様々な領域の商社という業界で沢山の刺激を受けております。新入社員育成として、新卒生成 AI 活用ブログ（ ブログ1 、 ブログ2 、 ブログ3 、 ブログ4 ）などを投稿。AWS User Group – Japan IoT 支部で登壇などをしております。Physical AI が最近のブームです 好きな AWS サービスは AWS IoT Core（ ブログ5 ）。趣味はカメラで、動物が好きです。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今年の目標は Kiro にどんどん業務をオフロードしていくことです。早速 Kiro を使って Strands Agent SOPs を作成してステアリングファイルとして利用してみましたが、複雑なワークフローでのエージェントの振る舞い記述を標準化できて便利ですね。 また、2月の Builder’s Flash も公開されております。生成 AI に関連する記事をピックアップしてみましたので、是非ご覧ください。 “伝わらない”を解消 ! 生成 AI で磨くAWS サポートケース起票スキル ~ 生成 AI 活用による問題解決の効率化 ~ AI エージェントで分析効率を飛躍的に向上させる実装ガイド 開発以外にも使える !? Bedrock Engineer の AI エージェントをカスタマイズしてみよう ! 限られた学習データでの画像生成 AI モデル開発とコスト最適化 エージェント自体の開発だけでなく、ユースケースを掘り下げる記事も公開されていますね。 新たに発表された「 フィジカル AI 開発支援プログラム 」をはじめとした各種「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き募集しております。特に「フィジカル AI 開発支援プログラム」は応募締め切りが2026年2月13日までとなっているので、ご興味のある方はぜひご確認ください。 それでは、2 月 3 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ:  地方病院が生成 AI の活用環境を2日で構築し内製化へ踏み出す 熊本中央病院様は、ANGEL Dojo 2025 で医療文書作成時間の削減に取り組み、月 800 時間の効率化が見込めるシステムを構築されました。しかし、電子カルテ端末からクラウドへの安全な接続と、電子カルテからのデータ抽出という2つの壁がありました。ispec様の CloudSail とAWSを組み合わせることで、2 日間という短期間で環境構築を完了し、翌日には職員を対象に 50 名以上が参加するハンズオンを実施しました。生成 AI により実装の速度やコストが低減していく中で、「やらなければいけないこと」にフォーカスして課題の特定と解決を迅速に実行した事例となっています。 開催報告「 11 社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 」を公開 2026年1月22日〜23日の2日間、AWS Loft Tokyo にて 11 社 87 名のエンジニア・ビジネスパーソンが参加した合同 AI-DLC Unicorn Gym の開催報告です。AI 駆動開発ライフサイクル（AI-DLC）は、AIを開発プロセスの中心に据えた新しい開発手法で、「AIが実行し人間が監視する」というアプローチを取ります。AI-DLC は特定のツールに依存せず、ウォーターフォールやアジャイルのような開発方法論をアップデートし、AI による変革を実現するためのガイドラインです。参加企業は当初 8 週間から 6 ヶ月を想定していた開発を 2 日間で完了させ、満足度は 5 点満点中 4.56 点、98.8 %が肯定的な評価を寄せました。 開催報告「 第9回鉄道技術展2025 AWS出展報告 」を公開 2025年11月26日から29日に開催された鉄道技術展 2025 での AWS 出展報告です。「クラウドと AI で変革する鉄道保全」をテーマに、IoT と生成 AI を活用したソリューションを紹介しました。AWS IoT Services によるリアルタイムの IoT 設備状態把握、Amazon Bedrock Knowledge Bases を活用した異常発生時の初動調査支援、Amazon Bedrock AgentCore による関係システムの情報把握支援という3つの柱で構成され、鉄道保全現場が抱える労働力不足や技術継承といった課題に対応します。 ブログ記事「 Kiro で Opus 4.6 が利用可能になりました 」を公開 Kiro IDE と CLI で Anthropic の最新モデル Claude Opus 4.6 が利用可能になりました。Opus 4.6 は Anthropic がこれまでにリリースした最も強力なモデルであり、コーディングにおいては世界最高のモデルです。大規模なコードベースや長期プロジェクトで優れた性能を発揮し、シニアエンジニアが複雑なタスクを Opus 4.6 に任せることで、数日かかるプロジェクトを数時間で完了できます。Kiro の仕様駆動型開発プロセスに最も適したモデルとして、実験的サポートとして提供されます。 ブログ記事「 AI を活用したゲーム制作: 静的なコンセプトからインタラクティブなプロトタイプへ 」を公開 AWS re:Invent 2025 で紹介された Agentic Arcade の技術アーキテクチャを解説しています。参加者が AI で数分で完全にプレイ可能なゲームプロトタイプを作成できるインタラクティブなデモ体験で、Amazon Bedrock AgentCore によるマルチエージェントオーケストレーション、 ComfyUI によるプログラマティックアセット生成、セマンティック検索を組み合わせています。 AI がゲームのコンセプト化をプロセスの早い段階でインタラクティブにすることで、初期段階の開発を変革する方法を示しています。 ブログ記事「 AI エージェントをプロトタイプから製品へ: AWS DevOps Agent 開発で得た教訓 」を公開 re:Invent 2025 で発表された AWS DevOps Agent の開発で学んだ、実用的なエージェント製品を構築するために必要な5つのメカニズムを紹介しています。評価テスト（evals）の実施、エージェントの軌跡をデバッグする可視化ツール、高速なフィードバックループ、意図を持った変更、本番環境のサンプルの定期的な確認です。LLM を使ったプロトタイプ構築は参入障壁が低いものの、多様な顧客環境で確実に動作する製品へと進むのは全く別のチャレンジであることを示しています。 ブログ記事「 オブザーバビリティエージェントで平均復旧時間を短縮する 」を公開 Amazon OpenSearch Service と Amazon Bedrock AgentCore を使用したオブザーバビリティエージェントを紹介しています。ログ、トレース、メトリクスの各シグナルタイプに対応する MCP サーバーを構築し、エージェントが複数のクエリや相関サイクルを処理して根本原因の特定やインサイト取得を高速化します。 SRE やオペレーションセンターの担当者が複数のダッシュボードを行き来する手動プロセスを、 AI エージェントが体系的に調査することで平均復旧時間（MTTR）を短縮できます。 ブログ記事「 フィジカル AI: 自律型インテリジェンスに向けた次なる基盤を築く 」を公開 AWSのフィジカル AI フレームワークを紹介する複数回ブログシリーズの導入記事です。フィジカル AI を物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステムと定義し、6つの相互接続された機能（物理世界の接続とデジタル化、データの保存と構造化、データのセグメント化と理解、シミュレーション・トレーニング・モデル最適化など）を通じて、デジタルインテリジェンスと物理的アクションの間に継続的な学習サイクルを作り出す方法を説明しています。 ブログ記事「 AI による物理的な現実世界の進化: インテリジェントな自動化の最前線 」を公開 AWS Generative AI Innovation Center が MassRobotics と NVIDIA と協業して立ち上げた Physical AI Fellowship を紹介しています。フィジカル AI は、アルゴリズムがデジタルの境界を超え、物理世界を認識し、理解し、操作するもので、各業界の運営方針を根本的に変えます。記事では自動化の4段階（基本的な自動化、適応的自動化、自律的自動化、完全な自律性）を定義し、AI ロボット分野が2034年までに1,242.6億ドルに達すると予測しています。Amazon のサプライチェーンでは効率を25%向上、Foxconn は製造デプロイ時間を40%削減、ヘルスケアでは AI 支援手術により合併症発生率が30%減少するなど、具体的な成果を示しています。 ブログ記事「 VAMS における NVIDIA Isaac Lab を使用した GPU アクセラレーション型ロボットシミュレーショントレーニング 」を公開 オープンソースの Visual Asset Management System（VAMS）が NVIDIA Isaac Lab と統合され、ロボットアセット向けの GPU アクセラレーション強化学習（RL）に対応しました。実世界でロボットをトレーニングするのは遅く、コストがかかり、危険を伴いますが、Isaac Lab は単一の GPU 上で数千のロボットインスタンスを並列実行でき、実世界で数か月かかるトレーニングが数時間のシミュレーション時間に圧縮されます。VAMS の Isaac Lab パイプラインアドオンは、アセット管理システムと直接統合することで、ロボットモデルからトレーニング済みポリシーまでのシームレスなパスを作成し、 GPU インスタンス管理やコンテナオーケストレーション、手動のデータ転送を不要にします。 ブログ記事「 フィジカル AI の実践: 人間と機械の相互作用を支える技術基盤 」を公開 フィジカル AI の完全な開発ライフサイクルを解説しています。データの収集と準備、モデルのトレーニングとファインチューニング（模倣学習、強化学習、シミュレーション、ワールドモデリング）、モデルの最適化（量子化、プルーニング、蒸留、コンパイル）、エッジ操作という反復的なプロセスを通じて、人間と真のパートナーシップを築くインテリジェントシステムを作成します。実例として、Diligent Robotics の Moxi ロボットが病院環境で看護師の日常的な物流業務を処理し、患者ケアに貴重な時間を取り戻している事例を紹介しています。 ブログ記事「 知的なフィジカル AI 構築: Strands Agents、Bedrock AgentCore、Claude4.5、NVIDIA GR00T、および Hugging Face LeRobot によるエッジからクラウドへ 」を公開 エージェンティック AI システムが物理世界へ拡大する中、エッジとクラウドのハイブリッドアーキテクチャの重要性を解説しています。ボールをキャッチするロボットアームのようなミリ秒単位の応答が必要な動作はエッジで処理し、複数ステップのタスク計画や他のロボットとの連携、集合的な経験からの学習はクラウドで処理します。Strands Agents Python SDK を使用して、Ollama でエッジデバイス上でローカルにモデルを実行することから始め、段階的にクラウドの高度な推論能力を統合する進歩的なアプローチを示しています。 ブログ記事「 AI を具現化するブログ: パート1 AWS Batch でロボット学習を開始する 」を公開 AWS 上で NVIDIA Isaac GR00T N1.5 3B をファインチューニングするためのスケーラブルなインフラストラクチャを構築する方法を紹介しています。GR00T N1.5 は実世界のデモンストレーション、Isaac Labからの合成データ、インターネット規模のビデオでトレーニングされた汎用基盤モデルで、様々なタスクと実装を超えた強力な汎化能力を提供します。AWS Batch、Amazon S3、Amazon EFS、Amazon ECRを組み合わせたアーキテクチャにより、GPU付きEC2インスタンスを動的にプロビジョニングし、トレーニングワークロードを実行します。クラウドの弾力性とNVIDIAの先進的なロボット学習スタックを組み合わせることで、開発サイクルを加速します。   サービスアップデート Amazon BedrockでClaude Opus 4.6が利用可能に Amazon BedrockでClaude Opus 4.6のサポートが開始されました。Anthropicによると、Opus 4.6は同社の最も高性能なモデルであり、コーディング、エンタープライズエージェント、プロフェッショナルワークにおいて世界最高のモデルです。エージェントワークフローでは数十のツールにわたる複雑なタスクを業界最高レベルの信頼性で管理し、プロアクティブにサブエージェントを起動して少ない監視で動作します。開発者は長期プロジェクト、複雑な実装、大規模コードベースに活用でき、200Kと1Mコンテキストトークン（プレビュー）をサポートします。 Amazon SageMaker JumpStartでDeepSeek OCR、MiniMax M2.1、Qwen3-VL-8B-Instructモデルが利用可能に Amazon SageMaker JumpStartでDeepSeek OCR、MiniMax M2.1、Qwen3-VL-8B-Instructの3つのモデルが利用可能になりました。DeepSeek OCRはドキュメント処理用のビジュアルテキスト圧縮を探求し、フォーム、請求書、図、複雑なドキュメントから構造化情報を抽出できます。MiniMax M2.1はコーディング、ツール使用、指示追従、長期計画に最適化されており、多言語ソフトウェア開発の自動化や複雑な複数ステップのオフィスワークフローを実行します。Qwen3-VL-8B-Instructは優れたテキスト理解と生成、深い視覚的知覚と推論、拡張されたコンテキスト長、強化された空間とビデオダイナミクスの理解、より強力なエージェントインタラクション機能を提供します。 Amazon SageMaker JumpStartでCartesia Sonic 3テキスト読み上げモデルが利用可能に Amazon SageMaker JumpStartでCartesiaのSonic 3モデルが利用可能になりました。Sonic 3はストリーミングテキスト読み上げ（TTS）用の最新ステートスペースモデル（SSM）で、高い自然さ、正確なトランスクリプト追従、業界最高レベルのレイテンシーを実現し、音量、速度、感情のきめ細かい制御を提供します。42言語をサポートし、APIパラメータとSSMLタグを通じた高度な制御性を提供します。100ms未満のレイテンシーで、感情やトーンの変化を含む人間の音声のニュアンスを捉えるリアルタイム会話AIを実現します。 Amazon SageMaker JumpStartでNVIDIA NIMsモデルが利用可能に Amazon SageMaker JumpStartで、バイオサイエンスとフィジカルAI向けに構築された4つのNVIDIA NIMsモデル（ProteinMPNN、Nemotron-3.5B-Instruct、MSA Search NIM、Cosmos Reason）がワンクリックデプロイ可能になりました。ProteinMPNNは構造データに基づくタンパク質配列最適化を実現し、MSA Search NIMはGPU加速された複数配列アライメントをサポートします。Nemotron-3.5B-Instructは256kトークンのコンテキストウィンドウで高い推論性能とネイティブツール呼び出しサポートを提供し、Cosmos ReasonはフィジカルAIとロボティクス向けのオープンでカスタマイズ可能な推論ビジョン言語モデルです。 Amazon BedrockでStructured Outputsが利用可能に Amazon BedrockでStructured Outputsのサポートが開始されました。定義したJSONスキーマに準拠した一貫性のある機械可読な応答を基盤モデルから取得できます。有効なJSONをプロンプトで要求したり、アプリケーションに追加のチェックを加える代わりに、必要な形式を指定するだけで、それに一致する応答を受け取れます。キーフィールドの抽出やAPIまたはツールを使用するワークフローの駆動など、小さなフォーマットエラーが下流システムを壊す可能性がある本番タスクに役立ちます。Anthropic Claude 4.5モデルと一部のオープンウェイトモデルで一般提供されており、Amazon Bedrockがサポートされているすべての AWS リージョンで利用可能です。 Amazon Bedrock AgentCore BrowserでBrowser Profilesをサポート Amazon Bedrock AgentCore BrowserでBrowser Profilesのサポートが開始されました。繰り返しログインフローなしで、複数のブラウザセッション間で認証状態を再利用できます。1日に数百または数千の自動ブラウザセッションを処理するエンタープライズ顧客にとって、セッションセットアップ時間を数分から数十秒に短縮します。Webサイトに一度認証してセッションをブラウザプロファイルに保存すると、そのプロファイルを使用して新しいセッションを開始した際に認証状態が保持され、ログイン状態が維持されます。読み取り専用と永続的な操作の両方に対応する柔軟なセッションモードを選択でき、複数のセッションが同じプロファイルを同時に使用する並列処理が可能です。アジアパシフィック（東京）リージョンをはじめとした 14 の AWS リージョンで利用可能です。 Amazon EC2 Capacity Blocks for MLが複数アカウント間で共有可能に Amazon EC2 Capacity Blocks for MLのクロスアカウント共有機能が一般提供されました。AWS Resource Access Manager（RAM）を使用して、予約されたGPU容量をAWSアカウント間で共有でき、利用率の最適化とコスト削減に役立ちます。組織はCapacity Blocksを購入して複数のアカウントにプロビジョニングでき、異なるワークロードが予約容量のプールに追加コストなしでアクセスできます。チームがMLインフラストラクチャ投資を調整し、予約されたGPU容量を異なるワークロード間で継続的に使用し続けることができます。EC2 Capacity Blocks for MLが提供されているすべてのAWSリージョンで利用可能です。 Amazon EC2 G7eインスタンスが米国西部（オレゴン）リージョンで利用可能に NVIDIA RTX PRO 6000 Blackwell Server Edition GPUを搭載したAmazon EC2 G7eインスタンスが米国西部（オレゴン）リージョンで利用可能になりました。G7eインスタンスはG6eと比較して最大2.3倍の推論性能を提供します。大規模言語モデル（LLM）、エージェントAIモデル、マルチモーダル生成AIモデル、フィジカルAIモデルのデプロイに使用でき、空間コンピューティングワークロードおよびグラフィックスとAI処理の両方の機能を必要とするワークロードで最高のパフォーマンスを提供します。最大8つのNVIDIA RTX PRO 6000 Blackwell Server Edition GPU（GPU当たり96 GBのメモリ）と第5世代Intel Xeonプロセッサを搭載しています。現在 G7e インスタンスは米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）のAWSリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

本ブログは 2025 年 11 月 11 日に公開された AWS Science News “ Amazon launches private AI bug bounty to strengthen Nova models ” を翻訳したものです。 本日 (2025 年 11 月 11 日)、Amazon は Amazon Nova 基盤モデルを含む特定の Amazon AI モデルおよびアプリケーションを対象としたプライベート AI バグバウンティプログラムの開始を発表しました。このプログラムは、セキュリティ研究者やパートナー大学の専門家と連携し、潜在的なセキュリティ上の問題を特定して修正することを目的としています。この招待制プログラムは、Amazon の既存の パブリックバグバウンティプログラム を補完するものです。パブリックプログラムはすべての研究者に公開されており、Amazon AI アプリケーションにおいて 30 件以上の有効な脆弱性が報告され、55,000 ドル以上の報奨金が支払われています。 「モデルをより強力で安全にするための最善の方法は、より広いコミュニティと連携することだと考えています」と、Amazon の汎用人工知能担当シニアバイスプレジデントである Rohit Prasad 氏はコメントしています。「Nova を外部からのテストに開放することで、安全性、透明性、継続的な改善への取り組みを強化しています」 このプログラムは、アカデミックな研究とセキュリティの現場のギャップを埋めることに重点を置いています。2025 年 11 月 11 日に、Amazon の米国オースティンオフィスでライブイベントが開催され、プログラムがスタートします。このイベントでは、 Amazon Nova AI Challenge のトップ大学チームとプロフェッショナルなセキュリティ研究者が一堂に会し、実環境の AI セキュリティ課題に取り組みます。目標は、Nova モデルを含む Amazon AI モデルおよびアプリケーションのセキュリティを強化するとともに、次世代の AI セキュリティ研究者を育成することです。 セキュリティ研究者は、AI システムを調査・検証する重要な外部の専門家として、初期の開発やテストでは明らかにならない潜在的な脆弱性、バイアス、予期しない動作を特定します。このプログラムを通じて、研究者はサイバーセキュリティの問題や化学、生物、放射性物質、核 (CBRN: Chemical, Biological, Radiological, and Nuclear) 脅威の検出など、重要な領域で Nova モデルをテストします。参加資格を満たした参加者は、有効な脆弱性の報告に対して 200 ドルから 25,000 ドルの報奨金を獲得できます。 「セキュリティ研究者は、私たちの AI モデルとアプリケーションが独創的な攻撃にも耐えられるかを実際に検証してくれる、最も重要なパートナーです」と、Amazon Stores の CISO である Hudson Thrift 氏はコメントしています。「この新しいプログラムにとても期待しており、セキュリティコミュニティや大学・研究機関と連携して、AI システムをさらに安全にすることを楽しみにしています」 プログラムの重点領域 参加者に期待している調査の重点領域は以下です。 セキュリティに影響を与えるプロンプトインジェクションとジェイルブレイク 実環境での悪用の可能性があるモデルの脆弱性 モデルがセキュリティの問題や CBRN 関連の脅威など、有害な活動を意図せず手助けしてしまう手法 参加資格と参加方法 2025 年 11 月にオースティンで Amazon Bug Bounty が主催するライブイベントが、プログラムの開始を告げます。プライベートな継続的ライブプログラムへのより広い参加は、2026 年初頭にセキュリティ研究者および選ばれた研究チームに招待制で提供される予定です。プライベートプログラム外の研究者や Amazon のお客様は、 Amazon のパブリックバグバウンティプログラム を通じて、 .amazon の下にある「Gen AI Apps」を選択することで、Amazon AI アプリケーションの潜在的なセキュリティ問題を報告できます。 このプログラムが重要な理由 Nova モデルは、Alexa、Amazon Bedrock を通じた AWS のお客様、その他の Amazon 製品にわたる成長するエコシステムを支えており、そのセキュリティの確保は引き続き最優先事項です。この新しいバグバウンティプログラムは、研究コミュニティとプロフェッショナルなセキュリティコミュニティが協力することで AI の安全性が最も速く進歩するという Amazon の信念を反映しています。実践的な学習と脆弱性検出の機会を生み出すことで、Amazon は AI の次の時代を形作るシステムを守れる、新世代の研究者の育成を支援しています。 参加方法 参加に興味のある研究者は、 Amazon Science で最新情報をご確認ください。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本記事は 2026 年 2 月 4 日に公開された Venugopalan Vasudevan、Dinesh Balaaji Prabakaran、Sureshkumar Natarajan、Anjan Dave による “ AWS Transform custom: AI-driven Java modernization to reduce tech debt ” を翻訳したものです。 今日の急速に進化するソフトウェア環境において、Java アプリケーションの保守とモダナイゼーションは、多くの組織が直面する重要な課題です。新しい Java バージョンがリリースされ、ベストプラクティスが進化するにつれて、効率的なコード変換の必要性がますます重要になっています。今日の組織は、Java アプリケーションをモダナイズする際に大きな課題に直面しています。レガシーコードベースには、パフォーマンスと保守性を妨げる古いパターン、非推奨の API、非効率な実装が含まれていることがよくあります。従来の手動リファクタリングアプローチは時間がかかり、エラーが発生しやすく、大規模なコードベース全体に拡張することが困難です。さらに、開発者が新規開発とデプロイにより多くの時間を費やすにつれて、技術的負債の量は増え続け、レガシーコードの大規模な変換が必要になります。 AWS Transform custom は、インテリジェントな自動化を通じてこれらの課題に対処し、Java バージョンアップグレードなどの一般的なシナリオ向けの標準化された変換パッケージである AWS マネージド変換 (AWS-Managed Transformation) を提供します。これらの変換により、チームは大規模に実行できる標準化されテスト済みの変換パターンを通じて迅速な成果を達成でき、お客様に大幅な時間とコストの削減をもたらします。さらに、お客様はカスタム ユーザー定義のカスタム変換 を作成して、言語、フレームワークなどにわたるコード変換で技術的負債に対処できます。 この記事では、Java アップグレード用の AWS Transform custom のすぐに使える変換を活用する方法について説明します。この記事の最後までに、変換プロセスを完全に制御しながら、これらの標準化された変換を使用して Java アプリケーションを効率的にモダナイズする方法を理解できるようになります。 AWS Transform custom の紹介 AWS Transform custom は、エージェント型 AI を使用して大規模なコードモダナイゼーションを自動化し、プログラミング言語のバージョンアップグレード、API の移行、フレームワークの更新、組織固有の変換を処理します。継続的な学習を通じて、エージェントは各実行と開発者からのフィードバックから改善を重ね、専門的な自動化技術が不要な高品質で再現性のある変換を実現します。 前提条件 AWS Transform custom で Java モダナイゼーションの旅を始める前に、必要な開発環境、ビルドツール、AWS Transform custom コマンドラインインターフェイス (CLI) がインストールされていることを確認してください。詳細な前提条件とセットアップ手順については、 AWS Transform custom 利用の前提条件 を参照してください。 モダナイゼーションシナリオの理解 Movie Service アプリケーション を使用して AWS Transform custom を実演します。これは、Gradle を使用した Java 8 上に構築された Spring Boot REST API です。これは、レガシーな依存関係、古いパターン、技術的負債を伴う典型的なエンタープライズモダナイゼーションの課題を表しています。 AWS マネージド変換 (AWS-Managed Transformation) の活用 AWS Transform custom は、Java バージョンアップグレードなどの一般的なモダナイゼーションタスク向けに設計された AWS マネージド変換 (AWS-Managed Transformation) の活用に焦点を当てています。 AWS マネージド変換 (AWS-Managed Transformation) は、追加のセットアップなしですぐに使用できる、一般的なユースケース向けの事前構築された AWS 検証済みの変換です。これらの変換は、最小限の設定で即座に価値を提供し、標準的なアップグレードシナリオに最適です。 AWS Transform custom CLI 機能の理解 AWS Transform custom は、インタラクティブと自動化の両方の変換ワークフローを可能にする包括的なコマンドラインインターフェイスを提供します。 atx --version # ATX のバージョンを表示 atx --help # 一般的なヘルプを表示 atx custom def list # 変換パッケージの一覧 atx # インタラクティブな会話の開始 利用可能なすべてのコマンドの詳細については、 AWS Transform custom コマンドリファレンス を参照してください。 図 1: AWS Transform custom インタラクティブモード 利用可能な変換の検出 atx custom def list を使用して、AWS マネージド変換 (AWS-Managed Transformation) と組織によって作成されたカスタム定義（ユーザー定義）変換を含む、利用可能なすべての変換を表示します。主要な AWS マネージド変換 (AWS-Managed Transformation) には、Java/Python/Node.js バージョンアップグレードと AWS SDK 移行が含まれます。 図 2: AWS Transform custom は利用可能な AWS マネージド変換 (AWS-Managed Transformation) とカスタム定義（ユーザー定義）変換をリスト表示 AWS マネージド変換 (AWS-Managed Transformation) の適用 変換を適用する前に、プロジェクトが Git で初期化されており、すべてのビルドとテストケースが Java 8 で正しく動作していることを確認してください（必要に応じて、適切なビルドコマンドオプションとエージェントへの指示を使用してテストケースをスキップできます）。Gradle プロジェクトの場合、 ./gradlew build が正常に実行されることを確認してください。 変換プロセスは構造化されたアプローチに従います。 クリーンな Git 状態の確保: git status git add . git commit -m "Baseline before Java 21 transformation" 変換の適用: インタラクティブモードまたはダイレクトコマンドモードのいずれかを使用して変換を適用できます。このブログでは、プロセスをステップバイステップで説明するためにインタラクティブモードを使用します。 インタラクティブモード（このブログで使用）: まず、変換設定を含む config.json ファイルを作成します。 { "codeRepositoryPath": "/path/to/your/aws-appconfig-java-sample-gradle", "transformationName": "AWS/java-version-upgrade", "buildCommand": "./gradlew clean build", "validationCommands": "build and validate using \"./gradlew clean build\" after transformation to test with java 21", "additionalPlanContext": "This is a Java 8 to 21 transformation of a gradle app , also include all dependency migration as well. Use java path /path/to/your/java-8/bin/java and /path/to/your/java-21/bin/java when building before and after transformation. We are using gradle wrapper gradlew, update it if needed for java 21 upgrade. Check for deprecated methods and dependencies and update them." } config.json の codeRepositoryPath をローカルプロジェクトディレクトリを指すように更新し、 additionalPlanContext の Java パスを Java 8 と 21 のインストールに合わせて更新します。設定ファイルとそのパラメータの詳細については、 設定ファイルの使用 を参照してください。 次に、インタラクティブモードで変換を実行します（このブログのウォークスルーで使用）。 For Java version upgrade with Gradle using config.json (Interactive Mode): atx custom def exec -t --configuration file://config.json 図 3: AWS Transform custom は config.json から提供された変換設定を使用してインタラクティブモードで gradle 変換を実行 ダイレクトコマンドモード（代替アプローチ）: 自動化された CI/CD パイプラインや、インタラクティブなプロンプトなしで変換を実行したい場合は、このモードを使用します。 atx custom def exec -x -t --configuration "file://config.json" パラメータの説明: – --configuration : インタラクティブモード用の設定ファイルを指定 – -x : インタラクティブなプロンプトなしで変換を自動的に実行（ダイレクトモード） – -t : 実行中の検証のためのテストモードを有効化（ダイレクトモード） --configuration : file:// プレフィックス付きの設定ファイルパスを指定（ダイレクトモード） ATX 実行コマンド ATX CLI を使用した Gradle プロジェクト用の AWS マネージド Java バージョンアップグレード変換の実行 変換計画のレビュー: AWS Transform custom は、 config.json で提供された設定に基づいてプロジェクトを分析し、包括的な変換計画を生成します。この計画には、以下を含むすべての提案された変更が詳細に記載されています。 Java バージョンの更新 : Java 8 から Java 21 設定への移行 API 移行パターン : 非推奨 API と最新の代替手段の自動更新 フレームワークのモダナイゼーション : Spring Boot バージョンアップグレードと互換性の更新 依存関係の変更 : Java 21 と互換性のある更新されたライブラリバージョン ビルドシステムの更新 : Java 21 互換性のための Gradle 設定とプラグインの変更 コードパターンの改善 : 最新の Java 機能とベストプラクティスの実装 変換計画が予想されるすべての更新を網羅していることを確認するために、徹底的なレビューを行うことをお勧めします。 config.json の additionalPlanContext は、依存関係の移行と Gradle ラッパーの更新を含めるように変換をガイドするのに役立ちます。調整が必要な場合は、CLI インターフェイスを通じてフィードバックを提供してください。 さらに、プロジェクトに含まれる追加のレガシー依存関係のアップグレードなど、追加の変更をターゲットにするために変換をカスタマイズしたい場合は、変換計画をレビューする際にフィードバックとして提供できます。AWS Transform custom は、続行する前に変換計画を改善するために提供されたすべてのフィードバックを組み込みます。 変換の適用: 変換計画が要件を満たしていることを確認したら、 proceed と入力して Enter キーを押します。AWS Transform custom は、承認された計画に従って変換を実行します。 変換プロセスは自動的に: – 新しいブランチを作成し、変換された変更をそこにコミット – Java 21 用の Gradle 設定を更新 – Java EE から Jakarta EE パッケージへの移行（該当する場合） – Java 21 互換性のためのフレームワーク依存関係を更新 – 必要なすべてのコード変更を適用 – Java 21 互換性のためのテストケースとテストフレームワークを更新 – 包括的な検証ビルドを実行 AWS マネージド変換 (AWS-Managed Transformation) の結果 Java バージョンアップグレード変換を適用した後、以下の変更が観察されます。 設定の更新: – Java バージョン: 8 → 21 – Spring Boot バージョンアップグレード – Gradle プラグインと設定の更新 – 依存関係バージョンのモダナイゼーション 変更を検証するには、Java 21 に切り替えて ./gradlew build を実行し、変換が成功したことを確認してから、アプリケーション機能をテストします。 図 4: 更新された Gradle 設定 – 更新された Java 21 設定とモダナイズされた依存関係を示す Gradle build.gradle 図 5: raw 型の使用というレガシーパターンがジェネリクスに変換された更新されたコード 図 6: raw 型の使用というレガシーパターンがジェネリクスに変換された更新されたコードの 2 番目の例 図 7: javax.security から java.security への依存関係の更新と CertificateFactory を使用した X509Certificate の取得 図 8: junit 4 から junit5 への更新されたテストケース AWS マネージド変換 (AWS-Managed Transformation) を超えて: カスタム定義変換 AWS マネージド変換 (AWS-Managed Transformation) は標準的な Java モダナイゼーションシナリオに対して優れたカバレッジを提供しますが、利用可能な AWS マネージド変換 (AWS-Managed Transformation) が特定の変換要件に対応していない場合があります。このような状況では、AWS Transform custom により、ユーザーは独自の組織固有のカスタム定義変換を作成およびテストできます。 カスタム定義変換を作成するタイミング カスタム定義変換は、独自のフレームワーク、組織固有のコーディング標準、複雑な複数ステップの移行シナリオなど、AWS マネージド変換 (AWS-Managed Transformation) が特定のニーズをカバーしていない場合に必要になります。 カスタム定義変換の作成 AWS Transform custom により、チームは変換ルールと設定ファイルを使用してカスタム変換を開発できます。これにより、組織は要件に固有の変換ロジックを定義し、サンプルコードでテストし、検証済みの変換をチーム間で共有できます。 AWS Transform custom のインタラクティブモード（ atx ）は、カスタム定義変換の作成に特に有益であり、会話型のインタラクションを可能にして要件を反復的に改善し、リアルタイムのフィードバックを得ることができます。カスタム定義変換は、AWS マネージド変換 (AWS-Managed Transformation) が特定のモダナイゼーションニーズを満たさない場合に、AWS Transform custom の機能を拡張する柔軟性を提供します。 継続的学習とナレッジアイテム AWS Transform custom は、各変換実行から自動的に学習して将来の結果を改善します。特に Java アップグレードについては、サービスは成功したリファクタリング戦略、一般的な依存関係の競合、Java バージョン間のフレームワーク互換性マトリックスなどのパターンをキャプチャします。この知識は将来の変換にフィードバックされ、成功したアップグレードパスの予測がより正確になり、手動介入が減少します。 ナレッジアイテム はアカウント固有であり、AWS アカウントの境界内に留まります。ユーザーは継続的学習を有効または無効にでき、この設定を完全に制御できます。 まとめ このブログでは、AWS マネージド変換 (AWS-Managed Transformation) を使用して AWS Transform custom が効率的な Java アプリケーションモダナイゼーションを可能にする方法を実演しました。Java 8 と Spring Boot 2.x で実行されているレガシー Movie Service アプリケーションから始めて、最新の依存関係とパターンを備えた Java 21 への変換に成功しました。 ステップバイステップのプロセスでは、ベースラインの確立、 atx custom def list を使用した利用可能な変換の検出、AWS Transform custom の CLI を通じた変換の適用方法を示しました。その結果、更新された Java バージョン、Spring Boot アップグレード、拡張された switch 式やローカル変数型推論などの最新の Java 機能を備えた完全にモダナイズされたアプリケーションが得られました。これらすべてが、数週間の手動リファクタリングではなく数分で達成されました。 Java モダナイゼーションを超えて Java モダナイゼーションを超えて、AWS Transform custom の変換機能は他のプログラミング言語とフレームワークに拡張され、多様なテクノロジースタック全体にわたる包括的なアプリケーションポートフォリオモダナイゼーションのための汎用的なソリューションとなっています。エージェントは、以下を含む多様な変換ユースケースをサポートします。 Java、Python、Node.js のバージョンアップグレード ランタイムと API の移行（AWS SDK v1→v2、Boto2→Boto3） フレームワークの移行とアップグレード 言語の翻訳とアーキテクチャの変更 組織固有のカスタム定義変換 AWS Transform customは「定義は一度、変換はどこでも (define once, transform everywhere) 」というアプローチにより、組織全体で変換処理を一度定義し、反復可能なタスクを実行することで、変換知識の蓄積と拡大を実現します。これにより知識のサイロ化が解消され、チームやプロジェクトの範囲に関わらず一貫した品質が保証されます。 今すぐ始めましょう AWS Transform custom で Java アプリケーションをモダナイズする準備はできましたか？開始方法は次のとおりです。 インストールスクリプトを使用して AWS Transform custom CLI (atx) のインストール し、環境を確認 transform-custom:* 権限で AWS 認証情報の設定 atx custom def list を使用して、 利用可能な AWS マネージド変換 (AWS-Managed Transformation) を探索 ダイレクト実行モード（ atx custom def exec ）またはインタラクティブモード（ atx ）を使用して Java アプリケーションに 変換の適用 Gradle プロジェクトの場合は ./gradlew build を使用した包括的なテストを通じて 結果の検証 アプリケーションポートフォリオ全体への拡張し、 一貫したモダナイゼーションを実現 追加リソース 詳細なセットアップ手順とドキュメントについては、以下をご覧ください: AWS Transform custom 入門ガイド AWS Transform custom 製品ページ AWS Transform custom ドキュメント AWS Transform custom コマンドリファレンス 今すぐモダナイゼーションの旅を始めて、大規模な AI 駆動コード変換の力を体験してください。 著者について Venugopalan Vasudevan Venugopalan Vasudevan (Venu) は AWS のシニアスペシャリストソリューションアーキテクトであり、Amazon Q Developer、Kiro、AWS Transform に焦点を当てた生成 AI イニシアチブをリードしています。彼は、顧客が AI を活用した開発者向けソリューションやモダナイゼーションソリューションを採用・拡張し、イノベーションとビジネス成果を加速できるよう支援しています。 Dinesh Balaaji Prabakaran Dinesh は AWS のエンタープライズサポートリードであり、独立系ソフトウェアベンダー（ISV）のクラウドジャーニーをサポートすることを専門としています。AWS 生成 AI サービスの専門知識を持ち、顧客が Amazon Q Developer、Kiro、AWS Transform を活用して、AI を活用した支援によりアプリケーション開発とモダナイゼーションを加速できるよう支援しています。 Sureshkumar Natarajan Sureshkumar Natarajan は AWS のシニアテクニカルアカウントマネージャーであり、生成 AI イニシアチブに焦点を当てて、エンタープライズ顧客のクラウドジャーニーをサポートしています。彼は、組織が Amazon Q Developer、Kiro、AWS Transform を活用して新しい機能を引き出し、開発ワークフローを効率化し、変革的なビジネス成果を達成できるよう導いています。 Anjan Dave Anjan Dave は AWS のプリンシパルソリューションアーキテクトであり、25 年以上の IT 経験を持っています。彼は、生成 AI アプリケーションのモダナイゼーション、インフラストラクチャのスケーラビリティ、開発者の生産性向上イニシアチブを専門としています。 Anjan は、グローバルプロジェクト全体で生成 AI とモダナイゼーション戦略をリードし、イベント駆動型アーキテクチャとマイクロサービスアーキテクチャを通じて HCM プロバイダーのテクノロジーロードマップに影響を与えています。彼は、ソフトウェア開発ライフサイクルに生成 AI を統合して日常的なタスクを自動化し、エンジニアリングチームが高付加価値のアーキテクチャ作業に集中できるようにすることを提唱しています。 翻訳は Solutions Architect の吉村が担当いたしました。

本記事は 2025 年 11 月 21 日 に公開された「 AI-assisted game production: From static concept to interactive prototype 」を翻訳したものです。 ゲーム開発は、プレイ可能になるずっと前から始まります。チームはコンセプトのブレインストーミングに数週間、デザイン作成に数か月、そしてインタラクティブなデモが完成するまでメカニクスの実装とテストに無数の時間を費やします。課題はタイムラインの制約だけではありません。重要な検証と改善は従来、開発サイクルの後半で行われるため、変更にコストがかかり、創造的な方向転換が困難になります。 AI は、ゲームのコンセプト化をプロセスの早い段階でインタラクティブにすることで、初期段階の開発を変革します。 AI でチームは次のことができます。 創造的な方向性を迅速に探索し検証する アーティスティックなビジョンに合ったプレースホルダーアセットを生成する プレイ可能なプロトタイプでゲームプレイメカニクスをテストする 完全な実装を待たず、即座のフィードバックでコンセプトを改善する 開発サイクルの早い段階に洗練度とインタラクティブ性が移行し、大規模なエンジニアリングリソースを投入する前に、より適切な情報に基づいた創造的な意思決定ができます。 Amazon Web Services (AWS) re:Invent 2025 では、 Agentic Arcade を紹介します。参加者が AI で数分で完全にプレイ可能なゲームプロトタイプを作成できるインタラクティブなデモ体験です。参加者は、カスタムアート、メカニクス、プロフェッショナルなストアフロントプレゼンテーションを備えた、すぐにプレイできる完全に機能するブラウザベースのゲームを組み立てます。 本記事では、Agentic Arcade の背後にある技術アーキテクチャを探り、これらのパターンを独自のゲーム開発ワークフローに適用して加速する方法を示します。 図 1: Agentic Arcade ブース デモ体験 Agentic Arcade は、プロのゲームスタジオワークフローを反映した 4 つのステーションで構成されています。参加者は各ステーションを順に進み、4 つの専門 AI エージェントと協力します。 クリエイティブディレクション: Director Agent と協力して、ゲームのジャンル、テーマ、目的を定義し、全体的なクリエイティブコンセプトを決定します。 テクニカルアート: Artist Agent と協力して、ゲームのパッケージデザインを生成し、スタイルに一貫性があり視覚的にまとまったキャラクターアセット、カラーパレット、サウンドエフェクトを選択します。 ゲームプレイ開発: Developer Agent と協力してゲームプレイ機能を実装し、コアゲームメカニクス、特殊能力、プレイヤー難易度を決定します。 ゲームプレイテスト: 仮想ストアフロントに最終ゲームをデプロイし、 Playtester Agent と一緒にゲームを体験します。エージェントはゲームを分析してフィードバックを提供します。 AI が初期コンセプトから数分でプレイ可能なプロトタイプまで、完全なゲーム開発パイプラインを通じて開発者をガイドする方法を示します。連携して動作する包括的な AWS AI サービス群によって実現されています。 Amazon Bedrock は基盤モデルへのアクセスを提供し、 Anthropic の Claude がゲームコンセプト生成とゲームレビューの推論を支え、 Stability AI の Stable Diffusion と Amazon Nova が高品質なビジュアルアセット作成を可能にし、 Amazon Titan がセマンティックアセット検索を推進します。 Amazon Bedrock AgentCore は、開発パイプライン全体で専門 AI エージェントが協力するマルチエージェントシステムを調整し、各エージェントが異なるゲームスタジオの役割を表します。 Strands Agents は、すべてのエージェントインタラクション全体で型安全な構造化出力を実現し、一貫したデータ形式とパイプラインの異なるステージ間の信頼性の高い統合を可能にします。 Kiro は、エージェンティック AI 統合開発環境 (IDE) で、目的、プレイヤー能力、敵の行動、スコアリングシステムを定義する包括的なゲーム仕様を生成します。 Amazon S3 Vectors は、Amazon Simple Storage Service ( Amazon S3 ) の機能で、ベクトル埋め込み表現でセマンティックアセット検索を可能にします。キーワードタグに依存せず、視覚的特性をマッチングします。 Amazon Bedrock Guardrails は、すべての AI 生成出力にわたってコンテンツ安全ポリシーを適用し、体験全体で適切なコンテンツを検証します。 マルチエージェントオーケストレーション、プログラマティックアセット生成、セマンティック検索、最新のゲームアーキテクチャパターンを組み合わせることで、開発者はより速く創造的な方向性を探索でき、ゲームをユニークにするものに集中できます。 アーキテクチャ概要 図 2: アーキテクチャ概要 完全なサーバーレスアーキテクチャで実現されており、複数のレイヤーを包含しています。 フロントエンドレイヤー: Amazon S3 でホストされ、 Amazon CloudFront で配信される React アプリケーション API レイヤー: HTTP および WebSocket API 用の Amazon API Gateway 、接続管理用の AWS Lambda 、認証用の Amazon Cognito コンピューティングレイヤー: Amazon ECS 用 AWS Fargate 上の FastAPI バックエンド、GPU サポート付きコンテナ化タスクとしての ComfyUI ワークフロー、処理キューを管理する Amazon Simple Queue Service ( Amazon SQS ) データレイヤー: セッション状態とタスクキュー用の Amazon DynamoDB 、アセットストレージ用の Amazon S3、セマンティック検索用の S3 Vectors、モデルストレージ用の Amazon Elastic File System ( Amazon EFS ) AI サービス: Amazon Bedrock (Amazon Nova Models、Claude、Stable Diffusion、Amazon Titan)、Kiro、Amazon Bedrock Guardrails、Strands Agents を使用した Amazon Bedrock AgentCore、オープンソースモデル ( FLUX.1 ) アーキテクチャの高レベルなデータフローは次のとおりです。 ユーザーインタラクションは CloudFront で React フロントエンドに流れます。 API Gateway がリクエストを Lambda または ECS コンテナにルーティングします。 マルチエージェントワークフローは Amazon Bedrock AgentCore で調整されます。 アセットは、Amazon ECS 上でヘッドレスで実行される ComfyUI で非同期で生成されます。 ライブデモ中は、ベクトル検索により Amazon S3 から類似のアセットを取得します。。 ゲーム構成は DynamoDB に保存されます。 WebSocket 接続がデータの更新をリアルタイムにストリーミングします。 最終ゲームは Excalibur.js でブラウザ内でレンダリングされます。 サーバーレスアーキテクチャは、コスト効率を維持しながら自動スケーリングを可能にし、アセット生成とランタイム選択の明確な分離により一貫したパフォーマンスを促進します。 次に、アーキテクチャの実装を詳しく見ていき、AI がゲーム開発ライフサイクルの複雑なワークフローをどのように強化できるかを示します。 Amazon Bedrock AgentCore によるマルチエージェントオーケストレーション Agentic Arcade の中核は、専門 AI エージェントがゲーム作成のさまざまな側面を処理するために調整する洗練されたマルチエージェントシステムです。AI が人間の創造的ワークフローをどのように反映できるかを示し、各エージェントが開発プロセスにドメイン専門知識をもたらします。 エージェントの専門化 各ステーションには、明確な責任を持つ専門エージェントがあります。 Director Agent はゲームコンセプト開発に焦点を当て、さまざまな AI モデルを使用して創造的な探索とゲーム定義を支援します。 Artist Agent はビジュアルアセット選択を調整し、ゲームのパッケージデザイン生成を担当し、ベクトル埋め込み表現を使用してキャラクターアセット群を取得します。 Developer Agent はゲームメカニクス構成を処理し、適切なメカニクスを選択して構成ファイルを生成します。 Playtester Agent は完成したゲームを評価し、ゲームプレイ機能を分析して次のステップに関するレコメンデーションを提供します。 スーパーバイザー・ワーカーパターン 舞台裏では、スーパーバイザー・ワーカーアーキテクチャがこれらのエージェントを調整します。スーパーバイザーエージェントがワーカーエージェントにタスクをディスパッチし、ワーカーエージェントは専門機能を実行して報告します。評価エージェントは、アセットが本番パイプラインに入る前に、品質基準に対して出力を検証します。 タスクキュー管理用の Amazon DynamoDB、タスクディスパッチ用の AWS Lambda で実装されています。Amazon Bedrock は、Amazon Bedrock AgentCore と Strands Agents によってエージェント的に駆動される AI モデル呼び出しを提供します。エージェントは各セッション内で短期記憶を維持し、呼び出し間でコンテキストを渡すことで、4 つのステーションすべてにわたって一貫した意思決定を実現します。 Strands Agents は構造化出力機能を提供し、型安全な応答を可能にし、エージェントインタラクション全体で一貫したデータ形式を保持します。オーケストレーション用の Amazon Bedrock AgentCore と構造化出力用の Strands Agents の組み合わせにより、複雑なマルチエージェントワークフローの堅牢な基盤が作成されます。 ComfyUI によるプログラマティックアセット生成 従来の画像生成ツールは、シンプルなテキストから画像へのプロンプトに依存しています。Agentic Arcade は ComfyUI で、複雑で再現可能なワークフローをコードとして構築します。必要なゲームジャンル、テーマ、必要なスタイルに基づいたエージェント的なプロンプト作成で、大規模で一貫したアセット生成が可能になります。ゲーム開発における基本的な課題を解決します。特定のコンセプトに一致し、潜在的に数千のアセット全体で品質と一貫性を維持するスプライトとビジュアルアセットを作成することです。 コードとしての ComfyUI ワークフロー ComfyUI は、画像生成用のノードベースのビジュアルプログラミングインターフェイスを提供します。Agentic Arcade はこれをプログラマティックに使用し、各ワークフローはモデル選択、生成パラメータ、後処理パイプライン、出力仕様を指定する JSON 構成として定義されます。ワークフローは、GPU サポート付きの Amazon ECS 上でコンテナ化タスクとして実行されます。モデルは高速タスク起動のために Amazon EFS ボリュームに保存されます。Amazon SQS が処理キューを管理します。 自律的なアセットパイプライン エージェントによって駆動されるパイプラインは、人間が提供するコンセプトに基づいて、洗練されたアセットを自動的に生成、評価、作成します。キャラクタースプライト生成は、ゲームアセット用に最適化された専門モデルをロードし、ユーザーのテーマとジャンル選択を組み込んだプロンプトを適用し、ゲームプレイ用に最適化された出力を作成するワークフローを使用します。 アセットは、レイテンシーを回避するためにゲームの実行前に非同期で生成されます。ComfyUI ワークフローは包括的なアセットライブラリを生成し、セマンティック検索用の埋め込み表現とベクトルが作成され、アセットがデモ体験にロードされます。ライブデモ中は、特定のコンポーネントが Amazon Bedrock でリアルタイムで生成され (ゲームコンセプトとタイトルを含む)、画像生成モデルでボックスアートが生成され、アセットをマッチングするためのベクトル埋め込み表現による検索が行われます。キャラクタースプライト、環境アセット、サウンドエフェクトは、セマンティック検索でアセットライブラリからインテリジェントに選択されます。 エージェンティックな品質管理 生成されたすべてのアセットは、アセットライブラリに入る前にエージェンティックな評価パイプラインを通過します。評価エージェントは Amazon Bedrock で Amazon Nova Lite のマルチモーダル機能にアクセスし、認識可能性、ジャンルの適切性、視覚的一貫性、コンテンツ安全性を含む品質基準に対して画像を評価します。アセットが品質しきい値を満たさない場合、システムは自動的に生成プロンプトを改善して再生成します。 プログラマティックアプローチは、アセット生成をアドホックな創造的プロセスから、バージョン管理、テスト、継続的改善が可能な信頼性の高いスケーラブルなパイプラインに変換します。 ベクトル埋め込み表現によるインテリジェントなアセット検索 数千のオプションから視覚的にまとまったアセットを見つけるには、キーワードマッチングではなく、セマンティックな理解が必要です。作成されるゲームに適したアセットを取得し、ユーザーの好みをコンテンツにインテリジェントにマッチングすることでアセット生成システムを拡張します。 セマンティック検索 ジャンル、テーマ、目的、選択されたアートワーク全体でのユーザーの選択に基づいて、システムは S3 Vectors が有効になっている Amazon S3 に保存されたアセットをクエリします。セマンティック検索を活用することで、類似した視覚的特性を持つキャラクタースプライトと環境アセットを取得できます。システムは Amazon Titan Multimodal Embeddings モデルで埋め込み表現 (Embeddings) を生成し、視覚的特性を高次元ベクトルとしてキャプチャし、ゲームジャンルでフィルタリングします。 インテリジェントなアセットマッチング 埋め込み表現ベースのアプローチにより、システムは各ゲームコンセプト内で一貫性を維持しながら、多様な創造的方向性をサポートできます。厳選されたライブラリから適切なアセットにユーザーの好みをインテリジェントにマッチングすることで、システムは応答性が高く適切に感じられる、コンテキストに関連したレコメンデーションを提供します。ベクトル類似性検索は数秒で結果を返し、リアルタイムのアセットレコメンデーションを可能にします。 Kiro によるエージェント駆動型ゲーム開発 最終的にプレイ可能なゲームは、さまざまなジャンルにわたってモジュール式で再利用可能なゲームロジックを可能にする最新のゲームアーキテクチャパターンを使用します。同じ基盤コードが、コンポーネントとシステムのさまざまな組み合わせを構成することで、縦スクロールシューティング、プラットフォーマー、その他のゲームタイプをサポートできます。 Entity Component System アーキテクチャ 各セッションでゲームをゼロから構築するのではなく、Agentic Arcade は Entity Component System ソフトウェアパターンを使用します。ゲームオブジェクト (エンティティ) をその動作 (コンポーネント) とロジック (システム) から分離します。エンティティは、プレイヤーキャラクターや敵などのゲームオブジェクトです。コンポーネントは、位置、速度、ヘルスなどのプロパティを定義します。システムには、特定のコンポーネントの組み合わせを持つエンティティに対して動作するロジックが含まれます。 このアーキテクチャにより、ゲーム生成は非常に柔軟でモジュール式になります。開発者がメカニクスと機能を選択すると、システムは適切なコンポーネントとシステムを構成します。同じ Entity Component System 基盤が、コンポーネント構成とシステムロジックを交換することで、さまざまなジャンルをサポートします。 スペック駆動の構成定義 Kiro は、デモ体験自体の多くを作成するために使用されました。Kiro は、ゲームの目的、プレイヤー能力、敵の行動、スコアリングシステム、難易度の進行を定義する構造化された仕様を生成します。 生成された各ゲームは、アセット参照、ゲームメカニクスパラメータ、タイトル情報を含む構成ファイル (JSON と Markdown) によって定義されます。構成がゲームエンジンを駆動し、コードコンパイルなしで動的レンダリングを可能にします。ブラウザベースのアーキテクチャは Excalibur.js を使用します。つまり、ゲームは即座にロードされ、最新の Web ブラウザを備えた任意のデバイスで実行されます。 リアルタイム AI ストリーミング マルチエージェントシステムは、複数のタスクを同時に処理します。体験をスムーズでインタラクティブに保つために、進行状況の更新を発生時にストリーミングし、AI エージェントが複雑な決定をどのように推論するかを透明性を持って提供します。 WebSocket 実装 参加者は、AI エージェントの推論をリアルタイムで表示する視覚化を見ることができ、エージェントが選択をどのように分析し、一貫性を評価し、レコメンデーションを作成するかを示します。透明性は、開発者が独自のワークフローで AI システムを効果的にプロンプトしガイドする方法を理解するのに役立ちます。 Amazon API Gateway WebSocket API がフロントエンドとバックエンド間の通信を処理します。AWS Lambda が接続ライフサイクルを管理し、Amazon DynamoDB がセッション状態を保存し、バックエンドが AI モデルからの更新をリアルタイムでストリーミングします。 Amazon Bedrock Guardrails によるコンテンツ安全性 AI モデルは、時に機密性の高い、または不適切なコンテンツを生成することがあります。Agentic Arcade のすべてのプロンプトとモデル応答は、ユーザーに表示される前に Amazon Bedrock Guardrails を通じてルーティングされます。 多層安全戦略 ユーザーの選択は、自由形式のテキストではなく事前定義されたオプションに制限されており、リスクエクスポージャーを大幅に削減します。評価エージェントは、アセットがライブラリに入る前に品質と適切性を評価します。生成された各画像は、コンテンツ安全性を含む複数の基準に対して分析されます。システムは、複雑なフィードバックループではなくコンテンツモデレーションアプローチを使用し、ランタイム中の信頼性を確保します。 システムは、特定のコンポーネントのリアルタイム AI 生成と、アセットライブラリからインテリジェントに選択されたコンテンツのバランスを取ります。同期および非同期コンテンツガードレールの組み合わせ実装により、制御と応答性のバランスを取る、まとまったエンドユーザー体験が作成されます。 スタートガイド Agentic Arcade で使用されているすべての技術は、すぐに利用可能です。Amazon Bedrock AgentCore でマルチエージェントワークフローを試し、Amazon ECS にデプロイされた ComfyUI ワークフローでプログラマティックアセット生成を実験できます。Amazon S3 Vectors と Amazon Titan Embedding でベクトル類似性検索を今すぐ開始し、Entity Component System パターンを使用したモジュール式ゲームアーキテクチャで Amazon API Gateway WebSocket API を使用したリアルタイム AI ストリーミングを実装し、AWS Cloud Development Kit ( AWS CDK ) で完全なサーバーレスデプロイを完了できます。 新しいゲームコンセプトのプロトタイピング、プレースホルダーアセットの生成、ゲームプレイメカニクスの探索など、これらのパターンは、より速く反復し、ゲームをユニークにするものに集中するのに役立ちます。 Agentic Arcade デモに基づくサンプルゲーム仕様が、 GitHub リポジトリ で利用可能になりました。Kiro で、「3 つの敵タイプとシールドパワーアップを備えた縦スクロールシューティングを作成」のような簡単なプロンプトから、プレイ可能な縦スクロールシューティングゲームを生成できます。包括的な仕様が Kiro をゲームメカニクスと実装を通じてガイドし、数分でコンセプトをインタラクティブなプロトタイプに変換できます。 まとめ Agentic Arcade は、AI がゲーム開発をどのようにサポートできるかの根本的な変化を示しています。創造的な決定を置き換えるのではなく、コンセプト化をインタラクティブにし、検証を即座に行えるようにします。プロダクション前フェーズに洗練度とインタラクティブ性をもたらすことで、チームは大規模なエンジニアリングリソースを投入する前に、より適切な情報に基づいた創造的な決定を下せます。 紹介されたパターン (マルチエージェントオーケストレーション、プログラマティックアセット生成、セマンティック検索、モジュール式ゲームアーキテクチャ) は、実用的なアプローチを表しています。静的なアイデアを、開発サイクルの早い段階で探索、改善、検証できるインタラクティブなプロトタイプに変換できます。 ビジネスの加速を支援する方法については、 AWS 担当者 にお問い合わせください。 参考資料 AWS for Games The 2025 AWS Guide to Generative AI for Game Developers Generative AI-powered game design: Accelerating early development with Stability AI models on Amazon Bedrock 著者について Armando Vargas AWS のゲームバックエンドと AI 駆動型ソリューションに焦点を当てた Senior Specialist Solutions Architect です。ゲームとメディアのお客様が最新のゲームプレイサービスをアーキテクトおよびスケールし、開発と本番パイプラインに AI を導入してより良いプレイヤー体験を提供できるよう支援しています。 Stanford Lee Technical Account Manager であり、Amazon Web Services の Spatial Computing Technical Field Community の一員です。大企業のシニアテクノロジーリーダーシップに技術ガイダンスを提供しています。この役割で、お客様とのエンゲージメントをリードし、技術プロトタイプを構築し、イマーシブ 3D コンピューティングおよび拡張現実、仮想現実、拡張現実 (AR/VR/XR) 技術に関するソートリーダーシップを提供しています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。

本記事は 2026 年 1 月 30 日 に公開された「 GPU-Accelerated Robotic Simulation Training with NVIDIA Isaac Lab in VAMS 」を翻訳したものです。 オープンソースの Visual Asset Management System (VAMS) が、NVIDIA Isaac Lab との統合により、ロボットアセット向けの GPU アクセラレーション強化学習 (RL) に対応しました。このパイプラインでアセット管理ワークフローから直接 RL ポリシーのトレーニングと評価ができ、AWS Batch でスケーラブルな GPU コンピューティングを活用できます。 フィジカル AI とロボティクス開発のための Isaac Lab 図 1: NVIDIA Isaac Lab でトレーニングされた ANYmal シミュレーション 世界は自律経済に向かって進んでいます。この変革モデルは AI、ロボティクス、シミュレーション、エッジコンピューティングを統合し、人の介入を最小限に抑えて動作するシステムを実現します。この変革の中心にあるのがフィジカル AI です。これは物理世界を認識し、理解し、推論し、行動できるシステムを指します。 実世界でロボットをトレーニングするのは遅く、コストがかかり、危険を伴います。四足歩行ロボットが歩行を習得するには何千回も転倒する可能性があります。転倒するたびに数万ドルのハードウェアが損傷するリスクがあります。シミュレーションはこの状況を完全に変えます。 NVIDIA Isaac Lab は GPU アクセラレーション型ロボティクスシミュレーションの最先端技術です。Isaac Sim の高精度物理エンジン上に構築され、ポリシーの複雑さと GPU 仕様に応じて、単一の GPU 上で数千のロボットインスタンスを並列実行できます。実世界で数か月かかるトレーニングが数時間のシミュレーション時間に圧縮されます。1,000 万の環境ステップを必要とするポリシーを、数か月ではなく一晩でトレーニングできます。 その意義は大きいです: 高速な反復サイクル : 新しい報酬関数、ロボット設計、制御戦略を数週間ではなく数時間でテストできます 安全な探索 : ハードウェアを損傷することなく、ロボットが積極的な動作を学習し、失敗から回復できます 再現性 : シミュレーションは決定論的な環境を提供し、アルゴリズムの比較と改善の追跡が可能です スケール : 数百の実験を並列実行し、体系的なハイパーパラメータ探索が可能です しかし、この機能へのアクセスには従来、大きなインフラストラクチャの専門知識が必要でした。チームは GPU インスタンスのプロビジョニング、NVIDIA ドライバーの設定、コンテナイメージの管理、トレーニングインフラストラクチャとアセットリポジトリ間のデータ移動パイプラインの構築、アセット、トレーニング済みポリシー、データ設定のバージョン管理を行うカスタムソリューションの作成が必要でした。この運用オーバーヘッドがプロジェクトを遅らせたり、シミュレーショントレーニングを活用できる人を制限したりすることがよくありました。 Isaac Lab を VAMS に統合 図 2: Isaac Lab VAMS ワークフロー VAMS の Isaac Lab パイプラインアドオンはこのインフラストラクチャ負担を解消します。アセット管理システムと直接統合することで、ロボットモデルからトレーニング済みポリシーまでのシームレスなパスを作成します: アップロード : ロボットの URDF/USD ファイルとカスタム環境を VAMS にアップロードします 設定 : VAMS にアセットとしてアップロードされたシンプルな JSON ファイルでトレーニングパラメータを設定します 起動 : GPU コンピューティングを自動的にプロビジョニングするジョブを起動します 取得 : トレーニング済みポリシーを完全な系統追跡機能を備えたバージョン管理されたアセットとして取得します GPU インスタンス管理は不要です。コンテナオーケストレーションも不要です。手動のデータ転送も不要です。パイプラインがプロビジョニング、実行、クリーンアップを自動的に処理します。 この統合は、シミュレーショントレーニングが必要だが専任の MLOps リソースがないチームにとって特に価値があります。ロボティクスエンジニアはインフラストラクチャと格闘するのではなく、より優れたロボットと報酬関数の設計に集中できます。一方、組織は VAMS のアセット追跡機能を通じてトレーニング実験を一元的に把握できます。 課題: アセット管理とシミュレーションの橋渡し ロボットアセットを管理する組織は共通の課題に直面しています。3D モデル、USD ファイル、シミュレーション環境は 1 つのシステムにあり、トレーニングインフラストラクチャは別のシステムに存在します。データサイエンティストはシステム間でアセットを移動し、コンピューティングリソースを設定し、どのアセットでどのポリシーがトレーニングされたかを追跡するのに多くの時間を費やします。 VAMS の Isaac Lab パイプラインは、GPU アクセラレーション型シミュレーショントレーニングをアセット管理ワークフローに直接統合することでこれを解決します。ユーザーは VAMS から離れることなく、ロボットアセットを選択し、トレーニングパラメータを設定し、ジョブを起動できます。 アーキテクチャ概要 パイプラインは複数の AWS サービスを調整してシームレスなトレーニング体験を提供します: 図 3: Isaac Lab パイプラインリファレンスアーキテクチャ ユーザーがトレーニングジョブを送信すると、リクエストは Amazon API Gateway を経由して AWS Lambda 関数に流れ、 AWS Step Functions ワークフローを開始します。このワークフローはジョブ設定を構築し、 AWS Batch に送信し、非同期コールバックパターンで完了を待ちます。トレーニングコンテナは NVIDIA GPU を搭載した GPU インスタンス上で実行され、並列シミュレーションに必要なコンピューティングパワーを提供します。 主要なインフラストラクチャコンポーネント: AWS Batch コンピューティング環境 : GPU インスタンス (g6.2xlarge から g6e.12xlarge) 全体で自動スケーリングするコンテナ化環境 Amazon EFS : マルチノードジョブ全体でトレーニングチェックポイントを共有するストレージ Amazon ECR : Isaac Lab コンテナイメージをホストし、 AWS Cloud Development Kit (CDK) デプロイ時に自動的に構築されます AWS Step Functions : 適切なエラー処理とタイムアウトでワークフローを調整します Container Insights : Amazon Elastic Container Service (Amazon ECS) クラスターで有効化され、モニタリングと可観測性を提供します コンテナ自体は NVIDIA の公式 Isaac Lab イメージ (nvcr.io/nvidia/isaac-lab:2.3.0) 上に構築され、最新のシミュレーション機能との互換性を保証します。 デュアルモード動作: トレーニングと評価 パイプラインは RL 開発ライフサイクルの異なる段階に対応する 2 つの異なるモードをサポートします。 トレーニングモード トレーニングモードはゼロから新しいポリシーを作成します。ユーザーはシミュレーションタスク、並列環境の数、トレーニング反復回数を指定します。パイプラインは残りすべてを処理します。VAMS からカスタム環境をダウンロードし、トレーニングループを実行し、チェックポイントを保存し、トレーニング済みポリシーを VAMS にアップロードします。 典型的なトレーニング設定は次のようになります: { "name": "Ant Training Job", "description": "Train a PPO policy for the Isaac-Ant-Direct-v0 environment", "trainingConfig": { "mode": "train", "task": "Isaac-Ant-Direct-v0", "numEnvs": 4096, "maxIterations": 1000, "rlLibrary": "rsl_rl" }, "computeConfig": { "numNodes": 1 } } numEnvs パラメータは GPU 使用率を制御します。Isaac Lab は単一の GPU 上で数千のシミュレーションインスタンスを並列実行します。四足歩行タスクでは、4096 環境で通常良好な GPU 飽和度を達成します。 トレーニング出力は簡単に識別できるようジョブ UUID の下に整理されます: {uuid}/checkpoints/model_*.pt – 定期的な間隔でのモデルチェックポイント {uuid}/metrics.csv – TensorBoard からエクスポートされたトレーニングメトリクス {uuid}/training-config.json – 入力設定のコピー {uuid}/*.txt – ログファイル 評価モード トレーニング済みポリシーを取得したら、評価モードでパフォーマンスを評価できます。このモードは既存のポリシーをロードし、指定された数のエピソードを実行し、メトリクスを収集してビデオを記録します。 { "name": "Ant Evaluation Job", "description": "Evaluate a trained PPO policy for the Isaac-Ant-Direct-v0 environment", "trainingConfig": { "mode": "evaluate", "task": "Isaac-Ant-Direct-v0", "checkpointPath": "checkpoints/model_1000.pt", "numEnvs": 4, "numEpisodes": 5, "stepsPerEpisode": 900, "rlLibrary": "rsl_rl" }, "computeConfig": { "numNodes": 1 } } 評価では、目標がトレーニングスループットではなく評価であるため、並列環境を少なく (4096 ではなく 4) 使用します。 評価出力には以下が含まれます: {uuid}/videos/*.mp4 – 記録された評価ビデオ {uuid}/metrics.csv – 評価メトリクス {uuid}/evaluation-config.json – 入力設定のコピー Isaac Lab の play スクリプトが適切に終了するには –video フラグが必要なため、評価中は常にビデオが生成されます。 図 4: トレーニング済みポリシーからのビデオ評価出力 チェックポイント検出 パイプラインは評価用のチェックポイントファイルを指定する 3 つの方法をサポートします: 相対パス (推奨) : checkpointPath を使用して同じアセット内のチェックポイントを参照します (例: “checkpoints/model_300.pt”) 完全な S3 URI : policyS3Uri をアセット間または外部チェックポイントに使用します (例: “s3://bucket/path/model.pt”) 自動検出 : 評価設定と同じディレクトリに .pt ファイルを配置します (レガシー、下位互換性のため) VAMS を通じたジョブの実行 VAMS を通じて Isaac Lab トレーニングジョブを実行する前に、 VAMS のインストールと開始手順 に従って、VAMS ソリューションとデータベースをデプロイおよびセットアップしてください。 VAMS の準備ができたら、トレーニングジョブを実行する最も簡単な方法は VAMS Web アプリケーションを使用することです: 1. 実行予定のジョブタイプ (トレーニングまたは評価など) の設定 JSON を作成します。トレーニング設定 JSON の例: 1. { 2. "name": "ANYmal Training Job", 3. "description": "Train a PPO policy for the Isaac-Velocity-Rough-Anymal-D-v0 environment", 4. "trainingConfig": { 5. "mode": "train", 6. "task": " Isaac-Velocity-Rough-Anymal-D-v0", 7. "numEnvs": 2048, 8. "maxIterations": 3000, 9. "rlLibrary": "rsl_rl" 10. }, 11. "computeConfig": { 12. "numNodes": 1 13. } 14. } 2. Web UI を使用してトレーニング設定 JSON ファイルを VAMS にアップロードします: 図 5: Web UI でファイルをドラッグアンドドロップ 3. Workflows に移動し、Isaac Lab Training または Evaluation パイプラインを選択します 図 6: VAMS ワークフロータブ 4. Execute Workflow を選択します 5. Select Workflow ドロップダウンから isaaclab-training ワークフローを選択します 図 7: VAMS ワークフロー選択 6. Select File to Process ドロップダウンからトレーニング設定 JSON アセットを選択します 図 8: VAMS ワークフローファイル選択 7. Execute Workflow ボタンをクリックしてワークフローを送信します 図 9: Isaac Lab トレーニングジョブ用に設定された VAMS ワークフローモーダル VAMS は実行ステータスをリアルタイムで追跡します。完了すると、トレーニング済みポリシーが元のロボットアセットにリンクされた新しいアセットバージョンとして表示され、完全な系統が維持されます。トレーニングジョブの詳細については、管理者は Amazon CloudWatch でトレーニング出力ログを確認できます。 図 10: VAMS ファイルマネージャーのトレーニング済みポリシーアセット カスタム環境の使用 Isaac Lab には 40 以上の事前構築された環境が含まれていますが、多くのプロジェクトではカスタムタスクが必要です。VAMS は簡単なパッケージングワークフローでこれをサポートします。 まず、Isaac Lab のテンプレート構造に従ってカスタム環境を作成します: my_custom_env/ ├── setup.py ├── my_custom_env/ │ ├── __init__.py # Contains gym.register() call │ ├── my_env.py # Environment implementation │ └── my_env_cfg.py # Configuration classes └── agents/ └── rsl_rl_ppo_cfg.py tarball としてパッケージ化し、アセットとして VAMS にアップロードします: tar -czf my_custom_env.tar.gz my_custom_env/ # VAMS Web UI または API 経由でアップロード トレーニングジョブを送信する際、カスタム環境アセットを参照します。パイプラインはトレーニング開始前に自動的にダウンロードしてインストールします: { "trainingConfig": { "task": "MyCustom-Robot-v0", "numEnvs": 4096, "maxIterations": 5000 }, "customEnvironmentPath": "environments/my_custom_env.tar.gz" } パフォーマンスに関する考慮事項 インスタンスの選択 パイプラインは自動選択で複数の GPU インスタンスタイプをサポートします: パイプラインは BEST_FIT_PROGRESSIVE 割り当て戦略を使用し、価格とパフォーマンスのバランスが最適な G6 インスタンス (L4 GPU) を優先し、次に G6E (L40S)、フォールバックとして G5 (A10G) を使用します。 マルチノードトレーニング 最大規模の実験では、パイプラインは PyTorch の分散トレーニング (torchrun) によるマルチノード並列トレーニングをサポートします。コンピューティング設定で numNodes > 1 を設定します: { "computeConfig": { "numNodes": 4 } } パイプラインは AWS Batch のマルチノード並列ジョブ機能を通じてノード通信を自動的に設定します。チェックポイントは Amazon Elastic File System (Amazon EFS) 経由で共有され、すべてのノードが同期された状態を維持します。 Isaac Lab を使用した AWS Batch マルチノードトレーニングの詳細なガイドについては、AWS のこちらの ブログ を参照してください。 パイプラインの有効化 Isaac Lab パイプラインには VAMS で VPC モードを有効にする必要があります。VAMS 設定オプションの詳細については、 設定ガイド を確認してください。/infra/config/config.json にある VAMS 設定ファイルを更新します: { "app": { "useGlobalVpc": { "enabled": true, "addVpcEndpoints": true }, "pipelines": { "useIsaacLabTraining": { "enabled": true, "acceptNvidiaEula": true, "autoRegisterWithVAMS": true, "keepWarmInstance": false } } } } 重要 : NVIDIA ソフトウェアライセンス契約 に同意するには、acceptNvidiaEula: true を設定する必要があります。これを設定しないとデプロイは失敗します。 Isaac Lab パラメータを含むように設定ファイルを更新したら、標準の VAMS 手順 に従って Isaac Lab アドオンを含む VAMS ソリューションをデプロイできます。 デプロイは Isaac Lab コンテナを自動的に構築し、Amazon Elastic Container Registry (Amazon ECR) にプッシュします。最初の Batch ジョブは約 10GB のコンテナイメージをプルするのに 5〜10 分かかる場合があります。その後のジョブはインスタンスキャッシュにより高速に起動します。 コンテナ Pull 時間の最適化 ジョブの起動を高速化するには: ウォームインスタンスの維持 : keepWarmInstance: true を設定してインスタンスを実行状態に保ちます (最小 8 vCPU)。インスタンスをウォーム状態に保つとパイプラインの実行コストが増加します。この設定は指定された数の EC2 vCPU を実行状態に保ちます。 AMI の事前構築 : コンテナイメージを事前キャッシュしたカスタム AMI を作成します 大容量 EBS ボリューム : パイプラインは Docker レイヤーキャッシュを備えた 100GB GP3 EBS ボリュームを使用します 次のステップ Isaac Lab 統合はロボットアセットワークフローに新しい可能性を開きます。GPU アクセラレーション型シミュレーショントレーニングを VAMS に統合することで、チームはアセット、トレーニング実行、デプロイされたポリシー間の完全なトレーサビリティを維持しながら、ロボットの動作をより速く反復できます。Isaac Lab の高精度物理シミュレーションと VAMS のアセット管理機能の組み合わせは、ロボット AI 開発のための強力なプラットフォームを作成します。 始めましょう Isaac Lab パイプラインは VAMS 2.4.0 で利用できます。完全なソースコード、詳細なドキュメント、コスト見積もり、トラブルシューティングガイドは VAMS GitHub リポジトリ で入手できます。 著者について Kellan Cartledge AWS Prototyping and Cloud Engineering チームの Senior Prototyping Architect で、AI/ML、生成 AI、クラウドインフラストラクチャ、リアルタイムグラフィックス、没入型 AR/VR テクノロジー全体にわたる変革的ソリューションの設計と実装において 10 年以上の経験があります。複雑な課題を解決し、新しいテクノロジーで可能性の限界を押し広げるチームを支援することに情熱を注いでいます。 Kurt Scheuringer Amazon Web Services (AWS) の Spatial Computing 担当 Principal Prototyping Architect として、15 年以上の空間テクノロジーの専門知識を活かしています。AWS 入社前は、防衛産業でさまざまな製品ライフサイクルに携わり、ビジネス開発、エンジニアリング設計、製造、保守の経験を積みました。Florida Atlantic University でコンピュータサイエンスの修士号、University of Central Florida でエンジニアリングマネジメントの修士号を取得しています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。

本記事は 2025 年 12 月 2 日 に公開された「 Physical AI: Building the Next Foundation in Autonomous Intelligence 」を翻訳したものです。 はじめに 世界は自律型経済 (Autonomous Economy) に向かって動いています。AI、エッジコンピューティング、ロボティクス、空間インテリジェンス、シミュレーション技術が連携し、人の介入を最小限に抑えてシステムが自律的に動作する経済モデルです。フィジカル AI はこれらの技術の融合であり、コンピュータが物理世界を感知し、理解し、予測し、行動できるようにすることで、自律型経済への移行に大きな機会をもたらします ( https://www.linkedin.com/pulse/path-fully-autonomous-economies-andre-drpde/ )。フィジカル AI は自律運用へのパラダイムシフトを支え、純粋にデジタル環境で動作する従来の AI システムから、物理世界を知覚し、理解し、行動できるインテリジェントシステムへと進化させます。輸送 (自動運転車)、製造 (無人製造施設)、エネルギー (現場の人員を最小化し危険エリアの自動検査を実現)、ヘルスケア (低侵襲ロボット手術) など、あらゆる分野を変革しています。以前の ブログ で、AWS はフィジカル AI で実現できる自律性のレベルを説明する 4 段階のフィジカル AI ケイパビリティ・スペクトラムを提案しました。今回は、これらの自律性レベルを達成する方法のガイダンスを提供します。ヘルスケア向けの Diligent Robotics を取り上げた ブログ で実例を確認できます。 本記事では、自動化への道筋を描くための包括的なフィジカル AI フレームワークを説明します。フィジカル AI を抽象的な概念から、開発して技術開発ロードマップに統合できる実用的で具体的な機能に分解します。今日のユースケースに対応し、明日の課題を解決する準備を整えます。物理世界 (アトム) とデジタル世界 (ビット) をつなぐ継続的な学習ループを説明し、物理運用での自律性の開発を加速します。最後に、仮想世界でのフィジカル AI モデルトレーニングと物理世界でのリアルタイム自律運用の違いを明確にし、クラウドからエッジへのハイブリッドデプロイメントで両者がどのように接続されるかを説明します。本記事は、フィジカル AI フレームワークの各機能を深く掘り下げる複数回のブログシリーズの最初の導入記事です。 フィジカル AI の理解 AWS では、フィジカル AI を物理世界と相互作用するために知覚、理解、推論、学習を統合したハードウェアとソフトウェアのシステムと定義しています。 フィジカル AI は人工知能のサブセットであり、時空間的な関係と世界の物理的性質の理解に焦点を当て、センサーとアクチュエータを通じて周囲の環境と相互作用します。画像、動画、テキスト、音声、深度/LiDAR、実世界のセンサーデータなどのマルチモーダル入力を処理し、洞察を導き出し、複雑で動的な環境で独立して動作できる自律システムでのリアルタイム意思決定を可能にします。たとえば、AI モデルは推論を使ってコーヒーを注ぐ方法を説明できますが、フィジカル AI モデルはまずコーヒーがどこにあり、カップに注ぐ必要があることを推論し、さらに物理世界への追加機能を拡張して、実世界の条件下でコーヒーを識別し、つかみ、持ち上げ、カップに注ぎます。 AWS のフィジカル AI フレームワーク フィジカル AI の可能性を完全に実現するには、自律システムのライフサイクル全体に対応する体系的なアプローチが必要です。図 1 に示す AWS フィジカル AI 概念フレームワークは、デジタルインテリジェンスと物理的アクションの間に継続的な学習サイクルを作り出す 6 つの相互接続された機能を通じて、この包括的な構造を提供します。これは、エンドツーエンドのフィジカル AI 技術スタックでカバーされる 6 つの機能領域にズームインしたもので、この ブログ でも取り上げられています。まず各機能を説明し、次にこれらの機能が仮想世界でのトレーニングループと物理世界での自律ループを構築・接続し、ハイブリッドクラウド-エッジデプロイメントを通じてどのように使用されるかを説明します。このように、フィジカル AI は将来の状態について推論し、複雑なアクションシーケンスを計画し、物理的能力を継続的に改善するシステムへの進化を表しています。 図 1: トレーニングループ、自律ループ、6 つの主要機能を示すフィジカル AI 継続的学習ループの図 1. 物理世界の接続とデジタル化 : フィジカル AI システムの基盤は、実世界の情報を取得してデジタル化する能力にあります。IoT デバイス、センサー、カメラ、その他の物理デバイスが物理環境からマルチモーダル状態データを収集します。LiDAR などの空間センサーは深度と体積データをマッピングし、地理空間データと衛星データは広大な物理エリアをマッピングし、温度、湿度、化学組成などのパラメータを監視するセンサーが使用されます。これらのさまざまなデータは、1D データストリーム、2D 画像、3D ポイントクラウド、センサーデータ、エンタープライズ運用技術 (OT) システムと資産管理システムからのメタデータを通じて、物理世界の包括的なデジタル表現を作成します。この豊富な感覚入力が、後続のすべての AI 処理の基盤となります。AWS では、 Amazon IoT SiteWise 、 Amazon IoT Core 、 Amazon Kinesis Video Streams など、 Industrial Data Fabric および Smart Machine ソリューションガイダンスの一部として使用できるサービスや、3D データ収集用の Matterport、Treedis、Prevu3D などのパートナーソリューションを提供しています。 2. データの保存と構造化 : フィジカル AI システムは二重経路アーキテクチャを採用しています。低レイテンシーのセンサーデータストリームは、ネットワークをバイパスしてエッジ ML モデルに直接送られ、リアルタイムオペレーティングシステム (RTOS) を使用して即座の反応制御を実現します。一方、より高レベルの推論タスクは、クラウド接続されたナレッジグラフとエンタープライズシステム統合 (ERP、CRM、LIMS、PLM) を活用して、複雑な計画と意思決定を可能にします。非構造化された多様なデータタイプを効率的に処理して相関付けできます。フィジカル AI システムで効果的にデータを管理するには、リアルタイム解析を維持しながら、複数のソースからの膨大な量の情報を処理する必要があります。高度なストレージアーキテクチャとデータ処理パイプラインにより、組織はこの複雑さを管理しながら、即座の意思決定と長期的な学習の両方に重要な情報を利用可能に保てます。AWS では、ストレージ用の Amazon S3 、 Amazon DynamoDB 、 Amazon Aurora などのサービスや、複雑な空間、IT、OT データを管理するための Spatial Data Management on AWS ソリューションを提供しています。 3. データのセグメント化と理解 : この段階では、変換、クリーニング、センサーストリームの時間的リサンプリングなどのデータ操作を処理し、動画、LiDAR、時系列データを構造化された 3D モデルと環境表現に変換してシミュレーションワークフローに情報を提供します。前処理と関係マッピングを通じて、生のマルチモーダル物理世界データを AI 対応の洞察に変換します。ナレッジグラフを通じて異なるマルチモーダルデータセット間のオントロジー関係を構築することが重要です。RAG 経由のメンテナンスマニュアルなどのデータを接続し、事前作成された 3D アセットをカタログ化し、空間、運用、時間データディメンション全体でセマンティック接続を確立できます。AWS サービスがこの変換を支えます。 AWS Glue は、マルチモーダルセンサーデータを処理して同期するための組み込みデータ変換パイプラインを備えたサーバーレス ETL 機能を提供し、 Amazon Neptune は、空間関係とアセットメタデータを構造化する高度なナレッジグラフとオントロジーを可能にし、自律システムが物理環境を理解して相互作用するために必要な基礎的なインテリジェンス層を作成します。産業検査レポート自動化のフレームワーク例については、この ブログ をご覧ください。 4. シミュレーション、トレーニング、モデル最適化 : シミュレーション環境は、実世界のリスクなしに自律システムをトレーニングするための安全で制御された空間を提供し、複数のユースケースにわたるフィジカル AI システムの開発をサポートします。これらの環境により、ニアエッジデプロイメントを対象としたモデル開発のための包括的なトレーニングが可能になり、AI システムは、現実でテストするのが非現実的または不可能な稀なケースや危険な状況を含む、無数のシナリオから学習できます。シミュレーション機能にはデジタルツインが含まれ、シミュレーションベースのトレーニングと仮想テスト、モデル開発用の合成データ生成、ML とハイブリッド AI + メカニスティックモデルの両方のトレーニングと調整、エッジデプロイメント用に最適化されたモデルの開発が含まれます。シミュレーション環境により、フィジカル AI モデルの反復的な最適化が可能になり、チームはエッジデプロイメント前に多様なシナリオ全体でパフォーマンスを検証しながら、知覚、意思決定、制御アルゴリズムを改良できます。シミュレーション機能は、基本的なデジタル表現から世界物理モデル (NVIDIA Omniverse、Unity、Unreal Engine、その他新興の WFM) まで、高忠実度エンジニアリングシミュレーション (数値流体力学、有限要素解析、熱力学プロセスモデリング) まで多岐にわたります。AWS で NVIDIA Cosmos world foundation model を実行する 例 をご覧ください。フィジカル AI モデルはデジタルツインで表現できる可能性があります。デジタルツインは複雑なトピックであり、 L1-L4 デジタルツインレベリングガイド と デジタルツインフレームワーク リファレンスアーキテクチャ を開発しました。AWS では、 AWS Batch 、 AWS ParallelCluster 、 AWS Parallel Computing Service 、 Amazon SageMaker 、 Amazon EKS/ECS など、モデルの構築、オーケストレーション、トレーニングのためのさまざまなサービスを提供しています。 5. 自律システムのデプロイと管理 : トレーニングと検証が完了したら、AI モデルとポリシーを堅牢な管理機能を備えた自律システムにデプロイする必要があります。この機能は、無線アップデート、エージェントポリシー管理、継続的なシステムアップデートを処理し、デプロイされたシステムが最新で、コンプライアンスに準拠し、効果的であることを保証します。デプロイフェーズでは、エッジコンピューティング機能、ローカライズされたインフラストラクチャ、ネットワーク接続、セキュリティ要件を慎重に検討する必要があります。システムは、中央管理システムから切断されている場合でも確実に動作し、アップデートを受信してステータス情報を報告する能力を維持する必要があります。 AWS IoT Greengrass は、自律システムへの AI モデルとアプリケーションの安全なデプロイと管理を可能にするコアエッジランタイムとして機能し、無線アップデート、ローカル処理機能、中央管理システムから切断されている場合でも確実に動作する能力をサポートします。 AWS IoT Device Management は、リモートデバイス監視、ポリシー管理、自動無線ファームウェアアップデートを含むフリート全体の運用を提供してこれを補完し、 AWS Systems Manager は、OS パッチ適用やアプリケーションデプロイメントなどのタスクのために、従来の IT インフラストラクチャと並んでエッジデバイスの一元管理を可能にします。さらに、 AWS IoT Core は、自律システムとクラウド間の安全な双方向通信を促進し、リアルタイムステータスレポートとポリシーアップデートを可能にし、 AWS Secrets Manager や IoT Device Defender などのサービスは、デプロイされた自律フリート全体で堅牢なセキュリティとコンプライアンス管理を保証します。 6. エッジ推論と運用 : 最後の機能は、インテリジェンスをエッジにもたらします。エッジベースのコンピューティングにより、低レイテンシーのデータ転送が可能になり、ネットワーク依存なしにアクチュエータとセンサーアレイを駆動するオンデバイスコンピューティングのリアルタイム分析が可能になります。フィジカル AI システムは、自動運転車の衝突回避や産業機器の緊急停止など、ミリ秒単位が重要でネットワーク接続に依存できない重要なアプリケーションに即座の応答を必要とします。エッジデバイスに高度な推論機能をデプロイすることは、モデルパフォーマンスの最適化、超低レイテンシー推論、信頼性の低い接続下での動作において大きな課題を提示し、リソース制約のあるエッジハードウェアで高度なフィジカル AI モデルを実現するための AWS の重要な投資領域となっています。AWS では、 AWS IoT Greengrass などのサービスを提供しており、クラウドから切断されている場合でも超低レイテンシーでローカル AI 推論を可能にし、 AWS Local Zones と AWS Outposts はクラウド機能をリモートロケーションに拡張し、ネットワーク依存を減らすために AI 処理がローカルで行われることを保証します。 フライホイール効果: 運用を通じた継続的な推論改善 フィジカル AI フレームワークが特に強力なのは、データ駆動型の改善ポテンシャルです。自律システムが実世界で動作すると、フィジカル AI モデルの改良に役立つ運用データが生成されます。強化されたモデルはより高性能な自律システムを可能にし、それがさらに追加のトレーニングデータを生成し、運用コストを削減しながら能力向上を推進できるフィードバックループを作り出します。この学習サイクルは、フィジカル AI システムが時間とともにより効果的になる可能性があることを意味しますが、改善の度合いは環境の性質と収集されるデータの品質に依存します。物理世界との各相互作用は、新しいトレーニングデータ、エッジケース、最適化の機会を提供します。フレームワークをうまく実装した組織は、戦略的なモデル管理と人間の監視を組み合わせることで、運用経験を蓄積するにつれて、システムがパフォーマンス、信頼性、効率の向上を示すことが期待できます。 デュアルループアーキテクチャ: クラウドとエッジの統合 フレームワークは、包括的なフィジカル AI 機能を提供するために連携して機能する 2 つの重要なループを通じて動作します。トレーニングループは主にクラウド環境で動作し、データ処理、AI モデルトレーニング、シミュレーション活動を処理します。計算能力、ストレージ容量、グローバルに分散されたネットワークインフラストラクチャを活用して、AI 機能を開発して改良します。自律ループは、リアルタイム運用と物理世界との相互作用に焦点を当て、通常、自律システムがデプロイされているエッジで動作します。速度、反復、信頼性を優先し、クラウドリソースへのネットワーク接続に依存せずに、システムが変化する条件に応答できることを保証します。2 つのループの統合により、組織はクラウドインフラストラクチャの計算上の利点とエッジデプロイメントの応答性要件の両方から恩恵を受けられます。データはクラウド環境とエッジ環境の間をシームレスに流れ、運用の信頼性を維持しながら学習と改善が継続的に行われることを保証します。 自律運用の安全なデプロイ セキュリティは AWS のフィジカル AI フレームワークの基盤を形成し、自律システムはデジタルから物理へのループのすべての段階で揺るぎない信頼と回復力を持って動作する必要があります。組織が物理システム、デジタルインテリジェンス、人間の監視の間の関係を調整する AI エージェントをデプロイする際、AWS はエッジからクラウドまで安全な自律運用を可能にするセキュリティフレームワークを提供します。フィジカル AI フレームワークは本質的に、初期センサーデータキャプチャと空間データ管理から、AI モデルトレーニングと物理ベースのシミュレーション、自律システムデプロイメントとリアルタイムエッジ推論運用まで、ワークフロー全体を通じてエンタープライズ統合とセキュリティコンプライアンスを優先する必要があります。安全/機密性の高い環境で動作したり人と相互作用したりすることが計画される自律システムには、プロプライエタリ/非公開のデータと環境、個人を特定できる情報 (PII) などのセキュリティ考慮事項が必要です。AWS のセキュリティ体制は、マルチモーダルデータフローの保護、フィジカル AI モデルの AI トレーニングパイプラインの保護、デジタルツインの安全な運用の保証、物理システムとデジタルブレイン間の安全な接続ループ (オプションの転送中暗号化と保管時暗号化を含む) によってフィジカル AI に適用されます。セキュリティファーストのアプローチにより、顧客は最高水準のデータ保護、アクセス制御、運用整合性を維持しながら、物理世界を知覚し、理解し、行動できる自律システムを自信を持って開発でき、最終的に企業が最も重要な資産と運用を保護しながらフィジカル AI の変革的な可能性を実現できます。 自律型経済の構築 フィジカル AI フレームワークは、組織に自律運用への道のりのロードマップを提供し、新興の自律型経済に貢献して恩恵を受けるのを支援します。初期データ収集から継続的な運用と改善まで、自律システムの完全なライフサイクルに対応するアプローチを実装することで、組織はそれぞれの領域で持続可能な競争優位性を開発できます。 フィジカル AI での成功には、個々の技術をデプロイするだけでなく、感知、処理、学習、アクションを、複雑な環境で独立して動作できる一貫したシステムに統合する体系的なアプローチが必要です。本記事で概説したフレームワークは、安全な自律運用、スケーラビリティ、信頼性、継続的な改善を保証しながら、統合を実現するために必要な構造を提供します。 まとめ AWS のフィジカル AI フレームワークは、組織がデジタル世界と物理世界を橋渡しする自律システムを安全に構築してデプロイする方法の根本的な変化を表しています。物理世界の接続とデジタル化からエッジ推論と運用まで、6 つの相互接続された機能を統合することで、このフレームワークは、実世界の運用データがますます高性能な AI モデルを推進する継続的な改善フライホイールを作り出します。クラウドベースのトレーニングとエッジベースの自律性を組み合わせたデュアルループアーキテクチャにより、組織は人の介入を最小限に抑えながら、複雑な物理環境を理解し、推論し、行動できるシステムを開発できます。製造、輸送、エネルギー、ヘルスケアなどの業界をすでに変革しており、インテリジェントシステムが継続的に学習して改善しながら独立して動作する新興の自律型経済を推進しています。補完的なポッドキャストをご覧ください: Physical AI: Teaching Machines to Act, Not Just Think 。 フィジカル AI が運用をどのように変革できるかを探る準備はできていますか? フィジカル AI フレームワークの各機能を深く掘り下げ、詳細な技術ガイダンス、リファレンスアーキテクチャ、実際の顧客事例を共有する今後の 6 部構成のブログシリーズにご参加ください。自律システムの旅を始めたばかりでも、既存のデプロイメントをスケールしようとしている場合でも、フィジカル AI スペシャリストに連絡して、特定のユースケースについて話し合い、AWS が自律型経済への参加をどのように支援できるかをご確認ください。 著者について David Randle AWS でフィジカル AI の GTM をリードしています。デジタル世界と物理世界を橋渡しする自律システムを実現する AWS の戦略的イニシアチブを担当しています。3D 技術とリアルタイムシステムで 19 年以上の経験を持ち、Dassault Systèmes SolidWorks に買収される前の Bunkspeed でリアルタイムレンダリングの普及に貢献しました。自律運用の基盤となるデジタルツインワークフローと仮想シミュレーションシステムのバックグラウンドに、ビジネスと工業デザインの知見を組み合わせ、変革的な技術をヒューマナイズして明確にしています。これらの経験により、AI を活用したシステムが物理環境をどのように知覚し、理解し、行動する必要があるかについて深い理解を持っています。 Adam Rasheed AWS の Emerging Technology (Advanced Computing) 部門の責任者として、エンジニアリング向けの Agentic AI と自律システムを実現するフィジカル AI の限界を押し広げるチームをリードしています。産業領域とデジタル領域の両方にまたがる中期段階の技術開発で 28 年以上の経験があり、航空、エネルギー、石油・ガス、再生可能エネルギー業界でデジタルツインを 10 年以上開発してきました。Caltech で実験的超高速空気熱力学 (軌道再突入加熱) を研究し博士号を取得しました。MIT Technology Review Magazine から「世界のトップ 35 イノベーター」の 1 人に選ばれ、AIAA Lawrence Sperry Award も受賞しました。産業分析、運用最適化、人工リフト、パルスデトネーション、極超音速、衝撃波誘起混合、宇宙医学、イノベーションフレームワークに関する 32 件以上の特許と 125 件以上の技術出版物があります。 Dan Cotting AWS で Worldwide フィジカル AI Specialist Solutions Architect チームをリードし、この領域の技術リーダーとして、フィールドでの AWS のフィジカル AI アーキテクチャ戦略の開発を支援しています。顧客とパートナーと直接協力して、空間インテリジェンス、シミュレーションとトレーニング、エッジインテリジェンスのユースケースにまたがるフィジカル AI ワークロードを AWS でスケールして成長させています。過去 9 年間、BMW、NVIDIA、ExxonMobil、Koch Industries、Siemens などの顧客やパートナーと協力しながら、自動車、製造、エネルギー、ヘルスケア、航空宇宙業界全体で空間コンピューティングとフィジカル AI を専門としてきました。AI、IoT、空間コンピューティング、シミュレーション、エッジ技術の融合を通じて自律運用を実現することに焦点を当てています。AWS に入社する前は、Magic Leap、Shockoe、Team One で多くの業界のエンタープライズ顧客に空間アプリケーションを提供していました。Virginia Commonwealth University で修士号、Boston University で学士号を取得しています。妻と息子とシアトルに住んでいます。 Ross Pivovar 物理シミュレーションと機械学習の両方のための数値的および統計的手法開発で 15 年以上の経験があります。AWS の Senior Solutions Architect として、自己学習デジタルツイン、マルチエージェントシミュレーション、物理 ML サロゲートモデリングの開発に焦点を当てています。 この記事は Kiro が翻訳を担当し、Professional Services の Akinori Hiratani と Solution Architect の Shinya Nishizaka がレビューしました。

本記事は 2026 年 1 月 20 日 に公開された「 Using the shared plan cache for Amazon Aurora PostgreSQL 」を翻訳したものです。 本記事では、 Amazon Aurora PostgreSQL 互換エディション の共有プランキャッシュ機能により、高い同時実行性環境で汎用 SQL プランのメモリ消費を大幅に削減できることを説明します。40GB のメモリ負荷を 400MB まで削減できます。 Aurora PostgreSQL データベースクラスターが数千の同時接続を処理し、それぞれが同じ プリペアドステートメント を実行している状況を想像してください。クエリ自体はシンプルなのに、メモリ使用量が数十 GB まで増加しています。何が起きているのでしょうか。これはプランの重複による隠れたコストが発生している可能性があり、共有プランキャッシュで解決できます。 PostgreSQL の汎用プランを理解する プリペアドステートメントは、アプリケーションで (データベースとやり取りする関数やメソッドを定義する際に) 一般的に使われます 。これらのステートメントは、データベースアクセスコードやメソッドに含まれます。準備フェーズには SQL ステートメントの構造とプレースホルダーが含まれ、アプリケーションがプリペアドステートメントを実行する際に実際の値が入ります。準備フェーズでステートメントが解析、分析、書き換えられるため、実行時の解析と分析作業の繰り返しが省けます。 ソリューションに入る前に、PostgreSQL がプリペアドステートメントをどう扱うかを理解しましょう。PostgreSQL と Aurora PostgreSQL では、プリペアドステートメントは 2 種類のプランで実行できます。 カスタムプラン: 実行ごとに特定のパラメータ値で新しく作成され、リテラルが含まれます。 汎用プラン: パラメータに依存しないプランで、実行間で再利用され、リテラルは含まれません。 デフォルトでは、PostgreSQL はこれら 2 つのプランタイプの選択にインテリジェントなアプローチを用います。 プリペアドステートメントの最初の 5 回の実行ではカスタムプランを使用 これらのカスタムプランの平均コストを計算 6 回目の実行で汎用プランを作成 汎用プランのコストがカスタムプランの平均コストと同等かそれ以下なら、以降の実行で使用 このアプローチは頻繁に実行されるクエリのプラン作成時間を節約できますが、多数の同時データベース接続がある環境では隠れたコストが発生します。 問題: 大規模環境でのメモリ非効率 このアプローチは個々の接続ではうまく機能しますが、多数の同時データベース接続がある環境では 2 つの大きな非効率が生じます。 不要なプラン生成: 汎用プランが使われない場合 (カスタムプランの方が効率的なため) でも、コスト比較のためにシステムは汎用プランを作成してメモリに保存します。たとえば、パーティションテーブルでは、コストがリーフパーティションごとに計算されて合計されるため、汎用プランが使われない可能性が高くなります。 プランの重複: 同じクエリが数百または数千のセッションで実行される場合、各セッションが同一の汎用プランのコピーを保持し、大量のメモリ重複が発生します。 この問題を具体例で示してみましょう。 テスト環境のセットアップ この例では、新しいセッションで各 1000 パーティションを持つテーブル t1 と t2 を作成します。次に、各ループで 1000 個の値を挿入する処理を 100 回ループし、各テーブルに 100,000 行を挿入します。最後に両方のテーブルの統計情報を更新します。 注意: 共有プランキャッシュ機能を使うには、Aurora PostgreSQL バージョン 17.6 以降、またはバージョン 16.10 以降を使用する必要があります。 -- Create partitioned tables CREATE TABLE t1(part_key int, c1 int) PARTITION BY RANGE(part_key); CREATE TABLE t2(part_key int, c1 int) PARTITION BY RANGE(part_key); \pset pager -- Generate 1000 partitions for each table (simulating large-scale partitioning) SELECT 'CREATE TABLE t1_' || x || ' PARTITION OF t1 FOR VALUES FROM (' || x || ') TO (' || x+1 || ')' FROM generate_series(1, 1000) x; \gexec SELECT 'CREATE TABLE t2_' || x || ' PARTITION OF t2 FOR VALUES FROM (' || x || ') TO (' || x+1 || ')' FROM generate_series(1, 1000) x; \gexec -- Populate tables with sample data DO $do$ BEGIN FOR i IN 1..100 LOOP INSERT INTO t1 SELECT x, i FROM generate_series(1, 1000) x; INSERT INTO t2 SELECT x, i FROM generate_series(1, 1000) x; END LOOP; END $do$; -- Update statistics for optimal query planning ANALYZE t1, t2; \gexec スイッチを使って、select の出力を独立した SQL ステートメントとして実行できます。\pset pager で psql pager を無効にすると、テーブルパーティション作成時に何度も Enter を押す必要がなくなります。 メモリ消費の観察 Session 1 で、次のプリペアドステートメントを作成して実行します。 -- Create a prepared statement with a simple join PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times to trigger generic plan creation EXECUTE p2(1, 4); -- Execution 1: Custom plan EXECUTE p2(1, 4); -- Execution 2: Custom plan EXECUTE p2(1, 4); -- Execution 3: Custom plan EXECUTE p2(1, 4); -- Execution 4: Custom plan EXECUTE p2(1, 4); -- Execution 5: Custom plan EXECUTE p2(1, 4); -- Execution 6: Generic plan created 次に、メモリ消費を確認します。 -- Check memory usage for cached plans SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; -[ RECORD 1 ]-+--------------------------------------- name | CachedPlan ident | prepare p2(int, int) as + | select sum(t1.c1) + | from t1, t2 + | where t1.part_key = t2.part_key and + | t1.c1 = $1 and t1.part_key = $2; size | 4161 kB このテストでは、汎用プランが約 4MB を消費し、プリペアドステートメントが解放されるか接続が終了するまでメモリに残ることがわかります。 重複の問題 次に、別のセッション ( Session 2 ) で同じプリペアドステートメントを実行します。 -- Session 2: Using the same prepared statement PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); -- Check memory usage SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; -[ RECORD 1 ]-+--------------------------------------- name | CachedPlan ident | prepare p2(int, int) as + | select sum(t1.c1) + | from t1, t2 + | where t1.part_key = t2.part_key and + | t1.c1 = $1 and t1.part_key = $2; size | 4161 kB Session 2 も全く同じ汎用プランで 4MB を消費しています! 乗算効果 この重複は、プリペアドステートメントを実行するすべてのセッションで発生します。影響を計算してみましょう。 1 プリペアドステートメント × 100 接続 × 4MB = 400MB のメモリ 100 種類のプリペアドステートメント × 100 接続 × 4MB = 40GB のメモリ この大量のメモリ消費は、セッションが同一の汎用プランのコピーを保存しているにもかかわらず発生します。多数の同時データベース接続がある環境では、利用可能なメモリをすぐに使い果たし、より大きく高価なインスタンスタイプを使わざるを得なくなります。 ソリューション: Aurora PostgreSQL 共有キャッシュプラン Aurora PostgreSQL は共有キャッシュプラン (SPC) でこの問題を解決します。各汎用プランのコピーを 1 つだけ保持し、複数セッションが使えるようにします。プランキャッシュのパフォーマンス上の利点を維持しながら、メモリ消費を大幅に削減します。 共有プランキャッシュ (SPC) は、 クラスターまたはインスタンスパラメータグループ で有効にできます。 apg_shared_plan_cache.enable = ON apg_shared_plan_cache.enable は動的パラメータであるため、変更を有効にするためにインスタンスを再起動する必要はありません。 SPC は動的ハッシュテーブルとして実装され、セッション間で共有されます。キャッシュ内のエントリ数は apg_shared_plan_cache.max で制御できます。次のパラメータでエントリの最小サイズと最大サイズも制御できます。 apg_shared_plan_cache.min_size_per_entry apg_shared_plan_cache.max_size_per_entry 共有プランキャッシュの動作デモ 共有プランキャッシュを有効にして、先ほどの実験を繰り返してみましょう。 Session 1 (最初の接続): -- Create and execute the same prepared statement PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); -- Check memory usage SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; 最初のセッションは、ローカルメモリに 4MB のプランが表示されます (共有キャッシュに入力するために必要)。 Session 2 (後続の接続): -- Create the same prepared statement PREPARE p2(int, int) AS SELECT sum(t1.c1) FROM t1, t2 WHERE t1.part_key = t2.part_key AND t1.c1 = $1 AND t1.part_key = $2; -- Execute 6 times EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); EXECUTE p2(1, 4); -- Check memory usage SELECT name, ident, pg_size_pretty(total_bytes) as size FROM pg_backend_memory_contexts WHERE name = 'CachedPlan'; (0 rows) ローカルプランストレージなし! 2 番目のセッションは共有プランキャッシュを使っています。 キャッシュ使用状況の監視 次の SQL を実行して、キャッシュに保存された個々の共有プランが受け取ったキャッシュヒット数を表示します。各ヒットは、セッションメモリで重複する必要がなかったプランを表します。 -- View shared plan cache statistics SELECT cache_key, query, hits FROM apg_shared_plan_cache(); -[ RECORD 1 ]------------------------------------- cache_key | -5127257242415815179 query | prepare p2(int, int) as + | select sum(t1.c1) + | from t1, t2 + | where t1.part_key = t2.part_key and + | t1.c1 = $1 and t1.part_key = $2; hits | 2 クリーンアップ: -- clear the cache SELECT * FROM apg_shared_plan_cache_reset(); -- drop the tables DROP TABLE t1; DROP TABLE t2; パフォーマンスへの影響 100 接続で 100 種類のプリペアドステートメントを使う先のシナリオ例では、40GB の重複プランストレージからわずか 400MB の共有キャッシュに変換されました。以下のスクリーンショットは、 apg_shared_plan_cache.enable = off で 100 接続で 100 種類のプリペアドステートメント (上記の例から使用) を使って pgbench でテストを実行したインスタンスから取得した Freeable Memory CloudWatch メトリックのグラフです。02:05 から 02:10 の間に、FreeableMemory が約 40GB 減少しています。これは予想される重複プランストレージのフットプリントと一致します。共有プランキャッシュを有効にして同じテストを再度実行すると、メモリへの影響は大幅に削減され、40GB ではなくわずかなメモリしか必要としませんでした。 この削減により、次のことが可能になります。 同じワークロードをより小さいインスタンスで実行 し、AWS コストを大幅に削減 メモリ制限に達することなく より多くの同時接続をサポート トラフィックスパイク時の メモリ不足エラーを回避 ベストプラクティス この機能は次の場合に特に有益です。 アプリケーションが数百または数千のデータベース接続を維持している プリペアドステートメントを多用している クエリにパーティションテーブルや複雑な演算子 (join や共通テーブル式など) が含まれ、大きなプランが生成される バックエンドプロセスからの高いメモリ使用量が観察される ワークロードに、パラメータ化されたクエリを使用した反復的なクエリパターンがある 共有キャッシュプランは大きな利点を提供しますが、次のシナリオには適さない場合があります。 一意性が高いアドホッククエリを用いるワークロード プリペアドステートメントをほとんど再利用しないアプリケーション 同時接続が少ない環境 まとめ 本記事では、Aurora PostgreSQL で共有キャッシュプランを有効にする方法を説明しました。多数の同時データベースセッションでプリペアドステートメントを使用する際に、同じ汎用クエリプランがメモリに重複して保存されるのを防げることを示しました。 セッション間で冗長なプランストレージを削除することで、より小さいインスタンスでより多くの接続を実行でき、運用の複雑さとコストの両方を削減できます。さまざまなプランタイプの詳細については PostgreSQL ドキュメントの the prepare statement を、空きメモリ測定の詳細については Amazon CloudWatch metrics for Amazon Aurora を参照してください。 著者について Souvik Bhattacherjee Souvik は AWS の Senior Software Engineer で、Aurora PostgreSQL データベースのクエリ処理機能の向上に取り組んでいます注。データベース/HPC 業界で 8 年以上の経験があり、データベースシステムと高性能コンピューティングシステムに関連するトピックに貢献してきました。 Jungkook Lee Jungkook は AWS の Senior Software Development Engineer で、Aurora PostgreSQL のパフォーマンス向上と機能拡張に注力するチームをリードしています。データベースシステムと分散コンピューティングアーキテクチャで 10 年以上の経験があり、クエリ最適化とデータベースパフォーマンスを専門としています。 Stephen Wood Stephen は AWS の Senior Specialist Database Solutions Architect です。Amazon RDS PostgreSQL、Amazon Aurora PostgreSQL、Amazon Aurora DSQL を専門としています。過去 24 年間、さまざまなタイプの企業でデータベースシステムに関わっており、常に新しいデータベーステクノロジーに取り組むことを楽しんでいます。 翻訳は Technical Account Manager の石渡が担当しました。

本稿は、2025 年 11 月 19 日に Networking & Content Delivery で公開された “ AWS PrivateLink extends cross-region connectivity to AWS services ” を翻訳したものです。 AWS は、 AWS PrivateLink が AWS のサービスへのクロスリージョン接続をサポート開始 を発表しました。今回のアップデートによってインターフェイス VPC エンドポイントを使用して、他の商用リージョンにある AWS サービスに対してプライベートかつ安全に接続できるようになりました。この記事では、クロスリージョンプライベート接続の潜在的なユースケースや利用方法、アクセス制御の方法について説明します。 概要 AWS PrivateLink は、セキュアかつシンプルな方法で VPC 間やアカウント間でサービスの共有やアクセス性を提供するサービスです。インターネットゲートウェイなしでプライベートサブネットから VPC エンドポイントサービス にアクセスでき、トラフィックは AWS のバックボーンネットワークのみを流れます。また、セキュリティグループや VPC エンドポイントポリシーを用いたエンドポイント保護も可能です。 以前の PrivateLink は同一のリージョン内での接続のみをサポートしており、サービスプロバイダーとサービス利用者は同一の AWS リージョン内に存在する必要がありました。re:Invent 2024 では、新たに ユーザ管理の VPC エンドポイントサービスへのクロスリージョンでのプライベート接続のサポート を開始しました。 今回の発表により、PrivateLink のクロスリージョン接続機能は AWS 商用リージョン内において Amazon が提供するマネージドサービスにまでサポート対象を拡張しました。これにより、VPC ピアリングなどによるリージョン間接続の管理やインターネットを介した接続を必要とせず、インターフェースエンドポイント経由で PrivateLink のクロスリージョン接続をサポートする他リージョンでホストされているサービスにネイティブにアクセスできるようになりました。この機能はエンドポイントポリシーをサポートしており、クロスリージョン接続が組織のポリシーを満たすことを保証する新たなアクセス制御を提供するとともに、データに対するリージョン単位の制御を簡素化します。 ユースケース この機能により、PrivateLink のシンプルさとセキュリティという中核的な利点が、リージョン内接続からリージョン間接続へと拡張されます。同一リージョン内の VPC エンドポイントサービスにアクセスする場合でも、別のリージョン内のサービスにアクセスする場合でも、実装とセキュリティは一貫して維持できます。ほとんどの AWS サービスはすべてのリージョンで利用可能ですが、以下のようなユースケースでは異なるリージョンのサービスにアクセスしたい場合があります： サードパーティプロバイダーが共有する別のリージョンにあるリソースにアクセスする必要がある場合。たとえば、社内外のさまざまなデータセットでトレーニングされたモデリングツールをバージニア北部リージョンで構築しているとします。このモデルがデータアグリゲーターの1社が提供するデータセットにアクセスする必要があり、そのデータセットはアフリカリージョンにある Amazon Simple Storage Service (Amazon S3) バケット経由で提供されている。 データレジデンシー要件が厳格な国で事業を展開する多国籍金融企業である場合。当該国内の消費者データは全て国内の AWS リージョンに保存する必要があるが、別のリージョンでホストされている外国為替ワークフローが取引承認のために国内に保存されたユーザーメタデータへの一時的なアクセスが必要。 グローバルに分散したインフラを持つ SaaS プロバイダーであり、監視データをアイルランドリージョンにある中央データレイクにストリーミングしたいと考えている場合。監視データはグローバルヘルス監視のためにほぼリアルタイムのダッシュボードを動作させるために疎通性が必要。 オレゴンリージョンに重要なワークロードがあり、Amazon Data Firehose への途切れないコネクションが必要な場合。プライマリ VPCE をオレゴンリージョンの Firehose に、セカンダリ VPCE をオハイオリージョンの Firehose に接続。オレゴンリージョンで接続問題が発生した場合に備え、ワークロードはオハイオリージョンにフェイルオーバーするよう構成されている。 クロスリージョンアクセスの制御 クロスリージョン接続機能を使い始める前に、適切な権限があることを確認する必要があります。 [必須] リージョン間の PrivateLink 接続機能を選択する : これまで、すべての PrivateLink アクション は Amazon Elastic Compute Cloud（EC2） の名前空間に含まれていました。クロスリージョン接続機能に関しては、異なる VPCE 名前空間での vpce:AllowMultiregion 権限のみのアクションによって制限されます。この許可がないと、ローカルリージョンのAWSサービスにはVPCエンドポイントを作成できますが、他のリージョンの AWS または VPCE サービスには作成できません。 アイデンティティポリシーで vpce:AllowMultiregion が許可されていることと、 サービスコントロールポリシー (SCP) で拒否されていないことを確認してください。クロスリージョン接続機能を有効にするには、両方のポリシーを正しく設定する必要があります。 [必須]リージョンのオプトイン : AWS アカウントではほとんどのリージョンがデフォルトで有効になっていますが、2019 年 3 月 20 日以降に開始されたリージョンは、手動で選択した場合にのみアクティブ化されます。AWS はこれらを オプトインリージョン と呼んでいます。オプトインリージョンでホストされている AWS サービスに PrivateLink 経由でアクセスする場合は、まずそのリージョンにオプトインする必要があります。このガードレールは、アカウントで許可されていない地域への誤ったアクセスや地域からのアクセスを防ぐのに役立ちます。 開始方法 サービスディスカバリー 必要な権限を構成した後、 AWS Management Console を使用して、クロスリージョン接続をサポートできる AWS サービスを検出します。図1のように VPC コンソール に移動し、ナビゲーションペインでエンドポイントを選択し、エンドポイントの作成をクリックします。 ＜図１ VPC Endpoint 作成のための AWS コンソール＞ 項目“ タイプ ”内で「AWSサービス」を選択し、次に「 クロスリージョンエンドポイントを有効にする 」のチェックボックスを有効にします。これで、ドロップダウンメニューから接続したいサービスリージョンを選択できるようになります。 サービスタブには、図２のようにクロスリージョン PrivateLink 接続機能でサポートされているすべてのAWSサービスが表示されます。 ＜図２ クロスリージョンプライベートリンク作成時の AWS コンソール UI＞ CLI を使用してサービスを検出するには、アクセスしたいリージョンに service-region フィルターを設定して describe-vpc-endpoint-services コマンドを使用します。次の例では、オレゴンリージョンの VPC エンドポイント経由でアクセスできるオハイオリージョンのすべての AWS サービスをリストします。 aws ec2 describe-vpc-endpoint-services \ --filters Name=service-type,Values=Interface Name=owner,Values=amazon \ --region us-west-2 \ --service-region us-east-2 \ --query ServiceNames インターフェースエンドポイントの作成 インターフェースエンドポイントを作成する残りの手順は、リージョン内およびクロスリージョン対応サービスで同じです。コンソールから必要なサービス名を選択し、VPC、サブネット、その他の構成オプションを選択します。最後に、エンドポイントの作成をクリックします。エンドポイントのステータスが利用可能になると、セットアップが完了し、インターフェースエンドポイント経由でリモート AWS サービスにアクセスできるようになります。 ＜図３ 作成された S3用のクロスリージョンプライベートリンクエンドポイント＞ CLI を通じてオレゴンリージョンの VPC からオハイオリージョンの S3 へのエンドポイントを作成するには、次の例を使用できます。 aws ec2 create-vpc-endpoint \ --vpc-id <vpc-id> \ --service-name com.amazonaws.us-east-2.s3 \ --vpc-endpoint-type Interface \ --subnet-ids <subnet-id-1> <subnet-id-2> \ --region us-west-2 \ --service-region us-east-2 デフォルトでは、AWS サービスへのすべてのインターフェースエンドポイントでプライベート DNS が有効になっています。これにより、パブリックエンドポイントの DNS 構文を保持することで、パブリックからプライベート接続への移行が簡素化されます。エンドポイントに関連付けられた DNS 名を確認するには、図４のように VPC エンドポイント ID をクリックし、 詳細 タブで DNS 名を確認します。 ＜図４ クロスリージョンプライベートリンクのための DNS 名＞ クロスリージョンアクセスの追加制御 PrivateLink は、使用がロールの権限と組織のポリシーに準拠することを保証するための複数の制御レイヤーを提供します。これらの制御を使用して、信頼できるエンティティのみが、許可されたサービスとリージョンに対して PrivateLink アクションを実行できるようにすることができます。前述の必須制御に加えて、以下のキーはクロスリージョン接続に特化した拡張機能を提供します。 [オプション] アクセスできるリージョンを定義する： コンシューマーとして、 ec2:VpceServiceRegion キーは、エンドポイントを通じてアクセスできるリモートサービスリージョンを定義するのに役立ちます。例えば、このアイデンティティポリシーは、東京リージョンまたはアイルランドリージョンでホストされているサービスへの VPC エンドポイントの作成と削除のみを許可します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "limitserviceregions", "Action": [ "ec2:CreateVpcEndpoint", "ec2:DeleteVpcEndpoint”, "vpce:AllowMultiRegion" ], "Effect": "Allow", "Resource": "arn:aws:ec2:*:*:vpc-endpoint/*", "Condition": { "StringLike": { "ec2:VpceServiceRegion": [ "ap-northeast-1", "eu-west-1" ] } } } ] } [オプション] AWS リソースにアクセスできるリージョンを定義する： リソース所有者として、リソースポリシーを使用してデータ境界を確立できます。これにより、どのリソースに、誰が、どのネットワーク経由でアクセスできるかを制限できます。 aws:VpceAccount や aws:VpceOrgID などのキーを引き続き使用できますが、新しい aws:SourceVpcArn キーは、VPC エンドポイント経由でリソースにアクセスする際のリージョンベースのアクセス制御の実装に役立ちます。クロスリージョン VPC エンドポイント経由でアクセス可能なすべての AWS サービスがこのキーをサポートしています。このキーを使用して、VPC エンドポイント経由でリソースにアクセスできるリージョンを定義できます。アカウントと VPC ID を含めて、ポリシーをより細かくまたは粗くすることもできます。詳細とサポートされているサービスについては、IAM に関するガイドを参照してください。例えば、このリソースポリシーは、ロンドンリージョンの指定されたアカウントと VPC の VPC エンドポイントから接続が発信されない限り、S3 バケットへのすべてのアクセスを拒否します。 { "Version":"2012-10-17", "Statement": [ { "Sid": "AccessToSpecificVpcOnly", "Principal": "*", "Action": "s3:*", "Effect": "Deny", "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket1", "arn:aws:s3:::amzn-s3-demo-bucket1/*" ], "Condition": { "ArnNotLike": { "aws:SourceVpcArn": "arn:aws:ec2:eu-west-2:<Account-Id>:vpc/<VPC-Id>" } } } ] } 考慮事項とベストプラクティス 耐障害性と高可用性のために、最低2つのアベイラビリティゾーン（AZ）に VPC エンドポイントを作成することをお勧めします。これにより、コンシューマーとサービスリージョンの両方で AZ 間の PrivateLink マネージドなフェイルオーバーが可能になります。リージョン内接続とは異なり、別のリージョンの VPCE サービスにアクセスする場合、 AZ を一致させる必要はありません。リモート VPCE サービスへのインターフェースエンドポイントは、必要な任意の数の AZ に作成できます。 他のリージョンの AWS サービスへのクロスリージョン接続は、ゾーン DNS をサポートしていません。これらのエンドポイントにはリージョナル DNS レコードのみが生成されます。これは耐障害性に関するガイダンスと沿っており、エンドポイントが PrivateLink マネージドなフェイルオーバー機能の恩恵を受けることを保証します。 クロスリージョン接続はインターフェースエンドポイントのみでサポートされています。ゲートウェイ、ゲートウェイロードバランサー、リソースエンドポイントタイプはクロスリージョン接続をサポートしていません。 執筆時点で、この機能は Amazon S3 、 AWS Identity and Access Management（IAM） 、 Amazon Elastic Container Registry（ECR） 、 Amazon Data Firehose などのサービスをサポートしており、今後さらに多くのサービスが追加される予定です。サポートされているサービスの最新リストについては、 PrivateLink のユーザーガイド を参照するか、このブログで説明されているサービスディスカバリー手順に従ってください。 PrivateLink は AWS Fault Injection Service（FIS） と統合されており、リージョン内およびクロスリージョン対応インターフェースエンドポイントのリージョナルイベントをシミュレートし、障害シナリオをモデル化できます。詳細については、 AWS FIS のドキュメント を参照してください。 PrivateLink の標準料金（時間とデータ処理）が、ローカルリージョンまたはリモートリージョンのサービスへのすべてのインターフェースエンドポイントに適用されます。さらに、データ転送の方向性に関係なく、 リージョン間で転送されるギガバイトごとに標準のEC2リージョン間データ転送料金 をインターフェースエンドポイント所有者に請求します。詳細については、 PrivateLink 料金ページ をご覧ください。 まとめ リージョナル分離と耐障害性の確保ために、ローカルリージョンで AWS サービスを使用することをお勧めします。クロスリージョン PrivateLink 接続は、特定のリージョンに配置されたリソースの共有やアクセスが必要なユースケース、データ居住規制への対応、マルチリージョン災害復旧計画の実装を目的として設計されています。この機能により、ワークロードが複数のリージョンに拡大しても一貫した安全なネットワーク接続が保証されます。グローバルに分散したアプリケーションが、プライベートエンドポイントを通じてリージョンごとの AWS リソースへの接続、集中管この機能により、ワークロードが複数のリージョンに拡大しても一貫した安全なネットワーク接続が保証されます。理されたデータレイクへのアクセス、他リージョンのベンダー・パートナー・チームとの連携を簡素化します。 今回紹介した機能はコンソール、CLI、API、または CloudFormation を使用して開始できます。詳細については、 PrivateLink ユーザーガイド 、 ユーザ管理 VPCE サービスのクロスリージョン接続の紹介ブログ 、および AWS PrivateLink 経由でサービスに安全にアクセスするためのホワイトペーパー を参照してください。 翻訳は Technical Account Manager の由原が担当しました。原文は こちら です。

本記事は 2026 年 2 月 5 日に公開された Nima Kaviani の“ Opus 4.6 is now available in Kiro ” を翻訳したものです。 本日より、Kiro IDE と CLI で Anthropic の最新 SoTA (State of the Art: 最先端)モデルである Claude Opus 4.6 が利用できるようになりました。Opus 4.6 は Anthropic がこれまでにリリースしたもっとも強力なモデルであり、コーディングにおいては世界最高のモデルです。 Opus 4.6 は 4.5 の優れた点をすべて維持しながら、コーディング機能を拡張し、本番環境のコードや高度なエージェントに最適なモデルとなりました。大規模なコードベースや長期プロジェクトで優れた性能を発揮し、シニアエンジニアが複雑なタスクを Opus 4.6 に任せることで、数日かかるプロジェクトを数時間で完了できます。しかも、監視の手間も少なくすみます。 Opus 4.6 は、Kiro の仕様駆動型開発プロセスにもっとも適したモデルだと考えています。Opus 4.6 を搭載した Kiro は、大規模な既存プロジェクトに対して詳細かつ正確な仕様を作成し、最小限のユーザー入力で外科手術のような精度で更新を行えます。 Opus 4.6 は、Google、GitHub、AWS BuilderID、AWS IAM Identity Center でログインするすべての Kiro Pro、Pro+、Power のお客様に 実験的サポート として提供されます。Opus 4.6 は AWS US-East-1 (Northern Virginia) リージョンで利用でき、Claude Opus 4.5 と同じ 2.2 倍のクレジット乗数が適用されます。 Kiro をダウンロードする か、アプリまたは CLI を再起動して新しいモデルを使用してください。 翻訳は AppDev Consultant の宇賀神が担当しました。

2025 年、AWS は Amazon Elastic Compute Cloud (Amazon EC2) C8i インスタンス 、 M8i インスタンス 、 R8i インスタンス をリリースしました。これらのインスタンスには、3.9 GHz の持続的なオールコアターボ周波数を実現する AWS 限定のカスタム Intel Xeon 6 プロセッサが搭載されており、クラウドにおける同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 2026 年 2 月 4 日、ホストサーバーに物理的に接続された最大 22.8 TB の NVMe ベースの SSD ブロックレベルインスタンスストレージを活用する、新しい Amazon EC2 C8id、M8id、および R8id インスタンスが発表されました。これらのインスタンスは、以前の第 6 世代インスタンスよりも 3 倍多い vCPU、メモリ、ローカルストレージを提供します。 また、第 6 世代インスタンスよりも最大 43% 優れたコンピューティングパフォーマンスと 3.3 倍のメモリ帯域幅も提供します。さらに、第 6 世代インスタンスと比較して I/O 集約型データベースワークロードのパフォーマンスが最大 46% 向上しており、I/O 集約型のリアルタイムデータ分析のクエリ結果も最大 30% 速くなっています。 C8id インスタンス は、コンピューティング集約型ワークロードに最適です。これには、動画エンコーディング、画像操作、その他の形式のメディア処理など、高速で低レイテンシーのローカルストレージへのアクセスを必要とするワークロードが含まれます。 M8id インスタンス は、データのログ記録、メディア処理、中規模データストアなど、高速で低レイテンシーのローカルブロックストレージに加えて、コンピューティングリソースとメモリリソースのバランスを必要とするワークロードに最適です。 R8id インスタンス は、大規模な SQL データベースと NoSQL データベース、インメモリデータベース、大規模なデータ分析、AI 推論などのメモリ集約型ワークロード向けに設計されています。 C8id、M8id、および R8id インスタンスは、最大 384 個の vCPU、3 TiB のメモリ、22.8 TB のローカルストレージを搭載した 96 xlarge にスケールアップされました (第 6 世代のサイズは最大 32xlarge )。96 xlarge は、アプリケーションのスケールアップを容易にし、効率性をさらに向上させます。また、これらのインスタンスでは 2 つのベアメタルサイズ ( metal-48xl と metal-96xl ) も提供されているため、適切なインスタンスサイズを使用して、物理リソースへの直接アクセスからメリットを得るパフォーマンス最重視のワークロードをデプロイできます。 インスタンスは、ファミリーごとに 11 のサイズと 2 種類のベアメタル構成で利用できます。 インスタンス名 vCPU メモリ (GiB) (C/M/R) ローカル NVMe ストレージ (GB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) large 2 4/8/16* 1 x 118 最大 12.5 最大 10 xlarge 4 8/16/32* 1 x 237 最大 12.5 最大 10 2xlarge 8 16/32/64* 1 x 474 最大 15 最大 10 4xlarge 16 32/64/128* 1 x 950 最大 15 最大 10 8xlarge 32 64/128/256* 1 x 1,900 15 10 12xlarge 48 96/192/384* 1 x 2,850 22.5 15 16xlarge 64 128/256/512* 1 x 3,800 30 20 24xlarge 96 192/384/768* 2 x 2,850 40 30 32xlarge 128 256/512/1024* 2 x 3,800 50 40 48xlarge 192 384/768/1536* 3 x 3,800 75 60 96xlarge 384 768/1536/3072* 6 x 3,800 100 80 metal-48xl 192 384/768/1536* 3 x 3,800 75 60 metal-96xl 384 768/1536/3072* 6 x 3,800 100 80 *メモリの値はそれぞれ C8id/M8id/R8id の値です。 これらのインスタンスは、他の第 8 世代インスタンスタイプと同様に Instance Bandwidth Configuration (IBC) 機能をサポートしており、ネットワーク帯域幅と Amazon Elastic Block Store (Amazon EBS) 帯域幅間でリソースを割り振る柔軟性を提供します。ネットワーク帯域幅または EBS 帯域幅を 25% スケールして、各ワークロードのリソースを最適に割り当てることができます。これらのインスタンスは、CPU 仮想化、ストレージ、ネットワーキング機能を専用のハードウェアとソフトウェアにオフロードする第 6 世代の AWS Nitro Card も使用しているため、ワークロードのパフォーマンスとセキュリティが強化されます。 Elastic Network Adapter (ENA) と NVMe のドライバーが含まれる任意の Amazon マシンイメージ (AMI) を使用することで、パフォーマンスと機能を最大限に活用できます。現行世代のすべての AWS Windows AMI と Linux AMI には、デフォルトで AWS NVMe ドライバーがインストールされています。 AWS NVMe ドライバーが含まれていない AMI を使用する場合は、手動で AWS NVMe ドライバー をインストールできます。 以前のブログ記事 にも書きましたが、これらのインスタンス上のローカル NVMe ストレージについて注意すべき点がいくつかあります。 ブロックデバイスマッピングを AMI で、またはインスタンス起動時に指定する必要はありません。ローカルストレージは、ゲストオペレーティングシステムの起動後に 1 つ、または複数のデバイス (Linux では /dev/nvme[0-26]n1 ) として表示されます。 各ローカル NVMe デバイスは、 XTS-AES-256 ブロック暗号と固有のキーを使ってハードウェア暗号化されます。各キーは、インスタンスが停止または終了されると破棄されます。 ローカル NVMe デバイスの存続期間はアタッチ先のインスタンスと同じであり、インスタンスの停止後または終了後は保持されません。 詳細については、「Amazon EBS ユーザーガイド」の「 Amazon EBS ボリュームと NVMe 」をご覧ください。 今すぐご利用いただけます Amazon EC2 C8id、M8id、R8id インスタンスは、米国東部 (バージニア北部)、米国東部 (オハイオ)、および米国西部 (オレゴン) の AWS リージョン でご利用いただけます。R8id インスタンスは、欧州 (フランクフルト) リージョンでも提供されています。リージョンごとの提供状況と今後のロードマップについては、 AWS Capabilities by Region の [CloudFormation リソース] タブでインスタンスタイプを検索してください。 これらのインスタンスは、 オンデマンドインスタンス 、 Savings Plans 、 スポットインスタンス として購入できます。また、 ハードウェア専有インスタンス および 専有ホスト としても利用できます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で、C8id、M8id、および R8id インスタンスをぜひお試しください。詳細については、 EC2 C8i インスタンス ページ、 M8i インスタンス ページ、 R8i インスタンス ページをご覧ください。フィードバックは、 AWS re:Post for EC2 に、または通常の AWS サポート連絡先を通じてお寄せください。 – Channy 原文は こちら です。

2026 年 2 月 3 日、 AWS IAM アイデンティティセンター のマルチリージョンサポートの一般提供の開始をお知らせします。これにより、追加の AWS リージョン で AWS アカウントアクセス と マネージドアプリケーションの使用 が可能になります。 この機能を使用すると、Microsoft Entra ID や Okta などの外部 ID プロバイダー (IdP) に接続された IAM アイデンティティセンターの組織インスタンス内のワークフォース ID、許可セット、および他のメタデータを、現在のプライマリリージョンから追加のリージョンにレプリケートできるため、AWS アカウントアクセスの回復力が高まります。 また、ユーザーエクスペリエンスを改善したり、データレジデンシー要件を満たしたりするために、アプリケーションユーザーやデータセットに近い、任意のリージョンに AWS マネージドアプリケーションをデプロイすることもできます。追加のリージョンにデプロイされたアプリケーションは、レプリケートされたワークフォース ID にローカルでアクセスすることで、最適なパフォーマンスと信頼性を実現します。 ワークフォース ID を追加のリージョンにレプリケートすると、ワークフォースはそのリージョンでアクティブな AWS アクセスポータルエンドポイントを取得できます。これは、プライマリリージョンで IAM アイデンティティセンターのサービスが中断するといった万一の場合でも、ワークフォースは既にプロビジョニングされている許可を使用して、追加のリージョンの AWS アクセスポータルを通じて AWS アカウントに引き続きアクセスできることを意味します。プライマリリージョンから IAM アイデンティティセンターの設定を引き続き管理し、一元的なコントロールを維持できます。 複数のリージョンで IAM アイデンティティセンターを有効にする 使用を開始するには、現在使用している AWS マネージドアプリケーションが、AWS アイデンティティセンターで有効になっている カスタマーマネージド AWS Key Management Service (AWS KMS) キー をサポートしていることを確認する必要があります。2025 年 10 月に この機能 を導入した際、Seb は、会社のポリシーで単一リージョンのキーしか使用できない場合を除き、マルチリージョンの AWS KMS キーを使用することを推奨しました。マルチリージョンキーは、各リージョンで独立したキーインフラストラクチャを維持しながら、リージョン間で一貫したキーマテリアルを提供します。 IAM アイデンティティセンターを追加のリージョンにレプリケートする前に、まずカスタマーマネージド AWS KMS キーをそのリージョンにレプリケートし、IAM アイデンティティセンターのオペレーションに必要な許可を使用してレプリカキーを設定する必要があります。マルチリージョンレプリカキーの作成手順については、「AWS KMS デベロッパーガイド」の「 Create multi-Region replica keys 」をご覧ください。 プライマリリージョン (例: 米国東部 (バージニア北部)) の IAM アイデンティティセンターコンソール に移動し、左側のナビゲーションペインで [設定] を選択し、 [管理] タブを選択します。設定された暗号化キーが、マルチリージョンのカスタマーマネージド AWS KMS キーであることを確認します。リージョンをさらに追加するには、 [リージョンの追加] を選択します。 利用可能なリージョンのリストで、IAM アイデンティティセンターをレプリケートする追加のリージョンを選択できます。追加のリージョンを選択する際は、データコンプライアンスやユーザーエクスペリエンスなど、想定されるユースケースを考慮してください。 コンプライアンス上の理由で特定のリージョンに制限されたデータセットにアクセスする AWS マネージドアプリケーションを実行する場合は、データセットが存在するリージョンを選択します。追加のリージョンを使用して AWS アプリケーションをデプロイすることを計画している場合は、選択したリージョンと追加のリージョンでのデプロイを、必要な アプリケーションがサポートしていること を確認してください。 [リージョンの追加] を選択します。これにより、初期レプリケーションが開始されます。レプリケーションの所要時間は、アイデンティティセンターインスタンスのサイズによって異なります。 レプリケーションが完了すると、ユーザーは、この新しいリージョンの AWS アカウントとアプリケーションにアクセスできるようになります。 [ACS URL を表示] を選択すると、プライマリリージョンと追加のリージョンに関する SAML 情報 (Assertion Consumer Service (ACS) URL など) を表示できます。 ワークフォースが追加のリージョンを使用する方法 AWS アイデンティティセンターは、Microsoft Entra ID や Okta などの外部 IdP を使用した SAML シングルサインオンをサポートしています。IdP で認証されると、ユーザーは、AWS アクセスポータルにリダイレクトされます。新しく追加されたリージョンの AWS アクセスポータルにユーザーをリダイレクトするには、IdP 設定に追加リージョンの ACS URL を追加する必要があります。 次のスクリーンショットは、Okta 管理コンソールでこれを行う方法を示しています: その後、ユーザーが追加リージョンを見つけられるように、アイデンティティプロバイダーにブックマークアプリケーションを作成します。このブックマークアプリケーションはブラウザのブックマークのように機能し、追加リージョンの AWS アクセスポータルへの URL のみが含まれています。 既存のデプロイワークフローを使用して、AWS マネージドアプリケーションを追加リージョンにデプロイすることもできます。ユーザーは、 AWS アクセスポータル 、アプリケーションリンク、 AWS コマンドラインインターフェイス (AWS CLI) などの既存のアクセス方法を使用して、アプリケーションまたはアカウントにアクセスできます。 追加のリージョンへのデプロイをサポートしている AWS マネージドアプリケーションの詳細については、「 IAM アイデンティティセンターユーザーガイド 」にアクセスしてください。 知っておくべきこと この機能に関する重要な考慮事項を次に示します: 考慮事項 – リリース時にこの機能を利用するには、外部 IdP に接続された IAM アイデンティティセンターの組織インスタンスを使用している必要があります。また、AWS アカウントでプライマリリージョンと追加リージョンがデフォルトで有効になっている必要があります。IAM アイデンティティセンターのアカウントインスタンス、および他の 2 つの ID ソース (Microsoft Active Directory と IAM アイデンティティセンターディレクトリ) は現在サポートされていません。 オペレーション – プライマリリージョンは、ワークフォース ID、アカウントアクセス許可、外部 IdP、および他の設定を管理するための中心的な場所です。IAM アイデンティティセンターコンソールは、追加のリージョンでご利用いただけます (機能セットに制限あり)。アプリケーション管理とユーザーセッションの取り消しを除き、ほとんどのオペレーションは読み取り専用です。 モニタリング – すべてのワークフォースアクションは、アクションが実行されたリージョンの AWS CloudTrail に出力されます。この機能により、アカウントアクセスの継続性が強化されます。外部 IdP でサービスが中断した場合に、特権ユーザーが AWS にアクセスできるように ブレークグラスアクセス をセットアップできます。 今すぐご利用いただけます AWS IAM アイデンティティセンターのマルチリージョンサポートは、 デフォルトで有効になっている 17 の商用 AWS リージョン でご利用いただけるようになりました。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」にアクセスしてください。この機能は追加費用なしでご利用いただけます。カスタマーマネージドキーの保存と使用には、標準の AWS KMS 料金 が適用されます。 AWS アイデンティティセンターコンソール でぜひお試しください。詳細については、「 IAM アイデンティティセンターユーザーガイド 」にアクセスしてください。また、 アイデンティティセンターの AWS re:Post に、または通常の AWS サポート担当者を通じて、フィードバックをぜひお寄せください。 – Channy 原文は こちら です。

2026 年 1 月 26 日週、私たちは ラバ祭り を祝いました。これは、旧正月まで残りわずかであることを告げる中国暦の伝統的な祝日です。ラバ祭りは、中国の多くの人々にとって振り返りと準備にまつわる祝日であり、今年の出来事をまとめ上げ、未来に目を向けます。 2026 年 2 月 9 日週は、春の始まりであり、二十四節気最初の節季である 立春 です。中国の伝統では、春は成長が始まり、新しい節目がやってくる季節として捉えられることがよくあります。「一年の計は春にあり」ということわざもあり、春が自分の方向を定め、新たなスタートを切るときだという考え方を反映しています。 2026 年 1 月 26 日週のリリース 2026 年 2 月 2 日週私が注目したリリースをご紹介します。 Amazon Bedrock がサーバーサイドツールと拡張されたプロンプトキャッシュでエージェントワークフローのサポートを強化 – Amazon Bedrock に、開発者が AI エージェントを構築して運用する方法を改善する 2 つのアップデートが導入されました。 Responses API がサーバーサイドツールの使用をサポート するようになりました。このため、エージェントは AWS のセキュリティ境界内でウェブ検索、コード実行、データベース更新などのアクションを実行できます。 Bedrock には、プロンプトキャッシュのための 1 時間有効期限 (TTL) オプションも追加されました 。この延長は、長時間にわたるマルチターンエージェントワークフローのパフォーマンス向上とコスト削減に役立ちます。Amazon Bedrock では、OpenAI GPT OSS 20B および 120B モデルで サーバーサイドツールを利用でき、1 時間のプロンプトキャッシュ TTL は 一部の Anthropic Claude モデルに一般提供されています。 Amazon SageMaker Unified Studio が AWS PrivateLink を用いたプライベート VPC 接続を追加 – Amazon SageMaker Unified Studio が AWS PrivateLink のサポートを開始しました。このサポートにより、VPC と SageMaker Unified Studio 間のプライベート接続が提供されるため、カスタマーデータをパブリックインターネット経由でルーティングする必要はありません。VPC にオンボードされた SageMaker サービスエンドポイントを使用すると、データトラフィックが AWS ネットワーク内に留まり、IAM ポリシーによって制御されるため、より厳格なセキュリティとコンプライアンス要件をサポートできます。 Amazon S3 がデータ移動を必要としないオブジェクト暗号化の変更をサポート – Amazon S3 では、データを移動または再アップロードしなくても、既存の暗号化されたオブジェクトのサーバー側暗号化タイプを変更できるようになりました。 UpdateObjectEncryption API を使用することで、オブジェクトプロパティとライフサイクル適合性を維持しながら、SSE-S3 から SSE-KMS への切り替え、お客様管理の AWS Key Management Service (AWS KMS) キーのローテーション、または S3 バッチオペレーションによるバケット全体での暗号化の大規模な標準化を行うことができます。 Amazon Keyspaces が予測可能な高スループットワークロードのためのテーブルの事前ウォーミングを導入 – Amazon Keyspaces (Apache Cassandra 向け) がテーブルの事前ウォーミングをサポートするようになりました。これは、ウォームスループットのレベルを事前に設定して、テーブルが大量の読み取りおよび書き込みトラフィックを瞬時に処理できるようにするため、コールドスタートによる遅延が発生しません。事前ウォーミングは、製品のリリースやセールスイベントなど、トラフィックが急激に増加するときのスロットリングの軽減に役立ち、マルチリージョンテーブルを含めたオンデマンドキャパシティモードとプロビジョニングキャパシティーモードの両方で動作します。この機能は、一貫的な低レイテンシーパフォーマンスをサポートしながら、スループットの準備状態をより細かく制御できるようにします。 Amazon DynamoDB MRSC グローバルテーブルが AWS Fault Injection Service と統合 – Amazon DynamoDB マルチリージョン強整合性 (MRSC) グローバルテーブルが AWS Fault Injection Service に統合されました。この統合を利用することで、強力な整合性を備えたマルチリージョンワークロードのためにリージョン障害をシミュレートし、レプリケーション動作をテストして、アプリケーションのレジリエンシーを検証できます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS Verified Access を使用したマルチアカウント AWS 環境でのゼロトラストアクセスの構築 – この記事では、一元化された共有サービスアーキテクチャに AWS Verified Access を実装する方法を詳しく説明します。AWS IAM アイデンティティセンターおよび AWS Resource Access Manager (AWS RAM) と統合して、アプリケーション層にゼロトラストアクセスコントロールを適用し、マルチアカウント AWS 環境全体で運用オーバーヘッドを削減する方法を紹介します。 Amazon EventBridge がイベントのペイロードサイズを 1 MB に増加 – Amazon EventBridge が 最大 1 MB のイベントペイロードをサポートするようになりました。これは、以前の 256 KB 上限からの増加となります。この更新は、イベント駆動型アーキテクチャが、ペイロードを分割したり外部ストレージに依存したりすることなく、単一のイベント内でより充実したコンテキスト (複雑な JSON 構造、テレメトリデータ、機械学習出力、生成 AI 出力など) を確保できるようにします。 AWS MCP サーバーがデプロイエージェント SOP を追加 (プレビュー) – AWS がデプロイ SOP (Standard Operating Procedure) を導入しました。この SOP では、AI エージェントが Kiro、Cursor、Claude Code といった MCP 互換の統合開発環境 (IDE) やコマンドラインインターフェイス (CLI) での単一の自然言語プロンプトから AWS にウェブアプリケーションをデプロイできます。エージェントは、AWS Cloud Development Kit (AWS CDK) インフラストラクチャを生成し、AWS CloudFormation スタックをデプロイして、AWS ベストプラクティスに従った継続的インテグレーションと継続的デリバリー (CI/CD) ワークフローを設定します。プレビューでは、React、Vue.js、Angular、Next.js などのフレームワークがサポートされています。 AWS Network Firewall がウェブカテゴリフィルタリングによる生成 AI トラフィック可視性を追加 – AWS Network Firewall が、定義済みのウェブカテゴリを通じて生成 AI アプリケーショントラフィックの可視性を提供するようになりました。ファイアウォールルール内でこれらのカテゴリを直接使用することで、生成 AI ツールやその他ウェブサービスへのアクセスを制御できます。TLS インスペクションと組み合わせると、カテゴリベースのフィルタリングを完全な URL レベルで適用できます。 AWS Lambda が Kafka イベントソースマッピングのオブザーバビリティを強化 – AWS Lambda に、Kafka イベントソースマッピングのための強化されたオブザーバビリティが導入されました。これは、イベントポーリング設定、スケーリング動作、イベント処理状態を監視するための Amazon CloudWatch Logs とメトリクスを提供します。この更新により、Kafka ベースの Lambda ワークロードの可視性が向上し、チームが設定上の問題、許可エラー、および関数の失敗をより効率的に診断できるようになります。この機能は、Amazon Managed Streaming for Apache Kafka (Amazon MSK) イベントソースとセルフマネージド Apache Kafka イベントソースの両方をサポートします。 AWS CloudFormation 2025 年の振り返り – 1 年を振り返るこの記事では、2025 年に行われた CloudFormation 更新が紹介されており、早期検証、より安全なデプロイ、改善された開発者ワークフローに焦点を当てています。改善されたトラブルシューティング、ドリフト認識変更セット、スタックリファクタリング、StackSets 更新、および CloudFormation 言語サーバーや Infrastructure as Code (IaC) MCP サーバーを含めた新しい IDE と AI 支援ツールなどの機能強化が取り上げられています。 今後の AWS イベント カレンダーを確認して、近日開催予定のイベントにサインアップしましょう。 AWS Community Day Romania (2026 年 4 月 23～24 日) – このコミュニティ主導の AWS イベントでは、AWS ヒーロー、ソリューションアーキテクト、および業界エキスパートによる 10 を超えるプロフェッショナルセッションのために、開発者、アーキテクト、起業家、学生が一堂に会します。参加者は、エキスパートによるテクニカルトーク、世界的なカンファレンスで経験を積んだ講演者からのインサイト、参加者だけのネットワーキングブレイクでつながる機会を期待できます。これらはすべて、コラボレーションとコミュニティエンゲージメントをサポートするために設計されたハイクラスな会場で行われます。 このイベント外でもつながりを維持する方法をお探しの場合は、 AWS Builder Center に参加して、AWS コミュニティのビルダーとともに学び、構築し、つながりましょう。 2026 年 2 月 9 日週の Weekly Roundup もお楽しみに! – Betty 原文は こちら です。

本記事は 2026 年 2 月 5 日 に公開された「 Reduce Mean Time to Resolution with an observability agent 」を翻訳したものです。 あらゆる規模のお客様が Amazon OpenSearch Service を活用してオブザーバビリティワークフローを構築し、アプリケーションやインフラストラクチャの可視性を確保しています。インシデント調査では、Site Reliability Engineer (SRE) やオペレーションセンターの担当者が OpenSearch Service でログをクエリし、可視化を確認し、パターンを分析し、トレースを相関させて根本原因を特定し、平均復旧時間 (MTTR) を短縮しています。アラートがトリガーされるインシデントが発生すると、SRE は通常、複数のダッシュボードを行き来し、特定のクエリを作成し、最近のデプロイを確認し、ログとトレースを相関させてイベントのタイムラインを組み立てます。調査プロセスは大部分が手動であるだけでなく、すべてのデータがすぐに利用可能な状態であっても、担当者に認知的負荷をかけます。ここでエージェント AI が役立ちます。クエリ方法を理解し、さまざまなテレメトリシグナルを解釈し、インシデントを体系的に調査できる的確なアシスタントです。 本記事では、OpenSearch Service と Amazon Bedrock AgentCore を使用したオブザーバビリティエージェントを紹介します。根本原因の特定やインサイト取得を高速化し、複数のクエリや相関サイクルを処理して、MTTR をさらに短縮できます。 ソリューション概要 次の図は、オブザーバビリティエージェントの全体アーキテクチャを示しています。 アプリケーションとインフラストラクチャは、ログ、トレース、メトリクスの形式でテレメトリシグナルを出力します。テレメトリシグナルは OpenTelemetry Collector (ステップ 1) で収集され、各シグナル用の個別パイプライン ( ログ 、 トレース 、 メトリクス ) を使用して Amazon OpenSearch Ingestion にエクスポートされます (ステップ 2)。各パイプラインは、シグナルデータを OpenSearch Service ドメインと Amazon Managed Service for Prometheus に配信します (ステップ 3)。 OpenTelemetry は計装の標準であり、幅広い言語とフレームワークにわたってベンダー中立のデータ収集を提供します。さまざまな規模の企業が、特にオープンソースツールにコミットしている企業を中心に、オブザーバビリティのニーズに対してこのアーキテクチャパターンを採用しています。特筆すべきは、オープンソース基盤の上に構築されたアーキテクチャにより、企業がベンダーロックインを回避し、オープンソースコミュニティの恩恵を受け、オンプレミスやさまざまなクラウド環境にわたって実装できる点です。 本記事では、オブザーバビリティのユースケースを示すために OpenTelemetry Demo アプリケーションを使用します。約 20 の異なるマイクロサービスで構成される e コマースアプリケーションで、負荷生成や障害シミュレーション機能とともに、リアルなテレメトリデータを生成します。 オブザーバビリティシグナルデータ用の Model Context Protocol サーバー Model Context Protocol (MCP) は、エージェントを外部データソースやツールに接続するための標準的な仕組みを提供します。本ソリューションでは、各シグナルタイプに 1 つずつ、3 つの異なる MCP サーバーを構築しました。 Logs MCP サーバーは、OpenSearch Service ドメインに保存されたログデータの検索、フィルタリング、選択のためのツール関数を公開します。エージェントは、単純なキーワードマッチング、サービス名フィルター、ログレベル、時間範囲などのさまざまな条件でログをクエリできます。調査中に実行する一般的なクエリを模倣しています。次のスニペットは、ツール関数の疑似コードを示しています。 # Logs MCP Server - Key Functions search_otel_logs( query: string, # Text search query for log messages service: string, # Service name to filter logs severity: string, # Log level (INFO, WARN, ERROR) startTime: string, # Start time (ISO format or relative e.g., 'now-1h') endTime: string, # End time (ISO format or relative e.g., 'now') size: number # Number of results to return ) get_logs_by_trace_id( traceId: string, # Trace ID to retrieve all correlated logs size: number # Maximum number of logs to return ) Traces MCP サーバーは、分散トレースの検索と情報取得のためのツール関数を公開します。Traces MCP サーバーの関数は、トレース ID によるトレースの検索、特定のサービスのトレースの検索、トレースに属するスパン、スパンに基づいて構築されたサービスマップ情報、レート、エラー、期間 (RED メトリクスとも呼ばれる) の取得に役立ちます。エージェントはサービス間のリクエストパスを追跡し、障害が発生した場所やレイテンシーの発生源を特定できます。 # Traces MCP Server - Key Functions get_otel_spans( serviceName: string, # Service name to filter spans traceId: string, # Trace ID to filter spans spanId: string, # Span ID to retrieve a specific span operationName: string, # Operation/span name to filter startTime: string, # Start time (ISO format or relative) endTime: string, # End time (ISO format or relative) size: number # Number of results to return ) get_spans_by_trace_id( traceId: string, # Trace ID to retrieve all spans for size: number # Maximum number of spans to return ) get_otel_service_map( serviceName: string, # Service name to filter service map startTime: string, # Start time endTime: string, # End time size: number # Number of results to return ) get_otel_rate_error_duration_metrics( startTime: string, # Start time (default: 'now-5m') endTime: string # End time (default: 'now') ) Metrics MCP サーバーは、時系列メトリクスをクエリするためのツール関数を公開します。エージェントはこれらの関数を使用して、エラー率のパーセンタイルやリソース使用率を確認できます。システム全体の健全性を理解し、異常な動作を特定するための重要なシグナルです。 # Metrics MCP Server - Key Functions query_instant( query: string, # PromQL query expression time: string, # Evaluation timestamp (optional) timeout: string # Evaluation timeout (optional) ) query_range( query: string, # PromQL query expression start: string, # Start timestamp end: string, # End timestamp step: string, # Query resolution step (e.g., '15s', '1m') timeout: string # Evaluation timeout (optional) ) get_timeseries( metric: string, # Metric name or PromQL expression duration: string, # Time duration to look back (e.g., '1h', '6h') step: string # Step size (optional) ) search_metrics( pattern: string # Search pattern (supports regex e.g., 'http.*') ) explore_metric( metric: string # Metric name to explore (metadata + samples) ) 3 つの MCP サーバーは、調査エンジニアが使用するさまざまなタイプのデータにまたがり、エージェントがログ、トレース、メトリクス間で自律的に相関させて問題の根本原因を特定するための完全なワーキングセットを提供します。さらに、カスタム MCP サーバーは、収益、売上、その他のビジネスメトリクスに関するビジネスデータのツール関数を公開します。OpenTelemetry デモアプリケーションでは、影響やその他のビジネスレベルのメトリクスのコンテキストを提供するための合成データを開発できます。簡潔にするため、アーキテクチャの一部としてそのサーバーは示していません。 オブザーバビリティエージェント オブザーバビリティエージェントはソリューションの中心です。インシデント調査を支援するために構築されています。従来の自動化や手動のランブックは通常、事前定義された運用手順に従いますが、オブザーバビリティエージェントでは定義する必要がありません。エージェントは利用可能なデータに基づいて分析、推論し、発見した内容に基づいて戦略を適応させます。ログ、トレース、メトリクス間で発見を相関させて根本原因に到達します。 オブザーバビリティエージェントは、AI エージェントの開発を簡素化するオープンソースフレームワークである Strands Agent SDK で構築されています。SDK は、公開されたツールを呼び出し、一貫したターンベースのインタラクションを維持することで、基盤となるオーケストレーションと推論 ( エージェントループ ) を処理する柔軟性を備えたモデル駆動型アプローチを提供します。ツールを動的に検出する実装のため、機能変更時もエージェントは最新情報に基づいて意思決定できます。 エージェントは Amazon Bedrock AgentCore Runtime で実行されます。エージェントのホスティングと実行のためのフルマネージドインフラストラクチャを提供し、Strands、LangGraph、CrewAI などの一般的なエージェントフレームワークをサポートしています。また、多くの企業が本番グレードのエージェントを実行するために必要とするスケーリング、可用性、コンピューティングも提供します。 3 つすべての MCP サーバーに接続するために Amazon Bedrock AgentCore Gateway を使用します。エージェントを大規模にデプロイする場合、ゲートウェイはカスタムコード開発、インフラストラクチャのプロビジョニング、入出力のセキュリティ、統合アクセスなどの管理タスクを削減するために不可欠なコンポーネントです。ワークロードを本番環境に移行する際に必要な企業機能です。このアプリケーションでは、 Server-Sent Events を使用して 3 つすべての MCP サーバーをターゲットとして接続するゲートウェイを作成します。ゲートウェイは Amazon Bedrock AgentCore Identities と連携して、安全な認証情報管理とユーザーから通信エンティティへの安全な ID 伝播を提供します。サンプルアプリケーションでは、ID 管理と伝播に AWS Identity and Access Management (IAM) を使用しています。 インシデント調査は多くの場合、複数のステップからなるプロセスです。反復的な仮説検証、複数回のクエリ、時間をかけたコンテキストの構築が含まれます。会話コンテキストの維持に Amazon Bedrock AgentCore Memory を使用します。本ソリューションでは、セッションベースの名前空間を使用して、異なる調査の会話スレッドを分離しています。たとえば、調査中にユーザーが「Payment service はどうですか？」と尋ねると、エージェントはメモリから最近の会話履歴を取得して、以前の発見を認識し続けます。ユーザーの質問とエージェントの応答の両方をタイムスタンプとともに保存し、エージェントが会話を時系列で再構築し、すでに完了した発見について推論できるようにしています。 オブザーバビリティエージェントは、推論に Amazon Bedrock の Anthropic Claude Sonnet v4.5 を使用するように設定しています。モデルは質問を解釈し、呼び出す MCP ツールを決定し、結果を分析し、一連の質問または結論を策定します。システムプロンプトを使用して、モデルに経験豊富な SRE またはオペレーションセンターエンジニアのように考えるよう指示しています。「高レベルのチェックから始め、影響を受けるコンポーネントを絞り込み、テレメトリシグナルタイプ間で相関させ、根拠とともに結論を導き出す。サービス間の依存関係を調査するためのドリルダウンなど、論理的な次のステップを提案するようモデルに求める。」エージェントは一般的なさまざまなインシデント調査を分析し推論する汎用性を持ちます。 オブザーバビリティエージェントの動作 次の図のように、アプリケーション全体のリアルタイム RED (レート、エラー、期間) メトリクスダッシュボードを構築しました。 ベースラインを確立するために、エージェントに次の質問をしました。「過去 5 分間にアプリケーションでエラーは発生していますか？」エージェントはトレースとメトリクスをクエリし、結果を分析し、システムにエラーがないと応答します。すべてのサービスがアクティブで、トレースは正常で、システムはリクエストを正常に処理していると報告します。エージェントはさらなる調査に役立つ可能性のある次のステップも積極的に提案します。 障害の導入 OpenTelemetry デモアプリケーションには、システムに意図的な障害を導入するために使用できるフィーチャーフラグがあります。また、エラーが顕著に表面化するように負荷生成も含まれています。フィーチャーフラグと負荷生成を使用して、payment service にいくつかの障害を導入します。前の図のリアルタイム RED メトリクスダッシュボードは影響を反映し、エラー率の上昇を示しています。 調査と根本原因分析 エラーを生成しているので、再びエージェントを使用します。通常、調査セッションの開始です。また、アラームのトリガーやページの送信など、調査の開始をトリガーするワークフローもあります。 「ユーザーから商品の購入に時間がかかるという苦情が来ています。何が起きているか確認してもらえますか？」と質問します。 エージェントはメモリから会話履歴を取得し (存在する場合)、ツールを呼び出してサービス全体の RED メトリクスをクエリし、結果を分析します。重大な購入フローのパフォーマンス問題を特定します。payment service は接続危機にあり完全に利用不可で、fraud detection、ad service、recommendation service で極端なレイテンシーが観測されています。エージェントは即時のアクション推奨事項 (payment service の接続復旧を最優先) を提供し、payment service のログ調査を含む次のステップを提案します。 エージェントの提案に従い、ログを調査するよう依頼します。「payment service のログを調査して接続の問題を理解してください。」 エージェントは checkout と payment service のログを検索し、トレースデータと相関させ、サービスマップからサービスの依存関係を分析します。cart service、product catalog service、currency service は正常ですが、payment service は完全に到達不能であることを確認し、意図的に導入した障害の根本原因を正常に特定します。 根本原因を超えて: ビジネスへの影響分析 前述のとおり、別の MCP サーバーに合成ビジネス売上および収益データがあるため、ユーザーがエージェントに「checkout と payment service の障害によるビジネスへの影響を分析してください」と尋ねると、エージェントはビジネスデータを使用し、トレースからトランザクションデータを調べ、推定収益への影響を計算し、checkout 障害による顧客離脱率を評価します。エージェントが根本原因の特定を超えて、将来の問題解決のためのランブック作成などの運用活動を支援できることを示しています。SRE を介さない自動修復を提供するための第一歩となり得ます。 メリットと結果 本記事の障害シナリオは説明のために簡略化されていますが、MTTR の短縮に直接貢献するいくつかの主要なメリットを強調しています。 調査サイクルの高速化 トラブルシューティングの従来のワークフローでは、各ステップで仮説、検証、クエリ、データ分析の複数の反復が必要で、コンテキストスイッチングが発生し、何時間もの労力を消費します。オブザーバビリティエージェントは、自律的な推論、相関、アクションにより、調査時間を数分に大幅に短縮し、MTTR を削減します。 複雑なワークフローの処理 実際の本番シナリオでは、カスケード障害や複数のシステム障害が発生することがよくあります。オブザーバビリティエージェントの機能は、履歴データとパターン認識を使用して複雑なシナリオにも拡張できます。たとえば、時間的または ID ベースの相関、依存関係グラフ、その他の手法を使用して、関連する問題を誤検知から区別し、SRE が無関係な異常に対する無駄な調査労力を回避できるようにします。 単一の回答を提供するのではなく、エージェントは潜在的な根本原因にわたる確率分布を提供し、SRE の修復方法の優先順位付けを支援できます。例: Payment service のネットワーク接続の問題: 75% ダウンストリームの payment gateway タイムアウト: 15% データベース接続プールの枯渇: 8% その他/不明: 2% エージェントは現在の症状を過去のインシデントと比較し、過去に同様のパターンが発生したかどうかを特定できるため、リアクティブなクエリツールからプロアクティブな診断アシスタントへと進化します。 まとめ インシデント調査は依然として大部分が手動です。SRE はダッシュボードを操作し、クエリを作成し、すべてのデータがすぐに利用可能な状態であっても、プレッシャーの下でシグナルを相関させています。本記事では、Amazon Bedrock AgentCore と OpenSearch Service で構築されたオブザーバビリティエージェントが、ログ、トレース、メトリクスを自律的にクエリし、発見を相関させ、SRE をより迅速に根本原因に導くことで、認知的負担を軽減できることを示しました。本記事のパターンは 1 つのアプローチですが、Amazon Bedrock AgentCore の柔軟性と OpenSearch Service の検索および分析機能を組み合わせることで、インシデントライフサイクルのさまざまな段階で、さまざまなレベルの自律性で、または特定の調査タスクに焦点を当てて、組織固有の運用ニーズに合わせてエージェントをさまざまな方法で設計およびデプロイできます。エージェント AI は既存のオブザーバビリティへの投資を置き換えるのではなく、インシデント調査中にデータを効果的に活用する方法を提供することで増幅します。 著者について Muthu Pitchaimani Amazon OpenSearch Service の Search Specialist です。大規模な検索アプリケーションとソリューションを構築しています。ネットワーキングとセキュリティのトピックに関心があり、テキサス州オースティンを拠点としています。 Jon Handler Jon は、AWS の Search Services 担当 Director of Solutions Architecture です。カリフォルニア州パロアルトを拠点としています。OpenSearch と Amazon OpenSearch Service に密接に関わり、生成 AI、検索、ログ分析のワークロードを持つ幅広いお客様にサポートとガイダンスを提供しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。