営業マンが、自分たちでアプリを作り始めた

SaaS に業務を合わせる時代から、現場が業務システムを作る時代へ

不動産営業の DX は、いったん SaaS の導入で止まりました。

反響は取り込めるようになった。

顧客情報は残せるようになった。

物件提案も送れるようになった。

追客メールも自動化できるようになった。

営業進捗も、昔よりは見えるようになった。

いえらぶCLOUD（公式：https://cloud.ielove.jp/ ）
KASIKA（公式：https://cocolive.co.jp/ ）
ATBB 顧客管理（公式：https://business.athome.jp/service/kokyaku_kanri/ ）
ITANDI 賃貸仲介・旧 nomad cloud（公式：https://service.itandi.co.jp/services/chukai ）
いい生活のクラウドSaaS（公式：https://www.es-service.net/ ）
Facilo（公式：https://www.facilo.jp/ ）。

さらに、不動産専用ではないものの、Salesforce Sales Cloud（公式：https://www.salesforce.com/jp/sales/cloud/ ）や kintone（公式：https://kintone.cybozu.co.jp/ ）のような汎用的な営業支援・業務アプリ基盤まで含めれば、不動産営業の現場にはすでに多くの選択肢があります。

だから、問題は「ツールがない」ことではありません。

むしろ逆です。

それでも、現場には残っている違和感があります。

お客様がなぜ止まったのか。

なぜ返信が鈍くなったのか。

なぜ内見後に温度が下がったのか。

なぜ条件に合っている物件を出しても決まらないのか。

なぜ住宅ローンの話をした瞬間に空気が重くなったのか。

なぜご主人は前向きなのに、奥様の納得感が追いついていないのか。

なぜ「駅近希望」と言っていたお客様が、最後は学区で迷っているのか。

このあたりは、CRM のステータス欄には入りません。

「検討中」と入れても、何を検討しているのかは分からない。

「内見済み」と入れても、どこで気持ちが止まったのかは分からない。

「追客中」と入れても、次に送るべき言葉は出てこない。

ここに、不動産営業のリアルがあります。

2026 年 7 月時点の現場リサーチでも、不動産・住宅領域では「ポータル連携、追客ツール、CRM、電子契約など、気づけば 10 種類以上の SaaS が並列稼働し、データも月額もバラバラになっている」という趣旨の指摘が出ています。

これは、かなり象徴的です。

DX が進んでいないのではありません。

むしろ、進めようとした結果、ツールが増えすぎている。

反響はこのツール。

追客はこのツール。

顧客情報はこのツール。

物件提案はこのツール。

電子契約はこのツール。

社内連絡は LINE、Slack、メール。

現場は、便利になるはずのツールをまたぎながら、今日もお客様に返信しています。

つまり、課題は「SaaS がないこと」ではありません。

SaaS が増えた後に、それでも残る判断の隙間です。

今回、現場の営業担当者たちが自分たちで作り始めたのは、その隙間を埋めるためのチャットボットです。

既製 SaaS を否定するためではありません。

いえらぶCLOUD も、KASIKA も、Facilo も、ITANDI 賃貸仲介も、それぞれ役割があります。

反響管理、追客、物件提案、顧客コミュニケーションの基盤としては強い。

ただ、それらは基本的に「記録する」「送る」「管理する」ための仕組みです。

一方で、現場が本当に苦しんでいるのは、その前後にある判断です。

このお客様には、物件を追加で送るべきなのか。

それとも、予算の現実を先に整理すべきなのか。

いま電話すべきなのか。

それとも、追いかけすぎず LINE で温度を戻すべきなのか。

住宅ローンの不安を先にほどくべきなのか。

配偶者の納得感を作るべきなのか。

この判断は、営業担当者の頭の中にあります。

だから、現場が作る必要がありました。

不動産 SaaS は便利です。ただし、便利さと「現場で使える」は違う

いえらぶCLOUD は、不動産会社向けの業務支援システムとして、賃貸仲介・売買仲介・賃貸管理などの業務効率化を支援するプロダクトです。公式 URL は https://cloud.ielove.jp/ です。

KASIKA は、住宅・不動産業界に特化したマーケティングオートメーションツールとして、追客や商談管理の支援を打ち出しています。公式 URL は https://cocolive.co.jp/ です。

ATBB 顧客管理は、アットホームが提供する不動産会社向け CRM で、反響への早期対応、顧客情報の自動取り込み、自動返信メール、物件情報の自動配信、営業進捗管理などを支援するサービスです。公式 URL は https://business.athome.jp/service/kokyaku_kanri/ です。

ITANDI 賃貸仲介、旧 nomad cloud は、反響・追客・来店・申込までの賃貸仲介業務を効率化する業務支援サービスです。公式 URL は https://service.itandi.co.jp/services/chukai です。

いい生活のクラウドSaaS は、不動産賃貸管理や賃貸募集業務などを一元管理できるサブスクリプション型の業務支援システムです。公式 URL は https://www.es-service.net/ です。

