本記事は 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 の 榎本 貴之 がレビューしました。

2025 年 12 月 、オラクル・コーポレーションと Amazon Web Services (AWS) は、日本のお客様向けに「Oracle Database@AWS」の AWS 東京リージョンでの提供を開始しました。これにより、お客様は AWS で Oracle Exadata を利用できるようになりました。 Oracle Database@AWS とは Oracle Database@AWS は、AWS データセンター内の Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャにアクセスできるサービスです。Oracle Database@AWS により、Oracle Exadata ワークロードを AWS に移行して、AWS 上で実行されるアプリケーションとの低レイテンシー接続を確立し、AWS サービスと統合することが可能になります。Oracle Database@AWSは、 Oracle Exadata Database Service on Dedicated Infrastructure または Oracle Autonomous AI Database on Dedicated Exadata Infrastructure の 2 種類をご利用可能です。 主なメリット Oracle Database@AWS をご利用頂く際の主なメリットは以下３点になります。   1. Oracle Exadata ワークロードの容易な移行 Oracle Database@AWS を使用すると、Oracle Exadata ワークロードを AWS 内の Oracle Exadata に簡単に移行できます。移行は最小限の変更で済み、機能の完全な可用性、アーキテクチャの互換性、オンプレミス Exadata デプロイメントと同じパフォーマンスを提供することが可能です。また、標準的な Oracle データベース移行ツール(Recovery Manager (RMAN)、Oracle Data Guard、トランスポータブル表領域、Oracle Data Pump、Oracle GoldenGate、AWS DMS、Oracle Zero Downtime Migration など) を使用して移行することも可能です。 2. データ統合によるイノベーション Zero-ETL 統合を使用して Oracle と AWS 全体でデータを統合し、分析、機械学習、生成 AI のためのより深いインサイトと新しいイノベーションを生み出すことができます。Amazon Bedrock を含む高度な分析、機械学習、生成 AI サービスに向けて、オラクルと AWS の間でデータを統合するZero-ETL 統合を提供します。Amazon Redshift とのZero-ETL 統合により、Oracle Database@AWS に保存されたトランザクションデータのほぼリアルタイムの分析と機械学習 (ML) が可能になります。 3. 一元化された管理と運用 Oracle と AWS 間の統合されたエクスペリエンスにより、サポート、購入、管理、運用を共同で提供することで、Oracle とAWS の統合によるベネフィットを提供します。使い慣れた AWS ツールとインターフェースを使用して、Oracle Database@AWS リソースを購入、プロビジョニング、管理でき、AWS API、CLI、または SDK を使用してリソースをプロビジョニングすることができます。また、同じ環境で実行される他の AWS サービスやアプリケーションと統合できます。例えば、モニタリング用の Amazon CloudWatch やイベント管理用の Amazon EventBridge などの AWS サービスとも統合できます。さらに、Oracle Database サービスの使用は、既存の AWS コミットメントと Oracle ライセンスベネフィット(Oracle Support Rewards など)の対象となります。 アーキテクチャ Oracle Database@AWS は、AWS データセンター内にデプロイされるマルチクラウド・データベース・サービスで、 OCI コントロール・プレーンにより一元管理されます。アクティブ/アクティブ・アーキテクチャと複数の可用性ドメインへの分散配置により障害に強く、最小権限アクセス、暗号化、継続的な監視により厳格なセキュリティを確保。AWS環境内でOracleの最高クラスのデータベース性能と信頼性を提供します。 Oracle Database@AWS の技術的な詳細、移行手順、ベストプラクティスなどについては、 AWS 公式ドキュメント をご参照ください。 まとめ Oracle Database@AWS の東京リージョンでの提供開始は、日本企業にとって大きな転換点となります。オンプレミスの Oracle 環境をクラウドに移行する際の選択肢として、既存の投資を維持しながら、クラウドの柔軟性とスケーラビリティ、Amazon Bedrock を含む高度な分析、機械学習、生成 AI サービスを利用することができます。Oracle Database@AWS への移行を検討されている方は、お気軽に AWS とオラクルの専門家にご相談ください。

本記事は 2026 年 1 月 15 日 に公開された「 From AI agent prototype to product: Lessons from building AWS DevOps Agent 」を翻訳したものです。 re:Invent 2025 で Matt Garman は、インシデントを解決し、事前に防止することで、信頼性とパフォーマンスを継続的に改善するフロンティアエージェントである AWS DevOps Agent を発表しました。DevOps Agent チームのメンバーとして、私たちは 「インシデント対応」 機能が有用な発見と観察結果を生成できるよう注力してきました。特に、ネイティブな AWS アプリケーションの根本原因分析が正確かつ効率的となるように取り組んでいます。内部的には、DevOps Agent はマルチエージェントアーキテクチャを採用しており、リードエージェントがインシデントコマンダーとして機能します。リードエージェントは症状を理解して調査計画を作成し、コンテキスト圧縮が有効なタスクは専門のサブエージェントに委任します。サブエージェントはクリーンなコンテキストウィンドウでタスクを実行し、圧縮した結果をリードエージェントに報告します。例えば、大量のログレコードを調査する際、サブエージェントはノイズをフィルタリングし、関連するメッセージのみをリードエージェントに提示します。 本記事では、実用的なエージェント製品を構築するために必要なメカニズムに焦点を当てます。大規模言語モデル (LLM) を使ったプロトタイプ構築は参入障壁が低く、動作するものを比較的早く見せられます。しかし、プロトタイプを超えて多様な顧客環境で確実に動作する製品へと進むのは全く別のチャレンジであり、過小評価されがちです。本記事では、AWS DevOps Agent の構築で学んだことを共有し、皆さん自身のエージェント開発に活かしていただければと思います。 私たちの経験では、エージェントの品質を継続的に改善し、プロトタイプから本番環境へのギャップを埋めるには 5 つのメカニズムが必要です。まず、 評価テスト (evals) を実施する必要があります。これにより、エージェントの失敗箇所と改善可能な領域を特定し、同時にエージェントが得意とするシナリオのタイプについて品質のベースラインを確立します。次に、エージェントの軌跡をデバッグし、どこで間違ったかを正確に把握するための 可視化ツール が必要です。3 つ目に、失敗したシナリオをローカルで再実行して反復できる 高速なフィードバックループ が必要です。4 つ目に、確証バイアスを避けるためシステムを変更する前に成功基準を確立する、 意図を持った変更 が必要です。最後に、定期的に 本番環境のサンプルを読んで 、実際の顧客体験を理解し、まだ評価されていない新しいシナリオを発見する必要があります。 評価 評価は、従来のソフトウェアエンジニアリングにおけるテストスイートの機械学習版です。他のソフトウェア製品と同様に、良いテストケースの蓄積が品質への信頼を築きます。エージェントの品質を反復的に改善することはテスト駆動開発 (TDD) に似ています。エージェントが失敗する評価シナリオがあり (テストが Red)、エージェントが合格するまで変更を加えます (テストが Green)。評価に合格することは、エージェントが正しい推論を通じて正確で有用な出力に到達したことを意味します。 AWS DevOps Agent では、個々の評価シナリオのサイズは、従来のソフトウェアエンジニアリングの テストピラミッド におけるエンドツーエンドテストに相当します。 “Given-When-Then” スタイルのテストの観点から見ると: Given – テストのセットアップ部分は、作成に最も時間がかかる傾向にあります。AWS DevOps Agent の評価シナリオの例として、 Amazon Elastic Kubernetes Service 上で動作するアプリケーションを考えます。複数のマイクロサービスで構成され、 Application Load Balancer をフロントに配置し、 Amazon Relational Database Service データベースや Amazon Simple Storage Service バケットなどのデータストアに読み書きし、 AWS Lambda 関数がデータ変換を行います。依存関係の深い部分で S3 への書き込みに必要な AWS Identity and Access Management (IAM) 権限を誤って削除するコード変更をデプロイして障害を注入します。 When – 障害が注入されるとアラームが発火し、AWS DevOps Agent が調査を開始します。評価フレームワークは、 DevOps Agent ウェブアプリケーション がレンダリングするのと同様に、エージェントが生成する記録をポーリングします。このセクションは、統合テストやエンドツーエンドテストでアクションを定義するのと根本的に変わりません。 Then – 複数のメトリクスを検証し、その結果をレポートします。基本的に、品質に対しては単一の “PASS” (1) または “FAIL” (0) メトリクスがあります。DevOps Agent のインシデント対応機能では、”PASS” は正しい根本原因が顧客に提示されたことを意味します。今回の例では、障害のあるデプロイを根本原因として特定し、依存関係のチェーンをたどって、影響を受けるリソースと S3 書き込み権限の不足を明らかにする観察結果を提示することです。それ以外は “FAIL” です。私たちはこれを ルーブリック として定義しています。「エージェントは根本原因を見つけたか？」だけでなく、「エージェントは正しい裏付けの証拠に基づいて正しい推論を行い、根本原因に到達したか？」を評価します。グラウンド・トゥルース (ソフトウェアテスト用語で “expected” や “wanted”) とシステムの応答 (“actual”) は LLM Judge を介して比較されます。LLM Judge とはグラウンド・トゥルースとエージェントの実際の出力の両方を受け取って、推論し、それらが一致しているか判定する LLM です。比較に LLM を使用するのは、エージェントの出力が非決定論的であるからです。つまり、エージェントは全体的には出力形式に従いますが、実際のテキストは自由に生成されるため、実行ごとに異なる単語や文構造を使用しながら同じ意味を伝える可能性があります。最終的な根本原因分析レポートではキーワードを厳密に検索するのではなく、ルーブリックの本質が満たされているかを評価したいのです。 評価レポートは、シナリオを行、メトリクスを列として構成されます。追跡する主要なメトリクスは、「能力」 (pass@k – k 回の試行で少なくとも 1 回合格したか)、「信頼性」 (pass^k – k 回の試行で何回合格したか、例えば k=3 で 3 回中 1 回合格なら 0.33)、「レイテンシー」と「トークン使用量」です。 評価が重要な理由 評価を行うことには複数の利点があります: 赤いシナリオは、エージェント開発チームが製品の品質を向上させるための明確な調査ポイントを提供します。 時間の経過とともに、緑のシナリオは回帰テストとして機能し、システムの変更によって既存の顧客体験が低下した場合に通知されます。 合格率が緑になったら、その他のメトリクスに基づいて顧客体験を改善できます。例えば、品質水準を維持しながらエンドツーエンドのレイテンシーを削減したり、コスト (トークン使用量で代用) を最適化したりできます。 評価の課題 高速なフィードバックループは、開発者がコードが機能するか (正しいか、パフォーマンスが良いか、安全か)、アイデアが良いか (主要なビジネスメトリクスを改善するか) を知るのに役立ちます。当たり前に思えるかもしれませんが、チームや組織が遅いフィードバックループを許容していることがあまりにも多いのです […] — Nicole Forsgren and Abi Noda、 Frictionless: 7 Steps to Remove Barriers, Unlock Value, and Outpace Your Competition in the AI Era 評価にはいくつかの課題があります。難易度の高い順に: 現実的で多様なシナリオの作成が難しい 。現実的なアプリケーションと障害シナリオを考え出すのは困難です。忠実度の高いマイクロサービスアプリケーションと障害を作成するには、業界経験を要する大変な作業です。効果的だと分かったのは、いくつかの「環境」(実際のアプリケーションアーキテクチャに基づく) を作成し、その上に 多くの 障害シナリオを作成することです。環境整備は評価のセットアップにおける高コストな部分なので、複数のシナリオで最大限に再利用します。 遅いフィードバックループ 。「Given」の評価シナリオのデプロイに 20 分かかり、その後「When」の複雑な調査が完了するのにさらに 10〜20 分かかるとしたら、エージェント開発者は変更内容を徹底的にテストしません。代わりに、1 回の合格した評価で満足して本番環境にリリースしてしまい、包括的な評価レポートが生成されるまでリグレッションを引き起こす可能性があります。また、フィードバックループが遅いと、小さく段階的な実験ではなく複数の変更をまとめて実施する傾向が強まり、どの変更が実際に効果をもたらしたかを把握するのが難しくなります。私たちは、フィードバックループを高速化するには3 つのメカニズムが効果的であると発見しました: 評価シナリオのための 長期稼働環境 。アプリケーションとその正常状態は一度作成され、稼働し続けます。障害注入は定期的に (例えば週末に) 行われ、開発者はエージェントの認証情報を障害のある環境に向けることで、テストの「Given」部分を完全にスキップできます。 重要なエージェント領域のみの 分離テスト 。私たちのマルチエージェントシステムでは、開発者はエンドツーエンドフロー全体を実行するのではなく、過去の評価実行からのプロンプトで特定のサブエージェントを直接トリガーできます。さらに、「フォーク」機能を構築しました。これにより開発者は、失敗した実行から特定のチェックポイントメッセージまでの会話履歴を保持した任意のエージェントを初期化して、残りの軌跡のみを反復できます。どちらのアプローチも「When」部分の待ち時間を大幅に短縮します。 エージェントシステムの ローカル開発 。開発者がテスト前に変更をマージしてクラウド環境にリリースしなければならない場合、ループが遅すぎます。ローカルで実行することで迅速な反復が可能になります。 軌跡の可視化 エージェントが評価や本番実行で失敗した場合、どこから調査を始めますか？最も生産性の高い方法は エラー分析 です。エージェントの完全な軌跡、つまりサブエージェントの軌跡を含むユーザー・アシスタント間のすべてのメッセージ交換を可視化し、各ステップに “PASS” または “FAIL” の注釈をつけ、何が間違っていたかメモを残します。このプロセスは面倒ですが効果的です。 AWS DevOps Agent では、エージェントの軌跡は OpenTelemetry トレースにマッピングされ、 Jaeger などのツールで可視化できます。 Strands などのソフトウェア開発キットは、最小限のセットアップでトレース統合を提供します。 図 1 – AWS DevOps Agent のサンプルトレース 各スパンにはユーザー・アシスタントのメッセージの組み合わせが含まれています。各スパンの品質を次のような表で注釈付けします: このローレベルの分析は、1 つだけでなく複数の改善点を一貫して明らかにします。1 つの評価が失敗すると、一般的に精度、パフォーマンス、コストにまたがる多くの具体的な変更点を特定できます。 意図を持った変更 私は父から意図を持って行うこと、すなわち自分が何をしようとしているのかを知り、すべての行動がその目標に向かっていることを確認すること、その重要さを学びました。— Will Guidara、 Unreasonable Hospitality: The Remarkable Power of Giving People More Than They Expect 失敗したシナリオを特定し、軌跡の分析を通して問題を診断しました。さぁ、システムを修正する時です。 この段階で最もよく見られる誤信:   過学習 につながる 確証バイアス です。前述の評価上の課題 (遅いフィードバックループと包括的なテストスイートの非現実性) を考えると、開発者は通常、合格するまでいくつか特定の失敗シナリオのみをローカルでテストします。より広範な影響を考慮せずに、1 つか 2 つのシナリオが合格するまでコンテキスト (システムプロンプト、ツール仕様、ツール実装など) を修正してしまいます。変更がコンテキストエンジニアリングのベストプラクティスに従っていないと、限られた評価では捉えられない悪影響が生じる可能性が高いです。 勤勉さと判断力の両方が求められます: 利用可能な評価と再利用可能な過去の本番環境でのシナリオを通して成功基準を確立するだけでなく、変更の指針となるコンテキストエンジニアリングのベストプラクティスを学んでください。Anthropic の プロンプティングベストプラクティス と エンジニアリングブログ 、Drew Breunig の “How Long Contexts Fail” 、 Manus 構築からの教訓 は特に参考になりました。 まず成功基準を確立する 変更を加える前に、成功とはどのようなものかを定義します: ベースライン: 現在のシステムに特定の git コミット ID を固定します。どのメトリクスが エージェントの体験 と顧客の体験の両方を改善するのかを慎重に検討し、それらをベースラインのメトリクスとして収集します。 テストシナリオ: どの評価で変更の影響を測定しますか？評価を何回再実行しますか？このテストセットが、調査している 1 つの失敗だけでなく、より広い顧客のパターンを代表していると確信を持ってください。 比較 : 同じメトリクスを使用して、ベースラインに対しての変更を測定します。 意図を持ったフレーミングにより、確証バイアス (結果を好意的に解釈する) とサンクコストの誤謬 (時間を費やしたという理由だけで変更を受け入れる) を避けられます。修正してもメトリクスが期待通りに動かない場合は、却下してください。 例えば、AWS DevOps Agent 内の サブエージェント を最適化する際、git コミット ID を固定し、同じシナリオを 7 回実行してベースラインを確立します。これにより、典型的なパフォーマンスと分散の両方が明らかになります。 各メトリクスは異なる側面を測定します: Correct observations – インシデントに直接関連する 関連 シグナル (ログレコード、メトリクスデータ、コードスニペットなど) をサブエージェントはいくつ提示したか？ Irrelevant observations – サブエージェントはリードエージェントにどれだけの ノイズ をもたらしたか？インシデントに無関係で、エージェントの調査を妨げる可能性のあるシグナルをカウントします。 Latency – サブエージェントはどのくらい時間がかかったか (分と秒で測定)？ Sub-agent tokens – サブエージェントはタスクを達成するのにどれだけのトークンを消費したか？サブエージェント実行コストの代理メトリクスとして機能します。 Lead-agent tokens – サブエージェントの入出力はリードエージェントのコンテキストウィンドウをどれだけ消費しているか？サブエージェントツールの最適化機会を具体的に特定できます。つまり、サブエージェントへの指示や返答結果を圧縮できるか？ということです。 ベースラインを確立した後、提案した変更に対して同じ測定値を比較します。これによって変更によって実際改善したかどうかが明確になります。 本番環境のサンプルを読む 幸運なことに、複数の Amazon のチームが AWS DevOps Agent を早期に採用してくれました。DevOps Agent チームのメンバーは、軌跡の可視化ツール (前述の OpenTelemetry ベースの可視化に似ていますが、根本原因分析レポートや観察結果などの DevOps Agent 固有のアーティファクトをレンダリングするようカスタマイズされています) を使用してローテーションで実際の本番実行を定期的にサンプリングし、エージェントの出力が正確であったかどうかをマークし、失敗したポイントを特定します。本番環境のサンプルは替えの効かないものです。実際の顧客体験を明らかにします。さらに、サンプルを継続的に確認することで、エージェントが得意なことと苦手なことの直感が磨かれます。本番実行が満足のいくものでない場合に反復するための実際のシナリオを持っています。エージェントをローカルで修正し、望ましい結果が得られるまで同じ本番環境に対して再実行してください。このような方法に協力してくれる重要なアーリーアダプターなチームとの信頼関係を築くことは非常に価値があります。彼らは迅速な反復のためのグラウンド・トゥルースを提供し、新しい評価シナリオを特定する機会を生み出します。本番データでの緊密なフィードバックループは、評価駆動開発と連携して機能し、包括的なテストスイートを形成します。 おわりに 現実のビジネス課題を解決できることを示すようなエージェントプロトタイプを構築することは、エキサイティングな第一歩です。より困難なのは、プロトタイプを様々な顧客環境とタスクにわたって確実に機能する製品に昇格させることです。本記事では、エージェントの品質を体系的に改善するための基盤となる 5 つのメカニズムを共有しました: 現実的で多様なシナリオでの評価、高速なフィードバックループ、軌跡の可視化、意図を持った変更、本番環境のサンプリングです。 エージェントアプリケーションを構築しているなら、今日から評価スイートの構築を始めてください。ほんの一握りの重要なシナリオから始めるだけでも、体系的に測定・改善するために必要な品質のベースラインを確立できます。AWS DevOps Agent がインシデント対応にこれらの原則をどのように適用しているかについては、 入門ガイド をご覧ください。 翻訳はソリューションアーキテクトの大西朔が担当しました。原文は こちら です。 著者について Efe Karakus AWS DevOps Agent チームのシニアソフトウェアエンジニアで、主にエージェント開発を担当しています。

