e-Govのパブリック・コメントに新しく出た案件のうち自社の事業に関わるものを拾い、論点と締切を要約して関係部署に知らせる

処理の起点を決める

毎朝9時30分に、Schedule Trigger で動かします。 Schedule Trigger はワークフローのタイムゾーンを使い、無ければインスタンスのタイムゾーンを使います。セルフホストの既定は America/New York なので、ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動きません。

9時30分にしているのは、RSSの更新の時刻を見てのことです。 確認の時点で、RSS全体の更新日時は当日の9時01分でした。それより前に取ると、前日の分しか載っていないことがあります。 毎朝の更新が終わった後に取り、部署の朝の会議の前に知らせます。

締切の催促は、別の Schedule Trigger で毎朝8時に動かします。 案件の台帳を読み、締切まで10日と3日の案件で、部署の回答が空のものを担当者へ知らせます。

入力データを集める

質を決めるのは、自社の事業の一覧です。 「化学物質」とだけ書くと、化学物質に触れた案件がすべて関わりありになります。「毒物及び劇物取締法：自社の取扱品のうち〇〇と〇〇が劇物。指定の追加は品質保証部と物流子会社に影響」のように、関わる理由まで書きます。 エージェントは、この説明を読んで判断します。

過去の案件の記録は、同じ法令の案件が繰り返し出るときに効きます。 毎年のように改正される告示では、前回どの部署に回し、意見を出したかを見れば、回す先がすぐ決まります。

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

RSSは HTTP Request ノードで取ります。 Response を Text にして、XML ノードの XML to JSON で JSON にします。RSS 1.0 では項目が rdf:RDF の下に並ぶ形なので、RSS 2.0 を前提にした取り出し方では空になります。 XML ノードの Explicit Array を有効にして、案件が1件の日も配列で受け取ります。

新しい案件の検出は、Remove Duplicates ノードの Remove Items Processed in Previous Executions で行います。 Keep Items Where を Value Is New にし、Value to Dedupe On に詳細ページのURLから取り出した案件番号（id= の値）を入れます。履歴は既定で10,000件まで持つとされています。

詳細ページは HTTP Request で取り、HTML ノードの Extract HTML Content で項目を取り出します。 項目名と値が並ぶ表から、CSS Selector で各項目を取ります。資料のリンクは、Return Value を Attribute にして href を、Text にして資料の題名を取り、Return Array を有効にします。 資料のURLは /pcm/download?seqNo=... の相対パスなので、https://public-comment.e-gov.go.jp と結んで絶対パスにします。

PDFは、エージェントが道具として呼ぶサブワークフローで読みます。 HTTP Request の Response を File にしてPDFを受け取り、Extract From File の Extract From PDF で文字を取り出します。エージェントには Call n8n Workflow Tool として渡します。 サブワークフローは公開しておかないと、本番で呼び出しが失敗します。

詳細ページとPDFの取得は、Batching で Items per Batch を1、Batch Interval を数秒にして、間隔をあけて順に取ります。

AIへ渡す前に整形する

1. 案件番号を取り出す … 詳細ページのURLの id= の値を案件番号とし、重複の判定と台帳の鍵に使います
2. 公示日はRSSの説明から取る … RSSの各案件の dc:date は 2026-10-07T15:00:Z のように秒が欠けたUTCの形でした（10月8日公示の案件）。日付の処理が失敗しうるので、説明の中の「案の公示日」を使います
3. 受付締切日時を読み替える … 「0時0分」で終わる締切は、前日の23時59分として台帳に書きます。 部署へ伝える締切は、さらに社内の取りまとめの日数を引いた日にします
4. 30日未満の理由を拾う … 「意見提出が30日未満の場合その理由」に記載があれば、期間が短い案件として印を付けます
5. 資料の一覧を作る … 資料の区分（意見募集要領、命令などの案、関連資料）、題名、URLを表にします
6. 事業の一覧と結ぶ … カテゴリーと根拠の法令で、事業の一覧の該当行を引き、エージェントに渡す入力に付けます

3番目を省くと、締切の当日に提出しようとして間に合いません。 e-Govの案内では、意見の提出期間は原則として案の公示日から起算して30日以上とされています。社内で取りまとめる日数を考えると、知らせが1日遅れるだけで部署の検討の時間が目に見えて減ります。

AIに処理させる

させるのは、案件ごとに自社との関わりを判断し、関わりがありそうなものは資料を読んで、論点と施行の予定と関係部署の候補を、根拠付きでまとめることです。

手順1で関わりなしとした案件も、理由を1行で残させます。 「船舶による危険物の運送の基準。自社は海上輸送を委託しておらず事業の一覧に該当なし」のように書かせると、担当者は一覧で判断を確かめられます。

読む資料には上限を置きます。 Tools Agent の Max Iterations は既定で10とされています。1件で読むPDFは最大3本とし、それを超えて読む必要があれば needs_human を立てて止めさせます。

3行目がいちばん起きやすい失敗です。 概要に「公布の日から施行」「令和〇年〇月〇日から施行予定」と書かれていれば写せますが、書かれていないときに、前回の改正の時期から推し量って書きます。 書かれていなければ「資料に記載なし」とさせます。

指示内容を固定する

あなたは化学品と電子部品のメーカーの経営企画部で、e-Govの
パブリック・コメントに新しく出た案件が、自社の事業に関わるかを
調べる担当です。道具を使って資料を読み、読んだ資料に書かれている
ことだけで答えてください。

