JP2020024489A - 情報処理装置、情報処理方法、プログラム、記憶媒体 - Google Patents

Abstract

【課題】 ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載するような環境を提供することを目的とする。【解決手段】 情報処理装置は、配信記事を受信する記事受信部と、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得部と、前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得部と、前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定部と、を備えるものとした。【選択図】図８

Description

本発明は情報処理装置、情報処理方法、プログラム、記憶媒体に関し、特にニュース掲載サイトの特定の記事掲載場所に掲載する記事を選別する技術に関する。

ニュース記事を閲覧可能なウェブサイト（以降、ニュース掲載サイト）には、多数の記事群の中から閲覧者に優先的に閲覧させたい記事を提供するための特定の記事掲載場所が設けられている。
特定の記事掲載場所は、例えば、ニュース掲載サイトのトップページに設けられている。このような特定の記事掲載場所に何れの記事を掲載するかを決定することは重要である。例えば、以下に示す特許文献１では、記事の選択方法として、ユーザに対して適合性の高いコンテンツ（ニュース記事）を提供する構成が記載されている。

特開２００６−２２７９２５号公報

ところで、ニュース掲載サイトでは、ユーザが興味を持つユーザ受けのいい記事をトップページのような特定の記事掲載場所に掲載することは重要であるが、ニュース掲載サイトの特性上、公共性が高い記事も該特定の記事掲載場所に掲載すべきという事情がある。
また、ニュース掲載サイトが他のニュース掲載サイトとは異なる独自性を有することにより、他のニュース掲載サイトとの差別化を図ることも重要である。

本発明は、このような事情を鑑みてなされたものであり、ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載すると共に、他のニュース掲載サイトとは異なる独自性を有するように掲載記事を選択する環境を提供することを目的とする。

本発明に係る情報処理装置は、配信記事を受信する記事受信部と、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得部と、前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得部と、前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定部と、を備えたものである。
ニュース掲載サイトには毎日各種の新着記事が配信され、その件数は数千件〜数万件にも及ぶ。そのような大量な新着記事から、ポータルサイトのトップページのような特定の記事掲載場所に掲載する注目記事を選別することは容易ではなく、作業者の負担が大きい。
このような状況を鑑みて、上記した情報処理装置としての記事の管理システムでは、例えば機械学習によって生成した掲載傾向モデル及び閲覧傾向モデルを利用することにより得られた判定結果を用いて、自動で新着記事の中から特定の記事掲載場所に掲載する記事（特定掲載記事）が選別される。

上述した情報処理装置の第１判定結果取得部は、前記選択されたニュース掲載サイト以外の他のニュース掲載サイトについての掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得し、前記掲載判定部は、前記配信記事について、前記選択されたニュース掲載サイトについての前記第１判定結果が掲載判定とされ、前記他のニュース掲載サイトについての前記第１判定結果が不掲載判定とされた場合に、当該判定の対象となった配信記事を前記他のニュース掲載サイトに対する差分記事として前記特定の記事掲載場所に掲載され易いように扱ってもよい。
他のニュース掲載サイトにおいて掲載されずに選択されたニュース掲載サイトで掲載されると判定した差分記事が、選択されたニュース掲載サイトに掲載されやすくすることで、他のニュース掲載サイトとの差別化が図られる。

上述した情報処理装置の掲載判定部は、前記選択されたニュース掲載サイトについての前記第１判定結果が掲載判定とされ、前記選択されたニュース掲載サイトについての前記第２判定結果が閲覧判定とされた記事については、掲載判定としてもよい。
掲載傾向に合致し閲覧傾向にも合致した記事は、ニュース掲載サイトにとって当然に掲載すべき記事である可能性が高い。そして、本構成の掲載判定部によれば、そのような記事を確実に掲載判定とすることができる。

上述した情報処理装置の掲載判定部は、前記選択されたニュース掲載サイトについての前記第１判定結果が掲載判定とされ、前記選択されたニュース掲載サイトについての前記第２判定結果が非閲覧判定とされた記事のうち少なくとも一部の記事については掲載判定としてもよい。
ニュース掲載サイトには、閲覧数が多いことが予想されるために特定の記事掲載場所に掲載される記事もあれば、ニュース掲載サイトの特性として閲覧数に関わらず特定の記事掲載場所に掲載すべき記事もある。本構成によれば、閲覧数が増えるとは限らない記事、即ち第２判定処理において非閲覧判定とされた記事についても、掲載判定部は掲載すると判定する場合がある。

上述した情報処理装置において、前記掲載判定部による掲載判定は、特定の時間帯のみ行ってもよい。
例えば、特定の時間帯以外は作業者によって特定掲載記事が選別されるようにし、その選別結果を用いて掲載傾向モデルと閲覧傾向モデルの調整を行うことが可能となる。

上述した情報処理装置の第２判定結果取得部は、前記特定の記事掲載場所に掲載された新たな記事についての閲覧数に基づいて更新された前記閲覧傾向モデルを用いた前記第２判定結果を取得してもよい。
これにより、ニュース掲載サイトに来訪するユーザ層に変化が起きた場合のように、閲覧されやすい記事が変化した場合でも、新たな特定掲載記事についての閲覧数の傾向が追加で学習されて第２判定結果に反映される。

上述した情報処理装置においては、前記掲載判定部が掲載すると判定した記事を作業者に提示する提示部と、前記作業者により選択された記事を前記特定の記事掲載場所に掲載する記事として決定する掲載記事決定部と、を備えていてもよい。
即ち、掲載判定部によって掲載すると判定された記事がそのまま特定記載記事として掲載されることはなく、作業者の目視による検査が行われた後に掲載される。

上述した情報処理装置においては、前記特定の記事掲載場所が特定のジャンルに属する記事を集めたウェブページに設けられている場合において、前記掲載判定部は、前記記事提供元から配信される記事のうち前記特定のジャンルに属する記事に対して前記判定を行ってもよい。
特定のテーマに沿った特集ページであっても、機械学習を用いて生成された各モデルを利用した掲載判定が行われる。

本発明に係る情報処理方法は、配信記事を受信する記事受信ステップと、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得ステップと、前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得ステップと、前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定ステップと、を情報処理装置が実行するものである。
この情報処理方法により、ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載するような環境を提供することができる。
本発明に係るプログラムは、上記各ステップに相当する手順を情報処理装置に実行させるプログラムである。本発明に係る記憶媒体は、上記プログラムを記憶したものである。これらにより上述の情報処理装置の処理を実現する。

本発明によれば、ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載するような環境を提供することができる。

本発明の実施の形態の記事管理端末を含むネットワークの説明図である。 実施の形態で利用できるコンピュータ装置のブロック図である。 実施の形態の記事管理端末の機能構成の説明図である。 ニュース掲載サイトのトップページの例を説明するための図である。 第１の実施の形態における掲載傾向モデル更新処理のフローチャートである。 第１の実施の形態における閲覧傾向モデル更新処理のフローチャートである。 第１の実施の形態における閲覧傾向モデル更新処理の別例のフローチャートである。 第１の実施の形態における新着配信記事確認処理のフローチャートである。 第１の実施の形態における総合判定処理のフローチャートである。 第１の実施の形態における入替判定処理のフローチャートである。 第１の実施の形態における総合判定処理のフローチャートである。 第１の実施の形態における新着配信記事確認処理の別例２のフローチャートである。 第２の実施の形態における掲載傾向モデル更新処理のフローチャートである。 第２の実施の形態における新着配信記事確認処理のフローチャートである。 第２の実施の形態における総合判定処理のフローチャートである。 第３の実施の形態における入替判定処理のフローチャートである。 第３の実施の形態における提示ページの例を説明するための図である。

以下、実施の形態を次の順序で説明する。
＜１．システム構成＞
＜２．コンピュータ装置のハードウェア構成＞
＜３．記事管理端末の機能構成及びＤＢ＞
＜４．第１の実施の形態＞
＜４−１．掲載傾向モデル更新処理＞
＜４−２．閲覧傾向モデル更新処理＞
＜４−３．閲覧傾向モデル更新処理の別例＞
＜４−４．新着配信記事確認処理＞
＜４−５．新着配信記事確認処理の別例＞
＜４−６．新着配信記事確認処理の別例２＞
＜５．第２の実施の形態＞
＜５−１．掲載傾向モデル更新処理＞
＜５−２．新着配信記事確認処理＞
＜５−３．総合判定処理＞
＜６．第３の実施の形態＞
＜６−１．入替判定処理＞
＜７．変形例＞
＜８．まとめ＞
＜９．プログラム及び記憶媒体＞

＜１．システム構成＞

本実施の形態としてのニュース掲載サイトを管理する管理システム１を含むネットワークシステム全体の構成について、図１を用いて説明する。
管理システム１は、例えばインターネット等の通信ネットワーク２を介して、配信社端末３，３，・・・ユーザ端末４，４，・・・と互いに通信可能とされている。

なお、図１に示した通信ネットワーク２の構成は特に限定されるものではなく、上記したインターネット以外にも、例えばイントラネット、エキストラネット、ＬＡＮ（Local Area Network）、ＣＡＴＶ（Community Antenna TeleVision）通信網、仮想専用網（Virtual Private Network）、電話回線網、移動体通信網、衛星通信網などが想定される。
また、通信ネットワーク２の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばＩＥＥＥ（Institute of Electrical and Electronics Engineers）１３９４、ＵＳＢ（Universal Serial Bus）、電力線搬送、電話線などの有線でも、ＩｒＤＡ（Infrared Data Association）のような赤外線、ブルートゥース（登録商標）、８０２．１１無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。

管理システム１は、それぞれコンピュータ装置で構成された記事管理端末１０、ウェブサーバ１１、記事ＤＢ（Database）５０、ユーザＤＢ５１、コメントＤＢ５２等を備えている。これらの各装置は、例えばＬＡＮ等のネットワークを介して互いに通信可能とされており、このようなネットワークは通信ネットワーク２と同様に特に限定されるものではない。

