IaC（インフラのコード化）
サーバーやデータベースを手作業ではなく『コードで宣言』して自動で構築する考え方。主要ツールを世界地図と早見表で中立に見くらべます
IaC は、インフラの完成形をレシピのようにコードへ書き、自動で組み上げるやり方です。ツールは『どのクラウドでも使える横断系』と『その会社専用の純正系』の 2 系統で押さえます。
- 同じコードから同じ環境を何度でも再現できる
- 変更が差分として残り、レビューできる
- 手作業の打ち間違い・設定漏れが減る
IaC ツールにはどんな系統がある？
考え方はシンプルでも、ツールの名前は Terraform、CDK、Ansible…と次々に出てきて面食らいます。実は『誰が作り、どこまで面倒を見るか』で系統がはっきり分かれており、枝ごとに眺めれば初見のツールにも居場所を与えられます。
各トピックをクリックすると、その内容の説明がここに表示されます。
この図をテキストで読む
マインドマップ「IaC ツールの世界地図」。中心トピック「IaC ツール」から 4 本の枝が広がる。 【トピック】 - IaC ツール（インフラのコード化） - マルチクラウド（横断）（1つの道具で各クラウドへ） - Terraform（専用言語 HCL・事実上の標準） - OpenTofu（Terraform 互換の OSS） - Pulumi（普段の言語で書く） - クラウド純正（その会社専用・利用は無料） - AWS - CloudFormation（YAML/JSON で宣言） - AWS CDK（普段の言語 → CFn に変換） - AWS SAM（サーバーレス特化） - Azure - Bicep（専用DSL・新規の第一候補） - GCP は例外（純正の宣言的IaCを終了） - 構成管理（作った後の中身を整える） - Ansible（YAML・Terraform と併用） - 周辺・特化（用途を絞ったツール） - Crossplane（Kubernetes を司令塔に） - Serverless Framework（サーバーレス向け老舗） - Infrastructure Manager（GCP のマネージド Terraform） 【要約】 - Terraform、OpenTofu をまとめて「書き方はほぼ同じ」 【関連】 - GCP は例外 ⇢ Terraform（公式が第一推奨） - AWS CDK ⇢ Pulumi（普段の言語で書く仲間） 【流れ】 - 系統を順に読む: IaC ツール → マルチクラウド（横断） → クラウド純正 → 構成管理 → 周辺・特化
特徴はどこを見てくらべる？
8 つも並ぶと、どれも同じに見えてきます。ただ、選びで効くのは機能の数ではなく性格の違いです。性格は提供元の出自やライセンスにもにじむので、観点を固定して横に並べると、自社との相性が浮かび上がります。
主要8ツールを特徴でくらべる
気になるセルはクリックで説明が出ます →
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。5列 × 8行。 【列】 1. 記述方法（言語・形式） 2. アプローチ（宣言的/命令的） 3. 対応範囲（横断/単一） 4. 提供元・ライセンス（誰の・どんな条件） 5. 向いている用途（どんなとき） 【比較】（観点ごとに） ■ Terraform - 記述方法: 専用言語 HCL / JSON でも書ける - アプローチ: 宣言的 / 完成形を書く - 対応範囲: クラウド横断 / AWS/Azure/GCP ほか多数 - 提供元・ライセンス: HashiCorp（IBM傘下） / v1.6〜は商用寄りBUSL - 向いている用途: 横断IaCの定番 / 事実上の業界標準 ■ OpenTofu - 記述方法: HCL（Terraform と同じ） - アプローチ: 宣言的 / Terraform と同手順 - 対応範囲: クラウド横断 / 同じ部品が動く - 提供元・ライセンス: Linux Foundation / OSS / MPL 2.0 を維持 - 向いている用途: OSSで使い続けたい人 / Terraform 互換の代替 ■ Pulumi - 記述方法: 普段の言語 / TS/Python/Go/C#/Java - アプローチ: 宣言的（コードで記述） / 結果は望ましい状態へ - 対応範囲: クラウド横断 / 300超の対応先 - 提供元・ライセンス: Pulumi 社 / OSS / 中核は Apache 2.0 - 向いている用途: 開発者の道具を活かす / 条件分岐・部品化に強い ■ Ansible - 記述方法: YAML（playbook） - アプローチ: 手順を書く寄り / 設定の維持にも使う - 対応範囲: 横断・構成管理寄り / 常駐ソフト不要で接続 - 提供元・ライセンス: Red Hat（IBM傘下） / OSS（GPLv3） - 向いている用途: 作った後の中身を設定 / Terraform と併用 ■ CloudFormation - 記述方法: YAML / JSON テンプレート - アプローチ: 宣言的 / 順序は自動で解決 - 対応範囲: AWS 専用 - 提供元・ライセンス: AWS 純正サービス / OSSでない・利用は無料 - 向いている用途: AWSをコードで管理 / 読める静的記述 ■ AWS CDK - 記述方法: 普段の言語 / TS/Python/Java/C#/Go - アプローチ: 命令的に書ける / 最後は宣言的成果物へ - 対応範囲: AWS 専用 / 土台は CloudFormation - 提供元・ライセンス: AWS / OSS / Apache 2.0 - 向いている用途: 慣れた言語でAWS構築 / 定型を部品にまとめる ■ AWS SAM - 記述方法: YAML（CFnの短縮形） / SAMテンプレート - アプローチ: 宣言的 / デプロイ時CFnへ展開 - 対応範囲: AWS 専用 / サーバーレス特化 - 提供元・ライセンス: AWS / OSS / Apache 2.0・利用は無料 - 向いている用途: AWSのサーバーレス / Lambda/API を手早く ■ Azure Bicep - 記述方法: 専用言語 Bicep / ARMのJSONより簡潔 - アプローチ: 宣言的 / 台帳ファイル不要 - 対応範囲: Azure 専用 - 提供元・ライセンス: Microsoft / OSS / MIT・利用は無料 - 向いている用途: Azure新規IaCの推奨 / 読みやすいDSL
クラウドとの相性はどう見る？
最後の決め手は『いま使っているクラウドで困らないか』です。適応度は対称ではなく、クラウド側の事情も三者三様 ── 純正が充実した所もあれば、横断ツールを本流に据えた所もあります。乗り換えや併用の余地まで含めて選びます。
AWS / GCP / Azure / マルチクラウドへの適応度
各セルをクリックすると、その意味や詳しい説明がここに表示されます。
この図をテキストで読む
比較表。4列 × 8行。 【列】 1. AWS（Amazon） 2. GCP（Google Cloud） 3. Azure（Microsoft） 4. マルチクラウド（横断・その他） 【比較】（観点ごとに） ■ Terraform - AWS: ◎ 最大規模で成熟 / 対応が最も厚い - GCP: ◎ Googleが第一推奨 / 実質の純正本流 - Azure: ◎ 公式提供で網羅 - マルチクラウド: ◎ 横断の事実上標準 / 乗り換えに強い ■ OpenTofu - AWS: ◎ 同じ部品が動く / Terraform 互換 - GCP: ◎ Terraform と同等 - Azure: ◎ Terraform と同等 - マルチクラウド: ◎ 互換の横断 / OSSのまま横断 ■ Pulumi - AWS: ◎ 主要を広く対応 - GCP: ○ 広く対応 - Azure: ○ 広く対応 - マルチクラウド: ◎ 1言語で横断 / 普段の言語で ■ Ansible - AWS: ○ 立上げ＋設定 / 構成管理が本領 - GCP: ○ 同様に対応 - Azure: ○ 同様に対応 - マルチクラウド: ○ 構成管理で横断 / 作る側と併用 ■ CloudFormation - AWS: ◎ AWS純正の土台 / 深く噛み合う - GCP: — 対象外 - Azure: — 対象外 - マルチクラウド: — AWS専用 ■ AWS CDK - AWS: ◎ 純正・CFnへ変換 / 慣れた言語で - GCP: — 対象外 - Azure: — 対象外 - マルチクラウド: — AWS専用 ■ AWS SAM - AWS: ◎ サーバーレスに特化 / Lambda/API 向け - GCP: — 対象外 - Azure: — 対象外 - マルチクラウド: — AWS専用 ■ Azure Bicep - AWS: — 対象外 - GCP: — 対象外 - Azure: ◎ Azure純正・推奨 / 新規の第一候補 - マルチクラウド: — Azure専用 【観点】 - AWS で見る: AWS - GCP で見る: GCP - Azure で見る: Azure - マルチクラウドで見る: マルチクラウド
比較を読むときの注意 ── 事実は変わります
ライセンス（Terraform は2023年に商用寄りの BUSL へ変更）、提供元（HashiCorp は IBM 傘下に）、採用率の数値は変わります。本記事は2026年前半時点の内容なので、導入前に最新の公式情報を必ず確認してください。
5SLAB は AWS CDK を使っています
5SLAB のクラウド基盤（cdk プロジェクト）は AWS 純正の CDK（TypeScript）で書いています。普段の言語で AWS インフラを定義でき、定型を部品にまとめて再利用できるのが採用理由。『AWS に集約 × 純正ツール』という選び方の具体例です。
押さえておきたい用語
- IaC（Infrastructure as Code）
- インフラを手作業ではなくコード（文章）で宣言して自動構築・管理する考え方。再現できる・履歴が残る・取り違えが減るのが利点です。
- 宣言的 / 命令的
- 「完成した姿」を書くのが宣言的（手順はツールが考える）、「こういう順で作れ」と手順を書くのが命令的（CDK の書き味）。
- プロビジョニング / 構成管理
- 前者は土台（サーバー等）を“作る”こと、後者は作った後の“中身（設定・ソフト）を整える”こと。前者は Terraform 等、後者は Ansible が得意で併用されます。
- HCL / DSL
- 特定用途に特化した小さな記述言語。Terraform / OpenTofu の HCL、Azure の Bicep が代表例です。Bicep は裏で ARM の JSON に自動変換されます。
- 状態（state）/ ドリフト
- state は「今どこに何を作ったか」の台帳（Terraform 系はファイルで持つ）。ドリフトは、コードと実際のクラウドの状態がズレることです。
- OSS / BUSL
- OSS は誰でも自由に使えるライセンス。BUSL は “source-available” の商用寄りライセンスで、競合 SaaS 提供などに制限があります。
ここから先へ
この解説とつながりのあるページ