n8nでYou.comとJevを組み合わせた朝のニュースブリーフ設計
ニュース要約で費用が膨らむ場所を切り分ける
ニュースの収集と要約は安く、判断が高いという整理が資料に記されている。 全記事に一般用途のLLMを走らせると、同じ内容の再配信まで判別させることになり、金額と遅延が積み上がるとされている。 多くのダイジェストはこの判定を諦め、すべて送るか、すべてをLLM要約して送る振る舞いになりやすいという指摘がある。 毎朝決まった時刻に届くが何も起きていない日が続くと、数週間で開封されなくなるという記述もある。
資料は、先にフィルターする設計に切り替えると述べている。 検索結果の各記事に小さなコストで三つの問いを掛け、通過したものだけに生成コストを払う流れであるとされている。 静かな日は何も送らない挙動が、三か月目の継続読了に効くと明記されている。
You.comとJevをn8nで繋いだ処理の流れ
平日八時にスケジュール実行し、設定ノードにトピック、チームの説明、重視する基準をまとめて持たせる構成が示されている。 一か所を編集すれば全体に反映されるように、設定を分散させない前提である。
各トピックごとに、You.com ノードが過去一日のニュースを検索する流れが資料に書かれている。 前回までに見かけたものはスキップし、前日の出来事を翌日に二重報告しないようにしているとされている。
見つかった各記事は Jev に渡され、単一の呼び出しで三つの問いに答えると資料は説明している。 実際に新しい出来事か、そのトピックの話か、チームにとっての重要度はどの程度か、という三点である。 重要度のしきい値を超えた記事だけが進み、残りは以後のコスト対象から外れる。 同一の出来事を複数媒体が報じている場合はトピック単位にまとめ、六件を一件に畳むとされている。 残った各トピックについて、You.com Research が引用付きの短いブリーフを書くと資料は述べている。
Jev は TypeSafe AI の System One 系のモデルで、検索から戻った各記事を一件あたり約四百分の一セントでスコアするという値が資料にある。 その価格感なら各記事に三つの問いを投げられ、朝全体で一〜四セント程度に収まるという見積もりも記載されている。 静かな日はそのトピックに何も投稿しない挙動も、資料の仕様として示されている。
You.com 側は、引用付きの出力を重視する「根拠に基づく生成」について解説している資料がある。 これはブリーフに出典を添える設計と整合しているが、利用条件や課金の細目は別途の一次資料の確認が要る。 TypeSafe AI の公式情報はモデル群の方向性を示す記述が中心で、価格やAPIの上限は本文からは読み取れない。
フィルター先行が実務に与える効果
先に判定してから要約する設計は、無関係な記事への推論コストを避けるため、実行時間と費用の分散を抑えやすい。 同じ出来事の重複送信を畳むことで、受け手が同じ話を何度も読まされる摩耗も減る。 資料の記述では、静かな日に投稿しないため、通知が空振りし続ける問題を避けられるとしている。
| アプローチ | フィルターの位置 | 既読除外 | 重複の扱い | 静かな日の動作 |
|---|---|---|---|---|
| 全件配信 | 無し | 無し | 無し | 毎朝送る |
| 全件をLLM要約 | 末尾 | 無し | 無し | 毎朝送る |
| 検索→Jevで厳選→You.comで執筆 | 先頭 | 前回見た記事を除外 | 同一トピックにまとめる | 送らない |
運用に落とすときの論点は次の三つに収斂する。 判定のしきい値をどこに置くか、重複判定の単位をどう定義するか、そして「何も起きなかった日」を敢えて空白にするかである。 しきい値が低すぎるとノイズが残り、高すぎると本来読みたい小粒な一次情報が落ちやすい。 重複はURL一致だけでは足りず、同一イベントの別見出しも束ねたいが、束ねすぎると異なる論点まで融合してしまう。
- 設定は一か所に集約する例として、Set ノード等にトピック配列とチーム記述、判定しきい値をJSONで持つと編集が楽になる。
- 既読の除外は、n8n のデータストアや外部のキー・バリューに URL と初見日を保持する方法が扱いやすい。
- 重複の畳み込みは、タイトルの正規化や主要固有名詞の抽出で近縁判定する手法が実装しやすいが、誤結合を避けるために人手での確認欄を残すのも一手である。
- 配信先はトピック単位で分け、無風日に投稿しない設計を維持するなら、まとめチャネル側に「今朝は投稿なし」というメタ通知を置かない構成にする。
最小構成で試す設定と留意点
実装を最小限で試すなら、次の順で組むと動作が見えやすい。
- Schedule Trigger を平日八時に設定する。
- 設定ノードに topics、teamDescription、careAbout、materialityThreshold をJSONで持たせる。
- 各トピックに対して You.com 検索ノードで過去一日を検索する。
- 既読除外ノードを挟み、URL単位で既出を落とす。
- Jev ノードに記事本文や見出し、トピックとチーム条件を渡し、三問同時判定のスコアを受け取る。
- しきい値で分岐し、通過分のみトピックごとに束ねる。
- You.com Research ノードに束ねた要点と出典URL群を渡し、短い引用付きブリーフを生成する。
- 配信ノードでチャンネルへ投稿する。
資料の記述では、Jev の判定は一件あたり約四百分の一セントの目安で、朝全体の合計は一〜四セントに収まるとしている。 費用感の前提はここに依存するため、運用前に実トピックで件数分布としきい値の感度を計測しておくと安全である。 You.com 側の生成は引用を添える前提に触れられているが、APIのレートや利用条件は別資料の確認が必要になる。
判定品質と集約の挙動は、業界イベントや製品名の揺れに影響される。 イベント名や製品系列を辞書にしておき、近縁判定の補助にするだけで無駄な分割が減る。 判定ログは記事URL、三問のスコア、採否、採否理由の短文を残すと、誤判定の追跡としきい値の再調整がやりやすい。