財務部が各銀行の口座の残高の報告をスプレッドシートに集め、Apps Script で残高の偏りと支払の予定から資金の振替の案を作る

処理の起点を決める

火曜と金曜の朝の時間主導のトリガーで動かします。 公式のページでは、時間主導のトリガーは指定した時間帯の中で実行の時刻が選ばれ、9時に設定すると9時から10時のあいだのどこかで動くとされています。財務の担当がCSVを置くのが8時半ごろなので、トリガーは9時台に置き、10時に案がそろう流れにします。

CSVが置かれていなければ、処理を進めません。 15本のうち1本でも残高が取り込めていなければ、その日の見込みは作らず、足りない口座を財務の担当に知らせて終わります。 一部の口座だけで案を作ると、足りない口座の分を見ないまま振替の額が決まります。

手動でもう一度動かせるようにしておきます。 CSVを置き直したときや、急ぎの支払が入ったときは、財務の担当がスプレッドシートのメニューから同じ処理を呼びます。インストール型トリガーは作った人のアカウントで動くと公式のページにあるので、財務部の共有のアカウントで作ります。

入力データを集める

判定の質を決めるのは、取り決めの表です。 「返済口座」「月末注意」のような短いメモでは、AIも人も判断できません。「借入の返済口座。返済日の前営業日の終わりに、返済額の110％以上を置く（借入の契約の条件ではなく社内の取り決め）」のように、何を、いつまでに、なぜ、を1行に書きます。 書いた人と日付を付けておくと、古い取り決めを見分けられます。

支払の予定の「確定か未確定か」の列は、この構成のために足します。 税金や社会保険料のように金額が後から決まるものは、前回の実績で仮の額を入れ、未確定の印を付けておきます。 AIはこの印と備考を見て、案の判定に反映します。

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

CSVの形式は銀行ごとに違います。 見出しの行の数、残高の列の位置、日付の書き方、文字コードが違うので、銀行ごとの形式の表に「何行目から」「何列目が残高」「日付の形」を書き、スクリプトはその表に従って読みます。 公式のページでは、Utilities.parseCsv は CSV の文字列を2次元の配列にし、区切りの文字も指定できるとされています。

基準の日時を必ず取ります。 前日の夜に書き出したCSVを朝に置き忘れたまま使うと、夜間の引落の前の残高で見込みを作ることになります。 基準の日時が当日の朝より前なら、その口座は取り込まずに知らせます。

AIへ渡す前に整形する

1. 口座の突き合わせ … CSVの口座番号の下4桁と銀行・支店で、口座の設定の表の口座に結び付けます。結び付かない行は取り込みません
2. 残高の検算 … 前回の残高と今回の残高の差が、前回からの支払の予定の合計と大きく違えば、印を付けます
3. 営業日の計算 … 社内の休日の表を使い、10営業日の日付の列を作ります。支払の予定日が休日なら、規則で前の営業日か後の営業日に寄せ、どちらに寄せたかを記録します
4. 見込みの計算 … 口座ごとに、日ごとの残高の見込みを出します
5. 不足と余りの計算 … 見込みの最も低い日の残高と最低残高、最も高い日の残高と上限の目安を比べます
6. 振替の案の作成 … 余りのある口座から不足のある口座へ、同じ銀行の中の振替を優先し、額は万円単位で切り上げて案を作ります

6番目までをすべて規則で行うのが、この設計の要です。 額と日付は計算で決まり、AIに渡すのは「計算が終わった案」です。 AIの判定がどう出ても、案の額そのものは変わりません。

6番目の振替の案は、次の順の規則で作ります。

2番目で同じ銀行の中を優先するのは、手数料と実行の手間が少ないからです。 どの組み合わせで手数料がかかるかは、口座の設定の表の手数料の区分で持ちます。

3番目の休日の寄せ方は、支払の種類ごとに決めておきます。 引落は銀行の規則で後ろの営業日になることが多い一方、振込は前の営業日に前倒しする運用の会社が多いので、寄せ方を種類の列で持ちます。迷う種類は前に寄せて、不足を早めに見るようにします。

AIに処理させる

させるのは、規則が作った振替の案の1本ずつについて、口座ごとの取り決めと支払の予定の備考に照らして、採れるかどうかを判定し、根拠の文を書き出すことだけです。

判定の対象には、案に含まれない口座も入れます。 規則で不足も余りも無いと出た口座でも、取り決めの文面に「今月は増資の払込に使う」とあれば、その口座は動かしてはいけないかもしれません。 案に出ていない口座について、取り決めから気をつけることがあれば account_notes に書かせます。

1行目がいちばん起きやすい失敗です。 案と取り決めが食い違うと、モデルは「120万円ではなく80万円にすれば取り決めに合います」と額を直そうとします。額を直すのは財務の担当で、AIには食い違いの事実と根拠だけを書かせます。

指示内容を固定する

あなたは財務部で、資金の振替の案を口座ごとの取り決めに照らして
点検する担当です。渡された「振替の案」「口座ごとの見込み」
「取り決め」「支払の予定の備考」だけを根拠にしてください。

【判定すること】
1. proposals：振替の案の1本ずつについて、verdict を
   ok ／ conflict ／ needs_info のいずれかにする。
   - ok：取り決めと備考に食い違いが無い
   - conflict：取り決めの文面と食い違う
   - needs_info：判定に要る情報が足りない（金額未確定、日付の不明など）
2. reason：判定の理由を2文以内で書く。
3. evidence：根拠にした取り決めの番号と文面、または備考の文を、そのまま写す。
4. account_notes：案に含まれない口座でも、取り決めから気をつけることがあれば書く。

