Terraformの`depends_on`地獄から脱却せよ：なぜ「明示的な依存」があなたのコードを殺すのか
こんにちは。インフラエンジニアの皆さん。
クラウドの海を泳いでいると、一度は遭遇するはずです。「なぜかリソースが作成されない」「修正するたびに依存関係でエラーが出る」。そんな時、安易に`depends_on`を書いて解決した気になっていませんか？
残念ですが、それは「負債」の入り口です。今日は、なぜ`depends_on`がアンチパターンなのか、そしてどうすればTerraformのグラフ理論を味方につけて、疎結合で堅牢なIaCを実現できるのか。その極意を伝授します。
—
1. なぜ`depends_on`は「劇薬」なのか
Terraformは、コード内に記述されたリソース間の参照（暗黙的な依存関係）を解析し、自動的に実行順序を決定するグラフエンジンを持っています。
例えば、`aws_instance`の`subnet_id`に`aws_subnet.main.id`を渡せば、Terraformは「サブネットが先、インスタンスが後」という順序を自動で理解します。
ここに無理やり`depends_on`を差し込むとどうなるか：
1. 並列実行の阻害: 本来は並列に作成できるはずのリソースが数珠つなぎになり、デプロイ時間が劇的に悪化します。
2. リファクタリングの硬直化: 一度書き込むと、将来的にコードの構成を変更する際、この「鎖」が足枷となり、修正が不可能に近い状態（依存の迷宮）に陥ります。
3. 計画の非効率化: Terraformが最適な実行計画を立てられなくなり、無駄なリフレッシュや計画の不整合を招きます。
結論：`depends_on`は、Terraformが依存関係を検知できない「例外的なケース」以外では、使ってはいけません。
—
2. Terraformの「HelloWorld」：暗黙的な依存を体験する
まずは基本の復習です。依存関係を「記述する」のではなく「自然に発生させる」設計を学びましょう。
ステップ1: インストール（サクッと終わらせる）
macOSならHomebrew一択です。
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
ステップ2: 基礎セットアップとコード
ディレクトリを作成し、`main.tf`を書きます。
プロバイダー設定
provider “aws” {
region = “ap-northeast-1”
}
VPCの作成
resource “aws_vpc” “main” {
cidr_block = “10.0.0.0/16”
}
サブネットはVPCに依存（暗黙的に決定）
resource “aws_subnet” “web” {
vpc_id = aws_vpc.main.id # これが暗黙の依存関係！
cidr_block = “10.0.1.0/24”
}
このコードでは、`aws_subnet`の中で`aws_vpc.main.id`を参照しています。これだけでTerraformは「VPCができてからサブネットを作る」と判断します。`depends_on`なんて不要ですよね？
—
3. リファクタリング：依存の「鎖」を断ち切る
もし皆さんのコードにこんな記述があったら要注意です。
アンチパターン
resource “aws_instance” “web” {
…
depends_on = [aws_vpc.main, aws_subnet.web] # 不必要！
}
どう改善するか？
もしリソース間で直接的なID参照ができない場合（例：IAMポリシーとインスタンスなど）、「データソース」を活用して参照を注入するか、「モジュール間インターフェース」を定義してください。
- データソースを使う: 他のモジュールが作成したリソース情報を `data` ブロックで取得し、参照を繋ぐ。
- 出力を活用する: `output` で必要なIDをエクスポートし、呼び出し元でそれを入力変数として渡す。
これだけで、コードは「モジュール」として綺麗に分離され、疎結合になります。
—
4. 現場で震えるほど役立つ「設計の極意」
1. リソースは小さく分割せよ: 1つのファイルにすべてを書くと依存関係が複雑化します。`vpc.tf`, `ec2.tf`, `iam.tf`のように役割で分けましょう。
2. グラフを可視化せよ: 依存関係がわからなくなったら、以下のコマンドを打ってください。
terraform graph | dot -Tpng > graph.png
これで現在の依存関係が画像として出力されます。絡まり合った蜘蛛の巣が見えたら、それがあなたの修正ポイントです。
3. 「順序」ではなく「関係」を定義せよ: 「AのあとにBを作る」ではなく「BはAの情報を必要としている」という視点でコードを書く。この思考の転換こそが、プロのインフラエンジニアへの第一歩です。
—
最後に：自動化とは「予測可能性」である
IaCの目的は、単にサーバーを立てることではありません。「何度実行しても、常に同じ状態が再現される（冪等性）」ことを担保することです。
`depends_on`に頼る設計は、この予測可能性を損ないます。Terraformという強力なエンジンを信じ、そのグラフ理論に身を委ねてみてください。最初は少し難しく感じるかもしれませんが、疎結合なコードを書き終えたとき、あなたは本当の意味でクラウドを「支配」していることに気づくはずです。
それでは、素晴らしい自動化ライフを！