n8nで毎日のトレンドレポート：2.45のスケジューラーを検証

セルフホストのn8nワークフローなら、EveryInfraを使って毎日のトレンドレポートを1回あたり$0.002224で作れます。難しいのはAPI呼び出しではありません。1つ目は、n8nが停止している間に予定時刻を迎える実行です。2つ目は、二重に課金されたように見える再実行です。3つ目は、1件の呼び出しの失敗でレポート全体が止まりうることです。

2026年10月26日、シンガポール時間（SGT、UTC+8）の10:36〜11:25（UTC 02:36〜03:25）に、Mac上でn8n 2.45.3を3分ごとに実行しました。意図的に2回停止させ、その後14件のレポートをデータベース、メトリクス、自社のサーバーログと照合しました。

この記事でいう「毎日のトレンドレポート」は、自分のマシン上で動かすn8nワークフローです。Schedule Triggerノードがワークフローを起動します。Codeノードで読み込むトレンドリストを指定します。HTTP RequestノードがAPIキー1つでEveryInfraを呼び出します。2つ目のCodeノードが、各リストの上位10件、前回の実行との重複、費用をMarkdownファイルに書き出します。

このレポートでわかるのは、今朝話題になっていることです。何がトレンドになるかを予測するものではなく、トピックが事実かどうかを確認するものでもありません。

このイラストは、永続スケジューラーの考え方を示しています。実行はプロセス内のタイマーではなく、予定時刻より前に書き込まれるデータベースの行です。時刻になると、1つのn8nプロセスがその行を確保して実行します。n8nのドキュメントでは、これをマテリアライズ、実行、リカバリー、保持、オーナー調整の5つの段階に分けています。以下の各テストでは、これらの段階についてSQLite上の実際の行を読み取っています。

レポート1件の中身

これはSGT 10:39:24の実行のレポートです。元のファイルはステップ5の初版で生成したもので、初版ではWeiboのプロモーション枠1件にも順位を振っていました。そこで、その実行の生のレスポンスから、修正後のステップ5（rankで並べ替え、rankのない行はスキップ）で再生成しました。短くするため、リストの行を一部省略しています。

# EveryInfra daily report 2026-10-26T10:39:24.294+08:00

## X US trends (52 items, $0.000556)
1. Lula
2. Brazil
3. Mahomes
4. Chiefs

## X Mexico trends (71 items, $0.000556)
1. Lula
2. Pachuca
3. #EleccionesBrasil2026

## Weibo hot search (10 items, 2 promoted slots skipped, $0.000556)
4. Brazil's President Lula wins re-election

## Deliberately misspelled list name: failed (HTTP 422, invalid_value)
- `boards` must be one of: challenge, entertainment, hotspot, seeding, social (got 'hot')

## Cost of this run
- Sum of charged_usd in the responses: $0.002224
- Actual charge after removing replays: $0.002224

見出しが中国語なのは、私たちのチームがワークフローを中国語で作成したためです。ラベルはCodeノード内の自由記述テキストなので、1行変更するだけで英語にできます。このファイルで特に注目したい点が2つあります。

第1に、1つの出来事が同時に4つのランキングの上位を占めました。ブラジルでは10月25日に大統領選挙の決選投票が行われました（ブラジル高等選挙裁判所の告知）。翌日の10:39 SGT（ニューヨークでは10月25日22:39）には、「Lula」が米国とメキシコのXトレンドで1位でした。同じニュースは、中国のWeiboホット検索で4位、Douyinホットスポットランキングで5位でした。Weiboの順位には補足が必要です。Weiboのレスポンスの4件目はrankフィールドのないブランドキャンペーンで、プロモーション枠でした（Weiboホット検索ルールでは、ラベルの種類の1つとして商業広告が挙げられています）。Lulaの件はrankが4でした。最初のレポートノードは位置で番号を振っていたため、Lulaを5位とし、広告をホットトピックとして掲載していました。現在のステップ5ではrankで並べ替え、rankが空の件を除外し、除外した件数を見出しに表示します。プラットフォームをまたいだレポートなら、こうした重なりがひと目でわかります。米国のランキングでは同時にスポーツも話題になっており、「Mahomes」「Chiefs」「Packers」が米国トップ10の残りを占めています。

2つ目は、呼び出しが失敗してもレポートは失敗しなかったことです。レポートでは、失敗した呼び出しが理由と候補値を添えた短い注記として表示されます。コストのセクションには、この失敗には費用がかからなかったことが記載されています。最初のエラーが起きた後ではなく、起きる前にこれを設計すべき理由は、テスト4で説明します。

最初の実行前に決めた合格ライン

最初の実行前に、チェックファイルに合格ラインを10項目書き込みました。結果を見た後も変更していません。ただし例外が1つあります。課金はアカウント残高で確認する予定でしたが、SGT 10:33に、同じテストキーをほかの執筆者も使っており、残高が彼らの呼び出しでも変動することがわかりました。そこで、課金される呼び出しを行う前に確認方法を変更し、サーバーの呼び出しログで各request_idを照合することにしました。

スケジュールジョブで最も厄介な問題は、エラーとして表に出ません。実行漏れや重複実行、課金額が少しだけ高いといった問題です。そのため、チェックでは件数、行、コストを事前に明記しています。あるn8nユーザーは、アイテムを0件受け取ったノードについて書いています。後続のノードは実行されないのに、実行結果は「Success」と表示され、エラーワークフローも起動しません（Redditのr/n8nスレッド）。こうした問題は、期待する件数、行、コストを先に書き出しておかなければ見つけられません。

始める前に：バージョン、インストール方法、Node.js

バージョン。 永続スケジューラーは、2026年10月20日にリリースされたn8n 2.45.0からデフォルトで有効です。変更履歴には、Schedule Triggerノードが「デフォルトで永続スケジューラー上で実行されるようになった」と書かれています。しかし10月26日時点で、npmレジストリのlatestタグが指していたのはまだ2.44.6（10月22日）でした。2.45.3（10月23日）にはnextとbetaのタグが付いていました。そのため、現在単純にnpm install n8nを実行すると2.44.6がインストールされ、永続スケジューラーはデフォルトで無効のままです。このテストを再現するには、バージョンを指定する必要があります。

また、n8nは2つのリリースラインに別々にパッチを適用しています。10月14日のセキュリティアップデートには「betaはv2.44.1で修正」「stableはv2.43.5で修正」と記載されています。

10月13日から23日にかけて、2.44系と2.45系の2つのラインから合わせて7つのバージョン（2.44.0〜2.45.3）がnpmに公開され、交互にパッチがリリースされました。オンラインのチュートリアルに従って「最新バージョン」をインストールすると、どちらのラインが入るかわかりません。

インストール方法。 このMacにはNode.jsがあり、Dockerがないため、npmを使いました。考慮すべき点が2つあります。1つ目は、npmインストールのページに「n8n 3.0からnpmベースのインストールは非推奨」と書かれていることです。3.0の破壊的変更のページによると、3.0ではDockerが必要になり、npmでは実行可能なn8nパッケージが提供されなくなります。GitHub上のn8n開発者ガイドでは、v3は2026年10月頃とされています。今回使用したn8nでも、起動時に「Running n8n outside a container is deprecated」という警告が表示されました。

つまり、npmはノートPCでのテストには向いています。何か月も毎日実行するレポートには、Docker Composeまたは1行セットアップを使ってください。

2つ目はサイズです。クリーンインストールでは6分で2,328個のパッケージが追加され、node_modulesは4.4GBになりました。最初のインストールは途中で止まりました。インストールが中途半端に終わったフォルダでは、起動時にCannot find module 'kuler'というエラーが出ました。同じフォルダでnpm installをもう一度実行しても直りませんでした。

node_modulesとpackage-lock.jsonを削除して再インストールすると、n8nは起動しました。インストールが途中で止まった場合は、空のフォルダからやり直してください。これが最も早い解決策です。

