開発プロセス

IaC（Infrastructure as Code）あいえーしー・いんふらすとらくちゃーあずこーど

インフラ自動化TerraformAnsible宣言的設定DevOpsクラウド

IaCって何？インフラをコードにするってどういうこと？

簡単に言うとこんな感じ！

昔はサーバーの設定を手作業でポチポチやっていたんだけど、IaCはそれを「プログラムのコード」として書いて管理する考え方だよ。コードだからGitで管理できるし、同じ環境を何度でも正確に再現できるし、レビューもできる。「インフラの設計書兼施工マニュアル」をコードで書くイメージ！

IaC（Infrastructure as Code）とは

IaC（Infrastructure as Code）とは、サーバー・ネットワーク・データベースなどのインフラ構成をコードとして記述・管理するアプローチです。従来、インフラの構築や変更は管理コンソールでの手作業や、担当者の手順書に依存していました。IaCではこれをテキストファイル（コード）で定義し、バージョン管理・自動実行・レビューの対象にします。

IaCには大きく2つのアプローチがあります。宣言的（Declarative）アプローチは「最終的にこうあってほしい状態」を記述し、ツールが現在の状態と比較して必要な変更を自動判断します（Terraform・Kubernetes YAMLなど）。手続き的（Imperative）アプローチは「この手順でこれをやれ」と順番に指示します（Ansible・シェルスクリプトなど）。現代では宣言的アプローチが主流です。

IaCの最大のメリットは再現性と冪等性（べきとうせい）です。同じコードを何度実行しても同じ結果になる（冪等）ため、「うっかり二重に設定してしまう」ミスが起きません。また、環境をコードで表現することで、開発・ステージング・本番を同一の定義から作れます。

IaCツールの比較

ツール	アプローチ	主な用途	特徴
Terraform	宣言的	クラウドリソース作成	マルチクラウド対応。HCL言語で記述
Ansible	手続き的（冪等性あり）	サーバー設定・ミドルウェア管理	エージェント不要。YAML（Playbook）で記述
Pulumi	宣言的	クラウドリソース作成	Python・TypeScript等の汎用言語で記述
AWS CDK	宣言的	AWSリソース作成	TypeScript/Pythonでインフラを定義。CloudFormationに変換
Kubernetes YAML	宣言的	コンテナ管理	Kubernetesリソースの望ましい状態を定義

歴史と背景

2006年：AWSがEC2を公開。APIでサーバーを作れるようになり、IaCの素地が生まれる
2011年：Puppet・ChefなどのConfiguration Managementツールが普及し、IaCの考え方が広まる
2012年：Ansibleが公開。エージェント不要・YAML記述でIaCの敷居が下がる
2014年：HashiCorpがTerraformを公開。宣言的なインフラプロビジョニングがスタンダードに
2016年〜：Kubernetes YAMLによるコンテナ管理がIaCの一形態として定着
2019年〜：PulumiやAWS CDKにより「プログラミング言語でインフラを書く」アプローチが登場

IaCの宣言的アプローチのイメージ

# Terraform例：AWSにEC2インスタンスを1台作る宣言
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.micro"

  tags = {
    Name = "WebServer"
    Env  = "production"
  }
}

# → terraform apply を実行すると：
#   - まだ存在しなければ → 作成する
#   - すでに同じ状態なら → 何もしない（冪等性）
#   - 変更があれば → 差分だけ更新する

規格・RFC番号	内容
OpenTOFU	HashiCorp LicenseからフォークされたTerraformのOSS実装（CNCF Sandbox）
TOSCA v2.0	クラウドアプリケーションのポータブルな定義言語（OASIS標準）

IaC（Infrastructure as Code）あいえーしー・いんふらすとらくちゃーあずこーど

IaC（Infrastructure as Code）とは

IaCツールの比較

歴史と背景

IaCの宣言的アプローチのイメージ

関連する規格・RFC

関連用語