マンション管理会社が管理員の手書きの修繕依頼票を Google Document AI で読み取り、物件・場所・内容・緊急度を修繕の台帳に登録して、同じ場所の未完了の依頼と書き漏れを拾う

処理の起点を決める

管理事務室の複合機から送られた PDF が、Cloud Storage のバケットに保存されたことを起点にします。 複合機の送信先を本社の受信の仕組みにし、そこからバケットに置きます。保存されると Cloud Run functions の処理が動き、1枚ずつ読み取りに回します。

夜にまとめず、届くたびに動かします。 「至急」「今週中」の依頼をフロントに知らせる通知は、届いてから数分のうちに出すことに意味があります。 まとめて動かすと、第3章の（b）の遅れが残ります。

処理が終わった PDF は処理済みのバケットへ移します。移すのは、読み取りと照合と下書きの作成が終わったときだけにします。 受信のバケットに残っている数が、未処理の数になります。

送り忘れも拾います。 物件ごとの月の依頼票の数を前の月と比べ、急に0枚になった物件を月の半ばに一覧にします。管理員の交代や複合機の故障で、送れていないことがあります。

入力データを集める

質を決めるのは、項目名の辞書と様式の項目の一覧です。 Form Parser が返す項目名は、依頼票に印刷された文字そのものです。公式の説明では、キーと値のペアのキーは文書に書かれたキーの文字そのものとされています。読み取りの具合で「発見日」が「発見 日」になれば、辞書で引けません。 表記ゆれを辞書に足していきます。

管理物件の一覧には、物件の別名を持たせます。 管理員は「〇〇マンション」を「〇〇M」や号棟だけで書くことがあります。正式名だけで照らすと、物件が特定できない依頼が増えます。

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

読み取りは、Cloud Run functions から Document AI の API で Form Parser のプロセッサを呼びます。1枚ずつのオンラインの処理で足ります。 公式の一覧では、Form Parser のオンラインの処理は1回15ページまで、バッチの処理は100ページまでとされています。

チェック欄は valueType で見ます。 公式の説明では、チェックの入った欄は filled_checkbox、入っていない欄は unfilled_checkbox として、pages > formFields > fieldValue > valueType に入るとされています。緊急度の3つの欄のうち、filled_checkbox がどれかを数えます。

自由欄は、キーと値のペアに頼りません。 不具合の内容は何行にもわたって書かれ、キーと値の組として取れるとは限りません。「内容」の項目名の位置から下、「緊急度」の項目名の位置より上にある文字を、全文から位置で切り出します。

管理物件の一覧と修繕の台帳は、管理業務のシステムの毎晩の書き出しを Python で読みます。照合の順は、物件が先、部位が後です。

AIへ渡す前に整形する

1. 画像の品質の確認 … 公式の説明では、画像の品質の点数を返すよう有効にでき、0から1の値で1が最良とされています。点数が低い依頼票は、読み取りの結果を使わずに管理員に送り直しを頼みます
2. ページの数の確認 … 依頼票は1枚1ページです。2ページ以上なら、裏面のメモか別の書類が混ざっています
3. 送信元の確認 … 複合機の送信元から物件を引き、依頼票の物件名と合うかを後で照らすために持っておきます
4. 重複の確認 … 同じ送信元から同じ内容の PDF が短い間に2回届いたら、送り直しとみなし、二重に読み取りません

1番目は、管理事務室の複合機の事情から来ています。 送信の画質が低い設定のまま使われていることがあり、細い字の管理員の依頼票は、品質の点数がまとまって下がります。 点数で分けておけば、読み違いを台帳に入れる前に止められます。

3番目の送信元は、物件の特定の物差しになります。 依頼票の物件名が読めなくても、どの管理事務室から送られたかで物件の候補が絞れます。 ただし、管理員が近くの別の物件を兼ねている場合があるので、送信元だけで決めません。

AIに処理させる

させるのは、依頼票の記入欄・チェック欄・自由欄を読み取り、信頼度を返すことだけです。 項目のそろえ方と照合は、Python が辞書と規則で行います。

欠けた項目の扱いが、この構成でいちばん大事な決めごとです。 公式の説明では、Form Parser は値の書かれていないキーと値のペアを確実には取り出せないとされています。部屋番号の欄が空のとき、結果に「部屋番号」の項目そのものが出てこないことがあります。 そこで、様式の項目の一覧と照らし、返ってこなかった項目は「空欄だった」と決めつけず、not_returned として画像で確かめる対象にします。

Python が行う照合は、次の3つです。

linked は「同じ不具合」の判定ではなく「同じかもしれない」の候補です。 同じ廊下でも、照明と手すりは別の依頼です。部位が同じで内容の言葉も近いものを上に並べますが、結び付けるかは担当が内容を読んで決めます。

指示内容を固定する

この構成では生成AIを使わず、Form Parser は追加の学習ができないため、プロンプトの代わりに項目名の辞書と、様式の項目の一覧の作り方を示します。

【項目名の辞書（例）】
台帳の項目        依頼票の項目名（表記ゆれを含む）
property_name    物件名 ／ 物件名称 ／ マンション名
building_no      号棟 ／ 棟
found_date       発見日 ／ 発見 日 ／ 発見年月日
reporter_type    申出者 ／ 申し出
room_no          部屋番号 ／ 号室 ／ 居室番号
photo            写真 ／ 写真の有無

