競合企業のプレスリリースとIRのお知らせをエージェントが毎日見回り、新製品・提携・設備投資・価格改定の動きを要約して、自社への影響の候補を経営企画に届ける

処理の起点を決める

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

1日1回にしているのは、翌朝に読めば足りるからです。 1日に何度も取りに行くと、相手のサイトへの負荷が増えるだけです。

決算発表の日だけは、例外にします。 競合の決算発表の日は競合の一覧に入れておき、その日だけ18時にもう一度動かす Trigger Rule を足します。公式のページでは、複数の Trigger Rule で別々の時刻に動かせるとされています。決算の数字の要約は UC-0743 の構成に任せ、本記事では決算と同時に出る提携や設備投資の発表を拾います。

入力データを集める

質を決めるのは、自社の事業の一覧です。 「工作機械事業」とだけ書くと、競合のどの発表も「工作機械事業に関わる」になります。「5軸加工機：航空機部品・医療機器部品向け、主要顧客は航空機の Tier2」のように、製品群・用途・顧客の業界まで書きます。 ここまで書くと、競合が「医療機器メーカーと提携」と発表したときに、関わる製品群を1つに絞れます。

主要顧客は、社名ではなく業界で書きます。 一覧はエージェントに渡すので、個別の顧客名を入れません。 業界で書いても、候補を付けるには足ります。

過去の記録は、続報を見分けるために持ちます。 同じ会社の同じ工場の話なら、今回は新しい動きではなく続報です。

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

取りに行く前に、会社ごとに取得してよいかを確かめます。 robots.txt は、RFC 9309 でサイトの最上位の /robots.txt に置くと定められた、クローラーへの依頼の書き方です。競合の一覧の「取得の可否」の列は、robots.txt と各社のサイトの利用条件を人が読んで埋めます。 断っているページは、ワークフローで取らずに人が見る対象に分けます。

RFC 9309 には、運用で効く決まりが3つあります。

RFC 9309 は、これらの決まりがアクセスの許可ではないとも書いています。 robots.txt が許していても、利用条件が断っていれば取りません。

一覧の取得は、会社ごとに次のように分けます。

3行目は、試してみるまで分かりません。 HTML ノードで空の配列が返る会社は、ページの中身がスクリプトで後から描かれています。この構成ではブラウザを動かす取得はしません。 RSS を探し直すか、人が見る対象に分けます。

HTTP Request には、Batching を設定します。 Items per Batch を1、Batch Interval を数秒にして、1社ずつ間をあけて取ります。 Timeout も設定し、応答の遅いサイトで全体が止まらないようにします。Include Response Headers and Status を有効にして、ステータスコードを例外処理で使います。

AIへ渡す前に整形する

1. 新しいリリースだけを残す … Remove Duplicates の Remove Items Processed in Previous Executions で、Keep Items Where を Value Is New、Value to Dedupe On をリリースのURLにします。履歴として持つ件数の既定は10,000件で、15社で月120本なら数年分を持てます
2. URLをそろえる … 末尾のスラッシュ、?utm_ などの追跡用のパラメータを落としてから重複を見ます。そろえないと、同じリリースが別のURLとして2回流れます
3. 本文を取り出す … HTMLは HTML ノードで本文の部分のCSSセレクタを指定して Text で取り、Clean Up Text で余分な空白と改行を落とします。PDFは HTTP Request で Response Format を File にして取り、Extract From File の Extract From PDF にかけます
4. 長さで分ける … 本文が数ページを超える統合報告書や中期経営計画の資料は、エージェントに渡さず「長文」として人に回します
5. 会社名と日付を付ける … 競合の一覧の会社名と、RSS や一覧ページの公表日を付けます。公表日はエージェントに読ませず、取得した値を使います

1番目の Scope は Node のままにし、RSS と一覧ページの2つの経路を1つの Remove Duplicates に合流させてから通します。 URLが同じなら同じリリースだからです。

4番目で長い資料を外すのは、費用と見落としのためです。 100ページの資料をそのまま渡すと費用がかかるうえに、エージェントが冒頭の要旨だけで種類を決めがちです。 長い資料は人が目次を見て、関わりのある章だけを読みます。

AIに処理させる

させるのは、リリースごとに、種類を分け、事実を抜き書きし、自社の事業の一覧と過去の記録を引いて影響の候補を付けることです。

種類の区分は、経営企画で決めた次の8つです。 新製品・新サービス／提携・出資・買収／設備投資・増産・新拠点／価格改定／撤退・縮小・生産終了／受注・採用事例／組織・人事／その他。区分を決めておくと、月ごとに「提携が何件」と数えられ、第3章の（c）のばらつきが消えます。

道具は、Call n8n Workflow Tool でサブワークフローとして持たせます。 公式のページでは、道具の Description がいつ呼ぶかをエージェントに伝え、本番ではサブワークフローを公開しておかないと「Workflow is not active and cannot be executed」が返るとされています。エージェントはこの応答を返事の中に埋めてしまうことがあるので、道具の実行の一覧に記録が残っているかを確かめます。

4行目がいちばん起きやすい失敗です。 「新工場を建設」とだけあるリリースで、エージェントは「生産能力が約2倍になる見込み」と書きたがります。書いていない数字は、経営会議の資料に載った瞬間に事実として扱われます。

指示内容を固定する

あなたは産業機械メーカーの経営企画部で、競合のリリースを読み、
自社への関わりの候補を整理する担当です。
入力のリリース本文と、道具で確かめた事実だけで答えてください。

