国・都道府県のサイトに載る自治体向けの通知・事務連絡を毎日見回り、新しく載ったものを要約して担当課に振り分ける

処理の起点を決める

トリガーは Schedule Trigger で、毎営業日の7時30分と13時です。 7時30分の分で前日の夕方以降の掲載を拾い、始業前に一覧を作ります。13時の分は、午前中の掲載を拾うためです。ワークフローのタイムゾーンを Asia/Tokyo にします。n8n の公式の説明では、ワークフローにタイムゾーンが無ければインスタンスのタイムゾーンが使われ、自分でホストする場合の既定は America/New_York とされています。保存して公開しないと、予定どおりに動きません。

見回りの回数を増やしすぎないでください。 1時間ごとに見ても、掲載の数は増えません。1日2回で足りるのは、通知の多くが数日から数週間の準備期間を置いているからです。

休日には動かしません。 休日に載った通知は、翌営業日の7時30分の分で拾えます。

入力データを集める

質を決めるのは、事務分掌の表です。 規則に書かれた所掌事務の文言だけでは、「介護情報基盤」「ケアプランデータ連携」のような新しい言葉がどの課の事務かが分かりません。過去の振り分けの記録と、課ごとの「よく出る言葉」の列で補います。

見回り先の一覧には、抜き出しの決まりをページごとに持たせます。 例えば厚生労働省の介護保険最新情報の掲載ページは、通知ごとにPDFへのリンクがあり、リンクの文字に号数と題名、その次の行に発出の日と発出元・種別（事務連絡、局長通知など）が書かれる形です。ページごとに形が違うので、ページごとにセレクタを決めます。

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

HTTP Request ノードは、応答の形式を自動判別・ファイル・JSON・テキストから選べます。 掲載ページはテキストで受け、PDFはファイルで受けます。取得に失敗したページは「Never Error」で止めずに受け、ステータスを見て見回り先の一覧に失敗を記録します。 1ページの失敗で全体が止まると、ほかの29ページの新着も拾えません。

HTML ノードのオプションには、前後の空白と改行を取り除く「Trim Values」と、連続する空白を1つにする「Clean Up Text」があります。 題名の比較が空白の違いでずれないように、両方を有効にします。

比べる値は、題名ではなくリンクにします。 題名は後から直されることがありますが、PDFのリンクは号ごとに別のものになっていることが多いからです。題名が直っただけのものを新着として二重に回さずに済みます。

取りに行くときは、どこの誰が取りに来ているかが相手に分かるようにします。 HTTP Request のヘッダーに、市の名前と問い合わせ先を入れた名乗りを付けておけば、相手のサイトの管理者が負荷を気にしたときに連絡が届きます。見回り先の一覧には、そのサイトの利用規約と robots.txt を確かめた日も列として持たせ、半年に1回見直します。

AIへ渡す前に整形する

1. ページの取得を確かめる … ステータスが成功で、取り出したリンクが0件でないかを見ます。0件なら、ページの形が変わったと見なして総務課に知らせます
2. リンクを絶対パスにそろえる … ページの中のリンクは相対パスのことがあるので、ページのURLを付けて完全な形にします
3. 差分を取る … Remove Duplicates で、以前の実行で処理したリンクを除きます
4. 初回の取り込みを分ける … 見回り先を新しく足した日は、そのページの既存の通知をすべて「既読」として記録するだけにし、一覧には出しません
5. PDFの文字を確かめる … 取り出せた文字が極端に少なければ、画像のPDFと見なし、題名だけで一覧に出します
6. 収受の記録と照らす … 題名・発出元・日付で、文書管理の仕組みに同じものが届いていないかを見ます

4番目を忘れると、初日に数百件の「新着」が出ます。 掲載ページには過去の通知が並んでいるので、足した日の分はすべて見たことにしてから、翌日から差分を取ります。

1番目は、黙って止まるのを防ぐためです。 相手のサイトのページの作りが変わると、セレクタが何も拾わなくなります。エラーにはならず「新着0件」が続くので、0件のページを毎日数えて知らせます。

AIに処理させる

させるのは、新しく載った通知1件ごとに、要点と期限を原文の箇所付きで取り出し、道具を引いて担当課の候補を出すことです。

エージェントにするのは、道具の引き方が通知ごとに変わるからです。 介護保険の通知なら過去の振り分けで足りることが多く、新しい制度の通知は事務分掌の表を言葉を変えて何度か引く必要があります。

2行目が見落とされやすい失敗です。 「本市では対応不要と考えられる」のような一文を、エージェントは自然に書き足します。その一文があると、担当課は本文を開かなくなります。

指示内容を固定する

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

あなたは市役所の総務課で、国・県のウェブサイトに新しく載った通知を読み、
要点と期限をまとめて、担当課の候補を出す立場です。

【取り出すもの】
- summary：何についての通知か、何が変わるか、誰に何を求めているかを2〜3文で。
- kind：request（照会・調査・提出・手続きの変更）／info（情報提供・周知）／
  event（会議・研修の案内）から1つ。迷ったら request にしてください。
