賃貸物件のポータルの掲載文とチラシを、不動産の表示に関する公正競争規約の禁止表現と物件データとの食い違い・必要な表示の抜けで、掲載前に校正する

処理の起点を決める

物件管理のシステムで、物件の状態が「掲載申請」になったことを起点にします。 書いている途中の文面を校正しないために、担当者が書き終えて申請したことを合図にします。

起動のしかたは、物件管理のシステムが何を出せるかで決まります。状態の変化を通知できるなら、その通知で Azure Functions を呼びます。 通知が無いシステムなら、掲載申請の一覧を数分おきに書き出して読み、まだ校正していないものだけを処理します。どちらでも、物件番号と申請の版で一度だけ処理するように、処理済みの組を記録します。

書き換えの再掲載は、変わった文だけを校正します。 前回の申請の文面と比べ、変わっていない文は前回の指摘をそのまま引き継ぎます。1行だけ書き換えた再掲載に、全文の指摘をもう一度出さないためです。

入力データを集める

質を決めるのは、用語の一覧の「使ってよい条件」の列です。 公正取引協議会の解説では、「特選」「厳選」は実際に選別の基準を設けている場合、「最高」「格安」は根拠となる事実を併せて表示する場合に限って使えるとされています。条件を列に書いておくと、AIは「この文には根拠の事実が併せて書かれていない」と指摘できます。 条件の無い一覧だと、用語を見つけた時点で一律に指摘するだけになります。

物件データは、AIの判断の材料であると同時に、照合の相手です。 文面に書かれた徒歩分数や築年数を、物件データの値と比べます。物件データの欄が空なら照合できないので、空の欄はそれ自体を指摘にします。

データの取得方法を決める

チラシは画像ではなく、文面を文字で取り出します。 作成ソフトから文字として書き出せない場合は、チラシのもとにしたポータルの掲載文を使い、チラシで足した見出しだけを手で入れる運用にします。画像から文字を読み取る段を足すと、読み取りの誤りが指摘に混ざります。

用語の一覧には版の番号を付けます。 広告責任者が「この表現は通す」と判断を変えたとき、どの版で校正したかが分からないと、同じ表現への指摘が日によって違う理由が追えません。

AIへ渡す前に整形する

1. 必要な表示事項の欄の判定 … 物件の種別に応じて、必要な欄が埋まっているかを見ます。中古の賃貸マンションや貸家なら、別表9の項目です
2. インターネット広告の項目の判定 … ポータルの掲載では、情報公開日（又は直前の更新日）と次回の更新予定日が入っているかを見ます
3. 徒歩分数の再計算 … 道路距離の欄があれば、80メートルにつき1分、1分未満の端数は1分として計算し、物件データの徒歩分数と比べます
4. 築年月からの判定 … 築年月と入居の履歴から、「新築」と書ける物件かを判定します
5. 文の分割 … キャッチコピー、コメント、備考、チラシの文面を、句点と改行で1文ずつに分けます
6. 前回との差分 … 再掲載なら、前回の文面と比べて変わった文に印を付けます
7. 物件の特定につながる情報の確認 … コメントに入居者や貸主の名前、部屋番号が書かれていないかを見て、あれば伏せたうえで指摘にします

1番目から4番目をAIにさせないのは、規約と物件データで答えが決まるからです。 表示規約の施行規則は、徒歩による所要時間を道路距離80メートルにつき1分間として算出し、1分未満の端数は1分とすると定めています。計算で決まるものは計算で決めます。

2番目は、ポータルの掲載に固有の項目です。 別表9では、情報公開日（又は直前の更新日）と次回の更新予定日はインターネット広告の項目になっています。チラシには求められない項目なので、媒体で切り替えます。

AIに処理させる

させるのは、文面を1文ずつ見て、指摘を3種類に分けて挙げ、直しの案を書くことです。

2行目は、AIに比べさせません。 「駅徒歩3分」という記載から、walk_minutes という項目名と 3 という値を返させるだけです。物件データの6分と比べるのは、後段の規則です。 AIが比べると、コメントに書かれた別の駅への分数を、最寄駅への分数として比べてしまいます。記載が最寄駅についてのものかが分からない場合は、station に書かれた駅名をそのまま返させます。

用語は、規約の区分に沿って一覧にします。 公正取引協議会の解説では、合理的な根拠が無ければ使えない用語として、完全無欠を意味する用語（完全、完ぺき、絶対、万全など）、競争事業者より優位であることを意味する用語（日本一、日本初、業界一、超、当社だけ、抜群など）、一定の基準による選別を意味する用語（特選、厳選など）、最上級を意味する用語（最高、最高級、極、特級など）、著しく安いという印象を与える用語（格安、破格、激安など）、著しく人気が高い印象を与える用語（完売など）が挙げられています。例示以外の似た用語も同じ扱いとされているので、AIには「似た語も区分に当てる」ように指示します。

4行目がいちばん起きやすい失敗です。 「もっと魅力的に」と頼まなくても、指摘のある文を直すときにAIは新しい宣伝文句を足します。足された文句が、別の使い方の決まった用語を含んでいることもあります。 直しの案は、指摘の箇所を取るか置き換えるだけにします。

指示内容を固定する

あなたは賃貸住宅の仲介会社の広告担当で、ポータルサイトの掲載文と募集チラシの
文面を、掲載の前に校正する担当です。渡された文を1文ずつ見て、指摘と直しの案を返してください。