【厳守事項】
- 振替の額を変えたり、別の額を提案したりしないでください。
- 新しい振替の案を作らないでください。
- 取り決めに書かれていないことを、推測で補わないでください。
- 銀行との契約や借入の契約の中身を推測しないでください。
  取り決めの表に書かれた範囲だけを根拠にしてください。
- 取り決めの書いた日付が古く、いまの支払の予定と合わないと思われる場合は、
  needs_info にし、reason にその旨を書いてください。
- 承認してよい、実行してよいとは書かないでください。

【基準日】{as_of}
【振替の案】{proposals}
【口座ごとの見込み（10営業日）】{forecast}
【取り決め】{rules_text}
【支払の予定の備考（未確定の印付き）】{payment_notes}

「額を変えない」を最初の厳守事項にしているのは、前の表の1行目のためです。 何も言わなければ、モデルは食い違いを見つけると親切に額を直します。直された額は誰も検算していない数字です。

取り決めの日付が古い場合を needs_info にするのは、担当者が替わって取り決めが残ったままのことがあるからです。 3年前の担当者のメモに従って資金を動かすより、いまの担当が取り決めを書き直すほうが先です。

指示は、Interactions API の system_instruction に置きます。 公式のページでは、system_instruction はその Interaction だけに効くとされているので、呼ぶたびに同じ指示を渡します。 取り決めや備考は入力の側に置き、指示と分けます。

出力形式を固定する

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

{
  "as_of": "2026-11-03",
  "proposals": [
    {
      "proposal_id": "P-01",
      "verdict": "ok | conflict | needs_info",
      "reason": "",
      "evidence": [
        { "source": "rule | payment_note", "ref": "R-07", "quote": "" }
      ]
    }
  ],
  "account_notes": [
    { "account_id": "", "note": "", "ref": "" }
  ]
}

1つ目の理由は、規則の層と判定の層を分けられることです。 振替の案の表には、規則が書いた額・振替の元・振替の先の列と、AIが書いた verdict・reason・evidence の列が並びます。AIの出力に額の欄が無いので、AIが額を変える余地がありません。

2つ目の理由は、スキーマで判定の値を縛れることです。 verdict を enum にしておけば、3つ以外の値は返りません。公式のページでは、enum・required・minItems・maxItems が使える一方、minLength・maxLength はエラーにならずに外されるとされています。reason の長さはスキーマで縛れないので、受け取ったあとに Apps Script で字数を数え、長すぎれば確認の印を付けます。

3つ目は、evidence の ref で取り決めの表に戻れることです。 財務の担当は、conflict の案を見たときに取り決めの番号から原文を開き、AIの読み方が正しいかを数秒で確かめられます。

振替の案の表は、次の形に並べます。

システムへ連携する

Gemini API の呼び出しは、muteHttpExceptions を有効にして、応答の番号を見ます。 公式のページでは、muteHttpExceptions を有効にすると失敗の応答でも例外を投げないとされています。エラーのときは案を判定なしで表に書き、「判定なし」の印を付けて知らせます。 判定が無くても、規則の案は財務の担当が従来どおり確かめられます。

インターネットバンキングにも会計の仕組みにも書き込みません。 この構成が書くのはスプレッドシートの案の表だけで、振替の実行と会計への計上は人の手で、従来の手順のまま行います。

人が確認する

財務の担当が見るのは、conflict と needs_info の案と、account_notes です。 ok の案は一覧で流し見ます。

1. CSVの取り込みの漏れを先に見る … 足りない口座があれば、その日の案は出ていません
2. conflict の根拠を開く … 取り決めの原文を読み、AIの読み方が正しければ額を直すか案を外します。正しくなければ、取り決めの文面を直す候補として記録します
3. needs_info の情報を埋める … 未確定の支払の額を経理に確かめ、支払の予定の表を直して、もう一度処理を呼びます
4. account_notes を読む … 案に出ていない口座の注意を見て、必要なら手で案を足します
5. 財務部長に承認を依頼する … 直した額と理由を表に残したまま依頼します

2番目でAIの判定に従って額を直すときも、直すのは人です。 直した額は表の「直した額」の列に書き、規則が出した額を上書きしません。 後から、規則の額とAIの判定と人の判断を並べて振り返れるようにします。

例外に対処する

1行目で一部の口座だけで案を作らないのは、第7章のトリガーのとおりです。 足りない1口座が、ちょうど不足の口座だったときに、その日の判断がまるごと外れます。

公式のページでは、スクリプトの1回の実行は6分までとされています。 15口座と10営業日の計算に、1回の API の呼び出しを足すだけなので、この時間に収まります。口座が増えて時間がかかるようになったら、残高の取り込みと案の作成を別の実行に分けます。

記録を残す

• 取り込んだCSVのファイルと、取り込んだ日時・基準の日時
• 日ごとの残高の見込みと、計算に使った口座の設定の表の版
• 規則が作った振替の案と、AIに渡した内容・返した JSON の全文
• 財務の担当が額を直した記録 … どの案を、いくらからいくらに、なぜ
• 財務部長の承認の日時と、実行した担当・実行の日時
• 取り決めの表を直した記録（誰が、いつ、どの文面を）

4つ目と6つ目は、取り決めを育てる材料になります。 同じ口座で同じ直しが続くなら、その口座の最低残高の数値か、取り決めの文面が実態に合っていません。 数値なら設定の表を、文面なら取り決めの表を直します。