CRDD概要（Overview）
September 12, 2026 · View on GitHub
CRDD概要（Overview）
Version: v0.20.1 Status: Stable Owner: Qual-Lab Last Updated: 2026-09-06 Related:
- 01_Principles.md
- 02_Terminology.md
- 03_Documentation.md
- 04_Agent_Organization.md
- 15_Progress.md
- 16_Quality_Assurance.md
- 17_Communication.md
- 18_Context_Dependency.md
- 52_Conformance_Audit.md
- 53_Gap_Impact_Audit.md
この文書で分かること（非規範の案内）
- CRDDを最初にどこから読めばよいか
- プロダクトリポジトリをどう構成するか
- 各正本文書がどの責務を持つか
- 変更・工程・監査をどの経路へ渡すか
- 外部標準をどの範囲で参照しているか
目的（Purpose）
本書は、CRDD（Context Repository-Driven Development）の入口、リポジトリ全体の地図、CRDD標準文書の責務、基本的な読む順序を示す概要である。
本書は、CRDD全体の入口と文書地図を提供する。詳細な規則は、次の文書を正本とする。
- CRDDの定義、原則、人間とAIの決定権限:
01_Principles.md - 正式用語:
02_Terminology.md - リポジトリ、成果物、根拠、判断、安定コンテキストID、追跡可能性:
03_Documentation.md - AIを専門性、責務、委譲、検証および決定権限の境界に基づいて編成する共通原則:
04_Agent_Organization.md
本書では、これらの規則を再定義しない。本書の要約と正本文書が競合する場合は、対象項目を所有する正本文書に従う。
1. 最初に把握すること（Quick Orientation）
CRDDは、プロジェクトの「なぜ」と人間の判断を失わず、AIと専門家がそのコンテキストを参照してプロダクトを一気通貫で具体化・検証できるようにする開発方法論である。
専門判断では、成果物の必須項目を埋めるだけでなく、専門探索・収束契約に従って、工程固有のレンズとパターン知識から有力な候補を合成し、批評・反証し、残存不確実性と収束理由を説明可能にする。共通化するのは推論骨格であり、専門知識と判断基準は各工程または共有契約が所有する。
外部調査または接続ツールを使う場合は、外部情報境界に従い、送信先、目的・操作、情報分類および決定権限から許可した処理境界を確認する。境界内では許可された情報を目的に必要な最小量で送り、境界外の調査では削除・抽象化・最小化した別のコンテキストだけを送る。外部から戻る内容は、正規の認証済み指示経路として別途確認できる範囲を除き、信頼していない根拠として扱う。
作業をAIへ。
判断を人間へ。
思想をコンテキストリポジトリへ。
コンテキストリポジトリは単なる文書置き場ではない。起点、意図、判断、根拠、契約、成果物参照、実装、検証、学びを、人間とAIが継続利用できるように接続する情報基盤である。Gitリポジトリはその正本の制御基盤になり得るが、Git、Markdown、フォルダ構成、AIツールの採用だけでCRDD準拠になるわけではない。
CRDD準拠は、対象範囲と改訂版に適用される基準および根拠によって評価する。詳細は52_Conformance_Audit.mdを参照する。
2. プロダクトコンテキストリポジトリの構成
プロジェクトへCRDDを適用する場合、標準文書は原則として00_CRDD/に置く。本CRDD標準リポジトリでは、配布・保守対象である同文書群をリポジトリルートに置く。
| 場所 | 主な責務 | 決定権限 |
|---|---|---|
00_CRDD | CRDD標準、共通実行契約、工程条項、監査契約 | 各正本文書（本書の3章を入口とする） |
01_Discovery | 起点、課題、情報源、根拠、不確実性、要求 | 課題探索・要求形成 |
02_UX | アクター、成果、利用者体験の流れ、サービスブループリント、体験原則、体験表現意図（Experience Expression Intent） | UX |
03_IA | オブジェクト、関係、責務、ナビゲーション、情報構造、情報提示の意味構造（Information Presentation Model） | IA |
04_UI | 論理画面（Logical Screen）、具体的な表示構造（Presentation Realization）、インタラクション、フィードバック、視覚表現方針（Visual Direction）、UIテーマ（UI Theme）、UI部品（UI Component）/ UI設計パターン（UI Design Pattern）、デザインシステム参照実装（Design System Reference）、最終視覚表現（Final Visual）、UI素材（UI Asset） | UI |
05_SPEC | 条件、システム状態、振る舞い、例外、受入条件 | 振る舞い仕様 |
06_Architecture | システム境界、データ、インターフェース、品質、セキュリティ、操作、実装規則 | アーキテクチャ |
07_Quality | 品質戦略、検証設計、検証結果、現在品質状態の統合表示 | 品質保証 |
08〜18 | 将来の工程横断成果物または共通運用領域のための予約。現在はフォルダを作らない | 文書化 |
19_Workflows | リポジトリ固有の反復可能な作業手順、運用手順、引き渡し | 作業手順 |
40_Develop | コード、構成、移行、ビルド、開発者テスト等の実装成果物 | 実装 |
80_Communication | Discoveryで管理される市場・採用仮説を該当時に参照し、外部へ伝える目的、受け手、表現、到達、反応測定、学びの還流、主張と根拠、公開済み記録を管理する。必要なRepositoryだけで使用する | 外部コミュニケーション |
90_Release | 変更トレース、リリース記録、CHANGELOG、配布物参照、リリース検証 | 変更、リリース |
99_Roadmap | 未完了の作業、課題、アイデア、変更候補、是正事項を横断する登録簿 | 文書化 |
UIと振る舞い仕様は直列工程ではない。両者は24_UI_Behavior_Specification.mdを共有契約として、相互参照しながら並行して具体化する。
課題探索・要求形成からアーキテクチャまでは、各工程に一つの固定入口を置く。案件規模に応じて入口名や基本のファイル分割を変えず、同じ入口内の記述、レビュー、根拠および詳細参照の深さを調整する。固定入口はリンクだけの索引ではなく、工程全体の対象範囲、網羅状態、主要な結論と判断、検証義務、未解決事項、次工程への義務を直接理解できる主要な正本成果物である。詳細成果物の内容は複製せず、決定権限、改訂版、現在状態および参照を示す。具体的なパスは文書化を正本とする。
根拠は成果物内、または最も近い親フォルダのEvidence/へ置く。判断の結果は結果となる正本成果物へ反映し、判断理由、根拠、代替案、履歴を同成果物へ残す。ルート直下に中央根拠フォルダまたは中央判断フォルダを基本構成として設けない。詳細は文書化を正本とする。
40_Developは実装成果物の領域であり、CRDD管理用Markdownの配置先にしない。コード固有README等を実装と同居させる場合も、上流コンテキストや判断理由の正本として暗黙に扱わない。
3. CRDD標準文書の構成
3.1. 文書番号の区分
文書番号は、CRDD文書の責務、分類、読む順序を補助する文書番号である。文書内のコンテキスト要素を追跡する安定コンテキストIDとは別の識別体系であり、一つの文書に複数の安定コンテキストIDが含まれてよい。
| 帯域 | 責務 |
|---|---|
00–03、04§1～§11 | 基礎規範候補：概要、原則、用語、文書化、エージェント組織の共通原則 |
04§12、05 | 非規範Architecture Candidate：エージェント／プロバイダー実行経路、自律Operation、責務、安全、運用健全性、Forward Compatibility |
04§13～§15 | 共有境界：参照する規範原則または非規範Architectureの強度を継承 |
06–09 | 予約 |
10–19 | 共通実行・提供・CRDD保守：エージェント、スキル、変更、リリース、作業手順、進捗、保守 |
20–29 | プロダクト工程条項とUI／振る舞い仕様横断契約 |
30–49 | 予約 |
50–59 | 横断監査契約 |
安定コンテキストIDの種類、付与境界、文書番号および成果物IDとの違いは03_Documentation.mdを正本とする。CHG-*は変更トレースの成果物IDであり、安定コンテキストIDではない。
3.2. 基礎原則、非規範Architecture候補と横断する決定権限
00～03と04_Agent_Organization.md§1～§11はv0.18.0の基礎規範、同書§12と05_Autonomous_Operation.mdはその境界を将来の実行形態へ投影して評価する非規範Architecture Candidateである。同書§13～§15の共有境界は、参照する規範原則または非規範Architectureの強度を継承する。ルート配置、ファイル単位の導線、文書番号およびStableヘッダーは規範性を変更しない。公式タグまたは不変のRelease識別子で参照された内容だけを公開基準として扱い、branchやStable表示だけから公開・採用を推定しない。非規範候補の存在、図、Profileまたは実証成功から、準拠要件、採用、Authority、Capability、Runtime利用可能性またはReleaseを成立させない。
| ファイル | 責務 |
|---|---|
00_Overview.md | CRDDへの入口、リポジトリ対応表、文書責務、読む順序 |
01_Principles.md | CRDDの定義、基本信条、準拠境界、人間／AIの決定権限、コンテキスト継続性、外部情報境界、工程遷移原則 |
02_Terminology.md | 中核コンテキスト種別、補助概念、責務・決定権限、状態遷移 / 状態用語、別名 |
03_Documentation.md | リポジトリ、成果物、文書記法、根拠、判断、安定コンテキストID、成果物参照、追跡可能性 |
04_Agent_Organization.md | §1～§11はエージェント組織の共通原則、§12は非規範の実行Architecture候補、§13～§15は参照元の強度を継承する共有境界 |
05_Autonomous_Operation.md | 能動的な再評価と自律Operation候補の全体像、責務境界、実行契約、安全、Operation健全性、人間接続および将来互換性 |
10_Agent.md | エージェント共通入力 / 出力、決定権限、委譲、サブエージェント統合、レビュー |
11_Skill.md | スキル共通状態遷移、専門探索・収束、視覚制作・材質／空間表現、外部調査・接続ツール実行、経路、中断・再開、レビュー、引き渡し、Git / Markdownの実行プロファイル |
12_Change.md | 90_Release/Changes/CHG-*.mdによる契機、変更意図、想定／実際の影響、実装、検証、終了のトレース |
13_Release.md | プロダクトリリースの最小契約、人間のリリース決定権限、リリース記録、CHANGELOG、リリース検証 |
14_Workflow.md | 19_Workflowsへ置くリポジトリ固有の反復可能な作業手順と引き渡し |
15_Progress.md | 進捗管理の最小対象、共通の進捗情報、算出階層、健全性、集約単位、開発方式の接続 |
16_Quality_Assurance.md | 工程横断の検証義務、検証設計、専門品質確認、検証結果、現在品質状態、Quality Center |
17_Communication.md | 外部コミュニケーションの目的、受け手、該当時のDiscovery市場・採用探索への接続、メッセージ・媒体・成果物・導線、主張と根拠、デザイン方針、公開判断、公開済み記録、測定と学びの還流 |
18_Context_Dependency.md | コンテキスト依存と成果物依存、完全契約を発火する管理対象境界、参照版、上書き、物理構成の選択、依存先更新時の影響評価 |
19_Maintenance.md | CRDD自身の変更、学びの昇格、版、採用プロジェクトの基準版評価、移行、修正、監査接続 |
3.3. プロダクト工程ごとの決定権限
21〜23および25〜29は、その工程の入口、変換、必要な責務の網羅、出口、工程判定基準、監査チェックリスト、ガイド付きスキル接続部を一体として定義する。24は独立工程ではなく、UIと振る舞い仕様の対応レビュー契約である。
| ファイル | 責務 |
|---|---|
21_Discovery.md | 課題探索・要求形成、機会仮説、判断を変える根拠、不確実性、REQ昇格、経路 |
22_UX.md | アクター、成果、体験合成、利用者体験の流れ、サービスブループリント、体験原則、体験表現意図、UXの網羅範囲 |
23_IA.md | オブジェクト、関係、責務、構造合成、ナビゲーション、情報構造、情報提示の意味構造 |
24_UI_Behavior_Specification.md | UIと振る舞い仕様の相互参照、対、整合性、共同レビューを定める横断契約 |
25_UI.md | 視覚表現方針、視覚制作、材質・空間表現、論理画面、具体的な表示構造、インタラクション、表示状態 / UI差分、UIテーマ、UI部品 / UI設計パターン、デザインシステム参照実装、最終視覚表現、UI素材、アクセシビリティ、UIの網羅範囲 |
26_Behavior_Specification.md | 振る舞い合成、条件、システム状態、規則、例外、失敗、受入条件、SPECの網羅範囲 |
27_Architecture.md | 設計要因、構造合成、境界・状態所有・失敗推論、データ、インターフェース、品質、セキュリティ、操作、互換性、実装規則 |
28_Implementation.md | 実装戦略、意味的に閉じた変更、コード、構成、移行、ビルド、開発者テスト、差分批評、実装根拠 |
29_Verification.md | 検証・根拠戦略、独立テスト / レビュー、新しい根拠、指摘事項、検証結果、リリース準備状況の推奨、学び |
3.4. 監査の決定権限
| ファイル | 責務 |
|---|---|
51_Document_Audit.md | 文書構造、参照、用語、決定権限、情報保存、追跡可能性の監査 |
52_Conformance_Audit.md | CRDD中核／プロファイル基準、必要な根拠、評価、準拠表明の適格性 |
53_Gap_Impact_Audit.md | 関係を横断する不足／影響探索、処置、再レビュー・再検証範囲 |
3.5. リポジトリ全体を補助する成果物
次はCRDD標準リポジトリ自身の公開・保守に使用する補助成果物であり、CRDDを適用するプロダクトリポジトリへ同じ受付ファイルの配置を要求するものではない。
| 成果物 | 責務 |
|---|---|
README.md | CRDD標準リポジトリの公開入口と簡易開始 |
ルート AGENTS.md | CRDD標準自身を保守するAI向けの共通リポジトリ接続部 |
ルート CLAUDE.md | ルート AGENTS.mdを利用するClaude Code固有の接続規則 |
.github/copilot-instructions.md | ルート正本と保守境界へ接続するGitHub Copilot固有の補助接続部 |
CONTRIBUTING.md | 公開フィードバック、標準変更提案、プルリクエストをCRDD保守へ接続する提案者向け入口 |
.github/ISSUE_TEMPLATE/ | 問題報告、標準変更提案、採用フィードバックの構造化された受付形式 |
.github/pull_request_template.md | 変更分類、根拠、決定権限、影響、移行、監査を確認するプルリクエスト入口 |
CHANGELOG.md | CRDD標準自体のバージョン間変更履歴。プロダクト固有のCHANGELOGとは別に扱う |
template/ | プロジェクトへCRDDを導入するためのひな型とAI入口ファイル |
template/tools/crdd-check.ts | 採用プロジェクトへ配布する軽量チェッカーの正本。全体確認を既定とし、親AIエージェントがレビュー／監査前の共通事前確認と参照関係の把握に使用する |
template/tools/crdd-coordinator.ts | clone／submodule利用者向けの安定したCoordinator起動入口。実行編成、診断、候補およびProject RuntimeのCLI操作へ接続する |
template/tools/crdd-mcp.ts | clone／submodule利用者向けの安定したMCP Server起動入口。stdioまたはlocalhost HTTPをProject Runtime公開契約へ接続する |
40_Develop/checker/crdd-check.ts | CRDD標準リポジトリのprivate checker packageから配布用チェッカー正本を呼び出す入口。配布正本はtemplate/tools/crdd-check.tsであり、監査または準拠判定の正本ではない |
06_Architecture/99_Coding_Standards.md | CRDD公式Repositoryの内部ツールに適用するファイル、フォルダ、TypeScript／Rust識別子、試験名および機械識別子（machine identifier）の命名正本 |
40_Develop/platform-access/ | OS固有の読み取り専用アクセス観測だけを所有するprivate Rust crate。CRDD本体・CLI・Policy・契約はTypeScriptに保持し、単独配布または公開CLIにしない |
CRDD標準自体のバージョン、CHANGELOG、タグ、移行と、採用プロジェクトにおけるCRDD基準版の評価・有効化は19_Maintenance.mdを正本とする。プロダクト固有リリースのCHANGELOGは13_Release.mdに従う。
3.6. 外部の基準と出典追跡
次は、CRDDが明示的に使用または参考にする外部情報源の中央索引である。関係と網羅範囲の意味、個別条項での記載規則は03_Documentation.mdを正本とする。参照キーは引用を簡潔にするための表示名であり、安定コンテキストID、文書番号、成果物IDではない。
| 参照キー | 情報源／正式な参照先 | 関係 | CRDDでの主な適用先 | 網羅範囲 |
|---|---|---|---|---|
BCP14 / RFC2119 / RFC8174 | IETF / RFC Editor: RFC 2119、RFC 8174 | uses | 文書化 — ロケールと規範表現 | Selected Concepts。大文字の規範語彙と大文字・小文字の境界 |
ISO29148-2018 | ISO / IEC / IEEE: ISO/IEC/IEEE 29148:2018 Requirements engineering | informed_by | 課題探索・要求形成 — 要求の昇格と集合品質 | 2026-07-21時点の現行版。改訂作業中のため置換時に再評価する。Selected Concepts。条項対応または準拠は表明しない |
ISO15288-2023 | ISO / IEC / IEEE: ISO/IEC/IEEE 15288:2023 Systems and software engineering — System life cycle processes | informed_by | 一気通貫の変換とライフサイクルプロセスの背景 | Referenced（参照のみ）。ライフサイクルモデルや準拠は表明しない |
ISO12207-2026 | ISO / IEC / IEEE: ISO/IEC/IEEE 12207:2026 Software life cycle processes | informed_by | ソフトウェアライフサイクルプロセスの背景 | Referenced（参照のみ）。特定のライフサイクルモデルまたは準拠は表明しない |
ISO25010-2023 | ISO / IEC: ISO/IEC 25010:2023 Product quality model | informed_by | 課題探索・要求形成の品質懸念プロファイル、SPEC、アーキテクチャ、検証 | Selected Concepts（選択した概念）。プロジェクトは必要な品質特性と対象範囲を選択できる |
EARS | Mavin, Wilkinson, Harwood, Novak (2009): Easy Approach to Requirements Syntax | uses | 振る舞い仕様 — EARSの使用 | Selected Concepts（選択した概念）。構文の使用は任意で、準拠は表明しない |
NIELSEN-HEURISTICS | Nielsen Norman Group: 10 Usability Heuristics for User Interface Design | informed_by | UIと視覚品質 | Referenced（参照のみ）。参考情報として使用する |
UNIVERSAL-DESIGN | NC State University, Center for Universal Design: The Principles of Universal Design, Version 2.0 | informed_by | UIと視覚品質 | Selected Concepts。準拠は表明しない |
WCAG22 | W3C: Web Content Accessibility Guidelines (WCAG) 2.2 | project_adopts | UIアクセシビリティプロファイル、振る舞い仕様、検証 | Referenced（参照のみ）。採用時はプロジェクトのプロファイルで適合レベル、対象プラットフォーム、対象範囲を選択する |
本索引は、外部情報源をCRDDの決定権限へ置き換えたり、CRDDが各情報源へ準拠していると宣言したりするものではない。情報源の全条項 / 基準を網羅したと主張するには、適用範囲、非適用理由、CRDD条項、検証根拠を条項 / 基準単位で対応づける。
4. 読み方と実行経路
4.1. 基礎原則を読む経路
人間が初めて読む場合は、本書の「最初に把握すること」と、対象作業の工程案内から始める。用語は分からないときに用語集で確認し、文書配置や記録方法が必要になったときに文書化を参照する。全基礎文書の通読を作業開始条件にしない。
AIまたはCRDD運用を設計する担当者は、対象範囲を決める前提として次の基礎正本を読む。
00 概要
↓
01 原則
↓
02 用語
↓
03 文書化
↓
04 エージェント組織
その後、実行主体に応じて10_Agent.mdと11_Skill.mdを読み、対象作業に必要な12〜19および工程文書だけを追加する。AI入口は04_Agent_Organization.mdを基礎コンテキストとして接続するが、同文書を読むことから調整役、別プロバイダー、複数エージェント、委譲または追加レビューを発火させない。単一エージェントで成立する作業には、不要な編成を追加しない境界を適用する。人間は作業開始のたびに全基礎正本を再読する必要はない。AI入口ファイルはこれらの正本を複製せず、現在の対象範囲、対象改訂版、対象工程、正本コンテキスト、決定権限、停止条件へ接続する。
4.2. プロダクト・変更・ロードマップ・学びをつなぐ経路
CRDDのプロダクト変換、変更、ロードマップ、リリース、学びの関係は次のとおりである。
根拠・要望・法改正・不具合・運用結果・監査結果・学び
│
未整理・未採用の入力か
┌───────┴───────┐
はい いいえ
│ │
今すぐ分析するか 分類済み・採用済みの契機
┌───┴────┐ │
する 今は保持する │
│ │ │
│ 21 課題探索・要求形成内の
│ 任意の候補保持 │
│ │ │
│ 99_Roadmap 登録簿へ
│ 存在・判断状態を登録
│ │ │
│ 再検討契機 / 人間による選択
│ │ │
21 課題探索・要求形成 │
├─ 追加調査 │
│ / 調査へ戻る │
└──────────┬────────────┘
↓
人間による経路判断
├─ 採用しない → 判断 / 対応なし → 登録簿を終了へ
├─ 採用 + 延期
│ ↓
│ 99_Roadmap 登録簿の主要表示
│ └─ 詳細（必要時）
│ ↓
│ 着手条件 / 再評価契機
│ ↓
│ 人間による着手判断
│ ├─ 再延期 → 主要 / 契機更新
│ ├─ 取消 → 判断 / 判断理由
│ └─ 着手 ─────────────────────┐
└─ 今回実施 ─────────────────────┤
↓
必要な変更トレース（CHG-*）
│
必要な工程を開始または再開
↓
22 UX → 23 IA → 24 UI・振る舞い仕様の共有契約
┌──────────┴──────────┐
↓ ↓
25 UI ⇄ 26 振る舞い仕様
└──────────┬──────────┘
↓
27 アーキテクチャ
↓
28 実装
↓
29 検証
↓
07_Quality / Quality Center
現在の品質状態・計画対実績・差異理由を表示
┌───────────────────────┼──────────────────────┐
未達・新たな不足 準備完了 / Conditional 学び
│ │ │
該当工程 / CHGへ戻る リリースが必要か 責務を持つ
┌──┴──┐ 正本コンテキストへ
いいえ はい │
│ │ 必要なら課題探索・要求形成 /
│ 人間による ロードマップ / CHG
│ リリース判断
│ ↓
│ 13 / 90_Release
└──┬──┘
↓
詳細固有情報を正本・CHG・結果へ移管
↓
ロードマップ起点なら終了結果と参照を反映
↓
参照の有効性を確認
↓
完了項目を主要表示から除去
↓
詳細ファイルを使用した場合は削除
図の工程列は基本的な意味変換順を示す。すべての変更が全工程を通る意味ではなく、承認済みコンテキストと影響に応じて最も近い必要工程から開始または再開する。UIと振る舞い仕様は並行・反復し、リリースは必要なプロジェクトだけが使用する。
任意の候補保持は、未整理・未採用の入力を後から再検討できるようにする01_Discovery内の表示であり、新しい工程ではない。候補保持を使わず、その場で分析、却下または分類してよい。明確な不具合、期限対応、採用済みロードマップ項目、是正決定等の分類済み・採用済みの契機を、未採用候補へ戻して先送りしない。候補として保持しただけでは、要求の採用、変更または実行の許可にならない。現在の対象範囲に関係しない候補は工程完了を妨げず、通常は全候補を一括確認しない。
99_Roadmapは、採用済みで延期した作業だけでなく、未完了のアイデア、課題、不具合、技術負債、移行、未解決の監査指摘、進行中の変更トレースを横断して確認できる登録簿である。登録簿は索引であり、意味、根拠、判断理由、確定結果は責務を持つ正本成果物へ残す。登録簿へ登録されていることは、採用、優先順位の確定、実行の許可を意味しない。登録対象、登録義務、判断状態と対応状態、完了時の除去は課題探索・要求形成を正本とする。
任意の工程: 人間による判断 / 制約 / 学び / 根拠 / 指摘事項
↓
変更影響の伝播確認
↙ 逆方向 同層方向 ↘
上流の未決事項 同層コンテキスト / 対
不足 / 仮定 競合 / 義務
↘ ↙
正本成果物の是正
↓
下流影響の再探索 / 再検証
↓
現在の工程を継続、または工程移行レビュー
この図は、固定ウォーターフォールやプロジェクト全体の一括状態を表さない。機能、ユースケース、変更、リリース等の対象範囲ごとに、反復、並行、上流工程の再開、技術検証、部分引き渡しを行ってよい。
ただし、成果物の一部が完成したことやスキル実行の終了だけから、工程完了を推定してはならない。
- 下流で新しい判断、制約、学び、根拠、指摘事項が確定した場合は、変更影響の伝播確認を行う
- 上流・同層の未決事項、不足、仮定、判断、制約への影響を探索する
- 必要な正本更新と再監査を完了する
- 通常の工程移行前には、送信側の出口と受信側の入口に加え、送信工程または対象共有契約が所有する網羅範囲と監査チェックリストに照らした専門品質を、対象改訂版に対して独立レビューする
- 指摘事項は責務を持つ工程で修正し、更新改訂版を再レビューする
次へ進めるのは、対象範囲の責務の網羅、変更影響の伝播確認、レビューのPassを満たした場合である。未解決事項を残して進む場合は、人間の決定権限が未解決事項、リスク、担当責任者、再開条件、適用する例外を明示的に承認する。
4.3. 横断経路
| 用途 | 経路 |
|---|---|
| 未採用で今は分析しない入力を、再検討可能な形で保持する | 課題探索・要求形成の任意の候補保持を必要な場合だけ使用する |
| 変更契機から影響・実装・検証・終了を追跡する | 変更に従い、必要なCHG-*を90_Release/Changes/へ置く |
| リポジトリ固有の反復作業を定義する | 作業手順に従い、19_Workflowsへ置く |
| 開発方式を問わず進捗と健全性を把握する | 進捗管理に従い、ライフサイクル単位ごとに対応状態、責務別進捗、根拠を取得可能にする |
| 品質保証の計画、実績、現在状態を横断して把握する | 品質保証に従い、各工程の検証義務と検証設計を育て、07_Quality/01_Quality_Center.mdから現在状態と詳細参照へ到達できるようにする。外部ツールを使っても品質保証記録はリポジトリ内で理解・再確認できるようにする。単体試験が適用される場合は分岐網羅率100%を既定目標とし、未達または除外の理由と残るリスクを明示する |
| 検証済み改訂版を配布・有効化する | 検証のリリース準備状況の推奨をプロジェクト固有リリース決定権限へ渡し、必要な場合だけリリースに従う |
| 未完了の作業、課題、アイデア、是正事項を横断して把握する | 課題探索・要求形成の未完了作業の登録簿に従い、存在、現在状態、参照先を99_Roadmapへ置く |
| 文書品質を監査する | 文書監査 |
| CRDD準拠を評価する | 準拠監査 |
| 監査またはレビューで合意した修正を、参照、ひな型、例示等へ漏れなく反映し、解消を確認する | エージェントの複数箇所へ及ぶ是正対象の列挙と照合に従い、元の指摘事項の意味を保持し、契約母集団と利用側母集団、処置進捗、阻害状態、解消判定を分ける。適用後は受入条件、合否判定方法、各利用側の新しい根拠、同じ固定改訂版の独立再レビュー、現在状態への伝播を確認する。局所修正で同じ原因が再発する場合は構造是正へ戻す |
| 採用プロジェクトでCRDD基準版の差分を評価し、有効化を判断する | 保守の基準版採用評価 |
| 人間の判断、制約、学び、根拠、指摘事項の確定・変更を上流／同層へ伝播する | 不足／影響監査の変更影響の伝播確認を即時実行し、正本更新後に再監査する |
| その他の変更について工程横断影響を調べる | 不足／影響監査 |
| 工程移行前に契約と、工程または対象共有契約固有の専門品質を独立レビューし、指摘事項を修正・再確認する | エージェントの工程移行レビュー、送信・受信工程の工程実行契約、対象共有契約 |
| CRDD標準自体を変更する | 保守 |
リリースは課題探索・要求形成から検証までと同じ設計工程ではない。検証の後に常に90_Releaseへ進むのではなく、配布・有効化を行うプロジェクトで必要な場合にだけ、人間によるリリース判断を経て使用する。
4.4. 変更時に選ぶ工程・レビュー・監査
次の表は、人間がAIの経路選択を短時間で確認するための案内である。新しい決定権限や監査条件を作るものではなく、各行の参照先を正本とする。一つの変更が複数行に該当する場合は必要な経路を組み合わせるが、該当しない監査を安全のためだけに追加しない。
| 変更の性質 | 主に確認・再開する範囲 | レビュー／監査の基本経路 |
|---|---|---|
| 誤字、表示、リンク、アンカー等で意味を変えない | 対象文書と直接参照 | 機械確認と必要な文書監査 |
| 一つの工程が所有する意味、成果物または出口を変える | 所有工程、直接の入力元・引き渡し先 | 対象工程の専門観点を含む独立レビュー。文書上の追従は文書監査 |
| 複数工程、共有契約、正本または利用側へ影響する | 影響候補となる工程・成果物・接続部 | 不足／影響監査 |
| 判断、制約、学び、根拠または指摘事項を確定・変更する | 上流、同層、下流の関係先 | 変更影響の伝播確認 |
| 決定権限、安定コンテキストID、工程契約または固定構造を変える | 所有する正本文書と全利用先 | 独立レビュー、文書監査、不足／影響監査。準拠へ影響する場合は準拠監査 |
| CRDD準拠表明または適用基準を評価する | 適用する中核／プロファイルと根拠 | 準拠監査 |
| 採用中のCRDD基準版を変更する | 途中リリースを含む差分とプロジェクト固有接続部 | 基準版採用評価から必要な監査・移行だけを選ぶ |
| 実装詳細だけを変え、上流の意味や契約を変えない | 実装、影響する検証、根拠 | 技術・品質リスクに応じたレビューと検証。工程横断監査を自動追加しない |
| 検証済み結果を配布・有効化する | 現在の品質状態、残存リスク、対象リリース | リリース準備状況の推奨と、人間のリリース判断 |
非自明か軽微かは、担当者またはAIの自己申告、変更行数、使用モデルだけで決めない。意味、決定権限、条件、正式結果、利用側、移行または重大リスクへの影響を差分と正本から確認し、分類と実差分が一致しない場合は影響の大きい経路へ戻す。操作条件、4種類の代表例、固定前の照合および省略境界は、着手前整合確認を正本とする。
AIは作業開始時または経路が変わった時に、少なくとも次を人間が確認できる形で示す。
変更分類
確認・再開する工程または共通責務
着手前整合確認の要否と、必要な専門観点
実行する独立レビューと監査
実行しない主な監査と理由
人間の判断が必要な点
非自明な変更では、この表示を変更トレースまたは同等の既存記録から後で確認できるようにする。計画時は、選んだ主な工程・共通責務、選択理由、予定する検証、および判断上重要だが選ばなかった主な経路と理由を示す。すべての工程や監査の非選択理由を列挙する必要はない。
完了時は、実際に通った経路、計画との差、追加または削除した工程・検証、その理由、経路不足から生じた指摘事項、および最終的に有効だった検証を取得可能にする。計画と実績が異なること自体を失敗とせず、差を説明できないこと、または必要な処置を追跡できないことを未完了として扱う。新しい経路専用のデータベース、登録簿または自動経路決定機構は要求しない。
非自明な変更では、表示した計画をそのまま初回編集へ移さず、着手前整合確認に従って現在の正本、直接参照、派生物、AI入口、変更しない意味・決定権限・互換性と照合する。軽微な変更へ確認者や承認を機械的に増やさず、同節の委譲条件に該当する場合だけ、不足する専門観点を読み取り専用の確認者へ渡す。