LMS 同期上書き ― SIS連携で手修正が消える場面と運用設計

履修登録期の窓口で、教員から「昨日直したはずの履修者名簿が元に戻っている」と言われる。この LMS 同期上書き の現象は、学務システム（SIS）とLMSを自動連携している大学であれば、一度は経験があるのではないでしょうか。多くの場合、原因は不具合ではなく、連携が設計どおりに動いた結果です。SISを「正」とする仕組みでは、次回の同期でSIS側の値がLMS側へ反映されます。LMS上で手を入れた修正は、意図せず元の値に戻ることがあるわけです。

手で直した値が消える ― LMS 同期上書きが起きる場面

典型的なのは、履修変更期間の名簿です。履修確定前の学生を、授業開始に間に合わせるため教員や職員がLMS上で先に追加する。ところが夜間の同期でSIS側の名簿が再び反映され、追加した学生が外れてしまう。翌朝、授業初回の教室で学生が「科目が見えない」と訴える、という流れです。

Instructure の開発者向け文書によれば、Canvas LMS の SIS インポートには「diffing（差分）」と呼ばれる仕組みがあり、同じ識別子をもつ前回のデータセットと比較して、差分だけを適用できます（SIS Imports）。毎回すべてを流し込むより負荷は小さく、変化のない行には触れません。ただし、差分連携であっても「SIS側の値が変われば、LMS側に反映される」という大原則は変わりません。問題は仕組みの良し悪しではなく、手修正をどこまで許し、どう扱うかという運用の取り決めにあるように思います。

日本の大学で「手修正」が避けにくい事情

手修正をなくせばよい、と単純には言えないのが現場です。日本の大学は年度制のもとで、開講直前まで担当教員が確定しない科目や、非常勤講師の急な変更、科目の統合・分割といった調整が、学期の直前にまで及ぶことがあります。SIS側の修正には教務課の手続きや承認の締切が伴うため、授業に間に合わせるには、LMS側で先に直すほうが現実的な場面も少なくありません。

こうした例外対応は、授業を止めまいとする教職員の誠実さの表れでもあります。情報センターの側から見れば、「手修正を禁じる」か「上書きを黙認する」かの二択に追い込まれると、どちらを選んでも運用負荷が残ります。教務は例外を受けたい、情報センターは連携を安定させたい。その両方を成り立たせる余地を、仕組みの側に用意できないでしょうか。なお、年度替わりの名簿更新の難しさについては過去の記事でも触れています。

標準規格と運用設計で考える、上書きとの付き合い方

データの受け渡しには標準規格があります。1EdTech の OneRoster は、ユーザ、コース、履修登録などを教育機関のシステム間でやり取りするための標準で、CSV と REST の2方式に対応しています（1EdTech: OneRoster）。ただし規格が定めるのはデータの形であり、「どちらの値を優先するか」は各大学が決める運用の領分です。

考え方の選択肢は、おおむね三つに整理できます。ひとつは、修正はすべてSIS側で行うと割り切ること。ふたつめは、履修変更期間だけ例外の窓口を設け、期間後に必ずSISへ反映する手順を定めること。三つめは、一定期間だけLMS側の修正が上書きされないよう、同期を部分的に止められる仕組みを持つことです。ヨウムの youmu perch. の perchadmin. には、SIS のデータを差分で連携する Sync Service に加え、更新を一時的に遮断する更新ロック（Emergency Override）があります。指定した期間だけ上書きを止めるという使い方で、前述の三つめの考え方に近いものです。もちろん、どれが適しているかは、大学の体制と学務の慣習によって異なります。

まとめ

LMS 同期上書きは、連携が正しく動いているからこそ起こる現象です。手修正を禁じるのでも黙認するのでもなく、例外をどの期間・どの範囲で認め、いつSISへ戻すのかを、教務と情報センターで先に決めておく。そのうえで、必要な場面で上書きを止められる道具を選べるようにしておく。そうした設計が、履修登録期の窓口の負担を静かに減らしていくのではないでしょうか。

※ Canvas および Canvas LMS は Instructure, Inc. の商標です。youmu perch. はヨウム株式会社の製品であり、Instructure, Inc. が提供・保証するものではありません。