IT女子 アラ美お疲れ様です！IT業界で働くアライグマです！
Terraformを2〜3人を超えるチームで運用しはじめると、ほぼ確実に「stateロック衝突」「PRの順番待ち」「環境間ドリフト」の3点で詰まります。実際、AWSのリソース数百個を10名で触っているチームでは、terraform planが走るたびに別メンバーの作業が止まり、レビューも追いつかず、勝手にコンソール操作されてドリフトが発生するという悪循環がよく起こります。本記事では、Terraform×GitHub Actionsの組み合わせを前提に、複数人でも衝突しないブランチ戦略と環境分離・PRレビュー設計を、実装テンプレートとケーススタディ付きで解説します。
テーマの全体像と背景
IT女子 アラ美Terraformを複数人で運用するチームが最初にぶつかる壁は、ツール固有の問題ではなく「並列開発を前提にした設計が抜けている」という運用設計の不足です。具体的には、stateファイルが1つしかないのに同時に複数のterraform planが走る、ブランチ命名がばらばらでレビュー順がわからない、applyの責任者が曖昧でドリフトに気づけない、といった事象が一気に発生します。
特に2026年現在、GitHub Actionsを使ったIaC自動化は事実上のデファクトになっており、ワークフローをジョブ単位で適切に分割しないと、planだけで数十分かかる肥大化したCI/CDに陥りやすい状況です。CI/CD自体の設計負債はGitHub Actionsの肥大化を防ぐCI/CD設計パターンで整理した通りで、その上にIaC特有の制約（stateロック・順序保証・本番applyの慎重さ）が乗ってくるイメージです。
複数人IaC運用で起きやすい代表的な問題は次の通りです。
- 同じstateに対するterraform plan/apply衝突によるロックエラー
- 環境（dev/stg/prd）の差分が把握できず、本番だけドリフトが累積する
- PRレビュー観点が共有されておらず、危険な変更が承認されてしまう
- 手動コンソール操作が後追いコミットされず、コードと現実が乖離する
これらは「ツールの使い方」ではなく「ブランチ・ワークフロー・責任分界点」の設計問題なので、ガードレールをCI側で組み立てるのが最短ルートです。
IT女子 アラ美
ITアライグマ前提条件と環境整理
本記事で想定する読者は、AWS / Azure / GCP のいずれかでTerraformを2〜10名規模のチームで運用しているインフラエンジニア・SRE・PjMです。Terraform v1.6以上、リモートstate（S3+DynamoDB / AzureRM / GCS）、GitHub ActionsのOIDC連携が利用できる前提で進めます。これらが揃っていない場合は、まずローカルstateからリモートstateへの移行と、IAM Role / Service Principalの整備を先に済ませてください。
IaCツール選定そのものに迷いがあるチームは、Terraform vs Ansible vs CloudFormationの違い・選定基準・乗り換えコスト徹底比較で整理した通り、宣言的な状態管理＋クラウドポータビリティを重視するならTerraformが最も無難な選択肢になります。本記事はTerraformを前提に話を進めます。
具体的に揃えておくべき前提条件は次の通りです。
- Terraform v1.6以上（プロバイダーロックファイルが安定して扱える）
- S3 / DynamoDBやAzureRM / GCSなどのリモートstateバックエンド
- GitHub Actions側のOIDCで一時クレデンシャル発行（長期キーをSecretsに置かない）
- 環境ごとに分離されたIAM RoleまたはService Principal（最小権限原則）
- 本番applyを実行できるユーザー / Teamの定義（CODEOWNERSやenvironment protection rules）
これらが揃っていれば、本記事のブランチ戦略・PRレビュー設計をそのまま適用できます。揃っていない場合は、まず環境分離とstate管理から手を付けるのが先です。
IT女子 アラ美ITアライグマステップ1：基本的な実装・設定
最初に固めるべきは「環境ごとのディレクトリ分離」「ブランチ命名規則」「PR時に必ず動くterraform planワークフロー」の3点です。順番に決めていきます。
ディレクトリ構成は、環境ごとにstateとtfvarsを分け、共通モジュールはmodules/配下にまとめます。
infra/
├── environments/
│ ├── dev/
│ │ ├── main.tf
│ │ ├── backend.tf
│ │ └── terraform.tfvars
│ ├── stg/
│ │ └── ...
│ └── prd/
│ └── ...
├── modules/
│ ├── network/
│ ├── compute/
│ └── data/
└── .github/workflows/
├── iac-plan.yml
└── iac-apply.yml
ブランチ命名規則は、変更対象の環境とリソース種別がひと目で分かるようにfeature/<env>/<scope>-<summary>の形を推奨します（例: feature/stg/network-add-subnet）。mainブランチは常に本番（prd）と一致させ、stg / dev はそれぞれのlong-livedブランチに対するPRで反映する運用にすると、planの対象環境がブランチから判別できます。
GitHub Secretsの扱いは、IaC運用では特に厳格にしたい部分です。envguardでシークレット流出を防ぐCI設計：チーム導入で押さえる運用ルールと教育の実務ガイドで解説した通り、長期シークレットを直接Secretsに置くのではなく、OIDC連携で短期トークンを取得する構成にしてください。
PR時に動かすiac-plan.ymlの最小構成は次のようになります。
name: iac-plan
on:
pull_request:
paths:
- "infra/**"
permissions:
id-token: write
contents: read
pull-requests: write
jobs:
plan:
runs-on: ubuntu-latest
strategy:
matrix:
env: [dev, stg, prd]
steps:
- uses: actions/checkout@v4
- uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/gha-iac-${{ matrix.env }}
aws-region: ap-northeast-1
- uses: hashicorp/setup-terraform@v3
- run: terraform init
working-directory: infra/environments/${{ matrix.env }}
- run: terraform plan -no-color -out=tfplan
working-directory: infra/environments/${{ matrix.env }}
このワークフローはPRに含まれるパスがinfra/**の場合のみ走り、3環境のplanを並列実行します。OIDCで環境ごとのRoleをAssumeする構成なので、長期シークレットは一切使いません。planの結果は次のステップ2でPRコメントに自動投稿する形に拡張します。
IT女子 アラ美ITアライグマステップ2：発展的な活用・応用パターン
基本のplanワークフローが動くようになったら、次は「PRコメントへのplan結果投稿」「ドリフト検知の定期実行」「本番applyの承認フロー」を順に積み上げます。これによってレビュー負荷を抑えつつ、ドリフト・不正applyを検知できる体制になります。
PRコメントへのplan結果投稿は、レビュアーが差分をPR上で確認できるようにする仕組みです。hashicorp/setup-terraformのラッパーアクションやgithub-scriptを使い、terraform planの出力をMarkdownでactions/github-scriptからPRにコメントします。差分が長い場合は<details>タグで折りたたみ、No changesの場合はコメントを省略するとPRが見やすくなります。
ドリフト検知はnightly cronで全環境のterraform planを実行し、差分が検出された場合のみSlack通知＋GitHub Issueを自動起票する構成が現実的です。手動コンソール操作はゼロにできない以上、検知の仕組みを入れておくと「気づかないうちに本番だけドリフトする」状態を防げます。Secrets経由で漏れた認証情報が悪用された場合の検知体制は、GitHubにシークレットを混入させない多層防御ガイドでカバーした多層防御と合わせて整備すると安心です。
本番applyの承認フローは、GitHub Actionsのenvironment機能とprotection rulesを組み合わせます。prd環境のapplyジョブをenvironment: productionに紐付け、必須レビュアー2名・待機時間5分などのルールを設定すると、人間の二重チェックなしには本番applyが走らない構成になります。
実装上のポイントを整理すると次の通りです。
- plan結果はPRコメントに自動投稿し、レビュアーが差分のみを見て判断できるようにする
- ドリフト検知はnightly cronで全環境を回し、差分のみSlack通知＋Issue起票
- 本番applyはGitHub Environmentsのprotection rulesで必須レビュアーと待機時間を設定する
- OPA / Conftestでpolicy as codeを導入し、危険なリソース変更を自動ブロックする
- applyログはCloudWatch / Cloud LoggingやS3に集約し、いつ誰が何を変えたかを監査可能にする
特にPolicy as Codeは、s3:PublicAccessBlockの解除・セキュリティグループの全開放・本番DBのprevent_destroy解除など、レビュアーが見落としやすい危険変更をCI側で自動ブロックできるため、規模が大きいチームほど投資対効果が高い領域です。
IT女子 アラ美ITアライグマ実装後の効果検証（ケーススタディ）
IT女子 アラ美実際に複数人IaC運用のブランチ戦略を導入した、田島さん（仮名・36歳・SREリード・経験8年）の事例を紹介します。SaaS企業のSREチーム10名で、AWSのリソース約400個をTerraformで管理しており、まさに本記事の典型ターゲットです。
状況（Before）
- 環境（dev/stg/prd）が同一stateにまとまっており、
terraform planに毎回12分かかる - ブランチ命名はメンバーごとにバラバラで、レビューの優先順位がPRタイトルから読み取れない
- 本番applyは「Slackで一声かけて手動実行」運用で、月2回ペースでドリフト事故が発生
- plan衝突によるリトライ・調整工数が月160時間（チーム合計）まで膨らみ、本来の改善業務に時間が割けない
田島さんは「本番だけ手動コンソールで触られた変更を、誰がいつどう戻したか追えなくなった」のがきっかけで、ブランチ戦略の刷新に踏み切りました。
行動（Action）
- 環境別ディレクトリへ分離し、stateを3つに分割（dev / stg / prd）
- ブランチ命名規則を
feature/<env>/<scope>-<summary>に統一し、レビュー観点を環境ベースで揃える - PR時の
terraform planをマトリックス実行し、結果をPRコメントに自動投稿 - nightly cronでドリフト検知を導入し、検知時はSlack＋GitHub Issueに自動起票
- 本番applyはGitHub Environmentsのprotection rulesで必須レビュアー2名＋5分待機を設定
- OPA / Conftestで「セキュリティグループの全開放」「本番DBのprevent_destroy解除」を自動ブロック
導入時は「stateを分けることでモジュール参照が増える」「PRコメントが冗長になる」といった反発もありましたが、まずdev環境だけで2週間試した上でstg / prdに横展開する方針で進めました。
結果（After）
terraform planの実行時間が12分→平均3分（環境ごとに並列実行されるため）- plan衝突によるリトライ・調整工数が月160時間→月30時間（81%削減）
- ドリフト事故が月2件→直近3ヶ月で0件継続
- 本番applyの誤実行・深夜帯applyが完全にゼロ化
- 新メンバーのオンボーディング期間が2週間→3日に短縮（ブランチ命名規則とPRコメントだけで意図が読める）
田島さん本人は「最初に環境分離をやる勇気がなかったのが一番の機会損失だった」「stateを分ける前に承認フローを入れても、結局衝突は解消しない」と振り返っています。IaC運用設計の経験は、レガシー手動運用から脱却したい多くの企業で求められているスキルセットであり、サーバー基盤の刷新を進める法人案件にもそのまま転用できます。基盤選定そのものに関わるなら、法人向けサーバー・インフラサービス5社比較のような選定軸を持っておくと、IaC運用と地続きで提案できるようになります。
IT女子 アラ美ITアライグマよくある質問
Q. 2〜3人の小規模チームでも、ここまで本格的なブランチ戦略は必要ですか？
A. 全部入れる必要はありませんが、環境別ディレクトリ分離・リモートstate・PR時のterraform plan自動化の3点は人数に関わらず最初から導入をおすすめします。これだけでstateロック衝突とドリフトの大半は防げます。承認フロー・Policy as Codeは5名超えくらいから検討で十分です。
Q. terraform planの結果をPRコメントに自動投稿する具体的な方法は？
A. hashicorp/setup-terraform@v3の組み込み機能で出力を取得し、actions/github-scriptでPR本文にコメント投稿する構成が一般的です。差分が長くなりやすいので、<details>タグで折りたたみ・No changes時はコメントをスキップする処理を入れると、PR画面が見やすくなります。
Q. ドリフト検知でドリフトが見つかった場合、自動でTerraformコードに反映してもいいですか？
A. 自動反映は推奨しません。ドリフトの多くは「コンソールで一時対応した結果」であり、根本原因の調査前にコード反映すると、本来戻すべき変更を正規化してしまう恐れがあります。検知→Issue起票→人間がレビュー→コード反映 or ロールバック、という流れに留めるのが安全です。
Q. GitHub ActionsではなくGitLab CIやCircleCIを使っている場合でも同じ設計は適用できますか？
A. 適用できます。OIDC連携・環境別ジョブのマトリックス実行・承認フローはどのCI/CDサービスでも実装可能です。本記事のYAML例はGitHub Actions形式ですが、概念（環境分離・PR時plan・本番apply承認）はそのまま他のCI/CDに移植できます。
Q. 既存のmonolithic stateから環境別stateへ分割する場合、ダウンタイムは発生しますか？
A. terraform state mvまたはterraform state rm + terraform importで論理的に分割するだけならダウンタイムは発生しません。ただしバックエンド設定の切り替えで一時的にstateが2系統存在する瞬間があるため、メンバー全員に作業時間を周知し、その間は他のapplyを止める運用が必要です。
IT女子 アラ美ITアライグマさらなる実践・活用に向けて
ブランチ戦略が安定したあとに次に取り組みたいのは、「stateモジュール分割」「Atlantis / Spaceliftの導入判断」「IaC運用経験のキャリアへの転換」の3点です。順に整理します。
stateモジュール分割は、リソースが500を超えてからplan時間が再び肥大化するタイミングで検討します。network・compute・data・securityのように責務単位でstateを分け、各stateごとにバージョン管理する形にすると、影響範囲が局所化されてレビューも楽になります。ただし最初から細かく分けすぎると、依存解決の手間でかえって運用負荷が上がるため、痛みを感じてから分割するくらいの方が現実的です。
Atlantis / Spaceliftの導入は、PRコメント駆動のterraform plan / applyを専用基盤に任せる選択肢です。GitHub Actionsで自前構築するよりUIが洗練されており、複数stateの依存関係も可視化できます。ただし月数万円〜のコストがかかるため、チーム規模・state数・運用人件費を計算して比較する必要があります。社内向けに本気のIaCプラットフォームを構築する段階で初めて検討に値する選択肢です。
IaC運用経験のキャリア転換は、本記事の読者にとって意外に大きなテーマです。Terraform / GitHub ActionsでマルチアカウントAWSを安定運用できるエンジニアは、社内SE・SRE・プラットフォームエンジニアいずれの求人でも引く手あまたで、レガシー手動運用から脱却したい企業の指名買いが起きやすい層です。社内SE転職市場での具体的な動き方は社内SEになるには？転職エージェント比較とキャリア設計ガイドで整理しているので、IaC運用設計の主導経験がある方は一度市場価値を測ってみる価値があります。年収重視で動くならエンジニアのハイクラス転職エージェント3社比較を、ハイクラス特化型のエージェントを横並びで見比べると判断が早くなります。
ここで、レガシー手動運用からIaC運用への転換を進めたいエンジニア向けに、キャリアチェンジを支援するエージェントを比較した一覧を用意しました。「SES脱出」「SIer→Web系」「レガシー環境からの転換」のいずれかに当てはまる方は、まず自分の市場価値を匿名でチェックしてから動くのが最短ルートです。
SES・SIerから自社開発企業へのキャリアチェンジや、年収アップを目指すなら、IT経験者向けの転職エージェントを活用しましょう。
| 比較項目 | ユニゾンキャリア | TechClipsエージェント | レバテックキャリア |
|---|---|---|---|
| 年収アップ実績 | 100万円単位のUP事例年収交渉に強い | 9割以上が年収UP離職ゼロ実績 | IT専門の条件交渉大手の安心感 |
| 求人の特徴 | 優良企業を厳選 | 自社開発企業特化 | SaaS・Web系豊富 |
| カウンセリング | Google★4.8の高評価 | 現役エンジニア対応 | 専任アドバイザー |
| おすすめ度 | 年収UPなら必須 | A自社開発狙いなら | A幅広く探すなら |
| 公式サイト | 無料相談する | - | - |
IT女子 アラ美ITアライグマまとめ
複数人でTerraformを運用する際の悩みの大半は、ツールの使い方ではなく「並列開発を前提にした設計が抜けている」ことが原因です。本記事で紹介した環境分離・ブランチ命名規則・PR時terraform plan自動化の3点を最初に固め、そのうえでドリフト検知・本番apply承認フロー・Policy as Codeを段階的に積み上げていけば、月160時間規模で消耗していたstate衝突や本番事故を、現実的に1/5以下に圧縮できます。
明日からの一歩として、まずは次のどれか1つから着手してみてください。
- 環境別ディレクトリへの分離とリモートstateの導入（最優先）
- ブランチ命名規則
feature/<env>/<scope>-<summary>の統一 - PR時の
terraform plan自動実行ワークフロー作成 - nightly cronによるドリフト検知Issue起票の仕組み化
- 本番applyのGitHub Environments protection rules設定
IaC運用設計はチーム生産性に直結するだけでなく、レガシー手動運用から脱却したい企業の指名買いが起きやすいキャリア領域でもあります。手を動かして仕組みを作り、その経験を市場価値として明文化しておくのが、これからのインフラ系エンジニアの最短コースだと考えています。
IT女子 アラ美ITアライグマ
