保険代理店に保険会社から届く異動・解約の処理完了の通知を、代理店で受けた依頼の記録と照らし、内容の違いと処理されていない依頼を募集人へ返す

処理の起点を決める

保険会社からの通知のメールが届いたことを起点にします。 通知は業務課の共有メールボックスで受けているので、トリガーの「元のメールボックス アドレス」にそのアドレスを入れます。差出人には、取扱う5社の通知の送信元アドレスをセミコロンで区切って並べます。 保険会社の営業担当からの連絡や、お知らせのメールは別のフォルダーに振り分け、このフローには入れません。

公式ドキュメントには、いくつか知っておくべき制限があります。 トリガーは受信日時に基づいて動くため、メールを別のフォルダーに移しても、最新の正常な実行より前に受信したメールはスキップされるとされています。また、「添付ファイルを含める」をはいにすると、添付のダウンロード中にタイムアウトすることがあるため、いいえにして「添付ファイルの取得 (V2)」で取ることが勧められています。まれにトリガーが動くまで最大1時間かかることも書かれています。

1時間の遅れは、この業務では問題になりません。 照合の目的は、違いを当日中に募集人へ返すことです。ただし、毎朝の未着のフローは、前日の通知の照合が終わった後に動くよう、時刻を朝8時に置きます。

もう1本のトリガーは「繰り返し」です。 毎朝、受付簿から状態が「依頼済み」のものを取り、期日を過ぎたものを拾います。通知を起点にするフローだけでは、届かない通知を数えられません。

入力データを集める

質を決めるのは、受付簿の「依頼の内容」の欄です。 「車両入替」とだけ書かれていると、通知の型式や登録番号と照らす相手がありません。依頼の種類ごとに、受付簿に書く欄を決めます。 車両入替なら新しい車の車名・型式・登録番号と入替の日、住所変更なら新しい住所と変更の日、解約なら解約の日と理由です。

読み替えの表は、業務課の4名の頭の中にあるものを書き出したものです。 「A社は異動日を『変更日』と書く」「B社の証券番号は先頭にアルファベットが付く」。これをプロンプトへの入力として渡すと、保険会社が増えても指示文を書き換えずに済みます。

期日の表は、本記事のモデル条件として「代理店システムで手続きした依頼は3営業日、書類を送った依頼は10営業日」と置きます。 実際の日数は、保険会社ごとの処理の実績を1か月見てから決めます。

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

通知のメールは、トリガーの出力から本文を取り、添付は「添付ファイルの取得 (V2)」で取ります。添付がPDFでないもの（画像の通知など）も、PNG・JPG なら同じプロンプトに渡せます。 それ以外の形式は、例外処理へ回します。

受付簿の検索は、証券番号を正規化してから行います。 ハイフン・空白・全角を落とし、英字を大文字にそろえた値を、受付簿の側にも別の列として持たせます。募集人が書いた証券番号はそのまま残し、検索には正規化した列を使います。 正規化の処理は Power Automate の式で書け、AIに任せません。

証券番号で見つからないときだけ、契約者名と保険会社で探します。 名前で見つかった候補が1件でも、自動で結びつけず、業務課の確認に回します。 同じ契約者が複数の契約を持つことは珍しくありません。

AIへ渡す前に整形する

1. 差出人と件名の確認 … 取扱う保険会社の送信元で、件名に「処理完了」「異動」「解約」などが含まれるかを見ます。外れるものは対象外のフォルダーへ移します
2. 本文の掃除 … 署名、免責の定型文、配信停止の案内を落とします
3. 添付の確認 … PDF・PNG・JPG か、ページ数が50ページ未満か、合計が25 MB未満かを見ます
4. 「代理店システムでご確認ください」だけの通知の検知 … 中身の無い通知は、取り出しにかけずに例外へ回します
5. 1通に複数の契約 … 1通の通知に複数の証券番号があるものは、プロンプト①で契約ごとに分けて返させます
6. 重複の検知 … 同じ証券番号・同じ異動の種類・同じ異動の日の通知が直近にあれば、再送として印を付けます

