ADR を書いてリポジトリに置いたものの、数か月後に開くと構成はすでに別のものになっていて、ADR だけが昔のまま残っている。変えたくなったときに元の文書を直してよいのかも、誰が受け入れるのかも決まっていない。この記事は、書いたあとの ADR を現状とずれないように回す運用を、AWS の規範的ガイダンスの ADR プロセスをもとに整理します。
この記事の結論
- ADR には状態があり、提案中・受け入れ済み・却下・置き換え済みの流れで回します。
- 受け入れた ADR は書き換えません。違う決定が要るなら新しい ADR を提案し、受け入れられたら古い方を「置き換え済み」にします。
- 却下するときも理由を残すと、同じ議論の蒸し返しを防げます。
- 変更のレビューで ADR を参照し、決定に反する変更には ADR へのリンクを添えて直してもらいます。
- 一覧（決定ログ）を、見出しだけで拾い読みできる状態に保ちます。
ADR は書いたあとどうなるのか？
ADR は書いて終わりの文書ではなく、状態を持って移り変わる文書です。AWS の規範的ガイダンスでは、状態として次の4つが挙げられています。
| 状態 | 英語表記 | 意味 |
|---|---|---|
| 提案中 | Proposed | 書かれてレビューを待っている。まだ決まっていない |
| 受け入れ済み | Accepted | 議論を経て、この決定を採ると決まった |
| 却下 | Rejected | 議論の結果、採らないと決まった |
| 置き換え済み | Superseded | 受け入れていたが、後の新しい ADR で置き換えられた |
書き方そのもの（文脈・決定・結果）は、前の記事の 
READ ALSO — 学習中向け・段2 構成
ADR（設計判断の記録）の書き方｜「なぜそうしたか」を文脈・決定・結果の3点で残す
で扱いました。この記事が扱うのは、書かれた ADR がこの4つの状態をどう移るかです。
流れは一方通行ではありません。レビューで直す点が出たら、提案に戻して書き直します。受け入れられたものだけが、現場の「決まっていること」になります。
LIFECYCLEADR の状態
ADR は提案 → レビュー → 受け入れか却下で回す
-
Proposed
提案中。まだ決まっていない
-
レビュー
直す点が出たら提案に戻る
-
Accepted
受け入れ。現場の決まりになる
-
Rejected
却下。理由を残す
提案から受け入れまでの回し方
提案から受け入れまでを回すとき、決めておくことは多くありません。ガイダンスの考え方をもとに、小さなチームでも使える形にまとめると次のとおりです。
- オーナーを決める。 ADR の更新と周知を受け持つ人です。決まったことが誰にも知られないまま終わるのを防ぎます。
- レビューの負担を軽くする。 ガイダンスは、レビューする人が10〜15分で読み切れる長さを目安にしています。長すぎる文書は、読まれずに受け入れられるか、放置されます。
- 日付と関係者を足す。 提案した日、受け入れた日、意見を出した人を書いておくと、後から「誰がいつ決めたか」を追えます。
- 決めたあとに状態を更新する。 受け入れたなら「受け入れ済み」、見送ったなら「却下」に変えます。
却下にも理由を残す
却下された ADR は、無駄になった文書ではありません。「この案は検討し、この理由で採らなかった」という記録です。理由が残っていれば、同じ案が別の人から再び出てきたときに、議論を最初からやり直さずに済みます。前提が変わったと思うなら、その前提の違いを新しい提案に書けばよいのです。
CHECK 1ここまでの確認
却下した ADR に却下の理由まで残しておくのは、何のためですか?
答えと解説
答え: 1. 同じ案が再び出たときに、同じ議論をやり直さずに済ませるため
理由が残っていれば、その案が出てきたときに「前回はこの理由で見送った」と示せます。「提案から受け入れまでの回し方」の章を確認してください。
受け入れた ADR を変えたいとき
構成を見直した結果、受け入れ済みの ADR とは違う決定をしたくなることがあります。このとき元の ADR の決定の欄を書き換えたくなりますが、ガイダンスは受け入れ後の ADR を変えない前提で作られています。変えたいときの手順は次のとおりです。
- 新しい ADR を提案する。文脈に「どの ADR の決定を見直すのか」「何が変わったのか」を書く
- 通常どおりレビューし、受け入れる
- 古い ADR の状態を「置き換え済み」にし、新しい ADR への参照を添える
書き換えてしまうと、「昔はなぜそうだったのか」が消えます。後から障害の原因を調べるとき、昔の判断の根拠は重要な手がかりになります。置き換えなら、昔の判断も今の判断も、それぞれの理由つきで残ります。
EDIT VS REPLACE書き換えと置き換え
変えたいときは書き換えず、置き換える
書き換える
元の ADR を直す
- 昔の判断が消えるなぜ昔はそうだったかが追えない
- 理由の履歴が途切れる障害の調査で手がかりを失う
置き換える
新しい ADR を足す
- 新旧が両方残る古い方は置き換え済みにする
- 理由がつながって読める何が変わったかを文脈に書く
ここで注意したいのは、置き換えは「失敗の記録」ではないことです。前提が変われば最善の判断も変わります。新旧がつながって読めることが、決定ログの価値になります。
CHECK 2ここまでの確認
受け入れ済みの ADR と違う方針に決めたいとき、まず何をしますか?
答えと解説
答え: 2. 新しい ADR を提案し、受け入れられたら古い方を置き換え済みにする
受け入れた ADR は後から変えない決まりです。新しい ADR で置き換えれば、昔の判断とその理由が履歴として残ります。「受け入れた ADR を変えたいとき」の章を読み直してください。
変更のレビューで ADR を使う
ADR は、変更のレビューで参照されて初めて、現場を縛る力を持ちます。ガイダンスもコードレビューで ADR を参照することを挙げています。
レビューをする側は、次の順で見ます。
- 変更が、受け入れ済みの ADR の決定に触れていないかを見る
- 反していれば、ADR へのリンクを添えて、直してもらうよう伝える
- 変更する側に「ADR のほうが現状に合わない」という理由があるなら、直すのは変更ではなく ADR 側と判断する。新しい ADR の提案に進む
リンクを添えるのが大事なのは、批判ではなく「決まっていること」を示せるからです。相手は、何が決まっていて、なぜ決まったのかを、その場で読めます。
また、AWS の例では、決定を守れているかの確認方法を「遵守事項」の節に残す書き方が示されています。たとえば「この通信はこの経路だけを通す」と決めたなら、それをどう確かめるかも書いておきます。レビューする人が、何を見ればよいか迷いません。
REVIEW変更のレビュー
決定に反する変更は、ADR のリンクを添えて直してもらう
-
変更を見る
ADR の決定に触れていないか
-
反している
決まっていることと照らす
-
リンクを添える
何が決まり、なぜかを示す
-
直して承認
変えたいなら新しい ADR へ
CHECK 3ここまでの確認
変更のレビュー中に、既存の ADR の決定に反する変更を見つけました。どうしますか?
答えと解説
答え: 2. ADR へのリンクを添えて、変更を直してもらう
リンクを添えると、何が決まっていてなぜかを相手がすぐ読めます。それでも変えたい理由があるなら、新しい ADR の提案に進みます。「変更のレビューで ADR を使う」の章を読み直してください。
決定ログを古くしない
ADR が増えてきたら、一覧にして持ちます。ガイダンスは、これを決定ログと呼んでいます。決定ログは、ADR を1つずつ開かなくても、いま有効な決定が何かを拾い読みできるようにするためのものです。
一覧に載せるもの
- 番号とタイトル（見出しだけで中身が分かる書き方にする）
- 状態（受け入れ済み・置き換え済みなど）
- 置き換えたもの・置き換えられたものへの参照
タイトルを「データベースの選定」のようにぼかさず、「注文データは関係データベースに置く」のように決定そのものを書くと、一覧が読み物になります。
見直しのきっかけ
放っておくと古くなるので、見直すきっかけを決めておきます。決定を採るときの前提が変わったとき、たとえば要件や使うサービスの条件が変わったときや、ADR に反する変更が繰り返し出てきたときです。後者は、現場のほうが正しくて、ADR が古くなっているという合図かもしれません。
やりすぎない線引き
すべての変更に ADR を求めると、続きません。後で変えにくく影響が広い判断だけを対象にし、日々の細かな設定の調整は対象外にします。続かない運用は、運用がないのと同じです。
学習者の1人運用ならどう簡略化するか
1人で学習用の構成を作っているなら、レビュー相手も周知の相手もいません。それでも次の最小の形は使えます。
- ADR を、リポジトリの
docs/adrのような決まった場所に、番号つきのファイルとして置く - 状態の欄を必ず書く。1人でも「提案中」と「受け入れ済み」を区別する
- 変えるときは書き換えず、新しい ADR を足して、古い方を「置き換え済み」にする
- 構成を変える前に、一覧（番号とタイトルと状態）を見る習慣をつける
これは運用の考え方の例であり、特定のツールの手順ではありません。レビューを自分に向けて行うだけでも、「なぜそうしたか」を数週間後の自分に渡せます。選択肢を比べる観点を広げたいときは、次の記事に進んでください。
READ ALSO — プロフェッショナル向け・段4 設計
トレードオフの考え方｜「なぜそのサービスか」を根拠つきで説明する型と、Well-Architected の6本柱の使い方
Cloudory 執筆者（AWS 認定 全冠）
ADR は、書いたことよりも、あとから開いて役に立つかどうかで価値が決まります。状態を書く、書き換えない、変更のたびに参照する。この3つを守るだけでも、決定ログは現場とずれにくくなります。
参照ソース
- AWS 規範的ガイダンス: ADR プロセス — 状態（Proposed / Accepted / Rejected / Superseded）、受け入れ後は変えないこと、置き換え、オーナー、レビューの読む時間、コードレビューでの参照、決定ログの根拠に使用
- AWS 規範的ガイダンス: ADR の付録（例） — 状態・日付・文脈・決定・結果・遵守事項・変更履歴を持つ ADR の例の根拠に使用
