建築要望の整理にAIを使う｜条件の抜けを確認

要求整理AIは要望を設計条件に確定する道具ではない

初回相談の発言には、「会議室がほしい」という希望と、「同時に12人が使う」という利用条件と、「消防法上必要だと思う」という顧客の推測が混ざります。AIは発言を表へ並べ、足りない項目を質問候補にする作業を助けます。一方で、敷地、法規、構造、設備、予算との整合を確認して要求を確定するのは設計者の仕事です。

設計事務所のAI活用ガイドは利用場面全体を扱います。ここでは、ヒアリング記録から要求表を作り、次回質問へつなぐ一工程だけを扱います。

入力は原発言と既知条件を分ける

AIへ渡す前に、相談メモを整った文章へ書き換えません。先に整文すると、誰の発言か、どの程度強い要望かが消えるためです。発言者、時刻またはメモ行、原文を残し、その横に既知条件を置きます。

氏名、住所、地番、未公開計画などは、利用するAIサービスへ入力してよいかを確認します。不要な識別情報は案件番号へ置き換えます。匿名化と権限の手順はAI情報管理を参照します。

出力は六つの欄を持つ要求表にする

文章の要約だけでは、検討に必要な抜けが見えません。要求ごとに根拠、強さ、確認状態を持つ表へします。

「必須」と「希望」はAIに判定させず、原発言に明示がある場合だけ仮分類します。「できれば」「絶対に必要」といった表現も、顧客の真意を次回確認します。要望を決定へ変えないことが最初の品質条件です。

匿名条件を使ったプロンプト例

以下の相談メモだけを根拠に要求候補を整理してください。出力列は、要求ID、原発言、利用場面、必須か希望か、根拠行、未確認事項、次回質問です。原文に強さが書かれていない場合は「未確認」とし、法規、面積、人数、予算を推測しないでください。設計側の仮定は要求へ混ぜず、別表にしてください。

入力例には「案件S、来客は執務室を通さず会議室へ案内したい。同時来客数は記載なし」のように識別情報を外した条件を使います。AIが「専用廊下が必要」と出した場合、それは原発言ではなく手段の提案です。要求は「執務室を通らない来客動線」として残し、手段を固定しません。

抜けの確認は質問の優先度で行う

AIに「不足を全部挙げて」と頼むと、案件に関係の薄い一般質問が大量に出ます。次の提案を変える情報から順に、質問数を絞ります。

1. 計画の目的と次回判断を確認します。
2. 利用者、人数、時間帯、行為を確認します。
3. 必須条件と調整できる条件を分けます。
4. 敷地、既存建物、予算、時期の資料有無を確認します。
5. 意思決定者と承認手順を確認します。
6. 回答が得られない条件は仮定と影響を記録します。

質問には「なぜ聞くか」を添えます。たとえば「最大同時利用人数を教えてください。面積配分と避難、設備検討の前提をそろえるためです」と書けば、単なる質問票になりません。法規や技術判断は、関係資料と有資格者の確認へ渡します。

要求同士の衝突を見つける

AIが役立つのは、正解を出すことより、同時に満たしにくい条件を並べることです。「来客動線を分離」「受付面積は最小」「執務席数は維持」のような要求を、影響する面積、費用、運用と一緒に表示します。衝突を勝手に解消させず、選択が必要な論点として顧客へ返します。

相反する要望は勝手に優先しない

たとえば「受付から来訪者が分かるようにしたい」と「執務席を来訪者から見えないようにしたい」は、同時に満たせないと即断する条件でも、AIが一方を選ぶ条件でもありません。要求IDを分け、それぞれの発言者、目的、必須度、対象時間帯を確認します。そのうえで「受付担当の視認性は必要だが、執務席への視線は遮る」など、両立条件の候補を設計者が検討します。要求表には未解決の衝突として残し、面積、動線、運用、費用への影響候補を添えます。次回は「誰がどこから何を確認できればよいか」「見せたくない対象は何か」と質問し、案を見せる前に判断基準を確かめます。

人が確認する五段階

まず原発言が欠落していないか見ます。次に、事実と推定が別欄か確認します。三つ目に、必須と希望の強さを発言者へ戻って確かめます。四つ目に、面積、数量、日付、予算を資料と照合します。最後に、要求が設計手段へ置き換わっていないか確認します。

設計手段へ早く置き換えると、別案を検討しにくくなります。「北側に倉庫を置く」は、顧客の指定なのか、「搬入口から短く運べる」が本来の要求なのかを分けます。要求表の承認後に、間取りAIの初期提案など次の検討へ渡します。

失敗時は分類規則へ戻る

AIが一般論を大量に追加した場合は、出力を削るだけでなく「根拠行がない項目は出さない」と指示を直します。必須と希望を混同した場合は、強さの判定をAIから外し、すべて未確認で出させます。同じ要望が重複した場合は、統合前後の原発言IDを残し、意味の違いを人が確認します。

長い相談メモを一度に処理して抜けた場合は、議題単位に分け、最後に要求IDで統合します。出力が読みやすくても、根拠へ戻れない項目は採用しません。

よくある質問

AIに優先順位を付けてもらえますか

原発言に明示された優先度の整理はできますが、顧客の代わりに順位を決めることはできません。衝突する要求と影響を示し、顧客へ確認します。

要望と要求はどう分けますか

要望は顧客の希望を含む広い表現です。要求表では、誰が、何のために、どの条件を必要とするかを確認可能な形へします。未確認なら無理に要求へ確定しません。

AIが挙げた法規条件を使えますか

確認項目の候補にはできますが、適用法令や法適合の判断には使いません。所在地、用途、規模、最新資料を基に担当者が確認します。

相談メモが短くても使う意味はありますか

あります。短い記録ほど、書かれていない項目を見える化しやすくなります。ただし、一般的な質問を増やすだけでなく、次の判断を変える質問に絞ります。

要求表はいつ顧客へ確認しますか

初回整理後と、条件が大きく変わった時点で確認します。設計案を見せた後だけでは、案から逆算した要求に書き換わるおそれがあります。

参考資料

• Microsoft：Copilot in Wordで参照資料から下書きを作る方法
• IPA：テキスト生成AIの導入・運用ガイドライン

関連記事

• 建築ヒアリングシート
• 間取りAIの入力条件
• 初回相談から提案までの進め方