JP2018049504A - 投稿情報管理システム、投稿情報管理方法、およびプログラム - Google Patents

Abstract

【課題】信頼性が低い投稿情報を表示させないようにするための新しい手法が求められている。【解決手段】投稿情報管理システムは、投稿された投稿情報と、投稿情報に対する投票の情勢と、投稿情報の状態とを管理する。また、投稿情報の状態に基づいて投稿情報を、投票を受け付け可能な状態でユーザ端末に提供する。投稿情報に対する投票を複数のユーザ端末から受信すると、管理部で管理されている情勢を更新する。そして、更新された情勢に基づいて、投稿情報をユーザ端末に表示すべきか否かを判定する。投稿情報をユーザ端末に表示すべきでないと判定された場合、投稿情報の状態を、ユーザ端末において表示が行われる状態から、ユーザ端末において表示が行われない状態に遷移させる。【選択図】図１

Description

本発明は、口コミなどに代表されるような投稿情報を管理する技術に関する。

各種の口コミがインターネット上で投稿されている。口コミは、第三者の意見を自分自身の知識として取り入れられる便利なツールである。しかしながら、口コミの全てが正しい情報とは限らない。信頼性が低い情報もある。

信頼性が低い情報を削除すべきか否かは、表現の自由との関係で判断することが難しい。信頼性が低い情報を削除しないまま放置すると、口コミが掲載されているサイト自体の信用が失われる。一方で、信頼性が低い情報を客観的な情報無しに削除することは、表現の自由が担保されなくなり、この結果、口コミを掲載するサイトに対する不信感が増加してしまう。

特許文献１には、実際に店舗などを訪問したユーザからの投稿は、信頼性が高いものとして取り扱う技術が開示されている。特許文献１では、口コミを投稿したユーザのクライアント端末の位置データを用いて、口コミの投稿情報の信頼度を評価する。

特開２００７−３０４９７７号公報

実際に店舗を訪問したユーザであっても、事実に基づかない情報を書き込む場合というのは起こり得る。むしろ、些細な誤解などから信頼性が低い情報を書き込んでしまう場合も起こり得る。信頼性が低い情報を表示させないようにするための新しい手法が求められている。

本発明の一実施形態に係る投稿情報管理システムは、投稿された投稿情報と、前記投稿情報に対する投票の情勢と、前記投稿情報の状態とを管理する管理部と、前記状態に基づいて、前記投稿情報を、前記投稿情報に対する投票を受け付け可能な状態でユーザ端末に提供する提供部と、前記投稿情報に対する投票を複数のユーザ端末から受信し、前記管理部で管理されている前記情勢を更新する更新部と、前記更新部において更新された前記情勢に基づいて、前記投稿情報を前記ユーザ端末に表示すべきか否かを判定する判定部と、前記判定部によって前記投稿情報を前記ユーザ端末に表示すべきでないと判定された場合、前記投稿情報の状態を、前記ユーザ端末において表示が行われる状態から、前記ユーザ端末において表示が行われない状態に遷移させる状態遷移部とを有するものとすることができる。

本発明によれば、投稿情報に対する投票結果に基づいて、投稿情報をユーザ端末で表示させない処理を行う。ユーザからの投票という客観的な情報に基づいて投稿情報を表示させない処理を行うことにより、口コミを掲載するサイトの健全性を高めるとともに、ユーザの表現の自由も担保することができる。

投稿情報管理システムを含む構成の一例を示す図である。 投稿情報に対する投票を行う画面の一例を示す図である。 管理部で管理されているデータの一例を示す図である。 投稿情報の状態の遷移の一例を示す図である。 削除準備状態の投稿の表示画面の一例を示す図である。 投稿情報管理システムの処理の一例を示すフローチャートである。 口コミの表示画面の一例を示す図である。 口コミの表示画面の一例を示す図である。 口コミの表示画面の一例を示す図である。 日記の表示画面の一例を示す図である。 投票に用いるユーザインタフェースの他の例を示す図である。 投票情報管理システムを含む構成の他の例を示す図である。 投票に応じて表示態様がされる例を示す図である。 投票に応じて表示態様がされる他の例を示す図である。

以下、図面を参照しながら本発明の実施形態について詳細に説明する。なお、以下の実施形態において説明する構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。

＜実施形態１＞
＜全体の構成＞
図１は、本実施形態に係る投稿情報管理システム１００を含む全体の構成の一例を示す図である。投稿情報管理システム１００は、投稿受付部１１１、提供部１１２、更新部１１３、通知部１１４、管理部１５１、判定部１５２、および状態遷移部１５３を含む。投稿情報管理システム１００は、ユーザ端末１０と通信する。なお、図１は構成の一例を示したものに過ぎず、他の構成を含んでもよい。また、図１に記載された構成の全てが必須の要件であるとは限らない。

投稿情報管理システム１００は、単一の情報処理装置を用いて実現されてもよいし、複数の情報処理装置を用いて実現されてもよい。例えば、投稿情報管理システム１００のうち、ユーザ端末１０との間で情報のやり取りを行う投稿受付部１１１、提供部１１２、更新部１１３、および通知部１１４を、ウェブサーバ１１０として構成してもよい。データの管理などを行う管理部１５１、判定部１５２、および状態遷移部１５３を、データベース（ＤＢ）サーバ１５０として構成してもよい。この例に限られず、各部の処理を複数のサーバが分散して処理を行う形態でもよい。本実施形態においては、図１に示すように、ウェブサーバ１１０及びＤＢサーバ１５０によって投稿情報管理システム１００が構成されている例を用いて説明する。

