教育DXの案件では、要件定義の早い段階で「どのデータを、どこまで持つか」を線引きすることになります。持てる項目を並べるだけでは、あとから扱いに困るデータまで抱え込んでしまうことがあります。文部科学省の留意事項は、公立学校の現場で実際に運用されている取組例を示しながら、実装で決めるべきことを整理しています。ここでは、権限設計・委託・契約という3つの切り口から、その要点を見ていきます。

1. 実装で決まるのは、何を持たないかです

目的が先にあり、データはその手段です

新しい学習支援システムを検討する打ち合わせでは、まずどんな項目を集められるかという話から始まりがちです。集められる項目を並べてから要件を組み立てると、使うかどうか分からない項目まで抱え込んでしまうことがあります。留意事項が示す出発点はこの順番とは逆です。データの利活用は、一人一人の力を最大限引き出すきめ細かい支援を可能にするための手段であり、技術やデータを利活用すること自体が目的化しないようにする必要があります¹。

要件定義の初期段階で「何を集められるか」ではなく「支援の目的は何か」から会話を始めると、後工程での手戻りを減らせます。集める項目の一覧から機能を積み上げる設計より、支援の目的から逆算して必要な項目を絞り込む設計のほうが、あとから項目を削る作業に追われにくくなります。会話の出発点を変えるだけで、後工程の項目定義書に書く内容も自然と絞られていきます。

持たない項目を選んだ取組例

実際の取組例では、ツールの利用に必要な児童の氏名やIDなどは登録した一方で、児童の電話番号はツールの利用に不要だったため登録しませんでした。登録できるかではなく、登録が必須ではない項目を利用目的に照らして検討する、という順番が示されています⁸。

この判断を実装に落とし込むなら、項目ごとに「この項目がないと、どの機能が成立しなくなるか」を確認する工程を、要件定義とデータベース設計の間に置くと効果的です。成立しなくなる機能が見つからない項目は、持たない候補として扱えます。持てる項目を先に決めてから削る設計より、持たない項目を先に洗い出しておく設計のほうが、あとから発生する削除対応や説明対応の量を抑えられます。この考え方は個人情報以外の項目にも当てはまります。ログや操作履歴のように運用上は便利に見える項目でも、支援の目的に結びつかないものは、収集する項目の一覧に加える前に一度立ち止まって検討する価値があります。この考え方は、次に説明する権限の設計にもそのままつながります。

この分かれ方を図にすると、次のようになります。

図の作成：Remogu編集部。取組例をもとに項目の分かれ目を整理したもので、統計データではありません

持たない項目を早い段階で決めておくメリットは、開発の初期だけにとどまりません。保有していない項目は、漏えいや誤操作が起きたときの影響範囲にも入りません。持つ項目を減らす設計は、事故が起きたときに説明しなければならない対象を、あらかじめ小さくしておく設計でもあります。

2. 見える範囲は、職ごとに分かれています

学級・学年・学校という単位がそのまま権限になります

権限をどう設計するかで迷う場面では、まず学校が普段どんな単位でクラスや学年を運営しているかを確認すると、設計の手がかりになります。ある取組例では、担任教師は担任しているクラスのデータ、専科教師等は授業を受け持つクラスのデータ、学年主任は学年全てのクラスのデータ、管理職は学校内の全てのデータを閲覧・編集できるように設定されています⁷。

この設定の特徴は、役職ごとに新しい権限の区分を作るのではなく、学校が既に持っている学級・学年・学校という組織の単位に、そのまま権限を重ねている点です。役職名から権限を設計するより、組織の単位から権限を設計するほうが、現場の教員にとって「自分が見られる範囲」を説明しやすくなります。権限テーブルを設計する際も、役職IDではなく所属する組織の単位をキーにしておくと、担当の入れ替わりや兼務が発生したときの変更が少なく済みます。

特別支援学級や複数教科を掛け持ちする教員のように、一人が複数の単位にまたがるケースも珍しくありません。役職に対して単位を1つだけひも付けるより、教員と単位の組み合わせを複数持てるテーブル構造にしておくほうが、学校ごとの体制の違いに対応しやすくなります。転入や転出でクラス編成が年度途中に変わることもあります。年度の切り替えだけでなく、学期の途中で発生する編成変更にも耐えられるよう、権限の見直しを手動の申請だけに頼らず、名簿データの更新と連動させておくと運用の負荷を抑えられます。

職	閲覧・編集できる範囲
担任教師	担任しているクラスのデータ
専科教師等	授業を受け持つクラスのデータ
学年主任	学年全てのクラスのデータ
管理職	学校内の全てのデータ

名簿システムと連携させる場合は、4つの区分をそのままロール名にするより、組織の単位と閲覧範囲の対応表を別に持たせておくと、区分が増えたときの改修が小さく済みます。

3. 登録と削除ができるのは管理職だけです

閲覧・編集と、登録・削除は別の権限です

閲覧・編集の範囲を役職ごとに分けたら、次に決めるのは操作の重さです。同じ取組例では、アカウントの登録や削除などの操作は管理職のみが実施できるように設定されています⁷。

