2026.08.23 業務システム

教務システムのクラウド移行はどこまで進めるか｜配置形態と学内機材の判断軸【2026年】

教務システムの更改は、おおむね5年から7年の周期で回ってきます。その時期に必ず議題へ上がるのが、学内のサーバ室で動かし続けるか、クラウドへ出すかという配置形態の選択です。ただし実際の判断は「全部クラウド」と「全部オンプレミス」の二択になりません。三条市立大学は学務システムをクラウドに置き、財務会計と人事給与を学内に残す構成を選んでいます。この記事では、履修登録期の負荷特性、学籍と成績の保管設計、学認との接続、既存カスタマイズの引き継ぎ可否という論点から、教務システムのどこまでをクラウドへ出し、何を学内機材として残すかの線引きを組み立てます。

まとめ：クラウドへ出す機能と学内に残す機能の線引き、更改期に取る移行順序

結論から示します。教務システムの配置形態は、機能単位で切り分けたほうが判断が早く進みます。学生と教員が学外から触る領域、つまり履修登録・シラバス参照・出欠・成績入力は、クラウドへ出す利得が大きい層です。逆に、自動証明書発行機や学生証カードリーダーのように物理的な媒体を扱う設備は学内に残り、クラウド化しても機材そのものは消えません。

三条市立大学（2021年4月開学）は、学務システムをクラウドに置きながら、財務会計と人事給与、学内サーバー基盤をオンプレミスに残しました。教職員38名・学生163名（2022年4月1日現在）という規模で、運用管理の負担を減らす側にクラウドを寄せた形です。「機微な学籍・成績は学内、事務系は外」という直感とは逆の切り分けである点に注目してください。

そして、判断の土台になる法的な前提をひとつ正しておきます。学業成績や学籍は、個人情報保護法の要配慮個人情報には該当しません。該当するのは健康診断の結果や心身の機能の障害に関する記録であり、修学支援の配慮記録がシステムに入る場合だけ扱いを分ければ足ります。移行順序は、出欠とシラバスを先に出し、成績と卒業判定を最後に残す形が安全側です。

教務システムの配置形態｜SaaS・IaaS・オンプレミスで分かれる責任分界と残る機材

配置形態の議論が噛み合わないのは、「クラウド」という語がSaaSとIaaSの両方を指したまま会議が進むためです。学内で動く範囲、ベンダーが持つ範囲、そして更改費が消える範囲は、この2つで大きく違います。まず責任分界を機能単位で言葉にするところから始めます。

SaaS型で大学側に残る運用責任と、ベンダーへ移るバージョン管理の範囲

SaaS型の教務システムでは、OS・ミドルウェア・アプリケーションの保守と版更新がベンダー側に移ります。学内の情報部門から消えるのは、深夜のパッチ適用、ハードウェア故障の一次対応、そしてサポート切れを起点にした更改計画の立案です。残るのは、学年暦・履修規程・成績評価基準といったマスタ設定と、学生や教員からの問い合わせ一次受けになります。

ここで見落とされやすいのが、版更新の時期を大学側で選べなくなる点です。SaaSは全利用機関へ同時に新版が適用される方式が一般的で、成績確定処理の直前に画面仕様が変わる事態も起こり得ます。契約前に、更新カレンダーの事前告知期間と、学事日程に合わせた適用延期の可否を確認してください。学務システム全体の機能範囲そのものは、大学・専門学校の学務システムの機能範囲と導入判断を整理した記事で整理しています。

IaaS移行で既存パッケージをそのまま動かす場合の費用構造と制約

既存パッケージを大きく変えず、サーバの置き場所だけをクラウドへ移す方式がIaaS移行です。埼玉大学は2014年4月稼働の新システムで、SaaSのDreamCampusシリーズとIaaSのUSiZEシェアードモデルを組み合わせるハイブリッド構成を採りました（提供はSCSK）。全面SaaSに寄せず、機能によって層を変えた実装例です。

IaaSの利得は、ハードウェア更改の山を平準化できることにあります。5年ごとに数千万円単位で立つ調達を、月額に均せる。一方で、OSとミドルウェアの保守責任は学内に残ったままです。ライセンスの持ち込み可否、データベースのコア数課金、そして仮想化基盤の対応バージョンという3点は、移行の前に必ず突き合わせが要ります。配置形態そのものの一般的な比較はオンプレミスとクラウドをコスト・セキュリティ・拡張性で比較した記事が扱っています。

