自治体の補助金の担当課が、事業者から届く申請書と添付書類を交付要綱の要件に照らして一次審査し、不足書類と確認点を照会の文案にする

処理の起点を決める

申請番号のフォルダに書類が置かれたことを起点にします。 電子申請の受付システムから書類を取り出してフォルダに置く作業は、受付の記録とあわせて担当職員が行います。受付台帳への記録を先に済ませることで、受付日が確定してから審査が動きます。 受付日は、証明書の期限や発注の日付を照らす基準になります。

再提出のときも同じフォルダに置きます。 再提出の書類だけを読ませるのではなく、前回の一次審査の表と一緒に、申請の書類一式をもう一度判定させます。 差し替えた書類で別の要件が崩れていないかを、同じ物差しで確かめるためです。

要件の一覧が確定していない補助金の申請は、流しません。 要綱の改正の直後で一覧が見直し中のときは、担当職員に知らせて手で審査します。

入力データを集める

質を決めるのは、要件の一覧です。 「中小企業者であること」とだけ書いても、AIはどの書類のどの欄で確かめるかを決められません。「登記事項証明書の資本金の額と、申請書の従業員数で確かめる。業種ごとの基準は別表のとおり」と、確かめ方まで書きます。

対象経費の区分は、補助額の試算のためです。 見積書の1行ずつを対象・対象外に振り分ける基準がないと、AIは見積書の合計をそのまま対象経費にします。

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

書類は、フォルダへの保存を検知した Power Automate が取り出し、申請番号ごとに1回の呼び出しで Claude API に渡します。書類の枚数が多い申請は、ページ数とリクエストの大きさの上限を確かめ、超えるときは書類の種類ごとに分けて渡します。

金額と日付は、書類に書かれているとおりに書き写させます。 「令和8年9月15日」と「2026/9/15」の変換や、税込と税抜の判定は、Python の側で行います。 AIに変換させると、どこで誤ったかを追えなくなります。

文字の小さいページや複雑な表が多い PDF は、ページ数の上限より先にコンテキストを使い切ることがあるとされています。カタログを何十ページも添付してくる申請は、対象の機器が載っているページだけを残して渡します。

AIへ渡す前に整形する

1. 受付日の確認 … 受付台帳に受付日が記録されていることを確かめます
2. PDF の状態の確認 … パスワード付きや暗号化された PDF は使えないので、申請者に解除して出し直してもらいます
3. 書類の種類の振り分け … ファイル名と1ページ目から、申請書・見積書・証明書などの種類を付けます。分からないものは「種類不明」として残します
4. 大きさの確認 … 上限を超える申請は、書類の種類ごとに分けて渡します
5. カタログの絞り込み … 対象の機器が載っていないページを除きます
6. 個人の情報の扱い … 個人事業主の申請では、判定に要らない情報（個人の生年月日、家族の情報など）が含まれる書類の扱いを決めておきます
7. 要件の一覧の選択 … 補助金の種類と受付日から、適用する一覧の版を選びます

7番目を軽く見ないでください。 要綱を改正した年度は、改正前に受け付けた申請と改正後の申請で、適用する要件が違うことがあります。受付日で版を選ばないと、正しい申請に not_met_possible が並びます。

AIに処理させる

させるのは、要件の一覧の1項目ずつについて、書類の記載から判定し、根拠の書類とページを添えることです。 あわせて、補助額の計算に使う金額と、日付の照合に使う日付を書き写させます。

右端の列の missing_document と not_met_possible と needs_judgment を分けることが、この構成でいちばん大事です。 missing_document は提出を頼めば済み、not_met_possible は要件を満たさない可能性を申請者に確かめる必要があり、needs_judgment は職員が判断します。照会の文案の段が、この区別で決まります。

not_met_possible は「要件を満たさない」とは書きません。 書類の記載から見て満たさない可能性がある、という事実だけです。資本金が基準を超えていても、従業員数の基準で中小企業者に当たる場合があるように、要綱の当てはめは担当職員が行います。

4行目がいちばん起きやすい失敗です。 生成AIは補助金の一般的な審査の観点を知っているので、「事業計画の実現性に懸念がある」のような、一覧に無い観点を書き足します。一次審査は要件の確認であって、事業の評価ではありません。

指示内容を固定する

あなたは市の補助金の担当課で、交付申請の一次審査を手伝う立場です。
渡す申請書類を読み、要件の一覧の1項目ずつについて判定してください。
要件の一覧にない観点で判定しないでください。

【status の選び方】
- met ................ 書類の記載から、条件を満たしていることが確かめられる
- missing_document ... 確かめるための書類が、申請の書類のなかに無い
- not_met_possible ... 書類はあるが、条件に合わない記載がある
- needs_judgment ..... 書類はあるが、記載だけでは条件に合うか決められない
- unreadable ......... 書類はあるが、該当の箇所が読めない
迷ったときに met を選ばないでください。

【厳守事項】
- すべての判定に、根拠にした書類の種類・ページ・該当の記載を書き写してください。
- 書類が無いことと、書類に条件に合わない記載があることを、混ぜないでください。
- not_met_possible でも、「要件を満たさない」「交付できない」と書かないでください。
  書類のどの記載が、一覧のどの条件と合わないかだけを書いてください。
- 金額は、見積書に書かれているとおりに、1行ずつ書き写してください。
  合計・税抜の計算・補助額の計算をしないでください。
