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

本記事は 2025/11/25 に公開された “ Physical AI in practice: Technical foundations that fuel human-machine interactions | Artificial Intelligence ” を翻訳したものです。 前回の投稿「 AI で物理的世界を変革：インテリジェント自動化の新たなフロンティア 」では、フィジカル AI の分野が建設、製造、ヘルスケア、農業など幅広い産業を再定義していることを解説しました。今回は、この技術の背後にある完全な開発ライフサイクル、つまり単に指示に従うだけでなく、協働し、要件を予測し、共通の目標に向けて積極的に推進することで、人間と真のパートナーシップを築くインテリジェントシステムを作成するプロセスに注目します。 このワークフローの実例として、 Diligent Robotics がフィジカル AI の原則を適用して、病院環境で臨床チームを支援する移動ロボットをどのように開発しているかを紹介します。また、業務と顧客体験の両方を改善できるフィジカル AI ソリューションを導入しようとしているビジネスリーダー向けに重要な考慮事項も共有します。 フィジカル AI の定義 人間と機械の関係は、根本的な変革を遂げつつあります。直接的な人間の制御下にある単純なツールとして始まったものが、今では、知的な機械がコンテキストを理解し、意図を解釈し、自律的な意思決定を行うことができる高度なパートナーシップへと進化しています。 「フィジカル AI」という用語は、対話的かつ反復的なシステムを指します。フィジカル AI とは、さまざまなパターンで要素が連携し、物理世界を理解し、推論し、学習し、相互作用するプロセスです。自律性フライホイールの各ステップにおいて、要素は継続的に学習と改善を重ね、次のステップへと進化を促します。 このプロセスは理解から始まります。ここでは、モデルとアルゴリズムをセンサー、実世界データ、シミュレーションデータと統合し、これらのデータセットを用いて推論能力を構築します。次に、推論モデルが物理世界でリアルタイムに実行されるアクションを予測します。しかし、これらのインテリジェントシステムのプロセスはそこで終わりません。システム全体のパフォーマンスを向上させるため、フィードバックループを通じて継続的に学習を重ねる必要があります。 人間と機械のチームワークのためのエンドツーエンドのフィジカル AI ワークフロー この高度な自律性における次の飛躍には、何が必要となるのでしょうか？フィジカル AI ソリューションの開発と展開は、データの収集と準備、モデルのトレーニングと最適化、エッジでの運用を含む反復的なプロセスです。開発ライフサイクルは次の図に示されています。それぞれの要素を見ていきましょう。 データの収集と準備 ワークフローの最初のステップは、モデルのトレーニングや評価といった後続タスクのために、データを収集し準備することです。これには、特定のアプリケーション向けに独自に収集したデータのほか、オープンソースデータやシミュレーションデータが含まれます。これらのデータソースは、後続タスクに応じて保存、クレンジング、フィルタリングが行われます。 モデルのトレーニングとファインチューニング フィジカル AI システムを現実世界と効果的に相互作用できるようトレーニングすることは、従来の機械学習アプローチを超える独自の課題を伴います。これらのシステムは、複雑で動的な環境を移動し、さまざまな特性を持つ物体を操作し、予期しない状況に適応することを学習する必要があります。多様な実環境で確実に動作する、有能かつ堅牢なフィジカル AI システムを開発するための専門的なトレーニング手法が登場しています。これらには以下が含まれます: 強化学習 ：自律機械は、環境との試行錯誤による相互作用を通じてスキルを学習できます。ラベル付きデータセットを必要とする教師あり学習とは異なり、強化学習では、報酬関数を最大化することで、フィジカル AI システムが経験から直接学習することができます。 物理知識を組み込んだ強化学習 ：学習プロセスに物理的知識を統合して、サンプル効率と汎化性能を改善します。このアプローチは、純粋なデータ駆動型手法と従来の物理ベースの制御との間のギャップを埋めるのに役立ちます。 模倣学習 ：フィジカル AI システムは、試行錯誤ではなく、人間によるデモンストレーションから学習できます。このアプローチは、報酬関数で指定することが難しいものの、人間が容易に実演できるタスクに特に有効です。行動クローニングや逆強化学習などの技術により、ロボットは人間の行動を観察し、その背後にあるポリシーや報酬関数を推測することができます。 シミュレーションベースのトレーニング ：物理システムの仮想レプリカを提供し、実環境での展開前に安全かつ費用対効果の高いトレーニングをサポートします。デジタルツインは、専門的な AI モデルのトレーニングのためのシミュレーションシステムとして機能し、開発者は実環境での展開前にロボットの動作をテストおよび改良できます。シミュレーションベースのトレーニングは、安全性、速度、スケーラビリティ、再現性、費用対効果などの利点を提供します。 モデルの最適化 モデルのトレーニングが完了すると、特定のハードウェア、レイテンシー要件、計算コスト、パフォーマンスなどに合わせて最適化できます。モデル最適化の手法には以下が含まれます: 量子化 ：重みと活性化の数値精度を削減します。一般的な量子化手法には、 float32 から float16 への変換、 float32 から int8 への変換などがあります。量子化により、メモリ使用量を削減し、推論速度を向上させることができます。 蒸留 ：大規模なモデルから小規模なモデルへ知識を転送しながら、パフォーマンスを維持します。小規模なモデルは、低性能なハードウェアにも展開でき、計算コストも低くなります。 エッジ対応モデルは、実環境・シミュレーション環境でのタスクで評価されます。モデルのトレーニング・最適化は、目標とするパフォーマンスが達成されるまで反復的に改良されます。 エッジ操作 最後に、最適化されたモデルは現場に展開され、実環境の実際のハードウェアで機能を検証します。システムは運用データと性能指標を継続的に収集し、これらを分析のためにクラウド環境へ体系的に送信します。クラウド基盤では、追加のモデルトレーニングと最適化を実行できます。修正されたモデルはエッジに再展開され、そこでモデル推論（エッジコンピューティング）が実行されます。エッジコンピューティングでは、ロボットアームの停止やゲートの開閉といった決定とアクションが行われます。このセンシング、推論、実行のワークフローが、継続的な改善サイクルを生み出します。ミッションクリティカルなアプリケーションでは、わずか数ミリ秒でアクションを予測する能力が重要となります。 実践における技術：Diligent Robotics がヘルスケアをどのように変革しているか インテリジェントシステムがニーズを予測し、人間と協働するこのプロアクティブなパートナーシップを支える技術は、単なる理論ではありません。これらの技術はすでに実装されており、具体的な成果を上げています。例えば、リスクが高く、人間とのつながりが極めて重要なヘルスケア分野での活用が挙げられます。 看護師の日常を考えてみましょう。看護師は通常、患者ケアから離れざるを得ない業務に1日の多くの時間を費やしています。例えば、薬剤の配送、検体の搬送、物品の調達などです。AWS Physical AI Fellow である Diligent Robotics は、上述のワークフローを用いてこの課題に取り組んでいます。Moxiは、日常的な物流業務を処理し、看護師とその患者に貴重な時間を取り戻すために設計された移動型マニピュレーションロボットです。 Moxi の知能は、病院環境から継続的に学習することで成長します。ロボットは運用データを収集し、それを基盤モデルに供給します。この反復プロセスにより、Moxi の信頼性が向上し、医療施設の複雑かつ動的な環境を移動する能力が高まります。モデルは効率性のために最適化され、計算能力の削減と処理速度の向上を実現します。これにより、エッジへの展開が可能になります。エッジ展開により、Moxi はエレベーターのボタンを押す、ドアを開けるといった動作をリアルタイムで自律的に判断できます。これは、常時接続に依存できない安全性が重要な環境では極めて重要です。 結果は顕著で、Diligent Robotics は次のように報告しています： 120 万回以上の配達 が Moxi の病院艦隊全体で完了しました 病院スタッフの 60 万時間近く の節約 Moxi は全国の医療システムで成果を上げています。例えば、ニューヨーク州のロチェスター・リージョナル・ヘルスでは、Moxi ロボットが以下のような成果を実現しています: 薬剤配送ワークフローの改革 ：Meds to Beds プログラムなどにおいて、Moxi が緊急性の高い薬剤配送をサポートすることで、退院遅延を削減し、患者満足度を向上させ、再入院を最小限に抑えています 検査ワークフローの効率化 ：検査結果の確実性と迅速性を向上させ、患者への提供を改善しています Moxi の影響は数字以上のものです。ロチェスター地域保健のチーフファーマシーオフィサーは次のように述べています。「私たちは次世代のヘルスケアを設計することに焦点を当てており、そのためには可能な限りあらゆるところで革新を行っています。Moxi は私たちの業務に欠かせないものとなっています。」 Diligent Robotics の創設者兼 CEO である Andrea Thomaz は次のように述べています。「臨床チームが Moxi と『おはよう』と挨拶を交わしたり、ハイファイブをしたり、さらには『今週の従業員』と名付けたりするなど、チームの本当のメンバーとして Moxi と交流しているのを見るのは、最も報酬の高い人間とロボットの経験の 1 つです。」 フィジカル AI の今後の方向性 フィジカル AI の今後の道筋は、実環境でその価値を証明している先進的な導入企業によってすでに切り開かれています。病院ではバーンアウトを削減し患者ケアを向上させ、工場では安全性と一貫性を高めています。これらの成果は明確なメッセージを示しています。成功は大規模な刷新からではなく、測定可能な成果をもたらす、焦点を絞ったインパクトの大きい用途から生まれるということです。 最先端技術だけでソリューションを構築するだけでは不十分です。フィジカル AI システムが私たちの世界により深く統合されるにつれ、ビジネスリーダーにとって適切なガバナンスが不可欠になっています。最近のブレイクスルーは新たな機会をもたらす一方で、新たな課題も生み出しています。企業リーダーは以下の点に対処する必要があります: サイバーセキュリティ ：クラウド接続されたロボット群向けのセキュリティ対策 相互運用性 ：システムと既存インフラストラクチャ間の互換性確保 安全機構 ：適応的アプローチと冗長システムを含む安全対策 倫理的枠組み ：透明性、公平性、プライバシーを確保する仕組み 規制手法は管轄区域によって異なります。例えば、EUは安全性・倫理に対応する包括的な枠組みを採用していますが、米国は業界主導による分野別アプローチを採用しています。 ビジネスリーダーは、一貫したグローバル運用を維持しながら、これらの異なる基準に対応する必要があります。リスクベースのガバナンス手法は効果的な戦略となります。これは、AI アプリケーションを潜在的な影響に基づいて分類し、それに応じて適切な管理策を適用するものです。このバランスの取れた手法は、多様な規制要件を満たしつつ、継続的なイノベーションに必要な俊敏性を維持します。 小規模から始め、迅速に学習し、成功したものをスケールアップすることで、組織は持続的な能力を構築し、明確な ROI を実現し、フィジカル AI 革命の最前線でより広範な実装に向けた態勢を整えることができます。未来を切り開くのは、ガバナンス、安全性、倫理的配慮に積極的に対処しながら、デジタルインテリジェンスと物理的能力を統合できる組織です。 AWS、MassRobotics、NVIDIA が推進する Physical AI Fellowship のようなイニシアチブは、この種の進歩を加速するために必要な協力的精神を体現しています。 フィジカル AI の始め方 フィジカル AI が貴社の業務をどのように変革できるか、探ってみませんか？ Generative AI Innovation Center について、そして組織がコンセプトから本番環境対応のフィジカル AI ソリューションへと進む過程をどのように支援しているかをご確認ください。 AWS アカウントマネージャーにお問い合わせいただき、フィジカル AI ソリューションについてご相談ください。貴社のニーズに合わせた実装サポートをご利用いただけます。 このブログはソリューションアーキテクトの水野貴博が翻訳しました。 著者について Sri Elaprolu は AWS Generative AI Innovation Center のディレクターであり、企業・政府組織向けに最先端の AI ソリューションの実装を支援するグローバルチームを率いています。AWS での13年間の在籍期間中、NFL、Cerner、NASA などの組織と連携する機械学習サイエンスチームを率いてきました。AWS 入社以前は、Northrop Grummanで14年間、製品開発およびソフトウェアエンジニアリングのリーダーシップ職を歴任しました。Sri は工学修士号と MBA を取得しています。 Alla Simoneau は 15 年以上の経験を持つ技術・ビジネス分野のリーダーであり、現在は Amazon Web Services（AWS）で新興技術部門フィジカル AI 責任者を務め、AI と実世界のアプリケーションの融合領域でグローバルなイノベーションを推進しています。Amazon に10年以上在籍する Alla は、戦略、チーム構築、オペレーショナルエクセレンスにおいて高く評価されているリーダーであり、最先端技術をスタートアップや企業顧客向けの実世界での変革へと転換することを専門としています。 Paul Amadeo は人工知能、機械学習、IoT システム、RF 設計、光学、半導体物理学、先進工学にまたがる 30 年以上の経験を持つベテラン技術リーダーです。AWS Generative AI Innovation Center のフィジカル AI 技術リードとして、Paul は AI 機能を具体的なフィジカルシステムに転換することを専門とし、企業顧客をコンセプトから本番環境までの複雑な実装プロセスを通じてガイドしています。彼の多様な経歴には、エッジ環境向けコンピュータビジョンシステムの設計、世界中で数十億のデバイスを生産したロボットスマートカード製造技術の設計、商業・防衛部門の両方における部門横断チームのリーダーシップが含まれます。Paul はカリフォルニア大学サンディエゴ校で応用物理学修士号、カリフォルニア工科大学で応用物理学学士号を取得し、光学システム、通信デバイス、製造技術にまたがる 6 つの特許を保有しています。 Laura Kulowski は AWS Generative AI Innovation Center のシニア応用科学者であり、顧客と協力して生成 AI ソリューションを構築しています。Amazon 入社前、Laura はハーバード大学地球惑星科学科で博士号を取得し、ジュノー探査機のデータを用いて木星の深部帯状流と磁場を研究しました。

