倉庫の作業者から出る「この荷主の検品・梱包・ラベルの決まりは」の質問に、荷主ごとの作業仕様書と変更の連絡を根拠にチャットで答え、記載の無いものを現場の責任者へ回す

処理の起点を決める

起点は、作業者が作業台の端末で質問を送ったことです。 端末は、センターの社内の ID でログインした作業者とリーダーだけが使い、荷主の担当者は使いません。 送信の前に、作業指示書のコードを読むか、荷主の一覧から選ぶ操作を必ず入れます。

荷主と出荷先の種類は、作業指示書のコードから確定させます。 作業指示書には荷主のコードと出荷の種類（個人宛て／店舗納品／ギフト）が印字されているので、それを読んだ値をそのまま絞り込みに使います。 コードが読めないときだけ、荷主の一覧から選ばせます。

質問の区分を先に選ばせます。 「検品」「梱包」「ラベル」「同梱物」「その他」の5つで、区分が分かると探す章が狭まり、答えの形もそろいます。 1件の質問は1つのセッションで続け、「店舗納品ならどうか」と聞き足すと同じセッションで絞り直します。別の作業指示書に移ったら、新しいセッションで始めます。

入力データを集める

質を決めるのは、文書ごとのメタデータです。 文書ごとに、荷主のコード、文書の種類（仕様書／変更の連絡／別表）、出荷先の種類、適用開始日、適用終了日、受け取った日を付けます。受け取った日と適用開始日は別の項目にします。 第3章の（b）は、メールの日付で掲示を差し替えることから起きます。

変更の連絡は、メールの本文をそのまま文書にします。 「件名」「送信者」「受け取った日」を残し、本文から適用日と対象の範囲を書き出してメタデータにします。 仕様書に反映された時点で、その変更の連絡の適用終了日を仕様書の改訂日の前日にし、同じ決まりが2か所から引かれないようにします。

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

文書は Cloud Storage に置き、メタデータ付きでデータストアへ取り込みます。 作業仕様書は PDF か Word、別表は Excel で持っていることが多いので、表と写真を残せる形式で入れます。 レイアウトの解析は PDF・HTML・DOCX・PPTX・XLSX・XLSM の配置を検出し、表と見出しを見分けます。

絞り込みの式は、荷主・出荷先の種類・今日の日付で書きます。 項目を索引可能にしておけば、shipper_id: ANY("C0412") AND ship_type: ANY("store", "all") AND valid_from <= "2026-10-08" AND valid_to >= "2026-10-08" のように、その荷主の、その出荷先の種類に当たる、今日効いている版を引けます。all は出荷先の種類によらない決まりです。

荷主のコードと日付は、中継プログラムが式に入れます。 モデルにも作業者にも書かせません。今日の日付は端末の時計ではなく、中継プログラムの側で決めます。

AIへ渡す前に整形する

1. 荷主ごとに文書を集める … 作業仕様書、品番の別表、資材の一覧を、荷主のコードの付いた場所に置きます
2. 仕様書を版ごとに分ける … 改訂のたびに上書きされた仕様書は、版ごとに別のファイルにして期間を付けます
3. 変更の連絡を文書にする … メールの本文を1通ずつ文書にし、適用日と対象の範囲を書き出します
4. 出荷先の種類を付ける … 章ごとに個人宛て・店舗納品・ギフトのどれの決まりかを書き分けます
5. 写真を残す … ラベルの位置や梱包の完成形の写真は、説明の文と同じページに置いたまま取り込みます
6. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします
7. 画像の注釈を有効にする … 写真の説明がその断片に付くよう、作成時に画像の注釈を有効にします

3番目は、荷主の窓口の担当が受け取った日のうちに入れます。 変更の連絡の書き方は荷主ごとにばらばらで、「次回入荷分から」としか書かれていないこともあります。 適用日が読み取れないものは空にせず、窓口の担当が荷主に確かめて埋めます。

6番目と7番目は、データストアを作る前に決めます。 分割はデータストアの作成後に有効にも無効にもできず、見出しを含める設定は既定では無効です。 「1点ずつ OPP 袋に入れる」の断片は、見出しが無いと店舗納品の決まりか個人宛ての決まりか分かりません。 画像の注釈を有効にすると、検出された画像の説明と画像そのものがその断片に割り当てられ、写真のページが根拠として引かれやすくなります。

AIに処理させる

させるのは、その荷主の文書から質問に当たる決まりを見つけ、決まった項目に分けて、根拠のページと適用日付きで並べることです。 記載の無い作業の扱いを決めることと、作業の良し悪しを判断することはさせません。

answer メソッドの設定は次のようにします。

3行目がいちばん起きやすい失敗です。 指定の緩衝材が切れているときに「代わりにエアキャップを使ってよいか」と聞かれると、モデルは一般的な梱包の考え方で「使えます」と書きがちです。資材の指定は荷主が売場や開封のしやすさで決めているもので、代えてよいかは荷主にしか決められません。 記載が無ければ「記載が見つからない」で止め、リーダーへ回します。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは物流センターで、出荷の作業をしている作業者を手伝う立場です。
選ばれた1社の荷主の作業仕様書、変更の連絡、品番の別表から、
質問された作業の決まりを探します。読むのは作業台にいる作業者です。

【答え方】
1. 最初の1行で、決まりを短く書いてください（例：全数検品。シリアル番号を読む）。
2. 次に、対象の範囲（全品番か、特定の品番・出荷先の種類か）と、
   品番の別表にある例外を書いてください。
3. 根拠にした文書の種類（仕様書／変更の連絡／別表）とページ、
   変更の連絡の場合は適用開始日を書いてください。
