HCP Terraformとは？旧Terraform Cloudの料金・無料枠500リソースと自前運用との違い

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

まとめ：HCP Terraformの要点

• 正体：Terraformの実行基盤とstate置き場のSaaS。Terraform Cloudが2024年4月22日に改称したもので、別製品ではありません。
• HCPとの関係：HCPはHashiCorpのマネージド製品群と、アカウント・組織・請求の共通基盤の総称です。HCP Terraformはその1製品です。
• 料金：管理リソース500個まで無料。超えると1リソース1時間単位の従量課金で、IBMの料金表ではEssentialsが0.00013ドル（月730時間換算で約0.095ドル）です。
• 自前運用との差：stateのロックとPRごとのplanはS3とGitHub Actionsでも組めます。差が出るのは、ワークスペース単位の権限、承認の記録、ドリフト検出、ポリシーを自分で作り込まずに済む点です。
• 接続：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」と「HCP Terraform」は同じものではなく、HCPのアカウントを作っただけではTerraformのワークスペースはできません。HCPのドキュメントに並ぶ製品は次のとおりです。

HCP Waypointのテンプレートとアドオンの機能は、HCP Terraformの中のTerraform Developer Portalへ移されている途中です。Developer Portalは2026年10月27日時点でパブリックベータで、公式は本番環境で使わないよう注記しています。HCP Vagrantは2026年11月2日にサポートを終え、12月31日に運用を終了するため、boxを置いている場合はS3などの自前の置き場へ移す必要があります。

請求の境界はHCPの組織で、1つのHCP組織に複数のHCP Terraform組織をひも付けられます。app.terraform.ioのサインイン画面で「Continue with HCP account」を選ぶと、同じメールアドレスのHCP Terraformアカウントがあればリンクされ、無ければ新規に作られます。HashiCorpの製品全体の関係はHashiCorp（ハシコープ）とは？主要製品の違い・IBM買収後の変化・BSLライセンスを解説でまとめています。

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

HashiCorpは2025年2月27日にIBMの傘下に入りました。2026年10月27日時点のIBMの料金ページでは同じ製品が「IBM Terraform」の名前で載り、HashiCorpの開発者向けドキュメントは「HCP Terraform」と表記しています。見積もりや稟議ではIBM Terraform、手順や設定はHCP Terraformの名前で探すと、それぞれの一次情報に当たれます。

HCP Terraformが肩代わりする作業：state・実行・承認・ドリフト検出

リモートstateとロック

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

実行ワークフロー：VCS・CLI・APIの起点と用途

VCS駆動では、PRを開くとspeculative plan（適用しない確認用の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ベースのプランで使えます。

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

ドリフト検出：手作業変更の検知条件と通知

HCP Terraformのhealth assessmentsは、ワークスペースの実際のインフラが設定と一致しているかを、おおむね24時間ごとにspeculative planで確かめる機能です。評価そのものはインフラを変更しません。クラウドのコンソールで誰かがバケットの設定を書き換えた、といった差分（configuration drift）を検出し、設定に戻すためのplanを提示します。あわせて、checkブロックやpostconditionに書いた条件が適用後も満たされているかを確かめるcontinuous validationも走ります。

• 提供プラン：StandardとPremiumのみ。FreeとEssentialsでは使えません。
• 前提：ドリフト検出だけならTerraform 0.15.4以上、continuous validationも使うなら1.3.0以上。実行モードがリモートかエージェントで、直近のrunが成功していること。
• 止まる条件：直近のrunがエラーで終わると、次に成功するまで評価が止まります。評価中に新しいrunが始まると、その回の評価は取り消されます。runが頻繁なワークスペースでは評価がほとんど回らないことがあります。
• 対象と通知：対象はワークスペースだけで、Stacksには対応していません。評価は同時実行数の上限に数えられず、ドリフトを初めて検知したときと内容が変わったときに、Slack・Microsoft Teams・メール・Webhookへ通知できます。

自前運用で同じことをするなら、terraform plan -detailed-exitcodeを定期実行し、終了コード2（差分あり）で通知するジョブを組みます。仕組みは単純ですが、ワークスペースの数だけ認証情報とスケジュールを持つことになります。

自前運用（S3＋GitHub Actions）との違い

HCP Terraformを検討する多くのチームが比べる相手は、S3バックエンドとGitHub Actions（またはAtlantis）で組む自前の構成です。Terraform 1.11でS3バックエンドのuse_lockfileが一般提供になり、DynamoDB無しでロックをかけられるようになったため、stateとロックだけなら自前でも手間は小さくなりました。差が出るのは、その外側を誰が作って保守するかです。

