こんにちは、ダックスフントです。
Github CopilotをはじめとするAIコーディングツールを使った開発にも、だいぶ慣れてきた方が多いかと思います。また、Planモードで実装計画を作り、Agentモードで実装する流れ（いわゆる仕様駆動開発）に取り組んでいる方もいると思います。
自分もこの進め方で開発しているのですが、比較的大きな変更でも耐えうる一方で、計画がチャット内の一時成果物になりやすく後から追跡しにくいことや、指示の粒度・その日のモデルの応答によって計画の品質がぶれやすいといった悩みが出てきました。
今回は、そんなときに役立つ選択肢としてOpenSpecを紹介します。OpenSpecはGitHub Copilotと全く別のものではなく、Copilotに追加して使えるスキル群のような位置づけです。導入すると、propose（計画作成）、apply（計画に沿った実装）、archive（完了した計画の保管）といったコマンドを使えるようになります。そのため、Copilotを使っている方でも普段の操作感を大きく変えずに、よりスムーズに開発を進められます。
自分はClaude CodeにOpenSpecを導入してみましたが、今回はその使用感を紹介しつつ、GitHub Copilotでも同様に導入できるため、その手順も紹介します。
この記事が、仕様駆動開発をあらためて見直すきっかけや、OpenSpec導入を検討するきっかけになればうれしいです。
目次
1. Plan → Agent 開発で感じた三つの課題
この節では、CopilotやClaude Codeなど複数のAIツールを使いながらPlan → Agent（自己流の仕様駆動開発）で開発してきた中で感じた課題を紹介します。
1-1. 計画が資産化されない
Planモードで生成した実装計画は、多くの場合チャットの会話内にとどまります。CursorやClaude Codeでは計画が一時ファイルとして出力されることもありますが、プロジェクトとは切り離された場所に保存されることが多く、後から見返しにくいのが実情でした。加えて、タスクごとに一時的な計画を作る運用になりやすく、最新の仕様を把握できるファイルが残りにくいという課題もありました。
結果として、「なぜその実装方針になったか」という意思決定の理由が残らず、特にチーム開発ではレビュー時や引き継ぎ時に改めて説明するコストが発生してしまいます。
1-2. 計画の品質が、質問の仕方やモデル、ツールに引っ張られる
同じ意図で指示を出しても、指示の粒度・その日の文脈・モデルの応答の揺れによって作成される計画ファイルの品質がばらつきます。Copilotの場合でも、プロンプトの書き方や会話コンテキストによって出力は変わります。
さらに、Copilot・Cursor・Claude Codeではそれぞれ効く指示の「癖」が異なります。Claude Codeはざっくりした指示でも広範囲のファイルを見つけ出して修正してくれますが、Cursorはかなり具体的に指示を書かないと局所的な修正やその場しのぎ的な修正をしてしまうことがありました。このようなことから、ツールごとに納得の行く計画が出力されるよう、試行錯誤を繰り返すのが手間に感じていました。
1-3. 複数ツール・複数メンバーで前提がずれる
Copilotがメジャーなツールであっても、チーム開発においては別のツールを併用する場面も発生します。チーム開発でメンバーごとに使用ツールが異なる場合、計画作成や実装においての「共通認識」がないと指示や手順の前提がずれやすくなります。
このようなずれがある状態では、開発速度を上げるためにAIツールを色々併用しても、ツール間の仕様の調整コストの方が大きくなってしまう問題が発生します。
2. OpenSpecとは何か
OpenSpecは、AIコーディングアシスタント向けの軽量な仕様駆動開発（SDD）フレームワークです。OSSとして公開されており（GitHub、執筆時点で46.7kスター）、APIキーやMCPサーバーの追加は不要です。最新版はv1.3.1（2026年4月リリース）で、30以上のAIツールに対応しています。
基本的な考え方は「コードを書く前に計画をレビューし、変更単位で仕様をリポジトリに残す」というシンプルなものです。OpenSpecをインストールすると、各AIツール向けのスキルファイルが自動配置され、この考え方を実現する専用コマンドが使用できるようになります。
なお、追加課金は発生しません。各AIツールの従来の利用料金だけで動作します。
2-1. 使用するコマンドは最低3種類
OpenSpecの基本コマンドはpropose / explore / apply / sync / archiveの5種です。ですが、従来のPlanモードで計画を作りAgentモードで実装する流れを再現するだけなら、propose → apply → archiveの3コマンドで十分です。覚えるコマンドが少ないため、導入初日から迷わずに使えます。
2-2. 新規だけでなく既存プロジェクトにも後から導入できる
OpenSpecの公式ドキュメントでは、思想としてbrownfield-first（既存コードベース前提）が明示されています。つまり「新規開発専用」ではなく、すでに動いている既存プロジェクトに後付けで導入することを前提に設計されています。
そのため、実際の導入もシンプルで、既存プロジェクトフォルダのルートでopenspec initを実行すれば、openspec/配下の仕様管理ディレクトリと、選択したAIツール向けのスキル/コマンドファイルが追加されます。既存アプリを作り直したり、MCPサーバーを追加したりする必要はありません。既存の開発フローに「仕様を変更単位で残すレイヤー」を重ねるイメージで導入できます。
2-3. 変更単位で仕様と設計が残る
propose コマンドを実行すると、openspec/changes/<作業名>/ 配下に以下の 4 種の計画ファイルが自動生成されます。
| ファイル | 役割 |
|---|---|
proposal.md |
変更提案。「何を・なぜ・どの範囲で・どう解決するか」を定義する |
specs/ |
仕様。機能要件・シナリオ・受け入れ条件などを記述する |
design.md |
技術設計。アーキテクチャや実装方針の詳細を記述する |
tasks.md |
タスク一覧。チェックボックス形式で実装の進捗を管理する |
archive コマンドを実行すると、計画ファイルは openspec/changes/archive/YYYY-MM-DD-<作業名>/ に日付付きで保存されます。「あの変更のときに何を考えていたか」を後から追いやすい形でプロジェクトフォルダに残すことで、仕様が資産化されます。また sync コマンドを実行すると、最新仕様を openspec/specs/（マスターとなる設計書類） に反映することができ、仕様と実装の乖離を減らせます。
2-4. 複数ツールに対応しロックインを下げられる
OpenSpecが特徴的なのは、インストール時に、使用するAIツール向けのスキル・コマンドファイルをプロジェクト内に展開する設計になっている点です。GitHub CopilotやClaude Code、Cursorなど各ツール専用のファイルが自動配置され、それぞれのUIに合わせた呼び出し方でOpenSpecの機能が使えるようになります。たとえばコマンドの表記はCopilotだと/opsx-propose、Claude Codeだと/opsx:proposeのように異なりますが、実際に行う操作はどちらも「計画作成（propose）→実装（apply）→アーカイブ（archive）」で共通です。
この「呼び出し方は違っても、実行するコマンドの意味と成果物は共通」という性質により、開発プロセスのロックインを下げられます。具体的には、次のような効果があります。
- ツールを切り替えても、同じ順序（propose→apply→archive）で開発を進められる
- 生成される計画ファイル（proposal.md / specs / design.md / tasks.md）の構造が共通なので、レビュー観点をそろえやすい
- メンバーごとに利用ツールが異なるチームでも、変更管理の運用を一本化しやすい
対応ツールはGitHub Copilot・Claude Code・Cursor・Amazon Q Developer・Cline・Windsurfなど30以上に及びます（対応ツール一覧）。まずはCopilotで始めて、必要に応じて他ツールへ広げても、「どのツールでも同じ進め方で開発できる」状態を維持しやすいのが魅力です。
3. OpenSpecを実際に使ってみて
3-1. 導入初日の実感
自分は、Claude Codeに導入してみました。インストールはnpm install -g @fission-ai/openspec@latestとopenspec initの2ステップで完了しました。また、実際に開発する際に覚えるべきコマンドの数が少ないので、操作に慣れるまでほとんど時間がかかりませんでした。
proposeコマンドを実行すると、要件を2〜3行で伝えるだけで、現在のプロジェクトファイルを考慮しながら、かなり品質の高い計画ファイルを生成してくれました。またチャットで計画に対する追加/修正要望を依頼するとそれに応じて計画のブラッシュアップもしてくれました。計画の内容に問題無ければapplyコマンドを実行することで実装が開始されます。実装中はtasks.mdのチェックボックスが実装中にリアルタイムで更新されるため、「エージェントが今何に取り組んでいるか」が一目でわかりました。
このようなことから小規模なプロジェクトでしたが1日に5つの機能実装/改修をさくさく完了できました。ブラッシュアップされた計画を元に実装/改修されたコードについては、ほとんど手での修正を行う必要がありませんでした。
これはClaude Codeだけかもしれませんが、
tasks.mdに「成果物の動作確認を行うこと」と記載しておくと、エージェントが実装だけでなく動作確認まで自律的に実行してくれました。今回はDockerコンテナ内で動くPythonファイルを実装してもらいましたが、エージェントがDockerコンテナ上でファイルを実行して、実行結果や速度まで提示してくれました。Copilotでは未検証ですが、同様のことが実現できるかもしれません。
3-2. 後から見返せる設計が残る
全タスクが完了して動作確認が取れたら、archiveコマンドを実行するだけです。計画ファイル一式が、作業名・目的・変更内容が揃った統一フォーマットでプロジェクトフォルダに保存されます。
ツール固有の一時ファイルではなく、プロジェクトの変更履歴として残るため、後から見返しやすくなります。加えて、アーカイブ時には仕様の差分がopenspec/specs/（最新仕様のマスターファイル）側にも反映されるため、変更の経緯だけでなく「現時点の最新仕様」が追いやすくなりました。
3-3. ツールに依存しない共通の開発スタイルを確立しやすい
1人で複数のAIツールを併用しているケースでも、メンバーごとに使っているツールが異なるチーム開発でも、共通化されたOpenSpecのコマンドを起点に進められるため、開発の進め方をそろえやすいと感じました。
3-4. トークン消費量が増加する
OpenSpec導入後に気になった点として、トークン消費量が増えたことが挙げられます。体感ではありますが、従来のPlan → Agent開発と比較して、トークン消費量が約1.5倍～2倍に増加したと感じています。特に、計画作成時におけるトークン消費量が増加したように感じます。
トークン消費量の増加をなるべく抑えるため、自分は以下のような対策を心掛けています。
- 各コマンド（
propose,apply,archive）は、必ずチャットをクリア（/clearコマンドを実行）してから実行 -
applyコマンドで実装した後に、修正したい部分がある場合、修正を行う上で過去のチャット履歴も必要でない限りは、チャットをクリアしてからapplyコマンドを再度実行
トークン消費量が増加する理由は、OpenSpecが複数のファイルを生成・管理する仕組みにあると考えられます。proposeコマンド実行時にproposal.md、specs/（複数ファイル）、design.md、tasks.mdの4種が生成され、その後apply実行時にこれらの計画ファイルすべてがAIに入力されます。計画ファイルが増えると、エージェントがそれらを参照・更新する過程でトークンが消費されるため、従来のシンプルなプロンプト単体の実行よりも、確実にトークン量が増えていると感じました。
一方で、品質の高い計画が作成されるため、実装時の手戻りが減ります。また、変更履歴がプロジェクトフォルダに蓄積されるので、後から仕様を見返しやすくなります。プロジェクトへの導入を検討される際は、こうした開発効率とメンテナンス性の向上に対して、トークン消費量のバランスが見合っているかを考慮されると良いか思います。
4. 類似ツールとの比較
OpenSpec以外にも、仕様駆動開発を支援するツールがいくつか存在します。ここでは代表的なSpec Kit、Kiro、cc-sddを紹介します。
| 観点 | OpenSpec | Spec Kit | Kiro | cc-sdd |
|---|---|---|---|---|
| 位置づけ | OSSの仕様駆動開発フレームワーク | GitHub公式のOSS仕様駆動開発フレームワーク | AWS公式の仕様駆動開発ツール（専用エディタやCLIから利用可能） | KiroにインスパイアされたOSSの仕様駆動開発フレームワーク（17スキル搭載） |
| 実行方式 | 既存エージェントへスキル/コマンドを配布 | 既存エージェントへスキル/コマンドを配布 | Kiro専用環境を設定 | 既存エージェントへスキル/コマンドを配布 |
| 対応ツール | 30以上（Copilot・Claude Code・Cursor等） | 30以上（Copilot・Claude Code・Cursor・Gemini CLI等） | Kiro専用ツール（Web, エディタ, CLI）。モデルはKiro提供の選択肢から選んで利用する。 | 8ツール（Claude Code・Codexは安定版、Copilot・Cursor等はベータ版） |
| 料金 | OSS（実行モデル費は別） | OSS（実行モデル費は別） | 無料枠あり（月50クレジット）、Pro $20/月〜 | OSS（実行モデル費は別） |
Spec KitはGitHubが公式に公開しているSDDツールキットです（github/spec-kit、執筆時点で95.4kスター）。/speckit.constitution（プロジェクト原則の定義）、/speckit.specify（要件仕様）、/speckit.plan（技術計画）、/speckit.tasks（タスク生成）、/speckit.implement（実装）の5コマンドでSDDフローを回せます。30以上のAIツールをサポートしており、MITライセンスのため無料で利用できます。
Kiroは独自の開発環境（IDE + CLI）で仕様駆動開発を一体的に体験できる製品です（Kiro 公式）。無料枠（月50クレジット）から試せますが、Proプランは月$20〜です。既存のCopilot運用に追加導入するというものではなく、専用の開発環境（IDE + CLI）への移行が前提になります。
cc-sddは複数のAIツールに対応した17スキル搭載の軽量SDDテンプレートです（gotalab/cc-sdd）。Claude Code・Codexは安定版、GitHub Copilot・Cursor・Windsurf等はベータ版として対応しており、各ツールで同一の17スキルセットを利用できます。
すでにCopilotを利用している場合に、仕様駆動開発フレームワークを導入したいという時は、OpenSpecやSpec Kitあたりが候補になると考えられます。
5. OpenSpecの導入手順
5-1. インストール
前提としてNode.jsがインストール済みであることを確認してください。
# 1. OpenSpec CLI をグローバルインストール
npm install -g @fission-ai/openspec@latest
# 2. 対象プロジェクトのルートで初期化
openspec init
openspec initを実行すると、使用するAIツールを選択する画面が表示されます。選択したツール向けのスキル・コマンドファイルが、以下のパスに自動展開されます。
GitHub Copilotの場合:
- スキルファイル：
.github/skills/openspec-*/SKILL.md - コマンドファイル：
.github/prompts/opsx-<id>.prompt.md
Claude Codeの場合:
- スキルファイル：
.claude/skills/openspec-*/SKILL.md - コマンドファイル：
.claude/commands/opsx/<id>.md
これらのファイルはMarkdown形式で記載されており、人間が読める内容です。ファイルの中身は自由に参照・編集できるため、プロジェクトのニーズに合わせてカスタマイズすることも可能です。
5-2. OpenSpecで仕様駆動開発する場合の流れ
OpenSpec導入済みのCopilotにおいて、最小限のコマンドで仕様駆動開発を実施する場合の流れを紹介します。
補足: Claude Codeではコマンドがコロン区切り（
/opsx:proposeなど）になります。
ステップ 1 — 変更作業を作成する（propose）
まずは、以下の内容をGitHub Copilotのチャットに入力します。
/opsx-propose OAuth 認証機能を追加したい
要求は2〜3行程度の短い文でも構いません。必要に応じてエージェントが不足情報を質問してくれるため、それに答えながら計画を具体化できます。実行後はopenspec/changes/<作業名>/配下にproposal.md、specs/、design.md、tasks.mdの4種が生成されます。これらのファイルはCopilotやClaude Code、Cursorなど、どの対応ツールから実行しても同じ形式で生成されるため、内容を確認しやすいのも利点です。
Claude Codeの場合は以下の形式でチャットを入力してください。
/opsx:propose OAuth 認証機能を追加したい
ステップ 2 — 計画ファイルを目視確認する
生成されたファイルを確認し、認識の齟齬がないかチェックします。気になる点はチャットで指摘すれば修正してくれます。
ステップ 3 — 実装してもらう（apply）
次に、以下の内容をGitHub Copilotのチャットに入力します。
/opsx-apply
実装の進捗はtasks.mdのチェックボックスがリアルタイムで更新されていくので、それで確認できます。進行中の変更作業が複数ある場合（changesフォルダに複数の計画ファイルがある場合）は/opsx-apply <作業名>のように作業名を明示してください。
Claude Codeの場合は以下の形式でチャットを入力してください。
/opsx:applyまた、Claude Codeでは、
tasks.mdに「成果物の動作確認を行うこと」旨の記載があると、実装後にエージェントが自律的に動作確認まで進めてくれました。Copilotでは未検証ですが、同様の対応をしてくれる可能性があります。
ステップ 4 — 成果物を確認する
実装が完了したら、自分でも動作を確認します。エージェントが自律的に動作確認を実施していた場合も、念のため手元で確かめておくと安心です。問題があればチャットで修正指示を出すか、追加要望を添えてapplyを再実行してください。
/opsx-apply エラーハンドリングも追加してほしい
Claude Codeの場合は以下の形式でチャットを入力してください。
/opsx:apply エラーハンドリングも追加してほしい
ステップ 5 — アーカイブする（archive）
成果物の確認が取れたら、以下の内容をGitHub Copilotのチャットに入力します。
/opsx-archive
変更分の内容が、openspec/specs/（マスターとなる設計書類）に反映されていない場合は、同期するか確認されます（そのままarchive実行時に一緒に処理することも可能）。アーカイブ後、計画ファイルはopenspec/changes/archive/YYYY-MM-DD-<作業名>/に日付付きで保存されます。
Claude Codeの場合は以下の形式でチャットを入力してください。
/opsx:archive
6. まとめ
- CopilotやClaude Codeで標準的に使えるPlanモード → Agentモードを使った仕様駆動開発は便利ですが、作成した計画が使い捨てになりやすく後から追跡しにくいことや、指示の出し方やモデルのその日の応答によって計画の品質にばらつきが生じることが課題です
- OpenSpecはこれらの課題に対処する選択肢の一つとなるOSSの仕様駆動開発フレームワークです。
propose → apply → archiveの3コマンドで、変更単位の仕様と設計をプロジェクトフォルダに蓄積できます - GitHub Copilotを含む30以上のAIツールをサポートしており、すでにCopilotを利用している場合は既存のCopilotに対する機能拡張として導入できます（追加課金不要）
- ツールごとに指示を書き替える負担が、OpenSpecで共通化された機能によって軽減されます（AIツールを併用していたり、メンバーごとに使用ツールが異なるチームで特に有効）
- チーム開発ではコード差分と仕様差分を同時に共有でき、レビューや引き継ぎのコスト削減が期待できます
- 複数の計画ファイルを生成・参照する仕組み上、従来のPlan → Agent開発と比べてトークン消費量が増える点には注意が必要です。手戻り削減やメンテナンス性向上によって回収できるかを見ながら、プロジェクトへの適用を判断するのが現実的です
- まずは小さな変更1つを
propose → apply → archiveで完走してみるのが、感触をつかむのが良いかと思います。
参考
- OpenSpec 公式サイト
- OpenSpec GitHub（Fission-AI/OpenSpec） — v1.3.1、46.7kスター（2026年5月時点）
- OpenSpec コマンドリファレンス
- OpenSpec Concepts（brownfield-first の説明）
- OpenSpec CLI リファレンス（
openspec initの仕様） - OpenSpec 対応ツール一覧
- OpenSpec OPSX ワークフロー
- Kiro 公式サイト
- Kiro 料金プラン
- Spec Kit GitHub（github/spec-kit） — v0.8.7、95.4kスター（2026年5月時点）
- Spec Kit 紹介ブログ（GitHub Blog）
- cc-sdd GitHub（gotalab/cc-sdd）