デザインドック（Design Doc）とは？書き方・項目テンプレート・AI活用まで解説

デザインドック（Design Doc、設計ドキュメント）とは、コーディングを始める前に「このシステムをなぜ・どう作るのか」を書き出し、設計の意図と決定の根拠をチームで共有するための文書です。仕様書のように「何を作るか」を細かく列挙するものではなく、採用したアーキテクチャと、検討して捨てた代替案・トレードオフを残すことに重きを置きます。この記事では、Design Docの定義と設計書・仕様書・ADRとの違い、書くべき項目のテンプレート、書き方と運用の流れ、GoogleのDesign Docs文化、そして生成AIで下書き・レビューを効率化する具体的な方法までをまとめます。

まとめ：デザインドックの要点

• Design Docの核心は「代替案とトレードオフの記録」。実装前に設計判断の根拠を残し、後から「なぜこの設計にしたのか」を追えるようにする文書です。
• 仕様書・設計書との違いは視点の高さ。仕様書が「何を作るか」の網羅なら、Design Docは「どう作るか・なぜそう決めたか」に絞ります。ADRより広く、機能・変更のまとまり単位で書きます。
• 書く項目はテンプレート化できる。背景・目標／非目標・設計・検討した代替案・懸念事項が中心で、本文の表にまとめました。
• すべての実装に必要なわけではない。単独で2〜3日以内に終わる小さな変更なら、書かない判断も正しい選択です。
• 生成AIは下書きとレビューで効く。箇条書きの設計メモからドラフトを起こし、代替案の抜け漏れを指摘させる使い方が実務的です。ただし最終判断は人が行います。

以下、それぞれを具体的に見ていきます。

デザインドック（Design Doc）の定義と役割

Design Docの定義と目的

Design Docは、実装に着手する前に設計者が作成し、システムの背景・目的・採用する設計・検討した代替案などを記述する文書です。目的は大きく2つあります。1つは着手前に設計の穴を見つけること。文章にする過程で、曖昧だった前提や見落としていた依存関係が表面化します。もう1つは設計判断の根拠を後世に残すことです。半年後に「なぜこのデータベースを選んだのか」と問われたとき、当時検討した代替案とトレードオフが書いてあれば、議論をやり直さずに済みます。ソースコードは「どう動くか」は語りますが、「なぜこう決めたか」は語りません。その欠落を埋めるのがDesign Docの役割です。

設計書・仕様書・ADRとの違い

混同されやすい近い文書との違いを整理します。仕様書・設計書は「何を・どう実装するか」を漏れなく記述する成果物で、完成後も参照される静的なドキュメントです。対してDesign Docは実装前の意思決定に焦点があり、重要な論点だけを高い視点で扱います。ADR（アーキテクチャ決定記録）はさらに粒度が細かく、1つの決定を1ファイルで記録するのに向きます。Design Docは「機能や変更のまとまり」を1本で扱うため、複数のADRを内包するような広さになります。

境界は組織によって揺れますが、判断の軸は「意思決定の根拠を残したいか（Design Doc・ADR）」「実装の網羅を残したいか（仕様書）」です。要件の書き方を突き詰めたい場合はEARS記法のような要件記述の型も併用できます。

デザインドックを書くメリットと、書かなくてよい場面

Design Docの効果は、書く工数を上回る場面でこそ現れます。第一に手戻りの削減です。設計の欠陥はコードになる前に紙の上で見つけたほうが桁違いに安く直せます。第二に合意形成の高速化。口頭やチャットで断片的に決めるより、1本の文書に論点を集約したほうがレビューが締まります。第三に属人化の解消で、頭の中にしかなかった決定理由が文書として組織に残ります。

一方で、Design Docを書くべきでない場面もはっきりしています。単独のエンジニアが2〜3日以内に終わらせられる小さな変更には、Design Docは重すぎます。設計の分岐が少なく、代替案を比較する必要もない作業に文書を強制すると、書くこと自体が目的化して形骸化します。判断基準はシンプルで、「後から誰かが設計判断の根拠を知りたくなるか」「複数人の合意が要るか」のどちらかに当てはまるときだけ書く、と決めておくと迷いません。

