Canvas LMS と学務システムの連携 ― 差分同期という選択

Canvas LMS と学務システムの連携は、なぜ年度替わりに山を作るのか

Canvas LMS と学務システムの連携は、多くの大学で「年に一度の大仕事」として扱われています。履修登録の確定を待って名簿を書き出し、科目とコースを突き合わせ、初回授業までに全学分を整える。作業そのものは単純でも、締切が一点に集中するため、情報センターの3月は毎年ほぼ同じかたちで膨らみます。

そしてこの山は、4月に入っても終わりません。履修の追加・取消、クラス分けの確定、非常勤講師の着任、留学生の登録。名簿は動き続け、そのたびに連携をもう一度回すことになります。夜間バッチが全件を読み直す設計であれば、変更が1件でも所要時間は同じです。翌朝までに終わらなければ、初回授業に間に合わない科目が出る。

大学ICT推進協議会（AXIES）の調査でも、高等教育機関のICT活用を妨げる要因として、システムを開発・維持する人員の不足や予算・時間の不足が繰り返し挙がっています。連携の作業量そのものより、それを引き受ける人が限られていることのほうが、実際には効いているのではないでしょうか。

日本の大学に固有の事情 ― 学務データの「かたち」は大学ごとに違う

海外では、名簿連携の標準として 1EdTech の OneRoster が広く使われています。ユーザ・科目・履修・成績のやり取りを共通の形式で定義したもので、SIS と LMS の組み合わせを問わず流通させることを狙った規格です。

ところが日本の大学の学務システムは、長く個別に育ってきました。科目コードの体系、学期の切り方、クラス・組・コースの入れ子、教員の兼担や共同担当の表現。これらは学則と運用の歴史そのものなので、標準形に寄せること自体が制度の議論になります。実際、大学が公開している調達仕様書を見ると、学務システムとLMSの連携データ仕様が大学独自に定義され、日次処理で展開される形が珍しくありません。

つまり、「標準に合わせれば解決する」とは言い切れない。標準規格の価値は疑いようがないとして、それを採るまでのあいだ、手元のCSVをどう扱うかという問題は残り続けます。ここを飛ばして議論すると、調達の要件定義が現場の3月と噛み合わなくなります。

全件洗い替えではなく、差分で流すという考え方

ここで効いてくるのが、連携を「差分」で組み立てられるかという点です。前回と同じ行は送らず、増えた・減った・変わった分だけを渡す。処理時間が短くなるだけでなく、失敗したときに見るべき範囲が狭くなる、という副次的な効き目があります。履修登録期の窓口で「反映されていない」と言われたとき、確認先が数十行で済むかどうかは、対応の速さをそのまま変えます。

ヨウムが提供する youmu perch. の perchadmin. は、この発想で作られています。SIS のユーザ・科目・履修データを大学独自の形式のまま受け取り、変更分だけを Canvas LMS へ流す。あわせて、ブループリントの自動紐付け、学内IDが変わった復帰教員の名寄せ、指定期間だけ自動更新を止める仕組みといった、日本の大学の運用で必要になる補いを担います。Canvas および Canvas LMS は Instructure, Inc. の商標であり、perchadmin. はヨウム株式会社の製品として、その外側から LTI 1.3 と API で寄り添う立ち位置です。

どの製品を選ぶかは別として、調達の段階で「全件か差分か」「独自フォーマットをそのまま受けられるか」を一行入れておくだけでも、あとの運用は違ってきます。Canvas LMS JP のような国内窓口の有無も、同じ観点で見ておきたいところです。

まとめ ― 学務システム連携の設計は、年度末の人員計画そのもの

Canvas LMS と学務システムの連携は、技術の話であると同時に、3月から4月にかけて誰が何時間を使うかという人員の話でもあります。標準規格への歩み寄りは中期の課題として進めつつ、いま手元にある独自フォーマットを差分で流せる設計にしておく。この二段構えが、当面もっとも現実的な落としどころではないでしょうか。