ウェブサーバ１１０及びＤＢサーバ１５０は、情報処理装置として実現することができる。図１に示す各部は、例えばハードウェアまたはソフトウェアによって実装することができる。ソフトウェアによって実装される場合、ハードウェアを制御するプログラムコードがＣＰＵ、ＭＰＵなどのコンピュータの各種のプロセッサによって実行されてもよい。例えば、情報処理装置は、ＣＰＵ、メモリ、ＨＤＤ、及びネットワークインタフェースを有してよい。図１に示す各サーバに含まれる各部は、各サーバのＨＤＤに格納されたプログラムが一時的にメモリに読み出され、各サーバのＣＰＵがメモリに読み出されたプログラムを実行することで、各サーバのＣＰＵが図１に示す各部として機能することができる。また、プログラムコードの機能を実現するための回路等のハードウェアを設けてもよい。プログラムコードの一部をハードウェアで実現し、残りの部分を各種プロセッサが実行してもよい。

投稿情報管理システム１００は、ユーザが使用するユーザ端末１０との間で通信が可能に構成されており、ユーザ端末１０に投稿情報を提供したり、ユーザ端末１０から投稿情報の投稿を受け付けたり、投稿情報に対する投票をユーザ端末１０から受信したりする。本実施形態においては、複数のユーザのユーザ端末を総称してユーザ端末１０と呼ぶこととする。

ユーザ端末１０は、パーソナルコンピュータ、タブレット、モバイル端末など任意の種類の端末であってよい。投稿情報管理システム１００は、ユーザをログイン管理しており、ログインしたユーザを一意に特定することが可能である。

＜ウェブサーバの構成＞
ウェブサーバ１１０の有する各構成について説明する。

投稿受付部１１１は、ユーザ端末１０から投稿された投稿情報を受け付ける。投稿情報とは、投稿対象に対する投稿内容を含む情報である。投稿対象とは、様々なものが挙げられる。例えば、商品、飲食施設、宿泊施設、レジャー施設、生活サービス、医療機関、相談機関などが挙げられる。もちろん、これらに限定されるものではなく、あらゆる対象が投稿対象となり得る。投稿内容は、例えば感想、評価などのいわゆる口コミのテキスト文章である。このように、投稿情報には、投稿対象に対する口コミが記述されたテキスト文章が含まれる。また、投稿情報には、口コミが記述されたテキスト文章のほか、投稿対象に関連する画像データ、動画データ、または音声データが含まれていてもよい。また、投稿情報には、投稿対象に対する評価点が含まれていてもよい。投稿情報を受け付ける形態の例としては次のようなものが挙げられる。ウェブサーバ１１０は、各投稿対象に関する説明が記載されているウェブページをユーザ端末１０に提供する。ユーザ端末１０は、このウェブページに含まれる投稿欄に対して投稿情報を投稿する。投稿受付部１１１は、このようにして投稿された投稿情報を受け付けることができる。

投稿情報は、口コミのような形態でもよいし、別の形態でもよい。別の形態としては、特定の投稿対象の使用方法や活用方法などを、繰り返し投稿するような日記形式のものでもよい。その他、何かしらの投稿が行われる形態であれば、いずれの形態でもよい。投稿受付部１１１は、このように投稿された投稿情報を受け付ける。

提供部１１２は、管理部１５１で管理されている投稿情報を、その投稿情報に対する投票をユーザから受け付け可能な状態でユーザ端末１０に提供する。例えば、提供部１１２は、ユーザ端末１０からの投稿情報の表示要求に応じてその要求元のユーザ端末１０に投稿情報を提供（送信）する。提供部１１２は、投稿情報を、その投稿情報に対する投票用のユーザインタフェースがユーザ端末１０で表示可能な状態で、ユーザ端末１０に送信することができる。

図２（ａ）は、提供部１１２が、投稿情報を、その投稿情報に対する投票をユーザから受け付け可能な状態でユーザ端末１０に提供し、提供された投稿情報を含む画面２００がユーザ端末１０のディスプレイにおいて表示されている例を示している。画面２００には、投稿情報として、ユーザ名２０１、タイトル２０２、評価点２０３、口コミ本文２０４を含む情報が表示されている。また、投稿情報に対する投票を受け付けるための投票を促すメッセージ２１０、「正」を投票する第一の投票ボタン２１１、および「誤」を投票する第二の投票ボタン２１２を含むユーザインタフェースが表示されている。また、画面２００には、この投稿情報に対する投票の情勢を示す投票数が共に表示されている。この例では、投票数が、第一の投票ボタン２１１および第二の投票ボタン２１２に含まれる例を示している。画面２００では、この投稿情報に対する「正」の投票数が１０あり、「誤」の投票数が２０あることが示されている。なお、画面２００は一例に過ぎずこれに限られるものではない。例えば、ユーザ名のほかに、年代、性別、所在地、職業や、ユーザの画像が表示されていてもよい。

なお、提供部１１２は、既にユーザＸが投票済みの投稿情報Ｘ１に関しては、ユーザＸに対しては、その投稿情報Ｘ１に対する投票をユーザＸから受け付け不可能な状態で提供する。図２（ｂ）は、既に投票済みのユーザに対して投稿情報を提供する画面２５０の例を示している。画面２５０は、ユーザＸが、「誤」に既に投票済みの例を示している。画面２５０においては、投票済みのボタンである「誤」を投票する第二の投票ボタン２５２が、ボタン押下済みの状態が継続された状態となっており、投票が行えない状態となっている。つまり、図２（ｂ）の画面２５０は、その投稿情報に対する投票をユーザから受け付け不可能な状態でユーザ端末１０に提供される画面である。この画面２５０において「正」を投票する第一の投票ボタン２５１を押下しても、既にユーザＸは「誤」に投票済みであるので、投票が受け付けられない。投票をユーザから受け付け不可能な状態で表示される他の例としては、例えば第一の投票ボタン２５１及び第二の投票ボタン２５２がグレー表示となっていてもよい。あるいは、「正」を投票する第一の投票ボタン２５１、および「誤」を投票する第二の投票ボタン２５２自体が非表示状態となっていてもよい。

このように、本実施形態においては、一つの投稿情報に対してユーザが１回だけ投票を行うことが可能である。なお、本実施形態では、一つの投稿情報に対してユーザが１回だけ投票を行う形態を例に挙げて説明するが、これに限られるものではない。誤って投票した場合のやり直しを可能にするように、投票済みの内容を変更（例えば、「正」から「誤」に変更）できてもよい。