デザインドックに書く項目とテンプレート

標準テンプレート（項目一覧）

組織ごとに書式は異なりますが、Googleが公開するエンジニアリング慣行（eng-practices）や各社の公開事例で共通して挙がる項目はほぼ決まっています。次の表を骨組みにすれば、抜け漏れなく書き始められます。

とくに見落とされがちなのが非目標（Non-Goals）です。「今回はやらないこと」を明示すると、レビューでの論点の発散を防げます。「これはスコープ外」と一言あるだけで、無駄な指摘や過剰設計を減らせます。

代替案とトレードオフ ── Design Docの核心

テンプレートの中で1つだけ手を抜いてはいけないのが「検討した代替案」です。ここがDesign Docと単なる設計書を分ける決定的な差になります。採用した設計だけを書いた文書は、レビュアーに「なぜ他ではダメなのか」を判断させる材料を渡せません。少なくとも2つ以上の案を挙げ、性能・コスト・実装工数・運用負荷といった軸で比較し、なぜその案を選び、他を捨てたかを1〜2文で言い切ります。ここを丁寧に書いた文書は、レビューで質の高い議論を呼び込み、実装後の「言った言わない」も防ぎます。逆に代替案が空欄のDesign Docは、レビューを通す価値がほとんどありません。

デザインドックの書き方と運用の流れ

いつ書くか・どこまで書くか（粒度と長さ）

書くタイミングは要件が一通り固まり、実装に入る前です。要件が動いている段階で詳細まで書くと、要件変更のたびに書き直しになります。長さは短いほど読まれます。設計判断の分岐が少ない小規模な変更なら1〜2ページで十分で、大規模なシステムでも本質的な論点に絞れば数ページに収まります。目安として、書き始めから初稿までに何日もかかるなら、対象を分割したほうがよいサインです。粒度の原則は「ソースコードとコメントで十分伝わることは書かない」。実装を読めば分かる詳細ではなく、コードからは読み取れない設計の意図と背景に字数を割きます。

レビューの回し方とライフサイクル

Design Docは書いて終わりではなく、レビューされて初めて価値が出ます。実務的な流れは次の4段階です。

1. ドラフト作成：目標・概要・主要な設計・代替案まで書き、まず自分で読み返す。
2. 少人数レビュー：チームメイトやメンターなど1〜2名に共有し、方向性の齟齬を早めに潰す。
3. 関係者レビュー：必要に応じて他チームやレビュー会に展開し、指摘を反映する。
4. 実装と保守：実装中に設計が変わったら、Doc側も更新して実態と一致させる。

更新が止まったDesign Docは、実装と食い違ってむしろ害になります。設計変更が入ったらその場でDocに反映する、という運用ルールを最初に決めておくと陳腐化を防げます。少人数チームでも、この「ドラフト→レビュー→反映」の1周を回すだけで設計の質は目に見えて上がります。

GoogleのDesign Docs文化に学ぶ設計の考え方

Design Docという文書は、Googleのエンジニアリング文化から広く知られるようになりました。その本質は、書式やテンプレートそのものではなく「実装前に設計をレビューにかける」という規律にあります。設計者が代替案とトレードオフを言語化し、経験のあるレビュアーが組織の知見をぶつける。この往復によって、個人の設計を組織の設計へ引き上げるのがDesign Docs文化の狙いです。ここで大事なのは、Design Docを「立派な文書を作る作業」と捉えないことです。目的はあくまで良い設計にたどり着くことで、文書は議論を成立させるための道具にすぎません。凝った図や長い前置きより、論点が明確で代替案が比較されている素朴な文書のほうが、はるかに機能します。

生成AIでデザインドックを書く・レビューする

ここからは、競合記事があまり触れていない実務のショートカットとして、生成AI（ChatGPTやClaudeなど）でDesign Docを効率化する方法を具体的に扱います。仕様駆動開発（SDD）のようにAIを開発工程へ組み込む流れが広がる中で、Design Docの下書きとレビューはAIと相性のよい作業です。

