JP6857775B1 - アカウント分析システム、及びアカウント分析方法 - Google Patents

Abstract

【課題】ＳＮＳの利用者が使用している他のアカウントを効率よく高い精度で特定する。【解決手段】アカウント分析システムは、ＳＮＳサイトから随時取得される投稿情報を投稿情報データベースに蓄積して管理し、上記投稿情報に基づき、監視対象アカウントの投稿情報の定常状態を学習した機械学習モデルである定常状態モデルを生成し、新たに取得された投稿情報が異常な内容を含む異常投稿であるか否かを定常状態モデルを用いて判定し、異常投稿に基づき、投稿情報データベースに蓄積されている投稿情報の検索に用いるクエリを生成し、クエリを投稿情報データベースに適用することにより検索される投稿情報を投稿したアカウントを、監視対象アカウントの使用者と関連する候補アカウントとして特定する。【選択図】図１

Description

本発明は、アカウント分析システム、及びアカウント分析方法に関する。

特許文献１には、ＳＮＳ（Social Networking Service）などの階層分類されたコミュ
ニティ内でのユーザ自身の特徴を表すＳＮＳユーザプロファイルを抽出する抽出装置について記載されている。抽出装置は、階層分類されたコミュニティページデータ、及び該コミュニティに所属しているユーザを管理しているユーザページデータを用い、ユーザＩＤを使用してユーザページデータからユーザが所属するコミュニティのコミュニティＩＤを抽出し、コミュニティＩＤからコミュニティページデータ内の全トピックの文書を抽出し、コミュニティ文書に対して、キーワード解析を実施してコミュニティのキーワードを抽出し、キーワードの中で、ユーザが発言したキーワードをコミュニティページデータの階層構造を利用して分類することでユーザ発言プロファイルを抽出する。

特許文献２には、Ｗｅｂアクセス履歴から得られるユーザのＳＮＳ上の閲覧範囲と、ＳＮＳに構築されている交友範囲とからＳＮＳにおけるユーザ識別子を特定することを目的として構成されたユーザ特定装置について記載されている。ユーザ特定装置は、プロキシサーバに蓄積されているユーザのＳＮＳへのＷｅｂアクセス履歴に基づいて、ユーザがＳＮＳにおいてＷｅｂページの閲覧を介して交友を行ったＳＮＳユーザの範囲を示す閲覧交友範囲を取得し、ＳＮＳサーバから、各ＳＮＳユーザの交友関係の範囲を示すＳＮＳ交友範囲を取得し、取得した各ＳＮＳユーザのＳＮＳ交友範囲と、取得した閲覧交友範囲との類似度を算出し、類似度が高いＳＮＳ交友範囲を有するＳＮＳユーザのユーザ識別子を、ユーザのＳＮＳにおけるユーザ識別子として特定する。

特開２００９−９９０８８号公報 特開２０１５−２２５６１３公報

近年、ＳＮＳを利用した重大事件が多発しており、事件への発展の未然防止や事件の早期解決のために、膨大な投稿の中から違法行為を行う者（以下、「違法行為者」と称する。）の特定に繋がる情報を効率よく取得するための仕組みの構築が急務となっている。

しかし違法行為者がＳＮＳで使用するアカウントは一般に匿名性が高く、また、違法行為者は、違法行為に際して用いるアカウント（以下、「裏アカウント」と称する。）と日常生活で用いているアカウント（以下、「表アカウント」と称する。）とを使い分けていることも多い。また、違法行為者は、本人の特定に結び付くような痕跡を残さぬように慎重に言葉を選んで投稿している上、証拠隠滅のために投稿を早期に削除してしまうため、有効な情報の取得には処理の迅速性も要求される。

特許文献１に開示されている技術では、ＳＮＳに公開されているユーザ情報に基づきユーザをプロファイリングしているため、ユーザが発覚を警戒して慎重に投稿している場合は本人を特定することが難しい。また、特許文献２に開示されている技術では、プロキシ利用者という特定の母集団の中からＳＮＳのユーザを特定しているため、特定したい人物が分析者が管理するネットワークに所属している必要があり、適用可能な場面は限定され
る。

本発明はこのような背景に鑑みてなされたものであり、ＳＮＳの利用者が関連している他のアカウントを効率よく高い精度で特定することが可能な、アカウント分析システム、及びアカウント分析方法を提供することを目的とする。

上記目的を達成するための本発明の一つは、アカウント分析システムであって、情報処理装置を用いて構成され、ＳＮＳサイトから随時取得される投稿情報を蓄積して管理する投稿情報データベースと、前記投稿情報に基づき、監視対象アカウントの投稿情報の定常状態を学習した機械学習モデルである定常状態モデルを生成する定常状態学習部と、新たに取得された前記投稿情報が異常な内容を含む異常投稿であるか否かを前記定常状態モデルを用いて判定する異常投稿判定部と、前記異常投稿に基づき、前記投稿情報データベースに蓄積されている前記投稿情報の検索に用いるクエリを生成するクエリ生成部と、前記クエリを前記投稿情報データベースに適用することにより検索される前記投稿情報を投稿したアカウントを、前記監視対象アカウントの使用者の他のアカウントの候補である候補アカウントとして特定する類似投稿検索部と、を備える。

その他、本願が開示する課題、及びその解決方法は、発明を実施するための形態の欄、及び図面により明らかにされる。

本発明によれば、ＳＮＳの利用者が使用している他のアカウントを効率よく高い精度で特定することができる。

アカウント分析システムの概略的な構成を示す図である。 監視対象アカウント設定画面の一例である。 投稿情報ＴＢＬの一例である。 アカウント情報ＴＢＬの一例である。 異常検出通知画面及び関連アカウント提示画面の一例である。 アカウント分析装置や管理者端末の実現に用いる情報処理装置のハードウェア構成の一例である。 アカウント分析処理を説明するフローチャートである。 定常状態モデル生成処理を説明するフローチャートである。 異常有無判定処理を説明するフローチャートである。 関連アカウント特定処理を説明するフローチャートである。 定常状態モデル更新処理を説明するフローチャートである。 第２実施形態のアカウント分析システムの概略的な構成を示す図である。 第２実施形態のアカウント情報ＴＢＬの一例である。 監視対象アカウント決定処理を説明するフローチャートである。 監視対象アカウント入力画面の一例である。

