1．情報統括本部の誕生

（1）大学における情報センター

大学内で情報サービスを提供するセンタはそれぞれの時代の要請に応じて目的別に設置されてきた．九州大学（以後，本学）においては，中央計数施設（学内措置で1963年に設置），大型計算機センター（1968年設置の省令施設），情報処理教育センター（1977年設置の省令施設），統合情報伝達システム（KITE）運用センター（学内措置で1994年設置）などである．こうした目的別の情報センターはその後，大学全体の教育・研究・業務・診療を支える幅広い情報サービスを実現するための情報基盤を提供する情報センターに変容する必要に迫られた．本学においても，2000年4月に上述の情報関連施設と附属図書館の一部を有機的に統合した組織として情報基盤センターに改組された．

（2）情報統括本部

学内の情報環境に関連する実状を正確に把握するために，2006年度に情報担当理事を核に情報基盤センター関係者を中心にしてCIO-WG （Chief Information Officer - Working Group）が設置され，当時の情報基盤センター長とCIO-WGのメンバが学内全部局を回ってヒアリングを行い，情報環境整備に関連する多くの意見を集約した．その議論に基づいて，2007年度に情報統括本部が設置されることになった．情報基盤センターは情報統括本部の発足に合わせて2007年4月に情報基盤研究開発センターに改組され，事務局情報企画課と統合して，情報統括本部の母体となった．情報統括本部は学内の教育・研究・業務を円滑に行うための情報環境整備について全責任を持つ，情報基盤研究開発センターと情報システム部を実体とする，仮想的な組織である[1]．

情報統括本部では，情報サービスに対応してそれぞれ事業室（定常的なサービスに対応），タスクフォース（新規サービスの実現，各種新規事項の検討）を設置し，利用者にサービスを提供している．表1に2020年度現在の事業室等の一覧を示す[2]．こうした事業室制は定常的な業務の遂行にはおおむね有効であるが，複数の事業室に跨る案件については，情報統括本部長のように関連する事業室をまとめる強い調整力とリーダシップが必要である．

（3）情報環境整備のための組織

多くの大学では，学内の情報環境整備を情報センターが担当する場合が多いが，通常の情報センターはあくまでも学内の部局としての1組織であり，大学全体の情報環境の整備を提言し，推進するには立場が弱い場合が多い．こうした情報センターに相当する組織さえない大学もある．本学においては，情報統括本部は部局の上位に位置し，大学全体の情報環境整備の企画・推進を行える立場にある．こうした組織の整備が大学の情報環境整備を円滑に行うためには必要である．

（4）本稿の位置付け

筆者は，九州芸術工科大学（芸工大）と九州大学との2003年10月の統合まで約6年間（1997年11月〜2003年9月），芸工大情報処理センター長であった．大学統合後は情報基盤センターの教授（兼務）として情報統括本部の立ち上げなど，さまざまな活動にかかわり，定年までの5年半（2010年10月〜2016年3月）は情報統括本部長（総長特別補佐，後に副理事）として，情報統括本部の活動を牽引した．さらに定年退職後も4年間（2016年4月〜2020年3月）にわたり，特任教授（学術研究員）として「残務整理」を行った．

本稿は，2007年度の情報統括本部の誕生から2020年度までの情報環境整備において，筆者が直接かかわった活動をまとめたものである．おおむね時間の流れに沿って，関連項目を整理し，情報統括本部の誕生，ソフトウェアの包括契約，認証基盤，基本メール，教育情報システム，PC必携化（BYOD），遠隔講義・会議システム，学習支援システム，それらを支えるクラウド，およびISMSの取得について述べる．

参考までに本学のキャンパスの位置関係を図1に，構成員の規模を表2に示す．箱崎キャンパスは伊都キャンパスへの移転が完了し，移転関連の一部の事務が残っている．黄色の線は，天神データセンターを中心に各キャンパスを接続するスター型ネットワークの接続関係を示している．

2．ソフトウェアの包括契約

2.1　ソフトウェア利用上の問題

2006年度にCIO-WGが学内意見を集約した結果，利用者が一番困っているのがソフトウェアに関連する経費であることが判明した．たとえば，大学の研究室には多くの学生が所属し，学生が使用するPCのセキュリティを確保するためにはセキュリティ対策ソフトウェアが必要である．また学生がOfficeソフトウェアを使えないと困る．研究費が毎年減少する中で，こうした学生用のソフトウェアを継続して整備していくことが指導教員の大きな負担になっていた．その結果，法令遵守にも影響する．そこで，情報統括本部の設置前ではあるが，ソフトウェアの一括契約で大学全体のソフトウェアにかかわる経費を節減する試みを行った[3],[4]．

2.2　セキュリティ対策ソフトウェア

（1）トレンドマイクロ製品の一括契約

筆者は芸工大情報処理センター長としてトレンドマイクロのセキュリティ対策ソフトウェア1,000ライセンスをセンター経費で一括契約し，学内に無料で提供していた．この経験から，情報統括本部設置前ではあったが，セキュリティ対策ソフトウェアを一括契約して，大学全体に安価に提供する提案を行った．その結果，まず2006年10月にトレンドマイクロ社製のセキュリティ対策ソフトウェア5,000ライセンスを一括契約し，単価650円で利用者希望者に提供した．

（2）シマンテック製品の包括契約

2007年2月にシマンテック社製のSCS（Symantec Client Security）10,000ライセンスを一括契約し，2007年3月から単価270円で全学の利用希望者に提供した．当初は課金していたが，その後，利用者から個別に利用料金を集める事務手続きの手間を考慮して，2009年4月から全額を情報統括本部で負担することとし，無料とした．

その後，2011年6月からSymantec Endpoint Protection（SEP）をアカデミックサブスクリプション＋学生オプションに契約を変更して大学全体の包括契約として利用者に提供した．その結果，大学の予算で購入したすべてのPC，さらに教職員＋学生の個人PCで1人につき1台で利用可能になった．

一方，トレンドマイクロ社製については利用者数が延びなかったこと，単価を下げられなかったことから，2011年9月末で一括契約を終了した．その結果，トレンドマイクロ社製セキュリティ対策ソフトウェアを使用したい場合には通常価格での自己負担になった．

（3）セキュリティ対策ソフトウェアの切り替え

アカデミックサブスクリプション＋学生オプションの廃止が2017年6月2日にシマンテックから正式に通知された．シマンテックの代替案は大学としては受け入れがたい内容であった．当時の契約では2018年5月31日まではSEPを利用可能で，少しだけ時間的な余裕があり，それまでに別のセキュリティ対策ソフトウェアに切り替える必要に迫られた． セキュリティ対策ソフトウェアを全学に提供することは次のような事情で必須であった．

• PC必携化には不可欠
• 学生の経済的支援
• 学生を含めた全学的セキュリティを確保

利用可能なセキュリティ対策ソフトウェアとして，価格，性能，包括契約可能なことなどを考慮して，検討した結果，トレンドマイクロのキャンパスアグリーメントを選定した．この契約で利用可能な対象は次のとおりである．

• 大学の予算で購入したすべてのPC
• 教職員＋学生が大学に持ち込む可能性があるPC，Mac
• Server for Linux

SEPから新しいセキュリティ対策ソフトウェアに切り替える目標期限は切りのよいところで，年度末の2018年3月末とした．契約の制約で時間がないことから，次のような方針で行った．

• 2017年度に卒業する学生はSEPのままでよい．
• 2018年度の新入生はPC必携化のための入学時のPC講習会でトレンドマイクロのセキュリティ対策ソフトウェアを入れる．
• 契約を迅速に行うと2017年11月1日からトレンドマイクロ社の製品が利用可能となる．一方，ライセンス管理サーバの準備が11月下旬になるため，利用者には11月下旬から新しいセキュリティ対策ソフトウェアを提供開始する．

（4）Windows Updateによるトラブル

セキュリティ対策ソフトウェアの切り替えはほぼ順調に進んだが，切り替え期間が終わる頃に，Windows 10の更新に関連して，別の問題が発生した．2018年4月にWindows 10のバージョンがWindows 10 April 2018 Update RS4 （以下，「RS4」という）に更新された．一方でトレンドマイクロ社製のウイルスバスター XG SP1 （TMVB）はRS4に未対応であった．

