生成AIに生徒情報はどこまで入力できる？文科省ガイドラインで検証した「重要性分類Ⅱ」の条件

生徒の名簿や成績、指導の記録を前にして、「これは生成AIに入力していいのだろうか」と手が止まったことはありませんか。

実は私も、まったく同じところで長いあいだ立ち止まっていました。

校務でGeminiやNotebookLMを使うほど便利さは実感するのに、肝心の「どこまで入れていいのか」の線が見えない。

だから結局、名前を消し、成績を消し、当たり障りのない一般的な文章しか入力できず、AIから返ってくるのも当たり障りのない答えばかり——そんな時期が続きました。

この壁を破る鍵は、実は「生成AIのルール」を探すことではありませんでした。

文部科学省の「教育情報セキュリティポリシーに関するガイドライン（令和7年3月改訂）」を読み込み、情報資産の「重要性分類」と「パブリッククラウドの扱い」という2つの条文にたどり着いたとき、判断の軸がはっきりしたのです。

結論を先に言います。

一定の条件をすべて満たせば、重要性分類Ⅱに該当する生徒情報も、Google Workspace for Education の環境内であればGeminiやNotebookLMに入力できる、というのが私の到達した読み方です。

この記事では、その根拠となるページ番号を明示し、必要な5つの条件と、NotebookLMに実際にガイドラインを読み込ませて検証したQ&Aまで公開します。

30年以上教壇に立ち、現在は特別支援学校で勤務しながら地域で生成AI講師も務めている立場から、「現場の教員が自分で判断できるようになる読み方」として整理しました。

なお、この記事はあくまで筆者が個人的に調べ、整理したものです。

所属校や教育委員会の公式見解ではありません。

参考程度にご覧いただき、実際の運用は必ずご自身の学校の管理職・情報担当者にご確認ください。

あわせてお伝えしておくと、筆者は現時点で計画を立案している段階であり、この記事で紹介する校内システムをまだ実行してはいません。

設計と根拠の整理までが、今回お見せできる範囲です。

この記事を読めば、生徒情報を生成AIに入力する際の判断基準が「なんとなくの自己判断」から説明できる根拠に変わります。管理職への相談も、資料を示しながら進められるようになります。

この記事では、次の流れで解説します。

それでは、順番に説明していきましょう。

生成AIへの生徒情報の入力は文科省ガイドラインのどこに書かれているか

まず最初に、多くの先生がつまずくポイントから片づけます。

参照するのは令和7年3月改訂の最新版ガイドラインです。文部科学省の「教育情報セキュリティポリシーに関するガイドライン（令和7年3月改訂）」。

この文書はツール名ではなく、情報の性質に応じて取り扱いを定める構造になっています。

順番に見ていきましょう。

ガイドラインに「生成AI」はたった1回しか登場しない

意外なようですが、文科省のガイドライン本文で「生成AI」という語が出てくるのは、冒頭の「はじめに」の1か所だけです。

理由は、このガイドラインが特定のツールを名指しして規制する文書ではなく、情報資産の性質に応じた取り扱いを定める文書だからです。

ツール名を列挙する構造になっていないので、「ChatGPTは可」「Geminiは不可」といった記述はどこにもありません。

実際に該当箇所を引くと、「さらに、生成AIの登場など、教育現場を取り巻く環境は日々変化している」という一文です。

環境変化の例として触れられているだけで、以降に生成AIの利用手順は出てきません。

つまり、「生成AIのルール」を探しているうちは、いつまでも答えにたどり着けないという構造になっています。

判断軸は「重要性分類」と「パブリッククラウド」の2条文

結論として、生成AIへの生徒情報の入力可否は

• ①その情報が重要性分類の何番に当たるか
• ②利用環境がパブリッククラウドとして必要な措置を満たしているか、この2点の掛け算で決まります。

理由は、GeminiやNotebookLMが「パブリッククラウド上のSaaSサービス」に該当するためです。

ガイドラインはパブリッククラウド上で扱う情報について、重要性分類ごとに必要な措置を明確に定めています。

ここに生成AIも当然に含まれます。

具体的には、この2つの条文を突き合わせます。

確認すること	該当する条文・ページ
情報の重要性分類の判定	35ページ 図表7／36ページ 分類の解説
パブリッククラウドでの取扱条件	45ページ 3.2(5)／60ページ 4.4(4)
公式クラウドが「外部」に当たるか	42ページ 3.2(7)／46ページ 定義の解説
事業者側の目的外利用の禁止	162ページ 9.2(1)

この4行が、この記事の骨組みそのものです。

最終判断は各教育委員会のポリシーが優先する

ガイドラインは「例文と解説」であり、実際に現場を縛るのは各教育委員会が定めた教育情報セキュリティポリシーです。

ガイドライン自体が各教育委員会にポリシーの策定・見直しを求める立場の文書だからです。

