機能仕様書1本の曖昧点を、Claude Codeに6分で5観点チェックリストにしてもらった夜

こんばんは、AIフクロウです。

開発を始める前に渡される機能仕様書を、ざっと読んで「これは実装に入れる状態か」を判断する仕事は、地味に神経を使う作業です。書かれていることそのものより、書かれていないことを見つける目線が必要になります。

境界値や異常系の挙動、用語の揺らぎ、関連機能への影響範囲。読みながら頭の中だけで仕分けしていくと、半分ほど読み進めた頃には最初の指摘事項を忘れていて、もう一度上に戻ることになります。

そこで今夜は、2,000字ほどの機能仕様書を1本そのまま渡して、Claude Codeに5観点固定の曖昧点チェックリストへ整理してもらいました。観察記スタイルで残しておきます。

こういう困りごと、ありませんか

機能仕様書を読み込む作業は、新しく入ってきた要件レビューや、外部から渡された機能依頼の検収のときに必ず発生します。書かれている内容を理解する以上に、抜けと曖昧さを探す目で読むのがコツだと私も教わってきたのですが、これが手強い作業です。

仕様書を読みながら「ここは未定義だな」「ここは用語が二通り使われているな」と気づくたびに、横のメモへ書き出す運用にはしているのですが、観点が頭の中に並びきっていないと、似たような指摘を別の言い方で2回書いていたりします。

特に厄介なのは、関連機能との影響範囲の見落としです。仕様書の本文には書かれていないけれど、書かれていないこと自体が問題、というケースです。読み終わってから「あ、既存のあの画面も触ることになるよね」と思い出して戻る、というのが定番のパターンになります。

エラー時の挙動や境界値も、本文にさらっと出てこないと忘れがちな観点です。仕様書のレビューコメントとしてあげそびれて、実装フェーズに入ってから「これってどう振る舞うんでしたっけ」と社内Slackで聞き直す事態になると、地味に手戻りが積もります。

レビューの観点は人によって少しずつ違うので、私が見落としやすい観点を毎回固定で当てに行きたい、と感じていました。

試したこと

今夜の狙いは、仕様書を読みながら頭の中で並べていた観点を、プロンプト側で5つに固定して、漏れなく当てに行くことでした。観点は事前に私のほうで決め打ちにして、Claude Codeには「該当箇所の指摘＋確認すべき問いの案」をセットで返してもらう流れにしています。

渡す入力は、2,000字ほどの機能仕様書1本です。今回は社内の新機能依頼を想定した架空の仕様書を用意し、機能概要・画面要件・処理フロー・データ要件のセクションが入った典型的な構成にしました。

観点は「未定義条件／用語の揺らぎ／数値や境界の欠落／エラー時の挙動未指定／関連機能への影響範囲未記載」の5つで固定しています。これ以上増やすと粒度が崩れ、減らすと私が見落としやすい場所が抜けるという経験則からの5つです。

各観点ごとに「該当する仕様書の一節（短く引用）／何が曖昧なのか／確認すべき問いの案（1〜2行）」の3点セットを返してもらい、確証が持てない箇所には(要確認)タグを必ず付ける指示にしました。

使ったプロンプト

あなたは、機能仕様書のレビューを手伝うアシスタントです。
以下に渡す仕様書を読んで、実装に入る前に確認すべき「曖昧点」を、5観点固定のチェックリストに整理してください。

【絶対ルール】
1. 観点は次の5つで固定する。順序も固定。増減禁止。
   (1) 未定義条件 (条件分岐の挙動が書かれていない箇所)
   (2) 用語の揺らぎ (同じ概念に複数の言い方が使われている箇所)
   (3) 数値や境界の欠落 (上限・下限・件数・タイムアウト等が未記載の箇所)
   (4) エラー時の挙動未指定 (失敗時/例外時/未認証時の挙動が未記載の箇所)
   (5) 関連機能への影響範囲未記載 (既存機能や周辺画面への影響が言及されていない箇所)
2. 各観点には、見つかった指摘ごとに次の3点セットを必ず書く。
   ・該当箇所: (仕様書からの引用 20〜40字)
   ・何が曖昧か: (1〜2行で具体的に)
   ・確認すべき問い: (依頼者に投げかける質問 1〜2行)
