保険代理店の募集人と顧客のメール・Teams のやり取りから、家族・住まい・仕事の変化を毎月拾い、保障の見直しを提案する先と話題の一覧を作る

処理の起点を決める

毎月の最初の営業日に、募集人が自分で動かします。 営業会議は毎月第2週に開くので、第1週のうちに一覧を作り、確かめ、リストに書き込むという日程にします。

自動で動かす仕組みは作りません。 Copilot が読むのは募集人本人のメールとチャットで、本人が自分の画面で頼むことが、この構成の前提です。 管理者がまとめて15名分を動かす形にすると、管理者が募集人のメールを読む形に近づきます。

動かす単位は、前月の1か月分です。 指示文の中で「前月1日から末日までのやり取り」と期間をはっきり書きます。期間を書かないと、Copilot は最近のやり取りを中心に探し、月の初めの分が抜けることがあります。 拾い漏れが気になる募集人は、前半と後半に分けて2回頼みます。

月の途中でも、顧客から変化を直接聞いた場合は、その場で見直し提案先のリストに書き込みます。 月の初めの振り返りは、聞き流してしまった変化を拾い直すためのものです。両方の経路で同じ顧客が出たら、リストの1行にまとめます。

入力データを集める

質を決めるのは、3行目の共有の指示文です。 15名がそれぞれ自分の言葉で頼むと、拾う変化の範囲も、出てくる表の形もばらばらになり、管理者がリストでまとめて見られません。 営業部で1つの指示文を決め、全員が同じ文を貼ります。

Teams のチャットで顧客とやり取りしていることが前提です。 社外の人とのチャットが自分の組織の Teams で行われていれば、Copilot の材料になります。どこまでのチャットが応答に使われるかは、組織の設定と契約で変わるため、最初の試行で確かめます（第8章）。

4行目の顧客の一覧は、Copilot に渡しません。 出力の顧客名とメールアドレスを、募集人が手元で顧客番号に引き当てるために使います。見直し提案先のリストには顧客番号で書き、氏名は顧客管理システムの側で見ます。

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

Copilot は、組織のデータを Microsoft Graph を通じて取り、利用者が少なくとも閲覧の権限を持つものだけを示すとされています。募集人が頼めば募集人のメールとチャットが、管理者が頼めば管理者のメールとチャットが材料になります。他の募集人のメールが混ざることはありません。

応答には、根拠にしたやり取りへの引用が付きます。 Copilot とのやり取りの記録には、プロンプトと応答に加えて、応答の根拠にした情報への引用も保存されるとされています。募集人は引用からメールやチャットを開いて確かめます。

メールの件名では絞り込ませません。 第3章の（a）のとおり、変化の話は件名と関係のないメールに書かれます。指示文で「件名にかかわらず本文を見る」と書きます。 ただし、メールマガジンや保険会社からの一斉配信は対象から外させます。

AIへ渡す前に整形する

1. 顧客とのやり取りを、自分のメールボックスと Teams に集める … 個人の携帯電話のメッセージでやり取りしたものは、この構成に乗りません
2. 共有の指示文の期間を書き換える … 「2026年9月1日から9月30日まで」のように、前月の日付を入れます
3. 社内のやり取りを外す … 指示文で「顧客（社外の個人）とのやり取りだけ」と書きます。社内の募集人どうしの相談は対象にしません
4. 保険会社からの一斉配信やメールマガジンを外す … 差出人の種類で外すよう指示文に書きます
5. 顧客の一覧のメールアドレスを最新にする … 出力の顧客を顧客番号に引き当てるのに使います。顧客がメールアドレスを変えたら、顧客管理システムの側を直しておきます

1番目は、運用の決まりです。 顧客とのやり取りを会社のメールと Teams に集めることは、この構成のためというより、代理店の記録として本来そうあるべきことです。携帯電話のメッセージで受けた変化は、拾われないだけでなく、代理店の記録にも残りません。

2番目を毎月書き換えるのが面倒なら、指示文に「前月」と書くだけでも動きます。 ただし、月の初めの何日に頼むかで「前月」の解釈がぶれないよう、日付で書くほうが確かです。 営業部の共有のメモに、毎月の初めに管理者が日付を入れた版を置いておく運用にすると、15名が書き換える手間がなくなります。

AIに処理させる

させるのは、顧客自身が書いた暮らしの変化を抜き出し、種類を付け、根拠のやり取りを示すことだけです。

