【2026年最新】物流倉庫シフト最適化Claude Code

はじめに:「ベテランの頭の中」が消える日

正直、最初にこのテーマに取り組んだのは、知り合いの3PL事業者からの「うちのシフト責任者が来年退職する。後任が引き継げない」という相談からだった。Excel と紙のシフト表を見せてもらったら、20年勤続のベテランが「この時期は田中さんが入った方が捌ける」「鈴木さんと佐々木さんは同じ便に入れたくない」といったメモを欄外に書き込みながら毎週12時間かけて作っていた。

これを Claude Code で再現できるか、という相談だった。答えは「シフト表そのものは7-8割再現できる。残り2-3割の暗黙知は構造化が必要」。本記事では、その「7-8割を仕組み化する」プロセスを、データ・フレームワーク観点で深掘りする。

物流倉庫のシフト管理は、表面上は「Excel で時間と名前を埋める単純作業」に見える。しかし実態はまったく違う。入出庫量の変動、フォークリフトや荷捌き機械の稼働可能台数、有資格者の配置、夜勤要員の確保、希望休、急な欠勤、繁忙期のスポット応援、派遣会社との単価交渉、社会保険の壁、36協定の上限まで、20を超える変数が同時に動く意思決定問題だ。これを属人化したまま回している現場が、いま全国に何千とある。

そして、ベテラン1人に依存している現場ほど、その1人が辞めたら回らなくなる。後任が「同じレベルでシフトを組める」までに、現実的には1-2年の見習い期間が必要で、その間の品質低下と労務リスクは経営的に小さくない。本記事は「ベテラン依存からの脱却」を、シフト最適化問題として工学的に分解し直す試みである。

なお、本記事の人件費・残業時間・エラー率の数値は、複数の3PL事業者の現場ヒアリングをもとにした想定例である。実際の数値は事業所ごとに大きく異なるため、自社データで検証してほしい。最終的なシフト決定は現場責任者と社労士の判断であり、Claude Code はあくまで設計補助のツールとして位置づける。本記事に登場する企業名・人物名はすべて仮名であり、具体的なクライアントの情報は含まない。

H2-1: 物流倉庫シフト最適化の4軸フレームワーク

物流倉庫の人員シフトを「最適化問題」として定式化するときに必ず登場する4軸を整理しておく。この4軸を Claude Code に最初に共有することで、その後のコード生成精度が劇的に変わる。

軸1: 需要側(入出庫量予測)

シフト最適化のすべての起点は「いつ、どれくらいの物量が動くか」である。ここを外すと、どれだけ精緻な制約モデルを組んでも結果は使い物にならない。需要側の入力は以下の3粒度で持つのが筋がいい。

• 日次粒度: 過去2-3年の入庫件数・出庫件数・ピッキングライン数。曜日効果・月末月初効果・季節性を分解可能
• 時間帯粒度: 1日を1-2時間刻みで分解。トラックバースの到着スロット、配送便の締め時刻と紐づける
• イベント粒度: セール、決算棚卸、新商品入荷、年末年始、お盆。カレンダー特徴量として明示的に持つ

ここで重要なのは「予測精度に過度に依存しない設計にする」という点だ。後述するが、予測の不確実性をシフト側で吸収する「変動枠(派遣・スポット)」を必ず確保する。

さらに、需要側のデータには「物量だけでは見えない難易度」が存在する。たとえば同じ100パレットでも、軽量・小ロットのアパレル雑貨と、重量・特殊扱いの建材では、必要な人時係数が3-5倍違う。品目特性(SKU属性)、ロット構成(大口/小口の比率)、特殊扱い(温度管理・危険物・割れ物)を需要モデルの説明変数に組み込まないと、繁忙期に予測が外れる。Claude Code に最初に渡すデータには、入出庫件数だけでなく品目分類フラグも入れておくと、後段の精度が大きく変わる。

もう1つ盲点になりやすいのが「戻り(返品・誤配送リワーク)」である。EC物流では出庫量の3-8%が翌週以降に返品として戻ってくる。これを別軸でカウントしないと、検品ラインの必要人時を読み違える。返品処理は新規入庫と作業フローが違うため、専用の必要人時係数を持つべきだ。

軸2: 供給側(スキル・雇用形態マトリクス)

人員側は「誰でも同じ仕事ができる」前提で組むと現場で破綻する。スキルと雇用形態をマトリクスで持つ。

スキル/雇用形態	正社員	パート(週20h以下)	派遣(短期)	スポット(単発)
フォークリフト	○(全員)	△(資格者のみ)	○(指定派遣)	×
ピッキング	○	○	○	○
検品・梱包	○	○	○	△(教育要)
夜勤対応	○(輪番)	×(原則不可)	○(夜勤指定)	×
主任業務(シフトリーダー)	○(限定)	×	×	×

このマトリクスは Claude Code に渡すときに JSON ないし YAML で持っておくと制約モデルへの変換が高速化する。

もう1つ、スキルマトリクスに必ず入れるべきカラムが「習熟段階」と「教育コスト」である。新人がフォーク資格を取得しても、実際に倉庫オペレーションで即戦力になるまでには通常3-6ヶ月かかる。この「習熟スロープ」を計画に織り込まないと、退職者が出た直後に必要スキル充足率が一気に落ちる。新人が独り立ちするまでの期間は、誰かが教育のために手を止める時間にもなる。この「教育時間」を裏側のコストとして必要人時から差し引いて計算しないと、シフトが理論値どおりに回らない。

