統合型校務支援システムとは？単機能製品との違いと、名簿の一元化・共同調達で問われる要件

統合型校務支援システムは、学籍・教務・保健・学校事務という校務の記録を一つの製品でまとめて扱う仕組みを指します。文部科学省の調査では整備率が9割を超え、いま議論の中心は「入れるかどうか」ではなく「統合型と呼ばれている製品が、本当にデータの側まで一つになっているか」に移りました。同じ統合型でも、画面を束ねただけの製品と、児童生徒の名簿を一つのマスタとして持つ製品では、教職員の手作業がどれだけ減るかがまるで違ってきます。この記事では、単機能製品との切れ目、名簿の一元化という仕組み、校務系と学習系のデータ連携、そして共同調達の仕様書に書く連携要件までを、受託開発会社の視点で整理します。

まとめ：統合型と呼べる条件と、名簿の一元化で決まる導入効果

先に結論を示します。文部科学省が言う統合型校務支援システムは、教務系（成績処理・出欠管理・時数管理など）、保健系（健康診断票・保健室来室管理など）、学籍系（指導要録など）、学校事務系などを統合した機能を持つシステムです。成績処理だけ、出欠だけを扱う製品はこの定義に入りません。まずは手元の製品がどの領域まで覆っているかを確かめるところが出発点になります。

そのうえで、実務の効果を分けるのは機能の数ではなく構造です。児童生徒と教職員の名簿がシステム内で一つのマスタとして保たれているなら、出欠から成績、指導要録までが同じ人物の記録としてつながり、転記という作業そのものが消えます。逆に、領域ごとに別々の名簿を持ち、画面だけを一つのメニューから開ける状態なら、名簿の突き合わせという新しい作業が増えるだけで終わります。製品デモでは、同じ児童生徒の情報を複数の画面から呼び出し、片方の修正がもう片方へ反映されるかを確認してください。

調達の側では、次世代校務DXという枠組みが前提を変えました。クラウド上で校務を行い、校務系と学習系のネットワークを統合し、認証と権限でデータを守る方向へ移ったためです。都道府県が主導する共同調達では、この連携をどこまで求めるかを仕様書に書き切れているかが成否を分けます。調達構造そのものや費用の内訳、パッケージか自治体カスタムかという選び方は、兄弟記事の校務支援システムとはで扱っているため、本記事は統合の中身と連携要件に絞って進めます。

統合型校務支援システムとは｜単機能の製品と何が分かれるのかを判断する基準

まず語の範囲を確かめます。校務支援システムという言い方には単機能の製品も含まれるため、「もう入っています」という現状報告が、実際には成績処理ソフト1本を指していた例は珍しくありません。統合型かどうかの判定は、調達の議論を始める前に済ませておく作業です。

文部科学省の定義が示す統合の範囲と、単機能の製品との切れ目を確認する方法

文部科学省は統合型校務支援システムを、教務系・保健系・学籍系・学校事務系などを統合した機能を有し、グループウェアによる情報共有を含めて校務全般に必要な機能を実装したシステムと説明しています。整備率の統計もこの定義に沿って集計されており、令和6年度の調査（令和7年3月1日現在）では平均94.8%と公表されました。単機能ソフトだけの状態は、この統計の上では整備済みに数えられません。

判定の実務では、四つの領域を並べて、どれが製品で覆われ、どれが表計算ファイルや紙で残っているかを一覧にする作業が必要です。学校事務系と保健系が抜けている例、教務系はあるが指導要録の出力が別ソフトという例が多い状況です。この一覧が、後の要件定義でそのまま移行対象の範囲になります。定義と全体像をひととおり押さえたい場合は、hubにあたる校務支援システムの機能範囲と調達の解説を先に読んでおくと、本記事の話が位置づけやすくなります。

統合型を名乗る製品でも中身が違う｜画面の統合とデータの統合を見分ける方法

ここが本記事の主題です。製品カタログで統合型と書かれていても、実装には二つの型があります。一つは、領域ごとのモジュールが共通の名簿マスタを参照し、データベースの側で一つにまとまっている型。もう一つは、別々の製品を一つのメニュー画面から起動できるようにし、名簿は定期的なファイル連携で同期させている型です。

後者にも「統合型」という呼称が見られるのが実情です。ただし、現場での手触りは分かれます。同期が1日1回なら、転入した児童生徒の情報が保健系の画面に出るまでに時差が生じる構造です。氏名の異体字や、旧姓と現姓の扱いが領域ごとにずれると、同一人物として結びつかない記録が残ります。年度末の異動が集中する時期に、この差は事故として表面化します。