図１に戻りウェブサーバ１１０の構成についての説明を続ける。

更新部１１３は、投稿情報に対する投票をユーザ端末１０から受信し、管理部１５１で管理されている投稿情報に関する情勢を更新する。投稿情報に関する情勢とは、例えば口コミに対するユーザの投票結果（途中経過の状態も含む）の情報のことである。本実施形態では、口コミに対する投票として、ユーザから「正」か「誤」の２つの投票ボタンを用いた投票が行われるものとする。つまり、第一のカテゴリ「正」に投票するか、第二のカテゴリ「誤」に投票するかをユーザが選択できるように、２つの投票ボタンを用いた投票が行われるものとする。投稿情報に関する情勢とは、この正誤の投票数であってよい。あるいは、正誤の投票のそれぞれに所定の重みを乗じて加算した重み付け加算の結果の値でもよい。更新部１１３が、管理部１５１に管理されている投稿情報に関する情勢を更新することで、後述する判定部１５２は、この更新された投稿情報の情勢に基づいて、投稿情報を表示すべきか否かの判定を行うことができる。詳細は後述する。なお、ここでは第一のカテゴリおよび第二のカテゴリとして正誤を用いる例を説明したが、投稿情報に対する肯定的なカテゴリと否定的なカテゴリの名称を用いてよい。例えば、「正」の代わりに「納得」「なるほど」「参考になった」といったカテゴリの名称を用いてもよい。また、肯定的なカテゴリ、否定的なカテゴリに限られるものではなく、任意のカテゴリを使用することができる。

通知部１１４は、投稿情報の状態が、ユーザ端末１０において表示が行われない状態に遷移する可能性があることを、その投稿情報を投稿したユーザに通知する。投稿情報の削除を、その投稿情報を投稿したユーザに予告することで、その投稿情報を投稿したユーザに、自身の投稿内容を再検証させる契機を与えることができる。再検証した結果、自身の投稿内容に誤りがあることをユーザ自身が発見した場合には、そのユーザは、再度の投稿を行う場合があり得る。詳細については後述する。

＜ＤＢサーバの構成＞
次に、ＤＢサーバ１５０の構成について説明する。

管理部１５１は、投稿された投稿情報と、投稿情報に対する投票の情勢と、投稿情報の状態とを管理する。投票の情勢とは、先に説明したように、投稿情報に対する正誤の投票数でもよいし、正誤の投票のそれぞれに所定の重み付けを行って加算した重み付け加算の結果の値でもよい。

図３は、管理部１５１が管理する各種の管理ＤＢの一例を示す図である。図３に示す管理ＤＢは一例に過ぎず、この例に限定されるものではない。

ユーザ管理ＤＢ３００は、本システムで登録されている各ユーザの情報を管理するＤＢである。ユーザ管理ＤＢ３００は、ユーザＩＤが「Ｕ１００１」で特定されるユーザは、ニックネームが「ユーザＡ」であり、ポイントが５００ポイント得られていることを示している。ポイントは、投稿情報を投稿したことに応じて付与されてもよいし、投稿情報に対する投票結果に応じて付与されてもよいし、いずれの場合に付与されてもよい。ユーザ管理ＤＢ３００には、その他、ユーザの性別、生年月日、職業、住所などのユーザに関する情報が管理されてもよい。

投稿情報管理ＤＢ３１０は、投稿受付部１１１において投稿情報の受付を行うたびに、レコードが増える。投稿情報管理ＤＢ３１０においては、投稿対象ＩＤが「Ｇ２１」で特定される投稿対象（例えばレストランＲ）に対して、ユーザＩＤ「Ｕ１００１」のユーザによって投稿情報ＩＤ「Ｐ１０１」の投稿が行われた場合の例を示している。投稿情報ＩＤ「Ｐ１０１」の投稿の投稿種別は「公開中」であることを示している。投稿種別には、例えば「公開中」「下書き」「過去投稿」「削除」などが含まれる。投稿種別は、現在の投稿の状態の種別を示している。図３の投稿情報管理ＤＢ３１０では、投稿情報ＩＤ「Ｐ１０１」の投稿内容として「とても悪かった」との投稿がなされており、投稿対象ＩＤが「Ｇ２１」で特定されるレストランに対する評価点として１．０点が投稿ユーザ（図３の例ではユーザＩＤがＵ１００１のユーザ）によって付されたことを示している。また、投稿情報管理ＤＢ３１０には、投稿情報ＩＤ「Ｐ１０１」の投稿に対する投票数が関連付けて管理されている。この例では、「正」の投票数が３であり「誤」の投票数が５０であることを示している。図３の例においては、投稿表示終了日時に所定の日時の設定がなされている。本実施形態においては、投稿種別が「公開中」であり、投稿表示終了日時に所定の日時の設定がなされている場合、投稿情報の状態は、削除準備状態になっていることを示す。投稿情報の状態に関しては、後述する。

投票管理ＤＢ３２０は、投稿情報に対する投票が行われるごとに逐次レコードを増やしていく。投稿情報管理ＤＢ３１０の「正」の数や「誤」の数は、投票管理ＤＢ３２０の集計値である。

投稿対象管理ＤＢ３３０は、投稿対象に対する総合評価点を格納する。管理部１５１は、同じ投稿対象に対する複数のユーザからの評価点に従って算出された総合評価点（第一の評価点）を、投稿対象に関連付けて管理する。図３の例においては、投稿対象ＩＤが「Ｇ２１」で特定される投稿対象に対して、総合評価点が３．３であることを示している。総合評価点は、投稿対象に対する各ユーザの投稿情報に含まれる評価点を元に算出される値である。算出方法としては、ユーザの信頼性に応じて重み付けを行った評価点の平均を算出するなどの方法を採用してもよい。