管理システム１は、各種のニュース記事（以降単に「記事」と記載することもある）をウェブページ上でユーザに閲覧可能な状態で提供するための各種の機能を備えている。
例えば、記事管理端末１０は、配信社が所有する配信社端末３からネットワーク２を介して配信されてくる各記事の管理や、記事に付与するラベル情報（ジャンル情報など）の管理や、ニュース掲載サイトを閲覧するユーザのユーザＩＤ（Identification）やパスワードや閲覧履歴情報を管理するユーザ管理のための各種処理を行う。

記事管理端末１０は、配信社端末３から配信されてくる記事についての各種処理を行う情報処理装置である。具体的な処理内容については後述する。

ウェブサーバ１１は、ニュース掲載サイトとしてのウェブページに関する各処理を実行する。例えば、ユーザ端末４からのＨＴＴＰ（Hypertext Transfer Protocol）リクエストに基づいて、該当のウェブページデータの生成処理や送信処理を行う。
ウェブページデータは、例えば、ＨＴＭＬ（Hypertext Markup Language）やＸＨＴＭＬ（Extensible Hypertext Markup Language）などの構造化文書ファイルである。構造化文書ファイルには、ニュースタイトルや記事本文などのテキストデータやニュースごとに用意された画像などの画像データと、それらの配置や表示態様（文字色やフォントや大きさや装飾など）が記述されている。
ウェブページとしては、例えば、ニュース掲載サイトのトップページや、各記事の詳細が掲載された記事個別ページや、ニュースに対して投稿されたコメントを閲覧可能なコメントページなどである。

配信社端末３は、記事を配信する配信社に所属する社員等が使用する情報処理装置である。配信社端末３は、管理システム１に対して新たな記事を配信するための送受信処理や、既に配信済みの記事を修正するための処理が行われる。
なお、配信社は企業である必要はなく、記事の配信を行う記者であってもよい。従って、配信社端末３は記事の配信を行う配信者が使用する配信者端末であってもよい。

ユーザ端末４は、ニュース掲載サイトを管理する管理システム１が提供する各種のサービスを受けるためにユーザが使用する情報処理装置である。具体的には、ニュース掲載サイト上のニュース記事を閲覧する場合などに用いられる。
配信社端末３やユーザ端末４は、例えば、通信機能を備えたＰＣ（Personal Computer）やフィーチャーフォンやＰＤＡ（Personal Digital Assistants）、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。

＜２．コンピュータ装置のハードウェア構成＞

記事管理端末１０やウェブサーバ１１をはじめとした各装置（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２、配信社端末３及びユーザ端末４）を構成するコンピュータ装置のハードウェア構成を図２に示す。各コンピュータ装置のＣＰＵ（Central Processing Unit）１０１は、ＲＯＭ( Read Only Memory)１０２に記憶されているプログラム、または記憶部１０８からＲＡＭ( Random Access Memory )１０３にロードされたプログラムに従って各種の処理を実行する。ＲＡＭ１０３にはまた、ＣＰＵ１０１が各種の処理を実行する上において必要なデータなども適宜記憶される。
ＣＰＵ１０１、ＲＯＭ１０２、およびＲＡＭ１０３は、バス１０４を介して相互に接続されている。このバス１０４には、入出力インタフェース１０５も接続されている。
入出力インタフェース１０５には、入力部１０６、出力部１０７、記憶部１０８、通信部１０９が接続されている。
入力部１０６はキーボード、マウス、タッチパネルなどにより構成される。
出力部１０７はＬＣＤ（Liquid Crystal Display）、ＣＲＴ（Cathode Ray Tube）、有機ＥＬ（Electroluminescence）パネルなどよりなるディスプレイ、並びにスピーカなどにより構成される。
記憶部１０８はＨＤＤ（Hard Disk Drive）やフラッシュメモリ装置などにより構成される。
通信部１０９はネットワーク２を介しての通信処理や機器間通信を行う。
入出力インタフェース１０５にはまた、必要に応じてメディアドライブ１１０が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア１１１が適宜装着され、リムーバブルメディア１１１に対する情報の書込や読出が行われる。

このようなコンピュータ装置では、通信部１０９による通信によりデータやプログラムのアップロード、ダウンロードが行われる。またリムーバブルメディア１１１を介したデータやプログラムの受け渡しが可能である。
ＣＰＵ１０１が各種のプログラムに基づいて処理動作を行うことで、記事管理端末１０やウェブサーバ１１などの各装置（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２、配信社端末３及びユーザ端末４）としての必要な情報処理や通信が実行される。
なお、記事管理端末１０やウェブサーバ１１などの各装置（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２、配信社端末３及びユーザ端末４）を構成する情報処理装置は、図２のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、ＬＡＮ等によりシステム化されていてもよいし、インターネット等を利用したＶＰＮ等により遠隔地に配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群（クラウド）としての情報処理装置が含まれてもよい。

情報処理装置の各機能は、情報処理装置においてＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部または一部の各構成の処理をハードウェアにより実現してもよい。
また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また各機能は複数の情報処理装置に分散されていてもよい。更に機能の一つが、複数の情報処理装置によって実現されてもよい。

＜３．記事管理端末の機能構成及びＤＢ＞

記事管理端末１０の具体的な構成について、図３を参照して説明する。
記事管理端末１０は、管理部１０ａ、掲載傾向モデル生成部１０ｂ、閲覧傾向モデル生成部１０ｃ、掲載判定部１０ｄ、提示部１０ｅ、掲載記事決定部１０ｆを備えている。

管理部１０ａは、配信社によって配信された各記事の管理するための各種処理を行う。
例えば、配信社から配信された記事を受信するための処理や、記事ごとの公開期限に基づく公開制御などの記事管理処理や、ユーザの登録処理やユーザ登録の解除処理などのユーザ管理処理等を行う。
記事の公開期限は、配信社とニュース掲載サイトの運営者の間の契約等により設定され得るものであり、公開期限を過ぎると記事の閲覧が不能とされる。

掲載傾向モデル生成部１０ｂは、ニュース掲載サイトの特定の記事掲載場所に掲載される記事（具体的には、見だしが掲載される記事）の傾向をモデル化した「掲載傾向モデル」を生成するための処理を行う。特定の記事掲載場所に見だしが掲載される記事を、以降の説明においては「トップ掲載記事」と記載する。ここで、「特定の記事掲載場所」がニュース掲載サイトのトップページ設けられた例を挙げる。

図４は、ニュース掲載サイトのトップページ（ウェブページ）の一例を示したものである。
ニュース掲載サイトのトップページ（以降、単にトップページと記載）は、ユーザ端末４上で動作するウェブブラウザ２０を用いて閲覧可能である。ウェブブラウザ２０には、ウェブページ表示欄２１が設けられ、その上部や側部には各種の操作子（ボタンや入力欄）２２，２２，２２・・・が設けられている。

トップページが表示されるウェブページ表示欄２１には、検索を行うための入力欄や検索ボタンと共に、トップ掲載記事の見だしが掲載される特定の記事掲載場所（以降、特定掲載場所２３）が設けられている。
特定掲載場所２３の周辺には、ログイン情報表示欄や広告表示欄、天候表示欄、他サービスへの導線部が配置されている。
特定掲載場所２３は、例えば「総合」、「経済」、「社会」、「国際」、「芸能」などの複数のタブを有して構成されている。

本実施の形態では、一例として「総合」のタブにおける特定掲載場所２３に掲載されるトップ掲載記事を対象とする。即ち、掲載傾向モデル生成部１０ｂは、「総合」のタブにおける特定掲載場所２３に掲載されたトップ掲載記事を入力とした機械学習を行い、掲載傾向モデルを生成する処理を行う。機械学習に用いる具体的な入力としては、トップ掲載記事の見だしや本文、ジャンル情報、配信社等の情報とされる。
このような入力情報（特徴量）による機械学習を経て生成された掲載傾向モデルを用いることにより、新たな記事が特定掲載場所２３に掲載されるべきか否かを判定する。このような機械学習は、例えば、ディープラーニングなどを用いることに実現可能である。

なお、掲載傾向モデル生成部１０ｂは、特定掲載場所２３に新たな記事が掲載されるごとに、掲載傾向モデルを更新する処理を行ってもよい。

閲覧傾向モデル生成部１０ｃは、少なくとも特定掲載場所２３に掲載された記事についての閲覧数の傾向をモデル化した「閲覧傾向モデル」を生成するための処理を行う。
具体的に、閲覧傾向生成処理では、記事の見だしや本文、ジャンル情報、配信社等の記事に関する入力情報を用いた機械学習を行い、閲覧傾向モデルを生成する。生成した閲覧傾向モデルは、新たな記事についての情報を入力することで、当該新たな記事についての閲覧数の予測に用いる。このような閲覧傾向モデルを生成するための機械学習としては、例えばディープラーニングなどを挙げることができる。
なお、閲覧数の傾向だけでなく、閲覧されるユーザの属性の傾向も含めてモデル化することにより、新たに配信された記事がどのようなユーザに閲覧されやすいかを推測可能とされていてもよい。

また、閲覧傾向モデルを生成するために付与する学習用データは、特定掲載場所２３に掲載された記事だけでなく、管理システム１が管理するニュース掲載サイトに配信される記事全てを用いてもよい。これにより、ニュース掲載サイトの全記事を対象とした学習が行われ、全記事の中で閲覧されやすい記事の特徴を捉えた閲覧傾向モデルを生成される。

なお、閲覧傾向モデル生成部１０ｃは、記事の閲覧数が更新されるごとや一定時間ごとに、掲載傾向モデルを更新する処理を行ってもよい。
また、特定掲載場所２３に掲載された記事の閲覧数を入力として閲覧傾向モデルの更新を行う場合には、特定掲載場所２３に掲載された記事がその場所から削除されるタイミングで、当該削除された記事のそれまでの閲覧数を取得して、閲覧傾向モデルの更新を行ってもよい。これにより、閲覧傾向モデルの更新処理の実行回数を少なくすることができ、記事管理端末１０の処理負担の軽減が図られる。

