倉庫の入出荷の件数と作業人員・作業時間から作業別の生産性を毎日集計し、下がった作業と理由の候補をセンター長への日報にまとめる

処理の起点を決める

毎朝6時台の時間主導型のトリガーで、前日の1日分をまとめて処理します。 作業の途中で何度も動かすことはしません。生産性は1日の締めの数字で比べるもので、昼の時点の数字で「下がった」と知らせても、午後に取り戻すことがあるからです。

動き始めたら、まずCSVの基準日を確かめます。 WMSと勤怠のCSVが前日の分でなければ、計算を始めずに担当者へ「前日分が届いていない」とだけ送ります。割り振り表も、前日の分にリーダーの記入があるかを見ます。 記入が空の日は、投入人時を勤怠だけで数えたことを日報に明記します。

休日の翌朝は、休日の分を処理しません。 稼働日の一覧をシートに持ち、稼働日だけを処理します。稼働しなかった日を「生産性0」として基準に混ぜると、翌週から全作業が「上がった」と出ます。

トリガーは業務課の共有の管理用アカウントで作ります。 インストール型のトリガーは作った人のアカウントで動き、失敗したときには失敗をまとめたメールがその人に届きます。担当者が休みでも止まらないように、個人のアカウントでは作りません。

入力データを集める

質を決めるのは、割り振りの記録です。 処理量はWMSに正確に残りますが、分母の人時は割り振り表の書き方しだいです。 応援で1時間だけピッキングに入った人を書き忘れると、ピッキングの生産性が上がり、元の作業の生産性が下がって見えます。

出荷の明細は、物量の構成を見るために持ちます。 同じ1,000行でも、1件1行の単品の出荷が多い日と、1件10行の店舗向けが多い日では、ピッキングの歩く距離がまったく違います。生産性が下がった日の多くは、この構成の違いで説明がつきます。

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

CSVと割り振り表は、範囲を1回でまとめて読みます。 Apps Script では、スクリプトの中での計算は他のサービスを呼ぶより速く、読み書きを交互にくり返すと遅くなるとされています。作業者70名・スキャン数万件を1行ずつ読み書きすると、1回の実行の6分に収まりません。

計算の式は、次の1つに決めます。

生産性 ＝ 作業区分ごとの処理量 ÷ その作業区分に割り振られた人時
いつもの水準 ＝ 同じ曜日の直近4週の生産性の中央値
下がった作業 ＝ 生産性 ÷ いつもの水準 が 0.90 を下回った作業
空白の時間 ＝ 同じ作業者のスキャンの間隔が10分を超えた部分の合計

比べる相手を「同じ曜日の直近4週の中央値」に固定するのは、第3章の（c）の対策です。 月曜は週末の受注がたまって単品の出荷が多い、といった曜日の癖を外せます。平均ではなく中央値にするのは、セールの日のような外れた1日に引っぱられないためです。 0.90の線と10分の線は、センター長が決めてシートに置きます。

AIへ渡す前に整形する

1. 基準日の確認 … WMSと勤怠のCSV、割り振り表が前日の分かを確かめます
2. 作業者IDの名寄せ … WMSのログインIDと勤怠の社員番号が違う場合は、作業者の一覧で対応させます
3. 人時の配分 … 割り振り表の開始と終了の時刻で、1人の勤務時間を作業区分ごとに分けます。休憩の時間は除きます
4. 割り振りの無い時間の扱い … 出勤しているのに割り振りが無い時間は「未割り振り」として別に数えます。どの作業にも足しません
5. 生産性と比較の計算 … 「データの取得方法」の式で計算し、下がった作業に印を付けます
6. 理由の材料の計算 … 下がった作業について、1件あたりの行数、単品の比率、新人の比率、空白の時間、入荷の遅れを、いつもの水準と並べて出します
7. メモの抽出 … 割り振り表のリーダーのメモから、その作業区分に関係する行だけを取り出します

4番目を省かないでください。 未割り振りの時間をどこかの作業に足すと、その作業の生産性が下がって見え、AIはそれに理由を付けようとします。 未割り振りが多い日は、それ自体を日報に書きます。

6番目の材料は、AIに計算させません。 「新人の比率がいつもより高い」と書かせるなら、その比率は前処理で出しておきます。AIが件数から比率を割り出すと、桁を誤ったまま日報に載ります。

AIに処理させる

させるのは、下がった作業ごとに、前処理で並べた材料のどれが理由の候補になるかを選び、センター長向けの文章にまとめることです。 計算と、どの作業が下がったかの判定は前処理で終わっています。

1つの作業に候補を複数付けてよく、順位を付けさせます。 ただし、どの候補にも evidence に材料の項目名と値を添えさせます。 根拠を添えられない候補は書かせません。

2行目と3行目が、いちばん起きやすい失敗です。 作業者IDを渡すと、空白の時間が長かった作業者を名指しして書きます。AIには作業者IDを渡さず、作業区分ごとの合計だけを渡します。 3行目は、材料が乏しい日ほど起きます。何も言わなければ、もっともらしい理由で文章を埋めます。

指示内容を固定する

あなたは物流センターの業務課で、センター長への日報を書く立場です。
与えられた数字と記録だけを使って書いてください。推測で埋めないでください。

【あなたの仕事】
生産性が下がった作業ごとに、理由の候補を選んで順位を付け、
センター長が1分で読める日報の文章にまとめてください。