派遣スタッフのスキル評価も同様に重要だ。同じ派遣会社からの派遣でも、毎回違う人が来る短期派遣と、3ヶ月以上同じメンバーが入る長期派遣ではスキルが大きく違う。マトリクスを作るときは「派遣A社・長期メンバー」「派遣A社・短期スポット」「派遣B社・夜勤専門」のように細分化すべきだ。これを区別せずに「派遣」とひとくくりにすると、必要人時の係数が大きく外れる。

軸3: 制約(労基法 + 社内規程)

労働基準法と社内規程は「ハード制約(絶対に破れない)」として最優先で組み込む。代表的なものを列挙する。

• 労基法第32条: 法定労働時間 1日8時間、週40時間
• 労基法第34条: 6時間超で45分、8時間超で60分の休憩
• 労基法第35条: 週1日または4週4日の休日
• 労基法第36条(36協定): 時間外労働 月45時間・年360時間(特別条項あり)
• 労基法第37条: 深夜(22時-翌5時)25%以上の割増賃金
• 連続勤務日数: 社内規程で多くは6日上限
• 勤務間インターバル: 努力義務(11時間推奨)、夜勤明け→翌日勤務の防止

これらは「条件を満たさないシフトは生成不可」とする。後でフェアネスとトレードオフされる「ソフト制約」と明確に分ける。

労基法以外で、社内規程として明示的に書き出すべきハード制約をいくつか挙げる。深夜帯(22時-翌5時)の最小人員(防犯・労災対応で1人作業を避ける)、フォークリフト同時稼働の上限(通路の幅で物理的に決まる)、女性専用ロッカーの収容数、社用車の台数、休憩室の同時利用人数。これらは「ソフトに緩めても良いか」と聞かれて「絶対ダメ」と返ってくるものはすべてハード制約に入れる。Claude Code に書かせるとき、最初に constraints.yaml でこれらを宣言的に持っておくと、後でルール追加が容易になる。

また、改正労基法で2024年4月から適用された「医師・建設・運送業の時間外労働上限の特例」など、業種別の例外規定がある。トラックドライバーを兼任している倉庫スタッフがいる場合、ドライバー側の拘束時間規制(改善基準告示)も同時に守る必要がある。シフトを設計するときに、複数の労務規制を同時にチェックする仕組みを最初に入れておくべきだ。

軸4: フェアネス(ソフト制約)

ハード制約を満たした解の中で「より良い解」を選ぶための重み付け軸。これが現場の満足度を左右する。

• 夜勤回数の偏り(個人別・月別の標準偏差を最小化)
• 希望休の充足率(全員の希望提出に対する充足割合)
• 連続夜勤の回避(2連続まで、3連続は禁止)
• 固定パートナーの組み合わせ希望(主任Aと新人Bの組み合わせ等)
• 長距離通勤者の早番回避

フェアネスを目的関数の重みでチューニングするのが、このプロジェクトの腕の見せ所になる。

フェアネスは「数値化できない要素」も含むので、すべてを目的関数に乗せるのは無理がある。たとえば「子育て中のメンバーは早朝枠を希望」「介護中のメンバーは夜勤回避」「持病で重量物を持てない」といった個別事情は、ラベル化して制約として扱う。これらは「ソフト制約に近いハード制約」として、ペナルティを極端に重くした目的関数項で扱うか、最初からハード制約に分類するかを、現場のリーダーと相談して決める。

もう1つ重要なのは「フェアネス指標の透明性」だ。シフトが出来上がった後、なぜAさんが夜勤4回でBさんが2回なのか、その理由が説明できる状態にしておく必要がある。Claude Code で生成するシフトレポートには「個人別の制約適用ログ」を必ず添付させる。たとえば「Bさんは希望休3日と通院日2日が制約に入っており、これらを除外した結果、夜勤可能枠が少なくなった」のように、結果に至った経緯を可視化することで、現場の不公平感を抑えられる。

H2-2: 必要人時マトリクスを Claude Code で組み立てる

4軸が揃ったら、最初に作るのは「必要人時マトリクス(時間帯 × スキル × 必要人数)」である。これは入出庫予測から逆算して出す。

たとえば「朝9時の入庫便で 200パレット 到着 → フォークリフト2台 × 1.5時間 → フォーク有資格者3名必要」という換算を、過去実績から係数化する。Claude Code に過去半年の入出庫データと人員配置データを渡して、回帰でこの係数を出させると早い。

# prompt-1: 必要人時マトリクスの係数推定
あなたは物流倉庫のオペレーション分析エンジニアです。

【提供データ】
- 過去6ヶ月の日次入出庫実績(CSV): warehouse_volume.csv
  カラム: date, hour_slot, inbound_pallets, outbound_pallets, picking_lines, returns
- 同期間のシフト実績(CSV): shift_actual.csv
  カラム: date, hour_slot, role(forklift/picking/check/lead), headcount

【依頼】
1. hour_slot × role の単位で「物量1単位あたりの必要人時」係数を OLS で推定
2. 曜日効果(月-日)と月末月初フラグを説明変数に追加
3. 残差プロットと交差検証スコアを提示
4. 結果を JSON で出力: { "role": "forklift", "intercept": 0.x, "coef_inbound": 0.x, ... }
5. 「予測値に対して何%の安全係数を上乗せすべきか」を、過去の欠員発生率から逆算して提案

