配達の不在・持ち戻りの記録を理由別に分類して、再配達を減らす打ち手を月次でまとめる

処理の起点を決める

分類のシナリオは毎日23時30分に動かします。 配送管理システムの定時出力が23時に終わるので、その後に置きます。夜のうちに分類が済めば、担当者は翌朝に確認待ちの一覧を見るだけで済みます。

配達の実績は夜遅くまで確定しないことがあります。 夜の時間帯の配達の結果が出力の後に入ると、その日の分が翌日のCSVに回ります。記録の番号で重複と抜けを見るので、どの日のCSVに入っても1回だけ分類されます。

集計と打ち手の案のシナリオは、毎月1日の朝に動かします。 前月分の確認待ちが残っている場合は、集計を始めずに担当者に知らせます。 確定していない分類が混ざった集計は、打ち手の根拠になりません。

入力データを集める

質を決めるのは、分類の区分の一覧と、建物の一覧です。 区分の一覧には、区分ごとの定義と、実際のメモの例を3つずつ入れます。定義だけでは、略語の多いメモを区分に当てはめられないからです。

建物の一覧は、生成AIに推させないために持ちます。 メモに「オートロック」と書かれていなくても、その建物がオートロックの集合住宅なら、集計ではそう扱えます。建物の種類はメモから推すのではなく、一覧から引きます。

最後の2つを分けるのが大事です。 「その他」は区分を足す候補、「分類できない」はドライバーへのメモの書き方の案内の候補です。混ぜると、区分の一覧をどう育てればよいかが分からなくなります。

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

CSVは共有ドライブのフォルダから、Make のシナリオで読み込みます。 読み込んだ行は、分類済みの表とは別の「受付の表」に追加します。記録の番号を一意のキーにし、すでにある番号は追加しません。

生成AIに渡す列は5つだけです。 残りの列は分類には使わず、集計のときに表の側で記録の番号で結び付けます。

建物の種類を渡さないのは、4行目の理由のとおりです。 「オートロックの集合住宅」と分かっていると、メモが「応答なし」だけでも「入館できない」に寄せたくなります。それは集計の段階で建物の種類と掛け合わせれば分かることです。

50件ずつにまとめるのは、呼び出しの回数を抑えるためです。 Make では、配列を1件ずつの束（バンドル）に分けるのが Iterator で、公式の説明では配列の各要素が別々のバンドルとして出力されるとされています。1件ずつ生成AIを呼ぶと、その件数だけ後続のモジュールが動きます。分類は50件を1つの配列のまま渡し、返ってきた配列を Iterator で1件ずつに分けて表に書き戻します。

AIへ渡す前に整形する

1. 重複の除外 … 記録の番号で、すでに分類した記録を除きます
2. 個人情報を外す … 受取人の氏名・電話番号・番地より細かい住所は、生成AIに渡す列から外します
3. メモの中の氏名を伏せる … 「山田様不在」のように、メモに氏名が入ることがあります。「様」「さん」の前の文字列を伏せ字にする置き換えを入れます
4. 空のメモの扱い … メモが空の記録は生成AIに渡さず、理由のコードだけで「分類できない」か、コードに対応する区分を機械的に付けます
5. 表記のゆれをそろえる … 全角・半角、よく使われる略語（「OL」＝オートロック、「BOX」＝宅配ボックス）は、区分の一覧のメモの例に入れておき、置き換えはしません

3番目は完璧にはなりません。 伏せきれない氏名が残ることを前提に、生成AIの利用の条件（入力が学習に使われないか、保存される期間）を先に確かめます（第13章）。

5番目で置き換えをしないのは、置き換えの誤りを防ぐためです。 「OL」を機械的に「オートロック」に置き換えると、別の意味で使われた「OL」まで変わります。例として示し、読み取りは生成AIに任せます。

AIに処理させる

させるのは2つです。毎日の分類と、月1回の打ち手の案です。

打ち手の案に渡すのは集計表だけで、1件ずつの記録は渡しません。 1か月分の記録をすべて渡すと、生成AIが自分で数え直し、表の数と違う数を書くことがあります。数えるのは表、読んで案を書くのが生成AIという分担を、渡すデータの側でも守ります。

2行目が、最も起きやすい逸脱です。 時間帯の指定が「19〜21時」で配達を試みた時刻が18時40分なら、生成AIは「指定前に到着」と判断したくなります。しかしメモに書かれていなければ、それは推測です。 時刻の比較で分かることは、表の関数で別の列として出します。 生成AIの分類と表の比較が食い違えば、それ自体が確かめる材料になります。

5行目も守ってください。 分類の表にはドライバーのコードが残るので、ドライバーごとの「分類できない」の割合を出すことはできます。 それはメモの書き方を案内するための数であり、評価に使うと、ドライバーはメモを書かなくなります。

指示内容を固定する

分類に使う指示です。

あなたは配送センターの業務課の補助です。
不在で持ち戻った荷物の記録を、下の【区分の一覧】のどれか1つに分類してください。

【区分の一覧】
{category_list}   ← 区分の名前・定義・メモの例