【理由の候補の選び方】
- volume_mix ..... 1件あたりの行数か単品の比率が、いつもの水準と違う
- new_staff ...... 経験3か月未満の人時の比率が、いつもの水準より高い
- idle_time ...... 空白の時間が、いつもの水準より長い
- inbound_delay .. 入荷の便に遅れがある（入荷検品・格納だけ）
- leader_note .... リーダーのメモに、その作業に関係する記載がある
- unknown ........ 上のどれにも当てはまらない
どの候補にも、evidence に根拠にした材料の項目名と値を書いてください。
根拠を書けない候補は挙げないでください。当てはまるものが無ければ unknown だけを返してください。

【厳守事項】
- 生産性、比率、時間などの数字は、入力の値をそのまま書いてください。計算し直さないでください。
- 個人を特定する書き方をしないでください。
- 疲労、天候、意欲など、入力に無い理由を書かないでください。
- 人の配置や作業の進め方の指示を書かないでください。
- 生産性が下がっていない作業については、所見を書かないでください。
- summary は3文以内で、下がった作業の名前、下がり幅、第1候補の理由を書いてください。
- リーダーのメモを引用するときは、メモの文言をそのまま書いてください。

【下がった作業ごとの材料】{flagged_json}
【全作業の生産性といつもの水準】{all_tasks_json}
【未割り振りの時間】{unassigned_hours}
【対象日】{date}（{weekday}）

「根拠を書けない候補は挙げない」と「unknown だけを返す」をセットで書きます。 どちらか一方だけだと、根拠が弱い候補を unknown と並べて返します。理由が分からないことを、そのまま日報に書ける形にしておくことが、この構成の目的の一つです。

出力形式を固定する

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

{
  "date": "2026-10-05",
  "summary": "",
  "flagged_tasks": [
    {
      "task": "picking",
      "productivity": 0,
      "baseline": 0,
      "ratio": 0,
      "reasons": [
        {
          "rank": 1,
          "code": "volume_mix | new_staff | idle_time | inbound_delay | leader_note | unknown",
          "evidence": [ { "field": "", "value": "" } ],
          "text": ""
        }
      ],
      "question_to_leader": ""
    }
  ]
}

1つ目の理由は、code を enum で絞れることです。 理由を自由文だけで書かせると、同じ物量の構成の違いが日によって違う言葉で書かれます。決まった値なら、「volume_mix が月に何日あったか」を記録から数えられます。 月末に、センター長が作業ごとの理由の内訳を見られます。

2つ目は、数字を入力と突き合わせられることです。 productivity・baseline・ratio と evidence の値を、スクリプトが前処理の値と比べます。1つでも違えば、その作業の所見を捨て、数字だけを日報に載せて「所見は担当者が記入」とします。

3つ目は、question_to_leader で確認が速くなることです。 業務課の担当者は、この1問だけを持ってリーダーのところへ行けます。「昨日は何があったか」を一から聞かずに済みます。

システムへ連携する

Gemini API は UrlFetchApp.fetch で呼びます。 method を post、contentType を JSON にし、headers に API キーを入れます。muteHttpExceptions を true にして、失敗の応答でも例外で止めずに応答のコードを見ます。 失敗したときは、数字だけの日報を作ります。

API キーと線の値は、スクリプトのプロパティに置きます。 スクリプトのプロパティは、そのスクリプトのすべての利用者に共有されるアプリ全体の設定の置き場所で、値は文字列で保存されます。0.90 や 10分 も文字列で返るので、読み出したら数値に直してから比べます。 直し忘れると、比較が文字列の大小で行われます。

日報は、まず担当者あての下書きにします。 GmailApp の createDraft で下書きを作れ、htmlBody で表を組んだ本文を付けられます。担当者がリーダーに確かめて理由を直したら、記録のシートの「確定」の列に印を付け、次の実行でセンター長へ送ります。 センター長には、確定していない所見を送りません。

人が確認する

人が確かめるのは、下がった作業の理由の候補だけです。 下がっていない作業は数字の表だけで、所見はありません。

1. 未割り振りの時間を先に見る … 多ければ、割り振り表の記入漏れをリーダーに確かめます。直すと、下がった作業が消えることがあります
2. 第1候補の根拠を確かめる … evidence の値を見て、候補が妥当かを判断します
3. リーダーに1問だけ聞く … question_to_leader を持って行き、現場で何があったかを聞きます
4. 理由を確定する … AIの候補を採るか、リーダーの話に直すかを決め、code を確定します。直したことは記録に残します
5. センター長へ送る … 確定の印を付けます

1番目が、いちばん効きます。 生産性が下がって見える日の多くは、割り振り表に応援の移動が書かれていないだけです。記入漏れを直す前に理由を考えると、存在しない問題に理由を付けることになります。

目標は、120件をならして1件4分です。 下がった作業が無い日は数字の確認だけで終わり、下がった作業がある日はリーダーとのやり取りに10分ほどかかる想定です。

例外に対処する

上から3行目までが、最初の1か月の大半を占めます。 どれもAIの問題ではなく、割り振りの記録の書き方の問題です。 リーダーが移動を書く習慣がつくまでは、日報の数字そのものが揺れます。

記録を残す

• その日に読み込んだCSVのファイル名と基準日
• 作業ごとの処理量、人時、生産性、いつもの水準、未割り振りの時間
• 理由の材料（行数、単品の比率、新人の比率、空白の時間、入荷の遅れ）
• AIに渡した入力と、返ってきたJSONの全文
• 担当者が確定した理由と、AIの候補から変えたかどうか
• そのときの線（0.90、10分）

5つ目は、AIの候補がどれだけ当たっているかを見る材料です。 unknown が多い作業は、理由を読み取る材料が足りていません。入荷の記録や設備の停止の記録を足す検討の材料になります。

割り振り表は、その日の内容を記録のシートに写しておきます。 リーダーが後から割り振り表を直すと、過去の生産性の分母が変わります。写しが無いと、なぜその日にその作業が下がったと出たのかを説明できません。