倉庫会社が荷主ごとの入出庫・在庫の記録と作業の備考から、月の保管料・荷役料・附帯作業料の請求明細を作り、料金表との違いと請求の漏れを拾う

処理の起点を決める

トリガーは2つ置きます。 1つ目は、毎週月曜の朝6時台に動く時間主導型のトリガーで、前週の月曜から日曜までの備考と作業依頼の文面から候補を抜き出します。2つ目は、毎月3日の朝に動く時間主導型のトリガーで、前月分の計算と見比べを行います。時間主導型のトリガーは毎分から月に1回までの間隔で動かせ、公式のページでは、9時に設定すると9時から10時のあいだのどこかで動くとされています。

月次の処理は、日付だけを条件にしません。 CSV の書き出しと取り込みは経理の担当の作業です。スクリプトは最初に取り込み用のシートの「状態」の欄を見て、前月分の3つの CSV が「取込済み」になっていなければ、何も計算せずに担当へ知らせて止まります。 3日から7日まで毎朝見に行き、取込済みになった日に動きます。半端な取り込みのまま計算すると、在庫の数が欠けたまま保管料が出てしまうからです。

インストール型のトリガーは、作った人のアカウントで動きます。 公式のページにそう書かれています。トリガーは経理課の担当者個人ではなく、請求の業務用の共用のアカウントで作ります。 トリガーが失敗すると失敗のまとめのメールが届くので、その宛先も共用のアカウントになります。

入力データを集める

質を決めるのは、料金表のシートです。 寄託の契約と覚書に書かれた決まりを、荷主ごとに1つの表の形にそろえることが、この構成の最初の作業です。決まりが表になっていないと、スクリプトは計算できず、AI が抜き出した作業に単価を掛けることもできません。

改定日の扱いは、料金表の行で持たせます。 改定のたびに行を足し、適用の始まりを書きます。国土交通省が公示した標準冷蔵倉庫寄託約款（乙）では、第52条で料金を変更したときは、変更された日の属する期から新料金で請求するとされています。自社の約款と荷主との契約で同じ決まりを使っているなら、 スクリプトは改定日の属する期から新しい単価を使います。

作業依頼の台帳の「受けた日時」が、急ぎの指図を見分ける材料です。 料金表に「前日の15時より後に受けた当日の出庫」のような条件があれば、受けた日時と作業の予定日をスクリプトが比べて判定します。 AI には時刻の比較をさせません。

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

CSV は経理の担当がシートに貼ります。 倉庫管理システムと直接つなぐ方法は製品ごとに違い、外から取れないものも多いので、書き出しを自動にしようとせず、貼る作業を月に1回と週に1回に集めます。 作業実績の備考だけは週ごとに要るので、週の書き出しは現場の事務の担当に頼みます。

シートは範囲を一度に読み、スクリプトの中で荷主ごとにまとめます。 入出庫の明細は月に数万行になるので、1行ずつ読むと1回の実行時間に収まりません。

AIへ渡す前に整形する

1. 期間と件数の確認 … 入出庫と在庫の日付が前月の範囲にそろっているか、件数が前月から極端に変わっていないかを見ます
2. 荷主のコードの照合 … CSV の荷主のコードが料金表のシートにすべてあるか。無い荷主は計算せず、一覧に「料金表なし」と出します
3. 期ごとの数の計算 … 料金表の期の分け方に沿って、期ごとに前の期の末の在庫とその期の入庫を数え、単位（個・ケース・パレット・重さ）に合わせます
4. 単価の選び方 … 改定日の属する期から新しい単価を使います
5. 備考の整え … 備考と依頼の文面から、人の名前、電話番号、メールアドレスを伏せます。荷主は名前ではなく荷主のコードで渡します
6. 作業のコード付きの行を分ける … 作業のコードが付いた行は、倉庫管理システムの請求に載っているはずなので、抜き出しには渡さず、見比べのほうで使います
7. 文面の並べ方 … 1件ずつ「番号｜日付｜荷主のコード｜種類（備考・依頼）｜文」の1行にし、荷主ごとにまとめます

