前回は、OpenAI、Anthropic、Google Gemini、Canva、n8n、Dify、WordPressなど、10種類の公式情報源を「自分専用AI週報」に集めた方法をお伝えしました。
情報源を増やすと、今度は別の課題が出てきます。
それが、同じニュースを何度も送ってしまう問題です。
- たとえば、毎週月曜日に「自分専用AI週報」を送るとします。
- 先週公開された記事が、今週も直近の更新として取得されることがあります。
- また、同じ内容が、複数の公式情報源から見つかる場合もあります。
仕組みとしては正常に動いていても、毎週同じニュースが届くと、読む側にとっては少しずつ負担になります。
そこで「自分専用AI週報」では、過去に扱った候補や、その週の中で重複した候補を減らす仕組みを入れることにしました。
今回は、n8nで同じAIニュースを二度送らないために考えたことと、重複送信を防ぐ仕組みをお伝えします。
この記事の要約
- 週次の自動配信では、同じニュースを繰り返し送らないための仕組みが必要です。
- 「自分専用AI週報」では、記事ごとに重複判定用の識別子を持たせています。
- 同じ実行内の重複と、過去30日間に扱った候補の重複を分けて確認する設計にしました。
- Manual Triggerによるテストでは、送信履歴を更新しないようにしています。
なぜ重複送信を防ぐ必要があるのか？
ニュースを週1回だけ送るなら、重複はあまり問題にならないように見えるかもしれません。
ですが、実際に運用すると、同じ記事が候補に残り続けることがあります。
取得期間に、少し余裕を持たせているからです。
「自分専用AI週報」では、週ごとの境目で情報を取りこぼしにくくするため、直近8日間の更新を対象にしています。
毎週7日ごとに動く仕組みで、8日間を確認すれば、前回と今回で1日分ほど候補が重なります。
これは、取りこぼしを防ぐためには役立ちます。
一方で、先週紹介した記事が、今週も候補に入る可能性があります。
また、同じニュースが、公式ブログとGitHub Releasesの両方に出ることもあります。
そこで必要になるのが、「これはすでに扱った候補か？」を判断する仕組みです。
重複には2種類あります
「自分専用AI週報」で考えた重複は、1種類ではありません。
大きく分けると、次の2種類があります。
| 重複の種類 | 起きる場面 | 対応 |
|---|---|---|
| 同じ実行内の重複 | 複数の情報源から、同じ記事が見つかる | 1回の実行の中で、2件目以降を除外する |
| 過去の送信との重複 | 先週扱った記事が、今週も候補に入る | 送信履歴と照合して除外する |
この2つを分けて考えることで、仕組みが分かりやすくなります。
同じ実行内の重複は、「今、集めた候補の中で同じものがないか？」を見る処理です。
過去との重複は、「以前に扱ったものが、また入ってきていないか？」を見る処理です。
記事ごとにuniqueKeyを持たせました
重複を判断するには、記事ごとに「これは同じ記事です」と見分けるための目印が必要です。
そこで「自分専用AI週報」では、候補ごとにuniqueKeyという識別子を持たせています。
難しく見えるかもしれませんが、役割はシンプルです。
- 記事に付ける、重複確認用の番号札
です。
RSSやSitemapから取得した記事では、主にURLを整えたものを使います。
たとえば、URLの末尾に付く不要な記号や、計測用の文字列などをできるだけ整理し、同じ記事なら同じ目印になるようにします。
GitHub Releasesのような情報では、リポジトリ名とリリース番号などを組み合わせます。
| 情報の種類 | 重複判定の考え方 |
|---|---|
| ブログ記事・ニュース | 整えたURLを使う |
| Sitemap由来の記事 | 整えたURLを使う |
| GitHub Releases | リポジトリ名とリリース情報を組み合わせる |
これにより、情報源が違っても、同じURLの記事であれば「同じ候補かもしれない」と判断しやすくなります。
まずは、同じ実行の中で重複を減らします
情報源を10種類まで増やすと、同じ内容に近い更新が複数入ってくる可能性があります。
そのため、Geminiへ候補を渡す前に、同じuniqueKeyを持つ候補を確認します。
- 最初に見つかった候補は残します。
- 2件目以降に見つかった同じ候補は、Geminiへ渡さないようにします。
こうしておくと、Geminiが同じ記事を何度も読んだり、同じ内容を何度も紹介したりしにくくなります。
情報源を増やした目的は、同じニュースを増やすことではありません。
見落としを減らすことです。
だからこそ、情報を集めた後に、余分な重なりを減らす必要があります。
次に、過去30日間の送信履歴と照合します
同じ実行内の重複を減らしても、先週紹介した記事が今週また候補に入る可能性は残ります。
そこで「自分専用AI週報」では、過去に扱った候補の履歴を一定期間残すことにしました。
保存期間は、ひとまず30日間です。
30日間にした理由は、同じニュースを短期間に繰り返し送らないためです。
一方で、何年も前の履歴まで残し続ける必要はありません。
AIツールは変化が速く、1か月前の記事でも、状況が変わっていることがあります。
そこで、古い履歴は少しずつ整理しながら、最近扱った候補だけを確認する設計にしました。
送信履歴はWorkflow Static Dataに保存します
n8nには、ワークフローの中で使う小さな保存領域があります。
今回の「自分専用AI週報」では、この保存領域を使って、送信済み候補の履歴を残す設計にしました。
保存するのは、主に次のような情報です。
- 重複判定用のuniqueKey
- 候補を扱った日時
- 履歴の保存期間
- 最終更新日時
ここで重要なのは、記事本文を丸ごと保存することではありません。
「この候補は、すでに扱ったか？」を確認できれば良いので、必要最小限の情報だけを残します。
仕組みを作るときは、何でも保存すれば良いわけではありません。
あとで判断に必要な情報だけを残す方が、管理しやすくなります。
Manual Triggerでは、履歴を更新しないようにしました
ここは、今回の仕組みで、特に大切にした部分です。
n8nでは、Manual Triggerを使うと、画面上から手動でワークフローを実行できます。
これは、情報取得やGeminiの出力を確認したいときに便利です。
ただし、手動テストの結果まで送信履歴として保存してしまうと問題が起きます。
たとえば、テスト中に取得した候補が「送信済み」として記録されるとします。
すると、本番の定期実行では、その候補が除外される可能性があります。
実際には本番でまだ紹介していないのに、紹介済みとして扱われてしまいます。
そこで「自分専用AI週報」では、Manual Triggerによる実行では、履歴を更新しない設計にしました。
| 実行方法 | メール送信 | 履歴の更新 |
|---|---|---|
| Manual Trigger | Gmailノードまで進めば送信される可能性がある | 更新しない設計 |
| Schedule Trigger | 定期実行として送信する | 更新する設計 |
Manual Triggerは、あくまで安全なプレビューではありません。
Gmailノードまで処理が進めば、メールは送信されます。
だから、テストでは送信先や実行範囲を確認する必要があります。
ただし、履歴については、本番と混ざらないように分けることができます。
手動テストで確認できたこと
今回、Manual Triggerで実際に「自分専用AI週報」を動かして確認しました。
その結果、次のようなことを確認できました。
- 送信履歴がない状態から処理を開始できた
- 重複候補を除外する処理を通せた
- Geminiへ渡す候補の一覧を作れた
- Gmailでテストメールを送信できた
- Manual Triggerでは、送信履歴を更新しない結果を確認できた
このとき、Geminiへ渡す候補は、数十件ありました。
同じ実行内で除外された重複候補は0件でした。
これは、重複が常に0件になるという意味ではありません。
その時点の情報源と取得結果では、同じuniqueKeyを持つ候補が見つからなかったということです。
仕組みは、重複があるときに備えて作っておくものです。
この仕組みにも、まだ限界があります
重複送信防止の仕組みを入れたことで、同じURLの記事を繰り返し送る可能性は減らせます。
ただし、すべての重複を完全に見つけられるわけではありません。
- たとえば、同じ内容でも、別のURLで公開された場合があります。
- URLが変われば、別のuniqueKeyとして扱われる可能性があります。
また、今回の仕組みでは、Geminiへ渡した候補を履歴として保存する設計です。
Geminiが最終メール本文で採用しなかった候補も、一定期間は再候補になりにくくなります。
これは、今後改善できるポイントです。
将来的には、メール本文に実際に採用された記事だけを記録する方法も考えられます。
ただ、最初から完璧な重複判定を作ろうとすると、仕組みが複雑になりすぎます。
- まずは、同じURLの候補を短期間で繰り返し送らない。
そのための最小限の仕組みから始めることにしました。
重複送信防止は、読者への配慮でもあります
自動化を作ると、「動くこと」に注目しがちです。
ですが、メールを受け取る側にとって大切なのは、毎週役立つ情報が、読みやすい量で届くことです。
- 同じニュースが何度も届けば、少しずつ開封する気持ちが下がります。
- 反対に、「今週はこれだけ見れば良い」と感じられれば、週報は習慣になります。
重複送信防止は、技術的な工夫です。
同時に、読む人の時間を守るための工夫でもあります。
「自分専用AI週報」は、情報をたくさん届けるための仕組みではありません。
毎週の判断を少し楽にするための仕組みです。
まとめ
- 週次の自動配信では、同じニュースを繰り返し送らないための仕組みが必要です。
- 「自分専用AI週報」では、候補ごとにuniqueKeyを持たせて重複を確認します。
- 同じ実行内の重複と、過去30日間に扱った候補との重複を分けて確認しています。
- Manual Triggerでは、テスト結果が本番の履歴に混ざらないよう、履歴を更新しない設計にしました。
- 重複送信防止は、仕組みを安定させるだけでなく、読む人の時間を守る工夫でもあります。
次回は、「自分専用AI週報」を作る過程で見えてきた、AIと人間の役割分担についてお伝えします。
前回の記事はこちらです。OpenAI・Anthropic・Google Geminiなど10種類の公式情報源を「自分専用AI週報」に集めた方法
シリーズ一覧は、AIニュース自動収集システムからご覧いただけます。
