Виртуальный класс: что это и чем он отличается от встречи

Автор: Николай СапуновОбновлено: август 202617 мин чтения
Содержание статьи +

Это инженерные рекомендации, а не юридическая консультация. Детали подтверждайте у профильных юристов.

Кратко

Виртуальный класс – программа для живого онлайн-занятия с преподавателем. Это не видеовстреча с логотипом курса: класс добавляет учебные роли, посещаемость, которая становится частью учебных данных, малые группы, общую учебную доску и запись занятия, которая остаётся в истории обучения ученика. Под капотом инструмент встреч и класс работают на одном движке реального времени – WebRTC, но класс оборачивает его в учебную структуру, для которой инструмент встреч не предназначен. Решение «создавать или покупать» сводится к одному вопросу: нужна ли эта структура глубоко встроенной в продукт и систему обучения или достаточно готовой российской ВКС либо развёрнутого open-source-класса. В статье – что на деле означает каждая функция класса, почему задержка в обучении важнее, чем на встрече, что меняют 152-ФЗ и правила для школ и сколько стоит создать виртуальный класс по сравнению с покупкой готового.

Зачем это читать

Если вы отвечаете за обучение в компании, основали EdTech-продукт или владеете каталогом курсов, живое занятие – место, где ваш самый дорогой ресурс, время преподавателя, встречается с учениками. Именно здесь разница между «подключили готовую видеосвязь» и «построили класс» сказывается на доле завершивших курс, на соответствии требованиям и на стоимости. Команды, которые считают эти варианты взаимозаменяемыми, выпускают встречу с логотипом, а при проверке выясняется, что они не могут доказать, кто присутствовал, не могут повторно использовать запись как учебный материал и не могут перевести ученика в нужную группу. Здесь вы найдёте язык, чтобы отличить настоящий виртуальный класс от встроенной встречи, архитектуру для постановки задачи инженерам и цифры для разговора с финансовым директором. Это базовая статья блока о живом обучении: все следующие статьи опираются на описанные здесь различия.

Что такое виртуальный класс

Начнём с простого. Виртуальный класс – программа, в которой преподаватель ведёт живое занятие для учеников через интернет. Все видят и слышат друг друга в реальном времени, преподаватель показывает материал и пишет на общей доске, ученики поднимают руки и отвечают, малые группы расходятся и возвращаются, а всё занятие записывается и учитывается в курсе. Это онлайн-версия урока по расписанию, а не телефонный звонок.

Возьмём одну аналогию на всю статью. Видеовстреча – переговорная, которую вы бронируете: люди заходят, разговаривают, а после их ухода комната ничего не помнит. Виртуальный класс – это занятие: в нём есть преподаватель и ученики с разными задачами, журнал посещаемости, групповая работа, доска, которая сохраняется, и запись, которая остаётся в истории обучения каждого ученика. Материалы те же – камеры, микрофоны, экраны, – но сущности совершенно разные.

Разница структурная, и функциями, которые можно «прикрутить», её не закрыть. Инструмент встреч представляет всех как равных «участников» одного временного пространства. Класс оперирует ролями, зачислением, посещаемостью, группами и учебными данными, и каждая из этих сущностей – отдельная инженерная задача поверх живого видео, а не галочка в настройках.

Рис. 1. Встреча и класс на одной видеооснове. Встреча – одна плоская временная комната. Класс добавляет пять вещей, для которых инструмент встреч не предназначен: учебные роли, посещаемость как учебные данные, постоянные малые группы, сохраняемую учебную доску и запись, которая остаётся в истории обучения ученика.

Пять вещей, которые класс добавляет, а встреча – нет

Один простой вопрос отсекает все подборки «лучшее ПО для виртуальных классов»: инструмент просто соединяет людей или поддерживает структуру занятия? Отличают одно от другого пять дополнений.

1. Учебные роли, а не равные участники

