【AI時代のLinuxエンジニア IaC編】第2回：Terraformで構築するAI向けクラウドインフラと状態（State）管理の極意

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
大反響をいただいている新シリーズ「AI時代のLinuxエンジニア IaC（Infrastructure as Code）編」。今回は、いよいよ本格的なツール実践に踏み込む「第2回：Terraform（テラフォーム）によるインフラ構築と状態管理」をお届けします。

前回の総集編ロードマップで解説した通り、IaCには大きく分けて「外側のハコ（インフラ）を作るツール」と「内側のOSを設定するツール」があります。
Ubuntu 26.04サーバーを立ち上げるための「土地（ネットワーク）」を用意し、「建物（仮想マシンやGPUインスタンス）」を建てるための、世界で最も使われているプロビジョニングツールがHashiCorp社の『Terraform』です。

本記事では、2026年現在のモダンなAIインフラ開発において必須となるTerraformのHCL構文の基礎から、チーム開発で命取りになる「State（状態ファイル）」のリモート管理（S3 + DynamoDB）、そして高価なGPUインスタンスのコストを激減させるスポットインスタンスの自動プロビジョニングまで、プロの現場の極意を8000文字超の圧倒的ボリュームで完全解説します。

---

1. 宣言型言語「HCL」の美学：Terraformの基本アーキテクチャ

Terraformは、AWS、Google Cloud、Microsoft AzureといったあらゆるクラウドベンダーのAPIを叩き、インフラを構築・変更・破壊するためのオープンソースツールです。

Terraformを記述するための専用言語を HCL（HashiCorp Configuration Language） と呼びます。この言語の最大の特徴は、シェルスクリプトのような「どうやって作るか（Imperative：命令型）」ではなく、「最終的にどうなってほしいか（Declarative：宣言型）」を記述する点にあります。

1-1. 命令型と宣言型の決定的な違い

アプローチ	シェルスクリプト (命令型 / AWS CLI)	Terraform (宣言型 / HCL)
コードの書き方	「1. ネットワークを作れ」「2. サーバーを立てろ」「3. ポートを開けろ」という手順（How）を書く。	「ネットワークが1つ、サーバーが1台、ポートが空いている状態であれ（What）」と記述する。
再実行時の挙動	もう一度実行すると、サーバーがもう1台増えてしまい、エラーになったり重複課金されたりする（冪等性がない）。	現在の状態と比較し、「すでにサーバーがあるなら何もしない（変更点のみ適用する）」という賢い動作をする（冪等性がある）。
依存関係の解決	エンジニアが「VPCを作ってからEC2を作る」という順番をプログラミングで制御しなければならない。	Terraformがリソースの依存関係（AがないとBが作れない）を自動で計算し、最適な順序（並列処理含む）で実行してくれる。

この「宣言型」というパラダイムシフトにより、インフラエンジニアは「複雑な構築手順書」を作る作業から解放され、「美しく無駄のないアーキテクチャの設計図」を描くことだけに集中できるようになりました。

---

2. GUI構築の終焉：インフラエンジニアの業務はどう変わるのか？

Terraformを導入した組織では、AWSなどのクラウド管理画面（Webブラウザのコンソール）にログインして手動で設定を変更することは「固く禁止」されます。

2-1. Terraformの3つの魔法のコマンド

Terraformを使ったインフラ構築は、基本的に以下の3つのコマンドのサイクルで回ります。

1. terraform init（初期化）: 必要なプラグイン（AWSを操作するためのモジュール等）をダウンロードし、作業準備を整えます。
2. terraform plan（計画）: ★最も重要！★ 実際にインフラを作る前に、「このコードを実行したら、AWS上の何が追加され、何が削除され、何が変更されるか」の差分（Dry Run結果）を画面に表示します。ここで人間（またはAI）が危険な変更がないかレビューします。
3. terraform apply（適用）: plan の結果に問題がなければ、実際にクラウドのAPIを叩いてインフラを構築・変更します。