1行目がいちばん大事です。 金融分野の個人情報保護のガイドラインは、保健医療に関する情報などを機微（センシティブ）情報とし、定められた場合を除いて取得・利用・第三者提供を行わないこととしています。 保険業の適切な業務運営のために本人の同意に基づいて必要な範囲で取得・利用する場合は除かれますが、見直しの提案先を探すためにメールから健康の情報を拾い集めることは、その範囲として扱いません。 「入院していました」「親の介護で」と書かれていても、一覧には「機微な情報を含むやり取りあり」とだけ出させ、中身は書かせません。

拾う変化を7種類に絞っているのは、確認の手間を一定に保つためです。 「旅行に行った」「趣味を始めた」まで拾わせると、一覧が長くなり、募集人は根拠を開かずに読み流すようになります。 保障の見直しか契約の手続きにつながる変化だけを拾わせ、種類を増やすのは、半年ほど運用して「拾われなかったが提案につながった変化」が記録にたまってからにします。

「変化を考えている」と「変化した」を分けさせます。 「引っ越しを考えている」は予定、「引っ越しました」は事実です。出力の列に「予定／事実」を設け、予定のものは手続きの確認の対象にしません。 予定の段階で住所の変更の手続きを始めると、顧客の確認を取らない変更になります。

指示内容を固定する

あなたは保険代理店の募集人を手伝う立場です。
2026年9月1日から9月30日までの、私と顧客（社外の個人）との
メールと Teams のチャットだけを見てください。
社内の人とのやり取り、保険会社からの一斉配信、メールマガジンは除いてください。
件名にかかわらず、本文を見てください。

【拾うもの】
顧客自身が書いた、次の変化だけを拾ってください。
結婚・離婚／出産／子の進学・独立／転居／住宅の購入／
転職・独立・退職／車の買い替え

【厳守事項】
- 顧客が書いた言葉をそのまま「顧客の言葉」に写してください。
  書かれていない変化を推し量らないでください。
- 予定（〜する予定、〜を考えている）と事実（〜した）を分けてください。
- 健康、病気、けが、入院、介護、障害に関わる内容は、
  中身を書かないでください。該当するやり取りがあれば、
  「機微な情報を含むやり取りあり」とだけ書いてください。
- 提案するべきかどうかは書かないでください。
- 各行に、根拠にしたメールまたはチャットの日付を付けてください。

【出力】
1. 変化の一覧（表）：顧客名／メールアドレス／変化の種類／予定・事実／
   顧客の言葉／日付
2. 手続きの確認が要るかもしれない先（転居・車の買い替え・結婚・離婚・転職で、事実のもの）
3. 機微な情報を含むやり取りがあった顧客（顧客名と日付だけ）

この指示文は、営業部の共有のメモに置き、15名が同じ文を貼ります。 毎月の初めに、管理者が期間の日付を書き換えた版を置きます。

「顧客の言葉をそのまま写す」を入れているのは、確認を速くするためです。 「転居」とだけ出ても、根拠を開くまで本当かが分かりません。顧客の言葉が表にあれば、多くの行は表を読むだけで見当がつき、怪しい行だけを開けば済みます。

話題の候補は、指示文では作らせません。 変化の種類から話題の候補への対応は、第7章「AIに何をさせるのか」の表として営業部で決めておき、募集人が見て使います。 AIに話題を作らせると、契約を見ないままの提案の案が一覧に並びます。

出力形式を固定する

表の形で返させます。 出力は募集人が確かめてから見直し提案先のリストに写すので、読んで確かめやすい表を形にします。

【変化の一覧（2026年9月）】
| 顧客名 | 変化の種類 | 予定/事実 | 顧客の言葉 | 日付 |
| 〇〇様 | 転居 | 事実 | 書類は今月から新しい住所の方にお願いします | 9/12 |
| △△様 | 出産 | 事実 | おかげさまで先週無事に生まれました | 9/20 |
| □□様 | 車の買い替え | 予定 | 年内に車を替えようと思っていて | 9/25 |

【手続きの確認が要るかもしれない先】
| 顧客名 | 変化の種類 | 確認すること |
| 〇〇様 | 転居 | 住所の変更の手続き |

【機微な情報を含むやり取りがあった顧客】
| 顧客名 | 日付 |
| ◇◇様 | 9/8 |

