---
title: ぼくの考えた最強のIaC
tags: 
author: [M.Nishimura](https://docswell.com/user/Otazoman)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/GJWGD2KM72.jpg?width=480
description: IaCに関しての体験談語りました
published: March 27, 26
canonical: https://docswell.com/s/Otazoman/KJWL6N-2026-03-24-124301
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/GJWGD2KM72.jpg)

ぼくの考えた最強のIaC
2026/3/27


# Page. 2

![Page Image](https://bcdn.docswell.com/page/4EZLGDZM73.jpg)

お前誰だよ
Otazoman
X:うひーマン(@norikoni)
1975年生まれ
がっつり氷河期世代の文系卒です
妙なこだわりですが、理系の修士卒ではなくエンジニアの
定義から外れていて、おこがましくてエンジニアは名乗れ
ないです。
AWSのインフラ構築メインにT社様案件に関わってました。
ダメダメなインフラおじさんです(本日最終出社ですw)。
趣味：惰眠をむさぼること


# Page. 3

![Page Image](https://bcdn.docswell.com/page/Y76WY1Z57V.jpg)

■本日お話しすること
自分で体験したIaCの話(あまり役に立たない)
■本日お話しないこと
IaCベストプラクティスとか最先端ななんか役に立ちそうなこと


# Page. 4

![Page Image](https://bcdn.docswell.com/page/G75MG4WG74.jpg)

皆さん、クラウドでのインフラ設定ってどうしてますか？


# Page. 5

![Page Image](https://bcdn.docswell.com/page/9J29YVQDER.jpg)

当然、GUIっすか・・・(石器時代)
GUIでちまちま操作して設定
・手順書見ながら操作
・GUI変わったら泣きそう


# Page. 6

![Page Image](https://bcdn.docswell.com/page/DEY4G3WMJM.jpg)

まぁCLIっしょ(土器時代)
CLIで操作して設定
・コマンドライン操作
・イケてる感じ醸し出せる


# Page. 7

![Page Image](https://bcdn.docswell.com/page/VJNYGV9378.jpg)

いやいやShell芸っすよ(鉄器時代)
ShellでCLIを組み合わせる
・コマンド一撃でリソース作成
・CSV定義の設定ファイル外出しも可能


# Page. 8

![Page Image](https://bcdn.docswell.com/page/YE9PW62PJ3.jpg)

今までのやりかたまとめ
GUI操作
CLI操作
Shell芸
メリット
・操作が簡単
・習得が早い
・追加リソース不要
・詳細設定が簡単
・再現性あり
・デバッグできる
・条件分岐できる
・複数リソース作成時に強み
・マルチクラウドも構築可能
デメリット
・詳細設定が煩雑
・誤操作による設定ミス
・デバッグできない
・コマンド理解が必要
・学習コストがかかる
・大規模環境には不向き
・属人性が強くなりがち
・追加環境とShellが必要
・複雑性が増す
評価
素人みたいにみられる
ややかっこよく見える
職人みたくみられる
Shell芸最強


# Page. 9

![Page Image](https://bcdn.docswell.com/page/GE8DNZ5XED.jpg)

今までのやり方の問題点
●UI変わったら手順書作り直し発生
●手で設定したらミスがついて回る
●コマンドだけ見ても何してるか判別しにくい
●なんでShell？ってDisられる
モダンではないので、巷のキラキラエンジニアの受けが悪い


# Page. 10

![Page Image](https://bcdn.docswell.com/page/LELMPDYN7R.jpg)

そこで救世主IaCの登場


# Page. 11

![Page Image](https://bcdn.docswell.com/page/4JMY4PNQJW.jpg)

IaCって何それおいしいの？
IaCとは
Infrastructure as Code（IaC） はコンピューティング・インフラ（プロセス、ベアメタ
ルサーバー、仮想サーバーなど）の構成管理・機械処理可能な定義ファイルの設定・プ
ロビジョニングを自動化するプロセスである。定義されたファイルはバージョン管理シ
ステムで保持することもある。従来、手動のプロセスではなくスクリプトや宣言的な定
義によって行われていたが、IaCの開発は今では、宣言的なアプローチに焦点が当てられ
ている[1]。
WikiPedia
より
転載
WikiPediaより転載
コードにインフラの構成記述しとけば、それを元に設定できる。
コード変更すればインフラの構成も変更できる。
コマンド一発滅びの呪文を使える。


# Page. 12

![Page Image](https://bcdn.docswell.com/page/PJR9W1DK79.jpg)

導入すればモダンなインフラ環境が実現できます
クラウドリソースをコードで管理
GitHubへのPushをトリガーにCI/CD
CI/CD
パイプライン
コードを修正しGitHubへPush
インフラ自動構築


# Page. 13

![Page Image](https://bcdn.docswell.com/page/PEXQPY15JX.jpg)

ちょっとだけIaCの説明


# Page. 14

![Page Image](https://bcdn.docswell.com/page/3EK9D32RED.jpg)

IaCの種類
宣言型
中間型
プログラミング型
YAMLとかJSONとかで設定内容を
記述してコマンドラインでテンプ
レートファイルを読み込んでリ
ソースを構築する.
テンプレートファイルを修正して
流しなおせば構成の変更も可能
専用ツールをインストールし、
DSL(ドメイン固有言語)でインフ
ラのリソースを記述してDeployし
てインフラを構築する。一応、繰
り返しや条件分岐できる。
プログラミング言語を使用して、
リソースをプログラムの様に記述
できる。内部で宣言型とか中間型
のスタックに置き換える形式のも
のが多い。
対応言語は
TypeScript/Python/C#/Javaの
ケースが大半だが専用ツールの
installがnpmってケースが多く、
TypeScriptが中心で他の言語使っ
てる事例は少ない。
・AWS Cloud Formation
・Azure ARM Template
・Google Deployment Manager
・ちょっと特殊
・Crossplane
・Ansible
・Terraform
・Open Tofu
・Azure Bicep
・AWS CDK
・CDK for Terraform(CDKTF)
・Plumi


# Page. 15

![Page Image](https://bcdn.docswell.com/page/L73WRG4G75.jpg)

宣言型
AWS Cloud Formation
・スタック単位でリソースを管理して、よしなにしてくれる
・テンプレートはYAMLもしくはJSONで記述
・AWS CloudFormation デザイナーでグラフィカルに管理できる
・SAMとかServerless Framework、AWS-CDKも行きつく先はコレ
Azure ARM Template
・リソースをグループ単位で管理して、よしなにしてくれる
・テンプレートはJSONで記述する
・手動作成したリソースからテンプレート出力できる
Google Deployment manager
・リソース単位でテンプレートファイルを記述する
・JSON, YAML, Python, Jinja2というフォーマットで柔軟な管理ができる
・2026年3月末でサービス終了、もはや使う理由はない
(ファイル分割とかきれいにできたので結構好きだったが残念)


# Page. 16

![Page Image](https://bcdn.docswell.com/page/87DKY1QNJG.jpg)

中間型
Terraform
・Hashi Corp製(IBMに買収されちゃった)、IaC界隈で圧倒的なシェア(62%)
・幅広いサービスを統一した形式(HCL)で記述できる
・条件分岐とか繰り返しとかいろいろできるけどトリッキーになる
Open Tofu
・Terraformのライセンス変更によってフォークしたOSS
・Terraformとほぼ同じ特徴、利用者そんなに多くない
・バージョンが進むとterraform互換が怪しくなりそう
Azure Bicep
・記述方法はTerraformに似てる
・Azureのリソースしか作成できない
・なんか色々とイケてなく見えてアレな感じ(MSなので・・・)


# Page. 17

![Page Image](https://bcdn.docswell.com/page/VJPK6QLNE8.jpg)

プログラミング型
AWS CDK
・AWS謹製なので当然、AWSのみでしか使用できない
・結構、頻繁に更新されている
・L3コンストラクタを使えば少ない記述量でリソースを表現できる
CDK for Terraform (CDKTF)
・Hashi Corp製のCDKでいろんなサービスで使用できるようになってる
・Terraformからインポートエクスポートできたりする
・開発止まってるけど大丈夫か(大丈夫ではなかった)
Plumi
・スタック作るタイプと違って純粋にプログラムでリソースを操作できる
・なんか巷では評価は高いみたいだが触っていないのでよくわからない
・採用が少なくマイナーすぎて知見が少ない


# Page. 18

![Page Image](https://bcdn.docswell.com/page/2EVV35QYEQ.jpg)

IaCの3タイプ比較
宣言型
中間型
プログラミング型
使用言語
JSON/YAML等
DSL
TypeScript,Python,Java,C#
学習コスト
JSON/YAMLの構文のみ。
直感的に理解しやすい。
HCL等の独自DSLの学習が必要
言語仕様 + 中間スタック仕様+ ク
ラス設計の理解が必要。
抽象化
リソース定義が冗長にな
りがち。
モジュールによる再利用が可能。ロ
ジック記述するとトリッキーになっ
て可読性が落ちる。
クラス継承、ループ、関数化によ
り高度に抽象化可能。
マルチクラウド
もともと想定されていな
い
単一ツールで多数のプロバイダを統
合管理可能。BicepはAzure特化
Pulumi、CDKTFは対応。CDKは
AWS特化
状態管理
ユーザ側で意識する必要
がない
tfstateファイルの安全な管理
（S3+Lock等）が必須。
CDKはAWS依存、それ以外はス
テートファイルの管理が必要
総評
クラウド単体なら一番簡
単に管理できる。小規模
であればこれがおススメ
ちょっと込み入った構成やマルチク
ラウド管理ならこちらがおススメ
アプリケーションと同じような感
覚で管理できる。テストとかしっ
かりやりたい場合はこちらがおス
スメ


# Page. 19

![Page Image](https://bcdn.docswell.com/page/57GL36WWEL.jpg)

そしてようやく本題


# Page. 20

![Page Image](https://bcdn.docswell.com/page/4EQY543QJP.jpg)

何がしたいのか
コンテナ+RDBMS構成でVPN接続したマルチクラウドのAPIバックエンド構成作りたい。
(現在も継続中)
Virtual private cloud (VPC)
Elastic Load Balancing
Amazon ECS
Amazon RDS
AWS Site-to-Site VPN
VNet
Virtual
NetworkGateway
Applicationg
ateway
Container
Apps
Flexible
Database
Cloud VPN
Cloud SQL
Cloud
Run
Cloud Load
Balancing


# Page. 21

![Page Image](https://bcdn.docswell.com/page/KJ4W9Q1Y71.jpg)

最初にマルチクラウドでVPN始めてみました
CLIコマンド組み合わせてVPN
接続するところからスタート
いきなりTerraformに進化


# Page. 22

![Page Image](https://bcdn.docswell.com/page/LE1YKPGN7G.jpg)

Terraformで作業しててモヤモヤ
・ベタ書き
↓
・モジュール化して分割
↓
可変値は変数化してvariables.tfに切り出し
・追加要件
・開発モードは非HAのVPN構成にしたい
・コンテナとかDBとかはフラグ制御したい
・接続するクラウドを制御したい
などなど
Terraformでやると複雑になりそう・・・
あとテスト何とかしたい
なんか管理しやすい手立てないかな


# Page. 23

![Page Image](https://bcdn.docswell.com/page/GEWGD25MJ2.jpg)

そこで採用したのが
マルチクラウド扱える!!
スナップショットテスト記述できる!!
CDK for Terraform (CDKTF)
Terraformと親和性高い!!
早速、TerraformのHCLをちまちまTypeScriptに変換


# Page. 24

![Page Image](https://bcdn.docswell.com/page/47ZLGDNMJ3.jpg)

が、現実はそう甘くない
・リソースが正しくできるかはやはり手動テストしないと不明
Constructs記述
・コンパイル通ってもリソース作ると謎のエラー
・プロパティ名がterraformと違って混乱・・・
・なんで・・・意味不明
オーケストレータ記述
・AzureのVPNリソースが作成完了までに1時間
・Azureマジでデプロイ遅い、殺意が芽生えました
スナップショットテスト
・GoogleもDestroy時に意味不明のエラー
・バグらしくIssueで上げられてるが修正見通しなし、手作業
なぜか実際にリソース作成し
てテスト
・おまけにGoogle・AzureはMySQL8.4、Postgre18まだ、未対応・・・


# Page. 25

![Page Image](https://bcdn.docswell.com/page/YJ6WY185JV.jpg)

極めつけは・・・・
・Windows UpdateのテロのせいでDISKが吹っ飛ぶ(MSマジかよ・・・)
・バックアップとGitHubからデータ復元して作業再開
3ヶ月分程度の作業がすべてパー
正直、この時は心折れました


# Page. 26

![Page Image](https://bcdn.docswell.com/page/GJ5MG49GJ4.jpg)

リカバリーの過程で
・スナップショットテストの威力をかみしめる
・復旧後テストの動作は担保!!
・スナップショットテストﾈ申


# Page. 27

![Page Image](https://bcdn.docswell.com/page/9E29YV2D7R.jpg)

そんなCDKTFとの日々が・・・


# Page. 28

![Page Image](https://bcdn.docswell.com/page/D7Y4G3YMEM.jpg)

いきなりのお別れ
2025年12月10日、突如GitHubのアーカイブとサービス終了、事前告知なし


# Page. 29

![Page Image](https://bcdn.docswell.com/page/VENYGVP3J8.jpg)

移行をどうするか・・
・せっかく3クラウド分のDB作成のところまで進んだのに、、、、
・移行するには
①HCL変換してterraformへ戻る
②Plumiへ・・・(が、インポートできるのはHCL)
どっちにしてもHCLにしないといけない
cdktf synth --hcl
CDKTF is Dead: What Now?


# Page. 30

![Page Image](https://bcdn.docswell.com/page/Y79PW63PE3.jpg)

そして救世主cdktn爆誕


# Page. 31

![Page Image](https://bcdn.docswell.com/page/G78DNZMX7D.jpg)

なんとコミュニティの方々が・・・
Xユーザーのk.gotoさん: 「CDKTF (CDK
for Terraform) がコミュニティ駆動の継
続版として CDK Terrain (cdktn) という
名前に変わり、Open Construct
Foundation (OCF) によって開発が引き継
がれるそうです。
https://t.co/tRheplfY8N」 / X


# Page. 32

![Page Image](https://bcdn.docswell.com/page/L7LMPD3NJR.jpg)

GitHub覗きに行きました
open-constructs/cdk-terrain: Define infrastructure resources using programming constructs and
provision them using OpenTofu/Terraform
リリースされてる
じゃないですか!!!
(2月4日のことでしたね・・・)


# Page. 33

![Page Image](https://bcdn.docswell.com/page/4EMY4PDQEW.jpg)

そして移行(1時間ほどで終了)
Migrating to CDKTN - CDK Terrain (CDKTN)
・作業用Dockerコンテナ修正
・cdktnインストール
・tenvいれてterraformとOpen tofu入れる
・コマンドにシンボリックリンク張る
・新コンテナ立上
・ソースコード修正
・importしているライブラリの[cdktf]を[cdktn]に書替
・package.json書替
・npm installで依存パッケージインストールしなおし
・最後にスナップショットテスト(npm run test)走らせて
・テストはすべてGreen
・コマンドはcdktfと変わらない!!!!


# Page. 34

![Page Image](https://bcdn.docswell.com/page/PER9W14KJ9.jpg)

無事に移行完了、cdktnとの新生活スタート


# Page. 35

![Page Image](https://bcdn.docswell.com/page/P7XQPY25EX.jpg)

学んだこと
・買収されるといきなりサービス終了される場合もあるので要注意
・IaCはテストコード書くこと非常に重要
・環境はコンテナで作成してコードはGitHubで管理が必須
・OSSのコミュニティの人達はﾈ申
・この先どうなるかは分からないです。なんせメジャーじゃないので・・・


# Page. 36

![Page Image](https://bcdn.docswell.com/page/37K9D3MR7D.jpg)

実務において
・マネコンでリソースを触る人が多いので人類にIaCは早すぎる
・IaCは状態管理が命なので全部コード管理する覚悟がないと破綻する
・ちょっとした修正でDeploy走らせるのはコストが大きく面倒
・設計書のないコードが残されると技術負債化しがち(そうなると本末転倒)
・インフラ設定はGitHub管理できていないことが多くて履歴管理ツライ
きちんと調整せずにIaCを導入すると廃墟化する


# Page. 37

![Page Image](https://bcdn.docswell.com/page/LJ3WRGYGJ5.jpg)

そういう意味で行くとShell芸は
・マネコンでリソースを触られてもびくともしない
・状態管理していないけどコードでインフラ管理できる
・ちょっとした修正はCLIなので柔軟、修正コストはIaCよりやや小さい
・Shell職人がいれば何とかなる(どれだけいるかは謎だがIaCできる人より多そう)
・GitHubなくても頑張ればEXCELで履歴管理できる(やりたくないけど)
もしかしたらShell芸こそ最強のIaCかもしれない


# Page. 38

![Page Image](https://bcdn.docswell.com/page/8JDKY15NEG.jpg)

ちなみに同じ内容で、はやりの生成AI
にスライド作ってって依頼したら
Genspark
爆速で作成してくれました。そして自
分が作ったのより有益でした。


# Page. 39

![Page Image](https://bcdn.docswell.com/page/VEPK6QGN78.jpg)

ご清聴ありがとうございました