【出力ファイル】
- coefficients.json
- residual_plot.png
- cv_report.md (検証スコアと信頼区間)

各係数の物理的解釈(「フォーク1人時で何パレット捌けるか」)も併記してください。

このプロンプトの肝は「物理的解釈を併記」させること。係数だけ返すと現場責任者が納得しない。「フォーク1人時あたり7-9パレット」のように現場感覚と擦り合わせ可能な数字に翻訳させる。

係数推定で必ず発生するのが「外れ値の扱い」である。過去ログには、システム障害日・大雪・コロナ感染対応で人員が極端に少なかった日など、通常時から大きく外れる日が含まれている。これを除外しないで回帰すると、必要人時が過大or過小に推定される。Claude Code に渡すデータは、事前に「異常値日リスト(events.csv)」を作って渡すか、Robust regression(Huber損失等)を使うように指示するのが安全だ。

もう1つの落とし穴は「同時並行作業の効果」である。倉庫の作業は、入庫検品とピッキングが同じフロアで動いていると、通路で人が交錯して効率が落ちる。一方、入庫が落ち着いた時間帯にピッキングだけ動かすと、フォークも通路も自由に使えて効率が上がる。この「相互干渉」を線形モデルでは表現しきれないので、必要に応じて時間帯別に係数を出す、または相互作用項を入れる工夫が必要になる。Claude Code に対して、最初に「時間帯別の係数分割は許容するか」を聞いておくと、後で再実装にならない。

H2-3: 制約ソルバへの落とし込み(PuLP / OR-Tools)

係数が出たら、次は最適化問題として定式化する。物流シフトは典型的な「混合整数線形計画(MILP)」問題で、Python なら PuLP か Google OR-Tools が定番だ。Claude Code に書かせるときの肝は「目的関数とハード制約・ソフト制約を分離して書かせる」こと。

# prompt-2: シフト最適化モデルの実装
あなたは制約最適化の専門エンジニアです。Python と PuLP で、以下の物流倉庫シフト最適化モデルを実装してください。

【決定変数】
- x[i,d,s,r] ∈ {0,1}: 従業員i が 日d のシフトs(早番/日勤/遅番/夜勤) で 役割r を担当するか

【ハード制約】
1. 各日・各シフト・各役割の必要人数を満たす(coefficients.json から算出した必要人時)
2. 1人は1日に1シフトのみ
3. 週40時間以内、1日8時間以内
4. 6時間超勤務には45分休憩、8時間超には60分休憩
5. 連続勤務6日以内、週1日以上の休日
6. 夜勤翌日は休み or 遅番のみ(勤務間インターバル11時間)
7. パート従業員は夜勤不可、月間労働時間制限あり
8. フォークリフト有資格者の最低配置(各シフトに2名以上)

【ソフト制約(目的関数で最小化)】
- 夜勤回数の個人別偏り(標準偏差)
- 希望休との衝突件数
- 連続夜勤(2連続を超える)のペナルティ
- 派遣・スポット利用コスト(なるべく正社員・パートで埋める)

【入力ファイル】
- employees.yaml(従業員マスタ・スキル・希望休)
- demand_matrix.csv(必要人時マトリクス)
- constraints.yaml(社内規程)

【出力】
- shift_solution.csv(最終シフト表)
- objective_breakdown.json(目的関数の内訳)
- constraint_violations.md(緩和した制約があれば明記)

ソルバが解を見つけられなかった場合は、「どの制約を緩めれば解が出るか」を IIS(Irreducible Infeasible Subsystem) 検出で提示してください。

このプロンプトを投げると、Claude Code は PuLP の LpProblem として80-150行のモデルを返してくる。最初の生成では必ずどこか制約の書き間違いがあるので、テストケース(極端な小規模データ)で検算してから本番データに当てる。

テストケースは「3人 × 3日 × 2シフト」など極小サイズで作る。手で最適解が分かるレベルにして、Claude Code が出してきた解と一致するかを確認する。一致しなければ、制約のどこかが間違っているか、目的関数の重みが想定と違う。デバッグ時は、PuLP の writeLP() で LP ファイルを出力させて、制約式を1つずつ目視確認するのが確実だ。

本番規模(100人 × 30日 × 4シフト × 5役割 = 60,000変数程度)になると、ソルバの選択が効いてくる。PuLP のデフォルトは CBC で、無料だが大規模問題で遅い。Gurobi(商用)やCPLEX(商用)が使えれば桁違いに速いが、ライセンスコストがかかる。中規模(20-50人)までなら CBC で十分、本格運用なら OR-Tools の CP-SAT を試す価値がある。Claude Code に「ソルバ選択肢を比較するベンチマークスクリプトを書いて」と指示すると、自社環境での最適選択ができる。

解の品質を上げるための工夫として「ウォームスタート」がある。前週のシフトを初期解として渡すことで、ソルバが早く良い解に到達する。シフトは週次や月次で組み続けるため、前回の解を再利用できる仕組みを最初から入れておくと運用が楽になる。

もう1つ実装上の工夫として、解が複数候補出てくることがある(目的関数値が同じ複数解)。この場合、現場リーダーが「どれを採用するか」を選べるよう、上位3-5案を提示するパターンが好まれる。Claude Code に「解の多様性を確保するオプション(diverse solutions)」を実装させると、現場の納得感が上がる。