【入力】
- 会社名：{company}
- 公表日：{published_at}（取得した値。本文から読み直さないこと）
- 題名：{title}
- URL：{url}
- 本文：{body}

【使える道具】
- get_history：会社名を渡すと、その会社の過去の発表の種類・要点・
  日付・URLを返す
- get_business_map：自社の事業部・製品群・用途・顧客の業界・
  主要な仕入品の一覧を返す

【進め方】
1. 種類を次から1つ選んでください。
   new_product / alliance / capex / price_change / withdrawal /
   order_case / organization / other
2. 何を、いつ、どれだけ、を本文から原文のまま抜き書きしてください。
   本文に無い項目は空にしてください。
3. get_history で過去の発表を確かめ、続報なら元の発表のURLを
   follow_up_of に入れてください。
4. get_business_map で自社の事業を確かめ、関わりそうな製品群を
   一覧の名称のまま選んでください。無ければ空にしてください。
5. 関わり方の候補を1〜2文で書いてください。

【厳守事項】
- 本文に書かれていない数字（能力、金額、時期、シェア）を
  補ったり推し量ったりしないでください。
- 競合の狙いや戦略を断定しないでください。「〜を狙っている」と
  書かず、「〜と発表した」と書いてください。
- 自社にとって脅威か機会かを書かないでください。
- 影響額を見積もらないでください。
- 製品群は get_business_map の名称だけを使ってください。
- 抜き書きは本文の文字をそのまま写してください。言い換えないでください。
- 判断がつかないときは needs_human を true にし、理由を書いてください。

「本文に無い数字を補わない」を明記しないと、増産の規模や投資額を推し量って書きます。 経営企画の資料で、最も困る誤りです。

「狙いを断定しない」も明記します。 エージェントは「価格攻勢に出た」「シェア拡大を狙う」と書きたがります。それは人が書く見立てで、記録の表では発表の事実と分けて残します。

出力形式を固定する

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

{
  "company": "",
  "url": "",
  "published_at": "2026-10-09",
  "category": "new_product | alliance | capex | price_change | withdrawal | order_case | organization | other",
  "facts": {
    "what": "",
    "when": "",
    "how_much": ""
  },
  "quotes": [""],
  "follow_up_of": "",
  "related_products": [""],
  "impact_candidate": "",
  "priority": "high | normal | low",
  "needs_human": false,
  "reason": ""
}

1つ目の理由は、facts と impact_candidate を別の欄に置けることです。 記録の表でも別の列に書き、経営会議の資料に写すときに、発表の事実とエージェントの候補を取り違えません。

2つ目は、quotes をワークフローの側で照合できることです。 抜き書きが本文の中にそのまま含まれるかを Code ノードで確かめ、含まれないものは needs_human を立てます。 言い換えた抜き書きは、数字や条件が変わっていることがあるからです。

3つ目は、priority を規則で付け直せることです。 エージェントには基準を渡して付けさせますが、ワークフローの側で「related_products が空でなく、category が capex・price_change・alliance なら high」と決め直します。重要度の決め方が変わっても、直すのは規則だけです。

Structured Output Parser の Generate From JSON Example では、すべての項目が必須として扱われるとされています。本文に無い項目は空文字や空の配列を返させます。 公式のページは、JSON Schema の $ref には対応していないとしています。

システムへ連携する

事業部へは自動で送りません。 日次の一覧は経営企画のチャットだけに送り、担当者が選んで事業部に伝えます。候補が的外れなまま事業部に届くと、次から読まれなくなるからです。

日次の一覧は、priority の順に並べます。 high は題名・抜き書き・候補を、normal は題名と候補を、low は題名だけを載せます。15社の全部を同じ重さで並べると、毎朝の一覧が長くなり、読み飛ばされます。

人が確認する

人が見るのは、priority が high のものと、needs_human が立ったものです。 normal と low は一覧で題名と候補を流し読みします。

1. 原文を開く … high のものは、URLから原文を開いて抜き書きが原文どおりかを確かめます
2. 候補を確かめる … 関わる製品群の選び方が的外れでないかを見ます
3. 判断の一言を書く … 事業部に伝えるかと、その理由を記録の表に書きます。この一言は担当者が書きます
4. 直したら記録する … 種類、製品群、重要度のどれを、どう直したかを残します

4番目は、自社の事業の一覧を直す材料になります。 同じ製品群を何度も付け外ししているなら、一覧の用途や顧客の書き方が足りていません。

目標は、120件をならして1件4分です。 high のものは原文を読んで10分前後、low のものは数秒です。競合の決算発表が重なる月は、4分を超えます。

例外に対処する

2行目と3行目は、この構成が止まる典型です。 会社ごとの取得件数を毎日記録し、3営業日続けて0の会社を担当者に知らせます。

記録を残す

• 実行の日時、会社ごとの取得の経路（RSS／一覧ページ）、robots.txt の取得結果、取れた件数
• リリースごとの、題名、URL、公表日、取得した本文
• エージェントの入力、道具の呼び出しの記録、結果のJSONの全文
• 抜き書きの照合の結果
• 担当者が直した種類・製品群・重要度と、判断の一言
• 事業部に伝えた日と、伝えた先

本文を残すのは、各社のサイトからリリースが消えることがあるからです。 後から「半年前の発表」をたどるときに、元のページが無くなっていても記録で読めます。Tools Agent の Return Intermediate Steps を有効にすると、どの道具を何の順で使ったかも残ります。