OpenSpec（Fission-AI/OpenSpec）は、AIコーディングエージェントに「仕様を先に書かせてから実装させる」ワークフローを強制するCLIツールだ。本記事ではnpx実行での起動確認までを実機で行い、README公称の新ワークフロー/opsx:propose→apply→archiveがCLI単体でどこまで再現できるかを検証する。
- ・正体：Fission-AI製・MITライセンスのAIコーディング向け仕様駆動開発CLI。GitHub star約70,000・fork約4,800（概数）
- ・何ができる：AIエージェントに変更提案(proposal/design/tasks)を`openspec/changes/`配下に作らせ、実装後は`archive`でspecsへ反映する
- ・実測：`npx @fission-ai/openspec@latest init`で`openspec/`ディレクトリと`config.yaml`が生成されることをLinux実機で確認。`opsx:propose`自体はAIエージェント越しのスラッシュコマンドのためCLI単体では未検証
- ・注意：README冒頭に「新しいワークフローに作り直した」旨の告知があり、`opsx:`系コマンドへの移行期。旧ワークフローとの併存状況は執筆時点で確認しきれていない
この記事ではOpenSpec単体の使い方と新ワークフローに絞って解説する。AIコーディングエージェント全般のインストールから運用まではClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめている。spec-kit・cc-sdd・AI-DLCなど複数の仕様駆動開発ツールを横並びで見分けたい場合はspec-kit完全ガイド｜GitHub公式の仕様駆動AI開発を cc-sdd・AI-DLCと徹底比較を先に読むと役割分担がわかりやすい。
OpenSpecとは──AIエージェントに仕様駆動開発を強制するCLI
OpenSpecは「AIエージェントにいきなりコードを書かせず、先に仕様書を書かせる」ことに特化したCLIだ。読者の3つの疑問に沿って整理する。
・何ができるか：openspec initでプロジェクトにopenspec/ディレクトリを作り、AIエージェント（Claude Code・Cursor・Codexなど多数のツールに対応）が変更提案・設計・タスク分解をMarkdownファイルとして残せるようにする
・何を解決するか：チャットで都度指示するだけのAIコーディングでは、なぜその実装になったかの文脈がセッション終了後に消える。OpenSpecはopenspec/changes/に提案を残すことで、レビュー可能な状態を作る
・何を代替できるか：仕様駆動開発（spec-driven development）を手作業のNotion／Docsで管理している運用を、Gitリポジトリ内で完結させる形に置き換えられる
opsx:プレフィックスの新コマンド体系はREADMEで「rebuilt」と告知されている移行期の仕組みで、CHANGELOG.mdの存在は確認できたが内容は未読のため、旧ワークフローとの詳細な差分は本記事では扱わない。
仕組み：propose→apply→archiveの新ワークフロー
docs/opsx.mdによれば、OpenSpecの標準フローは3段階に分かれる。
変更提案を作成"] --> B["proposal.md
design.md
tasks.md"] B --> C["/opsx:apply
提案どおりに実装"] C --> D["/opsx:archive
specsへ反映・履歴化"]
① 何ができる：提案→実装→アーカイブの3段階をディレクトリ構造として固定できる ② 何を解決する：AIエージェントが生成したコードの「なぜ」が残らない問題 ③ 何を代替する：手作業の仕様書管理・レビュープロセス
実測：インストールから起動確認まで（Linux x86_64）
READMEのインストール手順どおりにnpxで実行し、CLI単体で何が確認できるかを検証した。
npx @fission-ai/openspec@latest --version
# 1.13.2
npx @fission-ai/openspec@latest init . --tools none --no-animation --force
実行すると数秒でopenspec/ディレクトリが生成された。中身は次の3点のみで、proposal.mdやdesign.mdのような提案文書は生成されない。
| 生成物 | 内容 |
|---|---|
openspec/config.yaml |
スキーマ指定（schema: spec-driven）とプロジェクトコンテキストのコメントアウト済みテンプレート |
openspec/changes/archive/ |
完了した変更を格納する空ディレクトリ |
openspec/specs/ |
確定仕様を格納する空ディレクトリ（.gitkeepのみ） |
config.yamlの中身はコメントアウトされたテンプレートのみで、schema: spec-drivenという1行だけが有効な設定として残る。コメント部分には「project context（技術スタックや規約をAIに伝える）」「per-artifact rules（proposalやtasksごとのカスタムルール）」「per-operation guidance（apply/archive時のガイダンス）」の3種類の任意設定が例示されており、チームの規約をAIエージェントに読ませたい場合はここに追記する設計だとわかる。
続けてopenspec listを実行すると「No active changes found.」と表示され、openspec change --helpではshow/list/validateのサブコマンドが確認できた。brief内の想定どおり、/opsx:propose自体はClaude CodeなどAIエージェント内のスラッシュコマンドとして動く設計で、素のターミナルからproposal.mdを生成する手段は見つからなかった。CLI単体で確認できたのは「インストール可否」「ディレクトリ初期化」「状態確認コマンドの応答」までで、提案文書の生成品質はAIエージェント越しの操作が前提となるため本記事では未検証とする。
検証環境：Linux（x86_64）／Node.js経由のnpx実行／2026-09-26。確認したのは--version・init・list・change --help・store --helpの応答とディレクトリ生成の有無。opsx:proposeによるAIエージェント越しの提案生成フローは未検証。
openspec --helpが返すトップレベルのサブコマンドは20個以上ある。読者が実機で迷わないよう、実行して確認できた主要なものだけを抜き出す。
| サブコマンド | --help表示の説明 |
|---|---|
init |
Initialize OpenSpec in your project |
list |
List items (changes by default). Use --specs to list specs |
view |
Display an interactive dashboard of specs and changes |
change |
Manage OpenSpec change proposals |
archive |
Archive a completed change and update main specs |
spec |
Manage and view OpenSpec specifications |
store |
Create and manage stores（後述） |
doctor |
Report relationship health for the resolved OpenSpec root |
validate |
Validate changes and specs |
status |
Display artifact completion status for a change |
init時の--toolsオプションにはclaude・cursor・codex・gemini・kiroなど30種類近いAIツール名がカンマ区切りで指定でき、noneを渡すとツール固有の設定ファイルを生成せずディレクトリ構造だけを作れる（本記事の検証で使用したのはこのnone指定）。
Stores機能とチーム利用
openspec store --helpを実行すると、次のサブコマンドを持つ機能が確認できた。
・setup — Create and register a local store（新規のstoreを作成して登録）
・register — Register an existing local store（既存のOpenSpecリポジトリをstoreとして登録）
・unregister / remove — 登録解除のみ、または登録解除とローカルフォルダ削除まで行う
・list（ls） — List locally registered stores（登録済みstore一覧）
・doctor — Check local store registration and metadata（登録状態の健全性チェック）
READMEでは「Stores（beta）」として、チーム向けに独立したOpenSpecリポジトリをローカルマシンに複数登録・横断管理できる仕組みと説明されている。1台のマシンから複数プロジェクトのOpenSpec状態をまとめて見たいチーム向けの機能と推測できるが、商用マネージド版の記載は見当たらず、マネタイズ導線になり得るかは未確認のため推測を断定的には書かない。
Claude Code向けの周辺エコシステム（Skills・プラグイン）と組み合わせて使う運用を検討する場合は、Claude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説やclaude-plugins-community解説｜Anthropic公式プラグイン市場2,282件を中身から読むも参考になる。
OpenSpecと類似ツールの比較：spec-kit・cc-sddとの違い
仕様駆動開発（spec-driven development）を謳うツールは複数あり、OpenSpecはその1つに過ぎない。レイヤーごとの詳しい見分け方は前述の比較記事に譲り、ここでは主要な違いだけを表にまとめる。
| 項目 | OpenSpec | github/spec-kit | gotalab/cc-sdd |
|---|---|---|---|
| 開発元 | Fission-AI | GitHub公式 | 個人（日本発） |
| ライセンス | MIT | MIT | 既存記事で言及あり（詳細未確認） |
| 配布形態 | npmパッケージ@fission-ai/openspec |
CLI（specifyコマンド） |
npx導入 |
| ワークフロー | propose→apply→archive（opsx:系） |
specify→plan→tasks→implementの4フェーズ | Claude Code向けKiro風フロー |
| 対応エージェント | Claude Code・Cursor・Codexなど多数 | 30以上のエージェント対応 | 主にClaude Code |
star数はspec-kitが既存記事の2026-07-13時点実測で120,308（現在はさらに増加している可能性が高く、本記事では再確認していない）に対し、OpenSpecは約70,000（本記事執筆時点のWebFetch実測・概数）。単純な人気度ではspec-kitが上回るが、OpenSpecはopenspec/changes/というディレクトリ構造とStores機能でチーム運用に寄せている点が実装上の違いになる。
ライセンスと採用判断
LICENSEファイル原文は「MIT License / Copyright (c) 2024 OpenSpec Contributors」で、READMEのバッジ表記「License: MIT」とも一致している。商用利用・改変・再配布の制限はない。
一方でREADME冒頭には「新しいワークフローに作り直した」旨の告知があり、opsx:という新コマンド体系への移行期にある。README_OLD.mdの存在は確認できたが内容は未読で、旧ワークフローとの互換性・移行手順は本記事執筆時点では確認していない。バス係数（開発者の集中度）についても、README上で目立つのは開発者と見られる@0xTabのみで、正確な貢献者数・企業か個人主導かは未確認のまま採用判断の材料にはできない。
実体面では、git clone --depth 1実測で最終コミットが2026-09-23（クローン時点の前日付近）、総コミット数はGitHub表示値で913件、TypeScriptによる実ソース（bin/・src/・schemas/構成）、テスト設定（vitest.config.ts）、GitHub Actions のCIバッジが揃っており、star数だけが先行した「実体の薄いOSS」ではなく開発が継続しているプロダクトだと確認できた。npm配布は@fission-ai/openspecパッケージで行われており、@latestタグを実行するとv1.13.2が取得できることも今回の実機確認で裏付けられている。
まとめ
OpenSpecは、AIコーディングエージェントに仕様書を先に書かせるための軽量なディレクトリ規約とCLIだ。CLI単体で確認できたのはinitによるディレクトリ生成と状態確認コマンドまでで、opsx:proposeが作る提案文書の中身はAIエージェント越しの操作が前提になる。仕様駆動開発を試したいがエージェント環境を選ばない仕組みを探しているなら候補になるが、opsx:系ワークフローへの移行期にある点は踏まえておきたい。
・待った方がよい人：ターミナル単体で仕様書生成まで完結させたい人、移行期のツールの安定性を懸念する人
参照ソース
・Fission-AI/OpenSpec（公式リポジトリ・README） — 使い方・ライセンス・star/fork数を確認（2026-09-26時点）
・OpenSpec docs/opsx.md（新ワークフロー仕様） — propose/apply/archiveの詳細を確認
・Fission-AI/OpenSpec Issues — Stores機能等のフィードバック状況を確認
