ClaudeやCursorといったAIコーディングツールにAWSのアーキテクチャ設計を頼んだ経験があるエンジニアに向けた内容です。数分で立派な構成図が返ってきて、そのまま採用しそうになったことはないでしょうか。
AIに「スケーラブルな構成を」と頼むと、EKS（Kubernetesのマネージドサービス）やKinesis（大量データのストリーミング処理サービス）、Aurora Global Database（複数リージョンにまたがるデータベース）が一気に並んだ構成が出てくることがあります。一見クラウドネイティブに見えますが、月次のAWS請求書を見た経験がある人からすると、危険信号にしか見えません。この落とし穴がなぜ起きるのか、自分のプロジェクトが該当するかどうか、そして具体的な確認手順を整理します。
何が起きているか
AIが提案するAWS構成には、共通した3つの症状が見られます。
1つ目は「要件のハルシネーション（幻覚）」です。実際のRPS（1秒あたりのリクエスト数）やp99レイテンシ（全リクエストの99%が収まる応答時間）を聞かれてもいないのに、「高可用性」「高パフォーマンス」といった言葉だけで設計が進みます。
2つ目は「コストのハルシネーション」です。たとえばLambdaは安いと説明されても、API Gatewayが月4000万リクエストに達したときの料金や、NATゲートウェイの固定費（月32ドル程度）、AZ間データ転送費（1GBあたり0.01ドル）は語られないままになりがちです。技術的には動くのに、想定より数千ドル高くつく設計は失敗した設計と言えます。
3つ目は「サービスの乱立」です。あらゆる制約を同時に満たそうとして、SQS（シンプルなメッセージキューサービス）で十分な場面でもKinesisとMSK（マネージドKafka）とEventBridgeを並列で提案してくることがあります。運用できるチーム体制が伴わなければ、これは単なる管理負担の増加です。
なぜ起きるのか
原因を分解すると、AIの学習データの性質に行き着きます。
LLM（大規模言語モデル）は大量のドキュメントやブログ記事を学習していますが、その中には「レジリエンス」を名目に不必要な複雑さを推奨する質の低い記事も多く含まれています。AIは学習データの中で頻出するパターンを再現するため、コスト効率や自分のプロジェクトの制約に最適化された答えではなく、「よく見かける」答えを出しやすい性質があります。
さらにAIには確率的な予測というメカニズム上、数学的な厳密さや経済的な現実に基づいて判断する仕組みがありません。VPC内にひっそり存在するNATゲートウェイの固定費は「認識できていない」まま提案され、20人しか使わないツールに「マルチリージョン」構成が提案されるのも、単に「その方が専門的に聞こえる」からです。
つまりこれはコード生成の品質問題ではなく、推論プロセスそのものの問題です。要件を数値化せずに設計判断をさせると、AIは「雰囲気」で構成を組み立ててしまいます。
自分のプロジェクトが該当するか確認する
まず、AIが最近生成したAWS構成案やIaC（Infrastructure as Codeの略、インフラ構成をコードで定義する手法）のコードを見返してみてください。以下の観点でチェックできます。
- RPS・p99レイテンシ・可用性SLO（例: 99.95%）・RTO/RPO（障害復旧までの目標時間とデータ損失許容範囲）が数値で明記されているか
- EKSやKinesisなど高機能なサービスが提案された箇所で、Fargate（サーバー管理不要のコンテナ実行サービス）やSQSといったシンプルな代替と比較検討した形跡があるか
- コスト試算にNATゲートウェイ、AZ間転送費、VPCエンドポイント、CloudWatchのログ保存費が含まれているか
- IAMポリシーに
Resource: "*"のようなワイルドカードが残っていないか - アクセスキーではなくIAMロールでの認証を前提にしているか
Terraformを使っている場合は、terraform plan の出力とAWSの料金計算ツール（AWS Pricing Calculator）を突き合わせるだけでも、想定コストとのズレに気づけます。CloudFormationやCDKでも同様に、生成されたテンプレートに含まれるリソース数を数えてみると、サービス乱立の兆候が見えてきます。
対策の手順
AIに設計を任せる際は、レビューの手順を仕組み化することが有効です。
手順1: 要件を先に数値で固定する
AIに構成案を求める前に、プロンプトの中でRPS、p99レイテンシ、SLO、RTO/RPOを明示します。「高可用性にして」ではなく「p99レイテンシ200ms以内、可用性99.9%、RTOは15分」のように書くと、あいまいな提案が減ります。
手順2: 障害範囲（Blast Radius）を質問する
構成案が出てきたら、「AZが1つ丸ごと落ちたらどうなるか」「KMSが一時的に使えなくなったらどのコンポーネントが止まるか」を追加で質問します。「AWSが面倒を見てくれる」という回答が返ってきたら、その設計は障害シナリオを検討していない証拠です。
手順3: サービスごとに代替案との比較を求める
EKSが提案されたらFargateやECSとの比較を、Kinesisが提案されたらSQSやSNSとの比較を求めます。AIに「なぜこのサービスでなければならないか」を説明させることで、乱立を防げます。
手順4: TCO（総所有コスト）を項目別に出させる
コンピュート費用だけでなく、ストレージ、NATゲートウェイ、AZ間転送費、エグレス（外部への通信費用）、VPCエンドポイント、CloudWatch、サポートプランの費用まで内訳を出してもらいます。項目が抜けていたら追加で質問し、合計額を実際のAWS料金計算ツールで検算します。
手順5: セキュリティのDay 0チェックを行う
IAMロールを使っているか、ポリシーにワイルドカードがないかを確認します。アクセスキーの直接発行やAdministratorAccessの付与を前提にした提案は、その時点で差し戻す判断基準になります。
これらのゲートを手動のチェックリストとして運用するだけでも効果はありますが、レビュー専用のMCPサーバー（AIとツールを連携させる標準プロトコル上で動くサーバー）を使う方法もあります。AWS認証情報を一切要求せず、推論レイヤーだけで構成案を審査する仕組みであれば、インフラに直接触れさせるリスクを避けながら、設計段階でのチェックを自動化できます。導入を検討する場合は、対象のMCPサーバーがAWS Well-Architected Framework（AWSが提唱する設計原則集）のどの観点をゲートにしているかをドキュメントで確認しておくと安心です。
まとめ
AIが出すAWS構成案は、学習データに含まれる「よく見る派手な構成」に引っ張られやすい性質があります。
対策として押さえておきたいのは次の4点です。
- 構成案を求める前に、RPS・レイテンシ・SLO・RTO/RPOを数値で渡す
- 障害範囲とサービス選定の理由をAIに説明させ、乱立を防ぐ
- TCOを項目別に出させ、AWS Pricing Calculatorなどで実額を検算する
- IAMポリシーのワイルドカードとアクセスキー利用を必ずチェックする
次に構成案が出てきたときは、採用する前にこの5つの確認項目を1つずつ当てはめてみてください。数字とセキュリティ設定の裏付けがない提案は、いったん保留にする判断基準として使えます。