見分け方は単純です。ある児童生徒の氏名や所属クラスを一箇所で修正し、他の領域の画面で即座に同じ内容になるかを試します。反映まで待たされる、あるいは領域ごとに修正が要るなら、それは画面の統合に留まる製品です。どちらを選ぶかは規模と予算の判断になりますが、後者を選ぶなら同期の頻度と失敗時の検知方法を、契約前に確認しておく必要があります。

統合型校務支援システムの仕組み｜名簿マスタを一つに保つ構造と連携の流れ

統合型が効果を出す仕組みを、データの流れで説明します。校務のデータは、どれも「誰の」記録かという一点で結ばれており、そこが崩れると全体が崩れる構造になっているためです。

児童生徒マスタと教職員マスタを正とする設計が効果を生む理由と確認方法

統合型の中心にあるのは、児童生徒マスタと教職員マスタです。ここに在籍情報（学校、学年、学級、在籍期間）と識別のための番号を持ち、出欠・成績・保健・事務の各記録は、この番号を使って結び付けられます。指導要録や通知表は、その結び付きをたどって組み立てられる出力にすぎません。

この構造が成立していると、学級編成の変更や転入の登録は1回で済み、以降の帳票は自動的に新しい所属で出力される仕組みです。逆に、領域ごとに名簿を持つ構造では、同じ変更を領域の数だけ繰り返すことになり、どこかで漏れると帳票の内容が食い違います。教職員が「システムを入れたのに確認作業が増えた」と言う場合、原因の多くはこの二重管理にあります。

受託開発の観点では、この設計は業務システム一般のマスタ設計と同じ考え方です。違うのは、扱う記録に法令上の保存年限が定められている点で、指導要録は学校教育法施行規則により学籍に関する記録が20年、指導に関する記録が5年の保存とされています。マスタの番号が更新のたびに振り直される設計だと、20年分の記録を後から人物単位で追えなくなります。

教育データ標準が示す主体情報と、コードをそろえておく意味を判断する基準

名簿を一つに保つ話は、システムの中だけでは完結しません。市町村をまたぐ転出入や、学習系システムとの接続では、外部と同じ言葉でデータを表す必要があります。文部科学省の教育データ標準は、この共通言語にあたるもので、3.0系（2022年12月公表）では主体情報として児童生徒・教職員・学校・学校設置者のデータ項目が定義されています。学習指導要領の内容を指すコードも公開済みです。

標準にそろえておく効果が表れるのは、次の場面です。製品を更新するとき、県域の枠組みへ合流するとき、学習系のツールを追加するときが該当します。独自のコード体系で作り込んだ自治体には、そのたびに変換の仕組みが必要です。要件定義では、標準の版を明示したうえで、どの項目を標準に合わせ、どの項目を自治体固有として残すかを決めておきます。標準は版を重ねているため、参照する版と時点を仕様書に書き添えておくと、後任の担当者が迷わずに済みます。

校務系と学習系のデータ連携｜次世代校務DXが変えた前提と調達要件

統合型の議論がここ数年で変わったのは、校務系だけを統合すればよいという前提が崩れたためです。文部科学省が示す次世代校務DXは、クラウド上での校務実施を前提に、校務系と学習系をつなぐ方向を打ち出しています。

ネットワークの分離から、認証と権限で守る方式へ移った経緯と調達への影響

従来の学校は、成績や指導要録を扱う校務系ネットワークと、児童生徒が使う学習系ネットワークを物理的に分ける設計が基本でした。職員室の端末からしか校務系に入れないという制約が、そのまま安全の担保だったわけです。

次世代校務DXが示す整備の四要素は、強固なアクセス制御による対策の実施、ネットワーク統合、クラウド型校務支援システムの整備、データの可視化と利用を行う機能の整備です。分離をやめる代わりに、誰がどの端末からどのデータへ触れるかを認証と権限で表現する方式へ移りました。文部科学省は令和7年12月に第1回、令和8年7月に第2回の次世代校務DXサミットを開催しており、この方向づけは続いています。

調達に跳ね返るのは工数の内訳です。ネットワーク統合を配線の話と捉えていると、多要素認証の導入、端末の管理状態の確認、役割ごとの参照範囲の設計といった作業が見積もりから抜け落ちます。統合型の製品費用よりも、この土台側の費用が総額を左右する場面は少なくありません。

学習系との接続で扱うデータと、連携を止める三つの障害を確認する手順

校務系と学習系をつないで扱いたいデータは、おおむね三種類に整理できます。第一に名簿（誰がどの学級に所属しているか）、第二に学習の記録（提出物、テスト結果、ドリルの進度）、第三に出欠と健康の状況です。名簿が共通なら、学習系のツールを追加するたびにアカウントを作り直す作業が消えます。

