物件の写真を仕分けて、掲載用の並び順と説明文の下書きまで作る

処理の起点を決める

物件フォルダに写真が追加されたときを起点にします。ただし、撮影直後は追加が続くため、最後の追加から15分待ってから開始します。1枚追加されるごとに処理を始めると、同じ物件を何度も処理することになります。

物件番号をフォルダ名にする運用を先に決めます。ここが揃っていないと、どの物件の写真かを判定する処理が必要になり、構成が重くなります。

入力データを集める

2番目を必ず渡してください。 紹介文の数値はすべてここから取ります。写真から推測した数値を書かせないための材料です。

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

写真： Googleドライブから取得します。1枚あたりの解像度が高すぎると費用と時間がかさむため、判定用には縮小した画像を使い、掲載には元の画像を使います。

物件の条件： 物件管理システムのAPI、または日次で書き出したファイルを参照します。

表示のルール： 不動産の広告には、業界が定めた「不動産の表示に関する公正競争規約」があります。この構成に関係するのは次の点です。

• 写真は取引するものを表示すること。 建築工事の完了前などで取引する建物の写真を使えない事情がある場合に限り、その施工者が過去に施工した建物の写真を使えますが、他の建物である旨を写真に接する位置に明示することなどが求められます。外観は構造・階数・仕様が同一で規模・形状・色などが類似するもの、内部は写される部分の規模・仕様・形状などが同一のものに限られます
• 完成予想図やコンピュータグラフィックスは、その旨を明示して用いること。 周囲の状況について現況に反する表示をしないこと
• 徒歩による所要時間は、道路距離80メートルにつき1分として算出し、1分未満の端数は1分とすること
• 存在しない物件や取引できない物件を掲載する「おとり広告」が問題になっており、掲載数が管理できる件数を超えていることが原因の1つとして挙げられています

この構成では、規約の判断をAIにさせません。 「他の建物の写真である可能性がある」「工事前の可能性がある」と見つけて人に回すところまでです。

AIへ渡す前に整形する

1. 重複の除去 … 同じ構図の連写が混ざります。似た画像をまとめ、1枚だけを判定に回します
2. 縮小 … 判定用に長辺を一定サイズへ縮小します。掲載用の元画像は別に保持します
3. 撮影日時の取得 … 画像の撮影日時を読み、リフォームの完了日より前の写真に印を付けます。 これが工事前の写真を弾く手がかりになります
4. 間取り図の分離 … 間取り図やパンフレットの画像は、部屋の写真とは別に扱います
5. 向きの補正 … 縦横が回転している写真を直します

3番が効きます。工事前の写真の混入は、目で見ても判断が難しいことがあります。撮影日時という機械で読める手がかりを使うほうが確実です。

AIに処理させる

写真1枚ごとに、次を判定させます。

そのうえで、物件全体について紹介文の下書きを作らせます。

設備の有無を写真から判定させないでください。 「この写真から食洗機がありそう」という判定は、掲載可否の判断材料にはなっても、紹介文に書く根拠にはなりません。紹介文の設備は物件データベースの値だけを使います。

指示内容を固定する

あなたは賃貸物件の掲載担当を補佐する担当者です。
物件の写真と、物件データベースの条件を渡します。
写真の仕分けと、紹介文の下書きを作ってください。

【厳守事項】
- 紹介文に書く数値と設備は、下の物件データの値だけを使ってください。
  写真から読み取った内容を数値や設備として書かないでください。
- 徒歩分数、面積、築年、賃料を自分で計算したり言い換えたりしないでください。
- 写真に人物、表札、郵便物、宅配ボックスの名前、車のナンバー、
  他社の看板が写っている場合は、掲載可否を「不可」にし、
  何が写っているかを issues に書いてください。
- 同じ部屋の写真で、内装の状態が他の写真と明らかに違うものがある場合は、
  掲載可否を「要確認」にし、理由に「工事前の可能性」と書いてください。
- 写真の内容を誇張しないでください。
  「開放感あふれる」「圧倒的な採光」のような表現を使わないでください。
- 眺望の写真について、周辺の建物が今後変わらないことを示す表現を書かないでください。
- 紹介文は300字以内。断定できないことは書かないでください。

【物件データ】
{property_data}

【掲載順の定義】
{photo_order}

【写真】
{images}

「写真から読み取った内容を数値や設備として書かない」の1行が、この構成でもっとも重要です。 画像を扱える生成AIは、写真を見て「広々とした12畳ほどのリビング」と書きます。物件データの面積と食い違えば、不当な表示につながります。

出力形式を固定する

{
  "property_id": "",
  "photos": [
    {
      "file": "",
      "category": "",
      "quality": "good | blurry | dark | tilted",
      "issues": [],
      "taken_at": "",
      "before_renovation_suspected": false,
      "usable": "可 | 要確認 | 不可",
      "reason": "",
      "caption": "",
      "order": 0
    }
  ],
  "missing_categories": [],
  "listing_draft": "",
  "used_property_fields": []
}

missing_categories は、掲載順の定義にあるのに写真が無い種別です。「浴室の写真がない」と分かれば、再撮影の指示が出せます。 掲載してから気づくと、撮り直しに再訪が必要になります。

used_property_fields には、紹介文で使った物件データの項目名を入れさせます。ここに無い数値が紹介文に出てきたら、写真から推測した数値です。機械的に検出できます。

システムへ連携する

確認用のシートに、写真の一覧（サムネイル・種別・可否・理由・キャプション）と紹介文の下書きを出します。掲載担当はこの画面だけを見て確認します。

CMSとポータルへの登録は自動化しません。 掲載は対外的な広告であり、登録した時点で責任が発生します。担当者の確認を経てから登録します。

人が確認する

全件、人が確認します。

特に次の3点は、人が見ないと判断できません。

1. 他の建物の写真が混ざっていないか … 混ざっていた場合、規約上の扱いを確認する必要があります
2. 工事前の写真でないか … 撮影日時とリフォーム完了日で候補は絞れますが、最終判断は人が行います
3. 紹介文の内容が物件データと合っているか … 使った項目名の一覧と突き合わせます

確認を速くするための設計が要ります。

• 「不可」「要確認」の写真を先頭にまとめる
• 写り込みが検出された箇所を、写真の上に印で示す
• 紹介文の中で、物件データから取った数値に色を付ける
• 不足している種別を大きく表示する

例外に対処する

記録を残す

• 撮影した写真の原本と撮影日時
• AIの判定結果（種別・可否・理由）
• 掲載担当が変更した点（可否の変更、並び順、文面）
• 実際に掲載した写真と掲載開始日
• 差し替え・削除した写真とその理由

4番目と5番目は、規約上の指摘を受けたときに経緯を示す材料になります。 掲載期間中にどの写真を使っていたかを、後から確認できる状態にしてください。

写真には入居者や近隣の情報が写り込むことがあります。保管場所の閲覧範囲を、掲載担当と営業に限定します。