大学の教員が書いたシラバスを学内の記載要領に照らして点検し、直しの案を付けて教務の担当へ返す

処理の起点を決める

毎日夕方の定時に、提出済み・未点検のシラバスを書き出すことを起点にします。 教員が提出した瞬間に点検を走らせる作り方もありますが、教務システムの多くは提出の通知を外へ送る仕組みを持っていません。1日1回の書き出しなら、どの教務システムでも組めます。

書き出しのファイルが共有フォルダに置かれたら、Azure Functions のタイマーで取り込みます。取り込みが終わったファイルは処理済みのフォルダへ移します。 移すのは全件の点検が終わったときだけにし、途中で止まったら翌日にもう一度読みます。

締切の直後だけは、1日に2回書き出す運用にしてもかまいません。 担当が翌朝に指摘の一覧を読めることが目標で、書き出しの回数はそれに合わせて決めます。

修正されて再提出されたシラバスも、同じ経路で点検します。 再提出かどうかは書き出しの「提出回数」の列で分かるので、一覧で区別して表示します。

入力データを集める

質を決めるのは、記載要領を項目ごとに分けた形です。 十数ページの文書をそのままAIに渡すと、どの規定を根拠にしたのかが指摘に残りません。規定ごとに rule_id を振り、本文と良い例・悪い例を1行ずつ持たせます。 指摘には必ずこの rule_id を付けさせます。

単位の計算の規則は、学則・履修規程から取ります。 大学設置基準は、1単位の授業科目を45時間の学修を必要とする内容で構成することを標準とし、授業の方法に応じて、おおむね15時間から45時間までの範囲で大学が定める時間の授業をもって1単位とすると定めています。何時間の授業を1単位とするかは大学ごとに違うので、自校の規程の数字を設定に持たせます。

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

書き出しの列は、教務システムの入力画面の項目にそろえます。 到達目標を1つの欄にまとめて入力させている教務システムでは、番号や改行で分けて取り込みます。分けられないときは、到達目標の個数の点検を外し、言葉の点検だけを行います。

授業計画は、回ごとの行として取ります。 「第1回〜第15回」が1つの欄に詰め込まれていると、回数が足りているかが分かりません。入力画面が回ごとに分かれていないなら、それ自体を記載要領の改善として教務委員会に上げます。

前年度のシラバスは、同じ科目コードと担当教員の組で引きます。 担当が変わった科目は前年度と比べても意味がないので、比べません。

AIへ渡す前に整形する

1. 項目の分割 … 到達目標を番号と改行で分け、授業計画を回ごとに分けます
2. 数字の取り出し … 成績評価の割合を「方法」と「％」の組にします。「％」が無い記載は数字の点検から外し、言葉の点検に回します
3. 評価の割合の合計 … 合計が100％でなければ、数字の不備として記録します
4. 授業外学修の時間の計算 … 単位数 × 45時間から、授業の時間（1回の時間 × 回数）を差し引いた時間を、学修に必要な時間の目安として出します
5. 授業計画の回数 … 回ごとの行が規定の回数そろっているかを数えます
6. 到達目標の個数 … 記載要領の範囲（3〜5個）に入っているかを数えます
7. 表記の機械的な点検 … 全角・半角の混在、「です・ます」と「だ・である」の混在を規則で拾います

4番目の計算は、プログラムだけで行います。 たとえば講義の2単位の科目で、自校の規程が「15時間の授業で1単位」なら、授業は30時間、学修全体は90時間で、授業の外に60時間が必要という目安になります。 これを15回で割れば1回あたり4時間です。シラバスに「各回1時間の予習」としか書かれていなければ、数字の不備として出します。 学修時間の扱いをどこまで厳しく見るかは、自校の規程と教務委員会の取り決めに合わせます。

数字の不備は、この段階で確定させます。 AIには「数字の点検の結果」として渡し、AIが数字を計算し直さないようにします。

AIに処理させる

させるのは、言葉で判断するしかない項目について、記載要領の規定に照らした不備の候補を挙げ、原文の箇所と直しの案を付けることです。

「判断できないときの扱い」の列がいちばん大事です。 到達目標の書き方は分野によって慣行が違い、芸術や体育の実技の科目では「理解する」に代わる言い方が定まっていないこともあります。判断に迷うものは不備と言い切らず、unclear として担当に回します。

2行目がいちばん起きやすい失敗です。 直しの案を求めると、AIは到達目標を全部書き換えた文を返しがちです。案は1つの指摘につき1か所、原文の言い回しを残した最小の直しにします。

指示内容を固定する

あなたは大学の教務課で、教員が提出したシラバスの書き方を、
学内の記載要領に照らして点検する立場です。
授業の内容や水準が適切かは判断しないでください。
見るのは、記載要領の規定どおりに書かれているかだけです。

【点検する項目】
1. 到達目標の主語（学生を主語にしているか）
2. 到達目標の行動（確かめられる行動で書かれているか）
3. 成績評価の方法と到達目標の対応
4. 平常点の中身（内訳が書かれているか）
5. 授業外学修の具体性（回ごとに何をどれだけするか）
6. 表記（記載要領の用字用語にそろっているか）

【status の選び方】
- missing ....... 規定が求める記載が無い
- vague ......... 記載はあるが、規定が求める具体さに足りない
- rule_conflict . 記載が規定と食い違っている
- unclear ....... 分野の慣行などで、不備かどうか判断がつかない
迷ったときは unclear を選んでください。

【厳守事項】
- 指摘には、根拠にした規定の rule_id を必ず付けてください。
  記載要領に無い基準で指摘しないでください。
- quote には、シラバスの原文をそのまま写してください。
  要約したり言い換えたりしないでください。