Node.jsのバージョン。 ドキュメントとパッケージの記述が一致していません。npmインストールのページには「20.19から24.xまで」とありますが、パッケージ自体（npm view n8n@'2.45.3' engines）は>=24.0.0を要求しています。Node.jsのリリース表によると、20は2026年3月にサポートが終了し、24はLTS、26は「Current」です。今回は26.11.1を使い、このテストでは問題はありませんでした。ただし、ドキュメントに記載された範囲外なので、長期間実行するレポートにはNode.js 24 LTSを使ってください。

もう1つ落とし穴があります。ポートです。最初はn8nをポート5679に設定しました。するとn8nはすぐに停止し、ログに「n8n Task Broker's port 5679 is already in use」という1行が出力されました。n8n 2.xでは、Codeノードは組み込みのタスクランナーで実行され、そのブローカーがデフォルトでポート5679を使います。そこでN8N_PORTを5690に変更し、N8N_RUNNERS_BROKER_PORTを5691に設定しました。

これでn8nが起動しました。使用した設定は以下のとおりです。

export N8N_USER_FOLDER=$HOME/Downloads/n8n-lf25/home      # database and encryption key live here
export N8N_PORT=5690 N8N_LISTEN_ADDRESS=127.0.0.1          # listen on this machine only
export N8N_RUNNERS_BROKER_PORT=5691                        # keep away from the broker default 5679
export GENERIC_TIMEZONE=Asia/Singapore TZ=Asia/Singapore   # the default is America/New_York
export N8N_RESTRICT_FILE_ACCESS_TO=$HOME/Downloads/n8n-lf25/reports
export N8N_DIAGNOSTICS_ENABLED=false N8N_VERSION_NOTIFICATIONS_ENABLED=false
export N8N_METRICS=true N8N_METRICS_INCLUDE_SCHEDULER_METRICS=true
npm install n8n@2.45.3 --no-audit --no-fund

同じ設定を、それぞれの理由とあわせて表にまとめました。

リッスンアドレスを127.0.0.1にして、このマシンからのみn8nにアクセスできるようにしています。インターネットスキャン企業のCensysは、10月14日の年次レポートで、公開インターネット上に113,926台のn8nホストがあると集計しました。バージョンを読み取れたホストのうち76%に、最近の重大な脆弱性が少なくとも1件ありました（Censysのブログ）。また、n8nは2週間ごとにセキュリティアップデートを公開しています（例：10月1日のアップデート）。別のマシンからレポートを読むには、reports/フォルダを同期してください。n8nのエディターをインターネットに公開しないでください。

タイムゾーンの行は省略しないでください。タイムゾーンのページによると、セルフホストのインスタンスはデフォルトでAmerica/New_Yorkを使います。Schedule Triggerはこのタイムゾーンを基に、どの「午前8時」を指すかを判断します。ニューヨークの読者にとっては、このデフォルトはたまたま正しいだけです。それ以外の地域では、午前8時の

レポートが間違った時刻に実行されます。タイムゾーンは各ワークフローの設定でも指定できます。私たちは両方にAsia/Singaporeを設定しました。

ファイル設定の行も重要です。n8n 2.0以降、Read/Write Filesノードはデフォルトで~/.n8n-filesしか使えません。それ以外の場所にレポートを書き込むには、N8N_RESTRICT_FILE_ACCESS_TOでそのフォルダを許可する必要があります。許可するのはそのフォルダ1つだけにしてください。

米国の読者へ：11月1日に備える

米国時間でレポートを実行している場合は、ある日付に注意してください。NISTによると、2026年は11月1日の現地時間午前2時に夏時間が終了し、午前1時台が2回あります。毎日午前8時（

America/New_York）に実行するレポートは問題ありません。切り替え時刻から離れており、永続スケジューラーが現地の時計上の時刻を維持するためです。午前1時30分に実行するジョブは事情が異なります。11月1日にはその時刻が2回あるからです。

主な米国のタイムゾーンについて、NISTのルールに基づく11月1日の変更を次の表にまとめました。

永続スケジューラーのドキュメントには、毎時・毎日・毎週・毎月のスケジュールは「日常的な使用では」従来どおり実行されると書かれています。また、永続スケジューラーはインメモリスケジューラーよりも夏時間の切り替え、うるう年、第53週を正確に処理できるとも書かれています。インメモリスケジューラーでは「1周期ずれる可能性がある」とのことです。実際の時刻切り替えは来週まで起きないため、私たちはテストしていません。アドバイスはシンプルです。日次レポートを現地時間の午前1時

から午前3時の間に設定しないでください。ワークフローのタイムゾーンには固定オフセットではなく、America/Chicagoのような有効なIANAタイムゾーン名を設定してください。これらの名前とそのルールはIANAタイムゾーンデータベースで管理されています。

ワークフローの構築：6つのノード、1ステップに1アクション

ワークフローは6つのノードで構成されています。このアニメーションでは1回の実行を追います。

このワークフローはエディターでクリックして組み立てたものではありません。JSONで記述し、n8nのコマンドラインでインポートしました。これには2つの利点があります。すべての手順を正確に再現できます。また、ローカルのn8nにオーナーアカウントが不要です。各ステップについて、操作内容、表示されるはずの結果、その理由を示します。

1. APIキーをn8nの認証情報として保存します。 jq -n --arg t "$EVERYINFRA_API_KEY" '[{"id":"eiBearer000001","name":"EveryInfra API Key","type":"httpBearerAuth","data":{"token":$t}}]' | n8n import:credentials --input=/dev/stdinを実行します。「Successfully imported 1 credential」と表示されれば成功です。

ポイントは--input=/dev/stdinです。キーは環境変数とパイプだけを経由し、ファイルには一切書き込まれません。dataフィールドが平文の場合、インポートコマンドは行を書き込む前にインスタンスキーで暗号化します（ソースコードではcipher.encryptV2）。HTTP Requestノードのヘッダーフィールドにキーを直接入力しないでください。

入力すると、ワークフローのJSON、すべてのエクスポート、バージョン履歴に平文で残ります。HTTP Requestの認証情報ページには、Bearer、Headerなどの種類が記載されています。Bearerを使ってください。RFC 6750のAuthorization: Bearerヘッダーを送信します。これはEveryInfraが想定している形式です。

1. Schedule Triggerを追加します。 テストでは「3分ごと」に設定します。日次運用では「Days」、午前8時、0分に設定します。公開すると、SQLiteテーブルscheduled_jobに、intervalSecondsが180、misfirePolicyがskip、misfireGraceSecondsが60の行が新たに追加されます。

Schedule Triggerのページには、ノードの新しい設定が2つあります。「If Execution Is Missed」には3つの選択肢があり、デフォルトはスキップです。「Missed Execution Grace Period (Seconds)」は、0のままにするとインスタンスの値N8N_SCHEDULER_MISFIRE_GRACE（デフォルトは60秒）を使います。どちらの設定も、2.36以降で追加したノードにのみ、かつ永続スケジューラーが有効な場合にのみ適用されます。保存される値はノードのソースを読んで確認しました。coalesce_ownerは「Run the Most Recent Missed Execution」、coalesceはそれをルールごとに行うもので、skipがデフォルトです。

1. Codeノードでリクエストを一覧にし、リクエストごとにキーを1つ付けます。 このノードは5件のアイテムを返します。各アイテムには、プラットフォーム、アクション、パラメータ、idemフィールドが含まれます。実行データに5件の出力アイテムが表示されます。

const now = DateTime.now().setZone('Asia/Singapore');
// Daily use: one key per day (a rerun on the same day is a replay). Test: one key per minute.
const KEY_BY = 'day';
const keyBase = KEY_BY === 'day' ? now.toFormat('yyyyLLdd') : now.toFormat('yyyyLLdd-HHmm');
const reqs = [
  { label: 'Weibo hot search', platform: 'weibo', action: 'trending', params: {} },
  { label: 'Douyin hot list', platform: 'douyin', action: 'trending', params: { boards: 'hotspot' } },
  { label: 'X US trends', platform: 'twitter', action: 'trending', params: { country: 'us' } },
  { label: 'X Mexico trends', platform: 'twitter', action: 'trending', params: { country: 'mx' } },
  { label: 'Misspelled list name', platform: 'douyin', action: 'trending', params: { boards: 'hot' } },
];
return reqs.map(r => ({ json: { ...r,
  idem: `daily-report-${keyBase}-${r.platform}-${r.params.country || r.params.boards || 'default'}`,
  firedAt: now.toISO() } }));

