Terraform／Pulumi 周辺と MCP｜IaCの plan／apply を誰が承認するか（概念＋事例）

クラウドインフラをコードで管理するIaC（Infrastructure as Code）が浸透した現在、エンジニアが直面する最大の課題は「コードを書くこと」ではなく、「その変更を安全に、誰がどのタイミングで本番環境へ反映（apply）するか」という統制（ガバナンス）の設計に移行しています。

TerraformやPulumiを用いた開発において、plan（変更予測）の結果が意図通りであることを誰が保証し、誰がボタンを押すのか。本記事では、Terraform CloudやPulumi Cloudなどの公式ツールによる標準的な承認フローから、最新のMCP（Model Context Protocol）を活用したAIによるレビュー支援まで、実務に即したアーキテクチャを詳解します。

1. IaCにおける「承認」の必要性と職務分掌

オンプレミス時代、サーバーの増設やネットワーク変更には「物理的な作業」と「作業届」が必要でした。IaCではこれがGitのPull Request（PR）とマージに置き換わりますが、利便性の裏にリスクが潜んでいます。1行のコードミスで本番データベースが削除される（Replacementが発生する）リスクを、開発者一人に背負わせるべきではありません。

なぜGitHubのPR承認だけでは不十分なのか

多くの現場では、GitHubのPRが承認（Approve）されれば、マージと同時にCI/CDパイプラインが走り、terraform applyが実行されます。しかし、ここには「コード上のロジック」と「実際にインフラに起きる変化」の乖離という問題があります。コードが正しくても、既存のリソース状態（State）によっては意図しない削除や再作成が発生することがあるためです。

そのため、モダンなインフラ運用では以下の二段階承認が推奨されます。

• 論理承認（Code Review）: GitHub上で行う、意図や構文の確認。
• 実行承認（Deployment Review）: plan結果を確認し、物理的なリソース変更を許可する最終判断。

2. 実行基盤別：承認フローの実装パターン

主要なIaCツールには、この「実行承認」を管理するための機能が標準搭載されています。各ツールの特性を理解し、組織の規模に合わせた選択が必要です。

Terraform Cloud (HCP Terraform) の場合

HCP Terraform（旧Terraform Cloud）では、“VCS-driven workflow”を用いるのが一般的です。PRが作成されると自動的にplanが走り、その結果をTFCのUI上で確認できます。

• Speculative Plans: PR作成時に実行される未適用のプラン。
• Manual Apply: 設定により、apply実行前に特定のユーザーの承認を必須にできます。
• Sentinel / OPA: 「インスタンスタイプはt3.micro以下のみ」といったポリシーを自動適用し、違反があれば承認前にブロック可能です。

Pulumi Cloud の場合

Pulumiでは、“Pulumi Cloud”（公式マネージドサービス）の「Deployment Settings」を通じて承認フローを構築します。
Pulumi Deployments を利用することで、GitHub Actions等から直接applyするのではなく、Pulumi Cloud側に実行を委譲し、そこで承認待ちの状態を作ることが可能です。

GitHub Actions（Environments）の活用

特定のSaaSを使わず、GitHub Actionsのみで完結させる場合は、“Environments” 機能を利用します。production環境など特定の環境に対してデプロイを行うジョブに environment: production を指定することで、指定したレビュアーの承認なしにはジョブが進まないよう制御できます。

このようなインフラのガバナンスと、バックオフィス部門の承認フロー（経理・稟議等）は密接に関係しています。例えば、高額なインスタンスを立てる際の承認プロセスなどは、以下の記事で解説しているような業務DXの考え方が参考になります。

Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

3. 主要ツールの承認・運用機能比較

IaCの承認フローを支える主要ツールの機能を比較表にまとめました。コスト面だけでなく、既存のワークフロー（GitOps）との親和性が選定基準となります。

4. MCP（Model Context Protocol）が変えるIaCの承認実務

現在、急速に注目を集めているのが、Anthropic社が提唱したMCP（Model Context Protocol）を用いたAIによるIaC運用の補助です。これまで「人間が目視で確認」していたplan結果を、AIがコンテキストを理解した上で評価します。

MCPとは何か

MCPは、AIモデル（Claude等）が外部データソースやツールに安全にアクセスするための共通規格です。これをIaC運用に適用すると、以下のようなフローが実現します。