4番目を前処理で拾うのは、空の通知をプロンプトに渡すと、もっともらしい中身を作るおそれがあるからです。 中身が無いことを最初に確かめ、AIに渡す前に人の作業へ分けます。

AIに処理させる

生成AIの仕事は2つです。 通知から異動の中身を取り出すことと、取り出した中身を依頼と項目ごとに照らすことです。募集人へ返すかどうかは、規則で決めます。

照合する項目は、依頼の種類ごとに決めます。

規則は次のとおりです。

日付の differ を必ず return にするのは、補償の空白に直結するからです。 車両入替の日が依頼より遅ければ、その間の新しい車は補償の外です。日付の違いだけは、業務課の確認を経たうえで、当日中に募集人へ返します。

指示内容を固定する

プロンプト①（取り出し）は、次の指示です。

あなたは保険代理店の業務課で、保険会社から届いた異動・解約の処理完了の通知を読む立場です。
渡された通知の本文と添付の文書だけを読み、契約ごとに次の項目を取り出してください。

【取り出す項目】
- policy_no：証券番号（書かれたとおり）
- insurer：保険会社
- holder_name：契約者名
- change_type：異動の種類（vehicle_change / address_change / coverage_change / cancellation / other）
- effective_date：異動の日または解約の日（YYYY-MM-DD）
- changed_items：変更の後の値（項目名と値の組の配列）
- premium_change：保険料の増減（increase / decrease / none / not_stated）

【厳守事項】
- 書かれていない項目は空にしてください。他の項目から推測して埋めないでください。
- 日付が複数ある場合（受付日、処理日、異動日など）は、読み替えの表に従って異動の日を選び、
  選べない場合は effective_date を空にして date_candidates にすべて書いてください。
- 和暦は西暦に直してかまいませんが、元の書き方を effective_date_raw に残してください。
- 登録番号・型式・証券番号は、1文字も直さずに写してください。
- 1通に複数の契約がある場合は、契約ごとに分けてください。
- 回答に JSON マークダウンを含めないでください。

【通知の本文】{mail_body}
【添付の文書】{attachment}
【この保険会社の読み替えの表】{mapping}

プロンプト②（照合）は、次の指示です。

あなたは保険代理店の業務課で、代理店で受けた依頼が、その内容で保険会社に処理されたかを確かめる立場です。
依頼の記録と、通知から取り出した内容を、照らす項目ごとに比べてください。

【status の選び方】
- match ......... 依頼と通知の値が同じ。書き方の違い（全角と半角、和暦と西暦、
                  「丁目」と「-」）は同じとしてよい
- differ ........ 値が違う
- not_in_notice . 通知にその項目が書かれていない
- unclear ....... 通知の書き方からは同じか違うか決められない
迷ったときに match を選ばないでください。

【厳守事項】
- 書き方の違いとして同じとした場合は、reason にどの違いを同じとしたかを書いてください。
- 日付は1日でも違えば differ です。
- 通知に書かれていない項目を、依頼の値で埋めて match にしないでください。
- evidence に、判定の根拠にした通知の文をそのまま写してください。
- 保険会社の処理が正しいか誤りかを書かないでください。
- 契約者への説明や、募集人がすべきことを書かないでください。
- 回答に JSON マークダウンを含めないでください。

【照らす項目】{check_items}
【依頼の記録】{request}
【通知から取り出した内容】{notice}

「通知に書かれていない項目を依頼の値で埋めない」を明記しないと、match が増えます。 依頼の記録には値があり、通知には無い。何も言わなければ、モデルは依頼の値をそのまま「確認できた」としがちです。照合の意味は、通知の側に値があることを確かめる点にあります。

「書き方の違いを同じとしたら理由を書く」も同じ考えです。 「3丁目5-2」と「3-5-2」を同じとするのはよくても、「5-2」と「5-12」を同じとされては困ります。 理由が残っていれば、業務課が一覧で見たときに気づけます。

出力形式を固定する

