派遣・請負のスタッフから毎月届く手書きの交通費精算書と領収書の写真を読み取り、届け出た経路と運賃に照らして精算データを作り、食い違いを拾う

処理の起点を決める

提出用のフォルダにファイルが保存されたことを起点にします。 提出は締め日の翌日から3日間に集中するため、1日1回の夜間処理にはしません。 届いた順に読み取っておけば、3日間のうちに確認の一覧が少しずつたまり、担当者は締め切りを待たずに確認を始められます。

ファイル名の決まりを、提出の案内で決めておきます。 「スタッフ番号_対象月_種類_連番」の形にし、種類は「精算書」か「領収書」とします。ファイル名が決まりに合わないものは、読み取りに回さず、提出の受付の担当に戻します。 スタッフ番号の取り違えは、他人の精算に金額が載る誤りにつながるためです。

同じスタッフの精算書が二度上がることがあります。後から上がったものを正とし、前のものは処理済みに移して「差し替え」と記録します。 どちらを正とするかを担当者が毎回迷わないよう、規則で決めておきます。

入力データを集める

質を決めるのは、3行目の届けの有効期間です。 月の途中で派遣先が変わったスタッフは、変わる前と後で届けの経路が違います。有効期間が台帳に無いと、月の後半の行を古い経路で照らし、全部が食い違いとして出ます。 届けを上書きせず、期間付きで残す形に台帳を直すのが最初の準備作業です。

5行目の取り決めは、経理が持っている暗黙の決まりを書き出したものです。 「応援は営業の指示があれば認める」「深夜バスは領収書があれば認める」といった決まりを表にし、照合のプログラムが読めるようにします。

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

読み取りは、Power Automate からファイルを Azure AI Document Intelligence に送るだけです。精算書はレイアウトモデル、領収書はレシートモデルと、ファイル名の種類で振り分けます。

言語の指定はしません。 公式の説明では、深層学習の汎用モデルが文書の多言語の文字を取り出し、言語を確かめずに指定すると、関係する言語のモデルだけが使われ、不完全で誤った文字が返ることがあるとされています。駅名にアルファベットが混ざる精算書もあるため、自動の判定に任せます。

キーと値のペアは、オプションで有効にします。 v4.0 では、以前の一般文書モデルの役割がレイアウトモデルに加えられ、features=keyValuePairs を指定するとキーと値のペアを取り出せます。精算書の上の欄の氏名やスタッフ番号を、ファイル名の番号と照らすのに使います。

AIへ渡す前に整形する

1. ファイル名の確認 … 決まりに合うか、スタッフ番号が台帳にあるかを確かめます
2. 形式の確認 … PDF か画像であることを確かめ、それ以外は受付の担当に戻します
3. 画像の寸法と向きの確認 … 50×50から10,000×10,000ピクセルの間であること。横向きの写真は向きを直します
4. 文字の大きさの確認 … 1024×768の画像で12ピクセルが下限です。精算書の全体を遠くから撮った写真は、数字が小さすぎることがあります
5. パスワードの確認 … パスワード付きの PDF は、送る前にロックを外す必要があります
6. 1枚に複数の書類が写っていないかの確認 … 精算書と領収書を並べて1枚に撮ったものは、受付の担当に戻して撮り直してもらいます
7. 差し替えの確認 … 同じスタッフ・同じ月の精算書が既にあれば、差し替えとして扱います

4番目と6番目を軽く見ないでください。 スマートフォンで撮った精算書は、撮り方で読み取りの精度が大きく変わります。提出の案内に「1枚に1つ」「表の部分が画面いっぱいに入るように」と書くほうが、読み取りの工夫より効きます。

AIに処理させる

させるのは、精算書の表を1行ずつ、決まった項目にそろえることだけです。 届けと合っているかの判定は、照合のプログラムが行います。

右端の列が、人に回す行を決めます。 low_confidence は、手書きの数字の読み取りに自信が無い行です。届けの運賃に合わせて直さず、そのまま人に回します。

2行目がいちばん起きやすい失敗です。 読み取った「180」が届けの運賃「160」と違うと、AIは「読み違いだろう」と考えて160に直しがちです。直した瞬間、本当に180円の別の経路を書いた行が、届けどおりに見えます。

指示内容を固定する

あなたは経理部門で、スタッフの交通費精算書を精算データにそろえる立場です。
OCRが返した表の読み取り結果だけを見てそろえてください。推測で埋めないでください。

【1行ごとにそろえる項目】
1. date …… 日付（YYYY-MM-DD）。対象月は {target_month} です
2. from_station / to_station …… 乗車駅と降車駅
3. transport …… 電車／バス／その他
4. trip …… round（往復）／oneway（片道）／unknown
5. days …… 日数。「×18日」のようなまとめ書きは 18。1日1行なら 1
6. amount …… 書かれた金額（数字のまま）
7. note …… 備考欄の文字をそのまま
8. confidence …… 金額の欄について OCR が返した信頼度をそのまま

【厳守事項】
- 金額は読み取った数字をそのまま入れてください。
  届けの運賃や他の行の金額に合わせて直さないでください。
- 金額の信頼度が {threshold} 未満の行は flags に low_confidence を入れてください。
- 駅名は【駅名の一覧】から最も近いものを選び、station_raw に書かれた文字をそのまま残してください。
  一覧に近いものが無ければ、駅名を作らず flags に unknown_station を入れてください。
