派遣スタッフから毎月届く手書きのタイムシートを読み取り、派遣先への請求データと給与計算用の勤怠データにそろえる

処理の起点を決める

受付フォルダを、締め日の翌日から数営業日のあいだは15分ごとの定時実行で見に行きます。 月の残りは1日1回に落とします。届いた順に処理すると、差し戻しを早く出せます。 差し戻しが1日遅れると、スタッフが確認印をもらい直す時間がそのまま削られます。

入る経路は、スキャンした紙、FAXのPDF、メールの写真、PDFの4つです。いずれも同じ受付フォルダに入れ、ファイル名の先頭に経路の記号を付けます。経路ごとにフォルダを分けると、どれか1つだけが処理されない日ができます。

処理済みフォルダへ移すのは、判定まで書き終えたときだけです。 受付フォルダに残っている数が、そのまま未処理の数になります。

入力データを集める

質を決めるのは、下の3つです。 対応表が無ければ、「拘束」が実働なのかを毎回推すことになります。請求と給与の区分を別の表で持つのは、同じ1日の残業が、契約では「時間外」、給与では「法定内の残業」と別の扱いになることがあるためです。

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

スクリプトから Form Parser を呼び、結果から次のものを取り出します。

派遣契約の一覧は、スタッフ番号が先、氏名が後で引きます。 番号の欄が無い書式では、氏名と派遣先と対象月の3つで引きます。氏名だけで引くと、同姓同名や月の途中で派遣先が変わったスタッフで取り違えます。

キーと値のペアには既知の弱点があります。 Form Parser の制限事項には、値が空欄のキーと値のペアは確実には解析されないとあります。返らなかった項目は「空欄」として扱い、読み取りの失敗とは分けて記録します。

写真のときだけ、先に Enterprise Document OCR の画像品質スコアを取ります。 enableImageQualityScores を有効にするとページごとに0〜1のスコアが返り、0.5を下回ると、ぼやけ・暗さ・反射などの欠陥の種類が返ります。撮り直しを頼むときに、何が悪かったかを伝えられます。

AIへ渡す前に整形する

1. 形式の確認 … PDF、TIFF、JPEG、PNG、BMP、WebP などが対応する形式です。一覧にない形式は変換してから入れます
2. 解像度の確認 … スキャンは最低200dpi、300dpi以上が一般に最も良い結果になるとされています。複合機の既定の設定を先に見直します
3. 画像の品質の確認（写真のみ） … 品質スコアが基準を下回るものは、読み取りに進めず unreadable の候補にします
4. ページの確認 … 2ページに分かれる書式は1件として扱い、複数のスタッフがまとめてスキャンされたものはページで分けます
5. 重複の確認 … 同じスタッフ・同じ対象月のタイムシートが既にあれば、差し替えの印を付けて人へ回します
6. 書式の判定 … 見出しの文字列を書式の対応表と照らし、どの書式かを決めます

2番目と3番目を軽く見ないでください。 手書きの細い数字は、解像度が足りないだけで「1」と「7」の区別が消えます。5番目は、締め後に多い送り直しへの備えです。 差し替えの印が付いたものは、自動で上書きしません。

AIに処理させる

させるのは3つだけです。 書式の対応表に無い書式の列見出しを標準の項目に対応付ける案、備考欄の自由な書き込みを区分コードに寄せる候補、そして差し戻し文の下書きです。

対応付けの案は、そのまま使いません。 担当者が確かめて対応表に登録し、次の月からは対応表だけで読みます。 同じ書式が月によって違う読まれ方をするのを防ぐためです。

2行目がいちばん起きやすい失敗です。 一部が読めない「9:0□」は、所定の始業が9時なら「9:00」と埋められ、9時5分に来た日の記録が消えます。

指示内容を固定する

列見出しの対応付けと備考欄の区分は、同じ呼び出しで行います。

あなたは人材派遣会社の業務管理課で、派遣スタッフのタイムシートを
標準の項目にそろえる担当です。
OCRが返した表の見出しと、備考欄の文字列だけを見て答えてください。
推測で値を作らないでください。

【1. 列見出しの対応付け】
次の見出しの一覧の1つずつについて、標準の項目のどれに当たるかを選んでください。
標準の項目：work_date（日付）／ start_time（始業）／ end_time（終業）／
break（休憩）／ worked（実働）／ overtime（残業）／ late_night（深夜）／
note（備考）／ staff_sign（本人の確認）／ client_stamp（派遣先の確認）
- どれにも当たらない見出しは unmapped にしてください。
- 1つの見出しを2つの項目に割り当てないでください。
- 休憩が「12:00〜13:00」のような時刻の範囲で書かれているか、
  「60」のような分で書かれているかを、値の例から判断し、
  break_format に range ／ minutes ／ unknown のどれかを入れてください。
- 「拘束時間」「在社時間」を worked にしないでください。
  休憩を引く前の時間です。迷ったら unmapped にしてください。

【2. 備考欄の区分】
次の備考の文字列の1つずつについて、区分コードの候補を選んでください。
区分コード：paid_leave（有給休暇）／ half_am（午前休）／ half_pm（午後休）／
late（遅刻）／ early_leave（早退）／ holiday_work（休日出勤）／
comp_off（振替休日）／ absence（欠勤）／ other（その他）
- 書かれていない区分を補わないでください。空欄は空欄のまま返してください。
- 2つの区分が書かれていれば、両方を返してください。
- 区分を決めた根拠の文字列を evidence にそのまま写してください。

