n8nでAIニュース収集から LinkedIn下書きまで全自動化する個人運用フロー

「情報収集→要約→投稿下書き」を全部自動化：n8nで作るAIニュース発信ワークフローの設計と実装
なぜ今、n8nによる「半自動発信フロー」が注目されているのか
1. 「全自動」ではなく「半自動」が個人にちょうどいい理由
2. 「RSSまとめ」との本質的な違い
n8nワークフローの具体的な設計手順と注意点
類似手段との比較：n8nを選ぶ場面・選ばない場面
1. Zapier・Makeとの違い
2. 「もし自分がこのワークフローを設計するなら」の改善アイデア
このワークフローが個人発信者にとって持つ実務的な意味
あわせて読みたい
まとめ：「毎日動く仕組み」を一度作ることで、発信は習慣ではなくインフラになる

「情報収集→要約→投稿下書き」を全部自動化：n8nで作るAIニュース発信ワークフローの設計と実装

「AIの最新情報は追いたい。でも、調べて、まとめて、投稿文を考えて…と積み上げると、それだけで1〜2時間が消えてしまう」

SNSで情報発信を続けている個人・フリーランス・小規模事業者なら、このジレンマは共感できるはずです。

情報収集を怠ると発信が止まる。発信を続けようとすると情報収集に時間が取られる。どちらを優先しても、どこかで無理が生じます。

今回紹介するのは、n8nというワークフロー自動化ツールを使い、「ニュース収集→24時間フィルタ→要約→SNS投稿文の下書き→人間の承認→公開」という一連のフローを半自動化するアーキテクチャです。

2026年8月時点で、RedditのAI・自動化コミュニティ（r/n8n）で活発に議論されているトピックであり、単なる「RSSをまとめるだけ」ではなく、直近24時間以内の記事に限定してLLMに処理させる実運用に落とし込まれている点が、浅いまとめ記事との大きな違いです。

この記事では、なぜこの設計が個人運用にフィットするのか、具体的なワークフローの組み方と注意点、そして「設計者視点での改善アイデア」まで、実務レベルの解像度で解説します。

なぜ今、n8nによる「半自動発信フロー」が注目されているのか

「全自動」ではなく「半自動」が個人にちょうどいい理由

自動化ツールを使った情報発信と聞くと、「全部AIに任せて自動投稿」を想像する人も多いでしょう。しかし、個人・小規模チームの実運用において、全自動投稿は事故リスクが高く、実際に破綻しやすいという課題があります。

誤情報を含む記事を無加工で引用してしまう、文脈がズレた要約がそのまま拡散する、自分のブランドと合わないトーンで投稿が出てしまう。こうした事故は、信頼回復に想像以上の時間がかかります。

だからこそ、r/n8nコミュニティで話題になっているのは「最後の承認ステップだけを人間が担う半自動化」という設計です。AIが下書きを作り、人間が内容を確認してから公開する。この一点だけ手を残すことで、発信の品質担保と時間節約を同時に実現できます。

「RSSまとめ」との本質的な違い

以前から存在する「RSSフィードをまとめてメールで届けるツール」と、今回のn8nワークフローの違いは何でしょうか。

最大の違いは「24時間フィルタ」と「LLMによる2段階処理」の組み合わせにあります。

単なるRSSまとめは、数日前の記事も古い記事も一緒に流れてきます。情報過多になり、結局読まずに放置するという状態に陥りがちです。一方、n8nで「直近24時間以内に公開された記事のみ」を抽出するフィルタを入れることで、「今日発信する価値がある情報」だけを処理対象にできます。

さらに、RSSまとめはリンクとタイトルを送るだけですが、n8nにOpenAIやAnthropicのAPIを組み合わせれば、記事の事実要約とSNS投稿文の下書きを自動生成できます。情報を受け取るだけでなく、「今すぐ使える形」に変換して届けてくれる点が、本質的な違いです。

情報収集自体は習慣化できても、「そこから投稿文を作る」という変換作業がボトルネックになりやすいのは、多くの発信者が感じている共通の詰まりポイントです。ここを自動化の射程に入れるだけで、発信ペースは大きく変わる可能性があります。

