ピアノ調律の事業者が調律の依頼を Make で受け、AI で前回の記録と地域から訪問の日程の候補と案内のメールを作る

処理の起点を決める

フォームの新しい回答と、代表アドレスへの依頼のメールの2つを起点にします。 フォームは Google Forms のアプリの Watch Responses で見張り、メールは Gmail の Watch emails で「調律の依頼」のラベルを見張ります。ラベルは、前回の案内のメールの件名への返信と、件名や本文に「調律」が含まれるものに付けます。

実行の間隔は30分にします。 調律は急ぎの依頼が少なく、候補を出すときの調律師の予定が新しいことのほうが大事です。 30分おきなら、事務が下書きを開いたときに、候補が埋まっていることはまず起きません。

日程の変更の連絡は、同じ入口で受けます。 依頼の記録に同じ顧客の「案内済み」の行があれば、前の候補を外して、新しい候補で案内を作り直します。

入力データを集める

質を決めるのは、調律師が書く所見の書き方です。 所見は案内のメールにそのまま引用されることがあるので、「顧客に伝えてよいこと」と「調律師どうしの申し送り」を分けて書く決まりにします。調律の記録に「顧客向けの所見」と「社内の申し送り」の2つの列を作り、AIに渡すのは顧客向けの所見だけにします。

作業の表は、例えば次のように持ちます。

いちばん下の行は、作業の時間が読めないからです。 長く調律していないピアノは、音の高さが大きく下がっていて、1回で合わせきれないことがあります。 時間を決めて候補を出すと、当日に予定が崩れます。

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

顧客の台帳は、名前では引きません。 名前は書き方の揺れが大きく、同姓の顧客もいます。メールアドレス、電話番号、郵便番号と番地の順に引き、どれでも1件に決まらなければ事務の確認に回します。 1台の家に2台のピアノがあるときも、どちらの依頼かが決まらないので事務へ回します。

Free/Busy の問い合わせには、timeZone に Asia/Tokyo を入れます。 Google Calendar API の公式のページでは、timeZone は応答に使うタイムゾーンで、省略すると UTC になるとされています。午後の訪問の枠が9時間ずれ、夜中の時刻に空きがあるように見えます。 timeMin と timeMax にも +09:00 を付けます。

空きの計算は、ワークフローの式で行います。 訪問の曜日に当たる日だけを取り出し、訪問に使う時間（例：9時半〜17時）から busy を引いて、作業の時間に移動の余裕30分を足した長さが続けて取れる日を、早い順に3つまで候補にします。 希望の曜日があれば、その曜日に当たる候補を先に並べます。

AIへ渡す前に整形する

1. 重複の確認 … フォームは送信の時刻、メールはメッセージIDで依頼の記録を引き、記録があれば止めます
2. 返信の引用を落とす … 前回の案内のメールへの返信には、前回の案内の全文が付いてきます
3. 町名を取り出す … 住所から町名を取り出し、地域の対応表を引きます。境目の町は対応表に番地の範囲まで書きます
4. 前回からの年数を出す … 前回の調律の日から今日までの年数を、ワークフローが計算します
5. AIに渡す範囲を絞る … 名前、住所、電話番号、メールアドレスは渡しません。渡すのは、候補の日程、作業の時間、ピアノの種類、前回の調律の年月、顧客向けの所見、依頼の「気になること」の欄、準備のお願いの定型の文だけです

4番目をAIに任せないのは、年数で作業の時間が変わるからです。 前回が「2024年11月」なら、今日から何年かを数えるのは式の仕事です。AIが数え違えると、作業の表の別の行の時間で候補を出すことになります。

5番目で住所を渡さないのは、案内の文に住所は要らないからです。 宛名と訪問先の住所の確認の文は、下書きを作るときにワークフローが差し込みます。

「気になること」の欄には、家族の事情が書かれることがあります。 「子どもが受験で毎日弾いている」「介護のため午前は難しい」のような文です。曜日や時間の希望に関わる部分は、事務が候補を選び直す材料で、AIに案内の文で触れさせる必要はありません。 指示では「気になること」をピアノの音や鍵盤の話に限って扱わせ、それ以外の事情は needs_attention に「日程の事情の記載あり」とだけ書かせて事務に回します。

AIに処理させる

させるのは、渡した材料だけを使って案内のメールを書くことです。

所見の引用は、quotes という欄に1つずつ写させます。 ワークフローが、その文字列が渡した所見の中にそのまま含まれるかを確かめます。含まれていなければ、案内が正しそうに見えても事務の確認に回します。

指示内容を固定する

Instructions の欄（最初に置く指示）：

あなたはピアノ調律の事業所の事務として、調律の依頼をくださった方への
案内のメールを書きます。下に渡す材料だけを使ってください。
材料に無いことは書かないでください。

【書く順】
1. 依頼のお礼。前回の調律の年月があれば「前回は○年○月に
   伺いました」と書く。
2. 訪問の日程の候補を、渡した順に箇条書きで書く。
3. 作業の時間を「約○分」と書く。
4. 前回の所見があれば、当日までにしていただきたいことを書く。
5. 「気になること」の欄があれば、当日拝見してご相談する旨を書く。
6. 準備のお願いの文を、そのまま書く。
7. 都合のよい候補を返信で知らせてほしいこと、どの候補も合わない
   ときは希望の曜日を知らせてほしいことを書く。

