# Ansible vs Terraform 2026年完全比較: IaCとDevOps面接対策ガイド

> AnsibleとTerraformの使い分けを徹底解説。宣言的と手続き的アプローチの違い、ステート管理、OpenTofuの動向、DevOps面接で頻出する質問と回答例を紹介します。

- Published: 2026-08-22
- Updated: 2026-08-22
- Author: Anthony Fillion-Maillet
- Reading time: 5 min

---

AnsibleとTerraformの比較はDevOps面接で最も頻出するトピックの一つですが、この質問の立て方自体に誤解が含まれています。両ツールは本質的に異なる課題を解決するものです。Ansible 2.20は構成管理とアプリケーションデプロイを担当し、Terraform 1.15はインフラストラクチャリソースのプロビジョニングを担います。それぞれが得意とする領域、重複する部分、そして相互に補完し合う方法を理解することが、シニアDevOpsエンジニアとしての実力を証明する鍵となります。

> **本質的な違い**
>
> Terraformはインフラの状態を宣言的に管理します（VM、ネットワーク、データベース）。Ansibleはそのインフラ上で動作するものを手続き的に構成します（パッケージ、サービス、ファイル）。本番環境のほとんどでは両方が使用されています。

## 宣言的 vs 手続き的: 根本的な違い

Terraformは宣言的アプローチを採用しています。構成ファイルで望ましい最終状態を記述すると、Terraformがその状態に到達するために必要な変更を計算します。このアプローチは、一つの単位として作成、変更、または破棄する必要があるインフラに適しています。

```hcl
# main.tf
resource "aws_instance" "web" {
  ami           = "ami-0c55b159cbfafe1f0"
  instance_type = "t3.medium"
  
  tags = {
    Name        = "web-server"
    Environment = "production"
  }
}

resource "aws_security_group" "web" {
  name        = "web-sg"
  description = "Allow HTTP and HTTPS"
  
  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}
```

`terraform apply`を実行すると、リソースが存在しない場合は両方を作成し、構成と一致するように更新します。変更なしで再度実行しても操作は発生しません。Terraformは構成をステートファイルと比較し、変更がないことを検出します。

Ansibleは手続き的アプローチを採用し、タスクを順番に実行します。Ansibleモジュールはしばしば冪等性を持つ（2回実行しても同じ結果になる）一方で、Playbook自体は最終状態ではなくアクションの順序を記述します。

```yaml
# webserver.yml
- name: Configure web server
  hosts: webservers
  become: true
  
  tasks:
    - name: Install nginx
      ansible.builtin.apt:
        name: nginx
        state: present
        update_cache: true
    
    - name: Copy nginx configuration
      ansible.builtin.template:
        src: nginx.conf.j2
        dest: /etc/nginx/nginx.conf
      notify: Restart nginx
    
    - name: Ensure nginx is running
      ansible.builtin.service:
        name: nginx
        state: started
        enabled: true
  
  handlers:
    - name: Restart nginx
      ansible.builtin.service:
        name: nginx
        state: restarted
```

各タスクは順番に実行されます。notify/handlerパターンは宣言的な動作を提供し、handlerはトリガーされた回数に関係なく最後に1回だけ実行されます。

## ステート管理: 面接での重要トピック

