Terraformのインストール方法と初期設定を丁寧に解説

インフラをコードで管理するInfrastructure as Code（IaC）の代表的なツールとして、Terraformの名前を目にする機会が増えてきました。「導入したいけれど、最初の一歩がわからない」「公式ドキュメントが英語で不安」と感じている方も多いのではないでしょうか。本記事では、Terraformのインストールから初期設定、動作確認までを丁寧に解説します。さらに、Terraformで実際に何ができるのかを具体例とともに紹介し、実務で役立つコマンドもまとめています。これからTerraformを始める方にとって、確かな一歩目となれば幸いです。

Terraformとは何か──導入前に押さえたい基礎知識

TerraformはHashiCorp社が開発したオープンソースのIaCツールです。AWS、Google Cloud、Azureといった主要クラウドプロバイダーに対応しており、HCL（HashiCorp Configuration Language）という宣言的な記法でインフラリソースを定義できます。

筆者が初めてTerraformに触れたとき、「設定ファイルを書くだけでサーバーやネットワークが構築される」という体験に素直に驚かされました。手作業でコンソールを操作していた頃と比べると、再現性と効率の差は歴然です。

宣言的な記法とは

Terraformの特徴を理解するうえで「宣言的（Declarative）」というキーワードは外せません。宣言的とは、「こういう状態にしてほしい」とゴールだけを記述するアプローチです。対照的に、シェルスクリプトやAnsibleのような「命令的（Imperative）」なアプローチでは、「まずこれを実行して、次にあれを実行して」と手順を逐一記述します。

たとえば「S3バケットを1つ作りたい」とき、Terraformでは以下のように書きます。

resource "aws_s3_bucket" "my_bucket" {
  bucket = "my-example-bucket-2026"
}

「バケットを作成するAPIを呼ぶ」とは書きません。あるべき姿を記述するだけで、Terraformが現在の状態との差分を計算し、必要な操作を自動で行ってくれます。この仕組みのおかげで、リソースの追加だけでなく変更や削除も安全に管理できるのです。

Stateファイルの役割

Terraformはterraform.tfstateというStateファイル（状態ファイル）を生成し、管理対象リソースの現在の状態を記録します。terraform planを実行したとき、Terraformはこのファイルとコードの記述を比較して「何を作る・変える・消す」を判断します。

初学者のうちはStateファイルの存在を意識しないまま進めてしまいがちですが、チーム開発を始めると避けて通れません。筆者も最初は.tfstateファイルをGitにコミットしてしまい、機密情報が含まれることに後から気づいたことがあります。Stateファイルにはリソースの属性がそのまま記録されるため、S3やGCSなどのリモートバックエンドに保存し、ローカルには残さない運用が推奨されます。この点については、初期設定の段階から頭の片隅に置いておくとよいでしょう。

豊富なプロバイダーエコシステム

Terraformの大きな強みの一つが、プロバイダーと呼ばれるプラグインの豊富さです。2026年4月時点で、Terraform Registryには4,000を超えるプロバイダーが公開されています。主要なものだけでも、以下のように多岐にわたります。

クラウド: AWS、Google Cloud、Azure、Oracle Cloud、DigitalOcean
SaaS: GitHub、Datadog、PagerDuty、Cloudflare
データベース: MySQL、PostgreSQL、MongoDB Atlas
コンテナ: Docker、Kubernetes、Helm
その他: DNS、TLS証明書、ランダム値生成

つまり、クラウドインフラだけでなく、GitHubのリポジトリ設定やDNSレコード、監視ツールの設定まで、一つのワークフローで管理できるのです。筆者のプロジェクトでも、AWSのインフラ構築とGitHubリポジトリの権限管理を同じTerraformコードで運用しており、管理の一元化による恩恵を日々感じています。

Terraformを導入するメリット

Terraformを導入するメリットを整理すると、次のようになります。

観点	手作業による構築	Terraformによる構築
再現性	手順書に依存、属人化しやすい	コードで定義、誰でも同じ結果
変更管理	差分の把握が困難	Gitで履歴管理が可能
レビュー	スクリーンショットベース	コードレビューで品質担保
複数環境の展開	環境ごとに手動構築	変数の切替で効率的に展開
削除・復元	消し忘れによるコスト増リスク	`terraform destroy`で一括削除

この比較を見ると、チーム開発や本番運用を見据えた場合にTerraformの優位性が明確になるかもしれません。

OS別インストール手順──macOS・Windows・Linux対応

