目次
- はじめに:インフラ構築の課題とYAMLドリブン化の狙い
- IBM Bob との対話UIとアーキテクチャプラン策定
- プロジェクト構成と YAML ドリブン化の実装
- ローカル開発環境と自動品質チェックについて
- 徹底比較:「コード完結型」vs「YAMLドリブン型」のメリット・デメリットと最適ユースケース
- 通常の開発・運用フロー(3ステップ)
- まとめ
皆さま、こんにちは!
このテックブログでは、IT運用に関する内容を連載、「にこぷす通信」をお届けしています。
「NIC x Ops(にこぷす)」とは?
『NIC x Ops(にこぷす)』とは、
私たちの会社であるNTTインテグレーション(NI+C)の運用ノウハウと、
IBMさんの強力なソリューションを
Collaboration(コラボレーション)させた、IT運用高度化シリーズ(Ops)のニックネームなんです。
現代のIT運用の現場は、システムの複雑化や人手不足など、課題が山積みです。そんな現場を少しでも楽に、そしてエンジニアの皆さんが笑顔で「攻めの運用」ができるように支えたい。そんな想いがこの「にこぷす」には込められています。
「にこぷす」には、Instana(可観測性)のほかにも、Turbonomic(リソース最適化)やTerraform(インフラ自動化)など、IT運用を劇的に変える製品がたくさんあります。
これからもこの通信を通して、「IT用語は難しいけれど、中身を知ればこんなに便利で面白いんだ!」というテクニカルな内容をご紹介していきますので、どうぞよろしくお願いします。
1.はじめに:インフラ構築の課題とYAMLドリブン化の狙い
Terraformを用いたクラウドインフラのコード化(IaC)が進む一方で、リソースを追加・変更するたびに複雑なHCL(.tf)コードや変数を直接修正するのは、コードの可読性低下や手動ミスの原因となりがちです。
📌
本記事での前提条件
動的プロビジョニングの手法にはいくつかの選択肢がありますが、今回は「コード完結型 動的作成」ではなく「YAMLドリブン 動的作成」で構築してみました。それぞれの比較や使い分けについては後述のセクションで詳しく解説します。
❌
従来のインフラ変更(BEFORE)
-
•
複雑な
.tf ファイルを直接手作業で編集
-
•
HCL構文ミスやリスト・マップの指定漏れが発生しやすい
-
•
HCP Terraformの Variables(HCL型)の手動編集が必要
✨
本手法のYAMLドリブン(AFTER)
-
•
直感的な
config/*.yaml を書き換えるだけ
-
•
HCLコードに触れずにVM/DBを動的プロビジョニング
-
•
git push でクラウドへ安全に完全自動デプロイ
本記事(連載第3弾)では、自律型AIエージェント「IBM Bob」との対話を通して設計・構築した、GCP(GCE/Cloud SQL/VPC)リソースの動的一元デプロイの仕組みについて詳しく解説します。
💡連載シリーズについて
本シリーズ(全3回)では、この強力な連携による開発効率化を順を追って解説します。
2.IBM Bob との対話UIとアーキテクチャプラン策定
開発の第一歩として、人間が直接設計を行うのではなく、自律型AI「IBM Bob」にファーストプロンプトとしてゴールを投げかける形でスタートしました。
ユーザー(インフラ担当)
「YAML ファイルを活用した動的複数リソース作成手法の確立をしたいです。何をすべきですか?」
IBM Bob
要件を明確にするため、現在の技術スタックと既存コード(main.tf やモジュール類)を共有いただけますか?構成を確認した上で最適プランを作成します。
今回は元々、HCL内で変数を駆使してリソースを量産する「コード完結型」で全体の構成コードを作成していました。この既存コードの解析完了後、IBM Bobから3つのアプローチが提示され、最もシンプルで既存のモジュールコード(modules/gce , modules/sql)を変更せずに流用できる「yamldecode + file()」を採用しました。
1
YAML 設定ファイルの作成:
config/gce.yaml、config/sql.yaml を新規配置
2
locals.tf の作成:
yamldecode(file(...)) でYAML設定を読み込む構成を追加
3
main.tf の参照変更: モジュール呼び出しの参照先を
var.* から local.* へ切替
4
variables.tf から不要変数を削除:
env_instances、env_sql_instances を除去
5
動作検証: Agentモードへ切り替えて構文検証・自動実行
3.プロジェクト構成と YAML ドリブン化の実装
前セクションで策定したプランをもとに、IBM Bobとわずか数回のやり取りを交わすだけで、プロジェクト構成とコアコードがあっという間に仕上がりました
今回の構成では、インフラの定義情報をすべて config/ ディレクトリ配下の YAML ファイルに集約しています。HCLコード(.tf)は「YAMLを読み込んでリソースを展開するエンジン」として分離されているため、今後のリソース追加やスペック変更で .tf ファイルを直接編集する必要は一切ありません。
📁 プロジェクトのディレクトリ構成
.
├── config/ # 👈 パラメータ設定領域(運用者が操作)
│ ├── common.yaml # VPCネットワークやGCE共通設定
│ ├── gce.yaml # Compute Engine インスタンス定義
│ └── sql.yaml # Cloud SQL インスタンス定義
│
├── modules/ # 👈 再利用可能なリソースモジュール群
│ ├── gce/ # GCEプロビジョニングモジュール
│ │ ├── main.tf # └ VM/追加ディスクの動的生成ロジック
│ │ └── variables.tf # └ 型定義とoptionalデフォルト値
│ └── sql/ # Cloud SQLプロビジョニングモジュール
│ ├── main.tf # └ DBインスタンスの動的生成ロジック
│ └── variables.tf # └ 型定義とoptionalデフォルト値
│
├── locals.tf # yamldecode() によるYAML読み込み処理
├── main.tf # VPC構築 & 各モジュールへのバケツリレー
├── variables.tf # HCP TFからの最小限の注入変数定義
└── versions.tf # Provider・Terraformバージョン固定
💡
実装における3つの重要ポイント
-
設定とロジックの完全分離:
locals.tf で yamldecode(file(...)) を実行し、YAML文字列をHCLのマップ構造へシームレスにパースしています。
-
バケツリレーによるモジュール呼び出し:
ルートの
main.tf から子モジュール(modules/gce や modules/sql)へ解析済みのオブジェクト型変数を渡す設計を採用しています。
-
デフォルト値の自動補完:
子モジュールの
variables.tf で optional() 構文を活用し、YAML側で一部パラメータ(ディスク種別や削除保護等)が省略された場合でも安全にデフォルト値を適用します。
🔄
YAMLデータ処理の仕組み
config/gce.yaml (設定値)
⬇️
locals.tf 内の yamldecode(file(...)) で読み込み
⬇️
main.tf から local.gce_config をモジュールへ渡す
⬇️
既存の modules/gce 内の for_each で複数リソースが動的生成される
以下に、本検証で実際に使用したTerraformコードおよびYAML設定ファイルの全容(完全版ソースコード)を掲載します。
本構成ではプロビジョニングロジック(HCL)と設定値(YAML)が完全に分離されているため、実際の運用で触るのは config/ 配下のファイルのみとなります。各アコーディオンを展開してコードの全容を確認・コピーできますので、手元での検証やテンプレート作成の際にご活用ください。
📄 locals.tf (YAML設定読み込み・変換処理)
################################################################################
# File: locals.tf
# Project: GCE / SQL Infrastructure
# Description: YAML 設定ファイルを読み込み、Terraform の locals として展開する
# Dependency: config/common.yaml, config/gce.yaml, config/sql.yaml
################################################################################
# このファイルは config/ ディレクトリ配下の YAML ファイルを yamldecode() で読み込み、
# main.tf のモジュール呼び出し時に参照できる local 変数として定義します。
#
# リソースの追加・変更・削除はすべて config/*.yaml の編集のみで完結します。
# このファイル自体を変更する必要はありません。
locals {
# --------------------------------------------------------------------------
# 共通設定の読み込み
# --------------------------------------------------------------------------
# config/common.yaml を読み込み、VPC・GCE 共通設定を local として展開します。
# main.tf の google_compute_network および module "gce_cluster" で参照されます。
common_config = yamldecode(file("${path.module}/config/common.yaml"))
# --------------------------------------------------------------------------
# GCE インスタンス設定の読み込み
# --------------------------------------------------------------------------
# config/gce.yaml を文字列として読み込み、HCL の map(object) 型に変換します。
# main.tf の module "gce_cluster" に env_instances として渡されます。
gce_config = yamldecode(file("${path.module}/config/gce.yaml"))
# --------------------------------------------------------------------------
# Cloud SQL インスタンス設定の読み込み
# --------------------------------------------------------------------------
# config/sql.yaml を文字列として読み込み、HCL の map(object) 型に変換します。
# main.tf の module "sql_cluster" に env_sql_instances として渡されます。
sql_config = yamldecode(file("${path.module}/config/sql.yaml"))
}
📄 main.tf (VPC定義・各モジュール呼び出し)
# ==============================================================================
# ルートメイン構成ファイル (main.tf)
# ==============================================================================
# このファイルは、プロジェクト全体のネットワーク基盤を定義しつつ、
# 各カプセル化モジュールへと必要なリソース情報を受け渡す役割を担います。
# ------------------------------------------------------------------------------
# 1. 共有カスタムVPCネットワークの定義
# ------------------------------------------------------------------------------
resource "google_compute_network" "custom_vpc" {
name = local.common_config.vpc.name
auto_create_subnetworks = local.common_config.vpc.auto_create_subnetworks
project = var.gcp_project_id
}
# ------------------------------------------------------------------------------
# 2. GCE(仮想マシン)モジュールの呼び出し
# ------------------------------------------------------------------------------
module "gce_cluster" {
source = "./modules/gce"
project_id = var.gcp_project_id
env_instances = local.gce_config
network_name = google_compute_network.custom_vpc.name
allow_stopping_for_update = local.common_config.gce.allow_stopping_for_update
}
# ------------------------------------------------------------------------------
# 3. Cloud SQLモジュールの呼び出し
# ------------------------------------------------------------------------------
module "sql_cluster" {
source = "./modules/sql"
project_id = var.gcp_project_id
region = var.gcp_region
env_sql_instances = local.sql_config
}
📄 variables.tf (HCP TF最小注入変数)
################################################################################
# File: variables.tf
# Project: GCE Infrastructure
# Description: Global input variables for the environment
# Dependency: None
# Compliance: Standard Conventions 2.2 / 4.2
################################################################################
# このファイルでは、HCP Terraform から注入が必要な変数のみを定義します。
# それ以外の設定値は config/*.yaml で管理します。
# ------------------------------------------------------------------------------
# 1. GCP 接続用の基本変数定義(HCP Terraform Variables で管理)
# ------------------------------------------------------------------------------
variable "gcp_project_id" {
type = string
description = "構築対象となる GCP プロジェクトID。HCP TF上の Variables(String形式)で指定します。"
}
variable "gcp_region" {
type = string
default = "asia-northeast1"
description = "デフォルトで使用するリージョン。指定がない場合は東京リージョン(asia-northeast1)が自動選択されます。"
}
# ------------------------------------------------------------------------------
# ※ 削除済み変数について
# ------------------------------------------------------------------------------
# 以下の変数は YAML ドリブン化対応により削除しました。
# リソース設定は config/*.yaml を直接編集して管理してください。
#
# - variable "env_instances" → config/gce.yaml で管理
# - variable "env_sql_instances" → config/sql.yaml で管理
# - variable "custom_vpc_name" → config/common.yaml(vpc.name)で管理
# - variable "auto_create_subnetworks"→ config/common.yaml(vpc.auto_create_subnetworks)で管理
# - variable "allow_stopping_for_update" → config/common.yaml(gce.allow_stopping_for_update)で管理
#
# HCP Terraform の Variables 画面からも同名の変数を手動削除してください。
# ------------------------------------------------------------------------------
📄 versions.tf (Terraform/Provider バージョン定義)
################################################################################
# File: versions.tf
# Project: GCE Infrastructure
# Description: Terraform and Google Provider pinning
# Dependency: None
# Compliance: Standard Conventions 1.1
################################################################################
terraform {
# ----------------------------------------------------------------------------
# 1. Terraform 本体のバージョン制約
# ----------------------------------------------------------------------------
# オブジェクト型変数内でデフォルト値を定義できる `optional()` 構文を利用するため、
# Terraform v1.3.0 以上の実行環境を必須要件として定義しています。
required_version = ">= 1.3.0"
# ----------------------------------------------------------------------------
# 2. 使用するプロバイダー(外部API連携用プラグイン)の定義
# ----------------------------------------------------------------------------
# 本プロジェクトで Google Cloud Platform (GCP) のリソースを管理するため、
# HashiCorp社が提供・管理する公式の「google」プロバイダーを宣言します。
required_providers {
google = {
source = "hashicorp/google"
# state を作成した v6.x 系以上を使用するよう制約を更新しています。
version = ">= 6.0"
}
}
}
# ------------------------------------------------------------------------------
# 3. Google Cloud プロバイダーの接続設定
# ------------------------------------------------------------------------------
# 実際に GCP API と通信してリソースを操作するための認証と共通設定を行います。
# ここで使用されている `var.gcp_project_id` や `var.gcp_region` は、
# `variables.tf` で宣言され、HCP Terraform から動的に値が注入されます。
provider "google" {
project = var.gcp_project_id # 構築対象となるGCPプロジェクトのID
region = var.gcp_region # デフォルトのリージョン(例: asia-northeast1)
}
📄 config/common.yaml (VPC・GCE共通設定)
################################################################################
# File: config/common.yaml
# Project: GCE / SQL Infrastructure
# Description: インフラ全体の共通設定 YAML 定義ファイル
# VPC・GCE 共通オプションをここで一元管理します。
# このファイルを編集するだけで設定変更が可能です。
################################################################################
# ------------------------------------------------------------------------------
# VPC ネットワーク設定
# ------------------------------------------------------------------------------
vpc:
# カスタムVPCネットワークの名称(google_compute_network の name に対応)
name: custom-vpc-network
# サブネットをリージョンごとに自動作成するかどうか(true / false)
auto_create_subnetworks: true
# ------------------------------------------------------------------------------
# GCE 共通設定
# ------------------------------------------------------------------------------
gce:
# GCEインスタンスのマシンタイプ変更時に自動停止・再起動を許可するかどうか(true / false)
# true = 変更時に自動停止(推奨)
# false = 手動停止が必要
allow_stopping_for_update: true
📄 config/gce.yaml (GCEインスタンス動的定義)
################################################################################
# File: config/gce.yaml
# Project: GCE Infrastructure
# Description: GCE インスタンス設定の YAML 定義ファイル
# このファイルを編集するだけで GCE インスタンスの追加・変更・削除が可能です。
# キー名がそのままインスタンス名になります。
################################################################################
# ------------------------------------------------------------------------------
# 記述ルール
# ------------------------------------------------------------------------------
# <インスタンス名>: ← Terraform リソースのキー(= GCE インスタンス名)
# machine_type: <マシンタイプ> ← 必須(例: e2-small, e2-medium, n1-standard-2)
# zone: <ゾーン> ← 必須(例: asia-northeast1-a)
# disks: ← 省略可(省略時は追加ディスクなし)
# - name: <ディスク識別名>
# size_gb: <容量(GB)>
# type: <ディスク種別> ← 省略可(省略時: pd-standard)
# ------------------------------------------------------------------------------
web-server:
machine_type: e2-small
zone: asia-northeast1-a
# disks は省略(追加ディスクなし)
app-server:
machine_type: e2-medium
zone: asia-northeast1-b
# disks は省略(追加ディスクなし)
db-server:
machine_type: e2-medium
zone: asia-northeast1-c
disks:
- name: data-disk
size_gb: 100
type: pd-standard
- name: backup-disk
size_gb: 50
# type は省略(デフォルト: pd-standard が適用されます)
db-server2:
machine_type: e2-small
zone: asia-northeast1-a
disks:
- name: data-disk
size_gb: 100
type: pd-standard
- name: backup-disk
size_gb: 50
📄 config/sql.yaml (Cloud SQL動的定義)
################################################################################
# File: config/sql.yaml
# Project: SQL Infrastructure
# Description: Cloud SQL インスタンス設定の YAML 定義ファイル
# このファイルを編集するだけで Cloud SQL インスタンスの追加・変更・削除が可能です。
# キー名がそのままインスタンス名になります。
################################################################################
# ------------------------------------------------------------------------------
# 記述ルール
# ------------------------------------------------------------------------------
# <インスタンス名>: ← Terraform リソースのキー(= Cloud SQL インスタンス名)
# database_version: <エンジン+バージョン> ← 必須(例: POSTGRES_15, MYSQL_8_0)
# tier: <マシンスペック> ← 必須(例: db-f1-micro, db-custom-2-7680)
# availability_type: <可用性タイプ> ← 省略可(省略時: ZONAL)REGIONAL or ZONAL
# deletion_protection: <bool> ← 省略可(省略時: true)本番は true 推奨
# disk_size: <容量(GB)> ← 省略可(省略時: 10)
# ------------------------------------------------------------------------------
prod-db-main2:
database_version: POSTGRES_15
tier: db-custom-2-7680
availability_type: REGIONAL
deletion_protection: true
disk_size: 50
dev-db:
database_version: MYSQL_8_0
tier: db-f1-micro
availability_type: ZONAL
deletion_protection: false
disk_size: 10
📄 modules/gce/main.tf (GCEモジュールメイン定義)
# ==============================================================================
# GCE(仮想マシン)モジュールメイン定義ファイル (modules/gce/main.tf)
# ==============================================================================
# ------------------------------------------------------------------------------
# 1. 各VMのメインインスタンス定義
# ------------------------------------------------------------------------------
resource "google_compute_instance" "vm" {
for_each = var.env_instances
name = each.key
machine_type = each.value.machine_type
zone = each.value.zone
allow_stopping_for_update = var.allow_stopping_for_update # 修正:固定値から変数参照へ変更
project = var.project_id
boot_disk {
initialize_params {
image = "debian-cloud/debian-11"
}
}
network_interface {
network = var.network_name
access_config {}
}
lifecycle {
ignore_changes = [boot_disk[0].initialize_params[0].image]
}
}
# 2. 追加ディスクがある場合の処理(ディスク自体の作成)
locals {
additional_disks = merge([
for vm_key, vm_val in var.env_instances : {
for disk in vm_val.disks :
"${vm_key}-${disk.name}" => {
vm_key = vm_key
zone = vm_val.zone
name = disk.name
size_gb = disk.size_gb
type = disk.type
}
}
]...)
}
resource "google_compute_disk" "disk" {
for_each = local.additional_disks
name = each.key
type = each.value.type
zone = each.value.zone
size = each.value.size_gb
project = var.project_id
}
# 3. ディスクとVMのバインディング(接続)
resource "google_compute_attached_disk" "attach" {
for_each = local.additional_disks
instance = google_compute_instance.vm[each.value.vm_key].id
disk = google_compute_disk.disk[each.key].id
device_name = each.value.name
project = var.project_id
}
📄 modules/gce/variables.tf (GCEモジュール変数定義)
# ==============================================================================
# GCE(仮想マシン)モジュール用 変数定義ファイル (modules/gce/variables.tf)
# ==============================================================================
variable "project_id" {
type = string
description = "リソースをデプロイする対象のGCPプロジェクトID"
}
# ------------------------------------------------------------------------------
# 追加:ネットワーク接続用変数
# ------------------------------------------------------------------------------
# ルートモジュール(直下の main.tf)で定義されたカスタムVPCの名前を
# 子モジュール側で安全に受け取るための入力インターフェース変数です。
variable "network_name" {
type = string
description = "VMインスタンスが接続されるVPCネットワークの名前"
}
# ------------------------------------------------------------------------------
# GCEインスタンス設定マップ
# ------------------------------------------------------------------------------
# 追加:ルートモジュールから引き渡される設定値の受け皿
variable "allow_stopping_for_update" {
type = bool
description = "GCEインスタンス変更時に自動停止・再起動を許可するかどうか"
}
variable "env_instances" {
type = map(object({
machine_type = string
zone = string
disks = optional(list(object({
name = string
size_gb = number
type = optional(string, "pd-standard")
})), [])
}))
}
📄 modules/sql/main.tf (Cloud SQLモジュールメイン定義)
################################################################################
# File: modules/sql/main.tf
# Project: SQL Infrastructure
# Description: Definition of SQL instance with auto-lowercased names and labels
# Dependency: None
# Compliance: Standard Conventions 5.2 (CIS v8 Alignment) / 5.3
################################################################################
# このファイルでは、ルートモジュールからバケツリレーされた `env_sql_instances` 変数を使い、
# `for_each` 構文を用いて複数の Cloud SQL インスタンスを動的に作成します。
# ------------------------------------------------------------------------------
# 1. プライベートネットワーク (VPC) の定義
# ------------------------------------------------------------------------------
resource "google_compute_network" "private_network" {
name = "sql-vpc-network"
auto_create_subnetworks = true
project = var.project_id # 追加:project を明示指定
}
# ------------------------------------------------------------------------------
# 2. Cloud SQL データベースインスタンスの動的作成
# ------------------------------------------------------------------------------
resource "google_sql_database_instance" "db" {
for_each = var.env_sql_instances
name = each.key
database_version = each.value.database_version
deletion_protection = each.value.deletion_protection
project = var.project_id
region = var.region
settings {
tier = each.value.tier
availability_type = each.value.availability_type
disk_size = each.value.disk_size
ip_configuration {
ipv4_enabled = true
}
}
}
📄 modules/sql/variables.tf (Cloud SQLモジュール変数定義)
################################################################################
# File: modules/sql/variables.tf
# Project: SQL Infrastructure
# Description: Module input definitions with strict validation
# Dependency: None
# Compliance: Standard Conventions 4.2
################################################################################
# このファイルでは、Cloud SQL インスタンスを動的に複数作成するために
# 必要となる設定情報のマップ(変数の構造型)を定義します。
# ルートモジュールからバケツリレーされてきた設定データを受け取る口になります。
# ------------------------------------------------------------------------------
# 追加:GCP プロジェクト ID
# ------------------------------------------------------------------------------
# ルートモジュールから project_id を受け取り、モジュール内リソースの project に渡します。
variable "project_id" {
type = string
description = "リソースをデプロイする対象の GCP プロジェクト ID"
}
variable "region" {
type = string
description = "リソースをデプロイする対象のリージョン"
}
variable "env_sql_instances" {
type = map(object({
# --------------------------------------------------------------------------
# 必須パラメータ(各インスタンスで必ず指定が必要な項目)
# --------------------------------------------------------------------------
database_version = string # データベースエンジン名とバージョン(例: "POSTGRES_15"、"MYSQL_8_0")
tier = string # インスタンスのマシンスペック・サイズ(例: "db-f1-micro"、"db-custom-2-7680")
# --------------------------------------------------------------------------
# オプションパラメータ(省略時は optional の第2引数で定義されたデフォルト値が適用されます)
# --------------------------------------------------------------------------
# ① 可用性の配置オプション
availability_type = optional(string, "ZONAL")
# ② 削除保護の設定
deletion_protection = optional(bool, true)
# ③ 初期ディスク容量(GB単位)
disk_size = optional(number, 10)
}))
description = "動的に作成する Cloud SQL インスタンス群の設定情報。config/sql.yaml から読み込まれます。"
}
4.ローカル開発環境と自動品質チェックについて
本筋のIaC構築から少し脱線しますが、「日々の開発環境を快適・安全に保つための仕組み」も裏側で整えていました。そちらについても少しご紹介します。
ローカル開発環境を一括で準備するPowerShellスクリプト(setup.ps1)や、コミット時に自動実行される静的解析・ドキュメント挿入(pre-commit × IBM Bob)の詳細については、第2回「環境構築編」で詳しく解説しています。
実践・品質管理
Terraform
【NIC x Ops(にこぷす)通信】(Terraform編)環境構築スクリプト(setup.ps1)と pre-commit × AI自律化で実現するコード品質管理ガイド
Terraform開発の環境差異やチェック漏れを解決!Windows用自動構築スクリプト(setup.ps1)の作成手順と、pre-commit×AIによる品質管理・検証結果を解説します。
5.徹底比較:「コード完結型」vs「YAMLドリブン型」のメリット・デメリットと最適ユースケース
今回は「YAMLドリブン 動的作成」で構築しましたが、インフラの動的作成手法には「コード(HCL)のみで完結させる手法」も存在します。それぞれの特徴、メリット・デメリット、適したユースケースを整理してみました。
| 評価項目 |
① コード完結型 動的作成 |
② YAMLドリブン 動的作成(★今回の手法) |
| 概要 |
HCL内で for_each やローカル変数を駆使して直接リソースを量産
|
設定パラメータを外部YAMLに集約し yamldecode で動的展開
|
| 可読性・保守性 |
〇 標準作法に従えば把握しやすいが、リソース増でコードが肥大化しやすい
|
◎ 設定値の視認性は最高。一方、コード側のパース処理保守難易度は上昇
|
| 運用の容易性 |
△ HCL文法の理解が必要なため、非インフラエンジニアの修正ハードルが高い
|
◎ コピー&ペーストで値を変えるだけ。開発者へのセルフサービス化に最適
|
| 拡張性・柔軟性 |
〇 条件分岐や複雑なリソース間依存の制御がスムーズに行える
|
〇 特殊パターンの追加時にYAMLスキーマとコード両方の修正が必要
|
| 安全性・検証 |
◎ validation 機能で型や制約の厳密な静的チェックが可能
|
⚠️ 注意 インデントミス等の実行時エラーに備えCIでの検証が不可欠
|
📊
総合評価マトリクス
インフラ/設定分離
コード: ×
YAML: 完全分離
エラー検知性
コード: 静的解析が容易
YAML: △ 実行時に検知
💡
「① コード完結型」が適しているケース
適しているシステム特性:
- 構成変更の頻度が低く、初期構築がメイン
- リソース構成が毎回大きく異なり個別最適化が多い
- トラブルシューティングとコード追跡性を最優先
適している組織・お客様:
- インフラ専任の強力なSRE・プラットフォームチームが存在する企業
- 受託開発中心のSIer(個別要件への柔軟対応が必要)
- 小〜中規模の自社サービス運用企業
💡
「② YAMLドリブン型」が適しているケース
適しているシステム特性:
- マルチテナント環境の「定型量産」が発生する
- Dev/Stg/Prodでパラメータのみ異なり構成は共通
- アプリ開発者によるセルフサービスでのリソース追加・変更要件がある(GitOps)
適している組織・お客様:
-
SaaSプロバイダー・B2Bサービス企業(最も推奨)
- Platform Engineeringを推進する大規模エンタープライズ
- インフラ専任者が不足しているスタートアップ
📌
結論と選定のポイント
どちらの手法を採用すべきかは、「今後の運用フェーズで、誰が、どのようなビジネススピードでリソースを操作するか」が決定打となります。 SaaS展開での定型量産やセルフサービス化を目指す場合は今回構築した「② YAMLドリブン型」が強力な武器となり、個別要件が多くインフラチームが統制したい場合は堅牢な「① コード完結型」が最適です。
6.通常の開発・運用フロー(3ステップ)
一度仕組みを構築した後は、開発・運用担当者が行う作業は「YAMLの変更」と「Gitの操作」のみです。
STEP 01
YAMLを編集
config/*.yaml にパラメータを追加・修正します。
STEP 02
Git Push
git commit ➔ git push で変更を反映します。
STEP 03
自動プロビジョニング
HCP TFが検知し、GCPへ安全に自動デプロイ完了。
🔍
Speculative Plan(マージ前事前検証)
GitHubで Pull Request(PR)を作成すると、HCP Terraform がマージ前に自動で影響範囲を計算し、PRコメント欄に変更予定の差分を出力します。レビュー担当者は「YAMLの変更がインフラに与える影響」を正確に把握した上で安心してマージできます。
7.まとめ
本記事では、自律型AI「IBM Bob」への相談から始まった「YAMLドリブンな動的リソース作成手法」の設計・構築と、HCP Terraform連携による自律デプロイを検証しました。
🎉
本手法によって実現した自動化の成果
-
AI主導の計画策定:要件を伝えるだけで、IBM Bobが対話形式で最適な構成提案からコード生成までを完結。
-
安全で直感的な管理:YAMLファイルのみでインフラを追加・管理でき、Terraform構文エラーや事故を防止。
-
HCLから直感的なYAMLへのスムーズな移行:元々インフラ目線で書かれた複雑なHCLコードから、開発者でも直感的に扱いやすいYAMLコードへの変換が、AIの力で簡単に実現。
全3回の連載を通して、AIエージェント「IBM Bob」とTerraformを組み合わせた次世代IaC開発手法の有用性を実証しました。チームの開発自動化や品質維持の参考になれば幸いです!
「にこぷす通信」について
「NIC × Ops(にこぷす)通信」は、隔週で皆さまに情報をお届けします。
このシリーズでは、Instana(可観測性)をはじめ、Turbonomic(リソース最適化)やTerraform(インフラ自動化)など、IT運用を劇的に変える製品をピックアップしていきます。
これからも最新の技術検証をチームで継続し、皆さまの現場ですぐに役立つ「有益な知見」を全力で共有していきます。 次回の連載もお楽しみに!