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の鉄道向けソリューションにご興味をお持ちの方は、ぜひお気軽にお問い合わせください。 著者 岩永 昌寛 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 西部 信博 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアカスタマーソリューションマネージャー 鈴木 真史 アマゾンウェブサービスジャパン合同会社 技術統括本部　シニアソリューションアーキテクト 堀 竜慈 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト 宮﨑知洋 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト

本記事は、2026年 1 月 22 日に公開された “ Game development infrastructure simplified with AWS Game Dev Toolkit ” を翻訳したものです。翻訳は Solutions Architect の鷲見啓志が担当しました。 注釈: AnyCompany Gamesは、ゲーム開発における一般的な課題と解決策を説明するために作成された架空の会社です。 分散したチームでゲームを開発している場合、バージョン管理、ビルドシステム、クラウドインフラストラクチャのセットアップという課題に直面したことがあるのではないでしょうか。この記事では、AnyCompany Games の事例を例に、 AWS Cloud Game Development Toolkit を使用して、完全なゲーム開発パイプラインを数週間ではなく数時間でデプロイする方法を紹介します。 多くのインディーゲームスタジオと同様に、AnyCompany Games は大きな野望を抱く小規模なリモートチームから始まりました。業界暦の長い5人のベテランが、没入感のあるロールプレイングゲーム( RPG )体験を創造するという共通のビジョンを持って集まりました。しかし、彼らはすぐにゲーム開発における共通の課題に直面しました。彼らの野心的なプロジェクトには、堅牢なインフラストラクチャが必要だったのです。 AnyCompany Games のチームには、特別なものを作り上げる才能とビジョンがありました。彼らの前に立ちはだかる最大の問題は、インフラストラクチャの欠如でした。手元にあるハードウェアでは、ビルド時間が長くなり、ビルドはよく失敗していました。アーティストはシェーダーの読み込みに1時間以上待たされ、大容量のアセットの共有やバージョン管理が開発を遅らせていました。 彼らの開発に求められる環境は本格的なものでした。 Perforce P4 などのバージョン管理用サーバー、Unreal Engine Horde などの継続的インテグレーション・継続的デリバリー( CI/CD )ツール、そしてこれらすべてを支える基盤となるネットワークインフラストラクチャが必要でした。このシナリオは、ゲーム業界ではよく見られるものです。大容量なアセットを含む複雑なゲームには、スケーラブルなインフラストラクチャが必要ですが、大多数のゲームスタジオは、オンプレミスでスケーラブルなインフラを維持するのに苦労しています。 チームがクラウドソリューションを検討する中で、 Amazon Web Services（ AWS ）  は有望な選択肢であることが分かりました。AWS は必要に応じてリソースのプロビジョニングと削減を可能にし、大規模なハードウェア要件に対応できました。しかし、1つの課題が残っていました。それは、AWSリソースをゲーム開発ツールと効率的に連携するように設定することでした。 ここで Cloud Game Development Toolkit が登場します。これは、 AWS for Games によって開発された、公開されているオープンソースリポジトリに格納された Terraform モジュールと Packer テンプレート専用のコレクションです。この記事では、このツールキットが AnyCompany Games や同様のスタジオが開発ツールを AWS インフラストラクチャとシームレスに統合するのにどのように役立つかを探ります。 クラウドインフラストラクチャ構築の前提条件 多くのクラウドコンピューティング初心者の開発者と同様に、AnyCompany Games は AWS アカウントの作成から始めました。アカウント作成が完了すると、チームはゲーム開発のニーズに最適なクラウドインフラストラクチャについて調査を行いました。 その時、彼らは Cloud Game Development Toolkit を発見しました。このリポジトリは、AWS 上で重要なゲームインフラストラクチャコンポーネントのデプロイを効率化する、カスタマイズ可能な Terraform と Packer のテンプレートを提供していました。 ネットワーク基盤の構築 クラウド基盤を構築する最初のステップは、ネットワークアーキテクチャの作成でした。リソースは複数のアベイラビリティーゾーンにわたって高可用性を確保する必要がありました。 ネットワークインフラストラクチャを構築するための Amazon Virtual Private Cloud（ Amazon VPC ） リソースをデプロイするために、彼らは Terraform AWS プロバイダー のリソースとデータソースを使用しました。これらのプロバイダーを使用して、複数のアベイラビリティーゾーンにわたってパブリックサブネットとプライベートサブネットをデプロイし、仮想プライベートクラウド（ VPC ） からのインターネットアクセス用のインターネットゲートウェイ、およびプライベート AWS リソースからのアウトバウンドインターネットトラフィックを開始するための Amazon VPC NAT ゲートウェイを作成しました。ルートテーブルがこれらのサブネット間のトラフィックフローを管理し、適切なネットワークセグメンテーションを提供しました。 開発ツールやサービスへの信頼性の高いアクセスを提供するため、AnyCompany Games にはドメイン管理が必要でした。彼らは自社ドメイン用に Amazon Route 53 ホストゾーンを設定し、以下を実現しました。 一元化されたドメイン管理 DNS レコードの自動更新 他の AWS サービスとの統合 AWS Certificate Manager を通じた SSL 証明書管理 このネットワークと DNS のインフラストラクチャ基盤により、AnyCompany Games はゲーム開発ツールとサービスをサポートするために必要な、安全でスケーラブルな基盤を手に入れました。彼らは Infrastructure as Code（ IaC ） アプローチを使用して、インフラストラクチャ構成をバージョン管理し、異なる環境間で一貫してデプロイしました。 AnyCompany Games は Infrastructure as Codeとしてインフラストラクチャをデプロイし、Perforce を使用するためのネットワークインフラストラクチャの準備ができました。 以下のアーキテクチャ図は、この記事全体を通じてこのアーキテクチャ内に配置される Perforce と Horde リソースをホストする基盤を表しています。 図1: ネットワークアーキテクチャ クラウドでのバージョン管理に Perforce P4 サーバーを使用する ゲーム開発における重要なコンポーネントはバージョン管理であり、AnyCompany Games には、大容量のバイナリアセット、複雑なブランチ戦略、そして分散した労働力に対応できる堅牢なソリューションが必要でした。Perforce P4 サーバーが適切な答えとなるでしょう。しかし、そのセットアップに貴重な開発時間が奪われてしまいます。 Cloud Game Development Toolkit の Perforce モジュール の 例 を使用して、彼らはわずか数行のコードでバージョン管理システム全体をデプロイすることができました。 terraform apply コマンドを実行するだけで、Perforce サーバー、コードレビューシステム、認証サービスがクラウド上で稼働しました。 Perforce モジュールは3つの統合されたコンポーネントをデプロイしました。P4 サーバーは、バージョン管理のパフォーマンスに最適化された Amazon Elastic Block Store（ Amazon EBS ） ボリュームを備えた Amazon Elastic Compute Cloud（ Amazon EC2 ） インスタンス上で実行されています。次に、P4 Code Review と P4 Authentication Service の両方が、 Amazon Elastic Container Service（ Amazon ECS ） の共有クラスター上のタスクとして実行され、安全な認証とコラボレーション機能を提供しています。 セットアップには数週間ではなく数時間しかかからず、モジュールはチームが P4 One クライアントを接続するための接続文字列と設定詳細まで提供しています。 このツールキットは、Perforce の認証のセットアップを自動化し、Helix Authentication Extension のインストールを処理し、P4 Authentication Service をデプロイし、安全なアクセスのための認証サービスを設定しています。 Perforce をデプロイした後、AnyCompany Games の分散チームはついに効果的にコラボレーションできるようになりました。シアトルのアーティストが大容量ファイルをチェックインする一方で、フロリダのプログラマーは同時にエンジンの変更作業を行うことができました。 以下のアーキテクチャ図は、P4 Server、P4 Code Review、P4 Auth サービスを含む、AWS 上の Perforce のデプロイ構成を示しています。 図2: アーキテクチャ図 Horde でビルドパイプラインを加速する 次の課題は、Unreal Engine プロジェクト用の CI/CD パイプラインのセットアップでした。チームには、現在のハードウェアを置き換えるための2つの選択肢がありました。高額で最新のハードウェアを購入し、必要な容量を見積もるか、AWS クラウドの従量課金モデルを活用して、必要に応じてサーバーをプロビジョニングおよびデプロビジョニングするかです。 バージョン管理に使用した Cloud Game Development Toolkit を見直してみると、チームは、すぐにデプロイ可能な専用 CI/CD ツールも含まれていることを発見しました。Unreal Engine を使用していたため、彼らはツールキットの Horde モジュール をデプロイすることに決めました。 Hordeとは？ Unreal Engine Horde は、Epic Games によって開発された、ビルドとテストの自動化のための専用 CI/CD システムです。Epic Games によって設計され、Unreal Engine と統合するように作られており、Fortnite などの主要タイトルの開発に使用されています。Unreal Engine Horde は、プロジェクトのビルドとコンパイル方法を定義する Unreal Engine ビルドグラフシステム（ Unreal BuildGraph ）を標準で理解しています。これにより、汎用的な CI/CD ツールと比較して、Unreal ビルドプロセスとのより優れた統合が可能になります。 Horde は、アセットコンパイルやシェーダー処理などのリソース集約的なタスクの管理など、ゲーム開発に特化して最適化された分散ビルド機能を提供することで、CI/CD パイプラインの強化を支援します。これらの機能は、 Unreal Build Accelerator のリモート実行機能と組み合わせることで、ビルド時間の短縮を可能にし、チームの生産性を向上させることができます。Hordeの機能の詳細については、公式の Unreal Engine Documentation を参照してください。 ツールキットの例 を使用して、AnyCompany Games は AWS 環境に Horde を迅速に追加することができました。 Horde モジュールは、Horde サーバー用の Amazon DocumentDB（ MongoDB互換 ） クラスターと Amazon ElastiCache クラスターを自動的にデプロイし、サーバー設定用の環境変数を提供し、Auto Scalingグループを使用したエージェントのデプロイをサポートしています。 全体的に見ると、CI/CDに関するチームの要件も実現しています: Horde Controller  – ビルドジョブとエージェントを管理する中央サービス ビルドエージェント – 実際のビルド作業を実行する Auto Scaling EC2 インスタンス Perforce 統合 – バージョン管理システムへのシームレスな接続 Webインターフェース – ビルドを監視するためのユーザーフレンドリーなダッシュボード 認証  – 既存システムと統合された安全なアクセス制御 Horde のデプロイにより、2つの要件が満たされました。第一に、チームは Unreal Build Accelerator を使用できるようになり、Wine を使用して Linux マシン上で Windows ターゲットへのコンパイルを分散することで、ビルド速度の向上を実現しました。第二に、Horde の機能により、ゲームクライアント、マルチプレイヤーサーバー、エディターを含む異なる環境向けのビルドを構成するツールが提供されました。 以下の拡張されたアーキテクチャ図は、サポートするAWSサービスとともに、Amazon ECS上で実行されているPerforceとHordeの両方を示しています。 図3: 拡張されたアーキテクチャ図 Cloud Game Development Toolkit がもたらす効果 AnyCompany Games にとって、Cloud Game Development Toolkit は単に技術的な課題を解決しただけでなく、開発プロセス全体の変革を支援しました。パイプラインのセットアップ後、チームは実際のゲーム開発に集中できるようになりました。Cloud Game Development Toolkit は、インフラストラクチャの構築を簡素化し、ゲームの開発ニーズに合わせてAWSリソースを自動的に設定しました。 AnyCompany Games にとって、Cloud Game Development Toolkit は以下のような重要なメリットを提供しました: ゲームに特化した最適化 – ツールキットは、Unreal Engine 、大容量バイナリアセット、分散チームに必要なアプリケーションを、ベストプラクティスを組み込んだ状態でデプロイしました。 Infrastructure as Code（ IaC ） – IaCを定義できる機能により、チームは変更を追跡し、構成をテストし、環境を確実に複製できるようになりました。 組み込まれた AWS ベストプラクティス – AWS ベストプラクティスが組み込まれているため、チームはゲーム開発を優先でき、ツールキットはより安全で、スケーラブルで、再現可能なインフラストラクチャを実現しました。 スケーラビリティ – AnyCompany Games が成長を続けるにつれて、インフラストラクチャも共に成長できます。ビルドエージェントを5台から50台に拡張することは、簡単な設定変更で実現できます。オンプレミスで同じ結果を達成するには、サーバーラックのプロビジョニングとデプロビジョニングに数か月を要するでしょう。 スタートアップとして、コスト管理は AnyCompany Games にとって重要でした。ツールキットによるAWSベストプラクティスの実装により、費用の最適化も実現しています: Auto Scaling – オフピーク時にリソースを縮小 スポットインスタンス – ビルドエージェントが EC2 スポットインスタンス を使用し、コンピューティングコストを最大90%削減 適切なサイジング – インフラストラクチャコンポーネントが実際のニーズに合致 従量課金制 – 多額の初期ハードウェア投資が不要 リポジトリのフォーク  – スタジオの成長と変化に合わせてリポジトリを拡張可能 インフラ管理ではなく、ゲーム制作に集中 AWS で Cloud Game Development Toolkit を使用することで、架空の AnyCompany Games は、インフラストラクチャの習得に時間を費やすのではなく、彼らが最も得意とすること、つまり革新的なゲームの創造に集中できるようになりました。 Cloud Game Development Toolkit を使い始めるには、まずインフラストラクチャの課題を特定します。それがバージョン管理、ビルド自動化、またはその両方であるかを見極めましょう。Amazon VPC と Route 53 モジュールを使用してネットワーク基盤をデプロイし、次に Perforce モジュールでバージョン管理を追加します。チームメンバーがアセットを共有して作業できるようになったら、ビルド自動化のために Horde モジュールを実装します。このプロセス全体を通じて、スタジオ固有の要件に合わせて Terraform モジュールを調整してください。 AWS の豊富なドキュメントとサポートリソースを活用することで、さまざまな規模のゲームスタジオが自信を持ってクラウドへの移行を開始できます。Cloud Game Development Toolkit は、業界のベストプラクティスと一般的なゲーム開発ワークフローに沿った事前設定済みテンプレートを提供することで、この移行を簡素化します。AWS の担当者に連絡して、貴社のゲームスタジオがクラウドを始めるためにどのようにサポートできるかをご確認ください。 参考資料 ゲームスタジオのクラウド移行を加速する準備はお済みですか？準備ができているようであれば以下のリソースも併せてご参照ください: Building Games with Unreal Engine and Horde on AWS Deploying Perforce with AWS Cloud Game Development Toolkit AWS for Games — Cloud Game Development Toolkit はオープンソースプロジェクトです。AnyCompany Games は、ゲーム開発における一般的な課題と解決策を説明するために作成された架空のスタジオです。AWS および AWS ロゴは、米国および/またはその他の国における Amazon.com, Inc. またはその関連会社の商標です。 Basim Siddiqui Basim Siddiqui は、AWS で3年以上働いているソリューションアーキテクトです。ゲーム業界に焦点を当て、あらゆる規模の新規および既存の AWS ゲーム顧客にベストプラクティスと技術的なガイダンスを提供しています。彼は、ゲームスタジオが可能な限り最高の体験を創造できるよう支援するため、新しい AWS クラウド技術を学ぶことに情熱を注いでいます。 Issac Accord Issac Accord は AWS のソリューションアーキテクトで、ゲーム業界の顧客と協力して、既存の AWS フットプリントの改善と強化に取り組んでいます。 Josh Albert Josh Albert は、ゲーム業界に特化したソリューションアーキテクトです。新規および小規模なゲームスタジオが AWS サービスを活用して、より効率的にゲームを構築し、開発サイクルを強化できるよう支援することを専門としています。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 今回からサムネイルがリニューアルされ、新メンバーの古屋さんも一緒に写って心機一転、今年も張り切って週刊AWSお届けしたいと思います。ちなみに新年を迎えてから、私はずっとkiroに向き合って時間を過ごすことが多く、最近個人的にアプリを世に公開しました。いろいろとAI駆動開発のコツが身についてきた感じがします。こんな感じで週末プログラマーが今後どんどん増えていくんだろうなと思っています。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年1月26日週の主要なアップデート 1/26(月) AWS Transfer Family が Amazon FSx for NetApp ONTAP をサポート開始 AWS Transfer Family で Amazon FSx for NetApp ONTAP のファイルシステムに SFTP / FTPS / FTP でアクセスできるようになりました。これまで NFS / SMB でのみアクセス可能だった FSx for ONTAP のデータに、外部パートナーや内部ユーザーが業界標準のファイル転送プロトコルでセキュアにアクセスできます。S3 Access Points 経由でのアクセス制御により、既存のファイルシステムワークフローを維持しながら、データセキュリティとコンプライアンス要件を満たせます。詳細は こちらのドキュメントをご参照ください。 Amazon WorkSpaces Core がマネージドインスタンスの月額料金を発表 Amazon WorkSpaces Core の管理インスタンスに月次固定料金プランが新登場しました。従来は時間単位課金のみでしたが、常時稼働するデスクトップ環境では月次プランの方がコスト削減できます。例えば毎日 8 時間以上利用する場合、月次プランが経済的です。一方で利用頻度が不定期な場合は時間単位課金がお得。同じ環境内で両方の課金方式を混在させることも可能になり、用途に応じた柔軟なコスト管理が実現できます。 Amazon Bedrock がプロンプトキャッシュで 1 時間の持続時間をサポート Amazon Bedrock で Anthropic Claude モデルのプロンプトキャッシュが 1 時間まで延長可能になりました。従来の 5 分から大幅に延長され、長時間の AI エージェントワークフローや複数回にわたる会話でコスト効率と性能が向上します。例えば、ユーザーが断続的にやり取りするチャットボットや、複雑な処理を段階的に実行する AI エージェントで特に効果的です。詳細は こちらのドキュメントをご参照ください。 1/27(火) Amazon Connect でケースに対する詳細なアクセス制御がサポートされました Amazon Connect Cases でタグベースのアクセス制御が利用できるようになりました。これまでは細かいアクセス権限設定が困難でしたが、ケーステンプレートにタグを設定し、セキュリティプロファイルで特定タグ付きケースへのアクセスユーザーを制限できます。例えば詐欺関連ケースに専用タグを付けて詐欺対応チームのみアクセス可能にするなど、データガバナンスが強化されます。詳細は こちらのドキュメントをご参照ください。 AWS Marketplace が FPGA 製品への AMI セルフサービスリスティング体験を拡張 AWS Marketplace で FPGA (Field Programmable Gate Array) を使った AMI 製品の出品がセルフサービスで可能になりました。従来は手動フォームでの申請が必要でしたが、新しい UI や API を使って直接出品できるようになり、市場投入までの時間を大幅に短縮できます。Amazon F2 インスタンスで動作する高性能な AI や機械学習向けハードウェアアクセラレーターなどの製品販売が効率化され、開発者や企業がより迅速にビジネスを展開できるようになります。詳細は こちらの Seller Guide をご参照ください。 Amazon WorkSpaces が高度なプリンターリダイレクション機能を発表 Amazon WorkSpaces Personal で高度なプリンター リダイレクション機能が利用開始となりました。Windows ユーザーが仮想デスクトップから両面印刷、用紙トレイ選択、ステープル機能などプリンターの全機能を活用できるようになります。従来は基本的な印刷しかできませんでしたが、専門文書やラベル印刷など業務で必要な高度な印刷機能が使えるため、オフィス環境と同等の印刷体験を実現します。詳細は こちらのドキュメントをご参照ください。 1/28(水) マルチリージョン強整合性を持つ Amazon DynamoDB グローバルテーブルが AWS Fault Injection Service によるアプリケーション復旧力テストをサポート Amazon DynamoDB global tables with multi-Region strong consistency が AWS Fault Injection Service (FIS) に対応しました。これにより、リージョン障害などの実際の障害シナリオを意図的に発生させて、アプリケーションがどう応答するかをテストできるようになりました。従来は実際の障害が起きるまでアプリの復旧力を検証できませんでしたが、今回のアップデートで事前にテストして監視や復旧プロセスを改善できます。詳細は こちらのドキュメントをご参照ください。 1/29(木) Amazon GameLift Servers がゼロインスタンスへの自動スケーリングに対応 Amazon GameLift Servers でインスタンス数を 0 まで自動スケールできるようになりました。従来は低アクティビティ時でもインスタンスを稼働し続ける必要がありコストがかかっていましたが、今回のアップデートでゲームセッション要求時のみ自動でスケールアップし、非アクティブ時は完全にスケールダウンできるようになります。ピーク・オフピーク時間が明確なゲームや季節性ゲーム、新規ローンチゲームで大幅なコスト削減が期待できます。詳細は こちらのドキュメントをご参照ください。 AWS が AWS MCP Server (プレビュー) でデプロイメントエージェント SOP を発表 AWS MCP Server で Deployment Agent SOPs がプレビュー開始されました。これにより、開発者は自然言語のプロンプトだけで Web アプリケーションを AWS にデプロイできるようになります。従来はプロトタイプから本番環境への移行に複雑な DevOps 作業が必要でしたが、今回のアップデートで React や Vue.js などのフレームワークで作成したアプリを、たった一つのプロンプトで本番デプロイまで自動化できます。AWS CDK や CI/CD パイプラインも自動生成されるため、開発効率が大幅に向上します。バージニア北部リージョンでプレビュー提供中です。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock が Responses API を使用したサーバーサイドカスタムツールをサポート開始 Amazon Bedrock の Responses API でサーバーサイドツールのサポートが開始されました。これまではクライアントサイドでのツール利用のみでしたが、今回の更新によりサーバーサイドでも直接ツールを呼び出せるようになります。これにより AI アプリケーションが Web 検索、コード実行、データベース更新などをリアルタイムで実行できるため、より高度な自動化処理が可能です。カスタム Lambda 関数や AWS 提供ツールを利用でき、バージニア北部、東京、ミラノなど 9 つのリージョンで利用開始されています。詳細は こちらのドキュメントをご参照ください。 1/30(金) Amazon RDS for Oracle が追加ストレージボリュームを使用したクロスリージョンレプリカをサポート開始 Amazon RDS for Oracle でクロスリージョンレプリカが追加ストレージボリュームに対応しました。これまでプライマリストレージのみでしたが、最大 3 つの追加ボリューム (各 64 TiB) を設定でき、合計 256 TiB まで拡張可能です。ダウンタイムなしでストレージ容量を調整でき、災害復旧用のレプリカでも同様の柔軟性を得られます。詳細は こちらのドキュメントをご参照ください。 新しい Partner Revenue Measurement により AWS サービス消費量の可視性を提供 AWS が Partner Revenue Measurement という新機能を発表しました。AWS パートナーが自社のソリューションがどの程度 AWS サービスの利用につながっているかを可視化できるようになります。これまでパートナーは自分たちの提供するソリューションの AWS 収益への影響を具体的に測定することが困難でしたが、AWS Marketplace の製品コードを使ったタグ付けにより定量的な測定が可能になりました。パートナーにとって自社製品の価値を数値で示せるメリットがあります。詳細は こちらのオンボーディングガイドをご参照ください。 Amazon SageMaker Unified Studio が AWS PrivateLink をサポート開始 Amazon SageMaker Unified Studio が AWS PrivateLink に対応しました。これまではデータ通信がパブリックインターネットを経由していましたが、今回のアップデートにより VPC 内での完全なプライベート接続が可能になります。企業のセキュリティ要件が厳しい環境や、機密データを扱う ML プロジェクトにおいて、データ転送の安全性を大幅に向上させることができます。東京リージョンを含む 15 のリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。新年を迎えたと思ったら、あっという間にもう2月。今回は特に、AWS ジャパンが開始した「 フィジカル AI 開発支援プログラム 」が注目です。ロボット基盤モデル開発を支援する貴重な機会となっています。応募締め切りが2026年2月13日までとなっているのでご興味のある方は、ぜひご確認ください。 それでは今週も、生成AIを活用した開発支援プログラムやソリューション事例、そしてAmazon Bedrockを中心とした注目のサービスアップデートをお届けします。 さまざまなニュース フィジカル AI 開発支援プログラム by AWS ジャパン AWS ジャパンは2026年1月27日から、Vision-Language-Action（VLA）などのロボット基盤モデル開発に取り組む日本の企業・団体を支援する「フィジカル AI 開発支援プログラム」の応募受付を開始しました。このプログラムでは、データ収集・前処理からモデルトレーニング、シミュレーション、実環境へのデプロイまでの一連のパイプライン構築をサポートし、AWSクレジット提供に加えて、フィジカルAI領域スペシャリストによる技術支援、ロボティクス・生成AIコミュニティの形成、そしてモデル開発企業とロボット導入企業のマッチング機会を提供します。ロボティクス分野でAIを活用したい企業にとって、技術面・コスト面の両面で包括的な支援を受けながら、AIのロボティクスへの活用を加速させ、実用化に向けた開発を推進できる貴重な機会となります。プログラムの詳細な内容やスケジュール、応募方法については、ぜひブログ記事をご確認ください。 AWS生成AI事例ブログ「教育者を支援: Innovation Sandbox on AWS が学習目標の達成を加速する方法」 生成AIがテクノロジーの世界に大きな影響を与える中、大学や高等教育機関では学生にサンドボックス環境を提供し、業界が求める生成AIの専門知識を身につけることに取り組んでいますが、数千人の学生向けにサンドボックス環境のAWSアカウントを大規模に作成・管理することは困難でした。この課題を解決するため、Innovation Sandbox on AWSという安全でコスト効率に優れ、再利用可能な一時的なサンドボックス環境の管理を可能にするソリューションを利用し、管理者がサンドボックス環境のライフサイクル全体をセットアップおよび管理する方法を効率化し、技術的な負担を最小限に抑えながら、学生、研究者、教員がAWSで自由に実験できる環境を提供します。教育機関や研究機関にとって、セキュリティポリシー、承認ワークフロー、支出管理メカニズム、アカウントリサイクル設定などを直感的なユーザーインターフェースを通じて提供することで、学生のスキル習得効率が向上し、新しいアイデアやAWSのサービスを簡単に検証できる環境を構築できます。具体的な実装方法やユースケースについては、ぜひブログ記事で詳細をご確認ください。 ブログ記事「SAP JouleでAmazon Bedrock上のAnthropic Claudeモデルを使いSAPコンサルティングプロジェクトを加速」 SAPコンサルタントが複雑なクラウドトランスフォーメーションプロジェクトを進める際、膨大なドキュメントやベストプラクティスへのアクセス、SAP Knowledge Base記事の検索に多くの時間を費やしていました。この課題を解決するため、SAPチームはAWSと提携してSAP Joule for Consultants（J4C）を開発し、Amazon Bedrock上のAnthropic Claudeモデルを活用することで、コンサルタントが会話型AIを通じて独占的なSAPコンテンツに迅速にアクセスできる環境を構築しました。これにより、コンサルタントは特定のビジネスシナリオに対する技術的な実装要件を迅速にナビゲートし理解できるようになり、ジュニアコンサルタントとエキスパートの両方が顧客とのエンゲージメント効率を大幅に向上させ、専門知識をリアルタイムに活用できるようになります。具体的な実装アーキテクチャや成果については、ぜひブログ記事で詳細をご確認ください。 ブログ記事「ABAP Accelerator による AI-Assisted 開発のご紹介」 SAP S/4HANAへの移行を進める企業は、既存システムに存在する数千個のカスタムABAPプログラムのアップグレードが必要で、しかもドキュメントが不足しているという課題に直面しています。この課題を解決するために、ABAP AcceleratorというMCPサーバーベースのツールが提供され、お客様がより速く、より高いコード精度でコードの作成、テスト、ドキュメント化、変換を支援します。ABAP AcceleratorはSAP ABAP Test Cockpitに接続してコードを検証し、Kiro CLI内でお客様がハルシネーションを削減するのに役立ちます。生成AIを活用する開発者にとって、SAP ECCからSAP S/4HANAへの自動コード変換、SAP ABAP Test Cockpitとの統合による構文チェックとカスタムバリアント、そしてトランスフォーメーションのリスクを軽減するテスト駆動開発（TDD）アプローチにより、SAP開発ライフサイクル全体を大幅に最適化し、移行プロジェクトの品質基準を満たしながらビジネスロジックを保持できます。具体的な実装方法や各機能の詳細については、ぜひブログ記事で確認してみてください。 ブログ記事「Agentic workflowを使用したAmazon Nova Premierによるコード移行の効率化」 多くの企業が保守と拡張が困難になった古いテクノロジーで構築されたレガシーシステムに悩まされている中、Amazon Bedrock Converse APIとAmazon Nova Premierをagentic workflow内で使用して、レガシーコードを最新のJava/Springフレームワークアプリケーションに体系的に移行する方法を解説しています。この手法では、移行プロセスを複数の専門エージェントで分担し、堅牢なフィードバックループを実装することで、自動化により移行時間とコストを削減し、専門的な検証エージェントによってコード品質の向上と最新のベストプラクティスへの準拠を保証します。生成AIを活用する開発者にとって、レガシーシステムのモダナイゼーションという複雑な課題に対して、AIエージェントが言語パラダイムの違いやアーキテクチャの複雑性、ビジネスロジックの維持といった多くの課題を自動的に処理しながら、人間の専門家が戦略的な判断や品質保証に集中できる環境を提供し、大規模なコード移行プロジェクトを効率的かつ確実に進めることができます。具体的な実装アーキテクチャや各エージェントの役割については、ぜひブログ記事で詳細をご確認ください。 サービスアップデート Amazon Bedrockがプロンプトキャッシングの1時間保持に対応 Amazon Bedrockで、プロンプトキャッシングの保持時間が従来の5分から最大1時間まで延長できるようになりました。これにより、長時間にわたるAIエージェントとの対話や、ツール実行・データ検索を含む複雑なワークフローにおいて、同じプロンプトのプレフィックス（システムプロンプトやコンテキスト情報など）を再利用することで、コスト効率とレスポンス速度が向上します。この機能はClaude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.5で利用可能で、すべてのAWSリージョンおよびAWS GovCloud (US)リージョンで利用可能です。なお1時間キャッシュは標準の5分キャッシュとは異なる料金体系が適用されます。 AWS が AWS MCP サーバーのデプロイエージェント SOP のプレビューを発表 AWS MCP Serverに、AIエージェントがWebアプリケーションのデプロイメントを自動実行するためのStandard Operating Procedures（SOPs）が追加されました。これにより、開発者はKiro、Cursor、Claude Codeなどのツールから自然言語プロンプトを使うだけで、AWS CDKインフラストラクチャの生成、CloudFormationスタックのデプロイ、セキュリティベストプラクティスを含むCI/CDパイプラインの構築まで、すべて自動的に実行できるようになります。従来は複雑だったDevOpsのベストプラクティスの実装やプロトタイプから本番環境への移行が、たった1つのプロンプトで完結するため、デプロイメント環境を簡単に構築できます。React、Vue.js、Angular、Next.jsなどの主要フレームワークに対応しており、現在米国東部(バージニア北部)リージョンでプレビュー版として追加コストなしで利用可能です。 Amazon BedrockがResponses APIでサーバーサイドカスタムツールに対応 Amazon BedrockのResponses APIで、OpenAI API互換のサービスエンドポイントを使用したサーバーサイドツールが利用可能になりました。従来のクライアントサイドツールと異なり、Bedrockがクライアントを経由せずに直接ツールを呼び出すため、Web検索やコード実行、データベース更新などのマルチステップアクションをリアルタイムで実行でき、レイテンシーを削減しながらAWSアカウントの組織、ガバナンス、コンプライアンス、セキュリティの境界内で安全に動作します。現在、OpenAIのGPT OSS 20B/120Bモデルで利用可能で、東京リージョンを含む複数のリージョンで提供されています。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。今年はコロコロを続けたいと思います。

