保険代理店が契約者へ毎月送るお知らせを、保険会社から届いた通知と代理店のメモから下書きする

処理の起点を決める

シナリオ1は、「お知らせ候補」のラベルの付いたメールを起点にします。 Make の Gmail の Watch emails は、フォルダやラベル、送信元、件名、含む語で絞り込めます。ラベルで絞り、送信元を取扱う5社のドメインに限ります。 担当者が転送したメールも拾えるよう、代理店のドメインも送信元に加えます。

添付のあるメールだけに絞ることはしません。 保険会社の通知には、本文だけで完結するもの（システムの停止の予定など）が多くあります。添付があればPDFを、無ければ本文を読ませます。

シナリオ2は、毎月20日の朝に予定で動かします。 Make の予定の Monthly で日付と時刻を決めます。お知らせを月の下旬に送るので、所長が読んで直すのに2〜3日を取れる日付にしています。20日を過ぎて届いた通知は、翌月の版に回ります。急ぎのもの（台風の接近に伴う手続きの特例など）は、版を待たずに担当者が個別に案内します。

入力データを集める

質を決めるのは、書き直しの決まりです。 言い換えの一覧が無ければ、AIは代理店向けの言葉を自分で言い換え、毎月違う言葉で書いてきます。 「始期日」「満期日」「異動」「解約返戻金」のように、通知によく出る語を30語ほど並べておくと、版ごとの言葉がそろいます。

使わない語の一覧も、同じくらい大事です。 「お得」「安心」「最適」「業界初」のような、商品の良さを強調する語を並べておきます。理由は第13章で書きます。

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

PDF を渡すときは、本文と一緒に1回の呼び出しで渡します。 本文に「添付のとおり」としか書かれていない通知もあれば、本文に要点があってPDFは詳細だけの通知もあります。どちらか片方だけを読ませると、日付や対象を取り違えます。

Upload a File について、Make のアプリの説明には受け付けるファイルの形式が書かれていません。 Files API 自体は PDF を document のブロックで扱えるので、最初に1件のPDFで上げて file_id が返るかを確かめてから組みます。 動かなければ、Make an API Call で /v1/files へ直接上げます。

AIへ渡す前に整形する

1. 送信元を確かめる … 取扱う5社と代理店のドメイン以外からのメールは、読ませずに担当者へ戻します
2. 添付を PDF だけに絞る … Excel の一覧や画像が付いていることがあります。Excel は document のブロックでは扱えないので、PDF にしてから担当者がラベルを付け直します
3. パスワードを確かめる … パスワード付きの PDF は読めません。保険会社の代理店向けのシステムから、パスワードの無い版を取り直します
4. 転送の引用を落とす … 担当者が転送したメールは、転送の前の部分だけを本文とします
5. 同じ通知の重複を確かめる … 保険会社は同じ通知を、件名を変えて再送することがあります。件名と通知の番号で管理表を引き、同じものがあれば印を付けます
6. 代理店向けの情報を落とす … 本文の中の代理店コード、担当者の名前と内線、手数料の記載の段落を落としてから渡します

6番目を軽く見ないでください。 通知の本文には、代理店の担当者向けの連絡先や代理店コードが入っています。AIに渡せば、それを契約者向けの文章に入れてしまうことがあります。 落とす段落は、保険会社ごとの書き方に合わせて、見出しの語（「代理店各位」「ご担当者様」の後の署名欄など）で決めます。

AIに処理させる

させるのは、通知が契約者に関係するかを見分けることと、関係するものを契約者向けの文章に書き直すことだけです。

いちばん下から2つ目の「根拠の写し」が、この構成の安全装置です。 書き直した文章の1文ずつについて、原文のどの文をもとにしたかを並べさせます。 担当者は根拠と書き直しを横に並べて読み、原文に無いことが足されていないかを確かめます。

2行目が、いちばん起きやすい失敗です。 通知に「2027年1月以降始期の契約から」とあると、AIは「2027年1月から保険料が変わります」と書きます。正しくは「2027年1月以降に始まる契約から」で、いまの契約がすぐに変わるわけではありません。 契約者にとって意味がまったく違うので、日付は原文の表記のまま写させ、書き直しの文と並べて確かめます。

指示内容を固定する

あなたは保険代理店の業務部で、保険会社から届いた通知を読み、
契約者へ毎月送るお知らせの原稿を作る立場です。
渡した通知のメール本文とPDFだけを使って、決まった形で返してください。

【1. 関係の見分け】
- customer：契約者に関係する（商品・補償・保険料の改定、契約者の手続きの変更、
  契約者向けのページやアプリの停止、契約者が使える窓口の変更）
- agency_only：代理店の事務だけに関係する（代理店の締切、代理店向けシステム、
  代理店の研修、手数料）
- unclear：どちらとも決められない
迷ったときに customer を選ばず、unclear を選んでください。

【2. customer のときに書くもの】
- 対象：どの保険の、どの契約者に関係するか。書かれていなければ「対象が不明」
- 日付：原文に書かれた日付を、原文の表記のまま写す。言い換えない
- 本文：3〜5文。何が変わるか／契約者がすることがあるか／問い合わせ先
- 根拠：本文の1文ずつについて、もとにした原文の文をそのまま写す
- 版：individual／corporate／both