H2-4: 入出庫予測モデルの統合

必要人時の前段にあるのが「物量予測」である。シフトを2週間前に確定する場合、出庫量予測の精度がシフト品質を直接決める。

物流量予測は「ベースライン(曜日 + 季節)」+「イベント補正」+「ノイズ」の3層構造で考える。Claude Code に Prophet や lightgbm を使った予測モデルを書かせる場合、特徴量設計を明示的に渡すと精度が安定する。

# prompt-3: 出庫量予測モデル
あなたは時系列予測の専門エンジニアです。物流倉庫の14日先までの日次出庫量を予測するモデルを構築してください。

【データ】
- daily_volume.csv (3年分、date, outbound_qty, inbound_qty, returns, weather_temp, weather_rain)
- events.csv (date, event_type[sale/holiday/inventory/promo], magnitude)

【要件】
1. ベースラインモデル: Prophet で日次出庫量を予測。曜日季節性 + 年次季節性を分解
2. 残差をLightGBMで補正: ラグ特徴(1,7,14,28日前)、移動平均(7,28日)、天候、イベント
3. 14日先までの予測区間(80%, 95%)を提示
4. 過去6ヶ月で walk-forward 検証、MAPE と RMSE を報告
5. 予測値を時間帯(時刻スロット)に按分する係数表を別途出力

【出力】
- forecast_14d.csv(date, hour_slot, point_forecast, lo80, hi80, lo95, hi95)
- forecast_diagnostics.md(検証結果・残差分析)
- hourly_split_coef.json(日次→時間帯の按分係数)

予測の不確実性は「シフト計画時に何人分の変動枠を確保すべきか」に変換して提示してください。

ポイントは「不確実性を変動枠人数に翻訳」させること。たとえば「95%区間で±50パレット → 安全側で派遣2名分の枠を確保」のように、現場が翻訳しなくていい形にする。

予測モデルの運用で必ず議論になるのが「予測の更新頻度」である。シフトを2週間前に確定する場合、その時点での予測でシフトを組み、確定後に予測が更新されても基本的にはシフトを動かさない。例外的に、確定後の予測修正が大きい場合(例: 95%区間が大きく外れる新規イベント情報が入った)に限り、シフトの一部を再計画する。この「再計画のしきい値」を明文化しないと、現場と管理部門で「いつ動かすか」の判断が割れる。

予測の精度評価でよく使われる MAPE(平均絶対パーセント誤差)は、低物量日の誤差を過大評価する欠点がある。たとえば「予測10パレット・実績15パレット」は MAPE 50% だが、絶対値ではたった5パレットだ。物流シフトの文脈では、MAPE だけでなく WAPE(加重絶対パーセント誤差)や Pinball Loss(分位点予測の精度)を併用するのが筋がいい。Claude Code に「複数の評価指標を出してください」と最初に指示しておくと、後で「精度悪化」アラートの基準作りが楽になる。

需要予測には、外部データを組み合わせる選択肢もある。EC物流ならばクライアントの広告投資額・キャンペーン情報、BtoB物流ならば取引先の発注パターン・休業カレンダー、輸入物流ならば港湾の混雑度・天候情報。これらを取得・統合するパイプラインを Claude Code で書くと、予測精度が一段上がる。ただし、外部データ依存度を上げすぎると「APIが落ちたら予測も止まる」リスクがあるので、ベースラインモデル単独でも動く構成を必ず維持する。

H2-5: 夜勤フェアネス指標の設計

夜勤を「公平に」回すという要請は、現場で最もセンシティブなテーマである。これを Claude Code に丸投げすると「夜勤回数を平準化」程度の浅いモデルを返してくるので、フェアネス指標を自分で設計して渡す必要がある。

本記事で推奨するのは「Jain’s Fairness Index」と「最大-最小比」の2指標の併用である。

指標	定義	解釈	使いどころ
Jain’s Fairness Index	(Σx_i)² / (n × Σx_i²)	1に近いほど公平、1/nに近いほど不公平	全員に対する平均的な公平性評価
最大-最小比	max(x_i) / min(x_i)	1に近いほど公平、大きいほど偏り	「一番損してる人」の救済
標準偏差	σ(x_i)	0に近いほど均一	分布のばらつき
ジニ係数	0(完全平等)-1(完全不平等)	所得分布の指標を流用	連続夜勤・希望休等の累積評価

Claude Code には「Jain’s を主指標、標準偏差をサブ、最大-最小比を見張り役」として組み込ませる。目的関数の重みは「現場が許容する偏りの幅」をヒアリングして決める。

# prompt-4: フェアネス評価レポート生成
あなたはシフト分析の専門エンジニアです。生成されたシフト表(shift_solution.csv)を読み込み、以下のフェアネス指標を計算するレポートを生成してください。

【計算指標】
1. 個人別 月間夜勤回数 → Jain's Fairness Index、標準偏差、最大-最小比
2. 個人別 月間休日数 → 同上
3. 個人別 希望休充足率 → 全員の充足率と最低充足率の従業員
4. 連続夜勤発生回数 → 2連続、3連続以上の件数
5. 連続勤務日数の最大値 → 個人別
6. 早番/遅番の偏り → 個人別の早番:遅番比率

