Terraform と GCP の始め方：インストール・認証・ベストプラクティス

2026年4月22日

Contents

1 前提条件とバージョン確認
2 Terraform CLI のインストール
3 Google Cloud Provider の設定
- 3.1 versions.tf（必須）
- 3.2 プロバイダブロック例 (provider.tf)
4 認証情報の安全な取り扱い
- 4.1 サービスアカウントキーの作成手順（概要）
- 4.2 環境変数 GOOGLE_CREDENTIALS の使い方
  - 4.2.1 Terraform でデコードする例（variables.tf）
  - 4.2.2 Provider に適用
5 変数管理とベストプラクティス
6 サンプル構成：VPC・Compute Engine・Pub/Sub
7 Terraform ワークフロー（init → plan → apply）
- 7.1 実務での安全策
8 State 管理と Terraform Cloud の活用
9 クリーンアップ（destroy）とリスク回避策
- 9.1 安全な削除フロー
- 9.2 よくあるエラーと対処法
10 セキュリティ留意点
11 まとめと次のステップ
- 11.1 次にやるべきこと

スポンサードリンク

前提条件とバージョン確認

項目	推奨バージョン (2026‑04 時点)	根拠
Terraform 本体	≥ 1.9.0（最新安定版）	https://developer.hashicorp.com/terraform/downloads の「Latest Release」欄に記載
Google Cloud Provider	~> 6.11.0 以上	Terraform Registry（https://registry.terraform.io/providers/hashicorp/google/latest) の `required_version` が `>= 1.9.0`、Provider バージョンは 6 系の最新が 6.11.x 系です。※リリースノートで随時確認してください

⚠️ 注意
Provider バージョンは半年ごとにマイナーバージョンが上がります。versions.tf に記載するバージョン指定は「~> 6.11」や「>= 6.11,<7.0」のように範囲を明示し、常に公式リリースノートで互換性情報を確認してください。

Terraform CLI のインストール

macOS（Homebrew）

brew tap hashicorp/tap
brew install hashicorp/tap/terraform   # 常に最新版が取得されます

brew tap hashicorp/tap

brew install hashicorp/tap/terraform # 常に最新版が取得されます

Ubuntu/Debian（APT）

curl -fsSL https://apt.releases.hashicorp.com/gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

echo &quot;deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
      https://apt.releases.hashicorp.com $(lsb_release -cs) main&quot; | \
  sudo tee /etc/apt/sources.list.d/hashicorp.list &gt; /dev/null

sudo apt update &amp;&amp; sudo apt install terraform

curl -fsSL 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 > /dev/null

sudo apt update && sudo apt install terraform

Windows（公式 ZIP）

https://www.terraform.io/downloads.html から terraform_1.9.x_windows_amd64.zip をダウンロード
任意のディレクトリに展開し、パスを環境変数 PATH に追加

バージョン確認

$ terraform version
Terraform v1.9.4
on windows_amd64

$ terraform version

Terraform v1.9.4

on windows_amd64

ポイント：v1.9.x が表示されたらインストール完了です。バージョンが古い場合は再度インストール手順を実行してください。

Google Cloud Provider の設定

`versions.tf`（必須）

terraform {
  # Terraform 本体の最低バージョン
  required_version = &quot;&gt;= 1.9&quot;

  required_providers {
    google = {
      source  = &quot;hashicorp/google&quot;
      version = &quot;~&gt; 6.11&quot;   # 最新マイナーバージョンを自動取得（2026‑04 時点は 6.11.x 系）
    }
  }

  # バックエンドは別ファイル (backend.tf) に分離するのがベストプラクティス
}

