希望とスキルと法令の制約を満たすシフト表の原案を作る

処理の起点を決める

希望の締め切り翌日の朝に、定時で一括実行します。 管理者が出社したときに、希望の変換結果と最初の原案が出来ている状態にします。

再計算は管理者が手動で実行できるようにします。条件の優先度を変えて解き直す操作が何度も発生するためです。1回の計算に数分かかるので、待っている間に他の作業ができる形にしてください。

規模の目安として、公開されている実装例の報告では、150名・30日・50種類のシフトの規模で2〜5分、300名以上になると10〜30分かかるとされています。240名なら数分の範囲に収まる見込みですが、制約の数によって大きく変わるため、自社のデータで必ず実測してください。

入力データを集める

「公平性のルール」が、この構成でいちばん手間のかかる入力です。 現在は管理者の頭の中にあります。「夜勤は月8回まで、人による差は2回以内」「3か月連続で年末年始に出た人は次は外す」といったルールを、数字で書き出す必要があります。この作業自体が属人化の解消になります。

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

シフト希望： フォームの回答をスプレッドシートから読み込みます。自由記述の欄を必ず残してください。 選択肢だけにすると、書ききれない事情が口頭で入ってきて、結局手作業が残ります。

過去の勤務実績： 勤怠管理システムからCSVで取得します。夜勤回数の偏りと時間外労働の累計に使います。時間外労働の上限（月45時間、複数月平均80時間、年720時間など）を制約に入れるために、過去12か月分が必要です。

工程の必要人数： 生産計画から算出します。これが読めない月は、この構成は使えません。 必要人数が当日にならないと決まらない業務では、前提が成り立ちません。

AIへ渡す前に整形する

1. 自由記述の変換 … LLMで「日付・時間帯・可否・理由の区分・強さ」に変換します（後述）
2. 変換結果の確認 … 変換に迷ったものを管理者に見せ、確認してもらいます。ここを飛ばすと、誤った制約で解いてしまいます
3. 制約の分類 … すべての制約を「絶対に守るもの（ハード制約）」と「できれば守るもの（ソフト制約）」に分けます
4. 資格と工程の対応づけ … 工程ごとに、割り当て可能な有資格者の集合を作ります
5. 過去実績の集計 … 夜勤回数、休日出勤日数、時間外労働の累計を従業員ごとに集計します

3番目の分類が、この構成の設計の核です。

必要人数をハード制約にしないでください。 必要人数を絶対条件にすると、人が足りない月に解が1つも出なくなります。 現実には「必要人数を1名下回る枠がある」シフトでも運用できます。必要人数はソフト制約にして、下回った分を罰点として数え、管理者にどこが薄いかを見せるほうが使えます。

AIに処理させる

割り当ての計算は制約プログラミングで行います。 目的関数は「ソフト制約の罰点の合計を最小にする」です。罰点の重みが、そのまま優先順位になります。

LLMにさせること：

LLMにシフトを割り当てさせないでください。 240名×30日の割り当てが制約を満たしているかは、目では確認できません。制約プログラミングで解けば、出てきた解はハード制約を必ず満たしています。 これが検証可能性の差です。

「競合の説明」が実務では大きく効きます。 解が出ないとき、ソルバーは「実行不可能」としか返しません。管理者が知りたいのは「なぜ解けないのか」です。ハード制約を1つずつ外して解き直し、どれを外すと解けるようになるかを特定すれば、競合している条件が分かります。 その内容をLLMに日本語で説明させます。

指示内容を固定する

自由記述の変換（1件ずつ）：

あなたは、シフト希望の自由記述を、計算に使える形に変換する担当者です。

【厳守事項】
- 書かれていない日付を補わないでください。
  「来週」「月末」のように特定できない場合は、
  dates を空にし、needs_confirmation に理由を入れてください。
- 理由の内容を、必要以上に詳しく転記しないでください。
  区分（家庭の事情 / 通院・体調 / 学業 / 私用 / 記載なし）だけを reason_category に入れ、
  原文の理由は転記しないでください。
- 強さ（絶対に不可か、できれば避けたいか）は、書かれた表現から判断してください。
  判断できない場合は "unknown" とし、needs_confirmation に入れてください。
  「できれば」と勝手に弱めないでください。
- 健康状態に関する記述があった場合は、
  health_related を true にし、内容は転記しないでください。
  管理者が本人と個別に話す対象として印を付けるだけにしてください。
- 時間帯は、下記の勤務区分の名称のみを使ってください。
  新しい区分を作らないでください。

【勤務区分】
日勤（8:00-17:00）/ 準夜勤（16:00-1:00）/ 夜勤（0:00-9:00）