本記事は 2025/12/02 に公開された “ Embodied AI Blog Series, Part 1: Getting Started with Robot Learning on AWS Batch | AWS Spatial Computing Blog ” を翻訳したものです。 私たちは技術的進化の転換点を迎えました：高度な AI モデルを使用して、デジタル世界だけでなく物理的な世界にも影響を与える能力です。AI は、テキストを生成する AI から、原子を動かす AI へと移行しつつあります。衣服を折りたたみ、物流を整理し、複雑な物理的タスクを通じて推論を行うことで、日常生活を拡張しつつあります。しかし、非構造的で動的な物理世界と相互作用する技術をうまく統合するには、それを実現するコードだけでなく、再現性、大規模性、そして緻密な研究が必要です。 解決策は ロボット学習 の中にあります：古典的なモデルベースの制御から、データ駆動型のパラダイムへの移行により、自律システムに前例のない能力が解き放たれます。これは多層にわたるライフサイクルで、物理およびシミュレートされたハードウェア統合、統合された遠隔操作と制御、データセットの収集と拡張、ポリシーのトレーニングと評価、そして推論の最適化が含まれます。 図は人間のオペレーターとロボットが  TWIST2 の遠隔操作インターフェースを通じて首の動きを同調させ 、ハードウェアの統合、制御、データ収集を行うプロセスを示しています 過去 2 年間で、ロボット学習コミュニティは転換点を迎えました。Diffusion Policy や Action Chunking Transformers（ACT）のような模倣学習フレームワークは、実演データから操作タスクを学習するのに効果的であることが証明されました。一方、π0（Pi Zero）、NVIDIA Isaac GR00T、Molmo-Act などの汎用的なビジョン・言語・アクション（VLA）モデルは、視覚と自然言語理解を組み合わせて、様々なタスクや実装を超えた汎化を提供しています。こうした方法論的な飛躍と共に、NVIDIA Cosmos Predict のようなワールドモデリングアプローチは、ロボットが行動する前に将来の状態をシミュレートし予測することを可能にし、HIL-SERL のような強化学習方法 (Reinforced Learning, RL) は、人間のフィードバックと RL を組み合わせて、現在の状態に基づいてサンプル効率の高い学習やタスク報酬モデルを実現します。重要なことに、Hugging Face の LeRobot のようなオープンソースプロジェクトは、このスタックを民主化し、開発に貢献するために必要な標準化されたデータセット、トレーニングパイプライン、評価ベンチマークを提供しています。 NVIDIA Isaac GR00T は、ロボット学習のための汎用基盤モデルとして際立っています。オープンソースであり、開発者は独自のデータで事前トレーニングまたはファインチューニングすることができます。特に、 GR00T N1.5 3B は、実世界のデモンストレーション、 Isaac Lab からの合成データ、インターネット規模のビデオからなる広大な「データピラミッド」でトレーニングされました。様々なタスクと実装を超えた強力な汎化能力を提供します。GR00T N1.5 をファインチューニングすることで、事前トレーニングされた知識を活用して、大幅に少ない実演回数で高いパフォーマンスを達成できます。トレーニング時間を数ヶ月から数時間に短縮しつつ、エッジまたはクラウドのいずれかにデプロイする柔軟性を維持します。事前トレーニングされた GR00T ベースのモデルの商用利用については、NVIDIA の最新のライセンス要件を参照してください。 シミュレーションされた SO-ARM101 を用いて 60 未満の実演データでファインチューニングされた GR00T N1.5 モデルが、leisaac キッチンシーンで視覚によるガイドを元に操作を行い、スムーズな動きとフォールトトレランス性を備え、ボウルの位置を正確に把握してオレンジを配置します このブログシリーズのパート 1 では、AWS 上で Isaac GR00T N1.5 3B を簡単にファインチューニングするためのスケーラブルなインフラストラクチャを構築する方法を示します。クラウドの弾力性と NVIDIA の先進的なロボット学習スタックを組み合わせることで、開発サイクルを加速し、ポリシーを迅速に反復し、大規模なデータセットを管理し、高忠実度シミュレーションでパフォーマンスを検証することができます。 ソリューションの概要 以下のアーキテクチャ図は、デプロイする内容を示しています。これは、セキュアな Amazon VPC 内のスケーラブルなエンドツーエンド VLA ファインチューニングパイプラインです。ワークフローは、 Amazon S3 、HuggingFace、またはローカルストレージに保存された生データセットとベースモデルから始まります。一貫性を確保するために、 AWS CodeBuild はトレーニング環境をコンパイルし、NVIDIA Isaac GR00T の依存関係を Docker イメージにカプセル化し、 Amazon ECR に保存します。 ファインチューニングジョブが送信されると、 AWS Batch は、コスト効率の高い Amazon EC2 インスタンスを GPU で動的にプロビジョニングし、コンテナをプルしてトレーニングワークロードを実行します。これらのインスタンスは、モデルのチェックポイントとログをリアルタイムで保持するために、共有の Amazon Elastic File System (Amazon EFS) ボリュームをマウントします。 トレーニングと並行して、 Amazon DCV 対応の EC2 インスタンスがシミュレーションと評価のために NVIDIA Isaac Lab を実行します。同じ EFS ボリュームをマウントすることで、このインスタンスはトレーニングメトリクス（TensorBoard 経由）をすぐに可視化し、最新のチェックポイントを使用したポリシー評価を可能にし、シームレスなフィードバックループを作り出します。 このファインチューニングパイプラインをデプロイし、シミュレーションでファインチューニングされたポリシーをトレーニングおよび評価する手順を見ていきましょう。 前提条件 この投稿では、 AWS CDK （AWS Cloud Development Kit、使い慣れたプログラミング言語を使用してクラウドインフラストラクチャを定義するためのフレームワーク）を使用して AWS Batch リソースをデプロイします。 AWS CDK をインストールする npm install -g aws-cdk リポジトリをクローンする git clone https://github.com/aws-samples/sample-embodied-ai-platform.gitcd sample-embodied-ai-platform CDK アプリの Python 依存関係をインストールする： cd training/gr00t/infra pip install -r requirements.txt CDK をブートストラップする（このアカウント/リージョンですでに行った場合はスキップ可能） 注： YOUR_AWS_PROFILE と YOUR_AWS_REGION をあなたの認証プロファイルとターゲットリージョンに置き換えてください。 cdk bootstrap --profile YOUR_AWS_PROFILE --region YOUR_AWS_REGION 1. 模倣学習のための Lerobot データセットを確認する シミュレートされた SO-ARM101 をリモート操作し、オレンジを拾い上げて皿に置くというデータセットがリポジトリに提供されています。Git LFS を使用して提供されている シミュレーションデータセット をダウンロードして確認できます。 Git LFS をインストールするには、この ウェブサイト の説明をご覧ください。 git lfs pull サンプルデータセットは training/sample_dataset ディレクトリで利用可能になります。 あるいは、別の Lerobot 互換データセット がある場合は、 Lerobot データセットビジュアライザ で確認できます。カスタムエンボディメントの場合は、 meta フォルダに modality.json ファイルがあることを確認してください。カスタムエンボディメントの要件の詳細については、 Isaac GR00T ファインチューニングドキュメント を参照してください。 提供された トレーニングスクリプト では、データセットに modality.json ファイルが欠けている場合、 SO-ARM with dual-camera セットアップが自動的に適用されます。 2. ファインチューニングパイプラインのセットアップ デフォルトでは、以下の手順ではファインチューニングに us-west-2 リージョンを使用しますが、 G6e、P4d または P5 インスタンスファミリーをサポートするリージョン であればどれでも使用可能です。 このセクションでは、AWS Batch on EC2 を使用して GR00T をファインチューニングするための再利用可能なパイプラインを作成します。これにより、新しいデータセットやモデルでの将来のファインチューニング実行は、異なる環境変数で新しいジョブを送信するだけで済みます。 一回のトレーニングジョブは Jupyter ノートブック（例：Amazon SageMaker CodeEditor / JupyterLab を使用し、 Hugging Face Lerobot × NVIDIA ガイド に従う）で簡単に開始できます。しかし、機械学習エンジニアリングチームは、データセットやモデルの頻繁な更新により、信頼性、再現性、コスト効率に優れたパイプラインを要求することがよくあります。物理的な AI モデルのトレーニングには、通常、マルチコンテナセットアップによるシミュレーションが含まれます。AWS Batch は、これを安全かつスケーラブルに実行できます。 g6e.2xlarge（またはそれ以上の）インスタンスを起動するのに十分なクォータがあることを確認してください。選択したリージョン（例： us-west-2 ）で、AWS Service Quotas コンソール経由でより多くのコンピュートリソースをリクエストできます（「オンデマンド G および VT インスタンスの実行」には少なくとも 8 vCPU を推奨します）。 AWS CDK スタックのデプロイ AWS CDK スタック がリポジトリで提供されており、ファインチューニングパイプラインをすぐに開始するのに役立ちます。スタックは、以下の表にリストされているファインチューニングパイプラインに必要なリソースを自動的に作成します： リソース 名前 目的 VPC BatchVPC パブリック/プライベートサブネットとNATゲートウェイを備えた分離された仮想ネットワーク Security Group BatchEFSSecurityGroup BatchインスタンスとEFS間のNFSトラフィックを許可するセキュリティグループ Elastic File System BatchEFS モデルチェックポイントとトレーニングログ用の共有ストレージ (Optional) S3 Bucket IsaacGr00tCheckpointBucket ファインチューニングモデルのチェックポイントを保管するためのS3バケット (Optional) CodeBuild Gr00tContainerBuild ファインチューニングされた Docker イメージを構築して ECR にプッシュするための AWS CodeBuild プロジェクト Elastic Container Registry gr00t-finetune Docker イメージをファインチューニングするためのコンテナレジストリ EC2 Launch Template BatchLaunchTemplate 大きなコンテナイメージを実行するためのルートボリュームを増やした EC2 構成 Batch Compute Environment IsaacGr00tComputeEnvironment GPUインスタンス用のAWSバッチコンピューティング環境 Batch Job Queue IsaacGr00tJobQueue ファインチューニングジョブの送信と管理のための AWS Batch ジョブキュー Batch Job Definition IsaacGr00tJobDefinition コンテナ仕様の AWS Batch ジョブ定義テンプレート EC2 Instance DcvInstance ファインチューニングされたポリシーのシミュレーションと評価結果をAmazon DCV で可視化するための EC2 インスタンス スタックをデプロイするには、以下のコマンドを実行します。AWS プロファイル/IAM ロールがリソースの作成を許可していることを確認してください： # リポジトリのルートディレクトリから cd training/gr00t/infra cdk deploy IsaacGr00tBatchStack IsaacLabDcvStack --profile YOUR_AWS_PROFILE --region YOUR_AWS_REGION デフォルトでは、Batch スタックは infra フォルダをパッケージ化して AWS CodeBuild にアップロードし、Dockerfile からコンテナイメージをビルドして Amazon ECR にプッシュします。これには通常 10〜20 分かかります。既存のコンテナイメージを使用したい場合は、スタックをデプロイする際に環境変数としてカスタムの ECR イメージ URI を指定して、CodeBuild のプロセスをスキップできます： ECR_IMAGE_URI=<ECR_IMAGE_URI> cdk deploy IsaacGr00tBatchStack IsaacLabDcvStack その他のデプロイメントパス 環境と好みに応じて、インフラストラクチャを設定するための複数のパスが利用可能です。このブログでは、AWS CDK を使用してローカルマシンからすべてを自動的にデプロイします。このパスは、迅速なセットアップやプログラムによるカスタマイズを可能にするために選択されています。AWS Batch リソースの設定をよりよく理解し、AWS コンソールのナビゲーションに慣れるために、AWS コンソールを介してすべてのリソースを段階的に作成したい場合は、 コンソールウォークスルーパス に従うことができます。 3. ファインチューニングジョブの送信と監視 AWS Batch リソースが整えば、ファインチューニングジョブを繰り返し実行できます。新しいデータセット（例：新しいエンボディメントやタスク用）を収集/追加するたびに、ジョブ環境変数を更新し、ジョブキューに新しいジョブを送信するだけです。AWS Batch は必要に応じて自動的にコンピュートリソースを開始および停止します。 ジョブを送信するには、AWS Batch コンソールまたは AWS CLI を使用できます。 オプション A – AWS Batch コンソール : 左側のナビゲーションペインで ジョブ を選択し、右上にある 新しいジョブの送信 を選択します。 名前 に IsaacGr00tFinetuning と入力し、 ジョブ定義 で IsaacGr00tJobDefinition を選択し、 ジョブキュー で IsaacGr00tJobQueue を選択して 次へ を選択します。残りはデフォルトのままにして、もう一度 次へ を選択し、 ジョブの送信 を選択します。 デフォルトでは、ジョブはリポジトリで提供されているサンプルデータセットで GR00T をファインチューニングします。特定のデータセットでファインチューニングしたい場合は、 コンテナオーバーライド の下にある 環境変数 を更新できます。例えば、 HF_DATASET_ID を設定して、カスタムの Lerobot データセットでファインチューニングすることができます。設定可能な環境変数のリストについては、 サンプルの環境変数ファイル を参照してください。 オプション B – AWS CLI : AWS CLI がインストール され、正しいプロファイルとリージョンで設定されていることを確認します。次に、次のコマンドを実行してジョブを送信します： aws batch submit-job \ --job-name "IsaacGr00tFinetuning" \ --job-queue "IsaacGr00tJobQueue" \ --job-definition "IsaacGr00tJobDefinition" \ --container-overrides "environment=[{name=HF_DATASET_ID,value=<YOUR_HF_DATASET_ID>}]" オプションで、リージョンを --region <REGION> 、プロファイルを --profile YOUR_AWS_PROFILE 、環境変数を --container-overrides "environment=[{name=HF_DATASET_ID,value=<YOUR_HF_DATASET_ID>}]" でオーバーライドするために次のものを追加できます。 デフォルトでは、ジョブは GR00T を 6000 ステップでファインチューニングし、2000 ステップごとにモデルのチェックポイントを保存します。これは通常、g6e.4xlarge インスタンスで最大 2 時間かかります。ジョブを送信する際に MAX_STEPS と SAVE_STEPS 環境変数をオーバーライドすることで、ステップ数と保存頻度を変更できます。モデルをより速くファインチューニングしたい場合は、 GPU - optional フィールドをオーバーライドし、 NUM_GPUS 環境変数を追加して使用したい GPU の数を指定することで、ジョブに追加の GPU を要求できます。詳細については、 GR00T コンポーネントドキュメント を参照してください。 ジョブの進行状況を監視する コンソールまたは CLI を使用して、ステータスを追跡し、ログをストリーム配信できます。 オプション A – AWS Batch コンソール ジョブ に移動し、 IsaacGr00tJobQueue ジョブキューを選択して 検索 を選択します。送信したジョブとそのステータスがリストに表示されるはずです。 送信したジョブをクリックして Logging タブを選択します。ログがリアルタイムで表示されるはずです。 オプション B – AWS CLI JOB_ID （上記の batch submit-job 出力から）を提供し、オプションで REGION と PROFILE を設定して次のコマンドを実行します。ジョブのステータスを確認します： REGION=<REGION> PROFILE=<PROFILE> JOB_ID=<JOB_ID>; aws batch describe-jobs --jobs "$JOB_ID" \ --query 'jobs[0].{status:status,statusReason:statusReason,createdAt:createdAt,startedAt:startedAt,stoppedAt:stoppedAt}' \ --output table --region "$REGION" --profile "$PROFILE" ジョブが RUNNING ステータスになると、リアルタイムでログをストリーム配信できます： REGION=<REGION> PROFILE=<PROFILE> JOB_ID=<JOB_ID>; aws logs tail /aws/batch/job \ --log-stream-names "$(aws batch describe-jobs --jobs "$JOB_ID" --query 'jobs[0].container.logStreamName' --output text --region "$REGION" --profile "$PROFILE")" \ --follow --region "$REGION" --profile "$PROFILE" 注：ジョブが実行中の場合、セクション 4 で説明する評価環境を使用して、トレーニングの進行状況を監視し、メトリクスをリアルタイムで可視化することもできます。これにより、ファインチューニングプロセス全体が完了するのを待つ代わりに、トレーニングパフォーマンスを追跡し、チェックポイントが利用可能になったときにチェックポイントを検査できます。 4. ファインチューニングされたポリシーを評価する トレーニングプロセスを監視し、シミュレートされた SO-ARM101 とオプションで物理的な SO-ARM101 を使用してファインチューニングされたポリシーを評価できます。また、トレーニングの進行に合わせてテンソルボードログを視覚化することもできます。 チェックポイントが利用可能になると、 DcvInstance で GR00T ポリシーサーバーを起動し、IsaacLab を起動して、シミュレートされた環境でファインチューニングされたポリシーを視覚化および評価できるようになります。 セクション 2 で CDK スタックをデプロイした際、Amazon DCV EC2 インスタンスは初期化と ユーザーデータスクリプト の実行に数分かかります。インスタンスにログインしたら、ターミナルで sudo cat /var/log/dcv-bootstrap.summary を実行してステータスを確認できます。19 個の STEP_OK と最後の STEP_OK:EFS mount が表示されれば、インスタンスは準備完了です。このスタックは、Batch スタックに接続された同じ EFS を /mnt/efs にマウントするため、ジョブの実行中に TensorBoard のログとモデルのチェックポイントをライブで確認できます。 DCV インスタンスにログインし、TensorBoard を可視化してチェックポイントを検査します IsaacLabDcvStack のデプロイ出力（CLI または CloudFormation コンソール ）をチェックして、DCV インスタンスのパブリック IP アドレス（ DCVWebURL ）と認証情報（ DCVCredentials ）を取得し、その IP アドレスにアクセスして DCV セッションにログインします。 注：ブラウザで「Your connection is not private」という警告が表示される場合があります。無視して次のステップに進むか、 DCV Client を使用してインスタンスに接続してください。DCV インターフェースが読み込まれても「no session found」というエラーが表示される場合は、10 分後に再試行してください。トラブルシューティングとカスタマイズオプションについては、 ユーザーデータスクリプト を参照してください。 ログイン後、 Ctrl + Alt + T （または macOS の場合は Control + Option + T ）を使用してターミナルを開くと、 /mnt/efs/gr00t/checkpoints/runs ディレクトリに tensorboard ログがあるはずです。 ls -l /mnt/efs/gr00t/checkpoints/runs 次のコマンドを実行して tensorboard サーバーを起動します： # If the conda environment is not activated, run: conda activate isaac tensorboard --logdir /mnt/efs/gr00t/checkpoints/runs --bind_all tensorboard サーバーはポート 6006 で実行されるはずです。DCV インスタンス内で自動生成された URL を「Ctrl + クリック」するか、任意のクライアント（例：ローカルラップトップのブラウザ）で DcvInstance のパブリック IP アドレス（例： http://<DCV_INSTANCE_PUBLIC_IP>:6006 ）を使用してアクセスできます。 GR00T のファインチューニングの進捗状況をリアルタイムで視覚化し、4 つの主要なトレーニングメトリクスを示しています：エポックの進行（左）、勾配ノルムの安定化（中央左）、学習率スケジュール（中央右）、および損失の収束（右）。 ファインチューニングジョブが完了したら、 /mnt/efs/gr00t/checkpoints ディレクトリでモデルのチェックポイントを確認できます。 Isaac GR00T コンテナを実行し、ポリシーサーバーを起動します Amazon Elastic Container Registry コンソール に移動し、 gr00t-finetune コンテナリポジトリを選択します。右上の View push commands をクリックして、ECR に認証するための最初のコマンドを表示します。コマンドは次のようになります： aws ecr get-login-password --region <REGION> | docker login --username AWS --password-stdin <ECR_PREFIX> <ECR_IMAGE_URI> を取得するには、最新のイメージタグの URI（例： 1234567890.dkr.ecr.us-west-2.amazonaws.com/gr00t-finetune:latest ）をコピーし、次のコマンドを実行してイメージをプルし、EFS を読み取り専用としてマウントした状態でインタラクティブシェルを開始します： docker run -it --rm --gpus all --network host -v /mnt/efs:/mnt/efs:ro --entrypoint /bin/bash <ECR_IMAGE_URI> コンテナ内 で、 <STEP> （例： 6000 ）によってチェックポイントを選択し、サーバーを起動します： MODEL_STEP=<STEP> # e.g. 6000 MODEL_DIR="/mnt/efs/gr00t/checkpoints/checkpoint-$MODEL_STEP" python scripts/inference_service.py --server \ --model_path "$MODEL_DIR" \ --embodiment_tag new_embodiment \ --data_config so100_dualcam \ --denoising_steps 4 サーバーが準備完了になると、次の出力が表示されます： Server is ready and listening on tcp://0.0.0.0:5555 leisaac キッチンシーンオレンジピッキングタスクを実行します。 DCV インスタンスで新しいターミナルを開き 、次のスクリプトを実行して leisaac キッチンシーンのオレンジピッキングタスクを起動します。これにより、シミュレートされた SO-ARM101 がコンテナで実行中の GR00T ポリシーサーバーに接続されます： # If the conda environment is not activated, run: conda activate isaac cd /home/ubuntu/leisaac OMNI_KIT_ACCEPT_EULA=YES python scripts/evaluation/policy_inference.py \ --task=LeIsaac-SO101-PickOrange-v0 \ --policy_type=gr00tn1.5 \ --policy_host=localhost \ --policy_port=5555 \ --policy_timeout_ms=5000 \ --policy_action_horizon=16 \ --policy_language_instruction="Pick up an orange and place it on the plate" \ --device=cuda \ --enable_cameras IsaacSim は初回の初期化に数分かかる場合があります。 このスクリプトを実行する前に、コンテナ内で推論サーバーが実行されていることを確認してください。シーンがロードされ、ターミナルに [INFO]: Completed setting up the environment... と表示されるまでに 3 ～ 5 分かかる場合があります。これはシーンがプレイする準備ができていることを示します。黄色の [Warning] メッセージと赤色の [Error] メッセージは無視してください。シーンがロードされると、シミュレートされた SO-ARM101 がオレンジを拾って皿に置くのが見えるはずです。IsaacSim アプリケーションウィンドウを選択して r キーを押すとシーンをリセットしてランダム化できます。または、ターミナルで Ctrl+C を押してシミュレーションを停止できます。 おめでとうございます！GR00T のファインチューニングが成功し、シミュレーションでファインチューニングされたポリシーを評価しました。手首と前面カメラを備えた物理的な SO-ARM101 をお持ちの場合は、ローカルのクライアントをリモートの GR00T ポリシーサーバーに接続することで、ローカルの物理的な SO-ARM101 でポリシーを評価することもできます。以下の手順に進んでください： デュアルカメラを備えた SO-ARM101 を組み立て、 Lerobot ガイド に従ってキャリブレーションします Isaac GR00T 公式ガイド に従ってローカルマシンに依存関係をインストールし、Isaac GR00T サンプルクライアント を実行して物理的な SO-ARM101 を制御します ローカルの GPU マシンもお持ちの場合は、GR00T ポリシーサーバーとサンプルクライアントの両方をローカルで実行できます。 Isaac-GR00T ガイド で詳細をご確認ください。 クリーンアップ 継続的な課金を避けるため、 cdk destroy コマンドで作成したリソースを削除してください。 # リポジトリのルートから cd training/gr00t/infra # まず DCV スタックを破棄します（EC2 インスタンスを終了し、EIP を解放します） cdk destroy IsaacLabDcvStack --force # Batch スタックを破棄します（Batch リソース、EFS、VPC を削除します。CDK によって作成された場合） cdk destroy IsaacGr00tBatchStack --force まとめ この投稿では、 AWS Batch 、 Amazon ECR 、および  Amazon EFS  を使用し、 Amazon DCV  によって強化された対話型評価環境と組み合わせて、AWS 上にケーラブルで再現可能なロボット学習パイプラインを構築しました。インフラストラクチャのプロビジョニングとコンテナ管理を自動化することで、最も重要なこと、つまり複雑な物理的タスクを解決するためのデータセットとポリシーの反復に集中できます。 このアーキテクチャは、ロボット学習ワークフローをスケーリングするための堅固な基盤を提供します。NVIDIA Isaac GR00T のような基盤モデルをファインチューニングする場合でも、LeRobot のようなオープンソースフレームワークを使用してゼロからポリシーをトレーニングする場合でも、弾力性のあるコンピューティングと共有ストレージの組み合わせにより、トレーニングとシミュレーション間のシームレスなフィードバックループを可能にする迅速な実験が可能になります。 有用な参考資料 Robotics Fundamentals Learning Path | NVIDIA Robot Learning: A Tutorial – a Hugging Face Space by lerobot Enhance Robot Learning with Synthetic Trajectory Data Generated by World Foundation Models | NVIDIA Technical Blog NVIDIA Isaac GR00T in LeRobot Amazon FAR – TWIST2 : Scalable, Portable, and Holistic Humanoid Data Collection System LightwheelAI/leisaac : LeIsaac は SO101Leader (LeRobot) を用いて、IsaaCLab に遠隔操作の能力を提供します。データの収集、変換、ポリシーの学習が含まれています。 翻訳はソリューションアーキテクトの山本が実施しました。 Kimate Richards AWS ストラテジックアーキテクト | ロボティクス | 生成 AI | 空間コンピューティング | シミュレーション | パイロット Aaron Su Aaron Su は Amazon Web Services のソリューションアーキテクトで、スタートアップ企業が AI ソリューションをコンセプトから本番環境まで構築し、スケールアップするのを支援しています。彼はフィジカル AI とエージェントシステムに深い情熱を持ち、オープンソースプロジェクト、展望ガイダンス、リファレンスアーキテクチャを通じて技術コミュニティに積極的に貢献しています。Aaron は世界中の何百ものスタートアップをサポートし、グローバルカンファレンスで技術セッションを提供しています。彼はスタートアップの共同創設者およびロボティクス研究者としての経験を持っています。 Frank Olotu Frank Olotu はシアトル、ワシントンを拠点とするソリューションアーキテクトで、AWS クラウド上で中小企業（SMB）や独立系ソフトウェアベンダー（ISV）向けにクラウドソリューションを設計および実装する 2 年以上の経験があります。彼は高度なロボティクス研究に情熱を注ぎ、余暇にはオープンソースのロボティクスイニシアチブに参加しています。また、カリフォルニア大学マーセド校でコンピュータサイエンス＆エンジニアリングの学士号を取得しています。 Cole Harrison Cole は AI/ML エンジニアで、コンピュータビジョン、言語モデリング、エージェント LLM アプリケーションなどの生産 ML システムを数十の Fortune 500 企業に提供してきました。実体化された AI に情熱を注ぐ Cole は、ロボット学習イニシアチブの社内コラボレーションだけでなく、学術およびオープンサイエンスコミュニティとの外部研究にも参加しています。Cole の研究は、操作のための 6D ポーズ推定、VLA 事前および事後トレーニング、ダイナミクス世界モデリングなど、ジェネラリストロボットポリシーを構築するためのさまざまなデータ中心のアプローチに焦点を当てています。

