n8nで毎朝XとHacker Newsの24時間分をClaudeが要約し見出し承認だけで配信する仕組み

毎朝の情報収集を「見出し確認だけ」にする：n8n×Claude/DeepSeekで作る日次インテリジェンス・ダイジェスト自動化の設計と実装手順
なぜ今、”24時間ウィンドウ”に絞った情報収集が話題になっているのか
実装手順：「収集→整形→承認→配信」4段階の設計と具体的な設定ポイント
読者への実務上の意味と、今後注意すべき点
あわせて読みたい
まとめ：「見出し承認だけ」の半自動設計が、情報収集の質を上げる

毎朝の情報収集を「見出し確認だけ」にする：n8n×Claude/DeepSeekで作る日次インテリジェンス・ダイジェスト自動化の設計と実装手順

「X、Hacker News、ニュースレター……毎朝確認しているはずなのに、重要な情報を見逃している気がする」

こう感じている個人事業者やフリーランスの方は少なくないはずです。情報源が増えるほど、かえって”確認疲れ”が起きて、本当に価値のある情報をスルーしてしまう——これは多くの実務者が直面している矛盾です。

今回紹介するのは、n8nを使ってXとHacker Newsの直近24時間の投稿だけを収集し、ClaudeやDeepSeekで要約してTelegramまたはメールに配信する”日次インテリジェンス・ダイジェスト”自動化です。

ポイントは「完全自動」ではなく、「見出し承認だけ人間がやる」半自動設計にある点です。Hacker News単体の情報収集フローはすでに広く知られていますが、Xを正式な収集対象に加えた場合、リポストや重複の混入リスクが一気に上がるため、単一ソース向けの設計をそのまま流用すると事故につながります。この記事では、二つの情報源を安全に混ぜるための整形設計と、毎回・全件を見出しだけ承認する設計の巧みさを、実務レベルの解像度で解説します。

なぜ今、”24時間ウィンドウ”に絞った情報収集が話題になっているのか

n8nの公開ワークフローページやRedditの自動化コミュニティでは、2026年9月時点で、単純な「AIニュース要約」を超えた設計が活発に議論されています。

その中心にあるのが「24時間ウィンドウ」という時間軸の明示的な制御です。「最新情報を集める」という目的は同じでも、”いつからいつまでの情報か”を厳密に定義しない自動化は、実務では意外なほど破綻しやすい。

たとえば、UTC基準で24時間を判定すると、日本のJST（UTC+9）で運用する読者にとっては「今日の朝に届いたはずの情報が昨日扱われている」という時間軸のズレが生じます。配信先の読者のタイムゾーンで時刻判定を固定しないと、ダイジェストの鮮度感が損なわれるわけです。

さらに、AI要約の品質問題も議論の焦点になっています。リポスト（転載）や引用ツイートを含んだまま要約すると、同じ内容が複数回登場したり、元の文脈と異なる要約が生成されたりする問題が報告されています。これが「AI要約が雑になりやすい」と言われる主因です。

つまり、今話題になっているのは「AIで要約する」という話ではなく、収集・整形・承認・配信の4段階それぞれを丁寧に設計することの価値が、実務者の間で改めて認識されているということです。

次のセクションでは、この4段階を実際にどう組み立てるか、ステップごとに具体的な設定の考え方と注意点を解説します。

実装手順：「収集→整形→承認→配信」4段階の設計と具体的な設定ポイント

ステップ1：24時間以内の投稿だけを「正確に」収集する

まず最初の落とし穴が、タイムゾーンの固定です。

n8nのSchedule Triggerで毎朝7時（JST）に起動する設定にしたとしても、内部の時刻計算をUTCのままにしておくと、「直近24時間」の境界がJSTの0時ではなくUTCの0時（JSTの9時）になってしまいます。

実務上の推奨設定は以下のとおりです。

Schedule Triggerのタイムゾーン設定を「Asia/Tokyo」に固定する（n8nのワークフロー設定から変更可能）
収集の「開始時刻」と「終了時刻」を、変数として明示的にセットし、ログに残す（例：{{ $now.minus({hours: 24}).toISO() }} のような式を使う）
取得したデータの投稿日時フィールドを、収集時にJSTへ変換して保存しておくと、後工程でのデバッグが楽になります

