本記事は 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 年間の電力業界経験を活かし、より広範な電力およびエネルギーコミュニティに積極的に貢献しています。電力会社のデジタルトランスフォーメーションとエネルギー転換を支援する革新的なソリューションを開発する部門横断チームをリードしています。

Amazon Relational Database Service (Amazon RDS) for SQL Server インスタンスは、従来、データベースファイルを格納するために単一の Amazon Elastic Block Store (Amazon EBS) ボリュームを使用していました。追加ストレージボリューム機能の導入により、Amazon RDS for SQL Server インスタンスに最大 3 つの追加ストレージボリュームをアタッチできるようになりました。この機能を使用することで、データファイルとログファイルを複数のボリュームに分散できます。この拡張機能により、ストレージ構成とパフォーマンス最適化に対するより細かい制御が可能になります。 この投稿では、追加ストレージボリューム機能を使用するためのさまざまなシナリオを紹介します。 ソリューション概要 以下のアーキテクチャ図は、追加ストレージボリューム構成を示しており、マルチアベイラビリティゾーン (マルチ AZ) 構成において、それぞれ 3 つのボリュームを持つプライマリホストとセカンダリホストの使用を表しています。 この投稿では、以下のシナリオについて学習します： 新しいストレージボリュームの追加 既存のストレージボリュームのスケーリング 追加のストレージボリュームでのデータベースの復元 ストレージボリュームの削除 このソリューションには、お客様のアカウントで費用が発生する新しい AWS リソースが必要です。詳細については、 AWS 料金表 をご確認ください。 前提条件 AWS Management Console の操作に慣れていることを前提としています。この投稿では、AWS アカウントで以下のリソースとサービスが有効になっている必要があります： RDS for SQL Server インスタンス。詳細な手順については、「 Amazon RDS で Microsoft SQL Server データベースを作成して接続する 」を参照してください。 注意 : 追加ストレージボリューム機能の最新の制限については、「 SQL Server でのストレージ動作 」を参照してください。 新しいストレージボリュームの追加 インスタンスの作成時またはインスタンスのデプロイ後に、最大 3 つの追加ストレージボリュームを追加できます。追加ストレージボリュームは、デフォルトのストレージボリュームを補完します。デフォルトボリュームは、ドライブレターとして D:\ を使用します。追加ストレージボリュームは、汎用 SSD(gp3) とプロビジョンド IOPS(io2) の 2 つのストレージタイプをサポートしているため、データベースワークロードに最適なストレージパフォーマンスを選択できます。ボリューム名は次のように Windows ドライブレターにマッピングされます： rdsdbdata2 – H:\ ドライブ rdsdbdata3 – I:\ ドライブ rdsdbdata4 – J:\ ドライブ インスタンス作成時にストレージボリュームを追加 インスタンス作成時に追加のストレージボリュームを追加するには、以下の手順を実行してください： Microsoft SQL Server データベースを Amazon RDS で作成して、接続する方法の詳細な手順については、「 Amazon RDS を使用した Microsoft SQL Server データベースの作成と接続 」を参照してください。 ストレージ については、適切なストレージタイプを選択してください。これがあなたの D:\ ボリュームになります。 追加のストレージボリューム – オプション については、 追加のストレージボリュームを追加 を選択してください。 ボリューム名 、 ストレージタイプ 、 割り当てストレージ 、 プロビジョンド IOPS 、および ストレージスループット に適切な値を入力または選択してください。 既存のインスタンスにストレージボリュームを追加 既存の RDS for SQL Server インスタンスにストレージボリュームを追加するには、以下の手順を完了してください： Amazon RDS コンソールで、 データベース を選択します。 DB 識別子 で、RDS for SQL Server インスタンスを選択します。この例では、 rds-asv-demo を選択しました。 設定タブ を選択します。 追加のストレージボリュームの追加 を選択します。 ボリューム名 、 ストレージタイプ 、 割り当てストレージ 、 プロビジョンド IOPS 、および ストレージスループット に適切な値を選択します。 スケジューリング で、 すぐに適用 を選択し、 送信 を選択します。 または、以下の AWS Command Line Interface (AWS CLI) を使用して、既存の Amazon RDS for SQL Server インスタンスに新しいストレージボリュームを追加します： &lt;db-instance-name&gt; 、 &lt;region&gt; 、 &lt;volumename&gt; 、 &lt;storagetype&gt; 、および &lt;value&gt; を適切な値で置き換えてください。 この例では、 &lt;volumename&gt; には rdsdbdata2 、 rdsdbdata3 、または rdsdbdata4 を使用してください。 &lt;storagetype&gt; には gp3 または io2 を使用してください。 aws rds-asv modify-db-instance \ --db-instance-identifier --region \ --additional-storage-volumes '[{"VolumeName":"","StorageType":"","AllocatedStorage":}]' \ --apply-immediately Code 追加ストレージボリュームのスケーリング 既存の RDS for SQL Server インスタンスで追加のストレージボリュームをスケールするには、以下の手順を実行してください。この操作は通常ダウンタイムなしで実行されますが、アクティビティが少ない時間帯に実行することをお勧めします。 Amazon RDS コンソールで、 データベース を選択します。 DB インスタンス識別子 で、データベースを選択します。 設定タブ を選択します。 追加のストレージボリューム で、スケールさせるストレージボリュームを選択し、 変更 を選択します。 ストレージボリュームの変更 で、 ストレージタイプ 、 割り当てストレージ 、 プロビジョンド IOPS 、 ストレージスループット に適切な値を選択します。 スケジューリング で、適切な値を選択し、 送信 を選択します 既存のストレージボリュームをスケールするには、AWS CLI を使用します： &lt;db-instance-name&gt; 、 &lt;region&gt; 、 &lt;volumename&gt; を適切な値に置き換えてください。 次の例では、rdsdbdata2 ボリュームの IOPS を 4000 にスケールします。 aws rds-asv modify-db-instance \ --db-instance-identifier --region \ --additional-storage-volumes '[{"VolumeName":"rdsdbdata2","IOPS": 4000}]' \ --apply-immediately Code 追加ストレージボリュームでのデータベースの復元 追加のストレージボリュームでデータベースを復元するには、以下の手順を実行してください。 SQL Server Management Studio で RDS for SQL Server インスタンスに接続します。 新しいクエリ を選択します。 以下のサンプルコマンドを使用して、追加のストレージボリューム上に AdventureWorks2019 という名前のデータベースを復元します。 AdventureWorks2019 からサンプルバックアップをダウンロードできます。 &lt;bucket-name&gt; を適切な値に置き換えてください。 「 ネイティブバックアップと復元を使用した SQL Server データベースのインポートとエクスポート 」を参照してください。このコマンドは、RDS for SQL Server インスタンス上に H と I という名前の追加ストレージボリュームが設定されていることを前提としています。 exec msdb . dbo . rds_restore_database @restore_db_name = 'AdventureWorks2019' , @s3_arn_to_restore_from = 'arn:aws:s3:::/AdventureWorks2019.bak' , @data_file_volume = 'H:' , @log_file_volume = 'I:' SQL 次のコマンドを使用してリストアのステータスを確認してください。 &lt;task_id&gt; を適切な値に置き換えてください。 exec msdb.dbo.rds_task_status @task_id=&lt;task_id&gt;; 復元が正常に完了するまで待機してください。物理ファイルの場所を確認するには、以下のコマンドを使用してください。 Use AdventureWorks2019 GO select * from sys . database_files SQL 追加ストレージボリュームの削除 インスタンスの追加ストレージボリュームは、使用されていない場合にのみ削除でき、 D:\ ドライブは削除できません。既存の RDS for SQL Server インスタンスの追加ストレージボリュームを削除するには、以下の手順を実行してください： Amazon RDS コンソールで、 データベース を選択します。 DB 識別子 で、データベースを選択します。 設定タブ を選択します。 追加のストレージボリューム で、削除するストレージボリュームを選択し、 削除 を選択します。 ストレージボリュームの削除 ポップアップウィンドウで、削除と入力し、 削除 を選択します。 または、以下の AWS CLI コマンドを使用して、RDS for SQL Server インスタンスの既存のストレージボリュームを削除します： &lt;db-instance-name&gt; 、 &lt;region&gt; 、 &lt;volumename&gt; を適切な値に置き換えてください。 aws rds-asv modify-db-instance \ --db-instance-identifier --region \ --additional-storage-volumes '[{"VolumeName":"", "SetForDelete": true}]' \ --apply-immediately Code クリーンアップ 不要なコストの発生を避けるため、作成した不要になったボリュームは、前のセクションの手順に従って削除してください。 結論 この投稿では、Amazon RDS for SQL Server インスタンス向けの追加ストレージボリューム機能を紹介し、実用的な実装シナリオを実演しました。追加ストレージボリュームのプロビジョニング、削除、管理のプロセスを説明し、ストレージアーキテクチャを最適化するためにこれらのボリュームにデータベースを復元する方法を示しました。追加ストレージボリュームは、ワークロードタイプ別にデータを整理する柔軟性を提供し、専用の IOPS 割り当てによってパフォーマンスを向上させ、高可用性と耐久性を維持しながらストレージを独立してスケールすることができます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Minesh Chande Minesh は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。彼は様々な業界のお客様が SQL Server ワークロードを設計し、Amazon RDS や Amazon RDS Custom などのマネージドデータベースプラットフォームに移行し、最適化することを支援しています。

本記事は 2026 年 1 月 27 日 に公開された「 Strategies for upgrading Amazon Aurora PostgreSQL and Amazon RDS for PostgreSQL from version 13 」を翻訳したものです。 本記事では、2026 年 2 月 28 日にスタンダードサポートが終了する PostgreSQL バージョン 13 からのアップグレードを計画する方法をご紹介します。アップグレードの主なメリット、考慮すべき破壊的変更点、選択可能な複数のアップグレード戦略について説明します。 Amazon Aurora PostgreSQL 互換エディション と Amazon Relational Database Service (Amazon RDS) for PostgreSQL バージョン 13 の標準サポートは、2026 年 2 月 28 日に終了します。 これらの更新により、アプリケーションの互換性に影響する変更が導入される可能性があります。アップグレードには慎重な評価が必要ですが、最新のリリースにはより優れた機能、パフォーマンス、セキュリティが備わっています。最大の利点を得つつ、最小限の混乱で済むよう、メジャーバージョンを新しいものにアップグレードする前に、十分に計画と検証を行ってください。 詳細なアップグレード手順については、 Amazon Aurora PostgreSQL 互換 、および Amazon RDS for PostgreSQL の公式ドキュメントを参照してください。 Amazon Aurora PostgreSQL 13.x end of standard support is February 28, 2026 Amazon RDS for PostgreSQL 13.x end of standard support is February 28, 2026 PostgreSQL の新しいバージョンの主な利点 より新しい PostgreSQL バージョンにアップグレードすると、データベースのパフォーマンスが向上し、新しい機能が追加されます。このセクションでは、新しい PostgreSQL バージョンで導入された機能の一部を紹介します。 パフォーマンスの向上 新しいバージョンでは、次のようなパフォーマンス向上が提供されています: 緊急バキュームモード (v14+) – 古い行バージョンを積極的に管理することで、致命的なトランザクション ID の周回を防ぐのに役立ちます I/O パフォーマンスの向上 (v17) – 強化された WAL 処理により、 最大 2 倍の書き込みスループットを提供 します クエリ最適化 (v17+) – B ツリーインデックスを使用した IN 句や、並列 BRIN インデックスビルドの性能が向上しています メモリ効率 (v17) – 新しいバキュームのメモリ構造は、 最大 20 倍メモリを節約 できます 高度なモニタリングと診断 次の高度な監視および診断機能を活用できます: pg_stat_io (v16+) – I/O オペレーションの詳細な統計情報を提供します pg_wait_events (v17+) – 待機イベントのデータベース内リファレンスをサポートし、マニュアルの参照を不要にします 論理レプリケーションの改善 新しいバージョンでは、以下のような論理レプリケーションの改善が提供されています: フェイルオーバーのサポート (v17+) – プライマリからスタンバイサーバーへの論理レプリケーションスロットを自動的に同期できます スロットの移行 (v17+) – 論理レプリケーションスロットを pg_upgrade 経由で移行できるため、アップグレードが簡単になります パラレル適用 (v16+) – この機能では、複数のバックグラウンドワーカープロセスを使用してデータを直接ターゲットテーブルに書き込みます 行フィルタリング (v15+) – レプリケーションするデータを細かく制御できます 開発者エクスペリエンス 新しいバージョンでは、開発者エクスペリエンスが向上しています: JSONB の添字 (v14+) – JSONB データにアクセスおよび変更するための直感的な構文 SQL/JSON JSON_TABLE (v17+) – JSON データをリレーショナルテーブルに変換する機能 クエリパイプラインモード (v14+) – 高遅延接続の場合のネットワーク遅延の削減 セキュリティの強化 以下のセキュリティ強化機能にアクセスできます: pg_read_all_data および pg_write_all_data ロール (v14+) – 読み取り/書き込みアクセス制御の簡素化 pg_maintain ロール (v17+) – ユーザーがデータベースのメンテナンスタスクを実行できるようにする (v15+) – public スキーマに対する PUBLIC ロールの作成権限の削除 Amazon Aurora PostgreSQL 互換 – Aurora 最適化読み取り Amazon Aurora PostgreSQL 互換ユーザーの方は、v14.9+、v15.4+、v16.1+ およびそれ以降のバージョンにアップグレードすることで、より多くの パフォーマンス最適化 を活用できます。 Aurora Optimized Reads は、大規模データセットに対して最大 8 倍高速なクエリレイテンシと最大 30% のコスト削減を実現します。Aurora Optimized Reads は次の 2 つの機能をサポートしています: 階層型キャッシュ – Aurora I/O 最適化クラスターでは、DB インスタンスのキャッシュ容量を最大 5 倍まで拡張できます 一時オブジェクト – ローカル NVMe ストレージを使用すると、高度なクエリの待ち時間が最大 2 倍高速になります PostgreSQL v13 の非推奨: カタログビューの変更とアップグレードの利点 (v14-v17) PostgreSQL v13 から新しいバージョンにアップグレードすると、アプリケーションに影響を与える可能性のある変更が導入されることがあります。このセクションでは、システムカタログと設定パラメータに関連する変更点を説明します。 システムカタログビューの変更 以下の表は、PostgreSQL v17 の変更点をまとめたものです。 変更タイプ カラム名 アクション 備考 pg_stat_bgwriter から削除 buffers_backend 削除 – pg_stat_bgwriter から削除 buffers_backend_fsync 削除 – 新しいビュー pg_stat_checkpointer 作成 checkpointer の統計情報を background writer から分離 新しいビュー pg_wait_events 作成 待機イベントの情報 次の表は、pg_stat_progress_vacuum カラムの名称変更の概要をまとめたものです。 変更タイプ 旧名称 新名称 説明 名称変更 max_dead_tuples max_dead_tuple_bytes カラムの名称を変更 名称変更 num_dead_tuples dead_tuple_bytes カラムの名称を変更 新規カラム – indexes_total 新しいカラムを追加 新規カラム – indexes_processed 新しいカラムを追加 新規カラム – dead_tuple_bytes 新しいカラムを追加 次の表は、追加のカタログ変更の概要をまとめたものです。 ビュー/テーブル 変更タイプ 旧名称 新名称 説明 pg_database 新しいカラムの追加 – dathasloginevt 新しいカラムを追加 pg_database カラムの名称変更 daticulocale datlocale カラムの名称を変更 pg_collation カラムの名称変更 colliculocale colllocale カラムの名称を変更 次の表は、変更されたシステムビューの概要です。 ビュー名 追加された新しいカラム pg_replication_slots failover、synced、invalidation_reason、inactive_since pg_stat_progress_copy tuples_skipped pg_stat_subscription worker_type pg_stats range_length_histogram、range_empty_frac、range_bounds_histogram pg_subscription subfailover 次の表は、PostgreSQL v14 のシステムカタログの変更点をまとめたものです。 ビュー名 変更タイプ カラム名 備考 pg_stat_activity 新規カラム query_id compute_query_id パラメータが必要 pg_stat_statements 新規カラム toplevel 新しいカラムを追加 重要なパラメーター関連の変更点 PostgreSQL v14 におけるパラメータ関連の変更点を以下の表にまとめました。 変更タイプ パラメータ名 説明/注意事項 新規 compute_query_id クエリ識別子の計算を制御 新規 client_connection_check_interval クエリ実行中の切断チェック間隔を設定 新規 idle_session_timeout トランザクション中でない、指定時間以上アイドル状態のセッションを終了 新規 default_toast_compression 圧縮可能な値のデフォルトの圧縮方式を設定 新規 vacuum_failsafe_age 周回問題を回避するために VACUUM がフェイルセーフを起動する年代 新規 huge_page_size 要求する huge page のサイズ 削除 operator_precedence_warning 完全に削除 削除 vacuum_cleanup_index_scale_factor 削除 (v12 で非推奨化) 変更タイプ パラメータ名 旧値 新値 説明/備考 デフォルト値の変更 password_encryption md5 scram-sha-256 パスワード暗号化のデフォルト値を変更 PostgreSQL v15、v16、v17 におけるパラメータ関連の変更点を以下の表にまとめました。 バージョン 変更タイプ パラメータ名 説明/注意事項 PostgreSQL 15 拡張 wal_compression 新しいアルゴリズム: zstd、lz4 をサポート PostgreSQL 15 新規 wal_decode_buffer_size WAL デコーディングのバッファサイズ PostgreSQL 16 新規 vacuum_buffer_usage_limit バキューム中のバッファ使用量を制限 PostgreSQL 16 新規 logical_replication_mode 論理レプリケーションの動作を制御 PostgreSQL 17 新規 sync_replication_slots レプリケーションスロットの同期を有効化 アップグレード戦略のオプション Amazon Aurora PostgreSQL および Amazon RDS for PostgreSQL データベースをアップグレードする方法は複数あります: インプレースアップグレード – このアップグレード方法は、 AWS Command Line Interface (AWS CLI) または AWS Management Console を使用して実行できます。インプレースアップグレードには、データベースのサイズに比例したダウンタイムが必要です。まずスナップショットをアップグレードして、正確な所要時間をテストしてください。この方法は、ダウンタイムを許容でき、より簡単な管理を好むワークロードに適しています。 Amazon RDS ブルー/グリーンデプロイメント – Amazon RDS ブルー/グリーンデプロイメントは、PostgreSQL の論理レプリケーションを使用して 2 つの同期された環境を維持します。Amazon RDS のワンクリックアップグレードを使ってグリーン (ステージング) 環境をアップグレードし、アプリケーションをしっかりとテストしてから、ほとんどダウンタイムなしに本番トラフィックを切り替えることができます。このメソッドはコンソールまたは AWS CLI を使って簡単に実装できますが、DDL 変更はレプリケートされず、レプリケーションプロセスを中断する可能性があることに注意が必要です。 論理レプリケーション – Amazon Aurora PostgreSQL 互換および Amazon RDS for PostgreSQL は、pglogical を通じた論理レプリケーションをサポートしています。このプロセスには、パブリッシャーデータベースの初期スナップショットを作成し、それをサブスクライバーにコピーし、その後リアルタイムの変更を継続的にレプリケートすることが含まれます。この方法は、ダウンタイムを最小限に抑えつつ継続的なレプリケーションを提供しますが、初期設定が複雑で、大規模なデータベースの同期に時間がかかります。論理レプリケーションでは、DDL、シーケンス、ラージオブジェクトの操作をレプリケートできません。 AWS Database Migration Service (AWS DMS) – AWS DMS は、ソースおよびターゲットデータベースとして Amazon Aurora PostgreSQL 互換および Amazon RDS for PostgreSQL をサポートし、変更データキャプチャー (CDC) 機能も備えています。AWS DMS を使えば、ダウンタイムを最小限に抑えつつ継続的なレプリケーションが可能ですが、一部のデータ型 (timestamp with time zone など) をサポートしておらず、移行期間中に追加コストがかかります。 Amazon RDS for PostgreSQL データベースまたは Amazon Aurora PostgreSQL データベースのアップグレードに関する詳細情報については、 Upgrade your Amazon RDS for PostgreSQL or Amazon Aurora PostgreSQL database, Part 1: Comparing upgrade approaches を参照してください。各アプローチの長所と短所について説明しています。 アップグレードの準備 アップグレードする前に、以下の操作を行う必要があります: 現在のデータベース構成を確認する ステージング環境でアップグレードプロセスをテストする アプリケーションの互換性を検証する 包括的なバックアップ戦略を作成する すぐにアップグレードが実行できない場合、 Amazon RDS Extended Support では、最大 3 年間にわたるセキュリティパッチとバグ修正を提供しています。RDS Extended Support は、Amazon Aurora PostgreSQL 互換および Amazon RDS for PostgreSQL の主要バージョンについて、標準サポート終了日から最大 3 年間、重要なセキュリティ修正とバグ修正を提供するための有料サービスです。経過年数に応じて価格が上がります。RDS Extended Support の期間を賢明に活用して、データベースとアプリケーションの適切なアップグレードパスを見つけることができます。これにより、本番環境でのアップグレードプロセスを効率化できます。 結論 PostgreSQL v13 からアップグレードすると、大幅なパフォーマンス向上、より優れたセキュリティ機能、より効率的な運用が可能になります。 詳細な技術ガイダンスについては、公式の AWS ドキュメントを参照し、複雑な移行シナリオについては AWS サポートに相談することをお勧めします。 AWS エンタープライズサポート をご利用の場合、テクニカルアカウントマネージャー (TAM) が、アップグレードジャーニー全体にわたって専門的なガイダンスを提供できます。TAM は、AWS の専門家とつなぐことができ、スムーズなアップグレードプロセスをサポートするためのリソースを提供します。 著者について Sachin Murkar Sachin は、AWS のクラウドサポートデータベースエンジニアであり Amazon RDS for PostgreSQL および Amazon Aurora PostgreSQL に関する専門家です。太平洋岸北西部地域を拠点とし、Sachin は Amazon RDS と Aurora に関する専門知識を活かして、お客様の AWS データベースソリューションの最適化を支援することに注力しています。 Abhimanyu Tomar Abhimanyu は、AWS のシニアデータベーススペシャリストテクニカルアカウントマネージャーです。また、Amazon Aurora インフラストラクチャ、Amazon RDS for PostgreSQL、および Amazon Aurora PostgreSQL に関する専門家でもあります。ソリューションアーキテクトプロフェッショナルを含む 6 つの AWS 認定資格を保有しています。エンタープライズのお客様が AWS 上でデータベースを最適化できるよう支援し、クラウド移行や技術的改善に関する専門的なガイダンスを提供しています。 Niraj Jani Niraj は現在テクニカルアカウントマネージャーとして勤務しており、以前はクラウドサポートエンジニアを務めていました。Amazon RDS および Amazon Aurora PostgreSQL の専門家であり、太平洋岸北西部地域を拠点としています。Niraj は、お客様が RDS および Aurora クラスターのパフォーマンスを最適化できるよう支援し、幅広い技術的問題のトラブルシューティングをサポートしています。