【厳守事項】
- 時刻や時間数を計算しないでください。読めない数字を補わないでください。
- 時間外か、深夜か、休日かの判断をしないでください。
- 派遣先の確認印があるかどうかを書かないでください。

【見出しの一覧】{headers}
【値の例（先頭3行）】{sample_rows}
【備考の一覧】{notes}

「拘束時間を worked にしない」を明記しないと、worked を選びがちです。 見出しに「時間」と付き、値が時間数だからです。取り違えると、休憩の分だけ請求も給与も多くなります。

「計算しない」を2か所に書いているのは、 備考の「1時間早退」から終業の時刻を書き換えて返すことがあるためです。区分を付けることと時刻を直すことは別の仕事です。

出力形式を固定する

生成AIからは、次の形のJSONで受け取ります。 Gemini API の構造化出力で、mime_type に application/json を指定してスキーマを渡し、enum で標準の項目と区分コードの値を縛ります。

{
  "format_id": "",
  "header_map": [
    { "header": "", "field": "start_time | end_time | break | worked | unmapped", "evidence": "" }
  ],
  "break_format": "range | minutes | unknown",
  "notes": [
    { "row_date": "", "raw": "", "codes": ["paid_leave"], "evidence": "" }
  ]
}

スクリプトが最後に組み立てる1件の結果は、次の形です。

{
  "sheet_id": "",
  "staff_no": "",
  "client_id": "",
  "month": "2026-09",
  "days": [
    { "date": "2026-09-01", "start": "09:00", "end": "18:00", "break_min": 60,
      "worked_min": 480, "note_codes": [], "cell_confidence": 0.97, "status": "ok | unreadable | blank" }
  ],
  "total_written_min": 9600,
  "total_calc_min": 9600,
  "stamp_crop": "crops/2026-09/xxxx.png",
  "verdict": "ready | unreadable | mismatch | no_stamp | needs_human",
  "reasons": []
}

1つ目の理由は、AIの出力と計算の結果を別の層に置けることです。 header_map と notes はAIが埋め、worked_min はスクリプトが計算し、verdict は規則で決めます。端数の扱いが変わっても、直すのは規則だけです。

2つ目は、日ごとの status で読めなかった日と空欄の日を分けられることです。 unreadable は信頼度が低い日、blank は何も書かれていない日で、後者は休みの日かもしれないので契約の勤務日と照らします。

3つ目は、請求と給与の両方を同じ days から作れることです。 1日分の時刻が請求と給与でずれることが起きません。

要は、mismatch と unreadable を混ぜないことです。 読めない日が1日でもあれば、合計は比べようがありません。unreadable を先に判定し、すべて読めたものだけで合計を比べます。

システムへ連携する

販売管理システムと給与計算ソフトへは、直接書き込みません。 書き込みまで自動にすると、読み取りの誤りが請求書と給与明細まで一息に進みます。

請求用と給与用のCSVは、同じ days から別々の規則で作ります。 請求側は契約の単価と区分と端数の扱い、給与側は就業規則から作った区分の表です。どちらも表として持ち、スクリプトに書き込みません。 書式の対応表への登録も、担当者が確かめてから手で行います。

人が確認する

人が1枚ずつ開くのは、ready 以外のものだけです。 ready のものは、確認印の画像を一覧で流し見ます。

1. 確認印の画像の一覧を見る … 切り出した印の欄を1画面に数十枚ずつ並べ、印が無いものに no_stamp を付けます。 全件が対象ですが1枚数秒です
2. unreadable の日を確かめる … 該当するセルの画像を見て、人の目で読めるなら直し、読めないならスタッフに確認します。 推して埋めません
3. mismatch の内訳を見る … 計算した合計と書かれた合計の差が、休憩の引き忘れか、足し間違いか、1日分の読み違いかを見ます
4. 差し戻し文を直して送る … 理由ごとに、スタッフ宛てか派遣先宛てかが分かれた下書きを直します。送信は人が行います
5. 読み取りを直したら記録する … どの日のどの欄を、何から何に直したかを残します

1番目を自動にしないのは、印の形がそろっていないからです。 朱肉の印、手書きの署名、電子承認の印字があり、どれを確認とみなすかは派遣先との取り決めです。

目標は、600枚をならして1枚3分です。 ready 以外が2割前後という想定で、それより多い月は、写真の品質が落ちているか、書式の対応表が足りていません。

例外に対処する

上から2行目までが大半を占めます。 どれも写真の撮り方と対応表の整備の問題で、撮り方の見本を1枚配るほうが読み取りの工夫より効きます。

記録を残す

• 元のファイルと、受け取った日時・経路（紙／FAX／写真／PDF）
• OCRが返したJSONの全文と、写真の画像品質スコア
• 生成AIが返した対応付けの案と区分の候補、担当者が登録した書式の対応表の版
• 日ごとの結果（days）、判定（verdict）、そのとき参照した派遣契約の内容
• 人が読み取りを直した記録 … どの日のどの欄を、何から何に直したか
• 差し戻した日時、相手（スタッフ／派遣先）、理由、再提出されたファイルとの対応
• 書式ごと・経路ごとの unreadable の発生率

4つ目で「そのときの契約」を残すのは、契約が月の途中で変わるためです。 最後の行は、書式を変えてもらう相談の材料になります。