AI記事生成で重複コンテンツを防ぐ設計──スプレッドシートとWordPressの2段構えにした理由

最初の設計では、スプレッドシートからデータを取得するHTTPノードとWordPressから取得するHTTPノードを並列で置いていました。

ところが、GASを中継に使う設計に変えた結果、両方の処理をGASのactionで振り分けられるようになりました。

変更前：
  HTTPノードA → Googleシートから取得
  HTTPノードB → WordPressから取得（403エラーで失敗）

変更後：
  HTTPノード1本 → GASにPOST
    → action: get_articles
      → シートのデータ + WPの投稿記事を合算して返す

ノードが減ってワークフローがシンプルになりました。GASの中でスプレッドシートとWordPressの両方を処理するため、Dify側は1本のHTTPリクエストで済みます。

重複防止の精度と限界

この仕組みで重複コンテンツのリスクはかなり減りました。ただ完全ではありません。

現在の重複チェックは「キーワードとタイトルの文字列一致」を見ています。意味的に近い記事（別のキーワードだが内容が被る）は検出できません。

現在の精度：
✓ 同一キーワードの重複 → 防げる
✓ 同一タイトルの重複 → 防げる
✗ 意味的に近いが表現が違う記事 → 防げない

意味的な重複を防ぐには、記事の内容を比較する仕組みが必要です。現時点では実装していません。

動いてから見えてきた問題

システムが動いてGoogleシートに記事が溜まり始めたとき、別の疑問が浮かびました。

重複を防ぐことはできた。でも、何を書くべきかの判断はどこにもありません。

システムはキーワードを生成して記事を書きます。重複しないように管理もします。ただ、そのキーワードがサイト全体の設計として正しいかどうか、読者にとって本当に必要な記事かどうかは、システムには判断できません。

重複しない記事を量産することと、価値ある記事を作ることは別の話です。自動化できるのは前者だけで、後者は設計者が判断しなければなりません。

その「何を書くべきか」の判断軸をどう持つか。それはツールの話ではなく、設計の話です。bizinets.bizで書いています。