【速報】チケット起票もHCL直書きも不要に：HCP Terraform「Developer Portal」と AI 連携（MCP）が発表

皆さま、こんにちは！
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。

0. はじめに

HashiConf at TechXchange 2026 にて発表された、HCP Terraform に関する注目の新機能速報をお届けします。

今回の基調講演で発表された目玉の一つが、開発者向けセルフサービス基盤 「Terraform Developer Portal（TDP）」 と、AI エージェントと直接通信する 「Remote Terraform MCP Server」（※いずれも Public Preview） です。

一見すると「開発者向けの新しいポータル UI ができた」という話に見えますが、本質はそこではありません。既存の「No-Code Provisioning」を強化し、Day-2 運用の「Actions」、さらには「AI エージェントへの安全なレール」までを 1 本の線で繋いだ、実用的なセルフサービス基盤（IDP）の完成形 です。本稿では、発表内容とそのアーキテクチャのポイントを分かりやすく解説します。

※発表内容を自分なりに読み解き、手元で少し触ってみた感触をもとにまとめた速報になります。もし認識違いや間違いなどがあるかもしれませんが、ご容赦ください…！

3行まとめ

• 開発者向けカタログ（TDP）: HCL を書かずに、画面から Template（土台）と Add-on（パーツ）を組み合わせてインフラを安全にプロビジョニング可能に。
• 運用タスクのボタン化（Actions）: Terraform 1.14 の action ブロックがポータル画面に実行ボタンとして出現。DB バックアップやキャッシュクリアが画面から即実行可能。
• AI エージェント対応（MCP）: AI に生の HCL を書かせるのではなく、承認済みカタログ（TDP）の注文フォームを埋めさせる安全な自動化を実現。

1. 何が変わったのか？：従来の「No-Code Provisioning」との決定的な違い

HCP Terraform を使ったことのある方なら、「画面からモジュールを選ぶ機能なら、昔から No-Code Provisioning があったのでは？」と思うはずです。

今回の Developer Portal は、まさにその 従来の No-Code Provisioning が抱えていた実運用上のボトルネックを解消したアップデート です。

1つのリソースだけを作成するシンプルな構成であれば従来の No-Code Provisioning でも十分機能していましたが、Web・DB・ストレージなどが絡む実際のシステムを組もうとすると、以下のような悩みに直面していました。

• 【パターンA】「全部盛り」の巨大モジュールにする
  • モジュール内で値を自動連携できるので入力は楽だが、変更影響範囲（Blast Radius）が大きくなり怖すぎる。
• 【パターンB】モジュールを細かくバラして、値を直接指定（手入力/ハードコード）する
  • 影響範囲は局所化できるものの、親リソースの vpc_id や subnet_id を画面から手動で調べてコピペ入力する必要があり、設定ミスの可能性もあって運用が非常に面倒。

今回の TDP（Developer Portal） は、この「巨大モジュール vs 手動コピペ」という究極の二択を解消し、「モジュールは綺麗に分離したまま、値の引き渡しだけを裏側で自動化する」 という理想の形を実現してくれます。

2. カタログの設計思想：Template と Add-on の分離

ポータル内では、システムを以下の 2 つの役割に分けて管理します。

• Template（土台）: アプリケーションが稼働するための共通骨格（VPC、コンテナ実行基盤、ネットワークなど）。
• Add-on（追加パーツ）: アプリの要件に応じて後から足すリソース（データベース、キャッシュ、ストレージバケットなど）。

プラットフォームチームの工夫：モジュールはシンプルに保つのが吉？

プラットフォームチームが Add-on 用モジュールを作るときは、「あえて for_each を使わずに1つだけ作る形」にしておくのが良さそうです。

複雑な Map や Object 型の変数を組んでしまうと、ポータルの入力欄が「生の JSON を直接打ち込むテキストエリア」のようになってしまい、フォームの使いやすさが損なわれてしまう印象を受けました。

モジュールは「1つ分をシンプルに作る形」に留めておき、バケットが2つほしい時はポータルから Add-on を2回追加してもらう、という運用にした方が入力ミスも減りそうです。

3. 全体アーキテクチャ図（Google Cloud の例）

Git リポジトリ（VCS）から Private Module Registry、No-Code Provisioning、そして Developer Portal と利用インターフェース（開発者 / AI）までがどう繋がっているかの全体スタックです。

アーキテクチャのポイント

• 入力と出力の自動バインド: Template（Cloud Run 基盤）が払い出した vpc_id や connector_id は、Add-on ①（Cloud SQL）の入力へ裏側で自動注入されます。
• DB モジュールと Actions の近接: DB モジュールの HCL 内に action ブロックを仕込んでおくことで、ポータル上の Cloud SQL カードのすぐ横に「手動バックアップ」ボタンが自動出現します。

4. 動いているインフラを操作する「Actions」

