Terraform vs Ansible vs 手動構築 — 使い分けの設計判断

インフラ構築の現場でTerraform・Ansible・手動のどれを選ぶべきか迷ったとき、「どれが最も優れているか」という問い方は判断を迷走させる。正しく問うべきは「何を自動化し、何を手動に残し、2つのツールをどこで役割分担させるか」という設計の線引きだ。各ツールは固有の守備範囲を持っており、用途を無視した選定は後工程で大きな負債になる。この記事では3者の役割の違いと、場面ごとの選定基準・よくある落とし穴を設計視点で整理する。

「どれが最強か」ではなく「どこで使い分けるか」

比較の問いを立て直す

ツール選定の議論が停滞する現場では、「TerraformとAnsibleのどちらが優れているか」という問い方が繰り返されることが多い。しかしこの問いには答えがない。なぜなら両者は互いに競合するのではなく、インフラライフサイクルの異なる層を担うよう設計されているからだ。Terraformはクラウドリソースの存在と設定を宣言的に管理し、AnsibleはOS上のソフトウェア状態を手続き的に収束させる。対象が違う以上、「どちらが強いか」という比較は最初から成立しない。問いを「何を解かせるか」に切り替えることで、ようやく選定の視界が開ける。

設計判断が迷走する本当の理由

選定が迷走する背景には、構築フェーズと運用フェーズを区別しないまま議論が進むという構造的な問題がある。クラウドリソースのプロビジョニング（VPC・EC2・RDSの払い出し）と、OS上のソフトウェア設定（Nginxのインストール・設定ファイルの配布）は、性質がまったく異なる作業だ。前者は宣言的な状態管理が有効で、後者はサーバー内部への手続き的な収束が必要になる。ここを混在させると、Terraformでパッケージ管理を試みたり、AnsibleでVPCを定義しようとするような用途外の使い方が生まれ、ツールの限界に早々に突き当たる。

判断の起点は「変化の性質」の分類

3者を選ぶ起点として有効なのは、「変化の頻度と範囲」を事前に問うことだ。インフラの構成（どのリソースを何台持つか）は変わりにくく、ソフトウェアの設定（バージョン・設定値）は月に数回変わりうる。一時的な操作（証明書の更新・データ移行）は一度しか発生しない。この3種類の変化に対して、それぞれ最適なツールが異なる。変化の性質を先に分類しておくことで、「とりあえずTerraform」「とりあえずAnsible」というツール先行の選定ミスを防げる。

3者の役割の違いを設計視点で整理する

Terraformが担う「インフラの状態宣言」

TerraformはHCL（HashiCorp Configuration Language）でインフラの「あるべき状態」を宣言し、現状との差分を検出して自動適用するツールだ。中核となる概念がstateファイルで、実際のインフラとコード定義の差分をここで追跡する。これにより、「どのリソースをどの設定で持つべきか」という問いに対して冪等な操作が実現できる。設計上の最大の特徴は、インフラをコードとして履歴管理しGitでレビューできる点だ。3環境以上のクラウドインフラを同一定義から生成したり、本番環境の構成をステージングに複製する作業が、単一のコードベースで統制できるようになる。

Ansibleが担う「ソフトウェア状態の収束」

Ansibleはエージェントレスで動作し、SSHを通じて対象サーバーへ手続きを実行するツールだ。PlaybookというYAML定義に「何をインストールし、どのファイルをどう配置し、どのサービスを起動するか」を記述し、順次実行する。Terraformとの本質的な違いは、Ansibleがサーバーの「内側」を変える点にある。OSレベルのパッケージ管理・設定ファイルの配布・サービスの起動順序など、Terraformが関与しない領域を担う。20〜50台のサーバーに同じ設定を一斉適用するような作業では、Ansibleの真価が最も発揮される。

手動構築が担う「探索と緊急対応」

手動構築にも、自動化では代替しにくい役割がある。新しい構成を試す探索フェーズや、ツールでは表現しにくい一回限りの操作では、手動のほうが素直に動く。またTerraformのstate管理が壊れた際に単体リソースを直接修正するといった、自動化の補修作業でも手動操作が必要になる場面は多い。重要なのは「手動を残すこと」と「手動に依存すること」を分けて考えることだ。探索や緊急対応として手動を許容する設計と、定常運用を手動に任せる設計は、まったく異なるリスクプロファイルを持っている。

比較表：再現性・学習コスト・変更容易性・向く規模

項目	Terraform	Ansible	手動構築
再現性	高い（state管理で冪等）	中程度（モジュール選択に依存）	低い（人・手順書に依存）
学習コスト	高め（HCL・state・モジュール設計）	中程度（YAML・Playbookの記法）	ほぼなし
変更容易性	計画的変更に強い（plan→apply）	設定収束が柔軟・再実行可能	即時対応可能だが追跡困難
向く規模	3環境以上・多リソース	10〜数十台のサーバー群	1〜数台・探索フェーズ
主な対象層	クラウドリソース（IaaS層）	OS・ミドルウェア（ソフトウェア層）	一時的・探索的な操作全般

