本記事は「 A free year of Kiro, now for students around the world 」を翻訳したものです。 3 月に Kiro Students ティアを立ち上げたとき、私たちは 11 の大学から始めました。需要はほぼ即座にそのリストを追い越しました。まだ私たちが届いていない学校の学生たちが、同じことを繰り返し尋ねてきました。「私の学校は次はいつ？」 新年度の始まりにあたって、私たちは、より多くの学生が本格的なツールを手にしてキャンパスへ戻ることを望んでいます。そこで Kiro Students プログラムを、16 か国にわたる 新たな 121 の大学 へと拡大します。これら 16 か国の対象となる学生は、いまや同じオファーを受けられます。 Kiro を 1 年間無料で利用でき、毎月 1,000 クレジット、そしてプレミアムモデルや Kiro Web といった有料機能にもフルアクセスできます 。クレジットカードは不要。トライアルのタイマーもありません。ただ作るだけです。 サインアップの方法 始めるのに必要なのは、わずか数ステップです。 サインアップまたはログインします。大学に紐づくメールアドレスを使い、いずれかのサインインオプションで Kiro アカウントを作成してください。すでに Kiro アカウントをお持ちの場合は、先へ進む前に、大学に紐づくメールアドレスがそのアカウントに関連付けられていることを確認してください。 学生ステータスを確認します。サインイン後、対象となる大学の学生であれば、アカウントページに「You are eligible for Kiro Students」というバナーが表示されます。verify ボタンをクリックし、SheerID を通じた簡単な確認を完了してください。ほんの 1 分で済みます。 作り始めます。確認が完了すると、1 年間にわたって毎月 1,000 クレジットへのアクセスを得られます。 これだけです。長い申請も、待機期間もありません。 いくつか覚えておいていただきたい点があります。 確認は一度きり。 学生ステータスの確認は一度しか行えないため、情報が正しいことを確認してください。 超過分はなし。 その月の 1,000 クレジットの上限に達した場合は、次のサイクルまで待つ必要があります。クレジットは翌月に繰り越されません。 1 年が終わった後。 1 年間のアクセスが期限切れになると、アカウントは自動的に Kiro の無料プランへダウングレードされます。 学生は Kiro でどう作るか Kiro は 4 つの利用面（サーフェス）で使えます。IDE、CLI、Kiro Web、そして Kiro Crew です。学期を通じて それぞれを実際にどう使うか はこちらをご覧ください。 IDE では — スペックで計画し、手を動かして作る。 エディタの近くにいたい学生向けです。作りたいものを説明すると、Kiro はそれを要件・設計・順序立てられたタスクリストに変えます。気の重いプロジェクトが、1 タスクずつ進めていくチェックリストになります。1 週間を楽にしてくれるもの（全員のカレンダーから空き時間を見つけるスケジューラー、講義ノートから作るフラッシュカードアプリ）や、あなたがいつも話しているスタートアップのアイデアを作りましょう。いくつも同時に進めている？ Agent Focus に切り替えれば、並列タスクを立ち上げ、クラウドセッションとして実行してノートPCを占有させず、それぞれを一か所からレビューできます。 CLI では — ターミナルに住む学生向け。 同じエージェンティックな力を、スクリプティングと自動化のために作られた形でシェルの中に。1 週間を食いつぶす雑務に向けましょう。講義の録音を整理する、プロジェクトを毎晩 GitHub にバックアップする、シラバスをカレンダーの予定に変換する、コミットのたびにテストを実行する。学校のラボマシンやリモートクラスターでも SSH 越しに動き、長いジョブはノートPCを閉じた後も動き続けるクラウドセッションに渡せます。 Kiro Web では — どのブラウザからでも、インストール不要で作る。 すべての学生が、目の前のマシンにソフトウェアをインストールできるわけではありません。Kiro Web はブラウザの中で動きます。ロックダウンされたラボのPC、借り物のノートPC、Chromebook。アイデアから動くものへ到達する最速の道です。クラブのランディングページ、ハッカソンのゲーム、共同創業者に見せるための当日プロトタイプ。授業の合間に作業を始め、走らせておいて、後で自分のマシンで引き継げます。 Kiro Crew では — オープンソースで、あなた自身が形づくれる。 どう動くかを読み、あなたのワークフローに合わせて曲げましょう。自分のツールを組み込み、自分のエージェントを定義し、それらをバックグラウンドで走らせます。あるエージェントは毎朝、未返信メールの「やり残し（loose threads）」リマインダーを送り、別のエージェントは最初の授業の前にプロジェクトの最新の変更を取り込みます。ハッカソン中は、あなたがデモに集中している間に、複数の機能にクルーを放てます。戻ってくる頃には、作業はすでに動き出しています。 どの利用面を使っても、パターンは同じです。作りたいものを説明し、Kiro がそれを分解し、あなたが主導権を握り続けます。それこそが卒業後も役立つスキルです。単にコードを出荷することではなく、難しい問題を分解し、適切なツールを選び、作業を指揮することです。 なぜこれをするのか 私たちは、学生こそが、次に来るものをすでに作っている人々だと信じています。プロフェッショナルグレードのツールに慣れる最良のタイミングは、探求し、壊し、プレッシャーなく学ぶ自由がまだあるうちです。AI エージェントは標準的なエンジニアリングツールキットの一部になりつつあり、私たちは、どこで学んでいるかにかかわらず、すべての学生に本物のアクセスを持ってほしいと考えています。 グローバルに広げることこそが要点です。才能はひとつの国に集まるわけではなく、機会もそうであるべきではありません。だからこそ私たちは 11 校から 16 か国 121 の新しい大学へと拡大し、そしてここで止めるつもりはありません。 キャンパスで、どこでも 私たちは Kiro をキャンパスへ直接届けており、いまやより多くの大陸へと広がっています。世界各地の一部の学校で開催するキャンパス訪問・ワークショップ・ハッカソンの最新情報を受け取るには、 Kiro Student Discord コミュニティに参加 してください。日程や詳細は、まずそこで共有します。 あなたの学校で Kiro と ハッカソンを共同開催 しませんか？ 場所を問わず、ぜひ皆さんと組みたいと思っています。 始めよう kiro.dev/students にアクセスして、詳細を確認しサインアップしてください。作っているものを #KiroStudents でシェアしてください。私たちは X の @kirodotdev 、 LinkedIn 、 Instagram 、そして Bluesky の @kiro.dev にいます。 皆さんが何を作るのか、楽しみにしています。

