UNIT 05自動化 FIG.00 · EYECATCH

トリガー設計の基本｜時刻・イベント・ポーリングを使い分ける

n8nのSchedule Trigger・Webhook・ポーリングの違いと選定基準を整理。RSS Readを二つの入口から動かす実習を通じて、時刻設定、Test URL、重複・欠落・遅延の扱い、Executionsによる確認方法を具体的に解説します。

DOC NO.EKP-05-1275

DATE2026-10-30

REVB

READ約 10 分

自動化が動かないとき、最初に確認すべきなのは処理内容より「何を合図に起動する設計なのか」である。毎朝の収集、注文発生時の登録、更新の定期確認は、見かけ上は同じデータ処理でも開始条件が異なる。開始条件を取り違えると、処理の遅れだけでなく、二重登録や取りこぼしまで発生する。

この記事では、時刻起動・イベント起動・ポーリングを設計上の契約として比較し、n8nで一つのRSS取得処理をSchedule TriggerとWebhookの二つの入口から起動する。題材は「技術ニュースのRSSを毎朝集め、新着だけを台帳に記録して通知する」仕組みの最初の工程である。今回はRSSの取得までを完成させ、重複判定や通知は後続回に分ける。

トリガーは処理の開始条件を表す

トリガーは業務データを加工するノードではなく、「いつ、何を根拠に、処理を開始してよいか」を決める境界である。前回のワークフロー自動化の設計の基本では、開始・処理・記録を責務で分けた。今回はその開始部分を具体化する。

n8nの最初のWorkflowを作る実習で扱ったManual Triggerは、人が実行を指示する入口だった。本番運用では人の操作に代わり、時計、HTTPリクエスト、外部サービスの変更などが開始条件になる。

時刻起動

Schedule Triggerは指定時刻や間隔に従って実行を開始する。毎朝8時の収集、月初の集計、一定間隔の確認に向く。重要なのは「8時」という数値だけではなく、タイムゾーン、公開済みバージョン、停止中の扱いまで含めて開始条件とすることだ。

イベント起動

Webhookは外部の送信元がHTTPリクエストを送った時点で実行を開始する。問い合わせの到着や監視装置の通知など、発生時刻を事前に決められない処理に適する。ただし送信元の再送、ネットワーク障害、認証失敗によって同じイベントが複数回届いたり届かなかったりする。

ポーリング

ポーリングは一定間隔で対象を問い合わせ、前回の状態と比較して変化を検出する方式である。Schedule TriggerでRSS Readを定期実行するだけでは「取得」であり、前回との差分を判定して初めて「新着の検出」になる。外部側にWebhook送信機能がない場合にも使えるが、確認間隔に応じた遅延とアクセス負荷がある。

三方式の選定基準

観点	時刻起動	イベント起動	ポーリング
開始の根拠	時計とカレンダー	送信元の通知	周期的な問い合わせと差分
主な遅延	予定時刻まで待つ	送信と配送の時間	確認周期と処理時間
適した仕事	日次集計、定期報告	フォーム受信、状態変化通知	RSS新着、変更監視
失敗の焦点	停止中の実行漏れ	再送、認証、配送失敗	取りこぼし、重複、取得制限
設計上の対策	時刻帯と復旧方針	イベントIDと再送制御	前回状態と一意キー

例えば「毎朝まとめて読む」が要件なら、厳密な即時性は不要なので時刻起動を採用しやすい。「故障通知をできるだけ早く受ける」が要件なら、送信元が対応している限りイベント起動が有力になる。「更新されたか確認する手段がAPIしかない」ならポーリングが現実的だ。方式を流行で選ばず、許容遅延、更新頻度、API制限、失敗時の復旧条件から決める。

遅延・重複・欠落を先に定義する

遅延は開始までの時間と処理時間に分ける

ポーリング間隔をΔtとし、更新が周期内で一様に起きると仮定すれば、検出待ちの期待値はおよそΔt/2、最大はほぼΔtとなる。ただしこれは取得が毎回成功し、更新が残り続ける単純なモデルであり、ネットワーク遅延やキュー待ちは含まない。設計では検出待ちと実行処理時間を別々に測る。