プロンプトの出力は、JSON のカスタム形式で固定します。 公式ドキュメントでは、JSON の例を更新すると形式がカスタムになり、プロンプトを保存すると形式がロックされるとされています。フィールド キーの無い配列（["abc", "def"] の形）はサポートされないので、配列の要素は必ずキーを持つ形にします。

{
  "notice_id": "MAIL-20261007-0231",
  "request_id": "REQ-2026-09-1184",
  "policy_no": "AB-1234567-01",
  "change_type": "vehicle_change",
  "checks": [
    { "item": "effective_date", "request": "2026-11-01", "notice": "2026-11-10",
      "status": "differ", "reason": "", "evidence": "異動日 令和8年11月10日" },
    { "item": "model_code", "request": "6AA-XXXX", "notice": "6AA-XXXX",
      "status": "match", "reason": "", "evidence": "型式 6AA-XXXX" }
  ],
  "verdict": "return",
  "agent": "募集人のアカウント"
}

1つ目の理由は、status と verdict を別の層に置けることです。 checks はAIが埋め、verdict はフローが規則で決めます。「保険料の増減の違いは返さない」と代理店の方針が変わっても、直すのは規則だけです。

2つ目は、request と notice の値を並べて残すことです。 募集人が Teams の知らせを開いたとき、何が違うのかが1行で分かります。 通知の原文を開き直す手間がなくなります。

3つ目は、evidence で業務課の確認が速くなることです。 違いがあると出たものを、PDFを開かずに根拠の文で確かめられます。

システムへ連携する

受付簿の状態を「完了」にするのは、ok のときだけです。 return と needs_human は「照合で違いあり」「照合で確認待ち」という別の状態にします。募集人が保険会社や契約者に確かめて片が付いたら、募集人が「完了」にします。 フローが勝手に完了にしないことで、違いが放置されたまま受付簿から消えることを防ぎます。

保険会社への照会のメールは作りません。 照会するかどうか、どう書くかは、契約者の事情を知っている募集人が決めることです。

人が確認する

業務課が見るのは return と needs_human だけです。 ok は、件数と保険会社の内訳を日に1回流し見ます。

1. 日付の differ を最初に見る … 補償の空白につながるものです。根拠の文を読み、本当に違うかを確かめて、その日のうちに募集人へ返します
2. needs_human を片付ける … 多くは依頼が見つからないもの、通知に中身が無いものです。受付簿の記録漏れなら、募集人に記録を足してもらいます
3. それ以外の differ を確かめる … 型式や住所の違いです。書き方の違いにすぎないものは、match に直して理由を残します
4. 返すと決めたものを送る … 確認の待ち行列で「返す」を選ぶと、フローが募集人へ Teams で知らせます

3番目で直した記録は、読み替えの表を育てる材料です。 同じ保険会社で同じ書き方の違いが何度も出るなら、その書き方を表に足します。次からは match で通ります。

目標は、480件をならして1件2分です。 開くのは1〜2割という想定で、それより多い月は、受付簿の書き方がそろっていないか、新しい保険会社の書き方が表に入っていません。

例外に対処する

最後の行は、知らせるだけで終わらせないための決まりです。 毎朝同じ依頼が一覧に載り続けると、一覧そのものが読まれなくなります。 知らせた回数を受付簿に数え、一定の回数で人を替えます。

記録を残す

• 通知のメールのID、受信日時、差出人と、添付のファイル
• プロンプト①の出力（取り出した内容）とプロンプト②の出力（checks）
• 規則の結果（verdict）と、そのとき使った読み替えの表と期日の表の版
• 業務課が判定を直した記録 … どの項目を、どちらに直したか、理由
• 募集人へ知らせた日時と、募集人が「完了」にした日時
• 未着の知らせの回数

判定を直した記録は、保険会社ごとに数えます。 特定の保険会社だけ直しが多いなら、読み替えの表が足りていません。直しの数が減っていけば、業務課が見る件数も減ります。

照合の記録は、受付簿の1件ごとに結びつけて残します。 後から契約者に「いつ、何を確かめたか」を聞かれたとき、受付簿の1行から通知と照合の結果までたどれるようにします。