音楽教室が体験レッスンの申込を Make で受け、AI で希望の楽器・経験・曜日から講師の候補を絞って案内のメールを作る

処理の起点を決める

フォームの新しい回答を起点にします。 Make の Google Forms のアプリの Watch Responses で、体験の申込のフォームを見張ります。実行の間隔は15分にします。 申込は夜と週末に多いので、事務が出勤したときには案内の下書きがそろっている状態にします。

日程の変更の連絡は、別の入口にします。 代表アドレスに届く返信は、Gmail の Watch emails で「体験の返信」のラベルを見張り、体験の記録の行に紐づけて事務に知らせるだけにします。 変更の連絡からもう一度候補を作るのは、事務が記録の行の状態を「再案内」に変えたときだけです。

入力データを集める

質を決めるのは、講師の一覧の区分の列です。 「幼児のピアノを持つか」「受験の指導をするか」を、講師ごとに1つずつ「はい／いいえ」で埋めます。 ここが空いている講師は、絞り込みで一度も候補に上がりません。最初は、長く勤める事務の頭の中にある「この先生はこれを持つ」を書き出す作業になります。

今月の体験の担当数は、候補を選ぶ順に使います。 同じ講師ばかりに体験が回ると、その講師の週の予定が体験で埋まり、在籍の生徒のレッスンの振替が取れなくなります。 担当数の少ない講師から候補に並べます。

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

Free/Busy の問い合わせには、時刻の幅とタイムゾーンを必ず入れます。 Google Calendar API の公式のページでは、timeZone は応答に使うタイムゾーンで、省略すると UTC になるとされています。日本時間の夕方のレッスンが UTC の朝の時刻として返り、希望の時間帯と比べる段で9時間ずれます。 timeZone に Asia/Tokyo を入れ、timeMin と timeMax も +09:00 を付けた形で渡します。

一度に問い合わせるカレンダーの数には上限があります。 公式のページでは、calendarExpansionMax（情報を返すカレンダーの数の上限）の最大は50です。この教室の講師18名なら1回で足りますが、絞り込みの後の講師だけを問い合わせる形にしておけば、講師が増えても変わりません。

AIへ渡す前に整形する

1. 重複の確認 … 送信の時刻とメールアドレスで体験の記録を引き、記録があれば止めます
2. 選択式の欄をコードにする … 楽器と経験の選択肢を、区分の一覧のコードに置き換えてから渡します
3. 学年を年齢層に直す … 学年の欄から幼児・小学生・中高生・大人を、ワークフローの対応表で決めます。AIに年齢を推し量らせません
4. AIに渡す範囲を絞る … 申込者と生徒の名前、メールアドレスは渡しません。分類に要るのは、選択式の欄のコードと自由記述と年齢層だけです
5. 希望の曜日と時間帯を時刻の幅にする … 「平日の夕方」を、教室の決まりで「月〜金の16時〜19時」のような幅に直します

3番目をワークフローに置くのは、生徒の多くが子どもだからです。 学年の欄は保護者が選ぶので、その値を対応表で年齢層に直すほうが、自由記述から推し量るより確かです。 自由記述に「小3の息子」とあり、学年の欄が「小学4年」なら、学年の欄を使い、食い違いの印を付けます。

4番目で名前を渡さないのは、分類に名前は要らないからです。 案内のメールの宛名は、下書きを作るときにワークフローが差し込みます。

AIに処理させる

1回目の呼び出しでさせるのは、区分の一覧のコードから選ぶことだけです。

returning を experienced と分けるのは、担当できる講師が違うからです。 子どものころに習っていて20年ぶりに再開する大人は、楽譜は読めても指が動かないことが多く、大人の初心者を持つ講師のほうが合うことがあります。どちらを担当させるかは講師の一覧の列で決めますが、分類の段で分けておかないと、選べません。

2回目の呼び出しでさせるのは、渡した候補だけを使って案内を書くことです。 候補の日時、教室の住所、持ち物、体験の長さは、ワークフローが表にして渡します。

指示内容を固定する

1回目（分類）：

あなたは音楽教室の事務として、体験レッスンの申込を分類します。
下に渡す区分の一覧のコードから選んでください。一覧に無いコードを
作らないでください。講師や日時は決めないでください。

【すること】
1. instrument：楽器のコードを1つ選ぶ。決めていない・2つで迷っている
   ときは undecided、一覧に無い楽器は not_offered。
2. experience：beginner／experienced／returning から選ぶ。
   選択式の欄と自由記述が食い違うときは、自由記述を採り、
   conflict を true にする。
3. purposes：目的のコードを、書かれているものだけ選ぶ。
4. special_requests：受験、配慮の相談、楽器の購入の相談など、
   講師を決める前に事務が見るべきことを、文のとおりに写す。
5. evidence：区分を決めた自由記述の文を、そのまま写す。

【厳守事項】
- 年齢層は渡した値をそのまま使う。自由記述から年齢を推し量らない。
- 書かれていない目的を足さない。「楽しく」だけなら purposes は
  hobby だけにする。
- 生徒の才能、向き不向き、上達の見込みを書かない。
- 講師の名前、日時、月謝を書かない。

【区分の一覧】{categories}
【年齢層（対応表で決めた値）】{age_band}
【選択式の欄（コード）】{selected}
【自由記述】{free_text}

