Terraform連載2026 の3本目です。

1. はじめに

こんにちは。製造エネルギーグループの片岡久人です。

インフラストラクチャをコードで管理する「Terraform」と、そのマネージドサービスである「Terraform Cloud（現：HCP Terraform）」についての入門的な話をします。

後半では、私が普段関わっているようなサーバーレスアーキテクチャのプロジェクトにおいて、導入時に気をつけたい「コストの落とし穴」と、それを踏まえてアーキテクチャ選定時の考え方についても深堀りしてみたいと思います。

2. Terraformとは？

まず、Terraform自体について軽くおさらいしましょう。

Terraformは、HashiCorp社が提供しているIaC（Infrastructure as Code）ツールです。

AWS、Google Cloud、Azureなどのクラウドインフラはもちろん、様々なSaaSの設定などを、HCL（HashiCorp Configuration Language）という宣言的なコードで定義・構築ができます。「画面（コンソール）をポチポチ操作してインフラを作る」のではなく、「コードを書いて実行したらインフラができる」という状態を作れるため、作業の自動化やレビューがしやすくなるのが特徴です。

3. Terraform Cloud（現：HCP Terraform）とは？

次にマネージドサービス側のお話です。

名称についてですが、HashiCorp Cloud Platform（HCP）へのブランド統合の一環として、2024年4月に「Terraform Cloud（TFC）」から「HCP Terraform」へと公式に名称変更されました。（その後2025年2月にIBMによる買収が完了するなど、周辺環境にも大きな変化が起きています）

手元のPC単体でTerraformを実行する場合、インフラの現状を記録する「State（状態）ファイル」の管理や、複数人での同時作業による競合などが大きな課題になります。HCP Terraformは、これらの課題を解決し、チーム開発を安全かつ効率的に行うための様々な機能をSaaSとして提供してくれます。具体的には以下のような点が非常に便利です。

Stateファイルの安全な一元管理とロック

OSS版のTerraformをチームで使う場合、AWSのS3などを自前で用意してStateファイルを共有し、同時実行の競合を防ぐ『ロックの仕組み』を別途構築する必要があります。

HCP Terraformでは、これらが標準機能として最初から用意されているため、バックエンドの設計に悩むことなく安全なチーム開発を始められます。

柔軟なリモート実行と自動化

GitHubなどのバージョン管理システム（VCS）と連携することで、CI/CDパイプラインを簡単に構築できます。

Pull Request作成時：自動で terraform plan（プレビュー）を実行
マージ時：自動で terraform apply（適用）を実行

CLIやAPIからの実行時もクラウド上のリモート環境で処理されるため、ローカルPCの環境依存をなくし、セキュアに一元化することが可能です。

動的プロバイダークレデンシャル

AWSやGoogle Cloud等とOIDC連携することで、実行（Run）のたびに一時的なクレデンシャルを自動発行して利用できます。静的なアクセスキーをHCP Terraform上に手動で保存するリスクがなくなり、セキュリティが大幅に向上します。

ガバナンスとセキュリティ

「特定のサイズのインスタンスしか作成してはいけない」といった社内ルールをコード（SentinelやOPA）で定義し、自動チェックする機能や、きめ細かいロールベースのアクセス制御（RBAC）が可能です。

※プランに関する注意点
FreeプランではOPAを利用した小規模なポリシー適用（1ポリシーセット/5ポリシーまで）に限定されます。HashiCorp独自のSentinelの利用、無制限のポリシー適用、高度なチーム管理機能を利用するには有料プランが必要です。

ドリフト検出

Terraformで管理している設定と、実際のクラウドリソースの設定に差異（手動でこっそり変更されてしまった等）が発生していないかを定期的にチェックして通知してくれます。

※プランに関する注意点
高度な自動スケジュールによるドリフト検出などは上位プラン（Standard&Premium）に限定された機能となります。

チームや組織で本格的にTerraformを運用し、インフラの品質を保つためには、強力なプラットフォームです。

