RQ-043 ADR に記載すべき内容の実務研究 (GPT Deep Research 単独回答 / Confirmation・Assumption/Constraint 分離・5 公開事例パターン等の新発見)

調査エンジン: GPT Deep Research (OpenAI, 2026-05-13 取得) 調査依頼者: [email protected] 入手経路: 個別ダウンロードファイル (ADRに記載すべき内容の実務研究レポート.docx、29KB) を docx → md 変換 取得日: 2026-05-13 ステータス: ✅ 取得済 / 並列調査 (Gemini + Claude) は未実施 本 RQ の独自性: 過去 RQ-038-042 (ADR スキル / Triage / リポ構造 / 文脈サブ構造) は bizlp 既存研究で網羅済の領域。本 RQ は 「ADR 1 件にどの項目を記載するか」(本文内構造) に焦点

既存 bizlp 研究との関係

主要な新発見 (bizlp の既存研究で未取り込みの概念)

注意事項

• 単一エンジン調査: 過去の RQ-040/041/042 は Gemini + Claude の 並列調査 を前提に synthesis を作成していたが、本 RQ-043 は GPT DR 単独。Gemini Deep Research / Claude Research での並列再調査を実施すれば synthesis 作成可能だが、本日時点では未実施
• citation 形式: 原文に [1] [2] 等の citation marker が含まれ、文末に出典 URL 一覧あり。bizlp での再現性確保のため URL を保持
• Docx → MD 変換の制約: 表組み (table) は flat text に展開、フォーマット崩れあり。原典 docx は ~/Downloads/ADRに記載すべき内容の実務研究レポート.docx に保管

GPT Deep Research レポート本文