以下、図面を参照しつつ本発明の実施形態について説明する。尚、以下の記載及び図面は本発明を説明するための例示に過ぎず、説明の明確化のため、適宜、省略や簡略化がなされている。また、本発明は、他の種々の形態でも実施することが可能である。また、とくに限定しない限り、各構成要素は単数でも複数でも構わない。

以下の説明において、同一の又は類似する構成に同一の符号を付して重複した説明を省
略することがある。また、以下の説明では、「情報」、「テーブル」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。また、識別情報の表現として、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現があるが、これらについてはお互いに置換することが可能である。また、以下の説明において、「データベース」のことを「ＤＢ」と、「テーブル」のことを「ＴＢＬ」と、夫々表記することがある。

また、以下の説明において、ソーシャルネットワークサービス（Social Networking Service）（Ｔｗｉｔｔｅｒ（登録商標）、Ｆａｃｅｂｏｏｋ（登録商標）、電子掲示板等
）のことを「ＳＮＳ」と称する。また、ＳＮＳを利用して違法行為を行う者（以下、「違法行為者」と称する。）が違法行為に関する投稿を行う際に使用するアカウントのことを「裏アカウント」と称し、違法行為者がそれ以外の用途で使用しているアカウントのことを「表アカウント」と称する。

[第１実施形態]
図１に、第１実施形態として説明する情報処理システム（以下、「アカウント分析システム１」と称する。）の概略的な構成（機能ブロック図）を示している。同図に示すように、アカウント分析システム１は、アカウント分析装置１０と管理者端末２とを含む。アカウント分析システム１は、例えば、ＳＮＳサイト３における投稿を監視する業務を行う企業や官公庁等の組織によって利用される。

アカウント分析装置１０は、インターネット等の通信ネットワーク５を介してＳＮＳを提供する情報処理装置（以下、「ＳＮＳサイト３」と称する。）と通信可能に接続している。また、アカウント分析装置１０は、有線方式又は無線方式の通信手段（ＬＡＮ（Local Area Network）、無線ＬＡＮ等）を介して管理者端末２と通信可能に接続している。

アカウント分析装置１０は、ＳＮＳサイト３における投稿を分析することにより、監視の対象となるアカウント（例えば、違法行為者が使用している裏アカウント。以下、「監視対象アカウント」と称する。）を用いて行われた投稿に関する情報（投稿内容や投稿日時等。以下、「投稿情報」と称する。）に基づき、監視対象アカウントの使用者の本人に結び付く情報が記載されている可能性の高い他のアカウント（例えば、違法行為者が使用している表アカウント。以下、「関連アカウント」とも称する。）を特定し、特定した関連アカウントをユーザに提示する。

同図に示すように、アカウント分析装置１０は、情報収集部１００及び情報分析部２００の各機能を有する。情報収集部１００は、通信ネットワーク５を介してＳＮＳサイト３から投稿情報を取得し、取得した投稿情報を情報分析部２００に入力する。情報分析部２００は、情報収集部１００から入力された投稿情報に基づき関連アカウントを特定し、特定した関連アカウントを管理者端末２を介してユーザに提示する。

管理者端末２は、監視対象アカウントの設定、投稿情報の取得先に関する情報（取得先となるＳＮＳサイト３の所在や識別子等）の設定、関連アカウントの提示等を行うユーザインタフェースを、アカウント分析システム１の管理者や利用者等のユーザに提供する。

図２に、監視対象アカウントの設定に際し管理者端末２がユーザに提示する画面（以下、「監視対象アカウント設定画面２０００」と称する。）の一例を示す。例示する監視対象アカウント設定画面２０００は、新たに追加する監視対象アカウントの設定欄２０１０、及び監視対象アカウントに関する情報の表示欄２０２０を有する。

ユーザは、監視対象アカウントの設定欄２０１０に、新たに監視対象とするアカウント
の識別子（以下、「アカウントＩＤ」と称する。）を入力して追加ボタン２０１１を操作することにより、監視対象アカウントを追加することができる。

監視対象アカウントに関する情報の表示欄２０２０には、監視対象アカウント（アカウントＩＤ２０２１）に対応付けて、当該監視対象アカウントの監視開始日時の表示欄２０２２、現在の状態を示す情報の表示欄２０２３（監視中であれば「監視中」、監視を停止中であれば「停止中」が表示される。）、及び監視対象とするか否かを制御するためのボタン（以下、「監視制御ボタン２０２４」と称する。）が設けられている。ユーザは、監視対象アカウントごとに設けられている監視制御ボタン２０２４を操作することで、対応する監視対象アカウントを監視中とするか否かを制御することができる。

図１に示すように、アカウント分析装置１０の情報収集部１００は、管理部１１１、クローラ部１１２、投稿情報ＤＢ１１３、アカウント情報更新部１１４、及びアカウント情報ＤＢ１１５の各機能を備える。

管理部１１１は、管理者端末２から監視対象アカウントの情報や投稿情報の取得先のＳＮＳサイト３に関する情報の設定を受け付け、前者の監視対象アカウントの情報についてはアカウント情報更新部１１４に、後者の投稿情報の取得先のＳＮＳサイト３に関する情報についてはクローラ部１１２に、夫々入力する。

クローラ部１１２は、管理部１１１から入力された投稿情報の取得先のＳＮＳサイト３に随時（例えば、数分ごと、数時間ごと、一日ごと等、予め設定された時間が経過するごと等）アクセスして投稿情報を取得し、取得した投稿情報を投稿情報ＤＢ１１３に入力する。クローラ部１１２は、例えば、ＳＮＳサイト３が提供するＡＰＩ（Application Programming Interface）を利用して投稿情報を取得する。投稿情報ＤＢ１１３は、クローラ
部１１２から入力された投稿情報を、テーブル（以下、「投稿情報ＴＢＬ１１３０」と称する。）に管理（登録）する。尚、クローラ部１１２による投稿情報の収集は、投稿情報がＳＮＳサイト３から消されてしまう前に、新たな投稿がされてからなるべく早期に実施することが好ましい。