以下は実際に実行したコードです。ラベルが中国語なのは、私たちのチームが中国語でレポートを読むためです。ラベルの文字列は自由に変更できます。

なぜ独自にキーを作るのでしょうか。日次レポートは、同じ日に2回実行されたり、2回課金されたり、異なるファイルが2つ生成されたりしてはいけません。EveryInfraのOpenAPI定義によると、24時間以内に同じIdempotency-Key、プラットフォーム、アクション、パラメータで同期呼び出しを行うと「最初に成功したレスポンスをリプレイする」とされています。呼び出しは再実行されず、再課金もされません。同じキーで異なるパラメータを送ると409 idempotency_conflictが返ります。

日付から作ったキーは、APIに「今日のリストは1部だけ」と伝えます。このパターンはIETFのIdempotency-Keyヘッダーのドラフトに沿っています。このドラフトは2026年10月22日にバージョン08になりました。テストではKEY_BYをminuteに設定しました。1日1キーにすると、3分ごとのテスト実行は初回以降すべてリプレイになり、リストの変化を確認できないためです。

1. HTTP RequestノードでEveryInfraを呼び出します。 メソッドはPOST、URLはhttps://api.everyinfra.com/api/v1/socialを使います。ステップ1のBearer認証情報を選択します。ヘッダーIdempotency-Key: {{ $json.idem }}を追加します。JSONボディとして{{ JSON.stringify({ platform: $json.platform, action: $json.action, params: $json.params }) }}を送信します。「Include Response Headers and Status」と「Never Error」をオンにします。バッチ処理は1バッチあたり1アイテム、バッチ間隔1,500 msに設定します。1回の実行で5件のアイテムが表示されます。4件はstatusCodeが200、1件は422です。

このステップで最も重要なスイッチは「Never Error」です。HTTP Requestのページによると、デフォルトでは2xx以外のレスポンスでノードが失敗します。実行はそこで止まり、レポートノードは実行されません。日次レポートではその逆が必要です。1つのリストが失敗しても他のリストはレポートに含め、失敗したリストにはわかりやすい注記を付けます。

「Never Error」とフルレスポンスを有効にすると、422のボディとステータスは通常のデータとして次のノードに渡されます。バッチ間隔を設けることで、EveryInfraのAPIキーあたり毎分10回という制限を超えずに済みます。この値はGET /api/v1/accountがkey_requests_per_minuteとして返します。呼び出し間隔を1.5秒にすると、1回の実行に約13〜16秒かかりました。

1. 2つ目のCodeノードでレポートを作成し、前回の実行を記録します。このノードは、5件のレスポンスをステップ3の5件のリクエストと順番に対応させます。各リストからrank順にトップ10を取り出し、順位のないプロモーション行はスキップします（下記のコードを参照）。$getWorkflowStaticData('global')から前回のトップ10を読み込み、重複を数え、新しいリストを保存します。markdownとfileNameを持つアイテムが1件表示されます。

トップ10を取り出す処理は、特に注意して正しく実装してください。Weiboのホット検索のレスポンスにはプロモーション枠が混ざっています。タイトルと熱度の値はありますが、rankがありません。14回の実行で、Weiboの上位10位以内をプロモーション枠が占めたのは合計16回でした。DouyinとXでは0回でした。位置で番号を振ると、広告がホットトピックになり、それ以降の順位がすべて1つずれます。2つ目のCodeノードには次の処理を入れてください。リストのいずれかの行にrankがあれば、rankのある行だけを残してその値で並べ替えます。どの行にも順位がない場合に限り、位置で代用します。

function top10(results) {
  const rows = results || [];
  const hasRank = rows.some(x => x.rank != null);
  const kept = hasRank ? rows.filter(x => x.rank != null).sort((a, b) => a.rank - b.rank) : rows;
  return {
    top: kept.slice(0, 10).map((x, i) => ({ rank: x.rank ?? i + 1, title: x.title || x.keyword || x.name })),
    promoted: rows.length - kept.length,   // goes into the heading: "N promoted rows skipped"
  };
}

14回の実行で出現したプロモーション枠は以下の7件です。出現位置は4番目と8番目の2か所だけでした。タイトルは通常のホットトピックと見分けがつかず、空のrankだけが手がかりになります。最後の「複数のアイクリームに誇大広告の疑い」はニュースのように見えますが、これもrankがないためスキップします。このような行を残したい場合は、別のルールが必要です。

静的データは、n8nで実行間のデータを保持する最も軽量な方法です。n8nのドキュメントには2つの制限が記載されています。手動のテスト実行では保存されず、公開済みのワークフローがトリガーから実行された場合にのみ保存されます。また、高頻度の実行では信頼性が下がることがあります。そのため、手動実行では「前回の実行との重複」は常に空になります。

これは想定どおりの動作です。確実に保持する必要があるデータについては、ドキュメントではデータテーブルの使用を推奨しています。

このノードはコストも2通りの方法で計算します。「レスポンスの合計」は、すべての呼び出しのbilling.charged_usdを合計します。「実際の請求額」は、replayedがtrueの呼び出しを除外します。両方の数値が必要な理由はテスト3で説明します。

1. ファイルに変換してディスクに書き込みます。 Convert to Fileノードで、markdownフィールドに「Convert to Text File」を使います。続いて、Read/Write Filesノードでreports/フォルダにファイルを書き込みます。実行ごとに新しいreport-<time>.mdファイルが1つ作成されるはずです。

このステップでパスが書き込み不可、または許可されていないと表示された場合は、まずN8N_RESTRICT_FILE_ACCESS_TOを確認してください。パスは、この変数で許可されたフォルダ内にある必要があります。

1. 公開してから、n8nを再起動します。 n8n import:workflow --input=A.json、n8n publish:workflow --id=eiDailyReport01、n8n startの順に実行します。起動ログに「Scheduler started」と「Processed 0 draft workflows, 2 published workflows」が表示されるはずです。

コマンドラインからの公開には、見落としやすい点が1つあります。publish:workflowはデータベースに直接書き込みます。コマンド自体も「Changes will not take effect if n8n is running」と出力します。実行中のn8nは、再起動するまで変更を認識しません。この点がテスト1の答えを左右します。

テスト1：時間どおりに実行されるか、「N分ごと」の起点はどこか

n8n 2.45では「N分ごと」の意味が変わります。Durable schedulerのドキュメントには、これらのスケジュールは「ワークフローの公開時点から測った均等な間隔で実行される」とあります。分の区切りには揃わなくなりました。時計に合わせた実行タイミングを維持するには、N8N_SCHEDULER_TRIGGER_NODE_MODE=legacyを設定します。以下が原文で、該当するルールをティールの枠で囲んでいます。

では、どの時点が「公開」なのでしょうか。2つのワークフローは、コマンドラインから10:32:59と10:33:01 SGTに公開しました。n8nは10:36:20に起動し、10:36:24にそれらを有効化しました。答えはSQLiteのscheduled_jobテーブルにあります。2件のcreatedAtはそれぞれ10:36:24.207と10:36:24.209で、最初のnextRunAtは10:39:24.206です。

カウントが始まるのは、実行中のn8nがワークフローを有効化した時点であり、コマンドがデータベースに書き込んだ時点ではありません。エディタでは、この2つは同じクリックで起こります。コマンドラインでは、両者に3分25秒の差がありました。

その後の14回の実行は、すべて同じ位相になりました。10:39:24から11:24:24まで、各3分区切りの24.206秒後です。通常の実行では、予定時刻の0.008〜0.034秒後に実行が始まりました。合格ラインの5秒を大きく下回ります。停止が絡まない場合、2回の実行の間隔は179.978〜180.013秒でした。

