IaCツール選択の現実
Infrastructure as Code (IaC)のツール選択は、チームの生産性に直結する。KGAはTerraformを3年間メインで使用し、2025年から新規プロジェクトでPulumiの採用を開始した。両方を本番で運用している立場から、忖度なしの比較を行う。
Terraform: 業界標準の安心感
Terraformの最大の強みはエコシステムの成熟度だ。AWSだけでも3,000以上のリソースタイプに対応し、ほぼ全てのクラウドサービスをカバーする。Stack Overflowの回答数、ブログ記事、書籍の量は圧倒的で、問題解決の情報に困ることがない。
HCL（HashiCorp Configuration Language）はインフラ定義に特化したDSLで、学習曲線は緩やかだ。YAMLよりは表現力があり、汎用プログラミング言語よりはシンプル。初日からterraform planの出力を読んで変更内容を理解できる。
KGAのTerraformコードベースは約25,000行で、AWS（メイン）、GCP（一部）、Cloudflareを管理している。モジュール化により再利用性を確保し、Terragruntでマルチ環境（dev/staging/prod）の設定を管理している。
Terraformの限界
HCLの限界に最初にぶつかるのは条件分岐だ。count と for_each で基本的なループは書けるが、複雑な条件分岐は三項演算子の入れ子で可読性が壊滅する。KGAの実例では、環境ごとに異なるVPCサブネット構成を定義する際、HCLの条件分岐が20行を超えて誰もメンテナンスしたくないコードになった。
動的なリソース生成も苦手だ。「APIの設定ファイルからリソースを動的に生成する」ようなケースでは、local values + for_eachの組み合わせで実現はできるが、デバッグが困難で、terraform planの出力が膨大になる。
State管理のリスクも無視できない。terraform state rmを誤操作すると既存リソースとの関連が切れ、最悪の場合リソースの再作成が発生する。KGAでは1回、RDSインスタンスのstate操作ミスでデータベースが再作成されるヒヤリハットを経験した（幸いterraform planで事前に検出できた）。
Pulumi: プログラマーのためのIaC
PulumiはTypeScript、Python、Go、C#、Javaなどの汎用言語でインフラを定義できる。これがPulumi最大の差別化ポイントであり、プログラマーにとっては圧倒的に生産性が高い。
KGAではTypeScriptでPulumiコードを書いている。型安全にリソースを定義でき、IDEの補完が効く。条件分岐はif文、ループはfor文、関数で抽象化。Terraformで20行かかっていた条件分岐が3行で書ける。
実例として、KGAのマイクロサービス群のECSタスク定義をPulumiで管理している。サービス設定をTypeScriptのオブジェクトで定義し、それをmapしてECSリソースを動的に生成。新しいサービスの追加は設定オブジェクトに1エントリ追加するだけ。Terraformでは新しいモジュールインスタンスの追加と変数の受け渡しが必要だったものが、はるかにシンプルになった。
Pulumiの課題
エコシステムの成熟度はTerraformに劣る。AWSプロバイダはTerraform Providerのラッパーとして実装されているため、対応リソースはほぼ同等だが、ドキュメントの質と量に差がある。特にエッジケースのドキュメントが不足しており、Terraform のドキュメントを参照して Pulumi に翻訳する作業が発生する。
State管理はPulumi Cloudが推奨だが、KGAではS3バックエンドを使用している。Pulumi Cloudは便利だが、インフラの状態を外部SaaSに預けることに対するセキュリティ上の懸念があるクライアントがいる。
採用市場もTerraformの方が有利。「Terraform経験者」の求人はPulumiの10倍以上あり、チームの採用やオンボーディングではTerraformの方がスムーズだ。
移行の判断基準
KGAの移行判断基準を共有する。Pulumiに移行すべきケース: 既存のTypeScript/Pythonチームで、HCLの学習コストを避けたい。複雑な条件分岐やループを多用するインフラ構成。マイクロサービスの動的なリソース管理。テストの充実（Pulumiはunit testが書ける）。Terraformを維持すべきケース: 既存のTerraformコードベースが大きい。チームにTerraform経験者が多い。クライアントがTerraformを指定している。シンプルなインフラ構成。
KGAの現在の使い分け
既存プロジェクト: Terraform維持（移行コストが見合わない）。新規プロジェクト（複雑なインフラ）: Pulumi TypeScript。新規プロジェクト（シンプルなインフラ）: Terraform（学習コスト・採用の観点）。両ツール共通: CI/CDでplan/previewを必須化。本番への適用は2名以上のレビュー後にのみ実行。State のバックアップを日次で実施。
結論として、「全てをPulumiに」でも「全てをTerraformに」でもなく、プロジェクトの特性とチームの強みに応じて選択するのが現実解だ。