自治体の道路管理の担当に届く道路占用・道路使用の許可申請書を読み取り、場所・期間・占用物件・面積を受付台帳にそろえて、記入漏れと添付図面の不足を拾う

処理の起点を決める

受付フォルダに申請が保存されたことを起点にします。 Python のプログラムを数分おきに動かし、新しいフォルダを探します。申請1件を1つのフォルダにまとめる決まりにし、申請書と添付図面を同じフォルダに入れます。電子申請のPDFは、受付番号の付いたフォルダごと保存します。

紙の申請は、受付の担当が申請書と図面を一度にスキャンします。 図面を別にスキャンすると、どの申請の図面かが分からなくなります。フォルダの名前に受付日と受付番号を入れます。

処理が終わったフォルダは処理済みに移します。移すのは、受付台帳への書き込みまで終わったときだけにします。受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、添付図面の一覧です。 これが無いと、図面の不足は「何も添付が無い」ときしか拾えません。物件の種類と図面の対応が表になっていれば、足りない図面の名前まで申請者に伝えられます。

受付台帳の過去の占用は、更新の申請を見るために使います。 前回と場所や面積が変わっていれば、更新ではなく変更の手続きが要るのではないかを担当が確かめる材料になります。

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

読み取りは、Python から Form Parser のプロセッサを呼ぶだけです。オンラインの処理は1回の要求で最大15ページなので、申請書と図面を合わせて15ページを超える申請は、公式の上限が100ページのバッチ処理に回します。

空欄の見分けは、キーと値のペアだけに頼りません。 「道路の復旧方法」という項目名があって値が取れないとき、全文の中で項目名の近くに文字が検出されているかを見ます。何も検出されていなければ空欄、検出されていて信頼度が低ければ読めない欄です。

図面のページは、欄ではなく全文を使います。 図面には「位置図」「平面図」といった表題と、求積の数字が書かれています。表題と数字の位置から、ページの種類と面積を取り出すのが Gemini API の仕事です。

AIへ渡す前に整形する

1. 形式の確認 … 申請書と図面がPDFか画像であることを確かめます。複合機の保存はPDFにします
2. 解像度の確認 … 図面の細かい数字を読むため、スキャンは300dpiで保存します
3. ページの向きの確認 … 横長の図面は向きを直してから送ります
4. 大きな図面の確認 … A3を超える図面を縮小してスキャンすると、数字がつぶれます。縮小した図面は読めない欄として扱う前提にします
5. 申請書のページの特定 … 1ページ目が申請書でない申請（送り状や委任状が先頭）を見つけます
6. 道路使用の申請書の分離 … 道路使用の許可申請書が同じフォルダに入っていれば、別の書類として印を付けます

4番目は、図面の数字を読むときにいちばん効きます。 求積図の数字が読めないと、面積の食い違いを見ることができません。読めないものを無理に読ませず、担当が原本で見る側に回します。

6番目を前処理に入れるのは、警察署へ送る書類を占用の書類と混ぜないためです。 道路法第32条第4項と道路交通法第78条第2項は、それぞれ反対向きの経由の手続きを定めています。どちらの書類がどちらへ行くかを、受付の時点で分けておきます。

AIに処理させる

させるのは、申請書の欄を受付台帳の項目に書かれたとおりに写すことと、添付のページを図面の種類に分けることです。 記載事項の有無、図面の不足、面積の食い違いは、Python の規則で見ます。

4行目が、AIを使う理由です。 図面の表題は「位置図」とは限らず、「案内図」「付近見取図」と書かれていることもあります。呼び方の揺れを図面の種類にそろえるのは、決まった規則では書きにくい作業です。

1行目がいちばん大事です。 物件の構造の欄に寸法だけが書かれ、面積が書かれていない申請で、AIが寸法から面積を計算して埋めると、「面積が書かれていない」という不備が消えます。 面積は、書かれたとおりに写させます。

指示内容を固定する

あなたは市の道路管理課で、道路占用の許可申請書の読み取り結果を、
受付台帳の項目に写す立場です。OCRが返した結果だけを見て、
書かれていることを写してください。推測で埋めないでください。

【写す項目】
purpose（占用の目的）、period_from／period_to（占用の期間）、
location（占用の場所。路線名・地番を書かれたとおり）、
structure（物件の構造）、work_method（工事実施の方法）、
work_period（工事の時期）、restoration（道路の復旧方法）、
applicant（申請者の名称・住所・連絡先）、application_type（新規・更新・変更）
物件ごと：object_text（物件。書かれたとおり）、quantity、size、area、unit

【添付ページの分類】
各ページを site_map（位置図・案内図・付近見取図）、plan（平面図）、
section（断面図）、area_calc（求積図）、photo（写真）、
road_use_application（道路使用の許可申請書）、other のいずれかにしてください。

【厳守事項】
- 欄が空欄なら status を blank、文字はあるが読めなければ unreadable に
  してください。空欄と読めない欄を混ぜないでください。
