「スケジューリングはすたれた技術だ」という言葉を聞いたのは、2025年11月のことだった。
10年来の付き合いがある事業家のI氏から言われた一言だ。
そのとき私は、この言葉が転機になるとは思っていなかった。
I氏がそう言ったのは、スケジューリングを否定したからではなかった。
「新しいものがあるなら言語化してほしい」という問いがその背景にあった。
その問いが、shiftect.の制御構造を言語化する作業の起点になった。
言語化の過程で見えてきたのは、スケジューリングはすたれていないという事実だった。
個別指導塾では毎月、管理者が700コマの配置を手で決めている。
施設介護では毎月、シフト作成に膨大な時間が費やされている。
訪問介護では毎日、キャンセルと緊急依頼への対応が管理者を拘束している。
物流では毎日、配車担当者がベテランの経験と勘で配送計画を組んでいる。
スケジューリングはすたれていない。
解決されていないまま、現場に残り続けている。
なぜ解決されていないのか。
生成AIで解決できないのか。
生成AIは「もっともらしい答え」を確率的に生成する仕組みだ。
しかしスケジューリングは「もっともらしい答え」ではなく「全ての制約を必ず満たす答え」が求められる問題だ。
生成AIはハード制約を必ず守ることを保証できない。
また生成AIは、確定済みの配置という状態を保持しながら「どこを固定しどこを探索するか」を制御する仕組みを持っていない。
生成AIが「スケジューリングの話を説明する」ことはできる。
しかし「スケジューリングを実行する」ことはできない。
ソルバーで解決できないのか。
ソルバーは与えられた問題を解く最適化エンジンだ。
しかし現場の問題は「与えられた問題を解く」ことではない。
業務の状態が変わるたびに、何を固定し何を探索するかという問題の構造自体が変わる。
ソルバーはその変化を自動的に読み取って問題を組み立てる仕組みを持っていない。
問題を解く前に「どういう問題として解くべきか」を決める仕組みが別に必要だ。
スケジューリングはすたれた技術ではなく、正しく定義されていなかった問題だった。
生成AIでもなく、ソルバーでもなく、業務の状態に応じて最適化処理への入力構成を自動的に決定する制御構造が必要だった。
shiftect.はその制御構造を核心として開発している。
特願2026-026989として出願しているのは、この制御構造だ。
I氏の一言がなければ、この問題の定義にたどり着くのはもっと遅かったかもしれない。