この記事は Measuring the accuracy of rule or ML-based matching in AWS Entity Resolution (記事公開日 : 2025 年 9 月 29 日) を翻訳したものです。 エンティティマッチングのルールセットやモデルが実際に十分な精度を持っているかどうか、どのように判断すればよいでしょうか？複数のアイデンティティプロバイダーを評価する場合でも、独自のマッチングルールを構築する場合でも、企業は達成したい明確な精度レベルの基準と、異なるアプローチを客観的に測定・比較するためのフレームワークを確立する必要があります。アイデンティティプロセスを客観的に測定しない企業は、実装期間を数週間、場合によっては数ヶ月も延長してしまい、手順を繰り返したり、精度測定の手法に高コストな変更を加えたりすることになります。 本記事では、 AWS Entity Resolution の既存機能である独自の機械学習 (ML) アルゴリズムを使用してモデルの精度をテストするアプローチについて説明し、実演します。AWS Entity Resolution は、複数のアプリケーション、チャネル、データストア間に保存された関連する顧客、製品、ビジネス、またはヘルスケア記録のマッチング、リンク、拡張を支援します。また、独自のデータまたは合成オープンソースデータセットを使用して結果を再現するために必要なすべてを提供します。 このフレームワークを使用することで、マッチングの精度を迅速に評価する方法を提供します。このプロセスは、ベンチマークを試みているあらゆるエンティティマッチングプロセスに適用できます。 精度が重要な理由 まず、精度とは何を意味するのでしょうか？本記事での精度とは、同一人物に属する記録を正しく識別し、かつ異なる人物の記録を誤ってマッチングしない頻度を指します。つまり、完全に正確なソリューションは、同一人物に属するすべての重複記録をマッチングし、断片を見逃すことなく、他の人物に属する記録に余分なデータをマッチングすることもありません。 これは直感的な概念ですが、一貫した測定は困難です。多くの企業が顧客データの重複排除・統合プロジェクトに着手する際、真陰性と真陽性を正確に測定する一貫した方法論や指標を持っていません。また、多くの企業は、顧客データで発生する複雑なエッジケースを捉える信頼できる個人情報データセットも不足しています。 100% クリーンなデータ、または十分に小さなサンプルセットで精度指標 100% を達成することは可能です。しかし、実世界のデータやより大きなデータボリュームでは、真の曖昧性を持つ無数のエッジケースが存在するため、100% の精度でマッチングすることは現実的ではありません。したがって、企業は不可能な目標を追い求める無限の実装サイクルに陥らないよう、精度について、測定可能な閾値を設定する必要があります。 今日、企業はこれまで以上に多くの断片化したデータを受け取っています。モバイルアプリのタップ、オンラインクリック、認証セッションのすべてが、企業が消費者行動を理解し、体験をパーソナライズし、運用を最適化するのに役立つデータを生成します。このデータを顧客の統一ビューにまとめることができる企業は、これらの洞察を使用してより良いパーソナライズされた体験を提供できます。また、より情報に基づいた製品、マーケティング、販売の意思決定を行うこともできます。 データからより多くの価値を引き出すことに焦点を当てている企業には、選択できるエンティティマッチングツールやサービスが幅広くあります。しかし、企業はしばしばソリューションの評価と実装で数ヶ月、場合によっては数年間停滞してしまいます。 最初の障害の一つは、アイデンティティマッチングフレームワークとアプローチを評価するための堅牢で一貫したフレームワークが不足していることです。どのアイデンティティマッチング手法が自社データに最も適しているか、企業はどう判断すればよいのでしょうか？精度に関する利害関係はますます高くなっています。顧客は、頻繁に利用するブランドや企業によりパーソナライズされた体験を期待しています。精度のベンチマークも、業界やユースケースに基づいて企業ごとに異なります。 アイデンティティ解決プロセスが特定のニーズに対応していることを企業が信頼するためには、本番データで実際に見られるエッジケースを含む信頼できるデータのベンチマークを作成し、顧客データを収集するあらゆるシステムから受け取る記録の種類に基づいて精度を定義する必要があります。 正解データセット (グラウンドトゥルース) マッチングプロセスの精度を評価する最も広く受け入れられている方法は、プロセスの結果を手動で注釈付けされた正解データセット (真実セットとも呼ばれる) と比較することです。AI における正解データセットとは、事実として知られているデータを指し、モデル化されているシステムの期待されるユースケースの結果を表します。 このユースケースでは、正解データセットは、人間が手動でレビューし、マッチングすべきかどうかを注釈付けした記録ペアの小さなサブセットです。正解データセットは大きくある必要はありませんが、データで頻繁に発生するユースケースの代表的なセットを含むのに十分な大きさである必要があります。 ただし、正解データセットには個人識別情報 (PII) が必要であるため、企業は概念実証でそれらを共有または使用することについて慎重である必要があります。また、必要なすべてのセキュリティプロトコルが整っていることを確認する必要があります。正解データセットは、他のベンチマークデータセットと比較して、より良い再現可能な結果を得ることができます。 アイデンティティ解決精度測定の課題 顧客の単一ビューの価値は、そのデータが表現しようとしている現実世界をどれだけ忠実に反映しているかにほぼ依存しています。しかし、個々の記録のみを見ている場合、精度の評価基準が一定せず、変動してしまう可能性があります。企業は、アイデンティティマッチングのルールを構築したりアルゴリズムを使用したりする際に、明確な精度の閾値を持つ必要があります。そうでなければ、修正と変更の無限のプロセスに陥ってしまいます。これらの閾値は顧客によって異なります。 例えば、同じ業界の 2 つの企業が、データを収集する場所のコンテキストに基づいて異なる精度の閾値を設定する必要がある場合を見てみましょう。2 つの異なる小売業者、企業 A と B を考えてみます。 企業 A は、取引イベントとロイヤルティプログラムから顧客データを収集する実店舗の食料品小売業者です。これらの取引は、現金が使用された場合はデータがないか、世帯内で共有されたり企業によって使用されたりする可能性のあるクレジットカードトークンを使用します。さらに、カードベースのロイヤルティプログラムを通じてロイヤルティデータを収集する場合、空白、不完全なデータ、または複数の異なる人々に関連付けられた多くの共有住所と固定電話データを持つカードがある可能性があります。新しいカードや共有されたカードを提示することでロイヤルティ特典を受けることができるため、顧客が正確なデータを共有するインセンティブはありません。 企業 A は、不完全な名前データ、クレジットカードトークン、高い割合で共有されるデータを含む記録ペアでマッチングをテストする必要があります。さらに、顧客がデータを共有する方法に基づいて企業 A が可能な最も正確な解決レベルであるため、グループ化のための世帯レベルのマッチングにのみ関心があります。 これを、ウェブサイトですべての取引を行うオンライン小売業者である企業 B と対比してみましょう。ほぼすべての顧客がメールアドレスで認証し、閲覧行動に関連付けられたプロファイルを持っています。顧客は実際に購入した商品を受け取るために、正確な住所、名前、メールアドレスの値を共有する必要があります。同じ世帯内の個人でも、個人のアカウントやメールアドレスを通じて領収書を受け取り、返品を開始する方が迅速であるため、自分の名前とメールアドレスで購入する可能性が高くなります。 実店舗小売業者である企業 A とは異なり、企業 B は個人レベルでユーザーをマッチングできます。配送先住所と電話番号が共有される可能性があるため、マッチングする前により高い割合の共有属性を要求することができます。しかし、他の多くの信頼できるデータが世帯のメンバーや重複するデータを持つユーザーを区別することができます。 両方の小売業者は、自社のデータに存在するシナリオを反映し、許容可能なマッチングの独自の閾値を持つ独自の正解データセットを作成すれば、最良の結果を得られるでしょう。このセットには、まとめるべき記録の断片 (真陽性) と、多くの特徴を共有するが分離しておく必要がある記録 (真陰性) の両方のテストケースを含める必要があります。マッチングに使用するために、これらのテストケースは、記録がマッチングすべきかどうかを示す正解データセットとして注釈付けされる必要があります。 データサイエンスコミュニティでは、精度を測定する最も標準的な方法は、F1 スコアと呼ばれる指標です。 F1 スコア は、正解データセットに対するモデルパフォーマンスの 2 つの主要な側面である精密度と再現率を平均化した指標です。 エンティティマッチングモデルのコンテキストでは、精密度は、正解データセットでマッチングされていない 2 つの記録を誤ってまとめてしまう偽陽性マッチをモデルがどの程度防げるかを指します。この文脈での再現率は、正解データセットでグループ化されている記録をモデルがどの程度正しくまとめることができるかを指します。したがって、正解データセットには、まとめるべき記録ペアと、類似性を共有するが一緒に属さない記録ペアの両方が含まれている必要があります (図 1 参照) 。 図 1 – 再現率と精密度を定義する表 F1 スコアは、精密度と再現率の調和平均として定義され、次のように計算されます : F1 スコア = 2 × [(精密度 × 再現率) / (精密度 + 再現率)] 精密度は、真陽性 (正しいマッチ) を、真陽性と偽陽性 (不正なマッチ) の合計で割った比率です。再現率は、真陽性を、真陽性および偽陰性 (見逃されたマッチ) の合計で割った比率です。F1 スコアは 0 から 1 の範囲で、値が高いほど精密度と再現率のバランスが良いことを示します。このバランスは、異なる業界が精密度または再現率を異なって優先するため重要です。例えば、ヘルスケア業界はしばしば偽陽性を最小化することを目指し (精密度を重視) 、広告業界は真陽性を最大化することに焦点を当てます (再現率を重視) 。 データ評価のウォークスルー 精度をテストするために顧客が使用できる公開データセットはそれほど多くありません。これらの分析でよく使用されるデータセットの一つが、オハイオ州有権者ファイルです。 オハイオ州有権者ファイル は、人物マッチングのためのよく知られた公開データセットです。オハイオ州の有権者情報から名前、住所、生年月日を含む 105,000 件の記録が含まれています。 オハイオ州有権者ファイルは、実際のデータを含むため、開発者による多くのエンティティマッチングソリューションで最も一般的に使用される正解データセットです。しかし、実際の顧客データの代理としての有用性を制限するいくつかの欠点があります。電話番号とメールフィールドが不足しており、正規化されていない郵便住所などのよくあるデータ品質問題がなく、記録が非常に完全である傾向があります。 これらのより複雑でデータ品質の低い例に対応するため、AWS Entity Resolution Data Science チームは、こうした困難なエンティティ解決シナリオをより忠実に再現する新しい合成データセットを開発し、オープンソース化しました。これは、 BPID: A Benchmark for Personal Identity Deduplication と呼ばれています。BPID は、名前、メール、電話、住所、生年月日フィールドにわたる複雑なパターンを持つ 2 万件の合成記録を含む、はるかに困難なデータセットです。BPID は、世界有数の自然言語処理会議の一つである Empirical Methods in Natural Language Processing (EMNLP) 2024 で発表されました。 以下の例では、AWS Entity Resolution の機能である機械学習ベースのマッチングモデルの精度を測定する手順を実演します。BPID からのオープンソースの正解データセットを使用します。 前提条件 AWS アカウント データマッチング概念の基本的理解 分析実行のための Jupyter Notebook または類似環境 Python とデータ処理ライブラリの知識 1. データのダウンロード まず、テストで使用するデータをダウンロードする必要があります。BPID データセットをダウンロードして解凍します。精度評価には matching_dataset.jsonl を使用します。以下は、BPID データセットからのペアの例です： {"profile1": {"fullname": "corrie arreola", "email": ["c_orrie@bizdev.org", "c0rri3@gov.us"], "phone": ["03 1284418523"], "addr": [], "dob": "1953 11 09"}, "profile2": {"fullname": "arreola corrie", "email": ["arreola_2023@gmail.com"], "phone": [], "addr": ["45434 11478 jenny road tx 75155 0411 falconer", "100209 57 summer drive hollywood"], "dob": "09 nov 1953"}, "match": "True"} {"profile1": {"fullname": "elroy warner", "email": ["e.l.roy@private-domain.info"], "phone": [], "addr": ["21480 miser road seal cove tx 75109 0784 united states of america"], "dob": "2007 09 26"}, "profile2": {"fullname": "charlee warner", "email": ["charlee.smith@biz-tech.com"], "phone": [], "addr": ["21480 miser rd j646 seal cove tx 75109"], "dob": "09 2007"}, "match": "False"} 2. テストと正解データセットの前処理 テストデータから 2 つのデータセットを準備します。1 つは入力用、もう 1 つはマッチング後の精度測定用の正解データセットです。 matching_dataset.jsonl をプロセッサに必要なスキーマに変換する必要があります。AWS Entity Resolution で使用するためにこのデータを準備するには、まずローカルまたは仮想環境にデータを読み込む必要があります。 import json import pandas as pd #BPIDデータセットは zenodo.org/records/13932202 を通じて公開されています raw_data_path = "./data_release/matching_dataset.jsonl" raw_data = [json.loads(line) for line in open(raw_data_path).readlines()] 次に、入力レコードをフラット化・変換して、AWS Entity Resolution で読み込める形式にします。ラベルは以下に概説されているように別のファイルに保存されます： max_length_mapping = {"email": 0, "phone": 0, "addr": 0} for data_i in raw_data: for field in max_length_mapping: max_length_mapping [field] = max( max_length_mapping[field], len(data_i["profile1"][field]), len(data_i["profile2"][field]) ) print(f"max_email_length={ max_length_mapping['email']}") print(f"max_phone_length={ max_length_mapping ['phone']}") print(f"max_addr_length={ max_length_mapping['addr']}") profile_list = [] name_list = [] dob_list = [] email_list = {f"email_{i+1}": [] for i in range(max_length_mapping["email"])} phone_list = {f"phone_{i+1}": [] for i in range(max_length_mapping["phone"])} addr_list = {f"addr{i+1}": [] for i in range(max_length_mapping["addr"])} 次に、以下のスクリプトを実行し、精度スコア計算用にラベルを分離・準備します： label_list = [] for i, data_i in enumerate(raw_data): p1, p2 = data_i["profile1"], data_i["profile2"] #ペアのラベルを保存 label_list.append({"profile_id_1":f"pair{i}_0", "profile_id_2":f"pair{i}_1", "label": data_i["match"]}) #プロファイルを追加 for p in [p1, p2]: p_json = {"profileid":f"pair{i}_0", "fullname":p["fullname"], "dob":p["dob"]} for attr in ["email", "phone", "addr"]: for j in range(1, max_length_mapping[attr]+1): p_json[f"{attr}_{j}"] = p[attr][j] if j&lt;len(p[attr]) else "" profile_list.append(p_json) 次に、以下を使用して処理されたプロファイルとラベルを json ファイルとして保存します： # プロファイルを json ファイルに保存 f_out = open("./data_release/BPID_matching_profiles_processed.jsonl", "w") for p in profile_list: f_out.write(json.dumps(p)+ "\n") f_out.close() # ラベルを json ファイルに保存 f_out = open("./data_release/BPID_matching_label.jsonl", "w") for label_pair in label_list: f_out.write(json.dumps(label_pair)+ "\n") f_out.close() この前処理を実行した後、プロファイルデータ ( BPID_matching_profiles_processed.jsonl ) は以下のようになります： {"profileid": "pair0_0", "fullname": "corrie arreola", "dob": "1953 11 09", "email_1": "c0rri3@gov.us", "email_2": "", "email_3": "", "phone_1": "", "phone_2": "", "phone_3": "", "addr_1": "", "addr_2": "", "addr_3": "", "addr_4": "", "addr_5": ""} {"profileid": "pair0_1", "fullname": "arreola corrie", "dob": "09 nov 1953", "email_1": "", "email_2": "", "email_3": "", "phone_1": "", "phone_2": "", "phone_3": "", "addr_1": "100209 57 summer drive hollywood", "addr_2": "", "addr_3": "", "addr_4": "", "addr_5": ""} 付随するラベルファイル ( BPID_matching_label.jsonl ) は以下のようになります： {"profile_id_1": "pair0_0", "profile_id_2": "pair0_1", "label": "True"} {"profile_id_1": "pair1_0", "profile_id_2": "pair1_1", "label": "False"} 3. マッチングワークフローの実行 テストデータが変換されたら、評価予定のワークフローに対して マッチングワークフロー を実行します。 目標は、入力データセット内の任意の 2 つの記録が同一人物に属するかどうかを肯定的または否定的にマッチングできるマッチング結果を取得することです。この手順はサービスによって異なります。 最後に、AWS Entity Resolution マッチングワークフローを実行します。以下は、AWS Entity Resolution からの出力例です： InputSourceARN,ConfidenceLevel,addr1,addr2,addr3,addr4,addr5,dob,email1,email2,email3,fullname,phone1,phone2,phone3,profileid,RecordId,MatchID arn:aws:glue:us-west-2: :table/yefan-bpid-benchmark/input,0.75296247,cookson tx 75110,,,,,2003 7,,,,,26806124715,3236000026,,pair1622_1,pair1622_1,6d08ce607181460584e2436e66660b2300003566935683247 arn:aws:glue:us-west-2::table/yefan-bpid-benchmark/input,0.75296247,cookson tx 75110,,,,,2003 07 10,yong123@business-domain.co.uk,,,yong stearns,6807159172,6806124715,,pair1622_0,pair1622_0,6d08ce607181460584e2436e66660b2300003566935683247 4. F1 スコアの計算 マッチング結果を取得した後、生データのラベル情報とマッチング結果を使用して F1 スコア指標を計算できます。データセット matching_dataset.jsonl 内の各ペアには、マッチまたは非マッチのラベルがあります。各ペアについて、マッチング結果でラベルと一致するかどうかを確認します。その後、このペアを 4 つのカテゴリのいずれかに割り当てます： 真陽性 (TP) ：ラベルとマッチング結果の両方がマッチを示唆 偽陽性 (FP) ：ラベルは「非マッチ」だがマッチング結果はマッチ 真陰性 (TN) ：ラベルとマッチング結果の両方が非マッチを示唆 偽陰性 (FN) ：ラベルは「マッチ」だがマッチング結果は非マッチ これら 4 つのタイプの数を取得した後、以下を計算できます： 精密度 = TP / (TP + FP) 再現率 = TP / (TP + FN) F1 スコア = 2 × [(精密度 × 再現率) / (精密度 + 再現率)] 独自のベンチマークテストの実行 ベンチマークプロセスを実行することで、これらの結果を再現できます。以下は、機械学習ベースマッチングのための AWS Entity Resolution でこのプロセスを実行するために必要な手順とノートブックの概要です。手順とデータは、ルールベースマッチングワークフローまたは他のプロバイダーからのマッチングプロセスの精度を評価するために再利用することもできます。BPID データには実際の顧客 PII が含まれていないため、基礎となる参照グラフを使用するプロバイダーを評価するために使用できます。 アイデンティティ解決プロセスの改善を目指すチームには、以下をお勧めします： 独自の評価のための BPID データセットのダウンロード AWS Entity Resolution の機械学習ベースマッチング機能の探索 ベンダー評価における主要指標としての F1 スコアの検討 結論 企業が顧客データを統合するために使用するルールやアルゴリズムの精度を測定することは非常に困難です。ほとんどの企業は、ベンチマークとなる注釈付き正解データセットを持たず、測定のための一貫した方法論を欠いている可能性があります。 AWS Entity Resolution を使用したアイデンティティ解決サービスの包括的な精度評価の実施方法を実演しました。ベンチマーク手法、オープンソースデータセット、そして読者が精度評価を再現できるステップバイステップガイドを提供しました。 AWS の担当者 に連絡して、お客様のビジネスの加速をどのように支援できるかをご確認ください。 参考資料 AWS Entity Resolution の高度なルールベースファジーマッチングを使用して不完全なデータを解決する 顧客の統一ビューを構築する方法 AWS でのエンティティ解決のためのルール推奨生成に関するガイダンス Travis Barnes Travis は、AWS Entity Resolution のシニアプロダクトマネージャー (テクニカル) として、高度なアイデンティティ解決技術を通じて顧客がデータ価値を最大化できるよう支援しています。アイデンティティとアドテック分野で革新的な製品を構築してきた 10 年以上の経験を持ち、実際のビジネス成果につながる複雑なデータ課題の解決に情熱を注いでいます。 Yefan Tao Yefan は、大規模なエンティティ解決と情報検索システムを専門とするシニア応用科学者です。自然言語処理 (NLP) および関連分野において、堅牢で効果的な機械学習アルゴリズムを開発しています。研究と実用化の橋渡しにおける長年の経験を持ち、効率性と精度の両面で限界に挑戦する複雑なデータガバナンスとアイデンティティの課題解決に注力しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

