複数の銀行口座の入出金を毎日集めて、口座間の資金移動の指示案まで作る

処理の起点を決める

毎営業日の決まった時刻（朝8時）を起点にします。Google Apps Script の時間主導型トリガーは、1分おきから月1回までの間隔でスクリプトを実行できます。日次の実行はこの範囲に収まります。

営業日の判定を必ず入れてください。 土日祝に実行すると、前営業日の明細を重複して取り込むことになります。祝日は年によって変わるため、カレンダーのシートを持つか、カレンダーサービスを参照します。

入金が午後に反映される銀行があるため、朝だけでなく午後にもう一度実行する構成も考えられます。 ただし最初は朝1回で始め、必要が出てから増やしてください。

入力データを集める

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

入出金明細： 銀行によって取得方法が違います。3通りを想定します。

すべての口座をAPIにする必要はありません。 残高の大きい主要口座だけAPIにして、残りはファイル取り込みでも、この構成は成立します。利用可否と費用は銀行ごとに異なるため、個別に確認してください。

取引先マスタ： 振込名義（半角カナ）の列を持たせることが要です。「ｶ)ﾏﾙﾏﾙｼｮｳｼﾞ」と「株式会社マルマル商事」を結びつける表がないと、AIも判別できません。この列は最初は空でも構いません。 運用しながら、判別できなかった明細を人が確定するたびに追記していきます。

支払予定： 会計システムから日次でエクスポートします。手形の期日、口座振替の引落日、給与、税金・社会保険料を漏らさないでください。 月末に集中するこれらを見落とすと、過不足の計算が意味をなしません。

AIへ渡す前に整形する

1. 明細の正規化 … 銀行ごとに違うCSVの列を、共通の形（日付／口座／入出金／金額／摘要）に直します
2. 重複の除去 … 同じ明細を2回取り込まないよう、「口座＋日付＋金額＋摘要」で既存データと照合します
3. 半角カナの正規化 … 摘要の半角カナを全角に直し、記号（( ) . など）を統一します。この処理だけで、機械的に一致する明細が大きく増えます
4. 機械的に一致するものの先行処理 … 取引先マスタの振込名義と完全一致する明細は、AIを通さずに確定します。全明細をAIに渡す必要はありません。 費用も処理時間も減ります

AIに処理させる

前処理で機械的に一致しなかった明細だけをAIへ渡します。月1,800明細のうち、実際に渡るのは2〜3割程度のはずです。

金額の計算はAIにさせません。 過不足の計算、合算の検算はすべて表計算側で行います。AIにさせるのは「この明細は何か」という区分づけだけです。

指示内容を固定する

あなたは財務部の資金担当を支援する担当者です。
銀行の入出金明細の摘要から、相手先と取引区分を判別してください。

【厳守事項】
- 金額、日付、口座番号を書き換えないでください。明細の値をそのまま引き継いでください。
- 相手先は、下の取引先マスタにあるものからのみ選んでください。
  マスタに候補がない場合は counterparty_code を null にし、
  reason に摘要のどの部分が手がかりになったかを書いてください。
  **新しい取引先を作らないでください。**
- 取引区分は、下の区分一覧からのみ選んでください。判断できない場合は「その他」にし、
  confidence を low にしてください。
- 消込候補は、下の売掛金一覧に存在する請求からのみ挙げてください。
  金額が一致しない場合でも、合算・分割の可能性があれば候補として挙げ、
  match_type に「合算」「分割」と書いてください。
- 金額の計算をしないでください。合計や差額を出さないでください。
- 推測で取引の内容を補わないでください。摘要に書かれた文字だけを手がかりにしてください。

【取引区分の一覧】
売掛回収 / 仕入支払 / 経費 / 口座間振替 / 利息・手数料 / 税金・社会保険 / 給与 / その他

【判別する明細】
{transactions}

【取引先マスタ（正式名称 / 振込名義 / コード）】
{counterparty_master}

【売掛金一覧（未消込・相手先と金額が近いもの）】
{receivables}

「新しい取引先を作らない」の1行が重要です。 これを書かないと、AIは摘要をそのまま取引先名として返します。存在しない取引先コードが台帳に入ると、後の集計がすべて狂います。

出力形式を固定する

{
  "transaction_id": "",
  "account_code": "",
  "value_date": "",
  "direction": "in | out",
  "amount": 0,
  "raw_description": "",
  "counterparty_code": "",
  "counterparty_name": "",
  "category": "売掛回収 | 仕入支払 | 経費 | 口座間振替 | 利息・手数料 | 税金・社会保険 | 給与 | その他",
  "matched_receivables": [
    { "invoice_no": "", "amount": 0, "match_type": "完全一致 | 合算 | 分割" }
  ],
  "confidence": "high | medium | low",
  "needs_review": [],
  "reason": ""
}

JSON Schema を指定して出力を固定します。Claude API では output_config.format に json_schema を渡すことで、応答をスキーマに沿った形に制約できます。

金額は数値で受け取り、AIが返した値と元の明細の値が一致するかを機械で検算してください。 書き換えないよう指示していても、検算は必ず入れます。一致しなければその明細を破棄して人へ回します。

システムへ連携する

判別結果と口座残高から、資金ポジション表をスプレッドシートに作ります。Apps Script は SpreadsheetApp でシートの範囲を読み書きできるため、行の追記と書式の設定はスクリプト内で完結します。

表の構成は次のとおりです。

資金移動の案は「案」として出すだけです。 振替の実行データを作ったり、インターネットバンキングへ送ったりはしません。

消込候補は、会計システムへ自動反映しません。入金消込の確定は、別の業務として人が行う前提です。 ここではあくまで「この入金はこの請求らしい」という情報を、資金担当が相手先を特定するための手がかりとして使います。

人が確認する

資金移動は、全件、人が決めます。承認も人が行います。

理由は、金銭の移動を伴うためです。この構成で減らしているのは「集めて読んで計算する時間」であって、「いくら動かすかを決める責任」ではありません。

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

• 口座別サマリーを、差引後残高が少ない順に並べる
• 最低維持残高を下回る口座を赤で表示する
• 当座貸越の枠に入る見込みの口座を最上部に出す
• confidence が low の明細の件数を、サマリーの先頭に出す（多い日は過不足の計算自体が怪しい）
• 前日に人が確定した相手先を、取引先マスタへ追記する導線を作る

最後の項目が、運用の質を決めます。判別できなかった明細を人が確定するたびにマスタが育ち、翌月以降の判別率が上がります。 この仕組みを入れないと、いつまでも同じ明細で迷います。

例外に対処する

記録を残す

この業務のログは、資金の動きの説明責任に直結します。

• 取り込んだ明細の原本（銀行から取得したファイルまたはAPIの応答）
• 判別結果（相手先、区分、confidence）
• 人が修正した相手先・区分と、修正前後の値
• 資金ポジション表の日次スナップショット
• 資金移動の案と、実際に実行した内容の差
• 承認者、承認日時

「案と実際の差」を残すことに意味があります。 案のとおりに動かさなかった日が続くなら、案の作り方に前提の抜けがあります。

日次スナップショットは、後から「その日、なぜその判断をしたか」を再現する材料になります。月次で圧縮して保管しても構いません。