【出力】
- fairness_report.md(各指標の数値 + ヒストグラム)
- bottleneck_employees.csv(指標が悪化している従業員リスト + 改善提案)
- comparison_with_previous_month.md(前月との比較、悪化した指標のアラート)

各指標について「許容範囲」と「アラート閾値」を明示し、閾値を超えた場合は具体的な是正案(誰の夜勤を誰に振り替えるか)を提案してください。

このレポートは毎月のシフト確定後に必ず回す。3-4ヶ月分を積み上げると「うちの倉庫の公平性のクセ」が見えてきて、次のシフト設計にフィードバックできる。

フェアネスの議論で見落とされやすいのが「時間軸の長さ」である。1ヶ月単位で公平でも、3ヶ月・6ヶ月・1年で見ると偏りが出ているケースは多い。たとえば「いつも年末年始に夜勤が回ってくる人」「毎年同じ時期に休めない人」が積み重なって不満につながる。Claude Code には「ローリング3ヶ月のフェアネス」「年間累積夜勤回数」も指標として出させる。年度をまたぐ夜勤回数の精算ルール(翌年度に振替可能か等)も最初に決めておくとトラブルが少ない。

もう1つの観点は「グループ間フェアネス」である。正社員グループ内では公平でも、パートと正社員を比較したときに「正社員は夜勤手当が出るのに、パートは早朝手当しか出ない」といった構造的な格差がある場合、その不公平感がチーム全体のモラルに響く。雇用形態を超えた手当の整合性も、シフト設計と一緒に経営判断として整理しておくべきだ。

フェアネスレポートを誰に開示するかも設計事項だ。全員に公開すると「自分はあの人より損している」というネガティブ比較を生む。一方、リーダーだけが持つと「ブラックボックスで決まっている」と感じられる。実務的には「個人別の指標は本人だけが見られる、全体集計は全員見られる」という権限設計が落ち着く。

H2-6: 雇用形態の最適ミックス(線形計画の上位設計)

パート・派遣・正社員の組み合わせをどう決めるか。これはシフト最適化の前段にある「人員構成設計」の問題で、月-四半期サイクルで見直す。

雇用形態ミックスを決める際の経済的なフレームワークは以下の通り(数値は想定例)。

雇用形態	時間単価(想定)	柔軟性	定着率	スキル習熟	適した役割
正社員	2,500-3,500円	低(配置転換可)	高	高	主任・夜勤・トラブル対応
パート(週20-30h)	1,200-1,600円	中	中-高	中	定常業務(検品・梱包)
派遣(月単位)	1,600-2,200円	高	低	低-中	繁忙期増員・夜勤代替
スポット(日単位)	1,500-2,000円	最高	該当なし	低	突発欠員・セール対応

このマトリクスを Claude Code に渡して「年間の物量予測」と「制約(社員比率の下限、スポット利用の上限等)」を入れると、年間の人件費最小化問題が解ける。ただし、ここは経営判断の領域なので、結果はあくまで提案として人事責任者と擦り合わせる。

雇用形態ミックスを考えるうえで、見落としやすい論点が3つある。1つ目は「定着率による隠れたコスト」。派遣・スポット比率を上げれば短期的な人件費は下がるが、毎回の業務指示・初日教育・品質確認に正社員の時間が取られる。離職率が高いと、この「教育のための機会損失」が積み重なる。年間の総コストを正しく見るには、教育時間を時給換算して足し戻す必要がある。

2つ目は「110万円・130万円・150万円の壁」(社会保険の被扶養者条件の境界)。パート従業員の月収管理を間違えると、本人が想定外に保険料負担を強いられて離職する。Claude Code で年収管理ダッシュボードを作って、月次で「年初からの累積収入 → 年末予測」を出すと、本人と相談しながらシフトを調整できる。これも本来は労務担当者の仕事だが、シフト最適化と連動して動かすことで、年間を通じた離職リスクを下げられる。

3つ目は「同一労働同一賃金」関連の動向だ。2020年4月施行のパートタイム・有期雇用労働法により、「正社員と非正規で同じ業務をする場合に不合理な待遇差を設けてはならない」という制約が強くなった。シフトを設計するときに、正社員にだけ繁忙期の応援手当が出る、夜勤手当の単価が違う、といった差を放置すると、後で訴訟リスクになる。雇用形態ミックスを変えるときには、必ず社労士と賃金体系の整合性を確認する。

# prompt-5: 雇用形態ミックスの最適化
あなたは人員計画の専門コンサルタントです。物流倉庫の年間人員構成を最適化するモデルを Python + PuLP で実装してください。

【入力】
- annual_demand_forecast.csv(月次の総必要人時、12ヶ月分)
- employment_costs.yaml(雇用形態別の時間単価・付帯コスト・採用コスト)
- skill_requirements.yaml(役割別の必要スキルとカバー率)

【決定変数】
- n_fulltime: 正社員人数(整数、年単位で固定)
- n_part[m]: 月mのパート人数(整数)
- n_dispatch[m]: 月mの派遣人数(整数)
- n_spot[m,d]: 月m日dのスポット人数(整数)

【制約】
1. 各月の必要人時を満たす
2. 正社員比率 ≥ 40%(社内規定)
3. スポット比率 ≤ 15%(品質維持)
4. 主任業務(リーダー)は正社員のみ、最低必要数を確保
5. 採用には3ヶ月のリードタイム(年初に正社員数を確定)

