この記事の最終更新日: 2026年9月1日
Terraformでインフラを管理し始めると、次に悩みやすいのが 「Terraform CloudとGitHub Actionsのどちらで実行するべきか」 です。
どちらもTerraformの自動実行に使えます。
しかし、役割は同じではありません。
ざっくり言うと、次のように考えると分かりやすいです。
Terraform Cloud / HCP Terraform
→ Terraform実行・state管理・承認・ポリシー管理に強い
GitHub Actions
→ GitHub上のCI/CD・テスト・ビルド・周辺処理の自動化に強い
なお、Terraform Cloudは2024年4月22日から HCP Terraform という名称に変わっています。ただし、現場では今でも「Terraform Cloud」と呼ばれることが多いため、この記事では分かりやすさを優先して「Terraform Cloud」と表記します。(HashiCorp Developer)
- Terraform Cloudとは何か
- GitHub Actionsとは何か
- まず結論：Terraformの本番applyはTerraform Cloud寄りが安全
- 比較表
- Terraform Cloudを使うべき場面
- GitHub Actionsを使うべき場面
- よくある使い分けパターン
- パターン1：Terraform Cloud中心
- パターン2：GitHub Actions中心
- パターン3：GitHub Actions + Terraform Cloud連携
- 初心者におすすめの判断基準
- GitHub ActionsだけでTerraformを回すときの注意点
- Terraform Cloudだけで完結させるときの注意点
- 実務でおすすめの構成
- 小規模開発ならどうするべきか
- 本番運用ならどうするべきか
- よくある誤解
- 使い分けのチェックリスト
- まとめ
Terraform Cloudとは何か
Terraform Cloud、現在のHCP Terraformは、チームでTerraformを扱うための専用サービスです。
主な役割は、Terraformの実行環境、state管理、変数・シークレット管理、承認フロー、アクセス制御、ポリシー制御、プライベートモジュール管理などです。公式ドキュメントでも、HCP TerraformはチームでTerraformを使うためのアプリケーションであり、Terraform runを一貫した環境で管理し、shared state、secret data、access control、policy controlなどを提供すると説明されています。(HashiCorp Developer)
つまり、Terraform Cloudは単なるCIツールではありません。
Terraformを安全に、チームで、継続的に運用するためのプラットフォームです。
GitHub Actionsとは何か
GitHub Actionsは、GitHubリポジトリ上でワークフローを自動実行するためのCI/CDサービスです。
GitHub公式ドキュメントでは、GitHub Actionsはビルド、テスト、デプロイのパイプラインを自動化できるCI/CDプラットフォームとして説明されています。(GitHub Docs)
たとえば、次のような処理に向いています。
- Pull Request作成時にテストを実行する
- mainブランチにマージされたらデプロイする
- Dockerイメージをビルドする
- LintやFormatterを実行する
- Terraformのplanを実行する
- Slackに通知する
- 外部APIを叩く
- 定期実行する
GitHub ActionsはTerraform専用ではなく、アプリケーション開発全体の自動化に使える汎用的なワークフロー基盤です。
まず結論：Terraformの本番applyはTerraform Cloud寄りが安全
最初に結論を書くと、チーム開発や本番環境では、次の使い分けが現実的です。
Terraform Cloud:
terraform plan / apply
state管理
環境変数・シークレット管理
承認フロー
ポリシー制御
GitHub Actions:
terraform fmt / validate
Pull Requestへのplan結果通知
テスト
ビルド
アプリケーションデプロイ
Terraform Cloudのrun起動
Slack通知
Terraformの実行そのもの、特に apply はTerraform Cloud側に寄せると管理しやすいです。
一方で、GitHub ActionsはPull Requestを起点にした周辺自動化に向いています。
比較表
| 観点 | Terraform Cloud | GitHub Actions |
|---|---|---|
| 主な目的 | Terraform運用 | CI/CD全般 |
| 得意領域 | plan/apply、state管理、承認、ポリシー | テスト、ビルド、通知、デプロイ、自由な自動化 |
| Terraform実行 | 非常に得意 | 実行できるが自前管理が増える |
| state管理 | 標準機能として扱いやすい | S3など別途backend設計が必要 |
| 承認フロー | Terraform変更向けに管理しやすい | Environment protectionなどで実現可能 |
| シークレット管理 | Workspace変数として管理 | GitHub Secretsで管理 |
| ポリシー制御 | Sentinel / policy checksなどに強い | 自前でツールを組み合わせる |
| GitHub連携 | VCS連携やAPI連携 | GitHubイベントとの相性が非常に良い |
| 柔軟性 | Terraform中心 | かなり高い |
| 学習コスト | Terraform運用を理解する必要あり | YAMLとCI/CD設計を理解する必要あり |
Terraform Cloudを使うべき場面
1. Terraformのstateを安全に管理したい
Terraformで最も重要なファイルの一つが terraform.tfstate です。
stateには、Terraformが管理しているリソースの情報が入ります。
このstateをローカルPCに置いたままチーム開発すると、次のような問題が起きます。
- 誰のPCに最新stateがあるか分からない
- 同時実行でstateが壊れる可能性がある
- 誤って削除・上書きするリスクがある
- 機密情報を含む場合がある
- CI/CDで扱いづらい
Terraform Cloudを使うと、remote stateを前提にチームで管理できます。
個人開発ならローカルstateでも始められますが、チーム開発や本番運用ではremote stateを使う方が安全です。
2. applyに承認フローを入れたい
Terraformの apply は、インフラを実際に変更する操作です。
アプリケーションのテスト実行とは重みが違います。
たとえば、誤ったTerraform変更によって次のようなことが起こり得ます。
- 本番DBが削除される
- セキュリティグループが意図せず開く
- IAM権限が広がる
- ロードバランサー設定が変わる
- 本番環境のリソースが再作成される
- コストが大きく増える
そのため、本番環境のapplyには承認フローを入れたくなります。
Terraform Cloudは、Terraformのrunを中心に承認や確認を行いやすい設計になっています。
GitHub ActionsでもEnvironmentのrequired reviewersなどを使えば承認フローは作れます。GitHub ActionsのEnvironmentでは、環境ごとのsecretsやdeployment protection rulesを設定できます。(GitHub Docs)
ただし、Terraformのplan結果、state、workspace、policy checkを含めて管理するなら、Terraform Cloudの方がTerraform運用に寄っています。
3. Terraform専用の実行履歴を残したい
Terraformでは、「いつ」「誰が」「どのworkspaceで」「どんなplanを確認して」「何をapplyしたのか」が重要です。
GitHub Actionsにも実行ログは残ります。
ただし、GitHub ActionsのログはCI/CD全般のログです。
一方、Terraform CloudではTerraform runの履歴として管理できます。
インフラ変更の監査やレビューを重視するなら、Terraform専用の実行履歴が残ることは大きなメリットです。
4. Workspaceごとに環境を分けたい
Terraform Cloudでは、workspace単位で環境を分けられます。
たとえば、次のような構成です。
app-dev
app-stg
app-prod
workspaceごとに変数、state、実行履歴、権限を分けられます。
開発環境、検証環境、本番環境を明確に分離したい場合に便利です。
5. ポリシー制御を入れたい
Terraform運用では、単にapplyできればよいわけではありません。
次のようなルールを入れたくなることがあります。
- 本番環境で特定サイズ以上のインスタンス作成を禁止する
- S3バケットのpublic公開を禁止する
- タグ付けを必須にする
- 特定リージョン以外の作成を禁止する
- 危険なIAM権限を禁止する
Terraform Cloudは、Terraform変更に対するポリシー制御を行いやすいです。
チームや組織でガバナンスを効かせたい場合は、Terraform Cloudの価値が出やすいです。
GitHub Actionsを使うべき場面
1. Pull Requestでterraform fmtやvalidateを実行したい
Terraformの基本チェックはGitHub Actionsで十分です。
たとえば、Pull Request作成時に次のような処理を実行します。
terraform fmt -check
terraform validate
tflint
checkov
これらは本番環境を変更する処理ではありません。
そのため、GitHub Actionsで高速に実行し、PR上でフィードバックするのに向いています。
2. アプリケーションのCI/CDと一緒に管理したい
GitHub ActionsはTerraform専用ではなく、アプリケーション開発全体のワークフローを扱えます。
たとえば、次のような一連の流れです。
1. Pull Request作成
2. Backendのテスト実行
3. Frontendのビルド確認
4. Docker image build
5. Terraform validate
6. Terraform plan
7. Slack通知
Terraformだけでなく、アプリケーションのテストやビルドも含めて管理したい場合は、GitHub Actionsの方が柔軟です。
3. Terraform Cloudのrunを起動したい
GitHub ActionsからTerraform Cloudを呼び出す構成もあります。
HashiCorpは、HCP Terraform APIと連携するGitHub Actionsを提供しており、組織に合わせたカスタムCI/CDワークフローを作れると説明しています。(HashiCorp Developer)
この構成では、役割を次のように分けられます。
GitHub Actions:
PRやpushをトリガーにする
通知する
Terraform Cloudのrunを起動する
周辺処理を行う
Terraform Cloud:
plan/applyを実行する
stateを管理する
承認フローを扱う
つまり、GitHub ActionsとTerraform Cloudは競合ではなく、組み合わせて使えます。
4. Terraform CLIを直接実行したい
GitHub Actions上でTerraform CLIを直接実行することもできます。
HashiCorpの setup-terraform Actionは、GitHub Actions workflow内でTerraform CLIをセットアップするための公式Actionです。(GitHub)
たとえば、簡略化すると次のようなworkflowになります。
name: Terraform Check
on:
pull_request:
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: hashicorp/setup-terraform@v3
with:
terraform_version: 1.9.0
- name: Terraform Format
run: terraform fmt -check
- name: Terraform Init
run: terraform init
- name: Terraform Validate
run: terraform validate
- name: Terraform Plan
run: terraform plan
ただし、GitHub Actionsで直接 apply まで行う場合は、state backend、クラウド認証、シークレット管理、承認、同時実行制御などを自分たちで丁寧に設計する必要があります。
よくある使い分けパターン
パターン1：Terraform Cloud中心
GitHub
↓
Terraform CloudがVCS連携でplan/apply
↓
AWS / GCP / Azure
向いているケース
- Terraform運用をシンプルにしたい
- state管理をTerraform Cloudに任せたい
- apply承認をTerraform Cloudで管理したい
- Terraform専用の実行履歴を残したい
- インフラ変更の統制を強めたい
特徴
この構成では、Terraform Cloudが主役です。
GitHubはTerraformコードの置き場所として使い、Terraform Cloudがリポジトリの変更を検知してplan/applyを行います。
初心者チームや、Terraform運用を標準化したいチームには分かりやすい構成です。
パターン2：GitHub Actions中心
GitHub Actions
↓
terraform init / plan / apply
↓
Remote backend
↓
AWS / GCP / Azure
向いているケース
- CI/CDをGitHub Actionsに集約したい
- Terraform Cloudを使わない方針
- 既にS3 + DynamoDBなどのbackend設計がある
- コストや運用方針の都合で外部サービスを増やしたくない
- 小規模なチームまたは個人開発
特徴
GitHub ActionsだけでもTerraformは実行できます。
ただし、Terraform Cloudが持っている機能を自前で補う必要があります。
特に注意したいのは次の点です。
- state backend
- state lock
- シークレット管理
- クラウド認証
- apply承認
- plan結果のレビュー
- 並列実行の制御
- 権限分離
- 実行ログの保管
小さく始めやすい一方で、チームや環境が増えると設計負荷が上がります。
パターン3：GitHub Actions + Terraform Cloud連携
Pull Request
↓
GitHub Actions
↓
Terraform Cloudのrunを起動
↓
Terraform Cloudでplan/apply
↓
結果をPRやSlackに通知
向いているケース
- GitHub中心の開発フローにしたい
- Terraformの実行自体はTerraform Cloudに任せたい
- PRコメントやSlack通知を柔軟に制御したい
- アプリケーションCI/CDとインフラCI/CDを連携したい
- Terraform Cloudの安全性とGitHub Actionsの柔軟性を両方使いたい
特徴
実務でかなりバランスがよい構成です。
GitHub Actionsは「交通整理役」として使い、Terraform Cloudは「Terraform実行基盤」として使います。
両方の得意領域を活かせます。
初心者におすすめの判断基準
初心者向けにかなり単純化すると、次の判断でよいです。
Terraformの安全な実行とstate管理を重視する
→ Terraform Cloud
GitHub上でテスト・ビルド・通知も含めて自由に自動化したい
→ GitHub Actions
本番applyを安全に管理しつつ、GitHubのPRフローも活かしたい
→ GitHub Actions + Terraform Cloud
特に、本番環境を扱うなら「GitHub Actionsで全部できるから全部やる」よりも、Terraformの実行責務をどこに置くかを慎重に考えた方がよいです。
GitHub ActionsだけでTerraformを回すときの注意点
GitHub ActionsだけでTerraformを実行する場合、次の点に注意が必要です。
1. クラウド認証情報をどう渡すか
AWS、GCP、Azureなどの認証情報をGitHub Actionsに渡す必要があります。
長期的なアクセスキーをGitHub Secretsに保存する方法もありますが、可能であればOIDCを使って短期認証に寄せる方が安全です。
GitHub Actionsではrepository、environment、organizationなどの単位でsecretsを作成・利用できます。(GitHub Docs)
ただし、Secretsに入れたから安全、というわけではありません。
どのworkflowから使えるのか、どのbranchで使えるのか、誰が変更できるのかまで含めて設計する必要があります。
2. applyを自動化しすぎない
Pull Request作成時に terraform plan を実行するのは自然です。
しかし、Pull Request作成時に自動で terraform apply するのは危険です。
基本的には次のように分ける方が安全です。
Pull Request:
fmt
validate
plan
main merge後:
stg apply
手動承認後:
prod apply
本番環境のapplyには、最低でも人間の確認や承認を入れるべきです。
3. 同時実行を制御する
Terraformはstateを扱うため、同じ環境に対して複数のapplyが同時に走ると危険です。
remote backend側のlockがあるとしても、workflow設計として同時実行を抑制した方が安全です。
GitHub Actionsを使う場合は、環境ごとにconcurrencyを設定するなどの工夫が必要です。
concurrency:
group: terraform-prod
cancel-in-progress: false
4. plan結果をレビューしやすくする
Terraformは、plan結果を読んでからapplyするのが重要です。
ただし、GitHub Actionsのログだけにplan結果が埋もれると見づらくなります。
PRコメントに要約を出す、artifactとして保存する、Terraform Cloudにrunを作るなど、レビューしやすい形にすることが大切です。
Terraform Cloudだけで完結させるときの注意点
Terraform Cloud中心にする場合も、注意点はあります。
1. アプリケーションCI/CDとは別管理になりやすい
Terraform CloudはTerraformには強いですが、アプリケーションのテストやビルドまで全て担当するものではありません。
そのため、アプリケーション側はGitHub Actions、インフラ側はTerraform Cloud、というように分かれることがあります。
この分離自体は悪くありません。
ただし、リリース順序や通知設計を考えないと、全体の流れが分かりにくくなります。
2. GitHub上のPR体験を補いたくなる
開発者はGitHubのPull Request上でレビューすることが多いです。
そのため、Terraform Cloudだけでplan結果を見る運用にすると、GitHub側のレビュー体験と少し離れることがあります。
この場合、GitHub ActionsからTerraform Cloudのrunを起動し、結果をPRに返す構成が便利です。
3. Workspace設計が重要になる
Terraform Cloudではworkspace設計が重要です。
たとえば、次のような方針を決める必要があります。
- dev / stg / prodをworkspaceで分けるか
- サービス単位でworkspaceを分けるか
- リージョン単位で分けるか
- モジュール単位で分けるか
- 変数をどこまで共通化するか
- 権限をどう分離するか
workspaceを雑に増やすと、後から管理しづらくなります。
実務でおすすめの構成
個人的には、チーム開発では次の構成がバランスよいです。
Pull Request作成
↓
GitHub Actionsでfmt / validate / lint
↓
GitHub ActionsからTerraform Cloudのplanを起動
↓
PRでplan結果を確認
↓
mainへマージ
↓
stgは自動apply
↓
prodはTerraform Cloud側で承認後apply
この構成のメリットは次の通りです。
- GitHubのPRフローに乗せやすい
- Terraformのstate管理をTerraform Cloudに任せられる
- applyの承認をTerraform Cloud側で扱える
- GitHub Actionsで通知や周辺処理を柔軟に書ける
- Terraform実行環境を開発者PCに依存させなくてよい
- 本番変更の監査性を高めやすい
GitHub ActionsとTerraform Cloudを「どちらか一方」と考えるより、責務を分けて組み合わせる方が現実的です。
小規模開発ならどうするべきか
個人開発や小規模な検証環境なら、GitHub Actionsだけでも十分なことがあります。
たとえば、次のようなケースです。
- 管理するリソースが少ない
- 本番環境がまだない
- 開発者が1人か少人数
- apply頻度が低い
- Terraform Cloudを導入するほどではない
- S3 backendなどを既に理解している
この場合は、GitHub Actionsで fmt、validate、plan まで行い、apply は手動実行から始めてもよいです。
ただし、チーム開発や本番運用に移る段階で、Terraform CloudやHCP Terraformの導入を検討するとよいです。
本番運用ならどうするべきか
本番環境をTerraformで管理するなら、以下の要件が出やすくなります。
- 誰がapplyできるか制御したい
- plan結果を承認してからapplyしたい
- stateを安全に管理したい
- 実行履歴を残したい
- 環境ごとに権限を分けたい
- 変更の影響をレビューしたい
- policy checkを入れたい
- 複数人で安全に運用したい
この場合は、Terraform Cloud中心、またはGitHub Actions + Terraform Cloud連携がおすすめです。
GitHub Actionsだけでも実現はできますが、安全に作り込むにはそれなりの設計が必要です。
よくある誤解
Terraform Cloudを使えばGitHub Actionsは不要？
不要とは限りません。
Terraform CloudはTerraform運用に強いですが、アプリケーションのテスト、ビルド、デプロイ、通知、Issue操作などはGitHub Actionsの方が向いています。
両方使う構成は普通にあります。
GitHub ActionsがあればTerraform Cloudは不要？
これもケースバイケースです。
GitHub ActionsでTerraform CLIを実行することはできます。
しかし、Terraform Cloudが持つstate管理、run履歴、承認、policy、workspace管理などをどう補うかは考える必要があります。
planはGitHub Actions、applyはTerraform Cloudに分ければよい？
一見よさそうですが、planとapplyを別々の実行基盤に分ける場合は注意が必要です。
理想は、applyされるplanが明確に確認できることです。
planはGitHub Actionsで見たもの、applyは別環境で再実行、という構成だと、タイミングによって差分が変わる可能性があります。
そのため、Terraform Cloudのrunとしてplan/applyを管理し、GitHub Actionsはそれを起動・通知する役割にする方が安全です。
Terraform Cloudを使えば設計しなくてよい？
Terraform Cloudを使っても、設計は必要です。
特に次の設計は避けて通れません。
- workspace設計
- ディレクトリ構成
- module分割
- 変数管理
- 権限管理
- 環境分離
- provider認証
- apply承認ルール
- GitHub連携方針
Terraform Cloudは便利ですが、設計の代わりをしてくれるわけではありません。
使い分けのチェックリスト
最後に、判断用のチェックリストです。
Terraform Cloudを優先した方がよいケース
□ 本番環境をTerraformで管理している
□ 複数人でTerraformを触る
□ state管理を安全にしたい
□ apply承認を入れたい
□ Terraform実行履歴を管理したい
□ 環境ごとにworkspaceを分けたい
□ policy checkを入れたい
□ インフラ変更の監査性を高めたい
GitHub Actionsを優先した方がよいケース
□ Pull Requestでfmt/validateを回したい
□ アプリケーションのテストやビルドも一緒に管理したい
□ Slack通知など周辺処理を柔軟に書きたい
□ GitHubイベントを起点にしたい
□ 小規模なTerraform運用から始めたい
□ Terraform Cloudのrunを起動する窓口にしたい
両方使うのが向いているケース
□ GitHubのPRフローを中心にしたい
□ Terraformの実行は安全に管理したい
□ plan結果をPRで確認したい
□ applyは承認制にしたい
□ CI/CD全体の一部としてTerraformを扱いたい
□ 本番環境と検証環境で運用を分けたい
まとめ
Terraform CloudとGitHub Actionsは、どちらか一方だけを選ぶものではありません。
役割を分けて考えるのが重要です。
Terraform Cloud:
Terraformを安全に実行・管理する場所
GitHub Actions:
GitHub上のイベントを起点に処理を自動化する場所
初心者向けに一言でまとめるなら、次のようになります。
Terraformのapplyとstate管理はTerraform Cloudに寄せる。
PRチェックや通知、周辺のCI/CDはGitHub Actionsに任せる。
GitHub ActionsだけでもTerraformは実行できます。
しかし、本番環境やチーム開発では、state管理、承認、実行履歴、権限制御、ポリシー管理が重要になります。
そのため、実務では GitHub Actionsでワークフローを組み、Terraform CloudでTerraform runを管理する構成 がバランスのよい選択肢になります。
大阪のエンジニアが書いているブログ。
コメント