非エンジニアによる技術ブログ（仮）
よみじかん 約10分

n8nを触ったら、自作ツールの複雑さと自動化の穴が見えた

n8n自動化ノーコードai活用非エンジニア

n8nというノーコードの自動化ツールを、遊びのつもりで触ってみました。結論から言うと、作ってみた上で「これは使わない」と判断しました。

ただ、この遠回りは無駄ではありませんでした。ノーコードで同じものを組もうとしたことで、自分が前に書いたPythonのツールが、黙ってどれだけのことをやっていたのかが初めて見えたからです。しかも測っている最中に、そのツールの穴まで見つかりました。

何を作ったのか

私はAI関連のニュースを自動で集めてメールで送る仕組みを、以前Pythonで自作して毎日動かしています。今回はその「ミニ版」をn8nで作ってみることにしました。

作ったのは3つのノードだけです。

RSS Feed Trigger  →  Filter  →  Gmail
（記事を取ってくる）（絞り込む）（メールを送る）

n8nはブラウザだけで完結するので、環境構築はゼロでした。無料トライアルに登録して、画面上でノードを線でつないでいくだけです。ノードの意味をAIに聞きながらでしたが、10分ほどで実際に自分宛てにメールが届くところまで行きました。

最初に届いたメールは、タイトルと本文とURLが改行なしで一続きになっていて読めたものではありませんでしたが、式の間に空行を入れ直したらきれいになりました。書く、動かす、届いたものを見る、直す。このループが速いのは素直に気持ちよかったです。

つまずいた1: Filterは「拾う」のではなく「捨てる」

Filterというノードは、条件に合うものだけを通す関所です。ここで最初、私は勘違いをしていました。

「タイトルに OpenAI を含む記事だけ取ってくる設定」だと思っていたのです。実際は違いました。

RSS Feed Trigger        Filter              Gmail
 新着アイテムを出力  →  条件で選別   →  通ったものだけ
                       （残りはここで消える）

**Filterは、上流が取ってくる量を減らしません。**RSS Feed Triggerが出力した新着アイテムを、後ろに立った関所が1件ずつ見て捨てているだけでした。だから条件をどう厳しくしても、フィードを見に行く動作そのものは変わりません。

地味ですが、これは実務では効いてきます。n8nの課金対象である実行回数は、処理した件数やノードの数によらず「ワークフローが1回動いた」として数えられます。つまり条件を厳しくしても、請求は減りません。「絞り込んだから軽くなったはず」という直感が、そのまま裏切られる場所です。

（なお今回私が実際に流したのは1件だけなので、大量の記事が絞り込まれていく様子そのものは見ていません。）

つまずいた2: アイテムは1件ずつ処理される

もう一つ、n8nの根っこにある性質でつまずきました。n8nのノードは、受け取ったアイテムの配列に対して、設定した操作を1件ずつ適用します。

つまりGmailの「送信」に5件のアイテムが渡れば、送信操作も5件になります。メールが5通飛ぶ計算です。

ただしこれは公式のデータモデルから導いた推論で、今回の私は1件しか流していないので、5通飛ぶところを実際に見たわけではありません。

自作のPythonツールは「全部集めてから1通のメールにまとめる」作りだったので、感覚がまるで違いました。まとめたい場合は、Aggregateという「複数を1つに畳む」ノードを別途挟む必要があります。

そしてこの性質は、後でお金の話に直結します。要約のためにAIを挟むとして、畳む前に置けば記事ごとにAPIを呼び、畳んだ後に置けば1回で済みます。**ノードをどこに置くかが、そのまま請求額と品質のトレードオフになる。**絵で組み立てているだけのつもりが、実はコスト設計をしていた、というのが面白いところでした。

自作ツールは、思っていたより多くのことをやっていた

ここまで来て、いよいよ本題です。「同じものをn8nで作るなら、あと何が要るんだろう」と考えて、自分のPythonコードを読み直しました。

出てきた工程は6つでした。

  1. RSSを9本から取得する
  2. 既に送った記事を除外する
  3. 記事のURLを開いて、本文を取ってくる
  4. 記事ごとにAIで日本語の要約を作る
  5. 見出しを付けて1通のメールに組み立てる
  6. 送信する

3番目に自分で驚きました。RSSに含まれている短い抜粋ではなく、わざわざ記事ページを開いて全文を取りに行っていたのです。書いた本人が忘れていました。

もう一つ、細かいですが発見がありました。私は「英語のニュースを翻訳してから、要約している」と思い込んでいたのですが、コードを見たら翻訳と要約は1回のお願いで済ませていました。AIに「英語の場合も含めて、日本語で3〜5行に要約して」と頼むだけです。翻訳という工程は、そもそも存在していませんでした。

これをn8nで再現するとどうなるか。少なくとも、Gmailの手前に挟むのはAIノード1個では足りません。「記事ページを取ってくる（HTTP Request）」「本文を抜き出す（HTML）」「AIで要約する」の3つに加えて、最後に畳むAggregateが要ります。

正直なところ、私は再現版を実際には組んでいないので、最終的なノード数までは分かりません。9本のフィードをどう取り込むか、既読の除外をどう作るかで変わってきます。それでも、3ノードで済んだミニ版と比べて、必要な処理がはっきり増えることは数えるだけで見えました。