【やること】
1. 用語の一覧の区分に当たる語を拾い、term_findings に挙げる。
   一覧に無くても、同じ区分の意味を持つ似た語は挙げる。
   その文の中に、一覧の「使ってよい条件」を満たす記載があるかを condition_met に書く。
2. 徒歩分数、築年数、面積、設備、賃料・初期費用について書かれた記載を拾い、
   data_claims に、項目名（walk_minutes / building_age / area / equipment / fee）と、
   書かれた値をそのまま返す。徒歩分数は、書かれた駅名も station に写す。
3. 表記の決まりに反する書き方を notation に挙げる。
4. 指摘のある文には、直しの案を rewrite に書く。

【厳守事項】
- 規約に違反するか、違反しないかを書かないでください。
  「違反です」「問題ありません」という言葉を使わないでください。
- data_claims の値を、物件データと比べないでください。比べるのは後の工程です。
- 数値を計算し直したり、丸めたりしないでください。書かれた文字をそのまま返してください。
- quote は原文の文字を1字も変えずに写してください。要約や言い換えをしないでください。
- 直しの案に、新しい宣伝文句を足さないでください。
  指摘の箇所を取るか、用語の一覧の置き換えの例か、物件データの値に置き換えるだけにしてください。
- 迷ったときは term_findings に挙げてください。挙げずに済ませないでください。

【媒体】{media}
【物件データ】{property_data}
【文面（1文ずつ、番号付き）】{sentences}
【用語の一覧（版：{term_version}）】{term_list}
【表記の決まり】{notation_rules}

「比べないでください」を名指しで書かないと、AIは比べます。 物件データを一緒に渡しているので、「徒歩3分は物件データの6分と食い違います」と親切に書いてきます。その比較が別の駅についての記載だったとき、誤った指摘になります。 比べる工程を規則に置くために、AIには拾うところまでを頼みます。

「新しい宣伝文句を足さない」は、直しの案の質より、直しの案の安全のための指示です。 店舗の担当者は直しの案をそのまま貼ることが多く、足された文句は誰も校正しないまま掲載されます。

出力形式を固定する

次の形の JSON を、構造化出力で受け取ります。

{
  "property_id": "",
  "term_version": "",
  "sentences": [
    {
      "sentence_no": 2,
      "quote": "",
      "term_findings": [
        { "term": "格安", "category": "low_price", "condition_met": false }
      ],
      "data_claims": [
        { "item": "walk_minutes", "value": "3", "station": "" }
      ],
      "notation": [ { "issue": "", "quote": "" } ],
      "rewrite": ""
    }
  ]
}

構造化出力を使う理由は、後段で規則を当てるためです。 data_claims が項目名と値で返るので、Functions が物件データの同じ項目と比べられます。公式の説明では、すべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があるとされています。指摘の無い文も、空の配列で返させます。

判定は Functions が次の規則で決めます。

data_claims の照合は、駅名で分けます。 station が物件データの最寄駅と同じなら徒歩分数を比べ、違う駅なら「最寄駅以外の駅の分数」として人に見せます。別の駅への徒歩分数も、物件データの道路距離が無ければ確かめようがないので、指摘として残します。

システムへ連携する

物件データと掲載文そのものには書き込みません。 直しの案を自動で掲載文に入れる作りもできますが、店舗の担当者が知らないうちに文面が変わることになります。直すのは担当者で、この構成は差し戻しのコメントに指摘と案を出すだけです。

人が確認する

本部の広告担当が全件の承認を行います。 開き方を判定で変えます。

1. manager_review を先に見る … 用語と引用、その文に書かれた根拠の事実を読み、広告責任者へ回すかを決めます
2. fix_requested の指摘を確かめる … 物件データとの食い違いは、物件データの側が誤っていないかも見ます
3. 差し戻すかを決める … 採った指摘だけを差し戻しのコメントに残し、店舗へ返します
4. pass を一覧で流し見る … 物件名、キャッチコピー、賃料を並べて見て、掲載を承認します
5. 指摘を退けたら理由を残す … 「根拠の資料あり」「責任者が承認済み」など、選択肢から選びます

2番目で物件データの側を疑うのは、食い違いの半分はデータの入れ間違いだからです。 コメントの徒歩3分が正しく、物件データの6分が別の出入口から測った値ということもあります。どちらを直すかは店舗の担当者が現地を知っています。

目標は、1,500件をならして1件2分です。 指摘のある掲載が3割前後という想定で、それを大きく超える月は、用語の一覧の条件が足りないか、特定の店舗の書き方が崩れています。

例外に対処する

7行目は設計の最初に入れておきます。 AIが応答しなくても、必要な表示事項の欄と徒歩分数の判定は規則で出せます。掲載が止まらないように、規則の判定だけでも返せる形にしておきます。

記録を残す

• 校正にかけた申請の版（物件番号、申請の日時、媒体）
• 物件データの値と、規則による判定の結果
• Azure OpenAI に渡した文面と、返った JSON の全文
• 使った用語の一覧と表記の決まりの版の番号
• 判定、広告担当の採否、退けた理由、広告責任者の判断
• 店舗が直したあとの再申請の判定

退けた理由の記録は、用語の一覧を直す材料になります。 同じ用語で「根拠の資料あり」が続くなら、その根拠の示し方を一覧の条件に書き足す時期です。 公正取引協議会への相談の結果も、用語の一覧の条件に反映します。

店舗ごとの指摘の件数も残します。 特定の店舗で同じ指摘が続くなら、校正より先に、書き方の研修が効きます。