公開2026.08.03更新2026.10.01 アーキテクチャ

Any Decision Recordとは｜ADRの範囲をAnyに広げる判断基準とテンプレート・運用設計

Any Decision Recordとは、ADRの頭文字Aを Architecture ではなく Any と読み替え、領域も大小も問わず決定を残す運用を指します。ADRの情報を集約する adr.github.io にも、ADRの用途は設計やその他の決定へ広げられる（”any decision record”）と書かれており、思いつきの造語ではありません。国内では2026年8月3日に、Dress Code株式会社がアーキテクチャに限らず意思決定を全部残す運用の記事をZennで公開しました。同社はエンジニア15人・PdM／デザイナー6人の体制で、1年半に積み上げた記録は450本超です。

この記事では、定義と出典を押さえたうえで、記録対象をどこまで広げるかの線引き、書き手が潰れない粒度とそのままコピーできるテンプレート、リポジトリ内MarkdownとNotionのようなデータベースのどちらに置くか、AIから引かせる前提での書き方、そして更新が止まったときに古い記録を洗い出すスクリプトまでを扱います。ADRそのものの定義と記入項目はADR（アーキテクチャ決定記録）の書き方とテンプレートで解説しているため、本記事では範囲を広げる側の判断に絞ります。

まとめ｜ADRの範囲をAnyへ広げる採否条件と保管先・失速対策の結論

Any Decision Recordは別の手法ではなく、ADRの記録対象をアーキテクチャ以外へ広げた運用です。フォーマットは従来のADRやMADRをそのまま使えます。変わるのは対象範囲と、それに伴う粒度・保管先・レビューの設計だけです。

Any化の可否を分けるのは、書き手の人数と決定の発生頻度です。開発者が5人を下回り、決定が口頭で完結している組織では、記録が資産になる前に書く負担だけが残ります。先にアーキテクチャ決定だけで20〜30本を積み、参照される実感が出てから範囲を広げる順序を推奨します。

保管先は「非エンジニアが読み書きするか」で決まります。読み手が開発者に閉じるならリポジトリ内Markdown、PdMやデザイナーが参加するならNotionのようなデータベース型。両方に置く二重管理は、検索漏れと更新停止の最大の原因になるため避けてください。

失速対策の要点は3つ。更新の止まった記録を週次で洗い出す担当を置くこと（リポジトリ運用なら本文のスクリプトで自動化できます）、古い記録は書き換えず置き換え記録を新設すること、そして書き手に短期の見返り（オンボーディングの回答源泉、開発タスクからの関連記録の自動提示）を用意することです。受託開発では、ADRを契約上の納品物に含めず引き継ぎ資料として別立てにすると、検収を意識した硬い文章になりません。

Any Decision Recordとは何か：ADRのAをAnyへ読み替える定義と出典

「Any Decision Record」という言葉は、特定の企業が作った商標でも新しい規格でもありません。ADRという既存の記録様式の中で、記録対象を広げる考え方に付いた呼び名です。出典を3つ押さえておくと、社内で導入を提案するときの説明に困りません。

Nygardが2011年に広めたADRの5項目と1記録1決定の原則

ADRを広めたのは、Michael Nygardが2011年11月15日に公開したDocumenting Architecture Decisionsです。提案された様式は Title、Context、Decision、Status、Consequences の5項目で、状態は proposed、accepted、deprecated、superseded のいずれかを取ります。1本は1〜2ページに収め、箇条書きではなく文章で書くことが勧められています。

Any化しても、この骨格は変わりません。1本に1つの決定、背景と結論と影響をセットで残す、状態で有効か置き換え済みかを示す。この3点が守られていれば、記録対象がアーキテクチャでも命名方針でも同じ仕組みで扱えます。

adr.github.ioが「any decision record」と明記した拡張範囲

ADRの用語や道具をまとめた adr.github.io では、ADRを「アーキテクチャ上重要な要件に応える、理由付きの設計判断を1つ記録するもの」と定義したうえで、用途は設計やその他の決定に拡張できると添えています。その括弧書きが “any decision record” です。

つまり、ADRコミュニティの側でもAnyへの拡張は想定内の使い方として扱われています。Dress Codeの事例はこの拡張を組織全体で徹底した例であり、記録の母数が月50〜60本まで増えたときに何が起きるかを公開した点に価値があります。

MADRの名称がAnyからArchitecturalへ戻った2024年の経緯

