AWS公式の無料エミュレータはAIが全部書いている

S3にファイルを置く処理やDynamoDBへの書き込みを含むコードをテストするとき、本物のAWSを呼ぶと料金と待ち時間がかかる。この悩みに、2026年10月に「MiniStack」という登録不要の無料ツールで答えが出たばかりだった。そこへ今度は、AWS自身が無料のローカルエミュレータ「AWS Emulator」を公開した。しかも、このツールのコードは人間が1行も書いていない。

AWS公式が無料のエミュレータを出した

AWS公式ブログによれば、AWS Emulatorは2026年11月11日に公開された。手元のマシンでAWSのAPIエンドポイントを再現するローカルプログラムで、AWSアカウントは要らない。AWS CLIやSDKの接続先を環境変数でエミュレータへ向けるだけで、コードを書き換えずにそのまま動く。追加のサービス料金もかからない。

公式ドキュメントは、次の3つの使い方を挙げている。

• デプロイ前のローカルテスト
• AWSアカウントを使わないCI/CDパイプラインでの結合テスト
• AIコーディングエージェントでのプロトタイピング

対応するAPIモデルは400以上、サービス数は200以上にのぼる。Linuxでは専用パッケージ、macOSとWindowsはDockerで動かす。Rustのテストでは、プロセス内で動く「埋め込みモード」も使える。

AWSを再現するツールは他にもあった

MiniStackの記事で確かめたとおり、無料でAWSをローカル再現する選択肢はすでに2つあった。登録必須のLocalStack無料枠と、docker run一行で動くサードパーティ製のMiniStackだ。AWS Emulatorが加わったことで、選択肢は3つになる。

対応サービス数とAWS公式という立場だけを見れば、AWS Emulatorが一番手堅く見える。だが自分が引っかかったのは表の最後の行だった。200以上のサービスに追従するコードを、本当に人間が1行も書いていないということがあり得るのか。

エージェントだけで動く仕組み

仕様とテストさえあれば書けるという仮説

AWS幹部Swami Sivasubramanian氏が書いた開発裏話に、その答えがあった。きっかけは、Developer ToolsチームのシニアプリンシパルエンジニアMatt Goldberg氏の思いつきだったという。

公開されているAPIの仕様(Smithyで書かれたAPIモデル)と、本物のAWSに対して通るテストがある。この両方さえあれば、エージェントは自分でそれを満たす実装を書けるのではないか。これがGoldberg氏の仮説だった。

Goldberg氏が社内のAI開発環境「Kiro」に1つのプロンプトを与えたところ、Amazon SQSの「それなりに動く初版」が約15分で返ってきたという。15分でサービス1つぶんの実装ができるなら、200以上のサービスも時間の問題に思える。

4か月の仕事が2時間になった夜

ところがSivasubramanian氏自身が試すと、そう簡単にはいかなかった。同氏はかつて、社内の分散ロックサービス「Alf」のレプリケーションエンジンの開発に携わっていた。元の開発には約4か月かかっている。

この同じ再構築を、仕様書もテストも与えずにKiroへゼロからやらせてみたところ、4晩にわたって様子を見ても作業はまったく進まなかった。ところがAPIの仕様とテスト環境を揃えたうえでやり直すと、今度は約2時間で終わったという。

受け取り方を間違えそうになったのはここだ。「エージェントが速い」のではない。仕様とテストという、エージェントが自分で答え合わせをできる材料があるかどうかが、進むか進まないかを分けていた。Goldberg氏のSQSが15分で動いたのも、AWSの公開APIモデルという仕様と、本番のAWSに対して合格するテストという材料が最初から揃っていたからだ。

人間が触れない開発の仕組み

この「答え合わせ」の精度は、実際の挙動にも表れている。公式ドキュメントの例によれば、DynamoDBのテーブル名を3文字未満にして作成しようとすると、エミュレータは本番のAWSとまったく同じ文言のエラーを返す。

An error occurred (ValidationException) when calling the CreateTable operation: 1 validation error detected: Value 'ab' at 'tableName' failed to satisfy constraint: Member must have length greater than or equal to 3

このエラー文言が本番と一致するかどうかが、仕様とテストで突き合わせられる「答え」になる。

AWS Emulatorは今も、3種類のチームが並行して動いている。

• 本番のAWSに対してテストを走らせるチーム
• エミュレータでそのテストを実行し、ギャップを報告するチーム
• 報告されたギャップを直すチーム

公式ブログによれば、更新は「1日に何度も」入るという。

マージの関門にも複数のエージェントが並ぶ。敵対的な視点でレビューするセキュリティエージェントと、一般のコードレビュアー役のエージェント、そしてエージェントが触れてはいけないコードを守る機械的なチェックだ。

Sivasubramanian氏は、エンジニアの仕事をこう書いている。「エージェントが自律的に動ける余地を与え、その作業が正しいかどうかを判定する仕様・テスト・マージの関門を作ること」だと。

試す前に知っておきたい制限

今すぐ試すなら、起動の手順は難しくない。Linuxなら専用パッケージ、macOSとWindowsならDockerで起動し、AWS CLIやSDKの接続先を環境変数でエミュレータへ向けるだけでよい。ただし、公式ドキュメントが挙げる制限は小さくない。

• 本番環境やセキュリティテストには使えない。IAMポリシーやリソースベースのポリシーを、AWSと同じようには評価しない
• 1つのエミュレータにつき1リージョン・1アカウントまで。複数リージョンを試すには、リージョンごとに別のエミュレータをポートを分けて起動する
• AWSとの一致度(フィデリティ)はサービスや機能によって異なる。確認時点の最新リリース(v1.0.322)はバグ修正が中心で、個別サービスの一致度の数値はリリースごとにGitHub上で公開される
• すべてのリソースはメモリ上に保持され、エミュレータを止めると消える。長時間の稼働や負荷テストでの動作は確認されていない

これらの制限は、裏を返せば「短いテストを素早く繰り返す」という使い方に絞った設計だということでもある。長期間動かし続けるサーバーの代わりにはならない。

まとめ

AWSを呼ぶコードをお金をかけずにローカルでテストする選択肢は、これで3つになった。登録必須のLocalStack、サードパーティ製で登録不要のMiniStack、そしてAWS公式のAWS Emulatorだ。

AWS Emulatorの対応サービス数は200以上と最多で、AWSアカウントなしに環境変数を向けるだけで使える。何より、このエミュレータ自体が人間のコードを1行も含まず、公開APIの仕様と本番AWSに対するテストを基準にAIエージェントのチームが書き続けている。その開発体制は、ツールそのものより興味深い発見だった。

本番運用やセキュリティテストには使えないという制限はあるが、手元のDockerかパッケージで、今すぐ動かして試せる。