11月11日、About Amazonが「How we built the agents that built AWS Emulator」と題した記事を公開した。AWSサービスのローカルエミュレータ「AWS Emulator」を、人間のコードレビューを一切介在させず自律型AIエージェントだけで構築した取り組みを詳細に紹介したものだ。
AIがコードを「補助する」段階はすでに過去になりつつある。今回の事例が踏み込んでいるのは、バグの発見から修正・マージ・リリースまでのサイクル全体をエージェントが自律的に回すという点だ。人間の役割はパイプラインの設計と境界線の定義に限られており、コードそのものには一切触れない。
人間がコードを一行も書いていない
AWS Emulatorは、ローカル環境でAWSサービスを再現するエミュレータだ。ソースコードの全行が自律型AIエージェントによって書かれており、開発チームのメンバーはコードの記述もレビューも行っていない。ソースコードはGitHub上でCC0ライセンスとして公開されており、現在も継続的に更新されている。
なお、AWSのローカルエミュレータとしてはLocalStackが広く知られているが、AWS EmulatorはLocalStackとは異なり、コードベース全体がAIによって生成・維持されている点と、CC0（パブリックドメイン相当）という制限なしのライセンスでの公開が大きく異なる。
ことの発端は週末の実験だった。今年初め、Anthropicの研究者がAIエージェントによるCコンパイラの自律構築を実証した。これを受け、担当エンジニアは「仕様書と参照実装さえあれば、エージェントは自律的に動作するはずだ」という仮説を立てた。AWSにはその両方がある。AWS API Modelsが仕様書、実際のAWSクラウドが参照実装だ。
使用したのはAWSのAIコーディングエージェント「Kiro」だ。KiroはAWSが2025年にリリースした自律型開発エージェントで、仕様からコードの設計・実装・テストまでを一貫して担える点が特徴とされている。Kiroに与えたプロンプトはシンプルな3ステップだった。
- AWS CLIを元にテストを書く
- そのテストが実際のAWSに対してパスするまでイテレーションする
- 同じテストがパスするインメモリ実装を構築する
Kiroは15分後に、Amazon SQSの最初のバージョンを返してきた。 その週末中にAWS全体のエミュレータを構築させ、翌月曜日にはチームが実際にテストで使い始めていた。
3チームのエージェントがリレーで開発する
週末の実験を継続的な製品として成立させるために必要だったのは、エージェントに「塗り絵」を与えること——つまり、エージェントが迷わず動けるよう、明確な境界線を持つタスクを設計することだった。曖昧な指示ではエージェントは意図しない方向へ走り出す。その教訓のもと、開発フローは役割が明確に分かれた3チームのエージェントによるリレー構造に設計された。
チーム1：テスト作成
AWS API Modelsを元に、実際のAWSシナリオ（例：キュー作成→メッセージ送信→受信→削除）をテストとして記述し、実AWSに対して検証する。現在、数万件のフィデリティテストが蓄積されており、継続的に増加している。これらのテストは「エージェントが何を達成すべきか」を定義するガードレールの核となる。
チーム2：問題の発見
チーム1が作ったテストをエミュレータに対して再実行し、差異（divergence）を検出する。失敗したテストはissueとして起票され、根本原因が共通しそうなものはグルーピングされてファイリングされる。
チーム3：修正
issueを1件ずつ担当し、コードをチェックアウトして根本原因を特定・修正する。修正はマージ前にマージゲートを通過する必要があり、ゲートはコンパイル確認、コーディング規約レビュー、セキュリティ検査、フィデリティ回帰テストの4段階で構成される。いずれかが失敗すればエージェントへの差し戻しとなる。
このパイプラインにより、数百のエージェントが並列で稼働し、1日あたり数千件のissueが修正される状態が今も続いている。
マージゲートが品質を担保する
エンジニアにとって特に興味深いのが、このマージゲートの設計だ。人間のコードレビューを一切介在させず、自動化だけで本番リリースまで持ち込む構造になっている。
コードはソース管理システム上で管理され、コミットが一定数スタックされた段階でビルドと再テストが実施される。その後リリースブランチへのマージを経てバイナリとしてパッケージ化され、最終ステップでGitHubへの公開が行われる。この仕組みは、ソフトウェア開発における「人間によるレビュー」の役割をどこまでテストと自動化に置き換えられるかという問いへの、現時点での一つの実装例だ。
失敗から得られたもの
リポジトリのissueディレクトリはthings-that-now-workとthings-that-do-not-workに分かれており、エージェントの試行錯誤の全履歴が公開されている。過去のバージョンでは、エージェントがAWS Lambda関数をサポートするために独自のPythonインタープリタを自作したというエピソードも紹介されている。現在は既存ライブラリを再利用するよう指示が与えられているが、この事例は「エージェントに適切な境界線を与えなければ、想定外の方向に走り出す」という教訓を端的に示している。
フィデリティテストのセットもGitHub上で公開されており、今後はマルチエージェントワークフローの設計、フィデリティの計測方法、品質・セキュリティ基準の担保方法についての詳細記事が予定されているという。エージェントによるソフトウェア開発がどこまでスケールするかを測る上で、継続して追うべき事例だ。
詳細はHow we built the agents that built AWS Emulatorを参照していただきたい。