ガイドラインの記述をそのまま「うちの学校のルール」と読み替えることはできません。

たとえば、ガイドライン上は多要素認証があれば認められる運用であっても、自治体のポリシーで「生成AIへの児童生徒情報の入力は一律禁止」と定めていれば、そちらが優先されます。

逆に、自治体のポリシーが未整備の場合はガイドラインが実質的な判断基準になります。

ですので、これから紹介する読み方は「管理職と相談するときの共通言語」として使ってください。

生徒情報を生成AIに入力する前に押さえる「重要性分類」の4段階

入力の可否を判断する出発点は、目の前の情報が何番の分類かを見極めることです。

分類の判定を誤ると、以降の条件設計がすべて無効になります。ネット上の解説では「3段階」と誤記された例も少なくありません。

ひとつずつ確認していきます。

重要性分類Ⅰ〜Ⅳの定義（35〜36ページ）

ガイドラインの重要性分類はⅠ・Ⅱ・Ⅲ・Ⅳの4段階です。

理由は、情報の機密性・完全性・可用性という3次元の影響度を、現場で運用可能な1次元に単純化するために4段階が採用されているためです。

36ページには「3次元を1次元に単純化した重要性分類によって、分類・仕分けをすることを推奨したい」と明記されています。

具体的な定義は次のとおりです。

分類	定義（36ページより要約）
分類Ⅰ	セキュリティ侵害が教職員又は児童生徒の生命、財産、プライバシー等へ重大な影響を及ぼす情報。要配慮個人情報を含むもの
分類Ⅱ	セキュリティ侵害が学校事務及び教育活動の実施に重大な影響を及ぼす情報（Ⅰを除く）。健康・指導・成績・進路に関わる機密性の高い情報
分類Ⅲ	セキュリティ侵害が学校事務及び教育活動の実施に影響を及ぼす情報（Ⅱ以上を除く）
分類Ⅳ	セキュリティ侵害が学校事務及び教育活動の実施に影響を及ぼさない情報（Ⅲ以上を除く）

ネット上の解説記事では「分類Ⅰ〜Ⅲの3段階」と書かれているものを見かけますが、原典は4段階です。ここは押さえておきましょう。

成績・名簿・指導記録は「重要性分類Ⅱ」

結論から言うと、教員が日常的に扱う情報の多くは重要性分類Ⅱに当たります。

理由は、35ページの図表7「重要性分類に基づく情報資産の例示」に、分類Ⅱの具体例として成績・進路・生徒指導関係の情報が並べて示されているからです。

図表7の分類Ⅱ欄に挙げられている代表的な項目を拾うと、次のようになります。

• 教職員及び児童生徒の氏名・生年月日・電話番号・住所等の基本情報
• 成績に関する情報（通知表、定期考査・テスト等の採点結果）
• 個別教育計画、生徒指導に関する記録、家庭訪問等個別面談に関する記録
• 進路に関する情報（進路希望調査、調査書、推薦書、成績一覧表）
• 転退学・転入学、教科用図書の給付に関する情報
• 児童生徒名簿、児童生徒住所録、保護者緊急連絡先

つまり、「生徒の名前と学習の中身がセットで入っている資料」は、まず分類Ⅱだと考えてよいわけです。

要配慮個人情報は例外なく「重要性分類Ⅰ」

要配慮個人情報はすべからく重要性分類Ⅰに該当します。これは36ページに明記された断定表現です。

要配慮個人情報の漏えいが差別や偏見に直結し、本人の基本的人権に回復不能な損害を与えるためです。

特別支援学校の場合、情報の改ざんや消失が医療的ケアの継続性を断ち、生命の危機を招く可能性まであります。

具体的には、医師の診断書、健康診断票、心理検査・知能検査の結果、投薬管理表、医療的ケア実施記録、療育手帳の情報、虐待の疑いに関する相談記録などが分類Ⅰです。

分類Ⅰと分類Ⅱの境目を自分の言葉で説明できることが、この先の話の前提になります。

重要性分類Ⅱの生徒情報を生成AIに入力できる根拠ページ

ここからが本題です。分類Ⅱの生徒情報をパブリッククラウドで扱えると読める根拠を、ページ単位で示します。

根拠となる条文は「禁止」ではなく「条件付きの許容」で書かれており、ページ番号を示せれば管理職への説明材料になります。

順に見ていきましょう。

60ページ：パブリッククラウドで分類Ⅱ以上を扱う条件

この記事の最大の根拠は60ページ「4.4 教職員等の利用する端末や電磁的記録媒体等の管理(4)」の一文です。

この条文が分類Ⅱ以上の情報をパブリッククラウドで扱うこと自体を前提として、その条件を定めているからです。

禁止条文ではなく、条件を満たせば扱える構造になっています。

原文を引用します。

