AI時代の「設計書」は何を書き、何を書かないべきか

この記事でわかること:

• AI時代の設計書に必要な要素・不要な要素
• AIエージェントが読みやすい構成テンプレート
• 運用フェーズで陳腐化させない工夫

結論: 設計書は「AIへのプロンプト」になった

2026年、設計書の役割が大きく変わりました。かつては人間の合意形成ツールだった設計書は、いまやAIエージェントへの実装プロンプトでもあります。両方の役割を兼ねるため、書くべきことと書かないべきことの線引きが重要になっています。

書くべきこと

1. 目的と非目的

「何を達成するか」と「何を達成しないか」を明示します。AIは「やらないこと」を伝えないと、勝手に機能を追加します。実例として、ある決済機能の設計書に「返金は対象外」と書いたチームは、AIによる過剰実装を完全に防げました。

2. インタフェース定義

API・関数シグネチャ・データモデルを具体的に書きます。型レベルまで明示することが重要です。OpenAPI YAMLやTypeScript型定義をそのまま貼るのが最も効果的です。

3. データフロー

「ユーザーが○○する→システムが△△する」というシーケンスを箇条書きまたはMermaid図で記述します。AIはMermaidをかなり正確に解釈できるようになりました。

4. エラーケースと境界条件

正常系だけでなく、異常系・境界値を明示します。これがないとAIは正常系のみのコードを書きがちです。

5. 非機能要件

レイテンシ目標、スループット、データ保持期間など、数値で書きます。「高速に」のような曖昧表現は禁物です。

6. 設計判断の理由（ADR的に）

「なぜRedisではなくPostgreSQLを選んだか」など、選定理由を残します。AIは将来の改修時にこれを参照します。

書かないべきこと

1. UI詳細

UIはモック画像で示すか、別ドキュメントに切り出します。設計書に書くと陳腐化が早すぎます。

2. プロジェクト管理情報

スケジュール、担当者、リスク管理は設計書ではなくチケットに書きます。混在させると設計書がノイズだらけになります。

3. 一般論

「マイクロサービスとは…」のような教科書的説明は不要です。AIはすでに知っています。

4. 過剰な背景

過去経緯を延々と書くと、AIが本題を見失います。背景は3〜5行に抑え、必要なら別docへのリンクにします。

2026年版テンプレート

# [機能名] 設計書

## 目的（3行）
## 非目的（やらないこと）
## ユースケース（箇条書き 3〜5個）
## API契約（OpenAPI or TS型）
## データモデル
## シーケンス（Mermaid）
## エラーケース
## 非機能要件（数値）
## 設計判断（ADRリンク or 簡易記述）
## 受け入れ基準（テストケース）

陳腐化を防ぐ運用

設計書は「実装と一緒に更新する」ルールが必須です。PRに設計書の更新が含まれていない大規模変更は差し戻す、という運用を導入したチームでは、半年後も設計書の信頼度が90%以上を維持できました。

逆に運用ルールがないチームでは、3ヶ月で半数の設計書が嘘になります。AIに嘘の設計書を読ませると、嘘の上に嘘を重ねる実装が出来上がります。

AIに設計書を書かせる

2026年は「設計書もAIに書かせる」が普通になりました。エンジニアが要件を口頭で語り、AIが設計書のドラフトを作る、それを人間がレビューする—この流れだと作成時間が半分以下になります。ただしレビューは必須で、AIは時々非現実的な前提を置きます。

まとめ

AI時代の設計書は「AIへの実装プロンプト」と「人間の合意形成ツール」を兼ねる必要があります。書くべきは目的・インタフェース・データフロー・エラーケース・非機能要件、書かないべきはUI詳細・プロジェクト管理・一般論。テンプレートを整え、実装と一緒に更新する運用を組めば、設計書はAI時代に最強の武器になります。