例えば確認間隔を10分とした場合、理想的な条件では検出待ちは平均約5分となる。しかしRSSが最新20件しか配信しない場合、短時間に20件を超える更新があると、次の確認までに古い項目が消える可能性がある。頻度を決める際は配信件数の上限も確認する。

重複は起こる前提で扱う

Webhookの送信元は応答が届かなければ同じイベントを再送する場合がある。時刻起動でも、手動再実行、複数トリガーの重なり、停止からの復旧によって同じRSS項目を再取得する。したがって「トリガーが一度だけ動く」ことをデータの一意性の保証にしてはいけない。記事URLやguidなどの安定したキーを使い、登録側で重複を拒否する必要がある。

欠落は監視できる形にする

n8nが停止していた間の定期実行、外部側の送信失敗、RSSの一時停止などは、単に「実行履歴がない」だけでは原因を断定できない。期待する実行時刻、実際の開始時刻、取得件数、最終成功時刻を記録し、一定期間更新がなければ異常として扱う。

n8nの現行公式資料では、Schedule Triggerに停止中の予定をどう扱うかを選ぶ設定があるが、利用できる条件はバージョンとスケジューラ方式に依存する。初期値や利用可否を決めつけず、実際の環境で確認する。

【実践】一つのRSS取得処理に二つの入口を作る

ここからはn8nの画面で操作する。実行環境は自分で管理するn8nでもn8n Cloudでもよい。題材としてNASA公式の公開RSS https://www.nasa.gov/feed/ を使用する。実際の技術ニュース収集では、対象分野に合う公式RSSへ差し替えればよい。配信元の構成変更や一時的な取得失敗はあり得る。

ワークフローを新規作成する

新しいWorkflowを作成し、名前を Tech RSS Collector - Trigger Lab とする。
Workflow settingsを開き、Timezoneを Asia/Tokyo に設定する。n8nの画面表記はバージョンで異なる。
最初の入口として Schedule Trigger を追加する。
別の入口として Webhook を追加する。
後続の処理ノード RSS Read を一つだけ置き、両方のトリガーからその入力へ接続する。

同じRSS Readへ二つの入口を接続する構成により、起動経路によってRSSのURLや取得処理が変わることを防げる。どちらの入口から開始しても、その実行でRSS Readを通る。今回の設計では、取得後に台帳へ書き込むノードはまだ接続しない。

Schedule Triggerの設定値

項目	設定値
Trigger Interval	Days
Days Between Triggers	1
Trigger at Hour	8am
Trigger at Minute	0
Workflow timezone	Asia/Tokyo

これは毎朝8時（日本時間）に取得する設定である。毎日実行させるにはWorkflowをPublishする必要がある。編集内容が保存されただけのDraftと、本番で起動するPublished版は区別する。時刻変更後も新しい版をPublishしなければ、以前の設定で動き続ける場合がある。

Webhookの設定値

項目	設定値
HTTP Method	GET
Path	tech-rss-collect
Authentication	None（ローカル試験のみ）
Respond	Immediately
Response Code	200

Webhookの設定画面にはTest URLとProduction URLがある。今回の手動試験はTest URLを使い、Listen for test event を開始してから呼び出す。公開されたProduction URLはWorkflowをPublishした後に使う。実際のURLのホスト名は自分のn8n環境に合わせ、画面に表示されたものを採用する。

AuthenticationをNoneとするのは、ローカルの閉じた試験を簡単にするためである。インターネットへ公開する場合は認証やIP制限を設定し、無認証のまま業務処理を起動できる状態にしない。

RSS Readの設定値

項目	設定値
URL	https://www.nasa.gov/feed/
Ignore SSL Issues	Off（証明書検証を無効にしない）

RSS Readは指定URLのフィードを読み、取得した記事をitemとして出力する。記事のtitle、link、pubDate、guidなどの有無や形式はフィードごとに異なる。ここでは取得できることを確認し、必須項目の検証は次回の実習で実装する。

Webhookから手動実行して確かめる

Webhookノードで Test URL を表示し、Listen for test event を選択する。
別のターミナルから、表示されたTest URLへGETリクエストを送る。
n8nの実行画面でWebhookとRSS Readの両方が実行されたことを確認する。
RSS ReadのOUTPUTを開き、item数とtitle、linkなどの実際の値を確認する。

