2024 Volume 28 Issue 1 Pages 4-15
山口大学では，JupyterHubを独自に改修したWeb型プログラミング演習システム（YamaguchiHubと呼ぶ）を構築・運用している．このシステムでは，科目ごとの環境設定を自動的に生成・提供しつつ，多数の科目が自由にかつ同時にシステムを利用可能である．しかし，システムの構築手順が複雑な上，運用組織の計算機環境に依存する設定値等が実装部分から分離されていないため，他の組織への導入が困難である．そこで我々は，YamaguchiHubの構築・運用手順を整理し，国立情報学研究所が運営する学認クラウドオンデマンド構築サービス（OCS）に対応したアプリケーション・テンプレートとして開発して汎用化した．開発したシステムをMCJ-CloudHub（Multiple Course Jupyter-based Cloud Hub）と呼ぶ．MCJ-CloudHubの一般公開により，他の組織でもOCSから本システムの導入・運用が可能になる．本論文では，MCJ-CloudHubの概要及び開発状況，並びにこれまでの検証結果について述べる．
近年，世界各国で人工知能（AI）及びデータサイエンス（DS）分野の人材育成が重要視されている[1, 2]．これらの分野では，プログラミング演習及びデータ処理演習を含む実践的教育が重要である．多人数によるプログラミング演習を効率的・効果的に進めるためには，受講生の間で開発・実行環境やライブラリ等のバージョンが統一されていること，課題の配布・回収・採点等の支援機能を有すること，受講生の進捗状況を把握可能であること，並びに時間帯や場所を問わず課題への取り組みが可能であることが求められる．これらの要件を満たすため，Web型プログラミング演習システムの需要が高まっている[1–3]．企業や研究機関において，オープンソースのWeb型プログラム開発・実行環境であるJupyterHub[4]が広く普及している．そのため，国内・海外の教育機関ではJupyterHubの教育利用に関する研究・開発が進められてきた．国内の学協会においても関連イベントが開催されている[5, 6]．また，JupyterHubの機能拡張であるnbgrader[7–9]が持つ課題の配布・回収・採点機能，並びにフィードバックの作成・配布機能は，多人数の演習に有用である．さらに，Moodle[10]等の学習管理システムとJupyterHubを連携させたプログラミング教育環境の構築も進められている[11–13]．
国内では文部科学省により，理・工・農の3分野を対象とした学部再編等の支援事業，並びにデジタル分野の高度専門人材を養成する大学院教育の支援事業が進められている[14]．特にデジタル分野では，デジタルトランスフォーメーション（DX）に関連するAI・DS分野の知識・技術を備えた人材の育成が期待されている．しかし，地方の小規模・中規模の教育機関では，多数の科目や受講生に対応可能なプログラミング演習システムの導入・運用，並びにシステム管理者の確保が困難である．
山口大学では全学部において演習を含むDS関連の専門教育科目を開講しており，学部・学科ごとに演習で用いるプログラミング言語が異なる．そこで，MoodleとJupyterHub，nbgraderを組み合わせ，複数のプログラミング言語に対応したWeb型プログラミング演習システム（以降，YamaguchiHub）を構築・運用している[15]．YamaguchiHubでは，単一のJupyterHubシステムを多数の授業科目が自由にかつ同時に利用可能である．授業科目ごとの利用環境は自動的に生成・設定され，利用者のJupyter環境に適用される．科目ごとの設定作業等を必要としないため，各教員は容易にJupyterHubを利用可能であり，システム管理者の負担も大幅に軽減されている．学生は授業時間外でも各科目の課題に取り組み可能である．しかし，YamaguchiHubは従来のJupyterHubに比べてシステムの構成要素が多く，構築手順も複雑である．運用環境に依存する多数の設定値がソース・コードに含まれているため，他の教育機関への導入が困難である．
そこで我々は，YamaguchiHubの構築・運用手順を整理し，国立情報学研究所（NII）が運営する学認クラウドオンデマンド構築サービス（OCS）[16]に対応したアプリケーション・テンプレートとして開発し，汎用化した．開発したシステムをMCJ-CloudHub（Multiple Course Jupyter-based Cloud Hub）と呼ぶ．OCSは，オンプレミス環境とクラウド環境にまたがるハイブリッド・クラウドにアプリケーションの配置・実行が可能なクラウド構築支援サービスである．OCSは複数のクラウド・プロバイダに対応しているほか，オンプレミス環境とクラウド環境の一方だけでも利用可能である．そのため，各組織の計算機環境及びネットワーク環境に応じた形でアプリケーションの構築・運用が可能である（図1参照）．MCJ-CloudHubのアプリケーション・テンプレートを一般公開することにより[17]，同システムの他の教育機関への導入が可能になるほか，導入機関の間で環境構築，運用，授業実践に関するノウハウの共有が可能になる．
本論文では，2節でJupyterHubの教育利用に関する先行事例について整理した後，3節ではYamaguchiHubの概要及び問題点について述べる．4節では，MCJ-CloudHubについて，システムの概要及び構築・運用方法の汎用化，及びこれまでの動作検証について述べる．5節では，まとめと今後の課題について述べる．
本節では，JupyterHubの教育利用に関する先行事例及び関連研究について述べる．MCJ-CloudHubはYamaguchiHubの構築・運用手順を整理し，OCSの活用により汎用化したものであるため，本節で示す先行研究及び関連研究は両システムに共通している．
2.1 JupyterHubの教育利用近年，多人数を対象としたプログラミング演習においてWeb上で利用可能なプログラム開発・実行環境を提供するため，JupyterHubの教育利用が進められている．教員が自身の担当科目のために単独でシステムを構築・運用する小規模な環境については，JupyterHubサーバに蓄積されるログを活用し，受講生の学習状況の把握や授業改善に役立てる試みがなされている[18]．また，Moodle等の学習管理システムとJupyterHubを連携させ，講義資料及び課題ファイルの配布・回収を効率的に行うための教育支援システムが構築されている[11–13]．
JupyterHubを多数の教員が様々な科目に利用する場合，課題ファイル等を配布・回収するための共有ディレクトリを科目ごとに準備し，各科目の受講生のみアクセスを許可する必要が生じる．JupyterHubでは，グループ名（科目に相当），参加者，及び共有ディレクトリの情報をシステム設定ファイルに記述することにより，グループに固有の利用環境を実現可能であるが，複数のグループ設定を同時に利用することが出来ない．そのため，先行事例の多くは科目ごとの利用環境等を適用せずに広い範囲でJupyterHubを共同利用する事例と，各教員が個別にJupyterHubを構築・運用する事例に大別される．
学科等でシステムを共同利用しつつ，科目ごとの利用環境を適用する事例では，システム管理者は授業ごとに設定ファイルを差し替え，システムを再起動しなければならない．その場合，JupyterHubに1つの科目の環境設定が適用されている間，別の科目ではシステムを利用出来ないため，時間外学習への対応が困難である．
米国Google社はJupyterHubをベースとして実装したWeb型プログラム開発・実行環境であるGoogle Colaboratory（Colabとも呼ばれる）を提供しており，その教育利用も進められている[19]．Google Colaboratoryでは教員・学生が手軽にプログラム開発・実行環境を利用可能であり，システム管理も不要である．しかし，科目ごとの環境設定を適用する機能や，課題の配布・回収・採点機能，課題の進捗状況の把握を支援する機能を有していないため，多数の受講生によるプログラミング演習を効率的・効果的に進めることは困難である．また，2024年8月時点では，ColaboratoryにおけるJupyter Notebookファイルのランタイムとして指定可能なプログラミング言語はPython及びRのみである．その他のプログラミング言語を用いる場合，プログラムの実行に際し，通常とは異なる操作が要求される．Jupyter環境のオペレーティング・システム上に導入されていないプログラミング言語を用いる場合，利用者がその言語の処理系をインストールする必要が生じる．
2.2 nbgraderJupyterHubの機能拡張であるnbgrader[7]を利用したプログラミング教育も進められている[8, 9]．nbgraderを用いることにより，教員はJupyterHubのGUI上でJupyter Notebook形式の課題ファイルの作成・配布，提出物の回収・採点，及びフィードバック（採点結果及びコメント）の配布が可能である（図2参照）．図3は，nbgraderにおける教員側の課題一覧の画面を示している．画面内には，課題の一覧が表示され，各課題については課題名，状態，提出数等の情報が表示される．教員はこの画面において，課題の作成・配布，提出物の回収及び一括採点，フィードバックの公開等の操作を行う．
課題一覧の画面において教員が課題名もしくは提出数をクリックすると，図4に示す提出一覧の画面にジャンプする．画面内には受講生の一覧が表示され，各受講生については氏名，メールアドレス，提出状況，評点等が表示される．この画面では，個々の提出物に対する採点，フィードバックの公開等の操作が可能である．なお，図4では実際の授業科目における受講生の一覧を用いているため，氏名及びメールアドレスの箇所をぼかしている．
受講生はJupyterHubのGUI上で，公開中の課題ファイルの取得，課題の提出，及びフィードバックの取得・閲覧が可能である．図5は，受講生が取得した課題ファイルを開いた例を示している．受講生は課題ファイルを開き，ノートブック内のセルにプログラムや解答を記述し，実行した後，提出の操作を行う．
nbgraderでは，教員はコース（科目に相当）を作成し，コース内に課題を作成する．コースごとに課題，提出物，及びフィードバックを保存するためのファイル交換用ディレクトリが必要になる．複数のコースを取り扱うためにはコース名，コースの参加者一覧，そのコースで用いられるファイル交換用ディレクトリのパス等の設定内容をJupyterHubのシステム設定ファイルに記述する必要があるが，前述のJupyterHubの問題点と同様に，複数のコースの同時利用が困難である．
各種ディレクトリの取り扱い及びセキュリティに関する問題点も存在する．図6は，従来のnbgraderにおけるファイル交換用ディレクトリの権限設定を示している．図6では，各ディレクトリのアクセス権限の表現として，Unix系ファイルシステムにおける「rwx」表現を用いている．図6において「exchange」はファイル交換用ディレクトリのルート・ディレクトリ，「course1」は科目のファイル交換用ディレクトリを示している．「feedback」は受講生に公開するフィードバック・ファイルを保存するディレクトリ，「inbound」は受講生からの提出物を保存するディレクトリ，「outbound」は公開中の課題ファイルを保存するディレクトリである．「inbound」及び「outbound」ディレクトリの配下には，教員が定義した各課題のディレクトリが作成される．また，「teacher1」は授業担当教員のユーザ名，「users」は全ての利用者が所属するグループ名である．「teacher1:users」という表記は，そのディレクトリの所有者が「teacher1」，所属グループが「users」であることを示している．nbgraderでは，ルート・ディレクトリ（図6の「exchange」）のアクセス権限は「777」（誰でも読み出し，書き込み，実行が可能）に設定される．これは，認証サーバもしくはファイルサーバのアカウント情報を用いてディレクトリ等の所有者及びアクセス権限を適切に設定する機能を備えていないためである．nbgraderは，認証サーバやファイルサーバのアカウント情報を用いてディレクトリ等の所有者及，所属グループ，及びアクセス権限を適切に設定する機能を備えていない．このような環境下において，各科目の担当教員が手動のコマンド操作により科目や課題のディレクトリを作成するため，ルート・ディレクトリは，すべての利用者から読み書き可能に設定されている．そのため，いずれの利用者も科目のディレクトリ及びその配下にある各種ディレクトリ，それらに保存されているファイルについて，所有者の自身への変更，及びアクセス権限の変更が可能である．これに伴い，「course1」以下のディレクトリ及びファイルについて読み書き，削除が可能である．
また，利用者のホームディレクトリの配下には，課題名に応じたディレクトリが作成され，取得した課題ファイル，提出物，及びフィードバックが保存される．これらの配置場所が科目ごとに分離されていないため，科目間で課題名が重複した場合は正常に動作しない．
JupyterHub及びnbgraderは，標準のデータベース管理ソフトウェアとしてSQLite[20]を使用する．SQLiteは別のサーバからのリモート・アクセスに対応していない．複数のサーバから構成される分散環境では，各利用者のJupyter環境からデータベースにアクセス出来ないため，システムの運用に支障が生じる．
以上で述べたように，従来のJupyterHub及びnbgraderは，大学全体のような広範囲において多数の科目がシステムを共同利用する用途には適していない．
2.3 CoursewareHub複数科目におけるJupyterHubの利用を支援する先行事例として，NIIが運用しているCoursewareHubが挙げられる[21]．CoursewareHubは，OCSに準拠したアプリケーション・テンプレートとしても提供されている[22]．教員もしくはシステム管理者は，OCSのシステムとテンプレート・ファイルを用いて，授業科目ごとに個別にJupyterHubシステムを構築・運用する．科目ごとのシステム構築に際し，テンプレート・ファイルの修正により，設定内容やシステム規模を調節可能な利点がある．一方，アプリケーション・テンプレートを取り扱うためには，OCSを支える基盤ソフトウェアである仮想クラウドコントローラの操作に関する知識が必要になる．さらに，テンプレートにはシステムの構築・運用のための設定項目が多数含まれており，設定内容を適切に記述するためには，運用組織のシステム管理者としての権限及び知識が必要とされるため，一般の授業担当教員では利用が困難である．システム管理者が授業担当教員に代わって各科目のシステムを構築・運用する場合，利用科目数の増加に応じて管理者の負担が増大する．
CoursewareHubでは，科目ごとにシステムの規模，一部の仕様，及び設定内容を変更可能な利便性を有する反面，「授業担当教員≒システム管理者」であることが求められるため，大学全体のような広範囲にわたって多数の科目がシステムを利用する用途には適していない．
図7に，YamaguchiHubの概要を示す．システムは大まかにMoodle及びJupyterHubから構成される．システムは山口大学のオンプレミス環境に実装されており，構成要素となる各種サーバは仮想サーバとして構築されている．Moodleシステムは山口大学において通常の授業で利用されているものである．JupyterHubシステムは1台のManagerノードと複数のWorkerノード，ファイルサーバ，LDAPサーバ（認証サーバ），及びデータベースサーバから構成される．利用者（教員・学生）はMoodleコースに設置された「外部ツール」のインスタンスを経由してJupyterHubにアクセスする．MoodleとJupyterHubの連携の仕組みとしてLTI（Learning Tools Interoperability）[23, 24]を採用しているため，利用者のJupyterHubへのログインはLTI認証[25, 26]により自動的に完了する．ログインの完了後，利用者が経由してきたMoodleコース，及びコースにおける利用者のロール（役割）に応じて，自動的に環境設定等が行われる．まず，利用者がLDAPサーバに未登録の場合，アカウント登録及びホームディレクトリの作成が行われる．続いて，nbgraderを利用しない科目のための共有ディレクトリが作成される．共有ディレクトリのアクセス権限は，Moodleコースの「教師」は読み書き可能に，「学生」は読み込み限定に設定される．また，利用者のホームディレクトリの配下に，共有ディレクトリへのシンボリックリンクが作成される．シンボリックリンクの名称は科目によらず単一であるが，リンク先となる共有ディレクトリは，利用者が経由してきたMoodleコースに応じて選択される．受講生は必要なファイル等を共有ディレクトリから各自のホームディレクトリにコピーした後，講義資料の閲覧やプログラムの作成が可能である．この仕組みにより，nbgraderを利用しない場合でも課題ファイルの配布が可能である．また，利用者が経由してきたMoodleコースの情報に基づき，そのMoodleコース（科目に相当）に関連する共有ディレクトリのみが表示されるため，システムの利用科目数が増加した場合も，利用者による共有ディレクトリの選択間違いが生じない．
次に，nbgraderで利用されるディレクトリ等が作成・設定される．利用者が「教師」の場合は該当科目のファイル交換用ディレクトリが作成され，アクセス権限が設定される．従来のJupyterHubでは，科目に固有の環境設定を適用する場合，JupyterHubの設定ファイルに設定内容を記述しなければならない．JupyterHubの設定ファイルの内容は利用者ごとのJupyter環境に影響を及ぼすため，システム全体がその科目に専用のものになってしまう．一方，YamaguchiHubでは，利用者と科目に応じた設定ファイルが動的に生成され，利用者のJupyter環境に適用される．ユーザ名，コース名，役割（教師／学生），nbgraderで用いるファイル交換用ディレクトリのパス等の情報がJupyterHubから引き渡され，利用者のJupyter環境の設定ファイルに記述される．また，従来のnbgraderでは，利用者はnbgraderに登録済みのコースの一覧から所定のコースを選択した後に各種操作を行う．このとき，受講していない科目のnbgraderコースも表示され，選択可能である．nbgraderの利用科目数が増加した場合，利用者がコースの選択を間違える恐れがある．これに対しYamaguchiHubでは，Jupyter環境の起動時に，利用者が経由してきたMoodleコースに対応したnbgraderコースが自動的に作成・選択済みとなる．利用者がMoodleコースの「教師」である場合，Moodleのデータベースから受講生一覧が取得され，利用者のホームディレクトリの配下にあるnbgrader用の設定ファイルに適用される．
2.2節の後半で述べた問題点を改善するため，ファイル交換用ディレクトリのルート・ディレクトリのアクセス権限を修正した．さらに，JupyterHub用のLDAPサーバに登録されたアカウント情報を利用し，科目ごとのファイル交換用ディレクトリの所有者，所属グループ及びアクセス権限も修正した．図8は，YamaguchiHubにおけるnbgraderのファイル交換用ディレクトリの権限設定を示している．図6から変更した箇所は赤色の文字で示している．図8において「teachers」はコースの教師が所属するグループ名，「students」はコースの学生が所属するグループ名である．従来のnbgraderでは，利用者のユーザ・カウントは一律に「users」グループに所属するが，YamaguchiHubではMoodleコースにおける役割により，利用者は2つのグループに分けられる．その他のディレクトリ及びユーザ名については，図6と同様である．ルート・ディレクトリ（図8の「exchange」）のアクセス権限を「755」（システム管理者のみ書き込み可能）に修正したため，利用者はその配下にある「course1」等の各科目のディレクトリについて，所有者及びアクセス権限を変更することができない．図8の「course1」ディレクトリは，授業担当者である「teacher1」のみ書き込み可能であり，他の利用者は，「course1」ディレクトリの書き換え（名称変更や削除），及び所有権の取得はできない．「feedback」ディレクトリでは，授業担当教員以外の利用者には読み出し及び書き込みの権限が無く，ディレクトリ内に保存されているファイルの名称等も取得できない．さらに，利用者ごとのフィードバック・ファイルの名称はランダムな文字列である．そのため，授業担当教員以外の利用者は，フィードバック・ファイルの閲覧・書き換え・削除はできない．科目の受講生は，nbgraderのWeb GUIを介して自身へのフィードバックを閲覧可能である．「inbound」ディレクトリでは，受講生から提出された提出物を保存するため，すべての利用者に書き込みが許可されている．しかし，「teacher1」以外の利用者は読み出しの権限が無いため，提出物のファイルを閲覧できないほか，ディレクトリ内にあるファイルの名称等も取得できない．加えて，提出物のファイル名にはランダムな文字列及び提出日時が含まれ，他人の提出物のファイル名を特定することは困難であるため，他人の提出物の書き換え及び削除はできない．これらの仕組みにより，他者の提出物やフィードバックへのアクセスを禁止している．「outbound」ディレクトリについては，いずれの利用者もディレクトリ内にあるファイル（公開中の課題ファイル）を閲覧可能である．ただし，「teacher1」以外の利用者はこのディレクトリ及びその中に保存されたファイルの書き換え及び削除はできない．また，利用者のホームディレクトリ内に作成される各課題のディレクトリについても，科目ごとに配置場所が分離されるよう，ソース・コードを修正したため，科目間で課題名が重複していても不具合を生じない．
以上で述べたように，YamaguchiHubでは，JupyterHub（Managerノード）は利用者のWebブラウザとJupyter環境の間の中継役に加え，Moodle及び認証サーバから取得した情報に基づいてユーザ・アカウントの作成，各種ディレクトリの作成・権限設定，及び利用者のJupyter環境に引き渡す環境設定の作成を担当する．個々のJupyter環境は科目及びユーザの役割（教師／学生）に固有のものとして動作するが，JupyterHubは特定の科目に依存しない状態が維持されるため，複数科目による同時利用が可能である．また，ファイル交換用ディレクトリのアクセス権限，及び利用者のホームディレクトリ配下に作成される各課題のディレクトリの配置を改善することにより，多数の利用者が様々な科目でnbgraderを利用する際に生じる不具合を解消している．
YamaguchiHubはDS関連の専門教育科目で利用されており，2023年度は16のクラスで利用された．その他の専門教育科目にも利用されている．授業担当教員からの要望に基づき，Python，R，及びOctaveを利用可能とし，授業に必要なパッケージ等を追加したJupyter環境を提供している．
3.2 先行事例との比較YamaguchiHubにおける従来のJupyterHub及びnbgraderからの改善点については，いくつかの先行事例が存在する．LTIを用いて学習管理システムからコース情報や受講生一覧を取得し，ファイル交換用ディレクトリを自動的に作成する事例[27]は存在するが，ユーザ・アカウントの登録及びホームディレクトリの作成までは考慮されていない．ファイル交換用ディレクトリにある他者の提出物等を閲覧・書き換え出来ないように権限を設定する事例[28]は存在するが，教員は担当外の科目の課題内容や提出物の閲覧・書き換えが可能であり，科目ごとの権限の分離が不完全である．YamaguchiHubでは，認証サーバのアカウント登録，ホームディレクトリ及び各種ディレクトリの作成及び権限設定がすべて自動的に行われる．
また，nbgraderとその改善事例は，すべての利用者のJupyter環境が単一のサーバ（Workerノード）上に配置されることを前提としている．YamaguchiHubでは，分散環境においてもnbgraderを利用可能である．データベース管理ソフトウェアとしてMariaDB（MySQLの互換ソフトウェア）を採用し，いずれのWorkerノードもデータベースを読み書き可能にした．各種ディレクトリのファイルサーバ上への配置，及び認証サーバを活用したアクセス権限設定の改善も組み合わせ，サーバ分散環境に対応している．
3.3 YamaguchiHubの問題点YamaguchiHubでは，各科目の担当教員は環境構築の作業に関与しない．教員・学生は特別な作業を行うことなく，個々の科目に応じた設定が施されたJupyterHubを利用可能である．利用者は授業時間外でもプログラムの作成・実行や，nbgraderの各種操作が可能である．システム管理者についても，システムを構築・起動した後には，ハードウェア障害の対応等を除いて保守作業が不要であるため，運用・保守の負担が軽減される．利用科目の増減，年度ごとの情報の更新，受講生の変動に対応する作業も不要である．しかし，データベースサーバ，ファイルサーバ，及び認証サーバが追加され，システムの構築手順が複雑化している．
このシステムを他の教育機関で導入・運用可能にするためには，以下に示す課題が挙げられる．
● 山口大学の計算機環境及びネットワーク環境に依存した設定内容及び実装箇所の分離．
● 学習管理システムからの受講生一覧の取得方法の汎用化（YamaguchiHubではJupyterHub内に作成したプログラムがMoodleのデータベースから直接に取得）．
● 属性情報の取得方法の汎用化（YamaguchiHubでは大学のLDAPサーバのデータ構造に依存）．
● JupyterHub，nbgrader等の各種ソフトウェア，ライブラリのバージョンアップ．
我々はこれらの問題点を改善すると共に，YamaguchiHubと同等の機能を有するシステムをOCSに対応したアプリケーション・テンプレートとして開発した．このシステムをMCJ-CloudHubと呼ぶ．
図9に，MCJ-CloudHubの概要を示す．MCJ-CloudHubは，YamaguchiHubの構築・運用手順を整理した後，同等の機能を有するシステムをOCSに対応したアプリケーション・テンプレートとして開発し，汎用化したものである．アプリケーション・テンプレートにはJupyterHubのManagerノード及びWorkerノードを生成する手続き，各サーバ上で稼働するアプリケーションの設定内容が含まれる．ManagerノードではJupyterHub，Nginx（Webサーバ），MariaDB（DBサーバ），及びOpenLDAP（認証サーバ）が稼働する．図9では，OCSのアプリケーション・テンプレートにより構築されたMoodleを用いているが，運用組織の既存のMoodleとも連携可能である．
開発に際し，3.3節の後半で示した各課題を解決した．
● 運用組織の計算機環境に依存する箇所については，テンプレート内で設定項目として記述可能にした．システム管理者は，各設定項目において運用環境に応じた設定値を記入する．
● 受講生一覧は，JupyterHubへのログイン時にLTIのNRPS（Name and Role Provisioning Services）[29]を用いて取得することとした．
● 利用者の属性情報（氏名，メールアドレス，教員／学生の別等）の供給元は，NRPSを標準としている．
● 各種ソフトウェア及びライブラリを更新した．具体的には，JupyterHubを1.4.2から4.0.2に，nbgraderを0.6.2から0.9.1に，MoodleとJupyterHubの連携に用いるLTI規格を1.1から1.3に更新した．利用者のJupyter環境のDockerイメージも，jupyter/scipy-notebook:python-3.8.8からjupyter/scipy-notebook:lab-4.0.6（:notebook-7.0.4）に更新した．
MCJ-CloudHubとCoursewareHubとの相違点として，システム管理者と教員との分離が挙げられる．MCJ-CloudHubでは，科目ごとのJupyterHubの利用開始にあたり，教員が関与する作業は，該当科目のMoodleコースに「外部ツール」のインスタンスを貼り付ける操作のみである．そのため，運用組織の管理者権限を持たない教員，情報システムの構築・運用に詳しくない教員でも容易に利用可能である．
図10に，教員がMoodleコースに外部ツールを貼り付ける例を示す．まず，Moodleコースに貼り付けるコンテンツ（活動・リソース）の選択画面において，「外部ツール」を選択する（図10左上）．次に，外部ツールの設定画面において，事前設定（プリセット）のリストからJupyterHubに関する設定名を選択する（図10右上）．システム管理者がJupyterHubのURL，LTI設定，認証用の公開鍵を記載した事前設定を準備することにより，教員による外部ツールの設定作業は表示名の記入，及び事前設定の選択のみとなる．設定が完了すると，Moodleコース上に外部ツールへのリンクが表示される（図10左下）．利用者がこのリンクをクリックするとJupyterHubの画面が開き，システムを利用可能になる（図10右下）．LTI連携により，JupyterHubへのログインは自動的に完了する．
我々は2023年9月までに，学術研究用のパブリック・クラウドであるmdx[30]上においてMCJ-CloudHubの動作確認を進めた．アプリケーション・テンプレートを用いてmdx上にMCJ-CloudHubを構築し，著者のうち6名がnbgraderによる課題の作成・配布，提出物の回収・採点等の機能について動作を確認した．利用者のJupyter環境を展開するためのWorkerノードは3台とした．Workerノードごとの仮想CPUコア数は8コア，仮想メモリ容量は32 GBである．なお，利用者のJupyter環境ごとの資源割り当ての最大値は，CPUコア数は0.5コア，メモリ容量は512 MBである．参加者は6名であるため，Workerノードごとに2名の参加者を収容している．
mdxを用いた動作検証は以下の手順に沿って進めた．
（1）参加者はそれぞれ，mdx上に準備されたMoodleサイトにログインする．
（2）参加者はそれぞれ，所定のMoodleコースにアクセスし，「外部ツール」のインスタンスを経由してJupyterHubにログインする．
（3）教員の合図により，受講生は一斉にJupyter環境を起動する．
（4）受講生はそれぞれ，nbgraderの課題ファイルを取得し，解答を記入し，プログラムを実行した後にファイルを提出する．課題は2問あり，それぞれに，実行時間が数秒程度の簡単なPythonスクリプトの作成を含む．
（5）受講生全員が課題を提出した後，教員は課題の回収及び自動採点を実行し，生成されたフィードバックの公開の操作を行う．
（6）自動採点が行われている間，受講生は別のJupyter Notebookファイルを開き，グラフの表示を伴うスクリプトや，数分程度の実行時間を要するスクリプトを実行する．
（7）受講生はそれぞれ，nbgraderのフィードバックを取得し，閲覧する．
動作検証では，Moodleコースを経由したJupyterHubへのログイン，MoodleとJupyterHub（Managerノード）の間でのLTI規格のNRPSを用いた情報の取得，取得した情報を活用したユーザ・アカウントの登録及び各種ディレクトリの自動作成及び権限設定，利用者及びコースの情報を反映させたJupyter環境の起動が正常に動作することが確認された．また，nbgraderによる課題の配布・提出・回収・採点等の機能がmdx上で正常に動作することが確認された．参加者が少なく，各サーバの負荷状況の変動がほぼ生じなかったため，サーバの負荷状況の計測結果については割愛する．
4.2.2 AWSを用いた動作検証2024年2月には，AWS（Amazon Web Services）上において動作検証を行った．アプリケーション・テンプレートを用いてAWS上にMCJ-CloudHubを構築し，教員1名及び受講生11名の計12名による動作検証を行った．Workerノードは3台とし，それぞれのインスタンスタイプは「m4.2xlarge」とした．Workerノードごとのスペック，及び利用者ごとのJupyter環境への資源割り当ての設定は，mdxを用いた動作検証の際と同様である．参加者は12名であるため，Workerノードごとに4名の参加者を収容している．動作検証の手順は，4.2.1節に示したmdx上の動作検証の手順と同様である．
動作検証により，mdxを用いた場合と同様，MoodleとJupyterHubの連携，取得した情報を活用したユーザ・アカウント及び各種ディレクトリの作成及び権限設定，利用者及びコースの情報を反映させたJupyter環境の起動が正常に動作することが確認された．また，nbgraderの機能が正常に動作することが確認された．図11及び図12はそれぞれ，動作検証の開始時点からの経過時間に対する各仮想サーバ（Managerノード及びWorkerノード）のロード・アベレージ及びメモリ使用量の変動を示している．検証開始から5分ほど経過した時点で，参加者は一斉にJupyter環境を起動した．これに伴い，Workerノードのロード・アベレージ及びメモリ使用量が増加している．いずれの参加者においても，Jupyter環境の起動に要した時間は5～10秒程度であった．動作検証に用いたJupyter環境のDockerイメージのサイズは2 GB程度だったため，起動に要した処理時間が短く，いずれのWorkerノードも高負荷状態には達しなかった．検証開始から25分ほど経過した頃から，Workerノード3のロード・アベレージ及びメモリ使用量が著しく増加している．これは，当該時刻にWorkerノード3において提出物の自動採点が開始されたためである．一括の自動採点では，提出された各ノートブック内のセルを順番に実行し，採点対象として指定されているセルについては，教員が定めたルールに基づいて評点を算出する．従って，全提出物の一括の自動採点には「ノートブックあたりの実行時間×提出数」の時間を要する．Workerノードのメモリ使用量は，最大で2.2 GB程度であった．ノードごと（仮想サーバごと）の仮想メモリ容量は32 GBであるため，メモリ使用量には十分な余裕が見られた．
これまでの動作検証により，MCJ-CloudHubのOCSテンプレートはmdx及びAWSにおいて正常に動作することが示された．我々は現在，MCJ-CloudHubの初期バージョンをGitHub上で一般公開している[17]．
本論文では，複数科目で同時用可能なWeb型プログラミング演習システムの開発，アプリケーション・テンプレートの開発による構築・運用方法の汎用化，及びその動作検証について述べた．
山口大学で運用中のプログラミング演習システム（YamaguchiHub）では，大学の計算機環境，及びネットワーク環境に依存する箇所が多く，他の組織への導入が困難である．また，利用者ごとのJupyter環境はDockerコンテナとして起動するが，コンテナごとに割り当てるCPUコア数及びメモリ容量は，システム全体にわたる設定値として，JupyterHubの設定ファイルに記述しなければならない．システムの利用科目数及び同時利用者数の増加に伴い，必要な計算機資源も増大する．今後，利用科目数及び同時利用者数が増加した場合，オンプレミス環境だけで十分な計算機資源を整備・提供し続けることが困難になる恐れがある．一方，多人数による演習に対応可能な計算機資源をAWS等のクラウド環境に確保するための費用は高額である．プログラミング演習システムの導入・運用にあたり，組織ごとに異なる計算機環境に柔軟に対応可能であることが求められる．
そこで我々は，YamaguchiHubをOCSに対応したアプリケーション・テンプレートとして開発し，汎用化した．開発したシステムをMCJ-CloudHubと呼ぶ．ハイブリッド・クラウドへの対応により，組織ごとの計算機環境に応じた実装・運用が容易になる．また，アプリケーション・テンプレートの一般公開により，情報システム部門が手薄な教育機関においても，希望する計算機環境の上にプログラミング演習システムの構築・運用が可能となる．MCJ-CloudHubの導入機関の利用者，及びシステム管理者によるユーザ・コミュニティを形成し，関連分野の活性化を促すことも目指している．
これまでに，MCJ-CloudHubをOCSに対応したアプリケーション・テンプレートとして実装した．これと並行して，JupyterHubの設定ファイルの修正を進めた．システムの運用組織ごとに設定値が異なる箇所については，それらの値をテンプレート内でパラメータとして指定・記述できるよう，ソース・コード及び設定ファイルから分離した．また，LTI規格のNRPSにより，利用者の氏名，メールアドレス等の属性情報，並びにnbgraderで利用する受講生一覧を取得可能とした．
mdx上及びAWS上での動作検証により，MCJ-CloudHubのアプリケーション・テンプレートは，複数のクラウド・プロバイダに対応可能であることが示された．双方のクラウド環境において，教員はnbgraderを用いて課題ファイルの配布・回収，自動採点及びフィードバックの配布が可能であることが確認された．受講生は課題ファイルの取得，課題の提出，採点結果及びフィードバックの閲覧が可能であることが示された．
MCJ-CloudHubのアプリケーション・テンプレートは現在，GitHub上で公開中である[17]．
今後の課題として，オンプレミス環境，及びハイブリッド・クラウド環境における動作検証が必要である．また，利用者の属性情報の供給元として，GakuNin[31]に準拠したShibbolethサーバも選択可能にする予定である．LTI規格のNRPSと同様，GakuNin準拠のShibbolethサーバには特定の運用組織に依存しない共通の属性項目が定義されているため，複数の教育機関にMCJ-CloudHubを導入するために有用である．MCJ-CloudHubは現在，多数の受講生によるオンライン講義・演習を効率的・効果的に進めるための支援機能が不足している．具体的にはまず，多人数による演習を効率的に運営するため，教員が各受講生の進捗状況を把握するための支援機能が必要である．次に，教育機関ごとの計算機環境を有効活用して多様な科目に対応するため，各利用者のJupyter環境に割り当てる計算資源を見積もる技術が必要である．今後の課題として，これらの支援機能に関する研究・開発も挙げられる．
この研究は2024年度国立情報学研究所公募型共同研究（24S0802）及び情報・システム研究機構戦略的研究プロジェクト（2024-SRP-06）の助成を受けています．
本研究にご協力いただいた株式会社アスケイドの那須野淳様，羽鳥文子様，増山隆様，神田千暁様，鳥井貴史様，寺山流晟様に深く感謝いたします．
