国の審議会・研究会に新しく載った資料をエージェントが毎週見回り、自社の事業に関係する論点を要約して経営企画に届ける

処理の起点を決める

毎週月曜の朝7時に、Schedule Trigger で動かします。 間隔は Weeks を選び、曜日と時刻を指定します。Schedule Trigger はワークフローのタイムゾーンが設定されていればそれに従い、無ければインスタンスのタイムゾーンを使います。セルフホストの既定は America/New York なので、ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動かない点も、最初に確かめます。

週1回にしているのは、審議会の資料が会議の当日か前後に載るからです。 毎日見回っても、多くの会議は何も変わりません。月曜の朝に前の週の分をまとめて届ければ、事業部の週の会議に間に合います。 急ぎで追う会議（意見募集が始まりそうな会議など）は、一覧に「毎日」の印を付け、別の Schedule Trigger で平日の朝に見回ります。

入力データを集める

質を決めるのは、社内の論点の一覧です。 「電池」とだけ書くと、電池に触れた資料がすべて関係ありになります。「使用済みのリチウムイオン電池の回収の仕組みと、製造者の役割」のように、追っている理由まで書きます。 エージェントは、この説明を読んで資料を選び、関係の有無を判断します。

過去に届けた記録は、同じ論点を何度も届けないために持ちます。 同じ報告書の案が回をまたいで少しずつ直されるので、前回との違いを書けないと、事業部は毎回同じ要約を読みます。

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

会議のページは HTTP Request ノードで取ります。 約30のページを一度に取りにいかず、Batching で Items per Batch を1、Batch Interval を数秒にして、間隔をあけて順に取ります。 府省のページに負荷をかけないための設定です。Response は Text にして、ページのHTMLをそのまま受け取ります。

リンクの取り出しは HTML ノードの Extract HTML Content で行います。 CSS Selector で本文の領域のリンクを指定し、Return Value を Attribute にして href を、Text にしてリンクの文字を取ります。Return Array を有効にして、ページ内のリンクを配列で受け取ります。 本文の領域を指定しないと、ページの上下にあるサイト全体のメニューのリンクまで拾います。

新しいリンクの検出は、Remove Duplicates ノードの「Remove Items Processed in Previous Executions」で行います。 Keep Items Where を Value Is New にし、Value to Dedupe On にそろえたURLを入れます。前回までの実行で見たURLが落ち、新しく増えたリンクだけが残ります。 履歴は既定で10,000件まで持つとされているので、30の会議の数年分のリンクなら足ります。

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

AIへ渡す前に整形する

1. URLの書き方をそろえる … 相対パスを https://www.env.go.jp のような府省の起点と結んで絶対パスにし、末尾の / や index.html の有無をそろえます
2. メニューのリンクを落とす … 本文の領域の外のリンク、ページ内の移動のリンク、PDFの閲覧ソフトの案内のリンクを除きます
3. リンクの種類を分ける … リンクの文字とその前後から「議事次第・配布資料」「議事録」「議事要旨」「委員名簿」に分けます。規則で分からないものは「その他」にします
4. 回を特定する … リンクの前にある開催日と「（第66回）」のような回の番号を取り、リンクに付けます
5. 第一部・第二部をまとめる … 1つの回が部に分かれているときは、同じ回の資料として束ねます
6. 資料一覧を取る … 配付資料のページから、資料番号（資料1、参考資料6－1 など）、題名、PDFのURLを表にします
7. 会議の一覧と結ぶ … どの会議の、どの論点を追っている回かを、エージェントに渡す入力に付けます

1番目を省くと、運用の初週で破綻します。 同じページの中で相対と絶対が混ざっているため、ページの書き方が少し変わっただけで、過去の全リンクが新しいものとして拾われます。 そろえたURLで比べることが、見回りの土台です。

AIに処理させる

させるのは、回ごとに「どの資料を読むか」を選び、選んだ資料から社内の論点に関係する箇所を探し、根拠を付けて要約することです。

手順1で「読まない」と決めた資料も、理由とともに残させます。 「参考資料13 フォーラムの開催について：開催案内のため読まない」のように書かせると、担当者は一覧を見るだけで、読まなかった資料の判断を確かめられます。 第3章の（b）の見落としを、人の目で拾い直せる形にします。

読む資料の数には上限を置きます。 Tools Agent の Max Iterations は既定で10とされています。1回の会議で読むPDFは最大5本とし、それを超えて読む必要があると判断したら、needs_human を立てて止めさせます。 資料が多い回を全部読ませるより、人が残りを見るほうが早く終わります。

1行目がいちばん起きやすい失敗です。 報告書の案に「〜とする」と書かれていると、要約は「〜とすることになった」と書きます。資料の区分と、案か報告かの区分を、要約とは別の項目として返させます。

指示内容を固定する

あなたは製造業の経営企画部で、国の審議会・研究会の資料を読み、
自社が追っている論点に関係する箇所を探す担当です。
道具を使って資料を読み、読んだ資料に書かれていることだけで答えてください。

【入力】
- 会議名・回・開催日・議題：{meeting}
- 資料一覧（資料番号・題名・URL）：{documents}
- この会議で追っている論点：{watched_topics}

