スケジューリング自動化の記録　shiftect.開発ブログ

人手不足倒産が過去最多を更新するなかでスケジューリング機能のOEM提供が塾フランチャイズ本部の加

Tue, 09 Jun 2026 13:43:32 +0900

2025年の学習塾倒産件数は55件と過去最多を更新し、負債1億円未満の小規模塾が全体の94.5%を占めている。
後継者不在や経営悪化で単独運営が難しくなった教室がフランチャイズへの加盟を選ぶケースが増えており、塾フランチャイズ本部にとってこの環境は傘下の教室を増やすチャンスでもある。
しかし同時に、本部が抱える構造的な不安要素も大きくなる。

個別指導塾のフランチャイズは他業種と異なり、加盟校の運用を本部がグリップできていない。
本部が提供できるのは広告・マーケティング支援程度であり、各教室のオペレーションは現場の教室長に委ねられたまま、本部からは見えない。

加盟校が増えるほど、このグリップのなさが経営リスクとして積み上がる。
各教室の時間割作成と振替対応は現場の教室長に属人化しており、教室長が交代すれば運営の質が変わる。
本部は入退会数や売上という結果しか把握できず、問題が表面化してから初めて知るという構造が続く。
倒産・廃業が加速する環境では、加盟校の経営悪化が表面化するスピードも速まる。

このグリップのなさという構造問題に対してスケジューリングの自動化という観点から開発されているのがshiftect.であり、本部が自社ブランドのシステムとして時間割作成と振替対応の自動化を加盟校に提供できるOEM提供という仕組みを目指している。

shiftect.のOEM提供によって、本部は加盟校のオペレーションを初めてグリップできる手段を持つ。
時間割作成と振替対応がシステム化されることで、各教室のオペレーションが本部からリアルタイムで見えるようになる。
どの教室でどのような時間割が組まれ、振替対応がどう処理されているかという線の情報が本部に届くことで、問題が表面化する前に介入できる体制が生まれる。

加盟校が増えるほどこの可視化の価値は大きくなり、本部と加盟校の関係を広告・マーケティング支援にとどまらない実質的なものに変えることができる。

倒産・廃業が加速する今は傘下の教室を増やすチャンスであると同時に、グリップのなさという不安要素を解消できるかどうかが本部の経営課題になっている。

スケジューリング機能のOEM提供によってその課題を解くという手段を、shiftect.は本部に対して提供しようとしている。

塾の事業承継が加速する2026年にスケジューリング機能のOEM提供が塾フランチャイズ本部の差別化

Tue, 09 Jun 2026 13:37:18 +0900

2025年の学習塾倒産件数は55件と過去最多を更新し、学習塾業界のM&Aは2024年に53件、2025年も1〜9月だけで37件と過去最多ペースで推移している。
後継者を持たない独立系の塾が閉校するか、フランチャイズに加盟するかという選択を迫られるケースが増えており、フランチャイズ本部にとって加盟校の増加は事業拡大の機会だ。
しかし個別指導塾のフランチャイズは、飲食や小売と比べて本部のグリップが弱いと言われる。
加盟校にとってのメリットが広告・マーケティング支援程度にとどまり、オペレーションは各教室に委ねられているからだ。
本部は加盟校の入退会数・売上・生徒数という結果は把握できても、各教室の運営がどう行われているかは見えない。

この構造が、事業承継後の加盟校の運営不安定化につながる。
個別指導塾の教室長にとって、毎月の時間割作成と毎日の振替対応は最も負荷が高い業務だ。
この業務は前の経営者の経験と勘に依存しており、承継後の新しい教室長がすぐに同じ水準で対応できるとは限らない。
本部が広告・マーケティング支援を提供しても、現場で時間割を組める人間がいなければ教室は回らない。
本部がこの問題を解決する手段を持っているかどうかが、加盟先を選ぶ経営者の判断基準のひとつになりつつある。
こうした時間割作成と振替対応の属人化問題に対してスケジューリングの自動化という観点から開発されているのがshiftect.であり、本部が自社ブランドのシステムとして加盟校に提供できるOEM提供という仕組みを目指している。

shiftect.のOEM提供が本部にもたらす変化は二つある。
一つは加盟校の時間割作成の属人化をなくすことで、誰が教室長になっても同じ水準で運営できる構造が生まれる。
もう一つは、これまで見えなかった各教室のオペレーションが本部から可視化されることだ。
入退会数や売上という点の情報だけでなく、各教室の時間割の状態・振替対応の状況という線の情報が本部に届くようになる。
本部が各教室のオペレーションをリアルタイムで把握し、問題が表面化する前に支援できる体制が生まれることで、これまで緩かったフランチャイズの本部・加盟校関係が構造的に変わる。