掲載判定部１０ｄは、掲載傾向モデル生成部１０ｂが生成した掲載傾向モデルを利用して判定対象の記事が特定掲載場所２３に掲載されやすいか否かを判定（推定）する第１判定処理を行う。また、閲覧傾向モデル生成部１０ｃが生成した閲覧傾向モデルを利用して判定対象の記事が閲覧されやすいか否かを判定（推定）する第２判定処理を行う。
第２判定処理では、判定対象記事の閲覧数が所定数以上となると推定した場合に「閲覧される」と判定し、所定数未満となると推定した場合に「閲覧されない」と判定する。また、それ以外の判定方法としては、判定対象記事について推定した閲覧数を例えば３段階（推定した閲覧数が多い順にＡ判定、Ｂ判定、Ｃ判定）などで評価してもよい。即ち、ある記事Ａは余り閲覧されないと推定してＣ判定とし、他の記事Ｂは閲覧数が多くなると推定してＡ判定としてもよい。勿論、閲覧数の評価結果として０〜１００点のような更に多段階の評価結果を付与してもよい。

更に、掲載判定部１０ｄは、第１判定処理の結果と第２判定処理の結果を用いて特定掲載場所２３に判定対象の記事を掲載するか否かを判定する総合判定処理を行う。更に、判定対象とされた記事を特定掲載場所２３に掲載すると判定した場合、代わりに特定掲載場所２３から削除される記事を選定する削除判定処理を行う。

提示部１０ｅは、掲載判定部１０ｄの総合判定処理の結果特定掲載場所２３に新たに掲載すると判定した記事を作業者に通知するための処理を行う。この処理では、例えば、管理システム１の運用を行う作業者が使用する情報処理端末の画面上に当該記事がトップ掲載記事の候補として選択されたことを通知するウィンドウなどを表示させる。この処理は、例えば、ウェブサーバ１１などと協働することにより、管理のためのウェブページ上で報知されるように構成してもよい。
なお、総合判定処理の結果選択されたトップ掲載記事の候補を作業者に提示せずにそのままトップ掲載記事に掲載する場合は、提示部１０ｅは不要となる。

掲載記事決定部１０ｆは、作業者が選択した選択結果に応じて最終的なトップ掲載記事を決定する。例えば、掲載判定部１０ｄによって記事Ａがトップ掲載記事の候補として判定され、提示部１０ｅによって判定結果が作業者に提示される。その際には、記事Ａを判定処理に従ってトップ掲載記事に加えるか否かを選択される選択肢が作業者に提示され、その際にトップ掲載記事から削除される削除記事候補（例えば記事Ｂ）も提示される。作業者によって、記事Ｂの代わりに記事Ａをトップ掲載記事として選択する意思表示を受けて、掲載記事決定部１０ｆは、トップ掲載記事の一覧を更新する。
掲載記事決定部１０ｆは、その結果をウェブサーバ１１に送信する。ウェブサーバ１１ではその結果を受けて記事Ａを含む新たなトップ掲載記事群を表示させるためのウェブページデータを生成する。

管理システム１には、他にも、ユーザ情報を登録するための処理や、ユーザのログイン操作に対する認証処理などを実現するために必要な各部が設けられている。認証処理は、ユーザ端末４から送信されたログイン情報としてのユーザＩＤ（Identification）とログインパスワードを、ユーザＤＢ５１に記憶された認証情報と照合する処理である。
このような各部は、記事管理端末１０やウェブサーバ１１とは異なる情報処理装置に設けられていてもよいし、配信管理端末１０やウェブサーバ１１に設けられていてもよい。また、複数の情報処理装置を利用して各部の実現が可能とされていてもよい。

尚、管理システム１としての各機能は、情報処理装置におけるＣＰＵ１０１でプログラムに応じて実行される処理により実現される機能である。但し上記の全部又は一部の各構成の処理をハードウェアにより実現してもよい。

また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また、各機能は複数の情報処理装置に分散されていてもよい。更に、機能の一つが複数の情報処理装置によって実現されていてもよい。

記事管理端末１０及びウェブサーバ１１が上記の各種機能を実現するために、管理システム１は、記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２を備えている。

記事ＤＢ５０には、配信社から配信される記事が記憶されている。例えば、配信記事ごとに記事を一意に特定可能な記事ＩＤが付与され、該記事ＩＤごとに配信日時、配信社（配信社ＩＤ）、公開期限、ジャンルＩＤ（複数可）、画像情報（もしくは画像ＩＤ）等が紐付けられている。
画像情報は、画像データがそのまま記憶されていてもよいし、別の記憶領域に保存された画像を特定可能な画像ＩＤなどの状態で記憶されていてもよい。

ユーザＤＢ５１には、管理システム１が提供する各種サービスを利用するユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザＩＤに対して、ユーザ名、ログインパスワード、氏名、年齢、性別、年収、住所、メールアドレス、趣味などの個人的な情報が紐付けられて記憶される。
勿論、これらの情報の全てが記憶されていなくてもよく、記憶された情報量がユーザごとに異なっていてもよい。

コメントＤＢ５２には、ユーザによって投稿されるコメントが記憶される。例えば、コメントを一意に特定可能なコメントＩＤに対して、投稿日時、対象となった記事を特定するための記事ＩＤ、他のコメントへのリプライである場合には対象コメントを特定可能な情報（対象コメントＩＤ）、コメントに対して他のユーザが同意したか否かを示す同意数情報／非同意数情報等が紐付けられている。

これらの各ＤＢ（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２）は、管理システム１を構成する各情報処理装置が必要に応じてアクセス可能とされていればどのような形態で実現されていてもよい。例えば管理システム１と同一システム内の記憶部に各ＤＢ（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２）のすべてが形成されていてもよいし、各ＤＢ（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２）の一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各ＤＢ（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２）が一つの装置（例えば一つのＨＤＤ等）内に形成されている必要はない。また各ＤＢ（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２）のそれぞれが、それぞれ１つのＤＢとして構成される必要もない。例えばユーザＤＢ５１に記憶される情報が、複数のユーザＤＢ（例えばログイン用のユーザＤＢとユーザの興味を推測するためのユーザ情報が記憶されたユーザＤＢなど）により記憶管理されてもよい。以下説明する各ＤＢ（記事ＤＢ５０、ユーザＤＢ５１、コメントＤＢ５２）は、実施の形態の処理に関連する情報の記憶部を、それぞれ１つのＤＢの形態で例示したものに過ぎない。

＜４．第１の実施の形態＞

第１の実施の形態において記事管理端末１０が実行する処理について、添付図を参照しながら説明する。第１の実施の形態では、管理システム１が管理する一つのニュース掲載サイトについて各種の処理を行う。

＜４−１．掲載傾向モデル更新処理＞
記事管理端末１０の掲載傾向モデル生成部１０ｂは、掲載傾向モデルを更新するための処理を適宜実行する。その一例について、図５を参照して説明する。
記事管理端末１０は、特定掲載場所２３に掲載されたトップ掲載記事のラインナップを確認する処理をステップＳ１０１で実行する。この処理では、例えば、特定掲載場所２３に掲載された各記事の記事ＩＤを取得する。

続いて、記事管理端末１０は、ステップＳ１０２で、特定掲載場所２３に掲載された記事群に変更があったか否かに応じた分岐処理を行う。即ち、直前のステップＳ１０１で取得した記事群と、その前にステップＳ１０１を実行した際に取得した記事群に違いがあるか否かを判定する。違いがない場合（ステップＳ１０２：Ｎの場合）、即ちトップ掲載記事に変更がない場合、記事管理端末１０は図５に示す一連の処理を終了する。

一方、違いがある場合（ステップＳ１０２：Ｙの場合）、記事管理端末１０は続くステップＳ１０３で、新着記事の抽出を行う。なお、ステップＳ１０３の処理を実行する際、記事管理端末１０は次回のステップＳ１０２の実行に備えて今回取得したトップ掲載記事の一覧を保持しておく。
新着記事の抽出は、前回取得したトップ掲載記事の一覧に含まれておらず今回取得したトップ掲載記事の一覧に含まれている記事を抽出する処理となる。

次に、記事管理端末１０はステップＳ１０４で、掲載傾向モデルを更新するための処理を行う。具体的には、ステップＳ１０３で抽出した新着記事に関する情報（例えば、記事の見だしや本文、ジャンル情報など）を用いて掲載傾向モデルの更新を行う。この更新処理では、新着記事の特徴に応じて最新の掲載傾向を反映したモデルの構築、即ち、ディープラーニングにおける入力層、隠れ層、出力層の各ノードで用いられる重みやバイアスなどの自動的な最適化が行われる。

なお、特定掲載場所２３に掲載された記事（トップ掲載記事）が変更されたことをトリガとして掲載傾向モデルの更新処理を実行してもよい。その場合、掲載傾向モデル生成部１０ｂは、ステップＳ１０１及びＳ１０２の処理は実行せずに、トリガの発生に基づいてステップＳ１０３及びステップＳ１０４の処理を実行する。

また、掲載傾向モデルがまだ生成されておらず、掲載傾向モデルを新たに生成する場合においても図５に示す一連の処理が用いられる。
具体的には、特定掲載場所２３の確認処理をステップＳ１０１で実行し、ステップＳ１０２の判定処理を行う。ここで、特定掲載場所２３についてのステップＳ１０１の処理の実行は今回が初めてである。そのため、前回取得した特定掲載場所２３のトップ掲載記事の一覧は存在せず、ステップＳ１０２の判定は変更あり（ステップＳ１０２：Ｙ）となる。
続いて、ステップＳ１０３で新着記事を抽出する処理を実行するが、ここでは、ステップＳ１０１で確認したトップ掲載記事の全ての記事が新着記事として扱われる。
最後に、ステップＳ１０４で、新着記事の各種の情報を入力として掲載傾向モデルの生成が行われる。

＜４−２．閲覧傾向モデル更新処理＞
記事管理端末１０の閲覧傾向モデル生成部１０ｃは、閲覧傾向モデルを更新するための処理を適宜実行する。その一例について、図６を参照して説明する。