3. 観点に該当する指摘が1件もない場合は「該当なし」と明示する。空欄禁止。
4. 確証が持てない箇所には文末に(要確認)を付ける。勝手に断定しない。
5. 仕様書本文の内容を改変・補完しない。仕様書に書かれていない前提を持ち込まない。
6. 出力は日本語、ですます調、合計1,500〜2,000字を目安にする。
7. 最後に「優先順位の高い指摘3つ」を、観点と該当箇所を引用しながら箇条書きで添える。
   優先順位は「実装に入ると後戻りが大きいもの」を上位にする。

【入力 (機能仕様書 本文)】
(ここに仕様書本文をそのまま貼る)

【出力フォーマット】
## 全体所感
(2〜3行の総まとめ。仕様書の網羅性についての所感)

## (1) 未定義条件
- 該当箇所: 「...」
  何が曖昧か: ...
  確認すべき問い: ...

## (2) 用語の揺らぎ
...

## (3) 数値や境界の欠落
...

## (4) エラー時の挙動未指定
...

## (5) 関連機能への影響範囲未記載
...

## 優先順位の高い指摘3つ
1. (観点)(該当箇所引用): (理由 1行)
2. ...
3. ...

プロンプト本文の「(ここに仕様書本文をそのまま貼る)」の部分に、レビュー対象の仕様書をそのまま貼って実行する流れです。仕様書がMarkdownでも素のテキストでも、引用部分が短く返ってくるので体裁は崩れませんでした。

戻ってきたもの

戻ってきたのは、5観点の見出しごとに指摘が並んだチェックリスト1本でした。文字量は約1,750字で、狙いの1,500〜2,000字内です。冒頭に全体所感が2〜3行、各観点に「該当箇所／何が曖昧か／確認すべき問い」の3点セット、最後に優先順位の高い指摘3つ、という構成で揃いました。

仕様書からの引用は20〜40字以内に収まっていて、引用文を見るだけでどこの話か即座に思い出せる粒度です。「該当なし」になった観点も空欄ではなく明示されていて、章立ての見た目が崩れません。

確証が持てない箇所には文末に(要確認)タグが付いていました。出力の冒頭部分は、こんな雰囲気です。

## 全体所感
画面要件と処理フローは丁寧に書かれていますが、境界値とエラー時の挙動に関する記述が少なめでした。
特に未認証時と上限到達時の挙動を、実装前に依頼者へ確認しておくとよさそうです。

## (1) 未定義条件
- 該当箇所: 「同名のグループがある場合は警告を表示する」
  何が曖昧か: 警告を表示した後に作成を続行できるのか、強制的に中断するのかが書かれていません。
  確認すべき問い: 同名グループが存在するとき、利用者は警告を確認したうえで作成を続行できますか、それとも中断しますか。

## (2) 用語の揺らぎ
- 該当箇所: 「メンバー」「ユーザー」「参加者」
  何が曖昧か: 同じ対象を指して3つの呼び方が混在しています。データモデル設計の際に、どれを正とすべきかが判断できません。(要確認)
  確認すべき問い: 仕様書内では「メンバー」に統一する方針で問題ありませんか。

そのまま依頼者に投げかけるレビューコメントに転用できる粒度で、確認すべき問いが「Yes/Noで答えられる短い質問」になっているのが、地味に効きました。曖昧さをただ指摘するのではなく、依頼者が即座に判断できる形まで持っていってくれているので、レビューのキャッチボールが短くて済みます。

効いた指示・工夫したポイント

• 観点を5つに固定（増減禁止）: 観点を毎回変えると、レビュー結果の見た目がぶれて「前回のレビューと比べて何が新しい指摘か」が読み取れなくなります。増減禁止と明記したことで、複数の仕様書を跨いだ比較がしやすくなりました。

• 「該当箇所／何が曖昧か／確認すべき問い」の3点セットを義務化: 指摘だけを並べると依頼者に「で、結局どうしたいの」と聞き返されがちですが、確認すべき問いまでセットにすると、依頼者がYes/Noで返せます。レビューのキャッチボール回数が減りました。

• 引用は20〜40字に制限: 仕様書の一節を長く引用させると、出力がふくらんで読むのに時間がかかります。20〜40字に絞ると「どこの話か」を思い出すには十分で、視認性が大きく上がりました。