そのため，TMVBをインストールしたままRS4への更新を適用してしまうと，Windows Update中にフリーズする現象が発生し，ログイン後ほぼ何もできなくなる事例が発生した．その場合にはPCの初期化（OSの再インストール）が必要になる事例があった．さらにTMVBをインストールしたままRS4を適用した後に，ウイルスバスターをアンインストールし，Windows Defender を有効にする際に不具合が発生するとの報告もあった．

セキュリティ対策ソフトウェアが新しいWindowsに対応してない状態でWindows Updateの更新が行われてしまうことを想定していなかったために，対応が後手にまわった．2018年6月12日にトレンドマイクロ社製のTMVBがRS4に対応し，2018年6月14日10:25から最新のRS4に対応したウイルスバスターをソフトウェア事業室が提供できるまでは，Windows Updateの実施を保留にするように周知する以外に方法がなかった．すでにトラブルに見舞われた利用者には最悪，Windows 10を再インストールしてもらう事態になり，迷惑をかけた．この件は新聞でも記事として取り上げられた．

2.3　マイクロソフトのOffice

2006年度後期に2つのセキュリティ対策ソフトウェアの一括契約が成功したことから，次にマイクロソフトのCA（Campus Agreement）契約に取り組んだ．2006年当時はSchool AgreementというPCの台数に比例する契約形態はあったが，PCの台数を把握することは大学では困難である．そこで，マイクロソフトと交渉して，職員数や学生数で契約するCAを準備してもらった．一括契約をした結果，2007年4月からマイクロソフトのWindowsとOffice Enterprise 2007/Professional 2003を大学の経費で購入したPCに自由にインストールできるようになった．

その後，大学の予算で買ったPCだけでなく，個人のPCにもインストールできるように契約を改訂した．その結果，個人のPCに1人1台であるが，Officeを入れることができるようになった．これが後述のPC必携化（BYOD）にも役立った．

ソフトウェアの使用に必要なプロダクトキーに関しては，Volume License Keyとしてほとんどのソフトウェアに関して1機関あたり1つのプロダクトキーしか付与されないため，プロダクトキーが利用者の目に晒されないようにしてキーを厳密に管理し流出を防ぐ必要がある．そのため利用条件やキーの管理方法（KMS，MAK等）に合わせて配布の仕方を変え，ソフトウェア配布用のサイトは学内PC用，教職員個人PC用，学生個人PC用の3種類を用意した．

マイクロソフトとの包括契約（EES）の経費は学生分を本部で負担してもらい，職員分は人数で割って均等（約4,000円）に負担してもらった．その結果，この一括契約は研究室で学生を抱えている教員には大変な福音となった．具体的には，教員は特段の追加支出無しで研究室の学生全員にOfficeを提供でき，確実に法令遵守を実現できる．

Officeを提供していた当初は卒業時に「学生使用許諾証明書」を提供することで，ソフトウェアの使用権を大学が卒業生に譲渡することができ，学生は卒業後もOfficeを利用可能であった．しかしながら，マイクロソフトの方針変更に合わせて，学生に提供するOfficeが後述するようにOffice365のOffice ProPlusになってからは大学を卒業し認証が失効すると同時に利用できない契約になった．

2.4　Adobe のCLP

芸術工学部ではAdobeのソフトウェアを使う利用者（教員，学生）が多い．多くの学生は自分達でAdobe CS（Creative Suite）などを購入する．AdobeにはCLP （Contractual License Program） があり，購入したソフトウェアの合計ポイントによって，レベル1（6,000ポイント以上で学割価格から約10%引き），2（20,000ポイント以上で同約20%引き），3（50,000ポイント以上で同約30%引き）と割安になる仕組みである．

大橋キャンパスで，筆者が中心になって注文を28,000ポイント分まとめ，九州大学としてレベル2の一括契約を行った．この注文の取りまとめを2008年7月から始めて，約3カ月かかったが，10月にはAdobeとCLP契約を結ぶことができた．その結果，校費や個人でAdobe製品を学割価格よりもさらに約20%安く購入できるようになった．

その後，全学に通知して，CLP契約を全学展開したところ，瞬く間に10万ポイントを超えて，レベル3になった．その後は安定して50万ポイントを超えていたが，個人対象のCLP契約が2014年4月26日でなくなったので，大学の予算でソフトウェアをCLP価格で購入することはできるが，学生個人がAdobeのソフトウェアを安く購入する手段が無くなった．最近ではクラウド上のソフトウェアをサブスクリプションとして利用する契約形態に移行しており，学生の経済的な負担を軽減することが難しくなりつつある．教育用に必要なソフトウェアを学生の負担にならないように入手できる仕組みが望まれる．

2.5　費用対効果

大学として包括契約を行ったソフトウェア（マイクロソフト，セキュリティ対策ソフトウェア，Adobe CLP）の経費節減効果の累積が2020年3月末現在で，約70億円（マイクロソフト関連が約62億4千万円，セキュリティ対策ソフトウェアが5億8千万円，AdobeのCLPが約1億200万円）となっている．この金額は，インストールしたソフトウェアの数量に学割価格と契約によって安くなった価格の差額を掛けて積算した金額である．

セキュリティ対策ソフトウェアとマイクロソフトのWindowsやOfficeを制約なくインストールできるようにしたことで，CIO-WGが全部局の意見を集約したときに指摘された，ソフトウェアの導入に要する経費負担の問題を解決した．さらに不正利用が起こらない体制を実現することができ，大学として法令遵守を確実に守れるようになった．

3．認証基盤

3.1　認証基盤の必要性

大学ではさまざまな情報サービス（ソフトウェアの配布，メール等）を構成員限定で提供している．情報サービスにアクセスする人が大学の構成員であることを確認（認証）し，さらにそのサービスを利用できる資格があるか否かの判断（認可）を確実に行える必要がある．

2007年度にマイクロソフトの包括契約でソフトウェアを全構成員に提供開始したときに，学生は学生番号を利用できたが，教職員を確実に識別する手段がなかった．そのため大学の全構成員，特に教職員を確実に識別・確認できる仕組みを実現するために認証ID（SSO-KID）を導入し，その後，学生用にもSSO-KIDを導入，確実に認証と認可を行う仕組みを実現した．

認証基盤システムと連携している下位サービスは2019年度末において，学内情報サービスへの全学共通ID による利用者認証機能を提供しているシステムが26システム，その他に学内情報サービスへのデータ提供が31サービス，Shibboleth 認証の主な利用サービスが39と多い．これらは日々の生活や業務に直結する重要な情報サービスである．

3.2　職員用SSO-KIDの導入

大学の構成員を確実に識別・認証するために，2007年10月からSSO-KID（Single Sign On Kyushu uni-versity IDentification）の運用を開始した．これは全職員を対象に10桁の乱数を認証用のIDとして利用するもので，原則として1人に1個を割り当て，再利用しない．1回特定の個人に割り当てた番号は，たとえば退職後に再雇用された場合などには復活して再割り当てることも含めて，可能な限り継続して使用する．

通常はメールアドレスなどを認証用のIDとする場合が多いが，メールアドレスは広く公開される情報であるため，認証用のIDがメールアドレスであることが分かるだけで攻撃が容易になり，セキュリティレベルが下がる．本学では認証用のIDそのものを公開しないことでセキュリティレベルを上げる．

その後，さらに2010年7月からマトリックス認証（身分証明書のカード裏側に書かれている縦横の表から指定されたマス目の文字列を入力する方式）を開始し，セキュリティレベルを改善した．これで，たとえば，それまでは特にセキュリティが要求されるために外部からのアクセスが規制されていた学務システムの機能の一部（成績入力）や電子職員録を学外からも利用できるようになった．また，2010年4月からShibbolethも運用を開始し，図書館の電子ジャーナルなどで利用されている．

3.3　学生用SSO-KIDの導入

学生の認証用のIDは，当初は学生番号を利用していた．しかしながら学生番号は公開情報であり，セキュリティ的には問題がある．またPC必携化（BYOD）のためのPC講習会において，参加者を把握するために，個人を識別する必要があるが，学生番号が記載されている学生証は入学式後に配布されるため，入学式前のPC講習会では使えない．そのため2013年度のPC講習会において，名前，所属学科を聞いて識別したが，1部屋（約50名）で30分ぐらいの時間がかかった．

学生番号の発行は当時の学務部の方針で，すべての入学予定者の手続きが完了する3月31日の17時以降になり，PC講習会で学生番号を利用できる望みはなかった．そこで2013年5月に，情報統括本部が独自に発行できる学生用SSO-KIDを採用することとし，1年生から学年進行で適用することとした．学生用SSO-KIDを採用したことで，認証IDの発行時期の自由度が増え，3月中旬ぐらいにアカウントの有効化を行えるようになった．

