Terraform と Pulumi：可読性、テスト、チーム適合性

人々が本当に「Terraform と Pulumi」で問いていること

「Terraform と Pulumi」と言うとき、多くはプロバイダの数や目新しい機能の優劣を論じているわけではありません。実務的な問いはもっと現実的です：インフラを作成・変更・トラブルシュートする日常で、どちらが毎週扱いやすいか？

日常業務では、インフラをコード化するというのはクラウド構成が繰り返し実行可能な形で書かれているということです。変更はコードの変更として扱い、実行前にレビューします。ツールは何が変わるかのプランを示し、誰が何をしたかを残して適用します。

だからこそ、機能の多さより可読性と予測可能性が重要です。ほとんどのチームが失敗するのは、ツールがリソースを作れないからではありません。変更が何をするかをすぐに理解できないことや、出力を信用できずに手が止まることが原因です。

問題は通常、レビューが遅い・オンボーディングがまちまち・環境が並行してずれていく・次の変更が本番を壊すのではないかという不安が続く、という形で現れます。

この比較では、各ツールが実際のレビューでどう読まれるか、チーム導入がどう進むか、テストは現場でどう機能するか、そして設定ドリフトを生まない環境管理の方法に焦点を当てます。

可読性とコードレビュー体験

多くの「Terraform vs Pulumi」議論は一つの単純な問いから始まります：チームは変更を読んでそれが何をするか予測できるか？

Terraform は HCL を使い、インフラ向けに設計されています。VPC、IAM ロール、アプリサービスのような一般的作業では、ファイルは宣言的に読みやすく、リソースの種類、名前、主要な設定がすぐ分かります。プロジェクト間で異なる人が書いていてもレビューの感触は比較的一貫します。

Pulumi は通常のアプリコードのように読めます。関数やオブジェクトでリソースを作り、ループや条件、ヘルパー関数を自由に使えます。インフラロジックが複雑な場合はエンジニアにとって非常に読みやすくなりますが、値が動的に構築されるときに何が起きるかを隠してしまうこともあります。

変数や再利用の感じ方も異なります。Terraform は inputs、locals、modules を使う方向に導くため、レビュアーは何が入力として変わったか、どのモジュールのバージョンが変わったかに集中しがちです。Pulumi は言語のツール（関数、クラス、パッケージ、共有ライブラリ）を通じて再利用を促します。これで重複は減りますが、レビュー時に読むコード量が増えることもあります。

非専門家向けのレビューは、チームがいくつかの習慣で合意しているときにうまく行きます：名前やタグを予測可能に保つ、凝ったループより単純な式を好む、IAM やネットワーク、削除保護などリスクの高い設定の近くに短い「なぜ」を書く、差分を小さく保つ、コードと一緒にプラン/プレビュー出力を必ず見る、などです。

レビュアーが主にオプスやプラットフォーム担当なら、Terraform の均一な形が助けになります。レビュアーが主にソフトウェアエンジニアなら、Pulumi は自然に感じられることが多いですが、コードを平易に保つ規律が必要です。

チーム導入と学習曲線

Terraform と Pulumi の導入差は単なる構文の違いではありません。誰が変更をレビューし、承認し、問題発生時にサポートするか、という点に関わります。

Terraform は目的別に作られた一つの言語（HCL）と少数の IaC 概念を学ぶことを要求します。コードが設定のように読め、プロジェクト間で似た見た目になりやすいため、オプスやセキュリティ、プラットフォームチームには導入しやすいです。

Pulumi は IaC 概念に加えて一般的なプログラミング言語（多くは TypeScript や Python）を学ぶ必要があります。チームが既にその言語で開発しているならオンボーディングは早く感じられますが、そうでない場合、レビューをたまに行うメンバーにとっては学習曲線が存在します。

