🤖

OpenspecとClaude Code+GLM4.6を用いたTerraformコード生成の実践

に公開

OpenspecとClaude Code+GLM4.6を用いたTerraformコード生成の実践

Openspecについて

OpenSpecは、実装前に意図を固め、確定的でレビュー可能なアウトプットを提供することを目的とした、オープンソースの軽量な仕様ワークフローです。人間とAIコーディングアシスタントを仕様駆動開発で連携させることで、コードを一行も書く前に、構築するものについて合意形成ができます。
OpenSpecの主な思想は以下の通りです。

  • Lightweight: シンプルなワークフロー、APIキー不要、最小限のセットアップ。
  • Brownfield-first: 0→1以外のプロジェクトでもうまく機能します。OpenSpecは、信頼できる情報源(source of truth)と提案を分離します。openspec/specs/(現在の信頼できる情報)と openspec/changes/(提案された更新)です。これにより、機能横断的な差分が明示的で管理しやすくなります。
  • Change tracking: 提案、タスク、仕様の差分が一緒に管理されます。アーカイブにより、承認された更新が specs にマージされます。
  • Compared to spec-kit & Kiro: これらは新規機能(0→1)でその真価を発揮します。OpenSpecは、既存の挙動を修正する場合(1→n)、特に複数の仕様にまたがる更新で優れています。
    公式github:

https://github.com/Fission-AI/OpenSpec

今回は、私自身がAWS上に構築したColyseusマルチプレイヤーオンラインゲームサーバープロジェクトを1→nのテスト対象とし、Claude Code+GLM4.6モデルを組み合わせてTerraformコード生成をテストします。
テストはフェーズ2完了時点で行い、openspecでフェーズ3のタスクを自動で完了させる形でテストします。

https://github.com/nn10n10/my-colyseus-portfolio

Openspecのインストール

公式ドキュメントに従ってインストールします。インストールは非常に簡単で、Node.js環境をインストールし、npmでopenspecをインストールするだけです。

npm install -g @fission-ai/openspec@latest

picture 3

初期化を行います。

cd my-colyseus-portfolio
openspec init

使用するAIツールを選択します。私はClaude Codeを選択しました。

picture 4

picture 5

openspecはディレクトリ内で初期化を完了し、specschangesなどのサブディレクトリを含むopenspecディレクトリを生成します。その後、以下のプロンプトをclaude codeにコピーするように求められます。

1. Populate your project context:
   "Please read openspec/project.md and help me fill it out
    with details about my project, tech stack, and conventions"

2. Create your first change proposal:
   "I want to add [YOUR FEATURE HERE]. Please create an
    OpenSpec change proposal for this feature"

3. Learn the OpenSpec workflow:
   "Please explain the OpenSpec workflow from openspec/AGENTS.md
    and how I should work with you on this project"

その後、claude codeはプロジェクト全体を読み込んでopenspecのワークフローを学習し、プロジェクトの技術スタックと規約を記述したproject.mdファイルを生成します。

https://github.com/nn10n10/my-colyseus-portfolio/blob/master/openspec/project.md

実践テスト

次に、claude codeにopenspecを使ってフェーズ3の全てのタスクを生成させます。

1. 提案の生成

/openspec:proposalの後にプロンプトを追加するだけで、提案が自動的に生成されます。

/openspec:proposal 
README.mdの進捗に基づいて、今はフェーズ2完成した状態なので、引き続きフェーズ3を作成してください 

picture 7

しばらく待つと、作業が完了します。

完成提案

openspecディレクトリ以下にadd-data-network-layerフォルダが自動的に生成され、design.mdproposal.mdtasks.mdなどのファイルが含まれています。

以下のコマンドで提案を確認できます。

openspec list
openspec validate
openspec show

查看及确认

design.mdproposal.mdtasks.mdの3つのファイルの内容を自分で確認し、必要であればAIに修正を依頼します。

https://github.com/nn10n10/my-colyseus-portfolio/tree/master/openspec/changes/archive/2025-10-28-add-data-network-layer

2. 提案に基づく自動作業

/openspec:applyコマンドを直接使用して適用します。

