Infrastructure as Codeの導入を検討するエンジニアなら、一度はこの疑問にぶつかるはずです。
どちらもIaCを実現するツールですが、設計思想も得意領域もまったく異なります。「なんとなく流行っているから」という理由で選ぶと、現場で使い物にならない構成になってしまいます。
この記事では、TerraformとAnsibleの違いを設計思想レベルから整理し、「どの場面でどちらを選ぶべきか」の判断軸を実務目線で解説します。
この記事のポイント
・TerraformはインフラのプロビジョニングにAnsibleは設定管理に向く
・「宣言型」と「手続き型」の設計思想の違いが選定の核心になる
・現場では両ツールを役割分担させて併用するのが主流
・迷ったときはリソースの「作成/削除」ならTerraform、「設定/変更」ならAnsibleが目安
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
TerraformとAnsibleはどう違うのか
まず根本的な設計思想の違いを押さえましょう。Terraformは「宣言型」のプロビジョニングツールです。「どういう状態にしたいか」をコードで定義すると、現在の状態と比較して必要な操作を自動で判断して実行します。
Ansibleは「手続き型」の構成管理ツールです。「どういう操作をするか」を順番に記述します。べき等性（何度実行しても同じ結果になること）を意識した書き方ができますが、基本的には「このタスクをこの順番で実行する」という記述スタイルです。
この違いを具体例で見てみましょう。
Terraformでは、EC2インスタンスを1台作りたい場合、次のように書きます。
# Terraform: 「この状態を作れ」と宣言する resource "aws_instance" "web" { ami = "ami-0c55b159cbfafe1f0" instance_type = "t3.micro" tags = { Name = "web-server" } }
# Ansible: 「この操作を実行しろ」と手順を書く - name: Install Nginx hosts: webservers tasks: - name: Install nginx yum: name: nginx state: present - name: Start nginx service: name: nginx state: started enabled: yes
もう一点、重要な違いがあります。エージェントレス設計かどうかです。
・Terraform：TerraformはローカルのPC（またはCI/CDサーバー）からAPIを叩いて操作します。対象サーバーに何かをインストールする必要はありません
・Ansible：AnsibleもSSH経由でエージェントレスに動作します。ただし対象サーバーにSSHでアクセスできる必要があります
Terraformは主にクラウドプロバイダー（AWS/Azure/GCP等）のAPIを呼び出してリソースを作成・管理するのに特化しており、Ansibleはサーバーにログインして設定変更・パッケージ管理・ファイル配置を行うのに特化しています。
Terraformの得意領域：インフラのプロビジョニング
TerraformはHashiCorp社が開発したオープンソースのIaCツールです。AWSのEC2やRDS、Google CloudのCompute Engine、AzureのVirtual Machinesなど、複数クラウドのリソースをまとめて管理できる点が強みです。1. クラウドリソースの作成・変更・削除
Terraformが最も輝くのは、クラウドリソースの生成から廃棄までのライフサイクル管理です。実際の業務でよく使うシナリオを挙げます。
・VPC・サブネット・セキュリティグループの設計：ネットワーク構成をコードで定義し、環境ごとに複製する
・EC2インスタンス・ELBのセット構築：Webサーバーとロードバランサーをまとめて作成する
・RDS・ElastiCache等のマネージドサービス：設定パラメータをコードで管理して再現性を確保する
・IAMロール・ポリシーの定義：権限設計をコードで管理してドリフト（手動変更による乖離）を防ぐ
Terraformの `terraform plan` コマンドは、実行前に「何が作られ、何が変更され、何が削除されるか」を表示します。これによって本番環境への意図しない変更を事前に防げます。
# terraform plan の実行例（実際の出力イメージ） $ terraform plan Terraform will perform the following actions: # aws_instance.web will be created + resource "aws_instance" "web" { + ami = "ami-0c55b159cbfafe1f0" + instance_type = "t3.micro" ... } Plan: 1 to add, 0 to change, 0 to destroy.
2. 状態管理（tfstate）による差分検出
Terraformは `terraform.tfstate` というファイルで「現在のインフラの状態」を記録しています。次回 `terraform plan` を実行するとき、このstateファイルとクラウドの実際の状態を突き合わせて差分を計算します。この仕組みにより、「コードを変更したとき、実際に何が変わるか」を明示できます。手動でインフラを変更してしまった場合も、Terraformがそのドリフトを検出してくれます。
チームで使う場合は、tfstateをS3などのリモートバックエンドに保存して共有するのが標準的な運用です。
3. モジュールによる構成の再利用
Terraformはモジュール機能を使うと、共通の構成をテンプレート化して再利用できます。たとえば「本番環境」「ステージング環境」「開発環境」で同じ構成を変数だけ変えてデプロイするような使い方が効率的にできます。Ansibleの得意領域：構成管理と設定自動化
Ansibleは Red Hat社（現IBM）が買収したオープンソースの構成管理ツールです。エージェントレスでSSH経由で動作し、YAMLで書いたPlaybookで操作を記述します。1. サーバーへのミドルウェアインストールと設定
Ansibleが真価を発揮するのは、すでに存在するサーバーに対してソフトウェアのインストールや設定変更を行う作業です。典型的なユースケースを挙げます。
・Nginx/Apache の設定ファイル配置：設定ファイルをテンプレート化して複数台に配布する
・パッケージの一括インストール：yum/apt/dnf経由でパッケージを管理する
・cronジョブの設定：定期実行ジョブを複数サーバーに一括設定する
・セキュリティパッチ適用：脆弱性対応でパッケージをアップデートする
・ユーザー・グループ管理：アカウントの作成/削除を自動化する
2. Playbookによる手順の記述と再実行
Ansibleのコアはプレイブック（Playbook）です。YAMLで書かれた手順書を実行するイメージで、IT部門の新人でも読みやすいのが特徴です。検証サーバー（RHEL 9.4）での実行例を示します。
# ansible-playbook コマンドの実行 $ ansible-playbook -i inventory.ini site.yml PLAY [Configure web servers] *** TASK [Gathering Facts] ********* ok: [192.168.1.10] TASK [Install nginx] *********** changed: [192.168.1.10] TASK [Start and enable nginx] *** changed: [192.168.1.10] PLAY RECAP ********************* 192.168.1.10 : ok=3 changed=2 unreachable=0 failed=0
3. Role分割による大規模構成管理
Ansibleはロール（Role）という機能で、タスクを機能単位に分割・整理できます。「webserver」「database」「monitoring」といったロールを定義して組み合わせることで、複雑な構成でも管理しやすい状態を保てます。IaCツール選定の判断軸：何を基準に選ぶか
「結局どっちを使えばいいの？」という問いへの答えは、「何をしたいか」によって変わります。Terraform・Ansible 選定チェック
「クラウドでVMやネットワークを作りたい」→ Terraform
「作ったサーバーにNginxを設定したい」→ Ansible
「複数の環境を同じ構成で量産したい」→ Terraform（モジュール）
「OSのパッチを複数台に一括適用したい」→ Ansible
「インフラの状態変化を検出・修正したい」→ Terraform（plan/apply）
「設定変更をCIから自動実行したい」→ どちらも可能
| 観点 | Terraform | Ansible |
|---|---|---|
| 主な用途 | インフラリソースの作成・削除 | サーバー内の設定・ソフトウェア管理 |
| 設計思想 | 宣言型（あるべき状態を定義） | 手続き型（操作手順を記述） |
| 対象レイヤー | クラウドAPI・インフラレイヤー | OS・ミドルウェアレイヤー |
| 状態管理 | tfstateで明示的に管理 | 都度実行してべき等性で担保 |
| 学習曲線 | HCL記法の習得が必要 | YAMLで書けるため比較的入りやすい |
| マルチクラウド | プロバイダー機能で対応 | SSHが通れば基本対応可能 |
| コミュニティ | Terraform Registry | Ansible Galaxy |
逆に「Ansibleだけでクラウドリソースも管理できるのでは？」という疑問もあります。Ansibleにもクラウドモジュール（`amazon.aws`等）はあります。しかし、tfstateのような状態管理機能がないため、現在のインフラ状態と定義の差分を検出する機能はTerraformに劣ります。クラウドリソースの大規模管理はTerraformに任せるのが現場のベストプラクティスです。
＞＞ Terraform実践セミナーの詳細はこちら
併用パターン：TerraformとAnsibleを組み合わせる
現場では、TerraformとAnsibleを組み合わせて使うのが最も現実的な選択です。それぞれの得意領域を活かして役割分担します。1. 典型的な役割分担パターン
最も多い構成は「Terraformでインフラを作ってAnsibleで設定する」という2段階アプローチです。# フェーズ1: TerraformでAWSリソースを作成 terraform apply # → EC2インスタンス、VPC、セキュリティグループ等が作成される # フェーズ2: AnsibleでEC2の内部を設定 ansible-playbook -i aws_ec2.yml site.yml # → Nginx インストール、設定ファイル配置、起動設定
2. CI/CDパイプラインへの組み込み
GitHub ActionsやGitLab CI等のパイプラインでは以下のような流れが一般的です。・コードプッシュ → terraform plan で変更内容を確認
・プルリクエストマージ → terraform apply でインフラ変更を適用
・インフラ作成完了 → ansible-playbook でミドルウェア設定を実施
・設定完了 → サービス稼働確認のテストを実行
この分業体制にすることで、インフラの変更はTerraformのPRで管理し、アプリケーション設定の変更はAnsibleのPlaybookで管理するという明確な責任分離ができます。
3. Pulumi・CDKとの比較でTerraformを選ぶ理由
近年はPulumi（Python/TypeScript等の汎用言語でインフラ定義）やAWS CDK（TypeScript/Python等でAWSリソースを定義）も注目されています。これらとTerraformを比較するポイントとしては次が挙げられます。・マルチクラウド対応：TerraformはAWS/Azure/GCPを同一ツールで管理できる。PulumiもマルチクラウドだがCDKはAWS専用
・HCLの習得コスト：TerraformのHCLはDSL（ドメイン固有言語）のため学習が必要だが、慣れるとシンプル
・エコシステムの成熟度：Terraform Registryには豊富なプロバイダー・モジュールが揃っており、現場での採用実績が最も多い
よくある質問と落とし穴
Q1. AnsibleにはPlaybookがあるのに、なぜTerraformが必要なの？
Ansibleのクラウドモジュールでもリソースは作れますが、状態管理がない点が大きな違いです。Terraformは `terraform.tfstate` で「今どういうリソースが存在するか」を追跡し、次回の `terraform plan` で差分を計算します。Ansibleにはこの仕組みがないため、「誰かが手動でリソースを変更した」ことを検出するのが難しくなります。Q2. TerraformとAnsibleのどちらから学べばいい？
クラウドインフラ構築を主眼に置くなら Terraform から。サーバー設定・ミドルウェア管理が中心なら Ansible から始めるのが実践的です。多くの現場ではどちらも使うため、最終的には両方の基礎を理解することを目指してください。Q3. Terraformでサーバー内の設定もやろうとしたが上手くいかない
Terraformの `remote-exec` プロビジョナーはデバッグが困難で、公式でも使用を推奨していません。「サーバー内の設定」はAnsibleに任せ、TerraformはAWSリソースの作成・削除に特化させるのが正解です。Q4. tfstateファイルをGitにコミットしてしまった
これは現場でよくある落とし穴です。tfstateにはクラウドリソースのIDや場合によっては機密情報が含まれるため、Gitには絶対にコミットしてはいけません。 `.gitignore` に `*.tfstate` と `*.tfstate.backup` を追加し、S3等のリモートバックエンドで管理するのが正解です。Q5. Ansibleの実行が途中で失敗したが、どこまで適用されたかわからない
Ansibleのタスクは失敗した時点で停止します（`ignore_errors: yes` を設定しない限り）。どこまで適用されたかはAnsibleのRun Summaryを確認します。また、タスクはべき等性を持つように書いておけば、再実行しても問題ありません。本記事のまとめ
TerraformとAnsibleの違いと選定判断軸を整理しました。| やりたいこと | 推奨ツール |
|---|---|
| クラウドリソース（EC2/VPC/RDS等）を作成する | Terraform |
| サーバーにNginx/Apacheを設定する | Ansible |
| 環境（本番/ステージング/開発）を量産する | Terraform（モジュール） |
| OSパッチを複数台に一括適用する | Ansible |
| インフラの変更内容を事前に確認する | Terraform（plan） |
| 設定ファイルを複数サーバーに配布する | Ansible |
| クラウド＋OS設定を一気通貫で自動化する | Terraform + Ansible（併用） |
この使い分けを理解すると、IaCの全体像が見えてきます。次のステップとして、Terraformのtfstate管理やAnsibleのRole設計といった「現場で崩れない構成管理」のスキルを深めていきましょう。
・Terraformのtfstate管理とS3バックエンド設定｜チーム運用で壊さないための基礎
・AnsibleでAWS上にNginx・PHP・MariaDBを自動構築する実践手順
・Terraformのmoduleとfor_each・countで構成を再利用する設計パターン
・Terraform入門｜Infrastructure as CodeでAWSインフラをコード化する基礎ハンズオン
＞＞ Terraform実践セミナーの詳細はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：Terraformのmoduleとfor_each・countで構成を再利用する設計パターン
- この記事の属するカテゴリ：Terraformへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。
登録無料・いつでも解除できます