図３に、投稿情報ＴＢＬ１１３０の一例を示す。例示する投稿情報ＴＢＬ１１３０は、投稿ＩＤ１１３１、アカウントＩＤ１１３２、投稿日時１１３３、投稿内容１１３４、投稿相手１１３５、画像１１３６等の項目を有する複数のエントリ（レコード）で構成される。投稿情報ＴＢＬ１１３０の一つのエントリは一つの投稿の投稿情報に相当する。

上記項目のうち、投稿ＩＤ１１３１には、投稿の識別子である投稿ＩＤが設定される。アカウントＩＤ１１３２には、アカウントＩＤが設定される。投稿日時１１３３には、当該投稿がされた日時が設定される。投稿内容１１３４には、当該投稿の内容が設定される。投稿相手１１３５には、当該投稿が通信相手を特定して行われたものである場合は当該通信相手のアカウントＩＤが設定され、通信相手を特定せずに行われたものである場合は「無し」が設定される。画像１１３６には、当該投稿に画像が添付されている場合は「有り」が設定され、画像が添付されていなければ「無し」が設定される。

図１に戻り、アカウント情報更新部１１４は、管理部１１１から入力された監視対象アカウントの情報をアカウント情報ＤＢ１１５に入力する。アカウント情報ＤＢ１１５は、アカウント情報更新部１１４から入力された監視対象アカウントの情報（以下、「アカウント情報」と称する。）をテーブル（以下、「アカウント情報ＴＢＬ１１５０」と称する。）に管理（登録）する。

図４にアカウント情報ＴＢＬ１１５０の一例を示す。例示するアカウント情報ＴＢＬ１
１５０は、アカウントＩＤ１１５１、監視開始日時１１５２、及び状態１１５３等の項目を含む一つ以上のエントリ（レコード）で構成される。アカウント情報ＴＢＬ１１５０の一つのエントリは一つの監視対象アカウントのアカウント情報に対応している。

上記項目のうち、アカウントＩＤ１１５１には、監視対象アカウントのアカウントＩＤが設定される。監視開始日時１１５２には、監視対象アカウント設定画面２０００で設定された監視開始日時の表示欄２０２２の内容が設定される。状態１１５３には、当該監視対象アカウントが現在監視中であれば「監視中」が、現在監視を停止中であれば「停止中」が設定される。

図１に示すように、情報分析部２００は、定常状態学習部２１１、定常状態モデル２１２、異常投稿判定部２１３、クエリ生成部２１４、類似投稿検索部２１５、フィルタ処理部２１６、通知部２１７、及び結果通知部２１８の各機能を備える。

定常状態学習部２１１は、アカウント情報ＴＢＬ１１５１に登録されている各監視対象アカウントについて、投稿情報ＴＢＬ１１３０から取得される夫々の投稿情報に基づき、夫々の定常状態を学習することにより得られる機械学習モデルである定常状態モデル２１２を生成する（即ち、監視対象アカウントごとに定常状態モデル２１２が生成される。）。定常状態学習部２１１は、投稿情報ＴＢＬ１１３０の内容を学習データとして用いて定常状態モデル２１２を学習する。

定常状態モデル２１２は、投稿情報が異常な内容を含むか否か（投稿情報の内容が定常状態か否か）を判定する機械学習モデル（異常検知モデル）である。定常状態モデル２１２は、例えば、オートエンコーダを用いた時系列データの異常検知の仕組みにより生成される。その場合、上記時系列データは、例えば、各監視対象アカウントの投稿情報から取得される、平均投稿数、平均投稿文字数、平均画像添付割合、主要投稿時間帯、主要投稿曜日、投稿に頻繁に用いられる文章や用語、投稿に付与されるハッシュタグ、投稿の長さ、投稿に用いられる文体等についての時系列データである。

定常状態学習部２１１は、新たな投稿情報を学習データとして用いて定常状態モデル２１２を再学習する。上記再学習を行うタイミングは必ずしも限定されないが、本実施形態では、上記再学習は、当該新たな投稿情報について異常投稿判定部２１３により異常無し（定常）と判定された場合に行われるものとする。

異常投稿判定部２１３は、クローラ部１１２により、ある監視対象アカウントにより投稿された新たな投稿情報が取得されると、当該監視対象アカウントの定常状態モデル２１２を用いて、取得された新たな投稿情報が異常な内容を含むか否かを判定する。異常投稿判定部２１３は、新たな投稿情報が異常な内容を含むと判定すると、当該投稿情報（以下、「異常投稿」と称する。）をクエリ生成部２１４に入力する。

クエリ生成部２１４は、異常投稿判定部２１３から入力された異常投稿に基づき、投稿情報ＴＢＬ１１３０に適用するクエリを生成する。上記クエリの態様は必ずしも限定されないが、例えば、異常投稿の内容の全文や異常投稿の内容から抽出される一つ以上の用語をキーワードとして用いることにより編成される。クエリ生成部２１４は、編成したクエリを類似投稿検索部２１５に入力する。

類似投稿検索部２１５は、入力されたクエリを投稿情報ＴＢＬ１１３０に適用して投稿情報を検索する。これにより異常投稿の内容と類似する内容の投稿情報が投稿情報ＴＢＬ１１３０から取得される。類似投稿検索部２１５は、検索された投稿情報から当該投稿情報のアカウント（アカウントＩＤ）を、監視対象アカウントの使用者が使用している他の
アカウントの候補として取得し、取得したアカウント（以下、「候補アカウント」と称する。）のアカウントＩＤをフィルタ処理部２１６に入力する。

フィルタ処理部２１６は、類似投稿検索部２１５から入力された候補アカウントから、投稿情報ＴＢＬ１１３０から取得される、監視対象アカウントにより行われた過去の投稿情報の投稿日時と同じ日時に投稿されている、上記クエリにより検索された投稿情報のアカウント（当該投稿情報の投稿に用いられているアカウント）を除外したアカウントを、監視対象アカウントの使用者が使用している他のアカウント（関連アカウント）として特定する。ここで候補アカウントから、上記のように同じ日時に投稿を行っているアカウントを除外するのは、同じ投稿者が同時に異なるアカウントを使って投稿することは通常は考えにくいからである。このように、投稿情報ＴＢＬ１１３０の投稿情報に基づき監視対象アカウントの使用者が使用しているアカウントである可能性が低いと判定されるアカウントを候補アカウントから除外することで、監視対象アカウントの使用者が使用している他のアカウントの特定精度を高めることができる。