再現性と変更容易性のトレードオフを読む

再現性が高いということは、定義から同一環境を何度でも生成できるという意味だ。Terraformはこの点で最も強く、stateファイルと定義ファイルが一致している限り同じ環境を繰り返し再生成できる。ただし、これは「変更の追跡が厳格になる」という裏返しでもある。誰かが手動でリソースを変更した場合、次回のplan実行で差分が検出され、意図しない上書きが発生するリスクがある。変更容易性という観点ではAnsibleのほうが軽く、Playbookを書き換えて再実行するだけで設定を収束させられる。設計段階でどちらを優先するかを明確にしておかないと、運用フェーズに入ってから判断が揺れる。

学習コストを現実的に見積もる

Terraformの学習コストはAnsibleより一般的に高い。HCLの構文に加え、stateの概念・モジュール設計・リモートバックエンドの設定・workspaceによる環境分離など、理解すべき概念が多い。実際の構築現場では、Terraformを単独で実用水準まで引き上げるには実践込みで2〜3か月程度を要するという声が多い。AnsibleはYAMLベースで記述し、Linux操作に慣れたエンジニアであれば数週間で基本的なPlaybook作成が可能になるケースが多い。学習コストを過小評価したまま導入を進めると、ツールを持て余した状態で本番構築に臨む羽目になる。

Terraformが効く場面・過剰になる場面

Terraformが真価を発揮する条件

Terraformが最も効果を発揮するのは、複数環境（開発・ステージング・本番）を共通の定義から統一管理したい場面だ。同じVPC構成・セキュリティグループ・サブネット設計を3環境以上に展開する場合、手動や個別スクリプトでは環境間のパラメータ差異が必ず発生する。Terraformのモジュール機能を使えば、環境間の差分だけを変数で切り出し、共通のインフラ定義を再利用できる。また、インフラ変更をGitのPRレビューを経てapplyするというGitOpsワークフローを実現したい場合にも適している。クラウドインフラを5環境以上抱えるプロジェクトでは、Terraformなしの管理は現実的に破綻しやすい。

Terraformが過剰になる場面

単一の小規模環境を一時的に構築したい場面や、プロトタイプ検証のような使い捨て用途では、Terraformは重すぎる。stateファイルの管理・バックエンドの設定・CI/CDとの統合など、付随する整備工数がかかり、「1台のサーバーを立てて検証する」という目的に対してコードベースの整備コストが成果を上回りやすい。また、手動で構築済みの既存環境をTerraform管理下に移行したい場合、importという作業が必要になるが、既存リソース数が多いほど工数は膨らむ。100台規模の既存サーバーをTerraform配下に移行した際、import作業だけで数週間を費やしたという話は現場では珍しくない。

落とし穴：stateの乖離と手動修正の衝突

Terraformを使い続ける現場で必ず直面するのが、stateと実際のリソースの乖離だ。誰かがコンソールから手動でリソースを変更すると、stateが実態と一致しなくなる。次回のplan実行時に意図しない変更が検出され、最悪の場合はリソースの削除・再作成が提案される。この問題への設計的な対処は2つある。1つはstate変更の操作を単一のCIパイプラインに集約し、手動のコンソール操作を組織的に禁止すること。もう1つはPolicy as Code（OPAやSentinelなど）でapply前にポリシーチェックを挟むことだ。ツールの問題ではなく、チームの運用設計の問題として扱う必要がある。

Ansibleが効く場面・Terraformとの役割分担の境界

AnsibleがTerraformより優れる領域

AnsibleがTerraformより優れているのは、「すでに稼働しているサーバーの内側を変える」操作だ。パッケージのインストール・設定ファイルの配置・デーモンの起動・ユーザー作成・cronの登録といった、OS以上の操作はTerraformの守備範囲外であり、Ansibleが担う領域になる。特にミドルウェアのバージョンアップや設定変更を複数台へ一括適用する場面で強みが出る。Nginxの設定を変更して数十台のサーバーに一斉適用し、変更差分のあったサーバーだけにリロードをかける、という細かい制御がPlaybook内で完結する点は、他のツールでは容易に代替できない。

TerraformとAnsibleの分担線をどこに引くか

2つのツールの分担線は、「リソースの作成・削除・リサイズ」をTerraformが担い、「リソース上のソフトウェア状態の管理」をAnsibleが担う、という境界が基本だ。実際の構築フローとしては、TerraformでEC2インスタンスを立て、Ansibleのダイナミックインベントリを使ってIPアドレスを自動取得し、Playbookを実行するという連携パターンが多い。落とし穴になりやすいのが、インスタンス起動時にcloud-initでAnsibleを呼び出す構成だ。Terraformがリソースを作成したタイミングとAnsibleの実行タイミングのずれが問題になりやすく、初期化の責任をどちらが持つかを設計段階で明確にしておく必要がある。

落とし穴：冪等性の誤解とコマンドモジュール