記事管理端末１０は、ステップＳ２０１で、特定掲載場所２３の確認処理を行う。具体的には、特定掲載場所２３に見だしが掲載されたトップ掲載記事の記事ＩＤを取得する。
なお、ステップＳ２０１から続く一連の処理を実行するタイミングは各種考えられる。例えば、定期的に行ってもよいし、ニュース掲載サイトに対する累積アクセス数が一定数増えるごとに行ってもよい。

続いて、記事管理端末１０はステップＳ２０２で、トップ掲載記事の閲覧数をそれぞれ取得する。なお、閲覧数の取得は、記事がどの程度閲覧されているかを図るための指標として取得するものである。従って、異なるユーザがどの程度閲覧したかを把握するために、ユニークユーザの閲覧数を取得してもよい。この場合には、同一ユーザが同じ記事を何度閲覧したとしても、１回の閲覧としてカウントされる。
また、閲覧数を取得する代わりに、記事に対して投稿されたコメントの数を取得してもよい。即ち、投稿対象となった記事がどの程度閲覧されているかを図るための指標としてコメント数を用いるものである。コメントはコメントＤＢ５２から取得する。

最後に、記事管理端末１０はステップＳ２０３で閲覧傾向モデルの更新処理を実行する。
具体的には、ステップＳ２０２で取得した閲覧数などの指標を用いて閲覧傾向モデルの更新を行う。この更新処理では、各記事の閲覧数の変化、即ち閲覧傾向の変化や、新たに特定掲載場所２３に見出しが掲載されたトップ掲載記事についての閲覧数に応じて、最新の閲覧傾向を反映したモデルの構築、即ち、ディープラーニングにおける入力層、隠れ層、出力層の各ノードで用いられる重みやバイアスなどの自動的な最適化が行われる。

なお、閲覧傾向モデルがまだ生成されていない場合、即ち処理対象の特定掲載場所２３についてステップＳ２０３の処理を初めて行う場合においても、図６に示す一連の処理が用いられる。
具体的には、特定掲載場所２３の確認処理をステップＳ２０１で実行し、ステップＳ２０２で各記事の閲覧数取得を行う。続いて、ステップＳ２０３で、トップ掲載記事についての閲覧数の情報を入力として閲覧傾向モデルの生成が行われる。

＜４−３．閲覧傾向モデル更新処理の別例＞
閲覧傾向モデル更新処理の別例について、図７を参照して説明する。
図６に示した閲覧傾向モデル更新処理は、処理タイミングを定期的とする例や累積アクセス数が一定数増加ごととする例を説明した。本例は、処理タイミングを特定掲載場所２３に掲載されたトップ掲載記事のうち、いずれかの記事が特定掲載場所２３から削除されたタイミングとする例である。
従って、閲覧傾向モデルの更新回数は、トップ掲載記事の記事数と同等とされる。

記事管理端末１０は、ステップＳ３０１で、特定掲載場所２３から記事が削除されたか否かを判定する。この処理は、例えば、前回確認した際のトップ掲載記事の記事ＩＤ一覧を保持しておき、該一覧と現在のトップ掲載記事の記事ＩＤ一覧を比較することにより可能となる。
特定掲載場所２３から記事が削除されていない場合（ステップＳ３０１：Ｎの場合）は、ステップＳ３０１の処理を再度実行する。
一方、特定掲載場所２３から記事が削除されていた場合（ステップＳ３０１：Ｙの場合）、記事管理端末１０はステップＳ３０２で削除記事の閲覧数を取得し、続くステップＳ３０３で閲覧傾向モデルの更新を行う。

本例では、一つのトップ掲載記事について一回の閲覧傾向モデル更新処理が実行されるため、トップ掲載記事として掲載された全ての記事の閲覧傾向をモデルに反映することができる。即ち、入力情報として利用されないトップ掲載記事が存在しないため、学習漏れが起きない。
また、ある記事がトップ掲載記事として掲載された際の瞬間的な閲覧数の伸びが発生し、そのタイミングで閲覧傾向モデルの更新を行った場合に、イレギュラーな値に基づいた学習が行われてしまう可能性がある。しかし、本例によれば、そのようなイレギュラーな学習が起き得ず、適切な閲覧傾向モデルの生成／更新を行うことができる。

なお、掲載時間と閲覧数の両方を用いてモデルの更新を行ってもよい。例えば、話題性の高さが同等とされた記事Ａと記事Ｂが配信された場合を考える。記事Ａはトップ掲載記事として１時間特定掲載場所２３に見出しが掲載され、記事Ｂはトップ掲載記事として１０分間特定掲載場所２３に見出しが掲載された場合、閲覧数に関しては記事Ａの方が多くなることが一般的である。
このような場合に、掲載時間を考慮せずに閲覧数を用いた閲覧傾向モデル更新処理を行うと、記事Ｂよりも記事Ａの方が閲覧されやすいと判定するモデルが構築されてしまう虞がある。本来、記事Ａと記事Ｂが同等の話題性高さであることから、閲覧数の多さは同等と判定されるべきである。
そこで、掲載時間を用いて閲覧数を正規化した値を入力としたディープラーニングによって閲覧傾向モデル更新処理を行うことを考える。これにより、記事Ａと記事Ｂは同等に閲覧されやすいと判定される閲覧傾向モデルを生成することが可能となる。これは、先の図６に示す閲覧傾向モデル更新処理にも適用することができる。

なお、掲載時間を用いて閲覧数を正規化した値を用いたとしても、閲覧数以外の要素を考慮した結果、記事Ａの方が閲覧されやすいと判定する閲覧傾向モデルや記事Ｂの方が閲覧されやすいと判定する閲覧傾向モデルへと更新される可能性はある。

＜４−４．新着配信記事確認処理＞
記事管理端末１０の掲載判定部１０ｄは、配信社から記事が配信されるたびに、当該配信記事を特定掲載場所２３に掲載するか否かを判定する処理を実行する。
具体的に、図８を参照して説明する。

記事管理端末１０は、ステップＳ４０１で、配信社から配信された新たな配信記事の有無に応じた分岐処理を実行する。
新たな配信記事がない場合（ステップＳ４０１：Ｎの場合）、記事管理端末１０は再度ステップＳ４０１を実行する。

新たな配信記事がある場合（ステップＳ４０１：Ｙの場合）、記事管理端末１０はステップＳ４０２で、掲載傾向モデルを用いた判定処理（第１判定処理）を行う。この処理では、これまでのトップ掲載記事の傾向と新着記事の特徴が合致しているか否かを判定する。
判定結果は、新着記事が掲載される可能性が高いと判定した場合の「掲載判定」と、掲載される可能性が低いと判定した場合の「不掲載判定」の２択としてもよいし、０〜１００点などのように多段階であってもよい。

続いて、記事管理端末１０はステップＳ４０３で、閲覧傾向モデルを用いた判定処理（第２判定処理）を実行する。この処理では、トップ掲載記事の中で閲覧数の多い記事の傾向と新着記事の特徴が合致しているか否かを判定する。判定結果は、閲覧数が所定数以上となると判定した場合の「閲覧判定」と、閲覧数が所定数未満となると判定した場合の「非閲覧判定」とによる２択としてもよいし、０〜１００点などのように多段階であってもよい。

最後に、記事管理端末１０はステップＳ４０４で、総合判定処理を実行する。総合判定処理では、第１判定処理の判定結果と第２判定処理の判定結果を踏まえて、新着記事をトップ掲載記事とすべきか否か、即ちトップ掲載記事の候補であるか否かを判定する処理である。

総合判定処理の具体的な処理内容について、図９を参照して説明する。なお、図９に示すフローチャートは、第１判定処理及び第２判定処理の判定結果が共に２択（掲載判定／不掲載判定、閲覧判定／非閲覧判定）の場合についての一例である。
記事管理端末１０は、総合判定処理におけるステップＳ５０１で、第１判定処理で掲載判定となったか否かを判定する。
第１判定処理の判定結果が不掲載判定である場合（ステップＳ５０１：Ｎの場合）、記事管理端末１０は図９に示す一連の処理を終了する。

一方、第１判定処理の判定結果が掲載判定である場合（ステップＳ５０１：Ｙの場合）、記事管理端末１０はステップＳ５０２で第２判定処理による分岐処理を実行する。
具体的には、第２判定処理の判定結果が閲覧判定であるか否かによる分岐処理とされ、閲覧判定である場合（ステップＳ５０２：Ｙの場合）、記事管理端末１０は続くステップＳ５０３で現在の判定対象の配信記事を第１種掲載候補記事に分類する。
一方、非閲覧判定である場合（ステップＳ５０２：Ｎの場合）、記事管理端末１０は続くステップＳ５０４で判定対象の配信記事を第２種掲載候補記事に分類する。
即ち、第１種掲載候補記事は、第１判定処理で掲載判定とされ、第２判定処理で閲覧判定とされた配信記事である。
また、第２種掲載候補記事は、第１判定処理で掲載判定とされ、第２判定処理で非閲覧判定とされた配信記事である。

次に、記事管理端末１０はステップＳ５０５で、入替判定処理を実行する。該処理は、新たに第１種掲載候補記事または第２種掲載候補記事とされた配信記事と、既にトップ掲載記事として特定掲載場所２３に掲載されている記事を入れ替えるか否かを判定する処理である。

入替判定処理の例について、図１０を参照して説明する。
先ず、記事管理端末１０はステップＳ６０１で、削除候補記事を選択する処理を実行する。この処理では、トップ掲載記事の中から削除候補の記事を選択する。
例えば、削除候補記事選択の第１例として、各トップ掲載記事について、掲載開始時刻と現在時刻との差分を掲載経過時間として取得し、掲載経過時間が最も長い記事を削除候補記事とする。これにより、第１種掲載候補記事または第２種掲載候補記事とされた記事が配信された場合には、確実にトップ掲載記事との入れ替えが行われて掲載される。

削除候補記事選択の第２例として、掲載経過時間が所定時間（例えば１０分など）以上となった記事のうち、最も閲覧数が少ないものを削除候補記事としてもよい。これによれば、ユーザにあまり閲覧されないような記事を削除することができる。