尚、異常投稿と異常な内容を含まない投稿情報との違いは、例えば、平均投稿数の変化（普段は短い文章を投稿しているアカウントが長文を投稿した場合）、主要投稿時間帯の変化（普段は昼間の投稿が多いアカウントが夜間に投稿した場合）、投稿に付与されるハッシュタグの違い等として現れる。新たな投稿情報が定常状態から外れた異常な内容を含む場合の一例として、例えば、監視対象アカウントが、本来、表アカウントで投稿すべき内容を裏アカウントで発言してしまった場合があり、例えば、平日は裏アカウントを利用して違法行為に関する投稿を行い、休日は表アカウントを利用して友人や家族等の親しい者に向けた投稿を行っている違法行為者が、休日に表アカウントで投稿すべき内容をうっかり裏アカウントで投稿（いわゆる「誤爆投稿」）してしまった場合である。アカウント分析装置１０は、例えば、こうした「誤爆投稿」を異常投稿として検知し、検知した異常投稿を利用して監視対象アカウントの関連アカウントを特定する。

フィルタ処理部２１６は、異常投稿が検出された旨を通知部２１７に入力する。また、フィルタ処理部２１６は、関連アカウントに関する情報を結果通知部２１８に入力する。

通知部２１７は、フィルタ処理部２１６から異常投稿が検出された旨の通知が入力されると、その旨をユーザに提示する画面（以下、「異常検出通知画面５１０」と称する。）を生成し、生成した異常検出通知画面５１０を管理者端末２に送信する。管理者端末２は、送られてきた異常検出通知画面５１０を表示してユーザに提示する。

また、結果通知部２１８は、フィルタ処理部２１６から関連アカウントが入力されると、関連アカウントに関する情報を記載した画面（以下、「関連アカウント提示画面５２０」と称する。）を生成し、生成した関連アカウント提示画面５２０を管理者端末２に送信する。管理者端末２は、送られてきた関連アカウント提示画面５２０を表示してユーザに提示する。

図５に、異常検出通知画面５１０及び関連アカウント提示画面５２０の一例を示す。同図に示すように、例示する異常検出通知画面５１０には、監視対象アカウント（アカウントＩＤ５１２）ごとに異常の有無５１１を示す情報が表示されている。ユーザが、例えば、マウスポインタ５１３を操作していずれかの監視対象アカウントを選択すると、管理者端末２は、選択された監視対象アカウントについての関連アカウントを記載した関連アカウント提示画面５２０を表示する。

例示する関連アカウント提示画面５２０には、投稿ＩＤ５２１、投稿日時５２２、異常性５２３、関連アカウント５２４等の項目ごとに情報が表示される。投稿ＩＤ５２１には
、当該監視対象アカウントによる投稿（投稿情報）の投稿ＩＤが、投稿日時５２２には、当該投稿の投稿日時が、異常性５２３には、当該投稿についての異常の有無の判定結果が、関連アカウント５２４には、当該投稿に基づき特定された関連アカウントのアカウントＩＤが、夫々設定される。尚、異常性５２３には、当該投稿（投稿情報）が異常投稿でなければ「通常」が表示され、当該投稿（投稿情報）が異常投稿であれば「異常」が表示される。

ユーザは、異常検出通知画面５１０を参照することで、監視対象アカウントにより行われた投稿について異常が検出されたことを知ることができる。そのため、ユーザは、例えば、該当の投稿を調査して効率よく違法行為者に関する情報を得ることができる。また、ユーザは、関連アカウント提示画面５２０を参照することで、異常が検出された投稿の投稿者が使用している他のアカウントである可能性の高いアカウントを知ることができ、例えば、当該アカウントを監視対象アカウントとして追加することで、効率よく違法行為者に関する情報を収集することができる。

図６は、アカウント分析装置１０や管理者端末２の構成に用いる情報処理装置のハードウェア構成の一例である。例示する情報処理装置２０は、プロセッサ２１、主記憶装置２２、通信装置２３、入力装置２４、出力装置２５、及び補助記憶装置２６を備える。

尚、例示する情報処理装置２０の全部又は一部は、例えば、クラウドシステムによって提供される仮想サーバのように、仮想化技術やプロセス空間分離技術等を用いて提供される仮想的な情報処理資源を用いて実現されるものであってもよい。また、情報処理装置２０によって提供される機能の全部又は一部は、例えば、クラウドシステムがＡＰＩ（Application Programming Interface）等を介して提供するサービスによって実現してもよい
。また、情報処理装置２０によって提供される機能の全部又は一部は、例えば、ＳａａＳ（Software as a Service）、ＰａａＳ（Platform as a Service）、ＩａａＳ（Infrastructure as a Service）等を利用して実現されるものであってもよい。

プロセッサ２１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＧＰＵ（Graphics Processing Unit）、ＡＩ（Artificial Intelligence）チップ、ＦＰＧＡ（Field Programmable Gate Array）、ＳｏＣ（System on Chip）、ＡＳＩＣ（Application Specific Integrated Circuit）等を用いて構成される。

主記憶装置２２は、プログラムやデータを記憶する装置であり、例えば、ＲＯＭ（Read
Only Memory）、ＲＡＭ（Random Access Memory）、不揮発性メモリ（ＮＶＲＡＭ（Non Volatile RAM））等である。

通信装置２３は、通信ネットワーク（ＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット、専用線、公衆通信網等）を介して、他の情報処理装置
（スマートフォン、タブレット、ノートブック型コンピュータ、各種携帯情報端末等）との間で通信を行う装置であり、無線又は有線の通信モジュール（無線通信モジュール、通信ネットワークアダプタ、ＵＳＢモジュール等）である。

入力装置２４は、ユーザからの入力や外部の装置からのデータ入力を受け付けるユーザインタフェースであり、例えば、キーボード、マウス、タッチパネル、カードリーダ、音声入力装置(例えば、マイクロフォン)等である。

出力装置２５は、各種情報を、画像によって出力する表示装置、音声によって出力する音声出力装置、紙媒体に印刷する印刷装置等である。

