仮払金と立替経費の未精算を毎月点検して、督促と精算処理の候補を出す

処理の起点を決める

月次の締めの翌営業日に、Schedule by Zapier の Every Month で起動します。 締めの日が月によって前後する場合は、日付を少し後ろに取り、前処理で締めの完了を確認します。

ただし月1回だけの起動には弱点があります。1回止まると、1か月分の点検が丸ごと抜けます。 そこで起動を2本立てにします。

週次のほうが、じつは効きます。 期限前に「今週が期限です」と届けば、督促そのものが発生しません。なお実行の時刻を前提にした処理は書かず、履歴が UTC である点にも注意して台帳には日本時間で記録します。

入力データを集める

規程テーブルを持つことが、この構成の前提条件です。 「出張の仮払は帰着後10日」といった日数を種別ごとに表として持ちます。AIに「一般的には何日くらいか」を聞いて使うことは絶対にしないでください。 精算期限は会社ごとに違い、推測させると規程より厳しい督促や甘い放置が起きます。 段階テーブルも経理部門が先に決めます。退職予定・退職済みの未精算は、段階に関係なく最優先です。

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

仮払金の残高一覧： 会計システムから CSV で出力してスプレッドシートに置きます。月1回と週1回しか動かないので CSV で十分です。重要なのは形式ではなく、仮払番号または補助科目の単位で、誰のどの案件かが分かる粒度で出せるかどうかです。総額しか出せない会計システムでは成立しません。

経費精算の申請一覧： 当月だけでなく過去3か月分を取ります。 当月分だけだと、先月の仮払いを今月精算した人に督促を送ることになります。

規程テーブルと段階テーブル： スプレッドシートに置き、経理部門が見て直せるようにします。ワークフローの中に日数を書き込まないでください。

AIへ渡す前に整形する

1. 表記の正規化 … 社員番号の桁揃え、金額の型、日付の書式を揃えます。CSV出力では金額にカンマや円記号が入り、そのままでは比較できません
2. 突き合わせ … まず仮払番号で1対1に当て、残りを社員番号と出張番号の組で寄せます。出張番号も無い立替経費は発生日の近さと金額で候補を出し、確定させません
3. 金額の照合 … 一致・一部精算・超過（立替えが仮払額を上回った）に分けます。1件の仮払に複数の申請がぶら下がる場合は合計してから比べ（1件ずつ比べるとすべてが金額違いになります）、取り消された出張の仮払いは返金の未処理として分けます
4. 滞留日数の計算 … 規程テーブルの日数で期限日を出し、何日過ぎたかを計算します。この計算はすべて機械で行い、AIに日付の引き算をさせません
5. 段階の判定と保留リストの切り出し … 段階テーブルの境目に当てはめ、「なぜその段階か」（滞留日数と金額）を必ず添えます。 候補止まり、金額違い、取消、同額の別件が同月に2件ある行は督促の対象から外し、人が見る一覧に回します

最後を省かないでください。 同じ社員が同じ月に同額の仮払いを2件受けているとき、機械はどちらが精算済みか判断できません。

AIに処理させる

AIにさせるのは、そろえた材料を、段階に合った日本語の文面にすることだけです。 数を数えること、期限を決めること、段階を判定すること、会計処理を選ぶことはさせません。

段階1は「お知らせ」で、相手を責める言葉を一切入れません。段階4は「お願い」ではなく「現状の共有」に変わります。 上長への同報を段階で切り替えるのも意図的な設計です。段階1と2で同報すると数日の遅れが上長への報告として届き、社内の雰囲気を悪くします。 逆に段階3を過ぎても本人にしか送らないと、手が回らない状態が続きます。同報は、圧力ではなく支援に切り替わる合図です。

AIに任せるのは、文面の組み立て、段階に合わせた調子、種別（前渡しか立替えか）の書き分け、申請手続きの案内、そして段階5の会計処理の候補と根拠の整理です。最後は候補と根拠の一覧であって、結論ではありません。

指示内容を固定する

段階1〜4の督促文を作るプロンプトです。

あなたは経理部の担当者を支援する立場です。社内の同僚あてに、仮払金または
立替経費の精算をお願いする連絡文の下書きを作ってください。
この文面は経理担当者が確認し、承認してから送信されます。

【この連絡の性格】
- 相手は社外の取引先ではなく社内の同僚で、目的は「お金を取り立てること」
  ではなく「精算の手続きを済ませてもらうこと」です。
- 相手は悪意があって放置しているのではなく、忙しくて手が回っていない
  場合がほとんどです。そう読める文面にしてください。

【厳守事項】
- 渡した数値以外の数を本文に書かないでください。金額、仮払日、精算期限日、
  滞留日数は渡した値をそのまま使い、四捨五入も「約」への言い換えもしないこと。
- 精算期限の日数を推測せず、渡した deadline_days と deadline_date
  だけを使ってください。「通常は◯日以内です」と書かないでください。
- 段階（stage）に合った強さで書いてください。強さを自分で変えないでください。
  stage 1 … お知らせ。期限が近いことだけを伝える。督促の言葉を使わない。
  stage 2 … 依頼。いつまでにお願いしたいかを一度だけ書く。
  stage 3 … 依頼と期日の指定。未処理だと何が困るかを一文で添える。
  stage 4 … 現状の共有と、経理から直接相談したい旨。要求を重ねない。
