Google CloudをTerraformで効率的に管理する！主要リソースの設定と活用法

TerraformによるGCPインフラ自動化の全体像と最短アプローチ

なぜ今、GCPでTerraformを使うべきなのか？

クラウド環境の複雑化と大規模化が進む現代において、手動でのインフラ管理はヒューマンエラーのリスクを増大させ、構成の再現性や運用効率の低下を招きます。このような課題を解決するのがIaC（Infrastructure as Code）であり、その代表的なツールがTerraformです。Terraformは、GCPを含む多様なクラウドプロバイダーのインフラをコードとして定義し、自動的にプロビジョニング・管理することを可能にします。これにより、開発・運用チームは一貫性のある環境を迅速に構築でき、変更履歴もコードで追跡できるため、ガバナンスが向上します。特に日本国内では、2030年には最大約79万人ものIT人材が不足すると予測されており（経済産業省 2019年3月）、IaCによる自動化は、限られたリソースで効率的なインフラ運用を実現するための喫緊の課題への解決策となり得ます。

また、世界のIaC市場規模は2026年から2035年にかけて年平均成長率（CAGR）24.3%で拡大すると予測されており（Global Market Insights Inc. 2026年7月）、この潮流は今後も加速していくでしょう。GCPにおけるTerraformの導入は、インフラ管理を標準化し、将来の成長に合わせた拡張性を確保するための重要な一歩となります。手動運用からの脱却は、組織全体のDX推進において不可欠な要素であり、IaCの導入は単なる技術導入に留まらず、運用文化そのものを変革する可能性を秘めています。

TerraformによるGCPインフラ自動化の基本原則

TerraformがGCPインフラを管理する基本的な仕組みは、「あるべき状態（Desired State）」をコードで定義し、現在のクラウド環境との差分を自動的に解消する点にあります。ユーザーはHCL（HashiCorp Configuration Language）という宣言的な言語を用いて、GCPのプロジェクト、ネットワーク、仮想マシン、データベースといったリソースの構成を記述します。例えば、特定のリージョンに仮想マシンを何台、どのようなスペックで作成するか、あるいは特定のストレージバケットをどのようなセキュリティ設定で配置するか、といった情報をコードとして記述するのです。

Terraformを実行すると、まずterraform planコマンドで、記述されたコードと現在のGCP環境との間にどのような変更が必要か（新規作成、変更、削除）を詳細に提示します。このプランを確認し、意図した変更であることを承認した上でterraform applyコマンドを実行することで、TerraformはGCPのAPIを通じて必要なリソースを自動的にプロビジョニングまたは修正します。このプロセスにより、手動操作で発生しがちな設定ミスや抜け漏れを防ぎ、常に定義されたコード通りの状態を維持することが可能になります。また、環境構築が再現可能になるため、開発、ステージング、本番といった複数の環境を迅速かつ一貫性を持って展開できるようになります。

スムーズな導入のための最短アプローチと準備

TerraformをGCP環境にスムーズに導入するためには、いくつかの準備と心構えが重要です。まず、TerraformのHCL構文だけでなく、GCPの基本的なサービス（VPC、IAM、GCE、GCSなど）に関する知識が不可欠です。厚生労働省の職業情報提供サイト（job tag）でも、システムエンジニア（基盤システム）の職務要件として、クラウド全般のネットワーク・セキュリティの基礎知識が挙げられています。この基礎知識がなければ、コードを記述する際だけでなく、トラブルシューティング時にも課題に直面しやすくなります。

次に、Terraformを導入する際は、いきなり全てのリソースを自動化しようとせず、まずは小規模なプロジェクトや非本番環境から始めるのが良いでしょう。簡単な仮想ネットワークやストレージバケットの作成から着手し、徐々に管理範囲を広げていくことで、チームメンバーの習熟度を高められます。ガートナーの調査では、日本国内においてIaCが「幻滅期」に位置付けられることもあると指摘されていますが（エンタープライズジン 2026年2月）、これは導入したものの運用が続かないケースが散見されることを示唆しています。これを回避するためには、単なるツール導入に終わらせず、プラットフォームエンジニアリングの視点を取り入れ、組織全体でIaCのメリットを享受し続けるための運用体制や文化を同時に育むことが成功への鍵となります。