削除候補記事選択の第３例として、掲載経過時間が所定時間（例えば１０分など）以上となった記事のうち、最も閲覧数が多いものを削除候補記事としてもよい。これによれば、既に多くのユーザに閲覧され、今後の閲覧数の増加が見込めない記事を削除することができる。

削除候補記事選択の第４例として、トップ掲載記事の数が１０個とされており、第１種掲載候補記事に分類された後にトップ掲載記事として掲載された第１種掲載記事と第２種掲載候補記事に分類された後にトップ掲載記事として掲載された第２種掲載記事がある場合を考える。更に、トップ掲載記事に掲載される記事の割合を、第１種掲載候補記事を７割（＝７個）、第２種掲載候補記事を３割（＝３個）と設定し、各割合を変えないように入替判定処理を行う。即ち、新たな配信記事が第１種掲載候補記事に分類されている場合は、トップ掲載記事のうち第１種掲載記事の中から削除候補記事を選択し、新たな配信記事が第２種掲載候補記事に分類されている場合は、トップ掲載記事のうち第２種掲載記事の中から削除候補記事を選択する。このとき、同種（第１種、第２種の何れか）の記事の中で掲載時間が最も長い記事を削除候補記事としてもよいし、第２例のように掲載経過時間が所定時間以上であって閲覧数が最も少ないものを削除候補記事としてもよいし、第３例のように掲載経過時間が所定時間以上であって閲覧数が最も多いものを削除候補記事としてもよい。

削除候補記事選択の第５例として、記事の重要度（優先度）を考える。例えば、複数の配信社から同内容の記事が配信されている場合、その記事は世間的に重要度の高い記事とみなす事ができる。更に、関連の記事の数が多いほど重要度が高い。
例えば、重要度と第１例を組み合わせ、掲載経過時間に重要度を考慮したオフセットを加える。具体的には、重要度が高いトップ掲載記事については、掲載経過時間にマイナスの値（−２０分など）のオフセット値を加えることにより、重要度の高いトップ掲載記事について削除候補記事となりにくいようにする。オフセットの値は、重要度が高いほど低い（−３０分や−４０分など）値としてもよい。
また、重要度と第２例や第３例を組み合わせ、所定時間を重要度によって変えることが考えられる。具体的には、重要度が高い程、所定時間を長い時間（２０分や３０分）とすることにより、重要度が高いトップ掲載記事について削除候補記事となりにくいようにする。
更に、重要度を第４例と組み合わせることにより、重要度の高いトップ掲載記事について削除候補記事となりにくいようにすることも可能である。

削除候補記事選択の第６例として、世間的に重要度が極めて高いトップ掲載記事については、続報記事が配信記事として配信されて第１種掲載候補記事または第２種掲載候補記事として分類された場合のみ削除候補とし、それ以外の場合については削除候補記事とならないようにすることが考えられる。例えば、震災や戦争についての記事などが挙げられる。このような世間的に重要度が極めて高い記事がトップ掲載記事として既に掲載されている場合は、その記事枠については続報記事のみ入れ替えが行われるようにする。即ち、削除候補記事は、重要度が極めて高い記事を除いた残りの記事の中から選択することとなる。このときの選択方法は、前述の第１例乃至第５例の何れを用いてもよい。
このように、世間的に重要度が極めて高い記事を削除候補記事から外すことで、ユーザが当該ニュース掲載サイトをいつ訪れたとしても、重要度の極めて高いニュースを容易に閲覧することができ、ニュース掲載サイトとしての使命を果たすことができる。

ステップＳ６０１の削除候補記事選択処理を終えた記事管理端末１０は、ステップＳ６０２で、入替判定を行う。この処理では、ステップＳ６０１で削除候補とされた記事と、図９のステップＳ５０３またはＳ５０４で第１種または第２種掲載候補記事に分類された配信記事とを比較し、入れ替えを行うことが相応しいか否かを判定する。

具体的に、例えば先の削除候補記事選択として、第１例や第２例や第３例を採用した場合には、比較をせずに入れ替えを行うと判定してもよい。これによって、第１種または第２種掲載候補記事に分類された配信記事は無条件で削除候補記事の代わりにトップ掲載記事として掲載される。
また、例えば先の削除候補記事選択の第５例や第６例のように重要度を考慮した場合には、第１種または第２種掲載候補記事に分類された配信記事についての重要度も考慮し、配信記事の重要度よりも低い重要度のトップ掲載記事がある場合に入れ替えを行ってもよい。但し、この場合には、入れ替えが行われるたびに重要度の高い記事がトップ掲載記事を占めていくため、次第に入れ替えが行われなくなりトップ掲載記事が不変となってしまう可能性がある。従って、重要度は時間の経過と共に降下するように構成してもよいし、トップ掲載記事よりも多少重要度が低かったとしても入れ替えを行うように構成してもよい。

なお、上記した重要度は、高、中、低などの比較的少ない段階となるように評価してもよいし、０〜１００などのように多段階となるように評価してもよい。

ステップＳ６０２で入替判定を行った記事管理端末１０は、図９のステップＳ５０６に移動し入替処理を実行する。この処理により、削除候補記事の代わりに配信記事がトップ掲載記事として特定掲載場所２３に掲載される。

＜４−５．新着配信記事確認処理の別例＞
新着配信記事確認処理の別例について説明する。
別例では、新着配信記事確認処理で行う図８の各処理のうち、ステップＳ４０４の総合判定処理の処理内容が異なるものである。
具体的には、ステップＳ４０２の第１判定処理において、判定結果を０〜１００点とし、ステップＳ４０３の第２判定処理において、判定結果を同様に０〜１００点とする。これによって、ステップＳ４０４の総合判定処理の処理内容が異なる。

図１１を参照して総合判定処理を説明する。
記事管理端末１０の掲載判定部１０ｄは、ステップＳ７０１で第１判定処理の判定結果が第１閾値以上であるか否かによって分岐する処理を行う。第１閾値は、比較的高い点数とされており、例えば７０点とされる。
第１判定処理の判定結果が第１閾値以上である場合（ステップＳ７０１：Ｙの場合）は、記事管理端末１０はステップＳ７０２で入替処理を行う。即ち、第１判定処理の判定結果が高い場合は、トップ掲載記事の傾向と配信記事の特徴の合致度合いが高いとみなす事ができることから、無条件で入替処理を行うことにより、新たな配信記事をトップ掲載記事として掲載する。

一方、第１判定処理の判定結果が第１閾値未満である場合（ステップＳ７０１：Ｎの場合）、記事管理端末１０はステップＳ７０３で第１判定処理の判定結果が第２閾値以上であるか否かを判定する。第２閾値は第１閾値よりも低い数値とされ、例えば５０点とされる。
第１判定処理の判定結果が第２閾値未満である場合（ステップＳ７０３：Ｎの場合）、記事管理端末１０は図１１に示す一連の処理を終了する。
一方、第１判定処理の判定結果が第２閾値以上である場合（ステップＳ７０３：Ｙの場合）、記事管理端末１０はステップＳ７０４の分岐処理に進む。

ステップＳ７０４では、第２判定処理の判定結果が第３閾値以上であるか否かを判定する。第３閾値は、第１閾値及び第２閾値とは無関係に設定される値であり、第１閾値や第２閾値との大小関係は問わない。
第２判定処理の判定結果が第３閾値よりも高い配信記事は、閲覧数が高くなりそうな記事、即ちユーザの興味が高い記事とみなす事ができる。
第２判定処理の判定結果が第３閾値よりも高い場合（ステップＳ７０４：Ｙの場合）、記事管理端末１０はステップＳ７０５で入替判定処理を実行する。
ステップＳ７０５の入替判定処理の対象となる配信記事は、第１判定処理の判定結果が第１閾値未満第２閾値以上とされ、第２判定処理の判定結果が第３閾値以上とされる記事である。即ち、掲載傾向がそこまで高くないがある程度の水準であり、且つ閲覧傾向が高い記事がステップＳ７０５の処理の対象となる記事である。

入替判定処理では、例えば前述した図１０に示す処理を行う。削除候補記事の選択を行い、入替判定を行った記事管理端末１０は、続くステップＳ７０２で入替処理を実行する。
これにより、掲載傾向モデルに合致しなかった記事であってもユーザの関心が高そうな記事については、トップ掲載記事として特定掲載場所２３に掲載される。

＜４−６．新着配信記事確認処理の別例２＞
新着配信記事確認処理の別例２では、記事管理端末１０が掲載傾向モデル生成部１０ｂと閲覧傾向モデル生成部１０ｃを備えておらず、代わりに第１判定処理の判定結果を取得する取得部と、第２判定処理の判定結果を取得する取得部を備えている例について説明する。
例えば、第１判定処理及び第２判定処理の判定結果を取得する処理を、掲載判定部１０ｄが備えている。この場合には、請求項における第１判定結果取得部及び第２判定結果取得部としての役割を掲載判定部１０ｄが担う。

具体的に図１２を参照して説明する。
記事管理端末１０は、新着配信記事確認処理において、ステップＳ８０１の新たな配信記事があるか否かを判定する。新たな配信記事が無い場合、記事管理端末１０は再度ステップＳ８０１の処理を実行する。

なお、本例では、掲載傾向モデルを生成する処理や閲覧傾向モデルを生成する処理、そして、新たな記事が配信されてきたときにそれぞれのモデルを用いた判定処理（第１判定処理、第２判定処理）を実行する情報処理装置が記事管理端末１０とは別に設けられている。
従って、そのような別の情報処理端末が第１判定処理及び第２判定処理を完了したことに応じて記事管理端末１０がステップＳ８０１の処理を実行してもよい。その場合には、ステップＳ８０１では、新たな配信記事の有無を判定する処理ではなく、別の情報処理端末からの入力（トリガ）の有無を判定する処理としてもよい。

新たな配信記事がある場合（ステップＳ８０１：Ｙの場合）、記事管理端末１０はステップＳ８０２で、第１判定処理の判定結果を取得する処理を行い、続くステップＳ８０３で第２判定処理の判定結果を取得する処理を行う。
次に、記事管理端末１０はステップＳ８０４で総合判定処理を実行する。この処理は、図８のステップＳ４０４で説明した同名の処理と同じであるため、詳述を省く。

