前払費用と未払費用の計上漏れを、契約と支払データから毎月洗い出す

処理の起点を決める

毎月の締めが終わった翌営業日の朝を起点にします。支払明細が確定していない状態で走らせると、月の後半の支払が入っていない一覧ができあがり、翌月にもう一度同じ契約を見ることになります。

Make のシナリオのスケジュールで「Monthly」を選び、実行する日と時刻を指定します。既定では15分ごとに実行される設定になっているため、必ず変更してください。 月次の処理が15分おきに走ると、同じ契約書を何度もAPIへ送ることになります。

シナリオを有効化しないと動きません。 公式のヘルプでは、停止しているシナリオは手動で起動しない限り実行されないと説明されています。作っただけで安心して、1か月後に何も出ていないことに気づく、という取りこぼしが起きやすい部分です。「show advanced settings」で開始日と終了日を指定できるので、試験運用の期間を区切るときはここを使います。

2つ目の起点として、契約書のフォルダに新しいPDFが入ったときを置きます。最初の支払が起きる前に期間を読み取っておけば、初回の支払のときには既に期間が分かっています。3つ目として、期末月に、期首からの全契約を対象に走らせる経路を用意します。

入力データを集める

しきい値表を入力データとして持つことが、この構成の要です。 表の形は次のようにします。この数値は例であり、自社で決まっている基準に置き換えてください。

しきい値が決まっていない場合は、この仕組みを作る前に経理と会計士で決めてください。 決めずに始めると、AIか担当者のどちらかがその場で判断することになり、月ごとに扱いが変わります。

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

支払明細： 会計システムにAPIがあれば前月分を日付で絞って取得し、APIが無い製品では月次で出力するCSVを共有フォルダに置いて Make のシナリオで読みます。どちらの場合も、取得する期間を「前月1日から前月末日まで」と固定してください。 締めのやり直しで支払日が動くことがあるため、実行のたびに前月分を取り直す作りにします。

発注データ： 購買システムから、契約番号を持つ発注を取得します。支払明細と契約書をつなぐ鍵が、発注番号であることが多いためです。

契約書PDF： 法務のファイルサーバーから、契約番号のフォルダ単位で取得します。契約番号でフォルダが切られていない環境では、まずそこを整えるほうが先です。 ファイル名だけで本体契約と覚書を見分けるのは、どの会社でも失敗します。

取得したPDFは Gemini API へ渡します。公式のドキュメントでは、PDF以外にも、TXT、Markdown、HTML、XML などは文字として扱えるが、図やレイアウトは失われると説明されています。契約書がWordのまま保管されている場合は、PDFに書き出してから渡します。

契約台帳： 法務が契約台帳を持っていない場合は、契約番号と取引先と解約の有無だけの表を経理が作ります。解約したかどうかは契約書には書かれていないため、この列だけは人が更新します。

AIへ渡す前に整形する

1. 継続的な支払の候補を絞る … 勘定科目（賃借料、保険料、支払手数料、通信費など）、摘要に含まれる語（保守、ライセンス、利用料、年会費、顧問料、賃料）、同じ取引先への支払が過去12か月で3回以上あること、の3つで絞ります
2. 取引先名をそろえる … 「株式会社」の前後、全角と半角、カッコの種類、英字の大文字小文字をそろえます。表示用には元の文字列を残します
3. 契約書を引き当てる … 契約番号があればそれで、無ければ発注番号から、それも無ければ取引先名で候補を出します。候補が複数あるときは、AIに選ばせず、全部を1回のリクエストに添えて「どれを見たか」を返させます
4. ファイルの大きさを確かめる … 50MBまたは1,000ページを超えるファイルはそのままでは渡せません。契約書本体と別紙を分け、期間と支払条件が書かれた部分だけを渡します
5. 前月の計上一覧と照合する … 同じ契約番号と同じ対象期間の計上が既にあれば、AIへ渡さずに「計上済み」として分けます
6. しきい値の前さばき … 支払額そのものが1件あたりのしきい値を大きく下回る支払は、按分すればさらに小さくなります。この段階でAIへ渡さないことで、読み取りの回数を減らせます

5番目と6番目で、AIへ渡す件数が大きく減ります。 契約書を読み直す必要があるのは、新しい契約と、期間が今月で切り替わる契約と、初めて出てきた取引先の分だけです。前月と同じ契約の同じ周期の支払は、読み取りの結果を使い回せます。

AIに処理させる

機械（Python）にさせること：

生成AI（Gemini API）にさせること：

金額の計算は一切させません。 AIが返すのは、契約書に書かれている金額の文字列（「月額金330,000円（税込）」など）をそのまま写したものだけです。その文字列から数値を取り出すのも、按分するのも、機械が行います。

重要性の判断もさせません。 「この金額は少額だから計上不要」という文をAIが書くと、一覧の中で根拠が2種類混ざります。しきい値表を当てた結果だけが、対象外の理由になる作りにします。

