「IaC ツールの選び方」のタイトルバナー。左に汎化系(Terraform / OpenTofu / Pulumi / Crossplane)、右に各クラウド純正(CloudFormation・CDK / Bicep / Config Connector)を配し、中央に『特化 ⇄ 汎化』の軸と 6 ユースケースの分岐を示したモチーフ。

この記事の要点

  1. IaC ツールは数が多くて迷いますが、選ぶ軸は実は 1 本です。「特化(各クラウド純正)か、汎化(マルチクラウド)か」 をまず決め、あとは自分のユースケースに当てはめるだけです。
  2. 対象読者: 個人開発者・小チームで 「今日、どのツールで書き始めるか」 を決めたい人が主な対象です。組織での標準化を考える実務担当の方にも、判断軸としてそのまま使えます。前提知識は不要です。
  3. 得られる成果: 候補マップ(汎化系 と純正の全体像)+ 2026 年に新規採用を避けるべき終了予定ツール の明示 + Terraform か OpenTofu か の実務判断 + 6 ユースケース別の意思決定ガイド。
  4. 扱わないこと(別記事へ): 各ツールの文法・チュートリアル(公式 docs へ)/ コンテナや VM の隔離(仮想化とサンドボックス入門)/ 依存ライセンスの判定各論(OSS ライセンスの見極め)/ 依存の可視化(SBOM ツールの選び方)/ ネットワーク設計(企業ネットワークの仕組み)。