3.4　パスワードの再設定

利用者からは頻繁にパスワードを忘れたという問合せがある．当初は窓口まで来てもらって係員が対応しないと再設定できなかったが，利用者が出張中や海外留学中にパスワードが必要になる場合も多々あり，本人が窓口まで来なくてもパスワードの再設定を行える仕組みが必要であった．そこで2009年3月に新しい教育情報システムを導入する機会に合わせて，パスワードの再設定については，事前に登録してある秘密の質問や別途と記録してあるメールアドレスに必要な情報を送信するなどして，窓口まで来なくてもパスワードの再設定を行えるようにした．その後，さらにセキュリティを担保するために，メールで認証コードを受け取る方式に統一された．

4．基本メール

4.1　基本メールサービスの導入

情報統括本部が設置されてまもなく，インフルエンザ（H1N1）によるパンデミック発生時に全職員と学生に迅速・確実に情報を伝達できない問題が指摘された．歴史的な経緯で，大型計算機センターが提供していたごく一部利用者向けのmboxというメールサービス以外には教職員用のメールサービスは大学としては提供できていなかった．mboxサービスは数年だけということで始まったが，結局は基本メールが利用できるようになった後の2010年3月まで細々と16年間も運用された[5]．一方,学生には教育情報システムのサービスの一部としてメール機能が提供されていたが，現実にはほとんど使われていなかった．

そうした状況の中で，全職員と学生に適切な情報を迅速・確実に提供できることが必須であるという経営判断から，大学の全職員と学生に基本メールサービスを提供することになった．職員用の基本メールサービスは2009年2月から詳細な検討を開始し，ほぼ4カ月の設計・調達・設定作業を経て，メール用の専用機を使って，2009年7月1日にサービスを開始した[6]．

当初は，POP3とWebメールが基本で，メールの保存容量は，システムのディスク容量の都合で，1アカウントあたり100MBを上限とし，メッセージは60日で消去される運用で始めた．その後，ディスクに余裕があることが分かったので，2009年12月に300MBまで増やした．

一部利用者の要望に応じて，容量と保存期限の制約を軽減するために，月額1,000円で，保存容量を10GBでメッセージを消さないという有償サービスを2011年2月から開始した[7]．このサービスの利用者は40名少々であった．2014年3月に更新した新システムでは，1人あたり1GBで，保存期間の制限無しにできた．メール関連の主な変遷を表3に示す．

一方，学生は教育情報システムの付加サービス的な位置づけで，全学生にメールのサービスを提供していた．しかしながらディスク容量の制限で，保存容量が30MBと少なく，使い勝手も悪かった．2011年4月から全学基本メール事業室が教職員・学生用のメールサーバを導入し，300MBで保存期限の制約なしで基本メールサービスを提供した．

2011年4月にメールサーバを新システム（CentOS+Postfix+Dovecot）に更新したときに，旧サーバに溜まっているメールを新サーバに移すことができなかったため，新旧のサーバを並行運用し，60日経過すると旧サーバ上のメッセージがすべて消えるのを待つ方針で対応した．

その後，2018年度にメールサーバの更新時期になり，検討を行ったが，これまでのようにオンプレミスのサーバを導入するだけの予算を手当できないことが明らかになり，別途導入していたOffice 365のExchange Onlineを利用することとした．ただ，本学で必要とする機能でExchange Onlineの標準機能では実現できない機能があり，対応に苦慮した．最終的には次に示すような必要な機能を備えたシステムを外付けで開発し，対応した[8],[9]．

• 1）　利用者へのアカウント作成・変更・削除等に関するメール通知機能
• 2）　利用者による別名アドレス設定機能
• 3）　全利用者に対する通知メール一斉送信機能
• 4）　メール送信アドレスの変更機能

こうした独自機能によるサービスを提供していると，既存のサービスで代替することは容易でないことを実感した．メールは枯れたサービスだと言われるが，ユーザインタフェースやセキュリティ関連は必ずしも十分ではないように思う．

4.2　氏名ベースのアドレス

メールアドレスは学生番号や任意の英数字の塊であることが多い．しかしながら個人の尊厳などを考えると，姓名ベースのアドレスも提供する方がよいと判断し，2012年4月から別名で姓名ベースのアドレスを提供するようにした[10],[11]．

職員用基本メールは当初からkyudai.taro.123 のような姓名ベースのアドレスを採用していたが，学生は学生番号をそのままメールアドレスに使うようになっていた．姓名の順番やイニシャルの組み合わせで，いくつかのパターンからメールアドレスを選択でき，このアドレスは学部から大学院に進学しても継続して使える（学生番号は変わる）こともあって，サービス開始後間も無く3,000名弱の学生が利用していた．

2014年3月に職員と学生のメールサービスを統合してシステムを更新したときに，職員にも基本のメールアドレスとは別に姓名ベースでパターンから選択できる同様のサービスを提供するようにした．こちらも少しずつ利用者が増えている．外国人などで，姓名をそのまま機械的に繋げるときわめて長いアドレスになって使いにくい場合に，姓や名を1文字にして省略するパターンを選択すると，短いアドレスに設定できることが評価されている．またミドルネームを含めてもよい場合と含めてはいけない場合など，文化の違いに配慮する必要があり，名前の取り扱いは奥が深い．

4.3　安否確認（一斉送信）

全職員と学生に確実にメールを配送できる仕組みを整備したことから，パンデミックなどの際の情報提供システムとしての有効性を検証することになった．そのために全職員と学生の基本メール宛にメッセージを一斉送信し，メッセージを見た人に確認してもらうための一斉送信システム（安否確認システム）を構築した．この一斉送信システムは強毒のインフルエンザ等に感染したときの対応を強く意識していたので，感染時の症状などを確認するためのアンケート機能を付加していた．

実際に震災やパンデミックが発生したときを想定して，最初は2009年9月1日の防災の日に訓練を行った．その後，年に少なくとも１回は基本メールを使った受信確認訓練を行っている．訓練の結果，最初は必ずしも確認率は高くなかったが，最終的には，正規職員の確認は8割以上，学生の応答は半分弱になった．メールを見てはいるが確認してくれない例がかなりあるようである．この当時の一斉送信システムはパンデミック対応のアンケート機能を使うよりも，全構成員にメールで通知を一斉送信できる点が評価され，日常的な事務連絡等に利用されるようになった[5]．

その後，一斉送信システムの開発にかかわり，その後も保守を行っていた筆者が完全退職の見込みであること，安定して運用するためには人に依存しない体制が必要であることから，大学の方針で（株）アバンセシステムが提供するANPICという安否確認システムに切り替えられた．ただしその後もこの一斉送信システムは使いやすいこともあって，外部業者に依頼して，アンケート機能を除いて全面再構築し，保守契約を結んだ上で，従来とおり通常の事務的な一斉送信のために安定して運用・利用されている．

4.4　ファイル共有システム

（1）添付ファイルの問題

基本メールサービスを開始した当初はメッセージを保存するサーバのディスク容量が少ないことから，保存容量を100MB，保存期間を60日に制限していた．この状況でたとえば，1MBのファイルを1,000名の基本メールに送信すると，メールサーバ上では総計1GBになり，ディスク領域を圧迫する．そのため，基本メールの送受信において，できるだけ添付ファイルを止めてほしいと考えていた．

（2）ファイル共有システム

この問題に対応するために，大橋キャンパスの情報基盤室（旧情報処理センター）が実運用で有効性を確認していた（株）ノースグリッドが提供するProselfというファイル共有システム（Shareと呼ぶ）を大学全体用に新たに導入し，2010年5月からサービスを開始した[12],[13]．当初は1GBで2週間保存可能という設定にしたが，2週間では短すぎるという意見と，当初の推定以上にディスクに余裕があることから，2011年1月から4週間に，さらに2011年9月から90日に保存期間を拡大した．

Shareの運用開始後，ファイルが消えずに残ってほしい，学科や研究室で継続してファイルを共有したいという要望が強かったので，もう1台Proselfのサーバ（Archiveと呼ぶ）を導入し，教職員専用に2014年5月から運用を開始した．こちらは10GBで，保存期限の制約なしである．

（3）機密情報の取り扱い

