#生成AI

顧客の仕様書を生成AIに読ませると、どこで読み落とすのか？——要求の抜け・矛盾・暗黙の前提が残る条件と、人が突き合わせる範囲【2026年版】

製造DX編集部

2026年10月23日公開

この記事の要点

顧客の仕様書を生成AIに読ませると、要求の抜け・矛盾・暗黙の前提の約半分は残ると考えて使うのが安全です。AIの指摘は下書きとして扱い、突き合わせは人が行います。
2026年9月公開の研究では、10種の生成AIに要求の品質を評価させたところ、最も成績のよいモデルでも専門家が指摘した問題の検出は中央値47％で、問題のない要求の11％を誤って指摘しました。
見落としが特に多いのは「その要求は本当に必要か」「元の要望を正しく写しているか」のように、案件の背景を知らないと判断できない問題です。
任せてよいのは、要求箇所の洗い出し、表記ゆれや1文に複数の要求が入った箇所の候補出しまでです。要求の妥当性と客先への確認事項は人が決めます。

この記事が支援する判断：受注設計や引合対応を担う設計・営業技術の担当者が、顧客から届いた仕様書を生成AIに読ませるにあたり、「どこまでをAIの読み取りに任せ、どこからを人が突き合わせるか」と「AIの指摘をどう確認するか」を決める場面を支援します。

顧客の仕様書は、本文・図面の注記・別紙・打合せ記録に要求が散らばっており、読み解くのに時間がかかる文書です。生成AIに読ませれば要求の一覧はすぐにできますが、一覧に載らなかった要求や、AIが気づかなかった矛盾は、設計や見積もりの後で表に出ます。結論から言えば、生成AIは仕様書の「拾い出し」には使えますが、「抜けがないことの確認」には使えません。本稿では、公開された研究をもとに、生成AIが読み落としやすい記述と、人が突き合わせる範囲を整理します。

顧客の仕様書を生成AIに読ませると、どこで読み落とすのか？

生成AIが読み落とすのは、文の形から判断できる問題ではなく、案件の背景を知らないと判断できない問題です。米バージニア工科大学などの研究チームが2026年9月にarXivで公開した論文（arXiv:2609.03230）は、OpenAIとAnthropicの2系統・計10種のモデルに、システムズエンジニアリングの国際団体INCOSEの品質基準で要求文を評価させ、専門家の評価と比べました。要旨には次のようにあります。

“the best-performing Anthropic model detects a median of only 47% of expert-identified issues while false-flagging 11%.”（出典：Shefa et al., arXiv:2609.03230 要旨）

品質基準ごとに、生成AIはどこを見落とすのか？

つまり、最も成績のよいモデルでも、専門家が見つけた問題の半分強は見落とし、問題のない要求の約1割を誤って指摘しました。同じ論文は、「必要性」と「正しさ」に関する問題はほぼ常に見落とされ、新しい世代のモデルほど成績がよいとも限らないと報告しています。表1は、論文が使った品質基準のうち、仕様書の読み取りに関係の深いものと、生成AIの傾向をまとめたものです。

品質基準（INCOSE）	仕様書での例	生成AIの傾向（論文の結果）
必要性（その要求は必要か）	前の案件の仕様が残っている	ほぼ常に見落とす
正しさ（元の要望を正しく写しているか）	打合せで変わった条件が反映されていない	ほぼ常に見落とす
あいまいさがないか	「十分な強度」「従来どおり」	見落としは中央値で約半分
完全さ（条件が足りているか）	温度範囲や検査条件が書かれていない	見落としは中央値で約半分・実行ごとのぶれが最大
単一性（1文に1つの要求か）	1文に寸法と材質と納期が入っている	見落としは中央値で約半分

表1：要求の品質基準と、生成AIが読み落としやすい問題。基準と傾向は arXiv:2609.03230 の結果から編集部が整理、仕様書での例は編集部作成

