新型コロナ騒動前後に実施した⾼知⼤学 moodle の運⽤⽅針の⾒直し三好 康夫 1),2),3),4), 髙畑 貴志 4)1) 高知大学 理工学部情報科学科
2) 高知大学 学術情報基盤図書館
3) 高知大学 データサイエンスセンター
4) 高知大学 学び創造センター
miyoshi@is.kochi-u.ac.jp

Alterations of LMS Operation Policy
Before and After the COVID-19 Outbreak at Kochi University
Yasuo Miyoshi 1),2),3),4), Takashi Takabatake 4)1) Dept. of Information Science, Fac. of Science and Technology, Kochi Univ
2) Library and Information Technology, Kochi Univ.
3) Center for Data Science, Kochi Univ.
3) Center for Creative Learning Development, Kochi Univ.
概要

高知大学では Moodle を 2010 年度より本格運用している。当初は四国 8 大学間の eLearning による単位互換の教育連携を実施するためのシステムとして導入されたこともあり，ユーザの認証には Shibboleth を用いてきた。一方で，IMAP 認証と併用することにより，同じアカウント名とパスワードを用いてテストアカウントとしてもログインできる仕組みを提供してきた。コロナ禍がきっかけとなり学内の通常授業での利用率が大幅に増えたことと IMAP 認証の利用継続が困難になったことを受け，2022 年度より OAuth2 と Shibbolethを併用する認証方法に変更した。本稿では，認証方法の変更を実施することで得られた知見と事例として紹介する。また，本学で課題となっている教務システムとのデータの自動連携についても現状について簡単に報告する。

1

きっかけである。そして現在も，大学連携 e-はじめにLearning 教育支援センター四国 (知プラ e)[3]の取高知大学では，開講している全ての授業で利用り組みである「四国国立 5 大学連携による e-可能な LMS (Learning Management System) の運用

Learning 科目の共同実施」を行うために利用されを 2010 年度より実施してきた。本学の LMS は，オープンソースの Moodle を採用しており，2018ている。とはいえ，導入当初より，高知大学 moodle
は，連携大学への科目提供のためだけでなく，本年度までは学内のオンプレミスサーバ上で，2019学内向けに開講している通常の授業でも活用して年度からは Azure のクラウドサーバ上で稼働してもらいたいという方針で準備と運用を続けてきた。

いる。クラウドへの移行の際には動画のストリー今や，学内の通常授業での利用の方がメインとなミング配信プラグインの導入も行っており，2020っており，コロナを境にそれが顕著になった。そ年度のコロナ禍による急激な利用増加（例: 延べのような状況を踏まえて見直した高知大学 moodle

アクセス数は前年度の約 11 倍に増加[1]）に大きなの運用方針について，教務システムとの連携方法トラブルなく対応することができた。
この高知大学 moodle (https://moodle.kochi-u.ac.
jp) が導入されることになったのは，e-Knowledgeや認証方法を変更した点を中心に本稿で報告する。

2

単年度版と連年度版

コンソーシアム四国 (eK4)[2]の取り組みである「四高知大学 moodle は，単年度版（授業用）と連年

国 8 大学間の e-Learning による単位互換の教育連度版（共有用）の 2 つの Moodle サイトを構築して携」を実施するために LMS が必要になったことが提供している（図 1）。単年度版は，主に授業等で409

の利用を想定しており，年度ごとに新たに Moodleを行う期間を確保するため，新年度版の Moodle のを構築して追加している。連年度版は，主に学内構築とこれらの準備は，2 月中旬には完了させなの情報共有のための利用を想定しており，複数年ければならない。

にわたり継続して運用しているが，年度が変わる

現在，本学では Moodle と教務システムとの連際には単年度版と同じバージョンの Moodle にア

携は自動化できていないところが多い。特に履修ップデートするようにしている。

登録期間中の履修学生ユーザの一括コース登録

オンプレミスサーバ上で運用していた 2018 年(enrollment) は，教務担当の事務職員による手作業

度までは教職員のみが利用できる練習用のの負担が大きい点と，履修取消情報を反映できて[4]Moodle を提供していた が，クラウド移行と同時いない点が課題となっていた。そこで，データ連に練習用 Moodle を廃止し，連年度版を提供するこ携方法を見直し，Moodle のフラットファイル機能とに方針を切り替えた。本稿執筆時点で連年度版を 2020 年度後期から採用することにした。には 60 のコースが作成・利用されている（図 2）。

