2026.09.01 業務システム

オンライン塾システムとは：配信・予約・教材の機能範囲と塾管理システムとの連携で決める選び方

オンライン塾システムという言葉は、実際には四つの別物を指しています。授業を映す配信、受講枠を押さえる予約、教材と課題を届ける配信、そして誰がどこまで進んだかを見る進捗可視化です。この四つを一つの製品で揃えようとすると要件が膨らみ、逆に会議ツールだけで始めると出席と月謝の根拠が崩れます。本記事では、対面の塾運用をオンラインへ移すときにどこで詰まるのかを先に示し、既存の塾管理システムとの連携をどう設計するか、既製サービスの組合せで足りるのはどんな塾かを、受託開発会社の視点で線引きします。

まとめ：オンライン塾システムの機能範囲と導入判断の結論

機能は四層に分けて考える：授業配信（ライブ／録画）、受講予約、教材・課題配信、進捗可視化。全部を一製品に求めず、どの層を既存システムに任せるかを先に決めます。
先に決めるのは出席の定義：オンラインでは入退室の打刻が使えません。何分の接続で出席とするか、録画視聴を出席に含めるかを決めないと、月謝と振替の根拠が作れません。
生徒台帳は二つ持たない：既に塾管理システムがあるなら、生徒・保護者マスタはそちらを「正」として、配信側にはID配布と受講履歴だけを持たせる構成が扱いやすくなります。
費用は課金単位で決まる：会議ツールと既存システムの組合せなら月数千円規模、配信専用プラットフォームを足すとID数とストレージの従量が乗ります。映像制作まで外部に出す公開例では初期173万円台・月15万円台という水準もあります（2026年9月時点）。
組合せで足りる条件：同時受講が100名以内、受講ルールが数行で書ける、請求は既存システムのまま。この三つが揃うなら既製サービスの組合せで足ります。
開発に踏み込む条件：既存台帳との双方向連携が必要、コースごとに受講権限や視聴期限が違う、映像本数が数百規模に育つ。いずれかが該当するなら受託開発を検討する段階です。
見送るべき場面：対面のコマ表と月謝の突合が今も手作業なら、オンライン化より先にそこを直したほうが投資効率が上がります。

オンライン塾システムの機能範囲を配信・予約・教材・進捗の四層で捉える

製品比較の記事を読むと機能一覧が横並びで並びますが、塾側が本当に決めるべきなのは「どの層を何に任せるか」です。四層のうち二層は既に手元のシステムが持っている場合が多く、重複して買うと運用が二重になる原因です。ここでは層ごとに、何が変わり何が必要になるのかを整理します。学習の仕組みそのものの考え方はeラーニングとはで扱っているため、本記事は塾の運用に寄せて説明します。

ライブ配信と録画配信で変わる運用負荷と必要になる設備の範囲を見極める

ライブ配信は、対面の時間割をそのまま維持できる代わりに、講師と生徒の双方に安定した回線が必要です。板書をカメラで映すのか、画面共有で資料を出すのかで必要な機材が変わり、書画カメラや外部マイクの用意が現実的な検討対象になります。一方で録画配信（オンデマンド）は時間の制約を外せますが、映像を撮る・切る・差し替えるという制作の工程が新しく増えます。
判断の目安はこうです。集団指導で同時に同じ内容を教えているなら、まずライブから始めるほうが運用の変更を小さく抑えられる選択です。個別指導や自習支援が主体で、生徒ごとに進む速度が違う塾では、録画配信のほうが講師の時間を空けられます。両方を並行させる場合は、同じ授業を二度作らないよう「ライブを録って後日配信する」型に寄せると制作負荷が抑えられます。

受講予約をオンライン枠と配信の入口へ結び付けるときの設計と確認項目

対面の予約は、講師と座席という物理の資源を押さえる行為でした。オンラインでは座席がなくなる代わりに、配信の入口（会議URLや視聴ページ）が予約と結び付いていなければ、生徒はどこに入ればよいか分かりません。予約の完了通知に入口を載せ、直前のリマインドでもう一度届けるところまでを一続きで設計します。
個別指導のコマ予約や三者面談のように、対面の講師・座席割当が主題になる予約は塾予約システムの領域です。本記事で扱うのは、そこで押さえた枠にオンラインの入口をどう紐付けるかという接続部分に限ります。両者を混ぜて一つの製品に求めると、要件が膨らんで選定が止まります。

