大学の教員から届く休講・補講・教室変更の連絡メールを読み取り、科目・日時・教室を学務システムへの登録票にそろえて、学生向けのお知らせの下書きを作る

処理の起点を決める

教務課の共有メールボックスに、連絡のメールが届いたことを起点にします。 トリガーの「元のメールボックス アドレス」に共有メールボックスを入れ、フォルダーは「授業の変更」用に分けます。 教員に案内する宛先を1つにし、件名に「休講」「補講」「教室変更」のいずれかを入れてもらうよう頼んでおくと、受信の規則で振り分けられます。

件名の決まりを守らない連絡も、同じフォルダーに入れます。 件名で振り分けられなかったメールは、本文に「休講」「補講」「教室」などの語があるかを受信の規則で見て、同じフォルダーへ移します。 振り分けの漏れは、毎朝の未処理の件数で気づけるようにします。

急ぐ連絡には、別の目印を付けます。 トリガーは最大1時間遅れることがあるとされているので、翌日の授業についての連絡は、取り出しの後に「至急」の印を付け、職員の Teams に別の通知で知らせます。 夜間に届いたものは、翌朝の始業の前に職員が最初に見る一覧の先頭に置きます。

入力データを集める

質を決めるのは、時間割の「別名」の列です。 非常勤講師が使う科目の呼び方（「月曜の英語」「Reading II」）を、科目ごとに別名として足していきます。別名があれば、科目名が違っても教員と曜日時限で1つに絞れます。 最初は空で始め、職員が照合で直した記録から足します。

学年暦の「曜日の振替」も欠かせません。 祝日に授業を行う日や、月曜の授業を別の曜日に行う日があります。日付から曜日を計算するだけでは、その日にどの曜日の時間割で授業があるかは決まりません。

データの取得方法を決める

メールはトリガーの出力から本文を取ります。教員は、差出人のアドレスで教員の一覧を引いて特定します。非常勤講師は大学のアドレスを使わないことがあるので、届け出た個人のアドレスも一覧に持たせます。

科目の特定は、次の順で行います。

この表を、フローの条件分岐で書きます。 生成AIに「どの科目か」を決めさせず、取り出した文字と時間割のデータの一致で決めます。 一致しなければ人に回すだけで、近いものを選びません。

学年暦との照合は、次の4つを順に見ます。

2行目で、休講の対象の日がもともと授業の無い日なら、登録は要りません。 教員が学年暦を見ずに「来週の月曜は休講」と書き、その月曜が祝日だったという連絡は珍しくありません。登録票を作らず、教員に「その日は授業の無い日です」と返すだけで済みます。

AIへ渡す前に整形する

1. 差出人の確認 … 教員の一覧で引けるかを見ます。引けなければ、事務の職員や学生からの連絡の可能性があるので人へ
2. 本文の掃除 … 署名、引用の履歴を落とします。返信の連なりの中に過去の連絡が残っていると、古い日付を取り出してしまうためです
3. 受信日の付与 … 「来週の火曜」「明日」を日付に直す手がかりとして、受信日時をプロンプトに渡します
4. 1通に複数の連絡 … 休講と補講、複数の科目を1通で知らせるものは、プロンプトで連絡ごとに分けて返させます
5. 重複の確認 … 同じ教員・同じ科目・同じ日付の連絡が直近にあれば、訂正の連絡かどうかを人が確かめます

2番目を軽く見ないでください。 「先日お送りした10/14の休講に加えて」のように、過去の連絡を引用して新しい連絡を書く教員は多くいます。 引用の部分を落とさないと、10/14の休講がもう一度登録されます。

AIに処理させる

生成AIの仕事は、メールに書かれていることを連絡ごとに取り出すことだけです。

させないことも決めています。

曜日と日付の食い違いは、取り出しではなく照合で見つけます。 生成AIには書かれた曜日と日付をそれぞれそのまま取り出させ、学年暦と照らして合わなければ、フローが「教員に確認」の印を付けます。 どちらかに直させると、直したほうが正しいとは限らないからです。

指示内容を固定する

あなたは大学の教務課で、教員から届いた授業の変更の連絡を読む立場です。
渡されたメールの本文だけを読み、連絡ごとに次の項目を取り出してください。

【取り出す項目】
- kind：cancel（休講）/ makeup（補講）/ room_change（教室変更）
- course_text：書かれた科目名をそのまま
- weekday：書かれた曜日（月〜土）。書かれていなければ空
- period：書かれた時限（数字）。書かれていなければ空
- date：対象の日付（YYYY-MM-DD）
- date_basis：日付の元の書き方（例：「10/21（火）」「来週の火曜」）
- room：書かれた教室をそのまま
- makeup_method：in_person / online / assignment
- related_cancel_date：補講の場合、どの休講の分かが書かれていればその日付

【厳守事項】
- 書かれていない項目は空にしてください。推測で埋めないでください。
- 「来週」「明日」などは、受信日 {received_date} を基準に日付に直し、date_basis に元の書き方を残してください。
- 曜日と日付が両方書かれている場合は、それぞれ書かれたとおりに取り出し、
  食い違っていても直さないでください。