仕訳も書かせません。 それらしい仕訳が並んでいると、経理はそれを確認する側に回ってしまい、自分で判断する場面が減ります。

指示内容を固定する

あなたは契約書から、会計処理に必要な期間の情報を読み取る担当者です。
下の契約書から、役務の提供を受ける期間と、代金を支払うタイミングを読み取ってください。

【厳守事項】
- 金額の計算をしないでください。按分、日割り、月割り、合計のいずれも行いません。
  金額は契約書に書かれている文字列をそのまま period_amount_text に写してください。
- 読み取った項目には必ず、根拠になった条番号と、その条文の原文を evidence に入れてください。
  原文は契約書から一字一句そのまま写し、要約や言い換えをしないでください。
- 契約書に書かれていない期間や日付を推測しないでください。
  書かれていなければ、その項目を null にし、unknown_reason に理由を書いてください。
- 「重要かどうか」「計上すべきかどうか」を判断しないでください。
- 仕訳、勘定科目、借方・貸方、税区分を書かないでください。
- 契約期間と、役務の提供期間が違う場合は、両方を返してください。
  例：契約の有効期間は4月1日からだが、保守の開始は検収日の翌日から、など。
- 自動更新の条項があれば auto_renewal に、予告の期限と更新後の期間を入れてください。
  更新後の具体的な日付を計算しないでください。条文の定めをそのまま写します。
- 中途解約の条項があれば mid_term_termination に、予告期間と、
  既に支払った分の精算についての定めを入れてください。
- 覚書、変更契約、注文請書が一緒に与えられている場合は、日付の新しいものを優先し、
  どのファイルのどの条項を見たかを amendments に書いてください。
- 与えられたファイルのうち、この契約に関係しないものは used_files から外し、
  その理由を書いてください。

【読み取る項目】
service_period_start / service_period_end ... 役務の提供を受ける期間
period_basis ... その期間が契約書のどの記述から決まるか（日付が直接書かれている、
                 検収日を起点とする、初回支払日を起点とする、など）
contract_period_start / contract_period_end ... 契約そのものの有効期間
payment_timing ... 前払 / 後払 / 都度 / 不明
payment_cycle ... 一括 / 月次 / 四半期 / 半期 / 年次 / 不定
payment_due ... 支払期日の定め（「請求書受領後30日以内」など、書かれたまま）
period_amount_text ... 期間に対応する金額の記載（文字列のまま。計算しない）
auto_renewal ... 自動更新の有無、予告の期限、更新後の期間の定め
mid_term_termination ... 中途解約の予告期間、既払分の精算の定め
evidence ... 上の各項目の根拠（条番号と原文）

【契約の情報】
契約番号：{contract_id} ／ 取引先：{vendor_name} ／ 与えたファイル：{file_list}

【この契約に紐づく支払明細】
{payment_rows}

支払明細は、契約書のどの条項に対応する支払かを見分けるためだけに使ってください。
支払明細の金額から期間を逆算しないでください。

「金額の計算をしないでください」を先頭に置いています。 契約書と支払明細を一緒に渡すと、指示が無ければ按分額まで書いてきます。

「原文を一字一句そのまま写す」が、確認を速くする部分です。 引用が契約書のテキストと一致するかは、後段の処理で機械的に確かめられます。一致しない引用は、契約書に無い文である可能性が高いので、一覧に出す前に「要確認」へ回します。

「更新後の具体的な日付を計算しないでください」も必要です。 自動更新の契約で「更新後の期間は2027年4月1日から」と日付を書かれると、それが契約書に書かれた日付なのか、AIが1年足した日付なのかが区別できません。開始日に期間を足す計算は機械が行います。

「関係しないファイルを外す理由を書かせる」は、引き当てが外れたときに効きます。 取引先名だけで候補を出すと別の案件の契約書が混ざり、AIがそれを無理に使うと、まったく別の期間が読み取られます。

出力形式を固定する

{
  "contract_id": "",
  "vendor_name": "",
  "used_files": [],
  "service_period_start": "2026-04-01",
  "service_period_end": "2027-03-31",
  "period_basis": "",
  "contract_period_start": "2026-04-01",
  "contract_period_end": "2027-03-31",
  "payment_timing": "前払 | 後払 | 都度 | 不明",
  "payment_cycle": "一括 | 月次 | 四半期 | 半期 | 年次 | 不定",
  "payment_due": "",
  "period_amount_text": "",
  "auto_renewal": {
    "exists": true,
    "notice_deadline": "",
    "renewed_term": ""
  },
  "mid_term_termination": {
    "exists": true,
    "notice_period": "",
    "refund_treatment": ""
  },
  "amendments": [],
  "evidence": [
    { "field": "service_period_start", "article": "第3条第1項", "quote": "" }
  ],
  "unknown_reason": null
}

