Post
JA EN

AI時代にADRが再評価される理由——AIが台帳を管理し、人は「なぜ」を監督する

Posted
By
29 min read
AI時代にADRが再評価される理由——AIが台帳を管理し、人は「なぜ」を監督する
  • 想定読者： DDD開発でADRをどう使うか を読んで、「なぜ”AIの時代”にADRなのか、その理屈と根拠を知りたい」と思った人。実務の手順ではなく、背景・構造・エビデンスに関心がある読者
  • 前提知識： ADR（Architecture Decision Record）とは何かを知っていること。DDDの基本概念があるとなお良い
  • 所要時間： 約18分

概要

DDD開発でADRを「どう使うか」は別記事（実践編）で手順としてまとめた。本記事はその裏事情——なぜいま、しかもAI開発の文脈でADRが再評価されるのか、その構造とエビデンス、そして限界を論考する。

要点は3つだ。(1) 紙のADRは「書かれても読まれない」文書になりがちだったが、AIは読む。決定の理由が初めて確実に参照される。(2) AIはADRを参照するだけでなく、その管理（起票・初稿生成・supersede 処理・整合性チェック）まで回せる。(3) ただしAIが決定を量産すると、今度は人の検証がボトルネックになる。だからAIには「レビューしやすい形」で書かせる必要がある。

そして本記事の核心は、最後に置くエビデンスの強弱だ。これらの主張を支える証拠は、多くが2026年のごく新しいプレプリントか、PR説明・コードレビューといった隣接領域からの類推で、ADR×AIを直接・大規模に実証した研究はまだ薄い。本記事は「こう運用すると筋が通る」という設計論であって、効果が実証された報告ではない——その線を最初に引いておく。

「読まれない文書」だったADRが、反転する

ADRは長らく、DORAメトリクスでいう「エリートチームの実践」とされてきた。書く価値は認められても、書かれた後に読まれないまま放置されることが多かった。決定の理由を残す——それ自体は正しいが、参照されなければ死蔵されたファイルにすぎない。

AIがこの構図を反転させる。Zennで議論されている言い方が端的だ——「紙のADRはしばしば読まれないまま放置された。だがAIは全部読んで即答する」1。人間が読み飛ばしてきた決定台帳を、AIは確実に参照する。「なぜXにしたのか」と問えば、AIが該当ADRを引いて答える。同記事は「設計判断が本当に生きるのは、書かれた時ではなく、書かれた後に参照された時だ」とも言う。AIは、その参照を人間よりはるかに律儀に行う。

Chris Swan も、ADRがAIコーディングアシスタント利用時の標準装備（boilerplate）になると予測する2。ADRは「キーポイントを押さえる構造はあるが自然言語」という、LLMにとって理想的な形式だからだ。さらに、複数のAIエージェントをチームのように束ねるエージェント・スウォーム開発では、複数の担い手が同じ決定台帳を共有する必要が生じる——これはまさにADRが元々支えるよう設計されたシナリオだ、と。

ただし「全部読む」は文字通りではない

ここで早速、留保が要る。「AIは全部読む」というレトリックは、技術的には正確でない。LLMによる自動ADR生成を評価した研究3は、過去のADRを全部渡す（All-History）のが最良ではなく、直近3〜5件に絞るのが品質と効率の最良バランスで、凝った検索ベースの選択（RAFG）は通常の運用では統計的に有意な差を生まなかった、と報告している。支配的なのは「モデルの規模」ではなく「何を文脈として渡すか（context engineering）」だという。

つまり「AIは読む」の正しい意味は、「人間のように放置せず、必要なものを必ず参照する」だ。全部を毎回コンテキストに積むのが最適なのではない。ここから、次の運用像が導かれる。

push と pull——AGENTS.md と ADR の渡し方

AIが読むテキストには、性質の違う2種類がある。

flowchart TB
    AGENTS["AGENTS.md / CLAUDE.md<br>いまの制約 (What)"]
    ADR["ADR 台帳<br>なぜ・却下案 (Why)"]
    AI["AIコーディング"]
    AGENTS -->|"push: 毎ターン自動で渡る"| AI
    ADR -->|"pull: 必要なときだけ引かれる"| AI

