行政書士事務所で作った建設業許可の申請・届出の書類一式を、自治体の手引きの必要書類の一覧に照らして提出前に校正し、補正になりやすい箇所を挙げる

処理の起点を決める

補助者が書類一式を案件のフォルダの「確認待ち」に置いたことを起点にします。 Python の処理を数分おきに動かし、新しく置かれた案件を順に処理します。行政書士がまとめて見る時間の前に一覧が出ているように、置かれた順に流します。

案件の管理表に、申請の区分と顧問先の形が入っていることを動かす条件にします。 区分（新規、業種追加、更新、決算報告、変更届）と、顧問先の形（法人か個人か、株式会社か、資本金の額、従業員数の変更の有無）が無ければ、点検表の行を選べません。空欄の案件は処理せず、補助者に「管理表の入力待ち」と返します。

同じ案件で直した書類が置き直されたときは、案件全体を点検し直します。 直した1枚だけを見ると、その1枚に連動する別の様式の数字の食い違いを見逃します。

入力データを集める

質を決めるのは、点検表です。 手引きの必要書類の一覧を写すだけでなく、事務所で過去に補正を受けた点を、行ごとの注記として足していきます。 「工事経歴書：実績の無い業種は1枚にまとめる」のような手引きの注意も、ここに入れます。

前回の提出書類は、前年からの変化を見るために使います。 前年の決算報告と比べて資本金や役員が変わっていれば、決算報告とは別に変更の届出が要る可能性があります。 それを行政書士に知らせる材料になります。

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

様式のファイルは、Python で決まった欄の値を読み出します。 都の様式は表計算のファイルでも公開されていて、欄の位置が決まっているので、商号、主たる営業所の所在地、代表者、許可の業種、各年度の金額を、様式の番号と欄の名前つきで取り出せます。

確認資料はPDFのままAIに渡し、表計算のファイルは渡しません。 公式の説明では、PDF以外の文書は文字だけを取り出し、表計算のファイルは各シートの先頭1,000行までを読むとされています。欄の位置で意味が決まる様式は、プログラムが欄を指して読むほうが確実です。

スキャンのPDFは、1つの書類が1つのファイルになるように補助者に置いてもらいます。 複数の証明書を1つのPDFにまとめると、どのページがどの書類かをAIに決めさせることになり、読み違えたときに「不足」と「食い違い」の区別がつかなくなります。

AIへ渡す前に整形する

1. 点検表の行の選択 … 申請の区分と顧問先の形から、要る書類の行だけを選びます。条件付きの行は、条件を満たすかを管理表の値で決めます
2. 様式の値の読み出し … 様式の番号ごとに、決まった欄の値を取り出します
3. 表記の正規化 … 商号の「株式会社」の位置、所在地の丁目・番地の書き方、全角と半角をそろえた別の列を作ります。元の値は書き換えません
4. 金額の単位の確認 … 様式によって千円単位と円単位が混ざるので、点検表に書いた単位で読み、比べる前にそろえます
5. PDFの確認 … 1ファイル50MB未満であること、パスワードが掛かっていないことを確かめます
6. ファイル名と点検表の行の対応 … 事務所で決めたファイル名の付け方から、どの行の書類として置かれたかを読みます
7. 前回の値の付与 … 前年の決算報告の商号・資本金・役員を添えます

3番目で元の値を書き換えないのは、食い違いそのものを見つけたいからです。 正規化した値で比べて一致すれば「表記だけの違い」、正規化しても違えば「中身の違い」と分けます。前者は直すかどうかを行政書士が決め、後者は必ず直します。

4番目の単位を軽く見ないでください。 千円単位の様式の数字を円単位の財務諸表と比べると、すべての金額が食い違いとして出て、一覧が使えなくなります。 単位は点検表の側に様式ごとに書いておきます。

AIに処理させる

させるのは、確認資料のPDFを点検表の行に当てはめて、書かれていることを読み出すことです。 判断ではなく、読み出しと当てはめです。

右端の列で、換算をさせていないのが大事です。 手引きのページには、納税証明書は都税事務所と税務署とで年度の表記が異なると注記されています。AIに年度を換算させると、表記の違いを取り違えたまま「対象の年度が違う」と出します。書かれたとおりに読み出させ、比べ方は点検表の規則で決めます。

種類を読み出させるのは、手引きの改訂に追いつくためです。 令和8年度の手引きでは、常勤性を確かめる資料について、健康保険証とマイナ保険証の表面の代わりに、資格確認書の写し、運転免許証の写し（両面）、発行後3か月以内の住民票（個人番号と住民票コードを省略したもの）のいずれかを出すことになりました。資格確認書については「資格情報のお知らせ」とは異なることに注意するよう書かれています。種類が読めれば、去年のままの資料を規則で拾えます。

4行目が、いちばん起きやすい失敗です。 発行日がかすれて読めない証明書を渡すと、前後の書類から日付を推して埋め、その日付で「期限内」と判定されます。 読めないものは読めないと返させ、補助者に資料を取り直してもらいます。

指示内容を固定する

あなたは行政書士事務所で、建設業許可の申請・届出の確認資料を点検する補助をします。
渡されたPDFと点検表の行だけを見て作業してください。推測で埋めないでください。

【やること】
1. このPDFが、点検表のどの行（row_id）の書類に当たるかを答えてください。
   当たる行が無ければ unknown_document としてください。
