ポータル掲載原稿の規約チェックは、原稿の文字列だけで判定できる層／物件DBとの突合が必要な層／人の確認が必須な層に分けて設計します。禁止表現の検出だけを実装しても、実務で事故になるおとり広告は防げません。
不動産広告の掲載原稿は、AIで規約チェックできますか？
一部はできます。ただし「原稿を読ませて違反かどうか答えさせる」設計にすると、実務で問題になる部分がまるごと抜け落ちます。
チェック項目は、判定に必要な情報がどこにあるかで3層に分かれます。
| 層 | 判定に必要な情報 | 代表的な項目 | AIの役割 |
|---|---|---|---|
| L1: テキスト内で完結 | 原稿の文字列のみ | 特定用語・最上級表現、必須記載事項の欠落、原稿内の数値矛盾 | 検出と修正案の提示（自動判定可） |
| L2: 外部データとの突合 | 原稿＋物件DB・図面・地図・媒介契約情報 | 成約済み物件の掲載、面積・築年月・所在階の相違、徒歩分数の根拠、広告掲載承諾 | 突合処理が主役。AIは差分の説明と重要度の整理 |
| L3: 人の確認が必須 | 現況・契約・当事者の意思 | 写真と現況の一致、告知事項の記載要否、掲載可否の最終判断 | 確認項目を提示するだけ。判定はしない |
事故の多くはL2で起きます。L1だけを実装したツールは「動いているが事故は減らない」状態になります。
なぜ禁止語リストだけでは事故が防げないのですか？
おとり広告は、原稿の文言が正しいまま発生するからです。
成約済みの物件がポータルに残っている状態を考えてください。賃料も面積も駅からの分数も、掲載当時は正確です。文言に禁止表現もありません。テキスト検査は何も検出しません。それでも、取引できない物件が掲載され続けている状態です。
同じ構造の事故がほかにもあります。
- 販売中止・取り下げ後の掲載残存
- 別物件の外観写真・間取図の流用（文言は正しい）
- 図面上の面積と入稿データの面積が違う（どちらの数字も表記としては自然）
- 媒介契約が終了しているのに掲載が残っている
- 価格改定後、本文のフリーテキストだけ旧価格のまま
いずれも「原稿の外にある事実」と照合しないと検出できません。ここを設計に入れるかどうかが、規約チェック機能の実用性を決めます。
L1（テキスト検査）では何を検出しますか？
原稿の文字列だけで完結する項目です。ここは自動判定に向いており、修正案の提示までできます。
1. 特定用語・表現の検査
不動産の表示に関する公正競争規約では、使用にあたって条件が付く用語や、原則として使えない表現が定められています。最上級を示す表現、優良性を断定する表現、根拠の併記が必要な表現などです。これらは辞書と正規表現で拾えます。
ただし単純な文字列一致では過検知が増えます。「完全」「日本一」といった語は、設備名や周辺施設の固有名詞に含まれることがあります。候補を正規表現で抽出し、文脈判定だけをLLMに任せる二段構成にすると誤検知を抑えられます。
2. 必須記載事項の欠落
取引態様、所在地、交通、面積、価格または賃料、管理費・共益費、築年月、免許番号など、ポータルの入稿項目が空になっていないかを検査します。これは構造化データのバリデーションであり、LLMを使う必要はありません。決定的なロジックで実装します。
3. 原稿内の自己矛盾
見落とされがちですが、効果が大きい項目です。
- 構造化入力欄の賃料と、PRコメント本文に書かれた賃料が違う
- 入力欄の駅徒歩と、キャッチコピーの「駅徒歩◯分」が違う
- 入力欄の間取りと、本文の記述が違う
- 「即入居可」と書かれているのに入居可能日が先の日付になっている
フリーテキストから数値・条件を抽出し、構造化フィールドと突き合わせる処理です。抽出はLLMが得意で、比較は決定的ロジックで行います。外部データを必要としないため、L1に置けます。
4. 用語の定義条件
「新築」のように、規約上の定義を満たさなければ使えない用語があります。使用が検出された場合は、判定に必要なデータ（建築時期・入居履歴など）をL2側の突合に回します。L1で拾い、L2で確定させる項目です。
L2（データ突合）では何を照合しますか？
原稿を「文書」ではなく「主張の集合」として扱い、それぞれに突合先を割り当てます。
| 原稿上の主張 | 突合先 | 検出したい状態 |
|---|---|---|
| 募集中である | 物件DBのステータス、成約登録 | 成約済み・取り下げ済みの掲載残存 |
| 専有面積◯㎡ | 図面データ、物件マスタ | 入稿値と図面の相違、壁芯/内法の取り違え |
| 築年月◯年◯月 | 物件マスタ、登記情報 | 誤入力、旧データの流用 |
| 駅徒歩◯分 | 経路距離の計算結果 | 起点・終点の取り違え、直線距離での算出 |
| 所在階・総戸数 | 物件マスタ | 部屋番号との不整合 |
| 取引態様・広告可否 | 媒介契約情報、元付からの広告承諾記録 | 承諾期限切れ、専任解除後の掲載 |
| 掲載画像 | 画像ハッシュ、Exif、他物件の画像 | 他物件からの流用、撮影日の古さ |
| 価格・賃料 | 改定履歴 | 改定反映漏れ、二重価格表示の根拠不足 |
ここでの実装上の要点は3つです。
照合ロジックはAIに書かせない。 面積が一致するかどうかは決定的な比較処理です。LLMに判断させると出力が揺れ、同じ原稿で結果が変わります。AIの役割は、図面PDFや媒介契約書といった非構造データから比較可能な値を取り出すところまでに限定します。
許容差を項目ごとに定義する。 面積は小数第2位までの一致を求めるのか、表記の丸めを許容するのか。徒歩分数は再計算結果と何分までの差を許容するのか。この閾値をルール表に持たせ、後から調整できるようにします。
突合先が無い項目は「未検証」と表示する。 図面データが未登録の物件で面積を照合できない場合、「問題なし」と表示してはいけません。「検証済み」「違反の疑い」「未検証」の3値で返すのが安全な設計です。
なお、レインズのデータを自動処理に利用する場合は、運用規程上の取り扱いを事前に確認してください。取得方法や利用範囲の可否は、システム設計より先に整理すべき論点です。
L3（人の確認）に残すのはどこまでですか？
現況・契約・当事者の意思に関わる項目は、システムから判定を出しません。
- 掲載写真が当該物件の現況を写しているか（撮影時期、リフォーム前後）
- 告知事項・心理的瑕疵の記載要否
- 貸主・売主が掲載を承諾しているか、掲載範囲の合意内容
- 図面の作成者・利用許諾
- 最終的な掲載可否
これらについてシステムが出すのはチェックリストだけです。「写真は3か月以内に撮影したものですか」「告知事項の有無を確認しましたか」という確認項目を提示し、担当者のチェックと氏名・日時を記録します。判定を出さないことを明示するのが重要で、ここで「問題なし」と表示してしまうと、確認したつもりの状態を作ってしまいます。
チェックルールはどう保守しますか？
ルールはプロンプトに埋め込まず、ルール表として外部に持ちます。
プロンプトに書き込む設計は、初期構築は速いのですが運用で行き詰まります。規約改定やポータルの入稿仕様変更のたびにエンジニアの作業が必要になり、変更履歴が残らず、「なぜこの指摘が出たのか」を根拠までたどれません。
ルール表に最低限持たせる列は次のとおりです。
| 列 | 内容 |
|---|---|
| ルールID | 指摘に必ず付与する識別子 |
| 層 | L1 / L2 / L3 |
| 対象ポータル | 全社共通 / ポータル個別 |
| 検査対象フィールド | 本文、キャッチコピー、面積、画像 など |
| 判定方式 | 辞書 / 正規表現 / 突合 / LLM文脈判定 |
| 重大度 | block（掲載不可） / warn（要確認） / info（参考） |
| 根拠 | 規約の該当箇所、ポータルの入稿ガイドライン、社内規程 |
| 出典URL | 一次情報へのリンク |
| 最終確認日・確認者 | いつ誰が原典と突き合わせたか |
| 例外可否 | 例外登録を許すかどうか |
出典URLと最終確認日の列が、この表の実質的な価値です。規約は改定されます。半年前に確認したきりのルールが残っていないかを、一覧で棚卸しできる状態にしておきます。
指摘を表示する際は、必ずルールIDと根拠を併記します。根拠が見えない指摘は現場で無視されます。
掲載フローのどこに組み込みますか？
担当者が回避できない経路上に置きます。「チェックボタンを押したら診断する」独立ツールは、忙しい日ほど押されません。
推奨する配置は5点です。
- 下書き保存時（非同期） — info / warn を画面に表示。作業を止めない。
- 承認申請時（同期） — block のルールが未解消なら申請できない。ここが一次ゲート。
- ポータル入稿API直前（同期） — 承認から入稿までの間に物件ステータスが変わっている可能性があるため、直前にもう一度L2を回す。
- 掲載中の日次再検査（バッチ） — 掲載済み原稿を毎日、物件DBの成約フラグ・媒介契約の有効期限・価格改定履歴と突合する。おとり広告対策の本体はここです。掲載時点のチェックでは、時間経過で発生する乖離を防げません。
- 掲載停止までの導線 — 再検査で乖離を検出したら、担当者への通知だけで終わらせず、一定時間内に対応がなければ掲載停止申請を自動起票する。
例外登録を許す場合は、理由の記述と有効期限の入力を必須にします。期限が切れたら再び指摘が復活する設計にしておくと、なし崩しの例外が積み上がりません。
導入時はどう立ち上げますか？
ルール単位で shadow → warn → block と昇格させます。
いきなり block で本番投入すると、誤検知で入稿が止まり、現場から「使えない」と判断されて終わります。手順は次のとおりです。
- shadow モード — 判定は走らせるが担当者には見せず、ログだけ取る。既存の掲載原稿に対して過去分を一括で流し、どのルールがどれだけ発火するかを見る。
- 発火内容のレビュー — 発火した指摘を、実務担当者と一件ずつ「本当に直すべきか」で仕分ける。ここで許容差やホワイトリストを調整する。
- warn 昇格 — 誤検知がほぼ無くなったルールから、担当者に表示する。
- block 昇格 — warn 期間で「指摘に従って修正された割合」が高いルールだけを block にする。指摘されても直されないルールは、block にする前にルール自体を疑います。
L1の必須項目欠落のような決定的判定は早期に block へ、LLMの文脈判定に依存するルールは warn に留める、という切り分けが現実的です。
この仕組みでできないこと
- 規約適合の保証はできません。 表示規約への適合可否は、最終的に公正取引協議会やポータル側の審査、および自社の判断に委ねられます。システムは見落としを減らす道具であり、法的判断の代替にはなりません。個別案件は専門家にご確認ください。
- 現況との一致は検証できません。 掲載写真が本当にその部屋なのか、リフォーム前の写真ではないかは、現地または撮影記録を人が確認するしかありません。
- 告知事項の要否は判定できません。 記載漏れの「疑い」を提示することはできても、要否の判断は行いません。
- 物件DBが正しくないと機能しません。 突合の前提は自社データの鮮度です。成約入力が数日遅れる運用のままでは、日次再検査は空振りします。システム導入より先に、成約時の入力タイミングを決める必要があります。
- 規約改定に自動追随しません。 ルール表を人が更新する運用とセットでなければ、時間とともに陳腐化します。
- LLM判定は完全には再現しません。 同じ原稿でも出力が揺れます。だからこそ block 判定は決定的ロジックに寄せます。
まとめ
- チェック項目は「テキスト内で完結／外部データとの突合／人の確認必須」の3層に分ける。事故はL2で起きる。
- おとり広告は文言では検出できない。掲載中の原稿を日次で物件DBと突合する再検査が本体になる。
- 照合ロジックはAIに書かせない。AIは非構造データからの値の抽出と文脈判定に限定し、比較は決定的処理で行う。
- ルールはプロンプトに埋め込まず、ルールID・根拠・出典URL・最終確認日を持つ表として保守する。
- チェックは承認申請時と入稿API直前という回避できない経路上に置く。ルール単位で shadow → warn → block と昇格させる。
ご相談について
エクサテックは、不動産・建設業の現場に入り込んで業務システムと生成AIを設計・実装しています。株式会社イーリアルティ様の転記エージェント開発でも、契約の前段階から何度も現場に足を運び、困りごとを理解するところから始めました。
掲載原稿のチェックは、既存の物件DBやポータル入稿の運用と切り離しては設計できません。現状のフローを伺ったうえで、どこまでを自動判定に載せられるかの切り分けからご一緒します。まずは現在の入稿手順をお聞かせください。
