gists

ADR における Architecture / Decision / Record とは？

Architecture

システムの構造的な骨格を指す。具体的には:

• コンポーネント分割（マイクロサービス vs モノリス）
• 技術スタック（言語・フレームワーク・DB選定）
• 通信方式（REST / gRPC / メッセージング）
• 非機能要件の実現方法（認証、スケーリング、永続化戦略）

単なるコード構成ではなく、「後から変えるのが高コストな選択」全般。

Decision

「なぜその選択をしたか」という意思決定そのもの。ADRの中核で、通常こういう構造で書く:

• Context: どんな状況・制約があったか
• Decision: 何を選んだか
• Consequences: その結果起きる良いこと／悪いこと
• Alternatives: 検討したが採用しなかった案

「PostgreSQLを採用する」が Decision ではなく、「Xという制約下でAとBを比較した結果、Postgresを選んだ」全体が Decision。

Record

ADRの “R”。「記録」を意味し、以下の性質を持つ:

• 追記型（append-only）: 一度書いたADRは書き換えない。方針が変わったら新しいADRを追加し、古いものに “Superseded by ADR-0012” と参照を貼る
• 時点の凍結: 決定した瞬間のContext（当時の制約・前提・代替案）をそのまま保存する。後から見て「なぜこうなってるのか」が分かる
• 不変性: 間違いだったと分かっても元ADRは削除せず、Status を Deprecated / Superseded に変える

Decision が「意思決定そのもの」なら、Record は「その意思決定を消さずに残す」という運用ルール。Git のコミット履歴に近い発想で、過去の判断を再現・検証できる状態に保つことが目的。

---

まとめ

ADR = アーキテクチャ上の意思決定を、時系列の記録として残す仕組み。

用語	役割
Architecture	対象範囲（後から変えにくい構造的選択）
Decision	中身（Context / Decision / Consequences / Alternatives）
Record	運用ルール（追記型・不変・時点凍結）

---

補足: 「追記型」で古いADRと新しいADRはどうリンクするか

ADR-0013 が後から ADR-0101 で上書きされる場合、両方向にポインタを張るのが一般的。

ADR-0013（古い方）

# ADR-0013: セッションストアにRedisを採用

Status: Superseded by ADR-0101   ← 後から追記する
Date: 2024-03-10

## Context
（当時の状況をそのまま残す。書き換えない）

## Decision
Redisを使う

本文は書き換えない。Status行に “Superseded by ADR-0101” を足すだけ。

ADR-0101（新しい方）

# ADR-0101: セッションストアをDynamoDBへ移行

Status: Accepted
Date: 2026-04-15
Supersedes: ADR-0013   ← 前の決定を指す

## Context
ADR-0013 で Redis を採用したが、マルチリージョン対応が必要になり…

## Decision
DynamoDBに移行する

ポイント

• ADR-0013 → ADR-0101: 「これはもう生きてない、後継はこれ」という道標
• ADR-0101 → ADR-0013: 「この決定は過去のこれを覆すもの」という文脈
• ADR-0013 の Context / Decision 本文は絶対に書き換えない。Status行を足すだけ

追記型＝ファイル全体を不変にするのではなく、過去の判断内容（Context/Decision）を不変にする、という意味。Status行のようなメタ情報の更新は許されるのがポイント。

This site is open source. Improve this page.