4. 写真のページがあれば、そのページを示してください。
5. 作業者が読む文なので、短い文で、専門用語には言い換えを添えてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  他の荷主の決まりや、一般的な梱包・検品のやり方で補わないでください。
- 文書に記載が無い作業は「記載が見つからない。リーダーに確認」とし、
  してよい・しなくてよいを書かないでください。
- 資材や方法を、指定と違うものに代えてよいと書かないでください。
- 仕様書と変更の連絡で決まりが食い違うときは、どちらが正しいかを決めず、
  両方を並べて「リーダーに確認」と書いてください。
- 変更の連絡を受け取った日を、適用開始日として扱わないでください。

「一般的なやり方で補わない」を書くのは、補った答えのほうが自然に見えるからです。 検品の方法を聞かれて仕様書に記載が無いと、モデルは「通常は抜き取りで行います」と書きます。作業者にとって、それは荷主の決まりと区別がつきません。 根拠の無い文を1行も出さないことが、作業者が答えを信じて使える条件です。

「受け取った日を適用開始日として扱わない」も、明記しないと崩れます。 変更の連絡の冒頭にはメールの日付があり、適用日は本文の途中にあります。何も言わなければ、目立つほうの日付を使います。 絞り込みの式でも適用日で絞っていますが、答えの文に書く日付も適用日にそろえます。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、端末と記録に渡します。

{
  "query_id": "",
  "session_id": "",
  "worker_id": "",
  "shipper_id": "C0412",
  "ship_type": "store",
  "category": "inspection | packing | label | enclosure | other",
  "question": "",
  "rule_summary": "",
  "scope": "",
  "exceptions": [""],
  "photo_refs": [ { "uri": "", "page": 0 } ],
  "refs": [ { "doc_type": "spec | change_notice | sku_table",
              "location": "", "valid_from": "", "received_on": "",
              "uri": "", "grounding_score": 0 } ],
  "not_found": false,
  "conflict": false,
  "change_soon": false,
  "status": "answered | routed | skipped",
  "leader_reply": { "leader_id": "", "answer": "", "asked_shipper": false }
}

1つ目の理由は、rule_summary を1行で持てることです。 端末の画面は小さく、作業者は手袋をしたまま読みます。最初の1行で決まりが分かり、根拠は下に並べます。

2つ目は、not_found と conflict で回し先を機械的に決められることです。 どちらかが true なら、端末には「リーダーに回しました」とだけ出し、決まりの文は出しません。 根拠の無い答えを、作業者が読む画面に残さないためです。

3つ目は、change_soon で変更の前後を知らせられることです。 中継プログラムは、今日から7日以内に適用開始日を迎える変更の連絡がその荷主にあるかを別に調べ、あれば change_soon を立てて「○日出荷分から変わります」を添えます。 適用日の前に新しい決まりを当てる失敗と、適用日を過ぎても古い決まりで梱包する失敗の両方を減らします。

システムへ連携する

WMS には、つなぎません。 作業指示書のコードから荷主と出荷先の種類を読むだけで、出荷の指示や検品の結果を書き換える経路を作りません。 誤った答えが、そのまま出荷のデータに流れるのを防ぎます。

変更の連絡の取り込みは、自動にしません。 荷主の窓口のメールには、作業の決まり以外の連絡（入荷の予定、在庫の照会）も混ざります。どれを決まりとして取り込むかは、窓口の担当が決めます。 取り込んだ連絡は、その日のうちにリーダー全員の端末に「○○の決まりが変わります」と知らせます。

人が確認する

作業者は、答えが出たときに根拠のページを開いて確かめます。 画面の1行だけで作業を変えない運用にします。

1. 荷主と出荷先の種類を確かめる … 画面の上に出る荷主と出荷先の種類が、作業指示書と合っているかを見ます
2. 根拠のページを開く … 写真のページがあれば、完成形と見比べます
3. 変更の予告を読む … change_soon が出ていれば、今日の出荷が変更の前か後かを確かめます
4. リーダーに回ったものは待つ … 自分の判断で進めません

リーダーは、回ってきた質問に答え、答えを記録に残します。 記載の無い作業の扱いをその場で決めたときは、現場の責任者が荷主に確かめ、荷主の了解が取れたら変更の連絡として取り込みます。 その場の判断のまま続けると、同じ質問が別のリーダーに別の答えで返ります。

目標は、600件をならして1件3分です。 答えが出て根拠を確かめるだけなら1〜2分、リーダーに回るものは確かめて答えるので10分前後かかります。リーダーに回るものが1割強という想定でならすと3分です。

例外に対処する

2行目と3行目は、運用の最初の数か月に集中します。 変更の連絡の取り込み漏れと、仕様書に反映した後の古い連絡の閉じ忘れが、そのまま答えの穴と食い違いとして出てきます。 落ちた答えと食い違いを荷主ごとに数えると、どの荷主の文書から直すべきかが分かります。

記録を残す

• 質問の文、区分、荷主のコード、出荷先の種類、作業者、日時、セッションの ID
• 絞り込みの式と、answer メソッドの応答の全文（出典と根拠のスコアを含む）
• 整えた答え（rule_summary、refs、not_found、conflict、change_soon）
• そのとき参照した文書の版（文書の ID と valid_from・valid_to）
• リーダーの回答と、荷主に確かめたかどうか
• 誤出荷の報告があったときの、該当する出荷の作業指示書と質問の記録の対応

4つ目で「そのときの版」を残すのは、誤出荷の後で荷主から問い合わせが来るためです。 「この日の出荷はどの決まりで梱包したのか」と聞かれたとき、当時効いていた仕様書と変更の連絡を、検索の記録から示せます。

最後の行は、答えの質を測る材料になります。 誤出荷の報告と質問の記録を突き合わせ、質問したのに誤ったのか、質問せずに誤ったのかを分けます。前者は文書か答えの問題、後者は運用の問題です。