HCP Terraformとは？旧Terraform Cloudの料金・無料枠とCLI接続の手順

HCP Terraformは、Terraformのstate保管・plan/applyの実行・承認・権限管理をHashiCorpがホストするSaaSです。2024年4月22日まではTerraform Cloudという名前で、中身は同じ製品です。この記事では、HCP（HashiCorp Cloud Platform）やIBMとの関係、1リソース1時間あたりで決まる料金、Terraform CLIからの接続手順、使わない方がよい条件を順に整理します。数値は2026年9月28日時点の公式ドキュメントとIBMの料金ページで確認しています。

まとめ：HCP Terraformの要点

• 正体：Terraformの実行基盤とstate置き場のSaaS。Terraform Cloudが2024年4月22日に改称したもので、別製品ではありません。
• HCPとの関係：HCP（HashiCorp Cloud Platform）はHashiCorpのSaaS群の総称で、HCP Terraformはその1製品です。
• 料金：管理リソース500個まで無料。超えると1リソース1時間単位の従量課金で、IBMの料金表ではEssentialsが0.00013ドル（月730時間換算で約0.095ドル）です。
• 接続：terraform loginでトークンを保存し、terraformブロック内のcloudブロックに組織名とワークスペースを書いてterraform initします。
• 向かない条件：従量料金が予算を超える構成、データを米国・EU以外に置く必要がある組織、HCP Terraformへの外向き通信も許可できない環境。

HCP Terraformの位置づけ：改称の経緯とHCP・IBMとの関係

Terraform CloudからHCP Terraformへの改称

HashiCorpは2024年4月22日付でTerraform CloudをHCP Terraformへ改称しました。機能・URL（app.terraform.io）・APIはそのまま引き継がれています。CLIのcloudブロックや環境変数名にTFC_（Terraform Cloudの略）が残っているのはこのためで、古い記事の手順も大半はそのまま通ります。「Terraform CloudとHCP Terraformを連携させる」という説明は、同じ製品を別物として扱っているので誤りです。

HCP（HashiCorp Cloud Platform）の中での位置

HCPは、HashiCorpがマネージドで提供する製品群とアカウント・組織・請求の共通基盤を指します。HCP Terraformのほか、HCP Vault Dedicated、HCP Packer、HCP Boundary、HCP Vault Radarなどが同じ基盤に載っており、Terraformのstate管理やリモート実行はHCP Terraformが提供します。請求の境界はHCPの組織で、1つのHCP組織に複数のHCP Terraform組織をひも付けられます。サインイン画面の「Continue with HCP account」でHCPアカウントを使うと、既存のHCP Terraformアカウントがあればリンクされ、無ければ新規に作られます。HashiCorpの製品全体の関係はHashiCorp（ハシコープ）とは？主要製品の違い・IBM買収後の変化・BSLライセンスを解説でまとめています。

IBM買収後の製品名：料金表は「IBM Terraform」

HashiCorpは2025年2月27日にIBMの傘下に入りました。2026年9月時点のIBMの料金ページ（ibm.com/products/hashicorp/pricing）では、同じ製品が「IBM Terraform」の名前で単価付きで載っています。一方、HashiCorpの開発者向けドキュメントは引き続き「HCP Terraform」と表記しています。見積もりや稟議ではIBM Terraform、手順や設定を調べるときはHCP Terraformの名前で探すと、それぞれの一次情報に当たれます。

HCP Terraformが肩代わりする作業：state・実行・承認

リモートstateとロック

ローカル運用では、stateを置くS3バケットやGCSバケット、同時実行を防ぐロックを自前で用意します。HCP Terraformはワークスペースごとにstateを保管し、実行中はロックをかけ、版の履歴を残します。state保管用のバックエンドを自前で構築・運用する作業を減らせます。自前でS3に置く場合の構造と注意点はTerraform stateとは？tfstateの構造とS3バックエンド・移動削除の安全手順を参照してください。

3つの実行ワークフロー

VCS駆動では、PRを開くと変更内容で投機的なplan（speculative plan）が走り、結果がPRのチェックとして表示されます。マージされると本番のplanが走り、設定に応じて承認を待ってからapplyします。

プロジェクト・ワークスペース・Stacks

