学校向けのソフトウェアを設計するとき、最初につまずくのは機能の作り込みではなく、目の前のデータが誰のものかという整理です。個人情報を扱うとは分かっていても、公立と私立で扱いが変わる点や、同意を取る相手が児童生徒の発達段階で変わる点まで踏み込むと、一気に考える範囲が広がります。文部科学省が公表した留意事項には、教育データの利活用と安全・安心の両立を前提に、事業者に求められる条件がひとつずつ整理されています¹。この記事では、その内容を設計の手前でつまずかないための地図として読み解きます。

1. 教育データの利活用で前提になること

教育データの利活用に係る留意事項は、データの活用を止めるための資料ではありません。利活用と安全・安心の両立が実現されることが重要だという立て付けから始まっています¹。設計の起点を一方に寄せないことが、この資料の出発点です。

利活用と安全性、どちらか一方では成り立たない前提

機能を先に決めて、あとから安全管理の要件を足す進め方もあります。ですが留意事項が示しているのは逆の順番で、両立を前提に置いてから機能を組み立てる考え方です¹。

設計レビューで安全管理の話を後回しにしている現場では、この前提を先に共有しておくと、機能要件と安全管理の要件を同じ場で議論できます。両立という前提を、機能要件より先に置く順番です。

原則ではなく場面から書かれた資料

留意事項には、実際にデータを取り扱う場面を想定した手順や事例が盛り込まれています¹。抽象的な原則の羅列ではなく、現場で起きる場面を起点に組み立てられている資料です。

この作りは、自社の開発フローに置き換えて読めます。どこで何を確かめるかを、場面に沿って具体的にたどる読み方ができます。

最初の一手は、体制図を描くことから

留意事項を読み終えたら、次に手を動かしたいのは自社の開発体制を図にすることです。誰が個人情報に触れる機能を担当するかを可視化すると、両立という前提がどこで実装に落ちるかが見えてきます。

体制図は一度描いて終わりにせず、機能追加のたびに見直します。前提を資料の中だけに留めず、日々の設計判断に持ち込むための手段です。

体制図があれば、初めて案件に参画するメンバーへの引き継ぎにも使えます。誰が何を担当しているかを口頭で説明し直す手間が減ります。

両立という前提が分かると、次に気になるのは、その前提が誰にどう適用されるのかです。ここから先は、対象となる学校の種類によって条件が枝分かれします。

2. 公立・私立・国立で異なる適用条文

留意事項の対象は、公立・私立・国立の学校の教職員や教育委員会の職員などです¹。3つの学校種が並んで出てくる以上、事業者側は一つの学校種だけを前提にはできません。

私立と国立で異なる適用条文

私立・国立の学校では、適用される条文が公立とは異なります¹。同じ機能を持つソフトウェアを納める場合でも、相手の学校種によって根拠となる規律が変わります。

条文の中身に立ち入らなくても、この事実だけで設計判断は変わります。学校種ごとに一つの仕様で押し通す発想より、学校種の違いを前提にした設計のほうが、説明の筋が通ります。

学校種の違いを前提にした確認工程

学校種によって適用条文が異なるため、一つの学校種だけを読んで全体を理解したつもりになると、契約先の学校種が変わったときに前提が崩れます¹。

複数の学校種を相手にする事業者は、最初の段階で「今回はどの学校種の条文が根拠になるか」を確かめる工程を持つとよいでしょう。営業段階で相手の学校種を聞き取るだけでも、開発の見積りの前提がそろいます。

学校種による違いの整理

適用条文の違いを軸に、対象になる主体と設計側の確認点を学校種ごとに並べています。公立を基準にすると、私立と国立は適用条文が異なる構図です。

学校種	対象になる主体	適用条文	設計側の確認点
公立学校	教職員・教育委員会の職員等	私立・国立とは異なる	委託先選定や安全管理の要件を確認する
私立学校	教職員等	公立とは異なる	適用条文の違いを踏まえて個別に確認する
国立学校	教職員等	公立とは異なる	契約先ごとに前提を確認し直す

図の作成：Remogu編集部。留意事項の対象となる学校種の違いを整理したもので、統計データではありません

学校種による違いを押さえたら、次に整理したいのは事業者と学校の関係です。この関係の結び方が、以降の設計判断の土台になります。

3. 事業者と学校の「委託」関係

民間の学習用ソフトウェアを導入する場合、個人情報の取扱いを委託することが一般的であり、望ましいと考えられています¹。この関係では、事業者は単なる納入先ではなく、委託を受ける当事者です。

委託を受ける側に及ぶ安全管理の要件

個人情報の取扱いに係る業務を外部に委託する場合には、安全管理措置を講ずる必要があります¹。ソフトウェアを作る側は、機能の納品に加えて、この要件を引き受ける当事者になります。