実務では、役割を明確に分けるとオンボーディングが楽になります。典型的には次のような役割に分かれます：作者（日々の変更を行う）、レビュアー（意図とリスクをチェックする）、承認者（セキュリティやコストを確認する）、オンコール（デバッグや state の基本を扱う）。全員が同じ深さを知る必要はありませんが、変更の提案・プレビュー・適用の流れについて共通のメンタルモデルが必要です。

一貫性が導入を崩壊させないカギです。小さな規約セットを選び、早期に徹底してください：フォルダ構成、命名、タグ付け、入力の渡し方、環境の分離、そして「完了」の定義（フォーマット、リンティング、プランチェックをすべての変更で行う）などです。

経験の混在するチームでは、レビューのしやすさを最大化する選択が安全です。チームの半分が TypeScript に強ければ Pulumi はうまく機能しますが、パターンの標準化と「賢い」コードの禁止が必要です。レビュアーが非開発者中心なら Terraform の単純な形状が勝つことが多いです。

もし開発者が再利用可能なコンポーネントのために Pulumi を望むが、セキュリティレビュアーが読みにくさを訴えるなら、共有テンプレートリポジトリと厳格なレビュー規則から始めてください。これによりチームが自信を持つまで驚きを減らせます。

ステート、シークレット、変更の信頼性

Terraform と Pulumi の議論の多くは「この変更は思った通りに動き、本番を壊さないか？」という不安に帰着します。ステート、シークレット、プレビューが信頼の勝敗を分けます。

Terraform は state ファイルで現実を追跡します。ローカルに置けますが、チームは通常リモートバックエンドとロックに移行します。ステートが欠落していたり古かったり、ロックなしで複数人が同時に apply すると、Terraform は既に存在するリソースを再作成したり削除しようとすることがあります。Pulumi もステートを使いますが、stack = environment が明示的で、設定とステートが結びついていると感じるチームが多いです。

シークレットは次の鋭いポイントです。Terraform では出力を sensitive としてマークする手段がありますが、変数、ログ、state を通じて漏れる可能性は残ります。Pulumi はシークレットをファーストクラスで扱い、スタック状態内で暗号化するため偶発的露出が減ります。どちらのツールでも安全な心構えは同じです：state はシークレットストアではない、可能ならクラウドのシークレットマネージャーを使う、ということです。

変更の信頼性は差分から生まれます。Terraform の plan は広く理解され、レビューで標準化しやすいです。Pulumi の preview も似ていますが、どれだけロジックをコードに入れるかで読みやすさが左右されます。プログラミング要素を増やすほど規約が必要になります。

ガバナンスの面では、チームは大抵同じコア要件に収束します：ロック付きのリモートステートと最小権限アクセス、プラン/プレビュー出力を含むレビュー手順、本番には手動承認、環境は分離して別の認証情報を使う、などです。

再利用パターン：モジュール vs コンポーネント

「再利用」と言うと多くの場合こういう意味です：VPC、データベース、Kubernetes、IAM のようなスタックを複数チームでコピーせずに作れるか？

Terraform の基本ブロックはモジュールです：入力と出力を持つリソースのフォルダ。チームはしばしば「ゴールデン」モジュール（ネットワーク、ログ、データベース）を公開し、バージョンを固定してアップグレードを選択肢にします。そのバージョン固定は単純で効果的です。新しいモジュールバージョンはチームごとにロールアウトできます。

Pulumi の基本はコンポーネント（ライブラリ化されることが多い）です。複数のリソースをまとめて一つの高レベルユニットとして作るコードです。再利用は通常の言語機能（関数、クラス、型付き入力）で自然に行えます。コンポーネントは内部パッケージとして共有でき、デフォルトやガードレールを統一できます。

実務的なアプローチは「プラットフォーム」と「アプリ」を明確に分けることです。ネットワークやセキュリティ、ベースクラスタなどの共有ビルディングブロックはプラットフォームグループが所有し、意見を持ったデフォルトをブロック内に置き、チームが本当に必要なオプションだけを許可します。境界でバリデーションを行い（命名ルール、必須タグ、許可地域など）、すべてをバージョン管理し、何が変わったかを平易な言葉で書き、実際のユースケースに沿った1〜2個の例を提供します。

