売買仲介で受け取る固定資産税・都市計画税の課税明細書を読み取り、引渡し日での日割り精算の計算表に転記して、物件の表示との食い違いを拾う

処理の起点を決める

契約番号を付けたフォルダに、明細書のファイルが保存されたことを起点にします。 フォルダの名前は契約管理の仕組みの契約番号にそろえ、ファイルを入れた時点でどの契約の明細書かが決まるようにします。ファイル名から契約を推し量る作りにすると、売主の名前の表記ゆれで当たらないものが出ます。

1つの契約に複数のファイルが入ることがあります。土地と家屋で市区町村が違う（境界をまたぐ）場合や、明細書が2枚以上に分かれる場合です。最後のファイルが入ってから10分待って、まとめて処理します。 1枚ずつ処理すると、2枚目の行が無いまま「載っていない行がある」と返してしまいます。

決済の日が近いのに明細書のフォルダが空の契約は、毎朝の一覧で営業担当に知らせます。 明細書が来ないこと自体が、決済の直前に慌てる一番の原因だからです。

入力データを集める

質を決めるのは、2行目と3行目です。 物件の表示がデータで無ければ照合ができず、契約条件が項目で無ければ計算の入力がありません。明細書の側は読み取れば済みますが、契約の側は人が先に入れておく必要があります。

持分は必ず入れます。 マンションの敷地や私道は共有のことが多く、明細書の税額が持分で按分した後の額か、按分する前の額かは、自治体の書式によって違います。持分が無いと、ここを照らせません。

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

読み取りは、連携の処理からレイアウトモデルを呼ぶだけです。features=keyValuePairs と、outputContentFormat=markdown を付けます。 Markdown の出力では、表は結合したセルと複数行の見出しを表せるように HTML の表で返ります。課税明細書の見出しは2段になっていることが多いので、この形のほうが列の対応を取り違えにくくなります。

契約管理の仕組みからは、契約番号で物件の表示と契約条件を引きます。 連携は Power Automate のコネクタか、仕組みの API で行い、読むだけにします。

AIへ渡す前に整形する

1. 形式の確認 … レイアウトモデルが受け付けるのは PDF、画像（JPEG/JPG、PNG、BMP、TIFF、HEIF）、Office 形式などです。スマートフォンの写真はそのまま渡せます
2. ページ数とサイズの確認 … PDF と TIFF は2,000ページまで、ファイルは有料（S0）で500MBまでです。明細書なら十分に収まります
3. 画像の寸法の確認 … 50×50ピクセルから10,000×10,000ピクセルの間に収めます
4. 文字の大きさの確認 … 1024×768の画像で12ピクセルが読み取れる最小の高さで、150dpiで約8ポイントの文字にあたります。明細書の税額の欄は文字が小さいので、写真は明細書を画面いっぱいに撮ってもらいます
5. 余計なページを除く … 納税通知書の本体や納付書が一緒にスキャンされていれば、明細書のページだけを残します
6. 個人番号の欄を確かめる … 明細書に個人番号は通常ありませんが、売主が身分証の写しを一緒に入れてしまうことがあります。 明細書以外のページは処理に回しません

4番目は、写真で受け取るときに必ず効いてきます。 明細書を机に置いて少し離れて撮ると、税額の数字が下限に近くなり、「3」と「8」、「1」と「7」の取り違えが税額の行に出ます。 金額の読み違いは、計算が正しくても精算金をずらします。

AIに処理させる

させるのは、明細書の行ごとに項目を取り出し、根拠にした文字列を書き出すことだけです。

面積の欄を「登記」と「課税」に分けて取るのが大事です。 明細書には登記の地積と課税の地積が並ぶ書式があり、私道に使っている部分が非課税になっていると、課税の地積だけが小さくなります。 これは誤りではありません。照合は登記の地積で行い、課税の地積の差は「理由のある差」として別に出します。

2行目が一番起きやすい失敗です。 行ごとの税額が無い書式で、合計を面積の比で割り振って行に埋めることがあります。その瞬間、自治体が計算した額ではない数字が精算書に入ります。

指示内容を固定する

あなたは不動産会社で、売買の決済の前に課税明細書を読み取る担当です。
OCRが返した読み取り結果だけを見て、行ごとに項目を取り出してください。

【取り出すもの】
1. 明細書の年度と納税義務者
2. 土地と家屋の行ごとに、区分・所在・地番または家屋番号・
   地目または種類・登記の面積・課税の面積・価格・課税標準額・
   固定資産税の額・都市計画税の額・摘要
3. 明細書の合計欄の固定資産税と都市計画税の額

【厳守事項】
- 書かれていない値は null にしてください。推測で埋めないでください。
- 行ごとの税額が書かれていない場合、合計や面積から割り振らないでください。
- 計算をしないでください。日割り、合計、按分のいずれもしないでください。
- 地番・家屋番号は、書かれた文字をそのまま写してください。
  「番」を「-」に直すなどの書き換えをしないでください。
- 登記の面積と課税の面積が両方ある場合は、両方を別々に入れてください。
  片方しかない場合は、それがどちらの欄の値かを area_basis に書いてください。
- OCRの信頼度が0.8未満の文字を含む値は、low_confidence に項目名を入れてください。
- evidence には、その行の値を取った元の文字列をそのまま写してください。
- 売買の対象の行かどうかは判断しないでください。すべての行を出してください。
- 課税明細書でないページは document_type に種類を書き、行を出さないでください。

