窓口に届く紙の申請書・届出を読み取って受付台帳と不備の連絡文を作る

処理の起点を決める

SharePointの受付フォルダにスキャンファイルが保存されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルが作成されたとき」トリガーが用意されています。

様式ごとにフォルダを分けるか、1つのフォルダに入れて様式を自動判定するかは、運用によります。最初は様式ごとにフォルダを分けることを勧めます。 判定の誤りという不確実性を1つ減らせるためです。窓口の担当者がスキャン時にフォルダを選ぶ手間は数秒です。

入力データを集める

2番目の「様式の定義」を先に作ることが、この構成の準備の大半です。 12種類の様式それぞれについて、どの欄が必須で、どの欄が選択式で、どの欄が日付かを書き出します。この作業は紙の様式を見ながら行う地道な整理で、AIには任せられません。

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

読み取り： Azure AI Document Intelligence を使います。この業務で効くのは次の2つです。

• レイアウトモデル … 文字の抽出に加えて、表、段落、見出し、および選択マーク（チェックボックス等）の選択・非選択の状態を抽出します。選択式の欄が多い申請書では、ここが手作業との差になります
• カスタム抽出モデル … 自法人の様式に合わせて、どの位置のどの項目を取り出すかを学習させます。同じ様式が5件あれば学習を始められます。 様式が固定であればテンプレート型、記入位置が揺れるものはニューラル型を選びます

手書きの扱い： 読み取りの土台となるReadモデルは、英語・中国語簡体字・フランス語・ドイツ語・イタリア語・日本語・韓国語・ポルトガル語・スペイン語の手書きテキストに対応しています。ただし、「その行が手書きかどうか」を判定して返す機能はラテン文字の言語に限られます。日本語の手書きは読めるが、手書きであることを機械的に区別する前提の設計にはしない、と考えてください。

学籍データ： 学籍管理システムのAPI、または日次で書き出したファイルを参照します。リアルタイム連携は必要ありません。

過去の不備の類型： 最初は担当者への聞き取りで10〜20件書き出せば足ります。運用しながら増やします。

AIへ渡す前に整形する

1. 向きの補正 … 窓口で急いでスキャンすると、上下逆や横向きが混ざります。OCRサービス側で補正されるかを確認し、されない場合は前段で回転させます
2. 複数枚の結合と分割 … 2枚組の様式が別ファイルになっていたら結合し、1ファイルに複数の申請が入っていたらページ単位で分割します
3. 白紙・裏面の除去 … 両面スキャンで白紙が混ざります。文字量が一定以下のページを落とします
4. 様式の判定 … フォルダで分けていない場合は、様式名の記載位置から種類を判定します。判定できなかったものは処理を止めて人に回します。 推測で進めません
5. 画質の確認 … 薄い鉛筆書きやかすれたコピーは、読み取りの信頼度が下がります。信頼度が低いものは自動で「要目視」に分類します

AIに処理させる

OCRと生成AIで役割を分けます。

OCR（Document Intelligence）にさせること： 記入欄の文字の読み取り、チェック欄の選択状態の判定、表形式の欄の読み取り。

生成AIにさせること：

生成AIに読み取りの訂正をさせないでください。 「この欄はおそらく『田中』と書いてある」といった補完をさせると、原本と違う内容が台帳に入ります。読めなかったものは読めなかったまま人へ回します。

指示内容を固定する

あなたは学校事務の窓口担当を支援する担当者です。
OCRで読み取った申請書の内容と、様式の定義、学籍データをもとに、
記入の不備を検出し、申請者への連絡文の下書きを作ってください。

【厳守事項】
- OCRの読み取り結果を書き換えないでください。
  読めていない欄を推測で埋めないでください。空欄は空欄のまま扱ってください。
- 氏名・学籍番号・日付は、読み取り結果のとおりに転記してください。
  学籍データに合わせて書き換えないでください。
  食い違いがある場合は discrepancies に「紙の値」と「学籍データの値」を両方書いてください。
- 必須欄かどうかは、下の様式定義にのみ従ってください。
  一般的な申請書の慣習で判断しないでください。
- 連絡文には、何をどう直してほしいかだけを書いてください。
  申請の可否や、規程の解釈にあたる説明を書かないでください。
- 読み取りの信頼度が低い欄は low_confidence_fields に列挙してください。

【様式の定義】
{form_definition}

【学籍データ】
{student_record}

【OCRの読み取り結果】
{ocr_result}

「学籍データに合わせて書き換えない」の1行が重要です。 これを書かないと、紙に「田中太朗」と書かれていても学籍データの「田中太郎」に寄せて出力します。申請者が誤記したのか、改姓の届出漏れなのかが分からなくなります。

出力形式を固定する

{
  "form_type": "",
  "received_at": "",
  "student_id": "",
  "fields": {
    "氏名": { "value": "", "confidence": "high | medium | low" },
    "申請日": { "value": "", "confidence": "" },
    "用途": { "value": "", "confidence": "" },
    "通数": { "value": 0, "confidence": "" }
  },
  "selection_marks": {
    "和文": true,
    "英文": false
  },
  "missing_required": [],
  "discrepancies": [
    { "field": "", "on_paper": "", "on_record": "" }
  ],
  "low_confidence_fields": [],
  "notice_draft": "",
  "needs_review": true
}

通数のような数値は数値型で返させます。文字列で返すと、後段の集計で壊れます。

needs_review は既定で true にします。不備がない場合でも人が受け付けるためです。 ここを条件によって false にする設計は、運用が安定してから検討してください。

システムへ連携する

受付が確定したら、次の2つへ書き込みます。

2番目は慎重に扱ってください。 住所変更届を自動でマスタへ反映する構成は作れますが、読み取り誤りがそのまま基幹データを書き換えます。 最初は台帳への記録までにとどめ、マスタ更新は従来どおり人が行う形を勧めます。

原本のスキャンは、受付番号をファイル名に含めて保管します。台帳から原本を引けるようにしておくと、後から照合できます。

人が確認する

全件、人が確認して受け付けます。

理由は、申請の受付が「相手の権利にかかわる手続き」だからです。読み取り誤りで証明書の通数が変われば、申請者に再来を求めることになります。休学の願い出の日付を取り違えれば、在籍の扱いが変わります。

確認を速くするための設計が重要です。

• 確認画面で、スキャン画像と読み取り結果を左右に並べて表示する
• 信頼度が低い欄、不備として検出された欄を色分けする
• 学籍データとの食い違いは、両方の値を並べて表示する
• 前の申請と同じ内容が続く場合（同じ学生からの複数申請）は、まとめて表示する

これらがないと、確認に3分かかり、削減効果が出ません。確認画面の作り込みが、この構成の成否を決めます。

例外に対処する

記録を残す

この業務では、記録の保存が規程上の要件になります。

• 申請書のスキャン原本（保存年限は自法人の文書管理規程に従う）
• OCRの読み取り結果（生の状態）
• 生成AIが検出した不備と、連絡文の下書き
• 受け付けた担当者と受付日時
• 人が修正した欄と、修正前後の値

最後の項目が精度の実測値になります。「氏名はほぼそのまま通るが、日付の欄は2割修正されている」と分かれば、どの欄の読み取りを改善すべきかが決まります。様式の書式そのものを直す判断材料にもなります。