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 の 松崎 博昭 が担当しました。