はじめに
以前ハリネズミさんが実践的なOpenSpec関連の記事を作成されていましたが、それを基に私もOpenSpecを活用しています。
今回の記事では皆さんにもより身近に、気軽にOpenSpecを活用していただくために特徴やコマンドをまとめたチートシートを作成しました。
OpenSpecを使っていてコマンドを忘れた際や、他の仕様駆動開発の手法と比較したい時の参考情報としてご使用ください。
実際にどのようなファイルが生成されるかや、どのように活用できるかの具体例はハリネズミさんの実践的な記事をご覧ください。
OpenSpecの実践的な記事
OpenSpec — 仕様駆動開発のナレッジをいい感じに循環させる(Amplify + AgentCoreハンズオン付き)
OpenSpecとは
AIコーディングアシスタントと人間が「何を作るか」をコードの前に合意するための軽量フレームワーク。
→ fluid not rigid（柔軟）
→ iterative not waterfall（反復的）
→ easy not complex（簡単）
→ brownfield-first（既存プロジェクト対応）
リポジトリ: Fission-AI/OpenSpec | MIT | npm:
@fission-ai/openspec
OpenSpecのメリット
| メリット | 説明 |
|---|---|
| 合意してから作る | 人間とAIがスペックで合意してからコードを書くため、手戻りが減る |
| ナレッジの蓄積 | Archiveに「なぜ・何を・どうやって変えたか」が全て残り、過去の意思決定を後から参照できる |
| 仕様が常に最新 | デルタスペックがアーカイブ時にメインスペックへマージされ、ソースオブトゥルースが自動更新される |
| 並行作業が安全 | 各変更が独立フォルダなので、複数機能を同時に進めても仕様が衝突しにくい |
| ツールを選ばない | 29のAIコーディングアシスタントに対応。特定のIDEやモデルに縛られない |
| 既存プロジェクトに導入しやすい | デルタスペックで差分だけ記述するため、全仕様を一から書く必要がない |
| カスタマイズ可能 | スキーマを定義してチーム独自のワークフローを構築できる |
類似ツールとの比較
仕様駆動開発（SDD）のツールは複数存在する。それぞれアプローチが異なる。
| 項目 | OpenSpec | cc-sdd | Spec Kit (GitHub) | Kiro (AWS) |
|---|---|---|---|---|
| 思想 | 軽量・柔軟・フェーズゲートなし | 境界駆動・自律実装・TDD重視 | 厳格なフェーズパイプライン | IDE統合型の仕様管理 |
| ソースオブトゥルース | スペック（openspec/specs/） |
コード（スペックは契約） | 仕様（Constitution + テンプレート） | スペック |
| ワークフロー制御 | アクションベース（自由な順序） | フェーズゲートあり（承認後に実装） | 厳格な4段階パイプライン | IDE内で段階的に進行 |
| 対応ツール数 | 29ツール | 8ツール | 4ツール (Copilot, Claude, Gemini, Cursor) | Kiro IDE専用 |
| 対応モデル | ツール非依存（任意） | ツール非依存（任意） | ツール非依存（任意） | Claude, DeepSeek, MiniMax, GLM, Qwen等（AWS Bedrock経由） |
| 自律実装 |
/opsx:apply で実装 |
/kiro-impl でサブエージェント自律実装+レビュー |
/speckit.implement で実装 |
IDE内で自動実装 |
| デルタ管理 | デルタスペック（ADDED/MODIFIED/REMOVED） | なし（コードが真実） | なし | なし |
| カスタマイズ | スキーマで自由定義 | テンプレート・ルール編集 | テンプレート・拡張カタログ | 限定的 |
| セットアップ |
npm install -g + openspec init
|
npx cc-sdd@latest |
Python環境 + pip install
|
IDE導入のみ |
| Stars | 50.9k | 3.4k | 15k+ | - |
選び方の目安
| こんな場合 | 推奨ツール |
|---|---|
| 軽量に始めたい、ツールを選ばない | OpenSpec |
| 自律的な長時間実装+TDDを重視 | cc-sdd |
| GitHub Copilotメインで厳格な管理 | Spec Kit |
| IDE統合で完結させたい | Kiro |
| 既存プロジェクトへの差分管理が重要 | OpenSpec（デルタスペック） |
セットアップ
# インストール（Node.js 20.19.0+）
npm install -g @fission-ai/openspec@latest
# プロジェクト初期化
cd your-project
openspec init
# ツール指定で初期化
openspec init --tools claude,cursor,github-copilot
# プロファイル変更（拡張ワークフロー有効化）
openspec config profile
openspec update
ディレクトリ構造
openspec/
├── specs/ # ソースオブトゥルース（現在の仕様）
│ ├── auth/spec.md
│ └── payments/spec.md
├── changes/ # 進行中の変更
│ ├── add-dark-mode/
│ │ ├── proposal.md # なぜ・何を
│ │ ├── specs/ # デルタスペック（差分）
│ │ ├── design.md # どうやって
│ │ └── tasks.md # 実装ステップ
│ └── archive/ # 完了した変更の履歴
└── schemas/ # ワークフロー定義
プロファイルの違い
OpenSpecには2つのプロファイルがあり、ワークフローの粒度が異なる。
| 項目 | Core（デフォルト） | Expanded（拡張） |
|---|---|---|
| 対象 | 素早く進めたい場合 | 段階的に制御したい場合 |
| 計画の作り方 |
propose で一括生成 |
new → continue / ff で段階的に生成 |
| 検証 | なし（手動確認） |
verify で自動検証 |
| アーカイブ | 1件ずつ |
bulk-archive で一括対応可 |
| 有効化 | デフォルト |
openspec config profile → openspec update
|
Core は「提案→実装→アーカイブ」を最短で回すためのプロファイル。/opsx:propose 1つで proposal・specs・design・tasks を全て生成し、すぐ実装に入れる。
Expanded は計画フェーズを細かく制御したい場合のプロファイル。アーティファクトを1つずつ確認しながら進める continue や、一括生成の ff、実装後の整合性チェック verify など、より多くのコマンドが使える。
コマンド早見表
Core プロファイル（デフォルト）
| コマンド | 説明 | いつ使う |
|---|---|---|
/opsx:propose <name> |
変更提案 + 全アーティファクト作成 | 新機能を始めるとき |
/opsx:explore |
アイデアの探索・調査 | 要件が不明確なとき |
/opsx:apply |
タスクを実装 | コードを書く準備ができたとき |
/opsx:sync |
デルタスペックをメインにマージ | 仕様を更新したいとき |
/opsx:archive |
変更を完了・アーカイブ | 全作業が終わったとき |
Expanded プロファイル（拡張）
| コマンド | 説明 | いつ使う |
|---|---|---|
/opsx:new <name> |
変更スキャフォールド作成 | 段階的に進めたいとき |
/opsx:continue |
次のアーティファクトを1つ作成 | 1つずつ確認しながら進めたいとき |
/opsx:ff |
全計画アーティファクト一括作成 | 要件が明確で一気に進めたいとき |
/opsx:verify |
実装と仕様の整合性を検証 | アーカイブ前の確認 |
/opsx:bulk-archive |
複数変更を一括アーカイブ | 並行作業の完了時 |
/opsx:onboard |
プロジェクトオンボーディング | 新メンバー参加時 |
CLIコマンド
openspec init # 初期化
openspec init --tools all # 全ツール対応で初期化
openspec update # エージェント指示を再生成
openspec config profile # プロファイル選択
openspec list # 変更一覧
openspec schema init <name> # カスタムスキーマ作成
openspec schema fork <src> <dst> # スキーマをフォーク
クイックリファレンス: 典型的な1機能の流れ
# 1. 変更スキャフォールド作成
/opsx:new add-user-search
# 2. アーティファクトを順番に生成（proposal → specs → design → tasks）
/opsx:continue # proposal.md 生成
/opsx:continue # specs/ 生成
/opsx:continue # design.md 生成
/opsx:continue # tasks.md 生成
# 3. 内容を確認・修正（必要に応じて）
# 4. 実装
/opsx:apply
# 5. 完了
/opsx:archive
ワークフローパターン
標準（要件がある程度明確）
/opsx:new add-dark-mode → /opsx:continue → /opsx:apply → /opsx:archive
探索的（要件が不明確）
/opsx:explore 認証方式の比較検討 → /opsx:new add-jwt-auth → /opsx:continue → /opsx:apply → /opsx:archive
高速（Expanded、一括生成）
/opsx:new add-dark-mode → /opsx:ff → /opsx:apply → /opsx:verify → /opsx:archive
並行開発
/opsx:new feature-a → /opsx:ff → /opsx:apply
/opsx:new fix-bug-b → /opsx:ff → /opsx:apply
→ /opsx:bulk-archive
アーティファクト（生成される仕様書）の役割
/opsx:propose や /opsx:continue で生成される4つのアーティファクトは、それぞれ異なる問いに答える。
proposal.md — なぜ作るのか、何を作るのか
変更の意図・スコープ・大まかなアプローチを記述する。チームやAIが「この変更は何のためか」を理解するための出発点。
含める内容:
- Intent（意図）: なぜこの変更が必要か
- Scope（スコープ）: 何が対象で、何が対象外か
- Approach（アプローチ）: 大まかな方針
design.md — どうやって実現するのか
技術的なアプローチとアーキテクチャ上の決定を記述する。「なぜこの方法を選んだか」の根拠も含める。
含める内容:
- Technical Approach（技術的アプローチ）
- Architecture Decisions（アーキテクチャ決定とその理由）
- Data Flow（データフロー）
- File Changes（変更対象ファイル）
specs/ (デルタスペック) — 何が変わるのか
現在の仕様に対して「何が追加/変更/削除されるか」を記述する。要件とシナリオ（Given/When/Then）で構成され、テスト可能な形で振る舞いを定義する。アーカイブ時にメインスペックへマージされる。
含める内容:
- ADDED Requirements: 新しく追加する要件
- MODIFIED Requirements: 変更する既存要件
- REMOVED Requirements: 廃止する要件
tasks.md — 何をどの順番で実装するのか
実装のチェックリスト。AIが /opsx:apply で実装する際の作業指示書になる。
含める内容:
- グループ化されたタスク（見出しで分類）
- 階層的な番号付け（1.1, 1.2, 2.1...）
- チェックボックス（
- [ ]/- [x]）で進捗管理
4つの関係性
proposal.md → 「なぜ・何を」を定義
↓
design.md → 「技術的な実現方法」を定義
↓
specs/ → 「振る舞いの変更」を定義（テスト可能な形で）
↓
tasks.md → 「具体的な実装手順」を定義
↓
実装 → tasks.mdに従ってコードを書く
アーティファクト依存関係
proposal（なぜ・何を）
│
┌───────┴───────┐
▼ ▼
specs design
(何が変わる) (どうやって)
│ │
└───────┬───────┘
▼
tasks（実装ステップ）
│
▼
implement（実装）
/opsx:verify の検証3軸
| 軸 | チェック内容 |
|---|---|
| Completeness | 全タスク完了？全要件実装済み？シナリオカバー？ |
| Correctness | 実装がスペックの意図に合致？エッジケース対応？ |
| Coherence | デザイン決定がコードに反映？パターン一貫？ |
/opsx:explore の使用例
要件が不明確なとき、変更を作る前にアイデアを探索・調査できる。アーティファクトは生成されない。
You: /opsx:explore モバイルアプリの認証をどう実装すべきか
AI: 現在のコードベースを調査します...
Web側はセッションベース認証を使っていますね。
モバイル向けには3つの選択肢があります:
1. JWT（ステートレス、オフライン対応）
2. OAuth2（サードパーティログインが必要な場合）
3. 既存セッションの拡張（シンプルだが常時接続が必要）
どの方向に興味がありますか？
You: JWTで行こう
AI: 了解です。/opsx:new add-jwt-auth で変更を始められます。
活用場面:
- 技術選定の比較検討
- パフォーマンス問題の原因調査
- 既存コードの全体像把握
- 複数アプローチの比較
ベストプラクティス
| ルール | 説明 |
|---|---|
| 変更は焦点を絞る | 1論理単位 = 1変更フォルダ |
| 不明確なら探索から |
/opsx:explore で問題空間を理解 |
| アーカイブ前に検証 |
/opsx:verify で不一致を早期発見 |
| 明確な命名 |
add-dark-mode ○ / feature-1 × |
| 段階的厳密さ | 通常はLite、高リスク時のみFull |
| コンテキスト衛生 | 実装前にコンテキストをクリア |
対応ツール（抜粋）
| ツール | ID |
|---|---|
| Claude Code | claude |
| GitHub Copilot | github-copilot |
| Cursor | cursor |
| Codex | codex |
| Kiro | kiro |
| Windsurf | windsurf |
| Amazon Q | amazon-q |
| Cline | cline |
| Gemini CLI | gemini |
| RooCode | roocode |
全29ツール対応。openspec init --tools all で全対応可能。