- 見積書の各行について、対象経費の区分 {cost_rules} のどれに当たるかを書いてください。
  区分に無いものは needs_judgment としてください。
- 日付は、書類に書かれているとおりに書き写してください。西暦への変換をしないでください。
- 事業計画の良し悪し、実現性、効果について書かないでください。
- 申請者が補助事業者となれるかどうか（暴力団の排除に関する事項）について書かないでください。
- 種類の分からない書類は、document_type を unknown として残してください。

【補助金】{subsidy_name}（要件の一覧 {checklist_version}）
【要件の一覧】{checklist}
【受付日】{received_date}
【申請書類】（PDF）

「書類が無いことと、条件に合わない記載があることを混ぜない」を明記しないと、どちらも「不備」とまとめます。 そうなると、照会の文案の段を分ける材料がなくなります。

「交付できないと書かない」を入れるのは、一次審査の表が決裁の材料として回るからです。 AIの判定の欄に「交付不可」と書かれていると、担当職員が当てはめを確かめる前に、結論が決まったように読めてしまいます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力で JSON スキーマを渡し、この形を守らせます。

{
  "application_id": "",
  "subsidy": "",
  "checklist_version": "",
  "documents": [ { "file": "", "document_type": "application | estimate | certificate | plan | unknown", "pages": 0 } ],
  "checks": [
    { "req_id": "A-03", "requirement": "",
      "status": "met | missing_document | not_met_possible | needs_judgment | unreadable",
      "document": "", "page": 0, "evidence": "", "note": "" }
  ],
  "estimate_lines": [ { "item": "", "amount_text": "", "tax_text": "", "cost_category": "", "page": 0 } ],
  "dates": [ { "kind": "certificate_issued | estimate | contract | order", "date_text": "", "document": "", "page": 0 } ],
  "mismatches": [ { "field": "", "a": "", "a_page": 0, "b": "", "b_page": 0 } ]
}

1つ目の理由は、AIの判定と機械の計算を分けられることです。 estimate_lines と dates はAIが書き写したもの、補助額と日付の照合は Python が計算したものです。補助率や上限額が改正されても、AIの指示を変える必要はありません。

2つ目は、照会の文案を status から機械的に組めることです。 missing_document の行から「提出をお願いする書類」の段を、not_met_possible の行から「確認させていただきたい点」の段を作ります。needs_judgment は照会に入れず、担当職員の判断に回します。

3つ目は、page で書類に戻れることです。 担当職員は、判定の根拠のページだけを開けば確かめられます。第4章の②の18分が短くなるのは、ここです。

構造化出力は、型と必須の項目を守らせる仕組みです。拒否の応答や max_tokens に達した場合はスキーマに合わない出力になりうるとされているので、stop_reason を見てから表に流します。

システムへ連携する

受付台帳と決裁のシステムへは書き込みません。 一次審査の表は担当職員が確かめてから、係長への回付の資料にします。確かめる前の判定が決裁の材料として残ると、誤りが正式な審査の記録になります。

照会もこの構成からは送りません。 文案は担当職員が直し、担当課の名前で送ります。申請者から見れば、照会は市からの正式な連絡です。

人が確認する

人の確認は3か所です。 要件の一覧の確定、一次審査の表の確認、そして needs_judgment の判断です。

1. 要件の一覧を確定する（要綱の改正のとき） … 係長が、要綱の条文と一覧の項目を突き合わせて確定します
2. not_met_possible を先に見る … 根拠のページを開き、要綱の当てはめを確かめます。照会に入れるか、職員の判断で済むかを決めます
3. needs_judgment を判断する … 対象経費の区分に無い経費や、記載だけでは決められない要件を判断し、必要なら係長に相談します
4. 補助額の試算を確かめる … 対象経費に振り分けられた行を見て、試算を確かめます
5. 照会の文案を直して送る … 依頼の段と確認の段が混ざっていないかを見て、送ります
6. 判定を覆したら記録する … どの項目を、なぜ覆したかを残します

2番目と3番目は職員にしかできません。 要綱の当てはめは、条文の解釈と過去の取扱いに基づく判断です。AIの判定は、その判断を始める位置を示すものにとどめます。

目標は、60件をならして1件18分です。 書類がそろった申請は数分、not_met_possible や needs_judgment がある申請は20分を超えます。18分を大きく超える月は、要件の一覧の確かめ方の書き方が足りていないか、申請の手引きが分かりにくくなっています。

例外に対処する

上から2行目までが一番効きます。 受付日と要件の一覧は、判定の基準そのものです。基準が無いまま判定を出すくらいなら、出さないほうが担当職員の手間が少なくて済みます。

記録を残す

• 申請番号、補助金の種類、受付日と、判定に使った要件の一覧の版
• Claude API が返したJSONの全文
• Python で計算した対象経費の合計、補助額の試算、日付の照合の結果
• 担当職員が覆した判定とその理由、needs_judgment の判断の結果
• 送った照会の内容と、再提出された書類との対応
• 補助金ごと・要件ごとの missing_document と not_met_possible の件数

4つ目で判断の結果を残すのは、要件の一覧を育てるためです。 同じ種類の経費が毎回 needs_judgment になり、毎回同じ判断になるなら、その経費を対象経費の区分に書き足せます。 担当者ごとの判断の差も、ここで見えます。

最後の行は、申請の手引きを直す材料になります。