損害保険会社のコンプライアンス部門で、金融庁と業界団体の公表資料をエージェントが毎週見回り、自社の業務に関わるものを要約して担当部署へ回す

処理の起点を決める

トリガーは2つに分けます。 収集は Schedule Trigger で毎日8時、エージェントの判定は 毎週月曜の8時30分です。公式ページでは、Schedule Trigger は秒・分・時間・日・週・月の間隔か cron の式で動く時刻を決められ、ワークフローを保存して公開しないと動かないとされています。

収集を毎日にするのは、RSS が短いからです。 確認した時点の金融庁の新着情報RSSは15件で、最も古いものと新しいものの間は5日ほどでした。週に1回だけ取りに行くと、新着の多い週は古いものが RSS から外れた後になります。 毎日取りに行って台帳に積んでおけば、取りこぼしません。

判定を週に1回にするのは、人の確認をまとめるためです。 毎日エージェントを動かすと、担当者の確認も毎日発生します。意見募集の締切は公表から数週間先に置かれることが多く、週1回の回付で間に合います。 ただし、題名に「意見募集」「行政処分」を含むものは、収集の段で担当者に即日の通知を出します。

タイムゾーンは、自分でサーバーに置く場合の既定が America/New York とされています。ワークフローの設定で Asia/Tokyo を選びます。

入力データを集める

質を決めるのは、部署と所管業務の一覧です。 「代理店の業務品質の評価」についての資料は、代理店を管理する営業推進部と、評価の仕組みを持つ部署に関わります。部署の名前だけを渡すと、エージェントは名前の字面で回し先を選びます。所管する業務を具体的に書いておくほど、回し先が当たります。

他社への行政処分は、「処分の理由」を読むものとして扱います。 一覧の所管業務に「募集管理」「営業職員の管理」のような項目があれば、エージェントは処分の理由に書かれた問題と照らせます。

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

金融庁の新着情報は RSS Read ノードで取ります。 公式ページでは、RSS Read ノードはインターネットに公開された RSS フィードを読むノードで、URL を指定します。取得した項目のリンクを、台帳のキーにします。

協会のニュースリリースは、HTTP Request ノードで一覧のページを取り、HTML ノードの「Extract HTML Content」で取り出します。 公式ページでは、HTML ノードは CSS セレクターで要素を探し、属性・HTML・文字・値のいずれかを返し、複数の値を配列で返す設定があるとされています。

新しいものの判定は、台帳に無い URL かどうかで行います。 Data Table の「If Row Does Not Exist」で、台帳に無いものだけを残します。

本文と別紙は、エージェントのツールとして用意したサブワークフローで取ります。 本文は HTTP Request でページを取り、HTML ノードで本文の領域の文字と別紙へのリンクを取り出します。別紙は HTTP Request でPDFを取り、Extract From File ノードの「Extract From PDF」で文字にします。

AIへ渡す前に整形する

1. URL を正規化する … 末尾の # 以降を外し、http と https をそろえてから台帳と照らします
2. 出どころと分野の手がかりを付ける … 金融庁か協会か、金融庁なら URL の分野の部分（hoken、sonota など）を項目として持たせます
3. 即日の通知を出す … 題名に「意見募集」「行政処分」を含むものは、収集の段で担当者に知らせます
4. 本文の長さを確かめる … 別紙が数十ページに及ぶものは、目次・冒頭・新旧対照表の該当部分に絞って渡します
5. 文字が取れないPDFを見分ける … 取り出した文字がほとんど無いものは、画像のPDFとして人に回します
6. 部署の一覧を短くする … 部署と所管業務・保険種目だけを渡し、メールアドレスはエージェントに渡しません

2番目が、エージェントの読む量を減らします。 URL が国際関係の資料のものなら、題名と合わせて見るだけで、本文を開かずに見分けられることが多くなります。ただし手がかりとして渡すだけで、URL で機械的に外すことはしません。 分野の外に置かれた資料が保険会社に関わることもあるからです。

