保険代理店で、取扱う保険会社から毎日届くお知らせ（商品改定・事務の変更・引受の制限）をエージェントが見回り、影響する契約者と募集人を拾って対応の一覧を作る

処理の起点を決める

トリガーは2つです。お知らせが届いたときに動くものと、毎朝の通知です。

届いたときに動く側は、n8n の Gmail Trigger です。ノードのフィルタに、ラベル、Gmail の検索式、既読・未読、送り主の指定があります。保険会社の通知メールの送り主と、事務の担当者がPDFを送るアドレスに、Gmail の側でラベル「保険会社お知らせ」を付け、そのラベルで絞ります。 既読の状態は「未読のみ」にし、処理が終わったら既読にします。

毎朝の通知は、Schedule Trigger で営業日の8時30分に動かします。cron 式は (秒) 分 時 日 月 曜日 の欄で書け、秒の欄は省略できるとされています。月曜から金曜の8時30分なら 30 8 * * 1-5 です。ワークフローのタイムゾーンを Asia/Tokyo にします。 設定が無いとインスタンスのタイムゾーンが使われ、自分でホストする場合の既定は America/New York とされています。Schedule Trigger を使うワークフローは、保存して公開しないと動きません。

引受の制限で申込中の案件に関係するものは、毎朝を待たずにすぐ知らせます。

入力データを集める

質を決めるのは、商品の辞書です。 お知らせには「〇〇保険（家庭総合）」「△△特約」のような保険会社の正式な名前が書かれ、契約の一覧には社内のコードが入っています。この対応が無いと、エージェントは条件を検索の言葉に置き換えられません。 契約の一覧には、氏名や連絡先を入れません。 どの契約者に連絡するかは、証券番号から募集人が顧客管理で引きます。

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

契約の一覧と申込中の案件は、毎晩別のワークフローで読み込み直します。 一覧にいつ時点のものかを持たせ、対応の一覧にも書きます。

検索は、パラメーター付きのクエリにします。 PostgreSQL のノードは $1、$2 のような記号で値を渡すクエリに対応し、公式の説明では、パラメーターの値は n8n が無害化するため SQL インジェクションを防げるとされています。エージェントにSQLの文を組み立てさせず、決めておいた検索の形に値だけを渡させます。

AIへ渡す前に整形する

1. 送り主の確認 … ラベルの付いたメールが、登録した保険会社か事務の担当者から届いたものかを確かめます
2. 文字の取り出し … 本文と、添付のPDFから文字を取り出します。取り出せた文字が極端に少なければ、画像だけのPDFと見なして人へ回します
3. 定型の部分の除去 … 通知メールの定型のあいさつ、配信停止の案内、代理店システムへのリンクの説明を外します
4. 重複の確認 … 同じ保険会社・同じ件名・同じ掲載日のものが台帳にあれば、二重に処理しません。訂正版は件名に「訂正」とあることが多いので、元のものに結び付けます
5. 受付の台帳への記録 … 保険会社、掲載日、件名、処理の状態を1行足します

4番目の訂正版は、見落とすと危険です。 保険料の改定のお知らせに訂正が出たとき、元のお知らせの件数で募集人に伝えたままになることがあります。訂正版が届いたら、元のお知らせの対応の一覧の行に「訂正あり」と出し、件数を引き直させます。

AIに処理させる

させるのは、お知らせ1件ごとに、影響の条件を取り出し、必要な道具を選んで引き、次の4つを組み立てることです。

どの道具を呼ぶかを決めるのが、エージェントの仕事です。 システム停止なら get_agents だけで足り、引受の制限なら find_pending_applications を先に、保険料の改定なら lookup_product_code から count_policies へ進みます。

3行目がいちばん起きやすい失敗です。 「家庭総合保険」と「家庭総合保険（2024年版）」のように、名前の近い商品は少なくありません。辞書に無い名前を、似た名前の商品として数えると、件数はそれらしく出ます。 間違っていても、人の確認では気づきにくい形です。

指示内容を固定する

AI Agent ノードの System Message に次を入れます。

あなたは保険代理店の業務管理の担当として、保険会社から届いたお知らせを読み、
自社のどの契約・どの申込中の案件・どの募集人に関係するかを調べる立場です。

【お知らせの読み方】
- 種類を、商品改定・保険料改定・事務の変更・引受の制限・システム停止・その他
  から1つ選んでください
- 影響の条件（保険会社、商品、特約、適用の日、対象の地域・職業など）を取り出し、
  それぞれに、根拠にしたお知らせの原文をそのまま quote として付けてください
- お知らせに書かれていない条件を補わないでください。
  適用の範囲が書かれていないときは、scope_unclear を true にしてください

【道具の使い方】
- まず get_past_notices で、同じ保険会社の同じ種類のお知らせを見てください
- 商品や特約が条件にあるときは、lookup_product_code で社内の商品コードを引いてください。
  辞書に無い名前は、似た名前の商品に置き換えないでください。
  unmapped_products に書き、その商品については数えないでください
- 適用の日や引受の制限があるときは、find_pending_applications を
  count_policies より先に呼んでください
- 同じ道具を同じ条件で2回呼ばないでください

【書かないこと】
- 契約者へ案内すべきかどうかを、結論として書かないでください。
  「案内の要否を検討する」の形にしてください