Gemini API では、response_format に type と mime_type と schema を渡すことで、応答をJSONスキーマに沿った形にできます。公式のドキュメントには次の形が示されています。

"response_format": {
  "type": "text",
  "mime_type": "application/json",
  "schema": {
    "type": "object",
    "properties": { },
    "required": [ ]
  }
}

スキーマで使える型は string number integer boolean object array null です。payment_timing と payment_cycle は enum で固定します。 日付の項目は format に date を指定できます。ただし、すべてのJSONスキーマの機能が使えるわけではなく、非常に大きい、あるいは深く入れ子になったスキーマは拒否されることがあると明記されています。項目は上の程度に収めます。

evidence を必須項目にしてください。 ここが空で返ってくる読み取りは根拠を示せていないので、そのまま「要確認」へ回します。経理が見るのは、この条番号と原文です。

unknown_reason も必要です。 これが無いと、期間が書かれていない契約書でも、それらしい日付が入ってきます。「検収日を起点とすると書かれているが、検収日が契約書に無い」という申告が返るほうが、確認は速くなります。

システムへ連携する

読み取りと計算の結果を、3つの一覧に分けて書き出します。

一覧1：計上候補

一覧2：契約書の見つからない支払

支払はあるが、契約書を引き当てられなかったものです。部署がカードで契約したサブスクリプションが、ここに集まります。 取引先名、金額、摘要、過去12か月の支払回数を並べ、部門コードから推定した担当部署を添えます。

一覧3：支払の無い契約

契約台帳にあるが、今月の支払明細に出てこなかった契約です。後払の契約で請求書がまだ届いていない場合、未払費用の候補になります。 前回の支払日、支払周期、次に来るはずだった支払日、経過している日数を並べます。

一覧3は、Before では構造的に作れなかったものです。 支払明細を起点にしている限り、支払が起きていない契約は視界に入りません。契約の側から見に行く経路を作ることが、未払費用の漏れを減らす部分です。

会計システムへは書き戻しません。 この仕組みが持つのは、支払明細と契約書と契約台帳への読み取り権限だけです。通知は、一覧が更新された時点で経理のチャットへ1通だけ送り、3つの一覧の件数とリンクだけにします。1件ずつ通知すると、月初に180件の通知が届きます。

人が確認する

全件を経理が確認します。 経過勘定の計上は金額が確定する処理なので、AIの読み取りをそのまま使う場面はありません。確認するのは「AIが読み取った期間が正しいか」だけです。 按分額は機械の計算なので、計算式が正しければ全件で正しくなります。

確認の深さを分けます。

• 前月と同じ契約・同じ周期・同じ金額 … 差額が0であることを見るだけ。ここが件数の大半を占めます
• 新しく出てきた契約 … 条番号と原文を読み、契約書を開いて確かめる
• 期間が今月で切り替わる契約 … 更新されたのか、終わったのかを確かめる
• unknown_reason が入っているもの … 契約書を開く。期間が書かれていない契約は、法務か担当部署に確認する
• 引用が契約書のテキストと一致しなかったもの … 契約書を開く
• 中途解約・変更のあった契約 … 覚書を確かめる。按分の起点が変わります

確認を速くするための設計が効きます。

• 条番号と原文を、一覧の行の中に直接表示する（別のシートに飛ばさない）
• 契約書のファイルへのリンクを、同じ行に置く
• 前月の計上額との差額を、金額の隣に置く
• 前月「計上しない」とした契約には、その理由を表示する
• 前月と同じ内容の行を、折りたたんで表示する

4番目が効きます。 「この年会費は毎年、重要性の観点から計上していない」という判断は、毎月同じ行に出てきます。理由が見えていれば、開くのは新しい行だけになります。

例外に対処する

記録を残す

この記録は、翌月と来期の作業を軽くする材料になります。

• 月ごとの対象件数、AIへ渡した件数、読み取りが成功した件数
• 契約ごとの読み取り結果（期間、支払のタイミング、条番号と原文）と、読み取った日
• 経理の判断（計上する／しない／要確認）と、その理由
• unknown_reason の内容と、その後どう解決したか。引用が契約書と一致しなかった件数
• 契約書の見つからない支払の件数と、その後の契約書の回収状況
• 支払の無い契約の件数と、そのうち未払費用として計上したもの

読み取り結果を契約番号ごとに残しておくことが、いちばん効きます。 契約書のファイルの更新日時を見て、変わっていない契約は保存した結果を使う作りにすれば、同じ契約書を毎月読み直さずに済みます。

「契約書の見つからない支払」の件数の推移も見てください。 減らないなら、部署がカードで契約したサブスクリプションが、契約書を法務へ渡さずに増え続けているということです。点検で拾うより、契約の手続きを変えるほうが安く済みます。

経理の判断の理由も必ず残してください。 「重要性の観点から計上しない」とした契約が、来期に金額が上がって基準を超えることがあります。理由が残っていれば、しきい値表を見直す根拠になります。