学校管理システムをやめる前に｜データ出力・保存期限・アクセス停止の設計

契約終了後に生徒データを出せない。出力できても、授業や請求との関係が分からない。学校管理システムの乗換えや利用終了は、解約日だけ決めると、後から必要な記録を取り出せなくなるおそれがあります。

学校管理システムの利用終了では、必要なデータと出力仕様を決め、受け取った内容を照合してから、担当者・連携・共有リンクのアクセスを停止する順序を設計します。 同時に、何をどの目的で保持するかを分類し、本人からの削除等の依頼や法令上の確認とは別の判断として扱います。出力済みは、保存・移行・削除が完了したという意味ではありません。

この記事で分かること

• 生徒一覧だけでは足りない出力範囲と仕様
• 出力データの時点、関連、件数を照合する方法
• 業務上の保持と削除依頼を分ける考え方
• 利用終了時のアクセス停止と受入試験の条件

本稿はシステムの要件・移行計画の整理です。表や件数、日程、役割は架空例であり、実在する製品の実装や実際の移行実績ではありません。一律の法定保存年数、削除期限、国をまたぐ法令適合を示すものではなく、実環境の出力・削除・権限停止も実施していません。

1. 利用終了前に何を取り出す必要がある？

「全件出力」の対象はどこまでか？

生徒一覧を取り出せても、その生徒がどの授業を受け、どの請求と入金が対応するかが分からなければ、引継ぎには不足する場合があります。先に必要な業務を挙げ、その業務を再開・照会するための情報を並べます。画面ごとの出力ボタンを探すのは、その後です。

利用終了にも複数の目的があります。別のシステムへ移す、過去分だけ保管する、学校の拠点を統合するなどです。移行先で操作を続ける情報と、過去の照会にだけ使う情報では、必要な形式や精度が変わります。全部を同じファイルへ入れる前提で考えないようにします。

表は横にスクロールして比較できます。

一覧から外れる情報も確認します。学校独自の追加項目、連携先でしか持たない取引記録、画像として保存された資料などです。出力対象外を明記しておけば、提供会社へ追加方法を尋ねるか、学校側で別の引継ぎ方法を用意するかを決められます。

取り出す情報を必要な範囲へ絞る

「全部出しておけば安心」とすると、移行先で不要な健康情報や家族情報まで複製する可能性があります。何のために使うか、誰が使うかが説明できる項目を選び、移行用と照会保管用で対象を分ける方法を検討します。

不要な情報を増やさないという判断と、必要な記録を勝手に削る判断は別です。担当者が列を見て不要と推測するのではなく、業務責任者が用途を確認します。国や学校の形態、契約によって必要条件が変わるため、法律上の要件は該当する専門家や公的資料で別に確認してください。

コード表や項目定義も出力物の一部として扱います。「状態二」「区分B」だけが残ると、将来の担当者には意味が分かりません。項目名、値の意味、関連する識別番号、日付の基準などを、個人情報を含まない仕様書として添えます。

引継ぎ先と責任の境界を決める

提供会社がファイルを用意するまでか、学校が受領して読めることを確認するまでか、移行先で検証するまでか。終了の範囲を分けて責任者を置きます。「送ったので完了」と「使えるので受領した」が食い違わないよう、受入条件を先に合意してください。

学校側が出力を実行できない製品なら、依頼窓口、受付条件、対象、納期、費用の有無を契約に照らして確認します。本稿では追加費用の額や一般的な相場を示しません。出力を依頼してから初めて制約に気付くことを避けるため、利用終了日より前に確認する設計が必要です。

2. 出力したデータを後で読める仕様にするには？

CSV、帳票、添付を同じ役割で扱わない

CSVは表形式での移行や照合に使いやすい一方、見た目の再現には向きません。PDFなどの帳票は当時の表示を確認しやすくても、関係するデータを検索・集計するには別の情報が必要な場合があります。添付はファイル本体と、どの記録に属するかの対応が必要です。

表は横にスクロールして比較できます。