【使える道具】
- read_document：資料のURLを渡すと、ページ番号付きの本文を返す
- get_topic：論点の名前を渡すと、説明と手がかりの語を返す
- get_past_reports：会議名と論点を渡すと、過去に届けた要約を返す

【進め方】
1. 議題と資料の題名を見て、論点に関係しそうな順に並べてください。
   読まないと決めた資料は、理由を1行で残してください。
2. 関係しそうな資料から read_document で読んでください。
   1回の会議で読むのは最大5本です。それを超えて読む必要があると
   判断したら、読むのをやめ、needs_human を true にしてください。
3. 関係する箇所が見つかったら、資料番号、ページ、原文の抜き書き
   （そのまま写す。言い換えない）を残してください。
4. 同じ論点を前に届けていれば get_past_reports で確かめ、
   前回と何が変わったかを書いてください。分からなければ「不明」。

【厳守事項】
- 「決定した」「方針が固まった」「〜することになった」と書かないでください。
  資料が案なら「案として示された」、意見なら「委員から意見があった」と
  書いてください。区分は stage に入れてください。
- 資料に書かれていない見通し・時期・影響の大きさを書かないでください。
- 委員の氏名を書かないでください。
- 読んでいない資料の中身を、題名から推測して書かないでください。
- 関係する箇所が無ければ、無理に関係を作らず relevance を none に
  してください。
- 本文が取り出せなかった資料は、読めなかったとして記録してください。

「区分は stage に入れる」を本文の書き方の指示とは別に書いているのは、二重に縛るためです。 書き方だけを縛ると、要約は「案として示された」と書いても、事業部への一言で「決まった」と書くことがあります。区分を項目として持たせれば、担当者は stage を見るだけで書きぶりのずれに気づけます。

「最大5本」は、人に戻す合図でもあります。 5本を超えて読みたくなる回こそ、担当者が自分で資料を開くべき回です。

出力形式を固定する

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

{
  "meeting": "中央環境審議会 循環型社会部会",
  "session": "第66回",
  "held_on": "2026-07-28",
  "documents_read": [
    { "doc_no": "資料1", "title": "", "url": "", "read_status": "read | unreadable" }
  ],
  "documents_skipped": [
    { "doc_no": "参考資料13", "reason": "" }
  ],
  "findings": [
    {
      "topic": "",
      "relevance": "high | medium | none",
      "doc_no": "", "page": 0,
      "quote": "",
      "stage": "draft | report | member_opinion | secretariat_summary",
      "summary": "",
      "change_from_last": ""
    }
  ],
  "needs_human": false,
  "needs_human_reason": ""
}

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

2つ目は、stage を要約と別に持てることです。 第3章の（d）の書きぶりのばらつきは、ここで止まります。事業部への通知の文面も、stage から規則で前置きを付けます（「案として示された論点です」など）。

3つ目は、documents_skipped で読まなかった判断が残ることです。 選び方が合っているかは、読まなかった資料の一覧を人が見て初めて分かります。

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

システムへ連携する

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

人が確認する

人が見るのは、relevance が high と medium のものと、needs_human が立った回です。 none だけの回は、会議名と読んだ資料の一覧を流し見て終わりにします。

1. needs_human の回を先に見る … 5本を超えて読む必要があった回、PDFが読めなかった回、ページが取れなかった会議です
2. high の根拠を確かめる … 資料番号とページを開き、quote が原文どおりかと、stage が合っているかを見ます
3. 読まなかった資料を流し見る … documents_skipped の理由が題名と合っているかを見ます。怪しいものだけ自分で開きます
4. 事業部へ届けるかを決める … 届けるなら、自社にとっての意味を一言添えます。この一言は担当者が書きます
5. 要約を直したら記録する … どの項目を、どう直したかを残します

4番目の一言を、エージェントに書かせないでください。 資料から言えるのは「何が議題に上がったか」までです。

目標は、40件をならして1件12分です。 high の回は資料を開いて10分以上かかり、none だけの回は1〜2分で終わります。

例外に対処する

1行目は、見回りを自動にするうえで最初に確かめるべきことです。 府省のページの中には、ブラウザでは開けても、自動のアクセスには本文の無い応答と確認の画面を返すものがあります（本記事の確認の際にも、1つの府省のページでこの応答が返りました）。取れない会議を黙って飛ばすと、そこだけ見回りが止まったことに誰も気づきません。 HTTP Request の Include Response Headers and Status を有効にして状態と本文の長さを見て、取れなかった会議は毎回の通知に名前を出します。

記録を残す

• 実行の日時、見回った会議ごとの取得の結果（状態、本文の長さ、取り出したリンクの数）
• 新しく拾ったリンク（そろえたURL、リンクの文字、種類、回）
• エージェントの入力（議題、資料一覧、追っている論点）と、読んだ資料と読まなかった資料と理由
• 道具の呼び出しの記録（どの資料を何番目に読んだか）
• 結果のJSONの全文と、quote が原文にあったかの確認の結果
• 担当者が直した記録と、事業部へ届けたかどうか

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