出典：経済産業省, Global Market Insights Inc., 厚生労働省, エンタープライズジン

主要GCPリソースをTerraformで構築する実践ステップ

GCPプロジェクトと基本的なネットワークの構築

GCP環境をTerraformで管理する最初のステップは、GCPプロジェクトと基本的なネットワークインフラの構築です。Terraformではgoogle_projectリソースを使用して新しいプロジェクトを作成し、請求アカウントと関連付けることができます。その後、google_compute_networkリソースでVPC（Virtual Private Cloud）ネットワークを定義し、google_compute_subnetworkリソースでサブネットを作成します。これらの設定は、GCPリソース間の分離と接続性を確保するための基盤となります。

コード例としては、以下のような構造が考えられます。

resource "google_project" "my_project" {
  name       = "my-terraform-project-001"
  project_id = "my-terraform-project-001"
  org_id     = "your-organization-id"
  billing_account = "your-billing-account-id"
}

resource "google_compute_network" "vpc_network" {
  project                 = google_project.my_project.project_id
  name                    = "my-vpc-network"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet_us_east" {
  project       = google_project.my_project.project_id
  name          = "my-subnet-us-east"
  ip_cidr_range = "10.0.1.0/24"
  region        = "us-east1"
  network       = google_compute_network.vpc_network.id
}

この段階で、terraform planを実行して意図した変更が反映されるか確認し、問題なければterraform applyで適用します。これにより、インフラの基盤がコードによって一貫して管理される状態が確立されます。特に、ネットワーク設定は後続のリソースに大きな影響を与えるため、慎重な設計とコード化が重要です。

セキュアな状態管理と認証設定の確立

Terraformにおける状態管理（State Management）は、現在のGCPリソースの状態を記録し、コードと実際の環境との差分を判断するために不可欠です。このステートファイルは機密情報を含むため、ローカルに保存するのではなく、Google Cloud Storage（GCS）にバックエンドとして保存することがベストプラクティスです。GCSを利用することで、ステートファイルの共同編集時のロック機能、バージョニングによる変更履歴の保持、そしてアクセス制御によるセキュリティ確保が可能になります。これにより、チーム開発におけるコンフリクトを回避し、過去の任意の時点の状態に復元できる堅牢な運用基盤を築けます。

GCSバックエンドを設定するには、backend "gcs"ブロックをterraformブロック内に記述します。

terraform {
  backend "gcs" {
    bucket  = "my-terraform-state-bucket"
    prefix  = "terraform/state"
  }
}

認証に関しては、GCPサービスアカウントのキーを直接Terraformに渡すのではなく、Workload Identityなどのセキュアな連携方法を利用することが強く推奨されます。Workload Identityは、KubernetesサービスアカウントをGCPサービスアカウントにバインドすることで、キーファイルなしでGCPリソースに安全にアクセスできるようにする機能です。これにより、キーファイルの流出リスクを排除し、最小権限の原則に基づいたIAM管理を実現できます。適切な認証設定は、Terraform運用におけるセキュリティの根幹をなす要素であり、運用開始前に確立すべき重要なステップです。

再利用可能なモジュール設計で効率化を図る

TerraformでGCPインフラを効率的に管理するためには、リソースごとのモジュール分割が極めて重要です。モジュールは、関連する一連のリソースをまとめて再利用可能な単位としてパッケージ化する機能であり、これによりコードの重複を排除し、保守性を向上させることができます。例えば、VPCネットワーク、仮想マシン、データベースといった機能ごとにモジュールを作成し、異なる環境（開発、ステージング、本番）や異なるプロジェクトで共通のコンポーネントとして利用することが可能です。

推奨されるディレクトリ構造は、modules/ディレクトリに汎用的なモジュールを配置し、environments/ディレクトリに各環境固有の構成定義ファイルを配置する形式です。例として、

.
├── modules/
│   ├── vpc/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
│   ├── gce/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── outputs.tf
├── environments/
│   ├── dev/
│   │   └── main.tf
│   ├── prod/
│   │   └── main.tf
└── main.tf (root configuration)