【目的関数】
- 年間総人件費を最小化
- ただし「定着率による生産性ボーナス」を正社員・長期パートに加点

【出力】
- annual_staffing_plan.csv(月別・雇用形態別の人員数)
- cost_breakdown.md(雇用形態別コスト、想定削減額)
- sensitivity_analysis.md(物量±20%変動時のリスク評価)

最後に「現状の人員構成と比較して、何%の人件費削減ポテンシャルがあるか」をシミュレーションしてください。

H2-7: 労基法チェッカーの実装パターン

シフト表が出来上がっても、労基法に違反していないかをチェックする工程を必ず入れる。Claude Code に「ルール表」を渡してチェッカーを書かせると、人手レビューの時間が劇的に減る。

労基法チェッカーで実装すべき項目は以下の通り。

• 法定労働時間(1日8時間・週40時間)超過の検出
• 休憩時間の不足(6時間超で45分、8時間超で60分)
• 連続勤務日数(社内規程で6日以内が一般的)
• 勤務間インターバル(11時間推奨、最低でも8時間)
• 36協定の月間上限(45時間、年360時間)
• 深夜労働時間の集計(22時-翌5時、25%割増対象)
• パート従業員の社会保険加入条件(月87,000円、週20時間等)

これらをチェック関数として実装し、シフト生成パイプラインの最後で必ず通す。違反があったら「自動修正は提案するが、確定は責任者と社労士」というスタンスを徹底する。

実務的には、シフト確定後に勤怠実績と突合させて「計画と実績の乖離」もモニタする。突発残業・遅刻早退で計画外の労基リスクが発生していないかを月次でレビューする。

労基法チェッカーを Claude Code に書かせるとき、ルールはコード内にハードコードせず、必ず外部 YAML(labor_rules.yaml)として持つ。法改正のたびにコードを書き換えるのではなく、設定ファイルだけ更新できる構造にしておく。ルールには「根拠条文」「適用開始日」「次回見直し予定日」を必ずメタデータとして付けておくと、社労士レビューの時に確認しやすい。

もう1つの実装上のテクニックは「違反検出を段階レベルで分ける」こと。たとえば「絶対違反(法定労働時間超過)」「強い警告(連続勤務6日継続)」「弱い警告(勤務間インターバル10時間以下)」「情報(深夜労働発生)」のように4段階で分類する。これによって、レポートを受け取った責任者が優先順位を判断しやすくなる。Claude Code に「重要度別にカテゴリ分けして」と指示するだけで、この階層が出るレポートが書ける。

労基法チェッカーは、毎月の勤怠実績側でも同様に動かす。「計画段階で違反ゼロ」でも、現場で突発残業や代替勤務が発生すれば、実績ベースで違反になっていることがある。計画チェッカーと実績チェッカーをセットで作っておき、毎月の労務レビュー時に両方を回す習慣を作ると、労務監査での指摘が大幅に減る。

H2-8: 関連する Claude Code 物流実装事例との連携

シフト最適化単体で動かすより、倉庫の他システムと連携させると効果が大きい。本サイトで扱った関連事例とのつなぎ込みを整理する。

• WMS と人員配置を連動 → 物流WMS連携をClaude Codeで実装した事例 でWMSのデータ取得方法を解説
• 配車計画と荷役人員を同期 → 物流配車最適化をClaude Codeで実装した事例 でトラックバース時刻と荷役シフトの整合性確保
• 同じ需要予測ベースの人員設計の他業界応用 → 飲食店の需要予測ベースシフト計画をClaude Codeで実装した事例 で飲食店での類似手法を比較

とくに WMS との連動は重要で、入庫予定の品目特性(重量・サイズ・特殊扱い)まで取れると、必要人時の精度が一段上がる。配車最適化との連動はトラックバース時刻の前後30分で人員ピークが立つので、ここを同期しないとシフトと現場の動きがずれる。

システム連携の優先順位を決めるなら、まず WMS の入出庫予定データ取得から着手する。これがあるだけで需要予測の精度が劇的に上がる。次に勤怠管理システム(従業員マスタ・打刻データ)と連携して、計画と実績の突合を自動化する。配車最適化との同期は3番目で、ここまで来ると倉庫全体のオペレーション可視化が完成する。1段ずつフェーズを切って導入することで、現場の負荷を分散できる。

システム連携の API 仕様が古い・ドキュメント不足の場合、Claude Code に「既存システムの DB スキーマと出力サンプルからアダプタを書いて」と指示する。WMS のテーブル定義と出力 CSV を渡せば、必要なETLパイプラインを書いてくれる。ただし、本番DBへの書き込み権限は最初から渡さず、読み取り専用のレプリカDBで開発を進めるのが安全だ。

H2-9: 【要注意】失敗パターン4選

失敗1: ❌ 予測モデルの精度を上げすぎて、変動枠をゼロにする

予測 MAPE を10%以下にチューニングして「もう派遣枠はいらない」と判断した倉庫を見たことがある。結果、3ヶ月後の予期せぬセールで一気に物量が膨らみ、深夜まで全員残業 → 36協定のグレーゾーンに突入 → 翌月の労務監査でヒヤリ。

⭕ 正解: 予測区間の95%上限-中央値の差分を「最低限の変動枠」として確保する。MAPE10%でも、95%区間は±20-30%振れる。これを正社員残業ではなくスポット・派遣で吸収する設計にする。

