---
name: requirements-definition-gate
description: "受託開発の要件定義資料を横断レビューし、抜け漏れ、曖昧さ、矛盾、未決事項、見積前提、スコープ境界、非機能要件、外部連携リスクを抽出する。要件定義レビュー、見積提出前、基本設計着手前のゲート判定で使用する。"
---

# Requirements Definition Gate（要件定義ゲートレビュー）

## Codex / VS Code での利用

| 項目 | 内容 |
| --- | --- |
| 配置（本スキル） | `.agents/skills\requirements-definition-gate\` |
| 明示的呼び出し | チャットで `$requirements-definition-gate` またはスキルピッカーから選択 |
| 常時コンテキスト | リポジトリ直下 `AGENTS.md` |
| 利用説明書 | `documents/要件定義ゲートスキル_Codex利用説明書.md` |
| Cursor 版 | 同一内容は `.cursor/skills/` にも配置（どちらか一方で可） |

スクリプト例: `python .agents/skills/requirements-definition-gate/scripts/scan_ambiguous_words.py reference/`

## 目的

受託開発の要件定義・見積前提・責任境界・変更管理・設計着手判定を標準化する。

**AIの役割は最終判断の代行ではない。** 次に限定する。

1. 抜け漏れの検出
2. 曖昧さ・矛盾の可視化
3. 依頼者側確認事項とベンダ検討事項の分離
4. 見積・設計・テスト・契約への影響整理
5. 人間が判断すべき差分の優先順位付き提示

複数資料の意味逸脱監査は **`requirements-semantic-drift-audit`** を別途使用する（議事録↔要件一覧、要件定義↔設計書など）。

## 基本制約

- 根拠のない仕様を確定しない（推測で `ACCEPTED` にしない）
- 不足時は [references/review-statuses.md](references/review-statuses.md) のラベルで明示
- 外部ツールは必須にしない（Markdown / CSV / Git / Python標準のみ）
- 製造・BOM案件は [references/domain-addons/manufacturing-bom.md](references/domain-addons/manufacturing-bom.md) を必要時のみ参照

## レビューモード

依頼または資料の成熟度に応じてモードを選ぶ。未指定時は資料から推定し、冒頭で宣言する。

### MODE-A: PRE-ESTIMATE

見積提出前の簡易レビュー。短時間で重大な見積リスクを優先する。

**優先対象:** 対象範囲、対象外、外部連携、利用者数、データ件数、移行対象、非機能要件、依頼者側側タスク、見積前提、工数変動要因、別途見積条件

### MODE-B: REQUIREMENTS-REVIEW

要件定義書と関連資料の網羅レビュー。

**優先対象:** 背景・目的・KPI・受入、業務フロー、用語、ステークホルダー、機能、データ、画面/帳票/バッチ/通知、正常/例外/異常/復旧、外部連携、非機能、移行、運用保守、教育・マニュアル、権限、セキュリティ、責任境界、変更管理、成果物反映先

### MODE-C: PRE-DESIGN-GATE

基本設計・外部設計着手直前。

**優先対象:** 設計開始を妨げる未決、仕様矛盾、未定義業務ルール、データ項目不足、IF仕様不足、例外挙動、権限・監査ログ、移行方式、受入条件、責任境界、変更管理、トレーサビリティ、ゲート判定

### MODE-D: CHANGE-IMPACT

仕様変更・追加要望の影響分析。

**優先対象:** 当初要件との差分、スコープ増減、設計/データ/IF/テスト/移行/WBS/費用納期/契約/依頼者側作業への影響。必要なら `requirements-semantic-drift-audit` と併用。

## レビュー手順

1. **入力資料の一覧化**（版・日付・状態）。不足は「不足資料」として記録し、レビュー中止にはしない。
2. **モードに沿った観点チェック** — [references/review-catalog.md](references/review-catalog.md)
3. **曖昧語検出**（任意）— `python scripts/scan_ambiguous_words.py <paths>`
4. **指摘の分類・重要度付与**（下表）
5. **テンプレート順で出力**（下記「出力形式」）
6. **ゲート判定** — BLOCKER 残存時は原則 GO 不可

### プロジェクト固有（プロジェクト 等）

- [references/project-baseline.md](references/project-baseline.md)

## 参照ドキュメント

| ファイル | 用途 |
| --- | --- |
| [review-catalog.md](references/review-catalog.md) | 観点 RQ-01〜14 |
| [review-statuses.md](references/review-statuses.md) | 合意・情報の状態 |
| [ambiguity-dictionary.md](references/ambiguity-dictionary.md) | 曖昧語と確認質問 |
| [non-functional-baseline.md](references/non-functional-baseline.md) | 非機能確認（数値は推測しない） |
| [estimate-assumptions.md](references/estimate-assumptions.md) | 見積前提の整理 |
| [change-management.md](references/change-management.md) | 変更・契約境界 |
| [deliverable-map.md](references/deliverable-map.md) | 成果物への反映 |

## 指摘分類

| 分類 | 意味 |
| --- | --- |
| `MISSING` | 必要な記載がない |
| `AMBIGUOUS` | 複数解釈が可能 |
| `CONTRADICTION` | 資料間または記載内で矛盾 |
| `UNCONFIRMED` | 記載はあるが合意状態が不明 |
| `ASSUMPTION` | 見積または設計上の仮定 |
| `SCOPE-RISK` | 対象範囲の認識差 |
| `ESTIMATE-RISK` | 工数・費用・納期へ影響 |
| `DESIGN-RISK` | 設計開始後の手戻り |
| `OPERATION-RISK` | 運用開始後の障害 |
| `CONTRACT-RISK` | 契約・責任境界 |
| `TRACEABILITY-RISK` | 成果物への反映先不明 |
| `DRIFT-RISK` | 元資料から意味変化の疑い（逸脱監査へ） |

## 重要度

| 重要度 | 基準 |
| --- | --- |
| `BLOCKER` | 見積確定・契約・設計開始が危険 |
| `HIGH` | 工数・費用・納期・品質へ大きく影響 |
| `MEDIUM` | 後工程で手戻りの可能性 |
| `LOW` | 表記統一・軽微確認・改善提案 |

## 出力形式

レビュー結果は **次の順序・ファイル名** で出力する（`templates/` を雛形とする）。

```text
01_executive-summary.md
02_findings.md
03_open-questions.md
04_estimate-assumptions.md
05_scope-boundaries.md
06_risk-register.csv
07_traceability-matrix.csv
08_gate-decision.md
```

出力先はユーザー指定がなければ `output/requirements-gate/<YYYYMMDD>/` 等、案件フォルダ配下とする。

### ゲート判定（08）

| 判定 | 意味 |
| --- | --- |
| `GO` | 次工程へ進める |
| `CONDITIONAL-GO` | 条件・担当・期限を明示して進める |
| `NO-GO` | 重大な未決・矛盾・責任境界欠落があり進めない |

## 補助スクリプト

```bash
# 曖昧語スキャン（Codex / VS Code 配置）
python .agents/skills/requirements-definition-gate/scripts/scan_ambiguous_words.py path/to/docs

