厚生労働省の介護保険最新情報をエージェントが毎週確かめ、自社の事業所に関わる通知を要約して管理者に届け、対応の要否と完了までを追う

処理の起点を決める

n8n の Schedule Trigger で、毎週月曜の7時30分に動かします。 公式ページでは、Schedule Trigger は秒・分・時間・日・週・月の間隔か、cron の式で動く時刻を決められます。週の間隔では、動かす曜日と時刻を選びます。

タイムゾーンを必ず設定します。 公式ページでは、Schedule Trigger はワークフローのタイムゾーン、無ければインスタンスのタイムゾーンに従い、自分でサーバーに置く場合の既定は America/New York とされています。設定を忘れると、月曜の朝のつもりが日本の月曜の夜に動きます。ワークフローの設定で Asia/Tokyo を選びます。

サーバーが止まっていた週の扱いも決めておきます。 公式ページでは、n8n 2.36 以降で追加した Schedule Trigger には、実行を逃したときに直近の1回だけを後から動かす設定があり、durable scheduler で動かしているときだけ効くとされています。この構成では、逃した週の分を取りこぼさないよう、この設定を使うか、翌週の実行で前回からの差分をすべて拾う作りにします。 後者は台帳と照らす作りなので、もともとそうなっています。

週1回にしているのは、通知の性質に合わせてです。 通知には即日の対応を求めるものはほとんど無く、毎日動かすと、担当者の確認が毎日発生します。 災害の特例のように急ぐものは、掲載ページ以外の経路でも届きます。

入力データを集める

質を決めるのは、事業所の一覧のサービス種類と加算の列です。 「訪問介護の特定事業所加算の取扱い」という通知は、特定事業所加算を算定している訪問介護の事業所にだけ関わります。サービス種類だけで見分けると、算定していない事業所にまで届き、届きすぎた通知は読まれなくなります。

通知の表紙には、見分けに効く情報がまとまっています。 介護保険最新情報の表紙には、号の番号と日付、発出元の課、宛先（各都道府県の介護保険担当課など）、「今回の内容」としての件名、本紙を除いた枚数が書かれています。エージェントは、まず表紙だけで判断できるかを見ます。

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

掲載ページは HTTP Request ノードで取得し、HTML ノードの「Extract HTML Content」で取り出します。公式ページでは、HTML ノードは CSS セレクターで要素を探し、属性・HTML・文字・値のいずれかを返すとされています。

号の番号は正規化してから照らします。 掲載ページの表記は「Vol.」と「vol.」が混在し、行頭の記号も「○」と「〇」が混ざっています。「介護保険最新情報」の直後の数字だけを取り出して台帳のキーにします。 件名の中にも「Q&A（Vol.16）」のように別の番号が書かれることがあり、「Vol.」の後の数字を全部拾うと、存在しない号を拾います。

新しい号の判定は、番号の大小ではなく台帳に無いかどうかで行います。 一覧の中で番号の順が前後して見える箇所があり、「前回の最大の番号より大きいもの」だけを拾うと取りこぼします。 台帳に無い番号はすべて新しい号として扱います。

本文の取得は、エージェントのツールとして用意したサブワークフローで行います。HTTP Request でPDFを取り、Extract From File ノードの「Extract From PDF」で文字にします。公式ページでは、Extract From File は PDF などのバイナリのファイルから中身を取り出して JSON にするノードとされています。

AIへ渡す前に整形する

1. 号の番号を正規化する … 「Vol.」「vol.」、全角・半角の数字をそろえ、数字だけをキーにします
2. 台帳と照らす … Data Table の「If Row Does Not Exist」で、台帳に無い号だけを残します
3. 表紙と本文を分ける … 1ページ目の表紙から、号・日付・宛先・件名・枚数を取り出し、別紙と分けます
4. 本文の長さを確かめる … 別紙が数十ページに及ぶものは、目次と冒頭の数ページに絞ってエージェントに渡します
5. 文字が取れないPDFを見分ける … 取り出した文字がほとんど無いものは、画像のPDFとして人に回します
6. 事業所の一覧を短くする … サービス種類と加算の列だけを渡し、管理者の氏名やメールアドレスはエージェントに渡しません

3番目が効きます。 表紙の「今回の内容」と枚数を先に見れば、研修の案内やセミナーの告知は本文を読まずに見分けられます。 エージェントが本文を取りに行く回数が減り、そのぶん処理が速く安くなります。

6番目は、エージェントに要らない情報を渡さないためです。 見分けに要るのはサービス種類と加算だけで、誰に送るかはワークフローが台帳から引きます。

AIに処理させる

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

Max Iterations を小さくします。 公式ページでは、Tools Agent がモデルを動かす回数の上限は既定で10とされています。1つの号で本文を読みに行くのは多くても1〜2回なので、上限を小さくして、ツールを呼び続ける暴走を止めます。

指示内容を固定する

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

あなたは介護事業の法人本部の担当として、厚生労働省の介護保険最新情報を読み、
自社のどの事業所に関わるかを見分けます。

