授業記録から保護者へ毎月送る学習報告の下書きを生徒ごとに作り、退塾の兆しを教室長へ知らせる

処理の起点を決める

毎月1日の5時台に、前月分をまとめて処理します。 Apps Script の時間主導型トリガーで「月ごと」を選び、日と時刻を指定します。開始時刻は1時間の幅で揺れるため、講師が出勤して下書きを開くまでに処理が終わる時刻を選んでください。

月末の最終授業の記録が入りきってから動かすことが条件です。 月末の土曜に授業があり、講師がその記録を翌週に入れる運用なら、1日では早すぎます。「月末の授業の記録は、その日のうちに入力する」を先に決めてください。 決められないなら、トリガーを3日にずらします。

手動の起点も用意します。 転塾してきた生徒の初回報告や、記録を直したあとの作り直しのために、スプレッドシートのメニューから「この生徒だけ作り直す」を実行できるようにします。月次の処理と同じ関数を、生徒番号を1つ渡して呼ぶ形にします。

トリガーが失敗しても、画面にエラーは出ません。 失敗は Apps Script から届く通知メールで分かります。通知の宛先になるのはトリガーを作った人です。 教室長のうち1名のアカウントで作り、その人が休んでも誰かが見られるよう、通知メールの転送先を決めておきます。

入力データを集める

AIに渡すのは、このうち進度・一言所見・当月の目標・学年とコースだけです。 出欠と点数は、集計した値を「参考」として渡しますが、報告の数字の欄はAIの出力からではなく、集計結果から直接書き込みます。

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

授業記録： 講師が授業のあとにスプレッドシートへ1行ずつ入力します。1行が「1授業×1生徒」になる形にそろえてください。 1行に複数の生徒を書く形や、セルの中で改行して複数回分を書く形だと、集計ができません。フォームから入力させる場合も、回答がこの形のシートにたまるようにします。

一言所見の欄の書き方を、最初に決めます。 この欄が報告の所見の唯一の材料になります。「良かった点」「気になる点」「次回やること」の3つを、それぞれ短く書くルールにすると、AIが組み立てる文の偏りが減ります。空欄が続く生徒は、報告に書ける所見がありません。

生徒台帳： 氏名はこのシートに置き、授業記録には生徒番号だけを書きます。授業記録に氏名を書かないことで、AIへ送る経路から氏名を切り離せます。

前月の集計と当月の目標： 前月の処理で作った下書きシートと送付済みシートから読みます。「来月の目標」は保護者との約束なので、翌月の報告で必ず触れさせます。

AIへ渡す前に整形する

1. 当月の行の抽出 … 授業日で前月1日から末日までの行を取り出す
2. 集計（Apps Script の中で計算する） … 生徒ごとに出席・欠席・振替の回数、宿題の提出率、未提出の連続回数、小テストの点の一覧と平均、前月比を出す。AIに数えさせない
3. 兆しの判定（規則） … 次のどれかに当たれば要フォローにする。欠席が前月より2回以上増えた／欠席が2回続いた／宿題の未提出が3回続いた／小テストの平均が前月から15点以上下がった。閾値は設定シートに置き、教室長が変えられるようにする
4. 氏名と学校名の除去 … 一言所見の欄に講師がうっかり書いた生徒の名前、兄弟の名前、学校名を、生徒台帳と学校名の一覧で照合して「本人」「兄弟」「学校」に置き換える
5. 仮の番号への置き換え … 生徒番号を、その回の処理だけで使う連番に置き換える。対応表はスプレッドシートの中にだけ残す
6. メモの並べ替え … 一言所見を授業日の順に並べ、各行の頭に日付を付ける。AIが根拠を日付で示せるようにするため
7. 空欄の確認 … 一言所見が当月1件もない生徒は、AIへ送らない。下書きの所見欄を空にし、講師に「所見が記録されていません」と表示する

4番目の置き換えは、完全には防げません。 「Aちゃんと仲がいい」のように、台帳にない呼び名が書かれることがあります。講師への研修で「所見の欄に人の名前を書かない」を繰り返し伝えることのほうが効きます。

AIに処理させる

Apps Script（計算）にさせること：

生成AI（OpenAI API）にさせること：

「講師の気がかりの抜き出し」は、判定ではありません。 「退塾の可能性が高い」とは書かせず、メモにある文をそのまま拾わせるだけです。教室長は、規則で拾った数字と、講師が書いた原文を並べて見ます。 解釈は教室長がします。

成績の予測、志望校の合否、他の生徒との比較はさせません。 「このままなら偏差値が上がる」「クラスで上位」といった文は、メモからも記録からも導けません。

指示内容を固定する

あなたは学習塾の講師の補助として、保護者へ送る月次の学習報告の
「所見」の下書きを作ります。
下に与える講師のメモだけを材料にしてください。