比べるのは、HCP Terraformの従量料金と、自前構成のCI実行費・GitHubの契約費・保守工数の合計です。少数のリポジトリで数千リソースを管理する構成は、自前側の作り込みが少ないまま従量料金だけが膨らむので、自前構成が有利になりやすい形です。逆に、数十のワークスペースを複数チームで分担し、誰が何をapplyしたかの記録と権限の分離が監査で求められるなら、権限管理・承認記録・ドリフト検出を自作して保守する費用が利用料を上回るかどうかが、HCP Terraformを選ぶ根拠になります。GitHub Actionsで組む場合の手順はTerraformをGitHub Actionsで自動化しAWSへ反映する手順｜OIDCロール2本と承認付きapply、PRのコメントでplan・applyを回す構成はAtlantisでTerraformをPR運用する構成と権限設計｜採用条件を解説で扱っています。

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時間単位で、その時間内のピーク数で計算し、ワークスペースとStacksのリソースは合算されます。

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

# インデックス（["a"] や [0]）を外してから、
# モジュールパスの後ろが data・null_resource・terraform_data の行を除いて数える
terraform state list \
  | sed -E 's/\["([^"\\]|\\.)*"\]|\[[0-9]+\]//g' \
  | grep -v -E '^(module\.[^.]+\.)*(data|null_resource|terraform_data)\.' \
  | wc -l

子モジュール内のデータソースはmodule.net.data.aws_availability_zones.allのように行頭がmodule.になるため、行頭のdata.だけで除外すると数え過ぎます。逆に「.data.を含む行」で除外すると、module.data.aws_vpc.main（モジュール名がdata）やaws_route53_record.q["prod.data.example"]（キーにdataを含む）まで消えて数え足りなくなります。Terraform 1.17.0で、この2件を含む11行のstateに当てると、上のコマンドは課金対象の6行だけを残しました。

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

管理リソースを常時1,000個持つ組織を730時間で計算すると、Essentialsが約94.9ドル、Standardが約467.2ドル、Premiumが約985.5ドルです。5,000リソースならStandardで月約2,336ドルになります。前節のコマンドで得られるのは実行時点のリソース数です。実額は各時間帯のピーク数で計算するため、リソース数が変動する運用では、常時同数を管理する試算より高くも低くもなります。無料枠の500リソースは、2026年3月31日に提供を終えた旧Free（ユーザー数ベース）に代わるRUMベースのFreeプランの上限です。

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

トークンの保存：terraform login

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

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

# 保存先（Terraform 1.17.0 の 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.17.0で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はError: Invalid workspaces configurationとOnly one of workspace "tags" or "name" is allowed.で止まります。

initで出るエラーと対処

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

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ブロックに置き換えて（無ければ追加して）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を設定し、残っている静的キーの変数は削除します。subの条件にプロジェクト名とワークスペース名が入るため、組織全体を*で許可せず、ロールをプロジェクト単位に分けると権限の範囲を絞れます。planとapplyで別のロールを使いたい場合はTFC_AWS_PLAN_ROLE_ARNとTFC_AWS_APPLY_ROLE_ARNに分けます。セルフホストのHCP Terraformエージェントで使う場合は、エージェントv1.7.0以上が必要です。

HCP Terraform・HCP Europe・Terraform Enterpriseの違い

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

Terraform Enterpriseは同じ機能を自社のKubernetes・Docker・Podman・Nomad上に導入する形態です。2026年10月26日公開の2.1.0は同梱のTerraform CLIが1.16.0で、利用者の自己登録が既定で無効になり、VCSからの取り込みがエージェントのジョブで動くようになりました（エージェントからVCSサーバーへの通信許可が要ります）。インターネットから切り離した環境でTerraformを実行する必要がある組織は、こちらが選択肢になります。

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

次の条件に当てはまるなら、S3などの自前バックエンドとGitHub Actions、またはAtlantisで組む方が安く済むか、要件を満たせます。

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

AWS上のTerraform運用をどちらの構成で組むか決めきれない場合は、AWS・Google Cloud・Azureのインフラ構築支援で、既存のstateとリポジトリ構成から見積もりを出しています。ライセンスの観点でTerraform以外も比べるならOpenTofuとは？Terraformとのライセンス・機能差と移行判断を実装視点で解説、Terraform本体の版の確認はTerraformの最新バージョンは1.16｜terraform versionでの確認とアップグレード手順・新機能で扱っています。

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 Boundaryなどがあります。

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｜terraform versionでの確認とアップグレード手順・新機能
• Terraform stateとは？tfstateの構造とS3バックエンド・移動削除の安全手順
• TerraformをGitHub Actionsで自動化しAWSへ反映する手順｜OIDCロール2本と承認付きapply
• AtlantisでTerraformをPR運用する構成と権限設計｜採用条件を解説