補助記憶装置２６は、プログラムやデータを格納する装置であり、例えば、ＳＳＤ（Solid State Drive）、ハードディスクドライブ、光学式記憶媒体（ＣＤ（Compact Disc）
、ＤＶＤ（Digital Versatile Disc）等）、ＩＣカード、ＳＤカード等である。補助記憶装置２６の全部又は一部は、クラウドが提供する仮想的な記憶領域等であってもよい。補助記憶装置２６には、アカウント分析装置１０や管理者端末２の機能を実現するためのプログラムやデータが格納されている。プログラムやデータは、記録媒体の読取装置や通信装置２３を介して補助記憶装置２６に読み込むことができる。補助記憶装置２６に格納（記憶）されているプログラムやデータは主記憶装置２２に随時読み込まれる。プロセッサ２１は、補助記憶装置２６に格納されているプログラムを主記憶装置２２に読み出して実行することにより各種の機能を実現する。

情報処理装置２０には、例えば、オペレーティングシステム、ファイルシステム、ＤＢＭＳ（DataBase Management System）（リレーショナルデータベース、ＮｏＳＱＬ等）、ＫＶＳ（Key-Value Store）等が導入されていてもよい。

図７は、アカウント分析システム１において行われる処理（以下、「アカウント分析処理Ｓ７００」と称する。）を説明するフローチャートである。同図において、Ｓ７１１〜Ｓ７１２の処理は、情報収集部１００を主体として行われる処理であり、Ｓ７１３〜Ｓ７６０の処理は、情報分析部２００を主体として行われる処理である。尚、アカウント分析処理Ｓ７００の実行時において、アカウント情報ＤＢ１１５には、アカウント情報更新部１１４によってアカウント情報ＴＢＬ１１５０の内容が設定済であるものとする。

同図に示すように、情報収集部１００のクローラ部１２は、管理部１１１から入力される取得先のＳＮＳサイト３に随時アクセスして新たな投稿情報を取得し、取得した新たな投稿情報を、投稿情報ＤＢ１１３に入力する（Ｓ７１１）。投稿情報ＤＢ１１３は、入力された投稿情報を投稿情報ＴＢＬ１１３０に登録する（Ｓ７１２）。

情報分析部２００は、アカウント情報ＴＢＬ１１５０を参照し、Ｓ７１１でクローラ部１１２が取得した新たな投稿情報が監視対象アカウントによる投稿であるか否かを判定する（Ｓ７１３）。クローラ部１１２が取得した新たな投稿情報が、監視対象アカウントによる投稿である場合（Ｓ７１３：ＹＥＳ）、処理はＳ７１５に進む。一方、クローラ部１１２が取得した新たな投稿情報が監視対象アカウントによる投稿でない場合（Ｓ７１３：ＮＯ）、処理はＳ７１１に戻る。

Ｓ７１４では、情報分析部２００が、新たな投稿情報を投稿した監視対象アカウントの定常状態モデル２１２が存在するか（定常状態モデル２１２を記憶しているか）否かを判定する。当該監視対象アカウントの定常状態モデル２１２が存在しない場合（Ｓ７１４：ＮＯ）、情報分析部２００の定常状態学習部２１１１が当該アカウントの定常状態モデル２１２を生成する処理（以下、「定常状態モデル生成処理Ｓ７２０」と称する。）を行い、その後、処理はＳ７１１に戻る。一方、当該アカウントの定常状態モデル２１２が存在する場合（Ｓ７１４：ＹＥＳ）、情報分析部２００の異常投稿判定部２１３が、新たな投稿情報についての異常の有無を判定する処理（以下、「異常有無判定処理Ｓ７４０」と称する。）を行い、その後、処理はＳ７４５に進む。

尚、当該監視対象アカウントの定常状態モデル２１２が存在してはいるが、当該定常状態モデル２１２の学習が十分に進んでおらず（十分な量の学習データが適用されていない）、当該定常状態モデル２１２の信頼性が十分でない場合、情報分析部２００が、Ｓ７１４において「ＮＯ」と判定して新たな投稿情報を学習データとする定常状態モデル２１２の学習のみを行い（Ｓ７２０）、その後はＳ７１１に戻るようにしてもよい。

図８は、図７に示した定常状態モデル生成処理Ｓ７２０を説明するフローチャートである。同図に示すように、まず、定常状態学習部２１１が、投稿情報ＴＢＬ１１３０から当該監視対象アカウントの投稿情報を取得する（Ｓ８１１）。続いて、定常状態学習部２１１は、取得した投稿情報を学習データとして学習した機械学習モデルを生成し（Ｓ８１２）、生成した機械学習モデルを当該監視対象アカウントの定常状態モデル２１２として記憶する（Ｓ８１３）。その後、処理は図７のＳ７１１に戻る。

図９は、図７に示した異常有無判定処理Ｓ７４０を説明するフローチャートである。同図に示すように、まず、異常投稿判定部２１３が、当該監視対象アカウントの定常状態モデル２１２を取得する（Ｓ９１１）。続いて、異常投稿判定部２１３は、新たな投稿情報を定常状態モデル２１２に適用し、新たな投稿情報が異常な内容を含むか否かを判定する（Ｓ９１２）。その後、判定結果を戻り値（新たな投稿情報が異常な内容を含む場合は「異常」が、含まない場合は「定常」が設定される。）として、処理は図７のＳ７４５に進む。

図７に戻り、Ｓ７４５では、情報分析部２００は、異常有無判定処理Ｓ７４０の判定結果（戻り値）が「異常」であるか否かを確認する。判定結果が「異常」である場合（Ｓ７４５：ＹＥＳ）、情報分析部２００は、関連アカウントを取得する処理（以下、「関連アカウント特定処理Ｓ７５０」と称する。）を実行する。一方、判定結果が「定常」である場合（Ｓ７４５：ＮＯ）、情報分析部２００は、新たな投稿情報を学習データとして定常状態モデル２１２を更新する処理（以下、「定常状態モデル更新処理Ｓ７６０」と称する。）を行う。これにより定常状態モデル２１２が最新の投稿を反映した内容に更新される。定常状態モデル更新処理Ｓ７６０の詳細については後述する。

図１０は、図７の関連アカウント特定処理Ｓ７５０を説明するフローチャートである。同図に示すように、まず、情報分析部２００のクエリ生成部２１４が、異常投稿に基づきクエリを生成する（Ｓ１０１１）。