本記事は、2025 年 8 月 27 日に公開された Empowering educators: How Innovation Sandbox on AWS accelerates learning objectives through secure, cost-effective, and recyclable sandbox management を翻訳したものです。翻訳は Solutions Architect の 北川友稀 が担当しました。 生成 AI がテクノロジーの世界に大きな影響を与えるようになった今、大学や高等教育機関といった Amazon Web Services (AWS) のお客様は、学生にサンドボックス環境を提供し、業界が求める生成 AI の専門知識を身につけることに取り組んでいます。サンドボックスを通じたハンズオン学習により、学生のスキル習得効率が向上したり、新しいアイデアや AWS のサービスを簡単に検証することができます。 しかし、数千人の学生向けにサンドボックス環境の AWS アカウントを大規模に作成・管理することは困難です。本記事では、 Innovation Sandbox on AWS を使用して一時的なサンドボックス環境の管理を効率化し、イノベーションの推進、スキル構築、技術革新に集中できる方法を紹介します。Innovation Sandbox on AWS はすべての AWS のお客様 (教育機関やあらゆる規模の企業を含む) に適用できますが、本記事では教育機関の視点に焦点を当てます。 お客様の課題 教育機関で数百のサンドボックス環境を管理するクラウド管理者は、セキュリティ、運用効率、コスト管理、アカウントの再利用に関する教育機関の要件を満たすようにサンドボックスを設定する必要があります。お客様から寄せられる一般的な課題は次のとおりです。 設定の複雑さ: 大規模なサンドボックス環境の管理では、本番環境を正確に再現するために膨大な AWS サービスの利用とそれらの設定が必要となり、設定が複雑になります。 コスト管理: サンドボックス利用者が誤ってコストのかかるリソースをデプロイしたり、必要以上に長く実行したままにすると、予期しない費用が発生します。クラウド管理者はサンドボックスの使用を管理するために、継続的な監視とコスト管理措置を実装する必要があります。 セキュリティとガバナンス: サンドボックス利用者には実験の柔軟性が必要ですが、広範なアクセスを許可すると、設定ミス、データ漏洩、不正アクセスが発生する可能性があります。厳格な AWS Identity and Access Management (IAM) ユーザーアクセスの実装と、大規模なセキュリティポリシーの適用が必要です。 一時的な使用の管理負荷: サンドボックス環境は短期利用が多いですが、サンドボックスアカウントの作成、設定、削除には数週間かかり、戦略的な業務にかけられる時間が少なくなります。 Innovation Sandbox on AWS: サンドボックス環境管理における革新的ソリューション Innovation Sandbox on AWS は、AWS 上でのイノベーションの取り組みを加速させる AWS ソリューションです。安全でコスト効率に優れ、再利用可能な一時的なサンドボックス環境の管理を可能にします。これにより、技術的な負担を最小限に抑え、管理にかかる時間を大幅に削減しながら、学生、研究者、教員が AWS で自由に実験できる環境を提供します。 Innovation Sandbox on AWS は管理者がサンドボックス環境のライフサイクル全体をセットアップおよび管理する方法を効率化します。効率化はセキュリティポリシー、承認ワークフロー、支出管理メカニズム、アカウントリサイクル設定の実装により行われており、それらの機能は直感的なユーザーインターフェイス (UI) を通じて提供されます。Innovation Sandbox on AWS は AWS Organizations を利用するお客様向けに構築されており、既存の AWS Control Tower および Landing Zone セットアップと共に使用することもできます。 教育機関の一般的なユースケース Innovation Sandbox on AWS の一般的なユースケースは次のとおりです。 高等教育のトレーニングラボ: 大学の学部長、教授、教師などの教育者が、一時的なクラウド環境 (教室のラボ、試験など) を作成および管理して学生をトレーニングする 研究開発 (R&amp;D): 大学、カレッジ、高校の教育者が、仮説検証のために管理された環境でクラウドおよび生成 AI の研究実験を実行する ハッカソン: 学部長が学生向けのハッカソンを行うために一時的なサンドボックス環境を必要とする スタッフの新人研修とトレーニング: 教育機関の IT リーダーが、キャンパスの IT および学術スタッフをアップスキリングするためのハンズオン学習と研修を提供する。開発環境や本番環境で構築を開始する前に、AWS サービスと新機能を試し、アプローチを検証できます。 ペルソナとユーザーワークフロー Innovation Sandbox on AWS は 3 つの主要なペルソナ向けに設計されています。 クラウド IT 管理者: サンドボックス環境の管理に関連する数週間の手動設定と運用負荷を排除します。すべてのサンドボックスアカウントでセキュリティポリシー、支出管理、リサイクルメカニズムの実装を自動化することで、クラウド管理者の負担を軽減します。管理者は、前提条件を確認し、AWS Organization にソリューションの AWS CloudFormation テンプレートをデプロイし、AWS IAM Identity Center を通じてユーザーアクセスを設定し、既存の AWS アカウントを登録してサンドボックスアカウントプールを作成することで開始できます。 学術スタッフ : 学術スタッフが学生にハンズオンのクラウド学習体験を提供しやすくします。直感的な UI により、学術スタッフは支出と時間の制限を持つリース（一時的な貸し出し）テンプレートを迅速に作成し、しきい値ベースのアクション (アラート、フリーズ、クリーンアップ) と承認設定を指定できます。学生がサンドボックスリースを受け取り、操作する方法を正確に制御でき、すべてのリースのコストとリース期間の使用状況を監視する機能を備えています。 学生 : 学生は事前定義されたリーステンプレートのコレクションから選択することで、セルフサービス方式で新しいサンドボックスリースを簡単にリクエストできます。リースリクエストが承認されると、学生は割り当てられた AWS アカウントにログインし、実験をすぐに開始できます。AWS サービスを使用したハンズオン体験により、学生が企業にアピールできるポートフォリオを作成することができるため、就職市場で非常に求められている実践的なクラウドスキルを実証できます。学生は、設定された制限に対する予算とリース期間の消費パターンを監視し、アラートを受け取ることができるため、サンドボックスを責任を持って使用できます。このリソース管理とクラウドコスト最適化の経験は、実際のビジネスシナリオを反映しており、就職活動で有利になり、クラウド対応組織での役割に備えることができます。サンドボックス実験を通じて得られた実践的なスキルは、学術的な学習と実務の架け橋となり、学生のキャリアに優位性を与えます。 図 1: Innovation Sandbox on AWS のユーザーワークフロー お客様事例 AWS のお客様が Innovation Sandbox on AWS を通じてイノベーションの取り組みを加速している事例を紹介します。 シェフィールド大学 背景 1905 年に設立されたシェフィールド大学は、英国イングランドに拠点を置く名門の研究重視の公立大学です。世界のトップ 100 大学に常にランクインしており、約 30,000 人の学生が在籍しています。エンジニアリング、科学、医学など、多くの分野で重要な貢献を続けています。 課題 シェフィールド大学は、AWS サンドボックス環境を大規模に管理する上で 2 つの課題に直面していました。既存のサンドボックスアカウントのライフサイクル管理が非効率なため、割り当て後に多くのアカウントが未使用のままとなっており、未使用アカウントのリソース状況の把握が困難で不必要なコストを招いていました。さらに、学術部門は教育と学習のために AWS 環境を必要としていましたが、セキュリティアクセスとコストを適切に制限したアカウントを管理するための技術的専門知識が不足していました。 ソリューション 大学は Innovation Sandbox on AWS をデプロイし、アカウント割り当ての権限を管理スタッフと学術スタッフに移譲しました。サンドボックス使用に伴うリソースの非効率性という最初の課題に対処するため、大学はコスト制限とコース期間に基づいたアカウントリサイクル設定を構成しました。管理スタッフと学術スタッフは UI を活用して、すべてのサンドボックスリースのコストと利用状況を把握し、大学へ報告しました。 Innovation Sandbox on AWS に備わるセキュリティポリシーとコスト管理機能を使用し、大学のニーズに合わせて設定しました。事前定義されたセキュリティポリシーとコスト管理機能を備えた、管理された AWS 学習環境を迅速にセットアップし、教育目標や学部の要件とシームレスに統合することができました。また、コーススケジュールとスタッフのプロジェクトタイムラインの両方に対応する、サンドボックスアカウントの割り当てと解除の自動スケジューリングシステムも開発しました。 成果 Innovation Sandbox on AWS のデプロイにより、IT 効率と部門の自律性が向上しました。 リソース使用率の最適化: 自動化されたアカウント管理を通じてサンドボックス環境の管理プロセスを合理化し、学部全体の使用パターンを明確に可視化しました。 分離されたサンドボックスの安全な使用: このプラットフォームは IT 運用負荷を抑えながらセキュリティ態勢を改善し、非技術スタッフや学術サービスが AWS 機能を独自に活用できるようになりました。 コストガバナンスの確立: 学部の予算を効果的に管理しながら、AWS ツールを教育および学習活動へ統合することを促進しました。 セルフサービスサンドボックス: セキュリティとガバナンス基準を維持しながら、自動化機能を通じて IT 部門の関与が削減されました。 お客様の声 「生成 AI を教え、学生に Amazon Bedrock の使用に慣れてもらうための新しいコースモジュールを構築しました。Innovation Sandbox on AWS を使用することで、セキュリティとコスト管理を備えた AWS アカウントを迅速に展開でき、学生が&nbsp;Amazon Bedrock を安全に利用できるようになりました。導入したモジュールにより、法学部の学生が法律相談クリニック向けに独自の生成 AI 法律エージェントを構築できるようになりました。私たちのビジョンは、生成 AI 法律エージェントを各学期に新しい学生によって改善し、最終的に大学内のすべての法学部の学生、さらには法律業界全体で使用できる新しいエージェント AI 製品を生み出すことです。」 — Ben Orza 氏、シェフィールド大学 IT サービス元リードテクノロジーアーキテクト イーストロンドン大学 背景 イーストロンドン大学 (UEL) は、英国ロンドンのトップランクの公立教育機関であり、160 以上の国籍からなる 40,000 人以上の学生が在籍しています。同大学は、高等教育を通じて社会に良い影響を与えることに焦点を当てています。学生が成功するキャリアを築き、企業が求めるスキルを身につけられるようにすることを使命としています。 課題 UEL の学術部門、特にエンジニアリング・コンピューティング学部は、当初 AWS Academy を活用して基礎的なクラウド教育を提供していました。AWS Academy は、学生にクラウドの基礎を紹介し、クラウドテクノロジーへの関心を喚起する上で効果的でした。しかし、UEL のカリキュラムがより高度なクラウドネイティブおよび AI スキルを重視するように進化するにつれて、大学はより充実した学習環境の必要性を認識しました。 学生は、学期を通じて長期プロジェクトを開発・維持するために、より分離された環境を必要としていました。また、教育者はクラウド技術を授業カリキュラムにより深く組み込むための柔軟な環境を求めていました。さらに、高度な AWS サービスの実践的な経験への需要が高まるにつれて、UEL は、セキュリティを損なうことなく、また中央 IT の運用負荷を増やすことなく、AWS サービスへのより広範なアクセスを提供できるソリューションを必要としていました。 UEL の目標は、AWS Academy が提供する強固な基盤の上に構築し、よりスケーラブルで柔軟な AWS 環境を作成することでした。この AWS 環境は、学生と教員の両方を効果的にサポートし、業界の実践や新しいテクノロジーと密接に連携した実世界の学習体験を可能にする必要がありました。 ソリューション さまざまなオプションを検討した後、UEL はクラウド教育の課題に対処するために Innovation Sandbox on AWS を採用しました。学生と学術チームに、期限付き AWS アカウントへのオンデマンドアクセスを提供しました。大学の IT サービスチームはソリューションをデプロイし、さまざまな分野の数百人の学生をサポートするために 330 を超えるサンドボックスアカウントを迅速にセットアップし、柔軟な学習環境を提供しました。 セルフサービスポータルにより、学生は数分で AWS アカウントのリースをリクエストでき、AWS アカウントの利用開始プロセスが合理化されました。事前定義されたリーステンプレートには、承認要否、リース期間、クリーンアップを設定するためのコントロールが含まれており、効率的なリソース管理ができるようになりました。学術スタッフと IT スタッフは、直感的な UI により技術的な負荷を管理することなく、アカウントとリースの一元的な監視が可能になりました。学術スタッフは、AWS IAM Identity Center との統合を活用して、モジュールの提供、課題、評価のための学生アクセスを管理できました。さらに、Amazon Bedrock などの高度なサービスをサポートし、生成 AI などの最先端テクノロジーのハンズオン実施を可能にしました。 Innovation Sandbox on AWS により、教育チームは単一のログインセッションをはるかに超える実世界の学習体験を設計できるようになりました。Innovation Sandbox on AWS は、UEL のクラウド教育へのアプローチを改善し、学生と教育者の両方により柔軟なプラットフォームを提供しました。 成果 Innovation Sandbox on AWS のデプロイにより、UEL の教育インフラストラクチャと学生体験が向上しました。 永続的な学習環境 : 学生はリースの全期間にわたって AWS 環境を保持し、長期プロジェクトと反復的な開発をサポートします。 教育者のより大きな柔軟性 : クラウドサービスを、選択科目や学際科目を含む、より幅広い授業カリキュラムに組み込むことができるようになりました。 高度なサービスのサポート : 学術スタッフは、IT サービスの介入なしに、Amazon Bedrock、Amazon SageMaker、AWS Lambda などのツールに学生を触れさせることができます。 学生エンゲージメントの向上 : 学生は主体的に取り組めるようになり、クラウド技術をコースワークや研究に実践的に活用できます。 スケーラブルで安全 : 自動クリーンアップ、アカウントリサイクル、ガードレールが実装されているため、リスクや手動の負荷なしに大規模な学生集団をサポートできます。 お客様の声 「Innovation Sandbox on AWS により、学生とスタッフが実験するためのサンドボックス環境の管理を合理化することで、AWS 環境管理者の運用負荷が軽減されました。330 を超えるサンドボックスアカウントを管理しており、サンドボックスのライフサイクル管理が簡素化され、学習要件に必要なさまざまな環境を作成するという学術目標により多くの時間を費やすことができるようになりました。」 — Jordan Richards 氏、イーストロンドン大学 IT サービス部門 AWS ソリューションアーキテクト 「Innovation Sandbox on AWS により、サーバーレスアプリケーション、AI エージェント、マイクロサービスなど、実際の業界のユースケースを反映した学習環境を作成できます。変更のたびに IT を関与させる必要はありません。学生は、コースワークを完了するためだけでなく、実験、イノベーション、研究、さらには起業のためのプラットフォームとして、クラウド環境にアプローチできるようになりました。」 — Gaurav Malik 氏、イーストロンドン大学エンジニアリング・コンピューティング学部教育・体験ディレクター ハノイ工科大学 背景 ハノイ工科大学 (HUST) は、1956 年に設立されたベトナム初の技術系総合大学です。研究、科学、エンジニアリングの卓越性で長年の評判を持つ HUST は、国の産業と技術の進歩を推進する最前線に立ってきました。現在、大学には約 40,000 人の学生がおり、国際化、イノベーション、デジタルトランスフォーメーション、「共有デジタル大学」としての地位確立に焦点を当てた先進的な開発戦略を実施しています。 課題 イノベーションアジェンダの一環として、HUST は銀行セクターのユーザーエクスペリエンスを向上させることを目的とした全国的なハッカソン、HACK TOGETHER 2025 を実施しました。イベントには、学生、開発者、データサイエンティスト、金融プロフェッショナルで構成される学際的なチームが集まりました。24 チームがわずか 2 週間で技術ソリューションを構築およびプロトタイプ化することが予想される中、HUST はいくつかの課題に直面しました。 インフラストラクチャのセットアップ : 各チームに、コアシステムへのリスクなしにソリューションを構築およびテストするための安全で分離された環境を提供する。 スケーラビリティとガバナンス : 適切なセキュリティガードレールと利用ポリシーを実装し、複数のクラウドアカウントを管理する。 コスト管理 : 予算の予測可能性を確保し、クラウドコストの急上昇を抑止する。 運用負荷 : インフラストラクチャの管理に費やす時間を削減し、HUST スタッフがメンタリングとイノベーション支援に集中できるようにする。 ソリューション 課題に対処するため、HUST は AWS と提携して Innovation Sandbox on AWS を実装しました。サンドボックス環境の作成、ガバナンス、自動リサイクルを簡素化するように設計されたソリューションで、次のような機能を備えています。 ユーザーが AWS アカウントをリクエストするための セルフサービスポータル 組み込みのセキュリティと使用管理を備えた 自動サンドボックスリース管理 コストの透明性を実現する コスト上限と監視 リース期限を超えた AWS アカウント内の不要なリソースをクリーンアップして無駄を削減する スケジューリング AWS&nbsp;と協力して、HUST&nbsp;IT&nbsp;チームは数日以内に&nbsp;24&nbsp;のハッカソンチームに独自の分離された&nbsp;AWS アカウントを利用させることができました。サンドボックス環境は、自動化されたガバナンスとガードレールで構成されており、参加者はインフラストラクチャの管理やセキュリティと予算の心配をすることなく、自由に実験できました。 成果 Innovation Sandbox on AWS のデプロイにより、HUST のハッカソン実行が効率化されました。 セットアップの高速化: 24&nbsp;チームの&nbsp;AWS&nbsp;アカウントが数日でセットアップされ、手動プロビジョニングはゼロでした。 安全な実験 : チームは分離された環境で新しいソリューションを構築、テスト、デプロイしました。 イノベーションへの集中 : 参加者は、クラウドのセットアップや権限の処理ではなく、実際の銀行 UX の課題を解決することに時間を費やしました。 コストとリスクの軽減 : 自動化されたガードレールとコスト管理により、超過とポリシー違反が防止されました。 スケーラブルモデル : HUST は、AWS での将来のイノベーションイニシアチブをサポートするための再現可能なモデルを手に入れました。 お客様の声 「Innovation Sandbox on AWS は、HACK TOGETHER 2025 を大規模にホストし、わずか数日で 24 のハッカソンチームへ AWS アカウントを利用可能にする上で重要な役割を果たしました。安全で分離された環境を提供することで、ハッカソンチームが自由に実験でき、組み込みのガバナンスとコスト管理を通じて安心感を得られました。Innovation Sandbox on AWS は、当社のデジタルトランスフォーメーション戦略と完全に一致し、すべての参加者にとって真に革新的なハンズオンの体験を作成するのに役立ちました。」 — Nguyen Binh Minh 氏、ハノイ工科大学デジタル技術経済研究所准教授兼学部長 クラウドイノベーションジャーニーを加速する準備はできていますか? Innovation Sandbox on AWS は、AWS のお客様がセキュリティを維持し、コスト管理を改善し、AWS アカウントの再利用可能性を確保しながら、サンドボックス環境管理を合理化するための強力なソリューションを提供します。学生の学習体験を向上させたい教育機関、開発者の生産性に焦点を当てている企業、イノベーションイニシアチブを推進している組織のいずれであっても、開始は簡単です。 今すぐ AWS Solutions Library にアクセスして Innovation Sandbox をデプロイし、組織のクラウド実験を改善しましょう。詳細については、次をご覧ください。 ドキュメントの詳細な 実装ガイド を参照して、デプロイを開始してください ソリューションの GitHub リポジトリ をご覧ください AWS ソリューションアーキテクトに連絡して、お客様固有のニーズについて話し合ってください 複雑なサンドボックス管理がイノベーションを妨げることのないようにしてください。今すぐ Innovation Sandbox on AWS で、簡素化され、安全で、コスト効率に優れたクラウド実験への第一歩を踏み出しましょう。 Rakshana Balakrishnan Rakshana は AWS のシニアプロダクトマネージャーテクニカルであり、0-to-1 および 1-to-n のクラウドネイティブ製品の設計と提供に関する専門知識を持っています。世界中の数千のお客様がクラウド支出を最適化し、セキュリティ体制を改善し、AWS での生成 AI 価値創造を加速できるようにする製品ポートフォリオを担当しています。Innovation Sandbox on AWS のプロダクトリードとして、コンセプトから立ち上げまでの道のりを先導し、世界的な戦略的成長を推進しました。仕事以外では、ハイキング、ヨガ、アートを楽しんでいます。 Rakshana Balakrishnan Hannah は AWS のグローバル教育向け GTM ビジネスデベロッパーであり、市場投入戦略と実装に焦点を当て、高等教育、研究、EdTech セクターに新しいソリューションを提供しています。AWS での最初の 3 年間は、国際中央政府チームで、税務、福祉、国家安全保障と防衛、エネルギーセクターにわたるグローバルな公共セクターリーダー向けのプログラムを開発していました。世界中でよりアクセスしやすく公平な学習機会を創出するために、教育におけるデジタルトランスフォーメーションを推進することに情熱を注いでいます。 Rakshana Balakrishnan Todd は AWS のクラウド基盤スペシャリストです。お客様がビジネス目標を達成するために、クラウド環境の設計、デプロイ、最適化、スケーリングを支援することに情熱を注いでいます。Todd の情熱には、歴史、障害物レース、妻、3 人の子供、2 匹の犬との思い出作りが含まれます。 Rakshana Balakrishnan Wayne は AWS の EMEA 担当プリンシパルインダストリーソリューションマネージャーであり、金融、教育、製造、地方自治体セクターにわたる 20 年以上の経験を持っています。Wayne はこの経験を活かして、組織がコストを削減し、新しいテクノロジーを活用する最新のビジネスアプリケーションを実装するのを支援しています。

