退去立会いの写真から、入居時との差と原状回復の負担区分の一次案を作る

処理の起点を決める

立会いアプリから住戸フォルダへ写真が保存されたことを起点にします。 事務所へ戻るまでに一次案ができている形を狙います。日次のまとめ処理にはしません。 繁忙期は1日に3件から4件回るので、まとめると全部が夕方以降に寄ります。

合図は、アプリ側で「立会い終了」を押した時点です。1枚ごとに動かすと、対応づけが途中の状態で計算が走ります。そのとき揃っている写真を1組として扱い、処理済みの住戸には印を付けます。

入力データを集める

質を決めるのは、上の3つです。 入居時の写真が無ければ比べる相手がなく、入居時チェックシートが無ければ「入居時から既にあった」という記録が使えません。どちらも無い箇所は判定不能にしかなりません。

契約データの入居日と退去日は、必ず機械から引きます。 生成AIは画像のメタデータを読まないとされているので、写真から撮影日は分かりません。日付は文字として別に渡します。いちばん下の行は社内にあるものをそのまま使い、担当者ごとにばらばらに使われていること自体を直します。

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

写真は住戸フォルダから直接読みます。鍵は、部屋タグと部位タグでキーを作れることです。 room と part を組にした living/wall_a のような文字列を作り、同じキーのものを対にします。

タグを部位タグの検算に使えるのが、思わぬ拾いものです。 公開されている例では、家の外観の写真に grass outdoor house yard roof が信頼度つきで返っています。浴室と記録された写真に屋外のタグが強く出ていれば、付け間違いを疑えます。

呼び出しは Analyze Image の API で、features に denseCaptions Tags Objects を含めます。入居時と退去時は、それぞれ別に分析にかけます。 2枚をまとめて差を返す機能ではありません。

AIへ渡す前に整形する

1. 画像分析へ渡せる形にする … 入力は JPEG、PNG、GIF、BMP、WEBP、ICO、TIFF、MPO、20メガバイト未満、50×50ピクセルより大きく16,000×16,000ピクセル未満とされています
2. 生成AIへ渡す寸法の調整 … 1枚あたり8000×8000ピクセル、10メガバイトまでです。1リクエストに20枚を超える画像を入れると、そのリクエストの全画像により厳しい寸法制限がかかります。 各辺2000ピクセル以下にそろえるか、1回の呼び出しを20枚以下に抑えます
3. 向きの統一 … 天地が逆の写真をそろえてから比べます
4. 明るさの記録 … 明るさを数値で持ち、極端に違う対には印を付けます。明るさの差を変化として拾わせないためです
5. 対の作成 … 同じ room と part のキーで対にします。対が作れないものは、ここで判定不能として外します
6. 位置情報の除去 … 送信前に、画像に埋め込まれた位置情報を落とします

2番の枚数の制限は、実装の形を決めます。 1住戸で20か所を撮れば入居時と退去時で40枚です。部位ごとに1回ずつ呼べば、1回あたり2枚で収まります。 まるごと1回で送ると、寸法の制限に当たって細かい傷が読めなくなります。

4番を省くと、変化ありの件数が跳ね上がります。 カーテンを開けた写真と閉めた写真では、同じ壁が違う色に見えます。数値で持っておけば、後から「明るさの差が原因だった」と説明できます。

AIに処理させる

させるのは、2枚の写真を見比べて変化の有無を選び、それぞれの見え方を日本語で書くことだけです。 領域は処理側が番号で渡し、生成AIはその番号を指すだけにします。

右端の列が、この構成では特に効きます。 画角や明るさが違うだけの差を changed にすると、一次案が使いものになりません。「区別がつかない」という選択肢を用意し、そこに逃がします。

1行目を守らせる仕組みは、指示文ではなく出力の形に置きます。 区分を書く項目をスキーマに持たせなければ、書く場所がありません。指示文だけで禁じると、「通常の使用による範囲と思われます」と説明文に混ざってきます。 3行目も同じで、extent を3択にしてあるのは数字を書かせないためです。

指示内容を固定する

あなたは賃貸住宅の退去立会いの記録を作る担当者です。入居時の写真（Image 1）と
退去時の写真（Image 2）を見比べ、変わっている箇所と見え方を日本語で書いてください。

【この住戸の情報】
住戸ID: {unit_id}／部屋: {room}／部位: {part}
入居時の撮影日: {before_date}／退去時の撮影日: {after_date}
（写真から撮影日は読み取れません。上の値だけを使ってください）

【見るべき領域】
{regions}
（画像分析が返した領域です。findings では、この region_id だけを使ってください）

【入居時チェックシートの記載】
{move_in_notes}
（記載のある傷・汚れは unchanged とし、note_for_human にその旨を書いてください）

【change の選び方】
- changed ....... Image 2 に、Image 1 には見られない状態がある
- unchanged ..... 見え方に差が無い。入居時チェックシートに記載がある場合も含む
- undetermined .. 比べられない。理由を undetermined_reason に書く