教材と課題の配信、そして進捗の可視化はどこまで自動で回るかの判断基準

教材配信は、PDFや動画を置くだけなら難しくありません。運用が崩れるのは、配布した教材の版が変わったとき、そして提出物の回収が始まったときです。学年やコースごとに配布先を分ける仕組みがないと、講師が個別にファイルを送る作業へ戻る結果です。
進捗の可視化についても、期待値を先に下げておく必要があります。多くの配信サービスが持つのは受講履歴とテスト結果までで、理解度の判定は塾側の設計に依存します。視聴完了率と小テストの正答率を並べて見られる状態を最初の目標に置き、そこから面談で使う指標を足していく順序が現実的です。

対面の運用をそのままオンラインへ持ち込むと導入時に詰まる三つの点

ここが本記事の主題です。オンライン塾システムの導入が止まる原因は、製品の機能不足よりも、対面前提のデータ構造と運用ルールを持ち込んだことにあります。三つの詰まり方には共通の対処があり、いずれも「システムを選ぶ前に決める」ものです。

教室と座席を前提にしたコマ表が配信の入口と結び付かない問題への対処

対面のコマ表は「いつ・どの教室の・どの席で・誰が」という形で組まれています。オンラインの受講枠にこの構造を流用すると、教室と座席の欄が空のまま残り、代わりに入るべき配信URLの置き場所がありません。結果として、講師が毎回URLをメールやチャットで個別に送る運用に落ち、送り忘れが出席の欠落として記録されます。
対処は、枠の定義に「受講形態」という属性を一つ足すことです。対面・オンライン・併用の三値を持たせ、オンラインの枠だけ入口の欄を必須にします。既存の塾管理システムがコマ表を持っているなら、その枠にメモ欄でよいので入口を書き込める場所を作り、配信側の予定表と突き合わせる担当を一人決めておきます。

入退室の打刻が使えなくなり月謝と振替の根拠が薄くなる問題への対処法

対面の塾では、入退室の打刻がそのまま出席の記録になり、月謝や振替の根拠として機能していました。打刻方式そのものの比較は塾入退室システムで扱っていますが、オンラインではこの根拠が消えます。会議ツールの参加ログは残るものの、接続したまま席を離れたケースと、通信が切れて再入室したケースを区別しません。
先に決めるべきは三点です。第一に、何分の接続をもって出席とみなすか。第二に、録画視聴を出席に含めるのか、含めるなら視聴期限をいつまでにするか。第三に、接続不良で受講できなかった場合を欠席とするか振替とするか。この三点を文章にしてから製品を見ると、必要なログの粒度が決まり、比較が短時間で終わります。決めないまま導入すると、保護者からの問い合わせのたびに講師が個別判断する状態が固定化します。

保護者への状況共有が授業ごとに切れて問い合わせが増える問題への対処

対面では、送り迎えや教室での立ち話が状況共有の役割を担っていました。オンラインに移すと、保護者から見える情報は請求書だけになりがちです。ここで問い合わせが増え、講師の時間が事務対応に流れてしまいます。
共有の窓口は一つに絞る方針です。受講履歴と課題の提出状況を保護者が自分で見られる画面があるなら、連絡はそこへ集約する形です。画面を用意できない段階では、月次でまとめて送る形に固定し、個別のチャットで都度答える運用は避けます。窓口が二つ以上あると、どちらに書いたか分からない状態が生まれ、記録としても使えなくなります。

既存の塾管理システムと連携させて生徒台帳を二重に持たない設計

既に生徒台帳や請求の仕組みを持っている塾では、配信サービスを足した時点でマスタが二つになる構造です。ここを放置すると、入塾・退塾・コース変更のたびに二度入力する運用が定着し、片方が古いまま残ります。全体の機能構成と費用の考え方は塾管理システムとはで整理しているので、本節は接続部分に絞ります。