募集人が確かめた後、見直し提案先のリストには次の列で書き込みます。 顧客番号、変化の種類、予定・事実、根拠の日付、提案の予定（する・しない・保留）、話題、手続きの確認の結果、担当の募集人、次の連絡の予定日です。リストには顧客の言葉を写しません。 顧客の言葉はメールにあり、リストに二重に残す必要がありません。

1つ目の理由は、「予定／事実」の列で手続きの誤りを防げることです。 手続きの確認の一覧は事実のものだけで作られるので、予定の段階の変化で手続きを始める経路がなくなります。

2つ目は、機微な情報を含むやり取りが独立した一覧になることです。 中身は書かれず、顧客名と日付だけが出ます。募集人が、そのやり取りへの対応（給付金の請求の案内など）を忘れていないかを確かめるための一覧です。見直しの提案先のリストには載せません。

システムへ連携する

Copilot から顧客管理システムへは何も書き込みません。 住所の変更の手続きは、これまでどおり募集人が顧客に確かめてから行います。

見直し提案先のリストの権限は、営業部に絞ります。 募集人は自分の行を書き込み、管理者は全員の行を見ます。リストには顧客番号と変化の種類だけが並び、顧客の言葉や機微な情報は載りません。

人が確認する

1. 顧客の言葉を読む … 表の「顧客の言葉」で、変化が本当に書かれているかの見当をつけます
2. 怪しい行の根拠を開く … 顧客の言葉があいまいな行、予定か事実かが分かれる行は、メールやチャットを開きます
3. 手続きの確認の一覧を全件確かめる … 顧客管理システムで、住所や車両の変更が済んでいるかを見ます
4. 提案するかを決める … 契約を見て、提案する・しない・保留を決めます
5. リストに書き込む … 確かめた行だけを顧客番号で書き込みます

3番目は全件です。 手続きの漏れは、顧客に書類が届かない、事故のときに補償の確認に手間がかかる、といった形で顧客の不利益になります。見直しの提案は保留できますが、手続きの確認は保留しません。

4番目で「保留」とした行は、次の連絡のついでに顧客の意向を聞く行です。 たとえば出産の知らせには、まずお祝いを伝え、「ご家族が増えたので、保障を一度確かめてみませんか」と聞くところまでにします。顧客が望まなければ、提案はしないと記録します。 一覧は、顧客の意向を聞くきっかけであって、提案を押しつける根拠ではありません。

目標は、1回あたり40分です。 顧客の言葉を読むのに5分、根拠を開いて確かめるのに5分、手続きの確認に5分、契約を見て提案を決めるのに20分、リストへの書き込みに5分という配分です。

例外に対処する

4行目の家族の代理は、保険代理店ではよくあります。 契約者の妻が手続きのメールを送ってきて、その中で「主人が転職しまして」と書く場合です。変化したのは契約者で、書いたのは家族です。 出力の顧客名は差出人の名前になりがちなので、根拠を開いて誰の変化かを確かめ、契約者の顧客番号で記録します。

5行目は、起きたらその月のうちに指示文を直します。 指示文で禁じていても、顧客が書いた文に健康と住まいの話が混ざっていると、一緒に写してしまうことがあります。 起きた例を管理者に知らせ、指示文の禁止の書き方を強めます。

記録を残す

• 毎月の共有の指示文の版（期間の日付と、変更の理由）
• 見直し提案先のリストの行と、その後の提案の結果（提案した・見送った・顧客が断った）
• 手続きの確認の結果
• 採らなかった行の数と理由 … 社内のやり取り、推し量り、予定と事実の取り違え、機微な情報の混入
• Copilot とのやり取りの記録（組織の保持の設定に従う）

4つ目の数は、管理者が月に一度集めます。 理由ごとの数が分かれば、指示文のどこを直すかが決まります。 機微な情報の混入が1件でもあれば、最優先で直します。

2つ目の提案の結果は、話題の候補の表を直す材料です。 「住宅の購入」で火災保険の話をしても、ほとんどが金融機関の提携の保険にすでに入っていた、という結果が続けば、表の話題を地震保険の確認に替えるといった直しができます。 AIの指示文ではなく、営業部の表を直すところがこの構成の改善の場所です。

Copilot とのやり取りの記録は、管理者が Microsoft Purview で保持の設定をできるとされています。顧客のメールの内容を含むやり取りなので、保存の期間は代理店の個人データの保存の決まりにあわせます。