海外の賃貸物件の管理会社から毎月届く英文のレントロールを読み取り、区画ごとの賃料・滞納・空室を物件台帳と照らして、送金額との差を拾う

処理の起点を決める

物件ごとの保存場所にPDFが置かれたことを起点にします。 保存場所は s3://overseas-pm-reports/<管理会社コード>/<物件コード>/<年月>/ のように分け、場所から管理会社と物件を決めます。 ファイル名の付け方は管理会社ごとに違うためです。

レントロールと収支報告は、同じ物件・同じ月の場所に置かれた2つのファイルを1組として扱います。片方だけが届いた段階では読み取りまで進め、照合は2つがそろってから行います。 月の15日を過ぎてもそろわない物件は、未着の一覧に出します。

非同期の処理を始めるときは、物件コードと年月から作った値を ClientRequestToken に入れます。 同じ値で始めると同じジョブの識別子が返るので、保存の通知が二重に届いても、同じ報告を2回読み取ることがありません。JobTag には管理会社コードを入れ、完了の通知から書式を引けるようにします。

入力データを集める

質を決めるのは、下の3つです。 台帳に改定の予定が無ければ、改定後の賃料が「食い違い」になります。列の対応表は管理会社ごとに1枚で、書式が変わったときにその1枚を直します。

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

表の値は、セルの Confidence と一緒に取り出し、信頼度の低いセルには照合の前に unreadable の印を付けます。

収支報告の送金額のような単独の値は、問い（クエリ）で取ります。 次のように、問いの文と別名を渡します。

{
  "DocumentLocation": { "S3Object": { "Bucket": "overseas-pm-reports",
                                      "Name": "PM03/US-AUS-012/2026-09/owner_statement.pdf" } },
  "FeatureTypes": ["TABLES", "QUERIES"],
  "ClientRequestToken": "US-AUS-012-2026-09-os",
  "JobTag": "PM03",
  "NotificationChannel": { "SNSTopicArn": "arn:aws:sns:...:textract-done",
                           "RoleArn": "arn:aws:iam::...:role/textract-sns" },
  "QueriesConfig": { "Queries": [
    { "Text": "What is the statement period?", "Alias": "PERIOD" },
    { "Text": "What is the total cash received?", "Alias": "CASH_RECEIVED" },
    { "Text": "What is the management fee?", "Alias": "MGMT_FEE" },
    { "Text": "What is the owner distribution amount?", "Alias": "DISTRIBUTION" }
  ] }
}

問いの答えが見つからないときは、答えの欄が空で返ります。 表の合計の行から同じ値を探し、無ければ人に回します。問いは英語の文書でだけ使えます。

結果は GetDocumentAnalysis で取り、1回に返るブロックは最大1,000件です。NextToken が返る間は呼び続け、全ページの結果がそろってから表を組み立てます。 JobStatus が PARTIAL_SUCCESS のときは、Warnings に出たページを人に回します。

AIへ渡す前に整形する

1. 形式の確認 … PDF・JPEG・PNG・TIFF であることを確かめます。パスワードで保護されたPDFは扱えないので、管理会社に保護なしで送ってもらいます
2. ページの向きと文字の大きさ … 文字の高さの下限は15ピクセル（150DPIで約8ポイント）です。スキャンの粗い報告は、管理会社に元のPDFを頼みます
3. 表の組み立て … CELL を RowIndex・ColumnIndex で並べ、COLUMN_HEADER の行を見出しにします
4. ページをまたぐ表のつなぎ … 表はページごとに返るので、同じ見出しの並びを持つ表を、ページの順につなぐ処理を自分で書きます。 2ページ目以降に見出しが無い書式は、前のページの見出しを引き継ぎます
5. 列の対応づけ … 管理会社の対応表で、見出しを unit_id、tenant、lease_rent、charges、balance_due、status などの自社の項目に当てます
6. 数の読み替え … (1,250.00) のような括弧の負の数、通貨の記号、- だけのセルを数に直します。読み替えた元の文字列は残します
7. 合計の確かめ … 区画の行を足した額と、TABLE_SUMMARY の行の額が合うかを確かめます。合わないときは、行の読み落としを疑い、その物件は照合に進めず人に回します
8. 区画番号のそろえ … Unit 101、#101、101 を同じ区画として扱う規則を、物件ごとに決めます

7番目が、読み取りの誤りを見つけるいちばん確かな方法です。 合わないまま照合に進むと、読み落とした区画が「台帳に有るのに報告に無い」と出て、管理会社へ見当違いの照会をすることになります。

AIに処理させる

させるのは3つです。対応表に無い見出しの対応づけの案、食い違いの理由の候補の言葉づけ、照会の英文の下書きです。

3行目がいちばん起きやすい失敗です。 読めない賃料を台帳の額で埋めて「一致」とすると、本当に賃料が変わっていた区画を見落とします。

プログラムが出す食い違いの種類は、次のとおりです。

指示内容を固定する

食い違いの理由の候補と照会の下書きを作るときの指示です。

あなたは不動産会社の財務部で、海外の物件の管理会社から届いた
月次の報告と、自社の台帳の食い違いを整理する立場です。
食い違いの一覧はプログラムが計算したものです。数字はそのまま使ってください。

