Terraform入門｜state・module・CIの6週間学習順

クラウド資格やDockerを学んだ後、「画面操作ではなくコードで環境を作りたい」と考える人は多い。Terraformは、クラウドやオンプレミスの資源を設定ファイルで定義し、変更内容をplanで確認してから反映するInfrastructure as Code（IaC）ツールである。

ただし、HCLの文法を覚えて仮想マシンを1台作るだけでは、安全な運用にはつながらない。Terraformでは、設定コードだけでなく、実資源との対応を記録するstate、providerとmoduleのバージョン、planの確認、認証情報、CIでの権限分離まで設計する必要がある。

結論として、最初はクラウド料金が発生しない組み込みリソースで、init → fmt → validate → plan → apply → destroyを練習する。次に学習用クラウド資源、remote state、module、test、CIへ進む。6週間で、第三者がplanを確認し、安全に再現・撤去できるIaC成果物を完成させたい。

この記事の要点

HCLより先に、設定・state・実資源の関係を理解する
terraform planで差分を確認し、apply前に作成・変更・削除を読む
stateと保存済みplanには機密情報が含まれ得るため、Gitへ登録しない
moduleは重複が見えてから作り、単一resourceの薄いラッパーを増やさない
CIではfmt・validate・test・planを先に自動化し、applyは権限と承認を分ける

Terraformを始める前の前提

前提	確認課題	不足する場合
クラウド基礎	リージョン、ネットワーク、IAM、料金の基本を説明できる	クラウド基礎資格の範囲を先に学ぶ
CLI	作業ディレクトリ、環境変数、終了コードを扱える	Linux・PowerShellの基本を補う
Git	branch、diff、pull requestで変更を確認できる	小さな設定変更をPRにする
安全性	学習用アカウント、予算通知、削除手順がある	本番・会社環境で演習しない

AWSとAzureのどちらから始めるか迷う場合は、「AWS Cloud PractitionerとAZ-900はどっち？料金・有効期限・学習順【2026年】」で、先に身につけるクラウド基礎を比較できる。

手作業とIaCの違い

観点	管理画面・手作業	Terraform
変更内容	操作履歴や担当者の記憶に依存しやすい	コード差分とplanで確認する
再現	手順書を読みながら繰り返す	同じ構成を変数付きで再利用しやすい
レビュー	実施前の確認が難しい場合がある	PRとplanで事前確認できる
状態管理	実環境が正本になりやすい	設定・state・実資源の整合を管理する
注意	操作ミスと手順差	誤ったコードを再現性高く適用する危険もある

IaCは自動的に安全になる仕組みではない。レビュー、権限、state保護、テストが弱いと、誤った削除や過剰権限も同じ手順で反映される。コード化と運用設計を一緒に学ぶ。

最初はクラウドを使わず基本フローを学ぶ

Terraformには、外部providerなしで利用できる組み込みのterraform_dataresourceがある。実際のインフラは作らないが、resourceのアドレス、state、plan、置換、outputを確認できる。

variable "environment" {
  description = "Learning environment name"
  type        = string
  default     = "dev"

  validation {
    condition     = contains(["dev", "test"], var.environment)
    error_message = "environment must be dev or test"
  }
}

resource "terraform_data" "learning" {
  input = {
    environment = var.environment
    owner       = "learning-team"
  }
}

output "learning_resource" {
  description = "Stored learning values"
  value       = terraform_data.learning.output
}

terraform init
terraform fmt -check
terraform validate
terraform plan -out=plan.bin
terraform show plan.bin
terraform apply plan.bin
terraform state list
terraform output
terraform destroy

この段階で、変数を変えたときのplan、apply後のstate、設定を削除したときのdestroy予定を読む。applyを急がず、planの記号とresourceアドレスを説明できる状態を目指す。

基本ワークフローは7段階

1 Write
HCL

→

2 Init
初期化

→

3 Format
整形

→

4 Validate
整合

→

5 Plan
差分

→

6 Apply
反映

→

7 Review
確認・撤去

コマンド	確認できること	確認できないこと
`fmt`	標準的な書式へ整える	設計・権限・料金の妥当性
`validate`	構文と設定内部の整合性	remote stateやprovider API上の実在性
`plan`	現在の設定・state・実資源との差分	将来の同時変更後も同じ結果になる保証
`apply`	planに基づく作成・変更・削除	アプリ動作や業務要件の完全な確認
`test`	出力・条件・moduleの期待値	本番同等の負荷・運用を自動的に保証すること

stateは設定コードより慎重に扱う

Terraformはstateを使い、設定内のresourceアドレスと実世界の資源を対応付ける。stateを失う、誤って上書きする、複数人が同時更新すると、意図しない作成・変更・削除につながる可能性がある。

対象	Gitへ登録	理由
`*.tf`	する	設定コードと変更履歴の正本
`.terraform.lock.hcl`	する	providerの選択版とchecksumを共有
`terraform.tfstate*`	しない	機密値を含み得て、Gitはstate lockingを提供しない
保存済みplan	しない	設定・入力値・機密値を平文で含み得る
`.terraform/`	しない	providerとmoduleの取得物。initで再作成する
秘密を含む`*.tfvars`	しない	認証情報や個人情報の漏えいを防ぐ

一人で学ぶ初期段階はlocal stateでもよいが、共同作業や継続運用では、暗号化、アクセス制御、バックアップ、監査、state lockingに対応するremote backendを検討する。backendによってlockingの対応は異なるため、公式仕様を確認する。

sensitive指定だけではstateを守れない

