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

1. 教育データの利活用で何が前提になるのか

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

利活用と安全性は、どちらかだけでは成立しない

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

設計レビューで安全管理の話が後回しになりやすい現場ほど、この前提を先に共有しておくと手戻りが減ります。機能要件よりも、両立という前提のほうが、あとの判断に効いてきます。

資料は原則ではなく、場面から書かれている

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

この作りは、事業者にとってもかえって読みやすさにつながります。自社の開発フローに置き換えながら読み進めれば、どこで何を確認するかが具体的に見えてきます。

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

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

体制図は一度描いて終わりにせず、機能追加のたびに見直す対象にします。前提を資料の中だけに留めず、日々の設計判断に持ち込む工夫のほうが、あとの差し戻しを減らします。

体制図があれば、初めて案件に参画するメンバーへの引き継ぎも早くなります。誰が何を担当しているかを口頭で説明し直す手間が減り、途中からの合流でも前提を共有しやすくなります。

教育データの利活用と安全・安心の両立という前提が分かると、次に気になるのは「その前提は誰に対して、どう適用されるのか」という点です。ここから先は、対象となる学校の種類によって条件が枝分かれしていきます。

2. なぜ3つの版に分かれているのか

留意事項の対象は、公立・私立・国立の学校の教職員や教育委員会の職員などです²。3つの学校種が並んで出てくる時点で、事業者側は「どれか1つに合わせればいい」とは考えにくくなります。

私立と国立では、適用される条文が違う

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

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

版が分かれること自体が、設計のヒントになる

3つの版が並んでいるのは、それだけ学校種による違いが実務に影響する証拠でもあります⁴。1つの版だけを読んで全体を理解したつもりになると、契約する学校種が変わったときに前提が崩れます。

複数の学校種を相手にする事業者ほど、最初の段階で「今回はどの版が根拠になるか」を確認する工程を持っておくと、後工程での差し戻しを避けやすくなります。営業段階で相手の学校種を聞き取っておくだけでも、開発の見積り精度は変わります。

学校種による違いの整理

条文の内容そのものには立ち入らず、設計の観点から意識しておきたい違いだけを整理すると、次のようになります。

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

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

学校種によって適用される規律が変わるという前提を押さえたら、次に整理したいのは事業者と学校の関係そのものです。ここでの関係の結び方が、以降のすべての設計判断の土台になります。

3. 事業者と学校は「委託」の関係になる

民間の学習用ソフトウェアを学校が導入する場合、個人情報の取扱いを事業者に委託する形が一般的であり、望ましい進め方だと整理されています⁵。この一言で、事業者の立場は単なる納入先ではなく、委託を受ける当事者になります。

委託を受ける側にも、安全管理の要件が来る

個人情報の取扱いを外部に委託する場合、委託先には安全管理措置を講じる義務が生じます⁶。ソフトウェアを作る側は、機能の納品だけでなく、この義務を引き受ける当事者になります。

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

選ぶ側は、選定の基準を持っている

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

価格や機能の比較だけでなく、安全管理の体制そのものが選定の材料になります。機能の作り込みよりも、管理体制を説明できることのほうが、選定の場面では効いてきます。

契約書に落とし込む視点を持つ

口頭やメールでの合意だけでなく、安全管理措置の内容を契約書の条項に落とし込んでおくと、あとから行き違いが起きにくくなります。委託を受ける側から具体的な条項案を示す姿勢のほうが、選定の場面でも好印象につながります。

契約書に書く内容は、機能仕様書と対で作ると整合が取りやすくなります。仕様書だけを先に固めるよりも、契約条項と仕様書を同時に育てていくほうが、後工程での矛盾を防げます。

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

4. 預かる範囲は機能から逆算する

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

機能を先に広げると、範囲の説明が難しくなる

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

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

機能と業務内容の対応関係を先に整理する

機能ごとに、それが支える業務内容は何かを言語化しておくと、預かる個人情報の範囲も自然に絞られていきます。次の表は、その整理の考え方をイメージとして示したものです。

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

逆算の順番を、要件定義の1つの工程として組み込むと運用しやすくなります。機能一覧よりも、業務内容の一覧を先に作るという順番のほうが、あとの説明力につながります。

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

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

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

範囲を決める考え方が分かったところで、次に注意したいのは、決めた目的をあとから広げられるかという点です。ここは委託の設計だけでなく、運用開始後にも関わってきます。

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

