倉庫の保管場所を出荷実績から見直して、取り出しの短い配置案を出す

処理の起点を決める

毎月1日に動かします。 出荷の傾向は1日では変わりませんし、棚札の張り替えとシステムの更新を伴う以上、配置は毎日変えられません。

月初にする理由は2つあります。前月末までの出荷実績がそろうこと、そして移動作業を当月の作業計画に組み込めることです。

例外として、大型の販促や新規取引が決まったときのために、ゾーンを指定した手動起動を用意します。対象は指定したゾーンだけに限ります。

入力データを集める

この構成の質を決めるのは、上から4つ目の棚の条件です。 出荷実績とロケーションは倉庫管理システムに必ずありますが、耐荷重と温度帯は表としてそろっていないことがほとんどです。整っていないとAIは制約を「不明」と返すしかなく、人の確認時間は減りません。

出荷明細は、伝票番号を落とさずに取ります。 集計済みのデータでは第3章の（b）と同じ状態になり、一緒に出る品目を数える手立てが無くなります。

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

読み取り専用のビューまたはCSV出力を用意し、月初の未明に1回だけ取得します。期間は直近24か月です。次の3か月を見るのに使うのは直近12か月ですが、前年の同じ時期と比べるために、その前の12か月も要ります。

棚の条件のExcelは、列名と並びを固定して読み込みます。更新日の列を持たせ、更新が3か月以上前なら警告を出します。 古い表のまま計算すると、入らない間口を提案し続けることになります。

取得したデータは、ゾーン単位に分けて保持します。 ゾーンは通路のまとまりで、常温・定温・冷蔵の区画をまたぎません。区画をまたぐ移動はそもそも提案の対象外なので、最初から分けておけば、ありえない案が出る経路を閉じられます。1回の取得は数十万行、AIへの1回の投入は数十件が目安です。

AIへ渡す前に整形する

この構成では、数える仕事とAIの仕事を分けます。 数えるほうはプログラムで行い、計算式を残します。以下は本記事が設定する手順で、区切りの値、歩行速度、1パレットあたりの移動時間は、倉庫ごとに実測して決めてください。

まず、品目ごとに5つの値を計算します。

1. 出荷頻度 … その品目が現れた出荷伝票の数 ÷ 対象月数 ＝ 月あたりの取り出し回数
2. 出荷数量 … 対象期間の出荷数量の合計 ÷ 対象月数 ＝ 月あたりの出荷数量
3. 同時出荷回数 … 品目Aと品目Bが同じ伝票番号に並んだ伝票の数。明細を伝票単位で走査して数えます
4. 現在地の往復距離 … 通路の入口を起点に、通路番号と間口番号から片道の距離を求め、2倍します
5. 移動の見積もり時間 … （移動するパレット数 × 1パレットあたりの移動時間）＋ 棚札の張り替え時間 ＋ システム上のロケーション変更の時間

次に、区分を作ります。直近12か月の出荷伝票数で降順に並べ、累積構成比が70％までをA、70％から90％までをB、残りをCとします。 同じ区切りで出荷数量の側の区分も作り、2つを並べて持ちます。数量が多くても伝票数が少ない品目は、取り出しの回数が少ないからです。手前・腰の高さに置く候補になるのは、伝票数のAです。

次に、3か月先の見込みを出します。ここが「予測」にあたる部分です。

• 伸び率 ＝ 直近3か月の月平均伝票数 ÷ 直近12か月の月平均伝票数
• 季節係数 ＝ 前年の同じ3か月の月平均伝票数 ÷ 前年12か月の月平均伝票数
• 見込み伝票数 ＝ 直近3か月の月平均伝票数 × 季節係数

見込みの区分が現在の区分と違う品目だけが、見直しの対象に上がります。 これが月200件の中身です。見込みは配置の優先順位を決めるための目安であり、数字そのものを当てにいくものではありません。 どの程度合うかは品目によって異なります。

最後に、効果を見積もります。

• 月間歩行距離 ＝ 見込み伝票数 × 現在地の往復距離
• 削減距離 ＝ （現在地の往復距離 － 提案先の往復距離）× 見込み伝票数
• 回収の目安（月数）＝ 移動の見積もり時間 ÷（削減距離 ÷ 歩行速度）