Terraformのインストール方法はOSごとに異なります。ここでは主要な3つのOSについて、それぞれ推奨する方法をまとめました。

macOSの場合

Homebrewを利用するのが最も手軽です。

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

HashiCorpの公式tapを経由することで、常に最新の安定版を取得できます。すでに古いバージョンのTerraformがインストールされている場合は、brew upgrade hashicorp/tap/terraformでアップグレードできます。

なお、Apple Silicon（M1/M2/M3/M4）搭載のMacでも同じコマンドでインストール可能です。Homebrew自体がarm64に対応しているため、Rosetta 2を意識する必要はありません。

Windowsの場合

パッケージマネージャーのChocolateyを使う方法が便利です。

choco install terraform

Chocolateyを導入していない場合は、Terraform公式サイトからZIPファイルをダウンロードし、展開したterraform.exeをPATHの通ったディレクトリに配置します。

手動でPATHを設定する場合は、以下の手順を参考にしてください。

ダウンロードしたZIPをC:\terraformなどに展開する
「システム環境変数の編集」を開く（Windowsキー → 「環境変数」で検索）
「Path」変数にC:\terraformを追加する
コマンドプロンプトまたはPowerShellを新しく開き直してからterraform versionを実行する

「環境変数を変更したのに反映されない」という声をよく聞きますが、ほとんどの場合はターミナルを開き直していないことが原因です。設定変更後は、必ず新しいウィンドウで確認しましょう。

Linuxの場合（Ubuntu/Debian）

sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor | sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
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-get update && sudo apt-get install terraform

CentOS/RHELの場合は、yumを使った手順になります。

sudo yum install -y yum-utils
sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/RHEL/hashicorp.repo
sudo yum -y install terraform

インストール後の確認

インストール後は、以下のコマンドでバージョンを確認しておきましょう。

terraform version

Terraform v1.x.xのように表示されれば成功です。最初にここでつまずくと先に進めなくなるため、PATH設定の確認は丁寧に行うことをおすすめします。

もしcommand not foundと表示された場合は、以下を順に確認してみてください。

which terraform（macOS/Linux）またはwhere terraform（Windows）でバイナリの場所を確認する
バイナリがPATHに含まれるディレクトリにあるか確認する
シェルの設定ファイル（.bashrc、.zshrcなど）を再読み込みする

tfenvでバージョン管理を導入する

実務でTerraformを使い始めると、プロジェクトごとに異なるバージョンを使い分ける場面が出てきます。筆者自身、当初はバージョン管理を軽視していたのですが、チーム内で「自分の環境では動くのに」という問題が発生し、その重要性に気づかされました。

tfenvはTerraformのバージョン管理ツールで、プロジェクト単位でバージョンを固定できます。Node.jsにおけるnvmや、Rubyにおけるrbenvと同じ発想のツールです。

tfenvの導入と基本操作

# macOSの場合
brew install tfenv

# Linuxの場合（手動インストール）
git clone https://github.com/tfutils/tfenv.git ~/.tfenv
echo 'export PATH="$HOME/.tfenv/bin:$PATH"' >> ~/.bashrc

# インストール可能なバージョンの一覧を表示
tfenv list-remote

# 特定バージョンをインストール
tfenv install 1.9.8

# 使用バージョンを切替
tfenv use 1.9.8

# 現在インストール済みのバージョン一覧を表示
tfenv list

# プロジェクトルートにバージョンを固定
echo "1.9.8" > .terraform-version

.terraform-versionファイルをリポジトリに含めておけば、チームメンバー全員が同じバージョンで作業できます。tfenvはカレントディレクトリから親ディレクトリを遡って.terraform-versionを探してくれるため、プロジェクトルートに置いておくだけで自動的にバージョンが切り替わります。小さな工夫ですが、トラブルの予防効果は大きいと実感しています。

なお、tfenvを使う場合はHomebrewで直接インストールしたTerraformとの競合に注意してください。両方がPATHに存在すると、意図しないバージョンが使われることがあります。tfenvに一本化する場合は、brew uninstall terraformで直接インストール分を削除しておくのが安全です。

Terraformでできること──クラウド構成の具体例

基礎知識を押さえたところで、「実際にTerraformで何ができるのか」を具体的なコード例で見ていきましょう。ここではAWSを例にしますが、Google CloudやAzureでも同様のアプローチが可能です。

例1: VPCとサブネットの構築

ネットワークの土台となるVPCとサブネットの定義です。

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "main-vpc"
  }
}