本ブログは 2025 年 2 月 12 日に公開された AWS Blog “ The importance of encryption and how AWS can help ” を翻訳したものです。オリジナルの記事は、2020 年 6 月 11 日の初回公開以降にリリースされた新しいサービスや機能を含めて再公開されました。 暗号化は、多層防御セキュリティ戦略の重要な要素であり、複数の防御メカニズムを活用してワークロード、データ、資産を保護します。組織が顧客との信頼を築きながらイノベーションを推進するには、重要なコンプライアンス要件を満たし、データセキュリティを向上させる必要があります。暗号化を正しく使用すると、不正アクセスに対する保護層が追加され、データ保護の強化、法規制や業界標準への準拠、通信セキュリティの向上に役立ちます。 暗号化の仕組みと重要性 暗号化とは、アルゴリズムと鍵を使用してデータを読み取り不可能なデータ (暗号文) に変換し、正しい鍵がある場合にのみ再び読み取り可能にする仕組みです。例えば、「Hello World!」のような単純なフレーズは、暗号化すると「1c28df2b595b4e30b7b07500963dc7c」のようになります。暗号化アルゴリズムにはいくつかの種類があり、それぞれ異なる種類の鍵を使用します。強力な暗号化アルゴリズムは、数学的特性を利用して、正しい鍵なしには実質的にどのような計算能力を使っても復号できない暗号文を生成します。そのため、鍵の保護と管理があらゆる暗号化ソリューションの要となります。 セキュリティ戦略を支える暗号化 効果的なセキュリティ戦略は、厳格なアクセス制御と、データにアクセスする人やシステムに必要な最小権限を定義する継続的な取り組みから始まります。AWS クラウドを使用する場合、 責任共有モデル を採用することになります。お客様は自身のアクセス制御ポリシーを管理する責任があります。暗号化は、アクセス制御だけでは防ぎきれない弱点を補うことができるため、多層防御戦略の重要な要素です。アクセス制御メカニズムが失敗し、ディスク上の生データやネットワーク上を流れるデータへのアクセスを許可してしまった場合はどうなるでしょうか？データが強力な鍵で暗号化されていれば、復号鍵がデータと同じシステム上にない限り、悪意のある攻撃者がデータを復号することは現実的に不可能です。 これがいかに不可能かを確認するために、256 ビット鍵を使用した Advanced Encryption Standard (AES-256) を考えてみましょう。これは、業界で広く採用され、米国政府 (NIST) をはじめ各国で標準として承認された、データ暗号化のための最も強力なアルゴリズムです。AES-256 は、AWS でデータを暗号化するために使用している技術で、Amazon Simple Storage Service (Amazon S3) のサーバー側の暗号化などで使われています。現在の (および予見可能な将来の) コンピューティング技術を使用して解読するには、少なくとも 1 兆年かかります。現在の研究では、将来量子コンピューティングが利用可能になっても、AES-256 暗号化を解読するのにかかる時間を十分に短縮することはできないと考えられています。 しかし、誤ってアクセス権限を広く設定しすぎてしまった場合はどうでしょうか？適切に設計された暗号化と鍵管理システムは、復号鍵へのアクセスとデータへのアクセスを分離するため、これが問題になることを防ぐこともできます。 暗号化ソリューションの要件 暗号化ソリューションを最大限に活用するには、2 つのことを考慮する必要があります。 保管中の鍵の保護 : 暗号鍵を使用するシステムは、鍵がシステム外で使用されることがないように保護されていますか？また、暗号化アルゴリズムが正しく実装され、正しい鍵がなければ復号できない強固な暗号文が生成されていますか？ 独立した鍵管理 : 暗号鍵へのアクセス制御は、データへのアクセス制御から分離されていますか？ これらの要件を満たすために AWS に導入できるサードパーティソリューションがあります。ただし、これらのシステムは大規模に運用するのが難しく、コストがかかる場合があります。AWS は、暗号化と鍵管理を簡素化するためのさまざまなオプションを提供しています。 保管中の鍵の保護 サードパーティの鍵管理ソリューションを使用する場合、平文の暗号鍵が漏洩してソリューション外で使用されるリスクを評価することが難しい場合があります。鍵はどこかに保存する必要があり、それらのストレージシステムが不正アクセスからどのように保護されているかをすべて把握したり監査したりできるとは限りません。鍵管理ソリューションは技術的に複雑なうえ、パフォーマンスや可用性を損なわずに運用する必要があるため、選択と運用には難しいトレードオフが伴います。鍵のセキュリティを最大化するためのベストプラクティスは、ハードウェアセキュリティモジュール (HSM) を使用することです。HSM は専用のコンピューティングデバイスで、暗号鍵がデバイス外に流出して攻撃者に悪用されることを防ぐための複数のセキュリティ制御が組み込まれています。 モダンな HSM におけるそのような制御の 1 つが改ざん検知応答です。これは、デバイスが平文の鍵への不正アクセスの物理的または論理的な試みを検出し、攻撃が成功する前に鍵を破棄するものです。AWS データセンターにお客様独自のハードウェアを設置して運用することはできないため、AWS はお客様の鍵を保護するために改ざん検知応答を備えた HSM を使用する 2 つのサービスを提供しています。1 つは AWS Key Management Service (AWS KMS) でお客様に代わって AWS が HSM のフリートを管理します。もう 1 つは、 AWS CloudHSM でお客様が独自の HSM を管理する機能を提供します。どちらのサービスも、鍵を新規作成することも、オンプレミスシステムから既存の鍵をインポートすることも可能です。 AWS KMS または AWS CloudHSM の鍵は、データの直接暗号化に使用できるほか、アプリケーションがデータ暗号化に使用する鍵 (データキー) を保護するためにも使用できます。暗号鍵を暗号化する技術はエンベロープ暗号化と呼ばれ、毎回データを HSM に送信して暗号処理するのではなく、平文のお客様データが存在するコンピュータ上で暗号化と復号を行うことができます。非常に大きなデータセット (データベースなど) の場合、読み取り/書き込み操作のたびにデータセットと HSM の間でギガバイトのデータを移動することは現実的ではありません。代わりに、エンベロープ暗号化により、必要なときにデータキーをアプリケーションに払い出すことができます。HSM 内に保存された暗号鍵は、データキーのコピーを暗号化するために使用され、アプリケーションはその鍵で暗号化されたデータと一緒に暗号化された鍵を保存できます。アプリケーションがデータを暗号化すると、コピーされた平文のデータキーはメモリから削除できます。データを復号する唯一の方法は、わずか数百バイトのサイズの暗号化されたデータキーを HSM に送り返して復号することです。 エンベロープ暗号化のプロセスは、パフォーマンスの低下を最小限に抑えるために、お客様に代わってデータが暗号化される AWS サービス (サーバー側の暗号化) で使用されています。独自のアプリケーションでデータを暗号化する場合 (クライアント側の暗号化)、AWS KMS または AWS CloudHSM でエンベロープ暗号化を使用することをお勧めします。両方のサービスは、アプリケーションコードに暗号化機能を追加し、各サービスの暗号化機能を使用するためのクライアントライブラリと SDK を提供しています。 AWS Encryption SDK は、AWS で実行されているアプリケーションだけでなく、どこでも使用できるツールの例です。 Amazon DynamoDB などのデータベースでデータを暗号化することをお客様にとってより簡単にするために、AWS は AWS Database Encryption SDK を開発しました。AWS Database Encryption SDK は、データベースでクライアント側の暗号化を使用できるようにするソフトウェアライブラリのセットで、データベースアイテムのレコードレベルの暗号化にも対応しています。現在、AWS Database Encryption SDK は Amazon DynamoDB の属性単位の暗号化をサポートしています。 暗号化アルゴリズムと HSM の実装を正しく行うことが重要であるため、HSM のすべてのベンダーは、信頼できる第三者による製品の検証を受ける必要があります。AWS KMS と AWS CloudHSM の両方の HSM は、暗号モジュールを評価するための標準である米国国立標準技術研究所 (NIST) の FIPS 140 プログラムに基づいて検証されています。これにより、ポートとインターフェース、認証メカニズム、物理的セキュリティと改ざん検知応答、運用環境、暗号鍵管理、電磁干渉/電磁両立性 (EMI/EMC) に関連する機能を含む、暗号モジュールの安全な設計と実装が検証されます。FIPS 140 レベル 3 で検証された暗号モジュールを使用した暗号化は、米国の FedRamp や HIPAA-HITECH、または国際的なペイメントカード業界標準 (PCI-DSS) などの他のセキュリティ関連のコンプライアンススキームの要件であることが多いです。 独立した鍵管理 AWS KMS と AWS CloudHSM はお客様に代わって平文の暗号鍵を保護できますが、どの暗号鍵をどのような条件で誰が使用できるかを決定するアクセス制御の管理は、お客様の責任です。AWS KMS を使用する利点の 1 つは、鍵のアクセス制御を定義するために使用するポリシー言語が、他のすべての AWS リソースへのアクセスを定義するために使用するものと同じであることです。ただし、言語が同じであっても、実際の認可制御は同じではないことに注意してください。データへのアクセス管理に使用するものとは異なる、鍵へのアクセス管理メカニズムが必要です。AWS KMS は、鍵の管理のみを行う管理者のセットと、基盤となる暗号化データへのアクセス管理のみを行う別の管理者のセットを割り当てることができるメカニズムを提供します。このような鍵管理の仕組みを採用することで、職務分離を実現し、意図しない復号権限の付与を防ぐことができます。さらに制御を分離するために、AWS CloudHSM は鍵へのアクセスを定義するための独立したポリシーメカニズムを提供しています。 2022 年に、 AWS KMS は外部キーストア (XKS) のサポートを開始しました 。これは、オンプレミスまたは任意の場所で運用する HSM に AWS KMS カスタマーマネージドキーを保存できる機能です。仕組みとしては、AWS KMS は暗号化と復号のリクエストをお客様の HSM に転送します。鍵マテリアルがお客様の HSM から外に出ることはありません。これにより、暗号鍵を AWS データセンター外で保存および使用する必要がある、一部の高度に規制されたワークロードのユースケースにも対応できます。ただし、XKS では責任共有モデルにおける責任範囲が大きく変わります。KMS キーの耐久性、スループット、レイテンシー、可用性についてはお客様が責任を負うことになります。その鍵が紛失または破壊された場合、データへのアクセスを永久に失う可能性があり、XKS 鍵が利用できなくなった場合、その XKS 鍵に依存する AWS 内のすべてのワークロードにアクセスできなくなります。 AWS では、鍵管理とデータ管理を分離する機能があっても、暗号鍵へのアクセスが正しく設定されていることを検証できます。AWS KMS は AWS CloudTrail と統合されているため、誰がどの鍵を、どのリソースに対して、いつ使用したかを監査できます。これにより、暗号化管理プロセスをきめ細かく可視化でき、通常はオンプレミスの監査メカニズムよりもはるかに詳細な情報を得られます。AWS CloudHSM からの監査イベントは、AWS で運用するサードパーティソリューションの監視とアラームを行う AWS サービスである Amazon CloudWatch に送信できます。 保管中のデータと転送中のデータの暗号化 お客様のデータを扱う AWS サービスは、システム間で送信されるデータ (転送中のデータ) と保管中のデータの両方を暗号化するオプションを提供しています。AWS KMS または AWS CloudHSM を使用した保管時の暗号化を提供する AWS サービスは、AES-256 を使用しています。これらのサービスはいずれも、平文の暗号鍵を保管時に保存しません。これは、FIPS 140 レベル 3 で検証された HSM を使用する AWS KMS と AWS CloudHSM が担う機能です。このアーキテクチャにより、鍵の不正使用リスクを最小限に抑えることができます。 転送中のデータの暗号化では、AWS サービスは Transport Layer Security (TLS) プロトコル を使用して、アプリケーションと AWS サービス間の通信を暗号化します。ほとんどの商用ソリューションは、TLS の実装に OpenSSL というオープンソースプロジェクトを使用しています。OpenSSL には約 50 万行のコードがあり、そのうち少なくとも 7 万行が TLS の実装に使用されています。コードベースは大規模で複雑なため、監査が困難です。さらに、OpenSSL にバグが見つかった場合、グローバルな開発者コミュニティは修正とテストを行うだけでなく、その修正自体が新たな欠陥を導入しないことも確認しなければなりません。 OpenSSL の TLS 実装に関するこれらの課題に対応するため、AWS は s2n (signal to noise の略) として知られる独自の TLS 実装を開発しました。AWS は 2015 年 6 月に s2n をリリースしました 。s2n は小さく高速になるように設計されており、理解しやすく完全に監査可能なネットワーク暗号化を提供することを目標としています。Apache 2.0 ライセンスの下でリリースされ、 GitHub でホスティングされています 。 また、s2n は数学的論理を使用して安全性と正確性をテストする自動推論で分析できるように設計されています。形式手法として知られるこのプロセスにより、コードを変更するたびに s2n コードベースの正確性を検証しています。さらに、これらの数学的証明を自動化し、コードの新しいリリースでも望ましいセキュリティ特性が維持されていることを確認するために定期的に再実行しています。数学的証明による正確性の自動検証はセキュリティ業界で注目を集めている先進的な手法であり、AWS はミッションクリティカルなソフトウェア全般でこのアプローチを採用しています。 同様に、2022 年に AWS は s2n-quic をリリースしました。これは QUIC プロトコルの Rust によるオープンソース実装であり、AWS 暗号化オープンソースライブラリのセットに追加されました。QUIC はパフォーマンスを重視して設計された暗号化トランスポートプロトコルであり、HTTP/3 の基盤となっています。2021 年 5 月に批准された一連の IETF 標準で規定されています。 Amazon CloudFront の HTTP/3 サポートは s2n-quic の上に構築されています 。これは、パフォーマンスと効率性を重視しているためです。s2n-quic の詳細については、こちらの Security Blog の記事 をご覧ください。 TLS を実装するには、暗号鍵とデジタル証明書が必要です。デジタル証明書は公開鍵の所有者を証明します。 AWS Certificate Manager と AWS Private Certificate Authority を使用すると、TLS エンドポイントを提供するインフラストラクチャ全体でデジタル証明書の発行とローテーションを簡素化できます。両方のサービスは、AWS KMS と AWS CloudHSM の組み合わせを使用して、発行するデジタル証明書で使用される鍵を生成および保護します。 使用中のデータの暗号化 複数の組織が共同でトレーニングする機械学習モデルやその他のアプリケーションでアクティブに使用されているデータを保護するユースケースもあります。 暗号コンピューティング は、暗号化されたデータに対して計算を実行できる技術のセットであり、機密データを公開せずに使用中のデータを保護する方法論です。 保険詐欺検出のための機械学習モデルを開発するために他の企業と協力する保険会社の例を考えてみましょう。モデルのトレーニングデータとして顧客に関する機密データを使用する必要があるかもしれませんが、顧客データを平文で他の企業と共有することは避けたいところです。暗号コンピューティングにより、組織は顧客に関する平文データを互いに、または AWS のようなクラウドプロバイダーに公開することなく、共同でモデルをトレーニングできます。暗号コンピューティングの詳細については、こちらの AWS Security Blog の記事 をご覧ください。 現在、暗号コンピューティングは AWS Clean Rooms で実際に使用されています。AWS Clean Rooms は、企業とそのパートナーが互いの基盤となるデータを共有またはコピーすることなく、集合的なデータセットをより簡単かつ安全に分析およびコラボレーションできるようにするサービスです。AWS Clean Rooms には Cryptographic Computing for AWS Clean Rooms (C3R) という機能があり、AWS Clean Rooms のコラボレーションで処理されている間もデータを暗号的に保護します。 セキュアな通信におけるエンドツーエンド暗号化の役割 エンドツーエンド暗号化 (E2EE) は、2 者以上の間でセキュアな通信を行う方法であり、転送中の暗号化と保管中の暗号化を組み合わせて、不正アクセス、盗聴、改ざんからデータを保護します。復号は通信相手のみで行われ、その間のサービスプロバイダーでは行われません。すべての通話、メッセージ、ファイルは一意の秘密鍵で暗号化され、転送中も保護されたままです。権限のない第三者はデータを復号するために必要な秘密鍵を持っていないため、通信内容にアクセスできません。 AWS Wickr は、1 対 1 およびグループメッセージング、音声およびビデオ通話、ファイル共有、画面共有、位置情報共有を 256 ビット暗号化で保護するエンドツーエンド暗号化メッセージングおよびコラボレーションサービスです。Wickr では、各メッセージに一意の AES 秘密暗号鍵と、受信者との鍵交換をネゴシエートするための一意の楕円曲線ディフィー・ヘルマン (ECDH) 公開鍵が割り当てられます。テキスト、ファイル、音声、ビデオを含むメッセージコンテンツは、メッセージ固有の AES 鍵を使用して送信デバイス (例: iPhone) で暗号化されます。この鍵は ECDH 鍵交換メカニズムを使用して交換されるため、正当な受信者のみがメッセージを復号できます。 量子コンピューティングとポスト量子暗号 量子コンピューティングは、量子力学を使用して従来のコンピュータよりも高速に複雑な問題を解決する技術分野です。量子コンピュータは、重ね合わせや量子干渉などの量子力学的効果を利用することで、特定の種類の問題をより高速に解決できます。暗号化においては、これは公開鍵暗号方式などの従来の暗号化メカニズムに影響を与えます。公開鍵暗号方式は、転送中のデータの保護 (TLS) や、メッセージやファイルの整合性と真正性を検証するためのハッシュベースの署名の作成によく使用されます。量子コンピュータが十分な性能と安定性を持つようになれば、理論的には RSA、楕円曲線暗号 (ECC)、ディフィー・ヘルマン鍵合意方式などの公開鍵暗号アルゴリズムのセキュリティを危険にさらす可能性があります。現在の研究に基づくと、AES のような対称鍵アルゴリズムは量子コンピュータによるリスクは低いと考えられています。256 ビットの鍵長であれば、量子アルゴリズムによる暗号強度の低下を補うのに十分だからです。 AWS は、従来のアルゴリズムと併せてポスト量子アルゴリズムを利用できるオプションをお客様に提供しています。これは、従来の暗号化と、量子コンピュータの脅威に耐性を持つように設計された新しいポスト量子暗号 (PQC) アルゴリズムの両方を使用するハイブリッド方式によるものです。AWS は、AWS-LC (AWS のオープンソース FIPS-140-3 検証済み暗号ライブラリ) 内に ML-KEM (モジュール格子ベースの鍵カプセル化メカニズム) を実装し、PQC の展開をさらに推進しています。AWS-LC は AWS 全体で使用されるコア暗号ライブラリです。具体的には、AWS-LC は s2n-tls で使用されています。s2n-tls は HTTPS ベースのエンドポイントを持つ AWS サービス全体で使用される AWS のオープンソース TLS 実装です。 AWS は、AWS KMS、AWS Certificate Manager (ACM)、 AWS Secrets Manager の TLS エンドポイントにポスト量子対応の s2n-tls を導入しました。これにより、AWS SDK でハイブリッドポスト量子 TLS を有効にしてこれらのサービスに接続するお客様は、ポスト量子暗号のメリットを享受できます。 AWS Transfer Family も、ポスト量子ハイブリッド SFTP ファイル転送をサポートしています。より多くの AWS マネージドサービスエンドポイントを TLS 経由の PQC に移行する取り組みの詳細については、 こちらの AWS Security Blog の記事 をご覧ください。また、 Amazon Science Blog で暗号研究と改善における Amazon と AWS の取り組みに関する情報 もご覧いただけます。 Encrypt everything, everywhere AWS は、Encrypt everything, everywhere (すべてを、どこでも暗号化) する機能をお客様に提供しています。AWS マネジメントコンソールで数回クリックするか、AWS API コールを使用するだけで、保管中、転送中、メモリ内のデータを暗号化できます。 Amazon Simple Storage Service (Amazon S3) などのサービスは、デフォルトで新しいオブジェクトを暗号化し、暗号鍵をより細かく制御したい場合は、お客様が管理する AWS KMS キーの使用もサポートしています。重要なのは、AWS KMS がエンベロープ暗号化や高度にスケーラブルな鍵管理インフラストラクチャなどの技術を使用して、Amazon S3 や Amazon Elastic Block Store (Amazon EBS) などの AWS サービスが、アプリケーションのパフォーマンスへの影響を最小限に抑えながらデータを暗号化できるようにしていることです。 AWS は、ネットワークやデバイス間を移動するデータのパフォーマンスとセキュリティを継続的に改善しています。 2024 年 6 月時点で、すべての AWS API エンドポイントは TLS 1.3 をサポート し、少なくとも TLS 1.2 以上を必要としています。TLS 1.3 を使用することで、接続リクエストごとに 1 回のネットワークラウンドトリップを削減して接続時間を短縮でき、現在利用可能な最新かつセキュアな暗号スイートのメリットを享受できます。 メモリ暗号化が必要な場合は、ARM ベースのカスタムビルトプロセッサファミリーである AWS Graviton を使用できます。AWS Graviton2、AWS Graviton3、AWS Graviton3E では、メモリ暗号化が常に有効になっています。暗号鍵はホストシステム内でセキュアに生成され、ホストシステムから外に出ることはなく、ホストが再起動または電源オフされると破棄されます。メモリ暗号化は他のインスタンスタイプでもサポートされています。詳細については、 EC2 ドキュメント をご覧ください。 AWSのデジタル統制に関するお客様との約束 の一環として、お客様が AWS クラウド内外で管理する暗号鍵を使用して、Encrypt everything, everywhere (すべてを、どこでも暗号化) できるよう、革新と投資を継続することをお約束します。 まとめ AWS では、セキュリティが最優先事項です。AWS は、お客様がデータの使用・アクセス・保護を制御できるようにすることにコミットしています。クラウド上でもクラウド外でも機能する暗号化ツールを提供およびサポートすることで、データを保護し、環境全体でコンプライアンスを実現できるよう支援しています。AWS は、セキュリティをすべての取り組みの中核に置き、最高水準のセキュリティ技術でコスト効率よくデータを保護できるようにしています。 この記事についてご質問がある場合は、 AWS KMS フォーラム または AWS CloudHSM フォーラム で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Ken Beer Ken は AWS Key Management Service および暗号ライブラリのディレクターです。AWS で 7 年以上にわたり、ID およびアクセス管理、暗号化、鍵管理に携わってきました。AWS に入社する前は、Trend Micro でネットワークセキュリティ事業を担当していました。Trend Micro の前は、Tumbleweed Communications に在籍していました。RSA Conference、DoD PKI User’s Forum、AWS re:Invent などのイベントで、さまざまなセキュリティトピックについて講演しています。 Zach Miller Zach は AWS のプリンシパルセキュリティスペシャリストソリューションアーキテクトです。データ保護とセキュリティアーキテクチャのバックグラウンドを持ち、応用暗号化やシークレット管理を含むさまざまなセキュリティドメインに注力しています。現在は、エンタープライズのお客様が AWS セキュリティサービスを採用し運用化することで、セキュリティの有効性を高め、リスクを軽減できるよう支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

