公式スキル · プロダクト

作りはじめる前の仕様書レビュー

v1.0.1・2026年11月4日更新

作りはじめる前に PRD や仕様書をレビューする。あいまいさ、空・読み込み中・エラー・権限なしの抜け、指標、段階リリース、はじめて使う人としての流れ。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• PRD や仕様書がエンジニアの見積もりに回る直前
• 出した機能で想定外のことが起き、次の仕様書を厳しめに見たいとき

AI に渡すもの

• 仕様書か PRD の本文
• 対象の利用者（なくてもよい）
• 期限とチーム（なくてもよい）

できあがるもの

判定、はじめて使う人としてたどった流れ、引用つきの止まる問題と直したほうがよい点、状態の表、指標とリリースの確認。

手順

1. はじめて使う人として流れをたどる 利用者がたどり着くところ（メールのリンク、メニューの項目、何もないアカウント）から始め、各ステップを言葉にする。何が見えるか、何を決めなければならないか、何をクリックするか。次に何が表示されるかを仕様書が書いていないところは、抜けとして記録する。ラベルや質問が新しい人を迷わせそうなところも記録する。
2. すべての画面の状態を確かめる 画面やコンポーネントごとに、空（はじめての利用、結果なし）、読み込み中、エラー、データの一部だけ、権限なし、成功を探す。NN/g は、空の状態ではシステムの状態を示し、始め方を教え、作業へのまっすぐな道を示すこと、データを読み込んでいる最中に「データがありません」を出さないことを勧めている。エラーメッセージは、目に入り、わかりやすい言葉で、次にどうすればよいかがわかり、利用者の入力を消さないようにする。
3. あいまいな言葉を見つける 「速い」「簡単」「シンプル」「直感的」「〜すべき」「など」「および/または」「いくつか」「必要に応じて」に印をつける。それぞれ、数字、一覧、決定が必要。2人の読み手が別々にテストしうる要件にも印をつける。
4. ルールと上限を確かめる だれがこれをできるか。いくつまでか。上限に達したら何が起きるか。リリースしたとき、既存のデータと利用者はどうなるか。答えがなく、それでデータモデルが変わるなら、止まる問題にする。
5. 指標を確かめる 課題に結びつく主指標が1つあり、現状の値、目標、測り方がなければならない。数えるべきイベントがまだないなら、それは仕様書に抜けている要件。
6. 段階リリースと切り戻しを確かめる フラグの裏で出すか。最初にだれが見るか（社内、一定の割合、特定のセグメント）。どの指標で切り戻すか、リリースし直さずに止められるか。Martin Fowler のフィーチャートグルの解説は、リリーストグル、割合を段階的に広げるリリース、キルスイッチを分けている。キルスイッチは、新しいリリースなしにすぐ切り替えられなければならない。
7. 重さの順に並べ、指摘を書く 止まる問題 = チームが作れない、テストできない、またはデータや信頼を損なうおそれがある。直したほうがよい = 手戻りや混乱を生む。細かい指摘 = 言い回し。どの指摘も仕様書を引用し、なぜ大事かを書き、直し方か質問を出す。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: spec-review
description: チームが作りはじめる前に、PRD、製品仕様書、機能の企画書をレビューする。あいまいな言い回し、抜けている状態（空、読み込み中、エラー、権限なし）、抜けている成功指標、抜けている段階リリースと切り戻しの計画を見つけ、はじめて使う人として流れを1ステップずつたどる。止まる問題と質問を重さの順に返す。PRD や仕様書を渡され、レビュー、内容の確認、フィードバック、抜け漏れの指摘、「このまま作りはじめていい？」を頼まれたときに使う。
---

# 仕様書のレビュー

仕様書ができあがったと言えるのは、エンジニア、デザイナー、テスターがそれぞれ読んで、同じものを作り、同じようにテストできるとき。レビューでは、3人の解釈が分かれるところと、だれも書いていない状態を探す。要件の一覧を読む前に、はじめて使う人として流れをたどる。抜けはたどる途中で見つかる。

## 使う場面