【厳守事項】
- 講師のメモに書かれていないことを書かないでください。
  メモに「集中が続かない」とあれば書けますが、
  「家庭学習の時間が足りないためと思われます」のような原因の推測は書かないでください。
- 褒め言葉を足さないでください。
  メモに「計算ミスが減った」とあれば「計算ミスが減ってきました」と書けますが、
  「着実に力をつけています」「今後が楽しみです」のようにメモにない評価を加えないでください。
- 所見の各文には、根拠にしたメモの日付を source_dates に入れてください。
  根拠のない文は書かないでください。
- 小テストの点、出席や欠席の回数、宿題の提出率などの数字を、文章の中に書かないでください。
  数字は別の欄に表示されます。
- 本人以外の生徒、兄弟、学校、講師の名前を書かないでください。
  生徒は「本人」と表記し、文章では主語を省いてください。
- 成績の予測、合格の見込み、他の生徒との比較を書かないでください。
- 気になる点は、責める言い方にせず、事実と次にやることの形で書いてください。
  例：「宿題の途中で止まっている回がありました。次回は授業の最初に一緒に確認します」
- メモが少なく、所見が1文しか書けない場合は、1文だけにしてください。
  文を水増ししないでください。
- 前月の目標について、メモから達成の様子が分からない場合は、
  previous_goal_note に null を入れてください。

【継続に関わる記述】
- メモの中に、部活・体調・通塾の負担・やる気・家庭の予定など、
  通塾の継続に関わりそうな記述があれば、原文のまま concern_quotes に入れてください。
- それが退塾につながるかどうかを判断しないでください。

【文体】
- 保護者に向けた丁寧語。一文は60字以内。
- 専門用語は保護者が分かる言葉に言い換える。

【生徒の情報】
学年：{grade}
コース：{course}

【今月の進度（単元名、授業日の順）】
{progress}

【講師のメモ（授業日：良かった点／気になる点／次回やること）】
{notes}

【前月の報告に書いた来月の目標】
{previous_goal}

【参考：今月の集計（文章には書かない）】
{metrics}

「数字を文章の中に書かない」の1行が、この構成の要です。 数字を文章に書かせると、AIが写し間違えたときに報告の表と本文で数字が食い違います。表の数字は記録から、本文は言葉だけ、と分けると、点数の誤りは原理的に起きなくなります。 それでも集計を「参考」として渡すのは、「点が大きく下がった月に『順調です』と書く」のを防ぐためです。

「褒め言葉を足さない」も必須です。 指示しないと、言語モデルは報告らしい締めの一文を足します。400通すべてが「今後の成長が楽しみです」で終わると、保護者は定型文だと気づきます。 講師が自分の言葉で最後の1行を足す余地を、AIが埋めてしまわないようにします。

「1文しか書けないなら1文だけ」を入れないと、メモが空に近い生徒ほど一般論で膨らみます。 所見が短い報告は、講師がメモを書いていないことを示す信号です。短いまま講師の画面に出し、講師に書き足させてください。

学年によって、読み手が変わります。 小中学生なら保護者、高校生や社会人の語学受講者なら本人が読みます。設定シートに「読み手」の列を持たせ、プロンプトの【文体】を差し替えます。

【文体（受講者本人が読む場合）】
- 受講者本人に向けた丁寧語。二人称は使わず、主語を省く。
- 気になる点は、次回に一緒に取り組む内容として書く。

出力形式を固定する

{
  "type": "object",
  "additionalProperties": false,
  "required": ["student_ref", "learning_summary", "observations", "previous_goal_note", "next_goal_draft", "concern_quotes", "insufficient_notes"],
  "properties": {
    "student_ref": { "type": "string" },
    "learning_summary": { "type": "string" },
    "observations": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["kind", "text", "source_dates"],
        "properties": {
          "kind": { "type": "string", "enum": ["良かった点", "気になる点", "次にやること"] },
          "text": { "type": "string" },
          "source_dates": { "type": "array", "items": { "type": "string" } }
        }
      }
    },
    "previous_goal_note": { "type": ["string", "null"] },
    "next_goal_draft": { "type": ["string", "null"] },
    "concern_quotes": {
      "type": "array",
      "items": {
        "type": "object",
        "additionalProperties": false,
        "required": ["date", "quote"],
        "properties": {
          "date": { "type": "string" },
          "quote": { "type": "string" }
        }
      }
    },
    "insufficient_notes": { "type": "boolean" }
  }
}

OpenAI API の Responses API では、text: { format: { type: "json_schema", strict: true, schema: ... } } の形でスキーマを渡します。required に全項目を挙げ、additionalProperties を false にします。 値が無いことがある項目は、previous_goal_note のように型を ["string", "null"] にして null を許します。