テスト中にn8nを2回再起動しましたが、位相は変わりませんでした。再起動のたびにscheduled_jobの行は残っており、nextRunAtは以前の位相のまま続きました。再起動によって新しいカウントが始まることはありませんでした。これが、従来のインメモリスケジューラーとの最も明確な違いです。

次の表は、予定された16回の時刻を1つずつ示しています。値はすべてSQLiteと実行データから取得し、分析スクリプトanalysis.pyで算出しました。時刻はSGTです。

最後の列からは、スケジューリングとは関係のないことが1つわかります。最初の実行では、Weiboは10件、Douyinは8件しか返しませんでした。その後は両方ともほとんどの場合20件を返しました。これはカタログにある両者のdefault_limitです。これがコストにどう影響するかはテスト3で説明します。

これは日次レポートにどう影響するでしょうか。8:00ちょうどにレポートを受け取るには、「Days」間隔で午前8時0分を指定します。ドキュメントによると、時間単位、日単位、週単位、月単位のスケジュールは、通常の使用ではどちらのモードでも同じように動作します。変わるのは「N分ごと」と「N秒ごと」だけです。

「30分ごと」を使って毎時0分と30分に実行していた場合、2.45以降は公開をクリックした秒を起点に30分間隔で実行されます。毎時0分と30分に揃えるには、0 */30 * * * *のようなcron式を使います。ドキュメントによると、cronはこの設定の影響を受けません。legacyを設定することもできますが、ドキュメントではlegacyは非推奨とされており、将来のバージョンで削除される予定です。

テスト2：n8nの停止中、実行はどうなるか

これは2.45で最大の変更点で、最も時間をかけて検証しました。従来のインメモリスケジューラーは、次の実行をプロセス内に保持します。ドキュメントには「再起動すると保留中の実行は失われる」とはっきり書かれています。停止中に予定時刻を迎えた実行はスキップされます。Durable schedulerは各実行をまずデータベースに書き込むため、実行されなかった回も「記録に残ります」。猶予期間内にn8nが復帰すれば、その実行は遅れて始まります。猶予期間を過ぎた場合は、ミスファイアポリシーに従います。

同じ停止時間で2つのポリシーを比較するため、2つのワークフローを公開しました。ワークフローAはレポートで、デフォルトの「Don't Run Missed Executions」を使います。ワークフローBはハートビートです。APIは呼び出さず、時刻をファイルに書き込むだけなので、費用はかかりません。Bは「Run the Most Recent Missed Execution」を使います。

どちらも同じ位相で3分ごとに実行されます。スクリプトでプロセスIDを指定してSIGTERMでn8nを停止し、プロセスの終了を待ってから、決められた時刻に再起動しました。スクリプトはすべての時刻を記録しました。

1回目の停止：32秒、猶予期間内。 10:45:12（SGT）にn8nを停止し、10:45:40に起動、10:45:44に準備完了となりました。予定時刻10:45:24は停止中に当たりました。この実行は、停止前からテーブルscheduled_taskに登録されていました。マテリアライズウィンドウN8N_SCHEDULER_MATERIALIZATION_WINDOWはデフォルトで60秒なので、各実行の行は約1分前に作成されます。再起動後、AとBはどちらも10:45:46.0に開始しました。21.8秒の遅れで、60秒の猶予内です。

補足：停止前、両方の行のmissedAfterは10:46:24.206で、予定時刻に60秒を足した値でした。再起動後、n8nはこれを10:46:45.677に変更しました。再起動によって、起動時点から新たな猶予期間が与えられたようです。これは1回しか観測しておらず、このルールについてはそれ以上検証していません。

2回目の停止：6分44秒、予定時刻2回分にまたがる。10:49:00（SGT）にn8nを停止し、10:55:40に起動、10:55:44に準備完了となりました。予定時刻10:51:24と10:54:24はどちらも停止中に当たり、n8nが復帰した時点で両方とも60秒の猶予を過ぎていました。結果はドキュメントどおりでした。

Aはどちらの回も実行されず、次の実行は10:57:24でした。Bは10:55:53に1回だけ実行されました。この実行は直近の予定時刻10:54:24に対応するもので、89.0秒の遅れでした。Bが10:51:24の分を別途キャッチアップ実行することはありませんでした。

実行データだけでは不十分です。実行されなかった分は、そもそも記録に残らないからです。そこでn8nのPrometheusメトリクスを有効にし、2回目の再起動後の10:56:30 SGTに/metricsを1回読み取りました。カウンターはプロセス起動時にゼロから始まるため、反映されているのは2回目の停止分のみです。

レポート実行の間隔を見ると、2回の停止がはっきりわかります。1回目の停止では1回の実行が21.8秒遅れたため、その前後の間隔は201.8秒と158.2秒になりました。合計は360秒のままなので、位相はずれていません。2回目の停止では2回の実行が失われ、その間隔は540.0秒、ちょうど3周期分でした。

実行データ、scheduled_taskテーブル、メトリクスという3つの情報源が同じ結果を示しています。これがJ4を合格とした理由です。各カウンターの説明はスケジューラー変数のページにあります。n8nはすぐに使えるGrafanaダッシュボードも公開しています。レポートを他の人も読んでいるなら、occurrences_misfired_totalにアラートを設定しましょう。この値が増えた場合は、1日分のレポートが作成されなかったことを意味します。

日次レポートにはどのポリシーが適切でしょうか。おすすめは「Run the Most Recent Missed Execution」を、ステップ3の日付ベースのキーと組み合わせることです。日次レポートは1日1部あれば十分です。停止後に必要なのは、その日の分です。n8nが翌日に復旧した場合、キャッチアップ実行は新しい日付と新しいキーを使うので、新しい日の分が作成されます。デフォルトのスキップポリシーは、毎分のハートビートのように、遅れて実行しても意味のないジョブに向いています。

猶予期間は再起動にかかる時間をもとに設定します。ドキュメントによると、猶予期間はエグゼキューターの実行間隔より長く、かつマテリアライゼーションウィンドウ以上である必要があり、デフォルト設定では60秒になります。お使いのマシンでアップグレード時の再起動に3分かかるなら、ノードの猶予期間を300秒に設定してください。

テスト3：料金と、課金されたように見えるリプレイ

各実行では4つのトレンド機能を呼び出します。米国とメキシコのtwitter/trending、weibo/trending、douyin/trendingです。10:15 SGTに確認したEveryInfraカタログでは、3つとも1回の呼び出しあたりのprice_usdが0.000556です。したがって1回の実行コストは4 × $0.000556 = $0.002224になるはずです。以下はtwitter/trendingの実際のカタログレスポンスです。青緑の枠は価格とcollected_atの意味を示しています。

リプレイを除くと、14回の実行のコストはすべてちょうど$0.002224でした。合計は$0.031136です。

レスポンスだけを信用したわけではありません。テスト後、GET /portal/api/logsでサーバーの呼び出しログを読み取り、すべてのrequest_idを照合しました。14回の実行による課金済みの呼び出し56件は、すべてログにありました。いずれもcostは40クレジットで、これは$0.000556に相当し、レスポンスのcharged_usdと小数点以下6桁まで一致しました。422を返した14件の呼び出しは、呼び出しログに一切記録がありませんでした。つまり課金されていません。

落とし穴はリプレイです。10:40:46 SGTに、10:39の実行で行ったWeiboの呼び出しを、同じキーdaily-report-20261026-1039-weibo-defaultを使ってcurlで再送しました。

レスポンスは200で、ヘッダーにidempotent-replayed: true、ボディにreplayed: trueがありました。idは最初の呼び出しのreq_a5c69df94c2f4d66でした。新しいリクエスト自体のIDはx-request-idヘッダーにあるreq_7278432b29f64594です。サーバーログに2回目の課金はありませんでした。それでもbillingブロックには"charged": true, "charged_usd": 0.000556と表示されていました。

理由はOpenAPIの説明文にあります。リプレイは保存された最初のレスポンスを返し、「同じbillingで、再実行も再課金もされない」と記載されています。つまりbillingはこの呼び出しではなく、最初の課金を表しています。

