G-gen の本間です。Google Cloud のネットワーク機能である ハイブリッドサブネット について解説します。ハイブリッドサブネット機能を使うと、オンプレミスネットワークと VPC ネットワーク間で、同じ IP アドレス範囲を共有できます。 概要 ハイブリッドサブネットとは 料金 仕様 ルーティング ルートのアドバタイズ プロキシ ARP の使用 ハイブリッドサブネットを使用した VM 移行 制約事項と注意点 概要 IP アドレスの管理 使用できない環境・サービス オンプレミスネットワーク ルーティング 使用できない通信 概要 ハイブリッドサブネットとは ハイブリッドサブネット とは、Google Cloud の Virtual Private Cloud ネットワーク（以下、VPC ネットワーク）とオンプレミスネットワーク間で、同じ IP アドレス範囲を共有できる機能です。 通常、VPC ネットワークとオンプレミスネットワークを Cloud VPN（IPsec-VPN）や Cloud Interconnect（専用線）で接続する場合、IP アドレス範囲を重複させることはできません。しかし、ハイブリッドサブネットを使用することで、両環境にまたがる単一の論理的なサブネットを構成できます。 この機能は主に、オンプレミスのサーバーを Google Cloud へ移行する際、IP アドレスを変更せずに段階的に移行する目的で使用されます。 一般的に、クラウドへサーバーを移行する際には、サーバーの IP アドレスの変更を視野に入れるケースがあります。この場合、DNS レコードの更新、ファイアウォールルールの修正、依存するアプリケーションの設定変更なども付随して必要となります。 しかし、ハイブリッドサブネットを使用することで、オンプレミス環境と Google Cloud 環境を接続した状態でも同じ IP アドレス範囲をもつサブネットを Google Cloud に用意できるため、IP アドレスの変更が不要です。周辺システムの設定変更を最小限に抑え、Google Cloud 移行時のダウンタイムやリスクを低減できます。 参考 : About migrating to Google Cloud with Hybrid Subnets 料金 ハイブリッドサブネット機能自体の使用には、追加料金は発生しません。 VPC ネットワークのリソースや、送受信されるトラフィックに対する標準的な Google Cloud の料金のみが適用されます。 参考 : Virtual Private Cloud の料金 仕様 ルーティング ハイブリッドサブネットが有効になっているサブネットでは、パケットの転送動作が通常のサブネットとは異なります。 通常のサブネットでは、パケットの宛先がローカルまたはピアリングのサブネットルートと一致する場合、そのリソースへパケットを転送します。また、パケットの宛先が、実行中の Compute Engine VM（以下、VM）や内部転送ルールに関連付けられていなければ、パケットは破棄されます。一方、ハイブリッドサブネットでは以下のように処理されます。 パケットの宛先が一致する場合 パケットの宛先が、サブネット内で実行中の VM のネットワークインターフェースや内部転送ルールと一致する場合、通常のサブネット同様にそのリソースへパケットを配信します。 パケットの宛先が一致しない場合 パケットの宛先が、サブネット内の実行中の VM のネットワークインターフェースや内部転送ルールに一致しない場合でも、パケットは破棄されません。代わりに、ローカルまたはピアリングの静的ルート・動的ルートのネクストホップにパケットが転送されます。この動作により、クラウド上に存在しない宛先へのトラフィックを、オンプレミスネットワークへ正しく転送するための経路が確保されます。 参考 : About migrating to Google Cloud with Hybrid Subnets - Routing in the VPC network ルートのアドバタイズ Google Cloud へ移行されたサーバーへトラフィックを正しく引き込むため、Cloud Router からオンプレミスのルーターに対し、移行された個別の IP アドレスの /32 ルートをアドバタイズする必要があります。このルートは、Cloud Router にカスタムルートとして手動で設定する必要があります。 Border Gateway Protocol（以下、BGP）の最長一致の原則（Longest Prefix Match）により、オンプレミス側のより広い範囲のルート（ /24 など）よりも、Google Cloud 側からアドバタイズされた /32 ルートが優先されます。これにより、通信が正しく Google Cloud 上のサーバーに到達します。 プロキシ ARP の使用 サーバーが Google Cloud に移行された後も、オンプレミス側の他のクライアントは、対象サーバーが同じサブネット内にいると認識して ARP リクエストを送信します。このとき、オンプレミス側のルーターがプロキシ ARP で代理応答し、トラフィックを Cloud Router 経由で Google Cloud へ転送します。 このように、ハイブリッドサブネットを使用するには、オンプレミス側のネットワーク機器（ルーターなど）でプロキシ ARP を有効にする必要があります。 ハイブリッドサブネットを使用した VM 移行 ハイブリッドサブネットを使用して、オンプレミスから Google Cloud へサーバーの移行を行う際の、手順の概要は以下のとおりです。 オンプレミスのルーターが BGP をサポートし、プロキシ ARP を有効にできることを確認する Google Cloud 側で、オンプレミスと同じ IP アドレス範囲を持つ VPC サブネットを作成し、ハイブリッドサブネットルーティングを有効にする Cloud VPN や Cloud Interconnect を構成し、Cloud Router でオンプレミス環境との BGP セッションを確立する Migrate to Virtual Machines などの移行ツールを使用して、サーバーを Google Cloud に移行する 移行したサーバーの IP アドレス（ /32 ）を Cloud Router のカスタムアドバタイズルートに追加する VM の動作確認・試験を行う すべての移行が完了したら、ハイブリッドサブネットルーティングを無効にし、通常の VPC ルーティングに戻す ハイブリッドサブネット機能の有効化自体は簡単で、手順2のサブネット作成時に合わせて設定できます。またサブネットの新規作成時だけでなく、既存のサブネットに対しても、ハイブリッドサブネットを有効化できます。詳細な手順は以下のドキュメントを参照してください。 参考 : Prepare for Hybrid Subnets connectivity 参考 : Migrate workloads to Google Cloud with Hybrid Subnets 参考 : Disable hybrid subnet routing 制約事項と注意点 概要 当記事では、ハイブリッドサブネットの主要な制限を記載します。制限の詳細と、最新情報は公式ドキュメントを参照してください。 参考 : About migrating to Google Cloud with Hybrid Subnets - Limitations IP アドレスの管理 ハイブリッドサブネットには、IP アドレスの重複を自動的に防ぐ仕組みがありません。 そのため、オンプレミス環境と Google Cloud 環境で同じ IP アドレスが同時に使用されないよう、管理者が手動で厳密に IP アドレスを管理する必要があります。具体的には、Google Cloud 側への移行が完了したオンプレミスサーバーは速やかに停止するといった考慮が求められます。 使用できない環境・サービス ハイブリッドサブネットは、Google Cloud VMware Engine をサポートしていません。よってサーバーの移行先が Google Cloud VMware Engine の場合は、前述の移行手順を用いることはできません。 また Microsoft Azure や Amazon Web Services（AWS）とのプライベート接続で、ハイブリッドサブネットを用いることはできません。 オンプレミスネットワーク ハイブリッドサブネットで接続するオンプレミス側の対向機器となるルーターでは、プロキシ ARP の有効化と /32 ルートのアドバタイズの許容が求められます。 事前に使用する機器の仕様や設定を確認してください。 ルーティング ネットワークタグによる静的ルーティングの使用不可 Google Cloud の VPC ネットワークでは本来、Compute Engine VM のネットワークタグ機能を用いて静的ルートを設定可能です。しかし、ハイブリッドサブネットを使用している場合、ネットワークタグを使った静的ルーティングは使用できません。ハイブリッドサブネットでネットワークタグによる静的ルーティングを行っている場合、トラフィックが急増した際にパケットロスを引き起こす原因となります。 リージョンまたぎの通信は不可 ハイブリッドサブネット内のルーティングで宛先に通信を送る際、経路のネクストホップは、サブネットと同じリージョン内に存在する必要があります。異なるリージョンをネクストホップに指定した場合、パケットが破棄され、通信ができません。本来、Google Cloud の VPC ネットワークでは、本来であれば「東京リージョンのサブネットから、大阪リージョンの VPN ゲートウェイへ経路を向ける」といったルーティングも可能です。しかし、ハイブリッドサブネットでは仕様上、そのような設定はできないため注意してください。 使用できない通信 ハイブリッドサブネット環境では、IPv6 トラフィック、ブロードキャストトラフィック、マルチキャストトラフィックはサポートされていません。 また、Network Connectivity Center、ハイブリッド接続 NEG、ハイブリッド NAT とハイブリッドサブネットを併用することはできません。 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

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