安全上の理由で応答が拒否されると、スキーマに沿った出力の代わりに refusal が返ります。 出力の上限で切れた場合は、応答の status が incomplete、理由が max_output_tokens になります。どちらも、その生徒の下書きを空にして「作成できませんでした」と表示し、講師に手で書いてもらいます。 途中まで出た文を下書きに使わないでください。

source_dates が、講師の確認を速くします。 下書きの画面で所見の横に「10/7、10/21のメモ」と出れば、講師は該当の行だけを見て確かめられます。スクリプトは、source_dates の日付がその生徒の当月の授業日に含まれるかを検査します。 含まれない日付があれば、その文に印を付けます。

insufficient_notes は、メモが少なすぎて所見が組めない場合に true になります。 講師ごとにこの数を数えると、メモを書く習慣が定着していない講師が分かります。 ただし、これを講師の評価に使わないでください（第13章）。

システムへ連携する

下書きは、講師ごとのシートに1生徒1行で並べます。

AIの出力を報告の文へ戻すときに、仮の番号を生徒名に戻します。 「本人」と書かれた文はそのまま使えるので、名前を文の中へ差し込む処理は要りません。

出力の検査は3つです。 1つ目は、所見の文に数字が含まれていないか。単元名に含まれる「一次関数」のような語は除き、算用数字を拾います。2つ目は、source_dates が当月の授業日に含まれるか。3つ目は、生徒台帳の氏名や学校名が文に現れていないか。どれかに当たった行は「検査の印」列に理由を書き、講師が必ず直す行として色を付けます。

要フォロー一覧は、教室長だけが見られる別のファイルに書きます。

保護者への報告には、この一覧の内容を1文字も載せません。 報告の下書きシートと要フォロー一覧を別のファイルにするのは、コピーの誤りで「要注意」の文字が保護者へ届く経路をなくすためです。

送付は、既存の保護者連絡アプリで人が行います。 承認済みの行の文面をコピーして送り、状態を「送付済み」にします。送付の自動化は、この構成に含めません。 連絡アプリの側に送信の API があっても、最初の半年は人が送ってください。

人が確認する

400通すべてを講師が読みます。 保護者へ届く文章に、読まれていないものを混ぜないためです。ただし、読み方の深さを分けます。

• 検査の印が付いた行 … 数字の混入、日付の不一致、名前の混入のどれか。必ず直す
• 所見に「気になる点」がある行 … 言い方が保護者を責める調子になっていないか。声に出して読む
• insufficient_notes が true の行 … 講師が所見を自分で書く
• 要フォロー一覧に載っている生徒の行 … 報告の書きぶりを教室長と相談してから送る
• それ以外 … 根拠の日付のメモと見比べ、講師のひとことを足して確認済みにする

教室長の承認は、講師の確認より軽くしてよい部分があります。 数字は記録からの転記なので、照合は要りません。教室長が見るのは、所見の言い方と、要フォローの生徒の扱いです。

確認を速くするための設計が効きます。

• 講師ごとにシートを分ける（自分の担当分だけを開く）
• 検査の印の行を上に固定する
• 所見の横に、根拠の日付のメモを並べて表示する
• 前月の報告の所見を併記する（同じ言い回しの繰り返しに気づく）
• 状態の列を選択式にし、未確認の件数を上に出す

3つ目がもっとも効きます。 所見とメモが隣にあれば、「メモにないことが書かれていないか」は数秒で分かります。

例外に対処する

処理時間に注意してください。 1名ずつ API を呼ぶと、400名で時間がかかります。教室ごとに実行を分けるか、途中までの進み具合をスプレッドシートに記録して、次の実行で続きから処理する形にします。 すでに下書きがある生徒は飛ばす作りにすれば、再実行しても二重にはなりません。

記録を残す

• 月ごとの集計結果（生徒ごとの出欠・宿題・小テスト）
• AIへ送った内容（仮名化した後のもの）と、返ってきたJSON
• 検査の印の内容と、講師がどう直したか
• 講師が確認した日時、教室長が承認した日時、送付した日時
• 要フォロー一覧と、教室長の対応
• 使ったプロンプトの版

「AIの下書き」と「送付した文」を両方残してください。 講師が毎月同じ箇所を直しているなら、プロンプトのほうを直すべきです。差分が大きい講師と小さい講師を比べると、メモの書き方の違いが見えてきます。

要フォロー一覧の対応と、その後の結果を残します。 半年たつと、「欠席増で載った生徒のうち、何人が退塾したか」が分かります。規則の閾値が合っているかは、この記録でしか確かめられません。

OpenAI API へ送った内容の保存期間も決めます。 Responses API は既定で応答を30日保存し、store を false にすると保存しない指定になります（第13章）。自社側のログは、仮名化した後の内容だけを残します。