予約サイトから毎月届く精算明細のPDFを読み取り、予約台帳と突き合わせて、手数料・取消・入金額の差異を理由別に仕分ける

処理の起点を決める

受付用フォルダにPDFが保存されたことを起点にします。 精算明細は月末から月初に集中して届くため、週1回や月1回のまとめ処理にはしません。 届いた順に処理すれば、最後の1通が届いた時点で大半の突合が終わっています。

Google Apps Script の時間主導のトリガーで、数分ごとに受付用フォルダを見て新しいファイルを拾います。処理が終わったファイルは、施設と月ごとの処理済みのフォルダへ移します。 移すのは突合の結果を書き出せたときだけにします。受付用フォルダに残っている数が、未処理の数です。

ファイル名は「施設コード_予約サイトコード_対象月.pdf」の形で保存する運用にします。予約サイトと施設をPDFの中身から推し量らないためです。 列の対応表を選ぶ鍵になるので、ここを人の運用で固めます。

入力データを集める

質を決めるのは、予約台帳の「予約サイト側の予約番号」です。 突合の鍵はこの番号だけで、宿泊者名や宿泊日で突き合わせると同姓同日の予約で取り違えます。番号が台帳に入っていない予約は、この構成では突き合わせません。 「台帳に番号なし」として人に回します。

契約の条件は、改定の日付を持たせて管理します。 手数料率はキャンペーンや契約の見直しで変わります。宿泊日で見るか、予約日で見るかは予約サイトとの契約によるので、その区分も条件の表に持たせます。

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

読み取りは、スクリプトから Form Parser を呼びます。精算明細は予約の件数によってページ数が変わるので、ページ数で呼び方を分けます。

Form Parser の上限は、オンライン処理で15ページ・40MB、imageless_mode を有効にすると30ページ、バッチ処理で100ページ・1GBとされています。imageless_mode の30ページは、1ページ目から連続して処理する場合に限られます。 途中のページだけを投げると15ページの上限に戻ります。

表はページごとに返るので、ページをまたいで1つの表につなぎ直します。 2ページ目以降にも同じ見出しが印字されている明細が多く、見出しの行が本体の行として混ざらないよう、見出しの文字列が一致する行を落とします。 取消の予約が別の表に分かれている明細は、表ごとに「通常」「取消」の区分を付けてからつなぎます。

予約台帳は、予約管理システムから対象月の一覧を書き出し、スプレッドシートとして同じフォルダに置きます。書き出しの抽出条件は、宿泊日で対象月に入る予約と、対象月に取り消された予約の両方にします。 取消の予約を落とすと、取消料の差異がすべて「台帳にない予約」になります。

AIへ渡す前に整形する

1. ファイル名の確認 … 施設コード・予約サイトコード・対象月が読めないファイルは処理せず、担当者に知らせます
2. 形式の確認 … PDFであることを確かめます。予約サイトの画面を撮った画像が混ざっていたら、PDFを取り直してもらいます
3. ページ数の確認 … 上の表のとおりに呼び方を選び、100ページを超えるものは分割します
4. 重複の確認 … 同じ施設・予約サイト・対象月の明細がすでに処理済みなら、差し替え版かを担当者に確かめます
5. 読み取り後の見出しの照合 … 読み取った見出しの列名を、その予約サイトの対応表と照らします。1つでも一致しない列があれば、対応表の更新待ちにして突合を止めます
6. 金額と日付の正規化 … 「¥12,300」「12,300円」「△1,200」を数値に、「2026/9/3」「9月3日」を日付にそろえます。「△」とマイナス記号は負の数として扱います

5番目で止めるのが、この構成で最も大事な前処理です。 予約サイトが書式を変え、「手数料」の列が「手数料（税込）」に変わっただけでも、税別として計算すれば全件に差異が出るか、逆に全件の差異が消えます。 列が1つでも見慣れなければ、突合を進めません。

AIに処理させる

生成AIにさせる仕事は2つです。 対応表に無い列が出たときに対応の案を出すことと、差のある予約について理由の候補を選ぶことです。表の読み取りはOCR、突合と計算はスクリプトが行います。

差異の理由は、次の一覧から選ばせます。

1行目がいちばん起きやすい失敗です。 明細の行と台帳の行を渡して「差異を調べて」と頼むと、生成AIは自分で手数料を計算し直し、その計算が合っていれば差異なしと書きます。 差の有無と額はスクリプトで決めてから渡し、生成AIには「この差の理由はどれか」だけを問います。

Gemini API では、スキーマを指定してJSONで受け取ります。 理由コードを enum として指定すれば、一覧に無い値は返りません。ただし構造化出力の説明でも、JSONとして正しくても中身が誤っていることがあるので、アプリケーションの側で値を検証するよう求められています。理由の候補は、根拠の文字列が明細と台帳に本当にあるかをスクリプトで確かめてから一覧に載せます。

指示内容を固定する

あなたは宿泊施設の経理担当で、予約サイトとの精算の食い違いの理由を調べる立場です。
渡された情報だけを見て、差異の理由の候補を選んでください。推測で埋めないでください。

【予約サイト】{ota_name}　【精算の形】{settlement_type}
【明細の行】{statement_row}      … OCRで読み取った1予約分の行と備考欄
【台帳の行】{ledger_row}         … 予約台帳の同じ予約番号の行、変更履歴、備考
【計算結果】{diff}               … スクリプトが計算した手数料・取消料・精算額の差
【契約の条件】{contract_terms}   … この予約に適用される手数料率と取消料の扱い

