教員から Google Chat に届く出張・休暇・物品・会計の手続きの質問に、学校の事務の手引きを根拠に答え、手引きに無いものを事務室へ回す

処理の起点を決める

教員がアプリにメッセージを送ったときに動きます。 教員は、アプリとの1対1のチャットに書くか、学年のスペースでアプリを指名して書きます。このアプリは1対1のチャットだけで使う設定にします。 学年のスペースで答えると、休暇の理由などを他の教員に見せることになるためです。

事務室の勤務時間外も動かします。 夜や週末に書かれた質問にも答え、回すものは翌朝の受付シートに並びます。回したときの返事には「事務室は翌開室日の朝に確認します」と書き、すぐに答えが来ると思わせないようにします。

定時のトリガーを1つだけ置きます。 毎朝7時台に、手引きのドキュメントの最終更新日を見て、変わっていれば節の一覧のシートを作り直します。作り直しの途中で質問が来たときは、古い一覧で答えます。 節の一覧は新しいものを別のシートに作り、終わってから入れ替えます。

入力データを集める

質を決めるのは、手引きの節の一覧のキーワードの欄です。 教員は「年休」「有休」「休みの届」と書き、手引きの見出しは「年次休暇の申請」です。見出しの語だけで節を選ぶと、近い節が選ばれません。 事務室が、教員が実際に使う言い方を節ごとに5〜10語書き足します。

判断を回す一覧は、事務長と決めます。 「どこまでをアプリが答え、どこからを事務室が受けるか」を、AIの判断ではなく学校の取り決めとして持ちます。

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

質問は、Chat のイベントから取り出します。 メッセージの本文、送った人、スペースの種類をイベントから読みます。スペースが1対1のチャットでなければ、「1対1のチャットで聞いてください」とだけ返して終わります。

節の候補は、スクリプトで選びます。 質問の語と、節の見出し・キーワードが重なる数を数え、上位5節を取ります。直近のやり取りに出た節は、必ず候補に残します。 聞き返しへの返事（「宿泊です」）だけでは、どの節の話か分からないためです。

手引きのドキュメントからの節の一覧づくりは、毎朝の定時の処理で行います。 見出しのスタイルで節を区切り、本文・様式名・締切を列に分けて書き出します。質問のたびにドキュメントを読むと、30秒の中に収まりません。

キーワードの欄だけは、毎朝の作り直しで上書きしないようにします。 ドキュメント側に無い、事務室が足した列だからです。節の番号で前の一覧から引き継ぎます。

AIへ渡す前に整形する

1. スペースの確認 … 1対1のチャットでなければ答えません
2. 個人の事情の目印 … 本文に病名・家族の状態などの語があれば、AIへ渡す前に「（個人の事情）」に置き換えます。手続きを答えるのに、事情の中身は要りません
3. 会話のつなぎ … 直近のやり取りが30分以内なら同じ話の続きとし、それより前なら新しい質問として扱います
4. 節の候補の選び出し … 見出しとキーワードの一致の数で上位5節。一致が1つも無ければ、AIを呼ばずに事務室へ回します
5. 節の本文の切り詰め … 5節の本文の合計が長すぎる場合は、手順・様式名・締切の欄だけを渡します
6. 判断を回す一覧の添付 … 一覧の全文を毎回渡します

4番目で AI を呼ばないのは、根拠の無い答えを作らせないためです。 一致する節が無い質問は、手引きに書いていない可能性が高く、AIに渡すと一般的な知識で答えを組み立ててしまいます。

AIに処理させる

させるのは、選ばれた節だけを根拠に、答えるか、聞き返すか、事務室へ回すかを選び、その中身を書くことです。

聞き返しは1回に1つの条件だけにさせます。 「日帰りか宿泊か、県内か県外か、引率か」を一度に聞くと、教員は授業の合間に答えきれません。答えを分ける条件のうち、節の分かれ目に近いものから1つずつ聞きます。 3往復で条件がそろわなければ、事務室へ回します。

やり取りは、たとえば次のようになります。

2回目の聞き返しは、1回目の返事を受けて選んだものです。 日帰りなら県内・県外で手順が分かれない節もあり、その場合は2回目を聞かずに答えます。 どの条件で節が分かれるかは、節の本文の書き方で決まります。

3行目がいちばん起きやすい失敗です。 「○○市への出張の旅費はいくらになりますか」と聞かれると、AIは手引きの日当の表から金額を組み立てようとします。経路や時間帯で金額が変わり、誤った金額を教員が覚えると精算のときにもめます。 金額は「精算のときに事務室が確かめる」と答えさせ、手順だけを案内します。

指示内容を固定する

あなたは中学・高校の事務室の、教員向けの手続きの案内役です。
下の【手引きの節】だけを根拠に、教員の質問に応じてください。

【応じ方】次のどれか1つを mode に入れてください。
- answer ... 節に手順が書いてあり、答えに要る条件がそろっている
- clarify .. 節の手順が条件で分かれ、その条件がまだ分からない
- escalate . 節に書いていない／【事務室へ回す事柄】に当たる／節どうしが食い違う

【厳守事項】
- 【手引きの節】に書いていない手順・様式・締切を書かないでください。
  一般的な学校の慣行や、ほかの学校の例で補わないでください。
- 答えるときは、根拠にした節の番号を cited_sections に必ず入れてください。
  節の番号を挙げられない答えは書かず、escalate にしてください。
