設計書レビューをAIに頼んだら検出率0%だった — 3役割に分けて86%にした頼み方
設計書を AI にレビューさせて、「なんか浅いな」と感じたことはありませんか。
その「浅い」の正体を、答え合わせできる形で測りました。本物の設計書に欠陥を 7 個仕込んで、頼み方だけを変えて検出率を比較しています。
- 「レビューしてください」→ 検出 0/7 (0%)
- 「不整合がないか見て」→ 1/7 (14%)
- 観点を分けて 3 回頼む → 6/7 (86%)
同じファイル、同じモデル、同じ設定。変えたのは頼み方の日本語だけです。
この記事は手順書として書きます。プロンプトの構造と、渡すファイルの前処理、判定のさせ方まで、そのまま使える形で並べます。
TL;DR
1. 「レビューして」の一言で任せない（検出率 0% の頼み方）
2. 観点を3つに分け、別々のチャットで頼む
・校正者 … 各資料の中の欠番・重複・空欄・表記ゆれを全行走査
・監査役 … 資料Aが参照する番号・名前が資料Bに実在するか全件照合
・用語の番人 … 用語集を「正」として略語・別表記を検出
3. 全指摘に深刻度（重大/大/小/些細）を付けさせる
4. 答えを教えない（「3.1.5を見て」のような誘導を入れない）
5. Excel図形の業務フローは PDF に変換してから渡す
6. ★2026年7月追記：「重大な問題だけ報告して」と書かない（後述、逆効果）
測定条件
| 項目 | 内容 |
|---|---|
| 題材 | 総務省「税務システム標準仕様書【第3.0版】」個人住民税一式 (8ファイル、機能要件699件・帳票要件205件) |
| 仕込んだ欠陥 | 7個 (不整合2 / 実装漏れ1 / 用語ゆれ4) |
| 環境 | ブラウザ版 Claude (Pro プラン、Sonnet 5)、思考設定は最大、Web 検索オフ |
| 実施 | 2026年7月。毎回まっさらな新規チャット |
Web 検索をオフにしたのは、公開文書なのでネット上の原本と突き合わされたら実験にならないためです。
欠陥は実験のために筆者が加工して追加したもので、元の公開資料には存在しません。
なぜ「レビューして」だと 0% になるのか
8 ファイルを添付して「この設計書一式をレビューしてください。」とだけ送ると、7 ページの立派なレポートが返ってきます。優先度付きの指摘、修正提案、ポジティブ所見つき。
仕込んだ 7 個はひとつも見つかりませんでした。それどころか、本命の「実装漏れ」(機能要件から 3 行削除し、業務フロー側には使う手順が残っている状態) について、こう書かれていました。
「改版により削除された項番は欠番のまま維持され、後続番号の振り直しが行われていません。外部からの項番参照の安定性を保つ良い設計です」
削除の痕跡を、意図的な良い設計として褒めています。
理由は 2 つあります。
① AI は文脈を「善意で」補完する
欠番を見つけたとき、「削除ミスかもしれない」ではなく「番号の安定性を保つ意図的な設計だろう」ともっともらしい解釈を採用します。優秀な速読者ほど誤植を脳内補正して読み飛ばす、あれと同じです。
② 「レビューして」は調べる範囲を AI の裁量に丸投げしている
資料 A と資料 B の参照を 1 件ずつ突き合わせる、という地道な照合は、頼まれない限りやりません。新人に「この設計書、見といて」と渡したときに起きることと同じです。
ここがいちばん厄介な点です。AI が「見つけたもの」は確認できますが、「見逃したもの」は見えません。 中身のあるレポートが返ってくるので、こちらは「ちゃんとレビューされた」と感じてしまいます。
手順: 観点を 3 つに分けて別々に頼む
人間のレビューチームの組み方をそのまま持ち込みます。
役割1: 校正者 — 各資料の「中」を見る
1 つの資料の中で完結する異常を全行走査させます。
あなたはこの資料の校正者です。以下を全行走査して報告してください。
- 連番の欠番・重複
- 空欄になっている必須項目
- 同じ意味の語が別表記になっている箇所
各指摘に深刻度（重大/大/小/些細）を付けてください。
推測は書かず、資料に書かれている事実だけを根拠にしてください。
ポイント: 「全行走査」と明示します。書かないと、AI は目についたものだけ報告します。
役割2: つながりの監査役 — 資料を「またぐ」
実装漏れを捕まえるのは、この役割です。
あなたは資料間の整合性を監査する役割です。
資料Aが参照している番号・名前が、資料Bに実在するかを全件照合してください。
- 参照先が存在しないものを列挙
- 逆に、参照されていない項目も列挙
各指摘に深刻度（重大/大/小/些細）を付けてください。
この頼み方で、仕込んだ実装漏れがこう報告されました。
「この欠番は他と違って機能 ID の並びにも穴がある。過去に削除された痕跡」
「レビューして」で褒められた同じ欠陥が、削除の痕跡として名指しで暴かれます。
役割3: 用語の番人 — 用語集を「正」にする
添付の用語集を唯一の正とします。
本文中で、用語集に無い略語・別表記が使われている箇所を検出してください。
行番号または項番を明示してください。
3 つに分ける理由
1 チャットで全部やらせると、どの軸を見るかが AI 任せになります。選ばれなかった軸 (帳票→機能の参照列、用語のゆれ) は丸ごと盲点になります。実際、「不整合がないか見て」と目的だけ伝えた検証では、実装漏れの場所は特定できたものの、他の 6 件は見つからず 14% でした。
深刻度を付けさせる理由
検証 2 では、本命の実装漏れを見つけたのに**深刻度が「中程度🟡」**でした。「過去の改定で消えた項番が、フロー側で更新されずに残っているのでは」という穏当な解釈つきです。
指摘が何十件も並んだとき、人は重大とされたものから確認します。中程度に格付けされた重大欠陥は、多忙な現場では「見つからなかった」のとほぼ同じです。
深刻度を付けさせたうえで、その判定が妥当かを人間が見る。これが最終確認の中身になります。
答えを教えない
「3.1.5 を確認してください」のような誘導は入れません。実務では、レビュー前に設計書に何が書かれているか自分も知らないからです。
渡すのは「連番の欠番・重複を検出せよ」「参照の実在を全件照合せよ」という、どの設計書にも通用する汎用の観点だけにします。
結果
| 仕込んだ欠陥 | 結果 |
|---|---|
| 不整合 ×2 | すべて検出。2つの役割が独立に発見し、「1.9. は 1.3. の誤記では」と修正案つき |
| 実装漏れ ×1 | 検出。欠番の"質の違い"まで分析していた |
| 用語ゆれ ×4 | 3件検出 (1件見逃し) |
6/7 = 86%。
別環境 (Claude Code + 別モデル) でも試しましたが、結果は同じ 6/7 でした。モデルの性能ではなく、頼み方の構造が結果を決めています。 モデルが更新されても、別の AI に乗り換えても、この頼み方は持ち運べます。
それでも見つからなかった 1 件
どの頼み方でも、どの環境でも見つからなかった欠陥が 1 つあります。機能要件の補足説明欄、249 文字の長文セルに 1 回だけ埋めた「特別徴収義務者」の勝手な略語「特義者」です。
見つからない理由は構造的でした。
- 補足欄にあり、項目名も本文も正しいので行として「正常」に見える
- 出現が 1 回だけで、頻度の異常として浮かばない
- 頭文字をつまんだ略語なので、正式名称と連続一致する文字が 1 文字しかなく機械的照合にかからない
そして AI は文脈で補完します。「特義者情報が表示される」を読んだ瞬間に「特別徴収義務者のことだな」と理解して素通りする。欠陥を褒めたのと同じ、賢さゆえの見逃しです。
ただし、重大側の 3 件 (実装漏れ・不整合) はすべて検出されました。深刻度の高い欠陥ほど構造的な痕跡 (存在しない番号、欠番) を残すので、機械的な照合に引っかかりやすいようです。1 回の実験の傾向であって保証ではありませんが。
★2026年7月追記: 「重大な問題だけ報告して」は逆効果になった
ここからは元の実験より後に分かったことです。
新しいモデル (Claude Opus 5) の公式ドキュメントに、レビュー用途の注意が明記されました。
レビュー用プロンプトに「重大な問題だけ報告して」「保守的に判断して」と書いてあると、モデルはその指示に文字通り従って報告を減らすことがある。代わりに、すべて報告させて別のパスでフィルタすること。
（原文: If your review prompt says "only report high-severity issues" or "be conservative," the model may follow that instruction literally and report less; ask it to report everything and filter in a separate pass instead. — Prompting Claude Opus 5）
指摘が多すぎるとき、つい「重大なものだけ」と書き足したくなります。それが拾えたはずの問題を隠します。 しかも減ったことは画面に出ないので、「指摘が少なかった = 出来が良かった」と読み違えます。
この記事の 3 役割方式は、もともと全部出させて深刻度を付けさせる設計なので、この落とし穴を踏みません。フィルタは人間側の工程に置いてください。
あわせて、同じドキュメントで削除を指示されている指示もあります。筆者が実測したところ、これらを足すと出力量が平均 2.3 倍になり、成果物は変わりませんでした。
・「最後に検証ステップを入れて」
・「サブエージェントで検証させて」
・「答えをダブルチェックして」
・「返答前に再確認して」
おまけ: Excel 図形の業務フローは PDF にしてから渡す
デジタル庁公開の業務フロー Excel を調べたところ、セルに入っている文字はスイムレーンの見出し 5 種類だけで、業務の中身 180 個は全部図形 (テキストボックス) の中でした。
テキストとして読む方式 (コピペ、Excel 対応の MCP サーバー含む) では、業務フローの本体が丸ごと欠落します。厄介なのは、見出しだけでも AI は何かしら答えてしまうので、中身が渡っていないことにこちらが気づけない点です。
なお、この Excel をそのままブラウザの Claude に渡したら、15 分後にほぼ完璧な説明が返ってきました。本人いわく「セル自体にはレーン名しか入っていなかったため、PDF 変換して図として読み取りました」。読めないと自分で気づいて、自力で PDF 化していました。
とはいえ 15 分かかります。最初から PDF で渡せば数十秒です。
まとめ
□ 「レビューして」の一言で任せていないか
□ 観点を3つに分けて、別々のチャットで頼んでいるか
□ 全指摘に深刻度を付けさせているか
□ 答えを誘導していないか
□ Excel図形の業務フローを PDF 化してから渡しているか
□ 「重大な問題だけ報告して」と書いていないか（逆効果）
検出率 0% と 86% を分けたのは、AI の性能ではありませんでした。性能は最初から足りていて、こちらが引き出せていなかっただけでした。
この実験で使った 3 役割のプロンプト全文、答えを誘導しないための自己チェックリスト、会社の設計書で安全に試すための注意点は、note の実践パッケージ にまとめています。上の手順だけでも再現できますが、そのまま貼って使いたい方はどうぞ。
出典: 総務省ウェブサイト「税務システム標準仕様書【第3.0版】」／デジタル庁ウェブサイト「地方公共団体情報システム共通機能標準仕様書」関連資料