みなさん、こんにちは。ソリューションアーキテクトの稲田です。 2026 年 1 月 22 日〜23 日の 2 日間、AWS Loft Tokyo にて「合同 AI-DLC Unicorn Gym」を開催しました。日立産業制御ソリューションズ、三菱電機ビルソリューションズ、パナソニックエレクトリックワークス、DNP、TOPPAN、すかいらーく、JR東海、JTB、アルプスアルパイン、第一三共、しまうまプリント（順不同）の 11 社から計 87 名のエンジニア・ビジネスパーソンが集まり、AI による開発プロセスの変革を体験していただきました。 AI 駆動開発ライフサイクル (AI-Driven Development Lifecycle, AI-DLC) とは AI 駆動開発ライフサイクル (AI-Driven Development Lifecycle, AI-DLC) は、AI を開発プロセスの中心に据えた新しい開発手法です。従来のソフトウェア開発手法は人間主導の長期的なプロセスとして設計されており、計画や会議などの本質的ではない活動に多くの時間が費やされてきました。AI をアシスタントとして単純に後付けするだけでは、その能力を制約し、時代遅れの非効率性を助長することにもなりかねません。 AI-DLC では「AI が実行し人間が監視する」というアプローチを取ります。AI が体系的に詳細な作業計画を作成し、積極的に意図のすり合わせとガイダンスを求め、重要な決定は人間に委ねます。ビジネス要件の文脈的理解と知識を持つのは人間だからです。そして、チームはリアルタイムでの問題解決、創造的思考、迅速な意思決定のために協力します。この孤立した作業から活気のあるチーム作業への転換が、イノベーションと成果物の提供を加速させます。 2 日間で何が起きたか 各社はエンジニア 4〜6 名、ビジネスサイド 2 名の計 6〜8 名でチームを構成して参加しました。ビジネスとエンジニアが一体となって取り組むことが、AI-DLC の効果を最大化するポイントです。 1 日目は「Inception（開始）」フェーズ。午前中は AI-DLC の概要説明とチーム編成を行い、午後から本格的に Inception に取り組みました。各社が持ち寄ったテーマについて、AI がビジネス意図を詳細な要件、ストーリー、ユニットに変換していきます。これを「モブエラボレーション」と呼ばれる形式で進め、チーム全体が AI の質問や提案を積極的に検証しました。ビジネス担当者とエンジニアが同じ画面を見ながら議論することで、「何を作るのか」についての共通理解が深まっていきました。 ＊エラボレーション（精緻化）: 学習中の新しい情報を既存の知識と関連付けていくことで、新たにインプットしている情報に詳細を付け加えていくプロセスのことです。エラボレーションのプロセスでは What (何を) 学習しているかよりも、学習中のトピックの背後にある How (どのように) や Why (なぜ) により重きを置きます。 第一三共チームの開発風景 2 日目は「Construction（構築）」フェーズ。朝から夕方まで集中的に実装に取り組みます。前日に固めた要件をもとに、AI が設計、コード、テストを提案します。「モブコンストラクション」を通じて、チームが技術的決定とアーキテクチャの選択についてリアルタイムで明確化していきました。17 時からは各社が成果を発表し、2 日間の学びを共有しました。発表会の後は懇親会。異なる業界のエンジニア同士が、AI 駆動開発の可能性について熱く語り合う姿が印象的でした。 三菱電機ビルソリューションズチームの開発風景 参加者が達成したこと 2 日間のワークショップで、数週間から数ヶ月を想定していた開発を完了させる成果が生まれました。 ある企業は IT 資産管理システムの開発に取り組み、フロントエンド、バックエンド、ダッシュボード構築を並行して進め、AWS 環境へのデプロイまで完了。当初 8 週間を想定していた開発が 2 日間で完了しました。 別の企業は、行動変容を促すサービスの PoC 用アプリケーションを開発。認証、アカウント登録、データ収集、通知機能を含む Web アプリを 2 日間で構築しました。 IoT センサデータを分析するクラウドシステムに取り組んだ企業は、UI とバックエンド API の連携まで 2 日間で完了。当初 6 ヶ月を想定していた内容でした。 金融機関向けシステムの更改に取り組んだ企業では、「要件定義のドキュメント化に 1 ヶ月近く、10 人弱で会議を重ねていた工程が、6 人で 2 日間に短縮された」という声がありました。 特筆すべきは、ある企業の部長職の方が 2 日間フルで参加し、自ら AI ツールをインストールしてプロダクト開発に取り組んだ事例です。マネジメント層が現場と同じ体験を共有することで、AI 駆動開発の価値を実感として理解できたと語っていました。 パナソニックエレクトリックワークスチームの開発風景 参加者の声 「システム開発に産業革命のような大きなインパクトを与えると感じた」 「パラダイムシフトを感じることができました」 「ビジネスサイドとの密なコミュニケーションで手戻りが大幅に減少した」 「会話を中心にプロジェクトを進めることが新鮮で、とても楽しく学びのある研修になりました」 イベント後のアンケートでは、満足度は 5 点満点中 4.56 点、98.8% の参加者が肯定的な評価を寄せました。そして 92.5% が継続的なフォローアップを希望しており、この 2 日間が「終わり」ではなく「始まり」として受け止められたことがわかります。 一方で、実務適用に向けた課題も見えてきました。最も多く挙がったのはセキュリティ・コンプライアンスに関する懸念です。社内のセキュリティ統制や、個人情報・機密情報の取り扱いをどうするか。また、既存の社内制度や承認プロセスとの整合をどう取るかという声もありました。AI が生成したコードのレビュー体制についても、「レビューする側の知識が追いつかない」という指摘がありました。これらは AI-DLC の導入が単なる技術導入ではなく、組織文化と制度の変革を伴うものであることを示しています。 しまうまプリントチームの開発風景 これからの展開 AI-DLC は AI をうまく使うための方法ではありません。多くのお客様が語っている通り、AI-DLC は AI によって人と人のコミュニケーションをより活発に、円滑にします。これまでのソフトウェア開発において、最もボトルネックになっていたのは人間同士の認識合わせ、見解の調整とそのための準備（認識合わせのための詳細なドキュメンテーションや断続的な複数の会議、複数回のレビューによるゲートウェイなど）でした。これは、人間がアウトプットを担当する限り、書類などの準備にかかる時間があるために解決できない問題でした。AI はこれを変革します。AI のアウトプットの速さは関係者を一か所に集めた上でその場で意思決定のためのアウトプットを作成することを可能にします。これによって、ボトルネックが解消し、チームの意思決定の速度が劇的に向上します。 AI-DLC は特定のツールに依存した方法論ではないことも重要です。AI ツールの進化は早くそれはこれからより加速するでしょう。1 年後に皆さんがどのような AI ツールを利用しているかは誰にも予想できません。しかし、ツールだけでは真の課題は解決できないこともわかっています。AI による変革を実現するためにはみなさんの働き方そのものを変える必要があります。AI-DLC はウォーターフォールやアジャイルのようなソフトウェア開発の方法論を update し AI による変革を実現するためのガイドラインです。 今回の合同 AI-DLC Unicorn Gym をきっかけに多くの参加企業の方々がそれぞれの企業の文化やビジネスに合った形でのAIによる開発方法の変革を実現されると信じています。AWSはこれからもそれを支援し、また業界全体の発展のためにもそれぞれの発見や学びを共有できる機会を提供していきたいと考えています。 AI-DLC に興味を持たれた方は、ぜひ  aidlc-workflows をチェックしてみてください。Kiro を使って AI-DLC を始めるためのワークフローやテンプレートが公開されています。

