Any Decision Recordとは｜ADRの範囲をAnyに広げる判断基準と運用設計

ADRの頭文字Aを Architecture ではなく Any と読み替え、領域も大小も問わず決定を残す運用が、2026年8月3日にDress Code株式会社のテックブログで公開された事例です。同社はエンジニア15人・PdM／デザイナー6人の体制で、1年半に積み上げた記録は450本超です。この記事では、記録対象をどこまで広げるかの線引き、書き手が潰れない粒度、リポジトリ内MarkdownとNotionのようなデータベースのどちらに置くか、AIから引かせる前提での書き方、そして更新が止まったときの立て直し方を扱います。ADRそのものの定義と記入項目はADR（アーキテクチャ決定記録）の書き方とテンプレートで解説しているため、本記事では範囲を広げる側の判断だけを扱います。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

設計の詳細をまとまった文書として残したい場合は、ADRではなく設計文書の枠組みが向きます。判断の記録と設計の記述は目的が別で、デザインドック（Design Doc）の書き方と項目テンプレートで整理した構成のほうが、複数の決定をまたぐ全体像を書くのに適しています。

累計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（adr.github.io で公開されるMarkdownベースの様式）は4.0.0系が2024年9月に公開されており、項目は 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（決定が守られていることの確認方法）を毎回書かせると、書き手の手が止まります。必須は文脈・却下した選択肢・決定内容の3つ、残りは任意という運用に落とすのが実務的です。

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

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

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

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

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

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

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

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

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

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

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

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

Dress Codeでは、Notion AIによる検索、議事録からの下書き生成、開発タスクからの関連記録の自動抽出までを運用に組み込んでいます。AIに引かせる前提で書くと、人間が読む前提の書き方とは要件が変わります。

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

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

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

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

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

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

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

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

前提として、参照させたいデータベースへの権限付与が必要です。権限の範囲を絞りすぎると関連記録が抽出されず、広げすぎると人事や経営の情報まで参照対象に入ります。ADR専用のデータベースを分けておくのが無難な設計になります。

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

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

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

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

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

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

基準は単純です。前提や結論が変わったなら新しい記録を作り、元の記録は状態を置き換え済みに変えてリンクだけ張る。誤字、リンク切れ、事実誤認の訂正は元の記録を直します。

元を上書きしてしまうと、「なぜ以前はそう決めたのか」が消えます。同じ論点が再燃したとき、過去に却下した理由を再検討できないのが最大の損失です。設計文書とコードの乖離を継続的に埋める考え方は整合性駆動開発（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へ読み替え、アーキテクチャ以外の決定も同じ枠組みで残します。フォーマットは既存のものをそのまま流用でき、MADRのようなテンプレートも使えます。違いは対象範囲と、それに伴う保管先・粒度・レビュー運用の設計です。定義や記入項目そのものは従来のADRと変わりません。

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

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

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

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

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

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

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

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

関連記事

• ADR（アーキテクチャ決定記録）とは｜書き方・テンプレート・design docとの違い：定義、記入項目、Markdownテンプレート、ライフサイクルはこちらで解説しています。
• デザインドック（Design Doc）とは｜書き方・項目テンプレート：設計全体を通しで書く文書の構成。ADRとの併用時の役割分担の参考に。
• Design Docsとは何か？その定義と概要についての完全ガイド：設計文書の位置づけを基礎から整理したい場合に。
• 整合性駆動開発（CoDD）とは：設計書とコードの乖離を継続的に埋める手法。記録の鮮度管理と発想が共通します。
• Notion MCPサーバーのURL・接続方法まとめ：Notionに置いた記録を開発ツール側から引くための接続手順。