ディップ株式会社は、求人情報サイト「バイトル」や「はたらこねっと」などの運営や、中小企業の労働力を改善する DX ツール「コボットシリーズ」を提供する DX 事業を展開しています。2013 年から AWS を本格的に導入し、クラウドを活用したビジネス展開を積極的に推進してきた同社は、2024 年に基幹システムのデータベース基盤を、オンプレミス環境の Exadata から RDS for Oracle へと大規模な移行を実施しました。本ブログでは、 Amazon RDS for Oracle への移行プロジェクトの詳細について、お客様の声を紹介いたします。 移行検討の背景と課題 移行したデータベース基盤は、21 テラバイトという大規模なデータ、7,000 を超えるデータベースオブジェクト、約 5 万のユニークな SQL が稼働する複雑なシステムでした。万が一障害が発生した場合、億単位以上の機会損失リスクを抱えるミッションクリティカルなシステムとして、安定性と拡張性の確保が最重要課題となっていました。オンプレミス環境では、ハードウェアの物理的な制約により、急激なリソース需要の増加に対して迅速な対応が困難でした。リソース拡張などインフラの調達に向けたリードタイムや、ハードウェア障害のリスクも常に悩ませていました。さらに、システム停止や、ハードウェア障害などによる、長期間にわたるパフォーマンス劣化やシステム停止などによる対応に多くの工数を費やしており、本来注力すべき業務改善や新機能の開発に十分なリソースを割くことができない状況が続いていました。 移行先の検討では、 AWS 以外にも Oracle Cloud など複数のプラットフォームを比較検討しました。コスト最適化の可能性、システムの拡張性など、総合的な観点から AWS が最適との結論に至りました。データベースエンジンについては、将来的な Aurora PostgreSQL への移行を視野に入れながらも、段階的な移行アプローチを採用しました。まずは、アプリケーション改修コストを抑制し、現行システムの性能特性を維持できる同一エンジン(Amazon RDS for Oracle)への移行を第一ステップとして選択しました。移行性の判断では、 Insight Database Testing による SQL テストを活用し、 Exadata 上で実際に実行されている SQL をキャプチャし、移行先候補であった Aurora PostgreSQL に SQL を実行し、実行可否や実行結果に比較をツールが出力するテストレポートを元に判断されました。 アーキテクチャと移行プロセス 事前検討後、本格的な移行プロジェクトは 2024 年 4 月から 2024 年 9 月にかけて実施されました。 移行プロジェクトは、以下の段階で進められました。 2024 年 4 月 – 6 月 : 設計・製造・単体・結合試験を実施 2024 年 7 月 – 8月 : 総合・性能・負荷試験を実施 2024 年 8 月下旬 – 9 月上旬 : 移行リハーサルを実施 2024 年 9 月中旬 : 本番移行を完了 データベース移行における品質確保のため、様々な施策を段階的に実施しました。 移行をする上で発生した一つ目の課題として、文字コード変更の影響がありました。 RDS に移行する上で EUC から UTF-8 への文字コード変更が必要になり、マルチバイト文字に必要な文字数が 2 バイトから 3 バイトまたは 4 バイトに増加したため、すべてのマルチバイトを含む列のサイズを拡張データ型を活用し 2 倍に変更しました。 また、単体試験では 本番ワークロードをテストツールにより再現し、事前の性能検証とチューニングを実施することで、移行後に性能問題が発生するリスクを事前に軽減しました。 移行方式では、 AWS Database Migration Service (DMS) を用いて、フルロードと Change Data Capture (CDC) によるレプリケーションにより、本番システム切り替え時のダウンタイムの削減を目指しました。 DMS の事前検証の中で、拡張データ型利用時の固有の制限や、主キーのないテーブルをレプリケーションする方法など、いくつかの技術的課題に直面しましたが、 Oracle トリガーの活用や一時的な主キー付与などの対策により解決しました。また、データ件数が数億レコードと多くフルロードの時間がかかるテーブルでは、条件句 (WHERE) により取得対象を絞り、並列実行することでチューニングを行いました。 また、 DMS によるレプリケーションをより確実なものとするため、移行リハーサル前の 6 月から 8 月までの 3 ヶ月間で、特定タイミングでのみ発生する処理や複数の条件の組み合わせなど様々なパターンを網羅するために、複数回の長期間レプリケーションテストを実施しました。 プロジェクト体制として、 PM 、インフラ担当、 DBA 、アプリケーション開発者含め約 60 人の体制で、パートナー企業 (株式会社SP) との協力体制のもと、データ移行の検証から本番移行まで、プロジェクト全体の円滑な遂行を実現しました。 AWS からの支援体制として、アカウントチームによるアーキテクチャ全体の設計方針策定支援だけでなく、Customer Solutions Manager(CSM) による、PMO としての PM 支援や、移行やモダナイゼーション、データベースのように各専門領域に特化した各スペシャリスト SA による支援体制もありました。 移行リハーサルで検出された課題については、必要箇所の再テストを通じて本番移行時のリスクを最小化を行いました。その結果、本番移行は大きな問題なく完了することができました。さらに、移行後は一週間および一ヶ月の集中監視期間を設け、システムの安定稼働の確保に努めました。 Amazon RDS for Oracle への移行の効果 移行後、最も顕著な効果として現れたのは、データセンター費用と Exadata 関連コストの約 56 %削減という効果を見込めている点です。この効果達成の一因として、開発環境においては、 Oracle のマルチテナント構成を活用することでライセンスコストを最適化し、より効率的な開発環境を実現しました。それ以外の効果としては、システム運用の質的な改善です。ハードウェア障害に対応することがなくなったため、運用担当者は従来のインフラ保守から解放され、より付加価値の高い業務に注力できるようになりました。また、リソースの柔軟な拡張が可能になったことで、ビジネスの急速な成長にも迅速に対応できる体制が整ったこともメリットの一つと感じています。 AWS メインでのアーキテクチャーとなった為、 AWS に興味を持っているエンジニアが多く、モチベーションが向上している点も更なる効果となっています。 今後に向けて ディップ株式会社では、今回の移行を変革の第一歩と位置づけ、さらなる進化に向けたロードマップを策定中です。 中長期的な取り組みとして、現在のモノリシックなデータベース構造を、より俊敏で柔軟な分散システムアーキテクチャへと進化させることを計画しています。また、 EC2 で運用している環境についても、 AWS ECS などのマネージドサービスへの段階的な移行を通じて、運用効率の最適化とビジネスアジリティの向上を目指します。 さらに、最新テクノロジーにも積極的に着目しており、 Amazon Aurora Limitless Database や Amazon Bedrock など、最新の AWS サービスの活用検討を進めています。これらの戦略的な取り組みを通じて、ビジネスのさらなる加速とビジネス競争力の強化を推進していきます。 まとめ ディップ株式会社は、 Exadata から Amazon RDS for Oracle への移行により、コストを 56% 削減するとともに、システムの拡張性と運用効率を大幅に向上させました。中長期的な視点に基づく綿密な計画と段階的なアプローチにより、安全かつ確実な移行を実現。運用負荷の軽減により、技術者は本来注力すべき業務改善や新技術検討に取り組める環境が整い、 Aurora PostgreSQL への移行など、さらなる進化を実現する基盤が確立されました。

