JustFit
ブログ
AWS Emulator公開、全コードはAI執筆とAWSが公表

AWS Emulator公開、全コードはAI執筆とAWSが公表

2026.11.13 JustFit編集部（運営：株式会社LEGAREA）

AWS（Amazon Web Services）が2026年11月11日に公開した「AWS Emulator」は、クラウドの機能を手元のパソコンで試せるエミュレーター（本物の代わりに動く試験用の環境）です。AWSは、このツールのコードの全てを自律型のAIエージェントが書いたと説明しています。

この記事では、公開された内容と公式が書く制限を確かめたうえで、新規事業やシステム開発にとって何が変わりうるかを整理します。事実の部分には出典を付け、私たちの見方は別の見出しにまとめます。

11月11日、AWSが「エージェントが全部書いた」エミュレーターを公開した

AWSは2026年11月11日にAWS Emulatorを公開しました。一般提供（GA）の位置づけで、438のAWS API定義をもとに、200を超えるサービスを扱います。

注目されているのは、機能よりも作り方です。AWSは「エミュレーターは自律型エージェントが全て書いた。チームはコードを書いても、レビューしてもいない」と説明しています。

手元で動かす使い方

AWS CLI、AWS SDK、コーディングエージェントは、ローカルのHTTPSエンドポイントを通して接続します。クラウドで使うのと同じAPIを使います。AWSのアカウントがなくても、開発者やコーディングエージェントが自分のマシンでAWSのAPIを試せます。

AWSの文書は、開発サーバーや継続的インテグレーション（CI。コードの変更のたびに自動で試験を回す仕組み）も使う場所として挙げています。この場合、リクエストはAWSではなくエミュレートされたリソースに届きます。

コーディングAIにとっては、リソースを作り、結果を確かめ、コードを直す、という流れを、リージョンへのデプロイを待たずに回せるようになります。

三つのエージェントチームと、通らないと入れない関門

作り方は三つのエージェントチームに分かれています。一つ目は試験一式を書いて管理するチーム、二つ目はエミュレーターの問題を見つけるチーム、三つ目は原因を分析して直すチームです。変更が本体のコードに入る前には、ビルドの確認と、他のエージェントによる確認（コーディング規約・セキュリティ・忠実度）を通る必要があります。

規模についてはこう書かれています。AWSによると、数百のエージェントが同時にコードに取り組み、1日に数千件の問題を直しています。

出発点は小さな実験でした。あるエンジニアがKiroというコーディングエージェントに頼み、15分でAmazon SQSの使える版を作らせたのが始まりです。

ソースコードと忠実度テストはGitHubで公開され、ライセンスはCC0（パブリックドメインへの献呈）です。

点数を公開する「忠実度テスト」と、公式が書く制限

このツールの「本物にどれだけ近いか」は、忠実度テストで測られます。

テストに合格するには、ステータスコード、本文、エラーコードとメッセージまで含めて、全ての呼び出しの応答がAWSと一致する必要があります。作られるリソースやデータも一致しなければなりません。結果は、リリースごとにサービス別の「合格数／テスト数」で公表されます。テスト一式も、まだ通らないものを含めて公開されています。

一方で、制限も公式の文書に明記されています。

IAMのポリシーとリソースベースのポリシーは、AWSと同じようには評価されません。セキュリティの試験には使わないよう書かれています。
どのリージョンやアカウントIDも受け付けますが、リソースは分けて管理されません。1つのリージョンと1つのアカウントで使うよう案内されています。
本物とどれだけ一致するかは、サービスや機能によって異なります。
AWSとの照合は、原則としてUS West（オレゴン）で行われています。
本番の処理に使うことは想定されていません。作られたリソースはメモリ上にあり、エミュレーターを止めると消えます。

初期設定の扱いも確認が必要です。既定では、匿名の利用データとエラーデータがAWSに送られますが、止めることもできます。リクエストやレスポンス、リソースのデータは送られないと報じられています。

全体の一致率の数字は、第三者の記事によって少しずつ違っていました。公式ページでは、サービスごとの点数を見る形になっています。事業で使うサービスについては、その点数を個別に見るのが確実です。

