はじめに
不動産業界を題材に、3つのユースケースの設計をケーススタディとして書いてきました。
- 重要事項説明書のチェック：人が作ったものを、AIが確かめる
- 物件紹介文の作成：AIに作らせ、AIと人が確かめる
- 入居者・オーナーからの問い合わせ対応：AIが答える前に、危険を見分ける
業務も違えば、AIの使い方の向きも違います。ところが設計を詰めていくと、3回とも同じ場所で立ち止まりました。
この記事では、その「同じ場所」を不動産の文脈から切り離して書きます。ベテランの頭の中にしかない判断基準、AIが作ったものの事実性、失敗したときのコストの重さ、システム間を埋める手作業の転記。この4つは、どの業界のどの業務にもあるからです。
前提：相談の言葉と、本当の課題は違う
3本すべての起点はここでした。「AIで自動化できませんか」という相談を、そのまま自動化の設計に持ち込むと失敗します。
重説チェックで求められていたのは自動化ではなく、「ベテランの目を全件に行き渡らせること」でした。物件紹介文では、文章の生成だけを自動化しても負荷は消えず、転記や確認という前後の工程に移動するだけでした。問い合わせ対応では、「何％を自動化するか」ではなく「安全に任せられる問い合わせだけを切り出す」という問いに置き換える必要がありました。
この読み替えは、壁というより設計の入口です。ここを飛ばすと、この後に書く3つの壁のどれかに必ずぶつかります。
壁①：「まず言語化してから」で、着手前に止まる
1本目の重説チェックで、「遠回りに見えても、チェック観点の棚卸しを省略しないことが結局は近道」と書きました。
ところが2本目の物件紹介文で、この正論が最初のハードルになって止まる現実に向き合うことになりました。観点はベテランの頭の中にしかなく、「書き出してください」と言われて書ける人はほとんどいません。3本目の問い合わせ対応でも同じで、FAQを整備しようとして「書くことが多すぎて挫折した」という話は珍しくありませんでした。
そこで考え方を変えました。言語化は、基本的にAIに任せる前提で設計します。
重説のチェック観点、物件別・オーナー別の対応ルール、不動産用語と入居者の話し言葉の対応関係、差し戻しの理由。これらは多くの場合、過去の指摘事例、応対ログ、通話録音、業者への発注メールに、判断の結果としてすでに残っています。
構造化・非構造化データを読み、調べ、分類することは、LLMが得意とする分野です。人が考えて書き起こすより、LLMに抽出させて人が添削する方が速く、抜けも少ない。ナレッジ整備を「執筆作業」から「レビュー作業」に変える。3本すべてで採用した型です。
なお、その業務が事業の競争要因である場合は、レビューの工数も一定増やさざるを得ないと考えています。LLMの出す結論は、大量のデータから導かれる「もっともらしい結論」に近付きます。チェック観点や対応ルールのように、業界標準に沿っていれば問題ない業務では、この特性は長所として働きます。一方、何で差別化するのか、どの顧客を狙うのかといった、敢えて他社とずらすべき部分では、同業他社と同じ結論に収束する短所として働くため、一定人の手を加えて編集する必要があります。
ちなみに、AIに任せた言語化であっても、観点表や対応ルールという資産は、AIの精度がどうであれ会社に残ります。1本目で書いたとおり、何も残らないという失敗を回避できます。
壁②：作る仕組みだけ入れて、確かめる仕組みを入れない
「試してみたが、結局使わなくなった」。2本目で書いたこの現象の正体は、ここにあります。
生成AIは、入力にない情報をもっともらしく補完します（事実性の問題）。「魅力的に書いて」と指示すれば、広告として使えない表現も混ぜてきます（適法性の問題）。結果として、人が元データと突き合わせて全文を確認することになり、負荷は減らずに移動するだけです。
対策の型は、生成と検証をセットで設計することです。生成された文章の各記述が元データに根拠を持つかを照合し、根拠のない記述には印を付ける。使えない用語はルールとして持たせ、文脈上の判断が必要な箇所だけLLMに見させる。AIの指摘には「原文のどこを根拠にそう判断したか」を必ず添えさせ、根拠が原文に実在しない指摘は弾く。
興味深いのは、3本でこの「向き」が違うことです。重説チェックは「人が作ったものをAIが確かめる」、物件紹介文は「AIが作ったものをAIと人が確かめる」、問い合わせ対応は「AIが答える前に、ルールで危険を検知する」。向きは逆でも、設計思想は同じで、AIを作る側だけでなく、確かめる側にも置くという考え方です。
もう一つ、3本に共通して意識したのが「すべてを生成AIに任せない」ことです。日付の形式や記載の有無といった単純なチェックは、従来型のルールベース処理の方が速く、確実で、コストもかかりません。「ガス臭がする」「水が止まらない」といった緊急ワードの検知も、まずルールで拾います。判断を要する箇所だけに生成AIを使う使い分けが、精度とランニングコストの両立に繋がります。
この設計にすると、人の役割が変わります。「全文を読んで粗を探す」から、「指摘された箇所だけを確認して判断する」へ。負荷がなくなるのではなく、負荷の形が変わるのです。
壁③：どこまで任せるかを、件数や精度で決めてしまう
3つ目の壁は、両極端で現れます。
一方は「精度100%でなければ使えない」という思考で頓挫するケースです。比較すべき対象は完璧な精度ではなく、現状の人間によるダブルチェックの精度です。人のチェックも100%ではありません。「現状よりミスが減るか、業務が楽になるか」で評価しなければ、いつまでも導入に踏み切れません。
もう一方は「せっかく入れるのだから」と自動応対の範囲を広げすぎて、信頼を失うケースです。「天井から水が漏れている」という電話に、AIが悠長にFAQを読み上げる。実害が出るだけでなく、「あの会社はAIに丸投げしている」という評判に直結します。
どちらも、軸の取り方を変えるべきです。任せる範囲を決める軸は、件数や正解率ではなく失敗コストです。3本目で整理した観点は3つです。
- 緊急性：回答を待たせることで、人や建物への被害に繋がるか
- 機密性・本人確認：誰にでも答えてよい情報か、本人確認が要るか
- 回答の確定性：客観的に一つの答えが決まるか、個別判断や交渉を伴うか
件数が多く、回答が定型的で、失敗時の影響が小さい業務から始める。緊急対応では、AIの役割を「問題を解決すること」ではなく「必要な情報を聞き取り、緊急性を検知し、迅速かつ正確に人へ引き継ぐこと」までに限定する。
そのうえで、最終責任の所在を先に決めます。重説チェックにAIを入れても、宅地建物取引士の記名や説明の義務はなくなりません。「AIが見落としたら誰の責任か」を決めないまま導入すると、現場は使い方に迷い、結局使われなくなります。
そして、この線引きは一度決めれば終わりではありません。応対ログを分類・集計すると、どの問い合わせが多いか、どこまでAIだけで完結できたか、どの段階で人へ切り替わったかが見えてきます。安全性と効果を確認できた領域から、少しずつ自動化の対象を広げていく。「導入して終わり」ではなく、ログをもとに育てる運用が、この領域では特に重要です。
付記：既存システムは置き換えない
壁というより、3本に共通した「現場に受け入れられる条件」として書いておきます。
業者間の物件流通プラットフォーム、自社の管理システム、ポータルサイト。これらのシステムの「隙間」を、今は人の手入力が埋めています。従来この連携は、システム同士の個別接続が整わない限り解消できませんでした。書式のばらつく図面や帳票をそのまま読めるLLMは、既存システムを置き換えずに、その間を繋ぐ層になり得ます。
もう一つは、情報の参照先を性質で分けることです。管理規約やマニュアル、過去の対応事例といった文書はRAGで検索する。契約期間や入金状況のようにシステムに構造化されている情報は、FAQに転記するのではなく、APIやデータ連携基盤を通じて元のシステムから取得する。同じ情報を複数の場所に書き写す仕組みにすると、いずれどこかが古くなります。
掲載や受付といった業務フロー自体は変えず、「書く」「確かめる」の部分だけを差し替える。この設計が、現場に定着するかどうかを左右します。
業界が変わっても、壁は変わらない
ここまで書いた3つの壁は、重説やマイソクといった不動産固有の帳票や用語に由来するものではありません。
ベテランの頭の中にある判断基準。AIが作ったものの事実性。失敗したときのコストの重さ。システム間を埋める手作業の転記。業界や業務が違えど、この4つはそのまま存在します。
次回以降、業界を変えて、この型が本当に通用するのかを確かめる記事も書きたいと思います。
まとめ
- 言語化は、基本的にAIに任せる。過去の記録からLLMに抽出させ、人はレビューに回る
- 作る仕組みと確かめる仕組みはセットで設計する。AIを確かめる側にも置き、単純なチェックはルールベースに任せる
- 任せる範囲は件数や精度ではなく失敗コストで線を引く。責任の所在を先に決め、ログをもとに育てる