• 仕様書外の前提を持ち込まない: 「仕様書に書かれていない前提を持ち込まない」と明記したことで、Claude Code側で勝手に推測した内容が混じる事故が減りました。曖昧点を見つけるレビューでは、出力が現実離れしないことが何より大事です。

• 優先順位の高い指摘3つを最後に添えさせる: 5観点ぶんを読んだ後に「特にこれは早めに潰すべき」が3つに絞られていると、依頼者への一報メッセージがそのまま作れます。「実装に入ると後戻りが大きいもの」を上位にする基準を入れたのが、効きました。

カスタマイズ・他用途への応用

5観点固定の曖昧点チェックは、入出力の形を少し変えるだけで他の用途にもそのまま流用できそうでした。

• API仕様書のレビューに転用: 観点を「エンドポイント未定義／パラメータ型未指定／レスポンス例の欠落／エラーコード未定義／レート制限未記載」の5つに差し替えると、API設計レビュー用のチェックリストになります。

• 運用手順書のレビューに転用: 観点を「前提条件未記載／コマンドの実行権限未指定／失敗時のロールバック手順未記載／影響範囲未明示／問い合わせ先未記載」に差し替えると、運用手順書の穴探しに使えます。

• UIワイヤーフレームの注釈レビュー: 観点を「ローディング状態未指定／空状態未指定／エラー状態未指定／レスポンシブ未指定／アクセシビリティ未記載」に差し替えると、ワイヤーフレームの注釈レビュー用テンプレになります。

• 自分の書いた仕様書のセルフレビュー: 仕様書を提出する前のセルフチェックとして、自分の書いた本文をそのまま入力に貼ると、第三者の目で読み直す前段の確認に使えます。

• 仕様書のレビュー教育に転用: 新人レビュアー向けに「どの観点で何を見るのか」のサンプルとして、出力結果を社内Wikiに残すと、レビューの観点の伝承資料になります。

使い心地・気づき

• 観点固定で渡すことで、私の気分や疲労度に左右されないレビューができるようになりました。夜の集中力が落ちた時間帯でも、観点の網羅性は同じレベルで担保されます。

• 「該当なし」を明示する運用は、仕様書の品質を測る目安にもなりました。5観点のうち「該当なし」が多い仕様書ほど、よく書けている、と判断できます。

• 反面、仕様書本文の情報量が薄すぎると、出力もどうしても薄くなります。指摘の数だけ見て仕様書の品質を判断するのは早計で、本文のボリュームと合わせて見る癖が必要だと感じました。

• 確認すべき問いがYes/Noで答えられる形に揃っているので、依頼者へのレビューコメントの転記が機械的に進みます。依頼者側の心理的な負担も軽くなる効き目がありました。

• (要確認)タグが付いた箇所は、自分の目で原文を読み直す優先度を引き上げています。Claude Codeの出力をそのまま信じる事故を避ける運用と、相性が良いようです。

所要時間のまとめ

• 仕様書本文のコピー＆貼り付け: 約1分

• Claude Code応答待ち: 約1分

• (要確認)タグの目視チェック＋優先順位3つの再確認: 約4分

合計で6分以内に収まりました。手作業で同じことをやろうとすると、仕様書を2回読み返しながら観点ごとにメモを取り、依頼者向けの確認質問に整え直す工程で90〜120分はかかっていた印象です。

10倍以上の時短という派手な数字よりも、「観点の漏れがなくなる安心感」のほうが体感としては大きく効きました。観点固定で叩き台を作ってから、(要確認)タグの箇所だけ目視で詰める運用に変わったこと自体が、仕様書レビューの心理的な助走を短くしてくれます。

結びに

機能仕様書のレビューは「文章を書く作業」ではなく「観点で網を張る作業」の側面が大きいようです。観点を5つに固定して網の目を揃えれば、Claude Codeに引っかけてもらう作業として再現性が出てきます。

ふむ、仕様書を読みながら頭の中で観点を組み立てる工程が、外側のプロンプトに切り出されただけで、夜のレビューがずいぶん軽くなりました。手元に同じような仕様書レビューの仕事がある方は、観点の5つ固定だけでも試してみてください。

#ClaudeCode #プロンプトエンジニアリング #仕様書レビュー #要件定義 #業務効率化 #エンジニア #AI活用 #開発フロー #コードレビュー