配送ドライバーが出す日報の自由記述を、荷主・納品先・道路・車両・荷物の問題に分類し、週ごとの件数と対応が要るものを配車担当に届ける

処理の起点を決める

フォームの回答がスプレッドシートに入ったことを起点にします。 スプレッドシートに付けたスクリプトで、フォーム送信のインストール型トリガーを作ります。回答1件ごとに動き、その行の自由記述だけを分類します。

1日1回まとめて分類する形にしないのは、車両の報告のためです。 夕方に出た日報で「ブレーキの効きが甘い」と書かれていれば、翌朝その車が出る前に整備の担当が見る必要があります。 まとめて夜中に分類すると、知らせが翌朝の出庫に間に合わないことがあります。

週ごとの集計は、時間主導型のトリガーで毎週月曜の朝に動かします。 ScriptApp.newTrigger() に timeBased()・onWeekDay()・atHour() を続けて作ります。公式のページでは、時刻は少しずれることがあり、たとえば9時に設定すると9時から10時のあいだの時刻が選ばれ、その時刻が日をまたいで保たれるとされています。月曜の朝の打ち合わせの前に届けばよいので、7時台に設定します。

入力データを集める

質を決めるのは、名寄せの一覧です。 「A社の厚木」「厚木センター」「厚木DC」を1つの正式な名前に結べなければ、週ごとの件数が割れて、第3章の（c）がそのまま残ります。 最初は配車担当が知っている別名を書き出すところから始め、unknown_name で返ってきた名前を週ごとに足していきます。

配送した荷主の選択式の欄も、AI への入力に入れます。 自由記述に「センターで2時間待ち」としか書かれていなくても、その日に回った荷主が1社なら、どこのセンターかが決まります。 ただし、2社以上なら決めつけさせません。

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

フォーム送信のトリガーは、回答の行の値をイベントとして渡します。 スクリプトはその値から自由記述と荷主の欄を取り出し、同じ行の右の列に結果を書きます。 シートを上から読み直す必要はありません。

API キーはスクリプトに直接書きません。 スクリプトのプロパティに置き、実行時に読みます。スクリプトを人に見せたときにキーが漏れないようにするためです。

フォーム送信のトリガーで動く関数は、次の順で処理します。

1. イベントから、行の番号・自由記述・その日の荷主・運行日を取り出す
2. 自由記述が空か「特になし」だけなら、区分に none と書いて終わる
3. 名寄せの一覧・区分の定義・知らせの規則を読む
4. Claude API を呼び、JSON を受け取る（失敗したら「未分類」と書いて終わる）
5. 荷主名・納品先名を名寄せの一覧で正式な名前に直す
6. 行の右の列に、区分・名前・待ち時間・要約・根拠の文を書く
7. 規則の一覧と車両の語の一覧を見て、知らせるなら MailApp で送り、送った日時を書く

6番目の書き込みを、7番目の送信より先にしているのは意図してのことです。 送信が失敗しても、分類の結果は行に残ります。知らせの列が空のまま区分が vehicle の行は、拾い直しの処理で送り直せます。

Claude API は UrlFetchApp で呼びます。 送り先は Messages API で、ヘッダに API キーと API のバージョンを付け、本文に区分の定義・自由記述・output_config を入れます。Apps Script の公式の割り当てでは、URL Fetch の呼び出しは一般のアカウントで1日2万回、Google Workspace のアカウントで1日10万回で、月600件には十分です。

AIへ渡す前に整形する

1. 空と「特になし」を除く … 自由記述が空、または「特になし」「なし」「異常なし」だけのものは API を呼びません。区分は none として書き、件数には数えます
2. 前後の空白と絵文字を落とす … 分類に要らない文字を除きます
3. 荷主の選択式の値を添える … その日に回った荷主の一覧を渡します
4. 名寄せの一覧の別名を添える … AI が荷主名・納品先名を抜き出すときの手がかりにします
5. 運行日を確かめる … 提出日と運行日が2日以上離れているものは、前の日の日報の出し直しかもしれません。分類はしたうえで、週ごとの集計では運行日の週に数えます
6. 長さを確かめる … 自由記述が極端に長いもの（たとえば2,000字を超える）は、分類はしたうえで人の確認の印を付けます

1番目で API を呼ばない分が、費用の多くを占めます。 月1,200件の日報のうち半分は「特になし」で、呼ばなくても分類の結果は決まっています。

AIに処理させる

させるのは、自由記述を区分に分けることと、荷主名・納品先名・短い要約・根拠の文を抜き出すことです。

1件の自由記述に、区分が2つ以上あることを許します。 「A社で1時間待ち、その後の国道が通行止め」は shipper と road です。1つに絞らせると、件数が片方に寄ります。

荷主名・納品先名は、書かれたとおりに抜き出させます。 正式な名前に直すのは、スクリプトが名寄せの一覧で行います。AI に直させると、一覧に無い名前をそれらしい名前に寄せてしまいます。

2行目が、この構成でいちばん守るべきことです。 「少し」「気がする」と書かれた車両の報告を、AI は軽いものとして要約しがちです。区分が vehicle であれば、要約の言い方にかかわらず配車担当に届けます。

指示内容を固定する

あなたは運送会社の配車課で、配送ドライバーの日報の自由記述を分類する立場です。
自由記述に書かれていることだけを使い、区分に分けてください。