判定部１５２は、更新部１１３において更新された、管理部１５１で管理されている投票の情勢に基づいて、投稿情報をユーザ端末１０に表示すべきか否かを判定する。例えば、第二のカテゴリ（誤）の値に対する第一のカテゴリ（正）の値が所定の閾値以内であれば、その投稿情報をユーザ端末１０に表示すべきでないと判定する。すなわち、正／誤の値が所定の閾値以内であればその投稿情報をユーザ端末１０に表示すべきでないと判定する。判定による手法には、このような正誤比を用いるほかに、各種の手法を用いることができる。詳細は後述する。

状態遷移部１５３は、投稿情報をユーザ端末１０に表示すべきでないと判定部１５２によって判定された場合、その投稿情報の状態を、ユーザ端末１０において表示が行われる状態から、ユーザ端末１０において表示が行われない状態に遷移させる。

図４は、本実施形態に係る投稿情報の状態の遷移を示す図である。投稿情報の状態は、先に説明した、図３の投稿情報管理ＤＢ３１０の「正」の数や「誤」の数、あるいは、これらの数に所定の重み付けを行った値などの集計結果に基づいて決定される。

投稿受付部１１１において投稿を受け付けた時点において、すなわち、新規の投稿がユーザによって行われた時点においては、その投稿情報の状態は、通常状態４１０である。この通常状態４１０は、第一のカテゴリ（正）の投票数から、第二のカテゴリ（誤）の投票数を差し引いた第一の数が、第二の数以上でありかつ第三の数以下の投稿を示す第一態様とすることができる。図４の例では、説明を簡略化するために単純な値を用いて説明する。例えば新規の投稿がユーザによって行われた時点においては、何も投票が行われていないので第一の数は０である。ここで、第二の数を−２０、第三の数を２０とすると、第一の数が、−２０以上かつ２０以下であるか否かに応じて投稿情報の状態が遷移する。状態遷移部１５３は、第一の値が例えば３０であった場合、すなわち、正の投票数が誤の投票数よりも多い場合、その投稿情報の状態を、高評価状態４５０（第一の数が第三の数より大きい投稿を示す第二態様）に遷移させる。逆に、第一の数が例えば−３０であった場合、すなわち、誤の投票数が正の投票数よりも多い場合、状態遷移部１５３は、その投稿情報の状態を、低評価状態４２０（第一の数が第二の数よりも小さい投稿を示す第三態様）に遷移させる。

状態遷移部１５３は、高評価状態４５０と通常状態４１０との間の状態遷移、および通常状態４１０と低評価状態４２０との間の状態遷移に関しては、いずれの方向においても状態遷移をさせることが可能である。

低評価状態４２０から、さらに第二のカテゴリの投票数が多くなると、状態遷移部１５３は、その投稿情報の状態を、低評価状態４２０から削除準備状態４３０に遷移させる。削除準備状態４３０は、投稿情報が、ユーザ端末１０においてその投稿情報の表示が行われる状態から、ユーザ端末１０においてその投稿情報の表示が行われない状態に遷移した状態である。換言すれば、削除準備状態４３０は、削除が行われることが確定した状態である。状態遷移部１５３は、削除準備状態４３０から低評価状態４２０に状態を遷移させることはできない。

提供部１１２は、管理部１５１の投稿情報管理ＤＢ３１０の集計結果に基づいて決定される投稿情報の状態に基づいて投稿情報の提供を行う。提供部１１２は、投稿情報の状態が、削除準備状態４３０に遷移された場合、その投稿情報の本文を非表示にした状態で投稿情報をユーザ端末１０に提供する。

図５は、削除準備状態４３０の投稿情報がユーザ端末１０において表示される画面５００の例を示す図である。画面５００には、投稿情報として、ユーザ名５０１、タイトル５０２、及び評価点５０３が表示されている。画面５００では、投稿情報の本文の代わりに、削除がされる予定であることを示すメッセージ５１０が表示されている。また、ユーザ名５０１は、ニックネームではなく、ＸＸＸＸとマスク表示に変更されている。削除される予定であることを投稿ユーザや他のユーザに知らせることができればよいので、削除準備状態４３０の投稿情報を表示する画面５００では、ユーザ名は匿名扱いに変更されている。ユーザ名とともにユーザの画像が表示される形態では、この画像を非表示にしてもよい。なお、ユーザ名のほか、年代、性別、所在地を表示する形態の場合には、これらは個人を特定する情報ではないので、そのまま表示してもよい。また、「正」の投票ボタン及び「誤」の投票ボタンは、非表示状態となっている。すなわち、「正」の投票ボタン及び「誤」の投票ボタンは、投票が不可な状態である。つまり、仮にまだその投稿情報に対する投票を行っていないユーザであっても、削除準備状態４３０の投稿情報に対しては投稿が行われない。なお、画面５００には、これまでの投票数５２０が表示されている。

このように、本実施形態においては、投票の情勢が、その投稿情報の信頼性が低いことを示す場合に直ちに投稿情報を削除するのではなく、一旦、本文を非表示の状態で所定の期間（例えば１日）表示を続ける。投稿情報が何の前触れなしに削除されてしまうと、ユーザの不信感を引き起こす可能性がある。本実施形態では、ある程度の削除準備期間を設けた削除の予告を行うことで、投稿情報を提供するサイトの信頼性を向上させることができる。

削除準備状態４３０に投稿情報の状態が遷移すると、所定の時間が経過した後に、状態遷移部１５３は、削除準備状態４３０から削除状態４４０に遷移させる。管理部１５１は、投稿情報管理ＤＢ３１０の集計結果に基づいて決定される投稿情報の状態が削除状態に遷移された場合、当該投稿情報の投稿種別を「削除」に変更する。投稿情報の投稿種別が「削除」に変更された場合、当該投稿情報を投稿情報管理ＤＢ３１０から削除してもよいし、投稿情報がシステム上で削除扱いになるように処理してもよい。つまり、管理部１５１は、投稿情報を物理的に削除しなくてもよい。