Amazon CloudWatch Logs は AWS 環境におけるログ管理の中心的なサービスとして、様々なソースからのログデータを収集、監視、分析する機能を提供しています。一方で、長期保存のコスト最適化やサードパーティのログ分析ツールとの連携など、様々な理由からログデータを CloudWatch Logs から他の場所に転送する必要が生じることがあります。 本記事では、CloudWatch Logs からログを転送する必要が生じるユースケースと、AWS が提供する3つの転送方法について詳細に説明します。それぞれの方法の特徴、制限事項、そして適用シナリオについて解説していきます。 本記事ではログの取得方法について解説します。メトリクスの取得については Amazon CloudWatch からテレメトリデータを取得する：メトリクス編 をご参照ください。 はじめに ログの取り出し方法を説明する前に、まず AWS 上で稼働するサービスのログ発行の特徴について解説します。 AWS 環境では、図1に示すようにログの収集経路が大きく2つあります。 AWS マネージドサービスが発行するログ ALB、Amazon Route 53、Amazon S3、Amazon RDS、AWS Lambda など、多くのマネージドサービスは標準で Amazon CloudWatch にログを送信します。この方法ではログ収集のためのコードや特別な処理を組む必要がないため、実装工数が少なくて済むというメリットがあります。 ただし、一部のサービスは CloudWatch ではなく Amazon S3 や Amazon Data Firehose に直接ログを送信する場合があります。利用するサービスのログ出力先は、こちらの ドキュメント にまとめられています。 OS レイヤーや独自アプリケーションのログ EC2 の OS ログや、開発したアプリケーション内部のログなどは、デフォルトでは自動収集されません。 収集するには設定が必要であり、最も簡単な方法は Amazon CloudWatch エージェント（統合エージェント）を導入し、CloudWatch に送信する構成です。 では、次に Amazon CloudWatch に収集されたログを取り出す手段について解説していきます。 図1. AWS におけるログの種類 CloudWatch Logs からログを転送する方法 ここから本ブログの主題であるログを転送するため3つの方法をご紹介します。 1 : サブスクリプションフィルターを用いる方法 サブスクリプションフィルター とは、CloudWatch Logs に記録されたログをリアルタイムに他のサービスに配信をする仕組みです。名前の通りフィルターなので、特定のパターンにマッチするものだけを配信や、すべてのログの配信が可能です。配信先は「 Amazon Kinesis Data Streams 」「 Amazon Data Firehose 」「 AWS Lambda 」「 Amazon OpenSearch Service 」が選択可能で、 ロググループレベル で設定する方法と、 アカウントレベル で設定する方法があります。アカウントレベルで設定すれば、ロググループ一つずつにサブスクリプションフィルターを設定する必要がないという利点があります。 フィルターの種類に悩まれる方も多いかと思いますが、まずは、Amazon Data Firehose の検討から進めることをおすすめします。Amazon Data Firehose の配信先には Amazon S3 をはじめとする AWS サービスや、サードパーティの監視ソリューションに直接配信も可能です。詳細については、 ドキュメント をご覧ください。 2 : CloudWatch のエクスポート機能 エクスポートとは、CloudWatch Logs のログデータを Amazon S3に エクスポートする機能 です。「単一のロググループ」「開始日時（ミリ秒単位）」「終了日時（ミリ秒単位）」を指定し、エクスポートタスクを CLI や AWS Systems Manager 経由で作成し、非同期で実行します。ログデータのエクスポートが開始されるまで最大 12 時間かかる場合があり、またエクスポートタスクは 24 時間でタイムアウトするため、タスクが失敗する場合はエクスポート指定区間を短くする必要があります。また、アカウントごとにアクティブなエクスポートタスクは 1 つだけという クォータ があり、複数のロググループを並列でエクスポートできない点に注意が必要です。 3 : API を用いる方法 API を経由の取得を正確に理解するために、CloudWatch Logs のログデータの格納方法とその名称を整理しましょう。 ロググループ ├── ログストリーム1 │ ├── ログイベント1 │ ├── ログイベント2 │ └── ログイベント3 ├── ログストリーム2 │ ├── ログイベント1 │ └── ログイベント2 └── ログストリーム3 └── ログイベント1 CloudWatch Logs は、 ロググループ 、 ログストリーム 、 ログイベント の ３層構造でログデータ を管理します。 ログイベント は、モニタリングされているアプリケーションまたはリソースによって記録されたアクティビティのレコードで、タイムスタンプと生のイベントメッセージの 2 つのプロパティを持ちます。 ログストリーム は、同じソースを共有する一連のログイベントで、モニタリングされているアプリケーションインスタンスやリソースから送信された順序でイベントを表します。ストリームの分割単位は送信元のサービスによって異なります（例：EC2 ではインスタンスごと、Lambda では関数の実行ごと）。 ロググループ は、保持、監視、アクセス制御について同じ設定を共有するログストリームのグループを定義し、各ログストリームは必ず 1 つのロググループに属する必要があります。 AWS マネージドサービスがログを自動生成する場合は、この構造を深く意識する必要はありません。しかし、API 経由でログデータを取得する際には、この 3 層構造を意識する必要があります。 では、改めてCloudWatch Logs が提供している、ログを取り出す API を紹介いたします。 GetLogEvents 指定したログストリームからログイベントを一覧表示する API です。すべてのログイベントを一覧表示したり、時間範囲を使用してフィルタリングが可能です。 この API の主な用途は、特定のログストリームからのログイベント取得です。そのため、ロググループ全体を指定したログの取得はできません。 FilterLogEvents 複数のロググループやログストリームにわたってログを検索・フィルタリングできます。より高度な検索機能を提供する API です。 この API の主な用途は、複数のロググループを対象にしたログイベントの取得です。 StartLiveTail リアルタイムにログを取得できる API です。マネジメントコンソール経由で利用できる Live Tail を API 経由で利用できます。 tail -f コマンドのようにリアルタイムでログをストリーミング取得することが可能です。 この API の主な用途は、リアルタイムに CloudWatch Logs へ取り込まれたログの確認です。 これらの API には多くの制限があるため、使用する際にはそれらを意識する必要があります。 まず、GetLogEvents と FilterLogEvents には共通して「最大 1 MB のログイベント、または最大 10,000 件のログイベント」のみが含まれるという制限が存在しています。いずれかの制限を超えるような場合は、nextToken が返却されます。 大量のログデータを取得する際は、このページング機能を使用する必要があります。具体的には、API レスポンスに含まれる nextToken を次のリクエストのパラメータとして指定し、nextToken の出力が空になるまで繰り返し API を呼び出します。これにより、制限を超えるログデータを段階的に取得できます。以下の表は、この制限がどのように適用されるかを示した例です。パターン 1 のように両方の制限内に収まる場合は 1 回で取得が完了しますが、パターン 2〜4 のようにいずれかの制限を超える場合は、nextToken が返却され、ページングが必要になります。 パターン ログイベントサイズ ログイベント件数 結果 1 0.8 MB 7,000 1回で取得完了 2 1.2 MB 15,000 ログデータの一部とnextToken の返却 (サイズ超過) 3 0.5 MB 20,000 ログデータの一部とnextToken の返却 (件数超過) 4 1.5 MB 5,000 ログデータの一部とnextToken の返却 (両方超過) ただし、nextToken が空であるからといって、すべてのログを取り出したことを保証していません。たとえば、直近のログは API での取得が終了した後に CloudWatch Logs に登録される可能性があるからです。そのため、リアルタイムに近いログを継続的に取得したい場合は、定期的に API を呼び出すか、StartLiveTail API の使用を検討してください。 また、これらの API には呼び出し数に関しても クォータ が存在します。2026 年 1 月現在、バージニア北部リージョンであっても、GetLogEvents/FilterLogEvents は 1 秒あたり 25 リクエストの制限があるため、同時に呼び出しが想定される場合は注意が必要です。 ログの取り出しが必要となるユースケース CloudWatch Logs からログを取り出す手段について理解できたところで、次に実際の活用場面を見ていきましょう。以下では、ログの取り出しが必要となる代表的なユースケースを 3 つご紹介します。 ユースケース① 長期保存要件のあるログのコスト最適化 【活用する方法：サブスクリプションフィルター、エクスポート機能】 多くの組織では、コンプライアンスやガバナンス要件に基づいて、ログデータを 5 年や 7 年といった長期間保存する必要があります。このような場合、保存コストの最適化が重要な課題となります。 CloudWatch Logs では、アクセス頻度に応じて 2 つのストレージクラスを選択できます。標準ストレージクラスの保存料金は、東京リージョンで USD 0.033/GB（月額）です。一方、アクセス頻度の低いログには Infrequent Access (IA) ストレージクラスを利用でき、保存料金は USD 0.011/GB（月額）と、標準ストレージクラスの約 3 分の 1 のコストで保存できます。ただし、IA ストレージクラスではデータスキャン料金（USD 0.0055/GB）が発生するため、頻繁にクエリを実行するログには適していません。また、 IA ストレージクラスのログ は S3 へのエクスポート機能を利用できない点にも注意が必要です。 さらにコストを削減したい場合は、Amazon S3 へのエクスポートも検討できます。Amazon S3 スタンダードストレージの料金は USD 0.025/GB です。この差額は一見小さいものの、ログデータの量が増加し保存期間が長くなるにつれ、コスト差は拡大していきます。加えて Amazon S3 の場合はストレージクラスの変更が可能であり、Glacier Deep Archive を利用すると USD 0.002/GB まで料金を削減できます。 以下の表は、1 TB のログデータを 5 年間保存した場合のコスト比較例です。 ストレージ 月額料金（USD/GB） 5年間の総コスト（1TB） CloudWatch Logs 標準 0.033 USD 1,980 CloudWatch Logs IA 0.011 USD 660 Amazon S3 スタンダード 0.025 USD 1,500 Amazon S3 Glacier Deep Archive 0.002 USD 120 この表からわかるように、アクセス頻度の低いログであれば CloudWatch Logs IA を利用することで、CloudWatch Logs 内でクエリ機能を維持しながらコストを削減できます。さらに長期保存でほとんどアクセスしないログの場合は、S3 Glacier Deep Archive を利用することで大幅なコスト削減が可能です。 また、「最初から S3 に配信する」という手段も考えられますが、その場合はログのクエリに Amazon Athena などの別の仕組みを用いる必要があります。一般的にログの検索においては、CloudWatch Logs Insights の方が高機能であるという利点があります。そのため、直近のログは CloudWatch Logs で保持してクエリを実行し、一定期間経過後に S3 にエクスポートするといったハイブリッドなアプローチも有効です。 ユースケース② サードパーティソリューションとの連携 【活用する方法：サブスクリプションフィルター】 今日の IT 業界には CloudWatch 以外にも様々な特徴を持つ監視ソリューションが多くのベンダーから提供されています。組織で既に監視ソリューションが指定されていたり、CloudWatch にはない機能が必要になった場合は、それらのサービスにログを転送する必要があります。 多くのサードパーティソリューションでは、テレメトリを収集し、直接サードパーティサービスに送信するエージェントを提供しています。ただし、AWS には CloudWatch や S3 経由でしか取得できないログが存在しています。これらは CloudWatch からの転送操作が必要です。 ユースケース③ カスタムアプリケーションからの参照 【活用する方法：API（GetLogEvents、FilterLogEvents、StartLiveTail）】 ローカルのコマンドラインで一時的にログを参照したり、LLM アプリケーションでのログ検索や独自の運用ツールでログデータを活用したいケースが考えられます。例えば、「過去 1 週間のエラーログを要約して」といった自然言語でのログ分析や、チーム独自のダッシュボードでリアルタイムログ監視を行いたい場合です。 また、障害調査時に開発者がローカル環境で柔軟にログを検索・分析したり、特定のビジネスロジックに基づいた独自のアラート機能を構築したいといったニーズもあります。さらに、既存の社内ツールやワークフローにログデータを組み込んで、より効率的な運用を実現したい場合もあるでしょう。 このユースケースでは、CloudWatch Logs API を使用してプログラムからログデータを取得します。特定のログストリームから取得する場合は GetLogEvents、複数のロググループを横断して検索する場合は FilterLogEvents、リアルタイムでログを監視する場合は StartLiveTail を使用します。これらの API を活用することで、柔軟なログ活用が可能になります。 まとめ 記事では、Amazon CloudWatch Logs からログデータを転送する 3 つの主要な方法について解説しました。 サブスクリプションフィルター ：リアルタイムでのログ転送に適しており、サードパーティソリューションとの連携や S3 への継続的な転送に活用できます エクスポート機能 ：過去の特定期間のログを S3 にまとめて転送する際に適しており、長期保存のためのコスト最適化に有効です API（GetLogEvents、FilterLogEvents、StartLiveTail） ：カスタムアプリケーションからの柔軟なログ取得に適しており、独自の運用ツールやダッシュボードの構築に活用できます 手段を選択する際は、以下の観点から総合的に判断することが重要です。 リアルタイム性の要否 転送するログの量と頻度 コストとパフォーマンスのトレードオフ 既存システムとの連携要件 適切な手法を選択することで、運用コストの削減と機能性の向上を両立した、効率的なログ管理戦略を実現できます。各手段の詳細については、AWS ドキュメントも併せてご参照ください。 著者 伊藤 威 アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト

CloudWatch メトリクス を活用することで、システムの状態を可視化し効果的な監視を実現できます。 CloudWatch メトリクスには保存期間の制限があり、また外部の監視ツールと連携したいケースも多く存在するため、 CloudWatch メトリクスを外部に転送して活用するニーズが高まっています。 本記事では、CloudWatch メトリクスの基本的な概念を押さえた上で、メトリクス転送が必要となるユースケースと、AWS が提供する 2 つの転送方法について、それぞれの特徴や使い分けのポイントを詳しく見ていきましょう。 本記事ではメトリクスの取得方法について解説します。ログの取得については Amazon CloudWatch からテレメトリデータを取得する：ログ編 をご参照ください。 はじめに CloudWatch メトリクスの転送方法を詳しく考える前に、CloudWatch メトリクスについて解説します。 CloudWatch メトリクスは、CPU 使用率やメモリ使用量といったパフォーマンス測定値を時系列データとして収集します。各メトリクスは AWS/EC2 や AWS/RDS といった名前空間で分類され、さらに、インスタンス ID やインスタンスタイプなどのディメンション（名前と値のペア）で一意に識別されます。 収集したデータは、合計、最大値、最小値、平均値といった統計値として集計できます。データポイントの集計間隔は期間（Period）として設定でき、1 分、5 分、1 時間など必要に応じて選択可能です。 CloudWatch メトリクスの転送が必要となるユースケース CloudWatch メトリクスの転送が必要となる、具体的なユースケースを 3 つご紹介します。 1 . メトリクスの長期保存を行いたい CloudWatch メトリクスのデフォルトの保存期間はデータポイントの粒度によって異なり、次のようにメトリクスデータを保持します。 60 秒未満のデータポイント: 3 時間 1 分間隔のデータポイント: 15 日間 5 分間隔のデータポイント: 63 日間 1 時間間隔のデータポイント: 455 日間（約 15 ヶ月） 注意すべき点は時間が経過するとデータの解像度が自動的に低下することです。たとえば、1 分間隔でデータを収集した場合、最初の 15 日間は 1 分間の解像度で利用できますが、15 日を過ぎると 5 分間隔に集約されます。さらに 63 日を過ぎると 1 時間間隔に集約されます。455 日を超えて保持したい場合や、元の解像度を維持したまま長期保存したい場合は、 Amazon S3 などの外部ストレージにエクスポートする必要があります。 2. サードパーティー監視ツールとの連携を行いたい AWS 以外のクラウドプロバイダーやオンプレミス環境も含めた統合監視のために Datadog、New Relic、Grafana、Splunk などのサードパーティ監視ツールを利用することがあります。こうした環境で AWS のメトリクスも統合して監視したい場合、 CloudWatch メトリクスの転送が必要になることがあります。 3. 詳細な分析を行いたい 取得したメトリクスを使用して、組織固有のニーズに応じた詳細な分析を行いたい場合、メトリクスの転送が必要になる場合があります。 コスト最適化分析 : 長期間のリソース使用率データを分析し、コスト最適化の機会を特定 トレンド分析 : 数年にわたるメトリクスデータを保持し、長期的なトレンドを分析 機械学習モデルの構築 : 過去のメトリクスデータを使用して予測モデルを構築 CloudWatch メトリクスを転送する方法 この章では、Cloudwatch メトリクスを転送する 2 つの方法をご紹介します。 APIポーリングを使用する方法 CloudWatch Metric Streams を使用する方法法 1. API ポーリングを使用する方法 CloudWatch API を定期的にポーリングしてメトリクスデータを取得する方法です。 GetMetricData API または GetMetricStatistics API を使用し、AWS CLI、AWS SDK、または直接 API 呼び出しで実装できます。データの出力形式は JSON です。 この方法では、CloudWatch のデータ保持期間内であれば任意の過去のメトリクスデータを取得できます。 GetMetricData API GetMetricStatistics API のちがい GetMetricData を使用すると、データをより高速かつ大規模に取得できるため、GetMetricStatistics ではなく GetMetricData API を使用するのがベストプラクティスです。GetMetricData はメトリクス計算サポートしています。 GetMetricData API は、データをより高速かつ大規模に取得できます。1 回のリクエストで最大 500 のメトリクスを取得でき、Metric Math（メトリクス計算式）を使って統計情報を表示できるほか、順序付けされページ分割された結果を返します。 一方、GetMetricStatistics API は、少量のメトリクスを取得する場合に適しています。AWS 無料利用枠に含まれ、月間 100 万リクエストまで無料で利用できます。 詳細については、 API を使用して CloudWatch メトリックスからデータポイントを取得する を参照してください。 料金 GetMetricData API と GetMetricStatistics API では料金体系が異なる点にご注意ください。 GetMetricStatistics API: GetMetricStatistics API は通常の CloudWatch API リクエストと同じ料金体系で、AWS 無料利用枠に含まれま す。月間 100 万リクエストまで無料で、無料利用枠を超過すると課金されます。無料利用枠を超過すると1,000 リクエストあたり USD 0.01 の料金が発生します。(東京リージョン) GetMetricData API: GetMetricData API は AWS 無料利用枠の対象外で、最初のリクエストから課金され、1,000 個のメトリクスリクエストあたり 0.01 USD の料金が発生します。 単一のリクエストで同じメトリクスについて最大 5 つの統計を取得でき、5 つを超える統計は追加のメトリクスリクエストとして課金されます。例えば、1 つのメトリクスについて 9 つの統計をリクエストすると、2 つのメトリクスリクエストとして課金されます。(東京リージョン) 料金の詳細や最新情報については、 Amazon CloudWatch 料金ページ を参照してください。 2. CloudWatch Metric Streamsを使用する方法 CloudWatch Metric Streams を利用してCloudWatch メトリクスを転送することができます。 CloudWatch Metric Streams は、最小限のセットアップと設定でユーザーが希望する送信先に継続的にストリーミングする機能です。フルマネージド型のソリューションで、コードを書いたりインフラを維持したりする必要はありません。 CloudWatch Metric Streams を使用することで、API ポーリングを行うことなく CloudWatch からメトリクスデータを取得できます。Amazon S3 などのデータレイクなどにメトリクスを簡単に転送し、 Amazon Athena などのツールで使用状況やパフォーマンスの分析を開始できます。また、 Amazon Data Firehose の HTTP エンドポイントを使用して、CloudWatch メトリクスをサードパーティサービスプロバイダーに送信することも容易になります。 過去 3 日以上前に公開されたメトリクスはストリーミングされません。メトリクスがストリーミングされるかどうかを判断するには、CloudWatch コンソールでメトリクスをグラフ化して、表示される最新のデータポイントの時間を確認してください。3 日以上経過している場合、CloudWatch Metric Streams で取得されません。 料金 CloudWatch Metric Streams の料金は、更新されたメトリクスの件数に基づきます（東京リージョンでは 1,000 メトリクス更新あたり 0.003 USD）。メトリクスの更新には、4 つのデフォルト統計（最小、最大、サンプル 数、合計）が含まれます。加えて、Data Firehose の料金も課金されます。 不要なメトリクスをフィルタリングしないとコストが高額になる可能性があります。各メトリクスストリームに は最大 1,000 個のフィルターを設定できるため、必要なメトリクスのみをストリームに含めるようフィルター を設定してください。 CloudWatch Metric Streams の作成方法 CloudWatch Metric Streams は、CloudWatch コンソールを通じて、または CloudWatch API、AWS SDK、AWS CLI、AWS CloudFormation を使用してプログラムで作成・管理できます。サードパーティサービスプロバイダーが提供する AWS CloudFormation テンプレートを使用して、サードパーティーの宛先へのMetric Streamsの配信を設定することもできます。 主なセットアップ方法を 3 つご紹介します。  1. Amazon Data Firehose を使用したカスタムセットアップ CloudWatch Metric Streams を使用して、Amazon Data Firehose 配信ストリームに転送できます。Amazon S3 などデータレイクや、Firehose がサポートする任意の宛先やサードパーティープロバイダーのエンドポイントにストリーミングできます。 出力形式 JSON、OpenTelemetry 1.0.0、 OpenTelemetry 0.7.0 をネイティブに提供し、Firehose 配信ストリームで変換を設定することでParquet 形式などの別の形式にも変換できます。 2. クイック S3 セットアップ JSON、OpenTelemetry 1.0.0、OpenTelemetry 0.7.0 以外の形式に変換する必要がない場合は、クイック S3 セットアップの方法を使用することで Amazon S3 へのストリームを素早くセットアップ可能です。CloudWatch は、Firehose 配信ストリームや必要な IAM ロールなど、必要なすべてのリソースを作成します。 出力形式 JSON、 OpenTelemetry 1.0.0、 OpenTelemetry 0.7.0 3. クイックパートナーセットアップ CloudWatch では一部のサードパーティーパートナー向けとしてクイックセットアップのオプションを提供しています。CloudWatch は、Firehose 配信ストリームや必要な IAM ロールなど、必要なすべてのリソースを作成します。 クイックパートナーセットアップを使用してメトリクスストリームを作成する前に、ドキュメントに記載されたリンクから各パートナーの ドキュメント を読むことを強くお勧めします。 詳しい実装方法は ドキュメント をご覧ください。 フィルターの作成方法 メトリクスを転送する際には、 [すべてのメトリクス] または [メトリクスを選択] のどちらかを選択します。 [すべてのメトリクス] の場合、アカウントのすべてのメトリクスがストリームに含まれます。ストリーミングする料金が多いほど、CloudWatch Metrics Stream, Amazon Data Firehose の料金が高くなるため注意してください。 [メトリクスを選択] の場合、以下のいずれかによってストリーミングするメトリクスを選択します。 必要なメトリクスのみを転送することでコスト最適化を行うことができます。 [Exclude] : ほとんどの名前空間のメトリクスをストリーミングし、特定の名前空間またはメトリクスを除外 [Include] : 特定の名前空間またはメトリクスのみをストリーミング 統計について CloudWatch Metrics Streams には、デフォルトで Minimum、Maximum、SampleCount、 Sum の4つの統計データが含まれます。CloudWatch Metric Streams に追加の統計データを含めることもでき、メトリクスごとに設定可能です。その場合、追加の料金が発生します。詳細については、 ドキュメント を参照してください。 まとめ CloudWatch メトリクスを転送する2つの方法について詳しくみてきました。どちらの方法を選択すべきかまとめてみましょう。 API ポーリングが適している場合: 少量の特定のメトリクスのみを転送する場合 過去のデータも含めて転送する必要がある場合 CloudWatch Metric Streams が適している場合: 大量のメトリクスをリアルタイムで転送したい場合 運用オーバーヘッドを最小限に抑えたい場合 両方を組み合わせたハイブリッドアプローチも有効です。例えば、最新のデータは CloudWatch Metric Streamsで転送し、必要に応じて過去のデータを API ポーリングで取得する方法が考えられます。 要件に合わせて最適な方法を選択し、効率的なメトリクス転送を実現してください。 著者 大石　美緒 アマゾンウェブサービスジャパン合同会社　ソリューションアーキテクト