個人のPCに成績情報や機密レベルの高い情報を保存したまま学外に持ち出し盗難に遭う，機密情報をUSBに保存して学外に持ち出し，USBの紛失や盗難に遭遇するという事態が発生し，機密情報の取り扱いが問題になった．Archiveで提供しているProself Diskという機能を使うと，必要なときだけ手元のPCで仮想ドライブのようにファイルを利用でき，使用終了後にキャッシュなどの形でPCにファイルに関連した情報が残存しない．機密情報をProselfに保存し，Proself Diskの機能を使って，機密情報を学外に持ち出さすに，必要なときには利用することができるようにした．その結果，利便性の改善とキュリティの改善を実現できた．

5．教育情報システム

5.1　端末数の変遷

本学における教育用の端末の種類と台数の変遷を表4に示す．当初はホスト計算機に専用端末だったものが，ホスト計算機とPCになり，最後はホスト計算機なしでPCのみとなった．さらにPC必携化で，一部を除いて，これらのPCもなくなった．なお，表4で端末数が太字になっているものは筆者が機種更新にかかわったものである．2017年度の機種更新でクラウドを活用し，VDI（Virtual Desktop Infrastructure）でWindows 10を提供するようにした．2019年度時点でのシステム構成を図2に示す．

ホスト計算機については，正確に言うと端末としてのPCからログインして使うホスト計算機としてはなくなっているという意味で，プログラミングやWeb学習用にはホスト計算機と呼ばれるものが存在している．実体はAWSのインスタンス（x1.32xlarge）である．ただし一部の授業でしか利用されていない．このホスト計算機は2020年度末のシステム更新でクラウドを活用したWebベースのプログラミング環境に切り替わり，完全になくなる．

5.2　WindowsからMacへ

教育情報システムとして，2005年度には，情報処理教育センターの流れを汲む情報統轄本部の教育支援事業室と芸工大情報処理センターのレンタル料を統合し，598台のWindows PCを中心に整備した．これらのPCは10部屋のパソコン部屋で提供していたが，台数はまったく不十分であった．そこで，次の機種更新に際して，可能な限りPCの台数を増やすことを目的に，管理システムの撤廃・低廉化，プリンタの廃止を行った[14],[15]．新しいシステムは2009年3月から稼働し，1,087台（買い取り121台を含む）のiMacを中心としたシステムになった．

教育情報システムとして長い間Windows PCを提供していた．Windows PCは量販店などではMacに比べて比較的に安い価格で販売されている．しかしながら，学生の利用後に初期状態に復元できる環境復元の仕組みが必要で，これが意外に高価になり，PC自体が安価でも，システム全体としては価格を押し上げる要因になる．

Mac は OS X になってからベースがUNIXになり，共同利用の仕組みや環境復元という問題に対応するために十分な技術の蓄積があったこと，管理システムが安価ですむこと，PC自体の使い勝手がよいことから，機種をWindowsからMacに変更した．このときに，次の更新ではPCを廃止することも視野にいれて，この決断を行った．

5.3　プリンタの廃止

教育情報システムの利用者には枚数制限はあるが，無料の印刷サービスを提供していた．その結果，先生が100ページを超える授業の資料を学生にファイルで渡して無料プリンタで印刷させる，Webページなどを大量に印刷しても取りに来ず出力が毎日山積みされる，学生がメモ用紙を入手するために白紙を印刷するとかいったような，管理する側から見ると困った使い方が発生し，プリンタの紙やトナー代が年間で500万円近くになるなど，予算を圧迫していた．

PC台数を可能な限り増やすために，無料印刷サービスを廃止することにしたが，学生のグループや部局長から「無料印刷サービスの廃止」を中止するように要請があるなど，学内関係者から強い抵抗があった．その都度，状況や目的を説明して，納得してもらった．ある先生がパソコン部屋に自分のプリンタを持ち込んで学生に提供しようとする例もあったが，実際にはプリンタはまったく利用されず，1回限りの試みで終わった．授業では，基本的には教材の提供，課題の提出等はWeb学習システムを利用してもらえばよい．プリンタの廃止は多くの大学で強い要望となっているようであるが，本学に続いて完全廃止できた大学はいまだにないようである．

芸術工学部では，ポスターのデザインなどの授業があり，印刷・展示して相互に評価する必要性もあることから，大学の生協に依頼して有料プリンタ（A3のカラー対応）を格安の印刷費で提供してもらうなどの対応を行った．ほかのキャンパスにおいても部局の努力で生協の有料プリンタが設置され，学生達はこちらを使うようになった．印刷枚数は，正確な数を把握できていないが，大橋キャンパスで見ると，ほぼ1桁減った．コスト意識の育成も大切だと考えている．なお，研究室には教員が研究費で購入したプリンタがあって，卒研生や大学院生はそちらを使っている．

6．PC必携化（BYOD）

6.1　必要性と問題点

本学は2013年度からPC必携化（BYOD : Bring Your Own Device）を開始し，6年制の医歯薬系の学部を含めて，学年進行で2018年度に完了した．現在はすべての学部学生が個人PCを活用して授業や学習をこなしている．BYODは本来行うべき教育があって，それに対応するために必要な情報環境を整備するのが本筋である．個人にPCやタブレットの必携化を先に決定し，それに合わせて教育内容を対応づけるというのは本末転倒である．ましてPC購入の掛け声だけで，入学すると実はPCを使う授業がないという事態は決して望ましくない．

しかしながら多くの大学では情報システムの経費節減や省力化のためにBYODの推進を検討しているようである．本学の実施例を参考にしたいと国公私立大学から多くの来訪があった．また多くの講演も依頼された．しかしながらほぼすべての来訪者が情報関係者だけであり，中には納入企業の技術者や営業担当者だけが訪問されたこともあって，BYODに対する認識の違いに愕然とした．

6.2　移行の背景

2005年当時，学生が利用できるPCは次のような状況であった．

• PCの台数が学生数に比べて圧倒的に不足している．
• そのため混んでいるパソコン部屋は時間割ベースで8割近くが授業で占有されており，時間がある学生がPCを使って学習しようとしてもほとんど空いている状態がない．

そのため第5節でも述べたように，レンタル料の統合に加えて，PCをWindowsからMacに変更，プリンタの廃止などを行って学生が利用できるPC台数を増やしたが，状況は改善されなかった．

当時の全学教育によるアンケート調査では，1年生のほぼ95%が自分のPCを購入していることもあって，次のシステム更新に際しては，パソコン部屋を廃止し，学生が自分で購入して持参するPCを使って何時でも，何処でも，自由に，自分のペースで学習できる体制（BYOD）に移行する必要があると判断した．

6.3　移行期間

2013年度からPC必携化を開始した．当初の予定では教育情報システムの更新は2013年3月であったが，次のような事情で1年延期した．

• 2014年度開始で全面見直しを行っている基幹教育の教育課程の開始時期に同期してほしい．
• 2013年度の1年生の情報処理関係の授業を個人PCで行うことは問題ないが，PCでCALL （Computer Assisted Language Learning）システムを使って行う語学の授業では不安なので，初年度はこれまでどおりレンタルのPCを使い，その間に個人PCでの実施の可能性を検証したい．

2014年度からは基幹教育用のパソコン部屋を全廃し，基幹教育の授業はすべて個人PCを使って実施することになった．一方，専門教育用のパソコン部屋は学年進行で4年生まで個人PCを持っている状態になった時点（2017年3月）で教育情報システムのパソコン部屋を全廃（医学図書館分，大橋分を除く）した．

6.4　別途維持するパソコン部屋

（1）医学図書館パソコン部屋

2017年度からはパソコン部屋は全廃する予定であったが，6年制の医学系学部のきわめて強い要望があって，2017年4月から1年間は，それまで設置していた60台のiMacを買い取って（経費は情報統括本部と部局で半分ずつ負担）現状維持とした（2018年3月まで）．そのため認証システムやファイルサーバをさらに1年間維持するために予定外の出費が発生した．

（2）大橋キャンパス

大橋キャンパスでは，教育に必要なソフトウェアを個人PCで使える契約を行えなかったので，レンタル済みのiMac50台を買い取ってパソコン部屋を継続していた．結局，必要なソフトウェアを個人PCで使える契約の見通しが立たないことから，元々持っているレンタル料を使って2020年度から大橋キャンパスではパソコン部屋をレンタル契約で公式に維持する体制に変更した．

6.5　無線LAN

