建築確認の審査をAIで支援できないか、という話が来たとき、最初にやったのは「できること」の説明ではありませんでした。
「精度100%は約束できません。PoC（試作）の範囲で、狭い場所から確認していきましょう」と先に言いました。
審査という仕事の構造
指定確認検査機関が建築士の提出する図面を審査するとき、チェックしていることはざっくり2種類あります。「この数値は建築基準法の要件を満たしているか」という計算系と、「書類の記載が漏れていないか、前ページとの整合がとれているか」という確認系です。
前者は面積・高さ・用途地域といった数値を拾って、法令上の基準と突き合わせる作業です。計算自体は複雑でなくても、拾う量が多く、人が繰り返す部分が多い。後者は「この欄が空欄になっている」「前の図面ではAと書いてあるのに、ここではBになっている」という類の照合です。
どちらも、AIが得意そうに見えます。実際、PoC段階では試した部分があります。数値を図面から取り出して基準と照合する流れや、過去の審査事例をRAGで参照する仕掛けです。
動いた部分はあります。でも「審査員が最終確認なしに使える」レベルには、まだ届きません。
先に言っておかないと、あとで困る
規制業界でAIを入れるとき、一番事故りやすいのは「導入してみたら精度が足りなかった」ではなく、「最初から期待値が合っていなかった」ケースです。
AIを入れようとする側は、どうしても「これで手作業が全部なくなる」を前提に考えます。それを最初に崩しておかないと、後から「なぜ全件チェックしてくれないのか」という話になります。
私はこのテーマを受ける前に、整理してから持っていきました。
審査支援として最初に試せる範囲:
- 図面の数値（面積・高さ・用途地域）を取り出して、基準法の数値要件と照合する
- 書類の記載漏れと、書類間の整合性チェック
- 過去の類似事例をAIに参照させて、参考情報として出す
最初から言っておきたいこと:
- 精度100%は約束しない。読み取り誤りや見落としは出ます
- 「AIが確認したから合格」という使い方はNG。確認補助として使う前提で
- 要件定義は軽くない。審査のルールと例外を整理する作業に、最初に時間がかかります
- まず狭い範囲でPoCをやって、使えると判断してから広げる順序でいきましょう
この4点目、「狭いPoCから広げる」は結局どのAI案件でも言うことですが、規制業界では特に守った方がいいと思っています。ミスの影響範囲が違うからです。
「要件定義が重い」は本当
建築基準法の数値要件は、用途地域・建物の用途・延床面積によって適用条件が変わります。同じ「高さ制限」でも、第一種低層住居専用地域と商業地域では話が違う。図面1枚を審査するためのルールが、実はかなり多い。
これをAIが参照する形にするには、どのルールをどの形で持たせるかの整理が要ります。法令の条文をそのまま突っ込んでも、期待どおりに動かない場面が出てきます。
AIへの頼み方でいうと、こんな感じで試しました。
建築基準法の容積率に関する要件を、用途地域別に整理して。条文番号ではなく「第一種住居地域では〇〇m²以下の場合、制限値は何%か」という実務で引ける形に直して
法令の構造を「実務で使える形」に変換する作業が要るわけで、ここが「要件定義は重い」と先に言った理由です。AIが知識を持っているかどうかより、その知識をどう整理して渡すかの設計が先に来ます。
結局うまくいく理由
「できないことを先に言う」は、正直にやっているだけで戦略ではありません。ただ、結果として話が進みやすいのは事実です。
なぜかというと、期待を下げて入ると「これだけ動いた」が素直に評価されます。最初から「全部解決」で入ると、部分的に動いても「まだここができてない」ばかり出てきます。
規制業界のAI案件は、最初の期待値設定で半分が決まる気がしています。
精度が出るかどうかは試してみないと分かりません。でも「最初から制約を全部出す」かどうかは、受ける前に決められます。私は後者だけ必ず守るようにしています。