「AIが破ってはいけないルール」を明確化する
プロンプト頼みの開発は限界 「仕様」を資産にする「スペック駆動開発」
AIコーディングにおいて、プロンプトに依存した進め方には限界があるという声がある。Microsoft MVPの称号を持つエンジニアがプロンプトの限界を克服する開発手法を紹介する。
生成AIにプロンプトを入力し、コードを書かせる――。このようなAIコーディングは一般的になった。しかし、企業の大規模な開発プロジェクトでは限界があるという指摘がある。
ITベンダーSopra SteriaのシニアプリンシパルエクスパートでMicrosoft MVP(注)、クラウドアーキテクトのローラント・ディーベン氏は、プロンプトに依存した開発では、チームで要求や設計方針を共有し、継続的に管理することが難しくなると指摘する。
では、AIを使った開発を大規模なプロジェクトでも安定して進めるには、何を開発の中心に据えるべきなのか。ディーベン氏が提案するのが、プロンプトではなく「仕様」を中心に開発を進める「スペック駆動開発」(spec-driven development)だ。その考え方と具体的な進め方を見ていく。
※注:MVPはMost Valuable Professionalの略。Microsoft製品や関連技術に関する高度な専門知識を持ち、その知識をコミュニティー活動などを通じて継続的に共有している個人にMicrosoftが表彰し付与する称号を指す。
●プロンプト依存から抜け出すには
プロンプトを入力すれば、ソフトウェア開発をある程度効率化できる。一方、プロジェクトや開発チームの規模が大きくなるほど、個々の開発者が入力するプロンプトだけでは、要求や設計思想を継続的に管理しにくくなる。
この状態をディーベン氏は、「プロンプトが、ソフトウェア開発を弱くする土台になり得る」と表現する。プロンプトは各個人のスキルや入力条件に依存しやすく、そのときによって内容の質が低下する場合がある。レビューも困難だ。生成されたコードは動作していても、本来の目的から外れてしまうことがあるという。
「プロンプトを主要な成果物として扱うのをやめ、仕様を主要な成果物として扱う」必要性があるというのがディーベン氏の主張だ。
仕様をリポジトリに保存すれば、コードと同様にGitの履歴として残すことができる。新機能を開発するときにも、過去の仕様を土台として追加、変更できるため、AIへの指示をその場限りにせず、チームの資産として蓄積可能だ。
そこでディーベン氏は、プロンプトではなく「仕様」(Specification)をAI開発の中心に据える「スペック駆動開発」(spec-driven development)を紹介する。使うのは、GitHubの「Spec Kit」(仕様駆動開発向けオープンソースツールキット)と「GitHub Copilot」(AIコーディングエージェント)だ。
最初に作るのは「AIが破ってはいけないルール」
Spec Kitを使った開発では、いきなり機能の実装をAIに依頼するわけではない。最初に「Constitution」と呼ばれる基本原則を定める。
ディーベン氏によると、Constitutionは、AIコーディングエージェントに守らせる「必須条件」をまとめるものだ。
Constitutionには、個別機能よりも上位に位置するルールを記述する。例えば、テスト可能な設計にすること、社内のセキュリティ基準を守ること、企業や開発チーム固有のルールに従うことなどだ。
つまり「セキュアなコードを書いて」「テストも用意して」と開発者が毎回プロンプトを書くのではなく、AIコーディングエージェントが常に従うべき開発原則を明文化する。
「何を作るか」と「どう作るか」を分ける
Constitutionを定義した後に作成するのがSpecificationだ。ディーベン氏によると、ここで重要なのが、「何を作るのか」と「どう作るのか」を分離することだ。アプリケーションに必要な機能や要件を記載する一方、技術的な実装方法は含めない。実装方法は次の「Plan」で決める。
例えば、TypeScriptやNode.jsを使うこと、HTTPサーバとして動作させること、デプロイ方法や設定方法などをPlanに記述する。つまり、Specで「何を作るか」、Planで「どう作るか」を分けて管理する。
大きな仕様を「タスク」に分解
仕様と技術計画を作った後は、それらを実装可能な単位に分割する「Tasks」を定義する。Specificationで定義したユーザーストーリーやPlanの技術要件、Constitutionの原則を参照しながら、AIが順番に実装できるタスクへと分解する。
Tasksを作成した後は、AIコーディングエージェントがタスクを基にコードを生成する「Implement」だ。Constitutionでテスト可能な設計を求めていれば、テストも作成しながら実装を進めることができる。
「AIが作った仕様」も人間がレビューする
ただし、スペック駆動開発は「仕様書をAIに作らせれば、後は自動で開発できる」という考え方ではない。ディーベン氏が特に強調したのが、人間によるレビューだ。
同氏は「全てをレビューしてほしい」と強調する。対象はAIコーディングエージェントが出力したコードだけではない。Constitution、Spec、Planといった中間成果物も確認し、開発者自身が内容を理解した上で、チームとして方針に合意する必要があるという。
AIコーディングエージェントが自動的に補完する情報にも注意が必要だ。例えばPlanを作る際、使用するフレームワークなどのバージョンを指定していなければ、AIコーディングエージェントがバージョンを補完する場合がある。しかし、それが必ずしも最新とは限らない。
いきなり開発プロセス全体を変える必要はない
では、企業がスペック駆動開発を試す場合、何から始めればいいのか。ディーベン氏は、明日から開発ワークフロー全体を書き換えるのではなく、まず「小さいが意味のある実際の機能」を1つ選んで試すことを薦める。
その上で、プロンプトを書く前に仕様を書き、「何を、なぜ作るのか」を先に整理する。さらに、チームとして譲れないルールを数個Constitutionに設定し、AIコーディングエージェントが生成した内容を全てレビューしてから実装する。
本稿は、2026年8月25日にMicrosoft Developerが公開したStop Writing Prompts. Start Writing Specs.を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
新着ホワイトペーパー PR
-
製品資料
[株式会社MatrixFlow] 「物流リソース最適化」ガイド:人員・配車・傭車を出庫依頼の確定前に決めきる -
製品資料
[株式会社キーエンス] なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは -
製品資料
[株式会社セールスフォース・ジャパン] 「CRMは設計と無関係」は本当か? PLMとの融合で実現する高速開発 -
事例
[日本ヒューレット・パッカード合同会社] AIエージェントの時代にどう備える? 「新たな働き手」を支える3要素とは -
製品資料
[日本ヒューレット・パッカード合同会社] “横並びの自動化”から脱却、AI活用で生産性と競争力を高める秘訣
こんなメディアも見られています
TechTargetジャパンに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
ベンダーコンテンツ PR
From Informa TechTarget
SpecialPR
アクセスランキング
-
1
ChatGPTは“検索しまくり”でGeminiは“淡泊”? データが明かすAIの裏側
-
2
法務と開発者で「言葉が通じない」問題 トヨタやソニーが語るOSS管理の真実
-
3
なぜ「全社配布Copilot」は使われないのか? 失敗に学ぶAI定着
-
4
肥大化した「SFA」の沼 4カ月でBigQuery×AppSheetの新システムを構築した方法
-
5
損保ジャパンはなぜ「COBOL」を捨てなかったのか? 脱メインフレームの真相
-
6
AIの導入効果はどう測る? DMM.comのエンジニア組織に学ぶ効果検証のノウハウ
-
7
なぜ「Gemini 4 Argon」は出遅れたのか? Googleが狙う“逆転のシナリオ”
-
8
「何から始めればいい?」 情報漏えい対策で悲鳴を上げる中小企業のリアル
-
9
ノベルティプレゼント「Windows 8 TシャツとOffice クリーニングクロスセット」
-
10
ネットワールド、ICカード認証対応のシンクライアント構築アプライアンスを販売
ホワイトペーパーランキング PR
-
1
不審メールの経路や見せ方に変化? 2026年夏の3事例から見えた動向と対処方法
-
2
家庭用Wi-Fiルーターの業務利用は危険? 避けるべき理由と具体的な対策
-
3
プログラミング不要で誰でも実現できる、ネットワーク運用管理の自動化とは
-
4
Microsoft 365を安全に運用 うっかりミスやサイバー攻撃に備えるデータ保護術
-
5
財務部門がAIを最大限に活用する方法 無駄のない戦略的リーダーシップへの道
-
6
LLMが兵器化? 元FBI高官が鳴らす警鐘とセキュリティツール統合のポイント
-
7
なぜRPA導入は頓挫する? シナリオ作成の壁を乗り越える解決策とは
-
8
HDDを使わない「SSDオンリー」が無謀なのはなぜ?
-
9
“あのファイル転送”で暗躍するノーウェアランサム
-
10
「オンプレミス回帰」せざるを得ない“合理的な理由”
TechTargetジャパン SNS
インフォメーション
注目情報をチェック
TechTargetジャパンをフォロー