JP2006236264A - コミュニケーション管理装置 - Google Patents

Abstract

【課題】 本発明の目的は、コミュニケーション相手に応じて、匿名性を制御することができるコミュニケーション管理装置を提供することである。
【解決手段】 第１の端末から投稿され、前記第１の端末に関する情報を含むメッセージを受信する受信手段（２０１）と、前記第１の端末とは異なる第２の端末から、前記受信したメッセージの閲覧要求を受付ける受付手段（２１４）と、前記第１の端末と前記第２の端末との投稿及び返信の履歴を記録する記録手段（２０６）と、前記投稿及び返信の履歴に応じて、前記受信したメッセージのうち少なくとも前記第１の端末に関する情報を加工する加工手段（２０９）と、前記加工手段によって加工された結果を前記第２の端末に送信する送信手段（２１４）とを備えるコミュニケーション管理装置。
【選択図】 図２

Description

本発明は、ネットワークを利用したコミュニケーション管理装置に関し、特に、匿名投稿の気軽さを維持したまま、コミュニケーションを円滑にするコミュニケーション管理装置に関する。

従来から、ネットワーク上で効率よく情報交換、情報共有する手段として、たとえばメーリングリストや電子掲示板(Bulletin Board System; BBS)、ネットニュース(NetNews)を利用したコミュニケーションが行われている。これらのコミュニケーション管理装置や管理システムを投稿形態から分類すると、大きく分けて２種類ある。一方は特に身元を明確にしない、匿名によるメッセージ投稿を受け付けるもの、他方は記名を行うものである。決まったメールアドレスやアカウント名といった、基本的に変更しにくい投稿者情報を付加するものは、ここでは後者とする。また、匿名という言葉の定義を、参加ユーザに対して匿名であることとし、システムに対して匿名であることは要求しない。すなわち、システムは発信元のメールアドレス等を記録しているが、この記録したメールアドレス等を参加ユーザには開示しない。

匿名による投稿を許可するシステムは、投稿者の心理的な障壁の低下により、多くの発言が期待でき、中にはこのような場でしか発生し得ない情報提供や情報交換が行われることがある。

もちろん、発言内容や議論の質の低下、いらずら的書き込みが発生するおそれは高い。特に「荒らし」と呼ばれる、無意味、無関係、勘違いした書き込みを一人で、もしくは共謀する仲間と繰り返す行為は大きな問題である。さらに、別人にも関わらず、「あの投稿はオレが書いたんだけど……」と詐称し、他人が流した情報をねじ曲げることさえ発生する。

また、当初は匿名の利便性にひかれて情報交換したものの、経緯によっては匿名性が邪魔になることがある。例えば、価値ある情報を提供した際に相手に自分を覚えておいてもらいたい、価値ある情報が提供された場合に相手を覚えておきたい、または議論の果てに相手を認め合ったのでお互いに自分の識別方法を教え合いたい、といったことができず、新たな人間関係構築の機会の損失を招きがちである。

一方、記名による投稿を要求するシステムは、書き込み内容に対して責任感が発生する分、しっかりとした議論や発言が行われることが期待される。しかし、全体的に発言に対して臆病になり、例えば初歩的な質問しにくいといった問題がある。また、不特定多数の人間に、自分の発言を一方的に公開することには抵抗を覚える人が多い。話し合いが終わるまで内容そのものを伏せておきたい場合や、進行中の話題に関して秘密裏に相談したい場合もある。

このような２種類の投稿形態に関し、様々なシステムがその弱点を克服しようとしてきた。

匿名による投稿に重きをおいたシステムの例は下記のようなものがある。ここで、匿名による投稿とは、管理サーバ上に投稿者のIPアドレス等の個人識別に使いうる何らかの情報が記録されている、いないに関わらず、不特定多数の人が見る掲示板には、個人識別情報を掲載しないものをいう。

