授業料減免・奨学金の申請書類を読み取り、申請の種類ごとの提出要件に照らして書類の不足と不備を点検する

処理の起点を決める

1時間おきに動く定時の処理を起点にします。 学内のオンライン窓口に届いた申請のうち、まだ点検していないものを Python のスクリプトが探します。申請の番号を管理表に持ち、点検済みなら飛ばします。

1日1回にしないのは、期限のためです。 期限の近い申請は、不備を1日でも早く学生に伝える必要があります。朝に届いた申請の不備を、その日のうちに係員が確かめて連絡できる間隔にします。

点検は、学生が「提出を完了する」操作をしてから行います。 アップロードの途中で点検すると、まだ上げていない書類がすべて missing になり、学生がまだ作業中の申請に不足の連絡が届きます。 オンライン窓口の「提出完了」の状態を見て、完了したものだけを拾います。

再提出の書類が届いたときは、その申請の点検をやり直します。 追加された書類だけでなく、申請全体を点検し直し、前回の点検結果と比べて何が解消したかを係員に示します。

入力データを集める

質を決めるのは、必要書類の一覧です。 「収入証明書類」とだけ書かれた一覧では、何か月分が必要か、どの書類なら代わりになるかを突き合わせられません。一覧は、書類ごとに「確かめる項目」「必要な期間」「代わりになる書類」まで書いた形にします。

アップロードした欄の名前も入力に入れます。 学生が「離職票」の欄に給与の明細を上げていれば、それは書類の不足ではなく、上げる欄の間違いです。欄の名前と書類の中身が合っているかを確かめることで、学生に頼むことが変わります。

学業成績は、この構成の入力に入れません。 成績が基準を満たすかは、書類がそろった後に係員が基幹システムで確かめます。書類の点検と要件の判断を、入力の段階から分けておきます。

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

申請の種類と事由は、申請書のチェックボックスから取ります。 選択欄を読み取った結果が「記入済み」のものを採ります。2つ以上に印がある、どれにも印が無いときは、点検を進めずに係員へ回します。事由が決まらなければ、必要書類の一覧を引けないからです。

証明書類は全文を取り、位置も残します。 取り出した値がどの行にあったかを係員の画面で示すためです。Document AI の応答では、全文が文書の文字の「正本」とされ、ページの中の段落や行はその全文の位置を指す形で返ります。

AIへ渡す前に整形する

1. ファイルの形式の確認 … PDF、TIFF、GIF、JPEG、PNG、BMP、WebP のいずれかであることを確かめます。それ以外は学生に形式を変えて上げ直すよう連絡します
2. 解像度の確認 … 公式の案内では、スキャンは少なくとも200dpi、300dpi以上がよいとされています。下回るものは読み取りの前に unreadable の候補として印を付けます
3. ページ数の確認 … 1回の読み取りで扱えるページ数には上限があります（Form Parser と Enterprise Document OCR はオンラインの処理で15ページ）。超えるものは分けます
4. 向きの確認 … 横向きや逆さまの写真を回転します
5. 重複の確認 … 同じファイルが2つの欄に上がっていないかを確かめます
6. 氏名の表記の準備 … 基幹システムから、学生の氏名、旧姓、家計を支える人の氏名（申請書から）を取り、表記ゆれ（全角と半角、旧字体）の候補を作ります

2番目は、学生のスマートフォンの写真で最も起きます。 暗い部屋で撮った写真、影の入った写真、画面のスクリーンショットをさらに撮った写真です。解像度が足りないだけのものを「不備」として連絡すると、学生は書類を取り直しに行きます。 撮り直しで済むことを先に伝えます。

JPEGを圧縮し直さないでください。 公式の案内でも、非可逆の形式でファイルを小さくすると画質が落ちることがあるとされています。オンライン窓口の側で自動の縮小がかかっていないかを、最初に確かめます。

AIに処理させる

Gemini にさせるのは、書類の種類の確認と、記載事項の取り出しだけです。 不足と不備の判定は、必要書類の一覧との突き合わせで Python が行います。

取り出した値には、必ずその値があった行の文字列を添えさせます。 Python がその文字列を読み取り結果の全文と照らし、全文に無い文字列を根拠にした値は捨てます。 係員の画面では、その行を書類の画像の上で示します。

Python の規則で決める判定は、次のとおりです。

3行目が、最も起きやすい失敗です。 給与の明細が3か月分のうち2か月分しか無いとき、AIに金額をまとめさせると、2か月分から3か月分を見積もって埋めます。 埋まった瞬間、足りない1か月分の書類が消えます。取り出すのは書かれている月だけで、足りないかどうかは一覧と照らして Python が決めます。

指示内容を固定する

あなたは大学の奨学金係で、学生が提出した証明書類を確認する担当です。
渡した読み取り結果だけを根拠にしてください。推測で埋めないでください。

【渡すもの】
アップロードされた欄の名前：{slot_name}
読み取り結果の全文：{ocr_text}
申請者の氏名と表記の候補：{name_variants}
家計を支える人の氏名：{supporter_name}

【してほしいこと】
1. この書類が何かを、次の中から1つ選んでください。
   離職票／雇用保険受給資格者証／住民票の除票／死亡診断書の写し／
   診断書／罹災証明書／給与の明細／源泉徴収票／課税証明書／その他／unknown
   決められなければ unknown にしてください。
2. 書類に書かれた氏名、発行日、対象の期間、金額、事由の日付を取り出してください。
   それぞれに、値があった行の文字列をそのまま写して evidence に入れてください。
3. 給与の明細などで複数の月があれば、月ごとに分けて取り出してください。