管理部１５１が投稿情報の投稿種別を「削除」に変更した場合、その投稿対象の評価点が変わる可能性がある。そこで、管理部１５１は、投稿種別が「削除」に変更された投稿情報を除いて再度投稿対象に対する総合評価点を算出し、算出した総合評価点で、投稿対象管理ＤＢ３３０に格納される総合評価点を更新する。なお、管理部１５１は、投稿情報の投稿種別を「削除」に変更した場合に総合評価点を再度算出してもよいし、投稿情報の状態が削除準備状態に遷移された時点で、総合評価点の再算出を行ってもよい。

＜フローチャート＞
図６は、本実施形態に係る投稿情報管理システムの制御方法の一例を示すフローチャートである。図６の処理は、ある投稿情報に着目し、投稿情報が投稿情報管理システムに受け付けられてから削除されるまでの一連の投稿情報管理方法の処理を示すフローチャートである。

ステップＳ６１０において投稿受付部１１１は、ユーザ端末１０から投稿情報を受け付ける。受け付けられた投稿情報は、管理部１５１において管理される。

ステップＳ６２０において提供部１１２は、ユーザ端末１０からの要求に応じて、ステップＳ６１０において受け付けた投稿情報を、ユーザ端末１０に提供する。

ステップＳ６３０において更新部１１３は、ステップＳ６２０で提供された投稿情報に対する投票を受信する。そして、ステップＳ６４０において更新部１１３は、受信した投票内容に応じて管理部１５１で管理されている投票の情勢を更新する。例えば、投票されたカテゴリの投票数を増加させる。

ステップＳ６５０において判定部１５２は、ステップＳ６４０で更新された情勢に基づいて、ステップＳ６１０で受け付けた投稿情報をユーザ端末１０に表示すべきか否かを判定する。ステップＳ６５０の判定処理の詳細を説明する。

判定処理としては、二つのカテゴリである「正」「誤」の投票数の差（あるいは正誤の比率）を用いてもよい。ある程度の投票数が集まるまでは、判定処理に用いない処理を行ってもよい。

本実施形態においては、第一の値（判定値）を、例えば式（１）のように求めることができる。ここで、positiveは、「正」の投票数であり、negativeは、「誤」の投票数である。

第一の値＝(positive * α) / (negative * β) 式（１）
ここで、αとβはパラメータである。任意のパラメータを用いて、第一の値を算出することができる。この第一の値が所定の閾値を下回る場合に、投稿情報を表示すべきでないと判定する（ステップＳ６５０でＮＯと判定する）ことができる。また、二項分布に基づく母比率の信頼区間を用いてもよい。例えば、信頼区間９５％での上限値を第一の値とし、この第一の値が所定の閾値を下回る場合に、投稿情報を表示すべきでないと判定してもよい。また、ユーザの情報に応じて重みを付けた値を用いてもよい。例えば、都道府県別では、ユーザの登録数が異なる。したがって、例えば１票の重みを、ユーザの多いエリア（Ａ県）では相対的に低くし、ユーザの少ないエリア（例えばＺ県）では相対的に高くすることで、調整を行うことができる。また、より細分化して例えば「市」や「町」などの単位によって重み付けを変えてもよい。また、所在地に応じた重み付けのほか、性別や年齢に応じて重み付けを変えてもよいし、これらの組み合わせに応じて適宜重み付けを変えてもよい。

また、投票数というものは、投稿情報が投稿されてからの経過時間に比例して少なくなる傾向がある。したがって、投稿情報の投稿された日時からの経過時間に応じて、所定の閾値を変更してもよい。例えば、投稿情報の投稿された日時から経過時間が長い場合には、経過時間が短い場合と比べて、所定の閾値が高くなるように変更する。つまり、正誤比を緩めることで、所定の閾値を下回る第一の値が増えることになり、判定結果が得られやすくなる。また、時間が経過するに連れて、例えば店舗などの運営が開店当初は芳しくなかった状態から、ノウハウが蓄積されて大幅に改善されるといったように、投稿情報が投稿された時点とは、投稿対象の状態が異なっている場合も想定される。このように、過去の蓄積された投票数が必ずしも適切ではない場合もあるので、投稿情報の投稿された日時からの経過時間に応じて、所定の閾値を変えることで柔軟な判定結果を得ることができる。

ステップＳ６５０で投稿情報を表示すべきであると判定した場合、ステップＳ６６０に処理が進む。そうでない場合、ステップＳ６８０に処理が進む。

ステップＳ６６０において判定部は、ステップＳ６１０で受け付けた投稿情報が削除される可能性があるかを判定する。例えば、ステップＳ６４０で用いた所定の閾値の代わりに、その所定の閾値よりも高い第二の閾値を用いてステップＳ６４０と同様の判定処理を行えばよい。ステップＳ６６０において削除される可能性があると判定された場合、ステップＳ６７０に進む。ステップＳ６７０において通知部１１４は、ユーザ端末１０において表示が行われない状態に遷移する可能性があることを、ステップＳ６１０で受け付けた投稿情報を投稿したユーザに通知する。通知の方法は、予め登録されているメールアドレスにメールを送信する方法でもよいし、投稿情報管理システム１００にユーザがログインした際にメッセージをユーザ端末１０に表示する方法でもよい。削除される可能性があることを通知されたユーザは、自身の投稿情報を確認する可能性がある。自身の投稿内容を確認して誤りなどに気が付いた場合には、そのユーザは、投稿内容を修正した再投稿を行う場合がある。このように、ユーザに通知をすることで再投稿が行われる契機となる可能性がある。ステップＳ６７０の処理の後、及びステップＳ６６０において削除される可能性がないと判定された場合、ステップＳ６２０に戻り、処理を繰り返す。

ステップＳ６８０において状態遷移部１５３は、ステップＳ６１０で受け付けた投稿情報の状態を、削除準備状態に遷移させる。ステップＳ６８０の状態においても、ステップＳ６２０と同等の処理は行われる。すなわち、削除準備状態においても、提供部１１２は、ユーザ端末１０からの要求に応じて、ステップＳ６１０において受け付けた投稿情報を、ユーザ端末１０に提供する。ステップＳ６９０において管理部１５１は、所定期間が経過後に投稿情報を削除する。

