TerraformのCI/CDを効率化する「tfaction」の概要と導入メリット

こんにちは！
ウォンテッドリーのインフラチームでエンジニアをしている加藤 (@kkato) です。

この記事は夏のアドベントカレンダー17日目の記事です。昨日は林 (@python_walker) さんの「UXから考える推薦システムの設計」でした。

本記事では、GitHub Actions上でTerraform Workflowを構築するためのツールである「tfaction」について紹介します。ウォンテッドリーでは2022年からtfactionを導入し、2025年現在も利用しています。私自身、ウォンテッドリーに入社してからTerraformを使い始めたのですが、いまだにtfactionに対する理解が曖昧なまま利用しています。

そこで今回は、自分自身の理解を深めることも兼ねて、tfactionの概要や特徴、導入のメリットなどを整理してみようと思います。TerraformのCI/CDに課題を感じている方や、tfactionの導入を検討している方の参考になれば幸いです。

tfactionとは
tfactionを利用するにあたっての前提条件
GitHub Flowに基づいたワークフロー
Monorepo前提
CIツールはGitHub Actionsのみ対応
tfactionがCI/CDにもたらす運用効率化のポイント
安全にstate操作を支援するためのtfmigrateサポート
Renovateによる安全なアップデート
terraform fmtやtflintによるコード品質の維持
tfaction導入後に見えてきた課題
まとめ

tfactionとは

tfactionとは Suzuki Shunsuke さんが開発したOSSで、説明は以下のとおりです。

GitHub Actions で良い感じの Terraform Workflow を構築するための Action

開発者 Suzuki Shunsuke 氏のブログより

tfaction を使うことで、以下のような Terraform 運用フローを自動化できます。

GitHub 上で Pull Request を作成
変更された Terraform ディレクトリごとに terraform fmt / init / validate / plan を自動実行
レビュー・承認後に PR をマージすると、対象ディレクトリに対して terraform apply を実行

この一連の流れを GitHub Actions 上で完結させることで、人為的ミスの防止や作業効率の向上を図ることができます。

tfactionを利用するにあたっての前提条件

GitHub Flowに基づいたワークフロー

tfaction は、GitHub Flowに則ったシンプルなブランチ運用を前提としています。基本的な流れは以下の通りです：

default branch から feature branch を作成
feature branch 上で Terraform の変更を行い、Pull Request を作成
Pull Request 上で terraform fmt / init / validate / plan を実行
Pull Request を main にマージすると terraform apply が実行される

Monorepo前提

tfactionは、複数のTerraformディレクトリを1つのリポジトリで管理する Monorepoスタイルでの利用を前提としています。それぞれのディレクトリ単位で plan/apply を個別に実行でき、影響範囲の明確化や安全な運用が可能です。

CIツールはGitHub Actionsのみ対応

tfactionはGitHub Actionsに特化して設計されています。他のCIツール（CircleCI や GitLab CI など）には対応していません。

tfactionがCI/CDにもたらす運用効率化のポイント

まず前提として、Terraform運用にCI/CDを導入すること自体に大きな価値があります。手作業でのterraform applyは、オペレーションミスや意図しない変更を生むリスクが常に伴います。CI/CDを整備することで、Pull Requestをトリガーにterraform planが自動実行され、レビューがしやすくなります。これにより、誰が・いつ・何を・なぜ変更したのかがGitの履歴として明確になり、より安全にインフラを管理することができます。

ウォンテッドリーではtfaction導入以前、TerraformのCIフローを自前で整備していました。しかし、tfactionを導入したことで、CIパイプラインのメンテナンスコストが大きく減り、本質的なIaC改善に時間を割けるようになりました。また、OSSなのでベストプラクティスを外部から取り込みやすいというメリットもあります。

ここでは、tfactionを導入して特に便利だと感じた点について紹介します。

安全にstate操作を支援するためのtfmigrateサポート

Terraformを運用していると、importやstate mvのようなtfstateの直接操作が必要になる場面がたびたびあります。しかし、こうした操作は手動で行うとミスのリスクが高く、破壊的な影響を及ぼしかねません。tfactionでは、そうした課題を解決するために、tfmigrateというOSSツールをサポートしています。

tfmigrateでは、専用のマイグレーションファイルを作成し、その中にimportやstate mvなどの操作内容を記述します。たとえば、以下のようにHCL形式で操作内容を定義します。

migration "state" "test" {
  dir = "."
  actions = [
    "import aws_db_instance.foo",
  ]
}

tfmigrate planを実行すると、実際にtfstateを変更する前に差分を確認できるため、安全性を確保しつつ事前に内容をレビューできます。問題がなければtfmigrate applyを使って、変更を本番のtfstateに反映します。このようにtfmigrateを使えば、意図しない変更を防ぎながら、変更内容をチームで確認・承認するフローを構築できます。tfactionではtfmigrateの実行も自動化されており、安全かつレビューしやすいtfstate操作を実現できます。

Renovateによる安全なアップデート

ウォンテッドリーでは、依存関係のアップデートを自動で検出・PR作成してくれる Renovate というツールを利用しています。

しかし、Terraformのようにインフラに直接影響を与えるコードでは、自動マージは慎重に行う必要があります。tfactionでは、terraform planの結果に差分が含まれていた場合はCIを失敗させる設計になっており、差分がない場合のみ自動でマージされるようになっています。これにより、安全性を担保しつつ、tfactionならびに依存ツールの継続的なアップデートを自動で行うことができます。

terraform fmtやtflintによるコード品質の維持

Terraformコードのフォーマット (terraform fmt) や、静的解析 (tflint) もCIパイプラインに組み込まれており、チーム全体でコードのスタイルや品質を統一しやすくなっています。ベストプラクティスに沿った記述が自然と定着するため、コードベースの品質維持が可能です。

tfaction導入後に見えてきた課題

tfactionの導入によってTerraformのCI/CDフローを簡単に整備できるようになり、チーム全体で本格的なCI/CD運用が進むきっかけとなりました。これにより、レビューもしやすくなったほか、インフラコードの変更がGitの履歴として残るようになり、安全にインフラを管理・運用できる体制を整えることができました。

一方で、CI/CDの適用範囲が広がったことで、それまでは表面化していなかった課題も見えてきました。特に、巨大なtfstateを持つTerraformプロジェクトでは、CI上でのterraform planの実行に非常に時間がかかる、あるいはAPIリクエストの上限に達してエラーになる、といったケースが発生するようになりました。

これらの課題は、tfaction自体の問題というよりも、CI上でTerraformを実行する運用を本格導入したことで顕在化したものです。小規模なtfstateでは問題なく活用できている一方で、大規模なtfstateについては、サービス単位や環境単位でtfstateを分割するなどの工夫が求められるようになりました。

以前、弊社の川井（@fohte）が HashiTalks Japan 2024 で発表したスライドでも巨大化したtfstateによる苦労とその対処法について詳しく紹介しています。ぜひ以下の資料も参考にしてみてください。