Markdownで書くADRの様式として普及している MADR は、名称そのものが一度Anyに変わっています。3.0.0-beta（2022年5月17日）のリリースノートには「Markdown Architectural Decision Record」を「Markdown Any Decision Record」へ改名したと記載があり、4.0.0-beta（2024年9月2日）で「Markdown Architectural Decision Record」へ戻されました。2026年10月1日時点の公式ページの表記もArchitecturalです。

名称が戻ったからといって、Anyの使い方が否定されたわけではありません。テンプレートの項目はアーキテクチャ以外の決定にもそのまま当てはまり、Any化した運用でもMADRを流用できます。検索で「Any Decision Record」と「MADR」が並んで出てくるのは、この改名の経緯があるためです。

Anyへの読み替えで記録対象に加わる決定と意図的に除外する範囲

Any化の実体は、フォーマットの変更ではなく対象範囲の拡張です。何が新しく記録に入り、何を入れないかを先に決めないと、記録の粒度が人によってばらつきます。

Architecture限定運用が取りこぼす決定の具体例と発生頻度

Dress Codeの事例で記録対象に挙がっているのは、アーキテクチャ選定に加えて、開発プロセスの変更、ツール選定、命名方針、コードレビューの心得、AWSのコスト削減検討（Compute Savings Plansの検討など）、ライブラリのアップグレード調査、そして「その機能をやらないと決めた理由」です。このうちアーキテクチャ決定に該当するのは一部にすぎません。

取りこぼしが響くのは「やらない判断」です。実装されなかった決定はコードにもチケットにも痕跡が残らず、半年後に同じ議論が再燃します。同社の記録本数が直近3ヶ月で月50〜60本まで伸びたのは、この種の非アーキテクチャ決定が母数として大きいためと読めます。

やらない判断や命名方針までADRに含める際の線引きと除外の具体例

含めるかどうかは、判断基準を1つに絞ると運用が安定します。「6ヶ月後に入った人が、この状態を見て『なぜこうなっているのか』と聞いてくるか」。聞いてくるなら記録し、聞いてこないなら記録しません。

この基準で除外されるのは、手順書に落ちる作業（デプロイの実行手順、環境変数の設定方法）、誰が検討しても結論が変わらない機械的な選択、個人の調査メモです。逆に、命名方針のように「他の案もあり得たのに一方を選んだ」ものは、規模が小さくても記録側に入ります。

仕様の記録先をADRとタスク管理ツールのどちらに置くかの判断基準

Dress Codeが運用課題として明示しているのが「仕様はADRかBacklogか」の曖昧さです。ここは記録の中身で切り分けます。採用しなかった選択肢とその却下理由を含む「なぜ」はADR、実装する内容そのものと受け入れ条件はタスク管理ツール。両方に同じ文章を置かないという一点だけ守れば、参照先で迷いません。

設計の詳細をまとまった文書として残したい場合は、ADRではなく設計文書の枠組みが向きます。判断の記録と設計の記述は目的が別で、デザインドック（Design Doc）の書き方と項目テンプレートで整理した構成のほうが、複数の決定をまたぐ全体像を書くのに適しています。組織の知識をどの文書に何として残すかという全体設計は、ナレッジマネジメントの意味と導入手順で扱っている形式知化の考え方と同じ構図です。ADRはそのうち「判断の理由」を受け持つ器と位置づけると、他の文書との役割分担が決まります。

累計450本の運用実績から逆算するADRの粒度設計と書き手の負荷配分

公開されている本数と人数から、1人あたりの負担を逆算できます。この数字を先に置くと、粒度の設計が感覚論になりません。

月数本から月50〜60本へ増えた3段階の立ち上がりと必要な人数規模

Dress Codeの立ち上がりは3段階でした。導入から1年は月数本、2025年半ばで月10本台、直近3ヶ月は月50〜60本ペース。2026年7月時点の累計は450本超で、1年半の平均に均すと月25本前後になります。

体制はエンジニア15人とPdM・デザイナー6人の計21人。つまり月50〜60本というピークでも、1人あたりは月2〜3本です。逆に言えば、5人規模のチームが同じ密度を狙うと1人あたり月10本を超え、続きません。立ち上げ期の月数本というペースのほうが、規模の小さい組織には現実的な目標になります。

1人あたり月2〜3本へ収める粒度設計と長文化したときの分割基準

1人月2〜3本という上限から粒度を決めると、1本は「1つの決定と、却下した選択肢の比較」に収まる長さになります。目安として、却下理由を書く対象が3案を超える、あるいは決定が2つ以上含まれるなら分割してください。