匿名コミュニケーション場として名高い２ちゃんねる(http://www.2ch.net)では、投稿者の発信情報（IP(Internet Protocol)アドレス等）から固定長の英数字によるID(Identification)を計算し、各投稿ごとに付与している。通常の議論場（２ちゃんねる用語では「板」と呼ぶ）では隠蔽しているが、荒れやすいテーマの議論場では投稿内容とともにIDを開示することで、同一人物かどうかの判定ができるようにしている。このことで、同一人物による荒らし行為を判定することができる。しかし、IDの計算の元になる発信情報は、ネットワークへの再接続などの方法で容易に変更できるため、完全な防止には至っていない。また、投稿者詐称行為に対抗するため、fusianasanと呼ばれる発信情報の自己開示や、トリップと呼ばれるパスワードによるIDの生成＆提示機構により、本人が本人と主張できる仕組みも備える。事前に詐称されることがわかっている場合は有効に機能する。現実に即したシンプルな仕組みという点で高く評価できるが、このようなアプローチは匿名投稿によるメリットを薄めがちである。

NetNewsやメーリングリストへの投稿を管理するクライアントビューアのメジャーな機能として、特定人物無視、および特定キーワード含有メッセージ無視機能がある。これは、明らかに荒らし行為である内容のメッセージを非表示または受け取り拒否するものである。人物の特定はメールアドレスやIPアドレスといった発信者情報によって推定する。いちいちキーワードや発信者情報を登録して行かなければならないため、著名なユーザやキーワードについては、ボランティアによるデータベースの公開が行われているケースもある。

特許文献１では、システムのみが知っているユーザのプロファイル情報を用いることで、参加できる議論場を絞り込んで提供している。ユーザの趣味や課題認識が議論場内の話題と一致することで、荒らし行為を自然に避けることが期待できる。

特許文献２及び特許文献３では、ユーザが他のユーザを評価することができ、評価に応じて特典や制裁を課すことができる。このような仕組みにより荒らし行為を防止できるとしている。この発明による「ユーザ」は仮想空間上では一意に特定できるとされているため、そのサービス内では記名による参加に等しい。

これらの特許文献で述べられている方法は、今日ヤフーオークション(http://auction.yahoo.co.jp)等に代表される、ネットオークションでの基本的な仕組みであるユーザレイティングと同じものだと考えることができる。これらのサービスから得られる知見として、負の評価が与えられたユーザは、適時別人として再登録し、その評価をクリアできてしまうという問題点がある。このような問題に対して、正の評価も与えることで、その登録情報に未練を与える方法も用いられているが、多くの場合、荒らし用のユーザとそうではないユーザの情報は使い分けられることが多いため、大きな成果にはつながりにくい。また、身内同士がお互いに正の評価を多く与える行為までは防止できない。

一方、記名による投稿に重きを置いたシステムの例には、下記のようなものがある。

基本的には、コミュニケーションを取る相手を、自分が知っている相手か、同じ興味を持つ者同士に限定をかけ、その範囲にのみ情報を公開する、というパターンであり、どのように範囲を決めるか、という点と、どのようにして条件に合致する相手に通知するか、という部分に工夫が見られる。

Nifty(http://www.nifty.com)やBiglobe(http://www.biglobe.ne.jp)をはじめとするコミュニティサイトやメーリングリストでは、参加者限定のクローズドコミュニティは一般的である。これは参加者が招くべき相手を完全に把握できる状況では効果的である。

Mixi(http://www.mixi.jp)やOrkut(http://www.orkut.com)に代表されるソーシャルネットワーク(SN)では、「Ａさんの友人には公開」というように、人間関係に基づく参加条件を課すことができる。

特許文献４では、問題領域ごとにユーザデータベースを持たせることで、ある問題を議論したい場合に、好ましい相手にのみ参加募集をかけることができる。
特開２００３−１５７２７９号公報（第５頁、図１） 特開２００３−２８１１４２号公報（第７頁、図１） 特開２００４−６２８６５号公報（第１５頁、図５） 特開２００２−２１５９４２号公報（第４頁、図２）

しかし、従来のネットワークを利用したコミュニケーション管理システムでは、コミュニケーション相手に応じて、匿名性を制御することはできなかった。

本発明の目的は、コミュニケーション相手に応じて、匿名性を制御することができるコミュニケーション管理装置を提供することである。

第１の発明は、第１の端末から投稿され、前記第１の端末に関する情報を含むメッセージを受信する受信手段と、前記第１の端末とは異なる第２の端末から、前記受信したメッセージの閲覧要求を受付ける受付手段と、前記第１の端末と前記第２の端末との投稿及び返信の履歴を記録する記録手段と、前記投稿及び返信の履歴に応じて、前記受信したメッセージのうち少なくとも前記第１の端末に関する情報を加工する加工手段と、前記加工手段によって加工された結果を前記第２の端末に送信する送信手段とを備えるコミュニケーション管理装置である。

第２の発明は、前記第１の端末が前記メッセージを投稿する時に、前記投稿及び返信の履歴に基づいて前記第２の端末に対する公開方法を選択する選択手段をさらに備えることを特徴とする第１の発明記載のコミュニケーション管理装置である。

第３の発明は、前記第１の端末と前記第２の端末とが親密な関係であるかを前記投稿及び返信の履歴に応じて推定する推定手段をさらに備え、前記加工手段は、前記推定手段によって推定された第１の端末と第２の端末との親密な関係に応じて、前記受信したコミュニケーション情報を加工することを特徴とする第１の発明記載のコミュニケーション管理装置である。

第４の発明は、前記投稿及び返信の履歴が、前記第１の端末と第２の端末のメッセージの返信関係に基づくものであることを特徴とする第３の発明記載のコミュニケーション管理装置である。

第５の発明は、前記投稿及び返信の履歴が、前記第１の端末と第２の端末とのメッセージの表現に基づくものであることを特徴とする第３の発明記載のコミュニケーション管理装置である。

第６の発明は、前記推定手段が前記第１の端末と第２の端末との親密な関係を一定値以下と推定し、前記加工手段が前記第２の端末に対して前記第１の端末に関する情報を匿名にしていた場合であって、前記推定手段が前記第１の端末と第２の端末との親密な関係を一定値以上と推定し直すと、前記加工手段は前記第２の端末に対して前記第１の端末に関する情報の匿名を解除することを特徴とする第３の発明記載のコミュニケーション管理装置である。

第７の発明は、前記推定手段が前記第１の端末が前記第２の端末にとって一定値以下の親密な関係であると推定すると、前記加工手段は前記第１の端末からの投稿を前記第２の端末に対して提示しないように加工することを特徴とする第３の発明記載のコミュニケーション管理装置である。

第８の発明は、前記推定手段が、前記第１の端末と第２の端末との親密な関係を一定値以下と推定し、さらに、前記第２の端末と、前記第１の端末の投稿に対して閲覧要求を行う第３の端末との親密な関係が一定値以上と推定した場合、前記第１の端末と第３の端末との親密な関係も一定値以下と推定することを特徴とする第３の発明記載のコミュニケーション管理装置である。

本発明によれば、コミュニケーション相手に応じて、匿名性を制御することができるコミュニケーション管理装置を提供することができる。

以下、本発明の実施の形態について図面を参照しながら説明する。

図１は、本発明の実施形態に係るコミュニケーション管理システムの適用例を示す図である。本実施形態では、ユーザはWebブラウザやメーラ、インスタントメッセージツールといった端末１０１を用い、インターネットやイントラネットといったネットワークを介して本システムにアクセスする。本システム１００はメッセージ送受信装置１０２と、メッセージ管理装置１０３で構成され、お互いにメッセージを交換しあう。この二つは基本的に同一のホストコンピュータ上に置かれるが、メッセージ送受信装置１０２は既存のメールサーバで置き換えが可能であるため、複数のホスト上に分散しておかれてもよい。ユーザはメッセージ送受信装置１０２から送られたメッセージを受け取ることで、メッセージ管理装置１０３に蓄積された情報を所定の形式で参照することができる。

以下、メッセージ送受信装置１０２およびメッセージ管理装置１０３の行う処理について、本実施形態の詳細を説明する。図２は、同一のホストコンピュータ上にメッセージ送受信装置１０２およびメッセージ管理装置１０３が置かれた場合の、コミュニケーション管理システムの概略構成図である。

メッセージ受信部２０１はユーザからの発言（以後、メッセージと呼ぶ）を受け取り、アクセス制御部２０２を介し、メッセージ解析部２０３へ渡す。メッセージの種類は様々であるが、メールアプリケーションの場合は電子メールによって運ばれてくる情報であるとする。電子掲示板(BBS)のようなWebアプリケーションやインターネットメッセンジャー(IM)も、電子メールの場合と類似したテキストとして考えることができる。また、VoIPを利用した音声付きメール等の場合は、既存の音声からテキストへの変換ツールを通して、テキストとして情報にアクセスできるものとする。

アクセス制御部２０２は、ユーザ情報記録部２０５の情報を用い、メッセージの投稿元がシステムに登録されているどのユーザかを判定し、その情報をメッセージと一緒にメッセージ解析部２０３に送る。つまり、システムはメッセージ投稿者をあらかじめ知っていることが前提である。運用ポリシーのバリエーションとしては、未登録の場合は新規ユーザとしてユーザ情報記録部２０５に自動登録してしまう、という形態も考えられる。ここで重要なのは、システムはユーザを特定しうるという点であり、システムに対して投稿者は匿名ではない。少なくとも、過去に投稿されたメッセージと同じ投稿者であれば、システムは同一のユーザとして扱うことができるとする。

メッセージ解析部２０３は、メッセージの本文およびヘッダから、メッセージに関係するユーザもしくはユーザ群と、それらに対してどのような公開を望んでいるかを解析し、その結果をメッセージ記録部２０４およびユーザ関係記録部２０６に記録する。メッセージ解析方法の具体例は後述する。

メッセージ提示部２１４は、ユーザから投稿されたメッセージの閲覧要求を受け付け、要求されたメッセージの取得要求をアクセス制御部２０２を介して提示内容加工部２０９へ送る。Webアプリケーションの場合、Webブラウザからの要求を受け付け、その結果をHTML等のフォーマットで返す部分に相当する。メールアプリケーションの場合、メッセージ受信部２０１に投稿されるメッセージを監視し、新規メッセージが投稿されると、そのメッセージの取得要求を宛先ユーザごとに行い、取得結果をメールとして宛先ユーザへ向かって送信する、という形態も考えられる。この入出力スタイルはメーリングリストサーバもしくはドライバと呼ばれるものと同一である。

提示内容加工部２０９は、リクエストのあったメッセージもしくはメッセージ群に対し、参照形式判定部２０７に対して、閲覧者に対して投稿者の希望する公開方法の希望を問い合わせ、同時に、投稿者と閲覧者の関係をユーザ関係記録部２０６に対して問い合わせる。

この結果得られる情報としては、例えば、「匿名希望：閲覧者と投稿者の関係性は薄い」、「実名希望：投稿者は閲覧者とその関係者から評価が低い」、「不可視：閲覧者と投稿者の関係はない」等がある。

提示内容加工部２０９はこれらの情報を用い、双方にとって期待される提示内容、たとえば、投稿者名を匿名表示にしたり、メッセージそのものが存在しないかのような加工をしたり、評価が高く、すでに実名が開示されている場合は匿名指定であっても実名を出す、といった処理を行い、メッセージ提示部２１４に結果を返す。

ユーザ関係提示部２１１は、ユーザ関係取得部２１２より閲覧者と指定のメッセージの投稿者との関係性を取得し、閲覧者に提示する。関係性としてどのようなものが提示できるかは、ユーザ関係判定部２０８の仕様により、例えば、関わったことがあるか、あるとすればどれくらいか、その評価、実名開示経験の有無といったものになる。また、ユーザ関係編集部２１３に対して、指定のメッセージの投稿者に対して実名開示許可や評価の補正値付与を行うことができる。

図３は、メッセージ受信部２０１が受け取り、メッセージ記録部２０４に記録されるメッセージの例である。この図では電子メールの例を示した。メッセージ例３０１は話題の発端となるメッセージの例であり、メッセージ例３０２はメッセージ例３０１に対する返信を表している。一般的にメッセージはヘッダ３０３および本文３０４によって構成される。ヘッダ３０３には主に投稿者（From:）、投稿先（To:）、同時投稿先（Cc:)、投稿日時（Date:）、表題（Subject:）、メッセージ識別子（Message-ID:）、返信対象メッセージ（In-Reply-To:）といった属性が含まれる。

電子メール以外のメッセージ例としては、前述のインスタントメッセンジャー(IM)や電子掲示板(BBS)への投稿単位、WebLog、Blog、Web日記と呼ばれる個人用日記サイトの記事単位等がある。

図４は、メッセージ解析部２０３の動作フローの概略を表す図である。メッセージ解析部２０３はメッセージを受け取ると（Ｓ４０１）、投稿者が指定する公開方法を解析し（Ｓ４０２）、メッセージそのものとともに解析情報をメッセージ記録部２０４に記録する（Ｓ４０３）。

公開方法の解析は、本質的にはシステムポリシーとして事前に決めておくべきものであり、特に知的な処理を必要としない。誰が、誰に、どういう形式で公開するか、という一組を指定させるポリシー例のバリエーションを下記に列挙する。

以下の例は、複数のユーザが参加しているメーリングリストへの投稿を想定している。

* デフォルト固定
(例) このユーザから送られるメールはすべて、匿名扱いになる
* デフォルトは実名公開、一部のユーザに対しては匿名にしたい文字列をつける
(例) このユーザから送られるメールは実名公開されるが、宛先アドレスの末尾に-anonymousをつけることで、匿名扱いになる。たとえば、mysql-developer@ml.company.co.jp宛にメッセージを投稿する際に匿名にしたければ、mysql-developer-anonymous@ml.company.co.jpというアドレスを用いる。

* デフォルトは実名公開だが、一部の相手には匿名で送りたい
(例) 本文冒頭に、anonymous:という接頭語の後に匿名にしたい相手のアドレスを列挙する。この部分はメッセージ本文とは扱われず、メッセージ記録部２０４に送られる前にカットされる。

* デフォルトは実名公開だが、一部の相手以外には当面不可視にしたい
(例) 本文冒頭に、invisible:という接頭語の後に不可視にしたい相手のアドレスを列挙する。また、visible:と書いた後に可視にしたい相手のアドレスを列挙する。参加者全員を表すエイリアス名allを使えるものとする。

メッセージ記録部２０４には、誰によって投稿された、どのメッセージが、誰に対して、どのような形式で公開するか、という情報をメッセージそのものと併せて保存する。

また、あるメッセージに返信したメッセージについて、返信元のメッセージの指定を引き継ぐように指定できてもよい。つまり、匿名投稿にはデフォルトで匿名投稿で返す、一部の人間に対して不可視のメッセージへの返信は、それらの人間に対して不可視になる、というようにするものである。このようにすることで、返信元メッセージの投稿者が望む議論スタイルを雑多な手続きやミスなく運用できる。

次に、そのメッセージの他のユーザとの関係度を計算する（Ｓ４０４）。つまり、そのメッセージはどのユーザに対して関係があるかを所定の方法で測定する。シンプルな方法としては、メッセージの返信関係を用いて関係性を定義する。たとえば、ユーザＡの投稿したメッセージにユーザＢが返信した場合、ユーザＢのメッセージはユーザＡとユーザＢの関係を＋１し、さらにユーザＡの投稿がユーザＣの投稿の返信だった場合、ユーザＡとユーザＣの関係を＋０．５する、といった方法が考えられる。さらには、メッセージ本文中の表現による関係性も考えられ、たとえば、メッセージ本文中に名前やそれに類する呼び名が記載されているユーザに対しては＋０．３する、といったこともできる。

ユーザとユーザの関係度は、最小構成としてはシステム内で一つあればよいが、様々なジャンルの話題を扱うようなシステムで、ジャンルＡでの交流がジャンルＢにも関係するようなことが好ましくないような場合、各ジャンルや投稿先アドレスごとに関係度を別々に計算し、メッセージ記録部２０４にて保持してもよい。

次に、本文内の正負評価を解析する（Ｓ４０５）。つまり、処理中のメッセージを文字列解析し、丁寧な内容や感謝表現などを含むポジティブな内容なのか、罵倒表現などが含まれるネガティブな内容なのかを判定する。文中から感情表現を抽出する既存技術はいくつか存在するため、それらを用いて計算してもよい。最小構成としては、ユーザによる編集にまかせて、すべて「不明（つまり±ゼロ）」としてもよい。

この解析結果と、Ｓ４０４によって計算された関係度から、どのユーザとどのユーザが関係があるか、またその関係はポジティブなものか、それともネガティブなものか、を知ることができる。最後に、以上の解析結果をユーザ関係記録部２０６に記録する（Ｓ４０６）。これらの解析結果は、最小構成としてはシステム内で一つあればよいが、様々なジャンルの話題を扱うようなシステムで、ジャンルＡでの交流がジャンルＢにも関係するようなことが好ましくないような場合（例えば、意見やスタンスがその他の分野と独立性が高いような話題である、スポーツのひいきチームに関する話題や、政治の話題、宗教の話題等）、各ジャンルや投稿先アドレスごとに関係度と正負評価を別々に記録してもよい。

図５は、提示内容加工部２０９によって行われる加工処理の概略フローを表す図である。提示内容加工部２０９は、メッセージ提示部２１４がアクセス制御部２０２を介してメッセージ取得を要求することで動く（Ｓ５０１）。メッセージ提示部２１４から送られてくる情報は、提示ユーザ情報U_view、取得希望メッセージ群M_1,M_2,...,M_nである。提示ユーザ情報とメッセージ群の情報を参照形式判定部２０７に渡し、それぞれのメッセージ情報と、それらが提示ユーザに対してどのように表示されることを希望しているか、という情報を取得する。つまり、可視／不可視、匿名／実名公開といったものである（Ｓ５０２）。

次に、投稿者群と閲覧者の関係度をユーザ関係判定部から取得する。ユーザ関係取得部からは、それぞれの投稿者に対する閲覧者の関係度および正負評価と、実名開示許可が出ているかどうかのフラグが返される（Ｓ５０３）。ここで、投稿者と閲覧者の正負評価を、単純にその２者間の正負評価とするだけではなく、例えば閲覧者と関係度が高い他のユーザと、投稿者の関係度および正負評価を加味して定義することも考えられる。最も単純には、下記の式で求めることができる。

EF_a_b = E_a_b + Σ(k,1,n) R_a_k * E_a_k
n ... b以外の各ユーザ
EF_a_b ... 投稿者aと閲覧者bの最終的な正負評価
R_a_k ... 投稿者aと閲覧者kの関係度
E_a_k ... 投稿者aと閲覧者kの正負評価
Σ(k,1,n)： k=1からk=nまでの、それぞれのkに対する計算結果（この式ではR_a_k * E_a_k）を足し合わせることを意味するものとする。

この他にも、投稿者と関係度が深い他のユーザと、閲覧者の関係度および正負評価を加味した定義や、明示的に他の閲覧者に対して負の評価を耐えるような手段を各閲覧者に与え、その値を加味して決定するような定義を行っても良い。

これらの情報を元に、メッセージ内容の加工処理内容を決定し、処理を行う（Ｓ５０４）。

図６は、Ｓ５０４で行われる加工処理の概略フローを表す図である。投稿者が閲覧者にたいして不可視を希望している場合（Ｓ６０１）、不可視加工処理を行う（Ｓ６０２）。具体的には、閲覧内容からの削除に当たる。さらには、一般的なメーリングリストでよく見られる通し番号を加工し、そのメッセージに振られている番号を詰める処理等を行う。これらの処理をどのレベルまで行うかで、「あるはずのものが見えない」ではなく「存在しない」という錯覚を閲覧者に与えることができる。通し番号を詰める処理は、たとえば不可視ユーザ用専用の通し番号を別途用意し、管理する等の実現方法が考えられる。

また、ユーザ間の関係度が高いにもかかわらず、正否評価の値が低い場合、あえて不可視加工処理を行う、といった処理を行うことで、閲覧ユーザは不快なユーザの発言を無視することができる（Ｓ６０３）。オプション機能としてユーザに選択させることで、より快適な閲覧やコミュニケーションが可能になると期待される。

次に、投稿者が閲覧者に対して匿名を希望している場合（Ｓ６０４）、匿名加工処理を行う（Ｓ６０５）。具体的には、投稿者名、投稿アドレスを「名無し」、「anonymous」、「匿名希望」といった文字列に置き換える。さらには、メッセージ識別子(Message-ID)等のヘッダ情報内に含まれることが多い、個人特定用の文字列をすべてダミー文字列と置換する。この際、もし投稿者が閲覧者に対して実名公開を許可していた場合、匿名加工処理をスキップすることができる（Ｓ６０６）。

実名公開フラグは最小構成としてはシステム内でユーザとユーザのペアに対して一つあればよいが、様々なジャンルの話題を扱うようなシステムで、ジャンルＡでは公開を出したが、ジャンルBでは匿名のままにしておきたい、といった場合が想定される場合、各ジャンルや投稿先アドレスごとに匿名公開フラグを保持してもよい。また、この議論限定で公開する、といったことが可能なバリエーションももちろん考えられるし、シーンによっては非常に有効だろう。匿名公開フラグは前述の通り、ユーザ関係記録部２０６にて保持される。

図７は、提示内容加工部２０９によって行われた各メッセージの公開情報判定結果（７０１）と、その内容をメッセージ提示部２１４に提示される内容（７０２）の一例を示す図である。なお、閲覧ユーザはWebブラウザ等のグラフィカルインターフェースを通して閲覧を行っていることを想定した。この例は２ペイン構成のビューアであり、上部に閲覧要求メッセージを返信関係をツリー上に並べた一覧ビュー（７０８）、下部に上部のうちの一つのメッセージの本文を表示する内容ビュー（７０９）を備える。一覧ビュー中の横矢印７１１は、内容ビューで表示されているメッセージを指している。内容ビューの下部にある＋ボタン、−ボタン（７１２）は、閲覧ユーザが明示的にこの投稿ユーザを評価するためのものであり、選択すると、ユーザ間関係編集部２１３に対して、このメッセージの投稿者に対する正否評価の補正値として通知する。

メッセージｍ１、ｍ６は匿名表示、メッセージｍ３、ｍ４、ｍ５はユーザとの正否評価が低いため不可視（７０７）、メッセージｍ２はこの閲覧者に対しては実名公開が許可されており、メッセージｍ７はすべての閲覧者に対して実名公開を許可している。この場合、ビューア７０９の一覧ビュー７０８には、匿名のものは投稿者が「名無しさん」（７０３，７０５）、閲覧者に対して実名公開されているものは「ＸＸＸさん（匿名）」（７０４）として表示される。なお、不可視指定のメッセージは表示されない（７０７）。この例では、閲覧者用に通し番号がふり直されている（７１０）。

より徹底するには、本文中の文面に対しても、匿名化を行うフィルタを適用するといったことが考えられる。通し番号についても、閲覧ユーザによって通し番号が異なることで、相互のコミュニケーションが取りにくくなる可能性がある。閲覧ユーザによる通し番号の置換処理などが支援機能として必要になるだろう。技術的には一般的な方法で十分に可能なので詳細は省略する。もっとも簡単なのは、ほとんどの議論参加ユーザにとって不可視になるラインで処理を行うことである。一般的に、嫌われ者は誰に対しても嫌われるため、十分な効果を上げる方法だといえる。

図８は、ユーザ関係提示画面２１１の一例を示す図である。この画面８０１は、ユーザ関係編集部２１３に対して指示を送るためのものであり、この画面から送られた指示は、ユーザ関係編集部２１３を介してユーザ関係記憶部２０６の内容に反映される。

画面には、実名公開されているユーザ（８０１）、実名公開してはいないが、これまで良好なやりとりをしてきた匿名相手（８０２）がリストアップされている。実名公開している相手には、公開取り消しボタン８０７を選択することで、ユーザ関係編集部２１３に対して、実名公開フラグを取り除くことを指示することができる。また、これまで良好な関係を持ってきた匿名相手に対して、公開ボタン８０８を選択すること、実名公開フラグをONにすることができる。「良好な関係」が何を意味するかを決めるのが実名公開推奨基準８０４における設定である。

良好な関係は、基本的にはユーザ関係判定部２０８によって判定されるが、ここではその値に対して補正をかけることができる。この画面の例では、投稿→返信を行った回数で「良好な関係」としたり、メッセージ提示画面７０２における＋ボタン７１２を押した回数を「良好な関係」として扱うことが指定できる。わざわざユーザ間関係表示画面で公開指示を送るのが面倒な場合は、「自動的に公開」を選択することで、自動的に公開が行われる。

この例では実名公開は原則として双方が公開に同意した場合のみ、ということで、相手から公開許可がでていた場合は「相手が公開している」という情報が提示される。

不可視制御８０５では、主に好ましくない相手の投稿を無視するための条件を設定する。この画面の例では、メッセージ提示画面における−ボタン７１２を押した回数で「好ましくない相手」としたり、ユーザが実名公開しているユーザの半数がマイナス評価をしている場合に「好ましくない相手」とするといった方法が選択できる。これは、実名公開している相手を信頼し、相手の判断を自分も利用する、というものである。これにより、信頼できる集団で共同して不要な投稿を除去することができる。この例でいう「半数」は、もちろん一人から全員までどれを選んでもよい。低くすると信頼できない、もしくは判断基準が自分と異なるユーザが紛れ込んでしまった場合に、見るべきメッセージが見えなくなるし、高くすると共同除去による労力の削減が大して見込めなくなる。

これらの指定にはオプションも考えられる（８０６）。ここでの例は、不可視対象のメッセージに対する返信も不可視にする、不可視対象のユーザにプラス評価を与えているユーザも不可視にする、というものである。つまり、評価が低い相手につきあっている相手や、評価が低い相手を、逆に高く評価している相手も、自分にとっては無視してもかまわない対象である、という意志表示をシステムに教えることができるものである。

以上で説明したように、本実施形態によれば、任意の相手と任意のタイミングで匿名コミュニケーションが可能であり、また、関係が深まるにつれ、お互いにフェアな条件で実名開示を行うことができる。また、匿名性を利用した荒らし行為を、本人達に気づかれにくい方法で排除することができる。匿名コミュニケーションのもつ敷居の低さを最大限に利用できるようになることで、従来では発生しにくかったコミュニティの形成を促すことができる。その結果、究極的には日本人の特徴である内向的な性格によるデメリットに打ち勝つことができる。

上述した実施の形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の趣旨を逸脱しない範囲であれば、適宜組合わせ及び変更することができることはいうまでもない。

本発明の実施形態に係るコミュニケーション管理システムの適用例を示す図。 コミュニケーション管理システム１００の概略構成図。 メッセージ記録部２０４に記録される受信メッセージの例を示す図。 メッセージ解析部２０３の動作フローの概略を表す図。 提示内容加工部２０９の加工処理フローの概略を表す図。 Ｓ５０４で行われる加工処理の概略フローを表す図。 提示内容加工部２０９によって行われた各メッセージの公開情報判定結果と、その内容をメッセージ提示部２１４に提示される内容の一例を示す図。 ユーザ関係提示画面２１１の一例を示す図。

符号の説明

１００ コミュニケーション管理システム
１０１ ユーザ端末
１０２ メッセージ送受信装置
１０３ メッセージ管理装置
２０１ メッセージ受信部
２０２ アクセス制御部
２０３ メッセージ解析部
２０４ メッセージ記録部
２０５ ユーザ情報記録部
２０６ ユーザ関係記録部
２０７ 参照形式判定部
２０８ ユーザ関係判定部
２０９ 提示内容加工部
２１１ ユーザ関係提示部
２１２ ユーザ関係取得部
２１３ ユーザ関係編集部
２１４ メッセージ提示部

Claims (8)

1. 第１の端末から投稿され、前記第１の端末に関する情報を含むメッセージを受信する受信手段と、
   前記第１の端末とは異なる第２の端末から、前記受信したメッセージの閲覧要求を受付ける受付手段と、
   前記第１の端末と前記第２の端末との投稿及び返信の履歴を記録する記録手段と、
   前記投稿及び返信の履歴に応じて、前記受信したメッセージのうち少なくとも前記第１の端末に関する情報を加工する加工手段と、
   前記加工手段によって加工された結果を前記第２の端末に送信する送信手段と
   を備えるコミュニケーション管理装置。
2. 前記第１の端末が前記メッセージを投稿する時に、前記投稿及び返信の履歴に基づいて前記第２の端末に対する公開方法を選択する選択手段をさらに備えることを特徴とする請求項１記載のコミュニケーション管理装置。
3. 前記第１の端末と前記第２の端末とが親密な関係であるかを前記投稿及び返信の履歴に応じて推定する推定手段をさらに備え、
   前記加工手段は、前記推定手段によって推定された第１の端末と第２の端末との親密な関係に応じて、前記受信したコミュニケーション情報を加工することを特徴とする請求項１記載のコミュニケーション管理装置。
4. 前記投稿及び返信の履歴が、前記第１の端末と第２の端末のメッセージの返信関係に基づくものであることを特徴とする請求項３記載のコミュニケーション管理装置。
5. 前記投稿及び返信の履歴が、前記第１の端末と第２の端末とのメッセージの表現に基づくものであることを特徴とする請求項３記載のコミュニケーション管理装置。
6. 前記推定手段が前記第１の端末と第２の端末との親密な関係を一定値以下と推定し、前記加工手段が前記第２の端末に対して前記第１の端末に関する情報を匿名にしていた場合であって、
   前記推定手段が前記第１の端末と第２の端末との親密な関係を一定値以上と推定し直すと、前記加工手段は前記第２の端末に対して前記第１の端末に関する情報の匿名を解除することを特徴とする請求項３記載のコミュニケーション管理装置。
7. 前記推定手段が前記第１の端末が前記第２の端末にとって一定値以下の親密な関係であると推定すると、前記加工手段は前記第１の端末からの投稿を前記第２の端末に対して提示しないように加工することを特徴とする請求項３記載のコミュニケーション管理装置。
8. 前記推定手段が、
   前記第１の端末と第２の端末との親密な関係を一定値以下と推定し、さらに、前記第２の端末と、前記第１の端末の投稿に対して閲覧要求を行う第３の端末との親密な関係が一定値以上と推定した場合、
   前記第１の端末と第３の端末との親密な関係も一定値以下と推定することを特徴とする請求項３記載のコミュニケーション管理装置。

Images