AWSエミュレーターと、エージェントがコードを書く時代のエンジニアの仕事
AWS Emulator and the engineer's job when agents write the code (allthingsdistributed.com)
要約
AWSは、コーディングエージェントがローカル環境でAWSサービスをテストできる「AWS Emulator」をリリースしました。これは、AIエージェントがコードを生成する時代において、エンジニアの役割が仕様定義、テスト環境構築、品質保証へとシフトしていくことを示唆しています。このエミュレーターは、200以上のAWSサービスに対応し、エージェントによって開発・テストされており、エンジニアがAIと協働して高品質なソフトウェアを構築する未来への一歩となります。
全文翻訳
2026年11月11日 • 1671語
［画像： Werner Vogels氏の若い頃の写真］
2004年、Amazonに入社して1ヶ月も経たない頃、インターンを採用する機会がありました。同僚よりも有利な点がありました。アムステルダムのVrije Universiteit（私もそこを卒業しました :-))で博士号取得を目指していた優秀な若者について、すでに耳にしていたのです。私はすぐに、皆さんが今、Swamiとして知っているSwaminathan Sivasubramanianを選びました。おそらく、AmazonのCTOとして22年間で私が下した最高の決断の一つでしょう。
2004年のクリスマス、商用リレーショナルデータベースがAmazonのニーズにスケールしなかったという悲惨な出来事の後、私はSwamiにAmazonでリレーショナルデータベースが実際にどのように使われているかを深く調査するように依頼しました。その結果、データベース操作の70%は実際にはリレーショナルではなかったことが判明しました。それらはキーバリューでした。その洞察が、Swamiがアーキテクトを支援したDynamoにつながりました。インターンシップが終わると、彼は博士号を終える前に、私は彼をすぐに正社員として採用しました。
もう一人、意見をはっきり言う学術的な人材を迎えたことで、実際にスケールするシステムを構築してきたAmazonの実践的なエンジニアたちとの間で、多くの素晴らしい議論が生まれました。結果整合性 vs. 強整合性、CAP定理 vs. Paxosなどです。時が経つにつれて、SwamiはAWSのデータ戦略の主要なアーキテクトの一人となりました。そして近年見てきたように、彼はAmazonにおけるAIイノベーションの知的推進者の一人でもあります。
AWSの多くのサービスを支える基盤となる分散システムに関する根本的な仕事、そしてエージェントがコードを書くようになったときにエンジニアの仕事がどう変わるかについて、彼がゲスト投稿を書いてくれたことを光栄に思います。本日ローンチされたAWS Emulatorは、エージェントに、かつて私たちが依存していたようなテスト環境を提供します。Swamiの物語は、Lambdaのネットワークの背後にある見えないエンジニアリングのもう一つの素晴らしい例です。
さあ、構築を始めましょう。
-W
AWS Emulatorと、エージェントがコードを書く時代のエンジニアの仕事
本日、私たちはAWS Emulatorをリリースします。これは、コーディングエージェントがテスト対象としてローカルコピーのAWSを利用できるようにするもので、私のキャリア初期のプロジェクトに繋がっています。多くの点で、このエミュレーターのローンチは、私たちが構築する分散システムの品質を向上させるために、信頼性の高いソフトウェアエンジニアリングに注いだ努力を思い出させます。そのために、一つの物語を共有したいと思います。
約20年前、Wernerは私に、Amazonの初期のエンジニアの一人であるAl Vermeulenと共に、「Alf」と呼んでいた分散ロックサービスに取り組むように依頼しました。Alfは、Leslie Lamportの研究に基づいたプロトコルであるPaxos上に構築されており、サーバー群が一つの値に合意することを可能にし、その中のレプリケーションエンジンがサーバー間でデータのコピーを整合させていました。Alfは現在でも、S3、DynamoDBなど、私たちの多くの複雑な分散システム（ただし、様々な変更が加えられ、かなり進化していますが、それは別のブログで触れます！）を支えています。
分散システムはテストが難しい
Paxosは分散システム合意プロトコルのデファクトスタンダードであり、学術界ではよく理解されていました。しかし、AmazonとAWSが成長していく規模でそれを構築するのは容易ではありませんでした。私たちは、サーバーやデータセンター間のレプリケーションだけでなく、数万ものクライアントが同時にロックを要求し、ネットワークパーティション中にリースを更新するという状況に対処する必要がありました。そのすべてにおいて、中核となる要件は「常に正しくあること」でした！当時、分散システムをテストするための最良のアイデアは、大規模システムテストとカオスエンジニアリングでした。どちらも効果的でしたが、コストが高く、多くの種類の条件をオンデマンドで再現することはできませんでした。これは、真実のストアとして、すべてのクライアントに強整合的な真実のビューを提供し、サーバー障害やパケットロス中でも動作し続ける必要があったAlfにとって重要でした。いくつかの業界論文では、Paxosベースのロックサービスは正しく実装するのが難しいと書かれており、テストの困難さもその理由の一部でした。
私たちは、可能な限り忠実度の高いAlfの環境をシミュレートすることで、この問題に対処しました。サーバーをJVM内で実行し、ネットワークや依存するインフラストラクチャの残りをシミュレートしたため、システム全体が制御可能な一つのプログラム内に存在しました。パケットをドロップしたり、他の障害をいつでも注入したりでき、シミュレーションを突いてバグやスケーラビリティの問題を見つけるツールを構築しました。競合状態のバグは、イベントが特定の順序で発生した場合にのみ現れますが、シミュレーションでは、それらの順序の多くを意図的に設定し、Alfがそれぞれにどう対処するかを検査できました。また、TLA+のような理論的手法を用いた形式的推論も使用し、多くの問題を発見しました。このようにテストすることで、Alfが実際のサーバーで実行される前に、ほとんどの競合状態バグを解消しました。その後、実際の環境でのテストでは、シミュレーションではできないことを現実世界が露呈するため、異なる問題が見つかりました。
手作業で構築したテスト環境の限界
シミュレーションと形式的推論は、どちらも適用した分散システムのソフトウェア品質を向上させました。シミュレーションが機能したのは、小規模なチームが手作業でシステム環境のコピーを構築できたからです。当時、AWSにはサービスが少数しかなかったのです。しかし今日、AWSには200以上のサービスがあり、AWSを呼び出すアプリケーションは、使用する各サービスに対してテスト環境が必要です。これらすべてを手作業で構築するには何年もエンジニアリングが必要ですが、エージェントは現在、プロダクションでチェックできるチームよりもはるかに速くコードを書いています。そこで、エージェント自身がそれらの環境を構築し、テストできるかどうかを知りたかったのです。
このアイデアは、AWS Developer ToolsチームのSenior Principal EngineerであるMatt Goldberg氏から生まれました。彼の仮説は、サービスがどのように動作すべきかの記述と、チェック対象となる実際のサービスがあれば、エージェントはそれ自体でそのサービスの動作するバージョンを構築できるというものでした。AWSにとって、記述は公開APIモデルのセットです。これは、サービスの操作とその入力、出力、エラーを記述するためのAWSのフォーマットであるSmithyで書かれています。チェック対象となる実際のサービスは、顧客が使用しているのと同じシステムであるAWSクラウドそのものです。
エージェントは、公開APIモデルから考案されたエンドツーエンドの顧客シナリオである忠実度テストから作業します。例えば、Amazon Simple Queue Service（SQS）では、受信したメッセージが可視タイムアウトが切れるまで他のリーダーから隠されたままであることをチェックするテストなどがあります。エージェントは、実際のAWSに対してテストがパスするまで各テストを修正するため、テストはAWSの動作を記録します。その後、エージェントはテストがパスするまでエミュレーターを構築し、まだ失敗するテストはエミュレーターのギャップを示します。MattはSQS単体から始め、Kiroにこのアプローチを説明するプロンプトを1つ与えたところ、約15分で合格可能なSQSエミュレーターの最初のバージョンが返されました。Matt Goldberg氏のローンチ投稿には、そのプロトタイプがAWS Emulatorにどのように成長したかが書かれています。AWS Emulatorのコードはすべてエージェントによって書かれ、テストされており、200以上のAWSサービスをカバーする400以上のAPIモデルから構築されています。これは、お使いのマシン上で無料でオフラインで実行できます。エージェントのチームが実際のAWSに対してテストを実行し、見つかったギャップを修正します。すべての変更は、マージゲートを通過します。これは、コードベースに入る前にすべての変更が通過しなければならない多数の自動チェックであり、複数のセキュリティエージェントが敵対的なレビューを行います。
コーディングループ内のインフラストラクチャ
コーディングエージェントはループ内で動作します。コードを書き、実行し、結果を読み取ってから、次に何を修正するかを決定します。分散システムでは、そのループはインフラストラクチャ内で実行されるため、それが呼び出すサービスは実際のサービスのように動作する必要があります。それらがそうである場合、エージェントはコードを書きながら自身の作業をチェックでき、最初の試行でより頻繁に正しいコードを生成できるため、ソフトウェア品質が向上します。AWS Emulatorは、そのインフラストラクチャをあなた自身のマシン上のループ内に配置します。
エージェントがコードを書く時代のエンジニアの仕事
エージェントがコードを書き、自身の作業をチェックする場合、エンジニアの仕事は、それらが自律的に作業するためのスペースを提供し、その作業がいつ正しいかを決定する仕様、テスト、およびマージゲートを構築することです。これは、私がAlと私がAlfのために構築したレプリケーションエンジンをKiroを使って再構築したときに、苦労して学んだ教訓でした。その作業には、最初に約4ヶ月かかりました。私は、エージェントに結果をチェックする方法がないことに気づくまで、4晩監督しました。仕様とテスト環境が整うと、再構築は約2時間で完了しました。
AWS Emulatorを構築したエージェントは、最初から両方を持っていました。公開APIモデルと実際のAWSです。エンジニアがそれらを実行するスキャフォールディングを構築しました。内部バージョンは週末にかけてまとまり、1ヶ月以内に採用が始まりました。それを堅牢なソリューションに変えるには、さらに多くの作業が必要でした。
AI時代のソフトウェア品質は、エンジニアがエージェントの周りに設計するガードレールに依存します。AWS Emulatorでは、それらのガードレールは、実際のAWSに対して検証された忠実度テスト、さまざまな攻撃方法をレビューする複数のセキュリティエージェントと一般的なコードレビュアーを備えたマージゲート、そしてエージェントが触るべきではないコードに触れるのを防ぐ決定論的なチェックです。私たちは、エンジニアが構築されるものを決定し、作業がいつ正しいかを判断する一方で、エージェントがほとんどのソフトウェアを構築することを期待しています。私たちは、エンジニアがエージェントのチームを率いて信頼性が高く高品質なソフトウェアを構築する方法を学ぶ初期段階にあり、AWS Emulatorが生まれた方法は、それが実際にはどのように機能するかを示す良い例です。私たちは、ガードレールを追加し続け、エージェントがそれを構築する方法を洗練させていく予定です。
ローンチ時に知っておくべきこと
エミュレーターコードは、パブリックドメインへのクリエイティブ・コモンズの献納であるCC0の下でリリースされます。
re:Inventでこの作業についてさらに詳しく共有します。完全なコミット履歴とエージェントが提出したすべてのissueは、GitHubリポジトリで公開されており、その「things-that-do-not-work」フォルダには、エージェントが見つけた、まだ実際のAWSと一致しない動作を説明するissueが含まれています。