resource "aws_subnet" "public" {
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.1.0/24"
  availability_zone       = "ap-northeast-1a"
  map_public_ip_on_launch = true

  tags = {
    Name = "public-subnet-1a"
  }
}

aws_vpc.main.idのように、リソース間で値を参照できる点がポイントです。手作業だと「VPCを作ってIDをコピーして、サブネットの設定に貼り付けて……」という手順になりますが、Terraformではコード上の参照で自動的に依存関係が解決されます。

例2: EC2インスタンスの作成

resource "aws_instance" "web" {
  ami           = "ami-0abcdef1234567890"
  instance_type = "t3.micro"
  subnet_id     = aws_subnet.public.id

  tags = {
    Name = "web-server"
  }
}

わずか数行でEC2インスタンスが定義できます。terraform planを実行すれば、実際にリソースが作られる前に「何が起きるか」を確認できるため、意図しない変更を防げます。

例3: S3バケットとアクセスポリシー

resource "aws_s3_bucket" "assets" {
  bucket = "my-app-assets-2026"
}

resource "aws_s3_bucket_public_access_block" "assets" {
  bucket = aws_s3_bucket.assets.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

S3バケットを作成すると同時に、パブリックアクセスをブロックする設定を適用しています。セキュリティ設定をコードに含めることで、「バケットを作ったけれどアクセス制御を忘れた」という事故を防げます。

例4: 変数を使った環境の切替

Terraformではvariableブロックを使って値をパラメータ化できます。これにより、開発・ステージング・本番といった複数環境を効率的に管理できます。

variable "environment" {
  description = "デプロイ先の環境名"
  type        = string
  default     = "dev"
}

variable "instance_type" {
  description = "EC2インスタンスタイプ"
  type        = string
  default     = "t3.micro"
}

resource "aws_instance" "app" {
  ami           = "ami-0abcdef1234567890"
  instance_type = var.instance_type

  tags = {
    Name        = "app-${var.environment}"
    Environment = var.environment
  }
}

適用時に値を切り替えるには、terraform.tfvarsファイルを環境ごとに用意するか、コマンドライン引数で指定します。

# コマンドライン引数で指定
terraform apply -var="environment=prod" -var="instance_type=t3.large"

# tfvarsファイルを指定
terraform apply -var-file="environments/prod.tfvars"

筆者のプロジェクトでは、environments/ディレクトリにdev.tfvars、stg.tfvars、prod.tfvarsを配置して運用しています。環境差異がファイル単位で明確になるため、「本番だけ設定が違う」といった状況も見通しやすくなります。

初期設定と動作確認──最小構成で試してみる

環境構築ができたら、実際にTerraformを動かしてみましょう。ここではクラウドの認証情報なしで試せるlocal_fileリソースを使います。

作業ディレクトリを作成し、以下の内容でmain.tfを作成します。

terraform {
  required_version = ">= 1.0"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = "~> 2.0"
    }
  }
}

resource "local_file" "hello" {
  content  = "Hello, Terraform!"
  filename = "${path.module}/hello.txt"
}

各ブロックの意味を補足しておきます。

terraformブロック: Terraform本体のバージョン制約と、使用するプロバイダーを宣言します。required_versionでチーム全員のTerraformバージョンを揃え、required_providersでプロバイダーのソースとバージョンを固定します。
resourceブロック: 管理対象のリソースを定義します。"local_file"がリソースタイプ、"hello"がローカルでの識別名です。同じリソースタイプを複数定義する場合は、この識別名で区別します。
${path.module}: 現在の.tfファイルが置かれたディレクトリのパスを表す組み込み変数です。

基本ワークフロー: init → plan → apply

基本的なワークフローは次の3ステップです。

# 1. 初期化（プロバイダーのダウンロード）
terraform init

# 2. 実行計画の確認（何が作成・変更・削除されるか）
terraform plan

# 3. 適用（リソースの作成）
terraform apply

それぞれのステップで何が起きるか、もう少し詳しく見ていきましょう。

terraform init を実行すると、.terraformディレクトリが作成され、required_providersで指定したプロバイダープラグインがダウンロードされます。また、.terraform.lock.hclというロックファイルも生成されます。これはプロバイダーのバージョンとチェックサムを記録するファイルで、チーム全員が同じバージョンのプロバイダーを使えるようにするためのものです。このファイルはGitにコミットしておきましょう。

terraform plan を実行すると、以下のような出力が得られます。

