「インフラの変更が一部のベテランしか分からず、属人化している」「AIに任せて楽をしたいが、本番に触らせるのは正直こわい」。先日ご相談いただいた製造業 A 社の情シスは、まさにこの板挟みでした。Terraform のコードはあるのに、plan の差分を読めるのは退職予定の一人だけ。
この「IaC の属人化」と「AI に触らせる怖さ」が同時に解ける可能性を持つのが、2026 年 6 月に InfoQ が報じた Terraform MCP Server の GA（一般提供）です。HashiCorp 公式の Model Context Protocol サーバーにより、AI アシスタントが 自然言語で Terraform インフラを照会・操作できるようになりました。
受託で中堅・中小企業のインフラを支える立場では、これは「AI に IaC を任せたい、でも安全に統制したい」という最も多い相談に、設計で答えられるフェーズに入ったことを意味します。これまで OpenTofu/Terraform 移行と IaC ガバナンスの受託 で扱ってきた「IaC の標準化」が、今度は「AI エージェントが触る前提での統制設計」という新しい次元に移ります。本記事では弊社が提供する 「Terraform MCP 統制設計」 受託パッケージを整理します。
Terraform MCP Server で実際に何ができるのか
Terraform MCP Server は「AI がインフラを勝手に作り変える魔法」ではありません。MCP（Model Context Protocol）は AI エージェントと外部システムをつなぐ標準プロトコルで、その仕組みは MCP 完全ガイド で整理した通りです。Terraform MCP Server は、その Terraform 専用の窓口にあたります。公式情報（HashiCorp ブログ・公式ドキュメント）で確認できる主な機能は次の通りです。
| 機能カテゴリ | できること | 性質 |
|---|---|---|
| レジストリ照会 | プロバイダ・モジュール・ポリシー情報の取得、推奨提案 | 読み取り中心 |
| スタイルガイド参照 | Terraform スタイルガイド・モジュール開発ガイドの参照 | 読み取り専用 |
| ワークスペース操作 | HCP Terraform / Terraform Enterprise のワークスペース作成・更新・削除、変数・タグ管理 | 書き込みあり |
| Run 実行 | plan_and_apply（承認後に適用）、refresh_state（状態更新のみ）等の実行 | 書き込みあり |
| Stacks 対応 | Terraform Stacks を自然言語でデプロイ・管理 | 書き込みあり |
ポイントは、機能が「読み取りだけ」と「書き込みを伴う」にはっきり分かれていること、そして有効化する機能を --toolsets フラグで選択できることです。「公開レジストリ照会だけ」「操作系も含める」を起動時に切り替えられる ── ここが統制設計の起点になります。なお HashiCorp は「シークレットは MCP サーバー経由で共有されず、AI のアクセスはプロンプト時のみ有効化される（常時接続やバックグラウンドのデータ交換はない）」と明言しており、AI が裏で常にインフラを覗いている状態ではありません。
何が危ないのか ── 誤 apply・権限過多・機密
便利さの裏で、受託として必ず潰しておくべきリスクが三つあります。
ひとつ目は 誤 apply。自然言語は曖昧です。「古い検証環境を片付けて」という指示を、AI が本番ワークスペースに対する destroy を含む計画として解釈する余地はゼロではありません。plan_and_apply のような実行系を無防備に有効化すると、人間のレビューを飛ばして本番が変わる経路ができます。
ふたつ目は 権限過多。MCP サーバーが使うトークンやサービスアカウントに広い権限を与えると、AI の実質権限がそれと同じになります。AWS MCP サーバと IAM 統制の受託 でも同じ構図を扱いましたが、Terraform MCP では「MCP に渡す API トークン = AI が触れる範囲」と捉えるのが正解です。
みっつ目は 機密の混入。plan 出力や変数、state には IP アドレス・接続文字列・内部構成といった機微情報が含まれます。これを AI の文脈に流すこと自体が、クラウド外の LLM に内部構成を渡すことになりかねません。
整理すると、誤 apply は「plan 止まり + 承認ゲート」で、権限過多は「最小権限 + 環境分離」で、機密混入は「出力フィルタ + 環境限定」で抑えます。いずれも後付けではなく、最初の設計で経路ごと塞ぐのが要点です。
統制設計 ── 「触らせる」のではなく「触れる範囲を設計する」
統制の骨子はシンプルです。「AI に Terraform を触らせるかどうか」ではなく「どこまでなら触れてよいかを設計で固定する」こと。次の五点を組み合わせます。
読み取り専用から始める
最初から実行系を有効化しません。--toolsets を レジストリ照会・ガイド参照などの読み取り系に限定し、「plan の差分を AI に説明させる」用途から入ります。属人化の解消はここだけでもかなり進みます。
plan 止まり + 承認ゲート
書き込み系を入れる場合も、AI エージェントの経路は plan までで止め、apply は人間の承認を経た CI/CD パイプライン側で実行します。MCP から直接 apply する経路は、本番に対しては塞ぐのが基本方針です。
# 統制方針のイメージ（実際の構成はクライアント環境に合わせる）
# 環境ごとに「AI エージェントに許す toolset」を分ける
ai_agent_access:
dev:
toolsets: [registry, operations] # 検証環境は plan+apply まで許容
apply: agent_allowed
production:
toolsets: [registry] # 本番は読み取り照会と plan 説明のみ
apply: human_approval_required # apply は CI のレビュー済みパイプライン経由
# 本番での自然言語からの安全な流れ（イメージ）
# 担当者「本番の DB サブネットを 2 つ増やすとどうなる?」
# → AI が該当ワークスペースを照会し plan を生成・差分を日本語で説明
# → 担当者がレビュー、問題なければ PR を承認
# → apply は CI が実行（AI 経路では apply しない）最小権限と環境分離
MCP サーバーに渡すトークン／サービスアカウントは、環境ごと・用途ごとに分けて最小権限にします。本番用と検証用を同じ広い権限のトークンで兼用しない。「接続点ごとに権限を絞る」という、社内システムへのエージェントアクセス設計と地続きの考え方です。
監査ログ
誰が・いつ・どの自然言語指示で・どのワークスペースに対して何をしたか。MCP 経由の操作と CI 側の apply を 時系列で突き合わせられるログを初期構築に含めます。HCP Terraform / Terraform Enterprise の Run 履歴と、エージェント側のプロンプト履歴を対応づけるのがポイントです。
機密の流出防止
変数・state・plan 出力のうち機微なものは、AI の文脈に乗せない／マスクする方針を決めます。本番環境については読み取りも限定し、検証環境のダミーデータで AI の挙動検証を済ませてから広げます。
受託の進め方 ── 4 フェーズ
進め方は四段階に分けています。まず 診断（約 2 週間） で、既存の Terraform 構成・ワークスペース・トークン権限を棚卸しし、属人化している箇所を特定します。次の 統制設計（約 2 週間） で、toolset 方針・環境分離・承認ゲート・監査ログ・機密マスクの方針を固めます。続く PoC（約 2〜3 週間） では、検証環境で「読み取り → plan 止まり」までを構築し、わざと曖昧な指示や危険な指示を与えて挙動をテストします。最後の 段階展開（約 3〜4 週間） で、本番は読み取り照会から段階的に導入し、CI の承認パイプラインを整備して運用へ移管します。
冒頭の製造業 A 社では、フェーズ 1・2 の時点で「plan を AI に日本語で説明させる」だけを先行導入しました。退職予定者しか読めなかった差分を他のメンバーが確認できるようになり、属人化の解消が apply 権限の付与より先に効きました。
向き・不向き
| 向いている | 慎重にすべき |
|---|---|
| Terraform / IaC が既にある（コードが資産化済み） | IaC 化そのものが未着手 |
| 差分レビューが特定の人に属人化している | レビュー体制が既に複数名で機能 |
| HCP Terraform / Terraform Enterprise を利用中 | state を手元 CLI のみで運用し履歴が無い |
| 検証環境を本番と分離できる | 本番単一環境で実験の余地がない |
IaC 化自体がこれからの場合は、まず IaC の標準化から着手するのが順序です。MCP は「整ったIaCの上に乗せる」もので、土台が無いまま乗せると統制も曖昧になります。
価格モデル
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 / PoC | 90 万円〜（4〜5 週間） | 棚卸し + 検証環境 PoC | 統制方針レポート + ロードマップ |
| Lite | 30 万円〜 / 月 | 読み取り照会中心の運用 | toolset 運用 + 監査ログ確認 |
| Standard | 70 万円〜 / 月 | plan 止まり + 承認ゲート運用 | + 環境分離 + 承認フロー保守 |
| 初期構築 | 250 万円〜（一括） | MCP 統合 + 承認パイプライン + 監査 | 全プラン共通オプション |
金額はご相談時の構成・環境数によって調整します。
ハマりやすい落とし穴
落とし穴 1: いきなり実行系を全部有効化する。 便利さを試したくて --toolsets を全開放すると、本番への apply 経路が無防備に開きます。読み取り系から始めるのが鉄則です。
落とし穴 2: トークンを使い回す。 本番と検証で同じ広い権限のトークンを共有すると、最小権限が崩れます。環境ごとに分けます。
落とし穴 3: 監査ログを後回しにする。 「誰の指示で何が変わったか」を遡れないと、AI 経由の変更は説明責任を果たせません。初期構築に必須項目として組み込みます。
落とし穴 4: 機密のマスクを決めずに本番を読ませる。 plan 出力や変数の接続情報がそのまま LLM の文脈に乗ります。本番は読み取りも限定し、検証データで挙動を固めてから広げます。
まとめ ── AI に「触らせる」のではなく「触れる範囲を設計する」
Terraform MCP Server の GA で、AI エージェントが自然言語で IaC を扱える時代が現実になりました。ただし価値が出るのは、便利さに飛びつくことではなく、読み取り専用から始め・plan で止め・承認ゲートを置き・最小権限と監査ログで囲うという統制を設計したときです。属人化したインフラを開く鍵は、apply 権限の付与よりも先に「AI に差分を説明させる」ところにあります。
まずは小さく始めてください。第一歩は、検証環境で「読み取り照会と plan 説明だけ」を有効化してみること。第二歩は、本番に広げる前に承認ゲートと監査ログの設計をそろえることです。
「AI に IaC を任せたいが本番に触らせるのが怖い」「属人化した Terraform を複数名で読めるようにしたい」「MCP の操作を監査ログに統合したい」というご相談は、お問い合わせフォーム からお気軽にどうぞ。
Sources
- Terraform MCP Server Enables AI Assistants to Interact with Terraform Infrastructure（InfoQ）
- Terraform MCP server is now generally available（HashiCorp）
- Terraform MCP server overview（HashiCorp Developer）
- Build secure, AI-driven workflows with new Terraform and Vault MCP servers（HashiCorp）
- OpenTofu/Terraform 移行と IaC ガバナンスの受託（GH Media）
- CDK/Terraform による IaC 標準化の受託（GH Media）
- AWS MCP サーバと IAM 統制の受託（GH Media）
- MCP トンネルで社内システムにエージェントアクセス（GH Media）
- MCP 完全ガイド（GH Media）