3.1 フラットファイルによる履修情報の一括登録
これまでは，①教務システムから履修情報をXLSX 形式で書き出し，②Excel を用いて Moodle用の CSV 形式に変換し，③Moodle 管理画面にてアップロードする，という作業を事務職員が履修登録期間中は毎朝手動で実施していた。③はMoodle の「サイト管理／ユーザ／ユーザをアップロードする」から行っていたが，これで一括登録されたものは「手動登録」として扱われる。そのため，履修者以外のユーザがコースに登録されていた際に，削除すべき履修取消学生ユーザなのか，担当教員が手動で追加した（勝手に削除してはならない）ユーザなのか見分けがつかないことから，一括登録の際に履修取消学生ユーザをコースから削除することが行えていなかった。③を Moodle の

図 1 高知大学 moodle トップページ

フラットファイル (flatfile) 機能で行うようにしたところ，次のような利点があった。
• 担当教員が手動登録したユーザは，フラットファイルで削除（一時停止）されない

手動登録したものはフラットファイルによる一括登録の影響を受けない。そのため，履修取消情報を一括登録で反映させることができるようになった。
• フラットファイルで追加されたユーザは，担当教員が手動で削除することができない

教員が誤って学生をコースから削除してしまうと，それまで学生がコース内で行った活動
図 2 連年度版 Moodle（高知大学 moodle share）（課題提出や小テスト受験等）の履歴が失われてしまう。そのような事故が起こる前にフラッ教務システムとの連携方法の見直し

トファイルでの一括登録に切り替えることがで単年度版 Moodle は，教務システムに登録され• フラットファイルで履修取消学生を削除するている全ての科目のコースを用意し，担当教員が際，完全にコースから削除するのではなく「一コースを非公開から公開に切り替えればすぐに使時停止」とすることができる

3

きたことは非常に満足している。

えるようになっている。担当教員が新年度の準備410

一時停止であれば，学生の活動履歴は削除されないため，いつでも復活することができて安用できている。
（発生した事故は，正しく書き出し心である。フラットファイルで一時停止とした

た履修情報ファイルを用いて再度一括登録を行う

ユーザを担当教員が手動で「アクティブ」に戻ことで復旧できた。
）このようなヒューマンエラーすこともできるため，履修登録上は取り消されを起こさないためにも早急な自動化が望まれる。ていても，教員の判断でコースの利用を認めることは可能である。
3.2 フラットファイル管理アプリの開発
フラットファイル機能を採用することにした2020 年度後期の時点で，1 年以内に本学の教務システムの更新が予定されていたため，前節の①〜③の自動化は新しい教務システムの導入時に行うことにした。それまでの間，一時的に Moodle と教務システムとの連携を補助する「フラットファイル管理アプリ」を開発し，運用することにした。
（なお，教務システム側の更新が遅れてしまっており，本稿執筆時点でも本アプリを使用している。
）
本アプリは，Python 3 と PySide2 ライブラリを図 4 フラットファイルへの自動変換用いて本稿の著者が開発したもので，Qt 5 フレー
ムワークにより Windows と macOS の両方に対応した GUI アプリとなっている（図 3〜5）
。主な機能としては，教務システムで書き出した履修情報ファイルを CSV 形式のフラットファイルに自動変換する機能（②の代わり，図 4）と，Azure 上のMoodle サーバへアップロードする機能（③の代わり，図 5）を備えている。

図 5 フラットファイルのアップロード

4

認証方法の見直し

4.1 テストアカウント提供のための複数の認証方式の併用

高知大学 moodle（単年度版）は，高知大学の学生・教職員だけでなく，本学開講の知プラ e 科目
図 3 フラットファイル管理アプリ・データ入力[3]を履修する連携大学の学生も利用することになるため，ユーザ認証には Shibboleth を用いてきた。

本アプリを用いてフラットファイルによる履

eK4 や知プラ e で独自に Shibboleth 認証連携のフ修情報の一括登録を行うようになり 2 年が経過しェデレーションを構築していた時期もあったが，たが，①で書き出した履修情報ファイルが空にな

現在は NII が提供している学術認証フェデレーシっていることに気付かずに本アプリでフラットフ

ョン（学認 GakuNin）を利用している[5]。

ァイルをアップロードしてしまい，全てのコース

LMS のコース上に教材コンテンツを用意したの履修学生ユーザが「一時停止」になってしまう