PC必携化を実現する際に，学生が自分で購入したPCを大学に持参して，何時でも，何処でも，自由に，自分のペースで学習できる環境を実現するためには，学生が個人PCをネットワークに自由に接続できる環境が必要である．そこで，教育用無線LAN（EDUNET）を整備した．整備状況を表5に示す．約7割の講義室に教育用無線LANを整備できた．

2012年度に行った予算要求で，無線LANだけの予算要求では難しいということで，PC必携化，2011年4月に設置された教材開発センター[16]の設置と電子教材の開発・支援・普及などとセットにして申請し，予算獲得できた．

EDUNETは，IEEE 802.11nで5GHz帯を中心に使うことで，300人部屋で，1人あたり300Kbpsでビデオ教材等を視聴しても，円滑に授業を行えることを目標とした．2013年3月下旬から運用を開始し，一般公開直前に実測したところ，PC単体での通信速度に130Mbpsを確保できた．その後，40名程度の授業で，学生のPCでWindows Updateが一斉に走っても支障がないこと，300名の学生がCALLシステムを使って授業を行っても支障がないことを確認できた．

こうしたPC必携化などでネットワークを整備する際には，教材の内容（大きさ）や利用方法まで考慮して設計しないと円滑に教育を行えない．ネットワークの適切な設計と整備は重要である．

6.6　ファイヤーウオール

（1）必要性

本学では，当初は大学全体を守るファイアウォールに相当するものはなく，IDS（Intrusion Detection System）を活用するなどしてセキュリティを維持してきた．セキュリティホールがあるPCなどが外部から直接アクセスできると，PCが攻撃され，侵入され，悪用される可能性が高い．また著作権侵害を引き起こすファイル交換ソフトウェアの利用も大学としては禁止しているが，なかなか守られない．

こうした問題に確実に対応するためには大学と外部との接続点にファイアウォールを設置し，不適切な通信を規制すると効果的である．そのために2011年3月にセキュリティポリシーにおける対外接続の基本方針を「本学では，外部情報ネットワークとの接続点にファイアウォール等の管理装置を設置し情報セキュリティの保持を行う対外接続を原則とする」に改訂した．

（2）導入と運用

利用者に不便な思いをさせず，効果的に通信規制をするには，IPアドレスやポート番号で規制する従来型でなく，ヘッダーを解析して通信規制を行う次世代ファイアウォールの導入が効果的である．2012年3月に導入したPaloalto 5050は，たとえばP2Pのトラフィックでも，ファイル交換は規制するが，Skypeは通すことができる．

ファイアウォールの導入当初は，実際の通信状況を把握するために，1年間にわたり通信のモニタだけを行った．その結果に基づいて，できるだけ利用者に不便をかけない設定にして，PC必携化が始まる2013年3月から本運用を開始し，ファイル交換ソフトウェアの通信が遮断されていることを確認した．さらに，広く危険と見なされているURLへのアクセスも規制した．

（3）サイバー攻撃への対処

ファイアウォールを導入してまもなく，サイバー攻撃が活発になり，本学においてもさまざまな攻撃を受けるようになった．たとえば，複合機（スキャナ，コピー，FAX，プリンタ機能などを統合したもの）が外部からのアクセスによって情報漏洩を引き起こす事態が発生したため，2013年12月18日からHTTP／HTTPSの通信規制を開始した．ほかにもBaidu IMEやShimeziなどの日本語入力関連の問題が発生し，その度に速やかに規制を行った[17]．

さらに外部からのサイバー攻撃が激化すると予想されるお盆などの時期に通信規制を行うこととし，2013年8月から，期間限定で通信規制を実施した．

その後，通信規制を解除しないという方法で，2015年8月26日から永続的に通信規制を開始した．基本的に外部発の通信は制限する，内部からもC&Cセンターへのアクセスなど不都合なアクセスを規制している．外部に情報を提供する約1000のWebサイト等については外部からの通信を受けられるように個別に通信規制を解除している．

6.7　ソフトウェアの提供

すでに「ソフトウェアの包括契約」でも述べたように，大学で行っているソフトウェアの包括契約を活用して，セキュリティ対策ソフトとOffice（Word，Excel，PowerPoint）については無償で提供できる体制になっている．その結果，学生の経済的な負担を軽減できている．

6.8　部局説明会

大学の意思決定・情報伝達の常として，たとえば，最上位の部局長会議で筆者が10分間説明して決定された議題も，最下位の学科会議レベルでの報告では議題の項目が読まれる程度に省略される．そのためPC必携化を実現するために多くの会議で説明し，了解をもらっても，現場の先生達にはほぼ何も伝わらない．この状態を改善するために16部局を対象に個別に説明会を実施し，PC必携化の必要性や可能性について直接先生達に説明し，質問に答えることで，理解を得た．約2カ月で，30分から1時間程度の説明会を16回開催し，約700名の教員に参加してもらった．

どの会場ででも出た質問・意見と回答は次のとおりである．

• WindowsとMacのどちらがよいか？
  学生に何を教えたいかに依存するので，学科の教育に最適なPCをそれぞれ学科で選択してほしい．
• 情報統括本部のサポートは？
  Windows と macOS のどちらもサポートする．
• ネットワークにはどう接続するか？
  IEEE 802.11nの新しい教育用無線LANをほとんどの講義室に整備するので，これを利用してほしい．300人部屋で，動画等の教材（300Kbps）を全員が一斉に見ても大丈夫な設計をしている．
• 電源は？
  講義室の机にコンセントを整備できれば安心であることは分かるが，講義室の机にコンセントを整備すると大学全体で数億円の経費が必要になるので，今回は特段の整備を行わない．最近のPCの電池は長持ちするので，当面は電源コンセントなしで対応してほしい．
• 経済的に苦しい学生はどうするのか？
  PCの価格は十分に低下しており，Windows PCであれば10万円弱で購入できる．もしPCを購入できない学生がいるようなら学科で対応してもらいたい．本学に入学しようとする学生は4年間で入学金，授業料を合わせて250万円以上が必要で，それにPC代金が追加されると考えてほしい．実際にはPCを購入できないという事例は一件も発生しなかった．

6.9　PC講習会

（1）必要性と作業内容

学生にPCを購入して，大学に持参するように指示するだけでは，円滑な学習を期待できない．他大学では，授業のはじめにいろいろと混乱したという話もある．そこで，PC講習会を実施し，授業に支障が出ないようにしている．

PC講習会では，主に以下のような作業を行い，最初の授業から支障が出ないようにしている．

• アカウント（SSO-KID）の有効化を行う
• セキュリティ対策ソフトウェアをインストールする
• Officeをインストールする
• Mac指定の学科では，Mac にセキュリティ対策ソフトウェアとOffice をインストールし，さらにWindows をインストールし，同様のソフトウェアをインストールする

2013年度に行った最初のPC講習会において，Windows 8やMac OS Xに対応するために準備したドキュメントは合計で440ページになった．その後も増える傾向にある．このドキュメントと必要なソフトウェアのファイルを一緒にUSB（書き込み禁止機能付き）に入れて，USBを貸し出した．必要なファイルをコピーする等，最初の必要最小限の説明書については印刷して配布した．

（2）運用の工夫

事前に学部の全入学生に連絡して，入学式の前（2013年度は4月2〜5日）に学科ごとに指定されたPC講習会に参加するように指示している．

学生は入学式前に学生番号を知る手段がないために，学生番号で識別できない．そのために，最初のとき（2013年度）には50名弱のクラスで参加者の確認に30分程度かかった．翌年（2014年）のPC 講習会では，合格通知に記載されているSSO-KID（図3）をバーコードリーダで読むことで，同様のクラスの受付がほぼ5分で完了できた．

PC講習会では図4に示すようなチェックリストに従って，順番に作業を行い，最後まで作業したら完了というように分かりやすくしてある．

（3）参加状況とCOVID-19対応

2013年度のPC講習会では，2,688名の新入生のうち，欠席は33名であった．その後も欠席する学生は毎年30名程度が続いている．欠席した学生は，所属学科の関係者に連絡して，対応をお願いしている．

2020年度の入学生は，当初は対面のPC講習会を予定していたが，COVID-19の感染拡大防止のために急遽オンライン方式に切り替った．特別な配慮が必要な学生やどうしても参加できない学生のために，また将来は自宅等で全部作業してもらえるように説明資料を準備し，オンラインで公開しており，これまでも約3分の1の学生はPC講習会には参加せずに作業を完了していた．今回，突然ではあったが，準備はできていたため，例年とおり99%の新入生がオンラインベースで作業を完了できた．