契約段階でこの点を後回しにすると、納品直前になって安全管理の体制を急いで整えることになりかねません。要件を先に引き受けておけば、開発の見積りにも織り込めます。

選ぶ側が持つ選定の基準

学校側には、適切な管理を行える委託先を選べるよう、選定基準を整備することが挙げられています¹。つまり事業者は、この基準に照らして見られる立場にあります。

価格や機能の比較だけでなく、安全管理の体制そのものが選定の材料になります。管理体制を説明できるかどうかが、選定の場面で問われます。

契約書に落とし込む視点

口頭やメールでの合意だけでなく、安全管理措置の内容を契約書の条項に落とし込んでおくと、行き違いを防げます。委託を受ける側から具体的な条項案を示す進め方もあります。

契約書に書く内容は、機能仕様書と対で作ると整合を取れます。仕様書だけを先に固めず、契約条項と仕様書を同時に育てていけば、後工程で矛盾が出にくい進め方です。

委託の関係になった時点で、次に問われるのは、どこまでの個人情報を預かるかという範囲です。機能の設計と直結する部分なので、次の章で具体的に見ていきます。

4. 預かる範囲を機能から逆算する考え方

取扱いを委託する個人情報の範囲は、委託する業務内容に照らして必要最小限にすることが求められています¹。範囲を決める軸は、機能ではなく業務内容です。

機能を先に広げたときの、範囲の説明の難しさ

便利さを優先して収集項目を増やしていくと、あとから「なぜこの項目が必要か」を業務内容に照らして説明しづらくなります¹。範囲は、機能の都合ではなく業務内容から逆算します。

設計の初期段階で、この機能にはどの個人情報が必要最小限で足りるかを先に決めておくと、後工程での項目追加や見直しが減ります。

機能と業務内容の対応関係

機能ごとに、それが支える業務内容を文書に書き出しておくと、預かる個人情報の範囲も絞られていきます。出欠管理なら氏名と出欠の記録、連絡機能なら氏名と連絡先情報、というように対応させる考え方です。

機能の例	想定される業務内容	委託範囲として説明しやすい項目
出欠管理機能	出欠の記録と集計	氏名・出欠に関する記録
学習記録の閲覧機能	学習状況の把握	氏名・学習の記録
連絡機能	保護者との連絡	氏名・連絡先情報

逆算の順番は、要件定義の工程の一つとして組み込みます。機能一覧より先に、業務内容の一覧を作る順番です。

この順番なら、範囲を尋ねられたときに「この機能に必要だから」ではなく「この業務に必要だから」と答えられます。後者の答えのほうが、選定の場面でも筋が通ります。

業務内容の一覧は、開発の初期に一度作れば終わりではありません。機能を追加するたびに一覧へ戻り、新しい項目が必要最小限に収まっているかを確かめる運用にすると、範囲が少しずつ広がる事態を防げます。

図の作成：Remogu編集部。委託範囲の考え方を整理したもので、統計データではありません

預かる範囲の決め方が分かったところで、次は、決めた目的をあとから広げられるかです。運用開始後にも関わる点です。

5. 後から広げられない利用目的

利用目的を変更する場合は、変更前と相当の関連性があると合理的に認められる範囲を超えてはいけません¹。運用開始後の仕様変更にも、この制約が及びます。

「ついでに集める」発想の限界

リリース後に新しい分析機能を足し、既存の個人情報を新しい目的にも使う場合でも、目的の変更には関連性の範囲という制約が先にあります¹。

この制約を知らずに機能追加を進めると、あとから利用目的の見直しや再確認が必要になり、開発スケジュールに響きます。

目的の書き方と、後の自由度

最初に利用目的をどう書くかによって、あとで許容される範囲の広さが変わります。狭すぎる目的より、想定される業務の幅を見渡した書き方のほうが、後の変更の余地が残ります。

とはいえ、範囲を広げすぎた目的は説明力を失います。業務内容に照らした妥当な広さを、事業者側から学校側に提案する関係が理想です。

機能ごとに分けた目的の書き方

一つのソフトウェアが複数の機能を持つ場合、機能ごとに利用目的を分けて書いておくと、一つの機能だけを切り出すときにも目的を整理できます。目的を一文にまとめすぎると、あとの見直しがかえって難しくなります。

目的の見直しが必要になったら、新しい目的を足す前に、まず既存の目的の範囲内で対応できないかを確かめる順番が安全です。範囲を超えると分かった時点で、目的の変更を検討します。

目的を後から広げられないと分かったら、次は同意の取り方です。同意の相手は、一人に決まっていません。

6. 2通りに分かれる同意の相手

同意は、児童生徒本人が理解できる場合は本人から、理解できない場合は保護者から取得するのが基本です¹。同意の画面や説明文を一種類だけ用意すればよいわけではありません。

