D-quints 概論

Abstract（要旨）

大規模言語モデル（LLM）を用いたAIコーディングの普及は、開発速度を向上させた一方で、コンテキスト肥大・指示の属人化・構造崩壊・設計と実装の乖離といった副作用が現場で報告されている。本稿は、これらの多くがAIの性能不足単独では説明しきれず、コード中心の開発プロセスをAI生成にそのまま適用した構造的不整合に起因する、という仮説を提示する。

D-quints（Domain-Driven Design・Document-Driven Development・AI特性の融合）は、構造化された仕様書（Spec; Markdown形式）を唯一の真実（Single Source of Truth; SSOT）とし、AIをSpecからコードを生成するコンパイラ（比喩）として位置づける開発モデルである。

本稿の主軸は、Spec 執筆・実装生成において AI を同一モデル・同一単価で使うのではなく、3段階に役割分担することで AI コストを抑えつつ品質を確保する点にある。

Spec is source. AI is compiler.（比喩 — 厳密な決定論的コンパイラではない。§4.2 参照）

Cheap AI checks Spec. Human decides meaning. Smart AI writes code.

本稿（技術提言書）は概念提唱および最小仕様定義を目的とする。定量実証・大規模適用事例は Phase 1 以降の検証課題と位置づける。ただし、Specスキーマ・Convention形式・例外運用・検証仮説・反証条件を明示し、反証可能かつ実装可能な形でフレームワークを提示する。

本稿の位置づけとエビデンス方針

1. 背景および市場の課題

近年、大規模言語モデル（LLM）をはじめとするAIコーディングアシスタントの普及により、ソフトウェア開発のパラダイムは急激な変化を迎えている。GitHub 調査によれば、公開リポジトリにおける AI 支援コミットの割合は増加傾向にあり [1]、個人・小チームの生産性向上が広く報告されている。

一方、AI駆動型開発がスケールするにつれ、現場では以下の4つの課題が持続可能性を脅かす要因として繰り返し観察される（本稿の問題設定仮説）。

これらが同時に成立すると、「短期の生成速度向上と、中長期の構造劣化がトレードオフになる」状況が生じうる。加えて、高性能モデルをチャット試行錯誤やコード修正に多用すると、API コストが想定以上に膨らむという経済的な問題も現場で報告されている。本稿はこれらを必然的な帰結ではなく、プロセス設計の選択として再定義可能である、と位置づける。

2. 問題の本質

§1 の諸問題は、AI自体の性能不足のみに起因するものではない、というのが本稿の中核仮説である。より正確には、「コードをSSOTとする従来プロセスに、自律的コード生成器（LLM）をそのまま載せた」ことによる構造的不整合が、再現性・保守性・説明責任の問題を増幅する、と論じる。

従来の開発モデルでは、コードが事実（SSOT）、ドキュメントは補助、人間が暗黙知で意図を補完する、という前提が共有されてきた。この構造は、人間が最終判断者である限りは機能しうる。しかしAIが大量のコードを生成する局面では、意味（Spec）の管理を放棄し、生成物（Code）を事実として扱うと、再現性が低く、属人性が高く、スケールしにくい状態に陥りうる。

反例（本仮説の限界）： 優れたプロンプト設計、エージェントオーケストレーション、強固なCI/CD・コードレビュー文化を持つチームでは、コード中心のままでも一定規模までスケールしうる。D-quintsは「唯一の正解」ではなく、Spec中心に構造を寄せることで再現性と説明責任を優先する選択肢として提示する。

3. 基本思想と命名のロジック

D-quintsは、ドメイン駆動設計（Domain-Driven Design; DDD） [3]、ドキュメント駆動開発（Document-Driven Development; DocDD）、LLMの生成特性を統合し、開発モデルの前提を再定義するフレームワークである。

3.1 命名の由来

D-quints は、次の2系統の思想を Driven（駆動） という共通軸で統合した名称である。

• Domain-Driven Design — ドメインの意味を設計の中心に据える
• Document-Driven Development — ドキュメント（仕様）によって開発を駆動する

Quints（5つ子） は、フレームワークが扱う5つの関心を象徴する語である（厳密な数学的分割ではなく、思想のラベルとして用いる）。

注記： 「三位一体（DDD + DocDD + AI）」は中核の3要素を指し、「Quints（5要素）」はフレームワーク全体の象徴名である。数え上げの厳密性より、Specを駆動源に統一する思想の一貫性を優先する。

3.2 定義

D-quints とは、「構造化された仕様書（Spec; Markdown形式）を唯一の真実（SSOT）とし、AIを人間が記述したSpecからコードを生成するコンパイラ（比喩）として扱う開発モデル」である。

用語定義

3.3 コア構造（データフロー）

    Reality（業務・ドメインの現実）
          ↓  モデル化（人間）
    Spec（MD）  ←←← 【 SSOT（唯一の真実）】
          ↓
    ┌─────────────────────────────────────┐
    │ ① Spec Lint（ローカルLLM / 低コスト） │  ← 反復可能・低単価
    └─────────────────────────────────────┘
          ↓
    ┌─────────────────────────────────────┐
    │ ② 業務・実務レビュー（人間）          │  ← 意味確定
    └─────────────────────────────────────┘
          ↓  構造化入力 + Convention
    ┌─────────────────────────────────────┐
    │ ③ コーディング（高性能・有料モデル）   │  ← 確定 Spec のみ投入
    └─────────────────────────────────────┘
          ↓
    Artefact（Code / Tests / Docs — 再生成可能）

原則： 変更の起点は常に Spec。Artefact から Spec への暗黙の逆流（コードを直して仕様を更新しない運用）は禁止する。

Reality と Spec の関係： Reality が変化した場合、人間は Spec を更新し、Artefact を再生成する。SSOT は常に Spec である。Reality と Spec の差分は、業務テスト・受入確認で検出する（§6）。

4. 核心的特徴（Architectural Features）

§4.1〜4.5・4.8 はフレームワークの必須仕様（Normative）である。§5 の普遍規約は、それを支える思想テーゼ（Informative）として位置づける。

4.1 Spec中心設計（SSOTの徹底）

すべての仕様はSpec（Markdown）に記述され、コードはそこから出力される生成物に過ぎない。Specの最小構造は Appendix A を参照。

DocID 仕様：

コメント方針：

• コード内の処理説明インラインコメントは原則禁止
• モジュール先頭の DocID参照 および Spec由来の自動生成ヘッダ のみ許可
• 障害調査時は DocID から Spec へ辿る（§4.6）

4.2 構造化入力と「コンパイラ」比喩の限界

D-quintsは、チャット的な曖昧指示を排し、Spec + Convention による構造化入力をLLMへ与えることで、出力の再現性を高める。これは「プロンプト非依存」ではなく、プロンプト内容をSpecリポジトリに外部化し、バージョン管理するアプローチである。

限界の明示：

現状のLLMは、従来のプログラミング言語コンパイラのような完全な決定論を保証しない。モデルバージョン、推論基盤、サンプリング設定により出力分散が生じうる。temperature=0 も決定論を保証しない（分散低減のヒューリスティックに過ぎない）。

結論： 「AI is compiler」は役割分担 — 人間が意味を決め、AIがSpecからArtefactへ変換するという比喩である。実体は構造化入力と検証層付きの確率的生成器として設計・運用する。なお、コンパイラとして呼ぶのは主に Tier 3（高性能モデル）であり、Tier 1 の Spec Lint は「リンター（静的解析）」に相当する。

4.3 再生成前提（Disposable Code）と局所化ルール

ソースコードを長期間手編集する対象とせず、仕様変更時は Spec を修正し、対象スコープを再生成する。

再生成スコープは Bounded Context または DocID 単位に局所化し、コンテキスト肥大を防ぐ。

再生成時のリグレッション対策：

4.4 役割の厳密な分離（3段階モデル）

D-quints では、AI 利用を Tier 1（低コスト）→ Tier 2（人間）→ Tier 3（高性能） の3段階に固定する。詳細は §4.8。

4.5 規約（Convention）による制御

同一 Spec に対し、具象化コンパイラ規約（Appendix B）を差し替えることで、言語・フレームワーク・複雑度上限を変更できる。Spec はドメイン意味を、Convention は実装制約を担う。

4.6 例外運用（Hotfix プロトコル）

原則として Artefact の手編集は禁止するが、本番障害等の緊急時には以下の時間限定例外を認める。

【通常】 Reality 変化 → Spec 更新 → 再生成 → 検証 → デプロイ

【緊急例外】 本番障害 → 最小限の Artefact パッチ（Hotfix）
                    → 24時間以内に Spec へバックポート
                    → 再生成でパッチと同等以上を確認
                    → Hotfix ブランチを Spec 整合後にクローズ

4.7 SSOT の適用範囲（Artefact 分類）

すべてを Spec から生成することを目標としつつ、現実的な運用のため Artefact を3層に分類する。

テストの SSOT： 契約テスト・受入テストの期待値とシナリオは Spec に記述する。テストコードは Spec から生成する（層A）。スナップショットファイルは生成物として Git 管理し、Spec 意図変更時のみ更新する。

4.8 3段階AI活用モデル（コスト最適化の主軸）

本フレームワークの経済的・運用上の核心は、すべての工程に高性能モデルを使わない点にある。

なぜ3段階か

チャット型 AI コーディングでは、試行錯誤・コード修正・仕様の言い換えまで高性能モデルに任せがちであり、トークン単価 × 反復回数が膨らむ。D-quints では Spec を SSOT として分離し、反復が多い工程（Spec 推敲）を低コスト側に寄せ、生成は確定 Spec に対してのみ高性能モデルを使う。

Tier 1（Spec Lint）のチェック項目

Tier 1 は意味の正しさを保証しない。業務上正しいかどうかは Tier 2 の人間が判断する。

Tier 3 への投入条件（Gate C）

以下を満たすまで Tier 3 を呼び出さない。

• Tier 1 のブロッキング指摘 = 0
• Tier 2 による業務・実務レビュー完了
• OPEN: / TODO: が解消されている

これにより、高性能モデルへの入力は確定 Spec のみに限定され、生成後の手戻り（＝追加 API 呼び出し）を削減する。

コスト削減のメカニズム（概念式）

従来型（チャット中心）:
  コスト ≈ 高性能モデル単価 × （試行錯誤 + コード修正 + 仕様確認）の総トークン数

D-quints（3段階）:
  コスト ≈ 低コストモデル単価 × Spec Lint 反復
        + 高性能モデル単価 × 確定 Spec に対する生成回数（原則 1 DocID あたり 1 回）

Spec 収束を Tier 1/2 で完了させるほど、Tier 3 の再生成回数が減り、総 API コストの削減が期待できる（検証仮説 H6。§11.2）。

5. D-quints 普遍規約（AI制約フィルターのテーゼ）

本章はInformative（参考テーゼ）である。§4 の必須仕様を具体化する際の指針であり、数値（行数上限等）は Convention でプロジェクトごとに定義する。

普遍規約（メタ）をベースに、具象化コンパイラ規約（Appendix B）を作成し、AI 生成パイプラインへ注入する。

5.0 規約の2層構造

    D-quints 普遍規約（メタ規約 / テーゼ）
          ↓ 具象化
    具象化コンパイラ規約（YAML 等 / プロジェクト固有）
          ↓ 注入
    AI（Compiler）への制約フィルター

5.1 命名規則

略語・意味のない変数名（tmp, data 等）を避け、ドメイン語彙に沿った英語名を用いる。

5.2 構造・複雑度制限

単一責務を徹底し、関数長・ネスト深度に上限を設ける。上限超過は仕様過密として Spec 分割を促す（AI レビュー層が指摘）。

5.3 定数管理

マジックナンバー・ハードコードを Spec の定数定義へ昇格させる。

5.4 コメント原則

処理説明コメントは Spec へ書く。コード側は DocID 参照のみ（§4.1）。

5.5 AI特有ルール

推測による仕様補完を禁止する。不明点は Spec に TODO: または OPEN: として明示し、人間の意味決定を待つ。

6. 開発プロセス

D-quints の開発サイクルは、Spec を反復的に収束させるプロセスである。Tier 1（低コスト AI）→ Tier 2（人間）→ Tier 3（高性能 AI） の順序を厳守し、各段階に Gate（判定） を設ける。

① Spec 作成（人間）
      ↓ Gate A: DocID・必須セクション・OPEN 項目の確認
② Tier 1 — Spec Lint（ローカル LLM / 低コストモデル）
      │  欠落・矛盾・仕様過密・曖昧表現を検出
      │  ← 指摘ありなら ① へ戻る（低コストで反復）
      ↓ Gate B: ブロッキング指摘 = 0
③ Tier 2 — 業務・実務レビュー（人間）
      │  ドメインルール・例外・現場制約・受入基準を確定
      ↓ Gate C: Spec 確定（OPEN 解消）
④ Tier 3 — コーディング（有料の高性能モデル）
      │  確定 Spec + Convention のみを入力
      ↓ Gate D: 静的解析 + 契約テスト + Convention 準拠
⑤ 業務テスト・受入
      ↓ Gate E: Reality との整合
⑥ Spec 修正 → ① へ（必要時。修正後は必ず ② から再開）

Tier 跨ぎの禁止：

収束の終了条件（Gate E 合格）：

• 契約テスト・業務テストが Spec に記述された受入条件を満たす
• 非機能要件（§10）のチェックリストを満たす
• 未解決 OPEN: が存在しない

リリース判断： Gate D + E 合格後、Artefact をデプロイする。デプロイ後の変更は Spec 経由のみ（§4.6 例外除く）。

7. 従来手法との本質的な差

本稿の「従来開発」は、コードをSSOTとし、ドキュメントを後追いする典型パターンを指す。GitOps・契約ファースト・TDD 等を組み合わせた現代的開発と矛盾するわけではない。

8. 関連研究・先行手法との位置づけ

D-quints は既存思想との合成と差分の明示として位置づける。詳細は Appendix C。

D-quints の独自貢献（仮説）：

1. 3段階AI活用モデル — Spec Lint（低コスト）→ 人間レビュー → コーディング（高性能）で API コストを抑える
2. Spec SSOT + AI 生成 + 再生成運用 の三位一体
3. 普遍規約 → 具象化 Convention の2層による AI 制約の外部化
4. Hotfix 例外プロトコル による現場運用との両立
5. Artefact 分類（A/B/C） による SSOT 適用範囲の明確化

9. 適用領域と限界

9.1 適している

9.2 不向き（または追加コストが大きい）

9.3 レガシー移行

既存コードベースへの適用は Strangler Fig パターン を推奨する。新機能・新 BC から Spec 先行で開始し、既存モジュールは DocID 参照を段階的に付与しながら Spec 化する。一括 Big Bang 移行は Phase 3 以降の検証対象とする。

10. 非機能要件（セキュリティ・コスト・組織）

10.1 セキュリティ

10.2 コスト（3段階モデルによる最適化）

D-quints のコスト戦略は「高性能モデルを使わない」ことではなく、高性能モデルを呼ぶタイミングと回数を限定することにある。

運用指針：

• Tier 1 は Convention ファイルでモデル名・エンドポイントを指定（Appendix B の lint セクション）
• Tier 3 は DocID 単位の生成を原則とし、同一 Spec への無目的な再生成を避ける
• 月次で Tier 別トークン使用量を計測し、Tier 3 比率が高い場合は Spec 収束不足を疑う

Phase 2 で H6 として、チャット型開発との 総 API コスト对比 を計測する。

10.3 組織・スキル

エンジニアの役割は「コードを書く」から「意味を Spec に確定する」へシフトする。教育・テンプレート整備が導入成否を左右する。

11. 検証方針と今後のロードマップ

11.1 現状の位置づけ

本稿は技術提言書 v1.0（公開版） として、最小仕様と検証設計を定義する。定量実証は Phase 1 以降で行う。

11.2 検証仮説と反証条件

統制： 同一ドメイン・類似チーム規模・同一 LLM ファミリを原則とする。閾値は Phase 1 PoC でキャリブレーションする。

11.3 ロードマップ

11.4 Phase 1 計画（概要）

ドメイン： 注文管理（Order BC）の単一ユースケース

検証項目：

• 同一 Spec で 20 回生成 → H1
• Spec 1 行変更 → 部分再生成 → 契約テスト通過
• Convention 変更（TypeScript ↔ Python）→ 同一 Spec から生成
• Hotfix 例外プロトコルのドライラン
• Tier 1（ローカル LLM）→ Tier 3（高性能）のコスト对比 → H6

詳細な Spec / Convention 例は Appendix A / B を参照。

12. 結論

D-quints は、AI 時代において真実の源泉を Spec に置き直す実行モデルである。同時に、AI コストを抑えるための実務的な設計でもある。

高性能モデルをすべての工程に使うのではなく、①ローカル LLM や低コストモデルで Spec の過不足をチェックし、②人間が業務・実務の観点でレビューし、③確定 Spec のみを有料の高性能 AI にコーディングさせる — この3段階を主軸とすることで、試行錯誤コストを Tier 1 に、判断コストを人間に、生成コストを必要最小限の Tier 3 に分散できる。

Cheap AI checks Spec. Human decides meaning. Smart AI writes code.

本提言書 v1.0 は、D-quints の第一歩として3段階AI活用モデル・最小仕様・例外運用・検証設計を公開する。各主張は反証条件付きの仮説として Phase 1 以降で検証し、結果に応じて改訂する。

提言： エンジニアリングの中心を「高性能 AI に試行錯誤させること」から「Spec を低コストに収束させ、高性能 AI には確定 Spec だけを渡すこと」へ移す。

Appendix A: Spec 最小スキーマ（参考例）

以下は Phase 1 想定の参考例である。プロジェクトで subset 化してよいが、DocID と受入条件は必須とする。

---
bc: ORDER
version: 1.0.0
status: active
---

# 注文作成ユースケース

<!-- DocID: DOC-ORDER-001 -->

## 概要
顧客が商品を注文する。

## 入力
| 名前 | 型 | 必須 | 説明 |
|---|---|---|---|
| customerId | string | yes | 顧客ID |
| items | array | yes | 注文明細 |

## 出力
| 名前 | 型 | 説明 |
|---|---|---|
| orderId | string | 発行された注文ID |

## ドメインルール
- items が空の場合は `EMPTY_ORDER` エラー
- 各 item.quantity は 1 以上

## 受入条件（契約テスト）
- [ ] 正常系: 有効な items → orderId が返る
- [ ] 異常系: items=[] → EMPTY_ORDER

## OPEN
（なし）

必須セクション： 概要、入出力または IF、ドメインルール、受入条件、OPEN（空でも可）

Appendix B: Convention 設定例（参考例）

# convention.yaml — Phase 1 参考例
version: "1.0"
meta:
  extends: d-quints-universal  # 普遍規約テーゼ

target:
  language: typescript
  runtime: node20
  framework: none  # 純粋関数

structure:
  max_function_lines: 30
  max_nesting_depth: 2
  one_docid_per_file: false

naming:
  language: en
  forbidden: [tmp, data, foo]

comments:
  allow_inline: false
  require_spec_header: true

generation:
  tier: 3
  model: "（組織で指定 — 高性能・有料モデル）"
  temperature: 0
  prompt_template: "pipelines/generate.md"

lint:
  tier: 1
  model: "（組織で指定 — ローカル LLM または低コストモデル）"
  endpoint: "http://localhost:11434"  # 例: Ollama
  prompt_template: "pipelines/spec-lint.md"
  max_iterations: 10  # Spec 収束までの Tier 1 反復上限

validation:
  lint: eslint
  static_analysis: true
  contract_tests: required

Appendix C: 参考文献

改訂履歴