【読み取り結果】{layout_markdown}
【キーと値の組】{key_value_pairs}

「すべての行を出す」を明記しているのは、AIに行を選ばせないためです。 物件の表示を渡すと、AIは気を利かせて対象の行だけを返そうとします。対象でない行を落とすと、照合で「明細書にあって契約に無い行」を拾えなくなります。 選ぶのは処理の側です。そのため、プロンプトには物件の表示を渡していません。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。 Azure OpenAI の構造化出力では、スキーマのすべての項目を必須にし、additionalProperties: false を付けます。値が無い項目は null を許す型にしておきます。

{
  "document_type": "tax_bill_detail",
  "fiscal_year": "令和8年度",
  "taxpayer": "",
  "rows": [
    {
      "kind": "land | building | unknown",
      "location": "",
      "lot_or_house_no": "",
      "category": "",
      "registered_area": null,
      "taxable_area": null,
      "area_basis": "registered | taxable | both | unknown",
      "assessed_value": null,
      "tax_base": null,
      "fixed_asset_tax": null,
      "city_planning_tax": null,
      "remarks": "",
      "low_confidence": [],
      "evidence": ""
    }
  ],
  "total_fixed_asset_tax": null,
  "total_city_planning_tax": null
}

これを処理が照合と計算にかけ、次の計算表を作ります（1月1日起算、引渡し日から買主の負担、年365日、円未満切り捨ての例）。

1つ目の理由は、照合が機械でできることです。 lot_or_house_no と物件の表示の地番・家屋番号を、表記をそろえたうえで突き合わせ、行ごとに matched ／ not_in_bill ／ not_in_contract ／ mismatch を付けます。mismatch は地番は合うが面積や地目が違う行で、登記の後に分筆や地目の変更があったことを示す場合があります。 自由文で返されると、この4つの区分を毎回人が読み取ることになります。

2つ目は、計算を入力ごと残せることです。 計算表の数字がどの行のどの値から来たかを、evidence でたどれます。4月1日起算の契約なら、同じ引渡し日で売主233日・買主132日になり、買主の負担額は大きく変わります。 起算日の入れ違いは計算表の見直しで最も見落としやすいので、起算日を表の上に大きく出します。

システムへ連携する

契約管理の仕組みへの書き込みは、経理が確定した後の1回だけにします。 書くのは精算金の額と、照合の結果に食い違いがあったかどうかの印です。AIの出力を直接書き込む経路は作りません。

人が確認する

営業事務が見るのは、照合の結果と計算表の上の段です。 すべての行が matched で、low_confidence が空なら、起算日・引渡し日・年税額の3つを契約書と見比べて終わりにします。

1. 起算日と引渡し日を見る … 計算表の上に出した値を、契約書の条項と見比べます。ここだけは全件で行います。 引渡し日が契約後に変わっていないかも、営業担当の予定と照らします
2. 食い違いのある行の画像を開く … not_in_bill・not_in_contract・mismatch の行は、明細書の画像の該当箇所を見ます
3. low_confidence の数字を確かめる … 税額と地番に付いていれば、画像の数字と1桁ずつ見比べます
4. 理由が分からない食い違いを営業担当に渡す … 売主か司法書士への確認が要るものです
5. 経理が確定する … 計算表を確定し、決済の案内に載せます

not_in_bill は、多くの場合誤りではありません。 私道や公衆用道路のように非課税の土地や、免税点未満の土地には、明細書に行がありません。共有の土地で、売主が共有の代表者でない場合は、明細書そのものが売主に届いていないこともあります。 この場合は代表者に届いた明細書の写しを、売主を通して取り寄せてもらいます。ただし、売主が明細書の2枚目を渡し忘れている場合も同じ見た目になります。 地目が公衆用道路でない土地が not_in_bill のときは、必ず営業担当に確かめてもらいます。

例外に対処する

1行目が年の初めに集中します。 新しい年度の明細書が届くのは、たとえば神戸市では4月上旬です。それより前の決済は、前の年度の税額で精算するのか、届いてから精算し直すのかを契約で決めているはずなので、その取り決めを契約条件の項目に持たせておきます。

記録を残す

• 元の明細書ファイルと、受け取った日時・契約番号
• OCRが返したJSONの全文と、AIが返した行ごとのJSON
• 照合の結果（行ごとの区分）と、そのとき参照した物件の表示と契約条件
• 計算表の入力（年税額・起算日・引渡し日・日数・端数処理）と出力
• 人が直した値と、直した理由
• 経理が確定した日時と確定した人

3つ目で、参照した契約条件を残すのは、契約は決済の直前まで変わるからです。 引渡し日が1日ずれただけで負担の日数が変わります。どの時点の引渡し日で計算したかが残っていないと、決済の場で数字が合わない理由を説明できません。 引渡し日が変わったときは、契約管理の仕組みの更新をきっかけに計算表を作り直し、前の版は消さずに残します。

5つ目の「直した理由」は、自治体の書式ごとに集計します。 同じ自治体で同じ項目を毎回直しているなら、プロンプトにその書式の注意を1行足すだけで直ることが多く、直した記録がそのまま改善の材料になります。