🔐
LEVEL Ⅰ
最重要情報
分離ネットワークで管理
例と扱い方
成績原本、指導要録原本、パスワード管理台帳、個人情報の一括データなど。
提案：完全分離ネットワークで管理 ／ Teams不可
01 / SAFE & SMART
情報を安全に扱えるから、
安心して便利にできる。
便利さと安全性を両立するため、まず情報の扱い方を整理しました。
情報管理安心・安全学校のルールが前提
このページで伝えたいこと
便利だから何でも共有するのでも、危険だから使わないのでもない。情報の種類ごとに「どこに置くか」「誰が見られるか」を判断することから、学校DXを始めました。
情報の4分類
※ 校内運用の提案です。正式な規程ではありません。
この分類の位置づけ
柏市の基準の考え方を参考にした、2026年6月24日付の校内運用整理（案）の要約です。正式な市・学校の規程そのものではありません。
🩺
LEVEL Ⅱ
要配慮情報
指定された安全な保管先
例と扱い方
生徒指導・教育相談、健康情報、名簿、保護者連絡先、個人別のテスト結果など。
提案：校内の指定された安全な保管先 ／ Teamsには詳細を載せない
📋
LEVEL Ⅲ
通常校務情報
内容と権限を確認して共有
例と扱い方
会議資料、部屋予約、学年日報、提出状況、係分担など。内容によって要配慮情報を含むことがあります。
提案：内容・権限を確認しTeamsやSharePointで共有
📣
LEVEL Ⅳ
公開可能情報
公開承認後に活用
例と扱い方
学校だより、公開可能な行事予定、公開許可が確認された写真・お知らせなど。
提案：公開承認後、サイネージ・ホームページ等で活用
判断のポイントは「名前」より「内容」
Teamsには必要な所在情報を共有する一方、理由・背景・健康・家庭事情などは投稿しない運用です。
✅ 共有する例
「遅刻」「早退」「帰宅確認」などの所在情報
「遅刻」「早退」をそのまま共有
理由と注意点を見る
実際の運用では略号や暗号を使わず、日本語でそのまま記載しています。誰に共有するかは学校の設定・規程に従って判断します。
⛔ 書かない例
「早退（発熱）」「欠席（家庭の事情）」
理由・健康・家庭事情は書かない
理由と注意点を見る
健康・家庭・指導の理由や評価につながる情報は、Teamsへの一般投稿と切り分けて扱います。
📢 Teamsは「入口」
連絡や所在を確認する場所
運用の考え方
連絡や必要最小限の情報を伝える場。要配慮情報の本体は、権限を管理した別の場所に保管します。「Teamsにすべて入れる」という意味ではありません。
🗂️ 本体は指定された場所へ
要配慮情報は別の安全な場所に
運用の考え方
GIGA-NASなど、学校が認めた保管場所を使います。正式版を一か所にし、閲覧権限・画面ロック・端末管理まで含めて考えます。
重要：ここに記載した区分と保存先は、当時の研修・運用提案をまとめたものです。導入先では必ず教育委員会・学校の最新規程で確認してください。生成AIに個人情報・内部URL・認証情報を貼り付けないでください。
「守れないルールは続かない」
誤投稿は起こり得る。だからこそ、投稿できる情報の範囲を整理し、使いやすさを損なわずに影響を小さくする。研修では正解・不正解の場面を比べ、職員が自分で判断できることを重視しました。
置き場所の共通化理由・背景は分ける離席時に画面ロック利用状況から見直す
研修で確認した日常の運用
情報4分類を知識だけで終わらせず、Forms・共有フォルダ・端末の扱いを具体的に考えるための内容です。
📝 Forms・小テストの結果はどう扱う？
- Formsは回収や小テストの入口として利用する。
- 個人別の回答・点数は、権限が適切に管理された指定の保管先で扱う。
- 研修案ではExcelで結果を出力し、GIGA-NASの指定フォルダへ移す方式を紹介した。
- 結果共有リンクの作成や、Teamsへの個人別結果ファイル添付を避ける。
具体的な可否は学校・教育委員会の現在の規程を優先してください。
🗂️ GIGA-NAS・共有フォルダの整理
情報の置き場所が人によって違うと、古い版の参照や権限の間違いが起こりやすくなります。「正式版を一か所にする」「分類ごとの指定フォルダを決める」「個人のデスクトップを正式な保管先にしない」が要点です。
最重要情報（Ⅰ）の保管場所は分離ネットワークを前提とし、要配慮情報（Ⅱ）の保管先と混同しないようにします。
💻 画面・端末・パスワードの日常管理
- 離席時は画面をロックする。
- 端末を生徒のいる場所に放置しない。
- パスワード入力を他者から見られないようにする。
- 大型モニターには個人情報を表示したままにしない。
- 不要な印刷物やメモを机上に残さない。
02 / REAL PRACTICE
「探す」「転記する」「伝える」を、
仕組みで減らす。
日報・連絡・資料探し。毎日の小さな手間を仕組みで減らしました。
日報欠席連絡Teamsサイネージ生成AI研修
このページで伝えたいこと
実際に何の仕事を減らしたのか、どんな仕組みにしたのか、効果の試算をまとめました。取り組みが始まった経緯は「改善の流れ」で紹介します。
🗓️転記を減らす日報・学年日報
💬伝達を早くTeams・事務室
🖥️一目で分かるサイネージ
💡 この取り組みを支える3つの考え方
01 / SECURITY
情報管理
情報に合わせて、共有場所を選ぶ
考え方を見る
情報の性質によって保存場所と共有範囲を分ける。便利さと安全性を両立させる。
02 / EFFICIENCY
業務の効率化
毎日の「探す・転記・伝える」を減らす
考え方を見る
日報の転記、資料探し、教職員間の連絡など、繰り返しの手間を減らす。
03 / CULTURE
改善する文化
先生自身が改善に参加できる
考え方を見る
教員自身が困りごとを見つけ、生成AIやICTで試し、改善に参加できる環境をつくる。
実際に取り組んだ改善事例
補足と前提
「導入前に何が大変だったか」と「どんな仕組みにしたか」を対比。提供されたPower AutomateのフローやGAS・HTMLも確認した範囲で反映しています。
🗓️
CASE 01 / Power Automate
日報の自動化
転記を少なく
日報を何度も転記→必要な箇所へ自動反映
仕組みと実践資料を詳しく見る
日付別のExcel日報などに転記する作業を、Office ScriptsとPower Automateで整理・自動化。
SharePointのファイル変更→処理待機→Office Scripts→ファイル更新
別の手動実行フローもある「日報自動作成」は手動起動でOffice Scriptsを2本実行する構成。自動実行フローとは分けて扱っています。
実際のフローで確認できたこと
「日報自動化」のエクスポートにはファイル作成・変更、遅延、SharePoint上のスクリプト実行、Compose、ファイル更新が含まれます。Excel側のスクリプト内容と本番環境での動作は別途検証が必要です。
📘
CASE 02 / Power Automate
学年日報への自動反映
入力は一度に
学年日報へ再入力→元データから反映
仕組みと実践資料を詳しく見る
教務全体の日報から学年の日報へ、同じ内容を再転記する作業を減らす。
ファイル変更→Office Scripts→更新
教員の入力を増やさない元の入力をできるだけ一度で済ませ、学年側には必要な情報を反映させる考え方。
エクスポートで確認できた構成
「学年日報自動反映」にはファイル変更を起点とするスクリプト実行、Compose、ファイル更新、遅延の処理があります。実運用の成否まではエクスポートだけでは断定しません。
📨
CASE 03 / 転記負担の軽減
欠席連絡の転記
転記時間を短く
毎朝の連絡を転記→集約して確認
仕組みと実践資料を詳しく見る
学年ごとに毎朝手入力していた内容を、集約・転記・確認の工程に分けて見直す。
連絡を受ける→整理・転記→担当者が確認
紹介資料に記載した前後比較各学年約15分の転記作業から、約1分の確認作業へ。手入力ミスの防止にもつながる見込み。
公開上の注意
欠席理由などの要配慮情報は一般投稿や外部AIに入力しません。このケースの具体的な自動化フロー一式は今回の提出資料では検証していないため、導入例としては構成案を示します。
💬
CASE 04 / Teams
情報共有の一元化
情報を探しやすく
資料の場所が分からない→Teamsで探せる
仕組みと実践資料を詳しく見る
資料の所在を尋ねる、探し回る、相手が見つかるまで待つ、という小さな負担を減らす。
目的別チャンネル→検索・確認→各自の時間に利用
目的に応じた場所全体連絡、日報、学年、研究・DX、事務室など。Teamsに載せる内容は情報分類に従って判断します。
☎️
CASE 05 / 事務室との連絡
移動と紙メモを減らす
移動と紙を減らす
職員を探して伝言→デジタルで共有
仕組みと実践資料を詳しく見る
電話の取次ぎの後、別階まで移動し、職員の机に伝言メモを置くといった工程を見直す。
用件を受ける→デジタル共有→担当者が確認
効果は時間だけではない移動・配布の手間に加え、伝達漏れや受取人を探す時間を減らす。
🖥️
CASE 06 / GAS + HTML + Sheets
校内デジタルサイネージ
必要な情報を一画面に
情報があちこちに→一覧表示で確認
仕組みと実践資料を詳しく見る
提出期限、部屋予約、お知らせ、休暇・出張、来客などを必要なときに見られるようにする。
登録フォーム→GAS→スプレッドシート→画面表示
資料で確認できる画面時程・お知らせ・部屋予約・期限リマインダーなどの表示と、出張・休暇・来客を加えた事務室向け表示。
コード資料と注意点
登録用HTML、表示用HTML、GAS、スプレッドシートの対応を確認しました。ただし「サイネージ連携」というZIPは「日報自動化」と実質同じ定義だったため、そのZIPだけではサイネージ専用の連携を確認できません。
校内サイネージ｜説明用の再現イメージDEMO / 架空データ
お知らせ
今週の確認事項
提出・申請の締切
提出・申請の締切
部屋予約
会議室A：15:00〜
会議室B：利用なし
提出期限
時程
本日の校内時程
出張・休暇
本日の予定一覧
来客
受付予定・注意事項
個人名・学校内部URL・QRコード・本番データは使っていません。
年間削減時間の概算
補足と前提
配布資料に記載した前提による、50人・年間190日などを想定した仮の計算です。実測値や確定的な削減実績ではありません。
日報関連
544時間40分
転記等の工程と日報探索の時間
欠席連絡
133時間
3学年×14分×190日
資料探索・事務室連絡
310時間50分
一般資料の探索と移動・伝言
教職員間の相手探し
791時間40分
50人×1日1回×5分×190日
合計・重複調整前
学校全体の小さな時間を足すと
8時間の人日で約223人日相当。ただし実働時間削減を保証する数字ではありません。
試算の計算条件・限界を確認
| 項目 | 紹介資料の算定条件 | 年間概算 |
|---|---|---|
| 日報 | 転記等の4項目 ＋ 日報探索 45人×3分×190日 | 544時間40分 |
| 欠席連絡 | （15分－1分）×3学年×190日 | 133時間 |
| 一般資料探索 | 50人×週2回×3分×40週 | 200時間 |
| 事務室からの連絡 | 7分×1日5件×190日 | 110時間50分 |
| 相手探し | 50人×1日1回×5分×190日 | 791時間40分 |
| 合計（調整前） | 聞き取りと仮定に基づく暫定試算 | 1,780時間10分 |
試算の限界：日報探索と資料探索、事務室連絡と相手探しなどは重複する可能性があります。Teamsへの投稿・閲覧、システムの開発・保守時間も未控除です。時間がそのまま勤務時間の減少を意味するわけではありません。
時間だけでは測れない変化
🔎 自分で探せる
欲しい資料を自分で見つけられる
変化の背景
情報の保管場所と連絡の入口が定まり、必要な資料を自分のタイミングで確認しやすくなる。
⏰ 中断が減る
声かけ・探し回りの中断を減らす
変化の背景
資料の所在確認、取次ぎ、呼びかけの回数を減らし、今取り組んでいる仕事を続けやすくする。
🌱 自分でも改善できる
誰でも改善を試せる
変化の背景
生成AIを活用した研修を通して、プログラミングの専門家でなくても困りごとを形にする体験を共有。
「Teamsに入れたので確認してください」という連絡が日常化するなど、自分で情報を確認する文化が広がったという実践上の観察があります。全職員への効果を測定したものではありません。
03 / THE ROAD TO DX
どんな相談と試行を経て、
学校DXが動き始めたのか。
週1回程度の校務改善LDX会議を起点に、小さく試す改善と、学校全体で決める改善が生まれました。
このページで伝えたいこと
LDX会議で出たアイディアを、影響の小さいものは「面白そうだから試してみよう」と実行。学校全体に影響するものは主任会・職員会議を通して進めました。具体的な月ごとの歩みは下の縦型カレンダーで確認できます。
アイディアの出発点
ほぼ毎週
校務改善LDX会議
週1回程度。「これ、改善できない？」から始まる。
影響の大きさで進め方を選ぶ
小さく始められる改善
「面白そう！ やってみよう」
アイディア→試作→試用・改善
日報の自動化やサイネージなど、多くの試みはこの雰囲気から始まりました。
学校全体に影響する改善
組織で確認して進める
LDX会議→主任会→職員会議
情報の一元化と、情報セキュリティの4分類は、この流れを通して進めました。
💡 全ての改善を大きな会議にかけるのではなく、影響範囲に応じてスピードと合意形成を使い分ける。
OUR STORY / 2026
会議と試行から生まれた改善の記録
会議から生まれたアイディアが、どのように試作や全校的な取り組みへ発展したのか。
2026APR — OCT
試作・実施の記録方針案・準備今後の提案
4月構想・調査
課題整理
情報の一元化を改善テーマにした
「情報が散らばっている」という困りごとから、連絡の入口をTeamsに寄せる構想を検討。学校全体に関わるため、主任会・職員会議を通す進め方を取りました。
5月実装・試行
試作・実装
まず試す。日報の転記を自動化
「これ、面白そうだからやってみよう」という試行の一例。Excel日報の繰り返し作業に対し、Power AutomateとOffice Scriptsを試作・調整しました。
6月仕組みとルール
運用案を作成
便利さと安全性をセットで整理
サイネージなどの試行と並行して、情報の4分類を整理。6月24日に校内運用案をまとめ、情報の一元化と同様、主任会・職員会議を通す進め方を取りました。
7月研修準備
準備
教職員が試せる環境を整える
教材アプリを共有するサイトを試作。面白そうなものをまず作ってみる経験を、夏季の生成AI活用研修につなげました。
夏季教職員研修
研修実施
「自分でも作れる」を体験してもらう
教職員が生成AIを使い、身近な困りごとを小さなアプリとして試作・確認する研修を実施しました。
10月次の構想
提案段階
教員から生徒へ、改善の担い手を広げる
生徒自身が学校の困りごとに向き合い、アプリを作って共有する企画を提案。こちらは実施済みではありません。
📎 会議の進め方と、記録上の注意点
校務改善LDX会議はおおむね週1回。アイディアをすぐ試す改善と、影響範囲が大きいため主任会・職員会議を通す改善を使い分けていました。
「情報の一元化」と「情報セキュリティ4分類」は、実践担当者の説明に基づき、主任会・職員会議を通して進めた取り組みとして掲載しています。ただし、個々の案件が審議・承認された正確な日付や議事内容までは、このサイトの資料だけでは特定していません。
情報4分類の掲載内容は校内の運用整理案の要約であり、正式な法令・教育委員会規程そのものではありません。
🗺️ 他校でも取り組むときの進め方・注意点を見る
5つの段階を順番に進める
タブを開くと、カードが左から順番に現れます。各段階で「何を確認するか」を一つに絞ります。
01
🔍
困りごとを見つける
この段階ですること
「探す」「転記する」「相手を探す」など、同じ手間が繰り返されている場面を選ぶ。
02
🗂️
情報と手順を整理
この段階ですること
入力・判断・保存・通知を分け、情報分類・閲覧権限・利用できるツールを確認する。
03
🤖
Copilotと試作
この段階ですること
目的と制約をAIに伝え、許可されたMicrosoft 365等で最小構成を設計する。
04
🧪
架空データで検証
この段階ですること
想定外の入力、二重更新、権限設定、エラー時の動きまで確認する。
05
🌱
共有して改善
この段階ですること
職員の使い勝手を聞き、手順を残して引き継ぐ。必要なら改善を繰り返す。
導入時に避けたい3つの失敗
CHECK 01
いきなり全校で使わない
注意点を読む
最初は架空データ・少人数で試し、承認を得てから広げる。
CHECK 02
AIが書いた内容を鵜呑みにしない
注意点を読む
権限、接続先、処理条件、ライセンスを実際の画面で確認する。
CHECK 03
担当者だけが分かる仕組みにしない
注意点を読む
引き継げる設定一覧・操作手順・問い合わせ先を残しておく。
次は「プロンプト作成」タブへ。学校の環境を選ぶだけで、Copilotに相談するための文章を作れます。
04 / TRY IT WITH COPILOT
あなたの学校でも、
一つ試してみませんか。
条件を選ぶだけ。Copilotに相談する文章を作れます。
このページで伝えたいこと
相手校で使っているCopilotを前提に、AIへの依頼文をつくるページです。最初は「何を確認すればよいか」を聞くところから始めましょう。
Copilotへの依頼文を自動作成
生成された依頼文を確認・編集する
ポイント：Copilotにいきなり完成品を作らせず、まず利用環境と権限を確かめる。説明は一操作ずつ、分からないところをその都度聞けば大丈夫です。
最初の設定で迷わないための説明
必要になったものだけ開けるようにしています。GASやPower Automateを最初からすべて勉強する必要はありません。
💬 Copilotはどこで開けばいい？
学校で利用が認められているCopilotのチャット画面を使用し、上の依頼文を貼り付けます。Power Automateのフロー編集画面内に表示されるCopilotとは別の機能です。利用できる内容は学校のライセンスや管理設定によって変わります。
📢 Teams：情報共有の入口を整理する
- 連絡がどこに分散しているか書き出す。
- Copilotにチャンネルの分け方と投稿ルールを相談する。
- 所在情報は必要な範囲で「遅刻」「早退」などそのまま記載し、理由・背景は分ける。
- 少人数で試し、校内の承認・情報管理ルールを確認する。
🗓️ 日報：Power Automate / Office Scriptsの導入
- 元のExcelと転記先、更新するタイミングを整理する。
- 学校でPower Automate・Office Scripts・SharePointを利用できるか確認する。
- Copilotに、手動起動とファイル変更起動のどちらが適切か比較してもらう。
- 架空のExcelで小さなフローを作り、処理履歴・二重実行・エラーを試す。
- 本番導入前に権限・接続先・責任者を確認する。
参考：今回確認した3種のエクスポートは「日報自動作成」（手動、スクリプト2本）、「日報自動化」（ファイル変更起動）、「学年日報自動反映」（別のファイル変更起動）で、互いに役割が違います。
🖥️ サイネージ：GASとMicrosoft 365の選択
- 出したい項目を選ぶ。例：お知らせ・部屋予約・提出期限。
- 誰が入力し、誰が閲覧できるか整理する。
- GASが許可されているならGoogle Sheets＋GAS＋HTMLを検討する。
- Microsoft 365のみなら、許可されたSharePoint・Microsoft Lists・Power Apps等で代替できるかCopilotに相談する。
- 架空データで表示、更新、誤公開が起きないかを確認する。
学校独自のURL、コード内の認証情報、職員の実名や本番データを公開サイトやAIに渡さないでください。
📨 欠席連絡：安全性を確保して考える
- 入力元・集計先・誰が確認するかを整理する。
- 理由・健康情報を含む場合は情報管理の責任者に確認する。
- まず氏名も欠席理由も架空のものを使って検証する。
- 通知に載せるのは許可された必要最小限の内容に限定する。
実データの転記・処理をAIに直接依頼する前に、利用規程とデータの送信先を確認してください。
🛠️ エラーが出たときのCopilotへの相談文
画面のどの操作をしたか、期待した結果と実際の結果、エラーの文章を伝えると調べやすくなります。スクリーンショットは氏名・メールアドレス・内部URL・認証情報を隠してから使います。
掲載内容は「他校が試すための説明用」です。フロー・GAS・HTML・スプレッドシートの元ファイルは機密情報の有無や学校ごとの利用許可を確認せずに配布しないでください。既存の仕組みと同じ動作が他校でも保証されるわけではありません。