- deadlines：回答・提出・手続きの期限、施行や適用の日。
  日付は原文の書き方のまま写し、根拠にした原文を quote に入れてください。
  期限を計算したり、読み替えたりしないでください。書かれていなければ空にしてください。

【担当課の候補の出し方】
- まず get_past_routing で、同じ発出元・似た題名の過去の通知を見てください。
- 次に search_duties で、通知の中の制度・事務の名前を使って事務分掌の表を引いてください。
  当たらなければ、言葉を変えて2回まで引き直してください。
- 候補の課ごとに、根拠（事務分掌の表のどの事務か、過去のどの通知か）を書いてください。
- 根拠が見つからない課を候補にしないでください。見つからなければ candidates を空にし、
  needs_routing を true にしてください。

【書かないこと】
- 本市で対応が要るかどうか、どう対応すべきかを書かないでください。
- 通知の本文を長く写さないでください。quote は期限の根拠の部分だけにしてください。

【通知】
発出元：{issuer} ／ 種別：{doc_type} ／ 発出の日：{issued_on} ／ 題名：{title}
掲載ページ：{page_url} ／ 本文：{text}

「迷ったら request」にするのは、取りこぼしの重さが違うからです。 情報提供を照会と取り違えても、担当課が読んで「対応不要」とするだけです。照会を情報提供と取り違えると、回答の期限を逃します。

「根拠が見つからない課を候補にしない」を書かないと、もっともらしい課を当てます。 「総務課」「企画課」のような広い課に寄せがちで、寄せられた課は自分の事務ではないと判断して放置します。 空にして人に決めてもらうほうが、宙に浮きません。

出力形式を固定する

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

{
  "notice_url": "",
  "page_url": "",
  "issuer": "",
  "title": "",
  "issued_on": "",
  "kind": "request | info | event",
  "summary": "",
  "deadlines": [
    { "type": "reply | submit | effective | other", "date_text": "", "quote": "" }
  ],
  "candidates": [
    { "department": "", "basis": "duties | past_routing", "basis_detail": "" }
  ],
  "needs_routing": false,
  "already_received": false
}

1つ目の理由は、candidates に根拠が付くことです。 文書の担当は、候補の課が事務分掌のどの事務から出てきたかを見て、短い時間で回付を決められます。 根拠が「過去の振り分け」だけなら、過去の回し方が正しかったかも見ます。

2つ目は、kind と deadlines で並べ替えられることです。 ワークフローの側で、照会で期限が近いものを一覧の上に出します。

3つ目は、already_received で二重の回付を防げることです。 収受済みのものは一覧の下に「参考」として出し、担当課には回しません。

システムへ連携する

担当課へは、文書の担当が確かめてから回します。 エージェントの候補のまま自動で回すと、誤った課に回った通知は、その課で止まります。

文書管理の仕組みには書き込みません。 掲載だけの通知を正式な収受として扱うかは、自団体の文書の決まりに従って文書の担当が決めます。

人が確認する

総務課の文書の担当が見るのは、毎朝8時30分の一覧です。

1. 「至急」を最初に見る … 照会で期限の近いもの。要約と期限の quote を見て、その日の午前のうちに担当課へ回します
2. 「要振り分け」を見る … 候補の無いもの、候補の多いもの。題名と本文の冒頭を読み、回す課を決めます
3. 「通常」を流し見る … 候補の課と根拠が合っていれば、そのまま回します
4. 振り分けの結果を記録する … 最終的に回した課を残します。これが次の get_past_routing の中身になります
5. 見回り先の失敗を見る … 0件が続くページ、取得に失敗したページを確かめ、セレクタを直します

4番目を続けると、候補の当たり方が良くなります。 新しい制度の通知も、一度人が回した記録があれば、次の号からは過去の振り分けで候補が出ます。

回された担当課の側にも、確かめることがあります。 要約は本文の代わりではないので、照会や手続きの変更は必ず元のPDFを開いて読みます。 一覧に元のページへのリンクを付けているのは、そのためです。担当課が「自課の事務ではない」と返してきたものは、文書の担当が回し直し、その結果も振り分けの記録に残します。

目標は、1件2分です。 至急と要振り分けは丁寧に見て、通常は根拠を確かめて回すだけにします。

例外に対処する

2行目が、この構成でいちばん起きやすい止まり方です。 相手のサイトのページの作りは、予告なく変わります。黙って0件が続く状態を、毎日の数字で見つけます。

記録を残す

• 見回りの結果（ページごとの取得の成否、取り出したリンクの数、新着の数）
• 新しく載った通知のリンク、題名、発出元、取った日時、PDFから取り出した文字
• エージェントの入力、呼んだ道具とその結果、出力のJSON
• 文書の担当が回した課と、候補から変えた場合は変える前の候補
• 担当課が決めた対応の要否

1つ目の「ページごとの取得の成否」は、見落としを説明するために残します。 「なぜあの通知が回ってこなかったのか」と聞かれたとき、その日にそのページが取れていたか、セレクタが拾えていたかを確かめられます。