AIに処理させる

n8n の AI Agent ノード（Tools Agent）に、公表資料ごとの見分けを任せます。 公式ページでは、Tools Agent はツールの使い方を理解して、どのツールを使うかを課題に応じて決めるとされ、出力の形を決める Output Parser を、書式のためのツールとしてモデルに渡すとされています。対応するチャットモデルに Anthropic Chat Model が含まれ、使えるツールに Call n8n Workflow と HTTP Request が含まれます。

Max Iterations を小さくします。 公式ページでは、Tools Agent がモデルを動かす回数の上限は既定で10とされています。1件で本文と別紙を読みに行くのは多くても2〜3回なので、上限を小さくして、ツールを呼び続ける暴走を止めます。 Return Intermediate Steps を有効にし、どのツールを何回呼んだかを台帳に残します。

指示内容を固定する

AI Agent の System Message に、次のように書きます。

あなたは損害保険会社のコンプライアンス統括部の担当として、金融庁と
日本損害保険協会の公表資料を読み、自社のどの部署に関わるかを見分けます。

【入力】
- 公表資料の題名、URL、出どころ（金融庁／協会）、URL の分野の手がかり、公表日
- 部署と所管業務の一覧（部署ID、所管する業務、扱う保険種目）

【進め方】
1. まず題名と URL の手がかりだけで、関わるかどうかを判断できるか考えてください。
2. 判断できない場合だけ、fetch_page ツールで本文のページを読んでください。
3. 本文に別紙があり、別紙を読まないと判断できない場合だけ、fetch_pdf ツールで
   読んでください。1件について、ツールの呼び出しは合わせて3回までです。
4. 関わる場合は、関わる業務を書き出し、部署と所管業務の一覧と照らしてください。
5. 要約は、部署の担当者が読んで「自分の部署で何を確かめるか」が分かる
   300字以内の文にしてください。

【厳守事項】
- 法令や監督指針の解釈、自社が満たしているかの判断は書かないでください。
  「〇〇を確かめてください」の形にしてください。
- 施行日・適用日・意見募集の締切は、本文に書かれた記載だけを写し、
  どこに書かれていたか（本文／別紙の名前とページ）を添えてください。
  書かれていなければ空にしてください。日付を計算しないでください。
- 読んでも関わるかどうか決められないときは、relevance を "unsure" にし、
  理由を書いてください。"none" にしないでください。
- 他社に対する行政処分は、処分の理由に書かれた問題を要約し、
  自社の所管業務のどれと照らすべきかを書いてください。
  他社の名前を要約に書かず、「保険会社に対する行政処分」と書いてください。
- 公表資料と本文・別紙以外の知識で補わないでください。
- 根拠にした本文の一文を evidence にそのまま写してください。

「決められないときは unsure にし、none にしない」が最も大事な一文です。 書いておかないと、エージェントは決めかねた資料を「関わらない」に寄せます。「関わらない」は人の目に最も触れにくい判定なので、迷ったものは人に回る側へ倒します。

「日付を計算しない」も同じ理由です。 「公布の日から起算して1年を超えない範囲内において政令で定める日」と書かれていれば、エージェントは日付を推し量って書きます。推し量った日付は、原文の書き方と並べないと正しいか確かめられません。 原文の記載をそのまま写させます。

他社の名前を書かせないのは、部署に回るのが「自社に当てはまらないかを確かめる材料」だからです。名前は原文のリンクで分かります。

出力形式を固定する

Structured Output Parser で、次の形に決めます。 公式ページでは、JSON の例から生成するか、JSON Schema で定義するかを選べ、例から生成するとすべての項目が必須として扱われ、JSON Schema の $ref には対応しないとされています。