Facilo は、不動産仲介のコミュニケーションを一元化・可視化するクラウドツールで、「不動産営業OS」として仲介業務の成約率改善を掲げています。公式 URL は https://www.facilo.jp/ です。

Salesforce Sales Cloud は、営業支援・顧客管理・案件管理を支える SFA / CRM です。公式 URL は https://www.salesforce.com/jp/sales/cloud/ です。

kintone は、プログラミングの知識がなくても業務アプリを作れるノーコード・ローコードの業務改善プラットフォームです。公式 URL は https://kintone.cybozu.co.jp/ です。

これらは、現場の課題をかなり捉えています。

むしろ、だからこそ使われています。

ただし、現場の営業担当者が感じる不満は、「機能がまったくない」という単純なものではありません。

もっと面倒です。

「機能はある。でも、自分たちの営業の流れとは少し違う」

「入力はできる。でも、その入力が自分の次の一手に返ってこない」

「自動追客はある。でも、このお客様にその文面を送っていいかどうかは結局自分で判断しないといけない」

「顧客情報は残せる。でも、なぜ止まっているのかまでは残らない」

「物件提案はできる。でも、なぜその物件を出すべきなのかという思考は残らない」

「管理者には便利。でも、現場の手元では重い」

ここが本質です。

既製 SaaS は、業界全体の業務を広く支えるために作られています。

反響を取り込む。

顧客を管理する。

追客を自動化する。

物件を提案する。

対応漏れを防ぐ。

これらは最大公約数の課題です。

一方で、営業成果を分けているのは、もっと小さな違和感です。

「この人には、いま物件を送るより支払い不安をほどいた方がいい」

「この LINE 文面だと、少し押し売り感が出る」

「このご夫婦は、先に奥様の懸念を整理しないと前に進まない」

「この新人は、住宅ローンの話を聞いたつもりで、実は月々支払いの許容額を聞けていない」

「このお客様は駅距離を言っているが、本当は子どもの生活導線を気にしている」

こういう違和感です。

この違和感は、標準機能には入りにくい。

会社ごとに違うからです。

店舗ごとに違うからです。

営業担当者ごとに違うからです。

そして、お客様ごとに違うからです。

だから、既製 SaaS だけでは最後の 1 ミリが埋まりません。

現場の不満は「使いにくい」ではなく、「そこじゃない」です

ツールに対する現場の不満を、「使いにくい」の一言で片付けると、かなり雑です。

本当は、もっと具体的です。

たとえば、追客支援ツールでは、自動化や見込み客管理の価値がある一方で、実務では API 連携やカスタマイズの自由度、LINE 連携の細かい運用、情報の集約や集計のしやすさに不満を感じる声があります。

賃貸仲介向けの顧客管理・追客支援ツールでも、メール、LINE、SMS、チャットを統合できる点は評価される一方、居住用賃貸には合っても、店舗・事務所のような業務にはフィットしにくいという声があります。

つまり、プロダクトには強みがあります。

ただし、強みの外側に現場の業務がある。

ここで摩擦が起きます。

不動産営業は、きれいな業務フローどおりには進みません。

ポータル反響が来る。

初回連絡をする。

希望条件を聞く。

物件を送る。

内見する。

申込に進む。

契約する。

図にすれば簡単です。

しかし、実際の現場では、その間に無数の揺れがあります。

お客様が希望条件を言い切れない。

予算感が現実と合っていない。

配偶者と温度差がある。

親の意見が入る。

住宅ローンに不安がある。

勤務地が変わる可能性がある。

子どもの学区で迷う。

中古マンションの管理費と修繕積立金で急に表情が変わる。

内見後に「良かったです」と言ったのに、翌日から返信が遅くなる。

この揺れを、営業担当者は毎日見ています。

そして、その揺れに合わせて、言葉を変えています。

送るタイミングを変えています。

提案する物件を変えています。

あえて追わない判断もしています。

ここが営業の腕です。

しかし、既製 SaaS はここを完全には拾いきれません。

なぜなら、これは単なる情報管理ではなく、判断の連続だからです。

「問い合わせが来てからが本番」という現場感

不動産営業では、反響が来た瞬間に仕事が終わるわけではありません。

むしろ、そこからが本番です。

2026 年 7 月時点の現場リサーチでも、元不動産営業の立場から「問い合わせが来てからが本番だ」という趣旨の指摘がありました。

初回返信の速さ。

追客の一言。

媒介前の不安解消。

この小さな対応で結果が変わる、という話です。

これは、本当にその通りです。

不動産営業は、物件を送れば決まる仕事ではありません。

お客様は、物件情報だけを見て意思決定しているわけではないからです。

返信が早いか。

自分の不安を理解してくれているか。

押し売り感がないか。

住宅ローンの話を雑に扱っていないか。

内見後に、自分が迷っている理由を一緒に整理してくれるか。

こうした部分を見ています。

だから、追客の一言は重い。