本稿は、JFE スチール株式会社による CPS 開発実行基盤の構築について、これを主導された JFE スチール株式会社 庄村 啓様、JFE システムズ株式会社 杉田 朋晃様、原 洋平様、髙山 翔伍様より寄稿いただきました。 はじめに JFE スチール株式会社は、グローバル鉄鋼サプライヤーとして、自ら学習し自律的に最適自動操業を行う「インテリジェント製鉄所」の実現を目指しています。その実現の鍵を握るのが、製造プロセスの CPS（Cyber Physical System）化です。 CPS は、製造現場(フィジカル)から収集したセンサーデータをもとに、デジタル空間上に高度な仮想プロセス(サイバー)を再現する技術です。この 2 つをリアルタイムに連携させることで、現実では見えない設備内部の状態把握や将来予測を実施し、仮想プロセスでの健全性監視・異常予測の結果を実際の操業にフィードバックします。JFE スチールでは統計モデルと物理モデルを融合した予測モデルを構築し、安定操業、生産性向上、品質安定化、GHG 排出削減などを実現します。 インテリジェント製鉄所のコアとなる全製造プロセスの CPS 化を推進するためには、機械学習モデルの開発から製鉄所エッジでの推論実行まで、一気通貫で対応できる「CPS 開発実行基盤」が不可欠です。しかし、従来の機械学習基盤ではユーザーが個人ごとに環境分離を行えないなど当社の要件と合致しない点が複数あり、CPS 開発実行基盤の構築が停滞していました。これを解決するため、JFE スチールは Amazon SageMaker AI を中核とした CPS 開発実行基盤の構築プロジェクトに着手しました。 プロジェクト体制 本プロジェクトは、JFE スチール、JFE システムズ、AWS の 3 社協業体制で推進されました。 JFE スチールは、事業会社として業務要件を熟知していることから、全体統括と要件定義を担当しました。JFE システムズは長年にわたり当社の IT システム構築・運用に携わり、当社 IT システムに関する環境を熟知しています。近年はクラウド事業に注力し、クラウド活用推進部（CCoE）を新設してクラウド活用の推進に取り組んでいます。本案件では AWS パートナーとしての高度な技術力を活かし、閉域接続環境と CPS 開発実行基盤の設計および運用を担当しました。AWS は、基盤に関する技術支援に加え、全国の製鉄所・研究所への普及活動を支援しました。この 3 社協業により、それぞれの強みを活かした効率的なプロジェクト推進が実現しました。 本プロジェクトにおいて AWS ソリューションアーキテクト (SA) の皆様には、基盤構築の初期段階から全国拠点への展開に至るまで、専門性と実務経験に基づく多面的なご支援をいただきました。これらの伴走的な支援は、CPS 開発実行基盤の高品質な構築とスムーズな利用定着を大きく後押しし、今回構築した基盤を利用する研究者・製鉄所エンジニアから高い評価を得る結果につながりました。 まず、 SageMaker AI 、 IAM 、ネットワーク、セキュリティなど多岐にわたる領域に対して体系的な AWS 技術勉強会をご提供いただき、プロジェクトメンバーの AWS に対する理解が深まりました。これにより、企画・設計フェーズを効率的に進めることができました。アーキテクチャ設計においては、今回の用途の特性を踏まえ、サービス選定から構成設計に至るまで AWS の最新ベストプラクティスに基づく具体的な助言をいただきました。特に、当社固有のセキュリティ要件への適合や権限分離に関する設計提案は、基盤品質の向上に大きく寄与しました。 加えて、基盤を利用する研究者や製鉄所エンジニアが迅速に開発に取り組めるよう、 SageMaker Studio を中心とした操作手順やワークフローを体系化したハンズオン教材の整備にご協力いただきました。このコンテンツにより、導入直後から利用が加速し、現場での活用が円滑に進みました。さらに、ハンズオンや個別相談会においても必要に応じて国内各拠点に足を運んでいただき、研究者・技術者に対するきめ細かな支援を実施いただきました。現場の課題に寄り添った対応により、利用者の理解が深まり、基盤の定着と活用拡大が加速しました。 これら AWS SA の皆様による専門的かつ丁寧なご支援により、本基盤は短期間で安定稼働へと移行し、全国の研究者・製鉄所エンジニアからの高い評価につながりました。AWS の技術力と伴走支援は、本プロジェクト成功の重要な推進力となりました。 既存基盤の課題 従来の機械学習環境には、いくつかの課題がありました。 最も大きな課題は、研究者ごとに独立した開発環境を提供できなかったことです。機密情報管理の観点からユーザーは個人ごとの環境分離を要望していましたが、従来検討していたサービスではこの要件を満たすために多額のコストが発生する可能性があり、CPS 開発実行基盤の構築が停滞していました。 さらに、環境構築の手間も大きな負担でした。新しい研究者が開発を始める際、PC のセキュリティ設定や必要なライブラリやツールのインストールを行う必要があり、セットアップが複雑でした。 加えて、キャパシティ不足により、必要な時に十分な計算リソースを確保できないという制約もありました。大規模な機械学習モデルの開発や、複数の研究者が同時に計算リソースを必要とする場合、リソース不足が開発のボトルネックとなっていました。また、キャパシティ不足を解決するために新たなサーバーを調達する際には、コスト負担も課題となっていました。 全プロセスの CPS 化を加速するためには、これらの要件を満たす機械学習基盤が必要でした。 Amazon SageMaker AI による解決策 JFE スチールは、これらの課題を解決するため、 Amazon SageMaker AI を中核とした以下のような CPS 開発実行基盤を構築しました。 図1: 全体アーキテクチャ Amazon SageMaker Studio を用いた独立した環境の提供 SageMaker Studio は、 SageMaker AI が提供する機械学習の各種機能にアクセスする ための Web ベースのプラットフォームです。 SageMaker Studio からアクセスできる IDE 機能である Code Editor は、従来から使用していた Visual Studio Code と同様の使用感を提供し、デフォルトで個人ごとに開発環境が分離されています。Code Editor は、一定時間使用されない場合に自動的にシャットダウンされる仕組みを備えており、個人ごとの環境分離を低コストで実現できます。さらに、 Amazon S3 上の学習データや SageMaker AI のリソース（学習ジョブ、モデル、エンドポイントなど）へのアクセス権限を AWS IAM で個人ごとにきめ細やかに制御しています。これにより SageMaker Studio 全体で作業環境とリソースの個人ごとの環境分離を実現しました。 環境構築の簡単化 従来の環境では、新しい研究者が開発を始める際に PC へのライブラリやツールのインストールなど、煩雑なセットアップ作業が必要でした。 SageMaker Studio の導入により、研究者は PC へのインストール作業から解放され、Web ブラウザからアクセスするだけで、すぐに開発を開始できるようになりました。 Code Editor には、データ解析や機械学習で利用される主要なライブラリが一式プリインストールされており、イメージの最新版が頻繁にアップデートされて提供されるため、研究者は常に最新のアルゴリズムやライブラリを容易に試すことができます。また、 Amazon Q Developer による生成 AI を活用したコーディング支援も利用できます。 コストを増加させないキャパシティ不足の解決 従来の環境では、キャパシティ不足により必要な時に十分な計算リソースを確保できないという課題がありました。SageMaker Training は、機械学習モデルの学習を実行するための機能で、学習ジョブを実行すると機械学習用インスタンスが自動起動し、学習終了後に自動でシャットダウンされる仕組みです。インスタンス起動時には、研究者が自由にインスタンスの種類や数を指定できます。これにより、必要な時に必要なだけ計算リソースを柔軟に拡張できるようになり、従来は困難だった大規模な機械学習モデルの開発も、複数のインスタンスを並列で稼働させることで対応可能になりました。また、従来環境では常時起動による時間課金が発生していましたが、SageMaker Training では起動した時間分のみの課金となるため、使用していない時間のコストを削減できます。 得られた成果 基盤の改善 従来の機械学習環境における課題であった、個人ごとの環境分離、環境構築の手間、キャパシティ不足を解決しました。 また、 Amazon SageMaker AI の導入により以下の副次的なメリットがありました。 SageMaker Studio や Code Editor では最新のイメージを利用者が自由に選択できるため、開発に必要なアプリケーションや OS レイヤーの維持管理作業が不要になりました。また、必要に応じて柔軟にリソースを拡張できるため、従来必要だったキャパシティの常時モニタリングからも解放されました。セキュリティ面では、 AWS IAM Identity Center により、個人ごとに分離された環境への認証を社内の既存の認証基盤と連携させることで、認証の利便性を向上させました。さらに、閉域構成など社内ネットワークポリシーに準拠した構成を維持しました。 利用の拡大と研究者からの評価 機械学習基盤は全国の製鉄所・研究所で展開され、勉強会やハンズオンを通じて利用者からの高い評価を得ています。利用者からは、「これまでできなかったことができるようになった」「自由に計算資源を立ち上げられて良い」というフィードバックが寄せられています。現在、品質改善、異常検知、基盤モデルのファインチューニングなど、多様なユースケースで利用されています。 利用者の間では SageMaker AI の様々な便利機能の利用が始まっています。例えば、SageMaker Training では、学習の実験記録が自動保存されるため、ハイパーパラメータやモデル格納場所、コードの紛失リスクが解消され、実験の再現性が向上しました。この実験管理機能は、社内で大規模な実験の管理に利用されています。 また、利用者自身が学習済みの機械学習モデルをより簡単にデプロイすることが可能となっただけでなく、本格的な業務利用が予定されるユースケースにおいては、JFE システムズの支援により SageMaker AI のバッチ変換ジョブと Amazon ECS を組み合わせた機械学習推論パイプラインを構築し運用しています。 今後の展望 JFE スチールの CPS 開発実行基盤は、 Amazon SageMaker AI の導入を第一歩として、さらなる進化を目指しています。 CPSはそのすべてがクラウド上で完結するものではなく、ユースケースによっては製鉄所のエッジにオンプレミスサーバを配置して運用する必要があります。これを見据え今後は AWS IoT Greengrass によるエッジ配信基盤を構築予定です。 SageMaker AI で開発した機械学習モデルを、製鉄所のエッジサーバに Greengrass で配信し、エッジでのリアルタイム推論を実現します。これにより、機械学習モデルの開発から製鉄所エッジでの推論実行まで、一気通貫のワークフローが完成します。 この CPS 開発実行基盤を活用し、主要ラインの CPS 化を加速させ、最終的には全プロセスを CPS 化して仮想空間に製鉄プロセス全体を再現する「インテリジェント製鉄所」の実現を目指します。 まとめ JFE スチール、JFE システムズ、AWS の 3 社協業により、 Amazon SageMaker AI を中核とした CPS 開発実行基盤の構築を行い、個人ごとの環境分離、環境構築の簡単化、キャパシティ不足の解決を実現し、研究者や製造現場のエンジニアから高い評価を獲得しました。 今後は、 AWS IoT Greengrass によるエッジ配信基盤の統合により、インテリジェント製鉄所の実現に向けて前進していきます。 執筆者 写真左から髙山様、庄村様、杉田様、原様 庄村 啓 JFE スチール株式会社　DX 戦略本部 DX 企画部 大学院卒業後、JFE スチール株式会社に入社。製鉄所のプラント制御システムを管轄する部署にて、設備制御・監視システムの開発および建設業務に従事。 2022 年よりデータサイエンスプロジェクト部（現 DX 企画部）にて、インテリジェント製鉄所の実現に向けた CPS（Cyber Physical System）基盤の構築、維持運用、活用促進活動を担当。 杉田 朋晃 JFE システムズ株式会社 基盤事業本部 基盤エンジニアリング部 カスタムエンジニアリンググループ 大学卒業後、インフラエンジニアとしてシステム開発、設計・構築を担当。 2025 年に JFE システムズに入社。 JFE スチール担当システムエンジニアとして、CPS 開発実行基盤のプロジェクトをリーダとして推進。 原 洋平 JFE システムズ株式会社 基盤事業本部 基盤エンジニアリング部 カスタムエンジニアリンググループ 大学卒業後、2008 年に JFE システムズ株式会社に入社。 以降、JFE スチール向け基盤構築担当として、サーバ基盤の設計、構築を担当。 2022 年から、CPS-PF 案件のモデル開発・実行 PF の基盤リーダーとして推進。 髙山 翔伍 JFE システムズ株式会社 デジタル製造事業本部 第1開発部 大学院卒業後、2017 年に JFE システムズ株式会社に入社。 以降、JFE スチール様担当のシステムエンジニアとして、統計・機械学習を用いた分析業務，システムの設計、構築を担当。 2023 年より、CPS（Cyber Physical System）プラットフォームを活用したシステム構築を推進。