На встрече у всех примерно одинаковые права; «организатор» нужен в основном, чтобы начать звонок и выключить кому-нибудь шумный микрофон. В классе роли разные, и их возможности намеренно неравны – в этом и смысл. Преподаватель ведёт занятие, даёт слово, перемещает учеников между группами и завершает занятие с сохранением записи. Ассистент помогает вести занятие: собирает вопросы, следит за чатом, запускает опросы, помогает ученику настроить звук, – но занятием не управляет. Ученик участвует в рамках, которые задал преподаватель: поднимает руку вместо того, чтобы самому включать микрофон, отвечает в опросах, пишет на доске, только когда ему дали слово.

Асимметрия касается и того, кто кого видит. В специализированных классах преподаватель и ассистент видят всех учеников и управляют ими, а ученик обычно видит преподавателя, общий материал и только тех одноклассников, кого предусматривает сценарий занятия. Правильно описать роли – кто что может и кто кого видит – значит построить систему прав. Ошибка здесь – и «класс» снова превращается в хаотичную встречу.

Рис. 2. Модель ролей и прав. Преподаватель распоряжается словом и записью; ассистент помогает вести занятие, но не управляет им; ученик участвует в рамках, заданных преподавателем. Инструмент встреч сводит всех троих к одному «участнику» с добавленным «организатором».

2. Посещаемость как учебные данные

Инструмент встреч может выгрузить список того, кто и когда зашёл. Класс превращает эти сырые данные о входе в посещаемость – факт о прогрессе ученика, который система обучения может сохранить, показать в отчёте и использовать дальше. Разница важна, потому что в обучении посещаемость часто служит доказательством. Например, того, что сотрудник прошёл обучение по охране труда (ПП 2464 допускает для него дистанционные технологии, кроме практических занятий по первой помощи, применению СИЗ, на полигонах и тренажёрах, а результаты проверки знаний вносятся в реестр обученных лиц Минтруда в течение трёх рабочих дней). Или того, что слушатель повышения квалификации действительно занимался до выдачи удостоверения, а студент выполнил объём контактной работы.

В терминах стандартов это разница между лог-файлом и учебным утверждением. Experience API (xAPI) – стандарт учебных данных, который описывает короткие структурированные записи вида «Мария присутствовала на живом занятии 2026-06-20»; они сохраняются в Learning Record Store (LRS) – базе для таких записей. (Подробная механика – в статьях трекинг видео через xAPI Video Profile и основы метрик обучения.) Класс изначально выдаёт посещаемость как учебные данные, а инструмент встреч отдаёт CSV и оставляет интеграцию вам.

Как только посещаемость позволяет установить личность ученика, у неё появляется и юридический вес. Журнал присутствия с ФИО – персональные данные по 152-ФЗ «О персональных данных», и отсюда три инженерных требования. Первое: с 1 июля 2025 года собирать и хранить ПДн граждан России с использованием баз данных за пределами РФ нельзя (ч. 5 ст. 18), поэтому журнал, LRS и резервные копии – только в российском контуре. Второе: если обработка основана на согласии, с 1 сентября 2025 года его оформляют отдельно от других документов (ч. 1 ст. 9), а за несовершеннолетнего согласие дают законные представители. Третье: утечка обойдётся юрлицу в 3–15 млн ₽ в зависимости от числа записей, а повторная – в 1–3% выручки (ст. 13.11 КоАП в ред. 420-ФЗ). Поэтому посещаемость – защищаемые данные, а не разовая выгрузка.

3. Малые группы, иногда постоянные

Разбивать людей на комнаты поменьше умеют и встречи, и классы. Учебная разница в том, что классу часто нужны постоянные группы: одни и те же четыре ученика работают вместе на разных заданиях и занятиях, а не перемешиваются случайно каждый раз. Постоянные группы позволяют потоку строить работу на общем результате; разовые комнаты годятся, например, для знакомства. Инженерная задача в обоих случаях настоящая: распределить учеников, перевести кого-то в другую группу посреди занятия, разослать сообщение во все комнаты, запустить таймер и аккуратно вернуть всех в общий зал. Это задача управления состоянием, и при реальной текучке в классе она ломается самым неприятным образом. Подробный разбор – в статье сессионные залы: дизайн, состояние и возврат в общий зал.

