【AI駆動開発】迷ったらこれ！OpenSpecチートシート【仕様駆動開発】

はじめに

以前ハリネズミさんが実践的な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のメリット

類似ツールとの比較

仕様駆動開発（SDD）のツールは複数存在する。それぞれアプローチが異なる。

openspec/specs/

/opsx:apply

/kiro-impl

/speckit.implement

npm install -g

openspec init

npx cc-sdd@latest

pip install

選び方の目安

セットアップ

# インストール（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つのプロファイルがあり、ワークフローの粒度が異なる。

propose

new

continue

ff

verify

bulk-archive

openspec config profile

openspec update

Core は「提案→実装→アーカイブ」を最短で回すためのプロファイル。

/opsx:propose

Expanded は計画フェーズを細かく制御したい場合のプロファイル。アーティファクトを1つずつ確認しながら進める

continue

ff

verify

コマンド早見表

Core プロファイル（デフォルト）

/opsx:propose <name>

/opsx:explore

/opsx:apply

/opsx:sync

/opsx:archive

Expanded プロファイル（拡張）

/opsx:new <name>

/opsx:continue

/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

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軸

/opsx:explore の使用例

要件が不明確なとき、変更を作る前にアイデアを探索・調査できる。アーティファクトは生成されない。

You: /opsx:explore モバイルアプリの認証をどう実装すべきか

AI:  現在のコードベースを調査します...
     Web側はセッションベース認証を使っていますね。
     モバイル向けには3つの選択肢があります:

     1. JWT（ステートレス、オフライン対応）
     2. OAuth2（サードパーティログインが必要な場合）
     3. 既存セッションの拡張（シンプルだが常時接続が必要）

     どの方向に興味がありますか？

You: JWTで行こう

AI:  了解です。/opsx:new add-jwt-auth で変更を始められます。

活用場面:

• 技術選定の比較検討
• パフォーマンス問題の原因調査
• 既存コードの全体像把握
• 複数アプローチの比較

ベストプラクティス

/opsx:explore

/opsx:verify

add-dark-mode

feature-1

対応ツール（抜粋）

claude

github-copilot

cursor

codex

kiro

windsurf

amazon-q

cline

gemini

roocode

全29ツール対応。

openspec init --tools all