---

3. Terraformの心臓部：「tfstate（状態ファイル）」の残酷な真実

Terraformが「宣言型」として賢く振る舞えるのには理由があります。それが terraform.tfstate というファイルの存在です。

3-1. tfstate とは何か？

Terraformは、実行された結果（実際にAWS上に作られたVPCのIDや、UbuntuサーバーのIPアドレスなど）を、すべて terraform.tfstate というJSON形式のファイルに記録して保存します。

次回 terraform apply を実行した際、Terraformは以下の3つを比較します。

1. 手元にあるHCLコード（理想の姿）
2. tfstate ファイル（Terraformが知っている現在の姿）
3. 実際のクラウドリソース（現実の姿）

この比較によって、「あ、コードにはサーバーが2台と書いてあるけど、tfstateには1台しか記録されていないから、あと1台追加で作ればいいんだな」と判断しているのです。

3-2. ローカル管理の悲劇

初心者は、この tfstate ファイルを自分のパソコンの中（ローカル）に置いたまま作業をしてしまいます。
もしあなたがパソコンを壊して tfstate を紛失した場合、Terraformは「自分が作ったインフラの記憶」を完全に喪失します。コードを実行しても「すべて新規作成」しようとしてエラーになり、既存のインフラは「Terraformから管理できない迷子のリソース」と化すのです。

---

4. チーム開発の必須条件：S3とDynamoDBによるRemote Backendと排他制御

プロの現場では、インフラエンジニアが複数人で同時にTerraformのコードを書き換えます。
もしAさんとBさんが、同時に別々のパソコンから terraform apply を実行したらどうなるでしょうか？クラウド側のリソースが競合してメチャクチャになり、tfstate ファイルが破損してインフラが壊滅します。

4-1. Remote Backend（S3）による状態の共有

この悲劇を防ぐため、tfstate ファイルは個人のパソコンではなく、AWSの S3（オブジェクトストレージ） などのクラウド上に保存してチーム全員で共有します。これを「リモートバックエンド」と呼びます。

4-2. State Locking（DynamoDB）による排他制御

さらに重要なのが「状態のロック（排他制御）」です。
Aさんが apply を実行している最中は、Bさんが apply を打っても「現在ロックされています」と弾かれる仕組みが必要です。AWS環境では、これを DynamoDB（NoSQLデータベース） を使って実現します。

# チーム開発の絶対的なベストプラクティス（backend.tf の設定例）
terraform {
  backend "s3" {
    bucket         = "linuxkoubou-terraform-state-bucket"
    key            = "ai-infrastructure/terraform.tfstate"
    region         = "ap-northeast-1"
    encrypt        = true
    # DynamoDBテーブルを使った排他制御（ロック）の有効化
    dynamodb_table = "terraform-state-lock"
  }
}

---

5. 【実践】AI向けUbuntu 26.04インフラをTerraformで記述する

それでは、実際のプロのコードを見てみましょう。
AIの学習モデル（LLMなど）を構築するため、AWS上に「最新のUbuntu 26.04 LTS」を搭載したGPUインスタンスを立ち上げる main.tf の実践的なコードです。

5-1. Ubuntu 26.04のAMI（OSイメージ）の動的取得

OSのイメージID（AMI ID）は頻繁に更新されます。プロはIDをハードコードせず、AWSのAPIに「最新のUbuntu 26.04のIDを教えて」と動的に検索させます。

# 最新のUbuntu 26.04 LTS (Noble Numbat) AMIを動的に取得
data "aws_ami" "ubuntu_2604" {
  most_recent = true
  owners      = ["099720109477"] # Canonical公式アカウント

  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-noble-26.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
}

5-2. AI用GPUインスタンスの定義とCloud-initの流し込み

取得したUbuntuのイメージを使って、実際にサーバー（EC2）を構築します。AI用途であるため、NVIDIA GPUを搭載した g5.xlarge インスタンスを指定し、初期設定スクリプト（user_data）を渡します。