- 「同上」「〃」は直前の行の値を写し、flags に copied を入れてください。
- 日付が対象月の外なら flags に out_of_month を入れてください。
- 往復か片道か書かれていなければ trip を unknown にしてください。運賃から決めないでください。
- 交通費として認められるか、届けと合っているかは書かないでください。
- 精算書でない書類と判断した場合は、行を作らず document_type に種類を書いてください。

【OCRの表の読み取り結果】{layout_table}
【駅名の一覧（このスタッフの届けの駅と、取扱いの表にある駅）】{station_list}

「運賃から決めないでください」を書かないと、往復か片道かを金額から逆算します。 届けの片道運賃の2倍の金額なら往復だろう、と考えるためです。往復か片道かが書かれていないという事実が、照合の材料になります。 逆算させると、その材料が消えます。

駅名の一覧を、このスタッフの届けの駅と取扱いの表の駅に絞って渡すのにも意味があります。 全国の駅名を渡すと、手書きの崩れた駅名を似た名前の遠い駅に当てはめます。候補を絞れば、外れたときは unknown_station として出てきます。

出力形式を固定する

精算書1枚ごとに、次の形のJSONで受け取ります。 Azure OpenAI の構造化出力を使い、スキーマに沿った形で返させます。

{
  "staff_no": "",
  "target_month": "",
  "document_type": "commute_expense_form",
  "rows": [
    { "row_no": 1, "date": "", "from_station": "", "to_station": "",
      "station_raw": "", "transport": "train | bus | other",
      "trip": "round | oneway | unknown", "days": 1,
      "amount": 0, "note": "", "confidence": 0,
      "flags": ["low_confidence | unknown_station | copied | out_of_month | bulk"] }
  ],
  "total_written": null
}

照合のプログラムは、この行に次の印を足します。

1つ目の理由は、AIのそろえと照合の結果を別の層に置けることです。 flags はAIが付け、照合の印はプログラムが付けます。取扱いの決まりが変わっても、直すのはプログラムの規則だけです。

2つ目は、構造化出力で形が崩れないことです。 構造化出力は、指定した JSON Schema に従うようモデルに求める機能で、有効な JSON を返すだけの JSON モードと違い、スキーマへの厳密な従いを求められます。 すべての項目を必須とし、additionalProperties を false にする必要があるので、total_written のように書かれていないことのある項目は、null を許す形で定義します。

3つ目は、station_raw と confidence で確認が速くなることです。 担当者は写真を開く前に、何が書かれていて、どの程度の自信で読んだかを一覧で見られます。

システムへ連携する

給与計算のシステムへは、直接書き込みません。 確定した精算データを取込の形式で書き出し、取り込むのは担当者です。 取り込みを自動にすると、照合の規則の誤りがそのまま支給額になります。

スタッフ台帳も読むだけです。 届けと違う経路が続くスタッフがいても、台帳を書き換えません。届けを出し直してもらうかは、営業とスタッフが話して決めます。

人が確認する

人が見るのは、確認の一覧に載った行だけです。 印が route_ok だけの行は、精算データの合計を流し見て終わりにします。

1. low_confidence を先に見る … 写真を開いて数字を読み、正しい金額を入れます。多くは読み違いで、写真を見れば決まります
2. no_attendance を見る … 勤怠と精算書の日付を並べます。書き間違いなら直し、事情が分からなければスタッフに確かめます
3. off_route と receipt_missing を見る … 取扱いの表の条件に合うかを見ます。応援や研修の日なら、営業の指示があったかを確かめます
4. route_mismatch を見る … 届けと金額が違う行です。運賃の改定や経路の変更の可能性があり、続くなら届けの出し直しを営業に頼みます
5. 直したら理由を書く … どの行を、何から何に直したかを残します

1番目と4番目を混ぜないでください。 low_confidence は読み取りの問題で、route_mismatch は書かれた内容の問題です。読み違いを届けとの違いとして扱うと、スタッフに不要な確認の連絡が飛びます。

スタッフへの確認の連絡は、下書きまでにします。 Azure OpenAI が、確かめたい行と理由を書いた文面を作り、担当者が直してから送ります。 交通費の確認は、スタッフに「疑われている」と受け取られやすい連絡だからです。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの問題ではなく、提出の仕方の問題です。 提出の案内とファイル名の決まりを整えるほうが、読み取りの精度を上げるより効きます。

記録を残す

• 元の写真と、提出の日時、差し替えの有無
• Document Intelligence が返した JSON の全文（表、単語、信頼度、レシートの値）
• AI がそろえた行と flags、照合のプログラムが付けた印と、そのとき参照した届けの内容
• 担当者が直した記録 … どの行を、何から何に、なぜ直したか
• スタッフへ確認した日時と、回答の要旨
• スタッフごとの low_confidence と route_mismatch の発生の回数

3つ目で「そのときの届けの内容」を残すのは、届けが後から変わるためです。 経路の届けが出し直されると、過去の照合の意味が変わり、当時の届けが残っていないと、払った額が正しかったかを確かめられません。

最後の行は、提出の案内を直す材料になります。 特定のスタッフだけ low_confidence が続くなら、撮り方か書き方に理由があります。