ディベロッパーでのAI活用術

ディベロッパーに、そもそもAIは必要なのか

ディベロッパーでAIを入れる価値が出るかどうかは、二つの軸で見分けられます。一つは、同じ判断を月に何回繰り返しているか。もう一つは、その判断を誤ったときに何が起きるかです。この二つがどちらも大きい業務ほど、仕組みとして組み込む値打ちが出ます。ディベロッパーのAI活用も、この順で見ていきます。

一つの物件に法令・条例・契約の要件が幾重にも重なるのが、この仕事の特徴です。AIが効くのは、次のような業務です。

• 重要事項説明書と契約書類の記載の点検
• 開発許可や建築確認の申請書類が、要件を満たしているかの下調べ
• 施工会社から届く進捗報告と、当初の工程表との突き合わせ

いずれも 照らし合わせるものさしが法令と社内の様式にある 作業です。

一方、地権者との条件交渉と、住戸プランや外観の意匠の決定には入れないほうがよいと考えます。交渉は相続の事情や近隣との関係を聞き取りながら条件を組み替える仕事で、判断の基準が事前に決まりません。意匠の決定は、その立地でどう暮らしてもらうかという 問いの立て方そのもの だからです。

ただ、この線引きは業務ごとに変わります。同じ近隣対応でも、説明会の場でのやりとりと、協議記録の整理とでは向き不向きが分かれます。次のセクションでは、ディベロッパーの業務を工程に分けて見ていきます。

用地仕入れから販売・引渡しまで、負荷が大きいのはどの工程か

ディベロッパーの業務は、一つの土地が建物になって買主に届くまでを一本の線でたどれます。ただし販売は施工と並んで進むため、その時期だけは重なります。工程に分けると、決まった様式に照らす作業と、相手を見て決める作業がはっきり分かれます。

負荷が最も集中するのは 販売・引渡し です。分譲では買主が多数にのぼり、重要事項説明書は一件ごとに宅地建物取引士が記名して説明の責任を負います。記載を一つ落とせば、入居後に契約の効力そのものが問われます。

担当者は、物件ごとに違う法令上の制限を役所の窓口で一つずつ確かめ、上下水道やガスの引込み状況を事業者に照会し、管理規約の案や修繕積立金の設定と突き合わせます。さらに近隣で進む別の計画の有無まで拾い、それを所定の様式に書き移します。

同じ分譲でも、敷地にかかる条例と近隣の状況が違えば調べる項目が入れ替わるため、 前の物件の写しが使えません 。ここに手を入れると、担当者は書き移しではなく、買主に伝わる説明の組み立てに時間を使えます。前工程の許認可や近隣調整も、後で説明書に載せる事項をその場で記録に残す形に整っていきます。

極小とした設計・仕様の詰めは、同じ広さの土地でも、日当たりや前面道路、周辺の住まい方によって答えが変わる工程です。過去の住戸プランは参考になりますが、何を良しとするかがその都度動くため、決定そのものを任せられません。

ディベロッパーで最初に取り組むべきAI活用、3つ

最初に手をつけるのは、同じ点検が繰り返し起きていて、かつ落とすと引渡しや着工が止まる業務です。第1セクションの二つの軸で見ると、重要事項説明書と契約書類の点検、許認可申請書類の記載確認、環境認証の要件整理がここに当たります。

重要事項説明書の記載漏れを、先に洗い出す

起点は、説明書の原稿が案件フォルダに保存された時点です。

AIは原稿を読み取り、宅地建物取引業法で定められた記載事項の一覧、その敷地にかかる法令上の制限の調査結果、管理規約の案、過去の物件で指摘を受けた箇所の記録を照らし合わせ、埋まっていない項目と根拠資料が付いていない項目を並べた点検表を組み立てます。

点検表は案件フォルダに文書として保存され、販売担当と法務に業務チャットで通知が届きます。これまでは原稿を頭から読み下して確かめていましたが、 未記載の項目が並んだ状態 から中身の検討に入る形に変わります。

挙がった項目が本当に記載を要するかは、販売担当が確かめます。買主に説明する内容として認めるかは、記名する宅地建物取引士が決めます。

開発許可の申請書類を、出す前に突き合わせる

こちらの起点は、申請書類一式が指定のフォルダに揃った時点です。AIは都市計画法と建築基準法の該当条文、自治体の要綱、対象敷地の用途地域と高さ・容積の条件、過去に補正を求められた箇所の記録を突き合わせ、添付図書の欠落、数値の食い違い、様式のずれを拾って補正見込みの一覧にまとめます。