【入力】
- 新しい号の表紙の情報（号、日付、発出元、宛先、件名、枚数）
- 事業所の一覧（事業所ID、サービス種類、算定している主な加算）

【進め方】
1. まず表紙の件名だけで、関わるサービス種類が分かるかを判断してください。
2. 件名で分からない場合だけ、fetch_body ツールで本文を取得してください。
   1つの号について本文の取得は2回までです。
3. 関わるサービス種類と加算・基準を書き出し、事業所の一覧と照らしてください。
4. 要約は、事業所の管理者が読んで「自分の事業所で何を確かめるか」が分かる
   300字以内の文にしてください。

【厳守事項】
- 加算を算定できるか、基準に合っているかの判断は書かないでください。
  「〇〇を確かめてください」の形にしてください。
- 期日は本文に書かれた日付だけを写し、どこに書かれていたか（ページ・項目）を
  添えてください。書かれていなければ空にしてください。計算しないでください。
- 本文を読んでも関わるかどうか決められないときは、relevance を "unsure" にし、
  理由を書いてください。"none" にしないでください。
- 掲載ページと本文以外の知識で補わないでください。
- 研修・セミナー・調査への協力依頼は、notice_type を分けて書いてください。

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

「期日を計算しない」も同じ理由です。 「通知の日から1か月以内」と書かれていれば、エージェントは日付を計算して書きます。計算された日付は、原文の書き方と並べないと正しいか確かめられません。 原文の記載箇所を写させ、日付は人が確かめます。

出力形式を固定する

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

{
  "vol_no": 1541,
  "notice_type": "rule_change | interpretation | survey | training | other",
  "relevance": "relevant | none | unsure",
  "services": ["訪問介護"],
  "related_items": ["特定事業所加算"],
  "offices": ["H01", "H02"],
  "summary": "",
  "actions": ["〇〇を確かめてください"],
  "deadline_text": "",
  "deadline_location": "",
  "body_read": true,
  "reason": ""
}

1つ目の理由は、relevance で人の確認の順番を決められることです。 unsure を最初に、relevant を次に、none は件名だけを一覧で流します。

2つ目は、offices をワークフローが送り先に変えることです。 エージェントは事業所IDを返すだけで、メールアドレスはワークフローが事業所の一覧から引きます。 エージェントに送り先を決めさせません。

3つ目は、body_read で「件名だけで判断した」ものが分かることです。 件名だけで none にした号は、本部の担当者が件名を見て違和感があれば本文を開く対象になります。

台帳（Data Table）には、通知×事業所の1行で書き込みます。

配信のメールには、要約の末尾に「厚生労働省 介護保険最新情報 Vol.〇〇（原文のURL）をもとに、法人本部が要約したものです」と入れます。

システムへ連携する

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

管理者への配信は、Gmail ノードの Send and Wait for Approval で送ります。 公式ページでは、この操作はメールを送って受信者の承認を待ってからワークフローを続けるもので、承認のボタンだけか、承認と不承認の2つのボタンかを選べ、ボタンの文字を変えられるとされています。ボタンを「対応した」「対応不要」に変えて使います。 公式ページは、複雑な承認には Wait ノードを使うよう勧めていますが、この構成の返事は2択なので足ります。

返事を待つあいだ、ワークフローの実行は止まったままになります。 待つ実行が事業所の数だけ並ぶため、配信ごとに実行を分け、翌週の一覧は台帳の状態から作ります。

人が確認する

本部の担当者が、毎週月曜にエージェントの判定の一覧を確かめてから配信します。

1. unsure を先に見る … 本文を開き、関わるかどうかを決めます。決めかねるものは、指定権者に確かめる候補として残します
2. relevant の要約と事業所を確かめる … 関わる事業所に漏れや余計なものが無いか、要約が原文と食い違っていないかを見ます
3. deadline_text を原文で確かめる … 期日の記載箇所を開き、日付を確かめます
4. none の件名を流し見る … 件名だけで違和感があるものは本文を開きます
5. 直して承認する … 承認したものだけが管理者へ送られます

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

翌週の月曜には、返事の無い配信が一覧の先頭に出ます。 2週続けて返事の無い事業所には、本部から電話をかけます。ここで声をかけることが、この構成の目的の半分です。

例外に対処する

1行目がいちばん怖い失敗です。 掲載ページの書き方が変わると、セレクターが何も拾わなくなり、「今週は新しい号が無い」と区別がつかなくなります。 掲載ページの号の総数を毎回記録し、前回より減っていたら異常として扱います。

記録を残す

• 毎週取得した掲載ページの号の一覧（番号・件名・発出日・リンク）と、号の総数
• 新しい号ごとのエージェントの出力と、本文を読んだか（body_read）
• 本部の担当者が直した箇所（判定・事業所・要約・期日）
• 配信した日時、事業所、メールの本文
• 管理者の返事と日時、返事の無かった週と本部の対応

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

5つ目は、運営指導の準備に効きます。 国の通知を、いつ、どの事業所に伝え、いつ対応を確かめたかを示せます。