次に、ステップＳ６７０において通知部１１４からの通知を受けたユーザが、再投稿を行った場合の例を説明する。ここで、再投稿とは、同一の投稿対象に対して同一ユーザが再度の投稿を行うことを意味するものである。

図７は、投稿対象について口コミ投票を行ったユーザＹが再投稿を行った場合にユーザ端末１０に表示される画面の例を示す図である。なお、再投稿は通知部１１４からの通知を必要とするものではなく、任意のタイミングでユーザＹが行うことが可能である。本実施形態においては、同一の投稿対象については、２回まで再投稿を行うことを可能とする。図７の投稿７１０および投稿７２０は、過去にユーザＹが行った投稿（第一の投稿情報）である。過去の投稿分についても、投稿情報および正誤の投票数は引き続き表示がされる。再投稿７３０は、ユーザＹが新規で再投稿をした内容（第二の投稿情報）である。過去の投稿分の正誤の投票数は、再投稿には引き継がれない。したがって、判定部１５２が判定する場合には、再投稿７３０については、正誤の値が投稿７１０及び投稿７２０からリセットされた状態で判定が行われることになる。かかる処理によれば、不正な意図で再投稿がされることを防止できるからである。例えば、仮にユーザＹが不正な意図を持っていると仮定する。そして、過去の投稿７２０では「正」の投票数を多数得ている状態であるとする。このとき、ユーザＹが、これまでの投稿内容とは全く異なる内容（「誤」の投票数が圧倒的に多くなるような内容）で再投稿をした場合、従前の投票数を引き継いでしまうと、このような真逆の内容が「正」である事態が生じてしまうからである。

なお、再投稿７３０がある場合には、従前の投稿７２０に投稿をしたことがないユーザであっても、従前の投稿７２０に対する投票はできなくなる。つまり、最新の投稿に対する投票のみを許容する形態とすることができる。

図８は、図７の再投稿７３０を閲覧したユーザが、「誤」に投票をした場合の画面例を示す図である。図７で表示されていた投票を促すメッセージ７３１は、図８では表示されない。また、「誤」の投票数が一つ増えており、「誤」の投票ボタン８３２がボタン押下継続の状態となっている。

図９は、図８の状態から削除準備状態に遷移した場合に表示される画面例を示している。投票の結果、口コミが非表示となっていること、及び、評価点と口コミ内容とが削除される予定であるメッセージが表示されている。投票受付ボタンは表示されない。過去の投票数は表示されている。ユーザ名にはマスク処理が施される。ユーザ画像は、表示されない。

図１０は、日記の形式における追記の例を示す図である。日記の場合には、投稿対象に対し使用方法や活用方法などを投稿するように、継続的な投稿を受け付ける形態である。日記の形式においてもこれまで説明したものと同様に、投票機能を設けることが可能である。なお、日記の形式においては、再投稿ということは行うことができず、既存の内容に追記をすることが可能である。日記の場合も口コミの場合と同様に、既に投票が行われた日記記事に関しては、投票を促すメッセージは表示されない。また、投票が不可能な状態となる。削除準備状態に遷移した場合も図９で示した口コミの場合と同様に、日記が非表示となっていること、及び、評価点と日記内容とが削除される予定であるメッセージが表示される。投票受付ボタンは表示されない。過去の投票数は表示される。ユーザ名にはマスク処理が施される。ユーザ画像は、表示されない。なお、このように、日記と口コミとで表示態様を共通化してもよいし、部分的に変更してもよい。

図１１は提供部１１２が提供する、投票に用いられる各種のユーザインタフェースの例を示す図である。これまでの例においては、第一のカテゴリ（正）と第二のカテゴリ（誤）との二つのカテゴリに対する投票が行われる例を説明した。図１１（ａ）では、第一のカテゴリと第二のカテゴリとの間の中間的なカテゴリとして、第三のカテゴリと第四のカテゴリとが含まれる例を示す図である。第三のカテゴリは、第四のカテゴリよりも第一のカテゴリ寄りのカテゴリである。このように、中間的なカテゴリが選択された場合には、値を適宜変更して集計が行われればよい。例えば、ボタン１１０１が選択された場合に「正」を１．０加算する場合、ボタン１１０２が選択された場合に「正」を０．７５加算し「誤」を０．２５加算する。つまり、１票を「正」と「誤」に分配する。同様に、ボタン１１０３が選択された場合に「正」を０．２５加算し、「誤」を０．７５加算する。ボタン１１０４が選択された場合に「誤」を１．０加算する。必要に応じて先に説明した重み付けを行ってもよい。

図１１（ｂ）は、図１１（ａ）よりもさらに段階的に値を調整することが可能なボリュームボタン１１５１、１１５２を用いる場合の例を示している。ボリュームボタン１１５２のスライドバーが最も「正」に移動された位置で投票ボタン１１５４が押下されると、「正」に１．０票が加算される。ボリュームボタン１１５２のスライドバーが最も「誤」に移動された位置で投票ボタン１１５４が押下されると、「誤」に１．０票が加算される。ボリュームボタン１１５２の位置に応じて、例えば、「正」に０．９票（かつ「誤」に０．１票）、「正」に０．８票（かつ「誤」に０．２票）などのように、加算される票数が変わる。ここでは変化する幅は０．１段階ずつである場合を例に挙げたが、これに限られるものではない。なお、ボリュームボタン１１５２が中央にある場合での投票は、「正」に０．５票かつ「誤」に０．５票として投票を受け付けてもよいし、あるいはボリュームボタン１１５２が中央にある場合には、投票を受け付けなくしてもよい。このように、選択された位置に応じて適宜値を変更し、投票ボタン１１５３、１１５４を押下することで調整された値の投票を受信することができる。

