要件定義書のAIレビューは何から始めればよいですか
設計書をAIに一度読ませて終わりにせず、繰り返し批判させることが精度向上の最初の一歩です。
AIレビューとは、要件定義書や設計書をAIに読ませ、欠陥や前提の誤りを指摘させる工程のことです。当社の実装経験では、新しいツールの設計書をAIに繰り返し反証させてから実装に入る進め方を試しています。
実際に4巡させたところ、指摘の質が巡ごとに変わりました。1巡目は設計そのものが動かないという前提レベルの破綻が出ます。巡を重ねるほど指摘は細かくなり、最終的には境界条件のバグに収束しました。出典は当社の内製ツール開発での実施記録です。
一度読ませて終わりにすると、AIも人と同じように大きな見落としに気づかないまま終わることがあります。繰り返し批判させることで、人が暗黙に置いた前提そのものを疑わせる工程を作れます。
具体的にどう指示を変えながら繰り返すかは、次の見出しで手順として説明します。
AIに設計書を批判させる具体的な手順は
同じ設計書に対してAIへの指示を変えながら、複数回にわたって反証させるという手順で進めます。
- 1巡目は、設計書をそのままAIに渡し、そもそも動作するかどうかを批判させます。所要時間の目安は、設計書の分量にもよりますが30分程度です。
- 2巡目以降は、前の巡で出た指摘を反映した設計書を、再度AIに渡します。つまずきやすい点は、指摘を反映せずに同じ設計書を渡し続け、同じ指摘を繰り返し受けてしまうことです。
- 指摘の粒度が細部に移るまで、この反映と再批判を繰り返します。当社の実施記録では、4巡でこの収束が見られました。
実装者として実際に前提を覆された例を2つ紹介します。1つは、データの識別子を行番号で持つ設計案です。行を1行挿入するだけで以降の識別子がすべてずれると指摘され、構造上の位置で識別子を持つ方式に変更しました。もう1つは、画面の変化を画像のピクセル差分で検知する設計案です。要素が少しずれただけで無関係な差分が大量に出るため、変化を「変更・移動・追加・削除」に分類し、移動は無視する方式に変えました。どちらも実装後に気付いていたら作り直しになる種類の判断です。
指摘がいつ収束したと判断すればよいかは、次の見出しで説明します。
指摘が出なくなったら完了と判断してよいですか
新しい指摘が出なくなり内容が収束したタイミングが、レビューを終える一つの目安になります。
判断基準は指摘の件数ではなく、指摘の中身がどう変わったかです。当社の実施記録では、構造そのものを否定する指摘から、境界条件のような細部の指摘へと質が移ったところで収束しました。指摘が大きな穴から細部へ移ったら、それ以上回しても得るものは減ります。
AIレビューの価値は、正解を出させることではありません。人が暗黙に置いていた前提を、明示的に否定させることにあります。前セクションで紹介した2つの例は、いずれもこの前提の否定によって実装前に方針転換できたものです。
指摘の収束を確認したうえで、AIレビューだけで要件定義の精度として十分かどうかは、次の見出しで説明します。
AIレビューだけで要件定義の精度は十分ですか
抜け漏れの発見には強い一方、業界特有の商習慣や現場の暗黙知の判断は人による確認が必要です。
AIは設計書の内部矛盾や前提の破綻を指摘するのは得意ですが、その業界特有の商習慣を知りません。例えば、特定の業種で当たり前とされる締め日や検収の手順は、資料に明記していない限りAIには分かりません。
| 領域 | 得意な側 |
|---|---|
| 内部矛盾や前提の破綻の発見 | AI |
| 業界特有の商習慣の妥当性 | 人 |
| 現場の暗黙知に基づく判断 | 人 |
| 網羅的な繰り返しレビュー | AI |
AIレビューで構造面の指摘を出し尽くしたうえで、業界知識が必要な部分だけを人が確認する、という役割分担が現実的です。
このように役割分担をすると、専任の要件定義担当者がいない中小企業でも精度を上げやすくなります。次の見出しで、その具体的な場面を説明します。
中小企業の要件定義でAIレビューが特に有効な場面は
専任の要件定義担当者がおらず、レビューできる人が社内に一人しかいない場面で特に効果を発揮します。
IPAは2019年に、中小企業向けの「ストーリーで学ぶ要件定義実践入門」を公開しました。出典はIPAの公開告知ページです。この資料は、要件定義を発注者と受注者が共同で行う上流工程と位置づけています。
本来この共同作業は、社内の担当者同士で設計書を批判的に読み合うことで精度が上がります。しかし専任担当者がいない中小企業では、批判的に読む相手が社内にいない場面が現実には多くあります。
システム開発の外注でよく報告される失敗パターンとして、要件の曖昧さによる仕様変更の多発、丸投げによる進捗の不可視化、検収基準の未合意による納品後トラブルの3つがあります。出典は比較ビズの調査記事です。これらはいずれも、要件定義の段階で誰かが設計書を批判的に読んでいれば防ぎやすい問題です。
社内に一人しかレビューできる人がいない場面で、AIはこの批判的に読む役割の一部を代替できます。
自社での導入が難しい場合の相談先は、次の見出しで説明します。
自社での導入が難しい場合はどうすればよいですか
プロンプト設計から仕組み化まで、実装者に相談する方法もあります。
AIに設計書を批判させるという発想自体は単純ですが、どう指示すれば的確な指摘を引き出せるかにはコツが要ります。指示が曖昧だと、AIは表面的な感想しか返しません。継続的に使うには、ヒアリングから指示文の設計まで仕組み化しておく必要もあります。
当社ノーティックラボの代表は、UC Berkeley Data Science在学のAIエンジニアとして、こうしたプロンプト設計や業務への組み込みを自ら実装しています。コンサルとして考え方を伝えるだけでなく、実際に使える形にするところまで対応できる点が特徴です。要件定義や設計レビューへのAI活用を仕組み化したい場合は、無料診断（/diagnostic）から現状の進め方を伝えることができます。
よくあるご質問
この記事に関して多い質問と回答をまとめます。
AIに設計書をレビューさせる際、どのAIツールを使えばよいですか
長文の設計書を読み込め、対話形式で繰り返し指示できるAIであれば利用できます。特定のツール名を問わず、前述の反証を繰り返す手順が実行できるかを基準に選びます。
何巡くらい繰り返せば十分ですか
前述のとおり、当社の実施記録では4巡で収束しました。ただし設計書の複雑さによって変わるため、巡数そのものより、指摘が細部に移ったかどうかを基準にします。
AIの指摘をすべて反映すべきですか
すべてを反映する必要はありません。業界の商習慣や現場の判断が絡む指摘は、前述のとおり人が妥当性を確認したうえで採否を決めます。
機密情報を含む設計書をAIに読ませても大丈夫ですか
案件により変動します。利用するAIサービスの利用規約で、入力内容が学習等に利用されないかを確認したうえで、機密情報は匿名化するなどの対応をお勧めします。
人によるレビューは不要になりますか
不要にはなりません。前述のとおり、AIは構造面の指摘に強い一方、業界知識や現場の暗黙知が絡む判断は人の確認が必要です。