記事の状態要素

Cuerda-Feed-total が出力する RSS では、<item> の中に「記事の状態」を示すための要素がいくつか用意されています。 たとえば、汎用的な仕様における <status> 要素や、dmenuニュース向け配信で用いられる <goonews:delete> 要素などがそれにあたります。 これらは読者の画面には直接現れませんが、配信先のサーバーにとっては、 「この記事を新しく登録すべきか」「既に登録済みの記事を更新すべきか」「配信から削除すべきか」を判断するための中核となる情報です。 ここでは、Cuerda-Feed-total がどのような設計で記事の状態を把握し、どのタイミングで状態要素を書き換えているのか、その考え方を説明します。

なぜ「記事の状態要素」が必要なのか

ニュース配信の現場では、同じ記事が配信先へ複数回送られることが少なくありません。 初回の公開に続き、見出しや本文の修正、画像の差し替え、そして場合によっては削除や非公開化が発生します。 配信先のシステムは、その一つひとつを適切に解釈しなければなりません。

もし、すべてを「新しい記事」として扱ってしまえば、 同じ内容が重複して登録されるおそれがあります。 逆に、更新や削除が適切に伝わらなければ、誤った情報や公開すべきでない記事が残り続けてしまいます。 このような混乱を避けるために、配信仕様ではしばしば「記事の状態」を明示する要素が定義されており、 Cuerda-Feed-total はそれに従って、記事ごとの状態を記録・出力する役割を担っています。

状態を把握するための基本設計

Cuerda-Feed-total は、記事の状態を次のような単位で管理します。

• 記事ごと
• 配信先ごと

つまり、「ある記事が Yahoo!ニュース向けにどの状態で配信されたか」と「同じ記事が別の配信先にどの状態で配信されたか」は、 別々に記録されます。 これは、配信先ごとに仕様や運用が異なり、「更新」とみなす条件や「削除」として扱うべき状況が必ずしも同じではないためです。

内部的には、各記事・各配信先について、

• 前回フィードを生成した時点で「どの状態だったか」（新規／更新／削除など）
• その状態がいつ発生したか（時刻情報）

といった情報を記録しておきます。 新たにフィードを生成する際には、この記録と現在の WordPress 上の状態（公開・更新・非公開・配信除外など）を突き合わせることで、 今回どのような状態要素を出力すべきかを判断します。

状態が変化する代表的なタイミング

記事の状態は、次のような場面で変化します。

1. 新規公開されたとき

ある記事が初めて公開され、その配信先向けの条件（カテゴリ・タグ・投稿タイプなど）を満たした場合、 Cuerda-Feed-total はその記事を「新規配信すべき記事」として扱います。 内部の記録にまだ状態が存在しないため、

• 通常の <item> として出力しつつ
• 状態要素では「新規」であることを表す値（仕様ごとに定められた値）

を付与します。 これにより、配信先は「この記事は新しいものとして登録すべき」と判断できます。

2. 既存の記事が更新されたとき

すでに一度配信された記事の本文や見出し、画像などが更新され、 その変更を配信先側でも反映してもらう必要がある場合、 状態は「更新」に変わります。

この判定では、

• WordPress の更新日時（post_modified）
• 前回配信した時刻
• 配信先ごとに定めた「更新として扱うべき変更」の条件

を照らし合わせます。 条件を満たす場合、Cuerda-Feed-total は同じ記事を再び <item> として出力し、 状態要素には「更新」であることを示す値を設定します。 配信先にとっては、既存の記事レコードを上書きするきっかけとなる情報です。

3. 配信を停止すべきと判断されたとき

編集部の判断や契約上の理由により、ある記事を配信先から削除すべき場面もあります。 たとえば、次のようなケースです。

• 記事が非公開、あるいは削除状態に変更された。
• 配信設定の変更により、そのカテゴリやタグが配信対象外となった。
• 投稿単位の設定で「この配信先には送らない」と指定された。

このとき、Cuerda-Feed-total は、 「前回はこの配信先向けに配信していたが、今は対象から外れた」という事実をもとに、 状態を「削除」または「配信停止」と見なします。

dmenuニュース向け配信のように、仕様として削除専用の要素が定義されている場合、 たとえば <goonews:delete> のような要素に値を設定し、 「この記事は削除すべきである」という意図を明示します。 配信先はこのシグナルを受け取り、自身のデータベースから該当記事を取り除きます。

状態要素の具体的な表現例

「新規」「更新」「削除」という概念自体は共通していても、 その表現方法は配信先ごとの仕様書によって異なります。 Cuerda-Feed-total は、内部では共通の意味づけで状態を管理しつつ、 出力時には配信先ごとのルールに従って要素や値を切り替えます。

たとえば、

• ある配信先では <status> 要素の属性値として active や deleted を指定する。
• 別の配信先では、削除専用の要素 <goonews:delete> の有無で削除を表現する。
• 更新については、状態要素ではなく、配信先独自の「更新日時」要素と組み合わせて扱うこともある。

このように、記事の状態そのものは共通の概念でありながら、 実際の XML 上の表現は配信先ごとに異なります。 Cuerda-Feed-total は、その違いをプラグイン内部で吸収し、媒体側からは一つの仕組みとして扱えるよう設計しています。

状態要素がもたらすメリット

記事の状態要素は、配信の効率や正確さだけでなく、 媒体側の説明責任やトラブル対応にとっても重要な役割を持ちます。

• いつ、どの記事を「新規」として送り出したか。
• その後、どのタイミングで「更新」として再配信したか。
• 削除や配信停止を、どの状態要素で、どの時刻に知らせたか。

こうした履歴は、配信先のログと突き合わせることで、 「ある記事について、媒体側は適切なタイミングで配信停止を指示したか」といった確認にも役立ちます。 特に、人権や著作権に関わる削除要請への対応では、 状態要素が「いつ削除を依頼したか」を技術的に示す証拠となり得ます。

運用上のポイント

編集部や運用担当者にとって重要なのは、 「配信を止めたいときには WordPress 上で正しい操作を行う」ことです。 記事をゴミ箱に移動する、非公開にする、あるいは投稿単位の配信除外を指定するといった操作が、 最終的には状態要素を通じて配信先へ伝わります。

Cuerda-Feed-total は、これらの操作を監視し、記事ごとの状態記録と突き合わせることで、 次回のフィード生成時に適切な状態要素を自動的に付与します。 媒体側が状態要素を直接意識する必要はありませんが、 その背後で「新規」「更新」「削除」という判断が精密に行われていることを知っていただくことで、 配信の仕組み全体をより安心して運用していただけるはずです。