4. Учебная доска, а не только демонстрация экрана

Встреча показывает экран. Классу нужен общий холст, на котором ведёт занятие преподаватель, а иногда пишут и ученики. Такая доска синхронизируется в реальном времени, не путается, когда рисуют двое одновременно, сохраняется при переподключении и экспортируется в запись занятия. Синхронизация с разрешением конфликтов – задача другого рода и сложнее трансляции экрана, ей посвящена отдельная статья: интерактивная доска и общий холст. Демонстрация экрана, пригодная для преподавания (высокая частота кадров для показа программ, выделение, управление слайдами), – тоже отдельная дисциплина: демонстрация экрана для преподавания.

5. Запись занятия как учебный материал

Запись встречи – файл, который вы, возможно, сохраните. Запись занятия – учебный материал: её обрезают, разбивают на главы, перекодируют для каталога и привязывают к курсу, чтобы пропустившие могли посмотреть, а следующий поток – использовать повторно. Этот конвейер постобработки и то, как живая WebRTC-сессия превращается в видео по запросу, – тема статьи запись живых занятий и постобработка для каталога.

С записью снова возникает вопрос приватности. Лицо и голос ученика, который задаёт вопрос или выступает, делают запись носителем его персональных данных. Разумная инженерная политика: хранить записи в России, открывать их только участникам того же курса или группы, задать срок хранения и удалять записи по его истечении, а при публикации в открытом каталоге вырезать фрагменты с учениками. Если же вы начинаете распознавать лица на записи, чтобы идентифицировать учеников, это уже биометрия со своими правилами: письменное согласие (ст. 11 152-ФЗ) и работа через Единую биометрическую систему (572-ФЗ).

Под капотом: один движок, разные машины

Вот что удивляет большинство нетехнических покупателей: инструмент видеовстреч и виртуальный класс обычно работают на одном и том же движке реального времени. Это WebRTC (Web Real-Time Communication) – браузерный стандарт передачи живого аудио, видео и данных между участниками с очень малой задержкой. WebRTC 1.0 стал рекомендацией W3C 26 января 2021 года. Он задаёт JavaScript-интерфейсы, которые браузеры предоставляют для медиа реального времени, и опирается на стек протоколов, описанный IETF для браузерной связи реального времени (W3C, «WebRTC 1.0: Real-Time Communication Between Browsers», Recommendation, 2021; IETF RFC 8825). WebRTC встроен в каждый современный браузер, поэтому ученик заходит на занятие по ссылке – без плагинов и установки.

Как устроен WebRTC, здесь не разбираем: это задача раздела Video Streaming. Если нужны подробности протокола (как участники находят друг друга, как шифруется медиа, как медиасервер раздаёт видео многим зрителям), читайте WebRTC без зауми и топологии SFU, MCU и mesh. Подводные камни, характерные именно для класса, разбирает следующая статья блока – WebRTC для живого обучения. Здесь нам нужен один вывод: движок общий, а отличается то, что построено вокруг него.

Класс добавляет учебные подсистемы поверх общего медиаслоя. Слой сигналинга и сессий знает о зачислении и ролях, а не только о том, «кто на звонке». Сервис состояния групп отслеживает, кто в какой группе. Сервис синхронизации доски поддерживает согласованность холста. Мост посещаемости и трекинга пишет учебные данные. Конвейер записи готовит материал для каталога. А мост к системе управления обучением (LMS) связывает занятие с курсом. Ничто из этого не относится к WebRTC – и именно это делает класс классом.