【対象月】
{target_month}（{start_date} 〜 {end_date}）

【従業員】
{employee_name}（{department}）

【自由記述】
{free_text}

競合の説明：

あなたは、シフト作成の担当者を支援する担当者です。
条件を満たす割り当てが見つからなかった原因を、管理者に説明してください。

【厳守事項】
- あなたが割り当てを提案しないでください。
  「Aさんを夜勤に入れれば解決します」と書かないでください。
  どの条件とどの条件がぶつかっているかだけを説明してください。
- 入力に含まれる「外すと解けるようになった制約」の情報だけを使ってください。
  それ以外の推測を書かないでください。
- 説明には、具体的な日付・工程・人数を含めてください。
  「人手が足りません」だけでは行動できません。
- 管理者が取れる選択肢を、下記の4つから該当するものだけ挙げてください。
  新しい選択肢を作らないでください。
  （1）必要人数を見直す（2）他の課へ応援を依頼する
  （3）希望を断る（4）勤務区分の割り方を変える

【計算の結果】
{infeasibility_analysis}

【対象月の条件】
{constraints_summary}

「あなたが割り当てを提案しないでください」の1行が重要です。 LLMが提案した割り当ては、他の制約を破っている可能性があります。管理者が条件を変えて解き直すのが正しい手順です。

自由記述の変換で「理由の原文を転記しない」としているのは、意図的です。 シフト希望の理由には、通院、家族の介護、子どもの事情といった私的な情報が書かれます。これを計算に使う必要はありません。 必要なのは「その日のその時間帯が不可かどうか」と「その強さ」だけです。

出力形式を固定する

自由記述の変換：

{
  "employee_id": "",
  "requests": [
    {
      "dates": [],
      "shift_types": [],
      "availability": "unavailable | prefer_not | prefer",
      "strength": "strong | weak | unknown",
      "reason_category": "family | health | study | private | not_stated",
      "health_related": false,
      "source_text_hash": ""
    }
  ],
  "needs_confirmation": []
}

計算結果：

{
  "status": "optimal | feasible | infeasible",
  "assignments": [
    { "date": "", "shift_type": "", "process": "", "employee_id": "" }
  ],
  "hard_constraints_satisfied": true,
  "soft_constraint_penalties": {
    "understaffed_slots": [],
    "requests_denied": [],
    "night_shift_imbalance": 0,
    "consecutive_days_near_limit": []
  },
  "fairness": {
    "night_shifts_per_employee": {},
    "requests_granted_rate": 0
  },
  "solve_time_seconds": 0
}

source_text_hash を持つのは、原文そのものを保存せずに、後から「どの記述から変換したか」を照合できるようにするためです。管理者が確認するときは、原文と変換結果を並べて見ますが、計算の入力データとしては原文を持ち回りません。

soft_constraint_penalties の中身が、管理者が見る主な情報です。 「どこが人数不足か」「誰の希望を断ったか」「夜勤が偏っていないか」が並びます。罰点の合計値だけを出しても使えません。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-15時点ではベータ機能として提供）。自由記述の変換のように形の崩れが後段を壊す処理では、利用できると安全です。

システムへ連携する

確定前のシフトを勤怠システムに書き込まないでください。 原案の段階で書き込むと、従業員が見て混乱します。確定は管理者の操作を起点にします。

人が確認する

原案は必ず管理者が確認し、確定します。自動確定しません。

確認するのは次の点です。

最後の項目は制約に書けません。 「この2人は同じ班にしない」「新人はベテランと組ませる」といった事情は、書けるものは制約にしますが、書ききれないものが必ず残ります。管理者が見て直す余地を残してください。

手で直したら、必ず再計算してください。 1か所を直すと法令の条件が崩れることがあります。手直し後のシフトについて、ハード制約を満たしているかを検証する処理を用意してください。 これがないと、制約プログラミングを使う意味が半減します。

例外に対処する

記録を残す

• シフト希望の原文（管理者の確認用。計算には使わない。対象月の終了後に削除する）
• 変換後の制約（source_text_hash つき）
• 制約の設定（ハード／ソフトの分類と重み）
• 計算結果（assignments と soft_constraint_penalties）
• 管理者が手で直した内容と、その理由
• 確定したシフト表
• 本人への説明文と、その送信記録

「管理者が手で直した内容と、その理由」が、この構成の資産です。 「この工程には新人を1人までしか入れない」といった、制約に書けていなかった条件が見えてきます。それを制約として書き足していけば、手直しは減ります。

シフト希望の原文は、対象月が終わったら消してください。 理由の欄には私的な情報が書かれます。残す理由がありません。