生徒と保護者のマスタをどちらのシステムに寄せるかの決め方と判断軸

原則として、請求が発生する側が「正」です。月謝の請求が塾管理システムから出ているなら、生徒・保護者の氏名や連絡先はそちらを唯一の入力先とし、配信側にはログインに必要な情報だけを渡します。配信側で氏名を編集できる状態を残すと、そこが必ず食い違いの発生源になるため、可能なら編集権限を閉じます。
逆に、請求も含めて配信プラットフォーム側で完結させる小規模な塾であれば、正を配信側に置いても構いません。避けるべきなのは「どちらも正」という状態です。二つの台帳を人の目で合わせる運用は、生徒数が100名を超えたあたりで確実に破綻します。

受講履歴と月謝・回数券の請求をつなぐ最小限の連携ポイントを決める方法

連携は、全項目を同期させるより、請求の根拠になる数字だけを渡す形が壊れにくい構成です。具体的には、月次で「生徒ID・受講回数・視聴完了本数」の三つを配信側から出し、既存システムの請求処理に取り込む方式です。回数券や都度課金を採っている塾では、この受講回数が売上そのものになるため、締め日と数え方の定義を先に合わせておきます。
連携の手段は、APIで自動化するのが理想ですが、初期はCSVの月次取り込みで足ります。自動化の判断は、月末の作業時間が2時間を超えたかどうかで測ると迷いません。それ未満なら手作業のほうが安く、超えたなら開発費を回収できる見込みが立ちます。

IDの配布と停止の運用、卒塾時に残る受講履歴の扱いと確認項目

ID運用で見落とされやすいのが停止処理です。退塾や卒塾でIDを止め忘れると、ID数課金のサービスでは費用が下がらず、教材へのアクセスも残ります。入塾時の配布手順と同じ丁寧さで、停止の手順と実行タイミング（月末締めなど）を事前に決める対象です。
一方で、受講履歴は消さずに残す判断が向いています。卒塾生の成績推移は次年度のコース設計の材料になり、講師の指導実績としても参照されます。IDは停止し履歴は残す、という二段構えにできるかどうかは製品によって差が出るため、比較の段階で確認しておく項目です。

オンライン塾システムの費用構造と、教室規模ごとに変わる総額の見方

費用は「何にいくら」ではなく「何を単位に課金されるか」で見るのが、規模変化時の総額を読む基準です。オンライン化では、生徒数が増えたときに効く単位と、映像本数が増えたときに効く単位の二つが同時に動きます。製品ごとの価格帯そのものは学習塾管理システムの比較で扱っているため、ここでは配信を足すことで増える部分を見ます。

会議ツールと既存システムの組合せで収まる範囲とその限界の判断基準

最も安く始められるのは、Web会議ツールと既存の塾管理システムを組み合わせる形です。Zoom Workplaceの公式料金ページでは、無料のベーシックが1会議100名まで、ビジネスが300名までと記載されています（2026年9月時点の表記。金額は年額と月払いの切替表示のため、ここでは人数上限だけを示します）。集団指導で同時受講が100名に届かないなら、この構成で運用可能です。
限界は二つの形で来ます。一つは録画の保管で、授業を蓄積し始めると保存容量と検索性がすぐ足りなくなります。もう一つは視聴の記録で、会議ツールの参加ログからは「誰がどの動画をどこまで見たか」が取れません。この二つが必要になった時点が、配信専用の仕組みを足す境目です。

配信プラットフォームを足す場合の課金単位と増え方の読み方と判断軸

配信専用のサービスは、利用ID数とストレージ容量を課金単位に置くものが多くを占めます。ID数は生徒数に比例するため予測が立てやすい一方、ストレージは映像の長さと画質で伸び方が変わり、見落とされやすい部分です。
たとえば1本30分・画質1Mbps程度の映像は、単純計算で1本あたり200MB台になります。週2本の配信を1年続ければ100本規模に達し、保存容量は20GBを超える計算です。公開されている料金例では、100GBを超えた分を1GBあたり1,000円で加算する形が示されており（2026年9月時点）、映像を消さずに積み上げる運用だと、この従量が数年後の固定費として乗ってきます。過去年度の映像を残すのか毎年入れ替えるのかを、契約前に決めておく価値があります。