形式を増やせば十分という話ではありません。誰がどの用途で使うかを決め、必要な組合せを選びます。同じ情報を複数形式で持つなら、どちらが照会の基準で、どの時点のものかも明記します。

文字コードと値の型を明示する

日本語だけでなく、多国籍の生徒名や連絡内容を扱う学校では、出力先で文字が読めるかが重要です。文字コードを明示し、実際に必要な文字を含む試験データで確認します。画面で読めたから出力先でも読める、とは限りません。

識別番号や電話番号を数値として開くと、先頭のゼロが消えたり、桁の長い番号が変わったりする場合があります。値の型を仕様として定め、受け取る側でも文字列として扱う必要がある列を確認します。日付、日時、時間帯、金額、通貨も同様です。

PostgreSQLのCOPY文は、出力形式、文字コード、見出し、区切り、空値などを指定する仕組みを持ちます。これはデータの出力には明示する条件があるという技術的な参考で、学校製品が同じ操作を提供するという意味ではありません。PostgreSQL：COPY

空欄と未設定も区別します。連絡先を意図的に空文字として登録した状態と、まだ確認していない状態を分ける必要があるなら、出力で失われない方法が必要です。受け手が勝手に空欄を埋めたり、ゼロへ変換したりしないよう、例を添えて確認します。

出力する権限と持ち出す目的を結び付ける

通常画面で一人の生徒を閲覧できることと、全校分をまとめて取り出せることは違います。出力の対象期間、拠点、項目を指定できるようにし、その範囲を許可された担当だけが実行・受領できる設計を確認します。小さな一覧を何度も取得して全体を持ち出す経路も、必要に応じて評価対象にします。

出力を依頼した事実は、実際の個人情報そのものと分けて記録します。依頼者、目的、対象条件、作成結果、受領者が追えれば、ファイルの中身をログへ複製せずに確認できます。失敗した出力にも同じ番号を付け、再依頼と元の依頼の関係が分かるようにします。

識別番号を保ち、関係を復元できるようにする

生徒ファイルと授業ファイルを別々に出すなら、同じ生徒を識別する番号が両方で対応している必要があります。出力するたびに番号を振り直す場合は、ファイル間で対応する仕組みが必要です。氏名だけの照合では、同姓同名や表記の違いを扱いきれません。

添付ファイルの名前にも個人情報を不用意に含めず、一覧に識別番号と関係を持たせる方法が考えられます。一方、匿名の名前へ置き換えただけでは、本体の内容まで匿名化されたことにはなりません。匿名化という言葉は、単なるファイル名変更や番号への置換と分けて使います。

出力データを表計算ソフトで確認する場合は、入力された文字列を式として解釈しない方法も検討します。読みやすさのためにデータそのものを変えると、移行用の元の値を失うおそれがあります。閲覧用と移行用を分ける場合も、変更内容と変換規則を残し、元の意味が保たれるかを確認してください。

3. 出力時点と内容はどう照合すればよい？

複数ファイルを別時刻に出すと何が起こる？

生徒一覧を出した後に授業が追加され、次に出した授業ファイルには新しい生徒が含まれたとします。ファイル単体では正常でも、相互の関係が揃わない可能性があります。どの時点の状態として一式を出すか、出力中の更新をどう扱うかを決めます。

方法には、確定した一時点の状態を使う、更新を一時停止して出す、最初の出力後の差分を別に反映する、といった選択肢があります。製品で可能な方式を確認し、止める業務と時間を学校側が判断します。単に「最新データ」とだけ依頼すると、何が最新かが揃いません。

PostgreSQLのトランザクション分離に関する資料は、並行更新の下で読み取る状態が分離レベルによって異なることを説明しています。複数の出力を一つの整合した時点として扱えるかは、実装側に確認する条件です。PostgreSQL：Transaction Isolation

一覧と照合表を一緒に受け取る