terraform {

# Terraform 本体の最低バージョン

required_version = ">= 1.9"

required_providers {

google = {

source = "hashicorp/google"

version = "~> 6.11" # 最新マイナーバージョンを自動取得（2026‑04 時点は 6.11.x 系）

}

# バックエンドは別ファイル (backend.tf) に分離するのがベストプラクティス

}

プロバイダブロック例 (`provider.tf`)

provider &quot;google&quot; {
  project = var.project_id
  region  = var.region

  # 認証情報は後述の「認証情報の安全な取り扱い」参照
  credentials = var.google_credentials_json
}

provider "google" {

project = var.project_id

region = var.region

# 認証情報は後述の「認証情報の安全な取り扱い」参照

credentials = var.google_credentials_json

}

備考：required_providers の version フィールドは 「~> 6.11」 と書くことで、
6.11.x 系の最新が自動で取得されます。上位互換（7.0 以降）への自動アップグレードは防げるため、突発的な破壊的変更を回避できます。

認証情報の安全な取り扱い

サービスアカウントキーの作成手順（概要）

IAM → Service Accounts で新規サービスアカウント作成
必要最小限のロールを付与（例：roles/compute.instanceAdmin.v1, roles/network.admin）
「キー」タブから JSON キーを生成しダウンロード

重要：キーは 機密情報 です。決してリポジトリにコミットせず、アクセス権が必要な環境だけで保管してください。

環境変数 `GOOGLE_CREDENTIALS` の使い方

方法	メリット	デメリット
Base64 エンコードした JSON を直接設定 (`export GOOGLE_CREDENTIALS=$(cat cred.json \| base64 -w0)`)	CI/CD でシークレットストアに格納しやすい。環境変数漏洩リスクは同等だが、ログ出力されにくい	デコード忘れで認証失敗しやすい
`GOOGLE_APPLICATION_CREDENTIALS` にファイルパスを設定 (`export GOOGLE_APPLICATION_CREDENTIALS=$HOME/secrets/cred.json`)	ファイルベースのツールと相性が良い	ファイル自体の権限管理が別途必要

Terraform でデコードする例（`variables.tf`）

variable &quot;google_credentials_base64&quot; {
  description = &quot;Base64 エンコードされた GCP サービスアカウント JSON&quot;
  type        = string
  sensitive   = true
}

# デコード結果をプロバイダに渡すローカル変数
locals {
  google_credentials_json = jsondecode(base64decode(var.google_credentials_base64))
}

variable "google_credentials_base64" {

description = "Base64 エンコードされた GCP サービスアカウント JSON"

type = string

sensitive = true

}

# デコード結果をプロバイダに渡すローカル変数

locals {

google_credentials_json = jsondecode(base64decode(var.google_credentials_base64))

}

Provider に適用

provider &quot;google&quot; {
  project     = var.project_id
  region      = var.region
  credentials = local.google_credentials_json
}

provider "google" {

project = var.project_id

region = var.region

credentials = local.google_credentials_json

}

安全上の注意
Base64 は暗号化ではなく「エンコード」だけです。漏洩した場合は即座にキーが復元可能になるため、必ずシークレット管理ツール（Vault、Secret Manager 等）で保護してください。
terraform console など対話的なコンソールで var.google_credentials_base64 を表示すると平文の JSON が出力されるので、実行時は sensitive = true に設定し、ログに流れないようにしましょう。

変数管理とベストプラクティス

ファイル構成例

├─ main.tf            # ルートリソース（VPC、Compute 等）
├─ variables.tf       # 入力変数宣言
├─ terraform.tfvars   # デフォルト値（非機密情報のみ）
├─ backend.tf         # リモートバックエンド設定
└─ versions.tf        # プロバイダ・Terraform バージョン管理

├─ main.tf # ルートリソース（VPC、Compute 等）

├─ variables.tf # 入力変数宣言

├─ terraform.tfvars # デフォルト値（非機密情報のみ）

├─ backend.tf # リモートバックエンド設定

└─ versions.tf # プロバイダ・Terraform バージョン管理

主要変数 (`variables.tf`)

variable &quot;project_id&quot; {
  description = &quot;GCP プロジェクト ID&quot;
  type        = string
}

variable &quot;region&quot; {
  description = &quot;デプロイ先リージョン&quot;
  type        = string
  default     = &quot;asia-northeast1&quot;
}

variable &quot;instance_type&quot; {
  description = &quot;Compute Engine のマシンタイプ&quot;
  type        = string
  default     = &quot;e2-medium&quot;
}

variable "project_id" {

description = "GCP プロジェクト ID"

type = string

}

variable "region" {

description = "デプロイ先リージョン"

type = string

default = "asia-northeast1"

}

variable "instance_type" {

description = "Compute Engine のマシンタイプ"

type = string

default = "e2-medium"

}

環境別 tfvars（例：`dev.tfvars`）

project_id    = &quot;my-gcp-dev&quot;
region        = &quot;asia-northeast1&quot;
instance_type = &quot;e2-small&quot;
# 機密情報は含めない → CI では環境変数で注入

project_id = "my-gcp-dev"

region = "asia-northeast1"

instance_type = "e2-small"

# 機密情報は含めない → CI では環境変数で注入

実務での使い分け

項目	推奨方法
インフラ構成パラメータ（サイズ、タグ等）	`.tfvars` ファイルまたは `-var` オプション
機密情報（サービスアカウントキー、API キー）	環境変数 / シークレットマネージャ
CI/CD の実装例	GitHub Actions で `secrets.GCP_SA_JSON_BASE64` → `GOOGLE_CREDENTIALS` にエクスポート

GitHub Actions サンプル

jobs:
  terraform:
    runs-on: ubuntu-latest
    env:
      GOOGLE_CREDENTIALS: ${{ secrets.GCP_SA_JSON_BASE64 }}
    steps:
      - uses: actions/checkout@v3
      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2
        with:
          terraform_version: &quot;1.9.4&quot;
      - run: terraform init
      - run: terraform plan -var-file=dev.tfvars -out=tfplan.out
      - run: terraform apply -auto-approve tfplan.out   # 本番では manual approval を推奨

jobs:

terraform:

runs-on: ubuntu-latest

env:

GOOGLE_CREDENTIALS: ${{ secrets.GCP_SA_JSON_BASE64 }}

steps:

- uses: actions/checkout@v3

- name: Setup Terraform

uses: hashicorp/setup-terraform@v2

with:

terraform_version: "1.9.4"

- run: terraform init

- run: terraform plan -var-file=dev.tfvars -out=tfplan.out

- run: terraform apply -auto-approve tfplan.out # 本番では manual approval を推奨

ポイント：本番環境では -auto-approve の自動承認は避け、GitHub の「environment protection rule」や手動レビューを導入してください。

サンプル構成：VPC・Compute Engine・Pub/Sub

以下は最小構成のコード例です。実務に合わせてロールやタグ等を追加してください。

1️⃣ VPC とサブネット (`network.tf`)

resource &quot;google_compute_network&quot; &quot;vpc_main&quot; {
  name                    = &quot;tf-vpc-main&quot;
  auto_create_subnetworks = false
  routing_mode            = &quot;REGIONAL&quot;
}

resource &quot;google_compute_subnetwork&quot; &quot;subnet_a&quot; {
  name          = &quot;tf-subnet-a&quot;
  ip_cidr_range = &quot;10.0.0.0/24&quot;
  region        = var.region
  network       = google_compute_network.vpc_main.id
}

resource "google_compute_network" "vpc_main" {

name = "tf-vpc-main"

auto_create_subnetworks = false

routing_mode = "REGIONAL"

}

resource "google_compute_subnetwork" "subnet_a" {

name = "tf-subnet-a"

ip_cidr_range = "10.0.0.0/24"

region = var.region

network = google_compute_network.vpc_main.id

}

2️⃣ Compute Engine インスタンス (`instance.tf`)

resource &quot;google_compute_instance&quot; &quot;web&quot; {
  name         = &quot;tf-web-instance&quot;
  machine_type = var.instance_type
  zone         = &quot;${var.region}-a&quot;

  boot_disk {
    initialize_params {
      image = &quot;ubuntu-os-cloud/ubuntu-2204-lts&quot;
    }
  }

  network_interface {
    subnetwork = google_compute_subnetwork.subnet_a.id
    access_config {}   # パブリック IP を自動付与
  }

  metadata_startup_script = &lt;&lt;-EOS
    #!/bin/bash
    apt-get update -y &amp;&amp; apt-get install -y nginx
    systemctl enable --now nginx
  EOS

  tags = [&quot;http-server&quot;]
}

resource "google_compute_instance" "web" {

name = "tf-web-instance"

machine_type = var.instance_type

zone = "${var.region}-a"

boot_disk {

initialize_params {

image = "ubuntu-os-cloud/ubuntu-2204-lts"

}

network_interface {

subnetwork = google_compute_subnetwork.subnet_a.id

access_config {} # パブリック IP を自動付与

}

metadata_startup_script = <<-EOS

#!/bin/bash

apt-get update -y && apt-get install -y nginx

systemctl enable --now nginx

EOS

tags = ["http-server"]

}

ベストプラクティス：本番では metadata_startup_script の代わりに Cloud‑Init、Ansible、または Packer イメージで構成を行い、インスタンス起動時の処理を最小化します。

3️⃣ Pub/Sub トピック & サブスクリプション (`pubsub.tf`)

resource &quot;google_pubsub_topic&quot; &quot;events&quot; {
  name = &quot;tf-events-topic&quot;
}

resource &quot;google_pubsub_subscription&quot; &quot;pull_sub&quot; {
  name  = &quot;tf-pull-subscription&quot;
  topic = google_pubsub_topic.events.id

  ack_deadline_seconds = 20   # 必要に応じて調整
}

resource "google_pubsub_topic" "events" {

name = "tf-events-topic"

}

resource "google_pubsub_subscription" "pull_sub" {

name = "tf-pull-subscription"

topic = google_pubsub_topic.events.id

ack_deadline_seconds = 20 # 必要に応じて調整

}

Terraform ワークフロー（init → plan → apply）

コマンド	目的	補足
`terraform init`	プラグイン・バックエンド取得	初回だけでなく、Provider バージョン変更時は `-upgrade` オプションを併用
`terraform fmt -recursive`	コード整形	CI で自動実行推奨
`terraform validate`	設定の構文チェック	`plan` 前に必ず実施
`terraform plan -out=tfplan.out -var-file=dev.tfvars`	変更点をファイルへ保存	`-out` によりレビューが容易になる
`terraform show tfplan.out`	計画内容の詳細表示	変更対象 (`+`, `~`, `-`) を必ず確認
`terraform apply tfplan.out`	計画通りに適用	手動承認が必要な場合は `-auto-approve` を外す

実務での安全策

Plan のレビュー：プルリクエストに Plan 出力を添付し、チームで確認。
バックエンドロック：Terraform Cloud か、S3 + DynamoDB（AWS）/ GCS + ロックオブジェクトでロックを有効化。
CI の自動テスト：terraform validate と plan -detailed-exitcode を実行し、失敗したらパイプラインを停止。

State 管理と Terraform Cloud の活用

ローカル state のリスク

リスク	影響
ファイル破損・紛失	インフラの現状把握ができなくなる
同時実行による競合	予期せぬリソース削除や二重作成
バックアップ不足	復旧に時間がかかり、運用コスト増大

Terraform Cloud（remote backend）設定例 (`backend.tf`)

terraform {
  backend &quot;remote&quot; {
    hostname     = &quot;app.terraform.io&quot;
    organization = &quot;my-org&quot;

    workspaces {
      name = &quot;gcp-sample&quot;
    }
  }
}

terraform {

backend "remote" {

hostname = "app.terraform.io"

organization = "my-org"

workspaces {

name = "gcp-sample"

}

初回認証手順

# Terraform Cloud の UI で API Token を生成 → 環境変数に設定
export TF_CLOUD_TOKEN=xxxxxxxxxxxxxx

terraform login          # token をローカルの .terraform.d に保存
terraform init           # remote backend が有効化される

# Terraform Cloud の UI で API Token を生成 → 環境変数に設定

export TF_CLOUD_TOKEN=xxxxxxxxxxxxxx

terraform login # token をローカルの .terraform.d に保存

terraform init # remote backend が有効化される

ポイント：TF_CLOUD_TOKEN は 機密情報。GitHub Actions 等では secrets.TF_CLOUD_TOKEN として注入し、平文で残さないようにしてください。

料金とプラン

プラン	無料枠	主な制限
Free	500 runs / 月	同時実行 1, ステート容量 250 MB
Team & Governance	有償	ロック、ポリシー、SAML SSO 等

小規模チームや PoC であれば Free プラン が十分です。

クリーンアップ（destroy）とリスク回避策

安全な削除フロー

# 削除計画だけを作成
terraform plan -destroy -out=destroy.plan -var-file=dev.tfvars

# 計画内容の確認（必ずレビュー）
terraform show destroy.plan

# 確認後に適用
terraform apply destroy.plan

# 削除計画だけを作成

terraform plan -destroy -out=destroy.plan -var-file=dev.tfvars

# 計画内容の確認（必ずレビュー）

terraform show destroy.plan

# 確認後に適用

terraform apply destroy.plan

⚠️ 注意：terraform destroy -auto-approve は 本番環境では絶対に使用しない。
予期せぬリソース削除はコストだけでなく、データ損失やサービス停止につながります。

よくあるエラーと対処法

エラー	原因例	対策
`Error: Invalid credentials`	`GOOGLE_CREDENTIALS` が空・破損	環境変数を再設定し、`base64 --decode` で内容確認
`Failed to query available provider packages`	ネットワーク制限・プロキシ未設定	`HTTPS_PROXY/NO_PROXY` を正しく設定、もしくは社内ミラーを利用
`Locking state file failed`	同時実行やロックファイル残存	Terraform Cloud に移行、または `-lock-timeout=300s` で待機

セキュリティ留意点

最小権限の原則
bash gcloud projects add-iam-policy-binding my-project \ --member="serviceAccount:terraform-sa@my-project.iam.gserviceaccount.com" \ --role="roles/compute.instanceAdmin.v1" gcloud projects add-iam-policy-binding my-project \ --member="serviceAccount:terraform-sa@my-project.iam.gserviceaccount.com" \ --role="roles/network.admin"
Owner 権限は付与しない。必要に応じて pubsub.editor などを追加。
キーのローテーション
毎月または重要な権限変更時に新しい JSON キーを生成し、古いキーは即座に無効化。
自動化スクリプトで gcloud iam service-accounts keys create と keys delete を組み合わせる。
シークレット管理
HashiCorp Vault、Google Secret Manager、GitHub Secrets のいずれかを使用し、環境変数に注入。
Base64 は暗号化ではない ことをチーム全員に周知し、アクセス権限は最小限に。
State ファイルの暗号化
Terraform Cloud の場合は自動で暗号化されますが、GCS バックエンド使用時は kms_key_name で CMEK を設定。

まとめと次のステップ

項目	要点
Terraform 本体	公式サイトから最新（≥ 1.9）を取得し、`terraform version` で確認
Google Provider	`~> 6.11`（最新版）を `required_providers` に明示。リリースノートは必ずチェック
認証情報	サービスアカウント JSON を Base64 エンコードし、環境変数 `GOOGLE_CREDENTIALS` 経由で注入。シークレットストアに保管
変数管理	`variables.tf` + `.tfvars` で非機密パラメータを管理、機密情報は環境変数／Secret Manager
サンプル構成	VPC → Subnet → Compute Engine → Pub/Sub のフローが一通り体験できる
ワークフロー	`terraform init → fmt/validate → plan -out → apply` を CI に組み込み、Plan のレビューを必須化
State 管理	Terraform Cloud（Free）でリモートバックエンドとロック機能を利用。ローカル保存は避ける
クリーンアップ	`plan -destroy → apply` で削除計画を可視化し、`-auto-approve` は CI のみ限定的に使用
セキュリティ	最小権限ロール、キーの定期ローテーション、シークレットは暗号化ストレージへ

次にやるべきこと

公式ドキュメント確認
Terraform Registry の Google Provider ページで最新バージョンと required_version をチェック。
CI パイプライン構築
GitHub Actions（または Azure Pipelines 等）に上記の terraform fmt/validate/plan/apply ステップを実装し、Plan の自動コメント化を試す。
本番環境への適用
最小構成でステージング環境を作り、ロール・権限・キー管理フローを検証後、本番へ拡張する。

最終的なゴール：コードとしてインフラ（IaC）を完全に管理し、変更履歴とレビューが必ず行われる安全かつ再現性の高い GCP 環境を構築できることです。

この記事は 2026 年 4 月時点の情報に基づいています。リリースやベストプラクティスは随時変わりますので、公式ドキュメントで最新情報をご確認ください。

スポンサードリンク

-GCP

comment コメントをキャンセル

: GCP

BigQuery MLモデル作成とVertex AIデプロイ完全ガイド

BigQuery MLでのモデル作成からVertex AIへのエクスポート・デプロイ、運用最適化までを実践的に解説します。

: GCP

2026年版データウェアハウス選定ガイド：BigQuery と Snowflake の比較と最適化ポイント

データエンジニアや分析マネージャー向けに、BigQuery と Snowflake を5つの比較軸で評価し、2026年の最新機能と料金改定を踏まえた選定方法を提示します。

: GCP

BigQueryの料金構造とコスト削減完全ガイド（2026年版）

BigQuery のコストは「ストレージ」「オンデマンドクエリ（スキャン量）」「コンピュート（予約スロット／Flex スロット）」の3要素で決まり、最適化すれば無駄な支出を抑えられます。

: GCP

GCPで構築する最新データレイク入門：Dataplex・BigLake活用ガイド

本稿では GCP の主要サービスを用いたデータレイクの基本概念から構築手順、Dataplex ゾーン作成、BigLake 外部テーブル活用まで実践的に解説します。

: GCP

2026年版クラウドデータ分析とAIサービス徹底比較 – BigQuery Omni 2.0・Vertex AI Gemini

2026年リリースのBigQuery Omni 2.0はマルチクラウド環境で最も実用的なデータ分析基盤として、ETLコストとレイテンシを大幅に削減します。

2024年Freelance.jp単価調査と未経験エンジニアの高時給攻略ガイド

未経験エンジニアが合格する面接対策と必須5要素｜2026年最新ガイド

Terraform と GCP の始め方：インストール・認証・ベストプラクティス

前提条件とバージョン確認

Terraform CLI のインストール

macOS（Homebrew）

Ubuntu/Debian（APT）

Windows（公式 ZIP）

バージョン確認

Google Cloud Provider の設定

versions.tf（必須）

プロバイダブロック例 (provider.tf)

認証情報の安全な取り扱い

サービスアカウントキーの作成手順（概要）

環境変数 GOOGLE_CREDENTIALS の使い方

Terraform でデコードする例（variables.tf）

Provider に適用

変数管理とベストプラクティス

ファイル構成例

主要変数 (variables.tf)

環境別 tfvars（例：dev.tfvars）

実務での使い分け

GitHub Actions サンプル

サンプル構成：VPC・Compute Engine・Pub/Sub

1️⃣ VPC とサブネット (network.tf)

2️⃣ Compute Engine インスタンス (instance.tf)

3️⃣ Pub/Sub トピック & サブスクリプション (pubsub.tf)

Terraform ワークフロー（init → plan → apply）

実務での安全策

State 管理と Terraform Cloud の活用

ローカル state のリスク

Terraform Cloud（remote backend）設定例 (backend.tf)

初回認証手順

料金とプラン

クリーンアップ（destroy）とリスク回避策

安全な削除フロー

よくあるエラーと対処法

セキュリティ留意点

まとめと次のステップ

次にやるべきこと

`versions.tf`（必須）

プロバイダブロック例 (`provider.tf`)

環境変数 `GOOGLE_CREDENTIALS` の使い方

Terraform でデコードする例（`variables.tf`）

主要変数 (`variables.tf`)

環境別 tfvars（例：`dev.tfvars`）

サンプル構成：VPC・Compute Engine・Pub/Sub

1️⃣ VPC とサブネット (`network.tf`)

2️⃣ Compute Engine インスタンス (`instance.tf`)

3️⃣ Pub/Sub トピック & サブスクリプション (`pubsub.tf`)

Terraform Cloud（remote backend）設定例 (`backend.tf`)