同じ「その後いかがでしょうか？」でも、文脈によっては軽すぎます。

同じ「他にも物件をご紹介できます」でも、タイミングによっては押し売りに見えます。

同じ「月々支払いを整理しましょう」でも、言い方によってはお客様の不安を強めてしまいます。

この微妙な差を、現場の営業担当者は感じています。

だからこそ、私たちはチャットボットに、単なる文章生成ではなく、状況判断を入れようとしています。

「このお客様に、いま何を言うべきか」

「どの言葉なら、追いかけすぎに見えないか」

「どこまで説明し、どこから先は次回面談に回すべきか」

ここを支援するものにしたいのです。

住宅ローンの話をした瞬間、空気が重くなる理由

不動産営業で特に難しいのが、住宅ローンです。

物件そのものには前向きだったお客様が、月々支払いの話になった瞬間に止まることがあります。

購入意欲はある。

内見の反応も悪くない。

エリアも気に入っている。

でも、住宅ローンの話をした瞬間に、少し表情が変わる。

これは現場ではよくあることです。

住宅ローンは、単なる支払い方法ではありません。

35 年にわたる生活の前提です。

家を買う営業担当者にとっては商談の一部でも、お客様にとっては人生のリスクです。

2026 年 6 月の現場リサーチでも、住宅ローンの専門家の立場から「不動産営業にローンのことも全部説明してもらったが、どこか不安が残った」という顧客心理に触れる指摘がありました。

これは重要です。

不動産営業が住宅ローンの話をすること自体が悪いのではありません。

ただし、お客様からすると、「この人は家を売る立場の人だ」という見え方が残ります。

どれだけ丁寧に説明しても、長期リスクを背負うのは買い手です。

だから、住宅ローンの説明には特有の重さがあります。

この重さを分からずに、ただ月々支払いだけを見せると、お客様は止まります。

「払えますよ」では足りない。

「この条件なら通ります」でも足りない。

お客様が知りたいのは、審査に通るかだけではありません。

本当にこの支払いを続けて大丈夫なのか。

子どもが大きくなったときに負担は増えないか。

金利が上がったらどうなるのか。

管理費や修繕積立金は将来どうなるのか。

売却しようと思ったときに資産価値は残るのか。

こうした不安です。

だから、チャットボットにも、住宅ローンの話を計算として扱わせるべきではありません。

お客様の心理とセットで扱う必要があります。

「このケースでは、物件提案より先に支払い不安を受け止めるべきです」

「月々支払いだけでなく、管理費・修繕積立金込みの総支払額で整理した方がよいです」

「営業担当者から断定的に言い切るのではなく、必要に応じて専門家確認の導線を示した方が安心につながります」

こういう判断を返せるようにしたい。

これが、現場で本当に使えるチャットボットに必要な粒度です。

だから、ゼロスクラッチで作ることにしました

今回、現場の営業担当者たちが作り始めたのは、不動産営業の判断を支援するチャットボットです。

既存 SaaS の置き換えではありません。

反響管理をゼロから作り直したいわけでもありません。

物件データベースを自前で持ちたいわけでもありません。

CRM を全部捨てたいわけでもありません。

作りたいのは、その手前と、その間にあるものです。

営業担当者が CRM に入力する前に、頭の中で考えていること。

お客様に LINE を送る前に、少し迷っていること。

内見後の温度感を、どう解釈すべきか分からないこと。

新人が、何を聞き漏らしているのか自分では気づけないこと。

ベテランが、感覚で判断しているために言語化されていないこと。

ここを支援するチャットボットです。

なぜチャットボットなのか。

理由は明確です。

不動産営業の実務は、そもそも会話でできているからです。

お客様との会話。

LINE でのやり取り。

内見後の振り返り。

上司への相談。

住宅ローンの不安整理。

希望条件の優先順位づけ。

失注しそうな案件の立て直し。

すべて、会話です。

そして、現場の営業担当者の頭の中も、会話に近い形で動いています。

「このお客様、たぶん物件そのものじゃなくて、支払いが不安なんですよね」

「ご主人は前向きなんですけど、奥様がまだ納得していない感じです」

「駅近希望なんですけど、予算を考えると現実的ではないです」

「ここで追いすぎると引かれそうなので、一度整理の LINE を送りたいです」

こういう言葉は、チェックボックスに入りにくい。

しかし、チャットにはそのまま入れられます。

だから、チャットボットが合っています。

AI を使うことに罪悪感を持つ営業ほど、たぶん良い営業です

ここは、今回かなり大事なポイントです。

不動産営業の現場に AI を入れようとすると、意外な抵抗が出ます。

「楽をしている感じがする」

「お客様に失礼な気がする」

「テンプレートで返しているみたいで嫌だ」

「自分で考えずに AI に書かせるのは、サボっているように感じる」

特に、真面目な営業担当者ほど、この感覚を持ちます。

2026 年 6 月末から 7 月にかけた現場リサーチでも、追客メールや物件紹介文を AI に書かせることに罪悪感を持つ営業担当者がいる、という話が出ていました。

