ニュースサイトへの記事配信の仕組み

ニュースのポータルサイトは様々なニュースサイト・メディアサイトからの記事配信によって成り立っています。それらの配信記事が、何のために・どのような方式で配信されているのでしょうか。歯切れの悪い語尾を多用しますがご了承ください。

※ 以下は、2019年12月時点の状況です

なぜ配信するのか

配信先のメリット

自前でニュースソースを作成する必要がなくなる
多種多様なニュースソースを扱うことで配信元サイト全般の客層を増やすことができる

配信元のメリット

多様なプラットフォームに配信することで単体のメディアよりも広い訴求を狙える
配信先へのニュースソース販売利益がある
関連記事等からの元サイトへの PV 増加が見込める
元サイトへの PV 増加による広告収入の増加が見込める

ある程度の規模の配信元であれば、配信先のリンク経由での PV 増加が大きな目的となります。もし配信先で大きく取り上げられた場合、元サイトにアクセス集中 ⇒ 元サイト落ちる ⇒ 広告収入が減る、という事態になるため、サイトの高速化やサーバーのスケーリングが重要になってきます。

配信のタイプ

配信先が指定する形式で配信元にファイルを配信し、配信先に送信する
配信先が指定する形式で配信元が RSS フィードを配信し、配信先が取り込む
配信元の RSS の形式に合わせて、配信先が記事を取り込む

1 は、ほぼとある大手サイト専用の方式です。

2 は、とある大手サイト以外の殆どの配信先が採用する方式です。

3 は、配信先が配信元に合わせてくれる方式です。配信先の作業が大変なので、特別対応以外では無い方式です。

とある大手サイトへの配信

とある大手サイトへの配信は、配信元で生成したファイルを、とある大手サイト側へ送信する仕組みです。

とある大手サイト以外の配信

とある大手サイト以外の殆どのメディアは、配信元メディアが出力する RSS フィードを配信先が一定間隔でクローリングする仕組みをとっています。RSS フィードの形式は、RSS2.0 および Atom が殆どです。SmartNews が SmartFormat として配信仕様を公開しているため、SmartNews以外のメディアでも「SmartFormat に準じる」仕様になっていることがありますが、データの利用方法が各メディアで異なるため、独自の名前空間で拡張された RSS の仕様書を所持している可能性があります。

実装に関すること

ほぼ全てのケースで、配信元サイトの社内 SE か外注の開発・保守の会社が、配信先の仕様書をみて独自に実装していると思われます。

WordPress プラグインや、CMS の拡張機能を作る

ニュースの配信元メディアが WordPress である場合は、RSS 配信用の独自プラグインを作る方法があります。WordPress 組み込みの仕組みを流用するので、WP業界の方ならば比較的実装が楽です。たとえば、RSS 用のエンドポイントを追加して、仕様に沿った XML のテンプレートとコントローラを用意すれば動的な RSS 配信が可能です。

WordPress 以外の CMS や、フレームワークを使ったサイトでも、だいたい同じ考えだと思います。

CMSの枠組から外して開発する

配信元メディアの DB などからデータを取得して加工し、フィード用の XML ファイルを出力する仕組みを作ることもあります。こちらの方法でも WordPress を使用していれば、wp-load.php を読み込んで $wpdb や WP_Query でデータを抜いてくることが多いと思います。

こちらの方式の場合、特定の CMS に明るくなくても何らかの言語と SQL の知見があれば開発可能です。

プッシュ型配信の場合

RSS フィードを作ったら配信先がクローリングしてくれるのではないく、こちらから送信する必要がある場合は、Cron などの定期実行や FTP などの転送技術を使ってファイルを送信します。

非表示フラグ

全ての記事を配信用の RSS フィードに乗せると悲劇が起きる可能性があるため、「この記事は配信しない」「配信したが問題が出たので削除」といった場面で使うフラグを、CMS 側で用意する場合があります。こういったフラグを認識する仕様は各社で異なります。

実装上の問題点

名前空間の拡張による独自仕様のRSS

先に触れた、独自仕様の RSS の件です。RSS や Atom はオープンなフォーマットなので、各社が足並みを揃えることで実装側はテンプレートの使いまわしが可能なはずです。しかしそんな便利なことにはなっておらず、各配信先で使うタグや属性が異なるのでそれぞれ専用の実装をしているのが実情だと思います。

Linus Torvalds さんが、特殊なケースを汎用的なコードで書けるのが良いセンスというようなことを仰っていましたが、こういうのはセンスの悪いケースです。

記事の削除フラグが配信先ごとに異なる

これも先に触れた、非配信や削除のフラグの件です。独自拡張した XML タグに active/delete を指定したり、属性値に true/false を入れたり、ノードを消したり、日付を変えたり、手法は様々です。問題点としては、CMS の編集画面に特定状況の時だけ使う機能が配信先の分だけ増える可能性があります。上手く汎用的にまとめられればよいのですが、後から取り扱う配信先が増えると仕様変更を迫られる可能性もあります。

文字コードの指定が UTF-8 以外

かなり稀なことですが、UTF-8 以外の文字コードが指定されている場合があります。最近のサイトはHTMLの出力が UTF-8、データベースの文字コードは utf8 か utf8mb4 であることが多いので、単純に変換や確認の工数が増えます。また、記事内で Unicode の Emoji を使っている場合は表記が不可能なため、意図した情報が伝わらない場合があります。

今後の展望

今のところは、RSS 配信の仕組みが継続するでしょう。とある大手サイトは RSS 取得型になるか、もっとスマートな手法に移行するのではないかと予想します。

実装面では、とにかく各社で仕様の違う RSS の仕様が大変です。配信先が REST API + 認証なんかで好きなようにデータを取得してくれればいいのですが、配信元がレガシーな仕組みの場合に対応しずらく、配信先での開発も必要なので中々難しいと思います。

PV 増加を狙うべく扇情的な記事の配信やファクトチェックの問題もあるなか、記事配信の仕組みの構図がどう変化してゆくのかに注目です。