Ansibleのタスクが冪等であるというのは、正しく書かれた場合の話であり、すべてのモジュールが自動的に冪等になるわけではない。commandモジュールやshellモジュールは、同じコマンドを何度実行しても結果が冪等とは限らない。設計段階でこれを意識せずにPlaybookを組むと、2回目以降の実行で予期しない副作用が発生する。現場で「Ansibleを再実行したら設定が壊れた」という声が珍しくない理由がここにある。冪等性が保証されているモジュール（yum・apt・template・fileなど）を優先して使い、コマンド系モジュールには実行条件を明示するのが設計上の基本になる。

手動構築を残してよい／残すと危ない判断

手動を意図的に残してよい条件

手動構築を残すことが設計上合理的なケースは存在する。まず、一度しか実施しない操作だ。物理サーバーの初期セットアップ・ネットワークスイッチの初期設定・クラウドアカウントの初回払い出しなどは、自動化のコスト回収が見込めない。次に、自動化ツールのコンテキスト外にある操作だ。Terraformのproviderが未対応のリソースタイプや、APIが存在しない設定変更については、手動が現実解になる。また、構成がまだ固まっていない探索・検証フェーズも手動が適切だ。定義が確定する前にTerraformやAnsibleで先回りして書こうとすると、試行のたびにコードの大幅な書き直しが発生し、探索の速度が落ちる。

手動を残すと危ない条件

定常的に繰り返す作業・本番環境の定期変更・複数の担当者が実行する手順を手動のままにしておくことは、再現性と追跡可能性を著しく損なう。特に危ないのが「ほぼ同じ手順を複数人が担当する」状況だ。環境によって微妙に異なる手順が生まれ、担当者ごとに設定値がずれ、どの環境が正なのかが不明確になる。障害発生時に構成の実態を確認するためにサーバーへ直接入って目視確認するしかない、という状況は、手動構築の蓄積が招く典型的な問題だ。こうした環境では、稼働中のミドルウェアのバージョンさえ正確に把握できないことがある。

「とりあえず手動」が負債になる分岐点

手動構築が負債になるのは、「とりあえず」が繰り返された結果、誰も全体像を把握していない状態になったときだ。サーバーが3台程度であれば手動管理は許容範囲内だが、10台を超えたあたりから構成の把握が困難になり、30台を超えると変更の影響範囲が追えなくなるケースが多い。この段階で自動化ツールの導入を試みると、既存の手動構成をコードに起こすリバースエンジニアリングの工数が発生し、導入コストが大きく膨らむ。「あとから自動化する」が難しいのは、手動による構成が蓄積した状態ほど顕著だ。自動化の導入は台数が少ない早い段階のほうが、圧倒的にコストが低い。

小規模から始めるツール選定の順序

段階的導入の設計思想

最初から3者を組み合わせた完全自動化基盤を目指す必要はない。むしろ段階的に導入することで学習コストを分散させ、チームの習熟と構成規模に合わせてツールを加えていくアプローチが現実的だ。開始時点では「手動構築＋手順のドキュメント化」から入り、繰り返しが発生する構成管理タスクが増えた段階でAnsibleを導入し、さらに環境数が増えてマルチ環境管理の必要性が出た段階でTerraformを加える。この順序を守ることで、各ツールの導入時に学習と実践が自然に結びつき、ツールを持て余す状況を避けられる。

フェーズ別の判断チェックリスト

フェーズ1：環境数1〜2、サーバー3台以下

• 手動構築した手順を構成ドキュメントとして記録し、再現性を文書で担保する
• 繰り返し発生している手順をリスト化し、自動化の候補を特定しておく
• ツール導入は急がず、手順の標準化を優先する

フェーズ2：繰り返し作業が増えた・サーバー10台前後

• Ansibleを導入し、定常タスクをPlaybookとして管理する
• command・shellモジュールを避け、冪等性の保証されたモジュールを優先する
• 新規構築はPlaybook経由のみに限定し、手動構築との混在を防ぐ

フェーズ3：環境数3以上・マルチアカウント管理が必要

• Terraformでインフラ定義を管理し、環境間の差分を変数で切り出す
• stateをリモートバックエンド（S3＋DynamoDBなど）に移行し、ローカル管理を廃止する
• コンソールからの手動変更を禁止するルールを組織的に設ける
• TerraformとAnsibleの分担境界（プロビジョニング vs 設定管理）を明文化する

移行時の落とし穴と現実的な進め方

手動からAnsibleへの移行、またはAnsibleからTerraformの追加というステップを踏む際の落とし穴は、既存の手動構成をコードに追いつかせる「追い越し問題」だ。現在稼働中の本番環境の構成をPlaybookやTerraformコードとして書き起こしても、そのコードを既存サーバーにいきなり適用すると、差分が想定以上に大きくて現用設定を壊すリスクがある。移行の設計として有効なのは、新規に立てるサーバーから先にコード管理を適用し、既存サーバーはリプレースやバージョンアップのタイミングで順次移行することだ。全環境の一斉移行を計画すると移行作業自体が巨大なプロジェクトになり、完了前に次のリプレースが来ることもある。コードで管理される範囲を少しずつ広げていく漸進的なアプローチが、結果として最も安全で速い。