特に、パブリッククラウド上で重要な情報（重要性分類Ⅱ以上）を取り扱う際には、多要素認証を含む強固なアクセス制御による対策を講じなければならない。

「多要素認証を含む強固なアクセス制御」が、分類Ⅱをクラウドに載せるための入場券だと読み取れます。

45ページ：情報資産の利用における取扱制限

45ページ「3.2 情報資産の管理(5) 情報資産の利用」にも、ほぼ同じ条件が重ねて書かれています。

この規定が「端末管理」の側面（60ページ）と「情報資産の利用」の側面（45ページ）の両方から同じ結論を導いており、条文の読み間違いではないことを裏づけるからです。

45ページには、分類Ⅱについて「業務に係る教職員等・教育委員会・児童生徒本人とその保護者のみがアクセスできるような取扱制限が必要」と示され、例として「児童生徒の成績に関する情報については、その児童生徒の指導に関わる教職員等のみがアクセスできるよう設定する」と具体的に書かれています。

つまり、分類Ⅱに求められているのは「クラウドに置かないこと」ではなくアクセスできる人を絞ることです。

ここは実務感覚と一致するはずです。

42・46ページ：公式クラウドは「外部持ち出し」ではない

結論として、学校や教育委員会が管理する公式クラウドへの保存は「外部持ち出し」に該当しません。

これが3つ目の根拠であり、実務上いちばん効く一手です。

理由は、46ページに置かれた外部持ち出しの定義そのものです。原文はこうなっています。

外部持ち出しとは、教育委員会・学校が構築・管理している環境（本ガイドラインが適用されているクラウドサービスや学校外での利用が認められている情報端末等を含む環境）の外に情報資産を持ち出すことを示す。

括弧の中を読んでください。ガイドラインが適用されているクラウドサービスは「内側」に含まれているのです。

つまり、教育委員会が契約したGoogle Workspace for Education は、持ち出し先の「外部」ではなく、守られるべき「内側」の環境という位置づけになります。

一方で42ページ「3.2 情報資産の管理(7)」には、外部持ち出しをする場合の規定が置かれています。

教職員等は、重要性分類Ⅱ以上の情報資産を外部持ち出しする場合は、限定されたアクセスの措置設定（アクセス制限や暗号化）を行い、教育情報セキュリティ管理者の個別許可を得なければならない。また、持ち出し持ち帰りの記録をつけなければならない。

この2つを重ねると、判断はきれいに整理できます。

行為	外部持ち出しか	必要な手続き
公式Workspaceのドライブに分類Ⅱを保存	該当しない	強固なアクセス制御（多要素認証）
公式アカウントのGemini・NotebookLMで扱う	該当しない	同上＋学習利用オフの確認
私物PCにダウンロードする	該当する	個別許可＋持ち出し記録
個人契約のAIサービスに入力する	該当する	そもそも私的契約サービスの業務利用は禁止

境界は「AIかどうか」ではなく「公式環境の内か外か」です。

162ページ：目的外利用と第三者提供の禁止

環境の安全性を担保する最後のピースが162ページ「9.2(1) 守秘義務、目的外利用及び第三者への提供の禁止」です。

生成AIの最大の不安要素である「入力したデータがAIの学習に使われるのではないか」という点が、まさにここで契約要件として規定されているからです。

原文では
SaaS型パブリッククラウドサービス事業者は「守秘義務を遵守するとともに、同意のない目的外利用及び第三者への提供は行ってはならない」とされています。

さらに従業員の雇用契約にも同様の条項を含めること、退職後の守秘義務まで含めることが求められています。

したがって、Google Workspace for Education のように「入力データを学習に使わない」ことが契約・約款で確認できる環境であれば、この要件を満たすと読めます。

ここは自校の情報担当者に契約内容を確認するのが確実です。

生成AIに生徒情報を入力するための5つの必須条件

根拠が揃ったので、実務に落とします。

ここから挙げる5つは「どれかを満たせばよい」ものではなく、すべて満たして初めて成立する条件です。

内訳は技術要件が2つ、手続き要件が3つ。1つ欠ければ、残り4つを満たしてもポリシー違反になります。

ひとつずつ見ていきましょう。

条件1：教育委員会が契約した公式アカウントを使う

結論として、必ず教育委員会または学校が組織として契約したアカウントを使ってください。

理由は、42ページに「利用する電子メール、外部ストレージサービスは教育委員会又は学校から提供される公式サービスのみを利用し、私的に契約したサービスを利用してはならない」と明記されているためです。

具体的には、教職員個人のGmailアカウントで作ったNotebookLMに生徒の資料を読み込ませる行為は、それだけでアウトです。
無料枠かどうかは関係なく、「私的契約サービスの業務利用」に当たります。

アカウントのドメインが自校のものかを、作業の前に必ず確認する習慣をつけましょう。

条件2：多要素認証を有効にする

