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

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

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

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

# 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自体は最終状態ではなくアクションの順序を記述します。

# 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はステートファイルを維持し、構成を実際のリソースにマッピングします。このステートはリソースID、依存関係、メタデータを追跡します。ステートがなければ、Terraformは何が存在し何を変更すべきかを判断できません。

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

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

# 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を使用してリソース作成後にスクリプトを実行できます。Ansibleはamazon.aws.ec2_instanceのようなモジュールを通じてクラウドリソースを作成できます。しかし、各ツールをその強みの外で使用すると保守性の問題が発生します。

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

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

# 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を実行します。

# 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としてフォークし、現在は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としてマークします：

# 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のようなツールで統合テストを実行します。Ansible：ansible-lintで問題を検出し、--checkモードでドライランを実行し、Moleculeでコンテナに対してロールをテストします。

Terraform面接対策をさらに深めるには、Terraform面接質問：Infrastructure as Code完全ガイドを参照してください。Terraform基礎とAnsible構成管理モジュールでハンズオン演習を行えます。

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

2026年8月現在の安定版：

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

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

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

選択の判断基準

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

これらのツールが最新のデプロイワークフローにどのように適合するかの全体像については、CI/CDパイプライン面接質問を参照してください。

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

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