インフラを作った後の運用作業（Day-2 オペレーション）をセルフサービス化するのが 「Actions」 です。

Terraform 1.14 の action ブロックが画面のボタンになる

Terraform 1.14 で導入された action ブロックは、CRUD を行わず、State に状態を記録しない「一時的な命令的オペレーション」を定義するための構文です。

1.14 の登場時点では主に CLI（terraform action run など）から呼び出す機能でしたが、TDP（Developer Portal）と組み合わさることで真価を発揮します。

インフラチームが以下のようにモジュールの中に action ブロックを定義しておくだけで、TDP のポータル画面上に「実行ボタン」として自動で表示されます。

# modules/cloud-sql/main.tf に定義
resource "google_sql_database_instance" "default" {
  name             = var.instance_name
  database_version = "POSTGRES_15"
  # ...
}

# State を持たないオンデマンド実行タスク（手動バックアップ）
action "google_sql_backup_run" "manual_backup" {
  config {
    instance    = google_sql_database_instance.default.name
    description = "Developer Portal から実行された手動バックアップ"
  }
}

開発者は Google Cloud コンソールに入ることなく、ポータル画面のボタンを押すだけで安全にバックアップを実行できます。

5. 裏側はどう動くのか？：Application と Workspace

ポータル上でプロビジョニングされたリソースは、裏側では従来の「Workspace」として払い出されます。

DP は、リソース群を 「Application」 という開発者目線の論理的な枠組みでまとめて管理します。

これにより、開発者は「Workspace」やそれに紐づく「Variable Set」といった裏側の複雑な仕組みを意識する必要がなくなり、自分の担当サービスに必要なパーツをポータルから選ぶだけで完結できるようになります。

• ポータル側の見え方: 決済サービス（Application）
• HCP Terraform 裏側の実体:
  • ws-payment-core（Template 用 Workspace）
  • ws-payment-db（Add-on ① 用 Workspace）
  • ws-payment-gcs-images（Add-on ② 用 Workspace）
  • ws-payment-gcs-reports（Add-on ③ 用 Workspace）

実体が通常の Workspace であるため、監査ログや Terraform Policy（Sentinel による検査）といった既存のガバナンス機能がそのまま 100% 適用される のが大きな強みです。

6. AI 連携のここがすごい：Remote Terraform MCP Server

今回の発表の真骨頂は、「Remote Terraform MCP Server」 との連動です。Model Context Protocol（MCP）に対応したことで、Claude Code や Cursor などの AI コーディングエージェントが HCP Terraform と直接対話できるようになりました。

「AI に HCL を書かせてはいけない」

AI に自然言語で「開発用 DB を立ち上げて」と頼み、ゼロから Terraform コードを書かせると、社内ルールから外れた勝手なネットワークを作ってしまったり、実在しないモジュールをでっち上げたりするリスク（ハルシネーションやサプライチェーン汚染）が伴います。

AI は「カタログ注文フォームを埋めるだけ」

TDP がある環境では、MCP Server を介して AI の振る舞いが根本から変わります。

Plaintext

[開発者]「このアプリに Cloud SQL を追加しておいて」
   ↓ (チャットで指示)
[AI エージェント]
   ↓ 1. Remote MCP Server 経由で TDP のカタログを検索
   ↓ 2. 承認済みの「Cloud SQL Add-on」を発見
   ↓ 3. サイズ等のパラメータを自動推論し、注文 API を送信
[HCP Terraform]
   ↓ 4. 専用 Workspace が自動生成され、No-Code で安全にデプロイ
   ↓ 5. (万が一パラメータが不正なら Terraform Policy が自動遮断！)
[完了] 承認済み構成の DB が安全に払い出される

AI はコードを 1 行も書きません。「インフラチームが承認したカタログから適切な Add-on を選び、フォームを埋めて送信するだけ」 に徹します。 万が一 AI が誤ったスペックを指定しても、Plan 時に Terraform Policy が自動でブロックします。

まとめ：チケット起票のないセルフサービス運用へ

Terraform Developer Portal は、ゼロから作られた単体的新機能というわけではなく、「Private Registry」「No-Code Provisioning」「Actions」「Policy」「MCP」という手持ちの強力なピースを組み上げ、アプリ開発者と AI エージェントの双方にとって最も使いやすい形へと進化させた機能 です。

インフラチームは単調な申請処理やレビュー差し戻しから解放され、開発者はインフラの待ち時間がゼロになり、AI には安全なガードレールが敷かれます。

まずは社内でよく使われる構成をシンプルな単一モジュールとして Registry に整えるところから、セルフサービス化への準備を始めてみてはいかがでしょうか。

「にこぷす通信」について

「NIC × Ops（にこぷす）通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana（可観測性）をはじめ、Turbonomic（リソース最適化）やTerraform（インフラ自動化）など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。 次回の連載もお楽しみに！