- PRD や仕様書をもとに、エンジニアが見積もる前、作りはじめる前。
- 仕様書が改訂され、もう一度見る必要があるとき。
- 出した機能で想定外のことが起き、次の仕様書を厳しめに見たいとき。
- メモから仕様書を書く作業には使わない（prd-from-notes を使う）。できあがった画面や文言のレビューにも使わない（landing-copy-review かデザインレビューを使う）。

## 用意するもの

- 仕様書か PRD の本文。モックアップの説明も含めて。
- 仕様書に書いていなければ、対象の利用者。わからなければ、説明を受けていないはじめての利用者としてレビューし、「[仮定]」と書く。
- あれば、期限とチーム。範囲が妥当かを判断できる。

## 手順

1. **はじめて使う人として流れをたどる。** 利用者がたどり着くところ（メールのリンク、メニューの項目、何もないアカウント）から始め、各ステップを言葉にする。何が見えるか、何を決めなければならないか、何をクリックするか。次に何が表示されるかを仕様書が書いていないところは、抜けとして記録する。ラベルや質問が新しい人を迷わせそうなところも記録する。
2. **すべての画面の状態を確かめる。** 画面やコンポーネントごとに、空（はじめての利用、結果なし）、読み込み中、エラー、データの一部だけ、権限なし、成功を探す。NN/g は、空の状態ではシステムの状態を示し、始め方を教え、作業へのまっすぐな道を示すこと、データを読み込んでいる最中に「データがありません」を出さないことを勧めている。エラーメッセージは、目に入り、わかりやすい言葉で、次にどうすればよいかがわかり、利用者の入力を消さないようにする。
3. **あいまいな言葉を見つける。** 「速い」「簡単」「シンプル」「直感的」「〜すべき」「など」「および/または」「いくつか」「必要に応じて」に印をつける。それぞれ、数字、一覧、決定が必要。2人の読み手が別々にテストしうる要件にも印をつける。
4. **ルールと上限を確かめる。** だれがこれをできるか。いくつまでか。上限に達したら何が起きるか。リリースしたとき、既存のデータと利用者はどうなるか。答えがなく、それでデータモデルが変わるなら、止まる問題にする。
5. **指標を確かめる。** 課題に結びつく主指標が1つあり、現状の値、目標、測り方がなければならない。数えるべきイベントがまだないなら、それは仕様書に抜けている要件。
6. **段階リリースと切り戻しを確かめる。** フラグの裏で出すか。最初にだれが見るか（社内、一定の割合、特定のセグメント）。どの指標で切り戻すか、リリースし直さずに止められるか。Martin Fowler のフィーチャートグルの解説は、リリーストグル、割合を段階的に広げるリリース、キルスイッチを分けている。キルスイッチは、新しいリリースなしにすぐ切り替えられなければならない。
7. **重さの順に並べ、指摘を書く。** 止まる問題 = チームが作れない、テストできない、またはデータや信頼を損なうおそれがある。直したほうがよい = 手戻りや混乱を生む。細かい指摘 = 言い回し。どの指摘も仕様書を引用し、なぜ大事かを書き、直し方か質問を出す。

## 出力の形式

```markdown
# 仕様書のレビュー: [仕様書の名前]

**判定:** [作れる / 止まる問題を直せば作れる / まだ作れない] — [理由を1文で]

## はじめて使う人としてたどった流れ
1. [ステップ: 利用者が見るもの、すること] — [抜けか「明確」]

## 止まる問題
| # | 仕様書の記述 | 問題 | 直し方か質問 |
|---|---|---|---|
| B1 | 「[引用]」 | [なぜ止まるか] | [提案] |

## 直したほうがよい
| # | 仕様書の記述 | 問題 | 直し方か質問 |
|---|---|---|---|

## 抜けている状態
| 画面 | 空 | 読み込み中 | エラー | 権限なし | メモ |
|---|---|---|---|---|---|
| [画面] | [あり / 抜け] | ... | ... | ... | [メモ] |

## 指標とリリース
- 主指標: [あり / 抜け] — [メモ]
- 段階リリース: [あり / 抜け] — [メモ]
- 切り戻しの条件とキルスイッチ: [あり / 抜け] — [メモ]

## 細かい指摘
- [言い回し]
```