HCP Terraformでは、組織の下にプロジェクトがあり、その中にワークスペースとStacksが並びます。ワークスペースは1つのルートモジュールとそのstate・変数・実行履歴の単位で、Terraform CLIのterraform workspaceコマンドが扱う「同じ設定で複数のstateを切り替える」仕組みとは別物です。名前が同じなので、CLIのworkspaceで環境を分けている構成をそのまま移すと設計が混乱します。CLI側の使い分けはterraform workspaceの使い方と環境分離の判断基準｜分割方式の比較で整理しています。

Stacksは、複数のモジュールをコンポーネントとして束ね、同じ構成を環境やリージョンごとに繰り返し展開するための単位です。2025年9月25日のHashiConf 2025で一般提供（GA）が発表され、RUMベースの新しいプランで使えます。ワークスペースの上に作られたものではなく、同じプロジェクトの中に並べて置けます。

ワークスペース間の値の受け渡し

ネットワークとアプリケーションのようにワークスペースを分けて下流側から上流の出力値を読むとき、HCP Terraformではstate全体へのアクセスを必要としないtfe_outputsデータソース（tfeプロバイダー）を公式が推奨しています。terraform_remote_stateも使えますが、state全体へのアクセス権限が必要です。上流の変更で下流を自動的に再実行したいときは、ワークスペース間のrun triggerを設定します。

HCP Terraformの料金：無料枠500リソースと従量課金の計算

プラン別の機能と上限

単価はIBMの料金ページのPAYG（従量課金）表、機能と上限はHashiCorpのプラン比較ページと各機能のドキュメントによります。プライベートモジュールレジストリ、Run Tasks、セルフホスト型エージェント1台はFreeでも使えます。月額換算は730時間で掛けた概算で、税や地域による差は含みません。StandardとPremiumでは、同時実行数を追加購入できます（リモート実行1枠が1時間0.32877ドル＝月約240ドル、エージェント実行1枠が0.16438ドル＝月約120ドル）。

課金対象になるリソースの数え方

課金の単位は、HCP Terraformが保管するstateの中でmode = "managed"になっているリソースです。countやfor_eachで作った個々のインスタンス、モジュールの中身も1個ずつ数えます。数えないのはnull_resource、terraform_data、データソース、ローカル値と変数です。課金は1時間単位で、1時間に満たない分も1時間として扱い、その時間内のピーク数で計算します。ワークスペースとStacksのリソースは合算されます。

1,000リソースを管理したときの月額試算

管理リソースを常時1,000個持つ組織を例に、730時間で計算すると次のとおりです。

• Essentials：0.00013ドル×1,000×730時間＝約94.9ドル
• Standard：0.00064ドル×1,000×730時間＝約467.2ドル
• Premium：0.00135ドル×1,000×730時間＝約985.5ドル

無料枠の500リソースは、2026年3月31日に提供を終えた旧Free（ユーザー数ベース）に代わるRUMベースのFreeプランの上限です。

AWSでいえば、セキュリティグループのルール、Route 53のレコード、IAMポリシーのアタッチメントのような小さなリソースも1個として数えます。DNSレコードをfor_eachで300件管理するだけで300リソースになるため、見積もりは「サーバーの台数」ではなく「stateのリソース数」で行ってください。既存のstateなら、次のコマンドで課金対象外の行を除いた概数が出ます。子モジュール内のデータソースはmodule.net.data.aws_availability_zones.allのように行頭がmodule.になるため、行頭のdata.だけで除外すると数え過ぎます。

# データソース・null_resource・terraform_data を除いて数える
terraform state list \
  | grep -v -E '(^|\.)data\.|(^|\.)null_resource\.|(^|\.)terraform_data\.' \
  | wc -l

得られるのはそのstateの現時点の数です。課金は組織内の全ワークスペースとStacksの合計を1時間ごとのピークで数えるため、一時的に作って消すリソースが多い運用では実額がこの数を上回ります。

CLIからHCP Terraformへ接続する手順：terraform loginとcloudブロック

トークンの保存：terraform login

開発者のPCではterraform loginを実行すると、ブラウザでトークン発行画面が開き、発行したトークンが自分のホームディレクトリの資格情報ファイルに平文で保存されます。共用マシンでは実行しないでください。CIのように対話できない環境では、環境変数でトークンを渡します。

# 開発者のPC（ホスト名を省略すると app.terraform.io）
terraform login