resource "aws_instance" "ai_server" {
  ami           = data.aws_ami.ubuntu_2604.id
  instance_type = "g5.xlarge"  # NVIDIA A10G GPU搭載インスタンス
  key_name      = "my-ssh-key"
  
  # ネットワーク設定（VPCやサブネットは別途定義）
  subnet_id                   = aws_subnet.ai_public_subnet.id
  vpc_security_group_ids      = [aws_security_group.ai_sg.id]
  associate_public_ip_address = true

  # AIのデータセットを入れるための大容量・高速ディスク
  root_block_device {
    volume_size           = 100
    volume_type           = "gp3"
    iops                  = 3000
    delete_on_termination = true
  }

  # 初回起動時に流し込むCloud-init（Ansibleを動かすための事前準備）
  user_data = <<-EOF
              #!/bin/bash
              apt-get update -y
              apt-get install -y python3 python3-pip
              echo "AI Infrastructure Provisioned by Terraform" > /etc/motd
              EOF

  tags = {
    Name        = "Ubuntu2604-AI-Node"
    Environment = "Development"
  }
}

---

6. コスト破壊の魔法：Spot Instanceを用いたGPUサーバーの自動調達

AIの開発環境において、インフラエンジニアの最も重要な使命は「莫大なクラウドコスト（課金）を抑えること」です。
先ほど指定したGPUインスタンス（g5.xlarge）は、1ヶ月稼働させると数万円〜十数万円かかります。これを普通に立ち上げておくのはお金の無駄です。

6-1. スポットインスタンス（Spot Instances）の活用

AWSには、空いているサーバーを最大90%オフの激安価格で借りられる「スポットインスタンス」という仕組みがあります。ただし、「AWS側で空きがなくなったら、わずか2分の警告で強制終了（没収）される」という過酷な条件が付きます。

6-2. 壊れることを前提としたIaC設計

手動で環境を作っているエンジニアは、スポットインスタンスを使えません。なぜなら、没収された時に「もう一度NVIDIAのドライバを入れて、AIのライブラリを入れて……」と手作業で復旧していたら日が暮れるからです。

しかし、TerraformとAnsibleでインフラを完全にコード化（IaC化）しているあなたなら違います。
Terraformのコードを1行変えるだけで、激安のスポットインスタンスを要求する仕様になります。

# スポットインスタンスを要求するTerraformリソースの例
resource "aws_spot_instance_request" "ai_spot_server" {
  ami           = data.aws_ami.ubuntu_2604.id
  instance_type = "g5.xlarge"
  spot_price    = "0.50"  # 1時間あたり最大0.5ドルまでなら払う
  
  # ... (その他はaws_instanceと同じ) ...
}

没収されたらどうするのか？簡単です。ふたたび terraform apply と Ansibleコマンドを打てば、たった数分で「さっきまでと全く同じ完璧なUbuntu 26.04のAI環境」が自動で復活します。
「インフラはいつでも捨てられるし、いつでも再構築できる（Disposable Infrastructure）」。 これがIaCを導入する最大の金銭的・アーキテクチャ的メリットなのです。

---

7. モジュール化によるコードの再利用と環境分離（Dev/Stg/Prod）

コードの量が増えてくると、main.tf という1つのファイルに何百行も書くのは辛くなります。また、「開発環境（Dev）」と「本番環境（Prod）」で似たようなコードをコピペして2つ作るのは、メンテナンスの地獄（DRY原則違反）を生み出します。

7-1. Terraform Module（モジュール）の概念

Terraformには、よく使う構成を「部品（モジュール）」として切り出す機能があります。例えば「安全なネットワーク設定（VPC）」や「AI用Ubuntuサーバー一式」をモジュール化しておきます。

