「スケジューリング最適化にソルバーを使えばいいのではないか」という問いは、情報システム部門や技術者から出やすい。
数理最適化の文脈でソルバーは標準的な道具であり、制約充足問題や制約最適化問題の求解に使われてきた。
しかしソルバーはスケジューリング最適化の一部を担うことができるが、業務で使えるスケジューリングシステムの全体を構成することはできない。
この限界を正確に理解することが、スケジューリングシステムの技術選定において重要な判断基準になる。
こうした問いに対して、スケジューリングの自動化という観点から開発されているのがshiftect.であり、ソルバーをどう位置づけるかという問いに対して、その設計思想のなかに明確な答えを持っている。
ソルバーが解く問題と、業務スケジューリングが必要とする処理を整理する。
ソルバーは「与えられた入力構成（変数・定数・制約条件）に基づいて解を探索する」エンジンだ。
制約条件を定義し、探索対象となる変数と固定値となる定数を与えれば、その範囲で最適解を返す。
ソルバー自体は高性能であり、大規模な組み合わせ問題を効率的に解くことができる。
問題はソルバーが解く前段にある。
業務スケジューリングでは、業務の状態が変わるたびに「今回は何を変数として探索し、何を定数として固定するか」という入力構成そのものが変わる。
月初の全体生成では全リソースが変数になる。
欠勤が発生した再調整では、確定済みの配置が定数になり影響範囲だけが変数になる。
特別期間の生成では、通常期の確定済み配置が定数になり特定期間内のコマだけが変数になる。
この入力構成の切り替えを誰が・どのように決定するかという問題を、ソルバーは解かない。
ソルバーは「問題を解く」エンジンであり、「どういう問題として解くべきかを決める」機能を持っていない。
業務で使えるスケジューリングシステムに必要なのは、ソルバーの前段に位置する制御層だ。
業務の状態を示す情報（状態情報）を読み取り、その状態に応じて入力構成を自動的に決定する。
shiftect.が特願2026-026989として出願している技術の核心はこの制御層にある。
状態情報DBに保持された業務の文脈を参照し、全体生成・部分変更・特別期間対応という三つの局面に応じた入力構成を自動的に切り替えることで、管理者がいちいち固定設定を行わなくてもシステムが業務の文脈を読み取って適切な探索空間を自動定義する。
ソルバーがスケジューリング最適化に向いていないのではなく、ソルバーだけではスケジューリングシステムは完成しないということだ。
業務の状態に応じて入力構成を自動的に決定する制御層がなければ、どれだけ高性能なソルバーを使っても業務で使えるシステムにならない。
shiftect.はその制御層を核心として設計されており、業務の文脈から入力構成を自動決定するという処理そのものが技術の本体だ。
最適化エンジンはshiftect.の内部に持つことも外部APIとして呼び出すことも設計上どちらも可能であり、shiftect.が特願2026-026989として出願しているのは最適化エンジンそのものではなくこの制御層の仕組みだ。