# 保存先（Terraform 1.16.4 の terraform login -help の表示）
# ~/.terraform.d/credentials.tfrc.json

# CIではホスト名のドットをアンダースコアに置き換えた変数名で渡す
export TF_TOKEN_app_terraform_io="発行したチームトークン"

接続先の定義：cloudブロック

cloudブロックはTerraform 1.1以降で使える設定で（それ以前はremoteバックエンド）、terraformブロックの中に書き、組織名と対象ワークスペースを指定します。ワークスペースは名前で1つ指定するか、タグで複数を束ねます。次の例はTerraform 1.16.4でterraform validateが通ることを確認した設定です。

terraform {
  cloud {
    organization = "example-org"
    # hostname を省略すると app.terraform.io（EU組織は app.eu.terraform.io）

    workspaces {
      project = "networking"
      tags    = { layer = "network", env = "dev" }
    }
  }
}

タグ指定の場合、該当するワークスペースが無ければterraform initの途中で新規作成を提案されます。名前を指定するnameとタグ指定のtagsは同時に使えません。

initで出るエラーと対処

トークンが無い状態でterraform initを実行すると、Terraform 1.16.4では次のように止まります。

Initializing HCP Terraform...

Error: Required token could not be found

Run the following command to generate a token for app.terraform.io:
    terraform login

トークンはあるのに組織名を誤っている、またはトークンの権限が足りない場合はError: Failed to read organization "example-org" at host app.terraform.ioとunauthorizedが出ます。後者はトークンの種類（ユーザー・チーム・組織）と、そのトークンが対象組織に属しているかを確認してください。既にローカルやS3にstateがある作業ディレクトリでは、stateをバックアップしたうえで、既存のbackendブロックがあればcloudブロックに置き換え、なければcloudブロックを追加してterraform initを実行するとstateの移行を確認されます。

AWSの静的キーを置かない設定：動的プロバイダー認証

ワークスペースの変数にAWSのアクセスキーを保存する運用は、キーのローテーションと漏えい対策が残ります。HCP Terraformの動的プロバイダー認証（dynamic provider credentials）は、実行ごとにOIDCトークンを発行し、AWS側がそれを検証して一時的な認証情報を返す仕組みです。実行が終わると認証情報は破棄されます。

AWS側には、プロバイダーURLをhttps://app.terraform.io（末尾のスラッシュ無し）、オーディエンスをaws.workload.identityとしたOIDCプロバイダーを作り、次のような信頼ポリシーを持つIAMロールを用意します。信頼ポリシーはロールの引き受けを許すだけなので、操作対象のAWSリソースへの権限ポリシーは別に付与します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Federated": "arn:aws:iam::123456789012:oidc-provider/app.terraform.io" },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": { "app.terraform.io:aud": "aws.workload.identity" },
        "StringLike": { "app.terraform.io:sub": "organization:example-org:project:networking:workspace:*:run_phase:*" }
      }
    }
  ]
}

ワークスペース側では環境変数TFC_AWS_PROVIDER_AUTHをtrueに、TFC_AWS_RUN_ROLE_ARNにロールのARNを設定します。リージョンはAWSプロバイダーのregion引数かワークスペースのAWS_REGION変数で渡し、ワークスペースに残っている静的キーの変数は削除しておきます。subの条件にプロジェクト名とワークスペース名が入るため、組織全体に*で許可せず、ロールをプロジェクト単位に分けると権限の範囲を絞れます。planとapplyで別のロールを使いたい場合はTFC_AWS_PLAN_ROLE_ARNとTFC_AWS_APPLY_ROLE_ARNに分けて指定します。自前でホストするHCP Terraformエージェントで使う場合は、エージェントv1.7.0以上が必要です。GitHub ActionsからOIDCでAWSに入る構成と比べたい場合はGitHub ActionsとTerraformでAWSのCI/CDを構築する手順（OIDC・S3ネイティブロック対応）が同じ考え方で書かれています。

HCP Terraform・HCP Europe・Terraform Enterpriseの違い

HCP Europeは、アカウント・組織・請求を他地域と分けてEU内に置くための提供形態です。既存のHCP Terraform組織をつなぐことも移すこともできず、新しいHCPアカウントと組織を作り直します。チーム機能の代わりにHCP側のグループとロールで権限を管理し、ServiceNow連携やKubernetes Operatorは使えません。