閲覧や編集は日々の授業で使う操作である一方、登録や削除はデータそのものの存在を左右する操作です。権限の粒度を増やす場合、まず「見る・直す」権限と「作る・消す」権限を分けたうえで、後者を管理職に絞ることから始めると設計のリスクを抑えやすくなります。役職の数だけロールを用意するより、操作の重さで2段階に分けたロール設計のほうが、運用担当者にとって理解しやすい形になります。

管理職が交代する場面も想定しておく必要があります。管理職という役職に権限をひも付けるだけでなく、誰が現在の管理職として登録されているかを確認できる仕組みにしておくと、権限の空白期間が生まれにくくなります。登録・削除の操作ログを残しておくことも、管理職だけに権限を絞る設計と相性が良い工夫です。操作できる人を絞るほど、ログを確認する対象も絞られるため、あとから経緯を追う作業がしやすくなります。

できることの範囲を図にすると、次のようになります。

図の作成：Remogu編集部。取組例をもとに役職と操作の対応を整理したもので、統計データではありません

この整理は、権限の一覧表を作るときのチェックリストにもなります。閲覧・編集・登録・削除という4つの操作を役職ごとに一覧化しておくと、抜けている組み合わせをレビューの段階で見つけやすくなります。

4. 委託しても、安全管理は残ります

委託先にも安全管理の徹底が及びます

クラウドサービスや学習支援システムの開発を外部に委託すると、安全管理の責任も委託先に移ると考えたくなりますが、留意事項が挙げる保管・管理のルールでは、漏えい等が生じないよう安全に管理することに加えて、従業者や委託先にも安全管理を徹底することが挙げられています²。

委託したことをもって安全管理から手を離せるわけではなく、委託先の運用まで含めて安全管理の対象になります。開発側の立場で言えば、委託を受けた瞬間から、委託元と同じ水準の安全管理を自社の中でも維持し続ける必要があるということです。契約時に確認するだけでなく、稼働している間も維持できているかを振り返る機会を、開発体制の中に置いておくと安心です。

選定時に確認しておくこと

委託先を選ぶ段階でも、この安全管理は続きます。ある自治体の取組例では、児童生徒の個人情報を適切に管理する能力がある事業者を選ぶため、自治体が定める安全管理措置と同等の措置を行っているかを事業者へのヒアリングを通じて確認しています⁵。

これは自治体側が確認する取組例ですが、開発側から見れば、自分たちの安全管理措置を言葉にして説明できる状態にしておく必要があるという意味でもあります。ヒアリングで聞かれてから資料を作り始めるより、普段の運用をそのまま説明資料に転記できる状態にしておくほうが、選定の場面でも契約更新の場面でも使い回せます。クラウドサービスの選定では、政府情報システムのためのセキュリティ評価制度（ISMAP）の審査を通過したサービスの一覧を参照し、活用することも考えられます⁴。一覧に載っていることが選定の要件になっているわけではなく、選定を進める際に参照できる情報のひとつという位置づけです。

確認される観点	委託先に求められること	開発側が示せる状態
安全管理の徹底	委託先にも安全管理を徹底すること	自社の安全管理措置を文書で説明できる状態
事業者の選定	自治体が定める措置と同等の水準であること	ヒアリングに答えられる具体的な運用の説明
クラウドサービスの選定	必須ではないが参照できる情報があること	ISMAP審査の通過状況を伝えられる状態

委託先が複数にまたがる案件では、確認する項目が委託先ごとにばらつきやすくなります。同じ3つの観点（安全管理の徹底・事業者の選定・クラウドサービスの選定）を委託先ごとに並べたチェックシートを用意しておくと、確認漏れが起きにくくなります。委託先が変わるタイミングでも、同じ観点を使い回せるようにしておくと、選定のたびに一から確認項目を作り直す手間を省けます。

5. 契約に「終わったら消す」が入ります

契約書に書かれる削除の条項

委託先との契約は、稼働している間の取り決めだけでは終わりません。ある取組例では、契約書に「データの利用や方法を最小限にすること」や「契約終了後はデータを削除すること」等について記載しています⁶。

契約終了後の削除まで契約書に含めておくと、稼働が終わった後にどう対応するかを都度協議する手間が減ります。開発側としては、契約終了時にデータを削除できる仕組みをあらかじめ用意しておくことが、この条項に応える前提になります。削除の機能を契約終了時にまとめて作るより、稼働中の設計段階から削除の対象範囲と手順を決めておくほうが、契約終了が近づいてから慌てて対応する事態を避けやすくなります。

削除の対象には、本体のデータベースだけでなく、バックアップやログに残る複製も含まれます。契約書に「削除すること」と書かれていても、削除の範囲をどこまでとするかは開発側で具体化しておく必要がある部分です。削除の実行を人の作業だけに頼ると、担当者が入れ替わるタイミングで抜け漏れが起きやすくなります。契約終了日をきっかけに削除処理が動く仕組みをあらかじめ組み込んでおくと、条項への対応を人の記憶に依存させずに済みます。

契約期間と削除の位置を図にすると、次のようになります。

