ADR

Architecture Decision Record — 「なぜこの技術的判断をしたのか」を後から追跡できるよう構造化された短い記録ドキュメント。

概要

ADR は「結論」ではなく 「文脈 + 選択肢 + 決定 + 理由」 をセットで残す。個々の判断は時間が経つと「なぜこうなっているのか」が分からなくなる。ADR があれば、半年後・1 年後の読み手でも当時の制約とトレードオフを理解できる。

標準フォーマット

# ADR-001: [判断タイトル]

**日付:** YYYY-MM-DD
**状態:** 採用 / 却下 / 保留 / 置換

## コンテキスト

[判断が必要になった背景・制約]

## 選択肢

| # | 選択肢 | メリット | デメリット |
| - | ------ | -------- | ---------- |
| A | 自前実装 | 制御しやすい | 保守負担大 |
| B | 外部ライブラリ | 実績あり | 学習コスト |

## 決定

**選択肢 B を採用**

## 理由

[なぜこの選択肢を選んだか、重視した観点]

## 影響

- 想定される影響範囲・副作用
- 将来判断を覆す条件

2 段構成で使い分ける

ステアリング駆動開発では、ADR を 2 段に分離して運用する。

タスク固有の判断は作業メモに、設計原則・命名規則・アーキテクチャパターンなど プロジェクト全体に永続化すべきもの だけを docs/adr/ に昇華する。

ADR 昇華の基準

関連記事

• 壁打ち・規模判定編 — brainstorm.md から ADR に昇華する判断基準
• ステアリング作成編 — decision.md（ステアリング内 ADR）の書き方

関連用語

• SSoT — ADR は設計判断の SSoT として機能する