回収の目安が、（d）への答えです。 月に2回しか出ない品目を手前に動かす提案は削減距離が小さく、回収の目安が何十か月にもなって、一覧の下のほうへ自然に落ちます。

AIに処理させる

AIに数を数えさせません。 出荷頻度も距離も移動時間も、計算式が決まっている以上プログラムで出せます。計算させると検算ができなくなり、案の信用が一度で落ちます。

AIにさせるのは3つです。①棚の条件と品目の寸法・重量・温度帯を突き合わせ、候補の間口に入るかを判断する ②文章で書かれた運用メモを読み、そこにある制約を拾う ③なぜ動かすのかを、数字を根拠に文章にする。

指示内容を固定する

あなたは倉庫の保管場所の見直しを支援する立場です。
渡された数値は集計済みです。自分で計算し直さないでください。

【渡すもの】品目コード、寸法、重量、温度帯、危険物の区分、現在のロケーション、
見込み伝票数、区分の変化、移動の見積もり時間、削減距離、同じゾーンの棚の条件と空き間口の一覧、
現場の運用メモ。

【判断の手順】
1. 品目ごとに、候補の間口を上から順に見て、
   寸法・耐荷重・温度帯・危険物の4つを1つずつ確かめてください。
2. 4つすべてが問題なければ proposed_location に間口を書いてください。
3. 1つでも合わないときは proposed_location を null にし、
   blocked_by に「どの制約が、どう合わないか」を書いてください。
4. 運用メモにその品目や棚への記載があれば、必ず読んで判断に含めてください。

【厳守事項】
- 渡されたデータに記載が無い項目は「不明」としてください。
  寸法、耐荷重、温度帯、危険物のいずれかが分からない品目や棚は、
  constraints_checked の該当項目を unknown にし、
  needs_human を真にして、何が分からないかを note に書いてください。
  分からない値を、似た品目や近くの棚から補わないでください。
- move_minutes と expected_gain は、渡された値をそのまま書いてください。
  四捨五入も、単位の変換も、概算への言い換えもしないでください。
- reason には、なぜ動かすのかを渡された数値を挙げて書いてください。
  「効率が上がる」「最適化される」とだけ書いてはいけません。
  何％短くなる、何割改善する、といった割合を書かないでください。
- priority は次の基準で付けてください。
  5 = 見込み伝票数が多く、回収の目安が3か月以内
  3 = どちらかが当てはまる
  1 = 回収の目安が12か月を超える
  基準に当てはめられないときは3にし、その理由を reason に書いてください。
- 移動の作業手順、実施日、担当者を書かないでください。

【ゾーン】{zone}
【見直し対象】{items}
【棚の条件と空き間口】{locations}
【現場の運用メモ】{notes}

「記載が無ければ不明とする」を独立した項目にしているのは、ここが最も埋められやすいからです。 棚の耐荷重が空欄のとき、同じ通路の別の棚の値を持ってくる、という補い方をされると、出力は自然に見えるのに現場で棚がたわみます。 不明のまま返れば、人はその棚を測りに行けます。

優先度の定義を指示文に書いているのは、スキーマだけでは足りないからです。 minimum と maximum は1から5の外を防ぎますが、全件が5になることは防げません。 何を5とするかは、この文章の側で決めます。

出力形式を固定する

レスポンス形式に MIME タイプ application/json と、次のスキーマを指定します。