出力物には、作成日時、対象範囲、件数、ファイル一覧、対象外、処理結果をまとめた受領用の一覧を添えます。大きな出力を分割する場合は、どの分割が揃えば全体になるかを明記し、一部だけ届いた状態を完了扱いにしないようにします。

表は横にスクロールして比較できます。

ハッシュ値を使うと、受け取ったファイルが作成元のファイルと同じかを確かめる助けになります。ただし、同じ内容であることと、出力対象が正しいことは別です。必要な列が欠けているファイルでも、ハッシュ値は一致し得ます。内容と同一性を別の検査として扱います。

途中で出力が止まり再開する場合は、同じ行が重複したり、一部が抜けたりしないかも確認します。分割したファイルには対象範囲を付け、再開前後で出力時点が変わっていないかを照合します。処理の完了通知だけでなく、一式に含まれる分割の一覧と件数を受領条件にすれば、途中までのファイルを完成版と取り違えにくくなります。

件数が合っても関係が違えば受け入れない

架空の生徒三人、授業五件、請求二件を使う試験なら、件数の一致に加え、それぞれの請求が正しい生徒へ対応するかを確認します。取消授業が通常授業に変わっていないか、添付を開けるかなど、数字だけに表れない状態も期待値として残します。

移行先で一部を変換する場合は、変換前後の対応表を用意します。旧システムの状態を新システムのどの状態へ置き換えたか、引き継がない項目は何かを説明できるようにします。変換できない値を空欄にして処理を続けるなら、その件数と対象を必ず確認対象へ残します。

出力後も旧システムで受付を続ける場合は、差分の対象期間と更新項目を固定します。古い一式をもう一度全部読み込むと、新しい側で行った修正を消す可能性があります。何を最終データとするか、いつ以降はどちらへ入力するかを切替計画として合意してください。

4. 保存期間と削除の依頼はどう分けて判断する？

業務上の保持を目的別に分ける

退会したらすべて消す、またはすべて永久に残すという二択では、必要な判断が抜けます。未精算の取引を確認する記録、受講履歴の照会用記録、連絡のために使う情報など、用途ごとに必要性と閲覧できる担当を分けます。

学校側の保持台帳には、情報の分類、目的、保持を始める基準、見直す時点、閲覧範囲、保管先、処理を判断する人を書きます。年数だけが決まっていても、契約日からか、退会日からか、最後の取引からかが曖昧なら運用できません。

表は横にスクロールして比較できます。

英国ICOの保存制限に関する説明も、目的に応じた保持と、情報の種類ごとの方針を扱っています。これは英国制度の公式説明であり、すべての学校に同じ制度や期限が適用されるという意味ではありません。参照ページは改訂検討中の注記があるため、具体的な制度判断では最新の資料を確認します。ICO：Storage limitation

退会・アカウント停止・削除は同じ処理か？

退会は在籍の状態、アカウント停止は利用権限、データ削除は記録の保持状態に関する操作です。互いに関連していても、同じ操作として一括処理する必要があるとは限りません。退会者がログインできなくても、学校が必要な範囲の取引を照会する状態はあり得ます。

反対に、記録を保持する必要があるからといって、退会者のアカウントや以前の講師のアクセスを残す理由にはなりません。利用停止と保持を分ければ、必要な記録を保護しながら、日常の利用範囲を狭める設計ができます。

匿名化と仮名化も区別します。番号へ置き換えても、対応表や他の情報から個人を結び付けられるなら、単純に「個人情報ではなくなった」とは扱えません。どこまで情報を残すかと、どのような性質になるかは、専門的な判断が必要な場合があります。

本人からの依頼は受付と判断を分けて追跡する

本人から出力や訂正・削除等の依頼があった場合、通常の利用終了データの出力とは別に扱います。本人確認、依頼範囲、対象データ、適用される制度、保持が必要な事情、回答する担当を確認します。学校の都合だけで依頼を放置したり、画面から見えなくしただけで削除完了と答えたりしないようにします。