図１１（ｃ）は、投稿されたテキスト文章の中で、ドラッグされた（選択された）文字数に応じて値を変更する例を示している。ユーザは、投稿内容の文章のうち、同意する箇所をドラッグしてボタン１１６２を押下する。すると、ドラッグされた文字数に応じた値が加算される。なお、投稿内容の文章を全てドラッグしてボタン１１６２を押下すると、１．０票が加算される。投稿内容の一部をドラックしてボタン１１６２を押下すると、例えば０．３票が加算される。なお、ユーザは、投稿内容の文章のうち、同意しない箇所をドラッグしてボタン１１６３が押下されるとドラッグした文字数に応じて「誤」の値が調整される。このように、全体の文字数に占める割合に応じて、調整される「正」の値や「誤」の値が変更されるように構成してもよい。図１１で示した形態は一例に過ぎず、これに限られるものではない。

以上説明したように、本実施形態によれば、投稿情報に対する投票結果に基づいて、投稿情報をユーザ端末で表示させない処理を行う。ユーザからの投票という客観的な情報に基づいて投稿情報を表示させない処理を行うことにより、口コミを掲載するサイトの健全性を高めるとともに、ユーザの表現の自由も担保することができる。

＜変形例１＞
これまでの説明では、カテゴリとして主に「正」と「誤」のように相対するカテゴリを用意し、いずれかの方向性をユーザが投票する例を説明した。しかしながら、この例に限られるものではない。例えば、ユーザが、「正」にも「誤」にも判断がつかない場合がある。このようなユーザの意思を反映させるために、例えば「どちらでもない」というカテゴリを設け、「どちらでもない」といった投票ボタンを表示させる形態を採用してもよい。「どちらでもない」というカテゴリに投票された票数の扱いは、投稿情報を削除する際には、無効票として母数に含めなくてもよいし、母数に含めてもよい。また、所定の重みをつけて母数に含めてもよい。「どちらでもない」というカテゴリを設けた場合には、例えば図１１（ｂ）で示したボリュームボタン１１５１、１１５２が中間を指す場合に、「どちらでもない」に１票が加算されるように構成してもよい。

＜変形例２＞
図３のユーザ管理ＤＢ３００で説明したように、本実施形態ではユーザに対してポイントを管理することができる。このポイントは、例えば投稿を行ったユーザに対して付与されてよい。本実施形態においては、投稿情報に対する投票の情勢に応じて、ユーザにポイントを付与することができる。例えば、投稿情報の状態が高評価状態４５０に遷移された場合には、その投稿情報を投稿したユーザにポイントが付与される。あるいは、「正」の投票数が第一の閾値を超えている投稿情報に対して、「正」の投票数に応じたポイントを付与してもよい。また、「正」の投票数から「誤」の投票数を差し引きした数に応じたポイントを付与してもよい。投票の情勢に応じて、投稿情報を投稿したユーザにポイントが付与されるので、信頼性の高い投稿情報がユーザから投稿されることが期待できる。

＜実施形態２＞
実施形態２では、投稿情報に対する投票の情勢に応じて、投稿情報に関する表示の態様を変更する形態を説明する。

図１２は、本実施形態における投票情報管理システムを含む構成の一例を示すブロック図である。図１２は、図１に示す構成に対して変更部１２０１が追加されている。その他の構成については図１に示す例と同様とすることができるので、その他の構成については説明を省略する。なお、実施形態１でも説明したように、図１２に示す構成の全てが必須の構成であるとは限らない。

変更部１２０１は、更新部１１３において更新された、管理部１５１で管理されている投票の情勢に基づいて、投稿情報がユーザ端末で表示される表示態様を変更する。例えば図４で説明したような投稿情報の各種の状態に基づいて表示態様を変更することができる。

図１３および図１４は、高評価状態、通常状態、低評価状態、および削除準備状態のそれぞれで表示態様を異ならせる例を示している。すなわち、通常状態を第一態様、高評価状態を第二態様、低評価状態を第三態様、削除準備状態を第四態様として、表示態様を異ならせる例を示している。なお、ここでは４つの異なる表示態様を例に挙げて説明しているが、投稿情報の状態をより細分化して管理する場合には、その細分化のレベルに応じた表示態様を採用することが可能である。また、例えば高評価状態と低評価状態と削除準備状態の３つの表示態様であってもよい。表示態様の細分化のレベルは、適宜自由に設計することができる。図１３（ａ）は、投票に用いられるインタフェース（投票ボタン）を変更する例を示している。ここではハッチングの種類を変える例を示しているが、投票ボタンの色を変えてもよいし、大きさを変更してもよい。図１３（ｂ）は、投稿情報の枠を変更する例を示している。ここでは、線の種類や太さを変える例を示しているが、線の色を変えてもよい。図１４（ａ）は、投稿情報の背景を変更する形態を示している。色を変更してもよいし、グラデーションなどで表示態様を変更してもよいし、点灯制御を行ってもよい。図１４（ｂ）に示すように、文章の一部が選択されるような形態においては、「正」と多く選択された箇所や「誤」と多く選択された箇所の文字の大きさ、色、フォントなどを変更してもよい。図１３および図１４に示す形態は一例に過ぎず、これに限られるものではない。

本実施形態によれば、投稿情報に対する投票の情勢（例えば投票数、投票比率など）に応じて、投稿情報または投票に用いられるユーザインタフェースの表示態様を変更することができる。これにより、投稿情報を閲覧するユーザは、信頼性が高い投稿であるのか、信頼性が低い投稿であるのかを視覚的に判断することができる。実施形態１で説明したように、単純な正誤数だけでは信頼性が高い投稿であるのか低い情報であるのかの判別が難しい場合がある。本実施形態では、各種の条件などを考慮した投稿情報の情勢に基づいて表示態様を変えることで、投稿情報を閲覧するユーザは、投稿情報の状態を直ちに把握することができる。また、信頼性の高い投稿情報のみを選別して閲覧するといった利用形態も可能となる。

１０ ユーザ端末
１００ 投稿情報管理システム
１１０ ウェブサーバ
１１１ 投稿受付部
１１２ 提供部
１１３ 更新部
１１４ 通知部
１５０ ＤＢサーバ
１５１ 管理部
１５２ 判定部
１５３ 状態遷移部