Рис. 3. Подсистема виртуального класса. Медиапуть WebRTC (клиенты → сигналинг → медиасервер) такой же, как у любого инструмента встреч, и подробно разобран в разделе Video Streaming. Классом его делают учебные подсистемы вокруг: роли, состояние групп, синхронизация доски, посещаемость, запись и мост к LMS/LRS.

Почему задержка в обучении важнее

Малая задержка нужна и встречам, и классам, но обучение прощает меньше. Когда преподаватель задаёт вопрос и ждёт поднятых рук, полсекунды задержки оборачиваются неловкими паузами и перебиванием. Когда ученик отвечает, а преподаватель реагирует с опозданием, живой обмен репликами, на котором держится занятие, рассыпается. WebRTC создан как раз для этого: он рассчитан на задержку меньше секунды от камеры до экрана (glass-to-glass) – обычно несколько сотен миллисекунд при нормальном соединении. Поэтому интерактивные части занятия по умолчанию идут через WebRTC, а не через протокол вещания с задержкой в секунды. Для ориентира: круговая задержка 200 миллисекунд ощущается как обычный разговор, а 2 секунды – как звонок по спутниковому телефону. Бюджет задержки и причины, по которым его трудно удержать в школьных и корпоративных сетях, разобраны в статьях WebRTC для живого обучения и масштабирование живого класса.

Инструмент встреч и виртуальный класс: сравнение

Ниже различия, разложенные по тому, что действительно нужно учебной команде. Вопрос «создавать или покупать» чаще всего решает строка «Стандарты / LMS»: учебный продукт живёт или умирает в зависимости от того, попадают ли данные занятия в систему обучения.

ВозможностьИнструмент встречВиртуальный класс
Модель участниковРавные участники + организаторРоли преподавателя, ассистента и ученика, намеренно неравные
ПосещаемостьЛог входа/выхода (CSV)Посещаемость как учебные данные
Малые группыРазовые, состав каждый раз новыйРазовые и постоянные группы потока
Общая доскаДемонстрация экранаСовместная доска реального времени с сохранением
ЗаписьФайл, который вы хранитеОбработанный материал каталога, привязанный к курсу
Стандарты / LMSВстроенной поддержки нет; интеграцию делаете выДанные xAPI/cmi5, запуск по LTI, передача в LMS
СоответствиеОбычная конфиденциальность звонкаПДн в РФ по 152-ФЗ, реестр российского ПО, живые субтитры (WCAG 2.1 / ГОСТ Р 52872-2019)
Где уместноПереговоры, демо, гибридные встречиКурсы с преподавателем, обязательное обучение, потоки

Отметим две строки. Стандарты / LMS: типичные инструменты встреч не выдают учебных данных. Класс либо сам формирует данные xAPI/cmi5 и поддерживает запуск по LTI (стандарт безопасного запуска инструмента внутри любой LMS – см. LTI: объяснение), либо эту интеграцию вы строите сами. Соответствие: для образовательных организаций ПП 1678 требует, чтобы ПО видеоконференцсвязи в составе дистанционных технологий создавалось и использовалось по законодательству РФ и (или) входило в реестр российского ПО (п. 21), а порядок использования средств связи организация закрепляет в локальном акте и публикует на сайте (п. 20). Доступность – тоже не приятный бонус. Живые субтитры для синхронного занятия требует критерий 1.2.4 (Captions, Live) уровня AA из WCAG 2.1. На WCAG 2.1 основан ГОСТ Р 52872-2019, который становится обязательным, если заказчик включает его в техническое задание, а вуз по ст. 79 273-ФЗ обязан создавать специальные условия для студентов с ОВЗ, включая услуги сурдопереводчика.

Цифры: создать или купить виртуальный класс

«Создавать или покупать» – финансовое решение в технической обёртке, поэтому посчитаем. Цифры ниже – инженерные оценки 2026 года; сверьте их со ставками своей команды, но главное здесь – структура затрат.

