教務システムの価格を調べ始めると、数十万円という数字と一億円という数字が同じ検索結果に並びます。桁が三つ違うのに、どちらも嘘ではありません。教務システムには定価という考え方が成り立ちにくく、値札は学生数と、標準機能からどれだけ外れるかという差分の量で後から決まるからです。この記事では、見積書に並ぶ費目を分解したうえで、価格が動く軸、規模別のレンジ、そして国立大学であれば調達制度そのものが価格の出方を左右するという構造まで、順に組み立てます。
まとめ:教務システムの価格は学生数と標準機能からの差分でほぼ決まる
先に結論を置きます。教務システムの価格を左右するのは製品の優劣ではなく、在籍学生数という課金の母数と、パッケージの標準機能からどれだけ外れた要件を持ち込むかという差分の量です。同じ製品でも、学生二千人の単科大学が標準設定のまま使う場合と、学部十を抱える総合大学が独自の履修判定と独自帳票を持ち込む場合とでは、初期費用が一桁変わります。
次に押さえるのが、見積書を五つの費目に分けて読むという習慣でしょう。初期費用、年額の保守料と利用料、データ移行費、個別開発費、操作研修費。この五つに分けずに総額だけを比べると、初期費用を抑えた提案が五年後に最も高くつくという逆転が起きます。特にデータ移行費と個別開発費は、要件が固まるまで確定しないため、見積時点では前提条件つきの概算しか出てきません。
そして国立大学の場合、価格の出方に調達制度が直接効いてきます。政府調達に関する協定の基準額は、令和8年4月1日から令和10年3月31日までの適用分で10万SDR、邦貨換算2,000万円です。国立大学法人の物品およびサービス調達がこの額を超えると、官報公告を伴う政府調達手続に乗り、意見招請から納入までに一年前後の期間を見込むことになります。制度の全体像と機能範囲については学務システムの定義と機能範囲を整理した記事を先に読むと、この後の費目の話が具体的に見えてきます。
教務システムの価格を構成する五つの費目と、見積書での現れ方の違い
まず費目の分解から始めます。ここを揃えておかないと、複数社の見積を並べたときに何が高くて何が安いのか判別できません。
教務システムの初期費用に含まれるライセンスと環境構築と初期設定
初期費用と一括りにされる金額の中身は、おおむね三層に分かれます。第一層がソフトウェアのライセンスまたは初期導入料で、製品を使う権利そのものの対価です。第二層が環境構築で、クラウド提供であればテナントの払い出しと接続設定、オンプレミス提供であればサーバ調達と構築作業が入ります。第三層が初期設定、つまり学部・学科・課程のマスタ登録、科目区分、単位認定ルール、成績評価の段階設定といったパラメータ投入にあたります。
見積を読むときに注意したいのは、第三層の初期設定がどこまで含まれるかという線引きです。ベンダーが投入するのか、大学側が投入して不明点だけ支援を受けるのかで、作業量が数十人日単位で動きます。安い見積は第三層を大学側の作業として除外していることが多く、その場合は職員の稼働という見えない費用が別途発生するでしょう。
年額の保守料と利用料がそれぞれ何を買っている費目なのかの線引き
年額でかかる費用も一枚岩ではありません。クラウド型の利用料は、システムを稼働させ続けるための対価です。これに対して保守料は、障害対応、問い合わせ窓口、法令や制度改正に伴うプログラム改修、バージョンアップの提供といった役務の対価にあたります。オンプレミス型では両者が分離し、ハードウェアの保守がさらに別枠で立つ構成が一般的でした。
ここで確認しておきたいのが、制度改正対応が保守料に含まれるかどうかという一点です。高等教育では、認証評価の様式変更、修学支援の制度に関わる帳票、科目ナンバリングや単位互換の扱いなど、外部要因による改修が定期的に発生します。これを保守の範囲外として都度見積とする契約にしてしまうと、年額は安く見えても実支出は読めません。契約書の保守範囲の条文は、価格表よりも先に確認する価値があります。
データ移行と個別開発と操作研修という見積の変動幅を生む三費目
残る三費目が、見積の幅を作る張本人です。データ移行費は、旧システムに蓄積された学籍・履修・成績・卒業判定の履歴を新システムへ移す作業の対価で、移行対象の年数と、旧データの整い方で工数が変わります。学籍簿のように長期保存が求められるデータは移行対象年数が長くなりやすく、ここを何年分とするかが金額を左右する変数になります。
個別開発費は、標準機能で満たせない要件をつくり込む費用です。人月という単位で積算されるため、単価と工数の妥当性を発注者側で検算できると交渉の材料になります。単価の考え方は人月単価の相場と内訳を扱った記事に整理してあります。操作研修費は、教務課職員向け、教員向け、学生向けと対象が分かれ、回数と会場と教材で積算されるのが通例でした。
| 費目 | 変動の主因 | 見積時の確定度 |
|---|---|---|
| 初期費用 | ライセンス体系と規模 | 比較的高い |
| 年額保守・利用料 | 学生数と保守範囲 | 比較的高い |
| データ移行費 | 移行年数とデータ品質 | 低い |
| 個別開発費 | 標準機能からの差分 | 最も低い |
| 操作研修費 | 対象者数と回数 | 中程度 |
学生数と学部数と機能範囲という三つの軸で教務システムの価格が動く
費目が分かったところで、その金額を押し上げる軸を三つに整理します。この三つを自校の数字で埋められると、見積を受け取る前に概算の当たりがつきます。
学生数課金で数えるのは在籍者数か延べ利用者数かという定義の差
高等教育向けの教務システムは、在籍学生数を課金の母数に置く料金体系が主流です。ただし、その学生数の数え方には複数の流儀があります。年度当初の在籍者数で固定する方式、年度途中の最大在籍者数で見る方式、休学者や科目等履修生を含めるかどうかで刻む方式などが並びます。
この定義差は、社会人向けの科目等履修生や公開講座の受講者を多く抱える大学では無視できない金額になります。契約前に、休学者・研究生・科目等履修生・聴講生・卒業生をそれぞれ課金対象に含めるのかを確認し、含めるなら何人分になるのかを自校のデータで試算してください。教職員アカウントが別課金になる製品もあるため、そちらも同時に確認しておきます。
学部数と課程数が価格に効いてくるのは履修判定ロジックの本数の差
学部数が価格に効く理由は、単純な規模の大きさではありません。効いているのは、卒業要件判定と進級判定のロジックが何本必要かという点です。学部ごと、学科ごと、さらに入学年度ごとにカリキュラムが異なれば、判定パターンはその積で増えていきます。
学部が十あり、それぞれに三つの学科があり、カリキュラム改訂が四年分残っているとすれば、判定ロジックは百二十通りに近づく計算です。パッケージの標準機能が想定しているのは、この判定を汎用のルール設定で表現できる範囲までになります。教職課程や資格課程のように、他学部履修と読み替えが複雑に絡む要件は、設定では表現しきれず個別開発に落ちる場面が出てきます。
学籍と履修と成績というコアに何を足すかで総額の桁が変わる境目
三つ目の軸が機能範囲です。学籍管理、履修登録、成績処理、卒業判定、証明書発行という中核だけであれば、パッケージの守備範囲に収まります。総額が跳ねるのは、その外側を取り込もうとしたときでしょう。
外側にあたるのは、入試出願と入学手続、学費の請求と収納、奨学金、就職支援、学習管理システムとの成績連携、図書館システムとの利用者連携、学認による認証連携、そして人事給与や財務会計との基幹連携です。これらは既存システムとのインターフェース開発を伴い、一本ごとに設計と試験の工数が積み上がります。どこまでを一つのシステムに寄せ、どこからを連携で済ませるかという線引きが、価格の桁を決める境目になります。
規模と導入形態で分かれる教務システムの価格レンジの目安と読み方
次に、公開情報から読み取れるレンジを三段に分けて示します。ただし、これは値札ではなく当たりをつけるための目盛りとして扱ってください。
一校で標準設定のまま使うクラウド利用型の価格レンジと前提条件
最も軽い形が、単一校がクラウド型のサービスを標準設定のまま使う構成です。受託開発会社が公開している見積相場では、初期費用が数十万円規模、月額が一校あたり数万円規模という水準が示されています(2026年8月時点の公開情報)。中小規模の専門学校や単科大学で、既存データの移行対象が短く、独自帳票を持たない場合に成立する形になります。
この水準が成立する前提は厳しめに見ておく必要があります。判定ロジックが標準ルールで表現でき、外部システム連携が実質ゼロで、証明書の様式も製品の標準に寄せられること。この三つが揃わない場合、同じ製品でも見積は次の段へ移ります。
大学向けパッケージの導入で初期費用が桁を一つ上げる要因の内訳
中間帯が、大学向けパッケージを導入し、自校の要件に合わせて設定と一部作り込みを行う構成です。同じく公開されている見積相場では、初期が数百万円から一千万円規模、外部システムとの追加連携を重ねると一千万円台から数千万円規模へ伸びるという整理が見られます(2026年8月時点の公開情報)。
この帯で金額を押し上げているのは、製品そのものよりも周辺作業です。移行対象年数の長いデータのクレンジング、独自帳票の再現、既存の学内ポータルとの画面統合、そして稼働前の並行運用期間の支援が積み上がります。金額の妥当性を検算したい場合は、システム開発の費用相場と見積の妥当性を扱った記事にある人月換算の考え方を当てはめると、提示額が何人月ぶんに相当するのかが見えてきます。
全学基盤の刷新と個別受託開発が一億円前後まで届いてしまう条件
最も重い帯が、教務を含む全学の情報基盤をまとめて刷新する構成、あるいは要件が特殊で個別受託開発を選ぶ構成です。公開されている相場整理では、数千万円から一億円規模に届く事例が示されています(2026年8月時点の公開情報)。国立大学の実際の調達公告でも、学務システムや教務情報システムが単独案件として官報公告を伴う政府調達で扱われており、規模の大きさがうかがえます。
この帯に入るかどうかの判定は、金額の大小ではなく対象範囲で行うのが実務的です。教務単体なら中間帯、入試から学費収納、人事給与連携までを一つの調達にまとめるなら最重量帯、という具合に、調達の括り方が価格帯を決めます。導入形態そのものの選び分けについては業務システムの導入形態を三系統で比較した記事が全体像の参考になります。
調達方式と予算年度が教務システムの価格に効いてくる国立と私立の差
ここからが、相場表には載らない話です。国立大学法人は調達制度の枠内で買うため、価格の出方そのものが私立大学とは異なります。
二千万円という政府調達の基準額が国立大学の調達手続を分ける線
政府調達に関する協定の基準額は、令和8年4月1日から令和10年3月31日までに締結する契約に適用される邦貨換算額で、10万SDRが2,000万円と定められています。独立行政法人および国立大学法人等の物品およびその他のサービスについては、日本の自主的措置としてこの水準が用いられます(ジェトロ政府公共調達データベースの公開情報・2026年8月時点)。
この線を超える調達は、官報での公告、仕様に対する意見招請、十分な入札準備期間の確保といった手続を伴います。手続が増えること自体は価格を直接上げませんが、仕様書を先に固め切る必要があるため、要件を後から足しにくくなります。逆に言えば、仕様書の完成度がそのまま価格の確からしさに直結する構造です。
意見招請から開札まで数か月かかる調達のリードタイムの実例と含意
実際の期間感を公告情報から拾ってみます。放送大学の「教務情報システム設計・開発・導入 一式」では、意見招請の公告が令和8年5月18日、意見提出期限が同年6月8日、入札公告が同年7月27日、入札書等の受領期限が同年9月16日でした(放送大学の一般競争入札公告情報・2026年8月23日確認)。意見招請から入札書提出までで約四か月かかっています。
納入までを含めるとさらに長くなります。国立大学法人東京海洋大学の「学務システム 一式」は、公告日が2025年7月16日、開札が令和7年10月15日、納入期限が令和8年9月15日でした(ジェトロ政府公共調達データベース・2026年8月23日確認)。公告から納入期限まで約十四か月あり、総合評価落札方式が採られています。稼働希望日から逆算すると、仕様検討の着手はその一年半以上前になる計算です。
単年度予算と複数年契約のどちらで買うかで総額と柔軟性が変わる
予算の建て方も価格に影響します。初期費用を単年度の設備投資として一括計上する買い方と、サービス利用料や賃貸借として複数年に平準化する買い方では、単年度の支出額に大きな差が出る設計です。前者は総額を抑えやすい一方で、その年度に予算を確保できなければ計画が止まります。後者は年度あたりの負担を均せますが、契約期間を通じた総額は膨らむのが通例でした。
判断材料になるのは、想定利用年数と改修の見込みです。十年使う前提で改修が少ないなら一括購入型が有利に働きます。五年程度で制度変更に合わせて作り替える前提なら、複数年のサービス契約にして解約と乗り換えの余地を残すほうが結果的に安く収まるでしょう。私立大学であればこの選択は自由度が高く、単年度の予算制約に縛られない設計が可能です。
パッケージ導入と個別受託開発が入れ替わる損益分岐点の見極め方
ここが発注判断の中心です。パッケージが常に安いわけでも、個別開発が常に高いわけでもありません。入れ替わる地点があります。
教務システムをパッケージのまま使い切れる大学側の三つの前提条件
パッケージ導入で足りると言い切れるのは、次の三条件が揃うときです。第一に、卒業要件と進級要件の判定が製品の標準ルール設定で表現できること。第二に、証明書と成績通知の様式を製品の標準に寄せる合意が学内で取れること。第三に、外部システムとの連携が数本以内に収まり、いずれも製品の標準インターフェースで対応できること。
この三条件が揃うなら、業務のほうを製品に合わせる判断が費用面でも運用面でも有利です。逆に、いずれか一つでも譲れない事情があるなら、その一点が個別開発の起点になり、そこから連鎖的に周辺の作り込みが発生します。三条件のうち二つを満たす、という中途半端な状態が最も費用対効果を悪くします。
個別受託開発へ切り替える判断が立つのは改修費が保守料を越えた時
切り替えの判断は、感覚ではなく金額の比較で行えます。目安は、パッケージに対する個別開発費と、その改修を維持するための追加保守料の合計が、想定利用年数を通じて個別受託開発の総額に近づいたときです。カスタマイズを重ねたパッケージは、バージョンアップのたびに改修部分の追随作業が発生し、その費用が毎回積み上がります。
実務上の警戒ラインとしては、個別開発費がパッケージ初期費用の半分を超えた時点が一つの目印になります。この水準を超えると、製品の標準機能を使っているとは言いにくい状態に近づき、バージョンアップ追随の負担だけが残る状態です。パッケージと個別開発の性質の違いはスクラッチ開発とパッケージの違いと発注判断を扱った記事に整理してあります。
五年間の総額で並べて損益分岐を計算する手順と見落としやすい点
計算の手順を具体化します。まず固定する期間は五年です。次に、パッケージ案は初期費用と個別開発費に、年額の保守料と利用料の五年ぶん、加えてバージョンアップ追随の想定改修費を二回ぶん見込んで合計します。個別受託開発案は、開発費に年額の保守料五年ぶんとインフラ費五年ぶんを足します。両者を並べて、差額が一割以内に収まるなら、金額ではなく要件適合と将来の変更しやすさで決めるのが妥当です。
見落としやすいのが三点あります。移行時の職員稼働、稼働後の運用要員、そして契約終了時のデータ返却とその形式です。三つ目は特に軽視されがちですが、次の乗り換え費用を左右します。自校の要件がパッケージの想定から外れており、個別受託開発を含めた設計から相談したい場合は、基幹システム開発の窓口で要件整理の段階から扱えます。
見積を横並びで比較できる形に揃えるために提示単位を先に決める
最後に、価格を比較可能にするための発注者側の準備を整理します。同じ条件を出さなければ、返ってくる金額は比べられません。金額以外の比較軸をどう設計するかは、教務システムのシェアの読み方と選定軸を整理した記事にまとめました。
提案依頼の時点で学生数と学部数と移行対象年数を数字で明示する
提案依頼書には、在籍学生数、教職員数、学部数と学科数、カリキュラム改訂の残存年度数、移行対象データの年数と件数を数字で書き込みます。ここを空欄にしたまま概算を求めると、各社が独自の前提を置くため、金額の差が実力差なのか前提差なのか分からなくなります。
数字とあわせて、譲れない要件と譲れる要件も分けて示してください。判定ロジックは譲れないが証明書様式は標準に寄せられる、といった情報があると、各社は個別開発の範囲を絞った提案を組み立てられます。提案依頼書そのものの構成は提案依頼書の記載項目を発注者視点で整理した記事を土台にすると早く形になります。
除外項目を明記させないと初期費用の安さが導入後に反転する理由
見積書には、含まれるものと同じ密度で含まれないものを書かせます。初期設定のマスタ投入、旧データのクレンジング、独自帳票の作成、並行運用期間の支援、稼働後三か月の追加問い合わせ対応。これらが除外されていれば、初期費用は当然安く出ます。
除外項目が明記されていれば、追加で必要になる作業を自校の職員稼働で賄うか、別途発注するかを事前に判断できます。明記させないまま契約すると、稼働直前に追加見積という形で表面化し、そのときには他社への切り替えという選択肢が既にありません。
相見積の各社に同じ費目区分で提出させて桁ずれを防ぐ進め方の型
提案依頼書に見積の様式を添付し、費目区分を発注者側から指定するのが確実な進め方です。この記事の前半で示した五費目、すなわち初期費用、年額の保守料と利用料、データ移行費、個別開発費、操作研修費という区分をそのまま様式にして配れば、返ってくる見積は横並びになります。
加えて、五年総額の欄と、年度別の支出計画の欄を設けておくと、単年度予算との突き合わせがそのまま行えます。国立大学であれば、この五年総額が政府調達の基準額に対してどの位置にあるかで、必要な手続とスケジュールも同時に決まる仕組みです。様式を先に配るという一手間が、比較の精度と調達の段取りの両方を支えることになります。
よくある質問
教務システムの価格は結局いくらを見ておけばよいですか?
単一校で標準設定のまま使うクラウド型なら初期は数十万円規模から、大学向けパッケージを自校要件に合わせて導入するなら初期は数百万円から数千万円規模、全学基盤の刷新や個別受託開発を含むなら数千万円から一億円規模というのが、2026年8月時点の公開情報から読み取れる幅です。自校がどの帯に入るかは、学生数と外部連携の本数と個別開発の要否で決まります。
学務システムと教務システムで価格に違いはありますか?
呼称の違いであり、価格体系に構造的な差はありません。高等教育の現場では学務システムや学務情報システムという呼び方が多く、製品名や調達件名でも両方が使われています。呼称ごとの機能範囲の違いについては、親記事で整理しています。
クラウド型とオンプレミス型ではどちらが安く収まりますか?
五年程度の利用ならクラウド型が有利になりやすく、十年規模で使い続けてハードウェア更改を織り込んでもなお使うならオンプレミス型が拮抗してきます。ただし現在は製品側がクラウド提供を主軸に置く流れがあり、オンプレミス構成は選択肢自体が絞られる場面が増えました。費用以外の判断材料である負荷特性・認証接続・カスタマイズの引き継ぎは、教務システムのクラウド移行で配置形態を決める判断軸で整理しています。
国立大学と私立大学で価格の決まり方は変わりますか?
結論は、国立大学と私立大学で異なるということです。国立大学法人は政府調達の基準額を超える契約で官報公告と意見招請を伴う手続に乗るため、仕様書を先に固め切る前提になり、着手から納入まで一年前後を見込みます。私立大学は調達手続の自由度が高く、複数年契約や段階導入の設計を柔軟に組めます。
費用を抑えたい場合はどこから削るのが現実的ですか?
削る順序は、独自帳票の再現、移行対象データの年数、個別開発の範囲、この三つです。特に移行年数は、旧システムを参照専用で数年残す運用に切り替えることで、移行対象を大幅に絞れる場合があります。年額の保守料を削るのは、制度改正対応が範囲外になるため避けたほうが無難でしょう。
関連記事
- 学務システムとは?大学・専門学校の履修・成績・学籍の機能範囲と導入判断:本記事の親にあたる定義と機能範囲の整理です。
- 業務システムとは?種類・基幹システムとの違いと開発・導入形態の選び方:導入形態を三系統で比較した全体像を確認できます。
- システム開発の費用相場は?内訳・人月単価と見積もりの妥当性を発注者視点で解説:提示額を人月換算で検算する手順を扱っています。
- 人月単価とは?職種・スキル別の相場と内訳・発注者が妥当性を見抜く方法:個別開発費の単価の妥当性を判断する材料になります。
- スクラッチ開発とは?パッケージ・ローコードとの違いと発注判断を解説:損益分岐を考える前提となる方式の違いを整理しています。
- RFPとは?提案依頼書の意味・目的・記載項目を発注者視点で解説:見積を横並びにする提案依頼書の作り方に進めます。