n8nワークフローの具体的な設計手順と注意点

全体の設計思想：「悪い入力は最初に止める」

ワークフローを設計する前に、一つ重要な考え方を押さえておきましょう。

「処理の後半でエラーが出るより、入力段階で弾く設計のほうが、個人運用では圧倒的に安定する」ということです。

n8nのワークフローは、動いているように見えて「新着0件なのにLLMへリクエストを投げてAPIコストが発生し続ける」「重複記事を毎日要約して同じ内容が下書きに溜まる」という無駄な動作が起こりやすいです。こうした問題を最初の条件分岐で止める設計を先に作ることが、「毎日動いているのに使えない」状態を防ぐ鍵になります。

Step 1：情報ソースは3本に固定する

最初にやるべきことは、RSSや公式ブログなど信頼できるソースを3つだけに絞ることです。

「情報を増やすほど良い」と思いがちですが、ソースが多いほどノイズが増え、LLMへの入力量が増え、要約の質も下がります。個人運用では特に、処理量と品質はトレードオフになりやすいです。

AI系メディア（例：TechCrunch AI、VentureBeat AI）
特定ツール・プラットフォームの公式ブログ
自分の専門領域に近いニッチなニュースレター

この3本を決めたら、n8nの「RSS Feed Read」ノードをそれぞれに設定し、後続処理に流します。ソースを増やしたくなったら、古い1本と入れ替える形で運用するのが安定します。

Step 2：24時間フィルタを「最初の関門」として置く

RSS取得の直後に、「公開日時が現在から24時間以内かどうか」を判定するIfノードを必ず入れてください。

n8nのIfノードでは、記事のpubDateフィールドを現在時刻と比較する条件式が使えます。条件を満たした記事だけを次のノードに流し、古い記事はそこで処理を止めます。

注意点として、新着記事が0件だった場合の処理を必ず作っておくことが重要です。0件のまま後続のLLMノードに流れると、空のプロンプトでAPIコールが発生する場合があります。Ifノードの「False」側に「実行をここで終了」するノードを繋いでおくだけで防げます。

Step 3：LLM処理は「要約」と「投稿文生成」を2回に分ける

ここが設計の中で最も重要なポイントです。

いきなり「この記事を読んでSNS投稿を作れ」とプロンプトを1回で投げるより、「まず事実を要約させる→次にその要約からSNS投稿文を作らせる」という2段階にするほうが、出力の品質が安定します。

1段階目のプロンプト例（要約ノード）：

「以下の記事本文から、最も重要な事実を3点、箇条書きで日本語で要約してください。意見や推測は含めないでください。」

2段階目のプロンプト例（投稿文ノード）：

「以下の要約をもとに、LinkedInに投稿する250文字前後の日本語投稿文を作成してください。専門家らしい口調で、読者に価値を感じさせる書き出しにしてください。」

1段階目で「事実だけの要約」を固めることで、2段階目の投稿文にファクトのズレが混入しにくくなります。2段階に分ける分、APIコールが1回増えますが、品質の安定性という観点ではこのコストは払う価値があると考えられます。

Step 4：承認フローを「メール通知」で実装する

生成された下書きを自動投稿するのではなく、まずメールやSlackに「確認待ちの下書き」として送る設計にします。

n8nであれば、SendGridやGmail、Slackのノードを使って通知を飛ばせます。メール本文に「記事タイトル」「要約3点」「投稿下書き」を含めておくと、スマホから確認して承認・却下の判断が30秒でできます。

承認後の実際の投稿操作は、最初は手動でも構いません。まず「下書きが毎朝届く状態」を作ることを優先し、投稿操作の自動化は運用が安定してから検討するのが、個人・小規模事業者にとって最もリスクが少ないアプローチです。

Step 5：失敗しやすい3つの条件分岐を先に組み込む

最後に、運用開始前に必ず以下の3つのガード条件を入れておきましょう。

