IaC（Infrastructure as Code）

なぜ手作業をやめるのか

クラウドのコンソールをポチポチ操作してサーバーを立てる方法は、最初は速いですが、次の問題を抱えます。

• 再現できない：「本番と同じ検証環境」を手で作ると、必ずどこか食い違う（設定漏れ・スノーフレークサーバー）。
• 記録が残らない：誰がいつ何を変えたか分からず、障害時に切り分けできない。
• 属人化する：手順が担当者の頭の中にしかなく、レビューもできない。

IaC はこれを 「コード＝唯一の正（Single Source of Truth）」 にすることで解決します。環境はコードから生成されるので、ファイルを見れば構成が分かり、変更は差分（diff）で追えます。

宣言的 vs 手続き的

IaC の書き方には大きく2つの流派があります。違いは「何を書くか」です。

• 宣言的（Declarative）：あるべき最終状態（What） を書く。「サーバーを2台、このネットワークに」と宣言すると、ツールが現状との差分を計算して必要な操作を実行する。
• 手続き的（Imperative）：手順（How） を書く。「サーバーを1台作る → もう1台作る → …」と、やることを順番に並べる。

宣言的は「現状がどうあれ、書いたとおりの状態に収束させる」ため、後述の冪等性と相性が良く、現在の主流です。

冪等性（べきとうせい）が鍵

IaC で最も大事な性質が 冪等性（idempotency）：同じコードを何回適用しても、結果が同じ状態になる こと。

たとえば「サーバーが2台ある状態」を宣言したコードは、

• 0台のとき流す → 2台 作る
• すでに2台あるとき流す → 何もしない（差分ゼロ）
• 1台のとき流す → 不足分を 1台だけ追加

というように、現状に応じて差分だけを埋めます。これにより「もう一回流したら3台になった」といった事故を防げ、安心して何度でも適用できます。

プロビジョニング vs 構成管理

IaC は守備範囲で2層に分けて考えると整理できます。混同しやすいので押さえておきましょう。

• プロビジョニング（基盤の用意）：サーバー・ネットワーク・ロードバランサなど インフラそのものを作る。代表が Terraform。クラウドの状態を state で管理し、宣言的に構築する。
• 構成管理（中身のセットアップ）：用意したサーバーの中で ミドルウェア導入・設定・デプロイ を行う。代表が Ansible。OS の上の状態を整える。

実務では「Terraform で箱（サーバー）を作り、Ansible で中身（nginx 等）を入れる」のように 組み合わせて 使うのが定番です。

コードのイメージ

宣言的な書き方は、こんな雰囲気です（あるべき状態を宣言する）。

# あるべき状態：このスペックのサーバーを1台
resource "aws_instance" "web" {
  ami           = "ami-xxxxxxxx"
  instance_type = "t3.micro"
  tags = {
    Name = "web-server"
  }
}

適用は「差分を確認 → 反映」の2段階が基本です。いきなり本番を変えず、まず計画（プラン）を見るのが安全な作法です。

terraform plan    # 何が変わるか差分を表示（まだ変更しない）
terraform apply   # 確認のうえ実際に反映

構成管理（Ansible）側は「あるべき状態」をタスクで並べます。冪等なモジュールを使うので、再実行しても余計な変更は起きません。

# nginx が「入っていて起動している」状態にする
- name: install and start nginx
  hosts: web
  tasks:
    - name: nginx をインストール
      ansible.builtin.package:
        name: nginx
        state: present     # “あるべき状態”を宣言（無ければ入れる）
    - name: nginx を起動・有効化
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true

つまずきポイント

• state ファイルの扱い：Terraform は現状を state に記録します。これをローカルに置いて共有しないと、チームで上書き事故が起きます。リモート（S3 等）で共有＋ロック が定石。
• 手で直さない（ドリフト）：IaC 管理下のリソースをコンソールから手動変更すると、コードと実体がズレる 構成ドリフト が発生し、次回適用で巻き戻る/壊れる原因に。変更は必ずコード経由で。
• 秘密情報をコードに書かない：パスワードや鍵を平文でコミットしない。変数・シークレット管理（Vault 等）に逃がす。

まとめ

• IaC は インフラをコードで定義 し、Git で 履歴・レビュー・再現性 を得る手法。
• 主流は 宣言的（あるべき状態を書く）で、冪等性（何度流しても同じ状態）が安全性の核。
• プロビジョニング（Terraform）で基盤、構成管理（Ansible）で中身 を担当し、組み合わせて使うのが定番。
• インフラ変更が「コードの差分」になると、CI/CD で自動適用したり、GitOps で Git を起点に運用したりと、自動化の土台になります。詳しいツールは Terraform も参照。