続いて、情報分析部２００の類似投稿検索部２１５が、生成されたクエリを投稿情報ＴＢＬ１１３０に適用して投稿情報を検索し、検索された投稿情報を投稿したアカウントを候補アカウントとして特定する（Ｓ１０１２）。

続いて、情報分析部２００のフィルタ処理部２１６が、当該異常投稿を投稿した監視対象アカウントの全ての投稿情報の投稿日時を、投稿情報ＴＢＬ１１３０から取得する（Ｓ１０１３）。

続いて、フィルタ処理部２１６が、候補アカウントから、Ｓ１０１３で取得した監視対象アカウントによる投稿情報の投稿日時と同じ日時に投稿されている投稿情報に基づくアカウントを除外したものを関連アカウントとして特定する（Ｓ１０１４）。

続いて、フィルタ処理部２１６が、関連アカウントを、通知部と結果通知部に入力する（Ｓ１０１５）。その後、処理は図７のＳ７５５に進む。

図７に戻り、Ｓ７５５では、通知部２１７が、入力された関連アカウントに基づき異常検出通知画面５１０を生成して管理者端末２に送信する。また、結果通知部２１８が、入力された関連アカウントに基づき関連アカウント提示画面５２０を生成して管理者端末２に送信する。管理者端末２は、異常検出通知画面５１０及び関連アカウント提示画面５２０を受信して当該画面を表示する。その後、処理はＳ７１１に戻る。

図１１は、定常状態モデル更新処理Ｓ７６０を説明するフローチャートである。同図に
示すように、まず、定常状態学習部２１１が、当該監視対象アカウントの定常状態モデル２１２を取得する（Ｓ１１１１）。続いて、定常状態学習部２１１は、新たな投稿情報を学習データとして、取得した定常状態モデル２１２を再学習する（Ｓ１１１２）。その後、処理は図７のＳ７１１に戻る。

以上に説明したように、アカウント分析システム１は、監視対象アカウントによる投稿（投稿情報）の定常状態を学習した定常状態モデルを用いて監視対象アカウントが行った新たな投稿情報が異常投稿であるか否かを監視し、異常投稿を検出した場合、当該異常投稿の内容に基づくクエリを生成して投稿情報ＴＢＬ１１３０を検索して異常投稿と内容が類似する投稿情報を検索し、検索された投稿情報を投稿したアカウントを監視対象アカウントの使用者が関与する他のアカウントの候補として特定するので、監視対象アカウントの使用者が関連する他のアカウントを効率よく特定することができる。

また、アカウント分析システム１は、候補として特定したアカウントのうち、監視対象アカウントの使用者と可能性の低いアカウントを除外したものを関連アカウントとして特定するので、監視対象アカウントの使用者と関連する他のアカウントを高い精度で特定することができる。

また、アカウント分析システム１は、異常投稿を検知した旨や、異常投稿に基づき特定した関連アカウントに関する情報をユーザに提示するので、ユーザは、これらの情報を利用して違法行為者に関する情報を効率よく収集することができる。

[第２実施形態]
図１２に、第２実施形態として説明するアカウント分析システム１の概略的な構成（機能ブロック図）を示している。第２実施形態のアカウント分析システム１は、情報収集部１００の構成が第１実施形態のアカウント分析システム１と一部相違する。また、第２実施形態のアカウント分析システム１は、監視対象決定部１５０を備える。尚、第２実施形態の情報分析部２００の構成は、第１実施形態のアカウント分析システム１の情報分析部２００と同様である。以下、第１実施形態との相違点を中心として説明する。

第１実施形態では、情報収集部１００が、管理者端末２から監視対象アカウントの指定を受け付けていたが、第２実施形態では、管理者端末２を介してユーザから受け付けた監視対象アカウントに基づき監視対象決定部１５０が監視対象アカウントを追加する。

同図に示すように、第２実施形態の情報収集部１００は、管理部１１１、クローラ部１１２、投稿情報ＤＢ１１３、アカウント情報生成部１１６、及びアカウント情報ＤＢ１１７の各機能を備える。

第１実施形態と同様、管理部１１１は、管理者端末２から投稿情報の取得先のＳＮＳサイト３に関する情報の設定を受け付け、受け付けた投稿情報の取得先のＳＮＳサイト３に関する情報をクローラ部１１２に入力する。また、第１実施形態と同様、クローラ部１１２は、管理部１１１から入力された投稿情報の取得先のＳＮＳサイト３に随時（数時間ごと、一日ごと等、予め設定された時間間隔等）アクセスして投稿情報を取得し、取得した投稿情報を投稿情報ＤＢ１１３に入力し、投稿情報ＤＢ１１３は、入力された投稿情報を、投稿情報ＴＢＬ１１３０に管理（登録）する。

アカウント情報生成部１１６は、投稿情報ＴＢＬ１１３０に登録されている投稿情報のアカウントの情報（以下、「アカウント情報」と称する。）をアカウント情報ＤＢ１１７に入力する。アカウント情報は、投稿情報ＴＢＬ１１３０に登録されている投稿情報の内容や、同じアカウントにより投稿された複数の投稿情報について統計処理を施すことによ
り取得される情報等を含む。アカウント情報ＤＢ１１７は、アカウント情報生成部１１６から入力された情報をテーブル（以下、「アカウント情報ＴＢＬ１１７０」と称する。）に管理（登録）する。

図１３に、アカウント情報ＴＢＬ１１７０の一例を示す。同図に示すように、例示するアカウント情報ＴＢＬ１１７０は、アカウントＩＤ１１７１、ユーザ名１１７２、投稿数１１７３、平均投稿文字数１１７４、画像添付割合１１７５、主要投稿時間帯１１７６、主要投稿曜日１１７７等の項目を含む一つ以上のエントリ（レコード）で構成される。アカウント情報ＴＢＬ１１７０の一つのエントリは一つのアカウントに対応している。

