昨年後半から AIコーディングエージェントとして Claude Code を使い始め、OpenSpec を採用した仕様駆動開発(Spec Driven Development)を実践してきた。 2026年1月現在の私の開発スタイルをまとめておく。
Claude Code (CC と略す)
GitHub Copilot (Copilot CLI)
proposal.md, spec(s).md, tasks.md で構成されるplam.md や proposal.md, spec.md などのレビューや軽微な手直しに使用。システム開発の各フェーズに必要なノウハウをスキル(Agent Skills)として定義し、それを(サブ)エージェントと紐付け、エージェントを同僚(部下)のようにみなしてチームで実務にあたるイメージを持たせている。
エージェント間はコンテキストを共有せず、SsoT(Single source of truth ) である OpenSpec の文書(と参考資料である plan.md)、そして実装されたコードやレビュー報告書のみで情報交換する。
proposal.md, spec(s).md, tasks.md を作成全体の流れを示す。

私が Backlog に「○○を△△△したい」などと「やりたいこと」を簡単に起票する。課題キー(例: ABC-001)が採番される。
私が Claude Code の Plan モードで「ABC-001 を実施したい」と依頼する。CC は Backlog から課題を読み込み、ソースコードやドキュメントを分析して計画を提示する。私は CC の質問に答えたり、計画に指摘を行い、綿密なものにしていく。計画が固まったら、CC が Plan を Backlog の課題に記入する。
私が「仕様作成からテストまで行って」と依頼。CC はサブエージェント openspec-designer に plan を提示し、以下を作成させる:
proposal.md - 提案概要spec.md - 詳細仕様tasks.md - 実装タスクreferences/plan.md - 元プラン(保存用)CC が openspec-reviewer に仕様レビューを依頼。Copilot CLI を使ってレビューを実施。FAIL なら openspec-designer に修正を依頼し、PASS するまで最大10回繰り返す。
CC が openspec-applier に実装を依頼。仕様に基づいてコードを実装する。
CC が openspec-code-reviewer にコードレビューを依頼。実装コードと仕様の整合性をレビュー。FAIL なら openspec-applier に修正を指示し、PASS するまで最大10回繰り返す。
CC が openspec-tester にテストを依頼。単体テストや E2E テストを実施。FAIL なら openspec-applier に修正を指示し、PASS するまで最大10回繰り返す。
全てのテストが PASS したら、CC が Backlog の git でプルリクエストを作成する。
私が PR のコードレビューと動作テストを行い、問題なければマージする。
いわゆる「お膳立て」に時間がかかる。 できるだけプロジェクトをまたいでも共通なエージェント・スキルとして作成しているが、プロジェクト固有の情報やルールはそれなりに多いので、横展は簡単では無い。
「やりたいことを起票」から始まっているが、その粒度は人間(私)の能力に依存する。 たとえば、「顧客管理システムをゼロから開発する」場合、(AI と対話しながら)必要な要件を洗い出し、現在の AI に投げても大丈夫なレベルまで細分化するのは私だからできることであり、それを AI に任せるまでには至っていない。 結局、ITシステム開発において、機能設計以前に行うべき事もたくさんあって、次第にそちらが注目されていくのだろう。
AI が提示してきた計画について、毎回問う事がある。 「API や DB の仕様を変更しないよね?」「類似の機能も修正すべきでは?」「下位互換性は担保される(されない)べき?」など。 これらは、定型のレビュー事項として、 openspec-reviewer が確認、指摘すればよいと思う。 このように、各エージェントが行うべき事はまだありそう。
typora は「マークダウンエディタ」であり、 VSCode は「ソースコードエディタ」だ。 GitHub や Backlog のプルリクエスト機能もコードレベルでのレビューツールであり、AI が書いたコードを行レベルで検査することには意味を感じない。 いずれも「AI 時代のツール」という感じはしない。
要件定義や設計の時点では、ホワイトボードを前に人と人が議論するような、AI との壁打ちの様子がリアルタイムに視覚化されるようなツールが欲しい。 成果物のレビューでは、AIがテストしたエビデンスがあり、実行環境もあり、その成果について問えるようなツールがあると良さそう。
Cursor や Antigravity がそれに近いのかも知れないが、まだ「プログラマー寄り」な印象も受ける。
「AIエージェントに Claude Code を使っている」、「仕様駆動開発に OpenSpec を使っている」などの局所要素はあまり重要でなく、AIによるチームビルディングが重要になってきそう。 今回のチームは決まったタスクを順次実施していくだけの単純なものだが、業務に応じて複雑なフローを行うAIチームを構築できる能力を身につけたい。
KDDI系が仕様駆動開発を採用、AIで業務は「設計8割・開発2割」に | 日経クロステック(xTECH)
これは上記ニュース記事の受け売りだが、概ね同意。私のフローに照らし合わせると、
だ。 コードを書くことは「99% 無い」ので、8割は過小かも知れない。
Plan モードや Swarms など、AIエージェントの標準機能として SDD ライクなものが搭載されたり、自動オーケストレーション&ロングランが可能になってきている中で、仕様駆動開発フレームワークはどのような立ち位置となるか?
他の FW は知らないが OpenSpec で言えば、「ITシステム開発目的で統一された様式」である事に価値があると思う。 Plan モードが出力する計画には行いたいことが詳細に書かれているが、Claude Code が(派生アプリである Claude Cowork にも代表されるように)プログラミング/ITシステム開発以外の用途でも使用されるようになることを考えると、plan.md は「汎用のフリーフォーマット」であり、システム開発に特化した何らかのフォーマットが決まっていた方が、人間にも、AI にも都合が良いと思う。
また、SDDフレームワークが提供する「仕様化」「タスク化」「レビュー」などの機能は、それなりに多くの知見の素に作られているはずなので、それに「乗っかって」おけば概ね正解だろう。
半年、1年後にはどうなってるのか分からないので、「可搬性の高いAI開発チーム」を維持していこうと思う。
本命は Agent2Agent であり、Skills は過渡期の仕様かなと思う。 本稿に登場したエージェントも、基本は各々が専門のスキルを持つのみであり、Skills 化せずエージェントのプロンプトにそれを記述すれば良いことが多い。 「賢者である XXXさんは "魔法使いスキル" と "僧侶スキル" を両方持っている」みたいなスキルの組合せとその管理のために存在し続けるかも知れないけど、基本は「餅は餅屋」、「設計の専門家である Aさん」「実装のスペシャリスト Bさん」と考えた方が分かりやすいと思う。 Skills のマーケットよりは Agent のマーケット(人身売買?)、あるいは Agent の利用権販売、SaaS から AaaS(AI/Agent? as a Service) みたくなっていくのかな?と。