このような構造にすることで、environments/dev/main.tfからはmodules/vpcやmodules/gceを呼び出す形でインフラを定義し、環境ごとの差異はvariablesで吸収できます。モジュール設計を適切に行うことで、新しい環境のプロビジョニングを迅速化し、コードの一貫性を保ちながら、大規模なインフラを効果的に管理することが可能になります。これは、運用のベストプラクティスであり、長期的なTerraform運用の成功に直結する重要な要素です。

シナリオ別GCPリソースのTerraformコード例と応用パターン

Webアプリケーション環境をTerraformで構築する

一般的なWebアプリケーション環境をGCPに構築する際、Terraformを使用することで、仮想マシン（Compute Engine）、ロードバランサ（Cloud Load Balancing）、データベース（Cloud SQLまたはCloud Spanner）などを一貫して管理できます。例えば、Compute EngineインスタンスグループとHTTP(S)ロードバランサを組み合わせることで、トラフィックの分散と高可用性を実現します。さらに、Cloud SQLのようなマネージドデータベースサービスをTerraformでプロビジョニングすることで、手動でのセットアップや設定ミスを防ぎ、インフラのデプロイを自動化できます。

基本的なコード例としては、ロードバランサとバックエンドサービス、インスタンステンプレート、インスタンスグループマネージャを組み合わせて、スケーラブルなWebサーバ群を構築します。データベースは、Cloud SQLのPostgreSQLインスタンスをプロビジョニングし、ユーザー、パスワード、IP許可リストなどをコードで定義します。このように、アプリケーションのインフラ要件をTerraformコードとして完全に定義することで、開発環境から本番環境まで、迅速かつ確実な環境デプロイが可能になります。また、環境間の差異は変数ファイルで管理し、共通のモジュールとして再利用することで、管理の複雑さを軽減できます。

データ分析基盤をコードで管理する

現代のビジネスにおいて不可欠なデータ分析基盤も、Terraformを活用することで効率的に管理できます。GCPにおけるデータ分析の主要なサービスには、大規模データウェアハウスのBigQuery、オブジェクトストレージのCloud Storage、データ処理パイプラインのCloud Dataflowなどがあります。Terraformを使用すれば、これらのリソースをコードとして定義し、BigQueryのデータセットやテーブル、Cloud Storageバケット、Cloud Dataflowジョブの実行環境などを自動的にプロビジョニングできます。

例えば、BigQueryデータセットを作成し、特定のテーブルスキーマを定義するコード、あるいはCloud Storageバケットの作成とライフサイクル管理ポリシーを設定するコードを記述します。これにより、データエンジニアリングチームは、データ分析環境のセットアップ時間を大幅に短縮し、分析に集中できる環境を整えることが可能です。また、データ基盤のバージョン管理がコードで行われるため、変更履歴の追跡や監査が容易になり、ガバナンスが強化されます。データソースの変更や新しい分析要件が発生した場合でも、Terraformコードを更新するだけで迅速に対応できるため、アジリティの高いデータ基盤運用が実現します。

Serverless FunctionとAPI Gatewayの統合

マイクロサービスやイベント駆動型アーキテクチャの文脈で利用が増えているServerless Function（Cloud FunctionsやCloud Run）とAPI Gatewayの統合も、Terraformで一元的に管理できます。Cloud Functionsはイベントに応答する軽量なコードを実行し、Cloud Runはコンテナ化されたサービスをフルマネージドでデプロイします。これらをAPI Gatewayと組み合わせることで、堅牢なAPIエンドポイントを公開し、バックエンドのビジネスロジックを実行するモダンなアプリケーションを構築できます。

Terraformでは、google_cloudfunctions_functionやgoogle_cloud_run_serviceリソースを用いて関数やサービスをデプロイし、トリガーやIAM権限を設定します。さらに、google_api_gateway_apiとgoogle_api_gateway_api_configリソースを使ってAPI Gatewayを設定し、デプロイしたServerless Functionへのルーティングを定義します。これにより、APIのライフサイクル管理からバックエンドサービスのデプロイまでをコードで自動化し、開発から本番環境へのCI/CDパイプラインに容易に組み込めます。手動での設定ミスを排除し、デプロイの一貫性と信頼性を高める上で、Terraformによる管理は非常に効果的です。