エージェンティック AI システムは急速にデジタル世界を超えて物理世界へと拡大しており、AI エージェントは実際の物理環境で知覚、推論、および行動をとります。AI システムがロボティクス、自律走行車、およびスマートインフラストラクチャを通じて物理世界とますます相互作用するにつれて、根本的な疑問が浮かび上がります：複雑な推論のために大規模なクラウドコンピューティングを活用しながら、物理的な感知と作動に対してミリ秒レベルの応答性を維持するエージェントをどのように構築するのでしょうか？ 2025年は、AWS におけるエージェンティック AI にとって変革的な年でした。私たちは 2025 年 5 月に Strands Agents を立ち上げ 、シンプルな開発者エクスペリエンスと モデル駆動型アプローチ をエージェント開発にもたらしました。7 月には、マルチエージェントオーケストレーション機能を備えた バージョン 1.0 をリリース し、 Amazon Bedrock AgentCore を導入 して、あらゆる規模で AI エージェントを本番環境に迅速に展開できるようにしました。re:Invent 2025 では、 TypeScript SDK 、 評価 、 音声エージェント用の双方向ストリーミング 、および ルール内にエージェントを誘導するためのステアリング を追加して Strands を拡張しました。今日、私たちはこれらの機能がエッジやフィジカル AI にどのように拡張されるかを探っています。そこでは、エージェントは単に情報を処理するだけでなく、物理的な世界で私たちと共に働きます。 デモンストレーションの完全なコードは以下で見つけることができます： Strands + NVIDIA GR00T + SO-101 Strands + Boston Dynamics Spot これらのデモンストレーションでは、フィジカル AI エージェントが統一された Strands Agents インターフェースを通じて 2 つの非常に異なるロボットを制御します。このインターフェースは AI エージェントを物理的なセンサーやハードウェアに接続します。3D プリントの SO-101 ロボットアーム は、 NVIDIA GR00T ビジョン言語アクションモデル（VLA）を使用して操作を処理します。「果物を拾ってバスケットに入れる」というコマンドにより、リンゴを識別し、それを把持してタスクを完了します。一方、 Boston Dynamics Spot 四足歩行ロボットは、移動と全身制御を扱います。「センサーを点検する」というコマンドにより、Spot はセンサーが下側にあることを理解し、自律的に座って側面に転がってセンサーにアクセスします。両方のデモンストレーションは NVIDIA Jetson エッジハードウェア上で実行され、組み込みシステム上で直接実行できる高度な AI 機能を示しています。 エッジとクラウドの連続性 フィジカル AI アプリケーションは、インテリジェントシステムを構築する方法に影響を与えるトレードオフを明らかにします。ボールをキャッチするロボットアームを考えてみましょう。ボールを見てグリッパーの位置を調整する瞬間は、ミリ秒単位で行われなければなりません。最速の接続であっても、クラウドサービスへのネットワーク遅延はこれを不可能にします。推論は、物理的な現実が要求するほぼ瞬時の応答時間で、デバイス自体のエッジで行われなければなりません。しかし、同じロボットシステムはクラウドの機能から非常に大きな恩恵を受けます。複数のステップからなる組立作業の計画、他のロボットとの連携、または何千もの類似ロボットの集合的な経験から学ぶことは、クラウドのみが提供する計算規模を必要とします。 Anthropic Claude Sonnet 4.5 のようなモデルは、ロボットが複雑なタスクを理解し実行する方法を変革する推論能力をもたらしますが、エッジハードウェアで実行するには大きすぎます。これは Daniel Kahneman の System 1 and System 2 thinking を反映しています – エッジは速い本能的な反応を提供し、クラウドは慎重な推論、長期的な計画、そして継続的な学習を可能にします。最も有能なフィジカル AI システムは、両者をシームレスに連携させて使用します。 クラウドは、エッジでは実現不可能な追加機能を可能にします。 AgentCore Memory は、何が起こったかだけでなく、どこでいつ起こったかを覚えておく、時間的および空間的コンテキストを数時間または数日間維持できます。学習は個々のデバイスにサイロ化されるのではなく、全デバイスにわたって収集され適用できます – 1 つのロボットがより良いアプローチを発見すると、その知識は共有メモリを通じてすべてのロボットが利用できるようになります。 Distributed observability は全デバイスにわたって提供され、AI エージェントとロボットが大規模に展開されたときに何をしているかを理解する能力を提供し、単一のデバイスでは生成できない洞察を提供します。 Amazon SageMaker は、モデルの大規模な並列シミュレーションとトレーニングを可能にし、組織が実世界およびシミュレーションされた展開からの学習を改善されたモデルに適用して、全デバイスに利益をもたらすことを可能にします。 このハイブリッドアーキテクチャは、まったく新しいカテゴリーのインテリジェントシステムを可能にします。ヒューマノイドロボットは、クラウドベースの推論を使用して複数のステップからなるタスクを計画し、エッジベースのビジョン-言語-アクションモデルで正確な物理的な動きを実行します。クラウドエージェントは「朝食を準備する」ことを計画し、それをステップに分解し、あなたが好むものを覚えているかもしれませんが、エッジ VLA モデルはイチゴをつぶさずにつかむためのミリ秒レベルの制御を処理します。自律走行車は、ルート最適化と交通予測にクラウドインテリジェンスを活用しながら、エッジでリアルタイムの障害物回避を維持します。車両は歩行者を避けるためにクラウドの応答を待つことはできませんが、都市全体の交通パターンのクラウドベースの分析から恩恵を受けます。 コードを通じた進歩的なジャーニー エッジおよびフィジカル AI システムの構築には、エッジとクラウドのオーケストレーションの完全な複雑さから始める必要はありません。前進の道は、シンプルに始めて、ニーズが成長するにつれて洗練度を高めていく進歩的な反復です。 エッジから始める まず、エッジデバイスに Strands Agents Python SDK を  Ollama と共にインストールし、 Qwen3-VL モデルをプルします。Ollama を インストール し、これらのコマンドを実行します： ollama pull qwen3-vl:2b pip install 'strands-agents[ollama]' シンプルな出発点は、エッジデバイス上でモデルをローカルに実行することです。Strands の  Ollama プロバイダー を使用すると、Qwen3-VL のようなオープンソースモデルをエッジハードウェア上で直接実行できます。Strands はまた、量子化モデルを使用した高パフォーマンス推論のための llama.cpp と、Apple Silicon 上でモデルを実行するための MLX をサポートしています： from strands import Agent from strands.models.ollama import OllamaModel edge_model = OllamaModel( host="http://localhost:11434", model_id="qwen3-vl:2b" ) agent = Agent( model=edge_model, system_prompt="You are a helpful assistant running on edge hardware." ) result = agent("Hello!") フィジカル AI は、テキストの処理だけでなく、物理的な世界を理解する必要があることがよくあります。カメラ入力を介して視覚的理解を追加するのは簡単です – テキストを処理する同じエージェントが今や画像を処理でき、物理的な環境を見ることができます： def get_camera_frame() -> bytes: # Example function that returns the current camera frame with open("camera_frame.jpg", "rb") as f: return f.read() result = agent([ {"text": "What objects do you see?"}, {"image": {"source": {"bytes": get_camera_frame()}}} ]) 視覚を超えて、エージェントは他のセンサーにアクセスして状態を理解できます。センサー読み取りをツールとしてラップすることで、エージェントは情報に基づいた決定を行うために必要に応じてそれらを動的に呼び出すことができます。バッテリーレベルの読み取りは、エージェントがタスクを続行するか充電に戻るかを決定するのに役立ちます： @tool def get_battery_level() -> str: """Get current battery level percentage and remaining duration.""" # Example function that returns battery metrics percentage = robot.get_battery_percentage() duration = robot.get_battery_duration_minutes() return f"Battery level: {percentage}%, approximately {duration} minutes remaining" agent = Agent( model=edge_model, tools=[get_battery_level], system_prompt="You are a robot assistant. Use available tools to answer questions." ) result = agent("How long until you need to recharge?") 物理的な世界で行動する フィジカル AI システムは、環境を感知し、何をすべきかを推論し、目標を達成するために物理世界を変えるために行動するという連続的なサイクルに従います。カメラとセンサーを通じた感知については説明しました。今、エージェントが決定を物理的な行動に変換する方法を探ってみましょう。 物理世界で行動するということは、ハードウェアを制御することを意味します。ロボットの関節を回転させるモーター、開閉するグリッパー、移動プラットフォームを駆動する車輪などです。ロボットアームには 6 つの関節があり、それぞれが特定の角度に回転できるモーターで制御されています。オブジェクトを拾うには、ロボットは 6 つの関節を同時に調整し、現在の位置からオブジェクトに到達し、グリッパーの角度を調整し、グリッパーを閉じて持ち上げる必要があります。この調整は、ターゲット関節位置をモーターに送信することで行われ、モーターがロボットの物理構造を動かします。これには 2 つの方法があります：ロボットアクションを直接出力するビジョン-言語-アクションモデルを使用するか、AI が高レベルのコマンドを提供する従来のロボット SDK を使用することです。 NVIDIA GR00T のような ビジョン-言語-アクションモデル は、視覚的知覚、言語理解、行動予測を 1 つのモデルに組み合わせます。カメラ画像、ロボット関節位置、言語指示を入力として取り、新しいターゲット関節位置を直接出力します。 「あなたと同じ色の果物を拾ってバスケットに入れてください」という指示を考えてみましょう。VLA モデルのビジョン-言語バックボーンがまず指示とカメラ画像で見るものを推論し、どのオブジェクトがリンゴで、どれがバスケットかを識別します。ロボットの現在の状態（関節位置）を含めることで、モデルはロボットをリンゴに移動し、その周りでグリッパーを閉じ、バスケットに移動し、放出する新しい関節位置のシーケンスを生成します。モデルはこれをアクションチャンクとして実行します – ロボットがシーンを継続的に観察しながら実行する小さな関節移動のシーケンスです。タスク中に誰かがリンゴを動かした場合、VLA モデルは次のカメラフレームでこれを認識し、リンゴの新しい位置に到達するための修正された関節移動を生成します。 Hugging Face の LeRobot は、ロボットハードウェアの操作を容易にするデータとハードウェアインターフェースを提供します。テレオペレーションまたはシミュレーションを使用してデモンストレーションを記録し、データでモデルをトレーニングし、ロボットにデプロイします。LeRobot のようなハードウェア抽象化と NVIDIA GR00T のような VLA モデルを組み合わせることで、物理世界で知覚し、推論し、行動するエッジ AI アプリケーションを作成します： @tool def execute_manipulation(instruction: str) -> str: """Execute a manipulation task using your robotics hardware.""" # Example function that runs inference on a VLA model and actuates a robot while not task_complete: observation = robot.get_observation() # Camera + joint positions action = vla.get_action(observation, instruction) # Inference from the VLA model robot.apply_action(action) # Execute joint movements return f"Completed: {instruction}" robot_agent = Agent( model=edge_model, tools=[execute_manipulation], system_prompt="You control a robotic arm. Use the manipulation tool to complete physical tasks." ) result = robot_agent("place the apple in the basket.") これにより、自然な役割分担が生まれます。Strands が高レベルのタスク分解を処理し、GR00T がミリ秒レベルの感覚運動制御とリアルタイムの自己修正を処理します。 ビルダーにとってこれをより簡単にするために、私たちは NVIDIA GR00T のような VLA モデルとハードウェアを接続するためのシンプルなインターフェースを備えた 実験的なロボットクラス をリリースしました。 from strands import Agent from strands_robots import Robot # Create robot with cameras robot = Robot( tool_name="my_arm", robot="so101_follower", cameras={ "front": {"type": "opencv", "index_or_path": "/dev/video0", "fps": 30}, "wrist": {"type": "opencv", "index_or_path": "/dev/video2", "fps": 30} }, port="/dev/ttyACM0", data_config="so100_dualcam" ) # Create agent with robot tool agent = Agent(tools=[robot]) agent("place the apple in the basket") SDK ベースの制御 は、ロボットメーカーが堅牢なモーションプリミティブを提供し、テスト済みの制御システムを活用したい場合に適しています。 Boston Dynamics Spot では、SDK コマンドを Strands ツールとしてラップします： from bosdyn.client.robot_command import RobotCommandBuilder, blocking_command, blocking_stand, blocking_sit @tool def stand() -> str: """Command the robot to stand up.""" blocking_stand(command_client, timeout_sec=10) return "Robot is now standing" @tool def sit() -> str: """Command the robot to sit down.""" blocking_sit(command_client, timeout_sec=10) return "Robot is now sitting" @tool def battery_change_pose(direction: str = "right") -> str: """Position robot for battery access by rolling onto its side.""" cmd = RobotCommandBuilder.battery_change_pose_command( dir_hint=1 if direction == "right" else 2 ) blocking_command(command_client, cmd, timeout_sec=20) return f"Robot positioned for battery access" spot_agent = Agent( model=edge_model, tools=[stand, sit, battery_change_pose], system_prompt="You control a Boston Dynamics Spot robot." ) result = spot_agent("I need to inspect your sensors") 「センサーを点検する必要があります」と要求されたとき、エージェントはセンサーがロボットの下側にあると判断し、Spot に座るコマンドとバッテリー交換ポーズを実行するよう指示します。SDK は、ロボットを安全に横向きにするのに必要な複雑なバランスとモーター制御を処理します。 エッジとクラウドの架け橋 エッジエージェントは、必要に応じて複雑な推論をクラウドに委任できます。VLA モデルは物理的なアクションに対してミリ秒レベルの制御を提供しますが、システムがより深い推論を必要とする状況（複数ステップのタスクの計画や過去のパターンに基づく決定など）に遭遇した場合、 agents-as-tools パターンを使用して、より強力なクラウドベースのエージェントに相談できます： from strands import Agent, tool from strands.models import BedrockModel from strands.models.ollama import OllamaModel # Cloud agent with powerful reasoning cloud_agent = Agent( model=BedrockModel(model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0"), system_prompt="Plan tasks step-by-step for edge robots." ) # Expose cloud agent as a tool so that it can be delegated to # using the agents-as-tools pattern @tool def plan_task(task: str) -> str: """Delegate complex planning to cloud-based reasoning.""" return str(cloud_agent(task)) # Edge agent with local model edge_agent = Agent( model=OllamaModel( host="http://localhost:11434", model_id="qwen3-vl:2b" ), tools=[plan_task], system_prompt="Complete tasks. Consult cloud for complex planning." ) result = edge_agent("Fetch me a drink") 逆のパターンも同様に強力です。クラウドベースのオーケストレーターは、各エッジデバイスが独自のリアルタイム制御を処理する間、クラウドエージェントが全体的なワークフローを管理することで、複数のエッジデバイスを調整できます： @tool def control_robot_arm(command: str) -> str: """Control robotic arm for manipulation tasks.""" # Example function that invokes a remote robot arm agent return str(robot_arm_agent(command)) @tool def control_mobile_robot(command: str) -> str: """Control mobile robot for navigation and transport.""" # Example function that invokes a remote mobile agent return str(mobile_robot_agent(command)) warehouse_orchestrator = Agent( model=BedrockModel(model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0"), tools=[control_robot_arm, control_mobile_robot], system_prompt="You coordinate multiple robots in a warehouse environment." ) result = warehouse_orchestrator( "Coordinate inventory check: scan shelves, retrieve items, and sort" ) 倉庫では、これはロボットアーム、モバイルロボット、検査ドローンを調整して複雑な在庫タスクを完了することを意味するかもしれません。各デバイスは即時の応答のために独自のエッジインテリジェンスを維持しますが、クラウドオーケストレーションの下で一緒に働きます。 フリート全体での学習と改善 クラウドエージェントが複数のエッジデバイスを調整できることを見てきたように、フィジカル AI システムは、集合的な経験から学び、観察とフィードバックを通じて継続的に改善できるようになるとさらに能力が向上します。 多数のモバイルロボットを持つ倉庫を考えてみましょう。複数のロボットが同じ問題に遭遇すると、単一のロボットでは検出できないパターンが現れます。 AgentCore Memory   により、この集合的知性が可能になります – 各ロボットは動作中に観察を共有メモリに保存します： from bedrock_agentcore.memory import MemoryClient memory_client = MemoryClient(region_name="us-east-1") # Robot stores observation after navigation issue memory_client.create_event( memory_id=FLEET_MEMORY_ID, actor_id=robot_id, session_id=f"robot-{robot_id}", messages=[ ("Navigation failure in north corridor - low confidence in visual localization. " "Location: north_corridor, light_level: high_contrast", "ASSISTANT") ] ) フリートコーディネーターは、この共有メモリを照会して、北側の通路における87%のナビゲーション失敗が午後2時から4時の間に発生し、そのときの天窓からの日光がビジョンシステムを混乱させていることを発見することができます。この洞察により、即座に運用変更が行われ、モデル改善につながります。 AgentCore Observability は、推論 → シミュレート/実行 → 観察 → 評価 → 最適化の完全なフィードバックループを通じて継続的な改善の基盤を提供します。CloudWatch の GenAI Observability ダッシュボードは、エッジデバイスからのエンドツーエンドのトレースをキャプチャし、エージェントの実行パス、メモリの取得操作、およびシステム全体のレイテンシーの内訳を明らかにします。この観察データは強化学習のトレーニングシグナルとなり、成功した行動は強化され、失敗は修正に役立ちます。 Amazon SageMaker は、これらの学習を適用するための大規模な並列シミュレーションとトレーニングを可能にします。 NVIDIA Isaac Sim や MuJoCo などの物理シミュレーターは、ロボットがデプロイ前に何百万ものシナリオを安全に練習できる現実的な物理環境を提供します。LLM ベースのユーザーシミュレーターを含むデジタルシミュレーターは、エージェントがエッジケースを処理するのに役立つ多様な相互作用パターンを生成します。サイクルは繰り返されます：実際のロボットにデプロイし、行動を観察し、大規模に改善をシミュレートし、更新されたモデルをトレーニングし、フリートに再デプロイします。各反復により、フリート全体がより有能になります。AWS で Isaac GR00T のファインチューニングを使用したスケーラブルなロボット学習パイプラインの設定に関する詳細なウォークスルーについては、 embodied AI ブログ投稿シリーズ をご覧ください。 次世代のインテリジェントシステムの構築 この瞬間を興味深いものにしているのは、いくつかの分野で見られる収束です。強力なマルチモーダル推論モデルは物理的なタスクを理解し計画することができ、エッジハードウェアは VLA モデルが物理システムが要求する低レイテンシーでローカルで実行することを可能にし、オープンソースのロボティクスハードウェアはより広いビルダーコミュニティにフィジカル AI 開発を可能にしています。VLA モデルは、ロボットがミリ秒レベルの制御で動的環境を感知し行動することを可能にし、エージェントがシミュレーションと実際の物理的なデプロイメントの両方を通じて改善する継続的な学習ループがクラウド上で実用的になりました。 AWS の目標の一つは、AI エージェント開発を容易なものにすることです。この取り組みは、その目標を物理的な世界にまで拡張します。David Silver と Richard S. Sutton が Welcome to the Era of Experience で説明しているように、AI エージェントは環境での経験から学習し、モデルのトレーニング、チューニング、長期記憶、およびコンテキスト最適化を通じて改善しています。これらのシステムが物理的な世界についてより深く推論する能力を開発するにつれ、行動を起こす前に将来の世界状態をシミュレートし、決定の結果を予測し、より大きなシステムの一部として確実に連携できるようになります。 この急速に成長する分野で、今後数ヶ月間で皆さんが何を作るか楽しみにしています。 今日から始めましょう： Strands Agents Amazon Bedrock AgentCore Amazon SageMaker NVIDIA Isaac GR00T Hugging Face LeRobot SO-101 robot arm Boston Dynamics Spot Experimental Strands Robot Class このブログは、 Building intelligent physical AI: From edge to cloud with Strands Agents, Bedrock AgentCore, Claude 4.5, NVIDIA GR00T, and Hugging Face LeRobot を、AWSジャパンのソリューションアーキテクト、岩根義忠が翻訳しました。 Arron Bailiss Arron Bailiss はAWSの主任エンジニアで、人工知能、機械学習、ロボット工学の間で働く Agent AI に焦点を当てています。彼は、ビルダーが高度なAI駆動のアプリケーションを作成できるようにする開発者ツールの未来を形作る手助けをしています。 Cagatay Cali Cagatay Cali はAWSのリサーチエンジニアで、エージェントAIとロボティクスに注力しています。彼は、AI エージェントを実際のロボットに接続するインターフェースを設計し、開発者が自然言語でロボットシステムを制御できるようにしています。また、エージェントとロボット開発を、あらゆるスキルレベルの構築者が使えるようにしています。 Rachita Chandra Rachita Chandra はプロトタイピングソリューションアーキテクトであり、AWS上のワークロードにおいて生成AIおよび機械学習ソリューションの実装に特化しています。彼女の専門知識には、エンタープライズグレードのセキュリティとコンプライアンスを確保しながら、スケーラブルなAIパイプラインを設計することが含まれます。 Aaron Su Aaron Su はアマゾン ウェブ サービスのソリューションアーキテクトであり、スタートアップが概念から実際の運用まで AI ソリューションを構築して拡張することを支援しています。彼はフィジカル AI とエージェントシステムに深い情熱を注ぎ、オープンソースプロジェクト、視点のガイダンス、リファレンスアーキテクチャを通じて技術コミュニティに積極的に貢献しています。アーロンは世界中の何百もの起業家を支援し、世界の会議で技術セッションを行っています。彼は起業家およびロボット工学の研究者としての経験を持っています。  