分割の判断で迷ったら、タイトルが「AとBの決定」のように接続詞でつながるかを見ます。つながるなら2本です。1本に詰め込むと、後から片方だけが古くなったときに置き換えができません。

MADR 4.0.0系の項目をAny化した記録に流用するときの過不足

テンプレートを新規に設計する必要はなく、既存フォーマットの流用で十分です。MADRは4.0.0系がGitHubのリポジトリで2024年9月17日に公開されており、項目は Context and Problem Statement、Decision Drivers、Considered Options、Decision Outcome、Consequences、Confirmation、Pros and Cons of the Options、More Information で構成されます。冒頭のメタデータには status、date、decision-makers、consulted、informed を置けます。

Any化した記録では、この全項目を埋めることが過剰になる場面もあるのです。命名方針やレビュー運用の決定に Confirmation（決定が守られていることの確認方法）を毎回書かせると、書き手の手が止まります。MADR自身も必須を文脈・検討した選択肢・決定内容の3つとし、残りを任意としています。必須項目だけを収めた adr-template-minimal.md も同梱されているため、Any化ではこの最小版を起点にするのが実務的です。

Any化向けに必須3項目へ絞ったMADR派生テンプレートの記入例

以下は、MADRの最小構成に「領域」と「決定の種類」の2項目を足した記入例です。area と kind はMADRの標準項目ではなく、後述するタグ設計のために独自に加えたもので、内容は説明用の架空の決定です。リポジトリなら docs/decisions 配下に 0042-skip-point-combination.md のような名前で置けます。

---
status: accepted
date: 2026-10-01
decision-makers: 山田（PdM）, 佐藤（テックリード）
area: 決済画面
kind: 見送り
---

# 決済画面のポイント併用は2026年度は実装しない

## Context and Problem Statement

前提：2026年10月時点、決済担当2名、年末商戦までの残り8週間。
ポイント併用の要望が月3件届いているが、決済代行側の仕様確認に4週間かかる見込み。

## Considered Options

* 年末商戦前に併用を実装する
* 併用は見送り、ポイント単独払いのみ残す
* 外部のポイント基盤に置き換えてから併用する

## Decision Outcome

Chosen option: "併用は見送り、ポイント単独払いのみ残す", because 決済担当2名で8週間の期限内に検証まで終えられないため。
再検討の条件：決済担当が3名以上になる、または併用要望が月10件を超えたとき。

書き方の要は2つあります。1つは前提（時点・人員・期限）を文脈の先頭に置くこと。もう1つは「再検討の条件」を決定の直後に1行で書くことです。見送りの決定は特に、条件が変われば覆る前提で残すほうが、半年後の読み手が今も有効かを判断できます。

リポジトリ内MarkdownとNotion等データベースの保管先を分ける条件

保管先の選定は、Any化で最初に揉める論点です。範囲を広げると読み手にエンジニア以外が入るため、リポジトリ内で完結しなくなります。

リポジトリ内Markdownが向く条件とプルリクエスト経由の動線

リポジトリ内に docs ディレクトリを切って置く方式は、決定の大半が実装に紐づく組織に向きます。プルリクエストのレビュー動線にそのまま乗るため、決定と実装が同じ履歴に並び、後から「いつのコミットでこの方針になったか」を追えます。

この方式の限界は読み手です。PdMやデザイナーがGitHubのUIを日常的に開かない組織では、書かれても読まれません。読まれない記録は更新もされず、半年で参照価値を失います。

adr-toolsで採番と置き換えを自動化するリポジトリ内運用の手順

リポジトリ内に置くなら、採番と置き換えを手作業にしないことが続けるコツです。シェルスクリプト製の adr-tools を使うと、連番の付与と「置き換え済み」への状態変更をコマンド1つで済ませられます。既定の置き場は doc/adr で、初期化時に別のディレクトリを指定できます。

# 初回だけ：記録の置き場を作り、1本目の記録が生成される
adr init docs/decisions

# 新しい記録を採番して作る（エディタは環境変数 VISUAL か EDITOR で指定）
adr new Move decision records to Notion database

# 12番の記録を置き換える新しい記録を作る（12番の状態は置き換え済みへ更新される）
adr new -s 12 Move decision records back to repository

タイトルはファイル名にも使われるため、英数字で付けてから本文の見出しを日本語に書き換える運用が扱いやすくなります。なお、adr-toolsが生成するのはNygard形式の記録です。MADRの項目で揃えたい場合は、MADRのテンプレートを置き場にコピーして手で採番するか、どちらか一方の形式に統一してください。2つの形式が混ざると、後述する洗い出しスクリプトの判定条件も2通り要ります。