クラウド化しても学内に残る機材｜証明書発行機・カードリーダー・回線

「クラウドにすればサーバ室が空く」という説明は、教務システムに関しては半分しか当たりません。学内に残り続ける機材があります。

自動証明書発行機（在学証明書・成績証明書の券紙と印字装置を伴う）
学生証ICカードリーダー、出席確認端末、教室設置の読取機
学内無線LANのアクセスポイントと認証装置
インターネット回線と、その冗長化のための副回線

特に回線は、クラウド化によって重要度が上がります。学内サーバなら学内ネットワークだけで履修登録が回りましたが、クラウドでは外部回線が落ちた瞬間に学内からも使えません。SINETや商用回線の二重化、あるいは障害時にモバイル回線へ迂回する経路まで含めて、機材の予算を組み直す必要があります。サーバ室の空調とUPSも、残る機材の分だけ縮小はしても撤去はできません。

履修登録の同時アクセス集中に耐える構成｜ピーク特性とスケールの効き方

教務システムの負荷は、年間を通じて平坦ではありません。他の業務システムと決定的に違うのは、利用者のほぼ全員が同じ数十分に押し寄せる点です。この特性を理解しないままサイジングすると、クラウドへ移しても履修登録初日に落ちます。

年に数回・数十分へ集中するピークと、平常時との落差という負荷特性

履修登録は、前期と後期の開始直前に集中します。抽選科目の申込開始時刻をゼロ時に設定している大学では、その瞬間に在籍学生の大半が同時アクセスします。学生5,000名規模なら、平常時の同時接続が数十であるのに対し、ピークは数千まで跳ね上がる計算です。

この落差が、オンプレミスでの調達を非効率にしてきました。年に数回・数十分のピークに合わせてサーバを買うため、残りの期間は資源が遊びます。逆に言えば、教務システムはクラウドの従量課金と相性が良い数少ない学内システムです。ピーク時だけ台数を増やし、終われば戻す。この運用が制度上・契約上できるかを、調達仕様書に書き込んでおきます。

スケールアウトが効くWeb層と、効きにくいデータベース層の非対称

「クラウドだから自動で伸びる」という理解は、層によって当たり外れがあります。台数を増やせば素直に処理量が伸びるのはWeb・アプリケーション層です。一方、データベース層は書き込みが単一系に集まる構成が多く、台数を足しても書き込み性能はほとんど伸びません。

層	ピーク時の増強	効きにくい要因
Web・アプリ層	台数追加が有効	セッション共有の設計
データベース書き込み	台数追加は効きにくい	単一系への書き込み集中
データベース参照	読み取り専用複製が有効	複製の反映遅れ
バッチ・抽選処理	実行基盤の分離が有効	オンライン処理との資源競合

履修登録は登録＝書き込みが主体の処理です。つまりWeb層をいくら増やしても、データベースが詰まれば待ち行列が伸びるだけになります。ベンダーの提案に「オートスケール対応」とあったら、どの層が対象なのかを必ず確認してください。

抽選処理とバッチをオンライン処理から切り離す構成の判断と実装基準

抽選科目の当落計算、成績のGPA再計算、証明書の一括出力は、いずれも重いバッチ処理です。これらがオンライン処理と同じ資源を使っていると、抽選計算の裏で履修登録画面が遅くなります。切り離しの方針は単純です。

バッチ専用の実行基盤を分け、オンライン層と資源を共有しない
抽選の集計は読み取り専用複製から読み、書き戻しのみ主系へ送る
証明書の一括出力は履修登録期間を外した時間帯へ寄せる

SaaSを選ぶ場合、この分離はベンダー側の設計に依存します。仕様として問い合わせるべきは「抽選処理実行中にオンライン応答が劣化した実績の有無」で、抽象的な性能値ではありません。過去の繁忙期に何が起きたかを、具体的な事象で聞き出すほうが判断材料になります。

学籍と成績データの保管設計｜要配慮個人情報の誤解と、実際に効く権限設計

