調査日: 2026-05-12 調査エンジン: Claude Research 問い: ADR テンプレートの §1 コンテキストを「背景 / 現状 / 課題 / 要求 / 目標」等のサブ見出しに分解する事例・ベストプラクティス・個人開発向けの実用テンプレートは?

ADR の Context セクションを小項目に分解する事例とベストプラクティス —— 個人開発(代表取締役・GAS会計システム)向け実用テンプレート提案

TL;DR

• 結論として、ADR の Context を「背景／現状／課題／制約・要件／目標」の5項目に分割する形式は、Tyree & Akerman(IEEE Software, vol.22, no.2, March 2005, DOI: 10.1109/MS.2005.27)・MADR 4.0.0(2024-09-17 リリース)・arc42 といった主要テンプレートの構造から正当化でき、David Youngblood の ADR Master Template、Josh Rotenberg の Claude ADR System Guide、Cloud Posse、Microsoft Azure Well-Architected Framework 等で実装が確認できる。 ただし小規模・個人開発では過剰構造化が「フォーム埋め化」を招くため、サブ見出しを設けつつ不要項目は躊躇なく削る 運用が最適解。
• 代表取締役(一人会社・GAS会計システム)向けの推奨は、MADR minimal を拡張した5項目テンプレート: 背景 / 現状(As-Is) / 課題 / 制約・要件 / 目標(To-Be) の各項目を1〜2文で書く軽量フォーマット。ライブラリ選定など軽い判断には Nygard 型 (Cognitect Blog, 2011) の Mini-ADR(Context→Decision→Consequences の3節)で十分。
• 使い分けの判断基準: 「6〜12か月後に自分が議論を蒸し返しそうな決定か」「巻き戻すのに半日以上かかる決定か」「複数案を比較した上での選択か」のいずれかが Yes なら5項目分解テンプレ、すべて No なら素の Nygard 型で書く。

Key Findings

1. 主要テンプレートの「Context 分解」スタイルの分類

ADR の Context は、テンプレートごとに「単一の自由記述ブロック」と「複数の独立節への分解」という2つの設計思想に大別できる。

joelparkerhenderson/architecture-decision-record リポジトリの Tyree & Akerman テンプレート(locales/en/templates/decision-record-template-by-jeff-tyree-and-art-akerman/index.md)には次の通り並列の独立節が列挙されている: "Issue / Decision / Status / Group / Assumptions / Constraints / Positions / Argument / Implications / Related decisions / Related requirements / Related artifacts / Related principles / Notes"。Context という見出しはそもそも存在せず、それを構成する観点がはじめから分解されている。

2. Context を分解する代表的サブ項目(7パターン)

実際のテンプレートで観測される Context サブ項目を分類すると、次の通りとなる:

3. 実在事例: Context を明示的にサブ見出しで分解しているテンプレート

事例A: David Youngblood「ADR Master Template」(GitHub Gist thedavidyoungblood/bccce859af7a476e44a290a2230e0913) — 最も忠実に「Context を Background/Current State/Problem/Constraints/Goals 系の小見出しに分解」している例。## Context の下に **Problem statement:** / **Product context:** / **Current state:** / **Constraints:**(Technical / Organizational / Regulatory/Compliance / Timeline/Delivery にさらに細分) / **Assumptions (explicit):** / **Non-goals (optional):** をサブブロックとして配置し、別途トップレベルに ## Decision Drivers を持つ。

事例B: Josh Rotenberg「Claude ADR System Guide」(GitHub Gist joshrotenberg/a3ffd160f161c98a61c739392e953764, 2025-07-18) — 次の見出し構造を採る:

## Problem Statement をトップ見出しに置き、その下に ### Context / ### Goals / ### Non-Goals を明示的なサブ見出しとして分解。Decision Record 側でも ### Options Considered / ### Decision / ### Trade-offs Accepted に分けている。

事例C: devx gist「Architecture Decision Record (ADR) Template」(gist.github.com/devx/87f79e59141e9bb931fab43d09db63db) — Context セクションに「Background or existing problem / Constraints (technical, organizational, etc.) / Business goals or use cases driving this change / Systems, teams, or processes impacted」を箇条書きで明示。

事例D: Cloud Posse Reference Architecture の Design Decision テンプレート(docs.cloudposse.com/learn/maintenance/tutorials/how-to-write-adrs) — MADR 派生で Context and Problem Statement を独立節とし、別途 Considered Options に Recommended 印を付ける形式。Nygard 型 Context の説明を verbatim で明記: "This section describes the forces at play, including technological, political, social, and project local. These forces are probably in tension, and should be called out as such. The language in this section is value-neutral."

4. arc42 の思想: ADR 単体ではなく「文書全体で Context を分散させる」

arc42 公式(docs.arc42.org)は ADR の Context を膨らませることを推奨せず、別章への参照を奨励する:

• Section 9 (Architecture Decisions): *"Important, expensive, large scale or risky architecture decisions including rationales. … Please use your judgement to decide whether an architectural decision should be documented here in this central section or whether you better document it locally. Avoid redundant texts. Refer to section 4, where you captured the most important decisions of your architecture already."*
• Section 4 (Solution Strategy): "Motivate what you have decided and why you decided that way, based upon your problem statement, the quality goals and key constraints."
• Section 1.2 (Quality Goals): "You should know the quality goals of your most important stakeholders, since they will influence fundamental architectural decisions."
• Tip 1-18: "Defer detailed and complete quality requirements to arc42 section 10!"

つまり arc42 では、Context を ADR 内で完結させる代わりに Chapter 1(目標・品質目標・関係者)・Chapter 2(制約)・Chapter 3(コンテキスト/スコープ)・Chapter 10(品質要件) に分散し、ADR からは参照リンクを張る運用が公式に推奨されている。

5. Y-Statement と "5項目分解" の対応関係

Olaf Zimmermann の Y-Statement(初出: Zdun ら "Sustainable Architectural Design Decisions," IEEE Software vol.30 no.6, 2013, DOI: 10.1109/MS.2013.97)は1文の中に Context を分解している:

"In the context of <use case/feature/component>, facing <concern/non-functional requirement>, we decided for <option> and neglected <alternatives>, to achieve <quality/benefit>, accepting that <downside>."

ここで "context" = 背景・現状、"facing" = 課題・駆動要因、"to achieve" = 目標、"accepting" = トレードオフ、と対応する。Y-Statement と MADR の Context and Problem Statement + Decision Drivers + Decision Outcome + Consequences は同じ構造の言い換えにすぎない。

6. アンチパターン: 分解しすぎの罠 (Olaf Zimmermann)

ozimmer.ch の "How to create Architectural Decision Records — and how not to"(2023-04-03)は次のアンチパターンを警告する:

• Mega-ADR: 詳細情報を ADR に詰め込みすぎ → 別文書へ
• Blueprint or Policy in Disguise: 命令調・規則調 → 簡潔に書き直す
• Novel and Epic: SAD(Software Architecture Document)全体を単一 ADR に詰め込む
• Fairy Tale / Wishful Thinking: 都合の良い根拠しか書かない
• Pseudo-accuracy: 定量的な加重スコア評価が ADR の主役になることへの警告

サブ見出しを過剰に分割すると Mega-ADR / Blueprint in Disguise のリスクが上がる。MADR の "Context and Problem Statement" が「2〜3文 in free form using two to three sentences」と明記されているのはこの教訓の反映である。

7. 日本国内の実践事例

• Wantedly / kawasima 実践ADR: Nygard 単一節を踏襲
• NIFTY / CAMPFIRE: 軽量5項目構成 (LADR 寄り)
• DWANGO/KADOKAWA Connected: Tyree & Akerman 寄りに Option/Reason を独自追加
• giftee Tech Blog / サーバーワークス: MADR minimal からの漸進拡張
• sgrokym (Zenn) / laiso (はてな): Context 内を引用ブロックで段落分け (個人開発で5項目分解に最も近い実例)

推奨テンプレート (個人開発向け5項目分解)

## Context

### 背景 (Background)
<経緯 1〜2文>

### 現状 (Current State / As-Is)
<今どうなっているか 1〜2文>

### 課題 (Problem)
<痛みポイント 1〜2文>

### 制約・要件 (Constraints & Requirements)
- <箇条書き 2〜5項目>

### 目標 (Goals / Desired Outcome / To-Be)
<To-Be 像 1〜2文 + Non-Goals>

各項目の量目安 (1〜2文ルール)

使い分け判断基準

5項目分解 (Full-ADR) を使う条件 — いずれか1つでも Yes なら:

1. 6〜12か月後に再議論しそうな決定か?
2. 巻き戻すのに半日以上かかるか?
3. 外部要因 (規制・契約・第三者API) が制約か?
4. 複数案を比較した上での選択か?
5. 自分以外に説明することがあるか?

すべて No なら Mini-ADR (Context→Decision→Consequences の素の Nygard 型) で十分。

Caveats

• 過剰な構造化は Mega-ADR / Blueprint in Disguise を招く。各サブ項目を 1〜2文に制限することが最優先。
• 個人開発では「該当なしなら項目自体を削る」派を推奨。形式的なフォーム埋めは思考停止のサイン。
• Tyree & Akerman 14項目フル版は重すぎる。本推奨は Tyree & Akerman / Google Design Doc / MADR から要素を抽出した5項目。
• 日本語の小規模/個人開発で5項目分解の完成度の高い事例は限定的。先行事例が少ないため自分で調整する覚悟が必要。