- 引受できるかどうかを書かないでください
- 件数は道具が返した値だけを書いてください。推定した件数を書かないでください

【お知らせ】
保険会社：{insurer} ／ 掲載日：{posted_on} ／ 件名：{subject}
本文：{notice_text}
【契約の一覧の時点】{snapshot_at}

「辞書に無い名前を置き換えない」と「その商品は数えない」を両方書くのは、片方だけだと抜け道があるからです。 置き換えを禁じても、「おそらくこの商品のことと思われるため」と書いて数えることがあります。数えることまで禁じて、初めて止まります。

「申込中の案件を先に引く」は、途中で止まったときのためです。 Tools Agent の呼び出しには上限（Max Iterations、既定は10）があり、上限で止まっても申込中の案件の検索が済んでいれば、取りこぼしの痛手が小さく済みます。

出力形式を固定する

Tools Agent の「Require Specific Output Format」を有効にし、Structured Output Parser をつなぎます。 次の形のJSONで受け取ります。

{
  "notice_id": "",
  "insurer": "",
  "notice_type": "product_revision | premium_revision | procedure_change | underwriting_restriction | system_outage | other",
  "summary": "",
  "conditions": [
    { "field": "product | rider | effective_date | region | occupation | other", "value": "", "quote": "" }
  ],
  "scope_unclear": false,
  "unmapped_products": [],
  "impact": {
    "all_agents": false,
    "policies_by_agent": [ { "agent_id": "", "count": 0 } ],
    "pending_by_agent": [ { "agent_id": "", "application_ids": [] } ]
  },
  "deadline": "",
  "actions": [ "" ],
  "tools_called": [ "" ]
}

1つ目の理由は、quote で条件の読み違いを人が確かめられることです。 業務管理の担当者は、条件ごとに原文の箇所を見て、エージェントの読み取りが原文どおりかを短い時間で確かめられます。 原文の全体を読み直す必要がありません。

2つ目は、unmapped_products と scope_unclear で、分からなかったことが一覧に出ることです。 件数が0件のとき、本当に関係する契約が無いのか、辞書に無くて数えられなかったのかを区別できます。0件のお知らせを読み飛ばす前に、この2つを見ます。

3つ目は、件数を道具の返した値に限れることです。 ワークフローの側で、policies_by_agent の合計が count_policies の戻り値と一致するかを確かめます。一致しなければ、エージェントが数字を書き換えたということなので、その行は差し戻します。 途中の手順は Tools Agent の Return Intermediate Steps を有効にして受け取ります。

Structured Output Parser には注意があります。JSON スキーマで $ref による参照に対応していないとされ、例から作る方式ではすべての項目が必須として扱われます。 上のJSONは参照を使わない形にしてあります。

システムへ連携する

契約の一覧には書き込みません。 データベースの接続に使う利用者は読み取りの権限だけにし、道具に Insert や Update をつながないことで守ります。指示で禁じるより確実です。

募集人への連絡も、自動では送りません。 業務管理の担当者が確かめた行だけを、担当者が募集人に送ります。条件の読み違いのまま全員に送ると、取り消しの連絡をもう一度送ることになり、次からお知らせが読まれなくなります。

人が確認する

業務管理の担当者が見るのは、毎朝の一覧です。

1. 「至急」を最初に見る … 申込中の案件のある引受の制限と改定。担当の募集人に、その日の午前のうちに伝えます
2. 「要確認」を見る … unmapped_products は辞書に足し、件数を引き直させます。scope_unclear は保険会社の担当者に問い合わせます
3. 条件と原文を見比べる … quote を読み、条件の読み取りが原文どおりかを確かめます。適用の日と対象の範囲は必ず見ます
4. 募集人へ伝える … 件数と対象の証券番号を、担当の募集人ごとに送ります
5. 案内の要否を決める … 契約者へ案内するかどうかは、募集人と業務管理責任者で決めます。案内の文面は、保険会社が用意したものを使います
6. 対応の結果を記録する … 募集人が何をしたかを対応の一覧に残します。これが次の get_past_notices の中身になります

3番目の適用の日は、いちばん読み違いの起きやすい項目です。 「始期が11月1日以降の契約」と「11月1日以降に申込を受けた契約」では、対象がまったく違います。原文の言い回しをそのまま見ることが、確認の中心です。

6番目を続けると、前回の対応の手順を案として出せるようになります。

例外に対処する

5行目は、気づかれにくい失敗です。 前の晩の読み込みが失敗すると、前々日の時点の一覧で、それらしい件数が出ます。 時点の表示が無いと誰も気づきません。

記録を残す

• 届いたメールとPDFの原本、取り出した文字
• エージェントの入力、呼んだ道具とその結果（Return Intermediate Steps で取得）、出力のJSON
• そのとき使った契約の一覧の時点と、商品の辞書の版
• 業務管理の担当者が直した条件と件数、直す前の値
• 募集人へ伝えた日時と、募集人が行った対応
• 契約者へ案内したかどうかと、その判断をした人

3つ目の「一覧の時点と辞書の版」は、後から件数を説明するために残します。 「なぜこの契約者に連絡が来なかったのか」と聞かれたとき、その日の一覧に契約が載っていたか、辞書に商品があったかを確かめられます。

最後の行は、どのお知らせを、いつ、誰に伝え、どう対応したかを後から確かめられるように残します。