バイブコーディング時代のAWS基本戦略 — 最小権限とコスト管理を最初に固める

TL;DRAIにインフラコードを書かせる「バイブコーディング」では、過剰な権限と高額リソースが静かに混入する。構築を始める前にIAMの最小権限とAWS Budgetsのアラートという2つの防衛線を張るべきで、特にOpenSearchのような時間課金サービスは消し忘れが数万円の請求に直結する。AdministratorAccessでの作業を「楽だから」で続けないことが第一歩。

バイブコーディング、つまり自然言語の指示でAIにコードを書かせる開発スタイルは、アプリケーションだけでなくインフラ構築にも及んでいます。「S3とLambdaとAPI Gatewayでサーバーレス構成を作って」と頼めば、CloudFormationやTerraformのコードが数十秒で出てくる。便利ですが、生成されたコードには2つの危険が静かに混入します。過剰なIAM権限と、想定外の課金を生むリソース設定です。本稿では、AIが生成するインフラを安全に運用するために「構築より先に」固めるべき2つの防衛線を整理します。

第一の防衛線:IAMと最小権限の原則

AIが生成するIAMポリシーには、"Action": "s3:*""Resource": "*"のようなワイルドカードが頻繁に登場します。動かすことを優先すれば当然そうなりますが、これはS3の全バケットに対する全操作を許す指定であり、誤操作や認証情報の漏洩が起きたときの被害範囲を際限なく広げます。最小権限の原則とは、必要な操作を、必要なリソースに対してだけ許可することです。Lambda関数が特定バケットにオブジェクトを書くだけなら、ポリシーはここまで絞れます。

IAMポリシー(最小権限の例)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::my-app-output/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:*:*"
    }
  ]
}

運用面ではもう一つ重要な習慣があります。学習用アカウントでありがちな「rootユーザーやAdministratorAccess付きユーザーで日常作業をする」ことをやめ、用途別のロールを作って必要時だけ引き受ける形にすることです。AIに生成させたポリシーは、デプロイ前に必ずActionResourceのワイルドカードを点検する。このレビューはエージェントの生成コードレビューと同じで、人間側の責任範囲です。

第二の防衛線:課金アラートを最初に張る

AWSの学習で本当に怖いのは、ハッキングよりも消し忘れです。特にOpenSearch Serviceは、最小構成のドメインでも時間課金が止まらず、検証のつもりで立てたまま数週間放置すると数万円規模の請求になり得ます。EC2も同様で、インスタンスを停止してもEBSボリュームとElastic IPには課金が続く点を見落としがちです。NAT Gatewayも時間課金と通信量課金の両方が走る、初学者の典型的な事故ポイントです。

対策はシンプルで、リソースを1つでも作る前にAWS Budgetsで予算アラートを設定することです。たとえば月20ドルの予算を切り、実績が50%・80%・100%に達した時点でメール通知する。さらに「予測値が予算を超えそうな時点」でも通知できるため、消し忘れの検知が請求確定より早くなります。Cost Explorerでサービス別の日次コストを週に一度眺める習慣をつけると、身に覚えのない課金の芽を早期に摘めます。AIに「OpenSearchで検索基盤を作って」と頼む前に、そのリソースの課金モデルを自分が説明できるか。説明できないサービスは立てない、というルールを自分に課しています。

VPC・EC2・Lambdaの構築で意識する境界

ネットワークの基本設計も、AI任せにせず骨格だけは自分で決めます。VPCはパブリックサブネットとプライベートサブネットに分け、インターネットから直接届いてよいもの(ALB、踏み台)だけをパブリックに置く。EC2のセキュリティグループは「どこから・どのポートに・誰が」を最小で書き、0.0.0.0/0への22番ポート開放のような生成結果は必ず修正する。Lambdaは実行ロールを関数ごとに分離し、共有ロールに権限を足し続ける運用を避ける。どれも地味ですが、境界を最初に決めておけば、AIに細部を任せても全体が破綻しません。

バイブコーディングとの正しい付き合い方

結論はこうです。AIはリソースの「構築」は得意でも、あなたのアカウントの「責任」は取りません。最小権限とコスト管理は、AWSが公式に掲げるWell-Architected Frameworkでも繰り返し強調される基本ですが、バイブコーディング時代にはその重要性がむしろ上がっています。生成スピードが上がるほど、雑なリソースが量産されるスピードも上がるからです。アクセルはAIに任せてよい。ただしブレーキとガードレールは、構築を始める前に人間が用意する。これが現時点での私のAWS基本戦略です。

記事一覧へ戻る