【厳守事項】
- 原文に書かれていないことを書かないでください。日付・対象・条件を推測で補わないでください。
- 「〇月以降始期の契約」は「〇月以降に始まる契約」と書き、いまの契約が変わるように書かないでください。
- 保険料が上がる・下がる、得になる・損になる、と書かないでください。金額が原文にあれば、そのまま写してください。
- 次の語を使わないでください：{banned_words}
- 代理店の言葉は、次の一覧で言い換えてください：{glossary}
- 代理店コード、担当者の名前、内線、手数料、代理店の締切は書かないでください。
- 問い合わせ先は、保険会社の一覧にあるものだけを書いてください：{insurer_list}
- 文体は「です・ます」。1文は60字以内を目安にしてください。

【通知のメール本文】{mail_body}
【通知のPDF】（document ブロックで渡す）

「迷ったときに customer を選ばない」を明記しないと、ほとんどの通知が customer になります。 AIは「契約者にも関係があるかもしれない」と考えて広く拾います。unclear に寄せれば担当者が読むだけで済みますが、customer に寄せると、関係の無い項目の書き直しまで担当者が読むことになります。

「〇月以降始期の契約」の書き方を、例として直接書いているのも同じ理由です。 禁止の一般論だけでは、AIは自然な日本語に直そうとして意味を変えます。よく出る言い回しは、正しい書き方ごと指示に入れます。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力のスキーマとして渡します。

{
  "insurer": "",
  "notice_title": "",
  "relevance": "customer | agency_only | unclear",
  "target": "",
  "dates": [{ "label": "", "value_as_written": "" }],
  "body": "",
  "evidence": [{ "sentence": "", "source_text": "" }],
  "edition": "individual | corporate | both",
  "banned_word_hit": false
}

1つ目の理由は、relevance で管理表の並びを分けられることです。 customer は担当者が書き直しを読む行、agency_only は件名だけを見て閉じる行、unclear は原文を読む行です。読む順番と読み方が、管理表を開いた時点で決まります。

2つ目は、evidence で書き直しと原文を並べられることです。 管理表の1行に、本文の1文と原文の1文を並べて書き出します。原文の欄が空の文があれば、それはAIが足した文です。

3つ目は、dates の value_as_written で日付を確かめられることです。 本文の日付と、原文のままの日付を並べます。「以降始期」が「から」になっていないかを、担当者が一目で見られます。

banned_word_hit はワークフローの側でも確かめます。 使わない語の一覧と本文を Make の側で照らし、1つでも当たれば管理表の行に印を付けます。AIの自己申告だけに頼りません。

システムへ連携する

契約者へのメールは、この構成からは送りません。 版の下書きは担当者と所長に社内のメールで届くだけで、配信の仕組みに入れるのは所長の確認のあとの人の操作です。

シナリオ2の版のまとめでも、AIは新しい事実を足しません。 採用済みの行の本文を、保険会社ごと・テーマごとに並べ、前書きと見出しを付けるだけです。前書きに入れてよいのは、代理店のメモに書かれた内容だけと指示します。

人が確認する

担当者は、管理表の customer と unclear の行を全件読みます。 agency_only の行は件名だけを流し見ます。

1. unclear を先に読む … 原文を開いて、載せるかを決めます
2. customer の書き直しと根拠を並べて読む … 原文の欄が空の文は消すか、原文で確かめて直します
3. 日付と対象を確かめる … value_as_written と本文を見比べます。ここだけは原文のPDFを開いて確かめます
4. 商品の案内に当たるかを確かめる … 補償の内容や保険料に触れる項目は、取扱う保険会社の決まりに従って確認を受けます
5. 採用の印を付ける … 載せないものは、理由を1語入れます

所長は版の下書きを全文読みます。 版の中で文体と日付の書き方がそろっているか、前書きに代理店のメモに無いことが入っていないかを見ます。

目標は、40件をならして1件9分です。 agency_only は数十秒、customer は根拠との読み比べと原文での日付の確認で10分以上かかります。保険会社への確認が要る項目は、その返事を待つ時間が別にかかります。

例外に対処する

上から2行目までは、毎月必ず起きます。 どちらもAIの問題ではなく、保険会社の通知の出し方の問題です。 会社ごとに「PDFがパスワード付きで届く」「一覧がExcelで届く」という癖があるので、管理表に会社ごとの取り直し方を書いておきます。

記録を残す

• 通知のメールの件名、送信元、受け取った日時と、添付のファイル名
• AIに渡した本文（代理店向けの情報を落とした後のもの）
• AIが返したJSONの全文（relevance、body、evidence、dates）
• 担当者が採用・不採用を決めた記録と、直した後の本文
• 保険会社に確認した日と、確認の結果
• 送った版の全文と、送った日

4つ目の「直した後の本文」は、書き直しの決まりを育てる材料になります。 担当者が毎月同じ言葉を直しているなら、それは言い換えの一覧に足すべき語です。数か月分を並べると、一覧に足す語が見えてきます。

5つ目は、契約者から問い合わせがあったときに使います。 「お知らせに書いてあったことと違う」と言われたとき、どの通知を、いつ、どう書き直し、保険会社に確認したかを遡れるようにします。