物流会社が荷主へ毎月出す品質報告の下書きを、事故の記録と原因の分析から作り、件数と原因の説明を記録と照らしてから送る

処理の起点を決める

毎月第2営業日の朝に、前月分をまとめて動かします。 第1営業日にしないのは、前月の最終日の出荷の配送の完了が、翌日の夕方まで記録に入りきらないことがあるからです。遅延の件数が確定する前に動かすと、報告の後で件数が変わります。

荷主ごとに1件ずつ順に処理し、途中で止まった荷主は翌朝にもう一度処理します。 完了した荷主には作成済みの印を付け、二重に下書きを作らないようにします。

荷主から後から申し出のあった事故は、翌月の報告に「前月分の追加」として載せます。 確定した報告を作り直すと、荷主の手元の報告と数字が合わなくなるからです。この扱いは荷主ごとの取り決めに合わせ、設定に持たせます。

入力データを集める

質を決めるのは、事故の台帳の「原因の分析」の列です。 ここが「確認不足」の一言だけでは、AIがどう書いても荷主の知りたい説明になりません。台帳の入力の段で、「何が起きたか」「なぜ気づけなかったか」「なぜそうなる仕組みだったか」を分けて書く欄にしておくと、報告の説明文の質がそろいます。

荷主ごとの設定のうち、遅延の定義がいちばん大事です。 国の標準貨物自動車運送約款は、発送・輸送・集配の期間から引渡期間を定め、その満了後に引き渡したときを延着としています。荷主との間で時間帯の指定や納品の時刻を取り決めているなら、報告の遅延はその取り決めで数えます。 どちらで数えたかを、報告書の注記にも書きます。

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

「前月の事故」と「前月の追加の事故」を分けて取るのは、（a）の食い違いを止めるためです。 発生日で数えるか登録日で数えるかを、プログラムの中で決めておきます。担当者ごとの判断に任せていた境目を、設定の一行にします。

荷主ごとの設定の表は、たとえば次のような行で持ちます（項目名は自社の表に合わせます）。

【荷主 A（通信販売）】
率の分母 ........ 出荷の件数（100万件あたりで表示）
遅延の定義 ...... 配達の完了が、注文時に指定された時間帯の終わりを過ぎたもの
月の数え方 ...... 発生日で数える。前月以前の発生で前月に登録されたものは「前月分の追加」
主な事故 ........ 誤出荷と破損はすべて。遅延は同じ日・同じ地域で3件以上のもの

【荷主 B（小売のチェーン）】
率の分母 ........ 出荷の行数（1万行あたりで表示）
遅延の定義 ...... 店舗への納品が、納品の時刻表の時刻を30分以上過ぎたもの
月の数え方 ...... 登録日で数える
主な事故 ........ 店舗から申し出のあったものすべて

この表があれば、担当者が変わっても同じ数え方で報告が続きます。 逆にこの表を作らずに始めると、プログラムの中に荷主ごとの例外が書き込まれ、誰も全体を説明できない集計になります。

前年同月の件数は、確定した報告から取ります。 台帳を数え直すと、後から足された事故が入って前年の報告と数字が合わなくなります。荷主の手元にあるのは前年の報告の数字です。

AIへ渡す前に整形する

1. 荷主ごとの絞り込み … 出荷の実績・事故・配送の完了の記録を荷主ごとに分けます
2. 件数と率の計算 … 種別ごとの件数と、荷主の分母（件数・行数・個数）で率を計算します。率は荷主の様式に合わせ、100万件あたりなどの単位にします
3. 遅延の判定 … 荷主の定義で、配送の完了の記録を遅延とそうでないものに分けます
4. 比較の計算 … 前月・前年同月との増減を計算します
5. 主な事故の選定 … 荷主の設定に従い、重さ・損害の額・荷主からの申し出の有無で、報告で説明する事故を選びます
6. 届け先の情報の除去 … 事故の経緯にある届け先の氏名・住所・電話番号を取り除きます
7. 差し込み記号の表の作成 … 計算した値ごとに misship_count のような記号を付けた表を作ります