【様式の項目の一覧】
項目            値が要るか   空欄のときの扱い
property_name   必須        needs_review
found_date      必須        needs_review
parts（8欄）     1つ必須     needs_review
urgency（3欄）   1つ必須     missing
room_no         申出者が居住者のときだけ必須   missing
photo           任意        そのまま

【返ってこなかった項目の扱い】
- 様式の項目の一覧にあるのに formFields に無い項目は not_returned とする
- not_returned は空欄とみなさず、画像の該当の位置を担当が見る
- 同じ項目の not_returned が続くなら、辞書の表記ゆれを疑う

辞書は、最初の1か月で育てます。 最初は様式の項目名だけを入れ、辞書で引けなかった項目名を毎日書き出して、表記ゆれを足していきます。 公式の説明では、キーと値のペアのキーは文書に書かれた文字そのものなので、読み取りの揺れがそのまま項目名の揺れになります。

not_returned を空欄と分けるのは、公式の制限への対処です。 Form Parser の公式ページでは、空のフォームのような値の無いキーと値のペアは、確実には取り出されないとされています。項目名が見つからないという結果は、「書かれていない」の証拠になりません。

判定の基準値は、処理の側の設定として持ちます。 初期値は、画像の品質の点数の下限0.5、記入欄の信頼度の下限0.80とし、最初の1か月で、担当が直した欄の分布を見て見直します。

出力形式を固定する

依頼票1枚ごとに、次の形のJSONを作ります。

{
  "request_id": "R-20261015-0412",
  "source_property": "P0371",
  "quality_score": 0.82,
  "property": { "read": "", "code": "P0371", "check": "ok | needs_review" },
  "found_date": { "value": "", "conf": 0, "check": "ok | needs_review" },
  "parts": ["電気・照明"],
  "description": "",
  "urgency": { "value": "今週中", "check": "ok | missing | needs_review" },
  "reporter": { "type": "居住者", "room_no": "", "check": "ok | missing | not_returned" },
  "photo": true,
  "not_returned": ["room_no"],
  "linked_candidates": [
    { "ticket": "T-2026-08812", "parts": "電気・照明", "registered": "2026-10-02",
      "status": "手配済み", "description": "" }
  ],
  "verdict": "new | linked | needs_review"
}

1つ目の理由は、not_returned を独立した項目にすることです。 返ってこなかった項目の一覧を、missing と混ぜずに持ちます。担当は、not_returned の項目だけを画像の位置で見れば済みます。

2つ目は、linked_candidates に台帳の側の内容を並べることです。 候補の依頼の内容と状態が並んでいれば、担当は台帳を開かずに、同じ不具合かを判断できます。

3つ目は、verdict を規則で決めることです。 needs_review の欄が1つでもあれば needs_review、候補があれば linked、どちらも無ければ new。判定の規則を変えても、読み取りの結果はそのまま使えます。

台帳の登録の下書きには、物件のコード、部位、発見日、内容（原文）、緊急度、申出者と部屋番号、写真の有無、結び付けた依頼の番号を並べます。

システムへ連携する

台帳への登録は、担当が確かめてから行います。 未完了の依頼への結び付けを機械が決めると、別の不具合が1つの依頼にまとめられ、片方の手配が漏れます。

通知は、読み取った緊急度と依頼票の画像へのリンクだけを送ります。 内容の文や居住者の部屋番号は送らず、フロントが画像を開いて確かめます。

人が確認する

本社の担当が見るのは、linked と needs_review の依頼だけです。 new の依頼は、物件と部位と緊急度を一覧で流し見て登録します。

1. needs_review のうち、物件が決まらないものを先に見る … 送信元と画像を見て物件を決めます。決まらなければ管理員に電話します
2. not_returned と missing の項目を、画像の位置で見る … 書かれていれば補い、本当に空欄なら管理員に確かめます
3. linked の候補を読む … 候補の依頼の内容と状態を見て、同じ不具合なら結び付け、別なら新しい依頼にします
4. 緊急度が付いていない依頼を確かめる … 内容から推し量らず、管理員に聞きます
5. 直した内容を記録する … どの欄を、何から何に直したか、結び付けたかを残します

3番目で、手配済みのまま日が経っている候補が出たら、フロントに知らせます。 管理員が同じ不具合を再び書いてきたということは、業者の対応が止まっている可能性があります。 第3章の（d）は、ここで拾えます。

目標は、900枚をならして1枚1.2分です。 linked と needs_review が3割前後という想定で、それより多い日は、辞書の表記ゆれか、複合機の送信の画質を疑います。

例外に対処する

上から2行が大半を占めます。 どちらも AI の精度の問題ではなく、送信の設定と辞書の整備の問題です。 直すほうが早く効きます。

記録を残す

• 元の依頼票の PDF と、受信した日時・送信元の物件
• Document AI が返した JSON の全文と、プロセッサのバージョン
• 項目のそろえ方の結果（辞書で引けた項目、not_returned）と、そのとき使った辞書の版
• 照合の結果（物件のコード、linked_candidates）と、担当が結び付けたか、新しい依頼にしたか
• 通知を出した日時と、通知した相手
• 担当が直した記録 … どの欄を、何から何に直したか

3つ目で辞書の版を残すのは、辞書が毎週のように育つためです。 ある日の not_returned が辞書の不足だったのか、読み取りの問題だったのかを、後から分けられるようにします。