TECH PLAY

AWS

AWS の技術ブログ

å…š3023ä»¶

2026 幎 3 月 3 日、アマゟン りェブ サヌビス ゞャパン合同䌚瀟以䞋、AWS ゞャパンは、「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」のキックオフむベントを東京の AWS 目黒オフィスにお開催したした。本プログラムは 2026 幎 1 月 27 日に発衚 し、応募受付を開始したもので、倚数の応募の䞭から厳正な遞考を経お採択された皆さたをお迎えし、玄 6 ヶ月間にわたる開発支揎の幕開けずなりたした。 フィゞカル AI の可胜性 フィゞカル AI ずは、物理䞖界で動䜜する AI の総称です。ロボットや自動運転車、ドロヌンなど、珟実䞖界のセンサヌ情報を理解し、自埋的に刀断・行動する AI 技術を指したす。近幎、倧芏暡蚀語モデルLLMの急速な進化を背景に、蚀語だけでなく芖芚情報ず行動を統合的に扱う Vision-Language-ActionVLAモデルをはじめずしたロボット基盀モデルの研究開発が䞖界的に加速しおいたす。 日本は補造業やロボティクスにおいお䞖界をリヌドしおきた歎史がありたす。この匷みず、生成 AI の最新技術を掛け合わせるこずで、日本発のフィゞカル AI むノベヌションが生たれる倧きな可胜性があるず私たちは考えおいたす。 AWS ゞャパンは 2023 幎の LLM 開発支揎プログラムを皮切りに、生成 AI 実甚化掚進プログラムや経枈産業省 GENIAC ぞ参画するお客様の支揎など、これたでに 300 を超える䌁業・団䜓の生成 AI 開発を支揎しおきたした。本プログラムは、その知芋ず実瞟をフィゞカル AI 領域に展開するものです。 プログラム抂芁 本プログラムは、AWS 䞊でロボット基盀モデル等を開発する日本の䌁業・団䜓を包括的に支揎するもので、デヌタ収集・前凊理からモデルトレヌニング、シミュレヌション、実環境ぞのデプロむたでの䞀連のパむプラむン構築をカバヌしたす。 技術支揎 : ゜リュヌションアヌキテクトSAによるアヌキテクチャガむダンス、Prototyping & Cloud EngineeringPACEチヌムによるサンプルコヌド提䟛、生成 AI むノベヌションセンタヌGenAIICによるロボット基盀モデル開発支揎 コスト最適化支揎 : AWS クレゞットの提䟛蚈算リ゜ヌスおよびデヌタ保管等の利甚を支揎 コミュニティ圢成 : フィゞカル AI コミュニティ Powered by AWS ずしお、技術勉匷䌚・ワヌクショップの開催、゚ンゞニア間の亀流促進、業界暪断の知芋共有 GTM 支揎 : モデル開発䌁業ず補造業などロボット導入䌁業ずのマッチング機䌚の提䟛、実蚌環境の提䟛支揎、スタヌトアップ間の技術連携促進 支揎期間は 2026 幎 3 月から玄 6 ヶ月間で、成果発衚䌚を予定しおいたす。プログラムの詳现は 発衚時のブログ蚘事 をご芧ください。 キックオフむベントの様子 キックオフむベントは、採択䌁業の皆さたず AWS の支揎チヌムが䞀堂に䌚する初めおの機䌚ずなりたした。 ご挚拶 むベントの冒頭では、アマゟン りェブ サヌビス ゞャパン合同䌚瀟 代衚執行圹員瀟長の癜幡 晶圊よりプログラムに察するビゞョンに぀いおお話しさせおいただきたした。 Amazon Robotics の取り組みに぀いお 続いお、アマゟンゞャパン合同䌚瀟 オペレヌション技術統括本郚 技術開発本郚長 ダむレクタヌの内田 昌宏より、Amazon Robotics の取り組みに぀いお講挔いたしたした。 Amazon のフルフィルメントセンタヌFCでは、商品の入荷から出荷たでの䞀連のオペレヌションにおいお、AI ずロボティクスの融合が進んでいたす。講挔では、自動レシヌブ、AI による圚庫配眮最適化、Amazon Robotics の自動倉庫システム、そしお觊芚センサヌをも぀棚入れ・棚出しロボット Vulcan など、実際の物流珟堎で皌働するフィゞカル AI の事䟋をご玹介したした。 特に、Vision ず深局孊習で䜜業者の手の動きをトラッキングしおロケヌションデヌタを自動確定する Intent Detection SystemIDSや、ML ず Vision を掻甚しお圚庫の過䞍足を自動怜出する Visual Bin InspectionVBIずいった、珟堎の課題を AI で解決する具䜓的な取り組みをお䌝えしたした。さらに、ML アルゎリズムによる最小梱包の自動指定や、生成 AI を掻甚したオペレヌションマネゞメントなど、AI が物流オペレヌション党䜓に浞透しおいる様子を共有いたしたした。 癜幡 晶圊 内田 昌宏 Amazon は䞖界各囜の物流拠点で 100 䞇台を超えるロボットを運甚しおおり、こうした倧芏暡な実践から埗られた知芋を、本プログラムを通じお日本のフィゞカル AI 開発者の皆さたず共有しおいきたす。 プログラム支揎内容の玹介 続いお、プログラムの具䜓的な支揎内容、支揎チヌムのメンバヌ玹介、今埌の進め方に぀いおご説明したした。 本プログラムの技術支揎の柱のひず぀ずしお、 Physical AI Scaffolding KitPASK が玹介されたした。PASK は、PACE チヌムが開発するフィゞカル AI 開発者向けのツヌルキットで、開発ラむフサむクル党䜓の課題を䜓系的に解決するこずを目指しおいたす。 フィゞカル AI の開発は、デヌタ収集・前凊理からモデル孊習、シミュレヌション、実機デプロむたで、倚くのステップにたたがりたす。各ステップで必芁ずなるむンフラ構築やパむプラむン蚭蚈に倚倧な時間を費やし、本来泚力すべきモデル開発やアルゎリズム改善に十分なリ゜ヌスを割けないずいう課題を、倚くの開発者が抱えおいたす。 PASK の第䞀匟ずしお、Amazon SageMaker HyperPod 䞊で VLA のトレヌニングを実行する環境のサンプルが 3 月埌半に提䟛予定です。Physical Intelligence の openpiπ0や NVIDIA Isaac GR00T のファむンチュヌニングサンプルも含たれる予定で、プログラム参加䌁業ぞのヒアリングを通じお継続的にフィヌドバックを取り蟌み、PASK を進化させおいきたす。 たた、PACE チヌムによるプロトタむピング支揎も提䟛されたす。参加䌁業が実珟したいフィゞカル AI システムのプロトタむプを、AWS 䞊に共同で開発するプログラムで、トレヌニング可胜な暙準化されたデヌタパむプラむンの構築や、スケヌラブルなトレヌニング環境の敎備、Sim2Real 等の技術的ブロッカヌの解決を支揎したす。 さらに、 GenAIIC は、䞖界䞭の生成 AI ゚キスパヌトの知芋に基づくベストプラクティスを共有し、VLA 開発の支揎実瞟を掻かしお゜リュヌションの構築・展開を支揎したす。 採択䌁業によるピッチ キックオフのメむンセッションずしお、採択䌁業の皆さたによるピッチが行われたした。䌚堎に参加いただいた䌁業を䞭心に、それぞれが取り組むフィゞカル AI の課題ずビゞョンを共有したした。 ロボットメヌカヌ、AI スタヌトアップ、補造業、倧孊研究機関など、倚様なバックグラりンドを持぀䌁業・団䜓が集たり、産業甚ロボットの知胜化、自埋移動ロボット、マニピュレヌション、ヒュヌマノむドなど、幅広い領域のプロゞェクトが玹介されたした。参加者同士が互いの取り組みを知り、刺激を受け合う貎重な機䌚ずなりたした。 なぜコミュニティが重芁なのか – 日本のフィゞカル AI ゚コシステムの構築に向けお キックオフむベントの埌半では懇芪䌚が開催され、採択䌁業の皆さたず AWS チヌムが掻発に亀流したした。この「぀ながり」こそが、本プログラムが最も倧切にしおいる芁玠のひず぀です。 日本のフィゞカル AI 業界の珟状ず課題 フィゞカル AI の開発には、゜フトりェアだけの AI 開発ずは異なる固有の課題がありたす。 デヌタ収集の困難さ : ロボット基盀モデルの孊習には、珟実䞖界での倧量の行動デヌタが必芁です。しかし、実機でのデヌタ収集はコストず時間がかかり、䞀瀟単独で倚様なデヌタを網矅的に集めるこずには限界がありたす。シミュレヌション環境の構築や合成デヌタの生成ずいった技術的アプロヌチが重芁性を増しおおり、本プログラムでもこうした取り組みを支揎しおいきたす。 ハヌドりェアず゜フトりェアの融合 : フィゞカル AI は、AI モデルの開発だけでなく、センサヌ、アクチュ゚ヌタヌ、制埡系、通信ずいったハヌドりェア領域ずの密接な連携が䞍可欠です。日本にはロボティクスや補造業で培われた優れたハヌドりェア技術がありたすが、最新の生成 AI 技術ずの統合には、異なる専門領域を぀なぐ人材やコミュニティが必芁です。 研究ず瀟䌚実装のギャップ : 倧孊や研究機関で生たれた先端技術を、実際の産業珟堎で䜿えるレベルたで匕き䞊げるには、゚ンゞニアリング、ビゞネス、芏制察応など倚面的な取り組みが必芁です。研究者ず事業者が盎接察話し、課題を共有できる堎が䞍足しおいたす。 蚈算資源ぞのアクセス : VLA モデルをはじめずするロボット基盀モデルの孊習には、倧芏暡な GPU コンピュヌティングリ゜ヌスが必芁です。特にスタヌトアップや倧孊研究宀にずっお、これらのリ゜ヌスぞのアクセスは倧きなハヌドルずなっおいたす。 コミュニティがもたらす䟡倀 こうした課題は、䞀瀟や䞀組織だけで解決できるものではありたせん。だからこそ、本プログラムでは「コミュニティ圢成」を 4 ぀の支揎柱のひず぀ずしお䜍眮づけおいたす。 知芋の共有ず盞互孊習 : 異なる領域で掻動する䌁業・研究者が集たるこずで、技術的なブレヌクスルヌや倱敗からの孊びを共有できたす。キックオフむベントのピッチセッションでも、各瀟の発衚に察しお掻発な質疑応答が行われ、分野を超えた知芋の亀換が始たっおいたす。 ゚コシステムの圢成 : ロボットメヌカヌ、AI 開発䌁業、郚品サプラむダヌ、゚ンドナヌザヌ䌁業、倧孊研究機関 — フィゞカル AI の瀟䌚実装には、これらのプレむダヌが有機的に぀ながる゚コシステムが必芁です。本プログラムは、その栞ずなるコミュニティを日本に䜜るこずを目指しおいたす。 日本の匷みを掻かしたグロヌバル競争力 : 日本のものづくりの粟床、品質管理のノりハり、そしお産業甚ロボットの豊富な運甚実瞟は、フィゞカル AI の開発においお倧きなアドバンテヌゞです。これらの匷みを生成 AI ず融合させ、日本発のフィゞカル AI ゜リュヌションを䞖界に発信しおいくためには、囜内のプレむダヌが連携し、互いの匷みを補完し合うこずが重芁です。 コミュニティむベントの開催予定 本プログラムでは、キックオフむベントに続き、支揎期間䞭に定期的なコミュニティむベントを開催しおいきたす。技術的なディヌプダむブセッション、参加䌁業同士のコラボレヌションワヌクショップ、倖郚有識者を招いた勉匷䌚など、参加者の皆さたのニヌズに応じた倚様なプログラムを蚈画しおいたす。 今埌のスケゞュヌル 時期 タむトル 内容 2026 幎 3 月 24 日火午埌 Physical AI on AWS アヌキテクチャ勉匷䌚 Physical AI 開発に必芁なアヌキテクチャの解説ず PASKpreviewのご玹介 2026 幎 4 月 3 日金16:30〜 フィゞカル AI 開発支揎プログラム Community Meetup #1 AWS Startup Loft Tokyo にお開催予定内容調敎䞭 2026 幎 4 月 9 日氎 基盀モデル開発 Deep Dive AWS を掻甚した倧芏暡モデルの孊習から掚論たでを包括的に扱う終日セッション。午前は AWS ParallelCluster での分散トレヌニングハンズオン、午埌は SageMaker HyperPod アヌキテクチャ、倧芏暡 MoE モデルの掚論最適化、AWS Trainium による基盀モデル構築、Physical AI モデル孊習のスケヌリングパスなどを解説 2026 幎 4 月䞭 ロボット勉匷䌚 AI 開発者がロボット業界に入っおいく䞊で知っおおくべき知識の共有内容・日皋調敎䞭 2026 幎 6 月 25-26 日 Demo Day䞭間報告䌚 AWS Summit Tokyo 2026幕匵メッセ 2026 幎 7 月䞋旬 最終成果報告䌚 AWS 麻垃台ヒルズ オフィス 予定 おわりに キックオフむベントを通じお、日本のフィゞカル AI の未来を担う倚様なプレむダヌが䞀堂に䌚し、熱気あふれるスタヌトを切るこずができたした。ロボティクスず生成 AI の融合は、補造業、物流、蟲業、医療、むンフラなど、あらゆる産業に倉革をもたらす可胜性を秘めおいたす。 AWS ゞャパンは、本プログラムを通じお日本のフィゞカル AI ゚コシステムの発展に貢献しおたいりたす。採択䌁業の皆さたの挑戊ず、成果発衚䌚をどうぞご期埅ください。 関連リンク: フィゞカル AI 開発支揎プログラム by AWS ゞャパン発衚ブログ 朚村 公哉Kimura, Koya アマゟン りェブ サヌビス ゞャパン合同䌚瀟 シニアスタヌトアップ゜リュヌションアヌキテクト。2023 幎よりディヌプテックスタヌトアップを担圓。支揎プログラムの立ち䞊げなどに尜力し、2025 幎よりフィゞカル AI をはじめずしたロボティクス関連領域にも支揎を拡倧。2026 幎 1 月に「フィゞカル AI 開発支揎プログラム by AWS ゞャパン」を発足。VC・政府ずのディスカッションを通じ、フィゞカル AI・ディヌプテック領域の゚コシステム圢成にも取り組んでいる。
アバタヌ
2025 幎 12 月 1 日 – 12 月 5 日にラスベガスで開催された AWS re:Invent 2025 では、メディア゚ンタヌテむンメント領域における最新の AWS 掻甚事䟋が倚数玹介されたした。たた、2025 幎 11 月 19 日 – 11 月 21 日に幕匵メッセで開催された Inter BEE 2025 では、Global AI x Cloud Pavilion にお Create、Connect、Captivate の 3 ぀のテヌマによる展瀺を、たた DX x IP Pavilion では耇数局を集玄した統合クラりドマスタヌの展瀺等を行いたした。 本振り返りセミナヌでは、䞊蚘 2 ぀のむベントのハむラむトを、メディア゚ンタヌテむンメント業界のお客様向けにご玹介したした。たた、AWS Black Belt Online Seminar 䞊でも本セミナヌの 資料を公開 しおいたす。 re:Invent & Inter BEE 2025 re:Cap メディア & ゚ンタヌテむンメント業界線 [ 資料 ] re:Invent 2025 re:Cap メディア゚ンタヌテむンメント業界線 アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 小南 英叞 re:Invent 2025 のセッションから、メディア゚ンタヌテむンメント業界に関連する事䟋を、コンテンツ制䜜、メディアサプラむチェヌン、Direct-to-Consumer、スポヌツの 4 分野に分けお玹介したした。 コンテンツ制䜜では、Amazon MGM Studios が Amazon S3 ず Amazon FSx でストレヌゞを統合し、 Amazon EC2 䞊にリモヌト線集環境を構築するこずで、数週間かかっおいたメディア転送時間を倧幅に短瞮したした。これにより凊理時間の 50% 短瞮ず 5,000 マむル離れた遠隔地からの 1 秒未満の遅延での線集を実珟したした。たた、Angry Birds を制䜜する Rovio は、 Amazon SageMaker AI  ã«ç‹¬è‡ªã‚¢ãƒŒãƒˆã‚¹ã‚¿ã‚€ãƒ«ã‚’孊習させたした。 Amazon Bedrock で党瀟員が䜿える AI ツヌルを構築し、背景制䜜時間を 80% 削枛、アヌティストが反埩䜜業から解攟され、クリ゚むティブな業務に集䞭できる環境を手に入れたした。 メディアサプラむチェヌンでは、Netflix が Amazon S3 Storage Lens ず Apache Iceberg を組み合わせるこずで、2 ゚クサバむト超のデヌタを察象にストレヌゞ増加の早期怜知ずコストの完党可芖化を実珟し、消されず残されたたたずなったアセットや蚭定ミスによる䞍芁デヌタの特定が可胜になりたした。ブンデスリヌガは Amazon Nova を掻甚するこずで、詊合終了埌数分以内のレポヌト自動配信ず動画の倚蚀語ロヌカラむズを実珟し、制䜜時間を 75〜90% 削枛しながらパヌ゜ナラむズドコンテンツを 5 倍に増加させるこずができたした。 Direct-to-Consumer では、Amazon Prime Video が Amazon Managed Service for Apache Flink でリアルタむムストリヌム凊理基盀を構築し、NASCAR 䞭継においお燃料戊略を 5 秒以内に可芖化する業界初のシステムを 8 週間で立ち䞊げたした。5 億 3,400 䞇むンプレッションずいう倧芏暡なメディア露出を獲埗しおいたす。たたマルチ゚ヌゞェントシステムず Amazon Bedrock を組み合わせるこずで、アヌトワヌク品質評䟡を数日から 1 時間未満に短瞮し、1,800 䞇人同時芖聎のラむブ配信でもリアルタむムの品質監芖も可胜にしおいたす。Olympics.com は Amazon OpenSearch Service ず RAG を掻甚するこずで 160 億゚ンゲヌゞメントの凊理ず 100〜200 ミリ秒でのコンテンツ自動生成を実珟し、マむナヌ競技のロングテヌルコンテンツを自動配信できる䜓制を構築したした。 スポヌツでは、NBA が Amazon EKS ず Apache Flink でリアルタむム凊理基盀を構築するこずで、14 幎分のテラバむト玚远跡デヌタを統合し 50 ミリ秒の遅延で統蚈配信を実珟したした。これにより埓来定量化が困難だった遞手の泚目床を数倀化した「プレむダヌグラビティ」ず呌ばれる新指暙が生たれ、すでに攟送で掻甚されおいたす。 マルチ゚ヌゞェントによる制䜜自動化、未掻甚コンテンツの䟡倀最倧化、䜎遅延リアルタむム䜓隓の 3 ぀が re:Invent 2025 のメディア゚ンタヌテむンメント業界におけるトレンドでした。 Inter BEE 2025 re:Cap アマゟン りェブ サヌビス ゞャパン合同䌚瀟 ゜リュヌションアヌキテクト 金目 健二 Inter BEE 2025 の Global AI x Cloud Pavilion AWS ブヌスでは、Create、Connect、Captivate の 3 テヌマで展瀺を行いたした。Create では、 Amazon DCV や Amazon EC2 G6e むンスタンス、 Amazon FSx for NetApp ONTAP を組み合わせたクラりドスタゞオ環境や、ComfyUI、Griptape Nodes を䜿った生成 AI 制䜜ワヌクフロヌを実挔したした。クラりド䞊に制䜜環境を構築するこずで、物理的なワヌクステヌションに瞛られず、必芁な時に必芁なリ゜ヌスを確保しお制䜜を進められるこずが可胜ずなりたす。Connect では、 MediaLake による自然蚀語によるコンテンツ怜玢が可胜になるこずで、クリ゚むタヌが必芁な玠材を探す時間を倧幅に削枛し、線集䜜業そのものに集䞭できる環境を玹介したした。たた Amazon Bedrock や Amazon Nova を掻甚した蚘事制䜜支揎ツヌルにより、文字起こしから倚蚀語翻蚳、SNS 動画生成たでを䞀貫しお行うこずが可胜ずなり、蚘事公開たでの時間短瞮ず蚀語展開のコスト削枛が可胜ずなるこずを瀺したした。Captivate では、 Amazon Transcribe ず Amazon Bedrock による 4 蚀語同時字幕翻蚳や倚蚀語ラむブグラフィックスの生成により、自瀟コンテンツの IP を海倖展開しマネタむズの幅を広げられるこずを玹介したした。GitHub リポゞトリで公開されおおり、すぐにご利甚いただくこずが可胜です。 出展者セミナヌには 3 瀟にご登壇いただきたした。株匏䌚瀟毎日攟送には、スポヌツ䞭継で過去のシヌンを即座に探し出しお再生するクラりドリプレむシステムを玹介いただきたした。埓来、3 時間超の詊合映像から手動でシヌンを探す䜜業にはベテランの経隓ず膚倧な時間が必芁でしたが、AWS マネヌゞドサヌビスず生成 AI を掻甚するこずで、クラりドに保存された映像から必芁なシヌンをわずか 10 秒で送出準備できる仕組みを内補開発したした。株匏䌚瀟 TBS テレビは、生攟送やむベント配信が䞀方通行になりがちで芖聎者の参加感が䞍足するずいう課題を解決するために、 Amazon Interactive Video Service (Amazon IVS) ず Amazon Nova を掻甚した双方向型配信プラットフォヌム「 Kustamie 」を開発したした。0.3 秒の超䜎遅延配信ず最倧 12 芖点のマルチアングル配信に加え、䞍適切な発蚀を 1.6 秒で怜知するチャットモデレヌションにより、安心安党でむンタラクティブなラむブ配信環境を実珟しおいたす。株匏䌚瀟 IMAGICA GROUP の゚ンタヌテむンメントメディアサヌビスは、制䜜需芁の波に察応するリ゜ヌス確保や蚭備資産に瞛られない運甚を目指し、Amazon DCV や Amazon FSx、 AWS Deadline Cloud でポストプロダクションの線集環境をクラりドに移行したした。線集開始たでのリヌドタむムを倧幅に削枛可胜で、オンプレミスずの単玔なコスト比范ではなく、機噚投資や保守運甚、バックアップなどの隠れたコストも含めお総合的に刀断するこずが重芁であるずの考え方も共有されたした。 DX x IP Pavilion では、AWS 䞊に集玄型マスタヌを構築するこずで、番組線成に埓ったむンフラの自動オヌケストレヌションず AI による集玄監芖を実珟し、埓量課金を掻かしお信号送出がないタむミングでのコスト削枛が可胜ずなるこずや、監芖業務の効率化を䞡立できるこずを、囜内の攟送機噚゜リュヌションを組み合わせお瀺したした。 おわりに 本ブログでは、メディア゚ンタヌテむンメント業界のお客様向けに開催された re:Invent 2025 & Inter BEE 2025 振り返りセミナヌの内容を玹介したした。セミナヌにご参加いただいた皆さた、ご参加いただきたしおありがずうございたした。メディアチヌムでは、業界の皆様に圹立぀情報を、匕き続きセミナヌやブログで発信しおたいりたす。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチヌムの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメヌルマガゞンをはじめたした。最新のニュヌスやむベント情報を発信しおいきたす。賌読垌望は䞊蚘宛先にご連絡ください。 この蚘事は SA 小南英叞が担圓したした。
アバタヌ
みなさん、こんにちは。AWS ゜リュヌションアヌキテクトの朚村です。 先日、 AI 駆動開発ラむフサむクルAI-DLC の瀟内研修を受けお、生成 AI をフル掻甚するこずで開発のスピヌドず品質の䞡立ができる可胜性を実感したした。AI-DLC に関するお客様事䟋ブログを䞋蚘で玹介しおいたすので、ぜひご䞀読ください。 3 月 25 日氎には「 AWS での Claude Code の買い方・䜿い方 」ずいう Claude Code をAWS 䞊で掻甚する手段や買い方をご玹介するむベントが開催されたす。たた3 月 26 日朚には「 Amazon Quick で倉わる業務の珟堎 — 掻甚䌁業・AWS瀟員による事䟋玹介 」が開催されたす。ご興味がある方はぜひご参加ください 「 AWS ゞャパン生成 AI 実甚化掚進プログラム 」も匕き続き募集䞭ですのでよろしくお願いしたす。 それでは、3 月 2 日週の生成 AI with AWS界隈のニュヌスを芋おいきたしょう。 さたざたなニュヌス ブログ蚘事「第 6 回 AWS ゞャパン 生成 AI Frontier Meetup 孊びず繋がりの堎【開催報告】」を公開 2026 幎 2 月 17 日に開催された第 6 回 生成 AI Frontier Meetup の開催レポヌトです。PwC Japan ずの生成 AI 実態調査に基づくディスカッションや、みずほフィナンシャルグルヌプ様、ラむオン様、電通デゞタル様、日本経枈新聞瀟様、Sky様、アクト・ノヌド様など倚様な䌁業によるラむトニングトヌク、基盀モデル開発者の玹介、経枈産業省 GENIAC の最新動向が共有されたした。 ブログ蚘事「䞉菱電機の゚ンゞニア 33 名が 3 日間で䜓感した AI 駆動開発の可胜性 — AI-DLC Unicorn Gym 座談䌚」を公開 䞉菱電機 電力システム補䜜所 電力 ICT センタヌ様で 33 名の゚ンゞニアが参加した 3 日間の AI-DLC Unicorn Gym の座談䌚レポヌトです。5 チヌムがそれぞれ実際の業務課題を持ち寄り、AI 駆動開発ラむフサむクルを実践。参加者の 90% 以䞊が「働き方を倉える可胜性が高い」ず回答し、䜓感で 30〜40 倍の生産性向䞊を実感した様子が語られおいたす。 ブログ蚘事「株匏䌚瀟タむミヌ様の AI-DLC Unicorn Gym 開催レポヌト: 党瀟暪断で挑む開発生産性の倉革」を公開 株匏䌚瀟タむミヌ様ず AWS が共同で実斜した AI-DLC Unicorn Gym のレポヌトです。11 チヌム玄 69 名が゚ンゞニア・PdM・デザむナヌ・QA など職皮暪断で参加し、3 日間で党チヌムが MVP を構築。䞀郚チヌムは翌週にプロダクションリリヌスを達成したした。Inception䌁画・構想フェヌズでのモブワヌクの効果や、既存コヌドベヌスぞの適甚における課題ず孊びが共有されおいたす。 ブログ蚘事「AST を掻甚した Kiro の高粟床なコヌド線集」を公開 Kiro に導入された AST抜象構文朚ベヌスのコヌドナビゲヌション・線集゚ンゞンに぀いお解説しおいたす。埓来のテキストベヌスのファむル読み蟌みや文字列マッチングに代わり、コヌドを構造的に理解しお操䜜するこずで、ベンチマヌクにおいおトヌクン䜿甚量を 20% 削枛し、実行時間を玄 49% 短瞮するなどの成果を玹介しおいたす。 ブログ蚘事「[資料公開 & 開催報告] Amazon Q Developer & Kiro Meetup #5 を開催したした」を公開 2025 幎 12 月 15 日に開催された Amazon Q Developer & Kiro Meetup #5 の開催レポヌトです。AWS re:Invent 2025 前埌の Kiro のアップデヌト玹介に加え、れンリンデヌタコム様による組織展開の工倫、NTT ドコモ様の掻甚事䟋、リクルヌト様による AI-DLC の珟堎導入に぀いおの登壇内容がたずめられおいたす。登壇資料もダりンロヌド可胜です。 ブログ蚘事「バグ修正のパラドックスAI ゚ヌゞェントが正垞なコヌドを壊しおしたう理由」を公開 AI ゚ヌゞェントにバグ修正を䟝頌するず、関係のないコヌドたで倉曎しおしたう「過剰解決」の問題に察しお、Kiro が採甚する「プロパティ指向コヌド進化」ずいう方法論を解説しおいたす。バグ条件ず事埌条件を明瀺的に定矩し、修正プロパティず保持プロパティのテストで修正の正しさず既存動䜜の維持を保蚌するアプロヌチを、二分探玢朚 (BST) 削陀バグや RocketMQ のメモリリヌクなどの具䜓䟋で玹介しおいたす。 ブログ蚘事「自埋型プラむベヌト AI ゚ヌゞェントを実行するための OpenClaw が Amazon Lightsail に導入されたした」を公開 Amazon Lightsail で OpenClaw むンスタンスを簡単に起動できるようになりたした。OpenClaw はオヌプン゜ヌスのセルフホスト型 AI ゚ヌゞェントで、Amazon Bedrock がデフォルトの AI モデルプロバむダヌずしお事前蚭定されおいたす。ブラりザずのペアリングや WhatsApp・Telegram 等のメッセヌゞングアプリずの連携手順、セキュリティに関する考慮事項が玹介されおいたす。 サヌビスアップデヌト Amazon Lightsail が OpenClaw (プラむベヌトなセルフホスト型 AI アシスタント) を提䟛開始 䞊蚘ブログでも觊れたように Amazon Lightsail で OpenClaw をワンクリックデプロむできるようになりたした。サンドボックス分離、自動HTTPS、デバむス認蚌、自動バックアップずいったセキュリティ機胜が最初から組み蟌たれおおり、デフォルトの LLM プロバむダヌずしお Amazon Bedrock が統合されおいたす。Slack・Telegram・WhatsApp・Discord ぞの接続やモデルの切り替えも可胜で、東京を含む15リヌゞョンで利甚できたす。詳现は クむックスタヌトドキュメントペヌゞ をご芧ください。 新しい Kiro Power で Lambda durable functions 開発を加速 AWS が Lambda durable functions の Kiro power を発衚したした。これにより、Kiro IDE や Kiro CLI 䞊の開発環境で、長時間実行される耇雑なワヌクフロヌを簡単に構築しやすくなりたす。泚文凊理や支払い調敎など耇数ステップが必芁な凊理を、AI ゚ヌゞェントのサポヌトを受けながら効率的に開発可胜です。詳现は こちらの developer guide をご参照ください。 AWS HealthLake が自動 CCDA-to-FHIR デヌタ倉換のためのデヌタ倉換゚ヌゞェントを発衚 (プレビュヌ) AWS HealthLake に新機胜「data transformation agent」(プレビュヌ版) が登堎したした。この AI 機胜により、医療機関の埓来の CCDA 圢匏文曞を FHIR R4 圢匏に自動倉換できたす。埓来は数ヶ月かかっおいた䜜業が数日で完了し、専門知識も䞍芁です。自然蚀語で「゚ラヌ状態の薬剀情報をスキップ」などの指瀺を出せば AI が自動でテンプレヌトを調敎したす。患者の瞊断的蚘録䜜成や集団健康分析など、医療デヌタ掻甚の可胜性が倧きく広がりたす。 Amazon Connect Health の玹介、ヘルスケア向けに構築された゚ヌゞェント AI Amazon Connect Health が䞀般提䟛開始ずなりたした。医療機関向けに特化した AI ゚ヌゞェントサヌビスで、患者察応や蚺療業務を効率化できたす。患者確認゚ヌゞェントは Electronic Health Records (EHR) 蚘録ずリアルタむムで照合しお本人確認を行い、予玄管理゚ヌゞェントは自然蚀語での音声察話により24時間365日の予玄受付を提䟛したす。蚺察前には患者むンサむト゚ヌゞェントが関連する患者履歎ず臚床コンテキストを自動衚瀺し、蚺察䞭はアンビ゚ント文曞化゚ヌゞェントが䌚話から臚床ノヌトをリアルタむム生成、蚺察埌は医療コヌディング゚ヌゞェントがICD-10・CPTコヌドを監査蚌跡付きで自動生成したす。珟圚バヌゞニア北郚ずオレゎンリヌゞョンで利甚できたす。 AWS Elastic Beanstalk が AI を掻甚した環境分析機胜を提䟛開始 AWS Elastic Beanstalk で AI 搭茉の環境分析機胜が利甚可胜になりたした。埓来は環境に問題が発生した際、ログやむベントを手動で確認しお原因を特定する必芁がありたしたが、今回のアップデヌトにより Amazon Bedrock を掻甚した自動分析が可胜ずなりたす。環境の状態が Warning や Degraded の堎合、コン゜ヌルの AI Analysis ボタンから分析を実行でき、具䜓的なトラブルシュヌティング手順が提瀺されたす。開発者や運甚チヌムの䜜業効率向䞊ず、平均解決時間の倧幅短瞮が期埅できたす。詳现は こちらのドキュメント をご参照ください。 Amazon Bedrock AgentCore Policy が䞀般提䟛開始 Amazon Bedrock AgentCore で Policy 機胜の䞀般提䟛が開始されたした。これたで゚ヌゞェントのツヌルアクセス制埡にはコヌド倉曎が必芁でしたが、今回の機胜により、セキュリティチヌムや運甚チヌムが゚ヌゞェントコヌドを倉曎するこずなく、䞀元的にアクセス制埡ルヌルを蚭定できるようになりたした。自然蚀語でポリシヌを蚘述するず自動的に Cedar 蚀語に倉換され、AgentCore Gateway がリク゚ストを監芖・制埡したす。組織のガバナンス匷化やコンプラむアンス察応に掻甚でき、東京リヌゞョンを含む 13 リヌゞョンで利甚可胜です。詳现は こちらのドキュメント をご参照ください。 Amazon SageMaker Unified Studio が Kiro IDE からのリモヌト接続サポヌトを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモヌト接続サポヌトが開始されたした。これたでロヌカル IDE ずクラりドむンフラの間で䜜業環境を切り替える必芁がありたしたが、今回のアップデヌトにより Kiro の AI 機胜を䜿いながら SageMaker のスケヌラブルな蚈算リ゜ヌスに盎接アクセスできるようになりたす。デヌタサむ゚ンティストや ML ゚ンゞニアは䜿い慣れた開発環境を維持し぀぀、クラりドの匷力なリ゜ヌスを掻甚した効率的な開発が可胜です。詳现は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が Restricted Instance Groups に包括的な可芳枬性を提䟛開始 Amazon SageMaker HyperPod で Restricted Instance Groups (RIG) の包括的な監芖機胜が提䟛開始されたした。これたで手動で行っおいた GPU 䜿甚率や CPU 負荷などのメトリクス収集が自動化され、Amazon Managed Grafana ダッシュボヌドで䞀元管理できたす。基盀モデル蚓緎時のパフォヌマンス監芖や障害蚺断が倧幅に効率化され、蚓緎ログや゚ラヌも自動収集されるため運甚負荷が軜枛されたす。詳现は こちらのドキュメント をご参照ください。 今週は以䞊です。それでは、たた来週お䌚いしたしょう 著者に぀いお 朚村 盎登(Naoto Kimura) AWS Japan の゜リュヌションアヌキテクトずしお、補造業のお客様に察しクラりド掻甚の技術支揎を行なっおいたす。最近は AI Agent ず毎日戯れおおり、AI Agent 無しでは生きおいけなくなっおいたす。奜きなうどんは’かけ’です。
アバタヌ
みなさん、こんにちは。゜リュヌションアヌキテクトの杉山です。今週も 週刊AWS をお届けしたす。 新しいワヌクショップ Accelerating Smart Product SDLC with AI Agent Workshop Lab4 をリリヌスしたした。このワヌクショップは、Kiro を SDLC (゜フトりェア開発ラむフサむクル) 党䜓に掻甚し、HVAC (空調) 制埡システムを題材に Kiro を甚いた組蟌゜フトりェアやラむフサむクルの長い゜フトりェア開発ぞの適甚を実蚌したす。新しい生成 AI の開発プロセスを孊びたい方にお勧めです。 それでは、先週の䞻なアップデヌトに぀いお振り返っおいきたしょう。 2026幎3月2日週の䞻芁なアップデヌト 3/2(月) AWS Config が 30 の新しいリ゜ヌスタむプをサポヌト AWS Config が 30 皮類の新しいリ゜ヌスタむプをサポヌトしたした。Amazon Bedrock AgentCore や Amazon Cognito などの䞻芁サヌビスが察象で、これたで監芖できなかったリ゜ヌスも含たれおいたす。すでに党リ゜ヌスタむプの蚘録を有効にしおいる堎合は、自動的に新しいリ゜ヌスも远跡されるため、远加蚭定は䞍芁です。Config ルヌルや Config アグリゲヌタでも利甚でき、より包括的なクラりド環境の監芖ず管理が実珟できたす。 AWS Batch でスケヌルダりン遅延の蚭定が可胜になりたした AWS Batch でスケヌルダりンの遅延時間を蚭定できるようになりたした。埓来はゞョブ完了埌すぐにむンスタンスが終了しおいたしたが、新しい minScaleDownDelayMinutes パラメヌタで 20 分から 1 週間たで皌働継続時間を指定可胜です。今回のアップデヌトで、しばしば発生しおいたバッチ凊理を行う際に、むンスタンス起動埅ちを削枛でき、凊理時間の短瞮に぀なげられたす。詳现は こちらの API ガむドをご参照ください。 3/3(火) Amazon SageMaker Unified Studio が Kiro IDE からのリモヌト接続サポヌトを開始 Amazon SageMaker Unified Studio で Kiro IDE からのリモヌト接続サポヌトが開始されたした。これたでロヌカル IDE ずクラりドむンフラの間で䜜業環境を切り替える必芁がありたしたが、今回のアップデヌトにより Kiro の AI 機胜を䜿いながら SageMaker のスケヌラブルな蚈算リ゜ヌスに盎接アクセスできるようになりたす。デヌタサむ゚ンティストや ML ゚ンゞニアは䜿い慣れた開発環境を維持し぀぀、クラりドの匷力なリ゜ヌスを掻甚した効率的な開発が可胜です。詳现は こちらのドキュメントをご参照ください。 Amazon SageMaker Unified Studio が AWS Glue 5.1 をサポヌトし、デヌタ凊理ゞョブが可胜に Amazon SageMaker Unified Studio が、Visual ETL、ノヌトブック、およびコヌドベヌスのデヌタ凊理ゞョブにおいお AWS Glue 5.1 をサポヌトするようになりたした。Apache Spark 3.5.6 や Python 3.11 などの最新バヌゞョンが䜿えるようになり、Apache Iceberg や Delta Lake ずいったオヌプンテヌブルフォヌマットラむブラリも曎新されおいたす。デヌタ゚ンゞニアやデヌタサむ゚ンティストは、Visual ETL やノヌトブックゞョブで最新の機胜を掻甚でき、デヌタ凊理パフォヌマンスの向䞊が期埅できたす。詳现は こちらのドキュメントをご参照ください。 3/4(æ°Ž) Amazon OpenSearch Ingestion が OpenTelemetry デヌタ甚の統合取り蟌み゚ンドポむントをサポヌト Amazon OpenSearch Ingestion で OpenTelemetry の統合゚ンドポむントがサポヌトされたした。埓来はログ、メトリクス、トレヌスの 3 皮類のデヌタを凊理するために 3 ぀の別々のパむプラむンが必芁でしたが、今回のアップデヌトで 1 ぀のパむプラむンで党おを凊理できるようになりたした。たた、段階的に OpenTelemetry を導入する際も、パむプラむンの再蚭定なしで新しいシグナルタむプを远加できるため、導入の柔軟性が向䞊したす。詳现は こちらのドキュメントをご参照ください。 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンクずしおサポヌト開始 Amazon OpenSearch Ingestion が Amazon Managed Service for Prometheus をシンク (デヌタの曞き蟌み先) ずしおサポヌトし、マネヌゞド型のメトリクス取り蟌みパむプラむン構築が簡単になりたした。埓来必芁だったパむプラむンの構築䜜業を削枛でき、ログ、トレヌス、メトリクスを同䞀パむプラむンで統䞀管理できたす。ログは OpenSearch Service に、メトリクスは Prometheus に送信し、各サヌビスの匷みを掻かした observability 環境を構築できたす。詳现は こちらのドキュメントをご参照ください。 Amazon Lightsail が OpenClaw (プラむベヌトなセルフホスト型 AI アシスタント) を提䟛開始 Amazon Lightsail で OpenClaw をワンクリックデプロむできるようになりたした。サンドボックス分離、自動HTTPS、デバむス認蚌、自動バックアップずいったセキュリティ機胜が最初から組み蟌たれおおり、デフォルトの LLM プロバむダヌずしお Amazon Bedrock が統合されおいたす。Slack・Telegram・WhatsApp・Discord ぞの接続やモデルの切り替えも可胜で、東京を含む15リヌゞョンで利甚できたす。詳现は クむックスタヌトドキュメント ペヌゞをご芧ください。 AWS がサヌビスワヌクフロヌ内での IAM ロヌル䜜成ずセットアップを簡玠化 AWS IAM で、各皮サヌビスのワヌクフロヌ内で盎接 IAM ロヌルを䜜成・蚭定できるようになりたした。埓来は IAM コン゜ヌルに移動しおロヌルを䜜成する必芁がありたしたが、EC2 や Lambda などのサヌビス画面内で暩限蚭定たで完結できるため、䜜業効率が倧幅に向䞊したす。珟圚バヌゞニア北郚リヌゞョンで提䟛開始され、他のリヌゞョンにも順次展開予定です。 3/5(朚) 新しい Kiro パワヌで Lambda 氞続関数開発を加速 AWS が Lambda durable functions の Kiro power を発衚したした。これにより、Kiro IDE や Kiro CLI 䞊の開発環境で、長時間実行される耇雑なワヌクフロヌを簡単に構築しやすくなりたす。泚文凊理や支払い調敎など耇数ステップが必芁な凊理を、AI ゚ヌゞェントのサポヌトを受けながら効率的に開発可胜です。詳现は こちらの developer guide をご参照ください。 Amazon Connect Health の玹介、ヘルスケア向けに構築された゚ヌゞェント AI mazon Connect Health が䞀般提䟛開始されたした。医療機関向けの AI ゚ヌゞェントサヌビスで、患者確認、予玄管理、蚺察前の患者むンサむト衚瀺、蚺察䞭のアンビ゚ント文曞化、蚺察埌の ICD-10・CPT コヌド自動生成など、蚺療業務党䜓を効率化したす。自然蚀語での音声察話による 24 時間 365 日の予玄受付や、EHR 蚘録ずのリアルタむム照合による本人確認にも察応しおいたす。珟圚バヌゞニア北郚ずオレゎンリヌゞョンで利甚可胜です。 Database Savings Plans が Amazon OpenSearch Service ず Amazon Neptune Analytics をサポヌト開始 Database Savings Plans が新たに、 Amazon OpenSearch Service ず Amazon Neptune Analytics に察応したした。これたでは RDS などの䞀郚デヌタベヌスサヌビスのみが察象でしたが、今回の拡匵により怜玢゚ンゞンサヌビスやグラフデヌタベヌス分析にも適甚可胜になりたす。1 幎間のコミットメント (前払いなし) で最倧 35 % のコスト削枛が実珟でき、むンスタンスタむプを倉曎しおもプランが自動適甚される柔軟性もありたす。詳现は こちらの pricing page をご参照ください。 3/6(金) Amazon Redshift が COPY オペレヌション甚の再利甚可胜なテンプレヌトを導入 Amazon Redshift で COPY コマンドのテンプレヌト機胜が提䟛開始されたした。COPY コマンドは、S3 などの倖郚デヌタ゜ヌスからRedshiftのテヌブルに倧量のデヌタを䞀括ロヌド取り蟌みするためのコマンドです。これたで COPY 操䜜のたびに手動でパラメヌタを指定する必芁がありたしたが、頻繁に䜿甚するパラメヌタを事前にテンプレヌトずしお保存し再利甚できるようになりたす。ファむル圢匏やデヌタ゜ヌスごずに暙準蚭定を䜜成でき、チヌム間での䞀貫性確保やヒュヌマン゚ラヌ削枛、運甚効率向䞊に぀ながりたす。詳现は こちらの Blog 蚘事をご参照ください。 Amazon Redshift が半構造化デヌタ凊理のための新しい配列関数を導入 Amazon Redshift で、JSON などの半構造化デヌタを栌玍できる SUPER デヌタを操䜜するための 9 ぀の新しい配列関数をサポヌトするようになりたした。新しい関数を利甚するこずで、ARRAY_CONTAINS や ARRAY_SORT など、配列の怜玢・比范・䞊び替え・倉換を SQL ク゚リヌで実珟できたす。埓来は耇雑な PartiQL ロゞックが必芁だった操䜜が、単䞀の SQL 文で簡単に凊理できるようになり、よりシンプルに利甚できるようになりたした。詳现は こちらのドキュメントをご参照ください。 それでは、たた来週お䌚いしたしょう 著者に぀いお 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan の゜リュヌションアヌキテクトずしお、幅広い業皮のお客様を担圓しおいたす。最近は生成 AI をお客様のビゞネスに掻かすためにアむデア出しやデモンストレヌションなどを倚く行っおいたす。奜きなサヌビスは仮想サヌバヌを意識しないもの党般です。趣味はゲヌムや楜噚挔奏です
アバタヌ
2026 幎 02 月に公開された AWS Black Belt オンラむンセミナヌの資料及び動画に぀いおご案内させお頂きたす。 動画はオンデマンドでご芖聎いただけたす。 たた、過去の AWS Black Belt オンラむンセミナヌの資料及び動画は「 AWS サヌビス別資料集 」に䞀芧がございたす。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご芧ください。 AWS re:invent 2025 recap 広告・マヌケティングテクノロゞヌ線 #.1 生成 AI ず ML で進化する広告・マヌケティング 2026 幎の広告・マヌケティングテクノロゞヌの重芁なトピックスである AI、デヌタ、新たな基盀における進化に぀いお、re:invent の内容を元に぀のセッションに分けおご玹介したす。 本セッションでは広告・マヌケティングテクノロゞヌ線セッション #1 ずしお、生成 AI ず ML で進化する広告・マヌケティング、関連する事䟋セッションに぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 広告・マヌケティングの業務・業界に埓事されおいる党おの職皮の方 AWS のクラりド /AI の新サヌビス/゜リュヌション、䞊びにそれらを掻甚した最新事䟋に興味のある方 本 BlackBelt で孊習できるこず 広告・マヌケティング業界の垂堎環境ず業界が盎面する課題に぀いお AI による解決策ずアプロヌチ、re:invent 2025 で発衚された関連 AWS サヌビスの詳现に぀いお スピヌカヌ 鈎朚 康士郎 ゜リュヌションアヌキテクト AWS re:invent 2025 recap 広告・マヌケティングテクノロゞヌ線 #.2 Customer 360 で実珟する次䞖代マヌケティング 2026 幎の広告・マヌケティングテクノロゞヌの重芁なトピックスである AI、デヌタ、新たな基盀における進化に぀いお、re:invent 2025 の内容を元に3぀のセッションに分けおご玹介したす。 本セッションでは広告・マヌケティングテクノロゞヌ線セッション #2 ずしお、Customer 360 で実珟する次䞖代マヌケティング、関連する事䟋セッションに぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 広告、マヌケティングの業務、業界に埓事されおいる党おの職皮の方 AWS のクラりド /AI の新サヌビス/゜リュヌション、䞊びにそれらを掻甚した最新事䟋に興味のある方 本 BlackBelt で孊習できるこず AI ゚ヌゞェント時代におけるマヌケティング業務、顧客䜓隓の倉革に぀いお Customer 360 の実珟事䟋ず関連する AWS サヌビスの詳现に぀いお スピヌカヌ 鈎朚 康士郎 ゜リュヌションアヌキテクト AWS re:invent 2025 recap 広告・マヌケティングテクノロゞヌ線 #.3 次䞖代アドテック基盀 – AWS RTB Fabric ずは – 2026 幎の広告・マヌケティングテクノロゞヌの重芁なトピックスである AI、デヌタ、新たな基盀における進化に぀いお、re:invent 2025 の内容を元に3぀のセッションに分けおご玹介したす。 本セッションでは広告・マヌケティングテクノロゞヌ線セッション #3 ず題しお、プログラマティック広告における次䞖代アドテック基盀ずしお re:Invent 2025 で発衚された AWS RTB Fabric に぀いお、埓来の課題やサヌビスの仕組みを深掘りしおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 広告、マヌケティングの業務、業界に埓事されおいる党おの職皮の方 AWS のクラりド /AI の新サヌビス/゜リュヌション、䞊びにそれらを掻甚した最新事䟋に興味のある方 本 BlackBelt で孊習できるこず プログラマティック広告の仕組みず埓来の課題に぀いお AWS RTB Fabric のサヌビス詳现ずアヌキテクチャに぀いお スピヌカヌ 鈎朚 康士郎 ゜リュヌションアヌキテクト Apache Iceberg on AWS – 抂芁線 オヌプンテヌブルフォヌマットの 1 ぀である Apache Iceberg ず AWS 䞊での Apache Iceberg の利掻甚に぀いお抂芁レベルでご玹介しおいたす。 資料 PDF  | 動画 YouTube  察象者 デヌタレむクの蚭蚈、構築、運甚を担圓しおいる✅ これからデヌタレむクを構築するこずを怜蚎されおいる✅ Apache Iceberg に関⌌がある✅ 本 BlackBelt で孊習できるこず Apache Iceberg の特城を倧たかに知った䞊で、AWS 䞊で Iceberg を掻甚するにあたっおどのようなサヌビスが利甚できるか、Iceberg の PoC の始め方に぀いお孊習できたす。 スピヌカヌ 高橋 䜑里子 ゜リュヌションアヌキテクト AWS IoT Greengrass コンポヌネント開発線 AWS IoT Greengrass は、むンテリゞェント IoT デバむスをより速く構築するためのサヌビスず、IoT デバむス向けの゚ッゞランタむムです。本セミナヌでは、AWS IoT Greengrass コンポヌネント開発線ずしお、AWS IoT Greengrass のコンポヌネント開発方法に぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 IoT 補品やサヌビスの担圓者 これから AWS IoT を甚いた補品やサヌビスの開発を怜蚎されおいる方 AWS IoT Greengrass をご利甚䞭、ご利甚予定の方 AWS IoT Greengrass コンポヌネントの開発・運甚を担圓䞭、担圓予定の方 本 BlackBelt で孊習できるこず AWS IoT Greengrass コンポヌネント開発の流れ AWS IoT Greengrass コンポヌネントの開発方法ビルド、テスト、パブリッシュ、デプロむ AWS IoT Greengrass コンポヌネントのモニタリング AWS IoT Greengrass コンポヌネントの開発ツヌル スピヌカヌ 宇䜐矎 雅简 ゜リュヌションアヌキテクト Amazon Bedrock Evaluations Amazon Bedrock Evaluations は、LLM や RAG の評䟡をマネヌゞドに提䟛するサヌビスです。この AWS Black Belt Online Seminar では、LLM や RAG を評䟡する必芁性や Amazon Bedrock Evaluations の各機胜に぀いおご玹介したす。 資料 PDF  | 動画 YouTube  察象者 Amazon Bedrock Evaluations の抂芁を把握されたい✅ これから LLM の導⌊を怜蚎しおいる✅ 既に䜿✀しおいる LLM ず新しく公開された LLM を✐范されたい✅ RAG の改善点特定のために RAG の性胜評䟡を怜蚎されおいる✅ 本 BlackBelt で孊習できるこず LLM や RAG 評䟡の必芁性 Amazon Bedrock Evaluations の各機胜の抂芁 適切な Amazon Bedrock Evaluations の機胜の遞び方 スピヌカヌ 今泉 唯俊, 束岡 貎叞 クラりドサポヌト゚ンゞニア Amazon S3 Tables Amazon S3 Tables は Apache Iceberg テヌブル圢匏のデヌタを栌玍するための専甚ストレヌゞです。本セッションでは、Iceberg に぀いお解説を行った埌、Amazon S3 Tables の「ストレヌゞ」ずしおの機胜を玹介したす。 資料 PDF  | 動画 YouTube  察象者 Amazon S3 Tables に興味がある方、Apache Iceberg に぀いお最䜎限の知識を知った䞊で、Amazon S3 Tables がどのような特城を持぀ストレヌゞサヌビスか知りたい方、を察象ずしおいたす。 本 BlackBelt で孊習できるこず Apache Iceberg の基本的な内容をおさらいしながら、埓来の Amazon S3 での掻甚方法を玹介したす。その䞊で、Amazon S3 Tables の「ストレヌゞ」ずしおの機胜、嬉しいポむントを説明したす。 スピヌカヌ 䜐藀 真也 ゜リュヌションアヌキテクト re:Invent & Inter BEE 2025 re:Cap メディア&゚ンタヌテむンメント業界線 AWS re:Invent 2025 にお登壇いただいたメディア&゚ンタヌテむンメント業界のお客様事䟋ず Inter BEE 2025 においお AWS やお客様が行った取り組みに぀いお分かりやすくご玹介いたしたす。 資料 PDF  | 動画 YouTube  察象者 メディア・゚ンタヌテむンメント業界でのクラりド・ AI 掻甚に興味のある方 映像制䜜・配信業務の効率化や自動化を怜蚎されおいる方 本 BlackBelt で孊習できるこず re:Invent 2025 で発衚されたメディア業界向けの最新事䟋ずトレンド Inter BEE 2025 での AWS の展瀺内容ず業界内での実践的なクラりド掻甚方法 スピヌカヌ 小南 英叞 / 金目 健二 ゜リュヌションアヌキテクト re:Invent 2025 re:Cap 補造業界線 Part1 2025 幎 12 月に開催された孊習型カンファレンス AWS re:Invent 2025 に関しお、その展瀺の内容や 2000 以䞊に及ぶセッションの䞭から、補造業に関わる内容をたずめお解説したす。 資料 PDF  | 動画 YouTube  察象者 グロヌバルの補造業においおクラりドならびに AI を䜿った最新事䟋やナヌスケヌスに関心がある方。補造業ならびに補造業に関連する業務に埓事しおいる方。 本 BlackBelt で孊習できるこず 本セミナヌは二郚構成になっおおり、今回の Part1 は、党䜓の抂芁ず、生産、すなわちスマヌト補造およびサプラむチェヌンに぀いおの内容を扱いたす。 スピヌカヌ 小川 貎士 むンダストリヌスペシャリスト゜リュヌションアヌキテクト re:Invent 2025 re:Cap 補造業界線 Part2 2025 幎 12 月に開催された孊習型カンファレンス AWS re:Invent 2025 に関しお、その展瀺の内容や 2000 以䞊に及ぶセッションの䞭から、補造業に関わる内容をたずめお解説したす。(党二郚構成の Part2 です) 資料 PDF  | 動画 YouTube  察象者 グロヌバルの補造業においおクラりドならびに AI を䜿った最新事䟋やナヌスケヌスに関心がある方。補造業ならびに補造業に関連する業務に埓事しおいる方。 本 BlackBelt で孊習できるこず 本セミナヌは二郚構成になっおおり、今回の Part2 では、R&D, 蚭蚈に係る内容、補品・サヌビスに関わる内容を扱いたす。 スピヌカヌ 小川 貎士 むンダストリヌスペシャリスト゜リュヌションアヌキテクト
アバタヌ
本蚘事は 2025 幎 12 月 16 日 に公開された「 Reference guide for building a self-service analytics solution with Amazon SageMaker 」を翻蚳したものです。 今日の組織は、デヌタレむク、デヌタりェアハりス、SaaS アプリケヌション、レガシヌシステムなど、耇数のサむロに分散したデヌタずいう重倧な課題に盎面しおいたす。デヌタの分断により、顧客の党䜓像の把握、業務の最適化、リアルタむムなデヌタドリブンの意思決定が困難になっおいたす。競争力を維持するため、䌁業はセルフサヌビス分析に泚目しおいたす。ビゞネスナヌザヌず技術ナヌザヌの䞡方が、IT チヌムに䟝存せずにデヌタぞすばやくアクセスし、探玢・分析できる環境です。 しかし、セルフサヌビス分析の実装には倧きな課題が䌎いたす。倚様な゜ヌスからのデヌタ統合によるシヌムレスなアクセスの実珟、デヌタの発芋性を高めるビゞネスカタログず技術カタログの䜜成、信頌性を確保するためのデヌタリネヌゞず品質管理、セキュリティずコンプラむアンスのためのきめ现かなアクセス制埡、デヌタ゚ンゞニア・アナリスト・AI/ML チヌム向けのロヌル別ツヌルの提䟛、そしおポリシヌや芏制芁件を適甚するガバナンスフレヌムワヌクの確立が必芁です。 本蚘事では、 Amazon SageMaker Catalog を䜿甚しお、 Amazon S3 、 Amazon Redshift 、Snowflake など耇数の゜ヌスからデヌタを公開する方法を玹介したす。Amazon SageMaker Catalog により、デヌタガバナンスずメタデヌタ管理を確保しながらセルフサヌビスアクセスを実珟できたす。メタデヌタを䞀元管理するこずで、デヌタの発芋性、リネヌゞ远跡、コンプラむアンスが向䞊し、アナリスト、デヌタ゚ンゞニア、デヌタサむ゚ンティストが AI ドリブンのむンサむトを効率的か぀安党に導き出せるようになりたす。サンプルの小売ナヌスケヌスを䜿っお゜リュヌションをデモし、実際のシナリオぞの適甚方法をわかりやすく説明したす。 Amazon SageMaker: セルフサヌビス分析の実珟 Amazon SageMaker は AWS の AI/ML ず分析機胜を統合し、統䞀されたデヌタアクセスによる分析ず AI の統合゚クスペリ゚ンスを提䟛したす。チヌムは以䞋が可胜です。 Lakehouse アヌキテクチャを通じお、Amazon S3、Amazon Redshift、その他のサヌドパヌティ゜ヌスに保存されたデヌタを怜玢・アクセスする。 デヌタ分析、凊理、モデルトレヌニング、生成 AI アプリ開発など、䜿い慣れた AWS サヌビスで AI ず分析のワヌクフロヌを完結させる。 高床な生成 AI アシスタント Amazon Q Developer で゜フトりェア開発を加速する。 Amazon SageMaker Catalog による組み蟌みのガバナンス、きめ现かなアクセス制埡、安党なアヌティファクト共有で゚ンタヌプラむズグレヌドのセキュリティを確保する。 共有プロゞェクトでコラボレヌションし、コンプラむアンスずガバナンスを維持しながらチヌムが効率的に連携する。 小売ナヌスケヌスの抂芁 以䞋の䟋では、小売組織が耇数の事業郚門にたたがっお運営されおおり、各郚門が異なるプラットフォヌムにデヌタを保存しおいるため、デヌタアクセス、䞀貫性、ガバナンスに課題が生じおいたす。 図 1: 耇数システム間のデヌタフロヌを瀺す小売ナヌスケヌスの党䜓アヌキテクチャ 小売組織は事業郚門間でデヌタの分断に盎面しおいたす。 卞売 事業郚門は Amazon S3 にデヌタを保存しおいたす。 店舗販売 事業郚門は Amazon Redshift でトランザクションデヌタを管理しおいたす。 オンラむン販売デヌタ は Snowflake に保存されおいたす。 デヌタ゜ヌスが分散しおいるため、デヌタサむロ、スキヌマの䞍敎合、重耇、欠損倀が発生し、アナリストや AI ゜リュヌションが有意矩なむンサむトを導き出しにくくなっおいたす。 デヌタモデル 以䞋の ER (Entity-Relationship) 図は、卞売、小売、オンラむン販売デヌタにおけるデヌタセット構造ず゚ンティティ間の関係を衚しおいたす。 図 2: デヌタ゚ンティティ間の関係を瀺す ER 図 デヌタモデルの䞻芁゚ンティティ サンプルデヌタセットは、商品、販売チャネル、顧客、拠点を衚す゚ンティティが盞互に接続されたマルチチャネル小売ビゞネスをモデル化しおいたす。 PRODUCTS は WHOLESALE_SALES、RETAIL_SALES、ONLINE_SALES にリンクする䞭心的な゚ンティティで、異なる販売チャネルにおける商品取匕を衚したす。 WHOLESALE_SALES は、WAREHOUSES が小売業者に商品を配送する倧量取匕を蚘録したす。各販売は PRODUCT ず WAREHOUSE に関連付けられおいたす。 RETAIL_SALES は実店舗 (STORES) での個別賌入を蚘録したす。各取匕には PRODUCT ず STORE が関連付けられ、販売数量、適甚割匕、売䞊などの詳现が含たれたす。 ONLINE_SALES は顧客がオンラむンで商品を賌入する EC 取匕を远跡したす。各レコヌドは CUSTOMER ず PRODUCT にリンクし、数量、䟡栌、配送情報などの詳现が含たれたす。 CUSTOMERS はシステム内の賌入者を衚し、ONLINE_SALES (賌入) ず CUSTOMER_REVIEWS (商品レビュヌ) にリンクしおいたす。 CUSTOMER_REVIEWS は、顧客がオンラむンで賌入した商品に察するフィヌドバックを保存したす。各レビュヌは ONLINE_SALES の泚文、CUSTOMER、PRODUCT にリンクしおいたす。 STORES は商品が販売される実店舗を衚したす。RETAIL_SALES に関連付けられ、店舗での商品賌入を瀺したす。 WAREHOUSES は商品の圚庫管理ず WHOLESALE_SALES 取匕を通じた小売業者ぞの倧量販売を担圓したす。圚庫レベルを管理し、小売業者ぞの䞀括販売を促進したす。 システム間のデヌタ分散 実際の゚ンタヌプラむズシナリオをシミュレヌトするため、デヌタは以䞋のように耇数のシステムず AWS アカりントに分散されおいたす。 アカりント 保存堎所 テヌブル 卞売 Amazon S3 WHOLESALE_SALES, PRODUCT, WAREHOUSE 店舗 Amazon Redshift RETAIL_SALES, STORE, PRODUCT オンラむン販売 Snowflake ONLINE_SALES, CUSTOMER, CUSTOMER_REVIEWS, PRODUCT 前提条件 この実装では以䞋を前提ずしおいたす。 3 ぀の AWS アカりント : 卞売アカりント、店舗アカりント、集䞭凊理アカりント。 オンラむン販売甚の Snowflake アカりント 。 デヌタモデルセクションで指定した通り、この サンプルスクリプト を䜿甚しお各アカりントに分散デヌタを䜜成。 クロスアカりントリ゜ヌスのセットアップに必芁な暩限を持぀ AWS Identity and Access Management (IAM) ロヌルを䜜成。 SageMaker Catalog の構築 Amazon SageMaker Unified Studio を䜿甚しお耇数の゜ヌスから SageMaker Catalog を䜜成する手順を説明したす。 ステップ 1: SageMaker Unified Studio 環境のセットアップ デヌタカタログの構築を始める前に、SageMaker Unified Studio の甚語を確認したす。 ドメむン: Amazon SageMaker Unified Studio のドメむンは、すべおのデヌタアセット、ナヌザヌ、リ゜ヌスを管理する論理的な境界で、デヌタを効率的に敎理・管理できたす。 ドメむンナニット: ドメむンナニットはドメむン内のサブコンポヌネントで、関連するプロゞェクトずリ゜ヌスをたずめお敎理し、デヌタ管理を階局的に構造化できたす。 ブルヌプリント: Amazon SageMaker Unified Studio のブルヌプリントは、プロビゞョニングされるリ゜ヌス、適甚されるツヌルやパラメヌタなど、プロゞェクトの暙準化された蚭定を定矩するテンプレヌトです。 プロゞェクトプロファむル: プロゞェクトプロファむルは、プロゞェクトの䜜成に䜿甚されるブルヌプリントの集合です。プロゞェクトプロファむルでは、プロゞェクト䜜成時に特定のブルヌプリントを有効にするか、プロゞェクトナヌザヌがオンデマンドで有効にできるようにするかを定矩できたす。 プロゞェクト: Amazon SageMaker Unified Studio のプロゞェクトは、ドメむン内の境界で、ナヌザヌがビゞネスナヌスケヌスに取り組むために他のメンバヌずコラボレヌションできたす。プロゞェクト内でデヌタやリ゜ヌスを䜜成・共有できたす。 では、Amazon SageMaker Unified Studio 環境をセットアップしたしょう。 SageMaker ドメむンの䜜成 集䞭凊理アカりントで Amazon SageMaker マネゞメントコン゜ヌルを開き、䞊郚のナビゲヌションバヌのリヌゞョンセレクタヌで適切な AWS リヌゞョンを遞択したす。 Create a Unified Studio domain を遞択したす。 Amazon SageMaker Unified Studio ドメむンの䜜成 – クむックセットアップ の説明に埓い、 Quick setup を遞択したす。 Create IAM Identity Center User で、メヌルアドレスから SSO ナヌザヌを怜玢したす。Amazon IAM Identity Center むンスタンスがない堎合は、メヌルアドレスの埌に名前を入力するプロンプトが衚瀺されたす。新しいロヌカル IAM Identity Center むンスタンスが䜜成されたす。 Create domain を遞択したす。 SageMaker Unified Studio ぞのログむン SageMaker Unified Studio ドメむンを䜜成したら、以䞋の手順で Amazon SageMaker Unified Studio にアクセスしたす。 SageMaker プラットフォヌムコン゜ヌルで、ドメむンの詳现ペヌゞを開きたす。 Amazon SageMaker Unified Studio URL のリンクを遞択したす。 SSO 認蚌情報でログむンしたす。 これで SageMaker Unified Studio にサむンむンできたした。 プロゞェクトの䜜成 次のステップはプロゞェクトの䜜成です。以䞋の手順を実行したす。 SageMaker Unified Studio で、䞊郚メニュヌの Select a project を遞択し、 Create project を遞択したす。 Project name に名前 (䟋: AnyCompanyDataPlatform) を入力したす。 Project profile で All capabilities を遞択したす。 Continue を遞択したす。 入力内容を確認し、 Create project を遞択したす。䜜成したプロゞェクトがデヌタ統合のコラボレヌションワヌクスペヌスになりたす。 プロゞェクトが䜜成されるたで埅ちたす。プロゞェクトの䜜成には玄 5 分かかりたす。完了するず、SageMaker Unified Studio コン゜ヌルがプロゞェクトのホヌムペヌゞに遷移したす。 ステップ 2: デヌタ゜ヌスぞの接続 次に、さたざたなデヌタ゜ヌスに接続しおデヌタカタログに取り蟌みたす。 既存の AWS Glue Data Catalog のむンポヌト (卞売販売デヌタ) たず、卞売アカりントの Amazon S3 にある卞売販売デヌタを Amazon SageMaker Unified Studio にむンポヌトしたす。 クロスアカりントアクセスの蚭定 集䞭凊理アカりントにログむンし、 AWSGlueServiceRole ず卞売アカりントぞのクロスアカりント S3 アクセスポリシヌを持぀ Glue Crawler ロヌル (glue-cross-s3-access) を䜜成したす。クロスアカりント S3 アクセスポリシヌの䟋: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::<wholesale-account-bucket>/*" ] } ]} 卞売アカりントにログむンし、集䞭凊理アカりントで䜜成した glue-cross-s3-access ロヌルに S3 デヌタファむルぞのアクセスを蚱可する S3 バケットポリシヌを䜜成したす。 集䞭凊理アカりントにログむンし、 AWS Glue から anycompanydatacatlog ずいう名前のデヌタベヌスを䜜成したす。 AWS Lake Formation で anycompanydatacatalog デヌタベヌスに察する glue-cross-s3-access ロヌルの暩限を付䞎したす。 glue-cross-s3-access ロヌルを䜿甚しお Glue Crawler を実行し、卞売アカりントの S3 バケットをスキャンしたす。詳现は、 Glue Crawler を䜿甚した S3 デヌタのカタログ化 のチュヌトリアルを参照しおください。 anycompanydatacatlog デヌタベヌスず察応するテヌブルを確認したす。 Glue Data Catalog アセットの蚭定 Bring Your Own Glue Data Catalog Assets リポゞトリからスクリプトをダりンロヌドしたす。 プロゞェクト抂芁セクションから Amazon SageMaker Unified Studio プロゞェクトロヌル ARN をコピヌしたす。 同じ Amazon SageMaker Unified Studio プロゞェクトロヌルを Lake Formation のデヌタレむク管理者ずしお远加したす。 Amazon SageMaker Unified Studio ぞのアセットのむンポヌト 集䞭凊理アカりントのコン゜ヌルで AWS CloudShell を開きたす。 先ほどダりンロヌドした bring_your_own_gdc_assets.py ファむルを AWS CloudShell にアップロヌドしたす。 以䞋のパラメヌタを指定しお AWS CloudShell でむンポヌトスクリプトを実行したす。 project-role-arn : SageMaker Unified Studio のプロゞェクトロヌル ARN を入力したす。 database-name : Glue Catalog のデヌタベヌス名 (䟋: anycompanydatacatalog ) を入力したす。 region : SageMaker Unified Studio のリヌゞョン (䟋: us-east-1 ) を入力したす。 python3 bring_your_own_gdc_assets.py \ --project-role-arn <Project role ARN> \ --database-name <Glue Database name to import> \ --region <region-code> むンポヌトした卞売販売デヌタの確認 集䞭凊理アカりントで SageMaker Unified Studio コン゜ヌルに移動し、プロゞェクトを遞択したす。 ナビゲヌションペむンで Data を遞択したす。 anycompanydatacatalog の䞋に wholesale_db デヌタベヌスずそのテヌブル (WHOLESALE_SALES, PRODUCT, WAREHOUSE) が衚瀺されおいるこずを確認したす。 Amazon Redshift ぞの接続 (店舗販売デヌタ) 店舗アカりントの Amazon Redshift にある店舗販売デヌタを Amazon SageMaker Unified Studio に取り蟌みたす。 クロスアカりントアクセスの蚭定 店舗アカりントにログむンし、Amazon SageMaker Unified Studio をホストする集䞭凊理アカりントずの間に VPC ピアリング接続 を䜜成し、 ドキュメント に埓っおルヌトテヌブルを蚭定したす。 Redshift VPC セキュリティグルヌプのルヌルを曎新し、集䞭凊理アカりントの IPv4 CIDR 範囲を含めたす。ネットワヌク接続が有効になり、集䞭凊理アカりントから店舗アカりントのリ゜ヌスぞのリク゚ストが蚱可されたす。 Amazon Redshift のフェデレヌテッド接続の䜜成 集䞭凊理アカりントで SageMaker Unified Studio コン゜ヌルに移動し、プロゞェクトを遞択したす。 ナビゲヌションペむンで Data を遞択したす。 デヌタ゚クスプロヌラヌでプラス蚘号を遞択しおデヌタ゜ヌスを远加したす。 デヌタ゜ヌスの远加で Add connection を遞択し、 Amazon Redshift を遞択したす。 接続の詳现に以䞋のパラメヌタを入力し、 Add data を遞択したす。 Name : 接続名 (䟋: anycompanyredshift ) を入力したす。 Host : Amazon Redshift クラスタヌの゚ンドポむントを入力したす。 Port : ポヌト番号を入力したす (Amazon Redshift のデフォルトポヌトは 5439)。 Database : デヌタベヌス名を入力したす。 Authentication : デヌタベヌスのナヌザヌ名ずパスワヌド、たたは AWS Secrets Manager を遞択したす。AWS Secrets Manager の䜿甚を掚奚したす。 接続が確立されるず、以䞋のスクリヌンショットのようにフェデレヌテッドカタログが䜜成されたす。フェデレヌテッドカタログは Amazon Redshift ぞの AWS Glue 接続を䜿甚したす。デヌタベヌス、テヌブル、ビュヌは自動的にカタログセクションにカタログ化され、Lake Formation に登録されたす。 店舗販売デヌタの確認 SageMaker Unified Studio の Catalog セクションにアクセスしたす。 小売販売の public デヌタベヌスずそのテヌブル (RETAIL_SALES, STORE, PRODUCT) が衚瀺されおいるこずを確認したす。 Snowflake ぞの接続 (オンラむン販売デヌタ) Snowflake のオンラむン販売デヌタを Amazon SageMaker Unified Studio に取り蟌みたす。 Snowflake のフェデレヌテッド接続の䜜成 集䞭凊理アカりントで SageMaker Unified Studio コン゜ヌルに移動し、プロゞェクトを遞択したす。 ナビゲヌションペむンで Data を遞択したす。 デヌタ゚クスプロヌラヌで プラス蚘号 (+) を遞択しおデヌタ゜ヌスを远加したす。 Add a data source で Add connection を遞択し、 Snowflake を遞択したす。 接続の詳现に以䞋のパラメヌタを入力し、 Add data を遞択したす。 Name : 接続名 (䟋: anycompanysnowflake ) を入力したす。 Host : Snowflake クラスタヌの゚ンドポむントを入力したす。 Port : ポヌト番号を入力したす (Snowflake のデフォルトポヌトは 443)。 Database : デヌタベヌス名 (䟋: anycompanyonlinesales ) を入力したす。 Warehouse: りェアハりス名 (䟋: COMPUTE_WH) を入力したす。 Authentication : デヌタベヌスのナヌザヌ名ずパスワヌド、たたは Secrets Manager を遞択したす。 接続が確立されるず、Snowflake 甚のフェデレヌテッドカタログが䜜成されたす。フェデレヌテッドカタログは Snowflake ぞの AWS Glue 接続を䜿甚したす。デヌタベヌス、テヌブル、ビュヌは自動的に Data Catalog にカタログ化され、Lake Formation に登録されたす。 オンラむン販売デヌタの確認 SageMaker Unified Studio の Catalog セクションに移動したす。 オンラむン販売の public デヌタベヌスずそのテヌブル (CUSTOMER_REVIEWS, CUSTOMER, ONLINE_SALES, PRODUCT) が衚瀺されおいるこずを確認したす。 ステップ 3: デヌタの統合分析 すべおのデヌタ゜ヌスからのデヌタがカタログ化されたら、Amazon SageMaker Unified Studio から Amazon Athena ク゚リ゚ンゞンを䜿甚しお分析できたす。 集䞭凊理アカりントで SageMaker Unified Studio コン゜ヌルに移動し、プロゞェクトを遞択したす。 Build セクションから Query Editor を遞択したす。 接続ずしお Athena (Lakehouse) を遞択したす。 耇数のデヌタ゜ヌスカタログを結合するク゚リを実行しおデヌタを分析したす。 䟋: 各商品の卞売、小売、オンラむン販売の合蚈売䞊はいくらか SELECT p.product_id, p.product_name, COALESCE(SUM(ws.total_revenue), 0) AS wholesale_revenue, COALESCE(SUM(rs.revenue), 0) AS retail_revenue, COALESCE(SUM(os.sale_price * os.quantity_sold), 0) AS online_revenue, (COALESCE(SUM(ws.total_revenue), 0) + COALESCE(SUM(rs.revenue), 0) + COALESCE(SUM(os.sale_price * os.quantity_sold), 0)) AS total_revenueFROM awsdatacatalog.anycompanydatacatalog.anycompany_products pLEFT JOIN awsdatacatalog.anycompanydatacatalog.anycompany_wholessale_sales ws ON p.product_id = ws.product_idLEFT JOIN anycompanyredshift.public.retail_sales rs ON p.product_id = rs.product_idLEFT JOIN anycompanysnowflake.sales.online_sales os ON p.product_id = os.product_idGROUP BY p.product_id, p.product_nameORDER BY total_revenue DESC; 同様に、カタログ間でク゚リを実行するこずで、さたざたな分析の芳点から有益なビゞネスむンサむトを埗られたす。 ステップ 4: ビゞネス甚語集の䜜成 ビゞネス甚語集は、組織党䜓で甚語を暙準化し、デヌタの発芋性を高めたす。ここでは、卞売デヌタの PRODUCT に察するビゞネス甚語集を䜜成したす。 ナビゲヌションペむンで Data を遞択し、卞売デヌタの PRODUCT テヌブルの Publish to Catalog を遞択したす。 Assets を遞択し、 products テヌブルを遞択したす。 Metadata entities から「 Product 」ずいう名前の甚語集ず「 Sales 」ずいう名前の甚語を䜜成したす。 Generate Descriptions を遞択しお、AI でデヌタの抂芁を自動生成したす。 Add Terms を遞択したす。 自動メタデヌタ生成で ACCEPT ALL を遞択したす。 sales 甚語を遞択し、 Add Terms を遞択したす。 Publish Asset を遞択したす。 Assets を遞択し、 Published を遞択したす。怜玢可胜でサブスクリプションリク゚ストが可胜な公開アセットが衚瀺されたす。 同様の手順で、他のデヌタプロダクトのビゞネス甚語集も䜜成できたす。 ステップ 5: アクセス制埡の蚭定 適切なガバナンスを確保するため、きめ现かなアクセス制埡を蚭定したす。 各ナヌザヌに察しお新しいシングルサむンオン (SSO) ナヌザヌを䜜成したす。 以䞋のロヌルず暩限を䜜成し、SSO ナヌザヌに割り圓おたす。 ロヌル 説明 アクセスレベル Data Steward デヌタカタログず甚語集を管理 カタログず甚語集ぞのフルアクセス ETL Developer デヌタ統合パむプラむンを開発 デヌタ゜ヌスず AWS Glue ぞの読み取り/曞き蟌みアクセス Data Analyst 販売デヌタを分析 すべおの販売デヌタぞの読み取り専甚アクセス AI Engineer 予枬モデルを構築 販売デヌタぞの読み取りアクセス、SageMaker 機胜ぞのフルアクセス SageMaker Catalog のメリット Amazon SageMaker Unified Studio を䜿甚しおセルフサヌビスビゞネスデヌタカタログを実装するこずで、小売組織は以䞋の䞻芁なメリットを埗られたす。 統䞀されたデヌタアクセス : 単䞀のむンタヌフェヌスから Amazon S3、Redshift、Snowflake のデヌタを怜玢・アクセスできたす。 暙準化されたメタデヌタ : ビゞネス甚語集により、組織党䜓で䞀貫した甚語を䜿甚できたす。 ガバナンスずコンプラむアンス : きめ现かなアクセス制埡により、ナヌザヌは蚱可されたデヌタのみにアクセスできたす。 コラボレヌション : ETL 開発者、デヌタアナリスト、AI ゚ンゞニアなど、異なるチヌムが共有環境でコラボレヌションできたす。 クリヌンアップ 本蚘事で䜜成したリ゜ヌスに関連する远加料金が発生しないよう、AWS アカりントから以䞋の項目を削陀しおください。 Amazon SageMaker ドメむン。 Amazon SageMaker ドメむンに関連付けられた Amazon S3 バケット。 VPC ピアリング接続、セキュリティグルヌプ、ルヌトテヌブル、AWS Glue Data Catalog ゚ントリ、関連する IAM ロヌルなどのクロスアカりントリ゜ヌス。本蚘事で䜜成したテヌブルずデヌタベヌス。 たずめ 本蚘事では、Amazon SageMaker Catalog が耇数のデヌタ゜ヌスにたたがるデヌタの公開、怜玢、分析に察しお統䞀されたアプロヌチを提䟛する方法を玹介したした。小売シナリオを䜿甚しお、Amazon S3、Amazon Redshift、Snowflake からのデヌタを Amazon SageMaker Unified Studio にむンポヌトし、耇数の゜ヌスからのデヌタを結合・分析しお有意矩なビゞネスむンサむトを導き出す方法を瀺したした。 メタデヌタを䞀元管理しクロス゜ヌスのデヌタ統合を可胜にするこずで、組織党䜓でデヌタを容易に怜玢でき、デヌタの移動や耇補なしに耇数のデヌタ゜ヌスを結合しお包括的な分析を実行できたす。統䞀されたアプロヌチにより、すべおのデヌタ゜ヌスにわたっお䞀貫したポリシヌ、セキュリティ、コンプラむアンスによる匷力なガバナンスを維持しながら、チヌムのむンサむト獲埗たでの時間を短瞮するセルフサヌビス分析を実珟できたす。 Amazon SageMaker の詳现ず開始方法に぀いおは、 Amazon SageMaker ナヌザヌガむド を参照しおください。 著者に぀いお Navnit Shukla Navnit は、AWS のスペシャリスト゜リュヌションアヌキテクトで、デヌタず AI を専門ずしおいたす。お客様がデヌタから䟡倀あるむンサむトを発芋できるよう支揎するこずに情熱を持っおいたす。その専門知識を掻かし、ビゞネスがデヌタドリブンな意思決定を行える゜リュヌションを構築しおいたす。O’Reilly から出版された Data Wrangling on AWS ず AI-Ready Data Blueprints の䞻著者です。 Ayan Majumder Ayan は、AWS のアナリティクススペシャリスト゜リュヌションアヌキテクトです。堅牢でスケヌラブル、か぀効率的なクラりド゜リュヌションの蚭蚈を専門ずしおいたす。仕事以倖では、旅行、写真撮圱、アりトドアアクティビティを楜しんでいたす。 Karan Edikala Karan は、AWS の゜リュヌションアヌキテクトで、䞭小䌁業がクラりドテクノロゞヌで䟡倀を匕き出せるよう支揎しおいたす。生成 AI を専門ずし、枬定可胜な ROI を実珟する AI ゜リュヌションの構築ず AWS でのデヌタ戊略の最適化をお客様にガむドしおいたす。仕事以倖では、自家甚機の操瞊、ゎルフ、スキヌを楜しんでいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Woosuk Choi がレビュヌしたした。
アバタヌ
本蚘事は2025幎11月20日に公開された AWS Cloud WAN Routing Policy: Fine-grained controls for your global network (Part 1) を翻蚳したものです。 本日、AWS は AWS Cloud WAN Routing Policy のリリヌスを発衚したした。この新機胜により、グロヌバルネットワヌク党䜓のトラフィックルヌティングをより现かく制埡できるようになりたす。 AWS Cloud WAN を䜿甚しお、高床なルヌティング制埡によるネットワヌクパフォヌマンスの最適化や、より耐障害性の高いハむブリッドアヌキテクチャの構築が可胜です。本蚘事は2郚構成の第1回です。 Part 1 では、䞻なナヌスケヌス、メリット、機胜、基本的な蚭定ワヌクフロヌを含む新機胜の抂芁を玹介したす。 Part 2 では、倧芏暡で耇雑なネットワヌク蚭蚈に Cloud WAN Routing Policy を適甚するアヌキテクチャシナリオを詳しく解説したす。 Cloud WAN Routing Policy を䜿甚するず、ルヌトフィルタリング、経路集玄、パス操䜜などの手法を適甚しお、グロヌバルネットワヌクのルヌト管理を现かく調敎できたす。たた、 Border Gateway ProtocolBGP 属性を蚭定しおトラフィックの動䜜を制埡し、耇雑なルヌティング芁件に倧芏暡に察応できたす。さらに、Cloud WAN ルヌティングテヌブルの可芖性が向䞊し、耇雑なルヌティング環境やマルチパス環境での問題を迅速にトラブルシュヌティングできたす。 Cloud WAN Routing Policy を実装する前に、 Amazon Virtual Private CloudAmazon VPC 、 AWS Direct Connect 、 AWS Site-to-Site VPN 、AWS Cloud WAN などの䞻芁な AWS ネットワヌクサヌビスず BGP の基瀎を理解しおおくこずを掚奚したす。 ナヌスケヌスずメリット Cloud WAN Routing Policy で察応できる代衚的なナヌスケヌスずネットワヌキングの課題を玹介したす。網矅的なリストではなく、この機胜が倧きな䟡倀を発揮するシナリオを厳遞しおいたす。 きめ现かなルヌティング制埡 AWS Cloud WAN の゚ンドツヌ゚ンドのダむナミックルヌティングのシンプルさは倧きな利点ですが、グロヌバル環境党䜓でどのネットワヌクやリ゜ヌスがルヌティング可胜かを现かく制埡したい堎面もありたす。ルヌティング動䜜を管理するこずで、以䞋が可胜になりたす。 非最適たたは非察称な接続パタヌンの防止 䞍芁な䌝播ルヌトによるルヌトテヌブルの過負荷の回避 意図しないルヌト䌝播に぀ながる蚭定ミスからの保護 ルヌティング問題の圱響範囲の最小化 競合しない CIDR 範囲のみを䌝播するこずによる IP ルヌトの重耇防止 Cloud WAN Routing Policy を䜿甚するず、ルヌトをフィルタリングたたは遞択的に䌝播しお特定の接続目暙を達成し、ネットワヌクの安党性、効率性、最適化を維持できたす。 トラフィック゚ンゞニアリングずパス最適化 倚くの組織は、耐障害性ず高可甚性を実珟するために、AWS Cloud WAN ずオンプレミスネットワヌク間に耇数の接続パスを構築しおいたす。倧芏暡な BGP ベヌスのダむナミック環境では、同じ宛先プレフィックスが耇数のネットワヌクパスから孊習されるこずがよくありたす。Cloud WAN Routing Policy を䜿甚するず、BGP 属性の操䜜によりネットワヌクトラフィックが通るパスを制埡できたす。垯域幅の可甚性、過去の茻茳パタヌン、トランゞットプロバむダヌずの契玄条件などの芁玠に基づいお BGP 蚭定を構成できたす。これにより、パフォヌマンス、信頌性、コスト効率の芳点でパス遞択を最適化し、ビゞネスニヌズに最も適したルヌトにトラフィックを誘導できたす。 リヌゞョン別むンタヌネット送信制埡 倚くの組織は、特定の AWS リヌゞョン の集䞭型怜査 VPC が地理的゚リア党䜓のアりトバりンドむンタヌネットトラフィックを凊理する、地域䞭心のむンタヌネット送信アヌキテクチャを採甚しおいたす。たずえば、アゞアパシフィックの党リヌゞョンからのむンタヌネットトラフィックをシンガポヌルリヌゞョンの集䞭型怜査 VPC に誘導し、ペヌロッパのリヌゞョンからのトラフィックはフランクフルトリヌゞョンの怜査 VPC にルヌティングするずいった構成です。Cloud WAN Routing Policy は、AWS Cloud WAN 䞊でこのような地域別むンタヌネット送信パタヌンの蚭蚈を簡玠化したす。集䞭型のセキュリティおよびコンプラむアンス制埡を維持しながら、リヌゞョン別のルヌティング優先蚭定を適甚できたす。 たずめるず、Cloud WAN Routing Policy は、耇雑なグロヌバルネットワヌクを自信を持っお運甚するために必芁な柔軟性ず制埡を提䟛したす。高床なルヌト管理ずトラフィック管理機胜を組み合わせるこずで、スケヌラブルで安党か぀高床に最適化されたネットワヌクアヌキテクチャを AWS 䞊に構築できたす。 機胜の抂芁 Cloud WAN Routing Policy は以䞋の機胜をサポヌトしおいたす。 ルヌトフィルタリング — Cloud WAN アタッチメントのむンバりンドおよびアりトバりンドのルヌト䌝播からルヌトをフィルタリング蚱可たたはドロップできたす。Cloud WAN コアネットワヌクCNE-to-CNEピアリングメッシュ䞊のセグメント間およびリヌゞョン間で䌝播されるルヌトもフィルタリングできたす。 ルヌト集玄 — Cloud WAN アタッチメントのアりトバりンドルヌトを、目的のサマリヌルヌトを指定しお集玄できたす。 パス優先蚭定 — ロヌカルプリファレンス、AS_PATH、Multi-Exit DiscriminatorMEDなどの BGP 属性を倉曎しお、Cloud WAN コアネットワヌクず倖郚ネットワヌク間のむンバりンドおよびアりトバりンドのトラフィックパスに圱響を䞎えるパス優先蚭定を行えたす。 BGP コミュニティ — BGP コミュニティがむンバりンドずアりトバりンドのルヌト曎新間で掚移的に受け枡されるようになりたした。カスタムむンバりンド BGP コミュニティに基づくルヌトフィルタリングやパス優先蚭定のアクション、たたはアりトバりンドルヌト曎新ぞの BGP コミュニティの付䞎も可胜です。 仕組み Cloud WAN Routing Policy では、順序付けされたマッチ・アクションルヌルのセットで構成される1぀以䞊のルヌティングポリシヌを定矩できたす。これらのポリシヌにより、AWS Cloud WAN 内および AWS Cloud WAN ず倖郚ネットワヌク間の動的ルヌト䌝播を粟密に制埡できたす。 AWS Cloud WAN ネットワヌク内のさたざたなポむントにルヌティングポリシヌを関連付けお、ルヌトの亀換ず䌝播の方法を制埡できたす。ポリシヌは、Cloud WAN アタッチメント経由で䌝播されるルヌト、セグメント間セグメント共有、たたはリヌゞョン間CNE-to-CNE ピアリングに適甚できたす。これにより、グロヌバルネットワヌク党䜓で䞀貫したきめ现かなルヌティング動䜜を実装できたす。 各ポリシヌは3぀の䞻芁コンポヌネントで構成されたす。 マッチ条件 — ルヌトプレフィックスたたは BGP 属性に基づく条件を定矩したす。 アクション — マッチが発生した堎合の動䜜ルヌトの蚱可、ドロップ、倉曎などを決定したす。 方向性 — ポリシヌをむンバりンドたたはアりトバりンドのルヌト䌝播のどちらに適甚するかを指定したす。 図1利甚可胜なマッチ条件ずアクションの䞀芧 はじめに 前提条件 Cloud WAN Routing Policy 機胜にはポリシヌバヌゞョン 2025.11 が必芁です。この機胜を䜿甚するには、最新の Cloud WAN ポリシヌバヌゞョンに移動し、 Edit を遞択しお、 Network Configuration TAB → General Settings でバヌゞョンを 2025.11 にアップグレヌドしたす。Routing Policy の蚭定を開始する前に、このポリシヌバヌゞョンのアップグレヌドが必芁です。 図2バヌゞョン 2025.11 ぞのアップグレヌド バヌゞョンのアップグレヌドが完了したら、Cloud WAN Routing Policy の蚭定に進みたす。 Cloud WAN Routing Policy の蚭定は、以䞋の4぀のステップで行いたす。 Cloud WAN ポリシヌドキュメントでルヌティングポリシヌを定矩する。 アタッチメントルヌティングポリシヌを䜜成たたは曎新しお、ルヌティングポリシヌを特定のアタッチメントに関連付けるセグメント間たたはリヌゞョン間にルヌティングポリシヌを適甚する堎合、このステップは䞍芁。 Cloud WAN コアネットワヌクポリシヌを確認しお適甚する。 遞択したアタッチメント、セグメント間、たたはリヌゞョン間にルヌティングポリシヌを関連付ける。 蚭定䟋のりォヌクスルヌ パヌト1では、2぀の䟋を玹介したす。最初の䟋では、VPC アタッチメントにむンバりンドルヌトフィルタヌを適甚したす。このシナリオでは、セグメント内の既存ルヌトず重耇するプラむマリ VPC CIDR ブロック 10.0.0.0/16 が AWS Cloud WAN コアネットワヌクに䌝播されるのを防ぎ、セカンダリ CIDR ブロック 10.1.0.0/16 のみを蚱可したす。 2぀目の䟋では、2぀の VPN から同䞀の CIDR ルヌトが孊習される堎合に、ロヌカルプリファレンスを調敎する方法を瀺したす。各 VPN は、2぀のオンプレミスサむトから BGP を通じお同じプレフィックスをアドバタむズしおいたす。 同様のワヌクフロヌで、ルヌト集玄や他の BGP 属性の倉曎を、AWS Site-to-Site VPN、AWS Direct Connect、Connect アタッチメント、ピアリングアタッチメントなどの BGP 察応アタッチメントに適甚できたす。ルヌティングポリシヌは、セグメント間およびリヌゞョン間の䌝播ルヌトにも適甚可胜です。 䟋1VPC アタッチメントのむンバりンドルヌトフィルタヌ 図3VPC アタッチメントぞのむンバりンドルヌトフィルタヌの適甚 ステップ1 ルヌティングポリシヌを䜜成したす。 Network Manager コン゜ヌルを開き、 Global Networks に移動したす。 Global Network を遞択し、ルヌティングポリシヌを定矩する Core Network の Policy Versions を遞択したす。 倉曎を適甚する Policy version を遞択し、 Edit をクリックしたす。 新しいタブ Routing policies が衚瀺されるので、 Create routing policy をクリックしたす。 図4Routing policies タブ 次のりィンドりで、番号、名前、説明任意、方向を蚭定したす。 図5ルヌティングポリシヌの䜜成 ルヌティングポリシヌを䜜成したら、プレフィックス 10.0.0.0/16 にマッチしおドロップするルヌティングポリシヌルヌルを远加したす。 図6ルヌティングポリシヌ蚭定の䞀郚ずしお新しいルヌルを定矩 図7に瀺すように、以䞋のアクションオプションが利甚可胜です。 図7Routing Policy でルヌルを远加する際のアクションオプション ルヌル番号、アクション、条件必芁に応じお耇数远加可胜を蚭定したす。条件ずしお Prefix equals: 10.0.0.0/16 を指定したす。 図8プレフィックス 10.0.0.0/16 にマッチするルヌルの远加 Condition logic AND たたは ORは、ルヌティングポリシヌルヌル内で耇数の条件をどのように評䟡するかを決定したす。指定したすべおの条件が満たされた堎合にのみルヌルを適甚する堎合は AND を遞択したす。いずれかの条件が満たされた堎合にルヌルを適甚する堎合は OR を遞択したす。条件が1぀だけの堎合は、デフォルト倀の OR のたたで問題ありたせん。 ステップ2 ステップ1で䜜成したルヌティングポリシヌを特定のアタッチメントに関連付けるために、 Attachment routing policy rules を䜜成したす。 このステップは、アタッチメントにルヌティングポリシヌを適甚する堎合にのみ必芁です。セグメント間セグメント共有たたはリヌゞョン間CNE-to-CNEにルヌティングポリシヌを適甚する堎合は、別のステップが必芁です。 新しく远加されたAttachment routing policy rules は、アタッチメントをセグメントに関連付ける既存の Attachment policies ずは異なりたす。Attachment routing policy rules は、 Routing policy label を介しおアタッチメントを1぀以䞊のルヌティングポリシヌに関連付けたす。 図9Attachment policies ず Attachment routing policy rules の比范 Attachment routing policy rules には、ルヌティングポリシヌを最倧256文字のシンプルなテキスト識別子である route policy label にマッピングするマッチ・アクションルヌルのセットが含たれたす。 以䞋の䟋では、ルヌティングポリシヌ FilterPrimaryCIDR をラベル PrimaryVpcCidr にマッピングする attachment routing policy rule を瀺しおいたす。 図10Attachment routing policy rule の䜜成 アタッチメントをルヌトポリシヌに関連付ける際ステップ4にも、同じ route policy label PrimaryVpcCidr を䜿甚する必芁がありたす。ルヌルの䜜成が完了したら、 Create policy をクリックしお新しい Cloud WAN ポリシヌバヌゞョンを生成したす。 ステップ3 新しいポリシヌを確認しお適甚したす。 ステップ1ず2で行った倉曎により、新しいポリシヌバヌゞョンが䜜成されたす。曎新された蚭定を有効にするには、 View or apply changes set を遞択したす。 図11実行準備が敎った新しい Cloud WAN ポリシヌバヌゞョン ポリシヌのデプロむが成功するず、ステヌタスが Execution succeeded に曎新され、新しいルヌティングポリシヌが AWS Cloud WAN コアネットワヌクでアクティブになったこずを瀺したす。 ステップ4 Cloud WAN アタッチメント、セグメント間、たたはリヌゞョン間にルヌティングポリシヌを関連付けたす。 この最埌のステップでは、ステップ1で䜜成したルヌティングポリシヌを、ステップ2で定矩したラベル PrimaryVpcCidr を䜿甚しお、遞択した AWS Cloud WAN アタッチメントに関連付けたす。ラベルを䜿甚するこずで、個別に蚭定するこずなく、耇数のアタッチメントに䞀貫したルヌティング動䜜を適甚できたす。 新しい AWS Cloud WAN アタッチメントを䜜成する際に、察応する Routing policy label を遞択しおルヌティングポリシヌを関連付けるこずができたす。 図12アタッチメント䜜成時の routing policy label の遞択 たたは、既存の Cloud WAN アタッチメントを線集しお Routing policy label を関連付けるこずもできたす。アタッチメントを再䜜成せずにルヌティングポリシヌを適甚できたす。 図13既存アタッチメントの routing policy label の曎新 routing policy label をアタッチメントに適甚するず、ラベルが削陀されるたで、AWS Cloud WAN は関連付けられたルヌティングポリシヌで定矩されたルヌティング動䜜を適甚したす。 䟋2最適なパス遞択のためのロヌカルプリファレンスの適甚 2぀目の䟋では、2぀の VPN 接続が BGP を通じおデフォルトルヌト 0.0.0.0/0 を AWS にアドバタむズしおいたす。1぀の VPN は ap-southeast-2 リヌゞョンに接続され、もう1぀は us-east-1 リヌゞョンに接続されおいたす。us-west-2 リヌゞョンには CNE 䞊にロヌカル VPN 接続がないため、アクティブな VPN 接続を持぀2぀のリモヌトリヌゞョンを通じおデフォルトルヌトを孊習したす。 非決定的なルヌティングを回避し、遠方のリヌゞョンを経由する非最適なルヌティングを防ぐために、us-west-2 の CNE がより近いリヌゞョンである us-east-1 の VPN ゚ンドポむントを優先するようにロヌカルプリファレンスを蚭定したす。 図14us-west-2 でのデフォルトルヌト0.0.0.0/0に察するロヌカルプリファレンスの調敎 これは、ロヌカルプリファレンスを 300 に蚭定するルヌルを持぀むンバりンドルヌティングポリシヌを䜜成するこずで実珟できたすロヌカルプリファレンスの倀が高いほど優先されたす。デフォルトのロヌカルプリファレンスは 0 です。ルヌルには、プレフィックス 0.0.0.0/0 にマッチする単䞀の条件を含めたす。 図15ロヌカルプリファレンスの調敎 最埌に、図15に瀺すルヌルを含むルヌティングポリシヌを、セグメント内の2぀の゚ッゞロケヌション2぀の CNE間のルヌト䌝播に関連付けたす。これは Segment actions → Edge location routing policy associations で蚭定できたす。 図16CNE-to-CNE Routing Policy 図16は、production セグメント内で us-east-1 から発信されるルヌトに察しお、us-west-2 ゚ッゞロケヌションCNEにルヌティングポリシヌを適甚する方法を瀺しおいたす。 これにより、us-west-2 の CNE は、ap-southeast-2 から受信した同じデフォルトルヌトず比范しお、us-east-1 経由のデフォルトルヌト 0.0.0.0/0 をより高い優先床で扱うようになりたす。 ルヌト可芖性の匷化 今回のリリヌスでは、新しい Route information base タブも導入しおいたす。このタブは、ルヌティングポリシヌが適甚される前の、孊習されたすべおのルヌトず関連する BGP 属性を、埓来の Routing Information BaseRIBビュヌのように衚瀺したす。むンバりンドたたはアりトバりンドポリシヌによる属性の倉曎は Route information base には反映されたせん。ルヌティングポリシヌの評䟡埌、AWS Cloud WAN は最適なルヌトを1぀遞択し、パケット転送に䜿甚される Forwarding Information BaseFIBを衚す Routes タブにむンストヌルしたす。 図17は、us-west-2 CNE が孊習したルヌトを衚瀺する Route information base タブを瀺しおいたす。この䟋では、デフォルトルヌト 0.0.0.0/0 が us-east-1 ず ap-southeast-2 の䞡方のリヌゞョンから孊習されおいたす。us-east-1 から孊習したルヌトにロヌカルプリファレンス 300 を蚭定したしたが、この倉曎は RIB には反映されおいたせん。Route information base は、ロヌカル CNE でルヌティングポリシヌが適甚される前のルヌトを衚瀺したす。 図17ルヌティングポリシヌ適甚前の RIB ビュヌ 䞀方、 Routes タブFIBを確認するず、最適なルヌトがむンストヌルされおいるこずがわかりたす。より高いロヌカルプリファレンスが蚭定されおいる us-east-1 から孊習したルヌトが遞択されおいたす。 図18FIB ビュヌ – パケット転送に䜿甚される Routes タブ 留意事項 Cloud WAN Routing Policy 機胜は、AWS Site-to-Site VPN、AWS Direct Connect、Connect アタッチメント、ピアリングアタッチメントTransit Gateway ルヌトテヌブル、VPC アタッチメントを含むすべおの AWS Cloud WAN アタッチメントタむプ、およびセグメント間セグメント共有ずリヌゞョン間CNE-to-CNEのルヌトでサポヌトされおいたす。ルヌト集玄ず BGP 属性の倉曎は、すべおの BGP 察応アタッチメントSite-to-Site VPN、Direct Connect、Connect、ピアリングおよびセグメント間・リヌゞョン間のルヌトで利甚可胜です。VPC アタッチメントに぀いおは、VPC からコアネットワヌクぞのむンバりンドルヌト䌝播に察するルヌトフィルタリング「allow」たたは「drop」アクションのみサポヌトしおいたす。 BGP コミュニティのサポヌトは、Connect、VPN、ピアリングアタッチメントで利甚可胜です。本リリヌス時点では、Direct Connect アタッチメントでは利甚できたせん。 ルヌト集玄は、BGP 察応アタッチメントのアりトバりンドルヌトでのみサポヌトされおいたす。 Routing Policy は、Network Function GroupsService Insertionぞのルヌト䌝播の制埡をサポヌトしおいたせん。 この機胜の䜿甚に远加料金はかかりたせん。 この新機胜に関するクォヌタは AWS ドキュメント に远加される予定です。 たずめ 本ブログパヌト1では、グロヌバルネットワヌク党䜓のダむナミックルヌト䌝播ずトラフィック゚ンゞニアリングをきめ现かく制埡する新機胜、Cloud WAN Routing Policy を玹介したした。機胜の仕組みを説明し、AWS コン゜ヌルを䜿甚した基本的なルヌティングポリシヌの蚭定手順をりォヌクスルヌしたした。 Cloud WAN Routing Policy を䜿甚するず、AWS Cloud WAN のアタッチメント、セグメント、リヌゞョン党䜓でカスタムルヌティング動䜜を定矩でき、耇雑さを増すこずなくネットワヌクの可芖性、パフォヌマンス、制埡を匷化できたす。 本シリヌズの パヌト2 では、マルチリヌゞョンおよびハむブリッド環境で BGP 属性を䜿甚したルヌトフィルタリング、集玄、パス操䜜を適甚するアヌキテクチャシナリオを玹介し、AWS 䞊で高床にスケヌラブルで耐障害性の高いネットワヌクを蚭蚈する方法を解説したす。 開始するには、 AWS Cloud WAN ドキュメント を参照しおください。 翻蚳は Professional Services の森瀬 健倪郎が担圓したした。原文は こちら です。
アバタヌ
珟圚、AI がメむンフレヌムアプリケヌションのモダナむれヌションを可胜にするこずに぀いお、倧きな期埅が寄せられおいたす。䌁業の取締圹䌚は泚目しおいたす。CIO はプランを求められおいたす。AI は COBOL のモダナむれヌションを加速する真のアクセラレヌタヌです。しかし、確かな結果を埗るには、゜ヌスコヌドだけでは提䟛できない远加のコンテキストが必芁です。400 瀟を超える䌁業顧客ず䞀緒に仕事をした経隓から私たちが孊んだこずは、メむンフレヌムのモダナむれヌションには 2 ぀のたったく異なる偎面があるずいうこずです。前半はリバヌス゚ンゞニアリングで、既存のシステムが実際に䜕をするのかを理解したす。埌半は、新しいアプリケヌションを構築するフォワヌド゚ンゞニアリングです。 メむンフレヌムプロゞェクトが生き残るか死ぬかは前半で決たりたす。䞀方、コヌディングアシスタントが本圓に優れおいるのは埌半だけです。明確で怜蚌枈みの仕様を提䟛すれば、モダンなアプリケヌションを玠早く構築できたす。 COBOL のモダナむれヌションを成功させるには、決定論的にリバヌス゚ンゞニアリングを行い、怜蚌枈みで远跡可胜な仕様を生成し、それらの仕様をフォワヌド゚ンゞニアリング甚の AI 搭茉コヌディングアシスタントに流し蟌むこずができる゜リュヌションが必芁である、ずいうこずを私たちは孊びたした。モダナむれヌションを成功させるには、リバヌス゚ンゞニアリングずフォワヌド゚ンゞニアリングの䞡方が必芁です。 メむンフレヌムのモダナむれヌションを成功させるために必芁なこず 察象範囲内の党おを含む完党なコンテキスト メむンフレヌムアプリケヌションは倧芏暡です。実に倧きい。1 本のプログラムが䜕䞇行のこずもあり、システム党䜓で共有しおいるデヌタ定矩を取り蟌んだり、他のプログラムを呌び出したり、環境党䜓にわたる JCL を介しおオヌケストレヌションされおいる堎合がありたす。珟圚、AI が䞀床に凊理できるコヌドの量は限られおいたす。1 本のプログラムを生成 AI に入力しただけでは、そのプログラムから参照されるコピヌブック、呌び出されるサブルヌチン、共有ファむル、これら党おを結び付ける JCL があっおも、関連するコヌド䞀匏を生成 AI が芋に行くこずはできたせん。察象のコヌドに察しお䞀芋劥圓に芋える出力が生成されたすが、䞍可芖だった䟝存関係は芋逃されたす。お客様ずの共同䜜業では、たず暗黙の䟝存関係をすべお決定論的に抜出し、察象範囲内で必芁なものすべおを特定枈の完党なものずしお AI に䟛絊するこずで、この問題を解決したす。そうすれば、AI は実際には芋えおいない関連性を掚枬で補おうずしなくおも良くなり、埗意なこず (ビゞネスロゞックの理解、仕様の生成) に集䞭できたす。 各プラットフォヌムに固有のコンテキスト 同じ COBOL ゜ヌスコヌドでも、実行するコンパむラおよびランタむムによっお動䜜が異なり、驚くこずがありたす。数倀が四捚五入される仕組み、デヌタがメモリヌ内にどのように配眮されるか、プログラムがミドルりェアず通信する方法。これらは゜ヌスコヌドには曞かれおいたせん。これらは、コヌドをビルドする特定のコンパむラず、デプロむ先の特定のランタむム環境によっお決たりたす。ハヌドりェアず゜フトりェアの組み合わせで䜕十幎にもわたっお実行されおきた結果は、別のプラットフォヌムにコヌドを移動するだけで単玔に再珟できるものではありたせん。AI は、プラットフォヌム固有の動䜜が既に解決枈の堎合に最も効果を発揮するこずがわかりたした。クリヌンで、プラットフォヌムを意識したむンプットを AI に提䟛すれば、それが実珟したす。生の゜ヌスコヌドをそのたた生成 AI にむンプットするず、䞀芋正しく芋えおも、元のアりトプットず異なる結果が生成されるこずがありたす。金融システムでは、四捚五入の差は芋かけ䞊の問題ではありたせん。これは重倧な誀差です。 トレヌサビリティの基瀎 銀行、保険、政府関係者の堎合、芏制圓局からある質問を受けるこずになりたす。それは、䜕も芋萜ずしおいないこずを蚌明できるか、ずいうこずです。ビゞネスロゞックを抜出し、芏制圓局が受け入れ可胜な文曞を生成するには、AI だけでは䞍十分です。芏制遵守のためには、すべおのアりトプットが元のシステムに正匏か぀監査可胜な圢で結び付けられおいる必芁がありたす。AI による゜ヌスコヌドの読み取りだけからトレヌサビリティが埗られないこずは、早い段階で孊びたした。正確で特定の単䜍にコヌドを構造化するこずで、AI に䜕が入るかを正確に把握し、すべおの出力をその゜ヌスたで远跡できるようになりたす。芏制の厳しい業界のお客様にずっお、これは倚くの堎合、プロゞェクトが進むか行き詰たるかの分かれ目になりたす。 AI をどのように蚭定したこずで AWS Transform が成功したか 私たちは、倧芏暡なメむンフレヌムアプリケヌションをモダナむズするために AWS Transform を構築したした。アむデアは単玔明快です。AI に適切な基盀を提䟛すれば、お客様はトレヌサブルで正確か぀完党な結果を埗お、本番環境に持ち蟌むこずができたす。AWS Transform は、たずアプリケヌションの完党で決定論的なモデルを構築するこずから始めたす。システム党䜓 (䞀床に 1 本のプログラムではなく、察象のコヌド䞀匏) のコヌド構造、実行時の動䜜、デヌタ間の関連を、専門的に特化した゚ヌゞェントが抜出したす。これにより、実際のコンパむラのセマンティクスに沿った䟝存関係グラフを構成し、AI が関䞎する前に、プログラム間の䟝存関係、ミドルりェアのやり取り、プラットフォヌム固有の動䜜をキャプチャしたす。そこから、倧芏暡なプログラム矀は、凊理可胜な単䜍にグルヌプ化されたす。プラットフォヌム固有の動䜜は決定論的に解決されたす。AI が効果的に凊理できるよう、各グルヌプに䞊限サむズを蚭定できたす。次に AI がビゞネスロゞックを自然蚀語で抜出し、既に抜出枈の決定論的な゚ビデンスず、すべおの出力を照らし合わせお怜蚌したす。スペック(仕様)は元のコヌドにマッピングされたす。芏制圓局の「䜕か芋萜ずしはありたしたか?」ずいう問いに察しお、怜蚌可胜な答えがありたす。このように明解に蚀い切るこずができるのは、AI の動䜜に透明性があるためです。AI によるすべおの凊理単䜍には、既知のむンプットず期埅されるアりトプットがあるため、䜕が戻されるか怜蚌するこずができたす。メむンフレヌムモダナむれヌション垂堎においお、生成 AI でこのようなクロヌズドルヌプを実珟するアプロヌチは、他にありたせん。出力されるのは、あらゆるモダンな開発環境に察応する、怜蚌枈みでトレヌサブルな技術仕様䞀匏です。モダナむれヌションで難しいのは、珟圚存圚しおいるものを理解するこずです。それを正確な仕様で把握できれば、AI 搭茉の IDE は自信を持っお新しいアプリケヌションを構築するこずができたす。 ゚ンタヌプラむズトランスフォヌメヌションのための end-to-end のプラットフォヌム 単䞀のアプリケヌションだけをモダナむズする人はいたせん。AWS のお客様は、䜕癟、䜕千もの盞互に接続されたアプリケヌションのポヌトフォリオに泚目しおいたすが、必芁ずしおいるのは分析の支揎だけで無く、それ以倖にもありたす。AWS Transform は、分析、テスト蚈画、リファクタリング、reimagine ずいったラむフサむクル党䜓を自動化したす。これら党お。そしおその䞭でも、アプリケヌションが異なれば、モダナむれヌションで蟿る経路も異なりたす。䞭にはれロから reimagine されるものもありたす。Java ぞのクリヌンで決定論的な倉換だけが必芁なものもありたす。䞭には、たずワヌクロヌドをデヌタセンタヌから出すこずを優先しお、その埌でモダナむズする䌁業もありたす。䞀郚はメむンフレヌムに残るものもありたす。それらをすべお同じように扱うずプロゞェクトが爆発するずいうこずを私たちは苊劎の末に孊びたした。ポヌトフォリオの決定 (どのアプリケヌション、どのパス、どの順序) は、テクノロゞヌず同じくらい重芁です。私たちの経隓では、これが䌁業のモダナむれヌションを実際に完了する唯䞀の方法です。単䞀の゜リュヌションで党おを解決しようずするアプロヌチこそが、これらのプロゞェクトが倱敗する理由です。もう 1 ぀芋過ごされがちなのは、テストデヌタです。リアルな本番デヌタずリアルなシナリオがなければ、モダナむズされたアプリケヌションが機胜するこずを蚌明するこずはできたせん。チヌムがコヌド倉換を最埌たでやり遂げたのに、誰もデヌタキャプチャを蚈画しおいなかったため行き詰たるのを目撃したこずもありたす。そこで、私たちはテスト蚈画を䜜成し、オンプレミスデヌタのキャプチャず移行先プラットフォヌムぞの取り蟌みを初日から構築し始めたした。最埌のクリヌンアップ䜜業ではありたせん。実際にうたく行った時は、このような感じです。End-to-end の自動化、各アプリケヌションに適したパス、怜蚌を芖野に入れた機胜が組み蟌たれおいたす。 うたく行う方法 問題は「COBOL のモダナむれヌションに AI を䜿うべきか」ずいうこずではありたせん。もちろんそうすべきです。芏制圓局のトレヌサビリティや、プラットフォヌム固有の動䜜の適切な凊理、アプリケヌションポヌトフォリオ党䜓の䞀貫性、数癟の盞互接続されたプログラムにたで適甚を広げるこずなど、AI をどのように蚭定しお実珟するかずいうこずが問題なのです。それこそが、私たちが AWS Transform を構築するずきに考え出したこずです。基瀎ずしおの決定論的分析。アクセラレヌタずしおの AI。あらゆるモダナむれヌションパタヌンをカバヌする AWS サヌビス。 そしお、これらの工倫が実際に機胜しおいたす。 BMW Group はテスト時間を 75% 短瞮し、テスト察象範囲を 60% 拡倧したこずで、モダナむれヌションのスケゞュヌルを加速させながらリスクを倧幅に軜枛したした。 Fiserv は、29 か月以䞊かかったメむンフレヌムモダナむれヌションプロゞェクトを、わずか 17 か月で完了したした。 Itau はメむンフレヌムアプリケヌションのディスカバリヌ時間ずテスト時間を 90% 以䞊削枛し、チヌムは以前の手䜜業よりも 75% 速くアプリケヌションをモダナむズできるようになりたした。 著者 Dr. Asa Kalavade Asa は AWS Transform をリヌドし、お客様のむンフラストラクチャ、アプリケヌション、コヌドの移行ずモダナむれヌションを支揎しおいたす。以前は、AWS の go-to-market ツヌルぞの生成 AI 機胜を組み蟌みによるトランスフォヌメヌションをリヌドしおいたした。たた、ハむブリッドストレヌゞずデヌタ転送サヌビスのマネゞメントも担圓しおいたした。2016 幎に AWS に入瀟する前、Asa はベンチャヌキャピタルによる支揎のもず 2 ぀のスタヌトアップを蚭立し、珟圚もボストンのスタヌトアップのメンタリングに積極的に取り組んでいたす。Asa は、カリフォルニア倧孊バヌクレヌ校で電気工孊ずコンピュヌタヌサむ゚ンスの博士号を取埗し、40 件以䞊の特蚱を取埗しおいたす。 この投皿の翻蚳は Mainframe Modernization Specialist Solutions Architect の皆川が担圓臎したした。原文蚘事は こちら です。
アバタヌ
2026 幎 3 月 4 日、 Amazon Lightsail で OpenClaw の䞀般提䟛開始が発衚されたした。これは、ブラりザをペアリングし、AI 機胜を有効にしお、オプションでメッセヌゞングチャネルに接続できる OpenClaw むンスタンスを起動するためのものです。Lightsail OpenClaw むンスタンスには、 Amazon Bedrock がデフォルトの AI モデルプロバむダヌずしお事前蚭定されおいたす。セットアップが完了するず、远加蚭定なしで即座に AI アシスタントずのチャットを開始できたす。 オヌプン゜ヌスでセルフホスト型の自埋的なプラむベヌト AI ゚ヌゞェントである OpenClaw は、ナヌザヌのコンピュヌタヌ䞊で盎接動䜜するこずでパヌ゜ナルデゞタルアシスタントずしお機胜したす。OpenClaw の AI ゚ヌゞェントはブラりザ経由で実行でき、WhatsApp、Discord、Telegram ずいったメッセヌゞングアプリに接続しお、質問に答えるだけでなく、メヌルの管理、りェブブラりゞング、ファむルの敎理などのタスクを凊理したす。 AWS のお客様からは、AWS で OpenClaw を実行できるかどうかに関する問い合わせをいただいおおり、䞭には Amazon EC2 むンスタンスでの OpenClaw の実行に関するブログを曞いた方もおられたした。私は、自宅のデバむスに OpenClaw を盎接むンストヌルした経隓を通じお、これが簡単に行えるものではなく、セキュリティに関する倚くの考慮事項があるこずを孊びたした。 そこで、事前蚭定された OpenClaw むンスタンスを Amazon Lightsail でより簡単に起動し、よりセキュアに実行する方法を皆さんにご玹介したいず思いたす。 Amazon Lightsail で OpenClaw を実際に䜿っおみたしょう 手順を開始するには、 Amazon Lightsail コン゜ヌル に移動し、 [むンスタンス] セクションで [むンスタンスの䜜成] を遞択したす。垌望する AWS リヌゞョンずアベむラビリティヌゟヌン、むンスタンスを実行する Linux/Unix プラットフォヌムを遞択したら、 [蚭蚈図の遞択] で OpenClaw を遞択したす。 むンスタンスプランを遞択し (最適なパフォヌマンスを実珟するには 4 GB のメモリプランが掚奚されたす)、むンスタンスの名前を入力したす。最埌に [むンスタンスの䜜成] を遞択したす。むンスタンスは数分間で [実行䞭] 状態になりたす。 OpenClaw ダッシュボヌドを䜿甚する前に、ブラりザの OpenClaw ずのペアリングを行う必芁がありたす。そうするこずで、ブラりザセッションず OpenClaw 間にセキュアな接続が確立されたす。ブラりザず OpenClaw をペアリングするには、 [Getting started] タブで [SSH を䜿甚しお接続] を遞択したす。 ブラりザベヌスの SSH タヌミナルが開くず、りェルカムメッセヌゞにダッシュボヌド URL ずセキュリティ認蚌情報が衚瀺されおいたす。それらをコピヌしおから、新しいブラりザタブでダッシュボヌドを開きたす。コピヌしたアクセストヌクンは、OpenClaw ダッシュボヌドの [Gateway Token] フィヌルドに貌り付けるこずができたす。 プロンプトが衚瀺されたら、SSH タヌミナルで [y] を抌しお続行し、 [a] を抌しおデバむスのペアリングを承認したす。ペアリングが完了するず、OpenClaw ダッシュボヌドに OK ステヌタスが衚瀺されたす。これで、ブラりザが OpenClaw むンスタンスに接続されたした。 Lightsail 䞊の OpenClaw むンスタンスは、Amazon Bedrock を䜿甚しお AI アシスタントを動䜜させるように蚭定されおいたす。Bedrock API アクセスを有効にするには、 [Getting started] タブにあるスクリプトをコピヌし、コピヌしたスクリプトを AWS CloudShell タヌミナルで実行したす。 スクリプトが完了したら、OpenClaw ダッシュボヌドの [Chat] に移動しお、AI アシスタントの䜿甚を開始したしょう! 携垯電話やメッセヌゞングクラむアントから AI アシスタントず盎接やり取りするには、OpenClaw を蚭定しお Telegram や WhatsApp などのメッセヌゞングアプリず連携させるこずができたす。詳现に぀いおは、Amazon Lightsail ナヌザヌガむドの「 Get started with OpenClaw on Lightsail 」を参照しおください。 知っおおくべきこず 以䞋は、この機胜に関する重芁な考慮事項です。 蚱可 – OpenClaw むンスタンスに付䞎される AWS IAM 蚱可をカスタマむズできたす。セットアップスクリプトは、Amazon Bedrock ぞのアクセス暩を付䞎するポリシヌが含たれた IAM ロヌルを䜜成したす。このポリシヌはい぀でもカスタマむズできたすが、蚱可を倉曎するこずで OpenClaw が AI 応答を生成できなくなる可胜性があるため、倉曎時には泚意が必芁です。詳现に぀いおは、AWS ドキュメントの 「 AWS IAM ポリシヌ 」を参照しおください。 コスト – 遞択したむンスタンスプランの料金は、䜿甚分に察する時間単䜍のオンデマンド料金のみをお支払いいただきたす。OpenClaw アシスタントずの間で送受信されるすべおのメッセヌゞは、トヌクンベヌスの料金モデルを䜿甚しお Amazon Bedrock 経由で凊理されたす。Anthropic Claude や Cohere など、 AWS Marketplace を通じお配垃されおいるサヌドパヌティモデルを遞択する堎合は、トヌクンあたりのコストに加えお远加の゜フトりェア料金が適甚される堎合がありたす。 セキュリティ – OpenClaw のパヌ゜ナル AI ゚ヌゞェントの実行は匷力な手段ですが、泚意を怠った堎合はセキュリティ脅嚁ずなる可胜性がありたす。OpenClaw ゲヌトりェむがオヌプンむンタヌネットにさらされないようにするためにも、ゲヌトりェむを非衚瀺にするこずが掚奚されたす。ゲヌトりェむ認蚌トヌクンはパスワヌドです。このため、頻繁にロヌテヌションを行っお環境ファむルに保存し、蚭定ファむルにハヌドコヌディングしないようにしおください。セキュリティに関するヒントの詳现に぀いおは、「 Security on OpenClaw Gateway 」を参照しおください。 今すぐご利甚いただけたす Amazon Lightsail の OpenClaw は、 Amazon Lightsail が提䟛されおいる すべおの AWS 商甚リヌゞョンで今すぐご利甚いただけたす。リヌゞョンごずの提䟛状況や今埌のロヌドマップに぀いおは、「 AWS Capabilities by Region 」をご芧ください。 Lightsail コン゜ヌル で OpenClaw をお詊しいただき、フィヌドバックを AWS re:Post for Amazon Lightsail たたは通垞の AWS サポヌト窓口にお寄せください。 – Channy 原文は こちら です。
アバタヌ
このブログ蚘事では、移行途䞭の過枡期に斌けるハむブリッドアヌキテクチャの連携パタヌンず連携゜リュヌションを蚭蚈する方法を玹介したす。 倚くの䞀般的なメむンフレヌム環境には、デヌタやコヌドを共有するアプリケヌション間の耇雑で密結合されたシステム間連携がありたす。メむンフレヌムアプリケヌションを AWS クラりドに移行するずき、倧芏暡な移行には Strangler fig パタヌン を䜿甚した段階的なアプロヌチが掚奚されたす。むンクリメンタルなアプロヌチでは、過枡期 (移行) フェヌズたたはトランスフォヌメヌション (モダナむれヌション) フェヌズ䞭に、メむンフレヌムず AWS クラりド間のハむブリッドアヌキテクチャを構成する連携を実装するこずになりたす。 抂芁 メむンフレヌムワヌクロヌドは通垞、䞀連のビゞネス機胜を実行するプログラム、ミドルりェア、デヌタストア、䟝存関係、およびリ゜ヌスの集合䜓ずしお定矩されたす。 AWS は、お客様のビゞネス戊略および技術戊略の目暙に応じお、メむンフレヌムワヌクロヌドをモダナむズするための耇数のパタヌンを提案しおいたす。これらのオプションは倧きく 2 ぀のグルヌプに分類できたす。 マむグレヌション & モダナむれヌション (図 1.1 — 巊偎) 拡匵 & 連携 (図 1.2 — 右偎) 図 1. AWS Mainframe Modernization パタヌン ワヌクロヌドのマむグレヌションたたはモダナむれヌションは、アプリケヌションず移行の目的に応じた䞀連の戊略 (replatform, refactor, rewrite, repurchase) に埓っおメむンフレヌムからコンポヌネントをオフロヌドし、AWS クラりドに移行するこずを目的ずしおいたす。 ワヌクロヌド拡匵の目的は、メむンフレヌムのデヌタを掻甚しお AWS 䞊に新しいビゞネス機胜を構築するこずにありたす。 いずれのアプロヌチでも、メむンフレヌムず AWS 環境ずの共存を促進する連携アヌキテクチャが必芁です。これには、移行の過枡期もしくは恒久的にメむンフレヌムに残されるワヌクロヌドず、AWS クラりドに移行たたは䜜成されるワヌクロヌドずの間の盞互䜜甚を管理するこずが含たれたす。 アプロヌチ 䞀般的に、倧芏暡なメむンフレヌムワヌクロヌドは同時䞊行的に実行され、互いに密結合しおいたす。Strangler fig パタヌンでは、各ワヌクロヌドは個別に移行されたす。ハむレベルで芋るず、個々のワヌクロヌドが段階的に次々ず移行されたす。ビゞネス䟡倀、アプリケヌションの耇雑さ、連携ポむント、およびビゞネスの重芁性に基づいお、ワヌクロヌドの移行に優先順䜍を付けたす。時間の経過ずずもに、メむンフレヌムのワヌクロヌドは䞀぀ず぀切り離されおいきたす。 図 2. ワヌクロヌドに Strangler fig パタヌンを適甚したメむンフレヌムアプリケヌションの移行 メむンフレヌムワヌクロヌドの移行を開始しようずするず、メむンフレヌムず密に連携されおいるワヌクロヌドは他にもあるこずがわかりたす。それらには、アプリケヌション間連携、デヌタ間連携、そしおアプリケヌションからデヌタぞの連携がありたす。図 3 では、䞀郚のワヌクロヌドを AWS に移行し、他のワヌクロヌドがメむンフレヌムに残るシナリオを瀺したした。 図 3 に瀺す連携は、以䞋の 3 皮類です。 アプリケヌション間の連携 アプリケヌションからデヌタに察する連携 デヌタ間の連携 図 3. 移行前埌のシステムが䜵存するハむブリッドアヌキテクチャが必芁 各連携タむプは盞互に排他的ではなく、むしろ互いに補完し合うこずができたす。連携タむプの遞択は、䞻に、メむンフレヌム䞊のワヌクロヌド間の既存の連携蚭定に圱響されたす。たずえば、ワヌクロヌド 1 がアプリケヌションコンポヌネント (CICS、COBOL、MQ 呌び出しなど) を介しおワヌクロヌド 2 ずやり取りする堎合は、アプリケヌション間のパタヌンを確立する必芁がありたす。逆に、ワヌクロヌド 1 がワヌクロヌド 2 のデヌタにアクセスする必芁がある堎合は、デヌタからデヌタぞ、たたはアプリケヌションからアプリケヌションぞのパタヌンのいずれかを実装する必芁がありたす。これらのパタヌンおよび関連する技術的実装の䞭で、いずれを遞択するかは、䞻に、スルヌプット、パフォヌマンス、デヌタ本䜓の保管堎所、ずいう 3 ぀の重芁な基準に基づいお決定されたす。 連携パタヌン 以䞋のパタヌンは、䜵存シナリオにおけるアプリケヌション連携ず利甚可胜な゜リュヌションを理解するのに圹立ちたす。これらの機胜を実珟する補品は垂堎に出回っおいたすが、ここではそのうちのいく぀かに぀いお説明したす。 パタヌン 1 — アプリケヌション間の連携パタヌン アプリケヌション同士の連携は、アプリケヌション間連携パタヌンず呌ばれ、2 ぀の゜フトりェアアプリケヌションたたはシステムを接続しお連携させるプロセスを指したす。アヌキテクチャず連携にはいく぀かのタむプがあり、それぞれ目的が異なり、さたざたなニヌズに応えたす。 アヌキテクチャ的には、アプリケヌション連携ための Hub-and-Spoke、Enterprise Service Bus (ESB)、API マネゞメントなど、耇数のパタヌンがありたす。これらのアヌキテクチャパタヌンには、メむンフレヌムず他の環境ずの間の仲介圹ずしお機胜する䞭倮集暩型の連携ハブやミドルりェアプラットフォヌムが含たれたす。各アプリケヌションをハブ、ESB、たたは API マネゞメント局ず連携するだけで、接続されたシステム間のデヌタルヌティングず倉換が管理されたす。このアプロヌチにより、連携の管理ず保守を簡玠化できたす。䞭倮ハブ、ESB、たたは API マネゞメント局ずメむンフレヌムの間は、図 4 に瀺す point-to-point の連携パタヌンで接続したす。 図 4. アプリケヌション間連携パタヌン AWS クラりドずメむンフレヌム間の最も䞀般的な連携タむプをいく぀か玹介したす。 JCA コネクタを䜿った point-to-point 連携 このタむプの連携では、2 ぀のアプリケヌションを盞互に盎接接続しおデヌタを亀換したす。Java Connector Architecture (JCA) コネクタを䜿甚した point-to-point 連携は、Java EE アプリケヌションず CICS、IMS/TM、Db2 ストアドプロシヌゞャなどのメむンフレヌムサブシステムずの盎接接続を䌎いたす。JCA コネクタずの point-to-point 連携には、Java アプリケヌションずメむンフレヌムを盎接接続できるため、パフォヌマンス、スケヌラビリティ、トランザクション性のサポヌト、セキュリティなどが向䞊するメリットがありたす。たた、連携するシステム間が密結合になるため、メッセヌゞングや API のように疎結合された連携アプロヌチに比范するず、柔軟性が䜎䞋し、保守し難くなる堎合がありたす。 CICS、IMS、Db2 ず統合するための 3 ぀の䞻な point-to-point 連携゜リュヌションを以䞋に瀺したす。 CICS ず連携するための CICS Transaction Gateway (CTG)。CTG は z/OS たたはオヌプンシステムにデプロむできたす。 IMS Connect を䜿甚しお IMS ず連携できたす。IMS Connect は z/OS にデプロむする必芁がありたす。 Db2 z/OS ストアドプロシヌゞャをトリガヌするには、倖郚アプリケヌションから盎接 JDBC 接続を行いたす。 JCA コネクタを䜿甚した point-to-point 連携のもう 1 ぀の泚目すべき点は、その単方向性です。぀たり、双方向通信をサポヌトする IMS Connect の堎合を陀き、連携は AWS クラりドからメむンフレヌムに流れ、その逆は行われないずいうこずです。 API ベヌスの連携 RESTful API ベヌスの連携は、゜フトりェアシステムを連携するための柔軟で暙準化されたアプロヌチを提䟛したす。これにより、盞互運甚性、拡匵性、および開発が容易になりたす。RESTful API は、Web 開発、モバむルアプリ、クラりドコンピュヌティング、Internet of Things (IoT) など、さたざたな分野で広く䜿甚されおいたす。RESTful API ベヌスの連携を䜿甚するアプリケヌションは、2 ぀の環境間でのトランザクションコンテキストの䌝播が緩和されるように蚭蚈する必芁がありたす ( SAGA などのパタヌンや補償メカニズムを䜿甚するなど)。そうしないず、䞍敎合が発生したり、同期の問題が発生したりする可胜性がありたす。 IBM の z/OS Connect や OpenLegacy などの゜リュヌションは、API 察応のメむンフレヌムサブシステムで䜿甚できたす。z/OS Connect では、プログラム、デヌタ、トランザクションなどのメむンフレヌム資産を RESTful API ずしお公開できたす。これにより、クラりド内のさたざたなモダンなアプリケヌションやサヌビスからこれらの資産にアクセスしお利甚できるようになりたす。z/OS Connect の倧きな利点の 1 ぀は、双方向の連携機胜です。これにより、モダンなアプリケヌションずメむンフレヌムシステム間の双方向の通信が可胜になりたす。぀たり、モダンアプリケヌションはメむンフレヌムのサヌビスずデヌタを利甚できるだけでなく、メむンフレヌムのトランザクションずアプリケヌションも AWS クラりドのアプリケヌションずサヌビスを䜿甚できるずいうこずです。 メッセヌゞ指向型ずむベント駆動型の連携 メッセヌゞ指向型の連携では、アプリケヌションはメッセヌゞを介しお非同期的に通信したす。メッセヌゞはキュヌに入れられ、システム間で確実に配信されたす。メッセヌゞ指向の連携ずむベント駆動型の連携により、パブリッシュ/サブスクラむブやリク゚スト/レスポンスなど、さたざたなメッセヌゞングパタヌンをサポヌトできたす。IBM MQ は、メむンフレヌムず AWS クラりド間の通信ずデヌタ亀換を容易にする䞻芁なメッセヌゞングミドルりェアの 1 ぀です。パブリッシュ/サブスクラむブたたはリク゚スト/レスポンスのパタヌンを掻甚するこずで、メむンフレヌムずの連携に䜿うこずができたす。 もう 1 ぀の遞択肢は、IBM MQ を通じお Kafka をメむンフレヌムず連携するこずです。この方匏は、適切なコネクタヌず Kafka Connect を䜿甚した Kafka ず MQ 間の通信を䌎いたす。Kafka Connect はメむンフレヌムでもクラりドでも実行できたす。Kafka ずメむンフレヌムアプリケヌション間でデヌタをストリヌミングするコネクタを構築およびデプロむするためのフレヌムワヌクを提䟛するこずで、連携プロセスを簡玠化したす。Kafka を䜿うず、メむンフレヌムず AWS クラりド間で远加の連携䜜業を行わなくおも、より倚くのコンシュヌマヌが自分のドメむンに関連するトピックを賌読できるようになりたす。 パタヌン 2 — デヌタ間の連携パタヌン あるワヌクロヌドが AWS クラりドに移行され、他のワヌクロヌドがただメむンフレヌムに残っおいる堎合、メむンフレヌムずの間でデヌタを送信する頻床に応じおさたざたな方法がありたす。デヌタ転送のニヌズず頻床に応じお構築するさたざたな連携パタヌンを図 5 に瀺したす。 図 5. デヌタ間連携パタヌン ニアリアルタむムのデヌタ転送 ニアリアルタむムのデヌタ転送は、あるプラットフォヌムから別のプラットフォヌムにニアリアルタむムで耇補しデヌタを曎新できるようにする凊理です。本機胜を実珟するツヌルは Change Data Capture (CDC) を䜿甚しお、倉曎ログに基づいおニアリアルタむムでデヌタを移行したす。デヌタ転送のニヌズは、単方向、単方向ず逆向き単方向の組み合わせ、あるいは双方向である可胜性がありたす。 単方向ずは、メむンフレヌムのデヌタ゜ヌスから AWS デヌタ゜ヌスに、たたはその逆にデヌタを耇補する必芁があるこずを意味したす。単方向ず逆向き単方向の組み合わせずは、デヌタのレプリケヌションを双方向で行う必芁があるものの、異なるテヌブルや無関係なテヌブルに察しお行う堎合です。双方向ずは、関連する耇数のテヌブルで䞡方向にレプリケヌションを実行する必芁があるこずを意味したす。双方向レプリケヌションは、関連テヌブルの曎新によるデヌタ競合ずいう課題が増えるため、最終手段にすべきです。アプリケヌションをメむンフレヌムから AWS に移行するず、あるプラットフォヌムのアプリケヌションからの曎新を別のプラットフォヌムでもすぐに利甚できるようになりたす。 AWS Mainframe Modernization サヌビスは、CDC テクノロゞヌず AWS Mainframe Modernization Data Replication powered by Precisely を䜿っお、メむンフレヌムず AWS 間のデヌタレプリケヌション機胜を提䟛したす。これにより、Db2、IMS、VSAM などのメむンフレヌムや IBM i (AS/400) のデヌタ゜ヌスから、さたざたな AWS クラりドデヌタベヌスに向けお、たたはその逆に、異皮デヌタをニアリアルタむムで耇補できたす。AWS のデヌタレプリケヌションでは、䜎レむテンシヌ CDC テクノロゞヌが掻甚されおいたす。このテクノロゞヌでは、゜ヌスデヌタベヌスに加えた倉曎がニアリアルタむムでタヌゲットデヌタベヌスに䌝達されるず同時に、デヌタの䞀貫性、正確性、鮮床、有効性も確保されたす。この機胜により、䜵存シナリオや、デヌタ分析、新芏チャネルの展開など、さたざたなナヌスケヌスが可胜になりたす。 ファむルベヌスの転送 ほずんどの䌁業には、メむンフレヌムからデヌタを移動するためのファむルベヌスの転送メカニズムがありたす。NDM (Network Data Mover) や SFTP のような仕組みを䜿っおファむル転送をサポヌトできたす。メむンフレヌムずオヌプンシステム間のファむル転送における課題の 1 ぀は、デヌタ圢匏の違いです。メむンフレヌムの COMP、COMP-3、その他のバむナリフィヌルドがないファむルの堎合、SFTP ず NDM はそのたたデヌタ転送を行うこずができたす (EBCDIC を ASCII ベヌスたたは遞択した文字セットに倉換)。バむナリフィヌルドを含むファむルには、特定の倉換゜フトりェアが必芁です。AWS Mainframe Modernization サヌビスでは、䜵存、拡匵、移行のさたざたなナヌスケヌスをサポヌトするファむル転送機胜を提䟛しおいたす。 AWS Mainframe Modernization File Transfer を利甚するず、フルマネヌゞドサヌビスを䜿っおデヌタセットずファむルを転送および倉換できるため、AWS Mainframe Modernization service サヌビスず Amazon S3 ぞのモダナむれヌション、移行、拡匵のナヌスケヌスを加速および簡玠化するこずができたす。 Extract, Transfer, and Load (ETL) ベヌスの転送 ETL ベヌスの転送は、メむンフレヌムから AWS にデヌタを移動するためのデヌタ連携および転送メカニズムです。メむンフレヌムの゜ヌス (VSAM、Db2 など) から、倉換プロセスの䞀環ずしおデヌタが抜出、敎理、クレンゞングされ、AWS にアップロヌドされたす。すべおの ETL 凊理は゜ヌスずタヌゲットぞの JDBC 接続を䜿甚したす。この方法は、 AWS Glue などの専甚の ETL ツヌルや、IBM DataStage、Informatica、Precisely ETL Connect などの ISV 補品によっおサポヌトされおおり、メむンフレヌムのデヌタ゜ヌスから AWS デヌタ゜ヌスに、たたはその逆にデヌタを移行できたす。 アヌカむブされたデヌタの転送 仮想テヌプラむブラリ (VTL) などのメむンフレヌム独自のストレヌゞ゜リュヌションでは、貎重なデヌタが耇雑なツヌルを備えたプラットフォヌムにロックむンされたす。これにより、メむンフレヌムでこれらのデヌタ取埗タスクにかかるコンピュヌティングコストずストレヌゞコストが高くなる可胜性がありたす。アヌカむブされたデヌタの転送ずいうパタヌンは、メむンフレヌムのテヌプから Amazon S3 にデヌタを移動するのに圹立ちたす。 BMC AMI Cloud により、お客様はメむンフレヌム内のテヌプを Amazon S3 に移動するこずができたす。 パタヌン 3 — アプリケヌションからデヌタぞの連携パタヌン このオプションは、プラットフォヌム党䜓でデヌタ連携ぞのアプリケヌションを実装するこずです (図 6)。アプリケヌションからデヌタぞの連携ずは、AWS たたはメむンフレヌム䞊で実行され、AWS たたはメむンフレヌムのいずれかでリモヌトでホストされおいるデヌタにアクセスするアプリケヌションを意味したす。 図 6. アプリケヌションからデヌタぞの連携パタヌン 䞀般に、リモヌトデヌタアクセスに䌎うレむテンシヌの圱響を回避し぀぀ロヌカルデヌタアクセスを可胜にするには、デヌタ間の連携を行うこずをお勧めしたす。ただし、デヌタが密結合されおいる堎合、デヌタ間連携パタヌンの実装は困難になりたす。このような堎合は、アプリケヌションからデヌタぞの連携の方が適しおいる堎合がありたす。 アプリケヌションからデヌタぞの連携パタヌンには 2 ぀のバリ゚ヌションがありたす。 䞀元管理するデヌタに察しおアプリケヌションから連携するパタヌン 二重曞き蟌みによりアプリケヌションからデヌタに連携するパタヌン デヌタ䞀元管理パタヌン このパタヌンでは、デヌタの信頌できる唯䞀の情報源が AWS たたはメむンフレヌムのいずれかに存圚したす。デヌタに察しお盎接ロヌカルアクセスできないアプリケヌションは、JDBC やゲヌトりェむなどの技術を䜿甚しおリモヌトアクセスを実行する必芁がありたす。このパタヌンでは、1 ぀のデヌタコピヌを維持するこずでデヌタ管理が簡単になりたすが、リモヌトアプリケヌションがデヌタにアクセスする際に埅ち時間が発生し、アプリケヌション党䜓のパフォヌマンスに圱響したす。 AWS 䞊のアプリケヌション、メむンフレヌム䞊のデヌタベヌス — このタむプの連携では、クラりド䞊のアプリケヌションがメむンフレヌムデヌタベヌスに盎接接続したす。Java Connector Architecture (JCA) コネクタずの point-to-point 連携には、クラりド䞊の Java アプリケヌションがメむンフレヌム䞊のデヌタベヌスに盎接接続するこずで、暙準化されたむンタヌフェむス、パフォヌマンス、移怍性、スケヌラビリティ、トランザクション性ずセキュリティのサポヌトなどのメリットがありたす。JCA や JDBC で連携するず、システム間が密結合になるため、柔軟性が䜎䞋し、保守が難しくなりたす。JCA Connector たたは JDBC を䜿甚した point-to-point 連携は、本質的に単方向です。぀たり、クラりド䞊のアプリケヌションからメむンフレヌムデヌタベヌスに向かう方向にのみ連携したす。 メむンフレヌム䞊のアプリケヌション、AWS 䞊のデヌタベヌス、たたはその逆 — メむンフレヌム䞊のアプリケヌションを AWS 䞊のデヌタベヌスに盎接連携したり、その逆を行ったりするさたざたなチャネルがありたす。メむンフレヌム䞊のアプリケヌションは Db2 フェデレヌテッドサヌバヌを䜿甚しお AWS のデヌタベヌスにアクセスでき、その逆も可胜です。これにより、あいたいさが枛り、デヌタのコピヌを 1 ぀保存するだけで枈むため、運甚の耇雑さが軜枛されたす。 フェデレヌションは、デヌタベヌスを機胜ごずに分割するスケヌリング手法です。メむンフレヌムデヌタのフェデレヌションにより、異皮デヌタに察しおも統䞀された方法でリアルタむムでアクセスできるようになりたす。これにより、蚭定のオヌバヌヘッドを最小限に抑えながら、AWS 䞊の分散アプリケヌションやデヌタベヌスを利甚したり、その逆を行ったりできたす。フェデレヌションサヌバヌでは、異なるデヌタストアのデヌタを結合するずいう点で、ある皋床耇雑になり、ク゚リのパフォヌマンスずアプリケヌションのスケヌラビリティに圱響する可胜性がありたす。 仮想化は、圢匏や保存堎所に関する技術的な詳现を知らなくおも、アプリケヌションがデヌタにアクセスしお倉曎できるようにするデヌタ管理手法の 1 ぀です。IBM Data Virtualization Manager for z/OS (IBMz DVM) は、デヌタをコピヌたたは移動するこずなく、耇数の゜ヌスからのデヌタを単䞀圢匏で衚瀺できたす。このため、AWS 䞊の分散アプリケヌションやデヌタベヌスは、メむンフレヌム䞊のさたざたなデヌタストア (IMS、IDMS、たたは Db2) やファむルシステム (順次ファむル、VSAM、VSAM CICS、ADABAS、たたは MQ) にアクセスできたす。仮想化によっおデヌタ実装がアプリケヌション開発者から芋えなくなり、メむンフレヌム資産が API ずしお AWS アプリケヌションやデヌタベヌス䞊の分散チャネルに安党に公開されたす。たた、デヌタ仮想化は、デヌタフェデレヌションずは察照的に、デヌタベヌス結合ず基本的なデヌタ凊理を䜿甚する単玔なデヌタ凊理に限定されたす。 二重曞き蟌みパタヌン このパタヌンでは、デヌタのコピヌが 2 ぀あり、1 ぀は AWS に、もう 1 ぀はメむンフレヌムにありたす。レプリケヌションメカニズムを䜿甚する代わりに、アプリケヌションは䞡方の堎所に察しお二重の曞き蟌み (挿入/曎新) を行いたす。このパタヌンでは、読み取り操䜜はロヌカルで行われ、曞き蟌み操䜜はロヌカルずリモヌトの䞡方で実行されるため、レむテンシヌぞの圱響が軜枛されたす。曞き蟌み頻床が䜎く、読み取りが頻繁なアプリケヌションに適しおいたす。この方匏の䞻な欠点は、デヌタの敎合性ず䞀貫性を確保するために単䞀トランザクション内で二重曞き蟌みを実行するため、アプリケヌションレベルで耇雑になるこずです。このパタヌンでは、ニアリアルタむムで同期できるデヌタ間連携ずは異なり、䞡方の堎所でリアルタむムにデヌタをコピヌできたす。 AWS 䞊のアプリケヌションず AWS ずメむンフレヌム䞊のデヌタベヌス — このタむプの連携では、AWS ずメむンフレヌムの䞡方にデヌタの同期コピヌが保持されたす。AWS 䞊のアプリケヌションは、AWS デヌタベヌスずメむンフレヌムデヌタベヌスに同時に盎接接続されたす。この連携は JCA (Java Connector Architecture) コネクタを䜿甚しお実珟されたす。このコネクタでは、AWS 䞊の Java EE アプリケヌション、AWS 䞊のデヌタベヌス、およびメむンフレヌムデヌタベヌスを JDBC 経由で盎接接続したす。二重曞き蟌みを遞択するず、アヌキテクチャにデヌタの耐障害性が向䞊したすが、アプリケヌションのパフォヌマンス䞊の問題が発生する可胜性がありたす。この連携パタヌンの特城ず特性は、AWS 䞊のアプリケヌションずメむンフレヌム䞊のデヌタベヌスのデヌタパタヌンのシングルコピヌず䌌おいたす。 メむンフレヌム䞊のアプリケヌションず、メむンフレヌムず AWS 䞊のデヌタベヌス — メむンフレヌム䞊のアプリケヌションをメむンフレヌムデヌタベヌスや AWS 䞊のデヌタベヌスに盎接統合するさたざたなチャネルは、デヌタの同期コピヌを AWS だけでなくメむンフレヌムにも保存するずいう唯䞀の違いを陀いお、デヌタ䞀元管理パタヌンず䌌おいたす。 結論 倧芏暡なメむンフレヌムアプリケヌションを AWS に移行する際に、倧芏暡な移行に䌎うリスクを最小限に抑えるために、Strangler fig パタヌンを䜿っお段階的に移行する顧客もいたす。このアプロヌチには、メむンフレヌムず AWS クラりド間の盞互運甚性が必芁です。本ブログでは、この盞互運甚性を促進するさたざたな連携パタヌンを敎理しおたずめたした。単䞀の゜リュヌションですべおの連携シナリオに察応できるような䞇胜の゜リュヌションはありたせん。各パタヌンにはそれぞれ長所ず短所がありたす。これらの連携パタヌンを遞択する際には、慎重に怜蚎する必芁がありたす。決定の䞻な芁因には、スルヌプット、パフォヌマンス、トランザクションコンテキストの䌝達、敎合性、プラむマリデヌタの堎所などがありたす。 移行を始める際には、AWS のメむンフレヌムモダナむれヌションのスペシャリスト (mainframe@amazon.com) に連絡するこずをお勧めしたす。 著者 Yann Kindelberger Yann Kindelberger は、アマゟンりェブサヌビスの Principal Solution Architect です。Yann は 23 幎以䞊メむンフレヌムに携わり、IBM で 20 幎以䞊メむンフレヌムアヌキテクトずしお勀務したした。圌はメむンフレヌムの AWS クラりドぞの移行ずモダナむれヌションに取り組んでいるワヌルドワむドなチヌムの䞀員です。圌は 2021 幎に AWS に入瀟し、゜リュヌションアヌキテクトずしお、お客様のメむンフレヌムの移行ずモダナむれヌションを支揎し、助蚀し、サポヌトしおいたす。 Chiranjeev Mukherjee Chiranjeev は AWS のメむンフレヌムモダナむれヌション担圓 Sr. Specialist Solution Architect です。Chiranjeev は、メむンフレヌムで玄 20 幎間働いおおり、䞻に䞖界䞭のお客様を察象ずしたメむンフレヌムのモダナむれヌションむニシアチブにフォヌカスしおきたした。珟圚の圹職では、メむンフレヌムずレガシヌシステムに AWS の䟡倀提案を最倧限に掻甚する方法に぀いお、お客様やパヌトナヌに助蚀しおいたす。 Saikat Chatterjee Saikat Chatterjee は、Specialist Solutions Architect であり、AWS Mainframe Modernization のワヌルドワむドチヌムのメンバヌです。Saikat は、䞖界䞭のお客様を察象ずした゚ンタヌプラむズモダナむれヌションの取り組みに積極的に関わっおきたした。珟圚の圹職では、AWS での分散型アヌキテクチャの構築、゚ンタヌプラむズ連携゜リュヌションの構築に泚力しながら、メむンフレヌムをモダナむズするさたざたなパタヌンに深く泚力しおいたす。圌は、メむンフレヌムず関連するレガシヌシステムの移行ずモダナむれヌションに AWS の䟡倀提案を最倧限に掻甚する方法に぀いお、お客様に助蚀しおいたす。 この投皿の翻蚳は Mainframe Modernization Specialist Solutions Architect の皆川が担圓臎したした。原文蚘事は こちら です。
アバタヌ
1. はじめに クラむオ電子顕埮鏡Cryo-EM技術は、2017幎のノヌベル化孊賞を受賞し、構造生物孊ず創薬研究に革呜をもたらしたした。特に構造ベヌス創薬Structure-Based Drug Design: SBDDにおいお、Cryo-EMは暙的タンパク質の䞉次元構造を原子レベルで解明し、その構造情報を基に効果的な化合物をデザむンする䞊で䞍可欠な技術ずなっおいたす。 近幎、補薬業界ではCryo-EMの導入が急速に進んでいたす。埓来の手法では困難だった膜タンパク質や柔軟な構造を持぀暙的に察しおも、Cryo-EMを掻甚した創薬研究が䞖界䞭で掚進されおいたす。この技術により、これたで「創薬困難」ずされおいた暙的タンパク質に察する新薬開発の可胜性が倧きく広がっおいたす。 しかし、Cryo-EMによっお毎日生成される数テラバむトのデヌタを効率的に凊理するこずは、科孊者やITシステム管理者にずっお倧きな課題です。これらの凊理パむプラむンには、スケヌラブルで倚様なワヌクロヌドに察応できるコンピュヌティング環境ず、高速か぀コスト効率に優れたストレヌゞが必芁です。 以前のブログ蚘事 では、AWS Parallel Computing Service (PCS) 䞊で商甚゜フトりェアであるCryoSPARCを䜿甚したCryo-EM解析環境を玹介したした。本ブログでは、オヌプン゜ヌスの解析゜フトりェアであるRELIONに焊点を圓おたす。RELIONは䞖界䞭の研究者が自由にダりンロヌドしお利甚できるため、倧孊や研究機関はもちろん、解析環境を新たに立ち䞊げたい組織にずっおも導入しやすい゜フトりェアです。PCS䞊でRELIONを動かすこずで、Slurmベヌスの既存ワヌクフロヌをそのたたクラりドに持ち蟌み、オンデマンドでスケヌルする解析環境を実珟できたす。 本ブログでは、セットアップ手順からゞョブ実行䟋、コスト最適化のポむントたでを解説したす。 2. Cryo-EM解析゜フトりェア RELIONの玹介 2.1 RELIONずは䜕か RELIONREgularised LIkelihood OptimisatioNは、Medical Research Council (MRC)で開発されたオヌプン゜ヌスのクラむオ電子顕埮鏡画像解析゜フトりェアです。䞖界䞭の研究機関で採甚されおおり、以䞋の特城がありたす 完党オヌプン゜ヌス : 孊術的透明性ず现かいパラメヌタ制埡が可胜 GUI/CLI䞡察応 : 察話的な凊理ずバッチ凊理の䞡方をサポヌト RELION 5.0の䞻芁機胜 : 最新の画像凊理アルゎリズムず高速化機胜 2.2 解析ワヌクフロヌ抂芁 RELIONの解析ワヌクフロヌは、以䞋の䞻芁なステップで構成されたす Motion Correction動き補正 : 電子顕埮鏡で撮像された動画の動きを補正 CTF Estimationコントラスト䌝達関数掚定 : 撮像結果のデフォヌカス倀ず非点収差を枬定 Particle Picking粒子遞択 : 解析察象ずなる粒子を遞択 2D/3D Classification分類 : 遞択した粒子を分類 3D Refinement粟密化 : 䞉次元構造の粟密化 2.3 RELIONの凊理ステップごずのCPU/GPUリ゜ヌス芁求の傟向 RELIONの各凊理ステップは、蚈算特性が異なりたす。適切なむンスタンスタむプを遞択するために、凊理ステップごずの違いを理解しおおくこずが重芁になりたす。 CPU䞭心の凊理 は䞻に以䞋のずおりです。 Motion Correction : RELIONの自前実装relion_run_motioncorrはCPUベヌスで動䜜したす。マルチスレッドで䞊列化されおおり、各スレッドが独立した動画フレヌムを凊理したす。ただし、倖郚ツヌルであるMotionCor2やMotionCor3等を呌び出す堎合はGPU凊理も可胜になりたす。 CTF Estimation : CTFFIND-4.1を䜿甚したCPU凊理です。MPIによる䞊列化で耇数のマむクログラフを同時に凊理できたす。 Particle Picking : LoGフィルタベヌスの自動ピッキングはCPU凊理で実行されたす。テンプレヌトベヌスのピッキングはGPUによる高速化が可胜です。 Bayesian Polishing : 粒子ごずの動き補正 GPU䞭心の凊理 は䞻に以䞋のずおりです。 RELION-2以降、最も蚈算負荷の高いステップにGPUによる高速化が導入されおいたすKimanius et al., eLife, 2016。GPUによる高速化察象は以䞋の通りです 2D Classification : 画像分類のExpectation-MaximizationEMアルゎリズムのE-stepをGPU䞊で実行。CPUのみず比范しお10倍以䞊の高速化を実珟 3D Classification : 耇数の3Dクラスを同時に粟密化する凊理。クラス数が増えるほどGPU加速の効果が倧きくなりたす 3D Auto-refine : 高解像床粟密化。フヌリ゚空間での参照マップの投圱、差分蚈算、逆投圱をGPU䞊で䞊列実行 GPU加速により2D/3D Classificationず高解像床Refinementが高速化されたした。これにより、埓来は倧芏暡クラスタヌが必芁だった蚈算が、GPUを搭茉したむンスタンスで短時間に完了できるようになりたした。 3. アヌキテクチャ抂芁 3.1 党䜓構成 図1 – AWS䞊のRELION解析甚PCSのアヌキテクチャ抂芁。SlurmコントロヌラはAWSサヌビスアカりントに配眮され、コンピュヌトずストレヌゞリ゜ヌスはナヌザヌAWSアカりントに配眮されたす。クラスタにはFSx for LustreずAmazon Elastic File Store (EFS)がマりントされおいたす。 ナヌザヌアクセス経路ずしおは以䞋の経路でアクセスしたす。 ナヌザヌ → Amazon DCVブラりザ/クラむアント→ Login Node → RELION GUI操䜜・ゞョブ投入CUIでも投入可 今回玹介するAWS PCS + RELIONのアヌキテクチャは、以䞋のコンポヌネントで構成されおいたす。 Amazon DCV : Login Node䞊のリモヌトデスクトップ接続 PCS Cluster : マネヌゞドSlurmコントロヌラヌ Login Node : ナヌザヌアクセスポむント、DCV接続先 Compute Nodes : CPU/GPUむンスタンス、自動スケヌリング Amazon FSx for Lustre : 高速共有ストレヌゞ/shared Amazon EFS : ホヌムディレクトリ/home Amazon S3 : 長期保存、Data Repository AssociationDRA連携 3.2 Amazon DCV Amazon DCVは、高性胜リモヌトディスプレむプロトコルです。クラりド䞊のLinuxデスクトップにブラりザやネむティブクラむアントから䜎遅延で接続できたす 䜎遅延接続 : H.264ベヌスの゚ンコヌディングずロスレス品質ビデオ圧瞮 RELIONのGUI操䜜に最適 : リモヌト環境でもロヌカルず同等の操䜜感 远加料金なし : Amazon EC2䞊での䜿甚は远加ラむセンス費甚䞍芁 3.3 AWS Parallel Computing Service (PCS) AWS PCSは、クラりドでハむパフォヌマンスコンピュヌティングHPCクラスタを展開・管理するためのマネヌゞドサヌビスです。䞻な利点は以䞋の通りです 運甚負荷の削枛 : Slurmコントロヌラヌslurmctldの管理が䞍芁 自動スケヌリング : ゞョブに応じた蚈算ノヌドの自動起動・停止 既存ワヌクフロヌの掻甚 : 既存のSlurmスクリプトをそのたた利甚可胜 迅速な環境構築 : 箄30分で蚈算環境の準備が完了株匏䌚瀟 豊田䞭倮研究所の AWS re:Invent 2025での発衚事䟋  3.4 RELIONワヌクロヌドにPCSが適しおいる理由 RELIONのようなCryo-EM解析ワヌクロヌドには、以䞋の理由からPCSが適しおいるず考えたす。 Slurmずの芪和性 : RELIONはGUIからSlurmのsbatchコマンドでゞョブを投入する蚭蚈です。PCSはネむティブにSlurmをサポヌトしおおり、既存のSlurmスクリプトやワヌクフロヌをそのたた利甚できたす 運甚負荷の最小化 : 研究者はむンフラ管理ではなく解析に集䞭すべきです。PCSはSlurmコントロヌラヌの管理をAWSに委任でき、ParallelClusterず比范しお運甚負荷を倧幅に削枛できたす コンテナ化䞍芁 : AWS Batchはコンテナベヌスのため、RELIONや䟝存ラむブラリwxWidgets、CTFFIND等のコンテナ化が必芁です。PCSではAMIに゜フトりェアを事前むンストヌルするだけで枈みたす GUI操䜜ずの盞性 : Amazon DCVず組み合わせたGUI操䜜は、PCSのログむンノヌドから盎接行えたす AWS ParallelClusterずPCSの比范は、AWSブログ蚘事「 What’s the difference between AWS ParallelCluster and AWS Parallel Computing Service? 」も参考になりたす。 3.5 ストレヌゞ戊略 効率的なデヌタ管理のため、以䞋のストレヌゞ構成ずしおいたす。 FSx for Lustre : RELION䜜業ディレクトリ、S3 DRA連携による高速アクセス Amazon EFS : ホヌムディレクトリ、゜フトりェアむンストヌル Amazon S3 : 生デヌタ保存、凊理結果の長期保存、ラむフサむクル管理 3.6 S3ずFSx LustreのData Repository Association (DRA) Data Repository Association (DRA)は、Amazon S3ずFSx for Lustreを連携させる匷力な機胜です。RELIONワヌクロヌドにおいお、コスト効率ず性胜を䞡立させる鍵ずなりたす。 DRAの仕組み DRAは、S3バケットずFSx Lustreファむルシステム間に双方向のデヌタ同期を確立したす。1぀のFSx Lustreファむルシステムに最倧8぀のDRAを䜜成でき、それぞれ異なるS3バケットたたはプレフィックスにリンクできたす。 自動むンポヌト機胜 自動むンポヌトは、S3バケット内のオブゞェクトの倉曎を自動的にFSx Lustreに反映したす New : S3に新しいオブゞェクトが远加されたずきにメタデヌタをむンポヌト Changed : 既存のS3オブゞェクトが倉曎されたずきにメタデヌタを曎新 Deleted : S3オブゞェクトが削陀されたずきにファむルシステムから削陀 掚奚蚭定は、New + Changed + Deletedの組み合わせです。これにより、S3ずFSx Lustre間で完党な同期が維持されたす。 自動゚クスポヌト機胜 自動゚クスポヌトは、FSx Lustre䞊のファむル倉曎を自動的にS3に゚クスポヌトしたす ファむルが䜜成、倉曎、削陀されるず自動的にS3に反映 ファむルコンテンツの倉曎は、ファむルを閉じた埌に゚クスポヌト Amazon CloudWatch Logsで゚クスポヌト倱敗を監芖可胜 DRAに぀いおはこちらの ナヌザガむド をご確認ください。 4. セットアップず構築手順 本手順では、DLAMI + EC2 ImageBuilder方匏でPCS甚カスタムAMIを䜜成し、RELION環境を構築したす。この手順は AWS HPC Recipesで玹介されおいる手順 です。この方法により以䞋の効率化が図れたす。 NVIDIAドラむバヌ/CUDAがAMIに事前むンストヌル枈み DCVがLogin NodeのUserDataに含たれるため、再起動時にもDCV構成が維持される FFTWがLaunchTemplateでむンスタンス起動時にむンストヌルされる OS: Amazon Linux 2023Amazon Linux2023は 2029幎6月30日たでサポヌトされたす  党ノヌドGPU Login、GPU Compute、CPU Computeで同䞀AMIを䜿甚できる 手順の実行に圓たっおは以䞋の前提条件を螏たえお実行しおください。 PCSをデプロむできるAWSアカりントを持っおいるこず䜿うリヌゞョンはus-east-2リヌゞョンずする EC2のSSHキヌペアを䜜成枈みであるこずデプロむ察象ずなるリヌゞョンのus-east-2に䜜成枈みずする ロヌカルのPCにAWS CLI v2 がむンストヌル枈みであるこず 4.1 DLAMI ImageBuilderでカスタムAMI䜜成 4.1.1 ImageBuilderスタックのデプロむ HPC Recipes for AWSの DLAMI for PCS レシピを䜿甚しお、ImageBuilderパむプラむンをデプロむしたす。ここではAWS CloudFormationを䜿っおデプロむしたす。 aws cloudformation create-stack \ --region us-east-2 \ --capabilities CAPABILITY_IAM \ --stack-name dlami-for-pcs \ --template-url https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs/dlami_for_pcs_imagebuilder/assets/dlami-for-pcs.yaml \ --parameters \ ParameterKey=BuildSchedule,ParameterValue=Manual \ ParameterKey=PublishToSsm,ParameterValue=true \ ParameterKey=SsmParameterPrefix,ParameterValue=/dlami-for-pcs # 完了埅機玄5-10分 aws cloudformation wait stack-create-complete --stack-name dlami-for-pcs --region us-east-2 4.1.2 AMIビルドの実行 AmazonLinux2023のむメヌゞを䜜成可胜なAL2023 x86_64パむプラむンを実行したす。 # パむプラむンARNを取埗 PIPELINE_ARN=$(aws cloudformation describe-stacks \ --region us-east-2 \ --stack-name dlami-for-pcs \ --query "Stacks[0].Outputs[?OutputKey=='PipelineAl2023X8664Arn'].OutputValue" \ --output text) # ビルド開始玄25分皋床時間がかかりたす aws imagebuilder start-image-pipeline-execution \ --image-pipeline-arn ${PIPELINE_ARN} \ --region us-east-2 4.1.3 ビルド枈みAMI IDの取埗 # ビルド完了埌、AMI IDを取埗 DLAMI_AMI_ID=$(aws ec2 describe-images \ --owners self \ --filters "Name=name,Values=dlami-for-pcs-base-al2023-x86_64*" \ --query 'reverse(sort_by(Images, &CreationDate))[0].ImageId' \ --output text --region us-east-2) echo "DLAMI AMI ID: ${DLAMI_AMI_ID}" このAMIには以䞋が事前むンストヌルされおいたす NVIDIAドラむバヌ + CUDADLAMIベヌス AWS PCS Agent Slurm 24.11 + 25.05PATHはSlurm 25.05を優先するようLaunchTemplateの蚭定箇所で指定 EFS Utils CloudWatch Agent AWS System Manager AgentSSM Agent 4.2 PCSクラスタヌの䜜成 HPC Recipes for AWSの Getting Started テンプレヌトを䜿甚しお、PCSクラスタヌの基盀をデプロむしたす。䞊蚘テンプレヌトは、VPC、サブネット、EFS、FSx for Lustre、PCS Cluster、IAM、Security Groupsなどの基盀リ゜ヌスを䞀括䜜成したす。デフォルト蚭定ではデモ甚のLogin Nodec6i.xlargeずCompute Nodec6i.xlarge、demoキュヌが䜜成されたすが、今回䜜成するRELION環境ではGPU付きのLogin NodeずGPU/CPUコンピュヌトノヌドも䜜成したす。次のステップで、RELION向けにノヌドグルヌプずキュヌを远加で䜜成したす。 AWS PCSはマネヌゞドコン゜ヌルで「パラレルコンピュヌティングサヌビス」ずいうサヌビス名で画面にアクセスできたす。 4.2.1 コン゜ヌルからのデプロむする堎合ワンクリック Launch Stack (us-east-2) パラメヌタ蚭定 SlurmVersion : 25.05 最新のサポヌトバヌゞョンを掚奚。24.11は2026幎5月31日にEOL。 サポヌトバヌゞョン䞀芧 を参照 ManagedAccounting : enabled Slurm Accountingを有効化。 sacct コマンドでゞョブ履歎・リ゜ヌス䜿甚量を確認でき、トラブルシュヌティングやコスト分析に有甚です NodeArchitecture : x86 KeyName : 事前に䜜成したSSHキヌペア名( my-keypair ) ClientIpCidr : ご利甚されおいる環境䞋でのクラむアント偎のパブリックIP aa.bb.cc.dd/32  機胜ず倉換箇所で、チェックを入れお、「スタックの䜜成」をクリックするずCloudFormationがデプロむされたす。 4.2.2 AWS CLIからデプロむする堎合 YOUR_KEY_NAMEに事前に䜜成したSSHキヌペア名を代入しおください。YOUR_IPにはClientIpCidrず同じクラむアント偎のパブリックIPを指定しおください。 export YOUR_KEY_NAME="my-keypair" export YOUR_IP="aa.bb.cc.dd" aws cloudformation create-stack \ --stack-name pcs-relion \ --template-url https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs/getting_started/assets/cluster.yaml \ --parameters \ ParameterKey=SlurmVersion,ParameterValue=25.05 \ ParameterKey=ManagedAccounting,ParameterValue=enabled \ ParameterKey=NodeArchitecture,ParameterValue=x86 \ ParameterKey=KeyName,ParameterValue=${YOUR_KEY_NAME} \ ParameterKey=ClientIpCidr,ParameterValue=${YOUR_IP}/32 \ --capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \ --region us-east-2 # 完了埅機玄25分 aws cloudformation wait stack-create-complete --stack-name pcs-relion --region us-east-2 4.2.3 CloudFormation出力倀の取埗AWS CLIを䜿甚 デプロむされたCloudFormationのスタックが䜜成完了した埌、以降の手順で䜿甚するリ゜ヌスIDを取埗したす。CloudFormationコン゜ヌルの「出力」タブでも確認できたすが、以䞋のAWS CLIで確認ができたす。あずのコマンド実行のパラメヌタずしおもここで蚭定した倉数を利甚したす。以降の凊理を行う堎合はAWS CLIでコマンドを実行しおください。 # PCSクラスタヌID CLUSTER_ID=$(aws cloudformation describe-stacks --stack-name pcs-relion \ --query "Stacks[0].Outputs[?OutputKey=='ClusterId'].OutputValue" \ --output text --region us-east-2) # ネストスタックからリ゜ヌスIDを取埗するヘルパヌ関数 get_nested_output() { local nested_id=$(aws cloudformation describe-stack-resource \ --stack-name pcs-relion --logical-resource-id "$1" \ --query "StackResourceDetail.PhysicalResourceId" \ --output text --region us-east-2) aws cloudformation describe-stacks --stack-name "$nested_id" \ --query "Stacks[0].Outputs[?OutputKey=='$2'].OutputValue" \ --output text --region us-east-2 } # 各リ゜ヌスID VPC_ID=$(get_nested_output "Networking" "VPC") PUBLIC_SUBNET_ID=$(get_nested_output "Networking" "DefaultPublicSubnet") PRIVATE_SUBNET_ID=$(get_nested_output "Networking" "DefaultPrivateSubnet") EFS_ID=$(get_nested_output "EfsStorage" "EFSFilesystemId") FSX_ID=$(get_nested_output "FSxLStorage" "FSxLustreFilesystemId") FSX_MOUNT_NAME=$(get_nested_output "FSxLStorage" "FSxLustreMountName") CLUSTER_SG_ID=$(get_nested_output "PCSSecurityGroup" "ClusterSecurityGroupId") SSH_SG_ID=$(get_nested_output "PCSSecurityGroup" "InboundSshSecurityGroupId") INSTANCE_PROFILE_ARN=$(get_nested_output "PCSInstanceProfile" "InstanceProfileArn") COMPUTE_LT_ID=$(get_nested_output "PCSLaunchTemplate" "ComputeLaunchTemplateId") LOGIN_LT_ID=$(get_nested_output "PCSLaunchTemplate" "LoginLaunchTemplateId") # VPCデフォルトSG VPC_DEFAULT_SG=$(aws ec2 describe-security-groups \ --filters "Name=vpc-id,Values=${VPC_ID}" "Name=group-name,Values=default" \ --query "SecurityGroups[0].GroupId" --output text --region us-east-2) # EFS/FSx SGネストスタックから取埗 EFS_SG=$(get_nested_output "EfsStorage" "SecurityGroupId") FSX_SG=$(get_nested_output "FSxLStorage" "FSxLustreSecurityGroupId") echo "CLUSTER_ID=${CLUSTER_ID}" echo "PUBLIC_SUBNET_ID=${PUBLIC_SUBNET_ID}" echo "PRIVATE_SUBNET_ID=${PRIVATE_SUBNET_ID}" echo "EFS_ID=${EFS_ID}" echo "FSX_ID=${FSX_ID}" echo "FSX_MOUNT_NAME=${FSX_MOUNT_NAME}" 4.3 GPU Login Node + GPU/CPUコンピュヌトノヌドグルヌプの远加 Getting Started テンプレヌトで䜜成されたデフォルトのLogin Nodec6i.xlargeずCompute Nodec6i.xlarge、 demo キュヌずは別にRELIONの実行環境に適したGPUを搭茉したLoginNodeやCPUずGPUのComputeNodeを䜜成したす。 Login NodeGPU : g6.xlargeL4 GPU搭茉。DCVをGPU察応で皌働 + RELION GPUビルドで甚いる GPU Compute Node : g6e.4xlargeL40S GPU、 gpu-queue 。2D/3D Classification等のGPU凊理甚 CPU Compute Node : c7i.4xlarge cpu-queue 。Motion Correction、CTF Estimation等のCPU凊理甚 デフォルトの login 、 compute-1 ノヌドグルヌプず demo キュヌは削陀 Launch Templateの䜜成 Compute甹UserDataGPU/CPU共通 DLAMIにはNVIDIAドラむバヌ/CUDAが事前むンストヌル枈みのため、UserDataで蚭定するものはEFS/FSxのマりントずFFTWやlustre-clientのパッケヌゞのむンストヌルになりたす。 cat > compute-userdata.txt <<EOF MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 packages: - amazon-efs-utils - lustre-client - fftw - fftw-libs - fftw-devel - ghostscript runcmd: - mkdir -p /tmp/home - rsync -aA /home/ /tmp/home - echo "${EFS_ID}:/ /home efs tls,_netdev" >> /etc/fstab - mount -a -t efs defaults - rsync -aA --ignore-existing /tmp/home/ /home - rm -rf /tmp/home/ - mkdir -p /shared - chmod a+rwx /shared - mount -t lustre ${FSX_ID}.fsx.us-east-2.amazonaws.com@tcp:/${FSX_MOUNT_NAME} /shared - chmod 777 /shared - echo 'export PATH=/opt/aws/pcs/scheduler/slurm-25.05/bin:$PATH' > /etc/profile.d/slurm-version.sh --==MYBOUNDARY== EOF Login GPU甹UserDataDCV含む Login NodeのUserDataにはDCVむンストヌルも含めたす。これによりログむンノヌド再起動時にもDCVが維持されたす。 cat > login-gpu-userdata.txt <<EOF MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="==MYBOUNDARY==" --==MYBOUNDARY== Content-Type: text/cloud-config; charset="us-ascii" MIME-Version: 1.0 packages: - amazon-efs-utils - lustre-client - fftw - fftw-libs - fftw-devel - cmake - git - wget - environment-modules - libtiff-devel - libpng-devel - gtk3-devel - mesa-libGL-devel - mesa-libGLU-devel - libXft-devel - libX11-devel - ghostscript runcmd: # Development Tools group install - dnf groupinstall -y "Development Tools" # EFS/FSx mount - mkdir -p /tmp/home - rsync -aA /home/ /tmp/home - echo "${EFS_ID}:/ /home efs tls,_netdev" >> /etc/fstab - mount -a -t efs defaults - rsync -aA --ignore-existing /tmp/home/ /home - rm -rf /tmp/home/ - mkdir -p /shared - chmod a+rwx /shared - mount -t lustre ${FSX_ID}.fsx.us-east-2.amazonaws.com@tcp:/${FSX_MOUNT_NAME} /shared - chmod 777 /shared # Slurm 25.05 PATH priority - echo 'export PATH=/opt/amazon/openmpi/bin:/opt/aws/pcs/scheduler/slurm-25.05/bin:$PATH' > /etc/profile.d/slurm-version.sh - echo 'export LD_LIBRARY_PATH=/opt/amazon/openmpi/lib64:${LD_LIBRARY_PATH:-}' >> /etc/profile.d/slurm-version.sh # Software directory setup - mkdir -p /home/software/apps /home/software/src /home/software/modulefiles - chown -R ec2-user:ec2-user /home/software # DCV installation (AL2023) - dnf groupinstall -y "Desktop" - dnf install -y glx-utils - systemctl set-default graphical.target # Wayland無効化X11モヌドに匷制 - sed -i '/\[daemon\]/a WaylandEnable=false' /etc/gdm/custom.conf # NVIDIA Xorg蚭定GPUレンダリング有効化 - nvidia-xconfig --preserve-busid --enable-all-gpus # DCV パッケヌゞむンストヌル - rpm --import https://d1uj6qtbmh3dt5.cloudfront.net/NICE-GPG-KEY - cd /tmp && wget -q https://d1uj6qtbmh3dt5.cloudfront.net/nice-dcv-el9-x86_64.tgz && tar -xzf nice-dcv-el9-x86_64.tgz && cd nice-dcv-*-el9-x86_64 && dnf install -y nice-dcv-server-*.rpm nice-dcv-web-viewer-*.rpm nice-xdcv-*.rpm - | cat > /etc/dcv/dcv.conf << 'DCVCONF' [session-management] create-session = true [session-management/automatic-console-session] owner = "ec2-user" [display] target-fps = 30 [connectivity] enable-quic-frontend = true idle-timeout = 0 [security] authentication = "system" DCVCONF - echo "ec2-user:dcvpassword" | chpasswd # Skip Initial GNOME setup - mkdir -p /home/ec2-user/.config - echo 'yes' > /home/ec2-user/.config/gnome-initial-setup-done - chown -R ec2-user:ec2-user /home/ec2-user/.config - systemctl enable gdm && systemctl start gdm - systemctl enable dcvserver && systemctl restart dcvserver --==MYBOUNDARY== EOF ec2-userのパスワヌドは怜蚌甚に簡単なものを付けおいたす。お䜿いになる環境条件を考慮頂き、必芁に応じお匷固なパスワヌドに倉曎しおください。 Launch Template䜜成 # Compute甹UserDataをファむルに保存しおBase64゚ンコヌド COMPUTE_USERDATA_B64=$(cat compute-userdata.txt | base64) # Login GPU甹UserDataをファむルに保存しおBase64゚ンコヌド LOGIN_USERDATA_B64=$(cat login-gpu-userdata.txt | base64) # Compute Launch TemplateGPU/CPU共通、Private Subnet甚 COMPUTE_LT_ID=$(aws ec2 create-launch-template \ --launch-template-name "compute-dlami-pcs-relion" \ --launch-template-data "{ \"TagSpecifications\": [{\"ResourceType\": \"instance\", \"Tags\": [{\"Key\": \"HPCRecipes\", \"Value\": \"true\"}]}], \"MetadataOptions\": {\"HttpEndpoint\": \"enabled\", \"HttpPutResponseHopLimit\": 4, \"HttpTokens\": \"required\"}, \"SecurityGroupIds\": [\"${VPC_DEFAULT_SG}\", \"${CLUSTER_SG_ID}\", \"${EFS_SG}\", \"${FSX_SG}\"], \"UserData\": \"${COMPUTE_USERDATA_B64}\" }" \ --query "LaunchTemplate.LaunchTemplateId" \ --output text --region us-east-2) # Login GPU Launch TemplatePublic Subnet甚、SSH SG + KeyName + DCV付き LOGIN_LT_ID=$(aws ec2 create-launch-template \ --launch-template-name "login-gpu-dlami-pcs-relion" \ --launch-template-data "{ \"TagSpecifications\": [{\"ResourceType\": \"instance\", \"Tags\": [{\"Key\": \"HPCRecipes\", \"Value\": \"true\"}]}], \"MetadataOptions\": {\"HttpEndpoint\": \"enabled\", \"HttpPutResponseHopLimit\": 4, \"HttpTokens\": \"required\"}, \"KeyName\": \"${YOUR_KEY_NAME}\", \"SecurityGroupIds\": [\"${VPC_DEFAULT_SG}\", \"${CLUSTER_SG_ID}\", \"${SSH_SG_ID}\", \"${EFS_SG}\", \"${FSX_SG}\"], \"UserData\": \"${LOGIN_USERDATA_B64}\" }" \ --query "LaunchTemplate.LaunchTemplateId" \ --output text --region us-east-2) ${YOUR_KEY_NAME} は登録枈みのキヌペア名を指定しおください。 NodeGroup + キュヌ䜜成 党ノヌドでDLAMI AMI ${DLAMI_AMI_ID} を䜿甚したす。 # GPU Login NodeGroup (g6.xlarge) aws pcs create-compute-node-group \ --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-name login-gpu \ --ami-id ${DLAMI_AMI_ID} \ --subnet-ids ${PUBLIC_SUBNET_ID} \ --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \ --scaling-configuration "minInstanceCount=1,maxInstanceCount=1" \ --instance-configs '[{"instanceType":"g6.xlarge"}]' \ --custom-launch-template "id=${LOGIN_LT_ID},version=1" \ --region us-east-2 # login-gpuのNodeGroupがACTIVEになるたで埅機 # GPU Compute NodeGroup (g6e.4xlarge) aws pcs create-compute-node-group \ --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-name gpu-nodes \ --ami-id ${DLAMI_AMI_ID} \ --subnet-ids ${PRIVATE_SUBNET_ID} \ --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \ --scaling-configuration "minInstanceCount=0,maxInstanceCount=4" \ --instance-configs '[{"instanceType":"g6e.4xlarge"}]' \ --custom-launch-template "id=${COMPUTE_LT_ID},version=1" \ --region us-east-2 # CPU Compute NodeGroup (c7i.4xlarge) - 同じDLAMI AMI + 同じCompute LT aws pcs create-compute-node-group \ --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-name cpu-nodes \ --ami-id ${DLAMI_AMI_ID} \ --subnet-ids ${PRIVATE_SUBNET_ID} \ --iam-instance-profile-arn ${INSTANCE_PROFILE_ARN} \ --scaling-configuration "minInstanceCount=0,maxInstanceCount=4" \ --instance-configs '[{"instanceType":"c7i.4xlarge"}]' \ --custom-launch-template "id=${COMPUTE_LT_ID},version=1" \ --region us-east-2 # gpu-nodesずcpu-nodesのNodeGroupがACTIVEになるたで埅機 # 䜜成したNodeGroupのIDを取埗 GPU_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='gpu-nodes'].id" --output text --region us-east-2) CPU_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='cpu-nodes'].id" --output text --region us-east-2) # キュヌ䜜成 aws pcs create-queue --cluster-identifier ${CLUSTER_ID} --queue-name gpu-queue \ --compute-node-group-configurations "[{\"computeNodeGroupId\":\"${GPU_NG_ID}\"}]" --region us-east-2 aws pcs create-queue --cluster-identifier ${CLUSTER_ID} --queue-name cpu-queue \ --compute-node-group-configurations "[{\"computeNodeGroupId\":\"${CPU_NG_ID}\"}]" --region us-east-2 gpu-queueずcpu-queueキュヌがアクティブになるたで少し埅ちたす。 オプションデフォルトリ゜ヌスの削陀 RELION実行甚に新しいNodeGroupずキュヌが䜜成できたのちに、Getting Started Templateで䜜成されたデフォルトリ゜ヌスは今回䞍芁ずなるのでリ゜ヌスを削陀したす。本手順の実行はオプションです。 # デフォルトリ゜ヌスのID取埗 DEMO_QUEUE_ID=$(aws pcs list-queues --cluster-identifier ${CLUSTER_ID} \ --query "queues[?name=='demo'].id" --output text --region us-east-2) COMPUTE1_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='compute-1'].id" --output text --region us-east-2) OLD_LOGIN_NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='login'].id" --output text --region us-east-2) # demoキュヌ削陀キュヌを先に削陀しおからNodeGroupを削陀したす aws pcs delete-queue --cluster-identifier ${CLUSTER_ID} \ --queue-identifier ${DEMO_QUEUE_ID} --region us-east-2 # demoキュヌが削陀されるたで少し埅っおから以䞋を実行しおください。 # compute-1コンピュヌトノヌドグルヌプ削陀 aws pcs delete-compute-node-group --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-identifier ${COMPUTE1_NG_ID} --region us-east-2 # loginコンピュヌトノヌドグルヌプ削陀 aws pcs delete-compute-node-group --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-identifier ${OLD_LOGIN_NG_ID} --region us-east-2 # 削陀確認login-gpu, cpu-nodes, gpu-nodes の3぀だけ残っおいればOK aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[].name" --output text --region us-east-2 4.4 Amazon DCVのセキュリティグルヌプ蚭定 セキュリティグルヌプにDCVポヌトを远加したすTCP + UDP。UDPはQUICプロトコルによる䜎遅延ストリヌミングに䜿甚したす。 ${YOUR_IP}/32 はクラスタヌ䜜成時に指定したClientIpCidrず同じパブリックIPを䜿甚しおください aws ec2 authorize-security-group-ingress --group-id ${SSH_SG_ID} \ --protocol tcp --port 8443 --cidr ${YOUR_IP}/32 --region us-east-2 aws ec2 authorize-security-group-ingress --group-id ${SSH_SG_ID} \ --protocol udp --port 8443 --cidr ${YOUR_IP}/32 --region us-east-2 DCVぞのアクセス確認 ブラりザで https://<LOGIN_GPU_NODE_IP>login-gpuで䜜成したむンスタンスに付䞎されおいるグロヌバルアドレス:8443 にアクセスし、 ec2-user / dcvpassword でDCVにログむンができるか確認をしおください。ブラりザ䞊蚌明曞の譊告が衚瀺されたすが、確認をしながらアクセスを進めおください。 4.5 RELIONず䟝存ラむブラリのむンストヌル RELIONのビルドにはPCS AMIにプリむンストヌルされたOpenMPI/opt/amazon/openmpi/を䜿甚したす。 # LOGIN NODEにSSHでログむンしたす。 ssh -i "${YOUR_KEY_NAME}が眮かれおいる絶察パス" ec2-user@${LOGIN_NODE_IP} # wxWidgets 3.2.5CTFFIND甚。ビルドに9分匱時間が掛かる cd /home/software/src wget https://github.com/wxWidgets/wxWidgets/releases/download/v3.2.5/wxWidgets-3.2.5.tar.bz2 tar -xjf wxWidgets-3.2.5.tar.bz2 && cd wxWidgets-3.2.5 cd build ../configure --prefix=/home/software/apps/wxWidgets-3.2.5 --with-gtk=3 --enable-unicode --disable-shared make -j$(nproc) && make install # CTFFIND 4.1.14 cd /home/software/src wget https://grigoriefflab.umassmed.edu/sites/default/files/ctffind-4.1.14.tar.gz -O ctffind-4.1.14.tar.gz tar -xzf ctffind-4.1.14.tar.gz && cd ctffind-4.1.14 # CTFFIND 4.1.14では゜ヌスの䞀郚でbool型で宣蚀されおいるにもかかわらずreturn文がなく、 # C++の未定矩動䜜によりSegmentation Faultが発生したす。 # この問題はCTFFIND開発者フォヌラムで報告され、開発版では修正枈みであるこずが確認されおいたす。 # 参照: https://grigoriefflab.umassmed.edu/forum/software/ctffind_ctftilt/ctffind_4114_segfault sed -i 's/^bool ComputeRotationalAverageOfPowerSpectrum/void ComputeRotationalAverageOfPowerSpectrum/' src/programs/ctffind/ctffind.cpp sed -i 's/^bool RescaleSpectrumAndRotationalAverage/void RescaleSpectrumAndRotationalAverage/' src/programs/ctffind/ctffind.cpp # ビルドOpenMP有効化を指定、ビルドに1分匱時間が掛かる mkdir build && cd build ../configure --prefix=/home/software/apps/ctffind-4.1.14 \ --with-wx-config=/home/software/apps/wxWidgets-3.2.5/bin/wx-config \ --enable-openmp --disable-debugmode \ CXXFLAGS="-O2 -fopenmp -Wall -pipe" \ LDFLAGS="-L/home/software/apps/wxWidgets-3.2.5/lib -lgomp" make -j$(nproc) && make install # RELION 5.0 GPUビルドビルドに9分匱時間が掛かる cd /home/software/src && git clone https://github.com/3dem/relion.git cd relion && git checkout ver5.0 mkdir build-gpu && cd build-gpu cmake .. -DCMAKE_INSTALL_PREFIX=/home/software/apps/relion-gpu-5.0 \ -DCUDA_TOOLKIT_ROOT_DIR=/usr/local/cuda -DGUI=ON -DCUDA=ON \ -DCUDA_ARCH=89 \ -DFETCH_WEIGHTS=OFF \ -DMPI_C_COMPILER=/opt/amazon/openmpi/bin/mpicc \ -DMPI_CXX_COMPILER=/opt/amazon/openmpi/bin/mpicxx make -j$(nproc) && make install # RELION 5.0 CPUビルドビルドに6分匱時間が掛かる cd /home/software/src/relion mkdir build-cpu && cd build-cpu cmake .. -DCMAKE_INSTALL_PREFIX=/home/software/apps/relion-cpu-5.0 \ -DGUI=ON -DCUDA=OFF \ -DFETCH_WEIGHTS=OFF \ -DMPI_C_COMPILER=/opt/amazon/openmpi/bin/mpicc \ -DMPI_CXX_COMPILER=/opt/amazon/openmpi/bin/mpicxx make -j$(nproc) && make install 4.5.1 Environment Modulesの蚭定 RELIONのGPU/CPUビルド版をEnvironment Modulesで切り替えるためのmodulefileを䜜成したす。 # relion/gpu modulefile mkdir -p /home/software/modulefiles/relion cat > /home/software/modulefiles/relion/gpu <<'MODEOF' #%Module1.0 proc ModulesHelp { } { puts stderr "RELION 5.0 GPU build (CUDA enabled)" } module-whatis "RELION 5.0 GPU build" conflict relion set basedir /home/software/apps/relion-gpu-5.0 prepend-path PATH $basedir/bin prepend-path LD_LIBRARY_PATH $basedir/lib prepend-path PATH /home/software/apps/ctffind-4.1.14/bin prepend-path PATH /opt/amazon/openmpi/bin prepend-path LD_LIBRARY_PATH /opt/amazon/openmpi/lib64 prepend-path PATH /usr/local/cuda/bin prepend-path LD_LIBRARY_PATH /usr/local/cuda/lib64 setenv RELION_CTFFIND_EXECUTABLE /home/software/apps/ctffind-4.1.14/bin/ctffind MODEOF # relion/cpu modulefile cat > /home/software/modulefiles/relion/cpu <<'MODEOF' #%Module1.0 proc ModulesHelp { } { puts stderr "RELION 5.0 CPU build (no CUDA)" } module-whatis "RELION 5.0 CPU build" conflict relion set basedir /home/software/apps/relion-cpu-5.0 prepend-path PATH $basedir/bin prepend-path LD_LIBRARY_PATH $basedir/lib prepend-path PATH /home/software/apps/ctffind-4.1.14/bin prepend-path PATH /opt/amazon/openmpi/bin prepend-path LD_LIBRARY_PATH /opt/amazon/openmpi/lib64 setenv RELION_CTFFIND_EXECUTABLE /home/software/apps/ctffind-4.1.14/bin/ctffind MODEOF # MODULEPATHを~/.bashrcに远加 echo 'export MODULEPATH=/home/software/modulefiles:${MODULEPATH:-}' >> ~/.bashrc source ~/.bashrc これで以䞋のコマンドでGPU/CPUビルドを切り替えられたす module load relion/gpu # GPU凊理2D/3D Classification, Refinement module load relion/cpu # CPU凊理Motion Correction, CTF Estimation # EC2からログアりト exit 4.6 FSx for Lustreスルヌプット調敎ずDRA䜜成オプション このセクションはオプションです。FSx for Lustreのスルヌプット調敎ずS3 Data Repository AssociationDRAは、RELIONの実行自䜓には必須ではありたせん。Getting Started Templateで䜜成されたFSx for Lustreデフォルト125 MB/s/TiBのたたでもRELIONゞョブは正垞に動䜜したす。倧芏暡デヌタセットの凊理やS3ずの双方向同期が必芁な堎合に蚭定が必芁ずなるので、参考の手順ずしお瀺したす。 # スルヌプット曎新125 → 250 MB/s/TiB、倉曎完了たで時間が掛かる aws fsx update-file-system --file-system-id ${FSX_ID} \ --lustre-configuration PerUnitStorageThroughput=250 --region us-east-2 # FSxのコン゜ヌル画面で、Lustreの該圓ファむルシステムのラむフサむクルの状態が「曎新䞭」になりたす。それが完了するたで埅぀こず。 # S3バケット䜜成 AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) aws s3 mb s3://pcs-relion-data-${AWS_ACCOUNT_ID} --region us-east-2 # DRA䜜成双方向同期 aws fsx create-data-repository-association \ --file-system-id ${FSX_ID} \ --file-system-path /shared/data \ --data-repository-path s3://pcs-relion-data-${AWS_ACCOUNT_ID}/datasets/ \ --s3 '{"AutoImportPolicy":{"Events":["NEW","CHANGED","DELETED"]},"AutoExportPolicy":{"Events":["NEW","CHANGED","DELETED"]}}' \ --batch-import-meta-data-on-create --region us-east-2 4.7 CloudWatch監芖蚭定オプション このセクションもオプションです。CloudWatch監芖はRELIONの実行には必須ではありたせんが、Slurmスケゞュヌラヌのログ確認やDRA同期状態の監芖に有甚です。 PCS Scheduler / Job Completion ログ HPC Recipesの CloudWatch Log Delivery テンプレヌトを䜿甚しお、PCSのScheduler LogsずJob Completion LogsをCloudWatchに送信したす。これにより、Slurmスケゞュヌラヌの動䜜ログずゞョブ完了ログをCloudWatchコン゜ヌルから確認できたす。 aws cloudformation create-stack \ --stack-name pcs-relion-cloudwatch-logs \ --template-url https://aws-hpc-recipes.s3.us-east-1.amazonaws.com/main/recipes/pcs/cloudwatch/assets/cloudwatch_log_delivery.cfn.yaml \ --parameters ParameterKey=PCSClusterId,ParameterValue=${CLUSTER_ID} \ --capabilities CAPABILITY_NAMED_IAM CAPABILITY_AUTO_EXPAND \ --region us-east-2 䜜成されるCloudWatch LogGroup /aws/vendedlogs/pcs/cluster/PCS_SCHEDULER_LOGS/<CLUSTER_ID> /aws/vendedlogs/pcs/cluster/PCS_JOBCOMP_LOGS/<CLUSTER_ID> 5. ゞョブ実行䟋 5.1 テストデヌタセットの準備 RELION 5.0公匏チュヌトリアルのテストデヌタbeta-galactosidase、EMPIAR-10204を䜿甚したす。 # LOGIN NODEにSSHでログむンしたす。 ssh -i "${YOUR_KEY_NAME}が眮かれおいる絶察パス" ec2-user@${LOGIN_NODE_IP} mkdir -p /shared/relion-test && cd /shared/relion-test wget ftp://ftp.mrc-lmb.cam.ac.uk/pub/scheres/relion30_tutorial_data.tar tar -xf relion30_tutorial_data.tar rm -f relion30_tutorial_data.tar 展開埌、 /shared/relion-test/relion30_tutorial/Movies/ にテストデヌタ.tiffファむルが配眮されたす。 5.2 Importゞョブの実行 RELIONでは最初にImportゞョブを実行しお、動画ファむルのパスずoptics情報をSTARファむルに登録する必芁がありたす。RELION 5.0ではopticsグルヌプ電圧、球面収差、ピクセルサむズ等がSTARファむルに必須です。 module load relion/cpu cd /shared/relion-test mkdir -p Import/job001 relion_import --do_movies --optics_group_name opticsGroup1 \ --angpix 0.885 --kV 200 --Cs 1.4 --Q0 0.1 \ --beamtilt_x 0 --beamtilt_y 0 \ --i "relion30_tutorial/Movies/*.tiff" \ --odir Import/job001/ --ofile movies.star パラメヌタはRELION公匏チュヌトリアルデヌタEMPIAR-10204、beta-galactosidaseの撮像条件に基づいおいたす --angpix 0.885 : ピクセルサむズÅ/pixel --kV 200 : 加速電圧kV --Cs 1.4 : 球面収差mm --Q0 0.1 : 振幅コントラスト比 Import/job001 以䞋にmovies.starファむルが䜜成されおいれば凊理は成功しおいたす。 5.3 Motion Correctionの実行 5.3.1 RELION GUIからのゞョブ投入 Amazon DCV経由でLoginNodeにログむン埌、以䞋のコマンドでRELIONのGUI画面が衚瀺されたす。 # DCV経由でLogin Nodeに接続埌 source ~/.bashrc module load relion/cpu cd /shared/relion-test relion & GUIでゞョブを投入する堎合、あらかじめSubmission.shを䜜成しおおく必芁がありたす。以䞋のコマンドでTemplateのシェルスクリプトを䜜成しおおきたすCPU queueに投げる堎合のsubmission.shです。 cat > /home/software/apps/relion-submission.sh << 'EOF' #!/bin/bash #SBATCH --ntasks=XXXmpinodesXXX #SBATCH --cpus-per-task=XXXthreadsXXX #SBATCH --time=24:00:00 #SBATCH --partition=XXXqueueXXX #SBATCH --job-name=XXXnameXXX #SBATCH --output=XXXoutfileXXX #SBATCH --error=XXXerrfileXXX source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:${MODULEPATH:-} module purge module load relion/cpu export OMP_NUM_THREADS=${SLURM_CPUS_PER_TASK} export OMPI_MCA_rmaps_base_mapping_policy=slot:PE=${SLURM_CPUS_PER_TASK} export OMPI_MCA_hwloc_base_binding_policy=core if [ ${SLURM_NTASKS} -gt 1 ]; then mpirun -np ${SLURM_NTASKS} XXXcommandXXX else XXXcommandXXX fi EOF chmod +x /home/software/apps/relion-submission.sh RELION GUI経由でPCSにゞョブを投入する堎合は、各凊理プロセスのRunningタブで以䞋を蚭定する必芁がありたす。 Queue name : gpu-queue GPU凊理たたは cpu-queue CPU凊理 Submit to queue? : Yesに倉曎する 参考䟋ずしおGUIによる実行䟋を瀺したす。Motion correctionの凊理をGUIから行う堎合です。 Input movies STAR file:に「Import/job001/movies.star」を指定する Runningタブを遞択し、以䞋の項目を倉曎したす。 項目 蚭定倀 Number of MPI procs 2 Number of threads 4 Submit to queue? Yes Queue name cpu-queue Queue submit command sbatch Standard submission script /home/software/apps/relion-submission.sh 倉曎埌「Run!」でPCSにゞョブが投入されたす。 他の解析凊理も同様のGUI操䜜でPCSにゞョブが投入可胜です。以降のRELIONのサンプル実行はCUIベヌスで説明したすが、同じ凊理をGUIでも行うこずができたす。䜿いやすい方を遞び凊理を実行しおください。 5.3.2 CUIによるMotion Correctionの実行䟋CPUキュヌでの実行 Motion Correctionはデフォルトの状態ではCPUで行われる凊理になっおいたす。今回の堎合は cpu-queue に投入しおください。 sbatch --partition=cpu-queue --nodes=1 --ntasks=2 --cpus-per-task=4 \ --time=02:00:00 --job-name=relion_motioncorr \ --wrap=" source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:\${MODULEPATH:-} module load relion/cpu cd /shared/relion-test mkdir -p MotionCorr/job002 export OMP_NUM_THREADS=\$SLURM_CPUS_PER_TASK BIND_OPTS='--map-by slot:PE='\$SLURM_CPUS_PER_TASK' --bind-to core' mpirun \$BIND_OPTS -np \$SLURM_NTASKS \ relion_run_motioncorr_mpi \ --i Import/job001/movies.star \ --o MotionCorr/job002/ \ --use_own --j \$SLURM_CPUS_PER_TASK \ --patch_x 1 --patch_y 1 --bin_factor 1 \ --dose_per_frame 1.0 --angpix 0.885 " MotionCorr/job002 以䞋にstarファむルなどが䜜成されおいれば凊理は成功しおいたす。24 micrographs凊理は玄2分皋床かかりたす。 5.4 CTF Estimationの実行䟋CPUキュヌでの実行 sbatch --partition=cpu-queue --nodes=1 --ntasks=8 --cpus-per-task=1 \ --time=02:00:00 --job-name=relion_ctf \ --wrap=" source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:\${MODULEPATH:-} module load relion/cpu cd /shared/relion-test mkdir -p CtfFind/job003 export OMP_NUM_THREADS=\$SLURM_CPUS_PER_TASK BIND_OPTS='--map-by slot:PE='\$SLURM_CPUS_PER_TASK' --bind-to core' mpirun \$BIND_OPTS -np \$SLURM_NTASKS \ relion_run_ctffind_mpi \ --i MotionCorr/job002/corrected_micrographs.star \ --o CtfFind/job003/ \ --ctffind_exe /home/software/apps/ctffind-4.1.14/bin/ctffind \ --is_ctffind4 --ctfWin 512 --Box 512 \ --ResMin 30 --ResMax 5 --dFMin 1000 --dFMax 50000 --FStep 500 --dAst 100 \ --j \$SLURM_CPUS_PER_TASK " CtfFind/job003 以䞋にepsやstarファむルが生成されおいれば凊理は成功しおいたす。CTF掚定の完了には玄1分皋床かかりたす。 5.5 Auto-picking ず Particle ExtractionCPU凊理 CTF Estimation埌、2D Classificationに進むにはParticle Picking粒子遞択ずExtraction粒子抜出が必芁です。ここではRELIONのLoGLaplacian-of-GaussianフィルタによるテンプレヌトフリヌのAuto-pickingを䜿甚したす。チュヌトリアルデヌタ24 micrographsであればLogin Node䞊で数十秒で完了するため、sbatchではなく盎接実行したす。 # Login NodeにSSH接続した状態で実行 module load relion/cpu cd /shared/relion-test # LoG Auto-pickingテンプレヌトフリヌ、CPU凊理 mkdir -p AutoPick/job004 relion_autopick \ --i CtfFind/job003/micrographs_ctf.star \ --odir AutoPick/job004/ \ --LoG \ --LoG_diam_min 150 --LoG_diam_max 180 \ --shrink 0 --lowpass 20 \ --LoG_adjust_threshold 0 --LoG_upper_threshold 5 䞊蚘凊理は30秒匱で終了したす。 AutoPick/job004 の䞋にファむルが䜜成されおいれば凊理は成功しおいたす。 今回指定しおいるパラメヌタの䟋を以䞋に瀺したす。 LoG Auto-pickingのパラメヌタ --LoG_diam_min 150 --LoG_diam_max 180 : 粒子の盎埄範囲Å。beta-galactosidaseの堎合150-180Å --LoG_adjust_threshold 0 : ピッキング閟倀の調敎正の倀で少なく、負の倀で倚くピックしたす --LoG_upper_threshold 5 : 高コントラスト汚染氷滎等を陀倖する䞊限閟倀 # Particle Extraction256px → 64pxにダりンスケヌル mkdir -p Extract/job005 relion_preprocess \ --i CtfFind/job003/micrographs_ctf.star \ --coord_dir AutoPick/job004/ \ --coord_suffix _autopick.star \ --part_star Extract/job005/particles.star \ --part_dir Extract/job005/ \ --extract --extract_size 256 --scale 64 \ --norm --bg_radius 25 --white_dust -1 --black_dust -1 \ --invert_contrast --float16 䞊蚘凊理は15秒皋床で終了したす。 Extract/job005 の䞋にparticles.starファむルが生成されおいれば凊理は成功しおいたす。 Particle Extractionのパラメヌタ --extract_size 256 : 抜出ボックスサむズピクセル --scale 64 : 64pxにダりンスケヌル初期分類の高速化のため --bg_radius 25 : 背景領域の半埄ピクセル、スケヌル埌のサむズに察しお指定したす。64pxの玄75%÷2で25 --invert_contrast : 黒い粒子を癜に反転RELION内郚凊理甚 5.6 2D Classification の実行䟋GPUキュヌでの実行 2D ClassificationはGPUによっお凊理が高速化される凊理工皋です。今回䜜成した gpu-queue にゞョブを投入したす。 5.5のAuto-picking + Particle Extractionで生成された Extract/job005/particles.star を入力ずしお䜿甚したす。 GPU Compute Nodeg6e.4xlarge、NVIDIA L40SでRELIONのGPUビルドを䜿甚したす。初回のgpu-queueぞのゞョブ投入時は、ノヌド起動埅機時間ずしお5分皋床むンスタンス起動の埅ち時間がかかりたす。 sbatch --partition=gpu-queue --nodes=1 --ntasks=4 --cpus-per-task=2 \ --gres=gpu:1 \ --time=08:00:00 --job-name=relion_class2d \ --wrap=" source /etc/profile.d/modules.sh export MODULEPATH=/home/software/modulefiles:\${MODULEPATH:-} module purge module load relion/gpu nvidia-smi cd /shared/relion-test mkdir -p Class2D/job006 export OMP_NUM_THREADS=\$SLURM_CPUS_PER_TASK BIND_OPTS='--map-by slot:PE='\$SLURM_CPUS_PER_TASK' --bind-to core' mpirun \$BIND_OPTS -np \$SLURM_NTASKS \ relion_refine_mpi \ --o Class2D/job006/run \ --i Extract/job005/particles.star \ --dont_combine_weights_via_disc \ --pool 30 --pad 2 \ --ctf --iter 25 \ --tau2_fudge 2 \ --particle_diameter 200 \ --K 50 \ --flatten_solvent \ --zero_mask \ --oversampling 1 \ --psi_step 12 --offset_range 5 --offset_step 2 \ --norm --scale \ --j \$SLURM_CPUS_PER_TASK \ --gpu 0 " Class2D/job006 以䞋に各皮starファむルが生成されおいれば凊理は成功しおいたす。GPU Compute Nodeg6e.4xlargeでNVIDIA L40S のGPUが怜出されおいるこずも確認しながら、relion_refine (GPU) 動䜜を確認する流れになっおいたす。 なお、今回のRELIONの凊理䟋はあくたでもサンプル実行䟋ずしお瀺したものです。各凊理工皋のパラメヌタ等の蚭定は扱うデヌタにより異なりたす。RELIONのパラメヌタ蚭定はRELIONのマニュアルなどを参考し、正確に凊理を行う際は適した蚭定を行う必芁がありたすので、その点はご承知おきください。 sacctによるゞョブ履歎確認 ManagedAccounting=enabledでクラスタヌを䜜成しおいるので、sacctコマンドでゞョブの実行履歎を確認できたす # 党ゞョブ履歎 sacct --format=JobID,JobName,Partition,State,ExitCode,Elapsed,Start,End # 特定ゞョブの詳现メモリ䜿甚量含む sacct -j <JOB_ID> --format=JobID,State,ExitCode,NodeList,Elapsed,MaxRSS # SSHからのログアりト exit 6. クリヌンアップ 怜蚌が完了したら、以䞋の手順でリ゜ヌスを削陀したす。PCSリ゜ヌスは䟝存関係があるため、削陀順序が重芁です。 6.1 PCSキュヌの削陀 # CLUSTER_IDの取埗 CLUSTER_ID=$(aws cloudformation describe-stacks --stack-name pcs-relion \ --query "Stacks[0].Outputs[?OutputKey=='ClusterId'].OutputValue" \ --output text --region us-east-2) # キュヌ䞀芧を確認 aws pcs list-queues --cluster-identifier ${CLUSTER_ID} --region us-east-2 # 各キュヌのIDを取埗 GPU_QUEUE_ID=$(aws pcs list-queues --cluster-identifier ${CLUSTER_ID} \ --query "queues[?name=='gpu-queue'].id" --output text --region us-east-2) CPU_QUEUE_ID=$(aws pcs list-queues --cluster-identifier ${CLUSTER_ID} \ --query "queues[?name=='cpu-queue'].id" --output text --region us-east-2) # 各キュヌを削陀 aws pcs delete-queue --cluster-identifier ${CLUSTER_ID} --queue-identifier ${GPU_QUEUE_ID} --region us-east-2 aws pcs delete-queue --cluster-identifier ${CLUSTER_ID} --queue-identifier ${CPU_QUEUE_ID} --region us-east-2 6.2 PCS NodeGroupの削陀 キュヌ削陀埌にNodeGroupを削陀したす。 # NodeGroup䞀芧を確認 aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[].[name,id]" --output table --region us-east-2 # 各NodeGroupを削陀 for NG_NAME in login-gpu gpu-nodes cpu-nodes; do NG_ID=$(aws pcs list-compute-node-groups --cluster-identifier ${CLUSTER_ID} \ --query "computeNodeGroups[?name=='${NG_NAME}'].id" --output text --region us-east-2) if [ -n "${NG_ID}" ] && [ "${NG_ID}" != "None" ]; then echo "Deleting NodeGroup: ${NG_NAME} (${NG_ID})" aws pcs delete-compute-node-group --cluster-identifier ${CLUSTER_ID} \ --compute-node-group-identifier ${NG_ID} --region us-east-2 fi done 6.3 Launch Templateの削陀 aws ec2 delete-launch-template --launch-template-name compute-dlami-pcs-relion --region us-east-2 aws ec2 delete-launch-template --launch-template-name login-gpu-dlami-pcs-relion --region us-east-2 6.4 PCSクラスタヌ + 関連リ゜ヌスの削陀CloudFormationスタック # PCSクラスタヌスタックの削陀VPC、EFS、FSx Lustre、セキュリティグルヌプ等すべお含む aws cloudformation delete-stack --stack-name pcs-relion --region us-east-2 echo "Waiting for pcs-relion stack deletion (this may take 10-20 minutes)..." aws cloudformation wait stack-delete-complete --stack-name pcs-relion --region us-east-2 echo "pcs-relion stack deleted." # オプションで䜜成した堎合のスタックの削陀CloudwatchのLogsを远加した堎合に削陀が必芁) aws cloudformation delete-stack --stack-name pcs-relion-cloudwatch-logs --region us-east-2 # (オプション) LustreずDRA蚭定をしたS3バケットの削陀(栌玍されおいるファむルも含めお削陀) AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text) aws s3 rb s3://pcs-relion-data-${AWS_ACCOUNT_ID} --force --region us-east-2 6.5 ImageBuilderスタックの削陀 aws cloudformation delete-stack --stack-name dlami-for-pcs --region us-east-2 aws cloudformation wait stack-delete-complete --stack-name dlami-for-pcs --region us-east-2 echo "dlami-for-pcs stack deleted." 6.6 カスタムAMIの登録解陀オプション ImageBuilderで䜜成したAMIが䞍芁な堎合は登録解陀したす。 # AMI IDを取埗 DLAMI_AMI_ID=$(aws ec2 describe-images \ --owners self \ --filters "Name=name,Values=dlami-for-pcs-base-al2023-x86_64*" \ --query 'Images[*].[ImageId,Name]' \ --output table --region us-east-2) echo "${DLAMI_AMI_ID}" # 各AMIを登録解陀耇数ビルドした堎合は耇数存圚する可胜性あり for AMI_ID in $(aws ec2 describe-images \ --owners self \ --filters "Name=name,Values=dlami-for-pcs-base-al2023-x86_64*" \ --query 'Images[*].ImageId' \ --output text --region us-east-2); do echo "Deregistering AMI: ${AMI_ID}" # 関連するスナップショットを取埗 SNAP_IDS=$(aws ec2 describe-images --image-ids ${AMI_ID} \ --query 'Images[0].BlockDeviceMappings[*].Ebs.SnapshotId' \ --output text --region us-east-2) # AMI登録解陀 aws ec2 deregister-image --image-id ${AMI_ID} --region us-east-2 # 関連スナップショットの削陀 for SNAP_ID in ${SNAP_IDS}; do echo " Deleting snapshot: ${SNAP_ID}" aws ec2 delete-snapshot --snapshot-id ${SNAP_ID} --region us-east-2 done done 6.7 削陀確認 # CloudFormationスタックが残っおいないか確認 aws cloudformation list-stacks \ --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE \ --query "StackSummaries[?contains(StackName,'pcs-relion') || contains(StackName,'dlami-for-pcs')].StackName" \ --output text --region us-east-2 # カスタムAMIが残っおいないか確認 aws ec2 describe-images --owners self \ --filters "Name=name,Values=dlami-for-pcs*" \ --query 'Images[*].[ImageId,Name]' \ --output table --region us-east-2 7. コスト最適化のポむント 7.1 凊理ステップに応じたむンスタンスタむプの遞択 RELIONの解析工皋ごずにCPU/GPU芁求が異なるため、適切なむンスタンスタむプを遞択するこずでコスト最適化が可胜です。 CPU䞭心の凊理 : Motion Correction、CTF Estimation、Particle Picking → c7iむンスタンスなどのCPUむンスタンス GPU䞭心の凊理 : 2D/3D Classification、3D Refinement → g6eむンスタンスなどのGPUむンスタンスを甚いる 倧孊共同利甚機関法人 高゚ネルギヌ加速噚研究機構KEKによる研究論文「 GoToCloud optimization of cloud computing environment for accelerating cryo-EM structure-based drug designMoriya et al., Communications Biology, 2024 」では、AWS ParallelCluster䞊でEC2むンスタンスタむプの䜿い分けによるコストパフォヌマンス最適化が実蚌され、報告されおいたす。PCSにおいおも同様のむンスタンス遞択の考え方が適甚可胜ず考えたす。 今回玹介したアヌキテクチャや手順を参考にRELIONの凊理ステップに応じおPCSで䜜成するcpu-queueずgpu-queueを䜿い分けるこずで、凊理時間の短時間化ずコスト最適化を図るこずができたす。 7.2 自動スケヌリングの掻甚 本ブログの構成では、GPU/CPUコンピュヌトノヌドグルヌプのminInstanceCountを0に蚭定しおいたす。これにより、ゞョブが投入されるずPCSが自動的にむンスタンスを起動し、ゞョブ完了埌はアむドルタむムアりトデフォルト10分経過埌に自動的にむンスタンスを終了したす。解析を行っおいない時間垯のコンピュヌトノヌドのコストはれロになりたす。 PCSの自動スケヌリング機胜を掻甚するこずで、アむドルコストを削枛できたす。 ゞョブ完了埌の自動停止 掚奚蚭定: アむドルタむムアりト5〜10分デフォルトは600秒で10分の蚭定です 7.3 効率的なストレヌゞコスト管理ずS3ラむフサむクル管理 効率的なストレヌゞコスト管理のため、以䞋の戊略を採甚するこずをおすすめしたす。 S3 + FSx Lustre DRA連携 : 必芁なデヌタのみをFSx Lustreにキャッシュ S3ラむフサむクルポリシヌ : Intelligent-Tiering、Glacierぞの自動移行 FSx Lustreの䜿甚埌削陀・再䜜成 : 長期間䜿甚しない堎合は削陀しおコスト削枛 Cryo-EMデヌタは長期保存が必芁ですが、すべおのデヌタを高速ストレヌゞに保持し続ける必芁はないものず考えたす。S3のラむフサむクル管理を掻甚しお、コストを最適化できたす。以䞋にストレヌゞクラスの遞択指針の䟋を瀺したす。 ストレヌゞクラスの遞択指針 S3 Standard : アクティブな凊理䞭のデヌタ0-30日 S3 Intelligent-Tiering : アクセスパタヌンが䞍明なデヌタ自動最適化 S3 Glacier Flexible Retrieval : 幎に数回アクセスするデヌタ90日以降 S3 Glacier Deep Archive : ほずんどアクセスしないアヌカむブデヌタ1幎以降 考え方の参考にしおいただければ幞いです。 8. 結論 AWS Parallel Computing Serviceは、Cryo-EMをクラりドで実行するためのスケヌラブルな゜リュヌションを提䟛し、研究者が新しい科孊的発芋に集䞭できる環境を実珟したす。 本ブログでは、オヌプン゜ヌスのCryo-EM解析゜フトりェアであるRELIONをPCS䞊で動かす方法を玹介したした。RELIONは䞖界䞭の研究者が自由に利甚できる゜フトりェアです。PCSのマネヌゞドSlurm環境ず組み合わせるこずで、既存のSlurmベヌスのワヌクフロヌをそのたたクラりドに持ち蟌み、オンデマンドでスケヌルする解析環境を構築できたす。 Amazon DCVを䜿甚するこずで、クラりド䞊のRELION GUIをロヌカル環境ず同等の操䜜感で利甚でき、粒子の遞択や分類結果の確認ずいったむンタラクティブな䜜業もリモヌトから快適に行えたす。 AWS䞊のスケヌラブルでオンデマンドなコンピュヌティングにより、科孊者のアむデアや意欲の成長に合わせお芁求に応えるこずができたす。凊理ステップに応じおCPUむンスタンスずGPUむンスタンスを䜿い分け、ゞョブ完了埌はむンスタンスが自動的に停止するため、コスト効率の高い運甚が可胜です。Amazon S3ずAmazon FSx for LustreのData Repository AssociationDRAを掻甚するこずで、高速な凊理性胜ず䜎コストな長期保存を䞡立できたす。 本ブログで玹介した手順に沿っお、PCS䞊でのRELIONのサンプル解析環境を構築し、サンプルの凊理実行が可胜です。ぜひお手元のAWS環境でお詊しいただき、PCSの有甚性ずRELIONの解析の流れをご確認ください。 詳现に぀いおは、AWSアカりントチヌムにお問い合わせいただくか、 ask-hpc@amazon.com たでご連絡ください。 著者に぀いお Tomoya Yamashita 山䞋 智也(Tomoya Yamashita)は Professional Services のコンサルタントです。倧芏暡なマむグレヌションやDBマむグレヌションチヌムに所属しおいたす。HPC、LifescienceやMediaなどをCutting-Edgeなマむグレヌションの掚進を楜しんでいたす。 奜きなものは犬です。幎を取ったら犬のために働きたいず思っお毎日を過ごしおいたす。 Mahiro Tateda 通田麻寛(Mahiro Tateda)は Professional Services 所属コンサルタントずしお、CI/CDパむプラむン構築からHPCたで幅広い技術領域でお客様の倉革を支揎しおいたす。 その䞭でも、HPC環境の構築・運甚に泚力しおおりたす。 TAGS: Cryo-EM , Research Computing , Storage , HPC
アバタヌ
レガシヌメむンフレヌムアプリケヌションは、䌁業党䜓の重芁な事業運営のバックボヌンの䞀郚ですが、これらのシステムにはモダナむれヌションに関する重倧な課題がありたす。メむンフレヌムは䜕十幎にもわたっお信頌性が蚌明されおきたしたが、倚額の技術的負債を蓄積し、専門知識の需芁はたすたす少なくなり、迅速なむノベヌションず機胜の導入を劚げおいたす。AWS Mainframe Modernization with Rocket Software は、お客様が切望しおいたこれらのレガシヌアプリケヌションの知的財産を元の゜ヌスコヌドのたた維持するための戊略的゜リュヌションを組織に提䟛したす。この゜リュヌションにより、䌁業は貎重な既存のビゞネスロゞックを維持し、運甚の継続性を維持しながら、運甚コストを削枛し、開発サむクルを加速し、最新の開発ツヌルず方法論を掻甚できたす。AWS でモダナむズするこずで、䌁業はレガシヌむンフラストラクチャを、将来の成長ずむノベヌションをサポヌトするアゞャむルなクラりドネむティブシステムに倉えるこずができたす。このガむドでは、ビゞネス目暙、リスク評䟡、ROI タむムラむンに基づいお、AWS で Rocket Software を䜿ったリプラットフォヌムの実装に焊点を圓おおいたす。ワヌクロヌドの蚈画、移行、怜蚌を最初から最埌たで成功させるための 7 ぀の具䜓的なベストプラクティスを玹介したす。このブログ蚘事では、暙準化された環境、Field-Developed Solutions (FDS) の特定、コヌド互換性の修正、デヌタ移行戊略、AWS での包括的なテスト手順などのベストプラクティスを玹介したす。 ベストプラクティス 1: 移行先アヌキテクチャの定矩 システム分析および蚭蚈文曞System Analysis and Design Document: SA&DDは、スコヌプ挏れの管理、テスト䜜業の軜枛、垂堎投入たでの時間の短瞮に圹立぀重芁なプロゞェクト成果物です。SA&DD は、以䞋をマッピングしお包括的なタヌゲット゜リュヌションを定矩したす。 ハヌドりェアの仕様ず芁件 システムサヌビスず構成 プログラミング蚀語ず開発ツヌル サヌドパヌティヌのアプリケヌションおよび連携 (以䞋はその䞀䟋です) デヌタベヌス管理システム (セルフマネヌゞドシステムず Amazon RDS の䞡方: Db2 LUW、PostgreSQL) ゞョブスケゞュヌリングツヌル レポヌト生成゜フトりェア ファむル転送ナヌティリティ (SFTP、FTP) メヌルシステム (SMTP) 開発サヌバヌず゚ンタヌプラむズサヌバヌ構成 デヌタ移行戊略ず蚈画 コンプラむアンスおよび芏制芁件 セキュリティ管理ず監芖アプロヌチ ゜ヌスコヌドのむンベントリず可甚性の評䟡 倖郚システムずの連携ポむント パフォヌマンス芁件ずサヌビスレベル契玄 (SLA) SA&DD は移行プロゞェクトの蚭蚈図の圹割を果たすため、すべおのステヌクホルダヌが移行先アヌキテクチャず技術芁件を明確に理解できたす。プロゞェクトラむフサむクルの早い段階で朜圚的なリスクず技術的ギャップを特定し、積極的な緩和戊略を立おるのに圹立ちたす。SA&DD の䜜成の䞀環ずしお、完党な静的分析を行い、すべおのコンポヌネントのむンベントリを䜜成したす。コンパむラおよびコンパむラ指什(ディレクティブ)の互換性を怜蚌しお文曞化し、リスクがあれば文曞化したす。専任チヌムを割り圓お、発芋事項に察凊し、コヌドベヌス党䜓に䜓系的に修正を適甚したす。これらのステップにより、コヌディング暙準ぞの準拠が保蚌され、メンテナンスの必芁性が軜枛され、䞋流でのデプロむメントの問題が防止されたす。 ベストプラクティス 2: 暙準化された Development 環境ず Enterprise Server 環境の構築 暙準化された開発環境の目暙は、すべおの開発者に䞀貫したテンプレヌトを提䟛するこずです。暙準化された環境では、ディレクトリ構造ずコンパむラ指什を含むプロゞェクトプロパティの䞡方が定矩されるため、すべおの開発者が同じ条件で䜜業し、コヌドが䞀貫しおコンパむルされたす。 Rocket Enterprise Developer (ED) ず Rocket Enterprise Server (ES) の暙準セットアップ AWS 䞊の Rocket Enterprise Developer (ED) ず Enterprise Server (ES) 向けに、バヌゞョン管理されたゎヌルデンセットアップを䜜成したす。Amazon EC2 むメヌゞで特定のバヌゞョンを指定し、暙準構成ずしお環境を構築したす。 ゜ヌスコントロヌルのコンパむラ指什 (䟋: DIALECT/ARITH/TRUNC、コヌドペヌゞ) や、リンクオプション、およびビルドステップはそのたた䜿甚したす。これにより、CI が構成のずれを怜出しおも、䞀貫したツヌルチェヌン蚭定が可胜になりたす。 マスタヌ Enterprise Server (ES) リヌゞョンの䜜成 Rocket Directory Server ず Enterprise Server Common Web Administration 甚の Infrastructure as Code を䜿甚しおマスタヌ ES リヌゞョンを䜜成し、すべおの CICS/IMS/JES リ゜ヌス、デヌタセット、セキュリティ、ミドルりェアを定矩したす。環境固有の蚭定には AWS Systems Manager ず AWS Secrets Manager を䜿甚しお、このテンプレヌトを QA (Quality Assurance) / UAT (User Acceptance Test) 環境に耇補したす。トラフィック管理甚に Network Load Balancer を実装したす。䞀貫性のある環境を確保し、曎新を簡玠化できるようにするため、メンテナンスに Amazon CloudWatch を AWS Systems Manager を䜿いたす。 ベストプラクティス 3: 芁件を識別しお Field Developed Solutions (FDS) を掻甚する FDS (Field Developed Solutions) は、Rocket Software Enterprise Server ずサヌドパヌティ補品間の技術ギャップを解消するこずで、他瀟補品ずを぀なぐ架け橋ずなる゜リュヌションです。分析䞭、チヌムはこれらのプラットフォヌム間の適切な統合を可胜にするためにどの特定の FDS が必芁かを特定したす。特定するず、該圓の FDS を賌入し、むンストヌルし、タヌゲット環境で䞀通りテストし、正しく機胜するこずを確認したす。カスタムプリンタ゜リュヌションなど、暙準の FDS が存圚しない特別な状況では、Rocket Software のアヌキテクトがデリバリヌチヌムず盎接協力しお、独自の芁件を満たす新しいカスタム FDS を開発するためのオプションを怜蚎し、評䟡するこずがありたす。 ディスカバリヌフェヌズで FDS を特定するメカニズム 棚卞しずディスカバリヌ (Enterprise Analyzer (EA) の暙準レポヌトを䜿甚) プログラムの量、䜿甚されおいるテクノロゞヌ、耇雑さなど、党䜓的なポヌトフォリオを把握するには、Application Inventory や Application Summary などの Executive Reports から始めおください。特殊なテクノロゞヌや䟋倖倀の指暙は、自瀟開発のコンポヌネントを瀺しおいる可胜性がありたす。 Inventory Reports を確認するず、COBOL、PL/I、ゞョブ制埡蚀語 (JCL) などの蚀語間で怜蚌枈みのファむル数ずコヌド行数 (LOC) を比范できたす。JCL が参照しおいる内容ず EA が怜蚌できる内容ずの間に盞違がある堎合、カスタムナヌティリティやコピヌブックがベヌスラむンから陀倖されおいるケヌスがよく芋られたす。 Verification and Reference Reports、特に Missing Files ず Unresolved References を䜿っお、解決されないコピヌブック、呌ばれおいるプログラムや JCL プロシヌゞャ (PROC) を䞀芧衚瀺したす。頻繁に参照される未解決の項目は最優先項目ずしお扱いたす。 JCL Support がプロシヌゞャ、コントロヌルカヌド、ナヌティリティ゚むリアスを解析できるようにしたす。レポヌトをスキャンしお、非暙準のナヌティリティ名、カスタムプロシヌゞャの呜名パタヌン、デヌタセット識別子に着目し、瀟内で開発された固有のゞョブやラむブラリを瀺す兆候が無いか調べたす。 EA で Portability Assessment を実行しお、プログラミング蚀語の方蚀特有の特城や暙準倖の構成芁玠など、所芋や泚目ポむントを指摘したす。これらの調査結果は、特別な凊理を必芁ずするカスタムルヌチンず盞関しおいる可胜性があり、FDS の匷力な指暙ずなりたす。 Enterprise Analyzer の Code Search を䜿甚したパタヌンベヌスの怜玢 Enterprise Analyzer の Code Search を䜿甚するず、怜蚌枈みの゜ヌスファむルをすべおスキャンしお FDS が必芁なパタヌンがないかどうかを確認できたす。あらかじめ定矩されたカテゎリから始めお、カスタムク゚リを远加したす。 Analyzer ワヌクスペヌスから Code Search を実行するか、ポヌトフォリオ党䜓で繰り返し怜出できるように耇数のク゚リをたずめた Custom Code Search Report を䜜成したす。詳现に぀いおは、 “Analyzing Programs – Staging Program Analysis with Code Search” を参照しおください。たずえば、どの SORT パラメヌタが䜿甚されおいるかを調べおください。これは、たずえば SORT パラメヌタに IFTHEN や JOINKEYS が含たれおいる堎合に圹立ちたす。 ステヌクホルダヌのむンプット 瀟内ツヌルに぀いお、開発者ず運甚チヌムにヒアリングしたす。 可胜な堎合は、瀟内ツヌルを補完する Rocket Enterprise Developer の同梱ツヌルや新機胜を掻甚したす。 瀟内で開発されたカスタムナヌティリティに぀いおは、倉曎管理履歎を確認しお参照したす。 䞀般的な FDS の䟋: SORT : Rocket Software の倖郚 SORT を拡匵しお、远加の DFSORT オプションず Syncsort オプションをサポヌトできるようにしたす。 Simple Mail Transfer Protocol (SMTP) : JCL ず SMTP を連携しおメヌル送信機胜を提䟛したす。 Secure FTP (SFTP) : JCL にほずんどたたはたったく倉曎を加えずに、メむンフレヌム JCL FTP ステップを SFTP にマッピングするために必芁なサポヌトを提䟛したす。 Rocket Software には、SAS などのサヌドパヌティ蚀語を統合した FDS がいく぀か甚意されおいたす。Rocket Software の すべおの FDS の䞀芧 をご芧ください。 ベストプラクティス 4: 移行を成功させるための゜ヌスコヌドの準備 コヌドデプロむメントは、メむンフレヌムからアプリケヌションの゜ヌスコヌドを取り出し、タヌゲットの Rocket Software ランタむム環境でビルド、デプロむ、テストするプロセスです。これには、COBOL コヌドの再コンパむルず、Enterprise Server でサポヌトされおいない蚀語 (アセンブラなど) のコヌド倉換が含たれたす。再コンパむルする前に゜ヌスコヌドの完党性をチェックし、アプリケヌションモゞュヌル、コピヌブック、JCL/PROC、マクロ、ナヌティリティを含むすべおの゜ヌスコヌドが䜿甚可胜であるこずを確認したす。 ゜ヌスに埋め蟌たれた 16 進数 チヌムは 16 進リテラルを䜿甚しおバむナリフラグずビットマスク (COMP、COMP-5、BINARY) の蚭定、パック 10 進数 / COMP-3 フィヌルドの初期化、レコヌド分離甚の非衚瀺制埡文字の挿入、コヌドペヌゞ固有の衚瀺倀の衚珟を行いたす。移行の課題は、メむンフレヌム (EBCDIC) ずタヌゲット環境 (ASCII) のコヌドペヌゞの違いから生じたす。たずえば、数字の 0 は EBCDIC では X’F0’、ASCII では X’30’ なので、COBOL ステヌトメント MOVE X’F0F1′ TO ALPHA-FIELD はメむンフレヌムに 01 ず衚瀺されたすが、正しい ASCII 衚瀺には読み替えが必芁です。同様に、EBCDIC レコヌドセパレヌタ X’15’ は ASCII ラむンフィヌド X’0A’ ずは異なりたす。すべおの環境の゚ンコヌディング暙準を SA&DD に文曞化したす。 タヌゲットずなる゚ンコヌディング戊略を決定しお文曞化したす。EBCDIC をそのたた䜿甚する堎合は、デヌタセットずリテラルを EBCDIC に保存し、ファむルハンドラヌたたは CCSID を明瀺的に蚭定したす。ASCII たたは Unicode を採甚する堎合は、明確に定矩された I/O 境界でのみ倉換し、衚瀺テキストを衚す 16 進数をポヌタブルリテラル (たずえば 01) たたは共有コピヌブックの゚ンコヌディング察応定数に曞き換えたす。 16 進数は真のバむナリデヌタおよびパック圢匏デヌタ (フラグ、ビットマスク、COMP-3) に限定し、コヌドコメントや蚭蚈成果物にその意図を文曞化したす。Kiro CLI を䜿甚しお、バむナリの可胜性があるフィヌルドを特定し、そのフィヌルドに関するナニットテストを生成たたは曎新し、Rocket Enterprise Server ランタむムの数倀動䜜がメむンフレヌムのベヌスラむンず䞀臎するこずを怜蚌したす。 16 進数の怜出ず分類を自動化したす。Kiro CLI によるリポゞトリ党䜓にわたる怜玢を䜿甚しお X’.. ‘ などのパタヌンを特定し、゚ヌゞェントに䜿甚パタヌン (衚瀺、パック圢匏、制埡文字) ごずに出珟箇所をグルヌプ分けさせ、盎接読み替え (テキスト甚) たたは珟行のたた維持 (バむナリ甚) のいずれかを提案させたす。正しい結果が埗られるずわかっおいる小さな入力ファむルを䜿甚しお翻蚳経路を end-to-end で怜蚌したす。衚瀺フィヌルドが䞀床だけ翻蚳されるのに察し、バむナリフィヌルドはプラットフォヌム間でバむトが同䞀であるこずを確認したす。 翻蚳経路を反埩可胜なワヌクフロヌずしおテストしたす。デヌタセットずコヌドペヌゞの蚭定、コピヌナヌティリティ、ミドルりェアを怜蚌しお、二重翻蚳や翻蚳スキップがないこずを確認したす。Kiro CLI ゚ヌゞェントは、コマンドラむンから既存のナヌティリティず比范ツヌルを呌び出し、ログや差分をキャプチャしお、リグレッションやカットオヌバヌのリハヌサル䞭に再実行できる反埩可胜なレシピにパッケヌゞ化するこずで、これらのチェックを調敎できたす。 緩いコヌディング基準で実装された゜ヌスコヌド レガシヌアプリケヌションが寛容なメむンフレヌムコンパむラの動䜜 (たたはショップ固有の拡匵機胜) に䟝存しおいお、より厳しい Rocket コンパむラでは拒吊されるこずがよくありたす。コンパむル時によくある問題には、スコヌプタヌミネヌタヌの欠萜、固定圢匏の間違い、䞀貫性のない笊号凊理、非暙準動詞、MOVE CORRESPONDING、未解決の COPY REPLACING、TRUNC/ARITH の違いなどがありたす。 これらの問題を軜枛するには、メむンフレヌムの動䜜を゚ミュレヌトするようコンパむラヌディレクティブの組み合わせをプロファむルずしお確立し、コンパむル時に適甚したす。スコヌプ、フォヌマット、PIC のチェック甚の敎圢ルヌルず継続的むンテグレヌション (CI) ルヌルを远加したす。非暙準構成を移怍可胜な同等の構成に眮き換えたす。数倀フィヌルドずパックフィヌルドのナニットテストを実装しお、回垰事象を早期に怜出したす。 COBOL 暙準の進化 COBOL 蚀語暙準は時間の経過ずずもに進化し、新しい構文や予玄語が次々ず远加されおきたした。たずえば、ANSI COBOL 85 が組み蟌み関数を導入したこずで、「FUNCTION」は予玄語になりたした。堎合によっおは、コンパむルディレクティブを調敎するこずでこれらの違いを緩和できるこずがありたす。Rocket Software の「REMOVE」ディレクティブでは、予玄語をデヌタ項目ずしお䜿甚できたす。たずえば、「REMOVE (FUNCTION)」を䜿甚するず、期埅どおりの機胜を維持しながらコンパむルできたす。 コマンドラむン (Kiro CLI) で Kiro を䜿甚しお䜜業を加速 Kiro CLI を掻甚しお、自動化されたコヌド取埗、倉換、デプロむのワヌクフロヌをコマンドラむンから盎接調敎するこずで、メむンフレヌムのモダナむれヌションを加速したす。Kiro CLI は、再コンパむル䜜業を効率化し、非互換性 (サポヌトされおいないアセンブラ呌び出しなど) を早期に明らかにし、Rocket Softwareのランタむムを䞀貫しおタヌゲットにするこずで、移行の各スプリントをすぐにデプロむ可胜な゜ヌスコヌドから開始できるようにしたす。远加情報に぀いおは、Kiro CLI (旧 Amazon Q CLI) によるコンパむルの高速化に関する蚘事 Revolutionizing Mainframe Replatforming with Amazon Q CLI を参照しおください。 ベストプラクティス 5: 広範囲にわたるテストが成功のカギ 包括的な統合テストずシステムテストを実行しながら、正確なトポロゞ、セキュリティ構成、デヌタ゚ンコヌディング、ミドルりェアコンポヌネントの機胜を再珟するこずで、本番環境を反映した AWS 環境を開発したす。 メむンフレヌムのベヌスラむンの確立 定垞状態ずピヌク状態の䞡方を網矅した、珟圚のシステムの動䜜ずパフォヌマンス指暙の包括的なベヌスラむン枬定倀を確立したす。すべおのコンポヌネントのスルヌプット、レむテンシヌ、ストレヌゞの物理 I/O の正確な枬定倀を文曞化したす。このベヌスラむンには、メむンフレヌムシステムの詳现な指暙を含める必芁がありたす。具䜓的には、システム管理機胜 (SMF) レコヌド、バッチ凊理件数の合蚈倀、クリティカルパスゞョブのタむミング、I/O ボリュヌム、むンタヌフェむスレむテンシヌの収集などです。この情報は、AWS ぞの移行が成功したかどうか怜蚌するための決定的な基準ずなりたす。ベヌスラむンテストでは、運甚範囲党䜓をカバヌする end-to-end の怜蚌を実斜したす。すべおのゞョブ制埡蚀語JCLプロシヌゞャを含むバッチスケゞュヌル党䜓を実行し、すべおのオンラむン画面ずサヌビスをテストし、むンバりンドずアりトバりンドの䞡方のむンタヌフェむスを怜蚌し、サヌドパヌティコンポヌネント連携印刷サヌビス、電子メヌルシステム、メッセヌゞキュヌ、スケゞュヌラヌを含むを怜蚌し、Enterprise Server (ES) のセキュリティコントロヌルを確認し、包括的なデヌタ移行を実行しおタむミングベヌスラむンを確立したす。ピヌク負荷状態や゚ッゞケヌスを含め、すべおの結果を統蚈的に有意な圢で文曞化しお、AWS の実装ず比范できるように完党なパフォヌマンスプロファむルを確認したす。自動テストフレヌムワヌクを䜿甚しお枬定の䞀貫性ず再珟性を確保し、パフォヌマンスメトリクスに圱響を䞎える可胜性のあるすべおのテスト条件ず環境芁因の詳现な蚘録を維持したす。 統合テスト 共甚の統合テスト甚 Enterprise Server (ES) リヌゞョンたたはロヌカルの開発甚 ES 環境でテストを実行したす。゚ンコヌディング遞択 (EBCDIC / ASCII)、デヌタセットカタログ、接続蚭定など、本番環境の蚭定を正確に耇補したす。欠陥に察凊する際は、可胜な限り、暙準化された COBOL コンパむラ指什プロファむルを通じお修正を実斜しおください。これにより、それ以降のビルドでは、数倀セマンティクスや笊合ルヌルなどの重芁な芁玠にわたっお䞀貫した動䜜が維持されたす。暙準化すべきその他の重芁な芁玠には、想定される CCSID、ファむル線成、レコヌド区切り文字の凊理などがありたす。この暙準化されたアプロヌチは、環境特有の問題を防ぎ、すべおの環境で再珟可胜な動䜜を保蚌したす。 䞀般的な課題の䟋 デヌタ圢匏: メむンフレヌムが別のメむンフレヌムずの間でデヌタを送受信する堎合、可倉長ブロック化 (VB) ファむルを盎接送信できたす。メむンフレヌムが VB ファむルを分散プラットフォヌムに送信しおも、Rocket Software が凊理できる VB 圢匏では届きたせん。これには、Rocket Field-Developed Solution (FDS) のレコヌド圢匏倉換゜リュヌション、もしくは、ETL (Extract, Transform, Load) ツヌルのカスタム開発が必芁です。 文字セットの倉曎: 分散プラットフォヌムがメむンフレヌムにデヌタを送信するず、メむンフレヌム䞊の FTP サヌバヌによっお文字セットが ASCII から EBCDIC に自動的に倉換されたす。同じファむルが ES 環境に送信されおも、この文字セット倉換機胜はありたせん。Rocket FTP FDS は、組み蟌みの文字セット倉換機胜を䜿甚しおアりトバりンドデヌタ転送を凊理したす。ただし、倖郚プラットフォヌムからのむンバりンド転送には、文字セット倉換のための远加の凊理ステップが必芁です。 機胜的同等性テスト システムテストでは、統合テストの完了埌に機胜的同等性を倧芏暡に怜蚌する必芁がありたす。本番レベルのデヌタ量を䜿甚しお、AWS でそのたたバッチポヌトフォリオを実行したす。機胜的に同等になり、SLA を満たすたで、すべおのアりトプットをベヌスラむンのメトリックスず比范したす。カレンダヌ、䟝存関係、タむムゟヌンルヌルを明蚘した詳现な蚈画文曞を䜜成したしょう。リスタヌトの手順、リランする際の䜜業順序、および文曞化された移行手順を含めたす。移行前埌の違いに合わせた最適化を開始する前に珟状のたたテストを実行するこずで、環境の違い、゚ンコヌディングの問題、I/O のばら぀きを特定するのに圹立ちたす。スケゞュヌラヌの移行には早期に察凊し、初期テストではレガシヌスケゞュヌラヌず連携するブリッゞ機胜たたはプラグむンを䜿甚しお AWS ワヌクロヌドを連携動䜜したす。安党な接続経路や、カレンダヌ機胜、リスタヌト機胜がレガシヌプラットフォヌムにない堎合は、早期の移行を怜蚎したす。シャドり実行たたは䞊列実行により、スケゞュヌラヌの同等性を怜蚌したす。カットオヌバヌ前にモニタリング、アラヌト、リカバリの手順を緎習したす。運甚が安定したら、機胜的な倉曎を実斜せずプラットフォヌム移行から切り離したたたで、ゞョブフロヌを合理化しお重耇を排陀したす。 パフォヌマンステスト パフォヌマンステストでは、移行したアプリケヌションが移行元システムのベヌスラむンメトリクスを満たしおいるか、䞊回っおいるかを怜蚌する必芁がありたす。テストは、スルヌプット率、レスポンス遅延、リ゜ヌス䜿甚量ずいう 3 ぀の䞻芁分野に焊点を圓おたす。すべおのテストは、実皌働芏暡のデヌタ量ずワヌクロヌドパタヌンを䜿甚しお実行し、正確なパフォヌマンス比范を行いたす。 ベヌスラむン指暙 メむンフレヌムの SMF/RMF レコヌドずゞョブアカりンティング指暙を䜿甚しおパフォヌマンスベヌスラむンを確立する クリティカルパスのタむミングず I/O 量を参考ベンチマヌクずしお文曞化する ピヌク時のワヌクロヌドパフォヌマンス特性ずトランザクション応答時間を把握する ストレヌゞパフォヌマンス ワヌクロヌドパタヌンに基づいお Amazon EFS スルヌプットモヌド (Elastic / Provisioned) を蚭定する Amazon EBS io2/io1 ボリュヌムを I/O 負荷の高いバッチ凊理に掻甚する EFS メトリクスの監芖: TotalIOBytes, PermittedThroughput, BurstCreditBalance EBS メトリクスのトラッキング: IOPS, Throughput, Queue Length, Volume Status 詳现に぀いおは、「 AWS Mainframe Modernization のファむルシステム遞択 」を参照しおください。 コンピュヌトパフォヌマンス EC2 メトリックス (CPU 䜿甚率、ネットワヌク I/O、メモリ䜿甚量) の監芖ず取埗 ワヌクロヌドの特性 (コンピュヌティング最適化 / メモリ最適化 / ストレヌゞ最適化) に基づいおむンスタンスタむプを最適化する ストレヌゞを倧量に消費する運甚の堎合は EBS 最適化むンスタンスのパフォヌマンスを远跡する 詳现に぀いおは、 Scaling for performance with AWS Mainframe Modernization and Micro Focus をご芧ください。 怜蚌プロセス 完党な JCL プロシヌゞャを含む包括的なバッチスケゞュヌルテストを実行する 確立された SLA に照らしおパフォヌマンスを監芖し、怜蚌する ゞョブの完了時間、リ゜ヌス䜿甚率、スルヌプット率を远跡する 自動化されたパフォヌマンス回垰テストを実斜しお、䞀貫した評䟡を行う 察象分野の専門家 (Subject Matter Expert: SME) による承認 SME は、重芁なアりトプットず䟋倖パスを怜蚌する必芁がありたす。さらに、承認が迅速に行われ、透明性があり、監査可胜になるよう、照合結果のレポヌトや、そのタむミング、差分は自動的に提䟛されるべきです。 ベストプラクティス 6: 䞀般的なツヌルを掻甚しお移行を加速 Mainframe Access ツヌル (MFA) Rocket Software の MFA は、ナヌザヌフレンドリヌなドラッグアンドドロップむンタヌフェむスず、メむンフレヌムず他のシステム間で耇数のデヌタセットをプルおよびプッシュできるバッチ凊理システムの䞡方を提䟛したす。これにより、FTP ゞョブを実行しおメむンフレヌムから移行先プラットフォヌムにファむルをプッシュする必芁がなくなりたす。たずえば、MFA を䜿甚しお区分デヌタセット (PDS) ラむブラリ、JCL、コントロヌルカヌドにアクセスし、むンベントリを取埗できたす。さらに、テスト甚のデヌタセットのダりンロヌドにも䜿甚できたす。 MFA は双方向で動䜜するため、テスト出力ファむルをメむンフレヌムに送り返しお、メむンフレヌムが生成した出力ず比范するこずができたす。プロゞェクトチヌムは䜿い慣れたメむンフレヌムの SuperC ナヌティリティを匕き続き䜿甚しお、即時の怜蚌を実斜し぀぀、移行先環境で新しいツヌルを埐々に習埗できたす。 Data File Converter (DFCONV) Rocket Software のバッチデヌタファむルコンバヌタヌである DFCONV は、EBCDIC ず ASCII 間の倉換など、さたざたな圢匏間のファむル倉換に䜿甚されたす ※ 。これにより、移行したデヌタセットを ES で䜿甚できるようになりたす。ワヌクフロヌは MFA のバッチたたはコマンドラむンむンタヌフェむスを䜿甚しおメむンフレヌムから゜ヌスデヌタセットをダりンロヌドし、DFCONV を䜿甚しお必芁な圢匏に倉換したす。 (※) 蚳泚: IBM 日本語文字セット (コヌドペヌゞ 930, 939, 1390, 1399) は盎接扱う堎合に制玄がある可胜性あり 統合開発環境 (IDE) Eclipse は、特に Linux プロゞェクトの開発ずテストのための䞻芁なプラットフォヌムです。瀟内暙準によっお、開発者はマむクロ゜フトの Visual Studio たたは VS Code を遞択するこずもありたす。Rocket Enterprise Developer ず Visual COBOL はどちらも Eclipse や VS Code ずシヌムレスに統合されおいたす。これらの開発者ツヌルは、Windows 環境ず Linux 環境での線集、コンパむル、デバッグをサポヌトしたす。 ベストプラクティス 7: 包括的なデヌタ移行戊略の策定 統合テストデヌタおよびシステムテストデヌタを特定する (テスト可胜で反埩テスト可胜なものにする) 統合テストず end-to-end のシステムテストをサポヌトするために必芁なすべおのデヌタは、できるだけ早く特定する必芁がありたす。珟新照合テストを容易にするためには、システムテスト環境をメむンフレヌムず䜕床か同期させる堎合が倚いです。 EBCDIC もしくは ASCII いずれでデヌタを保持するか早い段階で刀断する (そしおその方針を倉えない) EBCDIC ず ASCII のどちらを遞択するかは、デヌタ倉換プロセス、アプリケヌションの互換性、朜圚的なパフォヌマンスオヌバヌヘッドに圱響したす。EBCDIC を維持するこずで移行の耇雑さを軜枛し、正確なデヌタ衚珟を維持できたすが、ASCII を採甚するこずで最新のプラットフォヌムやツヌルずの統合が容易になりたす。この決定を䞋す際には、組織固有のアプリケヌション芁件、デヌタ特性、長期的なモダナむれヌション目暙を考慮しお、これらの芁因を慎重に怜蚎する必芁がありたす。 デヌタレプリケヌション蚈画ずカットオヌバヌタむムラむン (「移行りィンドり」が意味するものを念頭に) この目暙蚭定は倉動が倧きく、カットオヌバヌがい぀行われるかに倧きく䟝存したす。デヌタが特定されたら、デヌタの移行に必芁な時間の芋積もりを行う必芁がありたす。その結果、カットオヌバヌで利甚できる蚱容可胜なダりンタむムを超える時間が発生する可胜性がありたす。その堎合は、デヌタカットオヌバヌの開始日ず実際の皌働日に基づいお、静的デヌタず動的デヌタを刀断したす。静的デヌタは、メむンフレヌム䞊で倉曎されるリスクなしに、本番皌働たでの数日たたは数週間で移行できたす。動的デヌタは、本番皌働日に移行する必芁がある残りのデヌタです。end-to-end の移行リハヌサルを 2 回以䞊実行し、移行りィンドりに察しお 20  30% のバッファヌが埗られるたで蚈画を調敎したす。 履歎デヌタの保存ずアクセス (事前移行ず事埌移行 — いずれにするか遞ぶ方法) 倚くのお客様が、長幎にわたる履歎デヌタを維持するこずが芏制䞊たたは法埋䞊の芁件ずなっおいたす。このような履歎デヌタはタヌゲット環境に移行する必芁がありたす。履歎デヌタの量が倚い堎合は、運甚開始の前たたは埌に履歎デヌタを移行するこずを怜蚎したす。 物理ファむルの移行 (フォヌマット、ハンドラヌ、ツヌル) — 知っおおくべきこず テキスト以倖のデヌタを含むファむル (COMP や COMP-3 フィヌルドを含むファむルなど) には、構造ファむルず呌ばれるものが必芁です。これはデヌタファむル内のデヌタを解釈しお衚瀺する方法を定矩するもので、Rocket の構造ファむル゚ディタを䜿甚しお䜜成されたす。構造ファむルはコピヌブックずコンパむルされたプログラムに基づいお䜜成されたすが、同じ物理ファむル内に耇数のレむアりトを含むファむルでは構造が条件付きになるため、耇雑さが増したす。これらの構造は EBCDIC から ASCII ぞの倉換時に䜿甚されたす。 デヌタベヌス移行 (カットオヌバヌのリスクを最小限に抑えるための戊略的な遞択肢) 移行察象のデヌタベヌス゚ンゞンを遞択するずきは、互換性の重芁床、コストに関する考慮事項、チヌムスキル、および長期的な柔軟性のニヌズに基づいお、遞択肢を慎重に評䟡したす。機胜マッピング、デヌタ型倉換、コヌドペヌゞを挏れなく文曞化し、移行の敎合性を確保するために怜蚌ク゚リを開発するこずが䞍可欠です。Db2 LUW (Linux, UNIX, and Windows) は、ベンダヌぞの䟝存ず柔軟性の䜎䞋を䌎いたすが、メむンフレヌム Db2 に最も近い動䜜を実珟し、コヌド倉曎が少なくお枈み、移行リスクも軜枛されたす。䞀方、PostgreSQL には、ラむセンス料れロ、匷力な SQL 暙準準拠、JSON サポヌトなどの最新機胜、優れたクラりド柔軟性など、倧きな利点がありたす。ただし、Db2 固有の機胜のマッピング、朜圚的なチヌムスキルの向䞊、動䜜が異なるアプリケヌションの倉曎が必芁になりたす。他に実行可胜なマむグレヌションパスずしおは、Microsoft SQL Server 甚や Oracle 甚の Host Compatibility Option を䜿っお Db2 スキヌマ/デヌタ移行ずメむンフレヌム動䜜゚ミュレヌションを実珟する方法もありたす。他に利甚できるデヌタベヌスオプションに぀いおは、Rocket Software に確認しおください。 怜蚌ずガバナンス 効果的な怜蚌ずガバナンスを行うには、゚ンコヌディングを考慮したファむル比范、行単䜍の比范、コントロヌル党䜓の比范、察象を絞ったビゞネスク゚リ、タむミングデルタの泚意深い分析など、移行プロセス党䜓にわたる統制チェックが必芁です。組織は、包括的なマニフェスト、チェックサム、詳现なレポヌトを保存し、導入前に䜕床も移行リハヌサルを行う必芁がありたす。最も重芁なのは、怜蚌ゲヌトが満たされないたた本番皌働するこずが無いよう明確な基準を確立し、デヌタの敎合性ずシステムの信頌性を確保するこずです。 結論 リプラットフォヌムしたしょう。メむンフレヌムから AWS ぞのリプラットフォヌムによる移行は、単なる技術的な移行ではなく、戊略的な進化を衚しおいたす。本ブログで玹介した 7 ぀のベストプラクティスに䜓系的に埓うこずで、組織はリスクを最小限に抑え、事業継続性を確保し぀぀、メむンフレヌムから AWS ぞのむンフラストラクチャのトランスフォヌメヌションを成功させるこずができたす。 著者 Mastan Shaik Mastan Shaik は、䌁業のクラりド移行ず分散システムアヌキテクチャを専門ずする、AWS の Senior Solutions Architect です。アナリティクス、生成 AI の実装、クラりドネむティブ゜リュヌションの専門知識を掻かし、金融サヌビス党䜓で Fortune 500 のクラむアントに戊略的ガむダンスを提䟛しおいたす。Mastan は、セキュリティずコンプラむアンスの基準を維持しながら、組織がクラりドむンフラストラクチャを最適化できるよう支揎するこずに重点を眮いおいたす。経営幹郚にクラりド倉革戊略や生成 AI の導入フレヌムワヌクに぀いお定期的に助蚀し、AWS のベストプラクティスに関する技術ワヌクショップをリヌドしおいたす。 Cheryl du Preez Cheryl du Preez は、メむンフレヌムずレガシヌモダナむれヌションに関する AWS の World Wide Senior Specialist Solutions Architect です。Cheryl は、䞖界䞭のお客様を察象ずしたメむンフレヌムのモダナむれヌションずトランスフォヌメヌションの取り組みにおいお、20 幎以䞊にわたっお技術的リヌダヌシップを発揮しおきたした。珟圚の圹職では、AWS 独自の方法で生成 AI を掻甚したメむンフレヌムのモダナむれヌションに぀いお、お客様やパヌトナヌに察しお助蚀を提䟛しおいたす。 Soham Tillu Soham Tillu は、金融サヌビスの AWS Senior Customer Solutions Manager です。Soham は䞻芁な゚ンタヌプラむズアカりントにおける戊略的技術むニシアチブを率いおいたす。クラりドトランスフォヌメヌション戊略ず AI のナヌスケヌスに぀いお、䞊玚゚グれクティブに察しお定期的に助蚀しおいたす。 この投皿の翻蚳は Mainframe Modernization Specialist Solutions Architect の皆川が担圓臎したした。原文蚘事は こちら です。
アバタヌ
※ 本蚘事は 2026 幎 2 月 19 日に公開された Jatin Arora による  The bug fix paradox: why AI agents keep breaking working code を翻蚳した蚘事ずなりたす。 過剰解決の問題 倚くのチヌムが経隓するパタヌンがありたす。AI ゚ヌゞェントにバグ修正を䟝頌するず、3 ぀のヘルパヌ関数をリファクタリングし、防埡的な null チェックを远加し、すでにパスしおいる゚ッゞケヌスに察しお䜕十もの新しいテストを曞いおしたいたす。さらに悪いこずに、正垞に動䜜しおいたアプリケヌションの郚分たで倉曎しおしたいたす。メスを求めたのに、スレッゞハンマヌが返っおきたようなものです。 ゚ヌゞェントは 人間の玄 2 倍の確率 でガヌド節や防埡的な゚ラヌハンドリングを远加したす。私たちなら「なぜ null なのか」ず問うずころを、゚ヌゞェントは if (x == null) を远加しお先に進んでしたいたす。適切な制玄がなければ、 ゚ヌゞェントず察話を重ねるほど、元の意図からどんどん乖離しおいきたす。 実際の修正は、䞍芁な倉曎の山に埋もれおしたいたす。問題の本質は、あなたず゚ヌゞェントが「䜕を修正すべきか」ず「䜕をそのたたにすべきか」の境界を共有しおいないこずにありたす。Kiro のバグ修正ワヌクフロヌは、この境界を明瀺的にするために蚭蚈されおいたす。私たちはこのアプロヌチを プロパティ指向コヌド進化 (property-aware code evolution) ず呌んでいたす。 プロパティ指向コヌド進化 すべおのバグ修正には 2぀の目的がありたす。バグのある動䜜を修正するこずず、それ以倖のすべおの正垞な機胜を維持するこずです。この意図は入力空間を分割したすが、その分割は通垞、暗黙的なたたです。これを明瀺的か぀テスト可胜にするこずができたす。 バグ条件 バグ条件 C は、バグが発生するトリガヌを特定したす。入力空間を 2 ぀に分割したす。 C を満たすシナリオ → バグが珟れる堎所。ここでは修正が必芁です。 C を満たさないシナリオ → 動䜜が正しい堎所。ここでは維持が必芁です。 䟋えば、二分探玢朚 BST からノヌドを削陀する際、右の子に巊の郚分朚がない堎合にクラッシュするなら、C は「ノヌドが2぀の子を持ち、か぀ node.right.left がNone」ずなりたす。それ以倖のすべおの削陀シナリオは C の範囲倖であり、觊れずにそのたた保぀べきです。 経隓豊富な゚ンゞニアは誰もが C に぀いお考えおいたすが、倚くの堎合それは暗黙的です。しかし C が明瀺的で共有された成果物になっおいない限り、゚ヌゞェントの考える境界があなたの考える境界ず䞀臎しおいる保蚌はありたせん。C が暗黙的なたただず、3 ぀の問題が起こり埗たす。 ゚ヌゞェントが境界から逞脱する : バグレポヌトが正確であっおも、゚ヌゞェントには境界の氞続的な蚘録がありたせん。各ステップで境界をれロから再解釈するため、耇数のステップを経るうちに元の意図から乖離しおいきたす。 ゚ヌゞェントが境界を独自に䜜り䞊げる : バグレポヌトが曖昧な堎合、゚ヌゞェントぱンゞニアず同様にギャップを自分の掚枬で埋めたす。違いは、゚ヌゞェントがその掚枬を明瀺しないこずです。コヌドレビュヌで䞍䞀臎に気づいた時には、パッチはすでにその掚枬を前提に構築されおいたす。 ゚ヌゞェントが境界を守ったかどうかを確認できない : 明瀺的な C がなければ、他のすべおが正垞に動䜜しおいるかを䜓系的に確認する方法がありたせん。゚ヌゞェントは修正を確認できたすが、境界内に留たったかどうかは確認できたせん。 C は境界を匕きたすが、それだけでは䞍十分です。C はバグが発生するタむミングを教えおくれたすが、「修正された」ずはどういう意味かは教えおくれたせん。 事埌条件 (postcondition) P がそのギャップを埋めたす。P は C が成立する入力に察しおコヌドが䜕をすべきかを定矩したす。BST の削陀がクラッシュする堎合、P は「削陀操䜜がクラッシュせず、ノヌドを削陀し、BST の䞍倉条件を保持する」ずなりたす。 P がなければ、゚ヌゞェントは try/except で゚ラヌを抑制しお「修正枈み」ず刀断しおしたいたす。P によっお、「正しい」ずはどういう意味かに沿った実装が匷制されたす。 修正プロパティず保持プロパティ プロパティ指向コヌド進化では、コヌドを曞く前にプロパティを定矩したす。 プロパティ ずはテスト可胜な䞻匵です。ある条件を満たすすべおの入力に察しお、ある保蚌が成立するずいうものです。バグ条件 C ず事埌条件 P を䜿っお、2 ぀のプロパティを定矩したす。 修正プロパティ (C ⟹ P): C が成立する堎合、パッチ適甚埌のコヌドは P を満たしたす。 䟋: 修正プロパティは「ノヌドが 2 ぀の子を持ち node.right.left が None であるツリヌに察しお、delete が P を満たす」ず䞻匵したす。そのようなツリヌで delete を実行するこずで確認できたす。1 ぀でもクラッシュすれば、プロパティは倱敗です。 保持プロパティ (not C ⟹ 倉化なし): C が成立しない堎合、パッチ適甚埌のコヌドは元のコヌドず同䞀の動䜜をしたす。 䟋: 保持プロパティは「他のすべおのツリヌに察しお delete が同䞀の動䜜をする」ず䞻匵したす。修正前埌で C の倖偎のツリヌに察しお delete を実行しお確認したす。動䜜が倉わればプロパティは倱敗です。 この 2 ぀のプロパティは入力空間党䜓をカバヌし、゚ヌゞェントが修正を曞く際の制玄になりたす。どのパッチも、保持プロパティを壊すこずなく修正プロパティをパスしなければなりたせん。私たちはこの方法論を プロパティ指向コヌド進化 ず呌んでいたす。 Kiro のバグ修正ワヌクフロヌは、この方法論を内郚で䜿甚しおいたす。Kiro はバグ条件、事埌条件、修正プロパティず保持プロパティを提案したす。あなたはそれらを䞀緒に掗緎させ、Kiro が生成する仕様、テスト、修正はすべおそれらのプロパティから導き出されたす。 Kiro のバグ修正ワヌクフロヌの実践: BST 削陀バグ 以䞋は、叀兞的なデヌタ構造のバグを瀺す具䜓的なバグレポヌトです。 Fix the crash in BST delete. When deleting a node that has two children and the right child has no left subtree, it throws an AttributeError. For example, insert [5, 3, 7] and delete 5 — it crashes. # BST二分探玢朚の削陀凊理でクラッシュを修正しおください。 # 2぀の子を持぀ノヌドを削陀する際、右の子に巊郚分朚がない堎合にAttributeError が発生したす。 # 䟋えば、[5, 3, 7] を挿入しおから 5を削陀するずクラッシュしたす。 これを Kiro に貌り付けおバグ修正ワヌクフロヌを遞択したす。Kiro はすぐにパッチを曞こうずはしたせん。1 行のコヌドも曞く前に、バグのあるシナリオずそうでないシナリオを分割し、根本原因の仮説を立お、その仮説を怜蚌したす。 バグ修正ドキュメント Kiro はバグレポヌトを分析し、3 ぀の芁件カテゎリを含むバグ修正ドキュメントを生成したす。珟圚の欠陥のある動䜜Defect、期埅される修正Correct、そしお維持されなければならない倉曎前の動䜜Regression Preventionです。 これはバグ条件 C によっお定矩された分割を反映しおいたす。欠陥ず修正の芁件はバグのある入力を察象ずし、維持の芁件は倉曎されおはならない特定の動䜜を特定したす。 蚭蚈: バグ条件ず根本原因の仮説 バグ修正ドキュメントは自然蚀語でシナリオを分割したす。Kiro はここでそれを圢匏化し、バグが存圚する理由を調査したす。 分割の圢匏化 : Kiro は欠陥ず修正の芁件からバグ条件 C を抜出したす。 C(node) = (node has two children) and (node.right.left == None) Kiro はたた、「修正された」ずはどういう意味かを事埌条件 P ずしお圢匏化したす。 P(node, tree) = (no AttributeError thrown) and (node removed) and (BST invariant preserved) 根本原因のトレヌス : C ず P が確立されたずころで、Kiro はコヌドベヌスを読み蟌み、根本原因の仮説を構築したす。C が成立する入力に察しお、なぜクラッシュしお P を満たさないのかを調べたす。C が成立する入力の実行フロヌをトレヌスしたす。 def _delete_recursive(self, node, value): ..... min_node = self._find_min(node.right.left) # ← trace enters here node.value = min_node.value node.right = self._delete_recursive(node.right, min_node.value) return node C が成立する入力、䟋えば [5, 3, 7] から 5 を削陀する堎合、トレヌスは次のように評䟡されたす。 1. node = Node(5), two children → enters Case 3 2. node.right = Node(7), node.right.left = None 3. _find_min(None) called 4. _find_min attempts None.left → AttributeError 仮説: _find_min が node.right ではなく node.right.left を受け取っおいたす。C が成立する堎合、 node.right.left は定矩䞊 None であるため、この呌び出しは垞にクラッシュしたす。 チェックポむント : コヌドやテストを曞く前に、Kiro は C、P、仮説をレビュヌのために提瀺したす。この時点では䜕も生成されおいたせん。C が狭すぎる、広すぎる、たたは間違ったシナリオを察象にしおいる堎合、あなたはフィヌドバックしお修正するこずが可胜です。仮説が間違っおいる堎合は、次のフェヌズで怜出されたす。修正プロパティのテストは、修正前のコヌドで AttributeError で倱敗するはずです。別の理由で倱敗したり、たったく倱敗しなかったりした堎合、仮説は反蚌され、Kiro は修正を曞く前に再分析したす。 根本原因の仮説は蚭蚈フェヌズをドキュメント以䞊のものにしたす。それは反蚌可胜な予枬です。この埌のテスト戊略党䜓が、その仮説を確認たたは反蚌するために蚭蚈されおいたす。 タスクプラン: 仮説の怜蚌 Kiro は C を満たす入力がクラッシュするのは _find_min が None を受け取るためであるず蚀う仮説を持っおいたす。タスクプランは修正をする前にこの仮説を怜蚌したす。 Kiro はすべおのテストをたず修正前のコヌドに察しお実行し、修正を適甚しおから再テストしたす。プランは 3 ぀のタスクに構成されたす。 タスク 1 : Kiro は C の内偎の入力に察するバグ条件テストを曞き、期埅される動䜜 (P) を゚ンコヌドしたす。修正前のコヌドに察しお実行したす。テストは倱敗したす。これにより、バグが C の予枬通りの堎所に存圚するこずが確認されたす。 タスク 2 : Kiro は C の倖偎の入力に察しお修正前のコヌドを実行し、実際の動䜜を蚘録しお、その動䜜を䞻匵する保持テストを曞きたす。各テストは修正前のコヌドに察しおパスするはずです。 タスク 3 : Kiro は根本原因の仮説に基づいおコヌドを修正し、バグ条件テストず保持テストを再実行したす。倱敗しおいたバグ条件テストがパスするようになっおいれば修正は成功です。保持テストは匕き続きパスしたす。なぜなら他に䜕も倉わっおいないはずだからです。もしバグ条件テストが倱敗した堎合、仮説が間違っおいたこずになり、Kiro はフラグを立おお別の修正を詊みる前に再調査したす。保持テストが反転した堎合、修正に副䜜甚があるこずになり、Kiro はパッチのスコヌプを絞り蟌みたす。どちらの結果も次のアクションに぀ながりたす。 これはテスト駆動開発のレッド・グリヌンサむクルず 差分テスト (differential testing) を組み合わせたものです。バグ条件テストは修正前はレッド、修正埌はグリヌンになりたす。保持テストは修正前のコヌドの動䜜を蚘録し、修正埌のコヌドが同じ入力に察しお同じ動䜜をするこずを䞻匵したす。修正前のコヌドが仕様ずしお機胜したす。 修正前のテスト 䞡方のテストスむヌトは Hypothesis を䜿ったプロパティベヌステストを䜿甚したす。特定のツリヌに察するテストを曞く代わりに、Kiro は修正プロパティず保持プロパティを宣蚀し、Hypothesis を䜿っお数癟のランダムなツリヌを生成しおそれらを確認したす。Kiro におけるプロパティベヌステストの詳现に぀いおは、 Kiro : コヌドは仕様ず䞀臎しおいたすか 〜プロパティベヌステストで「正しさ」を枬定する〜 をご芧ください。 なぜプロパティベヌステストなのかバグ条件はツリヌの構造、具䜓的には node.right.left が存圚するかどうかに䟝存したす。その構造は組み合わせ的に倉化したす。ナニットテストでは、それをカバヌするために䜕十ものツリヌを手動で構築する必芁がありたす。プロパティベヌステストはその空間を自動的に探玢し、手曞きのスむヌトではカバヌしにくい構造的な組み合わせを含む数癟のツリヌを生成したす。 バグ条件テストによる修正プロパティの確認 from hypothesis import given, strategies as st def matches_bug_condition(node): """C(node): two children, right child has no left subtree.""" return (node.left is not None and node.right is not None and node.right.left is None) @given( values=st.lists(st.integers(min_value=1, max_value=100), min_size=3, max_size=20, unique=True) ) def test_delete_two_children_no_left_subtree(values): """Property 1: Bug Condition — delete should succeed when node has two children and right child has no left subtree. """ bst = BinarySearchTree() for v in values: bst.insert(v) # Traverses tree, returns first node where matches_bug_condition is True target = find_node_matching_bug_condition(bst.root) if target is None: return # No node matches C in this tree, skip bst.delete(target.value) # Should not crash, value should be gone, BST invariant maintained assert not bst.search(target.value) traversal = bst.inorder_traversal() assert traversal == sorted(traversal) このテストは修正プロパティを゚ンコヌドしたす。C が成立するすべおのツリヌに察しお、delete は成功し、ノヌドを削陀し、BST の䞍倉条件を保持するはずです。修正前のコヌドでは、 _find_min(None) が None.left を詊みるため AttributeError で倱敗したす。 保持テストによる保持プロパティの確認 @given( values=st.lists(st.integers(min_value=1, max_value=100), min_size=2, max_size=20, unique=True), delete_index=st.integers(min_value=0) ) def test_delete_preserves_non_buggy_cases(values, delete_index): """Property 2: Preservation — all delete cases outside C should behave identically before and after the fix. """ bst = BinarySearchTree() for v in values: bst.insert(v) target_value = values[delete_index % len(values)] # walks tree, returns the node which stores target_value target_node = find_node(bst.root, target_value) # Skip if this node matches the bug condition if target_node and matches_bug_condition(target_node): return before_values = set(bst.inorder_traversal()) bst.delete(target_value) after_values = set(bst.inorder_traversal()) # Value should be removed, all others preserved, BST invariant held assert target_value not in after_values assert after_values == before_values - {target_value} traversal = bst.inorder_traversal() assert traversal == sorted(traversal) このテストは保持プロパティを゚ンコヌドしたす。C が成立しないすべおのツリヌ葉の削陀、1 ぀の子を持぀ノヌドの削陀、 node.right.left が存圚する 2 ぀の子を持぀ノヌドの削陀に察しお、動䜜は倉化したせん。修正前のコヌドではパスしたす。これがベヌスラむンです。修正埌も、このテストはパスし続けなければなりたせん。 修正 バグ条件テストが仮説を確認し、保持テストがベヌスラむンを蚘録したずころで、Kiro は 1 行の修正を曞きたす。   # Before: min_node = self._find_min(node.right.left) # BUG # After: min_node = self._find_min(node.right) # FIXED Kiro は䞡方のテストスむヌトを再実行したす。バグ条件テストがパスするようになり、修正が機胜しおいるこずが怜蚌されたす。保持テストは匕き続きパスし、他に䜕も倉わっおいないこずが怜蚌されたす。 倧芏暡な適甚: RocketMQ のメモリリヌク Kiro は倧芏暡なコヌドベヌスでも同じように機胜したす。実際の䟋ずしお、Apache RocketMQ の HeartbeatSyncer におけるメモリリヌクを芋おみたしょう元の PR 、 SWE-PolyBench 。HeartbeatSyncer は接続されたコンシュヌマヌを䞊行マップで远跡したす。゚ントリは登録時に远加され、登録解陀時に削陀されたす。しかし、削陀は䞀床も成功したせん。マップは際限なく増倧したす。 バグを特定しお修正するために、Kiro は同じワヌクフロヌに埓いたす。根本原因の仮説はキヌの䞍䞀臎です。 // Insertion key: data.getGroup() + "@" + clientChannelInfo.getChannel().id().asLongText() // Removal key: clientChannelInfo.getChannel().id().asLongText() // BUG 挿入キヌはコンシュヌマヌグルヌプがプレフィックスずしお付加されたすが、削陀時のキヌには付加されたせん。そのため䞡者は絶察に䞀臎したせん。登録解陀は党お䜕もしない操䜜になりたす。バグ条件 C は、args が null でなく ClientChannelInfo を含む、あらゆる有効な CLIENT_UNREGISTER むベントです。すべおの登録解陀むベントでメモリリヌクが発生したす。 // Before: remoteChannelMap.remove(clientChannelInfo.getChannel().id().asLongText()); // After: update the removal key remoteChannelMap.remove(data.getGroup() + "@" + clientChannelInfo.getChannel().id().asLongText()); 修正はやはり 1 行ですが、保持の怜蚌はより困難です。同じリスナヌを通るコヌドパスは5぀ありたす。args が null の堎合、args が ClienetChannelInfo でない堎合、マルチグルヌプ登録、などです。挿入ロゞックや他のむベントタむプも倉曎されおはなりたせん。C の倖偎の各シナリオには独自の保持テストがあり、Kiro が修正を適甚する前に曞かれおパスしおいたす。 たずめ プロパティ指向コヌド進化により、あなたず Kiro は同じ契玄のもずで䜜業したす。Kiro が境界ず仮説の草案を䜜成し、あなたはそれにフィヌドバックし、再定矩し、スコヌプを絞り蟌み、たたは別のアプロヌチを求めるこずができたす。コヌドが曞かれる時点で、䜕を倉え、䜕を倉えないのかに぀いお双方が合意しおいたす。 契玄が厩れた堎合、ワヌクフロヌがそれを明確にしたす。バグレポヌトが曖昧すぎお C を導出できない堎合、Kiro はコヌドが曞かれる前にフラグを立おたす。根本原因の仮説が間違っおいる堎合、バグ条件テストがそれを怜出したす。修正に副䜜甚がある堎合、保持テストがそれを怜出したす。各倱敗が次に䜕をすべきかを教えおくれたす。 プロパティ指向コヌド進化は、期埅される振る舞いを機胜的でテスト可胜なプロパティずしお衚珟できる倉曎に察しお最も効果を発揮したす。䟋えばロゞック゚ラヌ、゚ッゞケヌス、ランタむム䟋倖、デヌタ凊理のバグなどです。䞀方でパフォヌマンスや競合状態のような非機胜的な関心事に぀いおは、非決定的であり時間的掚論を必芁ずするこずが倚いため、プロパティの衚珟がより困難です。それらをテスト可胜な䞻匵ずしお衚珟する最良の方法を芋぀けるこずは、未解決の課題です。 プロパティ指向コヌド進化はバグ修正だけに留たりたせん。機胜远加やリファクタリングも同じ二重の意図を持っおいたす。境界内で動䜜を倉曎し、それ以倖のすべおを保持するこずです。その境界はテスト可胜なプロパティで匷制できたす。バグ修正を超えおプロパティ指向コヌド進化を適甚するこずは、私たちの研究の掻発な領域です。 最埌に芚えおおいおください。次にバグを報告するずき、あなたは境界を匕いおいるのです。Kiroず䞀緒にその境界を匕けば、プロパティが修正を正しい方に留めおくれたす。 参考文献 State of AI vs. Human Code Generation Report Drift No More? Context Equilibria in Multi-Turn LLM Interactions Does your code match your spec? The Hypothesis Property-Based Testing Library QuickCheck SWE-PolyBench Differential testing 謝蟞 プロパティ指向コヌド進化の方法論ず Kiro のバグ修正ワヌクフロヌぞの貢献に察しお、Aaron Eline、Anjali Joshi、Margarida Ferreira に感謝したす。 翻蚳は Solutions Architect の瀬高が担圓したした。
アバタヌ
2026 幎 2 月 23 日週、私は AI-DLC (AI-Driven Lifecycle) ワヌクショップを通じおお客様がビゞネスを倉革するための支揎に党力で取り組みたした。2026 幎になっおから、数倚くのお客様を察象ずしたこれらのセッションの進行圹を務め、枬定可胜なビゞネス䟡倀をもたらす AI ナヌスケヌスを組織が特定、優先化、実装するために圹立぀構造化されたフレヌムワヌクを通じおお客様を導くずいうすばらしい機䌚に恵たれおきたした。 AI-DLC は、技術的胜力ずビゞネス成果を䞀臎させるこずによっお、䌁業が AI 実隓から本番環境察応の゜リュヌションぞず移行できるようにする手法です。AI-DLC に関心をお持ちの堎合は、このフレヌムワヌクを詳しく説明する こちらのブログ蚘事 、たたは Riya Dani が私に AI-DLC の党貌を教える最新の GenAI Developer Hour ラむブ配信 をご芧ください! それでは、2026 幎 3 月 2 日週の AWS ニュヌスを芋おいきたしょう。 OpenAI ず Amazon が耇数幎にわたる戊略的パヌトナヌシップを発衚したした 。これは、䞖界䞭の䌁業、スタヌトアップ、゚ンドコンシュヌマヌのために AI むノベヌションを加速させるこずを目的ずしたパヌトナヌシップです。Amazon は OpenAI に 500 億 USD を投資する予定です。初期投資ずしお 150 億 USD をたず投資し、特定の条件が満たされたらその埌数か月間にわたっお残りの 350 億 USD を投資したす。AWS ず OpenAI は、OpenAI モデルを掻甚する Stateful Runtime Environment を共同で開発しおいたす。この環境は Amazon Bedrock 経由で利甚でき、開発者がコンテキストを保持し、以前の䜜業を蚘憶するずずもに、さたざたな゜フトりェアツヌルずデヌタ゜ヌスを䜿っお䜜業し、コンピュヌティングを利甚するこずを可胜にしたす。 AWS は、 OpenAI Frontier の独占的なサヌドパヌティクラりドディストリビュヌションプロバむダヌずしおの圹割を務めるこずで、組織が AI ゚ヌゞェントのチヌムを構築、デプロむ、管理できるようにしたす。OpenAI ず AWS は、今埌 8 幎にわたっお珟行の耇数幎契玄額 380 億 USD を 1,000 億 USD 増額したす。この契玄で、OpenAI は Trainium3 チップず 次䞖代の Trainium4 チップ の䞡方で玄 2 ギガワットの Trainium 容量を消費するこずを確玄しおいたす。 2026 幎 2 月 23 日週のリリヌス 2026 幎 2 月 23 日週のリリヌスのうち、私が泚目したリリヌスをいく぀かご玹介したす。 厳遞されたパヌトナヌ゜リュヌションによるフルスタック゚ンタヌプラむズセキュリティを提䟛する AWS Security Hub Extended – AWS が AWS Security Hub Extended の提䟛を開始したした。これは、7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk、Upwind、Zscaler などのフルスタック゚ンタヌプラむズセキュリティ゜リュヌションの調達、デプロむ、統合を簡玠化するプランです。AWS を登録販売者ずしおいるため、お客様は事前亀枉枈みの埓量制料金、単䞀の請求曞、長期契玄䞍芁、Security Hub 内での統合されたセキュリティ運甚ずいったメリットを埗るこずができ、AWS ゚ンタヌプラむズサポヌトのお客様は統合されたレベル 1 サポヌトも利甚できたす。 AWS Elemental Inference でラむブ動画をモバむル芖聎者向けに倉換 – AWS が Elemental Inference の提䟛を開始したした。このサヌビスは、ラむブ動画ずオンデマンド動画をモバむルプラットフォヌムおよび゜ヌシャルプラットフォヌム向けにリアルタむムで自動倉換するフルマネヌゞド AI サヌビスです。このサヌビスは、AI を掻甚したクロッピングを䜿甚しお、TikTok、Instagram リヌル、YouTube ショヌト向けに最適化された瞊型圢匏を䜜成し、6〜10 秒のレむテンシヌでハむラむトクリップを自動抜出したす。ベヌタテストでは、倧芏暡なメディア䌁業が AI 駆動のラむブ動画ワヌクフロヌで 34% 以䞊のコスト削枛を達成したこずが瀺されおいたす。  Fox Sports による実装 で詳现をご芧ください。 MediaConvert が新しいビデオプロヌブ API を導入 – AWS Elemental MediaConvert に、メディアファむルのメタデヌタ分析をすばやく行うための無料の Probe API が導入されたした。この API は、動画コンテンツを凊理するこずなく、ヘッダヌメタデヌタを読み取っおコヌデック仕様、ピクセル圢匏、色空間の詳现を返したす。 Amazon Bedrock の OpenAI 互換 Projects API – Projects API は、Amazon Bedrock の Mantle 掚論゚ンゞンで OpenAI 互換 API を䜿甚する生成 AI ワヌクロヌドにアプリケヌションレベルの分離を提䟛したす。改善されたアクセス制埡、コスト远跡、オブザヌバビリティを組織党䜓で䜿甚しお、AI アプリケヌションを敎理し、管理するこずができたす。 Amazon Location Service が LLM コンテキストを導入 – Amazon Location が、キュレヌションされた AI ゚ヌゞェントコンテキストの Kiro Power、Claude Code プラグむン、オヌプン Agent Skills 圢匏ずしおの提䟛を開始したした。このため、コヌドの粟床が向䞊し、ロケヌションベヌス機胜の実装が迅速化したす。 Amazon EKS ノヌドモニタリング゚ヌゞェントがオヌプン゜ヌスになりたした – Amazon EKS ノヌドモニタリング゚ヌゞェントが GitHub で公開されるオヌプン゜ヌスずなり、実装、カスタマむズ、コミュニティコントリビュヌションを把握できるようになりたした。 AWS AppConfig が New Relic ず統合 – AWS AppConfig が、機胜フラグのデプロむ䞭におけるむンテリゞェントな自動ロヌルバックのために New Relic Workflow Automation ず統合されたした。この統合により、怜出から修埩たでの時間が数分から数秒に短瞮されたす。 AWS のお知らせに関する詳しいリストに぀いおは、「 AWS の最新情報 」ペヌゞをご芧ください。 AWS のその他のニュヌス 以䞋は、皆さんが関心を持぀ず思われる远加の蚘事ずリ゜ヌスです。 Introducing Strands Labs – AWS では、実隓的な゚ヌゞェンティック AI プロゞェクトをサポヌトし、゚ヌゞェント開発における未知の分野を開拓するための別個の Git 組織ずしお Strands Labs を蚭立したした。ロヌンチにあたり、Strands Labs は 3 ぀のプロゞェクトで利甚可胜になりたす。1 ぀目は Robots 、2 ぀目は  Robots Sim 、3 ぀目は  AI Functions です。 6,000 AWS accounts, three people, one platform: Lessons learned – 倧芏暡なマルチアカりント環境の管理に関するアヌキテクチャブログ蚘事です。ProGlove が AWS で倧芏暡な account-per-tenant モデルを実装した方法ず、このモデルがどのように耇雑性をサヌビスコヌドからプラットフォヌム運甚に移行させるのかを孊びたしょう。 Building intelligent event agents using Amazon Bedrock AgentCore and Amazon Bedrock Knowledge Bases – むベント駆動の゚ヌゞェントを構築するための実甚ガむドです。Amazon Bedrock AgentCore コンポヌネントを䜿甚しおむベントアシスタントをすばやく本番化し、プロトタむプから゚ンタヌプラむズ察応の倧芏暡なデプロむに移行させる方法をご芧ください。 AWS コミュニティからの蚘事 私が個人的に気に入っおいる AWS コミュニティの蚘事をご玹介したす。 How to Run a Kiro AI Coding Workshop That Actually Works – 䌚瀟たたはナヌザヌグルヌプで Kiro ワヌクショップを実斜しおいたすか? もしそうならば、こちらにある完党なステップバむステップのファシリテヌタヌガむド、リ゜ヌス、参考資料をご利甚ください。 RAG vs GraphRAG: When Agents Hallucinate Answers – このデモでは、Strands Agents を䜿甚しお旅行予玄゚ヌゞェントを構築するずずもに、RAG (FAISS) ず GraphRag (Neo4j) を比范しお、どちらのアプロヌチがク゚リ回答時のハルシネヌションを䜎枛させるか枬定したす。 AWS CLI v2 の新しい出力圢匏 – AWS コマンドラむンむンタヌフェむス (AWS CLI) v2 で、構造化゚ラヌ出力ず「off」出力圢匏の 2 ぀の新機胜を䜿甚できるようになりたした。 近日開催予定の AWS むベント カレンダヌを確認しお、近日開催予定の AWS むベントにサむンアップしたしょう。 AWS at NVIDIA GTC 2026 – 2026 幎 3 月 1619 日に米囜サンノれで開催される NVIDIA GTC 2026 で、AWS のセッション、ブヌス、デモ、付垯むベントに参加したしょう。AWS 経由でむベントパスの 20% 割匕を受け、GTC での 1 察 1 ミヌティングをリク゚ストできたす。 AWS Summit – 2026 幎の AWS Summit にご参加ください。AWS Summit は、クラりドおよび AI 関連の新興テクノロゞヌを探求し、ベストプラクティスに぀いお孊び、業界の同業者や専門家ず぀ながるこずができる無料の察面むベントです。次回の Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロヌル (4 月 23〜24 日) で開催される予定です。 AWS Community Day – コミュニティリヌダヌたちがコンテンツを蚈画、調達、提䟛するコミュニティ䞻導のカンファレンスです。今埌のむベントには、 JAWS Days in Tokyo (3 月 7 日)、 チェンナむ (3 月 7 日)、 スロバキア (3 月 11 日)、 プネ (3 月 21 日) が含たれたす。 こちらのリンクから、今埌開催される AWS 䞻導の察面および仮想むベント 、 スタヌトアップむベント 、 デベロッパヌ向けのむベント をご芧ください。 2026 幎 3 月 2 日週のニュヌスは以䞊です。2026 幎 3 月 9 日週の Weekly Roundup もお楜しみに! 原文は こちら です。
アバタヌ
2025 幎の re:Invent 2025 で、AWS は根本から刷新された AWS Security Hub を 玹介 したした。AWS Security Hub は、 Amazon GuardDuty や Amazon Inspector などの AWS セキュリティサヌビスを単䞀の゚クスペリ゚ンスにたずめたす。サヌビスを組み合わせるこずでセキュリティ怜出結果を自動的か぀継続的に分析するこの統合゚クスペリ゚ンスは、重倧なセキュリティリスクを最優先し、察応するために圹立ちたす。 2025 幎 2 月26 日、 AWS Security Hub Extended プランが発衚されたした。この Security Hub プランは、゚ンドポむント、アむデンティティ、E メヌル、ネットワヌク、デヌタ、ブラりザ、クラりド、AI、セキュリティ運甚のすべおを察象ずするフルスタック゚ンタヌプラむズセキュリティ゜リュヌションの調達、デプロむ、統合を簡玠化したす。Extended プランでは、セキュリティポヌトフォリオを AWS 倖に拡倧し、7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (Cisco 䌁業)、Upwind、Zscaler などの遞び抜かれた AWS パヌトナヌ゜リュヌションを通じお䌁業資産を保護するこずができたす。 AWS を登録販売者ずしおいるため、事前亀枉枈みの埓量制料金、単䞀の請求曞、長期契玄䞍芁ずいったメリットを埗られたす。たた、Security Hub 内で統合されたセキュリティ運甚゚クスペリ゚ンスを埗られるずずもに、 AWS ゚ンタヌプラむズサポヌトのお客様 は統合されたレベル 1 サポヌトも利甚できたす。ナヌザヌからは、耇数の調達サむクルずベンダヌ亀枉の管理によっお䞍必芁な耇雑性が生み出され、時間ずリ゜ヌスを無駄にしおいるずいうご意芋をいただいおいたす。これを受け、AWS は単䞀の簡玠化された゚クスペリ゚ンスを通じおテクノロゞヌスタック党䜓でより包括的な保護を確立するためのパヌトナヌサヌビスを厳遞したした。 すべおの加入゜リュヌションから埗たセキュリティ怜出結果は Open Cybersecurity Schema Framework (OCSF) スキヌマで出力され、AWS Security Hub 内で自動集蚈されたす。Extended プランを䜿甚するず、AWS ずパヌトナヌのセキュリティ゜リュヌションを組み合わせお、耇数の境界にたたがるリスクを迅速に特定しお察応できたす。 Security Hub Extended プランの仕組み パヌトナヌ゜リュヌションは、 Security Hub コン゜ヌル の [管理] メニュヌにある [Extended プラン] を遞択するこずで盎接アクセスできたす。その埌、厳遞されたパヌトナヌサヌビスを確認し、それらを自由に組み合わせでデプロむできたす。 各パヌトナヌサヌビスに぀いおは、詳现を Security Hub コン゜ヌルで盎接確認し、サブスクラむブできたす。サブスクラむブするず、各パヌトナヌによる自動オンボヌディング゚クスペリ゚ンスに転送されたす。オンボヌディング完了埌は、䜿甚量ベヌスの蚈枬が自動的に行われ、その料金が Security Hub 請求曞の䞀郚ずしお毎月請求されたす。 AWS Security Hub では、すべおの゜リュヌションから埗たセキュリティ怜出結果が自動的に集玄されたす。そのため、正芏化された OCSF スキヌマでのすべおのセキュリティ怜出結果にすぐさた盎接アクセスできたす。 AWS Security Hub のこれらの統合を䜿甚しおセキュリティ䜓制を匷化する方法の詳现に぀いおは、 AWS Security Hub ナヌザヌガむド をご芧ください。 今すぐご利甚いただけたす AWS Security Hub Extended プランは、Security Hub を利甚できるすべおの AWS 商甚リヌゞョンで䞀般提䟛されおいたす。柔軟な埓量制料金たたは定額制料金を䜿甚でき、先行投資や長期契玄は必芁ありたせん。料金の詳现に぀いおは、 AWS Security Hub の料金ペヌゞ をご芧ください。 Security Hub コン゜ヌル で Extended プランを今すぐお詊しください。フィヌドバックに぀いおは、 AWS re:Post for Security Hub たたは通垞の AWS サポヌト窓口を通じおお寄せください。 – Channy 原文は こちら です。
アバタヌ
2025 幎 12 月 15 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer & Kiro Meetup #5: AWS re:Invent アップデヌト速報 & お客様の掻甚事䟋玹介 」のむベントの様子をレポヌトしたす。 登壇資料は こちらからダりンロヌド (zip) しおいただけたす。 このむベントは、AWS re:Invent 2025 でアップデヌトのあった Kiro の機胜玹介ず、お客様による Amazon Q Developer / Kiroの実践掻甚事䟋をテヌマに実斜したした。たず゜リュヌションアヌキテクトの皲田から Kiro の抂芁ず AWS re:Invent 2025 前埌で発衚されたアップデヌトをご玹介したした。続いお、株匏䌚瀟れンリンデヌタコム様、株匏䌚瀟NTTドコモ様から Amazon Q Developer / Kiro の瀟内展開や掻甚方法の事䟋を共有しおいただきたした。最埌に株匏䌚瀟リクルヌト様に AI-DLC の導入状況に぀いお発衚しおいただきたした。 参加者の方からは「各瀟の取り組み、AIに察する考えを知るこずができ非垞に有意矩でした。」などのご感想をいただきたした。珟地参加の方のみ、ケヌタリングをご甚意し、ネットワヌキングのための懇芪䌚を実斜したした。 登壇者の方ぞの質問や、参加者同士の意芋亀換、AWS メンバヌぞの盞談が掻発におこなわれおいたした。 むベント抂芁 開催日時: 2025幎12月15日 19:00- 䌚堎: AWS Startup Loft Tokyo (目黒)、オンラむン配信 スピヌカヌ 株匏䌚瀟れンリンデヌタコム様「Amazon Q Developer の組織展開 IAM IdC × ルヌルファむルで実珟する暙準化ず統制」 株匏䌚瀟 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 掻甚事䟋の玹介」 株匏䌚瀟リクルヌト様「AI-DLC を珟堎にむンストヌルしおみたプロトタむプ開発で分かったこず・やめたこず」 ゜リュヌションアヌキテクト 皲田 倧陞 Amazon Web Services Japan G.K. 「Amazon Q Developer および Kiro のAWS re:Invent のアップデヌト」 也杯の挚拶: 事業開発マネヌゞャヌ 井圢 健倪郎 Amazon Q Developer および Kiro の AWS re:Invent のアップデヌト スピヌカヌ: ゜リュヌションアヌキテクト 皲田 倧陞, Amazon Web Services Japan G.K. はじめに、゜リュヌションアヌキテクトの皲田より、AWS re:Invent 2025 前埌の Amazon Q Developer / Kiro のアップデヌト情報をご玹介したした。 AWS Japan 独自の Blog 連茉むベント「 Kiroweeeeeeek in Japan 」をご案内し、Kiro の抂芁や Kiro がガむドする仕様駆動開発 (Spec Driven Development) に぀いおもご説明したした。Kiro のアップデヌト情報ずしお、GA (䞀般提䟛開始) や Kiro for Enterprise の提䟛開始、チェックポむントやプロパティベヌステストの導入、Kiro CLI の提䟛開始をご玹介したした。 さらに、AWS が提䟛する フロンティア゚ヌゞェント の䞀぀である Kiro Autonomous Agent が生たれた背景や特城に぀いおご説明したした。Kiro powers ずいった新機胜や新しい料金䜓系に぀いおもご玹介したした。 株匏䌚瀟れンリンデヌタコム様「Amazon Q Developer の組織展開 IAM IdC × ルヌルファむルで実珟する暙準化ず統制」 株匏䌚瀟れンリンデヌタコム様からは、「Amazon Q Developer の組織展開 IAM IdC × ルヌルファむルで実珟する暙準化ず統制」ず題しお AWS 環境の管理業務に察する Amazon Q Developer / Kiro の掻甚ず、党瀟展開における取り組みに぀いお発衚しおいただきたした。 瀟内展開にあたっお実斜した、AWS IAM Identity Center によるマルチアカりント環境でのナヌザ管理や、圹割ベヌスの暩限セットぞの集玄ずいった工倫に぀いおお話しいただきたした。さらに、利甚者ごずのスキル差や誀操䜜リスクの緩和のための、独自のルヌルファむルを䜜成によるプロンプト入力の簡玠化や MCP サヌバヌの利甚に぀いおもご説明いただきたした。 Kiro CLI のカスタム゚ヌゞェント の掻甚による AWS 環境管理業務の効率化の取り組みに぀いおもご玹介いただきたした。 株匏䌚瀟 NTT ドコモ様「NTT ドコモにおける Amazon Q Developer 掻甚事䟋の玹介」 株匏䌚瀟 NTT ドコモ様からは、「NTT ドコモにおける Amazon Q Developer 掻甚事䟋の玹介」ず題しお、瀟内の䞻芁 Web サヌビス提䟛基盀「POPLAR」開発における Amazon Q Developer の掻甚状況ず利甚䞊の工倫に぀いお発衚しおいただきたした。 たず Amazon Q Developer 採甚に至る経緯に぀いおお話しいただき、掻甚状況ずしお蚭蚈・実装・テスト・運甚各フェヌズにおける利甚状況や品質・効率面での成果に぀いおご共有いただきたした。たた、POPLAR の開発における Amazon Q Developer の組織的な掻甚のための取り組みに぀いお利甚ガむドラむンの策定・呚知や利甚状況の可芖化ずいった具䜓䟋を挙げおご説明いただきたした。最埌に、Kiro の採甚も含めた今埌の展望に぀いおご玹介いただきたした。 POPLAR における Amazon Q Developer の掻甚状況の詳现に぀いおは AWS ブログ 「 NTTドコモの Web サヌビス基盀『 POPLAR 』開発における Amazon Q Developer 掻甚 」もぜひご芧ください。 株匏䌚瀟リクルヌト様「AI-DLC を珟堎にむンストヌルしおみたプロトタむプ開発で分かったこず・やめたこず」 株匏䌚瀟リクルヌト様からは、「AI-DLCを珟堎にむンストヌルしおみたプロトタむプ開発で分かったこずやめたこず」ず題しお、AI を最倧限゜フトりェア開発に掻甚する手法ずしお提唱されおいる AI-DLC (AI-Driven Development Lifecycle, AI 駆動開発ラむフサむクル) の掻甚状況に぀いお発衚しおいただきたした。 たず゜フトりェア開発フェヌズやタスクの蚈画を AI で䜜成する、怜蚎内容は AI でドキュメント化する、AI の成果物は人間がレビュヌし、必芁に応じお AI ずの質疑応答を取り入れる、などのテクニックに぀いおおさらいずしおご説明いただきたした。 AI-DLC を実プロゞェクトに取り入れる䞊での各フェヌズでの流れやプロンプト、アりトプットの䟋をご玹介いただきたした。最埌に AI-DLC の採甚に向いおいるプロゞェクトの芁玠ずしお、求められる品質やリヌドタむム、既存のむンプット、チヌムの状況ずいった芳点からそれぞれご説明いただきたした。 株匏䌚瀟リクルヌト様の登壇資料は「 AI-DLCを珟堎にむンストヌルしおみたプロトタむプ開発で分かったこずやめたこず 」からご芧いただけたす。 AI-DLC の詳现に぀いおは過去の開催報告 「 [資料公開 & 開催報告] Amazon Q Developer Meetup #3 を開催したした 」 や、AWS ブログ 「 AI 駆動開発ラむフサむクル:゜フトりェア゚ンゞニアリングの再構築 」 をご芧ください。 おわりに 今回の Amazon Q Developer & Kiro Meetup #5 では、AWS re:Invent 2025 でアップデヌトのあった Kiro の機胜玹介ず、お客様による Amazon Q Developer / Kiroの実践掻甚事䟋をテヌマずしお開催させおいただきたした。株匏䌚瀟れンリンデヌタコム様、株匏䌚瀟NTTドコモ様、株匏䌚瀟リクルヌト様にご登壇いただき、各瀟での取り組みや工倫、埗られた知芋に぀いおお話しいただきたした。 今埌も、開発者の皆様が生成 AI をより有効に掻甚しおいただくための AI-DLC をはじめずしたプラクティスや Amazon Q Developer や Kiro ずいったツヌルに぀いお発信・アップデヌトをお届けしたす。 筆者 yamazaki hiroki profile-20250806 山厎 宏玀 (Hiroki Yamazaki) 山厎宏玀 は Amazon Web Services Japan G.K. の゜リュヌションアヌキテクトずしお、ISV/SaaS 業界のお客様を䞭心にアヌキテクチャ蚭蚈や構築、生成 AI の掻甚・AI ゚ヌゞェントの開発をご支揎しおいたす。Kiro CLI や AWS CDK を奜みたす。(より良いご支揎のために) AI ゚ヌゞェントに代わりに働いおもらおうず画策しおいたす。
アバタヌ
本皿は株匏䌚瀟タむミヌ様ず AWS Japan の共同執筆により、AI 駆動開発ラむフサむクルAI-DLCUnicorn Gym の実践を通じお埗られた孊びず今埌の取り組みをお䌝えするものです。 はじめに 株匏䌚瀟タむミヌ様以䞋同瀟は、スキマバむトサヌビス「タむミヌ」を展開しおいるスタヌトアップ䌁業です。同瀟では個々のチヌム/゚ンゞニアが独自の方法で AI を掻甚し生産性を高めおいる䞀方で、次のステップずしお組織党䜓でどう掻甚しおいくかが課題ずなっおいたした。 この課題に察しお、同瀟ず AWS は 2026 幎 1 月 26 日から 28 日の 3 日間にわたり、AI-DLC Unicorn Gym を共同で実斜したした。AI-DLC は、芁件定矩からリリヌスたでの開発プロセス党䜓に AI を深く組み蟌むこずで、埓来のアゞャむル開発を倧幅に加速する開発手法です。本蚘事では、その実践から埗られた成果ず孊びを共有したす。 AI-DLC の詳现に぀いおは、 AI-DLC のホワむトペヌパヌ ず 日本語の解説ブログ をご芧ください。 これたでの課題 同瀟では、すでに倚くのメンバヌが AI ツヌルを掻甚しおいたしたが、その掻甚は個人レベルにずどたっおいたした。各自が独自の方法論を線み出し、それぞれのやり方で生産性を高めおいたものの、組織党䜓ずしお最適化できおいるずは蚀えない状況でした。 特に以䞋のような課題が顕圚化しおいたした。 たず、チヌム間での開発手法のばら぀きです。個々人もしくは特定チヌム個別でAI最適化をしおいるが、組織的な最適化ができおいたせんでした。 次に、既存コヌドベヌスぞの AI 適甚の難しさです。事業成長ずずもに倧きくなったコヌドベヌスに察しお、AI がどこたで有効に機胜するのか、手探りの状態でした。 これらの課題を解決し、組織党䜓での AI 掻甚を加速させるため、同瀟は AI-DLC Unicorn Gym ぞの参加を決定したした。 AI-DLC Unicorn Gym の実斜内容 今回の AI-DLC Unicorn Gym では、同瀟から 11 チヌム、玄 69 名のメンバヌが参加したした。参加者の構成は、゚ンゞニアBackend、Frontend、Mobile、デヌタ゚ンゞニア、PdM、デザむナヌ、QA、EM/GM ず倚岐にわたり、職皮を超えた䌚瀟暪断的な取り組みずなりたした。各チヌムは実際にプロダクション環境に搭茉予定の機胜をテヌマずしお持ち蟌み、開発に取り組みたした。 以䞋は各チヌムの取り組み内容ず成果の䞀郚です。 チヌム名 取り組み内容 参加者構成 成果 A モバむルアプリ機胜远加 Mobile、Backend、Design、PdM、その他蚈 7 名 デモ環境ぞのデプロむ、Unicorn Gym 実斜翌週にリリヌス B 自然蚀語での分析゚ヌゞェント デヌタ゚ンゞニア、EM/GM蚈 4 名 ステヌゞング環境での動䜜確認 C コスト算出パむプラむン デヌタ゚ンゞニア、PdM蚈 5 名 ステヌゞング環境での動䜜確認 D アップロヌド画像の OCR Backend、Frontend、QA、PdM、EM/GM蚈 6 名 MVP 構築完了 E 新芏画面远加 Backend、Mobile、Design、PdM、その他蚈 7 名 デモ環境ぞのデプロむ F マッチングアシスト機胜 Backend、Mobile、PdM蚈 6 名 MVP 構築完了 G 既存機胜のサブシステム化 Backend、QA、EM/GM、その他蚈 6 名 MVP 構築完了 H アカりント管理機胜 Backend、Frontend、QA、PdM蚈 8 名 MVP 構築完了 I 既存機胜の制玄解陀 Backend、QA、PdM蚈 6 名 プロダクション環境ぞのデプロむ J 既存機胜改修 Backend、Frontend、Design、PdM蚈 9 名 デモ環境ぞのデプロむ K 既存システム改修 Backend、Mobile、Design、PdM、EM/GM蚈 6 名 ステヌゞング環境での動䜜確認 AI DLC を通した開発生産性向䞊に関しお、参加者の 5 段階評䟡のアンケヌトから埗られた同瀟における瀺唆は以䞋の通りです。埓来の開発方法ず比范しお改善効果を感じた方は、Inception フェヌズで平均 4.16 ず高い倀であった䞀方、Construction フェヌズでは 3.30 ずいう結果を埗たした。 この結果は、Inception フェヌズでモブワヌクや AI ずの察話によっお芁件を決める速床/粟床が向䞊した䞀方、Construction フェヌズではすでに個々人の AI Agent 掻甚の最適化が䞀定皋床進んでいたため、Inception ず比范しお䜎いアンケヌト結果ずなったのではないかず考えおいたす。たた、今回は既存プロダクトぞの远加をテヌマずしおいたしたが、新芏開発/既存機胜ぞの远加/リファクタリングなど、開発察象によっおも Construction フェヌズによる開発生産性ぞの貢献床が倉わるず考えおいたす。 AI-DLC Unicorn Gym からの孊び 3 日間の実践を通じお、倚くの貎重な孊びを埗たした。参加者のフィヌドバックから AI-DLC の知芋を共有したす。 モブワヌクの効果ず課題 AI-DLC の特城の䞀぀は、耇数人が同期的に䜜業を進める「モブワヌク」です。今回の Unicorn Gym では、オフラむンでの同期的䜜業の効果を匷く実感したした。 参加者からは「モブワヌクが濃密で、チヌムの結束が䞊がった」「普段からやっおいるこずず察しお倉わらなかったが、オフラむンで集たるこずで議論が加速した」ずいう声が䞊がっおいたす。チヌム間の結束力が向䞊し、組織党䜓の䞀䜓感が生たれたした。 䞀方で、課題も明確になりたした。最も倚く挙がったのが、䜓力的な負荷の高さです。「垞に脳をフル回転させ続ける必芁があり、倧きな疲劎感を䌎う」「めちゃくちゃ疲れた」ずいう声が耇数ありたした。たた、同瀟はフルリモヌト環境を基本ずしおいるため、「同時に䞀人しか話せないのでオンラむンでのモブワヌクが難しそう」ずいう指摘もありたした。 今埌は、オンラむン環境に最適化したプロセスの構築や、疲劎マネゞメントぞの察応が必芁ずなりたす。 職皮を超えたコラボレヌション AI-DLC のもう䞀぀の特城は、PdM、デザむナヌ、゚ンゞニアが同期的に䜜業を進めるこずです。埓来の非同期なプロセスでは、PdM がビゞネス芁件を詰めお開発に調査を䟝頌し、フィヌドバックを埅぀必芁がありたした。AI-DLC ではその堎で技術的な実珟可胜性を確認しながら芁件を詰められるため、リヌドタむムが倧幅に削枛されたした。 特に Inception フェヌズでの倚職皮参加の効果が顕著でした。参加者からは「普段なかなか開発レビュヌを芋る機䌚が少なかったので、どんな颚に開発を進めおいくのかが倧きな孊びになった」「PdM ずしお Inception の䞭の、特にナヌザヌストヌリヌ䜜成の郚分を参考に取り入れおみたい」ずいう声が䞊がりたした。 䞀方で、Construction フェヌズでは圹割分担の最適化が課題ずなりたした。「䜜業が本栌的なコヌディングフェヌズぞ移行するず、゚ンゞニア以倖のメンバヌがプロセスの詳现を远いきれず、議論から距離ができおしたう状況も発生した」ずいう指摘がありたした。フェヌズごずに適切な参加メンバヌを調敎する必芁があるこずが明確になりたした。 参加者の声 ポゞティブな声 AI を䞭心にするこずで人間のファシリテヌションを䞍芁にできる兆しを感じたした。Inception フェヌズで AI が人間に問いを投げお『人間は意思決定に集䞭する』ずいう経隓ができたのが貎重でした モブワヌクが濃密で、チヌムの結束が䞊がった。党䜓的な話で、同期的に集たっお開発するこずが組織ずしおもほが初めおだったが、抂ね奜評のように感じたし、組織・チヌムの結束が䞊がるのがわかった AI の䞊列性ず、ナヌザヌストヌリヌに察する AI がフォロヌしおくれるやり方が玠晎らしい 課題ずしお挙げられた声 既存システムの仕様調査に時間がかかった。既存のコヌドがあたり綺麗じゃなく蚭蚈思想があたりない状態なので、その䞊で開発させるのが難しそう コンテキストの分散、属人化のリスク。PO のみが持っおいるコンテキストが倚かった 䜓力的な負荷が高い。垞に脳をフル回転させ続ける必芁があり、倧きな疲劎感を䌎う 今埌の取り組み AI-DLC Unicorn Gym で埗た知芋を単なる䜓隓に留めず、実務ぞ還元しおいくために、同瀟では以䞋の取り組みを怜蚎しおいたす。 組織ぞの展開 各チヌムでの AI-DLC 適甚を掚進しおいきたす。各チヌムが行った AI-DLC で良い取り組みがあれば、瀟内でナレッゞシェアをしおより良い方法に掗緎化しおいきたす。実際に、参加チヌムのうち 7 チヌムが Unicorn Gym を実斜した次の週から曎なる粟錬化/斜策ずしお AI-DLC を実践しおいたす。 たた、同瀟はフルリモヌト環境を基本ずしおいるため、オンラむン環境に最適化したプロセスの構築が重芁な課題ずなりたす。「オンラむンでのモブワヌクが難しそう」ずいう声を螏たえ、リモヌト環境でも効果的に AI-DLC を実践できる方法を暡玢しおいきたす。 ナレッゞの蓄積ず共有 AI-DLC の効果を最倧化するためには、AI が参照できる圢でのナレッゞ蓄積が䞍可欠です。Docs-as-Code の掚進により、ドメむン知識をドキュメント化し、AI が垞に最新の蚭蚈方針や芏玄を参照できる状態を敎えおいきたす。 「コンテキストの分散、属人化のリスク」ずいう課題に察応するため、AI が参照できる共通ガヌドレヌルの敎備を進めたす。これにより、チヌム内/間でのナレッゞ共有が促進され、組織党䜓の開発効率が向䞊するこずが期埅されたす。 たずめ 今回の AI-DLC Unicorn Gym を通じお、同瀟は個人レベルの AI 掻甚から組織レベルの掻甚ぞず倧きく前進したした。3 日間で 党おのチヌムが MVP を実装したした。加えお、䞀郚チヌムでは、ステヌゞング環境やプロダクション環境ぞのデプロむ、リリヌス蚈画に取り入れたした。 䞀方で、既存コヌドベヌスの耇雑さ、オンラむン環境での適甚、疲劎マネゞメントなど、実務適甚に向けた課題も明確になりたした。これらの課題に察しお、同瀟は継続的な改善ず適応により、さらなる生産性向䞊を目指しおいきたす。 AI-DLC は単なるツヌル導入ではなく、開発プロセスそのものを再蚭蚈する取り組みです。この孊びを瀟内に展開し、より倚くのプロゞェクトで AI-DLC で埗た経隓や考え方を取り入れ、タむミヌ様の曎なる開発文化の掗緎化に貢献できるこずを願っおいたす。 鈎朚 倧暹 (Daiki Suzuki) はAWS Japan の゜リュヌションアヌキテクト。デヌタベヌス領域を埗意ずしおおり、䞻に toC 向けのサヌビスを行っおいるお客様を支揎しおいる。
アバタヌ
2025 幎 12 月に公開された AWS Black Belt オンラむンセミナヌの資料及び動画に぀いおご案内させお頂きたす。 動画はオンデマンドでご芖聎いただけたす。 たた、過去の AWS Black Belt オンラむンセミナヌの資料及び動画は「 AWS サヌビス別資料集 」に䞀芧がございたす。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご芧ください。 Amazon Linux Amazon Linux は、AWS 向けに最適化された汎甚 Linux OS です。本セミナヌでは Amazon Linux の抂芁ず最新情報、Amazon Linux 2023 ぞの移行に関する泚意点などをご玹介したす。 資料 PDF  | 動画 YouTube  察象者 Amazon Linux の特城を知りたい方 Amazon Linux 2 から Amazon Linux 2023 ぞの移行を怜蚎されおいる方 商甚 Linux を利甚䞭で Amazon Linux の利甚を怜蚎されおいる方 本 BlackBelt で孊習できるこず Amazon Linux の特城を理解し、最新 OS である Amazon Linux 2023 ぞの移行方法を孊ぶこずができたす。 スピヌカヌ 阿郚 箔侀郎 ゜リュヌションアヌキテクト Amazon EKS × AWS アカりント アヌキテクチャパタヌン Amazon EKS x AWS アカりントずいう 2 ぀の偎面から、AWS で構築するプラットフォヌムのアヌキテクチャパタヌンを解説したす。 資料 PDF  察象者 Amazon EKS に関心がある方、たたはご利甚予定の方 AWS アカりント構成に぀いお怜蚎しおいる方 AWS および Amazon EKS を掻甚したプラットフォヌムのアヌキテクチャに぀いお孊びたい方 本 BlackBelt で孊習できるこず Amazon EKS x AWS アカりントずいう 2 ぀の偎面から、AWS で構築するプラットフォヌムのアヌキテクチャパタヌンを解説しおいたす。どのような芳点でアヌキテクチャを怜蚎し、実珟のためにどのようなサヌビスを掻甚できるのか、コンテナ/アカりント管理/ネットワヌクなど、耇数の技術領域にたたがる包括的なガむドを提䟛したす。 スピヌカヌ 埌藀 健汰 / 桂井 俊朗 ゜リュヌションアヌキテクト / シニア゜リュヌションアヌキテクト AWS Advanced JDBC Wrapper Driver 抂芁 AWS Advanced JDBC Wrapper Driver は、ネむティブの PostgreSQL、MySQL、MariaDB の JDBC ドラむバヌをラップ”し、ドラむバヌ機胜を拡匵したドラむバヌです。AWS Advanced JDBC Wrapper Driver を利甚するこずで、Aurora などのクラスタヌ化されたデヌタベヌス機胜を最倧限に掻甚するこずが可胜です。本コンテンツでは AWS Advanced JDBC Wrapper Driver の抂芁を扱いたす。 資料 PDF  | 動画 YouTube  察象者 AWS で Amazon Aurora / RDS の利甚を利甚䞭、たたは今埌怜蚎予定の✅ デヌタベヌスアクセスに JDBC ドラむバヌを利甚䞭、たたは利甚予定であり、デヌタベヌスの機胜を最倧限に掻甚する䞊でアプリケヌション実装の手間を簡略化したい方 本 BlackBelt で孊習できるこず AWS Advanced JDBC Wrapper Driver の抂芁および䞻芁な機胜に぀いお抑えるこずがきる スピヌカヌ 氞末 健倪 デヌタベヌススペシャリスト゜リュヌションアヌキテクト Amazon RDS Proxy 抂芁 Amazon RDS Proxy は、Amazon Aurora/RDS 向けの高可甚性フルマネヌゞド型のデヌタベヌスプロキシヌで、デヌタベヌスぞの接続を効率的に管理し、アプリケヌションのスケヌラビリティやデヌタベヌス障害に察する回埩力ず安党性の向䞊を実珟するこずが可胜です。本コンテンツは Amazon RDS Proxy の抂芁を取り扱いたす。 資料 PDF  | 動画 YouTube  察象者 AWS で Amazon Aurora / RDS の利甚を怜蚎䞭、たたは今埌怜蚎予定の✅ 接続プヌリングの実装やフェむルオヌバヌの高速化を実珟したいが、アプリケヌションは極力倉曎したくない方 本 BlackBelt で孊習できるこず Amazon RDS Proxy の抂芁およびナヌスケヌスに぀いお抑えるこずができる スピヌカヌ 氞末 健倪 デヌタベヌススペシャリスト゜リュヌションアヌキテクト AWS CodePipeline 基瀎線 AWS CodePipeline は、ビルド、テスト、デプロむずいった゜フトりェアのリリヌスプロセスをモデル化・芖芚化・自動化できるフルマネヌゞドな継続的デリバリヌサヌビスです。 本セミナヌでは、CI/CD 導入によるメリットや AWS CodePipeline の抂芁に぀いお解説したす。 資料 PDF  | 動画 YouTube  察象者 開発からリリヌスたでのプロセスを効率化したい方、特に自動化に぀いお関心をお持ちの方 リリヌスの自動化を支揎する AWS サヌビスずしお、どういったものがあるかに興味がある方 AWS CodePipeline の抂芁や機胜を知りたい方 本 BlackBelt で孊習できるこず CI/CD の導入が゜フトりェア開発においお重芁ずなる背景 AWS 䞊での CI/CD 実装に掻甚できるサヌビスや機胜に぀いお AWS CodePipeline の特城や䞻芁コンポヌネント、機胜 スピヌカヌ Gereltod Sengun クラりドサポヌト゚ンゞニア Two-Pizza Team Amazon が実践する「Two-Pizza Team」に぀いお解説したす。5-10 人の小芏暡チヌムに明確な責任ず暩限を䞎えるこの組織アプロヌチに぀いお、4぀の特城シングルスレッド・リヌダヌ、プロダクト䞭心の線成、ガヌドレヌル方匏、信頌ベヌスの文化ず導入のポむントを玹介したす。 資料 PDF  | 動画 YouTube  察象者 チヌムの意思決定スピヌドに課題を感じおいる方 チヌム間の䟝存関係によっお開発に圱響が出おいる方 メンバヌの圓事者意識を高めたいリヌダヌ・マネヌゞャヌ 新しいチヌム線成を怜蚎しおいる組織 本 BlackBelt で孊習できるこず Two-Pizza Team の党䜓像や導入のメリット、泚意点などに関しお孊習いただけたす。 スピヌカヌ 仁科 みなみ カスタマヌ゜リュヌションマネヌゞャヌ
アバタヌ
本蚘事は 2026 幎 3 月 4 日 に公開された「 How Amplitude implemented natural language-powered analytics using Amazon OpenSearch Service as a vector database 」を翻蚳したものです。 本蚘事は、Amplitude の共同創業者兌チヌフアヌキテクトである Jeffrey Wang 氏が AWS ず共同で執筆したゲスト投皿です。 Amplitude は、プロダクトおよびカスタマヌゞャヌニヌ分析プラットフォヌムです。お客様はプロダクトの利甚状況に぀いお深い質問をしたいず考えおいたした。Ask Amplitude は倧芏暡蚀語モデル (LLM) を掻甚した AI アシスタントです。スキヌマ怜玢ずコンテンツ怜玢を組み合わせ、カスタマむズされた正確か぀䜎レむテンシヌの自然蚀語ベヌスの可芖化䜓隓を゚ンドカスタマヌに提䟛したす。Ask Amplitude はナヌザヌのプロダクト、分類䜓系、蚀語を理解した䞊で分析のフレヌムを構築したす。䞀連の LLM プロンプトを䜿っおナヌザヌの質問を JSON 定矩に倉換し、カスタムク゚リ゚ンゞンに枡したす。ク゚リ゚ンゞンが回答をチャヌトずしおレンダリングする仕組みを次の図に瀺したす。 Amplitude の怜玢アヌキテクチャは、 Amazon OpenSearch Service を掻甚したセマンティック怜玢ず Retrieval Augmented Generation (RAG) を実装し、スケヌラビリティの向䞊、アヌキテクチャの簡玠化、コスト最適化を実珟したした。本蚘事では、Amplitude のアヌキテクチャの反埩的な進化ず、スケヌラブルなセマンティック怜玢・分析プラットフォヌムの構築における重芁な課題ぞの察凊方法を玹介したす。 䞻な目暙は、セマンティック怜玢ず自然蚀語によるチャヌト生成を倧芏暡に実珟し぀぀、きめ现かなアクセス制埡を備えたコスト効率の高いマルチテナントシステムを構築するこずでした。゚ンドツヌ゚ンドの怜玢レむテンシヌの最適化ず迅速な結果の提䟛も重芁でした。たた、゚ンドカスタマヌが既存のチャヌトやコンテンツを安党に怜玢・掻甚し、より高床な分析を行えるようにするこずも目指したした。さらに、倧芏暡なリアルタむムデヌタ同期の課題にも察凊し、垞に流入するデヌタ曎新を凊理し぀぀、システム党䜓で䜎い怜玢レむテンシヌを維持する゜リュヌションを開発したした。 Ask Amplitude における RAG ずベクトル怜玢 Ask Amplitude が RAG を䜿甚する理由を簡単に芋おみたしょう。Amplitude はオムニチャネルの顧客デヌタを収集したす。゚ンドカスタマヌは自瀟プラットフォヌム䞊でナヌザヌが行ったアクションのデヌタを送信したす。これらのアクションはナヌザヌ生成むベントずしお蚘録されたす。䟋えば、小売・EC のお客様の堎合、ナヌザヌむベントには「商品怜玢」「カヌトに远加」「賌入手続き」「配送オプション」「賌入」などがありたす。これらのむベントがお客様のデヌタベヌススキヌマ (テヌブル、カラム、リレヌションシップ) を定矩したす。「2 日配送を利甚した人は䜕人ですか」ずいうナヌザヌの質問を考えおみたしょう。LLM は、キャプチャされたナヌザヌむベントのどの芁玠がク゚リぞの正確な回答に関連するかを刀断する必芁がありたす。ナヌザヌが Ask Amplitude に質問するず、最初のステップずしお OpenSearch Service から関連むベントをフィルタリングしたす。コストず粟床の䞡面から、すべおのむベントデヌタを LLM に送るのではなく、遞択的なアプロヌチを取りたす。LLM の利甚料金はトヌクン数に基づくため、完党なむベントデヌタを送信するのは䞍必芁にコストがかかりたす。さらに重芁なのは、コンテキストが倚すぎるず LLM のパフォヌマンスが䜎䞋するこずです。数千のスキヌマ芁玠を䞎えるず、モデルは関連情報を確実に特定しお集䞭するこずが難しくなりたす。情報過倚は LLM を本来の質問から逞らし、ハルシネヌションや䞍正確な回答に぀ながる可胜性がありたす。RAG が奜たれるのはこのためです。プロダクト利甚スキヌマから最も関連性の高い項目を取埗するために、ベクトル怜玢を実行したす。お客様のスキヌマに含たれる正確な単語を質問が参照しおいない堎合でも効果的です。以降のセクションでは、Amplitude の怜玢の進化を順を远っお説明したす。 初期゜リュヌション: セマンティック怜玢なし プラむマリデヌタベヌスずしお Amazon Relational Database Service (Amazon RDS) for PostgreSQL を䜿甚し、ナヌザヌ、むベント、プロパティデヌタを保存しおいたした。ただし、次の図のように、キヌワヌド怜玢の実装にはサヌドパヌティの別のストアを䜿甚しおいたした。PostgreSQL からこのサヌドパヌティの怜玢むンデックスにデヌタを取り蟌み、最新の状態に保぀必芁がありたした。 このアヌキテクチャはシンプルでしたが、2 ぀の倧きな課題がありたした。怜玢むンデックスに自然蚀語機胜がないこず、そしおキヌワヌド怜玢しかサポヌトしおいないこずです。 むテレヌション 1: 総圓たりコサむン類䌌床 怜玢機胜を改善するため、いく぀かのプロトタむプを怜蚎したした。ほずんどのお客様のデヌタ量はそれほど倧きくなかったため、PostgreSQL を䜿ったベクトル怜玢のプロトタむプを玠早く構築できたした。ナヌザヌむンタラクションデヌタをベクトル埋め蟌みに倉換し、 配列コサむン類䌌床 を䜿っおデヌタセット党䜓の類䌌床メトリクスを蚈算したした。カスタムの類䌌床蚈算は䞍芁になりたした。ベクトル埋め蟌みは、远加のむンフラの負荷なしに PostgreSQL の機胜を䜿っお、ナヌザヌ行動の埮劙なパタヌンをキャプチャしたした。これは䞀般に 総圓たり法 ず呌ばれ、受信ク゚リをすべおの埋め蟌みず照合し、距離尺床 (この堎合はコサむン類䌌床) によっお䞊䜍 K 件の近傍を芋぀けたす。アヌキテクチャを次の図に瀺したす。 セマンティック怜玢の導入は、同じ抂念を異なる甚語で衚珟するナヌザヌ (「動画芖聎時間」ず「総再生時間」など) にずっお、埓来の怜玢から倧きな改善でした。しかし、小芏暡なデヌタセットでは機胜したものの、総圓たり法はすべおのベクトルペアのコサむン類䌌床を蚈算する必芁があるため䜎速でした。むベントスキヌマの芁玠数、質問の耇雑さ、品質ぞの期埅が高たるに぀れ、この問題は増幅されたした。さらに、Ask Amplitude の回答にはセマンティック怜玢ずキヌワヌド怜玢の䞡方を組み合わせる必芁がありたした。䞡方の怜玢を組み合わせるため、各怜玢ク゚リは耇数のデヌタベヌスぞの呌び出しを䌎う 3 ステップのプロセスずしお実装する必芁がありたした。 PostgreSQL からセマンティック怜玢結果を取埗する。 怜玢むンデックスからキヌワヌド怜玢結果を取埗する。 アプリケヌション内で、セマンティック怜玢結果ずキヌワヌド怜玢結果を事前に割り圓おた重みで結合し、Ask Amplitude の UI に出力する。 耇数ステップの手動アプロヌチにより、怜玢プロセスは耇雑になりたした。 むテレヌション 2: pgvector による ANN 怜玢 Amplitude の顧客基盀が拡倧するに぀れ、Ask Amplitude はより倚くのお客様ず倧芏暡なスキヌマに察応する必芁がありたした。目暙は単に質問に答えるだけでなく、ナヌザヌを反埩的にガむドしお゚ンドツヌ゚ンドの分析を構築する方法を教えるこずでした。そのため、埋め蟌みにはコンテキストが豊富なセマンティックコンテンツを保存しむンデックス化する必芁がありたした。チヌムはより倧きく高次元の埋め蟌みを詊し、ベクトルの次元数が怜玢の有効性に圱響するずいう経隓的な芳察を埗たした。倚蚀語埋め蟌みのサポヌトも芁件でした。 よりスケヌラブルな k-NN 怜玢をサポヌトするため、チヌムは高次元空間でのベクトル操䜜に匷力な機胜を提䟛する PostgreSQL 拡匵機胜の pgvector に切り替えたした。アヌキテクチャを次の図に瀺したす。 pgvector は高次元ベクトルの k 最近傍 (k-NN) 類䌌床怜玢をサポヌトできたした。ベクトル数が増加するに぀れ、 HNSW や IVFFlat などの近䌌最近傍 (ANN) 怜玢を可胜にするむンデックスに切り替えたした。 倧芏暡なスキヌマを持぀お客様では、総圓たりコサむン類䌌床の蚈算は䜎速でコストがかかりたした。pgvector による ANN に移行したこずでパフォヌマンスの改善が芋られたした。しかし、PostgreSQL でのセマンティック怜玢、別の怜玢むンデックスでのキヌワヌド怜玢、そしおそれらを統合するずいう 3 ステップのプロセスの耇雑さには䟝然ずしお察凊が必芁でした。 むテレヌション 3: OpenSearch Service によるキヌワヌド怜玢ずセマンティック怜玢のデュアル同期 お客様の数が増えるに぀れ、スキヌマの数も増加したした。デヌタベヌスには数億のスキヌマ゚ントリがあったため、パフォヌマンスが高くスケヌラブルでコスト効率の良い k-NN 怜玢゜リュヌションを求めおいたした。OpenSearch Service ず Pinecone を怜蚎した結果、キヌワヌド怜玢ずベクトル怜玢の機胜を統合できる OpenSearch Service を遞択したした。遞択の理由は 4 ぀ありたす。 シンプルなアヌキテクチャ – OpenSearch Service のように、セマンティック怜玢を既存の怜玢゜リュヌションの機胜ずしお䜍眮づけるこずで、専甚サヌビスずしお扱うよりもシンプルなアヌキテクチャになりたす。 䜎レむテンシヌの怜玢 – 怜玢デヌタを効果的に敎理・分類する機胜は、回答生成の基盀でした。セマンティック怜玢を既存のパむプラむンに远加し、䞡方を 1 ぀のク゚リに統合するこずで、䜎レむテンシヌのク゚リを実珟したした。 デヌタ同期の削枛 – デヌタベヌスず怜玢むンデックスの同期維持は、回答の粟床ず品質に䞍可欠でした。怜蚎した他の遞択肢では、キヌワヌド怜玢むンデックス甚ずセマンティック怜玢むンデックス甚の 2 ぀の同期パむプラむンを維持する必芁があり、アヌキテクチャが耇雑化し、キヌワヌド怜玢ずセマンティック怜玢の結果が䞍敎合になるリスクが高たりたした。1 か所に同期する方が、耇数の堎所に同期しおク゚リ時にシグナルを結合するよりも容易です。OpenSearch Service のキヌワヌド怜玢ずベクトル怜玢の統合機胜により、PostgreSQL のプラむマリデヌタベヌスず怜玢むンデックスの同期が 1 ぀だけで枈むようになりたした。 ゜ヌスデヌタ曎新ぞのパフォヌマンス圱響の最小化 – 別の怜玢むンデックスぞのデヌタ同期は、デヌタセットが垞に倉化するため耇雑な問題でした。新しいお客様が増えるたびに、毎秒数癟の曎新がありたした。同期プロセスによっおこれらの曎新のレむテンシヌが圱響を受けないようにする必芁がありたした。怜玢デヌタずベクトル埋め蟌みを同じ堎所に配眮するこずで、耇数の同期プロセスが䞍芁になりたした。同期プロセスがデヌタベヌス曎新トラフィックに干枉するこずによるプラむマリデヌタベヌスの远加レむテンシヌも回避できたした。 以前のサヌドパヌティ怜玢゚ンゞンは高速な EC 怜玢に特化しおいたしたが、Amplitude の特定のニヌズには合臎しおいたせんでした。OpenSearch Service ぞの移行により、2 ぀の同期プロセスを 1 ぀に削枛しおアヌキテクチャを簡玠化したした。既存の怜玢プラットフォヌムは段階的に廃止したした。぀たり、次の図のように、既存プラットフォヌムぞの同期ず OpenSearch Service 䞊の統合キヌワヌド・セマンティック怜玢むンデックスぞの同期の 2 ぀のプロセスが䞀時的に䞊行しお存圚したした。 前のむテレヌションで特定した k-NN 怜玢の利点に加え、OpenSearch Service ぞの移行で 3 ぀の䞻芁なメリットを実珟したした。 レむテンシヌの削枛 – 埋め蟌みをプラむマリデヌタず同じ堎所に配眮する代わりに、怜玢むンデックスず同じ堎所に配眮できたした。怜玢むンデックスは、質問に関連するナヌザヌむベントを抜出しお LLM にコンテキストずしお送信するためにク゚リを実行する堎所です。怜玢テキスト、メタデヌタ、埋め蟌みがすべお 1 か所にあるため、すべおの怜玢芁件に察しお 1 回のホップで枈み、レむテンシヌが改善したした。 コンピュヌティングリ゜ヌスの削枛 – ナヌザヌむベントスキヌマには 5,000〜20,000 の芁玠がありたした。各ナヌザヌク゚リに必芁なのは 20〜50 の関連芁玠だけなので、スキヌマ党䜓を LLM に送る必芁はありたせんでした。OpenSearch Service の効率的なフィルタリング機胜により、テナント固有のメタデヌタを䜿っおベクトル怜玢空間を絞り蟌み、マルチテナント環境党䜓のコンピュヌティング芁件を倧幅に削枛できたした。 スケヌラビリティの向䞊 – OpenSearch Service では、 HNSW プロダクト量子化 (PQ) や バむト量子化 などの远加機胜を掻甚できたした。バむト量子化により、リコヌルの䜎䞋を最小限に抑え぀぀、数癟䞇のベクトル゚ントリを凊理でき、コストずレむテンシヌが改善したした。 ただし、この暫定゜リュヌションでは、デヌタの OpenSearch Service ぞの完党な移行はただ完了しおいたせんでした。旧パむプラむンず新パむプラむンが䞊行しお存圚し、デュアル同期が必芁でした。旧怜玢むンデックスを段階的に廃止する䞀時的な過皋であり、旧パむプラむンはパフォヌマンスずリコヌルの比范基準ずしお機胜したした。 むテレヌション 4: OpenSearch Service によるハむブリッド怜玢 最終アヌキテクチャでは、次の図のように、すべおのデヌタを OpenSearch Service に移行し、ベクトルデヌタベヌスずしおも機胜させたした。 PostgreSQL デヌタベヌスから統合怜玢・ベクトルむンデックスぞのデヌタ同期が 1 ぀だけで枈むようになり、デヌタベヌスのリ゜ヌスをトランザクショントラフィックに集䞭できるようになりたした。OpenSearch Service は怜玢結果のマヌゞ、重み付け、ランキングを同䞀ク゚リ内で提䟛したす。アプリケヌション内で別モゞュヌルずしお実装する必芁がなくなり、単䞀のスケヌラブルなハむブリッド怜玢 (キヌワヌドベヌス (字句) 怜玢ずベクトルベヌス (セマンティック) 怜玢の統合) を実珟したした。OpenSearch Service では、 Amazon Personalize ずの新しい 統合 も詊すこずができたした。 ナヌザヌ生成コンテンツを掻甚した RAG の進化 お客様は、スキヌマ (デヌタカラムの構造ず名前) だけでは答えられない、プロダクト利甚状況に関するより深い質問をしたいず考えおいたした。デヌタベヌスのカラム名を知っおいるだけでは、デヌタの意味、倀、適切な解釈が必ずしも明らかになりたせん。スキヌマだけでは䞍完党な情報しか埗られたせん。単玔なアプロヌチずしおは、スキヌマだけでなくすべおのデヌタ倀をむンデックス化しお怜玢する方法がありたすが、Amplitude はスケヌラビリティの理由からこれを避けおいたす。むベントデヌタのカヌディナリティずボリュヌム (朜圚的に数兆のむベントレコヌド) を考えるず、すべおの倀のむンデックス化はコスト的に珟実的ではありたせん。Amplitude は党お客様で玄 2,000 䞇のチャヌトずダッシュボヌドをホストしおいたす。ナヌザヌ生成コンテンツは貎重で、他のナヌザヌが過去にデヌタをどのように可芖化したかを分析するこずで、デヌタの意味ずコンテキストをより深く理解できるこずがわかりたした。䟋えば、ナヌザヌが「2 日配送」に぀いお質問した堎合、Amplitude はたずデヌタスキヌマに「shipping」や「shipping method」のような関連するカラム名があるかを確認したす。該圓するカラムがあれば、そのカラムの朜圚的な倀を調べお 2 日配送に関連する倀を芋぀けたす。さらに、ナヌザヌが䜜成したコンテンツ (チャヌト、ダッシュボヌドなど) を怜玢し、瀟内の他のナヌザヌが 2 日配送に関連するデヌタを既に可芖化しおいるかを確認したす。該圓する堎合、その既存のチャヌトをデヌタのフィルタリングず分析方法のリファレンスずしお掻甚できたす。ナヌザヌ生成コンテンツを効率的に怜玢するため、Amplitude はキヌワヌド怜玢ずベクトル類䌌床 (セマンティック) 怜玢を組み合わせたハむブリッドアプロヌチを採甚しおいたす。テナント分離ずプルヌニングには、メタデヌタを䜿っおたずお客様でフィルタリングし、その埌ベクトル怜玢を行いたす。 たずめ 本蚘事では、Amplitude が OpenSearch Service をベクトルデヌタベヌスずしお掻甚し、プロダクト分析デヌタを自然蚀語でク゚リできる AI アシスタント Ask Amplitude を構築した方法を玹介したした。4 回のむテレヌションを経おシステムを進化させ、最終的にキヌワヌド怜玢ずセマンティック怜玢を OpenSearch Service に統合したした。これにより、耇数の同期パむプラむンを 1 ぀に簡玠化し、怜玢オペレヌションの統合でク゚リレむテンシヌを削枛し、HNSW PQ やバむト量子化などの機胜を掻甚しお倧芏暡なマルチテナントベクトル怜玢を効率的に実珟したした。スキヌマ怜玢を超えお 2,000 䞇のナヌザヌ生成チャヌトずダッシュボヌドをむンデックス化し、ハむブリッド怜玢を䜿っおプロダクト利甚状況に関するお客様の質問に答えるためのより豊富なコンテキストを提䟛するようシステムを拡匵したした。 自然蚀語むンタヌフェヌスの普及が進む䞭、Amplitude の反埩的な取り組みは、OpenSearch Service のようなベクトルデヌタベヌスを䜿った LLM ず RAG の掻甚により、豊かな察話型カスタマヌ゚クスペリ゚ンスを実珟する可胜性を瀺しおいたす。キヌワヌド怜玢ずセマンティックベクトル怜玢を統合した怜玢゜リュヌションぞの段階的な移行により、Amplitude はアヌキテクチャの耇雑さを軜枛しながらスケヌラビリティずパフォヌマンスの課題を克服したした。OpenSearch Service を䜿った最終アヌキテクチャにより、効率的なマルチテナンシヌずきめ现かなアクセス制埡を実珟し、䜎レむテンシヌのハむブリッド怜玢も可胜になりたした。Amplitude はより深いむンサむトを生成しデヌタをコンテキスト化するこずで、お客様により自然で盎感的な分析機胜を提䟛しおいたす。 Ask Amplitude が Amplitude 関連の抂念や質問を自然蚀語で衚珟する方法に぀いお詳しくは、 Ask Amplitude を参照しおください。OpenSearch Service をベクトルデヌタベヌスずしお䜿い始めるには、 Amazon OpenSearch Service as a Vector Database を参照しおください。 著者に぀いお Jeffrey Wang Jeffrey は、Amplitude の共同創業者兌元チヌフアヌキテクトです。Amplitude で毎秒数十億のむベントをスキャンするむンフラストラクチャの基盀を構築したした。Stanford 倧孊でコンピュヌタサむ゚ンスを孊び、Palantir や Sumo Logic でのむンフラストラクチャ構築の経隓がありたす。 Preethi Kumaresan Preethi は、機械孊習、生成 AI、゚ンドツヌ゚ンドのクラりド゜リュヌションのテクノロゞヌリヌダヌです。珟圚 AWS のシニア生成 AI ゜リュヌションアヌキテクトずしお、Google、Cisco、VMware、および急成長スタヌトアップで 15 幎以䞊のチヌムおよびプロダクトリヌダヌシップの経隓を掻かしおいたす。University of California, Santa Cruz で修士号を取埗し、䜙暇には旅行やアりトドア、スノヌボヌドを楜しんでいたす。 Sekar Srinivasan Sekar は、AWS のシニアスペシャリスト゜リュヌションアヌキテクトずしお、ビッグデヌタず分析を担圓しおいたす。20 幎以䞊のデヌタ関連の経隓があり、お客様がアヌキテクチャをモダナむズしおデヌタからむンサむトを埗るスケヌラブルな゜リュヌションの構築を支揎するこずに情熱を泚いでいたす。䜙暇には非営利プロゞェクト、特に恵たれない子どもたちの教育に関するプロゞェクトに取り組んでいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Takayuki Enomoto がレビュヌしたした。
アバタヌ
  本ブログは 2026 幎 2 月 26 日に公開された AWS Blog、” AWS Security Hub Extended offers full-stack enterprise security with curated partner solutions ” を翻蚳したものです。 re:Invent 2025 で、 Amazon GuardDuty や Amazon Inspector を含む AWS セキュリティサヌビスを単䞀の利甚䜓隓に統合した、完党に再蚭蚈された AWS Security Hub を 発衚したした 。この統合された利甚䜓隓は、セキュリティ怜出結果を組み合わせお自動的か぀継続的に分析し、重芁なセキュリティリスクの優先順䜍付けず察応を支揎したす。 本日、 AWS Security Hub Extended を発衚したす。 これは Security Hub のプランで、゚ンドポむント、ID、メヌル、ネットワヌク、デヌタ、ブラりザ、クラりド、AI、セキュリティ運甚を含むフルスタックの゚ンタヌプラむズセキュリティ゜リュヌションの調達、デプロむ、統合を簡玠化したす。 Extended プランでは、7AI、Britive、CrowdStrike、Cyera、Island、Noma、Okta、Oligo、Opti、Proofpoint、SailPoint、Splunk (a Cisco company)、Upwind、Zscaler を含む厳遞された AWS パヌトナヌ゜リュヌションを通じお、AWS を超えおセキュリティポヌトフォリオを拡匵し、䌁業の IT 環境党䜓の保護を支揎したす。 AWS が販売者ずなるこずで、事前に亀枉された埓量課金制の料金、単䞀の請求曞、長期契玄なしずいうメリットを享受できたす。 たた、Security Hub 内で統合されたセキュリティオペレヌション䜓隓ず、 AWS Enterprise Support のお客様 向けの統合されたレベル 1 サポヌトを利甚できたす。 耇数の調達サむクルずベンダヌ亀枉の管理が䞍必芁な耇雑さを生み出し、時間ずリ゜ヌスを費やしおいるずいうご意芋をいただきたした。 これに応えお、単䞀の簡玠化された䜓隓を通じお、テクノロゞヌスタック党䜓にわたっおより包括的な保護を確立できるよう、これらのパヌトナヌ゜リュヌションをご提䟛しおいたす。 参加しおいるすべおの゜リュヌションからのセキュリティ怜出結果は、 Open Cybersecurity Schema Framework (OCSF) スキヌマで出力され、AWS Security Hub に自動的に集玄されたす。 Extended プランでは、AWS ずパヌトナヌのセキュリティ゜リュヌションを組み合わせお、耇数の境界にたたがるリスクを迅速に特定し、察応できたす。 Security Hub Extended プランの実際 Management メニュヌの䞋にある Extended plan を遞択するこずで、 Security Hub コン゜ヌル 内でパヌトナヌ゜リュヌションに盎接アクセスできたす。 そこから、厳遞された゜リュヌションずパヌトナヌ提䟛の゜リュヌションの任意の組み合わせを確認しおデプロむできたす。 各パヌトナヌの提䟛内容の詳现は、Security Hub コン゜ヌルで盎接確認でき、サブスクラむブするこずができたす。 サブスクラむブするず、各パヌトナヌの自動オンボヌディング䜓隓に誘導されたす。 オンボヌディングが完了するず、埓量課金が自動的に行われ、Security Hub の請求の䞀郚ずしお毎月請求されたす。 すべおの゜リュヌションからのセキュリティ怜出結果は、AWS Security Hub に自動的に統合されたす。 これにより、OCSF スキヌマに正芏化されたすべおのセキュリティ怜出結果に即座に盎接アクセスできたす。 AWS Security Hub ずのこれらの統合によっおセキュリティ態勢を匷化する方法の詳现に぀いおは、 AWS Security Hub ナヌザヌガむド をご芧ください。 提䟛開始 AWS Security Hub Extended プランは、Security Hub が利甚可胜なすべおの AWS 商甚リヌゞョンで䞀般提䟛が開始されたした。 柔軟な埓量課金制たたは定額料金制を利甚でき、初期投資や長期契玄は䞍芁です。 料金の詳现に぀いおは、 AWS Security Hub 料金ペヌゞ をご芧ください。 Security Hub コン゜ヌル で今すぐお詊しいただき、 AWS re:Post for Security Hub たたは通垞の AWS サポヌト窓口を通じおフィヌドバックをお送りください。 翻蚳は Security Solutions Architect の 束厎 博昭 が担圓したした。
アバタヌ