本記事は 2025 年 12 月 18 日 に公開された　「 How Kaltura Accelerates CI/CD Using AWS CodeBuild-hosted Runners 」　を翻訳したものです。 この投稿は、Kaltura のシニアプラットフォームエンジニアである Adi Ziv 氏が AWS との協力により寄稿しました。 AI ビデオエクスペリエンスクラウドおよび企業コミュニケーション技術の大手プロバイダーである Kaltura は、GitHub Actions 用の AWS CodeBuild ホステッドランナーに移行することで CI/CD インフラストラクチャを変革しました。この移行により、DevOps の運用オーバーヘッドが 90% 削減され、ビルドキュー時間が 66% 短縮され、インフラストラクチャコストが 60% 削減されました。最も重要なことは、この移行が Kaltura の規模 (1,000 以上のリポジトリ、100 以上の異なるワークフロータイプ、複数の開発チームにわたる 1 日あたり 1,300 のビルド) をサポートしながらこれらの結果を達成したことです。 組織がエンジニアリング業務を拡大するにつれて、効率的な CI/CD インフラストラクチャの維持がますます重要になります。 GitHub Actions のようなツールはパイプラインの作成を簡素化しますが、基盤となるインフラストラクチャの管理は、特にセキュリティ要件やプライベートネットワークアクセスのニーズに対処する場合、エンジニアリングチームにとって大きな負担になる可能性があります。Kaltura にとって、この課題は、同社がエンジニアリングチームを急速に拡大し、毎週新しいマイクロサービスをオンボーディングするにつれて深刻になりました。 この投稿では、Kaltura がセルフマネージド  Amazon Elastic Kubernetes Service (Amazon EKS) ランナーから CodeBuild ホステッドランナーに移行することで CI/CD インフラストラクチャを近代化し、パフォーマンスを劇的に向上させ、運用オーバーヘッドを削減しながら、強化されたセキュリティ機能を実装した方法を紹介します。 課題とソリューションの概要 セルフホステッドランナーの理解 GitHub ホステッドランナーは、運用オーバーヘッドがゼロで、自動スケーリングがあり、各ジョブに対してクリーンな状態を提供するため、多くの開発チームにとって優れた選択肢です。しかし、Kaltura のような特定のセキュリティおよび運用要件を持つ企業にとって、セルフホステッドランナーの方が適していました。GitHub ホステッドランナーは、安全ではあるものの、企業が機密性の高いワークロードに必要とする可能性のある、同じレベルの詳細な制御を提供しない共有環境で動作します。AWS 上のセルフホステッドランナーに移行することで、Kaltura は Amazon Virtual Private Cloud (Amazon VPC) の分離、 AWS Identity and Access Management (IAM) ポリシー、きめ細かいアクセス管理などの堅牢なセキュリティ制御にアクセスできるようになりました。さらに、セルフホステッドランナーにより、Kaltura は特殊なニーズに合わせてハードウェア構成をカスタマイズし、特定の使用パターンに合わせてコストを最適化し、運用に不可欠なプライベートネットワークリソースへの直接アクセスを維持できるようになりました。 最初に実装されたセルフホステッドランナーは、Kaltura が必要とする制御を提供しました。Amazon VPC 内にランナーをデプロイすることで、Kaltura はエンタープライズ規模の運用に不可欠な機能を獲得しました。この実装により、IAM ロールを通じて詳細な権限を実装しながら、内部リソースへの直接アクセスが可能になりました。Amazon エンドポイントを使用することで、Kaltura はパブリック API リクエストを回避し、すべてのトラフィックが組織の安全なプライベートネットワーク内に留まることを保証しました。 Amazon EKS ベースの初期ソリューション Kaltura の初期ソリューションは、ノードの自動スケーリングに Karpenter を使用して、Amazon EKS 上にセルフホステッド GitHub Actions ランナーをデプロイしました。Kaltura は、GitHub API をポーリングしてキューに入っているワークフローを確認し、必要なランナーを起動するカスタムコントローラーを実装しました。このソリューションは Kaltura が必要とするセキュリティと制御を提供しましたが、大きな運用上の課題をもたらしました。 問題の核心は、Kaltura のポーリングメカニズムに起因していました。ソリューションの規模が拡大するにつれて、Kaltura は頻繁に GitHub の API レート制限に達し、ポーリング頻度を 2 分間隔に減らすことを余儀なくされました。これらの状況は、運用上の問題の連鎖効果を生み出しました。DevOps チームは、ランナーイメージ、インフラストラクチャ、スケーリングメカニズムの維持にかなりの時間を費やしました。新しいリポジトリごとに手動での構成更新が必要となり、開発プロセスにボトルネックが生じました。パフォーマンス SLA を満たすために、Kaltura はウォームランナープールを維持し、インフラストラクチャコストを大幅に増加させました。 図 1：初期ソリューションは Amazon EKS と Karpenter が GitHub ランナーを起動する形式でした 開発チームへの影響は大きなものでした。すべてのワークフロー実行は、キューイングと実行の間に最低 2 分の遅延に直面しました。これらの遅延は 1 日を通じて蓄積され、開発者の生産性に深刻な影響を与えました。DevOps チームは、インフラストラクチャのメンテナンスタスクを処理するために、他のイニシアチブから常に引き離されることになりました。Kaltura が拡大を続けるにつれて、状況はますます維持できなくなりました。 Kaltura のソリューション – AWS CodeBuild ホステッドランナー いくつかのオプションを評価した後、Kaltura は、セルフホステッドソリューションのセキュリティと制御の利点を維持しながら、インフラストラクチャの課題を解決するために CodeBuild ホステッドランナーを選択しました。この新しいアーキテクチャは、CI/CD ソリューションの動作方法を根本的に変更し、ポーリングベースのシステムから Webhook ベースのシステムに移行しました。 図 2：AWS CodeBuild ベースのソリューションはフルマネージドであり、Webhook ベースになっています 新しいアーキテクチャは、シンプルでありながら強力なフローを通じて動作します。開発者がコードを GitHub にプッシュすると、GitHub は AWS CodeConnections に即座に Webhook 通知を送信します。これにより CodeBuild がトリガーされ、Kaltura の Amazon VPC 内にランナーがプロビジョニングされます。その後、GitHub Actions ワークフローがこの CodeBuild ランナー上で実行され、最小権限の原則に従ったきめ細かい IAM ロールを活用して AWS サービスにアクセスします。 主要なアーキテクチャコンポーネント Webhook ベースのアーキテクチャは、以前のポーリングの課題を完全に排除します。定期的なチェックを待つ代わりに、ワークフローはトリガーされるとすぐに実行を開始します。CodeBuild と CodeConnections は、リポジトリ、組織、またはエンタープライズレベルで構成可能な Webhook を持つ GitHub App を使用します。この統合により、真の CI/CD 自動検出が可能になり、以前の手動構成要件からの大きな進歩となります。 セキュリティは、新しいアーキテクチャの主要なコンポーネントの 1 つです。各ランナーは Amazon VPC 内で動作し、厳格なネットワークセキュリティ要件を維持します。Kaltura は IAM ロールを通じてきめ細かいアクセス制御を実装し、ランナーが AWS Systems Manager Parameter Store 、 Amazon CloudWatch 、 AWS Secrets Manager などの必要な特定の AWS サービスのみにアクセスできるようにしました。これにより、アクセス管理を簡素化しながらセキュリティ態勢が維持されます。 インフラストラクチャ管理 CodeBuild のサーバーレスな性質により、インフラストラクチャ管理のアプローチが変わりました。カスタムコントローラーとスケーリングロジックを備えた複雑な Amazon EKS クラスターを維持する代わりに、Kaltura は現在 AWS のマネージドサービスを活用しています。この移行により、ランナーイメージのパッチ適用、インフラストラクチャの維持、スケーリングメカニズムの最適化の必要性がなくなりました。 システムの柔軟性は、多様なワークフロー要件に対して特に価値があることが証明されました。CodeBuild は、標準インスタンスからマルチアーキテクチャビルド、特殊な ARM および GPU ランナーまで、さまざまなコンピューティング構成をサポートします。Kaltura は、異なるランナープールを管理したり、個別のインフラストラクチャスタックを維持したりすることなく、シンプルなラベル構成を通じてコンピューティングリソースをワークフローのニーズに簡単に合わせることができます。 Docker ワークフローの改善 Docker ビルドプロセスで予期しない利点が現れました。以前の Amazon EKS ベースのソリューションでは、コンテナビルドに複雑な Docker-in-Docker (DinD) 構成または Kaniko のような代替ツールが必要でした。CodeBuild のネイティブ Docker サポートにより、これらの複雑さが解消されました。このサービスは、Docker が直接実行できる分離されたビルド環境を提供し、ビルドパフォーマンスを大幅に向上させる組み込みのレイヤーキャッシング機能を備えています。 自動検出とセルフサービス 新しいアーキテクチャの主な利点は、そのセルフサービス機能です。開発チームが新しいリポジトリを作成したり、既存のリポジトリを変更したりする場合、手動での DevOps の介入は必要ありません。システムは、事前定義された構成とワークフローの runs-on ラベルに基づいて、適切なランナーを自動的にプロビジョニングします。このセルフサービスアプローチにより、Kaltura の運用オーバーヘッドが劇的に削減され、開発者の生産性が向上しました。 以下は、新しいアプローチを示す典型的なワークフロー構成です： name: Hello World on: [push] jobs: Hello-World-Job: runs-on: - codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} - image:${{ matrix.os }} - instance-size:${{ matrix.size }} - fleet:myFleet - buildspec-override:true strategy: matrix: include: - os: arm-3.0 size: small - os: linux-5.0 size: large steps: - run: echo "Hello World!" この構成は、Kaltura がシンプルで宣言的なワークフロー定義を維持しながら、CodeBuild の柔軟性をどのように活用しているかを示しています。チームはラベルを通じてコンピューティングニーズを指定でき、システムはすべての基盤となるプロビジョニングと管理を処理します。 移行アプローチ CodeBuild ランナーへの移行には、ワークフローの変更を最小限に抑えたシームレスな移行が含まれていました。移行の成功の鍵はそのシンプルさでした – ほとんどのワークフローは runs-on ラベルへの 1 つの変更のみが必要でした： runs-on: codebuild-myProject-${{ github.run_id }}-${{ github.run_attempt }} 1 対 1 の互換性があるため、既存のワークフローはさらなる変更なしに機能し続けました。 結果 新しいアーキテクチャは、1,000 以上のリポジトリと 100 のワークフロータイプにわたって 1 日あたり 1,300 以上のビルドを正常に処理し、さまざまなセキュリティ要件を持つ複数の開発チームにサービスを提供しています。CodeBuild ホステッドランナーへの移行の結果は、すべての主要な指標で大幅な改善をもたらしました： 運用における効果： DevOps運用オーバーヘッドを 90% 削減 ビルドキュー時間を 66% 短縮 インフラストラクチャコストを 60% 削減 開発者 1 人あたり 1 日 30 分の時間節約 最も重要なことは、より高速なビルド、運用負担の削減、一貫したパフォーマンスにより、開発者の満足度が向上したことです。システムのセルフサービスの性質により、オンボーディングのボトルネックが解消され、開発ライフサイクルが加速されました。 結論 CodeBuild ホステッドランナーを通じた Kaltura の CI/CD インフラストラクチャの変革は、最新のクラウドサービスが複雑なエンタープライズ規模の開発課題をどのように解決するかを示しています。Amazon EKS 上のセルフホステッドランナーの管理から AWS マネージドサービスの活用への移行は、エンタープライズグレードのセキュリティ要件を維持しながら、運用オーバーヘッドの 90% 削減、ビルドキューの 66% 高速化、60% のコスト削減を実現しました。 同様の道を検討している組織には、重要でないリポジトリを使用したパイロットプログラムから始めることをお勧めします。ワークフロー要件、セキュリティニーズ、パフォーマンスのボトルネックを理解して、効果的な移行戦略を形成することに焦点を当ててください。移行の影響を可視化し、ステークホルダーに ROI を示すために、コスト配分タグと監視を早期に実装してください。 追加リソース 機能と料金についての AWS CodeBuild 製品ページ 実装手順についての AWS CodeBuild ユーザーガイド GitHub のオープンソースの例と設定 AWS の継続的インテグレーションとデリバリーに関する AWS re:Invent 2023 セッション AWS の継続的インテグレーションと継続的デリバリー (CI/CD) に関する AWS re:Invent 2024 セッション 翻訳はソリューションアーキテクトの紙谷が担当しました。原文は こちら です。 著者について Adi Ziv  は Kaltura のシニアプラットフォームエンジニアで、スケーラブルで回復力があり最適化されたクラウドネイティブアプリケーションとインフラストラクチャの設計と構築において 10 年以上の経験を持っています。彼はサーバーレス、コンテナ化、およびイベント駆動アーキテクチャを専門としています。 Michael Shapira は、機械学習と生成 AI ソリューションを専門とする AWS のシニアソリューションアーキテクトです。19 年間のソフトウェア開発経験を持つ彼は、最先端の AI 技術を活用して顧客のビジネス変革とクラウド導入の加速を支援することに情熱を注いでいます。Michael は AWS 機械学習コミュニティの積極的なメンバーでもあり、イノベーションと知識共有に貢献しながら、顧客がエンタープライズレベルで AI とクラウドインフラストラクチャを拡張できるよう支援しています。クラウドソリューションの設計に携わっていない時は、Michael は熱心な写真家として、カメラのレンズを通して世界を捉えることを楽しんでいます。 Maya Morav Freiman は AWS のテクニカルアカウントマネージャーで、お客様が AWS サービスから最大限の価値を得て、運用および事業目標を達成できるよう支援しています。彼女は AWS サーバーレスコミュニティの一員であり、 DevOps エンジニアとして 10 年の経験を持っています。 この投稿の内容と意見は第三者の著者のものであり、AWS はこの投稿の内容または正確性について責任を負いません。

(「 うったまがった！ 」は非常に驚くという熊本弁です) 2026年 1 月、 ANGEL Dojo 2025 で内製化に挑戦された熊本中央病院様 を訪問しました。その目的は2つです。電子カルテ利用端末からAWSへ接続するためのネットワーク設定を完了すること、そして電子カルテからドライバを使用し SQL でデータを抽出できることの確認です。いずれも ANGEL Dojo で構築した生成AIシステムを実際に院内で利用するために不可欠な工程でした。結果として 1日目に環境構築を完了し、勢いそのままに2日目にはハンズオンを実施 。医師、看護師、医療事務など様々な職種から午前と午後併せ 50 名以上が参加され、終了後のアンケートでは5名以上が「院内の生成AI推進リーダーになりたい」と手を挙げて頂きました。 病院での生成AI活用では SaaS の導入を契約するイメージが強いかもしれません。SaaSの利便性は高いものの、特定機能に特化しており文書作成やシフト作成などそれぞれのツールを導入するとコストや管理が課題となります。今回構築した環境は、院内からのクラウド接続を可能にするispec様のネットワーク機器 CloudSail と AWS を組み合わせた自由度の高い環境であり、費用も使用量によるものの月額数万からと特別な大規模投資は不要です。技術面でも、ispec様またANGEL Dojo に参加いただいた株式会社アンチパターン様の支援により 2 日という短期間で構築を進めることが出来ました。「高い」「難しい」という生成AI導入のイメージは、もはや過去のものになりつつあります。 では、なぜ多くの病院で生成AI活用が進まないのか。訪問を通じて感じたのは、技術やコストよりも「組織の本気度」が成否を分けるということでした。自治体病院の8〜9割が赤字と言われる中、熊本中央病院様は黒字経営を続けています。院長をはじめ組織全体に「より良くなろう」という意志が満ちており、50名以上のハンズオン参加、5名以上のリーダー候補という数字にそれが表れていました。本ブログでは、生成 AI の活用が病院という実地で始まるまでの課題と解決策、その背景にある組織力についてお伝えします。 生成AI導入を阻む「2つの壁」 先にご紹介した通り、熊本中央病院様はANGEL Dojo 2025で医療文書作成時間の削減に取り組まれ、中間発表では投票1位を獲得されました。90 日のプログラム期間内で AWS パートナー様と生成AIを活用した文書作成支援システムを構築し、月800時間の効率化が見込めることを確認されています。 しかし、ANGEL Dojoで構築したシステムを実際の院内環境で稼働させるには、2つの壁がありました。 1つ目は、電子カルテ端末からクラウドへの安全な接続です。 医療情報ガイドラインに準拠したセキュアなネットワーク環境を構築する必要がありました。病院内のネットワークは閉域網として運用されており、外部のクラウドサービスに接続するには専用の仕組みが必要でした。 2つ目は、電子カルテからのデータ抽出です。 生成AIで医療文書を作成するには、電子カルテに蓄積された患者情報を適切に取得する必要があります。電子カルテ側の操作では患者情報を時系列かつ横断的に取得することが困難で、退院サマリ等に欠かせない情報を統合的に得るには電子カルテベンダーが提供するドライバを使ってデータを抽出する必要がありました。 これらは技術的に解決不可能な課題ではありません。しかし、電子カルテベンダーとの調整も必要であり解決策の模索に時間を要していました。ANGEL Dojoの成果を実際の医療現場で活かすためには、これらの壁を越えるパートナーとの協力が不可欠でした。 壁を越えるパー トナーとの出会い 転機となったのは、2025年11月に開催された 医療情報学連合大会 でした。 AWSの展示ブースでANGEL Dojoにおける両病院の取り組みを紹介していたところ、多くの方から関心をいただきました。同時に、大会という多くの関係者が集う場を活かし私達は次のステップに不可欠なソリューションやパートナーとの引き合わせを実施しました。その中で出会ったのが、ispec様の CloudSail です。 CloudSailは、病院内ネットワークとクラウドサービスをセキュアに接続できるソリューションです。院内の通信を閉域に保ちつつ、外部へのリクエストについては CloudSail がプロキシとしてリクエストを代行することで安全な通信を実現する仕組みに熊本中央病院様も強い関心を持たれていました。ispec様はデジタル庁標準型電子カルテのプロダクトワーキンググループに参加された経験もあり、医療分野での知見も豊富です。 ANGEL Dojoを通じて「自分達自身で適切なパートナーを見つけ、選べる力」が培われていたこともこの出会いを主体的に判断し活用する力になったと考えています。 2日間の訪問で実施したこと 熊本中央病院様の訪問で実施した内容は以下の通りです。 1日目：環境構築 ネットワーク設定 ：ispec様のCloudSail機器を使用し、電子カルテ利用端末からAWS上の生成 AI アプリケーションへの接続環境を構築しました。事前に機器を病院へ送付しておくことで、当日のリスクを最小限に抑える工夫をしました。ispec様にも現地でサポートいただき、設定作業をスムーズに進めることができました。アプリケーション利用時にブラウザのバージョンに起因し適切に動作しない課題がありましたが、最新版のブラウザを別途導入頂き使い分けて頂くことで対応できました。 データ抽出確認 ：電子カルテベンダー様より提供頂いたドライバを使用し、電子カルテからのデータ抽出が正常に行えることを確認しました。 トラブルが全くなかったわけではありません。しかし、事前準備を入念に行っていたこと、なにより熊本中央病院様の担当の方に現場で柔軟に対応いただいたことで、1日目のうちに環境構築を完了することができました。 2日目：ハンズオン 環境が整った翌日、早速ハンズオンを実施しました。午前・午後の2回に分けて開催し、医師、看護師、医療事務など様々な職種から50名以上が参加されました。 ハンズオンでは、1 日目で実際にセットアップした端末を使って生成AIの基本的な使い方から実務課題への応用まで実践いただきました。プロンプトの書き方と生成 AI による改善方法、画像・音声の入力方法を基礎知識としてお伝えした後、実際の業務課題をテーマに演習形式で実践いただける構成としました。 参加者の方からは「なかなかイメージがつかなかったが、今回初めてできそうなことが見えたので、良かったです。」「業務の効率化に向けた取り組みには大変興味があり、スタッフとできることを考えていきたいといった声をいただきました。また主な生成AIの利用ニーズとしては、退院サマリー・看護サマリー関連を希望する声が最も多く、他にも勤務表作成や請求関連業務での効率化等様々な面での活用用途があげられました。そして、ハンズオン終了後のアンケートでは、5名以上が「院内の生成AI推進リーダーになりたい」と手を挙げられました。 黒字経営を続ける組織に見たもの  2日間の訪問を通じて、強く印象に残ったことがあります。 自治体病院の8〜9割が赤字と報道される中、熊本中央病院様は黒字経営を続けています。その理由の一端を、今回の訪問で垣間見た気がしました。 50名以上のハンズオン参加。 病院の業務は多忙を極めるため、ハンズオンへの参加は数名と予測していたのですが、1 週間ほどという短い告知期間にもかかわらず、医師、看護師、医療事務など多職種から多くの方が参加されました。あまりの熱意に、1 日目セットアップを始める前にも今回の取り組みについて聞きたいという方向けにお話をさせて頂きました。この人数の規模から、組織全体として忙しい中でも「学びたい」「活用したい」と熱意を持つ方が多いことを実感しました。 5名以上がリーダーに手を挙げた。 生成AIの院内活用を進めていくためのリーダーを募ったところ、複数名が自ら手を挙げられました。指名ではなく、自発的にです。新しい取り組みを「誰かがやってくれる」のではなく「自分がやる」という姿勢が組織に根付いているのだと感じました。 院長をはじめとしたリーダーシップ。 ANGEL Dojoへの参加も、院長自らが強い意欲を示されたことがきっかけでした。トップが本気で取り組む姿勢を見せることで、組織全体のモチベーションが高まる。当たり前のようで、実践できる組織は多くありません。今回も、院長はハンズオンに自ら参加し職員の方とコミュニケーションを取られていました。 病院の組織力という土台があるからこそ、今回の 2 日間でセットアップとハンズオンを含め有意義な結果を残すことが出来たのだと感じています。熊本中央病院様からは次に向けた展望を次のように語っていただいています まずは、退院時サマリーや看護サマリーの自動生成を出発点に、 地方からAI活用が標準化された医療の実現を目指します。 地方病院が持つ可能性 熊本中央病院様では、環境・体制共に生成 AI 活用のキックオフができました。振り返ると、「やらなければならないこと」を着実に進めた結果でもあります。 内製化へのチャレンジを通じ、システムで何がどの程度のコストでできるかを理解した チャレンジを進める中で信頼できるパートナーを得た トップを含め組織全体でチャレンジを推進した 生成 AI により技術的な質問も実装も迅速かつ低コストで行えるようになってきている中で、いずれもやろうと思えばできることです。地方病院だから、中小規模だからできない、という理由はありません。今後 50 年、100 年というスパンで地域に信頼される医療を維持していくには、今まさに「やらなければならないこと」をできるかが問われています。AWS では、AWS パートナー様と共にそのチャレンジを支えます。