塾の事業承継が加速する2026年において、スケジューリング機能のOEM提供は塾フランチャイズ本部が加盟校との関係を強化する最も実質的な手段のひとつになり得る。
広告・マーケティング支援にとどまっていた本部の価値を、オペレーション支援という領域にまで広げることを、shiftect.はOEM提供という形で本部に届けようとしている。

人材不足時代にAIエージェントがスケジューリングを担うとき経営は何が変わるのか

Tue, 09 Jun 2026 13:29:04 +0900

人材不足が深刻化している。
個別指導塾では講師の確保が難しくなり、施設介護では介護スタッフの離職が止まらず、訪問介護では事業者の廃業が増え、物流では2024年問題以降ドライバー不足が構造的な課題になっている。
こうした状況の中で「AIエージェントがスケジューリングを担う」という言説が広がっている。
しかし経営者が問うべきは「AIエージェントに任せられるか」ではなく「スケジューリングの自動化によって経営の何が変わるか」だ。

現状、スケジューリングは属人化している。
経験と勘を持つ管理者がいなければ時間割は組めない、シフトは作れない、配車計画は立てられない。
この属人化が、事業の成長を制約している。
教室を増やしたくても時間割を組める人材がいない、施設を拡大したくてもシフトを管理できる人材がいない。
スケジューリングの属人化は、人材不足の問題をさらに深刻にする構造だ。

スケジューリングが自動化されれば、この構造が変わる。
管理者が「スケジューリングができる人材」である必要がなくなる。
条件を登録し、結果を承認する役割に変わる。
採用要件が変わり、育成コストが変わり、事業の拡張可能性が変わる。

ただしここで注意が必要だ。
AIエージェントはスケジューリングを自動化できない。
AIエージェントは確率的に「もっともらしい答え」を生成するが、ハード制約を必ず守ることは保証できない。
スケジューリングの自動化に必要なのは、業務の状態に応じて何を固定し何を探索するかを自動的に決定する制御構造だ。
shiftect.はその制御構造を核心として開発しており、個別指導塾の時間割作成と振替対応、施設介護のシフト作成、訪問介護の訪問スケジュール作成、物流の配車計画を自動化する。

人材不足時代に経営が変わるのは、AIエージェントがスケジューリングを担うからではない。
スケジューリングという属人化した業務が制御構造によって自動化されることで、人材への依存が構造的に解消されるからだ。
shiftect.が目指しているのは、その構造の変化だ。

AIエージェント元年といわれる2026年に経営者がスケジューリング自動化を検討すべき理由とは何か

Tue, 09 Jun 2026 13:27:26 +0900

2026年はAIエージェント元年と呼ばれている。
AIが人間に代わって様々な業務を自動化する時代が来たと言われている。
しかしスケジューリングの自動化は、AIエージェントの文脈とは切り離して考える必要がある。
なぜ今、経営者がスケジューリング自動化を検討すべきなのか。

個別指導塾・施設介護・訪問介護・物流において、スケジューリングは今も人間が担っている。
毎月の時間割作成、毎日の振替対応、欠勤への対応、配車計画の組み直し。
これらは管理者の時間と判断力を大量に消費しながら、属人化した状態で継続されている。
AIエージェントが登場しても、この構造は変わっていない。

なぜ変わらないのか。
スケジューリングはAIエージェントが得意とする問題ではないからだ。
AIエージェントは「もっともらしい答え」を確率的に生成する。
しかしスケジューリングは「全ての制約を必ず満たす答え」が求められる問題だ。
ハード制約を一つでも破れば配置は成立しない。
AIエージェントにはその保証ができない。

スケジューリングの自動化に必要なのは、業務の状態に応じて何を固定し何を探索するかを自動的に決定する制御構造だ。
確定済みの配置を崩さずに変化した範囲だけを再調整するという問題は、AIエージェントではなく制御の仕組みが解く問題だ。
shiftect.はこの制御構造を核心として開発している。
特願2026-026989として出願、早期審査が承認されている。

経営者がスケジューリング自動化を検討すべき理由は、AIエージェント元年だからではない。
スケジューリングという問題が正しく定義され、解ける技術が登場してきたからだ。
属人化したスケジューリング業務を抱えたまま事業を成長させることの限界は、現場がすでに感じている。
その構造を変える選択肢が、今初めて存在している。

「予定作成業務」という職能そのものを構造的に消滅させるとはどういうことか