本稿では、依頼へ応じるべきか、どの期間内に何を行うかを一律には示しません。学校の所在地、対象者、契約関係、情報の種類などで確認事項が変わるためです。システムには、受け付けた依頼と判断、実施した処理、未完了の範囲を記録できる条件を求めます。

検索対象から外した記録、外部連携へ渡った記録、バックアップ、出力済みコピーは、同じ場所の同じ操作で処理できるとは限りません。削除等の判断が決まった後に、対象となる保管先へどう反映し、何を証拠として残すかを確認します。仕様が分からないまま「全域から即時削除」と約束しないことが重要です。

5. 利用終了時にどのアクセスを停止すればよい？

アカウント名だけでは停止範囲を把握できない

利用者のアカウントを無効化しても、すでにログインしている端末、外部連携の認証情報、共有リンク、予約された出力処理が残る場合があります。人の利用権限と、システム同士の連携やファイルのアクセスを分けて棚卸しします。

表は横にスクロールして比較できます。

OWASPは、アクセス権を要求ごとに確認することを勧めています。出力要求の開始時だけ確認し、作成後のファイルは誰でもURLから取れる設計では、権限停止の効果が届かない場合があります。OWASP：Authorization Cheat Sheet

長時間の出力中に権限が変わったら？

大量のデータを準備する処理では、開始から完成までの間に担当者の権限が変わるかもしれません。出力を作る処理の条件と、完成ファイルを受け取る条件を分け、停止済みの利用者が後から取得できないかを確認します。

同じ利用者でも、学校全体の管理権限から一拠点だけの権限へ変わった場合は、出力対象も見直す必要があります。古い広い権限で作られたファイルを、そのまま新しい権限で受け取れてよいかを判断します。ファイルへ含まれる対象の情報を、要求時の条件として記録しておく方法が考えられます。

ログアウトや画面を閉じる操作だけでは、サーバー側の利用状態が無効になったと断定できません。OWASPのセッション管理資料は、サーバー側での失効や、ブラウザーを閉じる操作の限界を説明しています。OWASP：Session Management Cheat Sheet

出力の検収とアクセス停止の順序を決める

利用終了日になったら先に全員を止める方式では、必要な出力を確認する担当までアクセスできなくなる可能性があります。一方、確認のために全員の権限を残す必要もありません。業務入力を止める、限定した担当が照合する、受領を確定する、残りのアクセスを止める、と役割を分けます。

期限までに検収が終わらない場合の窓口と対応条件も決めます。通常利用の延長、限定された照会、提供会社による再出力は別の対応です。契約で可能かを事前に確認し、終了日に初めて相談する状態を避けます。

出力済みファイルを受け取った後は、そのコピーの管理も学校の作業になります。共有フォルダへ置いたまま退職者が閲覧できる、外部へ送ったリンクが無期限、といった状態が残らないよう、保管先の責任者と閲覧者を確認します。旧システムの停止だけで、すでに配布したコピーが消えるわけではありません。

6. どんな試験と記録があれば利用終了を判断できる？

出力の受入と停止の受入を別々に行う

データが使えることと、以前の利用者が使えないことは別の合格条件です。前者は移行・保管のための確認、後者はアクセスの終了の確認です。片方が通ったことを理由に、両方を完了扱いにしないようにします。

以下は提供会社と実施を検討する試験案です。実環境で実行した記録ではありません。試験用のデータ、アカウント、保管先を使い、本番のデータ削除や権限停止を独断で行う手順にはしません。

表は横にスクロールして比較できます。

受け渡し用の一時コピーも管理対象にする

出力の準備や移行試験で、作業端末、受け渡し用フォルダ、変換処理の出力先へコピーが作られることがあります。本体の受領が終わっても、一時コピーが自動的に片付くとは限りません。作成目的、所在、利用者、終了条件を確認し、保持方針に沿って処理する対象へ含めます。

受け渡し先を間違えた場合や、意図した範囲より広い内容が入った場合は、通常の検収を続ける前に定めた窓口へ連絡する条件を置きます。別のファイルを送り直すだけで、最初に渡ったコピーの扱いまで解決したとは言えません。試験では架空データを使い、誤った対象範囲を検知して停止できるかを確認します。