2. その行の「あるべき記載」の項目ごとに、PDFに書かれているかを答えてください。
   - present ...... 書かれている
   - absent ....... 書かれていない
   - unreadable ... 文字はあるが読めない
3. 書類の種類、発行日、有効期限、対象の年度、商号・氏名・所在地を、
   書かれたとおりに写してください。

【厳守事項】
- 日付と年度は書かれたとおりに写してください。和暦と西暦の換算をしないでください。
- 読めない文字を、前後の書類や一般的な書式から補わないでください。
- 常勤性を確かめる資料は、書類の種類をそのまま答えてください。
  「資格確認書」と「資格情報のお知らせ」は別の書類です。
  見分けられない場合は uncertain としてください。
- 許可の要件を満たすか、補正になるかは書かないでください。
- 個人番号（マイナンバー）や住民票コードが見えている場合は、
  値を写さずに visible_sensitive に true を入れてください。
- それぞれの答えに、根拠にしたページ番号を付けてください。

【点検表の行】{checklist_rows}
【PDF】{file}

「資格確認書と資格情報のお知らせは別の書類」と書いているのは、手引きの改訂が名指しで注意しているからです。 名前が似ていて、どちらも健康保険の資格に関わる書類なので、指示に無ければ同じものとして読みます。 種類を取り違えると、改訂への追随がこの1行から崩れます。

個人番号を写させないのは、見えていること自体を知りたいからです。 住民票は個人番号と住民票コードを省略したものとされているので、見えていれば取り直しが要ります。 値を写す必要はありません。

出力形式を固定する

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

{
  "case_id": "",
  "file_name": "",
  "row_id": "",
  "document_type_as_written": "",
  "required_fields": [
    { "field": "", "status": "present | absent | unreadable", "value": null, "page": 1 }
  ],
  "issue_date": null,
  "expiry_date": null,
  "target_year_as_written": null,
  "names_as_written": [],
  "visible_sensitive": false,
  "uncertain": false
}

公式の説明では、text.format に type: "json_schema" と strict: true を指定すると応答がスキーマに従い、すべての項目を required にし、additionalProperties を false にする必要があります。 値が無いものは null との共用体で表します。

1つ目の理由は、点検表の行の結果に機械的に組み立てられることです。 プログラムは、AIの結果と様式の値の照合と金額の計算を合わせて、点検表の行ごとに次の結果を付けます。

2つ目は、as_written の値で比べ方を後から変えられることです。 年度の表記の扱いや、日付の期限の数え方は点検表の規則に書くので、手引きが変わっても、直すのは規則だけです。 AIの読み出しはやり直しません。

3つ目は、page で確かめが速くなることです。 一覧の各行から、根拠にしたPDFのページを開けます。

システムへ連携する

様式のファイルは書き換えません。 食い違いを見つけても、どちらの値が正しいかは決算書に戻らないと分からず、直すのは補助者の仕事です。 案件の管理表に書くのは、missing・mismatch・outdated・check の件数だけです。

電子申請でも窓口・郵送でも、この構成の位置は同じです。 都のページには電子申請の案内と注意事項が載っていますが、提出の前に書類一式がそろっているかを確かめる工程は、どの出し方でも残ります。

人が確認する

行政書士が見るのは、補正になりやすい箇所の一覧です。 ok の行は件数だけを見て、missing・mismatch・outdated・check の行を開きます。

1. missing を先に見る … 本当に要る書類か、点検表の条件の当てはめが正しいかを確かめます
2. outdated を見る … 手引きの改訂で扱いが変わった書類です。顧問先に取り直してもらう連絡は、ここから出します
3. mismatch を見る … どちらの値が正しいかを決算書や登記で確かめ、補助者に直す側を指示します
4. check を見る … 読めない・見分けられないものを、PDFのページで確かめます
5. 許可の要件にかかわる書類を自分で読む … 常勤役員等の証明書、営業所技術者等の証明書、実務経験証明書は、一覧の結果にかかわらず行政書士が読みます

5番目は、一覧が ok でも省かないでください。 一覧が見ているのは書類がそろっているかと、数字が合っているかです。経験の年数が要件に届いているかは、見ていません。

目標は、1件15分です。 そのうち5番目の要件の確認に半分ほどを使い、残りで一覧の ok 以外の行を見る想定です。

例外に対処する

最後の行が、この構成でいちばん大事な例外です。 点検表が古いまま動くと、一覧は自信を持って去年の基準で ok を出します。 都のページには更新日が出ているので、事務所の担当が毎月それを見て、変わっていれば点検表を直します。

記録を残す

• 案件ごとの点検の日時、使った点検表の版、選ばれた行
• 様式から読み出した値と、正規化した値
• AIに渡したPDFのファイル名と、返ってきたJSONの全文
• 照合と計算の結果、行ごとの判定
• 行政書士が判定を覆した記録（どの行を、何に変えたか）
• 提出の日と、補正を受けた場合はその内容

最後の行を残すのは、点検表を育てるためです。 補正を受けた内容が一覧で ok になっていた行は、点検表の注記か規則が足りていません。 毎月、補正の記録を点検表の注記に足していきます。

使った点検表の版を案件ごとに残すのは、後から問い合わせを受けたときのためです。 提出した時点の手引きの扱いで確かめたことを示せます。