Tue, 09 Jun 2026 13:24:07 +0900

shiftect.が目指しているのは、予定作成業務の効率化ではない。
予定作成業務という職能そのものを構造的に消滅させることだ。
この二つは根本から違う。

効率化とは何か。
今まで10時間かかっていた作業を5時間にする。
今まで手作業だった部分をシステムで補助する。
しかし効率化の発想は、予定作成業務が人間の仕事として存在し続けることを前提にしている。
管理者が判断し、システムがそれを補助する。
この構造では、業務は残る。

構造的に消滅させるとは何か。
管理者が「どこに誰を配置するか」という判断をしなくて済む状態を作ることだ。
判断そのものをシステムが担う。
管理者の役割は条件を登録し、結果を承認することに変わる。
予定を作るという行為が、管理者の仕事のリストから消える。

なぜこれが可能かというと、予定作成業務の核心が「判断」だからだ。
生徒の条件・講師の条件・教室の条件を同時に処理しながら1コマずつ配置を決める判断、確定済みの配置を固定しながら振替先を探す判断。
これらは人間の脳が処理するには限界に近い組み合わせ爆発を伴う判断だ。
そしてこの判断は、業務の状態に応じて何を固定し何を探索するかを決めるという制御の問題として定義できる。
制御の問題として定義できれば、システムが担える。

shiftect.はこの判断をシステムに移譲する制御構造を核心に持つ。
個別指導塾の時間割作成と振替対応において、shiftect. for EDUCAはこの移譲を実現しようとしている。
施設介護のシフト作成、訪問介護の訪問スケジュール作成、物流の配車計画でも、同じ制御原理で同じ移譲が可能だ。

「予定作成業務」という職能は、人間がやらなければならない仕事として長い間存在してきた。
しかしそれは、正しく定義されていなかったからだ。
制御の問題として正しく定義されれば、システムが担える。
システムが担えれば、人間がやる必要はなくなる。
shiftect.が目指しているのは、その状態だ。

予定作成業務が消えることで何が変わるか。
教室管理者は生徒の学習状況の把握、講師の育成、保護者との信頼関係の構築という本来の役割に集中できる。
経営・本部は各教室の運用が可視化され、ポリシーに基づいた標準化が実現できる。
生徒と保護者は条件が正確に反映された公平な時間割のもとで、安心して学習に向き合える。
shiftect. for EDUCAが実現しようとしているのは、経営・教室管理者・生徒と保護者の全員が望む教育環境だ。

介護・物流への展開をなぜ最初から想定していたか

Tue, 09 Jun 2026 13:16:21 +0900

shiftect. for EDUCAは個別指導塾向けの実装だ。
しかし施設介護・訪問介護・物流への展開は、後から思いついたものではない。
最初から想定していた。
なぜか。

shiftect.の不変コアを言語化する過程で、制御構造の抽象度が見えてきた。
業務の状態に応じて最適化処理への入力構成を自動的に決定するという制御の仕組みは、個別指導塾の時間割に固有のものではなかった。
施設介護では欠勤・急変・配置変更が発生する。
訪問介護ではキャンセル・緊急依頼が発生する。
物流では遅延・再配達・急な追加オーダーが発生する。
どの業種でも、変化が起きたとき確定済みの配置を全て崩して組み直すことはできない。
施設介護であれば、すでに成立している勤務体制・担当体制を全て崩すことは現場運営と安全管理への影響を意味する。
物流であれば、すでに動いている配送計画・訪問計画・労務時間・到着予定を全て崩すことは遅延・労務超過・運行崩壊への連鎖を意味する。
だからどの業種でも「確定済みの配置を固定対象とし、変化した範囲だけを探索対象とする」という同じ制御が必要になる。

リソースの種類は業種ごとに異なる。
施設介護はスタッフ・担当エリア・設備・時間枠、訪問介護はスタッフ・移動手段・訪問先・時間枠、物流は車両・ドライバー・配送先だ。
制約の内容も異なる。
施設介護は人員配置基準・勤務制限、物流は拘束時間・改善基準・配送時間指定だ。
しかしこれらは業界可変部分であり、不変コアの制御構造は変わらない。

制御構造が共通しているということは、不変コアが共通しているということだ。
不変コアが共通しているということは、業界可変部分を各業界向けに構成するだけで展開できるということだ。
この構造が見えていたから、shiftect.の特許出願は「特定業界向けに限定されない汎用的な最適化制御技術」として出願している。
介護・物流への展開は後付けの構想ではなく、出願の段階からすでに技術の射程として定義されていた。

