tfpolicy は2026年7月現在でβ版です
以下に記載の内容は2026年7月リリースの 0.1.0 を基準に記載していますが、今後仕様変更が発生する可能性があります。
はじめに
IBM/HashiCorpから Terraformの新しいポリシー評価フレームワークであるtfpolicyがリリースされ、公式ドキュメントにも追加されました。
これまでTerraformにおけるポリシー評価の選択肢としては、 IBM/Hashicorp の別製品の Sentinel や オープンソースの OPA がありました1。ここに新たな選択肢が加わったことになります。
しかし、tfpolicy の登場により、既存のツールは置き換えられるのかというと(2026年7月時点では)必ずしもそうではなさそうです。
まずは各ツールの比較表から整理します。
どのツールを選ぶべきか
各ツールの特性を踏まえると、チームの状況や目的に応じて最適な選択肢が変わってきます。
- tfpolicy ： HCP Terraform / Terraform Enterprise を利用している環境 で、インフラエンジニア主体でポリシーを運用するチームの第一選択肢となります。HCLで記述できるので、Terraform を利用しているチームの追加学習はさほど必要ないと思われます
- Sentinel：すでに豊富なSentinelポリシー資産が稼働しているエンタープライズ組織や、Vault/ConsulなどHashiCorp製品群全体でポリシーを統一している場合、継続利用するのが第一選択しになると思います
- OPA (Rego) ： 独自（GitHub Actions、GitLab CI、各クラウドのビルドパイプラインサービス等）のCI/CDパイプライン で自動化を組んでいる環境や、Kubernetes等を含め組織横断でポリシー（Rego）を標準化したい場合の第一選択肢となります
ポリシー評価ツールの比較表
| 比較項目 | tfpolicy | Sentinel | OPA (Rego) |
|---|---|---|---|
| 記述言語 | HCL | Sentinel言語 | Rego |
| 学習コスト | 非常に低い（Terraform知識を流用可） | 高い（独自言語） | 中〜高（習得すればterraform以外のエコシステムでも流用可） |
| 評価対象の適応範囲 | 静的解析、plan結果（動的）、apply結果 | 静的解析、plan結果、apply結果 | 主に静的解析（plan結果は事前JSON化の手間が必要） |
| 前提プラットフォーム / 実行環境 | HCP Terraform 必須（CLI単体ではポリシーの適応不可） | HashiCorpエンタープライズ標準搭載 | 環境不問（任意のCI/CDや自前パイプラインへ組み込み可） |
2026年7月現状 tfpolicy を使ったポリシー適応は HCP Terraform / Terraform Enterprise の利用 が必須になるので私は使えないのですが、 CLI でローカルでの
- ポリシー記述と検証
- モックを使ったポリシー自身のテスト
はできるので、今回の記事では公式ドキュメントを参照しつつローカルで対応可能な範囲で試してみました。
tfpolicy CLI を用いたローカル検証
ポリシーの定義
まず、.policy.hcl 拡張子でポリシーを定義します。対象となるリソースと、満たすべき条件（condition）を「HCL」で記述します。
今回は resource に対してポリシーを書いてみます(参考：resource_policy)
# Plan時に決まる値（AWS providerのdefault_tagsによる tags_all の解決）を評価するポリシー
resource_policy "aws_instance" "require_env_tag" {
enforcement_level = "mandatory"
enforce {
condition = core::contains(core::keys(attrs.tags_all), "Environment")
error_message = "All instances must have an 'Environment' tag (can be inherited from provider default_tags)"
}
}
※ core:: プレフィックスは、 tfpolicy において標準組み込み関数（contains, keys 等）を呼び出すためのネームスペースです。
ポリシーが書けたら tfpolicy validate でバリデーションをかけます。
$ tfpolicy validate --policies=policies
Success! Terraform policies validated successfully.
テストの定義
次に、ポリシーを検証するためのテストコードを記述します。
テストではリソースをモックし、想定される値を設定することで、パスするケースと失敗するケースの両方を検証できます。
- 失敗を想定したテストの場合は
expect_failure = trueを記載 - モックした属性値は
attrs = { ... }に記載
以下のようなテスト用モックが作成できます。
# Environmentタグが存在しないため違反となる
resource "aws_instance" "fail_missing_tag" {
expect_failure = true
attrs = {
instance_type = "t3.micro"
ami = "ami-12345678"
tags_all = {
Name = "no-env-tag"
}
}
}
検証の実行
ローカルにインストールした tfpolicy CLIを使用してテストを実行します。
以下のコマンドにより、テストファイルを用いてポリシーを評価します。
$ tfpolicy test --policies=policies --tests=tests
# tests/fail_tag.policytest.hcl... running
# resource.aws_instance.fail_missing_tag... running
# resource.aws_instance.fail_missing_tag... pass
# tests/fail_tag.policytest.hcl... pass
HCP Terraform / Terraform Enterprise 環境があれば、この後、ポリシーをコミットすると、以降 .tf ファイルの更新の度にポリシーチェックがされるようです(環境がないので未検証)。
おわりに
新たに登場した tfpolicy は、Terraform 利用チームにとって最も親和性の高い HCL 形式でポリシーを記述できます。静的解析だけでなく plan 結果の評価も可能であり、テストフレームワークも内蔵されています。
よさそうではあるのですが、採用するかは記事記載時点では「CDパイプラインが HCP Terraform / Terraform Enterprise か？」に依存してい状態です。
私は残念ながら該当の環境がない(GitHub Actions や各クラウドサービスのビルドパイプラインサービスを利用)ので引き続き OPA/Conftest の利用を続けることになりそうです。
-
Open Policy Agentの略称であり、conftestも含みます。 ↩