【第7回】TerraformとAIの連携：クラウドインフラ（AWS/GCP）のコード化と自動最適化

オンプレミスからクラウドへの移行が当たり前となった現代において、インフラエンジニアの主戦場は「物理サーバーのラッキング」から「クラウドAPIを叩くコードの記述」へと完全にシフトしました。そのクラウドインフラストラクチャをコードで定義し、構築・変更・バージョン管理を可能にするIaC（Infrastructure as Code）の決定版がTerraformです。

しかし、AWSやGCPといったメガクラウドのサービスは日々アップデートされ、それに伴いTerraformのプロバイダーやモジュールの仕様も絶えず変化しています。何百ページにも及ぶ公式ドキュメントを読み解き、依存関係を考慮しながらHCL（HashiCorp Configuration Language）をゼロから記述するのは、熟練のエンジニアであっても多大な時間を消費する作業です。

本連載「Linuxエンジニアのための生成AI」第7回となる今回は、生成AIを「高度なクラウドアーキテクト」として活用し、ベストプラクティスに準拠したセキュアなTerraformコード（HCL）を瞬時に自動生成するプロンプトエンジニアリングと、出力されたコードの脆弱性をシステム的に監査するテストパイプラインの構築手法について、プロの視点から徹底解説します。

📚 関連シリーズのアーカイブ

リナックス先生！最近AWSで検証環境を作ることになったんですが、VPC作って、サブネット切って、インターネットゲートウェイ設定して、セキュリティグループ書いて……って、マネジメントコンソールから手作業でポチポチやるのに限界を感じてます。Terraformを使えばいいのは分かるんですが、独自のHCLという言語の文法が難しくて挫折しそうです。

コウ君、クラウドのリソース構築をGUIで手作業するのは「1回限りの使い捨て環境」だけよ。本番環境への移行やスケールアウトを考えたら、Terraformでのコード化は必須スキルね。でも安心して。要件定義さえしっかり言語化できれば、HCLの文法やモジュールの依存関係の解決は生成AIが最も得意とするパズルのようなものなの。今日はAIに完璧なインフラコードを書かせる魔法のプロンプトを教えるわ！

1. なぜTerraform（IaC）の構築に生成AIが最適なのか？
- 1-1. 複雑な依存関係の自動解決と宣言的アプローチ
- 1-2. Terraformコード生成におけるLLMモデルの選定
2. 高品質なTerraformコード（HCL）を生成するプロンプト技術
3. AI生成コードの静的解析とセキュリティテスト（DevSecOps）
4. Terraform運用におけるAI連携のセキュリティ警告
- 4-1. Stateファイル（tfstate）は絶対にAIに送信しない
- 4-2. Plan結果を利用したAIによるレビューの自動化
5. 第7回の総まとめと最終回予告

📚 関連シリーズのアーカイブ

1. なぜTerraform（IaC）の構築に生成AIが最適なのか？
1. 1-1. 複雑な依存関係の自動解決と宣言的アプローチ
2. 1-2. Terraformコード生成におけるLLMモデルの選定
2. 高品質なTerraformコード（HCL）を生成するプロンプト技術
3. AI生成コードの静的解析とセキュリティテスト（DevSecOps）
4. Terraform運用におけるAI連携のセキュリティ警告
1. 4-1. Stateファイル（tfstate）は絶対にAIに送信しない
2. 4-2. Plan結果を利用したAIによるレビューの自動化
5. 第7回の総まとめと最終回予告
1. ▼ 【IaCのテスト・構築環境を手に入れよう】 ▼

1. なぜTerraform（IaC）の構築に生成AIが最適なのか？

クラウドインフラの構築は、単一のサーバーを立てて終わりではありません。ネットワーク（VPC）、ルーティング、ファイアウォール（セキュリティグループ）、そしてIAM（権限管理）といった多数のリソースが複雑に絡み合っています。

1-1. 複雑な依存関係の自動解決と宣言的アプローチ

第3回で解説したAnsibleと同様、Terraformも「最終的にどういう状態になってほしいか（What）」を記述する宣言的（Declarative）なツールです。しかし、TerraformのHCL（HashiCorp Configuration Language）は、リソース間の依存関係（例えば「VPCが作成された後でないとサブネットは作れない」「EIPはインターネットゲートウェイに依存する」など）をコード内で暗黙的に解決する高度なグラフ理論を用いています。

人間がこの依存関係を頭の中で組み立てながらゼロからコーディングするのは至難の業ですが、生成AIは数百万のオープンソースTerraformモジュールを学習しているため、自然言語で「AWSで可用性の高いWeb環境を作りたい」と指示するだけで、これらの依存関係を完璧に紐解き、論理的に破綻のないHCLを構築してくれます。

1-2. Terraformコード生成におけるLLMモデルの選定

Terraformのコード生成において、AIモデルの選定は極めて重要です。なぜなら、各クラウベンダー（AWS/GCP/Azure）のTerraformプロバイダーは高頻度でアップデートされ、古い構文（例えばTerraform 0.11時代の記法）を出力されると、最新環境では全く動作しないからです。