Claims (14)

1. 投稿された投稿情報と、前記投稿情報に対する投票の情勢と、前記投稿情報の状態とを管理する管理部と、
   前記状態に基づいて、前記投稿情報を、前記投稿情報に対する投票を受け付け可能な状態でユーザ端末に提供する提供部と、
   前記投稿情報に対する投票を複数のユーザ端末から受信し、前記管理部で管理されている前記情勢を更新する更新部と、
   前記更新部において更新された前記情勢に基づいて、前記投稿情報を前記ユーザ端末に表示すべきか否かを判定する判定部と、
   前記判定部によって前記投稿情報を前記ユーザ端末に表示すべきでないと判定された場合、前記投稿情報の状態を、前記ユーザ端末において表示が行われる状態から、前記ユーザ端末において表示が行われない状態に遷移させる状態遷移部と
   を有する、投稿情報管理システム。
2. 前記判定部は、投票された第二のカテゴリへの投票数に基づく値に対する、前記第二のカテゴリよりも肯定的なカテゴリを示す第一のカテゴリへの投票数に基づく値の比に関する第一の値が、所定の閾値を下回る場合、前記投稿情報を前記ユーザ端末に表示すべきでないと判定する、請求項１に記載の投稿情報管理システム。
3. 前記判定部は、投票したユーザの情報に応じた重みを前記第一のカテゴリへの投票のそれぞれに乗じた値と、投票したユーザの情報に応じた重みを前記第二のカテゴリへの投票のそれぞれに乗じた値とを用いて前記判定を行う、請求項２に記載の投稿情報管理システム。
4. 前記判定部は、信頼区間の上限値を前記第一の値として用いる、請求項２または３に記載の投稿情報管理システム。
5. 前記所定の閾値は、前記投稿情報が投稿された日時からの経過時間に応じて変わる、請求項２から４のいずれか一項に記載の投稿情報管理システム。
6. 前記第一の値が前記所定の閾値を下回らず、かつ、前記所定の閾値よりも高い第二の閾値を下回る場合、
   前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移する可能性があることを、前記投稿情報を投稿したユーザに通知する通知部をさらに有する、請求項２から５のいずれか一項に記載の投稿情報管理システム。
7. 前記管理部は、
   前記投稿情報を投稿した投稿ユーザの情報をさらに管理し、
   前記第一のカテゴリの投票数と前記第二のカテゴリの投票数とに基づいて、当該投稿情報を投稿した投稿ユーザにポイントを付与する。請求項２から６のいずれか一項に記載の投稿情報管理システム。
8. 前記提供部は、前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移された場合、当該投稿情報の本文を非表示にした状態で当該投稿情報を前記ユーザ端末に提供し、
   前記管理部は、前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移された場合、所定の期間が経過した後に、当該投稿情報を削除する、請求項１から７のいずれか一項に記載の投稿情報管理システム。
9. 前記提供部は、前記管理部で管理されている前記投稿情報に対する票数を、前記投稿情報と共に前記ユーザ端末に提供する、請求項１から８のいずれか一項に記載の投稿情報管理システム。
10. 前記管理部で管理されている第一の投稿情報に対する再投稿である第二の投稿情報が投稿された場合、
    前記提供部は、前記第一の投稿情報を、前記第一の投稿情報に対する投票を受け付け不可能な状態で、前記第一の投稿情報に対する票数と共に前記ユーザ端末に提供し、
    前記判定部は、前記第一の投稿情報に対する投票結果を用いることなく、前記第二の投稿情報に対する投票の結果に基づいて、前記第二の投稿情報を前記ユーザ端末に表示すべきか否かを判定する、請求項９に記載の投稿情報管理システム。
11. 前記投稿情報は、投稿対象に対するユーザの評価点を含み、
    前記管理部は、
    同じ投稿対象に対する複数のユーザからの評価点に従って算出された第一の評価点を、前記投稿対象に関連付けて管理し、
    前記投稿情報の状態が、前記ユーザ端末において表示が行われない状態に遷移した場合、当該投稿情報に含まれる評価点を除いて第一の評価点を再度算出する、請求項１から１０のいずれか一項に記載の投稿情報管理システム。
12. 前記更新部において更新された前記情勢に基づいて、前記投稿情報がユーザ端末で表示される表示態様を変更する変更部をさらに有し、
    前記変更部は、前記表示態様を、
    第一のカテゴリの投票数から、前記第一のカテゴリとは異なる第二のカテゴリの投票数を差し引いた第一の数が、第二の数以上でありかつ第三の数以下の投稿を示す第一態様、
    前記第一の数が前記第三の数より大きい投稿を示す第二態様、
    前記第一の数が前記第二の数より小さい投稿を示す第三態様、および
    前記ユーザ端末で投稿情報の本文が表示されない第四態様、
    の少なくとも１つの表示態様に変更する、請求項１から１１のいずれか一項に記載の投稿情報管理システム。
13. 投稿された投稿情報と、前記投稿情報に対する投票の情勢と、前記投稿情報の状態とを管理する管理部を有する投稿情報管理システムにおける投稿情報管理方法であって、
    前記状態に基づいて、前記投稿情報を、前記投稿情報に対する投票を受け付け可能な状態でユーザ端末に提供する提供ステップと、
    前記投稿情報に対する投票を複数のユーザ端末から受信し、前記管理部で管理されている前記情勢を更新する更新ステップと、
    前記更新ステップにおいて更新された前記情勢に基づいて、前記投稿情報を前記ユーザ端末に表示すべきか否かを判定する判定ステップと、
    前記判定ステップにおいて前記投稿情報を前記ユーザ端末に表示すべきでないと判定された場合、前記投稿情報の状態を、前記ユーザ端末において表示が行われる状態から、前記ユーザ端末において表示が行われない状態に遷移させる状態遷移ステップと
    を有する、投稿情報管理方法。
14. コンピュータを、請求項１から１２のいずれか一項に記載の投稿情報管理システムにおける各部として機能させるためのプログラム。

Images