AIニュース監視で同じ知らせが何度も届く原因は、文字列の差を「新しい意味」と取り違えることです。 ここでは、変化を拾う固定処理と、通知価値を読むAI判断を分けます。 読み終えると、自分の利用状況まで照合させる判定プロンプトをそのまま使えます。
ケミの見張り係も、以前はキーワード表、流入種別、しきい値で重要度を決めていました。ところが上流ページが取得ごとに少し違う文字列を返した2026-08-04、同じ知らせを4回連続で「新規」と判定しました。差分はありましたが、読めば同じ内容でした。
課題:文字列差分だけでは「自分に関係する新情報」か分からない
ニュース監視には二つの問いが混ざりがちです。
- 前回からデータが変わったか。
- その変化は新しい意味を持ち、自分の環境へ影響するか。
一つ目はハッシュや差分で機械的に扱えます。二つ目は、製品名が一致しただけでは決まりません。自分が使っている版、設定、用途、既に通知済みの内容と照らす必要があります。
旧実装は二つ目まで固定プログラムへ押し込んでいました。その結果、監視対象の追加と一緒にキーワード表や分岐も増え、検証処理は7個、実装全体は1,090行になりました。
設計判断:固定プログラムとAI判断の境界を決める
| 処理 | 固定プログラム | AI判断 |
|---|---|---|
| 定期的に取得する | ○ | — |
| 前回と違うかを検出する | ○ | — |
| 状態と処理履歴を保存する | ○ | — |
| 重複実行を防ぐ | ○ | — |
| 同じ知らせの言い換えか判断する | — | ○ |
| 自分の利用状況へ影響するか判断する | — | ○ |
| 通知する結論と理由を書く | — | ○ |
私は「起こす・取る・記録する・送る」を固定処理へ残し、「重要か・重複か・自分に影響するか」をAIへ渡しました。AIへ丸ごと監視を任せたわけではありません。AIが失敗しても、取得済みデータと状態は外側に残ります。
この置換で、手書き実装は1,090行から572行へ減りました。差分がない回はAIを呼びません。差分があった実測では、全体86.9秒、取得処理は約3秒、ピークメモリ319MB、判定依頼9,937字でした。AI呼び出しは1回の確認につき最大1回です。
再現手順:AIへ渡す材料を三つに固定する
判定へ必要なのは、単なるdiffではありません。次の三つを一緒に渡します。
- 前回通知した内容と今回取得した内容。
- 自分が現在使っている製品・モデル・版・設定。
- 返してよい結論の形式。
特に二つ目が重要です。置換翌日の2026-08-06、あるAIモデルの廃止情報を、自分たちの設定に影響するか照合せず大きく通知しました。同日、利用中モデル一覧も判定材料へ含める形に直しました。ニュース本文だけを読ませても、「うちに効くか」は判断できません。
入力を次の形で用意します。
## 利用中の構成
- product: Example Agent CLI
model: example-model-stable
usage: scheduled writer
## 前回通知済み
- 2026-08-01: example-model-preview の終了予定
## 今回取得した内容
- example-model-preview の終了予定を再掲
- example-model-stable の仕様変更は記載なし
後段の通知処理は、AIのJSON結果が notify=true の時だけ動かします。AI自身に状態ファイル更新や通知送信をさせない方が、失敗時の境界を追いやすくなります。
結果:同じ話を4回新規扱いした判定をやめられた
| 観測項目 | 旧方式 | 置換後 |
|---|---|---|
| 同一内容の表現差 | 4回連続で新規扱い | 意味の重複として判断 |
| 実装行数 | 1,090行 | 572行 |
| 差分なし | 固定判定を継続 | AI呼び出し0回 |
| 差分あり | キーワード表としきい値 | AI判断1回 |
| 判断材料 | 新着本文中心 | 新着+通知履歴+利用中構成 |
置換後、この見張り係では同種の誤判定は出ていません。ただし、あらゆるページで重複が消えるという保証ではありません。入力へ通知履歴と利用状況を含め、出力を機械が検証できるJSONへ限定した範囲での運用結果です。
コピペで再現
前提条件
- 監視対象から取得した「前回本文」と「今回本文」があります。
- 自分が利用中の製品・モデル・版を、公開してよい名前で一覧化します。
- 任意の対話AIへ下のプロンプトを貼れます。特定ベンダーのAPIや非公開repoは不要です。
次のプロンプトを、そのまま貼って末尾の三つの入力欄だけ置き換えます。
あなたは更新情報の通知判定者です。
目的は「文字列が変わったか」ではなく、今回の内容が前回通知と意味的に異なり、
かつ利用中の構成へ影響するかを判定することです。
判定規則:
1. 前回通知の言い換え・再掲だけなら duplicate=true とする。
2. 利用中の構成に該当しない情報は affected=false とする。
3. 影響が不明な時は推測で補わず needs_context に不足項目を書く。
4. notify=true にできるのは duplicate=false かつ affected=true の時だけ。
5. 入力にない仕様・日付・価格・利用状況を作らない。
出力は次のJSONだけ:
{
"duplicate": true,
"affected": false,
"notify": false,
"reason": "日本語1〜2文",
"needs_context": []
}
## 利用中の構成
{{製品・モデル・版・用途の一覧}}
## 前回通知済み
{{過去の通知要約。なければ「なし」}}
## 今回取得した内容
{{今回の本文。取得日時も添える}}
返却JSONを保存し、通知可否だけを確認する最小コマンド例です。
$ jq -e '.duplicate == false and .affected == true and .notify == true' result.json
ハマり所
- diffだけを渡すと、AIも表現差へ引っ張られます。前回本文か前回通知要約を必ず添えてください。
- ニュースだけを渡して「うちへの影響」を聞かないでください。利用中の製品・モデル・版が判断材料です。
notifyをAI出力だけで即送信へ直結する前に、JSON schema、必須キー、入力の鮮度を固定処理で検査してください。- 同じ内容でも、利用中構成が変われば影響判定は変わります。利用一覧の更新時刻を入力へ残してください。
あわせて読みたい: HTTP 200でも内容取得失敗を見抜く意味検証の作り方
この検証を回している環境
この検証は、自宅の常設ラボ(使い捨てVM/LXCを回す母艦+GPU+VLAN分離ネットワーク)で動かしています。使っている機材と選定理由、全体構成は1本にまとめています。
ラボ構成のまとめを見る →