Pythonならファイル1枚で済んでいることが、ノーコードだと相応の大きさの絵になる。しかもAIを使うための鍵は、結局自分で用意することになります。

だから私は、既存のツールをn8nに置き換えるのはやめました。

使わないと決めましたが、適所は見えました

念のため書いておくと、これは「n8nが良くない道具だった」という話ではありません。今回の用途に合わなかっただけです。触ってみて、どこでなら効くのかははっきりしました。

n8nが効くのは、別々のツールの間で、人が手でコピーして貼り付けている作業です。業務フローを描いて「人がコピペしている矢印」を探すと、候補が見つかります。

ただし条件が一つあります。その矢印に人の判断が乗っていないこと。「Aに来たものは全部Bへ」なら置き換えられますが、「重要そうなものだけBへ」だと話が変わります。その「重要そう」をどう表現するかが本題になってしまい、n8nは主役ではなくなるからです。

今回、Filterに「タイトルに OpenAI を含む」と書いた作業は、まさに自分の判断をルールに落とし込む作業でした。**ノーコードが自動化してくれるのは移動の部分だけで、判断の部分は自分で設計するしかない。**ここは手を動かして初めて分かりました。

私のニュース収集ツールは、9本のフィードから集めて、本文を取って、要約して、1通にまとめる。移動というより加工が主役でした。合わないのは当然だったわけです。

それでも収穫はあった: 自分のツールの穴が見つかった

ここからが、この記事で一番書きたかったことです。

n8nに入れるフィードのURLを、自作ツールから借りてくることにしました。せっかくなので9本すべてが生きているか、コマンドで叩いて確認してみたのです。

8本は正常。1本だけ、404で死んでいました。

Anthropicのフィードでした。よくある別のURLもいくつか試しましたが、すべて404。ニュースページの中を見ても、フィードの場所を示すタグはありませんでした。正確に言うと、2026年7月時点で私が確認した範囲では、使える公式RSSフィードを見つけられなかったということです。配信終了の告知そのものは見つけていません。

問題は、そこではありません。私がそれに、一度も気づいていなかったことです。

気になって、自分のツールが吐き出していたログを最初から数え直しました。記録は7月2日の運用開始から7月25日まで、23日間で71回の実行分が残っていました。媒体ごとに拾えた記事の数を数えると、こうなりました。

媒体拾えた記事数
TechCrunch AI172
The Decoder160
MIT Tech Review53
OpenAI41
Hugging Face31
Google DeepMind16
Google AI Blog15
VentureBeat AI12
Anthropic0

**23日間、71回動いて、1件も取れていませんでした。**その間ずっと、メールは毎日ちゃんと届いていました。

考えてみれば当たり前でした。9本のうち1本が黙って0件を返しても、残り8本が記事を運んでくるからです。エラーで止まるわけでもない。成功しているように見えていたのです。

人力でやっていた頃なら気づけたはずです。「今日はこのサイト見てないな」と手が覚えているからです。ところが流れを一本につないだ瞬間、その感覚が消えます。

自動化の代償は「壊れても気づかなくなる」こと

自動化して手間が減ったのは事実です。私のツールは毎日9本のフィードを見に行って、要約して、1通にまとめてくれていました。その分の作業は、たしかに私の手から消えています。

ただ、今回それと一緒に受け取ったものがありました。手間が減る側だけでなく、正常に見えたまま何も来ていない状態も、設計の対象になるということです。

流れをつなぐと、途中が切れても正常に見えます。

ここで一つ、自分でも整理がついていなかった点があります。「エラー通知を付ければいいのでは」と思ったのですが、それでは今回の穴は捕まりません。

n8nにはError Triggerという、ワークフローが失敗したときに動く仕組みがあります。ただし今回の問題は、失敗していないのです。取得元が0件を返しても、ワークフローは最後まで走り切って成功します。エラー通知は鳴りません。

つまり必要なのは2種類です。

  • 落ちたことに気づく仕組み … エラー通知。これは最初から用意されている
  • 落ちていないのに何も来ていないことに気づく仕組み … 取得元ごとの件数や最終取得時刻を検査して、0件が続いたら能動的に失敗させるか通知する。これは自分で作るしかない

自動化するときに本当にセットで設計しなければいけないのは、後者の方でした。「動いていること」ではなく「静かに何も起きていないこと」を見張る側です。

素人の自動化とプロの自動化の差は、たぶんここにあります。私はいま、はっきり前者でした。

まとめ

  • n8nは3ノードで動くところまで10分（AIに聞きながら）。ブラウザだけで完結して、試行錯誤は速い
  • ただし「アイテムは1件ずつ処理される」「Filterは上流の取得を減らさず、後から捨てる」という前提を知らないと、素直に事故る
  • 同じものを組もうとして、自作ツールが6工程もこなしていたことが初めて見えた。ノーコードは、既にあるものの複雑さを測る物差しとしてよく効く
  • そして測っている最中に、自分のツールのフィードが1本、23日間まったく取れていなかったことが分かった。自動化すると、壊れても気づかなくなる

道具としては採用しませんでしたが、自分の作ったものを測り直せたので、触った価値は十分ありました。次は死んだフィードの直しと、静かに何も起きていないことに気づく仕組みの方をやります。