一覧は許認可管理の表計算ソフトに一行として積まれ、設計担当と申請担当に通知が届きます。窓口で差し戻されてから直していた動きが、 提出前に手当てを済ませる 動きに置き換わります。

条文の当てはめが正しいかは、申請を担当する者が確かめます。この内容で提出してよいかは、事業責任者が判断します。

環境認証で問われる要件を、企画の段階で並べる

三つ目は申請の前ではなく、企画が固まる前に走ります。担当者が目指す認証の区分と建物用途を入力フォームに登録したときが起点です。

AIは認証区分ごとの評価項目、今回の設計図書と設備の仕様、過去の物件で取得できた項目とできなかった項目の記録に照らし、いまの仕様で満たせる項目、設計変更が要る項目、今回は狙えない項目に仕分けます。

仕分けた要件表は事業計画の案件フォルダに保存され、設計担当と事業担当に通知が届きます。審査が近づいてから慌てて仕様を積み増す進め方が、 企画の段階で取得の範囲を決める 進め方に変わります。

仕分けが妥当かは設計担当が確かめます。どこまでの取得を目指し、その費用を事業収支に織り込むかは、事業責任者が決めます。

業務に組み込むまでの4ステップ

例にするのは「契約書類・重要事項説明書のチェックリスト作成」です。新しいシステムを作る話ではなく、いま使っているファイル保管サービスと文書作成ソフトの間に、情報の通り道を一本引く作業です。

1. 使う情報がどこにあるかを決める

点検に使う記録は、すでに社内にあります。

• 宅地建物取引業法で定められた記載事項の一覧と、自社の説明書の様式
• 役所や事業者への照会結果をまとめた、物件ごとの調査資料
• 過去の物件で指摘を受けた箇所と、その是正の記録

新しく作るものはありません。販売部門と法務で別々に保管されているなら、一箇所にまとめます。

2. 何をきっかけに動かすかを決める

説明書の原稿が案件フォルダに保存されたときを起点にします。担当者が思い出して始める形にすると、販売開始の直前ほど後回しになり、使われなくなります。

3. 判断の基準を設定しておく

何を見て「記載が足りない」と判断するのかを文章にし、一箇所にまとめて設定します。AIは毎回そこを参照します。長く販売に携わってきた人が無意識に確かめている点を、 外に書き出す作業 です。

• 敷地にかかる条例や地区計画が、どの条件のときに記載を要するのか
• 上下水道の引込みと私道の負担について、どこまで書けば説明したことになるのか
• 過去に買主からの問い合わせが集中し、書き足すようになった項目

この工程がいちばん時間がかかります。一度書き留めれば、担当者が替わっても使えます。

4. 結果の戻り先と、確認する人を決める

点検表は案件フォルダに文書として保存し、業務チャットで販売担当と法務に知らせます。 販売の受付開始前 に宅地建物取引士が開き、未記載の項目を確かめてから、事業責任者の承認に回します。

先に知っておきたい、つまずきやすい3か所

• 自治体ごとの運用の違いを取りこぼす ：同じ条文でも、自治体の要綱や窓口の運用は分かれます。前の物件の基準のまま点検すると、通るはずの申請が差し戻されます。要綱と過去の補正記録を自治体別に保管し、所在地によって参照先が切り替わる形にします。
• 調査結果が紙のまま手元に残る ：役所や事業者への照会は、証明書や図面の写しが紙で戻ってくることが少なくありません。そのままでは点検の流れに乗りません。受け取った時点で決まった名前を付けて保管するところまでを、調査の段取りに組み込みます。
• 広告表現の可否まで任せてしまう ：販売資料の文言が不当表示に当たるかは、表示の規制と業界の自主規制をどう読むかという解釈の問題です。過去に指摘を受けた表現との照合までにとどめ、掲出してよいかは責任者が決める形にします。

ディベロッパーのAI活用は、どこから考えればいいか

第1セクションで引いた線は、法令や社内の様式に照らして同じ点検を繰り返す業務にAIが効き、地権者との交渉や意匠の決定は人が担う側に残る、というものでした。紹介した三つは、いずれも 正解の根拠が条文と社内の記録にある 業務で、誰が何を確かめるのかも決めやすい位置にあります。

すべてを一度に進める必要はありません。 まずは一つの業務から で十分です。説明書の様式、物件ごとの調査資料、過去の補正記録、表計算ソフトといった、すでに手元にあるものから着手できます。