2026年5月27日
2026年5月27日
Terraformのインストールと基本的な使い方|init・plan・apply・destroyの流れを手元で試す
Terraformは、サーバーやネットワーク、DNSなどのインフラを .tf ファイルに書き、「書いた状態」と「実際の状態」の差分を計算して反映するツールです。この記事では、Windows・macOS・LinuxそれぞれへのTerraformのインストール方法と、クラウドのアカウントがなくても試せる小さな例を使って、init・plan・apply・destroy という基本の流れと、最初につまずきやすい点を説明します。
Terraformを使う前に知っておきたいこと
Terraformはバージョン1.6以降、ライセンスがオープンソースのMPLからBSL(Business Source License)に変わっています。自社のインフラ管理に使う分には一般に問題になりにくいものの、Terraformと競合する製品やサービスを作る場合には制限がかかるため、業務で使う前に利用規約を確認してください。ライセンス変更をきっかけに、Linux Foundation配下でオープンソースのまま開発が続けられている互換ツール「OpenTofu」も生まれています。コマンド名が tofu になる点を除くと基本的な使い方は近いものの、新しい機能では差が出てきているため、どちらを使うかはチームで決めておくと混乱しません。
また、HashiCorpは2025年にIBMの傘下に入り、クラウド版の「Terraform Cloud」は「HCP Terraform」という名称に変わっています(2026年10月現在)。古い記事の名称と食い違うことがあるので、手順を調べるときは公式ドキュメントを優先してください。
インストールする
Ubuntu / Debian
HashiCorpが提供するaptリポジトリを登録して入れる方法が、公式に案内されています。
sudo apt update && sudo apt install -y gnupg software-properties-common wget
wget -O- https://apt.releases.hashicorp.com/gpg | \
sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/hashicorp.list
sudo apt update && sudo apt install -y terraform
リポジトリの登録手順は変わることがあるため、うまくいかない場合は公式のインストールページの最新の手順に合わせてください。
macOS
Homebrewを使う場合は、HashiCorpのtapから入れます。
brew tap hashicorp/tap
brew install hashicorp/tap/terraform
brew install terraform とだけ打つと、ライセンス変更前の古い版や別の配布物を参照することがあるため、hashicorp/tap/terraform と明示しておくと確実性が上がります。
Windows
公式サイトから自分の環境(多くは AMD64)のzipをダウンロードし、中の terraform.exe を任意のフォルダに置いて、そのフォルダを環境変数 Path に追加します。wingetやChocolateyといったパッケージマネージャーでも入れられますが、パッケージの提供元と更新の速さはマネージャーごとに異なります。WSLを使っている場合は、WSL側のUbuntuに上記の手順で入れる方法もあります。
確認とバージョン管理
インストールできたら、ターミナルを開き直して次を実行します。
terraform -version
バージョンが表示されれば完了です。「コマンドが見つからない」と出る場合は、Pathの設定が反映されていない(ターミナルを開き直していない)ことが多いです。
複数のプロジェクトで異なるバージョンのTerraformを使う場合は、tfenv のようなバージョン切り替えツールを使うと、プロジェクトごとに版を固定できます。
最初の構成を書いて動かす
ここでは、クラウドの認証情報がなくても動く例として、手元にファイルを1つ作るだけの構成を使います。Terraformの流れを覚えるには、課金や削除の心配がないこの形が向いています。
空のディレクトリを作り、main.tf を置きます。
# main.tf
terraform {
required_version = ">= 1.6"
required_providers {
local = {
source = "hashicorp/local"
version = "~> 2.5"
}
random = {
source = "hashicorp/random"
version = "~> 3.6"
}
}
}
variable "greeting" {
type = string
description = "ファイルに書く挨拶"
default = "こんにちは"
}
resource "random_pet" "name" {
length = 2
}
resource "local_file" "hello" {
filename = "${path.module}/hello.txt"
content = "${var.greeting}, ${random_pet.name.id}\n"
}
output "file_path" {
value = local_file.hello.filename
}
ここに出てくる要素は、クラウドを扱うときも同じです。
terraformブロック:使うTerraformとプロバイダー(操作対象ごとのプラグイン)のバージョン範囲を宣言します。~> 2.5は「2.5以上、3.0未満」という意味です。resource:作りたいものです。resource "種類" "名前"の形で、local_file.helloのように参照します。variable:外から値を差し替えられる入力です。output:適用後に表示したい値です。
local_file が random_pet.name.id を参照しているため、Terraformは「先に名前を作り、それからファイルを作る」という順番を自動で判断します。依存関係を手で並べる必要がないのが特徴です。
init・plan・apply・destroy の流れ
1. init:準備する
terraform init
宣言したプロバイダーをダウンロードし、作業ディレクトリを初期化します。.terraform/ ディレクトリと .terraform.lock.hcl ファイルができます。ロックファイルには実際に選ばれたプロバイダーの版とハッシュが記録されるので、Gitに含めてチームで共有します。プロバイダーの版を上げたいときは terraform init -upgrade を使います。
2. fmt と validate:書き方を整える
terraform fmt
terraform validate
fmt はインデントなどの書式をそろえ、validate は文法や参照の誤りを確認します。どちらも実際のリソースには触れないので、保存のたびに実行してもかまいません。
3. plan:差分を読む
terraform plan -out=tfplan
「何を作り、何を変え、何を消すか」が表示されます。行頭の記号で + は作成、~ は変更、- は削除、-/+ は作り直し(削除してから作成)を表します。最終行の Plan: 2 to add, 0 to change, 0 to destroy. のような要約で、想定どおりの件数かを確かめます。
クラウドを扱うようになると、この確認が一番大事な工程になります。特に -/+(作り直し)は、サーバーやデータベースが一度消えることを意味するので、予想外に出てきたら適用を止めて原因を調べてください。
4. apply:反映する
terraform apply tfplan
-out で保存した計画を指定すると、確認したとおりの内容だけが適用されます。計画ファイルを使わずに terraform apply とだけ実行した場合は、その場で計画が作り直され、yes と入力して承認する流れになります。
適用後、ディレクトリに hello.txt ができ、出力に file_path が表示されます。もう一度 terraform plan を実行すると「変更なし(No changes)」と出るはずです。書いた状態と実際が一致しているからです。
試しに -var で値を変えて差分を見てみると、仕組みがよく分かります。
terraform plan -var 'greeting=おはよう'
local_file の内容が変わるため、ファイルの作り直しが計画されます。
5. destroy:片付ける
terraform destroy
この構成で作ったものをすべて削除します。削除される一覧が表示され、yes で実行されます。本番の構成では影響が大きいので、対象のディレクトリと環境を取り違えていないかを確認してから実行してください。
stateファイルとGitに入れないもの
apply を実行すると、terraform.tfstate というファイルができます。これは「Terraformが何を作ったか」の記録で、次回の plan はこのファイルと実際の状態を比べて差分を出します。stateにはパスワードなどの値が平文で入ることがあるため、Gitには含めません。チームで使う段階になったら、S3などのリモートに置いて共有・ロックする構成に移します。
最低限の .gitignore は次のとおりです。
.terraform/
*.tfstate
*.tfstate.*
*.tfvars
tfplan
crash.log
.terraform.lock.hcl は除外しない(コミットする)点に注意してください。*.tfvars には環境ごとの値を書くことが多いので、秘密情報を含む場合は除外し、含まない共有用の値だけを別名で管理する方法もあります。
つまずきやすいポイント
- **
initをし忘れる。** プロバイダーを追加したり、モジュールを足したりしたら、もう一度terraform initが必要です。エラーメッセージにterraform initを促す文言が出たら、まず実行してみてください。 - 作業ディレクトリを間違える。 Terraformはカレントディレクトリの
.tfファイルをすべて読み込みます。別の環境のディレクトリでapplyすると、意図しない環境が変更されます。 - 手作業で変更する。 Terraformで作ったものを管理画面から直接変えると、次回の
planで元に戻す差分が出ます。変更はコードで行う、と決めておくことが運用の前提です。
まとめ
- TerraformはBSLライセンスで提供されており、互換のオープンソース版としてOpenTofuがあります。業務で使う前にライセンスと、使うツールをチームで決めておきます。
- インストールはLinuxならHashiCorpのaptリポジトリ、macOSなら
hashicorp/tap、Windowsならzipを展開してPathに追加するのが基本です。 - 流れは
init→fmt/validate→plan→apply、片付けはdestroyです。planの要約行と-/+(作り直し)を毎回読む習慣を付けると、事故を防げます。 .terraform.lock.hclはコミットし、terraform.tfstateと.terraform/はGitに入れません。