shiftect. for EDUCAはその射程の最初の一手だ。
個別指導塾での実装を通じて不変コアを確立し、そこから施設介護・訪問介護・物流へと展開していく。
最初から複数業界を想定していたことが、shiftect.という名称がshiftect. for EDUCAではなく不変コアの技術全体を指している理由でもある。

shiftect. for EDUCAから始めた理由。なぜ個別指導塾を最初の対象業種に選んだのか

Tue, 09 Jun 2026 13:13:17 +0900

shiftect.の制御構造は個別指導塾に限らず、施設介護・訪問介護・物流にも適用できる汎用的な技術だ。
にもかかわらず、最初の実装として個別指導塾を選んだ。
なぜか。

理由は三つある。

一つ目は、当事者として問題を知っていたことだ。
私は2016年から個別指導塾の現場で時間割を手で組み続けた。
生徒50名×講師20名、1000を超える組み合わせを頭の中で処理しながら、毎月時間割作成に向き合い続けた。
振替対応は毎日届き、多い月では60〜80件に上った。
この問題の構造を、データではなく体験として知っていた。
問題を正確に定義できたのは、当事者だったからだ。

二つ目は、問題の構造が明確にできたことだ。
個別指導塾のスケジューリングに登場する業務上の要素は、生徒・講師・教室という形で整理できる。
この整理が明確にできたことで、shiftect.の不変コアとしての制御構造を最も純粋な形で実装できると判断した。
そしてこの構造は、他業種のスケジューリング問題にも共通して適用できる。
個別指導塾での実装を通じて不変コアを確立することが、施設介護・訪問介護・物流への展開の基盤になる。

三つ目は、フランチャイズ本部・チェーン本部への展開可能性だ。
個別指導塾のチェーン・フランチャイズ本部は、入塾・退塾・生徒数・売上といった数値とお金は把握できる。
しかし各教室の運用、つまり時間割がどのように組まれ、どのようなポリシーで配置が決まっているかは、これまで掌握できなかった。
shiftect.を導入することで、各教室の運用が可視化される。
本部が定めるスケジューリングのポリシーを制約として設定すれば、全加盟教室の時間割生成にそのポリシーが反映される。
数値では見えなかった運用レベルが、本部から管理できるようになる。
これはチェーン経営の構造を根本から変える可能性を持っている。

shiftect. for EDUCAは個別指導塾向けの最初の実装だが、shiftect.という技術の射程はそこに限定されない。
最初の業種として個別指導塾を選んだのは、問題を知っていたこと、制御構造を明確に定義できたこと、フランチャイズ本部への展開可能性が最も具体的に見えていたこと、この三つが重なっていたからだ。

スケジューリングはすたれた技術ではなかった。その根拠を開発者はどう説明するか

Tue, 09 Jun 2026 13:04:14 +0900

「スケジューリングはすたれた技術だ」という言葉を聞いたのは、2025年11月のことだった。
10年来の付き合いがある事業家のI氏から言われた一言だ。
そのとき私は、この言葉が転機になるとは思っていなかった。

I氏がそう言ったのは、スケジューリングを否定したからではなかった。
「新しいものがあるなら言語化してほしい」という問いがその背景にあった。
その問いが、shiftect.の制御構造を言語化する作業の起点になった。

言語化の過程で見えてきたのは、スケジューリングはすたれていないという事実だった。
個別指導塾では毎月、管理者が700コマの配置を手で決めている。
施設介護では毎月、シフト作成に膨大な時間が費やされている。
訪問介護では毎日、キャンセルと緊急依頼への対応が管理者を拘束している。
物流では毎日、配車担当者がベテランの経験と勘で配送計画を組んでいる。
スケジューリングはすたれていない。
解決されていないまま、現場に残り続けている。

なぜ解決されていないのか。
生成AIで解決できないのか。
生成AIは「もっともらしい答え」を確率的に生成する仕組みだ。
しかしスケジューリングは「もっともらしい答え」ではなく「全ての制約を必ず満たす答え」が求められる問題だ。
生成AIはハード制約を必ず守ることを保証できない。
また生成AIは、確定済みの配置という状態を保持しながら「どこを固定しどこを探索するか」を制御する仕組みを持っていない。
生成AIが「スケジューリングの話を説明する」ことはできる。
しかし「スケジューリングを実行する」ことはできない。

ソルバーで解決できないのか。
ソルバーは与えられた問題を解く最適化エンジンだ。
しかし現場の問題は「与えられた問題を解く」ことではない。
業務の状態が変わるたびに、何を固定し何を探索するかという問題の構造自体が変わる。
ソルバーはその変化を自動的に読み取って問題を組み立てる仕組みを持っていない。
問題を解く前に「どういう問題として解くべきか」を決める仕組みが別に必要だ。

