はじめに
先日、ちょっとした実験をしました。
ChatGPTに「EC2インスタンスをTerraformで作って。パブリックサブネットに置いて、SSHできるようにして」とだけ打ち込んでみたんです。
30秒もしないうちに、main.tf のコードが出てきました。VPC、サブネット、セキュリティグループ、キーペア。必要なリソースが一式そろって。
正直、最初は「すごい」と思いました。でも同時に、少し怖くなった。
「これを見て、インフラを"わかった"と思い込む人が増えるんじゃないか」 と。
この記事は、AI活用を否定したいわけではありません。私自身、日常的に使っています。ただ、現場で見てきた「AIコードで躓くパターン」をもとに、正直な話をしたいと思います。
この記事を読むと、以下のことができるようになります。
- AIが生成したTerraformコードの落とし穴を具体的に把握できる
- 「使える人」と「理解している人」の差を言語化できる
- AIを正しく活用しながらインフラ理解を深める学習法がわかる
AIがTerraformコードを書くのは得意
AIが生成するTerraformコードは、確かにレベルが高いです。
たとえば「ALBとECSのFargateで簡単なWebアプリの構成を作って」と聞けば、こんなコードが出てきます。
resource "aws_lb" "app" {
name = "app-alb"
internal = false
load_balancer_type = "application"
subnets = var.public_subnet_ids
security_groups = [aws_security_group.alb.id]
}
resource "aws_ecs_cluster" "app" {
name = "app-cluster"
}
resource "aws_ecs_task_definition" "app" {
family = "app-task"
requires_compatibilities = ["FARGATE"]
network_mode = "awsvpc"
cpu = "256"
memory = "512"
container_definitions = jsonencode([{
name = "app"
image = var.container_image
portMappings = [{
containerPort = 80
protocol = "tcp"
}]
}])
}
構文は正しい。AWSの仕様にも沿っている。terraform plan も通る。
でも、これを「動かすだけ」で終わっている人が、現場で詰まります。
現場で起きる「AIコード頼り」の3つの詰まりパターン
パターン1：エラーが出たとき、何も言えない
本番環境に近い構成で terraform apply を実行したら、こんなエラーが出たとします。
Error: InvalidParameterException: The provided target group does not have the same VPC as the load balancer.
このエラー、VPCの設定を正しく理解していれば「ALBとターゲットグループのVPCが違う」とすぐわかります。でもコードをコピーしただけでは、VPCとサブネットの関係が頭に入っていないので、どこを直せばいいかすらわからない。
パターン2：セキュリティの穴を見落とす
AIが生成するセキュリティグループは、動作確認を優先して 0.0.0.0/0 を許可するコードを出してくることがあります。
resource "aws_security_group_rule" "allow_ssh" {
type = "ingress"
from_port = 22
to_port = 22
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"] # 全世界にSSH開放
security_group_id = aws_security_group.ec2.id
}
「インターネット全体にSSHを開けてはいけない」という基礎知識がなければ、これを本番に適用してしまいます。実際、こういうインシデントは起きています。
パターン3：コスト爆発に気づかない
NAT Gatewayの構成をAIに聞いたとき、何も指定しなければマルチAZ構成のコードが出てくることがあります。
resource "aws_nat_gateway" "az_a" {
allocation_id = aws_eip.az_a.id
subnet_id = aws_subnet.public_a.id
}
resource "aws_nat_gateway" "az_b" {
allocation_id = aws_eip.az_b.id
subnet_id = aws_subnet.public_b.id
}
NAT Gatewayは1つあたり約$30〜$50/月＋データ転送費用がかかります。可用性のために2つ立てると、開発環境でも月$100を超える可能性があります。
「なぜこの構成にするのか」を理解していなければ、コストの見直しすらできません。
AIが苦手なこと：現場の「文脈」を読めない
AIはコードを書くのは得意ですが、文脈を読むのが苦手です。
- このシステムの可用性要件はどれくらいか
- 開発環境と本番環境で構成を変えるべきか
- セキュリティ要件は何を守ればいいか
- コストの上限はどこか
こういった「現場の文脈」は、AIに教えてあげないと反映されません。そして、これを「教えられる人」になるためには、インフラの基礎知識が必要です。
AIとインフラエンジニアの関係を整理すると、以下のようになります。
AIは中間の「コード生成」を担うツールです。要件の整理とレビューは、人間がやります。
「使える人」と「理解している人」の差
AI時代に広がる格差は、スキルではなく理解の深さだと感じています。
| 観点 | AIコードを貼るだけの人 | 理解して使う人 |
|---|---|---|
| エラー対応 | 「なぜ動かないか」わからない | 原因を推測して修正できる |
| セキュリティ | 穴を見落とす | レビューで問題を指摘できる |
| コスト | 気づかずに積み上がる | 意図的に構成を選べる |
| 説明責任 | 「AIが書いた」で終わる | 設計の意図を言語化できる |
現場でのレビューや、顧客への説明のとき、この差が出ます。
AIはあなたのスキルを証明してくれません。それは自分でやるしかない。
AIを使いながら理解を深める3つの学習法
「だからAIを使うな」ということではありません。むしろ逆です。AIを使いながら、理解を深める学び方があります。
1. AIのコードを「写経」する
AIが出してきたコードを、意味を調べながら手で打ち直す。コピペせずに、1行ずつ意味を確認する。面倒に見えて、これが一番定着します。
2. AIを「教師」として使う
コードを書かせた後に「このコードのVPCとサブネットの役割を説明して」と聞き返す。するとAIは丁寧に解説してくれます。生成ツールとしてだけでなく、学習補助として使うのが効果的です。
3. 実際に壊してみる
セキュリティグループのルールを変えて、通信が止まるのを確認する。NAT Gatewayを削除して、プライベートサブネットからの通信がどう変わるかを見る。
動いている状態だけ見ていても、仕組みは理解できません。壊して、直す経験が理解を作ります。
まとめ
この記事では以下のことを解説しました。
- AIが生成するTerraformコードには、エラー対応・セキュリティ・コストの落とし穴がある
- AIは「現場の文脈」を読めないため、要件整理とレビューは人間が担う必要がある
- AIを写経・対話・破壊実験の学習ツールとして使うことで理解が深まる
AIコードが一瞬で出てくる時代だからこそ、「なぜそのコードなのか」を説明できる人の価値が上がっています。
まず1つ、AIが出してきたコードを写経してみてください。それだけで、見える景色が変わります。
疑問や「自分はこう使っている」があれば、ぜひコメントで教えてください！
ハンズオンラボでは、未経験からでも「作って覚える」をモットーにしたITハンズオンイベントを定期開催しています。
面白かったら
「👇いいね」で応援