Notionなどデータベース型が向く条件と非エンジニアの参加動線

Dress Codeは21人中6人が非エンジニアで、保管先にNotionのデータベースを選んでいます。プロパティで領域や状態を絞り込め、週次の読み合わせで一覧を共有する運用と噛み合うためです。

データベース型の弱点は、コードとの距離が開くこと。実装が変わっても記録側が自動では追随しません。ここは後述するレビュー運用で埋める前提になります。

保管先の選定を分ける4つの条件と二重管理・検索漏れを防ぐ運用規約

4つの条件で機械的に振り分けられます。判断が割れたら、読み手の構成を最優先の軸としてください。

条件	リポジトリ内Markdown	データベース型
読み手の構成	開発者にほぼ限定	PdMやデザイナーを含む
決定と実装の距離	同じ変更で追える	別管理になる
横断検索	全文検索に依存	プロパティで絞り込み
非開発者の書き込み	手順の習得が要る	そのまま書ける
採番と置き換え	adr-toolsで自動化	プロパティで手管理

やってはいけないのは、両方に置いて同期する運用です。片方だけ更新された記録が生まれ、検索でどちらが最新か判別できなくなります。片方を正とし、もう片方にはリンクだけを置くという規約を、運用開始時に文章で固定しておいてください。

AI検索を前提にしたADRのタイトル・タグ・前提条件の書き分け設計

Dress Codeでは、Notion AIによる検索、議事録からの下書き生成、開発タスクからの関連記録の自動抽出までを運用に組み込んでいます。AIに引かせる前提で書く場合、人間が読む前提の書き方とは異なる要件が必要です。議事録から下書きを起こす場合、元になる議事録の精度と機密の扱いが記録の質を左右するため、AI議事録・自動文字起こしの仕組みと選び方で整理した観点を先に確認しておくと、下書きの手直しが減ります。

AIが引ける記録にするためのタイトル命名規則と前提条件の明示

タイトルは「対象＋決定内容」の形に揃えます。「Notionについて」ではなく「ADRの保管先をNotionデータベースへ移す」。対象語だけのタイトルは、検索でも生成でも他の記録と区別がつきません。

もう1つ落としがちなのが前提条件です。決定した時点、対象範囲、制約（人員・期限・既存資産）を本文の先頭に置きます。要約を生成させると、前提の記述がないものは無条件の結論として出力され、条件が変わった後も有効な決定として読まれてしまいます。

タグ設計で決まる関連ADRの自動抽出精度と最小限にすべき分類軸

分類軸は3つまでに絞ってください。領域（対象のプロダクトや機能）、決定の種類（技術選定・プロセス・命名・見送り）、状態（有効・置き換え済み）。この3軸なら、書き手が迷わず付けられます。前掲のテンプレートでいえば area、kind、status の3項目がこれに当たります。

軸を増やすほど付け漏れが増え、自動抽出の再現率が落ちます。月50本のペースで積む前提なら、タグ入力に30秒以上かかる設計は成立しません。

Notion MCP接続で開発ツール側からADRを引くときの前提

記録をNotionに置く場合、エディタやコーディング支援ツールから直接参照させる接続手段があります。Notion MCPサーバーの接続手順で扱っている接続を通すと、開発中の文脈から過去の決定を引けます。

前提として押さえたいのは権限の効き方です。Notion公式のMCP解説によると、Notionがホストするリモートサーバーへ OAuth で接続を認可すると、MCPクライアントは認可した本人がアクセスできる内容を読み書きできます。権限の広い管理者が接続すると、人事や経営の情報まで参照対象に入ります。ADR専用のデータベースを分け、参照させる利用者の権限もその範囲に収めておく設計が、無難な選択です。

更新が止まるADRを防ぐ週次レビュー運用と置き換え記録の作成基準

Dress Codeが課題として挙げているのが「更新されない問題」です。書く文化が根づいた後に必ず来る局面で、放置すると記録全体の信頼が落ちます。

週次読み合わせで更新の停止を検知するレビュー運用と担当の置き方

同社は週次の読み合わせを運用に組み込んでいます。検知の仕組みとしては、状態が有効のまま一定期間更新されていない記録を一覧化するのが手軽です。期間の目安は90日。四半期に一度は目を通す計算になります。