AGENTS.md（や CLAUDE.md）は push 型だ。 リポジトリ直下に置けば毎ターン自動でロードされ、ユビキタス言語の禁則や不変条件といった「いまの制約（What）」をAIに渡し続ける。

ADRは pull 型だ。 常時は渡さず、「なぜそうしたか（Why）」を必要なときにだけ引く。前述の通り、全ADRを push し続けるのはむしろ品質を下げる3。

この2つを混ぜると事故る。AGENTS.md に決定の経緯まで書けばファイルが肥大化してコンテキストを圧迫し、逆にADRに現在の制約を書けばコードの変化に追従できず陳腐化する。現在形の制約は push、決定の理由は pull——この分離が、AI時代のADR運用の土台になる。

AIがADRを「管理」する——どこまで来たか

AIの役割は、ADRを読む（参照する）だけにとどまらない。台帳の管理そのものをAIが回せるところまで来ている。

  • 起票と初稿生成：PRの差分（変更内容・コミットメッセージ）をLLMに渡し、ADRのドラフトを生成して同じブランチにコミットバックする——という運用がすでに実装されている4。
  • 標準化とメタデータ：AIエージェントの自律的な決定を記録する Agent Decision Records（AgDR） という拡張提案では、作成主体をAIとし、モデル識別子・セッションID・タイムスタンプを必須メタデータにして、hook や skill で自動化する5。
  • 分業エージェント：単一の一括プロンプトでは、コンテキスト制限とアーキ知識の分散性のために不十分だ。抽出・検索・生成・検証を分けた専門エージェントを協調させる AgenticAKM は、29リポジトリのユーザースタディで、素朴な単一プロンプトより良いADRを生成できたと報告している6。

ここまで来ると、ADRは「書く手間で放置される文書」から「AIが自動で維持する台帳」に変わる。起票・採番・supersede の相互リンク・整合性チェックといった定型作業は、AIのほうが速く、抜けがない。

ただし、AIに任せてはいけない一線がある。 AIが差分から書けるのは「何を変えたか」までだ。「なぜその案を選び、他を却下したか」は差分に現れない人間の判断であり、AIに書かせれば推測で埋められる——もっともらしいが実際とは違うWhyが、レビューを素通りして台帳に固定されるリスクがある。だから分担はこうなる——管理はAIに、戦略的な決定と「Whyの妥当性検証」は人に。

人のレビューというボトルネック、そしてその解き方

「管理はAI、検証は人」と決めると、今度は人の検証が新たなボトルネックになる。AIが決定を量産すればするほど、人が妥当性を確かめるべきADRも増えるからだ。AI生成物の評価において「人によるレビューはゴールドスタンダードだが、コストが高く遅い」ことは、医療文書の領域で繰り返し指摘されている（だからこそ、別のLLMが一次評価を行う LLM-as-a-Judge のような緩和策が研究されている）7。

人のレビューが詰まる理由は、認知負荷にある。コードレビューの古典的な大規模研究（SmartBear / Cisco、2,500レビュー・320万行）は、レビュー対象が200〜400行を超えると見逃しが急増することを示した8。Empirical Software Engineering の認知負荷研究も、対象が大きい・複雑だとレビュアーは「ファイル間の移動」に時間を取られ、評価が分析的でなく機械的（＝素通り）になると報告する8。これはコードの話だが、文書でも構造は同じだ——冗長なADRは「読まれるが見逃される」。

解き方は「AIにレビューしやすい形で書かせる」ことだ。これには根拠がある。AI生成のPR説明を分析した研究（18,256件）は、AIが書き、人が補完した説明はレビュー時間が短く、マージされやすかったと報告し9、別の研究はAIエージェントの説明スタイルの違いが、レビュアーの応答時間やマージ結果の差と関連することを示した10。一方でLLMは放っておくと冗長に流れる傾向（verbosity bias）があり、「簡潔に」と頼むだけでは効きにくい——簡潔さは構造（テンプレート）で縛るほうが確実だ11。