【厳守事項】
- 通常損耗か、経年変化か、借主の責めに帰すべき損耗かを書かないでください。
  負担区分は人が決めます。区分にあたる言葉を説明文に混ぜないでください。
- 原因を書かないでください。「引越しのときについた」など、写真から分からない
  ことを推測せず、見え方だけを書いてください。
- 面積・寸法・個数を数字で書かず、extent を選ぶだけにしてください。
  数量は担当者が採寸して入れます。
- 座標を作らず、位置は region_id で指してください。
- Image 1 に写っていない範囲は undetermined とし、undetermined_reason に
  out_of_frame または no_before_photo を入れてください。
- 明るさ・画角・向きが違うだけの差を changed にしないでください。区別がつかない
  ときは undetermined とし、理由に angle_differs または too_dark を入れてください。
- 写真に人が写っていても、誰かを特定しないでください。
- appearance_before と appearance_after には見えている状態をそのまま書き、
  比べた評価の言葉を入れず、迷ったときに changed を選ばないでください。

「区分にあたる言葉を混ぜない」と書いても、説明文には漏れてきます。 だから出力の形のほうで受け止めます。指示文は漏れを減らすための二重の網です。入居時チェックシートを渡すのは、既にあった傷を毎回拾わせないためです。

画像はテキストより前に置き、複数の画像を送るときはそれぞれの前に「Image 1:」のような短いラベルを置くとされています。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力を使い、スキーマに合う形だけを返させます。

{
  "unit_id": "",
  "room": "",
  "part": "",
  "findings": [
    {
      "region_id": "",
      "change": "changed | unchanged | undetermined",
      "appearance_before": "",
      "appearance_after": "",
      "extent": "point | partial | whole",
      "model_confidence": "high | medium | low",
      "undetermined_reason": "no_before_photo | out_of_frame | too_dark | angle_differs | none",
      "note_for_human": ""
    }
  ]
}

構造化出力は、応答をスキーマに沿わせる仕組みです。 スキーマ違反での再試行が要らないのが、日々80件を回す処理では効きます。ただし、使える書き方には範囲があります。 オブジェクトでは additionalProperties を false にする必要があり、minimum や maximum といった数値の制約、文字列の長さの制約、パターンの指定は使えないとされています。

この制限が、設計をひとつ決めます。 負担割合を生成AIに返させるなら、0から1の範囲をスキーマで縛りたくなります。それができないなら、範囲外の値が返っても機械的には止まりません。 割合を計算処理の側に置く理由が、ここにもあります。

システムへ連携する

賃貸管理システムへは書き込みません。 この構成が出すのは一次案までで、確定データを作るのは担当者の操作です。書き込みを足すと、区分が決まる前の金額が正式な記録として残ります。

負担割合の計算は、次の材料から行います。

割合は、耐用年数から入居期間を引いた年数が、耐用年数に対してどれだけかという形で出します。 金額の候補は、単位あたり単価に数量を掛け、その割合を掛けたものです。東京都のガイドラインでは、破損部分の補修費用は最小単位で経過年数を考慮して負担割合を算定するとされています。

人が確認する

人が見るのは全件です。 第10章の18分は、確認を省いて作った数字ではありません。省いたのは、写真を探す時間と、20か所を1つずつ開いて見比べる時間です。

1. 判定不能を先に見る … 入居時の写真が無い箇所、画角が違う箇所。ここが多い住戸は一次案を使いません
2. 変化ありの箇所を見る … appearance_before と appearance_after を読み、必要なら写真を開きます
3. 拾えていない箇所が無いかを見る … 立会いで気になった箇所が一覧に出ているか。出ていなければ手で足します
4. 区分を決める … 通常損耗・経年変化／借主の責めに帰すべき損耗／判定不能を選びます
5. 数量を入れ、記録を残す … 採寸した値を入れて金額を確定し、誰がいつどの区分にしたかを残します

3番目を省かないでください。 画像の5%未満の物体は通常検出されず、近くに置かれた物体も検出されにくいとされています。細い擦り傷や家具の陰の汚れは一覧に出ません。一次案は出発点で、見落としが無いことの保証ではありません。

例外に対処する

上の2行が、実際にはいちばん多く出ます。 画像分析の問題ではなく、入居時の撮影が決まっていなかったという問題です。 比べる相手が無いという状態は、精度を上げても変わりません。

記録を残す

• 入居時・退去時の写真と、部屋タグ・部位タグ・撮影の順番
• 画像分析が返したJSONの全文（denseCaptionsResult、tagsResult、objectsResult）
• 生成AIが返した findings と、そのとき渡した領域の一覧
• 計算に使った単価表と耐用年数の表の内容（そのときの版）
• 担当者が決めた区分と、決めた人・決めた日時
• 一次案と最終の明細の差（どの箇所の判定が覆ったか）と、判定不能の件数

4番目で「そのときの版」を残すのは、単価表が改定されるためです。 改定後に過去の精算を見直すと、金額が合わない理由が分からなくなります。最後の行は、この仕組みを育てる材料です。 判定が覆った箇所を並べると、説明のどこが人の判断とずれているかが見えます。判定不能の件数は、撮影の手順が守られているかを表します。