はじめに

設計レビューでAIを使う現場が増えてきました。設計書ファイルをAIに読み込ませてレビューさせれば、Nullチェック漏れやElse分岐の考慮漏れといった単純な誤りは、かなり精度よく検出できます。

一方で、複数のドキュメントを突き合わせないと分からない不整合は、AIレビューであっても簡単には解決しません。この記事では、設計段階の誤りを2種類に分類した上で、なぜ後者がAIでも難しいのか、そしてどう対処すべきかを整理します。

前提として、以下の環境を想定しています。

ウォーターフォールでの開発
各種ドキュメントは Word / Excel / PowerPoint などのOffice系ファイルで作成
AIは業務利用できる環境（ファイルを読み込ませる、Excel上でCopilot/Claudeを使うなど、2026年7月時点で一般的な使い方ができる前提）

設計段階の誤りを2種類に分類する

設計レビューで見逃される誤りは、大きく2つに分けられます。

分類	内容	例
1. プログラムとしての考慮不足	設計書1ファイルの中だけで指摘できる誤り	Nullチェック漏れ、IF文のElseパターン考慮漏れ
2. 他ドキュメントとの不整合	複数ドキュメントを突き合わせて初めて分かる誤り	テーブル名・カラム名・データ型・業務用語の表記揺れや認識誤り

この2つの違いは誤りの種類だけでなく、
「1ファイルで完結するか、複数ファイルの突き合わせが必要か」
という点にあります。この違いが、AIレビューのしやすさに直結します。

設計段階で見つからなかったこれらの誤りは、開発段階でも気付かれず、単体試験でも気付かれず、
結合試験でようやく発覚
というケースが多々あります。フェーズが進んでから発覚すると、設計書修正・プログラム修正・単体試験のテストケース追加・再試験と、手戻りコストが跳ね上がります。

誤り1「考慮不足」はAIレビューでほぼ解決する

1つ目の「プログラムとしての考慮不足」は、設計書ファイル自体をAIに読み込ませて一定のルールでレビューさせれば、かなり正確な結果が得られます。

Excelファイルで設計書が作成されているケースが多いですが、Excelのセル内容をAIに読み込ませることも、Excel上でCopilotやClaudeを使うことも可能です。

ポイントは、このタイプの誤りはそのファイル単体で完結していることです。AIに渡すべき情報が「レビュー対象の設計書」だけで済むため、材料の準備で悩む余地がなく、AIの得意分野がそのまま活きます。

誤り2「ドキュメント間の不整合」がAIでも難しい理由

2つ目の「他ドキュメントとの不整合」は一見単純に思えますが、AIが進化してもなお対応が難しく、仕組みとしての解決策を考える必要があります。

具体例

処理Aの設計書とテーブル仕様書の不整合
処理Aの設計書内でテーブルAのカラムを使っているが、想定している型とテーブル仕様書に記載の型が異なる。単体試験でようやく気付くパターン。
処理Aと処理Bの設計書の不整合
処理Aから処理Bを呼び出す際、処理Aが渡す引数の想定と処理B側の想定が食い違う。単体試験でも気付けず、結合試験でようやく発覚する典型パターン。

なぜAIでも難しいのか

理由は、レビュー時にAIへ渡すべき情報が、開発規模に応じて増え続けることです。

上記のようなシンプルな例であっても、実際には次のように関連資料が芋づる式に増えていきます。

要件を満たしているか確認するには要件定義書も必要
要件定義書に記載はないが、先日の打ち合わせでこの資料を正とすることになった → 議事録も必要
処理Aには明記されていないが、共通処理を使用している → その共通処理の設計書も必要

そして何より問題なのは、AIは「渡されなかった資料」の存在に気付けないということです。材料が不足したままレビューさせても、AIは見えていない矛盾を指摘できず、「問題ありません」という結果だけが返ってきます。