AIモデル	Terraform適性	インフラエンジニア視点での評価
Claude 3.5 Sonnet	◎ 最高峰	Terraform 1.x系の最新構文（`for_each`、モジュール分割、変数の型定義）を深く理解しています。実務レベルでそのまま利用できる、高度にモジュール化された美しいHCLを出力します。
ChatGPT (GPT-4o)	〇優秀	非常に優秀ですが、時折巨大な1つの `main.tf` に全てのリソースを詰め込もうとする傾向があります。プロンプトで「ファイルを分割せよ」と明示的な指示が必要です。

⚠️ プロの結論
インフラコードの生成には、アーキテクチャの構造化に長けたClaude 3.5 Sonnetを推奨します。また、実行環境であるAlmaLinux 9上には、必ず最新版のTerraformバイナリをインストール（`dnf install -y dnf-plugins-core && dnf config-manager –add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo && dnf install terraform`）しておきましょう。

2. 高品質なTerraformコード（HCL）を生成するプロンプト技術

AIに「動く」だけでなく「現場で保守可能な」コードを書かせるためには、インフラの設計思想をプロンプトに落とし込む必要があります。

2-1. 素人のプロンプト（アンチパターン）が生む負債

❌ 素人のプロンプト（失敗例）

AWSにWebサーバーを立てるTerraformのコードを書いて。

この指示では、AIはデフォルトVPC（非推奨）の中に、パブリックIPを直付けしたEC2インスタンスを1台ポツンと配置し、全開放（0.0.0.0/0）の危険なセキュリティグループを設定した「巨大な1つの main.tf」を出力する可能性が高いです。これは技術的負債以外の何物でもありません。

2-2. 現場で使える実践的プロンプト・テンプレート

⭕ プロのプロンプト（成功例）

あなたはAWS認定ソリューションアーキテクト・プロフェッショナルおよびSREです。
Terraform (バージョン1.5以上) を使用して、以下の要件を満たすAWSインフラ環境のHCLコードを作成してください。

【アーキテクチャ要件】
1. ネットワーク: 新規VPCを作成し、2つのアベイラビリティゾーン(AZ)にまたがるパブリックサブネットを2つ作成すること。
2. コンピュート: 各パブリックサブネットにEC2インスタンス（OSはAlmaLinux 9の公式AMIを使用）を1台ずつ配置すること。
3. セキュリティ: EC2インスタンスには、HTTP(80)とHTTPS(443)のインバウンド通信のみを全開放し、SSH(22)は特定のIP範囲（変数化すること）からのみ許可するセキュリティグループをアタッチすること。

【コーディング規約・ベストプラクティス（厳守）】
- モノリス化を避け、最低でも `main.tf`, `variables.tf`, `outputs.tf`, `providers.tf` の4ファイルに論理的に分割して出力すること。
- ハードコードを極力排除し、環境（dev/prod）ごとに可変となる値（インスタンスタイプ、CIDRブロック、SSH許可IPなど）は必ず `variables.tf` で定義すること。
- リソースの命名規則には統一されたプレフィックス（例: `var.project_name`-`var.environment`）を使用すること。
- Terraformの公式AWSプロバイダー（hashicorp/aws）を使用すること。
- 出力はHCLコードのみとし、各ファイル名を明記したMarkdownのコードブロック形式とすること。

プロンプトの最重要ポイントは「ファイルの論理分割」と「ハードコードの排除（変数化）」を強制することよ。これを指定しないと、AIは1つのファイルに全てを書き連ねてしまい、将来的にリソースが増えた時にメンテナンス不能なスパゲッティコードになってしまうわ。

2-3. AWS環境（VPC + EC2 AlmaLinux 9）の出力例と解説

上記のプロンプトをClaude 3.5 Sonnetに入力すると、以下のように美しいモジュール分割が施されたコード群が出力されます。（※紙面の都合上、一部抜粋）

`variables.tf` の出力例（変数定義）

variable "project_name" {
  description = "プロジェクト名"
  type        = string
  default     = "linuxkoubou"
}

variable "environment" {
  description = "環境名 (dev/stg/prod)"
  type        = string
  default     = "dev"
}

variable "allowed_ssh_cidr" {
  description = "SSHアクセスを許可するCIDRブロックのリスト"
  type        = list(string)
  default     = ["203.0.113.0/24"] # ※実際の運用では自社のIPに変更
}

`main.tf` の出力例（AlmaLinux 9のAMI検索とEC2デプロイ部分）

# AlmaLinux 9の最新公式AMIを動的に取得
data "aws_ami" "almalinux9" {
  most_recent = true
  owners      = ["764336703387"] # AlmaLinux OS Foundation 公式アカウントID

  filter {
    name   = "name"
    values = ["AlmaLinux OS 9.*x86_64*"]
  }
}

# EC2インスタンスの作成
resource "aws_instance" "web" {
  count                  = length(var.public_subnet_cidrs)
  ami                    = data.aws_ami.almalinux9.id
  instance_type          = var.instance_type
  subnet_id              = aws_subnet.public[count.index].id
  vpc_security_group_ids = [aws_security_group.web_sg.id]

  tags = {
    Name = "${var.project_name}-${var.environment}-web-${count.index + 1}"
  }
}

