OTR_SpecDrivenDevelopment

仕様駆動の開発（spec → plan → 実装）

• TOP > 使い方 > 仕様駆動の開発

概要

コーディング・エージェントで規模のある変更を行うときは、spec（仕様）→ plan（計画）→ 実装の順で進めることを推奨する。

• 仕様を docs/spec/、計画を docs/plan/ に置いてから実装させる。
• リードエンジニアが仕様と計画を確認・承認し、エージェントは計画に沿って、スキルを使いながら実装する。
• OpenTouryoCodingAgentAssets のインストーラに -IncludeTutorial を付けると、この流れを通しで試す見本が導入先に配置される。

詳細

役割分担

段階	置き場	主に担う	内容
spec	docs/spec/	リードエンジニア（エージェントが下書きしてもよい）	何を作るか。使うフレームワーク・処理方式、対象テーブル、画面とボタン、処理の流れ
plan	docs/plan/	エージェントが作り、リードエンジニアが承認	どう作るか。手順、使うスキル、変更するファイル、検証方法
実装	ソース	エージェント	計画に沿って、スキルに書かれた方式どおりに実装する
検収	—	リードエンジニア	ビルド・テスト・動作確認、差分のレビュー

• 仕様に「どのスキル・どの処理方式を使うか」を書いておくと、エージェントの解空間がさらに狭まる。
• docs/spec・docs/plan は利用者の作業ディレクトリなので、インストーラを再実行しても既存のファイルは上書きされない。

見本（チュートリアル）

アセットには、Northwind のテーブルを使った見本が入っている。

見本	内容
test1	フレームワークの共通仕様、セットアップと変形の計画
test2	マスタ・テーブル（Suppliers）のバッチ更新
test3〜5	トランザクション・テーブル

test2 の仕様（要約）：

• 指定したマスタ・テーブルの件数を確認する SQL を CmnDao で実行する B 層を作り、画面 A のボタンから実行して、結果を OK メッセージ・ダイアログで表示する。
• マスタ・テーブルの Dao を CLI で自動生成し、画面 B で一覧を表示する。
• グリッドで行の追加・更新・削除を行い、YES/NO ダイアログの確認後に、自動生成 Dao 経由でバッチ更新する。
• 同じ仕様を、MVC（net48）・MVC（net10.0）・Web Forms・Windows Forms（2 層）・Windows Forms（3 層）の各サンプルに実装する。

同じ仕様を複数の処理方式・複数回実装させて、出力が揃うかを見ることは、開発基盤の「標準化の度合い」の評価にもなる
（評価、開発基盤のKPIとKGI）。

プロンプトの見本

src/docs/prompt/ にプロンプトの見本がある（2026 年 10 月時点）。

• 検証プロンプト：「plan/test1-setup.md のケース1 を実行して下さい。」のように、計画書のケースを指定して実行させる形。プロンプト自体は短くなる。
• 入門プロンプト：準備中。

進め方のポイント

• 計画の段階で「どのスキルを使うか」を明示させる。スキルを読まずに一般的な .NET の作法で書かせない。
• 実装は段階的に行わせ、都度ビルドして確認させる。
• 確認できない前提（親クラス2 の仕様など）は推測させず、人に聞かせる（opentouryo-project-policy）。
• Git の状態を変える操作は人が行う（導入先の AGENTS.md の既定）。

参考

• コーディング・エージェント用アセットの導入
• CRUD 画面
• DataTable によるバッチ更新
• D層自動生成ツール

---

Tags: 再構築