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：
今回は、私自身がAWS上に構築したColyseusマルチプレイヤーオンラインゲームサーバープロジェクトを1→nのテスト対象とし、Claude Code+GLM4.6モデルを組み合わせてTerraformコード生成をテストします。
テストはフェーズ2完了時点で行い、openspecでフェーズ3のタスクを自動で完了させる形でテストします。
Openspecのインストール
公式ドキュメントに従ってインストールします。インストールは非常に簡単で、Node.js環境をインストールし、npmでopenspecをインストールするだけです。
npm install -g @fission-ai/openspec@latest
初期化を行います。
cd my-colyseus-portfolio
openspec init
使用するAIツールを選択します。私はClaude Codeを選択しました。
openspecはディレクトリ内で初期化を完了し、specs、changesなどのサブディレクトリを含む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ファイルを生成します。
実践テスト
次に、claude codeにopenspecを使ってフェーズ3の全てのタスクを生成させます。
1. 提案の生成
/openspec:proposalの後にプロンプトを追加するだけで、提案が自動的に生成されます。
/openspec:proposal
README.mdの進捗に基づいて、今はフェーズ2完成した状態なので、引き続きフェーズ3を作成してください
しばらく待つと、作業が完了します。
openspecディレクトリ以下にadd-data-network-layerフォルダが自動的に生成され、design.md、proposal.md、tasks.mdなどのファイルが含まれています。
以下のコマンドで提案を確認できます。
openspec list
openspec validate
openspec show
design.md、proposal.md、tasks.mdの3つのファイルの内容を自分で確認し、必要であればAIに修正を依頼します。
2. 提案に基づく自動作業
/openspec:applyコマンドを直接使用して適用します。
/openspec:apply add-data-network-layer
かなり長い時間待った後、作業が完了しました。
以前に生成された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
planに問題はなかったので、terraform applyで適用します。
terraform apply
適用に成功しました。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
まとめ
今回のテストを通じて、OpenspecとClaude Code+GLM4.6モデルの組み合わせが、Terraformコード生成において非常に優れた性能を発揮することがわかりました。Openspecの仕様駆動開発プロセスにより、要件が明確で管理しやすくなり、一方でClaude Code+GLM4.6モデルは、要件を効率的に理解し、仕様に準拠したコードを生成することができました。プロセス全体の自動化度が高く、手作業によるコーディング作業量を大幅に削減し、開発効率を向上させました。
欠点を挙げるとすれば、生成される仕様がすべて英語であるため、英語力がそれほど高くない場合は確認に少し手間がかかったり、時間がかかったりする可能性があります。今後は、プロンプトに「ドキュメントはすべて日本語で記述してください」といった要件を追加して、その効果を試してみるとよいでしょう。また、コスト管理の面では、依然として人手または他のAIによるレビューが必要であり、そうしないと支出が比較的高くなる可能性があります。