コピー＆ペーストを避けるには、繰り返されるパターンをモジュール/コンポーネント候補として扱います。例えば「バックアップとアラーム付きの Postgres」が二つのチームで必要なら、それはサイズ・保持期間・オーナーのような小さな入力で動く一つの再利用ユニットにします。

構成ドリフトを起こさない環境管理

構成ドリフトは善意の変更から始まることが多いです。誰かがクラウドコンソールでセキュリティグループをちょっと編集したり、本番でアラートを止めるために DB フラグを変更したりします。システムは安定しますが、コードは現状と合わなくなります。

Terraform も Pulumi も一つのコードベースで複数環境を扱う考えをサポートしますが、モデリングが異なります。Terraform はワークスペース（あるいは別々のステートバックエンド）で dev/staging/prod を表すことが多いです。Pulumi はスタックを使い、各スタックが独自の config と state を持ちます。実際には、各環境の state を明確に分離し、単一の state ファイルを使い回さない方が結果はきれいです。

リソース命名は思ったより重要です。名前が衝突すると混乱した更新やデプロイ失敗が起きます。環境名を名前とタグに組み込み、どれがどこに属するか一目で分かるようにします。例：api-dev、api-staging、api-prod、および env=prod のような一貫したラベル。

アカウントやサブスクリプションを分けつつコードを共有するには、インフラロジックを一か所に置き、環境ごとにターゲットアカウントと設定だけ切り替えます。環境ごとにアカウントを分け、CI ジョブが適切なロール/アイデンティティを引き受けてから適用する、という構成が一般的です。

環境ごとのオーバーライドは小さく意図的にします。共通のベースラインを目指し、違いはインスタンスタイプやレプリカ数などのサイズや数だけに絞り、環境ごとの設定は環境/スタックごとの一つのファイルにまとめ、if env == prod のような散在ロジックを避けてください。コンソールでの変更を制限し、緊急対応は必ずその後にコードへ追記するルールにします。

ステップバイステップ：安全な変更ワークフロー

Terraform でも Pulumi でも安全なワークフローはほとんど同じです。目標は単純：すべての変更は毎回同じ方法でプレビューされ、レビューされ、適用され、「ローカルで動いたから本番でも大丈夫」という驚きが最小限にされることです。

多くのチームで機能する流れは次の通りです：

• コードを更新し、フォーマットと基本チェックを実行する。
• プラン/プレビュー（Terraform: plan, Pulumi: preview）を生成し、その出力を保存する。
• プルリクで差分をレビューし、削除・置換・広範な影響を優先的に確認する。
• レビューされたコミットから制御された場所（多くは CI）で適用する。
• クイックスモークチェックで検証し、何が変わったかを記録する。

どこで実行するかは重要です。ローカル実行は素早いフィードバックに良いですが、最終的な apply は一貫しているべきです。多くのチームはローカルでの preview/plan を許可し、apply は同じ環境変数、同じ認証情報ソース、固定されたツールバージョンで CI からのみ行うルールにしています。

バージョン固定は地味な救世主です。Terraform のバージョンとプロバイダバージョンや、Pulumi CLI と言語依存を固定してください。ロックファイルと依存制約は予期しない差分を減らします。

新しいメンバーが手順に従いやすいように、1 ページの「ここでの変更手順」を用意しておくとよいです：ハッピーパスのコマンド、誰がどこから適用できるか、シークレットの扱い（平文で渡さない）、不正な変更の止め方、プレビューで予期せぬドリフトが出たときの対処など。

チームが実際に使っているテスト手法