本記事は「 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 のパッケージ管理・型チェック・リンティング・フォーマット用 これらをメンテナンスしてくださっているすべての方々に感謝します。

G-gen の本間です。当記事では、 Migrate to Virtual Machines を使って、Amazon Web Services（AWS）から Google Cloud へ仮想マシンを移行する方法を解説します。 はじめに Migrate to Virtual Machines とは サポートされる環境 移行手順の概要 前提事項 AWS 側の設定 Google Cloud 側の設定 注意点 AWS 側の設定 Google Cloud 側の設定 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 はじめに Migrate to Virtual Machines とは Migrate to Virtual Machines は、オンプレミス環境や他のクラウド環境から Google Cloud の Compute Engine へ仮想マシンを移行するための Google Cloud サービスです。 このサービスでは、移行元の仮想マシンを稼働させたまま、Google Cloud 上にデータをレプリケーションできるため、移行に伴うダウンタイムを最小限に抑えられます。 参考 : Migrate to Virtual Machines のドキュメント サポートされる環境 Migrate to Virtual Machines では VMware、Amazon Web Services（以下、AWS）、Microsoft Azure が移行元としてサポートされています。ただし、それぞれの環境ごとにサポートされている OS が決まっているため、事前に確認する必要があります。 また、AWS からの移行においては、対象となる EC2 インスタンスの OS やディスクのタイプが、Migrate to Virtual Machines でサポートされているかについても事前に確認する必要があります。 なお、AWS 側からのデータ転送には、AWS のアウトバウンドデータ転送料金が発生します。移行対象のデータ量が多い場合は、コストに注意してください。 参考 : サポートされているオペレーティング システム 移行手順の概要 前提事項 当記事の解説における前提として、AWS 側では、VPC 内のパブリックサブネットに Windows Server 2025 の EC2 インスタンスを構築済みであり、インターネットゲートウェイ（IGW）経由でのルーティングおよびセキュリティグループの設定によりインターネットへのアウトバウンド通信の準備が完了しているものとします。 また、Google Cloud 側ではインスタンスを配置する対象リージョンの VPC ネットワークとサブネットの構築が完了しているものとします。移行先 VM の構築自体に特段通信要件はありませんが、移行工程でテストクローンを実施する場合、移行元 VM と移行先 VM が同時に起動する状態となります。予期しないトラブルを防止するため、移行先 VM と、移行元 VM および周辺システムが通信できないネットワーク設定とすることが推奨されます。 AWS 側の設定 AWS 側の手順では IAM ポリシーとユーザーの作成を行います。この際、アクセスキーとシークレットアクセスキーも発行します。 また、VPC や EC2 インスタンスが、前述の前提事項や後述の注意点に準拠していることを確認してください。 Google Cloud 側の設定 Google Cloud 側の大まかな手順は以下のとおりです。 インスタンスのレプリケーション ターゲットインスタンスの定義 テストクローンの作成と動作確認 カットオーバー レプリケーションの最終処理 最初に、AWS 側の VM のディスクデータを Google Cloud 側に同期します。この工程をレプリケーションと呼びます。この工程では Google Cloud 側に VM は起動せず、あくまでディスクのデータのみをコピーします。データは Migrate to Virtual Machines のマネージドなストレージに保管されます。 続いて、コピーしたデータを元にしてどのようなスペックで Google Cloud 側の VM として起動するかを定義し、その設定に基づいて実際に VM を起動します。テスト環境用に VM を起動することをテストクローンの作成、本番環境用に VM を起動することをカットオーバーといいます。 注意点 Google Cloud に移行する VM は、ブートパーティションに 128 MB 以上の空き容量が必要です。 レプリケーションは初回実施時から100日間、アクティブ状態が維持されます。100日経過後、EXPIRED 状態に移行し、レプリケーションサイクルが停止します。再びアクティブ状態にするには初回実施時から130日経過する前に存続期間を延長する必要があります。期間の延長は1回のみ可能で、追加で100日間アクティブ状態にできます。よって、VM の移行はこの期間内に完了させる必要があります。 Migrate to Virtual Machines では、レプリケーションのプロセスを通して OS 適応 というプロセスが自動的に実行されます。OS 適応は VM を Google Cloud 上で適切に動作させるために、パッケージのインストールやネットワーク設定等を行うプロセスです。このプロセスは Linux と Windows の両方で行われ、Linux VM では /root で最大640 MiB、/boot で最大128 MiB、/var で最大64 MiB、/tmp で最大32 MiB の空き容量が必要です。Windows VM では C ドライブに最大1.25 GiB の空き容量が必要です。 カットオーバー実行時は移行元の VM が停止されるため、注意してください。 参考 : 個々の VM を移行する - 前提条件 参考 : 移行中の VM のライフサイクル 参考 : Google Cloud で実行するように VM インスタンスを適応させる 参考 : VM の移行プロセス - カットオーバーフェーズ AWS 側の設定 当記事では、AWS 側の設定手順の詳細な解説は省略します。詳細は、公式ドキュメントを参照してください。 まずは AWS マネジメントコンソールにログインし、Migrate to Virtual Machines が必要とする権限を定義した IAM ポリシーを作成します。 参考 : AWS ソースを作成する - AWS IAM ポリシーを作成する 次に、作成した IAM ポリシーをアタッチした IAM ユーザーを作成します。この IAM ユーザーは、AWS リソースへのプログラムによるアクセス（API 経由でのアクセス）に使用されます。 IAM ユーザー作成後に IAM ユーザーの「セキュリティ認証情報」から、アクセスキーおよびシークレットアクセスキーを発行します。これらのキーは、Google Cloud 側の設定で使用するため、安全な場所に記録しておきます。 参考 : AWS ソースを作成する - IAM ユーザーを作成する Google Cloud 側の設定 インスタンスのレプリケーション 以下は、2026年8月現在の Google Cloud コンソール画面を前提とした手順です。 Google Cloud コンソールの上部検索ボックスに「Migrate to Virtual Machines」と入力して表示されるサジェストから「Migrate to Virtual Machines」画面へ進みます。表示された画面上部の「ソース」タブを選択し、「ソースを追加」から「AWS ソースを追加します」を選択します。 AWS ソースの作成画面から事前に発行した AWS IAM ユーザーのアクセスキーとシークレットアクセスキー、および対象の AWS リージョンを入力して、ソース環境を登録します。 このとき、AWS セキュリティグループやタグを使って対象のインスタンスをフィルタリングできます。 ソースを追加すると、指定した AWS リージョン内に存在する EC2 インスタンスのリストが自動的に取得されます。 このリストから移行対象とするインスタンスのチェックボックスにチェックを入れ、「移行を追加」プルダウンから「VM migration」を実行します。すると移行確認画面が表示されるため、「確認」を押下します。 完了後、画面上部の「VM の移行」タブを押下すると、先ほど選択したインスタンスが追加され、レプリケーションのステータスが準備完了となっていることが確認できます。続いて、対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを開始」を実行します。この処理により、AWS 上の仮想マシンデータが、Google Cloud 上に継続的にコピーされます。 ターゲットインスタンスの定義 レプリケーションが進行している間に、先行して Google Cloud 上で稼働させるインスタンスのスペック（マシンタイプ、ネットワーク設定、ディスクタイプなど）を定義します。 先ほどの画面から再び対象インスタンスのチェックボックスにチェックを入れ、「ターゲットの詳細を編集」を押下し、表示された編集画面を上から順に設定します。 なお、最下部の「Replication policy」設定でレプリケーション間隔を設定できます。デフォルトは2時間です。 テストクローンの作成と動作確認 しばらく待機し、先ほどの「VM の移行」画面から対象インスタンスのレプリケーションステータスが「有効」となっていることを確認します。この状態となっていれば初回レプリケーションは完了です。 以降は「Replication policy」で設定したレプリケーション間隔ごとに増分レプリケーションが実施されます。 参考 : VM の移行プロセス - レプリケーションフェーズ 次にテストクローンを実施します。テストクローン機能を使用すると、移行した VM のクローンを Compute Engine インスタンスとしてデプロイできます。テストクローンは省略可能ですが、本番環境へ移行する前に実施し、テスト環境で動作確認をすることが推奨されます。 参考 : VM の移行プロセス - テストクローンフェーズ 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「テストクローン」を実行します。するとテストクローン作成確認画面が表示されるため、「確認」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「クローンが完了しました」となっていることを確認します。 この状態になればテストクローン完了です。Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、インスタンスが起動していることを確認します。 ここで、必要に応じてインスタンスにログインし OS 設定を確認したり、コンソール画面から Compute Engine インスタンスの設定値を確認したりして、想定どおりにデプロイされていることを確認します。 カットオーバー テストクローンによる事前確認完了後、カットオーバーを実施します。 カットオーバーを実行すると、最後のレプリケーションが実施され、VM が Compute Engine インスタンスにデプロイされます。この際、移行元の VM は停止されるため、注意してください。 また、Compute Engine は IP アドレスやインスタンス名が同じ VM を複数作成できません。そのため、テストクローン実施時に作成したインスタンスが存在している場合は、インスタンスを削除するか、「ターゲットの詳細を編集」から別のインスタンス名を設定してください。当記事の手順では、テストインスタンスを削除してから実行します。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「カットオーバーとテストクローン」プルダウンから「カットオーバー」を実行します。するとカットオーバー確認画面が表示されるため、「確認」を押下します。 カットオーバーの状況については、先ほどの画面から対象インスタンス名を押下し、「テストクローン/カットオーバーの履歴」タブから確認できます。 しばらく待機し、「VM の移行」画面から対象インスタンスの「テストクローン/カットオーバーのステータス」が「カットオーバーが完了しました」となっていることを確認します。 この状態になればカットオーバー完了です。テストクローン実施時と同様に、Google Cloud コンソールの上部検索ボックスに「Compute Engine」と入力して表示されるサジェストから「Compute Engine」画面へ進み、想定どおりのインスタンスが起動していることを確認します。 レプリケーションの最終処理 カットオーバー完了後、レプリケーションの最終処理を実施します。カットオーバー完了時点で移行は完了していますが、レプリケーションの最終処理を実行するまではレプリケーションデータが保持された状態です。 「VM の移行」画面から再び対象インスタンスのチェックボックスにチェックを入れ、「移行」プルダウンから「レプリケーションを最終処理」を押下します。 しばらく待機し、「VM の移行」画面から対象インスタンスの「レプリケーションのステータス」が「最終処理済み」となっていることを確認します。 以上で AWS から Google Cloud への VM 移行作業は完了です。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。