はじめに
普段 IaC エンジニアをしています。タイトルに書いた通り、Terraformをより大規模で運用するためのプラットフォームである HCP Terraform の主要な機能を紹介する記事です。
現場で経験したことを踏まえて、個人的な意見をところどころに入れています。
優先度も入れてますので参考になればと思います。
また、各トピックごとに公式のリンクを貼っているので、気になる点があれば参照してください。
HCP TerraformはTerraformを大規模に管理することが多くなるため、個人的にはTerraformを使い始めた次のステップで扱うものだと思っています。
この記事がTerraformをコードで管理することに慣れてきた方が、HCP Terraform を検討する際の参考になればと思います。
前提
- 素のTerraform を知っている方が対象。
プランと料金体系
各機能の紹介の前に、HCP Terraform のプランと料金体系について簡単に説明します。
HCP Terraform には主に以下のプランがあります。（2026/05現在）
| プラン | 概要 |
|---|---|
| Free | 無料。基本的な State 管理・Run 実行・VCS 連携が利用可能 |
| Essentials | $0.10/月 per resource 相当。個人や IaC を導入するチーム向け |
| Standard | $0.47/月 per resource 相当。インフラ自動化を標準化する企業向け |
| Premium | $0.99/月 per resource 相当。セキュアなセルフサービスワークフローを実現する企業向け |
※「resource」とは、HCP Terraform が管理するマネージドリソース（managed resources）の数を指します。
基本的には Terraform の State で管理される各リソースが課金対象ですが、一部のリソースはカウント対象外となります。
料金表示は月額換算ですが、実際の課金は managed resources に対する時間単位課金です。
（実際に利用するときは公式ドキュメント、HCP Terraformの管理コンソールで最新の課金対象リソースを確認してください）
この記事で紹介する機能の一部（SSO/SAML、Audit Logging など）は有料プランで利用可能です。
プラン内容や課金対象リソースの詳細は、最新の情報を公式ページで確認してください。
参照:
1. HCP Terraform の全体像
HCP Terraform はクラウドインフラの定義・デプロイ・管理を一元化するためのプラットフォームです。
一言で表すと、
開発者がTerraformコードを変更してから実際にクラウドリソースへ反映されるまでの一連の流れを、ガバナンスを保ちながら自動化できます。
HCP Terraform の構成単位
HCP Terraform の設定は、大きく Organization, Project, Workspace の 3 階層で構成されます。
| 構成単位 | 概要 |
|---|---|
| Organization | HCP Terraform の最上位の管理単位。ユーザー・チーム・課金・SSO などの設定はここで管理する |
| Project | 関連する Workspace をグループ化する単位。チームへの権限付与やタグ管理を Project 単位で行える |
| Workspace | Terraform の State を管理する最小単位。VCS 連携・変数・実行モードなどの設定をここで行う |
各構成が階層的になっていて、イメージは以下の通りです。
設定のカテゴリ分け
この記事では各機能を以下のカテゴリに分けて説明します。
| カテゴリ | 主な機能 |
|---|---|
| 認証・アクセス管理 | SSO/SAML、Teams、OIDC、Vault Integration、Audit Logging |
| 環境管理 | VCS Connections、Organization/Project/Workspace、Variable Sets、Tags |
| デプロイ・実行制御 | Execution Mode、Run Triggers、Agent（Agent Pool）、Auto Destroy |
| コード品質・ガバナンス | Policy Sets、Run Tasks、Cost Estimation |
| モニタリング・通知 | Health Assessments, Notifications |
| モジュール・リソース管理 | Private Registry、No-Code Provisioning、Stacks |
多くの機能がありますが、Terraformを組織で運用する際に必要となる機能が体系的に用意されているイメージです。
2. 認証・アクセス管理
※以降で、各機能に個人的な優先度をついけています。 3 段階で評価しており、★★★ が最も優先度が高いです。
2.1. SSO / SAML 設定（優先度：★★★）
HCP Terraform では SAML 2.0 を用いたSSOに対応しています。
組織の IdP（Azure Active Directory等）と連携することで、HCP Terraform へのログインを一元管理できます。
参照:
2.2. Teams の設定（優先度：★★）
Teams 機能を利用することで、Organization 内のアクセス制御を実現できます。
基本的には個々のメンバーに直接権限を付与するのではなく、Team に対して権限を付与し、メンバーを Team に追加する運用を推奨します。
権限は Organization、Project、Workspace の各レベルで設定できます。
| 権限 | 内容 |
|---|---|
| Admin | Project 設定の変更・削除と Workspace の管理が可能 |
| Maintain | Workspace の作成・削除と Run の実行が可能（Project 設定の変更は不可） |
| Write | Run の実行（Plan / Apply）と変数・State の操作が可能 |
| Read | 閲覧のみ可能 |
参照:
2.3. OIDC 認証（Dynamic Provider Credentials）（優先度：★★★）
HCP Terraform からクラウドプロバイダーへの認証には OIDC（OpenID Connect） の利用を推奨します。
これにより、クライアントシークレットなどの長期的な認証情報を HCP Terraform に保存する必要がなくなり、
セキュリティが向上します。
Dynamic Provider Credentials を利用することで、Run（Plan / Apply）ごとに短命のトークンが
自動的に発行され、クラウドプロバイダーへの認証が行われます。
設定の大まかな流れは以下の通り（例としてAzure）です。
- クラウドプロバイダー側でアプリケーション（Service Principal 等）を登録する
- フェデレーション資格情報を設定し、HCP Terraform を発行者（Issuer）として登録する
- HCP Terraform の Workspace に必要な環境変数（テナント ID、クライアント ID 等）を設定する
- Terraformを実行する
参照:
2.4. Audit Logging（優先度：★）
Audit Logging を有効にすることで、Organization 内の操作（Workspace の作成・変更、
Run の実行等）の監査ログを記録・エクスポートできます。
コンプライアンス要件がある組織では、ログを外部の SIEM や分析基盤に連携して活用できます。
参照:
3. 環境管理
3.1. VCS Connections（優先度：★★★）
HCP Terraform から GitHub 等の VCS プロバイダーに接続するための設定です。
VCS 接続を事前に設定しておくことで、Workspace 作成時にスムーズに VCS 連携を構成できます。
対応している主な VCS プロバイダーは以下の通りです。
- GitHub.com / GitHub Enterprise Server
- GitLab.com / GitLab Enterprise Edition
等
VCS 接続には OAuth Application または GitHub App の登録が必要です。
GitHub の場合は GitHub App での連携が推奨されています。権限範囲には注意が必要です。
個人的にはHCP Terraformを使う理由として、VCS連携を簡単に構成できることが大きなメリットだと感じています。
基本的にはVCS連携を構成して、コードの変更を契機に自動的にRunがトリガーされるようにすることをおすすめします。
参照:
3.2. Project / Workspace の作成（優先度：★★★）
設定は Organization → Project → Workspace の順に進めると効率よく構成できます。
Project は関連する Workspace をグループ化する単位です。
例えば「システム A」というプロジェクトに対して infra、app、database などの
Workspace を作成し、それらを system-a という Project にまとめるイメージです。
Workspace は Terraform の State を管理する最小単位で、環境（production、staging）や
コンポーネント（ネットワーク、コンピューティング）ごとに分割して作成します。
Workspace 作成時の主な設定項目は以下の通りです。
| 設定項目 | 説明 |
|---|---|
| VCS provider | 事前に設定した VCS Connection を選択 |
| Terraform Working Directory | Terraform コードが格納されているディレクトリパス |
| Auto-apply | 有効にすると Plan 後に自動的に Apply を実行 |
| Execution Mode | Remote / Local / Agent から選択 |
特に Terraform Working Directory の設定は、1 つのリポジトリに複数の Workspace が存在するモノレポ構成の場合に重要です（1repo内にdev/stg/prdのように作る場合など）。
参照:
3.3. Variable Sets（優先度：★★★）
Variable Sets を利用することで、複数の Workspace で共通利用する変数をまとめて管理できます。
変数は Organization レベル と Project レベル で管理できるため、全体共通の変数と
Project 固有の変数を分けて管理することを推奨します。
Variable Set の適用範囲は以下から選択できます。
- Apply to all projects and workspaces：Organization 内のすべてに適用
- Apply to specific projects and workspaces：特定の Project または Workspace にのみ適用
変数の種類は以下の 2 種類です。
| 種類 | 説明 |
|---|---|
| Terraform variable | Terraform コード内で var.* として参照する変数 |
| Environment variable | 実行環境で参照する環境変数 |
機密情報（シークレット等）を扱う場合は、変数に Sensitive フラグを設定することで値がマスクされます。
参照:
3.4. Tags（優先度：★★）
Tags 機能を利用することで、Project や Workspace を分類・管理できます。
コスト管理や検索のために活用でき、Organization レベルで事前に Tag を登録しておくことで
一貫性のあるタグ付けが可能になります。
タグの命名例としては Environment、Department、System などが挙げられます。
参照:
4. デプロイ・実行制御
4.1. Execution Mode（優先度：★★★）
Workspace の Execution Mode では、Terraform の実行環境を選択できます。
| モード | 説明 |
|---|---|
| Project Default | Project の既定の実行モードを利用する |
| Remote | HCP Terraform のマネージド実行環境で Plan / Apply を実行する |
| Local | ローカル環境から Terraform CLI で実行し、State のみ HCP Terraform で管理する |
| Agent | 組織が用意したセルフホスト型の実行環境（Agent）で実行する |
基本的には Remote を利用します。
Workspace では Project Default が既定で、Project 側で実行モードを設定できます。運用上は Project の既定を Remote にしておくことが多いでしょう。
プライベートネットワーク内のリソースにアクセスが必要な場合は Agent を選択します。
参照:
4.2. Run Triggers（優先度：★★★）
VCS Driven（Branch-based / Tag-based）
HCP Terraform と VCS を連携させることで、コードの変更を契機に自動的に Run をトリガーできます。
-
Branch-based：特定のブランチ（例：
main）へのプッシュを契機に Run を実行 - Tag-based：特定のパターンに合致するタグの作成を契機に Run を実行
また、「Automatic speculative plans」を有効にすることで、Pull Request 作成時に自動的に
Speculative Plan（読み取り専用の試験的な Plan）が実行され、変更内容を事前に確認できます。
Workspace 間の Run Triggers（優先度：★）
Workspace 間に依存関係がある場合、Run Triggers を設定することで、
上流 Workspace の Apply 完了を契機に下流 Workspace の Run を自動的に開始できます。
例えば、ネットワーク Workspace の Apply が完了したら、アプリケーション Workspace の
Run を自動的に開始する、という構成が可能です。
参照:
4.3. Agent（優先度：★★）
Agent は、組織が管理するサーバー上で Terraform の Plan / Apply を実行する仕組みです。
HCP Terraform のデフォルトのマネージド実行環境はインターネット経由で動作するため、
プライベートネットワーク内のリソースには直接アクセスできません。
Agent を利用することで、そのようなリソースも Terraform で管理できるようになります。
例えば、以下のようなプライベートエンドポイント経由でのみアクセスを許可しているリソースに対して
Terraform を実行する場合に有効です。
- プライベートエンドポイントを有効にした Azure Storage Account
- パブリックアクセスを無効にした Azure Key Vault
- オンプレミス環境や VPN 内のリソース
Agent は Docker コンテナまたはサーバー上に配置し、HCP Terraform に対してアウトバウンド接続します。
インバウンドの穴あけは不要です。
Agent Pool は Agent をグループ化して管理する単位です。
Agent Pool を作成し、Workspace の Execution Mode を Agent に設定することで利用できます。
参照:
4.4. Auto Destroy（優先度：★）
Auto Destroy を設定することで、Workspace のリソースを自動的に削除できます。特定の日時を指定する方法と、一定期間非アクティブなら自動削除する方法があります。
検証環境や一時的な環境のリソースを期限付きで管理する際に有効です。
Auto Destroy を設定すると、条件を満たしたタイミングで対象 Workspace のすべてのリソースが削除されます。
基本的にPoC用Workspaceなどに設定することが多いです。
便利な機能ですが、運用始まってすぐに必要になることは少ないかもしれません。
参照:
5. コード品質・ガバナンス
5.1. Policy Sets（Sentinel / OPA）（優先度：★）
Policy Sets を利用することで、Terraform コードに対するガバナンスルールを Plan 実行時に
自動的に検証できます。ポリシーは Sentinel または OPA（Open Policy Agent） 形式で記述します。
Policy Sets は GitHub 等の VCS リポジトリと連携して管理することを推奨します。
VCS 連携により、ポリシーのコードレビューやバージョン管理が容易になります。
適用範囲：
- Policies enforced globally：全 Workspace に適用
- Policies enforced on selected projects and workspaces：特定の Project または Workspace にのみ適用
Enforcement mode（強制レベル）：
| レベル | 説明 |
|---|---|
| Advisory | 警告のみで実行は継続可能 |
| Soft mandatory | ポリシー違反時に警告を表示するが、権限があれば上書き可能 |
| Hard mandatory | ポリシー違反時は実行を中断（上書き不可） |
ポリシーの活用例としては、必須タグの検証、命名規則の検証、禁止しているリソースの検出などが挙げられます。
参照:
5.2. Run Tasks（優先度：★）
Run Tasks を利用することで、Plan / Apply の実行前後に外部ツールによる検証を組み込めます。
代表的な連携ツールとしては以下が挙げられます。
- Infracost：デプロイ前のクラウドコスト見積もり
- Checkov：セキュリティポリシーの静的解析
Run Tasks は Organization レベルで作成し、Workspace に関連付けて利用します。Terraform Registry では連携可能な Run Task を探せます。
Policy Sets と同様に、Advisory / Mandatory の強制レベルを選択できます。
参照:
5.3. Cost Estimation（優先度：★）
Cost Estimation 機能を利用することで、Plan 実行後にデプロイ対象リソースの
月額コスト見積もりが表示されます。対応しているクラウドプロバイダーは AWS、Azure、Google Cloud です。
Cost Estimation は Organization 設定から有効化できます。
Cost Estimationはありがたいのですが、実際の運用をする上では物足りないです。
より詳細なコスト分析が必要な場合は、Run Tasks での Infracost 連携等を検討してください。
参照:
6. モニタリング・通知
6.1. Health Assessments（優先度：★★）
Health Assessments は、Workspace の健全性を継続的に監視する機能です。
以下の 2 つの機能が含まれます。
Drift Detection
Drift Detection を有効にすることで、実際のクラウド環境と Terraform State を定期的に比較し、
差分（ドリフト）を検出できます。検出間隔は設定可能で、詳細は公式ドキュメントを確認してください。
Drift Detection は Organization レベルで全 Workspace に一括適用することもできます。
Continuous Validation
Continuous Validation を利用することで、check ブロックで定義した検証ルールを定期的に実行し、
リソースの設定が期待通りの状態を維持しているか監視できます。
例えば「特定のリソースのステータスが常に Healthy であること」を定義しておくと、
ステータスが変化した際に異常を検知できます。
参照:
6.2. Notifications（優先度：★★）
Notifications を設定することで、Run の状態変化（Plan 完了、Apply 失敗等）や
Health Assessments による検知結果をリアルタイムに受け取れます。
通知先として以下が設定できます。
- Slack
- Microsoft Teams
- Webhook（カスタム通知先）
通知タイミングは「Run が失敗したとき」「Apply が完了したとき」などの粒度で設定できます。
参照:
7. モジュール・リソース管理
7.1. Private Registry（優先度：★★）
HCP Terraform の Private Registry を利用することで、組織内で共有する Terraform モジュールを
一元管理できます。モジュールを VCS リポジトリと連携して公開することで、タグ作成時に自動的に
Private Registry にバージョンが追加されます。
git tag v1.0.0
git push origin v1.0.0
Private Registry に公開したモジュールは、以下の形式で参照できます。
module "example" {
source = "app.terraform.io/<organization名>/<module名>/<provider名>"
version = "1.0.0"
}
7.2. No-Code Provisioning（優先度：★）
No-Code Provisioning を利用することで、Terraform コードを書かずに HCP Terraform の
GUI 操作だけでクラウドリソースを作成できます。
事前に管理者がモジュールを Private Registry に公開し、No-Code 対応として有効化しておくことで、
開発者は変数を入力するだけでリソースをデプロイできます。
いわゆるサービスカタログのようなイメージで、セルフサービスでリソースをプロビジョニングできるようになります。
IaC不慣れな方に提供しやすい機能です。
参照:
7.3. Stacks（優先度：★）
Stacks は、Workspace とは別の構成単位として複数コンポーネントをまとめて管理できる機能です。
関連する複数コンポーネント（ネットワーク、コンピューティング、データベース等）を 1 つの Stack として
定義し、依存関係を持たせながら一括でデプロイ・管理できます。
従来の Workspace 間の依存管理（Remote State や Run Triggers）よりも、構成の複雑さを抑えて
コンポーネント間の依存関係を扱えます。
こちらの機能は、新規かつデプロイ管理方法が従来と異なるため慎重に検討する必要がありそうです。
参照:
おわりに
この記事では HCP Terraform の主要な機能を、認証・環境管理・デプロイ制御・ガバナンス・モニタリング・モジュール管理という観点から幅広く紹介しました。
すべての機能を一度に導入する必要はなく、まず VCS 連携周りを整えてから、
組織の要件に合わせて段階的に機能を追加していくことをおすすめします。
過去にHCP Terraformを利用し始めたときに設定しておきたい内容については以下記事にまとめています。必要であれば併せて確認いただけると嬉しいです。
HCP Terraform は使ってみると理解できるようになる部分が多くあります。ぜひ一度さわってみてください。
最後まで読んでいただきありがとうございました！
もし、誤り等がありましたら教えていただけますと幸いです。