【厳守事項】
- 書かれていない値は空にしてください。前後の月や他の書類から補わないでください。
- 金額を合計したり、年額に換算したりしないでください。書かれた金額だけを写してください。
- 日付は書類の表記のまま写してください。和暦を西暦に直すのはこちらで行います。
- 氏名が申請者と一致するかは判断しないでください。書かれた氏名を写すだけにしてください。
- 支援の対象になるか、要件を満たすかを書かないでください。
- 書類が本物かどうかを書かないでください。
- evidence は、読み取り結果の全文にある文字列をそのまま写してください。言い換えないでください。

「和暦を西暦に直すのはこちらで行う」と書くのは、日付の変換の誤りを避けるためです。 令和と平成の境目や、年度と年の違いをAIが変換すると、1年ずれた期間が「足りている」ことになります。 変換は Python の規則で行います。

「一致するかは判断しない」も同じ理由です。 旧姓、旧字体、家計を支える人の氏名。どれが一致とみなせるかは、奨学金係の決まりです。 AIには書かれた文字を写させ、照合は表記の候補の一覧で Python が行います。

出力形式を固定する

書類1点ごとに、Gemini から次の形で受け取ります。

{
  "file_id": "",
  "slot_name": "",
  "document_type": "給与の明細 | 源泉徴収票 | 課税証明書 | ... | その他 | unknown",
  "names": [{ "value": "", "evidence": "" }],
  "issue_date": { "value": "", "evidence": "" },
  "periods": [{ "value": "", "amount": "", "amount_label": "", "evidence": "" }],
  "event_date": { "value": "", "evidence": "" }
}

申請1件ごとに、Python が次の形の点検結果をまとめます。

{
  "application_id": "",
  "application_type": "",
  "reason": "",
  "deadline": "",
  "days_left": 0,
  "checks": [
    { "required_doc": "", "status": "ok | missing | defective | unreadable",
      "file_id": "", "detail": "" }
  ],
  "verdict": "complete | needs_resubmission | needs_staff",
  "message_draft": ""
}

1つ目の理由は、AIの出力と点検結果を別の層に置けることです。 Gemini の出力は書類ごとの「何が書かれているか」だけで、status と verdict は Python が必要書類の一覧から決めます。 一覧が学期の途中で変わっても、Gemini の出力を読み直すだけで点検をやり直せます。

2つ目は、evidence を機械で確かめられることです。 Gemini のスキーマ指定は JSON の形を守らせますが、公式の案内でも値の正しさはアプリケーションの側で確かめるようにとされています。evidence が読み取り結果の全文に無ければ、その値を捨てて空として扱います。

3つ目は、detail で学生への連絡文を具体的に書けることです。 defective の detail には「給与の明細：対象の月が〇月と〇月の2か月分。必要は3か月分」のように、何が足りないかを一覧の言葉で入れます。 連絡文の下書きは、この detail を並べて組み立てます。

days_left が7日以下の申請は、管理表の先頭に赤で並べます。

システムへ連携する

学生への連絡は、この構成から送りません。 下書きを管理表に置くところまでで止め、送るのは係員が確かめた後です。 家計が急に苦しくなった学生に、誤った不足の連絡が機械的に届くことは避けます。

基幹システムには書き込みません。 点検の結果は管理表だけに置き、採用や支援区分に関わる登録は、係員がこれまでどおりの手順で行います。

人が確認する

係員は全件の点検結果を確かめます。

1. needs_staff を先に見る … 事由の選択欄が読めない、書類の種類が unknown、氏名が表記の候補と合わない、といった申請です
2. 期限までの残り日数の短いものから見る … 7日以下の申請は、その日のうちに連絡します
3. defective と unreadable の根拠を画像で確かめる … evidence の行が書類の画像の上で示されます。本当に期間が足りないのか、読み取りが1か月分を落としただけなのかを目で見ます
4. 連絡文を直して送る … 何を、いつまでに、どの欄に上げればよいかが書かれているかを確かめます
5. complete のものを要件の確認へ回す … ここから先は、これまでどおり係員が学業成績と家計の状況を確かめます

3番目を省かないでください。 defective は、学生に書類を取り直させる連絡につながります。読み取りの見落としで「足りない」と連絡すると、学生は発行元へもう一度足を運びます。 家計急変の学生にとって、その手間は軽くありません。

目標は、1件9分です。 書類を1点ずつ開いて探すのではなく、取り出された値と根拠の行を確かめる時間です。9分を大きく超える申請が続くときは、必要書類の一覧が細かさに欠けて needs_staff が増えているか、写真の質が悪いかのどちらかです。

例外に対処する

上から2行目と4行目は、学生への頼み方が変わる例外です。 どちらも「不備」と一言で連絡すると、学生は書類を取り直しに行きます。欄の間違いと撮り直しは、学生の手元で数分で直ります。 連絡文の書き分けを、status と detail の組み合わせで機械的に行います。

記録を残す

• 申請の番号、申請の種類、事由、受付日時、提出完了の日時
• 書類ごとのファイルと、アップロードした欄の名前
• Document AI が返したJSONの全文と、使ったプロセッサの種類
• Gemini が返したJSONの全文と、evidence の照合の結果
• 点検結果（checks、verdict）と、そのとき使った必要書類の一覧の版
• 係員が点検結果を変えた記録 … どの書類の判定を、どちらに変えたか
• 学生への連絡の日時と内容、再提出の日時

5つ目で一覧の版を残すのは、一覧が制度の変更で直るためです。 必要書類が変わった後に、以前の申請の点検結果を問われたとき、当時どの一覧で点検したかが残っていないと説明できません。

6つ目は、一覧を直す材料になります。 係員が defective を ok に変えることが多い書類は、一覧の「代わりになる書類」が足りていない可能性があります。