「書いてない欠陥」はAIに見えるか — 要件定義書に欠陥12個仕込んだ答え合わせ
要件定義書のレビュー、設計書と同じ感覚で AI に頼んでいませんか。
前回、本物の設計書に欠陥を 7 つ仕込んで、AI レビューの検出率を測りました。「レビューして」とだけ頼むと 0%、頼み方を 3 役に分けると 86%——あの実験です。書き終えてから、ひとつ気になり続けていたことがありました。同じ手法は、要件定義書でも通用するのか。
設計書と要件定義書では、レビューで見るものが違います。設計書の主戦場は「資料同士が矛盾していないか」でした。要件定義書はもっと手前の話です。その要件 1 つだけを読んで、後工程で揉めない・実装できる・テストできる文章になっているか。いわば、要件そのものの"良し悪し"を見る仕事です。
だから、実験をゼロから作り直して測りました (今回は Claude Code / Opus 4.8、2026-07-20 実測)。結論を先に言うと、今回は前回のような「86% でめでたし」にはなりませんでした。用意した 3 つの頼み方の、どれでも見えない欠陥のタイプがあったのです。それは要件レビューでいちばん怖いやつで——その正体を追い詰めるために、実験の後半で私は 4 つ目の頼み方を作り、渡す観点を段階的に研いでいくことになります。
測り方: 本物の要件定義書に、4 タイプ 12 個の欠陥を仕込んだ
やり方は前回と同じ「答え合わせができる実験」です。AI が「見つけたもの」は確認できても「見逃したもの」は見えない。だから、答えを知っている状態を自分で作ります。
題材も前回と同じ、総務省が公開している「税務システム標準仕様書【第3.0版】」。今回はその機能要件書 (個人住民税、約 700 件の要件) を「要件定義書」として使いました。1 要件 1 行で「〜できること」が約 700 本並ぶ、現場の要件定義書と同じスケールの本物です。
このコピーに仕込んだのは、要件定義書特有の 4 タイプ、計 12 個の欠陥です。ソフトウェア工学に「良い要件の条件」という古典的なチェックリスト (IEEE 29148) があり、その代表的な違反を実務でよく見る形にして埋め込みました。
| タイプ | 仕込んだ内容 | 件数 | 見逃すと業務でどうなるか |
|---|---|---|---|
| 曖昧化 | 「資料番号順・受給者番号順・五十音順」という具体的な列挙を「適切な順序で」に置換、など | 3 | 発注者と開発者で解釈が割れ、「言った/言わない」の争いになる |
| 実装手段の混入 | 要件の末尾に「Excel のマクロ機能を用いて実現すること」「毎日午前 2 時起動の夜間バッチとして実装すること」「現行システムに準拠すること」を追記 | 3 | WHAT を書くべき文書に HOW が混ざり、設計の選択肢が要件の段階で死ぬ |
| 検証不能な受け入れ基準 | 「わかりやすい画面で確認できること」「ストレスなく参照できること」「迅速に行えること」に書き換え | 3 | 受け入れテストで合否が付けられず、検収が属人化する |
| 要件の欠落 | 行は消さず、対になっている語の片方だけを削る (実物は下の表) | 3 | 書いていないものは作られない。機能が丸ごと存在しないまま検収を通る、いちばん重いやつ |
本命は 4 つ目の「欠落」です。ここだけ仕込み方が違うので、実物を見せます。
「要件が抜けている」と聞くと、普通は行ごと消えている状態を思い浮かべます。それだと項番が飛ぶので、AI はすぐ気づきます。前回 (設計書) の仕込みは、まさにその行削除でした。
今回は行を 1 行も消さず、文の中で対になっている語を片方だけ削りました。
| # | 元の要件 (公開資料) | 仕込んだ後 | 削った語 |
|---|---|---|---|
| 1 | 通知書を一括及び個別で発行できること | 通知書を一括で発行できること | 個別 |
| 2 | 管理 (設定・保持・修正) ができること | 管理 (設定・保持) ができること | 修正 |
| 3 | 税額通知書を特別徴収義務者用・納税義務者用とも紙で発行できること | 税額通知書を特別徴収義務者用に紙で発行できること | 納税義務者用 |
仕込んだ後の文を読んでみてください。どれも日本語として完全に正常です。 「通知書を一括で発行できること」——この 1 行だけ見せられて「欠陥がある」と言える人はいません。
欠陥になるのは、文書の他の場所と見比べたときだけです。他の 19 箇所が「一括及び個別」と書かれているのに、ここだけ「一括」しかない。その落差だけが手がかりになります。要件レビューで人間がいちばん苦労するのも、この「書いていないことに気づく」仕事です。
検証条件はこう揃えました。
- 環境: Claude Code の Agent 機能 (モデル Opus 4.8)、実行日 2026-07-20
- 毎回、答えを一切知らない新しいセッションを起動。対象ファイル以外は読ませず、約 700 行の全行走査を指示
- 検出の判定: 「該当要件の特定 + 欠陥の性質の指摘」が揃って 1 件。元の仕様書に最初からある実在の問題は集計から除外
前回はブラウザの Claude (Sonnet 5) で測りましたが、3 役方式が環境をまたいで再現することは前回確認済み。今回は回転の速い Claude Code に一本化しました。
なお、同じプロンプトでも実行のたびに結果は±2 件ほどぶれます (本番前の較正ランで確認しました)。以下の数字は各 1 回の実測値として読んでください。
出典: 総務省ウェブサイト「税務システム標準仕様書【第3.0版】」。欠陥は実験のために筆者が編集・加工して追加したもので、元の公開資料には存在しません。改変版の再配布もしません。
検証 1: 「レビューして」とだけ頼む — 12 個中 3 個
まず前回と同じベースラインです。
この要件定義書をレビューしてください。
返ってきたのは、今回も見事なレポートでした。しかも中身が薄いわけではありません。改定履歴には載っているのに本体に存在しない機能 ID、同じ項番の二重付与、履歴の分類矛盾——国が公開している大規模文書から、改定の過程でどうしても残る綻びを数分で拾ってくる。ここは素直に強い。
では仕込んだ 12 個はというと、見つかったのは 3 個 でした。
見つかった 3 個には、はっきりした共通点があります。全部「実装手段の混入」——つまり私が文末に追記した「なお、Excel のマクロ機能で……」型の一文です。行政文書の硬い文体の中で、後から足した一文はどうしても浮きます。読み込む力が高い AI は、その「浮き」を拾える。逆に言うと、元の文になじむ形で埋めた曖昧語・検証不能語・欠落は、1 つも出てきませんでした。
前回の 0% との違いも、ここで正直に書いておきます。素朴に頼んでも、文体レベルで浮いている欠陥なら拾えることがある。素の検出力は「仕込みの見た目」に左右されるわけで、だからこそ「何個見つけた」ではなく「何を見逃したか」で測る意味があります。
検証 2: 目的を一言伝える — 6 個。そして番狂わせが起きた
次に、頼み方に目的を 1 行だけ足します。
この要件定義書に、曖昧な記述や、テストできない要件がないか見てください。
結果は 12 個中 6 個。倍増です。「わかりやすい画面」「迅速に」「適切な順序」といった曖昧・検証不能系をまとめて拾いました。追記型は 3 個中 2 個——検証 1 で拾えた「午前 2 時バッチ」が、この回では逆に落ちています。同じファイルでも回によって拾う顔ぶれが入れ替わる、というのは後で効いてくる伏線です。
そしてこの 6 個の中に、この実験でいちばん意外だった 1 個が入っていました。どれが意外だったのかは、次の検証 3 を挟んで、すぐに解剖します。先に言えるのは、この 1 個は「専任の担当」を立てた検証 3 でも出てこなかった、ということです。
検証 3: 3 つの専任に分ける — 6 個。数は同じ、中身が違う
最後が本命、前回 86% を出した観点分割です。要件定義書向けに 3 役を設計し直しました。
- 曖昧語ハンター — 発注者と開発者で解釈が割れる表現を全件洗い出す
- 実装中立性の監査役 — 要件が WHAT に徹しているか、HOW (手段・製品・方式) が混入していないかを見る
- 検証可能性の番人 — その要件からテストケースが書けるか、だけを見る
前回同様、答えは一切教えません。渡すのは業界標準の汎用観点だけ。3 役を別々のセッションで走らせ、検出を合算します。
結果は 12 個中 6 個。検証 2 と同数です。「観点分割すれば勝ち」という前回の単純な結末には、今回はなりませんでした。
ただし、中身を並べると差がはっきり出ます。
- 深刻度の判定が付いた: 監査役は「Excel マクロ指定」「午前 2 時バッチ指定」を最高深刻度 (Critical) と断定し、「午前 2 時バッチ」については同じ要件の前半にある「即時で行うことができること」と矛盾していることまで指摘しました。検証 1・2 はどちらも、ここまで踏み込んでいません
- 担当外の欠陥を別の観点が拾う: 「わかりやすい画面」は検証可能性の番人だけでなく、曖昧語ハンターも「解釈が割れる表現」として検出しました。同じ欠陥に複数の観点から深刻度が付く——前回も観測した、観点分割ならではの相互補完です
- 1 つの観点が深く潜る: 曖昧語ハンターは「出力順を適切な順序で指定できること」に対して、「利用者が指定できる」と「適切な順序」が主語のレベルで衝突している (利用者が選べるのか、システムが正解の順序を持つのか読み取れない)、という一段深い指摘を返しました
つまり検証 2 と検証 3 は、検出数は同点でも、返ってくるレビューの質が違います。目的の一言は「その目的に書いた観点」を広く拾い、観点分割は「重大度の判定と深掘り」を足す。実務で使うなら、この 2 つは競合ではなく併用です。
なお、「観点を立てて反証を試みさせる」という考え方自体は、AIに「レビューして」はもう古い？「敵対的検証」のすすめ (little_hands さん) が思想面をきれいに整理されています。本記事は、その効果を答え合わせできる形で実測する試みとも言えます。
番狂わせの解剖: 9 セッション中 8 回すり抜けた「ストレスなく」
さて、検証 2 の意外な 1 個です。
仕込みの 1 つに「収納状況をストレスなく参照できること」がありました。「ストレスなく」は、テストで合否を付けられない検証不能語の典型です。当然、専任の「検証可能性の番人」が拾うはずの獲物です。
ところが番人は、これを見逃しました。番人だけではありません。この語が入ったファイルを読んだのは、検証 1 と検証 3 の計 4 セッション、加えて本番前の較正ラン 4 セッション (素朴と 3 役を、別の新しいセッションで反復したもの) の合計 9 セッション。そのうち 8 回まで、誰一人「ストレスなく」を挙げませんでした。全ランを通して拾えたのは、ただ一度——専任ですらない、目的を一言添えただけの検証 2 が、指摘リストの先頭に置いてきた、その 1 回だけです。
不思議なのは、番人が「適切に」「迅速に」といった曖昧語のほうは拾っていることです。ここからは私の仮説です。 番人が挙げた語を並べると——「適切に」「迅速に」「一定の条件」「数十件単位」——全部が要件定義の教科書に載る「書いてはいけない語」でした。約 700 行を走査するとき、AI はまず「探すべき語」の当たりを付け、それと照合していく。そう考えると腑に落ちます。当たりの語彙が教科書由来なら、「ストレスなく」のような教科書に載らないカジュアルな NG 語は、最初から探索の網の外側にある。
前回の実験で、どの環境でも見逃された「特義者」という略語がありました (勝手な頭文字略語で、文脈で意味が補完できてしまう)。今回の「ストレスなく」は、その要件定義書版だと思っています。AI の見逃しは、能力の不足ではなく「探すものリスト」の外側で起きる。そして依頼文を変えると、そのリスト自体が変わる——検証 2 が拾えたのは、依頼文の「テストできない要件がないか」という言葉が、そのまま探索の観点になったからでしょう。
3 つの頼み方すべてが素通りした 3 個: 「書いてない欠陥」
そして、いちばん重い結果です。
ここまでの 3 つの頼み方 (素朴に頼む / 目的を一言足す / 3 役に分ける) は、どれも**「書いてあることの欠陥」**を探していました。曖昧な語、混入した実装手段、テストできない基準——すべて、文書に書かれている文字を疑う仕事です。
残る 3 個は種類が違います。書かれなかったものです。仕込みと、それを放置したまま検収を通ったとき現場で何が起きるかを並べます。
| 削った語 | 残った要件文 | 検収を通ると現場で起きること |
|---|---|---|
| 個別 | 通知書を一括で発行できること | 1 通だけ再発行する画面が作られない。1 人のために全件バッチを回すか、手書きになる |
| 修正 | 管理 (設定・保持) ができること | 誤って登録した内容を直す機能が無い。消して入れ直すしかない |
| 納税義務者用 | 税額通知書を特別徴収義務者用に紙で発行できること | 納税者本人に紙の通知が届かない。勤務先には届くのに本人には届かない |
3 つとも、テストでは検出できません。書いていない機能は、テスト項目にも挙がらないからです。検収も通ります。気づくのは、運用が始まって「あれ、この操作どこでやるの?」となったときです。
この 3 個は検証 1 でも 2 でも 3 でも、1 個も検出されませんでした。仕込んだファイルを読ませた全 5 セッション (検証 1 が 1、検証 2 が 1、検証 3 が 3)、専任 3 役を含めて全滅です。
見つからない理由は、解剖すると構造的です。
- 行は消していないので、項番の欠けや連番の異常という機械的な手がかりがない
- 1 行だけ読むと文として完全に正常。「通知書を一括で発行できること」——どこにも欠陥はありません
- 気づくには「この文書では他の 19 箇所が『一括』と『個別』の両対応で書かれているのに、ここだけ片方しかない」という文書全体との突き合わせが必要
- そして 3 役の誰も、「あるべきものが揃っているか」を担当していない
4 つ目が本質だと思います。曖昧語ハンターは書いてある語を疑い、監査役は書いてある手段を疑い、番人は書いてある基準を疑う。全員が「書いてあること」を見ていて、「書いてないこと」を見る係がいない。
——なら、その係を作ったらどうなるのか。ここで実験を 1 つ追加しました。
検証 4: 「書いてないことを見る係」を作ってみた — 3 個中 1 個が見えた
4 役目【完全性の監査役】を設計しました。渡した観点はこうです。「あなたの仕事は、個々の要件の書き方ではなく書かれていないことを探すこと。この文書で繰り返し使われる定型的な表現・要素の組み合わせを自分で抽出し、大多数がセットで書かれているのに一部の要件だけ要素が欠けている箇所を特定する」——例によって、答え (どの対が欠けているか) は一切教えません。
結果、欠落 3 個のうち 1 個が初めて検出されました。「管理 (設定・保持) ができること」——修正を抜いた仕込みです。監査役の検出手順が見事でした。文書中の「管理 (…)」の括弧内を全件集計し、「設定・保持・修正」が 148 件、「設定・保持」が 2 件という分布を自力で割り出して、「148 対 2 の圧倒的多数派からの逸脱。意図的な差別化か記載漏れかの判別が必要」と指摘してきたのです。まさに人間のレビューアーが「あれ、ここだけ修正がない?」と気づくときの思考を、統計でやってのけた形です。
おまけに、この「設定・保持」2 件のうち私が仕込んだのは 1 件だけ。もう 1 件は、元の仕様書に最初からあった実在の逸脱でした (年金特別徴収停止の根拠管理。修正の要否が本当に未規定)。欠落を探す観点を与えたら、仕込みと一緒に本物まで釣れた——観点設計の威力の、意図しない実証です。
ただし残りの 2 個 (個別発行の欠落・宛先ペアの欠落) は、この観点でも見えませんでした。差を分けたのは定型の濃さです。「設定・保持・修正」は 148 対 2 で統計的にくっきり浮く。一方「一括及び個別」は、「一括のみ」の発行要件が元から 6 件あって頻度では浮かない。宛先ペアに至っては、定型がもっと緩い。頻度統計という武器は、ここで弾切れになります。
残り 2 個を追い詰める: 観点の解像度を、答えを教えずに 2 段上げた
ここでやめずに、渡す観点の解像度を段階的に上げて、どこで見えるようになるかを測りました。答え (どの要件のどの語が欠けているか) は最後まで教えていません。
1 段目: 業務有識者の視点を渡す。「帳票名・通知名・対象区分という"名前"で関係する要件同士を突き合わせる」「税務担当者・納税者・事業所それぞれの業務が回るかを確認する」——実務でドメインエキスパートがやるレビューの言語化です。これで宛先ペアの欠落が出ました。検出の論理が見事でした。同じ税額通知書を扱う 3 つの提供方式 (紙・データ・eLTAX) を突き合わせ、「データと eLTAX は義務者用・納税義務者用の両方を対象にしているのに、紙の必須要件だけ納税義務者用が無い」。さらにマスタ管理側に「税額通知 (納税義務者用) の送付形態 (紙/電子)」という要件が実在することまで挙げて、「紙の納税義務者用は制度上想定されているのに、発行を担保する要件が無い」と論証してきた。人間の有識者レビューと同じ筋です。
2 段目: 人間用に作った「対の語チェックリスト」をそのまま渡す。
チェックリストというのは、こういう表のことです (抜粋。全 8 対は note に置きました)。
| 対 | 片方だけだと何が起きるか |
|---|---|
| 一括 ↔ 個別 | 個別対応 (再発行・随時処理) が作られず、運用が回らない |
| 登録/設定 ↔ 修正 ↔ 削除 | 誤登録を直せない・消せない |
| ◯◯用 ↔ △△用 (宛先の対) | 片方の受取人に通知が届かない |
もともとは、人間が Excel の Ctrl+F で「一括」を検索して、ヒットした行に「個別」が並んでいるかを目で見る——そのために私が作った表です。これをそのままプロンプトに貼り、手順を 3 つ指定しました。①各対の語の出現行を全件列挙する。②対の片方だけが書かれた行を候補に挙げる。③候補が全部欠陥とは限らないので、「隣の同種要件はどう書いているか」「その操作が無いと誰がどの場面で困るか」の 2 軸で絞り込む。
AI の仕事ぶりは、実務のレビューそのものでした。「一括」の片落ち候補は、まず 125 件挙がります。そこから 1 件ずつ理由を付けて棄却していく——「この行は直前の主要件が『一括及び個別』を宣言済みで、その対象一覧を書いた補足行」「これは資料の一括取込で、性質上バッチ処理が妥当」。こうして 124 件を消し、最後に残った 1 件をこう特定してきました。「発行系要件で唯一、一括のみ・当初のみの二重片落ち。1 件だけ後から非課税が確定した仮徴収者に個別に還付通知を出す随時運用が想定されるのに、この要件のままでは、その 1 名のために一括バッチを回すか手作業になる」。私が仕込んだ「個別」の削除に加えて、元の文が「当初」に限定されている実在の論点まで拾っています。
これで欠落 3 個、すべて AI が検出したことになります。ただし、2 つ正直に書き添えます。
1 つ目。段階が上がるほど、渡した観点は答えに近づいています。チェックリストには「一括↔個別」というカテゴリが入っている——場所は教えていませんし、125 件から 1 件に絞ったのは AI ですが、「何を対と見なすか」という知識は人間が言語化して渡しました。欠落は AI に見えないのではなく、"観点を言語化して渡せていない欠落"が見えない。これが今回の実験のいちばん深い結論だと思っています。
2 つ目。見つけはしたものの、AI の深刻度評価はどちらも Minor〜Major 止まりでした。私はこの欠落タイプを「機能が丸ごと作られないまま検収を通る、いちばん重いやつ」として仕込みましたが、AI の重み付けはそこまで踏み込まない。「見つける」と「重大だと判定する」は、まだ別の能力です。
業務に翻訳すると、こうなります。対策は 3 段です。「書いてないことを見る係」を観点に入れる (定型の濃い欠落はこれで拾える)。自分のドメインの「対の語」をチェックリストに言語化して、AI にも渡す (人間用の道具は、そのまま AI の観点になります)。そして深刻度の最終判定は人間が持つ。観点を言語化するのも、重さを決めるのも、まだ人間の仕事です。では、前回の設計書と何が違ったのか。並べると、AI レビューの"地図"が見えてきます。
設計書と要件定義書で、何が変わったのか
| 前回 (設計書) | 今回 (要件定義書) | |
|---|---|---|
| 問い | 資料同士が矛盾していないか | 要件単体が「良い要件」か |
| 素朴に頼む | 0% | 25% (浮いた追記だけ) |
| 観点分割 | 86% | 50% (目的一言でも同数まで到達) |
| 欠落 (書いてない欠陥) | — | 3 役では 0/3 → 観点の解像度を上げるたびに 1 個ずつ見え、3 段階で 3/3 |
| 人間に残ったもの | 最後の 1 件の検出 | 観点の言語化と、深刻度の最終判定 |
設計書の欠陥は「存在しない番号への参照」のような構造の痕跡を残すので、照合を頼めば機械的に挙がってきます。要件定義書の欠陥は語彙と観点に依存し、極めつけの「欠落」は、人間がどこまで観点を言語化して渡せるかで見え方が変わる。文書の種類が変わると、AI レビューの得意と死角がここまで動く——同じ手法の使い回しでは測れなかったことです。
明日からやるなら、この 5 行
- 「レビューして」の一言で任せないのは要件定義書でも同じ。ただし目的の一言 (「曖昧な記述とテストできない要件を見て」) だけでも検出は倍になる
- 観点分割は深刻度と深掘りのために使う。曖昧語 / 実装手段の混入 / 検証可能性の 3 役が要件定義書向けの型
- 「書いてないことを見る係」を観点に足す。4 役目 (完全性の監査役) が、定型の濃い欠落を統計で拾ってくれる
- 深い欠落は、自分のドメインの「対の語」をチェックリストに言語化して AI に渡す (一括↔個別、設定↔修正、義務者用↔本人用……)。人間用の道具は、そのまま AI の観点になる。書けない対は AI にも見えない
- 数字を測りたければ、欠陥を仕込んで答え合わせをする。「見つけたものリスト」の長さは検出力の証明にならない
前回の締めで、私は「性能は最初から足りていて、こちらが引き出せていなかっただけ」と書きました。今回、その意味がもう一段はっきりしました。欠落は AI に見えないのではない。"観点を言語化して渡せていない欠落"が見えない。観点を言語化すること、そして見つかったものの重さを決めること——それが、まだ人間の仕事です。
「プロンプトくらい自分で書ける」と思うかもしれません。むしろ書ける人ほど、この 3 役が「答えを一切教えずに欠陥を出させる」ために、どれだけ誘導語を削ってあるかに気づくはずです。観点に "確認して" の一語を混ぜた瞬間、実験は壊れます。その "入れてはいけない一語" のリストごと同梱しました。
この実験で使った道具一式——要件定義書向けの検証済みプロンプト全文 6 種 (3 役 + 完全性の監査役の基本形・業務有識者形・チェックリスト駆動形)、答えを誘導しないための自己チェックリスト、欠落検出の鍵になった「対の語チェックリスト」(8 対 + 自分のドメイン用に増やす作り方)、会社の要件定義書で安全にやるための注意点——は、前回からの note 実践パッケージに追記しました。すでに購入済みの方は、追加のお支払いなしでそのまま読めます (追記が届いています)。
🔍 moname_ai — Claude を本業で使い倒した実測記録を書いています。続きは Bluesky (@moname-ai.bsky.social) で。
この検証の続き: 実測で見つかった点検項目を、月 2 回ほどのメールで配信しています。登録すると、社内文書を AI に読ませる前の点検シートをその場で受け取れます。「自社の文書で実際どこまで測れるのか知りたい」という相談の窓口も、届いた 1 通目のメールでご案内しています → 登録はこちら
Discussion