仕組みの骨組みができて、試運転を始めた。実際には送信せず、取得と整形だけを試す空振りの運転で、まず対象の記事が正しく拾えるかを確かめる。対象は、サイトの区分でいう記事・告知・求人・連載・特集の五つ。伝言板だけは除く取り決めだ。ところが、記事の分類で絞り込んで取得すると、返ってくるのが0件。サイトには今日も新しい記事が並んでいるのに、である。
六つの区分は「親」だった
CMSの分類データを端から調べて、まず構造が分かった。サイトの上部に並ぶ六つの区分は、分類の木でいう親にあたる。実際の記事に付いているのは、その下にぶら下がる子の分類だ。連載なら、連載という親の下に個々の連載ごとの子があり、記事に付くのはその子のほうである。ニュースの記事も、催しの告知も、みな同じだった。親の名前しか知らなかった私の仕組みは、子しか付いていない記事をことごとく素通りしていたわけだ。
使われなくなった、古いタグ
もう一つ、決定打があった。「記事」という分類そのものが、2024年の半ばを境に使われなくなっていたのだ。それ以前の記事には付いているが、最近の記事には一件も付いていない。サイトの見た目は何も変わっていないから、外からは気づきようがない。運用の中で付け方が変わり、古いタグだけが残った。こういう変更が仕様書に書かれることは、まずない。分類名で直接絞り込むという素直な実装は、この歴史の前では0件しか返せない。
全部取って、親へ辿る
解決はこうした。分類での絞り込みをやめて記事を全件取得し、一件ずつ、付いている分類を親へ親へと辿る。辿り着いた親が六つの区分のどれかで、その記事の区分を決める。サイトが各記事に表示している区分のバッジと突き合わせて、この判定が一致することを実データで確かめた。実はもう一つ、RSSという新着一覧の口もあったのだが、こちらは分類の情報がすべて同じ表記で出てくるため、区分の判別には使えなかった。頼れるのは公開APIと、親子を辿る判定だけだ。
データは、運用の歴史を映す
きれいな設計図の上では、分類で絞れば終わりのはずだった。だが実際のデータには、数年分の運用の癖と変遷が刻まれている。よそのデータをあてにする仕組みを作るときは、仕様書や想像ではなく実物を見る。手元の数件ではなく、できるだけ広く見る。今回もその原則に助けられた。0件という結果が最初に出てくれたのは、むしろ幸運だったと思う。
これで五つの区分の新着が正しく拾えるようになった。ところが稼働の直前、配信の流れそのものを変えることになる。次の回は、全自動をやめた話だ。