Key Points (for international readers)

  1. There are many IaC tools, but the deciding axis is really just one: specialized (each cloud's native tooling) vs. generalized (multi-cloud). Decide that first, then map it to your use case.
  2. Who this is for: individual developers and small teams deciding "which tool to start writing with today" (primary), and practitioners weighing org-wide standardization.
  3. What you get: a candidate map, an explicit list of tools to avoid adopting in 2026 (reaching end-of-support), a practical Terraform-vs-OpenTofu decision, and a six-use-case decision guide.
  4. The international forces actually moving tool choice — OSS license/governance shifts, EU digital sovereignty, compliance-driven auditability — are centered in the English edition, a companion piece rather than a translation.

執筆時点: 2026-06 / 対象: 個人開発者・小チーム + 組織の標準化担当 / last_updated: 2026-06-12 更新履歴: 2026-06-12 初版

本記事は教材であり、ライセンス判断・最新仕様の代わりではない

IaC ツールは ライセンス・バージョン・サポート終了(EoS)日が変化しやすい 領域です。本記事の日付・バージョン・ライセンス表記はいずれも 2026-06 時点 の整理であり、内容の正確性・完全性・最新性を保証しません。とくに ライセンスが自分の使い方で問題ないかの最終判断(商用利用・競合製品の定義など)は、各ツールの ライセンス全文と公式アナウンス を確認し、必要に応じて法務に相談してください。導入前には各公式 Releases / Docs で最新状態を必ず確認してください。本記事の情報は「現状有姿(AS IS)」で提供され、利用した結果生じたいかなる損害についても執筆者および YATA-NODE は責任を負いません。

本シリーズの位置づけ: 本記事は「インフラを どのツールでコード化するか」の選び方です。何をデプロイするかの基盤である 仮想化とサンドボックス入門 や、依存の見える化 SBOM ツールの選び方・OSS ライセンスの見極め と合わせて読むと、土台から運用までが一本につながります。各記事は 独立に読めます。

用語ミニ解説(はじめての方へ):

  • IaC(Infrastructure as Code): サーバー・ネットワーク・データベースなどのインフラ構成を、画面のクリック操作でなく コード(設定ファイル)で宣言 し、同じ環境を何度でも再現できるようにする手法。
  • 宣言的(declarative): 「こうなっていてほしい最終状態」を書くと、ツールが現状との差分を埋める方式。手順を 1 つずつ書く命令的(imperative)と対比されます。
  • state(状態): ツールが「今どのリソースを管理しているか」を記録するファイル。Terraform 系では自前管理が必要で、純正ツールはクラウド側が持つことが多いです。
  • Provider / プラグイン: AWS や Azure など各サービスを操作するための拡張。汎化ツールは Provider を足してマルチクラウドに対応します。
  • OSS / 純正: OSS = 誰でも使えるオープンソース。純正 = AWS / Azure / GCP がそれぞれ提供する専用ツール。
  • BSL(Business Source License): OSI 非承認の「ソース公開だが利用に条件が付く」ライセンス。Terraform が 2023 年に採用し、フォーク(OSS ライセンスの見極め で詳述)の発端になりました。
  • (Domain-Specific Language。特定用途向けに設計された記述言語。ここではインフラ構成を書くための専用言語を指す)。
  • (Cloud Development Kit。汎用プログラミング言語でインフラを記述し、テンプレートに変換する仕組み。例: AWS CDK)。
  • フォーク(fork。既存の OSS のコードを分岐させ、別の独立した開発系統を作ること)。
  • ベンダー(vendor。製品・サービスを提供する供給元の企業。「ベンダ」とも表記)。

ツールは多いが、選ぶ軸は「特化 vs 汎化」の 1 本

先に結論です。IaC ツールは十数種類あって圧倒されますが、最初に決めるべき軸は 1 本だけ です。それが 「特化(各クラウド純正)か、汎化(マルチクラウド)か」。ここさえ決まれば、残りは自分のユースケースへの当てはめになります。

IaC を使う理由は、構成を コードで宣言して同じ環境を再現でき、レビューや差分管理ができる ことにあります。ここまでは全ツール共通です。違いが出るのは「1 つのクラウドに深く寄せるか、複数クラウドを 1 つの言語でまたぐか」という一点で、これが特化と汎化の分かれ目です。

特化(クラウド純正)と汎化(マルチクラウド)のスペクトラム。左端に CloudFormation・ARM・SAM、中央に CDK・Bicep・Config Connector、右端に Terraform・OpenTofu・Pulumi・Crossplane を配置し、下部に特化/汎化それぞれのメリット・デメリットを対比した図。
  • 特化(純正)の強み: ベンダーの 新サービスへ最速で対応(純正が最初に対応する)、ネイティブ機能をフルに使える、state 管理をクラウド側が持ってくれる、ツール本体は無料。弱みは 単一クラウドに縛られる こと(他クラウドへ持っていけない)。
  • 汎化系の強み: AWS / Azure / GCP その他を 1 つの言語でまたげる、巨大なエコシステム、HCL や TypeScript など 汎用スキルが転用 できる。弱みは 新サービス対応が後追い(Provider 開発が数週〜数ヶ月遅れる)で、state を自前運用する手間が要ること。

判断の本質はシンプルです。単一クラウドで完結し、そのベンダーのフルパワーを使いたいなら特化。複数クラウドを使う / 将来の移行余地を残したい / 人材プールを広く取りたいなら汎化。そして現実には、両者を レイヤごとに使い分けるハイブリッド が最も多くなります(具体策は最後のユースケース別ガイドで示します)。

候補マップと「2026 年は新規採用を避けるツール」

主要な候補を、特化 / 汎化で整理すると次のようになります(ライセンスは 2026-06 時点)。

  • 汎化(マルチクラウド)系: Terraform(HCL / 1.1)、OpenTofu(HCL / 2.0、Terraform フォーク)、Pulumi(TS・Python・Go 等 / Apache 2.0)、Crossplane(Kubernetes ネイティブ / Apache 2.0)。
  • AWS 純正: CloudFormation(最古典)、CDK(プログラミング言語で書き CloudFormation に変換)、SAM(サーバレス特化)。
  • Azure 純正: ARM Template(JSON、現役だが移行推奨)、Bicep(現代の標準 DSL)、AVM(Azure 公式の再利用モジュール集)。
  • GCP 純正: Config Connector(Kubernetes 経由)、Infrastructure Manager(中身は Terraform を Google がマネージド提供)。GCP は純正が弱く、Google 自身が IaC に Terraform を推奨(Infrastructure Manager も内部は Terraform)しているのが特徴です。

各カードは提供元(汎化系 / 各クラウド純正)でまとめています。同じカード内に複数のツールが並ぶのは、抽象度(高水準の言語か、低水準のテンプレートか)や位置づけ(現役か、移行推奨か)が異なる選択肢が併存するためです。例えば Azure 純正には、低水準でやや冗長な ARM Template と、それを簡潔に書ける高水準の Bicep が共存します。どれを使うかは、後半のユースケース別ガイドで絞り込みます。

IaC 候補のカテゴリマップ。4 ゾーン(汎化系 / AWS 純正 / Azure 純正 / GCP 純正)に各ツールをカードで配置し、ライセンスと公開年を併記。サポート終了予定のツールには取り消し線を引いた図。

ここで 古い比較記事には載っていない、最も重要な実務情報 を先に出します。2026 年時点で新規採用を避けるべき「終了予定 / 終了済」のツール です。古い記事を見てこれらを選んでしまうと、出発点から負債を抱えます。

  • AWS Copilot CLI — 2026-06-12 にサポート終了(EoS)。これ以降は更新・セキュリティパッチ・サポートが提供されません。新規利用は推奨されず、コンテナアプリの構築は他の手段への移行が案内されています(後継の詳細は公式アナウンスを確認)。
  • GCP Cloud Deployment Manager — 2026-03-31 でサポート終了。後継として Google は Infrastructure Manager(Terraform ベース) への移行を公式に推奨しています。
  • cdktf(CDK for Terraform) — 2025-12-10 に HashiCorp が公式に非推奨化(deprecation)。言語で IaC を書きたい場合は後述の Pulumi を検討します。

日付・バージョンは陳腐化が速い

上記はいずれも 2026-06 時点の整理です。IaC はリリースとアナウンスの頻度が高いため、導入前に各公式アナウンス / Releases を必ず確認 してください。本記事は「告知された事実」を起点に書いており、確定日や状況は公式一次情報が優先します。

Terraform か OpenTofu か — 経緯より「自分はどちらか」

汎化系で最初に迷うのが、Terraform と OpenTofu のどちらか です。経緯はコンパクトに押さえ、判断に直結させます。

2023-08-10、HashiCorp は Terraform を MPL 2.0(OSS)から BSL 1.1 へ変更 しました。これに反発したコミュニティが OpenTofu をフォークし、Linux Foundation 傘下 のプロジェクトとして 2024 年初頭に GA。文法(HCL)は Terraform 互換です。その後 2025-02-27 に IBM が HashiCorp の買収を完了 しましたが、Terraform の BSL は 2026-06 時点で据え置き で、緩和の公式声明は出ていません。

実務上の判断は、難しく考えず次の 2 点で足ります。

  • OSS の純度を最優先 / BSL のリスクを避けたい → OpenTofu。財団保有でライセンスを単一企業が変えられない構造が安心材料です(ただし本体が MPL 2.0 でも、利用する Provider やモジュールは個別のライセンスに従う点は別途確認します)。
  • 既存の HashiCorp 契約がある / Terraform Cloud(HCP)を使いたい / エコシステムの厚みを取りたい → Terraform。なお BSL が制限するのは「Terraform と競合する製品を作って提供する」ような用途で、通常の自社インフラ管理(個人利用・社内利用)は BSL でも問題ありません。
  • どちらも HCL は同じ で移行のハードルは比較的低めですが、Provider の既定解決先(レジストリ)が異なる点だけ把握しておきます。

主要ツールを 5 つの軸で俯瞰すると、強み・弱みの輪郭がつかめます(◎=最強 / ○=良好 / △=混合 / ✕=限定的、2026-06 時点)。

ツールライセンスマルチクラウド新サービス対応学習コスト
Terraform / OpenTofuBSL 1.1 / MPL 2.0◎△(Provider 後追い)中(HCL)
PulumiApache 2.0◎△低(TS/Py/Go)
CrossplaneApache 2.0◎△中(K8s 前提)
CloudFormationAWS✕(AWS 専用)◎(最速級)中〜高(冗長)
CDKApache 2.0✕(AWS 専用)○低(言語ベース)
BicepMIT✕(Azure 専用)◎低(IntelliSense 充実)

6 ユースケースで選ぶ — 今日どれで書き始めるか

ここまでの軸を、「自分のケース」に当てはめるだけ の意思決定ガイドにまとめます。多くの人が当てはまる順に並べました。

6 ユースケース別の IaC ツール推奨マッピング。マルチクラウド→OpenTofu、単一 AWS サーバレス→SAM+CDK、単一 Azure→Bicep+AVM、単一 GCP→Terraform、言語で書きたい→Pulumi、Kubernetes 中心→Crossplane を分岐図で示し、底部に『ハイブリッドが現実的』と注記した図。
  1. 複数クラウドを使う(2 社以上) → OpenTofu(または Terraform)。BSL を避けたいなら OpenTofu、HashiCorp 契約やエコシステム重視なら Terraform。1 つの言語で全体を標準化できます。
  2. AWS だけ、サーバレス中心 → SAM + CDK。Lambda / API Gateway 周りは SAM、VPC・IAM など周辺は CDK。CloudFormation を直接書くより生産性が上がります。
  3. Azure だけ → Bicep + AVM。Bicep は ARM Template の事実上の上位互換で、AVM(検証済みモジュール)で土台を固められます。既存 ARM があれば段階移行できます。
  4. GCP だけ → Terraform / OpenTofu + Google provider。GCP は純正が弱く、Google 自身が Terraform を推奨。Kubernetes 中心なら Config Connector も選べます。
  5. プログラミング言語で書きたい(TS / Python / Go) → Pulumi(AWS 限定なら CDK)。既存スキルを活かせ、テストや抽象化がしやすいのが利点です。
  6. Kubernetes 中心で GitOps と統合したい → Crossplane。CNCF の成熟プロジェクトで、ArgoCD / Flux と相性が良く、各クラウドのリソースを Kubernetes の流儀で扱えます。

実務はハイブリッドが現実解

1 つに統一できれば理想ですが、現場は レイヤごとの適材適所 が普通です。例えば「Azure 全体は Bicep で書き、Cloudflare 連携だけ Terraform」「AWS のサーバレスは SAM、それ以外は CDK」「BSL リスクを避けるため OpenTofu に統一」といった組み合わせです。最初から完璧な統一を目指さず、主戦場のクラウドに最適なツールを軸に、はみ出す部分だけ汎化系で補う のが続けやすい形です。

まとめ — 3 ステップで決まる

IaC ツール選びは、次の 3 ステップに圧縮できます。

  1. 軸を 1 本に絞る: まず「特化(クラウド純正)か、汎化(マルチクラウド)か」を決める。単一クラウド完結なら特化、複数クラウド / 移行余地なら汎化。
  2. 終了・終了予定ツールを外す: 2026-06 時点で AWS Copilot CLI(EoS 2026-06-12)/ GCP Cloud Deployment Manager(2026-03-31 終了)/ cdktf(2025-12-10 非推奨) は新規採用しない。古い記事に引きずられないこと。
  3. ユースケースに当てはめる: 上の 6 分岐から自分のケースを選び、まず 1 つで書き始める。完璧な統一より、レイヤごとのハイブリッドで十分です。

「どれが最強か」ではなく「自分のクラウドと使い方にどれが合うか」が問いです。迷ったら、マルチクラウドなら OpenTofu、AWS なら CDK、Azure なら Bicep から始めれば大きく外すことはありません。土台となる 仮想化とサンドボックス入門、依存管理の SBOM ツールの選び方 と OSS ライセンスの見極め も合わせてどうぞ。

References(一次ソース、2026-06 時点)