平成
18
年度
筑波大学第三学群情報学類
卒業研究論文
題目
web
ページにおける閲覧者間の繋がりを用いた
インフォーマルコミュニケーション支援
主専攻
情報科学主専攻
著者
佐藤 俊輔
指導教員 田中二郎 高橋伸 三末和男 志築文太郎
要 旨
コミュニケーションには人と人との繋がりが重要である。近年BlogやSNSなどの特にイン フォーマルコミュニケーションを支援するサービスが脚光を浴びているが、これらは「同じ 趣味を持っている」や「友達の友達」といった繋がりが根底にある。本研究では「偶然同じ Webページを見ている」という繋がりをユーザに知らせることでインフォーマルなコミュニ ケーションのきっかけを作り出し、そのきっかけを活かし円滑にコミュニケーションができ るチャットシステムを開発する。またその発展として繋がりを積極的に作り出す機能である ホットページランキングを導入した。目 次
第1章 序論 1 1.1 背景 . . . . 1 1.2 コミュニケーション支援サービス . . . . 1 1.2.1 Blog・SNSに見るきっかけとしての「繋がり」 . . . . 1 1.2.2 既存の「繋がり」の問題点と解消案 . . . . 2 1.2.3 既存のコミュニケーションツールの問題点と解消案 . . . . 2 1.3 論文の構成 . . . . 3 第2章 インフォーマルコミュニケーションを誘発させるシステムの提案 4 2.1 提案システム：Page-Chat . . . . 4 2.1.1 日常的な活動における繋がりの構築 . . . . 4 2.1.2 積極的な繋がり探索 . . . . 4 2.1.3 即時的な会話 . . . . 5 2.2 利用例 . . . . 5 2.2.1 偶発的な繋がり . . . . 5 2.2.2 積極的な働きかけ . . . . 6 第3章 Page-Chat 8 3.1 クライアントアプリケーションの説明. . . . 8 3.1.1 パネル➀：会話スペース . . . . 9 3.1.2 パネル➁：ルームリスト . . . . 9 3.1.3 パネル➂：ユーザリスト . . . . 10 3.1.4 パネル➃：ホットページランキング . . . . 10 3.2 動作例 . . . . 11 第4章 システム構成 13 4.1 全体の構成 . . . . 13 4.2 プロキシサーバの実装 . . . . 14 4.2.1 概要 . . . . 14 4.2.2 リクエストラインの解析 . . . . 15 4.2.3 ログファイル . . . . 15 4.2.4 並列処理. . . . 164.3 実装：チャットサーバ. . . . 16 4.3.1 概要 . . . . 16 4.3.2 ユーザスレッド . . . . 17 4.3.3 チャットルーム . . . . 18 4.4 実装：クライアントアプリケーション. . . . 21 第5章 考察と課題 24 第6章 関連研究 25 6.1 繋がりを支援する研究 . . . . 25 6.2 Webブラウジングに関する研究 . . . . 26 第7章 まとめと今後の展望 27 謝辞 28 参考文献 29
図 目 次
2.1 偶然同じWebページを見ている . . . . 6 2.2 人気があるページに気付く . . . . 7 3.1 PageChat実行画面 . . . . 8 3.2 ルームリスト . . . . 9 3.3 ルームリスト . . . . 10 3.4 炎レベル,左からレベル1∼レベル5 . . . . 10 3.5 STAYセルの動作例(A) . . . . 11 3.6 STAYセルの動作例(B) . . . . 11 3.7 STAYセルの動作例(C) . . . . 11 3.8 VIEWセルの動作例(D) . . . . 12 3.9 VIEWセルの動作例(E) . . . . 12 3.10 VIEWセルの動作例(F) . . . . 12 3.11 VIEWセルの動作例(G) . . . . 12 4.1 システム概観 . . . . 13 4.2 サーバとクライアントの関係. . . . 14 4.3 googleのリクエスト文 . . . . 15 4.4 リクエスト文をGETメソッドでフィルタリングしたもの . . . . 15 4.5 マルチスレッドプロキシサーバ . . . . 16 4.6 チャットサーバの概略図 . . . . 17 4.7 ユーザスレッドが受け取るコマンド一覧 . . . . 18 4.8 入室の場合 . . . . 19 4.9 入室時のやり取り . . . . 20 4.10 発言時のやり取り . . . . 20 4.11 ホットページランキング変更の工程 . . . . 21 4.12 クライアント側が受け取るコマンド一覧 . . . . 22 4.13 ホットページランキングの受信 . . . . 23 6.1 わくらわ . . . . 25 6.2 グリッドブラウジング. . . . 26 6.3 antwaveの実行画面 . . . . 26第
1
章 序論
1.1
背景
近年、Blogや趣味などを公開することで知人の和を広げていくmixi1が２０代から３０代 の世代を中心に関心を集めている。またmixiはソーシャルネットワーキングサービス(SNS) に分類される。Blog・SNSの言葉の定義と特徴は1.2.1節で述べるが、2006年3月末時点で blogの利用者数（登録者数の合計）が868万人、SNSは716万人である2。情報発信やコミュ ニティ形成を効率的に行うためのツールとして発展してきた両者だが、目的は既述の通り情 報発信とコミュニティ形成であり、その後発生するコミュニティ内でのコミュニケーション である。利用者数の増加傾向から今後もBlog・SNSなどのネットワークコミュニケーション を支援するサービスは大きい需要があると予想される。 コミュニケーションはTPOに応じて使い分けられるフォーマルなものとインフォーマルなも のがあるがBlog・SNSで行われるコミュニケーションはインフォーマルなものが多い。井戸 端会議・雑談に代表されるインフォーマルコミュニケーションは会議などフォーマルなコミュ ニケーションと比較すると，偶発的で相手も話題も不特定という特徴がある[2]。その特徴故 にインフォーマルコミュニケーションの中ではしばしば柔軟なアイディアが生まれることも あり、インフォーマルコミュニケーションは豊かなライフスタイルの形成に有益であると考 えられる。しかし現在のコミュニケーション支援サービスにはいくつかの問題点がある。そ の問題点については1.2節で述べる。本研究ではその問題点を改善したインフォーマルコミュ ニケーションを支援するシステムを提案する。1.2
コミュニケーション支援サービス
1.2.1
Blog
・SNS に見るきっかけとしての「繋がり」
• IT用語辞典3によればBlogとは『個人や数人のグループで運営され、日々更新される 日記的なWebサイトの総称。内容としては時事ニュースや専門的トピックスに関して 自らの専門や立場に根ざした分析や意見を表明したり、他のサイトの著者と議論したり する形式が多く、従来からある単なる日記サイト(著者の行動記録や身辺雑記)とは区別 されることが多い。』である。Blogの特徴としてトラックバック機能を利用することで、記事がクチコミで広まりやす く多くの人を集めることができるということが挙げられる。同じサイトに対してリンク を張った者同士、または自分の記事に興味をもちリンクを張ってくれた人達などの「繋 がり感」がコミュニケーションを促すきっかけとなっていると考えられる。 • IT用語辞典によればSNSとは『人と人とのつながりを促進・サポートする、コミュニ ティ型のWebサイト。友人・知人間のコミュニケーションを円滑にする手段や場を提供 したり、趣味や嗜好、居住地域、出身校、あるいは「友人の友人」といったつながりを 通じて新たな人間関係を構築する場を提供する、会員制のサービス』である。
SNSの特徴として、SNSの中ではFOAF（Friend Of A Friend）、すなわち「友人の友人」 が重要になっている。FOAFは自分の個人情報などのプロフィール（本名、ニックネー ム、職業、居住地、誕生日、趣味、関心、友人関係など）を記述し、相互の「繋がり」 を可視化・共有することでコミュニケーションのきっかけを作り出している[4]。
1.2.2
既存の「繋がり」の問題点と改善案
Blogでは「興味の対象が同じである」という繋がり、SNSでは「FOAF」という繋がりを 支援していて、コミュニケーションのきっかけを作り出している。そこで「繋がり」がイン フォーマルコミュニケーション生起における重要なファクターであると考えられる。しかし上 記のサービスにおいて新たな繋がりが構築されるためには、トラックバックを張ったり、FOAF のページにアクセスしたりと、ある程度能動的な繋がり探しをしなければならない。これら のプロセスは積極的な活動として精神活動に有益であるが、裏を返せば「繋がり」を探すと いう非日常的活動を行わなければ「繋がり」は得られないということである。 本研究では既存のサービスの良さである「繋がり」探しを継承する一方で、本人と不特定多 数の他ユーザとの「繋がり」を探さずに日常的活動の中から構築することで、インフォーマ ルコミュニケーションのきっかけを提示することを目指す。1.2.3
既存のコミュニケーションツールの問題点と改善案
インターネットを用いてコミュニケーションを行うツールには、掲示板やチャット、Blogの コメント欄等、様々な種類がある。これら既存のコミュニケーションツールにおいて、自分が 話したいテーマに沿った掲示板やチャットルームを探したりするプロセスが必要となる。それ らの能動的なアクションは、会話へのモチベーションがある程度高くなければ起こしにくい。 さらに本研究はインフォーマルコミュニケーションに焦点を当てていて、その特徴の偶発的 [1]という点に着目するならば突発的に沸いたモチベーションを下げさせないために会話は相 手と即時的に行われる方が好ましい。そのためB. A. Nardi[3]らが議論しているレスポンスの 即時性・明確な相手との接触を持てるという利点から、使用するコミュニケーションツール はチャットシステムを採用する。しかし既に述べたように既存のチャットツールでは部屋を探 すというプロセスを踏まなければならないため、本研究が必要とする即時性は備えていない。そこで本研究では話す場所を探すというプロセスを排除し、その場で会話を行えるチャット ツールを開発する。
1.3
論文の構成
1章でBlogやSNSがどのような特徴をもつサービスであり、どのような問題点があるのか を述べた。インフォーマルコミュニケーション支援に必要な「繋がり」の提示とそれを活か すシステムの提案、及び利用例を2章で述べる。3章ではシステムの機能と動作例を説明し、 4章で実装方法を述べる。 5章で本システムに関する考察を行い、6章で関連研究との位置づけを述べた後に7章でまと める。第
2
章 インフォーマルコミュニケーションを誘
発させるシステムの提案
2.1
提案システム：
Page-Chat
本研究では1.2.2節と1.2.3節を受け次に挙げる3つの要件を満たすシステムPage-Chatを 提案する。2.1.1
日常的な活動における繋がりの構築
Page-Chatではユーザの日常的行為の一つとしてWebページの閲覧に注目する。Webペー
ジは実世界での場所と同じ意味を持ち、偶然同時刻に同じページを閲覧しているユーザ相互 に「繋がり感」を感じさせることができる。このメリットは以下の２つである。 • 探さなくても「繋がり」が構築できる • 「自分と同じ記事に興味を持つ人間がいる」という親近感と記事の話題性がコミュニ ケーションのきっかけとなる。
2.1.2
積極的な繋がり探索
2.1.1節の偶然同じWebページを見ているという繋がりはWebブラウジングをしていた場 合の副次的な産物として感じることができるが、この同じWebページを見ているという状況 を積極的に作り出すことで更にネットワークコミュニケーションは豊かになると考えられる。 そこでPage-Chatは多くの人が閲覧している人気ページの存在をユーザに気付かせる機能を 実装する。この機能のメリットは以下の2点である。 • 積極的に他者との繋がりを構築することができる。 • 未だ見ぬ人気ページのコンテンツを試しに閲覧することで、新しく興味を引かれる記事 に出会える可能性がある。2.1.3
即時的な会話
インフォーマルコミュニケーションは「偶発的で話題も不特定である」という特徴[2]のた めにきっかけはあっても、しばしばコミュニケーションが発生しないケースがある。例えば 隣に人がいるときだと、話したいと思えば隣人と会話が気軽にできる。しかしそうでない場 合は、既存のコミュニケーションツールでは突発的に沸いたこの会話欲を満たす空間はその トピックスに関する掲示板やチャットルームになる。この時都合よくテーマに沿った掲示板・ チャットルームを探したりするプロセスは、突発的に沸いた会話欲に対する熱を冷ましてしま う恐れがある。 より円滑なコミュニケーションを支援するためにPage-Chatでは『場所を探すことなく』閲覧 者同士で即時的な会話を行えるようにする。そのために閲覧中のWebページを一つのチャッ トルームと見なして、その場で話せるチャットシステムを開発する。2.2
利用例
提案するシステムの利用シーンを二つ挙げる。2.2.1
偶発的な繋がり
A氏は釣りが好きで休日はよく各地の釣りスポットへ出かける。たまには友人達と一緒に 行くこともあるが、友人達はA氏ほど釣りに深く関心を持っているわけではないのでほとん どの場合はA氏一人で行く。 いつものように今度の休日に出かける釣りスポットを探すために、自宅のパソコンで釣りス ポット紹介サイトを見ていた。各スポットの風景や釣れる魚の種類を慎重に吟味するが、実 際に行ってみないと分からない事も多々あった。とりあえず気になったスポットに行ってみ ようかと考えていた時に偶然同じサイトを見ている人がいる事に気付いた。スポットについ て何か情報が聞けるかもしれないのでA氏はチャットで彼に話しかけてみることにした。話 しかけられたB氏は釣り好きがいたことに喜び、自分が行ったことのあるスポットの感想・ 今度行こうかと思っているスポットなどを話してくれた。A氏とB氏は存分に釣り談議を楽 しんだ。 これは同じ興味を持っているユーザ同士が偶然居合わせ、コミュニケーションが発生した 例である。A氏は掲示板に書き込むほど迷っていたわけではなかったので、コミュニケーショ ンが発生する余地は無かった。しかし同じページに人がいると分かると、会話欲が沸いてき てB氏と雑談で盛り上がった。 繋がりを知らせてその場で会話できるPage-Chatの典型的な利用例である。図2.1:偶然同じWebページを見ている
2.2.2
積極的な働きかけ
釣りスポット探しが大成功に終わったA氏はブラウザを閉じようとしたが、何やら人が多 く集まっているページがある事に気付いた。好奇心を抱いたA氏はそのページを閲覧してみ ることにした。 そのページはニュースサイトでサッカー日本代表の試合速報が報じられていた。サッカー強 国ブラジル代表を相手に前半戦は日本代表がリードしている、といった内容の記事でチャット の会話を見ると日本の選手達が一丸となって失点を防ぐ様を称える内容だった。もうすぐ後 半戦が始まるらしい。サッカーは詳しくなかったが皆の興奮ぶりに興味を引かれたA氏はテ レビをつけた。 これは人気ページの存在を知り、新たな記事に対して興味を持つ例である。A氏は記事の 内容に対して詳しくなかったが、今後興味を持つことでそのジャンルにおけるコミュニケー ション生起の可能性を示唆している。またA氏が詳しい内容の記事であったならばその人気 ページで一緒に盛り上がった可能性もある。第
3
章
Page-Chat
この章ではPage-Chatのクライアントアプリケーションとその動作例を説明する。
3.1
クライアントアプリケーションの説明
図3.1はPage-Chatの実行画面である。
3.1.1
パネル➀：会話スペース
利用者間で会話を表示するためのスペースである。スペースの最上段の行は会話をしてい るウェブページのURLである。これは通常のチャットアプリケーションでの部屋名にあたる。3.1.2
パネル➁：ルームリスト
図3.2: ルームリスト 部屋名(URL)を行別にリスト化したものであり、現在入室中の部屋を表示している。左か ら順にURL,STAY,MEMBER,VIEWの列があり、それぞれ各部屋の状態を示している。また チャットを快適に行うためのアクションを起こす時に用いる。 [URL] ブラウザでウェブページを訪問するとそのページのURL名の部屋に自動的に入室する。ルー ムリストにはユーザが自ら訪れたページの部屋のみを表示する。 [STAY] STAYセルの初期状態(入室時)は「OFF」にセットされている。この状態で新規に別のページ を閲覧すると自動的に以前のページの部屋から退室する。STAYセルをクリックするとセルの 値は「ON」にセットされる。この状態で新規に別のページを閲覧したとしても以前のページ の部屋から退室することはない。これにより大量の訪問済みのページ(部屋)から自分の興味 のあるページ(部屋)だけを残すことができる。また部屋に居続けることで新規にページを訪 れた他ユーザとの出会いを誘発することができる。そのページに対する興味が薄れて退室し たい時には、もう一度STAYセルをクリックすることで即座に退室できる。 [MEMBER] そのページ(部屋)にいるユーザ数を表示している。 [VIEW] どの部屋の会話内容を会話スペースに表示するかを選択するものである。以前訪れた部屋が 「STAY」状態であったとしても、新規に別のページを閲覧すると会話スペースには新規に訪 れたページ(部屋)の会話内容が自動的に表示される。この時に任意の「STAY」状態の部屋のいる部屋以外の部屋で他ユーザによる発言等のアクションが起きたときは、対応する部屋の
VIEWセルの値に「VIEW」がセットされる。ユーザは「VIEW」を見ることでどの部屋でア クションが起こったかを知ることができ、VIEWセルをクリックすることで即座にその部屋 で起こったアクションの確認ができる。一度「VIEW」状態のセルをクリックするとそのセル は再び何もセットされていない状態に戻る。
3.1.3
パネル➂：ユーザリスト
現在会話スペースで表示されている部屋の入室者一覧である。 図3.3: ルームリスト3.1.4
パネル➃：ホットページランキング
現在人が集まっているページ、つまり人気のあるページのURLを表示し、盛況具合を炎で アンビエントに表現する。今回の実装では、人気度は存在している全ての部屋のユーザ数を 比較することで選出している。ユーザ数が多ければ多いほど炎は燃え盛ることになる。 図3.4:炎レベル,左からレベル1∼レベル53.2
動作例
Page-Chatの動作例を挙げる。
STAYセルのON・OFF
(A)はgoogleのページを見ているがSTAYセルの値はOFF状態になっている。この状態で新
たにyahooのページをブラウザで見るとルームリストからgoogleが消え、yahooのみが残る
(B)。(B)の状態からyahooのSTAYセルを一回クリックしてON状態にしておくと次に再び
googleを訪れた時、yahooは残りルームリストにはgoogleが新たに追加される。(C)
図3.5: STAYセルの動作例(A) 図3.6: STAYセルの動作例(B)
VIEWセル
(D)と(E)を見るとyahooとgoogleの両方の部屋に2人のユーザが入室していることが分か
る。次にgoogle部屋を見ているとyahoo部屋のVIEWセルの値が「VIEW」に変わったこと
に気付いた(F)。そこでyahoo部屋のVIEWセルをクリックして覗いてみるとyahoo部屋で発 言があったことが分かる。
図3.8: VIEWセルの動作例(D) 図3.9: VIEWセルの動作例(E)
第
4
章 システム構成
4.1
全体の構成
図4.1: システム概観 図4.1はシステムの概観を表している。 プロキシサーバが得て保存したユーザの情報を用いてチャットサーバはチャット機能を提供し ている。 ➀ チャットクライアントを起動しているユーザは好みのブラウザでウェブページを閲覧す る。この時コンテンツのリクエストはプロキシサーバを介して行う。 ➁ プロキシサーバはこのユーザの情報(IPアドレス・リクエストライン)を取得してログ ファイルに保存する。この情報を元にチャットサーバはユーザの認証、チャットルーム の作成・入室などの動作を行う。 ➂ チャットクライアントとチャットサーバが会話やホットページランキングなどのデータ4.2
プロキシサーバの実装
開発環境は以下の通りである。また本研究におけるプログラムは全て同じ環境下で実装し た
• CPU：Pentium(R)4:3.00GHz,Memory:1GB
• OS：Microsoft Windows XP Professional Version 2002 Service Pack 2
• 開発言語：Java(JDK5.0) • 開発環境：Eclipse SDK3.1.1
4.2.1
概要
ほとんどの場合サーバとクライアント(ブラウザ)のプロトコロルはHTTPであり、実装を 行う上でもこれを基本として進める。HTTPは大別するとリクエストとレスポンスで構成さ れている(図4.2)。クライアントはサーバに向けてリクエストを送信する。リクエストの一行 目は「メソッド URI HTTPバージョン」で構成されていて、URIで指定されている対象 をどうメソッドで処理するのかが既述されている。これを一般にリクエストラインと呼ぶが、 本研究でプロキシサーバを設置する目的はチャットクライアントアプリケーションを起動して いるユーザのリクエストラインを解析することで、ユーザが見ているウェブページの情報を 取得することである。またプロキシサーバで管理することによりブラウザに依存することな く情報が取得できる。 図4.2:サーバとクライアントの関係4.2.2
リクエストラインの解析
リクエストラインは「メソッド リクエストURI HTTPバージョン」で構成されている。 ユーザがウェブページを1つリクエストするだけでもプロキシが処理するリクエスト文(図 4.3)は膨大な量になる。その膨大な量のリクエスト文を解析してログファイル(4.2.3)に必要 なURLを抽出する必要がある。 現段階ではGETメソッドでフィルタリングをした結果を利用している(図4.4)。フィルタリ ングした結果を時系列順で見てみると、先頭でHTMLドキュメントのURI(URL)をリクエス トして以降の行ではHTMLドキュメントに含まれる画像のURIをリクエストしている。全て のページのリクエストでこの法則が成り立っているかどうかの検証は行っていないが、現段 階ではこの先頭GETメソッドのURIをログファイルに書き込んでいる。 図4.3: googleのリクエスト文 図4.4:リクエスト文をGETメソッドでフィル タリングしたもの4.2.3
ログファイル
必要なユーザの情報を保存するファイルである。ここでいう必要な情報とは「どのユーザ (IPアドレス)がどのページ(URL)を見ているか？」ということを明示する情報を指す。 ただし現在の実装ではユーザが見ている全てのページのURLを保存するのではなく、ユーザ が最後にアクセスしたページのURLのみを保存している。これは現段階でリクエストライン の有効な解析法を模索中のためである。ログファイルは次のような形式で作成される。 ファイル名 ：「(IPアドレス).txt」 内容 ：「(URL)」 例えば「IPアドレス：127.0.0.1」のユーザがgoogleのエントランスページを見ていた場合は 次のようになる。ログファイルの詳しい用途は4.3節で説明するが、チャットサーバでしか利用されないので 将来的にはファイルとして保存するのではなくデータとして直接チャットサーバに送ることに なる。なお現段階では開発時のデバッグ用データとしてもファイルを利用している。
4.2.4
並列処理
プロキシサーバは複数のユーザが同時に接続する事態が考えられる。シングルスレッドで はアクセス数が多くなれば多くなるほどユーザのウェイトタイムも大きくなり、ユーザを不 快にさせてしまう恐れがある。この対策としてサーバをマルチスレッド設計にすることでク ライアントを並列処理する(図4.5)。 図4.5: マルチスレッドプロキシサーバ4.3
実装：チャットサーバ
4.3.1
概要
チャットサーバはソケット(SocketServerクラス)を用いてクライアントアプリケーションと 通信を行う。概略図を図4.6に示した。チャットサーバは存在する全てのチャットルームオブ ジェクト(4.3.3節)と接続中の全ソケットに対するユーザスレッドオブジェクト(4.3.2節)を 保持する。チャットルームは入室中のユーザのユーザスレッドオブジェクトをそれぞれ保持す る。ユーザスレッドがソケットのクライアントアプリケーション(一対一対応)との通信を行うので、入退室・発言・ログアウト等のやり取りはユーザスレッドを通じてチャットルーム・ チャットサーバオブジェクトで行われる。 チャットサーバの役割はチャットルームとユーザ全体の管理である。チャットサーバはユーザ スレッドを複数保持すること(マルチスレッド)により個々のクライアントを並列処理する一 方で、クライアントソケットの接続を待ち続けて新たなソケット接続があれば新規ユーザス レッドを生成する。また必要に応じてチャットルームオブジェクトを生成・破棄することが可 能である。さらに個々のチャットルームの入室者数を数えてホットページランキングを作成す るメソッドを有している。 図4.6:チャットサーバの概略図
4.3.2
ユーザスレッド
ユーザスレッドはクライアントアプリケーションと一対一対応で通信を行っていて、現在 クライアント側の会話スペースで表示している部屋の名前(URL)を保持している。またチャッ トで使用するユーザの名前を保持し、それを返り値とする外部から呼び出し可能なメソッド を実装している。 またクライアントとの通信はテキストベースで行われ、通信メソッドも外部から呼び出し可 能である。通信するメッセージは[コマンド名(半角スペース)内容]で構成されていて、例え ばユーザが「こんにちは」と発言した場合は[msgこんにちは]というメッセージを受け取る。 ユーザスレッドが受け取る各種コマンドの用途と付随して送られてくる内容の一覧は図4.7に 示してある。 退室・発言・会話スペースに表示する部屋の変更等のメッセージをクライアント側から受話の履歴(メッセージログ)をクライアント側に送信する。 またユーザスレッドはクライアントソケットのIPアドレスを利用してクライアントのログファ イル(4.2.3節)の更新状況を監視する。ログファイルが更新されるとクライアントが新しい部 屋(URL)に移動したと判断して新しい部屋への入室処理を行う。図4.8は入室処理時のクラ イアント側とのやり取りの説明である。 図4.7:ユーザスレッドが受け取るコマンド一覧 まずクライアントがブラウザで新しいページに移動するとプロキシサーバによってそのURL が取得されログファイルに保存される。チャットサーバ内でそのクライアントを監視してい るユーザスレッドがログファイルの更新を確認すると、チャットルームの入室メソッド(4.3.3 節で後述)を呼び出し入室メンバーに登録されたあと、チャットクライアントアプリケーショ ンにも入室を通知する。クライアント側はGUIコンポーネントのユーザリストを取得するた めに、サーバ側に入室した部屋のメンバーを要求する。サーバは要求がくると対応する部屋 のメンバーリストをクライアントに送信する。メンバーリストを受け取ったクライアントは それを元にコンポーネントを更新する。メンバーリストと同じようにクライアント側は部屋 のメッセージログを要求・取得する。この時ログファイルの内容(URL)が既に入室済みの部 屋であり二重に同じ部屋の入室メソッドを行う場合があるが、その場合はチャットルームオブ ジェクトが判断して二重入室を防ぐ。
4.3.3
チャットルーム
チャットルームは部屋名(URL)・メッセージログ(会話の履歴)・入室中のユーザスレッド配 列を保持する。また入退室メソッドを持ちユーザスレッドからの呼び出しが可能である。入 室中のユーザスレッドのメソッドを用いることで入室中のメンバー全員の名前をリスト化す るメソッドを有していてこれも外部から呼び出し可能である。同様に外部呼出し可能であり図4.8:入室の場合 メッセージログを返り値とするメソッドも有する。入退室メソッドは呼び出されると保持し ているユーザスレッド配列において呼び出し元のユーザスレッドの登録・抹消を行う。入室 メソッドに関しては4.3.2節で述べた様に、呼び出し元のユーザスレッドが既に配列の中に登 録されていた場合は二重の登録を防ぐ。またチャットルームオブジェクトはユーザスレッド配 列が０になるとチャットサーバからの参照を消去して自動的に破棄される。チャットルームオ ブジェクトとユーザスレッドの関係の例として入室時(図4.9)と会話時(図4.10)のやり取り を説明する。 入室時 まずユーザスレッドAがクライアントの入室をログファイルの更新から判断する。Aは入室 メソッドを呼び出すことで自身のオブジェクトをチャットルームに登録する。チャットルーム は入室メソッド呼び出しから新たに呼び出し元のAを登録し、ユーザスレッド配列の各要素 の通信メソッド(4.3.2節)を呼び出して、Aが入室したことを入室者全員に知らせる。その後 図4.8でも説明した通り、Aは入室メンバーのリストとメッセージログの要求メソッドを呼び 出しこれらを取得する。 会話時 まずクライアント側からメッセージを受け取ったユーザスレッドがチャットルームに通知す る。その後チャットルームはユーザスレッド配列の各要素の通信メソッド(4.3.2節)を呼び出 してAが発言したことを通知し、その内容をメッセージログに保存する。
図4.9:入室時のやり取り
またチャットルームの登録ユーザ数に変更があった場合には、ホットページランキングを計 算するメソッド(4.3節)を呼び出す。このメソッド自体はチャットサーバ自身が有しているの でチャットサーバが管理しているユーザ全体にランキングの変更を通知することが可能であ る。図4.11はその工程を表している。 図4.11:ホットページランキング変更の工程
4.4
実装：クライアントアプリケーション
クライアントアプリケーションはルックアンドフィールの観点からウィンドウコンポーネン トにはSwingを使用している。またソケット(Socketクラス)を用いてチャットサーバと通信 を行うが、その通信は4.3.2節で述べたようにチャットサーバ内のユーザスレッドの1スレッ ドとして処理される。ユーザスレッドとの対話でクライアント側が受け取るメッセージのコ マンドの一覧は図4.12で示されている通りである。コマンドの一部を紹介する。 viewS このコマンドはクライアント側からview(図4.12)を送信した場合に、チャットサーバ側から のレスポンスとして受信する。クライアントがviewコマンドを送信したということは、クラ イアントは任意の部屋の会話履歴を会話スペースに表示しようとしていることになる。 この 時今まで会話スペースに表示されていた内容を破棄してから新しい会話履歴を表示しなけれ ばならない。その最初の工程、つまり会話スペースにある古い内容の破棄を指示するコマン ドである。従ってコマンドに付随する内容は無い。のコンポーネントに追加する。 otherRoom 現在会話スペースに表示している部屋以外の場所で会話が起こった場合に受信する。[部屋名] は会話が起こった部屋の名前である。[部屋名]で会話が起こったことを示すためクライアン トはルームリストにある対応する部屋のVIEWセルの値を「VIEW」に変更する。 図4.12:クライアント側が受け取るコマンド一覧 Top1 ホットページランキング1位の[部屋名]と[人数]を受信する。クライアントは人数に応じて描 画する炎のレベルを決定し、コンポーネントの更新を行う。また類似コマンドに[Top2],[Top3] がありそれぞれホットページランキング2位,3位を通知する。4.3.3節(図4.11)で述べたよう にチャットルームの人数が変わるたびに通知される。通知はTop1,Top2,Top3の順に行われる (図4.13)。 尚ホットページランキングにおける炎の描画に関してはフリーウェアアプレットを開発し ている四井 賢一郎氏のホームページ1に記載されているアルゴリズムを参考にした。 1四井 賢一郎氏のホームページ：http://www.kdn.gr.jp/ shii/java/exam/algorithm/
第
5
章 考察と課題
Page-Chatではインフォーマルコミュニケーションが起きる前段階におけるきっかけとし て「偶然同じページを見ているという繋がり」を提示した。しかしPage-Chatはコミュニケー ションが始まった後の支援についてはまだまだ課題が残る。例えば会話中のコンテクストア ウェアネスに関しては西田[10]らによって研究されている。西田らのLock-on-Chatでは画像 を共有し、それら画像の特定箇所に結び付けられた会話を楽しむことができる。特定箇所に ユーザが注目していてその箇所についての会話が起きているという強いコンテクストアウェ アネスを受けられる。これはPage-Chatについても応用の余地が考えられる。現在見ている Webページのどの部分に対して会話が行われているかというアウェアネスを提示することで より充実したコミュニケーションが可能になると予想できる。同様にコミュニケーションにお けるユーザ間のコンテクストアウェアネスの研究はTangibleChat[14],ConChat[8],Notification collage[7],Chat Circles[9]など盛んに行われている。 また会話中及び会話後のコミュニティ作りに関しても課題が残る。Page-Chatでは相手と会話 をした後にその相手とは特にコミュニティを形成するわけでもなくその場で別れてしまう。気 が合う仲間とは何らかのグループ・コミュニティを形成できる機能を拡張していくことでよ りソーシャルな要素を取り入れることになりPage-Chatは充実したコミュニケーションツール になると考えられる。さらに形成後のグループ・コミュニティの管理も考慮に入れるべきだ ろう。これについてはグループの参加メンバーを手軽に変更できるQuickML[11]や、異なる コミュニケーションツールを統合したqwikWeb[12]、インターネット上でも情報の公開範囲 を詳細に設定・変更できるようにするenzin[13]などがそれぞれアプローチしていて我々も学 ぶべき所が多い。第
6
章 関連研究
6.1
繋がりを支援する研究
我々と同じ繋がりに着目した赤塚大典[5]らの「わくらわ」という研究がある。日常的に付 き合いのある知人を「強い紐帯」、普段は疎遠な知人を弱い紐帯に喩えていて、弱い紐帯から 何かのきっかけで思いがけずに有益な情報が得られる可能性を述べている。しかし弱い紐帯 は普段疎遠なために維持することが難しく従来のコミュニケーションメディアにはこれを支 援するツールがまだあまり検討されていない段階である。そこで弱い紐帯を維持しながらも、 きっかけが与えられたときにそれを活かすことができる枠組みを目指す試みが行われている。 具体的には図6.1のように同じページにいる知人の存在をアイコンで提示する。このアイコン は例え気付かなくてもおかしくない位置にある。そのためこのシステムの核心部分は「知人 の発見後どのような行動を取るかはユーザ自身に委ねられる」ということである。 「わくらわ」は同じページを見ているという繋がりに着目している点では我々のアプローチと 共通している。しかし「わくらわ」は既に本人が属しているコミュニティ内の知人とのきっか けを支援するのに対し、我々は不特定多数の他人とのコミュニケーションを目的としていて 積極的な繋がりを支援するという点でコミュニケーションの対象に対するスタンスの相違が ある。また「わくらわ」はきっかけを提示するのみでその後のコミュニケーション機能(メー ル・チャットなど)は既存のツールに委託している。6.2
Web
ブラウジングに関する研究
井上恭輔[6]らのantwaveはグリッドブラウジング(図6.2)という手法を用いることでブラ ウザ同士が有益な情報を共有し、他者がどのようなページを選んで遷移していったか？とい う情報を3次元で提示するシステムである。特に目的もなくWebブラウジングしているユー ザにとっては他者が歩んだ道筋は自分をナビゲートする道しるべとなるのである。その際提 示されたイメージでは多くのユーザが通った道ほど太いラインで結ばれていて、より人だか りを感じることができる(図6.3)。 人が集まるページを提示するという点で本研究のホットページランキング機能と共通する部 分がある。しかし井上らは人に会うという目的が根幹にあるので、Webページでの遭遇に対 して作為的に会うという立ち位置であるのに対し、我々はそれに加えて偶然ばったり会って しまうという偶然性に焦点を当てている点で違いがある。 図6.2:グリッドブラウジング. 図6.3: antwaveの実行画面第
7
章 まとめと今後の展望
Webブラウジングという日常的な活動の中において「偶然同じページを見ている」という繋 がりを構築することで、インフォーマルコミュニケーションのきっかけを支援するPage-Chat のプロトタイプを提案した。Page-Chatは与えられたきっかけをコミュニケーションの誘発に 活かすために「部屋を探すことなく会話ができる」チャットシステムを有していて、コミュニ ケーション生起の前段階における支援をしている。今後は会話中にユーザ間のコンテクスト アウェアネスを提示することでより充実したコミュニケーションを行えるようにしたいと考 えている。また会話中及び会話終了後における気の合う仲間とのグループ・コミュニティの 形成支援にも着手する予定である。謝辞
本研究の執筆にあたり、筑波大学システム情報工学研究科 田中二郎教授には懇切なご指導 とご助言をいただきました。ここに深く感謝致します。また、三末和男助教授、志築文太郎 講師には大変有益な議論の機会を与えて頂きました。心から感謝申し上げます。さらに高橋 伸講師には、研究内容に留まらず進捗等についてもご指導頂きました。心から感謝致します。 筑波大学システム情報工学研究科 インタラクティブプログラミング研究室のメンバーの方々 にも大変お世話になりました。この場を借りて厚くお礼申し上げます。参考文献
[1] 小野孝之,三村和,川原圭博,森川博之,青山友紀. ”インフォーマルコミュニケーションを 支援するプレゼンス技術”. 電子情報通信学会技術研究報告,NS2004-296,March 2005 [2] 北陸先端科学技術大学院大学. ”ナレッジ・サイエンス”(2002).
http://www.kousakusha.com/ks/index.html
[3] B.A.Nardi,S. Whittaker and E. Bradner.“Interaction and Outeraction: Instant Messaging in Action”. CSCW’00,pp.79-88,2000 [4] 浜屋敏,吉田倫子,土屋太洋. ”ブログ・SNSの双発的特性と組織へのインパクト”. 富士通 総研経済研究所『研究レポート』,No.269,June 2006 [5] 赤塚大典. ”弱い紐帯に注目したコミュニケーションメディア「わくらわ」”. WISS 2006,pp.139-140 [6] 井上恭輔. ”antwave-超次元コラボレーションブラウザ”. 第16回全国高等専門学校プログ ラミングコンテスト自由部門,20045,March 2005
[7] Saul Greenberg,Michael Rounding. ”The notification collage: posting information to public and personal displays”. SIGCHI,pp.515-521,2001.
[8] Anand Ranganathan, Roy H Campbell, Arathi Ravi, Anupama Mahajan. ”ConChat: A Context-Aware Chat Program”. IEEE Pervasive Computing,pp.51-57,July 2002.
[9] Fernanda B. Viegas,Judith S. Donath. ”Chat circles”. SIGCHI,pp.9-16,1999.
[10] Takeshi Nishida, Takeo Igarashi. ”Lock-on-Chat: Boosting Anchored Conversation and its Operation at a Technical Conference”. INTERACT 2005 (Short paper), pp.970-973.
[11] Toshiyuki Masui, Satoru Takabayashi. ”Instant Group Communication with QuickML”. Pro-ceedings of the ACM Conference on Supporting Group Work (Group ’03), pp. 268-273, November, 2003.
[13] 永田周一,安村通晃. ”Enzin:情報の公開範囲を手軽に変更できるコミュニケーションツー ル”. ソフトウェア科学会WISS2005, pp.111-116, (Dec. 2005).
[14] 山田裕子,平野貴幸,西本一志. ”Tangible Chat:打鍵振動の伝達によるキーボードチャット
における対話状況アウェアネス伝達の試み”.情報処理学会論文誌，Vol.44, No. 5, pp.1392-1403, 2003.