失敗2: ❌ フェアネスを「平均」だけで評価して、特定個人が割を食う

「夜勤回数の平均は月3回」と報告したら現場から不満爆発。よく見ると、半数は月2回、半数は月4回で、月4回側のメンバーが「いつも自分ばかり」と感じていた。平均だけ見ると公平に見えるが、実際は二極化していた。

⭕ 正解: Jain’s Fairness Index、標準偏差、最大-最小比の3指標を必ず併記する。最大-最小比が2倍を超えたら自動アラートを出す設計にする。月4回のメンバーには翌月優先的に夜勤を減らす補正ルールを入れる。

失敗3: ❌ 労基法チェックを「最終確認だけ」で済ませる

シフト生成後に違反検出 → 修正 → 再生成のループに入ると、フェアネス指標が悪化する。「違反は出ないけど不公平な解」が量産される。

⭕ 正解: 労基法はソルバの「ハード制約」として最初から組み込む。後付けチェッカーは「制約定義の検算」として使う。フェアネスは目的関数で扱う。この階層を最初に決めておくとリファクタが楽になる。

失敗4: ❌ Claude Code に「全部やらせる」スコープで丸投げ

「シフト最適化を Claude Code で作って」と一気に投げると、雑な予測モデルと雑な制約モデルを混ぜた巨大スクリプトが返ってくる。後でデバッグ不能になる。

⭕ 正解: プロジェクトを「予測モデル」「必要人時マトリクス」「制約ソルバ」「フェアネス評価」「労基法チェッカー」の5モジュールに分解。それぞれ独立にテスト可能な単位で Claude Code に書かせる。CLAUDE.md にこの分割方針を最初に書いておくと、後続のセッションでも一貫性が保たれる。

モジュール分割の目安として、1モジュールあたり300-500行のコードに収まるように設計する。これより大きくなると、Claude Code の生成・修正でコンテキスト消費が増え、品質が落ちる。各モジュールは tests/ 配下に最小限のユニットテストを置き、入力・出力の契約をはっきりさせる。モジュール間のデータの受け渡しは CSV や JSON など、人間が中身を確認できる形式にしておくと、後で問題が起きた時に原因追跡が楽になる。

H2-9b: 運用フェーズで効いてくる3つの落とし穴

本番運用に入って3-6ヶ月後、最初の設計では想定していなかった問題が必ず出てくる。よく見る3つの落とし穴を挙げておく。

当日欠員のリカバリ設計が後手に回る

シフト最適化に成功すると、計画段階での欠員はほぼゼロになる。しかし、当日朝の体調不良・家族の急病・公共交通機関の遅延による突発欠員は依然として発生する。この時、最適化済みのシフト表をどう再計画するかが運用品質を左右する。

事前に「リカバリのプレイブック」を用意しておく。たとえば「当日の朝7時時点で欠員 → スポット派遣会社A社に8時までに連絡 → ダメなら社内応援を打診 → さらにダメなら作業優先順位を組み直す」のようなフローを文書化する。Claude Code に「欠員1人発生時の代替候補を即時に提案するスクリプト」を書かせて、リーダーが現場で判断できるツールにすると、復旧時間が大きく短縮される。

長期休暇シーズンの精算ルールが曖昧

夏季休暇・年末年始・GW などの長期休暇は、希望休が殺到する。先着順なのか、前年実績ベースなのか、家族構成優先なのか。ここのルールを明文化しておかないと、毎年同じトラブルが起きる。Claude Code には「希望休の重複時のルールベース解決」を実装させ、優先順位ロジックを透明化する。希望が通らなかったメンバーには、別の月で優先的に希望休を取れる「振替ポイント制」も併用すると公平感が出る。

シフト管理者のスキルが Claude Code に置き換わらない

システム化が進むと、若手の管理職にシフト作成の経験が積めなくなる。これは現場の暗黙知が次世代に継承されないリスクで、5年・10年スパンで効いてくる。対策として、若手にも月1回は「Claude Code に頼らずシフトを組み立てる」訓練の機会を作る。最適化結果を「正解」として、若手の手作りシフトとの差分を Claude Code に分析させると、教育コンテンツとしても機能する。

H2-10: 本番運用に向けたチェックリスト

シフト最適化を本番で回す前のチェック項目をまとめる。

• □ 過去3ヶ月の手作りシフトと最適化シフトを並べて比較レビュー(人手のベテランの判断を再現できているか)
• □ 労基法チェッカーが、過去の違反履歴をすべて検出できるか(テストケースを過去ログから生成)
• □ ソルバが解を出せない時のフェイルセーフ(前週のシフトに微修正、または手動編集)
• □ 従業員へのシフト確定通知フロー(LINE WORKS / Slack / 紙の3チャネル)
• □ 当日欠員発生時のリカバリ手順(スポット手配のリードタイム想定)
• □ 社労士による定期レビュー(月1回、特に36協定・特別条項)
• □ 個人情報(シフト希望・健康情報)の管理と権限分離
• □ 雇用形態別の労務管理(派遣法・パート有期雇用法・労働契約法)

H2-11: ROI とプロジェクト投資対効果の現実的な目安

シフト最適化プロジェクトの ROI 議論は、経営者と現場の温度差が出やすい。「Claude Code を入れると人件費が30%下がる」のような過大な期待は、ほぼ確実に裏切られる。現実的な投資対効果のレンジを整理する(以下は想定例)。