{
  "url": "",
  "source": "fsa | sonpo",
  "doc_type": "law | guideline | public_comment | enforcement | request | other",
  "relevance": "relevant | none | unsure",
  "business": ["代理店管理"],
  "departments": ["D03"],
  "summary": "",
  "actions": ["〇〇を確かめてください"],
  "date_text": "",
  "date_location": "",
  "evidence": "",
  "read_level": "title | page | attachment",
  "reason": ""
}

1つ目の理由は、relevance で人の確認の順番を決められることです。 unsure、relevant の順に見て、none は題名だけを流します。2つ目は、departments をワークフローが送り先に変えることです。 メールアドレスはワークフローが一覧から引き、エージェントに送り先を決めさせません。 3つ目は、read_level で「どこまで読んで判断したか」が分かることです。

台帳（Data Table）には、公表資料×部署の1行で書き込みます。

回付のメールには、要約の末尾に「出典：金融庁ウェブサイト（原文のURL）をもとに、コンプライアンス統括部が要約したものです」と入れます。協会のものは「日本損害保険協会（原文のURL）」とします。

システムへ連携する

台帳には n8n の Data Table を使います。 公式ページでは、Data Table は n8n の中に構造化されたデータを持ち、ワークフローをまたいで使えるとされ、行の追加・更新・取得・Upsert のほか、「行が存在するか」「存在しないか」で入力を振り分ける操作があります。収集のワークフローと判定のワークフローで同じ台帳を使います。

部署への回付は、Microsoft Outlook ノードの Send and Wait for Response で送ります。 公式ページでは、この操作はメッセージを送って相手が応じるまで実行を止めるもので、応答の種類に承認・自由記述・独自のフォームがあり、承認では承認だけか承認と不承認の2つのボタンかを選べ、ボタンの文字を変えられるとされています。ボタンを「確認した」「当部署には関係なし」に変えます。 待つ時間の上限（Limit Wait Time）も設定でき、上限を過ぎたら「未返信」として台帳に戻す作りにします。

人が確認する

コンプライアンス統括部の担当者が、毎週月曜にエージェントの判定の一覧を確かめてから回付します。

1. unsure を先に見る … 本文と別紙を開き、関わるかどうかを決めます
2. relevant の要約と部署を確かめる … 関わる部署に漏れや余計なものが無いか、要約が原文と食い違っていないかを見ます
3. date_text を原文で確かめる … 期日の記載箇所を開きます。意見募集の締切は、部署が意見をまとめる時間を逆算して回付の文に書き足します
4. none の題名を流し見る … 題名だけで違和感があるものは本文を開きます
5. 直して承認する … 承認したものだけが部署へ送られます

4番目を省かないでください。 none の誤りは、それ以外の判定の誤りと違い、後から誰も気づく機会がありません。 月80件のうち多くは none ですが、題名を流すだけなら数分で済みます。

翌週の月曜には、返事の無い回付が一覧の先頭に出ます。

例外に対処する

最後の行が、この構成に固有の弱点です。 金融庁の RSS は短いので、収集が数日止まると、その間の新着が RSS から外れることがあります。収集のワークフローが毎日動いたかを台帳の取得日で確かめ、抜けた日があれば一覧のページで補います。 また、RSS のページには配信後にページが削除されたり URL が変わったりする場合があると書かれているため、収集した日のうちに本文を取っておきます。

記録を残す

• 毎日取得した RSS と一覧の件数、新しく台帳に入れた URL
• 公表資料ごとのエージェントの出力と、どこまで読んだか（read_level）、ツールを呼んだ回数
• 担当者が直した箇所（判定・部署・要約・期日）
• 回付した日時、部署、メールの本文
• 部署の返事と日時、返事の無かった週と担当者の対応
• 金融庁の資料は、取得した本文の文字（出典の URL と取得日を付けて）

3つ目を残すのは、エージェントの癖を知るためです。 同じ種類の資料で毎回 none から relevant に直しているなら、部署と所管業務の一覧の書き方か、プロンプトが足りていません。

5つ目は、社内の監査への説明に効きます。