図1　生成AIによる要求の品質評価の結果。最も成績のよいモデルでも、専門家が指摘した問題の半分強が残った（arXiv:2609.03230 をもとに編集部作成）

読み落としが残りやすいのは、どんな記述か？

製造業の顧客仕様書に置き換えると、読み落としが残りやすい記述は3種類に分けられます。1つ目は要求の抜けで、準拠する規格、使用環境の温度や湿度、検査の方法と合否基準など、書かれていないことが問題になる記述です。書かれていない要求は文書の中に手がかりがないため、AIは「抜けている」と判断する材料を持ちません。2つ目は矛盾で、本文と図面の注記、本文と別紙、旧版と新版のように、離れた場所に書かれた条件どうしが食い違う記述です。3つ目は暗黙の前提で、「従来どおり」「前回仕様に準ずる」のように、過去の案件や客先の慣習を知らないと意味が決まらない記述です。部品カタログを生成AIに読ませた過去記事でも、間違いの起きる場所を次のように書きました。

結論から言えば、間違いは「数値そのもの」より「数値に付いている条件」で起きます。
部品選定を生成AIに手伝わせると、どこで間違えるのか？——カタログの定格・注記・型式で取り違えが起きる5つの条件と、任せてよい作業の範囲【2026年版】

チェックリストで抜けを補う方法もありますが、それだけでは足りません。要求抽出の属人化を扱った過去記事では、次のように指摘しています。

チェックリストは有効ですが、あらかじめ用意した既知の観点しか拾えません。客先固有の特殊要求や、記述どうしの矛盾、後から変更された条件は、決まった項目の外側で起きます。
客先の要求仕様書を、毎回ベテランが読み解いている——引合仕様の要求抽出が属人化する構造と、設計OSでそろえられる範囲【2026年】

生成AIに任せる範囲と、人が突き合わせる範囲はどう分けるのか？

任せる範囲は、「AIが見落としたとき、後の工程で気づけるか」で分けます。要求箇所の洗い出しは、漏れがあっても人が原本と突き合わせれば足せます。一方、要求の妥当性や客先への確認事項を任せると、見落としは設計や製作の段階まで残ります。表2は、仕様書の読み取り作業を任せる側と人が担う側に分けた判断表です。

作業	生成AIに任せる	人が行う
要求箇所の洗い出し	本文・注記・別紙から候補を一覧にする	原本と照らして抜けを足す
表記ゆれ・1文に複数の要求	候補を指摘させる	分け方を決める
あいまいな表現	「十分な」「従来どおり」などを拾わせる	具体的な値を決め、客先に確認する
書かれていない条件	任せない	規格・環境・検査の項目を自社の一覧で確認する
本文と図面・別紙の矛盾	同じ項目の記述を並べさせる	どちらが正しいかを客先に確認する

表2：顧客仕様書の読み取りで、生成AIに任せる作業と人が行う作業の判断表（編集部作成）

AIの指摘を先に見ると、人の読み方はどう変わるのか？

注意したいのは、AIの指摘を見ながら読むと、人の見落としが増える場合があることです。イタリア学術研究会議などのチームが2026年8月に公開した実験（arXiv:2608.21298）では、34人が要求文書の問題を探す作業を、LLMの支援がある場合とない場合で比べました。その結果、LLMの支援は問題の検出の正確さを下げ、作業時間には有意な差が出ませんでした（出典：Broccia et al., arXiv:2608.21298 要旨）。参加者は経験の浅い点検者で、論文は、最初からLLMの支援付きで学ぶと点検の技能が身につくのが遅れる可能性も指摘しています。AIの一覧を先に見るのではなく、人が原本を読んだ後でAIの指摘と照らす順番にすると、AIに引きずられにくくなります。

図2　顧客仕様書を生成AIと人で読む順番。人が先に原本を読み、その後でAIの一覧と照らす〔概念図〕

生成AIに仕様書を読ませるのが向かないのは、どんなときか？