直接効果として見込めるのは、シフト作成時間の短縮(週12時間 → 週2-3時間)、突発残業の削減(月平均で1-2割減)、派遣・スポット費用の最適化(過剰発注を5-10%抑制)、欠員時のリカバリ時間短縮、労務監査での指摘減少。これを年間で積み上げると、20-50人規模の倉庫で年間数百万円のオペレーション改善になる。

間接効果として大きいのが「シフト作成の属人化解消」と「労務リスクの可視化」だ。これらは金額換算しにくいが、ベテラン1人の退職が事業継続リスクになる構造を解消できる。労務トラブル発生時の対応コストを考えると、こちらの方が長期的なリターンが大きい場合もある。

逆に過大評価しがちなのが、「シフト品質向上による生産性アップ」だ。理論上は最適配置で生産性が10-20%上がる計算になるが、実際には現場の慣れや人間関係で5%程度の改善に落ち着くことが多い。期待値はこのレンジで持っておいた方が、現場との温度差が出にくい。

投資額の目安としては、社内に Python が書けるエンジニアがいる前提で、開発工数 2-3ヶ月分(エンジニア1人 + 現場リーダーの並走時間)を見込む。外部委託する場合は、設計・実装・本番移行・運用引き継ぎまで含めて、規模に応じた予算感を持つ。Claude Code を活用すれば、設計フェーズは大幅に短縮できるが、現場との合意形成・テストデータの整備・社労士レビューの時間は短縮できない。ここを甘く見積もると、スケジュールが大きくぶれる。

もう1つ、忘れがちな投資対象が「運用体制の継続コスト」である。本番稼働後も、月次のレポートレビュー、四半期の係数再推定、年次の法改正対応、新規メンバー追加時のマスタ更新が必要になる。これらの定常運用に、月数時間-10時間の工数が継続的にかかる。ここを最初から見積もって運用設計しないと、リリース直後は動いていたシステムが、半年後には誰も触らないお飾りになる。

著者プロフィール

佐藤傑(さとう・すぐる)。株式会社Uravation 代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向け AI 研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT 連載7回執筆。物流・製造・小売の現場で Claude Code を使った業務システムの設計・実装支援を行っている。

次のアクション(3つ)

1. 過去半年の入出庫データと現行シフト表を CSV 化する — Claude Code に渡すための前提整備。Excel から CSV エクスポートして、最低でも日次粒度・時間帯粒度の2種類を準備する。
2. 必要人時マトリクスを Claude Code で試算する — 本記事のプロンプト1を使って、自社データで係数推定をやってみる。MAPE が15%以下になればシフトモデルへの統合に進める。
3. 労基法チェッカーから着手する — 最適化モデルを作る前に、現行シフト表をチェッカーに通す。違反が見つかればまずそこを是正する。Claude Code 導入の最初のクイックウィンになる。

シフト最適化は「現場のベテランを置き換える」ことが目的ではない。ベテランの暗黙知を構造化し、誰でも同じ品質のシフトを設計できる状態にすることが目的だ。最終決定権は現場責任者と社労士にあり、Claude Code は設計補助のツールにすぎない、というスタンスを最初から共有しておくと、現場の納得感が大きく変わる。

導入のロードマップとしては、最初の1ヶ月で「現状把握と労基法チェッカー」、次の1-2ヶ月で「必要人時マトリクスと予測モデル」、最後の1-2ヶ月で「制約ソルバとフェアネス評価」を組み立てるのが現実的だ。3-5ヶ月で本番運用までもっていけるが、それより重要なのは「ベテランがいるうちに作る」という時間軸の判断である。退職後では暗黙知のヒアリングができず、係数推定の精度が一気に落ちる。

最後に、シフト最適化のプロジェクトは、IT 部門だけで完結しない。現場リーダー、人事・労務、社労士、経営者(人件費の責任を持つ)、そして従業員代表が同じテーブルにつく必要がある。Claude Code が出した「最適解」を、関係者全員で「自分たちの倉庫の解」として受け止められる対話のプロセスを最初に設計することが、プロジェクト成功の鍵になる。

参考出典

• 厚生労働省「労働基準法のあらまし」(mhlw.go.jp) — 法定労働時間・休憩・休日・36協定の根拠
• 厚生労働省「働き方改革関連法のあらまし」(mhlw.go.jp) — 時間外労働の上限規制、勤務間インターバル制度
• 経済産業省「物流DX・自動化に関する調査」(meti.go.jp) — 物流業界の人手不足と DX 推進の方向性
• Google OR-Tools 公式ドキュメント “Employee Scheduling” (developers.google.com/optimization) — 制約プログラミングによるシフト最適化の実装パターン
• PuLP Documentation (coin-or.github.io/pulp/) — Python による線形計画ソルバの公式ガイド
• Jain, R., Chiu, D., Hawe, W. “A Quantitative Measure of Fairness and Discrimination” (DEC-TR-301, 1984) — Jain’s Fairness Index の原典

関連記事（自動）

• ▸ 【2026年最新】物流・運送業のClaude Code活用｜配車計画・伝票処理・ドライバー教育の自動化
• ▸ 【2026年最新】物流3PLの配車計画をClaude Codeで半自動生成
• ▸ 物流WMS連携をClaude Codeで自動化｜入出庫データ整形と通知パイプライン