担当は持ち回りにしてください。特定の1人に固定すると、その人の離脱で運用ごと止まります。読み合わせの場で決めるのは「この記録はまだ有効か」の一点に絞り、修正作業そのものは持ち帰ります。

状態が有効のまま90日更新のない記録をgitの履歴から洗い出す

リポジトリ内に置いている場合、読み合わせの一覧は手で作らずスクリプトで出せます。以下は、前掲のMADR形式のテンプレートを前提に、status: accepted の記録のうち最終コミットから90日以上経ったものを列挙するPythonです。ファイルの更新日時はクローンし直すと変わるため、gitの最終コミット日を基準にしています。

# stale_adr.py：状態が有効のまま90日以上更新のないADRを列挙する
import datetime
import pathlib
import re
import subprocess

DECISIONS = pathlib.Path("docs/decisions")
LIMIT_DAYS = 90
today = datetime.date.today()

for md in sorted(DECISIONS.glob("[0-9][0-9][0-9][0-9]-*.md")):
    text = md.read_text(encoding="utf-8")
    m = re.search(r"^status:\s*\"?(\w+)", text, re.M)
    if not m or m.group(1) != "accepted":
        continue
    # ファイルの最終コミット日（YYYY-MM-DD）をgitから取る
    out = subprocess.run(
        ["git", "log", "-1", "--format=%cs", "--", str(md)],
        capture_output=True, text=True,
    ).stdout.strip()
    if not out:
        continue
    age = (today - datetime.date.fromisoformat(out)).days
    if age >= LIMIT_DAYS:
        print(f"{age:4d}日  {md.name}")

リポジトリのルートで python stale_adr.py と実行すると、経過日数とファイル名が1行ずつ出ます。この出力を読み合わせの議題にそのまま貼れば、担当が持ち回りでも準備の手間はほぼかかりません。CIで週1回走らせ、結果をチャットへ流す形にすると、担当が忘れても一覧が届きます。Nygard形式の記録では状態が見出しの下の本文に書かれるため、正規表現を置き場の形式に合わせて書き換えてください。

古い記録を書き換えず置き換えADRを新設する場合の具体的な判断基準

基準は単純です。前提や結論が変わったなら新しい記録を作り、元の記録は状態を置き換え済みに変えてリンクだけ張る。誤字、リンク切れ、事実誤認の訂正は元の記録を直します。リポジトリ運用なら、前述の adr new -s がこの手順をそのまま実行します。

元を上書きしてしまうと、「なぜ以前はそう決めたのか」が消えます。同じ論点が再燃したとき、過去に却下した理由を再検討できないのが最大の損失です。設計文書とコードの乖離を継続的に埋める考え方は整合性駆動開発（CoDD）による設計とコードの同期でも扱っており、記録側の鮮度管理にも同じ発想が使えます。

書き手への短期リターンを設計してADRの執筆を続かせる社内の仕組み

Dress Codeは書き手への短期的なリターン不足を課題として挙げています。裏を返せば、リターンを作れれば続きます。同社が実際に接続しているのは、新メンバーのオンボーディング質問への回答源泉、開発タスクからの関連記録の自動提示、記録を画像生成AIでグラフィックレコーディング風に変換する仕組みです。

効果が出やすいのはオンボーディングです。新メンバーの質問に「その決定はこの記録にあります」と返せる回数が増えると、書いた本人が説明工数の削減を体感します。数値で追うなら、入社1ヶ月の質問件数の推移を見るのが分かりやすい指標になります。

Any化を見送る開発現場の条件と受託開発での引き継ぎ資産化の判断

ここまでの条件を踏まえて、導入の可否を言い切ります。Any化は文化の話であって、ツールを入れれば成立するものではありません。

Any化を採用しない方がよい3つの条件と先に整えるべき記録の土台

次の3つのいずれかに当てはまるなら、Any化は見送ってください。第1に、開発者が5人を下回り、決定が口頭で完結している場合。記録が参照される回数より書く時間のほうが多くなります。第2に、3ヶ月以内に終わる単発案件。参照される将来が来ません。第3に、設計文書の運用が既に回っている場合。両方を並行させると、どちらに書くかの判断コストが記録の価値を上回ります。

見送ると決めたなら、先にアーキテクチャ決定だけで20〜30本を積んでください。実際に「あの記録を見て決めた」という場面が月に数回起きるようになった段階が、範囲を広げる合図です。順序を逆にすると、書かれた記録が読まれないまま残ります。