【やること】
1. 食い違いの一覧を1件ずつ読み、考えられる理由の候補を挙げてください。
   候補は「台帳の更新漏れ」「報告の反映の遅れ」「計上の時期のずれ」
   「為替・送金の手数料」「報告の誤り」「読み取りの誤り」から選び、
   当てはまる根拠を一覧の項目から書いてください。
2. 管理会社に確かめるべき食い違いだけを選び、英文の照会のメールを書いてください。
   区画番号、報告の額、自社の台帳の額、確かめたい点を並べてください。

【厳守事項】
- 金額を自分で計算しないでください。一覧に書かれた差の額だけを使ってください。
- 一覧に無い区画や額を書かないでください。
- status が unreadable の値は「読み取れなかった」と書き、推測で埋めないでください。
  読み取りの誤りが疑われる食い違いは、照会に入れず担当者の確認に回してください。
- 管理会社の誤りと断定しないでください。照会は確認を依頼する書き方にしてください。
- 賃借人の個人名を照会の本文に書かないでください。区画番号で示してください。
- 賃借人への対応（督促・退去の手続き）について提案しないでください。

【物件と期間】{property} {period}
【食い違いの一覧】{discrepancies}
【前月の状態】{prior_month}
【管理委託の条件】{agreement_terms}

「金額を自分で計算しない」を明記しないと、差の額を足し合わせて「合計でいくらの不足」と書きます。 その合計が一覧の値と合っているとは限りません。数字はプログラムの出したものだけを、そのまま写させます。

「読み取りの誤りが疑われるものは照会に入れない」も同じくらい大事です。 入れると、自社の読み取りの誤りを管理会社に確かめさせることになります。

対応表に無い見出しが出たときの指示は別に持ち、「Market Rent と Lease Rent が分かれていれば契約の額を lease_rent に。当たるものが無ければ unmapped」のように、取り違えやすい組を書いておきます。

出力形式を固定する

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

{
  "property_code": "US-AUS-012",
  "period": "2026-09",
  "discrepancies": [
    {
      "id": "D-001",
      "type": "rent_mismatch | status_change | arrears_increase | unit_missing | fee_mismatch | distribution_gap",
      "unit_id": "204",
      "reported": "1850.00",
      "ledger": "1795.00",
      "difference": "55.00",
      "reason_candidates": [
        { "reason": "ledger_not_updated | report_lag | timing | fx_or_bank_fee | report_error | ocr_error",
          "basis": "" }
      ],
      "include_in_inquiry": true
    }
  ],
  "inquiry_draft": { "subject": "", "body": "" },
  "for_internal_review": []
}

1つ目の理由は、reported・ledger・difference をプログラムの値と照らせることです。 1文字でも違えば、その食い違いは表示しません。

2つ目は、include_in_inquiry と for_internal_review で行き先を分けられることです。 管理会社に聞くものと、社内で確かめるもの（読み取りの誤りが疑われるもの、台帳の更新漏れが疑われるもの）が混ざらずに出ます。

構造化出力は、output_config.format に JSON スキーマを渡して使います。Amazon Bedrock 経由の Claude では使える範囲が限られるため、この構成では Claude API を直接呼びます。応答が refusal や max_tokens で終わったときはスキーマに合わないことがあるので、受け付けずにやり直します。

システムへ連携する

物件台帳は読み取りだけです。 担当者が確かめて「台帳の更新漏れ」と決めたものだけ、担当者が台帳を直します。この構成が台帳を書き換えると、管理会社の報告の誤りが台帳に入ってしまいます。 確認の画面では、Textract が返したセルの位置（Geometry）をもとに、PDFの該当箇所を枠で示します。

人が確認する

1. 合計が合わなかった物件を先に見る … 区画の合計と報告の合計が合わない物件は、照合に進んでいません。読み落としの行をPDFで探します
2. unreadable の値を確かめる … 信頼度の低いセルを、PDFで目で読みます
3. 食い違いをPDFと見比べる … 枠で示された箇所を見て、報告の値と台帳の値を確かめます
4. 行き先を決める … 管理会社への照会、台帳の更新、経理への連絡のどれにするかを決めます
5. 照会の下書きを直して送る … 送るのは担当者です
6. 見出しの対応づけの案を承認する … 書式が変わった月だけ、案を確かめて対応表に入れます

1番目を省かないでください。 合計が合わない物件の照合結果は、食い違いの多くが読み取りの問題です。

目標は、40件をならして1件30分です。 食い違いの無い物件は一覧を流し見て数分、区画の多い物件や書式が変わった物件は1時間近くかかる見込みです。

例外に対処する

上から3行目が、運用でいちばん多く起きます。 直すのはAIではなく前処理の規則です。

記録を残す

• 報告の原本（PDF）と、受け取った日時
• Textract のジョブの識別子と、GetDocumentAnalysis の結果の全文（ジョブの識別子は7日間しか有効でないので、結果はその場で S3 に残す）
• 組み立てた区画ごとの表と、そのとき使った列の対応表の版
• 照合の結果（食い違いの一覧）と、そのとき参照した台帳の内容
• Claude API の出力と、指示の版
• 担当者が決めた行き先（照会・台帳の更新・経理）と、管理会社からの回答
• 見出しの対応づけを承認した記録

台帳の内容を照合のときの状態で残すのは、台帳が後から直されるためです。 「9月の時点では台帳が古かった」ことが分からないと、その月の食い違いが誰の側の問題だったかを説明できません。