OPENLOGI Tech BlogPublicationへの投稿
⚖️

HCP Terraformからtfactionに移行した話

k-saiki
に公開
Terraform
tfaction
hcpterraform
tech

はじめに

HCP Terraformを利用してTerraformのCI/CDを運用していました。しかし、いくつかの課題をきっかけにtfactionへ移行しました。本記事では移行に至ったモチベーションと移行後の所感についてご紹介します。

HCP Terraformとは

HCP TerraformはHashiCorpが提供するTerraformのマネージドサービスです。State管理、リモート実行、VCS連携、SentinelやOPAを使ったPolicy as Codeなどを提供しており、Terraformを組織で運用する際の選択肢として広く利用されています。

なお、私たちはSentinelやOPAを使ったPolicy as Codeによるポリシーの強制や大量のワークスペースを管理しておらず、純粋にTerraformのCI/CDにHCP Terraformを利用していました。本記事はこの前提に基づきます。

tfactionとは

tfactionはsuzuki-shunsuke氏が開発したGitHub Actions用のTerraform Workflowフレームワークです。モノレポでの利用を前提に設計されており、ドリフト検出やtrivy, tflint, conftestの実行など実践的な機能を備えています。

移行のモチベーション

コスト最適化

HCP Terraformからの移行を検討した最大の理由はコストです。HCP Terraformの課金モデルは管理対象リソース数に基づいておりリソースの数に応じて課金が発生します。IaCカバレッジがまだまだ低い状態で、これからIaC化を本格的に進めようとしていたタイミングであり、このまま進めると将来的にコストがボトルネックになることが予想されました。

また、コストを意識するあまりリソース設計に悪影響が出る可能性も懸念していました。例えば、aws_vpc_security_group_ingress_ruleを使って個別にセキュリティグループルールを管理する代わりに、aws_security_groupのインラインでまとめて管理してしまうケースなどです。インラインでまとめて管理すると変更時の差分が非常に見づらくなるケースがあり推奨されません。

一方、tfactionのコストは主にGitHub Actionsの実行時間とtfstateを保管するS3の料金のみです。今後IaCを推進していくことを考えると、tfactionへの移行によりコスト効率は大幅に改善されると判断しました。

ワークスペース設定の煩雑さ

HCP Terraformはコード上でrequired_versionを使ってTerraform本体のバージョンを固定しても、実際に実行されるバージョンはHCP Terraformのワークスペース設定に依存します。

そのためTerraform本体のバージョンをアップデートする際は、コードの変更に加えてHCP Terraformのワークスペース設定も変更する必要があります。HCP TerraformのWebUIからポチポチ変更する必要があり、この作業は地味にストレスでした。

terraform-provider-tfeを使えばHCP Terraformのワークスペース設定もコードで管理できますが、逆に手間が増えるように思えます。

tfactionはaquaを使ってCLIツールのバージョンを管理します。Renovateを導入していればTerraform本体のバージョンアップもひとつのPull Requestで完結します。

GitHubへの統合

普段の開発はGitHubで完結しているにもかかわらず、Terraformの実行結果だけは別のツールを確認しに行く必要があるというのは若干の煩わしさを感じていました。

tfactionではplanやapply結果がPull Requestコメントとして投稿され、GitHub Actionsのログからも詳細を確認できます。コードレビューから実行結果の確認まですべてをGitHub上で完結できます。

マルチレポ運用の課題

基本的に単一のチームがメンテナンスしているにも関わらず、AWSアカウントやサービス(GitHubやDatadogなど)ごとにリポジトリが分割されたマルチレポ構成で運用しており、以下のような課題がありました。

  • Terraform本体、Terraformプロバイダー、GitHub Actionsで使用するActionのバージョンアップを複数リポジトリで行う必要がある
  • GitHub Actionsワークフローを各リポジトリで個別にメンテナンスする必要がある

実際にTerraform本体、Terraformプロバイダーのバージョンがリポジトリによってバラバラであり、統一されておらずメンテナンスが行き届いていない状況でした。

上記はマルチレポを採用しているから発生している課題であり、HCP Terraformでもモノレポにした上でRenovateを導入すれば課題は解決します(Terraform本体のバージョンアップの場合、"ワークスペース設定の煩雑さ"で述べたHCP Terraformワークスペース側の設定問題は発生しますが)。