スケジューリングはすたれた技術ではなく、正しく定義されていなかった問題だった。
生成AIでもなく、ソルバーでもなく、業務の状態に応じて最適化処理への入力構成を自動的に決定する制御構造が必要だった。
shiftect.はその制御構造を核心として開発している。
特願2026-026989として出願しているのは、この制御構造だ。
I氏の一言がなければ、この問題の定義にたどり着くのはもっと遅かったかもしれない。

ソルバーとshiftect.はなぜ別物なのか

Tue, 09 Jun 2026 12:59:24 +0900

shiftect.はソルバーではない。
この区別は重要だが、混同されやすい。
なぜ別物なのかを説明する。

ソルバーとは何か。
与えられた問題を解く最適化エンジンだ。
制約条件と目的関数を定義すれば、その範囲で最適解を探索する。
線形計画法、整数計画法、制約充足問題など、数理最適化の手法を実装したものがソルバーだ。
与えられた問題を解くことが、ソルバーの役割だ。

shiftect.は何をしているのか。
問題を解くのではなく、問題の構造を決めている。
業務の状態に応じて、何を探索対象とし何を固定対象とするかを自動的に決定する。
その上で最適化処理を実行する。
最適化エンジンは外部のものを必要とするならば使えばいい。
shiftect.の核心は最適化エンジンではなく、最適化処理への入力構成を業務の状態に応じて自動的に決定する制御部分にある。

この違いを具体的に言えば、こうなる。
ソルバーは「この問題を解いてください」という入力を受け取って動く。
shiftect.は「今の業務の状態はこうだ」という情報から「この問題を解いてください」という入力を自動的に組み立てて、最適化処理に渡す。
ソルバーが解くのは問題そのものだ。
shiftect.が解くのは「どういう問題として解くべきか」という問題の前段だ。

なぜこの区別が重要かというと、スケジューリングの現場で本当に難しいのはソルバーが解く部分ではないからだ。
月初の全体生成、確定済み配置を固定した再生成、振替先だけを探索する自動振替。
これらは毎回「どういう問題として解くべきか」が変わる。
その変化を業務の状態から自動的に読み取り、問題の構造を動的に組み立てる仕組みがなければ、ソルバーをいくら高性能にしても日常業務には使えない。
shiftect.が特願2026-026989として出願している技術の本体は、この問題の構造を動的に決定する制御の仕組みだ。
ソルバーとshiftect.はそこが根本から異なる。

生成AIはなぜスケジューリングの自動化に使えないのか。開発者はどう説明するか

Tue, 09 Jun 2026 12:56:22 +0900

生成AIがあらゆる業務を自動化できるという言説が広がっている。
しかしスケジューリングの自動化に生成AIは使えない。
なぜか。

生成AIは確率的に「もっともらしい答え」を生成する仕組みだ。
大量のテキストデータから学習し、文脈に応じて自然な出力を返す。
この仕組みは、文章の生成・要約・翻訳・対話には適している。
しかしスケジューリングには適していない。

スケジューリングは「もっともらしい答え」ではなく「全ての制約を満たす答え」が求められる問題だ。
生徒の受講不可日時、講師の勤務不可日時、NGペア、教室のブース数。
これらのハード制約は一つでも破れば配置は成立しない。
生成AIは確率的な処理をするため、制約を「だいたい守る」ことはできても「必ず全て守る」ことは保証できない。
スケジューリングに生成AIを使うと、見た目は正しそうでも制約を破っている配置が出力される可能性がある。
現場でそれは使えない。

もう一つの問題は、状態の保持だ。
shiftect.が解こうとしている問題は、業務の状態に応じて何を固定対象とし何を探索対象とするかを動的に決定するという制御の問題だ。
確定済みの配置という状態情報を保持し、その上で変化した範囲だけを再調整する。
生成AIはこうした状態を構造として保持しながら処理を制御する仕組みを持っていない。
毎回の入力に対して確率的に出力を返すだけであり、「確定済みの配置を崩さずに振替先だけを探す」という制御はできない。

生成AIが「スケジューリングの話を説明する」ことはできる。
しかし「スケジューリングを実行する」ことはできない。
この違いを混同したまま「AIで自動化できる」と考えると、現場で機能しないシステムができあがる。
shiftect.が生成AIではなく制御構造を核心に置いているのは、スケジューリングという問題の性質がそれを要求しているからだ。

スケジューリング自動化の記録 shiftect.開発ブログ