【分類のしかた】
- メモと理由のコードに書かれていることだけを根拠にしてください。
- 区分の一覧に無い区分を作らないでください。
- 理由が読み取れるが、どの区分にも当てはまらない場合は「その他」にしてください。
- メモが意味をなさない、または理由が読み取れない場合は「分類できない」にしてください。
- 配達を試みた時刻と時間帯の指定を比べて、理由を推測しないでください。
  「指定前」などの記載がメモに無ければ、時間帯の指定の前に到着した区分にしないでください。
- confidence は、メモの記載がその区分の定義にはっきり当てはまるなら high、
  当てはまるが略語などで確かでないなら medium、迷ったなら low にしてください。
- evidence には、根拠にしたメモの語をそのまま写してください。
- 伏せ字（＊＊）の部分を推測して補わないでください。
- 入力のすべての記録について、記録の番号を変えずに1件ずつ返してください。

【記録（50件）】
{records_json}

「時刻と時間帯の指定を比べて推測しない」を明記しないと、ほぼ確実に比べます。 生成AIにとっては親切な推論ですが、分類は「ドライバーが何を見たか」の記録であるべきです。 時刻の比較は表の側で別に行います。

「すべての記録を番号を変えずに返す」も省けません。 50件を渡して48件しか返らないことがあります。返ってきた番号と渡した番号を突き合わせ、足りなければその分だけ再度送ります。

打ち手の案に使う指示では、次の3点を厳守事項にします。 集計表にある数だけを使うこと、案ごとに根拠にした集計の行（区分・エリア・時間帯・建物の種類と件数）を示すこと、配送センターだけでできることと、荷主や建物の管理会社への相談が要ることを分けて書くことです。

出力形式を固定する

分類は、次の形のJSONで受け取ります。 Claude API の構造化出力で output_config.format に JSON スキーマを指定し、category と confidence は enum で決まった値に絞ります。

{
  "results": [
    {
      "record_id": "20260928-0147",
      "category": "入館できない",
      "confidence": "high",
      "evidence": "OL応答なし"
    }
  ]
}

category を enum にするのが、区分を固定する仕組みそのものです。 区分の一覧を直したら、スキーマの enum も同じ日に直します。公式の説明では、構造化出力ではすべてのオブジェクトに additionalProperties: false が必要で、enum には文字列・数・真偽値・null が使えます。

表に書き戻すときの判定は、ワークフローの側で決めます。

打ち手の案は、次の列の表で受け取ります。

システムへ連携する

配送管理システムの理由のコードは書き換えません。 分類した区分は別の表に持ちます。元のコードと付け直した区分を並べておくと、コードの選び方の案内にも使えます。

人が確認する

1. 毎朝、確認待ちの一覧を見る … low と「分類できない」の記録です。メモを読み、区分を確定します。1日十数件、数分で終わる量を想定しています
2. 週に1回、medium を抜き取って見る … 20件を見て、誤りが多い区分があれば、区分の一覧のメモの例を足します
3. 月に1回、「その他」を見る … 同じ理由が何件も「その他」に入っていれば、区分を足すかどうかを業務課で決めます
4. 表の比較と食い違うものを見る … 表の関数で出した「指定の時間帯より前の時刻に試みた」の列と、生成AIの分類が食い違う記録を月に1回まとめて見ます。ドライバーがメモに書き漏らしている理由の傾向が分かります
5. 打ち手の案を確かめる … 根拠の行が集計表と合っているかを見て、責任者に報告します

2番目と3番目が、区分の一覧を育てる場です。 最初に作った区分の一覧は、実際のメモに合っていないところが必ずあります。区分を足すのは月に1回までにし、足した月を記録に残します。頻繁に変えると月ごとの比較が崩れます。

high を人が見ないのは、分類の誤りが1件ずつの荷物の扱いに影響しないからです。 この分類は打ち手を考えるための集計の材料で、1件の誤りは集計の中で薄まります。 ここが、1件の誤りが取引先との関係に直結する点検の業務との違いです。

例外に対処する

上から4行目は、稼働の初めによく見つかります。 ドライバーのメモの書き方は人それぞれで、「山田様」だけでなく「ヤマダ」「山田さん宅」のような書き方があります。見つけるたびに置き換えの規則を足していきます。

記録を残す

• 受け取ったCSVのファイル名と行数
• 生成AIに渡した記録（伏せた後のメモ）と、返ってきた区分・確からしさ・根拠の語
• 担当者が区分を確定・変更した記録（元の区分、確定した区分、日付）
• 区分の一覧の版と、区分を足した月
• 月次の集計表と、打ち手の案、責任者が採った打ち手
• 採った打ち手の翌月以降の、その区分の件数の変化

最後の行が、この構成の目的です。 打ち手を採った翌月に、その区分の件数がどう動いたかを見ます。動かなければ、打ち手が効いていないか、区分の分け方が打ち手に合っていません。

3つ目の記録は、区分の一覧のメモの例を足す材料にもなります。 担当者が low を確定した区分と根拠の語を並べると、生成AIが迷いやすい略語や書き方が見えてきます。

保存の期間を決めておきます。 分類済みの表には受取人の情報を入れていませんが、記録の番号から配送管理システムの記録をたどれます。集計に使い終わった記録の番号を、いつまで残すかを社内の規程に合わせて決めてください。