Codex CLIでインフラ構築を自動化｜Terraform・Docker・CloudFormation生成の実践ガイド

「Terraformの書き方がわからない」「Dockerfileのベストプラクティスってなんだっけ」——SES現場でインフラ周りのタスクを任されたとき、こんな悩みを抱えた経験はありませんか？

Infrastructure as Code（IaC）は現代のインフラ管理に不可欠な技術ですが、各ツールの構文やベストプラクティスを覚えるのは大変です。本記事では、OpenAI Codex CLIを使ってIaCコードを自動生成・最適化する実践的な方法を解説します。

なぜCodex CLIでインフラ構築なのか？

IaC（Infrastructure as Code）は、インフラをコードで管理する手法です。手動でクラウドコンソールを操作するのと比べ、再現性・バージョン管理・レビューが可能になるメリットがあります。しかし、以下の課題もあります。

• 学習コストが高い: Terraform HCL、CloudFormation YAML、Dockerfileなど、ツールごとに異なる構文を覚える必要がある
• ベストプラクティスの把握が困難: セキュリティ設定やパフォーマンス最適化の正解がわかりにくい
• SES現場特有の事情: 参画直後に既存インフラ構成を理解し、追加・修正する必要がある

Codex CLIなら、自然言語で要件を伝えるだけでIaCコードを生成できます。しかもサンドボックス環境で安全に動作するため、誤って本番環境に影響を与える心配がありません。

Terraformコード自動生成の実践

基本的なAWSリソースの生成

まず、シンプルなAWSインフラをCodex CLIで生成してみましょう。

codex "AWSでVPC、パブリックサブネット2つ、プライベートサブネット2つ、NATゲートウェイを含むネットワーク構成のTerraformコードを生成して。リージョンはap-northeast-1で。"

Codex CLIは以下のようなTerraformコードを生成します。

# main.tf
provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_vpc" "main" {
  cidr_block           = "10.0.0.0/16"
  enable_dns_hostnames = true
  enable_dns_support   = true

  tags = {
    Name = "main-vpc"
  }
}

resource "aws_subnet" "public" {
  count                   = 2
  vpc_id                  = aws_vpc.main.id
  cidr_block              = "10.0.${count.index + 1}.0/24"
  availability_zone       = data.aws_availability_zones.available.names[count.index]
  map_public_ip_on_launch = true

  tags = {
    Name = "public-subnet-${count.index + 1}"
  }
}

resource "aws_subnet" "private" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.${count.index + 10}.0/24"
  availability_zone = data.aws_availability_zones.available.names[count.index]

  tags = {
    Name = "private-subnet-${count.index + 1}"
  }
}

既存構成の読み込みと拡張

SES現場では、既にTerraformコードが存在するプロジェクトに参画することが多いでしょう。Codex CLIなら既存コードを読み込んで拡張できます。

codex "このTerraformプロジェクトにALB（Application Load Balancer）とECSクラスターを追加して。既存のVPCとサブネットを参照して。"

ポイントは、Codex CLIがプロジェクトディレクトリ内の既存ファイルを自動的に認識し、変数名やリソース参照を正しく引き継ぐことです。

変数とモジュールの分離

実務では、環境ごとに設定を切り替えるためのモジュール分離が重要です。

codex "このTerraformコードをモジュール化して。modules/network、modules/compute、modules/databaseに分離して、environments/dev/main.tfとenvironments/prod/main.tfから呼び出す構成にして。"

Codex CLIは以下の作業を自動で行います。

1. 既存リソースの依存関係を分析
2. モジュールのinput/output変数を自動定義
3. 環境ごとの terraform.tfvars を生成
4. backend.tf にS3バックエンド設定を追加

Dockerfile生成と最適化

マルチステージビルドの自動生成

Dockerfileの最適化は、イメージサイズやビルド時間に直結します。Codex CLIはベストプラクティスに沿ったDockerfileを生成します。

codex "Next.js 15アプリ用のDockerfileを作成して。マルチステージビルドで、最終イメージはnode:22-alpineベースにして。pnpmを使用。"

生成されるDockerfileの例：

# ---- ベースイメージ ----
FROM node:22-alpine AS base
RUN corepack enable && corepack prepare pnpm@latest --activate
WORKDIR /app

# ---- 依存関係インストール ----
FROM base AS deps
COPY package.json pnpm-lock.yaml ./
RUN pnpm install --frozen-lockfile --prod=false

# ---- ビルド ----
FROM base AS builder
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN pnpm build

# ---- 本番イメージ ----
FROM node:22-alpine AS runner
WORKDIR /app
ENV NODE_ENV=production

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs
EXPOSE 3000
CMD ["node", "server.js"]

既存Dockerfileのセキュリティ監査

既存のDockerfileをCodex CLIに読み込ませ、セキュリティリスクを検出できます。

codex "このDockerfileをセキュリティ観点でレビューして。脆弱性やベストプラクティス違反があれば修正して。"

Codex CLIが検出する主な問題：

リスク	具体例	修正方法
rootユーザーで実行	USER 指定なし	非rootユーザーを作成して USER を指定
不要パッケージ残存	ビルドツールが最終イメージに含まれる	マルチステージビルドで分離
シークレットのハードコード	ENV API_KEY=xxx	ビルド時に --build-arg で渡す
ベースイメージの固定なし	FROM node:latest	FROM node:22-alpine@sha256:...

CloudFormation テンプレートの生成

スタック構成の自動生成

AWSネイティブのIaCツールであるCloudFormationも、Codex CLIで効率的に生成できます。

codex "CloudFormationテンプレートを作成して。ECS Fargate + ALB + RDS Aurora PostgreSQLの構成。パラメータでインスタンスサイズやDB名を設定できるようにして。"