Terraformは[ステートファイル](https://developer.hashicorp.com/terraform/language/state)を維持し、構成を実際のリソースにマッピングします。このステートはリソースID、依存関係、メタデータを追跡します。ステートがなければ、Terraformは何が存在し何を変更すべきかを判断できません。

| 観点 | Terraform | Ansible |
|--------|-----------|----------|
| ステートストレージ | 必須（ローカルファイルまたはリモートバックエンド） | デフォルトでなし |
| ドリフト検出 | `terraform plan`で内蔵 | 明示的なチェックが必要 |
| リソース追跡 | ステートを通じて自動 | インベントリベース |
| ロールバック | ステートから破棄して再作成 | ネイティブなロールバックなし |

Ansibleには同等のステートファイルがありません。ターゲットシステムに接続してタスクを実行し、現在のシステム状態とモジュールの冪等性に依存します。これによりAnsibleは始めやすいですが、時間経過に伴う変更の追跡が困難になります。

面接でよく聞かれる質問の一つは、ステートファイルのセキュリティについてです。Terraformステートには機密データが含まれる可能性があります：データベースパスワード、APIキー、リソース識別子など。本番デプロイではステートをリモート（S3、Azure Blob、Terraform Cloud）に暗号化とアクセス制御付きで保存します。

```hcl
# backend.tf
terraform {
  backend "s3" {
    bucket         = "company-terraform-state"
    key            = "prod/infrastructure.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}
```

DynamoDBテーブルはロックを提供し、2人のエンジニアが同時にステートを変更することを防ぎます。

## 各ツールの使い分け

Terraformはクラウドインフラのプロビジョニングに優れています：仮想マシン、マネージドデータベース、ロードバランサー、IAMロール、VPC。リソース間の依存関係を自動的に処理し、一貫したHCL構文を通じてすべての主要クラウドプロバイダーをサポートします。

Ansibleは既存システムの構成に優れています：パッケージのインストール、ユーザー管理、アプリケーションコードのデプロイ、マルチステップデプロイのオーケストレーション。SSH（Windowsの場合はWinRM）を介して接続し、ターゲットマシンにエージェントを必要としません。

重複領域が混乱を招きます。両方ともVM上にソフトウェアをインストールできます。Terraformは[provisioners](https://developer.hashicorp.com/terraform/language/resources/provisioners/syntax)を使用してリソース作成後にスクリプトを実行できます。Ansibleは`amazon.aws.ec2_instance`のようなモジュールを通じてクラウドリソースを作成できます。しかし、各ツールをその強みの外で使用すると保守性の問題が発生します。

> **避けるべきアンチパターン**
>
> Terraform provisionerを構成管理に多用すると、脆弱なインフラになります。Provisionerは作成時にのみ実行され、その後のapplyでは実行されません。インフラにはTerraform、構成にはAnsibleを使用してください。

## 本番環境での統合ワークフロー

ほとんどの組織では両方のツールを組み合わせて使用します。Terraformがインフラをプロビジョニングし、接続詳細を出力します。Ansibleがその出力を消費してシステムを構成します。

```hcl
# outputs.tf
output "web_server_ips" {
  value       = aws_instance.web[*].private_ip
  description = "Private IPs of web servers"
}

output "db_endpoint" {
  value       = aws_rds_instance.main.endpoint
  description = "RDS endpoint for application config"
}
```

CI/CDパイプラインは最初にTerraformを実行し、出力を取得し、Ansibleインベントリを動的に生成してから、新しいインフラに対してPlaybookを実行します。

```yaml
# ansible/inventory/aws_ec2.yml
plugin: amazon.aws.aws_ec2
regions:
  - us-east-1
filters:
  tag:Environment: production
  instance-state-name: running
hostnames:
  - private-ip-address
groups:
  webservers: "'web' in tags.Role"
  databases: "'db' in tags.Role"
```

このダイナミックインベントリはAWSに直接クエリを発行し、タグに基づいてインスタンスをグループ化します。手動でのIP管理は不要です。

## OpenTofu: 情勢を変えたフォーク

HashiCorpは2023年8月にTerraformをBusiness Source License（BSL）の下で再ライセンスしました。コミュニティはTerraform 1.5を[OpenTofu](https://opentofu.org/)としてフォークし、現在はLinux Foundation傘下でホストされています。

2026年8月現在、OpenTofu 1.11.6はほとんどのTerraformワークフローのドロップイン代替として機能し続けています。同じHCL構文、同じプロバイダーエコシステム、同じステートフォーマット。OpenTofuはTerraformのオープンソースバイナリにはない機能を追加しています：ステート暗号化、provider `for_each`、早期変数評価などです。

面接対策として、ライセンスの違いを理解しておく必要があります。BSLは社内使用を許可しますが、競合製品の構築を制限します。ベンダーロックインを懸念する組織や特定のコンプライアンス要件を持つ組織は、OpenTofuのMPL 2.0ライセンスを好む場合があります。2024年12月のIBMによるHashiCorp買収は、ベンダー関係の議論に新たな変数を加えました。

## DevOps面接でよくある質問

**Q: AnsibleでTerraformを置き換えられますか？**

効果的には置き換えられません。Ansibleはクラウドリソースを作成できますが、ステート管理機能がありません。同じPlaybookを2回実行すると重複リソースが作成される可能性があります。Terraformのステートファイルは存在するものを追跡し、最小限の変更を計算します。Ansibleは得意な分野、つまり構成管理に使用してください。

**Q: Terraformでシークレットをどう扱いますか？**

シークレットをバージョン管理にコミットしないでください。環境変数、Vault統合、またはクラウドプロバイダーのシークレットマネージャーを使用します。ログに表示されないように変数をsensitiveとしてマークします：

```hcl
# variables.tf
variable "db_password" {
  type        = string
  sensitive   = true
  description = "Database password from Vault or environment"
}
```

**Q: Ansibleの冪等性とは何ですか？**

冪等な操作は、1回実行しても複数回実行しても同じ結果を生成します。`apt`モジュールと`state: present`は、パッケージがない場合はインストールし、既にインストールされている場合は何もしません。冪等なPlaybookを書くことで、繰り返し実行時の意図しない変更を防ぎます。

**Q: インフラコードをどうテストしますか？**

Terraform：`terraform validate`は構文をチェックし、`terraform plan`は変更をプレビューし、[Terratest](https://terratest.gruntwork.io/)のようなツールで統合テストを実行します。Ansible：`ansible-lint`で問題を検出し、`--check`モードでドライランを実行し、[Molecule](https://ansible.readthedocs.io/projects/molecule/)でコンテナに対してロールをテストします。

Terraform面接対策をさらに深めるには、[Terraform面接質問：Infrastructure as Code完全ガイド](/blog/devops/terraform-interview-questions-infrastructure-as-code)を参照してください。[Terraform基礎](/technologies/devops/interview-questions/terraform-basics)と[Ansible構成管理](/technologies/devops/interview-questions/ansible-configuration)モジュールでハンズオン演習を行えます。

## バージョン互換性とエコシステム

2026年8月現在の安定版：

| ツール | バージョン | リリース日 | 主な機能 |
|------|---------|--------------|-------------|
| Ansible | 2.20.5 | 2026年4月 | コレクション管理の改善 |
| Terraform | 1.15.8 | 2026年7月 | Windows ARM64サポート、convert関数 |
| OpenTofu | 1.11.6 | 2026年4月 | ステート暗号化、provider for_each |

Ansibleのコレクションアーキテクチャは、コア機能とプロバイダー固有のモジュールを分離しています。`amazon.aws`コレクションはAnsibleコアとは独立して更新を受け取ります。これはCI/CDパイプラインでのバージョン固定に重要です。

Terraformのプロバイダーバージョン管理も同様の原則に従います。ロックファイル（`terraform.lock.hcl`）により、チームメンバーとCIシステム間で一貫したプロバイダーバージョンが保証されます。

```hcl
# versions.tf
terraform {
  required_version = ">= 1.15.0"
  
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
  }
}
```

## 選択の判断基準

問題は「AnsibleかTerraformか」ではありません。問題は「どのツールがどの責務を担当するか」です。

| ユースケース | 推奨ツール |
|----------|------------------|
| VM、データベース、ネットワークのプロビジョニング | Terraform |
| OSの構成、パッケージのインストール | Ansible |
| Kubernetesリソースの管理 | TerraformまたはkubectlおよびHelm |
| アプリケーションコードのデプロイ | AnsibleまたはCI/CDネイティブ |
| IAMロールとポリシーの作成 | Terraform |
| サーバー上のユーザーアカウント管理 | Ansible |
| モニタリングインフラの構築 | Terraform（リソース作成）+ Ansible（エージェント構成） |

これらのツールが最新のデプロイワークフローにどのように適合するかの全体像については、[CI/CDパイプライン面接質問](/blog/devops/ci-cd-pipeline-interview-questions-github-actions-gitlab-ci-jenkins)を参照してください。

## シニアエンジニアが知るべきAnsibleとTerraform

- Terraformはインフラの状態を宣言的に管理し、Ansibleはシステムを手続き的に構成します。両方を組み合わせることで保守性の高いインフラが実現します。
- ステートファイルのセキュリティは重要です。Terraformステートは暗号化とロックを有効にしてリモートに保存してください。
- OpenTofuはMPLライセンスのTerraform代替を提供し、追加機能も備えています。ほとんどのワークフローで移行は簡単です。
- 冪等性は自動ではありません。繰り返し実行で一貫した結果を生成するPlaybookを書いてください。
- ダイナミックインベントリにより手動ホスト管理が不要になります。現在のインフラについてクラウドプロバイダーに直接クエリを発行します。
- バージョン固定により予期せぬ事態を防ぎます。Terraformではプロバイダーバージョンをロックし、Ansibleではコレクションバージョンを固定します。
- インフラコードのテストには異なるアプローチが必要です：変更のプレビューには`terraform plan`、Ansibleのドライランには`--check`モード、両方に統合テストフレームワークを使用します。

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/ja/blog/devops/ansible-vs-terraform-2026-infrastructure-as-code-devops-interview