ホテルの清掃委託会社から毎月届く請求明細を、客室ごとの清掃の実績（チェックアウト・連泊・特別清掃）と単価表に照らして、件数と金額の食い違いを支払の前に拾う

処理の起点を決める

Watch emails を1時間ごとに動かします。 対象は、委託先2社のアドレスから届いた、添付のあるメールです。委託先のアドレスから届いたメールに「清掃請求」のラベルを付ける Gmail のフィルターを置き、そのラベルだけを見ます。取り込んだときに既読にする設定にはしません。

請求明細は月に1回ですが、届いたらすぐに動かします。 12施設の明細が同じ週に届き、支払の締めまで数日しかありません。1通目が届いた日に照合が始まれば、委託先に問い合わせて訂正の請求を受け取る時間が残ります。

同じ施設の同じ月の明細が2回届いたら、2回目を訂正版として扱います。 施設のコードと対象の月で照合の表を引き、すでに行があれば、前の行を消さずに「訂正前」の印を付けてから新しい行を書きます。 訂正の前後で何が変わったかを、後から見られるようにするためです。

入力データを集める

質を決めるのは、いちばん下の契約の定義です。 第3章の（b）の食い違いは、定義を読めばどちらの数え方が正しいかが分かるものが多いのですが、契約書の定義は短く、運用の取り決めはメールのやり取りに散らばっています。最初の準備として、定義と、その後に取り決めた運用を1つの文書にまとめます。

単価表には適用の開始日を持たせます。 単価は年に1回見直されることがあり、月の途中で単価が変わる月は、日によって正しい単価が違います。

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

請求明細は、PDFをそのままAIに渡して表にします。 Make an API Call の本文に、取り出したPDFを base64 にした document のブロックと、取り出しの指示を入れます。明細の書式は委託先2社で違いますが、取り出す項目は同じなので、指示は1つで足ります。

照合の表は、施設ごと・月ごとに1枚のシートにします。 AIが返した行を Bulk Add Rows で書き込むと、同じシートの式が次を計算します。

差の計算をスプレッドシートの式にするのは、誰が見ても同じ答えになるからです。 AIに「件数が合うか」を聞くと、数え方の説明は上手でも、数そのものを取り違えることがあります。 数は式、見立てはAI、と分けます。

どこまでの差を「差あり」とするかも、表の側で決めます。 件数の差が0でも金額の検算がずれる行、件数の差が1件だけの行も、すべて差ありとして拾います。 1件の差でも、毎日続けば月に30件になるからです。逆に、施設がまだ書き出しを始めていない日の行は「実績なし」として差の計算から外し、存在しない食い違いを作らないようにします。

差のある行は Search Rows で取り出し、Iterator で1行ずつAIに渡します。 そのとき、その日の客室の実績の行（客室番号と状態、チェックアウトの時刻）と、前後1日の実績を一緒に渡します。夕方のチェックアウトが翌日の清掃に回った、という見立ては、前後の日を見ないと立てられません。

AIへ渡す前に整形する

1. ファイルの確認 … 添付がPDFであること、パスワードが付いていないことを確かめます。付いていれば委託先に外して送ってもらいます
2. 施設と月の特定 … 件名とファイル名から施設のコードと対象の月の候補を拾い、AIが読み取った値と一致するかを確かめます。一致しなければ照合に進まず、担当に回します
3. 合計の検算 … AIが返した明細の金額の合計が、PDFに書かれた請求の合計と合うかを確かめます。合わなければ読み取りの誤りを疑い、照合に進みません
4. 実績の書き出しの確認 … その施設のその月の客室の実績が、全日分そろっているかを確かめます
5. 重複の確認 … 同じ施設・同じ月の明細がすでにあれば、訂正版として扱います

3番目が、読み取りの誤りを止める関所です。 明細の1行を読み飛ばしたり、件数と金額を取り違えたりすると、照合の表に存在しない食い違いが現れます。合計が合わない明細を照合に進めると、委託先に誤った問い合わせを送ることになります。

AIに処理させる

AIを2回呼びます。 1回目は請求明細を表にすること、2回目は差のある行ごとの判定です。この構成の主眼は2回目です。

2回目で付けさせる判定は、次の4つです。

判定ごとに、根拠を書かせます。 根拠は「どの客室の、どの記録を見て、契約の定義のどの文に当てはめたか」で、契約の定義の文はそのまま写させます。

3行目がいちばん守らせたいことです。 判定の文に「○○円を差し引いて支払う」と書かせると、そのまま支払の処理に流れる恐れがあります。 問い合わせの下書きにも、差し引くという言葉は使わせません。

指示内容を固定する

2回目（食い違いごとの判定）の指示の例です。

あなたはホテルの本部の経理で、客室清掃の委託費の請求明細を確かめる担当です。
渡された材料だけを見て、食い違いの理由の見立てを付けてください。
推測で補わないでください。

【判定】
- vendor_error_candidate ... 実績と契約の定義から見て、請求の件数・単価・区分が
                               誤っている候補
- record_gap_candidate ..... 自社の客室の実績や特別清掃の依頼の記録に
                               抜けがある候補
