はじめに こんにちは。2026年4月にInsight Edge（以下、IE）へデータサイエンティストとして新卒入社した田中です。 本記事を執筆している2026年9月時点で、入社から約5か月が経ちました。新卒データサイエンティスト（DS）の2期生として、新卒研修から最初の案件への参画までを経験する中で、入社前には見えていなかったIEの特徴が少しずつ分かってきました。本記事では、実際に働いて感じたことを新卒の視点からお伝えします。 IEへの新卒入社を検討している学生の方はもちろん、商社グループでデータサイエンティストとして働くことに興味がある方にとっても、本記事が参考になれば幸いです。 目次 1. 自己紹介とIEを知ったきっかけ 1.1 大学での研究 1.2 IEを知ったきっかけ 2. 新卒でInsight Edgeに入社した理由 2.1 幅広い事業領域と少数チームの機動力 2.2 メンターから感じた高い技術力と温かい人柄 2.3 学び続けながら柔軟に働ける環境 3. 入社して初めて分かった3つのこと 3.1 分野横断の研修と早期の案件配属 3.2 オフィスで実感した住友商事との距離の近さ 3.3 案件外の活動を通じた学びと交流 4. まとめ 1. 自己紹介とIEを知ったきっかけ まずは自己紹介として、学生時代のバックグラウンドとIEを知ったきっかけについて紹介します。 1.1 大学での研究 大学時代は、経営工学を専攻しており、さまざまな産業領域のテキスト・表・画像・動画データから知識抽出をすることに焦点を当てた研究分野と、自動運転を中心とする強化学習の応用研究の両方を専門とする研究室に所属していました。当時は25人ほどいた学生のうち6〜7割が留学生で、ミーティングは常に英語で行われる国際色豊かな環境でした。 修士の頃は、産総研との共同研究として、スポーツの試合から収集したプレーデータや映像をもとに、テキスト速報や実況・解説を生成する応用研究に取り組んでいました。 1.2 IEを知ったきっかけ IEを知ったきっかけは、修士1年の夏に受講した大学のデータサイエンス講義です。毎回異なる企業が登壇し、さまざまなデジタル活用事例を紹介する講義でした。ある回にIEの社員が登壇し、そこで初めてIEを知りました。 講義では、IEが住友商事グループ内のDX推進を担っている会社であることが紹介されていました。また、案件としては商社ならではの幅広い産業分野を扱い、その中でPoCからプロダクト開発までを内製の少人数のチームで進めていることも知りました。 講義を通じて、私はIEに次のような魅力を感じました。 さまざまな事業領域に触れられそうで、面白そう 海外案件に関わり、研究室で英語を使ってきた経験も生かせそう 優秀な技術者と働きながら、若いうちから裁量を持って成長できそう いずれも自分の就職活動の軸と合っていたため、講義の最後に案内されたインターンシップへの応募を決めました。 その後、面接を経て、2024年夏の1か月間のインターンシップに参加しました。このインターンシップは、講義だけでは分からなかったIEの詳しい仕事内容や組織体制などを、より深く知る機会になりました。その内容については次の章で詳しく説明していきます。 また、インターンシップで取り組んだ内容は、 こちらの記事 で紹介していますので、興味のある方はぜひこちらもご覧ください。 2. 新卒でInsight Edgeに入社した理由 本章では、インターンシップでの経験を踏まえた、私がIEへの入社を決めた理由について、3つ紹介します。 2.1 幅広い事業領域と少数チームの機動力 IEは住友商事グループの内製的なパートナーとして、コーポレートや、グループ内の事業会社の方々と目標を共有しながらプロジェクトに取り組みます。案件によっては、提示された要件を実装するだけでなく、課題がまだ明確になっていない段階から議論し、PoCや開発、現場での活用まで継続して関わります。IEがデータやAIに関する知見を提供する一方で、クライアントからは業務や事業について学び、双方の知見を持ち寄って解決策を考えられることに、内製パートナーならではの健全な関係性を感じました。 また、住友商事グループには多様な事業会社があり、海外案件を含むさまざまな業界の事業や課題に触れられることも魅力でした。IEは、住友商事グループの幅広い事業基盤をフィールドとしつつ、比較的少人数でのプロジェクトを進めます。新しい技術を積極的に取り入れ、まずは自分たちで検証してみるという姿勢が根付いており、成長環境として理想的だと感じていました。 2.2 メンターから感じた高い技術力と温かい人柄 インターンシップでは、3人の方にメンターとしてご指導いただきました。皆さんが豊富な経験と高い技術力を備えながらも、新しい技術に強い好奇心と探究心を持ち、学んだことを楽しみながら仕事に生かそうとする姿勢を持っていたことが印象に残っています。経験を積んだ後も学び続ける方々と働ける環境は、技術者として成長していくうえで非常に魅力的だと感じました。 加えて、私の話や疑問へ耳を傾け、気さくに応じてくださった姿も印象的でした。入社後に活躍できるか、不安を持つ新卒もいると思いますが、私の場合は、「IEであれば大丈夫」と思えたことも入社を決めた理由の1つです。 2.3 学び続けながら柔軟に働ける環境 働く環境や制度の充実も、IEへの入社を決めた理由の1つです。例えば、業務時間の一部を自己研鑽や勉強会に充てられる制度があります。目の前の案件に必要な知識だけでなく、自分が興味を持った技術を試し、将来の仕事につなげる時間も用意されています。そこに、社員の継続的な成長を大切にする姿勢を感じました。 また、業務内容やチームの状況に応じて、テレワークやサテライトオフィスを利用できる点にも魅力を感じました。私自身は出社派で、対面で働くことから得られるものも大きいと感じています。一方、その日の業務や生活に合わせて働く場所を選べる点は、ライフステージが変化しても働き続けるうえで大きな魅力だと思いました。 IEに入社してから、「いろいろな選択肢があった中で、なぜ新卒でIEに入社したの？」と聞かれることがあります。私にとっては 大企業グループの幅広い事業にパートナーとして関われること 技術力と人間的な魅力を備えた社員の方々と働けること 新しい技術を学びながら柔軟に働けること の3つが、私がIEへの入社を決めた大きな理由でした。以上が本章のまとめです。 3. 入社して初めて分かった3つのこと 夏季インターンシップ後に本選考を経て、内定をいただきました。その後、自ら志願し、修士2年の4月から約6か月間、内定者インターンシップに参加しました。途中で1か月の研究留学を挟みましたが、このインターンシップでは音声対話型マルチエージェントに関する調査に主に取り組みました。この内容に興味がある方は、ぜひ こちらの記事 をご覧ください。 2つのインターンシップを通じてIEへの理解は深まりましたが、それでも、入社して初めて分かったことがいくつかありました。ここからは、新卒研修や最初の案件への参画を通じて特に強く感じたことを、3つに分けて紹介します。 3.1 分野横断の研修と早期の案件配属 研修 入社後の最初の2か月間は、新卒研修として座学とアプリ開発に取り組みました。開発したアプリの詳細は割愛しますが、アプリ開発研修では1つのアプリを企画から開発まで形にしました。参加者は私一人だったため、データサイエンティスト（DS）だけでなく、エンジニア（ENG）やプロジェクトマネージャー（PM）の業務も体験しました。各職種に求められる基礎知識と、プロジェクトにおける役割を学べるように設計された研修でした。 新卒研修で体験したPM・ENG・DSの役割（筆者作成） この研修で特に良いと感じたのは、アプリ開発の進捗に合わせて、その時点で必要となる技術を座学で学べるようなスケジュールが組まれていたことです。座学で得た知識をすぐにアプリ開発で試せるため、知識を学ぶだけで終わらず、実践を通して理解を深めることができました。 この座学研修で学んだ内容を、DS・ENG・PM・その他の分野に分けると、次のようになります。 分野 座学研修で学んだ分野 DS ・データ前処理・後処理 ・時系列分析 ・画像処理 ・統計 ・数理最適化 ENG ・エンジニア心構え ・データベースモデリング ・オブザーバビリティ ・Webを支える技術（TCP/IP） ・ソフトウェアテスト ・AIコーディング ・生成AI概論 ・GitHub/Gitワークフロー ・IaC・CI/CD ・UI/UX ・良い設計・良いコード ・セキュリティ PM ・プロジェクトマネジメント ・開発プロセス その他 ・テクニカルライティング ・スライド作成技術 研修を通じ実感したことは、DSに求められるのは、与えられたデータを分析してモデルを作ることだけではないということでした。IEのプロジェクトでは、エンジニアチーム内のPM・ENG・DSがそれぞれの専門性を持ち寄ります。PMの視点を知ることは、プロジェクトでのヒアリングや課題整理、検証計画について、技術者の立場から意見を出す際に役立ちます。また、ENGの視点を知ることで、PoC後の本番開発を見据えてコードやインフラを整備したり、PMが整理した要件を開発へつなげたりしやすくなります。 生成AIをはじめとするツールによって、技術の調査やコーディングの進め方は変わりつつあります。だからこそ、これからのDSには自分の専門領域だけに閉じない姿勢が必要で、PMやENGの仕事も自分ごととして捉え、プロジェクト全体を前に進める力がより重要になると私は考えています。分野を横断して学ぶこの研修は、私にとって、将来どのようなDSを目指したいかを考えるきっかけを与えてくれました。 案件配属 5月に研修を終え、6月から実際のプロジェクトチームに参画しました。私が配属されたチームは比較的少人数で、新卒の私にも早い段階からタスクを任せていただき、議論の中で意見を求められました。たとえばMVP開発の方針提案を検討する場面では、対象モデルの仕様を調査し、その内容をチームに報告した上で、推奨する活用方針などを提案しました。指示された作業をこなすだけでなく、研修や学生時代に学んだことをプロジェクトに生かし、技術者の一人として自分の考えをチームに伝えることが期待されている点は、入社前の想像以上に印象的でした。 早い段階からタスクを任せていただきながら、一方で分からないことや判断に迷うことがあれば、いつでもメンターに相談できる環境が整っていました。案件への配属後も、案件について相談する機会や、仕事の進め方・今後伸ばしたいスキルについて話す機会が設けられています。 このサポート体制には、現在も大きく助けられています。うまくできた点は評価していただき、改善すべき点は具体的に指摘していただけます。そのため、これまでの経験を振り返り、学びを次にどう生かすかを考える力を日々鍛えることができています。一人の新人にきちんと向き合い、成長を支えてくれる方々がいることは、IEの良さだと感じています。 3.2 オフィスで実感した住友商事との距離の近さ 私は新卒DSの2期生ということもあり、入社前は、IE社内で同世代とのつながりをどの程度持てるのかは、少し気になっていたポイントでした。実際に入社してみると、1つ上の先輩方が優しく接してくださったので安心しました。 また、オフィスの同じフロアには、住友商事の複数のデジタル関連部門が集まっています。そこで働く新卒社員の方々に自分から声をかけ、一緒にランチへ行くなど、会社や部署の枠を越えて交流できました。IE社内に限らず、住友商事グループまで視野を広げて同世代とのつながりを持てることは、入社前には想像していませんでした。 交流の中では、互いの仕事や担当領域について話すこともあります。そうした会話を通じて、住友商事の方々がどのような視点で事業やデジタル活用を捉えているのかを知ることができます。一方で、私から技術的な考え方を伝えることもあり、それぞれの立場や専門性を生かした意見交換ができています。将来同じプロジェクトに関わる際も、こうした日頃の関係が連携のしやすさにつながると感じています。 「住友商事グループと近い距離で働く」という言葉を、入社前は主に仕事上の関係として捉えていました。実際には同じフロアで働き、日常的に会話できる環境があります。そのため、同じグループの仲間として働いていることをより実感できました。 3.3 案件外の活動を通じた学びと交流 IEには、担当案件以外にも、業務時間内の自己研鑽や、社員同士で交流するための活動があります。 私が実際に参加している学習活動には、次のようなものがあります。 勉強会 ：業務時間の10％を目安に自己研鑽へ充てる取り組みがあり、執筆時点では、私は先輩社員と一緒に統計の勉強をしています。疑問点を相談し、考え方を共有しながら学べることに、一人で勉強する場合にはない良さを感じています。 DSチームのLT会 ：DSチームのメンバーが最近学んだ技術や試したことを、短い発表形式で共有する会です。自分の担当案件だけを追っていると触れにくい技術も知ることができ、継続的なキャッチアップの機会になっています。 海外グループとの技術交流会 ：私は有志として、住友商事グループの海外拠点で働く方々と英語で技術情報を交換する会に参加しています。海外での技術活用や異なる考え方に触れられるだけでなく、実際に英語で技術について議論する経験にもなっています。これは将来、海外案件に参加するための良い練習だと感じており、積極的に参加しています。 このように、基礎をじっくり学ぶ機会、新しい技術を社内で共有する機会、海外の方々から異なる視点を得る機会など、案件外でも自分を高める機会がたくさんあります。こんなにたくさん学びの機会があるとは入社前は知りませんでした。 また、技術に関する活動だけでなく、部活動やシャッフルランチなど、社員同士の交流を目的とした取り組みもあります。仕事の性質上、少人数のチームで案件を進め、テレワークも利用できる環境では、担当案件が異なる社員との接点が少なくなることもあります。そのため、こうしたイベントが会話のきっかけとなり、案件や職種を越えて、社内にどのような経験や専門性を持つ人がいるのかを知ることができます。 入社前は、勉強会や社内活動を、それぞれ独立した制度のように捉えていました。しかし実際には、技術を学ぶ場であると同時に、普段は一緒に仕事をしない人とつながる入り口にもなっています。用意された機会を自分から活用することで、学べる範囲も、相談できる相手も国内外へ広げていけることが、入社して分かったIEの特徴の1つです。 4. まとめ 入社前の私は、IEに対して「住友商事グループの幅広い事業に関われる」「優秀な技術者と働ける」「新しい技術に挑戦できる」という印象を持っていました。入社して5か月が経った今、その印象は大きく変わっていません。一方で、実際にIEの一社員として働いたからこそ、それぞれの魅力をより具体的に理解できるようになりました。 分野横断の研修を経て、早い段階から案件に入り、新卒でも一人の技術者として意見を求められること。その一方で、メンターをはじめ、困ったときに相談できる方々がいること。住友商事のデジタル関連部門と同じフロアで働き、会社の枠を越えて日常的に交流できること。そして、案件外にも技術を学び、人とつながるための機会が用意されていること。これらは、入社前には十分に想像できていなかったIEの姿でした。 IEは私にとって、データサイエンスの専門性を深めるだけでなく、他職種やグループ内会社の方々と協力しながら、技術を企業価値につなげる経験を積める環境だと感じています。一方で、こうした環境を生かすためには、自分から学び、周囲に働きかける姿勢も必要です。入社からまだ5か月で、私自身も学ぶことばかりですが、これから1つずつ経験を積んでいきたいと思います。 本記事が、IEへの新卒入社や、商社グループでデータサイエンティストとして働くことに興味を持つ方にとって、少しでも参考になれば幸いです。 Insight Edgeでは、新卒採用に加えてインターンシップの募集も行っています。少しでも興味を持っていただけた方は、ぜひ 新卒採用、インターンシップ募集ページ をご覧ください。