【厳守事項】
- 候補の日程は、渡した文字列を1文字も変えずに写す。曜日や時刻の
  書き方を整えない。
- 前回の所見を使うときは、所見の文をそのまま quotes に写す。
  所見に書かれていない、ピアノの状態や原因を書かない。
- 「気になること」に対して、原因や直し方を書かない。
- 「気になること」のうち、ピアノの音や鍵盤以外の事情には触れず、
  needs_attention に「日程の事情の記載あり」と書く。
- 整音・整調・修理を勧めない。所見に「次回相談」とあるときだけ、
  「当日、調律師からご相談します」と書く。
- 料金、割引、保証について書かない。
- 宛名は {recipient}、料金の案内は {price_text} と書き、
  中身を入れない。

入力の欄（依頼ごとに差し込むもの）：

【候補の日程】{slots}
【作業の時間】{duration}
【ピアノの種類】{piano_type}
【前回の調律の年月】{last_tuned}
【顧客向けの所見】{notes_for_customer}
【気になること】{concern}
【準備のお願い】{preparation}

「1文字も変えずに写す」を書くのは、照合をワークフローの文字の比較で行うからです。 AIは「11月20日（木）13:30〜」を「11月20日（木曜日）午後1時30分から」に整えます。整えられると照合を通らず、すべてが事務の確認に回ります。

「原因や直し方を書かない」を名指しで禁じるのは、AIが親切に答えようとするからです。 「最近、ペダルを踏むとキーキー鳴る」と書かれていると、よくある原因と直し方を書き添えます。 当日に別の原因だったとき、案内の文が約束のように残ります。

出力形式を固定する

次の形の JSON を返させます。

{
  "subject": "",
  "body": "",
  "slots_used": ["11月20日（木）13:30〜"],
  "quotes": ["湿度が高い部屋。梅雨時は除湿をお勧めしました。"],
  "mentions_consultation": false,
  "needs_attention": null
}

構造化出力にする1つ目の理由は、照合する欄を本文から分けられることです。 slots_used の各要素が渡した候補の文字列と一致し、本文にも含まれるか。quotes の各要素が顧客向けの所見に含まれるか。どちらもワークフローの文字の比較で確かめます。

2つ目は、値の無い欄の扱いを決めておけることです。 公式のページでは、構造化出力ではすべての項目を required にする必要があり、省略してよい項目は null との組み合わせの型で表すとされています。needs_attention は、AIが材料の足りなさに気づいたときだけ文を入れ、それ以外は null を返させます。 オブジェクトには additionalProperties: false を付けます。

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

システムへ連携する

ルーターのルートは、事務の確認→照合が通らない→通常→フォールバックの順に並べます。 公式のページでは、ルートは同時ではなく1本ずつ順に処理され、どの条件にも当たらないデータをフォールバックのルートが処理するとされています。事務の確認に回すのは、顧客が1件に決まらない、地域の対応表に無い町、前回から5年以上か記録が無い、21日間に候補が無い、needs_attention に文があるものです。

案内は下書きまでにし、自動では送りません。 調律の案内は、調律師が家に伺う約束の始まりです。

人が確認する

事務が確かめるのは、下書きの全件です。

1. 事務の確認に回ったものを先に見る … 前回から長いピアノは、担当の調律師に電話で状態を聞いてもらうよう回します
2. 候補の日程を見る … 調律師のカレンダーを開き、候補の日に新しい予定が入っていないかを見ます
3. 所見の使い方を見る … 引用が顧客向けの所見の欄からのものか、案内として伝えてよい書き方かを見ます
4. 送る … 宛名と料金の文が差し込まれていることを見て、Gmail の画面から送ります

返事で日程が決まったら、事務が調律師のカレンダーに予定を入れます。 予定の説明には、ピアノの種類と顧客向けの所見と社内の申し送りを入れ、調律師が訪問の前に読めるようにします。

下書きを直したら、直した箇所を依頼の記録に残します。 同じ直しが続くなら、指示か準備のお願いの文を直します。

目標は、160件をならして1件6分です。 下書きの多くは、カレンダーを開いて候補を確かめ、所見の使い方を読んで送るだけで済みます。事務の確認に回る件数が2割を超える月は、地域の対応表か台帳の引き方に抜けがあります。

例外に対処する

上の3行が大半を占めます。 どれもAIの誤りではなく、台帳の引き方と地域の対応表の作り方の問題です。 地域の対応表に無い町が続くなら、隣の市の顧客が増えています。

記録を残す

• 依頼の元の回答とメールの本文（引用を落とす前のもの）
• 特定した顧客とピアノ、引いた前回の記録
• 決めた地域・調律師・作業の時間と、Free/Busy を引いた日時
• 返ってきた JSON の全文と、照合の結果
• 事務が下書きを直した箇所と、送った案内の本文
• 返事で決まった日程と、当日の実際の作業の時間

最後の行は、作業の表を直す材料になります。 前回からの年数の区分ごとに、表の時間と実際の時間がどれだけ違ったかを見ます。 ずれの大きい区分は、表の時間を直します。