- 面積を寸法から計算しないでください。面積が書かれていなければ blank です。
- 数字と単位は書かれたとおりに写してください。単位が無ければ no_unit です。
- 物件の名前を言い換えたり、まとめたりしないでください。
- 求積図の合計の面積は、図に書かれた数字をそのまま写してください。
- 許可できるか、基準に合うか、道路使用の許可が要るかは書かないでください。
- 道路占用の許可申請書でない書類が先頭にある場合は、
  document_type に種類を書いてください。

【読み取り結果】{ocr_result}

「面積を計算しない」を独立した1行にしているのは、AIがいちばん自然に埋めてしまう値だからです。 寸法が「幅1.5m 長さ20m」と書かれていれば、30㎡と書きたくなります。計算してよいのは、申請者に確かめた担当だけです。

分類の指示に、呼び方の揺れを括弧で並べています。 「案内図」を位置図に入れることを書いておかないと、other に落ちて「位置図が無い」という誤った印が付きます。

出力形式を固定する

次の形のJSONで受け取ります。 Gemini API の Interactions の要求で、response_format に JSON スキーマを渡して形を固定します。

{
  "document_type": "road_occupancy_application",
  "application_type": "new | renewal | change | multiple",
  "fields": [
    { "item": "purpose | period_from | period_to | location | structure | work_method | work_period | restoration | applicant",
      "value": "", "status": "read | blank | unreadable" }
  ],
  "objects": [
    { "object_text": "", "quantity": "", "size": "", "area": "", "unit": "",
      "status": "read | blank | unreadable | no_unit" }
  ],
  "attachments": [
    { "page": 0, "kind": "site_map | plan | section | area_calc | photo | road_use_application | other | unknown",
      "area_total": "" }
  ]
}

1つ目の理由は、7つの記載事項を同じ形で並べられることです。 道路法第32条第2項の7つを fields の item にそのまま当て、blank と unreadable の数を申請ごとに数えられます。

2つ目は、図面と記載の照合を Python の規則で持てることです。

road_use_attached は、不備の印ではありません。 警察署へ送る書類があることを受付の担当に知らせる印で、送る段取りを忘れないためのものです。 道路使用の申請書が無いのに工事の足場の申請がある、といった組み合わせは、要否の判断に関わるので印を付けず、担当の確かめに任せます。

3つ目は、area_total で図面の数字を記載と並べられることです。 求積図の数字と申請書の数字を同じ行に並べるので、担当は図面を開く前に食い違いの大きさが分かります。

公式のページでは、構造化出力は JSON スキーマの一部に対応し、出力が構文として正しい JSON でも値はアプリケーションの側で確かめるよう書かれています。Python で item と kind が決めた値のどれかであることを確かめ、外れたものは台帳に書かずに呼び直します。

システムへ連携する

受付台帳の「審査中」以降のシートと、許可書の作成には書き込みません。 受付待ちから審査へ回すのは、受付の担当の操作だけです。読み取りの誤りが、そのまま許可の手続きに流れることはありません。

申請者への補正の連絡も、この構成からは送りません。 足りない図面や記載事項の一覧は受付待ちのシートに出るので、担当はそれを見ながら電話で伝えます。

人が確認する

受付の担当が開くのは、印の付いた申請だけです。 印の無い申請は、台帳の行を流し見て審査に回します。

1. road_use_attached を先に見る … 道路使用の申請書を占用の書類から分け、警察署へ送る段取りをとります
2. missing_item と missing_drawing を見る … 申請書の写しで本当に書かれていないかを確かめ、申請者に補正を頼みます
3. area_mismatch を見る … 申請書と求積図のどちらが正しいかを申請者に確かめます。どちらかに合わせて台帳を直すのは、確かめた後です
4. changed_on_renewal を見る … 更新ではなく変更の手続きが要るかを確かめます
5. route_unknown・period_error・check_original を見る … 原本で確かめます

1番目を先にするのは、申請者の工事の日程に直結するためです。 道路使用の許可は警察署が出すので、送るのが1日遅れると、申請者の工事の開始が1日遅れることがあります。

目標は、200件をならして1件4.5分です。 印の無い申請は流し見で1分ほど、印の付いた申請は原本と図面を見て申請者に電話するので、十数分かかります。

例外に対処する

5行目で市の様式でない申請書も受け付けるのは、道路法が求めているのが記載事項だからです。 項目名が違っても、7つが書かれていれば審査はできます。様式の違いで差し戻さないよう、規則は記載事項の有無で組みます。

記録を残す

• 元の申請書と図面、受付日と経路（窓口・郵送・電子申請）
• OCRが返したJSONの全文と、Gemini API の応答の全文
• 照合に使った添付図面の一覧と路線の一覧の版
• 付いた印と、担当が確かめた結果・申請者とのやり取り・審査へ回した日時
• 道路使用の申請書を警察署へ送った日
• 印の種類ごとの件数と、申請者ごとの補正の回数

3つ目で一覧の版を残すのは、手引きが改められるためです。 添付図面の一覧を変えると、過去の申請の「図面の不足」の意味が変わります。

最後の行は、手引きを見直す材料になります。 同じ図面の不足が多くの申請者で続くなら、手引きの書き方が分かりにくいのかもしれません。