Dockerを自分のPCで公開ポート5678として起動している例では、WindowsのPowerShellから次を実行できる。ホスト名・ポート・Pathは環境に合わせて置き換える。PowerShellのcurlエイリアスとの混同を避けるため curl.exe としている。

curl.exe -i "http://localhost:5678/webhook-test/tech-rss-collect"

HTTP 200が返れば受信自体は確認できる。ただし Respond: Immediately ではRSS取得の完了を待たずに応答するため、200だけでRSS Readの成功を判定してはいけない。n8nのExecutionsまたはエディター上のRSS Read OUTPUTまで確認する。Test URLは試験待受中だけ有効であり、待受を開始し忘れるとリクエストが失敗する。

Schedule Triggerからの実行を確かめる

毎朝8時を待たずに試験したい場合は、Schedule Triggerを一時的に短い周期へ変更し、WorkflowをPublishして実際の定期実行を観察する。例えば試験中だけ Minutes、Minutes Between Triggers: 1 とする。n8n 2.45以降のdurable schedulerでは分単位の間隔がPublish時点を基準に進む場合があるので、必ずExecutionsで実時刻を確認する。

短い周期の試験版をPublishし、ExecutionsにSchedule Trigger起点の実行が作られるまで待つ。
その実行でRSS ReadのOUTPUTに記事itemが出ていることを確認する。
確認後は必ず Days / 1 / 8am / 0 に戻し、新しい版をPublishする。
Executionsの起点と開始時刻を見比べ、Webhook起点とSchedule起点の双方が同じRSS Readを通ったことを確認する。

試験用の1分間隔を放置すると、取得先への不要なアクセスが増える。公開状態を維持する場合は本番周期へ戻したことまでが試験の完了条件となる。単にエディターのExecute Workflowで動いたことと、スケジュールに従うproduction executionが発生したことは区別する。

取得結果をどう評価するか

RSS ReadのOUTPUTに記事が複数件表示されても、それは「新着記事だけ」という意味ではない。フィードの現在の掲載件数を取得したにすぎず、次の朝も同じ記事が返ることがある。台帳に保存する前に、各itemの必須項目を検証し、一意キーを決め、すでに記録したキーを除外する工程が必要である。

今回の成功条件は、二つの入口のいずれかから同一のRSS Readを実行できること、取得したitemの構造を観察できること、起点と実行時刻を区別できることの三つだ。実行履歴と公開状態の解説も参照すると、試験と本番の違いを追いやすい。

よくある失敗と切り分け

症状	まず確認する点
8時になっても動かない	Publishedか、Asia/Tokyoか、時刻設定と版が一致するか
Webhookが404になる	Test URLの待受中か、Test/Productionを取り違えていないか
Webhookは200だが記事がない	RSS ReadのexecutionとOUTPUT、フィードの到達性
RSS Readが証明書エラー	URLと証明書を確認。安易にSSL検証を無効化しない
同じ記事が繰り返し出る	取得と新着判定は別。台帳で一意キーを比較する
試験後も頻繁に実行される	短周期の試験設定を再Publishして戻したか

複数のトリガーを一つのWorkflowへ接続すると、同時刻に二つの実行が発生する可能性がある。今回は読み取りだけなので影響は限定的だが、後続回で台帳書き込みを追加したら、同じ記事が二重登録されないようにする。再実行可能性を確保することが、開始方式を柔軟に選べる設計につながる。

次回につなげる入力契約

次回はRSS Readの出力に対し、title、link、pubDate、guidの必須条件を検証する。フィードによっては項目が欠けたり名前が異なったりするため、正常なitemだけを次の処理へ渡し、不正なitemは理由付きで隔離する。入力契約を定義することで、将来RSSの取得元を増やしても同じ処理を使い続けやすくなる。

さらに後続回では中間形式への正規化、分類、通知、Data tablesによる重複防止へ進む。Sub-workflowによる責務分離の考え方も、取得元が増えた段階で役立つ。

まとめ

トリガーは「開始できる」だけでなく、許容遅延、再送、欠落、認証、復旧を含む設計契約である。毎朝のRSS取得には時刻起動、外部からの任意の試験にはWebhook、取得結果から新着を判定する工程にはポーリングの考え方を適用する。今回は二つの入口から同じRSS Readを動かし、取得結果を観察するところまでを実装した。次の工程で検証と一意性を追加し、実運用へ近づける。