本記事は「 Build full-stack AWS applications in minutes with AI-powered scaffolding 」を翻訳したものです。 AI アシスタントを使えば、AWS 上で動くアプリケーションや Web サイトを数分で立ち上げられます。しかし、実際のお客様に提供できる本番相当のものにたどり着くのは、依然として難しい部分です。セキュリティ、可観測性、型安全性、そしてレジリエンスは、本番運用では譲れない要件です。AI アシスタントがこれらすべてを一度で正しく実装できることはまれで、その出力を本番品質まで固めるには、レビュー・修正・テストのサイクルを何度も繰り返す必要があります。 このギャップを埋めるため、私たちは Nx Plugin for AWS のバージョン 1.0 をリリースします。 本記事では、それが何であるか、なぜこのように作ったのか、そして、お客様である Bingo Industries がこれを使ってマルチエージェントのソリューションをアイデアから本番まで 3 週間未満で進めた事例を簡単にご紹介します。 Nx Plugin for AWS とは何か Nx は、単一のリポジトリの中でアプリケーションを構成する多数のプロジェクトを管理する、拡張可能なオープンソースのビルドシステムです。Nx は プラグイン によって拡張でき、Nx Plugin for AWS はそのひとつで、AWS 上にアプリケーションをスキャフォールディングするためのオープンソースのツールキットです。これは Nx ジェネレーター のライブラリで、各ジェネレーターはリクエストに応じてアプリケーションの一部（API、Web サイト、AI エージェント）を、それらを動かすためのクラウドインフラストラクチャとともに構築します。 各ジェネレーターは、動作しデプロイ可能なアプリケーションの一部を書き出します。それぞれの部品には、セキュリティ・可観測性・型安全性のベストプラクティスがあらかじめ組み込まれています。また各ジェネレーターは決定的（deterministic）です。つまり、毎回同じ結果を生成します。これにより、AI アシスタントが自ら考え出さなければならないものではなく、信頼できる土台としてジェネレーターの上に構築を進められます。AI アシスタントはこれらのジェネレーターを自分で実行できるため、価値のある部分、すなわちアプリケーションをあなたのものにするロジックに労力を割けるようになります。 上の図は Nx Plugin for AWS を視覚的に示したものです。ワークスペースを作成し、エージェントまたは CLI を使ってアプリケーションの各部品をスキャフォールディングします。 クイックスタート: フルスタックのエージェンティックアプリケーションを数分で まずはワークスペース、つまり空の Nx モノレポから始めます。ワークスペースを作成するには、ターミナルで次のコマンドを実行します。 pnpm create @aws/nx-workspace my-project --no-interactive この例では pnpm を使っていますが、お好みで npm 、 yarn 、 bun も使えます。デフォルトではインフラストラクチャは AWS Cloud Development Kit (CDK) で定義されますが、 Terraform をお好みの場合は上記のコマンドに --iac terraform を付けて実行できます。エージェントを構築するので、Amazon Bedrock を呼び出せる AWS 認証情報 が必要です。 ワークスペースを Kiro CLI などの AI コーディングエージェントで開き、アプリケーションの構築を依頼します。たとえば次のようにします。 Nx Plugin for AWS を使って、shadcn と Cognito 認証を備えた React の Web サイトを、AG-UI プロトコル経由で TypeScript の Strands エージェントに接続し、それをデプロイするためのインフラストラクチャからなるフルスタックアプリケーションを構築してください。 AI エージェントは、上記のコマンドで作成したすべてのワークスペースにあらかじめ設定されている Nx Plugin for AWS MCP サーバー を使用します。このプロンプトによって、 Strands エージェント、Amazon Cognito ログインを備えた React フロントエンド、 AG-UI プロトコル 経由でユーザーとエージェントがやり取りする CopilotKit のチャットインターフェイス、そしてプロジェクトをデプロイするために必要な AWS リソースを定義したインフラストラクチャプロジェクトが手に入ります。 Web サイトとエージェントを自分のマシン上でローカルに起動するには、次を実行します。 pnpm dev Web サイトとエージェントは、コードを編集するとどちらもホットリロードされます。ローカルでの変更に満足したら、エージェントに AWS へのデプロイを依頼できます。 ここでは Nx Plugin for AWS をエージェントで駆動しましたが、お好みで CLI を使ってアプリケーションを手作業で組み立てることもできます。ステップバイステップの例は後述しますが、 クイックスタートガイド もご覧ください。Nx と Nx Plugin for AWS の恩恵を受けるためにゼロから始める必要はなく、ドキュメントでは 既存プロジェクトへのプラグイン追加 についても解説しています。 なぜこれを作ったのか 私たちは AWS の PACE（Prototyping and AI Customer Engineering）チームの一員で、スピードと本番運用への備えという緊張関係に日々向き合っています。私たちは、まだ明確な答えのない問題や、これまで作られたことのない技術的にリスクのあるアイデアについて、お客様と一緒に取り組みます。各エンゲージメントの期間は 4〜6 週間で、目標はただひとつ、特定のアイデアが実現可能かどうかを証明することです。 プロトタイプの価値は、問題の最も難しい部分、つまり従うべき確立されたパターンが存在しない部分から生まれます。これほど短いタイムラインでは、私たちのエンジニアは本番運用に向けたハードニングではなく、お客様の中核的な課題に時間を使う必要があります。とはいえ、プロトタイプは使い捨てるのではなく本番まで持っていけるほうが、お客様にとってより役に立ちます。 AWS 上での構築は通常、Infrastructure as Code、バックエンドサービス、フロントエンド、そして多くの場合、同一プロジェクト内に複数の言語が混在することを意味します。私たちには、選んだ言語に依存せず、多数の可動部からなるプロジェクトを管理できるビルドシステムが必要でした。私たちのチームは Nx にたどり着き、まさにこの目的のために数年間使ってきました。Nx はプロジェクトごとに一貫したモノレポのワークフローを、技術選定にかかわらず提供してくれます。ただ、Nx にモノレポを任せてもなお、私たちは各エンゲージメントの冒頭でプロジェクトの土台を手作業で組み立てていました。私たちは、自分たちのベストプラクティスをあらかじめ組み込んだ形で土台をスキャフォールディングし、本番に近いところからスタートして、限られた期間をお客様の課題に効率よく使いたいと考えました。 ジェネレーターがテンプレートやライブラリに勝った理由 現在の形にたどり着くまでに、私たちはいくつかのアプローチを試しました。 最初は、各エンゲージメントの冒頭でフォークするスターターテンプレートから始めました。フォークは変更した瞬間にドリフト（乖離）します。テンプレート側で加えた修正はフォークには決して届かず、必要かどうかにかかわらずテンプレート全体を引き継ぐことになります。 次に、ライブラリベースのアプローチを試し、プロジェクト構造・アプリケーションコード・インフラストラクチャコードを、再利用可能で型付きのビルディングブロックとして定義しました。これはテンプレートの問題の多くを解決しました。必要な部品だけを使えて、ライブラリへの改善はそれを使うすべてのプロジェクトに取り込めます。しかし、いくつか制約もありました。エンジニアがライブラリの公開していない設定を必要とした瞬間に、手が止まってしまうのです。ライブラリがサポートする範囲を超えたカスタマイズには、分かりにくい回避策、ライブラリ周りのコピー＆ペースト、あるいはライブラリのオーナーが拡張してくれるのを待つことが必要でした。PACE エンゲージメントの 4〜6 週間というタイムラインでは、どの選択肢も現実的ではありませんでした。 最終的にしっくり来たのが Nx ジェネレーター でした。フォークするテンプレートや依存するライブラリではなく、ジェネレーターはコードを直接あなたのワークスペースに書き込みます。生成された瞬間からそのコードはあなたのものであり、扱うのにプラグイン固有の知識は一切必要ありません。ジェネレーターが想定していなかった何かを変更したくなったら、いつも通りにコードを編集できます。そして、テンプレートでは生成コードが取り残されていたのに対し、 Nx マイグレーション によって、私たちが提供する改善が、以前にスキャフォールディングしたワークスペースにも届きます。ジェネレーターはいつでも実行できるので、既存の Web サイトに認証を追加したり、数か月前に作った API にフロントエンドを接続したりできます。各ジェネレーターは意図的に自己完結していて明確に説明されているため、個々のファイルではなく、より高いレベルのビルディングブロックで考えられるようになります。手作業でも AI アシスタントを使う場合でも、単一のコマンドで組み立てられる、コンポーネント丸ごとの単位で考えられるのです。 Nx Plugin for AWS の仕組み まずワークスペースを作成し、次にジェネレーターを使ってアプリケーションを組み立て、必要なものを必要なときにだけ追加していきます。ジェネレーターは単なるファイルテンプレート以上のものです。新しいファイルを書き出すだけでなく、既存のファイルを変更し、依存関係を配線し、設定を更新します。 API・Web サイト・データベース・AI エージェント向けのコアジェネレーター ジェネレーターは、ほとんどの AWS アプリケーションが構成される主要なコンポーネントを、TypeScript と Python の両方でカバーします。たとえば次のとおりです。 tRPC 、 FastAPI 、 Smithy を使った API と、それらをデプロイするためのインフラストラクチャ オプションで Amazon Cognito 認証を備えた React の Web サイト Amazon DynamoDB と Amazon Aurora 上のデータベース エージェンティック AI: Strands Agents SDK を使ったエージェントと Model Context Protocol （MCP）サーバーの構築。いずれも Amazon Bedrock AgentCore 上にデプロイされます。 デフォルトでは、各ジェネレーターは本来なら自分で追加しなければならないベストプラクティスを備えて出荷されます。 API ハンドラーには、構造化ロギング・AWS X-Ray トレーシング・Amazon CloudWatch メトリクスのために AWS Lambda Powertools が配線済みで組み込まれます。 生成される DynamoDB テーブルは、自動キーローテーション付きのカスタマーマネージド KMS 暗号化、ポイントインタイムリカバリ、削除保護を使用します。 生成される Aurora データベースは IAM 認証を備えた Amazon RDS Proxy の背後に配置され、データベースのスキーマとマイグレーションは、TypeScript 向けには Prisma 、Python 向けには SQLModel と Alembic であらかじめ設定されます。 エージェントと MCP サーバーは AgentCore Observability が設定された状態で提供され、AgentCore Gateway には エージェントのセキュリティ制御のためのポリシー を書き始めるのに必要なものがすべて揃っています。 スタック全体にわたる型安全な接続 これらのコンポーネントを結びつけるのが connection ジェネレーターです。React の Web サイトと tRPC の API があるとします。connection ジェネレーターを実行すると、両者が型安全なクライアントで配線され、API の形状に対する変更が、本番での呼び出し失敗としてではなく、デプロイ前にフロントエンドの型エラーとして現れるようになります。React フロントエンドをエージェントに接続する場合も同様です。 AG-UI プロトコル （リッチでインタラクティブなエージェントの応答をフロントエンドへストリーミングするためのオープンスタンダード）で生成されたエージェントに対しては、応答のストリーミング、ツール呼び出しのレンダリング、状態管理を備えた CopilotKit のチャットインターフェイスを生成します。すべてのジェネレーターがローカル開発をサポートしており、 Nx continuous tasks を使えば、単一のコマンドで相互接続された各部品（Web サイト、その API、エージェント）が、あなたのマシン上でホットリロードしながら一斉に立ち上がるため、何もデプロイせずに変更をテストできます。 実際には、コンポーネントの選択とそれらの接続は AI に任せて駆動しますが、このアプローチにより、お好みならアプリケーション全体を視覚的にスキャフォールディングすることもできます。 このスクリーンショットは Nx Plugin for AWS の Graph Builder のものです。作りたいアプリケーションを図として描き、それをスキャフォールディングするためのコマンドをコピーできます。 あなたのコード、あなたのインフラストラクチャ選択 生成されるコードは主流のフレームワーク上に構築され、あなたのものになります。プラグインへのランタイム依存はなく、生成された内容を編集するのを妨げるものは何もありません。ジェネレーターは出発点であってコミットメントではありません。作りたいものに最も近いものを選び、そこから自分の方向へ進めてください。インフラストラクチャの定義方法も選べます。ジェネレーターは AWS Cloud Development Kit (AWS CDK) のコンストラクトか Terraform のモジュールのいずれかを生成するからです。 Nx マイグレーションで最新に保つ コードを所有することは通常、ライブラリが与えてくれていた唯一のもの、すなわち後から改善をきれいに取り込む手段を犠牲にすることを意味します。v1.0 では、Nx Plugin for AWS は Nx マイグレーション によってそのギャップを狭めます。私たちが新しいバージョンを出荷したら、 公開されたマイグレーションを適用 してワークスペースを更新できます。マイグレーションは、アプリケーションコードだけでなく、ジェネレーターが書いたすべてに届きます。たとえば、非推奨になった Vite の設定オプションを現行の API に置き換えたり、静的 Web サイトのアクセスログを Amazon Simple Storage Service (Amazon S3) バケットから CloudWatch へ移して、監視やアラームを設定できるようにしたりします。エージェントにプラグインのアップグレードを依頼することもできますし、CLI を使ってマイグレーションを駆動することもできます。 # Install the latest version and prepare migrations pnpm nx migrate @aws/nx-plugin@latest # Apply the migrations to your codebase pnpm nx migrate --run-migrations 変更に判断が必要で自動的に適用できない場合は、オプションのエージェンティックマイグレーションが、あなたを放置せずにコーディングエージェントを通じてその変更をガイドします。最新に保つことが、リリースノートやプルリクエストを手作業でレビューする作業ではなく、日常的なコマンドになります。 ステップバイステップの例: CLI を使ったスキャフォールディング ワークスペースを作成した後、最も手早く始めるには AI にジェネレーターを駆動させるのが良いですが、お好みで各ジェネレーターを CLI から手作業で呼び出すこともできます。このセクションでは、CLI コマンドといくつかの小さなコード編集で、複数言語のアプリケーションを構築する方法を順を追って説明します。 AWS 認証情報 に加えて、Python エージェント用に UV をインストールしておく必要があります。 # Create a new workspace with pnpm (yarn, bun and npm are also supported) pnpm create @aws/nx-workspace my-project --no-interactive cd my-project # Create a Python project and add an agent pnpm nx g @aws/nx-plugin:py#project backend --no-interactive pnpm nx g @aws/nx-plugin:py#agent --project backend --auth=cognito --protocol=ag-ui --no-interactive # Add a website with Cognito login pnpm nx g @aws/nx-plugin:ts#website website --no-interactive pnpm nx g @aws/nx-plugin:ts#website#auth --project website --no-interactive # Connect the website to the agent pnpm nx g @aws/nx-plugin:connection --source-project=website --target-project=backend --no-interactive # Create a CDK project to deploy to AWS pnpm nx g @aws/nx-plugin:ts#infra infra --no-interactive Terraform を使いたい場合は、ワークスペースの作成時に --iac=terraform を渡し、 ts#infra の代わりに terraform#project を使います。同じパターンがすべてのジェネレーターに当てはまります。エージェントを tRPC や FastAPI のバックエンドに差し替えれば、connection ジェネレーターは代わりにそのバックエンドへ Web サイトを配線します。 connection ジェネレーターはすでに CopilotKit がエージェントと安全に通信するよう配線済みなので、あとは React コンポーネントをインスタンス化するだけです。たとえばホームページで次のようにします。 // packages/website/src/routes/index.tsx import { createFileRoute } from '@tanstack/react-router'; import { BackendAgentChat } from '../components/backend-agent-chat'; export const Route = createFileRoute('/')({ component: RouteComponent, }); function RouteComponent() { return <BackendAgentChat />; } pnpm dev を実行すると、ローカルの Web サイトとエージェントを起動できます。 AWS 認証情報 が設定されていれば、エージェントは Amazon Bedrock 上の Strands のデフォルトモデルを使用します。ローカル開発サーバーを開いて、エージェントとのチャットを始められます。 準備ができたら、生成された CDK コンストラクトを自分のスタックに組み込みます。 // packages/infra/src/stacks/application-stack.ts import { Stack, StackProps } from 'aws-cdk-lib'; import { Construct } from 'constructs'; import { BackendAgent, UserIdentity, Website } from '@my-project/common-constructs'; export class ApplicationStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); // Create the Cognito resources const identity = new UserIdentity(this, 'Identity'); // Create the agent new BackendAgent(this, 'Agent', { identity, }); // Create the website new Website(this, 'Website'); } } 開発用スタックを AWS にデプロイするには、 pnpm nx deploy-sandbox infra を実行し、デプロイされたユーザープールに Amazon Cognito ユーザーを作成 し、CloudFront ディストリビューションの URL を開いてサインインし、デプロイしたアプリケーションを使用します。 終わったら AWS リソースをクリーンアップするために pnpm nx destroy-sandbox infra を実行し、Amazon Cognito と Amazon S3 のリソースを AWS マネジメントコンソールから削除します（これらはデータ損失を防ぐためにデフォルトでは保持されます）。 フロー全体の詳しいウォークスルー（テキストベースのエージェンティックなゲームの例の構築を含む）は、 Dungeon Adventure チュートリアル をご覧ください。 お客様事例: Bingo Industries のマルチエージェントソリューション オーストラリアのリサイクル・廃棄物管理企業である Bingo Industries は、Nx Plugin for AWS を使ってマルチエージェントアプリケーションを構築し、本番環境に投入しました。彼らが構築したアーキテクチャは次のとおりです。 以下は、彼ら自身の言葉による、何を構築したかの説明です。 Bingo のオペレーション・物流部門は、ビジネスがスムーズに機能することを支える中心的な役割を担っています。この部門には、24 時間常時高い可用性を維持しつつ、効率的にスケールできる必要のある幅広いアプリケーションが含まれます。これらのアプリケーションは、アロケーター、カスタマーサービス担当者、コンタクトセンタースタッフ、オペレーター、アナリストなど、多様なユーザーグループによって利用されており、全員が日々の業務でこれらのツールに頼っています。関わる業務が複雑なため、ユーザーは複数の画面を行き来し、さまざまなフィルター・クエリ・検索を使いこなすことが多く、そのプロセスは時間がかかり煩雑になりがちです。こうした課題を軽減し効率を高めるため、私たちは複数のデータソースやログの情報を活用してユーザーからの問い合わせに応答する、マルチエージェント AI ソリューションを実装することにしました。 マルチエージェント AI ソリューションをゼロから開発するアプローチは数多くありましたが、私たちは時間とリソースの制約に直面していました。この制約を乗り越えるため、私たちは Nx Plugin for AWS を選びました。これはまだ使ったことのない方々に強くおすすめできるツールです。このツールは AWS ベースのアプリケーションのための、加速されたスキャフォールディングの発射台として機能し、AI エージェントを素早く立ち上げるために必要なアプリケーションコードとクラウドインフラストラクチャを、それらを取り囲む API やフロントエンドとともに生成します。 この土台の上に、私たちはユーザーからの問い合わせに回答し、説明を提供できるマルチエージェントのチャットボットを開発しました。ひとつの巨大なエージェントがすべてをこなそうとするのではなく、このソリューションは各質問を適切なスペシャリストエージェントにルーティングします。これにより各エージェントの焦点が絞られ、その回答の信頼性が保たれます。一方で、基盤となる AWS の生成 AI サービスが、全体を結びつける言語理解を提供します。 このアプローチの大きな利点は、AG-UI（リッチでインタラクティブなエージェントの応答をフロントエンドへ直接ストリーミングする）や A2A（エージェント同士が直接呼び出し合えるようにする）といったプロトコルを含む、成熟しつつある新しいスタンダードを、それらが成熟するにつれて素早く採用できたことです。私たちのチームは、セットアップ・認証・配線をゼロから考え出す必要がなく、その土台があらかじめ整った形で手に入り、代わりにビジネスロジックに集中できました。また、すべてを一から考える必要がなく、AWS 推奨のプラクティスと AWS Well-Architected Framework に沿った強力な出発点も得られました。最初の本番ローンチに到達するまで、3 週間弱でした。 たとえば、トランザクションが失敗したとき、チャットボットはよくある障害シナリオの中から考えられる原因の診断を手助けでき、オペレーターは複数のシステムをまたいで手作業で状況を組み立てるよりも速く解決へたどり着けます。さらにユーザーは、プロンプトベースのレポートをリアルタイムに生成でき、分析や情報に基づいた意思決定を促進します。このプロジェクトを通じて協力的に支援してくれた AWS チームに感謝します。 — Alex To（Principal Engineer）、Balaji Ravichandran（Head of Engineering）、Bingo Industries Alex は Nx Plugin for AWS に多大な貢献を還元してくれており、私たちは彼の尽力に大いに感謝しています。生成されたコードは彼らが自由に変更できるものであったため、Bingo Industries はそれらの変更を手元に留めておくこともできましたが、代わりにそれらをアップストリームに貢献してくれ、彼らの改善は v1.0 を形作ったものの一部になっています。 自分たちのジェネレーターで拡張する アップストリームへの貢献はひとつの道にすぎず、多くのチームが必要とする道でもありません。私たちはジェネレーターを SDK として公開しているので、自分たちのニーズに合わせて拡張・適応できます。あなたの組織独自のベストプラクティスのパターンや好みのフレームワークを、私たちが自分たちのものをエンコードしたのとまったく同じようにエンコードできます。これにより、あなたのエンジニアと彼らの AI アシスタントが、チームをまたいで、同じ決定的でレビュー済みの土台から構築できるようになります。 Nx Plugin ジェネレーター を使って自分のプラグインをスキャフォールディングし、自分のジェネレーターを作り、それを MCP サーバー経由で公開してください。 コミュニティに参加する Nx Plugin for AWS は Apache 2.0 ライセンスのもと GitHub で公開されており、私たちは貢献を歓迎します。質問・バグ・アイデアがあれば issue や discussion を開いてください。 最初のプルリクエストに取りかかるには、 ジェネレーター貢献のチュートリアル に従ってください。 すべてのジェネレーターのガイドを含むドキュメントは awslabs.github.io/nx-plugin-for-aws にあります。 また、 CDK.dev Slack の #nx-plugin-for-aws チャンネルで、これを使って構築している他の人たちと一緒に私たちを見つけられます。 私たちがこれを作ったのは、自分たちに必要だったからであり、オープンに作ったのは、これが解決する問題が私たちのチームだけのものではないからです。あなたが AWS 上で構築していて、同じ土台を何度も書いている自分に気づくなら、ジェネレーターをより良くするお手伝いをぜひお願いしたいです。 オープンソースの上に築かれている Nx Plugin for AWS は、多くのオープンソースコミュニティの成果の上に成り立っています。 Nx : Nx Plugin for AWS が構築されている、拡張可能なモノレポのビルドシステム tRPC : TypeScript でのエンドツーエンドの型安全な API FastAPI と Pydantic : API とエージェントのジェネレーターの背後にある Python の Web フレームワークとデータバリデーションライブラリ Smithy : API をモデリングするためのプロトコル非依存のインターフェイス定義言語 React : Web サイトジェネレーターの背後にある UI ライブラリ Vite と Rolldown : TypeScript の Web サイトとバックエンドのビルド・バンドル用 Shadcn と CloudScape : Web サイトジェネレーターが設定できる UX フレームワーク TanStack : Web サイトのルーティングと API 向けの型安全なフック CopilotKit と AG-UI プロトコル : エージェントフロントエンド向けのチャットインターフェイスとストリーミングプロトコル A2A と a2a-sdk : 生成されたエージェントが互いを発見し委譲できるようにする、エージェント間プロトコルと SDK Strands Agents SDK と LangChain : エージェントジェネレーターが使用するエージェントフレームワーク Model Context Protocol : AI アシスタントがジェネレーターを駆動できるようにするスタンダード AWS CDK と Terraform : ジェネレーターが対象とする 2 つの Infrastructure as Code の選択肢 AWS Lambda Powertools : 生成される API ハンドラーの可観測性のデフォルト Prisma 、 ElectroDB 、 SQLModel 、 Alembic 、 PynamoDB : データベースジェネレーターの ORM とエンティティモデリングのレイヤー GritQL : ジェネレーターとマイグレーションによる堅牢なコード編集を支える Biome : ワークスペース全体での TypeScript のリンティングとフォーマット用 uv 、 ty 、 Ruff : Python のパッケージ管理・型チェック・リンティング・フォーマット用 これらをメンテナンスしてくださっているすべての方々に感謝します。

