英語でADR（アーキテクチャ決定記録）を書くよう求められたとき、何をどこまで書けばいいか迷った経験はないだろうか。
ADRは「なぜその技術的決定をしたのか」を記録するドキュメントだ。グローバルチームでは英語が基本になるが、5つのセクション構成さえ押さえれば英語でも問題なく書ける。
この記事では、ADRに必要な5つの構成要素と、そのまま使える日英テンプレートを紹介する。コピペして使えばすぐに実務で活用できる。
ADRに必要な5つの構成要素
ADR（Architecture Decision Record）は技術的決定の背景・選択肢・結果を1決定1ファイルで記録するドキュメントだ。以下の5つが標準的な構成要素になる。
- タイトル・ステータス（Title & Status）
- 背景・課題（Context）
- 検討した選択肢（Considered Options）
- 決定内容（Decision）
- 影響・結果（Consequences）
なぜADRを書くのか
「なぜこの構成になっているのか」は半年後には誰も覚えていない。ADRを残すことで、後から参加したメンバーが決定の経緯を理解でき、同じ議論の繰り返しを防げる。
「未来のチームメンバーへの手紙」がADRの本質だ。
ADRとアーキテクチャ設計書の違い
ADRは「個々の決定」を時系列で記録する軽量ドキュメントだ。一方、アーキテクチャ設計書は「システム全体の現在の構成」を示す網羅的なドキュメントになる。設計書が地図なら、ADRはその地図に至った判断の履歴だ。
設計書の書き方は英語アーキテクチャ設計書の書き方でも確認してほしい。
テンプレートをダウンロード（Word）
以下のWordファイルをダウンロードして、プロジェクトに合わせてカスタマイズして使ってほしい。表の列・行はそのまま追加・削除できる。
📥 日本語テンプレートをダウンロード（Word）
📥 Download English Template (Word)
日本語版テンプレート（コピペOK）
タイトル・ステータス
| 項目 | 内容 |
|---|---|
| ADR番号 | （例：ADR-012） |
| タイトル | （例：セッション管理にRedisを採用する） |
| ステータス | Proposed / Accepted / Deprecated / Superseded |
| 決定日 | YYYY-MM-DD |
| 決定者 | （例：バックエンドチーム＋テックリード） |
| 関連ADR | （例：ADR-008を置き換える） |
背景・課題
| 項目 | 内容 |
|---|---|
| 現状 | （例：セッションをアプリケーションサーバーのメモリで管理している） |
| 課題 | （例：サーバーを水平スケールするとセッションが失われ、ユーザーが再ログインを強いられる） |
| 制約条件 | （例：レイテンシは10ms以内。既存のAWS環境を利用する。追加予算は月5万円まで） |
| 決定の期限 | （例：負荷増対応のため2026年Q3のスケールアウト前に決定が必要） |
検討した選択肢
| 選択肢 | メリット | デメリット |
|---|---|---|
| 案1：Redis（ElastiCache） | 高速・実績豊富・マネージドで運用負荷が低い | 追加コストが発生する。障害時の影響範囲が広い |
| 案2：DynamoDB | サーバーレスでスケール自動。可用性が高い | レイテンシがRedisより大きい。設計の自由度が低い |
| 案3：Sticky Session | 追加コストなし。実装変更が最小 | スケールイン時にセッションが失われる。根本解決にならない |
決定内容
| 項目 | 内容 |
|---|---|
| 決定 | （例：案1のRedis（ElastiCache）を採用する） |
| 主な理由1 | （例：レイテンシ要件10ms以内を満たすのはRedisのみだった） |
| 主な理由2 | （例：チームにRedisの運用経験があり、学習コストが低い） |
| 主な理由3 | （例：マネージドサービスのため、運用負荷の増加が最小限に抑えられる） |
影響・結果
| 種類 | 内容 |
|---|---|
| ポジティブな影響 | （例：水平スケールが可能になり、セッション切れの問い合わせが解消される見込み） |
| ネガティブな影響 | （例：月3万円のコスト増。Redis障害時は全ユーザーのセッションが失われる） |
| 必要な対応 | （例：Redis障害時のフォールバック設計をADR-013で別途決定する） |
| 再評価の条件 | （例：月間コストが5万円を超えた場合、またはレイテンシ要件が変わった場合に見直す） |
英語版テンプレート（コピペOK）
Title & Status
| Item | Details |
|---|---|
| ADR Number | (e.g., ADR-012) |
| Title | (e.g., Use Redis for session management) |
| Status | Proposed / Accepted / Deprecated / Superseded |
| Date | YYYY-MM-DD |
| Deciders | (e.g., Backend team + Tech Lead) |
| Related ADRs | (e.g., Supersedes ADR-008) |
Context
| Item | Details |
|---|---|
| Current State | (e.g., Sessions are stored in application server memory.) |
| Problem | (e.g., Horizontal scaling causes session loss, forcing users to log in again.) |
| Constraints | (e.g., Latency must be under 10ms. Must use the existing AWS environment. Budget up to $350/month.) |
| Deadline | (e.g., Decision needed before the Q3 2026 scale-out to handle increased load.) |
Considered Options
| Option | Pros | Cons |
|---|---|---|
| Option 1: Redis (ElastiCache) | Fast, proven, low operational overhead as a managed service. | Additional cost. Wide blast radius on failure. |
| Option 2: DynamoDB | Serverless with automatic scaling. High availability. | Higher latency than Redis. Less design flexibility. |
| Option 3: Sticky Sessions | No additional cost. Minimal code changes. | Sessions are lost on scale-in. Not a fundamental solution. |
Decision
| Item | Details |
|---|---|
| Decision | (e.g., We will adopt Option 1: Redis (ElastiCache).) |
| Reason 1 | (e.g., Redis was the only option that met the 10ms latency requirement.) |
| Reason 2 | (e.g., The team has operational experience with Redis, minimizing the learning curve.) |
| Reason 3 | (e.g., As a managed service, it adds minimal operational overhead.) |
Consequences
| Type | Details |
|---|---|
| Positive | (e.g., Enables horizontal scaling and eliminates session-loss complaints.) |
| Negative | (e.g., Adds $200/month in cost. A Redis outage would invalidate all user sessions.) |
| Follow-ups | (e.g., Design a fallback for Redis outages in ADR-013.) |
| Revisit When | (e.g., Monthly cost exceeds $350, or latency requirements change.) |
各セクションの書き方と例文
テンプレートを埋めるときに悩みやすいセクションを解説する。
Context（背景）の書き方
Contextは「事実」だけを書く。意見や結論を混ぜず、現状・課題・制約を客観的に記述することで、後から読む人が決定の妥当性を判断できる。
| 日本語 | 英語 |
|---|---|
| 現在〇〇という課題があります | We are currently facing [problem]. |
| 〇〇という制約があります | We have a constraint that [constraint]. |
| 〇〇までに決定が必要です | A decision is needed by 2026/06/13. |
| この決定はADR-008を置き換えます | This decision supersedes ADR-008. |
| 前提条件が変わったため再検討します | We are revisiting this because the assumptions have changed. |
選択肢比較・決定のフレーズ
| 日本語 | 英語 |
|---|---|
| 3つの選択肢を検討しました | We considered three options. |
| トレードオフは〇〇です | The trade-off is [trade-off]. |
| 〇〇の理由で案1を採用します | We chose Option 1 because [reason]. |
| この案は〇〇の理由で見送りました | We rejected this option because [reason]. |
| 完璧な選択肢はありませんでした | There was no perfect option. |
アーキテクチャ議論のフレーズはエンジニアの英語アーキテクチャ議論術でも確認してほしい。
ADRでよく使う英語表現
実務でよく使う英語表現を場面別にまとめた。
ADR・設計判断の基本用語
| 日本語 | 英語 |
|---|---|
| アーキテクチャ決定記録 | Architecture Decision Record (ADR) |
| 承認済み | Accepted |
| 提案中 | Proposed |
| 廃止 | Deprecated |
| 置き換え済み | Superseded |
| トレードオフ | Trade-off |
| 制約条件 | Constraint |
| 技術選定 | Technology Selection |
決定の影響を説明するフレーズ
| 日本語 | 英語 |
|---|---|
| この決定により〇〇が可能になります | This decision enables [benefit]. |
| 〇〇というリスクを受け入れます | We accept the risk of [risk]. |
| 運用コストが増加します | This will increase operational costs. |
| 〇〇の場合は再評価します | We will revisit this if [condition]. |
| 移行は段階的に行います | The migration will be done incrementally. |
技術的負債の議論はエンジニアの英語技術的負債議論術でも参考にしてほしい。
まとめ：英語ADRは5つのセクションで完成する
英語ADRに必要な構成要素を整理した。
- Contextで「現状・課題・制約」を事実ベースで記録する
- 検討した選択肢で「採用しなかった案とその理由」も必ず残す
- Decisionで「何を・なぜ」を理由3つ以内で簡潔に書く
- Consequencesで「ネガティブな影響と再評価の条件」まで開示する
テンプレートをコピーして、1決定1ファイルでリポジトリの docs/adr/ に蓄積してほしい。特に「採用しなかった選択肢」を残すことで、半年後の「なぜRedisなの？」という議論の繰り返しを防げる。
コメント