おおっ！AMIのIDを直書きするんじゃなくて、data "aws_ami" を使ってAlmaLinux 9の最新版をAWSのAPIから動的に検索する高度な書き方をしてくれてる！しかも count を使ってサブネットの数だけ動的にインスタンスを立てる仕組みまで。これは本の中級編で習うレベルのテクニックですね！

3. AI生成コードの静的解析とセキュリティテスト（DevSecOps）

AIが生成したインフラコードを、そのまま terraform apply（本番環境への適用）してはいけません。AnsibleやDockerの回でもお伝えした通り、「自動テスト」のプロセスを挟むことがプロの流儀です。

3-1. `terraform fmt` と `terraform validate` による基本チェック

まず、AlmaLinux 9のターミナル上で、AIが出力したファイルを保存したディレクトリに移動し、Terraformの組み込みコマンドで基本的な構文チェックを行います。

# コードのインデントやフォーマットを自動修正
terraform fmt

# 構文やモジュールの参照関係にエラーがないか検証
terraform validate

ここで Success! The configuration is valid. と出れば第一関門突破です。

3-2. TFLintによるベストプラクティスの検証

次に、Terraform専用の静的解析ツールである TFLint を使用して、非推奨の記法やクラウドプロバイダー固有のベストプラクティス違反がないかチェックします。

# AlmaLinux 9へのTFLintインストール
curl -s https://raw.githubusercontent.com/terraform-linters/tflint/master/install_linux.sh | bash

# チェックの実行
tflint

3-3. tfsec (Trivy) によるクラウドセキュリティ設定の監査

最も重要なのがセキュリティ監査です。AIが誤って「S3バケットをパブリック公開する設定」や「セキュリティグループの0.0.0.0/0全開放」を記述していないか、Aqua Security社が提供する tfsec（現在はTrivyに統合）を用いてスキャンします。

# tfsecのインストールと実行
curl -s -L "$(curl -s https://api.github.com/repos/aquasecurity/tfsec/releases/latest | grep -o -E "https://.+?tfsec-linux-amd64")" > tfsec
chmod +x tfsec
sudo mv tfsec /usr/local/bin/

# ディレクトリ内のHCLファイルをセキュリティスキャン
tfsec .

もし警告が出た場合は、その結果をそのままAIにコピペし、「tfsecで以下の脆弱性が指摘されました。セキュアな設定に修正してください」と指示を出してリファクタリングさせます。これが「AIとツールの対話ループ」によるDevSecOpsの実現です。

4. Terraform運用におけるAI連携のセキュリティ警告

Terraformと生成AIを連携させる上で、絶対に犯してはならない致命的なタブーが存在します。

4-1. Stateファイル（tfstate）は絶対にAIに送信しない

Terraformが現在のクラウドの状態を記録する terraform.tfstate ファイルには、RDS（データベース）のマスターパスワード、IAMのシークレットアクセスキー、証明書の秘密鍵などが「平文」で保存されています。

「エラーの原因を探って」とAIに質問する際、うっかりこの tfstate ファイルの中身をプロンプトに貼り付けてAPIに送信してしまうと、重大な情報漏洩インシデントとなります。AIにコンテキストとして渡して良いのは、自作した .tf ファイル（HCLソースコード）のみと徹底してください。

4-2. Plan結果を利用したAIによるレビューの自動化

安全な連携方法としては、terraform plan（実行計画）の出力結果のうち、機密情報が含まれていない変更のサマリ部分だけをAIに渡し、「このインフラ変更によってダウンタイムやセキュリティ上のリスクが発生しないかレビューして」と指示するフローが効果的です。これをCI/CDパイプライン（GitHub Actionsなど）に組み込むことで、自動レビューシステムが完成します。

⚠️ セキュリティの絶対原則
AIは構築を爆速化させますが、クラウドインフラの設定ミスは会社を傾かせるほどの損害（大規模情報漏洩、数百万単位のクラウド破産）を生むリスクがあります。Terraformの適用（apply）前には、必ず人間による terraform plan の目視確認と承認フローを挟んでください。

5. 第7回の総まとめと最終回予告

本記事では、Terraformを用いたAWS/GCPのクラウドインフラ構築を、生成AIを利用してコード化・最適化する手法について解説しました。

複雑な依存関係やモジュール分割といった「HCLの難しさ」はAIに任せ、私たちインフラエンジニアは「アーキテクチャの要件定義」と「tfsec等を用いたコードの監査」という、より上流でクリエイティブな業務にリソースを集中させることができるようになりました。これが、次世代のクラウドインフラ構築のスタンダードです。

次回の【第8回・最終回】完全自動化パイプラインの構築：AIとCI/CDが創るインフラ運用革命では、連載第1回から第7回までに学んだ「Bash、Ansible、Docker、Terraform」の全ての自動化技術を「GitLab CI / GitHub Actions」の上に統合し、AIによる自動レビューを組み込んだ究極の「自己修復・自律型インフラパイプライン」の全貌をお見せします。感動の最終回をお見逃しなく！