結論として、ID・パスワードのみのログインでは条件を満たしません。

理由は、60ページと45ページの両方で「多要素認証を含む強固なアクセス制御」が義務として書かれているためです。
ここは推奨事項ではなく「講じなければならない」という表現になっています。

具体的には、スマートフォンの認証アプリ、パスキー、セキュリティキーなどを併用した状態にしておきます。

なお45ページには例外規定があり、児童生徒本人やその保護者が自分自身に関する情報にアクセスする場合には、パスワードの秘匿管理の徹底やロック機能の有効化を前提にID・パスワード認証を許容する、とされています。

教職員が使うなら、多要素認証は例外なく必須です。

条件3：データの学習利用がオフであることを確認する

入力したデータがAIの学習・解析に使われない設定・契約であることを確認してください。

理由は、162ページが「同意のない目的外利用」を禁じており、逆に言えばこの確認が取れていない環境は要件を満たさないからです。

具体的には、Google Workspace for Education のGeminiやNotebookLMは、法人向け契約においてユーザーデータを生成モデルの学習に使用しない旨が示されています。

ただし契約プランや管理コンソールの設定によって挙動が変わる余地があるため、自校の情報担当者に「学習利用オフになっているか」を一度書面レベルで確認しておくことをおすすめします。

この確認記録が、後で「なぜ入力してよいと判断したのか」を説明する材料になります。

条件4：管理者（校長）の許可と記録を残す

必ず校長（教育情報セキュリティ管理者）への事前申請と記録を行ってください。

理由は2つあります。第一に、42ページが分類Ⅱ以上の外部持ち出しについて個別許可と記録を義務づけていること。

第二に、公式クラウド内の利用が形式的には外部持ち出しに当たらないとしても、新しい運用を個人の判断で始めるべきではないからです。

具体的には、次の内容を申請書に書きます。

1. 目的（例：教育相談資料の下書き作成、単元目標の三観点化）
2. 使用するツール（例：Google Workspace内のNotebookLM／Gemini）
3. 入力する情報の範囲と重要性分類（例：分類Ⅱの成績情報・指導記録）
4. アクセス制御の状況（多要素認証の有効化、共有範囲）
5. 保管期間と消去のタイミング

個人の裁量で始めた運用は、個人の責任で終わります。組織の運用に載せてください。

条件5：目的達成後は速やかに消去する

作業が終わったら、生成AI側に残った情報は速やかに消去してください。

必要のなくなった情報を残し続けることが、そのまま漏えいリスクの蓄積になるためです。

ガイドラインが求めるのは「持ち出した情報を持ち続けないこと」であり、これは生成AIのチャット履歴やソースにも同じ考え方が及びます。

具体的には、通知表のコメント案が完成して校務支援システムに転記した時点で、Gemini_Notebook側のソースとチャットを整理します。

年度単位でノートブックを作り直す運用にしておけば、消去のタイミングが自動的に訪れる仕組みになります。

「作りっぱなしにしない」設計を最初から入れておくことが、5つ目の条件です。

Gemini_Notebookに生徒情報を入力して検証したQ&A

最後に、私が実際に検証した過程をお見せします。

ガイドラインPDFそのものをGemini_Notebookのソースとして読み込ませ、判断に迷う質問を投げていくという方法です。

検証に使ったのは公開されている行政文書のみで、生徒情報は入力していません。

AIの回答は必ず原文とページ番号で裏づけを取る前提で進めました。

順番に見ていきます。

検証方法：ガイドラインPDFをソースに読み込ませる

結論として、制度の解釈を調べるときは、一次資料をソースに固定したGemini_Notebookがいちばん確実です。

理由は、通常のチャット型AIに「文科省のガイドラインでは？」と聞くと、学習知識から一般論を答えてしまい、ページ番号の裏づけが取れないためです。

ソースを固定すれば、回答は必ずその文書の中から根拠を示して返ってきます。

具体的な手順はシンプルです。

1. 文科省サイトから「教育情報セキュリティポリシーに関するガイドライン（令和7年3月）」のPDFを取得する
2. Gemini_Notebookに新しいノートブックを作り、そのPDFをソースとして追加する
3. 判断に迷っている場面を、そのまま具体的な質問として投げる
4. 返ってきた回答の引用箇所をクリックし、原文とページ番号を必ず自分の目で確認する

なお、この検証で読み込ませたのは公開されている行政文書だけです。

生徒の情報は一切入れていません。ここも念のためお伝えしておきます。

検証Q1：分類ⅡをGemini_Notebookに紐づけるのは違反か

結論として、返ってきた答えは「特定の条件をすべて満たしている場合に限り、違反にはならない」でした。

理由として示されたのが、まさに前章で確認した条文群です。