「一度サボると、お客様に対して申し訳ない気がする」

そう感じる人ほど、お客様と真剣に向き合っている。

これは、とてもよく分かります。

不動産営業は、お客様の人生にかなり深く関わる仕事です。

家を買う。

住む場所を決める。

ローンを組む。

家族の生活が変わる。

そんな意思決定に関わる以上、営業担当者が「テンプレで済ませたくない」と感じるのは自然です。

むしろ、その感覚がある人ほど良い営業です。

だから、AI は営業を代替するものではありません。

AI は、8 割の骨組みを作るものです。

残り 2 割に、そのお客様だけの一言を入れる。

ここに人間の仕事があります。

たとえば、AI が内見後のフォロー文面を作る。

そこに営業担当者が一言足す。

「先ほどお話しされていた、お子様の通学時間の点も気になっているかと思います」

「日当たりについて、現地で少し気にされていたように感じたので、改めて整理します」

「月々支払いについては、無理に進める意図はありませんので、一度落ち着いて比較できる形にします」

この一言があるだけで、文面はテンプレートではなくなります。

AI が作った文章に、人間の観察が乗る。

これが大事です。

夜遅くまで疲れ切った営業担当者が、最後のお客様にそっけない文面を送ってしまうより、AI で土台を作り、浮いた時間と余力で「その人だけの一言」を足す方が、よほど誠実です。

AI を使うことは、手を抜くことではありません。

お客様に向き合う余力を取り戻すことです。

プロンプトは、きれいに書かなくていい

もう一つ、現場で大きいのがプロンプトへの抵抗です。

AI を使おうとすると、多くの人が最初に止まります。

「どう聞けばいいか分からない」

「ちゃんとした指示文を書かないといけない気がする」

「プロンプトが下手だと、変な答えが返ってきそう」

これもよく分かります。

ただ、不動産営業の現場で使うなら、最初から完璧なプロンプトを書く必要はありません。

むしろ、お客様に話しかけるように雑に打てばいい。

「このお客様、ローンが不安そう。追いすぎない LINE を作って」

「駅近希望だけど予算が合わない。初回面談でどう整理すればいい？」

「奥さんがまだ納得していない感じ。次回どう進める？」

これでいい。

返ってきたものを見てから、

「もっと優しい感じで」

「営業感を弱めて」

「住宅ローンの不安を先に受け止めて」

「LINE で送れる短さにして」

と追加すればいい。

このくらいで十分です。

むしろ、現場の言葉で入力した方が、現場に合った答えが返ってきます。

きれいなプロンプトより、リアルな状況説明の方が大事です。

これも、現場主導で作る理由です。

エンジニアや外部コンサルが整えた言葉より、営業担当者が普段使っている言葉の方が、業務の実態に近いからです。

既存 SaaS の外側にある「営業の脳内」を作る

今回のチャットボットでは、既存 SaaS の使いにくさを裏返して設計しています。

まず、入力項目から始めない。

営業担当者に、最初からきれいなデータ入力を求めません。

「年収 650 万円、夫婦と子ども 1 人、頭金 100 万円。駅近希望だが、予算的には駅徒歩 15 分以上になりそう。初回面談では何から説明すべきか」

これでいい。

あるいは、

「内見後に反応が薄くなったお客様。物件自体は悪くない反応だったが、月々支払いを見た後から返信が遅い。追いかけすぎない LINE 文面を作りたい」

これでいい。

営業担当者が普段話している言葉で入力できるようにします。

次に、出力を「管理者向け」ではなく「次の一手」に寄せます。

管理画面に表示するための整理ではありません。

営業担当者が、次に何を言うべきか。

何を確認すべきか。

何を送るべきか。

どの順番で話すべきか。

どこにリスクがあるか。

ここまで返す。

たとえば、チャットボットはこう返します。

「このお客様は、物件条件よりも月々支払いへの不安が意思決定を止めている可能性があります。次の提案では、物件を追加で送るより先に、管理費・修繕積立金を含めた総支払額の見え方を整理した方がよいです。LINE では『無理に進める意図はありません』と先に伝え、比較表を作る提案にすると返信しやすくなります」

あるいは、こう返します。

「このケースでは、駅距離・広さ・予算が同時に成立していません。物件を追加で送る前に、『絶対に譲れない条件』と『調整できる条件』を分ける会話を入れた方がよいです。初回面談では、駅徒歩ではなく通勤時間ベースで許容範囲を聞くと、選択肢が広がります」

これは、自動返信ではありません。

営業判断の補助です。

既存 SaaS が「顧客情報を管理する」ものだとすれば、私たちが作っているものは「営業の脳内を補助する」ものです。

ここが違います。

過剰な自動化は、営業を強くするとは限らない

ここも、いまの不動産営業ではかなり重要です。

反響はポータルから来る。

物件資料はシステムから出る。

追客は自動配信される。

査定価格も AI が出す。

