ガイド
プロダクトチームが作る前に仕様書を AI でレビューする方法
プロダクトチームは、開発に入る前に、どの仕様書も AI に同じ型でレビューさせられます。初めての利用者として流れをたどり、次に何が表示されるかを仕様書が書いていないところをすべて挙げさせます。そのうえで、画面ごとに空、読み込み中、エラー、一部のデータ、権限なしの状態を確かめ、「速い」「簡単」「必要に応じて」のように 2 人が違うふうに試しそうな言葉に印をつけ、上限と既存のデータの扱い、基準値と目標つきの成功の指標が 1 つあるか、段階的に公開でき、リリースなしで止められるかを確かめます。指摘は必須・直すべき・細部に分けて返り、どれも仕様書の引用と直し方つきです。
要点
- 流れをたどる:初めての利用者として。
- 画面ごとの状態:空、読み込み中、エラー、権限なし。
- あいまいな言葉、上限、指標、ロールバック。
- 指摘を分ける:引用と直し方つき。
そのまま使える頼み方
仕様書レビューの頼み方
「作る前に、この仕様書をレビューしてください。
初めての利用者として、たどり着いたところから流れをたどる。次に何が見えるかを仕様書が書いていない手順と、初めての人が迷う言葉をすべて挙げる。
画面ごとに、空、読み込み中、エラー、一部のデータ、権限なし、成功を確かめる。
『速い』『簡単』『シンプル』『〜すべき』『など』『一部』『必要に応じて』と、2 人が違うふうに試しそうな要件に印をつける。
だれができるか、何件まで、上限でどうなるか、既存のデータはどうなるか。基準値と目標つきの主な指標が 1 つあるか。公開(フラグ、だれから)とロールバック(何がきっかけか、リリースなしで止められるか)。
指摘を分ける:必須、直すべき、細部。仕様書を引用し、なぜ問題か、直し方を書く。
仕様書:[貼りつけ]」
例
架空の例です。40 人の請求書サービスの会社で、プロダクトチームが「定期請求」の仕様書を書きました。レビューから。
レビューから
必須:「請求書を定期的に繰り返せる」。顧客の登録が削除されたとき、定期の請求書がどうなるかが書かれていない。直し方:今後の請求を止めるか、最後の情報で続けるかを決めて書く。
必須:ロールバックがない。直し方:フラグの裏で 10% のアカウントに公開し、リリースなしで新しい定期請求を止められるスイッチをつける。
直すべき:初めての利用者向けの、予定の画面の空の状態がない。直し方:定期請求で何ができるかの 1 行と「最初の定期請求を設定」のボタン。
直すべき:「期日のあと速やかに請求書を送る」。直し方:「アカウントのタイムゾーンで 9 時から 15 分以内」のように数字に。
直すべき:指標がない。直し方:予定どおりに送られた請求書の割合。いまの手作業での基準値と目標つきで。
プロダクトマネージャーは計画の会議の前に 2 つの必須を直し、細部は文言のレビューに回しました。
チームの習慣にする
- 計画に回す前に、どの仕様書にも同じレビューをする。
- 指摘と決めたことを仕様書に添える。
- 必須の指摘は計画の会議の関門にする。
- 顧客のデータを仕様書に入れたまま個人のアカウントに貼らない。
- 同じ抜けが本番まで 2 回届いたら、確かめを足す。
次の一歩:リポジトリのスキルにする
チーム全員で使うレビューは、全員の AI が読む場所に置きます。Claude Code でスキルを作る方法でリポジトリに置く方法を、SKILL.md と AGENTS.md の違いで何をどこに書くかを説明しています。
このテーマに使えるスキル
- プロダクト作りはじめる前の仕様書レビュー作りはじめる前に PRD や仕様書をレビューする。あいまいさ、空・読み込み中・エラー・権限なしの抜け、指標、段階リリース、はじめて使う人としての流れ。
- プロダクト散らかったメモから PRD を作るメモ、Slack のスレッド、商談メモから PRD を作る。根拠つきの課題、目標と目標外、指標、Must・Should・Could の要件をそろえ、足りない情報を挙げる。
- プロダクト受け入れ条件つきのユーザーストーリー機能をユーザーストーリーに分け、Given/When/Then の受け入れ条件、エッジケース、対象外のメモ、ストーリーごとの INVEST のチェックをつける。
- プロダクトRICE で機能の優先順位づけバックログを RICE か ICE で採点し、項目ごとの計算と感度を示して、工数に合わせた線引きと依存関係を提案する。
よくある質問
AI で仕様書のレビューはできる?
毎回同じ確かめをする最初のレビュー役としてならできます。初めての利用者として流れをたどり、画面ごとに空、読み込み中、エラー、一部のデータ、権限なしの状態を確かめ、「速い」「必要に応じて」のようなあいまいな言葉、上限、成功の指標、公開とロールバックの計画を確かめ、仕様書を引用して指摘を必須・直すべき・細部に分けるよう頼みます。
仕様書のレビューでは何を確かめる?
初めての利用者が流れを最後まで進めるか、どの画面にも状態があるか、どの要件も 1 通りに試せるか、上限と既存のデータが扱われているか、基準値と目標つきの指標が 1 つあるか、段階的に公開でき、リリースなしで止められるか、です。
AI のレビューでチームのレビューはいらなくなる?
なりません。どの仕様書にも同じ基本の確かめをしておくことで、チームのレビューの時間を製品の判断に使えるようにするものです。どの指摘に対応するかはプロダクトマネージャーが決めます。
AI スキル
AI に、作りはじめる前に仕様書をレビューさせる
このスキルを AI Skill Pod に入れれば、チーム全員が自分の Claude、Cursor、ChatGPT(Pro・Business・Enterprise)で使えます。招待リンク 1 つで共有でき、無料で始められます。「作りはじめる前の仕様書レビュー」スキルで、AI が仕様書をレビューします。初めての利用者として流れをたどり、画面ごとの状態、あいまいな言葉、上限、指標、ロールバックを確かめ、引用と直し方つきで指摘を分けます。
14日間無料・カード不要
出典
- Nielsen Norman Group:Designing empty states — システムの状態を示し、始め方を教え、作業への近道を出す (閲覧 2026-11-04)
- Nielsen Norman Group:Error-message guidelines (閲覧 2026-11-04)
- Martin Fowler:Feature toggles — リリースのトグル、段階的な公開、キルスイッチ (閲覧 2026-11-04)