上記で挙げた以外にも、自社専用のモジュールを共有できる「プライベートレジストリ」や、プライベートネットワーク内の隔離されたインフラを管理できる「HCP Terraformエージェント」など様々な機能がありますので、詳細は公式ドキュメントをご確認ください。

4. アーキテクチャ選定とコストの落とし穴

HCP Terraformは非常に便利なツールですが、Cloud Run Functions（旧Cloud Functions）などを多用する「サーバーレス開発」において、「なんでもかんでもTerraformで管理しようとする」と、思わぬコストの罠にハマることがあります。まずは具体的な料金体系とコスト感を見てみましょう。

HCP Terraformの料金体系と具体的なコスト感

現在のHCP Terraformは、RUM（Resources Under Management：管理リソース数）ベースの課金体系を採用しています。つまり、Terraform（Stateファイル）で管理しているリソースの数に比例して月額コストが発生します。

現在は下記のようなプランになっています。
500リソースを超えた場合の各プランの単価（1リソースあたり/月）は以下の通りです。

Freeプラン： 500リソースまで無料 ※参考
Essentialsプラン： $0.10 / 月
Standardプラン： $0.47 / 月
Premiumプラン： $0.99 / 月

※HCP Terraformの課金体系は、IBMによる買収後、プランの統合や単価の見直しが随時行われています。導入検討時には必ず最新の公式価格表を確認してください。

例えば、Standardプランを利用した場合のコスト概算は以下のようになります。

1,000リソースを管理した場合：月額約 $470
5,000リソースを管理した場合：月額約 $2,350
※（管理リソース数-500）× $0.47で算出

コストの落とし穴（リソース爆発の罠）

上記のコスト感（1リソースごとに課金される点）を踏まえた上で、Cloud Run Functionsの関数をデプロイする場合を考えてみましょう。実は1つの関数を動かすために、以下のような複数のリソースが必要になります。

Cloud Run Functionsの関数本体
実行用のIAMサービスアカウント
権限周りのロールバインディング
イベント駆動のためのトリガー
ソースコード配置用のバケット

つまり、1つの関数を追加するだけで、Terraform上では複数個のリソースを消費してしまいます。
また、関数に関連するリソースを追加しようとした場合、関数の個数に比例してリソース数が増えます。
マイクロサービス化で関数が100個、200個と増えていけば、管理リソース数はあっという間に跳ね上がり、気づいた時にはコストがとんでもないことに……という「リソース爆発」が現実味を帯びてきます。

解決策：あえて「コンテナ」に寄せるという選択

この罠を回避するためには、ツールの使い方だけでなく、アーキテクチャそのものをHCP Terraformの課金モデルに寄せて設計するという逆転の発想が有効です。

例えば、細かな関数を並べる代わりに、Cloud Runを採用して複数のエンドポイントを1つのコンテナに集約する構成です。
これにより、Terraformで管理する対象は「Cloud Runの定義（数個のリソース）」に抑えつつ、中身のアプリケーション更新はCI/CDで回す、といった具合に「インフラ管理の堅牢性」と「コスト効率」を両立できます。

「ツールで何でも管理する」のではなく、「ツールの特性（課金モデルなど）に合わせてアーキテクチャ全体を柔軟にデザインする」という視点も、システム設計時のヒントにしていただければ幸いです。

5. まとめ

今回は、TerraformとHCP Terraform（旧Terraform Cloud）の基本的な概要から、サーバーレス環境で利用する際のコストに関する注意点までをご紹介しました。

HCP Terraformはチーム開発において非常に優秀なプラットフォームですが、ツールの特性（特に管理リソース数ベースの課金モデル）と自社のアーキテクチャの相性を理解した上で導入することが重要です。これから導入しようとしている方の参考になれば幸いです。

HCP Terraform（旧Terraform Cloud）の基礎とサーバーレスアーキテクチャ選定のポイント