1. AIがMCPサーバー経由で最新のTerraformソースコードと、Stateファイル、そしてplan結果を取得。
2. AIが「今回の変更はセキュリティグループに全開放（0.0.0.0/0）を含んでいるため危険です」といった具体的リスクを指摘。
3. AIが「過去の同様の構成変更事例」や「クラウドプロバイダーのベストプラクティス」と照らし合わせ、承認の推奨（Ready to Merge）を出す。

これにより、プラットフォームエンジニアは細かな差分チェックから解放され、AIがフィルタリングした「重要な変更」のみに集中できるようになります。このデータ駆動型の自動化アプローチは、マーケティング基盤の自動最適化における考え方とも通ずるものがあります。

広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

5. 失敗しない承認フロー構築の5ステップ

実務で導入する際、最初からすべてをガチガチに固めると開発スピードが著しく低下します。段階的な導入を推奨します。

STEP 1：変更レベルの定義（ティアリング）

すべての変更に承認を求めると、レビューが形骸化します。

• Tier 1（低リスク）: タグの追加、既存リソースのパラメータ微調整。 → AIレビューのみで自動承認可。
• Tier 2（中リスク）: 新規リソースの追加、ネットワーク経路の変更。 → 1名以上のピアレビュー必須。
• Tier 3（高リスク）: DBの削除・再作成、IAM権限の広範な変更。 → 管理者（SRE）の承認必須。

このように、変更のインパクトに応じたレベル分けをコードベースで定義（例：GitHubのラベル活用）します。

STEP 2：GitHub PRによる論理レビューの徹底

コードの可読性やメンテナンス性は、実行結果（Plan）には現れません。ここでは「なぜこのリソースが必要なのか」という意図を重視します。
インフラ負債を抱えないための考え方は、SaaSやオンプレ負債の剥がし方を解説した以下の記事も参考になるでしょう。

SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

STEP 3：CIによる自動チェック

terraform fmt（整形）や tflint（エラーチェック）、tfsec（セキュリティスキャン）をPR作成時に強制します。人間に「インデントがずれている」といった指摘をさせてはいけません。

STEP 4：Plan結果の可視化と通知

PRのコメント欄に terraform plan の実行結果が自動で書き込まれるように設定します。HCP Terraformの標準機能や、OSSの tfnotify を利用します。ここで前述のMCP/AIを活用し、「このプランを適用すると、本番DBのダウンタイムが約5分発生します」といった要約を添えるのが理想的です。

STEP 5：最終承認とデプロイ

開発環境はマージで即時適用、本番環境はボタンクリックによる「承認後のapply」というフローに分離します。この際、承認したユーザーと実行したユーザーのIDがログに残るようにします。

6. よくあるエラーと対処法

承認フローを導入すると、以下のような実務上のトラブルが発生しやすくなります。

1. ステートロック（State Lock）の競合

承認待ちのPRが複数ある場合、あるPRがapply中に別のPRがplanを実行しようとすると、ステートがロックされエラーになります。これはTerraform Cloudの「Run Queueing」機能や、GitHub Actionsでの concurrency 設定でキューイング処理を行うことで解決します。

2. シークレット情報の露出

plan結果にパスワードやAPIキーが含まれてしまうケースです。sensitive = true 設定を適切に行うとともに、AIレビュー（MCP）のプロンプトで「秘密情報の検知」を組み込むことが有効です。

7. まとめ：自社に最適な承認フローの選び方

IaCの承認フローに「唯一の正解」はありませんが、判断基準は明確です。

• スピード優先のスタートアップ: GitHub Actions + Environments で、特定のブランチへのマージを承認制にするシンプルな構成。
• ガバナンス重視の中堅・大企業: HCP Terraform または Pulumi Cloud を導入し、SentinelやPolicy as Codeで自動ガードレールを構築。
• 先進的な効率化を狙うチーム: MCPサーバーを介してAIに plan の事前評価をさせ、人間は「リスクあり」と判定されたものだけを精査する体制。

インフラは一度構築して終わりではなく、常に変化し続けるものです。承認フローを「縛り」ではなく「エンジニアを事故から守る安全装置」として再定義し、AIやMCPといった新しい技術を取り入れることで、安全かつ高速なインフラ運用を実現してください。