日次レポートでは、これは下のグラフのようになります。KEY_BYをdayに設定し、n8n executeでワークフローを手動で2回実行しました。実行記録の開始時刻は10:56:46.565 SGTと10:57:04.358 SGTです。2回目の実行では4件の呼び出しがすべてリプレイで、実際の課金は$0でした。多くのチュートリアルのようにすべてのcharged_usdを合計するレポートでは、2回目の実行が$0.002224と表示されてしまいます。

そのため、replayedがtrueでない呼び出しだけをカウントしてください。今回作成したレポートでは両方の数値を表示しています。2つの数値が異なる場合はその日に再実行があったということなので、誰がなぜ実行したのかを確認できます。

逆のケースもテストしました。10:40:54 SGTに、同じキーで異なるパラメータを送信しました。APIは409 idempotency_conflictを返し、next_stepsには「新しいリクエストは新しいキーで送信してください。課金は発生していません。」とありました。つまり日付ベースのキーには、プラットフォームとパラメータも含める必要があります。そうしないと、同じ日の異なる2つのリストが互いをブロックしてしまいます。ステップ3のキーにプラットフォームと国が含まれているのはそのためです。

コスト

テスト全体の請求額です。金額はすべてリプレイを除いた実際の課金額で、サーバーログと照合済みです。

ご自身のレポートのコストは、スケジュールによって次のように変わります。

価格はすべてカタログのprice_usdの値で、2026年10月26日10:15（SGT）に確認しました。最終行はキーの効果を示しています。同じ日に何度再実行しても、課金は1回だけです。

もう1つ見落としやすい事実があります。トレンドのランキングは件数単位ではなく呼び出し単位で課金されます。同じ$0.000556で、Xのメキシコのランキングは71件、WeiboとDouyinのランキングはそれぞれ20件を返しました（14回の実行の中央値）。1,000件あたりでは3.6倍の差です。

件数も呼び出しごとに変わります。10:39 SGTの最初の実行では、Weiboは10件、Douyinは8件を返しました。その後の13回では、Douyinは常に20件、Weiboは15〜20件（ほとんどが20件）を返しました。これはカタログにある両者のdefault_limitで、weibo/trendingのmax_limitは200です。Weiboホット検索ルールには毎分更新されるTop 50のランキングが記載されているため、デフォルトではその一部しか取得できません。

このレポートで使うのは上位10件だけなので、最初の実行で欠けたのはDouyinの2件だけでした。全件が必要な場合は、カタログでlimitを指定できるか確認してください。そのうえで、実際の呼び出しを1回行い、行数を確認してください。また、各実行の行数もレポートに書き込んでください。

デフォルトの件数で見積もらないでください。件数が少ないレスポンスでも$0.000556かかるため、1件あたりの価格を計算するときはそれも含めてください。

テスト4：誤った呼び出しが1回あってもレポートは届く

毎回の実行で、5番目の呼び出しはDouyinのboardsの値をhotにしています。正しい値はhotspotです。14回の実行すべてで、この呼び出しは422を返しましたが、レポートは届き、他の4つのランキングは欠けていませんでした。以下は10:39の実行での実際のレスポンスです。

このレスポンスが自動化に向いているのはなぜでしょうか。修正方法を、プログラムで読み取れるフィールドで返すからです。allowedには有効な値が並びます。did_you_meanは最も近い値を示します。retryable: falseは、同じリクエストを送っても再び失敗することを示します。

next_stepsの1行目には「Nothing was charged」とあります。レポート用ノードはmessageとdid_you_meanをレポートにコピーするので、読む人は値をhotspotに変えればよいとわかります。ステータス422はRFC 9110で「Unprocessable Content」とされており、リクエストの形式は正しいものの、その内容を処理できないことを意味します。同じリクエストを再試行しても成功しません。

この設計は、ステップ4の「Never Error」スイッチがあって初めて成り立ちます。このスイッチがないと、n8nは実行を失敗として扱ってエラーワークフローを開始し（エラー処理のページ）、その日のレポートは作成されません。毎日読むファイルなら、リストが1つ欠けているほうが、ファイル自体がないよりはるかにましです。次の表は、テストで実際に発生させたレスポンスとOpenAPIの記述にあったレスポンスを、レポート側の対応とあわせてまとめたものです。

最初の5つのケースは自分たちで発生させたものです。401は10:18 SGTにキーなしで呼び出したときのもので、生のレスポンスを保存しています。最後の2行はOpenAPIの記述によるもので、このテストでは発生させていません。

テスト5：MCP Clientノードでの同じ機能の呼び出し

n8nにはMCP Clientノードもあります。任意のMCPサーバーのツールを、通常のワークフローステップとして使えます。EveryInfraのMCPエンドポイントはhttps://api.everyinfra.com/mcpです。ツールの一覧取得にキーは不要で、10:39 SGT時点で25個のツールが表示されました。REST呼び出し1回と同じパラメータで、everyinfra_call_apiを1回呼び出しました。

{
  "type": "@n8n/n8n-nodes-langchain.mcpClient",
  "typeVersion": 1.1,
  "parameters": {
    "endpointUrl": "https://api.everyinfra.com/mcp",
    "authentication": "bearerAuth",
    "tool": { "__rl": true, "mode": "id", "value": "everyinfra_call_api" },
    "inputMode": "json",
    "jsonInput": "{\"platform\":\"weibo\",\"action\":\"trending\",\"params\":{}}",
    "options": { "timeout": 90000 }
  },
  "credentials": { "httpBearerAuth": { "id": "eiBearer000001", "name": "EveryInfra API Key" } }
}

10:39:52（SGT）にn8n execute --id=eiMcpCheck0001で実行しました。ノードの処理時間は9.3秒でした。content[0].textは、トップレベルのフィールドid、platform、action、results、count、billing、quota、async_hintを持つオブジェクトとして返りました。件数は10、課金額は$0.000556で、サーバーログにもこの呼び出しが記録されていました（req_0e075488e27f44e6、10:40:01）。各結果にはrank、title、hot_value、is_hot、is_new、label、url、platformがあり、同時刻のRESTレスポンスと同じフィールドでした。トランスポートはデフォルトのStreamable HTTPで、2025-11-25版のMCP仕様にある2つの標準トランスポートの1つです。

では、なぜレポートにMCPを使わないのでしょうか。理由は2つあります。第1に、HTTP RequestノードはIdempotency-Keyヘッダーを送信できますが、MCP Clientノードにはツールの引数にそれを入れる場所がありません。キーがなければ、キャッチアップ実行に「1日1回の課金」の保護が働きません。第2に、MCPが最も向いているのは、モデルがツールを選んで引数を組み立てる場合です。

固定の呼び出しが5回だけのレポートには、それは必要ありません。MCP Clientが適しているのはAI Agentノードの後段で、モデルがレポートを読み、特定のトピックをさらに掘り下げるかどうかを判断する場面です。この用途向けに、n8nには別途MCP Client Toolノードがあります。

コマンドラインにはもう1つ落とし穴があります。n8nサービスの実行中にn8n executeを実行すると、同じポートで独自のタスクブローカーが起動します。このコマンドに限ってN8N_RUNNERS_BROKER_PORT=5692を設定したところ、動作しました。Claude、CursorなどのクライアントでEveryInfra MCPを設定するには、リモートMCPセットアップガイドをご覧ください。詳しくはMCPサーバーのページをご覧ください。

45分間でのリストの変化量

1日1回のレポートで十分でしょうか。それは各リストがどれだけ速く変化するかによります。計測したのは10:39から11:24（SGT）までの45分間だけなので、ここで答えられるのは「1時間以内」の変化であり、「1日以内」の変化ではありません。数値はすべて、分析スクリプトanalysis.pyが14回分の実行記録から算出しています。

リストごとの数値は次のとおりです。Weiboホット検索ではrankで数え、プロモーション枠を除外しています（各実行の先頭10枠のうち0〜2枠。位置で数えると、これらが新しいトピックのように見えていました）。連続する2回の実行の間で上位10件のうち7〜10件が残ったため、3分ごとに0〜3件のトピックが入れ替わり、13組中9組では入れ替わったトピックは1件以下でした。1位のトピックは10:57と11:18（SGT）の2回入れ替わりました。最初と最後の上位10件の両方に入っていたトピックは4件だけでした。