## 例

**入力（抜粋）:** 「利用者は、顧問の税理士を閲覧のみの権限で招待できる。招待は簡単であるべき。閲覧のみの利用者は編集できない。利用率を測る。1日に全員に公開する」

**出力:**

```markdown
# 仕様書のレビュー: 閲覧のみのシート

**判定:** まだ作れない — 状態が決まっておらず、指標が測れず、戻す手段のないリリースになっている。

## はじめて使う人としてたどった流れ
1. オーナーが招待の場所を探す — どのページかを仕様書が書いていない。抜け。
2. オーナーがメールアドレスを入れる — そのアドレスがすでにメンバーのときどうなるかを書いていない。抜け。
3. 税理士が招待メールを開く — メールの内容が決まっていない。抜け。
4. 税理士がアプリに入る — 最初に何が見えるか？ 空のダッシュボードは「壊れている」と読まれる。抜け。

## 止まる問題
| # | 仕様書の記述 | 問題 | 直し方か質問 |
|---|---|---|---|
| B1 | 「編集できない」 | 書き出しは編集か？ コメントは？ エンジニア2人で答えが分かれる。 | 許可する操作を並べる: 閲覧、書き出し [要確認]、それ以外はなし。 |
| B2 | 「1日に全員に公開する」 | フラグも切り戻しの条件もない。権限のバグがあれば、すべてのアカウントがさらされる。 | フラグの裏で社内のアカウントに出し、次に10%へ [このスキルの既定値]。キルスイッチを足す。 |
| B3 | 「利用率を測る」 | イベントも、現状の値も、目標もない。 | 閲覧のみの招待が1件以上承諾されたアカウント数を週ごとに数える。目標はこれから決める。 |

## 直したほうがよい
| # | 仕様書の記述 | 問題 | 直し方か質問 |
|---|---|---|---|
| S1 | 「招待は簡単であるべき」 | テストできない。 | 「オーナーはチームのページから3クリック以内で招待を送れる」[このスキルの提案]。 |
| S2 | （記述なし） | 閲覧のみのシートに上限がない。 | 上限を決めるか、「上限なし」と書く。 |

## 抜けている状態
| 画面 | 空 | 読み込み中 | エラー | 権限なし | メモ |
|---|---|---|---|---|---|
| チームのページの招待 | 該当なし | 抜け | 抜け | 抜け | オーナー以外には何が見える？ |
| 税理士の最初の画面 | 抜け | 抜け | 抜け | 該当なし | 「閲覧のみの権限です」の表示が必要 |

## 指標とリリース
- 主指標: 抜け — B3を参照。
- 段階リリース: 抜け — B2を参照。
- 切り戻しの条件とキルスイッチ: 抜け — B2を参照。

## 細かい指摘
- 「税理士」と「閲覧のみの利用者」が同じ役割に使われている。どちらかに決める。
```

## 送る前のチェック

- [ ] たどった流れが、実際の利用者がたどり着くところから始まり、成功までのすべてのステップを含んでいる。
- [ ] どの指摘も仕様書を引用しているか、抜けについては「（記述なし）」と書いている。
- [ ] 止まる問題のすべてに、直し方の提案かまっすぐな質問がある。
- [ ] 状態の表が、仕様書に出てくるすべての画面を含んでいる。
- [ ] 指標、段階リリース、切り戻しに、それぞれありか抜けかの印がある。
- [ ] 自分が提案した既定値（割合、クリック数）は、仕様書のものではなく提案だと印をつけている。

## よくある失敗

- 要件の一覧だけをレビューする。抜けの多くはステップとステップの間にある。まず流れをたどる。
- 細かい指摘を40個並べる。止まる問題から書き、細かい指摘は5個までにする。
- 仕様書を書き直す。抜けを指して提案する。直すのは書き手。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.1 · 2026年11月4日 · Example: S1's "3 clicks or fewer" is marked [our suggestion], as the checks require for defaults the review proposes.
• v1.0.0 · 2026年11月4日 · First release.