---
name: requirement-convergence
description: 変更が生むべき成果と、そこへ至るために提案された要件を切り分け、ユーザーが除外したものを記録し、構造からコストをおおまかな区分で見積もる。要件がワークフローに入った時点、設計を始める前、または「どこまでやるか/スコープ外は何か/やる価値があるか」が言及された時に使用。
---

# 要件収束

## 目的

要件は、膨らんだ状態、曖昧な状態、狙う成果を外した状態で届く。能力の高いモデルはその3つをまとめて筋の通った計画に組み直し、忠実に作り上げてしまう — 求められたものが間違っていたときに、求められたとおりのものを届けることになる。

このスキルは**何を作るか**を収束させる。どう作るか、そして変更にどのドキュメントが必要かは、何を作るかが決まった後に定める。

## 収束フィールド

| フィールド | 通過条件 |
|-----------|---------|
| `outcome` | 観測可能な結果が1つ。それに寄与しない要件は不要である。 |
| `requirements[]` | 作る対象に関わる各項目に `current-state` または `desired-future` のラベルが付いている。 |
| `nonGoals[]` | ユーザーが挙げたもの。または、除外すべきものはないとユーザーが述べたこと。 |
| `cost` | 区分1つと、それを決めた構造上の根拠、および残っている不明点。 |

`cost` はおおまかな区分であり、作業計画書がスケジュールの根拠にする工数見積ではない — 要件の段階では人日を裏付けられない。残っている不明点は、規模そのものよりも判断に影響する。

分類は、アナライザが言い換えたものではなく、保持しているユーザー自身の文言から行う。評価を求める文言、推測的なアイデアを述べる文言、実装手段を提案する文言は、収束中は判断のための候補としてのみ扱う。`requirements[]` や後続作業で参照されるドキュメントに入れるのは、ユーザーが明示的に採用したものだけとする。

各フィールドは自身の readiness ラベルを持つ: `ready`、`weak`、`weak-but-explicit`（weak だが、未解決のまま残すことにユーザーが同意した状態）。`weak-but-explicit` を設定できるのはユーザーだけである。該当する全フィールドが `ready` または `weak-but-explicit` になった時点で、要件は収束したとみなす。

フィールドごとの判断ルール: [references/criteria.md](references/criteria.md)。

## ヒアリングプロトコル

利用可能なスコープとコストのエビデンスを、聞き出す作業と判定の両方に用いる。質問するのは、リポジトリからは答えられないプロダクト上の選択だけとする。スコープとコストを再分析するのは、回答が分析対象または必要なスコープエビデンスを変える場合に限る。

開始前に以下のステップを登録し、完了ごとにその根拠を記録する:

| ステップ | 行うこと | 完了の根拠 |
|---------|---------|-----------|
| 1 | 下記のスコープ確認を提示し、`ready` に達していないフィールドについてだけ質問する | 各事実に出所となる分析結果が付き、**ユーザーの判断事項** に `ready` に達していないフィールドごとの質問が1問ずつある |
| 2 | 各回答をそのフィールドの値として記録する | 値が、ユーザーが明示的に選んだ選択肢、またはユーザー自身が述べた言い回しになっている |
| 3 | 記録した値がまだ通過条件を満たさない場合は1度だけ聞き直し、2度目の回答のままでよいとユーザーが同意した時点でそのフィールドを `weak-but-explicit` とする | 記録された回答が2つ、またはそこで止めることへのユーザーの同意 |
| 4 | 各フィールドを通過条件に照らして判定し、記録を完成させる | 全フィールドにラベルが付いた収束記録 |

## スコープ確認

要件を確認する停止点では、ヒアリングを行ったかどうかにかかわらず、次の形で提示する。含めるのは、ユーザーの要件判断を変えうる内容だけとする。

| セクション | 内容 |
|-----------|------|
| **確定したスコープ** | ユーザーが既に述べた、または明示的に選んだ要件と対象外。ユーザー自身の言い回し、または選んだ選択肢で示す |
| **判断材料** | 重要な項目ごとに、観測・推定・提案のいずれかを示し、その出所と、スコープ・成果・コストの何を変えうるかを添える。コストの区分と残っている不明点を含む |
| **ユーザーの判断事項** | 未解決のプロダクト・UX・運用上の問いと、実質的に異なる回答ごとのスコープ・成果・コストへの影響 |

これらを分けておくことで、ユーザーは、自分が既に決めた境界、リポジトリで観測された事実、まだ決まっていない問いを見分けられる。**確定したスコープ** へ移せるのは、ユーザーが明示的に答えた、または選んだ項目だけである。構造スケールのような呼び出し元ワークフロー固有の進め方に関する項目は、これらのセクションとは分け、それを提示する停止点でだけ示す。

## 保存プロトコル

| 保持先 | 保持する内容 |
|-------|------------|
| 現在の収束記録 | 全フィールドとその readiness ラベル |
| PRD の `成功基準` と `Out of Scope` | `outcome`、およびユーザーが挙げた `nonGoals` |
| Design Doc の `Requirement Convergence` | PRD がない場合は上と同じ内容。加えて `weak-but-explicit` のまま残ったフィールドは常にここへ記録する |

どちらのドキュメントも生成しない場合は、現在のコンテキストに記録を保持する。

## 参照プロトコル

1. プロンプトから収束記録を読む。
2. `nonGoals` は今回の変更から除外し、`desired-future` 要件を作る対象として扱う。採用されていない評価依頼、推測的なアイデア、指定された実装手段、エージェントが提案した機能は実装作業を生まない。評価した選択肢を判断の履歴として残せるのは、承認済みADRがそれを扱う場合だけである。
3. `weak-but-explicit` のフィールドは、確定した判断ではなく記録された未解決の論点として扱い、作業がその解決に依存する場合はエスカレーションする。

## 品質チェックリスト

- [ ] 質問の前に、スコープ確認で確定したスコープ・判断材料・ユーザーの判断事項を分けて提示した
- [ ] `nonGoals` がユーザーから出たもの、または除外すべきものはないとユーザーが述べたものになっている
- [ ] 該当する全フィールドが `ready`、またはユーザーの同意による `weak-but-explicit` になっている

## References

- [references/criteria.md](references/criteria.md) — フィールドごとの判断ルール、コストの入力、チャレンジの強度、手段すり替えの検出