AIとIaCとAWS CLIでインフラアレルギーを治そう

2026-06-14 23:49

はじめに

こんにちは。株式会社divxのエンジニアの石川です。
皆さんはWebアプリのインフラ構築に苦手意識はありますか？私は前までメチャクチャありました。

必要な知識が多い
どのリソースがどう設定されているのかよくわかんない、いじるのが怖い
練習したいけどリソースの消し忘れが怖い
お客様のサービスを止めてしまったらと想像するだけで怖い
インフラ担当になったら休日に呼び出されそうでヤダ

インフラに対する苦手意識は、この辺りが原因かと思います。
一番最後のはちょっとどうしようもない部分もあるのですが、AI IaC AWS CLIの力で概ね解決できますよ！

尚、
この記事はほぼ人力で書いています。
この記事でのAIはAI Agent（主にClaude Code）としてお読みください。
この記事でのインフラはAWSを、IaCはAWS CDKを指しますが、インフラサービスはだいたい似たようなサービスやライブラリや仕組みがあるので、ご利用のインフラサービスに合わせて読み替えていただければと思います。

IaCとは？

IaC（Infrastructure as Code）とは、インフラリソースをコードで定義・管理する手法のことです。
AWSであれば、CFn（CloudFormation）を使えばIaCでリソース管理ができるようになります。
CFnのインフラリソース定義ファイルであるテンプレートファイルは、YAMLまたはJSONで作成するのですが、CDK（Cloud Development Kit）を使えば、定義ファイルをtypescriptやPythonで書くことができます。

AIとIaCとAWS CLIのシナジー

AIはコードを見れます
さらに、AIはコマンドも打てます
そして、IaCはインフラの設計図をコードとして書く手法のことです
でもって、AWS CLIは、AWSリソースの閲覧や操作をCLIコマンドでやれます
なので、IaCでインフラを扱っていれば、AIはインフラ構成が見れるし、AWS CLIでリソースの情報取得・操作もできます

・・・

そう、IaCでインフラを扱っていれば、AIはインフラ構成が見れるし、AWS CLIでリソースの情報取得・操作もできるのです！

AIに自然言語で頼めば、やりたいことを読み解いてインフラ設計図を作ってくれたり、リソースの現状を調べたり、修正までもやってくれるのです。

それではインフラアレルギーを治して行きましょう

必要な知識が多い → AIに教えてもらいながらIaC組めば良い

「EC2インスタンスを作ろうとしたら、設定項目の多さに戦慄した。何をどう設定したらいいのか全然わからない。」
そんな時にはClaude Codeを起動して、やりたい設計を伝えたりパッケージ情報を見てもらったりしつつ、CDKコードを書いてもらいましょう。
どこでどのような設定をしているか、コメントも入れてもらうと良い感じです。

プロンプト例...

「React Router製のアプリをデプロイしたいので、CDK組んでください。DBはPostgreSQLです。」
「Python 3製のバッチをLambdaで毎日午前3時に実行するようにCDK組んでください。」

どのリソースがどう設定されているのかわからない → IaCなら設定が明示されているし、差分もチェックできる

以下は、S3設定をCDKで書いた例です。
インフラ設定がTypeScriptコードで記されていますね。
「productionデプロイならオブジェクトのバージョニングを有効にして、stagingデプロイなら無効にする」といった設定も、TypeScriptで書いて指定できます。

    const uploadBucket = new s3.Bucket(this, "AwesomeSiteUploadBucket", {
      bucketName: `awesome-site-${env}-uploads`,
      versioned: env === "production", // productionではバージョニング有効
      publicReadAccess: false,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
      removalPolicy: cdk.RemovalPolicy.RETAIN, // バケットを保持
      autoDeleteObjects: false, // ファイルを自動削除しない
      cors: [
        {
          allowedMethods: [
            s3.HttpMethods.GET,
            s3.HttpMethods.POST,
            s3.HttpMethods.PUT,
          ],
          allowedOrigins: ["*"],
          allowedHeaders: ["*"],
        },
      ],
    });

リソースの設定コードをいじった後、デプロイ前にcdk diffコマンドを打てば、実際にデプロイするとどう変更が起こるかがわかります！

↓cdk diffコマンドについて
https://docs.aws.amazon.com/ja_jp/cdk/v2/guide/ref-cli-cmd-diff.html

cdk diffコマンドを打った時、リソース名の右に「replace」や「may be replaced」と表示されている場合は、そのリソースが作り直される可能性があります。
データのバックアップを取ったり、リプレイスされてもちゃんと動くことの確認が必要です。

練習したいけど消し忘れが怖い → スタックでモレなく消せる

CDKで作成した設定をデプロイする場合、自動的にAWS CloudFormationを使うことになるのですが、CloudFormationを利用するためにスタックというものを作成します。
スタックはリソースをまとめて管理するためのフォルダのようなものです。
他のリソースと混ざらず管理ができますし、スタック単位で作成や更新、削除ができるようになります。

CloudFormationはデプロイ・デストロイする時に、リソースをスタック単位で操作するため、
「練習で作ったリソースをうっかり消し忘れて、AWSから10万の請求が来ました」
「うっかり他所のリソースを消してしまいました」
ということが防げます。

⚠️尚、スタックで扱っていても、以下の場合はまとめて削除ができません。

RemovalPolicy.RETAINが設定されているリソース
- CDKの設定で、S3バケットやRDSスナップショットを残すために、RemovalPolicyにRETAIN（保持）指定ができる
手動作成したリソース
- 後述の理由で、手動作成つまりマニュアル操作は基本禁止

サービスを止めてしまうのが怖い → IaCでリソース操作に再現性を持たせて練習しよう！もしやらかしたらAIと一緒に原因調査しよう

IaCで諸々リソース設定を決めておくと、予行演習ができるようになります。
スタックの名前を本番用・練習用で変えて運用すれば、全く同じ設計図なので、全く同じリソースがデプロイできます。
練習用環境でIaC変更プッシュやバックアップ作成・リストア作業の手順確認をして、本番用環境でも同じことができるようにしておきましょう！
いざ動かしてみないとわからないことがそこそこあるので、予行練習は必須です。

うまくいかない時もAIで解決だ！

例えば、Webアプリを公開したのに、デプロイしていつまで経っても503だ！疎通チェックしよう！という時、まずClaude Codeを起動しましょう。
どこまでは正常に動いててどこからミスってるのか、AIにお任せすれば、原因追求・調査コマンド作成・実行・仮説立ても何から何までやってくれます。もうIPアドレスコピーしてcurlコマンドをちまちま書き換えて、なんて作業もいらないんですね〜

ただ、気がつくと本番環境で勝手に環境変数いじったりS3操作したりをIaC通さずにやり始めます。
「原因追求・解決策提示までを行い、解決策の実行はしないで」と伝えるのと、AIが実行しようとしているコマンドを毎回確認するようにしましょう・・・

IaCやる時の禁忌・リソースのマニュアル操作

リソースのマニュアル操作は極力行わないようにしましょう。
デプロイした後にリソースをいじくると、設計図とリソースの間に乖離が生まれます。
IaC導入は中途半端にやると破綻します。やるなら最初から導入し、リソース操作も設計図からの操作が基本です。
「データリストアのために、昔のスナップショットからボリューム作り直す必要がある」等、ど〜〜〜〜してもマニュアル操作をしないといけない時は、設計図との乖離をなるべく早くに解消しましょう。