気象警報の発表を受けて対象地域の契約者と代理店をエージェントが抽出し、事故受付の体制の案と連絡文の下書きを担当に知らせる

処理の起点を決める

Schedule Trigger で、数分おき（例：3分）に動かします。 高頻度フィードは直近少なくとも10分の入電を載せるので、10分より短い間隔で取れば取りこぼしません。 Schedule Trigger はワークフローのタイムゾーンを使い、無ければインスタンスのタイムゾーンを使います。セルフホストの既定は America/New York なので、Asia/Tokyo にします。 保存して公開しないと動きません。

別に、毎時の Schedule Trigger で長期フィード（随時）も取ります。 n8n の停止や通信の失敗で高頻度フィードを取れなかった時間があっても、長期フィードは数日間の全入電を載せているので、後から拾い直せます。 どちらで取っても、電文のURLで重複を除くので二重には処理しません。

1日の取得量に気をつけます。 気象庁のページでは、1日10GB以上のダウンロードを伴うアクセスがあるとIPアドレスを遮断するとされ、一度取得したファイルを再度取得しない改修が求められています。フィードは数分おきでも、電文の本体は新しいものだけを取ります。

入力データを集める

質を決めるのは、市町村等の対応表と過去の事例です。 電文の市町村等のコードは7桁で（例：唐津市は 4120200）、契約の所在地を持つ側のコードと桁がそろっていないことがあります。 対応表が無いと、契約の件数が0件と出て、体制の案が「通常」に偏ります。

過去の事例は、この構成を回すほど増えます。 最初の数か月は事例が少ないので、エージェントには「事例が3件未満なら、事例から推し量らない」と指示します。

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

フィードは HTTP Request ノードで取ります。 Response を Text にして、XML ノードの XML to JSON で JSON にします。エントリーの題名で電文を選びます。 題名は「気象警報・注意報（Ｒ０６）（暴風）」のように全角の文字で書かれているので、題名の比較は、電文のURLの中のデータ種類コード（VPWW58 など）で行うほうが確実です。 URLは .../20261008112622_0_VPWW58_410000.xml の形で、末尾の6桁は府県予報区等のコードです。

新しい電文の検出は、Remove Duplicates ノードの Remove Items Processed in Previous Executions で行います。 Keep Items Where を Value Is New にし、Value to Dedupe On に電文のURLを入れます。履歴は既定で10,000件まで持つとされています。高頻度と長期の2つのワークフローで同じ履歴を使うなら、Scope を Workflow にして1つのワークフローにまとめます。

電文の本体も HTTP Request で取り、XML ノードで JSON にします。 電文には Head の Headline と、Body の Warning があります。使うのは Body の、type が「気象警報・注意報（市町村等）」の Warning です。 市町村等ごとに Item があり、Kind の Name（種別の名前）、Code、Status（解除、発表警報・注意報はなし など）、LastKind（前の種別）が入ります。

Head の Headline だけを読んではいけません。 確認した暴風の電文では、Headline の市町村等の欄には Name が「解除」とだけ書かれ、どの種別が解除されたかは Body の LastKind を見ないと分かりませんでした。種別と前の種別の比較は、必ず Body で行います。 また、1つの市町村等に複数の種別が同時に出ることがあるので、XML ノードの Explicit Array を有効にして、Item も Kind も常に配列で受け取ります。1件のときだけ配列でなくなる形のまま組むと、警報が2つ重なった日にだけ取り出しが壊れます。

契約の集計、代理店の一覧、過去の事例、体制の基準、人員は、エージェントが道具として呼ぶサブワークフローにします。 Call n8n Workflow Tool で渡し、サブワークフローは公開しておきます。公開していないと、本番で呼び出しが失敗します。

AIへ渡す前に整形する

1. 電文を選ぶ … データ種類コードで VPWW55〜VPWW60 を残します。VPWW61（その他の注意報）は体制の検討に使わないので外します
2. 市町村等の行を取り出す … type が市町村等の Warning だけを、市町村等のコード・種別・状態・前の種別の行にします
3. 変化を分ける … 前の種別が無く警報以上が付いたものを「新たに発表」、前の種別より上がったものを「引き上げ」、Status が解除のものを「解除」、変わらないものを「継続」に分けます
4. 警報以上に絞る … 種別の名前が注意報だけの市町村等は、体制の検討から外します（記録には残します）
5. 数分まとめる … 同じ府県の電文が数分の間に続けて届くことがあるので、府県ごとに5分待ってから1つのまとまりにします
6. コードを結ぶ … 市町村等の対応表で、契約の所在地のコードに変えます

3番目を省くと、継続の電文のたびに同じ案が届きます。 警報が出ている間も、ほかの種別の変化や範囲の変化で電文は何度も届きます。新たに発表と引き上げの市町村等が無いまとまりは、エージェントに渡さず、記録だけ更新します。

AIに処理させる

させるのは、まとまりごとに、どの道具をどこまで引くかを決め、体制の案と理由、連絡すべき代理店、連絡文の下書きをまとめることです。

手順4を条件付きにしているのが、エージェントにする理由です。 1つの町に暴風警報が出ただけのまとまりで、過去の事例や人員まで引く必要はありません。基準に当てはめて「通常」なら、そこで止めさせます。 引く道具が多いほど時間がかかり、警報の最中の知らせが遅れます。

4行目は法令に関わります。 気象業務法第23条は、気象庁以外の者は気象などの警報をしてはならないと定めています。連絡文には「気象庁が〇〇市に大雨警報を発表しました」と出典を書き、自社が警戒を呼びかけるような書き方にしません。

指示内容を固定する