これだけ聞くと、営業は楽になったように見えます。

しかし、便利になった結果、別の問題も起きています。

「自分で顧客をつくる」

「売主から物件を預かる」

「融資を組み立てる」

「売れない原因を分析する」

「価格変更を提案する」

こうした営業の本体を、現場で教える機会が減っているのではないか。

2026 年 7 月時点の現場リサーチでも、不動産会社の経営側から、そうした問題意識が語られていました。

これは、非常に重要な指摘です。

自動化は、営業を強くする場合もあります。

しかし、設計を間違えると、営業を受け身にします。

反響が来るのを待つ。

システムが物件を出す。

自動配信が追客する。

AI が査定する。

その結果、営業担当者が自分で考える領域が減っていく。

それなのに、数字が悪くなると「最近の若手は受け身だ」と言われる。

これは、かなり残酷です。

本当に必要なのは、営業の本体を奪う自動化ではありません。

営業の本体に集中するための自動化です。

追客文面の骨組みは AI が作る。

物件比較の整理は AI が手伝う。

初回ヒアリングの抜け漏れはチャットボットが補う。

ただし、最後にお客様の不安を感じ取り、どの言葉を足すかは人間が決める。

浮いた時間で、気になっていたお客様に電話を一本入れる。

内見で気になった日当たりの話を一言足す。

お子様の学校の話を覚えておいて、次回の提案に反映する。

こういう方向に使うべきです。

AI は、人間を現場から遠ざけるためのものではありません。

人間が、もう一度お客様に向き合うためのものです。

GitHub を触り、プルリクを出す。不動産営業が「開発の参加者」になる

さらに重要なのは、これを外部の開発会社に丸投げしていないことです。

不動産営業の現場にいる人たちが、自分たちで GitHub アカウントを作りました。

GitHub の公式 URL は https://github.com/ です。

リポジトリを触りました。

ブランチを切りました。

コードを修正しました。

プルリクエストを出しました。

レビューを受けました。

修正しました。

Cloudflare Pages（公式：https://pages.cloudflare.com/ ）などを使い、デプロイまで経験しました。

最初から分かっていたわけではありません。

リポジトリ。

ブランチ。

コミット。

プルリクエスト。

レビュー。

マージ。

デプロイ。

営業の日常語ではありません。

むしろ、最初は意味が分からなくて当然です。

ただ、Claude Code（公式：https://www.anthropic.com/product/claude-code ）や Codex（公式：https://openai.com/ja-JP/codex/ ）を使えば、分からないままでも前に進めます。

エラーが出たら、そのまま聞く。

「このエラーは何を意味していますか」

「次に何をすればいいですか」

「この修正で壊れる可能性はありますか」

「プルリクエストの説明文を作ってください」

「このコードを、非エンジニアにも分かるように説明してください」

「この変更をデプロイする前に確認すべき点を教えてください」

こうやって、一つずつ進める。

ここで起きた変化は、単なるスキル習得ではありません。

立場の変化です。

これまで現場は、開発に対して要望を出す側でした。

「こういう機能が欲しいです」

「ここが使いにくいです」

「この入力項目を変えてください」

「このテンプレートを追加してください」

そこから先は、開発側の仕事でした。

しかし、プルリクエストを出せるようになると、言葉が変わります。

「ここまで作ってみました」

「この分岐を追加しました」

「この回答パターンを入れました」

「このプロンプトを修正しました」

「レビューをお願いします」

「デプロイして確認できます」

この差は大きい。

現場が、依頼者ではなくなります。

開発の参加者になります。

しかも、業務を一番知っている人間が、開発の入口に立つ。

ここに大きな意味があります。

既存 SaaS は最大公約数を取る。現場開発は、最小違和感を拾う

既存 SaaS は、最大公約数を取りにいきます。

それは正しいことです。

多くの会社に導入されるには、汎用性が必要です。

反響管理。

顧客管理。

追客管理。

物件提案。

タスク管理。

進捗管理。

これらは、多くの不動産会社に共通する課題です。

だから SaaS 化できます。

一方で、営業成果を分けるのは、最大公約数ではなく、最小違和感です。

この LINE は、少し押しが強い。

このタイミングで電話すると、追われている感じが出る。

このお客様には、物件の魅力より先に支払いの不安をほどいた方がいい。

このご夫婦は、夫より妻の納得を作らないと進まない。

この新人は、条件を聞いているようで、意思決定者を確認できていない。

この物件は良いが、管理費・修繕積立金の説明を後回しにすると後で揉める。

この小さな違和感が、商談を動かします。

そして、この違和感は標準機能には入りにくい。

だから、現場で作る必要があります。

現場が毎日感じている違和感を、プロンプトにする。

現場が毎回説明していることを、チャットボットの回答にする。

ベテランが無意識に行っている判断を、新人でも使える形にする。

失注理由を、次回の確認項目に変える。

追客文面を、単なるテンプレートではなく、状況別の判断に変える。