{
  "type": "object",
  "properties": {
    "zone": { "type": "string" },
    "generated_for": { "type": "string", "format": "date" },
    "proposals": {
      "type": "array",
      "maxItems": 60,
      "items": {
        "type": "object",
        "properties": {
          "item_id": { "type": "string" },
          "current_location": { "type": "string" },
          "proposed_location": { "type": ["string", "null"] },
          "priority": { "type": "integer", "minimum": 1, "maximum": 5 },
          "reason": { "type": "string" },
          "constraints_checked": {
            "type": "object",
            "properties": {
              "weight": { "type": "string", "enum": ["ok", "ng", "unknown"] },
              "size": { "type": "string", "enum": ["ok", "ng", "unknown"] },
              "temperature": { "type": "string", "enum": ["ok", "ng", "unknown"] },
              "hazardous": { "type": "string", "enum": ["ok", "ng", "unknown"] }
            },
            "required": ["weight", "size", "temperature", "hazardous"],
            "additionalProperties": false
          },
          "blocked_by": { "type": ["string", "null"] },
          "move_minutes": { "type": "number", "minimum": 0, "maximum": 480 },
          "expected_gain": { "type": "number", "minimum": 0 },
          "needs_human": {
            "type": "object",
            "properties": {
              "flag": { "type": "boolean" },
              "note": { "type": "string" }
            },
            "required": ["flag", "note"],
            "additionalProperties": false
          }
        },
        "required": ["item_id", "current_location", "proposed_location", "priority",
          "reason", "constraints_checked", "blocked_by", "move_minutes",
          "expected_gain", "needs_human"],
        "additionalProperties": false
      }
    }
  },
  "required": ["zone", "generated_for", "proposals"],
  "additionalProperties": false
}

構造化する理由の1つ目は、ありえない数値を構造で止めることです。 優先度に minimum: 1 と maximum: 5 を、移動時間と削減距離に minimum: 0 を指定しているため、0や9の優先度も、負の移動時間も返ってきません。 制約の確認結果を enum で3つに限っているのも同じで、「おおむね問題なし」という中間の答えが入りません。

2つ目は、blocked_by を持たせるためです。 「動かせない」も答えとして価値があります。理由が記録に残らなければ、翌月も同じ品目が候補に上がります。 保存しておけば次回の集計で外せます。動かせる場合は null を返すため、type を配列で書いて null を許しています。

3つ目は、優先度の順に並べ替えて現場に渡せることです。文章で返ってくると、この並べ替えが人の作業に戻ります。

maxItems を60にしているのは、非常に大きい、または深くネストされたスキーマが拒否されることがあるためです。1ゾーンあたりの対象がこれを超えるときは、通路単位までさらに分けて回します。

システムへ連携する

最後の行を自動化しません。 配置案の確定と同時にシステムのロケーションを書き換えると、実際には動かしていない品目が、動いたことになります。

人が確認する

全件、人が確認します。確認せずに移動計画にする設計にしません。

1. 優先度の高い順に案を見る … reason に挙げられた数値と、move_minutes、expected_gain を見て、その移動を当月にやる価値があるかを判断します
2. 現場の事情を当てる … 作業導線、通路の幅、台車のすれ違い、応援の人が入りやすいかどうか。この4つはデータに無く、人にしか分かりません
3. needs_human が真の案を先に見る … 制約が unknown の品目は、棚か品目のどちらかを実際に測りに行く必要があります

2番目が、この構成の中心の作業です。 機械は距離を計算し、AIは寸法と温度帯を照合しますが、「そこに置くと台車が止まる」は図面にも実績にも出てきません。 そこに担当者の時間を使うのがねらいです。

確認の目標は1件3分です。 それ以上かかるなら、reason に数値が入っていないか、unknown が多すぎます。unknown が多い場合に直すのは、指示文ではなく棚の条件の表のほうです。

例外に対処する

4行目を軽く見ないでください。 渡した数値が書き換わることがあり、そのまま現場に出ると「AIの出した数字は当てにならない」という評価が定着します。

記録を残す

• 集計に使った期間、行数、品目数、ゾーンごとの対象件数
• 品目ごとの計算結果（出荷頻度、同時出荷の組み合わせ、往復距離、移動の見積もり時間、回収の目安）
• AIへ渡した入力と、返ってきたJSONの全文
• 担当者が見送った案と、その理由（とくに現場の事情によるもの）
• 実際に移動した品目、移動日、移動前後のロケーション
• 移動後3か月の、その品目の出荷伝票数と往復距離

4つ目と6つ目が、この構成を育てる材料です。 見送りの理由が同じ言葉で何度も出てくるなら、それは制約として表に入れるべきものです。