あなたは損害保険会社の損害サービス部で、気象庁が発表した警報を
受けて、事故受付の体制の案と連絡の準備をまとめる担当です。
道具で確かめた事実と、入力の電文の内容だけで答えてください。

【入力】
- 府県・まとまりの時刻：{prefecture} / {window}
- 新たに発表・引き上げの市町村等（種別・レベル）：{raised}
- 継続・解除の市町村等：{others}

【使える道具】
- get_policy_counts：市町村等のコードで、種目別の契約件数を返す
- get_rule：レベルと件数を渡すと、体制の基準の該当行を返す
- get_past_events：府県と種別で、過去の事例を返す
- get_staffing：日付で、受付の人員を返す
- get_agents：市町村等のコードで、代理店ごとの契約件数を返す

【進め方】
1. 新たに発表・引き上げの市町村等の契約件数を確かめてください。
2. get_rule で基準を当てはめてください。結果が「通常」なら、
   過去の事例と人員は引かずにまとめてください。
3. 「増員」以上なら、過去の事例と当日の人員を確かめてください。
   過去の事例が3件未満なら、事例から推し量らないでください。
4. 連絡すべき代理店を、契約件数の多い順に最大20店選んでください。

【厳守事項】
- 体制を決めたと書かないでください。「基準に当てはめると〇〇」と
  書き、決定は担当者に委ねてください。
- 事故の件数を予測した数字を書かないでください。
- 連絡文では、警報は「気象庁が〇〇に〇〇を発表」と出典を付けて
  書いてください。自社が警報や警戒を出すような表現にしないでください。
- 連絡文に契約者の氏名・証券番号を書かないでください。
  差し込みは {差し込み} の形で残してください。
- 道具が失敗したら、失敗した道具の名前を残し、推し量らないでください。

「結果が通常なら引かずにまとめる」を明記しないと、エージェントは念のためにすべての道具を引きます。 警報の多い日には、それだけで知らせが数分遅れます。

「体制を決めたと書かない」も明記します。 要約が「増員とする」と書けば、チャットを見た人は決まったものとして動きます。

出力形式を固定する

Structured Output Parser で、次の形のJSONを受け取ります。

{
  "group_id": "410000-2026-10-08T20:25",
  "prefecture": "佐賀県",
  "raised_areas": [
    { "area_code": "4120200", "area_name": "唐津市",
      "kind": "暴風警報", "level": "",
      "policies": { "fire": 0, "auto": 0 } }
  ],
  "rule_result": "normal | reinforce | special",
  "rule_row": "",
  "reason": "",
  "past_events_used": 0,
  "agents_to_contact": [
    { "agent_code": "", "policies_in_area": 0 }
  ],
  "agent_message_draft": "",
  "customer_notice_draft": "",
  "tool_errors": [],
  "needs_human": false
}

1つ目の理由は、rule_result と rule_row で案の根拠が分かることです。 担当者は基準のどの行に当たったかを見て、基準の当てはめが正しいかだけを確かめれば済みます。

2つ目は、past_events_used で事例の数が見えることです。 0件や1件なら、理由に事例の話が出てきても当てにしません。

3つ目は、下書きと集計を分けていることです。 下書きには差し込みの印だけが入り、契約者の個人の情報はエージェントを通りません。 送るときに、別の仕組みが差し込みます。

Structured Output Parser の Generate From JSON Example では、すべての項目が必須として扱われるとされています。空のときは空文字や空の配列を返させます。 $ref は使えないとされています。

システムへ連携する

契約管理システムへは書き込みません。 この構成が読むのは集計だけで、個人の契約の行は読みません。 契約者への案内を送る場合は、担当者が範囲を決めた後に、既存の通知の仕組みが差し込んで送ります。

人が確認する

人が見るのは、すべてのまとまりの案です。 ただし、見る深さを rule_result で変えます。

1. special と reinforce を先に見る … 基準の行、契約の件数、過去の事例を確かめ、体制を決めます
2. normal は件数と市町村等を流し見る … 契約の多い地域が含まれていないかだけを見ます
3. 代理店への連絡を決める … 下書きを直して送ります。送る前に、警報がまだ出ているかを電文の記録で確かめます
4. 契約者への案内は別に決める … 送る範囲（市町村等と種目）と時期を決め、既存の仕組みに渡します
5. 判断を記録する … とった体制、送った連絡、その後の事故受付の件数を、発表の記録に残します

5番目が、次の警報のときの「過去の事例」になります。 記録を残さないと、エージェントはいつまでも事例の少ないまま案を作ります。

夜間・休日は、当番の1名が1番目だけを見ます。 special と reinforce は当番が体制を決め、normal は翌朝の担当者に回します。

目標は、36件をならして1件15分です。 special のまとまりは30分以上かかり、normal は数分で終わります。

例外に対処する

4行目を0件として扱うと、いちばん危ない失敗になります。 契約が多い地域ほど、合併や区の新設でコードがずれていることがあり、そこで「契約0件・通常の体制」という案が出ます。

最後の行は、エージェントが止まっても知らせを止めないための手当てです。 件数と基準の当てはめは規則でできるので、生成AIが応答しないときも、最小限の案は届きます。

記録を残す

• 取得したフィードの時刻と、新しく取った電文のURL
• 電文から取り出した市町村等ごとの種別・状態・前の種別
• まとまりの内容と、エージェントに渡した入力
• 道具の呼び出しの記録（どの道具を、どの条件で引いたか）と結果のJSON
• 担当者が決めた体制、送った連絡、送った時刻
• その後の事故受付の件数（翌日以降に追記）

4つ目は、道具の引き方を見直すために残します。 Tools Agent の Return Intermediate Steps を有効にすると、途中の手順を出力に含められます。

最後の行は、次の警報のときの過去の事例になります。