本ケーススタディは、AI導入をご検討中の企業様から実際にいただくご相談をもとに、内容を再構成した仮想ケースを取り上げ、「その相談に私たちならどう答えるか」を解説するシリーズです。
なお、本記事は法的助言を提供するものではありません。個別の法的判断については専門家にご相談ください。
前回参照：不動産 | ベテラン頼みの重説チェック、あと何年持ちますか？【ケーススタディ】
今回の想定ケース
「営業がポータルサイトへの掲載作業や紹介文の作成に時間を取られていて、本来の営業活動に集中できない。AIで自動化できないか」
不動産会社からいただく相談として、多いテーマの一つです。話を聞くと、すでにChatGPTなどで試している会社も少なくありません。物件情報を貼り付けて「魅力的な紹介文を書いて」と指示すれば、それらしい文章は数秒で出てきます。
しかし、しばらくすると多くの会社で利用が止まります。
「試してみたが、結局使わなくなった」。
今回は、この「物件紹介文の自動生成」という一見シンプルなテーマを題材に、生成AIの導入がなぜつまずくのか、どう設計すればよいのかを考えます。
前提：物件情報はどう流れてくるか
前提として、紹介文の作成は単独の作業ではなく、物件情報が流通するフローの一工程です。
賃貸であれば、管理会社が業者間の物件流通プラットフォームに公開した募集情報を仲介会社が取得する。売買であれば、業者間の物件情報データベースに登録された情報が起点になる。
各社はそれをもとに、自社の広告としてポータルサイトや自社サイトへ掲載します。複数のポータルへ配信する一括入稿ツール（コンバーター）も普及しており、「配信する」部分の道具立ては整いつつあります。
一方で、その手前で、業者間流通で取得した物件情報を自社のシステムに登録する工程は、募集図面を見ながらの手入力が今も残っている会社が少なくありません。1物件の入力に15分程度かかるとも言われ、物件入力の代行サービスや入力支援ツールが一つの市場として成立していること自体が、この負担の大きさの裏返しです。
そして入力を終えた後も人の手に残り続けるのが、「何をどう書くか=紹介文」の部分です。
なぜ「チャットツールで試しても使われなくなる」のか
この業務をChatGPTなどへの「丸投げ」で自動化しようとすると、次のようなつまずきが生じます。
つまずき1：書いていないことを書いてしまう - 課題は「事実性」
生成AIは、入力にない情報をもっともらしく補完することがあります。物件データに記載のない「南向きで日当たり良好」「閑静な住宅街」といった記述が紛れ込むと、広告として掲載する以上、事実でない記述は許されません。結局、人が元データと突き合わせて全文を確認することになります。つまり紹介文には、「書いて良いのは元データにある事実だけ」という要件があり、これを保証する仕組みがない限り、生成した文章をそのまま使うことはできません。
つまずき2：使えない表現が混ざる - 課題は「適法性」
「魅力的に書いて」と指示すれば、AIは素直に「最高の住環境」「格安物件」と書いてくることもあります。しかし不動産広告には、宅建業法の誇大広告の禁止に加え、景品表示法に基づく「不動産の表示に関する公正競争規約」という業界ルールもあります。「完全」「絶対」といった用語や、「最高」などの最上級表現、「格安」「掘り出し物」といった割安感を与える表現は、根拠となる客観的な事実や資料を示せない限り使えません。違反すれば、不動産公正取引協議会からの警告や違約金の対象になり得ます。このチェックも、現状はベテランや広告担当者の「目」に頼っているケースが多く、チェックできる人が全文を読む運用が残る限り、負荷はさほど減りません。
つまずき3：指示を書く手間が新たに増える - 課題は「負荷」
物件ごとにデータを貼り付け、ターゲットを説明し、注意事項を書き添える。このプロンプト作成自体が数分かかる作業になり、「これなら自分で書いたほうが早い」となります。そもそも「作成の負荷」の実態は、図面からの転記、指示の作成、書き上がった文章のチェックです。文章の生成だけを自動化しても、負荷は消えるのではなく、前後の工程に移動するだけです。
うまく生成できても残る課題 - 「訴求の設計」
仮に事実に忠実で適法な文章が出てきたとしても、まだ足りないものがあります。物件紹介文は、事実の羅列ではなく広告です。その物件を誰に届けるのか（単身の社会人か、子育て世帯か、投資家か）。何を推すのか（駅距離か、日当たりか、管理状態か）。同じ物件でも、想定する読み手が変われば書くべき文章は変わります。そしてこの判断は多くの会社で、営業個人のセンスと経験に委ねられています。「刺さる文章を書けるのは、結局あの人だけ」。
前回の記事で取り上げた重要事項説明書のチェックと同じく、ここにも属人化が潜んでいます。丸投げの生成には、この「誰に何を」の判断が組み込まれていません。
従い、この相談のなかには、「負荷」「訴求」「事実性・適法性」という課題が重なっています。「生成」部分だけを導入して、入力の仕組みと検証、そして訴求の判断を設計していないことが、「試しても使われなくなる」理由です。
アプローチ - 「生成」と「検証」をセットで設計する
私たちがこの種の相談にお応えする場合、文章を作る仕組みではなく、掲載までの一連の流れを次のように設計します。
入力は「物件データ」と「訴求方針」の2つに分ける（「負荷」への対応）
まず物件データです。既存システムに構造化データ（所在地、駅徒歩、間取り、築年数、設備など）が揃っていれば、それをそのまま入力にします。一方、現場では「手元にあるのは業者間プラットフォームから取得した募集図面のPDFだけ」という物件も少なくありません。その場合は、図面からの項目抽出まで自動化の範囲に含めます。人がプロンプトを書く工程も、図面を見ながら転記する工程も、どちらもなくすのが狙いです。
訴求方針は、AIに仮説を出させて人が選ぶ（「訴求」への対応）
物件データから「この物件は駅近・コンパクトなので単身社会人向け、推しは通勤利便性」といったターゲットと訴求ポイントの候補をAIに提案させます。担当者がゼロから考えるのではなく、仮説を選ぶ/直すだけ。ベテランの「誰に何をアピールするか」という判断を、選択肢へのフィードバックという形で仕組みに残していきます。訴求方針が確定してから、本文を生成します。
生成文は、根拠とルールの2段階で機械的に検証する（「事実性・適法性」への対応）
1段階目は根拠の突合です。生成された文章の各記述が、入力した物件データに根拠を持つかを照合し、元データにない記述には印を付けます。2段階目は表現チェックです。使用できない用語・要注意表現をルールとして持たせ、さらにLLMで文脈上の優良誤認リスクも確認し、指摘理由つきで返します。
最終判断は人に残す。ただし負荷の形を変える
人の役割は「全文を読んで粗を探す」から「指摘された箇所だけを確認して判断する」に変わります。AIをチェックする側にも置くことで、人の目は最後の判断に集中できるようになります。そして確認を通った文章は、すでに使っている一括入稿ツールにそのまま流し込みます。ポータルへの掲載フロー自体は変えず、その手前の「書く」「確かめる」だけを差し替え、既存の業務システムを置き換えない設計が、現場に受け入れられやすい条件です。
これは「転記」をなくす話でもある
図面PDFから項目を抽出できるということは、紹介文の生成に限った技術ではありません。業者間流通、自社システム、ポータルサイト、これらのシステム間の「隙間」を、現状は人の手入力が埋めています。従来この連携は、システム同士の個別接続が整わない限り解消できませんでしたが、書式のばらつく図面や帳票をそのまま読み取れるLLMは、既存システムを置き換えずに、その間を繋ぐ層になり得ます。紹介文の自動化を入口として、物件の入力・転記業務全体をシームレスにしていく。そんな段階的な広がりを描けることも、このテーマに取り組む価値の一つです。
前回の重説チェックが「人の作ったものをAIが確かめる」構図だったのに対し、今回は「AIの作ったものを、AIと人が確かめる」構図です。向きは逆ですが、設計思想は同じです。
導入の現実的なステップ
「まずは自社のチェック観点を言語化しましょう」というのは正論ですが、これが最初のハードルになって止まるケースをよく見ます。観点の言語化そのものが、ベテランの頭の中にしかない暗黙知だからです。
そこでお勧めしているのは、棚卸し自体をAIにやってもらうところから始める方法です。
過去の掲載文と、社内で差し戻しや指摘を受けた事例をまとめてLLMに読ませ、「どのような観点で指摘されているか」を抽出・分類させます。担当者の仕事は、ゼロからの言語化ではなく、出てきた観点リストの添削になります。敲き台があるだけで、着手のハードルは大きく下がります。
同じ方法は訴求側にも使えます。反響の良かった掲載文を読ませ、「刺さった訴求のパターン」を抽出させる。チェック観点と訴求パターン、どちらの整備も「過去の実績から抽出して、人が添削する」という同じ型で回せます。
そのうえで、生成の適用は一つの物件種別（たとえば賃貸居住用）に絞ってスモールスタートし、「1掲載あたりの作成時間」と「差し戻し件数」で効果を測り、手応えを確認してから対象を広げるのが現実的です。
まとめ - AIに「作らせる」なら、「確かめる仕組み」まで
物件紹介文の自動生成は、「文章を作るAI」を入れるだけでは定着しません。
作る（生成）、選ぶ（訴求方針の判断）、確かめる（根拠と表現の検証）、この3つのどこにAIを使い、どこに人の関与を残すかを設計して、はじめて業務に組み込めます。
ベテランの「目」や「勘所」に頼ってきた業務を、仕組みとして再設計すること。前回の重説チェックと今回の紹介文生成に共通しています。作業の置き換えだけでなく、業務設計の見直しまで踏み込むことが肝要です。
