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

情報処理装置、情報処理方法、プログラム、記憶媒体 Download PDF

Info

Publication number
JP6539772B1
JP6539772B1 JP2018147466A JP2018147466A JP6539772B1 JP 6539772 B1 JP6539772 B1 JP 6539772B1 JP 2018147466 A JP2018147466 A JP 2018147466A JP 2018147466 A JP2018147466 A JP 2018147466A JP 6539772 B1 JP6539772 B1 JP 6539772B1
Authority
JP
Japan
Prior art keywords
article
publication
determination
specific
determination result
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018147466A
Other languages
English (en)
Other versions
JP2020024489A (ja
Inventor
愼吾 原澤
愼吾 原澤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Rakuten Group Inc
Original Assignee
Rakuten Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rakuten Inc filed Critical Rakuten Inc
Priority to JP2018147466A priority Critical patent/JP6539772B1/ja
Application granted granted Critical
Publication of JP6539772B1 publication Critical patent/JP6539772B1/ja
Publication of JP2020024489A publication Critical patent/JP2020024489A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

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

Description

本発明は情報処理装置、情報処理方法、プログラム、記憶媒体に関し、特にニュース掲載サイトの特定の記事掲載場所に掲載する記事を選別する技術に関する。
ニュース記事を閲覧可能なウェブサイト(以降、ニュース掲載サイト)には、多数の記事群の中から閲覧者に優先的に閲覧させたい記事を提供するための特定の記事掲載場所が設けられている。
特定の記事掲載場所は、例えば、ニュース掲載サイトのトップページに設けられている。このような特定の記事掲載場所に何れの記事を掲載するかを決定することは重要である。例えば、以下に示す特許文献1では、記事の選択方法として、ユーザに対して適合性の高いコンテンツ(ニュース記事)を提供する構成が記載されている。
特開2006−227925号公報
ところで、ニュース掲載サイトでは、ユーザが興味を持つユーザ受けのいい記事をトップページのような特定の記事掲載場所に掲載することは重要であるが、ニュース掲載サイトの特性上、公共性が高い記事も該特定の記事掲載場所に掲載すべきという事情がある。
また、ニュース掲載サイトが他のニュース掲載サイトとは異なる独自性を有することにより、他のニュース掲載サイトとの差別化を図ることも重要である。
本発明は、このような事情を鑑みてなされたものであり、ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載すると共に、他のニュース掲載サイトとは異なる独自性を有するように掲載記事を選択する環境を提供することを目的とする。
本発明に係る情報処理装置は、配信記事を受信する記事受信部と、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第1判定結果を取得する第1判定結果取得部と、前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第2判定結果を取得する第2判定結果取得部と、前記第1判定結果と前記第2判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定部と、を備えたものである。
ニュース掲載サイトには毎日各種の新着記事が配信され、その件数は数千件〜数万件にも及ぶ。そのような大量な新着記事から、ポータルサイトのトップページのような特定の記事掲載場所に掲載する注目記事を選別することは容易ではなく、作業者の負担が大きい。
このような状況を鑑みて、上記した情報処理装置としての記事の管理システムでは、例えば機械学習によって生成した掲載傾向モデル及び閲覧傾向モデルを利用することにより得られた判定結果を用いて、自動で新着記事の中から特定の記事掲載場所に掲載する記事(特定掲載記事)が選別される。
上述した情報処理装置の第1判定結果取得部は、前記選択されたニュース掲載サイト以外の他のニュース掲載サイトについての掲載傾向モデルによって得られる前記配信記事についての第1判定結果を取得し、前記掲載判定部は、前記配信記事について、前記選択されたニュース掲載サイトについての前記第1判定結果が掲載判定とされ、前記他のニュース掲載サイトについての前記第1判定結果が不掲載判定とされた場合に、当該判定の対象となった配信記事を前記他のニュース掲載サイトに対する差分記事として前記特定の記事掲載場所に掲載され易いように扱ってもよい。
他のニュース掲載サイトにおいて掲載されずに選択されたニュース掲載サイトで掲載されると判定した差分記事が、選択されたニュース掲載サイトに掲載されやすくすることで、他のニュース掲載サイトとの差別化が図られる。
上述した情報処理装置の掲載判定部は、前記選択されたニュース掲載サイトについての前記第1判定結果が掲載判定とされ、前記選択されたニュース掲載サイトについての前記第2判定結果が閲覧判定とされた記事については、掲載判定としてもよい。
掲載傾向に合致し閲覧傾向にも合致した記事は、ニュース掲載サイトにとって当然に掲載すべき記事である可能性が高い。そして、本構成の掲載判定部によれば、そのような記事を確実に掲載判定とすることができる。
上述した情報処理装置の掲載判定部は、前記選択されたニュース掲載サイトについての前記第1判定結果が掲載判定とされ、前記選択されたニュース掲載サイトについての前記第2判定結果が非閲覧判定とされた記事のうち少なくとも一部の記事については掲載判定としてもよい。
ニュース掲載サイトには、閲覧数が多いことが予想されるために特定の記事掲載場所に掲載される記事もあれば、ニュース掲載サイトの特性として閲覧数に関わらず特定の記事掲載場所に掲載すべき記事もある。本構成によれば、閲覧数が増えるとは限らない記事、即ち第2判定処理において非閲覧判定とされた記事についても、掲載判定部は掲載すると判定する場合がある。
上述した情報処理装置において、前記掲載判定部による掲載判定は、特定の時間帯のみ行ってもよい。
例えば、特定の時間帯以外は作業者によって特定掲載記事が選別されるようにし、その選別結果を用いて掲載傾向モデルと閲覧傾向モデルの調整を行うことが可能となる。
上述した情報処理装置の第2判定結果取得部は、前記特定の記事掲載場所に掲載された新たな記事についての閲覧数に基づいて更新された前記閲覧傾向モデルを用いた前記第2判定結果を取得してもよい。
これにより、ニュース掲載サイトに来訪するユーザ層に変化が起きた場合のように、閲覧されやすい記事が変化した場合でも、新たな特定掲載記事についての閲覧数の傾向が追加で学習されて第2判定結果に反映される。
上述した情報処理装置においては、前記掲載判定部が掲載すると判定した記事を作業者に提示する提示部と、前記作業者により選択された記事を前記特定の記事掲載場所に掲載する記事として決定する掲載記事決定部と、を備えていてもよい。
即ち、掲載判定部によって掲載すると判定された記事がそのまま特定記載記事として掲載されることはなく、作業者の目視による検査が行われた後に掲載される。
上述した情報処理装置においては、前記特定の記事掲載場所が特定のジャンルに属する記事を集めたウェブページに設けられている場合において、前記掲載判定部は、前記記事提供元から配信される記事のうち前記特定のジャンルに属する記事に対して前記判定を行ってもよい。
特定のテーマに沿った特集ページであっても、機械学習を用いて生成された各モデルを利用した掲載判定が行われる。
本発明に係る情報処理方法は、配信記事を受信する記事受信ステップと、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された前記特定の記事掲載場所の掲載傾向モデルによって得られる前記配信記事についての第1判定結果を取得する第1判定結果取得ステップと、前記特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された前記特定の記事掲載場所の閲覧傾向モデルによって得られる前記配信記事についての第2判定結果を取得する第2判定結果取得ステップと、前記第1判定結果と前記第2判定結果を用いて、記事提供元から配信される記事を前記特定の記事掲載場所に掲載するか否かを判定する掲載判定ステップと、を情報処理装置が実行するものである。
この情報処理方法により、ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載するような環境を提供することができる。
本発明に係るプログラムは、上記各ステップに相当する手順を情報処理装置に実行させるプログラムである。本発明に係る記憶媒体は、上記プログラムを記憶したものである。これらにより上述の情報処理装置の処理を実現する。
本発明によれば、ユーザの興味を引く記事と公共性の高い記事の双方をバランスよく特定の記事掲載場所に掲載するような環境を提供することができる。
本発明の実施の形態の記事管理端末を含むネットワークの説明図である。 実施の形態で利用できるコンピュータ装置のブロック図である。 実施の形態の記事管理端末の機能構成の説明図である。 ニュース掲載サイトのトップページの例を説明するための図である。 第1の実施の形態における掲載傾向モデル更新処理のフローチャートである。 第1の実施の形態における閲覧傾向モデル更新処理のフローチャートである。 第1の実施の形態における閲覧傾向モデル更新処理の別例のフローチャートである。 第1の実施の形態における新着配信記事確認処理のフローチャートである。 第1の実施の形態における総合判定処理のフローチャートである。 第1の実施の形態における入替判定処理のフローチャートである。 第1の実施の形態における総合判定処理のフローチャートである。 第1の実施の形態における新着配信記事確認処理の別例2のフローチャートである。 第2の実施の形態における掲載傾向モデル更新処理のフローチャートである。 第2の実施の形態における新着配信記事確認処理のフローチャートである。 第2の実施の形態における総合判定処理のフローチャートである。 第3の実施の形態における入替判定処理のフローチャートである。 第3の実施の形態における提示ページの例を説明するための図である。
以下、実施の形態を次の順序で説明する。
<1.システム構成>
<2.コンピュータ装置のハードウェア構成>
<3.記事管理端末の機能構成及びDB>
<4.第1の実施の形態>
<4−1.掲載傾向モデル更新処理>
<4−2.閲覧傾向モデル更新処理>
<4−3.閲覧傾向モデル更新処理の別例>
<4−4.新着配信記事確認処理>
<4−5.新着配信記事確認処理の別例>
<4−6.新着配信記事確認処理の別例2>
<5.第2の実施の形態>
<5−1.掲載傾向モデル更新処理>
<5−2.新着配信記事確認処理>
<5−3.総合判定処理>
<6.第3の実施の形態>
<6−1.入替判定処理>
<7.変形例>
<8.まとめ>
<9.プログラム及び記憶媒体>
<1.システム構成>

本実施の形態としてのニュース掲載サイトを管理する管理システム1を含むネットワークシステム全体の構成について、図1を用いて説明する。
管理システム1は、例えばインターネット等の通信ネットワーク2を介して、配信社端末3,3,・・・ユーザ端末4,4,・・・と互いに通信可能とされている。
なお、図1に示した通信ネットワーク2の構成は特に限定されるものではなく、上記したインターネット以外にも、例えばイントラネット、エキストラネット、LAN(Local Area Network)、CATV(Community Antenna TeleVision)通信網、仮想専用網(Virtual Private Network)、電話回線網、移動体通信網、衛星通信網などが想定される。
また、通信ネットワーク2の全部又は一部を構成する伝送媒体についても多様な例が想定される。例えばIEEE(Institute of Electrical and Electronics Engineers)1394、USB(Universal Serial Bus)、電力線搬送、電話線などの有線でも、IrDA(Infrared Data Association)のような赤外線、ブルートゥース(登録商標)、802.11無線、携帯電話網、衛星回線、地上波デジタル網などの無線でも利用可能である。
管理システム1は、それぞれコンピュータ装置で構成された記事管理端末10、ウェブサーバ11、記事DB(Database)50、ユーザDB51、コメントDB52等を備えている。これらの各装置は、例えばLAN等のネットワークを介して互いに通信可能とされており、このようなネットワークは通信ネットワーク2と同様に特に限定されるものではない。
管理システム1は、各種のニュース記事(以降単に「記事」と記載することもある)をウェブページ上でユーザに閲覧可能な状態で提供するための各種の機能を備えている。
例えば、記事管理端末10は、配信社が所有する配信社端末3からネットワーク2を介して配信されてくる各記事の管理や、記事に付与するラベル情報(ジャンル情報など)の管理や、ニュース掲載サイトを閲覧するユーザのユーザID(Identification)やパスワードや閲覧履歴情報を管理するユーザ管理のための各種処理を行う。
記事管理端末10は、配信社端末3から配信されてくる記事についての各種処理を行う情報処理装置である。具体的な処理内容については後述する。
ウェブサーバ11は、ニュース掲載サイトとしてのウェブページに関する各処理を実行する。例えば、ユーザ端末4からのHTTP(Hypertext Transfer Protocol)リクエストに基づいて、該当のウェブページデータの生成処理や送信処理を行う。
ウェブページデータは、例えば、HTML(Hypertext Markup Language)やXHTML(Extensible Hypertext Markup Language)などの構造化文書ファイルである。構造化文書ファイルには、ニュースタイトルや記事本文などのテキストデータやニュースごとに用意された画像などの画像データと、それらの配置や表示態様(文字色やフォントや大きさや装飾など)が記述されている。
ウェブページとしては、例えば、ニュース掲載サイトのトップページや、各記事の詳細が掲載された記事個別ページや、ニュースに対して投稿されたコメントを閲覧可能なコメントページなどである。
配信社端末3は、記事を配信する配信社に所属する社員等が使用する情報処理装置である。配信社端末3は、管理システム1に対して新たな記事を配信するための送受信処理や、既に配信済みの記事を修正するための処理が行われる。
なお、配信社は企業である必要はなく、記事の配信を行う記者であってもよい。従って、配信社端末3は記事の配信を行う配信者が使用する配信者端末であってもよい。
ユーザ端末4は、ニュース掲載サイトを管理する管理システム1が提供する各種のサービスを受けるためにユーザが使用する情報処理装置である。具体的には、ニュース掲載サイト上のニュース記事を閲覧する場合などに用いられる。
配信社端末3やユーザ端末4は、例えば、通信機能を備えたPC(Personal Computer)やフィーチャーフォンやPDA(Personal Digital Assistants)、或いは、スマートフォンやタブレット端末などのスマートデバイスなどである。
<2.コンピュータ装置のハードウェア構成>

記事管理端末10やウェブサーバ11をはじめとした各装置(記事DB50、ユーザDB51、コメントDB52、配信社端末3及びユーザ端末4)を構成するコンピュータ装置のハードウェア構成を図2に示す。各コンピュータ装置のCPU(Central Processing Unit)101は、ROM( Read Only Memory)102に記憶されているプログラム、または記憶部108からRAM( Random Access Memory )103にロードされたプログラムに従って各種の処理を実行する。RAM103にはまた、CPU101が各種の処理を実行する上において必要なデータなども適宜記憶される。
CPU101、ROM102、およびRAM103は、バス104を介して相互に接続されている。このバス104には、入出力インタフェース105も接続されている。
入出力インタフェース105には、入力部106、出力部107、記憶部108、通信部109が接続されている。
入力部106はキーボード、マウス、タッチパネルなどにより構成される。
出力部107はLCD(Liquid Crystal Display)、CRT(Cathode Ray Tube)、有機EL(Electroluminescence)パネルなどよりなるディスプレイ、並びにスピーカなどにより構成される。
記憶部108はHDD(Hard Disk Drive)やフラッシュメモリ装置などにより構成される。
通信部109はネットワーク2を介しての通信処理や機器間通信を行う。
入出力インタフェース105にはまた、必要に応じてメディアドライブ110が接続され、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア111が適宜装着され、リムーバブルメディア111に対する情報の書込や読出が行われる。
このようなコンピュータ装置では、通信部109による通信によりデータやプログラムのアップロード、ダウンロードが行われる。またリムーバブルメディア111を介したデータやプログラムの受け渡しが可能である。
CPU101が各種のプログラムに基づいて処理動作を行うことで、記事管理端末10やウェブサーバ11などの各装置(記事DB50、ユーザDB51、コメントDB52、配信社端末3及びユーザ端末4)としての必要な情報処理や通信が実行される。
なお、記事管理端末10やウェブサーバ11などの各装置(記事DB50、ユーザDB51、コメントDB52、配信社端末3及びユーザ端末4)を構成する情報処理装置は、図2のようなコンピュータ装置が単一で構成されることに限らず、複数のコンピュータ装置がシステム化されて構成されてもよい。複数のコンピュータ装置は、LAN等によりシステム化されていてもよいし、インターネット等を利用したVPN等により遠隔地に配置されたものでもよい。複数の情報処理装置には、クラウドコンピューティングサービスによって利用可能なサーバ群(クラウド)としての情報処理装置が含まれてもよい。
情報処理装置の各機能は、情報処理装置においてCPU101でプログラムに応じて実行される処理により実現される機能である。但し以下説明する全部または一部の各構成の処理をハードウェアにより実現してもよい。
また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また各機能は複数の情報処理装置に分散されていてもよい。更に機能の一つが、複数の情報処理装置によって実現されてもよい。
<3.記事管理端末の機能構成及びDB>

記事管理端末10の具体的な構成について、図3を参照して説明する。
記事管理端末10は、管理部10a、掲載傾向モデル生成部10b、閲覧傾向モデル生成部10c、掲載判定部10d、提示部10e、掲載記事決定部10fを備えている。
管理部10aは、配信社によって配信された各記事の管理するための各種処理を行う。
例えば、配信社から配信された記事を受信するための処理や、記事ごとの公開期限に基づく公開制御などの記事管理処理や、ユーザの登録処理やユーザ登録の解除処理などのユーザ管理処理等を行う。
記事の公開期限は、配信社とニュース掲載サイトの運営者の間の契約等により設定され得るものであり、公開期限を過ぎると記事の閲覧が不能とされる。
掲載傾向モデル生成部10bは、ニュース掲載サイトの特定の記事掲載場所に掲載される記事(具体的には、見だしが掲載される記事)の傾向をモデル化した「掲載傾向モデル」を生成するための処理を行う。特定の記事掲載場所に見だしが掲載される記事を、以降の説明においては「トップ掲載記事」と記載する。ここで、「特定の記事掲載場所」がニュース掲載サイトのトップページ設けられた例を挙げる。
図4は、ニュース掲載サイトのトップページ(ウェブページ)の一例を示したものである。
ニュース掲載サイトのトップページ(以降、単にトップページと記載)は、ユーザ端末4上で動作するウェブブラウザ20を用いて閲覧可能である。ウェブブラウザ20には、ウェブページ表示欄21が設けられ、その上部や側部には各種の操作子(ボタンや入力欄)22,22,22・・・が設けられている。
トップページが表示されるウェブページ表示欄21には、検索を行うための入力欄や検索ボタンと共に、トップ掲載記事の見だしが掲載される特定の記事掲載場所(以降、特定掲載場所23)が設けられている。
特定掲載場所23の周辺には、ログイン情報表示欄や広告表示欄、天候表示欄、他サービスへの導線部が配置されている。
特定掲載場所23は、例えば「総合」、「経済」、「社会」、「国際」、「芸能」などの複数のタブを有して構成されている。
本実施の形態では、一例として「総合」のタブにおける特定掲載場所23に掲載されるトップ掲載記事を対象とする。即ち、掲載傾向モデル生成部10bは、「総合」のタブにおける特定掲載場所23に掲載されたトップ掲載記事を入力とした機械学習を行い、掲載傾向モデルを生成する処理を行う。機械学習に用いる具体的な入力としては、トップ掲載記事の見だしや本文、ジャンル情報、配信社等の情報とされる。
このような入力情報(特徴量)による機械学習を経て生成された掲載傾向モデルを用いることにより、新たな記事が特定掲載場所23に掲載されるべきか否かを判定する。このような機械学習は、例えば、ディープラーニングなどを用いることに実現可能である。
なお、掲載傾向モデル生成部10bは、特定掲載場所23に新たな記事が掲載されるごとに、掲載傾向モデルを更新する処理を行ってもよい。
閲覧傾向モデル生成部10cは、少なくとも特定掲載場所23に掲載された記事についての閲覧数の傾向をモデル化した「閲覧傾向モデル」を生成するための処理を行う。
具体的に、閲覧傾向生成処理では、記事の見だしや本文、ジャンル情報、配信社等の記事に関する入力情報を用いた機械学習を行い、閲覧傾向モデルを生成する。生成した閲覧傾向モデルは、新たな記事についての情報を入力することで、当該新たな記事についての閲覧数の予測に用いる。このような閲覧傾向モデルを生成するための機械学習としては、例えばディープラーニングなどを挙げることができる。
なお、閲覧数の傾向だけでなく、閲覧されるユーザの属性の傾向も含めてモデル化することにより、新たに配信された記事がどのようなユーザに閲覧されやすいかを推測可能とされていてもよい。
また、閲覧傾向モデルを生成するために付与する学習用データは、特定掲載場所23に掲載された記事だけでなく、管理システム1が管理するニュース掲載サイトに配信される記事全てを用いてもよい。これにより、ニュース掲載サイトの全記事を対象とした学習が行われ、全記事の中で閲覧されやすい記事の特徴を捉えた閲覧傾向モデルを生成される。
なお、閲覧傾向モデル生成部10cは、記事の閲覧数が更新されるごとや一定時間ごとに、掲載傾向モデルを更新する処理を行ってもよい。
また、特定掲載場所23に掲載された記事の閲覧数を入力として閲覧傾向モデルの更新を行う場合には、特定掲載場所23に掲載された記事がその場所から削除されるタイミングで、当該削除された記事のそれまでの閲覧数を取得して、閲覧傾向モデルの更新を行ってもよい。これにより、閲覧傾向モデルの更新処理の実行回数を少なくすることができ、記事管理端末10の処理負担の軽減が図られる。
掲載判定部10dは、掲載傾向モデル生成部10bが生成した掲載傾向モデルを利用して判定対象の記事が特定掲載場所23に掲載されやすいか否かを判定(推定)する第1判定処理を行う。また、閲覧傾向モデル生成部10cが生成した閲覧傾向モデルを利用して判定対象の記事が閲覧されやすいか否かを判定(推定)する第2判定処理を行う。
第2判定処理では、判定対象記事の閲覧数が所定数以上となると推定した場合に「閲覧される」と判定し、所定数未満となると推定した場合に「閲覧されない」と判定する。また、それ以外の判定方法としては、判定対象記事について推定した閲覧数を例えば3段階(推定した閲覧数が多い順にA判定、B判定、C判定)などで評価してもよい。即ち、ある記事Aは余り閲覧されないと推定してC判定とし、他の記事Bは閲覧数が多くなると推定してA判定としてもよい。勿論、閲覧数の評価結果として0〜100点のような更に多段階の評価結果を付与してもよい。
更に、掲載判定部10dは、第1判定処理の結果と第2判定処理の結果を用いて特定掲載場所23に判定対象の記事を掲載するか否かを判定する総合判定処理を行う。更に、判定対象とされた記事を特定掲載場所23に掲載すると判定した場合、代わりに特定掲載場所23から削除される記事を選定する削除判定処理を行う。
提示部10eは、掲載判定部10dの総合判定処理の結果特定掲載場所23に新たに掲載すると判定した記事を作業者に通知するための処理を行う。この処理では、例えば、管理システム1の運用を行う作業者が使用する情報処理端末の画面上に当該記事がトップ掲載記事の候補として選択されたことを通知するウィンドウなどを表示させる。この処理は、例えば、ウェブサーバ11などと協働することにより、管理のためのウェブページ上で報知されるように構成してもよい。
なお、総合判定処理の結果選択されたトップ掲載記事の候補を作業者に提示せずにそのままトップ掲載記事に掲載する場合は、提示部10eは不要となる。
掲載記事決定部10fは、作業者が選択した選択結果に応じて最終的なトップ掲載記事を決定する。例えば、掲載判定部10dによって記事Aがトップ掲載記事の候補として判定され、提示部10eによって判定結果が作業者に提示される。その際には、記事Aを判定処理に従ってトップ掲載記事に加えるか否かを選択される選択肢が作業者に提示され、その際にトップ掲載記事から削除される削除記事候補(例えば記事B)も提示される。作業者によって、記事Bの代わりに記事Aをトップ掲載記事として選択する意思表示を受けて、掲載記事決定部10fは、トップ掲載記事の一覧を更新する。
掲載記事決定部10fは、その結果をウェブサーバ11に送信する。ウェブサーバ11ではその結果を受けて記事Aを含む新たなトップ掲載記事群を表示させるためのウェブページデータを生成する。
管理システム1には、他にも、ユーザ情報を登録するための処理や、ユーザのログイン操作に対する認証処理などを実現するために必要な各部が設けられている。認証処理は、ユーザ端末4から送信されたログイン情報としてのユーザID(Identification)とログインパスワードを、ユーザDB51に記憶された認証情報と照合する処理である。
このような各部は、記事管理端末10やウェブサーバ11とは異なる情報処理装置に設けられていてもよいし、配信管理端末10やウェブサーバ11に設けられていてもよい。また、複数の情報処理装置を利用して各部の実現が可能とされていてもよい。
尚、管理システム1としての各機能は、情報処理装置におけるCPU101でプログラムに応じて実行される処理により実現される機能である。但し上記の全部又は一部の各構成の処理をハードウェアにより実現してもよい。
また各機能をソフトウェアで実現する場合に、各機能がそれぞれ独立したプログラムで実現される必要はない。一つのプログラムにより複数の機能の処理が実行されてもよいし、一つの機能が複数のプログラムモジュールの連携で実現されてもよい。
また、各機能は複数の情報処理装置に分散されていてもよい。更に、機能の一つが複数の情報処理装置によって実現されていてもよい。
記事管理端末10及びウェブサーバ11が上記の各種機能を実現するために、管理システム1は、記事DB50、ユーザDB51、コメントDB52を備えている。
記事DB50には、配信社から配信される記事が記憶されている。例えば、配信記事ごとに記事を一意に特定可能な記事IDが付与され、該記事IDごとに配信日時、配信社(配信社ID)、公開期限、ジャンルID(複数可)、画像情報(もしくは画像ID)等が紐付けられている。
画像情報は、画像データがそのまま記憶されていてもよいし、別の記憶領域に保存された画像を特定可能な画像IDなどの状態で記憶されていてもよい。
ユーザDB51には、管理システム1が提供する各種サービスを利用するユーザの情報が記憶される。例えば、一人のユーザを特定可能な一つのユーザIDに対して、ユーザ名、ログインパスワード、氏名、年齢、性別、年収、住所、メールアドレス、趣味などの個人的な情報が紐付けられて記憶される。
勿論、これらの情報の全てが記憶されていなくてもよく、記憶された情報量がユーザごとに異なっていてもよい。
コメントDB52には、ユーザによって投稿されるコメントが記憶される。例えば、コメントを一意に特定可能なコメントIDに対して、投稿日時、対象となった記事を特定するための記事ID、他のコメントへのリプライである場合には対象コメントを特定可能な情報(対象コメントID)、コメントに対して他のユーザが同意したか否かを示す同意数情報/非同意数情報等が紐付けられている。
これらの各DB(記事DB50、ユーザDB51、コメントDB52)は、管理システム1を構成する各情報処理装置が必要に応じてアクセス可能とされていればどのような形態で実現されていてもよい。例えば管理システム1と同一システム内の記憶部に各DB(記事DB50、ユーザDB51、コメントDB52)のすべてが形成されていてもよいし、各DB(記事DB50、ユーザDB51、コメントDB52)の一部又は全部が別体、遠隔地等のコンピュータシステムに設けられていてもよい。もちろん各DB(記事DB50、ユーザDB51、コメントDB52)が一つの装置(例えば一つのHDD等)内に形成されている必要はない。また各DB(記事DB50、ユーザDB51、コメントDB52)のそれぞれが、それぞれ1つのDBとして構成される必要もない。例えばユーザDB51に記憶される情報が、複数のユーザDB(例えばログイン用のユーザDBとユーザの興味を推測するためのユーザ情報が記憶されたユーザDBなど)により記憶管理されてもよい。以下説明する各DB(記事DB50、ユーザDB51、コメントDB52)は、実施の形態の処理に関連する情報の記憶部を、それぞれ1つのDBの形態で例示したものに過ぎない。
<4.第1の実施の形態>

第1の実施の形態において記事管理端末10が実行する処理について、添付図を参照しながら説明する。第1の実施の形態では、管理システム1が管理する一つのニュース掲載サイトについて各種の処理を行う。
<4−1.掲載傾向モデル更新処理>
記事管理端末10の掲載傾向モデル生成部10bは、掲載傾向モデルを更新するための処理を適宜実行する。その一例について、図5を参照して説明する。
記事管理端末10は、特定掲載場所23に掲載されたトップ掲載記事のラインナップを確認する処理をステップS101で実行する。この処理では、例えば、特定掲載場所23に掲載された各記事の記事IDを取得する。
続いて、記事管理端末10は、ステップS102で、特定掲載場所23に掲載された記事群に変更があったか否かに応じた分岐処理を行う。即ち、直前のステップS101で取得した記事群と、その前にステップS101を実行した際に取得した記事群に違いがあるか否かを判定する。違いがない場合(ステップS102:Nの場合)、即ちトップ掲載記事に変更がない場合、記事管理端末10は図5に示す一連の処理を終了する。
一方、違いがある場合(ステップS102:Yの場合)、記事管理端末10は続くステップS103で、新着記事の抽出を行う。なお、ステップS103の処理を実行する際、記事管理端末10は次回のステップS102の実行に備えて今回取得したトップ掲載記事の一覧を保持しておく。
新着記事の抽出は、前回取得したトップ掲載記事の一覧に含まれておらず今回取得したトップ掲載記事の一覧に含まれている記事を抽出する処理となる。
次に、記事管理端末10はステップS104で、掲載傾向モデルを更新するための処理を行う。具体的には、ステップS103で抽出した新着記事に関する情報(例えば、記事の見だしや本文、ジャンル情報など)を用いて掲載傾向モデルの更新を行う。この更新処理では、新着記事の特徴に応じて最新の掲載傾向を反映したモデルの構築、即ち、ディープラーニングにおける入力層、隠れ層、出力層の各ノードで用いられる重みやバイアスなどの自動的な最適化が行われる。
なお、特定掲載場所23に掲載された記事(トップ掲載記事)が変更されたことをトリガとして掲載傾向モデルの更新処理を実行してもよい。その場合、掲載傾向モデル生成部10bは、ステップS101及びS102の処理は実行せずに、トリガの発生に基づいてステップS103及びステップS104の処理を実行する。
また、掲載傾向モデルがまだ生成されておらず、掲載傾向モデルを新たに生成する場合においても図5に示す一連の処理が用いられる。
具体的には、特定掲載場所23の確認処理をステップS101で実行し、ステップS102の判定処理を行う。ここで、特定掲載場所23についてのステップS101の処理の実行は今回が初めてである。そのため、前回取得した特定掲載場所23のトップ掲載記事の一覧は存在せず、ステップS102の判定は変更あり(ステップS102:Y)となる。
続いて、ステップS103で新着記事を抽出する処理を実行するが、ここでは、ステップS101で確認したトップ掲載記事の全ての記事が新着記事として扱われる。
最後に、ステップS104で、新着記事の各種の情報を入力として掲載傾向モデルの生成が行われる。
<4−2.閲覧傾向モデル更新処理>
記事管理端末10の閲覧傾向モデル生成部10cは、閲覧傾向モデルを更新するための処理を適宜実行する。その一例について、図6を参照して説明する。
記事管理端末10は、ステップS201で、特定掲載場所23の確認処理を行う。具体的には、特定掲載場所23に見だしが掲載されたトップ掲載記事の記事IDを取得する。
なお、ステップS201から続く一連の処理を実行するタイミングは各種考えられる。例えば、定期的に行ってもよいし、ニュース掲載サイトに対する累積アクセス数が一定数増えるごとに行ってもよい。
続いて、記事管理端末10はステップS202で、トップ掲載記事の閲覧数をそれぞれ取得する。なお、閲覧数の取得は、記事がどの程度閲覧されているかを図るための指標として取得するものである。従って、異なるユーザがどの程度閲覧したかを把握するために、ユニークユーザの閲覧数を取得してもよい。この場合には、同一ユーザが同じ記事を何度閲覧したとしても、1回の閲覧としてカウントされる。
また、閲覧数を取得する代わりに、記事に対して投稿されたコメントの数を取得してもよい。即ち、投稿対象となった記事がどの程度閲覧されているかを図るための指標としてコメント数を用いるものである。コメントはコメントDB52から取得する。
最後に、記事管理端末10はステップS203で閲覧傾向モデルの更新処理を実行する。
具体的には、ステップS202で取得した閲覧数などの指標を用いて閲覧傾向モデルの更新を行う。この更新処理では、各記事の閲覧数の変化、即ち閲覧傾向の変化や、新たに特定掲載場所23に見出しが掲載されたトップ掲載記事についての閲覧数に応じて、最新の閲覧傾向を反映したモデルの構築、即ち、ディープラーニングにおける入力層、隠れ層、出力層の各ノードで用いられる重みやバイアスなどの自動的な最適化が行われる。
なお、閲覧傾向モデルがまだ生成されていない場合、即ち処理対象の特定掲載場所23についてステップS203の処理を初めて行う場合においても、図6に示す一連の処理が用いられる。
具体的には、特定掲載場所23の確認処理をステップS201で実行し、ステップS202で各記事の閲覧数取得を行う。続いて、ステップS203で、トップ掲載記事についての閲覧数の情報を入力として閲覧傾向モデルの生成が行われる。
<4−3.閲覧傾向モデル更新処理の別例>
閲覧傾向モデル更新処理の別例について、図7を参照して説明する。
図6に示した閲覧傾向モデル更新処理は、処理タイミングを定期的とする例や累積アクセス数が一定数増加ごととする例を説明した。本例は、処理タイミングを特定掲載場所23に掲載されたトップ掲載記事のうち、いずれかの記事が特定掲載場所23から削除されたタイミングとする例である。
従って、閲覧傾向モデルの更新回数は、トップ掲載記事の記事数と同等とされる。
記事管理端末10は、ステップS301で、特定掲載場所23から記事が削除されたか否かを判定する。この処理は、例えば、前回確認した際のトップ掲載記事の記事ID一覧を保持しておき、該一覧と現在のトップ掲載記事の記事ID一覧を比較することにより可能となる。
特定掲載場所23から記事が削除されていない場合(ステップS301:Nの場合)は、ステップS301の処理を再度実行する。
一方、特定掲載場所23から記事が削除されていた場合(ステップS301:Yの場合)、記事管理端末10はステップS302で削除記事の閲覧数を取得し、続くステップS303で閲覧傾向モデルの更新を行う。
本例では、一つのトップ掲載記事について一回の閲覧傾向モデル更新処理が実行されるため、トップ掲載記事として掲載された全ての記事の閲覧傾向をモデルに反映することができる。即ち、入力情報として利用されないトップ掲載記事が存在しないため、学習漏れが起きない。
また、ある記事がトップ掲載記事として掲載された際の瞬間的な閲覧数の伸びが発生し、そのタイミングで閲覧傾向モデルの更新を行った場合に、イレギュラーな値に基づいた学習が行われてしまう可能性がある。しかし、本例によれば、そのようなイレギュラーな学習が起き得ず、適切な閲覧傾向モデルの生成/更新を行うことができる。
なお、掲載時間と閲覧数の両方を用いてモデルの更新を行ってもよい。例えば、話題性の高さが同等とされた記事Aと記事Bが配信された場合を考える。記事Aはトップ掲載記事として1時間特定掲載場所23に見出しが掲載され、記事Bはトップ掲載記事として10分間特定掲載場所23に見出しが掲載された場合、閲覧数に関しては記事Aの方が多くなることが一般的である。
このような場合に、掲載時間を考慮せずに閲覧数を用いた閲覧傾向モデル更新処理を行うと、記事Bよりも記事Aの方が閲覧されやすいと判定するモデルが構築されてしまう虞がある。本来、記事Aと記事Bが同等の話題性高さであることから、閲覧数の多さは同等と判定されるべきである。
そこで、掲載時間を用いて閲覧数を正規化した値を入力としたディープラーニングによって閲覧傾向モデル更新処理を行うことを考える。これにより、記事Aと記事Bは同等に閲覧されやすいと判定される閲覧傾向モデルを生成することが可能となる。これは、先の図6に示す閲覧傾向モデル更新処理にも適用することができる。
なお、掲載時間を用いて閲覧数を正規化した値を用いたとしても、閲覧数以外の要素を考慮した結果、記事Aの方が閲覧されやすいと判定する閲覧傾向モデルや記事Bの方が閲覧されやすいと判定する閲覧傾向モデルへと更新される可能性はある。
<4−4.新着配信記事確認処理>
記事管理端末10の掲載判定部10dは、配信社から記事が配信されるたびに、当該配信記事を特定掲載場所23に掲載するか否かを判定する処理を実行する。
具体的に、図8を参照して説明する。
記事管理端末10は、ステップS401で、配信社から配信された新たな配信記事の有無に応じた分岐処理を実行する。
新たな配信記事がない場合(ステップS401:Nの場合)、記事管理端末10は再度ステップS401を実行する。
新たな配信記事がある場合(ステップS401:Yの場合)、記事管理端末10はステップS402で、掲載傾向モデルを用いた判定処理(第1判定処理)を行う。この処理では、これまでのトップ掲載記事の傾向と新着記事の特徴が合致しているか否かを判定する。
判定結果は、新着記事が掲載される可能性が高いと判定した場合の「掲載判定」と、掲載される可能性が低いと判定した場合の「不掲載判定」の2択としてもよいし、0〜100点などのように多段階であってもよい。
続いて、記事管理端末10はステップS403で、閲覧傾向モデルを用いた判定処理(第2判定処理)を実行する。この処理では、トップ掲載記事の中で閲覧数の多い記事の傾向と新着記事の特徴が合致しているか否かを判定する。判定結果は、閲覧数が所定数以上となると判定した場合の「閲覧判定」と、閲覧数が所定数未満となると判定した場合の「非閲覧判定」とによる2択としてもよいし、0〜100点などのように多段階であってもよい。
最後に、記事管理端末10はステップS404で、総合判定処理を実行する。総合判定処理では、第1判定処理の判定結果と第2判定処理の判定結果を踏まえて、新着記事をトップ掲載記事とすべきか否か、即ちトップ掲載記事の候補であるか否かを判定する処理である。
総合判定処理の具体的な処理内容について、図9を参照して説明する。なお、図9に示すフローチャートは、第1判定処理及び第2判定処理の判定結果が共に2択(掲載判定/不掲載判定、閲覧判定/非閲覧判定)の場合についての一例である。
記事管理端末10は、総合判定処理におけるステップS501で、第1判定処理で掲載判定となったか否かを判定する。
第1判定処理の判定結果が不掲載判定である場合(ステップS501:Nの場合)、記事管理端末10は図9に示す一連の処理を終了する。
一方、第1判定処理の判定結果が掲載判定である場合(ステップS501:Yの場合)、記事管理端末10はステップS502で第2判定処理による分岐処理を実行する。
具体的には、第2判定処理の判定結果が閲覧判定であるか否かによる分岐処理とされ、閲覧判定である場合(ステップS502:Yの場合)、記事管理端末10は続くステップS503で現在の判定対象の配信記事を第1種掲載候補記事に分類する。
一方、非閲覧判定である場合(ステップS502:Nの場合)、記事管理端末10は続くステップS504で判定対象の配信記事を第2種掲載候補記事に分類する。
即ち、第1種掲載候補記事は、第1判定処理で掲載判定とされ、第2判定処理で閲覧判定とされた配信記事である。
また、第2種掲載候補記事は、第1判定処理で掲載判定とされ、第2判定処理で非閲覧判定とされた配信記事である。
次に、記事管理端末10はステップS505で、入替判定処理を実行する。該処理は、新たに第1種掲載候補記事または第2種掲載候補記事とされた配信記事と、既にトップ掲載記事として特定掲載場所23に掲載されている記事を入れ替えるか否かを判定する処理である。
入替判定処理の例について、図10を参照して説明する。
先ず、記事管理端末10はステップS601で、削除候補記事を選択する処理を実行する。この処理では、トップ掲載記事の中から削除候補の記事を選択する。
例えば、削除候補記事選択の第1例として、各トップ掲載記事について、掲載開始時刻と現在時刻との差分を掲載経過時間として取得し、掲載経過時間が最も長い記事を削除候補記事とする。これにより、第1種掲載候補記事または第2種掲載候補記事とされた記事が配信された場合には、確実にトップ掲載記事との入れ替えが行われて掲載される。
削除候補記事選択の第2例として、掲載経過時間が所定時間(例えば10分など)以上となった記事のうち、最も閲覧数が少ないものを削除候補記事としてもよい。これによれば、ユーザにあまり閲覧されないような記事を削除することができる。
削除候補記事選択の第3例として、掲載経過時間が所定時間(例えば10分など)以上となった記事のうち、最も閲覧数が多いものを削除候補記事としてもよい。これによれば、既に多くのユーザに閲覧され、今後の閲覧数の増加が見込めない記事を削除することができる。
削除候補記事選択の第4例として、トップ掲載記事の数が10個とされており、第1種掲載候補記事に分類された後にトップ掲載記事として掲載された第1種掲載記事と第2種掲載候補記事に分類された後にトップ掲載記事として掲載された第2種掲載記事がある場合を考える。更に、トップ掲載記事に掲載される記事の割合を、第1種掲載候補記事を7割(=7個)、第2種掲載候補記事を3割(=3個)と設定し、各割合を変えないように入替判定処理を行う。即ち、新たな配信記事が第1種掲載候補記事に分類されている場合は、トップ掲載記事のうち第1種掲載記事の中から削除候補記事を選択し、新たな配信記事が第2種掲載候補記事に分類されている場合は、トップ掲載記事のうち第2種掲載記事の中から削除候補記事を選択する。このとき、同種(第1種、第2種の何れか)の記事の中で掲載時間が最も長い記事を削除候補記事としてもよいし、第2例のように掲載経過時間が所定時間以上であって閲覧数が最も少ないものを削除候補記事としてもよいし、第3例のように掲載経過時間が所定時間以上であって閲覧数が最も多いものを削除候補記事としてもよい。
削除候補記事選択の第5例として、記事の重要度(優先度)を考える。例えば、複数の配信社から同内容の記事が配信されている場合、その記事は世間的に重要度の高い記事とみなす事ができる。更に、関連の記事の数が多いほど重要度が高い。
例えば、重要度と第1例を組み合わせ、掲載経過時間に重要度を考慮したオフセットを加える。具体的には、重要度が高いトップ掲載記事については、掲載経過時間にマイナスの値(−20分など)のオフセット値を加えることにより、重要度の高いトップ掲載記事について削除候補記事となりにくいようにする。オフセットの値は、重要度が高いほど低い(−30分や−40分など)値としてもよい。
また、重要度と第2例や第3例を組み合わせ、所定時間を重要度によって変えることが考えられる。具体的には、重要度が高い程、所定時間を長い時間(20分や30分)とすることにより、重要度が高いトップ掲載記事について削除候補記事となりにくいようにする。
更に、重要度を第4例と組み合わせることにより、重要度の高いトップ掲載記事について削除候補記事となりにくいようにすることも可能である。
削除候補記事選択の第6例として、世間的に重要度が極めて高いトップ掲載記事については、続報記事が配信記事として配信されて第1種掲載候補記事または第2種掲載候補記事として分類された場合のみ削除候補とし、それ以外の場合については削除候補記事とならないようにすることが考えられる。例えば、震災や戦争についての記事などが挙げられる。このような世間的に重要度が極めて高い記事がトップ掲載記事として既に掲載されている場合は、その記事枠については続報記事のみ入れ替えが行われるようにする。即ち、削除候補記事は、重要度が極めて高い記事を除いた残りの記事の中から選択することとなる。このときの選択方法は、前述の第1例乃至第5例の何れを用いてもよい。
このように、世間的に重要度が極めて高い記事を削除候補記事から外すことで、ユーザが当該ニュース掲載サイトをいつ訪れたとしても、重要度の極めて高いニュースを容易に閲覧することができ、ニュース掲載サイトとしての使命を果たすことができる。
ステップS601の削除候補記事選択処理を終えた記事管理端末10は、ステップS602で、入替判定を行う。この処理では、ステップS601で削除候補とされた記事と、図9のステップS503またはS504で第1種または第2種掲載候補記事に分類された配信記事とを比較し、入れ替えを行うことが相応しいか否かを判定する。
具体的に、例えば先の削除候補記事選択として、第1例や第2例や第3例を採用した場合には、比較をせずに入れ替えを行うと判定してもよい。これによって、第1種または第2種掲載候補記事に分類された配信記事は無条件で削除候補記事の代わりにトップ掲載記事として掲載される。
また、例えば先の削除候補記事選択の第5例や第6例のように重要度を考慮した場合には、第1種または第2種掲載候補記事に分類された配信記事についての重要度も考慮し、配信記事の重要度よりも低い重要度のトップ掲載記事がある場合に入れ替えを行ってもよい。但し、この場合には、入れ替えが行われるたびに重要度の高い記事がトップ掲載記事を占めていくため、次第に入れ替えが行われなくなりトップ掲載記事が不変となってしまう可能性がある。従って、重要度は時間の経過と共に降下するように構成してもよいし、トップ掲載記事よりも多少重要度が低かったとしても入れ替えを行うように構成してもよい。
なお、上記した重要度は、高、中、低などの比較的少ない段階となるように評価してもよいし、0〜100などのように多段階となるように評価してもよい。
ステップS602で入替判定を行った記事管理端末10は、図9のステップS506に移動し入替処理を実行する。この処理により、削除候補記事の代わりに配信記事がトップ掲載記事として特定掲載場所23に掲載される。
<4−5.新着配信記事確認処理の別例>
新着配信記事確認処理の別例について説明する。
別例では、新着配信記事確認処理で行う図8の各処理のうち、ステップS404の総合判定処理の処理内容が異なるものである。
具体的には、ステップS402の第1判定処理において、判定結果を0〜100点とし、ステップS403の第2判定処理において、判定結果を同様に0〜100点とする。これによって、ステップS404の総合判定処理の処理内容が異なる。
図11を参照して総合判定処理を説明する。
記事管理端末10の掲載判定部10dは、ステップS701で第1判定処理の判定結果が第1閾値以上であるか否かによって分岐する処理を行う。第1閾値は、比較的高い点数とされており、例えば70点とされる。
第1判定処理の判定結果が第1閾値以上である場合(ステップS701:Yの場合)は、記事管理端末10はステップS702で入替処理を行う。即ち、第1判定処理の判定結果が高い場合は、トップ掲載記事の傾向と配信記事の特徴の合致度合いが高いとみなす事ができることから、無条件で入替処理を行うことにより、新たな配信記事をトップ掲載記事として掲載する。
一方、第1判定処理の判定結果が第1閾値未満である場合(ステップS701:Nの場合)、記事管理端末10はステップS703で第1判定処理の判定結果が第2閾値以上であるか否かを判定する。第2閾値は第1閾値よりも低い数値とされ、例えば50点とされる。
第1判定処理の判定結果が第2閾値未満である場合(ステップS703:Nの場合)、記事管理端末10は図11に示す一連の処理を終了する。
一方、第1判定処理の判定結果が第2閾値以上である場合(ステップS703:Yの場合)、記事管理端末10はステップS704の分岐処理に進む。
ステップS704では、第2判定処理の判定結果が第3閾値以上であるか否かを判定する。第3閾値は、第1閾値及び第2閾値とは無関係に設定される値であり、第1閾値や第2閾値との大小関係は問わない。
第2判定処理の判定結果が第3閾値よりも高い配信記事は、閲覧数が高くなりそうな記事、即ちユーザの興味が高い記事とみなす事ができる。
第2判定処理の判定結果が第3閾値よりも高い場合(ステップS704:Yの場合)、記事管理端末10はステップS705で入替判定処理を実行する。
ステップS705の入替判定処理の対象となる配信記事は、第1判定処理の判定結果が第1閾値未満第2閾値以上とされ、第2判定処理の判定結果が第3閾値以上とされる記事である。即ち、掲載傾向がそこまで高くないがある程度の水準であり、且つ閲覧傾向が高い記事がステップS705の処理の対象となる記事である。
入替判定処理では、例えば前述した図10に示す処理を行う。削除候補記事の選択を行い、入替判定を行った記事管理端末10は、続くステップS702で入替処理を実行する。
これにより、掲載傾向モデルに合致しなかった記事であってもユーザの関心が高そうな記事については、トップ掲載記事として特定掲載場所23に掲載される。
<4−6.新着配信記事確認処理の別例2>
新着配信記事確認処理の別例2では、記事管理端末10が掲載傾向モデル生成部10bと閲覧傾向モデル生成部10cを備えておらず、代わりに第1判定処理の判定結果を取得する取得部と、第2判定処理の判定結果を取得する取得部を備えている例について説明する。
例えば、第1判定処理及び第2判定処理の判定結果を取得する処理を、掲載判定部10dが備えている。この場合には、請求項における第1判定結果取得部及び第2判定結果取得部としての役割を掲載判定部10dが担う。
具体的に図12を参照して説明する。
記事管理端末10は、新着配信記事確認処理において、ステップS801の新たな配信記事があるか否かを判定する。新たな配信記事が無い場合、記事管理端末10は再度ステップS801の処理を実行する。
なお、本例では、掲載傾向モデルを生成する処理や閲覧傾向モデルを生成する処理、そして、新たな記事が配信されてきたときにそれぞれのモデルを用いた判定処理(第1判定処理、第2判定処理)を実行する情報処理装置が記事管理端末10とは別に設けられている。
従って、そのような別の情報処理端末が第1判定処理及び第2判定処理を完了したことに応じて記事管理端末10がステップS801の処理を実行してもよい。その場合には、ステップS801では、新たな配信記事の有無を判定する処理ではなく、別の情報処理端末からの入力(トリガ)の有無を判定する処理としてもよい。
新たな配信記事がある場合(ステップS801:Yの場合)、記事管理端末10はステップS802で、第1判定処理の判定結果を取得する処理を行い、続くステップS803で第2判定処理の判定結果を取得する処理を行う。
次に、記事管理端末10はステップS804で総合判定処理を実行する。この処理は、図8のステップS404で説明した同名の処理と同じであるため、詳述を省く。
<5.第2の実施の形態>

第2の実施の形態では、管理システム1が管理する一つのニュース掲載サイトだけでなく、他の管理システムが管理するニュース掲載サイトに対しても各種の処理を行う例である。例えば、管理システム1が管理するニュース掲載サイトを「第1のニュース掲載サイト」とし、例えば、他者が運営する管理システムが管理するニュース掲載サイトを「他のニュース掲載サイト」とする。そして、第2の実施の形態では、他のニュース掲載サイトの掲載傾向も加味して第1のニュース掲載サイトの管理を行う。
具体的な処理について述べる。
<5−1.掲載傾向モデル更新処理>
本例における掲載傾向モデル更新処理を図13に示す。掲載傾向モデル更新処理では、対象となるニュース掲載サイトが複数となる。即ち、第1のニュース掲載サイトだけでなく他のニュース掲載サイトについても掲載傾向モデルを生成する。
従って、記事管理端末10の掲載傾向モデル生成部10bは、ステップS901で、ニュース掲載サイトを一つ選択する処理を実行する。
続いて記事管理端末10はステップS902で、特定の記事掲載場所を確認する。具体的には、ステップS901で選択したニュース掲載サイト(以降、対象サイト)における特定掲載場所23に掲載されたトップ掲載記事の一覧を取得する。
次に、記事管理端末10はステップS903で、取得したトップ掲載記事の一覧に変更があるか否かを判定する。即ち、対象サイトについて取得した前回のトップ掲載記事の一覧と今回のトップ掲載記事の一覧で差分となる記事があるか否かを判定する。変更がある場合(ステップS903:Yの場合)、記事管理端末10はステップS904で新記事抽出(差分となる記事)を抽出する処理を実行し、続くステップS905で掲載傾向モデルの更新処理を行う。掲載傾向モデルは、ニュース掲載サイトごとに生成され、ここで更新される掲載傾向モデルは、対象サイトについての掲載傾向モデルである。
掲載傾向モデルの更新処理を終えた記事管理端末10は、ステップS906で対象の全てのニュース掲載サイトについて処理を終えたか否かによって分岐する処理を実行する。
なお、ステップS903でトップ掲載記事の一覧に変更が無いと判定した場合についても記事管理端末10はステップS906の処理へと遷移する。
対象の全てのニュース掲載サイトについて各処理を終えた場合、記事管理端末10は図13に示す一連の処理を終了する。一方、対象の全てのニュース掲載サイトについて処理を終えていない場合、記事管理端末10はステップS901で新たな別のニュース掲載サイトを選択し、以降の処理を実行する。
これによって、対象となる全てのニュース掲載サイトについて、掲載傾向モデルの更新処理が実行される。
なお、記事管理端末10は図13に示す一連の処理を定期的に実行する。例えば、30分ごとや1時間ごとに実行される。勿論、各ニュース掲載サイトのトップ掲載記事の一覧が変更されたことをトリガとしてステップS904,S905の処理が実行されるように構成されていてもよい。
<5−2.新着配信記事確認処理>
第2の実施の形態における新着配信記事確認処理について、図14を参照して説明する。 なお、図8の新着配信記事確認処理で説明した内容については、適宜詳述を省略する。
先ず、記事管理端末10の掲載判定部10dは、ステップS1001で新たな配信記事の有無を確認し、無い場合はステップS1001を再度実行する。
続いて、記事管理端末10はステップS1002で、第1のニュース掲載サイトの掲載傾向モデル(メイン掲載傾向モデル)を用いた判定処理(メイン第1判定処理)を実行する。即ち、配信記事について、第1のニュース掲載サイトでは掲載されやすいか否かを判定する処理となる。
次に、記事管理端末10はステップS1003で、他のニュース掲載サイトの掲載傾向モデル(サブ掲載傾向モデル)を用いた判定処理(サブ第1判定処理)を実行する。即ち、配信記事について、他のニュース掲載サイトでは掲載されやすいか否かを判定する処理となる。
この処理においては、他のニュース掲載サイト一つを対象とした判定処理を行ってもよいし、他のニュース掲載サイトとして複数のサイトを対象とした判定処理を行ってもよい。
複数の他のニュース掲載サイトを対象とする場合、対象とした他のニュース掲載サイトの数だけ判定結果を出力してもよいし、平均的な判定結果を出力してもよい。具体的には、例えば判定結果として0〜100点(掲載されやすいほど高得点)の多段階で評価する場合を考える。他のニュース掲載サイトとしてサイトA、サイトB、サイトCを対象とする場合に、サイトAで80点、サイトBで60点、サイトCで40点であれば、平均値である60点を判定結果としてもよい。また、最大値である80点を判定結果としてもよいし、最小値である40点を判定結果としてもよい。
また、サイトA,B,Cの中で第1のニュース掲載サイトとの関連性を考慮した重みを付けて平均値を算出し、判定結果としてもよい。
例えば、第1のニュース掲載サイトの主たる掲載記事がスポーツに関するものであり、サイトAも同様に主たる掲載記事がスポーツに関するものである場合、サイトAを重要な他のニュース掲載サイトとして重みを増して評価してもよい。これにより、類似したユーザが閲覧しそうなサイトAを意識して第1のニュース掲載サイトの掲載判定を行うことが可能となる。
続いて、記事管理端末10はステップS1004で、第1のニュース掲載サイトの閲覧傾向モデルを用いた判定処理(第2判定処理)を実行する。
最後に、記事管理端末10はステップS1005で総合判定処理を実行し、再度ステップS1001の処理へ遷移する。
<5−3.総合判定処理>
図14のステップS1005の総合判定処理の具体的な処理内容について、図15を参照して説明する。なお、図9や図11を参照して既に説明した部分については、適宜詳述を省略する。
総合判定処理では、記事管理端末10はステップS1101で、先のメイン第1判定処理の判定結果が掲載判定であるか否かに応じて分岐する。
メイン第1判定処理の判定結果が不掲載判定である場合、記事管理端末10は図15に示す一連の処理を終了する。
一方、掲載判定である場合(ステップS1101:Yの場合)、記事管理端末10はステップS1102で、サブ第1判定処理の判定結果が不掲載判定であるか否かに応じて分岐する。
サブ第1判定処理で不掲載判定である場合、記事管理端末10はステップS1103で処理対象の配信記事を差分記事と認定する。このような配信記事は、第1のニュース掲載サイトで掲載されるだろうと判定され、他のニュース掲載サイトでは掲載されないだろうと判定された記事であり、即ち他のニュース掲載サイトに対する差別化要因とされる記事である。第2の実施の形態では、他のニュース掲載サイトに対して差別化を図れる差分記事を考慮した処理を行うものであることから、ステップS1103の処理が必要となる。
続いて、記事管理端末10はステップS1104で第2判定処理の判定結果が閲覧判定であるか否かに応じて分岐する。
閲覧判定である場合、記事管理端末10はステップS1105で当該配信記事を第1種掲載候補記事に分類する。
一方、非閲覧記事である場合、記事管理端末10はステップS1106で当該配信記事を第2種掲載候補記事に分類する。
次に、記事管理端末10はステップS1107で入替判定処理を実行し、該判定結果に基づいてステップS1108で入替処理を実行する。
ここで、ステップS1107の入替判定処理について、図10を参照して説明する。
入替判定処理では、記事管理端末10はステップS601で、削除候補記事を選択する処理を実行する。
本実施の形態における削除候補記事選択は、先述した他の例(第1例〜第6例)とは異なるものであり、削除候補記事選択の第7例として説明する。
第7例では、トップ掲載記事が差分記事であるか否かを考慮して削除候補記事の選択が行われる。
例えば、トップ掲載記事として掲載されている記事のうち、差分記事に該当する記事は、削除候補記事として選択され難い構成とする。具体的には、第1例や第2例や第3例のように掲載経過時間を考慮する例では、トップ掲載記事のうち差分記事と認定されているものに関しては、掲載経過時間を少なめに算出してもよい。また、第4例のように、第1種掲載記事と第2種掲載記事の配分を考慮する場合であっても、同種の記事の中で差分記事と認定されているものが選択され難いように構成する。
また、第5例や第6例のように重要度を考慮する場合であっても、差分記事と認定されているものが選択され難いように構成する。具体的には、掲載経過時間について、重要度及び差分記事か否かに応じたオフセットを付与する。
また、他の例として、差分記事ではないトップ掲載記事がある場合は、そのような記事を優先的に削除候補記事として選択することで、他のニュース掲載サイトとの差別化をより図ることも可能である。
削除候補記事選択の処理の後、記事管理端末10はステップS602で入替判定を行う。ここで、入替判定において、配信記事が差分記事であるか否かを考慮する例について述べる。
新たな配信記事が差分記事と認定されている場合には、必ず記事の入れ替えを行うように判定を行い、新たな配信記事が差分記事と認定されていない場合には、前述のように重要度を考慮した入替判定を行ってもよい。
<6.第3の実施の形態>

第3の実施の形態では、図10のステップS602で説明した入替判定を記事管理端末10が行わず、作業者に行わせるものである。具体的に、添付図を参照して説明する。
<6−1.入替判定処理>
第3の実施の形態では、入替判定処理に至るまでの各処理については、前述の第1の実施の形態及び第2の実施の形態で説明した如何なる処理であってもよい。例えば、図5に示す掲載傾向モデル更新処理や図6に示す閲覧傾向モデル更新処理を行うことにより各モデルを生成/更新し、該モデルを用いて新着配信記事確認処理を実行する。新着配信記事確認処理では、図9に示す総合判定処理を実行し、該総合判定処理の中で例えばステップS505に示す入替判定処理を行う。
第3の実施の形態における入替判定処理(ステップS505やステップS705、ステップS1107)の一例を図16に示す。
入替判定処理では、記事管理端末10はステップS1201で、削除候補記事の選択を行う。この処理は、前述の何れの手法であってもよい。
続いて、記事管理端末10はステップS1202で削除候補記事の提示処理を行う。この処理は、例えば、ウェブサーバ11と連携することにより実現してもよい。具体的には、ウェブサーバ11に提示のためのウェブページ生成を行わせることにより、作業者への通知を行う。
提示のためのウェブページ(提示ページ)には、入れ替え候補となる新たな配信記事と、削除候補として選択された記事と、他のトップ掲載記事についての情報が含まれる。また、それぞれの配信時間や掲載開始時間や掲載経過時間等の情報を含んでいてもよい。
更に、提示ページには、入れ替えるか否かの意思表示を示すためのボタンや、削除記事を選択するためのラジオボタン等の操作子が提示される。具体的には、「入れ替える」と表示された入替実行ボタン30、「入れ替えない」と表示された入替非実行ボタン31、新着の配信記事情報表示欄32、入れ替える場合にどの記事を削除するかを選択させるトップ掲載記事一覧33及びラジオボタン34が掲載される(図17参照)。
作業者は、上記の提示ページを閲覧し、内容を吟味した上で入替実行ボタン30と入替非実行ボタン31のいずれかの操作子を押下する。
記事管理端末10は、操作子に対する押下操作を受け付ける入力受付処理をステップS1203で実行する。即ち、該操作が行われるまで、記事管理端末10はステップS1203で待機する。
最後に、記事管理端末10は作業者の操作に応じた入替処理を実行する(ステップS506、ステップS702、ステップS1108)。勿論、作業者が入替非実行ボタン31を押下した場合には、入替処理は実行されない。
なお、本実施の形態では、作業者の人手によって特定掲載場所23に掲載される記事の最終的な選択が行われる例を説明した。また、第1の実施の形態や第2の実施の形態では、記事管理端末10が特定掲載場所23に掲載される記事の最終的な選択を行う例を説明した。
しかし、最終的な記事選択は必ずしも作業者と記事管理端末10の何れか一方が行わなければならないわけでは無く、例えば時間帯に応じて切り換えてもよい。
例えば、日中作業者が勤務している時間帯に関しては、作業者による最終的な記事選択操作を必要とする構成とし、夜間などのそれ以外の時間帯に関しては作業者の操作を必要とせず最終的な記事選択まで含めて記事管理端末10が実行するように構成してもよい。
この構成によれば、作業者が定期的に特定掲載場所23へ掲載する記事を選択する操作を行うことにより、機械学習による掲載傾向モデルの更新が自ずと行われるため、ニュース掲載サイトの方向性の変化に応じて掲載傾向モデルが自動的に最適化され、適切な掲載傾向モデルの構築及び記事の選択を行うことが可能となる。
更には、記事管理端末10による記事選択(或いは掲載候補の提示)のための処理を実行する時間帯と実行しない時間帯を設けてもよい。
例えば、午後6時から午前9時59分59秒までは、記事管理端末10が記事選択や掲載候補の提示のための処理を実行するが、それ以外の時間帯は記事選択や掲載候補の提示のための処理を行わずに、全ての作業を作業者が行うようにしてもよい。
このようにすることでも、掲載傾向モデルの最適化が行われる。特に、記事管理端末10が選択して提示した掲載候補となる記事以外から作業者の手作業によって記事が選択された場合には、掲載傾向モデルが最適でないこととなり、掲載傾向モデルの最適化によって掲載傾向モデルが大きく変更される可能性がある。即ち、掲載傾向モデルの方向性の大きな転換を行うことができる。
<7.変形例>

上記の各例では、ニュース掲載サイトのトップページに設けられた特定掲載場所23に掲載される記事(トップ掲載記事)について各種の処理を実行する例を説明したが、それ以外のウェブページに掲載される記事に対しても同様の構成で記事の選択及び掲載を行うことが可能である。
例えば、ニュース掲載サイトのトップページ以外の場所に、特集ページとして「オリンピック」に関するニュース記事が集められる記事掲載場所が設けられている例を挙げる。
このような場合には、例えば、図5に示す掲載傾向モデル更新処理において、特定掲載場所をオリンピックに関するニュース記事が集められる記事掲載場所とすることにより該掲載場所に応じた掲載傾向モデルが構築される。
更に、図8に示す新着配信記事確認処理においては、ステップS401の処理で新たな配信記事があるか否かを確認する代わりに、オリンピックに関する新たな配信記事があるか否かを確認する処理を実行することにより、特集ページに設けられた記事掲載場所に適した処理を行うことが可能である。
このような構成とすることで、ニュース掲載サイトの各所に設けられた記事掲載場所について、それぞれ適切な掲載記事の選択及び掲載を行うことが可能となる。
<8.まとめ>

上記の各例で説明したように、記事管理端末10は、配信記事を受信する記事受信部(管理部10a)と、選択されたニュース掲載サイト(第1のニュース掲載サイト)における特定の記事掲載場所(特定掲載場所23)に掲載された記事の特徴量を用いた機械学習(例えばディープラーニング)によって生成された特定の記事掲載場所の掲載傾向モデルによって得られる配信記事についての第1判定結果を取得する第1判定結果取得部(掲載判定部10d)と、特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習(例えばディープラーニング)によって生成された特定の記事掲載場所の閲覧傾向モデルによって得られる配信記事についての第2判定結果を取得する第2判定結果取得部(掲載判定部10d)と、第1判定結果と第2判定結果を用いて、記事提供元(配信社端末3)から配信される記事を特定の記事掲載場所に掲載するか否かを判定する掲載判定部10dと、を備えている。
ニュース掲載サイトには毎日各種の新着記事が配信され、その件数は数千件〜数万件にも及ぶ。そのような大量な新着記事から、ポータルサイトのトップページのような特定の記事掲載場所に掲載する注目記事を選別することは容易ではなく、作業者の負担が大きい。
このような状況を鑑みて、上記した情報処理装置としての記事の管理システムでは、例えば機械学習によって生成した掲載傾向モデル及び閲覧傾向モデルを利用することにより得られた判定結果を用いて、自動で新着記事の中から特定の記事掲載場所に掲載する記事(特定掲載記事)が選別される。
これにより、作業者の処理負担を大幅に軽減すると共に、配信記事の受信から特定掲載場所23に掲載される記事の選別までの時間を短縮することができ、配信記事が速やかに特定掲載場所23に掲載されるため、高い速報性を備えたニュース掲載サイトを提供することが可能となる。
特に、そのニュース掲載サイトの特定掲載場所23へ過去に掲載された記事からの学習を行うことにより、当該ニュース掲載サイトの特定掲載場所23の掲載傾向(記事の内容の傾向)に沿った記事が選択されやすくすることができ、そのニュース掲載サイトの独自性を確保するような掲載記事判定を行うことができる。
具体的には、スポーツに関する配信記事を掲載するニュース掲載サイトであっても、試合結果や競技結果を重視するもの、競技者の人間性を重視するもの、競技までの過程などを重視するもの、或いは特定の競技を重視するものなど、サイトごとに方向性の違いが考えられる。
上記構成によれば、そのようなニュース掲載サイトごとの方向性(独自性)に沿った掲載記事が選択を行うことができる。
また、第2の実施の形態で説明したように、第1判定結果取得部(掲載判定部10d)は、選択されたニュース掲載サイト(第1のニュース掲載サイト)以外の他のニュース掲載サイトについての掲載傾向モデルによって得られる配信記事についての第1判定結果(サブ第1判定結果)を取得し、掲載判定部10dは、配信記事について、選択されたニュース掲載サイトについての第1判定結果(メイン第1判定結果)が掲載判定とされ、他のニュース掲載サイトについての第1判定結果(サブ第1判定結果)が不掲載判定とされた場合に、当該判定の対象となった配信記事を他のニュース掲載サイトに対する差分記事として特定の記事掲載場所(特定掲載場所23)に掲載され易いように扱ってもよい。
他のニュース掲載サイトにおいて掲載されずに選択されたニュース掲載サイトで掲載されると判定した差分記事が、選択されたニュース掲載サイトに掲載されやすくすることで、他のニュース掲載サイトとの差別化が図られる。即ち、ニュース掲載サイトの方向性(独自性)をより強調したニュース掲載サイトを生成することが可能となる。
これにより、選択されたニュース掲載サイトを特定のユーザにとって魅力のあるニュース掲載サイトとすることができる。
そして、他のニュース掲載サイトとの差分が総合判定処理に反映されることにより、他のニュース掲載サイトとの差別化が自動的に図られ、人手に頼らずにニュース掲載サイトの方向性を汲み取った記事が特定掲載場所に掲載される記事として選択されやすくなる。
また、選択されたニュース掲載サイトの配信記事と他のニュース掲載サイトの配信記事は、必ずしも同じとは限らない。即ち、他のニュース掲載サイトにのみ配信される記事なども存在する。このような場合に、他のニュース掲載サイトに配信された記事全てを把握しなくても済むような構成とされている。
即ち、本構成によれば、他のニュース掲載サイトについての掲載傾向モデルは、当該他のニュース掲載サイトの特定の記事掲載場所に掲載された記事を用いた機械学習によって生成される。従って、他のニュース掲載サイトの特定の記事掲載場所に掲載された記事の把握は必要である。しかし、他のニュース掲載サイトについての第1判定結果は、自身が管理する選択されたニュース掲載サイトに配信された記事について行うように構成されている。即ち、管理システム1が管理する選択されたニュース掲載サイトの配信記事を用いて他のニュース掲載サイトについての第1判定結果を行うものである。
これにより、他のニュース掲載サイトについて配信された記事全てを把握する必要はなく、他のニュース掲載サイトの特定掲載場所23に掲載された記事のみを把握すればよいため、処理負担の軽減が図られる。
更に、第1の実施の形態における新着配信記事確認処理で説明したように、掲載判定部10dは、選択されたニュース掲載サイトについての第1判定結果が掲載判定とされ、選択されたニュース掲載サイトについての第2判定結果が閲覧判定とされた記事については、掲載判定としてもよい。
特定掲載場所23の掲載傾向に合致し閲覧傾向にも合致した記事は、ニュース掲載サイトにとって当然に掲載すべき記事である可能性が高い。そして、本構成の掲載判定部10dによれば、そのような記事を確実に掲載判定とすることができる。
従って、特定の記事掲載場所に掲載すべき記事を見逃してしまうことの防止が図られる。
更にまた、第1の実施の形態における新着配信記事確認処理で説明したように、掲載判定部10dは、選択されたニュース掲載サイトについての第1判定結果が掲載判定とされ、選択されたニュース掲載サイトについての第2判定結果が非閲覧判定とされた記事のうち少なくとも一部の記事については掲載判定としてもよい。
ニュース掲載サイトには、閲覧数が多いことが予想されるために特定の記事掲載場所に掲載される記事もあれば、ニュース掲載サイトの特性として閲覧数に関わらず特定の記事掲載場所に掲載すべき記事もある。本構成によれば、閲覧数が増えるとは限らない記事、即ち第2判定処理において非閲覧判定とされた記事についても、掲載判定部は掲載すると判定する場合がある。
これにより、閲覧数によらず特定の記事掲載場所に掲載すべき記事も掲載判定とされるため、そのような記事を人手で探し出す手間を省くことができる。
加えて、第3の実施の形態で説明したように、掲載判定部10dによる掲載判定(図10の入替判定処理)は、特定の時間帯のみ行ってもよい。
例えば、特定の時間帯以外は作業者によって特定掲載場所23に掲載する記事が選別されるようにし、その選別結果を用いて掲載傾向モデルと閲覧傾向モデルの調整を行うことが可能となる。
これにより、例えば、人手によって特定掲載場所23に掲載する記事として選択されて掲載された記事について追加で分析(学習)することができ、掲載傾向モデルを最適な状態で保つことが可能となる。
また、ニュース掲載サイトの傾向が変わった場合でも、継続的な分析(学習)を続けることにより、傾向の変化に追随した適切な記事選択が行われる。
そして、第1の実施の形態における閲覧傾向モデル更新処理で説明したように、第2判定結果取得部(掲載判定部10d)は、特定の記事掲載場所(特定掲載場所23)に掲載された新たな記事についての閲覧数に基づいて更新された閲覧傾向モデルを用いた第2判定結果を取得してもよい。
これにより、ニュース掲載サイトに来訪するユーザ層に変化が起きた場合のように、閲覧されやすい記事が変化した場合でも、新たに特定掲載場所23に掲載された記事についての閲覧数の傾向が追加で学習されて第2判定結果に反映される。
管理システム1(記事管理端末10)は、そのような第2判定結果を用いることにより、閲覧傾向の変化に沿った掲載判定を行うことができる。
また、第3の実施の形態で説明したように、掲載判定部10dが掲載すると判定した記事を作業者に提示する提示部10eと、作業者により選択された記事を特定の記事掲載場所(特定掲載場所23)に掲載する記事として決定する掲載記事決定部10fと、を備えていてもよい。
即ち、掲載判定部10dによって掲載すると判定された記事がそのまま特定記載記事として掲載されることはなく、作業者の目視による検査が行われた後に掲載される。
従って、掲載傾向モデルや閲覧傾向モデルが不完全であることにより意図しない記事が特定掲載場所23に掲載されてしまうことが防止される。
また、作業者の目視による検査の工程が加わったとしても、膨大な記事を全て目視検査するものではなく提示部によって提示された記事のみを目視検査する構成とされているため、大幅な作業時間の短縮を図ることができる。即ち作業時間を短縮とニュース掲載サイトの信頼性の確保の双方をバランスよく達成することができる。
更に、変形例で説明したように、特定の記事掲載場所(特定掲載場所23)が特定のジャンル(例えばオリンピック)に属する記事を集めたウェブページに設けられている場合において、掲載判定部10dは、記事提供元(配信社端末3)から配信される記事のうち特定のジャンルに属する記事に対して判定を行ってもよい。
特定のテーマに沿った特集ページであっても、機械学習を用いて生成された各モデルを利用した掲載判定が行われる。
即ち、その結果掲載すると判定された記事はテーマに沿ったものとされるため、特集ページの意図に沿った記事が選択されて掲載される。
上記した各種の構成及び処理は、それぞれ適宜組み合わせることが可能である。例えば、第2の実施の形態と第3の実施の形態を組み合わせ、新たに配信された配信記事が他のニュース掲載サイトに対する差分記事となるかを判定し(ステップS1101〜S1103)、配信記事の代わりに特定掲載場所23から削除する記事の候補を選択し(削除候補記事選択:ステップS1201)、その選択結果等を作業者に提示する提示処理を行う。更に、作業者の操作に応じた入力受付処理(ステップS1203)を行い、特定掲載場所23の更新を行ってもよい。
<9.プログラム及び記憶媒体>

実施の形態のプログラムは、記事管理端末10の演算処理装置(CPU等)に各種の処理を実行させるプログラムである。
実施の形態のプログラムは、配信記事を受信する記事受信機能を演算処理装置に実行させる。
また、選択されたニュース掲載サイトにおける特定の記事掲載場所に掲載された記事の特徴量を用いた機械学習によって生成された特定の記事掲載場所の掲載傾向モデルによって得られる配信記事についての第1判定結果を取得する第1判定結果取得機能を演算処理装置に実行させる。
更に、特定の記事掲載場所に掲載された記事についての閲覧数を特徴量として用いた機械学習によって生成された特定の記事掲載場所の閲覧傾向モデルによって得られる配信記事についての第2判定結果を取得する第2判定結果取得機能を演算処理装置に実行させる。
そして、第1判定結果と第2判定結果を用いて、記事提供元から配信される記事を特定の記事掲載場所に掲載するか否かを判定する掲載判定機能を演算処理装置に実行させる。
即ちこのプログラムは、情報処理装置の演算処理装置に対して図5乃至図16に示す各処理を実行させるプログラムである。
このようなプログラムにより、上述した記事管理端末10としての1または複数の情報処理装置を実現できる。
そしてこのようなプログラムはコンピュータ装置等の機器に内蔵されている記憶媒体としてのHDDや、CPUを有するマイクロコンピュータ内のROM等に予め記憶しておくことができる。あるいはまた、半導体メモリ、メモリカード、光ディスク、光磁気ディスク、磁気ディスクなどのリムーバブル記憶媒体に、一時的あるいは永続的に格納(記憶)しておくことができる。またこのようなリムーバブル記憶媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、このようなプログラムは、リムーバブル記憶媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、LAN、インターネットなどのネットワークを介してダウンロードすることもできる。
1 管理システム、10 記事管理端末、10a 管理部、10b 掲載傾向モデル生成部、10c 閲覧傾向モデル生成部、10d 掲載判定部、10e 提示部、10f 掲載記事決定部、11 ウェブサーバ、2 通信ネットワーク、3 配信社端末、4 ユーザ端末、23 特定掲載場所、50 記事DB、51 ユーザDB、52 コメントDB

Claims (11)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018147466A JP6539772B1 (ja) 2018-08-06 2018-08-06 情報処理装置、情報処理方法、プログラム、記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018147466A JP6539772B1 (ja) 2018-08-06 2018-08-06 情報処理装置、情報処理方法、プログラム、記憶媒体

Publications (2)

Publication Number Publication Date
JP6539772B1 true JP6539772B1 (ja) 2019-07-03
JP2020024489A JP2020024489A (ja) 2020-02-13

Family

ID=67144650

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018147466A Active JP6539772B1 (ja) 2018-08-06 2018-08-06 情報処理装置、情報処理方法、プログラム、記憶媒体

Country Status (1)

Country Link
JP (1) JP6539772B1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023162909A (ja) * 2022-04-27 2023-11-09 Lineヤフー株式会社 情報提供装置、情報提供方法、および情報提供プログラム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7311568B2 (ja) * 2021-09-14 2023-07-19 ヤフー株式会社 情報提供装置、情報提供方法、および情報提供プログラム

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023162909A (ja) * 2022-04-27 2023-11-09 Lineヤフー株式会社 情報提供装置、情報提供方法、および情報提供プログラム
JP7545436B2 (ja) 2022-04-27 2024-09-04 Lineヤフー株式会社 情報提供装置、情報提供方法、および情報提供プログラム

Also Published As

Publication number Publication date
JP2020024489A (ja) 2020-02-13

Similar Documents

Publication Publication Date Title
JP6147944B1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP6619024B2 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
CN103460236A (zh) 信息提供装置、信息提供方法、信息提供程序及记录媒体
US10565561B2 (en) Techniques for identifying and recommending skills
JP6679250B2 (ja) 決定装置、決定方法および決定プログラム
CN104025084A (zh) 历史浏览会话管理
JP5506104B2 (ja) 情報処理装置、情報処理方法、及び情報処理プログラム
JP6539772B1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP6139037B1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP6160362B2 (ja) 情報評価装置、情報評価方法および情報評価プログラム
JP6754808B2 (ja) 情報処理装置、情報処理方法
CN105190619B (zh) 终端装置以及装置的程序
JP2018045572A (ja) 判定装置、判定方法、及び判定プログラム
US20140200979A1 (en) Information providing device, information providing method, information providing program, and recording medium
KR101990502B1 (ko) 범용화된 정보 추출 방법 및 이를 적용한 디바이스
JP2011210196A (ja) サーバ装置、評価方法、及び評価プログラム
JP6349466B2 (ja) 情報処理装置、情報処理方法、プログラム及び記憶媒体
JP5171775B2 (ja) 宿泊予約管理システム
JP5112459B2 (ja) ページ生成装置及び方法
JP6089156B1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP2010157006A (ja) インターネット上の各webサイト属性判定方法
US20230079425A1 (en) System and method of optimized dynamical allocation of display resources
JP6641486B2 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JPWO2018029810A1 (ja) 情報処理装置、情報処理方法、プログラム、記憶媒体
JP6362775B2 (ja) 空き時間管理装置、空き時間管理方法、コンピュータープログラム、及び記憶媒体

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180806

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190604

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20190610

R150 Certificate of patent or registration of utility model

Ref document number: 6539772

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250