- definition_check ......... 契約の定義の読み方で、どちらの数え方もありうる
- undetermined ............. 渡された材料では見立てが立たない
迷ったときは vendor_error_candidate を選ばないでください。

【厳守事項】
- 件数と金額の計算をしないでください。差は渡した値をそのまま使ってください。
- 根拠には、見た客室番号と記録の値、当てはめた契約の定義の文を書いてください。
  契約の定義の文は、渡した文書からそのまま写してください。
- 前後の日の実績も見て、日をまたいだ数え方の違いで説明できるかを確かめてください。
- 特別清掃の依頼の記録が無いことだけを理由に vendor_error_candidate にしないでください。
  口頭の依頼で記録が残っていない場合があります。record_gap_candidate も検討してください。
- 支払う額、差し引く額、委託先の責任について書かないでください。
- 委託先への問い合わせの文には、確かめたい日・区分・件数と、
  こちらの記録の値だけを書き、どちらが正しいかを書かないでください。

【施設と月】{facility} {month}
【食い違いの行】{diff_row}
【その日と前後1日の客室の実績】{room_records}
【その日の特別清掃の依頼の記録】{special_requests}
【契約の定義（運用の取り決めを含む）】{definition_text}

「依頼の記録が無いことだけを理由に請求の誤りにしない」を明記しないと、特別清掃の食い違いがすべて請求の誤りになります。 第3章の（c）のとおり、フロントの口頭の依頼は記録に残っていないことがあります。記録が無いことは、依頼が無かったことの証明になりません。

「迷ったときに vendor_error_candidate を選ばない」と書くのも同じ理由です。 委託先への問い合わせは、空振りが続くと委託先の現場の担当者に余計な調べものをさせ、関係を悪くします。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "facility": "",
  "date": "",
  "category": "checkout | stayover | no_service_stay | special",
  "diff": { "count": 0, "unit_price": 0, "amount_check": 0 },
  "verdict": "vendor_error_candidate | record_gap_candidate | definition_check | undetermined",
  "rooms_examined": [""],
  "evidence": "",
  "definition_quote": "",
  "question_to_vendor": "",
  "question_to_rooms": ""
}

1つ目の理由は、verdict で回す先が機械的に決まることです。 Router の枝のフィルターを verdict の値で書けば、請求の誤りの候補は委託先への下書きへ、記録の抜けの候補は客室部門の一覧へと流れます。

2つ目は、diff を渡した値のまま返させることです。 AIの判定と、式で計算した差を同じ行に並べておけば、AIが数を書き換えていないかを、照合の表と1対1で見比べられます。 違っていれば、その判定は使いません。

3つ目は、definition_quote で定義の当てはめを確かめられることです。 経理の担当は、契約書を開かなくても、どの文に当てはめた見立てかを読めます。 定義の文が間違っていれば、判定ごと差し戻します。

委託先への問い合わせは、vendor_error_candidate の行を施設ごとにまとめ、Array aggregator で1通にしてから、Gmail の Create a draft email で下書きにします。送信は経理の担当が行います。

システムへ連携する

会計システムには書き込みません。 支払の処理は、委託先から訂正の請求が届いた後に、経理の担当がいつもの手順で行います。この構成が出すのは、確かめるべき食い違いの一覧までです。

予約管理システムにも書き込みません。 客室部門の確認で記録の抜けが分かったときに、予約管理システムを直すかどうかは客室部門が決めます。

人が確認する

1. 合計の検算が合わなかった明細を先に見る … 読み取りの誤りか、明細そのものの誤りかを確かめます
2. vendor_error_candidate の根拠を確かめる … 見た客室と記録の値を、予約管理システムで確かめてから問い合わせを送ります
3. record_gap_candidate は客室部門に聞く … 口頭の特別清掃の依頼が無かったか、清掃なしの連泊の記録が漏れていないかを確かめます
4. definition_check は契約の担当が決める … 決めた読み方を契約の定義の文書に書き足します
5. 判定を覆したら記録する … どの判定を、どれに変えたか、理由を残します

4番目が、翌月以降の判定を軽くします。 定義の読み方を文書に書き足すと、翌月の同じ型の食い違いは definition_check ではなく、どちらかの判定に落ちるようになります。

目標は、12施設をならして1件75分です。 差のある行が1施設10行前後という想定です。それより多い月は、予約管理システムの書き出しが欠けているか、定義の文書が追いついていません。

例外に対処する

上から4行目までが大半を占めます。 どれもAIの判定の問題ではなく、明細と実績という材料の欠けの問題です。 材料が欠けた行を判定させないことが、判定の精度を上げるより効きます。

記録を残す

• 受け取った請求明細のPDFと、受け取った日時、訂正版かどうか
• 1回目の読み取りの結果のJSONと、合計の検算の結果
• 照合の表（その月の版を、訂正前の行も含めて残す）
• 2回目の判定のJSONと、そのとき参照した契約の定義の文書の版
• 人が判定を覆した記録 … どの判定を、どれに変えたか
• 委託先への問い合わせと、訂正の請求との対応

4つ目で定義の文書の版を残すのは、文書が毎月書き足されるからです。 後から判定を見直すときに、当時の定義で見た判定か、新しい定義で見た判定かを分けられます。