Douyinホットスポットランキングで固定されている1位は一度も変わりませんでした。2回の実行の間で残ったトピックは7〜10個で、最初と最後のランキングの両方にあったのは5個でした（最初の実行は8件のみ）。

Xの2つのリストは、最初の8回の実行ではまったく変化しませんでした。その後、11:12の実行で両方が同時に変化しました。米国のリストでは「Chiefs」が1位に上がりました。メキシコのリストでは、テレビ番組の新しいハッシュタグが2位に入り、前回の実行から残ったトピックは6件だけでした。その後、両リストは再び安定しました。最初と最後の実行の間で残ったトピックは、米国のリストで9件、メキシコのリストで6件でした。

プロモーション枠がWeiboの数値に与える影響を並べると、次のとおりです。

同じデータを別の角度から見てみます。45分間で、Weiboの上位10件には21件の異なるトピックが入りました（表示位置ごとに数えると27件で、その差の6件は入れ替わるプロモーション枠です）。Douyinでは18件、X（メキシコ）では14件、X（米国）では11件でした。1日1回実行するレポートでは、各リスト10件しか表示されません。Xの場合、それでこの1時間のほとんどをカバーできます。Weiboの場合、この1時間に上位10件に入ったトピックの半数以上（21件中11件）がレポートに一度も表示されません。

これらの数値が示しているのは、4つのリストの変化の速さが異なるということです。どのリストが優れているかを示すものではありません。Xのリストは毎回の呼び出しで最新でした。collected_atは各呼び出しの数秒前で、たとえば10:39:34や10:42:35 SGTでした。上位10件はほとんどの時間変わらず、その後一度にまとめて変化しました。この間、前夜のブラジルの選挙が上位を占めていました。

このような一斉の変化は1回しか観測できなかったため、Xがリストをどの頻度で更新しているかはわかりません。Xのトレンドのおすすめに関するページには、トレンドは「今人気の」トピックであると書かれています。また、Xは新しいアカウントやフォロワーの少ないアカウントを除外し、国、地域、都市ごとにトレンドを検出しているとも書かれています。そのため、Xのトレンドは、毎分更新されるWeiboホット検索よりもゆっくり変化します。

レポートに当てはめると、Xで大きな話題を追うには1日1〜2回の実行で十分です。Weiboの浮き沈みを追う場合、1日1回の実行では、実行の合間に浮上して消えていく多くのトピックを見逃します。実行頻度を上げるか、すべてのリストを保存して「今日登場したすべてのトピック」をレポートしてください。

キーはディスクに書き込まれたか

レポートは長期間にわたって実行されます。エクスポート、実行データ、バックアップに入り込んだキーも、同じく長期間そこに残ります。

テスト後の11:25 SGTにn8nを停止し、3か所でキーの文字列を検索しました。1か所目は、SQLiteデータベース、そのWALファイル、イベントログ、設定ファイルを含むn8nのデータフォルダ全体です。2か所目はreports/内の16件のレポートです。3か所目は、この記事のすべての元ファイルです。一致は0件でした。

認証情報テーブルには暗号化された値しか保存されていません。実行データでは、HTTP Requestノードの出力にステータス、レスポンスヘッダー、ボディは含まれますが、リクエストヘッダーは含まれません。422となった呼び出しのエラーデータにもキーは含まれていませんでした。

エラーデータを調べたのには理由があります。10月14日、n8nは関連する問題を修正しました。GHSA-qmvv-q3c9-wpp7は、Git、MongoDB Atlas Vector Store、Google Cloud Storageの各ノードに関するものです。これらのノードは、操作が失敗すると、認証情報に含まれるパスワードやトークンをエラーデータに書き込んでいました。実行データは閲覧できても認証情報は閲覧できないユーザーが、そのシークレットを読み取れる状態でした。修正済みバージョンは1.123.85、2.44.1、2.43.5です。

HTTP Requestノードは対象リストに含まれておらず、今回のテストでも漏えいは見つかりませんでした。それでも、アップグレードのたびに実行データ内のシークレットを検索すべき理由がよくわかります。

実際に遭遇した問題

以下の各行は、今回のテスト中に実際に発生したものを順に並べています。ほとんどはn8nのバグではありません。2.xの新しいデフォルト設定とコマンドライン利用の組み合わせによって生じたものです。

最も時間を取られたのは1行目で、誤解しやすい点でもあります。エラーにはn8nと無関係なログ出力パッケージの名前が出るため、Node.jsの問題に見えます。しかしそうではありません。インストールが完了しておらず、クリーンインストールで解決します。

3行目と4行目は合わせて読んでください。エディタでは、データベースへの書き込みとワークフローの有効化が同じクリックで行われるため、フェーズはクリックした秒になります。コマンドラインと再起動を使う場合、フェーズは再起動でワークフローが有効化された秒になります。このテストでは、2つの時点に3分25秒の差がありました。コマンドラインからレポートをデプロイし、「N分ごと」を別のシステムと揃える必要がある場合、フェーズは再起動の時点で決まります。

非推奨の通知は一度しっかり読んでおく価値があります。10:36 SGTの起動ログには6件ありました。N8N_UNVERIFIED_PACKAGES_ENABLEDのデフォルトがfalseになります。内部タスクランナーモードは削除されるため、外部モードへ移行する必要があります。タスクのタイムアウトN8N_RUNNERS_TASK_TIMEOUTは300秒から60秒に短縮されます。

圧縮ノードの2つの制限値が引き下げられます。さらに、「Running n8n outside a container is deprecated」という通知もあります。レポートに影響するのはタスクのタイムアウトです。3.0以降は、60秒を超えて実行されるCodeノードのタスクが停止するため、タイムアウトを自分で設定するか、処理を分割してください。外部モードについてはタスクランナーのページで説明されています。

SQLiteで自分で確認する方法

n8nのエディタには実行の一覧が表示されますが、「本来行われるはずだったのに行われなかった実行」は表示されません。永続スケジューラーはこれを2つのテーブルに保持しており、sqlite3で読み取れます。J1〜J4の判定には、次の3つのクエリを使いました。

DB=$HOME/Downloads/n8n-lf25/home/.n8n/database.sqlite
# 1. Phase, interval, misfire policy and grace of each schedule
sqlite3 -header $DB "select name, intervalSeconds, nextRunAt, lastFiredAt, misfirePolicy, misfireGraceSeconds from scheduled_job;"
# 2. Each run in the queue: planned time, actual start, latest allowed start
sqlite3 -header $DB "select id, jobId, status, scheduledFor, startedAt, missedAfter from scheduled_task order by id;"
# 3. Runs that executed: trigger mode, status, start time (all times in UTC)
sqlite3 -header $DB "select id, workflowId, mode, status, startedAt from execution_entity order by id;"

注意点が3つあります。まず、時刻はすべてUTCです。シンガポール時間にするには8時間を足し、ニューヨーク時間にするには11月1日までは4時間を引きます。

次に、scheduled_taskにはキューに入った実行しか保存されません。猶予時間はデフォルトで60秒です。停止中に予定時刻を迎え、n8nが復帰した時点で猶予時間を過ぎていた実行は、このテーブルに一切現れません。そのため、行数を数えても実行されなかった回数はわかりません。フェーズから算出するか、n8n_scheduler_occurrences_misfired_totalを確認してください。

今回まさにこのケースがありました。10:51:24と10:54:24 SGTのAの実行には行がありません。「フェーズ + 180 s × k」からこれらを特定し、カウンター値の2と照合しました。

最後に、完了した実行はデフォルトで1日保持され（N8N_SCHEDULER_RETENTIONは86,400秒）、失敗した実行や実行されなかった実行は7日間保持されます。月次レビューを行う場合は、定期的にエクスポートしてください。今回は3つのテーブルをexecutions.jsonにエクスポートし、分析スクリプトanalysis.pyがこのファイルから本記事のすべての時刻を算出しています。