2番目から4番目の結果は、この段階で確定させます。 AIには差し込み記号の名前と意味だけを渡し、値そのものは渡しません。 値を渡すと、AIはその値を本文に書き写し、表と本文で桁や丸め方が違う報告ができます。

6番目は、通信販売の荷主で特に大事です。 誤出荷の経緯には「◯◯様宛の商品を△△様に送った」のような記述が入りがちです。荷主への報告に、届け先の個人の情報は要りません。

AIに処理させる

させるのは、集計の結果と事故の記録から、荷主に送る報告の説明文を書くことです。

3行目の「台帳に書かれていることだけ」が、この構成でいちばん効くところです。 AIには、原因の分析の文を言い換えるときも、原因の向き（人・手順・設備・表示・システム）を変えないよう指示します。「表示が見づらかった」を「作業者の確認不足」に書き換えると、荷主は人の教育を対策だと受け取ります。

1行目がいちばん起きやすい失敗です。 差し込み記号を使うよう指示しても、AIは文の流れで「2件」と書いてしまうことがあります。後段で本文に数字がそのまま書かれていないかを確かめ、見つかれば下書きを止めます。

指示内容を固定する

あなたは物流会社の品質管理の担当として、荷主に毎月送る品質報告の
説明文を書く立場です。
件数・率・増減の数字は、すでにプログラムが計算しています。
あなたの仕事は、その数字と事故の記録を、荷主が読んで分かる説明にすることです。

【書くもの】
1. overview ......... 今月の概況（2〜3文）
2. incidents ........ 主な事故ごとの経緯・原因・対策
3. previous_actions . 前月の報告で約束した対策の進捗

【厳守事項】
- 数字を本文に書かないでください。
  件数・率・増減・日付の数字は、【差し込み記号】の記号を {misship_count} の形で
  書いてください。記号の表に無い数字は書かないでください。
- 原因は、【事故の記録】の cause_analysis に書かれていることだけを書いてください。
  言い換えるときも、原因の向き（人・手順・設備・表示・システム）を変えないでください。
- cause_analysis が空の事故は、原因を「調査中」とし、status を cause_pending にしてください。
  ありそうな原因を書かないでください。
- 対策は countermeasure と due に書かれたものだけを書いてください。
- 責任の所在、損害の賠償、運送約款や契約の解釈に触れないでください。
- 作業者や配送の担当者の氏名を書かないでください。
- 荷主を責める書き方や、言い訳に読める書き方をしないでください。
- 各文に、根拠にした事故の記録の incident_id を付けてください。

【荷主の情報】{shipper_profile}
【差し込み記号（記号と意味。値は渡しません）】{placeholders}
【事故の記録】{incidents}
【前月に約束した対策と台帳の状況】{previous}
【報告の様式の決まり】{format_rules}

「値は渡しません」と記号の表に書いておくのは、AIが値を推測して書くのを防ぐためです。 値を渡さなければ、AIには書き写す数字がありません。数字が本文に現れたら、それはAIが作った数字だと分かります。

「荷主を責める書き方をしない」を入れているのは、荷主の側の事情が原因の事故もあるからです。 出荷の指示の誤りや、荷姿の問題が原因なら、それは台帳の原因の分析にそう書かれています。事実として書くことと、責める書き方をすることは別です。

出力形式を固定する

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

{
  "shipper_code": "",
  "period": "",
  "overview": [
    { "text": "", "placeholders_used": [""] }
  ],
  "incidents": [
    {
      "incident_id": "",
      "category": "misship | damage | delay",
      "background": "",
      "cause": "",
      "countermeasure": "",
      "status": "ready | cause_pending | needs_input"
    }
  ],
  "previous_actions": [
    { "action_id": "", "progress": "", "status": "ready | needs_input" }
  ]
}