Terraform for GCP運用で注意すべき一般的な失敗と回避策

ステートファイル破損とバージョン管理の重要性

Terraformのステートファイルは、GCP環境の現在の状態とTerraformコードで定義されたDesired Stateとの差分を判断するために不可欠なファイルです。このステートファイルが破損したり、意図しない変更が加えられたりすると、Terraformが正しく機能しなくなり、最悪の場合、インフラが不整合な状態に陥る可能性があります。ローカル環境にステートファイルを置いたままチームで作業を行うと、互いの変更が上書きされてしまったり、誤って削除してしまったりするリスクが高まります。

この失敗を回避するためには、前述の通りGCSをバックエンドとして利用することが最も効果的です。GCSバックエンドは、ステートファイルの共同編集時にロックをかけ、複数ユーザーによる同時変更を防ぐ機能を提供します。また、GCSのオブジェクトバージョニング機能を有効にすることで、ステートファイルの変更履歴が自動的に保持され、万が一破損した場合でも過去の健全な状態に復元することが可能です。さらに、terraform stateコマンドを使ってステートファイルを手動で編集することは避けるべきです。どうしても修正が必要な場合は、十分に注意し、バックアップを取得した上で行うべきです。計画的な運用を心がけることで、ステートファイルの安全性を確保し、安定したIaC運用を実現できます。

IAM権限の過剰付与と最小権限の原則

Terraformを使用してGCPリソースを管理する際、Terraformを実行するサービスアカウント（またはユーザー）に与えるIAM権限は、セキュリティ上極めて重要な考慮事項です。安易にプロジェクトオーナーなどの広範な権限を付与してしまうと、Terraformコードの誤りや悪意ある操作によって、意図しないリソースの変更や削除、機密情報の漏洩といった重大なセキュリティインシデントに繋がる可能性があります。最小権限の原則は、必要なリソースに対して、必要な操作を行うための最小限の権限のみを付与するというセキュリティの基本原則です。

この原則を実践するためには、TerraformがプロビジョニングするGCPリソースと、それぞれのリソースに対する操作（作成、読み取り、更新、削除）を詳細に洗い出し、それに合致するカスタムIAMロールを作成することが望ましいです。例えば、Compute Engineを管理するサービスアカウントには、compute.instances.createやcompute.instances.deleteなどの権限のみを付与し、Cloud Storageバケットにはstorage.buckets.createといった具体的な権限を割り当てます。さらに、認証にはGCPサービスアカウントキーを直接扱うのを避け、Workload Identityなどのセキュアな方法を利用することで、キーの漏洩リスクを根本的に排除できます。権限設定は常にレビューの対象とし、定期的に見直すことで、セキュリティリスクを最小限に抑えることが可能です。

意図しないリソース変更を防ぐための戦略

Terraformは強力な自動化ツールである反面、誤ったコードや不注意な操作が意図しないGCPリソースの変更や削除を引き起こすリスクも内包しています。特に本番環境においては、サービス停止やデータ損失に直結する可能性があるため、これらのリスクを最小限に抑えるための戦略が不可欠です。Terraformの運用で最も基本的な対策は、terraform planコマンドを徹底的に活用することです。terraform planは、実際に変更を適用する前に、どのようなリソースが作成、変更、削除されるかを詳細にプレビューします。このアウトプットをチームメンバーでレビューするプロセスを義務付けることで、誤った変更が適用される前に発見しやすくなります。

さらに、より高度なガバナンスを確保するためには、Policy as Codeツールを導入することが有効です。例えば、HashiCorp SentinelやOpen Policy Agent (OPA)などのツールは、Terraformコードが組織のセキュリティポリシーやコスト最適化ポリシーに準拠しているかを自動的にチェックできます。これにより、「特定のリージョン以外でのリソース作成を禁止する」「インスタンスタイプの上限を設ける」といったガバナンスルールをコードで定義し、強制することが可能になります。CI/CDパイプラインにこれらのチェックを組み込むことで、ポリシー違反のデプロイを未然に防ぎ、より安全で一貫性のあるGCPインフラ運用を実現できます。

【ケース】本番デプロイ時の依存関係エラーを解決した改善事例