Реальных путей три. Встроить SDK или API российской ВКС (например, TrueConf SDK, SaluteJazz SDK или Voximplant): запуск быстрый, но вы получаете модель встречи и сами строите поверх все учебные подсистемы – роли, учёт посещаемости, постоянные группы, мост к LMS. Строить на открытой WebRTC-инфраструктуре (свой медиасервер на mediasoup, LiveKit OSS или Jitsi плюс учебные подсистемы, в российском облаке или на своих серверах): максимум контроля, никаких ограничений по числу мест и самые большие вложения в разработку. Купить или развернуть готовую платформу. Российские ВКС – МТС Линк (облако и коробочная версия), Яндекс Телемост (до 1 000 участников, трансляции до 10 000 зрителей), Контур.Толк (серверы в РФ), IVA, TrueConf (on-prem, в реестре российского ПО), SaluteJazz – дают надёжную видеосвязь, но насколько глубоко каждая поддерживает именно сценарий класса, проверяйте на пилоте. Open-source BigBlueButton изначально спроектирован как виртуальный класс (малые группы, многопользовательская доска, опросы, интеграция с Moodle) и разворачивается на ваших серверах в России.

Оценим путь «строим учебный слой», который выбирает большинство продуктов, разрабатываемых на заказ. Видеооснова – решённая задача, её берут из WebRTC-инфраструктуры или open-source-медиасервера. Работа – в учебном слое сверху: система ролей и прав, состояние групп, синхронизация доски, мост посещаемости и xAPI, конвейер записи и интеграция с LMS. Разумная первая версия укладывается примерно в 20–35 инженеро-недель:

  • 28 инженеро-недель × 40 часов × 4 700 ₽/час средней ставки = 5 264 000 ₽ (≈ 5,3 млн ₽) за надёжную первую версию.

Затем сопровождение, без которого видео реального времени не живёт: закладывайте около 25–30% стоимости разработки в год на изменения браузеров, масштабирование и исправление ошибок. Для примера выше это ≈ 1,3–1,6 млн ₽ в год.

Теперь сторона покупки. Платформа ВКС или API с поминутной оплатой обычно стоит от десятков до нескольких сотен тысяч рублей в месяц – в зависимости от числа одновременных мест, объёма записей и варианта поставки (коробка или облако); точные цифры берите из прайса провайдера. Платформа за 170 000 ₽/мес за три года обойдётся в 36 × 170 000 = 6 120 000 ₽ (≈ 6,1 млн ₽) – немного больше разовой разработки учебного слоя. Но своему слою нужно сопровождение, и за те же три года он будет стоить 5,3 млн ₽ + 3 × (1,3–1,6) млн ₽ ≈ 9,2–10 млн ₽, примерно в полтора раза дороже подписки. При таком тарифе разработка не окупится и за семь лет, поэтому учебный слой строят не ради экономии, а ради контроля над тем, какие функции класса появятся дальше. По деньгам свой слой выигрывает за три года, только если подписка дороже ≈ 260–280 тыс. ₽ в месяц, а тарифы платформ с ростом числа одновременных мест доходят до этого уровня. Итог: не стройте медиадвижок WebRTC, если инфраструктура реального времени – не ваш продукт; стройте учебный слой, когда для бизнеса критичны роли, собственный учёт посещаемости, глубокая интеграция с LMS и экономика по числу мест; покупайте или разворачивайте готовое, когда быстро получить работающий класс важнее, чем владеть этим слоем.

Рис. 4. Решение «создать или купить». Сначала исключите разработку медиадвижка WebRTC, затем решите, критичен ли учебный слой: роли, учёт посещаемости, постоянные группы, интеграция с LMS. Большинство учебных продуктов, разрабатываемых на заказ, строят учебный слой на готовой медиаоснове – open-source-медиасервере или купленной инфраструктуре.

Если ваш заказчик – школа или колледж