上記項目のうち、アカウントＩＤ１１７１には、投稿情報ＴＢＬ１１３０の投稿情報から取得されるアカウントＩＤが設定される。ユーザ名１１７２には、投稿情報ＴＢＬ１１３０の投稿情報から取得されるユーザ名が設定される。投稿数１１７３には、投稿情報ＴＢＬ１１３０における当該アカウントの投稿数が設定される。平均投稿文字数１１７４には、当該アカウントを使用して行われた投稿の平均文字数が設定される。画像添付割合１１７５には、投稿情報ＴＢＬ１１３０に管理されている当該アカウントを使用して行われた投稿（投稿情報）のうち、画像が添付されていた投稿の割合が設定される。主要投稿時間帯１１７６には、投稿情報ＴＢＬ１１３０に管理されている当該アカウントを使用して行われた投稿がされた主な時間帯（例えば、平均投稿数が最大の時間帯）が設定される。主要投稿曜日１１７７には、投稿情報ＴＢＬ１１３０に管理されている当該アカウントを使用して行われた投稿がされた主な曜日（例えば、平均投稿数が最大の曜日）が設定される。

図１２に戻り、同図に示すように、監視対象決定部１５０は、監視対象アカウント受付部１５１、監視対象アカウント取得部１５２、及び監視対象アカウント決定部１５３の各機能を有する。

監視対象アカウント受付部１５１は、管理者端末２から、監視対象アカウントの入力を受け付ける。ユーザは、例えば、既に知っている違法行為者のアカウントを監視対象アカウントとして入力する。尚、本実施形態では、このように監視対象アカウントをユーザから受け付けるが、監視対象決定部１５０は他の方法で監視対象アカウントを取得してもよい。

監視対象アカウント取得部１５２は、受け付けた監視対象アカウントについてアカウント情報ＴＢＬ１１７０から取得されるアカウント情報に類似するアカウント情報のアカウント（以下、「類似アカウント」と称する。）をアカウント情報ＴＢＬ１１７０から取得する。尚、監視対象アカウント取得部１５２は、両者が類似するか否かの判定を、例えば、アカウント情報の各項目の値の差の合計が予め設定された閾値以下であるか否かに基づき行う。

監視対象アカウント決定部１５３は、監視対象アカウント受付部１５１がユーザから受け付けた監視対象アカウントに類似アカウントを追加したものを監視対象アカウントとして決定し、決定した監視対処アカウントを情報分析部２００の定常状態学習部２１１に入力する。

図１４は、監視対象決定部１５０が監視対象アカウントの決定に際して行う処理（以下、「監視対象アカウント決定処理Ｓ１４００」と称する。）を説明するフローチャートである。

同図に示すように、まず、監視対象アカウント受付部１５１が、管理者端末２を介して
ユーザから監視対象アカウントの入力を受け付ける（Ｓ１４１１）。

続いて、監視対象アカウント取得部１５２が、受け付けた監視対象アカウントのアカウント情報をアカウント情報ＴＢＬ１１７０から取得する（Ｓ１４１２）。

続いて、監視対象アカウント取得部１５２は、アカウント情報ＴＢＬ１１７０から類似アカウントを取得する（Ｓ１４１３）。

続いて、監視対象アカウント決定部１５３が、監視対象アカウント受付部１５１がユーザから受け付けた監視対象アカウントに類似アカウントを追加したものを監視対象アカウントとして決定し、決定した監視対象アカウントを情報分析部２００の定常状態学習部２１１に入力する（Ｓ１４１４）。

図１５は、監視対象アカウントをユーザから受け付ける際や決定した（拡張後の）監視対象アカウントをユーザに提示する際に管理者端末２がユーザに提示する画面（以下、「監視対象アカウント入力画面１５００」と称する。）の一例である。監視対象アカウント入力画面１５００は、例えば、監視対象決定部１５０により生成され管理者端末２に送信される。

例示する監視対象アカウント入力画面１５００は、監視対象アカウントの入力欄１５１０、及び監視対象アカウントのアカウントＩＤの表示欄１５２１、及び類似アカウントの表示欄１５２２を有する。ユーザは、監視対象アカウントの入力欄１５１０に監視対象アカウントのアカウントＩＤを入力して追加ボタン１５１１を操作する。類似アカウントの表示欄１５２２には、ユーザが入力した監視対象アカウントの類似アカウントのアカウントＩＤが表示される。

以上のように、第２実施形態のアカウント分析システム１では、監視対象決定部１５０が、ユーザから受け付けた監視対象アカウントに自動的に類似アカウントを追加するので、例えば、ユーザが事前に知っているアカウントに、更に同様の違法行為を実施する別の違法行為者が使用している可能性の高いアカウントが監視対象として追加され、ユーザは、違法行為者が使用している他のアカウントの探索を効率よく行うことができる。

以上、本発明の一実施形態について説明したが、本発明は上記の実施形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記実施形態の構成の一部について、他の構成の追加や削除、置換をすることが可能であり、例えば、アカウント分析システム１が管理者端末２としても機能するように構成してもよい。

また、上記の各構成、機能部、処理部、処理手段等は、それらの一部又は全部を、例えば、集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、Ｉ
Ｃカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

以上に説明した各情報処理装置の各種機能部、各種処理部、各種データベースの配置形態は一例に過ぎない。各種機能部、各種処理部、各種データベースの配置形態は、これらの装置が備えるハードウェアやソフトウェアの性能、処理効率、通信効率等の観点から最
適な配置形態に変更し得る。

前述した各種のデータを格納するデータベースの構成（スキーマ（Schema）等）は、リソースの効率的な利用、処理効率向上、アクセス効率向上、検索効率向上等の観点から柔軟に変更し得る。

１ アカウント分析システム、３ ＳＮＳサイト、５ 通信ネットワーク、１０ アカウント分析装置、１００ 情報収集部、１１１ 管理部、１１２ クローラ部、１１３ 投稿情報ＤＢ、１１３０ 投稿情報ＴＢＬ、１１４ アカウント情報更新部、１１５ アカウント情報ＤＢ、１１６ アカウント情報生成部、１１７ アカウント情報ＤＢ、１１５０ アカウント情報ＴＢＬ、１１７０ アカウント情報ＴＢＬ、１５０ 監視対象決定部、１５１ 監視対象アカウント受付部、１５２ 監視対象アカウント取得部、１５３ 監視対象アカウント決定部、２００ 情報分析部、２１１ 定常状態学習部、２１２ 定常状態モデル２１２、２１３ 異常投稿判定部、２１４ クエリ生成部、２１５ 類似投稿検索部、２１６ フィルタ処理部、２１７ 通知部、２１８ 結果通知部、Ｓ７００ アカウント分析処理、Ｓ７２０ 定常状態モデル生成処理、Ｓ７４０ 異常有無判定処理、Ｓ７５０ 関連アカウント特定処理、Ｓ７６０ 定常状態モデル更新処理、Ｓ１４００ 監視対象アカウント決定処理