連携が止まる原因も、だいたい三つに集約されます。一つ目はコード体系の不一致で、学級名や科目名の表記が製品ごとに違うと突き合わせができません。二つ目は更新タイミングのずれで、年度替わりに校務系が先に新学年へ切り替わり、学習系が旧学年のままという期間が生まれます。三つ目は認証基盤の分裂で、教職員が複数のアカウントを持ち続ける状態です。

この三つは、製品を選んだ後では直しにくい部分です。名簿の受け渡し方式（連携の頻度と方向）、年度更新の順序、認証をどの基盤に寄せるかの三点は、要件定義の段階で決めておいてください。ちなみに高等教育では、履修登録と単位認定を軸にした学務システムが同じ役割を担いますが、指導要録や時数管理という概念がないため、連携の設計も別物になります。校種をまたいだ製品比較は、この点で成り立ちません。

統合型で実際に減る作業と、入れても減らない作業を見分ける判断軸

導入の目的を説明する場面では、効果が出る領域と出ない領域を分けて示したほうが、現場の納得が得られます。全部が軽くなるという説明は、稼働後に失望へ変わるためです。

転記が消える領域｜出欠・成績・指導要録がつながる効果と削減条件

統合型で確実に減るのは、同じ数値を複数の帳票へ書き写す作業です。日々の出欠が学期の集計に自動でまとまり、その集計が通知表と指導要録へ流れる仕組みです。健康診断の結果が保健系に入っていれば、必要な様式へそのまま出力できます。学期末に集中していた作業のうち、転記と検算にあたる部分がここで消える領域です。

もう一つの効果は、記録の突き合わせにかかる時間です。名簿が一つなら、学級担任が持つ名簿と保健室の名簿と事務室の名簿が食い違う状態が起こりません。転入生の情報が全領域へ一度に反映されるため、確認の往復が不要になります。学校単位で見ると地味ですが、教育委員会が域内の状況を把握する場面では、この一致が前提条件になります。

減らない作業を先に見込む｜入力・所見・様式合わせを確認する手順

一方、統合型を入れても減らない作業は明確です。日々の出欠を打ち込む作業、所見や指導の記録を書く作業は、人が判断して入力する部分なので残ります。むしろ紙に書いていた頃より入力先が増えたと感じる教職員も出てきます。

もう一つ残りやすいのが様式合わせです。システムから出る帳票が校内の決裁様式や保護者向けの体裁を満たしていないと、出力後に手作業で整える工程が残り、紙とシステムの二重運用になります。稼働前に、置き換える帳票の一覧を作り、実データで出力して現場が確認する工程を、稼働判定の条件に組み込んでください。この確認を省いた導入は、効果の実感が出ないまま次の更新を迎えます。

都道府県単位の共同調達で問われる要件｜仕様書に書く項目と連携条件

都道府県教育委員会が主導する共同調達では、複数の市町村と学校が同じ基盤に乗ります。ここで問われるのは製品の機能一覧ではなく、連携と引き継ぎをどう約束させるかです。調達方式そのものの選び方や費用の内訳はhub記事に譲り、ここでは連携要件の書き方に絞ります。

データ連携要件として仕様書へ明記しておきたい四項目と確認方法

連携要件は、次の四項目を具体的に書いておくと、後の交渉が楽になります。第一に、名簿データの受け渡し形式と頻度。ファイル連携かAPIか、日次か随時かまで書きます。第二に、市町村をまたぐ転出入時のデータ引き継ぎ手順で、送り出す側と受け取る側の作業をそれぞれ定義します。

第三に、契約終了時のデータ出力形式と返却手順です。画面の印刷イメージしか出せない製品では、20年保存の学籍記録を次の基盤へ移せません。第四に、学習系システムとの接続方式で、対応する認証方式と、名簿を渡す範囲（どの項目を渡し、どれを渡さないか）を明記します。

この四項目は、どれも稼働後に追加しようとすると費用が跳ね上がる部分です。自治体側の既存システムとの受け渡しを含めて設計を組み立てる作業は、公共システム開発で扱う要件定義と同じ進め方で対応できます。仕様書の段階で相談先を持っておくと、後戻りが減ります。

標準への準拠をどこまで求めるか｜要件の書き方で提案の質が変わる

教育データ標準への準拠は、要件の書き方で実質が変わる要素です。「標準に準拠すること」とだけ書くと、提案側は自社の解釈で応じるため、稼働後に項目名が合わないという事態が起こります。参照する版を示し、主体情報のうちどの項目をそのまま持つかを列挙する書き方に変えると、提案を同じ条件で比較できます。同じ条件で並んだ提案をどう採点するかは、校務支援システムの比較軸と評価表の作り方が参考になります。

ただし、すべてを標準へそろえる必要はありません。自治体固有の項目（就学援助の区分や、独自の学級編成の考え方）は、標準にない情報として別に持つ判断で構いません。線を引く基準は、外部とやり取りする情報かどうかです。域内で完結する情報まで標準に合わせようとすると、要件が膨らむ割に得るものが少なくなります。