2回目（案内）：

あなたは音楽教室の事務として、体験レッスンの案内のメールを書きます。
下に渡す「候補の日時」だけを使ってください。候補に無い日時、
講師、教室を書かないでください。

【書くこと】申込のお礼／候補の日時（渡した順に、講師の名前と教室を
添えて）／体験の長さと持ち物／都合のよい候補を返信で知らせてほしいこと／
どの候補も合わないときは希望の曜日を知らせてほしいこと

【厳守事項】
- 候補の日時は、渡した文字列をそのまま写す。曜日を書き直さない。
- 入会、月謝、割引について書かない。
- 宛名は {recipient} と書き、名前を入れない。

【候補の日時】{slots}
【教室の情報（住所・持ち物・体験の長さ）】{school_info}
【申込の区分】{classification}

「一覧に無いコードを作らない」を書くのは、楽器の名前がそのまま返るのを防ぐためです。 「エレキギター」と書かれた申込に、guitar ではなく electric_guitar を返すと、講師の一覧のどの列とも一致せず、候補の講師が0人になります。 スキーマの enum で値を縛ったうえで、指示でも縛ります。

「候補の日時は文字列をそのまま写す」は、照合のための1行です。 AIは「11月18日（火）17:00」を「11月18日（火曜日）午後5時」に整えます。整えられると、ワークフローの文字の照合を通らず、すべてが事務の確認に回ります。

出力形式を固定する

1回目は次の形の JSON を返させます。

{
  "instrument": "piano | violin | guitar | vocal | drums | flute | sax | ukulele | undecided | not_offered",
  "experience": "beginner | experienced | returning",
  "conflict": false,
  "purposes": ["hobby"],
  "special_requests": "",
  "evidence": ""
}

2回目は、body（本文）と slots_used（使った候補の文字列の配列）を返させます。 slots_used の各要素が、渡した候補の文字列と一致するかをワークフローが確かめ、本文の中にその文字列が含まれるかも確かめます。

構造化出力にする1つ目の理由は、講師の一覧の列とそのまま突き合わせられることです。 instrument と experience は区分の一覧のコードなので、講師の一覧の列の値と文字で比べるだけで絞り込めます。 OpenAI の構造化出力は、スキーマに合う応答を返す機能で、strict を true にして使います。

2つ目は、値の無い項目の扱いを決めておけることです。 公式のページでは、構造化出力ではすべての項目を required にする必要があり、省略してよい項目は null との組み合わせの型で表すとされています。special_requests は空文字で返させ、欄そのものが返らないことで後段が止まる形にしません。 オブジェクトには additionalProperties: false を付けます。

3つ目は、拒否を見分けられることです。 公式のページでは、安全上の理由で応答を拒んだことをプログラムで見分けられるとされています。拒否が返ったときは分類を使わず、事務の確認に回します。

システムへ連携する

ルーターのルートは、担当の確認→日時の不一致→通常→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータをフォールバックのルートが処理するとされています。担当の確認に回すのは、undecided・not_offered・special_requests があるもの、絞り込みで講師が0人のもの、14日間に候補が1つも無いものです。

この構成は案内を自動では送りません。 体験の案内は、教室と家庭の最初のやり取りです。下書きを事務が見て送る形にし、送るのは人にします。

人が確認する

事務が確かめるのは、下書きの全件と、担当の確認に回ったものです。

1. 担当の確認に回ったものを先に見る … 楽器が未定の家庭には、電話で楽器選びの相談を勧めます。受験や配慮の相談は、主任の講師に回します
2. 下書きの区分と候補を見る … 区分の根拠の文を読み、候補の講師がその区分に合うかを見ます
3. conflict の印を見る … 選択式の欄と自由記述が食い違った申込は、採った区分が正しいかを根拠の文で確かめます
4. 送る … Gmail の画面から送り、体験の記録の状態を「案内済み」にします

返事で日時が決まったら、講師のカレンダーへの予定の登録は事務が行います。 返事が来るまでの間に、候補の時間に講師の別の予定が入ることがあるからです。登録の前に、その講師の空きをもう一度確かめます。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、フォームの選択肢と講師の一覧の列の作り方の問題です。 講師が0人になる申込が続く区分は、講師の一覧のその列がまだ埋まっていません。

Free/Busy の応答には、カレンダーごとにエラーが入ることがあります。 公式のページでは、カレンダーの情報を作れなかったときに errors が返り、notFound などの理由が付くとされています。エラーの講師を「空いている」と読まないように、busy が空でも errors があれば候補から外します。

記録を残す

• 申込の元の回答（選択式の欄と自由記述）
• 1回目の JSON の全文（区分・conflict・根拠）
• 絞り込みに使った講師の一覧の版と、絞り込みの結果の講師
• Free/Busy を引いた日時と、候補にした日時
• 2回目の JSON と、日時の照合の結果
• 事務が区分や候補を直した記録と、送った案内の本文

3つ目で講師の一覧の版を残すのは、講師の担当が学期ごとに変わるからです。 「先月は幼児のピアノにこの先生を案内された」と言われたとき、そのときの一覧で選ばれたことが分かります。

最後の行は、区分の一覧を直す材料になります。 事務が同じ区分を何度も直しているなら、区分の分け方か選択式の欄の選択肢が、申込の書き方に合っていません。