Claims (15)

1. 情報処理装置を用いて構成され、
   ＳＮＳサイトから随時取得される投稿情報を蓄積して管理する投稿情報データベースと、
   前記投稿情報に基づき、監視対象アカウントの投稿情報の定常状態を学習した機械学習モデルである定常状態モデルを生成する定常状態学習部と、
   新たに取得された前記投稿情報が異常な内容を含む異常投稿であるか否かを前記定常状態モデルを用いて判定する異常投稿判定部と、
   前記異常投稿に基づき、前記投稿情報データベースに蓄積されている前記投稿情報の検索に用いるクエリを生成するクエリ生成部と、
   前記クエリを前記投稿情報データベースに適用することにより検索される前記投稿情報を投稿したアカウントを、前記監視対象アカウントの使用者と関連する候補アカウントとして特定する類似投稿検索部と、
   を備える、アカウント分析システム。
2. 請求項１に記載のアカウント分析システムであって、
   前記候補アカウントから、前記投稿情報データベースから取得される前記監視対象アカウントの投稿情報の投稿日時と同じ日時に投稿されている、前記クエリにより検索された投稿情報のアカウントを除外して得られるアカウントを、前記監視対象アカウントの使用者が使用する他のアカウントである関連アカウントとして特定するフィルタ処理部、
   を更に備える、アカウント分析システム。
3. 請求項１に記載のアカウント分析システムであって、
   前記異常投稿判定部が、新たに取得された前記投稿情報が前記異常投稿であると判定した場合に、前記異常投稿を検知した旨を示す情報を出力する通知部、
   を更に備える、アカウント分析システム。
4. 請求項２に記載のアカウント分析システムであって、
   前記関連アカウントに関する情報を出力する結果通知部、
   を更に備える、アカウント分析システム。
5. 請求項１に記載のアカウント分析システムであって、
   前記監視対象アカウントを受け付けるユーザインタフェースを提供する管理部、
   を更に備える、アカウント分析システム。
6. 請求項１に記載のアカウント分析システムであって、
   前記投稿情報データベースに蓄積されている前記投稿情報に基づき、前記投稿情報のアカウントの特徴を示す情報であるアカウント情報を生成するアカウント情報生成部と、
   前記アカウント情報を管理するアカウント情報データベースと、
   前記監視対象アカウントの入力を受け付ける監視対象アカウント受付部と、
   受け付けた前記監視対象アカウントの前記アカウント情報に類似するアカウント情報のアカウントである類似アカウントを前記アカウント情報データベースから取得し、取得した前記類似アカウントを前記監視対象アカウントに追加する監視対象アカウント決定部と、
   を更に備える、アカウント分析システム。
7. 請求項６に記載のアカウント分析システムであって、
   前記監視対象アカウントを受け付けるとともに、受け付けた前記監視対象アカウントに対応する前記類似アカウントを提示するユーザインタフェースを提供する、
   アカウント分析システム。
8. 請求項１に記載のアカウント分析システムであって、
   前記ＳＮＳサイトにアクセスして前記投稿情報を収集するクローラ部、
   を更に備える、アカウント分析システム。
9. 請求項１に記載のアカウント分析システムであって、
   前記定常状態モデルは、オートエンコーダを用いた時系列データの異常検知の仕組みにより生成される、
   アカウント分析システム。
10. 情報処理装置が、
    ＳＮＳサイトから随時取得される投稿情報を投稿情報データベースに蓄積して管理するステップと、
    前記投稿情報に基づき、監視対象アカウントの投稿情報の定常状態を学習した機械学習モデルである定常状態モデルを生成するステップと、
    新たに取得された前記投稿情報が異常な内容を含む異常投稿であるか否かを前記定常状態モデルを用いて判定するステップと、
    前記異常投稿に基づき、前記投稿情報データベースに蓄積されている前記投稿情報の検索に用いるクエリを生成するステップと、
    前記クエリを前記投稿情報データベースに適用することにより検索される前記投稿情報を投稿したアカウントを、前記監視対象アカウントの使用者と関連する候補アカウントとして特定するステップと、
    を実行する、アカウント分析方法。
11. 請求項１０に記載のアカウント分析方法であって、
    前記情報処理装置が、前記候補アカウントから、前記投稿情報データベースから取得される前記監視対象アカウントの投稿情報の投稿日時と同じ日時に投稿されている、前記クエリにより検索された投稿情報のアカウントを除外して得られるアカウントを、前記監視対象アカウントの使用者が関与する他のアカウントである関連アカウントとして特定するステップ、
    を更に実行する、アカウント分析方法。
12. 請求項１０に記載のアカウント分析方法であって、
    前記情報処理装置が、新たに取得された前記投稿情報が前記異常投稿であると判定した場合に、前記異常投稿を検知した旨を示す情報を出力するステップ、 を更に実行する、アカウント分析方法。
13. 請求項１１に記載のアカウント分析方法であって、
    前記情報処理装置が、前記関連アカウントに関する情報を出力するステップ、を更に実行する、アカウント分析方法。
14. 請求項１０に記載のアカウント分析方法であって、
    前記情報処理装置が、前記監視対象アカウントを受け付けるユーザインタフェースを提供するステップ
    を更に実行する、アカウント分析方法。
15. 請求項１０に記載のアカウント分析方法であって、
    前記情報処理装置が、
    前記投稿情報データベースに蓄積されている前記投稿情報に基づき、前記投稿情報のア
    カウントの特徴を示す情報であるアカウント情報を生成するステップと、
    前記アカウント情報をアカウント情報データベースに管理するステップと、
    前記監視対象アカウントの入力を受け付けるステップと、
    受け付けた前記監視対象アカウントの前記アカウント情報に類似するアカウント情報のアカウントである類似アカウントを前記アカウント情報データベースから取得し、取得した前記類似アカウントを前記監視対象アカウントに追加するステップと、
    を更に実行する、アカウント分析方法。

Images