＜５．第２の実施の形態＞

第２の実施の形態では、管理システム１が管理する一つのニュース掲載サイトだけでなく、他の管理システムが管理するニュース掲載サイトに対しても各種の処理を行う例である。例えば、管理システム１が管理するニュース掲載サイトを「第１のニュース掲載サイト」とし、例えば、他者が運営する管理システムが管理するニュース掲載サイトを「他のニュース掲載サイト」とする。そして、第２の実施の形態では、他のニュース掲載サイトの掲載傾向も加味して第１のニュース掲載サイトの管理を行う。
具体的な処理について述べる。

＜５−１．掲載傾向モデル更新処理＞
本例における掲載傾向モデル更新処理を図１３に示す。掲載傾向モデル更新処理では、対象となるニュース掲載サイトが複数となる。即ち、第１のニュース掲載サイトだけでなく他のニュース掲載サイトについても掲載傾向モデルを生成する。
従って、記事管理端末１０の掲載傾向モデル生成部１０ｂは、ステップＳ９０１で、ニュース掲載サイトを一つ選択する処理を実行する。

続いて記事管理端末１０はステップＳ９０２で、特定の記事掲載場所を確認する。具体的には、ステップＳ９０１で選択したニュース掲載サイト（以降、対象サイト）における特定掲載場所２３に掲載されたトップ掲載記事の一覧を取得する。

次に、記事管理端末１０はステップＳ９０３で、取得したトップ掲載記事の一覧に変更があるか否かを判定する。即ち、対象サイトについて取得した前回のトップ掲載記事の一覧と今回のトップ掲載記事の一覧で差分となる記事があるか否かを判定する。変更がある場合（ステップＳ９０３：Ｙの場合）、記事管理端末１０はステップＳ９０４で新記事抽出（差分となる記事）を抽出する処理を実行し、続くステップＳ９０５で掲載傾向モデルの更新処理を行う。掲載傾向モデルは、ニュース掲載サイトごとに生成され、ここで更新される掲載傾向モデルは、対象サイトについての掲載傾向モデルである。

掲載傾向モデルの更新処理を終えた記事管理端末１０は、ステップＳ９０６で対象の全てのニュース掲載サイトについて処理を終えたか否かによって分岐する処理を実行する。
なお、ステップＳ９０３でトップ掲載記事の一覧に変更が無いと判定した場合についても記事管理端末１０はステップＳ９０６の処理へと遷移する。

対象の全てのニュース掲載サイトについて各処理を終えた場合、記事管理端末１０は図１３に示す一連の処理を終了する。一方、対象の全てのニュース掲載サイトについて処理を終えていない場合、記事管理端末１０はステップＳ９０１で新たな別のニュース掲載サイトを選択し、以降の処理を実行する。
これによって、対象となる全てのニュース掲載サイトについて、掲載傾向モデルの更新処理が実行される。

なお、記事管理端末１０は図１３に示す一連の処理を定期的に実行する。例えば、３０分ごとや１時間ごとに実行される。勿論、各ニュース掲載サイトのトップ掲載記事の一覧が変更されたことをトリガとしてステップＳ９０４，Ｓ９０５の処理が実行されるように構成されていてもよい。

＜５−２．新着配信記事確認処理＞
第２の実施の形態における新着配信記事確認処理について、図１４を参照して説明する。 なお、図８の新着配信記事確認処理で説明した内容については、適宜詳述を省略する。
先ず、記事管理端末１０の掲載判定部１０ｄは、ステップＳ１００１で新たな配信記事の有無を確認し、無い場合はステップＳ１００１を再度実行する。

続いて、記事管理端末１０はステップＳ１００２で、第１のニュース掲載サイトの掲載傾向モデル（メイン掲載傾向モデル）を用いた判定処理（メイン第１判定処理）を実行する。即ち、配信記事について、第１のニュース掲載サイトでは掲載されやすいか否かを判定する処理となる。

次に、記事管理端末１０はステップＳ１００３で、他のニュース掲載サイトの掲載傾向モデル（サブ掲載傾向モデル）を用いた判定処理（サブ第１判定処理）を実行する。即ち、配信記事について、他のニュース掲載サイトでは掲載されやすいか否かを判定する処理となる。

この処理においては、他のニュース掲載サイト一つを対象とした判定処理を行ってもよいし、他のニュース掲載サイトとして複数のサイトを対象とした判定処理を行ってもよい。
複数の他のニュース掲載サイトを対象とする場合、対象とした他のニュース掲載サイトの数だけ判定結果を出力してもよいし、平均的な判定結果を出力してもよい。具体的には、例えば判定結果として０〜１００点（掲載されやすいほど高得点）の多段階で評価する場合を考える。他のニュース掲載サイトとしてサイトＡ、サイトＢ、サイトＣを対象とする場合に、サイトＡで８０点、サイトＢで６０点、サイトＣで４０点であれば、平均値である６０点を判定結果としてもよい。また、最大値である８０点を判定結果としてもよいし、最小値である４０点を判定結果としてもよい。

また、サイトＡ，Ｂ，Ｃの中で第１のニュース掲載サイトとの関連性を考慮した重みを付けて平均値を算出し、判定結果としてもよい。
例えば、第１のニュース掲載サイトの主たる掲載記事がスポーツに関するものであり、サイトＡも同様に主たる掲載記事がスポーツに関するものである場合、サイトＡを重要な他のニュース掲載サイトとして重みを増して評価してもよい。これにより、類似したユーザが閲覧しそうなサイトＡを意識して第１のニュース掲載サイトの掲載判定を行うことが可能となる。

続いて、記事管理端末１０はステップＳ１００４で、第１のニュース掲載サイトの閲覧傾向モデルを用いた判定処理（第２判定処理）を実行する。
最後に、記事管理端末１０はステップＳ１００５で総合判定処理を実行し、再度ステップＳ１００１の処理へ遷移する。

＜５−３．総合判定処理＞
図１４のステップＳ１００５の総合判定処理の具体的な処理内容について、図１５を参照して説明する。なお、図９や図１１を参照して既に説明した部分については、適宜詳述を省略する。

総合判定処理では、記事管理端末１０はステップＳ１１０１で、先のメイン第１判定処理の判定結果が掲載判定であるか否かに応じて分岐する。
メイン第１判定処理の判定結果が不掲載判定である場合、記事管理端末１０は図１５に示す一連の処理を終了する。

一方、掲載判定である場合（ステップＳ１１０１：Ｙの場合）、記事管理端末１０はステップＳ１１０２で、サブ第１判定処理の判定結果が不掲載判定であるか否かに応じて分岐する。
サブ第１判定処理で不掲載判定である場合、記事管理端末１０はステップＳ１１０３で処理対象の配信記事を差分記事と認定する。このような配信記事は、第１のニュース掲載サイトで掲載されるだろうと判定され、他のニュース掲載サイトでは掲載されないだろうと判定された記事であり、即ち他のニュース掲載サイトに対する差別化要因とされる記事である。第２の実施の形態では、他のニュース掲載サイトに対して差別化を図れる差分記事を考慮した処理を行うものであることから、ステップＳ１１０３の処理が必要となる。

続いて、記事管理端末１０はステップＳ１１０４で第２判定処理の判定結果が閲覧判定であるか否かに応じて分岐する。
閲覧判定である場合、記事管理端末１０はステップＳ１１０５で当該配信記事を第１種掲載候補記事に分類する。
一方、非閲覧記事である場合、記事管理端末１０はステップＳ１１０６で当該配信記事を第２種掲載候補記事に分類する。

次に、記事管理端末１０はステップＳ１１０７で入替判定処理を実行し、該判定結果に基づいてステップＳ１１０８で入替処理を実行する。

ここで、ステップＳ１１０７の入替判定処理について、図１０を参照して説明する。
入替判定処理では、記事管理端末１０はステップＳ６０１で、削除候補記事を選択する処理を実行する。
本実施の形態における削除候補記事選択は、先述した他の例（第１例〜第６例）とは異なるものであり、削除候補記事選択の第７例として説明する。

第７例では、トップ掲載記事が差分記事であるか否かを考慮して削除候補記事の選択が行われる。
例えば、トップ掲載記事として掲載されている記事のうち、差分記事に該当する記事は、削除候補記事として選択され難い構成とする。具体的には、第１例や第２例や第３例のように掲載経過時間を考慮する例では、トップ掲載記事のうち差分記事と認定されているものに関しては、掲載経過時間を少なめに算出してもよい。また、第４例のように、第１種掲載記事と第２種掲載記事の配分を考慮する場合であっても、同種の記事の中で差分記事と認定されているものが選択され難いように構成する。
また、第５例や第６例のように重要度を考慮する場合であっても、差分記事と認定されているものが選択され難いように構成する。具体的には、掲載経過時間について、重要度及び差分記事か否かに応じたオフセットを付与する。
また、他の例として、差分記事ではないトップ掲載記事がある場合は、そのような記事を優先的に削除候補記事として選択することで、他のニュース掲載サイトとの差別化をより図ることも可能である。

削除候補記事選択の処理の後、記事管理端末１０はステップＳ６０２で入替判定を行う。ここで、入替判定において、配信記事が差分記事であるか否かを考慮する例について述べる。
新たな配信記事が差分記事と認定されている場合には、必ず記事の入れ替えを行うように判定を行い、新たな配信記事が差分記事と認定されていない場合には、前述のように重要度を考慮した入替判定を行ってもよい。

＜６．第３の実施の形態＞

第３の実施の形態では、図１０のステップＳ６０２で説明した入替判定を記事管理端末１０が行わず、作業者に行わせるものである。具体的に、添付図を参照して説明する。

＜６−１．入替判定処理＞
第３の実施の形態では、入替判定処理に至るまでの各処理については、前述の第１の実施の形態及び第２の実施の形態で説明した如何なる処理であってもよい。例えば、図５に示す掲載傾向モデル更新処理や図６に示す閲覧傾向モデル更新処理を行うことにより各モデルを生成／更新し、該モデルを用いて新着配信記事確認処理を実行する。新着配信記事確認処理では、図９に示す総合判定処理を実行し、該総合判定処理の中で例えばステップＳ５０５に示す入替判定処理を行う。