ADRに記載すべき内容の実務研究レポート エグゼクティブサマリ ADRの最小核は、原典にあたる Michael Nygard[1] の提案と、その後の公的・実務ガイドに共通する Title / Status / Context / Decision / Consequences です。日本語の公式資料としては urlAWS 規範ガイダンスturn1search9 と が導入時に特に有用で、英語の原典としては Nygard 原典、、urlMADR 4.xturn0search1 が実務設計の基準になります。 [2] ただし、2026年時点の実務で「あとから見て本当に使える」ADRにするには、最小核だけでは足りません。特に 日付、検討した選択肢、評価基準、関係者、関連チケット/PR/設計文書、関連ADR、確認方法 を持たせると、再判断・監査・オンボーディング・設計変更時の説明コストが大きく下がります。MADR は decision-makers / consulted / informed / confirmation まで含め、GitLab の公開ADRは alternatives・implementation references・diagram を強く使っており、Structurizr は ADR を C4 モデルの workspace / system / container に紐づけて公開できます。 [3] 運用面では、ADR は バージョン管理下のテキスト として置き、accepted 後は基本的に不変 にし、変更が必要になったら 新しいADRで supersede するのが最も事故が少ないです。AWS は承認後の ADR をイミュータブルとして扱い、GDS も実装後の変更は新ADRで説明することを勧めています。GitLab は設計文書の下にADRを置き、DRIとレビュー期限を明示する運用を公開しています。 [4] 本レポートの結論は、「必須は薄く、推奨は強く」 です。つまり、どのADRでも必須項目は必ず書き、影響が大きい意思決定だけに推奨項目を段階的に足す構成が最適です。これにより、Nygard流の軽さを保ちながら、MADR・GitLab・Structurizr が持つ実務的な強さを取り込めます。 [5] 必須項目 以下の「必須」は、Nygard/GDS/AWS の共通最小要件に、現代的な実務で実質的に落としづらい 日付 と 検討した選択肢 を加えたものです。厳密な国際標準が一つあるわけではありませんが、このセットなら小さなチームから大規模組織まで無理なく回せます。 [6] 項目 目的 記載例 記載時の注意点 関連メタデータ ADR ID / タイトル 一意識別し、一覧・検索・後続ADRから安定的に参照できるようにする。タイトルは「問題名」ではなく「決定内容」を表す。 [7] ADR-0012: 内部APIの同期通信にgRPCを採用する 短い名詞句または能動的表現にする。連番は再利用しない。作成順を示すだけで意味を持たせない。 [8] adr-id, slug, repository path, created ステータス 検討中か、承認済みか、却下か、置換済みかを明示し、読者が「今有効な決定か」を即判断できるようにする。 [9] Accepted / Proposed / Superseded by ADR-0021 語彙をプロジェクト内で統一する。superseded のときは後継ADRを必ず指す。GDS のように main ブランチで accepted を暗黙化する運用もあるが、外部公開や docs portal では明示した方が移植性が高い。 [10] status, supersedes, superseded-by, approved-by, status-changed-at 日付 その決定が「いつ時点の判断か」を示し、陳腐化判断や監査を容易にする。Structurizr でも date は表示要素として扱われる。 [11] 2026-05-13 可能なら ISO 8601 で統一する。VCS 履歴だけに依存すると、docs site で日付が見えないことがある。 [12] created, updated, last-reviewed, changelog 背景 / コンテキスト / 問題 なぜ判断が必要になったか、どの制約や事実が判断を駆動したかを保存する。ここがないと後任は「盲目的に従う」か「根拠なく壊す」かになりやすい。 [13] API境界が増え、RESTでは型安全と後方互換の運用コストが高い。BFFからは低遅延も要求される。 事実・制約・緊張関係を書く。ここで結論を先に書きすぎない。Nygard は value-neutral を勧め、MADR は scope を明示することを勧める。 [14] related requirement, problem statement, affected components, ticket 決定 チームが何を採用するかを断定的に示す。ADR の中心。AWS は「We will...」型で書くことを明確に推奨している。 [15] 内部同期通信には gRPC を採用し、外部公開APIは REST を維持する。 曖昧語を避ける。検討する かもしれない should より、能動態・断定形がよい。1 ADR = 1 significant decision を意識する。 [16] decision-maker, approvers, decision-date 検討した選択肢 なぜ他案を採らなかったかを残し、将来の再検討コストを下げる。MADR と GitLab 公開運用では事実上の中核項目。AWS FAQ も可能な解決策の記載を求める。 [17] REST / gRPC / 非同期イベント駆動 2〜4個の現実的な案に絞る。藁人形の案を並べない。採用案以外も「なぜ捨てたか」を最低限残す。 [18] benchmark, RFC, spike, comparison doc 結果 / Consequences 決定後に何が楽になり、何が難しくなり、どんな追従作業が発生するかを将来の文脈として残す。Nygard は「次のADRの context になる」と位置づける。 [19] 良い: 型安全が向上。悪い: ブラウザ直結が難しくなり、gateway整備が必要。 良いことだけを書かない。正負中立を混ぜる。実装タスクや運用コストが出るなら明記する。 [20] follow-up tasks, risk, review date, runbook impact 実務上は、1 ADR に 1 つの重要決定 を守るほうが管理しやすいです。一方で、実際の公開事例には、スキーマやログインフローのように「その決定自体が仕様」になるものもあり、その場合は例示・図・用語定義まで含めた長めのADRが正当化されます。つまり既定値は短く、仕様化が必要なときだけ長くするのがよい運用です。 [21] 推奨項目 以下は、MADR 4.x、Tyree/Akerman、GitLab の公開ADR、Structurizr のC4連携、社内ハンドブック系ガイドで効果が高いと確認できる拡張項目です。必須ではありませんが、影響範囲が大きい決定、非機能要件が絡む決定、複数チームが関わる決定では、ほぼ必須に近い価値があります。 [22] 項目 目的 記載例 記載時の注意点 関連メタデータ Decision Drivers / 評価基準 何を最重要視して比較したかを明示し、後から見ても判断軸が再現できるようにする。 [23] 低遅延、型安全、ブラウザ非公開、監査容易性 採用案を決めた後に後付けで基準を書かない。比較前に定義する。 [24] quality attributes, NFR IDs, security requirements 各選択肢の Pros / Cons 案ごとの利点・欠点を同じ軸で比較し、結論の透明性を上げる。MADR はここを重視する。 [25] REST: 良い=公開容易 / 悪い=IDLなし 軸を揃える。ある案だけ詳細、別案だけ雑、を避ける。 [24] comparison matrix, benchmark link Assumptions / Constraints 前提条件と制約条件を分けて残し、再評価時に「前提が壊れたか」「制約が変わったか」を判別しやすくする。 [26] 前提: 社内通信のみ / 制約: ブラウザ直結は不要 assumption と external constraint を混同しない。変わりうる前提は review date を持つとよい。 [26] assumptions, constraints, expiry/review date Decision maker / Consulted / Informed 所有者と相談先を明示し、レビュー責任を曖昧にしない。MADR と GitLab はこの運用に親和的。 [27] Decision maker: Platform TL / Consulted: AppSec, SRE 名前の羅列で終わらせず、最終決定者を1人または小数に絞る。 [28] owner, DRI, reviewers, approvers スコープ / 影響範囲 どのシステム・コンテナ・コンポーネントに効く決定かを明示し、過剰適用や誤適用を防ぐ。 [29] 対象: Order API と Billing API。外部公開RESTは対象外。 対象外も書く。C4 の要素名や repository path と合わせると強い。 [30] c4 elements, repo path, service names, domain 実装ノート / 移行計画 決定と実装の橋渡しを行う。GitLab の公開ADRでは implementation notes / references がよく使われる。 [31] Phase 1: protobuf定義 / Phase 2: gateway導入 / Phase 3: client移行 ADRに低レベル実装を詰め込みすぎない。長くなる場合は issue / PR / design doc へ分割する。 [32] epic, milestone, PR/MR, migration checklist Confirmation / 準拠確認 「決めたことが実装で守られているか」を確認する。MADR は fitness function まで示唆している。 [24] ArchUnitでREST直呼び出しを禁止するルールをCIで検証 測定可能・反証可能にする。レビューだけでなく自動検査を持てると強い。 [33] fitness function, CI job, review checklist, test suite 関連成果物 / 関連ADR / レビュー期限 要件→設計→ADR→実装→検証の線をつなぎ、変更時の追跡性を上げる。GDS・AWS・adr-tools はいずれも trace の重要性を示している。 [34] Related: ARCH-142, PR-991, ADR-0007, review due 2026-09-30 旧ADRと新ADRの双方を更新する。高リスク決定は review due を置く。 [35] tickets, design docs, PR/MR, supersedes, review due, change log 運用を軽く保ちたい場合は、推奨項目のうち Decision Drivers / Pros-Cons / Related artifacts を最優先に残すと効果が高いです。逆に、監査・複数チーム連携・長期移行がある場合は owner / implementation notes / confirmation / supersedes まで含めたほうが失敗しにくいです。 [36] 主要テンプレート比較 adr.github.io が整理している通り、ADR テンプレートは一枚岩ではなく、Nygard 系、MADR、Y-Statement、その他の企業・標準系テンプレートに分かれます。実務で重要なのは「どれが唯一正しいか」ではなく、どのくらいの情報密度を必要とする決定か です。 [37] テンプレート 代表的な構成 長所 短所 向く場面 urlMichael Nygard 原典turn2search2 Title / Status / Context / Decision / Consequences。軽量で1〜2ページ想定。 [38] 最小で始めやすい。将来の読者への会話として書ける。導入障壁が低い。 [39] 代替案、評価基準、owner、traceability は別途足さないと薄くなりやすい。 小〜中規模チーム、まずADR文化を作りたい時、日常的な技術選定 Date/Status/Context/Decision/Consequences 版と、id/title/description + Context/Decision/Consequences 版が代表的。 [40] リポジトリ運用・PRレビュー・docsサイト公開と相性がよい。OSS で扱いやすい。 [41] 情報が薄いと「決まったことのメモ」で終わりやすい。状態や評価軸が外部化されやすい。 OSS リポジトリ、TechDocs、PR主導の継続開発 urlMADR 4.xturn0search1 front matter に status/date/decision-makers/consulted/informed、本文に Context and Problem Statement / Decision Drivers / Considered Options / Decision Outcome / Consequences / Confirmation / Pros and Cons / More Information。 [42] 理由と比較が残りやすい。メタデータが強い。確認方法まで入れられる。 小さい決定にはやや重い。書き手の慣れが必要。 非機能要件、複数案比較、複数チーム合意、監査対応 Issue / Decision / Status / Group / Assumptions / Constraints / Positions / Argument / Implications / Related decisions / requirements / artifacts / principles / notes。 [26] 要求・原則・成果物まで結びつく。 enterprise governance と相性がよい。 重い。全決定に適用すると更新コストが高い。 アーキテクト審査、規制産業、要件追跡が重い組織 urlarc42 section 9 + ADRturn3search2 アーキテクチャ文書全体の一部として decisions を持ち、必要なら building block 側へ局所化。 [43] 全体アーキテクチャ文書と意思決定が分断されにくい。 全体文書とADRの重複管理が起きやすい。 既に arc42 を採用している組織的ドキュメンテーション urlC4 + ADR / Structurizrturn4search1 ADR を workspace / software system / container に !adrs で紐づけ、UI 上で ID / title / date / status と一緒に公開。 [44] 「どの図のどの要素に対する決定か」が見える。図と理由を往復しやすい。 モデル整備の習慣が必要。小規模チームでは過剰になりうる。 C4 を運用しているチーム、architecture-as-code、社内ポータル公開 実務上のおすすめは、日常運用は Nygard か GitHub系ミニマル、重要決定は MADR 相当へ拡張、そして 図を運用しているチームは C4/Structurizr と紐づける という段階運用です。全部を最初から重くするより、重いテンプレートを「使う条件」を決めるほうが成功率が高いです。 [45] 公開事例から抽出した記載パターン 公開されているADRを見ると、実務でよく現れる書き方は大きく五つに分かれます。単なる「テンプレートの違い」ではなく、決定の性質 に応じて書き方が伸び縮みしている点が重要です。 [46] 事例 観察できる書き方 抽出できる重要パターン 真似すべき場面 Date / Status / Context / Decision の極小構成で、まず「ADRを記録する」こと自体を決定している。 [47] 導入初手のADRは、最初に「ADRを使う」を決める。これで以後の連番・置き場・更新規律の土台ができる。 ADR導入開始時、既存文書が散乱しているとき Background / Inspiration / Core Concepts / Format と進み、YAML の具体例まで含めている。 [48] 仕様やスキーマを決めるADRは、例やフォーマットを含む「準規範文書」になる。 descriptor format、schema、protocol、naming rule など Context / Problems / Decision / Benefits / Alternatives Considered / Implementation References と、問題・判断・実装リンクが分離されている。 [49] 技術的負債や性能問題のADRは、現状の痛みと実装追跡リンクを分ける と読みやすい。 API再設計、payload削減、依存除去、段階移行 制約の列挙に加え、シーケンス図、Positive Consequences / Technical Consequences、Alternatives、Implementation Notes を持つ。 [50] フローや振る舞いを決めるADRは、図と consequence の分割が有効。 認証、ルーティング、ユーザーフロー、分散システムの相互作用 長めの narrative に加え、diagram、Shall / Should / May / To determine で責務を分解している。 [51] 大きな再設計初期では、ADRが「能力要件を分解する設計メモ」に近づく。 新規基盤・大規模リプレイス・未確定事項の多い初期設計 これらの事例から見える共通則は三つです。第一に、最小構成で始めてよい こと。第二に、仕様そのものを決めるADRは例示や図を持つべき こと。第三に、実装へ降りる決定ほど issue / PR / system model へのリンクが重要 だということです。つまり、すべてのADRを同じ密度で書く必要はありませんが、重要な決定では「比較」「結果」「追跡」の三点を厚くする必要があります。 [52] 作成とトレースのワークフロー 実務上のワークフローは、AWS の「提案→レビュー→承諾/拒否→不変化→置換」、GitLab の「DRI と期限付きレビュー」、GDS の「実装後の変更は新ADR」、Structurizr の「図側との接続」を合成すると、次の形に落ち着きます。 [53] flowchart TD A[課題・要件・設計論点を識別] --> B{アーキテクチャ上重要か} B -->|いいえ| C[Issueや設計メモで処理] B -->|はい| D[ADRドラフト作成] D --> E[関係者とレビュー] E --> F{結論} F -->|Accepted| G[main へマージ] F -->|Rejected| H[却下理由を残して終了] F -->|Needs work| D G --> I[実装・移行・検証] I --> J{決定は守られているか} J -->|はい| K[継続運用] J -->|いいえ/状況変化| L[新ADRを作成] L --> M[旧ADRを Superseded に更新] M --> G 保存先は、サービス固有の決定はそのリポジトリ、複数サービス横断の決定だけ中央リポジトリ が実務上もっともぶれません。AWS は集中配置を勧め、GDS はアプリ影響なら当該コードリポジトリを勧め、Wantedly は org-level と repo-level の二階建てを採用しています。 [54] 意思決定のトレースは、要件からコードまで一直線につながっている必要があります。GitLab は design doc から ADR subpage を張る運用を公開し、GDS は issue tracker で意思決定の実装追従を勧め、adr-tools は ADR 間リンクと関係図の可視化をサポートしています。Structurizr は ADR を C4 の要素に直接紐づけられます。 [55] flowchart LR R[Requirement / NFR] --> I[Issue / Epic] I --> D[Design Doc] D --> A[ADR] A --> C[C4要素
Workspace / System / Container] A --> P[PR / MR] P --> Q[Code / Config / IaC] A --> T[Test / Fitness Function] Q --> U[Release / Runbook / Ops] A --> S[Superseding ADR] 実務ルールとしては、ADR ID を issue、design doc、PR/MR、図、テスト、後継ADRの少なくとも一つから参照できる状態 にしておくと、意思決定が「生きた文書」になります。逆に、ADR が孤立ファイルになると検索性はあってもトレース性が失われます。 [56] 実務推奨テンプレートとサンプルADR 以下のテンプレートは、Nygard の最小核 を土台に、MADR の Drivers / Options / Confirmation、AWS の status/date/ownership、GitLab の implementation references、Structurizr/C4 の traceability を取り込んだ、実務向けの折衷案です。影響が小さい決定では optional ブロックを削って構いません。 [57] Markdownテンプレート ---adr: ADR-00XXtitle: <短い決定タイトル>status: proposed | accepted | rejected | deprecated | supersededdate: YYYY-MM-DDupdated: YYYY-MM-DDdecision-maker: - <最終決定者>consulted: - <相談先>informed: - <共有先>scope: - <対象システム/コンテナ/コンポーネント>supersedes: - superseded-by: - related: tickets: - design-docs: - prs: - c4: - <workspace/system/container identifier>review: due: YYYY-MM-DDtags: - architecture - security - platform---# ADR-00XX: <短い決定タイトル>## Context and Problem Statement<何が起きていて、なぜ今判断が必要なのか。事実、制約、背景、対象範囲を書く。>## Decision Drivers- <最重要の評価基準>- <非機能要件>- <制約条件>## Considered Options- - - ## Decision<We will ... の形で断定的に書く。1 ADR 1 決定を意識する。>## Decision OutcomeChosen option: ""### Consequences- Good, because <利点>- Bad, because <欠点>- Neutral, because <注意点または前提>## Pros and Cons of the Options### - Good, because <根拠>- Bad, because <根拠>### - Good, because <根拠>- Bad, because <根拠>### - Good, because <根拠>- Bad, because <根拠>## Implementation Notes- <移行や段階導入の要点>- <適用範囲・対象外>- <実装上の注意>## Confirmation- <どう確認するか。例: CI ルール、ArchUnit、レビュー観点、負荷試験>## Related Artifacts- Ticket: - Design doc: - PR/MR: - C4: - Previous ADR: このテンプレートでは、一覧性の高い front matter と 本文の判断ロジック を分けています。もし docs portal や Structurizr のような表示基盤を使わないなら、front matter は通常見出しに落としても構いません。逆に、公開ポータルや検索を強くしたいなら front matter を維持したほうが便利です。 [58] サンプルADR ---adr: ADR-0012title: 内部サービス間の同期通信に gRPC を採用するstatus: accepteddate: 2026-05-13updated: 2026-05-13decision-maker: - Platform Tech Leadconsulted: - Backend Team - SRE - AppSecinformed: - Mobile Team - Data Teamscope: - Order API - Billing API - Inventory APIsupersedes: []superseded-by: []related: tickets: - ARCH-142 design-docs: - DESIGN-031 prs: - PR-991 c4: - workspace:commerce - container:order-api - container:billing-apireview: due: 2026-09-30tags: - architecture - platform - api---# ADR-0012: 内部サービス間の同期通信に gRPC を採用する## Context and Problem StatementOrder API と Billing API の間で呼び出し回数が増え、REST ベースの JSON 通信ではスキーマ変更時の調整コストと後方互換確認の負荷が高くなっている。また、同一VPC内通信であり、ブラウザから直接呼び出す要件はない。一方で、公開APIは既存クライアント互換のため引き続き REST を維持する必要がある。## Decision Drivers- 型安全なインターフェースを維持したい- サービス間通信のレイテンシを下げたい- 変更時の契約差分をレビューしやすくしたい- 公開APIの互換性は壊せない## Considered Options- REST/JSON を継続する- gRPC を採用する- 非同期イベント駆動に全面移行する## Decision内部サービス間の同期通信には gRPC を採用する。外部公開APIは REST のまま維持し、必要な箇所だけ gateway で変換する。## Decision OutcomeChosen option: "gRPC を採用する"### Consequences- Good, because protobuf によりインターフェースが明示され、差分レビューがしやすくなる- Good, because 同一ネットワーク内では JSON よりレイテンシ改善が見込める- Bad, because ブラウザから直接扱いにくく、gateway または BFF が必要になる- Bad, because 開発者に protobuf / codegen の学習コストが発生する- Neutral, because 外部APIは REST 維持のため、二つの境界を並行運用する期間が生じる## Pros and Cons of the Options### REST/JSON を継続する- Good, because 既存の運用・監視・開発体験をそのまま維持できる- Bad, because 契約差分が曖昧になりやすく、後方互換の調整コストが高い### gRPC を採用する- Good, because IDL を契約として共有できる- Good, because code generation によりクライアント実装のばらつきを減らせる- Bad, because ブラウザ直結には向かない- Bad, because gateway と observability の整備が追加で必要になる### 非同期イベント駆動に全面移行する- Good, because 結合度をさらに下げられる可能性がある- Bad, because 現時点のユースケースは同期レスポンス前提であり、要件を満たしにくい- Bad, because 変更範囲が広く、今期のマイルストーンに収まらない## Implementation Notes- Phase 1: protobuf 定義を共有リポジトリに追加する- Phase 2: Order API と Billing API 間の一部呼び出しを gRPC 化する- Phase 3: 共通 gateway とメトリクス/トレースを整備する- 対象外: 公開 REST API、モバイル向け API、Webhook- 例外が必要な場合は別ADRを作る## Confirmation- CI で protobuf 生成物の差分を検査する- Architecture review で、新規内部同期APIが REST を直接増やしていないか確認する- 負荷試験で p95 latency の改善を測定する- リリース後 1 か月で review due に基づき再評価する## Related Artifacts- Ticket: ARCH-142- Design doc: DESIGN-031- PR/MR: PR-991- C4: workspace:commerce / container:order-api / container:billing-api- Previous ADR: なし このサンプルでは、drivers → options → decision → consequences → implementation → confirmation の順に並べています。これにより、「なぜその判断になったか」と「その判断をどう追うか」が一本につながります。小さな意思決定なら Pros and Cons of the Options と Implementation Notes を簡略化しても構いませんが、Status / Context / Decision / Consequences は削らないほうがよいです。 [59] オープンクエスチョンと留意点 本レポートの「必須」と「推奨」は、公式な単一標準の写経ではなく、Nygard・AWS・GDS・MADR・GitLab・Structurizr・公開ADR事例を突き合わせた実務向けの統合案です。実際には、GDS のように accepted を main ブランチで暗黙化する運用もあれば、AWS や MADR や Structurizr のように status/date/owner を明示したほうがよい運用もあります。したがって、今回の推奨テンプレートは「移植性と追跡性を優先して明示項目を多めにした」設計です。 [60] また、公開されている企業ADRは一部しか見えず、Wantedly のようにガイドは公開でも実例は内部限定のケースがあります。そのため、公開事例比較は 公開されている公式リポジトリ/公式ハンドブックに限定 しており、各社の内部審査フローやテンプレートカスタマイズまでは網羅していません。ただし、最小核・拡張項目・supersede運用・traceability の骨格については、主要ソース間でかなり強い一致が見られます。 [61] [1] [2] [5] [8] [9] [13] [14] [15] [16] [19] [21] [39] [45] [57] [59] https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions [3] [17] [18] [22] [23] [24] [27] [29] [33] [36] [42] [58] https://github.com/adr/madr/blob/develop/template/adr-template.md https://github.com/adr/madr/blob/develop/template/adr-template.md [4] [53] https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/adr-process.html https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/adr-process.html [6] [7] [38] https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-michael-nygard/index.md [10] [20] [34] [35] [60] https://gds-way.digital.cabinet-office.gov.uk/standards/architecture-decisions.html https://gds-way.digital.cabinet-office.gov.uk/standards/architecture-decisions.html [11] https://docs.structurizr.com/ui/decisions/ https://docs.structurizr.com/ui/decisions/ [12] Releases · npryce/adr-tools · GitHub https://github.com/npryce/adr-tools/releases [25] [37] https://adr.github.io/adr-templates/ https://adr.github.io/adr-templates/ [26] https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md https://github.com/joelparkerhenderson/architecture-decision-record/blob/main/locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md [28] [32] [55] https://handbook.gitlab.com/handbook/engineering/architecture/workflow/ https://handbook.gitlab.com/handbook/engineering/architecture/workflow/ [30] [44] https://docs.structurizr.com/dsl/adrs https://docs.structurizr.com/dsl/adrs [31] [49] [56] https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/duo_workflow/decisions/005_deprecate_checkpoint_field/ https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/duo_workflow/decisions/005_deprecate_checkpoint_field/ [40] https://github.com/npryce/adr-tools/blob/master/src/init.md https://github.com/npryce/adr-tools/blob/master/src/init.md [41] https://github.com/npryce/adr-tools https://github.com/npryce/adr-tools [43] https://docs.arc42.org/section-9/ https://docs.arc42.org/section-9/ [46] [47] [52] https://github.com/alphagov/govuk-infrastructure/blob/main/docs/architecture/decisions/0001-record-architecture-decisions.md https://github.com/alphagov/govuk-infrastructure/blob/main/docs/architecture/decisions/0001-record-architecture-decisions.md [48] https://github.com/backstage/backstage/blob/master/docs/architecture-decisions/adr002-default-catalog-file-format.md https://github.com/backstage/backstage/blob/master/docs/architecture-decisions/adr002-default-catalog-file-format.md [50] https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/decisions/005_organization_login/ https://handbook.gitlab.com/handbook/engineering/architecture/design-documents/organization/decisions/005_organization_login/ [51] https://github.com/alphagov/email-alert-api/blob/main/docs/adr/adr-001-notify-integration.md https://github.com/alphagov/email-alert-api/blob/main/docs/adr/adr-001-notify-integration.md [54] https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/best-practices.html https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/architectural-decision-records/best-practices.html [61] https://docs.wantedly.dev/fields/dev-process/adr https://docs.wantedly.dev/fields/dev-process/adr