ネストスタックへの分離

大規模な構成では、ネストスタックでの管理が推奨されます。

codex "このCloudFormationテンプレートをネストスタックに分離して。network.yaml、compute.yaml、database.yamlの3つに分けて、親テンプレートのmain.yamlから呼び出す構成にして。"

Docker Compose による開発環境構築

SES現場で開発環境を素早く立ち上げるために、Docker Composeは非常に重宝します。

codex "以下の構成でdocker-compose.ymlを作成して：
- Next.jsフロントエンド（ポート3000）
- NestJSバックエンドAPI（ポート4000）
- PostgreSQL 16（ポート5432）
- Redis 7（ポート6379）
- MinIO（S3互換ストレージ、ポート9000）
ホットリロード対応のボリュームマウント付きで。"

生成される docker-compose.yml は、開発環境に必要なすべてのサービスを含み、ボリュームマウントによるホットリロードにも対応します。

version: '3.9'
services:
  frontend:
    build:
      context: ./frontend
      target: dev
    ports:
      - "3000:3000"
    volumes:
      - ./frontend:/app
      - /app/node_modules
    environment:
      - NEXT_PUBLIC_API_URL=http://localhost:4000
    depends_on:
      - backend

  backend:
    build:
      context: ./backend
      target: dev
    ports:
      - "4000:4000"
    volumes:
      - ./backend:/app
      - /app/node_modules
    environment:
      - DATABASE_URL=postgresql://postgres:password@db:5432/app
      - REDIS_URL=redis://redis:6379
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_started

  db:
    image: postgres:16-alpine
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: app
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  minio:
    image: minio/minio
    ports:
      - "9000:9000"
      - "9001:9001"
    environment:
      MINIO_ROOT_USER: minioadmin
      MINIO_ROOT_PASSWORD: minioadmin
    command: server /data --console-address ":9001"
    volumes:
      - minio-data:/data

volumes:
  pgdata:
  minio-data:

IaCコードのセキュリティ監査と最適化

Terraformセキュリティチェック

Codex CLIは、IaCコードのセキュリティ監査にも活用できます。

codex "このTerraformプロジェクト全体をセキュリティ監査して。CISベンチマーク準拠の観点で問題を洗い出して、修正コードも出力して。"

検出される主な問題例：

• S3バケットの暗号化未設定: server_side_encryption_configuration の追加
• セキュリティグループの0.0.0.0/0許可: 必要最小限のIPレンジに制限
• CloudTrailの無効化: 監査ログの有効化
• IAMポリシーの過剰権限: 最小権限の原則に基づく修正

コスト最適化の提案

codex "このTerraformコードのAWSコストを最適化するための提案をして。リザーブドインスタンスやSpotインスタンスの活用も含めて。"

SES現場でのインフラ引き継ぎ効率化

既存インフラのドキュメント化

SES案件で参画直後に最も求められるのが、既存インフラの理解です。Codex CLIを使えば、IaCコードから自動的にドキュメントを生成できます。

codex "このTerraformプロジェクトのインフラ構成図をMermaid記法で生成して。リソース間の依存関係と通信フローを含めて。README.mdにインフラ概要ドキュメントも作成して。"

terraform plan の差分レビュー

変更内容を安全に確認するために、terraform plan の出力をCodex CLIに渡してレビューさせる方法も有効です。

terraform plan -no-color > /tmp/plan-output.txt
codex "このterraform planの出力をレビューして。破壊的変更やセキュリティリスクがあれば指摘して。" < /tmp/plan-output.txt

Kubernetes マニフェストの生成

コンテナオーケストレーションが必要な現場では、KubernetesマニフェストもCodex CLIで生成できます。

codex "以下の要件でKubernetesマニフェストを生成して：
- Deployment: replicas 3、リソース制限付き
- Service: ClusterIP
- HPA: CPU 70%で2-10台スケーリング
- Ingress: ALB Ingress Controller対応
- ConfigMap + Secret の分離"

Helmチャートへの変換

codex "このKubernetesマニフェストをHelmチャートに変換して。values.yamlで環境ごとに設定を切り替えられるようにして。"

実践Tips：Codex CLIでIaCを書く際のコツ

1. プロンプトに制約条件を明示する

# 悪い例
codex "AWSのインフラを作って"

# 良い例
codex "AWSでECS Fargateのインフラを作って。条件：
- リージョン: ap-northeast-1
- VPC CIDR: 10.0.0.0/16
- マルチAZ構成（2AZ）
- タグ規約: Environment, Project, ManagedBy=terraform
- tfstateはS3+DynamoDBでリモート管理"

2. 既存のtfstateやモジュールを活用する

Codex CLIはプロジェクト内のファイルを参照するため、既存のコードベースと整合性のある出力を得られます。

3. 段階的に生成する

大規模なインフラを一度に生成するのではなく、ネットワーク→コンピュート→データベース→監視の順に段階的に生成すると、品質が向上します。

まとめ

OpenAI Codex CLIを活用すれば、Terraform・Docker・CloudFormation・Kubernetesといった主要なIaCツールのコード生成を大幅に効率化できます。

特にSES現場で役立つポイント：

• 参画直後: 既存IaCコードの理解とドキュメント自動生成
• 構築フェーズ: 要件からIaCコードを高速生成
• 運用フェーズ: セキュリティ監査とコスト最適化の提案
• 引き継ぎ時: 構成図とドキュメントの自動生成

IaCの知識がまだ浅いエンジニアでも、Codex CLIをパートナーとして活用することで、品質の高いインフラコードを効率的に作成できるようになります。ぜひ現場で試してみてください。