つまり、AIに渡すべき情報の精査ができていないと、不十分なレビューが「OK」と判定されてしまうのです。これはレビューを実施していない状態より、ある意味たちが悪い結果を招きます。

人間が確認する場合の限界

AIに任せられないなら人間が確認することになりますが、これもまた簡単ではありません。

理想を言えば、設計書を作成する時点で関連するドキュメントを逐一検索し、内容を突き合わせて確認できれば誤りは防げます。しかし規模がある程度大きいプロジェクトでは、関連しそうなExcelやWordのファイルを必要なだけ開き、それぞれのファイルの中で個別に検索をかけて内容を確認する、という作業がとにかく面倒です。ファイルを開く手間、検索窓を開く手間、ヒットした箇所を目で追って照合する手間が、関連ファイルの数だけ積み重なっていきます。

この面倒さが積み重なった結果、往々にして起きるのが「たぶんこうだったはず」と記憶を頼りにしてしまい、本来やるべき確認を怠ることです。そして、その省略した確認の先に不整合があった場合、それがそのまま設計書の不備として残ってしまいます。つまり、色々な場所に散らばった情報を記憶を頼りに探したり、大量のExcel/Wordファイルを画面上に並べて突き合わせたりする作業には限界があり、そもそもそれが完璧にできていないからこそ、設計レビューをすり抜ける誤りが発生しているのです。

つまりこの問題のボトルネックは、
AIのレビュー能力でも、レビューアの能力でもなく、「レビューの材料を漏れなく集めること」
にあります。

解決アプローチ: 「材料集め」を機械化する

ここから導かれるのは、次のような仕組みです。

関連ワードで機械的に検索して必要ファイルを洗い出し、それらをAIに読み込ませてレビューさせる

例えば処理Aの設計書をレビューするなら、そこに登場するテーブル名・処理名・業務用語でドキュメントフォルダ全体を機械的に検索し、ヒットしたファイルを漏れなくAIに渡してからレビューさせます。人の記憶ではなく検索で材料を洗い出すことで、「渡し忘れた資料との矛盾が見逃される」というリスクを大きく減らせます。

この仕組みの弱点

正直に弱点も書いておきます。検索でヒットしたファイルが大量になると、その全てをAIに読み込ませるのは、AIが一度に扱える情報量やコストの面で現実的ではなくなります。

そのため実際には、ヒットした一覧から必要な情報に絞り込みながら段階的に読み取る、というやり方が必要になります。この「どれを深く読むか」という判断は、結局AIに依存する部分として残ります。「材料の洗い出し」までは機械的にできても、「材料の取捨選択」まで完全に機械化できるわけではない、という点は認識しておく必要があります。

まとめ

設計段階の誤りは「1ファイルで完結する考慮不足」と「複数ドキュメントの突き合わせが必要な不整合」の2種類に分けられる
前者はAIレビューでほぼ解決に向かうが、後者は「AIに渡すべき材料が開発規模に応じて増え続ける」ため難しい
AIは「渡されなかった資料」の存在に気付けないため、材料不足のまま「問題なし」と判定されるリスクがある
ボトルネックはAIやレビューアの能力ではなく「レビューの材料を漏れなく集めること」
関連ワードでの機械的な検索によって材料集めを機械化するアプローチが有効。ただし、大量ヒット時の絞り込み判断はAI依存のまま残る

この「機械的に検索して材料を集め、AIに渡す」仕組みは、筆者が個人開発したローカル全文検索ツール OmniGrep で実現できます。Excel・Word・PDFなどOffice系ファイルの中身まで横断検索でき、MCPサーバー機能によりClaude等のAIと接続して「このキーワードに関連するファイルを探して読んで」という使い方が可能です。

具体的な検索の連鎖をAIに自動実行させる方法は、以下の記事で紹介しています。

最後まで読んでいただきありがとうございました。「うちの現場ではこうやってレビューの精度を上げている」といった事例があれば、ぜひコメントで教えてください。