生徒から質問フォームに届く質問を科目・単元・急ぎ具合で仕分けて担当講師へ回し、回答が遅れている質問を拾う

処理の起点を決める

質問フォームの送信を起点にします。 1件ずつ届いたその場で動かし、定時にまとめて振り分けることはしません。 テストの前日の夜に届く質問は、翌朝のまとめ処理では間に合わないことがあるからです。

遅れの検知は、別のトリガーで1時間ごとに動かします。 時間主導型のトリガーは毎分から月1回まで設定できます。質問の期限は時刻の単位で決めるので、1時間ごとにします。 回答用フォームの送信にも、もう1つトリガーを付け、台帳の「回答済み」を書き込みます。

トリガーが失敗しても、画面には何も出ません。 失敗したときは、Apps Script から失敗をまとめたメールが届きます。このメールの届き先を、運営部の共有アカウントにしておきます。 届かない人のアカウントで作ると、振り分けが止まっていることに誰も気づきません。

入力データを集める

質を決めるのは、単元一覧の「生徒が書きそうな言い方」の列です。 「二次関数」の単元に「放物線」「グラフの頂点」「平方完成」と書いておくと、生徒の書き方がばらばらでも単元が選べます。この列は、運営スタッフが過去の質問を見ながら埋めます。 AIの指示を直すより、この列を足すほうが早く効きます。

行事の予定は、期限の計算に使います。 「テスト前だから急ぎ」とAIに判断させるのではなく、教室の定期テストの日程をシートに持たせ、スクリプトが日付で比べます。

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

質問はフォーム送信のイベントから受け取ります。 回答のスプレッドシートを毎回上から読み直す必要はありません。

AIへ渡す単元は、その生徒の学年のものだけに絞ります。 全学年の単元を渡すと、中学1年の生徒の「方程式」に高校の単元を選ぶことがあります。選択肢を絞るのは、AIの精度を上げるいちばん確実な方法です。

生徒の名前はAIへ渡しません。 渡すのは、学年と、本文と、絞り込んだ単元一覧だけです。分類に名前は要りません。

台帳の行と回答用フォームは、質問の ID でつなぎます。 台帳に書き込むときに「教室コード＋日付＋連番」の ID を振り、講師へのメールの件名と本文の先頭に書きます。講師は回答用フォームでその ID と「回答済み」を送り、スクリプトが ID で台帳の行を探して印を付けます。 行の番号でつなぐと、運営スタッフが台帳を並べ替えたときに別の質問に印が付きます。ID が台帳に見つからない送信は、運営スタッフに回します。

AIへ渡す前に整形する

1. 同時の送信への備え … テスト前は質問が重なって届きます。スクリプトのロックを取ってから台帳に書き込みます
2. 生徒番号の照合 … 生徒の一覧に無い番号なら、分類をせず運営スタッフに回します
3. 本文の長さの確認 … 本文が極端に短い（「わかりません」だけなど）ものは、分類をせず「内容不足」として運営スタッフに回します
4. 個人情報の除去 … 本文に電話番号やメールアドレスのような文字列があれば、伏せてからAIへ渡します
5. 重複の検知 … 同じ生徒から同じ本文が数分以内に届いたものは、2件目を重複として印を付けます
6. 単元一覧の絞り込み … 学年で絞り、フォームで科目が選ばれていれば科目でも絞ります。ただし、科目の選択が誤っていることがあるので、科目で絞った結果で選べなければ学年だけで絞り直します

1番目を軽く見ないでください。 同じ時刻に2件の送信があると、トリガーも2つ同時に動きます。ロックを取らずに台帳の最終行を書くと、片方の行が上書きされて質問が1件消えます。 消えた質問は、誰にも回らず、遅れの検知にもかかりません。

AIに処理させる

させるのは、3つの分類と、期限の手がかりの書き出しです。

左上の「迷ったら consult」が、この構成でいちばん大事な決めごとです。 勉強の質問を相談と誤って分けると、教室長が1件余分に読むだけで済みます。相談を勉強の質問と誤って分けると、悩みの相談が大学生の講師に届きます。 誤りの重さが違うので、迷ったときの寄せ先を相談の側に決めます。

期限の手がかりは、日付に直させません。 「明日」が何日かは、送信日時から決まります。AIには本文の言葉のまま書き出させ、スクリプトが送信日時と行事の予定を使って日付にします。

2行目を最初から禁じておきます。 AIは質問の答えを書けてしまうので、指示が曖昧だと分類の結果に解き方を添えてきます。それをそのまま生徒に返す運用にすると、講師が確かめていない解き方が生徒に届きます。

指示内容を固定する

あなたは学習塾の質問窓口の受付係です。生徒から届いた質問を仕分けます。
質問に答えてはいけません。仕分けだけを行ってください。

【この生徒の学年】{grade}
【フォームで選ばれた科目】{subject_selected}（空欄や誤りのことがあります）
【この学年の単元一覧】{unit_list}
  （ID、科目、単元名、生徒が書きそうな言い方 の順）
【質問の本文】{question_text}

【kind の選び方】
- study ..... 教科の内容についての質問
- admin ..... 授業の日程、振替、教材の受け取りなどの事務
- consult ... 塾をやめたい、学校や家庭のこと、体調や気持ちについての相談
- other ..... 上のどれにも当たらない
勉強の質問か相談か迷ったときは consult を選んでください。