本記事は 2026 年 1 月 15 日 に公開された「 Unlock granular resource control with queue-based QMR in Amazon Redshift Serverless 」を翻訳したものです。 Amazon Redshift Serverless は、データウェアハウス運用からインフラストラクチャ管理と手動スケーリングの要件を取り除きます。Amazon Redshift Serverless のキューベースクエリリソース管理は、クエリを専用キューに分離し、高負荷のクエリが他のユーザーに影響を与えることを防ぐ自動ルールを使用することで、重要なワークロードを保護し、コストを制御するのに役立ちます。さまざまなワークロードに対してカスタマイズされた監視ルールを持つ専用クエリキューを作成でき、リソース使用量をきめ細かく制御できます。キューを使用すると、メトリクスベースの述語と自動応答を定義でき、時間制限を超えたり過剰なリソースを消費したりするクエリを自動的に中止するなどの対応が可能です。 さまざまな分析ワークロードには、それぞれ異なる要件があります。マーケティングダッシュボードには、一貫した高速な応答時間が必要です。データサイエンスワークロードでは、複雑でリソース集約的なクエリを実行する場合があります。抽出、変換、ロード (ETL) プロセスでは、オフピーク時に長時間の変換を実行する場合があります。 組織がより多くのユーザー、チーム、ワークロードにわたって分析の使用を拡大するにつれて、共有環境で一貫したパフォーマンスとコスト管理を確保することがますます困難になっていきます。最適化が不十分な単一のクエリが過度のリソースを消費し、ビジネスクリティカルなダッシュボード、ETL ジョブ、経営層向けレポートのパフォーマンスを低下させる可能性があります。Amazon Redshift Serverless のキューベース Query Monitoring Rules (QMR) を使用すると、管理者はキューレベルでワークロードに応じたしきい値と自動アクションを定義できます。これは、以前のワークグループレベルの監視からの大幅な改善です。BI レポート、アドホック分析、データエンジニアリングなどの異なるワークロード用に専用キューを作成し、キュー固有のルールを適用して、実行時間またはリソース消費制限を超えるクエリを自動的に中止、ログ記録、または制限できます。ワークロードを分離し、ターゲットを絞った制御を実施することで、このアプローチはミッションクリティカルなクエリを保護し、パフォーマンスの予測可能性を向上させ、リソースの独占を防ぎます。これらすべてを、サーバーレスエクスペリエンスの柔軟性を維持しながら実現します。 この記事では、Redshift Serverless でクエリキューを使用してワークロードを実装する方法について説明します。 キューベース監視とワークグループレベル監視の比較 クエリキューが導入される前は、Redshift Serverless はワークグループレベルでのみクエリ監視ルール (QMR) を提供していました。これは、目的やユーザーに関係なく、すべてのクエリが同じ監視ルールの対象となることを意味していました。 キューベース監視は、大きな進化をしています。 きめ細かな制御 – さまざまなワークロードタイプ用に専用キューを作成できます ロールベースの割り当て – ユーザーロールとクエリグループに基づいて、クエリを特定のキューに振り向けることができます 独立した動作 – 各キューは独自の監視ルールを維持します ソリューション概要 以下のセクションでは、一般的な組織が Redshift Serverless でクエリキューを実装する方法を検討します。 アーキテクチャコンポーネント ワークグループ設定 クエリキューが定義される基本単位 キュー定義、ユーザーロールマッピング、監視ルールが含まれます キュー構造 単一のワークグループ内で動作する複数の独立したキュー 各キューには独自のリソース割り当てパラメータと監視ルールがあります ユーザー/ロールマッピング 以下に基づいて、クエリを適切なキューに振り向けます。 ユーザーロール (例: analyst、etl_role、admin) クエリグループ (例: reporting、group_etl_inbound) 柔軟なマッチングのためのクエリグループワイルドカード Query Monitoring Rules (QMR) 実行時間やリソース使用量などのメトリクスのしきい値を定義します しきい値を超えた場合の自動アクション (中止、ログ記録) を指定します 前提条件 Amazon Redshift Serverless でクエリキューを実装するには、以下の前提条件が必要です。 Redshift Serverless 環境 : アクティブな Amazon Redshift Serverless ワークグループ 関連付けられた名前空間 アクセス要件 : Redshift Serverless 権限を持つ AWS Management Console アクセス AWS CLI アクセス (コマンドライン実装の場合はオプション) ワークグループの管理データベース認証情報 必要な権限 : Redshift Serverless 操作の IAM 権限 (CreateWorkgroup、UpdateWorkgroup) データベースユーザーとロールを作成および管理する機能 ワークロードタイプの特定 まず、ワークロードを分類することから始めます。一般的なパターンには以下が含まれます。 インタラクティブ分析 – 高速な応答時間を必要とするダッシュボードとレポート データサイエンス – 複雑でリソース集約的な探索的分析 ETL/ELT – より長い実行時間を持つバッチ処理 管理 – 特別な権限を必要とするメンテナンス操作 キュー設定の定義 各ワークロードタイプに対して、適切なパラメータとルールを定義します。実用的な例として、3 つのキューを実装したいとします。 Dashboard キュー – analyst および viewer ユーザーロールによって使用され、60 秒を超えるクエリを停止する厳格なランタイム制限が設定されています ETL キュー – etl_role ユーザーロールによって使用され、データ処理操作中のリソース使用量を制御するために、ディスクスピル ( query_temp_blocks_to_disk ) に 100,000 ブロックの制限があります Admin キュー – admin ユーザーロールによって使用され、クエリ監視制限は適用されません AWS Management Console を使用してこれを実装するには、以下の手順を実行します。 Redshift Serverless コンソールで、ワークグループに移動します。 制限 タブの クエリキュー で、 キューを有効にする を選択します。 以下のスクリーンショットに示すように、適切なパラメータで各キューを設定します。 各キュー (dashboard、ETL、admin_queue) は特定のユーザーロールとクエリグループにマッピングされ、クエリルール間に明確な境界を作成します。クエリ監視ルールはリソース管理を自動化します。たとえば、dashboard キューは 60 秒を超えるクエリを自動的に停止し ( short_timeout )、ETL プロセスには異なるしきい値でより長い実行時間を許可します。この設定は、適切なガードレールを備えた個別の処理レーンを確立することでリソースの独占を防ぎ、重要なビジネスプロセスが必要な計算リソースを維持しながら、リソースを大量に消費する操作の影響を制限できるようにします。 または、 AWS Command Line Interface (AWS CLI) を使用してソリューションを実装することもできます。 以下の例では、 test-namespace という既存の名前空間内に test-workgroup という名前の 新しいワークグループを作成 します。これにより、以下のコマンドを使用して、キューを作成し、各キューに関連する監視ルールを確立できます。 aws redshift-serverless create-workgroup \ --workgroup-name test-workgroup \ --namespace-name test-namespace \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\"&gt;\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"etl_role\"],\"query_group\":[\"group_etl_inbound\",\"group_etl_outbound\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\"&gt;\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\"&gt;\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' また、以下のコマンドを使用して、 update-workgroup で既存のワークグループを変更することもできます。 aws redshift-serverless update-workgroup \ --workgroup-name test-workgroup \ --config-parameters '[{"parameterKey": "wlm_json_configuration", "parameterValue": "[{\"name\":\"dashboard\",\"user_role\":[\"analyst\",\"viewer\"],\"query_group\":[\"reporting\"],\"query_group_wild_card\":1,\"rules\":[{\"rule_name\":\"short_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\"&gt;\",\"value\":60}],\"action\":\"abort\"}]},{\"name\":\"ETL\",\"user_role\":[\"etl_role\"],\"query_group\":[\"group_etl_load\",\"group_etl_replication\"],\"rules\":[{\"rule_name\":\"long_timeout\",\"predicate\":[{\"metric_name\":\"query_execution_time\",\"operator\":\"&gt;\",\"value\":3600}],\"action\":\"log\"},{\"rule_name\":\"memory_limit\",\"predicate\":[{\"metric_name\":\"query_temp_blocks_to_disk\",\"operator\":\"&gt;\",\"value\":100000}],\"action\":\"abort\"}]},{\"name\":\"admin_queue\",\"user_role\":[\"admin\"],\"query_group\":[\"admin\"]}]"}]' キュー管理のベストプラクティス 以下のベストプラクティスを検討してください。 シンプルに始める – 最小限のキューとルールのセットから始めます ビジネスの優先順位に合わせる – 重要なビジネスプロセスを反映するようにキューを設定します 監視と調整 – キューのパフォーマンスを定期的に確認し、しきい値を調整します 本番環境の前にテスト – 本番環境に適用する前に、テスト環境でクエリメトリクスの動作を検証します クリーンアップ リソースをクリーンアップするには、Amazon Redshift Serverless ワークグループと名前空間を削除します。手順については、 ワークグループの削除 を参照してください。 まとめ Amazon Redshift Serverless のクエリキューは、さまざまな分析ワークロードに合わせたキュー固有の Query Monitoring Rules を有効にすることで、サーバーレスのシンプルさときめ細かなワークロード制御のギャップを埋めます。ワークロードを分離し、ターゲットを絞ったリソースしきい値を実施することで、ビジネスクリティカルなクエリを保護し、パフォーマンスの予測可能性を向上させ、高負荷のクエリを制限できます。これにより、予期しないリソース消費を最小限に抑え、コストをより適切に管理しながら、Redshift Serverless の自動スケーリングと運用のシンプルさの恩恵を受けることができます。 今すぐ Amazon Redshift Serverless を始めましょう 。 著者について Srini Ponnada Srini は、Amazon Web Services (AWS) のシニアデータアーキテクトです。20 年以上にわたり、お客様がスケーラブルなデータウェアハウスとビッグデータソリューションを構築するのを支援してきました。AWS で効率的なエンドツーエンドソリューションを設計および構築することを愛しています。 Niranjan Kulkarni Niranjan は、Amazon Redshift のソフトウェア開発エンジニアです。Amazon Redshift Serverless の採用と Amazon Redshift のセキュリティ関連機能に注力しています。仕事以外では、家族と時間を過ごし、質の高いテレビドラマを視聴することを楽しんでいます。 Ashish Agrawal Ashish は現在、Amazon Redshift のプリンシパルテクニカルプロダクトマネージャーであり、クラウドベースのデータウェアハウスと分析クラウドサービスソリューションを構築しています。Ashish は IT 分野で 24 年以上の経験があります。Ashish は、データウェアハウス、データレイク、Platform as a Service の専門知識を持っています。Ashish は世界中の技術カンファレンスで講演しています。 Davide Pagano Davide は、Amazon Redshift のソフトウェア開発マネージャーであり、自動ワークロード管理、多次元データレイアウト、Amazon Redshift Serverless の AI 駆動スケーリングと最適化などのスマートなクラウドベースのデータウェアハウスと分析クラウドサービスソリューションの構築を専門としています。データベースで 10 年以上の経験があり、そのうち 8 年は Amazon Redshift に特化しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Tatsuya Koyakumaru がレビューしました。