利用目的をあとから変更する場合、変更前の目的と相当の関連性があると合理的に認められる範囲を超えることはできません⁹。この一文は、運用開始後の仕様変更に直接効いてきます。

「ついでに集める」発想が使えない

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

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

目的の書き方が、後の自由度を左右する

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

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

目的は機能ごとに分けて書く

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

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

目的を後から広げられないという制約が分かると、次に気になるのは同意そのものの取り方です。同意の相手は、実は1つに決まっていません。

6. 同意の相手が2通りになる

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

発達段階によって、同意の設計が変わる

同じ学年でも、対象の児童生徒が同意の内容を理解できるかどうかで、取得する相手が変わります¹⁰。この分岐を、画面側の分岐としてあらかじめ組み込んでおく必要があります。

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

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

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

分岐を後付けにすると、手戻りが大きい

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

機能の見た目よりも、この分岐を前提にした設計のほうが、あとの開発コストに効いてきます。次の表は、同意の相手による違いを整理したものです。

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

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

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

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

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

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

本人や保護者は、開示、訂正、利用停止の請求を行うことができます¹¹。事業者側のシステムには、この請求に応える処理があらかじめ組み込まれている必要があります。

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

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

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

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

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

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

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

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

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

ここまでの前提と仕組みを踏まえると、教育データを扱う案件は、機能を作るだけの仕事ではないと見えてきます。立場を読み、範囲を逆算し、続ける仕組みまで設計する経験は、教育分野に限らず評価されやすい経験になります。案件の90%以上がフルリモート可能です。自分の経験がこうした案件でどう活きるかを確かめたい場合、まずは案件情報を見て、条件を確認するところから始められます。

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

いいえ、この記事で扱っているのは学校の運営そのものではなく、学習用ソフトウェアを作って納める事業者側の設計です。留意事項が求めているのは、事業者が委託を受ける立場として満たす条件です⁵。委託を受ける以上、安全管理の要件も引き受けることになります⁶。

公立・私立・国立のどれか1つの版だけ読めば十分ですか

十分とは言えません。私立・国立の学校では、公立とは適用される条文が異なるため⁴、契約する学校種が変われば確認し直す前提になります。複数の学校種を相手にする事業者ほど、この確認を工程として持っておくと安心です。

この分野の経験は、他の案件でも活きますか

はい。立場を読み分ける視点や、範囲を機能から逆算する考え方、続ける仕組みまで設計する経験は、教育分野に限らず個人情報を扱う案件全般で活きます。自分の経験がどの案件に近いかを確かめたい場合、まずは案件情報を見て条件を確認してみましょう。

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

出典・参考情報

＊1 文部科学省「教育データの利活用に係る留意事項」前提の置き方（2026年4月）
＊2 文部科学省「教育データの利活用に係る留意事項」読み手の広さ（2026年4月）
＊3 文部科学省「教育データの利活用に係る留意事項」資料の作り（2026年4月）
＊4 文部科学省「教育データの利活用に係る留意事項」版が分かれる理由（2026年4月）
＊5 文部科学省「教育データの利活用に係る留意事項」関係の形（2026年4月）
＊6 文部科学省「教育データの利活用に係る留意事項」委託先の義務（2026年4月）
＊7 文部科学省「教育データの利活用に係る留意事項」選ばれる側の条件（2026年4月）
＊8 文部科学省「教育データの利活用に係る留意事項」範囲の決め方（2026年4月）
＊9 文部科学省「教育データの利活用に係る留意事項」目的変更の限界（2026年4月）
＊10 文部科学省「教育データの利活用に係る留意事項」同意の相手（2026年4月）
＊11 文部科学省「教育データの利活用に係る留意事項」請求への対応（2026年4月）
＊12 文部科学省「教育データの利活用に係る留意事項」正確性の維持（2026年4月）
＊13 文部科学省「教育データの利活用に係る留意事項」保存期間（2026年4月）
＊14 文部科学省「教育データの利活用に係る留意事項」措置の分類（2026年4月）
＊15 文部科学省「教育データの利活用に係る留意事項」実装に落ちる措置（2026年4月）
＊16 文部科学省「教育データの利活用に係る留意事項」置き場所の把握（2026年4月）
＊17 文部科学省「教育データの利活用に係る留意事項」続ける仕組み（2026年4月）