その「構造」の好例が、Olaf Zimmermann の Y-statement12 だ。決定の文脈・採用案・却下案・トレードオフを1文に構造化する形式で、名前の “Y” は “why” を指す——構造が「なぜ」を不可避にする。「各決定を1スライドに収められるか」という要請から生まれた、冗長さを避けるための形式だ。AIにこの形で書かせれば、人は「against（却下案）」の1行だけを見てWhyの妥当性を判断できる。レビューの目を一点に集められる。具体的な書かせ方は実践編に譲る。

エビデンスの強弱——正直なところ

ここまでの議論を支える証拠が、どれくらい強いのかを正直に整理しておく。これが本記事で最も重要な節だ。

主張支えるエビデンス強さ
レビュー対象が大きい・冗長だと人は見逃すSmartBear/Cisco（大規模）、認知負荷研究8強い（ただしコードレビュー。ADRへは類推）
構造化・AI生成＋人補完の説明はレビューが速いPR説明 18,256件の分析9、説明スタイル研究10中〜強（ただしPR説明であってADRではない）
AIの分業エージェントは良いADRを生むAgenticAKM、29リポジトリのユーザースタディ6中（小規模・2026年の新しい研究）
全部渡すより絞るほうが生成品質が高いContext Matters3中（2026年のプレプリント）
LLMは放置すると冗長出力長制御の研究群11中〜強
ADRはAI時代に再評価される／boilerplate化するKosk1、Chris Swan2実践知（実務家の観察・予測）
Y-statement で端的に書けるZimmermann12実践知（確立した形式だがRCTはない）

見ての通り、ADR×AIを直接・大規模に実証した研究はまだ存在しない。強いエビデンスはコードレビューやPR説明という隣接領域のもので、ADRへの適用は類推だ。ADRに最も近い研究（AgenticAKM、Context Matters）は2026年のごく新しいプレプリント・ワークショップ論文で、規模も小さい。残りは実務家の観察と、Y-statement のような確立した実践知に依る。

加えて、構造的な穴も残る。前述した「AIが却下理由を推測で埋め、嘘のWhyが台帳に固定される」リスクは、運用で人が検証する以外に技術的な解決を持たない。AIにADR管理を任せるほど、この検証の質が全体の信頼性を左右する。

だから、本記事の主張はあくまで「こう運用すると筋が通る」という設計論だ。「AIにADRを管理させると開発が速くなる／品質が上がる」という効果が、対照実験で測られたわけではない。そこは区別して受け取ってほしい。

まとめ

AI時代にADRが再評価されるのは、3つの反転による。

  1. 読まれない文書が、読まれる文書になる。 AIは決定台帳を律儀に参照する。ただし「全部読む」のではなく、push（現在の制約）と pull（必要な時の理由）を分けて渡すのが正確な姿だ。
  2. AIが台帳を管理する。 起票・生成・supersede・整合性チェックをAIが回し、人は戦略判断とWhyの検証だけを握る。
  3. 人の検証がボトルネックになるので、書き方で解く。 AIには構造化された端的な形（Y-statement など）で書かせ、人の目をWhy検証の一点に集める。