私たちの見方：人が持つのは、コードよりも「正しさの基準」

ここから先は、事実ではなく、JustFit編集部としての見方です。

見方1：書く作業が減るほど、「何をもって正しいとするか」が仕事の中心になる

AWSのSwami Sivasubramanian氏は、エージェントがコードを書いて自分で確かめる場合、エンジニアの役割は、エージェントが自分で動ける余地をつくり、仕事が正しいと判断する仕様・テスト・マージの関門を作ることだと書いています。

AWS Emulatorでは、この「基準」にあたるものが、本物のAWSで確かめた忠実度テストでした。新規事業の開発に置き換えると、基準は「事業として何が起きれば成功か」「画面や動きとして何が確認できればよいか」になります。AIの得意分野が広がるほど、人が決める部分がはっきりしてくる、というのが私たちの見方です。役割分担については「AI開発でエンジニアの役割はどう変わる？任せる作業と判断」や「AI開発でも品質には人の確認が必要な理由」でも書いています。

見方2：手元で確認できる範囲が広がると、試作の見直しが回しやすくなる

エージェントが「書く→動かす→結果を読む」を繰り返すには、動かす先が必要です。クラウドへのデプロイを待たずに済めば、クラウドを使うシステムの試作でも、確認の往復を増やしやすくなる可能性があります。

ただし、これは公式が確かめた効果ではなく、仕組みから考えた私たちの推測です。実際にどれだけ短くなるかは、使うサービスの忠実度によって変わります。試作の作り方は「AIでプロトタイプを短期間で作れる理由｜工程ごとの仕組み」、試験の任せ方は「AIのテスト自動生成｜任せる範囲と人が見る確認項目」で整理しています。

見方3：「手元で通った」は、「本番で通る」の代わりにならない

公式が挙げる制限のうち、特に新規事業で効いてくるのは権限の扱いです。会員ごとに見られる情報が違うサービスや、決済・個人情報を扱うサービスでは、アクセス権限の設計が事業の信用に直結します。

手元の環境では、AWSなら拒否されるリクエストが通ってしまうことがあります。権限まわりは、本物の環境での確認を別に残す前提で考えるのが安全です。確認の観点は「AI生成コードのセキュリティ｜確認点と人の役割」にまとめています。

見方4：「人が読んでいないコード」は、引き継ぎと権利の確認が要る

今回のAWSは、自社で出す道具に、基準と関門を整えたうえで「人はコードを読まない」やり方を選びました。同じやり方を、事業で使うシステムにそのまま当てはめられるかは別の話です。

事業で使う場合は、後から誰が直すのか、コードの権利をどう扱うのかも、あらかじめ確認する必要があります。「AI生成コードの保守は可能か｜引き継ぎと改修の確認点」と「AI生成コードの著作権｜事業で使う前の確認点」が参考になります。

まとめ

AWS Emulatorは、11月11日に公開された、AWSのAPIを手元で試せるエミュレーターです。AWSは、コードの全てを自律型のAIエージェントが書き、チームは書いてもレビューしてもいないと説明しています。作り方の中心は、本物のAWSで確かめた忠実度テストと、通らないと本体に入れない関門でした。

一方で、IAMなどの権限の評価がAWSと異なること、1つのリージョンとアカウントで使うこと、本番向けではないことが、公式の文書に書かれています。

新規事業やシステム開発にとっては、AIが書く量が増えるほど、人が「何を作るか」と「何を正しいとするか」を決める比重が高くなる、というのが私たちの見方です。

私たちJustFitは、AIを活用した独自の開発基盤「LAF」で、要件定義から設計、実装、テスト、レビューまでを複数の専門AIがチームとして進め、人は何を作るかの決定と品質の最終判断を担います。構想をもとに約1ヶ月で動くプロトタイプを先に作り、実物を見てから判断できる進め方です。新規事業のアイデアを、システムを軸にした事業の形にしたいときは、JustFitのサービス紹介をご覧ください。

参考にした情報

← ブログ一覧へ