知識マップ: ADR(Architecture Decision Record)入門 ── 小規模開発で「なぜこの設計にしたか」を残す最小の方法

記事「ADR(Architecture Decision Record)入門 ── 小規模開発で「なぜこの設計にしたか」を残す最小の方法」の主張を、概念と関係(エッジ)に分解した知識グラフの全体です。各関係には根拠・確認日・確度が付いています。

ADR(Architecture Decision Record)は、1つの設計判断をステータス・コンテキスト・決定・結果という定型で1ファイルに記録する軽量なドキュメントで、コードと同じリポジトリに置きコードレビューと合わせて運用する。記録の対象は、データベースや通信方式のように後戻りが難しい決定や、予算・納期・既存資産といった制約が決め手になった決定に絞り、命名規則やフォーマッタ設定のように機械的に統一できる規約は対象にしない。方針を変えるときは古いADRを書き換えず、ステータスをSupersededにして新しいADRへ置き換えるパターンを使うことで、記録されなかった決定が忘れられ議論が蒸し返される問題を防ぐ。この運用は、既に稼働している既存システムに後から導入する場合にも価値がある。

flowchart LR
    accTitle: ADR(Architecture Decision Record)の知識マップ
    accDescr: ADRがステータス・コンテキスト・結果を含む定型でコードリポジトリに保管されコードレビューと組み合わせて運用されること、後戻りが難しい決定や制約が決め手になった決定を対象にすること、方針を覆すときはSupersededパターンで置き換えて記録されない決定の忘却を防ぐこと、既存システムへの遡及導入にも価値があることを示す図。
    adr["ADR(Architecture Decision Record)"]
    adr_status["ADRのステータス"]
    code_repository["コードリポジトリ"]
    code_review["コードレビュー(プルリクエストレビュー)"]
    undocumented_decision_loss["記録されない決定の忘却"]
    hard_to_reverse_decision["後戻りが難しい決定"]
    coding_convention["規約・フォーマット設定"]
    adr_consequences["結果(Consequences、ADRの要素)"]
    brownfield_adoption["既存(ブラウンフィールド)システムへの導入"]
    adr_supersede_pattern["Supersededによる置き換えパターン"]
    azure_well_architected_framework["Azure Well-Architected Framework"]
    adr_context["コンテキスト(ADRの要素)"]
    constraint_driven_decision["制約が決め手になった決定"]
    adr -->|"前提とする"| adr_status
    adr -.->|"に保存される"| code_repository
    code_review -.->|"推奨される対応"| adr
    adr -->|"軽減する"| undocumented_decision_loss
    adr -->|"推奨される対応"| hard_to_reverse_decision
    adr -->|"用いるのは非推奨"| coding_convention
    adr -->|"前提とする"| adr_consequences
    adr -->|"推奨される対応"| brownfield_adoption
    adr_supersede_pattern -->|"前提とする"| adr_status
    adr -.->|"前提とする"| adr_supersede_pattern
    adr_supersede_pattern -->|"軽減する"| undocumented_decision_loss
    azure_well_architected_framework -->|"推奨される対応"| adr
    adr -->|"前提とする"| adr_context
    adr -->|"推奨される対応"| constraint_driven_decision
    adr_supersede_pattern -.->|"に保存される"| code_repository

概念間の関係(全15件)

図と同じ関係を文章でも列挙します。表示している文と機械可読な意味データ(RDFa)は同じ要素に載っています。確度が「確立した関係」のものは直接の関係として、「条件付きの関係」のものは成立条件つきの言明(rdf:Statement)として表現しています。

• ADR(Architecture Decision Record)はADRのステータスを前提とします。ADRはタイトル・ステータス・コンテキスト・決定・結果の5要素の1つとしてステータスを持ち、提案中から承認済みへ進み、覆すときは廃止・置き換え済みにする / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)はコードリポジトリに保存されます。この記事が推奨する運用(Wikiや共有フォルダーではなく)では、ADRはコードと同じリポジトリにMarkdownとしてコミットし、バージョン管理下に置く / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• コードレビュー(プルリクエストレビュー)はADR(Architecture Decision Record)に対する本記事の推奨です。ADRの追加・更新をプルリクエストのコードレビューに含めることが実務上推奨される / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)は記録されない決定の忘却を軽減します。記録されなかった決定は忘れられ、同じ議論の蒸し返しや当初の意図に反する変更を招くため、ADRはこれを防ぐ記録として機能する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)は後戻りが難しい決定に対する本記事の推奨です。システムの構造や重要な品質特性に影響し後戻りが難しい決定は、ADRに記録することが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)を規約・フォーマット設定に用いることは推奨されません。命名規則やフォーマッタ設定のように機械的に統一できる規約は、ADRの対象にしない / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)は結果(Consequences、ADRの要素)を前提とします。ADRの結果(Consequences)には決定の帰結を意図的にも偶発的にも隠さず、トレードオフを記す / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)は既存(ブラウンフィールド)システムへの導入に対する本記事の推奨です。既存(ブラウンフィールド)のワークロードでも、把握できている過去の決定を遡って記録する価値がある / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Supersededによる置き換えパターンはADRのステータスを前提とします。Supersededによる置き換えは、古いADRのステータス行をSupersededに変え新しいADRへの参照を付けることで成立する / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)はSupersededによる置き換えパターンを前提とします。決定を覆すときはADRを上書きせず、Supersededパターンで新しいADRに置き換える。この関係が生じるのは決定を覆す場合に限られ、単に新しい決定を記録するだけのADRにはSupersededパターンは関与しない / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典
• Supersededによる置き換えパターンは記録されない決定の忘却を軽減します。Supersededパターンは古い記録を残したまま置き換えるため、いつ・なぜ方針が変わったかという履歴自体が失われるのを防ぐ / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Azure Well-Architected FrameworkはADR(Architecture Decision Record)に対する本記事の推奨です。Azure Well-Architected FrameworkはADRの維持をアーキテクトの役割のガイダンスとして推奨している / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)はコンテキスト(ADRの要素)を前提とします。ADRのコンテキストには、決定が必要になった技術的・業務的な前提や制約、検討した選択肢を書く / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• ADR(Architecture Decision Record)は制約が決め手になった決定に対する本記事の推奨です。予算・納期・既存資産・顧客環境の制約が決め手になった決定や、外部との取り決めはADRに書くことが推奨される / 確度: 確立した関係 / 確認日: 2026-08-01 出典
• Supersededによる置き換えパターンはコードリポジトリに保存されます。ADRをコードリポジトリで管理するこの記事の運用では、Supersededによる置き換えでも古いADRは削除せず、コードリポジトリ内にそのまま残す / 確度: 条件付きの関係 / 確認日: 2026-08-01 出典

主要概念の定義

ADR(Architecture Decision Record)

ソフトウェアの構造に関わる1つの決定を、タイトル・ステータス・コンテキスト・決定・結果という定型で1ファイルに記録する軽量なドキュメント形式である。

コードレビュー(プルリクエストレビュー)

プルリクエスト単位でコードの変更内容を他者が確認する開発プロセスである。

Supersededによる置き換えパターン

決定を変更する際に古いADRを書き換えず、ステータスをSupersededに変えて新しいADRへの参照を付ける運用パターンである。

Azure Well-Architected Framework

Microsoftが提供する、クラウドワークロードの設計品質を高めるためのアーキテクチャガイダンス群である。

機械可読データ

• JSON-LD / Turtle ── この記事の知識グラフ全体
• 概念一覧 / 語彙(述語)の定義

このページはサイトの知識グラフ(_data/knowledge/)から自動生成されています。誤りの指摘はお問い合わせからお願いします。