# 開発環境（Dev）用のコード呼び出し
module "ai_server_dev" {
  source        = "./modules/ai_server"
  environment   = "dev"
  instance_type = "t3.micro"  # 開発用は安いサーバー
  volume_size   = 20
}

# 本番環境（Prod）用のコード呼び出し
module "ai_server_prod" {
  source        = "./modules/ai_server"
  environment   = "prod"
  instance_type = "g5.xlarge" # 本番用はGPUサーバー
  volume_size   = 100
}

このように、中身のロジックは共通化しつつ、渡す変数（インスタンスサイズなど）だけを変えることで、開発環境と本番環境の「インフラの差分（バグの原因）」を根絶することができます。

---

8. AIを部下にする：TerraformコードをLLMに生成させるプロンプト術

最後に、AI時代のインフラエンジニアの真骨頂です。
TerraformのHCL構文は非常に厳格であり、人間がゼロから書くとタイポ（打ち間違い）や括弧の閉じ忘れで何時間も溶かすことになります。
2026年の私たちは、設計図のアイデアをAI（GeminiやChatGPT）に伝え、コードの骨組みを一瞬で生成させます。

8-1. インフラコード生成の「神プロンプト」

「あなたはシニア・クラウドアーキテクトです。
AWS上にTerraform (HCL2) を用いて、セキュアなAI推論環境を構築するコードセットを生成してください。

【要件定義】
1. S3とDynamoDBを用いたリモートバックエンドとStateロックの設定を含めること。
2. ネットワーク:
   - 新規VPC (10.0.0.0/16) を作成。
   - パブリックサブネットとプライベートサブネットを1つずつ作成。
3. セキュリティグループ:
   - SSH (TCP 22) は、特定のIPアドレス変数 (`var.admin_ip`) からのみ許可する。絶対に `0.0.0.0/0` を指定しないこと。
   - AIのAPI用ポート (TCP 8000) はVPC内部からのみ許可する。
4. インスタンス:
   - 最新のUbuntu 26.04 LTS AMIを動的データソースで取得。
   - プライベートサブネットに配置するGPUインスタンスを定義。

出力するコードは `main.tf`, `variables.tf`, `backend.tf` に分割し、プロフェッショナルなインデントと日本語の解説コメントを付与してください。」

AIはあなたの指示に従い、ネットワークの依存関係やセキュリティルールを完璧に満たしたHCLコードを数秒で出力します。
あなたの仕事は、出力されたコードの terraform plan を眺め、「AIが勝手に危険なポートを開けていないか」「自分の意図したアーキテクチャになっているか」をレビュー（承認）することです。
これが、コードを書かずにクラウドを支配する「次世代インフラエンジニア」の働き方です。

---

総まとめ：コードでクラウドを制する者がインフラを制す

「AI時代のLinuxエンジニア IaC編」第2回、本当にお疲れ様でした！

今回は、クラウドインフラをコードで支配する「Terraform」の哲学と実践について学びました。

1. 宣言型のアプローチ： 手順（How）ではなく、最終状態（What）をコード化する。
2. State（状態）の管理： tfstate をS3とDynamoDBで保護し、チーム開発の競合を防ぐ。
3. コスト最適化： IaCの復旧力を盾にして、高価なGPUサーバーをスポットインスタンスで格安運用する。
4. AIとの協業： 面倒なHCL構文はAIに書かせ、人間はアーキテクチャのレビューに専念する。

「Terraformでクラウドのハコを作る」。これでUbuntu 26.04のサーバーが立ち上がりました。
しかし、立ち上がったばかりのUbuntuの中身は空っぽです。NVIDIAのドライバも入っていなければ、Dockerも動いておらず、セキュリティ設定もデフォルトのままです。

次回、第3回「AnsibleによるUbuntu 26.04のOS内部構成と冪等性の確保」では、Terraformが作った空っぽのサーバーに対して、Ansibleを流し込み、AIを動かすための完璧なミドルウェア環境を「全自動で組み上げる」魔法を解説します。お楽しみに！