一部が対象外なら残件として閉じる

出力できない添付、仕様が不明なコード、未精算の記録などが残った場合は、対象、理由、担当、次の対応を残します。「ほぼ全部取れた」という表現では、終了後に不足が分かったときの判断ができません。

保持が必要な記録を旧サービス側で残す場合も、誰がどの条件で照会できるか、通常利用とは何が違うかを確認します。学校側のコピーと提供会社側のコピーについて、保持・削除・照会の責任が混ざらないようにします。実施した処理の範囲が分かる確認記録を受け取ることも検討してください。

終了の記録には、出力の版、対象期間、受領したファイル一覧とハッシュ、内容確認者、未完了、権限停止の結果、連携の停止状況をまとめます。秘密情報や生徒の情報そのものを台帳へ貼り付けず、保護された保管物を特定できる形にします。

受領に不備があって再出力した場合は、版を区別します。新しい一式が旧版を置き換えるのか、差分だけを追加するのかを一覧に書き、どちらを移行や照会の基準に使うかを確認してください。

導入前から終了条件を確認する

• ☐ 出力対象と対象外、形式、項目定義を確認できる
• ☐ ファイル同士の識別番号と時点が揃う
• ☐ 出力費用・期限・窓口を契約に照らして確認した
• ☐ 移行用と照会保管用を分け、必要な項目を決めた
• ☐ 保持目的、見直し、法令確認の担当を決めた
• ☐ 本人からの依頼を別の判断として管理できる
• ☐ 既存セッション、連携、リンク、定期処理を停止できる
• ☐ 出力検収とアクセス停止に別の合格条件がある

導入時に出口を確認することは、すぐ解約するためではありません。学校の記録をどの形式で扱い、必要なときに取り出せるかを明らかにするためです。長く使う場合も、データの所在と責任が分かる状態は引継ぎに役立ちます。

学校管理のデータや利用終了条件を整理したい場合は、個人情報を含まない項目一覧と、出力後に行いたい業務を添えてタゲンゴへ相談することができます。実際の生徒ファイル、請求記録、認証情報を最初の相談へ送らず、必要な範囲を言葉で整理するところから始めましょう。

よくある質問

CSVを出せれば別システムへ移行できますか？

必ず移行できるとは限りません。項目の意味、識別番号の関係、日付や状態の対応、添付の扱いが必要です。移行先の仕様と照合し、変換できない情報を明確にしたうえで受入試験を行います。

退会者のデータは何年残せばよいですか？

本稿では一律の年数を示しません。用途、情報の種類、契約、適用される制度によって確認事項が変わります。保持の目的と起算点、見直す条件を分類し、法令上の要件は該当する専門家や公的資料で確認してください。

アカウントを無効にすれば出力ファイルも見られなくなりますか？

仕組み次第です。共有リンク、出力済みコピー、外部連携、ログイン済みセッションは別の経路になり得ます。それぞれの期限と権限確認を点検し、停止後のアクセスを試験条件として確認します。

出力を受け取ったら旧サービスのデータをすぐ削除してよいですか？

受領だけで判断しないでください。内容の照合、移行先の検収、保持が必要な記録、本人からの依頼、契約上・法令上の条件を確認します。削除の範囲と承認、実施後の証拠を別の作業として定めます。

関連記事

• 出力を実行・受領できる担当の設計は、学校管理システムの役割・権限設計を参照してください。
• データを別システムへ取り込む前の検証は、CSV取込プレビューの確認と区別して進めます。

出典・確認日

公式照合日：2026年10月27日。PostgreSQL 18：COPY、Transaction Isolation、OWASP：Authorization、Session Management、英国ICO：Storage limitationを参照。表・要件・試験は編集上の提案です。実製品の実装、実際の移行、削除、法令適合の監査は未実施です。

執筆・運営：タゲンゴ