このブログは、2026 年 1 月 5 日に Fabio Bottoni、Dr. Bin Qiu、Dr. Song Zhang によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 エネルギー環境が分散型モデルへと進化する中、分散型エネルギーリソース ( DER ) は、エネルギー市場のさまざまなプレーヤー (電力会社、立法機関、アグリゲーター、消費者、サービスプロバイダー) に課題と機会の両方をもたらしています。 さまざまな関係者が Amazon Web Services (AWS) を活用して DER を最大限に活用する方法について、ブログシリーズを通して説明していきます。最初のブログでは、アグリゲーターが事業の成長に合わせて拡張できる堅牢な分散型エネルギーリソース管理システム ( DERMS ) を構築するために、AWS サービスがどのように役立つかを探ります。 DER アグリゲーターの課題 DER アグリゲーター は、数千の分散型エネルギーの設備を効率的に管理する、複雑化する環境で事業を展開しています。これらの設備は、住宅用太陽光発電設備や産業用蓄電池システムから、広範囲に展開された電気自動車充電ネットワークまで多岐にわたります。課題は設備の管理だけにとどまりません。アグリゲーターは、規制への準拠を確保し、高いサービス信頼性を維持しながら、さまざまなエネルギー市場への参加を最適化する必要があります。 こうした要求に応えていくためには、リアルタイムの監視と制御を処理し、複数の通信プロトコルと統合できる高度なソリューションが必要です。また、高度な予測と最適化アルゴリズムを実行し、堅牢なサイバーセキュリティ対策を維持し、膨大な量のデータを効率的に管理する必要があります。これらの技術的課題は、DER の構成要素が多種多様であるため、さらに複雑になります。アグリゲーターは、応答時間、運用上の制約、通信機能が異なるさまざまな技術を調和させる必要があります。 このようなソリューションを実装するには、堅牢な通信インフラストラクチャと、グリッド（送配電網）を新たな脅威から保護するための高度なサイバーセキュリティ対策が必要であり、同時にコスト効率も維持する必要があります。また、システムレベルの制約と個々の DER の制限の両方を考慮した複雑な入札戦略を開発する必要があります。複雑な決済プロセスに対処し、複数の市場商品にわたる財務リスクを管理する必要があります。 規制環境も、グリッド運用者が課題の解決方法を意思決定するプロセスに影響を与えています。たとえば北米では、 FERC Order 2222 の実施により、地域送電機関 ( RTO ) と独立系統運用者 (ISO) は、卸売市場への DER アグリゲーションの参加を可能にする必要があります。この規制命令は、最小サイズ要件 (具体的には、アグリゲーションは 100 kW まで小さくできる) を満たし、小売市場と卸売市場間の両方の参加ルールを確立し、配電事業者と調整して信頼性の高いグリッド運用を確保することを義務付けています。 別の例として、ドイツの エネルギー産業法 の 第 14a 条 があります。この機能により、配電系統運用者 ( DSO ) に、顧客所有の DER (ヒートポンプ、EV 充電器、蓄電池など) を積極的に管理することを要求しています。第 14a 条により、動的な DER 制御を通じてグリッドの安定性が向上しますが、アグリゲーターは DSO の要件と市場へのコミットメントを慎重にバランスさせる必要があります。 こうした規制フレームワークは、グリッド運用者、DER 所有者、アグリゲーター間の関係が進化していることを示すとともに、高度な管理および通信システムの必要性を強調しています。 ソリューション概要 AWS は、DSO とアグリゲーターが最新の DER 管理の複雑な課題に対処する方法を提供する包括的なサービス群を提供しています。以下のセクションでは、AWS 上でのクラウドネイティブな DERMS アーキテクチャの実装を順を追って説明し、これがどのように実現できるかを詳しく説明します。 このアーキテクチャは、次のような重要な業界の課題を解決することを目的としています。 多種多様な DER 設備のニアリアルタイムの可視化と制御 複数の通信プロトコルの統合 DER の制限を踏まえた動的最適化 市場参加の調整 数百から数百万の接続デバイスへのシームレスな拡張 このアーキテクチャは、エッジコンピューティング機能、堅牢なデータストリーミング、高度な分析、エンタープライズグレードのセキュリティを統合します。AWS は、電力会社が従来の配電系統運用者から高度な分散システムオーケストレーターへと変革することを支援します。 図 1 – ハイレベルのソリューションアーキテクチャ それでは、アーキテクチャの各セクションを詳しく見ていきます。各セクションがなぜ重要なのか、AWS サービスがどのように課題解決に役立つのかを説明します。以下のセクションについて説明します。 1. エッジでの DER 統合 2. データ取り込み 3. データストリーミング 4. ストレージレイヤー 4.1 ホットストレージ – 時系列データベース 4.2 コールドストレージ – データレイク 5. リアルタイム分析 6. アプリケーション統合 7. DERMS アプリケーション 8. 人工知能と機械学習 9. セキュリティとコンプライアンス 1. エッジでの DER 統合 DER は多様な性質と従来の産業用プロトコルへの依存により、統合には独自の課題があります。多くの DER の設備は、 Modbus や DNP3 などのローカルプロトコルを使用して通信するため、クラウドへの直接統合ができません。ローカルプロトコルとクラウド間のギャップを埋めるため、AWS では AWS IoT Greengrass を提供しています。AWS IoT Greengrass は、デバイスソフトウェアを構築、デプロイ、管理するオープンソースのエッジランタイムおよびクラウドサービスです。エッジで実行されるサービスとして、AWS IoT Greengrass は、ローカルプロトコルをクラウド互換形式に変換するロジックを管理できます。標準化されたプロトコルで AWS への安全で信頼性の高いデータ送信を実現します。 AWS IoT Greengrass はモジュール設計を採用しています。一部のモジュールは AWS によって提供され、他のモジュールは顧客またはエンドユーザーが開発できます。また、多くの AWS パートナー が AWS IoT Greengrass を直接サポートまたは統合し、プロトコルアダプターやその他の機能を提供してデバイス統合を促進しています。 一般的な統合プロトコルは次のとおりです。 Standard IEEE 2030.5 (北米の電力会社で広く使用) Modbus (産業環境で一般的) DNP3 (電力会社の運用で普及) IEC-61850 (変電所の自動化に不可欠) 2. データ取り込み DER のポートフォリオが数百から数百万の設備に成長するにつれて、電力会社は、デバイス登録の管理、場所やタイプ別の設備の整理、運用ステータスの監視、協調制御アクションの実行において、ますます複雑さに直面しています。 AWS IoT Core は、安全なデバイス接続の中心ハブとして機能し、DER 設備からの数百万の同時接続を処理します。 AWS IoT Device Management は、エッジデバイスを大規模に登録、グループ化、検索、監視、リモート管理するための包括的な機能を提供することで、スケーラビリティの課題に対処します。電力会社は DER フリートを効率的に統制および制御できます。たとえば、統合デマンドレスポンスイベントのために、特定の都市、郵便番号、または地理的場所のすべてのバッテリーをグループ化できます。 迅速に更新できないレガシーまたは既存の DER 設備の場合、AWS IoT Greengrass は中間管理デバイスとして機能できます。古いデバイスはネイティブプロトコルを引き続き使用でき、AWS IoT Greengrass がプロトコル変換、セキュリティ、クラウド接続を処理します。さらに、カスタムプロトコルアダプターにより、独自またはレガシープロトコルとの統合が可能になります。この機能により、非標準デバイスでもハードウェアのアップグレードを必要とせずに DERMS エコシステムに組み込むことができます。 DER 管理における最も重要な課題の 1 つは、断続的なネットワーク接続を持つ DER 設備に対する信頼性の高い制御を維持することです。グリッド運用者は、デバイスが一時的に接続を失った場合でも、コマンド配信と状態同期を保証する必要があります。 AWS IoT Device Shadow サービスは、クラウド内に各デバイスの仮想的な状態 (シャドウ) を永続的に維持することで、これを解決します。 この シャドウ サービスは 3 つの状態ビューを提供します。Desired State (ソリューションが望む状態)、Reported State (最後に確認されたデバイスの状態)、Delta State (Desired と Reported の差分) です。デバイスがオフラインになると、制御コマンドは Desired State に保存されます。再接続すると、デバイスは自動的にこれらの保留中のコマンドを受信して処理し、制御アクションが失われないことを確認します。デバイスとソリューションの更新間で競合が発生した場合、シャドウサービスはバージョン追跡を使用した Last-Writer-Wins (後勝ち) ルールで競合を解決して、データの一貫性を維持します。 AWS IoT Device Defender は、異常な動作を継続的に監視し、セキュリティの問題を検出し、IoT フリートが侵害される前に潜在的な脅威を警告することで、IoT デバイスを保護します。 AWS IoT Core を流れるすべてのデータは、 AWS IoT Rules を使用して他の AWS サービスにルーティングされます。各 IoT Rule はデータを選択し、次の機能ブロックであるデータストリーミングサービスに送信します。 3. データストリーミング 最新の DERMS プラットフォームは、DER 運用の複雑さを反映する多様なデータ処理要件に対応する必要があります。グリッド運用者は、集約された DER を仮想発電所 (VPP：Virtual Power Plant) として扱い、従来の発電機と同様の監視および制御機能を必要とします。時間間隔に関する要件は多岐にわたります。周波数応答や電圧サポートなどの重要なグリッドサービスは、通常 100 ミリ秒から 1 秒の間隔で、サブ秒の監視と制御を要求します。運転予備力や容量サービスを実行する大規模な DER 設備 (&gt; 1 MW) には 2 ~ 4 秒の監視が必要ですが、デマンドレスポンスまたはエネルギー裁定取引に参加するメーターの背後にある DER は通常 5 ~ 15 分間隔で報告します。さらに、長期計画および決済機能には、分析とコンプライアンスのために数か月または数年の履歴データが必要です。 AWS は、これらのニーズに対応するさまざまなストリーミングサービスを提供しています。 Amazon Kinesis Data Streams はサーバーレスサービスであり、容量を推測することなく DER デプロイメントを迅速にスケールアップおよびスケールダウンするのに最適です。Kinesis Data Streams は他の AWS サービスとネイティブに統合されています。DERMS ソリューションと接続および切断する DER の数が動的であり、完全な AWS ネイティブアーキテクチャのケースで使用することが推奨されます。 Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、メッセージ量が予想できるようなより安定した DERMS デプロイメントに適しています。Amazon MSK は、処理されたデータをより長い時間保持し、ストレージとして機能できます。この機能を使用して、外部ストレージを使用せずに Kinesis Data Streams から直接再処理を実行できます。Amazon MSK は、DER の数が予測可能であり、非 AWS ネイティブアーキテクチャのケースで使用することをお勧めします。 規制コンプライアンスや長期計画のためのテレメトリデータのアーカイブなど、時間的制約の少ないデータフローの場合、 Amazon Kinesis Firehose はコード不要のソリューションを提供します。AWS IoT Core から直接データを受信し、Amazon Simple Storage Service (Amazon S3) に書き込むことができ、データに対するバッチ処理とパーティション分割のための組み込みオプションがあります。 4. ストレージレイヤー 前述のように、DER 運用のタイムスケールは、グリッド安定化に関するミリ秒レベルの応答から市場参加に関する時間単位の応答まで、幅広く多様です。 こうした幅広い要件に対しては、2 種類のストレージを用いるアプローチが効果的です。 低レイテンシーのリアルタイム運用のための時系列データベース (4.1) 高レイテンシーの履歴分析と計画のためのデータレイク (4.2) このソリューションアーキテクチャは、最新の DER 管理のさまざまな時間間隔の要件を満たしながら、パフォーマンスとコストを最適化します。 時系列データベース (4.1 ホットストレージ) とデータレイク (4.2 コールドストレージ) 低レイテンシーアクセス用に最適化されたホットストレージレイヤーは、応答時間がグリッドの安定性に直接影響するリアルタイムの DER 運用に不可欠です。周波数調整などの時間的に重要な機能には、ミリ秒単位のデータアクセスが必要であったり、デマンドレスポンスプログラムには通常、数秒以内の応答時間が必要です。 Amazon Timestream for InfluxDB はこれらのニーズに対応しているため、電力会社はデータベース管理ではなく運用に集中できます。時系列データとリレーショナルデータの両方を含む、より複雑なクエリの場合、 Amazon OpenSearch Service は柔軟なインデックス作成と検索機能を提供します。DER の動作をグリッドのイベントと相関させる必要がある障害分析やパフォーマンス監視に特に有用です。 Amazon S3 と AWS Lake Formation を使用して実装されたコールドストレージレイヤーは、履歴データ分析と規制コンプライアンスのニーズに対処します。このレイヤーは、個々のデバイステレメトリから集約パフォーマンスメトリクスまで、包括的な運用データを保存し、通常は秒ではなく分単位でアクセスされます。応答時間は遅くなりますが、テラバイトあたりのコストは大幅に低くなります。この機能は、規制報告と長期計画のために何年もの DER 運用データを管理する電力会社にとって重要です。AWS Lake Formation は、権限管理を一元化し、組織の境界を越えた安全なデータ共有を合理化します。この機能は、規制機関や市場運用者との調整に不可欠です。 AWS Glue Data Catalog は、中央メタデータリポジトリとして機能し、組織全体でデータ資産を迅速に検出および管理できます。このカタログは、データの属性、スキーマ、場所の包括的なインベントリを維持するため、チームは分析に関連する履歴データを迅速に見つけてアクセスできます。 AWS Glue は、データの準備と変換タスクを自動化することでこれを補完し、履歴トレンドとパフォーマンスパターンをより迅速に分析できます。 ホットストレージからコールドストレージへのデータの移動は、データアクセス要件とコスト削減のバランスによって決定されます。ミッションクリティカルなリアルタイムの DER 運用に使用されなくなったホットストレージデータ (たとえば、数時間または 1 日後) は、コールドストレージへの移動を検討できます。古いデータは、コスト削減とパフォーマンスの観点でコールドストレージに移動するための時間しきい値によって事前定義できます。 5. リアルタイム分析 DER 運用の真の価値には 3 つの重要な側面があります。第一に、グリッド運用者は、最大消費電力を管理し、グリッドの安定性を維持するための強力なツールとして DER を捉えています。第二に、消費者は戦略的な市場参加を通じて財務的利益を最大化することにますます焦点を当てています。第三に、電力会社は、コストのかかるインフラストラクチャのアップグレードを延期するために DER を使用することに大きな価値を見出しています。 これらの目標をサポートするために、DERMS プラットフォームは、さまざまなリアルタイムデータストリームを処理および分析する必要があります。これには、基本的な電圧と電流の測定から、高度な市場シグナルと気象予測まで、すべてが含まれます。各データポイントは、グリッドの安定性と市場機会のバランスを取りながら、情報に基づいたディスパッチの決定を行う上で重要な役割を果たします。 ほぼリアルタイムの分析機能を実装するため、AWS は、さまざまなユースケースに対応する 2 つの異なるサービスを提供しています。 Amazon Managed Service for Apache Flink は、ステートフル操作と Exactly Once での処理が重要な、周波数応答のために数千の DER を調整するなどのシナリオで優れています。Flink のイベント時間処理機能により、イベントの正確なタイミングと順序が重要なリアルタイム市場入札などのアプリケーションに最適です。 AWS Lambda は、個別のイベント駆動型処理ニーズを処理することで、このアーキテクチャを補完します。個々のデバイステレメトリ検証、アラーム処理、または特定のイベントに応答したデバイスステータスの更新などのタスクに適しています。 これらのサービスは通常、包括的な DERMS ソリューションで連携して機能します。Flink は継続的で複雑なストリーム処理要件を処理し、Lambda は個別のイベント駆動型タスクを管理します。 6. アプリケーション統合 DERMS が効果的に機能するには、電力会社の既存のエンタープライズシステムとシームレスに統合する必要があります。 主なエンタープライズシステムとの統合は次のとおりです。 顧客関係管理 (CRM：Customer Relationship Management) システム は、DER プログラムの登録、請求、サービス管理に不可欠なデータを提供します。 高度計量インフラストラクチャ (AMI：Advanced Metering Infrastructure) は、スマートメーターからのリアルタイムのエネルギー消費と生産データを提供します。 地理情報システム (GIS：Geographic Information System) マッピング により、グリッドの設備に対する DER の場所の空間認識が可能になります。 監視制御とデータ収集 (SCADA：Supervisory Control And Data Acquisition) システム は、リアルタイムのグリッド状態情報と制御機能を提供します。 気象予測システム は、再生可能エネルギーの発電量と消費電力のパターンの予測に役立ちます。 設備管理システム は、DER のメンテナンススケジュールと運用ステータスを追跡します。 配電管理システム (DMS) は、基幹系統運用との調整を確保します。 これらの統合は包括的な意思決定に不可欠です。たとえば、CRM データと AMI 読み取り値を組み合わせることで、パーソナライズされたデマンドレスポンスプログラムが可能になります。GIS と SCADA を統合すると、電圧サポートのための場所を認識した DER へのディスパッチが可能になります。多くの電力会社は、これらのシステムをオンプレミスでホストしているため、アプリケーションがクラウドに移行するにつれて適応できる柔軟な統合アプローチが必要です。 AWS は、さまざまな統合シナリオに合わせたソリューションを提供しています。 Amazon AppFlow は、SaaS (Software as a Service) から AWS への統合に優れています。Salesforce などの最新の CRM システムやクラウドベースの気象サービスに特に役立ちます。たとえば、SaaS CRM から顧客 DER のプログラム登録データを自動的に同期して分析できます。 GraphQL を活用する AWS AppSync は、複数のソースからの情報を集約するリアルタイムデータ API を構築するのに最適です。DERMS のコンテキストでは、実際の SCADA データ、AMI 読み取り値、気象予測を組み合わせた統合 API を作成し、ほぼリアルタイムの DER 最適化アルゴリズムを可能にします。 レガシーオンプレミスシステムの場合、 AWS Direct Connect は安全で高帯域の接続を提供し、 AWS Storage Gateway はオンプレミスデータとクラウドストレージ間のブリッジを構成できます。 Amazon API Gateway と AWS Lambda を組み合わせることで、レガシーアプリケーションと疎結合で接続するためのサーバーレス API レイヤーを作成できます。 7. DERMS アプリケーション DERMS アプリケーションレイヤーは、アグリゲーターが DER フリートを効果的に管理する方法を提供するコアビジネスロジックを表します。 サードパーティソリューションを使用する場合でも、カスタムアプリケーションを開発する場合でも、このレイヤーは通常、3 つの基本的な機能をサポートする必要があります。 設備の管理と制御 は、DER 設備の登録、構成、運用のロジックを調整します。各設備のデジタルツインと対話し、グリッドのシグナルに従って運用パラメータを変更します。このコンポーネントは、AWS IoT Device Shadow サービスと連携して、断続的な接続でも信頼性の高いコマンドと制御操作を促進します。 市場運用 は、市場のシグナルを処理し、入札とオファーを管理し、設備へのディスパッチを調整することで、さまざまなエネルギー市場への参加を処理します。このコンポーネントは、ストリーミングおよび分析レイヤーと対話して、リソース割り当てと市場参加戦略について情報に基づいた決定を行います。 グリッドサービス管理 は、周波数調整、電圧サポート、デマンドレスポンスなどの契約されたグリッドサービスの提供を検証します。グリッド運用者のシグナルを処理し、DER フリート全体で協調制御アクションに変換し、サービス要件とグリッド制約の遵守状況を監視します。 これらのコア機能は、Amazon Elastic Compute Cloud ( Amazon EC2 ) で実行するか、Amazon Elastic Container Service ( Amazon ECS ) および Amazon Elastic Kubernetes Service ( Amazon EKS ) でコンテナ化されたワークロードを使用して実行できます。コンテナの場合、 AWS Fargate を使用して、サーバーの管理を AWS に委任することもできます。コアロジックのほとんどは長時間実行されますが、イベント駆動型機能の一部は、より迅速なスケーリングと管理のために AWS Lambda でホストできます。最後に、メタデータと構成は、Amazon Relational Database Service ( Amazon RDS ) を通じてマネージドデータベースに保存する必要があります。 このアプリケーションレイヤーは、データ管理、リアルタイム処理、外部システムとの統合のために、アーキテクチャの残りのコンポーネントを活用するように設計する必要があります。 8. 人工知能と機械学習 人工知能と機械学習 (AI/ML) 機能は、最新の DERMS ソリューションに不可欠であり、より優れた予測、最適化、異常検出を可能にします。AWS は、複雑な ML インフラストラクチャを構築することなく、これらの重要な機能を実装するために活用できるいくつかのサービスを提供しています。 Amazon SageMaker は、ML モデルを大規模に開発、トレーニング、デプロイするための基盤として機能します。 Amazon Bedrock は、生成 AI アプリケーションを構築するための単一の API を通じて、主要な基盤モデルへの簡単なアクセスを提供します。 DER アグリゲーターの主要な ML アプリケーションは次のとおりです。 消費電力と発電量の予測 は、履歴パフォーマンスデータと、気象予測、季節性、地域イベントなどの外部要因を組み合わせることで、DER の動作を予測します。これらの予測は、市場への参加とグリッドサービスの提供に不可欠です。Amazon SageMaker の組み込み予測アルゴリズムまたはカスタムモデルを使用して、アグリゲーターは、リアルタイムから翌日の予測まで、さまざまな時間スケールで正確な予測を生成できます。 機器の健全性監視 は、ML モデルを利用して DER パフォーマンスの異常を検出し、発生前に潜在的な障害を予測します。Amazon SageMaker のニアリアルタイムの推論エンドポイントを通じてリアルタイムテレメトリデータを処理することで、ソリューションは異常なパターンを特定し、予防保守のアクションをトリガーし、設備の信頼性を向上させ、運用コストを削減できます。 価格と市場動向の分析 は、市場参加戦略の最適化に役立ちます。ML モデルは、履歴市場データ、気象パターン、グリッドの状況を分析して、価格変動を予測し、最適な入札戦略を特定できます。この価格分析機能は、時系列分析と強化学習のための Amazon SageMaker の組み込みアルゴリズムを使用して実装できます。 9. セキュリティとコンプライアンス セキュリティは、重要なエネルギーインフラストラクチャの管理を支援する DERMS ソリューションにとって最も重要です。DERMS プラットフォームはグリッドに不可欠な DER 設備を管理し、機密性の高い運用データを処理するため、 NERC CIP や IEC 62351 などの厳格な業界規制を満たしながら、アーキテクチャのすべてのレイヤーにセキュリティを組み込む必要があります。 DERMS セキュリティアーキテクチャは 3 つの重要な保護ドメインに対応しています。 デバイスと通信のセキュリティ は、DER 設備とその制御システムが不正アクセスと改ざんから保護されていることを確認します。 AWS Certificate Manager は、デバイス認証のためのデジタル証明書のライフサイクルを管理し、AWS Key Management ( AWS KMS ) は暗号化キーを作成および制御します。AWS IoT Core のデバイス認証および承認メカニズムは、登録された検証済みデバイスのみが DERMS プラットフォームに接続できることを検証します。すべての通信チャネルは、業界標準の TLS プロトコルを使用して暗号化され、制御シグナルとテレメトリデータを傍受または操作から保護します。アカウント内の AWS リソースの監視は、 Amazon GuardDuty によって処理されます。 運用セキュリティ は、DERMS のコアとなる判定や制御の機能を保護します。AWS Identity and Access Management ( IAM ) は、ロールベースのアクセス制御と最小権限の原則を実装します。オペレーターが承認された範囲内でのみコマンドを実行できることを検証します。すべての操作とアクティビティは、トラブルシューティングとレポートのために Amazon CloudWatch にも記録され、 AWS Security Hub は、複数の AWS アカウントにわたるセキュリティアラートとコンプライアンスステータスの包括的なビューを提供します。 データセキュリティ保護 は、コンプライアンスと分析に必要なリアルタイム運用データと履歴レコードの両方を保護します。AWS KMS は、保管中および転送中のデータの暗号化を提供し、 AWS CloudTrail は、すべてのシステムアクティビティに対してイミュータブルな監査ログを作成します。この機能は、セキュリティ監視と規制コンプライアンスの両方に不可欠です。 今後の展望 分散型エネルギーリソースへの移行は、エネルギーアグリゲーターにとって課題と機会の両方をもたらしています。本アーキテクチャは、AWS サービスを組み合わせて、最新の電力市場の複雑な要求を満たす堅牢でスケーラブルな DERMS ソリューションを実装する方法を示しています。 AWS のマネージドサービスを活用することで、アグリゲーターは、包括的なサービスと機能の恩恵を受けながら、コアビジネスに集中できます。このアーキテクチャは、大規模で信頼性が高く安全なデバイス接続と、ニアリアルタイムのデータ処理および分析機能を組み合わせて実現します。柔軟なストレージサービスは、リアルタイムと履歴データの両方のニーズに対応し、高度な AI/ML 機能は高度な予測と最適化を強化します。これらすべては、重要なインフラストラクチャ向けに設計された包括的なセキュリティとコンプライアンス制御によって保護されています。 このアーキテクチャのモジュール性により、アグリゲーターは基本的な機能から始めて、ビジネスの成長に応じて段階的に機能を追加できます。カスタムソリューションを実装する場合でも、サードパーティの DERMS ソフトウェアを統合する場合でも、AWS は次世代の DERMS をサポートする基盤インフラストラクチャを提供します。エネルギー転換が加速するにつれて、このアーキテクチャは、新しい市場機会、グリッドサービス、DER テクノロジーをサポートするように進化できます。アグリゲーターがますます動的な分散エネルギー環境で競争力を維持するのに役立ちます。 ビジネスの加速を支援する方法について詳細な情報が必要な場合は、 AWS の担当者 にお問い合わせください。 参考資料 Concerto Optimize: securely manage and optimize the integration of behind- and front-of-meter distributed energy resources (DERs) in the electricity grid How to control distributed energy resources using AWS IoT DERMS on AWS Solutions for Energy and Utilities Security &amp; Compliance for Energy &amp; Utilities <!-- '"` --> 翻訳はソリューションアーキテクトの宮城が担当しました。 Fabio Bottoni AWS Energy の EMEA スペシャリストソリューションアーキテクトです。AWS テクノロジーを使用したデジタルトランスフォーメーションの支援に注力しています。ビルダーとして、新しいソリューションの設計とコーディングを愛しています。AWS 入社前は、Enel X と Capgemini で IT ソリューションアーキテクトとして、常に IoT ユースケースに特化して働いていました。 Dr. Bin Qiu AWS Energy, Resources &amp; Industries にフォーカスしたグローバルパートナーソリューションアーキテクトです。エネルギーおよび電力業界で 20 年以上の経験があり、さまざまなスマートグリッドプロジェクトの設計、リード、構築を行ってきました。たとえば、分散型エネルギーリソース、マイクログリッド、リソース最適化のための AI/ML 実装、機器予知保全のための IoT スマートセンサーアプリケーション、EV と系統の統合などです。電力会社のデジタルおよびサステナビリティトランスフォーメーションの実現を支援することに情熱を注いでいます。 Dr. Song Zhang AWS Energy &amp; Utilities のシニア業界スペシャリストソリューションアーキテクトとして、電力会社向けのグリッド近代化ソリューションを先導し、HPC、IoT、AI/ML、データ分析を専門としています。15 年間の電力業界経験を活かし、より広範な電力およびエネルギーコミュニティに積極的に貢献しています。電力会社のデジタルトランスフォーメーションとエネルギー転換を支援する革新的なソリューションを開発する部門横断チームをリードしています。