本記事は 2025/10/13 に公開された “ Transforming the physical world with AI: the next frontier in intelligent automation | Artificial Intelligence ” を翻訳したものです。 昨今の人工知能と物理のシステムの統合は、技術的進化の重要な転換点となっています。特にフィジカル AI は、アルゴリズムがデジタルの境界を超え、形のある物理世界を認識し、理解し、また操作します。そのためフィジカル AI は、各業界の企業で、運営方針を根本的に変えるものになります。これらの人工知能のシステムは、デジタルの情報と物理的現実の間のギャップを埋め、効率性とイノベーションをもたらす前例のないほど大きな機会となります。多くの組織にとっては、このことは顧客満足を向上させる斬新な方法となり、結果として、全ての業界を変革することになります。 この変革を加速するため、AWS Generative AI Innovation Center は、MassRobotics とNVIDIA と協業し、 Physical AI Fellowship を立ち上げました。これにより、次世代のロボティクスと自動化ソリューションを開発しているスタートアップが、必要なサポートを享受することが可能になり、先端を進むスタートアップとの協力ができるようになりました。以下はそのリストです。 Bedrock Robotics – 既存の建築業のシステム群に、自律性を追加提供するためのハードウェアとソフトウェアを、1日でインストールすることを可能にします Blue Water Autonomy – ハードウェア、ソフトウェア、AI を統合して、無人の船が長期間にわたり、外洋での運航を行うことを可能にします Diligent Robotics – 動的で人間と対面する状況で稼働する、自律型ヒューマノイドロボットに使用される基盤モデルを開発しています Generalist AI – 器用さに焦点を当てて、汎用ロボット向けのエンドツーエンドの AI 基盤モデルを開発しています RobCo – 機械の管理、パレタイジング（パレットにまとめる作業）、ディスペンシング（分配や塗布）、溶接などのタスクを初期投資や専門知識なしで自動化するためのモジュラーハードウェアとノーコードシステムを提供しています Tutor Intelligence – AI 駆動のロボットを構築し、メーカーや倉庫がすぐに投資対効果を得ることを可能にしています Wandercraft – リハビリテーションや在宅、または外来センターにおいて、歩行能力の回復を支援する外骨格ロボットを開発しています Zordi – AI、ロボティクス、機械学習を組み合わせて、温室農業を革新しています この AI と物理システムの統合は、企業や公共団体などの組織にとって、従来の少しずつ発展してきた改善とは全く異なる、業務や顧客体験で可能だったことの範囲を根本的に変えるものとなります。 フィジカル AI の段階：自動化から真の人工知能へ 組織がフィジカル AI を推進するプロジェクトを評価する場合、戦略的に行なわなければなりません。そのためには、一つ一つのソリューションでできる自動化が、自動化の段階のどこに位置するかを理解する必要があります。自動化の各段階は、自律性と自然さにおいて下記のように明確なレベルに分けられます。 レベル 1：基本的な物理的な自動化： この基礎段階では、厳密に制御された環境で事前定義されたタスクを実行するシステムの段階です。組立ラインの産業用ロボットを想像してみてください。とても効率的ですが、画一的で、完全に人間のプログラミングと指示に依存しています。 レベル 2：適応した物理的な自動化： この段階では、システムは柔軟にタスクを実行することができます。個々のアクションは事前にプログラムされていますが、リアルタイムの環境では、トリガによりタスク実行の順序を調整します。たとえば人間が近くにいるときに動作を変更することができる協働ロボットが、こういった適応の例といえます。 レベル 3：部分的に自律的なフィジカル AI： この段階では、システムが人間のわずかな入力でタスクの計画、実行し、環境にふさわしい、知性的な動きを行えます。このレベルで獲得される自律性は、たとえば、デモンストレーションを実行することにより、新しいプロセスを学習することが可能なロボットです。 レベル 4：完全に自律的なフィジカル AI： 最も高度なレベルでは、わずかな人間の監視の下で、様々な領域で動作できるシステムの実現が可能となります。このレベルのシステムでは新しいシナリオや環境の変化に柔軟に対応します。ほとんどの商用ソリューションはレベル 1 または 2 にとどまっていますが、完全な自律性に向けた進化は現在どんどん加速してきています。 進化する技術：フィジカル AI の構成要素 上記の基本的な自動化から、完全な自律性を実現するための進化には、高度な技術基盤が必要です。進化を推進する技術には下記があります： 高度な制御理論 は、精密で信頼性の高い作動を可能にします 高精度知覚モデル は、マルチモーダル（複数の異なる）センサーが稼働し、機械が周りの複雑な環境を理解することを可能にします エッジ AI アクセラレータ は、アクションの時点でリアルタイムの推論をサポートし、遅延を許容しないタスクの実行をします 基盤モデル は、マルチモーダルのデータセットでトレーニングされ、ドメイン全体で一般化できる人工知能を提供します デジタルツインシステム は、実環境での本稼働前に、物理システムのシミュレーション、検証、そして最適化するための調整し、開発サイクルを大幅に加速します 業界からの後押しと投資の好機 フィジカル AI は複数の他の急成長産業の中心に位置しています。、AI ロボット分野だけでも 2034 年までに $1,242.6億 にすら到達すると予測されています。同時に、デジタルツイン技術産業も関連する産業となり、 $3,790億 まで成長すると予測されています。企業にとってこういった予測は、自動化と効率性、ならびにデジタル変革に対してのアプローチを抜本的に変えるべきであると示唆になります。 投資ビジネスもこのチャンスを察知しており、フィジカル AI 分野で特にいくつかの重要なテーマに注視しています。その一つとしてヒューマノイドロボティクスはよく話題にあがり、第一線に立つだろうと言われています。いくつかのスタートアップビジネスは既に大規模な資金調達を実現しており、人間の活動環境でシームレスに動作する、汎用ロボットワーカーを開発しています。同時に、ロボティクスのための基盤モデル、つまり様々なタスクに適応し、多様なロボットシステムを制御できる高機能の「ロボット脳」の開発への関心が高まっています。各業界では業界内でしか使用できないアプリケーションの存在が共通の課題となっており、この課題に迅速に取り組むために柔軟で高度な知能を持つシステムの実現に継続して投資しており、この取り組みの分野は倉庫の物流の効率化から農作業の革新にまで多岐にわたります。フィジカル AI の幅広い能力により斬新なアプリケーションが出現し、手術用ロボティクス、自律型配送システム、高度な防衛技術など、さまざまな分野での活用が実証されています。新しい領域への拡大により、各業界で フィジカル AI の多様で大きな変革力が浮き彫りになってきています。 現実世界への影響：フィジカルAI 変革の定量化 投資市場での傾向で将来への期待が高いことは明らかではありますが、さらにフィジカル AI はすでに各業界で具体的な成果を上げています。例えば、Amazon のサプライチェーンは インテリジェントな自動化によって効率を 25％向上させ 、Foxconn は製造の デプロイに要する時間を 40％を削減しました。 ヘルスケアでは、AI が支援した手術により 合併症の発生率が 30％減少し、手術時間を 25％削減 し、多大な成果を上げています。 2024 年の 製造業とエネルギーに関する AI レポート によると、製造に AI を使用している製造業の 64％が ROI の改善があり、約 3 分の 1 の企業が 1 ドルの投資に対して 2〜5 ドルの収益を見込んでいます。こういった企業では 20〜40％の効率改善、ならびに 15〜30％のコスト削減、そして Robot-as-a-Service のような革新的なビジネスモデルの提供へと進化しています。 例えば小売業では、デジタルツインを使用してそれぞれの店舗レイアウトが買い物客の行動に与える影響を調査しています。この調査では、自律型の在庫管理システムとフィジカル AI を組み合わせたテストをして、店舗での物理的なスペースの活用と運営の効率を上げるために役立ちました。一方、農業ではデータ活用による作物品質の向上、作物のモニタリング、自動収穫の発展に恩恵を受けています。このように、フィジカル AI は広い範囲で各産業にどんどん強い影響をもたらしてきています。 将来への展望 フィジカル AI の影響はすでに業界全体で明らかになってきています。多くの企業はすでに概念実証の先に進んで、測定可能なビジネス的な価値を立証しています。この潮流に参加する組織にとっては、Physical AI Fellowship の助力が重要な役割を担い、共に新しい技術を研究から商用アプリケーションへ発展させる役割を担う道を歩むでしょう。さまざまな規模とそれぞれの業種の企業にとって、AI と物理システムの統合を成功させることが、今後 10 年間で業界のリーダーを決めることになるでしょう。 詳細情報： お問い合わせ先 ：みなさんの企業でチーム一体となり、フィジカル AI の活用計画やスキル開発の準備、またリスクについて検討をご希望される場合はこちらのリンク先からご連絡をください。 実験から本番環境まで専門的なカスタマイズされたサポートを提供する Generative AI Innovation Center については こちら をご覧ください。 著者 Sri Elaprolu は AWS Generative AI Innovation Center のディレクターであり、企業や政府組織向けに最先端の AI ソリューションを実施するグローバルチームを率いています。AWS での 13 年間の在籍中、彼は NFL、Cerner、NASA などの組織と提携する ML サイエンスチームを率いてきました。AWS 以前は、Northrop Grumman で 14 年間製品開発とソフトウェアエンジニアリングのリーダーシップの役割を担っていました。Sri は工学修士号と MBA を保持しています。 Alla Simoneau は 15 年以上の経験を持つ技術および営利法人分野のリーダーであり、現在 Amazon Web Services（AWS）で Emerging Technology Physical AI Lead を務め、AI と実世界のアプリケーションの交差点でグローバルなイノベーションを推進しています。Amazon で 10 年以上を過ごした Alla は、戦略、チームビルディング、運用卓越性のリーダーとして認められており、スタートアップや企業顧客のために最先端の技術を実世界の変革に転換しています。 Paul Amadeo は人工知能、機械学習、IoT システム、RF 設計、光学、半導体物理学、および先進工学にまたがる 30 年以上の経験を持つ経験豊富な技術分野におけるリーダーです。AWS Generative AI Innovation Center の フィジカル AI のテクニカルリードとして、Paul は AI 機能を具体的な物理システムに変換し、概念から生産までの複雑な実装を通じてお客様をガイドすることを専門としています。彼の多様な背景には、エッジ環境向けのコンピュータビジョンシステムの設計、世界中で何十億ものデバイスを生産したロボットスマートカード製造技術の設計、営利法人および防衛分野の両方でクロスファンクショナルチームをリードすることが含まれます。Paul はカリフォルニア大学サンディエゴ校で応用物理学の修士号、カリフォルニア工科大学で応用物理学の学士号を取得し、光学システム、通信デバイス、製造技術にまたがる 6 つの特許を保持しています。 Randi Larson は、AWS Generative AI Innovation Center で AI イノベーションと経営戦略のギャップを埋め、組織が技術的なブレイクスルーをビジネス価値に変換する方法を実現しています。Randi は戦略的なストーリー構成とデータ駆動の洞察をグローバルな基調講演、Amazon 初のtech-for-good ポッドキャスト、そして AI 変革に関する業界や Amazon のリーダーとの対話を通して提供しています。Amazon 入社前、Randi は Bloomberg のジャーナリストとして、また経済機関、シンクタンク、中小オフィスのテクノロジーイニシアチブのアドバイザーとして、分析的精度を上げてきました。Randi はデューク大学フーカビジネススクールで MBA を、ボストン大学でジャーナリズムとスペイン語の学士号を取得しています。