これまでの課題も自前でGitHub Actionsワークフローを書けばなんとかできるものでしたが、モノレポ化によって懸念される「不必要なCIの実行」の対策としてtfactionに注目しました。

tfactionはモノレポを想定して設計されており、特にローカルパスモジュールを参照する関連ルートモジュールのみでCIを実行できる(参考: local-path Module | tfaction)という点が、導入を後押しする大きな要因となりました。

移行

tfactionに移行を決定する前からモノレポに別途移行を進めており、モノレポ化完了後にtfactionへの移行を進めました。移行にあたって以下のリンクを参考にしました。

当初は段階的な移行として「ワークフローはtfactionを使いつつ、実行はHCP Terraform(CLI-driven Workflow)を利用する」という構成を検討していました。

tfactionはplanで差分が発生していない場合においても*.tfファイルが変更されていればapplyを実行する動作になります。しかしHCP Terraformはplanで差分がない状態でapplyを実行することができずError: Saved plan has no changesといったエラーになります。こういった状況はTerraform本体やTerraformプロバイダーのアップデートのタイミングで発生します。

移行時の一時的なものなのでこのエラーを許容して運用することもできたかもしれませんが、tfactionによってPull Requestに"Apply Failed"とコメントされ、混乱を招きかねないためこの移行方法は採用しませんでした。

移行後の所感

コスト面での改善は期待通りで、リソース数を気にせずIaC化を進められるようになりました。現在の管理対象リソース数は合計3300程度(データソース等除く)であり、HCP TerraformのEssentialとtfactionのGitHub Actionsの使用量(2025年11月実績)で比較すると以下の対比になります。

  • HCP Terraform(Essentialプラン): 3300(resources) * $0.10(per month) = $330
    • 既に使用していないのでEssentialに500リソース無料が適用されるか不明ですが、適用される場合は$280
  • tfaction(GitHub Actions): 1517(minutes) * $0.008(Standard runner: ubuntu-latest) = $12.136
    • GitHub Actionsの無料使用枠は消費しているという前提の計算
    • 厳密にはS3の料金も含める必要があるが現在のサイズはS3バケット全体で100MB程度であり、リクエスト料金を考慮しても月1ドル未満

また、Pull Request上でplan結果やapply結果を確認できるようになったことで、レビューがしやすくなったと感じています。

移行後も継続的に改善を進めており、ドリフト検出やTerraformモジュールごとにGitHubリリースを作成するワークフローも導入しています。必要に応じてワークフローを自分たちでカスタマイズできるため柔軟性も高いです。

どちらを選ぶべきか

今回の判断は、あくまで私たちの組織規模、要件、運用スタイルにはtfactionが適していたというだけです。Terraformをプラットフォームとして多数のチームに提供するような組織であれば、HCP Terraformが適している場面も当然あります。

それぞれがどのような組織規模や要件にマッチするかを私なりに考えてみました。

tfactionがマッチするケース

  • GitHub Actionsを既に活用しておりTerraformのワークフローも同じ基盤に統一したい
  • 複数のTerraform構成をモノレポで一元管理したい
  • ワークフローを自分たちでメンテナンスでき必要に応じて柔軟にカスタマイズしたい

HCP Terraformがマッチするケース

HCP Terraformは以下のようなケースでは依然として有力な選択肢だと考えています。特に大規模組織ではVCS連携を有効化するだけで各チームが使い始められるため導入のハードルが低いです。

  • 数十チーム以上が様々なリポジトリでTerraformを運用するような大規模組織
  • SentinelやOPAによるPolicy as Codeでガバナンスを組織全体に強制したい
  • 監査要件に対応するためのログの一元管理をしたい

まとめ

ツール選定は組織の状況や優先事項によって最適解が変わります。私たちはIaC化の推進フェーズにあったこと、既にGitHub Actionsを活用していたこと、コスト効率を重視していたことなどから、tfactionへの移行が現時点では適切な判断だったと考えています。

しかし、将来組織規模の拡大やガバナンス要件の変化に応じて、HCP Terraformの採用を改めて検討する局面もあると考えています。

OPENLOGI Tech Blog
OPENLOGI Tech BlogPublication

私たちは身近な社会課題である物流の未来を変えるべく、「物流版AWS」をコンセプトとしたプラットフォームの開発、データの活用によって、業界全体の最適化を目指す会社です。

Discussion