【厳守事項】
- unit_id は、上の単元一覧にある ID から1つだけ選んでください。
  一覧に無い単元を作らないでください。選べなければ unknown にしてください。
- フォームで選ばれた科目と本文の内容が食い違うときは、本文を優先し、
  subject_mismatch を true にしてください。
- 1つの質問に複数の単元が含まれるときは multi を true にし、
  いちばん中心の単元を unit_id にしてください。
- deadline_hint には、本文の中の期限を示す言葉を、本文のとおりに写してください。
  「明日」を日付に直さないでください。無ければ空にしてください。
- kind が study 以外のときは、unit_id を unknown にしてください。
- 質問への回答、解き方、ヒントを書かないでください。
- evidence には、判定の根拠にした本文の言葉をそのまま写してください。

「本文を優先し、subject_mismatch を立てる」は、科目の欄の誤りを拾うために入れます。 生徒はフォームの科目を前回のまま送ってくることがよくあり、欄を信じると、数学の質問が英語の講師に届きます。 食い違いを印として残すと、運営スタッフが単元一覧の言い方の列を見直す材料にもなります。

「ヒントを書かない」まで書くのは、「回答しない」だけでは足りないからです。 回答を禁じると、AIは「ヒント：まず平方完成をしてみましょう」のような一言を evidence に混ぜてきます。

出力形式を固定する

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

{
  "kind": "study | admin | consult | other",
  "unit_id": "M3-07",
  "subject_mismatch": false,
  "multi": false,
  "deadline_hint": "明日の小テスト",
  "evidence": ""
}

1つ目の理由は、単元を一覧の ID に縛れることです。 Gemini API の構造化出力では、response_format に MIME タイプ application/json とスキーマを渡します。スキーマは enum と required が使え、enum は分類の用途に挙げられています。 kind を4つに、unit_id をその学年の単元の ID と unknown に絞ったスキーマを、質問ごとにスクリプトで組み立てて渡します。

2つ目は、規則の側で期限を計算できることです。 スクリプトは次の規則で回答の期限を決めます。

数字は自社の運営の取り決めで置き換えてください。 大事なのは、期限を決める規則がシートとスクリプトにあり、AIの返す値に含まれていないことです。

3つ目は、値を必ず検査できることです。 Gemini API の案内でも、構造化出力の値はアプリケーションの側で検査すべきとされています。unit_id が渡した一覧に本当にあるか、kind が study 以外なのに unit_id が入っていないかをスクリプトで確かめ、外れたものは運営スタッフに回します。

システムへ連携する

API の呼び出しには UrlFetchApp.fetch を使い、muteHttpExceptions を true にします。 既定では、失敗の応答で例外が投げられて処理が止まります。true にすると失敗の応答もそのまま返るので、状態の番号を見て、台帳に「分類失敗」と書いてから運営スタッフに回せます。

メールの送信数には1日の上限があります。 Google Workspace のアカウントでは、メールの受信者が1日1,500人までとされています。テスト前に1日100件を超えても、講師への1通と教室長への知らせで届く範囲です。 上限は予告なく変わりうるとされているので、送信数を台帳に記録しておきます。

生徒への回答は、この構成から送りません。 生徒へ返すのは講師で、返す手段は今までどおりです。

人が確認する

運営スタッフが見るのは、次の4つに当たったものだけです。

1. consult に分けられたもの … 教室長が直接読みます。講師へ回すかどうかは、教室長が決めます
2. unit_id が unknown のもの … 運営スタッフが単元を選び、単元一覧の「生徒が書きそうな言い方」の列に、その質問の言葉を足します
3. subject_mismatch が立ったもの … 割り当ては本文の科目で済んでいます。週に一度まとめて見て、誤りがあれば講師を付け替えます
4. 期限を過ぎて回答済みでないもの … 講師に連絡し、つかまらなければ同じ科目の別の講師に付け替えます

2番目の後半を省かないでください。 unknown が出た質問の言葉を言い方の列に足すと、同じ言い方の質問は次から自動で振り分けられます。 足さないと、毎月同じ言い方で unknown が出続けます。

目標は、1,200件をならして1件30秒です。 4つに当たるのが全体の1割前後という想定です。それより多い月は、単元一覧の言い方の列が足りていないか、担当表が新しい学期に合っていません。 講師の側にも、割り当てが担当外だと思ったら「担当外」を回答用フォームで送れるようにしておき、送られた質問は運営スタッフが付け替えます。

例外に対処する

上から3行目と9行目が、運営の初めに多く出ます。 どちらもAIの問題ではなく、担当表と回答の記録の運用の問題です。 直すほうが、分類の精度を上げるより効きます。

記録を残す

• 質問の本文、送信日時、生徒番号（名前は台帳に持たない）
• AIが返したJSONの全文と、そのとき渡した単元一覧の版
• スクリプトが計算した回答の期限と、その根拠（手がかりの言葉・行事の予定）
• 割り当てた講師と、付け替えた記録
• 回答済みになった日時と、期限を過ぎていたか
• 単元ごとの unknown の件数と、subject_mismatch の件数

2つ目で「そのときの単元一覧の版」を残すのは、一覧が後から増えるためです。 言い方の列を足すと、同じ本文でも選ばれる単元が変わります。当時の一覧が残っていないと、振り分けの誤りの原因が一覧にあったのかAIにあったのかが分かりません。

最後の行は、単元一覧を育てる材料になります。 特定の単元で unknown が続くなら、生徒の言い方が一覧に足りていません。