AnsibleとTerraformの使い分け：プロビジョニングと設定管理の境界線
TL;DR
- Terraformはインフラの「箱」を作り、Ansibleは箱の「中身」を設定する — これが両者の役割分担の核心です。
- Terraformは仮想サーバーやネットワークといったリソースを宣言的に定義し、作成・変更・削除する「プロビジョニング」を担当します。
- Ansibleはできあがったサーバーに対して、OSの初期設定・ミドルウェアのインストール・アプリのデプロイといった「設定管理」を担当します。
- 現場では対立させず、Terraformでサーバーを作った直後にAnsibleで中身を設定する、という順序で併用するのが一般的です。
- 迷ったら「今すぐクラウド上にリソースを増やしたいのか」「すでにあるサーバーの中身を整えたいのか」で入口を決めます。
Terraformとは — インフラをコードで宣言する
Terraformは、HashiCorpが開発するInfrastructure as Code（IaC）ツールです。公式ドキュメントでは「クラウドおよびオンプレミスのリソースを安全かつ効率的に構築・変更・バージョン管理できるIaCツール」と説明されており、仮想サーバーやストレージ、ネットワークといった低レイヤーのリソースから、DNSレコードやSaaSの設定といった高レイヤーのリソースまで扱える点が特徴です。
Terraformの動作はWrite → Plan → Applyという3段階のワークフローで進みます。
- Write — HCL（HashiCorp Configuration Language）という設定言語で、作りたいインフラの「あるべき状態」を記述する
- Plan — 現在の状態と設定ファイルを比較し、「何を作成・変更・削除するか」の実行計画を提示する
- Apply — 承認後、その計画どおりにインフラへ変更を適用する
この「あるべき状態」を先に書いておく書き方を宣言的（declarative）と呼びます。手順を1つずつ命令するのではなく、最終形だけを書けば、Terraformが現状との差分を計算して必要な操作を組み立ててくれる、という考え方です。
さらにTerraformは、実際のインフラの状態をステートファイルという形で記録し、これを「環境の正としての記録」として扱います。次回実行時はこのステートファイルと設定ファイルを突き合わせて差分を検出するため、同じコードを何度実行しても意図しない重複作成が起きにくい仕組みです。クラウドやSaaSとのやり取りは「プロバイダ」と呼ばれるプラグイン経由で行われ、Terraform Registryには数千種類のプロバイダが公開されています。AWS・Azure・GCPはもちろん、CloudflareやDatadogのような外部SaaSまで、同じHCLの書き方で扱えるのが強みです。
Ansibleとは — 設定を人が読めるYAMLで自動化する
Ansibleは、Red Hat（IBM傘下）が開発を主導するオープンソースの自動化ツールです。公式ドキュメントは、Ansibleの設計原則として次の4つを挙げています。
- Agent-less（エージェントレス） — 対象サーバーに専用ソフトウェアを追加インストールする必要がなく、SSHと既存のOS認証情報だけで動く
- Simplicity（シンプルさ） — YAML形式の「プレイブック」で、ドキュメントのように読めるコードを書ける
- Scalability and flexibility（拡張性） — モジュール構造により、幅広いOS・クラウド・ネットワーク機器に対応する
- Idempotence and predictability（冪等性と予測可能性） — プレイブックが示す状態にすでになっている場合、何度実行しても余計な変更を加えない
Ansibleの中心となるのがプレイブックです。プレイブックにはサーバーの「あるべき状態」をYAMLで記述し、Ansibleがその状態に近づくよう対象サーバーへ処理を実行します。たとえば「Nginxがインストールされていること」「サービスが起動していること」といった状態を宣言すると、すでにその状態であれば何もせず、そうでなければ必要な操作だけを行います。この性質が「冪等性（idempotency）」と呼ばれるもので、同じプレイブックを何度流しても安全という信頼性の土台になっています。
実行の仕組みはTerraformとは異なり、AnsibleはコントロールノードからSSH経由で対象サーバーに接続し、都度モジュールを送り込んで実行するプッシュ型です。ステートファイルのような永続的な状態管理は持たず、実行のたびに対象サーバーの現状を確認しながら処理します。
役割の境界線 — プロビジョニング vs 設定管理
両者はしばしば「IaCツール」として並べて語られますが、対象とするレイヤーと得意分野は明確に異なります。
| 観点 | Terraform | Ansible |
|---|---|---|
| 主な役割 | インフラのプロビジョニング（箱を作る） | 設定管理（箱の中身を整える） |
| 得意なレイヤー | クラウドリソース・ネットワーク・DNS・SaaS設定 | OS・ミドルウェア・アプリのデプロイ |
| 設定言語 | HCL（宣言的） | YAML（プレイブック） |
| 実行方式 | ステートファイルと設定を比較して差分適用 | SSH経由でモジュールを都度実行（プッシュ型） |
| 対象サーバーへのエージェント | 不要（APIやSSH経由でプロバイダが操作） | 不要（エージェントレス、SSHで直接接続） |
| 繰り返し実行の安全性 | ステートファイルによる差分管理 | モジュールの冪等性による |
| 典型的な対象 | 仮想マシン・VPC・ロードバランサー・DNSレコード | パッケージインストール・設定ファイル配布・サービス起動 |
境界線を一言でまとめると、「リソースの有無・数・接続構成を決めるのがTerraform、リソースの中で動くソフトウェアの状態を決めるのがAnsible」ということになります。Terraformで作った仮想マシンにTerraform以外の手段で変更を加えると、ステートファイルと実際の構成にズレが生じるため、Terraformの管理対象はTerraformだけで完結させるのが基本です。OSの中身の管理は、その役割分担のもとでAnsibleに委ねます。
併用パターン — Terraformでサーバーを作り、Ansibleで設定する
実務でよく見る構成は、Terraformでインフラを作成した直後に、Ansibleで中身を設定するという順序の組み合わせです。HashiCorp自身も、Terraformによる「Day 0のプロビジョニング作業（VMのセットアップ完了まで）」から、Ansibleが担う「Day 1・Day 2の設定・運用管理タスク」への引き継ぎを明確な連携パターンとして説明しています。
典型的な流れは次のようになります。
- Terraformでサーバーを作成する — クラウド上に仮想マシンやセキュリティグループ、ロードバランサーを
applyする - 作成したサーバーのIPアドレスをAnsibleのインベントリに渡す — TerraformのOutput（出力値）をインベントリファイルに反映する、あるいはCI/CDのスクリプトで橋渡しする
- Ansibleでプレイブックを実行する — OSの初期設定、ミドルウェアのインストール、設定ファイルの配布、サービスの起動を行う
この連携は、GitHub ActionsなどのCIツール上でTerraformのapplyとAnsibleのansible-playbook実行を順番に呼び出すスクリプトとして組むケースが多く見られます。サーバー構築の土台部分はTerraform入門：AWSとConoHa VPSのインフラをコード化する最初の一歩で扱っているので、まずインフラ層のコード化から着手したい場合はあわせて参照してください。
なお、Terraformにはlocal-execプロビジョナーのように、リソース作成直後にローカルコマンドを実行してAnsibleを直接呼び出す方法もありますが、多くの実務者はこの結合を最小限にとどめ、「Terraformはインフラ管理に専念し、設定管理はAnsible側のワークフローに任せる」形で責務を分離しています。責務が混ざると、トラブル時の切り分けが難しくなるためです。
どちらから始めるべきかの判断基準
両方を一度に導入しようとすると混乱しやすいため、次の基準で入口を決めることをおすすめします。
今の悩みが「サーバーの数・構成」ならTerraformから
- クラウド上のサーバーを手動でポチポチ作っていて、構成が属人化している
- 環境（開発・検証・本番）ごとに構成がズレてしまう
- サーバーを増やす・減らす作業をコードで再現したい
この場合は、まずTerraformでインフラの構成をコード化するところから始めます。サーバーの台数や接続関係を先にコードで固めておかないと、後からAnsibleで設定管理を導入しても「そもそも何が何台あるか」が曖昧なままになってしまいます。
今の悩みが「サーバーの中身の設定」ならAnsibleから
- サーバーはすでに用意されていて、手作業でのミドルウェア設定や手順書運用に限界を感じている
- 複数台のサーバーに同じ設定を反映する作業に時間がかかっている
- 設定変更の手順が個人の記憶やExcel手順書に依存している
この場合は、既存のサーバー群に対してAnsibleのプレイブックを整備するところから着手するのが近道です。Terraformを後から入れて既存インフラをコード管理下に置くよりも、先に「中身の設定」を自動化するほうが早く効果を実感できます。
両方の悩みが同時にあるなら、小さく併用から
新規プロジェクトでゼロから構築する場合は、最初から「Terraformで箱を作り、Ansibleで中身を設定する」という併用パターンを想定して設計すると手戻りが少なくなります。IaC導入そのものでつまずきやすいポイントについてはIaC導入の壁：中小企業が脱落する3つのポイントにまとめているので、導入前の見積もりに活用してください。
まとめ
TerraformとAnsibleは競合するツールではなく、インフラの「箱」を作るプロビジョニング層と箱の「中身」を整える設定管理層という、担当するレイヤーが異なるツールです。実務では対立させず、Terraformでサーバーを作成した直後にAnsibleで設定を流し込む順序の併用が定石です。導入の入口に迷ったら、「サーバーの数・構成」に悩んでいるならTerraformから、「サーバーの中身の設定」に悩んでいるならAnsibleから着手し、両方の悩みが同時にあるなら最初から併用を前提に設計するとよいでしょう。