- suggestion は、1つの指摘につき1か所の最小の直しにしてください。
  原文の言い回しをできるだけ残し、全体を書き直さないでください。
- 書かれていない評価方法や学修内容を、推測で補わないでください。
- 成績評価の割合と授業外学修の時間は【数字の点検の結果】をそのまま使い、
  計算し直さないでください。
- 授業の内容、難易度、教員の専門性について書かないでください。
- 不備が無い項目は、指摘を作らないでください。

【記載要領の規定】{rules}
【科目の情報】{course_info}
【数字の点検の結果】{numeric_checks}
【シラバス】{syllabus}

「規定の rule_id を必ず付ける」を最初に置くのは、指摘の根拠を記載要領に縛るためです。 何も言わなければ、AIは一般的な「良いシラバス」の基準で指摘を増やします。記載要領に無い指摘は、教員から見れば教務課の好みでしかありません。

「原文をそのまま写す」は、後段の照合のための指示です。 言い換えた引用は原文と照合できず、どこを直せばよいのかが教員に伝わりません。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "course_code": "",
  "submission_no": 1,
  "findings": [
    {
      "item": "objective_subject | objective_verb | assessment_mapping | participation_detail | study_outside_class | wording",
      "rule_id": "",
      "status": "missing | vague | rule_conflict | unclear",
      "quote": "",
      "suggestion": "",
      "reason": ""
    }
  ],
  "summary_for_staff": ""
}

1つ目の理由は、指摘を一覧で並べられることです。 担当はシラバスごとではなく、指摘ごとに採否を選びます。item と status で並べ替えれば、rule_conflict から先に読めます。

2つ目は、照合ができることです。 quote はプログラムがシラバスの原文と突き合わせ、一致しない指摘は一覧に出しません。 AIが原文に無い文を引用して指摘を作る失敗を、ここで止めます。

3つ目は、rule_id で集計できることです。 どの規定の不備が多いかを月ごとに数えれば、入力画面の注意書きや記載要領の説明会で何を伝えるべきかが分かります。

構造化出力のスキーマでは、公式のページにあるとおり、すべての項目を必須にし、オブジェクトには additionalProperties: false を設定します。 指摘が無い項目を空にしたいときは、項目を省くのではなく、配列を空で返させます。

数字の点検の結果は、AIの出力とは別に、プログラムが次の形で持ちます。

{
  "course_code": "",
  "assessment_total": 110,
  "assessment_ok": false,
  "required_outside_hours": 60,
  "stated_outside_hours": 15,
  "outside_hours_ok": false,
  "plan_rows": 15,
  "plan_ok": true,
  "objective_count": 2,
  "objective_count_ok": false
}

AIの出力と分けておくのは、数字の不備は確定した事実で、言葉の不備は候補だからです。 一覧の表示も分け、数字の不備は採否を選ばずにそのまま依頼文に入れます。

システムへ連携する

教務システムには書き込みません。 点検の結果をシラバスの欄に書き戻すと、教員の入力と教務課の指摘が同じ場所に混ざります。公開の手続きも、担当が教務システムの画面で行います。

依頼文は下書きまでで、送信は担当が行います。 自動で送ると、外したはずの指摘が教員に届くことがあります。教員との関係は、毎年続くものです。

依頼文の下書きは、教員ごとに1通にまとめます。複数の科目を担当している教員には、科目ごとに見出しを分けた1通にします。科目ごとに別のメールが何通も届くと、教員はどれから直せばよいか分からなくなります。

人が確認する

担当が見るのは、指摘の一覧です。 シラバスを最初から読むのではなく、指摘ごとに原文の箇所と直しの案を読み、採る・直す・外すを選びます。

1. rule_conflict を先に見る … 規定と食い違う記載です。出席だけを評価に入れているような記載は、学部の教務委員と相談が要ることもあります
2. unclear は学部の慣行に照らして決める … 実技の科目の到達目標のように、分野で書き方が違うものです。判断したら、その判断を記載要領の補足として残します
3. missing と vague は直しの案を読む … 案が原文の趣旨を変えていないかを確かめます
4. 依頼文を確定する … 採った指摘だけで文面を組み直し、送ります

2番目の判断を残すのが、属人化を減らす仕組みです。 「実技の科目では『〜を演奏できる』を到達目標の書き方として認める」のような判断を補足に書き足し、次からは規定としてAIに渡します。担当ごとに違っていた線引きが、記載要領の側にたまっていきます。

目標は、240件をならして1件5分です。 不備の無いシラバスは一覧を流し見て終わり、指摘の多いものだけに時間を使います。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの問題ではなく、入力画面と科目マスタの作りの問題です。 直すほうが、指示を工夫するより効きます。

5行目の件数は、毎月見てください。 一致しない引用が増えたら、書き出しの文字コードや改行の扱いが変わった可能性があります。

記録を残す

• 書き出したシラバスの表と、点検に使った記載要領の版
• 数字の点検の結果（評価の割合の合計、授業外学修の時間、授業計画の回数、到達目標の個数）
• AIへの入力と出力のJSONの全文
• 担当の採否の記録 … どの指摘を採り、直し、外したか、その理由
• 教員へ送った依頼文と、再提出されたシラバスとの対応
• 規定ごとの指摘の件数と、採られた割合

2つ目に「記載要領の版」を残すのは、要領が年度ごとに改められるためです。 前年度の点検結果を見返すときに、当時の規定が分からないと、指摘が正しかったかを判断できません。

最後の行は、記載要領を直す材料になります。 採られた割合が低い規定は、AIの読み方か、規定の書き方のどちらかに問題があります。 担当が毎回外している指摘は、規定の文言を見直す合図です。