クラウド化の会議で最も時間が溶けるのが、「成績のような機微な情報を外部に置いてよいのか」という論点です。ここには法的な誤解が混ざっており、前提を正しておくと議論が一段速く進みます。

成績と学籍は要配慮個人情報に当たらない｜法第2条第3項の限定列挙

個人情報保護法の要配慮個人情報は、法第2条第3項と政令第2条、規則第5条によって11項目に限定列挙されています。人種、信条、社会的身分、病歴、犯罪の経歴、犯罪被害の事実、心身の機能の障害、健康診断等の結果、保健指導や診療・調剤の事実、刑事事件の手続、少年保護事件の手続の11項目です。

この列挙に、学業成績・学籍・所属は含まれません。個人情報保護委員会のガイドライン（通則編）でも、要配慮個人情報を推知させるにすぎない情報は該当しないと整理されています。したがって、成績データがクラウドにあることを理由に取得時の同意義務や漏えい時の追加規律が発生するわけではありません。もちろん個人情報であることに変わりはなく、安全管理措置と委託先の監督は当然に必要です。

大学で実際に該当するデータ｜健康診断の結果と障害に関する記録

では、大学の情報システムで要配慮個人情報になるのは何か。定期健康診断の結果、保健管理センターの受診記録、そして修学支援のために保持する心身の機能の障害に関する記録です。これらは列挙項目に直接当たります。

教務システム本体には通常これらを持ちませんが、注意すべき接続点があります。修学上の配慮事項（試験時間の延長、別室受験、板書の代替など）を履修・試験運用へ渡すために教務システム側へ持たせる設計にすると、その項目だけが要配慮個人情報になります。この場合の実務対応は、全体をオンプレミスに戻すことではありません。配慮事項を別テーブルに分離し、参照権限を保健・学生支援部門に限定したうえで、教務側には「配慮の有無」という真偽値だけを渡す設計にします。

保管リージョンと再委託の確認、委託先監督を契約条項へ落とす手順

クラウド事業者への委託で確認すべき事項は、法的な区分より運用の実体にあります。調達段階で書面化しておく項目を挙げます。

データの保管リージョン（国内保管か、国外へ複製されるか）
再委託の範囲と、再委託先の名称を開示する義務の有無
バックアップの保持期間と、契約終了時のデータ返還・消去の方法
障害・漏えい発生時の通知時限と、大学側の報告義務との整合

保管場所が国外になる場合、外国にある第三者への提供の規律が関わるため、事前に法務・情報公開担当と条項を詰めます。政府調達では政府情報システムのためのセキュリティ評価制度（ISMAP）のクラウドサービスリストが参照されており、国立大学法人でも自主的な確認基準として使う例があります。制度の適用範囲と掲載状況は変動するため、調達時点で公式の一覧を確認してください。

学内認証基盤との接続｜学認とシングルサインオンをクラウド前提で組み直す

教務システムをクラウドへ出すと、認証の入口が学内ネットワークの外へ移ります。ここを後回しにすると、学生が教務・LMS・図書館・メールで別々のIDを打つ運用に逆戻りします。

SAMLとShibbolethを前提にした学認接続と、SaaS側の対応可否

国内の大学が共通の土台として使ってきたのが、国立情報学研究所と全国の大学等が連携する学術認証フェデレーション「学認」です。2009年度から構築・運用され、運用フェデレーションとテストフェデレーションの2種が提供されています。IdPホスティングサービスや認証プロキシサービスも用意されており、自前でIdPを立てられない小規模校の受け皿になっています。

教務システムのSaaSを選ぶ際は、SAML 2.0のサービスプロバイダとして学内IdPと連携できるかについて、機能一覧の文言ではなく接続実績の確認が必要です。「SSO対応」とだけ書かれた製品が、実際には独自の代理ログイン方式だったという食い違いは起こります。方式ごとの違いはシングルサインオンの4つの実現方式とIdP選定を扱った記事に整理があります。

卒業・休学・退学でアカウント権限が落ちるタイミングの設計基準