第３の実施の形態における入替判定処理（ステップＳ５０５やステップＳ７０５、ステップＳ１１０７）の一例を図１６に示す。

入替判定処理では、記事管理端末１０はステップＳ１２０１で、削除候補記事の選択を行う。この処理は、前述の何れの手法であってもよい。
続いて、記事管理端末１０はステップＳ１２０２で削除候補記事の提示処理を行う。この処理は、例えば、ウェブサーバ１１と連携することにより実現してもよい。具体的には、ウェブサーバ１１に提示のためのウェブページ生成を行わせることにより、作業者への通知を行う。

提示のためのウェブページ（提示ページ）には、入れ替え候補となる新たな配信記事と、削除候補として選択された記事と、他のトップ掲載記事についての情報が含まれる。また、それぞれの配信時間や掲載開始時間や掲載経過時間等の情報を含んでいてもよい。
更に、提示ページには、入れ替えるか否かの意思表示を示すためのボタンや、削除記事を選択するためのラジオボタン等の操作子が提示される。具体的には、「入れ替える」と表示された入替実行ボタン３０、「入れ替えない」と表示された入替非実行ボタン３１、新着の配信記事情報表示欄３２、入れ替える場合にどの記事を削除するかを選択させるトップ掲載記事一覧３３及びラジオボタン３４が掲載される（図１７参照）。

作業者は、上記の提示ページを閲覧し、内容を吟味した上で入替実行ボタン３０と入替非実行ボタン３１のいずれかの操作子を押下する。
記事管理端末１０は、操作子に対する押下操作を受け付ける入力受付処理をステップＳ１２０３で実行する。即ち、該操作が行われるまで、記事管理端末１０はステップＳ１２０３で待機する。

最後に、記事管理端末１０は作業者の操作に応じた入替処理を実行する（ステップＳ５０６、ステップＳ７０２、ステップＳ１１０８）。勿論、作業者が入替非実行ボタン３１を押下した場合には、入替処理は実行されない。

なお、本実施の形態では、作業者の人手によって特定掲載場所２３に掲載される記事の最終的な選択が行われる例を説明した。また、第１の実施の形態や第２の実施の形態では、記事管理端末１０が特定掲載場所２３に掲載される記事の最終的な選択を行う例を説明した。
しかし、最終的な記事選択は必ずしも作業者と記事管理端末１０の何れか一方が行わなければならないわけでは無く、例えば時間帯に応じて切り換えてもよい。
例えば、日中作業者が勤務している時間帯に関しては、作業者による最終的な記事選択操作を必要とする構成とし、夜間などのそれ以外の時間帯に関しては作業者の操作を必要とせず最終的な記事選択まで含めて記事管理端末１０が実行するように構成してもよい。
この構成によれば、作業者が定期的に特定掲載場所２３へ掲載する記事を選択する操作を行うことにより、機械学習による掲載傾向モデルの更新が自ずと行われるため、ニュース掲載サイトの方向性の変化に応じて掲載傾向モデルが自動的に最適化され、適切な掲載傾向モデルの構築及び記事の選択を行うことが可能となる。

更には、記事管理端末１０による記事選択（或いは掲載候補の提示）のための処理を実行する時間帯と実行しない時間帯を設けてもよい。
例えば、午後６時から午前９時５９分５９秒までは、記事管理端末１０が記事選択や掲載候補の提示のための処理を実行するが、それ以外の時間帯は記事選択や掲載候補の提示のための処理を行わずに、全ての作業を作業者が行うようにしてもよい。
このようにすることでも、掲載傾向モデルの最適化が行われる。特に、記事管理端末１０が選択して提示した掲載候補となる記事以外から作業者の手作業によって記事が選択された場合には、掲載傾向モデルが最適でないこととなり、掲載傾向モデルの最適化によって掲載傾向モデルが大きく変更される可能性がある。即ち、掲載傾向モデルの方向性の大きな転換を行うことができる。

＜７．変形例＞

上記の各例では、ニュース掲載サイトのトップページに設けられた特定掲載場所２３に掲載される記事（トップ掲載記事）について各種の処理を実行する例を説明したが、それ以外のウェブページに掲載される記事に対しても同様の構成で記事の選択及び掲載を行うことが可能である。

例えば、ニュース掲載サイトのトップページ以外の場所に、特集ページとして「オリンピック」に関するニュース記事が集められる記事掲載場所が設けられている例を挙げる。
このような場合には、例えば、図５に示す掲載傾向モデル更新処理において、特定掲載場所をオリンピックに関するニュース記事が集められる記事掲載場所とすることにより該掲載場所に応じた掲載傾向モデルが構築される。

更に、図８に示す新着配信記事確認処理においては、ステップＳ４０１の処理で新たな配信記事があるか否かを確認する代わりに、オリンピックに関する新たな配信記事があるか否かを確認する処理を実行することにより、特集ページに設けられた記事掲載場所に適した処理を行うことが可能である。
このような構成とすることで、ニュース掲載サイトの各所に設けられた記事掲載場所について、それぞれ適切な掲載記事の選択及び掲載を行うことが可能となる。

＜８．まとめ＞

上記の各例で説明したように、記事管理端末１０は、配信記事を受信する記事受信部（管理部１０ａ）と、選択されたニュース掲載サイト（第１のニュース掲載サイト）における特定の記事掲載場所（特定掲載場所２３）に掲載された記事の特徴量を用いた機械学習（例えばディープラーニング）によって生成された特定の記事掲載場所の掲載傾向モデルによって得られる配信記事についての第１判定結果を取得する第１判定結果取得部（掲載判定部１０ｄ）と、特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習（例えばディープラーニング）によって生成された特定の記事掲載場所の閲覧傾向モデルによって得られる配信記事についての第２判定結果を取得する第２判定結果取得部（掲載判定部１０ｄ）と、第１判定結果と第２判定結果を用いて、記事提供元（配信社端末３）から配信される記事を特定の記事掲載場所に掲載するか否かを判定する掲載判定部１０ｄと、を備えている。
ニュース掲載サイトには毎日各種の新着記事が配信され、その件数は数千件〜数万件にも及ぶ。そのような大量な新着記事から、ポータルサイトのトップページのような特定の記事掲載場所に掲載する注目記事を選別することは容易ではなく、作業者の負担が大きい。
このような状況を鑑みて、上記した情報処理装置としての記事の管理システムでは、例えば機械学習によって生成した掲載傾向モデル及び閲覧傾向モデルを利用することにより得られた判定結果を用いて、自動で新着記事の中から特定の記事掲載場所に掲載する記事（特定掲載記事）が選別される。
これにより、作業者の処理負担を大幅に軽減すると共に、配信記事の受信から特定掲載場所２３に掲載される記事の選別までの時間を短縮することができ、配信記事が速やかに特定掲載場所２３に掲載されるため、高い速報性を備えたニュース掲載サイトを提供することが可能となる。
特に、そのニュース掲載サイトの特定掲載場所２３へ過去に掲載された記事からの学習を行うことにより、当該ニュース掲載サイトの特定掲載場所２３の掲載傾向（記事の内容の傾向）に沿った記事が選択されやすくすることができ、そのニュース掲載サイトの独自性を確保するような掲載記事判定を行うことができる。
具体的には、スポーツに関する配信記事を掲載するニュース掲載サイトであっても、試合結果や競技結果を重視するもの、競技者の人間性を重視するもの、競技までの過程などを重視するもの、或いは特定の競技を重視するものなど、サイトごとに方向性の違いが考えられる。
上記構成によれば、そのようなニュース掲載サイトごとの方向性（独自性）に沿った掲載記事が選択を行うことができる。

また、第２の実施の形態で説明したように、第１判定結果取得部（掲載判定部１０ｄ）は、選択されたニュース掲載サイト（第１のニュース掲載サイト）以外の他のニュース掲載サイトについての掲載傾向モデルによって得られる配信記事についての第１判定結果（サブ第１判定結果）を取得し、掲載判定部１０ｄは、配信記事について、選択されたニュース掲載サイトについての第１判定結果（メイン第１判定結果）が掲載判定とされ、他のニュース掲載サイトについての第１判定結果（サブ第１判定結果）が不掲載判定とされた場合に、当該判定の対象となった配信記事を他のニュース掲載サイトに対する差分記事として特定の記事掲載場所（特定掲載場所２３）に掲載され易いように扱ってもよい。
他のニュース掲載サイトにおいて掲載されずに選択されたニュース掲載サイトで掲載されると判定した差分記事が、選択されたニュース掲載サイトに掲載されやすくすることで、他のニュース掲載サイトとの差別化が図られる。即ち、ニュース掲載サイトの方向性（独自性）をより強調したニュース掲載サイトを生成することが可能となる。
これにより、選択されたニュース掲載サイトを特定のユーザにとって魅力のあるニュース掲載サイトとすることができる。
そして、他のニュース掲載サイトとの差分が総合判定処理に反映されることにより、他のニュース掲載サイトとの差別化が自動的に図られ、人手に頼らずにニュース掲載サイトの方向性を汲み取った記事が特定掲載場所に掲載される記事として選択されやすくなる。
また、選択されたニュース掲載サイトの配信記事と他のニュース掲載サイトの配信記事は、必ずしも同じとは限らない。即ち、他のニュース掲載サイトにのみ配信される記事なども存在する。このような場合に、他のニュース掲載サイトに配信された記事全てを把握しなくても済むような構成とされている。
即ち、本構成によれば、他のニュース掲載サイトについての掲載傾向モデルは、当該他のニュース掲載サイトの特定の記事掲載場所に掲載された記事を用いた機械学習によって生成される。従って、他のニュース掲載サイトの特定の記事掲載場所に掲載された記事の把握は必要である。しかし、他のニュース掲載サイトについての第１判定結果は、自身が管理する選択されたニュース掲載サイトに配信された記事について行うように構成されている。即ち、管理システム１が管理する選択されたニュース掲載サイトの配信記事を用いて他のニュース掲載サイトについての第１判定結果を行うものである。
これにより、他のニュース掲載サイトについて配信された記事全てを把握する必要はなく、他のニュース掲載サイトの特定掲載場所２３に掲載された記事のみを把握すればよいため、処理負担の軽減が図られる。