6番目で、AI に渡す量を絞ります。 抜き出しが要るのは、コードが付かずに文でしか残っていない作業だけです。コードの付いた作業まで渡すと、同じ作業が二重に候補に出ます。

3番目の単位の合わせ方は、荷主ごとの決まりの中でいちばん間違えやすいところです。 ケースで数える荷主の在庫が、倉庫管理システムでは個で入っていることがあります。入り数は品番の台帳から取り、入り数が無い品番は計算せずに一覧に出します。

AIに処理させる

させるのは、備考と作業依頼の文面から、請求の対象になりうる作業を項目として抜き出すことです。

数量は、書かれたとおりに写させます。 「約1,200枚」を1200に直させません。「約」が付いた数量は、現場のリーダーが確かめる対象で、その印を消さないためです。数として読める形にするのはスクリプトで、「約」「〜分」「程度」が付いたものは、確かめが済むまで請求の計算に使いません。

指図の変更は、時刻を判定させません。 「本日16時までに」という依頼の文面を抜き出させるだけで、それが料金表の「急ぎ」の条件に当たるかは、台帳の受けた日時と予定日からスクリプトが決めます。

2行目がいちばん起きやすい失敗です。 「パレット3枚分のラベル貼り」と書かれていると、AI はパレットの入り数から枚数を出そうとします。その瞬間、現場が書いていない数量が請求に入ります。 数量が文に無ければ空にし、現場に聞きます。

指示内容を固定する

あなたは営業倉庫の経理課で、荷主への請求の準備を手伝う担当です。
以下は、1つの荷主の1週間分の「作業実績の備考」と「作業依頼の文面」です。
この文だけを使って、請求の対象になりうる作業を1件ずつ抜き出してください。

【作業の種類】
labeling（ラベル・値札・シール貼り）／sorting（仕分）／
full_inspection（全数検品）／unpack_inspection（開梱検品）／
hand_unloading（車両での手荷役）／order_change（当日の出庫依頼・
出庫の取り消し・入出庫の日の変更）／other（上のどれにも当たらない作業）

【書き方】
- items：作業ごとに1件。同じ作業が備考と依頼の両方に出ていれば、
    1件にまとめ、source_ids に両方の番号を入れる。
- quantity_text：文に書かれた数量と単位を、書かれたとおりに写す。
    「約」「程度」「〜分」も含めて写す。数量が無ければ空にする。
- work_date：作業の日、または依頼された作業の予定日。書かれていなければ空。
- evidence：抜き出しの元になった部分を、原文のまま写す。

【厳守事項】
- 金額・単価を書かないでください。計算をしないでください。
- 数量を推し量らないでください。入り数から枚数を出す、
  「約」を外す、丸めることをしないでください。
- 当日の依頼や取り消しが、急ぎの料金に当たるかを判断しないでください。
  order_change として抜き出すだけにしてください。
- 請求すべきかどうかを書かないでください。
- 作業の種類に迷ったら other にしてください。
- 保管や通常の入庫・出庫そのもの（附帯の作業を伴わないもの）は抜き出さないでください。
- 人の名前、連絡先を書かないでください。

【荷主のコード】{shipper_code}
【文の一覧】{notes}

最後から2つ目の「通常の入庫・出庫は抜き出さない」が、候補の数を左右します。 備考には「入庫 30ケース 完了」のような記録が多く、何も言わなければ全部を作業として抜き出します。 第4条が別の料金を認めているのは附帯する業務なので、通常の業務は候補から外すことを明記します。

出力形式を固定する

Gemini API の Interactions API で、構造化出力を使って次の形の JSON を受け取ります。 公式のページでは、/v1beta/interactions に response_format で mime_type を application/json にし、schema を渡す書き方が示されています。

{
  "shipper_code": "SH-024",
  "week_start": "2026-10-19",
  "items": [
    { "work_type": "labeling",
      "quantity_text": "約1,200枚",
      "work_date": "2026-10-21",
      "source_ids": ["N-1021-07", "Q-1020-03"],
      "evidence": "値札シール貼り 約1,200枚" }
  ],
  "needs_review": ""
}

1つ目の理由は、根拠をスクリプトで検算できることです。

