はじめに
株式会社ネクストスケープ Chief Technology Office所属の小野塚です。
今回紹介したいのはOpenSpecという「仕様駆動開発（SDD）」のためのOSSフレームワークです。
AIコーディングツール上で動くスラッシュコマンドで、コードを書く前に仕様を生成・管理できるという点では他のフレームワークと同じなのですが、「Delta Spec」という差分管理の仕組みが非常に興味深いといいますか、「使える」機能ではないかと思いますので実際に試してみた結果を紹介しつつご紹介します。
インストール
OpenSpecはNode.js 20.19.0以上が必要です。以下のコマンドでインストールします。
npm install -g @fission-ai/openspec@latest
更に以下のコマンドで初期化を行うのですが、この時に使用するツールを選択します。今回はClaude Codeでいきます。
openspec init
あとはopenspec/config.yamlというファイルがありますので以下の内容で上書きしておきます。これは言語やフォーマットを制御する設定ファイルで、必ずしも設定する必要は無いのですが、出力結果が安定しますので今回は設定した上で作業を進めます。
ーーー
schema: spec-driven
context: |
プロジェクト: todo-cli（CLIベースのTodoアプリ）
Tech stack: Node.js, TypeScript, ts-node
実行方法: npx ts-node src/index.ts <command> [args]
言語: 日本語で全ての成果物（proposal, spec, design, tasks）を記述すること
rules:
specs:
- ScenarioはGiven/When/Then形式で記述
- REMOVEDには必ずReasonとMigrationを含める
proposal:
- 影響範囲を明示する
tasks:
- タスクは実装可能な粒度に分割する
ーーー
編集が終わったら、Claude Codeを再起動してください。
実装開始・フォルダ構造説明
この時点での仕様に関するフォルダ構造は以下のようになります（コードの部分は除きます）。
├── specs/ ← 空（確定仕様の置き場）
├── changes/ ← 空（作業中changeの置き場）
└── config.yaml
OpenSpecの基本サイクル
OpenSpecは基本的に propose → apply → archive という3ステップ、3つのコマンドで実装を進めていきます。
まずはpropose 、計画を立てるところから。
Claude Codeで以下のように指示を出します。
ーーー
/opsx:propose add-basic-todo
CLIベースのTodoアプリの基本機能を実装する。
- `todo add "タスク名"` でタスク追加（自動でID付与）
- `todo list` で一覧表示（ID、ステータス、タスク名）
- `todo done <id>` で完了にする
- `todo delete <id>` で削除
- データはローカルの data/todos.json に保存
ーーー
このproposeを実行した後のフォルダの状態は以下のようになります。
openspec/
├── specs/ ← まだ空
├── changes/
│ └── add-basic-todo/ ← ★ 生成された
│ ├── proposal.md ← なぜ・何を作るか
│ ├── design.md ← どう作るか
│ ├── tasks.md ← 実装チェックリスト
│ └── specs/
│ └── task-management/
│ └── spec.md ← ★ Delta Specを記載
計画書は `changes/` の中に作られます。specs/配下はまだ空のままです。
Delta Specの中身を見てみましょう。
ーーー
## ADDED Requirements
### Requirement: タスクの追加
システムはSHALL `todo add "タスク名"` コマンドを受け付け、
自動採番されたIDを付与して新しいタスクを `data/todos.json` に保存しなければならない。
#### Scenario: タスクを追加する
- WHEN ユーザーが `todo add "買い物"` を実行する
- THEN IDが自動採番されたタスクが追加され、確認メッセージが表示される
### Requirement: タスクの一覧表示
（...省略...）
### Requirement: タスクの完了
（...省略...）
### Requirement: タスクの削除
（...省略...）
ーーー
すべてが `## ADDED Requirements` の下にありますが、既存の確定仕様がまだ空なので、すべてが「新規追加」になるわけです。
ここで 「Delta Spec」という概念を整理します。Delta Specとは 「確定仕様からの変更点だけ」を書いたもので、3種類の目印があります。
・ADDED：新しく追加する要件
・MODIFIED：既存の要件を変更する
・REMOVED： 既存の要件を廃止する
AIがtasks.mdに沿ってコードを実装します（src/配下にファイルが生成される）。
この時点でもspecs/はまだ空です。
/opsx:archive add-basic-todo
archive後のフォルダ構成は以下のようになります。
ーーー
openspec/
├── specs/
│ └── task-management/
│ └── spec.md ← ★ 確定仕様が生成
├── changes/
│ └── archive/
│ └── 2026-05-04-add-basic-todo/ ← 作業記録として保存
ーーー
変更内容としては以下の２つになります。
1. specs/配下に確定仕様が作られる— Delta Specから `## ADDED Requirements` のヘッダーが外れ、「今のアプリはこう動く」という確定仕様になった
2. changes/の作業フォルダがarchive/に移動した — 「いつ・何を・なぜ変えたか」の記録が残る
2度目の改修
次に２度目の改修を実施します。優先度追加 + deleteを廃止します。
以下のようにadd-priority-and-refactorという名前でproposeコマンドを実行します。細かい指示内容は割愛させてください。
/opsx:propose add-priority-and-refactor
AIはChange 1の確定仕様（openspec/specs/task-management/spec.md）を読んだ上で、Delta Specを生成します。
実際に試していただき、MODIFIEDやREMOVEDが存在することを確認してみてください。
そして実装、アーカイブを行います。
/opsx:apply add-priority-and-refactor
/opsx:archive add-priority-and-refactor
archive後のフォルダは以下のようになります。
ーーー
openspec/
├── specs/
│ └── task-management/
│ └── spec.md ← 最新の確定仕様
├── changes/
│ └── archive/
│ ├── 2026-05-04-add-basic-todo/ ← 1回目の変更の記録
│ └── 2026-05-04-add-priority-and-refactor/ ← 2回目の変更の記録
ーーー
実際のファイルエクスプローラーでは以下の通り。
archive後の確定仕様はどうなったかを最初の変更での確定仕様（4つのRequirement）と比較しながら説明すると、
・タスクの追加 ：MODIFIED → 優先度オプションの記述を含む新しい全文に置き換わった
・タスクの一覧表示 ： MODIFIED → 優先度列・ソート・絞り込みの記述に置き換わった
・タスクの完了 ：変更なし → Delta Specに含まれなかったのでそのまま
・タスクの削除 ：REMOVED → 確定仕様から消えた
といった内容になります。
まとめ
改めてフォルダ構造の変化（全体像）を以下に記します。
ーーー
【init直後】 specs/ = 空 changes/ = 空
↓ propose
【1回目の変更】 specs/ = 空 changes/add-basic-todo/ = 計画書 + Delta Spec(全ADDED)
↓ apply (コード生成。specs/は変わらない)
↓ archive
【archive後】 specs/ = 確定仕様 changes/archive/ = Change 1の記録
↓ propose
【2回目の変更】 specs/ = そのまま changes/add-priority-and-refactor/ = Delta Spec(MODIFIED+REMOVED)
↓ apply (コード変更。specs/は変わらない)
↓ archive
【最終形】 specs/ = 最新仕様 changes/archive/ = Change 1 + Change 2の記録
specs/ が更新されるのタイミングはarchiveだけ。
ーーー
既存の確定仕様がないとMODIFIEDもREMOVEDも出しようがないので、1回目のchangeは全部ADDEDになり、2回目以降のchangeで初めてMODIFIED/REMOVEDが登場します。この「仕様が積み上がっていく」構造がDelta Specの核心です。
チーム開発ではどう使える？
proposeの段階でDelta Specが生成されるので、コードレビューの前に「仕様レビュー」を挟む運用ができます。「この変更でいいか？」をコードではなく仕様の単位で議論できます。
また、specs/が常に最新の確定仕様を保持しているので、途中からプロジェクトに参加したメンバーでも「今のアプリはどう動くか」をspecs/を読むだけで把握できます。archive/を遡れば「なぜこの仕様になったのか」の経緯も追えます。
今回触れなかった機能
OpenSpecにはcore profile以外にも多くのコマンドがあります。
/opsx:explore — アイデアの壁打ち。artifactは生成されない自由な対話モードで、要件が固まったらproposeに移行する
/opsx:verify — 実装と仕様のズレをAIがチェック。完全性（全タスク完了か）・正確性（仕様通りか）・一貫性（設計と実装が合っているか）の3軸で検証する
/opsx:new + /opsx:continue — proposeが4つのartifactを一括生成するのに対し、1つずつ段階的に生成して都度レビューできる
/opsx:onboard — 実際のコードベースを使ったインタラクティブなチュートリアル
これらは openspec config profile でexpandedプロファイルを有効にすると使えます。
所感
OpenSpecを一通り試してみて感じたのは、AIに「何を作るか」を伝える行為が、そのまま仕様書として残るという体験の良さです。これまでチャットで指示して実装させると、その指示内容は会話ログの中に埋もれてしまっていましたが、OpenSpecではspecsとして構造化されて蓄積されます。
一方で、生成されるspecの品質はAIモデルに依存します。Scenarioが不十分だったり、Requirementの粒度がばらつくこともあるので、proposeの後に人間が内容を確認・修正するステップは省略しない方がよいと感じました。
生成物がすべてMarkdownファイルである点も安心材料です。仮にOpenSpecを使わなくなっても、specs/のファイルは普通のドキュメントとして読めますし、Gitで差分管理もできます。ロックインのリスクがほぼないので、まずは小さなプロジェクトで試してみることをおすすめします。
最後に
当社ネクストスケープはこのように生成AIをはじめとした新しい技術・知識を日々取り入れており、Webサイト、スマホアプリ、Hololensアプリの開発をはじめ、CMSを利用したサイトの新規構築やリニューアルなど、お客様のニーズに幅広く対応いたします。お困りのことがございましたら、いつでもお気軽にお問い合わせください。
（以下当社お問合せフォーム）
当社では一緒に働いてくれる仲間を募集しています。是非以下のサイトよりお申込みください。
