自動車ディーラーが、車検と法定点検の時期が来る顧客を毎月抜き出し、車種と前回の整備の記録に合わせた入庫の案内文の下書きを作る

処理の起点を決める

月初に、本部の担当者が書き出しを決まったフォルダに保存したことを起点にします。 これまで店舗ごとに抜き出していたのを、本部で1回、同じ規則で行う形に変えます。 抜き出しの規則が店舗ごとに違うことが、二重の案内と案内の漏れの原因だったからです。

書き出しは毎月同じ日に行い、ファイル名に年月を入れます（例：vehicles_2026-11.xlsx）。フローは最初にファイル名の年月が今月かを確かめ、違えば止まります。先月のファイルを誤って入れると、先月案内した顧客に同じ案内が二度届きます。

送信のフローは別にします。案内の一覧の項目が変更されたときに動き、状態が「送る」になったものだけを送ります。 下書きを作るフローと送るフローを分けておくと、営業の確認が数日かかっても、下書きのフローが待ち続けることがありません。

入力データを集める

質を決めるのは、整備の記録の「次回の推奨」の欄です。 ここに「ブレーキパッド残り3mm、次回の車検で交換推奨」のように書かれていれば、案内にそのまま生かせます。空欄なら、案内には何も書きません。 AI が車種や年数から「そろそろ交換の時期です」と推測して書くことは禁じます。

用途の列を持たせるのは、点検の時期が用途で違うからです。 道路運送車両法の第48条は、定期点検の間隔を、事業用の車などは3か月、自家用有償旅客運送の車や業として貸し渡す車などは6か月、それ以外の車は1年と定めています。この構成が扱うのは自家用の乗用車の12か月点検で、事業用の車は対象から外し、法人の担当者に任せます。

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

1. 書き出しの整形 … 「Run script」で、見出しを決まった列名（英数字）にし、テーブル「Vehicles」「Services」にします
2. 車両と顧客の読み込み … 「List rows present in a table」で読みます。ページ分割をオンにします
3. 整備の記録の読み込み … 車両番号ごとに、最新の入庫の行だけを残します
4. 案内文の部品の読み込み … 店舗ごとの部品を SharePoint のリストから取ります

日付の条件は、フローの中で絞ります。 このコネクタのフィルター クエリで使えるのは eq、ne、contains、startswith、endswith だけで、「満了日が3か月後の月に入る」のような大小の条件は書けません。 全件を読んでから、「アレイのフィルター処理」で絞ります。

列名を英数字にするのは、フィルター クエリと並べ替えが英数字の列名しか受け付けないからです。 管理システムの見出しが日本語でも、整形のスクリプトで ExpiryDate、Usage、EmailConsent のように置き換えます。

AIへ渡す前に整形する

1. ファイルの年月の確認 … 今月のファイルでなければ止めます
2. 対象の抽出 … 自家用で、車検の満了日が3か月後の月に入る車を「車検」、前回の12か月点検または車検から11か月目に入る車を「12か月点検」とします。同じ車が両方に当たる月は「車検」にまとめます
3. 受検できる最初の日の計算 … 車検の対象は、満了日の2か月前の日をフローで計算して渡します
4. 送り先の振り分け … 受信拒否がある、またはメールの同意が無い顧客はメールの対象から外し、はがき・電話の可否で振り分けます。どれも不可なら「送らない」
5. 既に予約がある車の除外 … 管理システムに車検や点検の予約が入っている車は外します
6. 次回の推奨の整え … 前回の入庫の「次回の推奨」の欄を、そのまま文字列で渡します。空欄なら空のまま渡します

4番目を AI に任せないでください。 誰にメールを送ってよいかは、記録された同意と受信拒否だけで決まります。 特定電子メール法の第3条は、あらかじめ同意した者などを除いて広告や宣伝のメールを送ってはならないとし、受信をしないよう求められたときは、その意思に反して送ってはならないと定めています。取引のある顧客をどこまで送信の対象にするかは、自社の法務と決めてください。

