目次
このブログの目的（と、ごあいさつ）
こんにちは。SREの gumamon です！
昨今のAI Agentの進歩は目覚ましいものがありますね。Vibe Coding という言葉も登場し、自然言語でAIに指示をすればアプリケーションが作れる時代になる──そんな話もちらほら聞きます。
しかし、Vibe（雰囲気）で作業をされると一瞬で崩壊してしまうのがインフラ領域です。
「AI Agentをどう使っていこう？」と悩まれている方も多いのではないでしょうか。
このブログでは、AI Agentの一種である ClaudeCode を使って、既存のAWS環境をTerraform化した過程をご紹介します。
この記事を読むことで、インフラ領域におけるAI Agent活用のイメージを掴んでいただければと思います。
対象読者と前提知識
本記事は、実務で Terraform を使用している技術者を対象としています。
また、以下については（本稿よりも圧倒的に良いブログやドキュメントがあるので）割愛します。
- AI Agentについての基礎知識
- ClaudeCode とは／使い方
免責
本稿の元となる作業は2025年7月に実施したものです。
執筆時点では、より良い選択肢や方法があるかもしれません (時の流れが速すぎて怖い・・・)。
結論から言うと、現状では 「インフラ（リソース）の変更を伴わない作業」 に留めるのが良いと思います。
先日行われた PLATFORM ENGINEERING KAIGI 2025 のKeynoteで、こんな発言がありました。
AI is an angry intern（AIは怒れるインターン生）
少々言い過ぎですが、「確かにね！」と思うところがあります。
AI Agentに作業を任せる際、人間は「期待するふるまい」をコンテキストとして伝えます。
たとえば次のような指示です。
terraform planは実行可、terraform applyは禁止- 既存のAWSリソース（ECSなど）をもとにTerraformコードを生成する
序盤はこれを忠実に守って動くのですが、作業が長引くにつれて次第に怪しい提案をしはじめ、最終的には terraform apply を実行してリソースを合わせにいく──そんなことも起こります（というか起こりました）。
現状のAI Agentは長いコンテキストを保持するのが苦手で、会話履歴が圧縮される過程で重要な指示が抜け落ちることがあります。
その結果、「やってはいけないこと」をやってしまう。
AIと人間は根本的に特性が異なります。
AIに任せるなら、ガードレール（制限・権限・監視）をきちんと整えることが必須だと感じました。
AI Agentを逐一監視（提案されるコマンドのたびにEnter）していたのでは、人間側の作業効率が上がりません。
（諸説あると思いますが）私は AI Agentの実行環境をサンドボックス化し、インフラ構成を変更できない権限 を与えたうえで、自由に作業させることにしました。以下が実際の実行環境です。
実行環境で工夫したポイントは以下です。
AWSへのアクセス権限（IAM User/RoleにアタッチするIAM Policy）は以下の通りです。
ReadOnlyAccess（AWS管理／全リソースへのRead権限）custom-dynamodb-access-for-terraform（ユーザー管理／DynamoDB(lock)へのGet,Put,Delete権限）custom-s3-access-for-terraform（ユーザー管理／S3(tfstate)へのGet,Put,List権限）
ここからは、3日間で実際に行った作業と悩んだことを書いていきます。
Day1：ClaudeCodeのインストールとプロンプト整備
実行環境の作成 → ClaudeCodeの導入
Terraformを少しだけ書く
- サンプルとして軽くTerraformコードを追加（いわゆるワンショットプロンプト）
- 自分の構成が意外と曖昧なことに気づく
README.mdにTerraformフォルダ構成を書く
- フォルダ構成と役割を整理しながらREADMEに記載
(構成ツリー)
.
├── README.md # README
└── terraform # Terraform Code
├── bootstrap # Bootstrap Code (初期化用コード: Terraform自体の初期設定を行う)
│ ├── dev # Development Bootstrap Code (Terraformの実行ディレクトリ: dev環境用)
│ │ ├── main.tf # Main Terraform file for dev bootstrap (Terraformのエントリーポイント)
│ │ └── variables.tf # Variables for dev bootstrap (dev環境用変数)
│ └── prod (WIP) # Production Bootstrap Code (Terraformの実行ディレクトリ: prod環境用)
├── environments # Environment Code (環境ごとのコード: dev,prodなど)
│ ├── dev # Development Environment Code (Terraformの実行ディレクトリ: dev環境用)
│ │ ├── main.tf # Main Terraform file for dev environment (Terraformのエントリーポイント)
│ │ ├── variables_global.tf # Global variables (グローバル変数)
│ │ ├── variables_platform.tf # Variables for platform module (プラットフォームモジュール用変数)
│ │ ├── variables_gateway.tf # Variables for gateway module (ゲートウェイモジュール用変数)
│ │ └── ...
│ └── prod
└── modules # Modules (モジュール: 再利用可能なコードの集まり)
└── common # Common Modules (共通モジュール: 複数の環境で使用される共通のリソース)
├── platform # Platform Modules (プラットフォームモジュール: VPC, IAMなどの基盤となるリソース)
│ ├── vpc.tf # VPC configuration (VPC設定)
│ ├── xxx.tf # xxx configuration (任意のリソース設定: .tfファイルはリソースごとに準備する)
│ ├── variables.tf # Variables for platform module (プラットフォームモジュール用変数)
│ └── outputs.tf # Outputs for platform module (プラットフォームモジュールの出力)
├── gateway # Gateway Modules (ゲートウェイモジュール: API Gatewayなどの設定)
│ ├── alb.tf # Application Load Balancer configuration (ALB設定)
│ ├── xxx.tf # xxx configuration (任意のリソース設定)
│ └── variables.tf # Variables for gateway module (ゲートウェイモジュール用変数)
└── ...
一日目終了。
Day2：AWSリソースのTerraform化
ClaudeCodeのPJ初期化再実行
/init実行 → より良いCLAUDE.mdが生成される
既存AWSのTerraform化を開始
- Claudeに「既存AWS環境から1モジュールを作成」と依頼
- 想定外の提案も多く、しばらくペアプロ的に進行
- 成功したケースを要約してCLAUDE.mdに反映
- 試行錯誤の末、安定して出力できるようになり、2モジュールをTerraform化
（プロンプト例）
# 目的 VPCのリソースをTerraformで管理したい - すでにAWS環境のリソースは存在しています (.aws/config の情報でアクセス可能) - AWSリソースを調査し、Terraformのコードを作成する必要があります - さらに、既存のリソースをTerraformで管理するために、`terraform import` を使用する必要があります - 複雑なタスクです `think` して取り組んでください。調査ができ、**実行計画を立てることができたら一度私に確認させてください** # 追加するリソース - VPCに関するリソース # その他要件 - リソースはplatform moduleに追加してください - environments/dev から platform module を呼び出すコードを作成してください - moduleの変数は適宜設定してください - 構成や変数化の粒度については既存のコードを参照
二日目終了。
Day3：Terraformのリファクタリング
リファクタリング方針を検討
- Day2のコードではIAMをplatform moduleに含めていたが、
それではgateway moduleなどをスケールさせる際に柔軟性がないと気づく - 各moduleで使うIAMをそれぞれに分離する方針へ変更
ClaudeCodeにリファクタを指示
- 想定通りに動かないため、再びペアプロモードへ
- 成功パターンを要約し、
additional_prompts/以下に保存 - CLAUDE.mdからリンク参照させる方式を試す
NOTE
CLAUDE.mdが長くなってきたため、プロンプトを分割。
結果として「どの追加プロンプトを編集すべきか」が明確になり、体験が向上しました。
仕上げ
- Terraform全体をレビューさせ、命名規則・タグのばらつき を指摘させ修正
- 人間による最終チェックを実施し、
#TODOコメントをClaudeに処理させて完了
1. とにかく速い
序盤はClaudeCodeの動作を見守っていましたが、プランニングもコーディングも人間の速度を遥かに超える。
自力で1ヶ月かかる作業が、試行錯誤込みで3日で完了しました。
インフラ領域でも、今後仕事の進め方が根本的に変わると実感しました。
2. 想定以上に応用が効く
以前ならAWSリソースをTerraform化するには Terraformer が必須でした。
しかし、対応外リソースでもClaudeCodeは問題なくコードを生成。
ドキュメントを読んだり学習済み知識を活用したりしているようで、十分な精度を感じました。
3. 思い切った意思決定ができる
Day3でIAM設計の問題に気づきリファクタに踏み切りましたが、手書きでTerraform化していたら費用対効果の面で諦めていたと思います。
Agentと協働することで、人間の業務をより抽象度の高い領域へシフトできると実感しました。
4. 思考整理の効果がある
Day1でも触れましたが、曖昧な要件では曖昧な出力しか得られません。
Agentに読ませるプロンプトを練る過程で、自分の理解が不十分な部分が浮き彫りになり、思考が整理されていきました。
「自分がわからないことは指示できない」という制約が、結果的に品質を高めているように感じました。
今回は、ClaudeCodeを使用した既存AWS環境のTerraform化の事例をご紹介させて頂きました！
インフラ領域へのAI Agentの活用検討の一助となれていましたら幸いです。
以上、最後までお読み頂きありがとうございました！
コメント