Для школ и колледжей выбор ограничен законом. Организация, которая реализует общеобразовательные программы или программы СПО, при обработке персональных данных учеников обязана использовать государственные информационные системы и национальный мессенджер MAX (ч. 3.1 ст. 16 273-ФЗ; п. 4.1 и 9 ПП 1678 в ред. ПП 517 от 06.05.2026). Школьная платформа «Сферум» с октября 2025 года работает внутри MAX. Иностранные мессенджеры для передачи ПДн при выполнении государственного или муниципального задания запрещены (ч. 8 ст. 10 149-ФЗ). Поэтому для государственной школы ваш класс должен встраиваться в эту обязательную связку, а не подменять её. Свободнее рынок вузов и ДПО (ГИС «Современная цифровая образовательная среда» и MAX им разрешены, но не обязательны – п. 10 ПП 1678) и корпоративного обучения.

Частая ошибка: выпустить встречу с логотипом

Самая дорогая ошибка в живом обучении – считать, что вся задача сводится к «добавить видеозвонки», и встроить обычный инструмент встреч в оболочку курса. На демо всё выглядит прекрасно: появляются лица, работает звук. А потом пробелы всплывают один за другим. Нет асимметрии между преподавателем и учеником, и ученик может перехватить слово. Посещаемость – это CSV, который никто не может привязать к ведомости, и отдел обучения не может доказать, что обязательное занятие состоялось. Группы каждый раз перемешиваются, и поток не может работать на общий результат. Запись – неразмеченный файл, а не материал для каталога. А поскольку учебные данные никуда не передаются, в LMS живое занятие выглядит пустым: самое посещаемое событие недели не видно ни в одном отчёте.

Поэтому ещё до выбора инструмента решите, какие из пяти дополнений вашему продукту нужны глубоко встроенными, а какие можно сымитировать обычной встроенной встречей. Еженедельная сессия вопросов и ответов вполне может жить как встроенная встреча. Курс с оценками, обязательным обучением и потоком – это класс, и делать вид, что это не так, значит лишь отложить расходы до дня проверки. Задайте на планёрке вопрос: «мы строим класс или встраиваем встречу?» – и ответ на «создавать или покупать» обычно становится очевиден.

Где здесь Фора Софт

Мы разрабатываем продукты для живого обучения на заказ, и именно с виртуальным классом чаще всего помогаем клиентам провести границу «создавать или покупать». Схема, которую мы рекомендуем: не писать заново медиадвижок WebRTC, а брать его из проверенной инфраструктуры или open-source-медиасервера, развёрнутого в России, и вкладывать бюджет в учебный слой, который делает класс классом: модель ролей и прав, постоянные группы, передачу посещаемости в LMS и конвейер записи, который даёт полноценный материал для каталога. Живое интерактивное видео объединяет всё, чем мы занимаемся с 2005 года: видеоконференции, стриминг, e-learning и телемедицину. И вывод каждый раз один: медиапуть – в основном типовой компонент, а отличие продукта – в структуре класса вокруг него, поэтому тщательная инженерия окупается именно там.

Главное

  • Виртуальный класс – не встреча с логотипом: он поддерживает структуру занятия.
  • Пять дополнений: учебные роли, посещаемость как учебные данные, постоянные группы, сохраняемая доска, запись для каталога.
  • Встреча и класс работают на одном движке WebRTC; отличается учебный слой вокруг него.
  • Задержка вредит обучению сильнее, чем встречам, поэтому по умолчанию используют WebRTC с задержкой меньше секунды.
  • Посещаемость и записи, по которым можно опознать ученика, – персональные данные по 152-ФЗ: базы в РФ, отдельное согласие, ограниченный доступ; для школ и колледжей обязательны ГИС и MAX.
  • Не стройте медиадвижок; стройте учебный слой (≈ 5,3 млн ₽ за первую версию), когда роли, учёт посещаемости и связь с LMS критичны.

Что читать дальше

Строите такую систему?

Подберём параметры кодирования под ваш контент и посчитаем стоимость доставки до старта разработки.