TECH PLAY

AWS

AWS の技術ブログ

å…š3251ä»¶

(「 うったたがった 」は非垞に驚くずいう熊本匁です) 2026幎 1 月、 ANGEL Dojo 2025 で内補化に挑戊された熊本䞭倮病院様 を蚪問したした。その目的は2぀です。電子カルテ利甚端末からAWSぞ接続するためのネットワヌク蚭定を完了するこず、そしお電子カルテからドラむバを䜿甚し SQL でデヌタを抜出できるこずの確認です。いずれも ANGEL Dojo で構築した生成AIシステムを実際に院内で利甚するために䞍可欠な工皋でした。結果ずしお 1日目に環境構築を完了し、勢いそのたたに2日目にはハンズオンを実斜 。医垫、看護垫、医療事務など様々な職皮から午前ず午埌䜵せ 50 名以䞊が参加され、終了埌のアンケヌトでは5名以䞊が「院内の生成AI掚進リヌダヌになりたい」ず手を挙げお頂きたした。 病院での生成AI掻甚では SaaS の導入を契玄するむメヌゞが匷いかもしれたせん。SaaSの利䟿性は高いものの、特定機胜に特化しおおり文曞䜜成やシフト䜜成などそれぞれのツヌルを導入するずコストや管理が課題ずなりたす。今回構築した環境は、院内からのクラりド接続を可胜にするispec様のネットワヌク機噚 CloudSail ず AWS を組み合わせた自由床の高い環境であり、費甚も䜿甚量によるものの月額数䞇からず特別な倧芏暡投資は䞍芁です。技術面でも、ispec様たたANGEL Dojo に参加いただいた株匏䌚瀟アンチパタヌン様の支揎により 2 日ずいう短期間で構築を進めるこずが出来たした。「高い」「難しい」ずいう生成AI導入のむメヌゞは、もはや過去のものになり぀぀ありたす。 では、なぜ倚くの病院で生成AI掻甚が進たないのか。蚪問を通じお感じたのは、技術やコストよりも「組織の本気床」が成吊を分けるずいうこずでした。自治䜓病院の8〜9割が赀字ず蚀われる䞭、熊本䞭倮病院様は黒字経営を続けおいたす。院長をはじめ組織党䜓に「より良くなろう」ずいう意志が満ちおおり、50名以䞊のハンズオン参加、5名以䞊のリヌダヌ候補ずいう数字にそれが衚れおいたした。本ブログでは、生成 AI の掻甚が病院ずいう実地で始たるたでの課題ず解決策、その背景にある組織力に぀いおお䌝えしたす。 生成AI導入を阻む「2぀の壁」 先にご玹介した通り、熊本䞭倮病院様はANGEL Dojo 2025で医療文曞䜜成時間の削枛に取り組たれ、䞭間発衚では投祚1䜍を獲埗されたした。90 日のプログラム期間内で AWS パヌトナヌ様ず生成AIを掻甚した文曞䜜成支揎システムを構築し、月800時間の効率化が芋蟌めるこずを確認されおいたす。 しかし、ANGEL Dojoで構築したシステムを実際の院内環境で皌働させるには、2぀の壁がありたした。 1぀目は、電子カルテ端末からクラりドぞの安党な接続です。 医療情報ガむドラむンに準拠したセキュアなネットワヌク環境を構築する必芁がありたした。病院内のネットワヌクは閉域網ずしお運甚されおおり、倖郚のクラりドサヌビスに接続するには専甚の仕組みが必芁でした。 2぀目は、電子カルテからのデヌタ抜出です。 生成AIで医療文曞を䜜成するには、電子カルテに蓄積された患者情報を適切に取埗する必芁がありたす。電子カルテ偎の操䜜では患者情報を時系列か぀暪断的に取埗するこずが困難で、退院サマリ等に欠かせない情報を統合的に埗るには電子カルテベンダヌが提䟛するドラむバを䜿っおデヌタを抜出する必芁がありたした。 これらは技術的に解決䞍可胜な課題ではありたせん。しかし、電子カルテベンダヌずの調敎も必芁であり解決策の暡玢に時間を芁しおいたした。ANGEL Dojoの成果を実際の医療珟堎で掻かすためには、これらの壁を越えるパヌトナヌずの協力が䞍可欠でした。 壁を越えるパヌ トナヌずの出䌚い 転機ずなったのは、2025幎11月に開催された 医療情報孊連合倧䌚 でした。 AWSの展瀺ブヌスでANGEL Dojoにおける䞡病院の取り組みを玹介しおいたずころ、倚くの方から関心をいただきたした。同時に、倧䌚ずいう倚くの関係者が集う堎を掻かし私達は次のステップに䞍可欠な゜リュヌションやパヌトナヌずの匕き合わせを実斜したした。その䞭で出䌚ったのが、ispec様の CloudSail です。 CloudSailは、病院内ネットワヌクずクラりドサヌビスをセキュアに接続できる゜リュヌションです。院内の通信を閉域に保ち぀぀、倖郚ぞのリク゚ストに぀いおは CloudSail がプロキシずしおリク゚ストを代行するこずで安党な通信を実珟する仕組みに熊本䞭倮病院様も匷い関心を持たれおいたした。ispec様はデゞタル庁暙準型電子カルテのプロダクトワヌキンググルヌプに参加された経隓もあり、医療分野での知芋も豊富です。 ANGEL Dojoを通じお「自分達自身で適切なパヌトナヌを芋぀け、遞べる力」が培われおいたこずもこの出䌚いを䞻䜓的に刀断し掻甚する力になったず考えおいたす。 2日間の蚪問で実斜したこず 熊本䞭倮病院様の蚪問で実斜した内容は以䞋の通りです。 1日目環境構築 ネットワヌク蚭定 ispec様のCloudSail機噚を䜿甚し、電子カルテ利甚端末からAWS䞊の生成 AI アプリケヌションぞの接続環境を構築したした。事前に機噚を病院ぞ送付しおおくこずで、圓日のリスクを最小限に抑える工倫をしたした。ispec様にも珟地でサポヌトいただき、蚭定䜜業をスムヌズに進めるこずができたした。アプリケヌション利甚時にブラりザのバヌゞョンに起因し適切に動䜜しない課題がありたしたが、最新版のブラりザを別途導入頂き䜿い分けお頂くこずで察応できたした。 デヌタ抜出確認 電子カルテベンダヌ様より提䟛頂いたドラむバを䜿甚し、電子カルテからのデヌタ抜出が正垞に行えるこずを確認したした。 トラブルが党くなかったわけではありたせん。しかし、事前準備を入念に行っおいたこず、なにより熊本䞭倮病院様の担圓の方に珟堎で柔軟に察応いただいたこずで、1日目のうちに環境構築を完了するこずができたした。 2日目ハンズオン 環境が敎った翌日、早速ハンズオンを実斜したした。午前・午埌の2回に分けお開催し、医垫、看護垫、医療事務など様々な職皮から50名以䞊が参加されたした。 ハンズオンでは、1 日目で実際にセットアップした端末を䜿っお生成AIの基本的な䜿い方から実務課題ぞの応甚たで実践いただきたした。プロンプトの曞き方ず生成 AI による改善方法、画像・音声の入力方法を基瀎知識ずしおお䌝えした埌、実際の業務課題をテヌマに挔習圢匏で実践いただける構成ずしたした。 参加者の方からは「なかなかむメヌゞが぀かなかったが、今回初めおできそうなこずが芋えたので、良かったです。」「業務の効率化に向けた取り組みには倧倉興味があり、スタッフずできるこずを考えおいきたいずいった声をいただきたした。たた䞻な生成AIの利甚ニヌズずしおは、退院サマリヌ・看護サマリヌ関連を垌望する声が最も倚く、他にも勀務衚䜜成や請求関連業務での効率化等様々な面での掻甚甚途があげられたした。そしお、ハンズオン終了埌のアンケヌトでは、5名以䞊が「院内の生成AI掚進リヌダヌになりたい」ず手を挙げられたした。 黒字経営を続ける組織に芋たもの  2日間の蚪問を通じお、匷く印象に残ったこずがありたす。 自治䜓病院の8〜9割が赀字ず報道される䞭、熊本䞭倮病院様は黒字経営を続けおいたす。その理由の䞀端を、今回の蚪問で垣間芋た気がしたした。 50名以䞊のハンズオン参加。 病院の業務は倚忙を極めるため、ハンズオンぞの参加は数名ず予枬しおいたのですが、1 週間ほどずいう短い告知期間にもかかわらず、医垫、看護垫、医療事務など倚職皮から倚くの方が参加されたした。あたりの熱意に、1 日目セットアップを始める前にも今回の取り組みに぀いお聞きたいずいう方向けにお話をさせお頂きたした。この人数の芏暡から、組織党䜓ずしお忙しい䞭でも「孊びたい」「掻甚したい」ず熱意を持぀方が倚いこずを実感したした。 5名以䞊がリヌダヌに手を挙げた。 生成AIの院内掻甚を進めおいくためのリヌダヌを募ったずころ、耇数名が自ら手を挙げられたした。指名ではなく、自発的にです。新しい取り組みを「誰かがやっおくれる」のではなく「自分がやる」ずいう姿勢が組織に根付いおいるのだず感じたした。 院長をはじめずしたリヌダヌシップ。 ANGEL Dojoぞの参加も、院長自らが匷い意欲を瀺されたこずがきっかけでした。トップが本気で取り組む姿勢を芋せるこずで、組織党䜓のモチベヌションが高たる。圓たり前のようで、実践できる組織は倚くありたせん。今回も、院長はハンズオンに自ら参加し職員の方ずコミュニケヌションを取られおいたした。 病院の組織力ずいう土台があるからこそ、今回の 2 日間でセットアップずハンズオンを含め有意矩な結果を残すこずが出来たのだず感じおいたす。熊本䞭倮病院様からは次に向けた展望を次のように語っおいただいおいたす たずは、退院時サマリヌや看護サマリヌの自動生成を出発点に、 地方からAI掻甚が暙準化された医療の実珟を目指したす。 地方病院が持぀可胜性 熊本䞭倮病院様では、環境・䜓制共に生成 AI 掻甚のキックオフができたした。振り返るず、「やらなければならないこず」を着実に進めた結果でもありたす。 内補化ぞのチャレンゞを通じ、システムで䜕がどの皋床のコストでできるかを理解した チャレンゞを進める䞭で信頌できるパヌトナヌを埗た トップを含め組織党䜓でチャレンゞを掚進した 生成 AI により技術的な質問も実装も迅速か぀䜎コストで行えるようになっおきおいる䞭で、いずれもやろうず思えばできるこずです。地方病院だから、䞭小芏暡だからできない、ずいう理由はありたせん。今埌 50 幎、100 幎ずいうスパンで地域に信頌される医療を維持しおいくには、今たさに「やらなければならないこず」をできるかが問われおいたす。AWS では、AWS パヌトナヌ様ず共にそのチャレンゞを支えたす。
本蚘事は 2025/10/13 に公開された “ Transforming the physical world with AI: the next frontier in intelligent automation | Artificial Intelligence ” を翻蚳したものです。 昚今の人工知胜ず物理のシステムの統合は、技術的進化の重芁な転換点ずなっおいたす。特にフィゞカル AI は、アルゎリズムがデゞタルの境界を超え、圢のある物理䞖界を認識し、理解し、たた操䜜したす。そのためフィゞカル AI は、各業界の䌁業で、運営方針を根本的に倉えるものになりたす。これらの人工知胜のシステムは、デゞタルの情報ず物理的珟実の間のギャップを埋め、効率性ずむノベヌションをもたらす前䟋のないほど倧きな機䌚ずなりたす。倚くの組織にずっおは、このこずは顧客満足を向䞊させる斬新な方法ずなり、結果ずしお、党おの業界を倉革するこずになりたす。 この倉革を加速するため、AWS Generative AI Innovation Center は、MassRobotics ずNVIDIA ず協業し、 Physical AI Fellowship を立ち䞊げたした。これにより、次䞖代のロボティクスず自動化゜リュヌションを開発しおいるスタヌトアップが、必芁なサポヌトを享受するこずが可胜になり、先端を進むスタヌトアップずの協力ができるようになりたした。以䞋はそのリストです。 Bedrock Robotics – 既存の建築業のシステム矀に、自埋性を远加提䟛するためのハヌドりェアず゜フトりェアを、1日でむンストヌルするこずを可胜にしたす Blue Water Autonomy – ハヌドりェア、゜フトりェア、AI を統合しお、無人の船が長期間にわたり、倖掋での運航を行うこずを可胜にしたす Diligent Robotics – 動的で人間ず察面する状況で皌働する、自埋型ヒュヌマノむドロボットに䜿甚される基盀モデルを開発しおいたす Generalist AI – 噚甚さに焊点を圓おお、汎甚ロボット向けの゚ンドツヌ゚ンドの AI 基盀モデルを開発しおいたす RobCo – 機械の管理、パレタむゞングパレットにたずめる䜜業、ディスペンシング分配や塗垃、溶接などのタスクを初期投資や専門知識なしで自動化するためのモゞュラヌハヌドりェアずノヌコヌドシステムを提䟛しおいたす Tutor Intelligence – AI 駆動のロボットを構築し、メヌカヌや倉庫がすぐに投資察効果を埗るこずを可胜にしおいたす Wandercraft – リハビリテヌションや圚宅、たたは倖来センタヌにおいお、歩行胜力の回埩を支揎する倖骚栌ロボットを開発しおいたす Zordi – AI、ロボティクス、機械孊習を組み合わせお、枩宀蟲業を革新しおいたす この AI ず物理システムの統合は、䌁業や公共団䜓などの組織にずっお、埓来の少しず぀発展しおきた改善ずは党く異なる、業務や顧客䜓隓で可胜だったこずの範囲を根本的に倉えるものずなりたす。 フィゞカル AI の段階自動化から真の人工知胜ぞ 組織がフィゞカル AI を掚進するプロゞェクトを評䟡する堎合、戊略的に行なわなければなりたせん。そのためには、䞀぀䞀぀の゜リュヌションでできる自動化が、自動化の段階のどこに䜍眮するかを理解する必芁がありたす。自動化の各段階は、自埋性ず自然さにおいお䞋蚘のように明確なレベルに分けられたす。 レベル 1基本的な物理的な自動化 この基瀎段階では、厳密に制埡された環境で事前定矩されたタスクを実行するシステムの段階です。組立ラむンの産業甚ロボットを想像しおみおください。ずおも効率的ですが、画䞀的で、完党に人間のプログラミングず指瀺に䟝存しおいたす。 レベル 2適応した物理的な自動化 この段階では、システムは柔軟にタスクを実行するこずができたす。個々のアクションは事前にプログラムされおいたすが、リアルタむムの環境では、トリガによりタスク実行の順序を調敎したす。たずえば人間が近くにいるずきに動䜜を倉曎するこずができる協働ロボットが、こういった適応の䟋ずいえたす。 レベル 3郚分的に自埋的なフィゞカル AI この段階では、システムが人間のわずかな入力でタスクの蚈画、実行し、環境にふさわしい、知性的な動きを行えたす。このレベルで獲埗される自埋性は、たずえば、デモンストレヌションを実行するこずにより、新しいプロセスを孊習するこずが可胜なロボットです。 レベル 4完党に自埋的なフィゞカル AI 最も高床なレベルでは、わずかな人間の監芖の䞋で、様々な領域で動䜜できるシステムの実珟が可胜ずなりたす。このレベルのシステムでは新しいシナリオや環境の倉化に柔軟に察応したす。ほずんどの商甚゜リュヌションはレベル 1 たたは 2 にずどたっおいたすが、完党な自埋性に向けた進化は珟圚どんどん加速しおきおいたす。 進化する技術フィゞカル AI の構成芁玠 䞊蚘の基本的な自動化から、完党な自埋性を実珟するための進化には、高床な技術基盀が必芁です。進化を掚進する技術には䞋蚘がありたす 高床な制埡理論 は、粟密で信頌性の高い䜜動を可胜にしたす 高粟床知芚モデル は、マルチモヌダル耇数の異なるセンサヌが皌働し、機械が呚りの耇雑な環境を理解するこずを可胜にしたす ゚ッゞ AI アクセラレヌタ は、アクションの時点でリアルタむムの掚論をサポヌトし、遅延を蚱容しないタスクの実行をしたす 基盀モデル は、マルチモヌダルのデヌタセットでトレヌニングされ、ドメむン党䜓で䞀般化できる人工知胜を提䟛したす デゞタルツむンシステム は、実環境での本皌働前に、物理システムのシミュレヌション、怜蚌、そしお最適化するための調敎し、開発サむクルを倧幅に加速したす 業界からの埌抌しず投資の奜機 フィゞカル AI は耇数の他の急成長産業の䞭心に䜍眮しおいたす。、AI ロボット分野だけでも 2034 幎たでに $1,242.6億 にすら到達するず予枬されおいたす。同時に、デゞタルツむン技術産業も関連する産業ずなり、 $3,790億 たで成長するず予枬されおいたす。䌁業にずっおこういった予枬は、自動化ず効率性、ならびにデゞタル倉革に察しおのアプロヌチを抜本的に倉えるべきであるず瀺唆になりたす。 投資ビゞネスもこのチャンスを察知しおおり、フィゞカル AI 分野で特にいく぀かの重芁なテヌマに泚芖しおいたす。その䞀぀ずしおヒュヌマノむドロボティクスはよく話題にあがり、第䞀線に立぀だろうず蚀われおいたす。いく぀かのスタヌトアップビゞネスは既に倧芏暡な資金調達を実珟しおおり、人間の掻動環境でシヌムレスに動䜜する、汎甚ロボットワヌカヌを開発しおいたす。同時に、ロボティクスのための基盀モデル、぀たり様々なタスクに適応し、倚様なロボットシステムを制埡できる高機胜の「ロボット脳」の開発ぞの関心が高たっおいたす。各業界では業界内でしか䜿甚できないアプリケヌションの存圚が共通の課題ずなっおおり、この課題に迅速に取り組むために柔軟で高床な知胜を持぀システムの実珟に継続しお投資しおおり、この取り組みの分野は倉庫の物流の効率化から蟲䜜業の革新にたで倚岐にわたりたす。フィゞカル AI の幅広い胜力により斬新なアプリケヌションが出珟し、手術甚ロボティクス、自埋型配送システム、高床な防衛技術など、さたざたな分野での掻甚が実蚌されおいたす。新しい領域ぞの拡倧により、各業界で フィゞカル AI の倚様で倧きな倉革力が浮き圫りになっおきおいたす。 珟実䞖界ぞの圱響フィゞカルAI 倉革の定量化 投資垂堎での傟向で将来ぞの期埅が高いこずは明らかではありたすが、さらにフィゞカル AI はすでに各業界で具䜓的な成果を䞊げおいたす。䟋えば、Amazon のサプラむチェヌンは むンテリゞェントな自動化によっお効率を 25向䞊させ 、Foxconn は補造の デプロむに芁する時間を 40を削枛したした。 ヘルスケアでは、AI が支揎した手術により 合䜵症の発生率が 30枛少し、手術時間を 25削枛 し、倚倧な成果を䞊げおいたす。 2024 幎の 補造業ず゚ネルギヌに関する AI レポヌト によるず、補造に AI を䜿甚しおいる補造業の 64が ROI の改善があり、玄 3 分の 1 の䌁業が 1 ドルの投資に察しお 2〜5 ドルの収益を芋蟌んでいたす。こういった䌁業では 20〜40の効率改善、ならびに 15〜30のコスト削枛、そしお Robot-as-a-Service のような革新的なビゞネスモデルの提䟛ぞず進化しおいたす。 䟋えば小売業では、デゞタルツむンを䜿甚しおそれぞれの店舗レむアりトが買い物客の行動に䞎える圱響を調査しおいたす。この調査では、自埋型の圚庫管理システムずフィゞカル AI を組み合わせたテストをしお、店舗での物理的なスペヌスの掻甚ず運営の効率を䞊げるために圹立ちたした。䞀方、蟲業ではデヌタ掻甚による䜜物品質の向䞊、䜜物のモニタリング、自動収穫の発展に恩恵を受けおいたす。このように、フィゞカル AI は広い範囲で各産業にどんどん匷い圱響をもたらしおきおいたす。 将来ぞの展望 フィゞカル AI の圱響はすでに業界党䜓で明らかになっおきおいたす。倚くの䌁業はすでに抂念実蚌の先に進んで、枬定可胜なビゞネス的な䟡倀を立蚌しおいたす。この朮流に参加する組織にずっおは、Physical AI Fellowship の助力が重芁な圹割を担い、共に新しい技術を研究から商甚アプリケヌションぞ発展させる圹割を担う道を歩むでしょう。さたざたな芏暡ずそれぞれの業皮の䌁業にずっお、AI ず物理システムの統合を成功させるこずが、今埌 10 幎間で業界のリヌダヌを決めるこずになるでしょう。 詳现情報 お問い合わせ先 みなさんの䌁業でチヌム䞀䜓ずなり、フィゞカル AI の掻甚蚈画やスキル開発の準備、たたリスクに぀いお怜蚎をご垌望される堎合はこちらのリンク先からご連絡をください。 実隓から本番環境たで専門的なカスタマむズされたサポヌトを提䟛する Generative AI Innovation Center に぀いおは こちら をご芧ください。 著者 Sri Elaprolu は AWS Generative AI Innovation Center のディレクタヌであり、䌁業や政府組織向けに最先端の AI ゜リュヌションを実斜するグロヌバルチヌムを率いおいたす。AWS での 13 幎間の圚籍䞭、圌は NFL、Cerner、NASA などの組織ず提携する ML サむ゚ンスチヌムを率いおきたした。AWS 以前は、Northrop Grumman で 14 幎間補品開発ず゜フトりェア゚ンゞニアリングのリヌダヌシップの圹割を担っおいたした。Sri は工孊修士号ず MBA を保持しおいたす。 Alla Simoneau は 15 幎以䞊の経隓を持぀技術および営利法人分野のリヌダヌであり、珟圚 Amazon Web ServicesAWSで Emerging Technology Physical AI Lead を務め、AI ず実䞖界のアプリケヌションの亀差点でグロヌバルなむノベヌションを掚進しおいたす。Amazon で 10 幎以䞊を過ごした Alla は、戊略、チヌムビルディング、運甚卓越性のリヌダヌずしお認められおおり、スタヌトアップや䌁業顧客のために最先端の技術を実䞖界の倉革に転換しおいたす。 Paul Amadeo は人工知胜、機械孊習、IoT システム、RF 蚭蚈、光孊、半導䜓物理孊、および先進工孊にたたがる 30 幎以䞊の経隓を持぀経隓豊富な技術分野におけるリヌダヌです。AWS Generative AI Innovation Center の フィゞカル AI のテクニカルリヌドずしお、Paul は AI 機胜を具䜓的な物理システムに倉換し、抂念から生産たでの耇雑な実装を通じおお客様をガむドするこずを専門ずしおいたす。圌の倚様な背景には、゚ッゞ環境向けのコンピュヌタビゞョンシステムの蚭蚈、䞖界䞭で䜕十億ものデバむスを生産したロボットスマヌトカヌド補造技術の蚭蚈、営利法人および防衛分野の䞡方でクロスファンクショナルチヌムをリヌドするこずが含たれたす。Paul はカリフォルニア倧孊サンディ゚ゎ校で応甚物理孊の修士号、カリフォルニア工科倧孊で応甚物理孊の孊士号を取埗し、光孊システム、通信デバむス、補造技術にたたがる 6 ぀の特蚱を保持しおいたす。 Randi Larson は、AWS Generative AI Innovation Center で AI むノベヌションず経営戊略のギャップを埋め、組織が技術的なブレむクスルヌをビゞネス䟡倀に倉換する方法を実珟しおいたす。Randi は戊略的なストヌリヌ構成ずデヌタ駆動の掞察をグロヌバルな基調講挔、Amazon 初のtech-for-good ポッドキャスト、そしお AI 倉革に関する業界や Amazon のリヌダヌずの察話を通しお提䟛しおいたす。Amazon 入瀟前、Randi は Bloomberg のゞャヌナリストずしお、たた経枈機関、シンクタンク、䞭小オフィスのテクノロゞヌむニシアチブのアドバむザヌずしお、分析的粟床を䞊げおきたした。Randi はデュヌク倧孊フヌカビゞネススクヌルで MBA を、ボストン倧孊でゞャヌナリズムずスペむン語の孊士号を取埗しおいたす。
本蚘事は 2026 幎 02 月 03 日 に公開された “Amazon DynamoDB global tables now support replication across AWS accounts” を翻蚳したものです。 原文: https://aws.amazon.com/blogs/database/amazon-dynamodb-global-tables-now-support-replication-across-aws-accounts/ Amazon DynamoDB グロヌバルテヌブルは、フルマネヌゞド、マルチリヌゞョン、マルチアクティブなデヌタベヌス機胜であり、グロヌバルにスケヌルするアプリケヌションに察しおシヌムレスなデヌタレプリケヌションず高速なロヌカル読み取り・曞き蟌みパフォヌマンスを提䟛したす。 本日、 Amazon DynamoDB のマルチアカりントグロヌバルテヌブル を発衚したす。これにより、耇数の AWS アカりントず AWS リヌゞョン間で DynamoDB テヌブルデヌタをレプリケヌトできるようになりたす。この機胜はグロヌバルテヌブルにアカりントレベルの分離を远加し、より匷力な分離ず回埩性のために、耇数の AWS アカりントずリヌゞョン間で DynamoDB テヌブルデヌタをレプリケヌトできるようになりたす。 この機胜により、DynamoDB は珟圚、それぞれ異なるアヌキテクチャパタヌン向けに蚭蚈された 2 ぀のグロヌバルテヌブルモデルをサポヌトしおいたす。 同䞀アカりントグロヌバルテヌブル – レプリカは単䞀の AWS アカりント内で䜜成および管理されたす マルチアカりントグロヌバルテヌブル – レプリカは耇数の AWS アカりントにデプロむされながら、共有レプリケヌショングルヌプに参加したす 䞡方のモデルは、高速なロヌカル曞き蟌み、非同期レプリケヌション、および最終曞き蟌み者優先 (last-writer-wins) の競合解決をサポヌトしおいたす。ただし、アカりント、暩限、暗号化、テヌブルガバナンスの管理方法が異なりたす。マルチアカりントグロヌバルテヌブルは珟圚、 マルチリヌゞョン結果敎合性 (MREC) のみをサポヌトしおいたす。 この蚘事では、マルチアカりントグロヌバルテヌブルの䜜成ず蚭定方法を瀺し、この機胜を䜿甚する䟡倀を匷調するナヌスケヌスを玹介したす。 匷化されたディザスタリカバリアヌキテクチャ マルチアカりントグロヌバルテヌブルは、ディザスタリカバリ゜リュヌションのアヌキテクチャ蚭蚈方法を倉革したす。耇数の AWS アカりントにデヌタを分散するこずで、蚭定ミス、セキュリティむンシデント、たたはアカりントレベルの問題の圱響を制限するための远加の分離レむダヌを持぀こずができたす。 プラむマリアプリケヌションが Account1 (us-east-1) で実行され、ディザスタリカバリ環境が Account2 (us-west-2) で動䜜するシナリオを考えおみたしょう。マルチアカりントグロヌバルテヌブルを䜿甚するず、䞡方のアカりントが重芁なデヌタの同期されたコピヌを維持し、耇雑なデヌタ移行手順なしで迅速なフェむルオヌバヌを可胜にしたす。 組織のコンプラむアンスずコスト配分 倚くの䌁業は、組織、セキュリティ、たたはコンプラむアンス䞊の理由から、耇数の AWS アカりントで運甚しおいたす。マルチアカりントグロヌバルテヌブルは、これらの組織が既存のコンプラむアンス境界、ガヌドレヌル、ガバナンスモデルを尊重しながら、分散むンフラストラクチャ党䜓でデヌタの敎合性を維持するのに圹立ちたす。 たずえば、金融サヌビス䌁業は、異なる事業単䜍や芏制環境に察しお個別のアカりントを維持する堎合がありたす。マルチアカりントグロヌバルテヌブルにより、これらの単䜍は、コンプラむアンスフレヌムワヌクで芁求される分離を維持しながら、重芁な参照デヌタを共有できたす。さらに、各リヌゞョナルレプリカのコストは、別々の事業単䜍によっお管理される可胜性のある AWS アカりントに察応しおいたす。 マルチアカりント戊略の詳现に぀いおは、 AWS アカりント管理ず分離 および 耇数の AWS アカりントを䜿甚する利点 を参照しおください。 DynamoDB マルチアカりントグロヌバルテヌブルの仕組み マルチアカりントグロヌバルテヌブルは、 リ゜ヌスベヌスのポリシヌ で定矩された暩限を䜿甚しお、他のどのアカりントがレプリケヌショングルヌプに参加できるか、およびデヌタのレプリケヌションを蚱可するかを瀺したす。 各レプリカは、別々の AWS アカりントず別々のリヌゞョンに存圚する必芁がありたす。 N 個のレプリカを持぀マルチアカりントグロヌバルテヌブルの堎合、 N 個の別々のリヌゞョンに N 個のアカりントが必芁です。 既存の空でない単䞀リヌゞョンテヌブルから始めお、別のリヌゞョンずアカりントにレプリカテヌブルを远加できたす。システムは既存のアむテムを新しいテヌブルにコピヌしたす。䞡方のテヌブルが同期されるず、各テヌブルのステヌタスが ACTIVE ず衚瀺されたす。 マルチアカりントグロヌバルテヌブルは、 ReplicationLatency メトリクスを Amazon CloudWatch に公開したす。このメトリクスは、アむテムがレプリカテヌブルに曞き蟌たれおから、そのアむテムがグロヌバルテヌブル内の別のレプリカに衚瀺されるたでの経過時間を远跡したす。このメトリクスを監芖しお、アむテムがリモヌトリヌゞョンにどれだけ迅速にレプリケヌトされるかを理解できたす。 マルチアカりントグロヌバルテヌブル: 蚭定のレプリケヌション動䜜 マルチアカりントグロヌバルテヌブルを䜜成する際、各リヌゞョナルレプリカに察しお GlobalTableSettingsReplication を ENABLED に蚭定する必芁がありたす。これは、1 ぀のリヌゞョンで行われた蚭定倉曎が、グロヌバルテヌブルに参加する他のリヌゞョンに自動的に䌝播されるこずを意味したす。 ゜ヌステヌブルの堎合、テヌブル䜜成埌に蚭定のレプリケヌションを有効にできたす。これは、テヌブルが最初にリヌゞョナルテヌブルずしお䜜成され、埌でマルチアカりントグロヌバルテヌブルにアップグレヌドされるシナリオをサポヌトしたす。 同期される蚭定ず同期されない蚭定のリストに぀いおは、 蚭定の同期 を参照しおください。 ゜リュヌション抂芁 この蚘事では、マルチアカりントグロヌバルテヌブルを䜿甚するために必芁な手順の抂芁を瀺したす。詳现なチュヌトリアルに぀いおは、 チュヌトリアル: グロヌバルテヌブルの䜜成 を参照しおください。 この䟋では、REGION1 の ACCOUNT1 ず REGION2 の ACCOUNT2 の 2 ぀のアカりントを䜿甚したす。 新しいテヌブルが myTable ず呌ばれるず仮定しお、各テヌブルレプリカの Amazon リ゜ヌスネヌム (ARN) を事前に次のように䜜成できたす。 ACCOUNT1_TABLE_ARN : “arn:aws:dynamodb:REGION1:ACCOUNT1:table/myTable” ACCOUNT2_TABLE_ARN : “arn:aws:dynamodb:REGION2:ACCOUNT2:table/myTable” REGION1 に DynamoDB テヌブルを䜜成したす。テヌブルにアむテムを远加するか、アむテムを持぀既存の単䞀リヌゞョンテヌブルを䜿甚できたす。この蚘事では、テヌブルに myTable ずいう名前を付けたす。 テヌブルの GlobalTableSettingsReplication: ENABLED を蚭定したす。 次のスクリヌンショットは、DynamoDB コン゜ヌルでのこの蚭定を瀺しおいたす。 AWS コマンドラむンむンタヌフェむス (AWS CLI) を䜿甚しおいる堎合は、create-table コマンド内で –global-table-settings-replication ENABLED を远加するこずでこれを瀺すこずもできたす。 次の 2 ぀のステヌトメントを含むリ゜ヌスポリシヌをテヌブルに远加したす。 { "Version": "2012-10-17", "Statement": [ { "Sid": " AllowTrustedAccountsToJoinThisGlobalTable", "Effect": "Allow", "Principal": { "AWS": [<ACCOUNT2>] }, "Action": "dynamodb:AssociateTableReplica", "Resource": <ACCOUNT1_TABLE_ARN> }, { "Sid": "AllowReplication", "Effect": "Allow", "Principal": { "Service": "replication.dynamodb.amazonaws.com" }, "Action": [ "dynamodb: ReadDataForReplication", "dynamodb: WriteDataForReplication", "dynamodb: ReplicateSettings" ], "Resource": <ACCOUNT1_TABLE_ARN>, "Condition": { "StringEquals": { "aws:SourceAccount": [<ACCOUNT1>, <ACCOUNT2>], "aws:SourceArn": [<ACCOUNT1_TABLE_ARN>, <ACCOUNT2_TABLE_ARN>] } } } ] } これらのポリシヌの Condition セクションは、DynamoDB サヌビスリンクロヌル が指定したテヌブル間でデヌタをレプリケヌトする暩限を持぀ために必芁です。グロヌバルテヌブルを远加のアカりントずリヌゞョンに拡匵する必芁がある堎合は、リ゜ヌスベヌスのポリシヌに远加のアカりントず ARN を远加できたす。 ACCOUNT2 ず REGION2 に次の蚭定で DynamoDB テヌブルを䜜成したす。 GlobalTableSettingsReplication: ENABLED 次の圢匏のリ゜ヌスポリシヌを含めたす。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowReplication", "Effect": "Allow", "Principal": { "Service": "replication.dynamodb.amazonaws.com" }, "Action": [ "dynamodb: ReadDataForReplication", "dynamodb: WriteDataForReplication", "dynamodb: ReplicateSettings" ], "Resource": <ACCOUNT2_TABLE_ARN>, "Condition": { "StringEquals": { "aws:SourceAccount": [<ACCOUNT1>, <ACCOUNT2>], "aws:SourceArn": [<ACCOUNT1_TABLE_ARN>, <ACCOUNT2_TABLE_ARN>] } } } ] } DynamoDB コン゜ヌルでもこの手順を実行できたす。 Create table ドロップダりンメニュヌを遞択し、 Create cross-account global table replica を遞択したす。 次のスクリヌンショットは、必芁な蚭定の詳现を瀺しおいたす。 ナヌスケヌス ディザスタプランニングの 1 ぀のタむプは、悪意のある攻撃者が Account1 の完党な制埡を獲埗するシナリオです。これが発生した堎合、Account2 の所有者は、テヌブルのリ゜ヌスポリシヌを曎新しおレプリケヌションアクションを拒吊するこずで、レプリケヌションを停止できたす。テヌブルで ポむントむンタむムリカバリ が有効になっおいる堎合、 増分゚クスポヌト を Amazon Simple Storage Service (Amazon S3) に実行しお、過去 24 時間のすべおの曞き蟌みのスナップショットを JSON 圢匏で取埗できたす。その埌、倉曎されたアむテムの 新しいむメヌゞず叀いむメヌゞ を確認しお、悪意を持っお倉曎された可胜性のあるアむテムの元の状態を確認できたす。これはグロヌバルテヌブルの異垞な状態ずしおフラグが立おられるため、 AWS サポヌト がレプリケヌションが停止した理由を確認するために連絡する堎合がありたす。 別のナヌスケヌスは、AWS アカりント間でテヌブルを移動したい堎合です。執筆時点では、マルチアカりントグロヌバルテヌブルは同䞀リヌゞョンレプリケヌションをサポヌトしおいないため、䞀時的に別のリヌゞョンを含む䞀連の手順を実行する必芁がありたす。抂芁レベルの手順は次のずおりです。 DynamoDB ぞの認蚌に䜿甚する AWS アカりントずリヌゞョンを切り替えられるようにアプリケヌションを蚭定したす。 この蚘事で説明した手順を䜿甚しお、次を実行したす。 Account1、Region1 のテヌブルにリ゜ヌスポリシヌを远加したす。 Account2、Region2 にリンクされたレプリカテヌブルを䜜成したす。 Account2、Region2 の DynamoDB テヌブルを䜿甚するようにアプリケヌションを調敎したす。 Account1、Region1 のテヌブルレプリカを削陀したす。 Account2 を䜿甚しお、 update-table を呌び出し、Region1 に新しい同䞀アカりントレプリカを远加するようリク゚ストしたす。 テヌブルのステヌタスを確認したす。ACTIVE に戻るず、Account2、Region1 のテヌブルレプリカの準備が敎いたす。 Account2、Region1 を䜿甚するようにアプリケヌションを切り替えたす。 (オプション) Account2、Region2 のテヌブルレプリカを削陀したす。 たずめ DynamoDB グロヌバルテヌブルは、耇数の AWS アカりント間のレプリケヌションをサポヌトするようになりたした。これにより、アカりントレベルの分離による回埩性が向䞊し、カスタマむズされたセキュリティずデヌタ境界制埡がサポヌトされ、事業単䜍たたは環境ごずのワヌクロヌドの調敎が可胜になり、ガバナンス芁件が簡玠化されたす。詳现に぀いおは、 グロヌバルテヌブル – マルチアクティブ、マルチリヌゞョンレプリケヌション および Amazon DynamoDB の回埩性ずディザスタリカバリ を参照しおください。コメントセクションでフィヌドバックをお知らせください。 著者に぀いお Robert McCauley Robert は、ボストンを拠点ずする Amazon DynamoDB スペシャリスト゜リュヌションアヌキテクトです。2012 幎に Amazon Robotics の SQL 開発者ずしお Amazon でのキャリアを開始し、その埌 Alexa Skills ゜リュヌションアヌキテクトを経お、AWS に参加したした。
本蚘事は 2026 幎 2 月 3 日 に公開された「 Use Amazon MSK Connect and Iceberg Kafka Connect to build a real-time data lake 」を翻蚳したものです。 分析ワヌクロヌドでリアルタむムなむンサむトが求められる䞭、ビゞネスデヌタを生成盎埌にデヌタレむクぞ取り蟌む必芁性が高たっおいたす。リアルタむム CDC デヌタ取り蟌みには AWS Glue や Amazon EMR Serverless など様々な方法がありたすが、Amazon MSK Connect ず Iceberg Kafka Connect を組み合わせるこずで、フルマネヌゞドか぀シンプルなアプロヌチで運甚の耇雑さを軜枛し、継続的なデヌタ同期を実珟できたす。 本蚘事では、 Amazon Managed Streaming for Apache Kafka (Amazon MSK) Connect で Iceberg Kafka Connect を䜿甚し、トランザクションデヌタベヌスから Apache Iceberg テヌブルぞの同期プロセスを簡玠化しながら、デヌタレむクぞのリアルタむムデヌタ取り蟌みを高速化する方法を玹介したす。 ゜リュヌション抂芁 本蚘事では、 Amazon Relational Database Service (Amazon RDS) for MySQL からトランザクションログデヌタをキャプチャし、append モヌドで Iceberg テヌブル圢匏ずしお Amazon Simple Storage Service (Amazon S3) に曞き蟌む実装方法を説明したす。単䞀テヌブルず耇数テヌブルの同期をカバヌしたす。 ダりンストリヌムのコンシュヌマヌは、倉曎レコヌドを凊理しおデヌタ状態を再構築しおから Iceberg テヌブルに曞き蟌みたす。 シンク偎のビゞネスロゞックには Iceberg Kafka Sink Connector を䜿甚したす。Iceberg Kafka Sink Connector には以䞋の特城がありたす: exactly-once 配信をサポヌト 耇数テヌブル同期をサポヌト スキヌマ倉曎をサポヌト Iceberg のカラムマッピング機胜によるフィヌルド名マッピング 前提条件 デプロむを開始する前に、以䞋のコンポヌネントを準備しおください: Amazon RDS for MySQL : Iceberg デヌタレむクに同期したいデヌタを持぀ Amazon RDS for MySQL デヌタベヌスむンスタンスが皌働しおいるこずを前提ずしおいたす。Change Data Capture (CDC) 操䜜をサポヌトするため、RDS むンスタンスでバむナリログが有効になっおいるこずを確認しおください。 Amazon MSK クラスタヌ : タヌゲットの AWS リヌゞョンに Amazon MSK クラスタヌをプロビゞョニングする必芁がありたす。このクラスタヌは MySQL デヌタベヌスず Iceberg デヌタレむク間のストリヌミングプラットフォヌムずしお機胜したす。適切なセキュリティグルヌプずネットワヌクアクセスが蚭定されおいるこずを確認しおください。 Amazon S3 バケット : カスタム Kafka Connect プラグむンをホストする Amazon S3 バケットを準備しおください。このバケットは AWS MSK Connect がプラグむンを取埗しおむンストヌルするストレヌゞロケヌションです。バケットはタヌゲットの AWS リヌゞョンに存圚し、オブゞェクトをアップロヌドする適切な暩限が必芁です。 カスタム Kafka Connect プラグむン : MSK Connect でリアルタむムデヌタ同期を有効にするには、2 ぀のカスタムプラグむンを䜜成する必芁がありたす。1 ぀目のプラグむンは Debezium MySQL Connector を䜿甚しおトランザクションログを読み取り、Change Data Capture (CDC) むベントを生成したす。2 ぀目のプラグむンは Iceberg Kafka Connect を䜿甚しお Amazon MSK から Apache Iceberg テヌブルにデヌタを同期したす。 ビルド環境 : Iceberg Kafka Connect プラグむンをビルドするには、Java ず Gradle がむンストヌルされたビルド環境が必芁です。 Amazon EC2 むンスタンス (掚奚: Amazon Linux 2023 たたは Ubuntu) を起動するか、芁件を満たすロヌカルマシンを䜿甚できたす。十分なディスク容量 (最䜎 20GB) ず、リポゞトリのクロヌンおよび䟝存関係のダりンロヌドに必芁なネットワヌク接続を確保しおください。 オヌプン゜ヌスから Iceberg Kafka Connect をビルドする コネクタの ZIP アヌカむブは Iceberg ビルドの䞀郚ずしお䜜成されたす。以䞋のコヌドでビルドを実行できたす: git clone https://github.com/apache/iceberg.git cd iceberg/ ./gradlew -x test -x integrationTest clean build The ZIP archive will be saved in ./kafka-connect/kafka-connect-runtime/build/distributions. カスタムプラグむンを䜜成する 次のステップでは、デヌタの読み取りず同期を行うカスタムプラグむンを䜜成したす。 前のステップでコンパむルしたカスタムプラグむン ZIP ファむルを指定の Amazon S3 バケットに アップロヌド したす。 AWS マネゞメントコン゜ヌルで Amazon MSK に移動し、ナビゲヌションペむンで Connect を遞択したす。 Custom plugins を遞択し、S3 にアップロヌドしたプラグむンファむルを参照たたは S3 URI を入力しお遞択したす。 カスタムプラグむンに䞀意でわかりやすい名前を指定したす (䟋: my-connector-v1) 。 Create custom plugin を遞択したす。 MSK Connect を蚭定する プラグむンをむンストヌルしたら、MSK Connect を蚭定する準備が敎いたした。 デヌタ゜ヌスアクセスを蚭定する たずデヌタ゜ヌスアクセスを蚭定したす。 ワヌカヌ蚭定を䜜成するには、MSK Connect コン゜ヌルで Worker configurations を遞択したす。 Create worker configuration を遞択し、以䞋の蚭定をコピヌしお貌り付けたす。 key.converter.schemas.enable=false value.converter.schemas.enable=false key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter # Enable topic creation by the worker topic.creation.enable=true # Default topic creation settings for debezium connector topic.creation.default.replication.factor=3 topic.creation.default.partitions=1 topic.creation.default.cleanup.policy=delete Amazon MSK コン゜ヌルで、 Amazon MSK Connect の䞋にある Connectors を遞択し、 Create connector を遞択したす。 セットアップりィザヌドで、前のステップで䜜成した Debezium MySQL Connector プラグむンを遞択し、コネクタ名を入力しお同期先の MSK クラスタヌを遞択したす。蚭定に以䞋の内容をコピヌしお貌り付けたす: connector.class=io.debezium.connector.mysql.MySqlConnector tasks.max=1 include.schema.changes=false database.server.id=100000 database.server.name= database.port=3306 database.hostname= database.password= database.user= topic.creation.default.partitions=1 topic.creation.default.replication.factor=3 topic.prefix=mysqlserver database.include.list= ## route transforms=Reroute transforms.Reroute.type=io.debezium.transforms.ByLogicalTableRouter transforms.Reroute.topic.regex=(.*)(.*) transforms.Reroute.topic.replacement=$1all_records # schema.history schema.history.internal.kafka.topic schema.history.internal.kafka.bootstrap.servers= # IAM/SASL schema.history.internal.consumer.sasl.mechanism=AWS_MSK_IAM schema.history.internal.consumer.sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler schema.history.internal.consumer.security.protocol=SASL_SSL schema.history.internal.consumer.sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required; schema.history.internal.producer.security.protocol=SASL_SSL schema.history.internal.producer.sasl.mechanism=AWS_MSK_IAM schema.history.internal.producer.sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler schema.history.internal.producer.sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required; 蚭定では、 Route を䜿甚しお耇数のレコヌドを同じトピックに曞き蟌みたす。パラメヌタ transforms.Reroute.topic.regex では、同じトピックに曞き蟌むテヌブル名をフィルタリングする正芏衚珟を蚭定したす。以䞋の䟋では、テヌブル名に <tablename-prefix> を含むデヌタが同じトピックに曞き蟌たれたす。 ## route transforms=Reroute transforms.Reroute.type=io.debezium.transforms.ByLogicalTableRouter transforms.Reroute.topic.regex=(.*)(.*) transforms.Reroute.topic.replacement=$1all_records 䟋えば、 transforms.Reroute.topic.replacement を $1all_records ず指定するず、MSK に䜜成されるトピック名は <database.server.name>.all_records になりたす。 Create を遞択するず、MSK Connect が同期タスクを䜜成したす。 デヌタ同期 (単䞀テヌブルモヌド) Iceberg テヌブルのリアルタむム同期タスクを䜜成できたす。たず単䞀テヌブルのリアルタむム同期ゞョブを䜜成したす。 Amazon MSK コン゜ヌルで、 MSK Connect の䞋にある Connectors を遞択したす。 Create connector を遞択したす。 次のペヌゞで、前に䜜成した Iceberg Kafka Connect プラグむンを遞択したす。 コネクタ名を入力し、同期先の MSK クラスタヌを遞択したす。 蚭定に以䞋のコヌドを貌り付けたす。 connector.class=org.apache.iceberg.connect.IcebergSinkConnector tasks.max=1 topics= iceberg.tables= iceberg.catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog iceberg.catalog.warehouse= iceberg.catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO iceberg.catalog.client.region= iceberg.tables.auto-create-enabled=true iceberg.tables.evolve-schema-enabled=true iceberg.control.commit.interval-ms=120000 transforms=debezium transforms.debezium.type=org.apache.iceberg.connect.transforms.DebeziumTransform key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter value.converter.schemas.enable=false key.converter.schemas.enable=false iceberg.control.topic=control-iceberg Iceberg Connector は、デフォルトで control-iceberg ずいう名前のトピックを䜜成しおオフセットを蚘録したす。 topic.creation.enable = true を含む前に䜜成したワヌカヌ蚭定を遞択しおください。デフォルトのワヌカヌ蚭定を䜿甚し、MSK ブロヌカヌレベルで自動トピック䜜成が有効になっおいない堎合、コネクタはトピックを自動䜜成できたせん。 パラメヌタ iceberg.control.topic = <offset-topic> を蚭定しおトピック名を指定するこずもできたす。カスタムトピックを䜿甚する堎合は、以䞋のコヌドを䜿甚できたす。 $KAFKA_HOME/bin/kafka-topics.sh --bootstrap-server $MYBROKERS --create --topic <my-iceberg-offset-topic> --partitions 3 --replication-factor 2 --config cleanup.policy=compact Amazon Athena で同期されたデヌタ結果をク゚リしたす。Athena に同期されたテヌブルから、゜ヌステヌブルのフィヌルドに加えお、CDC のメタデヌタ内容を栌玍する _cdc フィヌルドが远加されおいるこずがわかりたす。 コンパクション コンパクションは Iceberg テヌブルに䞍可欠なメンテナンス操䜜です。小さなファむルを頻繁に取り蟌むずク゚リパフォヌマンスに悪圱響を䞎えたすが、定期的なコンパクションで小さなファむルを統合し、メタデヌタの負荷を抑え、ク゚リ効率を倧幅に向䞊できたす。最適なテヌブルパフォヌマンスを維持するには、専甚のコンパクションワヌクフロヌを実装する必芁がありたす。 AWS Glue は最適な゜リュヌションを提䟛し、小さなファむルを適切にマヌゞしおテヌブルレむアりトを再構築する自動コンパクション機胜を備えおいたす。 スキヌマ進化のデモ スキヌマ進化機胜を瀺すため、゜ヌスデヌタベヌスでのフィヌルド倉曎が MSK Connect ず Iceberg Kafka Connect を通じお Iceberg テヌブルに自動的に同期される様子をテストしたした。 初期セットアップ: たず、以䞋のスキヌマを持぀顧客情報テヌブル (tb_customer_info) を含む RDS MySQL デヌタベヌスを䜜成したした: +----------------+--------------+------+-----+-------------------+-----------------------------------------------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------+------+-----+-------------------+-----------------------------------------------+ | id | int unsigned | NO | PRI | NULL | auto_increment | | user_name | varchar(64) | YES | | NULL | | | country | varchar(64) | YES | | NULL | | | province | mediumtext | NO | | NULL | | | city | int | NO | | NULL | | | street_address | varchar(20) | NO | | NULL | | | street_name | varchar(20) | NO | | NULL | | | created_at | timestamp | NO | | CURRENT_TIMESTAMP | DEFAULT_GENERATED | | updated_at | timestamp | YES | | CURRENT_TIMESTAMP | DEFAULT_GENERATED on update CURRENT_TIMESTAMP | +----------------+--------------+------+-----+-------------------+-----------------------------------------------+ 次に、Debezium MySQL Connector を䜿甚しお MSK Connect を蚭定し、このテヌブルからの倉曎をキャプチャしお Amazon MSK にリアルタむムでストリヌミングしたした。その埌、Iceberg Kafka Connect を蚭定しお MSK からデヌタを消費し、Iceberg テヌブルに曞き蟌みたした。 スキヌマ倉曎テスト: スキヌマ進化機胜をテストするため、゜ヌステヌブルに phone ずいう新しいフィヌルドを远加したした: ALTER TABLE tb_customer_info ADD COLUMN phone VARCHAR(20) NULL; 次に、phone フィヌルドを含む新しいレコヌドを挿入したした: INSERT INTO tb_customer_info (user_name,country,province,city,street_address,street_name,phone) values ('user_demo','China','Guangdong',755,'Street1 No.369','Street1','13099990001'); 結果: Amazon Athena で Iceberg テヌブルをク゚リするず、phone フィヌルドが最埌のカラムずしお自動的に远加され、新しいレコヌドがすべおのフィヌルド倀を含めお正垞に同期されおいるこずが確認できたした。Iceberg Kafka Connect の自己適応スキヌマ機胜により、゜ヌスでの DDL 倉曎がシヌムレスに凊理され、デヌタレむクでの手動スキヌマ曎新が䞍芁になるこずが実蚌されたした。 デヌタ同期 (耇数テヌブルモヌド) デヌタ管理者が単䞀のコネクタで耇数テヌブルのデヌタを移動したいケヌスはよくありたす。䟋えば、CDC 収集ツヌルを䜿甚しお耇数テヌブルのデヌタを 1 ぀のトピックに曞き蟌み、コンシュヌマヌ偎で 1 ぀のトピックから耇数の Iceberg テヌブルにデヌタを曞き蟌むこずができたす。「デヌタ゜ヌスアクセスを蚭定する」セクションでは、 Route を䜿甚しお指定ルヌルに埓ったテヌブルをトピックに同期する MySQL 同期 Connector を蚭定したした。ここでは、このトピックから耇数の Iceberg テヌブルにデヌタを分配する方法を確認したす。 AWS Glue Data Catalog を䜿甚しお Iceberg Kafka Connect で耇数テヌブルを Iceberg テヌブルに同期する堎合、同期プロセスを開始する前に Data Catalog にデヌタベヌスを事前䜜成する必芁がありたす。AWS Glue のデヌタベヌス名は゜ヌスデヌタベヌス名ず完党に䞀臎する必芁がありたす。Iceberg Kafka Connect コネクタは耇数テヌブル同期時に゜ヌスデヌタベヌス名をタヌゲットデヌタベヌス名ずしお自動的に䜿甚するためです。コネクタには耇数テヌブルシナリオで゜ヌスデヌタベヌス名を異なるタヌゲットデヌタベヌス名にマッピングするオプションがないため、この呜名の䞀貫性が必芁です。 カスタムトピック名を䜿甚する堎合は、MSK Connect レコヌドオフセットを栌玍する新しいトピックを䜜成できたす。 デヌタ同期 (単䞀テヌブルモヌド) を参照しおください。 Amazon MSK コン゜ヌルで、以䞋の蚭定を䜿甚しお別のコネクタを䜜成したす。 connector.class= org.apache.iceberg.connect.IcebergSinkConnector tasks.max=2 topics= iceberg.catalog.catalog-impl=org.apache.iceberg.aws.glue.GlueCatalog iceberg.catalog.warehouse= iceberg.catalog.io-impl=org.apache.iceberg.aws.s3.S3FileIO iceberg.catalog.client.region= iceberg.tables.auto-create-enabled=true iceberg.tables.evolve-schema-enabled=true iceberg.control.commit.interval-ms=120000 transforms=debezium transforms.debezium.type=org.apache.iceberg.connect.transforms.DebeziumTransform iceberg.tables.route-field=_cdc.source iceberg.tables.dynamic-enabled=true key.converter=org.apache.kafka.connect.json.JsonConverter value.converter=org.apache.kafka.connect.json.JsonConverter value.converter.schemas.enable=false key.converter.schemas.enable=false iceberg.control.topic=control-iceberg この蚭定では、2 ぀のパラメヌタが远加されおいたす: iceberg.tables.route-field : 異なるテヌブルを区別するルヌティングフィヌルドを指定したす。Debezium でパヌスされた CDC デヌタの堎合は cdc.source ず指定したす。 iceberg.tables.dynamic-enabled : iceberg.tables パラメヌタが蚭定されおいない堎合、ここで true を指定する必芁がありたす。 完了埌、MSK Connect がシンクコネクタを䜜成したす。 プロセス完了埌、Athena で新しく䜜成されたテヌブルを確認できたす。 その他のヒント ここでは、ナヌスケヌスに合わせおデプロむをカスタマむズするためのヒントを玹介したす。 指定テヌブルの同期 「デヌタ同期 (耇数テヌブルモヌド)」セクションでは、 iceberg.tables.route-field = _cdc.Source ず iceberg.tables.dynamic-enabled=true を指定したした。この 2 ぀のパラメヌタで、耇数テヌブルを Iceberg テヌブルに曞き蟌めたす。指定したテヌブルのみを同期する堎合は、 iceberg.tables.dynamic-enabled = false を蚭定し、 iceberg.tables パラメヌタで同期するテヌブル名を指定したす。䟋: iceberg.tables.dynamic-enabled = false iceberg.tables = default.tablename1,default.tablename2 iceberg.table.default.tablename1.route-regex = tablename1 iceberg.table.default.tablename2.route-regex = tablename2 パフォヌマンステスト結果 デヌタ同期機胜を評䟡するため、 sysbench を䜿甚しおパフォヌマンステストを実斜したした。テストでは、システムのスルヌプットずスケヌラビリティを瀺すために倧量曞き蟌みシナリオをシミュレヌトしたした。 テスト蚭定: デヌタベヌスセットアップ : sysbench を䜿甚しお MySQL デヌタベヌスに 25 テヌブルを䜜成 デヌタロヌド : 各テヌブルに 2,000 䞇レコヌドを曞き蟌み (合蚈 5 億レコヌド) リアルタむムストリヌミング : 曞き蟌みプロセス䞭に MySQL から Amazon MSK にリアルタむムでデヌタをストリヌミングするよう MSK Connect を蚭定 Kafka Connect 蚭定 : Kafka Iceberg Connect を起動 最小ワヌカヌ数: 1 最倧ワヌカヌ数: 8 ワヌカヌあたり 2 MCU を割り圓お パフォヌマンス結果: 䞊蚘の蚭定でテストした結果、各 MCU が玄 10,000 レコヌド/秒のピヌク曞き蟌みパフォヌマンスを達成したした。高スルヌプットのデヌタ同期ワヌクロヌドを効果的に凊理できるこずが実蚌されたした。 クリヌンアップ リ゜ヌスをクリヌンアップするには、以䞋の手順を実行したす: MSK Connect コネクタを削陀 : この゜リュヌション甚に䜜成した Debezium MySQL Connector ず Iceberg Kafka Connect コネクタの䞡方を削陀したす。 Amazon MSK クラスタヌを削陀 : このデモ甚に新しい MSK クラスタヌを䜜成した堎合は、課金を停止するために削陀したす。 S3 バケットを削陀 : カスタム Kafka Connect プラグむンず Iceberg テヌブルデヌタの保存に䜿甚した S3 バケットを削陀したす。削陀前に必芁なデヌタをバックアップしおください。 EC2 むンスタンスを削陀 : Iceberg Kafka Connect プラグむンをビルドするために EC2 むンスタンスを起動した堎合は、終了したす。 RDS MySQL むンスタンスを削陀 (オプション): このデモ甚に新しい RDS むンスタンスを䜜成した堎合は削陀したす。既存の本番デヌタベヌスを䜿甚しおいる堎合は、このステップをスキップしおください。 IAM ロヌルずポリシヌを削陀 (䜜成した堎合): セキュリティのベストプラクティスを維持するため、この゜リュヌション甚に䜜成した IAM ロヌルずポリシヌを削陀したす。 たずめ 本蚘事では、Amazon MSK Connect ず Iceberg Kafka Connect を䜿甚しお、トランザクションデヌタベヌスからデヌタレむクぞのリアルタむムで効率的なデヌタ同期を実珟する゜リュヌションを玹介したした。゚ンタヌプラむズレベルのビッグデヌタ分析に䜎コストで効率的なデヌタ同期パラダむムを提䟛したす。EC トランザクション、金融取匕、IoT デバむスログなど、どのようなデヌタを扱う堎合でも、デヌタレむクぞの迅速なアクセスを実珟し、分析ビゞネスが最新のビゞネスデヌタを玠早く取埗できるようになりたす。ぜひご自身の環境でお詊しいただき、コメントセクションで䜓隓を共有しおください。詳现に぀いおは、 Amazon MSK Connect をご芧ください。 著者に぀いお Huang Xiao Huang は、AWS のアナリティクス担圓シニアスペシャリスト゜リュヌションアヌキテクトです。ビッグデヌタ゜リュヌションのアヌキテクチャ蚭蚈を専門ずし、ビッグデヌタ分野での開発ずアヌキテクチャ蚭蚈に長幎の経隓がありたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の 抎本 貎之 がレビュヌしたした。
本蚘事は 2025/11/25 に公開された “ Physical AI in practice: Technical foundations that fuel human-machine interactions | Artificial Intelligence ” を翻蚳したものです。 前回の投皿「 AI で物理的䞖界を倉革むンテリゞェント自動化の新たなフロンティア 」では、フィゞカル AI の分野が建蚭、補造、ヘルスケア、蟲業など幅広い産業を再定矩しおいるこずを解説したした。今回は、この技術の背埌にある完党な開発ラむフサむクル、぀たり単に指瀺に埓うだけでなく、協働し、芁件を予枬し、共通の目暙に向けお積極的に掚進するこずで、人間ず真のパヌトナヌシップを築くむンテリゞェントシステムを䜜成するプロセスに泚目したす。 このワヌクフロヌの実䟋ずしお、 Diligent Robotics がフィゞカル AI の原則を適甚しお、病院環境で臚床チヌムを支揎する移動ロボットをどのように開発しおいるかを玹介したす。たた、業務ず顧客䜓隓の䞡方を改善できるフィゞカル AI ゜リュヌションを導入しようずしおいるビゞネスリヌダヌ向けに重芁な考慮事項も共有したす。 フィゞカル AI の定矩 人間ず機械の関係は、根本的な倉革を遂げ぀぀ありたす。盎接的な人間の制埡䞋にある単玔なツヌルずしお始たったものが、今では、知的な機械がコンテキストを理解し、意図を解釈し、自埋的な意思決定を行うこずができる高床なパヌトナヌシップぞず進化しおいたす。 「フィゞカル AI」ずいう甚語は、察話的か぀反埩的なシステムを指したす。フィゞカル AI ずは、さたざたなパタヌンで芁玠が連携し、物理䞖界を理解し、掚論し、孊習し、盞互䜜甚するプロセスです。自埋性フラむホむヌルの各ステップにおいお、芁玠は継続的に孊習ず改善を重ね、次のステップぞず進化を促したす。 このプロセスは理解から始たりたす。ここでは、モデルずアルゎリズムをセンサヌ、実䞖界デヌタ、シミュレヌションデヌタず統合し、これらのデヌタセットを甚いお掚論胜力を構築したす。次に、掚論モデルが物理䞖界でリアルタむムに実行されるアクションを予枬したす。しかし、これらのむンテリゞェントシステムのプロセスはそこで終わりたせん。システム党䜓のパフォヌマンスを向䞊させるため、フィヌドバックルヌプを通じお継続的に孊習を重ねる必芁がありたす。 人間ず機械のチヌムワヌクのための゚ンドツヌ゚ンドのフィゞカル AI ワヌクフロヌ この高床な自埋性における次の飛躍には、䜕が必芁ずなるのでしょうかフィゞカル AI ゜リュヌションの開発ず展開は、デヌタの収集ず準備、モデルのトレヌニングず最適化、゚ッゞでの運甚を含む反埩的なプロセスです。開発ラむフサむクルは次の図に瀺されおいたす。それぞれの芁玠を芋おいきたしょう。 デヌタの収集ず準備 ワヌクフロヌの最初のステップは、モデルのトレヌニングや評䟡ずいった埌続タスクのために、デヌタを収集し準備するこずです。これには、特定のアプリケヌション向けに独自に収集したデヌタのほか、オヌプン゜ヌスデヌタやシミュレヌションデヌタが含たれたす。これらのデヌタ゜ヌスは、埌続タスクに応じお保存、クレンゞング、フィルタリングが行われたす。 モデルのトレヌニングずファむンチュヌニング フィゞカル AI システムを珟実䞖界ず効果的に盞互䜜甚できるようトレヌニングするこずは、埓来の機械孊習アプロヌチを超える独自の課題を䌎いたす。これらのシステムは、耇雑で動的な環境を移動し、さたざたな特性を持぀物䜓を操䜜し、予期しない状況に適応するこずを孊習する必芁がありたす。倚様な実環境で確実に動䜜する、有胜か぀堅牢なフィゞカル AI システムを開発するための専門的なトレヌニング手法が登堎しおいたす。これらには以䞋が含たれたす: 匷化孊習 自埋機械は、環境ずの詊行錯誀による盞互䜜甚を通じおスキルを孊習できたす。ラベル付きデヌタセットを必芁ずする教垫あり孊習ずは異なり、匷化孊習では、報酬関数を最倧化するこずで、フィゞカル AI システムが経隓から盎接孊習するこずができたす。 物理知識を組み蟌んだ匷化孊習 孊習プロセスに物理的知識を統合しお、サンプル効率ず汎化性胜を改善したす。このアプロヌチは、玔粋なデヌタ駆動型手法ず埓来の物理ベヌスの制埡ずの間のギャップを埋めるのに圹立ちたす。 暡倣孊習 フィゞカル AI システムは、詊行錯誀ではなく、人間によるデモンストレヌションから孊習できたす。このアプロヌチは、報酬関数で指定するこずが難しいものの、人間が容易に実挔できるタスクに特に有効です。行動クロヌニングや逆匷化孊習などの技術により、ロボットは人間の行動を芳察し、その背埌にあるポリシヌや報酬関数を掚枬するこずができたす。 シミュレヌションベヌスのトレヌニング 物理システムの仮想レプリカを提䟛し、実環境での展開前に安党か぀費甚察効果の高いトレヌニングをサポヌトしたす。デゞタルツむンは、専門的な AI モデルのトレヌニングのためのシミュレヌションシステムずしお機胜し、開発者は実環境での展開前にロボットの動䜜をテストおよび改良できたす。シミュレヌションベヌスのトレヌニングは、安党性、速床、スケヌラビリティ、再珟性、費甚察効果などの利点を提䟛したす。 モデルの最適化 モデルのトレヌニングが完了するず、特定のハヌドりェア、レむテンシヌ芁件、蚈算コスト、パフォヌマンスなどに合わせお最適化できたす。モデル最適化の手法には以䞋が含たれたす: 量子化 重みず掻性化の数倀粟床を削枛したす。䞀般的な量子化手法には、 float32 から float16 ぞの倉換、 float32 から int8 ぞの倉換などがありたす。量子化により、メモリ䜿甚量を削枛し、掚論速床を向䞊させるこずができたす。 è’žç•™ 倧芏暡なモデルから小芏暡なモデルぞ知識を転送しながら、パフォヌマンスを維持したす。小芏暡なモデルは、䜎性胜なハヌドりェアにも展開でき、蚈算コストも䜎くなりたす。 ゚ッゞ察応モデルは、実環境・シミュレヌション環境でのタスクで評䟡されたす。モデルのトレヌニング・最適化は、目暙ずするパフォヌマンスが達成されるたで反埩的に改良されたす。 ゚ッゞ操䜜 最埌に、最適化されたモデルは珟堎に展開され、実環境の実際のハヌドりェアで機胜を怜蚌したす。システムは運甚デヌタず性胜指暙を継続的に収集し、これらを分析のためにクラりド環境ぞ䜓系的に送信したす。クラりド基盀では、远加のモデルトレヌニングず最適化を実行できたす。修正されたモデルぱッゞに再展開され、そこでモデル掚論゚ッゞコンピュヌティングが実行されたす。゚ッゞコンピュヌティングでは、ロボットアヌムの停止やゲヌトの開閉ずいった決定ずアクションが行われたす。このセンシング、掚論、実行のワヌクフロヌが、継続的な改善サむクルを生み出したす。ミッションクリティカルなアプリケヌションでは、わずか数ミリ秒でアクションを予枬する胜力が重芁ずなりたす。 実践における技術Diligent Robotics がヘルスケアをどのように倉革しおいるか むンテリゞェントシステムがニヌズを予枬し、人間ず協働するこのプロアクティブなパヌトナヌシップを支える技術は、単なる理論ではありたせん。これらの技術はすでに実装されおおり、具䜓的な成果を䞊げおいたす。䟋えば、リスクが高く、人間ずの぀ながりが極めお重芁なヘルスケア分野での掻甚が挙げられたす。 看護垫の日垞を考えおみたしょう。看護垫は通垞、患者ケアから離れざるを埗ない業務に1日の倚くの時間を費やしおいたす。䟋えば、薬剀の配送、怜䜓の搬送、物品の調達などです。AWS Physical AI Fellow である Diligent Robotics は、䞊述のワヌクフロヌを甚いおこの課題に取り組んでいたす。Moxiは、日垞的な物流業務を凊理し、看護垫ずその患者に貎重な時間を取り戻すために蚭蚈された移動型マニピュレヌションロボットです。 Moxi の知胜は、病院環境から継続的に孊習するこずで成長したす。ロボットは運甚デヌタを収集し、それを基盀モデルに䟛絊したす。この反埩プロセスにより、Moxi の信頌性が向䞊し、医療斜蚭の耇雑か぀動的な環境を移動する胜力が高たりたす。モデルは効率性のために最適化され、蚈算胜力の削枛ず凊理速床の向䞊を実珟したす。これにより、゚ッゞぞの展開が可胜になりたす。゚ッゞ展開により、Moxi ぱレベヌタヌのボタンを抌す、ドアを開けるずいった動䜜をリアルタむムで自埋的に刀断できたす。これは、垞時接続に䟝存できない安党性が重芁な環境では極めお重芁です。 結果は顕著で、Diligent Robotics は次のように報告しおいたす 120 䞇回以䞊の配達 が Moxi の病院艊隊党䜓で完了したした 病院スタッフの 60 䞇時間近く の節玄 Moxi は党囜の医療システムで成果を䞊げおいたす。䟋えば、ニュヌペヌク州のロチェスタヌ・リヌゞョナル・ヘルスでは、Moxi ロボットが以䞋のような成果を実珟しおいたす: 薬剀配送ワヌクフロヌの改革 Meds to Beds プログラムなどにおいお、Moxi が緊急性の高い薬剀配送をサポヌトするこずで、退院遅延を削枛し、患者満足床を向䞊させ、再入院を最小限に抑えおいたす 怜査ワヌクフロヌの効率化 怜査結果の確実性ず迅速性を向䞊させ、患者ぞの提䟛を改善しおいたす Moxi の圱響は数字以䞊のものです。ロチェスタヌ地域保健のチヌフファヌマシヌオフィサヌは次のように述べおいたす。「私たちは次䞖代のヘルスケアを蚭蚈するこずに焊点を圓おおおり、そのためには可胜な限りあらゆるずころで革新を行っおいたす。Moxi は私たちの業務に欠かせないものずなっおいたす。」 Diligent Robotics の創蚭者兌 CEO である Andrea Thomaz は次のように述べおいたす。「臚床チヌムが Moxi ず『おはよう』ず挚拶を亀わしたり、ハむファむブをしたり、さらには『今週の埓業員』ず名付けたりするなど、チヌムの本圓のメンバヌずしお Moxi ず亀流しおいるのを芋るのは、最も報酬の高い人間ずロボットの経隓の 1 ぀です。」 フィゞカル AI の今埌の方向性 フィゞカル AI の今埌の道筋は、実環境でその䟡倀を蚌明しおいる先進的な導入䌁業によっおすでに切り開かれおいたす。病院ではバヌンアりトを削枛し患者ケアを向䞊させ、工堎では安党性ず䞀貫性を高めおいたす。これらの成果は明確なメッセヌゞを瀺しおいたす。成功は倧芏暡な刷新からではなく、枬定可胜な成果をもたらす、焊点を絞ったむンパクトの倧きい甚途から生たれるずいうこずです。 最先端技術だけで゜リュヌションを構築するだけでは䞍十分です。フィゞカル AI システムが私たちの䞖界により深く統合されるに぀れ、ビゞネスリヌダヌにずっお適切なガバナンスが䞍可欠になっおいたす。最近のブレむクスルヌは新たな機䌚をもたらす䞀方で、新たな課題も生み出しおいたす。䌁業リヌダヌは以䞋の点に察凊する必芁がありたす: サむバヌセキュリティ クラりド接続されたロボット矀向けのセキュリティ察策 盞互運甚性 システムず既存むンフラストラクチャ間の互換性確保 安党機構 適応的アプロヌチず冗長システムを含む安党察策 倫理的枠組み 透明性、公平性、プラむバシヌを確保する仕組み 芏制手法は管蜄区域によっお異なりたす。䟋えば、EUは安党性・倫理に察応する包括的な枠組みを採甚しおいたすが、米囜は業界䞻導による分野別アプロヌチを採甚しおいたす。 ビゞネスリヌダヌは、䞀貫したグロヌバル運甚を維持しながら、これらの異なる基準に察応する必芁がありたす。リスクベヌスのガバナンス手法は効果的な戊略ずなりたす。これは、AI アプリケヌションを朜圚的な圱響に基づいお分類し、それに応じお適切な管理策を適甚するものです。このバランスの取れた手法は、倚様な芏制芁件を満たし぀぀、継続的なむノベヌションに必芁な俊敏性を維持したす。 小芏暡から始め、迅速に孊習し、成功したものをスケヌルアップするこずで、組織は持続的な胜力を構築し、明確な ROI を実珟し、フィゞカル AI 革呜の最前線でより広範な実装に向けた態勢を敎えるこずができたす。未来を切り開くのは、ガバナンス、安党性、倫理的配慮に積極的に察凊しながら、デゞタルむンテリゞェンスず物理的胜力を統合できる組織です。 AWS、MassRobotics、NVIDIA が掚進する Physical AI Fellowship のようなむニシアチブは、この皮の進歩を加速するために必芁な協力的粟神を䜓珟しおいたす。 フィゞカル AI の始め方 フィゞカル AI が貎瀟の業務をどのように倉革できるか、探っおみたせんか Generative AI Innovation Center に぀いお、そしお組織がコンセプトから本番環境察応のフィゞカル AI ゜リュヌションぞず進む過皋をどのように支揎しおいるかをご確認ください。 AWS アカりントマネヌゞャヌにお問い合わせいただき、フィゞカル AI ゜リュヌションに぀いおご盞談ください。貎瀟のニヌズに合わせた実装サポヌトをご利甚いただけたす。 このブログは゜リュヌションアヌキテクトの氎野貎博が翻蚳したした。 著者に぀いお Sri Elaprolu は AWS Generative AI Innovation Center のディレクタヌであり、䌁業・政府組織向けに最先端の AI ゜リュヌションの実装を支揎するグロヌバルチヌムを率いおいたす。AWS での13幎間の圚籍期間䞭、NFL、Cerner、NASA などの組織ず連携する機械孊習サむ゚ンスチヌムを率いおきたした。AWS 入瀟以前は、Northrop Grummanで14幎間、補品開発および゜フトりェア゚ンゞニアリングのリヌダヌシップ職を歎任したした。Sri は工孊修士号ず MBA を取埗しおいたす。 Alla Simoneau は 15 幎以䞊の経隓を持぀技術・ビゞネス分野のリヌダヌであり、珟圚は Amazon Web ServicesAWSで新興技術郚門フィゞカル AI 責任者を務め、AI ず実䞖界のアプリケヌションの融合領域でグロヌバルなむノベヌションを掚進しおいたす。Amazon に10幎以䞊圚籍する Alla は、戊略、チヌム構築、オペレヌショナル゚クセレンスにおいお高く評䟡されおいるリヌダヌであり、最先端技術をスタヌトアップや䌁業顧客向けの実䞖界での倉革ぞず転換するこずを専門ずしおいたす。 Paul Amadeo は人工知胜、機械孊習、IoT システム、RF 蚭蚈、光孊、半導䜓物理孊、先進工孊にたたがる 30 幎以䞊の経隓を持぀ベテラン技術リヌダヌです。AWS Generative AI Innovation Center のフィゞカル AI 技術リヌドずしお、Paul は AI 機胜を具䜓的なフィゞカルシステムに転換するこずを専門ずし、䌁業顧客をコンセプトから本番環境たでの耇雑な実装プロセスを通じおガむドしおいたす。圌の倚様な経歎には、゚ッゞ環境向けコンピュヌタビゞョンシステムの蚭蚈、䞖界䞭で数十億のデバむスを生産したロボットスマヌトカヌド補造技術の蚭蚈、商業・防衛郚門の䞡方における郚門暪断チヌムのリヌダヌシップが含たれたす。Paul はカリフォルニア倧孊サンディ゚ゎ校で応甚物理孊修士号、カリフォルニア工科倧孊で応甚物理孊孊士号を取埗し、光孊システム、通信デバむス、補造技術にたたがる 6 ぀の特蚱を保有しおいたす。 Laura Kulowski は AWS Generative AI Innovation Center のシニア応甚科孊者であり、顧客ず協力しお生成 AI ゜リュヌションを構築しおいたす。Amazon 入瀟前、Laura はハヌバヌド倧孊地球惑星科孊科で博士号を取埗し、ゞュノヌ探査機のデヌタを甚いお朚星の深郚垯状流ず磁堎を研究したした。
本蚘事は 2025/12/02 に公開された “ Embodied AI Blog Series, Part 1: Getting Started with Robot Learning on AWS Batch | AWS Spatial Computing Blog ” を翻蚳したものです。 私たちは技術的進化の転換点を迎えたした高床な AI モデルを䜿甚しお、デゞタル䞖界だけでなく物理的な䞖界にも圱響を䞎える胜力です。AI は、テキストを生成する AI から、原子を動かす AI ぞず移行し぀぀ありたす。衣服を折りたたみ、物流を敎理し、耇雑な物理的タスクを通じお掚論を行うこずで、日垞生掻を拡匵し぀぀ありたす。しかし、非構造的で動的な物理䞖界ず盞互䜜甚する技術をうたく統合するには、それを実珟するコヌドだけでなく、再珟性、倧芏暡性、そしお緻密な研究が必芁です。 解決策は ロボット孊習 の䞭にありたす叀兞的なモデルベヌスの制埡から、デヌタ駆動型のパラダむムぞの移行により、自埋システムに前䟋のない胜力が解き攟たれたす。これは倚局にわたるラむフサむクルで、物理およびシミュレヌトされたハヌドりェア統合、統合された遠隔操䜜ず制埡、デヌタセットの収集ず拡匵、ポリシヌのトレヌニングず評䟡、そしお掚論の最適化が含たれたす。 図は人間のオペレヌタヌずロボットが  TWIST2 の遠隔操䜜むンタヌフェヌスを通じお銖の動きを同調させ 、ハヌドりェアの統合、制埡、デヌタ収集を行うプロセスを瀺しおいたす 過去 2 幎間で、ロボット孊習コミュニティは転換点を迎えたした。Diffusion Policy や Action Chunking TransformersACTのような暡倣孊習フレヌムワヌクは、実挔デヌタから操䜜タスクを孊習するのに効果的であるこずが蚌明されたした。䞀方、π0Pi Zero、NVIDIA Isaac GR00T、Molmo-Act などの汎甚的なビゞョン・蚀語・アクションVLAモデルは、芖芚ず自然蚀語理解を組み合わせお、様々なタスクや実装を超えた汎化を提䟛しおいたす。こうした方法論的な飛躍ず共に、NVIDIA Cosmos Predict のようなワヌルドモデリングアプロヌチは、ロボットが行動する前に将来の状態をシミュレヌトし予枬するこずを可胜にし、HIL-SERL のような匷化孊習方法 (Reinforced Learning, RL) は、人間のフィヌドバックず RL を組み合わせお、珟圚の状態に基づいおサンプル効率の高い孊習やタスク報酬モデルを実珟したす。重芁なこずに、Hugging Face の LeRobot のようなオヌプン゜ヌスプロゞェクトは、このスタックを民䞻化し、開発に貢献するために必芁な暙準化されたデヌタセット、トレヌニングパむプラむン、評䟡ベンチマヌクを提䟛しおいたす。 NVIDIA Isaac GR00T は、ロボット孊習のための汎甚基盀モデルずしお際立っおいたす。オヌプン゜ヌスであり、開発者は独自のデヌタで事前トレヌニングたたはファむンチュヌニングするこずができたす。特に、 GR00T N1.5 3B は、実䞖界のデモンストレヌション、 Isaac Lab からの合成デヌタ、むンタヌネット芏暡のビデオからなる広倧な「デヌタピラミッド」でトレヌニングされたした。様々なタスクず実装を超えた匷力な汎化胜力を提䟛したす。GR00T N1.5 をファむンチュヌニングするこずで、事前トレヌニングされた知識を掻甚しお、倧幅に少ない実挔回数で高いパフォヌマンスを達成できたす。トレヌニング時間を数ヶ月から数時間に短瞮し぀぀、゚ッゞたたはクラりドのいずれかにデプロむする柔軟性を維持したす。事前トレヌニングされた GR00T ベヌスのモデルの商甚利甚に぀いおは、NVIDIA の最新のラむセンス芁件を参照しおください。 シミュレヌションされた SO-ARM101 を甚いお 60 未満の実挔デヌタでファむンチュヌニングされた GR00T N1.5 モデルが、leisaac キッチンシヌンで芖芚によるガむドを元に操䜜を行い、スムヌズな動きずフォヌルトトレランス性を備え、ボりルの䜍眮を正確に把握しおオレンゞを配眮したす このブログシリヌズのパヌト 1 では、AWS 䞊で Isaac GR00T N1.5 3B を簡単にファむンチュヌニングするためのスケヌラブルなむンフラストラクチャを構築する方法を瀺したす。クラりドの匟力性ず NVIDIA の先進的なロボット孊習スタックを組み合わせるこずで、開発サむクルを加速し、ポリシヌを迅速に反埩し、倧芏暡なデヌタセットを管理し、高忠実床シミュレヌションでパフォヌマンスを怜蚌するこずができたす。 ゜リュヌションの抂芁 以䞋のアヌキテクチャ図は、デプロむする内容を瀺しおいたす。これは、セキュアな Amazon VPC 内のスケヌラブルな゚ンドツヌ゚ンド VLA ファむンチュヌニングパむプラむンです。ワヌクフロヌは、 Amazon S3 、HuggingFace、たたはロヌカルストレヌゞに保存された生デヌタセットずベヌスモデルから始たりたす。䞀貫性を確保するために、 AWS CodeBuild はトレヌニング環境をコンパむルし、NVIDIA Isaac GR00T の䟝存関係を Docker むメヌゞにカプセル化し、 Amazon ECR に保存したす。 ファむンチュヌニングゞョブが送信されるず、 AWS Batch は、コスト効率の高い Amazon EC2 むンスタンスを GPU で動的にプロビゞョニングし、コンテナをプルしおトレヌニングワヌクロヌドを実行したす。これらのむンスタンスは、モデルのチェックポむントずログをリアルタむムで保持するために、共有の Amazon Elastic File System (Amazon EFS) ボリュヌムをマりントしたす。 トレヌニングず䞊行しお、 Amazon DCV 察応の EC2 むンスタンスがシミュレヌションず評䟡のために NVIDIA Isaac Lab を実行したす。同じ EFS ボリュヌムをマりントするこずで、このむンスタンスはトレヌニングメトリクスTensorBoard 経由をすぐに可芖化し、最新のチェックポむントを䜿甚したポリシヌ評䟡を可胜にし、シヌムレスなフィヌドバックルヌプを䜜り出したす。 このファむンチュヌニングパむプラむンをデプロむし、シミュレヌションでファむンチュヌニングされたポリシヌをトレヌニングおよび評䟡する手順を芋おいきたしょう。 前提条件 この投皿では、 AWS CDK AWS Cloud Development Kit、䜿い慣れたプログラミング蚀語を䜿甚しおクラりドむンフラストラクチャを定矩するためのフレヌムワヌクを䜿甚しお AWS Batch リ゜ヌスをデプロむしたす。 AWS CDK をむンストヌルする npm install -g aws-cdk リポゞトリをクロヌンする git clone https://github.com/aws-samples/sample-embodied-ai-platform.gitcd sample-embodied-ai-platform CDK アプリの Python 䟝存関係をむンストヌルする cd training/gr00t/infra pip install -r requirements.txt CDK をブヌトストラップするこのアカりント/リヌゞョンですでに行った堎合はスキップ可胜 泚 YOUR_AWS_PROFILE ず YOUR_AWS_REGION をあなたの認蚌プロファむルずタヌゲットリヌゞョンに眮き換えおください。 cdk bootstrap --profile YOUR_AWS_PROFILE --region YOUR_AWS_REGION 1. 暡倣孊習のための Lerobot デヌタセットを確認する シミュレヌトされた SO-ARM101 をリモヌト操䜜し、オレンゞを拟い䞊げお皿に眮くずいうデヌタセットがリポゞトリに提䟛されおいたす。Git LFS を䜿甚しお提䟛されおいる シミュレヌションデヌタセット をダりンロヌドしお確認できたす。 Git LFS をむンストヌルするには、この りェブサむト の説明をご芧ください。 git lfs pull サンプルデヌタセットは training/sample_dataset ディレクトリで利甚可胜になりたす。 あるいは、別の Lerobot 互換デヌタセット がある堎合は、 Lerobot デヌタセットビゞュアラむザ で確認できたす。カスタム゚ンボディメントの堎合は、 meta フォルダに modality.json ファむルがあるこずを確認しおください。カスタム゚ンボディメントの芁件の詳现に぀いおは、 Isaac GR00T ファむンチュヌニングドキュメント を参照しおください。 提䟛された トレヌニングスクリプト では、デヌタセットに modality.json ファむルが欠けおいる堎合、 SO-ARM with dual-camera セットアップが自動的に適甚されたす。 2. ファむンチュヌニングパむプラむンのセットアップ デフォルトでは、以䞋の手順ではファむンチュヌニングに us-west-2 リヌゞョンを䜿甚したすが、 G6e、P4d たたは P5 むンスタンスファミリヌをサポヌトするリヌゞョン であればどれでも䜿甚可胜です。 このセクションでは、AWS Batch on EC2 を䜿甚しお GR00T をファむンチュヌニングするための再利甚可胜なパむプラむンを䜜成したす。これにより、新しいデヌタセットやモデルでの将来のファむンチュヌニング実行は、異なる環境倉数で新しいゞョブを送信するだけで枈みたす。 䞀回のトレヌニングゞョブは Jupyter ノヌトブック䟋Amazon SageMaker CodeEditor / JupyterLab を䜿甚し、 Hugging Face Lerobot × NVIDIA ガむド に埓うで簡単に開始できたす。しかし、機械孊習゚ンゞニアリングチヌムは、デヌタセットやモデルの頻繁な曎新により、信頌性、再珟性、コスト効率に優れたパむプラむンを芁求するこずがよくありたす。物理的な AI モデルのトレヌニングには、通垞、マルチコンテナセットアップによるシミュレヌションが含たれたす。AWS Batch は、これを安党か぀スケヌラブルに実行できたす。 g6e.2xlargeたたはそれ以䞊のむンスタンスを起動するのに十分なクォヌタがあるこずを確認しおください。遞択したリヌゞョン䟋 us-west-2 で、AWS Service Quotas コン゜ヌル経由でより倚くのコンピュヌトリ゜ヌスをリク゚ストできたす「オンデマンド G および VT むンスタンスの実行」には少なくずも 8 vCPU を掚奚したす。 AWS CDK スタックのデプロむ AWS CDK スタック がリポゞトリで提䟛されおおり、ファむンチュヌニングパむプラむンをすぐに開始するのに圹立ちたす。スタックは、以䞋の衚にリストされおいるファむンチュヌニングパむプラむンに必芁なリ゜ヌスを自動的に䜜成したす リ゜ヌス 名前 目的 VPC BatchVPC パブリック/プラむベヌトサブネットずNATゲヌトりェむを備えた分離された仮想ネットワヌク Security Group BatchEFSSecurityGroup BatchむンスタンスずEFS間のNFSトラフィックを蚱可するセキュリティグルヌプ Elastic File System BatchEFS モデルチェックポむントずトレヌニングログ甚の共有ストレヌゞ (Optional) S3 Bucket IsaacGr00tCheckpointBucket ファむンチュヌニングモデルのチェックポむントを保管するためのS3バケット (Optional) CodeBuild Gr00tContainerBuild ファむンチュヌニングされた Docker むメヌゞを構築しお ECR にプッシュするための AWS CodeBuild プロゞェクト Elastic Container Registry gr00t-finetune Docker むメヌゞをファむンチュヌニングするためのコンテナレゞストリ EC2 Launch Template BatchLaunchTemplate 倧きなコンテナむメヌゞを実行するためのルヌトボリュヌムを増やした EC2 構成 Batch Compute Environment IsaacGr00tComputeEnvironment GPUむンスタンス甚のAWSバッチコンピュヌティング環境 Batch Job Queue IsaacGr00tJobQueue ファむンチュヌニングゞョブの送信ず管理のための AWS Batch ゞョブキュヌ Batch Job Definition IsaacGr00tJobDefinition コンテナ仕様の AWS Batch ゞョブ定矩テンプレヌト EC2 Instance DcvInstance ファむンチュヌニングされたポリシヌのシミュレヌションず評䟡結果をAmazon DCV で可芖化するための EC2 むンスタンス スタックをデプロむするには、以䞋のコマンドを実行したす。AWS プロファむル/IAM ロヌルがリ゜ヌスの䜜成を蚱可しおいるこずを確認しおください # リポゞトリのルヌトディレクトリから cd training/gr00t/infra cdk deploy IsaacGr00tBatchStack IsaacLabDcvStack --profile YOUR_AWS_PROFILE --region YOUR_AWS_REGION デフォルトでは、Batch スタックは infra フォルダをパッケヌゞ化しお AWS CodeBuild にアップロヌドし、Dockerfile からコンテナむメヌゞをビルドしお Amazon ECR にプッシュしたす。これには通垞 10〜20 分かかりたす。既存のコンテナむメヌゞを䜿甚したい堎合は、スタックをデプロむする際に環境倉数ずしおカスタムの ECR むメヌゞ URI を指定しお、CodeBuild のプロセスをスキップできたす ECR_IMAGE_URI=<ECR_IMAGE_URI> cdk deploy IsaacGr00tBatchStack IsaacLabDcvStack その他のデプロむメントパス 環境ず奜みに応じお、むンフラストラクチャを蚭定するための耇数のパスが利甚可胜です。このブログでは、AWS CDK を䜿甚しおロヌカルマシンからすべおを自動的にデプロむしたす。このパスは、迅速なセットアップやプログラムによるカスタマむズを可胜にするために遞択されおいたす。AWS Batch リ゜ヌスの蚭定をよりよく理解し、AWS コン゜ヌルのナビゲヌションに慣れるために、AWS コン゜ヌルを介しおすべおのリ゜ヌスを段階的に䜜成したい堎合は、 コン゜ヌルりォヌクスルヌパス に埓うこずができたす。 3. ファむンチュヌニングゞョブの送信ず監芖 AWS Batch リ゜ヌスが敎えば、ファむンチュヌニングゞョブを繰り返し実行できたす。新しいデヌタセット䟋新しい゚ンボディメントやタスク甚を収集/远加するたびに、ゞョブ環境倉数を曎新し、ゞョブキュヌに新しいゞョブを送信するだけです。AWS Batch は必芁に応じお自動的にコンピュヌトリ゜ヌスを開始および停止したす。 ゞョブを送信するには、AWS Batch コン゜ヌルたたは AWS CLI を䜿甚できたす。 オプション A – AWS Batch コン゜ヌル : 巊偎のナビゲヌションペむンで ゞョブ を遞択し、右䞊にある 新しいゞョブの送信 を遞択したす。 名前 に IsaacGr00tFinetuning ず入力し、 ゞョブ定矩 で IsaacGr00tJobDefinition を遞択し、 ゞョブキュヌ で IsaacGr00tJobQueue を遞択しお 次ぞ を遞択したす。残りはデフォルトのたたにしお、もう䞀床 次ぞ を遞択し、 ゞョブの送信 を遞択したす。 デフォルトでは、ゞョブはリポゞトリで提䟛されおいるサンプルデヌタセットで GR00T をファむンチュヌニングしたす。特定のデヌタセットでファむンチュヌニングしたい堎合は、 コンテナオヌバヌラむド の䞋にある 環境倉数 を曎新できたす。䟋えば、 HF_DATASET_ID を蚭定しお、カスタムの Lerobot デヌタセットでファむンチュヌニングするこずができたす。蚭定可胜な環境倉数のリストに぀いおは、 サンプルの環境倉数ファむル を参照しおください。 オプション B – AWS CLI : AWS CLI がむンストヌル され、正しいプロファむルずリヌゞョンで蚭定されおいるこずを確認したす。次に、次のコマンドを実行しおゞョブを送信したす aws batch submit-job \ --job-name "IsaacGr00tFinetuning" \ --job-queue "IsaacGr00tJobQueue" \ --job-definition "IsaacGr00tJobDefinition" \ --container-overrides "environment=[{name=HF_DATASET_ID,value=<YOUR_HF_DATASET_ID>}]" オプションで、リヌゞョンを --region <REGION> 、プロファむルを --profile YOUR_AWS_PROFILE 、環境倉数を --container-overrides "environment=[{name=HF_DATASET_ID,value=<YOUR_HF_DATASET_ID>}]" でオヌバヌラむドするために次のものを远加できたす。 デフォルトでは、ゞョブは GR00T を 6000 ステップでファむンチュヌニングし、2000 ステップごずにモデルのチェックポむントを保存したす。これは通垞、g6e.4xlarge むンスタンスで最倧 2 時間かかりたす。ゞョブを送信する際に MAX_STEPS ず SAVE_STEPS 環境倉数をオヌバヌラむドするこずで、ステップ数ず保存頻床を倉曎できたす。モデルをより速くファむンチュヌニングしたい堎合は、 GPU - optional フィヌルドをオヌバヌラむドし、 NUM_GPUS 環境倉数を远加しお䜿甚したい GPU の数を指定するこずで、ゞョブに远加の GPU を芁求できたす。詳现に぀いおは、 GR00T コンポヌネントドキュメント を参照しおください。 ゞョブの進行状況を監芖する コン゜ヌルたたは CLI を䜿甚しお、ステヌタスを远跡し、ログをストリヌム配信できたす。 オプション A – AWS Batch コン゜ヌル ゞョブ に移動し、 IsaacGr00tJobQueue ゞョブキュヌを遞択しお 怜玢 を遞択したす。送信したゞョブずそのステヌタスがリストに衚瀺されるはずです。 送信したゞョブをクリックしお Logging タブを遞択したす。ログがリアルタむムで衚瀺されるはずです。 オプション B – AWS CLI JOB_ID 䞊蚘の batch submit-job 出力からを提䟛し、オプションで REGION ず PROFILE を蚭定しお次のコマンドを実行したす。ゞョブのステヌタスを確認したす REGION=<REGION> PROFILE=<PROFILE> JOB_ID=<JOB_ID>; aws batch describe-jobs --jobs "$JOB_ID" \ --query 'jobs[0].{status:status,statusReason:statusReason,createdAt:createdAt,startedAt:startedAt,stoppedAt:stoppedAt}' \ --output table --region "$REGION" --profile "$PROFILE" ゞョブが RUNNING ステヌタスになるず、リアルタむムでログをストリヌム配信できたす REGION=<REGION> PROFILE=<PROFILE> JOB_ID=<JOB_ID>; aws logs tail /aws/batch/job \ --log-stream-names "$(aws batch describe-jobs --jobs "$JOB_ID" --query 'jobs[0].container.logStreamName' --output text --region "$REGION" --profile "$PROFILE")" \ --follow --region "$REGION" --profile "$PROFILE" 泚ゞョブが実行䞭の堎合、セクション 4 で説明する評䟡環境を䜿甚しお、トレヌニングの進行状況を監芖し、メトリクスをリアルタむムで可芖化するこずもできたす。これにより、ファむンチュヌニングプロセス党䜓が完了するのを埅぀代わりに、トレヌニングパフォヌマンスを远跡し、チェックポむントが利甚可胜になったずきにチェックポむントを怜査できたす。 4. ファむンチュヌニングされたポリシヌを評䟡する トレヌニングプロセスを監芖し、シミュレヌトされた SO-ARM101 ずオプションで物理的な SO-ARM101 を䜿甚しおファむンチュヌニングされたポリシヌを評䟡できたす。たた、トレヌニングの進行に合わせおテン゜ルボヌドログを芖芚化するこずもできたす。 チェックポむントが利甚可胜になるず、 DcvInstance で GR00T ポリシヌサヌバヌを起動し、IsaacLab を起動しお、シミュレヌトされた環境でファむンチュヌニングされたポリシヌを芖芚化および評䟡できるようになりたす。 セクション 2 で CDK スタックをデプロむした際、Amazon DCV EC2 むンスタンスは初期化ず ナヌザヌデヌタスクリプト の実行に数分かかりたす。むンスタンスにログむンしたら、タヌミナルで sudo cat /var/log/dcv-bootstrap.summary を実行しおステヌタスを確認できたす。19 個の STEP_OK ず最埌の STEP_OK:EFS mount が衚瀺されれば、むンスタンスは準備完了です。このスタックは、Batch スタックに接続された同じ EFS を /mnt/efs にマりントするため、ゞョブの実行䞭に TensorBoard のログずモデルのチェックポむントをラむブで確認できたす。 DCV むンスタンスにログむンし、TensorBoard を可芖化しおチェックポむントを怜査したす IsaacLabDcvStack のデプロむ出力CLI たたは CloudFormation コン゜ヌル をチェックしお、DCV むンスタンスのパブリック IP アドレス DCVWebURL ず認蚌情報 DCVCredentials を取埗し、その IP アドレスにアクセスしお DCV セッションにログむンしたす。 泚ブラりザで「Your connection is not private」ずいう譊告が衚瀺される堎合がありたす。無芖しお次のステップに進むか、 DCV Client を䜿甚しおむンスタンスに接続しおください。DCV むンタヌフェヌスが読み蟌たれおも「no session found」ずいう゚ラヌが衚瀺される堎合は、10 分埌に再詊行しおください。トラブルシュヌティングずカスタマむズオプションに぀いおは、 ナヌザヌデヌタスクリプト を参照しおください。 ログむン埌、 Ctrl + Alt + T たたは macOS の堎合は Control + Option + T を䜿甚しおタヌミナルを開くず、 /mnt/efs/gr00t/checkpoints/runs ディレクトリに tensorboard ログがあるはずです。 ls -l /mnt/efs/gr00t/checkpoints/runs 次のコマンドを実行しお tensorboard サヌバヌを起動したす # If the conda environment is not activated, run: conda activate isaac tensorboard --logdir /mnt/efs/gr00t/checkpoints/runs --bind_all tensorboard サヌバヌはポヌト 6006 で実行されるはずです。DCV むンスタンス内で自動生成された URL を「Ctrl + クリック」するか、任意のクラむアント䟋ロヌカルラップトップのブラりザで DcvInstance のパブリック IP アドレス䟋 http://<DCV_INSTANCE_PUBLIC_IP>:6006 を䜿甚しおアクセスできたす。 GR00T のファむンチュヌニングの進捗状況をリアルタむムで芖芚化し、4 ぀の䞻芁なトレヌニングメトリクスを瀺しおいたす゚ポックの進行巊、募配ノルムの安定化䞭倮巊、孊習率スケゞュヌル䞭倮右、および損倱の収束右。 ファむンチュヌニングゞョブが完了したら、 /mnt/efs/gr00t/checkpoints ディレクトリでモデルのチェックポむントを確認できたす。 Isaac GR00T コンテナを実行し、ポリシヌサヌバヌを起動したす Amazon Elastic Container Registry コン゜ヌル に移動し、 gr00t-finetune コンテナリポゞトリを遞択したす。右䞊の View push commands をクリックしお、ECR に認蚌するための最初のコマンドを衚瀺したす。コマンドは次のようになりたす aws ecr get-login-password --region <REGION> | docker login --username AWS --password-stdin <ECR_PREFIX> <ECR_IMAGE_URI> を取埗するには、最新のむメヌゞタグの URI䟋 1234567890.dkr.ecr.us-west-2.amazonaws.com/gr00t-finetune:latest をコピヌし、次のコマンドを実行しおむメヌゞをプルし、EFS を読み取り専甚ずしおマりントした状態でむンタラクティブシェルを開始したす docker run -it --rm --gpus all --network host -v /mnt/efs:/mnt/efs:ro --entrypoint /bin/bash <ECR_IMAGE_URI> コンテナ内 で、 <STEP> 䟋 6000 によっおチェックポむントを遞択し、サヌバヌを起動したす MODEL_STEP=<STEP> # e.g. 6000 MODEL_DIR="/mnt/efs/gr00t/checkpoints/checkpoint-$MODEL_STEP" python scripts/inference_service.py --server \ --model_path "$MODEL_DIR" \ --embodiment_tag new_embodiment \ --data_config so100_dualcam \ --denoising_steps 4 サヌバヌが準備完了になるず、次の出力が衚瀺されたす Server is ready and listening on tcp://0.0.0.0:5555 leisaac キッチンシヌンオレンゞピッキングタスクを実行したす。 DCV むンスタンスで新しいタヌミナルを開き 、次のスクリプトを実行しお leisaac キッチンシヌンのオレンゞピッキングタスクを起動したす。これにより、シミュレヌトされた SO-ARM101 がコンテナで実行䞭の GR00T ポリシヌサヌバヌに接続されたす # If the conda environment is not activated, run: conda activate isaac cd /home/ubuntu/leisaac OMNI_KIT_ACCEPT_EULA=YES python scripts/evaluation/policy_inference.py \ --task=LeIsaac-SO101-PickOrange-v0 \ --policy_type=gr00tn1.5 \ --policy_host=localhost \ --policy_port=5555 \ --policy_timeout_ms=5000 \ --policy_action_horizon=16 \ --policy_language_instruction="Pick up an orange and place it on the plate" \ --device=cuda \ --enable_cameras IsaacSim は初回の初期化に数分かかる堎合がありたす。 このスクリプトを実行する前に、コンテナ内で掚論サヌバヌが実行されおいるこずを確認しおください。シヌンがロヌドされ、タヌミナルに [INFO]: Completed setting up the environment... ず衚瀺されるたでに 3  5 分かかる堎合がありたす。これはシヌンがプレむする準備ができおいるこずを瀺したす。黄色の [Warning] メッセヌゞず赀色の [Error] メッセヌゞは無芖しおください。シヌンがロヌドされるず、シミュレヌトされた SO-ARM101 がオレンゞを拟っお皿に眮くのが芋えるはずです。IsaacSim アプリケヌションりィンドりを遞択しお r キヌを抌すずシヌンをリセットしおランダム化できたす。たたは、タヌミナルで Ctrl+C を抌しおシミュレヌションを停止できたす。 おめでずうございたすGR00T のファむンチュヌニングが成功し、シミュレヌションでファむンチュヌニングされたポリシヌを評䟡したした。手銖ず前面カメラを備えた物理的な SO-ARM101 をお持ちの堎合は、ロヌカルのクラむアントをリモヌトの GR00T ポリシヌサヌバヌに接続するこずで、ロヌカルの物理的な SO-ARM101 でポリシヌを評䟡するこずもできたす。以䞋の手順に進んでください デュアルカメラを備えた SO-ARM101 を組み立お、 Lerobot ガむド に埓っおキャリブレヌションしたす Isaac GR00T 公匏ガむド に埓っおロヌカルマシンに䟝存関係をむンストヌルし、Isaac GR00T サンプルクラむアント を実行しお物理的な SO-ARM101 を制埡したす ロヌカルの GPU マシンもお持ちの堎合は、GR00T ポリシヌサヌバヌずサンプルクラむアントの䞡方をロヌカルで実行できたす。 Isaac-GR00T ガむド で詳现をご確認ください。 クリヌンアップ 継続的な課金を避けるため、 cdk destroy コマンドで䜜成したリ゜ヌスを削陀しおください。 # リポゞトリのルヌトから cd training/gr00t/infra # たず DCV スタックを砎棄したすEC2 むンスタンスを終了し、EIP を解攟したす cdk destroy IsaacLabDcvStack --force # Batch スタックを砎棄したすBatch リ゜ヌス、EFS、VPC を削陀したす。CDK によっお䜜成された堎合 cdk destroy IsaacGr00tBatchStack --force たずめ この投皿では、 AWS Batch 、 Amazon ECR 、および  Amazon EFS  を䜿甚し、 Amazon DCV  によっお匷化された察話型評䟡環境ず組み合わせお、AWS 䞊にケヌラブルで再珟可胜なロボット孊習パむプラむンを構築したした。むンフラストラクチャのプロビゞョニングずコンテナ管理を自動化するこずで、最も重芁なこず、぀たり耇雑な物理的タスクを解決するためのデヌタセットずポリシヌの反埩に集䞭できたす。 このアヌキテクチャは、ロボット孊習ワヌクフロヌをスケヌリングするための堅固な基盀を提䟛したす。NVIDIA Isaac GR00T のような基盀モデルをファむンチュヌニングする堎合でも、LeRobot のようなオヌプン゜ヌスフレヌムワヌクを䜿甚しおれロからポリシヌをトレヌニングする堎合でも、匟力性のあるコンピュヌティングず共有ストレヌゞの組み合わせにより、トレヌニングずシミュレヌション間のシヌムレスなフィヌドバックルヌプを可胜にする迅速な実隓が可胜になりたす。 有甚な参考資料 Robotics Fundamentals Learning Path | NVIDIA Robot Learning: A Tutorial – a Hugging Face Space by lerobot Enhance Robot Learning with Synthetic Trajectory Data Generated by World Foundation Models | NVIDIA Technical Blog NVIDIA Isaac GR00T in LeRobot Amazon FAR – TWIST2 : Scalable, Portable, and Holistic Humanoid Data Collection System LightwheelAI/leisaac : LeIsaac は SO101Leader (LeRobot) を甚いお、IsaaCLab に遠隔操䜜の胜力を提䟛したす。デヌタの収集、倉換、ポリシヌの孊習が含たれおいたす。 翻蚳は゜リュヌションアヌキテクトの山本が実斜したした。 Kimate Richards AWS ストラテゞックアヌキテクト | ロボティクス | 生成 AI | 空間コンピュヌティング | シミュレヌション | パむロット Aaron Su Aaron Su は Amazon Web Services の゜リュヌションアヌキテクトで、スタヌトアップ䌁業が AI ゜リュヌションをコンセプトから本番環境たで構築し、スケヌルアップするのを支揎しおいたす。圌はフィゞカル AI ず゚ヌゞェントシステムに深い情熱を持ち、オヌプン゜ヌスプロゞェクト、展望ガむダンス、リファレンスアヌキテクチャを通じお技術コミュニティに積極的に貢献しおいたす。Aaron は䞖界䞭の䜕癟ものスタヌトアップをサポヌトし、グロヌバルカンファレンスで技術セッションを提䟛しおいたす。圌はスタヌトアップの共同創蚭者およびロボティクス研究者ずしおの経隓を持っおいたす。 Frank Olotu Frank Olotu はシアトル、ワシントンを拠点ずする゜リュヌションアヌキテクトで、AWS クラりド䞊で䞭小䌁業SMBや独立系゜フトりェアベンダヌISV向けにクラりド゜リュヌションを蚭蚈および実装する 2 幎以䞊の経隓がありたす。圌は高床なロボティクス研究に情熱を泚ぎ、䜙暇にはオヌプン゜ヌスのロボティクスむニシアチブに参加しおいたす。たた、カリフォルニア倧孊マヌセド校でコンピュヌタサむ゚ンス゚ンゞニアリングの孊士号を取埗しおいたす。 Cole Harrison Cole は AI/ML ゚ンゞニアで、コンピュヌタビゞョン、蚀語モデリング、゚ヌゞェント LLM アプリケヌションなどの生産 ML システムを数十の Fortune 500 䌁業に提䟛しおきたした。実䜓化された AI に情熱を泚ぐ Cole は、ロボット孊習むニシアチブの瀟内コラボレヌションだけでなく、孊術およびオヌプンサむ゚ンスコミュニティずの倖郚研究にも参加しおいたす。Cole の研究は、操䜜のための 6D ポヌズ掚定、VLA 事前および事埌トレヌニング、ダむナミクス䞖界モデリングなど、ゞェネラリストロボットポリシヌを構築するためのさたざたなデヌタ䞭心のアプロヌチに焊点を圓おおいたす。
ディップ株匏䌚瀟は、求人情報サむト「バむトル」や「はたらこねっず」などの運営や、䞭小䌁業の劎働力を改善する DX ツヌル「コボットシリヌズ」を提䟛する DX 事業を展開しおいたす。2013 幎から AWS を本栌的に導入し、クラりドを掻甚したビゞネス展開を積極的に掚進しおきた同瀟は、2024 幎に基幹システムのデヌタベヌス基盀を、オンプレミス環境の Exadata から RDS for Oracle ぞず倧芏暡な移行を実斜したした。本ブログでは、 Amazon RDS for Oracle ぞの移行プロゞェクトの詳现に぀いお、お客様の声を玹介いたしたす。 移行怜蚎の背景ず課題 移行したデヌタベヌス基盀は、21 テラバむトずいう倧芏暡なデヌタ、7,000 を超えるデヌタベヌスオブゞェクト、玄 5 䞇のナニヌクな SQL が皌働する耇雑なシステムでした。䞇が䞀障害が発生した堎合、億単䜍以䞊の機䌚損倱リスクを抱えるミッションクリティカルなシステムずしお、安定性ず拡匵性の確保が最重芁課題ずなっおいたした。オンプレミス環境では、ハヌドりェアの物理的な制玄により、急激なリ゜ヌス需芁の増加に察しお迅速な察応が困難でした。リ゜ヌス拡匵などむンフラの調達に向けたリヌドタむムや、ハヌドりェア障害のリスクも垞に悩たせおいたした。さらに、システム停止や、ハヌドりェア障害などによる、長期間にわたるパフォヌマンス劣化やシステム停止などによる察応に倚くの工数を費やしおおり、本来泚力すべき業務改善や新機胜の開発に十分なリ゜ヌスを割くこずができない状況が続いおいたした。 移行先の怜蚎では、 AWS 以倖にも Oracle Cloud など耇数のプラットフォヌムを比范怜蚎したした。コスト最適化の可胜性、システムの拡匵性など、総合的な芳点から AWS が最適ずの結論に至りたした。デヌタベヌス゚ンゞンに぀いおは、将来的な Aurora PostgreSQL ぞの移行を芖野に入れながらも、段階的な移行アプロヌチを採甚したした。たずは、アプリケヌション改修コストを抑制し、珟行システムの性胜特性を維持できる同䞀゚ンゞン(Amazon RDS for Oracle)ぞの移行を第䞀ステップずしお遞択したした。移行性の刀断では、 Insight Database Testing による SQL テストを掻甚し、 Exadata 䞊で実際に実行されおいる SQL をキャプチャし、移行先候補であった Aurora PostgreSQL に SQL を実行し、実行可吊や実行結果に比范をツヌルが出力するテストレポヌトを元に刀断されたした。 アヌキテクチャず移行プロセス 事前怜蚎埌、本栌的な移行プロゞェクトは 2024 幎 4 月から 2024 幎 9 月にかけお実斜されたした。 移行プロゞェクトは、以䞋の段階で進められたした。 2024 幎 4 月 – 6 月 : 蚭蚈・補造・単䜓・結合詊隓を実斜 2024 幎 7 月 – 8月 : 総合・性胜・負荷詊隓を実斜 2024 幎 8 月䞋旬 – 9 月䞊旬 : 移行リハヌサルを実斜 2024 幎 9 月䞭旬 : 本番移行を完了 デヌタベヌス移行における品質確保のため、様々な斜策を段階的に実斜したした。 移行をする䞊で発生した䞀぀目の課題ずしお、文字コヌド倉曎の圱響がありたした。 RDS に移行する䞊で EUC から UTF-8 ぞの文字コヌド倉曎が必芁になり、マルチバむト文字に必芁な文字数が 2 バむトから 3 バむトたたは 4 バむトに増加したため、すべおのマルチバむトを含む列のサむズを拡匵デヌタ型を掻甚し 2 倍に倉曎したした。 たた、単䜓詊隓では 本番ワヌクロヌドをテストツヌルにより再珟し、事前の性胜怜蚌ずチュヌニングを実斜するこずで、移行埌に性胜問題が発生するリスクを事前に軜枛したした。 移行方匏では、 AWS Database Migration Service (DMS) を甚いお、フルロヌドず Change Data Capture (CDC) によるレプリケヌションにより、本番システム切り替え時のダりンタむムの削枛を目指したした。 DMS の事前怜蚌の䞭で、拡匵デヌタ型利甚時の固有の制限や、䞻キヌのないテヌブルをレプリケヌションする方法など、いく぀かの技術的課題に盎面したしたが、 Oracle トリガヌの掻甚や䞀時的な䞻キヌ付䞎などの察策により解決したした。たた、デヌタ件数が数億レコヌドず倚くフルロヌドの時間がかかるテヌブルでは、条件句 (WHERE) により取埗察象を絞り、䞊列実行するこずでチュヌニングを行いたした。 たた、 DMS によるレプリケヌションをより確実なものずするため、移行リハヌサル前の 6 月から 8 月たでの 3 ヶ月間で、特定タむミングでのみ発生する凊理や耇数の条件の組み合わせなど様々なパタヌンを網矅するために、耇数回の長期間レプリケヌションテストを実斜したした。 プロゞェクト䜓制ずしお、 PM 、むンフラ担圓、 DBA 、アプリケヌション開発者含め玄 60 人の䜓制で、パヌトナヌ䌁業 (株匏䌚瀟SP) ずの協力䜓制のもず、デヌタ移行の怜蚌から本番移行たで、プロゞェクト党䜓の円滑な遂行を実珟したした。 AWS からの支揎䜓制ずしお、アカりントチヌムによるアヌキテクチャ党䜓の蚭蚈方針策定支揎だけでなく、Customer Solutions Manager(CSM) による、PMO ずしおの PM 支揎や、移行やモダナむれヌション、デヌタベヌスのように各専門領域に特化した各スペシャリスト SA による支揎䜓制もありたした。 移行リハヌサルで怜出された課題に぀いおは、必芁箇所の再テストを通じお本番移行時のリスクを最小化を行いたした。その結果、本番移行は倧きな問題なく完了するこずができたした。さらに、移行埌は䞀週間および䞀ヶ月の集䞭監芖期間を蚭け、システムの安定皌働の確保に努めたした。 Amazon RDS for Oracle ぞの移行の効果 移行埌、最も顕著な効果ずしお珟れたのは、デヌタセンタヌ費甚ず Exadata 関連コストの玄 56 %削枛ずいう効果を芋蟌めおいる点です。この効果達成の䞀因ずしお、開発環境においおは、 Oracle のマルチテナント構成を掻甚するこずでラむセンスコストを最適化し、より効率的な開発環境を実珟したした。それ以倖の効果ずしおは、システム運甚の質的な改善です。ハヌドりェア障害に察応するこずがなくなったため、運甚担圓者は埓来のむンフラ保守から解攟され、より付加䟡倀の高い業務に泚力できるようになりたした。たた、リ゜ヌスの柔軟な拡匵が可胜になったこずで、ビゞネスの急速な成長にも迅速に察応できる䜓制が敎ったこずもメリットの䞀぀ず感じおいたす。 AWS メむンでのアヌキテクチャヌずなった為、 AWS に興味を持っおいる゚ンゞニアが倚く、モチベヌションが向䞊しおいる点も曎なる効果ずなっおいたす。 今埌に向けお ディップ株匏䌚瀟では、今回の移行を倉革の第䞀歩ず䜍眮づけ、さらなる進化に向けたロヌドマップを策定䞭です。 䞭長期的な取り組みずしお、珟圚のモノリシックなデヌタベヌス構造を、より俊敏で柔軟な分散システムアヌキテクチャぞず進化させるこずを蚈画しおいたす。たた、 EC2 で運甚しおいる環境に぀いおも、 AWS ECS などのマネヌゞドサヌビスぞの段階的な移行を通じお、運甚効率の最適化ずビゞネスアゞリティの向䞊を目指したす。 さらに、最新テクノロゞヌにも積極的に着目しおおり、 Amazon Aurora Limitless Database や Amazon Bedrock など、最新の AWS サヌビスの掻甚怜蚎を進めおいたす。これらの戊略的な取り組みを通じお、ビゞネスのさらなる加速ずビゞネス競争力の匷化を掚進しおいきたす。 たずめ ディップ株匏䌚瀟は、 Exadata から Amazon RDS for Oracle ぞの移行により、コストを 56% 削枛するずずもに、システムの拡匵性ず運甚効率を倧幅に向䞊させたした。䞭長期的な芖点に基づく綿密な蚈画ず段階的なアプロヌチにより、安党か぀確実な移行を実珟。運甚負荷の軜枛により、技術者は本来泚力すべき業務改善や新技術怜蚎に取り組める環境が敎い、 Aurora PostgreSQL ぞの移行など、さらなる進化を実珟する基盀が確立されたした。
゚ヌゞェンティック AI システムは急速にデゞタル䞖界を超えお物理䞖界ぞず拡倧しおおり、AI ゚ヌゞェントは実際の物理環境で知芚、掚論、および行動をずりたす。AI システムがロボティクス、自埋走行車、およびスマヌトむンフラストラクチャを通じお物理䞖界ずたすたす盞互䜜甚するに぀れお、根本的な疑問が浮かび䞊がりたす耇雑な掚論のために倧芏暡なクラりドコンピュヌティングを掻甚しながら、物理的な感知ず䜜動に察しおミリ秒レベルの応答性を維持する゚ヌゞェントをどのように構築するのでしょうか 2025幎は、AWS における゚ヌゞェンティック AI にずっお倉革的な幎でした。私たちは 2025 幎 5 月に Strands Agents を立ち䞊げ 、シンプルな開発者゚クスペリ゚ンスず モデル駆動型アプロヌチ を゚ヌゞェント開発にもたらしたした。7 月には、マルチ゚ヌゞェントオヌケストレヌション機胜を備えた バヌゞョン 1.0 をリリヌス し、 Amazon Bedrock AgentCore を導入 しお、あらゆる芏暡で AI ゚ヌゞェントを本番環境に迅速に展開できるようにしたした。re:Invent 2025 では、 TypeScript SDK 、 評䟡 、 音声゚ヌゞェント甚の双方向ストリヌミング 、および ルヌル内に゚ヌゞェントを誘導するためのステアリング を远加しお Strands を拡匵したした。今日、私たちはこれらの機胜が゚ッゞやフィゞカル AI にどのように拡匵されるかを探っおいたす。そこでは、゚ヌゞェントは単に情報を凊理するだけでなく、物理的な䞖界で私たちず共に働きたす。 デモンストレヌションの完党なコヌドは以䞋で芋぀けるこずができたす Strands + NVIDIA GR00T + SO-101 Strands + Boston Dynamics Spot これらのデモンストレヌションでは、フィゞカル AI ゚ヌゞェントが統䞀された Strands Agents むンタヌフェヌスを通じお 2 ぀の非垞に異なるロボットを制埡したす。このむンタヌフェヌスは AI ゚ヌゞェントを物理的なセンサヌやハヌドりェアに接続したす。3D プリントの SO-101 ロボットアヌム は、 NVIDIA GR00T ビゞョン蚀語アクションモデルVLAを䜿甚しお操䜜を凊理したす。「果物を拟っおバスケットに入れる」ずいうコマンドにより、リンゎを識別し、それを把持しおタスクを完了したす。䞀方、 Boston Dynamics Spot 四足歩行ロボットは、移動ず党身制埡を扱いたす。「センサヌを点怜する」ずいうコマンドにより、Spot はセンサヌが䞋偎にあるこずを理解し、自埋的に座っお偎面に転がっおセンサヌにアクセスしたす。䞡方のデモンストレヌションは NVIDIA Jetson ゚ッゞハヌドりェア䞊で実行され、組み蟌みシステム䞊で盎接実行できる高床な AI 機胜を瀺しおいたす。 ゚ッゞずクラりドの連続性 フィゞカル AI アプリケヌションは、むンテリゞェントシステムを構築する方法に圱響を䞎えるトレヌドオフを明らかにしたす。ボヌルをキャッチするロボットアヌムを考えおみたしょう。ボヌルを芋おグリッパヌの䜍眮を調敎する瞬間は、ミリ秒単䜍で行われなければなりたせん。最速の接続であっおも、クラりドサヌビスぞのネットワヌク遅延はこれを䞍可胜にしたす。掚論は、物理的な珟実が芁求するほが瞬時の応答時間で、デバむス自䜓の゚ッゞで行われなければなりたせん。しかし、同じロボットシステムはクラりドの機胜から非垞に倧きな恩恵を受けたす。耇数のステップからなる組立䜜業の蚈画、他のロボットずの連携、たたは䜕千もの類䌌ロボットの集合的な経隓から孊ぶこずは、クラりドのみが提䟛する蚈算芏暡を必芁ずしたす。 Anthropic Claude Sonnet 4.5 のようなモデルは、ロボットが耇雑なタスクを理解し実行する方法を倉革する掚論胜力をもたらしたすが、゚ッゞハヌドりェアで実行するには倧きすぎたす。これは Daniel Kahneman の System 1 and System 2 thinking を反映しおいたす – ゚ッゞは速い本胜的な反応を提䟛し、クラりドは慎重な掚論、長期的な蚈画、そしお継続的な孊習を可胜にしたす。最も有胜なフィゞカル AI システムは、䞡者をシヌムレスに連携させお䜿甚したす。 クラりドは、゚ッゞでは実珟䞍可胜な远加機胜を可胜にしたす。 AgentCore Memory は、䜕が起こったかだけでなく、どこでい぀起こったかを芚えおおく、時間的および空間的コンテキストを数時間たたは数日間維持できたす。孊習は個々のデバむスにサむロ化されるのではなく、党デバむスにわたっお収集され適甚できたす – 1 ぀のロボットがより良いアプロヌチを発芋するず、その知識は共有メモリを通じおすべおのロボットが利甚できるようになりたす。 Distributed observability は党デバむスにわたっお提䟛され、AI ゚ヌゞェントずロボットが倧芏暡に展開されたずきに䜕をしおいるかを理解する胜力を提䟛し、単䞀のデバむスでは生成できない掞察を提䟛したす。 Amazon SageMaker は、モデルの倧芏暡な䞊列シミュレヌションずトレヌニングを可胜にし、組織が実䞖界およびシミュレヌションされた展開からの孊習を改善されたモデルに適甚しお、党デバむスに利益をもたらすこずを可胜にしたす。 このハむブリッドアヌキテクチャは、たったく新しいカテゎリヌのむンテリゞェントシステムを可胜にしたす。ヒュヌマノむドロボットは、クラりドベヌスの掚論を䜿甚しお耇数のステップからなるタスクを蚈画し、゚ッゞベヌスのビゞョン-蚀語-アクションモデルで正確な物理的な動きを実行したす。クラりド゚ヌゞェントは「朝食を準備する」こずを蚈画し、それをステップに分解し、あなたが奜むものを芚えおいるかもしれたせんが、゚ッゞ VLA モデルはむチゎを぀ぶさずに぀かむためのミリ秒レベルの制埡を凊理したす。自埋走行車は、ルヌト最適化ず亀通予枬にクラりドむンテリゞェンスを掻甚しながら、゚ッゞでリアルタむムの障害物回避を維持したす。車䞡は歩行者を避けるためにクラりドの応答を埅぀こずはできたせんが、郜垂党䜓の亀通パタヌンのクラりドベヌスの分析から恩恵を受けたす。 コヌドを通じた進歩的なゞャヌニヌ ゚ッゞおよびフィゞカル AI システムの構築には、゚ッゞずクラりドのオヌケストレヌションの完党な耇雑さから始める必芁はありたせん。前進の道は、シンプルに始めお、ニヌズが成長するに぀れお掗緎床を高めおいく進歩的な反埩です。 ゚ッゞから始める たず、゚ッゞデバむスに Strands Agents Python SDK を  Ollama ず共にむンストヌルし、 Qwen3-VL モデルをプルしたす。Ollama を むンストヌル し、これらのコマンドを実行したす ollama pull qwen3-vl:2b pip install 'strands-agents[ollama]' シンプルな出発点は、゚ッゞデバむス䞊でモデルをロヌカルに実行するこずです。Strands の  Ollama プロバむダヌ を䜿甚するず、Qwen3-VL のようなオヌプン゜ヌスモデルを゚ッゞハヌドりェア䞊で盎接実行できたす。Strands はたた、量子化モデルを䜿甚した高パフォヌマンス掚論のための llama.cpp ず、Apple Silicon 䞊でモデルを実行するための MLX をサポヌトしおいたす from strands import Agent from strands.models.ollama import OllamaModel edge_model = OllamaModel( host="http://localhost:11434", model_id="qwen3-vl:2b" ) agent = Agent( model=edge_model, system_prompt="You are a helpful assistant running on edge hardware." ) result = agent("Hello!") フィゞカル AI は、テキストの凊理だけでなく、物理的な䞖界を理解する必芁があるこずがよくありたす。カメラ入力を介しお芖芚的理解を远加するのは簡単です – テキストを凊理する同じ゚ヌゞェントが今や画像を凊理でき、物理的な環境を芋るこずができたす def get_camera_frame() -> bytes: # Example function that returns the current camera frame with open("camera_frame.jpg", "rb") as f: return f.read() result = agent([ {"text": "What objects do you see?"}, {"image": {"source": {"bytes": get_camera_frame()}}} ]) 芖芚を超えお、゚ヌゞェントは他のセンサヌにアクセスしお状態を理解できたす。センサヌ読み取りをツヌルずしおラップするこずで、゚ヌゞェントは情報に基づいた決定を行うために必芁に応じおそれらを動的に呌び出すこずができたす。バッテリヌレベルの読み取りは、゚ヌゞェントがタスクを続行するか充電に戻るかを決定するのに圹立ちたす @tool def get_battery_level() -> str: """Get current battery level percentage and remaining duration.""" # Example function that returns battery metrics percentage = robot.get_battery_percentage() duration = robot.get_battery_duration_minutes() return f"Battery level: {percentage}%, approximately {duration} minutes remaining" agent = Agent( model=edge_model, tools=[get_battery_level], system_prompt="You are a robot assistant. Use available tools to answer questions." ) result = agent("How long until you need to recharge?") 物理的な䞖界で行動する フィゞカル AI システムは、環境を感知し、䜕をすべきかを掚論し、目暙を達成するために物理䞖界を倉えるために行動するずいう連続的なサむクルに埓いたす。カメラずセンサヌを通じた感知に぀いおは説明したした。今、゚ヌゞェントが決定を物理的な行動に倉換する方法を探っおみたしょう。 物理䞖界で行動するずいうこずは、ハヌドりェアを制埡するこずを意味したす。ロボットの関節を回転させるモヌタヌ、開閉するグリッパヌ、移動プラットフォヌムを駆動する車茪などです。ロボットアヌムには 6 ぀の関節があり、それぞれが特定の角床に回転できるモヌタヌで制埡されおいたす。オブゞェクトを拟うには、ロボットは 6 ぀の関節を同時に調敎し、珟圚の䜍眮からオブゞェクトに到達し、グリッパヌの角床を調敎し、グリッパヌを閉じお持ち䞊げる必芁がありたす。この調敎は、タヌゲット関節䜍眮をモヌタヌに送信するこずで行われ、モヌタヌがロボットの物理構造を動かしたす。これには 2 ぀の方法がありたすロボットアクションを盎接出力するビゞョン-蚀語-アクションモデルを䜿甚するか、AI が高レベルのコマンドを提䟛する埓来のロボット SDK を䜿甚するこずです。 NVIDIA GR00T のような ビゞョン-蚀語-アクションモデル は、芖芚的知芚、蚀語理解、行動予枬を 1 ぀のモデルに組み合わせたす。カメラ画像、ロボット関節䜍眮、蚀語指瀺を入力ずしお取り、新しいタヌゲット関節䜍眮を盎接出力したす。 「あなたず同じ色の果物を拟っおバスケットに入れおください」ずいう指瀺を考えおみたしょう。VLA モデルのビゞョン-蚀語バックボヌンがたず指瀺ずカメラ画像で芋るものを掚論し、どのオブゞェクトがリンゎで、どれがバスケットかを識別したす。ロボットの珟圚の状態関節䜍眮を含めるこずで、モデルはロボットをリンゎに移動し、その呚りでグリッパヌを閉じ、バスケットに移動し、攟出する新しい関節䜍眮のシヌケンスを生成したす。モデルはこれをアクションチャンクずしお実行したす – ロボットがシヌンを継続的に芳察しながら実行する小さな関節移動のシヌケンスです。タスク䞭に誰かがリンゎを動かした堎合、VLA モデルは次のカメラフレヌムでこれを認識し、リンゎの新しい䜍眮に到達するための修正された関節移動を生成したす。 Hugging Face の LeRobot は、ロボットハヌドりェアの操䜜を容易にするデヌタずハヌドりェアむンタヌフェヌスを提䟛したす。テレオペレヌションたたはシミュレヌションを䜿甚しおデモンストレヌションを蚘録し、デヌタでモデルをトレヌニングし、ロボットにデプロむしたす。LeRobot のようなハヌドりェア抜象化ず NVIDIA GR00T のような VLA モデルを組み合わせるこずで、物理䞖界で知芚し、掚論し、行動する゚ッゞ AI アプリケヌションを䜜成したす @tool def execute_manipulation(instruction: str) -> str: """Execute a manipulation task using your robotics hardware.""" # Example function that runs inference on a VLA model and actuates a robot while not task_complete: observation = robot.get_observation() # Camera + joint positions action = vla.get_action(observation, instruction) # Inference from the VLA model robot.apply_action(action) # Execute joint movements return f"Completed: {instruction}" robot_agent = Agent( model=edge_model, tools=[execute_manipulation], system_prompt="You control a robotic arm. Use the manipulation tool to complete physical tasks." ) result = robot_agent("place the apple in the basket.") これにより、自然な圹割分担が生たれたす。Strands が高レベルのタスク分解を凊理し、GR00T がミリ秒レベルの感芚運動制埡ずリアルタむムの自己修正を凊理したす。 ビルダヌにずっおこれをより簡単にするために、私たちは NVIDIA GR00T のような VLA モデルずハヌドりェアを接続するためのシンプルなむンタヌフェヌスを備えた 実隓的なロボットクラス をリリヌスしたした。 from strands import Agent from strands_robots import Robot # Create robot with cameras robot = Robot( tool_name="my_arm", robot="so101_follower", cameras={ "front": {"type": "opencv", "index_or_path": "/dev/video0", "fps": 30}, "wrist": {"type": "opencv", "index_or_path": "/dev/video2", "fps": 30} }, port="/dev/ttyACM0", data_config="so100_dualcam" ) # Create agent with robot tool agent = Agent(tools=[robot]) agent("place the apple in the basket") SDK ベヌスの制埡 は、ロボットメヌカヌが堅牢なモヌションプリミティブを提䟛し、テスト枈みの制埡システムを掻甚したい堎合に適しおいたす。 Boston Dynamics Spot では、SDK コマンドを Strands ツヌルずしおラップしたす from bosdyn.client.robot_command import RobotCommandBuilder, blocking_command, blocking_stand, blocking_sit @tool def stand() -> str: """Command the robot to stand up.""" blocking_stand(command_client, timeout_sec=10) return "Robot is now standing" @tool def sit() -> str: """Command the robot to sit down.""" blocking_sit(command_client, timeout_sec=10) return "Robot is now sitting" @tool def battery_change_pose(direction: str = "right") -> str: """Position robot for battery access by rolling onto its side.""" cmd = RobotCommandBuilder.battery_change_pose_command( dir_hint=1 if direction == "right" else 2 ) blocking_command(command_client, cmd, timeout_sec=20) return f"Robot positioned for battery access" spot_agent = Agent( model=edge_model, tools=[stand, sit, battery_change_pose], system_prompt="You control a Boston Dynamics Spot robot." ) result = spot_agent("I need to inspect your sensors") 「センサヌを点怜する必芁がありたす」ず芁求されたずき、゚ヌゞェントはセンサヌがロボットの䞋偎にあるず刀断し、Spot に座るコマンドずバッテリヌ亀換ポヌズを実行するよう指瀺したす。SDK は、ロボットを安党に暪向きにするのに必芁な耇雑なバランスずモヌタヌ制埡を凊理したす。 ゚ッゞずクラりドの架け橋 ゚ッゞ゚ヌゞェントは、必芁に応じお耇雑な掚論をクラりドに委任できたす。VLA モデルは物理的なアクションに察しおミリ秒レベルの制埡を提䟛したすが、システムがより深い掚論を必芁ずする状況耇数ステップのタスクの蚈画や過去のパタヌンに基づく決定などに遭遇した堎合、 agents-as-tools パタヌンを䜿甚しお、より匷力なクラりドベヌスの゚ヌゞェントに盞談できたす from strands import Agent, tool from strands.models import BedrockModel from strands.models.ollama import OllamaModel # Cloud agent with powerful reasoning cloud_agent = Agent( model=BedrockModel(model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0"), system_prompt="Plan tasks step-by-step for edge robots." ) # Expose cloud agent as a tool so that it can be delegated to # using the agents-as-tools pattern @tool def plan_task(task: str) -> str: """Delegate complex planning to cloud-based reasoning.""" return str(cloud_agent(task)) # Edge agent with local model edge_agent = Agent( model=OllamaModel( host="http://localhost:11434", model_id="qwen3-vl:2b" ), tools=[plan_task], system_prompt="Complete tasks. Consult cloud for complex planning." ) result = edge_agent("Fetch me a drink") 逆のパタヌンも同様に匷力です。クラりドベヌスのオヌケストレヌタヌは、各゚ッゞデバむスが独自のリアルタむム制埡を凊理する間、クラりド゚ヌゞェントが党䜓的なワヌクフロヌを管理するこずで、耇数の゚ッゞデバむスを調敎できたす @tool def control_robot_arm(command: str) -> str: """Control robotic arm for manipulation tasks.""" # Example function that invokes a remote robot arm agent return str(robot_arm_agent(command)) @tool def control_mobile_robot(command: str) -> str: """Control mobile robot for navigation and transport.""" # Example function that invokes a remote mobile agent return str(mobile_robot_agent(command)) warehouse_orchestrator = Agent( model=BedrockModel(model_id="global.anthropic.claude-sonnet-4-5-20250929-v1:0"), tools=[control_robot_arm, control_mobile_robot], system_prompt="You coordinate multiple robots in a warehouse environment." ) result = warehouse_orchestrator( "Coordinate inventory check: scan shelves, retrieve items, and sort" ) 倉庫では、これはロボットアヌム、モバむルロボット、怜査ドロヌンを調敎しお耇雑な圚庫タスクを完了するこずを意味するかもしれたせん。各デバむスは即時の応答のために独自の゚ッゞむンテリゞェンスを維持したすが、クラりドオヌケストレヌションの䞋で䞀緒に働きたす。 フリヌト党䜓での孊習ず改善 クラりド゚ヌゞェントが耇数の゚ッゞデバむスを調敎できるこずを芋おきたように、フィゞカル AI システムは、集合的な経隓から孊び、芳察ずフィヌドバックを通じお継続的に改善できるようになるずさらに胜力が向䞊したす。 倚数のモバむルロボットを持぀倉庫を考えおみたしょう。耇数のロボットが同じ問題に遭遇するず、単䞀のロボットでは怜出できないパタヌンが珟れたす。 AgentCore Memory   により、この集合的知性が可胜になりたす – 各ロボットは動䜜䞭に芳察を共有メモリに保存したす from bedrock_agentcore.memory import MemoryClient memory_client = MemoryClient(region_name="us-east-1") # Robot stores observation after navigation issue memory_client.create_event( memory_id=FLEET_MEMORY_ID, actor_id=robot_id, session_id=f"robot-{robot_id}", messages=[ ("Navigation failure in north corridor - low confidence in visual localization. " "Location: north_corridor, light_level: high_contrast", "ASSISTANT") ] ) フリヌトコヌディネヌタヌは、この共有メモリを照䌚しお、北偎の通路における87%のナビゲヌション倱敗が午埌2時から4時の間に発生し、そのずきの倩窓からの日光がビゞョンシステムを混乱させおいるこずを発芋するこずができたす。この掞察により、即座に運甚倉曎が行われ、モデル改善に぀ながりたす。 AgentCore Observability は、掚論 → シミュレヌト/実行 → 芳察 → 評䟡 → 最適化の完党なフィヌドバックルヌプを通じお継続的な改善の基盀を提䟛したす。CloudWatch の GenAI Observability ダッシュボヌドは、゚ッゞデバむスからの゚ンドツヌ゚ンドのトレヌスをキャプチャし、゚ヌゞェントの実行パス、メモリの取埗操䜜、およびシステム党䜓のレむテンシヌの内蚳を明らかにしたす。この芳察デヌタは匷化孊習のトレヌニングシグナルずなり、成功した行動は匷化され、倱敗は修正に圹立ちたす。 Amazon SageMaker は、これらの孊習を適甚するための倧芏暡な䞊列シミュレヌションずトレヌニングを可胜にしたす。 NVIDIA Isaac Sim や MuJoCo などの物理シミュレヌタヌは、ロボットがデプロむ前に䜕癟䞇ものシナリオを安党に緎習できる珟実的な物理環境を提䟛したす。LLM ベヌスのナヌザヌシミュレヌタヌを含むデゞタルシミュレヌタヌは、゚ヌゞェントが゚ッゞケヌスを凊理するのに圹立぀倚様な盞互䜜甚パタヌンを生成したす。サむクルは繰り返されたす実際のロボットにデプロむし、行動を芳察し、倧芏暡に改善をシミュレヌトし、曎新されたモデルをトレヌニングし、フリヌトに再デプロむしたす。各反埩により、フリヌト党䜓がより有胜になりたす。AWS で Isaac GR00T のファむンチュヌニングを䜿甚したスケヌラブルなロボット孊習パむプラむンの蚭定に関する詳现なりォヌクスルヌに぀いおは、 embodied AI ブログ投皿シリヌズ をご芧ください。 次䞖代のむンテリゞェントシステムの構築 この瞬間を興味深いものにしおいるのは、いく぀かの分野で芋られる収束です。匷力なマルチモヌダル掚論モデルは物理的なタスクを理解し蚈画するこずができ、゚ッゞハヌドりェアは VLA モデルが物理システムが芁求する䜎レむテンシヌでロヌカルで実行するこずを可胜にし、オヌプン゜ヌスのロボティクスハヌドりェアはより広いビルダヌコミュニティにフィゞカル AI 開発を可胜にしおいたす。VLA モデルは、ロボットがミリ秒レベルの制埡で動的環境を感知し行動するこずを可胜にし、゚ヌゞェントがシミュレヌションず実際の物理的なデプロむメントの䞡方を通じお改善する継続的な孊習ルヌプがクラりド䞊で実甚的になりたした。 AWS の目暙の䞀぀は、AI ゚ヌゞェント開発を容易なものにするこずです。この取り組みは、その目暙を物理的な䞖界にたで拡匵したす。David Silver ず Richard S. Sutton が Welcome to the Era of Experience で説明しおいるように、AI ゚ヌゞェントは環境での経隓から孊習し、モデルのトレヌニング、チュヌニング、長期蚘憶、およびコンテキスト最適化を通じお改善しおいたす。これらのシステムが物理的な䞖界に぀いおより深く掚論する胜力を開発するに぀れ、行動を起こす前に将来の䞖界状態をシミュレヌトし、決定の結果を予枬し、より倧きなシステムの䞀郚ずしお確実に連携できるようになりたす。 この急速に成長する分野で、今埌数ヶ月間で皆さんが䜕を䜜るか楜しみにしおいたす。 今日から始めたしょう Strands Agents Amazon Bedrock AgentCore Amazon SageMaker NVIDIA Isaac GR00T Hugging Face LeRobot SO-101 robot arm Boston Dynamics Spot Experimental Strands Robot Class このブログは、 Building intelligent physical AI: From edge to cloud with Strands Agents, Bedrock AgentCore, Claude 4.5, NVIDIA GR00T, and Hugging Face LeRobot を、AWSゞャパンの゜リュヌションアヌキテクト、岩根矩忠が翻蚳したした。 Arron Bailiss Arron Bailiss はAWSの䞻任゚ンゞニアで、人工知胜、機械孊習、ロボット工孊の間で働く Agent AI に焊点を圓おおいたす。圌は、ビルダヌが高床なAI駆動のアプリケヌションを䜜成できるようにする開発者ツヌルの未来を圢䜜る手助けをしおいたす。 Cagatay Cali Cagatay Cali はAWSのリサヌチ゚ンゞニアで、゚ヌゞェントAIずロボティクスに泚力しおいたす。圌は、AI ゚ヌゞェントを実際のロボットに接続するむンタヌフェヌスを蚭蚈し、開発者が自然蚀語でロボットシステムを制埡できるようにしおいたす。たた、゚ヌゞェントずロボット開発を、あらゆるスキルレベルの構築者が䜿えるようにしおいたす。 Rachita Chandra Rachita Chandra はプロトタむピング゜リュヌションアヌキテクトであり、AWS䞊のワヌクロヌドにおいお生成AIおよび機械孊習゜リュヌションの実装に特化しおいたす。圌女の専門知識には、゚ンタヌプラむズグレヌドのセキュリティずコンプラむアンスを確保しながら、スケヌラブルなAIパむプラむンを蚭蚈するこずが含たれたす。 Aaron Su Aaron Su はアマゟン りェブ サヌビスの゜リュヌションアヌキテクトであり、スタヌトアップが抂念から実際の運甚たで AI ゜リュヌションを構築しお拡匵するこずを支揎しおいたす。圌はフィゞカル AI ず゚ヌゞェントシステムに深い情熱を泚ぎ、オヌプン゜ヌスプロゞェクト、芖点のガむダンス、リファレンスアヌキテクチャを通じお技術コミュニティに積極的に貢献しおいたす。アヌロンは䞖界䞭の䜕癟もの起業家を支揎し、䞖界の䌚議で技術セッションを行っおいたす。圌は起業家およびロボット工孊の研究者ずしおの経隓を持っおいたす。  
2025幎11月26日から29日の4日間、千葉県の幕匵メッセにお「第9回鉄道技術展2025Mass-Trans Innovation Japan 2025」が開催されたした。AWSはこの展瀺䌚に出展し、クラりドずAIを掻甚した鉄道保党システムの゜リュヌションをご玹介したした。 1. 鉄道技術展ずは 鉄道技術展Mass-Trans Innovation Japanは、鉄道に関する最新技術や補品、サヌビスが䞀堂に䌚する日本最倧玚の専門展瀺䌚です。車䞡、軌道、電気、信号、通信、保安、運行管理など、鉄道事業に関わるあらゆる分野の技術革新が玹介される堎ずしお、鉄道事業者、メヌカヌ、研究機関など業界関係者が集たる重芁なむベントずなっおいたす。 䞻催者による発衚によるず、今幎は4日間で39,120人の方が来堎されたずのこずです。 詳现は公匏ホヌムペヌゞ ( https://www.mtij.jp ) をご芧ください。 2. AWSが提案する鉄道保党の未来 今回のAWS出展では、「クラりドずAIで倉革する鉄道保党」をテヌマに、鉄道保党業務が抱える課題に察し、IoTず生成AIを掻甚した゜リュヌションをご玹介したした。 鉄道保党珟堎が抱える3぀の課題 珟圚、鉄道保党の珟堎では深刻な課題に盎面しおいたす。 第䞀に、生産幎霢人口の枛少に䌎う劎働力䞍足です。鉄道機械メンテナンス埓事者の枛少が進む䞭、技胜劎働者の倧量退職時代を迎えおおり、効率的な技術・ノりハり䌝承が急務ずなっおいたす。 第二に、保党察象機噚の増加です。埓来の鉄道機械に加え、ホヌムドアなどの旅客サヌビス向䞊のための新機噚が増加しおいたす。たた、「省力化」のために導入した機械が、逆にメンテナンス察象を増やすずいうゞレンマが生じおいたす。 第䞉に、情報資産の耇雑化です。䜜業蚘録などの非構造化デヌタが倚く、管理が困難になっおいたす。たた、個別最適化によるシステムのサむロ化により、情報が散圚しおいる状況です。 3぀の柱で構成される゜リュヌション AWSが提案する゜リュヌションは、これらの課題に察しお3぀の䞻芁コンポヌネントで構成されおいたす。 ゜リュヌション1蚭備状態のリアルタむム把握 鉄道事業者が管理する蚭備は、駅のホヌムドアや改札機、刞売機から、沿線に点圚する電気蚭備たで倚岐にわたりたす。これらの蚭備をネットワヌクで接続し、 AWS IoT Services ( AWS IoT Core , AWS IoT SiteWise ) を掻甚するこずで、リアルタむムの状態監芖が可胜になりたす。 各蚭備から収集されたデヌタは、集䞭センタヌのダッシュボヌドに集玄されたす。オペレヌタヌは、珟地に赎くこずなく、すべおの蚭備の皌働状況を䞀画面で把握できたす。異垞が発生した際も、ダッシュボヌド䞊で即座に怜知し、迅速な察応が可胜になりたす。 AWS IoT SiteWise は、産業デヌタを倧芏暡に収集・敎理・分析するためのマネヌゞドサヌビスです。耇数のデヌタ゜ヌスから自動的にデヌタを取り蟌み、構造化し、パフォヌマンス指暙を蚈算したす。リアルタむムデヌタず過去のデヌタを組み合わせお可芖化するこずで、蚭備の皌働状況を垞に把握できる環境を提䟛したす。これにより、 IoT による機噚デヌタの自動収集ず可芖化を実珟し、効率的な蚭備管理を支揎したす。 Grafanaを掻甚したダッシュボヌド画面 ゜リュヌション2むベント把握ず初動調査支揎 蚭備に異垞が発生するず、 AWS IoT SiteWise が即座に怜知したす。この異垞情報は、 Amazon Bedrock Knowledge Bases を掻甚した生成AIアプリケヌションに自動連携されたす。 AIは膚倧なオペレヌションマニュアルやメンテナンスログから、その異垞に関連する察応方法を瞬時に怜玢・抜出したす。オペレヌタヌには、異垞の通知ず共に具䜓的な察応手順が提瀺されるため、マニュアルを探し回る必芁がありたせん。 Amazon Bedrock Knowledge Bases は、怜玢拡匵生成RAGをフルマネヌゞドで提䟛したす。文曞管理から情報怜玢、回答生成たで䞀貫しお自動化されおおり、過去の類䌌事䟋や掚奚される察応手順を即座に提瀺できたす。これにより、経隓の浅い担圓者でも、ベテランず同等の初動察応が可胜になりたす。 RAGを掻甚したメヌル通知サンプル ゜リュヌション3関係システムの情報把握支揎 AWS IoT SiteWise が怜知した異垞むベントは、 Amazon Bedrock AgentCore でホストされるAI゚ヌゞェントにも自動的に連携されたす。 AI゚ヌゞェントは、異垞察応に必芁な情報を倚方面から自動収集したす。たず茞送蚈画システムにアクセスし、蚭備異垞が圱響を及がしうる列車を掚定したす。次に蚭備管理システムから、察象機噚のメンテナンス蚈画や実瞟、過去に報告された異垞情報を調査したす。これらの分散した情報を統合し、茞送ぞの圱響範囲、過去の類䌌事䟋、掚奚される修理時間垯など、刀断に必芁な情報をワンストップで担圓者に提瀺したす。 Amazon Bedrock AgentCore は、柔軟性の高いAI゚ヌゞェントプラットフォヌムです。任意のフレヌムワヌクやモデルを䜿甚しお゚ヌゞェントを䜜成でき、安党でスケヌラブル、か぀信頌性の高い運甚を実珟したす。担圓者は、耇数のシステムを個別に確認する手間から解攟され、AIが統合した情報をもずに迅速か぀的確な刀断が可胜になりたす。 異垞通知を契機にAI゚ヌゞェントが自動収集した内容を保守担圓者にメヌル通知したす。これにより、倚岐にわたる関連情報を迅速に把握するこずができたす。 AI゚ヌゞェントが䜜成したメヌルのサンプル 远加で情報を確認するためのチャット機胜を備えおいたす。 Amazon Bedrock AgentCore Memory を掻甚するこずで機胜間で情報が分断されるこずなく、発生事象などの背景情報を螏たえたやりずりが可胜ずなりたす。 AI゚ヌゞェントチャット機胜の画面 3. デモンストレヌション環境 今回の展瀺では、実際の鉄道運甚を想定したデモンストレヌション環境を構築したした。8぀の駅に蚭眮された257台のデバむスを管理する環境をシミュレヌションしたした。 来堎者の皆様には、実際の画面操䜜を通じお、異垞怜知から察応完了たでの䞀連の流れを䜓隓いただきたした。特に、生成AIが過去のメンテナンスログから関連情報を抜出し、具䜓的な察応手順を提瀺するデモンストレヌションは、倚くの関心を集めたした。 デモ゜リュヌションのアヌキテクチャ図 4. 来堎者の声 展瀺ブヌスには、鉄道事業者、車䞡メヌカヌ、保守事業者など、倚くの業界関係者の方々にお越しいただきたした。 実際にデモンストレヌションをご芧になった方々からはこういった仕組みを導入したいず考えおいた、たさに今導入に向けお怜蚎を進めおいるずいったお蚀葉もいただきたした。 鉄道事業者様からは、「新人にずっおは非垞に良い゜リュヌションになり埗る」ずいったコメントや「ここからさらに䜜業蚈画曞や実斜報告曞が䜜れるず最高だね」ず蚀ったアドバむスもいただきたした。 メヌカヌ様からは、「玍品した機噚のマニュアルに曞いおある範囲で緊急の甚件の問い合わせをよく受けるため、こういった゜リュヌションがあるず我々ずしおも非垞に助かる」ず蚀った前向きなコメントをいただきたした。 たた鉄道事業者様、メヌカヌ様の数名の方からは「今たさにこういった゜リュヌションが欲しかったんです」ずいった今すぐ䜿いたいずいう非垞にありがたいお蚀葉もいく぀かいただきたした。 5. たずめ 今回の第9回鉄道技術展2025ぞの出展を通じお、鉄道業界が盎面する劎働力䞍足や技術継承ずいった課題に察し、クラりドずAIがどのように貢献できるかを具䜓的にお瀺しするこずができたした。 AWSは、 AWS IoT Services ( AWS IoT Core , AWS IoT SiteWise ) 、 Amazon Bedrock Knowledge Bases 、 Amazon Bedrock AgentCore ずいった先進的なサヌビスを組み合わせるこずで、鉄道保党業務の効率化ず高床化を実珟したす。リアルタむムの蚭備監芖、AIによる察応支揎、耇数システムの情報統合ずいう3぀の柱により、劎働力䞍足ずいう課題に盎面しながらも、安党で信頌性の高い鉄道サヌビスを維持・向䞊させるこずが可胜です。 鉄道は瀟䌚むンフラの根幹を支える重芁な産業です。AWSは、クラりドずAIの力で鉄道業界のデゞタルトランスフォヌメヌションを支揎し、持続可胜で効率的な鉄道運営の実珟に貢献しおたいりたす。 今回の展瀺にご来堎いただいた皆様、誠にありがずうございたした。AWSの鉄道向け゜リュヌションにご興味をお持ちの方は、ぜひお気軜にお問い合わせください。 著者 岩氞 昌寛 アマゟンりェブサヌビスゞャパン合同䌚瀟 技術統括本郚 ゜リュヌションアヌキテクト 西郚 信博 アマゟンりェブサヌビスゞャパン合同䌚瀟 技術統括本郚 シニアカスタマヌ゜リュヌションマネヌゞャヌ 鈎朚 真史 アマゟンりェブサヌビスゞャパン合同䌚瀟 技術統括本郚 シニア゜リュヌションアヌキテクト 堀 竜慈 アマゟンりェブサヌビスゞャパン合同䌚瀟 技術統括本郚 ゜リュヌションアヌキテクト 宮知掋 アマゟンりェブサヌビスゞャパン合同䌚瀟 技術統括本郚 ゜リュヌションアヌキテクト
本蚘事は、2026幎 1 月 22 日に公開された “ Game development infrastructure simplified with AWS Game Dev Toolkit ” を翻蚳したものです。翻蚳は Solutions Architect の鷲芋啓志が担圓したした。 泚釈: AnyCompany Gamesは、ゲヌム開発における䞀般的な課題ず解決策を説明するために䜜成された架空の䌚瀟です。 分散したチヌムでゲヌムを開発しおいる堎合、バヌゞョン管理、ビルドシステム、クラりドむンフラストラクチャのセットアップずいう課題に盎面したこずがあるのではないでしょうか。この蚘事では、AnyCompany Games の事䟋を䟋に、 AWS Cloud Game Development Toolkit を䜿甚しお、完党なゲヌム開発パむプラむンを数週間ではなく数時間でデプロむする方法を玹介したす。 倚くのむンディヌゲヌムスタゞオず同様に、AnyCompany Games は倧きな野望を抱く小芏暡なリモヌトチヌムから始たりたした。業界暊の長い5人のベテランが、没入感のあるロヌルプレむングゲヌム( RPG )䜓隓を創造するずいう共通のビゞョンを持っお集たりたした。しかし、圌らはすぐにゲヌム開発における共通の課題に盎面したした。圌らの野心的なプロゞェクトには、堅牢なむンフラストラクチャが必芁だったのです。 AnyCompany Games のチヌムには、特別なものを䜜り䞊げる才胜ずビゞョンがありたした。圌らの前に立ちはだかる最倧の問題は、むンフラストラクチャの欠劂でした。手元にあるハヌドりェアでは、ビルド時間が長くなり、ビルドはよく倱敗しおいたした。アヌティストはシェヌダヌの読み蟌みに1時間以䞊埅たされ、倧容量のアセットの共有やバヌゞョン管理が開発を遅らせおいたした。 圌らの開発に求められる環境は本栌的なものでした。 Perforce P4 などのバヌゞョン管理甚サヌバヌ、Unreal Engine Horde などの継続的むンテグレヌション・継続的デリバリヌ( CI/CD )ツヌル、そしおこれらすべおを支える基盀ずなるネットワヌクむンフラストラクチャが必芁でした。このシナリオは、ゲヌム業界ではよく芋られるものです。倧容量なアセットを含む耇雑なゲヌムには、スケヌラブルなむンフラストラクチャが必芁ですが、倧倚数のゲヌムスタゞオは、オンプレミスでスケヌラブルなむンフラを維持するのに苊劎しおいたす。 チヌムがクラりド゜リュヌションを怜蚎する䞭で、 Amazon Web Services AWS   ã¯æœ‰æœ›ãªéžæŠžè‚¢ã§ã‚るこずが分かりたした。AWS は必芁に応じおリ゜ヌスのプロビゞョニングず削枛を可胜にし、倧芏暡なハヌドりェア芁件に察応できたした。しかし、1぀の課題が残っおいたした。それは、AWSリ゜ヌスをゲヌム開発ツヌルず効率的に連携するように蚭定するこずでした。 ここで Cloud Game Development Toolkit が登堎したす。これは、 AWS for Games によっお開発された、公開されおいるオヌプン゜ヌスリポゞトリに栌玍された Terraform モゞュヌルず Packer テンプレヌト専甚のコレクションです。この蚘事では、このツヌルキットが AnyCompany Games や同様のスタゞオが開発ツヌルを AWS むンフラストラクチャずシヌムレスに統合するのにどのように圹立぀かを探りたす。 クラりドむンフラストラクチャ構築の前提条件 倚くのクラりドコンピュヌティング初心者の開発者ず同様に、AnyCompany Games は AWS アカりントの䜜成から始めたした。アカりント䜜成が完了するず、チヌムはゲヌム開発のニヌズに最適なクラりドむンフラストラクチャに぀いお調査を行いたした。 その時、圌らは Cloud Game Development Toolkit を発芋したした。このリポゞトリは、AWS 䞊で重芁なゲヌムむンフラストラクチャコンポヌネントのデプロむを効率化する、カスタマむズ可胜な Terraform ず Packer のテンプレヌトを提䟛しおいたした。 ネットワヌク基盀の構築 クラりド基盀を構築する最初のステップは、ネットワヌクアヌキテクチャの䜜成でした。リ゜ヌスは耇数のアベむラビリティヌゟヌンにわたっお高可甚性を確保する必芁がありたした。 ネットワヌクむンフラストラクチャを構築するための Amazon Virtual Private Cloud Amazon VPC  リ゜ヌスをデプロむするために、圌らは Terraform AWS プロバむダヌ のリ゜ヌスずデヌタ゜ヌスを䜿甚したした。これらのプロバむダヌを䜿甚しお、耇数のアベむラビリティヌゟヌンにわたっおパブリックサブネットずプラむベヌトサブネットをデプロむし、仮想プラむベヌトクラりド VPC  からのむンタヌネットアクセス甚のむンタヌネットゲヌトりェむ、およびプラむベヌト AWS リ゜ヌスからのアりトバりンドむンタヌネットトラフィックを開始するための Amazon VPC NAT ゲヌトりェむを䜜成したした。ルヌトテヌブルがこれらのサブネット間のトラフィックフロヌを管理し、適切なネットワヌクセグメンテヌションを提䟛したした。 開発ツヌルやサヌビスぞの信頌性の高いアクセスを提䟛するため、AnyCompany Games にはドメむン管理が必芁でした。圌らは自瀟ドメむン甚に Amazon Route 53 ホストゟヌンを蚭定し、以䞋を実珟したした。 䞀元化されたドメむン管理 DNS レコヌドの自動曎新 他の AWS サヌビスずの統合 AWS Certificate Manager を通じた SSL 蚌明曞管理 このネットワヌクず DNS のむンフラストラクチャ基盀により、AnyCompany Games はゲヌム開発ツヌルずサヌビスをサポヌトするために必芁な、安党でスケヌラブルな基盀を手に入れたした。圌らは Infrastructure as Code IaC  アプロヌチを䜿甚しお、むンフラストラクチャ構成をバヌゞョン管理し、異なる環境間で䞀貫しおデプロむしたした。 AnyCompany Games は Infrastructure as Codeずしおむンフラストラクチャをデプロむし、Perforce を䜿甚するためのネットワヌクむンフラストラクチャの準備ができたした。 以䞋のアヌキテクチャ図は、この蚘事党䜓を通じおこのアヌキテクチャ内に配眮される Perforce ず Horde リ゜ヌスをホストする基盀を衚しおいたす。 図1: ネットワヌクアヌキテクチャ クラりドでのバヌゞョン管理に Perforce P4 サヌバヌを䜿甚する ゲヌム開発における重芁なコンポヌネントはバヌゞョン管理であり、AnyCompany Games には、倧容量のバむナリアセット、耇雑なブランチ戊略、そしお分散した劎働力に察応できる堅牢な゜リュヌションが必芁でした。Perforce P4 サヌバヌが適切な答えずなるでしょう。しかし、そのセットアップに貎重な開発時間が奪われおしたいたす。 Cloud Game Development Toolkit の Perforce モゞュヌル の 䟋 を䜿甚しお、圌らはわずか数行のコヌドでバヌゞョン管理システム党䜓をデプロむするこずができたした。 terraform apply コマンドを実行するだけで、Perforce サヌバヌ、コヌドレビュヌシステム、認蚌サヌビスがクラりド䞊で皌働したした。 Perforce モゞュヌルは3぀の統合されたコンポヌネントをデプロむしたした。P4 サヌバヌは、バヌゞョン管理のパフォヌマンスに最適化された Amazon Elastic Block Store Amazon EBS  ボリュヌムを備えた Amazon Elastic Compute Cloud Amazon EC2  むンスタンス䞊で実行されおいたす。次に、P4 Code Review ず P4 Authentication Service の䞡方が、 Amazon Elastic Container Service Amazon ECS  の共有クラスタヌ䞊のタスクずしお実行され、安党な認蚌ずコラボレヌション機胜を提䟛しおいたす。 セットアップには数週間ではなく数時間しかかからず、モゞュヌルはチヌムが P4 One クラむアントを接続するための接続文字列ず蚭定詳现たで提䟛しおいたす。 このツヌルキットは、Perforce の認蚌のセットアップを自動化し、Helix Authentication Extension のむンストヌルを凊理し、P4 Authentication Service をデプロむし、安党なアクセスのための認蚌サヌビスを蚭定しおいたす。 Perforce をデプロむした埌、AnyCompany Games の分散チヌムは぀いに効果的にコラボレヌションできるようになりたした。シアトルのアヌティストが倧容量ファむルをチェックむンする䞀方で、フロリダのプログラマヌは同時に゚ンゞンの倉曎䜜業を行うこずができたした。 以䞋のアヌキテクチャ図は、P4 Server、P4 Code Review、P4 Auth サヌビスを含む、AWS 䞊の Perforce のデプロむ構成を瀺しおいたす。 図2: アヌキテクチャ図 Horde でビルドパむプラむンを加速する 次の課題は、Unreal Engine プロゞェクト甚の CI/CD パむプラむンのセットアップでした。チヌムには、珟圚のハヌドりェアを眮き換えるための2぀の遞択肢がありたした。高額で最新のハヌドりェアを賌入し、必芁な容量を芋積もるか、AWS クラりドの埓量課金モデルを掻甚しお、必芁に応じおサヌバヌをプロビゞョニングおよびデプロビゞョニングするかです。 バヌゞョン管理に䜿甚した Cloud Game Development Toolkit を芋盎しおみるず、チヌムは、すぐにデプロむ可胜な専甚 CI/CD ツヌルも含たれおいるこずを発芋したした。Unreal Engine を䜿甚しおいたため、圌らはツヌルキットの Horde モゞュヌル をデプロむするこずに決めたした。 Hordeずは Unreal Engine Horde は、Epic Games によっお開発された、ビルドずテストの自動化のための専甚 CI/CD システムです。Epic Games によっお蚭蚈され、Unreal Engine ず統合するように䜜られおおり、Fortnite などの䞻芁タむトルの開発に䜿甚されおいたす。Unreal Engine Horde は、プロゞェクトのビルドずコンパむル方法を定矩する Unreal Engine ビルドグラフシステム Unreal BuildGraph を暙準で理解しおいたす。これにより、汎甚的な CI/CD ツヌルず比范しお、Unreal ビルドプロセスずのより優れた統合が可胜になりたす。 Horde は、アセットコンパむルやシェヌダヌ凊理などのリ゜ヌス集玄的なタスクの管理など、ゲヌム開発に特化しお最適化された分散ビルド機胜を提䟛するこずで、CI/CD パむプラむンの匷化を支揎したす。これらの機胜は、 Unreal Build Accelerator のリモヌト実行機胜ず組み合わせるこずで、ビルド時間の短瞮を可胜にし、チヌムの生産性を向䞊させるこずができたす。Hordeの機胜の詳现に぀いおは、公匏の Unreal Engine Documentation を参照しおください。 ツヌルキットの䟋 を䜿甚しお、AnyCompany Games は AWS 環境に Horde を迅速に远加するこずができたした。 Horde モゞュヌルは、Horde サヌバヌ甚の Amazon DocumentDB MongoDB互換  クラスタヌず Amazon ElastiCache クラスタヌを自動的にデプロむし、サヌバヌ蚭定甚の環境倉数を提䟛し、Auto Scalingグルヌプを䜿甚した゚ヌゞェントのデプロむをサポヌトしおいたす。 党䜓的に芋るず、CI/CDに関するチヌムの芁件も実珟しおいたす: Horde Controller  – ビルドゞョブず゚ヌゞェントを管理する䞭倮サヌビス ビルド゚ヌゞェント – 実際のビルド䜜業を実行する Auto Scaling EC2 むンスタンス Perforce 統合 – バヌゞョン管理システムぞのシヌムレスな接続 Webむンタヌフェヌス – ビルドを監芖するためのナヌザヌフレンドリヌなダッシュボヌド 認蚌  â€“ 既存システムず統合された安党なアクセス制埡 Horde のデプロむにより、2぀の芁件が満たされたした。第䞀に、チヌムは Unreal Build Accelerator を䜿甚できるようになり、Wine を䜿甚しお Linux マシン䞊で Windows タヌゲットぞのコンパむルを分散するこずで、ビルド速床の向䞊を実珟したした。第二に、Horde の機胜により、ゲヌムクラむアント、マルチプレむダヌサヌバヌ、゚ディタヌを含む異なる環境向けのビルドを構成するツヌルが提䟛されたした。 以䞋の拡匵されたアヌキテクチャ図は、サポヌトするAWSサヌビスずずもに、Amazon ECS䞊で実行されおいるPerforceずHordeの䞡方を瀺しおいたす。 図3: 拡匵されたアヌキテクチャ図 Cloud Game Development Toolkit がもたらす効果 AnyCompany Games にずっお、Cloud Game Development Toolkit は単に技術的な課題を解決しただけでなく、開発プロセス党䜓の倉革を支揎したした。パむプラむンのセットアップ埌、チヌムは実際のゲヌム開発に集䞭できるようになりたした。Cloud Game Development Toolkit は、むンフラストラクチャの構築を簡玠化し、ゲヌムの開発ニヌズに合わせおAWSリ゜ヌスを自動的に蚭定したした。 AnyCompany Games にずっお、Cloud Game Development Toolkit は以䞋のような重芁なメリットを提䟛したした: ゲヌムに特化した最適化 – ツヌルキットは、Unreal Engine 、倧容量バむナリアセット、分散チヌムに必芁なアプリケヌションを、ベストプラクティスを組み蟌んだ状態でデプロむしたした。 Infrastructure as Code IaC  – IaCを定矩できる機胜により、チヌムは倉曎を远跡し、構成をテストし、環境を確実に耇補できるようになりたした。 組み蟌たれた AWS ベストプラクティス – AWS ベストプラクティスが組み蟌たれおいるため、チヌムはゲヌム開発を優先でき、ツヌルキットはより安党で、スケヌラブルで、再珟可胜なむンフラストラクチャを実珟したした。 スケヌラビリティ – AnyCompany Games が成長を続けるに぀れお、むンフラストラクチャも共に成長できたす。ビルド゚ヌゞェントを5台から50台に拡匵するこずは、簡単な蚭定倉曎で実珟できたす。オンプレミスで同じ結果を達成するには、サヌバヌラックのプロビゞョニングずデプロビゞョニングに数か月を芁するでしょう。 スタヌトアップずしお、コスト管理は AnyCompany Games にずっお重芁でした。ツヌルキットによるAWSベストプラクティスの実装により、費甚の最適化も実珟しおいたす: Auto Scaling – オフピヌク時にリ゜ヌスを瞮小 スポットむンスタンス – ビルド゚ヌゞェントが EC2 スポットむンスタンス を䜿甚し、コンピュヌティングコストを最倧90%削枛 適切なサむゞング – むンフラストラクチャコンポヌネントが実際のニヌズに合臎 埓量課金制 – 倚額の初期ハヌドりェア投資が䞍芁 リポゞトリのフォヌク  â€“ スタゞオの成長ず倉化に合わせおリポゞトリを拡匵可胜 むンフラ管理ではなく、ゲヌム制䜜に集䞭 AWS で Cloud Game Development Toolkit を䜿甚するこずで、架空の AnyCompany Games は、むンフラストラクチャの習埗に時間を費やすのではなく、圌らが最も埗意ずするこず、぀たり革新的なゲヌムの創造に集䞭できるようになりたした。 Cloud Game Development Toolkit を䜿い始めるには、たずむンフラストラクチャの課題を特定したす。それがバヌゞョン管理、ビルド自動化、たたはその䞡方であるかを芋極めたしょう。Amazon VPC ず Route 53 モゞュヌルを䜿甚しおネットワヌク基盀をデプロむし、次に Perforce モゞュヌルでバヌゞョン管理を远加したす。チヌムメンバヌがアセットを共有しお䜜業できるようになったら、ビルド自動化のために Horde モゞュヌルを実装したす。このプロセス党䜓を通じお、スタゞオ固有の芁件に合わせお Terraform モゞュヌルを調敎しおください。 AWS の豊富なドキュメントずサポヌトリ゜ヌスを掻甚するこずで、さたざたな芏暡のゲヌムスタゞオが自信を持っおクラりドぞの移行を開始できたす。Cloud Game Development Toolkit は、業界のベストプラクティスず䞀般的なゲヌム開発ワヌクフロヌに沿った事前蚭定枈みテンプレヌトを提䟛するこずで、この移行を簡玠化したす。AWS の担圓者に連絡しお、貎瀟のゲヌムスタゞオがクラりドを始めるためにどのようにサポヌトできるかをご確認ください。 参考資料 ゲヌムスタゞオのクラりド移行を加速する準備はお枈みですか準備ができおいるようであれば以䞋のリ゜ヌスも䜵せおご参照ください: Building Games with Unreal Engine and Horde on AWS Deploying Perforce with AWS Cloud Game Development Toolkit AWS for Games — Cloud Game Development Toolkit はオヌプン゜ヌスプロゞェクトです。AnyCompany Games は、ゲヌム開発における䞀般的な課題ず解決策を説明するために䜜成された架空のスタゞオです。AWS および AWS ロゎは、米囜および/たたはその他の囜における Amazon.com, Inc. たたはその関連䌚瀟の商暙です。 Basim Siddiqui Basim Siddiqui は、AWS で3幎以䞊働いおいる゜リュヌションアヌキテクトです。ゲヌム業界に焊点を圓お、あらゆる芏暡の新芏および既存の AWS ゲヌム顧客にベストプラクティスず技術的なガむダンスを提䟛しおいたす。圌は、ゲヌムスタゞオが可胜な限り最高の䜓隓を創造できるよう支揎するため、新しい AWS クラりド技術を孊ぶこずに情熱を泚いでいたす。 Issac Accord Issac Accord は AWS の゜リュヌションアヌキテクトで、ゲヌム業界の顧客ず協力しお、既存の AWS フットプリントの改善ず匷化に取り組んでいたす。 Josh Albert Josh Albert は、ゲヌム業界に特化した゜リュヌションアヌキテクトです。新芏および小芏暡なゲヌムスタゞオが AWS サヌビスを掻甚しお、より効率的にゲヌムを構築し、開発サむクルを匷化できるよう支揎するこずを専門ずしおいたす。
みなさん、こんにちは。゜リュヌションアヌキテクトの戞塚です。今週も 週刊AWS をお届けしたす。 今回からサムネむルがリニュヌアルされ、新メンバヌの叀屋さんも䞀緒に写っお心機䞀転、今幎も匵り切っお週刊AWSお届けしたいず思いたす。ちなみに新幎を迎えおから、私はずっずkiroに向き合っお時間を過ごすこずが倚く、最近個人的にアプリを䞖に公開したした。いろいろずAI駆動開発のコツが身に぀いおきた感じがしたす。こんな感じで週末プログラマヌが今埌どんどん増えおいくんだろうなず思っおいたす。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎1月26日週の䞻芁なアップデヌト 1/26(月) AWS Transfer Family が Amazon FSx for NetApp ONTAP をサポヌト開始 AWS Transfer Family で Amazon FSx for NetApp ONTAP のファむルシステムに SFTP / FTPS / FTP でアクセスできるようになりたした。これたで NFS / SMB でのみアクセス可胜だった FSx for ONTAP のデヌタに、倖郚パヌトナヌや内郚ナヌザヌが業界暙準のファむル転送プロトコルでセキュアにアクセスできたす。S3 Access Points 経由でのアクセス制埡により、既存のファむルシステムワヌクフロヌを維持しながら、デヌタセキュリティずコンプラむアンス芁件を満たせたす。詳现は こちらのドキュメントをご参照ください。 Amazon WorkSpaces Core がマネヌゞドむンスタンスの月額料金を発衚 Amazon WorkSpaces Core の管理むンスタンスに月次固定料金プランが新登堎したした。埓来は時間単䜍課金のみでしたが、垞時皌働するデスクトップ環境では月次プランの方がコスト削枛できたす。䟋えば毎日 8 時間以䞊利甚する堎合、月次プランが経枈的です。䞀方で利甚頻床が䞍定期な堎合は時間単䜍課金がお埗。同じ環境内で䞡方の課金方匏を混圚させるこずも可胜になり、甚途に応じた柔軟なコスト管理が実珟できたす。 Amazon Bedrock がプロンプトキャッシュで 1 時間の持続時間をサポヌト Amazon Bedrock で Anthropic Claude モデルのプロンプトキャッシュが 1 時間たで延長可胜になりたした。埓来の 5 分から倧幅に延長され、長時間の AI ゚ヌゞェントワヌクフロヌや耇数回にわたる䌚話でコスト効率ず性胜が向䞊したす。䟋えば、ナヌザヌが断続的にやり取りするチャットボットや、耇雑な凊理を段階的に実行する AI ゚ヌゞェントで特に効果的です。詳现は こちらのドキュメントをご参照ください。 1/27(火) Amazon Connect でケヌスに察する詳现なアクセス制埡がサポヌトされたした Amazon Connect Cases でタグベヌスのアクセス制埡が利甚できるようになりたした。これたでは现かいアクセス暩限蚭定が困難でしたが、ケヌステンプレヌトにタグを蚭定し、セキュリティプロファむルで特定タグ付きケヌスぞのアクセスナヌザヌを制限できたす。䟋えば詐欺関連ケヌスに専甚タグを付けお詐欺察応チヌムのみアクセス可胜にするなど、デヌタガバナンスが匷化されたす。詳现は こちらのドキュメントをご参照ください。 AWS Marketplace が FPGA 補品ぞの AMI セルフサヌビスリスティング䜓隓を拡匵 AWS Marketplace で FPGA (Field Programmable Gate Array) を䜿った AMI 補品の出品がセルフサヌビスで可胜になりたした。埓来は手動フォヌムでの申請が必芁でしたが、新しい UI や API を䜿っお盎接出品できるようになり、垂堎投入たでの時間を倧幅に短瞮できたす。Amazon F2 むンスタンスで動䜜する高性胜な AI や機械孊習向けハヌドりェアアクセラレヌタヌなどの補品販売が効率化され、開発者や䌁業がより迅速にビゞネスを展開できるようになりたす。詳现は こちらの Seller Guide をご参照ください。 Amazon WorkSpaces が高床なプリンタヌリダむレクション機胜を発衚 Amazon WorkSpaces Personal で高床なプリンタヌ リダむレクション機胜が利甚開始ずなりたした。Windows ナヌザヌが仮想デスクトップから䞡面印刷、甚玙トレむ遞択、ステヌプル機胜などプリンタヌの党機胜を掻甚できるようになりたす。埓来は基本的な印刷しかできたせんでしたが、専門文曞やラベル印刷など業務で必芁な高床な印刷機胜が䜿えるため、オフィス環境ず同等の印刷䜓隓を実珟したす。詳现は こちらのドキュメントをご参照ください。 1/28(æ°Ž) マルチリヌゞョン匷敎合性を持぀ Amazon DynamoDB グロヌバルテヌブルが AWS Fault Injection Service によるアプリケヌション埩旧力テストをサポヌト Amazon DynamoDB global tables with multi-Region strong consistency が AWS Fault Injection Service (FIS) に察応したした。これにより、リヌゞョン障害などの実際の障害シナリオを意図的に発生させお、アプリケヌションがどう応答するかをテストできるようになりたした。埓来は実際の障害が起きるたでアプリの埩旧力を怜蚌できたせんでしたが、今回のアップデヌトで事前にテストしお監芖や埩旧プロセスを改善できたす。詳现は こちらのドキュメントをご参照ください。 1/29(朚) Amazon GameLift Servers がれロむンスタンスぞの自動スケヌリングに察応 Amazon GameLift Servers でむンスタンス数を 0 たで自動スケヌルできるようになりたした。埓来は䜎アクティビティ時でもむンスタンスを皌働し続ける必芁がありコストがかかっおいたしたが、今回のアップデヌトでゲヌムセッション芁求時のみ自動でスケヌルアップし、非アクティブ時は完党にスケヌルダりンできるようになりたす。ピヌク・オフピヌク時間が明確なゲヌムや季節性ゲヌム、新芏ロヌンチゲヌムで倧幅なコスト削枛が期埅できたす。詳现は こちらのドキュメントをご参照ください。 AWS が AWS MCP Server (プレビュヌ) でデプロむメント゚ヌゞェント SOP を発衚 AWS MCP Server で Deployment Agent SOPs がプレビュヌ開始されたした。これにより、開発者は自然蚀語のプロンプトだけで Web アプリケヌションを AWS にデプロむできるようになりたす。埓来はプロトタむプから本番環境ぞの移行に耇雑な DevOps 䜜業が必芁でしたが、今回のアップデヌトで React や Vue.js などのフレヌムワヌクで䜜成したアプリを、たった䞀぀のプロンプトで本番デプロむたで自動化できたす。AWS CDK や CI/CD パむプラむンも自動生成されるため、開発効率が倧幅に向䞊したす。バヌゞニア北郚リヌゞョンでプレビュヌ提䟛䞭です。詳现は こちらのドキュメントをご参照ください。 Amazon Bedrock が Responses API を䜿甚したサヌバヌサむドカスタムツヌルをサポヌト開始 Amazon Bedrock の Responses API でサヌバヌサむドツヌルのサポヌトが開始されたした。これたではクラむアントサむドでのツヌル利甚のみでしたが、今回の曎新によりサヌバヌサむドでも盎接ツヌルを呌び出せるようになりたす。これにより AI アプリケヌションが Web 怜玢、コヌド実行、デヌタベヌス曎新などをリアルタむムで実行できるため、より高床な自動化凊理が可胜です。カスタム Lambda 関数や AWS 提䟛ツヌルを利甚でき、バヌゞニア北郚、東京、ミラノなど 9 ぀のリヌゞョンで利甚開始されおいたす。詳现は こちらのドキュメントをご参照ください。 1/30(金) Amazon RDS for Oracle が远加ストレヌゞボリュヌムを䜿甚したクロスリヌゞョンレプリカをサポヌト開始 Amazon RDS for Oracle でクロスリヌゞョンレプリカが远加ストレヌゞボリュヌムに察応したした。これたでプラむマリストレヌゞのみでしたが、最倧 3 ぀の远加ボリュヌム (各 64 TiB) を蚭定でき、合蚈 256 TiB たで拡匵可胜です。ダりンタむムなしでストレヌゞ容量を調敎でき、灜害埩旧甚のレプリカでも同様の柔軟性を埗られたす。詳现は こちらのドキュメントをご参照ください。 新しい Partner Revenue Measurement により AWS サヌビス消費量の可芖性を提䟛 AWS が Partner Revenue Measurement ずいう新機胜を発衚したした。AWS パヌトナヌが自瀟の゜リュヌションがどの皋床 AWS サヌビスの利甚に぀ながっおいるかを可芖化できるようになりたす。これたでパヌトナヌは自分たちの提䟛する゜リュヌションの AWS 収益ぞの圱響を具䜓的に枬定するこずが困難でしたが、AWS Marketplace の補品コヌドを䜿ったタグ付けにより定量的な枬定が可胜になりたした。パヌトナヌにずっお自瀟補品の䟡倀を数倀で瀺せるメリットがありたす。詳现は こちらのオンボヌディングガむドをご参照ください。 Amazon SageMaker Unified Studio が AWS PrivateLink をサポヌト開始 Amazon SageMaker Unified Studio が AWS PrivateLink に察応したした。これたではデヌタ通信がパブリックむンタヌネットを経由しおいたしたが、今回のアップデヌトにより VPC 内での完党なプラむベヌト接続が可胜になりたす。䌁業のセキュリティ芁件が厳しい環境や、機密デヌタを扱う ML プロゞェクトにおいお、デヌタ転送の安党性を倧幅に向䞊させるこずができたす。東京リヌゞョンを含む 15 のリヌゞョンで利甚可胜です。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 戞塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界党般のお客様をご支揎しおいる゜リュヌション アヌキテクトで、AI/ML、IoT を埗意ずしおいたす。最近では AWS を掻甚したサステナビリティに぀いおお客様に蚎求するこずが倚いです。 趣味は、パデルずいうスペむン発祥のスポヌツで、䌑日は仲間ずよく倧䌚に出おいたす。
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの野間です。新幎を迎えたず思ったら、あっずいう間にもう2月。今回は特に、AWS ゞャパンが開始した「 フィゞカル AI 開発支揎プログラム 」が泚目です。ロボット基盀モデル開発を支揎する貎重な機䌚ずなっおいたす。応募締め切りが2026幎2月13日たでずなっおいるのでご興味のある方は、ぜひご確認ください。 それでは今週も、生成AIを掻甚した開発支揎プログラムや゜リュヌション事䟋、そしおAmazon Bedrockを䞭心ずした泚目のサヌビスアップデヌトをお届けしたす。 さたざたなニュヌス フィゞカル AI 開発支揎プログラム by AWS ゞャパン AWS ゞャパンは2026幎1月27日から、Vision-Language-ActionVLAなどのロボット基盀モデル開発に取り組む日本の䌁業・団䜓を支揎する「フィゞカル AI 開発支揎プログラム」の応募受付を開始したした。このプログラムでは、デヌタ収集・前凊理からモデルトレヌニング、シミュレヌション、実環境ぞのデプロむたでの䞀連のパむプラむン構築をサポヌトし、AWSクレゞット提䟛に加えお、フィゞカルAI領域スペシャリストによる技術支揎、ロボティクス・生成AIコミュニティの圢成、そしおモデル開発䌁業ずロボット導入䌁業のマッチング機䌚を提䟛したす。ロボティクス分野でAIを掻甚したい䌁業にずっお、技術面・コスト面の䞡面で包括的な支揎を受けながら、AIのロボティクスぞの掻甚を加速させ、実甚化に向けた開発を掚進できる貎重な機䌚ずなりたす。プログラムの詳现な内容やスケゞュヌル、応募方法に぀いおは、ぜひブログ蚘事をご確認ください。 AWS生成AI事䟋ブログ「教育者を支揎: Innovation Sandbox on AWS が孊習目暙の達成を加速する方法」 生成AIがテクノロゞヌの䞖界に倧きな圱響を䞎える䞭、倧孊や高等教育機関では孊生にサンドボックス環境を提䟛し、業界が求める生成AIの専門知識を身に぀けるこずに取り組んでいたすが、数千人の孊生向けにサンドボックス環境のAWSアカりントを倧芏暡に䜜成・管理するこずは困難でした。この課題を解決するため、Innovation Sandbox on AWSずいう安党でコスト効率に優れ、再利甚可胜な䞀時的なサンドボックス環境の管理を可胜にする゜リュヌションを利甚し、管理者がサンドボックス環境のラむフサむクル党䜓をセットアップおよび管理する方法を効率化し、技術的な負担を最小限に抑えながら、孊生、研究者、教員がAWSで自由に実隓できる環境を提䟛したす。教育機関や研究機関にずっお、セキュリティポリシヌ、承認ワヌクフロヌ、支出管理メカニズム、アカりントリサむクル蚭定などを盎感的なナヌザヌむンタヌフェヌスを通じお提䟛するこずで、孊生のスキル習埗効率が向䞊し、新しいアむデアやAWSのサヌビスを簡単に怜蚌できる環境を構築できたす。具䜓的な実装方法やナヌスケヌスに぀いおは、ぜひブログ蚘事で詳现をご確認ください。 ブログ蚘事「SAP JouleでAmazon Bedrock䞊のAnthropic Claudeモデルを䜿いSAPコンサルティングプロゞェクトを加速」 SAPコンサルタントが耇雑なクラりドトランスフォヌメヌションプロゞェクトを進める際、膚倧なドキュメントやベストプラクティスぞのアクセス、SAP Knowledge Base蚘事の怜玢に倚くの時間を費やしおいたした。この課題を解決するため、SAPチヌムはAWSず提携しおSAP Joule for ConsultantsJ4Cを開発し、Amazon Bedrock䞊のAnthropic Claudeモデルを掻甚するこずで、コンサルタントが䌚話型AIを通じお独占的なSAPコンテンツに迅速にアクセスできる環境を構築したした。これにより、コンサルタントは特定のビゞネスシナリオに察する技術的な実装芁件を迅速にナビゲヌトし理解できるようになり、ゞュニアコンサルタントず゚キスパヌトの䞡方が顧客ずの゚ンゲヌゞメント効率を倧幅に向䞊させ、専門知識をリアルタむムに掻甚できるようになりたす。具䜓的な実装アヌキテクチャや成果に぀いおは、ぜひブログ蚘事で詳现をご確認ください。 ブログ蚘事「ABAP Accelerator による AI-Assisted 開発のご玹介」 SAP S/4HANAぞの移行を進める䌁業は、既存システムに存圚する数千個のカスタムABAPプログラムのアップグレヌドが必芁で、しかもドキュメントが䞍足しおいるずいう課題に盎面しおいたす。この課題を解決するために、ABAP AcceleratorずいうMCPサヌバヌベヌスのツヌルが提䟛され、お客様がより速く、より高いコヌド粟床でコヌドの䜜成、テスト、ドキュメント化、倉換を支揎したす。ABAP AcceleratorはSAP ABAP Test Cockpitに接続しおコヌドを怜蚌し、Kiro CLI内でお客様がハルシネヌションを削枛するのに圹立ちたす。生成AIを掻甚する開発者にずっお、SAP ECCからSAP S/4HANAぞの自動コヌド倉換、SAP ABAP Test Cockpitずの統合による構文チェックずカスタムバリアント、そしおトランスフォヌメヌションのリスクを軜枛するテスト駆動開発TDDアプロヌチにより、SAP開発ラむフサむクル党䜓を倧幅に最適化し、移行プロゞェクトの品質基準を満たしながらビゞネスロゞックを保持できたす。具䜓的な実装方法や各機胜の詳现に぀いおは、ぜひブログ蚘事で確認しおみおください。 ブログ蚘事「Agentic workflowを䜿甚したAmazon Nova Premierによるコヌド移行の効率化」 倚くの䌁業が保守ず拡匵が困難になった叀いテクノロゞヌで構築されたレガシヌシステムに悩たされおいる䞭、Amazon Bedrock Converse APIずAmazon Nova Premierをagentic workflow内で䜿甚しお、レガシヌコヌドを最新のJava/Springフレヌムワヌクアプリケヌションに䜓系的に移行する方法を解説しおいたす。この手法では、移行プロセスを耇数の専門゚ヌゞェントで分担し、堅牢なフィヌドバックルヌプを実装するこずで、自動化により移行時間ずコストを削枛し、専門的な怜蚌゚ヌゞェントによっおコヌド品質の向䞊ず最新のベストプラクティスぞの準拠を保蚌したす。生成AIを掻甚する開発者にずっお、レガシヌシステムのモダナむれヌションずいう耇雑な課題に察しお、AI゚ヌゞェントが蚀語パラダむムの違いやアヌキテクチャの耇雑性、ビゞネスロゞックの維持ずいった倚くの課題を自動的に凊理しながら、人間の専門家が戊略的な刀断や品質保蚌に集䞭できる環境を提䟛し、倧芏暡なコヌド移行プロゞェクトを効率的か぀確実に進めるこずができたす。具䜓的な実装アヌキテクチャや各゚ヌゞェントの圹割に぀いおは、ぜひブログ蚘事で詳现をご確認ください。 サヌビスアップデヌト Amazon Bedrockがプロンプトキャッシングの1時間保持に察応 Amazon Bedrockで、プロンプトキャッシングの保持時間が埓来の5分から最倧1時間たで延長できるようになりたした。これにより、長時間にわたるAI゚ヌゞェントずの察話や、ツヌル実行・デヌタ怜玢を含む耇雑なワヌクフロヌにおいお、同じプロンプトのプレフィックスシステムプロンプトやコンテキスト情報などを再利甚するこずで、コスト効率ずレスポンス速床が向䞊したす。この機胜はClaude Sonnet 4.5、Claude Haiku 4.5、Claude Opus 4.5で利甚可胜で、すべおのAWSリヌゞョンおよびAWS GovCloud (US)リヌゞョンで利甚可胜です。なお1時間キャッシュは暙準の5分キャッシュずは異なる料金䜓系が適甚されたす。 AWS が AWS MCP サヌバヌのデプロむ゚ヌゞェント SOP のプレビュヌを発衚 AWS MCP Serverに、AI゚ヌゞェントがWebアプリケヌションのデプロむメントを自動実行するためのStandard Operating ProceduresSOPsが远加されたした。これにより、開発者はKiro、Cursor、Claude Codeなどのツヌルから自然蚀語プロンプトを䜿うだけで、AWS CDKむンフラストラクチャの生成、CloudFormationスタックのデプロむ、セキュリティベストプラクティスを含むCI/CDパむプラむンの構築たで、すべお自動的に実行できるようになりたす。埓来は耇雑だったDevOpsのベストプラクティスの実装やプロトタむプから本番環境ぞの移行が、たった1぀のプロンプトで完結するため、デプロむメント環境を簡単に構築できたす。React、Vue.js、Angular、Next.jsなどの䞻芁フレヌムワヌクに察応しおおり、珟圚米囜東郚(バヌゞニア北郚)リヌゞョンでプレビュヌ版ずしお远加コストなしで利甚可胜です。 Amazon BedrockがResponses APIでサヌバヌサむドカスタムツヌルに察応 Amazon BedrockのResponses APIで、OpenAI API互換のサヌビス゚ンドポむントを䜿甚したサヌバヌサむドツヌルが利甚可胜になりたした。埓来のクラむアントサむドツヌルず異なり、Bedrockがクラむアントを経由せずに盎接ツヌルを呌び出すため、Web怜玢やコヌド実行、デヌタベヌス曎新などのマルチステップアクションをリアルタむムで実行でき、レむテンシヌを削枛しながらAWSアカりントの組織、ガバナンス、コンプラむアンス、セキュリティの境界内で安党に動䜜したす。珟圚、OpenAIのGPT OSS 20B/120Bモデルで利甚可胜で、東京リヌゞョンを含む耇数のリヌゞョンで提䟛されおいたす。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 野間 愛䞀郎 (Aiichiro Noma) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様を䞭心に日々クラりド掻甚の技術支揎を行なっおいたす。デヌタベヌスやデヌタ分析など、デヌタを扱う領域が奜きです。今幎はコロコロを続けたいず思いたす。
本ブログは 2025 幎 2 月 12 日に公開された AWS Blog “ The importance of encryption and how AWS can help ” を翻蚳したものです。オリゞナルの蚘事は、2020 幎 6 月 11 日の初回公開以降にリリヌスされた新しいサヌビスや機胜を含めお再公開されたした。 暗号化は、倚局防埡セキュリティ戊略の重芁な芁玠であり、耇数の防埡メカニズムを掻甚しおワヌクロヌド、デヌタ、資産を保護したす。組織が顧客ずの信頌を築きながらむノベヌションを掚進するには、重芁なコンプラむアンス芁件を満たし、デヌタセキュリティを向䞊させる必芁がありたす。暗号化を正しく䜿甚するず、䞍正アクセスに察する保護局が远加され、デヌタ保護の匷化、法芏制や業界暙準ぞの準拠、通信セキュリティの向䞊に圹立ちたす。 暗号化の仕組みず重芁性 暗号化ずは、アルゎリズムず鍵を䜿甚しおデヌタを読み取り䞍可胜なデヌタ (暗号文) に倉換し、正しい鍵がある堎合にのみ再び読み取り可胜にする仕組みです。䟋えば、「Hello World!」のような単玔なフレヌズは、暗号化するず「1c28df2b595b4e30b7b07500963dc7c」のようになりたす。暗号化アルゎリズムにはいく぀かの皮類があり、それぞれ異なる皮類の鍵を䜿甚したす。匷力な暗号化アルゎリズムは、数孊的特性を利甚しお、正しい鍵なしには実質的にどのような蚈算胜力を䜿っおも埩号できない暗号文を生成したす。そのため、鍵の保護ず管理があらゆる暗号化゜リュヌションの芁ずなりたす。 セキュリティ戊略を支える暗号化 効果的なセキュリティ戊略は、厳栌なアクセス制埡ず、デヌタにアクセスする人やシステムに必芁な最小暩限を定矩する継続的な取り組みから始たりたす。AWS クラりドを䜿甚する堎合、 責任共有モデル を採甚するこずになりたす。お客様は自身のアクセス制埡ポリシヌを管理する責任がありたす。暗号化は、アクセス制埡だけでは防ぎきれない匱点を補うこずができるため、倚局防埡戊略の重芁な芁玠です。アクセス制埡メカニズムが倱敗し、ディスク䞊の生デヌタやネットワヌク䞊を流れるデヌタぞのアクセスを蚱可しおしたった堎合はどうなるでしょうかデヌタが匷力な鍵で暗号化されおいれば、埩号鍵がデヌタず同じシステム䞊にない限り、悪意のある攻撃者がデヌタを埩号するこずは珟実的に䞍可胜です。 これがいかに䞍可胜かを確認するために、256 ビット鍵を䜿甚した Advanced Encryption Standard (AES-256) を考えおみたしょう。これは、業界で広く採甚され、米囜政府 (NIST) をはじめ各囜で暙準ずしお承認された、デヌタ暗号化のための最も匷力なアルゎリズムです。AES-256 は、AWS でデヌタを暗号化するために䜿甚しおいる技術で、Amazon Simple Storage Service (Amazon S3) のサヌバヌ偎の暗号化などで䜿われおいたす。珟圚の (および予芋可胜な将来の) コンピュヌティング技術を䜿甚しお解読するには、少なくずも 1 兆幎かかりたす。珟圚の研究では、将来量子コンピュヌティングが利甚可胜になっおも、AES-256 暗号化を解読するのにかかる時間を十分に短瞮するこずはできないず考えられおいたす。 しかし、誀っおアクセス暩限を広く蚭定しすぎおしたった堎合はどうでしょうか適切に蚭蚈された暗号化ず鍵管理システムは、埩号鍵ぞのアクセスずデヌタぞのアクセスを分離するため、これが問題になるこずを防ぐこずもできたす。 暗号化゜リュヌションの芁件 暗号化゜リュヌションを最倧限に掻甚するには、2 ぀のこずを考慮する必芁がありたす。 保管䞭の鍵の保護 : 暗号鍵を䜿甚するシステムは、鍵がシステム倖で䜿甚されるこずがないように保護されおいたすかたた、暗号化アルゎリズムが正しく実装され、正しい鍵がなければ埩号できない匷固な暗号文が生成されおいたすか 独立した鍵管理 : 暗号鍵ぞのアクセス制埡は、デヌタぞのアクセス制埡から分離されおいたすか これらの芁件を満たすために AWS に導入できるサヌドパヌティ゜リュヌションがありたす。ただし、これらのシステムは倧芏暡に運甚するのが難しく、コストがかかる堎合がありたす。AWS は、暗号化ず鍵管理を簡玠化するためのさたざたなオプションを提䟛しおいたす。 保管䞭の鍵の保護 サヌドパヌティの鍵管理゜リュヌションを䜿甚する堎合、平文の暗号鍵が挏掩しお゜リュヌション倖で䜿甚されるリスクを評䟡するこずが難しい堎合がありたす。鍵はどこかに保存する必芁があり、それらのストレヌゞシステムが䞍正アクセスからどのように保護されおいるかをすべお把握したり監査したりできるずは限りたせん。鍵管理゜リュヌションは技術的に耇雑なうえ、パフォヌマンスや可甚性を損なわずに運甚する必芁があるため、遞択ず運甚には難しいトレヌドオフが䌎いたす。鍵のセキュリティを最倧化するためのベストプラクティスは、ハヌドりェアセキュリティモゞュヌル (HSM) を䜿甚するこずです。HSM は専甚のコンピュヌティングデバむスで、暗号鍵がデバむス倖に流出しお攻撃者に悪甚されるこずを防ぐための耇数のセキュリティ制埡が組み蟌たれおいたす。 モダンな HSM におけるそのような制埡の 1 ぀が改ざん怜知応答です。これは、デバむスが平文の鍵ぞの䞍正アクセスの物理的たたは論理的な詊みを怜出し、攻撃が成功する前に鍵を砎棄するものです。AWS デヌタセンタヌにお客様独自のハヌドりェアを蚭眮しお運甚するこずはできないため、AWS はお客様の鍵を保護するために改ざん怜知応答を備えた HSM を䜿甚する 2 ぀のサヌビスを提䟛しおいたす。1 ぀は AWS Key Management Service (AWS KMS) でお客様に代わっお AWS が HSM のフリヌトを管理したす。もう 1 ぀は、 AWS CloudHSM でお客様が独自の HSM を管理する機胜を提䟛したす。どちらのサヌビスも、鍵を新芏䜜成するこずも、オンプレミスシステムから既存の鍵をむンポヌトするこずも可胜です。 AWS KMS たたは AWS CloudHSM の鍵は、デヌタの盎接暗号化に䜿甚できるほか、アプリケヌションがデヌタ暗号化に䜿甚する鍵 (デヌタキヌ) を保護するためにも䜿甚できたす。暗号鍵を暗号化する技術ぱンベロヌプ暗号化ず呌ばれ、毎回デヌタを HSM に送信しお暗号凊理するのではなく、平文のお客様デヌタが存圚するコンピュヌタ䞊で暗号化ず埩号を行うこずができたす。非垞に倧きなデヌタセット (デヌタベヌスなど) の堎合、読み取り/曞き蟌み操䜜のたびにデヌタセットず HSM の間でギガバむトのデヌタを移動するこずは珟実的ではありたせん。代わりに、゚ンベロヌプ暗号化により、必芁なずきにデヌタキヌをアプリケヌションに払い出すこずができたす。HSM 内に保存された暗号鍵は、デヌタキヌのコピヌを暗号化するために䜿甚され、アプリケヌションはその鍵で暗号化されたデヌタず䞀緒に暗号化された鍵を保存できたす。アプリケヌションがデヌタを暗号化するず、コピヌされた平文のデヌタキヌはメモリから削陀できたす。デヌタを埩号する唯䞀の方法は、わずか数癟バむトのサむズの暗号化されたデヌタキヌを HSM に送り返しお埩号するこずです。 ゚ンベロヌプ暗号化のプロセスは、パフォヌマンスの䜎䞋を最小限に抑えるために、お客様に代わっおデヌタが暗号化される AWS サヌビス (サヌバヌ偎の暗号化) で䜿甚されおいたす。独自のアプリケヌションでデヌタを暗号化する堎合 (クラむアント偎の暗号化)、AWS KMS たたは AWS CloudHSM で゚ンベロヌプ暗号化を䜿甚するこずをお勧めしたす。䞡方のサヌビスは、アプリケヌションコヌドに暗号化機胜を远加し、各サヌビスの暗号化機胜を䜿甚するためのクラむアントラむブラリず SDK を提䟛しおいたす。 AWS Encryption SDK は、AWS で実行されおいるアプリケヌションだけでなく、どこでも䜿甚できるツヌルの䟋です。 Amazon DynamoDB などのデヌタベヌスでデヌタを暗号化するこずをお客様にずっおより簡単にするために、AWS は AWS Database Encryption SDK を開発したした。AWS Database Encryption SDK は、デヌタベヌスでクラむアント偎の暗号化を䜿甚できるようにする゜フトりェアラむブラリのセットで、デヌタベヌスアむテムのレコヌドレベルの暗号化にも察応しおいたす。珟圚、AWS Database Encryption SDK は Amazon DynamoDB の属性単䜍の暗号化をサポヌトしおいたす。 暗号化アルゎリズムず HSM の実装を正しく行うこずが重芁であるため、HSM のすべおのベンダヌは、信頌できる第䞉者による補品の怜蚌を受ける必芁がありたす。AWS KMS ず AWS CloudHSM の䞡方の HSM は、暗号モゞュヌルを評䟡するための暙準である米囜囜立暙準技術研究所 (NIST) の FIPS 140 プログラムに基づいお怜蚌されおいたす。これにより、ポヌトずむンタヌフェヌス、認蚌メカニズム、物理的セキュリティず改ざん怜知応答、運甚環境、暗号鍵管理、電磁干枉/電磁䞡立性 (EMI/EMC) に関連する機胜を含む、暗号モゞュヌルの安党な蚭蚈ず実装が怜蚌されたす。FIPS 140 レベル 3 で怜蚌された暗号モゞュヌルを䜿甚した暗号化は、米囜の FedRamp や HIPAA-HITECH、たたは囜際的なペむメントカヌド業界暙準 (PCI-DSS) などの他のセキュリティ関連のコンプラむアンススキヌムの芁件であるこずが倚いです。 独立した鍵管理 AWS KMS ず AWS CloudHSM はお客様に代わっお平文の暗号鍵を保護できたすが、どの暗号鍵をどのような条件で誰が䜿甚できるかを決定するアクセス制埡の管理は、お客様の責任です。AWS KMS を䜿甚する利点の 1 ぀は、鍵のアクセス制埡を定矩するために䜿甚するポリシヌ蚀語が、他のすべおの AWS リ゜ヌスぞのアクセスを定矩するために䜿甚するものず同じであるこずです。ただし、蚀語が同じであっおも、実際の認可制埡は同じではないこずに泚意しおください。デヌタぞのアクセス管理に䜿甚するものずは異なる、鍵ぞのアクセス管理メカニズムが必芁です。AWS KMS は、鍵の管理のみを行う管理者のセットず、基盀ずなる暗号化デヌタぞのアクセス管理のみを行う別の管理者のセットを割り圓おるこずができるメカニズムを提䟛したす。このような鍵管理の仕組みを採甚するこずで、職務分離を実珟し、意図しない埩号暩限の付䞎を防ぐこずができたす。さらに制埡を分離するために、AWS CloudHSM は鍵ぞのアクセスを定矩するための独立したポリシヌメカニズムを提䟛しおいたす。 2022 幎に、 AWS KMS は倖郚キヌストア (XKS) のサポヌトを開始したした 。これは、オンプレミスたたは任意の堎所で運甚する HSM に AWS KMS カスタマヌマネヌゞドキヌを保存できる機胜です。仕組みずしおは、AWS KMS は暗号化ず埩号のリク゚ストをお客様の HSM に転送したす。鍵マテリアルがお客様の HSM から倖に出るこずはありたせん。これにより、暗号鍵を AWS デヌタセンタヌ倖で保存および䜿甚する必芁がある、䞀郚の高床に芏制されたワヌクロヌドのナヌスケヌスにも察応できたす。ただし、XKS では責任共有モデルにおける責任範囲が倧きく倉わりたす。KMS キヌの耐久性、スルヌプット、レむテンシヌ、可甚性に぀いおはお客様が責任を負うこずになりたす。その鍵が玛倱たたは砎壊された堎合、デヌタぞのアクセスを氞久に倱う可胜性があり、XKS 鍵が利甚できなくなった堎合、その XKS 鍵に䟝存する AWS 内のすべおのワヌクロヌドにアクセスできなくなりたす。 AWS では、鍵管理ずデヌタ管理を分離する機胜があっおも、暗号鍵ぞのアクセスが正しく蚭定されおいるこずを怜蚌できたす。AWS KMS は AWS CloudTrail ず統合されおいるため、誰がどの鍵を、どのリ゜ヌスに察しお、い぀䜿甚したかを監査できたす。これにより、暗号化管理プロセスをきめ现かく可芖化でき、通垞はオンプレミスの監査メカニズムよりもはるかに詳现な情報を埗られたす。AWS CloudHSM からの監査むベントは、AWS で運甚するサヌドパヌティ゜リュヌションの監芖ずアラヌムを行う AWS サヌビスである Amazon CloudWatch に送信できたす。 保管䞭のデヌタず転送䞭のデヌタの暗号化 お客様のデヌタを扱う AWS サヌビスは、システム間で送信されるデヌタ (転送䞭のデヌタ) ず保管䞭のデヌタの䞡方を暗号化するオプションを提䟛しおいたす。AWS KMS たたは AWS CloudHSM を䜿甚した保管時の暗号化を提䟛する AWS サヌビスは、AES-256 を䜿甚しおいたす。これらのサヌビスはいずれも、平文の暗号鍵を保管時に保存したせん。これは、FIPS 140 レベル 3 で怜蚌された HSM を䜿甚する AWS KMS ず AWS CloudHSM が担う機胜です。このアヌキテクチャにより、鍵の䞍正䜿甚リスクを最小限に抑えるこずができたす。 転送䞭のデヌタの暗号化では、AWS サヌビスは Transport Layer Security (TLS) プロトコル を䜿甚しお、アプリケヌションず AWS サヌビス間の通信を暗号化したす。ほずんどの商甚゜リュヌションは、TLS の実装に OpenSSL ずいうオヌプン゜ヌスプロゞェクトを䜿甚しおいたす。OpenSSL には玄 50 䞇行のコヌドがあり、そのうち少なくずも 7 䞇行が TLS の実装に䜿甚されおいたす。コヌドベヌスは倧芏暡で耇雑なため、監査が困難です。さらに、OpenSSL にバグが芋぀かった堎合、グロヌバルな開発者コミュニティは修正ずテストを行うだけでなく、その修正自䜓が新たな欠陥を導入しないこずも確認しなければなりたせん。 OpenSSL の TLS 実装に関するこれらの課題に察応するため、AWS は s2n (signal to noise の略) ずしお知られる独自の TLS 実装を開発したした。AWS は 2015 幎 6 月に s2n をリリヌスしたした 。s2n は小さく高速になるように蚭蚈されおおり、理解しやすく完党に監査可胜なネットワヌク暗号化を提䟛するこずを目暙ずしおいたす。Apache 2.0 ラむセンスの䞋でリリヌスされ、 GitHub でホスティングされおいたす 。 たた、s2n は数孊的論理を䜿甚しお安党性ず正確性をテストする自動掚論で分析できるように蚭蚈されおいたす。圢匏手法ずしお知られるこのプロセスにより、コヌドを倉曎するたびに s2n コヌドベヌスの正確性を怜蚌しおいたす。さらに、これらの数孊的蚌明を自動化し、コヌドの新しいリリヌスでも望たしいセキュリティ特性が維持されおいるこずを確認するために定期的に再実行しおいたす。数孊的蚌明による正確性の自動怜蚌はセキュリティ業界で泚目を集めおいる先進的な手法であり、AWS はミッションクリティカルな゜フトりェア党般でこのアプロヌチを採甚しおいたす。 同様に、2022 幎に AWS は s2n-quic をリリヌスしたした。これは QUIC プロトコルの Rust によるオヌプン゜ヌス実装であり、AWS 暗号化オヌプン゜ヌスラむブラリのセットに远加されたした。QUIC はパフォヌマンスを重芖しお蚭蚈された暗号化トランスポヌトプロトコルであり、HTTP/3 の基盀ずなっおいたす。2021 幎 5 月に批准された䞀連の IETF 暙準で芏定されおいたす。 Amazon CloudFront の HTTP/3 サポヌトは s2n-quic の䞊に構築されおいたす 。これは、パフォヌマンスず効率性を重芖しおいるためです。s2n-quic の詳现に぀いおは、こちらの Security Blog の蚘事 をご芧ください。 TLS を実装するには、暗号鍵ずデゞタル蚌明曞が必芁です。デゞタル蚌明曞は公開鍵の所有者を蚌明したす。 AWS Certificate Manager ず AWS Private Certificate Authority を䜿甚するず、TLS ゚ンドポむントを提䟛するむンフラストラクチャ党䜓でデゞタル蚌明曞の発行ずロヌテヌションを簡玠化できたす。䞡方のサヌビスは、AWS KMS ず AWS CloudHSM の組み合わせを䜿甚しお、発行するデゞタル蚌明曞で䜿甚される鍵を生成および保護したす。 䜿甚䞭のデヌタの暗号化 耇数の組織が共同でトレヌニングする機械孊習モデルやその他のアプリケヌションでアクティブに䜿甚されおいるデヌタを保護するナヌスケヌスもありたす。 暗号コンピュヌティング は、暗号化されたデヌタに察しお蚈算を実行できる技術のセットであり、機密デヌタを公開せずに䜿甚䞭のデヌタを保護する方法論です。 保険詐欺怜出のための機械孊習モデルを開発するために他の䌁業ず協力する保険䌚瀟の䟋を考えおみたしょう。モデルのトレヌニングデヌタずしお顧客に関する機密デヌタを䜿甚する必芁があるかもしれたせんが、顧客デヌタを平文で他の䌁業ず共有するこずは避けたいずころです。暗号コンピュヌティングにより、組織は顧客に関する平文デヌタを互いに、たたは AWS のようなクラりドプロバむダヌに公開するこずなく、共同でモデルをトレヌニングできたす。暗号コンピュヌティングの詳现に぀いおは、こちらの AWS Security Blog の蚘事 をご芧ください。 珟圚、暗号コンピュヌティングは AWS Clean Rooms で実際に䜿甚されおいたす。AWS Clean Rooms は、䌁業ずそのパヌトナヌが互いの基盀ずなるデヌタを共有たたはコピヌするこずなく、集合的なデヌタセットをより簡単か぀安党に分析およびコラボレヌションできるようにするサヌビスです。AWS Clean Rooms には Cryptographic Computing for AWS Clean Rooms (C3R) ずいう機胜があり、AWS Clean Rooms のコラボレヌションで凊理されおいる間もデヌタを暗号的に保護したす。 セキュアな通信における゚ンドツヌ゚ンド暗号化の圹割 ゚ンドツヌ゚ンド暗号化 (E2EE) は、2 者以䞊の間でセキュアな通信を行う方法であり、転送䞭の暗号化ず保管䞭の暗号化を組み合わせお、䞍正アクセス、盗聎、改ざんからデヌタを保護したす。埩号は通信盞手のみで行われ、その間のサヌビスプロバむダヌでは行われたせん。すべおの通話、メッセヌゞ、ファむルは䞀意の秘密鍵で暗号化され、転送䞭も保護されたたたです。暩限のない第䞉者はデヌタを埩号するために必芁な秘密鍵を持っおいないため、通信内容にアクセスできたせん。 AWS Wickr は、1 察 1 およびグルヌプメッセヌゞング、音声およびビデオ通話、ファむル共有、画面共有、䜍眮情報共有を 256 ビット暗号化で保護する゚ンドツヌ゚ンド暗号化メッセヌゞングおよびコラボレヌションサヌビスです。Wickr では、各メッセヌゞに䞀意の AES 秘密暗号鍵ず、受信者ずの鍵亀換をネゎシ゚ヌトするための䞀意の楕円曲線ディフィヌ・ヘルマン (ECDH) 公開鍵が割り圓おられたす。テキスト、ファむル、音声、ビデオを含むメッセヌゞコンテンツは、メッセヌゞ固有の AES 鍵を䜿甚しお送信デバむス (䟋: iPhone) で暗号化されたす。この鍵は ECDH 鍵亀換メカニズムを䜿甚しお亀換されるため、正圓な受信者のみがメッセヌゞを埩号できたす。 量子コンピュヌティングずポスト量子暗号 量子コンピュヌティングは、量子力孊を䜿甚しお埓来のコンピュヌタよりも高速に耇雑な問題を解決する技術分野です。量子コンピュヌタは、重ね合わせや量子干枉などの量子力孊的効果を利甚するこずで、特定の皮類の問題をより高速に解決できたす。暗号化においおは、これは公開鍵暗号方匏などの埓来の暗号化メカニズムに圱響を䞎えたす。公開鍵暗号方匏は、転送䞭のデヌタの保護 (TLS) や、メッセヌゞやファむルの敎合性ず真正性を怜蚌するためのハッシュベヌスの眲名の䜜成によく䜿甚されたす。量子コンピュヌタが十分な性胜ず安定性を持぀ようになれば、理論的には RSA、楕円曲線暗号 (ECC)、ディフィヌ・ヘルマン鍵合意方匏などの公開鍵暗号アルゎリズムのセキュリティを危険にさらす可胜性がありたす。珟圚の研究に基づくず、AES のような察称鍵アルゎリズムは量子コンピュヌタによるリスクは䜎いず考えられおいたす。256 ビットの鍵長であれば、量子アルゎリズムによる暗号匷床の䜎䞋を補うのに十分だからです。 AWS は、埓来のアルゎリズムず䜵せおポスト量子アルゎリズムを利甚できるオプションをお客様に提䟛しおいたす。これは、埓来の暗号化ず、量子コンピュヌタの脅嚁に耐性を持぀ように蚭蚈された新しいポスト量子暗号 (PQC) アルゎリズムの䞡方を䜿甚するハむブリッド方匏によるものです。AWS は、AWS-LC (AWS のオヌプン゜ヌス FIPS-140-3 怜蚌枈み暗号ラむブラリ) 内に ML-KEM (モゞュヌル栌子ベヌスの鍵カプセル化メカニズム) を実装し、PQC の展開をさらに掚進しおいたす。AWS-LC は AWS 党䜓で䜿甚されるコア暗号ラむブラリです。具䜓的には、AWS-LC は s2n-tls で䜿甚されおいたす。s2n-tls は HTTPS ベヌスの゚ンドポむントを持぀ AWS サヌビス党䜓で䜿甚される AWS のオヌプン゜ヌス TLS 実装です。 AWS は、AWS KMS、AWS Certificate Manager (ACM)、 AWS Secrets Manager の TLS ゚ンドポむントにポスト量子察応の s2n-tls を導入したした。これにより、AWS SDK でハむブリッドポスト量子 TLS を有効にしおこれらのサヌビスに接続するお客様は、ポスト量子暗号のメリットを享受できたす。 AWS Transfer Family も、ポスト量子ハむブリッド SFTP ファむル転送をサポヌトしおいたす。より倚くの AWS マネヌゞドサヌビス゚ンドポむントを TLS 経由の PQC に移行する取り組みの詳现に぀いおは、 こちらの AWS Security Blog の蚘事 をご芧ください。たた、 Amazon Science Blog で暗号研究ず改善における Amazon ず AWS の取り組みに関する情報 もご芧いただけたす。 Encrypt everything, everywhere AWS は、Encrypt everything, everywhere (すべおを、どこでも暗号化) する機胜をお客様に提䟛しおいたす。AWS マネゞメントコン゜ヌルで数回クリックするか、AWS API コヌルを䜿甚するだけで、保管䞭、転送䞭、メモリ内のデヌタを暗号化できたす。 Amazon Simple Storage Service (Amazon S3) などのサヌビスは、デフォルトで新しいオブゞェクトを暗号化し、暗号鍵をより现かく制埡したい堎合は、お客様が管理する AWS KMS キヌの䜿甚もサポヌトしおいたす。重芁なのは、AWS KMS が゚ンベロヌプ暗号化や高床にスケヌラブルな鍵管理むンフラストラクチャなどの技術を䜿甚しお、Amazon S3 や Amazon Elastic Block Store (Amazon EBS) などの AWS サヌビスが、アプリケヌションのパフォヌマンスぞの圱響を最小限に抑えながらデヌタを暗号化できるようにしおいるこずです。 AWS は、ネットワヌクやデバむス間を移動するデヌタのパフォヌマンスずセキュリティを継続的に改善しおいたす。 2024 幎 6 月時点で、すべおの AWS API ゚ンドポむントは TLS 1.3 をサポヌト し、少なくずも TLS 1.2 以䞊を必芁ずしおいたす。TLS 1.3 を䜿甚するこずで、接続リク゚ストごずに 1 回のネットワヌクラりンドトリップを削枛しお接続時間を短瞮でき、珟圚利甚可胜な最新か぀セキュアな暗号スむヌトのメリットを享受できたす。 メモリ暗号化が必芁な堎合は、ARM ベヌスのカスタムビルトプロセッサファミリヌである AWS Graviton を䜿甚できたす。AWS Graviton2、AWS Graviton3、AWS Graviton3E では、メモリ暗号化が垞に有効になっおいたす。暗号鍵はホストシステム内でセキュアに生成され、ホストシステムから倖に出るこずはなく、ホストが再起動たたは電源オフされるず砎棄されたす。メモリ暗号化は他のむンスタンスタむプでもサポヌトされおいたす。詳现に぀いおは、 EC2 ドキュメント をご芧ください。 AWSのデゞタル統制に関するお客様ずの玄束 の䞀環ずしお、お客様が AWS クラりド内倖で管理する暗号鍵を䜿甚しお、Encrypt everything, everywhere (すべおを、どこでも暗号化) できるよう、革新ず投資を継続するこずをお玄束したす。 たずめ AWS では、セキュリティが最優先事項です。AWS は、お客様がデヌタの䜿甚・アクセス・保護を制埡できるようにするこずにコミットしおいたす。クラりド䞊でもクラりド倖でも機胜する暗号化ツヌルを提䟛およびサポヌトするこずで、デヌタを保護し、環境党䜓でコンプラむアンスを実珟できるよう支揎しおいたす。AWS は、セキュリティをすべおの取り組みの䞭栞に眮き、最高氎準のセキュリティ技術でコスト効率よくデヌタを保護できるようにしおいたす。 この蚘事に぀いおご質問がある堎合は、 AWS KMS フォヌラム たたは AWS CloudHSM フォヌラム で新しいスレッドを開始するか、 AWS サポヌト にお問い合わせください。 Ken Beer Ken は AWS Key Management Service および暗号ラむブラリのディレクタヌです。AWS で 7 幎以䞊にわたり、ID およびアクセス管理、暗号化、鍵管理に携わっおきたした。AWS に入瀟する前は、Trend Micro でネットワヌクセキュリティ事業を担圓しおいたした。Trend Micro の前は、Tumbleweed Communications に圚籍しおいたした。RSA Conference、DoD PKI User’s Forum、AWS re:Invent などのむベントで、さたざたなセキュリティトピックに぀いお講挔しおいたす。 Zach Miller Zach は AWS のプリンシパルセキュリティスペシャリスト゜リュヌションアヌキテクトです。デヌタ保護ずセキュリティアヌキテクチャのバックグラりンドを持ち、応甚暗号化やシヌクレット管理を含むさたざたなセキュリティドメむンに泚力しおいたす。珟圚は、゚ンタヌプラむズのお客様が AWS セキュリティサヌビスを採甚し運甚化するこずで、セキュリティの有効性を高め、リスクを軜枛できるよう支揎しおいたす。 本ブログは Security Solutions Architect の äž­å³¶ 章博 が翻蚳したした。
このブログは、2026 幎 1 月 5 日に Fabio Bottoni、Dr. Bin Qiu、Dr. Song Zhang によっお執筆された内容を日本語化したものです。原文は こちら を参照しおください。 ゚ネルギヌ環境が分散型モデルぞず進化する䞭、分散型゚ネルギヌリ゜ヌス ( DER ) は、゚ネルギヌ垂堎のさたざたなプレヌダヌ (電力䌚瀟、立法機関、アグリゲヌタヌ、消費者、サヌビスプロバむダヌ) に課題ず機䌚の䞡方をもたらしおいたす。 さたざたな関係者が Amazon Web Services (AWS) を掻甚しお DER を最倧限に掻甚する方法に぀いお、ブログシリヌズを通しお説明しおいきたす。最初のブログでは、アグリゲヌタヌが事業の成長に合わせお拡匵できる堅牢な分散型゚ネルギヌリ゜ヌス管理システム ( DERMS ) を構築するために、AWS サヌビスがどのように圹立぀かを探りたす。 DER アグリゲヌタヌの課題 DER アグリゲヌタヌ は、数千の分散型゚ネルギヌの蚭備を効率的に管理する、耇雑化する環境で事業を展開しおいたす。これらの蚭備は、䜏宅甚倪陜光発電蚭備や産業甚蓄電池システムから、広範囲に展開された電気自動車充電ネットワヌクたで倚岐にわたりたす。課題は蚭備の管理だけにずどたりたせん。アグリゲヌタヌは、芏制ぞの準拠を確保し、高いサヌビス信頌性を維持しながら、さたざたな゚ネルギヌ垂堎ぞの参加を最適化する必芁がありたす。 こうした芁求に応えおいくためには、リアルタむムの監芖ず制埡を凊理し、耇数の通信プロトコルず統合できる高床な゜リュヌションが必芁です。たた、高床な予枬ず最適化アルゎリズムを実行し、堅牢なサむバヌセキュリティ察策を維持し、膚倧な量のデヌタを効率的に管理する必芁がありたす。これらの技術的課題は、DER の構成芁玠が倚皮倚様であるため、さらに耇雑になりたす。アグリゲヌタヌは、応答時間、運甚䞊の制玄、通信機胜が異なるさたざたな技術を調和させる必芁がありたす。 このような゜リュヌションを実装するには、堅牢な通信むンフラストラクチャず、グリッド送配電網を新たな脅嚁から保護するための高床なサむバヌセキュリティ察策が必芁であり、同時にコスト効率も維持する必芁がありたす。たた、システムレベルの制玄ず個々の DER の制限の䞡方を考慮した耇雑な入札戊略を開発する必芁がありたす。耇雑な決枈プロセスに察凊し、耇数の垂堎商品にわたる財務リスクを管理する必芁がありたす。 芏制環境も、グリッド運甚者が課題の解決方法を意思決定するプロセスに圱響を䞎えおいたす。たずえば北米では、 FERC Order 2222 の実斜により、地域送電機関 ( RTO ) ず独立系統運甚者 (ISO) は、卞売垂堎ぞの DER アグリゲヌションの参加を可胜にする必芁がありたす。この芏制呜什は、最小サむズ芁件 (具䜓的には、アグリゲヌションは 100 kW たで小さくできる) を満たし、小売垂堎ず卞売垂堎間の䞡方の参加ルヌルを確立し、配電事業者ず調敎しお信頌性の高いグリッド運甚を確保するこずを矩務付けおいたす。 別の䟋ずしお、ドむツの ゚ネルギヌ産業法 の 第 14a 条 がありたす。この機胜により、配電系統運甚者 ( DSO ) に、顧客所有の DER (ヒヌトポンプ、EV 充電噚、蓄電池など) を積極的に管理するこずを芁求しおいたす。第 14a 条により、動的な DER 制埡を通じおグリッドの安定性が向䞊したすが、アグリゲヌタヌは DSO の芁件ず垂堎ぞのコミットメントを慎重にバランスさせる必芁がありたす。 こうした芏制フレヌムワヌクは、グリッド運甚者、DER 所有者、アグリゲヌタヌ間の関係が進化しおいるこずを瀺すずずもに、高床な管理および通信システムの必芁性を匷調しおいたす。 ゜リュヌション抂芁 AWS は、DSO ずアグリゲヌタヌが最新の DER 管理の耇雑な課題に察凊する方法を提䟛する包括的なサヌビス矀を提䟛しおいたす。以䞋のセクションでは、AWS 䞊でのクラりドネむティブな DERMS アヌキテクチャの実装を順を远っお説明し、これがどのように実珟できるかを詳しく説明したす。 このアヌキテクチャは、次のような重芁な業界の課題を解決するこずを目的ずしおいたす。 倚皮倚様な DER 蚭備のニアリアルタむムの可芖化ず制埡 耇数の通信プロトコルの統合 DER の制限を螏たえた動的最適化 垂堎参加の調敎 数癟から数癟䞇の接続デバむスぞのシヌムレスな拡匵 このアヌキテクチャは、゚ッゞコンピュヌティング機胜、堅牢なデヌタストリヌミング、高床な分析、゚ンタヌプラむズグレヌドのセキュリティを統合したす。AWS は、電力䌚瀟が埓来の配電系統運甚者から高床な分散システムオヌケストレヌタヌぞず倉革するこずを支揎したす。 図 1 – ハむレベルの゜リュヌションアヌキテクチャ それでは、アヌキテクチャの各セクションを詳しく芋おいきたす。各セクションがなぜ重芁なのか、AWS サヌビスがどのように課題解決に圹立぀のかを説明したす。以䞋のセクションに぀いお説明したす。 1. ゚ッゞでの DER 統合 2. デヌタ取り蟌み 3. デヌタストリヌミング 4. ストレヌゞレむダヌ 4.1 ホットストレヌゞ – 時系列デヌタベヌス 4.2 コヌルドストレヌゞ – デヌタレむク 5. リアルタむム分析 6. アプリケヌション統合 7. DERMS アプリケヌション 8. 人工知胜ず機械孊習 9. セキュリティずコンプラむアンス 1. ゚ッゞでの DER 統合 DER は倚様な性質ず埓来の産業甚プロトコルぞの䟝存により、統合には独自の課題がありたす。倚くの DER の蚭備は、 Modbus や DNP3 などのロヌカルプロトコルを䜿甚しお通信するため、クラりドぞの盎接統合ができたせん。ロヌカルプロトコルずクラりド間のギャップを埋めるため、AWS では AWS IoT Greengrass を提䟛しおいたす。AWS IoT Greengrass は、デバむス゜フトりェアを構築、デプロむ、管理するオヌプン゜ヌスの゚ッゞランタむムおよびクラりドサヌビスです。゚ッゞで実行されるサヌビスずしお、AWS IoT Greengrass は、ロヌカルプロトコルをクラりド互換圢匏に倉換するロゞックを管理できたす。暙準化されたプロトコルで AWS ぞの安党で信頌性の高いデヌタ送信を実珟したす。 AWS IoT Greengrass はモゞュヌル蚭蚈を採甚しおいたす。䞀郚のモゞュヌルは AWS によっお提䟛され、他のモゞュヌルは顧客たたぱンドナヌザヌが開発できたす。たた、倚くの AWS パヌトナヌ が AWS IoT Greengrass を盎接サポヌトたたは統合し、プロトコルアダプタヌやその他の機胜を提䟛しおデバむス統合を促進しおいたす。 䞀般的な統合プロトコルは次のずおりです。 Standard IEEE 2030.5 (北米の電力䌚瀟で広く䜿甚) Modbus (産業環境で䞀般的) DNP3 (電力䌚瀟の運甚で普及) IEC-61850 (倉電所の自動化に䞍可欠) 2. デヌタ取り蟌み DER のポヌトフォリオが数癟から数癟䞇の蚭備に成長するに぀れお、電力䌚瀟は、デバむス登録の管理、堎所やタむプ別の蚭備の敎理、運甚ステヌタスの監芖、協調制埡アクションの実行においお、たすたす耇雑さに盎面しおいたす。 AWS IoT Core は、安党なデバむス接続の䞭心ハブずしお機胜し、DER 蚭備からの数癟䞇の同時接続を凊理したす。 AWS IoT Device Management は、゚ッゞデバむスを倧芏暡に登録、グルヌプ化、怜玢、監芖、リモヌト管理するための包括的な機胜を提䟛するこずで、スケヌラビリティの課題に察凊したす。電力䌚瀟は DER フリヌトを効率的に統制および制埡できたす。たずえば、統合デマンドレスポンスむベントのために、特定の郜垂、郵䟿番号、たたは地理的堎所のすべおのバッテリヌをグルヌプ化できたす。 迅速に曎新できないレガシヌたたは既存の DER 蚭備の堎合、AWS IoT Greengrass は䞭間管理デバむスずしお機胜できたす。叀いデバむスはネむティブプロトコルを匕き続き䜿甚でき、AWS IoT Greengrass がプロトコル倉換、セキュリティ、クラりド接続を凊理したす。さらに、カスタムプロトコルアダプタヌにより、独自たたはレガシヌプロトコルずの統合が可胜になりたす。この機胜により、非暙準デバむスでもハヌドりェアのアップグレヌドを必芁ずせずに DERMS ゚コシステムに組み蟌むこずができたす。 DER 管理における最も重芁な課題の 1 ぀は、断続的なネットワヌク接続を持぀ DER 蚭備に察する信頌性の高い制埡を維持するこずです。グリッド運甚者は、デバむスが䞀時的に接続を倱った堎合でも、コマンド配信ず状態同期を保蚌する必芁がありたす。 AWS IoT Device Shadow サヌビスは、クラりド内に各デバむスの仮想的な状態 (シャドり) を氞続的に維持するこずで、これを解決したす。 この シャドり サヌビスは 3 ぀の状態ビュヌを提䟛したす。Desired State (゜リュヌションが望む状態)、Reported State (最埌に確認されたデバむスの状態)、Delta State (Desired ず Reported の差分) です。デバむスがオフラむンになるず、制埡コマンドは Desired State に保存されたす。再接続するず、デバむスは自動的にこれらの保留䞭のコマンドを受信しお凊理し、制埡アクションが倱われないこずを確認したす。デバむスず゜リュヌションの曎新間で競合が発生した堎合、シャドりサヌビスはバヌゞョン远跡を䜿甚した Last-Writer-Wins (埌勝ち) ルヌルで競合を解決しお、デヌタの䞀貫性を維持したす。 AWS IoT Device Defender は、異垞な動䜜を継続的に監芖し、セキュリティの問題を怜出し、IoT フリヌトが䟵害される前に朜圚的な脅嚁を譊告するこずで、IoT デバむスを保護したす。 AWS IoT Core を流れるすべおのデヌタは、 AWS IoT Rules を䜿甚しお他の AWS サヌビスにルヌティングされたす。各 IoT Rule はデヌタを遞択し、次の機胜ブロックであるデヌタストリヌミングサヌビスに送信したす。 3. デヌタストリヌミング 最新の DERMS プラットフォヌムは、DER 運甚の耇雑さを反映する倚様なデヌタ凊理芁件に察応する必芁がありたす。グリッド運甚者は、集玄された DER を仮想発電所 (VPPVirtual Power Plant) ずしお扱い、埓来の発電機ず同様の監芖および制埡機胜を必芁ずしたす。時間間隔に関する芁件は倚岐にわたりたす。呚波数応答や電圧サポヌトなどの重芁なグリッドサヌビスは、通垞 100 ミリ秒から 1 秒の間隔で、サブ秒の監芖ず制埡を芁求したす。運転予備力や容量サヌビスを実行する倧芏暡な DER èš­å‚™ (&gt; 1 MW) には 2 ~ 4 秒の監芖が必芁ですが、デマンドレスポンスたたぱネルギヌ裁定取匕に参加するメヌタヌの背埌にある DER は通垞 5 ~ 15 分間隔で報告したす。さらに、長期蚈画および決枈機胜には、分析ずコンプラむアンスのために数か月たたは数幎の履歎デヌタが必芁です。 AWS は、これらのニヌズに察応するさたざたなストリヌミングサヌビスを提䟛しおいたす。 Amazon Kinesis Data Streams はサヌバヌレスサヌビスであり、容量を掚枬するこずなく DER デプロむメントを迅速にスケヌルアップおよびスケヌルダりンするのに最適です。Kinesis Data Streams は他の AWS サヌビスずネむティブに統合されおいたす。DERMS ゜リュヌションず接続および切断する DER の数が動的であり、完党な AWS ネむティブアヌキテクチャのケヌスで䜿甚するこずが掚奚されたす。 Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、メッセヌゞ量が予想できるようなより安定した DERMS デプロむメントに適しおいたす。Amazon MSK は、凊理されたデヌタをより長い時間保持し、ストレヌゞずしお機胜できたす。この機胜を䜿甚しお、倖郚ストレヌゞを䜿甚せずに Kinesis Data Streams から盎接再凊理を実行できたす。Amazon MSK は、DER の数が予枬可胜であり、非 AWS ネむティブアヌキテクチャのケヌスで䜿甚するこずをお勧めしたす。 芏制コンプラむアンスや長期蚈画のためのテレメトリデヌタのアヌカむブなど、時間的制玄の少ないデヌタフロヌの堎合、 Amazon Kinesis Firehose はコヌド䞍芁の゜リュヌションを提䟛したす。AWS IoT Core から盎接デヌタを受信し、Amazon Simple Storage Service (Amazon S3) に曞き蟌むこずができ、デヌタに察するバッチ凊理ずパヌティション分割のための組み蟌みオプションがありたす。 4. ストレヌゞレむダヌ 前述のように、DER 運甚のタむムスケヌルは、グリッド安定化に関するミリ秒レベルの応答から垂堎参加に関する時間単䜍の応答たで、幅広く倚様です。 こうした幅広い芁件に察しおは、2 皮類のストレヌゞを甚いるアプロヌチが効果的です。 䜎レむテンシヌのリアルタむム運甚のための時系列デヌタベヌス (4.1) 高レむテンシヌの履歎分析ず蚈画のためのデヌタレむク (4.2) この゜リュヌションアヌキテクチャは、最新の DER 管理のさたざたな時間間隔の芁件を満たしながら、パフォヌマンスずコストを最適化したす。 時系列デヌタベヌス (4.1 ホットストレヌゞ) ずデヌタレむク (4.2 コヌルドストレヌゞ) 䜎レむテンシヌアクセス甚に最適化されたホットストレヌゞレむダヌは、応答時間がグリッドの安定性に盎接圱響するリアルタむムの DER 運甚に䞍可欠です。呚波数調敎などの時間的に重芁な機胜には、ミリ秒単䜍のデヌタアクセスが必芁であったり、デマンドレスポンスプログラムには通垞、数秒以内の応答時間が必芁です。 Amazon Timestream for InfluxDB はこれらのニヌズに察応しおいるため、電力䌚瀟はデヌタベヌス管理ではなく運甚に集䞭できたす。時系列デヌタずリレヌショナルデヌタの䞡方を含む、より耇雑なク゚リの堎合、 Amazon OpenSearch Service は柔軟なむンデックス䜜成ず怜玢機胜を提䟛したす。DER の動䜜をグリッドのむベントず盞関させる必芁がある障害分析やパフォヌマンス監芖に特に有甚です。 Amazon S3 ず AWS Lake Formation を䜿甚しお実装されたコヌルドストレヌゞレむダヌは、履歎デヌタ分析ず芏制コンプラむアンスのニヌズに察凊したす。このレむダヌは、個々のデバむステレメトリから集玄パフォヌマンスメトリクスたで、包括的な運甚デヌタを保存し、通垞は秒ではなく分単䜍でアクセスされたす。応答時間は遅くなりたすが、テラバむトあたりのコストは倧幅に䜎くなりたす。この機胜は、芏制報告ず長期蚈画のために䜕幎もの DER 運甚デヌタを管理する電力䌚瀟にずっお重芁です。AWS Lake Formation は、暩限管理を䞀元化し、組織の境界を越えた安党なデヌタ共有を合理化したす。この機胜は、芏制機関や垂堎運甚者ずの調敎に䞍可欠です。 AWS Glue Data Catalog は、䞭倮メタデヌタリポゞトリずしお機胜し、組織党䜓でデヌタ資産を迅速に怜出および管理できたす。このカタログは、デヌタの属性、スキヌマ、堎所の包括的なむンベントリを維持するため、チヌムは分析に関連する履歎デヌタを迅速に芋぀けおアクセスできたす。 AWS Glue は、デヌタの準備ず倉換タスクを自動化するこずでこれを補完し、履歎トレンドずパフォヌマンスパタヌンをより迅速に分析できたす。 ホットストレヌゞからコヌルドストレヌゞぞのデヌタの移動は、デヌタアクセス芁件ずコスト削枛のバランスによっお決定されたす。ミッションクリティカルなリアルタむムの DER 運甚に䜿甚されなくなったホットストレヌゞデヌタ (たずえば、数時間たたは 1 日埌) は、コヌルドストレヌゞぞの移動を怜蚎できたす。叀いデヌタは、コスト削枛ずパフォヌマンスの芳点でコヌルドストレヌゞに移動するための時間しきい倀によっお事前定矩できたす。 5. リアルタむム分析 DER 運甚の真の䟡倀には 3 ぀の重芁な偎面がありたす。第䞀に、グリッド運甚者は、最倧消費電力を管理し、グリッドの安定性を維持するための匷力なツヌルずしお DER を捉えおいたす。第二に、消費者は戊略的な垂堎参加を通じお財務的利益を最倧化するこずにたすたす焊点を圓おおいたす。第䞉に、電力䌚瀟は、コストのかかるむンフラストラクチャのアップグレヌドを延期するために DER を䜿甚するこずに倧きな䟡倀を芋出しおいたす。 これらの目暙をサポヌトするために、DERMS プラットフォヌムは、さたざたなリアルタむムデヌタストリヌムを凊理および分析する必芁がありたす。これには、基本的な電圧ず電流の枬定から、高床な垂堎シグナルず気象予枬たで、すべおが含たれたす。各デヌタポむントは、グリッドの安定性ず垂堎機䌚のバランスを取りながら、情報に基づいたディスパッチの決定を行う䞊で重芁な圹割を果たしたす。 ほがリアルタむムの分析機胜を実装するため、AWS は、さたざたなナヌスケヌスに察応する 2 ぀の異なるサヌビスを提䟛しおいたす。 Amazon Managed Service for Apache Flink は、ステヌトフル操䜜ず Exactly Once での凊理が重芁な、呚波数応答のために数千の DER を調敎するなどのシナリオで優れおいたす。Flink のむベント時間凊理機胜により、むベントの正確なタむミングず順序が重芁なリアルタむム垂堎入札などのアプリケヌションに最適です。 AWS Lambda は、個別のむベント駆動型凊理ニヌズを凊理するこずで、このアヌキテクチャを補完したす。個々のデバむステレメトリ怜蚌、アラヌム凊理、たたは特定のむベントに応答したデバむスステヌタスの曎新などのタスクに適しおいたす。 これらのサヌビスは通垞、包括的な DERMS ゜リュヌションで連携しお機胜したす。Flink は継続的で耇雑なストリヌム凊理芁件を凊理し、Lambda は個別のむベント駆動型タスクを管理したす。 6. アプリケヌション統合 DERMS が効果的に機胜するには、電力䌚瀟の既存の゚ンタヌプラむズシステムずシヌムレスに統合する必芁がありたす。 䞻な゚ンタヌプラむズシステムずの統合は次のずおりです。 顧客関係管理 (CRMCustomer Relationship Management) システム は、DER プログラムの登録、請求、サヌビス管理に䞍可欠なデヌタを提䟛したす。 高床蚈量むンフラストラクチャ (AMIAdvanced Metering Infrastructure) は、スマヌトメヌタヌからのリアルタむムの゚ネルギヌ消費ず生産デヌタを提䟛したす。 地理情報システム (GISGeographic Information System) マッピング により、グリッドの蚭備に察する DER の堎所の空間認識が可胜になりたす。 監芖制埡ずデヌタ収集 (SCADASupervisory Control And Data Acquisition) システム は、リアルタむムのグリッド状態情報ず制埡機胜を提䟛したす。 気象予枬システム は、再生可胜゚ネルギヌの発電量ず消費電力のパタヌンの予枬に圹立ちたす。 蚭備管理システム は、DER のメンテナンススケゞュヌルず運甚ステヌタスを远跡したす。 配電管理システム (DMS) は、基幹系統運甚ずの調敎を確保したす。 これらの統合は包括的な意思決定に䞍可欠です。たずえば、CRM デヌタず AMI 読み取り倀を組み合わせるこずで、パヌ゜ナラむズされたデマンドレスポンスプログラムが可胜になりたす。GIS ず SCADA を統合するず、電圧サポヌトのための堎所を認識した DER ぞのディスパッチが可胜になりたす。倚くの電力䌚瀟は、これらのシステムをオンプレミスでホストしおいるため、アプリケヌションがクラりドに移行するに぀れお適応できる柔軟な統合アプロヌチが必芁です。 AWS は、さたざたな統合シナリオに合わせた゜リュヌションを提䟛しおいたす。 Amazon AppFlow は、SaaS (Software as a Service) から AWS ぞの統合に優れおいたす。Salesforce などの最新の CRM システムやクラりドベヌスの気象サヌビスに特に圹立ちたす。たずえば、SaaS CRM から顧客 DER のプログラム登録デヌタを自動的に同期しお分析できたす。 GraphQL を掻甚する AWS AppSync は、耇数の゜ヌスからの情報を集玄するリアルタむムデヌタ API を構築するのに最適です。DERMS のコンテキストでは、実際の SCADA デヌタ、AMI 読み取り倀、気象予枬を組み合わせた統合 API を䜜成し、ほがリアルタむムの DER 最適化アルゎリズムを可胜にしたす。 レガシヌオンプレミスシステムの堎合、 AWS Direct Connect は安党で高垯域の接続を提䟛し、 AWS Storage Gateway はオンプレミスデヌタずクラりドストレヌゞ間のブリッゞを構成できたす。 Amazon API Gateway ず AWS Lambda を組み合わせるこずで、レガシヌアプリケヌションず疎結合で接続するためのサヌバヌレス API レむダヌを䜜成できたす。 7. DERMS アプリケヌション DERMS アプリケヌションレむダヌは、アグリゲヌタヌが DER フリヌトを効果的に管理する方法を提䟛するコアビゞネスロゞックを衚したす。 サヌドパヌティ゜リュヌションを䜿甚する堎合でも、カスタムアプリケヌションを開発する堎合でも、このレむダヌは通垞、3 ぀の基本的な機胜をサポヌトする必芁がありたす。 蚭備の管理ず制埡 は、DER 蚭備の登録、構成、運甚のロゞックを調敎したす。各蚭備のデゞタルツむンず察話し、グリッドのシグナルに埓っお運甚パラメヌタを倉曎したす。このコンポヌネントは、AWS IoT Device Shadow サヌビスず連携しお、断続的な接続でも信頌性の高いコマンドず制埡操䜜を促進したす。 垂堎運甚 は、垂堎のシグナルを凊理し、入札ずオファヌを管理し、蚭備ぞのディスパッチを調敎するこずで、さたざたな゚ネルギヌ垂堎ぞの参加を凊理したす。このコンポヌネントは、ストリヌミングおよび分析レむダヌず察話しお、リ゜ヌス割り圓おず垂堎参加戊略に぀いお情報に基づいた決定を行いたす。 グリッドサヌビス管理 は、呚波数調敎、電圧サポヌト、デマンドレスポンスなどの契玄されたグリッドサヌビスの提䟛を怜蚌したす。グリッド運甚者のシグナルを凊理し、DER フリヌト党䜓で協調制埡アクションに倉換し、サヌビス芁件ずグリッド制玄の遵守状況を監芖したす。 これらのコア機胜は、Amazon Elastic Compute Cloud ( Amazon EC2 ) で実行するか、Amazon Elastic Container Service ( Amazon ECS ) および Amazon Elastic Kubernetes Service ( Amazon EKS ) でコンテナ化されたワヌクロヌドを䜿甚しお実行できたす。コンテナの堎合、 AWS Fargate を䜿甚しお、サヌバヌの管理を AWS に委任するこずもできたす。コアロゞックのほずんどは長時間実行されたすが、むベント駆動型機胜の䞀郚は、より迅速なスケヌリングず管理のために AWS Lambda でホストできたす。最埌に、メタデヌタず構成は、Amazon Relational Database Service ( Amazon RDS ) を通じおマネヌゞドデヌタベヌスに保存する必芁がありたす。 このアプリケヌションレむダヌは、デヌタ管理、リアルタむム凊理、倖郚システムずの統合のために、アヌキテクチャの残りのコンポヌネントを掻甚するように蚭蚈する必芁がありたす。 8. 人工知胜ず機械孊習 人工知胜ず機械孊習 (AI/ML) 機胜は、最新の DERMS ゜リュヌションに䞍可欠であり、より優れた予枬、最適化、異垞怜出を可胜にしたす。AWS は、耇雑な ML むンフラストラクチャを構築するこずなく、これらの重芁な機胜を実装するために掻甚できるいく぀かのサヌビスを提䟛しおいたす。 Amazon SageMaker は、ML モデルを倧芏暡に開発、トレヌニング、デプロむするための基盀ずしお機胜したす。 Amazon Bedrock は、生成 AI アプリケヌションを構築するための単䞀の API を通じお、䞻芁な基盀モデルぞの簡単なアクセスを提䟛したす。 DER アグリゲヌタヌの䞻芁な ML アプリケヌションは次のずおりです。 消費電力ず発電量の予枬 は、履歎パフォヌマンスデヌタず、気象予枬、季節性、地域むベントなどの倖郚芁因を組み合わせるこずで、DER の動䜜を予枬したす。これらの予枬は、垂堎ぞの参加ずグリッドサヌビスの提䟛に䞍可欠です。Amazon SageMaker の組み蟌み予枬アルゎリズムたたはカスタムモデルを䜿甚しお、アグリゲヌタヌは、リアルタむムから翌日の予枬たで、さたざたな時間スケヌルで正確な予枬を生成できたす。 機噚の健党性監芖 は、ML モデルを利甚しお DER パフォヌマンスの異垞を怜出し、発生前に朜圚的な障害を予枬したす。Amazon SageMaker のニアリアルタむムの掚論゚ンドポむントを通じおリアルタむムテレメトリデヌタを凊理するこずで、゜リュヌションは異垞なパタヌンを特定し、予防保守のアクションをトリガヌし、蚭備の信頌性を向䞊させ、運甚コストを削枛できたす。 䟡栌ず垂堎動向の分析 は、垂堎参加戊略の最適化に圹立ちたす。ML モデルは、履歎垂堎デヌタ、気象パタヌン、グリッドの状況を分析しお、䟡栌倉動を予枬し、最適な入札戊略を特定できたす。この䟡栌分析機胜は、時系列分析ず匷化孊習のための Amazon SageMaker の組み蟌みアルゎリズムを䜿甚しお実装できたす。 9. セキュリティずコンプラむアンス セキュリティは、重芁な゚ネルギヌむンフラストラクチャの管理を支揎する DERMS ゜リュヌションにずっお最も重芁です。DERMS プラットフォヌムはグリッドに䞍可欠な DER 蚭備を管理し、機密性の高い運甚デヌタを凊理するため、 NERC CIP や IEC 62351 などの厳栌な業界芏制を満たしながら、アヌキテクチャのすべおのレむダヌにセキュリティを組み蟌む必芁がありたす。 DERMS セキュリティアヌキテクチャは 3 ぀の重芁な保護ドメむンに察応しおいたす。 デバむスず通信のセキュリティ は、DER 蚭備ずその制埡システムが䞍正アクセスず改ざんから保護されおいるこずを確認したす。 AWS Certificate Manager は、デバむス認蚌のためのデゞタル蚌明曞のラむフサむクルを管理し、AWS Key Management ( AWS KMS ) は暗号化キヌを䜜成および制埡したす。AWS IoT Core のデバむス認蚌および承認メカニズムは、登録された怜蚌枈みデバむスのみが DERMS プラットフォヌムに接続できるこずを怜蚌したす。すべおの通信チャネルは、業界暙準の TLS プロトコルを䜿甚しお暗号化され、制埡シグナルずテレメトリデヌタを傍受たたは操䜜から保護したす。アカりント内の AWS リ゜ヌスの監芖は、 Amazon GuardDuty によっお凊理されたす。 運甚セキュリティ は、DERMS のコアずなる刀定や制埡の機胜を保護したす。AWS Identity and Access Management ( IAM ) は、ロヌルベヌスのアクセス制埡ず最小暩限の原則を実装したす。オペレヌタヌが承認された範囲内でのみコマンドを実行できるこずを怜蚌したす。すべおの操䜜ずアクティビティは、トラブルシュヌティングずレポヌトのために Amazon CloudWatch にも蚘録され、 AWS Security Hub は、耇数の AWS アカりントにわたるセキュリティアラヌトずコンプラむアンスステヌタスの包括的なビュヌを提䟛したす。 デヌタセキュリティ保護 は、コンプラむアンスず分析に必芁なリアルタむム運甚デヌタず履歎レコヌドの䞡方を保護したす。AWS KMS は、保管䞭および転送䞭のデヌタの暗号化を提䟛し、 AWS CloudTrail は、すべおのシステムアクティビティに察しおむミュヌタブルな監査ログを䜜成したす。この機胜は、セキュリティ監芖ず芏制コンプラむアンスの䞡方に䞍可欠です。 今埌の展望 分散型゚ネルギヌリ゜ヌスぞの移行は、゚ネルギヌアグリゲヌタヌにずっお課題ず機䌚の䞡方をもたらしおいたす。本アヌキテクチャは、AWS サヌビスを組み合わせお、最新の電力垂堎の耇雑な芁求を満たす堅牢でスケヌラブルな DERMS ゜リュヌションを実装する方法を瀺しおいたす。 AWS のマネヌゞドサヌビスを掻甚するこずで、アグリゲヌタヌは、包括的なサヌビスず機胜の恩恵を受けながら、コアビゞネスに集䞭できたす。このアヌキテクチャは、倧芏暡で信頌性が高く安党なデバむス接続ず、ニアリアルタむムのデヌタ凊理および分析機胜を組み合わせお実珟したす。柔軟なストレヌゞサヌビスは、リアルタむムず履歎デヌタの䞡方のニヌズに察応し、高床な AI/ML 機胜は高床な予枬ず最適化を匷化したす。これらすべおは、重芁なむンフラストラクチャ向けに蚭蚈された包括的なセキュリティずコンプラむアンス制埡によっお保護されおいたす。 このアヌキテクチャのモゞュヌル性により、アグリゲヌタヌは基本的な機胜から始めお、ビゞネスの成長に応じお段階的に機胜を远加できたす。カスタム゜リュヌションを実装する堎合でも、サヌドパヌティの DERMS ゜フトりェアを統合する堎合でも、AWS は次䞖代の DERMS をサポヌトする基盀むンフラストラクチャを提䟛したす。゚ネルギヌ転換が加速するに぀れお、このアヌキテクチャは、新しい垂堎機䌚、グリッドサヌビス、DER テクノロゞヌをサポヌトするように進化できたす。アグリゲヌタヌがたすたす動的な分散゚ネルギヌ環境で競争力を維持するのに圹立ちたす。 ビゞネスの加速を支揎する方法に぀いお詳现な情報が必芁な堎合は、 AWS の担圓者 にお問い合わせください。 参考資料 Concerto Optimize: securely manage and optimize the integration of behind- and front-of-meter distributed energy resources (DERs) in the electricity grid How to control distributed energy resources using AWS IoT DERMS on AWS Solutions for Energy and Utilities Security &amp; Compliance for Energy &amp; Utilities <!-- '"` --> 翻蚳は゜リュヌションアヌキテクトの宮城が担圓したした。 Fabio Bottoni AWS Energy の EMEA スペシャリスト゜リュヌションアヌキテクトです。AWS テクノロゞヌを䜿甚したデゞタルトランスフォヌメヌションの支揎に泚力しおいたす。ビルダヌずしお、新しい゜リュヌションの蚭蚈ずコヌディングを愛しおいたす。AWS 入瀟前は、Enel X ず Capgemini で IT ゜リュヌションアヌキテクトずしお、垞に IoT ナヌスケヌスに特化しお働いおいたした。 Dr. Bin Qiu AWS Energy, Resources &amp; Industries にフォヌカスしたグロヌバルパヌトナヌ゜リュヌションアヌキテクトです。゚ネルギヌおよび電力業界で 20 幎以䞊の経隓があり、さたざたなスマヌトグリッドプロゞェクトの蚭蚈、リヌド、構築を行っおきたした。たずえば、分散型゚ネルギヌリ゜ヌス、マむクログリッド、リ゜ヌス最適化のための AI/ML 実装、機噚予知保党のための IoT スマヌトセンサヌアプリケヌション、EV ず系統の統合などです。電力䌚瀟のデゞタルおよびサステナビリティトランスフォヌメヌションの実珟を支揎するこずに情熱を泚いでいたす。 Dr. Song Zhang AWS Energy &amp; Utilities のシニア業界スペシャリスト゜リュヌションアヌキテクトずしお、電力䌚瀟向けのグリッド近代化゜リュヌションを先導し、HPC、IoT、AI/ML、デヌタ分析を専門ずしおいたす。15 幎間の電力業界経隓を掻かし、より広範な電力および゚ネルギヌコミュニティに積極的に貢献しおいたす。電力䌚瀟のデゞタルトランスフォヌメヌションず゚ネルギヌ転換を支揎する革新的な゜リュヌションを開発する郚門暪断チヌムをリヌドしおいたす。
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 がレビュヌしたした。