7．遠隔講義システム

7.1　必要性

本学は2009年10月の六本松キャンパスの伊都キャンパスへの移転完了当時，11の学部と18の学府からなる総合大学であった．その後の2018年9月の移転完了まで，5つの主要キャンパスに分散して教育が行われた．本学では，学問分野をできるだけ幅広く学べるように総合選択履修科目や大学院共通科目という枠組みが設定されている．しかしながらキャンパス間の移動などを考えると，他キャンパスの授業の聴講は容易ではなかった．

こうした状況を踏まえ，2007年7月に「遠隔講義・会議システム整備プロジェクト」が発足し，筆者がリーダとして，遠隔会議・講義システムiClass （ICLASS：Inter Campus Learning Assistant System）の整備を行い，2009年10月から運用を開始した[18],[19],[20]．

7.2　 iClass

この遠隔講義システム（iClass）はユーザインタフェースをタッチパネル方式（図5）で直感的に使えるように工夫しており，主要5キャンパスを8部屋でカバーし，キャンパス間の授業を行える．しかしながら，同時接続が3カ所までで，それを超える授業の場合にはMCUを利用する必要があり，通常の遠隔会議システムの集合体とあまり変わらない使い方になった．大学院共通科目には海外も含めて10カ所程度を同時接続する授業があることから，不満となっていた．また，当時は価格の都合で標準画質（SD）にせざるを得なかった点も不満であった．

このときに導入したiClassは他にも次のような特徴を有するシステムで，当時としては先進的なものであった．

• 遠隔の装置の電源投入・切断が可能
• 遠隔からカメラ，スクリーンに投影される映像の切り替え等の操作が可能
• 豊富な映像の提供
  

  教室の前（学生を撮影）と後ろ（教師とスクリーンを撮影）のカメラ，PCや書画カメラ，DVDなどの映像ソースを接続先に送信することが可能

7.3　qClass

2014年4月に新しい遠隔講義システム（qClassと命名）に更新したが，その際に次のような配慮をした．

• 多数の講義室を接続する大学院共通科目等を考慮し，講義室系の設置場所を増やす．
• 合わせて同時接続個所を，MCUを中心にして，従来の3カ所から最大45カ所まで拡張する．
• 箱崎キャンパスの本部機能移転に合わせて，会議の中心が箱崎から伊都に移ることを考慮し，会議室系を新規に追加整備する．
• 画質を標準画質（SD）から高画質（HD）に改善する．

MCUを中心に据えた構成にしたために，遠隔の講義室等の電源を手元（教員側）から制御できなくなり，遠隔地に人手（TA）が必要にはなったが，システムとしての経費は半分以下に，設置場所は，大講義室3式，小講義室12式の計15式，会議室7式，総計22式と約3倍に増やせた．

新システムでは，教卓型の収納ケースの中に設置している遠隔会議システムの本体装置が熱に弱く，教卓型の収納ケースの中に籠る熱のために，当初トラブルが頻発した．最終的には，当該装置だけ教卓型の収納ケースに外付けすることで改善したが，原因の追及と対応には時間がかかった．

新旧の遠隔講義・会議システムは通常の授業以外にも，総長の年頭の挨拶，科研説明会の中継，その他全学的な規模のイベントの中継などにも利用された．

7.4　設備の移設と運用終了

箱崎キャンパスの移転進行に伴って，不要になる設備が出ることから，2018年9月末で箱崎の設備3式を先行撤去・移設した．また伊都キャンパスへの移転が完了した時点で「もう必要ない」との経営判断で，予算配分がなくなったので，2019年3月までの運用となり，情報統括本部が運用する遠隔講義・会議システムの設置・運用は終了した．

現実には，大学院共通科目，学部専門科目，高年次教養科目などの受講生が複数のキャンパスにまたがる授業があり，qClassが完全になくなると教育に支障が出ることから，それまでリースで導入していた機器を安価に買い取り，各キャンパスで最低限の機能を維持できる体制にはした．

8．Web学習システム

8.1　必要性

Web学習システムを利用することで，教材の提供，課題の提出・採点，出席管理など，より効率的な学習支援が可能になる．また最近では保存された学習履歴を分析することで，教育・学習方法を改善できるようになった．本学ではいくつかのWeb学習システムを切り替えながら利用を拡大し，教育改革につなげている．

8.2　Web学習システムの変遷

本学では，2002年度から一部の教員有志がWebCT（後にBB9：Blackboard Learn R9.1 に名称変更）を使った授業を行っていた．WebCTの利用が拡大し，機能拡張が進む中，当初は問題にならなかった運用経費が，2007年度には約900万円に近づくなど，予算的にこのBB9の維持が困難になった．そのため，当時普及し始めていたオープンソースベースのMoodleとMaharaへの切り替えを計画した．

Web学習システムをBB9からMoodleに切り替えるにあたっては，コンテンツの移行が問題になった．ツールを使うなどして自動的に全面移行ができればよかったが，当時はそれが困難であった．また自動的に全部移行するとすでに不要なコンテンツまで移行し，ディスク容量を圧迫することから，利用者が自分で必要なコンテンツだけを移行してもらう方針にした．動画のコンテンツの移行は手間がかかり利用者に迷惑をかけることになった．コンテンツの移行や新システムの習熟には時間がかかることから，2016年度末までの1年半にわたってBB9とMoodleを並行運用し，時間をかけて順次移行してもらった．

MoodleとMaharaに加えて，デジタル教材配信システムとしてのBookLooperも提供した．BookLooperはNICTのプロジェクト予算をもらって京セラコミュニケーションシステム（株）と共同開発したシステムで，PDFにした教科書を登録することで，学生が見ているページの順番，ページに書き込むメモやマーカーなどを記録できるシステムである．ただ，当時は授業が始まる前に1学期分の教材を事前に登録しないといけない，その登録も自分ではできないといった使い勝手の問題があった．

その後，独自開発のBookRollに切り替え，使い勝手はかなり改善された．さらにソフトウェア自体の著作権に配慮して，本学ではオープンソースベースのBookQと名付けたシステムを現在では使用している．Moodle，Mahara，BookQを合わせてM2Bシステムと呼んでいる．

8.3　情報統括本部の関与

基幹教育院の有志が運用を始めたMoodle，Mahara，BookLooperの運用であるが，最初は有志の授業で，その後で基幹教育の情報系の授業で利用するようになり，さらに基幹教育の授業全体で，最終的に大学全体で使用する方向になっていた．こうしたシステムを研究室や部局レベルで運用することには無理がある．情報統括本部では，WebCT（BB9）の維持経費のこともあって，それまで全学で利用してもらっていたWeb学習システム（BB9）を2015（平成27）年10月から「Moodle，Mahara」に切り替え，大学全体での運用に備えて，引き取ることにした．

8.4　クラウドの採用

情報統括本部がM2Bシステムの運用を引き取ったときはオンプレミスのサーバで運用していたが，負荷の増大への対応などを考慮して, 2017年6月1日からサーバをクラウドに移行した．初めてのクラウド利用であり，後述するように，機密保持などの対応をどうするかなど，検討すべきことが多く，本来は4月からの運用が望ましかったが，仕様書の作成や事務手続き等に時間がかかり，2カ月遅れた．

8.5　Moodle運用上の問題

M2Bシステムをオンプレミスからクラウドに移した結果，想定外のトラブルに遭遇した．当初はマルチサーバにして，負荷に応じて性能を動的に変更し，十分な性能を維持しつつも運用経費を節約しようと考えていた．しかしながら負荷に応じてロードバランサーでサーバを切り替えると，次のような状況で，セッションが切断され，問題になった[21]．

• 接続しているサーバ上で一時的な作業ファイルが保存される．そのためロードバランサーが別のサーバに切り替えると，元のサーバの一時的な作業ファイルを参照できないため，必要な情報が入手できず，処理を失敗する．
• 複数のサーバで一時的な作業ファイルを共用できるように一時的な作業ファイルをネットワーク上の共有ファイルにすると，アクセス性能が低下し，Moodleの性能が低下する．
• 性能を上げるために各サーバがキャッシュを使うと，別のサーバとはキャッシュが同期されないため，キャッシュを無効にする必要があり，その結果，やはり性能が低下する．

セッションを確実に維持できるように一度接続したサーバに再接続するようにロードバランサーを設定すると，結果的に負荷分散にならず，期待した性能を発揮できない．