次の条件に当てはまる場合は、生成AIに仕様書を読ませても照合の手間が減らないか、見落としの影響が大きすぎます。AIを使う前に、仕様書の渡し方や社内の確認の仕組みを整えるほうが先です。仕様書が表や帳票の形で届く場合は、読ませる前の整え方も効いてきます。Excel帳票を扱った過去記事では、次のように整理しました。

すべての帳票を完璧に直してから渡す必要はありません。判断の分かれ目は、崩れている箇所の数と、同じ様式を何回読ませるかです。
Excel帳票を生成AIに読ませると何がずれるのか？——読み違いを招く7つの作りと、渡す前に直す範囲・渡してはいけないブックの条件【2026年版】

向かない条件	理由	先にやること
安全や法規に関わる要求が中心	見落としの影響が大きく、全件を人が確認することになる	人の確認手順を先に決める
要求の多くが打合せや口頭で決まっている	文書にない条件はAIが読めない	打合せ記録を残し、仕様書に反映する
旧版と新版が混ざっている	どちらの条件か分からないまま一覧ができる	最新版だけを渡し、版と日付を記録する
原本を読める担当者がいない	AIの指摘の正誤を誰も確かめられない	経験者が照合する体制をつくる
顧客との契約で外部サービスへの入力が制限されている	仕様書を渡すこと自体ができない	契約と社内規程を確認する

表3：顧客仕様書を生成AIに読ませるのが向かない5つの条件と、先にやること（編集部作成）

よくある質問（FAQ）

生成AIに仕様書の要求一覧を作らせれば、抜けはなくなりますか？

なくなりません。公開された研究では、最も成績のよいモデルでも専門家が指摘した問題の検出は中央値47％でした。特に、書かれていない条件や、案件の背景を知らないと判断できない問題は残ります。一覧は下書きとして使い、原本との突き合わせは人が行ってください。

新しいモデルを使えば、読み落としは減りますか？

減るとは限りません。2026年9月公開の研究では、同じ系統のモデルでも世代が新しいほど成績がよいとは限らないと報告されています。モデルを替えたときは、過去の案件の仕様書で読み落としの傾向を確かめてから使うのが安全です。

生成AIの指摘は、どの順番で確認すればよいですか？

人が先に原本を読んで要求と疑問点を書き出し、その後でAIの一覧と照らす順番がおすすめです。AIの一覧を先に見ると、その内容に引きずられて人の見落としが増える場合があることが、2026年8月公開の実験で報告されています。

まとめ

顧客の仕様書を生成AIに読ませると、要求の抜け・矛盾・暗黙の前提の約半分は残ると考えて使うのが安全です。公開された研究では、最も成績のよいモデルでも専門家が指摘した問題の検出は中央値47％で、要求の必要性や正しさに関する問題はほぼ常に見落とされました。任せてよいのは要求箇所の洗い出しと表記ゆれの候補出しまでで、書かれていない条件の確認と、客先への質問は人が担います。人が先に原本を読み、その後でAIの一覧と照らす順番にしてください。

次に読みたい関連記事

出典・参考

Jannatul Shefa, Alejandro Salado, Paul Wach, Taylan G. Topcu「Two Truths and A Lie? Benchmarking off-the-shelf LLMs for Requirements Quality Assessment – Performance, False Alarms, and Misses」（arXiv:2609.03230・2026年9月。要旨と第4章を2026年10月22日に原文で確認）
Giovanna Broccia, Julian Frattini ほか「Human-AI Collaboration in Requirements Engineering: Evidence of the Negative Effect of LLMs on Requirements Inspection」（arXiv:2608.21298・2026年8月。要旨を2026年10月22日に原文で確認）

仕様書・FMEA・是正処置・見積書・各種ログなど、製造業の帳票を様式のまま構造化し、生成AIで起案・確認できる状態にする仕組みは、SPESILLの紹介ページで確認できます。帳票と技術文書を生成AIで扱える状態にする「SPESILL」の仕組みを見る