図の作成：Remogu編集部。取組例に基づいて契約と削除の時系列を整理したもので、統計データではありません

削除の条項は、契約書の文言としては数行でも、実装としては削除対象のデータ一覧・削除の実行タイミング・削除が完了したことの確認方法という3つの要素に分解できます。契約書を読んだ時点で、この3つを誰がどう担当するかまで決めておくと、契約終了の間際になって慌てずに済みます。

6. 責任者は制度として決まっています

学校長が管理責任者、教育長等が総括管理責任者です

データを扱う設計をしていると、責任者を誰にするかも決めなければならないと考えがちですが、これは開発側が決める範囲ではありません。留意事項が挙げる組織的安全管理措置では、教育委員会・学校において各学校長等を管理責任者とし、管理責任者が保有個人情報を取り扱う担当者を指定すること、教育長等を総括管理責任者として置くことが必要です³。

責任者の位置づけは学校運営の制度としてすでに決まっており、開発側が新しく設計する部分ではありません。責任者を誰にするかを決めるより、決まっている責任の構造を前提にして権限や承認のフローをシステムの機能に落とし込むほうが、開発側の役割としては筋が通ります。承認フローを実装するときは、管理責任者が指定した担当者という位置づけを、システム上のロールにもそのまま反映しておくと、制度と機能がずれにくくなります。

役割	制度上の位置づけ	開発側が決められる範囲
総括管理責任者（教育長等）	教育委員会全体を統括する責任者として置かれる	開発側が設計する範囲ではない
管理責任者（各学校長等）	学校ごとに置かれ、担当者を指定する	開発側が設計する範囲ではない
担当者（管理責任者が指定）	実務としてデータを取り扱う	権限設計やシステムの機能として開発側が形にできる範囲

表にまとめた3つの立場を、上下の構造として図にすると次のようになります。

図の作成：Remogu編集部。留意事項が示す責任者の位置づけを整理したもので、統計データではありません

この整理を見ると、開発側が担当者の権限設計に集中し、責任者そのものの任命には関与しない、という役割分担が見えてきます。開発側が権限設計を提案する際も、最終的な承認は管理責任者や総括管理責任者に委ねる前提で進めると、あとから「誰が決めたことか」があいまいになる事態を避けられます。責任者は年度や体制の変わり目に交代します。システム側では、責任者の氏名をハードコーディングするのではなく、役職に紐づく形で管理責任者・総括管理責任者を参照できるようにしておくと、交代のたびに設定を洗い替える負担を抑えられます。この参照の仕組みは、担当者の交代にも同じように適用できます。

教育DXの実装で決まるのは、目的から逆算した持たない項目の選び方、組織の単位に重ねた権限、委託先に及ぶ安全管理、契約に書き込む削除の条項、そして制度として決まっている責任者の位置づけです。次に教育分野のシステムを設計する機会があれば、まず持たない項目から検討してみましょう。

7. よくある質問

目的以外にデータを利用する場合、本人の同意は書面でなければなりませんか

本人の同意を得る方法は、書面に限られません。利用目的以外の目的でデータを利用したり、第三者に提供したりする場合、本人が同意の判断を行うために必要な、合理的かつ適切な方法によることが求められますが、口頭等でも取得できます⁹。同意を得た記録がどこにも残っていないと、あとから利用目的の範囲を説明する場面で困ることがあります。運用上は、あとから同意の有無を確認できるよう、記録が残る方法を選んでおくと安心です。

学習用ソフトウェアやクラウドサービスを契約するとき、留意事項ではどんなことを確認できますか

留意事項のQ&A編には、新たに学習用ソフトウェア等を契約・導入する際の留意点、クラウドサービスを利用する場合に気を付けること、教育データが流出したり意図せず削除されたりした場合に求められる対応が、それぞれ設問として設けられています¹⁰。契約や導入を進める前に、この設問に沿って自社の対応を洗い出しておくと、抜けにあとから気づく事態を避けやすくなります。特にクラウドサービスは利用中に仕様が変わることもあるため、契約前だけでなく利用中も確認を続けられる体制にしておくと安心です。個別の対応は案件や自治体の方針によって異なるため、契約時にクライアントと協議しておく部分になります。

教育DXに関わる案件は、リモートで進められますか

Remoguで扱う案件の90%以上がフルリモート可能です¹¹。教育委員会や学校との打ち合わせなど一部の工程で稼働形態は案件によって異なるため、参画前にクライアントと確認しておくと安心です。案件を探す際は、稼働形態の条件を案件詳細で確認しておくと、参画後のミスマッチを避けやすくなります。

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

出典・参考情報

＊1 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版（2026年4月）
＊2 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版（2026年4月）
＊3 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版（2026年4月）
＊4 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版（2026年4月）
＊5 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版の取組例（2026年4月）
＊6 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版の取組例（2026年4月）
＊7 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版の取組例（2026年4月）
＊8 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版の取組例（2026年4月）
＊9 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版（2026年4月）
＊10 文部科学省「教育データの利活用に係る留意事項」公立学校編・第4版のQ&A編（2026年4月）
＊11 Remoguサイト公開情報（案件の90%以上がフルリモート可能）