映像制作までまとめて外部に出す場合の費用水準と向く塾を判断する基準

撮影・編集・配信基盤をまとめて外部に委ねる選択もあります。公開されている料金例では、塾の動画授業向けの構成で初期費用1,731,400円（税込）・月額153,670円（税込）という水準が示されています。条件は映像編集の制作36本・1本30分・画質1Mbps・利用110人で、課金単位は利用ID数とストレージ容量です（2026年9月時点の公開表記）。
この水準が見合うのは、映像そのものを商品として売る塾、つまり通塾生以外にも配信して受講料を取るモデルです。逆に、通塾生の補助として録画を配る目的なら、講師が自分で撮って編集を最小限にする形のほうが投資効率が上がります。制作を外に出す判断は、映像の品質が申込率に影響するかどうかで分かれます。

既製サービスの組合せで足りる条件と、開発に踏み込むべき条件の線引き

ここまでの整理をもとに、判断を条件で言い切ります。生徒数の多さは開発の理由になりません。分かれ目は、受講のルールを文章で書き切れるか、そして既存システムとの間で人が転記する作業が残るかどうかです。

既製サービスの組合せでそのまま運用に乗せられる塾の三条件を見極める基準

次の三つが揃うなら、既製サービスの組合せで足ります。第一に、同時受講が100名以内で、教室単位のライブ配信が主体であること。第二に、受講のルール（出席の定義、振替の締切、視聴期限）が数行で書き切れること。第三に、請求は既存の塾管理システムのままで、配信側からは月次の受講回数だけを受け取れば足りること。
この条件に当てはまる塾が開発に進むと、既製品なら設定で済む部分に費用を払うことになります。まず組合せで3か月運用し、詰まった箇所だけを対象に開発を検討する順序を勧めます。

受託開発やカスタマイズに踏み込むべき条件と費用・期間の目安を見極める基準

次のいずれかに当てはまるなら、既製品のカスタマイズ範囲を超えます。既存の生徒台帳と双方向で同期する必要がある場合、コースや学年ごとに受講権限と視聴期限が細かく分かれる場合、そして映像本数が数百規模に育ち検索と差し替えの運用が必要な場合です。加えて、複数校舎で同じ映像を共有しながら請求は校舎別に立てる、といった要件も開発側に寄ります。
配信と受講管理に絞った小規模な開発であれば、要件定義から本番稼働まで3か月から5か月程度が目安です。既存システムとのAPI連携を含める場合は、相手側の仕様調査に時間を取るため、この目安に1か月から2か月を足して考えます。eラーニングシステム開発（LMS）では、受講管理と配信を含む構築の進め方を扱っています。

オンライン化そのものを先に見送るべき場面と、直す順序を判断する基準

投資の順序として、オンライン化を後回しにすべき場面があります。対面のコマ表と月謝の突合が今も手作業で、月末に数時間かかっている塾です。この状態でオンラインの受講記録が増えると、突合の対象が二つになり作業時間が伸びます。
同じく、講師のシフトが紙や表計算で管理され、担当変更が口頭で伝わっている段階でも見送りが妥当です。オンラインの枠は担当講師と入口が結び付いていないと成立せず、口頭の変更が入口の付け替え漏れとして表に出ます。まず対面側の記録を一元化し、そのうえで配信を足す順序のほうが、結果として早く回り始めます。

導入の進め方と、稼働後に見直す指標の置き方を塾内でそろえる方法

最後に、進め方を三段に分けて示します。要件を広く集めるより、決めるべき三点を先に固定して小さく始めるほうが、稼働までの時間が短くなります。

比較を始める前に文章で固定しておく三つの決めごとと製品比較の条件

製品を見る前に、配信形式（ライブ主体か録画主体か併用か）、出席の定義（接続時間と録画視聴の扱い）、保護者連絡の窓口（どの画面かどの頻度か）の三点を文章で固定する作業が先です。この三点が決まっていれば、比較で見る機能は10個程度に絞られ、候補も3製品前後に収まります。
逆に、機能一覧を横並びにして丸を数える比較は避けます。塾ごとに使わない機能が半分近くあり、丸の数は選定の根拠になりません。決めごとを書いた文章を、そのまま各社への質問状として使うと回答の比較もそろいます。