これが、現場主導開発の価値です。

作っているのは、営業を代替する AI ではありません

ここは誤解してはいけません。

今回作っているチャットボットは、営業担当者を置き換えるものではありません。

むしろ逆です。

営業担当者を "強くするため" のものです。

新人には、"ベテランの視点" を渡す。

ベテランには、案件の壁打ち相手を渡す。

チームには、属人的な営業ノウハウを共有する器を渡す。

管理者には、現場がどこで詰まっているのかを見る入口を渡す。

たとえば、新人が初回面談前に相談します。

「年収 500 万円、単身、初めてのマンション購入。駅近希望だが、予算はかなり厳しい。初回面談で何を聞くべきか」

チャットボットは、いきなり物件を出しません。

資金計画。

購入理由。

月々支払いの許容額。

将来の住み替え可能性。

駅距離と広さの優先順位。

住宅ローン審査への不安。

これらを確認するよう促します。

そして、初回面談前に送れる LINE 文面まで作る。

これは、新人教育そのものです。

あるいは、ベテラン営業が使う場合は違います。

「このお客様、条件は合っているが決め切らない。夫婦間で意見が割れていそう。次回どう進めるべきか」

この場合、チャットボットは、意思決定者の整理、懸念点の分解、配偶者向け説明、比較表の作成などを提案する。

つまり、案件の壁打ち相手になります。

営業を消すのではありません。

営業の判断を増幅する。

そのためのチャットボットです。

大手不動産会社でも、AI によって事務作業を削減し、浮いた時間を人間の営業活動に戻す事例が語られています。

重要なのは、「AI で人を減らす」ことではありません。

浮いた時間で、人間に何をさせるかです。

お客様に電話を一本入れる。

現地で気になった日当たりの話を補足する。

住宅ローンの不安をもう一度整理する。

夫婦間の温度差を丁寧に拾う。

「この人から買いたい」と思ってもらうための、人間にしかできない接点を増やす。

ここを設計している会社が、AI を武器にできます。

逆に、ここを設計しない会社は、自動化によって営業を弱くする可能性があります。

なぜエンジニアだけでは作れないのか

ここは、はっきり書きます。

現場の業務を深く理解していない人間に、現場で本当に使われるプロダクトは作れません。

エンジニアの能力が低いという話ではありません。

役割が違うのです。

エンジニアは、システムを構造化する力を持っています。

安全に動かす力を持っています。

セキュリティ、権限管理、データベース設計、ログ、監査、インフラ、障害対応。

本番運用では、エンジニアの力が必要です。

ここを軽く見てはいけません。

しかし、業務の核心はコードの中ではなく、現場にあります。

お客様が言葉にしない不安。

新人が毎回つまずく確認項目。

ベテランが無意識に行っている質問の順番。

商談が止まる直前の空気。

物件そのものではなく、意思決定者の温度差で失注する場面。

こうした実務の細部は、会議室の要件定義だけでは拾えません。

仕様書にも書ききれません。

なぜなら、現場の人間自身も、それを知識として整理しているわけではないからです。

日々の経験として、身体感覚で持っている。

だからこそ、現場の人間が AI を使って言語化し、そのままプロダクトに落とし込む意味があります。

「この回答だと、お客様は営業されていると感じます」

「この順番で聞くと、初回面談では重くなります」

「住宅ローンの話は、ここで出した方が自然です」

「内見後の追客文は、強く押すより選択肢を整理した方が返信が来ます」

「新人はこの質問を飛ばしがちですが、ここを聞かないと次の提案がズレます」

こういう言葉は、現場からしか出ません。

そして、この言葉こそ、チャットボットの品質を決めます。

月額数千円で、開発の入口が現場に開いた

ここで起きている変化は、AI 活用ではありません。

開発コストの構造変化です。

以前なら、小さな業務アプリを作るにも大きなコストがかかりました。

要件定義をする。

（しかも、エンジニアによっては、要件定義のコミュニケーションがうざい場合ありますよね。なんですが、以前までは頼らざるを得なかったので、我慢してきましたよね？）

開発会社に相談する。

見積もりを取る。

仕様を詰める。

設計する。

実装する。

テストする。

リリースする。

現場の小さなアイデアは、たいていこの途中で止まります。

「便利そうですね」

「いつか作りたいですね」

「開発リソースが空いたらやりましょう」

「優先順位を整理しましょう」

そう言われて、数週間、数か月が過ぎる。

そのうち、現場の熱量が落ちる。

課題は残る。

また同じ不便を繰り返す。

しかし、Claude Code や Codex のようなツールが出てきたことで、最初の一歩は現場でも踏み出せるようになりました。

Claude Code は、コードベースを読み、複数ファイルの変更やテスト実行、コミットまで支援する agentic coding system として提供されています。公式 URL は https://www.anthropic.com/product/claude-code です。

Codex は、OpenAI が提供する AI コーディングパートナーで、機能開発、リファクタリング、レビュー、リリースなどの実務を支援するツールとして提供されています。公式 URL は https://openai.com/ja-JP/codex/ です。