複雑な依存関係が引き起こすデプロイエラーの課題

（架空のケース）ある日、弊社で担当していたGCP上のマイクロサービス環境で、Terraformによる本番デプロイ時に予期せぬ依存関係エラーが発生しました。エラーの内容は、Cloud Functionsのデプロイが完了する前に、その関数をトリガーとするCloud Schedulerジョブが作成されようとし、結果としてジョブの作成に失敗するというものでした。この環境では、複数のマイクロサービスが相互に連携し、それぞれがCloud Functions、Cloud Run、Cloud SQL、Pub/Subといった多種多様なGCPリソースで構成されていました。開発当初は小規模だったため、単一のTerraformステートで全ての環境を管理していましたが、サービスの増加と複雑化に伴い、Terraformの実行計画が数百のリソースに及び、terraform applyの実行時間が長大化していました。

このような状況下では、Terraformが自動的に解決する依存関係だけでは不十分なケースが発生します。特に、サービスが別々のTerraformモジュールで管理されている場合や、非同期的にプロビジョニングされるリソース間では、Terraformが推測できない明示的な依存関係を定義する必要が出てきます。今回のケースでは、Cloud FunctionsのデプロイとCloud Schedulerのジョブ作成の順序が重要であり、Terraformがその順序を自動で認識できなかったことがエラーの直接的な原因でした。複雑化したステートファイルと、リソース間の隠れた依存関係が、デプロイの安定性を著しく損ねていたのです。

モジュール分割とリモートステート活用による解決策

上記のエラーを解決するために、私たちはTerraformのベストプラクティスに基づいた運用改善に着手しました。まず、モノリシック化していたTerraform構成を、マイクロサービスごとに独立したモジュールに分割しました。具体的には、Cloud Functionsとそれに関連するIAMポリシー、トリガー設定を一つのモジュールとして定義し、Cloud Schedulerのジョブも別のモジュールとして切り出しました。これにより、各モジュールの責任範囲を明確にし、Terraformの実行計画を小さく保つことが可能になりました。

次に、各モジュールのステートファイルをGoogle Cloud Storage（GCS）に個別に保存するリモートステート管理を導入しました。これにより、各モジュールが独立してデプロイできるようになり、特定のモジュールに変更があっても、関連するステートのみが更新されるため、全体への影響範囲を局所化できました。さらに、モジュール間の明示的な依存関係を定義するために、terraform_remote_stateデータソースを使用して、Cloud Functionsモジュールのアウトプット（例：デプロイされた関数のURL）をCloud Schedulerモジュールが参照するようにしました。これにより、Cloud Functionsが完全にデプロイされた後にCloud Schedulerジョブが作成されることが保証され、デプロイ時の依存関係エラーを完全に解消することができました。この変更により、デプロイの信頼性が大幅に向上し、サービス停止のリスクを低減できました。

継続的な改善のための運用フローとコードレビューの強化

依存関係エラーの解決にとどまらず、私たちは将来的な問題発生を防ぐための継続的な運用改善にも取り組みました。まず、Terraformコードの変更には、必ずCI/CDパイプラインを介したデプロイを義務付けました。パイプライン内では、terraform validateによる構文チェック、terraform fmtによるコードフォーマットの統一、そしてterraform planによる変更内容のレビューを自動的に実施するようにしました。特にterraform planのアウトプットは、Slackなどのコミュニケーションツールに通知されるように設定し、チームメンバー全員が変更内容を確認し、問題があれば指摘できる体制を構築しました。

さらに、Terraformコードの定期的なレビュープロセスを導入しました。これにより、コードの品質維持だけでなく、GCPリソースの利用状況やセキュリティ設定、IAM権限の適切性などを継続的にチェックできるようになりました。また、新しいリソースを導入する際には、事前にアーキテクチャレビューを実施し、Terraformでの管理方法や依存関係、モジュール設計について議論する場を設けています。これらの取り組みにより、属人性を排除し、チーム全体でTerraformの運用知識を共有しながら、インフラの堅牢性と開発の効率性を両立させる文化を醸成しています。インフラのコード化は一度やれば終わりではなく、継続的な改善が不可欠であることを改めて実感しました。