← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0000type: adrstatus: accepted
pagemode: Lightkruchten: Executivescope: platformimplementation_status: N/A (メタ ADR、実装不要)proposed_at: 2026-05-12 22:30approved_at: 2026-05-12 22:30business: meta
型付き辺: 出 1 / 入 0
関連: ADR-0039全体は INDEX →

ADR-0000: Record architecture decisions

  • Status: Accepted
  • Mode: Light
  • Kruchten Type: Executive
  • Scope: platform
  • Implementation Status: N/A (メタ ADR、実装不要)
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-12 22:30
  • 承認日時 (JST): 2026-05-12 22:30

Kruchten Type は ADR-0031 (2026-05-13) で遡及追加。分類根拠は ADR-0031 §決定セクションおよび docs/adr/README.md の Kruchten 3 分類ガイドを参照。 Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。

コンテキスト

本プロジェクト (bizlp-gas-accounting) では、開発が進むにつれて「なぜこの選択をしたか (Why)」が失われやすい状況にあった。コードを読めば「何を (What)」は分かるが、判断の背景・代替案・トレードオフは時間とともに記憶から消える。

特に以下の状況が当てはまる:

  • 1 人開発 (+ 2026-10 入社予定 Jr 1 名) — 代表取締役が半年後の自分に文脈を伝える必要
  • 監査要件あり — 過去の判断根拠が監査時に問われる可能性
  • 業務委託エンジニア / 副業協力者の入退場 — オンボーディング時の参照ドキュメントが必要

業界では Michael Nygard が 2011 年に提唱した Architecture Decision Records (ADR) がこの問題への定番解として確立されており、Spotify / Backstage / GOV.UK / adr-tools / MADR など多くの実装事例がある。

決定

bizlp-gas-accounting プロジェクトでは、アーキテクチャ上重要な意思決定を ADR として docs/adr/ 配下に記録する。

採用するフォーマット:

  • Nygard + MADR 4.0 ミニマル統合形式 (docs/adr/templates/template.md 参照)
  • 4 桁連番 + ハイフン + ケバブケース (NNNN-kebab-case-title.md)
  • イミュータブル原則: Accepted 後の本文編集禁止、決定変更は新 ADR で Supersede
  • 運用ガイド: docs/adr/README.md (本ファイルとは別)
  • Decision Pipeline 経由起案: ADR-0019 で確立した LangGraph TS + Cloudflare Workers の自動起案フロー

詳細な命名規約・運用ルール・テンプレート選択は docs/adr/README.md を参照。本 ADR は「ADR を採用するという決定そのもの」のみを記録する不変アーティファクトとして機能する。

影響 (Consequences)

  • Good, because 過去の判断根拠が時間軸とともに保全され、将来の自分・Jr エンジニア・監査人への説明責任を果たせる
  • Good, because Markdown + Git でコードと同じワークフロー (PR レビュー / 履歴管理) に統合され、Wiki 等への分離による陳腐化を回避
  • Good, because Nygard / MADR の業界標準に準拠し、adr-tools / Log4brains 等のツールチェーン互換性を確保
  • Bad, because 重要な意思決定ごとに 1 ファイル作成する文書化オーバーヘッドが発生 (1 件あたり 30-60 分)
  • Bad, because Accepted 後の本文編集禁止のイミュータブル原則により、軽微な追記や訂正のたびに Supersede ADR が必要 (個人開発では小さな修正に Git commit を許容)

Confirmation (準拠確認 / Fitness Function)

本セクションは ADR-0036 (Accepted 2026-05-14) で遡及追加された。ADR-0031 パターン (業界標準準拠メタデータ後付け = 誤字修正範疇) に準拠する遡及で本文の意思決定内容は不変。

  • 検証手段: N/A — 要マッピング更新 (ADR-0036 遡及時点で未定義、月次レビューで確定)
  • 実行頻度: —
  • 違反時の対応: —

参照 (References)

  • 関連 ADR (本 ADR 採用後に蓄積されたもの):
    • ADR-0019: Decision Pipeline (LangGraph TS) — 自動起案フローの基盤
    • ADR-0021: UC スライス開発と監査ログ機構の採用 — ADR メタデータ運用 (起案日時 / 承認日時 (JST)) を確立
    • ADR-0022: Decision Pipeline への Policy Alignment ノード追加 — 会社方針適合評価ゲート
    • ADR-0023: ADR ドキュメント群の構造を業界標準に整える — 本 ADR (0000) を新設する決定を含む
  • 外部資料:
  • 関連 PR/Issue:
    • PR #633 (ADR-0023 起案): 本 ADR 0000 を新設する決定を含む
    • 本 ADR を含む renaming 実装 PR (要追記)