また負荷が下がったからとアクティイブなセッションが残っているサーバを停止すると，それらのセッションを継続できない．つまり負荷に応じてインスタンスを増やすことは問題ないが，インスタンスを停止するためにはタイミングが問題になり，インスタンスを減らすことは難しい．

このように性能の低いサーバを複数台稼働して負荷の増減に追随する試みは，セッションの維持と性能の両立が困難で，期待する性能を得られないことから，まとめて1台の高性能なインスタンスに切り替えて運用する方法に切り替えた．こうしたシステム構成の変更はクラウドならではある．

8.6　COVID-19

2020年春からの新型コロナウィルス（COVID-19）の拡大に伴って，大学全体の授業がオンラインベースに移行し，ほとんどの授業でM2Bシステム，特にMoodleが使われるようになった．当然，負荷が増え，リソースの増強が必要になったが，クラウドに移行していたために，メモリやディスクの増強を手際良く行うことができた．

9．教育データとLA

9.1　背景とこれまでの経緯

ICTの進化・発展に伴って，ICTと教育の融合が進み，大学における教え方や学び方が変わろうとしている．電子教材の普及やオンラインの学習支援システムの利用が進むにつれて，学習履歴のデータが蓄積され，学習履歴の分析（LA：Learning Analytics）が可能になる．適切な学習分析を行うことによって，教員の教え方や学生の学び方の改善が可能である．大局的に見ると大学全体，あるいは広く世界を視野に入れた教育改革が可能である．

本学では2013年度からPC必携化（BYOD）を開始したことから，M2Bシステムの利用が進み，最近では日々20万件程度の学習履歴データが蓄積され，全学規模で学習履歴等の教育データを利活用できる環境としては世界トップレベルを維持している．この蓄積される教育データを解析することで，授業の改善や学び方の改善を行えることから，本学ではLAC（Learning Analytics Center）を設置して教育データの解析に基づく教育改善に積極的に取り組んでいる[22],[23]．これに関連する本学の大きな出来事の経緯を表6に示す．

9.2　教育データ活用の方針

学習履歴等の教育データは個人の情報を含んでいることから，誰でも自由に利用してよいものではない．2019年度に本学関係者で教育データの取り扱いを検討し，次のような方針になっている^☆1．

（1）運用システムと研究システムを区別

これまでは運用システムとしてのM2Bシステムの学習履歴データを，プライバシーには配慮しながらも，そのまま研究にも使用しており，運用と研究が明確に分離していなかった．今回の議論で，運用と研究を明確に分離し，運用システムで得られた教育データについては明確な手順や体制ができるまでは外部組織や研究者には提供しないこととした．

（2）データ利用の同意の取り方

2019年度現在では，M2Bシステムの学習履歴などの教育データを利用する同意書については，特定の研究で利用することを想定しており，一般的なデータ利用の同意書になっていない．一般的な枠組みに対応した同意書・プライバシーポリシー・利用規約を決め，同意書の文面を改訂する必要がある．

その場合の同意書は，利用者や利用範囲，目的に対応して，学生が選択できることが望ましい．M2Bシステムにおいて提示するデータ利用の同意書については，最終的には法務，知財，弁護士と相談して作成する必要があろう．

（3）利用目的とデータの種類に応じたデータ扱い

教育データについては，M2Bシステムだけでなく，健康データ，学務部保有のデータなど，さまざまな部署のさまざまなシステムに各種のデータを蓄積されている．すでに収集・蓄積されているデータだけでなく，たとえば学生の指導を行うにしても何をどこまで対応したいのかを議論し，今後収集・蓄積すべきデータの取り扱いを検討する必要がある．

M2Bシステムで収集されている教育データに限定しても，学生が自分の学習改善に利用，教員が担当授業の改善に利用する場合，事務組織による教育改善のための学内利用においては，特に利用に制約はないと考えられる．しかしながらオープンデータのような形で外部の組織や研究者への提供については，同意書の整備に加えて，生データではなく，仮名化や匿名化しプライバシーを守れる提供の仕方を実現するなど，明確な基準や提供体制の構築が必要であろう．

10．クラウド

10.1　利点と必要性

当初，クラウドの利用はセキュリティ上の問題を考慮して，使われていなかった．しかしながら次のような利点を考慮して，クラウドを利用しようという機運が盛り上がってきた．

• 次の例のような場合に，負荷変動に合わせて柔軟に資源を増減できる可能性がある
  ✓教育利用では，昼間の利用は多いが，夜間は利用が少ない
  ✓授業期間中は利用が多いが，長期休暇中は利用が減る
  ✓入試の合格発表では，ごく短期間（約1週間）だけ必要で，それ以外は不要である
• システムの性能増強が必要になったときに，資源（CPU，メモリ，記憶装置）の増強が容易にできる
• ソフトウェアとハードウェアの契約を分離して，システム更新の自由度を改善できる
• 電気使用料をキャンパスの契約から外せる
• 設置スペース（免震サーバ室）を占有しない
• オンプレミスのサーバを一括購入する場合に比較して，経費の支払いを平滑化でき，予算を計画的に準備できる（一括購入資金）

10.2　クラウド選定基準

クラウドを利用する場合には，認証データ，学習履歴などの重要データをクラウドに保存する可能性がある．クラウドのセキュリティを議論するときに，学内と同じグローバルIPアドレスを割り付け，実際は遠隔地にあるが，あたかも学内ネットワークの一部のように見せると，納得してもらえる場合が多い．そのためAWSのDirect ConnectやAzureのExpress Routeと呼ばれる接続形態を採用し，SINET経由でNIIとクラウドが直接接続するVPN接続とした．この接続方式は，インターネット経由の一般的な接続よりも信頼性が高く，セキュリティが強固になる．

次にクラウドの選定する上で，次のような配慮を行った．

• 経済合理性があること
• 安心感があること
  ➢市場で受け入れられていること
  ➢法律上の問題
  
  • •データセンターの場所問題
  • •管轄の裁判所
  ➢内容の保護（CIA -機密性：confidentiality，完全性：integrity，可用性：availability）
  ➢基本的にはIasS （Infrastructure as a Service）, PasS （Platform as a Service）として自前で運用

10.3　Webサーバ

クラウドを使用する最初の試みとして，学外に情報提供している1,000台以上のWWWサーバを対象に考えた．それらは次のような特徴を有する．

• 学部，学科，研究室等で独自に運用している．
• 定期的にハードウェアの更新が必要になる．
• 運用担当者（若手職員）の負担を無視できない．
• セキュリティ上の問題（ソフトウェア，コンテンツ）があるサーバが存在する，
• 問題発生時に情報統括本部が直接介入できない．

これらのWebサーバをクラウド上に集約して，経済性，安定性，セキュリティの確保を実現したい．そうした方針に沿って，最初に本学の公式Webサーバをクラウドに移行する試みを行った．外部に公開するWebサイトでは，学内限定で情報のアクセスコントロールを行っているものあるが，基本的には高度な機密情報が含まれていないことから機密保持の問題を軽減できる．

この切り替えのときに「学内限定（学内から本学のIPアドレスからの接続のみ許可）」のデータは，構成員が学外でも構成員限定の情報をアクセスできるようにSSO-KIDで認証し，場所に関係なく，構成員が学内限定情報を参照できるようにした．このサーバは総務課の広報担当が内容の管理・更新を行い，安定して運用できている．

続けて，部局のWebサーバをクラウドに移行することとし，まずは芸術工学関係の19ドメイン分をクラウドに移行した．外部に出すために認証方式の変更が必要であったが，これも問題なく移行できた．その後，他のWebサーバについては情報統括本部が提供しているホスティングサーバ（クラウド上）で受け入れるものが増えている．

10.4　VDIシステム

PC必携化によって，すべての学部学生が個人PCを使って学習するようになった．しかしながら個人PCであるが故に，たとえば同じWindows PCであっても微妙に環境（設定）が異なり，演習などを行うときに問題になる可能性があった．そこでVDI（Virtual Desktop Infrastructure）を利用して，個人PCにおいても完全に同じ環境を提供できるようにした．これにはAWS （Amazon Web Service）のサービスを利用している．システム名をQUEENS（Kyushu University Educational ENvironment Services）と名付けている．図6にMac上でVDIを使ってWindows 10を起動している画面例を示す．

授業でVDIを使用する場合に，どのくらい速やかに起動できるかが重要であると考え，一度に約200台のVDIインスタンスを起動するテストを行った．