はじめに コンタクトセンター管理者は、本番環境を中断することなく、コンタクトフローを効率的にテストと検証するという課題に直面しています。従来のアプローチ、例えば手動でシステムに電話をかける、カスタム検証ツールを構築する、サードパーティソリューションに投資するような手段は、時間とコストがかかります。大企業では、年間予算の大部分が自動テストツールに割り当てられることも多く、一方で手動検証を用いる場合は変更ごとに数日から数週間の作業が必要になることがあります。Amazon Connect が高度な AI 機能で進化するにつれて、サービス品質と顧客満足度を維持するための効率的なテスト戦略がさらに重要になっています。 Amazon Connect はネイティブコールシミュレーション機能の一般提供を発表しました。組み込まれたこのテストソリューションは、検証時間と作業を大幅に削減しながら、コンタクトセンター設計への信頼性を高めます。外部ツールや手動での電話テストなしでコンタクトセンターワークフローを自動的にテストでき、チームはイノベーションと優れた顧客体験の提供に集中できます。 本記事で学べること 本記事では、Amazon Connect の新しいテスト機能を活用してコンタクトセンターの検証を自動化する方法を説明します。次のことを学べます。 直感的なビジュアルデザイナーでテストケースを設定する 自然な顧客インタラクションを反映したテストシナリオを作成する 自動テストを実行し、結果を分析して継続的な改善を行う テストフレームワークの概要 Amazon Connect のテストとシミュレーションフレームワークは、直感的なビジュアルインターフェースでコンタクトセンター体験を検証できます。ステップバイステップのガイドと複雑な遷移による従来のテストアプローチとは異なり、顧客が実際にコンタクトセンターとやり取りする方法を反映した、自然でユーザーフレンドリーなものです。 イベント駆動型テストモデル フレームワークのコアにはイベント駆動型モデルを使用しています。コンタクトフロー実装の深い技術知識による記述ではなく、「X が発生したら Y を実行する」という観点でテストを記述します。例: 「IVR が『エージェントと話すには 1 を押すか、エージェントと言ってください』と再生したら、顧客は 1 を押すか、エージェントと言う必要があります。」 これには 3 つの直感的な概念を活用します。 Observations (監視): 期待されるシステムイベントと対応するアクションを含む完全なインタラクション Events (イベント): システムから期待される特定の動作 (プロンプト、ボットメッセージ、Lambda 関数呼び出し) Actions (アクション): テストフレームワークが応答としてシミュレートすべきこと (顧客入力、属性検証、リソースモック) イベント駆動型モデルは大きなメリットをもたらします。技術者以外のチームメンバーでもテストを簡単に理解して作成でき、QA チームにとっては最小限のトレーニングで済ませられ、フレームワークによってプロセスをアクセスしやすく保ちながら技術的な精度を維持できます。 ビジュアルテストデザイナーインターフェース デザイナーは、インタラクショングループを使用してテストシナリオを視覚的に構築できるインターフェースです。各インタラクショングループは、期待される動作とシミュレートされたアクションの完全なシーケンスを表し、テストフローを一目で把握できます。ビジュアルアプローチにより学習にかかる時間が短縮され、チームメンバーは基礎となる技術実装の詳細を理解することなくテストを作成できます。 テスト分析とダッシュボード Amazon Connect は、 分析と最適化 &gt; ダッシュボードとレポート &gt; テストおよびシミュレーションダッシュボード からアクセスできる専用のテストとシミュレーションダッシュボードを提供します。ダッシュボードでは以下のようなテスト実行履歴の詳細な洞察が得られます。 全体的なテスト成功率を示すサマリーメトリクス 一般的な問題を特定するための失敗タイプの内訳 パフォーマンス分析のための実行時間メトリクス 時間の経過に伴う改善を追跡するための日付範囲フィルタリング テストケースの作成 効果的なテストケースの構築には、3 つの主要なステップがあります。基本的なテスト設定の構成、インタラクショングループを使用したテストフローの設計、観察およびシミュレートする特定の動作の定義です。 テスト設定とパラメータの構成 テストケース管理ページ（ ルーティング &gt; テスト ）で テストを作成 をクリックして、新しいテストケースを作成します。 設定 タブで次を構成します。 開始点 : 特定のフローまたは電話番号 チャンネル : 音声通話 着信電話番号 : シミュレートされる発信者の電話番号 属性 : プロファイル情報などのユーザー定義コンタクト属性 インタラクショングループの構築 デザイナー タブで、インタラクショングループのテストフローを構築します。各グループは、何かが発生することを期待し、そのイベントを検証または応答する必要がある瞬間を表します。 + 新しいインタラクション ボタンでインタラクショングループを追加し、それらを接続して完全なテストケースフローを定義します。 Observation、Check、Action ブロックの設定 各インタラクショングループには、最大 3 つのブロックタイプが含まれます。 Observe ブロック (必須) : 「Test started(テスト開始)」、「Message received(メッセージ受信)」、「Action triggered(アクション呼び出し)」などの期待されるシステムイベントを定義します。メッセージベースの観察の場合、メッセージの内容が一致するか確認するために次のいずれかを選択できます。 Contains : 実際のメッセージに指定されたテキストが含まれているかどうかをチェックします (部分一致) Similar : セマンティックな類似性のための高度な比較を使用します (意味的一致) ※訳注 ブログ翻訳時点では Observe ブロックは英語で受信されるメッセージをサポートしています。詳しくは ドキュメント をご覧ください。 Check (チェック)ブロック (オプション) : コンタクトジャーニーのその時点で、特定の属性に期待される値が含まれているか検証します。名前空間 (System、User defined、Segment Attributes など)、属性キー、期待値を指定して属性検証を構成します。 Action ブロック (オプション) : 観察されたイベントに応答してフレームワークがシミュレートすべきことを定義します。 Mock resource behavior : 連携している Lambda 関数からの応答や、 Hours of Operation (オペレーション時間)、Queue(キュー)、Lex bot などのリソースをテスト用の代替リソースに置き換えることができます Send instruction : 顧客入力をシミュレートします (DTMF トーン、テキスト発話、通話切断) Test commands : 属性のログ記録やテストの終了などのユーティリティです セルフサービスとキュー体験のテスト: 実践例 コンタクトセンターフローをテストすることで、顧客が一貫性のある信頼性の高い体験を受けられるようになります。このセクションでは、一般的なシナリオのテストについて説明します。既存の顧客が営業時間内に電話をかけてエージェントに到達するケースです。 顧客体験 フローは次のように動作します。 Lambda 関数が着信電話番号で顧客のタイプを確認します。 システムがウェルカムプロンプトを再生し、顧客にエージェントに到達するためには 1 を押すように求めます。 入力を受信した後、顧客は確認メッセージを聞きます。 システムは、エージェントが対応可能になるまで、保留音楽付きのキューに顧客を転送します。 テストケースの構築 体験を検証するために、3 つのインタラクショングループを持つテストケースを作成します。 テスト設定の構成 シミュレートするフローを選択し、顧客の識別情報として着信電話番号を入力します。 インタラクショングループ 1: テストの初期化 テストのセットアップと営業時間のオーバーライドを処理します。 Observe ブロック : イベントタイプとして「Test started」を選択します。テストが開始されるとすぐに実行されます。 Action ブロック : Hours of Operation リソースのオーバーライドを構成します。テストを実行するタイミングに関係なく、営業時間内であるかのようにテストが実行されます。フローの Hours of Operation リソースを選択し、フローで営業時間チェックが呼び出されたときに「営業時間内」になるように応答をモックするか、常に営業中の代替リソースを指定します。 インタラクショングループ 2: ウェルカムプロンプトの検証 ウェルカムプロンプトを検証し、顧客入力をシミュレートします。 Observe ブロック : Event の種類: 「Message received」 Actor: 「System」(デフォルト。プロンプトはコンタクトフローから発信されるため) Expected text: 「Press 1 to be connected to an agent(エージェントに接続するには、1 を押してください)」 Matching criteria: 「Similar」 Action ブロック : 顧客が 1 を押すことをシミュレートする「Send instruction」アクションを構成します。 Response type: 「DTMF Input」 Input value: 「1」 インタラクショングループ 3: キューの検証 キューへの配置を検証し、テストを終了します。 Observe ブロック : 期待される確認メッセージを指定します。「Thank you for calling. Your call is very important to us and will be answered in the order it was received.(お電話ありがとうございました。お客様からの声は重要です。順番におつなぎしますのでお待ちください。)」 Check ブロック : System 名前空間の「Queue Name」属性を期待値 (例: 「Agent Queue」) と照合して、正しいキューに転送されたかを検証します。 Action ブロック : 2 つの「Test commands」アクションを追加します。 Log data : テスト実行の詳細で分析するために関連する属性をキャプチャします End test : テストケースの実行を終了します テストの実行 すべてのインタラクショングループを構成した後、3 つのインタラクショングループが順番に接続されていることを確認します。その後、テストケースを保存して公開し、実行できる状態にします。 テストの実行と分析 テストケースの実行 テストデザイナーから テストを実行 ボタンで直接テストを実行するか、テストケース管理ページからバッチ実行できます。Amazon Connect は、インスタンスごとに最大 5 つの同時テスト実行をサポートし、追加のテストは自動的にキューに入れられます。主要な変更をテストして結果を取得してから、時間がかかる可能性のあるリグレッションテストを実行できます。 結果の監視とレビュー テスト実行 タブでテストの進行状況をリアルタイムで監視します。詳細な結果ページには、次のような詳細なビューを確認できます。 全体的なテストパフォーマンスを要約するセッションメトリクス インタラクショングループの完了率と合格/不合格の統計、および合計シミュレーション時間 初期セットアップ、テスト開始、インタラクション、テスト完了を含む詳細なテスト実行ステップ 各 observe ブロック、check ブロック、action ブロックの実行の詳細 失敗したテストのトラブルシューティング テストが失敗した場合、詳細な結果ページには、どの特定のインタラクションまたはブロックが失敗したかが示されます。次の情報を確認できます。 失敗した observe ブロックの期待されるイベントと実際のイベント 失敗した check ブロックの属性検証の詳細 アクション失敗の理由と試行された操作 完全な音声録音とトランスクリプション (有効な場合) 利用を始めるには ベストプラクティス 整理 : 「一般的な顧客 – 営業時間中 – エージェントへ転送」のように、明確でわかりやすいテスト名を使用します。タグを活用して、機能領域、顧客タイプ、優先度レベルごとにテストを分類します。 レジリエンス : 可能な限りプロンプトにセマンティックマッチングを使用して、わずかな文言の変更に対応できるようにします。時間依存のリソースをオーバーライドして、テストを実行するタイミングに関係なく一貫したテスト実行を定義します。 優先順位付け : 重要なカスタマージャーニーを最初に優先します。エージェント転送、一般的なセルフサービスシナリオ、営業時間外の体験です。最も重要な機能から常に検証していきます。 統合 : テストをデプロイメントプロセスに組み込みます。コンタクトフローの変更をデプロイする前に関連するテストケースを実行して、顧客に影響を与える前に問題を発見します。 その他のテストシナリオの例 営業時間外のテスト : 営業時間外に電話をかけることをシミュレートするテストを構成し、適切なクローズメッセージとコールバックオプションを検証します。 セルフサービスの検証 : 顧客が IVR メニューをナビゲートし、DTMF または音声でアカウント情報を提供し、期待される結果に到達することをシミュレートするテストを作成します。 認証された顧客体験 : 認証された顧客に対する差別化された処理をテストします。優先キュー配置や専門エージェントルーティングなどです。 コールバックシナリオ : 待ち時間が長い場合のコールバックオプションを検証します。番号の収集と確認プロセスを含みます。 まとめ Amazon Connect のネイティブなコールシミュレーション機能は、コンタクトセンター体験を検証および維持する方法を変革します。テストケースを迅速に作成し、オンデマンドに、あるいはデプロイメントプロセスの一部として実行し、継続的な改善を推進する洞察を得ることができます。 Amazon Connect インスタンスで今すぐこれらのテスト機能をお試しください。最も重要なカスタマージャーニーの重要なテストケースから始め、時間の経過とともにカバレッジを拡大し、テストダッシュボードを活用して進捗状況を追跡すれば、最適化の機会を特定できます。 詳細なドキュメントと実装のガイドは、 Amazon Connect 管理者ガイド および Amazon Connect API Reference をご覧ください。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

Amazon Connect は、より低いコストで優れた成果を実現する AI を活用したカスタマーエクスペリエンスソリューションです。2017 年のパブリックローンチ以来、Amazon Connect は AI の活用を推進し、あらゆる種類の組織が顧客とやり取りする方法を変革してきました。 先週の Q3 2025 年決算報告で、Amazon は重要なマイルストーンを発表しました。Amazon Connect は年間換算売上高 10 億ドルのペース(ランレート)を達成し、AI が前年に 120 億分を超える顧客とのやり取りを最適化しました。このような成功が続く中でも、Amazon Connect はミッションに基づいて行動し続け、サービスのスタート時と同様に、最終的な顧客の満足、エージェントの満足、そしてビジネスリーダーの喜びを通じて結果を測定しています。 ここで Amazon Connect のストーリーを探ってみましょう。Amazon の内部ソリューションから AI のパイオニアとなるまでの道のりです。 ストーリーの起源 Amazon Web Services (AWS) と同様に、Amazon Connect は Amazon が内部ソリューションを業界をリードするサービスに変革した事例です。ストーリーは 2007 年に始まりました。内部のカスタマーサービスチームが、3 つのコンタクトセンターベンダーを置き換えるため、ゼロから新しい統合ソリューションを構築する提案を採用したときです。従来の方法では、ハードウェアアップグレードのための 300 万ドルの前払い投資に加えて、継続的なライセンスとメンテナンス料金が見積もられていました。一方、提案された内部ソリューションは、より安価であるだけでなく、地球上で最もお客様を大切にする企業であるという Amazon の明文化されたミッションを体現していました。 「当時、他のすべての製品を調べました。しかし魅力的な選択肢はみつかりませんでした」カスタマーサービスチームを設立し、Connect の最も上級なエンジニアリングリーダーの一人であり続けている Jon Jay 氏は述べています。「いずれも要件を満たすキャパシティを持っていなかったため、これらのコンタクトセンターソリューションでは十数個のインスタンスを管理する必要があったでしょう。それらは非常に高価でしたし、顧客を喜ばせるために対処したいと考えていた問題を解決しませんでした。」 Amazon Worldwide Consumer の元 CEO である Jeff Wilke 氏からの承認を受けた後、チームは 2007 年に最初のパイロット展開に成功し、2008 年に完全に展開されました。内部効率化プロジェクトとして始まったこのプロジェクトは、カスタマーサービスから人事、輸送まで、Amazon のさまざまな部門に何年もサービスを提供し続け、競合ソリューションと比較して推定年間 6,000 万ドルの節約を実現しました。Audible や Zappos など新たに買収された企業も、このソリューションを熱心に採用し、カスタマーエクスペリエンスに対する Amazon 独自のアプローチが、市場での需要があることを証明しました。 「私たちが構築したものを他の Amazon チームに見せると、これは急速に広がりました。Zappos、Audible – 彼らはみな同じく、従来のコンタクトセンターで頭痛の種を抱えていました。私たちのソリューションを見せた時、彼らは『ちょっと待って – あなたたちは私たちの最大の問題をすべて解決したのですか』と言ったのです」と Jay 氏は述べています。 製品ローンチと初期の成功 Amazon Connect を一般に利用可能にする決定は 2015 年第 3 四半期に行われ、当時の AWS CEO である Andy Jassy 氏の承認を得て、Pasquale DeMaio 氏が主導しました。 「潜在的な外部顧客と話すと、お客様も Amazon と同じ課題に直面していることは明らかでした」と Jay 氏は付け加えました。「実装が簡単で、イノベーションの速度を提供し、最大規模の企業が必要とする信頼性とセキュリティ、拡張性を提供できるクラウドベースのソリューションであった可能性が分かりました。私たちは Amazon の問題だけを解決していたのではないことを知りました。業界全体が何十年もの間行き詰まっていた問題を解決していたのです。」 外部サービスとしての開発から 1 年強後、Amazon Connect は Enterprise Connect 2017 でパブリックデビューを果たし、重大なスケーリングの課題に直面している大企業の間で急速に注目を集めました。また AWS サービスとの深い統合により、シームレスなスケーリングと迅速な機能開発が可能になり、Amazon Lex を通じて&nbsp;Alexa AI テクノロジーを早期採用したことで、Amazon Connect を際立たせる自然言語対話型音声応答 (IVR) 機能が提供されました。 Capital One、Hilton、GE など Amazon Connect を早期に採用したお客様は、Amazon Connect の独自の価値提案に魅力を感じました。それは従来の電話インフラストラクチャの必要性を排除したクラウドネイティブなアーキテクチャです。この革新的なアプローチにより、従来は 1 年間の構築プロセスだったものが、多くの組織にとって週末のプロジェクトに変わり、市場投入時間と運用の複雑さの両方を劇的に削減しました。 「最初、私たちのイノベーションの速度を求める組織が、Amazon Connect とのパートナーシップで成功を収めました」と Amazon Connect の VP である Pasquale DeMaio 氏は述べています。「組織は、私たちが非常にユニークな方法でカスタマーエクスペリエンスを理解していることを知っています。お客様へのこだわり・お客様を起点に考えることもその一つです。Amazon では、私たちは毎日そのように過ごしています。」 COVID-19 のパンデミックが発生したときも、Amazon Connect のクラウドネイティブ設計のメリットが発揮されました。セルフサービスセットアップとネイティブな在宅勤務のエージェントサポートは、組織がリモートワークの従業員でカスタマーサービス業務を維持しようと奔走する中で、重要な利点となりました。標準的なインターネット接続とヘッドセットだけで機能し、専用の電話機器の必要性を排除できるため、突然のリモートワークへの移行に理想的なソリューションとなりました。パンデミックの終わりまでには、Amazon Connect は数万の顧客を抱えていました。 カスタマーエクスペリエンスにおける AI 革命 Amazon Connect の進化は、2019 年に AI を活用した会話分析、感情分析などのローンチにより更なる飛躍を遂げました。これらに一般的な複雑な技術要件はありません。他のソリューションでは数週間の展開が必要なのに対し、Amazon Connect ではお客様がこれらの AI 機能を有効にするためにチェックボックスを選択するだけで済みました。 2023 年、Amazon Connect は 2 つの主要な業界レポートで初めてリーダーシップポジションを達成しました。 Forrester Wave for Contact Center as a Service と Gartner’s Contact Center as a Service Magic Quadrant です。Amazon Connect は、現在まで後続のレポートでこれらのリーダーシップポジションを維持しています。 追加の AI 機能は、カスタマージャーニー全体に対して迅速に提供されました。生成 AI の出現で、チームはロードマップを転換し、大規模言語モデル (LLM) テクノロジーを採用し、自動でのエージェントのラップアップ、通話要約、LLM ベースのセルフサービスエクスペリエンスなどの機能を可能にしました。 2024 年 12 月、Amazon Connect は 60 億分の顧客とのやり取りが AI によって最適化されたと発表、顧客が実際のシナリオで AI を活用されている規模を示しました。Amazon Connect が 2025 年 3 月にカスタマージャーニー全体で AI が有効になった「次世代の Amazon Connect」を発表したときも、お客様の反応はとても肯定的でした。現在、Amazon Connect は AI で 120 億分の顧客とのやり取りを最適化しており、これは 1 年足らず前に発表された数値の 2 倍です。 Amazon Connect は、エンタープライズ規模の革新的で統合された AI ソリューションを提供しています。最近も、複数のグローバルブランドが他のプロバイダーや新興の AI ネイティブプレーヤーよりも Amazon Connect を選択しています。これらの評価において、Amazon Connect は、インテント検出精度、AI エージェントの安全性、人間と AI のコラボレーション機能などの重要な領域で優れたパフォーマンスを実証しました。これらの結果は、単なる優れたデモではなく、技術的メリットと信頼性に基づいてミッションクリティカルなユースケースを可能にし、Amazon Connect がクラス内で最高レベルの AI ソリューションを提供する能力を実証しています。 今後の展望 Amazon Connect は 10 億ドルの収益ランレートというマイルストーンの達成により、従量課金ベースのカスタマーエクスペリエンスソリューションとしてのこの規模に到達した存在になりました。この従量課金制アプローチは、AI とエージェンティックな未来に向けて Amazon Connect を特徴づけています。 「転機が次々と訪れました。Amazon Connect はまず最初に、クラウドベースのコンタクトセンターを新しい標準にする主要な推進力となり、次に COVID 中に需要の大幅な変動を管理しながらリモートワークをナビゲートするビジネスを可能にし、最終的に生成 AI で実世界の結果を提供しました」と DeMaio 氏は述べています。「今、私たちはさらに 2 つのテーマに直面しています。エンタープライズ規模で安全で倫理的なエージェンティック AI を提供すること、受動的な顧客エンゲージメントから積極的な顧客エンゲージメントに進化すること – これらをすべて顧客の問題を解決する新しい機会領域に拡大しながら解決していくのです。」 Amazon 自身のカスタマーサービスの課題を解決する内部プロジェクトから、Amazon Connect は 8 年間で数万の顧客に信頼されるグローバルサービスに進化しました。これは、まだ Day 1 です。この創造を促したときと変わらず、好奇心と顧客体験を変革する使命を持って、チームは問題を解決し顧客を喜ばせることを目的とした AI を活用したソリューションの開拓を続けています。 Amazon Connect の詳細については、 Amazon Connect ページ をご覧ください。 Amazon Connect でカスタマーサービスエクスペリエンスを変革する準備はできていますか？ お問い合わせください。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。原文は こちら です。