変数やoutputへsensitive = trueを付けるとCLI表示を隠せるが、通常は値がstateやplanへ保存される。stateの暗号化・アクセス制御と、秘密を設定ファイルへ直接書かない運用が別に必要である。

クラウド演習は最小資源・短時間で行う

組み込みリソースで基本を確認したら、学習用クラウドアカウントで、タグ、ストレージ、ネットワーク等の小さな資源へ進む。公式チュートリアルのサンプルでも料金が発生する可能性があるため、作成前に料金・リージョン・削除条件を確認する。

学習用アカウントまたはsubscriptionを本番から分離する
予算通知とタグを先に設定する
providerとTerraformの対応版を明示し、lockファイルを登録する
planで削除・置換がないか確認してからapplyする
演習終了後にdestroyし、管理画面でも残存資源と料金を確認する

コンテナとクラウド資源の役割を分けたい場合は、「Dockerはいつ学ぶ？Dockerfile・Compose・安全な4週間ロードマップ」で、アプリ実行環境とインフラ構築の違いを整理できる。

moduleは重複が見えてから作る

作業ディレクトリ内の.tfファイル全体がroot moduleになる。最初から全resourceをmodule化せず、同じ構成を複数環境で使う、入力とoutputの境界を説明できる、独立した建築概念として名前を付けられる段階で切り出す。

判断	例
module化しやすい	ネットワーク一式、監視付きアプリ基盤、標準タグ付きストレージ
まだ早い	一度しか使わない単一resourceを、そのresource名のmoduleで包む
入力	環境ごとに変える値。type、description、validationを付ける
output	呼出側が次の構成に必要とする値だけを公開する
版管理	remote moduleはsourceとversionを固定し、更新差分を確認する

moduleを深く入れ子にすると、planのresourceアドレスと変数の流れを追いにくくなる。HashiCorpはmoduleツリーを比較的平らに保ち、過剰なmodule化を避けるよう案内している。

テストは静的確認と実環境確認を分ける

層	例	費用・権限
書式	`terraform fmt -check -recursive`	クラウド資格情報不要
構成検証	`terraform init -backend=false`後の`validate`	remote stateへ接続せず実行可能
Terraform test	output、validation、module条件。provider mockも利用可能	runがapplyなら資源作成の可能性あり
plan	実環境との差分、作成・変更・削除のレビュー	通常は読取り中心のクラウド権限を検討
統合テスト	一時環境を作成し、接続・監視・削除まで確認	料金と書込み権限、確実なcleanupが必要

terraform testのrun blockは既定でapplyとして動くため、テスト名だけを見て安全と判断しない。クラウド資源を作らないテストはcommand = planやprovider mockを使い、統合テストは専用アカウントと上限を設ける。

CIではplanとapplyの権限を分ける

pull requestでは、fmt、validate、test、planを実行し、変更内容をレビューする。applyはmainへの反映後または承認済み環境で実行し、PR由来の未信頼コードへ書込み資格情報を渡さない。

terraform fmt -check -recursive
terraform init -backend=false
terraform validate
terraform test

CIで使うTerraform・provider・moduleの版を固定する
plan用とapply用のクラウド権限を分け、最小権限にする
長期アクセスキーをrepository secretsへ固定保存せず、対応環境ではOIDCによる短期資格情報を検討する
保存済みplanをartifactにする場合は、機密情報として閲覧範囲・保持期間を制限する
apply前に最新状態から最終planを作り直し、古いspeculative planだけで反映しない

GitHubでのbranch、PR、Actionの基本は、「GitとGitHubはどちらから学ぶ？違い・認証・4週間ロードマップ」で確認できる。

経験別の学習期間

開始時点	期間の目安	重点
クラウド・Git・CLI経験あり	6週間、週5〜7時間	state、module、test、CI、権限分離
クラウド資格を学習済み	8〜12週間、週5〜7時間	CLI、Git、IAM、ネットワーク、料金管理
クラウド未経験	先にクラウド基礎を追加	管理画面で資源の役割と依存関係を理解

当ブログの演習計画例であり、クラウド基盤の設計・運用を単独で担当できることや費用削減を保証する期間ではありません。

6週間の学習ロードマップ

週	学ぶこと	完成条件
1週	HCL、block、expression、変数、output、terraform_data	料金なしでplan・apply・destroyを説明できる
2週	provider、resource、data source、依存関係、版固定	学習用クラウド資源を一つ作成・撤去
3週	state、remote backend、locking、sensitive、drift	state保管・権限・復旧方針を1枚に整理
4週	module、入力、output、環境分離、refactoring	重複構成を一つのmoduleへ切り出す
5週	fmt、validate、terraform test、mock、統合テスト	入力・output・禁止条件を自動確認
6週	PR plan、OIDC、権限分離、apply承認、README	レビュー・反映・destroyまで再現できる成果物

成果物に残す5点

Terraformコード

変数、output、provider・module版、命名理由を整理する。

state設計

保管先、暗号化、locking、閲覧権限、バックアップを記録する。

planレビュー

作成・変更・置換・削除と料金・停止影響を確認する。

自動テスト

fmt、validate、test、PR planをCIで実行する。

README

前提、費用、認証、実行、確認、destroy、既知の制約を書く。

まとめ

TerraformはHCLの記述量を競うツールではない。設定、state、実資源の関係を理解し、planで差分を確認してからapplyする。stateとplanを機密情報として守り、重複が見えてからmodule化し、fmt・validate・test・planをCIへ載せる。最後に、apply権限と承認、destroyまで含むIaC成果物を完成させたい。