【理由コード】
rate_mismatch / cancel_fee / no_show / stay_changed /
point_coupon / not_in_ledger / not_in_statement / unknown

【厳守事項】
- 金額の計算をしないでください。差の有無と額は【計算結果】をそのまま使ってください。
  計算し直して「差異なし」と判断しないでください。
- 理由は理由コードの一覧から選んでください。一覧に無い理由を作らないでください。
  当てはまるものが無いときは unknown にしてください。
- 理由を選んだ根拠の文字列を、明細の行か台帳の行からそのまま写してください。
  根拠の文字列が無いときは、理由を選ばず unknown にしてください。
- 備考欄の略語（「NS」「泊変」など）を推測で読み替えないでください。
  意味が決められないときは unknown にしてください。
- 予約サイトへ申し立てるべきかどうかは書かないでください。
- 【精算の形】が「施設が受け取る」のときは、差の向きが逆になることに注意してください。
  向きの判断は【計算結果】の符号に従ってください。

「計算し直して差異なしと判断しない」を明記しないと、計算結果が無視されます。 生成AIは渡された数字から自分で手数料を出し直し、丸めの違いで差が消えれば「差異なし」と書きます。 差の有無はスクリプトが決めた事実として渡し、それを覆す経路を指示の上でも塞ぎます。

「根拠の文字列が無ければ unknown」は、理由の作り話を防ぐためです。 差額が宿泊料金の1泊分なら、根拠が無くても stay_changed を選びがちです。根拠の文字列を写させ、スクリプトでその文字列の存在を確かめることで、もっともらしい推測を一覧から外します。

出力形式を固定する

予約1件ごとに、次の形のJSONを作ります。 diff と match はスクリプトが入れ、reason と evidence は生成AIが入れます。

{
  "statement_id": "H02_OTA05_2026-09",
  "ota_reservation_no": "",
  "match": "matched | not_in_ledger | not_in_statement",
  "statement": { "stay_date": "", "nights": 0, "room_charge": 0,
                 "commission": 0, "cancel_fee": 0, "payout": 0,
                 "confidence_min": 0 },
  "ledger":    { "stay_date": "", "nights": 0, "room_charge": 0,
                 "cancelled": false, "cancel_fee": 0 },
  "diff": { "commission": 0, "cancel_fee": 0, "payout": 0 },
  "reason": "rate_mismatch | cancel_fee | no_show | stay_changed | point_coupon | not_in_ledger | not_in_statement | unknown",
  "evidence": "",
  "status": "ok | review | reread"
}

1つ目の理由は、diff と reason の書き手を分けていることです。 差の額はスクリプト、理由は生成AIが入れます。理由の一覧を変えても、差の計算には触れません。

2つ目は、confidence_min を持たせることです。 その行の金額の要素のうち、いちばん低い読み取りの信頼度を入れます。信頼度が低い行の差異は、理由を調べる前に読み取りを疑います。

3つ目は、status で人の見る順番を決めることです。

システムへ連携する

予約管理システムと会計ソフトへは書き込みません。 差異が見つかっても、台帳を直すのはフロントか予約の担当者で、会計ソフトへの計上は人が確かめた精算額で行います。 突合の結果から会計ソフトへ直接書く経路を作ると、読み取りの誤りがそのまま売上の数字になります。

列の対応表の更新も人が行います。生成AIの案は、対応表の横の「案」の列に書き出すだけにし、担当者が確かめて本表へ移します。

人が確認する

人が開くのは review と reread の予約だけです。 ok の予約は件数と合計額を一覧で見ます。

1. reread を先に見る … 読み取りの疑いがある行です。PDFの該当行と見比べ、読み取りを直してから突合し直します
2. 合計の検算を見る … 明細に印字された合計と、行を足し上げた額が合っているかを明細ごとに見ます。合わない明細は、行の読み落としを探します
3. review の理由と根拠を確かめる … evidence の文字列を明細と台帳で確かめます。unknown はフロントの記録まで当たります
4. 予約サイトへ問い合わせるものを決める … 理由と差額から判断します。問い合わせの判断は担当者が行います
5. 精算額の合計を入金額・請求額と照合する … 照合が済んだ明細だけを計上に回します

2番目を省かないでください。 行を1つ読み落とすと、その予約は not_in_statement として差異に出ますが、読み落とした行の金額が小さいと、理由を調べるうちに「予約サイト側の漏れ」と判断してしまいます。 合計が合わない明細は、差異を見る前に読み取りを確かめます。

例外に対処する

上から2行目と3行目が、書式の変化への備えです。 予約サイトの明細の書式は予告なく変わることがあり、変わった月に全件の差異が消える・全件に差異が出るのが最も気づきにくい失敗です。列が見慣れなければ止める、という1つの規則で両方を防ぎます。

記録を残す

• 精算明細のPDFと、取得した日時・取得した担当者
• Document AI が返した結果の全文（表、キーと値の組、信頼度）
• 突合に使った列の対応表と契約の条件のその時点の版
• 予約ごとのJSON（diff、reason、evidence、status）
• 担当者が理由を直した記録と、予約サイトへ問い合わせた結果
• 明細ごとの合計の検算の結果

3つ目で対応表と条件の版を残すのは、手数料率が後から変わるためです。 契約の見直しで率が変わった後に過去の月を見直すと、当時の率が残っていなければ、差異があったのかどうかが決まりません。