【区分】
- shipper：荷主の都合による問題（荷待ち、荷役、積み込みの指示の変更）
- consignee：納品先の都合による問題（受付時間、置き場、不在、検品の待ち）
- road：道路の問題（渋滞、通行止め、工事、駐車の場所）
- vehicle：車両の問題（異音、警告灯、ブレーキ、タイヤ、ミラー、荷台の設備）
- cargo：荷物の問題（破損、数量違い、梱包の崩れ、温度）
- none：問題の記述が無い
1件に複数の区分があれば、すべて挙げてください。

【抜き出す項目】
- categories：区分の一覧と、それぞれの小区分
- shipper_name・consignee_name：書かれたとおりの名前。無ければ空
- wait_minutes：待ち時間が数字で書かれていれば分に直す。無ければ null
- summary：問題を1文で。書かれていない事情を足さない
- evidence：区分の根拠にした文をそのまま写す

【厳守事項】
- 車両について少しでも書かれていれば vehicle を挙げてください。
  「気がする」「少し」でも、軽いものとして外さないでください。
- 荷主名・納品先名を正式な名前に直したり、似た名前に寄せたりしないでください。
- その日に回った荷主が1社だけなら、「センター」とだけ書かれた待ちを
  その荷主のものとしてよいです。2社以上なら shipper_name は空にしてください。
- 待ち時間が「長かった」など数字でないときは、wait_minutes を null にしてください。
- 対応が要るか、急ぐかは書かないでください。

【区分の定義と例】{category_definitions}
【名寄せの一覧の別名】{alias_hints}
【その日に回った荷主】{shippers_of_day}
【自由記述】{free_text}

「軽いものとして外さないでください」を書くのは、要約の性質のためです。 AI は短くまとめるときに、程度の弱い記述を落とします。車両の記述が落ちると、その日報は none になり、誰の目にも入りません。

「2社以上なら空」も要ります。 書かなければ、最初に挙がった荷主を当てはめます。荷待ちの件数が別の荷主に付くと、荷主との話し合いの根拠が崩れます。

出力形式を固定する

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

{
  "categories": [
    { "category": "shipper | consignee | road | vehicle | cargo | none",
      "subcategory": "" }
  ],
  "shipper_name": "",
  "consignee_name": "",
  "wait_minutes": null,
  "summary": "",
  "evidence": ""
}

スキーマでは category を enum で縛り、オブジェクトに additionalProperties: false を付けます。区分に無い語が返ってこないので、集計の関数が崩れません。

1つ目の理由は、区分で知らせの規則を引けることです。 スクリプトは categories を見て、規則の一覧から知らせるかどうかを決めます。自由文で返させると、「車両」が文中にあるかを探す処理になり、言い換えで漏れます。

2つ目は、回答の行の右の列にそのまま並べられることです。

3つ目は、書かれたとおりの名前と正式な名前を両方残せることです。 名寄せの一覧に無い名前は正式の列が空になり、週ごとに一覧へ足す候補として拾えます。

システムへ連携する

MailApp で送れる宛先の数には、1日の上限があります。 公式の割り当てでは、一般のアカウントで1日100、Google Workspace のアカウントで1日1,500の宛先です。知らせは配車課の共有アドレス1つに送るので、上限に近づくことはありません。

週次のメールには、件数の表と週次のシートへのリンクを載せます。 荷主ごと・納品先ごとの件数、荷待ちの合計の分、車両の報告の件数を並べます。根拠の日報は、週次のシートから回答の行へたどれます。

人が確認する

人が確かめるのは、知らせの来たものと、週ごとの件数です。

1. 知らせを読む … 車両の報告は、整備の担当にその日のうちに回します。翌朝の出庫の前に見てもらいます
2. 荷物の破損・数量違いを荷主の窓口へつなぐ … 荷主との連絡は配車担当が行います
3. 週ごとの件数を見る … 荷待ちの多い荷主・センター、受付時間の変わった納品先を拾います
4. 名寄せの一覧を足す … 正式の列が空の名前を一覧に足します
5. 区分の誤りを直す … 誤りに気づいたら、右の列の区分を直し、確認の列に記録します

整備の担当に回した車両の報告は、結果を確認の列に書きます。 「点検して異常なし」「部品を交換」などです。同じ車番の報告が続くなら、その記録が整備の判断の材料になります。

知らせの来ないものは、1件ずつは読みません。 road の渋滞のように、週ごとの件数で見れば足りるものが大半だからです。ただし、最初の1か月は全件の分類の結果を流し見て、none に落ちたものの中に車両の記述が無いかを確かめます。

例外に対処する

3行目は、AI の分類に頼らない安全弁です。 車両の報告を漏らすことが、この構成でいちばん重い失敗です。語の一覧での拾い上げを、AI の区分と並べて持ちます。

5行目は、Apps Script の1回の実行が6分までという制限から来ます。 回答1件ごとの処理は数秒で終わりますが、未分類の拾い直しで溜まった件数を一度に回すと届きます。1回あたりの件数に上限を置きます。

記録を残す

• 日報の回答そのもの（回答のスプレッドシート）
• AI の出力（区分、項目、要約、根拠の文）と、そのときの区分の定義と知らせの規則の版
• 名寄せの前と後の名前
• 知らせを送った日時と宛先
• 配車担当が区分を直した記録 … どの行を、どの区分からどの区分へ変えたか
• 週次の件数（週次のシートに残す）

2つ目で区分の定義の版を残すのは、区分を後から足すためです。 たとえば consignee に「検品の待ち」を足した週から、件数の数え方が変わります。荷主に週ごとの推移を示すときに、定義の変わり目を説明できるようにします。

5つ目は、指示の見直しの材料です。 直された区分が特定の書き方に偏っていれば、区分の定義の例にその書き方を足します。