TL;DR
- 合意の再燃は、判断理由の欠落で起きる。「何を選んだか」ではなく「なぜ選んだか」を残す。
- Decision Log に「選択肢・理由・証拠・棄却案」を記録し、レビュー時に参照可能にする。
- ログの置き場所を固定し、PR テンプレとリンクすると、議論時間が大幅に短縮する。
- AI 開発では意思決定の速度が上がる分、記録の仕組みがないと「なぜこうなった？」が頻発する。
はじめに
本記事は Spec-Driven Development（SDD）シリーズ の1本です。仕様品質の全体像は親記事で確認できます。 👉 AI時代の仕様品質マネジメント
AI を使った開発では、短時間で複数の実装案が生成されます。人間だけで開発していた時代と比べて、選択肢の量が爆発的に増えるのが特徴です。しかし「なぜその案を採用したか」が記録されないまま実装が進むと、レビューや後続開発で同じ議論が蒸し返される問題が起きます。
本記事では、この「合意の再燃」を防ぐための意思決定ログ（Decision Log）と証拠管理の設計パターンを解説します。
なぜ意思決定ログが必要なのか
AI 開発特有の課題
従来の開発でも意思決定の記録は重要でしたが、AI 開発では以下の理由で緊急度が増します。
| 比較軸 | 従来の開発 | AI 活用開発 |
|---|---|---|
| 選択肢の生成速度 | 人間が検討して数案 | AI が数秒で 5〜10 案を生成 |
| 判断の頻度 | 1 日数回 | 1 時間に数回以上 |
| 文脈の揮発性 | 会議メモに残りやすい | チャットログに埋もれやすい |
| レビュー時の再現性 | 担当者に聞ける | 担当者も AI の出力を覚えていない |
AI は与えられた前提だけで「もっともらしい案」を出力するため、前提が曖昧なまま判断が進むリスクが高くなります。これはコンテキスト負債とも密接に関連します。 👉 コンテキスト負債とは何か
合意の再燃が起きるパターン
意思決定ログがない現場では、以下のパターンが繰り返されます。
- 「なぜこの方式にしたの？」パターン — レビュアーが代替案を知らず、ゼロから議論が始まる
- 「前にも検討したはず」パターン — 棄却済みの案が再提案され、過去の結論を掘り返す時間が発生
- 「あのとき OK したのは誰？」パターン — 口頭合意のみで承認者が不明、責任の所在が曖昧になる
いずれも判断理由と根拠が残っていれば防げる問題です。
Decision Log の設計：証拠の最小セット
テンプレート構造
Decision Log に記録すべき最小項目は以下の 6 つです。
## Decision Log: [判断タイトル]
- **日付**: 2026-02-10
- **判断者**: @username
- **選択肢**:
- A: REST API で実装
- B: GraphQL で実装
- C: gRPC で実装
- **採用案**: A（REST API）
- **理由**: 既存クライアントとの互換性維持、チーム内の習熟度が最も高い
- **棄却理由**:
- B: フロント側の学習コストが高い、既存エンドポイントとの混在が複雑化
- C: 社内ツールチェーンが未対応、導入工数が見合わない
- **証拠**:
- パフォーマンステスト結果: [リンク]
- 影響範囲分析: [リンク]
証拠として有効なもの
証拠は「第三者が判断を再現できるか」を基準に選びます。
- テスト結果 — ベンチマーク、負荷テスト、ユニットテストのカバレッジ差分
- 影響範囲分析 — 変更が影響するモジュール・API・データベーススキーマの一覧
- 代替案の比較表 — 各案の pros/cons を定量・定性の両面で整理
- ステークホルダーの承認記録 — Slack スレッドや PR コメントへのリンク
受入条件（Acceptance Criteria）を先に定義しておくと、判断の根拠が自動的に構造化されるため、Decision Log の記録負荷が下がります。 👉 受入条件を先に書く TDD 実践
アンチパターン：記録しすぎ / 記録しなさすぎ
| アンチパターン | 症状 | 対策 |
|---|---|---|
| 全判断を記録 | ログが膨大になり誰も読まない | 「覆る可能性がある判断」のみ記録する |
| 採用案だけ記録 | 棄却理由がないため代替案が何度も再浮上 | 棄却案と理由をセットで残す |
| 口頭合意のみ | 1 週間後に誰も内容を覚えていない | 48 時間以内にログへ転記するルールを設ける |
| 個人メモに分散 | 本人以外アクセスできない | チーム共有の固定場所に置く |
置き場所と運用ルール
置き場所を固定する
Decision Log の効果は「見つけやすさ」に比例します。チーム全員が迷わずアクセスできる場所に固定することが最重要です。
推奨構成:
docs/
├── decisions/
│ ├── 001-api-protocol-choice.md
│ ├── 002-auth-strategy.md
│ └── 003-data-migration-approach.md
└── templates/
└── decision-log-template.md
- ファイル名に連番と概要を含め、一覧性を確保する
- Git 管理に含めることで、変更履歴とコードの対応が追える
Issue テンプレで要件品質を上げる仕組みと組み合わせると、Issue → Decision Log → PR の流れが一貫します。 👉 Issue テンプレで要件解像度を上げる
PR テンプレとの連携
PR テンプレに Decision Log へのリンク欄を追加すると、レビュアーが判断根拠に即座にアクセスできます。
## PR チェックリスト
- [ ] テストが通る
- [ ] 影響範囲を確認済み
- [ ] **Decision Log**: docs/decisions/xxx.md（該当する場合）
このリンクがあるだけで、レビュアーは「なぜ？」を聞く前に背景を確認でき、レビュー時間が短縮されます。
更新ルール
- 判断が変わった場合: 元のログを削除せず、差分理由を追記する（
## 変更履歴セクション） - 更新頻度: スプリントレトロで Decision Log の棚卸しを行い、古い判断の有効性を確認する
- 責任者: 判断を下した本人が記録。記録がない PR はレビュー着手しないルールにすると定着する
AI ワークフローへの組み込み方
AI 開発で Decision Log を実効的に運用するコツは、AI の出力プロセスに記録を組み込むことです。
プロンプトに判断記録を要求する
AI に実装を依頼する際、以下のように判断根拠の出力を求めます。
以下の要件を実装してください。
実装案を3つ提示し、それぞれの pros/cons を表形式で示した上で、
推奨案とその理由を明記してください。
要件: [...]
AI の出力結果をそのまま Decision Log にコピーすれば、記録の手間がほぼゼロになります。
SDD（Spec Driven Development）との連携
仕様ファイルを正（SSoT）とする SDD のアプローチでは、Decision Log は仕様ファイルの補足資料として位置づけられます。仕様が「何を作るか」を定義し、Decision Log が「なぜそう作るか」を補完する関係です。 👉 なぜ AI エージェントは仕様書を無視するのか？
まとめ：次にやること
意思決定ログと証拠管理は、レビューの高速化と組織の学習資産化を同時に実現する仕組みです。
今日から始められる 3 ステップ:
- テンプレートを用意する — 上記の最小 6 項目を
docs/templates/decision-log-template.mdに配置 - PR テンプレにリンク欄を追加 — レビュアーが判断根拠にアクセスできる導線を作る
- 「棄却理由」を必ず書く — 採用案だけでなく、なぜ他の案を選ばなかったかを記録する
全体像に戻る: AI時代の仕様品質マネジメント
シリーズ全体に戻る: 親記事
