【通算090｜要求AI 07】要件定義書を渡したら、設計書ができた——技術設計書には何が書かれるのか

2026年7月20日 21:33

前回、4つの視点で構造化した指示から要件定義書ができた。しかし、SDD（仕様駆動開発）の本領はここから。要件定義書→設計書→タスクリスト——「要求仕様からシステムを作る」。
同じセッションの続きを確かめた。まず設計書作成まで。
タスクリストは次回に分けて紹介する。

Kiroについてのこれまでの記事

Kiroはまず、ファイルをチェックする

入力欄に「技術設計書を生成してください」と送る。

kiro:「requirements.md は存在しますが、design.md がまだありません。技術設計書を生成します」

会話の記憶ではなく、フォルダー内の要件定義（書）を確認して、設計を始めた。セッションを閉じても、MDファイルさえ残っていれば続きから再開できる。

そしてもう一つ。技術スタックの質問は来なかった。言語は？　データベースは？　——何も聞かずに、KiroはTypeScriptと4層アーキテクチャ（DDD）を自分で決めて書き始めた。要件のときに業務を聞かなかったのと同様に、設計では技術を聞かない。

約10分・3.37クレジットで design.md（433行）が生成され、承認を求めるメッセージが出た。
記事の後半に、作成された設計書の一部のスクリーンショットを添付している。

状態遷移図とアーキテクチャ図（テキストから図を生成するmermaid記法）、データモデルの型定義6、エラー処理の一覧表、テスト戦略。そして注目は「正確性プロパティ」——システムが常に満たすべき性質を9本、文章で定義し、それぞれに要件番号を紐づけている。

Property 4: 金額閾値による一次承認後ステータス分岐 — 金額 < 50,000円であれば承認後ステータスは APPROVED、>= 50,000円であれば PENDING_ACCOUNTING になる。Validates: Requirements 3.2, 3.3

バリデーションチェックの例

指示に書いた「5万円未満は上長承認のみ」が、要件になり、検証可能な性質にまで落ちている。

テキストで渡した要求が、設計の段階で図と型に変換される。

ただし、データモデルの状態定義に、見覚えのある文字があった。

DRAFT（下書き）。

要件定義書に下書きは存在しない。状態遷移図にもDRAFTからの矢印は無い。それなのに、型定義にだけ、下書きが入っている。——雑な一文で検証したとき、Kiroは用語集に「下書き」を定義しながら要件化し忘れた。指示を構造化して要件からは消えたはずの下書きが、一段下の設計層で復活した。

「経費申請には下書きがあるはず」というAIの学習知識は、書かなくても紛れ込む。しかも要件・設計のどちらのレビューゲートでも、誰にも気づかれずに通過した。

作成された「設計書」の一部のスクリーンショットが以下のとおり

ディレクトリ構成は以下のように、".kiro"配下に、"design.md"として作成される

設計書は、MDファイルとして作成され、一部、Mermaid形式の図解あり

この設計書を土台に、Kiroは次の工程「タスクリスト（実装計画）」を生成する。設計がどんなタスクに分解され、要件番号がどこまで貫通するのか——それは次回紹介する。