本記事は 2026 年 02 月 03 日 に公開された “Amazon DynamoDB global tables now support replication across AWS accounts” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/amazon-dynamodb-global-tables-now-support-replication-across-aws-accounts/ Amazon DynamoDB グローバルテーブルは、フルマネージド、マルチリージョン、マルチアクティブなデータベース機能であり、グローバルにスケールするアプリケーションに対してシームレスなデータレプリケーションと高速なローカル読み取り・書き込みパフォーマンスを提供します。 本日、 Amazon DynamoDB のマルチアカウントグローバルテーブル を発表します。これにより、複数の AWS アカウントと AWS リージョン間で DynamoDB テーブルデータをレプリケートできるようになります。この機能はグローバルテーブルにアカウントレベルの分離を追加し、より強力な分離と回復性のために、複数の AWS アカウントとリージョン間で DynamoDB テーブルデータをレプリケートできるようになります。 この機能により、DynamoDB は現在、それぞれ異なるアーキテクチャパターン向けに設計された 2 つのグローバルテーブルモデルをサポートしています。 同一アカウントグローバルテーブル – レプリカは単一の AWS アカウント内で作成および管理されます マルチアカウントグローバルテーブル – レプリカは複数の AWS アカウントにデプロイされながら、共有レプリケーショングループに参加します 両方のモデルは、高速なローカル書き込み、非同期レプリケーション、および最終書き込み者優先 (last-writer-wins) の競合解決をサポートしています。ただし、アカウント、権限、暗号化、テーブルガバナンスの管理方法が異なります。マルチアカウントグローバルテーブルは現在、 マルチリージョン結果整合性 (MREC) のみをサポートしています。 この記事では、マルチアカウントグローバルテーブルの作成と設定方法を示し、この機能を使用する価値を強調するユースケースを紹介します。 強化されたディザスタリカバリアーキテクチャ マルチアカウントグローバルテーブルは、ディザスタリカバリソリューションのアーキテクチャ設計方法を変革します。複数の AWS アカウントにデータを分散することで、設定ミス、セキュリティインシデント、またはアカウントレベルの問題の影響を制限するための追加の分離レイヤーを持つことができます。 プライマリアプリケーションが Account1 (us-east-1) で実行され、ディザスタリカバリ環境が Account2 (us-west-2) で動作するシナリオを考えてみましょう。マルチアカウントグローバルテーブルを使用すると、両方のアカウントが重要なデータの同期されたコピーを維持し、複雑なデータ移行手順なしで迅速なフェイルオーバーを可能にします。 組織のコンプライアンスとコスト配分 多くの企業は、組織、セキュリティ、またはコンプライアンス上の理由から、複数の AWS アカウントで運用しています。マルチアカウントグローバルテーブルは、これらの組織が既存のコンプライアンス境界、ガードレール、ガバナンスモデルを尊重しながら、分散インフラストラクチャ全体でデータの整合性を維持するのに役立ちます。 たとえば、金融サービス企業は、異なる事業単位や規制環境に対して個別のアカウントを維持する場合があります。マルチアカウントグローバルテーブルにより、これらの単位は、コンプライアンスフレームワークで要求される分離を維持しながら、重要な参照データを共有できます。さらに、各リージョナルレプリカのコストは、別々の事業単位によって管理される可能性のある AWS アカウントに対応しています。 マルチアカウント戦略の詳細については、 AWS アカウント管理と分離 および 複数の AWS アカウントを使用する利点 を参照してください。 DynamoDB マルチアカウントグローバルテーブルの仕組み マルチアカウントグローバルテーブルは、 リソースベースのポリシー で定義された権限を使用して、他のどのアカウントがレプリケーショングループに参加できるか、およびデータのレプリケーションを許可するかを示します。 各レプリカは、別々の AWS アカウントと別々のリージョンに存在する必要があります。 N 個のレプリカを持つマルチアカウントグローバルテーブルの場合、 N 個の別々のリージョンに N 個のアカウントが必要です。 既存の空でない単一リージョンテーブルから始めて、別のリージョンとアカウントにレプリカテーブルを追加できます。システムは既存のアイテムを新しいテーブルにコピーします。両方のテーブルが同期されると、各テーブルのステータスが ACTIVE と表示されます。 マルチアカウントグローバルテーブルは、 ReplicationLatency メトリクスを Amazon CloudWatch に公開します。このメトリクスは、アイテムがレプリカテーブルに書き込まれてから、そのアイテムがグローバルテーブル内の別のレプリカに表示されるまでの経過時間を追跡します。このメトリクスを監視して、アイテムがリモートリージョンにどれだけ迅速にレプリケートされるかを理解できます。 マルチアカウントグローバルテーブル: 設定のレプリケーション動作 マルチアカウントグローバルテーブルを作成する際、各リージョナルレプリカに対して GlobalTableSettingsReplication を ENABLED に設定する必要があります。これは、1 つのリージョンで行われた設定変更が、グローバルテーブルに参加する他のリージョンに自動的に伝播されることを意味します。 ソーステーブルの場合、テーブル作成後に設定のレプリケーションを有効にできます。これは、テーブルが最初にリージョナルテーブルとして作成され、後でマルチアカウントグローバルテーブルにアップグレードされるシナリオをサポートします。 同期される設定と同期されない設定のリストについては、 設定の同期 を参照してください。 ソリューション概要 この記事では、マルチアカウントグローバルテーブルを使用するために必要な手順の概要を示します。詳細なチュートリアルについては、 チュートリアル: グローバルテーブルの作成 を参照してください。 この例では、REGION1 の ACCOUNT1 と REGION2 の ACCOUNT2 の 2 つのアカウントを使用します。 新しいテーブルが myTable と呼ばれると仮定して、各テーブルレプリカの Amazon リソースネーム (ARN) を事前に次のように作成できます。 ACCOUNT1_TABLE_ARN : “arn:aws:dynamodb:REGION1:ACCOUNT1:table/myTable” ACCOUNT2_TABLE_ARN : “arn:aws:dynamodb:REGION2:ACCOUNT2:table/myTable” REGION1 に DynamoDB テーブルを作成します。テーブルにアイテムを追加するか、アイテムを持つ既存の単一リージョンテーブルを使用できます。この記事では、テーブルに myTable という名前を付けます。 テーブルの GlobalTableSettingsReplication: ENABLED を設定します。 次のスクリーンショットは、DynamoDB コンソールでのこの設定を示しています。 AWS コマンドラインインターフェイス (AWS CLI) を使用している場合は、create-table コマンド内で –global-table-settings-replication ENABLED を追加することでこれを示すこともできます。 次の 2 つのステートメントを含むリソースポリシーをテーブルに追加します。 { "Version": "2012-10-17", "Statement": [ { "Sid": " AllowTrustedAccountsToJoinThisGlobalTable", "Effect": "Allow", "Principal": { "AWS": [<ACCOUNT2>] }, "Action": "dynamodb:AssociateTableReplica", "Resource": <ACCOUNT1_TABLE_ARN> }, { "Sid": "AllowReplication", "Effect": "Allow", "Principal": { "Service": "replication.dynamodb.amazonaws.com" }, "Action": [ "dynamodb: ReadDataForReplication", "dynamodb: WriteDataForReplication", "dynamodb: ReplicateSettings" ], "Resource": <ACCOUNT1_TABLE_ARN>, "Condition": { "StringEquals": { "aws:SourceAccount": [<ACCOUNT1>, <ACCOUNT2>], "aws:SourceArn": [<ACCOUNT1_TABLE_ARN>, <ACCOUNT2_TABLE_ARN>] } } } ] } これらのポリシーの Condition セクションは、DynamoDB サービスリンクロール が指定したテーブル間でデータをレプリケートする権限を持つために必要です。グローバルテーブルを追加のアカウントとリージョンに拡張する必要がある場合は、リソースベースのポリシーに追加のアカウントと ARN を追加できます。 ACCOUNT2 と REGION2 に次の設定で DynamoDB テーブルを作成します。 GlobalTableSettingsReplication: ENABLED 次の形式のリソースポリシーを含めます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowReplication", "Effect": "Allow", "Principal": { "Service": "replication.dynamodb.amazonaws.com" }, "Action": [ "dynamodb: ReadDataForReplication", "dynamodb: WriteDataForReplication", "dynamodb: ReplicateSettings" ], "Resource": <ACCOUNT2_TABLE_ARN>, "Condition": { "StringEquals": { "aws:SourceAccount": [<ACCOUNT1>, <ACCOUNT2>], "aws:SourceArn": [<ACCOUNT1_TABLE_ARN>, <ACCOUNT2_TABLE_ARN>] } } } ] } DynamoDB コンソールでもこの手順を実行できます。 Create table ドロップダウンメニューを選択し、 Create cross-account global table replica を選択します。 次のスクリーンショットは、必要な設定の詳細を示しています。 ユースケース ディザスタプランニングの 1 つのタイプは、悪意のある攻撃者が Account1 の完全な制御を獲得するシナリオです。これが発生した場合、Account2 の所有者は、テーブルのリソースポリシーを更新してレプリケーションアクションを拒否することで、レプリケーションを停止できます。テーブルで ポイントインタイムリカバリ が有効になっている場合、 増分エクスポート を Amazon Simple Storage Service (Amazon S3) に実行して、過去 24 時間のすべての書き込みのスナップショットを JSON 形式で取得できます。その後、変更されたアイテムの 新しいイメージと古いイメージ を確認して、悪意を持って変更された可能性のあるアイテムの元の状態を確認できます。これはグローバルテーブルの異常な状態としてフラグが立てられるため、 AWS サポート がレプリケーションが停止した理由を確認するために連絡する場合があります。 別のユースケースは、AWS アカウント間でテーブルを移動したい場合です。執筆時点では、マルチアカウントグローバルテーブルは同一リージョンレプリケーションをサポートしていないため、一時的に別のリージョンを含む一連の手順を実行する必要があります。概要レベルの手順は次のとおりです。 DynamoDB への認証に使用する AWS アカウントとリージョンを切り替えられるようにアプリケーションを設定します。 この記事で説明した手順を使用して、次を実行します。 Account1、Region1 のテーブルにリソースポリシーを追加します。 Account2、Region2 にリンクされたレプリカテーブルを作成します。 Account2、Region2 の DynamoDB テーブルを使用するようにアプリケーションを調整します。 Account1、Region1 のテーブルレプリカを削除します。 Account2 を使用して、 update-table を呼び出し、Region1 に新しい同一アカウントレプリカを追加するようリクエストします。 テーブルのステータスを確認します。ACTIVE に戻ると、Account2、Region1 のテーブルレプリカの準備が整います。 Account2、Region1 を使用するようにアプリケーションを切り替えます。 (オプション) Account2、Region2 のテーブルレプリカを削除します。 まとめ DynamoDB グローバルテーブルは、複数の AWS アカウント間のレプリケーションをサポートするようになりました。これにより、アカウントレベルの分離による回復性が向上し、カスタマイズされたセキュリティとデータ境界制御がサポートされ、事業単位または環境ごとのワークロードの調整が可能になり、ガバナンス要件が簡素化されます。詳細については、 グローバルテーブル – マルチアクティブ、マルチリージョンレプリケーション および Amazon DynamoDB の回復性とディザスタリカバリ を参照してください。コメントセクションでフィードバックをお知らせください。 著者について Robert McCauley Robert は、ボストンを拠点とする Amazon DynamoDB スペシャリストソリューションアーキテクトです。2012 年に Amazon Robotics の SQL 開発者として Amazon でのキャリアを開始し、その後 Alexa Skills ソリューションアーキテクトを経て、AWS に参加しました。

