Terraform の tfstate とは？Ansible との比較から学ぶ状態管理の仕組みとその利点
🧠 AI生成のドキュメント
本文書はAI生成のドキュメントです。AIとの対話でできた、役に立つ情報をブログ形式に変換して蓄積していきます。
📕 概要
インフラ構成管理ツールを使っていると、Terraform の tfstate ファイルの存在に戸惑う方も多いのではないでしょうか？
一方、Ansible のような構成管理ツールには、そのような状態ファイルは存在しません。
この記事では、Terraform の tfstate の仕組みや役割を、Ansible との違いを交えて解説し、なぜ Terraform がこのような設計になっているのか、どんなメリットがあるのかをわかりやすく紹介します。
目次
-
tfstateとは何か？ - Ansible に状態ファイルがない理由
-
tfstateの仕組みと重要な役割 - 状態管理がもたらす利点
- Terraform と Ansible の使い分け
1. tfstate とは何か？
Terraform における tfstate ファイルとは、Terraform が管理しているインフラの状態情報を記録するファイルです。
このファイルには、作成されたリソースの情報（ID、属性、依存関係など）が JSON 形式で保存されます。
Terraform はこの tfstate を参照しながら、インフラを「設定ファイルで定義された望ましい状態」に保つように操作を行います。
2. Ansible に状態ファイルがない理由
Terraform には tfstate ファイルがありますが、Ansible にはそれに相当する「状態ファイル」が存在しません。
それは「Ansible には必要ないから」です。ではなぜ必要ないのか？
それは、Terraform と Ansible のリソースの管理方法の違いに起因します。
✅ 冪等性の担保方法が違う
| ツール | 冪等性の担保方法 |
|---|---|
| Terraform |
tfstate を使って「最後に知っている状態」と「設定ファイルの望ましい状態」を比較 |
| Ansible | モジュール内部で毎回ターゲットの状態を直接チェックして判断 |
Ansible は、状態を保存せずにその場で確認することで冪等性を実現しています。
つまり、**「状態を保存しておく必要がない」**という前提で設計されています。
✅ 削除のアプローチが違う
Terraform
- 設定ファイルからリソース定義を削除すると、
apply時にその差分を見て リソースを削除 します。 - このためには、「前に何を作ったか（＝状態）」を覚えておく必要がある。
Ansible
- 削除は
state: absentのように明示的に記述されたときだけ実行される。 - つまり、何が前にあったかは覚えておく必要がない。実行時に毎回「今あるか？」だけ見ればいい。
✅ 動的に生成される値の扱いが違う
Terraform
- 多くのクラウドリソースでは、作成後に 動的に生成される属性（ID、IPアドレス、DNS名など）が存在します。
- これらは設定ファイルに書かれておらず、
tfstateに記録して再利用する必要があります。 - 例：一度作成した VPC の ID を後続のリソースで使う
Ansible
- 基本的に**「状態の変化が目的」ではなく「状態の結果が目的」**。
- IP アドレスや ID を管理するよりも、「設定ファイルを配置する」「パッケージをインストールする」など、操作結果そのものに意味がある。
- 動的値が必要な場合は、
registerなどで都度取得して使えば済むので、状態として保存しておく必要はない。
✅ まとめ：Ansible に状態ファイルが不要な理由
Ansible に tfstate 的な仕組みが不要なのは、単に「状態を保存しないツールだから」ではなく、ツールの役割と設計方針そのものが違うからです。
- ❌ 削除を自動で検出・実行する必要がない
- ❌ 動的な属性値を永続的に保存・再利用する必要がない
- ✅ 実行時に現在の状態を確認し、必要な操作だけを行う設計
- ✅ 冪等性はモジュール内で処理されており、ファイルとして保持しなくても担保される
だから、Ansible に状態ファイルがないのは「欠けている」のではなく、「必要がない」からなんです。
3. tfstate の仕組みと重要な役割
Terraform の tfstate ファイルには、以下のような重要な情報が含まれています：
- Terraform が管理しているリソース一覧
- 各リソースの ID や属性値（IPアドレス、DNS名など）
- リソース間の依存関係
- 前回の
apply実行時点での状態
Terraform は tfstate を使って、以下のようなことを実現しています：
| 項目 | 説明 |
|---|---|
| 差分の検出 | 現在の状態（プロバイダーから取得）と tfstate を比較して、設定との差分を特定 |
| リソースの追跡 | どのリソースが Terraform によって作成・管理されているかを把握 |
| 削除・更新 | 設定から消えたリソースを tfstate から検出し、適切に削除 |
| 動的属性の保持 | 例えば EC2 のパブリックIPなど、設定ファイルに書かれていない動的な値を保持 |
4. 状態管理がもたらす利点
Terraform が tfstate によって実現しているメリットは数多くあります。
✅ 意図した操作だけが行われる
plan によって「どこがどう変わるか」が明確に出力され、想定外の変更を防げます。
✅ 安全な削除や変更
リソース間の依存関係を tfstate で追跡するため、削除順や作成順を自動で管理できます。
✅ 再現性と一貫性
状態を明示的に管理することで、環境を何度でも正確に再構築できます（本番・ステージングの整合性確保）。
✅ 手動変更の検出
手動でリソースを変更しても、plan 実行時に差分として検出されます。
5. Terraform と Ansible の使い分け
| 項目 | Terraform | Ansible |
|---|---|---|
| 主な用途 | インフラ（VM、ネットワーク、DBなど）の管理 | サーバー構成やアプリケーション設定の管理 |
| 状態管理 |
tfstate による状態追跡 |
状態は持たず、都度確認 |
| 削除処理 | 自動でリソース削除可能（設定と tfstate に基づく） |
明示的に記述が必要（対象の状態確認は実行時） |
| 冪等性 | 差分に基づく計画的適用 | タスクベースの冪等性（都度確認） |
まとめ
Terraform の tfstate は、ただの「記録ファイル」ではありません。
それはTerraform にとっての記憶装置であり、意図したインフラ操作を正確かつ安全に実行するための土台です。
一方、Ansible のようなツールは「その場で確認しながら実行する」設計であり、状態管理が不要な設計となっています。
どちらが良い・悪いということではなく、**「何を管理したいか」**に応じて、ツールの使い分けが重要になります。
たとえば：
- インフラ全体の構築・再現性を担保したいなら Terraform
- サーバー設定やアプリのデプロイを柔軟に管理したいなら Ansible
このように、状態管理の有無とツールの設計思想の違いを理解することで、IaCツールの選定や使い分けがより明確になります。