不動産テックが失敗するのは、製品の性能不足ではなく発注プロセスに原因があることが多いです。本記事では「導入したのに使われない」に至る7つの失敗パターンと、発注時に確定させるべき3点を実務手順で示します。
なぜ不動産テックは「導入したのに使われない」で終わるのか？
不動産テック導入の失敗とは、製品の性能不足ではなく、発注時に「対象業務の範囲」「入力データの実態」「確認工程を誰が担うか」の3点を確定させないまま契約したことによって起きる、運用停止の状態です。
この3点が曖昧なままだと、検収は通るのに現場が使わないという結果になります。ベンダーは仕様書どおりに作っており、発注側も指示どおり受け取っている。それでも使われない。原因は開発品質ではなく、発注の入口にあります。
以下、発注プロセスに起因する失敗を7つに分けて整理します。
| # | 失敗パターン | 発注時の対処 |
|---|---|---|
| 1 | 全業務を一度に自動化しようとする | 1業務・1帳票に絞って着手する |
| 2 | 入力データの実態を確認せず要件を固める | 現物20〜30件を集めて例外率を数える |
| 3 | 実際に入力する担当者が要件ヒアリングにいない | 操作画面の観察・録画を先に行う |
| 4 | 精度100%を前提に設計する | 人の確認工程を最初から仕様に入れる |
| 5 | 既存システムに繋がる前提で契約する | 書き込み経路を契約前に確定させる |
| 6 | 検収条件が「動くこと」になっている | 実案件を担当者が単独処理できることを基準にする |
| 7 | 運用の持ち主を決めない | 変わる箇所と修正担当を発注時に列挙する |
失敗パターン1〜3：着手前の見立てを誤る
パターン1：全業務を一度に自動化しようとする
物件資料の作成、追客メール、契約書のチェック、写真の整理を同時に対象にすると、要件が固まる前に予算と関係者の熱量が尽きます。
最初の対象業務は、次の4条件で選びます。
- 発生件数が多い（毎週以上の頻度で発生する）
- 1件あたりの手作業時間が長い（他業務が止まるほど拘束される）
- 入力元データが電子で存在する（紙・口頭のみではない）
- 担当者が2名以上いる（特定の1人しか手順を知らない業務は、まず手順の可視化が先）
逆に「年に数回・毎回条件が違う」業務は自動化の効果が出にくく、最初の対象には向きません。
パターン2：入力データの実態を確認せず要件を固める
不動産・建設の入力データは、想定より汚れています。
- マイソクがPDFのみで、テキスト抽出できないスキャン画像が混ざる
- 図面がFAX受信のまま保管されている
- 現地調査のメモが手書きで、担当者ごとに略記が違う
- 同じ物件名の表記が「〇〇ハイツ」「○○ハイツ」「〇〇HEIGHTS」で混在する
- 面積の単位が㎡と坪で混ざり、端数処理のルールが担当者依存
発注前に、対象業務の入力データの現物を直近20〜30件分そろえてください。きれいなサンプル1件ではなく、実際に処理した順に取ります。ここで例外パターンが何割あるかを数えると、見積の前提が具体化します。例外率が高い業務は、自動化率の目標を下げるか、例外を弾いて人に回す設計にします。
エクサテックが株式会社イーリアルティ様に構築した転記エージェントでは、契約の前段階から何度も現場に足を運び、困りごとを理解するところから着手しました。業務マニュアルが未整備の状態でしたが、転記そのものを自動化したことで、マニュアルを整備する必要自体が減っています。ドキュメントを整えてから発注するより、現物を見せながら詰めたほうが早い場面は実際にあります。
パターン3：実際に入力する担当者が要件ヒアリングにいない
要件が役員と情報システム担当だけで決まると、実務の細部が落ちます。落ちるのは以下のような部分です。
- 「この項目は先にこちらへ入れないとエラーになる」という入力順序
- 「レインズから出したデータは、この列だけ手で直す」という慣習
- 「この管理会社の物件だけ確認先が違う」という例外
- 「担当者が不在のときは別画面から入れる」という裏手順
対処は単純です。要件定義の前に、実際に入力している担当者の操作を観察し、画面を録画させてもらいます。口頭のヒアリングでは、本人が意識していない手順は出てきません。
失敗パターン4〜5：設計の前提を誤る
パターン4：精度100%を前提に設計する
OCRも生成AIも外れます。前提を「外れる」に置き換え、確認工程を最初から仕様に入れるのが実務的です。仕様に入れるべき要素は次の3つです。
- 抽出結果と元データを並べて表示する差分確認画面
- 確信度が低い項目のフラグ表示（人が見る順番を決めるため）
- 修正した内容を記録し、後から傾向を確認できるログ
特に法定書類は、人の確認を外す設計にしてはいけません。宅地建物取引業法第35条は、宅地建物取引士が重要事項を説明することと、重要事項説明書への宅地建物取引士の記名を定めています（2022年5月18日の改正で押印は不要となり、記名のみとなりました。出典：国土交通省「重要事項説明・書面交付制度の概要」）。個別案件の法令解釈は専門家にご確認ください。
建設業でも同様です。工事写真の電子管理は、国土交通省「デジタル写真管理情報基準（令和5年3月）」で「写真区分 → 工種 → 種別 → 細別」の階層による分類が定められています。自動分類の下書きは作れますが、基準への適合可否を最終判断するのは発注者・監督員です。この判断を人が行う前提で画面を設計しないと、確認に余計な手間が発生します。
パターン5：既存システムに繋がる前提で契約する
「あとで連携すればいい」で契約すると、開発の終盤で止まります。基幹システムがAPIを公開していない、CSV取込の仕様が固定で列追加ができない、パッケージのカスタマイズにベンダー側の見積が別途必要、といった事情は珍しくありません。
発注前に、どの経路でデータを書き込むかを1つに決めてください。選択肢は概ね次の3つです。
| 経路 | 前提 | 発注前に確認すること |
|---|---|---|
| API連携 | 既存システムが外部連携に対応 | 認証方式、更新可能な項目、レート制限 |
| CSV/取込ファイル | バッチ取込の仕組みがある | ファイル仕様書の入手、取込エラー時の挙動 |
| 画面操作の自動化 | 上記が使えない場合の代替 | 画面レイアウト変更の頻度、多要素認証の有無 |
既存システムのベンダーへの確認が必要になる場合、その回答待ちが工程上の最大のリスクです。これは発注側でしか動かせないため、着手前に依頼を出しておきます。
失敗パターン6〜7：運用に渡すところで落ちる
パターン6：検収条件が「動くこと」になっている
「仕様書の機能が実装されていること」を検収条件にすると、使われないシステムでも検収は通ります。
推奨する検収条件は、実案件を担当者が単独で処理できることです。具体的には次のように書きます。
- 現場の担当者が、開発側の同席なしで実案件を連続して処理できる
- 例外が出た場合の手戻り手順が担当者に伝わっている
- 処理結果の確認にかかる時間が、従来の手作業を超えていない
3番目は見落とされがちです。自動化したのに確認作業が増え、合計時間が変わらないケースは実際にあります。
パターン7：運用の持ち主を決めない
不動産・建設の業務は前提が変わります。帳票フォーマットの変更、管理会社のルール変更、法改正、取引先の追加。変わることは避けられないため、発注時に「変わる箇所」と「誰が直すか」を列挙しておきます。
- 帳票のレイアウト変更 → 誰が検知し、誰が修正するか
- 生成AIの出力の調整 → 社内で触るのか、ベンダーに依頼するのか
- 連携先システムの改修 → 通知は誰に来るのか
ここを決めていないと、最初の変更が起きた時点で運用が止まり、そのまま使われなくなります。
この発注方法でも避けられない限界
発注プロセスを整えても、次の点は解決しません。
- 判断そのものは自動化できません。 契約条件の妥当性、積算の最終確認、重要事項の説明といった責任を伴う判断は人が担います。自動化できるのは、その判断に必要な材料をそろえる工程までです。
- 手順が決まっていない業務は自動化できません。 担当者ごとにやり方が違う業務は、まず「どのやり方を正とするか」を社内で決める必要があります。この決定を外部に委ねることはできません。
- 紙・口頭のみで完結している情報は、入力の電子化が先です。 現地でのやり取りが電話とメモだけで完結している業務は、記録の形を変えるところから始まります。
- 例外が大半を占める業務は、投資回収が難しくなります。 毎回条件が違う業務は、自動化のルールが増え続け、保守コストが効果を上回ることがあります。この場合は自動化を諦め、チェックリストの整備にとどめる判断も合理的です。
- 効果の測定には、着手前の実測が必要です。 「今どれだけ時間がかかっているか」を測っていないと、導入後の効果も示せません。これは発注側で先に測っておくのが確実です。
なお、建設業では2024年4月1日から時間外労働の上限規制が全面適用されています（原則月45時間・年360時間。厚生労働省「建設業・ドライバー・医師等の時間外労働の上限規制」）。事務作業の削減はこの対応の一部にはなりますが、単独で解決するものではありません。36協定の運用など具体的な適用可否は社労士等の専門家にご確認ください。
まとめ
- 不動産テックの失敗は製品選定より発注プロセスに起因する。確定すべきは「対象業務の範囲」「入力データの実態」「確認工程の担い手」の3点
- 最初の対象業務は「発生件数が多い・1件の手作業時間が長い・入力元が電子・担当者が2名以上」で選ぶ
- 発注前に入力データの現物を20〜30件そろえ、例外率を数える。きれいなサンプル1件では見積の前提が固まらない
- 精度100%を前提にせず、差分確認画面と確信度フラグを最初から仕様に入れる
- 検収条件は「機能が動くこと」ではなく「担当者が単独で実案件を処理できること」にする
よくある質問
Q. 不動産テックの導入が失敗する最大の原因は何ですか？
A. 製品の性能不足より、発注時に「対象業務の範囲」「入力データの実態」「確認工程を誰が担うか」の3点を確定させないまま契約することが原因になりやすいです。この3点が曖昧だと、動くものはできても運用に乗らず放置されます。
Q. 最初に自動化する業務はどう選べばよいですか？
A. 「発生件数が多い」「1件あたりの手作業時間が長い」「入力元データが電子で存在する」「担当者が2名以上いる」の4条件を満たす業務から選びます。逆に月数件しか発生せず例外が多い業務は、自動化より手順の整理が先です。
Q. 発注前に用意しておくべき資料は何ですか？
A. 完成された要件定義書より、実際の入力データの現物（直近20〜30件分の帳票やメール、CSV）、担当者の操作画面の録画、既存システムのデータ取込仕様の3点が有効です。例外パターンが見えるため、見積の精度が上がります。
Q. 見積を比較するとき、どこを見て判断すればよいですか？
A. 金額の前に「質問の内容」を見ます。入力データの例外率、既存システムへの書き込み経路、確認工程の担い手を聞いてこない見積は、その分をリスクとして後から精算されるか、使われないシステムになる確率が上がります。
Q. AIを使えば重要事項説明書や契約書も完全自動で作れますか？
A. 作成の下書きまでは自動化できますが、最終確認は人が担う設計が前提です。宅地建物取引業法第35条は宅地建物取引士による説明と重要事項説明書への記名を定めています（個別案件の解釈は専門家にご確認ください）。
ご相談について
エクサテックは、不動産・建設の現場に入り込み、仕組みの設計からWebアプリの実装までを同一チームで担っています。「どの業務から手を付けるべきか分からない」「入力データがそろっていない」という段階でのご相談も歓迎です。まずは現状の業務をそのまま見せていただくところから始めます。