2025年11月26日から29日の4日間、千葉県の幕張メッセにて「第9回鉄道技術展2025（Mass-Trans Innovation Japan 2025）」が開催されました。AWSはこの展示会に出展し、クラウドとAIを活用した鉄道保全システムのソリューションをご紹介しました。 1. 鉄道技術展とは 鉄道技術展（Mass-Trans Innovation Japan）は、鉄道に関する最新技術や製品、サービスが一堂に会する日本最大級の専門展示会です。車両、軌道、電気、信号、通信、保安、運行管理など、鉄道事業に関わるあらゆる分野の技術革新が紹介される場として、鉄道事業者、メーカー、研究機関など業界関係者が集まる重要なイベントとなっています。 主催者による発表によると、今年は4日間で39,120人の方が来場されたとのことです。 詳細は公式ホームページ ( https://www.mtij.jp ) をご覧ください。 2. AWSが提案する鉄道保全の未来 今回のAWS出展では、「クラウドとAIで変革する鉄道保全」をテーマに、鉄道保全業務が抱える課題に対し、IoTと生成AIを活用したソリューションをご紹介しました。 鉄道保全現場が抱える3つの課題 現在、鉄道保全の現場では深刻な課題に直面しています。 第一に、生産年齢人口の減少に伴う労働力不足です。鉄道機械メンテナンス従事者の減少が進む中、技能労働者の大量退職時代を迎えており、効率的な技術・ノウハウ伝承が急務となっています。 第二に、保全対象機器の増加です。従来の鉄道機械に加え、ホームドアなどの旅客サービス向上のための新機器が増加しています。また、「省力化」のために導入した機械が、逆にメンテナンス対象を増やすというジレンマが生じています。 第三に、情報資産の複雑化です。作業記録などの非構造化データが多く、管理が困難になっています。また、個別最適化によるシステムのサイロ化により、情報が散在している状況です。 3つの柱で構成されるソリューション AWSが提案するソリューションは、これらの課題に対して3つの主要コンポーネントで構成されています。 ソリューション1：設備状態のリアルタイム把握 鉄道事業者が管理する設備は、駅のホームドアや改札機、券売機から、沿線に点在する電気設備まで多岐にわたります。これらの設備をネットワークで接続し、 AWS IoT Services ( AWS IoT Core , AWS IoT SiteWise ) を活用することで、リアルタイムの状態監視が可能になります。 各設備から収集されたデータは、集中センターのダッシュボードに集約されます。オペレーターは、現地に赴くことなく、すべての設備の稼働状況を一画面で把握できます。異常が発生した際も、ダッシュボード上で即座に検知し、迅速な対応が可能になります。 AWS IoT SiteWise は、産業データを大規模に収集・整理・分析するためのマネージドサービスです。複数のデータソースから自動的にデータを取り込み、構造化し、パフォーマンス指標を計算します。リアルタイムデータと過去のデータを組み合わせて可視化することで、設備の稼働状況を常に把握できる環境を提供します。これにより、 IoT による機器データの自動収集と可視化を実現し、効率的な設備管理を支援します。 Grafanaを活用したダッシュボード画面 ソリューション2：イベント把握と初動調査支援 設備に異常が発生すると、 AWS IoT SiteWise が即座に検知します。この異常情報は、 Amazon Bedrock Knowledge Bases を活用した生成AIアプリケーションに自動連携されます。 AIは膨大なオペレーションマニュアルやメンテナンスログから、その異常に関連する対応方法を瞬時に検索・抽出します。オペレーターには、異常の通知と共に具体的な対応手順が提示されるため、マニュアルを探し回る必要がありません。 Amazon Bedrock Knowledge Bases は、検索拡張生成（RAG）をフルマネージドで提供します。文書管理から情報検索、回答生成まで一貫して自動化されており、過去の類似事例や推奨される対応手順を即座に提示できます。これにより、経験の浅い担当者でも、ベテランと同等の初動対応が可能になります。 RAGを活用したメール通知サンプル ソリューション3：関係システムの情報把握支援 AWS IoT SiteWise が検知した異常イベントは、 Amazon Bedrock AgentCore でホストされるAIエージェントにも自動的に連携されます。 AIエージェントは、異常対応に必要な情報を多方面から自動収集します。まず輸送計画システムにアクセスし、設備異常が影響を及ぼしうる列車を推定します。次に設備管理システムから、対象機器のメンテナンス計画や実績、過去に報告された異常情報を調査します。これらの分散した情報を統合し、輸送への影響範囲、過去の類似事例、推奨される修理時間帯など、判断に必要な情報をワンストップで担当者に提示します。 Amazon Bedrock AgentCore は、柔軟性の高いAIエージェントプラットフォームです。任意のフレームワークやモデルを使用してエージェントを作成でき、安全でスケーラブル、かつ信頼性の高い運用を実現します。担当者は、複数のシステムを個別に確認する手間から解放され、AIが統合した情報をもとに迅速かつ的確な判断が可能になります。 異常通知を契機にAIエージェントが自動収集した内容を保守担当者にメール通知します。これにより、多岐にわたる関連情報を迅速に把握することができます。 AIエージェントが作成したメールのサンプル 追加で情報を確認するためのチャット機能を備えています。 Amazon Bedrock AgentCore Memory を活用することで機能間で情報が分断されることなく、発生事象などの背景情報を踏まえたやりとりが可能となります。 AIエージェントチャット機能の画面 3. デモンストレーション環境 今回の展示では、実際の鉄道運用を想定したデモンストレーション環境を構築しました。8つの駅に設置された257台のデバイスを管理する環境をシミュレーションしました。 来場者の皆様には、実際の画面操作を通じて、異常検知から対応完了までの一連の流れを体験いただきました。特に、生成AIが過去のメンテナンスログから関連情報を抽出し、具体的な対応手順を提示するデモンストレーションは、多くの関心を集めました。 デモソリューションのアーキテクチャ図 4. 来場者の声 展示ブースには、鉄道事業者、車両メーカー、保守事業者など、多くの業界関係者の方々にお越しいただきました。 実際にデモンストレーションをご覧になった方々からはこういった仕組みを導入したいと考えていた、まさに今導入に向けて検討を進めているといったお言葉もいただきました。 鉄道事業者様からは、「新人にとっては非常に良いソリューションになり得る」といったコメントや「ここからさらに作業計画書や実施報告書が作れると最高だね」と言ったアドバイスもいただきました。 メーカー様からは、「納品した機器のマニュアルに書いてある範囲で緊急の用件の問い合わせをよく受けるため、こういったソリューションがあると我々としても非常に助かる」と言った前向きなコメントをいただきました。 また鉄道事業者様、メーカー様の数名の方からは「今まさにこういったソリューションが欲しかったんです」といった今すぐ使いたいという非常にありがたいお言葉もいくつかいただきました。 5. まとめ 今回の第9回鉄道技術展2025への出展を通じて、鉄道業界が直面する労働力不足や技術継承といった課題に対し、クラウドとAIがどのように貢献できるかを具体的にお示しすることができました。 AWSは、 AWS IoT Services ( AWS IoT Core , AWS IoT SiteWise ) 、 Amazon Bedrock Knowledge Bases 、 Amazon Bedrock AgentCore といった先進的なサービスを組み合わせることで、鉄道保全業務の効率化と高度化を実現します。リアルタイムの設備監視、AIによる対応支援、複数システムの情報統合という3つの柱により、労働力不足という課題に直面しながらも、安全で信頼性の高い鉄道サービスを維持・向上させることが可能です。 鉄道は社会インフラの根幹を支える重要な産業です。AWSは、クラウドとAIの力で鉄道業界のデジタルトランスフォーメーションを支援し、持続可能で効率的な鉄道運営の実現に貢献してまいります。 今回の展示にご来場いただいた皆様、誠にありがとうございました。AWSの鉄道向けソリューションにご興味をお持ちの方は、ぜひお気軽にお問い合わせください。 著者 岩永 昌寛 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 西部 信博 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアカスタマーソリューションマネージャー 鈴木 真史 アマゾンウェブサービスジャパン合同会社 技術統括本部　シニアソリューションアーキテクト 堀 竜慈 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト 宮﨑知洋 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト