ギャップ診断：現体系の網羅性スコアリング
診断方法
各領域を以下の4段階でスコアリングする： - A（90-100点）：非エンジニアが単独で使える。具体的なテンプレート・手順・判断基準が揃っている - B（70-89点）：概念は説明されているが、具体的な手順・テンプレートが不足している - C（50-69点）：言及はあるが、素人が実際に使うには説明が不十分 - D（0-49点）：未対応または根本的に欠落している
1. 要件定義書の完全性
現状
world_class_requirements_template.md：IEEE/ISO/IEC 29148-2018準拠のテンプレートあり- 機能要件・非機能要件・制約・対象外の整理フレームワークあり
- Evidence Matrix（根拠管理）の概念あり
評価：B（75点）
強み： - テンプレートの構造は世界標準に準拠している - 「逆順アプローチ」（テンプレートを先に作り、それを埋めるリサーチ）は有効
弱み（ギャップ）： - テンプレートの「埋め方」の具体例が不足している - 非エンジニアが「機能要件とは何か」を理解できるかが不明 - Substack自動化のような具体的なユースケースでの記入例がない - 「要件定義書が完成した」と判断する基準が不明確
補完が必要な項目： - 記入例付きの要件定義書サンプル（Substack自動化版） - 「この項目が空欄のままでは次に進めない」という必須項目の明示 - 完成判定チェックリスト
2. SDD（詳細設計書）の完全性
現状
requirements_definition_master_structure_plan.md：統合構成案あり- SDDの概念（モジュール・データ構造・エラー処理・実装手順）は言及あり
評価：C（55点）
強み： - SDDが必要であることは説明されている - 「Claude Codeが迷わず実装できる状態にする」という目的は明確
弱み（ギャップ）： - SDDのテンプレートが存在しない（要件定義書テンプレートはあるが、SDDテンプレートがない） - 「Explore→Plan→Implement→Commit」の4フェーズが組み込まれていない - Spec-Driven Development（SDD）の3レベル（Spec-First/Spec-Anchored/Spec-as-Source）が未定義 - 非エンジニアが「SDDをどう書くか」を理解できない
補完が必要な項目： - SDDテンプレート（非エンジニア向け記入例付き） - 4フェーズワークフロー（Explore→Plan→Implement→Commit）の明示 - Spec-First（最低限）の実践手順
3. ハーネス設計の完全性
現状
harness_engineering_strengthened_proposal.md：walkinglabs全12講義精読後の提案書あり- CLAUDE.md + CONSTRAINTS.md + progress.mdの3ファイル体系あり
- Feature List（IN SCOPE/OUT OF SCOPE/DEFER）の概念あり
評価：B（72点）
強み： - walkinglabs基準でのギャップ分析が完了している - CONSTRAINTS.mdの必要性が明確に説明されている - Feature Listの3分類が定義されている
弱み（ギャップ）： - CLAUDE.mdの「具体的な書き方テンプレート」が不足している - CLAUDE.mdの「200行以内・削除基準」が具体的でない - CONSTRAINTS.mdの「禁止事項の書き方テンプレート」がない - 「コンテキスト使用量の可視化」方法が素人向けに説明されていない - CLAUDE.md階層化（docs/harness/配下への分割）の具体的な実装方法が不明
補完が必要な項目： - CLAUDE.md記入テンプレート（Substack自動化版の具体例付き） - CONSTRAINTS.md記入テンプレート（禁止事項の書き方例付き） - コンテキスト管理の実践的な方法（素人向け）
4. テスト計画の完全性
現状
universal_e2e_test_guide.md：汎用E2Eテスト完全ガイドありe2e_scenario_creation_prompt_template.md：書き換え5箇所のみのテンプレートあり- 正常系・異常系・境界系シナリオ設計の概念あり
- GitHub Actions CI/CD実装ガイドあり
評価：B（78点）
強み： - E2Eテストの概念・重要性・手順が説明されている - テンプレートで「書き換え5箇所のみ」という素人配慮がある - GitHub ActionsによるCI/CDが設計されている
弱み（ギャップ）： - 「境界ケース」の発見方法が素人には難しい（仮想テストで発見した問題） - 「テストが通った≠完成」という認識ギャップへの対策が不足 - 本番環境での動作確認手順が不明確 - 「このシステムで必ず確認すべき境界ケースリスト」が汎用的に提供されていない
補完が必要な項目： - 境界ケース発見チェックリスト（永続性・認証・文字コード・タイムゾーン等） - 「完了」の定義の明確化（テスト通過≠完成の説明） - 本番移行前の動作確認手順
5. セキュリティ対策の完全性
現状
complete_risk_destruction_prevention_guide.md：リスク対策ガイドあり- 3大抜け穴（コンテキスト枯渇・コスト管理・完了誤認）の対策あり
- 非エンジニア向け「これだけ守れば壊れない」5ルールあり
評価：C（58点）
強み： - 主要なリスクは特定されている - 5ルールは素人向けに分かりやすく整理されている
弱み（ギャップ）： - AI生成コードの45%がセキュリティ脆弱性を含むという事実への対策が不足 - 認証・認可・暗号化の具体的なチェックリストがない - .envファイル管理・シークレット管理の具体的な手順がない - SQLインジェクション・XSS等の基本的な脆弱性チェックが未言及 - 「プロトタイプ→本番」移行時のセキュリティ強化手順がない
補完が必要な項目： - セキュリティチェックリスト（非エンジニア向け・具体的） - シークレット管理の実践手順（.env, GitHub Secrets等） - 本番移行前のセキュリティ確認項目
6. 本番移行計画の完全性
現状
- 本番移行に関する専用ドキュメントが存在しない
- 「プロトタイプ≠製品」という概念は言及されているが、移行手順がない
評価：D（30点）
強み： - 「プロトタイプ≠製品」という認識は存在する
弱み（ギャップ）： - 本番移行チェックリストが存在しない - 認証・データセキュリティ・信頼性・統合の具体的な移行手順がない - cronジョブ・永続化・バックアップの設計が未言及 - 監視・アラート・ログ管理の設計が未言及 - 「本番稼働後に何を監視するか」が不明
補完が必要な項目： - 本番移行チェックリスト（認証・セキュリティ・信頼性・監視） - 本番環境設計テンプレート - 運用・監視の基本設計
7. 非エンジニア操作性の完全性
現状
- 全ドキュメントが日本語で書かれている
- 「これだけ守れば壊れない」5ルールがある
- RYGゲートで専門判断を赤黄緑に変換している
評価：B（70点）
強み： - 日本語対応・素人向け配慮がある - 判断基準の単純化（RYGゲート）がある
弱み（ギャップ）： - 「Claude Codeのインストール方法」等の初期設定手順がない - 「最初に何をするか」の具体的なスタートガイドがない - コスト管理の具体的な方法（月額予算の設定等）が不明 - エラーメッセージへの対処方法が不明 - 「詰まったときにどうするか」のエスカレーション手順がない
補完が必要な項目： - 初心者向けスタートガイド（ゼロから始める手順） - コスト管理の具体的な方法 - よくあるエラーと対処法
総合スコアサマリー
| 領域 | スコア | 評価 | 最重要ギャップ |
|---|---|---|---|
| 要件定義書の完全性 | 75点 | B | 記入例・完成判定基準の不足 |
| SDD（詳細設計書）の完全性 | 55点 | C | SDDテンプレートの欠如 |
| ハーネス設計の完全性 | 72点 | B | CLAUDE.md具体的書き方の不足 |
| テスト計画の完全性 | 78点 | B | 境界ケース発見・完了定義の不足 |
| セキュリティ対策の完全性 | 58点 | C | 具体的チェックリストの欠如 |
| 本番移行計画の完全性 | 30点 | D | 専用ドキュメントの欠如 |
| 非エンジニア操作性の完全性 | 70点 | B | スタートガイドの欠如 |
| 総合平均 | 63点 | C+ | 本番移行・セキュリティ・SDDが最弱点 |
優先度別ギャップリスト
優先度1（緊急・致命的）
- 本番移行チェックリストの欠如：プロトタイプが本番で動かない最大の原因
- SDDテンプレートの欠如：Claude Codeが迷わず実装できる状態を作れない
- セキュリティチェックリストの欠如：45%のコードに脆弱性という統計的リスク
優先度2（重要・影響大）
- CLAUDE.md具体的書き方テンプレートの欠如：コンテキスト枯渇の直接原因
- 境界ケース発見チェックリストの欠如：「完了誤認」の主要原因
- スタートガイドの欠如：素人が最初の一歩を踏み出せない
優先度3（改善・品質向上）
- Explore→Plan→Implement→Commitの4フェーズ未組み込み
- Spec-Anchored（仕様の継続維持）の仕組みの欠如
- コスト管理の具体的方法の欠如
- よくあるエラーと対処法の欠如
結論：現体系は「完璧」か？
答え：NO。現体系は63点（C+）であり、「完璧」とは言えない。
特に以下の3点が致命的： 1. 本番移行計画が存在しない（30点/D）：プロトタイプを作れても、本番で動かすための知識がない 2. SDDテンプレートが存在しない（55点/C）：Claude Codeへの指示が曖昧になる 3. セキュリティ対策が具体的でない（58点/C）：AI生成コードの45%に脆弱性という現実への対策がない
ただし、骨格は正しい。CLAUDE.md + CONSTRAINTS.md + progress.md + RYGゲート + E2Eテストという体系は、世界最高水準の設計原則（Claude Code公式、SDD論文、walkinglabs）と整合している。
必要なのは「骨格の強化」ではなく「肉付け」である。 特に、非エンジニアが実際に使える「具体的なテンプレート・記入例・チェックリスト」の充実が最優先課題である。