教職員は，学生ユーザからどのように見えている事故が一度発生してしまった以外は，安定して運のかを確認したい。Moodle にはそのような要求に411対応した「ロール切替」機能を有しているが，簡易トは，Moodle の「サイト管理／サーバ／OAuth2 サ的な確認にしか使えない。そこで，以前提供してービス／Microsoft サービス」画面にて，クライアいた練習用の Moodle では，教職員全員が教員としント ID 欄とクライアント秘密鍵欄に入力する。て利用するためのメインアカウントと学生として

Moodle の認証設定に関する項目のほとんどは「サ利用するためのテストアカウントの 2 つを使用でイト管理／プラグイン／認証」メニューから辿れきる仕組み（Shibboleth 認証と他の認証方式との併るよう集約されているが，この設定を行う場合は[4]用）を導入した 。

メニュー階層が異なるので注意したい。

認証方式を併用するには，Shibboleth 認証の SP

また Azure Portal にて OAuth2 認証用アプリを(Service Provider) となる Moodle に渡されるユーザ登録する際，「サポートされているアカウントの種ID 名 (eduPersonPrincipalName 等) が他の認証方式類」を「任意の組織ディレクトリ内のアカウントでログインした時と異なるものを返すよう IdP(マルチテナント)」にする必要がある。Moodle 3.9(Identity Provider) を設定しておく必要がある。そではシングルテナントに対応していないためであれを満たせば，Moodle の Shibboleth 認証機能は他る。自大学のユーザのみに利用を制限する場合は，の認証方式とは別の専用のログインフォームを持

Moodle の「サイト管理／サーバ／OAuth2 サービっているため，1 組の ID とパスワードで 2 つのアス／Microsoft サービス」画面にて，ログインドメカウントを切り替えることができる。

イン欄に自大学のドメイン名を指定すればよい。

本学では現在，この仕組みを単年度版と連年度版の Moodle の両方に導入しており，1 つの ID（全学認証 ID）とパスワードしか持っていない教職員が自分用のテストアカウントとしてもログインすることが可能となっている。
（テストアカウントの提供は本学の教職員に対してのみとしており，学生がテストアカウントとしてログインすることはできない。
）これにより，管理者・サポート担当者がテストアカウントの発行希望に個別対応しなければならない状況や，Moodle 内でテスト用のローカルアカウントがむやみに増えてしまうことについては，かなり軽減できている。
4.2 認証方法の変更 (IMAP 認証→OAuth2 認証)
高知大学 moodle では 2021 年度まで，Shibboleth認証と IMAP 認証を併用していた。本学教職員が図 6 高知大学 moodle 2021 年度版ログイン画面

Shibboleth 認証でログインすると教職員としての（メインアカウントでの）ログインとなり（図 6），IMAP 認証でログインすると学生としての（テストアカウントでの）ログインとなるようになっていた（図 7）。しかし，本学で使用しているメールサーバが IMAP 認証に対応できなくなることになり，2022 年度からは IMAP 認証の代わりに OAuth2認証を用いることにした。
Moodle の IMAP 認証設定は，メールソフトでメール受信するために必要な設定とほぼ同じで非常にシンプルであったが，OAuth2 認証は少し複雑である。まず，Azure Portal サイトから「App Service

図 7 高知大学 moodle 2021 年度版ログイン画面／Azure Active Directory の管理／アプリの登録」に（IMAP 認証ログインフォーム）て，アプリケーション ID とクライアントシークレットを作成する必要がある。この ID とシークレッ

412

4.3 メイン認証方式の変更

メイン認証方式を OAuth2 認証へ切り替えた後2021 年度までの高知大学 moodle のログイン画にログイン画面の作成したが，その際に Shibboleth

面では，
図 6 のように学認の DS (Discovery Service)

認証で学認の所属機関選択リストのメニューを必で提供される所属機関選択インタフェースを採用ずしも使用する必要がないことに気が付いた。図していたため，Shibboleth 認証でログインするたび

8, 9 に示すように，Shibboleth 認証であっても，ボにリストから所属大学を選択する手間がかかってタンを押すだけで所属機関の認証画面へ誘導するいた。
（学認が提供する所属機関デフォルト選択機ことができるため，メイン認証方式は Shibboleth 認

能を使えば半年間は所属機関選択の手間をスキッ証のままでも良かったということになる。

プすることができるが，2021 年度の時点ではこの

OAuth2 認証（Microsoft サービス利用の場合）機能を提供するページに記述された JavaScript コの利点は，パスワード入力の回数を減らせることードが古くなっており，ほとんどのブラウザで有である。Web ブラウザが Office365 サイトにログイ効に機能しなくなっていた。
）コロナ禍をきっかけ