パブリッククラウド上で分類Ⅱ以上を扱う際の多要素認証の要件、公式サービスのみを利用する原則、目的外利用の禁止。これらを満たす環境であれば、Gemini_Notebookのソースとして生徒の学習記録を追加する行為は、ガイドラインに準拠した正当な校務活用と読める、という整理です。

具体的な回答を要約すると、こうなります。

校長の許可を得たうえで、多要素認証のかかった公式アカウントで行い、作業後に消去する——という運用を徹底していれば、最新のガイドラインに準拠した正当な校務活用と言える。

逆に、条件が1つでも欠けた場合は「不適切な取り扱い」に当たると明確に否定されました。

5条件がAND条件であるという理解は、ここから来ています。

検証Q2：匿名化すれば許可なく入力していいか

結論として、これは明確に否定されました。ここが検証全体で最も印象的だった回答です。

理由は、児童生徒の情報を完全に匿名化することが困難だからです。

氏名を伏せても、評価内容や指導の記録、学級の規模、支援の具体的な内容といった要素の組み合わせから、特定の生徒が推測できてしまいます。

具体的には、「匿名化したから許可はいらない」という自己判断が最も危険な発想でした。

匿名化は条件を満たすための代替手段ではなく、条件を満たした上で追加で行う配慮という位置づけになります。

つまり、入口の手続きは省略できないということです。

検証Q3：私物PCや個人契約のAIならどうか

結論として、こちらも一切認められないという回答でした。

理由は、42ページの「私的に契約したサービスを利用してはならない」という規定と、モバイル端末・外部での作業制限に関する規定の両方に抵触するためです。

具体的には、次のように整理されました。

• 私物PCで職場のWorkspaceにアクセスする：原則禁止。やむを得ない場合は校長の許可に加え、端末のロックや遠隔消去機能などの追加的な安全管理措置が必要
• 私物PCにダウンロードした資料を個人契約のChatGPTで加工する：明確に禁止。意図しない漏えいと、生徒情報が学習データとして蓄積されるリスクを同時に招く
• 分類Ⅱ以上の情報を私物端末で扱う：作業自体を禁止とする対策が推奨される

ここまで整理して、私の中で線がはっきり引けました。

扱ってよいのは「公式アカウント」「多要素認証」「学習利用オフ」「許可と記録」「作業後の消去」がそろった箱の中だけであり、その箱の中でなら、分類Ⅱの生徒情報を生成AIと組み合わせられる——これが今回の結論です。

そして、この結論が正しいなら、次に見えてくるものがあります。バラバラに散らばっている生徒の情報を、一つの箱にまとめてしまえばいい、という発想です。

生徒情報を一元管理する校内システムの設計

ここからは、前半の結論を前提にした設計の話です。

分類Ⅱの情報を公式Workspaceの中で扱えるなら、生徒情報を一箇所に集めてしまえる——その構想を具体的に書きます。

目的は情報を集めること自体ではなく、生成AIとの連携を成立させること。

使うツールはGoogleドライブとGemini_Notebookの2つだけです。

順番に見ていきましょう。

設計の目的｜散逸した生徒情報を一つの箱に集める

この設計の目的は一人の生徒に関する情報が散らばっている状態を解消することです。

理由は、情報が散逸していると生成AIに渡せる材料がその都度バラバラになり、AIの回答の質が安定しないからです。

学習の記録は担任のドライブ、通知表のデータは校務支援システム、教育相談の記録は別のファイル——この状態では、AIに聞くたびに資料を集め直すことになります。

具体的に、私が現在集約の対象として想定しているのは次の情報です。

• 生徒の氏名、住所、学年、緊急連絡先などの基礎情報
• 通知表に関するデータ
• 学習の記録（各教科の目標・支援方法・評価）
• 教育相談の報告書
• 個別の指導計画（分類Ⅰに該当しない教育目標レベルのもの）

つまり、一元管理はゴールではなく、生成AI連携の前提条件という位置づけになります。

共有ドライブの4フォルダ構成

結論として、専用の共有ドライブを1つ作り、その中に4つのフォルダを置く構成にします。私はこのドライブを、重要性分類Ⅱを扱う箱という意味で「最重要C2ドライブ」と呼んでいます。

理由は、扱う情報の分類を名前に埋め込んでおくことで、「ここに入れてよいのは分類Ⅱまで」という判断が名前を見た瞬間に伝わるからです。

分類Ⅰの情報を誤って入れる事故を、運用ルールではなく命名で防ぐ発想です。

具体的な構成は次のとおりです。

フォルダ	入れるもの	想定する一般教職員の アクセス権
① 個別の生徒情報	生徒ごとのフォルダ、Gemini_Notebookのリンク一覧	投稿者
② 生徒共通情報	緊急連絡先、住所、学部・学年・学級名簿など一覧データ	閲覧者(コメント可)
③ 学校全体の情報	職員会議資料、学部会資料	閲覧者(コメント可)
④ 成果・反省	学部ごとの目安箱ファイル、行事の成果・反省ファイル	コンテンツ管理者