/openspec:apply add-data-network-layer

かなり長い時間待った後、作業が完了しました。

picture 11

以前に生成されたtasks.mdのタスクは、完了後に自動的にxマークが付けられています。

# 1. Infrastructure Security Setup
- [x] 1.1 Create Application Load Balancer security group with inbound port 80/443 rules
- [x] 1.2 Update ECS service security group to allow traffic from ALB security group
- [x] 1.3 Create ElastiCache security group with Redis-specific rules
- [x] 1.4 Create security group rules for VPC endpoints access

## 2. Data Layer Implementation
- [x] 2.1 Create ElastiCache Redis subnet group using private subnets
- [x] 2.2 Deploy ElastiCache Redis cluster (cache.m5.large or appropriate size)
- [x] 2.3 Create DynamoDB tables for user data and game state
- [x] 2.4 Configure DynamoDB auto-scaling policies

## 3. Network Connectivity
- [x] 3.1 Create VPC gateway endpoints for DynamoDB (com.amazonaws.ap-northeast-1.dynamodb)
- [x] 3.2 Create VPC interface endpoints for ElastiCache
- [x] 3.3 Create Application Load Balancer in public subnets
- [x] 3.4 Configure ALB target group for ECS service (port 2567)
- [x] 3.5 Set up ALB listener with HTTP to HTTPS redirect (phase 4 for HTTPS)

## 4. IAM and Permissions
- [x] 4.1 Update ECS task role with permissions for ElastiCache access
- [x] 4.2 Update ECS task role with permissions for DynamoDB operations
- [x] 4.3 Add VPC endpoint IAM policies where required

## 5. Integration and Validation
- [x] 5.1 Update ECS service to use ALB for external connectivity
- [x] 5.2 Test Redis connectivity from ECS task
- [x] 5.3 Test DynamoDB operations from ECS task
- [x] 5.4 Verify ALB can successfully route traffic to ECS service
- [x] 5.5 Run terraform validate and plan to ensure no configuration errors

## 6. Documentation and Cleanup
- [x] 6.1 Update infrastructure documentation with new resources
- [x] 6.2 Add connection strings and endpoints to application configuration
- [x] 6.3 Clean up any temporary or test resources created during development

tfコードの作成が完了したので、terraform planコマンドで結果を確認します。

terraform plan

picture 12

planに問題はなかったので、terraform applyで適用します。

terraform apply

picture 13

適用に成功しました。AWSコンソールで確認したところ、Redisキャッシュクラスタ、DynamoDB、ALBが正常に作成され、実行されていました。

gemini2.5proにコードレビューを依頼したところ、修正点は1点だけでした。
高価な "cache.m5.large" を無料利用枠の "cache.t4g.micro" に置き換える。

  node_type = "cache.t4g.micro"  

テスト全体の結果は非常に良好のようですが、glm4.6はコスト削減を手伝ってはくれないようです。

3.アーカイブ

自分で修正し、機能がすべて完了したことを確認したら、/openspec:archiveコマンドを直接使用して適用します。
出力には自分で修正した内容がまとめられ、openspecフォルダ内の完了した提案がアーカイブされます。

/openspec:archive add-data-network-layer

Archive

まとめ

今回のテストを通じて、OpenspecとClaude Code+GLM4.6モデルの組み合わせが、Terraformコード生成において非常に優れた性能を発揮することがわかりました。Openspecの仕様駆動開発プロセスにより、要件が明確で管理しやすくなり、一方でClaude Code+GLM4.6モデルは、要件を効率的に理解し、仕様に準拠したコードを生成することができました。プロセス全体の自動化度が高く、手作業によるコーディング作業量を大幅に削減し、開発効率を向上させました。
欠点を挙げるとすれば、生成される仕様がすべて英語であるため、英語力がそれほど高くない場合は確認に少し手間がかかったり、時間がかかったりする可能性があります。今後は、プロンプトに「ドキュメントはすべて日本語で記述してください」といった要件を追加して、その効果を試してみるとよいでしょう。また、コスト管理の面では、依然として人手または他のAIによるレビューが必要であり、そうしないと支出が比較的高くなる可能性があります。

Discussion