🐬

Claude Code と OpenSpec を採用した仕様駆動開発の流れ（2026年2月版）

に公開
AI
Claude
仕様駆動開発
openspec
tech

昨年後半から AIコーディングエージェントとして Claude Code を使い始め、OpenSpec を採用した仕様駆動開発(Spec Driven Development)を実践してきた。
2026年1月現在の私の開発スタイルをまとめておく。

使用ツール・技術

  • Claude Code (CC と略す)

    • メインの AI コーディングエージェント
    • モデルは Opus 4.5
    • 私との対話、兼、サブエージェント群とのオーケストレーションを担当
    • VSCode の拡張機能を使っている（CLI直もたまに使う）

  • GitHub Copilot (Copilot CLI)

    • モデルは OpenAI GPT-5.1-Codex, GPT-5.2-Codex, Gemini 3 Pro などを使用
    • 仕様レビューやコードレビューを担当

  • OpenSpec

    • 仕様駆動開発(SDD)フレームワークの一つ
    • 既存プロジェクトに導入しやすいとされる
    • 一つの仕様は主にproposal.md, spec(s).md, tasks.md で構成される
    • プロンプトを少しカスタマイズして使っている
      • change_id と backlog の課題キーを同期させるように
      • v1.0 は未だ使っていない

  • Chrome DevTools MCP

    • E2E テストで AIエージェントが使用する

  • Typora または VSCode

    • Markdown ビューア・エディタ
    • 私が plam.md や proposal.md, spec.md などのレビューや軽微な手直しに使用。

  • Backlog または GitHub

    • 課題管理システムと Git リポジトリ
    • 会社では Backlog を、個人では GitHub を使用

AI開発チームを構成するエージェント達と彼らが持つスキル

システム開発の各フェーズに必要なノウハウをスキル（Agent Skills）として定義し、それを(サブ)エージェントと紐付け、エージェントを同僚（部下）のようにみなしてチームで実務にあたるイメージを持たせている。

エージェント間はコンテキストを共有せず、SsoT(Single source of truth
) である OpenSpec の文書（と参考資料である plan.md）、そして実装されたコードやレビュー報告書のみで情報交換する。

  • 私（人間）
    • a のオーケストレータと対話し、「やりたい事」を入念に計画する
    • b-h の作業の様子には関知しない
    • 成果物であるコードや、その挙動の最終的なレビューやテストを行い、結果に責任を持つ
  • a. オーケストレータ
    • 所持スキル: openspec, openspec-workflow, backlog, github
    • 私との対話、b〜f のエージェント群への指示系統担当。
  • b. openspec-designer（仕様設計担当）
    • 所持スキル: openspec-design
    • plan を元に openspec の proposal.md, spec(s).md, tasks.md を作成
  • c. openspec-reviewer（仕様レビュー担当）
    • Copilot CLI を呼び出す
    • 所持スキル: openspec-review
    • レビューを実施。フォーマット検証、整合性チェック、シナリオの網羅性を確認し、結果を reviews/ に出力
  • d. openspec-applier（実装担当）
    • 所持スキル: openspec-apply
    • 承認済みの仕様に基づいてコードを実装
    • tasks.md に従い、ビルドが通る状態にする
  • e. openspec-code-reviewer（コードレビュー担当）
    • Copilot CLI を呼び出す
    • 所持スキル: openspec-code-review
    • 実装コードが仕様を満たしているかレビュー
    • spec との乖離を検出し、結果を code-reviews/ に出力
  • f. openspec-tester（テスト担当）
    • 所持スキル: openspec-test
    • Chrome DevTools MCP を使って実際に動作検証
    • コードレビューのみでの PASS は禁止。実際の操作で検証する

現在の開発フロー

全体の流れを示す。

Phase 1: 起票

私が Backlog に「○○を△△△したい」などと「やりたいこと」を簡単に起票する。課題キー（例: ABC-001）が採番される。
このプロセスで重要なのは「ユニークな課題キーの採番」であって、記述内容は正直どうでもよい（ソースコード側との二重管理になるので）。

Phase 2: 壁打ち

私が Claude Code の Plan モードで「ABC-001 を実施したい」と依頼する。CC は Backlog から課題を読み込み、ソースコードやドキュメントを分析して計画を提示する。私は CC の質問に答えたり、計画に指摘を行い、綿密なものにしていく。計画が固まったら、CC が Plan を Backlog の課題に記入する。

Phase 3: 仕様作成

私が「仕様作成からテストまで行って」と依頼。CC はサブエージェント openspec-designer に plan を提示し、以下を作成させる：

  • proposal.md - 提案概要
  • spec.md - 詳細仕様
  • tasks.md - 実装タスク
  • references/plan.md - 元プラン（保存用）

Phase 4: 仕様レビュー

CC が openspec-reviewer に仕様レビューを依頼。Copilot CLI を使ってレビューを実施。FAIL なら openspec-designer に修正を依頼し、PASS するまで最大10回繰り返す。

Phase 5: 実装

CC が openspec-applier に実装を依頼。仕様に基づいてコードを実装する。

Phase 6: コードレビュー

CC が openspec-code-reviewer にコードレビューを依頼。実装コードと仕様の整合性をレビュー。FAIL なら openspec-applier に修正を指示し、PASS するまで最大10回繰り返す。