ン中であれば，ID とパスワードを入力することなに学内の通常授業での利用が増えたことから，主く Moodle にログイン可能である。一方で，本学のたる利用者である本学ユーザのログイン操作を簡アカウントとは別のアカウントで Office365 にロ略化すべきと考え，これを機に Shibboleth 認証メグインした状態では，高知大学 moodle に OAuth2インから OAuth2 認証メインへ切り替えることに認証でログインすることができない。Office365 のした。これにより，本学の学生ユーザと教職員ユサイトでログアウトするか，Web ブラウザのプラーザは所属機関選択が不要な OAuth2 認証でログイベートブラウズモードあるいは別の Web ブラウインし，本学教職員がテストアカウントでログイザを利用する必要がある。そのため，本学のアカンする場合や連携大学ユーザがログインする時はウント以外で Office365 を利用することの多いユShibboleth 認証を使用することになる。

ーザ（非常勤講師等）には，プライベートブラウズモードの利用推奨等の注意喚起が必要となる。
4.4 OAuth2 と Shibboleth の併用で起こる問題
Moodle で IMAP, OAuth2, Shibboleth 等の外部認証方式を採用した場合，Moodle 上に登録されていないユーザがログイン認証を通過することがある。
この時，Moodle 上にユーザアカウントを自動で生成するか，生成せずにログインできないようにするかは設定で決めることができる。高知大学
moodle では，知プラ e 連携大学から Shibboleth 認
証でログインしたユーザのアカウントは自動生成

図 8 高知大学 moodle 2022 年度版ログイン画面（本学ユーザ用）

される必要があるため，アカウント自動生成を止める設定にすることができない。
IMAP 認証をテストアカウント提供用に採用していた際には，図 10 のように教職員ユーザのみを事前登録しておくだけで運用上問題はなかった。
しかし，OAuth2 認証アカウントと同じメールアドレスをもつ Shibboleth 認証アカウントが自動生成されてしまうと，OAuth2 認証でログインしてもメールアドレスが同じ Shibboleth 認証アカウントの方でログインされてしまうことがわかった。そのため 2022 年度は，図 11 のように，メールアドレスを onmicrosoft.com のサブドメインのものに変

図 9 高知大学 moodle 2022 年度版ログイン画面（知プラ e 連携大学ユーザ用）

えたテストアカウントを事前登録しておくことにした。この時，学生のテストアカウントも「利用停止アカウント」にして事前登録した。利用停止ア413

図 10 2021 年度のユーザ登録用 CSV ファイルの形式

図 11 2022 年度のユーザ登録用 CSV ファイルの形式
カウントは表示されるユーザの名に「(利用不可)」と記しているものの，教職員がコースに手動でユーザ登録等を行う際に，ユーザ一覧のリストに利用停止のユーザも表示されてしまうのが煩わしいという課題が残っている。今のところ，解決するには Moodle のソースコードを修正するしかなさそうである。

5

おわりに
本稿執筆時点では，2023 年度に向けた準備を開始したばかりである。2022 年度版までの単年度版と連年度版の Moodle を動かしている Azure 上のVM は，OS や PHP の更新が必要となっていることから，VM を新たに作成し，その上に 2023 年度用の単年度版と連年度版を構築する予定である。
連年度版はこれまで年度が変わる際に Moodle のバージョンの更新のみを行ってきたが，今回初めて構築をし直すことになる。この機にメインアカ
ウントの認証方式を Shibboleth に戻すかどうか，検討を行っているところである。

414

参考文献
[1] 髙畑貴志, 三好康夫: “高知大学 moodle2020 利用状況レポート”, 高知大学教育研究論集,
Vol.26, pp.89-96, 2021．
[2] 林敏浩: “e-Knowledge コンソーシアム四国(eK4) と は ？ ”, 情 報 知 識 学 会 誌 , Vol.21,
No.2, pp.299-302, 2011.
[3] 大学連携 e-Learning 教育支援センター四国,
https://chipla-e.itc.kagawa-u.ac.jp/[4] 三好康夫, 石黒克也, 髙畑貴志, 立川明: “高知大学 Moodle の運用と利用率向上のための取組み”, 大学 ICT 推進協議会 2018 年度年次大会 (AXIES2018), MP-18, pp.1-2, 2018.
[5] 後藤田中, 裏和宏, 藤本憲市, 林敏浩: “大学連携 e ラーニングにおける認証連携方式の変更に伴う移行方法について”, 教育システム
情報学会第 42 回全国大会講演論文集, pp.461462, 2017.