0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

General Decision Recordというものを考えてみる

0
Last updated at Posted at 2026-04-18

これは何?

AIが推論という名のダイスロールでファンブルしないようにするためのアプローチ

  • GDR
  • AI-Driven GDR ビルドアップ

を紹介します。

GDR とは何か?

ADR(Architectural Decision Record)の拡張概念です。
GDR は仕様策定・UI 設計・運用方針・開発プロセス・ビジネス判断など、プロジェクト内のあらゆる意思決定を統一フォーマットで記録します。

目的

  1. 判断の根拠を残す — なぜそう決めたかを追跡可能にする
  2. 再検討を可能にする — 状況変化時に当時の前提を確認して判断を更新できる
  3. 代替案を記録する — 不採用の選択肢とその理由を残し、同じ議論の繰り返しを防ぐ

書式

GDR レコードは scope(決定の影響領域)と PREFIX(ドメイン識別子)という 2 つの分類軸を持ちます。いずれもプロジェクトごとに定義します。

**GDR-{PREFIX}-{番号}: {決定の要約}**

- **status:** Proposed | Approved | Implemented | Superseded
- **scope:** 影響領域の略記(カンマ区切り)
- **決定:** 何をするか(または何をしないか)
- **理由:** なぜその判断に至ったか(代替案との比較、トレードオフ)
- **影響:** この決定がもたらす具体的な影響
- **再検討条件:** どのような状況変化があれば判断を見直すか
  • scope: 決定の影響領域(例: arch, spec, ui, pol)。プロジェクトごとに定義する
  • PREFIX: ドメイン識別子(例: INFRA, UI, AD)。GDR ID の一部として使う

そして AI-Driven GDR ビルドアップ

AI-Driven GDR ビルドアップとは、AI との対話を通じて GDR を反復的に積み上げながらプロジェクトを前進させる開発プロセスです。

従来手法との違い

手法 判断の記録タイミング AI との相性
ウォーターフォール 設計フェーズで事前作成
TDD テスト作成時に暗黙的
ADR 併用アジャイル 実装後に追認で記録
GDR ビルドアップ 対話中にリアルタイムで結晶化

「GDR 駆動開発」ではなく「ビルドアップ」と呼ぶのは、GDR を先に書いてから開発するのではなく、対話と実装を通じて判断が積み上がっていくプロセスだからです。開発を駆動するのは GDR ではなく AI です。

期待される効果

  • 判断の揮発を防ぐ — 対話がそのまま GDR として永続化される
  • 属人性の排除 — 担当者が変わっても判断を追跡できる
  • 意思決定の速度向上 — AI が情報収集・整理を担い、人間は「選ぶ」ことに集中
  • 過剰設計の早期検出 — ROI ベースで過剰な施策を刈り込める
  • 再検討の仕組み化 — 「再検討条件」により見直すべき判断が自動的に特定される
  • オンボーディングの加速 — 新規参加者が判断履歴を辿れる

また、AI の既知の失敗モード(ハルシネーション、コンテキスト喪失、過剰同意、矛盾生成など)に対しても構造的な抑止効果があります。詳細は AI-Driven GDR ビルドアップ を参照してください。

サイクル

要件・課題を伝える
  ↓
AI が分析し、判断を GDR として構造化
  ↓
レビュー・フィードバック(修正があれば GDR を更新して再提案)
  ↓
実装(コード → テスト・ビルドで検証 → GDR ステータス更新)
  ↓
次の要件・課題へ(繰り返し)

3 つの原則

  1. 対話が設計書を生む(Dialog-First) — 設計書を書いてから対話するのではなく、対話の中で設計が生まれる
  2. 判断は積み上がる(Incremental Crystallization) — 最初は粗い判断でスタートし、レビュー・実装を経て精度が上がる
  3. 実装が判断を検証する(Implementation Validates Decision) — GDR は仮説。実装とテストで初めて検証される

導入ステップ

  1. プロジェクトに general-decision-record を配置(clone / fork / submodule / download)
  2. プロジェクトに沿った内容で 1 で取得した各 GDR 文書のローカライズを行う
  3. 「要件を伝える → AI が GDR を構造化 → レビュー → 実装」のサイクルを回す
  4. ビルドアップ記録にサイクルの流れを追記していく

デメリット

  • あなたが行っていた従来のやり方よりもトークンの使用量は増大するかもしれません
  • 高機能なローカルLLMの維持に関わらず、一定の料金が必要となることでしょう

こちらで文書を管理しています。
引用元: General Decision Record (GDR)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?