学籍の異動は、認証基盤の設計課題そのものです。卒業直後に成績証明書の申請を受け付ける大学では、卒業日にアカウントを即停止すると窓口が回らなくなります。休学者は在籍しているが履修はできない、退学者は在籍しないが証明書発行の対象には残る。この状態の差を、権限として表現する必要があります。休学・退学・除籍を事由コードと有効期間で持ち分ける設計は、学籍レコードの採番と在籍異動のデータ設計を扱った記事で詳しく解説しています。

実装で決めるのは3点です。学籍状態を認証基盤へ流す頻度（日次か即時か）、状態ごとに許可する機能の対応表、そして猶予期間の長さ。クラウド側で学籍状態を判断させず、学内の人事・学籍マスタを唯一の正としてIdPの属性に載せ、SaaS側は属性を受け取って制御するだけにしておくと、更新漏れの事故が減ります。

既存カスタマイズ資産の引き継ぎ｜三分類の棚卸しと段階移行の順序

10年以上動いた教務システムには、必ず改修の積み重ねがあります。この資産の扱いは、クラウド移行の成否を左右する要因です。全部残そうとすればSaaSは選べず、全部捨てようとすれば現場が止まります。

カスタマイズを制度由来・運用由来・画面都合に仕分ける棚卸し手順

改修の一覧を眺めても判断できません。先に三分類へ仕分けます。

制度由来：学則・履修規程・単位認定の独自ルールに紐づく改修（例：他学部履修の上限、GPA算出式の独自係数）
運用由来：事務手続の流れに紐づく改修（例：承認経路、通知の文面、締切の段階設定）
画面都合：見た目や入力補助のための改修（例：項目の並び替え、一括入力の補助）

捨てられないのは制度由来だけです。運用由来は、SaaSの標準機能に合わせて事務手続の側を変えられないかを検討対象にします。画面都合は原則として捨てる。この仕分けを先にやらないと、ベンダーへ「現行通り」と伝えてしまい、結局スクラッチ相当の見積りが返ってきます。

SaaSで再現できない改修の逃がし先｜周辺システムと帳票基盤

制度由来の改修がSaaSの標準機能で表現できない場合、本体を諦める前に逃がし先を検討します。現実的な受け皿は3つあります。

ひとつは帳票基盤です。独自様式の成績通知や単位修得証明は、教務システム本体ではなく帳票ツール側で持たせることで、本体を標準のまま運用できる構成です。ふたつめは周辺の小規模システムで、抽選ロジックや実習配属の割当のように独自性が高い処理を切り出して外に置き、結果だけを教務システムへ書き戻します。3つめはデータ連携基盤で、他システムとのマスタ同期をSaaSの標準APIと変換処理の組み合わせで吸収します。

この切り出しは、次回の更改でも資産として残ります。本体をSaaSに寄せ、独自性を外側に置く構造にしておくと、製品を入れ替えても外側は生き延びるためです。製品選定の軸そのものは公表統計の不在を前提に教務システムの選定軸を組み立てる手順を扱った記事で整理しています。

出欠とシラバスを先に出し、成績と卒業判定を最後に残す移行順序

段階移行の順序は、影響範囲と巻き戻しの容易さで決めます。埼玉大学が2012年に出欠確認システムを先行してクラウド化し、2014年4月の新システムで教務全体へ広げた進め方は、この順序に沿っています。

シラバス・時間割の参照系（読み取り中心で、障害時も紙で代替できる）
出欠管理（学期途中でも切り戻しが利き、過年度データへの影響が小さい）
履修登録（ピーク負荷の検証が必要で、学事日程の切れ目に合わせる）
成績・単位認定・卒業判定（過去データとの整合が必須で、誤りが学位に及ぶ）

逆順、つまり成績から移すのは避けてください。卒業判定は数十年分の科目読み替え規則を参照するため、移行時のデータ変換で最も事故が出ます。旧システムのデータ構造の解読と変換規則の設計を含めた移行工程は、システムマイグレーション・リプレイスのような移行専門の支援を組み合わせると、学内の情報部門の負荷を平準化できます。

教務システムのクラウド化を見送るべき条件と、踏み切ってよい条件の線引き

ここは条件を付けて言い切ります。教務システムのクラウド化は、どの大学にも一律に勧められる打ち手ではありません。

見送るべき条件｜独自制度の多さと、単年度予算による契約の制約

