AI対話やプルリクエストの差分から、技術判断の記録を自動で残す価値はあります。ただし、最初に決めるべきは対象範囲、人間による確認の方法、そしてコミットまたはマージ前に止める仕組みです。
📑目次
記録のコストは今書く側に偏り、便益は将来のメンテナ側に寄ります。EASE 2026 の論文（arXiv 2604.03826） は、ADR を始めたリポジトリの約半数が 5 件未満で放棄する、という既存観察を引用しています。手作業の整理だけに頼ると途切れやすい、という見立てはここでも同じです。
対象判定・確認者・ゲート
採用するかどうかは、発見記事の人気度ではなく、対象判定・確認者・ゲートの3点が揃うかどうかで判断します。以下ではADRとDDRの違い、公開されている自動化の数値、導入前のチェックリストを順に説明します。
判断記録の方式を先に比べる
方式を選ぶ前に、入力内容と「人間が止める地点」を整理しておきます。完成画面の説明を残す仕組みと、採否の理由を残す仕組みは全く別物です。この表でADR、DDR、会議抽出、対話ログ、PRゲートの止め所を比較した上で、後段のゲート条件と1枚のテンプレートに進んでください。
| 方式 | 入力 | 人が止める地点 | 公開されている制限 |
|---|---|---|---|
| 公式 ADR（Nygard / MADR） | 人間が書いた 1 判断 | 受理前レビュー。覆したら superseded | 1〜2ページ。業界横断の DDR 規格は無い |
| 作業中の AI 下書き + hook | 対話コンテキスト + git 差分 | 下書き確認後に docs/ddr/ 保存。意味変更なき誤字は対象外 |
発見元の社内フロー。公開再現手順は限定的 |
| 会議書き起こし抽出（GADR） | 生の会議テキスト | 出力検証を必須の human-in-the-loop | 単発プロンプトは劣化する、と論文側が主張 |
| 対話ログ機械抽出 | エージェント発話と Edit 差分 | 理由欠けレコードを本人へ一行確認 | 1,157発話中 191件（16.5%）。訂正の理由は約3割 |
| PR ゲート（gh-aw） | PR 本文 / docs/adr/ / 差分 |
判断が推論不能なら下書きせずコメント停止 | 既定は implementation ラベル、または業務DIR追記 100行超 |
出典
出典は以下の通りです。
同じ「自動記録」でも、止める場所が異なります。下書き生成と漏れ検査を混同すると、それらしい理由が先にファイルに入ってしまいます。
テクノロジー判断を記録に残す最小項目
残すべき対象は完成画面の説明ではありません。なぜ採用し、何を捨て、何を受け入れたのかという判断の過程です。
Nygard が残す最小節
Michael Nygard の 2011 年の記事 は、理由が無いと後任は盲目的受容か盲目的変更の2択になると書いています。推奨節は Title / Context / Decision / Status / Consequences です。
置き場所の例はリポジトリ内 doc/arch/adr-NNN.md です。覆した記録は削除せず superseded にします。番号は再利用しません。
adr.github.io と MADR の初期化
adr.github.io は ADR を、単一の判断とその根拠を残す decision log と定義します。同じ型を設計など any decision record へ拡張できる、と書いています。MADR 4.0.0 は docs/decisions を初期化例にしています。
npm install madr && mkdir -p docs/decisions && cp node_modules/madr/template/* docs/decisions/
ADR / PDR / DDR の呼び分け
glukhov.org の整理 は、ADR（技術）/ PDR（プロダクト）/ DDR（UX・インタラクション）を AI 支援開発の memory layer と位置づけます。コードは「何を」しか残しません。DDR という名称に業界横断の Open Standard はありません。項目はチームが ADR 思想から決めます。
発見元の項目例
発見元の SoftBank Zenn 記事 は、記録ID、変更種別（表記調整 / 意味変更 / 判定基準変更 / ルール逸脱承認）、背景、決定、代替案、影響、検証計画を例示しています。記入例 ID は DDR-001_delete-confirmation-dialog（2026-08-07）です。これは社内フローの一次記述であり、規格そのものではありません。
読者の次の一手は、置き場所（docs/adr/ か docs/ddr/ か docs/decisions/）と必須4節を、1枚のテンプレに固定することです。混ぜると後から検索できません。
AI下書きは文脈窓と理由欠けで崩れる
自動化の論点は、モデルの規模ではなく、渡す履歴の質と、理由がログに残っているかどうかです。
直近 3–5 件の recency window
EASE 2026 の論文は、750 リポジトリの時系列 ADR で no-context / All-history / First-K / Last-K / RAFG を比較しています。直近 3–5 件の recency window が品質とコストの最良バランスでした。RAFG の追加効果は、線形ワークフローでは統計的に有意でない、と報告しています。生成タスクには「次の ADR タイトルから本文を書く」実験も含まれます。自チームの対話ログ品質とは別物です。
会議書き起こしからの抽出
GADR（arXiv 2608.17694） は、生の会議書き起こしから Nygard 形式へ落とす multi-agent self-correcting を提案します。人間検証が前提です。知識は記憶から再構成せず、作られた時点で残す、と主張しています。単発プロンプトは劣化する、というのが論文側の立場です。
対話ログに理由が残る割合
Qiita の永田氏の実測 では、3案件・1,157ユーザー発話から4つ組（入力・介入・出力差分・理由）が成立したのは 191件（16.5%）でした。訂正シグナル 612件のうち、理由まで残るのは約3割です。
作成に使った実例では到達 0/8→5/8（+62pt）ですが、別実例6件では +0pt でした。効いたのは抽象観点ではなく、ログに既にあった基準値です。著者自身が、1人・文書作成偏りで一般化しないと書いています。
下書きプロンプトには直近 3–5 件の受理済み記録を渡します。理由欄が空なら TODO にして、本人へ一行聞きます。それらしい文章を受理しないでください。
記録漏れはコミットまたはマージの直前で止める
下書き生成と漏れ検査を分ける
下書き生成と漏れ検査は分けます。検査はコミットまたはマージの直前に機械で止めます。指示・ガード・検証を混ぜない考え方は、エージェントLoopを安全に回すハーネス設計 と同じです。
対象条件と保存先
- 対象条件を1枚に書く。ルール・判定基準・実行フローの意味変更を対象にし、誤字・体裁は除外する。
- エージェント指示に「対話 + 差分 → テンプレ下書き」を置く。Git 非連携チャットなら、会話末に FMT 指定で依頼し、共有URLを添える。
- 保存先を
docs/adr/またはdocs/ddr/に固定する。
ゲートを1つ選ぶ
- ゲートを1つ選ぶ。pre-commit は、ステージ済みの意味変更に新規記録が無ければ停止する。PR ゲートは gh-aw の Design Decision Gate が、
implementationラベル、またはsrc|lib|pkg|internal|app|core|domain|services|api追記 100行超で発火する。必須節は Context / Decision / Alternatives Considered / Consequences。無ければ差分から draft を push する。推論不能ならコメントして止める。ターン予算 20、安全出力は1回。
記録の同梱と「なぜ」の質問
- Rick Pollick の整理 は、新パターンを入れる PR に記録を同梱せよ、と書きます。後追い批准は失敗モードです。書けない変更は出荷未準備です。
- VS Code の ADR AI Manager は、選択コミットを判定し、コードに無い「なぜ」だけ質問します。不明は捏造せず TODO にします。MADR を
docs/adr/へ書きます。Claude / OpenAI / ローカル Ollama・LM Studio・vLLM に対応します。
公開範囲と開始地点
発見元 hook の検査ロジックは公開再現が薄いです。gh-aw は公開ワークフローですが、自リポジトリのラベル運用が無いと過発火または未発火します。
個人リポジトリは会話末テンプレで開始してよいです。共有ブランチがあるなら PR ゲートを先に置きます。完了報告と実状態の差を見る姿勢は、コーディングエージェントのテスト改ざんを見抜く検証分離 とも重なります。
導入前チェックリスト（進める／見送る）
人気度や「自動記録」という言葉ではなく、対象判定と確認負荷で進めるかを決めます。手順のパッケージと合格定義を先に置く考え方は、社内AgentはSkills化とEval設計で育てる と同じです。
- 残したいテクノロジー判断は技術（ADR）、プロダクト（PDR）、UI（DDR）のどれか。混ぜない。
- 対象外（誤字、体裁、単純リファクタ）を1行で書けている。
- 人間が確認する欄は「実際の決定・代替案・帰結」である。AI が書いた plausible な理由を受理していない。
- ゲートは pre-commit / PR / 手動のどれか。無ゲートの自動保存は採用しない。
- 直近記録 3–5 件を下書き文脈に渡せる。無いなら先に人間が 3 件書く。
- 丸投げ「いい感じに書いて」を禁止できる。
ラクスの実務報告 は、工程を 前提固め→計画→案出し→独立評価→合議→ドラフト に分解し、適格性ゲートを先頭に置きました。初期は単発約60分、境界確認約20回、レビュー3巡で空転しました。条件付き自動進行と Blocker 時だけ停止、レビュー2巡上限で抑えました。エージェントチーム常用はコンテキスト肥大です。同一タスクのセッション時間は、サブエージェント案で約1/3（1セッションのみ）でした。
見送り条件は次です。対象が毎回曖昧、確認者がいない、ログに理由がほぼ残らない、ゲートを置く権限が無い。
今週入れるのは、テンプレート1枚と適格性の確認質問1問だけです。自動生成はその後に対応します。
よくある質問
DDR と ADR は別規格か
別の Open Standard ではありません。adr.github.io は同じ記録型を設計判断へ拡張できると書いています。DDR は UX / インタラクション側の呼び方です。項目はチームが決めます。
対話履歴を全部記録すればよいか
いいえ。Qiita 実測では4つ組成立は 16.5% です。理由が無い訂正が過半です。基準値と却下案が残るレコードだけが資産になります。
直近何件をプロンプトに渡せばよいか
公開実験の既定は 3–5 件です。全履歴はコストが上がります。線形ワークフローでは RAFG の追加効果が有意でない、と論文は報告しています。
Git を使わないデザインチャットでも始められるか
会話末にテンプレを渡し、共有URLを添えて人間が保存すれば足ります。漏れ検査は後から hook や PR ゲートを足します。
AI が書いた理由をそのまま受理してよいか
よくありません。glukhov.org と GADR は人間検証を必須とします。不明は TODO です。ADR AI Manager も捏造しない設計です。
ブックマーク数は採用理由になるか
なりません。注目度シグナルだけです。採用は対象判定・確認者・ゲートの3点が揃うかで決めます。
関連記事:
まとめ
テクノロジー判断を資産にするなら、自動記録そのものより、下書きを止めて人が確認し、コミットまたはマージ前に漏れを止める設計が先です。
次の一手は次の5点です。
- 必須4節のテンプレを1枚置く
- 適格性の1問を先頭に置く
- 直近 3–5 件を文脈にする
- pre-commit か PR ゲートを1つ選ぶ
- 無ゲートの自動保存は採用しない
残る不確実性は、発見元 hook の非公開実装、論文コーパスと自チームログの差、Qiita の母数です。人気度は採用理由にしないでください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す