アーキテクチャ決定記録 (ADR) は何をしますか?
コーディングセッション中に行われるアーキテクチャ上の決定を記録します。決定がSlackスレッド、PRコメント、または誰かの記憶にのみ残るのではなく、コードと共に構造化されたADRドキュメントとして残ります。
いつアクティブにするか
- ユーザーが明示的に「この決定を記録して」または「ADRにして」と言ったとき
- ユーザーが重要な代替案(フレームワーク、ライブラリ、パターン、データベース、APIデザイン)の間で選択しているとき
- ユーザーが「〜に決めた」や「XではなくYを採用した理由は...」と言ったとき
- ユーザーが「なぜXを選んだのか?」と尋ねたとき(既存のADRを読む)
- アーキテクチャ上のトレードオフが議論される計画フェーズ中
ADRフォーマット
Michael Nygardが提案した軽量ADRフォーマットを、AI支援開発向けに適応したもの:
# ADR-NNNN: [決定タイトル]
**日付**: YYYY-MM-DD
**ステータス**: proposed | accepted | deprecated | superseded by ADR-NNNN
**決定者**: [関わった人]
## コンテキスト
この決定や変更の動機となっている問題は何ですか?
[状況、制約、影響する要因を2〜5文で説明]
## 決定
提案および/または実行している変更は何ですか?
[決定を明確に1〜3文で記述]
## 検討した代替案
### 代替案1: [名前]
- **メリット**: [利点]
- **デメリット**: [欠点]
- **採用しなかった理由**: [却下された具体的な理由]
### 代替案2: [名前]
- **メリット**: [利点]
- **デメリット**: [欠点]
- **採用しなかった理由**: [却下された具体的な理由]
## 結果
この変更により、何が容易になり、何が困難になりますか?
### ポジティブ
- [利点1]
- [利点2]
### ネガティブ
- [トレードオフ1]
- [トレードオフ2]
### リスク
- [リスクとその軽減策]
ワークフロー
新しいADRの記録
決定の瞬間が検出されたとき:
- 初期化(初回のみ) —
docs/adr/が存在しない場合、ユーザーに確認してからディレクトリ、インデックステーブルヘッダーがシードされたREADME.md(下記のADRインデックスフォーマット参照)、および手動操作用の空のtemplate.mdを作成します。明示的な同意なしにファイルを作成しないでください。 - 決定を特定する — 核となるアーキテクチャ上の選択を抽出します
- コンテキストを収集する — 何がこの問題を引き起こしたのか?どのような制約があるのか?
- 代替案を文書化する — 他にどのような選択肢が検討されたのか?なぜ却下されたのか?
- 結果を述べる — トレードオフは何か?何が容易になり、何が困難になるのか?
- 番号を割り当てる —
docs/adr/内の既存のADRをスキャンし、インクリメントします - 確認して書き込む — ADRのドラフトをユーザーにレビュー用に提示します。明示的な承認があった場合のみ
docs/adr/NNNN-decision-title.mdに書き込みます。ユーザーが辞退した場合は、ファイルを書き込まずにドラフトを破棄します。 - インデックスを更新する —
docs/adr/README.mdに追記します
既存のADRの読み取り
ユーザーが「なぜXを選んだのか?」と尋ねたとき:
docs/adr/が存在するか確認する — 存在しない場合、「このプロジェクトにはADRが見つかりませんでした。アーキテクチャ決定の記録を開始しますか?」と応答します。- 存在する場合、
docs/adr/README.mdインデックスをスキャンして関連するエントリを探します - 一致するADRファイルを読み込み、コンテキストと決定セクションを提示します
- 一致するものがない場合、「その決定に関するADRは見つかりませんでした。今すぐ記録しますか?」と応答します。
ADRディレクトリ構造
docs/
└── adr/
├── README.md ← 全ADRのインデックス
├── 0001-use-nextjs.md
├── 0002-postgres-over-mongo.md
├── 0003-rest-over-graphql.md
└── template.md ← 手動操作用の空テンプレート
ADRインデックスフォーマット
# アーキテクチャ決定記録
| ADR | タイトル | ステータス | 日付 |
|-----|--------|--------|------|
| [0001](0001-use-nextjs.md) | フロントエンドフレームワークにNext.jsを採用 | accepted | 2026-01-15 |
| [0002](0002-postgres-over-mongo.md) | プライマリデータストアにMongoDBではなくPostgreSQLを採用 | accepted | 2026-01-20 |
| [0003](0003-rest-over-graphql.md) | GraphQLではなくREST APIを採用 | accepted | 2026-02-01 |
決定検出シグナル
会話の中でアーキテクチャ上の決定を示す以下のパターンに注意:
明示的なシグナル
- 「Xでいこう」
- 「YではなくXを使うべき」
- 「トレードオフには価値がある。なぜなら...」
- 「これをADRとして記録して」
暗黙的なシグナル(ADRの記録を提案する — ユーザーの確認なしに自動生成しない)
- 2つのフレームワークやライブラリを比較し、結論に達する
- 理由を示しながらデータベーススキーマの設計選択を行う
- アーキテクチャパターン(モノリス vs マイクロサービス、REST vs GraphQL)の間で選択する
- 認証/認可戦略を決定する
- 代替案を評価した上でデプロイメントインフラを選択する
優れたADRの条件
やるべきこと
- 具体的に — 「ORMを使う」ではなく「Prisma ORMを使う」
- 理由を記録する — 根拠は何を選んだかよりも重要
- 却下された代替案を含める — 将来の開発者は何が検討されたかを知る必要がある
- 結果を正直に述べる — すべての決定にはトレードオフがある
- 短く保つ — ADRは2分で読めるべき
- 現在形を使う — 「Xを使う予定」ではなく「Xを使う」
避けるべきこと
- 些細な決定を記録しない — 変数名やフォーマットの選択にADRは不要
- 長文を書かない — コンテキストセクションが10行を超える場合は長すぎる
- 代替案を省略しない — 「とにかく選んだ」は有効な根拠ではない
- 遡って記録する場合はマークを付ける — 過去の決定を記録する場合は、元の日付を明記する
- ADRを陳腐化させない — 置き換えられた決定は、その代替ADRを参照する
ADRのライフサイクル
proposed → accepted → [deprecated | superseded by ADR-NNNN]
- proposed: 決定が議論中で、まだ確定していない
- accepted: 決定が有効で、それに従っている
- deprecated: 決定がもはや関連しない(例:機能が削除された)
- superseded: 新しいADRがこれを置き換える(必ず置き換え先をリンクする)
記録する価値のある決定のカテゴリ
| カテゴリ | 例 |
|---|---|
| 技術選択 | フレームワーク、言語、データベース、クラウドプロバイダー |
| アーキテクチャパターン | モノリス vs マイクロサービス、イベント駆動、CQRS |
| APIデザイン | REST vs GraphQL、バージョニング戦略、認証メカニズム |
| データモデリング | スキーマ設計、正規化の決定、キャッシュ戦略 |
| インフラ | デプロイメントモデル、CI/CDパイプライン、監視スタック |
| セキュリティ | 認証戦略、暗号化アプローチ、シークレット管理 |
| テスト | テストフレームワーク、カバレッジ目標、E2E vs 統合テストのバランス |
| プロセス | ブランチ戦略、レビュープロセス、リリースサイクル |
他のスキルとの連携
- プランナーエージェント: プランナーがアーキテクチャ変更を提案した場合、ADRの作成を提案する
- コードレビューアーエージェント: 対応するADRなしにアーキテクチャ変更を導入するPRにフラグを立てる