次の表は、合格基準の各項目と、その判定の根拠となったエビデンスの対応を示しています。ファイルはすべて記録として保管しています。

フィールドリファレンス：レポートで使えるすべてのフィールド

レポートで使うのは各行の名前と順位だけですが、4つの機能はそれ以外のフィールドも返します。この表は、10:15 SGTに取得したカタログのresponse_fieldsとフィールドごとに照合しました。「今回の実行」列は、10:39の実行の行にどのフィールドが含まれていたかを示します。

生のレスポンスを1件ずつ確認して初めて気づいたことが3つあります。第1に、Douyinで固定表示される項目（is_pinned: true）にはhot_valueがありませんが、他の19件にはあります。熱度順に並べるとこの項目が最後になるため、Douyinはrankで並べ替えてください。

2つ目は、event_timeフィールドだけが2つの形式で返ってきたことです。ピン留め行はタイムゾーンなしの「2026-10-26 10:41:56」、他の行はUTCの「2026-10-25T01:23:31.000Z」でした。単純な文字列比較では誤った結果になるため、両方の形式をパースしてください。

3つ目は、14回の実行でWeiboが一度もcategoryを返さなかったことです。フィールドが常に存在するとは考えないでください。x.category ?? ''のようにデフォルト値を指定して読み取らないと、フィールドが欠けた日にCodeノードがエラーを投げます。boardsの他の値では挙動が異なる可能性がありますが、検証していません。

パラメータとフィールドの全一覧は、XトレンドAPIページ、Weiboトレンドページ、Douyinトレンドページに掲載しています。各プラットフォームの概要は、XスクレイピングAPI、WeiboスクレイピングAPI、DouyinスクレイピングAPIをご覧ください。

同じ呼び出しのコード例

まだn8nをインストールしたくない場合は、このcurlコマンドでステップ4のHTTP Requestノードと同じリクエストを送れます。まずはターミナルでAPIキーとパラメータを確認するのに使ってください。

curl -s https://api.everyinfra.com/api/v1/social \
  -H "Authorization: Bearer ${EVERYINFRA_API_KEY}" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: daily-report-$(TZ=America/New_York date +%Y%m%d)-twitter-us" \
  -d '{"platform":"twitter","action":"trending","params":{"country":"us"}}' \
  | jq '{replayed, count, top3: [.results[0:3][].name], charged_usd: .billing.charged_usd}'

同じ日に2回目を実行すると、replayedがtrueになります。charged_usdには最初の値が表示されたままですが、新たな課金は発生しません。なお、ここではキーの日付にニューヨーク時間を使っています。キーに使うタイムゾーンを1つに決め、n8nでも同じものを使ってください。そうしないと、深夜0時前後のレポートで、想定より早く、または遅く新しいキーに切り替わることがあります。

APIキーの取得とリクエスト・レスポンス形式の確認は、クイックスタートから始めてください。各機能の料金は料金ページに掲載しています。レポートで失敗した呼び出しの返金も確認しますか？失敗した呼び出しの返金照合ガイドでは、charge_idと呼び出しログを使って各課金を照合する方法を説明しています。

同じことを実現する他の方法

日次レポートにn8nは必須ではありません。この表には、私たちが確認できた事実のみを記載し、あわせて各方法が向いているケースを示しています。

「cronはキャッチアップしない」は従来のcronについての説明です。Persistent=trueを設定したsystemdタイマーのように、キャッチアップできるタイマーもありますが、検証していません。私たちの基準では、失敗時の分岐がない1〜2回の呼び出しなら、cronとcurlのほうが軽量です。ステップが3つ以上ある場合、失敗をレポートに含める必要がある場合、または他の人も編集するフローの場合は、n8nを使います。比較したい場合は、別のアプローチを採用しているマルチプラットフォームの評判モニタリングガイドをご覧ください。

この構成が適さないケース

すべての実行を必ず1回だけ行う必要がある場合。 キャッチアップポリシーで実行されるのは、未実行分のうち、多くても最新の1回だけです。すべての実行が行われるわけではありません。ドキュメントには、どのポリシーでも溜まった実行を1回ずつ再実行することはないと記載されています。たとえば日次平均を計算するために1時間ごとのデータがすべて必要な場合は、レポートで予定時刻を確認し、欠けた分をご自身で補ってください。

1つのSQLiteデータベースを複数のn8nインスタンスで共有する場合。 私たちが検証したのは1インスタンスのみです。ドキュメントによると、メインインスタンスが複数ある場合は各実行を1つのインスタンスが引き受けますが、それにはPostgresとキューモードが必要で、これらは検証していません。

ランキング全体が必要です。デフォルトでは1回の呼び出しで20件が返り、最初の呼び出しでは10件と8件しか返りませんでした（テスト3を参照）。

長い時間枠が必要な場合。 私たちが計測したのは、SGTで10月26日午前の45分間です。ブラジルの選挙の翌日で、1件の記事がすべてのリストの首位を占めていました。

最近の変更

• 2026年10月20日：n8n 2.45で永続スケジューラーがデフォルトで有効に。 変更履歴とGitHubのリリースノートを参照してください。このリリースでは、使われていなかったN8N_SCHEDULER_MIN_INTERVALも削除されています。影響：アップグレード後は「N分ごと」の実行タイミング（位相）が変わり、停止時の挙動も変わるため、スケジュール実行する各ワークフローのミスファイアポリシーを見直してください。
• 3.0以降：Dockerのみ。 3.0の破壊的変更ページによると、npmとnpx n8nのサポートが終了し、旧CronノードとIntervalノードが削除されます。影響：本記事のnpmインストールはテスト用です。長期間動かすレポートはDockerに移行し、CronノードはSchedule Triggerに置き換えてください。
• 2026年10月14日：n8nのセキュリティアップデート。 アップデートには、実行エラーデータに認証情報が含まれる問題を含む15件のアドバイザリが記載されています。影響：セルフホストのインスタンスは最新のパッチを適用した状態に保ち、アップグレード後は実行データにシークレットが含まれていないか検索してください。
• 2026年10月14日：Censysが、n8nはインターネット上で最も多く公開されているAI関連製品だと報告。 Censysのレポートでは113,926台のホストを確認しています。影響：自分のマシンで動かすレポート用のn8nを、インターネットに公開する理由はありません。
• 2026年10月6日：Diagridがn8n向けの永続実行（durable execution）を発表。 有料のプレスリリースによると、クラッシュ後もワークフローは失敗したノードから再開します。冪等性の台帳によって副作用の重複を防ぎます。影響：n8n 2.45は、予定された実行が失われないことを保証します。実行途中のクラッシュは別の問題で、すでにパートナー企業が取り組んでいます。
• 2026年10月12日：ZoomInfoがn8nのネイティブノードを提供開始。 Business Wireのリリースによると、同社はデータをAPIとMCPでも提供しています。影響：データサービスは専用ノードとMCPの両方を通じてn8nと連携できます。EveryInfraには現在n8n専用ノードがありません。本記事では汎用のHTTP RequestノードとMCP Clientノードを使っています。
• 2026年10月22日：IETFのIdempotency-Keyドラフトがバージョン08に。 IETF datatrackerのページを参照してください。影響：リクエストヘッダーによる冪等性は標準になりつつあるため、日付ベースのキーは他のAPIでも使えます。

FAQ

n8nのSchedule Triggerのタイムゾーンはどう設定しますか？（出典：Googleのサジェスト「n8n schedule trigger time zone」、2026年10月26日に確認）

セルフホストのn8nは、デフォルトでAmerica/New_Yorkを使います。GENERIC_TIMEZONEを設定し（例：America/Chicago）、再起動してください。ワークフロー設定でもタイムゾーンを設定でき、こちらがインスタンスの設定より優先されます（Schedule Triggerのページ）。私たちは両方にAsia/Singaporeを設定したため、ファイル名はシンガポール時間になっています。

再起動後にn8nのSchedule Triggerが実行されなかったのはなぜですか？（出典：Googleのサジェスト「n8n schedule trigger not running」、2026年10月26日に確認）