Hacker Newsの場合は、Algolia HN Search APIのnumericFilters=created_at_i>{UNIXタイムスタンプ}というクエリパラメータで24時間以内の投稿に絞り込めます（UNIX時間はUTCなので、JSTへの変換は取得後に行います）。ここではHacker News単体の細かなスコア閾値の話には深入りせず、Hacker News単体では拾えない「Xでしか流れていない一次情報」をどう安全に混ぜるかにフォーカスします。

XのAPIの場合は、2026年時点のAPIプランによって取得できる件数や速度制限が異なるため、まず自分のAPIプランで1日に何件まで取得できるかを確認してから設計することを強く推奨します。件数が少ない場合は、Hacker Newsを主軸にしてXを補助的な情報源と位置づける設計が現実的です。ただし後述するとおり、Xを1件でも混ぜる場合はリポスト・重複の除去がHacker News単独運用よりもシビアに効いてきます。

ステップ2：重複排除と「原文投稿のみ」へのフィルタリング

収集した投稿をそのままAIに渡すのは、品質上の大きなリスクになります。

特に対処すべきは次の3つです。

リポスト・引用ツイートの除外：XのAPIレスポンスには referenced_tweets フィールドがあり、これが存在する投稿はリポストや引用である可能性が高いです。このフィールドの有無でフィルタリングし、オリジナル投稿のみを次工程に渡す設計にします
URL正規化による重複排除：Hacker Newsでは同じ記事へのリンクが複数スレッドから投稿されることがあります。URLのドメインとパスを正規化して比較し、重複を排除するn8nのCodeノードを挟むと有効です
キーワードによるノイズフィルタ：「宣伝」「スポンサー」「PR」などのキーワードを含む投稿を除外するリストを事前に用意し、条件分岐で弾く設計を入れておくと、AI要約の原料が安定します

この整形工程をn8nで実装する場合、Codeノード（JavaScript）を使って配列操作をするのが最も柔軟です。SwitchノードやFilterノードだけでは複雑な条件の組み合わせが難しくなるため、フィルタリングロジックはCodeノードにまとめて書いておくと、後のメンテナンスも楽になります。

ステップ3：ClaudeまたはDeepSeekでAI要約を生成する

整形済みのデータをAIに渡す工程です。ここで選択肢になるのがClaudeとDeepSeekです。それぞれの特性を実務視点で整理します。

Claude（Anthropic）：長文の文脈理解と、指示への忠実度が高いと言われています。「箇条書きで3点にまとめる」「英文を日本語に要約する」のような構造化指示との相性がよく、出力フォーマットが安定しやすいと考えられます。API料金はモデルによって異なりますが、日次で数十件の要約を処理する用途であれば、コストは比較的抑えられる可能性があります（実際の料金は公式サイトで最新情報を確認してください）
DeepSeek：コスト面での優位性が指摘されることが多く、大量の投稿を一括処理する場面でAPIコストを抑えたい場合の選択肢として挙げられています。ただし、日本語要約の品質やレイテンシーについては、自分のユースケースで実際にテストして確認することを強く推奨します

プロンプト設計で特に重要なのは、「出力フォーマットを固定する」ことです。

たとえば、以下のような構造を指定します。

見出し（30文字以内）
要約（100〜150文字）
情報源URL
重要度スコア（1〜5）

この出力をJSONで返させると、後工程のTelegramやメール送信ノードでのパース処理が格段に楽になります。また、文字数が極端に短い出力（たとえば50文字未満）が返ってきた場合はエラーとして扱う条件分岐を入れることで、空振り配信を防ぐことができます。

ステップ4：「見出し承認のみ手動」で速度と安全性を両立する配信設計

ここが今回の設計の最大の肝です。

完全自動配信は、誤配信リスクが高い。かといって全文を確認してから承認するのは時間がかかりすぎる。この矛盾を解決するのが「見出しだけ承認」という設計です。

具体的なフローは以下のとおりです。

AI要約が完了すると、見出しと重要度スコアのみをTelegramやSlackに送信する（配信前の承認用チャネルを別に用意する）
承認者が「OK」または「スキップ」を返信する（TelegramのBotであれば、インラインボタンで実装可能）
OKが出た見出しだけを含むダイジェストを、最終的な配信先（メールまたは別のTelegramチャネル）へ送信する

この設計のメリットは、確認にかかる時間が1件あたり数秒で済む点です。見出しと重要度スコアだけなら、10件のダイジェストでも1〜2分で承認できます。