ほとんどのチームはアプリのユニットテストと同じやり方でインフラを“単体テスト”しません。現実的な分割は、明らかなミスを早期に検出する速いチェックと、本番に近いクラウドアカウントで変更が動くことを証明する少数のライブテストです。

静的チェック（高速）

Terraform では基本がフォーマットと検証、その後にセキュリティやポリシーチェックでビルドを失敗させます。ここで開くセキュリティグループ、タグ欠如、暗号化なしの S3 などを捕まえます。

Pulumi でもリンティングや型チェックを行い、小さなアサーション風テストをプログラムの出力に対して書けます（例：「すべてのデータベースにバックアップが有効」）。Pulumi はプレビューに基づくチェックや、クラウドリソースを作らずにテストできるモックもサポートします。

多くのチームがプルリクごとに実行するのはツール差はあまりなく：フォーマットと基本検証、静的セキュリティルール、予定変更に対するポリシーチェック、可読なサマリを含むドライランプレビュー、一定以上のリスクには短い承認ステップ、などです。

プレビューとライブテスト（遅い）

統合テストは通常、一時的な環境を作り変更を適用し、いくつかの主要な事実（サービス到達性、データベース存在、アラーム）を確認することを意味します。小さく保ってください。例えばロードバランサーモジュールの変更後にテストスタックを立ち上げ、ヘルスチェックが通ることを確認してから破棄する、という形です。これにより IaC テストが第二のフルタイム作業になるのを防げます。

構成ドリフト：検出、トリアージ、予防

ドリフトは多くの場合「ちょっとした修正」から始まります：誰かがセキュリティグループを開ける、IAM ポリシーを変える、オートスケーリングを調整する、DB のフラグをいじるなど。本当に急を要する場合もありますが、コードと実環境が乖離すると次の変更が怖くなります。

ドリフト検出は救出作戦ではなく習慣として機能します。多くのチームは定期的または大きなインシデント後に読み取り専用のプラン/プレビューを実行します。重要なのはツールではなく、誰かがその出力を実際に見ることです。

ドリフトが出たら修正する前にトリアージしてください。プロバイダ管理フィールドのような無害なノイズもあれば、「一時的に公開された」リスクある変更もあります。簡単な問いを持つと混乱が避けられます：変更は意図的か？承認されているか？セキュリティ/コスト/可用性に影響するか？IaC にきれいに表現できるか？緊急か？修正するとダウンタイムが起きるか？

ドリフトを放置してよいのは、それが既知で低リスクかつ文書化されている場合のみです。それ以外はクラウド側で元に戻すか、重要な変更なら IaC に取り込み次回の apply がそれを上書きしないようにするべきです。

ノイズを低く保つには、計算フィールド（タイムスタンプなど）の定期差分をフィルタし、有意なリソースのみでアラートを出すことです。タグとラベルはオーナーシップの把握に役立ちます。小さな慣習が大きな効果を生みます：owner, service, env, cost_center, intent（なぜ存在するか）など。

よくあるミスと落とし穴

Terraform と Pulumi の最大の落とし穴は言語自体ではなくワークフローです。チームは今日は速く感じるショートカットで後々何日もコストを払います。

プランを任意に扱うことは古典的な失敗モードです。人がプレビューを飛ばしてラップトップから直接 apply すると、共有された真実のソースやきれいな監査証跡を失います。ツールバージョンの不一致や認証差の違いが本番リスクになります。

もう一つの静かな問題は環境が一時的上書きでズレていくことです。ステージングでのちょっとした変更、本番での緊急修正、変数ファイルの「一度だけ」の差し替え、などが積み重なります。次の変更を誰も信用できなくなります。

Pulumi では動的コードの使い過ぎが罠になりがちですが、Terraform でも過度なテンプレート化で同様の問題が起きます。実行時にすべてが計算されるとレビューが当てになりません。変更を読んで差分を予測できないなら、システムは賢すぎます。

モジュールやコンポーネントのバージョン管理を怠るのも簡単に起きるミスです。共有モジュールをその場で変えると下流の複数リポジトリや環境が静かに壊れます。

