仕様駆動開発(SDD)をClaude Codeで試した手順と気づき

「SDDって結局なんですか」と、研修先で何度か聞かれるようになりました。2026年に入ってからAI開発まわりでよく見る言葉です。私も最初はバズワードだと思って横目で眺めていたのですが、実際に試したら考えが変わりました。

この記事は、仕様駆動開発(SDD)をClaude Codeで試した記録です。

SDDという言葉をよく聞くようになった

SDDは Spec-Driven Development の略で、日本語だと仕様駆動開発と呼ばれます。AWSのAI開発ツール Kiro が「仕様駆動」を前面に打ち出したあたりから、検索でもよく見るようになりました。

AmazonのKiroとClaude Codeの違い

GitHubも spec-kit というSDD向けのツールキットを公開しています。各社が似た方向を向いている、という状況です。

GitHub spec-kit

考え方そのものは難しくありません。いきなりコードを書き始めるのではなく、まず「何を作るか」を仕様として文章にまとめる。そのうえでAIに実装させる、という順番です。

ふだんのClaude Codeの使い方は、対話しながらその場で実装に進む「プロンプト駆動」。SDDはそこに一段、仕様を書く工程を挟みます。

なぜわざわざ手間を増やすのか。私が試してわかったのは、仕様を文章にした時点で、自分の考えの曖昧さが見えるということでした。「ログイン機能がほしい」では足りない。失敗した時どうするのか、パスワードを忘れた人はどうするのか。書いていくうちに、決めていなかったことが次々に出てきます。

AIが書くコードの量が増えたことが背景にあると感じています。

AIは指示すればどんどんコードを書きます。でも指示が曖昧なら、曖昧なまま大量のコードができあがる。あとから直すほうが大変です。だったら最初に仕様を固めよう、という揺り戻しがSDDの正体だと私は理解しています。

人間のチーム開発で昔から「仕様書を先に書け」と言われてきたのと、本質は同じ。それをAIとの作業に持ち込んだものです。

専用ツールが無くても、Claude CodeだけでSDDは試せます。私がやっている流れはこうです。

肝は2番と3番です。Plan modeは、いきなり実装せずに「何をどうするか」の計画だけ先に見せてくれる機能。仕様と計画を突き合わせる工程に、ちょうど噛み合います。

Claude CodeのPlan modeの使い方

仕様ファイルは凝らなくて大丈夫です。箇条書きで「やりたいこと」「やらないこと」「困った時の動き」を書くだけでも、何も書かないより格段にぶれが減ります。

最初の失敗を正直に書きます。私は仕様ファイルに気合いを入れすぎて、3000字くらいの長文を書きました。結果、AIが全部を均等に扱ってくれず、肝心な部分が薄まった。

学んだのは、仕様は短く、優先順位をはっきりさせること。「これだけは外せない」を先頭に、3〜5項目くらいに絞ったほうが、計画の精度が上がりました。

もうひとつ。小さい使い捨てのスクリプトにSDDを持ち込むのは、正直やりすぎです。仕様を書く時間のほうが長くなる。SDDが効くのは、ある程度の規模があって、後から直すコストが高い作業です。

ここが私がいちばん伝えたい点です。

SDDの「仕様を書く」工程は、コードを書く作業ではありません。日本語で「何を作りたいか」を整理する作業です。これは非エンジニアにこそ向いている。

研修でも、受講者に最初からコードを書かせるのではなく、「作りたいものを文章で書く」練習からやってもらうようにしました。仕様さえ書ければ、実装はClaude Codeが引き受ける。SDDは、非エンジニアがAIにものを作らせる時の、現実的な入り口になります。