GitHub は、コード管理やプルリクエストを含む開発ワークフローの基盤です。公式 URL は https://github.com/ です。

Cloudflare Pages は、GitHub などと連携してフロントエンドをデプロイできる JAMstack プラットフォームです。公式 URL は https://pages.cloudflare.com/ です。

こうしたツールを使えば、非エンジニアでもアプリケーション開発の入口に立てる。

GitHub を触れる。

プルリクエストを出せる。

デプロイできる。

チャットボットを作れる。

業務フローをプロンプトに落とし込める。

小さな画面を動かせる。

これは、抽象論ではありません。

実際に、不動産営業の現場で起きています。

もちろん、月額数千円で本番品質の業務システムがすべて作れる、という意味ではありません。

セキュリティ。

個人情報保護。

権限管理。

ログ管理。

監査対応。

保守性。

障害対応。

ここは専門家が必要です。

ただし、試作品を作ること。

業務の痛みを形にすること。

現場の暗黙知をチャットボットにすること。

小さく動かして、チームで改善すること。

ここまでは、現場でも届く時代になりました。

これが、開発の民主化です。

エンジニアの仕事は奪われるのか

この話をすると、エンジニア不要論に聞こえるかもしれません。

しかし、そうではありません。

むしろ、（人間性も伴った）優秀なエンジニアの価値は上がります。

ただし、価値の出し方は変わります。

補足すると、ブリリアントジャークで性格が悪く、「これは要件なんですか」とか「要件に定義されていないものは形にできません」といった後ろ向きなことばかり言っているエンジニアの価値は、相対的にますます落ちていきます。

優秀なエンジニアというのは、技術が優れているだけではありません。コミュニケーション面でも優れており、部署を横断していろんな人と円滑にやり取りができる、そういう人の価値は上がっていきます。

一方で、AI と大差がないような機械的なエンジニアは、もういらないというか、むしろ邪魔です。周囲の精神衛生上もマイナスになっていくので、そういう意味で価値は下がっていく、ということです。

これからのエンジニアに求められるのは、「自分だけが作れる」という立場に居続けることではありません。

現場が作ったものを、組織で使える品質に引き上げることです。

現場の試作品を、本番に耐える構造へ変える。

属人的なコードを、保守できる形に整える。

プロンプトの寄せ集めを、運用可能なワークフローにする。

チャットボットを、安全な権限管理とデータ設計の上に載せる。

ログを残す。

個人情報を守る。

障害時に復旧できるようにする。

ここに、エンジニアの本当の価値があります。

一方で、現場を理解しようとしないエンジニアは厳しくなります。

「要件を整理してから来てください」

「仕様にありません」

「開発リソースが空いたら対応します」

「現場のことは分からないので、詳しく書いてください」

この姿勢のままでは、現場は AI に向かいます。

そして、自分たちで作り始めます。

現場は、もう待たなくていいからです。

これから必要なのは、現場の上に立つエンジニアではありません。

現場の創造力を増幅できるエンジニアです。

SaaS 導入で終わる DX と、現場が作る DX は違う

不動産 DX という言葉は、もう珍しくありません。

反響管理を入れる。

CRM を入れる。

自動追客を入れる。

電子契約を入れる。

物件提案クラウドを入れる。

LINE 連携を入れる。

もちろん、それは重要です。

しかし、それだけで現場が変わるわけではありません。

SaaS を入れても、入力されなければ意味がない。

自動追客を入れても、文面が現場感とズレていれば使われない。

CRM を入れても、営業判断が残らなければ新人教育にはつながらない。

物件提案ツールを入れても、なぜその物件を出すのかが整理されなければ、提案力は属人化したままです。

DX は、ツール導入では終わりません。

現場の思考が変わらなければ、業務は変わりません。

AI 導入でも同じです。

「とりあえず ChatGPT を使う」

「データを入れずに汎用回答だけを得る」

「出力を誰もチェックしない」

「法的記載や数値の誤りを確認しない」

こうした使い方では、現場は強くなりません。

むしろ危険です。

不動産は、金額が大きく、法務・金融・生活設計が絡む領域です。

AI の出力をそのまま送ればいい、という話ではありません。

業務フローに組み込む。

必要なデータを入れる。

現場の判断基準を入れる。

人間がチェックする。

法的な表現や数値を確認する。

この設計があって、初めて使えます。

今回の取り組みで変わったのは、まさにそこです。

現場の人間が、自分たちの業務をプロダクト化できるものとして見始めた。

「この作業、チャットボットにできますね」

「この確認項目、プロンプトに入れられますね」

「この返信文、パターン化できますね」

「この判断基準、新人にも使えるようにできますね」

「この部分、既存ツールでは拾えないので自分たちで作りましょう」

こういう会話が出てきます。

これは、単なる AI 活用ではありません。

現場が開発組織に変わり始めているということです。