- 「いつもの教室」「同じ教室」と書かれている場合は、room を空にし、room_note に元の書き方を写してください。
- 引用された過去のメールの部分からは取り出さないでください。
- 休講の理由（出張、体調など）は書かないでください。
- 1通に複数の連絡がある場合は、連絡ごとに分けてください。
- 回答に JSON マークダウンを含めないでください。

【受信日】{received_date}
【メールの本文】{mail_body}

「食い違っていても直さない」を明記しないと、モデルは親切に直します。 「10/21（火）」で10月21日が水曜なら、どちらかに合わせた日付を返しがちです。直された日付は、もっともらしいぶん、職員の目をすり抜けます。 食い違いのまま返させ、照合の側で拾います。

「同じ教室」を空にさせるのも、同じ考えです。 補講の「同じ教室」は、元の授業の教室のことですが、その教室が補講の時限に空いているとは限りません。 空にしておけば、フローが時間割の教室を引き、空きを確かめる流れに乗ります。

学生向けのお知らせは、生成AIに書かせません。 種別ごとの定型の文を用意し、登録票の値を差し込みます。「【休講】{科目名}（{曜日}{時限}限・{担当教員}）{日付}の授業は休講です。補講の日程は決まりしだいお知らせします。」理由を書く欄を最初から持たないので、教員の事情が学生に出ることもありません。

補講のお知らせに「どの休講の分か」を入れるのは、学生が自分の時間割と照らせるようにするためです。 補講の時限に別の授業がある学生は、どの回の補講かが分かれば教員に相談できます。

出力形式を固定する

プロンプトの出力は、JSON のカスタム形式で固定します。 公式ドキュメントでは、JSON の例を更新すると形式がカスタムになり、保存すると形式がロックされるとされています。フィールド キーの無い配列はサポートされないので、連絡の配列は要素ごとにキーを持たせます。フローは、これに照合の結果を足して登録票を作ります。

{
  "mail_id": "KYOMU-20261007-0158",
  "teacher_no": "T30412",
  "notices": [
    { "kind": "cancel", "course_text": "統計学", "weekday": "火", "period": "2",
      "date": "2026-10-20", "date_basis": "来週の火曜", "room": "", "room_note": "",
      "makeup_method": "", "related_cancel_date": "" }
  ],
  "match": {
    "course_code": "B2041", "course_name": "統計学I", "rule": "teacher_and_period_unique",
    "calendar_ok": true, "class_day": true, "room_free": null
  },
  "status": "ready",
  "urgent": false
}

1つ目の理由は、取り出した値と照合の結果を分けて持てることです。 notices は生成AIが埋め、match はフローが埋めます。職員が誤りを見つけたとき、取り出しの誤りか照合の誤りかがすぐ分かります。

2つ目は、match.rule で科目をどう決めたかが残ることです。 「教員と曜日時限で1つ」「別名で一致」「職員が選んだ」。別名で決まった件が多い教員は、別名の登録が効いているということです。

3つ目は、status で職員の待ち行列を作れることです。 ready（そのまま登録できる）、needs_teacher（教員に確認）、needs_staff（職員が科目や教室を決める）に分け、ready から順に片付けます。

システムへ連携する

教員への確認のメールは、職員が学務システムに登録した後に送ります。 登録票の値（科目名、日付、時限、教室）をそのまま書き、「この内容で登録しました。違っていればお知らせください」と添えます。教員の目で、最後にもう一度確かめてもらう形です。

needs_teacher の問い合わせは、定型の文で作ります。 「10/21（火）とありますが、10月21日は水曜日です。どちらの日の授業でしょうか」。何が食い違っているかを具体的に書くと、教員の返事が1回で済みます。

人が確認する

職員は、すべての登録票を確かめてから学務システムに入力します。 見るところは決めておきます。

1. 至急の印の付いたものを最初に見る … 翌日の授業の変更です。掲載が遅れると、学生が教室に来てしまいます
2. ready の値を元のメールと見比べる … 科目名・日付・時限を、メールの文で確かめます
3. needs_staff で科目や教室を決める … 候補から選び、選んだ結果を時間割の別名に足すかを決めます
4. お知らせの下書きを読み、そのまま掲載する … 文を書き換えるのは、定型に収まらない連絡のときだけです

目標は、360件をならして1件3分です。 ready は元のメールと見比べて入力するだけで1〜2分、needs_staff と needs_teacher に時間を残せます。

例外に対処する

最後の行は、知らせるだけの仕組みです。 補講が要るかどうか、課題で代えてよいかは、教務の決まりと教員が決めることです。 この構成は、休講と補講の数の差を見えるようにするところまでを受け持ちます。

記録を残す

• 連絡のメールのIDと受信日時、差出人
• プロンプトの出力（notices）と、照合の結果（match、status）
• そのとき使った時間割・学年暦の版
• 職員が直した値と、選んだ候補
• 学務システムへの登録日時と、お知らせの掲載日時
• 教員への確認のメールの送信日時と、教員からの訂正の有無
• 科目ごとの休講と補講の結びつき

最後の記録が、学期の終わりにいちばん役に立ちます。 科目ごとに、休講が何回あり、補講がどの回の分として行われたか。第2章の授業の期間の考え方に照らして、予定した回数の授業が行われたかを、教務課が科目ごとに説明できます。