3番目を AI に計算させないのは、日付の誤りを防ぐためです。 満了日から2か月を引く計算は、月末の日付で間違えやすく、AI に任せると「1か月前から」と古い決まりで書くこともあります。

AIに処理させる

させるのは、フローが渡した事実から、案内のメールの件名と本文、電話で話す要点を作ることだけです。

次回の推奨は、記録に書かれた事実だけを伝えさせます。 たとえば記録が「バッテリー電圧低下、次回交換推奨」なら、「前回の点検で、バッテリーの交換を次回お勧めしていました」と書かせます。「放っておくと危険です」「すぐに交換が必要です」のように、記録より強い言い方に変えさせません。

3行目がいちばん起きやすい失敗です。 初度登録から7年の車だと分かると、AI は「タイミングベルトの交換時期です」のような一般論を書き足しがちです。その車にタイミングベルトが無いこともあります。 整備の推奨は、整備士が実際に車を見て書いた記録だけに限ります。

指示内容を固定する

あなたは自動車ディーラーの店舗で、車検と12か月点検の入庫の案内を書く担当です。
フローが渡す【車両と顧客の情報】【前回の整備の記録】【店舗の案内文の部品】だけを使って、
案内メールの件名と本文、電話で話す要点を作ってください。

【書き方】
- 宛名は「{customer_name} 様」とし、本文は5〜8文で書いてください。
- 案内の種類が「車検」のときは、満了日と、受検できる最初の日を書いてください。
- 案内の種類が「12か月点検」のときは、前回の点検の月と、点検の時期を書いてください。
- 前回の整備の記録に「次回の推奨」があるときは、
  「前回の入庫で、〇〇を次回お勧めしていました」の形で1文だけ書いてください。

【厳守事項】
- 日付は渡された値をそのまま書いてください。日付を計算し直したり、
  曜日を足したりしないでください。
- 受検できる時期について、渡された日付以外の説明（何か月前から、など）を
  書かないでください。
- 「次回の推奨」が空のときは、整備の推奨を一切書かないでください。
  車種、年式、走行距離から交換時期を推測して書かないでください。
- 「次回の推奨」の内容を、記録より強い言い方（危険、すぐに、必ず など）に
  変えないでください。
- 料金、割引、キャンペーンは、店舗の案内文の部品にあるものだけを書いてください。
- 本文の最後に、店舗の案内文の部品の「送信者の名称」と「配信の停止の連絡先」を
  そのまま書いてください。
- 回答に JSON マークダウンを含めないでください。

【車両と顧客の情報】{vehicle}
【前回の整備の記録】{last_service}
【店舗の案内文の部品】{store_snippets}

「渡された日付以外の説明を書かない」を入れているのは、古い決まりを書かせないためです。 AI が学習した時期によっては、車検は満了日の1か月前からと書くことがあります。受検の期間は令和7年4月に変わっているので、説明はフローが計算した日付だけにします。

最後の「送信者の名称」と「配信の停止の連絡先」は、表示の義務に対応するためです。 特定電子メール法の第4条は、送信者の氏名または名称と、受信をしない旨の通知を受けるためのメールアドレスなどを、受信する人の画面に正しく表示することを求めています。文面に必ず入るよう、部品からそのまま写させます。

出力形式を固定する

AI Builder のプロンプトの出力を JSON にし、次の形で受け取ります。

{
  "vehicle_no": "",
  "notice_type": "車検 | 12か月点検",
  "mail_subject": "",
  "mail_body": "",
  "call_points": [
    { "point": "" }
  ],
  "used_recommendation": true
}

1つ目の理由は、メールと電話の要点を別々に使えることです。 メールの顧客には mail_subject と mail_body を、電話の顧客には call_points を店舗の一覧に載せます。はがきの顧客には、本文を短くして印刷用の一覧に入れます。

2つ目は、used_recommendation で推奨を使ったかを確かめられることです。 フローは、整備の記録の「次回の推奨」が空なのに true が返ってきたら、AI が推奨を作り出したとみなし、その下書きを「要確認」にします。 逆に記録があるのに false なら、推奨を落としたとして同じく「要確認」にします。