- 聞き返すときは、条件を1つだけ聞き、選択肢を2〜4個付けてください。
- 出張や休暇を認めるか、校費で払えるか、休暇の事由に当たるかは判断せず、
  escalate にしてください。
- 旅費・日当などの金額を計算しないでください。
- 「（個人の事情）」の中身を推測したり、尋ねたりしないでください。
- 迷ったときは answer を選ばず、escalate にしてください。

【事務室へ回す事柄】{escalation_rules}
【直近のやり取り】{history}
【手引きの節】{sections}
【教員の質問】{question}

「迷ったときは answer を選ばない」を明記しないと、AIは答えるほうに寄ります。 案内役として作られた指示は、回すより答えることを良いことと受け取りがちです。誤った案内の1件は、回した10件より事務室の手間を増やします。

「節の番号を挙げられない答えは書かない」は、スクリプトの照合とつながっています。 cited_sections が空の answer は、スクリプトの側で escalate に置き換えます。

出力形式を固定する

次の形のJSONで受け取ります。 Claude API の構造化出力を使い、要求の output_config の format に type を json_schema として下の形のスキーマを入れます。

{
  "mode": "answer | clarify | escalate",
  "category": "travel | leave | purchase | accounting | other",
  "answer": {
    "steps": ["", ""],
    "form_names": [""],
    "deadline": "",
    "cited_sections": ["2-3"]
  },
  "clarify": { "question": "", "options": ["", ""] },
  "escalate": {
    "reason": "not_in_manual | judgment_required | conflicting_sections",
    "known_conditions": [""],
    "nearest_sections": [""]
  }
}

1つ目の理由は、cited_sections をスクリプトで照合できることです。 挙げられた節の番号が、渡した5節の中に本当にあるかを確かめ、無い番号を挙げた答えは escalate に置き換えます。 様式名も、その節の様式名の欄と一致するかを確かめます。

2つ目は、mode ごとに Chat の返し方を変えられることです。 answer は手順と様式名と、共有ドライブの様式へのリンクをスクリプトが足して返します。clarify は選択肢を並べ、escalate は「事務室に回しました」と受付の番号を返します。リンクはAIに書かせず、節の一覧の様式の欄からスクリプトが付けます。

3つ目は、known_conditions で事務室が聞き直さずに済むことです。 「宿泊あり」「県外」「生徒の引率なし」と分かっていれば、事務職員は受付シートを読むだけで答えに入れます。

システムへ連携する

UrlFetchApp.fetch() は、method に post、contentType に JSON、headers に API キー、payload に要求の本文を入れて呼びます。muteHttpExceptions を true にして、失敗の応答でも例外で止まらないようにします。 失敗したときは「いまは答えられないので事務室に回しました」と返し、受付シートに書きます。

API キーと Webhook の URL は、スクリプト プロパティに置きます。 スクリプト プロパティはスクリプトのすべての利用者で共有されるため、スクリプトの編集権限は事務室と情報担当の教員に限ります。

事務室のスペースへの知らせには、教員の名前と質問の分類だけを書きます。 質問の本文は受付シートで読みます。休暇の質問の中身を、スペースの全員に流さないためです。

人が確認する

AIの答えを、教員に返す前に人が見ることはしません。 授業の合間に答えが要る質問で、人の確認を挟むとアプリの意味がなくなるためです。その代わりに、答えてよい範囲を節の根拠で絞り、後から記録を見ます。

1. 回された質問に答える … 事務職員が受付シートを見て、教員に Chat で答えます
2. 手引きに節を足す … 同じ質問が2回回されたら、手引きに節を足すかを事務長と決めます
3. 答えた記録を週1回見る … 教員が「解決しなかった」を押したものと、根拠の節が1つだけの答えを読みます
4. 誤った案内を直す … 誤りがあれば、その教員に正しい案内を送り、節の本文かキーワードを直します

答えの最後には「解決した／解決しなかった」のボタンを付けます。 押されたかどうかを答えた記録に残し、「解決しなかった」は翌朝の受付シートにも並べます。

目標は、300件をならして1件2分です。 回されたものは事務職員が答えるので数分、アプリが答えたものは週1回の見直しで数十秒です。回される割合が3割を超える月は、キーワードの欄が足りていないか、手引きに無い手続きが増えています。

例外に対処する

3行目は、この構成でいちばん気にする例外です。 節の候補の選び出しをスクリプトで先に済ませ、AIに渡す本文を短くすると、多くの質問は30秒の中に収まります。 それでも間に合わない質問は、半自動化の段階では事務室に回して取りこぼしを防ぎます。

記録を残す

• 質問の本文（個人の事情を置き換えたもの）、送った人、日時
• 選んだ節の候補と、AIが返したJSONの全文
• 教員に返した答え・聞き返し・受付の番号
• 「解決した／解決しなかった」の記録
• 回した質問と、事務職員が答えた内容、手引きに節を足したかどうか
• 答えたときに使った節の一覧の改訂日

最後の行は、改訂のあとに誤った案内を探すときに使います。 締切が変わった節について、改訂前の一覧で答えた記録を抜き出し、その教員にだけ正しい締切を送り直せます。

節ごとの質問の数は、手引きの改訂の材料になります。 質問が多い節は、本文が分かりにくいか、見つけにくい場所にあります。