試験配信の段階で実測しておく三つの数字と合格の目安を判断する基準

本格導入の前に、1コース・2週間程度の試験配信を行い、三つの数字を取ります。接続の失敗率（入室できなかった件数を受講予定数で割る）、視聴の完了率（録画を最後まで見た割合）、そして講師の準備時間（1コマあたりの配信準備に要した分数）です。
目安として、接続失敗率が5%を超えるなら、機材か案内文のどちらかに原因が残っています。視聴完了率が5割を下回る録画は、長さを分割するか要点を先に出す構成へ作り直す対象です。講師の準備時間が1コマ15分を超えるなら、テンプレート化か担当の分担で削ります。

稼働から3か月後に見直す枠設計と、続けるかを決める判断材料の確認方法

稼働後3か月の時点で、受講枠の稼働率と振替の発生率を見ます。稼働率が低い枠は時間帯そのものが合っていないため、枠を減らして別の時間帯へ寄せます。振替の発生率が高い枠は、締切ルールが運用に合っていない兆候です。
続けるかどうかの判断材料は、対面のみで運用していた期間と比べた講師の総稼働時間と、退塾率の二つに置きます。配信を足したことで講師の時間が増え続け、退塾率が下がっていないなら、機能を足すのではなく対象コースを絞る方向へ舵を切ります。オンライン化は全コースに広げることが目的ではなく、通塾が難しい生徒を取りこぼさないための手段です。

よくある質問

オンライン塾システムは会議ツールだけで足りますか？

同時受講が100名以内で、録画の蓄積と視聴記録を求めないなら足ります。Zoom Workplaceの公式表記では、無料のベーシックが1会議100名まで、ビジネスが300名までとされています（2026年9月時点）。足りなくなる境目は二つで、授業の録画を蓄積して後から配信し始めたときと、誰がどこまで見たかを月謝や面談の根拠にしたくなったときです。この二つが出てきた段階で、配信専用の仕組みを足す検討に入ります。

既存の塾管理システムがある場合、入れ替えたほうがよいですか？

入れ替えは勧めません。生徒台帳と請求が動いているなら、それを「正」のまま残し、配信の層だけを足す構成が安全です。入れ替えると、過去の請求履歴と成績の移行という別のプロジェクトが同時に走ることになり、オンライン化の稼働が半年単位で遅れます。連携は初期はCSVの月次取り込みで足り、月末の作業が2時間を超えた時点で自動化を検討する順序が扱いやすくなります。

オンライン受講の出席はどう記録すればよいですか？

入退室の打刻が使えないため、塾側で定義を決める必要があります。実務で使いやすいのは、ライブなら「授業時間の半分以上の接続で出席」、録画なら「配信から1週間以内の視聴完了で出席」という二本立てです。接続不良の扱いも同時に決めます。生徒側の通信起因は振替、塾側の配信起因は無条件で振替、と分けておくと、問い合わせのたびに判断する状態を避けられます。

映像の保存容量はどれくらい見ておけばよいですか？

1本30分・画質1Mbps程度なら、単純計算で1本200MB台です。週2本を1年続けると100本規模・20GB超に達する計算です。公開されている料金例では100GBを超えた分に1GBあたり1,000円を加算する形が示されており（2026年9月時点）、映像を年度をまたいで残すかどうかで数年後の固定費が変わります。過去年度分は画質を落として保管する、あるいは入れ替える、という方針を契約前に決めておくと予算が読めます。

自社開発に踏み込むべきなのはどんな場合ですか？

生徒数の多さは理由になりません。分かれ目は三つで、既存台帳との双方向同期が必要な場合、コースや学年ごとに受講権限と視聴期限が細かく分かれる場合、映像本数が数百規模に育つ場合です。配信と受講管理に絞った開発なら要件定義から稼働まで3か月から5か月程度が目安で、既存システムとのAPI連携を含めるならさらに1か月から2か月を見ます。いずれにも当てはまらない塾は、既製サービスの組合せで足ります。