【入力】
- 案件番号・題名・カテゴリー・所管：{case}
- 根拠法令条項・手続の種類：{basis}
- 締切（社内の読み替え済み）・30日未満の理由：{deadline}
- 資料一覧（区分・題名・URL）：{documents}
- 事業の一覧の該当行：{business_rows}

【使える道具】
- read_document：資料のURLを渡すと、ページ番号付きの本文を返す
- get_business：法令名か語を渡すと、事業の一覧の行を返す
- get_past_cases：法令名を渡すと、過去の案件と回した部署を返す

【進め方】
1. 題名・根拠法令・カテゴリー・資料の題名から、関わりの見込みを
   high / possible / none で付けてください。none の理由を1行で。
2. high と possible は、概要、命令などの案の順に読んでください。
   1件で読むのは最大3本です。超える必要があれば needs_human を
   true にして止めてください。
3. 自社の取扱品・業種・設備に当たる記述があれば、資料の区分、
   ページ、原文の抜き書き（そのまま写す）を残してください。
4. 何が変わるか、施行の予定、関係部署の候補をまとめてください。

【厳守事項】
- 施行日・適用日は、資料に書かれていれば写し、なければ
  「資料に記載なし」としてください。推し量らないでください。
- 意見を出すべきか、影響が大きいかを書かないでください。
- 締切は入力の値をそのまま使ってください。書き換えないでください。
- 関わる記述が見つからなければ、無理に関わりを作らず
  relevance を none にしてください。
- 本文が取り出せなかった資料は、読めなかったとして記録してください。

「締切は入力の値をそのまま使う」を明記するのは、0時0分の読み替えを規則の側で済ませているからです。 何も言わなければ、エージェントは資料の中の「〇月〇日まで」を拾い直し、読み替える前の日付で上書きします。

「関わる理由」を入力の事業の一覧から渡しているのは、判断の根拠をそろえるためです。 エージェントの一般的な知識で関わりを決めると、同じ案件でも日によって判断が揺れます。

出力形式を固定する

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

{
  "case_no": "495260197",
  "title": "",
  "category": "厚生",
  "ministry": "",
  "deadline_internal": "2026-11-06T23:59",
  "short_period": false,
  "relevance": "high | possible | none",
  "relevance_reason": "",
  "documents_read": [
    { "kind": "概要", "url": "", "read_status": "read | unreadable" }
  ],
  "findings": [
    { "business_row": "", "doc_kind": "", "page": 0, "quote": "" }
  ],
  "what_changes": "",
  "effective_date": "",
  "departments": ["品質保証部"],
  "needs_human": false,
  "needs_human_reason": ""
}

1つ目の理由は、quote と page で確認が速くなることです。 担当者は資料の該当ページを開いて抜き書きと見比べるだけで済みます。ワークフローの側で、quote が取り出した本文にそのまま含まれるかを確かめ、含まれなければ印を付けます。

2つ目は、relevance_reason で判断の根拠が一覧に並ぶことです。 none の理由を流し見れば、事業の一覧の書き漏れが見えてきます。

3つ目は、deadline_internal と short_period を台帳に書けることです。 催促のワークフローはこの2つの項目だけを見て動きます。

Structured Output Parser の Generate From JSON Example では、すべての項目が必須として扱われるとされています。空のときは空文字や空の配列を返させる前提で例を作ります。 スキーマを自分で書く場合、$ref は使えないとされています。

システムへ連携する

部署へは自動で送りません。 台帳に「回す」の列を置き、担当者が「回す」にした案件だけを、別のワークフローで部署のチャットへ送ります。要約が誤っていたときに、部署の判断まで一息に進むことを止めるためです。

人が確認する

人が見るのは、relevance が high と possible の案件と、needs_human が立った案件です。 none の案件は、題名と理由を流し見ます。

1. needs_human を先に見る … 資料が多い案件、PDFが読めなかった案件、詳細ページが取れなかった案件です
2. high の根拠を確かめる … 資料の該当ページを開き、quote が原文どおりかと、事業の一覧の行が合っているかを見ます
3. none の理由を流し見る … 自社の名前の出る業種や物質が題名にあるのに none のものだけ、自分で開きます
4. 部署へ回すかを決める … 回すなら、自社にとっての意味を一言添えます。この一言は担当者が書きます
5. 事業の一覧を直す … 判断が外れた案件から、手がかりの語と関わる理由を書き足します

5番目を毎週続けることが、判断の質を上げる唯一の手段です。 エージェントの指示を直すより、事業の一覧を直すほうが確実に効きます。

目標は、120件をならして1件4分です。 high の案件は15分以上かかり、none の案件は数十秒で終わります。

例外に対処する

6行目に気づくには、案件番号での重複の判定とは別の仕組みが要ります。 Remove Duplicates は新しい案件番号だけを通すので、同じ番号の締切の変更は落ちます。 台帳にある募集中の案件は、締切の催促のワークフローで詳細ページを取り直し、受付締切日時を比べます。

記録を残す

• 実行の日時、RSSの更新日時、取れた案件の数
• 新しく拾った案件（案件番号、題名、公示日、締切の原文と読み替えた値）
• エージェントの入力と、読んだ資料と読まなかった資料
• 道具の呼び出しの記録と、結果のJSONの全文、quote の照合の結果
• 担当者の判断（回したか、どの部署へ）と、部署の回答（意見を出したか）
• 締切の変更を見つけた記録

3つ目と4つ目は、判断の外れを見直すために残します。 Tools Agent の Return Intermediate Steps を有効にすると、途中の手順を出力に含められます。

5つ目は、翌年の同じ法令の案件で、回す先を決める材料になります。