受託開発の納品物にADRを含める場合の契約上の扱いと引き継ぎ範囲

受託開発でAny化した記録を残すなら、契約上の扱いを先に決めてください。納品物として検収対象に含めると、記録が体裁を整えるための文書に変質します。却下した選択肢の率直な記述や「やらないと決めた理由」は、検収を意識した瞬間に書けなくなるためです。

実務的な落としどころは、納品物には設計文書と操作手順を含め、ADRは引き継ぎ資料として別立てにする形。移管時にエクスポートして渡す前提であれば、保管先をデータベース型にしておくと出力の手間が小さくなります。リポジトリ内に置いた場合は、リポジトリの移管とともに記録も引き継がれるため、別途の受け渡し作業は要りません。

内製化と保守運用への移行局面でADRが効く場面と効かない場面の線引き

効くのは、担当者が入れ替わる局面です。保守フェーズでの引き継ぎ、開発の内製化に伴う巻き取り、障害対応時の「なぜこの構成なのか」の確認。いずれも当事者が不在の状態で判断の背景をたどる場面で、記録の有無が調査時間を左右します。

効かないのは、決定がまだ固まっていない探索フェーズです。仮説が週単位で変わる段階で記録を積んでも、置き換え済みの記録ばかりが増えます。外部の体制へ運用を移す、あるいは自社で巻き取るといった移行の設計は保守運用・内製化支援で扱っており、記録の整備範囲もこの移行計画と合わせて決めると無駄が出ません。

よくある質問

Any Decision Recordの導入を検討する際に、実務でよく挙がる質問をまとめました。

Any Decision RecordはArchitecture Decision Recordと別物ですか？

別の手法ではなく、同じADRの記録対象を広げた運用です。頭文字のAをArchitectureからAnyへ読み替え、アーキテクチャ以外の決定も同じ枠組みで残します。adr.github.ioにも、ADRの用途は設計やその他の決定へ広げられると書かれています。フォーマットは既存のものをそのまま流用でき、MADRのようなテンプレートも利用可能です。違いは対象範囲と、それに伴う保管先・粒度・レビュー運用の設計です。

ADRとDesign Docはどう使い分ければよいですか？

ADRは1つの決定と却下した選択肢を短く残すもの、Design Docは機能や仕組み全体の設計を通しで書くものです。判断の履歴を追いたいならADR、実装前に全体像を共有したいならDesign Doc。両方を運用する場合は、Design Docの中で下した個別の決定をADRとして切り出し、相互にリンクする形にすると重複しません。片方に寄せる場合、Any化を選ぶなら記録の粒度が小さいADR側が扱いやすくなります。

Any化したADRは1本あたりどのくらいの分量が適切ですか？

1つの決定と、却下した選択肢の比較が収まる長さが目安です。Nygardの原典も1〜2ページを想定しています。却下理由を書く対象が3案を超える、または決定が2つ以上含まれるなら分割してください。分量そのものより、1本1決定を守るほうが後の運用に効きます。決定が複数入った記録は、片方だけ前提が変わったときに置き換えができず、そのまま古い記述として残ってしまうためです。

ADRの保管先をNotionにするとリポジトリとの整合はどうなりますか？

自動では追随しないため、レビュー運用で埋める前提になります。実装が変わっても記録側は変わらないので、状態が有効のまま90日以上更新のない記録を一覧化し、週次または隔週で棚卸しする担当を置いてください。リポジトリ側にはリンクだけを置き、本文を両方に持たないことが条件です。二重に持つと、どちらが最新か判別できなくなります。

少人数のチームでもAny Decision Recordは成立しますか？

開発者が5人を下回る規模では推奨しません。決定の多くが口頭で完結し、記録を参照する場面が生まれにくいためです。目安として、月50〜60本という密度は21人規模で1人あたり月2〜3本の計算になりますが、5人で同じ密度を狙うと1人月10本を超えます。少人数で始めるなら、アーキテクチャ決定に絞って月数本のペースから積み、参照される実感が出てから範囲を広げてください。

Any Decision Recordを始めるのに専用ツールは必要ですか？

必要ありません。Markdownファイル1つとテンプレートがあれば始められます。リポジトリに置くなら、採番と置き換えを自動化するadr-toolsのような道具を後から足す形で十分です。Notionに置くなら、状態・領域・決定の種類の3プロパティを持つデータベースを1つ作れば運用できます。先に道具を選ぶより、最初の20〜30本を書いて「参照された」実感を得るほうが、定着の確度は上がります。