ただし——これらを支えるエビデンスは、隣接領域からの類推とごく新しいプレプリントが中心で、ADR×AIの直接の実証は薄い。「Why捏造」という穴も残る。ADRがAI時代に陳腐化するどころか再評価される、という見立て自体はもっともらしいが、まだ「実証された効果」ではなく「筋の通った設計論」の段階にある。実務でどう使うかは、その前提を踏まえた上で 実践編 を参照してほしい。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. A Prescription for SDD Fatigue: Recording Architectural Decisions with ADRs in the AI Era - Kosk, Zenn (2026). 「紙のADRは読まれなかったがAIは全部読んで即答する」「設計判断が生きるのは参照された時」。【信頼性: 中】（実務家ブログ） ↩︎ ↩︎2

  2. Using Architecture Decision Records (ADRs) with AI coding assistants - Chris Swan (2025-07-10). ADRはLLMに理想的な形式。DORAエリート実践から標準boilerplateへ。エージェント・スウォームで特に有効。【信頼性: 中】（実務家ブログ） ↩︎ ↩︎2

  3. Context Matters: Evaluating Context Strategies for Automated ADR Generation Using LLMs - Aviral Gupta, Rudra Dhar, Daniel Feitosa, Karthik Vaidhyanathan, EASE 2026 研究トラック (arXiv:2604.03826). 全履歴を渡すより直近3〜5件が最良バランス。検索ベース(RAFG)は線形運用では有意差なし。モデル規模よりcontext engineeringが支配的。【信頼性: 高】（査読会議トラックのプレプリント） ↩︎ ↩︎2 ↩︎3

  4. From Stale Docs to Living Architecture: Automating ADRs with GitHub + LLM - Iraj Hedayati, Medium (2025-09-14). PRの差分からLLMがADR初稿を生成し、人がレビューするワークフロー。【信頼性: 中】（実務家ブログ） ↩︎

  5. Agent Decision Records (AgDR) - me2resh, GitHub (2025). AIエージェントの自律決定をADRとして記録する拡張標準。作成主体=AI、必須メタデータ（モデル識別子・セッションID・timestamp）、hook/skill で自動化。【信頼性: 中】 ↩︎

  6. AgenticAKM: Enroute to Agentic Architecture Knowledge Management - Rudra Dhar, Karthik Vaidhyanathan, Vasudeva Varma, AGENT ‘26（arXiv:2602.04445）. 抽出・検索・生成・検証の専門エージェント協調でコードからADRを生成。29リポジトリのユーザースタディで「より良いADR」と報告。※ACM proceedings の DOI は本稿執筆時点で未解決のため arXiv を一次参照とする。【信頼性: 高】（査読ワークショップ論文、小規模だが実証あり） ↩︎ ↩︎2

  7. Evaluating clinical AI summaries with large language models as judges - npj Digital Medicine (2025). AI生成文書の評価で「人レビューはゴールドスタンダードだがコストが高く遅い」。緩和策としてLLM-as-a-Judge。【信頼性: 中〜高】（医療文脈、ADRへは類推） ↩︎

  8. Code Review at Cisco Systems（SmartBear） ／ Do explicit review strategies improve code review performance?（認知負荷研究） - SmartBear/Cisco（2,500レビュー・320万行、200〜400行超で見逃し急増）＋ Empirical Software Engineering（複雑な変更ほど認知負荷が高くレビューが機械的に）。【信頼性: 高】（コードレビュー。ADRへは類推） ↩︎ ↩︎2 ↩︎3

  9. Generative AI for Pull Request Descriptions: Adoption, Impact, and Developer Interventions - Tao Xiao, Hideaki Hata, Christoph Treude, Kenichi Matsumoto, PACMSE (2024, DOI: 10.1145/3643773). AI生成PR説明 18,256件を分析。AIが書き人が補完した説明はレビュー時間が短くマージされやすい。※PR説明であってADRではない。【信頼性: 高】 ↩︎ ↩︎2

  10. How AI Coding Agents Communicate: A Study of Pull Request Description Characteristics and Human Review Responses - Kan Watanabe ほか (2026, arXiv:2602.17084). AIエージェントの説明スタイルの違いが、レビュアーのengagement・応答時間・マージ結果の差と関連。※abstract水準、最適形の具体は本文要確認。【信頼性: 中〜高】 ↩︎ ↩︎2

  11. Concise Thoughts: Impact of Output Length on LLM Reasoning（ほかLLM出力長制御研究） - (2024-). LLMは verbosity bias を持ち長さ指示に従いにくい。簡潔化は「簡潔に」より構造での制約が有効。【信頼性: 中〜高】 ↩︎ ↩︎2

  12. Architecture Decision Record Template: Y-Statements - Olaf Zimmermann (SATURN 2012). 決定を1文に構造化するADR形式（文脈・採用案・却下案・トレードオフ）。”Y” は “why” を指す。【信頼性: 中〜高】 ↩︎ ↩︎2

AI・テクノロジー
ADR AI開発 DDD AGENTS.md 意思決定 エビデンス
This post is licensed under CC BY 4.0 by the author.