3つ目は、本文に日付が正しく入ったかを機械で見られることです。 フローは mail_body に、渡した満了日と受検できる最初の日の文字列がそのまま含まれているかを確かめ、含まれていなければ「要確認」にします。

JSON の形は保存したときに固定されます。 Microsoft の説明では、キーの無い JSON は使えないとされているため、call_points は point を持つ要素の配列にしています。

推奨のある車の mail_body は、たとえば次のようになります。

山田 太郎 様

いつも〇〇自動車 △△店をご利用いただき、ありがとうございます。
お乗りの〇〇〇〇（車名）の車検の満了日は 2027年2月14日 です。
2026年12月14日 から車検をお受けいただけます。
前回の入庫で、フロントのブレーキパッドの交換を次回お勧めしていました。
ご予約は店舗のお電話か、Webの予約ページから承ります。代車もご用意できます。

【送信者】〇〇自動車株式会社 △△店
【配信の停止】このご案内が不要な方は、下記までご連絡ください。
（配信の停止の連絡先）

日付の2行は、フローが渡した文字列がそのまま入っているかを機械で確かめる部分です。 推奨の1文は、記録の「Fr ブレーキパッド残3mm 次回交換推奨」を、顧客に通じる言葉に直したものです。言葉を直すのは許しますが、強さを変えることは許しません。

システムへ連携する

管理システムには書き込みません。 案内を送ったことは案内の一覧に残し、管理システムへの記録は、予約が入ったときに店舗が通常の手順で行います。 書き込みを足すと、システムごとに連携の方法を確かめる必要が出て、難易度が上がります。

案内の一覧は、担当の営業ごとに絞り込んだビューで見せます。 1人あたり月に百数十件で、「要確認」を先頭に、その次に推奨のある下書きを並べます。 一覧の列は次のとおりです。

送信のフローは、SharePoint コネクタの「項目が作成または変更されたとき」で動きます。 このトリガーは作成時だけでなく変更のたびに動くので、最初の条件で「状態が『送る』または『直して送る』で、送った日時が空」のものだけに絞ります。絞らないと、送った後に一覧を直しただけで二度送ります。

人が確認する

1. 担当の営業が自分の顧客の下書きを見る … 「要確認」を先に見て、日付と次回の推奨が記録と合っているかを確かめます
2. 送らない顧客を選ぶ … 乗り換えの商談中、事故の対応中、苦情の対応中など、管理システムに無い事情を知っているのは担当者だけです
3. 直して送る … 本文を一覧の上で直し、状態を「送る」にします
4. サービスフロントが次回の推奨の書き方を見直す … 推奨が伝わりにくい書き方（略語、社内の符号）になっているものを、月に1度拾います

1番目で見るのは、事実の誤りです。 日付と推奨が合っていれば、文面はほぼそのまま送れます。「要確認」以外は、件名と最初の2文を流し見るだけにします。

4番目が、この構成の質を長く保ちます。 「Fr パッド 3mm」のような社内の略記は、AI がそのまま写すと顧客に通じません。記録の書き方を、顧客に見せてもよい言葉にそろえるのが、いちばん効く改善です。

例外に対処する

いちばん多いのは、上から5行目です。 家族で2台、3台を持つ顧客に、同じ月に別々の案内が届くと、ばらばらに来る案内は読まれません。 顧客番号でまとめ、1通の中で車ごとに書き分けます。

記録を残す

• 月ごとの書き出しの原本（ファイル名の年月で残す）
• 抽出の結果（車両番号、案内の種類、満了日、受検できる最初の日、送り先の振り分け）
• AI が作った下書きの全文と、担当の営業が直した後の文面
• 送った日時、方法、送信の成否
• 「送らない」を選んだ理由（任意の一言）
• 照合で「要確認」になった理由

直した後の文面を残すのは、指示を直す材料にするためです。 営業が毎回同じところを直しているなら、それは部品か指示の書き方の問題です。 3か月分を見れば、どこを直すべきかが分かります。