②の「生徒共通情報」は、要録に載せられる正式な表記の元データを置く場所です。

住所や氏名の表記ゆれをなくすための「原本」として扱います。

なお、健康診断票や医師の診断書は要配慮個人情報であり、重要性分類Ⅰです。この箱には入れず、従来どおりの厳格な管理下に置くべき情報です。

箱の名前と箱の権限、その両方が分類と対応していることが、この設計の要になります。

参考:Googleドライブの「アクセスレベル」

アクセスレベル	主な操作
管理者	コンテンツの操作に加え、メンバーの追加・削除、アクセスレベルの変更、共有ドライブの設定変更ができる
コンテンツ管理者	ファイルやフォルダの追加・編集・移動・削除ができる
投稿者	ファイルの追加・編集はできるが、基本的にファイルやフォルダの移動・削除はできない
閲覧者（コメント可）	ファイルの閲覧とコメントができる
閲覧者	ファイルの閲覧のみできる

「編集者」は、通常のマイドライブ内のファイルやフォルダを個別共有するときの名称です。

共有ドライブでは、編集できる人は「投稿者」「コンテンツ管理者」「管理者」のいずれかになります。

例えば次のように使います。

ファイル	コメントする対象	コメント例
Googleドキュメント	文章や単語を選択	「この表現は分かりにくいので修正してください」
Googleスプレッドシート	特定のセル	「この金額は税込みですか？」
Googleスライド	文字、画像、図形、スライド	「この写真を新しいものに差し替えてください」
PDF・画像など	プレビュー上の箇所	「この部分の数字を確認してください」

コメントには他の人が返信でき、対応が終わったら「解決」を押して閉じられます。

生徒フォルダはドキュメントとスプレッドシートで統一する

フォルダの中身はGoogleドキュメントとスプレッドシートに統一します。

WordやExcelのファイルは置きません。

理由は、Gemini_Notebookとの同期の仕組みにあります。

ドキュメントやスプレッドシートをソースに指定しておけば、元ファイルを更新したあとGemini_Notebook側の同期ボタンを押すだけで最新の内容が反映されます。

ファイルを差し替える必要がないのです。

一方、WordやExcelはアップロードした時点のコピーとして扱われるため、更新が反映されません。

具体的な運用は次のようにします。

1. 年度当初に、必要な項目をそろえたテンプレートのドキュメントとスプレッドシートを作っておく
2. 情報が増えたら、新しいファイルを作らずドキュメントのタブとして追加する
3. どうしても新規ファイルが必要な場合は作成し、担任に伝えてGemini_Notebookのソースに追加してもらう
4. Gemini_Notebookを使う前にソースパネルで同期アイコンを押す

どうしてもWordやExcelで作業したい先生には、完成後にドキュメントとスプレッドシートへコピペしてもらう運用でお願いする想定です。

ここを妥協すると、同期の仕組みが成立しません。

Gemini_Notebookは担任が作成しリンク一覧で共有する

Gemini_Notebookは生徒ごとに担任が自分のアカウントで作成し、リンクを一覧にまとめて共有します。

理由は、ノートブックの作成者が明確でないと、更新の責任者が曖昧になるからです。

この責任の所在をはっきりさせておきます。

具体的な運用ルールはこうなります。

• 担任が生徒フォルダのファイルをソースとして追加し、ノートブックを作成する
• 共有設定は、学部の先生のメールアドレスを登録したグループアドレスを共有先にする
• ノートブックのリンクは学部ごとに一覧化し、②のフォルダに置く
• 原則として1年ごとにノートブックを作り直す。
• 音声概要などのStudio機能は使ってよいが全員が閲覧可能になる。

年度ごとの作り直しは手間に見えますが、前半で挙げた「条件5：目的達成後は速やかに消去する」を運用の中に組み込む仕掛けになっています。

生徒情報の一括管理を持続させるために設定した4つの条件

システムを作るときに、私が最初に決めた条件があります。

ここを共有しておかないと、設計の意図が伝わりません。

条件はすべて「続くかどうか」を基準に決めており、4つ目は一見セキュリティに逆行するように見える判断です。

ひとつずつ説明します。

条件1：文部科学省のセキュリティポリシーに合致する

結論として、ガイドラインに合致しない設計は、どんなに便利でも採用しません。

理由は、根拠を示せない運用は必ずどこかで止まるからです。

「便利だから」で始めた仕組みは、管理職の異動や事故の発生をきっかけに一瞬で使えなくなります。

具体的には、この記事の前半で整理した5条件——公式アカウント、多要素認証、学習利用オフ、許可と記録、作業後の消去——を設計の必須要件として組み込んでいます。ページ番号まで示せる状態にしてから提案するのが、この条件の意味です。

