11月11日、Werner Vogelsが「AWS Emulator and the engineer's job when agents write the code」と題した記事を公開した。AIエージェントがコードを書く時代、エンジニアの仕事はどう変わるのか——そして、その変化を体現するために生まれた「AWS Emulator」の詳細が明かされた。
AWS EmulatorはS3、SQS、DynamoDBをはじめとする200以上のAWSサービスをローカルマシン上で再現するエミュレーターだ。無料・オフラインで動作し、ライセンスはCC0（パブリックドメイン相当のCreative Commonsライセンス）。コードはすでにGitHubで公開されている。同種のツールとしてはLocalStackが広く知られているが、AWS Emulatorはエミュレーター自体のコードをAIエージェントが生成・テストしたという開発プロセスが際立った特徴だ。
エージェントに「何を与えるか」がエンジニアの仕事になる
記事の大半は、Amazon AI担当SVPのSwaminathan Sivasubramanian（通称「Swami」）がゲスト執筆している。Swamiは自身のキャリア初期の経験を語ることから始める。Amazonで分散ロックサービス「Alf」を開発していた頃、同僚のAl Vermeulenと4ヶ月かけて実装したPaxosベースのレプリケーションエンジンを、最近になってAmazon製AIコーディングエージェント「Kiro」で再構築しようとした。
最初の4夜、Swamiはエージェントの作業を直接監督したが、すぐに問題に気づいた。エージェントには自分の出力が正しいかどうかを確認する手段がなかった。そこで仕様（spec）とテスト環境を整えて渡すと、エージェントによる再構築が約2時間で完了した。
この体験がこの記事の中心テーゼに直結する。エージェントがコードを書く時代、エンジニアの仕事は「コードを書くこと」から「エージェントが動ける仕様・テスト・マージゲートを設計すること」に移行する——これがSwamiの主張だ。
AWS Emulatorはどうやって作られたか
AWS Emulatorのアイデアを最初に提案したのは、AWS Developer ToolsチームのSenior Principal EngineerであるMatt Goldbergだ。「サービスの仕様記述と、正解として参照できる本物のサービスがあれば、エージェントが自力でそのサービスの動作するバージョンを作れるのではないか」という仮説を立て、SQS（Amazon Simple Queue Service）一つで試してみた。
結果、Kiroへの一度のプロンプトで約15分後に動作するSQSエミュレーターの初期版が返ってきた。これを皮切りに、プロトタイプは200以上のサービスをカバーする現在の形に成長した。開発の詳細はMatt GoldbergによるAmazon公式ローンチポストに詳しい。
技術的な構成は次のとおりだ：
- 400以上のAPIモデルを元に構築。モデルの記述フォーマットはAWS独自のIDL（インターフェース定義言語）であるSmithy
- エミュレーター自体のコードはすべてエージェントが生成・テスト
- 無料・オフラインで動作、ライセンスはCC0
品質をどう担保するか：「マージゲート」という設計
エージェントが自律的にコードを書く以上、品質と安全性の担保が問題になる。AWS Emulatorでは以下の仕組みで対応している。
- Fidelity tests（忠実性テスト）：公開APIモデルから生成したエンドツーエンドのシナリオテスト。本物のAWS上で正しく通ることを確認してから、エミュレーターにも同じテストを課す。SQSでは「受信したメッセージがvisibility timeout切れまで他のコンシューマーから見えないこと」を検証するテストが一例として挙げられている
- マージゲート：変更がコードベースに入る前に通過しなければならない自動チェック群。複数のセキュリティエージェントが異なる攻撃観点からコードをレビューする
- 決定論的チェック：エージェントが触ってはいけないコードに手を出せないようにする静的な制御
この設計思想自体が、前述の「仕様・テスト・マージゲートを設計することがエンジニアの仕事になる」というテーゼの実例になっている。
分散システムのテストという、古くて新しい問題
記事がユニークなのは、今日のAI時代の話をするために20年前の分散システム開発の話から始める点だ。Alfの開発時、SwamiたちはPaxosベースの実装をJVM上のサーバーシミュレーション内で動かし、ネットワーク遅延やパケットロス、障害を任意のタイミングで注入してテストした。さらにTLA+（分散システムの形式検証に広く使われる仕様記述言語）を組み合わせることで、実環境に乗せる前に並行性バグのほとんどを潰すことができた。
PaxosはLeslie Lamportが考案した分散合意プロトコルで、複数のサーバーが障害環境下でも一つの値について合意するための手法だ。現代の分散データベースやストレージ基盤の多くがその派生アルゴリズムを採用している。
この「シミュレーション環境でテストを完結させる」発想はAWS Emulatorにも直結している。ただし当時はチームが一つのシステムの環境を手で作れるスケールだった。今のAWSは200以上のサービスを持ち、手で全部作るのは現実的でない。だからエージェントに作らせた——そういう流れだ。
現状と今後
GitHubリポジトリではエージェントが起票したissueや全コミット履歴もすべて公開されている。リポジトリ内の「things-that-do-not-work」フォルダには、エミュレーターがまだ本物のAWSと一致しない挙動が正直に記録されており、現時点での限界が明示されている。詳細はAWSの年次開発者カンファレンス「re:Invent」でも発表予定とのことだ。
詳細はAWS Emulator and the engineer's job when agents write the codeを参照していただきたい。