3行目が、数量を守る検査です。 写したはずの数量が根拠の文に無ければ、AI が計算するか推し量ったということです。文字列の一致で見るので、作り込まれた数量は必ず見つかります。

2つ目の理由は、現場が確かめる一覧にそのまま並べられることです。 種類・日付・書かれた数量・根拠の文が並ぶので、現場のリーダーは、確かめた数量を隣の列に書くだけで済みます。

公式のページでは、出力の JSON は構文として正しくても値はアプリケーションの側で必ず確かめることとされ、制約の中には制約付きの生成の仕組みで守られないものがあるとも書かれています。列挙型の値も検査で確かめ直します。 スキーマが大きすぎたり深すぎたりすると400のエラーで断られることがあるとされているので、スキーマは上の形の1段の入れ子にとどめます。

システムへ連携する

API の呼び出しでは muteHttpExceptions を true にします。 公式のページでは、これを true にすると失敗の応答でも例外を投げず、応答を返すとされています。応答のコードを見て、混み合いなら時間をおいてやり直し、続けて失敗した荷主は「候補なし」ではなく「抜き出し失敗」として一覧に出します。 候補が無いことと、抜き出せなかったことを混ぜると、漏れを探す仕組みそのものが漏れます。API キーはスクリプトのプロパティに置きます。公式のページでは、スクリプトのプロパティはそのスクリプトの利用者全員で共有され、スクリプトの間では共有されないとされています。

Interactions API は、既定でやり取りを保存します。 公式のページでは、既定で store=true となり、有料の利用では55日、無料の利用では1日保たれるとされ、store=false を指定すれば保存しないとされています。この構成は1回ごとに完結するので、リクエストに store=false を付けます。

人が確認する

確認は2か所で、別の人が行います。

1. 週ごと：現場のリーダーが候補を確かめる … 候補の一覧で、作業が本当にあったか、数量はいくつか。「約」の付いた数量は確かめた数を隣の列に書き、確かめの印を付けます
2. 月ごと：経理の担当が違いと漏れの一覧を見る … 上から「料金表なし」「抜き出し失敗」「請求の下書きに無い行（漏れ）」「金額の違い」「下書きにしか無い行」の順に並びます
3. 漏れの行は、料金表の決まりを確かめてから足す … 附帯作業の料金を決めていない荷主の作業は、請求に足さず、営業の担当に回します
4. 金額の違いは、どちらが正しいかを決める … 改定の反映漏れなら、倉庫管理システムの単価の登録も直します
5. 上長が見てから送る … 送るのはこれまでどおり請求の仕組みから

3番目を省かないでください。 作業があったことと、その作業に料金を請求できることは別の話です。料金を決めていない作業をいきなり請求すると、荷主との関係を損ねます。 そうした作業が毎月出るなら、料金を決めて届け出る話として営業に渡します。

1件12分を目安にします。 計算の違いが無い荷主は数分で終わり、漏れや改定のある荷主に時間を使います。

例外に対処する

最後の行は、Apps Script の上限から来ます。 公式の上限の表では、スクリプトの実行時間は1回あたり6分で、トリガーで動かした合計の実行時間は Google Workspace のアカウントで1日6時間です。60社分の計算は入出庫の明細が多い荷主で重くなるので、10社ずつ計算し、残りは1回きりのトリガーで続きを作ります。 トリガーはユーザー・スクリプトごとに20個までとされているので、続きのトリガーは動いたら消します。

記録を残す

• 実行の日時、対象の週または月、荷主ごとの取り込みの件数
• 荷主ごとの計算の内訳（期ごとの数、単位、使った単価と料金表の行、最低料金の当てはめ）
• AI に渡した文の一覧（伏せ字の後）と、AI が返した JSON の全文
• 検査の結果と、確認待ちにした理由
• 現場のリーダーが確かめた数量と、確かめた日・人
• 経理の担当が直した請求の行と、その理由

2つ目の計算の内訳が、荷主からの問い合わせへの答えになります。 「今月の保管料が高い」と言われたとき、どの期の、どの在庫の数に、どの単価を掛けたかをそのまま示せます。

最後の行は、同じ違いが毎月出る荷主の登録を直す材料になります。