統合型へ移る判断が成立する条件と、単機能のままでよい場面を見極める判断軸

整備率が9割を超えたいま、残っているのは事情があって進んでいない自治体と、単機能の製品で回している学校です。ここは条件を分けて考えます。

統合型への切り替えを先に進めてよい自治体の条件を判断する三つの基準

次の条件が二つ以上そろうなら、統合型への切り替えを先に進める判断が成立します。第一に、指導要録や通知表の作成で、複数のソフトや表計算ファイルを行き来する運用が定着していること。第二に、市町村をまたぐ転出入が一定数あり、そのたびに紙と手入力に戻っていること。第三に、都道府県が共同調達の検討を開始し、参加の時期が見えていること。

とくに三つ目が該当するなら、単独で作り込む部分を最小限に留め、移行しやすい構成で組むほうが総額を抑えます。名簿の出力形式とコード体系を標準側へ寄せておけば、合流時の変換作業がそのまま減るためです。切り替えの判断は、製品の良し悪しよりも、この時間軸で決まります。

単機能の運用を続けてよい場面と、その間に整えておく土台と移行準備

逆に、単機能のままで構わない場面もあります。学校数が少なく転出入がまれで、現行の運用が破綻せずに回っており、都道府県の枠組みが数年先という自治体です。この状況で単独調達に踏み切ると、共同調達を前提とした支援の枠組みから外れ、費用を全額自治体で負担したうえに、数年後に移行し直すことになります。

ただし、待つと決めた期間を空けて過ごすと、合流のときに準備不足が出ます。この期間に着手しておくのは、製品ではなく土台の部分です。校務系と学習系のネットワークの現況調査、教職員アカウントの整理と多要素認証の導入、帳票の棚卸し、そして名簿データのコード体系の整理。いずれもどの製品を選んでも必要になる作業で、先に済ませておくほど合流時の立ち上がりが速くなります。現行の運用がすでに限界で、教職員の時間外が増えているなら、待つ判断は取れません。その場合は負荷が集中している領域から範囲を絞って入れ、移行しやすい構成で組みます。

よくある質問

単機能の製品が入っている場合、統合型へ移すとデータは引き継げますか？

引き継げるかどうかは、現行製品から出力できる形式次第です。CSVなどの構造化された形式で出せるなら、項目の対応づけを行って取り込めます。画面の印刷イメージやPDFしか出せない製品では、手入力での再登録か、過去分は参照用に別途保管する判断になります。移行の可否は、新しい製品を選ぶ前に、いま使っている製品側の出力仕様を確認するところから始めてください。

統合型校務支援システムは学習系のツールと必ず接続しなければなりませんか？

接続しない構成でも運用は成り立ちます。ただし、名簿を共通にしないと、学習系のツールを追加するたびにアカウントの作成と学級編成の反映を手作業で行うことになります。学習系のツールを複数使っている自治体ほど、接続しない選択のコストが積み上がる構造です。当面つながない場合でも、名簿の出力形式だけはそろえておくと、後から接続する余地が残ります。

統合型校務支援システムの導入で、保護者側に見える変化はありますか？

製品によっては、欠席連絡の受付や、お知らせの配信を保護者向けの画面から行える機能を持ちます。この部分が入ると、朝の電話対応という業務が減るため、教職員側の効果としても表れます。ただし紙の配布を完全にやめられるかは、家庭側の受信環境をどう確保するかという運用の判断になり、システムだけでは決められません。

教育データ標準にそろえておくと、どの場面で効果が出ますか？

効果が出るのは、製品を更新する場面、県域の共同調達へ合流する場面、学習系のツールを追加する場面の三つです。いずれもデータを外へ渡す局面で、標準に沿っていれば変換の作業が小さく済みます。日々の運用の中では違いが見えにくいため、要件定義の段階で意識して決めておかないと、後回しにされやすい項目です。

統合型校務支援システムの導入は、誰が主導して進めるのですか？

調達の主体は学校ではなく設置者、つまり市町村または都道府県の教育委員会です。ただし帳票の統一や運用ルールの決定には学校側の合意が要るため、教育委員会の情報担当と、各校種の代表となる教職員が入る検討体制を組む形が現実的です。連携要件やネットワークの設計は専門性が高いため、要件定義の段階から開発側を交えると、仕様書の粒度がそろいます。

関連記事

• 校務支援システムとは：機能範囲・共同調達の仕組みと、パッケージか自治体カスタムかの判断基準
• 業務システムとは：種類・基幹システムとの違いと、開発・導入形態の選び方を整理
• 学務システムとは：大学・専門学校の履修・成績・学籍の機能範囲と導入判断