既製 SaaS の時代が終わるのではありません。既製 SaaS だけに合わせる時代が終わるのです

もう一度言います。

既製 SaaS が不要になるわけではありません。

むしろ、必要です。

反響管理や顧客管理をゼロから全部作る必要はありません。

物件データ連携やポータル連携、メール配信、LINE 連携、タスク管理、権限管理。

こうしたものは、既存プロダクトを使った方がいい。

ただし、既製 SaaS に業務をすべて合わせる時代は終わり始めています。

これからは、既製 SaaS を土台にしながら、その上に現場固有の判断レイヤーを作る時代です。

不動産会社ごとに、営業スタイルは違います。

店舗ごとに、顧客層も違います。

売買と賃貸でも違います。

都心と地方でも違います。

ファミリー向けと投資用でも違います。

新人が多い組織と、ベテラン中心の組織でも違います。

この違いを、すべて既製 SaaS の標準機能に求めるのは無理があります。

だから、現場が自分たちで作る。

自分たちの営業スタイルに合わせて、チャットボットを育てる。

自分たちの勝ちパターンを、プロンプトにする。

自分たちの失注パターンを、チェック項目にする。

自分たちの新人教育を、会話型にする。

これが、これからの現場 DX です。

おわりに

不動産営業の現場には、すでにたくさんの SaaS があります。

いえらぶCLOUD
https://cloud.ielove.jp/

KASIKA
https://cocolive.co.jp/

ATBB 顧客管理
https://business.athome.jp/service/kokyaku_kanri/

ITANDI 賃貸仲介、旧 nomad cloud
https://service.itandi.co.jp/services/chukai

いい生活のクラウドSaaS
https://www.es-service.net/

Facilo
https://www.facilo.jp/

Salesforce Sales Cloud
https://www.salesforce.com/jp/sales/cloud/

kintone
https://kintone.cybozu.co.jp/

それぞれに役割があります。

それぞれに強みがあります。

ただし、それでも埋まらない領域があります。

入力項目に入らない温度感。

ステータスでは表せない迷い。

テンプレートでは拾えないお客様の事情。

管理画面には出てこない営業担当者の判断。

ベテランが無意識に行っている質問の順番。

新人が毎回つまずく確認項目。

商談が止まる直前の空気。

この細部を、誰がプロダクトにするのか。

答えは、現場です。

現場の人間が、自分たちで作る。

Claude Code を使う。
https://www.anthropic.com/product/claude-code

Codex を使う。
https://openai.com/ja-JP/codex/

GitHub に触る。
https://github.com/

プルリクエストを出す。

Cloudflare Pages などでデプロイする。
https://pages.cloudflare.com/

使いながら直す。

もちろん、最後はエンジニアの力が必要です。

セキュリティを高める。

システムを堅牢にする。

データ設計を整える。

本番運用に耐える形へ引き上げる。

そこは専門家の仕事です。

しかし、最初の問いは現場から出るべきです。

そして今は、最初の試作品も現場から出せる時代になりました。

既製 SaaS に業務を合わせるだけの時代は、もう終わり始めています。

これからは、既製 SaaS を使いながら、既製 SaaS では拾えない現場の判断を、自分たちで作る時代です。

不動産営業が GitHub にプルリクを出す。

数年前なら、冗談のように聞こえたかもしれません。

でも今、それは現実になり始めています。

そして、この変化はもう止まらないと思います。

作る側に回った現場は、強い。

SaaS を使うだけだった現場が、自分たちで業務システムを作り始めたとき、営業組織の学習速度は一気に変わります。

これは、不動産営業の DX ではありません。

現場そのものが開発組織に変わる、最初の兆候です。

2026 年 7 月現在、その兆候はもう現場の声として出始めています。

AI を使うことに罪悪感を持つ営業担当者がいる。

テンプレートで返したくないと感じる営業担当者がいる。

SaaS が増えすぎて、逆に業務が分断されていると感じる現場がある。

自動化が進んだ結果、営業の本体を教える機会が減っていると感じる経営者がいる。

これは、AI 活用の技術論ではありません。

営業という仕事を、もう一度どう設計し直すかという話です。

AI で営業を薄めるのか。

AI で営業を強くするのか。

その分かれ目は、現場にあります。

現場が自分の業務を言葉にし、自分たちで作り、使いながら直していく。

その動きが始まった会社から、不動産営業の DX は次の段階に進むと思います。

※ 本記事は 2026 年 7 月時点の体験、公開情報、ならびに X 上で確認された不動産営業・不動産 DX 領域の現場感をもとに書いています。Claude Code、Codex、GitHub、Cloudflare Pages、各種不動産 SaaS の仕様や料金は変更される可能性があります。実際に利用する際は、各サービスの最新情報をご確認ください。

#Claude
#ClaudeCode
#Codex
#GitHub
#プルリクエスト
#デプロイ
#不動産DX
#営業DX
#不動産SaaS
#現場主導開発
#開発の民主化
#非エンジニア開発
#チャットボット