発達段階による同意の設計の違い

同意の内容を対象の児童生徒が理解できるかどうかで、取得する相手が変わります¹。この分岐は、画面側の分岐としてあらかじめ組み込む前提になります。

本人向けの説明と、保護者向けの説明では、伝える言葉の難易度も変わります。同じ文面を両方に使い回すより、相手に合わせた二種類の文面を用意するほうが、運用が安定します。

同意の取得画面をどちらか一方だけで作り、あとから分岐を足す進め方は、データベースの持ち方まで直す事態につながります。最初から二通りの相手を前提にした画面設計のほうが、開発の総量は小さく済みます。

本人と保護者のどちらが同意したかという記録は、あとから開示請求に応じるときの根拠になります。同意画面の見た目だけでなく、誰がいつ同意したかを残す仕組みまで含めて設計します。

分岐の後付けで大きくなる手戻り

同意の相手が二通りになるという前提に、要件定義の後半で気づくと、画面設計やデータの持ち方にまで手戻りが及びます。設計の初期段階で分岐を織り込んでおけば、修正の範囲は小さく済みます。

対象が同意の内容を理解できるかどうかで、同意の相手も、説明文も、システムでの扱いも変わります。この分岐を前提にした設計は、機能の見た目よりも、あとの開発コストを左右します。

対象	同意の相手	説明文の作り方	システムでの扱い
理解できる児童生徒	本人	本人が理解できる言葉で説明	本人向けの同意画面を用意
理解できない児童生徒	保護者	保護者向けの説明文を用意	保護者向けの同意画面を用意

図の作成：Remogu編集部。同意の相手が分かれる考え方を整理したもので、統計データではありません

同意の相手までを設計に織り込めたら、残るのは運用を続けていく仕組みです。開示の請求、情報の正確性、保存の期限まで含めて、最後に整理します。

7. 請求・正確性・保存期間と、続ける仕組み

運用が始まったあとも、事業者が支える仕組みは続きます。開示・訂正・利用停止の請求に応じる機能、記録の正確性を保つ仕組み、保存期間の管理などです。

開示・訂正・利用停止に応える機能

開示、訂正、利用停止の請求を行えます¹。事業者側のシステムは、この請求に適切に対応できる必要があります。

請求を受けてから個別に対応する仕組みより、あらかじめ機能として用意しておく仕組みのほうが、運用開始後の負担は小さくなります。

正確性と保存期間を支える仕組み

保管する個人情報は、過去または現在の事実と合致するように努めなければなりません¹。古い情報を放置しない更新の仕組みが、機能として求められます。

法令で保存期間が定められている情報は、その期間を設定する必要があります¹。保存期間を過ぎた情報を残し続けない仕組みも、設計に含める対象です。

作って終わりにしない安全管理措置

安全管理措置には、組織的な措置と従事者への教育が挙げられています¹。技術的な措置には、アクセス制御やアクセスする者の識別・認証が含まれます¹。

個人情報が外国で取り扱われる場合は、その外国の特定も措置に含まれます¹。海外のクラウド基盤を使う構成では、置き場所の把握を設計の段階から組み込む必要があります。

さらに、自己点検及び監査も措置に含まれます¹。安全管理は一度整えて終わりではなく、点検を続ける前提で運用に組み込みます。

図の作成：Remogu編集部。安全管理措置の項目を整理したもので、統計データではありません

冒頭の問いに戻ると、目の前のデータが誰のものかは、学校種、委託の関係、利用目的、同意の相手の順にたどると整理できます。立場を読み、範囲を機能から逆算し、運用を続ける仕組みまで設計する流れは、個人情報を扱う案件の設計全般で土台になります。

案件の90%以上がフルリモート可能です。自分の経験が教育分野のような案件でどう活きるかを確かめたいときは、案件情報を見て、条件を確かめるところから始めてみましょう。

8. よくある質問

教育データを扱う案件は、学校の運営に関わる仕事ですか

いいえ。ここで扱ったのは学校の運営そのものではなく、学習用ソフトウェアを作って納める事業者側の設計です。民間の学習用ソフトウェアでは、個人情報の取扱いを委託する形が一般的であり、望ましいと考えられています¹。

公立の学校向けの条文だけ押さえれば十分ですか

十分とは言えません。私立・国立の学校では、適用条文が異なるためです¹。契約する学校種が変われば、確かめ直す前提になります。

保存期間は、どのように決めればよいですか

法令で保存期間が定められている情報は、その期間を設定する必要があります¹。保管する個人情報は、過去または現在の事実と合致するように努めなければなりません¹。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 文部科学省「教育データの利活用に係る留意事項」前提の置き方（2026年4月・2026年10月確認）