Terraform Enterpriseは同じ機能を自社のKubernetes・Docker・Podman・Nomad上に導入する形態で、2026年9月時点の最新は2026年9月23日公開の2.0.8（同梱のTerraform CLIは1.15.9）です。インターネットから切り離した環境でTerraformを実行する必要がある組織は、こちらが選択肢になります。

HCP Terraformを使わない方がよい条件

HCP Terraformは「stateとCIを自前で持ちたくない」チームには合理的ですが、次の条件に当てはまるなら、S3などの自前バックエンドとGitHub Actions、またはAtlantisで組む方が安く済むか、要件を満たせます。

• 小さなリソースを数千個管理する：課金はstateのリソース数で決まるため、DNSレコードやIAMの付け外しを大量に持つ構成では膨らみます。5,000リソースならStandardで月約2,336ドルです。採用前に、HCP Terraformの従量料金と、自前CIの実行料金・state保管費・保守工数を比較してください。
• Freeプランで同時に複数のリモート実行が必要になる：リモート同時実行枠が1のため、PRが重なるとplanが順番待ちになります。カスタムRBACも無いため、細かく権限を分けたいなら最低でもEssentialsが要ります。
• データを米国・EU以外に置く規定がある：SaaSとして案内されているのは米国（app.terraform.io）とEU（app.eu.terraform.io）の2系統で、stateにはパスワードなどの機密値がそのまま記録され得ます。国内保管が条件ならTerraform Enterpriseか自前バックエンドです。
• ポリシー制御が要件なのに下位プランで済ませたい：Sentinel・OPAのポリシーセットの提供範囲は、公式ドキュメント同士で記述が食い違っています。プラン比較表はFreeとEssentialsを「-」とし、Policy Sets APIのページは「Freeに1ポリシーセット・最大5ポリシーが含まれる」と書いています。apply前に止めるポリシーを本番の要件にするなら、Freeの枠に頼らずStandardで見積もり、契約前に対象組織の画面で上限を確かめてください。

PRのコメントでplan・applyを回す自前の構成はAtlantisでTerraformをPR運用する構成と権限設計｜採用条件を解説で、Terraform本体の版の確認はTerraformの最新バージョンは1.16｜バージョン確認とアップグレード手順・1.16の新機能で扱っています。

HCP Terraformに関するよくある質問

HCP Terraformとは何ですか？

Terraformのstate保管、plan・applyのリモート実行、承認フロー、権限管理をHashiCorp（IBM傘下）がホストするSaaSです。旧称はTerraform Cloudで、2024年4月22日に改称しました。

HCP TerraformとTerraform Cloudの違いは何ですか？

名前だけで、製品は同じです。URLのapp.terraform.io、API、cloudブロックの書き方も変わっていません。環境変数のTFC_接頭辞は旧称の名残です。

HCP（HashiCorp Cloud Platform）とは何ですか？

HashiCorpのマネージド製品群と、それらのアカウント・組織・請求をまとめる共通基盤です。HCP Terraformはその中の1製品で、ほかにHCP Vault DedicatedやHCP Packerなどがあります。

HCP Terraformは無料で使えますか？

管理リソース500個まではFreeプランで無料です。超える場合はEssentials以上の従量課金になり、IBMの料金表では1リソース1時間あたりEssentials 0.00013ドル、Standard 0.00064ドル、Premium 0.00135ドルです。

CLIからHCP Terraformにログインするにはどうすればよいですか？

terraform loginを実行し、ブラウザで発行したトークンを保存します。保存先は~/.terraform.d/credentials.tfrc.jsonです。CIではTF_TOKEN_app_terraform_io環境変数でトークンを渡します。

関連記事

• HashiCorp（ハシコープ）とは？主要製品の違い・IBM買収後の変化・BSLライセンスを解説
• Terraformの最新バージョンは1.16｜バージョン確認とアップグレード手順・1.16の新機能
• Terraform stateとは？tfstateの構造とS3バックエンド・移動削除の安全手順
• GitHub ActionsとTerraformでAWSのCI/CDを構築する手順（OIDC・S3ネイティブロック対応）
• AtlantisでTerraformをPR運用する構成と権限設計｜採用条件を解説