似た半自動設計として、「件数が閾値を超えた日だけ人間が確認し、それ以外の日は自動配信する」という例外ベースの承認も考えられます。運用の手間はこちらの方が少なく済みますが、閾値以下の日にAI要約が誤っていても誰も気づけないという盲点が残ります。今回のように毎回・全件を見出しだけ承認する設計にしておくと、確認の手間はわずかに増える代わりに、AI要約の異常に気づけるタイミングが「閾値を超えた例外日」ではなく「毎日」になります。Xのような速報性の高い情報源を混ぜるほど、この違いは効いてきます。

また、配信停止条件をワークフローに組み込むことも重要です。以下のいずれかに該当する場合は、自動配信をストップして通知だけ送る設計にしておくと安心です。

収集できた投稿が5件未満（情報量不足）
重複率が50%を超えている（フィルタが機能していない可能性）
AI要約の平均文字数が50文字未満（API応答に問題がある可能性）

配信停止条件の3つの数値（収集5件未満・重複率50%超・要約文字数50文字未満）は、最初は経験に基づいた仮の値として設定していました。運用を始めて2週間ほど経った頃、重複率の条件に一度だけ引っかかり、通知だけが届いて配信が止まった日があります。ログを確認すると、Hacker Newsで同じ技術系ニュースが複数スレッドから投稿されており、クエリパラメータだけが違うURLがURL正規化のロジックをすり抜けていたことが原因でした。数値を決めて終わりにするのではなく、実際に停止条件が発動した日のログを必ず見返し、フィルタのルール自体を細かくする作業をセットにするようにしてから、同じ理由での停止は起きなくなりました。

読者への実務上の意味と、今後注意すべき点

「配信先は最初の1チャネルに絞る」が失敗しないコツ

自動化ワークフローを作り始めると、「TelegramにもメールにもSlackにも流したい」という欲が出がちです。しかし、最初から複数チャネルへ流すと、どのチャネルが有効かの判断ができなくなります。

推奨するのは、まず1チャネル（Telegramかメールのどちらかを選ぶ）に絞り、2〜4週間運用して「クリック率」「保存率」「返信や反応の有無」を観察してから、拡張するかどうかを判断することです。

Telegramは、BotのAPIが比較的使いやすく、インラインボタンによる承認フローとの相性もよいため、最初の配信先としてはTelegramを選ぶ方が設計しやすいと考えられます。メールの場合は、HTMLフォーマットのダイジェストが作れる反面、承認フローを組むためにはWebhookやフォームとの連携が必要になり、初期設計の複雑さが上がります。

完全自動化への”誘惑”と、人間の判断を残す設計思想

自動化が軌道に乗ると、「承認ステップも外してしまいたい」という気持ちになることがあります。これは理解できる反応ですが、外部へ発信するコンテンツにおいては、人間の承認を最後まで残しておくことを強く推奨します。

特に、AIが要約した情報を自分のSNSやニュースレターで再発信する場合、要約の誤り・文脈の欠落・不適切な表現が含まれるリスクはゼロにはなりません。「見出し承認のみ」という設計は、速度を落とさずにこのリスクを最小化する現実的なバランス点です。

この設計の考え方は、当サイトで以前紹介した「AIにワークフローの下書きを任せ、人間が承認3点だけ握る半自動設計」とも共通する思想です。自動化は「人間の仕事をゼロにする」ためではなく、「人間が最も価値を発揮できる判断だけに集中できるようにする」ために使う、というスタンスが長続きのコツだと思っています。

今後の注目点：X APIの制限変更とコスト影響

X（旧Twitter）のAPIは、2026年9月時点でもプランや料金体系の変更が続いているとされています。特に無料・低価格プランでの取得件数制限が厳しくなっている可能性があり、Hacker Newsを主軸にしてXを補助的な情報源とする設計が、コストとリスクのバランスとして現実的な選択肢になっている可能性があります。

また、DeepSeekをはじめとするAPIの価格変動も、今後のコスト設計に影響する可能性があります。AIのAPI料金は変動しやすいため、ワークフロー設計時には「AIプロバイダーを差し替えやすい構造」にしておくことが重要です。n8nでAIノードを使う場合、APIキーと接続先を設定から切り替えられるように整理しておくと、後の移行コストを下げられます。