これは何か
設計判断記録は、設計で何を選び、ほかにどんな案があり、なぜその案にしたのかを、判断のたびに残す成果物です。一般的には ADR（Architecture Decision Record）とも呼ばれます。
設計書が「どう作るか」を示すのに対し、設計判断記録は「なぜそう作ったか」を示します。
なぜ作るか
- あとから設計を変えたくなったとき、当時の前提と理由を確かめられる
- 同じ議論を何度も繰り返さずに済む
- 担当者が替わっても、判断の理由が失われない
- 性能・安全・費用などの非機能の目標と、設計の選択のつながりを残せる（04-03 機能要件と非機能要件）
誰が使うか・いつ作るか
- 書く人：アーキテクト、設計の担当
- 読む人：設計・開発・運用の担当、あとから設計を見直す人
- 設計で大事な選択をしたときに、そのつど作ります
- アステリア案件の実際の設計判断は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
設計判断に関係する記載
- P-008 黒田 健 — システムアーキテクト
- AIへ最終委任しないことに「設計承認」がある
- Unit 05-05 のタイトルは「設計判断をなぜ記録するのか」
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 設計判断記録の項目
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
| 項目 | 何を書くか | 書き方の例（教材上の例） |
|---|---|---|
| 番号・題名 | 判断を特定する番号と題名 | ADR-EX-01 システム同士のつなぎ方 |
| 状況 | どんな問題・前提があったか | つなぐ相手の多いシステムがある |
| 選択肢 | 検討した案 | 案1：直接つなぐ／案2：連携基盤を経由する |
| 判断 | 選んだ案 | 案2 |
| 理由 | なぜその案か。何を優先したか | つなぐ相手の数と、管理のしやすさ |
| 影響・引き換え | その案で失うもの、後で必要になること | 連携基盤が止まると、経由する連携がまとめて止まる |
| 前提の確認 | 判断の前提となった条件 | つなぐ相手の数と、今後増える見込み |
| 状態・承認 | 提案中・承認済み・見直し済み、承認した人と日付 | 記入欄 |
番号・内容はすべて教材上の例です。アステリア案件の設計判断ではありません。
何を書いてはいけないか
- 選んだ案だけを書き、ほかの選択肢と理由を書かない
- 判断の前提（データ量・利用の状況・目標）を書かない
- あとから都合よく書き換える（見直したときは、新しい記録として残す）
どこを見るか
- 検討した選択肢が、2つ以上書かれているか
- 理由が、要件（特に非機能の目標）とつながっているか
- 判断の前提となった条件が、書かれているか
- その案で失うもの・引き換えが書かれているか
- 承認した人と日付、見直しの履歴があるか
赤信号
- 「慣例に従った」「一般的なため」だけが理由
- 前提の条件が書かれていない
- 前提が変わったのに、記録が見直されていない
- 設計書と記録の内容が食い違っている
関係するUnit・危機演習
- Unit：05-01 システム全体図を読む、05-04 システム同士をどうつなぐのか、04-03 機能要件と非機能要件
- 危機演習：CR06（学習上の接続です。正式な対応関係ではありません）
AI WORKFLOW
「この設計判断記録を読み、①選択肢が1つしかない、②理由が要件とつながっていない、③前提の条件が書かれていない、④引き換えが書かれていない箇所を挙げてください。どの案がよいかは判断しないでください。」
AIに、会議の記録から設計判断の下書きを作らせることもできます。
REVIEW
- 下書きの選択肢と理由が、実際の議論と合っているか
- AIが前提の条件を、一般的な値で埋めていないか
- 判断した人・日付が正しいか
人間が判断すること
- どの案を選ぶか（設計承認）
- 前提が変わったとき、判断を見直すか
- 引き換えを受け入れるか
設計承認は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 05｜全体設計を作る の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
1年後にこの記録を読んだ人は、なぜこの設計にしたのかを説明できますか？