# トレーサビリティ検証
python .agents/skills/requirements-definition-gate/scripts/validate_traceability.py 07_traceability-matrix.csv
```

## 禁止事項

- 見積前提を合意済み要件へ昇格しない
- `GENERATED` / `VENDOR-PROPOSED` を確定仕様として扱わない
- 未決を自然な文章で隠さない
- 矛盾する複数案を勝手に統合しない
- 正常系のみでレビュー完了にしない
- 対象外・別途見積を曖昧にしない
- 依頼者側作業をベンダ作業へ勝手に移さない

## 利用例

### 見積前レビュー

```text
この案件資料を MODE-A: PRE-ESTIMATE でレビューしてください。
重大な見積リスク、依頼者側への追加質問、見積前提、対象外範囲、別途見積条件を整理してください。
推測で仕様を補完しないでください。
```

### 要件定義書レビュー

```text
議事録、要件定義書、画面一覧、IF一覧を MODE-B: REQUIREMENTS-REVIEW で横断レビューしてください。
抜け漏れ、曖昧語、矛盾、例外系、非機能要件、責任境界、成果物への反映漏れを整理してください。
```

### 基本設計着手判定

```text
現在の資料を MODE-C: PRE-DESIGN-GATE でレビューしてください。
BLOCKERとHIGHを優先して示し、GO、CONDITIONAL-GO、NO-GOのいずれかを判定してください。
```

### 仕様変更影響分析

```text
初期要件、前回承認版、今回の変更依頼を比較してください。
MODE-D: CHANGE-IMPACT と requirements-semantic-drift-audit を併用し、スコープ、見積、納期、設計、テスト、移行、責任境界への影響を整理してください。
```

### 意味逸脱監査（別スキル）

```text
議事録と要件一覧を比較し、requirements-semantic-drift-audit を実行してください。
候補が採用へ変わった箇所、見積前提が確定仕様へ変わった箇所、責任主体の変化、条件や例外の削除、矛盾の平準化を重点的に確認してください。
LEVEL-2以上を drift-candidates.md に整理してください。
```

## 将来拡張（任意・非必須）

- Kotonoha Console / Obsidian 連携
- 外部APIによる課題起票

初期版では導入を必須としない。