Terraform graphで依存グラフを可視化する：Associate/Pro向け 実務と試験の押さえどころ

terraform graphは、現在の構成や計画に基づく依存関係をDOT言語で出力し、Graphvizなどで画像化できる公式機能です。

試験では、依存解決の概念、-typeや-draw-cycles等のフラグの意味、可視化の活用場面が頻出です。実務では循環検出や作成/削除順序の検証に使います。

terraform graphの基礎

terraform graphは、Terraformが解決したリソース間の依存グラフをDOT形式で標準出力に書き出します。Graphvizのdotコマンドにパイプすれば、PNGやSVGの図として保存できます。挙動はTerraformの安定した基本機能に属し、CLIから再現性高く利用できます。

グラフは「作る順序」「壊す順序」「循環の有無」などの把握に有効です。大規模コードベースでは全体像の要点把握に役立ち、モジュール設計やdepends_onの必要性の再検討にも使えます。

• 出力はDOT（Graphviz）で、画像化はdot -Tpngや-Tsvgなどで行う
• 実行ディレクトリの構成と状態に基づいた依存グラフを表示
• オプションでタイプ（計画/削除計画）やサイクル強調、モジュール深度を制御可能
• 巨大な構成ではノードが多くなるため、深度制限やフィルタで段階的に観察するのが現実的

最小手順（DOTをSVGに変換）

terraform graph | dot -Tsvg > graph.svg
# Graphvizが未導入なら、OSパッケージからインストール
# macOS: brew install graphviz
# Ubuntu/Debian: sudo apt-get install graphviz

依存グラフの読み方：ノードとエッジの意味

ノードは主にresource、data、module、providerなどに対応します。エッジ（有向線）は依存方向を示し、上流のノードが準備できて初めて下流のノードが評価/作成されます。dataソースは読み取り専用で、通常はリソースから参照されます。

destroy（削除）時は依存の向きが逆転します。作成時に下流だったものが、削除時の上流になるため、削除順序を確かめる際は削除向けのグラフタイプを選びます。

• resource.aws_xxx.name は管理対象リソースのノード
• data.aws_xxx.name は読み取りノードで、作成順序には関与しないが解決順序には影響
• module.mod_name はサブグラフのハブとして現れることが多い
• depends_onや参照（属性参照）でエッジが形成される

典型的な依存の流れ（作成時）

# 解釈メモ:
# - instance.web は VPC(main) に依存
# - instance.web は AMI(data) を参照
# - EIP は instance.web に依存

DOTファイルを中間生成してから閲覧する例

terraform graph -type=plan > plan.dot
dot -Tpng plan.dot -o plan.png
# 表示: open plan.png（macOS） あるいは xdg-open plan.png（Linux）

実務での使いどころ：デバッグと設計の確認

作成や変更が想定どおりの順序になっていないと感じたら、まずグラフで依存を可視化します。明示的なdepends_onが不足していたり、属性参照が間接的な依存を作っているケースを発見できます。

循環依存が疑われる場合はサイクル強調を有効にし、問題の最小再現の単位までモジュール深度を絞って観察します。変更規模が大きいときは、まず上位モジュールの構造だけを見るのが効率的です。

• 循環検出: -draw-cycles で疑わしい辺を強調
• モジュールの展開制御: -module-depth=N（0は全展開、数値で段階表示）
• 削除順序の事前確認: -type=plan-destroy
• レビュー支援: CIでSVGをアーティファクト化し、PRごとに比較

循環強調とモジュール深度の例

terraform graph -draw-cycles -module-depth=1 | dot -Tsvg > shallow.svg
terraform graph -draw-cycles -module-depth=0 | dot -Tsvg > full.svg
# shallow.svg で俯瞰し、必要な箇所だけ full.svg を見る運用が現実的

出力の加工とオプション比較

出力はDOTなので、Graphvizでレイアウトや形式を選べます。可読性を重視するならSVGを推奨します。拡大・検索が容易で、レビュー用の差分確認にも向きます。

グラフのタイプや補助フラグで、用途に合わせた可視化に切り替えます。削除順序の確認や循環の検出、段階的なモジュール展開などを組み合わせるのが実務的です。オプションの正確なラインアップや既定値はTerraformのバージョンにより変わる可能性があるため、使用中のバージョンの公式ドキュメントを都度確認してください。

• SVGは拡大・テキスト検索が可能でレビューに便利
• PNGは一枚画像で共有しやすいが拡大に弱い
• 大規模構成では-typeと-module-depthの併用が有効

形式の切替とレビュー向け出力

# SVGで高解像度出力
terraform graph -type=plan | dot -Tsvg > plan.svg

# 削除計画の確認用
terraform graph -type=plan-destroy | dot -Tpng > destroy.png

# CIでアーティファクト化（例）
terraform graph -module-depth=1 | dot -Tsvg > overview.svg

資格試験（Associate/Pro）での出題ポイント

Associateでは、依存解決の基本（明示的depends_onと暗黙の属性参照）、graphコマンドの目的、Graphvizによる可視化の流れが出やすいです。-draw-cyclesの意味を言い当てられること、出力がDOTであることも基本です。

Professionalでは、モジュール化や大規模構成での可視化方針、削除計画の検証、CI/CDパイプラインでのグラフ活用など、実務的な運用設計が問われやすくなります。

• graphは計画や構成に基づく依存可視化であって、実リソースのライブトポロジ図ではない
• 出力はDOT（テキスト）。画像はGraphvizで生成する
• 循環依存の特定には-draw-cyclesを使う
• 削除順序の確認には-type=plan-destroyを使う

試験で押さえるべき基本コマンド

terraform graph -type=plan | dot -Tsvg > plan.svg
terraform graph -type=plan-destroy | dot -Tsvg > destroy.svg
terraform graph -draw-cycles -module-depth=1 | dot -Tsvg > cycles.svg

ありがちな落とし穴とベストプラクティス

非常に大きな構成では、フル展開のグラフは可読性が低下します。まずは-module-depthで階層を抑え、関心領域を特定したうえで深掘りするのが実践的です。

dataソースは作成対象ではないため、順序の根拠というよりは評価依存のヒントとして読みます。削除順序の把握には、必ずplan-destroy相当のグラフを確認しましょう。

バージョンにより細部の出力表現や既定値が変わることがあります。フラグや出力の意味解釈は、使用中のTerraformの公式ドキュメントで適宜確認してください。

• 巨大グラフは段階的に観察（深度制御やサブセットでの検証）
• 循環は設計改善で解消（依存の切り出しや分離デプロイ）
• 画像はSVG推奨（拡大・検索・レビュー差分が容易）
• 自動化：CIでgraph出力をアーティファクト化し、PRで必ず確認

対象を絞るテクニック（例）

# モジュール直下までで俯瞰
terraform graph -module-depth=1 | dot -Tsvg > overview.svg

# テキストDOTをgrepで簡易フィルタ（例: computeモジュール）
terraform graph > all.dot
grep -E "module.compute|cluster|aws_instance" all.dot > focus.dot
# 注意: 正規表現フィルタは簡易的。正式なフィルタ機構ではない

問題で確認

よくある質問