Terraform will perform the following actions:

  # local_file.hello will be created
  + resource "local_file" "hello" {
      + content              = "Hello, Terraform!"
      + filename             = "./hello.txt"
      + id                   = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

+記号は新規作成を表します。変更の場合は~、削除の場合は-で表示されます。この出力を確認することで、意図した変更だけが行われるかを事前にチェックできます。

terraform apply を実行すると確認プロンプトが表示されます。内容を確認してyesと入力すると、同じディレクトリにhello.txtが生成されます。このinit → plan → applyのサイクルがTerraformの基本であり、実際のクラウドリソース管理でも同じ流れで進めることになります。

最初は「たったこれだけ？」と感じるかもしれませんが、この小さな成功体験が次のステップへの足がかりになるのではないでしょうか。

変更と削除も体験してみる

リソースの作成だけでなく、変更と削除もこの段階で試しておくと理解が深まります。

先ほどのmain.tfのcontentを書き換えてみましょう。

resource "local_file" "hello" {
  content  = "Hello, Terraform! Updated."
  filename = "${path.module}/hello.txt"
}

terraform planを実行すると、既存リソースの置き換えが表示されます。

  # local_file.hello must be replaced
-/+ resource "local_file" "hello" {
      ~ content              = "Hello, Terraform!" -> "Hello, Terraform! Updated."
        filename             = "./hello.txt"
      ~ id                   = "..." -> (known after apply)
    }

Plan: 1 to add, 0 to change, 1 to destroy.

-/+は「削除してから再作成」を意味します。terraform applyで適用すると、ファイルの内容が更新されたことを確認できます。

不要になったリソースを削除するにはterraform destroyを使います。

terraform destroy

確認プロンプトでyesと入力すると、Terraformが管理しているリソースがすべて削除されます。クラウドリソースの場合、消し忘れによる課金を防ぐためにもこのコマンドは重要です。検証が終わった環境を確実にクリーンアップできる安心感は、手作業では得られないものです。

実務で役立つTerraformコマンド集

基本のinit・plan・apply以外にも、日常的に使うコマンドは数多くあります。ここでは実務で特に出番の多いものを厳選して紹介します。

コードの検証とフォーマット

# 構文の検証（HCLの文法エラーをチェック）
terraform validate

# コードの自動フォーマット
terraform fmt

# サブディレクトリも含めて再帰的にフォーマット
terraform fmt -recursive

# フォーマットが必要なファイルの一覧を表示（CI向け）
terraform fmt -check -recursive

terraform fmtはチーム開発で特に重宝します。インデントや改行のスタイルが自動で統一されるため、コードレビューでフォーマットの指摘に時間を取られることがなくなります。筆者はGitのpre-commitフックにterraform fmt -checkを組み込んでおり、フォーマット未適用のコードがコミットされるのを防いでいます。

状態の確認と操作

# 管理しているリソースの一覧を表示
terraform state list

# 特定リソースの詳細情報を表示
terraform state show aws_instance.web

# リソースをStateから除外（Terraform管理外にする）
terraform state rm aws_s3_bucket.old_bucket

# Stateの中でリソース名を変更（リファクタリング時に使用）
terraform state mv aws_instance.old_name aws_instance.new_name

terraform state listは、「今Terraformが何を管理しているか」を俯瞰するのに便利です。引き継ぎ案件で既存のTerraformコードを触るとき、まずこのコマンドで全体像を把握する習慣をつけておくとよいでしょう。

terraform state mvは、リソース名をリファクタリングしたいときに使います。コード上でリソース名を変更すると、Terraformは「旧リソースの削除＋新リソースの作成」と解釈してしまいます。state mvで事前にState内の名前を変更しておけば、実リソースに影響を与えずにリネームが完了します。

出力値とリソースの確認

# outputブロックで定義した値を表示
terraform output

# 特定のoutputをJSON形式で表示（スクリプト連携向け）
terraform output -json

# 特定のoutput値だけを表示
terraform output instance_ip

outputはTerraformの実行結果を外部に渡す仕組みです。たとえば、作成したEC2インスタンスのIPアドレスやロードバランサーのDNS名をoutputとして定義しておけば、デプロイスクリプトや他のツールから参照できます。

その他の実用コマンド

# 特定リソースだけを対象にapply（大規模環境で部分適用したいとき）
terraform apply -target=aws_instance.web

# 確認プロンプトをスキップ（CI/CDパイプライン向け）
terraform apply -auto-approve

# 現在のStateとコードの差分を表示（ドリフト検出）
terraform plan -detailed-exitcode

# プロバイダーのキャッシュをクリアして再初期化
terraform init -upgrade

# 依存関係をグラフとして出力（Graphviz形式）
terraform graph | dot -Tpng > graph.png

-targetオプションは大規模な環境で一部だけを素早く適用したいときに使いますが、常用は推奨されません。依存関係が正しく解決されない場合があるため、あくまで限定的な場面で使うものと考えてください。

-auto-approveはCI/CDパイプラインでの自動適用に使います。人間が確認プロンプトに応答できない環境では必須ですが、ローカル実行時には安全のため使わないことをおすすめします。

よくあるトラブルと対処法

Terraformを使い始めて間もない頃は、思わぬエラーに遭遇することがあります。筆者自身がつまずいた経験も含め、よくあるトラブルと対処法をまとめておきます。

プロバイダーの初期化エラー

Error: Failed to query available provider packages

terraform init時にこのエラーが出る場合、ネットワーク接続の問題か、プロバイダーのソース指定が誤っている可能性があります。社内プロキシ環境ではHTTPS_PROXY環境変数の設定が必要になることもあります。

export HTTPS_PROXY=http://proxy.example.com:8080
terraform init

Stateのロック競合

チームで同じStateファイルを共有していると、同時にapplyを実行した場合にロック競合が発生します。

Error: Error locking state: Error acquiring the state lock

通常はもう一方の操作が完了すれば解消しますが、異常終了でロックが残ってしまった場合は、以下のコマンドで強制解除できます。

terraform force-unlock <LOCK_ID>

ただし、実行中の操作が本当に終了しているか必ず確認してから実行してください。

plan時の大量の差分

コードを変更していないのにterraform planで大量の差分が出る場合、Terraformのバージョンやプロバイダーのバージョンが変わった可能性があります。tfenvと.terraform.lock.hclでバージョンを固定しておくことで、こうしたトラブルを予防できます。

また、クラウド側で手動変更が行われた場合にも差分が生じます。いわゆる「ドリフト」と呼ばれる状態で、Terraformの管理外で変更が加わったことを意味します。terraform planが検出してくれるため、定期的にplanを実行してドリフトがないか確認する運用も有効です。

.gitignoreの設定

Terraform関連のファイルの中には、Gitにコミットすべきでないものがあります。プロジェクト開始時に.gitignoreを適切に設定しておきましょう。

# ローカルの.terraformディレクトリ（プロバイダープラグインなど）
.terraform/

# Stateファイル（機密情報を含む可能性あり）
*.tfstate
*.tfstate.*

# 変数定義ファイルのうち機密情報を含むもの
*.tfvars
!example.tfvars

# クラッシュログ
crash.log
crash.*.log

# planの出力ファイル
*.tfplan

一方で、以下のファイルはGitにコミットしておくべきです。

.tfファイル（インフラ定義そのもの）
.terraform.lock.hcl（プロバイダーのバージョンロック）
.terraform-version（tfenvのバージョン指定）

筆者の経験では、この.gitignore設定をプロジェクト初期に整えておくことで、後々のトラブルをかなり減らせます。特にStateファイルの誤コミットは、機密情報の漏洩につながるリスクがあるため、最初の段階で確実に除外しておきたいところです。

まとめ──次のステップに向けて

本記事ではTerraformのインストールから初期設定、動作確認、そして実務で使える具体例やコマンドまでを解説しました。改めてポイントを整理します。

OS別のインストール方法を確認し、terraform versionで動作を検証する
tfenvを導入してプロジェクト単位のバージョン管理を行う
init → plan → applyの基本ワークフローを手元で体験する
変数やプロバイダーの仕組みを理解し、実際のクラウド構成に応用する
fmt・validate・stateコマンドを日常的に活用する
.gitignoreやロックファイルの管理でチーム開発に備える

ここまでできれば、次はAWSやGoogle Cloudの実リソースを管理するステップに進めます。terraform planで変更差分を確認してから適用するという安全な運用フローは、本番環境でも大きな安心材料になるはずです。

さらに先を見据えると、モジュールを使ったコードの再利用、Workspaceによる環境分離、CI/CDパイプラインとの統合など、Terraformの世界はまだまだ広がっています。まずは本記事の内容を手元で一通り動かしてみて、Terraformの感覚をつかんでいただければと思います。

Terraformを活用したインフラ構築や、IaC導入についてお悩みの際は、こちらからお気軽にご相談ください。クラウドネイティブなインフラ設計から運用まで、一貫してサポートいたします。