本稿は、2026 年 8 月 19 日に AWS Blog で公開された “Disaster Recovery for VMware Workloads on Amazon EVS” を翻訳したものです。 ビジネスクリティカルなワークロードを VMware 上で稼働させている多くの企業が、たった 1 度の障害が業務を中断し、顧客に影響を与え、収益と信頼を危険にさらし得ることを認識しています。 災害復旧 （DR）はその解決策であり、プライマリサイトがダウンした際に引き継ぐ準備が整ったセカンダリサイトを指します。しかし、従来その構築には多額の初期投資、長いハードウェアのリードタイム、そして本番環境との乖離が避けられない環境が必要であったため、プロジェクトは先送りにされてきました。 Amazon Elastic VMware Service（Amazon EVS） はこれらの障壁を取り除きます。AWS 上で完全な VMware 環境（VMware Cloud Foundation）をオンデマンドでデプロイでき、ハードウェアの購入もリードタイムも環境の乖離も不要です。使用した分だけ支払い、チームは既に慣れ親しんだ VMware のツールとプロセスをそのまま使い続けることができます。AWS が基盤インフラストラクチャを管理し、ワークロードは変更なしで復旧します。 この記事では、Amazon EVS を使用した災害復旧ソリューションの実装における 6 つのフェーズを解説します：戦略と目標の定義、復旧環境の作成、本番環境のミラーリング、ワークロードの保護、必要に応じた復旧、そして切り替えです。その過程で、ビジネスに適した DR 戦略を選択するためのトレードオフについても取り上げます。 図 1: Amazon EVS 上で DR ソリューションを構築するための 6 つのステップ フェーズ 1：災害復旧の目標と戦略の定義 何かを構築する前に、一歩引いて、何を保護するのか、なぜ保護するのかを考える必要があります。 スコープ： どのワークロードがビジネスにとって重要でしょうか？いくつのワークロードに保護が必要で、それらがダウンした場合の影響はどれくらいでしょうか？これが DR 設計全体のスコープを決定します。 復旧目標： ビジネスはどれくらいの時間ダウンを許容できますか？どれくらいのデータ損失を許容できますか？これが目標復旧時間（ RTO ）と目標復旧時点（ RPO ）です。 地理： 本番環境は現在どこで稼働していますか？1 つの 災害 で両サイトがダウンしないよう、復旧環境はどこに配置すべきでしょうか？データ所在地とコンプライアンスの要件が、利用可能な AWS リージョンを絞り込みます。 ツール： DR サイトでワークロードを運用するために、チームはどのようなツールを必要とするでしょうか？使い慣れたツールを拡張することで、新たな学習コストや未検証の障害モードを回避できます。 環境の忠実度： アプリケーションは本番環境の完全なコピー（同じ IP、同じポリシー）で動作する必要がありますか？それとも変更を許容する柔軟性がありますか？これがネットワーキングと構成のアプローチを決定します。 予算： 予算上限はありますか？コミット型キャパシティとオンデマンドの柔軟性、どちらが適していますか？これが、災害発生前にどれだけの待機環境を維持するべきかを決定します。 事業継続： 会社に 事業継続計画（BCP） はありますか？ある場合は、DR 計画をそれに合わせます。BCP が優先順位、許容可能なダウンタイム、復旧順序を設定します。 ランサムウェア対策： 復元前にワークロードがクリーンであることを検証する必要はありますか？イミュータブルストレージと隔離された復旧環境が再感染を防止します。 これらを検討し終えれば、戦略はほぼ自動的に決まります。正しい戦略とは、全体で最も低い RTO を持つものではなく、全てのワークロードがビジネスに必要なレベルの保護を受け、持続可能なコストで、チームが自信を持って実行・テストできるプロセスを備えたものです。以下の表に 4 つの一般的なアプローチを示します。 Cold (オンデマンド) Pilot Light (最小構成) Warm Standby (部分構成) Hot (アクティブ)* 事前デプロイされるもの なし (EVS は災害時にデプロイ) 最小限の EVS 環境 (2 〜 4 ホスト) 縮小クラスター (重要ワークロード向け) フルクラスター (本番同等の容量) コスト $ $$ $$$ $$$$ RTO** 最も高い(8 時間以上) 中‑高(~ 4 時間以上) 中-低(~ 2 時間以上) 低 (~ 15 分以上) RPO 数時間〜数日（最終バックアップ） 数分（最終レプリケーション） 数分（最終レプリケーション） ほぼゼロ（継続的同期） 復旧アクション* EVS デプロイ → 本番ミラーリング → VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え VM 復旧 → 切り替え テストの信頼性 低（災害時まで未テスト） 中（クラスター検証済み） 高（部分的フェイルオーバーテスト） 非常に高（継続的検証） 最適な用途 RTO に余裕のある非重要ワークロード 標準的な本番ワークロード 厳格な SLA を持つ重要アプリケーション ゼロダウンタイムのミッションクリティカル * Hot（アクティブ）：アプリケーション層では実現可能ですが、インフラストラクチャレベルでは vSAN ストレッチクラスタリングが必要です（EVS では未対応）。 ** RTO は災害時に残っている復旧アクションの数に依存し、復旧アクティビティが少なく短いほど RTO は低くなります。 フェーズ 2：DR 環境の作成 復旧環境の作成は 3 つの決定に集約されます：どこにデプロイするか、何をデプロイするか、事前にどれだけ稼働させておくかです。完全なデプロイワークフローについては、 Amazon EVS のドキュメントを参照してください。 どこに： Amazon EVS を、プライマリサイトとは別の AWS リージョン またはアベイラビリティゾーンに、自身の VPC 内にデプロイします。そこから、必要に応じて AWS 内の他のサービスやオンプレミスに接続します。 何を： インフラストラクチャ基盤となる EC2 ベアメタルインスタンス と、ワークロードが期待するソフトウェア定義データセンターを提供する VMware Cloud Foundation のバージョンを選択します。 どれだけ： 上限と下限を把握し、その間のどこに位置するかを決定します。 上限： 上限を算出するには、前のフェーズで作成したワークロードインベントリから、重要なワークロードが消費するリソースを合計し、VCF 管理オーバーヘッドを考慮します。これにより、全てを一度に復旧するために必要なホストの最大数が得られます。 下限： 一方、下限は VCF のバージョン、ストレージタイプ、 フリートフットプリント に応じて Broadcom が定義します。最新の値については VCF のドキュメント を確認してください。現在、VCF 5.2 および 9.x では、Broadcom は本番環境向けに 4 ホストと vSAN ストレージによる 高可用性デプロイメント を推奨しています。VCF 9 では、vSAN で 3 ホスト、または外部ストレージで 2 ホストから始められる シンプルデプロイメント も提供しており、管理プレーンの冗長性よりもコストが重要な環境に適しています。 ティアの選択： これらの上限と下限の間で、現時点でどこに位置するかを決定します。これがコスト対速度の核心的な判断です。事前にデプロイしておくホストが多いほど復旧は速くなりますが、そのアイドル状態のキャパシティを維持するコストも増えます。何もデプロイせず災害発生時に完全に構築する方法（Cold）もあれば、小規模なフットプリントを稼働させておき必要時にスケールアウトする方法（Pilot Light または Warm Standby）もあります。また、DR サイトで日常的に非重要ワークロードを稼働させ、災害発生時にそれらをシャットダウンしてキャパシティを回収するという、一般的な手法もあります。 フェーズ 3：本番環境構成のミラーリング Amazon EVS がデプロイされたら、ワークロードがソースサイトとまったく同じように動作するよう構成します。ネットワーキング、セキュリティ、コンピュート、ストレージ、アイデンティティです。これらが本番環境と一致していれば、ワークロードはクリーンに復旧し、プライマリサイトと同じように動作します。 図 2: 災害復旧の概要 これらの中で、ネットワーキングが最も難しく、最も重要な部分です。フェイルオーバー後に VM が期待するセグメント、ゲートウェイ、ファイアウォールルールに到達できなければ、何も機能しません。このサービスは、復旧サイトで本番ネットワークを再現するための確実な選択肢を提供します。最も一般的な 2 つのモデルを以下に示します： コード駆動型ネットワークレプリケーション このアプローチは、 Terraform 、 Ansible 、 PowerCLI 、 VCF Automation などの Infrastructure as Code（IaC）ツールを使用して、本番ネットワーク構成を復旧サイトにレプリケートします。動作方法は準備する戦略によって異なります。復旧サイトがまだ存在しない場合は、本番ネットワークをコードとしてキャプチャし、サイトのデプロイ時に実行します。既に稼働している場合は、IaC パイプラインが両サイトを自動的に同期させます。いずれの場合も、DR が起動すると、VM は既に配置されているネットワークに接続します。すべてのティアで機能します。 NSX Federation NSX Federation を使用すると、両サイトのネットワーキングを 1 つの中央拠点、NSX グローバルマネージャーから管理できます。セグメント、ファイアウォールポリシー、セキュリティグループを一度定義すれば、両方のロケーションに自動的にプッシュされます。VM が DR サイトで復旧すると、同じ IP、同じファイアウォールルール、同じセキュリティポリシーが適用されます。IP の再割り当て、再構成、乖離は不要です。 これには、両サイトにネットワーキングインフラストラクチャが既にデプロイされ稼働している DR 環境が必要です。初期セットアップが必要であり、一部のポリシーは VM が復旧サイトに登録されて初めて有効になります。それでも、両サイトを常に同期させる必要がある環境にとって、即座のネットワーク準備完了への最もクリーンなパスです。 NSX Federation コード駆動型ネットワークレプリケーション ネットワーク同期 自動、リアルタイム 手動または IaC 駆動、定期的 フェイルオーバー時の IP 再割り当て なし（同じセグメントがストレッチ） あり得る（マッピングに依存） インフラストラクチャオーバーヘッド 高い（両サイトにグローバルマネージャー + Edge） 低い（クロスサイト NSX インフラ不要） 乖離リスク なし（グローバルマネージャーが強制） 自動化されていなければ存在する 最適な用途 Warm Standby、Hot — 頻繁な変更、IP 再割り当てゼロ Cold、Pilot Light、Warm Standby — 安定したネットワーク、IaC の成熟度 フェーズ 4 & 5：ワークロードの保護と復旧 復旧環境が作成され、本番環境と一致するよう構成されたら、次の問題はワークロードデータをどのようにそこに移すか、そしてその時が来たときに仮想マシンをどのように復旧するかです。Amazon EVS で動作するソリューションは複数あります。以下の表は、最も重要な基準に沿って利用可能なソリューションを比較しており、続くセクションでそれぞれを詳しく解説します。 VMware Live Recovery Veeam FSx for NetApp ONTAP AWS Backup カバー範囲 保護 + 復旧 保護 + 復旧 保護 + 復旧 保護のみ レプリケーション層 ハイパーバイザー(vSphere Replication) ハイパーバイザー(I/O フィルタ + プロキシ) ストレージ(SnapMirror、ブロックレベル) スケジュール(S3 へのスナップショット) RPO 5 分 – 24 時間 ~2 秒 (CDP)、 分 (レプリケーション)、時間 (バックアップ) 5 分 数時間〜数日 自動化 高 (復旧計画、スクリプト、再 IP) 高 (切替計画, 即時 VM 復旧) 中-高 (BlueXP でワンクリック) 最小 (スケジュールバックアップ、手動復旧) テスト 非破壊、隔離ネットワーク 非破壊切替テスト FlexClone ゼロスペースコピー 組み込みテスト無し 粒度 VM 単位 VM 単位 ストレージボリューム単位 VM 単位 DR サイト必要？ Yes Yes (CDP/Replication)、No (Backup) Yes No 複雑さ 低 中 低 – 中 最低 ライセンス VM – VCF アドオン VM GB 単位の従量課金 GB 単位の従量課金 最適な用途 統合ソリューションを求める VMware チーム すべてのティアで 1 つのサービスを求めるチーム 既に NetApp ONTAP を使用している組織 ベースライン保護とコンプライアンス層 ハイパーバイザーレベルのレプリケーション これらのソリューションは、ハイパーバイザーレベルで仮想マシンのディスクへの変更をインターセプトし、復旧サイトに転送することでレプリケーションを行います。通常、データの管理と移動のために両サイトにアプライアンス VM をデプロイします。このアプローチは最もタイトな RPO を提供し、復旧環境が既に稼働していることを必要とします。保護と復旧は同じサービス内で処理されます。 図 3: ハイパーバイザーベースのレプリケーション — 仮想アプライアンスを通じた DR オーケストレーションとデータレプリケーション VCF Protection and Recovery これは VCF における統合 DR プラットフォームであり、2 つのワークフローを持ちます：1 つは運用継続に焦点を当て、もう 1 つはサイバー攻撃後の安全な復旧のために設計されています。Disaster Recovery Orchestration：従来型の DR を処理します。各サイトにアプライアンスをデプロイし、vSphere Replication、vSAN Data Protection、またはストレージアレイでレプリケーションを行います。復旧計画が残り、つまり IP の変更、ネットワークマッピング、起動順序を処理します。RPO はレプリケーション方式に依存します：vSphere Replication で約 5 分、vSAN DP では設定したスケジュール、同期アレイではほぼゼロです。DR サイトが既に稼働していれば、RTO は通常わずか数分です。Cyber Recovery はランサムウェアからの復旧のための隔離された場所を提供します。小さなコネクターが重複排除された VM スナップショットをイミュータブルなクラウドファイルシステムに送信します。問題が発生した場合、隔離された復旧環境を起動し、Live Mount を使用してクリーンなスナップショットを即座に起動します。完全な復元は不要であり、DR サイトを 24 時間 365 日稼働させる必要もありません。 パートナーソリューション 複数のパートナー製品が Amazon EVS で動作します。Veeam は最も一般的なものの 1 つであり、単一のサービスで複数のティアにわたる保護と復旧の両方を処理します。保護については 3 つのモードを提供します：Amazon S3 へのスケジュールバックアップ（RPO は数時間）、スタンバイ VM へのほぼ継続的なレプリケーション（RPO は数分）、そしてハイパーバイザーレベルですべての書き込みをキャプチャする Continuous Data Protection（RPO は約 2 秒）。復旧については、フェイルオーバー計画がブートシーケンスと IP 再割り当てルールを自動的に処理し、Instant VM Recovery はフルリストアがバックグラウンドで完了する間にバックアップから直接マシンを起動できます。バックアップモードは事前の DR 環境を必要としません。レプリケーションと CDP モードは DR 環境を必要とします。粒度は VM 単位。複雑さは中程度で、1 つのコンソールですべてを管理しますが、3 つのモードすべてを同時に運用するには計画が必要となります。イミュータブルバックアップがランサムウェアから復旧ポイントを保護します。ライセンスは VM 単位です。 ストレージレベルのレプリケーション ストレージベースのレプリケーションはブロックレベルで動作し、両サイトに同じストレージサブシステムが必要です。Amazon FSx for NetApp ONTAP は 1 つの選択肢であり、EverPure などのパートナーからも同等のソリューションが利用可能です。 図 4: ストレージレベルのレプリケーション — 本番環境と復旧ストレージアレイ間のブロックレベル同期 Amazon FSx for NetApp ONTAP このソリューションは両サイトに FSx for NetApp ONTAP が必要であり、保護と復旧の両方を処理します。保護については、 SnapMirror がブロックレベルでストレージボリュームを 5 分ごとにレプリケートし、VM に対して完全に透過的で、ゲストレベルのオーバーヘッドはありません。完全な EVS 環境は復旧時のみ必要です。 復旧については BlueXP がフェイルオーバーをオーケストレートします：SnapMirror の関係を切断し、レプリカボリュームを書き込み可能にし、DR サイトにデータストアとしてマウントし、vCenter に VM を登録し、定義した順序で電源を入れます。プロセス全体がワンクリックまたは API 駆動です。粒度はボリューム単位で、通常は VM のグループを意味します。複雑さは低〜中程度。価格は GB 単位の従量課金で、大規模ではコスト効率が高いです。既に NetApp ONTAP を使用しており、最小限の運用オーバーヘッドでストレージ効率の高いレプリケーションを求める組織に最適です。 スケジュールバックアップ 最もシンプルかつ安価な保護形態で、耐久性のある外部ストレージに保存される定期的なスナップショットです。RPO はバックアップ頻度に応じて数時間から数日です。事前に DR 環境を稼働させておく必要はありません。 図 5: バックアップとリストア — リモートリポジトリへのスケジュールスナップショットとオンデマンド復旧 AWS Backup このオプションは保護のみを処理します。VM のスケジュールスナップショットを取得し、Amazon S3 に保存します。オプションの Vault Lock によるイミュータビリティにより、ランサムウェアを含め誰も復旧ポイントを削除または変更することができません。復旧は完全に手動です。オペレーターが仮想マシンを復元し、ネットワーキングを構成し、ブート順序を設定し、検証します。オーケストレートされたフェイルオーバーはありません。そのため、復旧時間が重要なワークロードには単独では不向きですが、他のアプローチの下にあるベースライン保護およびコンプライアンス層としては上手く機能します。ポリシー駆動、エージェント不要で、すべての操作が CloudTrail にログとして記録されます。粒度は VM 単位で、複雑さは最小限です。 フェーズ 6: 切り替えとテスト 最終フェーズは 2 つのことに関するものです：ユーザーを復旧サイトに切り替えること、そして実際の災害が発生した際にプロセスがまだ機能することを確認するために、十分な頻度でテストすることです。 切り替えの実行 切り替えとは、シンプルに DNS を更新して、ユーザーとシステムがプライマリサイトへの参照を停止し、復旧サイトへの参照を開始することです。Route 53 のヘルスチェックとフェイルオーバールーティング、加重レコード、またはオーケストレーションツールによってトリガーされる DNS 更新を使用します。重要なレコードの TTL は低く保ちます（60 秒以下）。長い TTL は、レプリケーションツールが提供する値をはるかに超えて実効 RTO を延ばす可能性があります。また、ランブックには外部依存関係への対応も記載して下さい。パートナー連携や、ハードコードされた IP を持つアプリケーション、管理外のサードパーティ DNS ゾーンなどです。 DR 計画のテスト テストされていない DR 計画は単なる推測に過ぎません。実際の復旧が失敗する最も一般的な理由は乖離です。レプリケーションから漏れたアプリケーション、本番環境でのみ変更されたファイアウォールルール、数ヶ月前にリネームされたものを参照しているスクリプトなどです。ほとんどのレプリケーションツールは、隔離ネットワークやサンドボックス環境を通じた非破壊テストをサポートしているため、スケジュールに従って使用します。重要ワークロードは毎月、その他は四半期毎。実際の RTO を目標と比較して追跡し、テストごとの想定外の事象の数を記録します。想定外の事象の傾向こそが、DR 成熟度の真の指標になります。ランブックの実行者をローテーションし、壊れた自動化が宣言時ではなく訓練時に発見されるようにします。 本番環境へのフェイルバック 実際のフェイルオーバー後、プライマリサイトが復旧したら、最終的にワークロードを本番環境に戻す必要があります。保護に使用したのと同じレプリケーションツールが逆方向に機能します：DR 環境を本番環境にレプリケートし、整合性を検証してから、トラフィックを切り戻します。フェイルバックは最初から計画しテストして下さい。テストされていないフェイルバックは、テストされていないフェイルオーバーと同じリスクを伴います。 結論 Amazon EVS 上の災害復旧は、単一のツールや単一の決定ではありません。6 つのフェーズにわたる一連の選択であり、それぞれが RTO、RPO、コスト制約、運用の現実によって形作られます。復旧環境をどこにどのようにデプロイするか、本番環境をどれだけ忠実にミラーリングするか、データをどのように移すか、ワークロードをどのようにオンラインに戻すか、そしてすべてが機能することをどのように証明するかを選択します。良いニュースは、Amazon EVS が小さく始めて成長する柔軟性を提供することです。優先度の低いワークロードには最小限のフットプリントとスケジュールバックアップから始め、ダウンタイムを許容できないワークロードには継続的レプリケーションとフルオーケストレーションを段階的に追加できます。すべてを一度に解決する必要はなく、すべてのキャパシティを一度にコミットする必要もありません。唯一省略できないのはテストです。ドキュメントの中にしか存在しない DR 戦略は負債です。テストを実行し、想定外の事象を追跡し、ギャップを埋め、繰り返します。目標は初日から完璧であることではありません。検証済みの復旧を1回ずつ積み重ねて信頼を築いていくことです。 Amazon EVS を始める AWS 上の VMware ワークロードのための災害復旧を構築する準備はできましたか。Amazon EVS を探索し、今日から復旧戦略の計画を始めましょう。 Amazon EVS のオファリングを Amazon EVS 製品ページ で確認してください。 技術的な詳細を Amazon EVS ドキュメント で掘り下げましょう。 最初の EVS 環境を Amazon EVS コンソール からデプロイしましょう。 この投稿の翻訳は Solutions Architect の有岡が担当いたしました。原文記事は こちら です。 Akshay Joshi AWS の Worldwide Public Sector チームのシニアソリューションアーキテクトであり、政府および教育機関の顧客が VMware 環境をモダナイズするのを支援しています。IT インフラストラクチャ（サーバー、ネットワーキング、ストレージ）で 15 年以上の経験があり、VMware を専門とし、そのキャリアの最後の 5 年間を AWS で過ごしてきました。公共セクターチームと協力し、既存の VMware 投資をスケーラブルでセキュアな AWS アーキテクチャに引き継ぐ支援を行っています。 Erick Meneses AWS の移行とモダナイゼーションに特化したスペシャリストソリューションアーキテクトです。大規模な変革プログラムのリードで 20 年以上の経験を持ち、EMEA 全域のエンタープライズ顧客がクラウドジャーニーを進め、成功した成果の達成を支援しています。 Ben Lipman 仮想化、ストレージ、ネットワークを管理する IT インフラストラクチャエンジニアリングで 25 年のバックグラウンドを持ち、あらゆる規模のエンタープライズを担当してきました。AWS で過去 10 年間を過ごし、現在はワールドワイド VMware テクニカルリーダーを務めています。