Phase 7: テスト

CC が openspec-tester にテストを依頼。単体テストや E2E テストを実施。FAIL なら openspec-applier に修正を指示し、PASS するまで最大10回繰り返す。

Phase 8: PR 作成

全てのテストが PASS したら、CC が Backlog の git でプルリクエストを作成する。

Phase 9: 最終確認

私が PR のコードレビューと動作テストを行い、問題なければマージする。

現在のスタイルでの課題

1. 条件を整えるまでの時間

いわゆる「お膳立て」に時間がかかる。
できるだけプロジェクトをまたいでも共通なエージェント・スキルとして作成しているが、プロジェクト固有の情報やルールはそれなりに多いので、横展は簡単では無い。

2. 「仕様化」の粒度

「やりたいことを起票」から始まっているが、その粒度は人間（私）の能力に依存する。
たとえば、「顧客管理システムをゼロから開発する」場合、（AI と対話しながら）必要な要件を洗い出し、現在の AI に投げても大丈夫なレベルまで細分化するのは私だからできることであり、それを AI に任せるまでには至っていない。
結局、ITシステム開発において、機能設計以前に行うべき事もたくさんあって、次第にそちらが注目されていくのだろう。

3. 各エージェントのスキル向上

AI が提示してきた計画について、毎回問う事がある。
「API や DB の仕様を変更しないよね？」「類似の機能も修正すべきでは？」「下位互換性は担保される（されない）べき？」など。
これらは、定型のレビュー事項として、 openspec-reviewer が確認、指摘すればよいと思う。
このように、各エージェントが行うべき事はまだありそう。

4. AI との対話、AI の成果物のレビューを効率よく行えるツール

typora は「マークダウンエディタ」であり、 VSCode は「ソースコードエディタ」だ。
GitHub や Backlog のプルリクエスト機能もコードレベルでのレビューツールであり、AI が書いたコードを行レベルで検査することには意味を感じない。
いずれも「AI 時代のツール」という感じはしない。

要件定義や設計の時点では、ホワイトボードを前に人と人が議論するような、AI との壁打ちの様子がリアルタイムに視覚化されるようなツールが欲しい。
成果物のレビューでは、AIがテストしたエビデンスがあり、実行環境もあり、その成果について問えるようなツールがあると良さそう。

Cursor や Antigravity がそれに近いのかも知れないが、まだ「プログラマー寄り」な印象も受ける。

まとめ

「AIエージェントに Claude Code を使っている」、「仕様駆動開発に OpenSpec を使っている」などの局所要素はあまり重要でなく、AIによるチームビルディングが重要になってきそう。
今回のチームは決まったタスクを順次実施していくだけの単純なものだが、業務に応じて複雑なフローを行うAIチームを構築できる能力を身につけたい。

設計8割、実装2割

KDDI系が仕様駆動開発を採用、AIで業務は「設計8割・開発2割」に | 日経クロステック（xTECH）

これは上記ニュース記事の受け売りだが、概ね同意。私のフローに照らし合わせると、

  • Phase1 〜 3 - アイデアの起票から、AI と壁打ちして Plan を詰める
  • Phase9 - AI の成果物の品質を担保する

が「8割」に相当する。
コードを書くことは「99% 無い」けれど、具体的な箇所まで指示して修正させるのはほぼコードを書いているのと同じなので妥当かな。

OpenSpec は、SDDフレームワークは必要か？

Plan モードや Swarms など、AIエージェントの標準機能として SDD ライクなものが搭載されたり、自動オーケストレーション＆ロングランが可能になってきている中で、仕様駆動開発フレームワークはどのような立ち位置となるか？

他の FW は知らないが OpenSpec で言えば、「ITシステム開発目的で統一された様式」である事に価値があると思う。
Plan モードが出力する計画には行いたいことが詳細に書かれているが、Claude Code が（派生アプリである Claude Cowork にも代表されるように）プログラミング／ITシステム開発以外の用途でも使用されるようになることを考えると、plan.md は「汎用のフリーフォーマット」であり、システム開発に特化した何らかのフォーマットが決まっていた方が、人間にも、AI にも都合が良いと思う。

また、SDDフレームワークが提供する「仕様化」「タスク化」「レビュー」などの機能は、それなりに多くの知見の素に作られているはずなので、それに「乗っかって」おけば概ね正解だろう。

半年、1年後にはどうなってるのか分からないので、「可搬性の高いAI開発チーム」を維持していこうと思う。

おまけ

(サブ)エージェントと Skills

本命は Agent2Agent であり、Skills は過渡期の仕様かなと思う。
本稿に登場したエージェントも、基本は各々が専門のスキルを持つのみであり、Skills 化せずエージェントのプロンプトにそれを記述すれば良いことが多い。
「賢者である XXXさんは "魔法使いスキル" と "僧侶スキル" を両方持っている」みたいなスキルの組合せとその管理のために存在し続けるかも知れないけど、基本は「餅は餅屋」、「設計の専門家である Aさん」「実装のスペシャリスト Bさん」と考えた方が分かりやすいと思う。
Skills のマーケットよりは Agent のマーケット（人身売買？）、あるいは Agent の利用権販売、SaaS から AaaS(AI/Agent? as a Service) みたくなっていくのかな？と。

Discussion