根拠のある仕組みだけが、担当者が変わっても残ります。

条件2：すべての教員が参加でき、理解できるやり方にする

結論として、一部の先生しか使えない仕組みは作りません。

そうなると情報は再び散逸し、一元管理という目的そのものが崩れます。

具体的には、覚えてもらう操作を「Googleドキュメントとスプレッドシート」「Googleドライブ」「Gemini_Notebook」の基本的な使い方の3つに絞りました。プロンプトの書き方や高度なAI操作を習得しなくても、システムの一員になれる設計です。

全員参加のハードルは、限界まで下げてください。

条件3：学校の一般的な情報管理能力で継続できる形にする

大切なことは、特定の教員の得意分野に依存しない形にすることです。

理由は、学校には異動があるからです。

詳しい人が一人いる状態で回している仕組みは、その人の異動と同時に止まります。

私自身、そうやって消えていった校内システムを何度も見てきました。

具体的には、GoogleドライブとGemini_Notebookという標準機能だけで組み立てています。

スクリプトも自動化ツールも外部サービスも使いません。

年度更新の作業も、テンプレートをコピーしてノートブックを作り直すだけです。

「面白いことができる仕組み」より「誰でも引き継げる仕組み」を選ぶ、という判断です。

条件4：アクセス権限をあえて絞らない

生徒フォルダは全職員がフルアクセスできる状態にします。これは意図的な判断です。

理由は2つあります。

• 第一に、アクセス権限を細かく設定し始めると管理が複雑になり、継続できなくなること。
• 第二に、編集権限のない先生は結局その資料を自分のパソコンにコピーして使うからです。

情報を守るつもりで権限を絞った結果、コピーが増えて情報が散逸する——これが最も避けたい事態です。

具体的には、「このフォルダは生徒に関する許可された情報をすべて入れる場所」と全員で割り切り、誰でもここに追記できるようにします。

そのかわり、ドライブ全体には多要素認証がかかり、分類Ⅰの情報は入れないというルールを徹底します。

権限設計は、守れるかどうかではなく守り続けられるかどうかで決めてください。

一元管理した生徒情報を生成AIに入力して業務を削減する使い方

最後に、この仕組みが動いたときに何ができるようになるのかを書きます。

ここがこの記事の到達点です。

ノートブックから情報を引き出すだけでは、まだ半分の価値しか使えていません。

本当の価値は、Geminiにノートブックを読み込ませたときに生まれます。

順番に見ていきましょう。

NotebookLMから生徒の総合的な所見を引き出す

情報が集約されていれば、ノートブックに質問するだけで生徒の全体像が返ってきます。

Gemini_Notebookが与えられたソースを横断して答える仕組みだからです。

各教科の学習記録、通知表、教育相談の記録が同じノートブックに入っていれば、教科の壁を越えた答えが出てきます。

具体的には、こういう質問ができるようになります。

• 「この生徒の今学期の成績表から、課題になっている点を挙げてください」
• 「この生徒を支援するうえでポイントになることは何ですか」
• 「昨年度と今年度で、変化が見られる部分はどこですか」
• 「氏名、住所、保護者名、連絡先などの基礎情報をすべて出してください」

これまでなら複数のファイルを開いて頭の中で突き合わせていた作業を、AIが担当してくれるわけです。

Geminiに読み込ませて指導案から三観点の目標をつくる

この仕組みの真価はGeminiにノートブックを読み込ませて操作したときに出ます。

理由は、Gemini_Notebookが「その生徒の情報に閉じた質問」に強い一方、Geminiは外部の資料と生徒情報を掛け合わせる作業ができるからです。組み合わせることで、参照と生成が一本につながります。

具体的な例を挙げます。音楽科の単元指導案をGeminiに読み込ませ、同時にその生徒のノートブックを参照させて、こう指示します。

この指導案をもとに、この生徒についての単元の目標を三観点で作成してください。過去の学習記録から、この生徒が達成できそうな水準に調整してください。

すると、一般論ではなく「この生徒の記録に裏づけられた目標」が返ってきます。教科の指導案という共通の枠と、生徒個人の実態が、その場で結び付くわけです。

共通の枠と個別の実態を掛け合わせる——これが一元管理の本当の狙いです。

教育相談のテンプレートに沿って基礎情報を生成する

書式が決まっている書類の下書きは、ほぼ自動化できます。

テンプレートと材料の両方が揃っていれば、あとは当てはめる作業に近づくからです。

教育相談の報告書、支援計画の様式、引き継ぎ資料——学校の書類の多くは決まった枠を埋める形式です。

具体的には、Geminiに校内の教育相談テンプレートを読み込ませ、ノートブックを参照させてこう指示します。

このテンプレートに基づいて、この生徒の教育相談の基礎情報を作成してください。記載の根拠となった資料名も併記してください。