本記事は 2026 年 2 月 3 日 に公開された「 Use Amazon MSK Connect and Iceberg Kafka Connect to build a real-time data lake 」を翻訳したものです。 分析ワークロードでリアルタイムなインサイトが求められる中、ビジネスデータを生成直後にデータレイクへ取り込む必要性が高まっています。リアルタイム CDC データ取り込みには AWS Glue や Amazon EMR Serverless など様々な方法がありますが、Amazon MSK Connect と Iceberg Kafka Connect を組み合わせることで、フルマネージドかつシンプルなアプローチで運用の複雑さを軽減し、継続的なデータ同期を実現できます。 本記事では、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) Connect で Iceberg Kafka Connect を使用し、トランザクションデータベースから Apache Iceberg テーブルへの同期プロセスを簡素化しながら、データレイクへのリアルタイムデータ取り込みを高速化する方法を紹介します。 ソリューション概要 本記事では、 Amazon Relational Database Service (Amazon RDS) for MySQL からトランザクションログデータをキャプチャし、append モードで Iceberg テーブル形式として Amazon Simple Storage Service (Amazon S3) に書き込む実装方法を説明します。単一テーブルと複数テーブルの同期をカバーします。 ダウンストリームのコンシューマーは、変更レコードを処理してデータ状態を再構築してから Iceberg テーブルに書き込みます。 シンク側のビジネスロジックには Iceberg Kafka Sink Connector を使用します。Iceberg Kafka Sink Connector には以下の特徴があります: exactly-once 配信をサポート 複数テーブル同期をサポート スキーマ変更をサポート Iceberg のカラムマッピング機能によるフィールド名マッピング 前提条件 デプロイを開始する前に、以下のコンポーネントを準備してください: Amazon RDS for MySQL : Iceberg データレイクに同期したいデータを持つ Amazon RDS for MySQL データベースインスタンスが稼働していることを前提としています。Change Data Capture (CDC) 操作をサポートするため、RDS インスタンスでバイナリログが有効になっていることを確認してください。 Amazon MSK クラスター : ターゲットの AWS リージョンに Amazon MSK クラスターをプロビジョニングする必要があります。このクラスターは MySQL データベースと Iceberg データレイク間のストリーミングプラットフォームとして機能します。適切なセキュリティグループとネットワークアクセスが設定されていることを確認してください。 Amazon S3 バケット : カスタム Kafka Connect プラグインをホストする Amazon S3 バケットを準備してください。このバケットは AWS MSK Connect がプラグインを取得してインストールするストレージロケーションです。バケットはターゲットの AWS リージョンに存在し、オブジェクトをアップロードする適切な権限が必要です。 カスタム Kafka Connect プラグイン : MSK Connect でリアルタイムデータ同期を有効にするには、2 つのカスタムプラグインを作成する必要があります。1 つ目のプラグインは Debezium MySQL Connector を使用してトランザクションログを読み取り、Change Data Capture (CDC) イベントを生成します。2 つ目のプラグインは Iceberg Kafka Connect を使用して Amazon MSK から Apache Iceberg テーブルにデータを同期します。 ビルド環境 : Iceberg Kafka Connect プラグインをビルドするには、Java と Gradle がインストールされたビルド環境が必要です。 Amazon EC2 インスタンス (推奨: Amazon Linux 2023 または Ubuntu) を起動するか、要件を満たすローカルマシンを使用できます。十分なディスク容量 (最低 20GB) と、リポジトリのクローンおよび依存関係のダウンロードに必要なネットワーク接続を確保してください。 オープンソースから Iceberg Kafka Connect をビルドする コネクタの ZIP アーカイブは Iceberg ビルドの一部として作成されます。以下のコードでビルドを実行できます: git clone https://github.com/apache/iceberg.git cd iceberg/ ./gradlew -x test -x integrationTest clean build The ZIP archive will be saved in ./kafka-connect/kafka-connect-runtime/build/distributions. カスタムプラグインを作成する 次のステップでは、データの読み取りと同期を行うカスタムプラグインを作成します。 前のステップでコンパイルしたカスタムプラグイン ZIP ファイルを指定の Amazon S3 バケットに アップロード します。 AWS マネジメントコンソールで Amazon MSK に移動し、ナビゲーションペインで Connect を選択します。 Custom plugins を選択し、S3 にアップロードしたプラグインファイルを参照または S3 URI を入力して選択します。 カスタムプラグインに一意でわかりやすい名前を指定します (例: my-connector-v1) 。 Create custom plugin を選択します。 MSK Connect を設定する プラグインをインストールしたら、MSK Connect を設定する準備が整いました。 データソースアクセスを設定する まずデータソースアクセスを設定します。 ワーカー設定を作成するには、MSK Connect コンソールで Worker configurations を選択します。 Create worker configuration を選択し、以下の設定をコピーして貼り付けます。 key.converter.schemas.enable=false value.converter.schemas.enable=false key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter # Enable topic creation by the worker topic.creation.enable=true # Default topic creation settings for debezium connector topic.creation.default.replication.factor=3 topic.creation.default.partitions=1 topic.creation.default.cleanup.policy=delete Amazon MSK コンソールで、 Amazon MSK Connect の下にある Connectors を選択し、 Create connector を選択します。 セットアップウィザードで、前のステップで作成した Debezium MySQL Connector プラグインを選択し、コネクタ名を入力して同期先の MSK クラスターを選択します。設定に以下の内容をコピーして貼り付けます: connector.class=io.debezium.connector.mysql.MySqlConnector tasks.max=1 include.schema.changes=false database.server.id=100000 database.server.name= database.port=3306 database.hostname= database.password= database.user= topic.creation.default.partitions=1 topic.creation.default.replication.factor=3 topic.prefix=mysqlserver database.include.list= ## route transforms=Reroute transforms.Reroute.type=io.debezium.transforms.ByLogicalTableRouter transforms.Reroute.topic.regex=(.*)(.*) transforms.Reroute.topic.replacement=$1all_records # schema.history schema.history.internal.kafka.topic schema.history.internal.kafka.bootstrap.servers= # IAM/SASL schema.history.internal.consumer.sasl.mechanism=AWS_MSK_IAM schema.history.internal.consumer.sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler schema.history.internal.consumer.security.protocol=SASL_SSL schema.history.internal.consumer.sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required; schema.history.internal.producer.security.protocol=SASL_SSL schema.history.internal.producer.sasl.mechanism=AWS_MSK_IAM schema.history.internal.producer.sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler schema.history.internal.producer.sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required; 設定では、 Route を使用して複数のレコードを同じトピックに書き込みます。パラメータ transforms.Reroute.topic.regex では、同じトピックに書き込むテーブル名をフィルタリングする正規表現を設定します。以下の例では、テーブル名に <tablename-prefix> を含むデータが同じトピックに書き込まれます。 ## route transforms=Reroute transforms.Reroute.type=io.debezium.transforms.ByLogicalTableRouter transforms.Reroute.topic.regex=(.*)(.*) transforms.Reroute.topic.replacement=$1all_records 例えば、 transforms.Reroute.topic.replacement を $1all_records と指定すると、MSK に作成されるトピック名は <database.server.name>.all_records になります。 Create を選択すると、MSK Connect が同期タスクを作成します。 データ同期 (単一テーブルモード) Iceberg テーブルのリアルタイム同期タスクを作成できます。まず単一テーブルのリアルタイム同期ジョブを作成します。 Amazon MSK コンソールで、 MSK Connect の下にある Connectors を選択します。 Create connector を選択します。 次のページで、前に作成した Iceberg Kafka Connect プラグインを選択します。 コネクタ名を入力し、同期先の MSK クラスターを選択します。 設定に以下のコードを貼り付けます。 connector.class=org.apache.iceberg.connect.IcebergSinkConnector tasks.max=1 topics= iceberg.tables= iceberg.catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog iceberg.catalog.warehouse= iceberg.catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO iceberg.catalog.client.region= iceberg.tables.auto-create-enabled=true iceberg.tables.evolve-schema-enabled=true iceberg.control.commit.interval-ms=120000 transforms=debezium transforms.debezium.type=org.apache.iceberg.connect.transforms.DebeziumTransform key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter value.converter.schemas.enable=false key.converter.schemas.enable=false iceberg.control.topic=control-iceberg Iceberg Connector は、デフォルトで control-iceberg という名前のトピックを作成してオフセットを記録します。 topic.creation.enable = true を含む前に作成したワーカー設定を選択してください。デフォルトのワーカー設定を使用し、MSK ブローカーレベルで自動トピック作成が有効になっていない場合、コネクタはトピックを自動作成できません。 パラメータ iceberg.control.topic = <offset-topic> を設定してトピック名を指定することもできます。カスタムトピックを使用する場合は、以下のコードを使用できます。 $KAFKA_HOME/bin/kafka-topics.sh --bootstrap-server $MYBROKERS --create --topic <my-iceberg-offset-topic> --partitions 3 --replication-factor 2 --config cleanup.policy=compact Amazon Athena で同期されたデータ結果をクエリします。Athena に同期されたテーブルから、ソーステーブルのフィールドに加えて、CDC のメタデータ内容を格納する _cdc フィールドが追加されていることがわかります。 コンパクション コンパクションは Iceberg テーブルに不可欠なメンテナンス操作です。小さなファイルを頻繁に取り込むとクエリパフォーマンスに悪影響を与えますが、定期的なコンパクションで小さなファイルを統合し、メタデータの負荷を抑え、クエリ効率を大幅に向上できます。最適なテーブルパフォーマンスを維持するには、専用のコンパクションワークフローを実装する必要があります。 AWS Glue は最適なソリューションを提供し、小さなファイルを適切にマージしてテーブルレイアウトを再構築する自動コンパクション機能を備えています。 スキーマ進化のデモ スキーマ進化機能を示すため、ソースデータベースでのフィールド変更が MSK Connect と Iceberg Kafka Connect を通じて Iceberg テーブルに自動的に同期される様子をテストしました。 初期セットアップ: まず、以下のスキーマを持つ顧客情報テーブル (tb_customer_info) を含む RDS MySQL データベースを作成しました: +----------------+--------------+------+-----+-------------------+-----------------------------------------------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------+------+-----+-------------------+-----------------------------------------------+ | id | int unsigned | NO | PRI | NULL | auto_increment | | user_name | varchar(64) | YES | | NULL | | | country | varchar(64) | YES | | NULL | | | province | mediumtext | NO | | NULL | | | city | int | NO | | NULL | | | street_address | varchar(20) | NO | | NULL | | | street_name | varchar(20) | NO | | NULL | | | created_at | timestamp | NO | | CURRENT_TIMESTAMP | DEFAULT_GENERATED | | updated_at | timestamp | YES | | CURRENT_TIMESTAMP | DEFAULT_GENERATED on update CURRENT_TIMESTAMP | +----------------+--------------+------+-----+-------------------+-----------------------------------------------+ 次に、Debezium MySQL Connector を使用して MSK Connect を設定し、このテーブルからの変更をキャプチャして Amazon MSK にリアルタイムでストリーミングしました。その後、Iceberg Kafka Connect を設定して MSK からデータを消費し、Iceberg テーブルに書き込みました。 スキーマ変更テスト: スキーマ進化機能をテストするため、ソーステーブルに phone という新しいフィールドを追加しました: ALTER TABLE tb_customer_info ADD COLUMN phone VARCHAR(20) NULL; 次に、phone フィールドを含む新しいレコードを挿入しました: INSERT INTO tb_customer_info (user_name,country,province,city,street_address,street_name,phone) values ('user_demo','China','Guangdong',755,'Street1 No.369','Street1','13099990001'); 結果: Amazon Athena で Iceberg テーブルをクエリすると、phone フィールドが最後のカラムとして自動的に追加され、新しいレコードがすべてのフィールド値を含めて正常に同期されていることが確認できました。Iceberg Kafka Connect の自己適応スキーマ機能により、ソースでの DDL 変更がシームレスに処理され、データレイクでの手動スキーマ更新が不要になることが実証されました。 データ同期 (複数テーブルモード) データ管理者が単一のコネクタで複数テーブルのデータを移動したいケースはよくあります。例えば、CDC 収集ツールを使用して複数テーブルのデータを 1 つのトピックに書き込み、コンシューマー側で 1 つのトピックから複数の Iceberg テーブルにデータを書き込むことができます。「データソースアクセスを設定する」セクションでは、 Route を使用して指定ルールに従ったテーブルをトピックに同期する MySQL 同期 Connector を設定しました。ここでは、このトピックから複数の Iceberg テーブルにデータを分配する方法を確認します。 AWS Glue Data Catalog を使用して Iceberg Kafka Connect で複数テーブルを Iceberg テーブルに同期する場合、同期プロセスを開始する前に Data Catalog にデータベースを事前作成する必要があります。AWS Glue のデータベース名はソースデータベース名と完全に一致する必要があります。Iceberg Kafka Connect コネクタは複数テーブル同期時にソースデータベース名をターゲットデータベース名として自動的に使用するためです。コネクタには複数テーブルシナリオでソースデータベース名を異なるターゲットデータベース名にマッピングするオプションがないため、この命名の一貫性が必要です。 カスタムトピック名を使用する場合は、MSK Connect レコードオフセットを格納する新しいトピックを作成できます。 データ同期 (単一テーブルモード) を参照してください。 Amazon MSK コンソールで、以下の設定を使用して別のコネクタを作成します。 connector.class= org.apache.iceberg.connect.IcebergSinkConnector tasks.max=2 topics= iceberg.catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog iceberg.catalog.warehouse= iceberg.catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO iceberg.catalog.client.region= iceberg.tables.auto-create-enabled=true iceberg.tables.evolve-schema-enabled=true iceberg.control.commit.interval-ms=120000 transforms=debezium transforms.debezium.type=org.apache.iceberg.connect.transforms.DebeziumTransform iceberg.tables.route-field=_cdc.source iceberg.tables.dynamic-enabled=true key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter value.converter.schemas.enable=false key.converter.schemas.enable=false iceberg.control.topic=control-iceberg この設定では、2 つのパラメータが追加されています: iceberg.tables.route-field : 異なるテーブルを区別するルーティングフィールドを指定します。Debezium でパースされた CDC データの場合は cdc.source と指定します。 iceberg.tables.dynamic-enabled : iceberg.tables パラメータが設定されていない場合、ここで true を指定する必要があります。 完了後、MSK Connect がシンクコネクタを作成します。 プロセス完了後、Athena で新しく作成されたテーブルを確認できます。 その他のヒント ここでは、ユースケースに合わせてデプロイをカスタマイズするためのヒントを紹介します。 指定テーブルの同期 「データ同期 (複数テーブルモード)」セクションでは、 iceberg.tables.route-field = _cdc.Source と iceberg.tables.dynamic-enabled=true を指定しました。この 2 つのパラメータで、複数テーブルを Iceberg テーブルに書き込めます。指定したテーブルのみを同期する場合は、 iceberg.tables.dynamic-enabled = false を設定し、 iceberg.tables パラメータで同期するテーブル名を指定します。例: iceberg.tables.dynamic-enabled = false iceberg.tables = default.tablename1,default.tablename2 iceberg.table.default.tablename1.route-regex = tablename1 iceberg.table.default.tablename2.route-regex = tablename2 パフォーマンステスト結果 データ同期機能を評価するため、 sysbench を使用してパフォーマンステストを実施しました。テストでは、システムのスループットとスケーラビリティを示すために大量書き込みシナリオをシミュレートしました。 テスト設定: データベースセットアップ : sysbench を使用して MySQL データベースに 25 テーブルを作成 データロード : 各テーブルに 2,000 万レコードを書き込み (合計 5 億レコード) リアルタイムストリーミング : 書き込みプロセス中に MySQL から Amazon MSK にリアルタイムでデータをストリーミングするよう MSK Connect を設定 Kafka Connect 設定 : Kafka Iceberg Connect を起動 最小ワーカー数: 1 最大ワーカー数: 8 ワーカーあたり 2 MCU を割り当て パフォーマンス結果: 上記の設定でテストした結果、各 MCU が約 10,000 レコード/秒のピーク書き込みパフォーマンスを達成しました。高スループットのデータ同期ワークロードを効果的に処理できることが実証されました。 クリーンアップ リソースをクリーンアップするには、以下の手順を実行します: MSK Connect コネクタを削除 : このソリューション用に作成した Debezium MySQL Connector と Iceberg Kafka Connect コネクタの両方を削除します。 Amazon MSK クラスターを削除 : このデモ用に新しい MSK クラスターを作成した場合は、課金を停止するために削除します。 S3 バケットを削除 : カスタム Kafka Connect プラグインと Iceberg テーブルデータの保存に使用した S3 バケットを削除します。削除前に必要なデータをバックアップしてください。 EC2 インスタンスを削除 : Iceberg Kafka Connect プラグインをビルドするために EC2 インスタンスを起動した場合は、終了します。 RDS MySQL インスタンスを削除 (オプション): このデモ用に新しい RDS インスタンスを作成した場合は削除します。既存の本番データベースを使用している場合は、このステップをスキップしてください。 IAM ロールとポリシーを削除 (作成した場合): セキュリティのベストプラクティスを維持するため、このソリューション用に作成した IAM ロールとポリシーを削除します。 まとめ 本記事では、Amazon MSK Connect と Iceberg Kafka Connect を使用して、トランザクションデータベースからデータレイクへのリアルタイムで効率的なデータ同期を実現するソリューションを紹介しました。エンタープライズレベルのビッグデータ分析に低コストで効率的なデータ同期パラダイムを提供します。EC トランザクション、金融取引、IoT デバイスログなど、どのようなデータを扱う場合でも、データレイクへの迅速なアクセスを実現し、分析ビジネスが最新のビジネスデータを素早く取得できるようになります。ぜひご自身の環境でお試しいただき、コメントセクションで体験を共有してください。詳細については、 Amazon MSK Connect をご覧ください。 著者について Huang Xiao Huang は、AWS のアナリティクス担当シニアスペシャリストソリューションアーキテクトです。ビッグデータソリューションのアーキテクチャ設計を専門とし、ビッグデータ分野での開発とアーキテクチャ設計に長年の経験があります。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。