はじめに
「軽くしてほしい」「できるだけ丈夫にしたい」「コストは抑えたい」「今までより使いやすくしてほしい」。
製造業や建設業、システム開発などの現場では、顧客の要望が最初から明確な数値や設計条件として提示されるとは限りません。
むしろ実際の仕事では、会話、メール、議事録、仕様書、図面、過去案件などに情報が分散し、それを営業担当者、設計者、技術者が読み解きながら「何を満たせばよいのか」を定義していきます。
この工程は、製品やシステムの品質を左右する極めて重要な作業です。一方で、担当者の経験や知識に依存しやすく、解釈の違いや確認漏れが後工程の設計変更や手戻りにつながることがあります。
そこで注目されているのが、生成AIを単なる文章作成ツールとしてではなく、**「人の言葉を設計条件へ翻訳する仕組み」**として利用する考え方です。
添付資料でも、自然言語からシステムモデルや設計条件への変換、要件品質の自動チェック、GraphRAGによる根拠管理、人間による最終確認までを組み合わせたアプローチが整理されています。特に建設、製造、化学、ソフトウェアなど、複数の産業で実装が進み始めている点が重要です。
なぜ「顧客要望から設計条件への変換」が難しいのか
顧客の言葉と設計者が必要とする情報には、大きな隔たりがあります。
例えば顧客から、
「できるだけ軽くて丈夫な製品にしてほしい」
という要望があったとします。
設計者が必要なのは、その言葉そのものではありません。
- 目標重量はいくらか
- どの程度の荷重に耐える必要があるか
- 使用環境は屋内か屋外か
- 想定耐用年数はどの程度か
- 製造コストの上限はいくらか
- 軽量化と耐久性のどちらを優先するのか
といった、具体的な条件です。
つまり、
顧客の言葉 → 要求 → 制約条件 → 設計条件 → 検証条件
という変換が必要になります。
従来、この作業の多くを経験豊富な営業担当者や設計者が担ってきました。
生成AIが期待されているのは、この専門家を置き換えることではありません。大量の情報から要求候補を抽出し、不明確な部分や矛盾を見つけ、人間が判断しやすい状態へ整理することです。
AIは顧客の言葉をどうやって設計条件へ変えるのか
今後の要件定義AIは、「顧客の文章をAIに入れて答えを出してもらう」という単純な仕組みではありません。
複数の処理を組み合わせることが重要になります。
顧客要望から要求事項を抽出する
最初の段階では、商談記録、メール、ヒアリング議事録、提案依頼書などから要求を抽出します。
例えば、
「高齢者でも簡単に操作できるようにしたい」
という発言であれば、AIはそのまま設計条件に決定するのではなく、
「操作手順」「表示サイズ」「入力方法」「誤操作防止」「アクセシビリティ」
など、追加確認が必要な項目へ分解します。
ここで重要なのは、AIが数値を勝手に決めないことです。
不明な条件については「確認事項」として人間へ戻す設計が必要です。
曖昧さや矛盾を検出する
要件定義では、
「高速に処理してほしい」
「操作しやすくしてほしい」
「できるだけ安くしてほしい」
といった曖昧表現が頻繁に登場します。
AIを使えば、「高速とは何秒以内なのか」「誰にとって使いやすいのか」といった確認事項を抽出できます。
さらに、
「最高性能を求める一方で最低コストを要求している」
など、複数の要求間に存在するトレードオフを整理することも可能になります。
添付資料では、INCOSEの要求記述ルールやEARSなどを利用し、要件の曖昧さ、完全性、検証可能性などをAIで確認するアプローチが紹介されています。
要求品質の評価にLLMと自然言語処理を組み合わせる研究も進められています。
自然言語とSysMLをAIがつなぐ可能性
さらに重要なのがMBSE（Model-Based Systems Engineering）との接続です。
これまで要件定義の多くはWordやExcelなどの文書として管理されてきました。
しかし製品や設備、ソフトウェアが複雑になると、
「この顧客要件が、どの機能、部品、設計値、試験項目につながっているのか」
を追跡する必要があります。
そこで利用されるのがSysMLなどのシステムモデリング言語です。
OMGが策定するSysML v2は、要求、構造、動作、解析、検証などを一貫して扱える仕組みを持ち、テキスト記法や標準APIも備えています。2025年にはSysML v2が正式採用され、AIや自動化との接続に適した環境が整ってきました。
将来的には、
顧客との会話
↓
AIによる要求抽出
↓
構造化された要件
↓
SysMLモデル
↓
設計条件
↓
シミュレーション・検証
という流れが、より連続的になる可能性があります。
これは単なる文書作成の効率化ではありません。
設計プロセスそのもののデジタル化です。
RAGとGraphRAGが「根拠のある設計」を支える
生成AIだけに要件判断を任せると、大きな問題があります。
ハルシネーションです。
AIがもっともらしい内容を生成しても、それが自社基準や法令、過去案件に基づいているとは限りません。
そこで重要になるのがRAGです。
AIが回答する前に、
- 過去の設計仕様書
- 社内技術基準
- 法令・条例
- 類似案件
- 不具合記録
- 顧客との過去の合意事項
などを検索し、それを根拠として回答させます。
さらにGraphRAGでは、単なる文章検索だけでなく、
「顧客要求」
「設計条件」
「部品」
「法規」
「試験項目」
「過去案件」
といった情報同士の関係をグラフとして扱います。
Microsoft ResearchもGraphRAGを、テキスト抽出、ネットワーク分析、LLMを組み合わせてデータ集合を理解する手法として公開しています。
設計業務では、この「情報同士の関係」が非常に重要です。
建設業ではすでに「要件整理AI」が実務段階へ
この動きは研究だけの話ではありません。
特に建設業では実際の業務への導入が急速に進んでいます。
大林組は2026年8月19日、設計初期段階における法令調査・要件整理業務へ生成AIを適用した検証結果を発表しました。
法令データだけでなく、社内に蓄積された過去の法令解釈や設計検証の知見をAIエージェントのナレッジとして利用し、設計初期に確認すべき論点や留意事項を根拠資料とともに提示する仕組みです。
検証では、法令調査・要件整理にかかる時間が平均4.3時間／週／人から1.4時間へ短縮され、約67％の削減となったと報告されています。
まさに、
大量の情報から必要な条件を抽出し、設計者の判断材料へ変換する
という活用です。
過去の図面や設計知識もAIが「使えるデータ」に変える
竹中工務店では、Tektomeの「KnowledgeBuilder」を試行導入しています。
図面、議事録、画像、朱書きなど、これまでフォルダの中に埋もれていた設計情報をAIで抽出・構造化し、自然言語で検索できるデータベースへ変換する仕組みです。
これは要件定義AIを考えるうえで重要なポイントです。
AIが顧客要望を設計条件へ変換するには、一般知識だけでは足りません。
「この会社では過去にどう設計したのか」
「同じ顧客では何を重要視したのか」
「過去にどの条件で不具合が起きたのか」
という企業独自のナレッジが必要だからです。
したがって、要件定義AIの競争力はAIモデルの性能だけではなく、企業が持つ設計データや技術知識をどれだけ構造化できるかによって左右される可能性があります。
AIを入れれば自動的に要件定義できるわけではない
一方で、生成AIに顧客とのヒアリング記録を読み込ませるだけでは、実務に耐える要件定義システムにはなりません。
最低限、次の仕組みが必要です。
要件の形式を決める
例えば、
「要求内容」「理由」「制約」「優先度」「根拠資料」「確認者」「検証方法」
など、AIが出力すべき項目をあらかじめ設計します。
根拠データと接続する
RAGなどを使い、社内標準、過去設計、法規、マニュアルなどを参照できるようにします。
人間が承認する
AIが作成した設計条件を、そのまま正式要件にしてはいけません。
特に安全性、法令、品質、契約、コストなどに影響する事項では、専門家による確認が不可欠です。
これがHuman-in-the-Loop（HITL）の考え方です。
AIの判断履歴を残す
「どの顧客発言から、この要件が作られたのか」
「どの資料を根拠にしたのか」
「誰が承認したのか」
を追跡できるようにします。
設計変更が発生したときにも、このトレーサビリティが重要になります。
企業が最初に取り組むなら「全部自動化」ではなく一工程から
中小企業を含め、多くの企業にとって現実的なのは、設計工程全体を一気にAI化することではありません。
例えば、
顧客ヒアリング → 要件一覧作成
だけをAIで支援するところから始める方法があります。
次に、
要件一覧 → 過去案件検索
へ広げます。
さらに、
要件 → 設計条件 → 見積条件 → 検証項目
へ接続していく。
この順序であれば、AIの精度を確認しながら段階的に適用範囲を広げられます。
効果測定についても、「AIを何回使ったか」では不十分です。
見るべきなのは、
- 要件整理にかかった時間
- 確認漏れ件数
- 設計変更・手戻り
- 顧客への確認回数
- 類似案件検索時間
- 要件と設計のトレーサビリティ
といった業務指標です。
まとめ
生成AIの産業利用は、「文章を書くAI」から次の段階へ進み始めています。
その一つが、顧客の曖昧な要望を、設計者が扱える構造化された条件へ変換するAIです。
自然言語処理、SysML v2、RAG、GraphRAG、AIエージェント、LLMOps、HITLなどを組み合わせることで、
顧客の言葉
→ 要求
→ 設計条件
→ 根拠
→ 検証
をつなぐ仕組みが現実味を帯びてきました。
重要なのは、AIに設計判断を丸投げすることではありません。
AIに「抽出・整理・照合・不足の発見」を担当させ、人間が「判断・合意・責任」を担うことです。
この役割分担ができれば、AIは単なる業務効率化ツールではなく、営業・設計・製造をつなぐ新しい業務基盤になり得ます。
そして企業にとって本当に価値を持つのは、汎用AIそのものではなく、そこへ接続される自社の設計知識、過去案件、技術基準、顧客との合意履歴です。
顧客の声を「設計可能なデータ」へ変えること。
そこが、これからの産業AI活用における重要なテーマの一つになるでしょう。
※本記事は添付調査資料「顧客要望を設計条件へ変換するAI活用の可能性と産業実装の最前線」を基礎資料とし、2026年8月時点の公開情報を補足して構成しています。
コメント