AIにドラフトを書かせるプロンプトの型

白紙から書くより、箇条書きの設計メモをAIに渡してテンプレートの形へ整えさせるほうが速く、品質も安定します。有効なプロンプトは、出力してほしい項目構成を先に指定する形です。

あなたはシニアソフトウェアエンジニアです。以下の設計メモを、Design Docに整えてください。
構成は「背景／目標／非目標／設計概要／詳細設計／検討した代替案／懸念事項」とし、
各項目は簡潔に。代替案は最低2つ挙げ、却下理由も添えてください。
不足している前提があれば、決めつけず質問として末尾に列挙してください。

# 設計メモ
- （ここに箇条書きの設計メモを貼る）

ポイントは末尾の「不足している前提は質問として出す」指示です。これがないと、AIは曖昧な箇所を勝手に埋めて、それらしいが根拠のない文章を作ります。質問を返させることで、人間が決めるべき論点を炙り出せます。

代替案の洗い出しと抜け漏れレビューにAIを使う

下書きより効果が大きいのが、書き上げたDesign Docをレビューさせる使い方です。人間のレビュー前に一次チェックをAIに任せると、レビュアーは本質的な議論に集中できます。

以下のDesign Docをレビューしてください。観点は次の3つです。
1. 検討されていない代替案はないか（あれば具体的に提案）
2. 非目標やリスクで書き漏れている論点はないか
3. 記述が曖昧で実装者が迷いそうな箇所はどこか
指摘は重要度の高い順に、根拠とセットで挙げてください。

とくに「検討されていない代替案の提案」はAIが得意な領域です。人間が思いつかなかった選択肢が出てくれば、それを検討して却下するだけでもDesign Docの説得力は上がります。

AIに任せてよい範囲と、人が判断すべき境界

AIに任せてよいのは下書きと一次レビューまでで、設計判断そのものを委ねてはいけません。理由は3つあります。第一に、AIは事実と異なる内容（ハルシネーション）をもっともらしく書くため、生成された技術的記述は必ず人が裏取りします。第二に、外部のAIサービスに未公開の設計情報を貼り付けると機密情報の流出につながるため、社内規定で入力可否を確認し、必要なら固有名を伏せます。第三に、代替案の取捨や優先度といった最終判断は人間の責任で行うべきで、AIの提案を鵜呑みにすると設計の一貫性が崩れます。AIは設計者の思考を速める道具であり、設計者の代わりではありません。

よくある質問

デザインドックとは何ですか？

実装を始める前に、システムの背景・目的・採用する設計・検討した代替案などを書き、設計の意図と根拠をチームで共有する文書です。「どう作るか・なぜそう決めたか」を残すことに重点があります。

デザインドックと設計書・仕様書の違いは何ですか？

仕様書・設計書が「何を作るか」を網羅的に記述するのに対し、Design Docは実装前の意思決定に絞り、代替案とトレードオフを含めて「なぜその設計にしたか」を残します。視点がより高く、量は少なめです。

デザインドックには何を書けばよいですか？

背景・目標／非目標・設計概要・詳細設計・検討した代替案・懸念事項が基本です。中でも「検討した代替案」は必須で、これを省くとDesign Docの価値が大きく下がります。

デザインドックは誰が・いつ書きますか？

設計を担当するエンジニアが、要件が固まり実装に入る前に書きます。ただし単独で2〜3日以内に終わる小さな変更なら、無理に書かない判断も適切です。

生成AIでデザインドックは作れますか？

箇条書きの設計メモを渡してテンプレート形式のドラフトを作らせたり、書いた文書の抜け漏れや代替案をレビューさせたりできます。ただし技術的記述の裏取りと最終的な設計判断は人間が行う必要があります。

関連記事

• ADR（アーキテクチャ決定記録）とは｜書き方・テンプレート・design docとの違い
• 仕様駆動開発（SDD／Spec-Driven Development）とは？従来手法との違いとAI時代に注目される理由
• EARS記法とは？6つの型と書き方・実例をKiro連携まで解説