- 相手を責める表現、督促の回数を強調する表現を書かないでください。
- 会計処理（給与からの控除、費用への振替、回収不能としての処理）に
  言及しないでください。stage 4 でも書かないでください。
- 本文で使った数値は、すべて facts_used に
  「項目名・使った値・出どころ」の形で列挙してください。

【未精算の明細】{item}
【種別と精算期限（規程テーブルの値）】{rule}
【段階と、その段階になった理由（滞留日数と金額）】{stage_with_reason}
【申請の手順】{how_to_apply}　【前回までに送った督促の記録】{previous_notices}

「相手は悪意があって放置しているのではない」を明記していることに注目してください。 これを書かないと、督促文はどうしても取り立ての文体に寄ります。社外の売掛金の督促文をそのまま社内に使うと角が立つのは、このためです。

「会計処理に言及しない」も必要です。 段階4の文面に「このままですと給与からの控除を検討することになります」と入ると、それは経理部門としての通告になります。

段階5については、別のプロンプトで候補と根拠の整理だけをさせます。「処理を決めないでください」「〇〇が妥当です と書かないでください」「候補は渡した candidates の中からだけ挙げてください」「根拠が無い候補は根拠なしと明記してください」「人が確認すべき点を open_questions に列挙してください」を厳守事項に置き、明細と経過、候補、社内規程の該当条文を渡します。

加えて「本人の勤務態度、能力、意図についての記述を書かないでください」を必ず入れてください。 長期化した理由を書かせると、AIは「管理がずさん」「意識が低い」といった人物評を書きます。それが社内の記録に残ると、この仕組みは督促の道具ではなく人事評価の道具になります。

出力形式を固定する

督促文の出力は、output_config.format に json_schema を指定します。

{
  "type": "object",
  "properties": {
    "item_id": { "type": "string" },
    "stage":   { "type": "integer", "enum": [1, 2, 3, 4] },
    "kind":    { "type": "string",
                 "enum": ["advance_unsettled", "reimbursement_unfiled", "refund_pending"] },
    "subject": { "type": "string" },
    "body":    { "type": "string" },
    "facts_used": { "type": "array", "items": { "type": "object",
        "properties": { "item": {"type":"string"}, "value": {"type":"string"},
                        "source": {"type":"string"} },
        "required": ["item","value","source"], "additionalProperties": false } },
    "needs_human_attention": { "type": "object",
        "properties": { "flag": {"type":"boolean"}, "reason": {"type":"string"} },
        "required": ["flag","reason"], "additionalProperties": false }
  },
  "required": ["item_id","stage","kind","subject","body","facts_used",
               "needs_human_attention"],
  "additionalProperties": false
}

会計処理の候補は、candidates（候補・根拠・不足している根拠）、open_questions、decision の3項目にし、decision は const で not_made_by_ai に固定します。 これでAIが結論を書き込む場所を構造として塞げます。 stage の enum も同じ理由で、渡した値と違う値が返ってきたら下書きを捨てて再実行します。 facts_used は、本文の数値が台帳のどの値かを1行で照合するための項目です。

システムへ連携する

会計システムへの書き戻しは行いません。 仕訳を自動で起こすと承認の設計がまるごと会計システム側の話になります。

人が確認する

全件、人が承認してから送信します。承認なしで送る設計にしません。 Zapier の Request Approval では、次のように設定します。

最後の2行が、いちばん重要な設定です。 却下時と待ち時間超過時の動作には「そのまま続ける（Skip and continue）」と「終了する（End run）」が選べます。督促の送信では必ず End run を選んでください。 「そのまま続ける」にすると、誰も見ていない督促文が2日後に自動で送信されます。 承認を挟んだ意味がなくなります。

承認者の編集を許可すれば、承認の画面の中で文面を直せます。 承認されると Decision に approved が入り、後続はこれで分岐します。承認のときに見るのは3点です。

• facts_used の金額と日数が台帳の値と合っているか（本文の数字を1つずつ追わない）
• 段階と文面の強さが合っているか（段階1に督促の言葉が混ざっていないか）
• この相手に、この文面を送ってよいか（休職中、異動直後、すでに個別に話している）

3つ目は機械にできません。社内の事情を知っている人だけが判断できる部分で、ここに時間を使えるようにするのが目的です。

例外に対処する

最後の行を仕組みで持ってください。 プロンプトの制約は必ずすり抜けます。本文から数値を機械で拾い、facts_used と突き合わせるだけの処理で防げます。

記録を残す

• 点検した対象の一覧（精算済み・未精算・保留の件数）と、突き合わせに使ったキー
• 規程テーブルと段階テーブルの、その時点の中身
• AIに渡した材料と、返ってきた下書き、facts_used
• 承認したか却下したか、誰が、いつ。却下したなら理由と、直した箇所
• 送信した日時と宛先・同報先、そして精算された日付

2つ目を残す理由は、あとで必ず聞かれるからです。 「なぜ先月は督促が来なくて、今月は上長にも来たのか」に、そのときの段階テーブルが無いと答えられません。 最後の行は効き目を示す数字で、何日で精算されたかを段階ごとに見ればどの段階の文面が効いているかが分かります。