まずバージョンを確認してください。2.44までは、デフォルトのインメモリスケジューラーが、停止中に予定されていた実行をすべてスキップします。2.45以降の永続スケジューラーでは、猶予期間（デフォルトは60秒）内にn8nが復帰すれば、遅れて実行されます。猶予期間を過ぎた場合はノード設定の「If Execution Is Missed」で挙動が決まり、こちらもデフォルトはスキップです。私たちが6分44秒停止したときは、デフォルトのポリシーにより、設計どおり2回の実行が破棄されました。キャッチアップするには「Run the Most Recent Missed Execution」を設定し、キャッチアップで二重に課金されないよう日付ベースのキーを使ってください。

n8nでワークフローを止めずにHTTP Requestのエラーを処理するには？（出典：Googleのサジェスト「n8n http request error handling」、2026年10月26日に確認）

HTTP Requestノードのオプションで「Never Error」と「Include Response Headers and Status」をオンにします。これで2xx以外のレスポンスもデータとして次のノードに渡されるので、statusCodeで分岐できます。私たちが行った14回の実行では、誤った呼び出しは毎回422を返し、レポートも毎回届きました。EveryInfraのエラーにはnext_stepsが含まれるため、そのままレポートに記載できます。

関連記事

• リモートMCPのセットアップ：Claude、CursorなどのクライアントでEveryInfra MCPに接続します。
• 失敗した呼び出しの返金照合：すべての課金と返金を突き合わせます。
• YouTubeコメントからトピックレポートを作って販売する：毎月実行する別の定期レポートです。
• MCP 2026仕様と本番運用への備え：MCPのトランスポートと認証に関する背景知識です。

参考資料

1. Durable scheduler、n8nドキュメント、2026年10月、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/durable-scheduler/>
2. Scheduler environment variables、n8nドキュメント、2026年10月、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/scheduler/>
3. Schedule Trigger node、n8nドキュメント、2026年10月、<https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/>
4. Changelog（durable schedulerがデフォルトで有効）、n8nドキュメント、2026年10月20日、<https://docs.n8n.io/changelog/>
5. Release notes（n8n 2.45および2.44）、n8nドキュメント、2026年10月20日、<https://docs.n8n.io/changelog/release-notes/>
6. Release n8n 2.45.0、n8n（GitHub）、2026年10月20日、<https://github.com/n8n-io/n8n/releases/tag/n8n%402.45.0>
7. v3.0 Breaking changes、n8nドキュメント、2026年10月、<https://docs.n8n.io/changelog/v30-breaking-changes/>
8. Developing v3 features、n8n（GitHub）、2026年、<https://github.com/n8n-io/n8n/blob/master/.github/DEVELOPING_V3.md>
9. Install with npm、n8nドキュメント、2026年10月、<https://docs.n8n.io/deploy/host-n8n/install-options/install-with-npm/>
10. n8nパッケージのメタデータ（dist-tagsとリリース日時）、npmレジストリ、2026年10月26日閲覧、<https://registry.npmjs.org/n8n>
11. Use Docker Compose、n8nドキュメント、2026年10月、<https://docs.n8n.io/deploy/host-n8n/install-options/install-using-docker-compose/>
12. One-line setup、n8nドキュメント、2026年10月、<https://docs.n8n.io/deploy/host-n8n/install-options/one-line-setup/>
13. Node.js Releases、Node.js、2026年10月21日更新、<https://nodejs.org/en/about/previous-releases>
14. Set the timezone、n8nドキュメント、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/set-the-timezone/>
15. Daylight Saving Time Rules、NIST、2026年、<https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst>
16. Time Zone Database、IANA、<https://www.iana.org/time-zones>
17. Security environment variables、n8nドキュメント、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/security/>
18. Read/Write Files from Disk node、n8nドキュメント、<https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.readwritefile/>
19. Use the command line、n8nドキュメント、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/use-the-command-line/>
20. HTTP Request credentials、n8nドキュメント、<https://docs.n8n.io/integrations/builtin/credentials/httprequest/>
21. RFC 6750: Bearer Token Usage、IETF、2012年、<https://www.rfc-editor.org/rfc/rfc6750>
22. EveryInfra OpenAPI（冪等キー、リプレイ、エラー）、EveryInfra、2026年10月26日閲覧、<https://api.everyinfra.com/openapi.json>
23. The Idempotency-Key HTTP Header Field、draft-08、IETF HTTPAPI WG、2026年10月22日、<https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/>
24. HTTP Request node、n8nドキュメント、<https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/>
25. getWorkflowStaticData、n8nドキュメント、<https://docs.n8n.io/build/code-in-n8n/cookbook/built-in-methods-and-variables-examples/getworkflowstaticdata/>
26. Convert to File node、n8nドキュメント、<https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.converttofile/>
27. Enable Prometheus metrics、n8nドキュメント、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/configuration-examples/enable-prometheus-metrics/>
28. n8n-scheduler Grafana dashboard、n8n-observability（GitHub）、<https://github.com/n8n-io/n8n-observability/tree/main/dashboards/grafana/n8n-scheduler>
29. EveryInfra機能カタログ、EveryInfra、2026年10月26日10:15（SGT）閲覧、<https://api.everyinfra.com/api/v1/social/catalog>
30. Hot search rules、Weibo、<https://m.s.weibo.com/hot/description>
31. RFC 9110: HTTP Semantics（422 Unprocessable Content）、IETF、2022年、<https://www.rfc-editor.org/rfc/rfc9110>
32. Handle errors gracefully、n8nドキュメント、<https://docs.n8n.io/build/flow-logic/handle-errors-gracefully/>
33. MCP Client node、n8nドキュメント、<https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-langchain.mcpclient/>
34. MCP Client Tool node、n8nドキュメント、<https://docs.n8n.io/integrations/builtin/cluster-nodes/sub-nodes/n8n-nodes-langchain.toolmcp>
35. MCP specification 2025-11-25: Transports、Model Context Protocol、<https://modelcontextprotocol.io/specification/2025-11-25/basic/transports>
36. Trends Recommendations、Xヘルプセンター、<https://help.x.com/en/resources/recommender-systems/trends-recommendations>
37. Set up task runners、n8nドキュメント、<https://docs.n8n.io/deploy/host-n8n/configure-n8n/set-up-task-runners/>
38. GHSA-qmvv-q3c9-wpp7: Credential Secrets Exposed in Execution Error Data、n8n（GitHub）、2026年10月14日、<https://github.com/n8n-io/n8n/security/advisories/GHSA-qmvv-q3c9-wpp7>
39. 5 Key Takeaways From Censys' State of the Internet Report、Censys、2026年10月14日、<https://censys.com/blog/state-of-the-internet-report-2026/>
40. Security update — 01 October 2026、n8nコミュニティ、2026年10月1日、<https://community.n8n.io/t/security-update-01-october-2026/318054>
41. Security update — 14 October 2026、n8nコミュニティ、2026年10月14日、<https://community.n8n.io/t/security-update-14-october-2026/321284>
42. Diagrid Brings Durable Execution to n8n（有料プレスリリース）、Business Wire（Yahoo Finance経由）、2026年10月6日、<https://finance.yahoo.com/technology/ai/articles/diagrid-brings-durable-execution-n8n-130000140.html>
43. ZoomInfo Launches Native Integration With n8n Through GTM.AI、Business Wire、2026年10月12日、<https://www.businesswire.com/news/home/20261012317239/en/ZoomInfo-Launches-Native-Integration-With-n8n-Through-GTM.AI>
44. 「Faltam 12 dias: consulte propostas das candidaturas que disputam o 2º turno」（決選投票まで残り12日：決選投票に臨む候補者の公約を確認）、ブラジル高等選挙裁判所、2026年10月13日、<https://www.tse.jus.br/comunicacao/noticias/2026/Outubro/faltam-12-dias-consulte-propostas-das-candidaturas-que-disputam-o-2o-turno>
45. n8nの実行は、処理したアイテムがゼロ件でも「Success」と表示されることがある、Reddit r/n8n、<https://www.reddit.com/r/n8n/comments/1xadlkd/an_n8n_execution_can_show_success_after/>