本記事では、Amazon Relational Database Service (Amazon RDS) for Db2 のトラブルシューティングで必要となる情報の収集方法をご紹介いたします。 2026 年 1 月 update : rdsadmin.db2support_command プロシージャの対応により、db2suppot の説明を追加 Linux、Unix、Windows 上で動作する IBM Db2 で収集していた情報を、Amazon RDS for Db2 ではどのように収集すれば良いか分からないという方もいらっしゃるのではないでしょうか。 あるいは、IBM サポートにお問い合わせいただいた際に「〜の情報を収集してください」と依頼され、どのように情報を収集すれば良いか分からないという方もいらっしゃるかもしれません。 今回は、IBM サポートから情報収集を求められた場合の情報の収集方法について、サンプルクエリ等を交えてご紹介していきます。 Amazon RDS for Db2 におけるサポート体制 はじめに、前提として Amazon RDS for Db2 のサポート体制についてご説明いたします。 Amazon RDS for Db2 では BYOL (Bring Your Own Licnece) モデルを採用しており、お困りの問題に応じて以下のサポートをご利用いただくことが可能です。 IBM サポート IBM Db2 LUW の動作に関するお問い合わせ(パフォーマンスの問題や、サービスリクエスト)は、 IBM サポート にお問い合わせください。 AWS サポート AWS サポートのアカウントをお持ちの場合、Amazon RDS 固有の問題については、 AWS サポート にお問い合わせください。 IBM サポートで必要となる情報 IBM サポートでトラブルシューティングを行う場合、主に以下の情報を求められる場合があります。 db2diag.log db2support コマンドにより取得されたファイル First Occurrence Data Capture(FODC) の情報 コアダンプファイル Amazon RDS for Db2 はマネージドサービスのため、Linux、Unix、Windows 上で動作する IBM Db2 では実行可能なコマンドや SQL クエリが一部制限されています。 これらの情報は マスターユーザーアカウント権限 を使用しても収集することができないため、代用手段を用いて情報を収集する必要があります。 以降、各項目の情報収集方法について説明します。 db2diag.log Amazon RDS for Db2 では、マネジメントコンソールから db2diag.log をダウンロードいただくことが可能です。 問題の発生状況が確認できるよう、問題が発生した日時の前後の記録を含む db2diag.log をダウンロードしてください。 db2diag.log はローテーションにより一定のサイズを超えると古いログが削除されてしまうため、過去の記録を遡って確認できるよう Amazon CloudWatch Logs へのエクスポートをお勧めします。 Amazon CloudWatch Logs にエクスポートされたログは、CloudWatch Logs Insights により検索条件の指定により必要なログのみを抽出できます。 抽出したログのみをファイルに保存することも可能です。 Amazon CloudWatch Logs、および CloudWatch Logs Insights の詳細については、 こちら をご覧ください。 db2support コマンドにより取得されたファイル RDS for Db2 でご利用いただけるユーザー権限では、 db2support コマンドを直接実行することができません。 db2support コマンドの実行、および db2support コマンドにより取得されたファイルを収集される場合は、 rdsadmin.db2support_command プロシージャ を実行してください。 なお、当該プロシージャを実行いただくと、Amazon Simple Storage Service (Amazon S3) にファイルが出力されます。 そのため、プロシージャ実行前に Amazon S3 統合を有効化いただく必要がございます。 Amazon S3 統合の有効化につきましては、 こちら をご覧ください。 First Occurrence Data Capture(FODC) の情報 db2support 同様、 First Occurrence Data Capture(FODC) の情報の収集についても、現時点ではお客様にて行えない操作となっています。 First Occurrence Data Capture(FODC) の情報が必要な場合は、AWS サポートまでお問い合わせください。 コアダンプファイル コアダンプファイルの取得は、現時点ではお客様にて行えない操作となっています。 コアダンプファイルの取得が必要な場合は、AWS サポート までお問い合わせください。 AWS サポートご利用時の Tips AWS サポート での情報収集をご依頼いただく場合のお問い合わせ IBM サポートへ既にお問い合わせ済みで、該当の情報の取得を依頼されている旨をご説明いただくことで、AWS サポート側でもスムーズなご案内が可能です。 例： ◯◯(発生している事象の概要) という問題が発生しており、原因を調査中です。 現在、IBM サポートへ問い合わせており、調査には ◯◯(コアダンプ 等)のデータを必要としております。 ◯◯のデータは、ユーザー側で取得ができない情報のため、AWS サポートにて取得、提供いただけますでしょうか。 適切な緊急度の選択 情報のご提供には、お時間が掛かってしまう場合があります。お急ぎの場合は、問題の影響度と発生しているビジネス影響を添えて、高い緊急度でのお問い合わせをご検討ください。 サポートケースの緊急度の考え方については、 こちら をご覧ください。 AWS サポートご利用時のガイドライン AWS サポートの基本的なガイドラインをご一読いただくことで、迅速なサポートが可能となります。 お問い合わせいただく際に、 こちら をご一読ください。 トラブルシューティングで必要となる情報、および情報収集の手段についてご紹介いたしました。 ご不明な点等ございましたら、お気軽に AWS サポート へお問い合わせください。 クラウドサポートエンジニア　松原 睦美