更に、第１の実施の形態における新着配信記事確認処理で説明したように、掲載判定部１０ｄは、選択されたニュース掲載サイトについての第１判定結果が掲載判定とされ、選択されたニュース掲載サイトについての第２判定結果が閲覧判定とされた記事については、掲載判定としてもよい。
特定掲載場所２３の掲載傾向に合致し閲覧傾向にも合致した記事は、ニュース掲載サイトにとって当然に掲載すべき記事である可能性が高い。そして、本構成の掲載判定部１０ｄによれば、そのような記事を確実に掲載判定とすることができる。
従って、特定の記事掲載場所に掲載すべき記事を見逃してしまうことの防止が図られる。

更にまた、第１の実施の形態における新着配信記事確認処理で説明したように、掲載判定部１０ｄは、選択されたニュース掲載サイトについての第１判定結果が掲載判定とされ、選択されたニュース掲載サイトについての第２判定結果が非閲覧判定とされた記事のうち少なくとも一部の記事については掲載判定としてもよい。
ニュース掲載サイトには、閲覧数が多いことが予想されるために特定の記事掲載場所に掲載される記事もあれば、ニュース掲載サイトの特性として閲覧数に関わらず特定の記事掲載場所に掲載すべき記事もある。本構成によれば、閲覧数が増えるとは限らない記事、即ち第２判定処理において非閲覧判定とされた記事についても、掲載判定部は掲載すると判定する場合がある。
これにより、閲覧数によらず特定の記事掲載場所に掲載すべき記事も掲載判定とされるため、そのような記事を人手で探し出す手間を省くことができる。

加えて、第３の実施の形態で説明したように、掲載判定部１０ｄによる掲載判定（図１０の入替判定処理）は、特定の時間帯のみ行ってもよい。
例えば、特定の時間帯以外は作業者によって特定掲載場所２３に掲載する記事が選別されるようにし、その選別結果を用いて掲載傾向モデルと閲覧傾向モデルの調整を行うことが可能となる。
これにより、例えば、人手によって特定掲載場所２３に掲載する記事として選択されて掲載された記事について追加で分析（学習）することができ、掲載傾向モデルを最適な状態で保つことが可能となる。
また、ニュース掲載サイトの傾向が変わった場合でも、継続的な分析（学習）を続けることにより、傾向の変化に追随した適切な記事選択が行われる。

そして、第１の実施の形態における閲覧傾向モデル更新処理で説明したように、第２判定結果取得部（掲載判定部１０ｄ）は、特定の記事掲載場所（特定掲載場所２３）に掲載された新たな記事についての閲覧数に基づいて更新された閲覧傾向モデルを用いた第２判定結果を取得してもよい。
これにより、ニュース掲載サイトに来訪するユーザ層に変化が起きた場合のように、閲覧されやすい記事が変化した場合でも、新たに特定掲載場所２３に掲載された記事についての閲覧数の傾向が追加で学習されて第２判定結果に反映される。
管理システム１（記事管理端末１０）は、そのような第２判定結果を用いることにより、閲覧傾向の変化に沿った掲載判定を行うことができる。

また、第３の実施の形態で説明したように、掲載判定部１０ｄが掲載すると判定した記事を作業者に提示する提示部１０ｅと、作業者により選択された記事を特定の記事掲載場所（特定掲載場所２３）に掲載する記事として決定する掲載記事決定部１０ｆと、を備えていてもよい。
即ち、掲載判定部１０ｄによって掲載すると判定された記事がそのまま特定記載記事として掲載されることはなく、作業者の目視による検査が行われた後に掲載される。
従って、掲載傾向モデルや閲覧傾向モデルが不完全であることにより意図しない記事が特定掲載場所２３に掲載されてしまうことが防止される。
また、作業者の目視による検査の工程が加わったとしても、膨大な記事を全て目視検査するものではなく提示部によって提示された記事のみを目視検査する構成とされているため、大幅な作業時間の短縮を図ることができる。即ち作業時間を短縮とニュース掲載サイトの信頼性の確保の双方をバランスよく達成することができる。

更に、変形例で説明したように、特定の記事掲載場所（特定掲載場所２３）が特定のジャンル（例えばオリンピック）に属する記事を集めたウェブページに設けられている場合において、掲載判定部１０ｄは、記事提供元（配信社端末３）から配信される記事のうち特定のジャンルに属する記事に対して判定を行ってもよい。
特定のテーマに沿った特集ページであっても、機械学習を用いて生成された各モデルを利用した掲載判定が行われる。
即ち、その結果掲載すると判定された記事はテーマに沿ったものとされるため、特集ページの意図に沿った記事が選択されて掲載される。

上記した各種の構成及び処理は、それぞれ適宜組み合わせることが可能である。例えば、第２の実施の形態と第３の実施の形態を組み合わせ、新たに配信された配信記事が他のニュース掲載サイトに対する差分記事となるかを判定し（ステップＳ１１０１〜Ｓ１１０３）、配信記事の代わりに特定掲載場所２３から削除する記事の候補を選択し（削除候補記事選択：ステップＳ１２０１）、その選択結果等を作業者に提示する提示処理を行う。更に、作業者の操作に応じた入力受付処理（ステップＳ１２０３）を行い、特定掲載場所２３の更新を行ってもよい。

＜９．プログラム及び記憶媒体＞

実施の形態のプログラムは、記事管理端末１０の演算処理装置（ＣＰＵ等）に各種の処理を実行させるプログラムである。

実施の形態のプログラムは、配信記事を受信する記事受信機能を演算処理装置に実行させる。
また、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された特定の記事掲載場所の掲載傾向モデルによって得られる配信記事についての第１判定結果を取得する第１判定結果取得機能を演算処理装置に実行させる。
更に、特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された特定の記事掲載場所の閲覧傾向モデルによって得られる配信記事についての第２判定結果を取得する第２判定結果取得機能を演算処理装置に実行させる。
そして、第１判定結果と第２判定結果を用いて、記事提供元から配信される記事を特定の記事掲載場所に掲載するか否かを判定する掲載判定機能を演算処理装置に実行させる。
即ちこのプログラムは、情報処理装置の演算処理装置に対して図５乃至図１６に示す各処理を実行させるプログラムである。

このようなプログラムにより、上述した記事管理端末１０としての１または複数の情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのＨＤＤや、ＣＰＵを有するマイクロコンピュータ内のＲＯＭ等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納（記憶）しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ、インターネットなどのネットワークを介してダウンロードすることもできる。

１ 管理システム、１０ 記事管理端末、１０ａ 管理部、１０ｂ 掲載傾向モデル生成部、１０ｃ 閲覧傾向モデル生成部、１０ｄ 掲載判定部、１０ｅ 提示部、１０ｆ 掲載記事決定部、１１ ウェブサーバ、２ 通信ネットワーク、３ 配信社端末、４ ユーザ端末、２３ 特定掲載場所、５０ 記事ＤＢ、５１ ユーザＤＢ、５２ コメントＤＢ

Claims (11)

1. 配信記事を受信する記事受信部と、
   選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得部と、
   前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得部と、
   前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定部と、を備えた
   情報処理装置。
2. 前記第１判定結果取得部は、前記選択されたニュース掲載サイト以外の他のニュース掲載サイトについての掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得し、
   前記掲載判定部は、前記配信記事について、前記選択されたニュース掲載サイトについての前記第１判定結果が掲載判定とされ、前記他のニュース掲載サイトについての前記第１判定結果が不掲載判定とされた場合に、当該判定の対象となった配信記事を前記他のニュース掲載サイトに対する差分記事として前記特定の記事掲載場所に掲載され易いように扱う
   請求項１に記載の情報処理装置。
3. 前記掲載判定部は、前記選択されたニュース掲載サイトについての前記第１判定結果が掲載判定とされ、前記選択されたニュース掲載サイトについての前記第２判定結果が閲覧判定とされた記事については、掲載判定とする
   請求項１に記載の情報処理装置。
4. 前記掲載判定部は、前記選択されたニュース掲載サイトについての前記第１判定結果が掲載判定とされ、前記選択されたニュース掲載サイトについての前記第２判定結果が非閲覧判定とされた記事のうち少なくとも一部の記事については掲載判定とする
   請求項１に記載の情報処理装置。
5. 前記掲載判定部による掲載判定は、特定の時間帯のみ行う
   請求項１に記載の情報処理装置。
6. 前記第２判定結果取得部は、前記特定の記事掲載場所に掲載された新たな記事についての閲覧数に基づいて更新された前記閲覧傾向モデルを用いた前記第２判定結果を取得する
   請求項１に記載の情報処理装置。
7. 前記掲載判定部が掲載すると判定した記事を作業者に提示する提示部と、
   前記作業者により選択された記事を前記特定の記事掲載場所に掲載する記事として決定する掲載記事決定部と、を備えた
   請求項１に記載の情報処理装置。
8. 前記特定の記事掲載場所が特定のジャンルに属する記事を集めたウェブページに設けられている場合において、
   前記掲載判定部は、前記記事提供元から配信される記事のうち前記特定のジャンルに属する記事に対して前記判定を行う
   請求項１に記載の情報処理装置。
9. 配信記事を受信する記事受信ステップと、
   選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得ステップと、
   前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得ステップと、
   前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定ステップと、を
   情報処理装置が実行する情報処理方法。
10. 配信記事を受信する記事受信機能と、
    選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得機能と、
    前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得機能と、
    前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定機能と、を
    コンピュータに実行させるプログラム。
11. 配信記事を受信する記事受信機能と、
    選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第１判定結果を取得する第１判定結果取得機能と、
    前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第２判定結果を取得する第２判定結果取得機能と、
    前記第１判定結果と前記第２判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定機能と、を
    コンピュータに実行させるプログラムを記憶したコンピュータが読み取り可能な記憶媒体。

Images