1つ目の理由は、差し込みと照合ができることです。 placeholders_used に挙がった記号が記号の表にあるかを確かめ、本文に記号以外の数字が無いかを確かめてから値を差し込みます。

2つ目は、原因の照合ができることです。 incident_id ごとに、cause と台帳の原因の分析を並べて担当に示します。プログラムは、原因の向きを表す語（表示、手順、設備、システム、作業者など）が台帳と本文で一致しているかを見て、違えば印を付けます。

3つ目は、status で担当の作業が分かることです。 cause_pending と needs_input の事故だけを先に見れば、送る前に埋めるべき箇所が一覧になります。

構造化出力のスキーマでは、公式のページにあるとおり、すべての項目を必須にし、additionalProperties: false を設定します。 主な事故が無い月は、incidents を空の配列で返させます。

差し込みを終えた本文は、たとえば次のようになります。

【今月の概況】
今月の誤出荷は2件で、前月から3件減りました。出荷100万件あたりでは12.4件です。
破損は1件、遅延は0件でした（遅延は、お取り決めの指定時間帯の到着で数えています）。

【主な事故】誤出荷（隣接ロケーションの類似品の取り違え）
経緯：同じ棚の上下段に、色違いの同じ形の商品が保管されていました。
原因：棚の表示が商品名だけで、色の区別が表示されていませんでした。
対策：棚の表示に色の区別を加えます（今月末まで）。

システムへ連携する

事故の台帳には書き込みません。 原因の分析や対策の状況を直すのは、品質管理の担当が台帳で行います。報告書の側で原因を直したら、台帳も同じように直す運用にし、報告と台帳がずれないようにします。

荷主へ送るのは人です。 送り方は荷主ごとの取り決め（メール、荷主の取引先向けの仕組みへの登録など）に従います。下書きを自動で荷主へ送る経路は作りません。

人が確認する

品質管理の担当が、照合で印の付いた箇所から読みます。

1. cause_pending を確かめる … 原因の分析がまだの事故です。報告の送付までに分析が終わるなら台帳を埋めて作り直し、終わらないなら「調査中」と報告の予定日を書きます
2. 原因の向きの印を確かめる … 台帳と本文で原因の向きが違うと判定された文です。台帳の言葉に戻します
3. 数字を表と見比べる … 差し込みが正しく入っているかを、表と本文で一度だけ見ます
4. 前月の対策の進捗を確かめる … 台帳の状況が更新されていない対策は、現場に確かめます
5. 全体を荷主の目で読む … 言い訳に読める文、荷主を責めるように読める文を直します

センター長は、主な事故の説明と対策が、荷主に約束してよい内容かを見ます。 対策の期限は、そのまま荷主との約束になります。設備の改修のように予算の要る対策は、社内で決まる前に期限を書かないでください。

目標は、60件をならして1件30分です。 事故の無い荷主は数分で確認が終わり、事故の多い荷主に時間を使います。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、記録のそろい方と設定の問題です。 下書きを止めた理由は、荷主ごとに一覧に残して担当へ知らせます。 配送の完了の記録が遅れる配送の会社があるなら、取り込みの日をその会社に合わせます。

記録を残す

• 取り込んだ出荷の実績・事故の台帳・配送の完了の記録の版
• 計算した件数と率、差し込み記号の表、使った荷主の設定の版
• AIへの入力と出力のJSONの全文
• 担当とセンター長が直した差分 … どの事故の、どの欄を、どう直したか
• 荷主へ送った報告の確定版と、送った日
• 原因の向きの印が付いた文の件数と、直された件数

2つ目で「荷主の設定の版」を残すのは、遅延の定義が途中で変わることがあるためです。 定義が変われば前年同月との比較の意味も変わります。どの定義で数えたかが残っていないと、荷主から問われたときに説明できません。

最後の行は、台帳の付け方を直す材料になります。 印が多く付く事故の種別は、台帳の原因の分析の書き方が荷主向けの言葉とかけ離れています。 台帳の欄の分け方を見直す合図です。