多くの企業は、保守と拡張が困難になった古いテクノロジーで構築されたレガシーシステムに悩まされています。 この投稿では、 Amazon Bedrock Converse APIと Amazon Nova Premier をagentic workflow内で使用して、レガシーCコードを最新のJava/Springフレームワークアプリケーションに体系的に移行する方法を紹介します。移行プロセスを複数の専門エージェントで分担し、堅牢なフィードバックループを実装することで、組織は以下を達成できます: 移行時間とコストの削減 – 自動化により反復的な変換タスクを処理し、人間のエンジニアは高付加価値作業に集中できます コード品質の向上 – 専門的な検証エージェントが、移行されたコードの最新のベストプラクティスへの準拠を保証します リスクの最小化 – 体系的なアプローチにより、移行中に重要なビジネスロジックの損失を防ぎます クラウド統合の実現 – 結果として得られるJava/SpringコードはAWSサービスとシームレスに統合できます 課題 レガシーシステムから最新のフレームワークへのコード移行には、AI機能と人間の専門知識を組み合わせたバランスの取れたアプローチを必要とするいくつかの重要な課題があります: 言語パラダイムの違い – CコードをJavaに変換するには、メモリ管理、エラー処理、プログラミングパラダイムの根本的な違いをナビゲートする必要があります。Cの手続き型の性質と直接的なメモリ操作は、Javaのオブジェクト指向アプローチと自動メモリ管理とは大きく対照的です。AIは多くの構文変換を自動的に処理できますが、開発者はこれらの変換の意味的正確性をレビューおよび検証する必要があります。 アーキテクチャの複雑性 – レガシーシステムには、人間の分析と計画を必要とするコンポーネント間の複雑な相互依存関係が含まれていることがよくあります。我々のケースでは、Cコードベースには、一部のTP(Transaction Program)が最大12の他のモジュールに接続されているなど、モジュール間の複雑な関係が含まれていました。人間の開発者は依存関係マッピングを作成し、移行順序を決定する必要があります。通常は依存関係が最小のリーフノードから移行を開始します。AIはこれらの関係を識別するのに役立ちますが、移行シーケンスに関する戦略的決定には人間の判断が必要です。 ビジネスロジックの維持 – 変換中に重要なビジネスロジックが正確に保持されることを確認するには、継続的な人間の監視が必要です。我々の分析では、自動移行はシンプルで構造化されたコードには非常に成功していますが、大きなファイル(700行以上)に埋め込まれた複雑なビジネスロジックには、エラーや欠落を防ぐために慎重な人間のレビューと手動での改良が必要であることが示されました。 一貫性のない命名と構造 – レガシーコードには、移行中に標準化する必要がある一貫性のない命名規則と構造が含まれていることがよくあります。AIは多くのルーチン変換(関数名の英数字IDの変換、C形式のエラーコードのJava例外への変換、C構造体のJavaクラスへの変換など)を処理できますが、人間の開発者は命名標準を確立し、自動変換が曖昧になる可能性のあるエッジケースをレビューする必要があります。 統合の複雑性 – 個々のファイルを変換した後、まとまりのあるアプリケーションを作成するには人間が主導する統合が不可欠です。元のCファイル全体で一貫していた変数名は、個々のファイル変換中に一貫性がなくなることが多く、開発者は調整作業を実行し、適切なモジュール間通信を促進する必要があります。 品質保証 – 変換されたコードが元のコードと機能的に同等であることを検証するには、自動テストと人間による検証の組み合わせが必要です。これは複雑なビジネスロジックにとって特に重要です。微妙な違いが重大な問題につながる可能性があります。開発者は包括的なテストスイートを設計し、徹底的なコードレビューを実行して移行の正確性を確保する必要があります。 これらの課題には、大規模言語モデル(LLM)のパターン認識機能と構造化ワークフローおよび重要な人間の監視を組み合わせて、成功した移行結果を生み出す体系的なアプローチが必要です。鍵となるのは、AIを使用してルーチン変換を処理しながら、戦略的決定、複雑なロジック検証、品質保証のために人間をループに留めることです。 ソリューション概要 このソリューションは、Amazon Bedrock Converse APIとAmazon Nova Premierを使用して、体系的なagentic workflowを通じてレガシーCコードを最新のJava/Springフレームワークコードに変換します。このアプローチは、複雑な移行プロセスを管理可能なステップに分割し、反復的な改良とトークン制限の処理を可能にします。 ソリューションアーキテクチャは、いくつかの主要なコンポーネントで構成されています: Code analysis agent – Cコードの構造と依存関係を分析します Conversion agent – CコードをJava/Springコードに変換します Security assessment agent – レガシーコードと移行されたコードの脆弱性を識別します Validation agent – 変換の完全性と正確性を検証します Refine agent – validation agentからのフィードバックに基づいてコードを書き直します Integration agent – 個別に変換されたファイルを結合します 我々のagentic workflowは、堅牢なエージェントオーケストレーションとLLM推論のためにAmazon Bedrock Converse APIと組み合わせたStrands Agentsフレームワークを使用して実装されています。アーキテクチャ(次の図に示すように)は、Strandsのセッション管理機能とトークン継続のためのカスタムBedrockInference処理を組み合わせたハイブリッドアプローチを使用しています。 このソリューションは、以下のコアテクノロジーを使用しています: Strands Agentsフレームワーク(v1.1.0+) – エージェントライフサイクル管理、セッション処理、構造化されたエージェント通信を提供します Amazon Bedrock Converse API – Amazon Nova PremierモデルでLLM推論を実行します カスタムBedrockInferenceクラス – テキスト事前入力とレスポンス継続によりトークン制限を処理します Asyncioベースのオーケストレーション – 並行処理とノンブロッキングエージェント実行を可能にします ワークフローは以下のステップで構成されています: 1. コード分析: Code analysis agent – 変換要件を理解するために入力コード分析を実行します。Cコードベース構造を調べ、依存関係を識別し、複雑性を評価します。 フレームワーク統合 – 分析にBedrockInferenceを使用しながら、セッション管理にStrandsを使用します。 出力 – 依存関係マッピングと変換推奨事項を含むJSON構造化分析。 2. ファイル分類とメタデータ作成: 実装 – 複雑性評価を含むFileMetadataデータクラス。 Categories – Simple(0-300行)、Medium(300-700行)、Complex(700行以上)。 File types – 標準Cファイル、ヘッダーファイル、データベースI/O(DBIO)ファイル。 3. コード変換: Conversion agent – code analysis agentからの情報に基づいて個々のファイルのコード移行を実行します。 Token handling – トークン制限を超える大きなファイルを処理するためにstitch_output()メソッドを使用します。 4. セキュリティ評価フェーズ: Security assessment agent – レガシーCコードと変換されたJavaコードの両方で包括的な脆弱性分析を実行します。 Risk categorization – セキュリティ問題を重大度(Critical、High、Medium、Low)で分類します。 Mitigation recommendations – 具体的なコード修正とセキュリティベストプラクティスを提供します。 Output – アクション可能な修復ステップを含む詳細なセキュリティレポート。 5. 検証とフィードバックループ: Validation agent – 変換の完全性と正確性を分析します。 Refine agent – 検証結果に基づいて反復的な改善を適用します。 Iteration control – 満足のいく結果が得られた場合の早期終了を伴う最大5回のフィードバック反復。 Session persistence – Strandsフレームワークは反復間で会話コンテキストを維持します。 6. 統合と最終化: Integration agent – 個別に変換されたファイルの結合を試みます。 Consistency resolution – 変数命名を標準化し、適切な依存関係を提供します。 Output generation – まとまりのあるJava/Springアプリケーション構造を作成します。 7. DBIO変換: Purpose – SQL DBIO CソースコードをMyBatis XMLマッパーファイルに変換します。 Framework – 一貫性のために同じStrandsとBedrockInferenceハイブリッドアプローチを使用します。 ソリューションは以下の主要なオーケストレーション機能で構成されています: Session persistence – 各変換はエージェント相互作用間でセッション状態を維持します Error recovery – グレースフルデグラデーションを伴う包括的なエラー処理 Performance tracking – 処理時間、反復回数、成功率の組み込みメトリクス Token continuation – レスポンススティッチングによる大きなファイルのシームレスな処理 このフレームワーク固有の実装により、多様なCコードベース構造と複雑性を処理する柔軟性を維持しながら、信頼性が高くスケーラブルなコード変換が促進されます。 前提条件 このコード変換ソリューションを実装する前に、以下のコンポーネントが設定されていることを確認してください: AWS環境: Amazon Nova Premierモデルへのアクセス権限を含む、適切なAmazon Bedrock権限を持つAWSアカウント 開発とテスト用の Amazon Elastic Compute Cloud (Amazon EC2)インスタンス(t3.medium以上)またはローカルマシン 開発セットアップ: Python 3.10以上(Boto3 SDK、Strands Agentsライブラリをインストール済み) AWS CLI (適切な認証情報とリージョン設定済み) Git(バージョン管理用) テキストエディタまたはIDE(CとJavaコード対応) ソースとターゲットコードベースの要件: 整理された構造のCソースコード Java 11以上とMaven/Gradleビルドツール Spring Framework 5.xまたはSpring Boot 2.x以上 この投稿で使用されているソースコードとプロンプトは、 GitHubリポジトリ にあります。 エージェントベースの変換プロセス このソリューションは、Strandsフレームワークを使用して実装された洗練されたマルチエージェントシステムを使用しており、各エージェントはコード変換プロセスの特定の側面を専門としています。この分業アプローチは、多様なコード構造と複雑性を処理する柔軟性を維持しながら、徹底的な分析、正確な変換、包括的な検証を可能にします。 Strandsフレームワーク統合 各エージェントはBaseStrandsConversionAgentクラスを拡張し、Strandsセッション管理とカスタムBedrockInference機能を組み合わせたハイブリッド構成で実装しています: class BaseStrandsConversionAgent(ABC): def __init__(self, name: str, bedrock_inference, system_prompt: str): self.name = name self.bedrock = bedrock_inference # トークン処理のためのカスタムBedrockInference self.system_prompt = system_prompt # セッション管理のためのstrands agentを作成 self.strands_agent = Agent(name=name, system_prompt=system_prompt) async def execute_async(self, context: ConversionContext) -&gt; Dict[str, Any]: # 各専門エージェントによって実装される pass Code analysis agent Code analysis agentは、Cコードベースの構造を調べ、ファイル間の依存関係を識別し、最適な変換戦略を決定します。このエージェントは、最初に変換するファイルに優先順位を付け、潜在的な課題を識別するのに役立ちます。 以下は、code analysis agentのプロンプトテンプレートです: You are a Code Analysis Agent with expertise in legacy C codebases and modern Java/Spring architecture. &lt;c_codebase&gt; {c_code} &lt;/c_codebase&gt; ## TASK Your task is to analyze the provided C code to prepare for migration. Perform a comprehensive analysis and provide the following: ## INSTRUCTIONS 1. DEPENDENCY ANALYSIS: - Identify all file dependencies (which files include or reference others) - Map function calls between files - Detect shared data structures and global variables 2. COMPLEXITY ASSESSMENT: - Categorize each file as Simple (0-300 lines), Medium (300-700 lines), or Complex (700+ lines) - Identify files with complex control flow, pointer manipulation, or memory management - Flag any platform-specific or hardware-dependent code 3. CONVERSION PLANNING: - Recommend a conversion sequence (which files to convert first) - Suggest logical splitting points for large files - Identify common patterns that can be standardized during conversion 4. RISK ASSESSMENT: - Highlight potential conversion challenges (e.g., pointer arithmetic, bitwise operations) - Identify business-critical sections requiring special attention - Note any undocumented assumptions or behaviors 5. ARCHITECTURE RECOMMENDATIONS: - Suggest appropriate Java/Spring components for each C module - Recommend DTO structure and service organization - Propose database access strategy using a persistence framework Format your response as a structured JSON document with these sections. Conversion agent Conversion agentは、CコードからJava/Springコードへの実際の変換を処理します。このエージェントには、CとJava/Springフレームワークの両方の専門知識を持つシニアソフトウェア開発者の役割が割り当てられています。 Conversion agentのプロンプトテンプレートは以下の通りです: You are a Senior Software Developer with 15+ years of experience in both C and Java Spring framework. &lt;c_file&gt; {c_code} &lt;/c_file&gt; ## TASK Your task is to convert legacy C code to modern Java Spring code with precision and completeness. ## CONVERSION GUIDELINES: 1. CODE STRUCTURE: - Create appropriate Java classes (Service, DTO, Mapper interfaces) - Preserve original function and variable names unless they conflict with Java conventions - Use Spring annotations appropriately (@Service, @Repository, etc.) - Implement proper package structure based on functionality 2. JAVA BEST PRACTICES: - Use Lombok annotations (@Data, @Slf4j, @RequiredArgsConstructor) to reduce boilerplate - Implement proper exception handling instead of error codes - Replace pointer operations with appropriate Java constructs - Convert C-style arrays to Java collections where appropriate 3. SPRING FRAMEWORK INTEGRATION: - Use dependency injection instead of global variables - Implement a persistence framework mappers for database operations - Replace direct SQL calls with mapper interfaces - Use Spring's transaction management 4. SPECIFIC TRANSFORMATIONS: - Replace PFM_TRY/PFM_CATCH with Java try-catch blocks - Convert mpfmdbio calls to a persistence framework mapper method calls - Replace mpfm_dlcall with appropriate Service bean injections - Convert NGMHEADER references to input.getHeaderVo() calls - Replace PRINT_ and PFM_DBG macros with SLF4J logging - Convert ngmf_ methods to CommonAPI.ngmf method calls 5. DATA HANDLING: - Create separate DTO classes for input and output structures - Use proper Java data types (String instead of char arrays, etc.) - Implement proper null handling and validation - Remove manual memory management code ## OUTPUT FORMAT: - Include filename at the top of each Java file: #filename: [filename].java - Place executable Java code inside &lt;java&gt;&lt;/java&gt; tags - Organize multiple output files clearly with proper headers Generate complete, production-ready Java code that fully implements all functionality from the original C code. Security assessment agent Security assessment agentは、元のCコードと変換されたJavaコードの両方で包括的な脆弱性分析を実行し、潜在的なセキュリティリスクを識別し、具体的な緩和戦略を提供します。このエージェントは、移行中にセキュリティの脆弱性が持ち越されないようにし、新しいコードがセキュリティのベストプラクティスに従っていることを確認するために不可欠です。 以下は、security assessment agentのプロンプトテンプレートです: You are a Security Assessment Agent with expertise in identifying vulnerabilities in both C and Java codebases, specializing in secure code migration practices. ORIGINAL C CODE: &lt;c_code&gt; {c_code} &lt;/c_code&gt; CONVERTED JAVA CODE: &lt;java_code&gt; {java_code} &lt;/java_code&gt; ## TASK Your task is to perform comprehensive security analysis on both the legacy C code and converted Java code, identifying vulnerabilities and providing specific mitigation recommendations. ## SECURITY ANALYSIS FRAMEWORK 1. **LEGACY C CODE VULNERABILITIES:** - Buffer overflow risks (strcpy, strcat, sprintf usage) - Memory management issues (dangling pointers, memory leaks) - Integer overflow/underflow vulnerabilities - Format string vulnerabilities - Race conditions in multi-threaded code - Improper input validation and sanitization - SQL injection risks in database operations - Insecure cryptographic implementations 2. **JAVA CODE SECURITY ASSESSMENT:** - Input validation and sanitization gaps - SQL injection vulnerabilities in persistence framework queries - Improper exception handling that leaks sensitive information - Authentication and authorization bypass risks - Insecure deserialization vulnerabilities - Cross-site scripting (XSS) prevention in web endpoints - Logging of sensitive data - Dependency vulnerabilities in Spring framework usage 3. **MIGRATION-SPECIFIC RISKS:** - Security assumptions that don't translate between languages - Privilege escalation through improper Spring Security configuration - Data exposure through overly permissive REST endpoints - Session management vulnerabilities - Configuration security (hardcoded credentials, insecure defaults) 4. **COMPLIANCE AND BEST PRACTICES:** - OWASP Top 10 compliance assessment - Spring Security best practices implementation - Secure coding standards adherence - Data protection and privacy considerations ## OUTPUT FORMAT Provide your analysis as a structured JSON with these fields: - "critical_vulnerabilities": array of critical security issues requiring immediate attention - "security_risk_issues": array of security concerns - "secure_code_recommendations": specific code changes to implement security fixes - "spring_security_configurations": recommended Spring Security configurations - "compliance_gaps": areas where code doesn't meet security standards - "migration_security_notes": security considerations specific to the C-to-Java migration For each vulnerability, include: - Description of the security risk - Potential impact and attack vectors - Specific line numbers or code sections affected - Detailed remediation steps with code examples - Priority level and recommended timeline for fixes Be thorough in identifying both obvious and subtle security issues that could be exploited in production environments. Validation agent Validation agentは、変換されたコードをレビューして、欠落または不正に変換されたコンポーネントを識別します。このエージェントは、後続の変換反復で使用される詳細なフィードバックを提供します。 Validation agentのプロンプトテンプレートは以下の通りです: You are a Code Validation Agent specializing in verifying C to Java/Spring migrations. ORIGINAL C CODE: &lt;c_code&gt; {c_code} &lt;/c_code&gt; CONVERTED JAVA CODE: &lt;java_code&gt; {java_code} &lt;/java_code&gt; ## TASK Your task is to thoroughly analyze the conversion quality and identify any issues or omissions. Perform a comprehensive validation focusing on these aspects: ## INSTRUCTIONS 1. COMPLETENESS CHECK: - Verify all functions from C code are implemented in Java - Confirm all variables and data structures are properly converted - Check that all logical branches and conditions are preserved - Ensure all error handling paths are implemented 2. CORRECTNESS ASSESSMENT: - Identify any logical errors in the conversion - Verify proper transformation of C-specific constructs (pointers, structs, etc.) - Check for correct implementation of memory management patterns - Validate proper handling of string operations and byte manipulation 3. SPRING FRAMEWORK COMPLIANCE: - Verify appropriate use of Spring annotations and patterns - Check proper implementation of dependency injection - Validate correct use of persistence framework mappers - Ensure proper service structure and organization 4. CODE QUALITY EVALUATION: - Assess Java code quality and adherence to best practices - Check for proper exception handling - Verify appropriate logging implementation - Evaluate overall code organization and readability ## OUTPUT FORMAT Provide your analysis as a structured JSON with these fields: - "complete": boolean indicating if conversion is complete - "missing_elements": array of specific functions, variables, or logic blocks that are missing - "incorrect_transformations": array of elements that were incorrectly transformed - "spring_framework_issues": array of Spring-specific implementation issues - "quality_concerns": array of code quality issues - "recommendations": specific, actionable recommendations for improvement Be thorough and precise in your analysis, as your feedback will directly inform the next iteration of the conversion process. Refine agentによるフィードバックループの実装 フィードバックループは、変換されたコードの反復的な改良を可能にする重要なコンポーネントです。このプロセスには以下のステップが含まれます: Conversion agentによる初期変換。 Security assessment agentによるセキュリティ評価。 Validation agentによる検証。 Refine agentによるフィードバックの組み込み(検証とセキュリティの両方のフィードバックを組み込む)。 満足のいく結果が得られるまで繰り返す。 Refine agentは、機能的な改善とともにセキュリティの脆弱性修正を組み込み、セキュリティ評価結果は本番デプロイメント前の最終レビューと承認のために開発チームに提供されます。 以下は、コード改良のためのプロンプトテンプレートです: You are a Senior Software Developer specializing in C to Java/Spring migration with expertise in secure coding practices. ORIGINAL C CODE: &lt;c_code&gt; {c_code} &lt;/c_code&gt; YOUR PREVIOUS JAVA CONVERSION: &lt;previous_java&gt; {previous_java_code} &lt;/previous_java&gt; VALIDATION FEEDBACK: &lt;validation_feedback&gt; {validation_feedback} &lt;/validation_feedback&gt; SECURITY ASSESSMENT: &lt;security_feedback&gt; {security_feedback} &lt;/security_feedback&gt; ## TASK You've previously converted C code to Java, but validation and security assessment have identified issues that need to be addressed. Your task is to improve the conversion by addressing all identified functional and security issues while maintaining complete functionality. ## INSTRUCTIONS 1. ADDRESSING MISSING ELEMENTS: - Implement any functions, variables, or logic blocks identified as missing - Ensure all control flow paths from the original code are preserved - Add any missing error handling or edge cases 2. CORRECTING TRANSFORMATIONS: - Fix any incorrectly transformed code constructs - Correct any logical errors in the conversion - Properly implement C-specific patterns in Java 3. IMPLEMENTING SECURITY FIXES: - Address all critical and high-risk security vulnerabilities identified - Implement secure coding practices (input validation, parameterized queries, etc.) - Replace insecure patterns with secure Java/Spring alternatives - Add proper exception handling that does not leak sensitive information 4. IMPROVING SPRING IMPLEMENTATION: - Correct any issues with Spring annotations or patterns - Ensure proper dependency injection and service structure - Fix persistence framework mapper implementations if needed - Implement Spring Security configurations as recommended 5. MAINTAINING CONSISTENCY: - Ensure naming conventions are consistent throughout the code - Maintain consistent patterns for similar operations - Preserve the structure of the original code where appropriate ## OUTPUT FORMAT Output the improved Java code inside &lt;java&gt;&lt;/java&gt; tags, with appropriate file headers. Ensure all security vulnerabilities are addressed while maintaining complete functionality from the original C code. Integration agent Integration agentは、個別に変換されたJavaファイルをまとまりのあるアプリケーションに結合し、変数命名の不整合を解決し、適切な依存関係を提供します。 Integration agentのプロンプトテンプレートは以下の通りです: You are an Integration Agent specializing in combining individually converted Java files into a cohesive Spring application. CONVERTED JAVA FILES: &lt;converted_files&gt; {converted_java_files} &lt;/converted_files&gt; ORIGINAL FILE RELATIONSHIPS: &lt;relationships&gt; {file_relationships} &lt;/relationships&gt; ## TASK Your task is to integrate multiple Java files that were converted from C, ensuring they work together properly. Perform the following integration tasks: ## INSTRUCTIONS 1. DEPENDENCY RESOLUTION: - Identify and resolve dependencies between services and components - Ensure proper autowiring and dependency injection - Verify that service method signatures match their usage across files 2. NAMING CONSISTENCY: - Standardize variable and method names that should be consistent across files - Resolve any naming conflicts or inconsistencies - Ensure DTO field names match across related classes 3. PACKAGE ORGANIZATION: - Organize classes into appropriate package structure - Group related functionality together - Ensure proper import statements across all files 4. SERVICE COMPOSITION: - Implement proper service composition patterns - Ensure services interact correctly with each other - Verify that data flows correctly between components 5. COMMON COMPONENTS: - Extract and standardize common utility functions - Ensure consistent error handling across services - Standardize logging patterns 6. CONFIGURATION: - Create necessary Spring configuration classes - Set up appropriate bean definitions - Configure any required properties or settings Output the integrated Java code as a set of properly organized files, each with: - Appropriate package declarations - Correct import statements - Proper Spring annotations - Clear file headers (#filename: [filename].java) Place each file's code inside &lt;java&gt;&lt;/java&gt; tags. Ensure the integrated application maintains all functionality from the individual components while providing a cohesive structure. DBIO conversion agent この専門エージェントは、SQL DBIO CソースコードをJava Springフレームワークのpersistence framework互換のXMLファイルに変換する処理を行います。 以下は、DBIO conversion agentのプロンプトテンプレートです: You are a Database Integration Specialist with expertise in converting C-based SQL DBIO code to persistence framework XML mappings for Spring applications. SQL DBIO C SOURCE CODE: &lt;sql_dbio&gt; {sql_dbio_code} &lt;/sql_dbio&gt; ## TASK Your task is to transform the provided SQL DBIO C code into properly structured persistence framework XML files. Perform the conversion following these guidelines: ## INSTRUCTIONS 1. XML STRUCTURE: - Create a properly formatted persistence framework mapper XML file - Include appropriate namespace matching the Java mapper interface - Set correct resultType or resultMap attributes for queries - Use proper persistence framework XML structure and syntax 2. SQL TRANSFORMATION: - Preserve the exact SQL logic from the original code - Convert any C-specific SQL parameter handling to persistence framework parameter markers - Maintain all WHERE clauses, JOIN conditions, and other SQL logic - Preserve any comments explaining SQL functionality 3. PARAMETER HANDLING: - Convert C variable bindings to persistence framework parameter references (#{param}) - Handle complex parameters using appropriate persistence framework techniques - Ensure parameter types match Java equivalents (String instead of char[], etc.) 4. RESULT MAPPING: - Create appropriate resultMap elements for complex result structures - Map column names to Java DTO property names - Handle any type conversions needed between database and Java types 5. DYNAMIC SQL: - Convert any conditional SQL generation to persistence framework dynamic SQL elements - Use &lt;if&gt;, &lt;choose&gt;, &lt;where&gt;, and other dynamic elements as appropriate - Maintain the same conditional logic as the original code 6. ORGANIZATION: - Group related queries together - Include clear comments explaining the purpose of each query - Follow persistence framework best practices for mapper organization ## OUTPUT FORMAT Output the converted persistence framework XML inside &lt;xml&gt;&lt;/xml&gt; tags. Include a filename comment at the top: #filename: [EntityName]Mapper.xml Ensure the XML is well-formed, properly indented, and follows persistence framework conventions for Spring applications. トークン制限の処理 Amazon Bedrock Converse APIのトークン制限に対処するために、モデルが中断したところからコード生成を続行できる継続生成機能を実装しました。このアプローチは、モデルのコンテキストウィンドウを超える大きなファイルにとって特に重要であり、Strandsベースの実装における重要な技術的工夫を表しています。 技術実装 以下のコードは、継続生成機能を持つBedrock Inferenceクラスを実装しています: class BedrockInference: def __init__(self, region_name: str = "us-east-1", model_id: str = "us.amazon.nova-premier-v1:0"): self.config = Config(read_timeout=300) self.client = boto3.client("bedrock-runtime", config=self.config, region_name=region_name) self.model_id = model_id self.continue_prompt = { "role": "user", "content": [{"text": "Continue the code conversion from where you left off."}] } def run_converse_inference_with_continuation(self, prompt: str, system_prompt: str) -&gt; List[str]: """大きな出力の継続処理で推論を実行""" ans_list = [] messages = [{"role": "user", "content": [{"text": prompt}]}] response, stop = self.generate_conversation([{'text': system_prompt}], messages) ans = response['output']['message']['content'][0]['text'] ans_list.append(ans) while stop == "max_tokens": logger.info("Response truncated, continuing generation...") messages.append(response['output']['message']) messages.append(self.continue_prompt) # 継続コンテキストのために最後の数行を抽出 sec_last_line = '\n'.join(ans.rsplit('\n', 3)[1:-1]).strip() messages.append({"role": "assistant", "content": [{"text": sec_last_line}]}) response, stop = self.generate_conversation([{'text': system_prompt}], messages) ans = response['output']['message']['content'][0]['text'] del messages[-1] # 事前入力メッセージを削除 ans_list.append(ans) return ans_list 継続戦略の詳細 継続戦略は以下のステップで構成されています: 1. レスポンス監視: システムはAmazon BedrockレスポンスのstopReasonフィールドを監視します。 stopReasonがmax_tokensに等しい場合、継続が自動的にトリガーされます。これにより、トークン制限によるコード生成の損失を防ぎます。 2. コンテキストの保持: システムは生成されたコードの最後の数行を継続コンテキストとして抽出します。 テキスト事前入力を使用してコード構造とフォーマットを維持します。継続間で変数名、関数シグネチャ、コードパターンを保持します。 3. レスポンスのスティッチング: def stitch_output(self, prompt: str, system_prompt: str, tag: str = "java") -&gt; str: """複数のレスポンスを結合し、指定されたタグ内のコンテンツを抽出""" ans_list = self.run_converse_inference_with_continuation(prompt, system_prompt) if len(ans_list) == 1: final_ans = ans_list[0] else: final_ans = ans_list[0] for i in range(1, len(ans_list)): # オーバーラップを削除してレスポンスをシームレスに結合 final_ans = final_ans.rsplit('\n', 1)[0] + ans_list[i] # 指定されたタグ(java、xmlなど)内のコンテンツを抽出 if f'&lt;{tag}&gt;' in final_ans and f'&lt;/{tag}&gt;' in final_ans: final_ans = final_ans.split(f'&lt;{tag}&gt;')[-1].split(f'&lt;/{tag}&gt;')[0].strip() return final_ans 変換品質の最適化 実験を通じて、変換品質に大きく影響するいくつかの要因を特定しました: ファイルサイズ管理 – 300行を超えるコードファイルは、変換前に小さな論理単位に分割することで効果が向上します。 集中変換 – 異なるファイルタイプ(C、ヘッダー、DBIO)を個別に変換すると、各ファイルタイプが異なる変換パターンを持つため、より良い結果が得られます。変換中、C関数はクラス内のJavaメソッドに変換され、C構造体はJavaクラスになります。ただし、ファイルはクロスファイルコンテキストなしで個別に変換されるため、最適なオブジェクト指向設計を達成するには、関連する機能の統合、適切なクラス階層の確立、変換されたコードベース全体での適切なカプセル化を促進するために人間の介入が必要になる場合があります。 反復的な改良 – 複数のフィードバックループ(4〜5回の反復)により、より包括的な変換が生成されます。 役割の割り当て – モデルに特定の役割(シニアソフトウェア開発者)を割り当てると、出力品質が向上します。 詳細な指示 – 一般的なパターンに対する具体的な変換ルールを提供すると、一貫性が向上します。 前提条件 この移行戦略は以下の主要な前提条件を設けています: コード品質 – レガシーCコードは、識別可能な構造を持つ合理的なコーディング慣行に従っています。難読化された、または構造が不十分なコードは、自動変換前に前処理が必要になる場合があります。 スコープの制限 – このアプローチは、低レベルのシステムコードではなく、ビジネスロジックの変換を対象としています。ハードウェアとの相互作用やプラットフォーム固有の機能を持つCコードには、手動介入が必要になる場合があります。 テストカバレッジ – 移行後の機能的同等性を検証するための包括的なテストケースがレガシーアプリケーションに存在します。十分なテストがない場合、追加の検証ステップが必要です。 ドメイン知識 – agentic workflowはCとJavaの両方の専門知識の必要性を軽減しますが、重要なビジネスロジックの保持を検証するためにビジネスドメインを理解する主題専門家へのアクセスが必要です。 段階的移行 – このアプローチは、コンポーネントを個別に変換および検証できる段階的な移行戦略が許容されることを前提としており、プロジェクト全体レベルの移行ではありません。 結果とパフォーマンス Amazon Nova Premierを活用した移行アプローチの有効性を評価するために、典型的な顧客シナリオを代表するエンタープライズグレードのコードベース全体でパフォーマンスを測定しました。評価は2つの成功要因に焦点を当てました:構造的完全性(すべてのビジネスロジックと機能の保持)とフレームワーク準拠(Spring Bootのベストプラクティスと規約への準拠)。 コードベースの複雑性による移行精度 agentic workflowは、ファイルの複雑性に基づいて異なる効果を示し、すべての結果は主題専門家によって検証されました。以下の表は結果をまとめたものです。 ファイルサイズカテゴリ 構造的完全性 フレームワーク準拠 平均処理時間 Small(0-300行) 93% 100% 30〜40秒 Medium(300-700行) 81%* 91%* 7分 Large(700行以上) 62%* 84%* 21分 *複数のフィードバックサイクル後 エンタープライズ導入のための主要な洞察 これらの結果は重要なパターンを明らかにしています:agenticアプローチは、移行作業の大部分(小〜中規模ファイル)の処理に優れており、人間の監視を必要とする複雑なファイルに対しても依然として大きな価値を提供します。これにより、AIがルーチン変換とセキュリティ評価を処理し、開発者が統合とアーキテクチャの決定に集中するハイブリッドアプローチが実現します。 結論 我々のソリューションは、agentic workflow内で実装されたAmazon Bedrock Converse APIとAmazon Nova Premierが、レガシーCコードを最新のJava/Springフレームワークコードに効果的に変換できることを実証しています。このアプローチは複雑なコード構造を処理し、トークン制限を管理し、最小限の人間の介入で高品質の変換を生成します。 このソリューションは、変換プロセスを専門のエージェントロールに分割し、堅牢なフィードバックループを実装し、継続技術によりトークン制限を処理します。このアプローチは移行プロセスを加速し、コード品質を向上させ、エラーの可能性を減らします。 独自のユースケースでソリューションを試し、コメントでフィードバックと質問を共有してください。 著者について 余 錦澤 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Applied Scientist 木田 悠歩 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Deep Learning Architect 劉 雪峰 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Senior Data Science Manager Aditya Prakash AWS Generative AI Innovation Center，Senior Data Scientist Yash Shah AWS Generative AI Innovation Center，Science Manager