AWS、自律型AIエージェントだけで開発したローカルエミュレーターを公開

AWSは2026年11月11日、438種類のAWS APIモデルを基に構築され、200を超えるサービスをカバーする、一般提供中のローカルエミュレーターAWS Emulatorを公開しました。自律型AIエージェントがコードの作成とテストを行っており、開発者やコーディングエージェントはAWSアカウントを使わずに、自分のマシン上でAWS APIを試せます。

AWS CLI、AWS SDK、コーディングエージェントは、クラウドで利用するものと同じAPIを使い、ローカルのHTTPSエンドポイント経由で接続する。環境変数でこれらのツールの接続先をユーザーのマシンに切り替えられるため、アプリケーションコードを変更する必要はない。AWSのローンチ記事では、Linux向けのRPMおよびDebianパッケージ、macOSとWindows向けのDocker、Rustのテスト用の組み込みモードについて詳しく説明している。追加のサービス料金はかからないが、クラウドにデプロイしたAWSリソースの料金は引き続き発生する。

コーディングエージェントにとって、このエミュレーターはAWSインフラを「書き込み、実行、読み取り」のサイクルに組み込むものだ。エージェントはリソースを作成して結果を確認し、AWSリージョンへのデプロイを待たずにコードを修正できる。AWSのドキュメントでは、開発サーバーや継続的インテグレーションもエミュレーターの利用環境として挙げられており、リクエストはAWSではなくエミュレートされたリソースに送られる。

3つのエージェントチームがコードの開発と保守を担う

AWSのシニア・プリンシパル・エンジニアであるMatthew Goldbergは、エンジニアリングに関する記事で、自身のチームはエミュレーターのコードを書いておらず、レビューもしていないと述べた。人間が担ったのは、仕様、テストの仕組み、マージゲート、リリースパイプラインなど、開発を支える仕組みの構築だった。プロジェクトは、Kiroコーディングエージェントが、テストを書き、それを実際のAWSで検証し、テストに合格するインメモリ実装を作るよう指示されてから、約15分で実用に足るAmazon SQSエミュレーターを生成したことをきっかけに始まった。その後Goldbergは、週末をかけてKiroにプロトタイプを拡張させた。堅牢な製品に仕上げるには、周囲のガードレールが必要だった。

現在は、担当範囲を定めた3つのエージェントチームで作業を分担している。テスト作成チームは公開APIモデルを基にシナリオを考案し、実際のAWSで検証する。問題発見チームはテストを再実行し、根本原因が共通している可能性のある失敗をまとめる一方、修正エージェントは問題を1件ずつ担当する。Goldbergによると、忠実度テストは数万件に上り、数百のエージェントが並行して作業するなか、毎日数千件の問題が修正されている。

修正案はすべて、マージ前にコンパイルされ、コーディング規約、セキュリティ、忠実度に関する自動チェックに合格しなければならない。独立したセキュリティエージェントが開発中に敵対的な視点から変更をレビューし、リリースパイプラインでも再度レビューする。Goldberg氏は「このマージゲートがなければ、エージェントが構築しているものを信頼できない」と記している。

変更はAWS CodeCommitとCodePipelineを経てから、GitHubで公開される。公開リポジトリでは、コミット履歴と、解決済みおよび未解決の忠実度に関する問題をそれぞれまとめたフォルダーを確認できる。AWSはコードをパブリックドメインの献辞であるCC0の下で公開したが、ベンダーコードはApache 2.0の下で公開している。リポジトリではプルリクエストを受け付けていないものの、ユーザーはGitHub Issuesを通じてバグや忠実度の不足を報告できる。

忠実度スコアがエミュレーターの限界を示す

忠実度テストとは、実際のAWSと照合して検証する短いワークフローだ。テストに合格するには、エミュレーターは各呼び出しへの応答について、ステータスコード、本文、正確なエラーコードとメッセージに加え、ワークフローが作成するリソースとデータも一致させなければならない。未実装の操作はHTTP 501（Not Implemented）を返すため、失敗はすぐに明らかになる。各リリースではサービスごとの合格件数が示されるが、テストを追加すると、エミュレーターが改善していてもスコアが下がる場合があるとAWSは注意を促している。

公開評価テストスイートのすべてのテストは、少なくとも2つのサンドボックス化されたAWSアカウントで検証されている。また、リポジトリでは、テストのない動作は検証済みではないことが明示されている。

こうしたスコアがあるからといって、このエミュレーターをセキュリティテスト環境として使えるわけではない。AWS Identity and Access Management（IAM）やリソースベースのポリシーをAWSと同じ方法で評価しないため、AWSが拒否するリクエストがローカルでは成功する可能性がある。用途として想定されているのは構築とテストであり、本番ワークロードやアプリケーションのセキュリティテストは対象外だ。各インスタンスは1つのアカウントとリージョンでの使用を想定しており、リソースはメモリ内に保持され、停止すると削除される。

エンジニアの仕事は仕様とテストへと移る

リリース告知でSwaminathan Sivasubramanian氏は、エンジニアの役割について、何を構築すべきかを決め、仕様書やテスト、マージゲートを作成して正しさを判断することだと説明した。その間、エージェントがコードを書き、チェックを行う。

初期のAmazon分散ロックサービスであるAlfとの比較は、具体例を示している。元のレプリケーションエンジンの構築には約4か月かかった。Sivasubramanianによると、Kiroで再構築した際、エージェントには結果を確認する手段がなかったため、最初は監督下で4晩を要した。仕様とテスト環境を用意した後は、再構築に約2時間かかった。

AWS Emulatorは、この教訓を実際に提供される製品へと結びつけている。エージェントが実装を生成して修正する一方、エンジニアは許容できる動作を定め、その遵守を自動化する。実用上の適用範囲は、拡大を続ける公開テストスイートと、なお残る忠実度の不足に左右される。セキュリティと本番環境での検証には、依然として実際のAWSが必要だ。