AIにコードを書かせる前に、何を決める？仕様から始める開発

たとえば、AIに「社内資料を検索する画面を作って」と頼む場面を考えよう。資料のタイトルだけを探すのか、本文も探すのか。閲覧権限のない資料をどう扱うのか。こうした条件が曖昧なままだと、動く画面ができても作り直しになることがある。

作るものと完成の条件を先に決め、その内容をもとに実装やテストを進める方法が、仕様中心の開発（SDD、spec-driven development）だ。AIへ指示を出す前に、人どうしで決めておく仕事がある。 Microsoft Digitalの事例を手がかりに、検索画面で先に決めておきたいことから見ていく。Microsoft Digitalの開発事例

検索する範囲と、完成の条件を決める

まず、先ほどの依頼のどこで解釈が分かれるのかを追ってみる。「社内資料を検索する画面」という一文には、少なくとも3つの決まっていない点がある。

1つ目は、何を検索対象にするか。資料のタイトルだけを見るのか、本文の中身まで探すのかで、作るものが変わる。タイトルだけなら一覧から名前を照合すれば済むが、本文まで探すなら、資料の中身を読み込んで検索できる状態にしておく必要がある。依頼した側が本文検索を想像していて、実装した側がタイトル検索を作れば、動く画面はできても求めたものにはならない。

2つ目は、閲覧権限の扱いだ。社内資料には、部署や役職によって見られない資料がある。検索結果にタイトルだけ出して中身は開けないようにするのか、そもそも結果に出さないのか。ここを決めないまま作ると、後から「この資料が見えるのはまずい」と判明し、検索の作りに戻ることになる。

3つ目は、見つからなかったときだ。0件と表示するのか、似た名前の資料を候補として出すのか。候補を出すなら、何を似ているとみなすかまで決めることになる。

依頼の一文からは、どちらの動きを求めているのかが決まらない。仕様を書くとは、この6つの箱から使うものを選んで書き留めることにあたる。分岐は説明用に並べたもので、Microsoftの事例に出てくる機能ではない。

こうした点を、実装の前に文章として書き出したものが仕様にあたる。仕様と聞くと大きな文書を想像するかもしれないが、まずは関係者が同じ完成形を思い浮かべられるかで考えると分かりやすい。先ほどの3点なら、次の4行で足りる。

これはMicrosoftの実装を再現した表ではなく、仕様の書き方を示す仮の例だ。

この4行は、そのまま次の作業につながっている。2行目の検索範囲が決まれば、どのデータを読み込むか、権限をどこで判定するかという実装の話に進める。3行目が決まれば、候補を出す仕組みは今回作らないと判断できる。

一番効くのは、最後の行にある完成の確認方法だ。「使いやすい検索画面」では完成を判定できないが、名前が一部だけ一致する資料は表示し、権限のない資料は表示しないという条件なら、できあがったものを操作して合否を言える。権限のない資料を1件用意して検索すれば、その場で確かめられる。GitHubもSDDの説明で、仕様をコードの振る舞いについての取り決めと位置づけ、AIが生成・テスト・検証に使う基準にすると書いている。GitHubによるSDDの説明

Microsoftは仕様をどう開発に使ったか

2026年9月3日の記事は、社内IT組織であるMicrosoft Digitalの取り組みを紹介している。同社が教訓として挙げているのは、個人の開発者の生産性を上げても、チームの生産性の向上にはつながらなかったという経験だ。コードを書く時間が短くなっても、確認や修正に時間がかかれば、機能が届くのは早くならない。Microsoftの事例と「How the SDD workflow works」

そこで同社は、仕様をチーム全体の共通の基準に置いた。要件を一つの部門から次の部門へ手渡すのではなく、要件を決める人も開発者も同じ仕様に関わる。仕様はコードと同じように変更を管理し、開発中に分かったことを反映していく。

検索画面の例に戻すと、この違いは確認の対象に表れる。仕様がなければ、できあがった画面を見てから「本文も検索したかった」「この資料は出さないでほしい」と伝えることになる。指摘のたびに、どこまでが作り直しなのかを見積もり直す必要がある。仕様が先にあれば、検索範囲を書いた1行をレビューする段階で同じ食い違いに気づける。AIが正確にコードを書いても、検索の範囲にチームが合意していなければ手戻りは起きる、というのがこの進め方の前提だ。

仕様に関わる人の顔ぶれも、この進め方では変わる。検索画面の例なら、どの資料を誰に見せてよいかを決められるのは、開発者ではなく資料を管理している側だ。仕様という一つの文書を全員で読むことで、その判断を実装が始まる前に受け取れる。逆に、実装が終わってから相談すると、権限の判定をどこに入れるかという作りの話と、見せてよい範囲という運用の話が同時に動くことになる。

開発中に条件が変わる場合も同じで、権限の扱いを変えるなら仕様の該当行を直し、その変更を全員が見る。仕様を更新せずに実装だけ直すと、次に見た人が古い条件で確認してしまう。

この進め方を支えるツールとして、GitHubは2025年9月2日にSpec Kitを公開している。仕様の作成、技術的な計画、実装できる作業への分解を段階に分け、各段階で人が内容を確認する流れだ。GitHubによるSpec Kitの紹介 検索画面に当てはめると、仕様では誰が何を検索できればよいかを決め、技術計画では使うデータと権限の確認方法を決め、作業の分解では入力欄、検索処理、結果表示、テストに分ける。段階を分ける利点は、後戻りの範囲が小さくなることだ。権限の判定方法を変えても、仕様の目的が変わらなければ、直すのは技術計画から先になる。実際に使うコマンドや対応する開発環境は版によって変わるため、導入時はSpec KitのREADMEを確認する。

仕様を書く時間も含めて効果を見る

Microsoft Digitalは、コード生成やテスト、実装までの進行が速くなったと説明している。一方、今回読んだ公開本文には、導入前後の時間と測定方法を揃えた定量的な評価は見当たらなかった。Microsoftの公開記事 社内で測っていないと断定はできないが、公開されている範囲では、この手法を入れれば何割速くなるとチームの計画に織り込むことはできない。

自分たちで確かめるなら、検索画面のように完成の条件を短く書ける変更を1件選びたい。実装前に要件と完成条件を関係者で読み、意見が分かれた点を仕様へ反映する。AIで実装を進めたら、その完成条件に沿って人が確認する。途中で要件が変わったら仕様も直す。

見るのは、コード生成にかかった時間だけではない。仕様を書いた時間、レビューにかけた時間、実装後の手戻りを合わせて振り返る。この3つを合わせて見るのは、条件によって結果が変わるからだ。仕様を書くのに半日かかっても、権限の食い違いが実装前に見つかれば、作り直しの数日を避けられたことになる。逆に、条件がもともと明確な変更なら、仕様を書く時間がそのまま上乗せになる。前者では続ける材料になり、後者では対象の選び方を見直すことになる。

AIにコードを書かせる前に決めるのは、誰が何をできれば完成なのかだ。Microsoftの事例から借りられるのは、その条件をチームで先に合意するという進め方であり、どれだけ速くなるかは自分たちのチームで測ることになる。

まとめ

• SDDは、作るものと完成の条件を先に決め、それを基準に計画・実装・テストを進める方法。
• 検索画面の例なら、検索範囲・権限の扱い・0件時の表示・完成の確認方法を書き出すと、実装前に食い違いに気づける。
• Microsoft Digitalの記事に導入前後の定量的な評価は載っていない。効果は、仕様を書く時間・レビューの時間・実装後の手戻りを合わせて自分たちで測る。