子会社から毎月届く資金繰り表を点検し、残高の不一致・前月の見込みとの大きな差・資金ショートの懸念を洗い出して照会文の案を作る

処理の起点を決める

1時間ごとに動く時間主導型のトリガーを起点にします。 ScriptApp.newTrigger() に timeBased()・everyHours(1) を続けて作ります。動くたびに共有のフォルダの資金繰り表を見て、提出の欄に印があり、点検の一覧にまだ載っていないものを拾います。

子会社のファイルの編集をきっかけにしないのは、子会社が記入の途中で何度も保存するためです。 編集のたびに点検すると、書きかけの数字で照会文の案ができてしまいます。提出の印を、子会社の経理が「出しました」と言う合図にします。

提出のあとに子会社が数字を直すこともあります。 そこで、点検の一覧には点検したときのファイルの最終更新の日時を書き、次に見たときに更新されていれば「提出後に更新あり」として点検し直します。

提出期限の翌朝には、別のトリガーで未提出の会社を担当者に知らせます。 onMonthDay() は日付の指定なので、第5営業日のような営業日の指定には使えません。毎朝動くトリガーにして、スクリプトの中で営業日の一覧と照らします。

入力データを集める

質を決めるのは、会社ごとの基準です。 月の入出金が数千万円の会社と数十億円の会社で、同じ金額の基準を使うと、小さい会社は何でも拾い、大きい会社は何も拾いません。 そこで、差を拾う基準を金額と率の両方で持ち、どちらも超えたものだけを拾います。

最低の残高も、会社ごとに決めます。 「月の支出の1か月分」のような決め方が多いですが、季節で支出が大きく変わる会社や、親会社からの借入で回している会社は別の決め方になります。 財務部が会社ごとに決めて、シートに書きます。

前月の版は、点検のたびに写しを残します。 子会社のファイルは毎月上書きされるので、前月に出された見込みは、写しを取っておかないと消えます。 第3章の（c）が起きていた理由の1つです。

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

書式が統一されているので、読む範囲は固定できます。 ただし、子会社が行を足したり消したりすると、範囲がずれます。 読む前に、科目の名前の列が決まった並びになっているかを確かめ、ずれていれば点検せずに担当者に知らせます。

1社ごとの処理は、次の順で行います。

1. 科目の名前の列が決まった並びかを確かめる（ずれていれば「書式の崩れ」で止める）
2. 数字の点検をする
   C1 期首の残高 ＝ 前月の写しの期末の残高
   C2 各月の 期首＋収入計−支出計 ＝ 期末
   C3 収入計・支出計 ＝ 科目の合計
   C4 当月の期末の残高 ＝ 口座の残高の合計
   C5 当月の実績と、前月の写しの当月の見込みの差（科目ごと）
   C6 先3か月の見込みの期末の残高と、最低の残高
3. C5 で基準を超えた科目と C6 で下回った月を、差の一覧にする
4. 差の一覧が空なら、AI を呼ばずに「差なし」と書いて終わる
5. 差の一覧と、その行のコメント、過去の照会を Gemini API に渡す
6. 返ってきた JSON の値を確かめる（差のキーが渡したものと一致するか）
7. 点検の一覧に書き、当月の版の写しを残す

C1 から C4 で合わないものは、AI に渡しません。 計算が合わないのは、説明の問題ではなく記入の誤りだからです。そのまま「計算の不一致」として担当者に回します。

Gemini API は UrlFetchApp で呼びます。 API キーはスクリプトのプロパティに置きます。公式の割り当てでは、URL Fetch の呼び出しは一般のアカウントで1日2万回、Google Workspace のアカウントで1日10万回で、月に30回ほどの呼び出しには十分です。1回の実行は6分までなので、1時間ごとの実行で一度に点検する会社の数に上限を置きます。

AIへ渡す前に整形する

1. 通貨をそろえない … 海外子会社の資金繰り表は現地の通貨のまま点検します。換算すると、為替の動きが差として拾われます
2. 差の金額と率を添える … C5 の差は、スクリプトが計算した金額と率を渡します。AI に計算させません
3. コメントが空の行も渡す … 差があってコメントが空なら、それ自体が判定の材料です
4. 過去の照会を添える … 同じ科目を過去3か月に照会していれば、その回答の要旨を渡します
5. 会社の規模を添える … 月の支出の平均を渡し、差の大きさの目安にします
6. 取引先の名前は渡す範囲を決める … コメントに書かれた得意先の名前はそのまま渡すか、記号に置き換えるかを、第13章の取り決めで決めます

4番目は、第3章の（c）への手当てです。 3か月続けて同じ科目の見込みが外れていれば、今月のコメントが丁寧でも、照会の理由になります。 過去の照会を渡さなければ、AI は毎月を初めてのものとして見ます。

AIに処理させる

させるのは、スクリプトが拾った差の1つずつについて、子会社のコメントで説明が足りているかを判定し、足りていなければ聞くことを書くことです。

inconsistent が、この構成で最も見つけたいものです。 コメントの言葉が丁寧でも、差の向きと合っていなければ、記入の誤りか、説明が実態と違うかのどちらかです。 担当者が忙しい月に読み流すと、最も見落としやすいものです。

資金不足の懸念（C6）にも、同じ判定をさせます。 見込みの残高が最低の残高を下回る月について、コメントに資金の手当て（借入の予定、親会社からの貸付の依頼）が書かれているかを見ます。ただし、C6 で拾ったものは、判定にかかわらず担当者に必ず回します。 AI の判定で explained になっても、資金の手当てが本当に決まっているかは人が確かめます。

