Terraform Cloud vs GitHub Actions — どちらで運用すべきか

1. 概要

• Terraform CloudとGitHub Actionsの役割の違い
• どちらを選ぶべきか判断するための比較軸
• チーム規模・インフラ規模別の推奨構成
• 両者を組み合わせるハイブリッド構成

Terraform CloudはHashiCorpが提供するTerraform専用のSaaSプラットフォームです。一方GitHub ActionsはCI/CDの汎用ツールです。「TerraformをどこでどうCI/CDするか」という問いに対して、多くのチームがこの2択で悩みます。

---

2. 機能比較

比較軸	Terraform Cloud	GitHub Actions
State管理	組み込み（リモートバックエンド）	別途S3+DynamoDB等が必要
Secrets管理	Workspace変数として管理	GitHub Secrets
plan/applyの実行環境	Terraform Cloud内（管理不要）	セルフホストRunnerまたはGitHub管理Runner
PRへのplan結果表示	自動（VCS連携で標準機能）	サードパーティAction（tfcmt等）が必要
ポリシー制御	Sentinel（有料プラン）	OPA/Conftest等を自前で組み込む
コスト	無料〜$20/ユーザー/月（Plus）	GitHub無料枠あり（分数課金）
セットアップ難度	低（GUIでVCS連携するだけ）	中（YAMLワークフロー設計が必要）
カスタマイズ性	低（Terraform専用）	高（任意のステップを追加可能）

---

3. Terraform Cloudを選ぶべきケース

# Terraform Cloudを使う場合、backendをcloudブロックで指定する
terraform {
  required_version = ">= 1.9"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }

  cloud {
    organization = "my-org"
    workspaces {
      name = "production"
    }
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

variable "environment" {
  description = "環境名"
  type        = string
  default     = "dev"
}

Terraform Cloudが向いているケース:

• Terraform専用のプラットフォームが欲しい（State・シークレット・実行環境を一括管理したい）
• インフラチームがGitHub ActionsのYAML設計を担当できるエンジニアを確保しにくい
• PRベースのplan確認ワークフローをすぐに使いたい（VCS連携で標準機能）
• 監査ログ・アクセス制御をTerraformに特化した形で管理したい

---

4. GitHub Actionsを選ぶべきケース

# .github/workflows/terraform.yml
name: Terraform CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  terraform:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials (OIDC)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
          aws-region: ap-northeast-1

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "~> 1.9"

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan -no-color
        if: github.event_name == 'pull_request'

      - name: Terraform Apply
        run: terraform apply -auto-approve
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'

GitHub Actionsが向いているケース:

• すでにGitHub ActionsでアプリのCI/CDを運用しており、インフラも同じプラットフォームで統一したい
• Terraform以外のツール（terraform-docs・tfsec・Checkov等）を柔軟に組み合わせたい
• セルフホストRunnerでオンプレ環境やVPC内リソースへアクセスする必要がある
• コストを最小化したい（GitHub無料枠内で収まるスモールチーム）

---

5. ハイブリッド構成（両方使う）

# GitHub ActionsからTerraform Cloudのrunをトリガーする
- name: Trigger Terraform Cloud Run
  uses: hashicorp/tfc-workflows-github/actions/create-run@v1
  with:
    workspace: production
    configuration_version: ${{ steps.upload.outputs.configuration_version_id }}

State管理はTerraform Cloud、ワークフロー制御はGitHub Actionsという組み合わせも一般的です。GitHub ActionsでコードチェックやDockerビルドを行い、Terraformの実行だけTerraform Cloudに委ねるパターンです。

---

6. チーム規模別推奨

チーム規模	推奨	理由
1〜5人	GitHub Actions	セットアップが軽量、Terraform Cloud無料枠でも可
5〜20人	Terraform Cloud（Free〜Plus）	State管理とアクセス制御を早めに整備
20人以上	Terraform Cloud（Business）	Sentinelポリシー・監査ログ・SSO必須
オンプレ環境あり	GitHub Actions + セルフホストRunner or Terraform Cloud Agent	VPC内リソースへのアクセスが必要

---

7. 関連記事

• CI/CDパイプラインとTerraform — GitHub Actions連携例 — GitHub Actions基本構成
• GitHub ActionsでTerraformを実行する方法 — 実装手順詳解
• Terraform Cloudは無料でどこまで使える？ — 料金プラン比較
• Terraform CloudのVCS連携設定ガイド — VCS連携の手順
• Terraform CI/CDのブランチ戦略 — apply戦略の設計
• backend — stateファイルの保存場所を設定 — S3バックエンドとの比較

---

8. まとめ

• Terraform Cloudは「State・シークレット・実行環境の一括管理」が強み。設定が最小限で済む
• GitHub Actionsは「柔軟なカスタマイズ」が強み。既存CI/CDとの統合が容易
• スモールチームはGitHub Actions、成長するチームはTerraform Cloudへ段階的に移行するパターンが多い
• 両者を組み合わせるハイブリッド構成も有効（State管理はTF Cloud、ワークフローはGHA）
• 最終的な選択基準は「チームのYAML設計力」と「State/シークレット管理をどこで一元化するか」

---

対象バージョン: Terraform >= 1.9 / GitHub Actions (2024) 公式ドキュメント: https://developer.hashicorp.com/terraform/cloud-docs

---