次の条件が2つ以上重なる場合、今回の更改でのクラウド化は見送り、オンプレミスまたはIaaSでの現行踏襲を選ぶほうが安全です。

制度由来のカスタマイズが多数あり、学則・履修規程の改正が今回の更改に間に合わない
単年度予算主義の運用が固く、複数年契約や従量課金の増減を予算科目に載せられない
インターネット回線が単線で、副回線の予算措置が同時に取れない
学内IdPが未整備で、認証基盤の構築と教務更改を同時並行で走らせる体制がない

とりわけ回線の単線構成は、クラウド化と組み合わせてはいけません。学内サーバなら回線障害でも学内から履修登録できましたが、クラウドでは全学が同時に使えなくなります。費用の見積り方そのものは学生数・機能範囲・調達方式で変わる教務システムの費用構造を扱った記事で扱っています。

踏み切ってよい条件｜更改期・小規模校・情報部門が実質1名以下の体制

逆に、次の条件がそろうなら踏み切ってよい局面です。ハードウェアが更改期を迎えていて調達が避けられない、学生規模が小さく標準機能で回せる、情報システム部門の専任がひとりかそれ以下で夜間障害の対応体制がない、という3つです。

三条市立大学は、教職員38名・学生163名（2022年4月1日現在）という規模で学務システムをクラウドに置き、財務会計と人事給与を学内に残しました。小規模校ほど、運用管理の負担削減という効果が相対的に大きく出ます。判断を単純化すると、「専任の運用要員を張れないなら、機微さを理由にオンプレミスへ留めるのは合理的でない」となります。停止時間を短くする力は、自前の当番体制よりクラウド事業者の運用体制のほうが上回る場面が多いためです。

よくある質問

教務システムのクラウド移行を検討する担当者から、実際に寄せられることの多い質問をまとめました。

教務システムをクラウドにすると学内のサーバ機材は不要になりますか？

サーバ本体は減りますが、機材がなくなるわけではありません。自動証明書発行機、学生証ICカードリーダー、教室の出席確認端末、無線LANのアクセスポイントと認証装置は学内に残ります。加えて、インターネット回線の重要度が上がるため、副回線や機器の二重化に予算を振り直す必要が出ます。サーバ室そのものは縮小できても、空調とUPSを完全に撤去できる例は多くありません。

学籍や成績をクラウドに置いても個人情報保護法上の問題はありませんか？

学業成績と学籍は、個人情報保護法の要配慮個人情報には該当しません。要配慮個人情報は法第2条第3項と政令第2条により11項目に限定列挙されており、成績や所属はそこに含まれないためです。ただし通常の個人情報であることに変わりはなく、安全管理措置と委託先の監督は必要です。健康診断の結果や修学支援上の配慮記録を同じシステムに持たせる場合は、その項目だけを分離して権限を絞ります。

履修登録の時期だけサーバを増強することはできますか？

IaaSであれば台数の増減で対応できますが、伸びる層と伸びない層があります。Web・アプリケーション層は台数追加が素直に効く一方、履修登録のような書き込み中心の処理はデータベースの単一系に集中するため、台数を足しても改善しにくい構造です。SaaSの場合は増強の可否がベンダーの設計に依存するので、繁忙期の実績を具体的な事象で確認してください。

既存の教務システムのカスタマイズはクラウドへ引き継げますか？

すべては引き継げません。学則や履修規程に紐づく制度由来の改修は残す前提で設計し、事務手続の流れに紐づく運用由来の改修は標準機能に合わせられないかを検討し、画面の見た目に関する改修は原則として捨てます。制度由来でSaaSに載らないものは、帳票基盤や周辺の小規模システムへ切り出して外側に置くと、本体を標準のまま使えます。

オンプレミスとクラウドではどちらが費用を抑えられますか？

総額の大小は規模と期間で逆転するため、一般解はありません。判断しやすいのは費用の形です。オンプレミスは5年前後ごとに数千万円規模の調達が立つ山型、クラウドは月額で平準化される平坦型になります。単年度予算の制約が強い場合は平準化が効きますが、複数年契約を結べない運用だと従量課金の増減を予算に載せられず、逆に足かせになります。