多くのチームは次のようなガードレールでこれらを避けます：すべての変更で CI によるプレビュー/プランを実行し、apply は CI のみで行う、環境の違いを明示（別スタック/ワークスペース＋明確な入力）、賢い抽象より読みやすい冴えないコードを好む、共有モジュール/コンポーネントはバージョン化して意図的にアップグレードする、コンソールでの手動変更は「緊急→その後コード化」のルールで制限する、など。

選ぶ前や移行前のクイックチェックリスト

Terraform と Pulumi の選択は好みより、チームが毎週安全に変更できるかどうかに近い判断です。コミット（または移行）する前に次の質問に書面で答え、実際の運用と合っているか確認してください。

「変更を信頼できるか？」チェックリスト

• 適用前に明確なプレビューが見られ、それをレビュアーがリスクのある編集を見抜けるか？
• ステートは保護されているか（アクセス制御、必要に応じた暗号化）、バックアップはあり、メンテナが所有しているか？
• 日常的にシークレットはどこにあり、ローテーションしてもデプロイが壊れないか？
• 環境は設計上分離されていて、名前や境界は明確か（例：dev や staging が誤って prod に触れない）？
• 定期的にドリフトチェックを実施しているか、そしてドリフトの是正・許容・エスカレーションを決める担当者がいるか？

どれか一つでも「後で考える」となっているなら、一旦止めるサインです。多くの IaC の痛みは弱い変更管理から来ます：プレビューが不明瞭、環境が共有されている、ドリフトの責任者がいない、など。

選択をプレッシャーテストする実用的な方法は、実際のワークフローを一つ選ぶことです：「新しいキューを作り、サービスに繋げ、まずは staging に展開し、その後 prod に展開する」。これを自信を持ってレビューし、きれいにロールバックできるなら準備はできています。

例シナリオと実践的な次の一手

小さなチーム（エンジニア 1–2 名とプロダクトオーナー）が顧客ポータルを運営し、dev（日常）、staging（リリース確認）、prod（実ユーザー）という3環境を持っているとします。必要なものはデータベース、いくつかのサービス、キュー、ストレージ、監視。問題点は予想どおり：レビューが遅い、シークレットの扱いが怖い、「staging で動いた」が続くこと。

Terraform では、このチームは明確なフォルダ構成と少数のモジュール、ワークスペースや環境ごとのステートファイルを使うことが多いです。利点は大きなエコシステムと確立されたパターンが多いこと。欠点はロジックが増えると可読性が落ちやすく、テストは「プラン出力チェック＋いくつかのスモークテスト」に留まりがちな点です。

Pulumi では同じセットアップが普通のコードになります：ループ、関数、共有ライブラリ。変更が複雑なときはレビューがわかりやすくなり、テストも自然に書けます。代償はチームの慣れです。プログラミング言語でインフラを管理することになり、シンプルに保つための規律が必要です。

シンプルな決め方のルール：

• 標準ツールと最小限のコーディング、確立されたパターンを望むなら Terraform を選ぶ。
• 日常的にある言語でデプロイし、再利用性とテストを重視するなら Pulumi を選ぶ。
• リスク許容度が低ければ、レビュアーが確実に読める方を優先する。

実務的な次の一手：薄いスライスでパイロットを行う（サービス一つ＋DB）、短い基準（命名、環境分離、シークレットルール、レビュー必須項目）を書く、ひとつの安全ゲートを追加する（CI でのプラン/プレビュー＋適用後の基本スモークテスト）、そして最初のスライスが陳腐で再現可能になるまでは拡張しない、という流れが効果的です。

もしこれらのワークフロー周りで内部ツールを作るなら、AppMaster (appmaster.io) はアプリ層（バックエンド、Web、モバイル）を速く作りつつ、必要なインフラだけを IaC 側で管理するのに役立ちます。