recurring は、説明の中身と別の軸で付けます。 今月のコメントが explained に当たる丁寧なものでも、同じ科目を過去3か月に照会していれば recurring にします。毎月それらしい理由で外れ続ける見込みは、見込みの立て方の問題で、1か月ずつの説明では見えません。

指示内容を固定する

あなたは企業グループの親会社の財務部で、子会社の資金繰り表を点検する立場です。
渡された差の一覧と、子会社が書いたコメントだけを使って判定してください。

【差の一覧の見方】
- 差はスクリプトが計算したものです。金額と率はそのまま使ってください。
- direction は、実績が見込みより多い（over）か少ない（under）かです。
- kind が shortage のものは、見込みの期末の残高が最低の残高を下回る月です。

【判定の選び方】
- explained ...... 理由・相手・時期が書かれ、差の向きと大きさに合っている
- insufficient ... 理由はあるが、相手か時期が分からない
- inconsistent ... コメントの内容が、差の向きや大きさと合わない
- no_comment ..... コメントが空
- recurring ...... 説明はあるが、過去3か月に同じ科目を照会している
迷ったときに explained を選ばないでください。

【厳守事項】
- 計算をしないでください。差の金額や率を自分で出し直さないでください。
- コメントに書かれていない事情を補わないでください。
  「おそらく季節の要因」のように推し量らないでください。
- shortage のものは、資金の手当て（借入・貸付の依頼など）が
  具体的に書かれているかだけを見てください。資金が足りるかは判断しないでください。
- 照会するべきか、急ぐべきかは書かないでください。
- questions には、子会社の経理に聞くことを1つずつ、短い文で書いてください。
  explained のものは空にしてください。
- evidence には、判定の根拠にしたコメントの文をそのまま写してください。

【会社】{company_code}（通貨：{currency}、月の支出の平均：{avg_outflow}）
【差の一覧】{diffs_json}
【各行のコメント】{comments_json}
【過去3か月の照会と回答の要旨】{past_inquiries}

「計算をしないでください」は、差の金額をそのまま渡しても要ります。 AI は「差は約1億円で、売上の1割に当たる」のように、頼まれていない計算を足して説明しようとします。 その数字が照会文の案に入ると、子会社に誤った数字で問い合わせることになります。

「資金が足りるかは判断しないでください」は、C6 のためです。 見込みの残高が細っている会社について、AI は「借入の予定があるので問題ない」とまとめがちです。問題があるかどうかは、借入が本当に決まっているかを人が確かめてから決めます。

出力形式を固定する

構造化出力で、次の形の JSON を受け取ります。

{
  "company_code": "",
  "items": [
    { "diff_key": "",
      "kind": "variance | shortage",
      "judgement": "explained | insufficient | inconsistent | no_comment | recurring",
      "evidence": "",
      "reason": "",
      "questions": [""] }
  ],
  "inquiry_draft": ""
}

diff_key は、スクリプトが差の一覧に付けたキーをそのまま返させます。 返ってきたキーが渡したキーと1対1で対応しているかをスクリプトが確かめ、抜けや余分があれば、その会社の結果を「要再実行」にします。 差の1つが判定から落ちると、照会すべきものが一覧から消えるためです。

スキーマでは kind と judgement を enum で縛ります。公式のページが勧めるとおり、構文が正しくても中身はスクリプトで確かめます。

照会文の案は、insufficient・inconsistent・no_comment・recurring の項目をまとめた1通です。 子会社の経理に、科目ごとに何を聞きたいかが並ぶ形にします。

システムへ連携する

子会社のファイルには書き込みません。 点検の結果を子会社のファイルに書くと、子会社の経理が書き換えられます。結果は親会社の側の点検の一覧にだけ書きます。

照会のメールも送りません。 担当者が案を直し、自分のメールで送ります。

人が確認する

担当者は、点検の一覧を次の順で見ます。

1. 計算の不一致 … 子会社に記入の直しを頼みます。AI の判定はありません
2. 資金不足の懸念（C6） … 判定にかかわらず全件を見ます。資金の手当てが決まっているかを確かめ、必要なら上長に上げます
3. inconsistent … コメントと差を見比べ、照会文の案を直して送ります
4. recurring … 過去の回答を読み、見込みの立て方そのものを子会社と話すかを決めます
5. insufficient と no_comment … 照会文の案を確かめて送ります
6. explained … 一覧で流し見て、違和感のあるものだけ開きます

2番目を、判定より先に見てください。 資金の不足は、照会文のやり取りを待てないことがあります。

判定を覆したら、点検の一覧の「担当者の判断」の列に理由を一言書きます。 「explained だが金額が大きいので念のため照会」「insufficient だが先月の回答で分かっている」のような理由がたまると、判定の基準のどこが課の実際の判断とずれているかが見えてきます。2名の担当者で月に1回、覆した理由を読み合わせると、照会の基準そのものもそろっていきます。

例外に対処する

最も多いのは2行目と5行目です。 どちらも AI の問題ではなく、提出の手順の問題です。

記録を残す

• 点検した日時と、そのときのファイルの最終更新の日時
• 当月の版の写し（翌月の C1 と C5 に使う）
• 数字の点検の結果（C1〜C6）
• AI に渡した差の一覧とコメント、返ってきた JSON
• 担当者の判断 … 照会した・しなかった・判定を覆した
• 子会社の回答の要旨（翌月以降の過去の照会として使う）

5つ目で判定を覆した件数を数え、指示を直す材料にします。 explained を担当者が照会に変えた件数が多ければ、判定の基準を厳しくします。

2つ目の写しは、点検の根拠そのものです。 子会社のファイルは翌月に上書きされるので、「このとき、この数字を見てこう判定した」を後から説明できるのは写しだけです。写しは閲覧を財務部に限ったフォルダに置き、保存の期間はグループの文書の規程に合わせます。