• このVDIが収容されているAWSの東京リージョンで2017/8/28 21:23より199台の環境作成テストした結果，最速が11分，最遅が112分であった
• 比較として，ノースバージニアリージョンで2017/9/30 21:01:23より200台の環境作成テストを行った結果，最速が9分，最遅が49分であった

2カ所のリージョンでのテスト結果を図7に示す．性能の違いが歴然としている．ただし，東京リージョンはできて間もなく，当時は十分な資源がまだなかった可能性がある．この結果から，VDIインスタンスを作成して起動するには最速でも約10分間が必要なことである．したがって授業中に「さあWindowsを動かして」とすると，多くの学生は起動が間に合わない．少なくとも授業の前日にWindowsのインスタンスを作成するよう指示することが必要である．

10.5　VDIの利用料金

VDIを利用できるようにする場合に，通常のやり方では決まったライセンス数を購入し，それを，予約システムなどを利用して，一定時間だけ利用する方法が多い．しかしながら，それではライセンス数の上限で制約が発生し，何時でも，何処でも，自由に使う環境を提供できない．ここではすべての学生が必要なときに人数制限なしに利用できる体制を構築する．

AWSのVDI利用には，月額の基本料金（14ドル／月）と時間あたりの利用料金（0.4ドル）がかかる．月額基本料金がそれなりに負担になり，無視できない．そこで基本的には月末に自動的にWindowsのインスタンスを削除するものとし，削除されると困る場合には利用者が「月末に削除しない」という設定を行う仕組みにした．

そうした仕組みを円滑に行うために管理ポータルを作成し，細かな制御を行えるようにした．VDIの管理ポータルの主な機能は次のとおりである．

• ユーザ管理
• Windows管理（個数，延起動時間，月末削除無効，検索・一括処理）
• Linux管理（個数，延起動時間，月末削除無効，検索・一括処理）
• クレジット（予算）申請
• 問合せ処理
• お知らせ
• データ管理（OSごとクレジット額，累計）

学生は1人あたり300ドル（利用者にはクレジットという表現で説明）の使用枠を持ち，その範囲内でWindowsとLinuxを利用できる．Windowを1カ月間稼働し続けると288ドル，Linux（1時間0.032ドル）を1年間稼働すると280ドルである．つまりWindowsは1カ月間，Linuxは1年間，連続して稼働できる料金設定にしてある．

10.6　クラウドのCIA

クラウドを本格的に利用開始するに際に， Confidentiality（機密性），Integrity（完全性），Availability（利用可能性）の3つが問題になった．最初にAWSのクラウドを利用する際に，これらについて厳密な検討を行った．

（1）Confidentiality（機密性）

• Webサービスなどの通常サービスからの情報漏洩
• AWSの管理者アカウントを利用した情報漏洩
• AWS上の仮想マシンイメージ（AMI・スナップショット・EBSボリューム等）の漏洩
• EBSボリュームの暗号鍵の漏洩
• 仮想マシンへの管理者アクセスによる情報漏洩
• 通信回線の盗聴による情報漏洩
• データが国外に持ち出されることによる情報漏洩
• 廃棄されたボリュームによる情報漏洩

（2）Integrity（完全性）

• Webサービスなどからの改ざん
• AWS管理者アカウントからの仮想マシンイメージの不正操作
• 仮想マシンへの管理者アクセスによる改ざん・不正操作

（3）Availability（可用性）

• サービスに対する妨害攻撃
• 保守などによる停止
• 電源喪失によるサービス停止
• ネットワーク断によるサービス停止
• 物理サーバ障害によるサービス停止・データ喪失
• AWS管理者アカウントへの侵入によるサービス妨害
• 仮想マシンへの管理者アクセスによるサービス妨害

検討した結果，最終的にこれらの条件を満足していることが確認でき，M2Bシステムなどをクラウドで運用できることになった．

10.7　クラウド利用の問題点

（1）クレジットカード問題

AWSの料金支払いは基本的にクレジットカード決済である．大学の法人カードでクラウド利用料金の支払いを決済できれば，簡単で余分な手数料は不要で，何も問題は起こらない．ただ大学の本部（財務部）は大きな金額を法人クレジットカードで毎月支払うことに抵抗があるようである．その場合には間に業者に入ってもらって，立替払いをして貰えば解決できるが，手数料が発生する．

（2）保守

クラウドを使い始めると，当然ながら自分たちで制御できない事項が出てくる．たとえば保守などは，避けてほしい時間帯などを要望できるが，最終的には事業者側の都合で実施される．また予定とおりに作業が進まず遅延する場合にも迅速に連絡が来ない可能性がある．

実際に当初は01:00〜04:00の予定で行われた保守が01:00〜05:45と1時間45分超過した例が発生した．このときは大問題になった訳ではないが，「自分たちで制御・管理している」感はない．

（3）調達方法

VDIを提供するQEENSシステムはレンタル料で競争入札して，落札者と契約している．従来のレンタル契約では特に問題にならなかったが，クラウドのインスタンスを使っただけ支払うという契約では「役務」としての請負契約の扱いになる．契約に際しては，単価を算定して，利用時間に単価をかけて総額の使用料を請求する仕組みになるが単価の算定が難しい．

入札に際しては，QUEENSシステムの構築費，各種サーバの維持費，VDIとLinuxのインスタンス利用見込みによる推定利用料金の合計を推定利用時間の合計で割って「単価」が算出される．そのため，入札仕様書の資料として推定利用時間を提示しないといけないが，まったく新規の利用方法で実績がないので正確な利用量を推定できなかった．そのため実際の運用実績に基づく支払いでは支払い金額との齟齬が発生した．

国立大学で，政府調達を行うと，本来，クレジットカードを使えば数分で使えるようになるクラウドのインスタンスを使うために，導入計画から利用開始までに約1年かかる．国立大学の現在の調達や契約の仕組みではクラウドを利用する契約にはいろいろと無理があり，早急に適切な契約ができるように改善すべきである．

10.8　クラウドサービス導入支援TF

大学においてクラウドを活用するためには，ガイドラインに基づいて，個々の項目をきちんと評価し，使用に耐えられるものかどうかを判断しないといけない．利用経験があればそれほど困難な作業ではないが，なにかのシステムを初めてクラウド上で構築する場合には，担当者は多くの場合どうしてよいか分からない．そこでそうした部局担当者や研究者に対してクラウドの導入支援を行うタスクフォースを設置している．クラウドを利用するためのチェックリストがNIIから提供されている[24]．最初はそのチェックリストに基づいて，クラウド利用の可否の判断を行う支援を行う．

情報統括本部自体もさまざまな情報サービスのためにクラウドを利用しており，最初はAWSから利用を始めたが，その後はMicrosoft EES契約の特典利用によるMicrosoft Azureも利用している．自分たちでクラウドを利用する経験を通じて，クラウドを利用するために必要な情報の収集，それぞれのクラウドごとに特徴や使い方に特徴に沿った利用経験を積み，ノウハウを蓄積し,新たに使いたい人，利用を開始する人や部局が円滑にクラウドを活用できるようにしている．

11．ISMS 認証

情報統括本部は2012年3月22日付けでISO（国際標準化機構）の認証基準であるISMS（ISO27001，情報セキュリティ管理システム）の認証を取得した．ISMSは，情報セキュリティの継続的改善のために，情報の「機密性（C）」，「完全性（I）」および「可用性（A）」の観点から，組織的な枠組みを構築・運用していく国際規格である．

これを取得していることは，組織として，より安全で，確実な情報システムの運用を行う体制を構築・維持していることを示し，組織内部において，情報を適切に取り扱っており，各種マニュアルを整備する，インデントに適切に対応できる体制を維持していることを対外的にも示している．

準備から認証取得まで約2年を要し，一大事業であった．このISMS認証を取得するためには情報統括本部の関係者全員が2年間一丸となって努力した．ISMS認証を取得するための議論を通じて，通常の会議や打ち合わせでも「これはISMS的にはどうなのだろうか」という意見が出るようになり，職員の意識が変わった．また扱う情報のCIAを意識し，情報の格付けを行うことにもなった．メールの見出しや文書の上部にCIAのレベルを記載する習慣もできた．各種データの取り扱いに対する意識が上がり，教育データの取り扱いなどの議論にも結びついたと考える．このように認証取得を契機によい影響が出ており，苦労した甲斐はあった．