根拠となる資料名を併記させるのがポイントです。

出てきた文章を必ず自分で検証してから使うという前提を、指示の中に埋め込んでおきます。

出力はあくまで下書きであり、ゼロから書く時間が確認して直す時間に変わる——その差が業務削減の実体です。

最終的な判断と記述の責任は教員にあります。

目安箱ファイルで学期末の反省を自動整理する

気づいたことを書き溜めておくだけで、学期末の反省がまとまります。

断片的なメモの整理がAIの得意分野だからです。

人間は「あとでまとめよう」と思ったメモをまとめられません。AIは、見出しさえ付いていればまとめられます。

具体的には、④の「成果・反省」フォルダに学部ごとの目安箱ファイルを置き、次のように使います。

• 学校の仕事の進め方について気づいたこと、意見、反省点を、思いついたときに書く
• タブで分けても分けなくてよい。とにかく見出しを付けて書き溜める
• 行事ごとの反省も同じファイルに入れておく
• 学期末に、そのファイルを読み込ませて「今学期の課題を整理してください」と指示する

年間の反省や次年度の計画にも、同じファイルがそのまま使えます。書き溜めた記録が資産に変わる仕組みです。

生成AIへの生徒情報の入力に関するよくある質問

ChatGPTやClaudeでも、同じ条件なら生徒情報を入力できますか？

条件の枠組みは同じです。組織として契約し、多要素認証がかかり、学習利用がオフであれば理屈は変わりません。ただし前提は「自治体・学校が公式に導入したサービス」であることです。2026.7現在でgoogle以外にそのサービスを導入している例を筆者は知りません。なお、個人契約では条件を満たせません。

重要性分類Ⅰの情報は、生成AIでは一切扱えないのですか？

一律禁止とは書かれていませんが、分類Ⅰには「真に必要な者のみがアクセスできる取扱制限」が求められます。健康・診断・検査結果などは、実務上は生成AIに入力しない判断が無難です。校長への確認が前提になります。

校長への申請は、作業のたびに毎回必要ですか？

分類Ⅱは個別許可が原則で、分類Ⅲは管理者の判断で包括的許可が可能とされています。実務では「この業務・この範囲」という単位でまとめて許可を得る形を管理職と相談するのが現実的です。

生徒や保護者への説明・同意は必要ですか？

セキュリティポリシーとは別に、個人情報保護の観点からの確認が必要です。校務での利用目的の範囲内かどうかは学校の個人情報取扱要領で定められているため、そちらを管理職とあわせて確認してください。

まとめ｜生成AIへの生徒情報の入力は「箱の設計」で決まる

まず最初にするべきなのは自校のセキュリティポリシーの確認です。文部科学省のガイドラインは各教育委員会がポリシーを策定するための基準であり、現場を直接縛るのは自治体が定めたポリシーだからです。

前半で示した根拠ページ——35ページの重要性分類、45ページと60ページのパブリッククラウドの要件、46ページの外部持ち出しの定義、162ページの目的外利用の禁止——は、そのポリシーを読むための地図として使ってください。地図があれば、自校のルールが何を許し何を禁じているのかが読み取れるようになります。

そのうえで、管理職に相談してください。「生成AIを使いたい」ではなく、「分類Ⅱの情報を、多要素認証がかかった公式アカウントの範囲内で扱いたい。根拠はこのページです」と伝えてください。話が通じる相談になります。

もう一つ大切なのは、ツールより先に情報を入れる箱を設計することです。どのAIを使うかは、あとから変えられます。しかし情報がどこに置かれているかという構造は、一度散らばると元に戻せません。

生成AIの回答の質は、プロンプトの巧拙よりも、渡せる材料の質と量で決まります。だからこそ、集約の設計が先に来るのです。

判断の基準はひとつです。その情報が公式環境の内側にとどまっているか。

生成AIに生徒情報を入力する前に、まず分類Ⅰと分類Ⅱの線を自分の言葉で引いてください。

そのうえで公式アカウント・多要素認証・学習利用オフ・許可と記録・作業後の消去という5条件を満たせば、生徒情報の活用が自己判断のグレーゾーンに落ちる心配もありません。

適切に設計された情報の箱は、あなたの日々の判断と子どもたちへの支援を、確実に支える基盤になるのです。

なお、冒頭でもお伝えしたとおり、この記事は筆者が個人的に調べ、設計したものです。筆者はこのシステムをまだ実行しておらず、現在は生徒1名を対象としたテスト運用の実施について管理職へ提案する段階にあります。進展があれば、また記事にしてご報告します。

生成AIを校務にどう組み込むかについては、当ブログの他の記事でも実践例を紹介しています。単元計画づくりや生徒の実態把握の記事もあわせて読んでみてください。

この記事が役に立ったと感じたら、フォローをお願いします。現場で試した結果を、これからも一次情報としてお届けします。