新着0件なら通知しない：処理対象が0件の場合は全体の処理を止め、不要な通知やAPIコールを防ぐ
重複URLを除外する：過去に処理した記事のURLをGoogle SpreadsheetやNotionのデータベースに記録し、再処理を防ぐ（n8nのSet/Merge/FilterノードとSpreadsheetノードで実装可能）
記事が極端に長い場合はスキップまたは冒頭のみ処理：LLMのコンテキスト制限を超える記事は要約品質が落ちるため、文字数が一定以上の場合は冒頭1,500文字のみを対象にするか、処理対象外とする

この3条件は「後から問題になってから対処する」より「最初から組んでおく」ほうがはるかに工数が少ないです。特に重複除外は、実装し忘れると同じ記事の投稿下書きが毎日届くという状態になりやすく、運用モチベーションを損ないます。

このブログの自動化でも、似たような重複防止の仕組みを入れています。過去に使ったタイトルの履歴をWordPressから取得して、新しいタイトルを作る前にAIに参照させるようにしています。この一手間がないと、気づかないうちに同じような記事を何度も生成してしまうということが、実際に何度か起きていました。

類似手段との比較：n8nを選ぶ場面・選ばない場面

Zapier・Makeとの違い

同様のワークフロー自動化ツールとして、ZapierやMake（旧Integromat）が挙げられます。それぞれの特性を整理すると以下のようになります。

Zapier：UIが最もシンプルで導入ハードルが低い。一方、複雑な条件分岐や2段階LLM処理を実装しようとするとプランのアップグレードが必要になりやすく、コストが上がりやすい
Make：視覚的なフロー設計がわかりやすく、中程度の複雑さなら無料〜低価格帯で運用しやすい。n8nよりも学習コストが低い傾向がある
n8n：セルフホスト版（無料）とクラウド版がある。カスタムコードノード（JavaScript/Python）が使えるため、柔軟な条件分岐や独自処理を組みやすい。今回のような「重複URL管理」「文字数による条件分岐」はn8nが最も実装しやすいと考えられる

コストの観点では、n8nのセルフホスト版（VPSに立てる場合）は月額1,000〜2,000円程度のサーバー代のみで運用できる可能性があります。ただしサーバー管理の知識が必要になるため、技術的なハードルを感じる場合はn8nのクラウド版（Starter相当のプランから）から始めるほうが現実的です。

発信を止めずに実験したい段階では、Makeで概念を検証し、本格運用に移行する際にn8nに乗り換えるという順序も合理的な考え方です。

「もし自分がこのワークフローを設計するなら」の改善アイデア

実務的にさらに一歩踏み込むとしたら、以下の拡張が有効だと考えられます。

要約にスコアリングを加える：「この記事は自分のターゲット読者にとってどの程度関連性があるか1〜5でスコアをつけよ」というプロンプトを追加し、スコア3以上の記事だけを下書き生成対象にする。関連記事スコアリングの応用については、Grokで24時間トレンドを要約させる運用術も参考になります
曜日・時間帯でスケジュールを変える：月曜は「週のAIトレンドまとめ」、水・金は「単発ニュース投稿」というように、配信する曜日によって出力フォーマットを変えると、受け取る側のエンゲージメントが高まる可能性があります
却下した下書きを学習データとして蓄積する：「なぜ却下したか」の理由をメモとして残し、月次でプロンプトを見直す仕組みを作ると、出力品質が継続的に向上します

このワークフローが個人発信者にとって持つ実務的な意味

「情報収集→要約→投稿作成」という作業は、個人発信者にとって「重要だがすぐに後回しにされる」タスクの典型です。

重要性は理解している。でも毎日続けるのが難しい。だからこそ、「習慣として定着させる」のではなく「動き続ける仕組みとして設計する」という発想の転換が、このワークフローの本質的な価値です。

ただし、注意しておくべきことがあります。このワークフローはあくまで「下書きの生成」までを担うものです。承認と公開は人間が行い、投稿後の反応を見てプロンプトや情報ソースを定期的に見直す作業も発生します。「一度設定したら何もしなくていい」という性質のものではなく、月に1回程度のメンテナンスを前提に設計しておくことが、長期安定運用の条件だと考えられます。

また、自動生成された要約はあくまで補助的な情報整理であり、その内容の正確性の最終確認は運用者自身が担う必要があります。承認ステップをきちんと機能させることが、このフローの品質担保の要です。