学校グループのための Moodle 代替候補：ライセンスではなく運用を見積もる
Moodle はライセンスが無料で、運用は無料ではありません。ホスティング、アップグレード、プラグインの互換性、マルチテナンシーが学校グループに実際にかける費用。
Moodle はライセンスが無料で、運用は無料ではありません。Moodle をよく知るシステム管理者がいる1校なら、たいていは良い取引です。グループ — 学校法人、教育区、出版社、省庁のプログラム — になると計算が変わります。判断を左右するコストがホスティング、バージョンのアップグレード、そのアップグレードをまたいだプラグインの互換性、セキュリティパッチ、バックアップだからであり、そしてマルチテナンシーがコア製品に含まれていないからです。どの代替と比べるにせよ、誠実な比較の単位はライセンス費用ではなく総運用コストです。
これは批判ではありません。Moodle は教育分野で最も広く導入されているオープンソース LMS であり、その地位を実力で得ています。本当に無料で、本当に自社ホスティングでき、商用製品なら作らないであろうものに満ちています。ここでやっているのは算数であって、旗色を決めることではありません。
Moodle の運用に実際にかかる費用
ホスティング
PHP のアプリケーション、データベース、ファイルストア、そして実際に動いていなければならない cron ジョブ。サイジングは平均的な火曜日ではなく、試験週間と成績発表日に合わせます。さらに、リハーサルが意味を持つ程度に本番へ近いステージング環境。ずれてしまったステージングは、別の芝居のリハーサルです。
バージョンのアップグレード
Moodle はすべてのリリースについてサポート終了日を公表しています。その日を過ぎたバージョンにはセキュリティ修正が届かなくなるため、最新に保つことは事務作業ではなく、セキュリティ体制そのものです。メジャーアップグレードはそれぞれ、コードの更新、スキーマの更新、停止時間の確保、そして事前のリハーサルを伴います。バージョンを飛ばしても作業は減らず、積み上がります。
プラグインの互換性
多くの機関が Moodle を選んだ理由はプラグインディレクトリにあり、インストールしたプラグインは1つひとつが他人のリリース計画への依存です。だからアップグレードは表になります。プラグインごとに、対象リリース向けのビルドはあるか、保守は続いているか、教師が1学期を組み立てる土台にしていた機能は今も動くか。保守が止まったプラグインが1つあるだけで、サイト全体が古いバージョンに留め置かれることがあります。サポートの切れたリリースを動かし続ける、最もよくある経路です。
セキュリティパッチ
Moodle はセキュリティ勧告を定期的に公開しています。自社ホスティングであれば、それに対応するのは自分たちの仕事です。告知を追い、緊急度を判断し、適用し、検証する。ときには通常のサイクル外で、ときにはやり方を知っている人が不在の休暇中に。その下には PHP、データベース、オペレーティングシステムがあり、それぞれに独自のパッチの流れがあります。
バックアップ
バックアップと呼ばれるものは2種類あります。コースのエクスポートと、データベースおよびファイルストアのインフラバックアップです。両方が必要で、一度も復元したことのないバックアップは仮説にすぎません。そしてグループを苦しめる質問。1つの学校を、他のすべての学校にメンテナンス時間を強いることなく復元できますか。
総運用コスト
プラットフォームを1年間動かし続けるために必要なすべて。ホスティングとストレージ、アップグレードとリハーサルに費やす時間、プラグインの再テスト、セキュリティパッチ、バックアップの検証、インシデント対応、そしてサポート契約 — それらに、運用している個別インストールの数を掛けたもの。オープンソースソフトウェアでは、そのなかでゼロなのはライセンスの行だけです。
Moodle は本当に無料ですか
ソフトウェアのライセンスは無料で、自社ホスティングも無料です。ユーザーあたりの費用も更新料もありません。支払うのはインフラと人の時間です。ピーク週に合わせたホスティング、アップグレードごとのリハーサルと停止時間、メジャーバージョンごとのプラグインの再テスト、公開されるたびに対応するセキュリティ勧告、そして復元をテスト済みのバックアップ。システム部門が他のシステムのためにすでにこれらのコストを負っている機関なら、たいていは最も安い選択肢を運用していることになります。その部門を持たないグループは、採用かパートナー契約を検討することになり、それが商用ライセンスと比べるべき数字です。
グループ規模で壊れるのがマルチテナンシーである理由
1校だけならこれにぶつかることはめったにありません。グループがぶつかるのは、2つの学校が同じ日に別々のものを求めた時点です。別のロゴ、別の学期構成、誰が誰のデータを見てよいかについての別の答え。
マルチテナンシー
1つのプラットフォームが、それぞれ独自のメンバー・ブランディング・ドメイン・管理者を持つ複数の組織を保持し、そのデータのあいだに強固な境界を置く仕組み。学校グループはその典型です。各校の職員は自校の学習者しか見えない一方で、グループは全校にまたがる1つの問いを投げ、1つの答えを得られます。
Moodle のサイトは、1つの組織の内側に構造を与えます。入れ子にできるカテゴリー、コホート、カテゴリー単位で割り当てられる役割。これは本物の階層です。しかし設計の中心にあるのは、1つの機関のための1つのサイトです。アカウントはサイトに属し、管理はサイト全体に及び、バージョン・プラグイン構成・メンテナンス時間はそのサイトの全員で共有されます。そのため「各校が自校の管理者を持つ」は、実際には「各校に、間違ったものをクリックしないと信頼できる人がいる」に落ち着きがちです。
その差を露わにする質問は、退屈で具体的です。
- B校は、A校のものに触れずに自校のロゴ・配色・ログインページを変更できますか。
- B校の管理者は、B校にのみ存在するユーザーを作成し、削除できますか。
- 各校で週2日ずつ働く教師は、1つのアカウントで済みますか。
- グループは、エクスポートなしで全校にまたがる1つの問いを投げ、1つの答えを得られますか。
- C校がグループを離れるとき、そのデータ・ユーザー・コンテンツを引き渡し、その後削除できますか。
- 1つの学校を、他校にメンテナンス時間を強いることなくバックアップから復元できますか。
どれも Moodle で答えられます。十分な設定作業を行うか、十分な数の個別インストールを立てれば。コストになるのは、その設定作業か、そのインストールです。
1つの Moodle サイトで複数の学校を分離して運用できますか
コア製品ではできません。Moodle のコアは1つの組織のための1つのサイトとして作られており、その内側にカテゴリー、コホート、カテゴリー単位の役割が構造を与えます。より完全な意味での分離 — 独自のブランディング、独自のドメイン、独自の管理者、独自のデータ境界 — は、商用の Moodle Workplace 階層、パートナーが構築する設定、あるいは並列インストールが担う領域です。3つのうちどれかを意識して選んでください。1校ずつ並列インストールへ流れていくのは、高くつく道です。
よくある3つの答えと、それぞれの引き換え
Moodle Workplace
認定 Moodle パートナー経由で販売される商用階層で、マルチテナンシーが加わります。引き換えは、あいだにパートナーを挟んで商用製品を買うことになる点です。無料のライセンスはもはやそこにいる理由ではありません。現行製品としてではなく、他の商用プラットフォームと対等な条件で比較してください。そして、学校グループの形（学年、保護者、学期）が、職場研修を設計の中心に置く製品にどう対応するのかを確認してください。
パートナー契約
認定パートナーがホスティング、アップグレード、パッチ適用を行い、電話にも出ます。作業がなくなるわけではなく、SLA 付きの費用項目になります。採用より良い取引であることも多いでしょう。限界は2つ。それ自体はマルチテナンシーを足しません — そこは依然として Workplace か複数サイトです。そして費用はサイト数とユーザー数に比例しがちなので、グループはおおむね学校ごとに支払うことになります。署名する前に、離れるときにどうなるのかを尋ねてください。
並列インストール
学校ごとに Moodle を1つ。データ、ブランディング、停止時間まで正直に分かれており、学校を引き渡すときはそのサイトを引き渡せば済みます。引き換えは、すべてが掛け算になることです。10校なら、10回のアップグレードの停止時間、10通りのプラグイン対応表、10組のセキュリティ勧告、10系統のバックアップ運用。学校をまたぐレポートはエクスポートして結合する作業になり、たいていは表計算ファイルで、たいてい仕組みを知っているのは1人だけです。グループ全体の変更は10回適用され、11か月目にはずれ始めます。
グループが並列インストールを選び取ることはめったにありません。たどり着いてしまうのです。4校目を受け入れるのに、新しいサイトを立てるのが最も早かったから。
プラグイン経由の AI は、製品の中の AI とは違う
Moodle 環境における AI 機能の多くは、プラグインとして届きます。プロバイダーへのコネクタ、問題の生成、要約。プラグインは Moodle がずっと成長してきた方法です。ただし、機能がプラットフォームに組み込まれるのではなく横に付けられるとき、3つの性質が違う振る舞いをします。
グラウンディング
答えはどこから来るのか。汎用のコネクタはプロンプトをモデルに渡してテキストを返すだけなので、反映されるのは自校のシラバスや採点方針ではなく、モデルの一般的な知識です。グラウンディングとは、自分たちの資料を検索し、ある一文がどの文書から来たのかを引用として示すことです。グループにおいては、これはまずデータ境界の問題です。A校の文書が B校に返す答えの根拠になってはならず、単一サイトのデータモデルの上に載るプラグインには、尊重すべきテナント境界がそもそもありません。
安全性の審査
モデルを選んだのは誰か、プロンプトを書いたのは誰か、何が自組織のインフラの外へ出るのか、提供者はそれをどれだけの期間保持するのか、そして子どもの記述物がその中に含まれるのか。プラグインの場合、答えは「それを書いた人」と「自分が設定した内容」です。オープンなコードなので確認はできますが、確認する人は自分であり、プラグインごとに、アップグレードのたびに行うことになります。
監査
1学期後、保護者や視学官が AI は何をしたのかと尋ねます。何が生成され、誰によって、どの資料から生成され、学習者に届く前に人がどこを変えたのかを示せますか。プラグインは、記録を残すとしても、自前の形式で自前のテーブルに書き込みます。
プラットフォームの権限モデル、テナント境界、監査ログを共有する AI。だから、誰が成績を変更したかを示す記録が、モデルが何を下書きし、その根拠が何で、誰が承認したのかも示します。
サイトの横にボルト留めされたモデルのコネクタ。独自の設定画面、独自のログ形式、独自のデータ経路、独自のアップグレード計画を持つもの。
プラグインが問題なのではありません。AI とデータのあいだの境界は、他のすべての境界を引いているものが引かなければなりません。そしてプラグインは、プラットフォームが持っていない境界を引くことはできません。
誠実に費用を出す
見積もらないでください。過去12か月分のチケットシステムと変更履歴を開いて、数えてください。
annual operating hours, per Moodle site
major upgrades (windows per year) x (hours per window)
+ point releases (releases applied) x (hours each)
+ plugin re-testing (plugins relied on) x (hours per upgrade)
+ security advisories (acted on per year) x (hours each)
+ backup restore tests (tests per year) x (hours each)
+ unplanned incidents (last 12 months, from the ticket system)
= hours per site per year
x number of sites you run
x loaded hourly cost of the people who do it
+ hosting, storage and bandwidth
+ partner or support contract
= the number to compare against a licence移行によって本当になくなる時間だけを数えてください。そのうえで、今日答えられないグループ全体の問いを別に列挙します。今学期、全校で何人の学習者が児童保護の研修を修了したのか、そしてどの学校が遅れているのか。
それでも Moodle が正しい答えである場合
よくあります。Moodle を知っている社内のシステム部門があるなら、留まることが最も安く、最も説明のつく選択であることが少なくありません。スタックの完全な統制、ベンダー依存のなさ、そして商用のロードマップが優先しない教育手法を覆うプラグインのエコシステム。調達規則がオープンソースを明確に求めている場合もあります。そして移行コストは実在します。コンテンツ、問題バンク、成績簿の履歴、アカウント、そして百冊の手引きに印刷された古いリンク。
離れる理由として間違っているのは、アップグレードが1回うまくいかなかったことです。正しい理由は構造的なものです。グループが大きくなり、いま問題なのはソフトウェアではなくその形であり、運用コストを払っているのは別の仕事のために雇われた人たちである、という状態です。
他を検討するなら、何を確認するか
ここから先、私たちはベンダーです。そのつもりで読んでください。Lurno は上で述べた形のために作られたマルチテナントのプラットフォームで、学校グループは設計の中心にあるケースです。以下は、当社にも、候補リストの他社にも同じように当ててほしいチェックリストです。
- テナントの構造。入れ子の組織を、スライドに描かれた図ではなくその場で作成して見せてもらってください。Lurno では組織がさらに組織を含むことができ、そのツリーのある枝で付与した役割はその下へ継承されます — グループ全体の児童保護責任者は、一度付与すれば済みます。
- 分離がどこで強制されているか。アプリケーション層のフィルタリングは、バグ1つで漏洩に変わります。境界がデータベースにあるかを尋ねてください。Lurno はデータベースにあります。676 のマイグレーションにわたる 868 の行レベルセキュリティポリシーで、セキュリティページに記載しています。
- ブランディングとドメイン。組織ごとのホワイトラベルのブランディングと、自動 TLS 付きのカスタムドメイン。各校のログインページは各校のものになり、サブ組織は上書きするまで親組織のブランディングを引き継ぎます。
- サインオン。正確に、そして当社にも同じ基準を課してください。Lurno には現時点でパートナーサインオン（サイレント SSO）があります。SAML/OIDC の SSO、MFA、パスキーはロードマップ上にあり、利用できません。各校が Entra や Google Workspace 経由で SAML でサインインしているなら、当社を含むすべてのベンダーに、時期を書面で尋ねてください。
- 規格。Lurno では SCORM 1.2、SCORM 2004、xAPI、LTI 1.3 は開発中です — 製品内にモデル化され、ランタイムを構築中です。10年分の SCORM パッケージを抱えているなら、それは最後ではなく最初に尋ねてください。
- 商取引まわり。現時点でアカウントは招待によって作成されます。セルフサービスのサインアップ、決済、チェックアウトは設計済みで、未実装です。
- 企業向け LMS が作る理由のないもの。データ区分ごとに範囲を絞った保護者ポータル、公開の検証ページを備えた修了証、エビデンス付きのコンピテンシーフレームワーク、そして完全な RTL のアラビア語を含む4つの製品言語。
- 解約。すべてをどうやって、どの形式で持ち出せて、どれくらいの時間がかかりますか。これに素早く答えるベンダーは、何かを伝えてくれています。
学校グループが Moodle を置き換える前に尋ねるべきことは何ですか
順番に5つ。自分たちのサイトを1年運用するのにいくらかかるのか、見積もりではなくチケットシステムから時間を数えるとどうか。個別インストールをいくつ運用していて、それはなぜか。エクスポートなしでは答えられないグループ全体の問いはどれか。個別インストールを立てずに、各校が独自のブランディング・ドメイン・管理者を持てるか。そして、どの規格 — SCORM、xAPI、LTI、SAML SSO — を各ベンダーが今日提供しているのか、開発中のものとロードマップ上のものをそれぞれそう明示したうえで。
Lurno と Moodle のより詳しい並列比較を用意しています。Moodle のほうが本当に適しているのは誰かについても、率直に書いています。計算の結果が Moodle のままなら、それは良い結末です。しかも次の予算会議でそれを説明するための数字が手元にあります。