”‰−oﬁI…R…ﬁ…e…L…X…g‡ðŠp‡¢‡½„�“õ„‰›Ê‡Ì™ñ”¦

(1)

視覚的コンテキストを用いた検索結果の提示

情報通信工学専攻情報通信システム学講座

０９３００１０井桁正人

指導教員寺田実准教授

提出日２０１１年１月２８日

(2)

1

図目次

1.1 Googleの検索結果ページ(SERP) . . . . 6

1.2 視覚的コンテキストの具体例. . . . 7

2.1 プロトタイプ:ノートパソコンの寸法を調べる場合．仕様表の一部が表示され，寸法に関する情報があることが分かる． . . . . 11

2.2 プロトタイプでのVP生成の様子．ここでは「寮」というVPクエリ周辺の一定範囲がVPとしてキャプチャされる． . . . . 12

2.3 プロトタイプシステムの全体像 . . . . 13

2.4 プロトタイプシステムの使用例 . . . . 16

4.1 PatchworkVision:大学の寮についての解説記事を探す場合． . . . . 22

4.2 マウスオーバーでVPが拡大する様子． . . . . 23

4.3 提案システムにおけるVPの生成される様子．結果ページの薄い赤色の部分がVP クエリの含まれる箇所となる． . . . . 24

5.1 時間測定に用いたブラウザ右下に追加したストップウォッチボタン . . . . 27

5.2 評価実験におけるタスク達成時間 . . . . 30

5.3 リッカート尺度を用いたアンケートの結果 . . . . 30

6.1 FirefoxアドオンのSearchPreview：SERP上に各結果のサムネイルが提示されている． . . . . 32

6.2 TeevanらのVisual Snippets[2]：元のページから最終的に右の視覚的なスニペットが生成される． . . . . 34

6.3 SuhらのPopout prism[4]：キーワードが強調表示されたサムネイルからページ構成の把握とスクロールを支援． . . . . 34

6.4 LiuらのWildThumb[5]：ロゴなど特徴的な画像を強調表示することでタブ選択を支援． . . . . 35

6.5 Googleのインスタントプレビュー機能：検索クエリ「電気通信大学寮」の場合． 35 6.6 著者らのScoutView[6]：ページ内検索で結果の視覚的コンテキストの把握とスクロールを支援． . . . . 36

(5)

表目次

2.1 VPのランク付け . . . . 14

3.1 予備実験のタスク . . . . 17

3.2 予備実験のアンケート . . . . 18

5.1 評価実験のタスク . . . . 28

5.2 リッカート尺度方式の評価実験のアンケート . . . . 29

5.3 記述方式のアンケートの結果. . . . 31

(6)

5

第 1 _{章序論}

1.1 背景

現在，インターネットから情報を取得する際にGoogle¹ やBing² などの検索エンジンを利用する事がごく日常的に行われている．何らかの情報をインターネットから検索するその際には，検索に必要なキーワード（以下，検索クエリとする）を入力した後，検索エンジン検索結果ページ

（Search Engine Result Page.以下，SERPとする）上で，所望の情報が記載されているであろうページを見つけ出す，という作業が必要となる．

情報の存在しそうなページをSERP上で探しだす手掛かりとなるのは以下の三つである．

1. 検索エンジンによる結果のランキング 2. ページのタイトルやURL

3. スニペット（図1.1）–ページの見出しとなる箇所を本文から一部抽出したもの

特に（3）のスニペットは唯一ページ内部の情報をSERP上から判断できるものである．これは，

ユーザが注目するであろう箇所をページから抽出したその見出しである．そのページを閲覧するべきか否かを判断するのに，（1）や（2）で判断が付かない場合には非常に有効である．高久らの報告[1]によると，SERP上に記載されている情報の中でスニペットが最も注視されていることが分かっている．

スニペットはページ内のテキスト情報を断片的に集めたものであり，検索クエリが強調表示されていても，

• HTML,CSS等で加工される前のプレーンなテキストであり実際の表示とは異なる，

• 検索クエリが含まれる文，前後の文のコンテキストがとれない，

という問題がある．

この様に検索においてユーザの目的が特定のサイトやサービスを利用するわけでなく，Web全体からページのコンテンツの中に具体的な情報があるかどうかを探す場合(以下，調べ物検索とする)には，SERPにおいてページの選別が重要である．検索によって見つけたSERP上のいくつものページを別のタブなどに開き，その中に所望の情報があるかどうかを調べていくことは，ユーザにとって大きな負荷となってしまう．

また，近年Web上のページは通信サービスの高度化やWiki・ウェブログなどのページ作成支援サービスの充実により，その数が増加している．その中には情報量の豊富な長いページも数多く存在し，一つ一つのページの長さが一画面を超えてしまう可能性がある．Boungwon Suhら[4]によると，69%のページが一画面以上の長さを持つことが分かっている．さらに長大なページの場合

1Google http://www.google.co.jp/

2Bing http://www.bing.com/

(7)

図1.1: Googleの検索結果ページ(SERP)

には複数の話題が存在すると推測できる．よって，調べ物検索においてSERPに表示されているタイトルやスニペット等とそのコンテンツの話題が1:1対応するとは限らず，SERPでのその選別がより困難となっている．これはスニペットが内容を完全に要約しきれている訳ではないためである．結果，スニペットからその箇所を閲覧したいと思っても，ページを開いてさらにスニペットに記載されていた部分がどこかスクロールをして探し直す手間が発生してしまう．

以上より，ユーザが情報の情報を得る支援をするためには，検索クエリの入力してからSERP上でのページ選択とページ内でスクロールを支援する必要がある．

1.2 視覚的コンテキスト

1.2.1 検索におけるユーザの予測と視覚的コンテキスト

検索エンジンで検索を行う際，ユーザはスニペットで示されるページ内の表現を手がかりにして所望の情報がそのページのどこにあるかを予測している．

例えば，ノートPCの大きさを知りたい場合，それは仕様表に「寸法」などの行があるとユーザは予測する．しかし，SERP上でそのページに仕様表があるかどうかはテキストのスニペットからは直接判断できない．結果，実際にページを開いて確認する必要が生じてしまう．

情報があると思ってページを開いても，前述の様にスニペットの情報は実際の表示と異なるため，その情報が本当に欲しかったものとは限らない．そのため，その様なページ内の見栄えを考慮して情報検索を行うことができない．前述の例で言えば本当に仕様表があるかどうかをスニペットから判断できれば，SERP上にて直ちに所望の情報を含んだページを特定できる．

また，ページ閲覧時に一度訪れたことのあるサイトや使ったことのあるWebサービスに類似のデザインであれば，そのページのおおよそのコンテンツが把握でき，ユーザは所望の情報の有無を判断し易くなる．この時，既に欲しい情報がどの様に表現されているかユーザはほぼ予測できており，その実際の見栄えを頼りにSERP上でページの選択を行えるためである．これは，上の例ではその商品についての説明ページを実際に閲覧すれば，オフィシャルのノートPCのスペックが記

(8)

第1章序論 7

図1.2: 視覚的コンテキストの具体例

載されているページであるか，ニュース記事であるか，個人のウェブログで感想が書かれているものであるか，等が即座に判断できるということである．

さらに別の例として，大学の寮についての解説記事を探している際には図1.2の（1）の様にその検索クエリが見出し語になっているかは重要である．しかし，その検索クエリが図1.2の（2）の様にリンクのアンカー内にあれば，それは解説記事でないことが容易に把握でき，欲しい情報とは異なる可能性が高い．この様に特定のキーワードに関する情報について調べ物検索を行っている場合には，そのキーワード自体の視覚的な表現のされ方が重要な手がかりとなる．

SERPでページ内の見栄えを提示すれば，無駄にページを開いてしまう「はずれ」が無くなり，

上の例の様に見栄えから様々な判断を行うことが可能となる．

この時，既に欲しい情報がどの様に表現されているかユーザは把握しており，その実際の見栄えを頼りにSERP上でページの選択を行えるためである．ここで，ページの見栄えも含めた文脈情報であるページ内でのキーワードの視覚的特徴を視覚的コンテキストとする．また，区別のため一般的な意味での文章についてのコンテキストを文章的コンテキストとする．

1.2.2 視覚的コンテキストの実例

視覚的コンテキストとは文章的コンテキストとは異なり，ページのデザインやレイアウトのために生じる，HTMLやCSS等による段組み，文字サイズ，そして色の変更などを指す．特にキーワードに焦点を当てたものとして具体的には，

1. キーワードが列挙されていたりリンクが集まってリンク集であると分かる，

2. キーワードが太字で見出し語となりその下に文章が続いているのでその解説であると分かる，

3. 表の一部にキーワードが存在していてどの様にまとめられているかが分かる，

など表現の手法によるものである（図1.2）．

本研究ではスニペットから視覚的コンテキストを把握可能とすることで，ページ内に所望の情報が有るか否かのユーザの判断を助け，ページ内でのその情報までのナビゲーションを支援する．

1.3 _目的

本研究では，以下の機能を持つインタフェースを備えたシステム“PatchworkVision”を実装し，

視覚的コンテキストを提示することでWeb検索を支援することを目的とする．具体的には，

(9)

• SERPにおいて結果ページ内の実際の表示を提示，

• 所望の情報があるであろうページの選択を支援，

• 提示された表示内容へのナビゲーションを支援，

という特徴を備え，検索結果から容易に所望の情報が存在するページを発見し，そこまでのナビゲーションを支援する手法を提案する．また，提示システムの有用性を検証するために評価タスクを行う．なお最終的な提案システムを設計するため，それとは異なるプロトタイプを設計，評価している．

1.4 本論文の構成

論文の構成について簡単に説明する．

本章では，「序論」として本研究の背景と検索エンジンを用いた検索結果における問題点，そして目的について述べた．

第2章では，提案システムのためのプロトタイプの設計及び実装について述べる．

第3章では，提案したプロトタイプについての評価について述べる．

第4章では，提案したシステム“PatchworkVision”についてプロトタイプからの変更点について述べる．

第5章では，PatchworkVisionの評価についての方法及び結果と考察について述べる．

第6章では，関連研究と提案システムとの比較について述べる．

第7章では，結論を述べて今後の課題について述べる．

(10)

9

第 2 _{章プロトタイプ}

本手法を用いたシステムを設計するにあたり，従来のSERPとは大きく異なった結果表示方式を採用することを検討した．従来はページ単位で検索結果を提示していたが，本手法では指定したキーワードを軸としたページ内の実際の見栄え単位での結果提示方式となる．しかし，SERPという日頃ユーザが慣れ親しんだものを大きく変更してしまうことは，極めて大きな負荷となってしまうことが予測される．そのため，予備実験によりその評価を行ってから最終的なシステムの提案を行う．

2.1 設計

ユーザが視覚的コンテキストを把握できるようページの見栄えを提示するには，そのスクリーンショットを提示すればよい．しかし，ページ全体を提示してしまうと結果の一覧性が低下してしまう．また後述する関連研究[3][4][5]の様にあるキーワードを拡大したサムネイルとして提示すると，おおよその視覚的コンテキストを把握することは可能になるしかし，キーワード以外の細かい文字は読めなくなってしまい，従来のスニペットの様に文章的コンテキストを把握することができなくなってしまう．その様な問題点を解決するために，以下でその手法について述べる．

2.1.1 VP の提示手法

従来のスニペットは検索クエリが含まれる文やユーザが注目するであろうと思われる箇所等が記載されていた．本システムでは，同様にユーザが注目するであろう箇所として見栄えが把握でき，

かつ一覧性を損なわずに視覚的コンテキストの把握が行える検索結果の提示を目的とする．そのため，キーワード周辺の固定サイズの部分的なスクリーンショット（以下，VP:Visual Patchとする）により検索結果を提示する（図2.1）．

なお，検索クエリとは別に，ユーザが所望の情報を直接的に示すためのキーワードが必要となる．その様なVPで強調表示するキーワードをここではVPクエリとする．

本システムでは，この検索クエリとVPクエリの二つのクエリにより検索を行う．これはWeb 検索において本来ユーザはページを検索エンジンにて検索した後に，さらにページ内で所望の情報を検索するというタスクを行っている．しかし，検索クエリの指定はページ検索とページ内検索の両方が混同されたものとなってしまっているため，調べ物検索ではページの選択が困難になってしまう．そこで，本研究ではページ内検索のためのキーワードをVPクエリとして別途指定している．

また，VPクエリは検索クエリと同じである必要はない．入力が無い場合には検索クエリがVP クエリとなり，検索クエリが複数語であればその末尾の語がVPクエリとなる．これは検索クエリとして複数の単語を指定する場合，著者の主観から一般的に条件を狭めるためにより詳細な単語が末尾となることが多いためである．

(11)

2.1.2 検索結果のリランキング手法との違い

視覚的コンテキストをページのDOM(Document Object Model¹)構造の解析から自動的に算出し，視覚的なスニペットを用いないでユーザが所望の視覚的コンテキストから検索結果をリランキングするといった手法は用いなかった．これは，ユーザが検索の際に想定している視覚的コンテキストは非常に曖昧なものであり，実際にページを見てからでないと判断できないためである．

例えば，前述の例の様にユーザがPCの仕様表を求めている場合，結果ページ内にHTMLによる

<TABLE>タグがあるかどうかは容易に判断することはできる．しかし実際には，<TABLE>タ

グはページのレイアウトを揃えるために本来の想定される使用用途とは異なった使い方がされている可能性が存在する．このように，ページのDOM構造から実際に人が受け取る意味は必ずしも一致するとは言えない．よって検索・VP両クエリの入力段階での視覚的コンテキストの指定が困難であるため，本システムではユーザが自ら確認できるよう実際の見栄えとして提示する．

検索結果をVPの一覧として提示することで，VPクエリ付近の実際の表示を閲覧することができ，視覚的コンテキストを把握することが可能となる．結果，スニペットからページに情報が記載されていると判断したが，実際にページを開いてスクロールしたら，情報はそこには存在しなかったという「はずれ」を減少できる．

2.1.3 VP 単位での結果提示

これまで多くのWeb検索システムでは，その結果をあくまでページ単位のものとして提示していた．しかし，1.1節で述べたとおり，調べ物検索で見つかるようなページは長大なページの可能性があり，そしてページ内に複数の話題を含む可能性がある．そのためページと目標は1:1対応しているわけではないと言える．よって，結果の提示もページ内に複数の話題が存在することを考慮して提示する必要がある．

本システムでは従来のSERPと違い，ページ単位でなくVP単位での結果提示となり，ページの区別なくより細かいコンテキスト単位で一覧して結果を見ることができる．これは本来ページを開いてスクロールしながらユーザが注目したであろう箇所だけを，拾い読みできることを意味している．結果，VPクエリという軸から検索結果として得られた複数ページ内に存在する複数の話題に対して，横断的に閲覧することが可能となる．

2.1.4 文章的コンテキストの把握支援

従来のスニペットの様な文章的なコンテキストによる情報の有無の判断をより正確に行うことができる．例えば，どこかの入場料金を調べていた場合，その料金は「○○円」と表現されているとユーザは予想する．スニペットからもその様な表記を見つけることは可能であるが，それが大人のものか子供のものであるかなど，一体何の料金であるか不確実である．そこでVPを提示することで，従来のスニペットでは取れなかった検索クエリ前後の行の文章も把握することが可能になるため，より判断を正確に行える．

なお，卒業研究で行ったScoutView[6]では単一ページ内のみを対象としていたが，本システムでは検索で得られる複数ページに適用している点で異なる．

1Document Object Model (DOM) Specifications http://www.w3.org/DOM/DOMTR

(12)

第2章プロトタイプ 11

図2.1: プロトタイプ:ノートパソコンの寸法を調べる場合．仕様表の一部が表示され，

寸法に関する情報があることが分かる．

2.2 機能詳細

2.2.1 VP の生成方法

VPはページ内でVPクエリがある箇所の部分的なスクリーンショットであり，図2.2の様に検索から得られた複数のページからキャプチャされる．後述するマウスオーバーでの表示領域拡大

のために510px× 340pxのサイズで部分的なスクリーンショットをキャプチャし，提示の際には

300px ×200pxのVPとして中央を部分的に提示している．ページ内に複数VPクエリが存在する場合にはその数だけVPクエリが生成されることとなり，キャプチャの際にはVPクエリが中央となるよう調整される．ただし，VPの表示数を節約するため，生成済みのVPクエリの300px×

200pxの範囲にVPクエリが重複した場合には一枚のVPにまとめて提示している．

2.2.2 SERP における VP の提示

各検索結果のページからVPクエリ周辺の部分的なスクリーンショットであるVPを生成し，その一覧として検索結果を提示する．SERPでは，検索結果のページのタイトルとURLの一覧の下にVPの一覧が提示されることとなる．また，

1. 枠の色は検索結果タイトルの色と対応，

2. マウスオーバーで表示領域が1.7倍に拡大，

3. 特徴的な視覚的コンテキストでVPをソートするかどうかを選択可能，

という機能がある．ここで3つ目の機能については，DOM構造から著者の経験則により重要であると判断したVPが上に来るように設定されている．具体的には，VPクエリの存在する要素が，

<H1>のような見出し語になっていれば優先度が高い，URLのアンカーに入っていたり，VPク

エリのフォントサイズが小さければ優先度が低い，という様なものである．

(13)

図2.2: プロトタイプでのVP生成の様子．ここでは「寮」というVPクエリ周辺の一定範囲がVPとしてキャプチャされる．

2.2.3 VP の表示箇所までのナビゲーション

各VPをクリックすることで，その検索結果のページを別のタブに開き，対応する箇所までスクロールする．これにより，スニペット上にあった検索クエリのある場所をページを開いて探しなおす手間を省くことができる．

2.3 プロトタイプシステムの実装

PatchworkVisionシステムの全体像は図2.3の様なサーバ−クライアントシステムとなっている．

サーバ上の処理はApacheによるHTTPサーバとPHPが管理している．サーバ−クライアントシステムとしたのは，将来的にサーバ上でページのレンダリング結果の共有による処理能力の向上や，検索クエリからVPクエリを自動抽出するための学習用のユーザデータの取得を想定しているためである．

2.3.1 プロトタイプシステムの処理の流れ

処理の流れとしてはまず，クライアントサイドから検索・VP両クエリがユーザに入力され，サーバ上でそれらのクエリを受け付けて検索クエリからYahoo!検索API²より検索結果を取得する．

サーバ上のFirefox及びアドオンはVPクエリと検索結果のURLを受け取り，ページを開いてレンダリングする．次にVPの生成を行うために，開いたページでVPクエリを検索してそのオフセット座標を取得，図2.2の様に一定範囲内をcanvas要素としてキャプチャしてPNG形式のファイルとして保存する．そして，得られたVPとタイトルやURL等を検索結果としてユーザへ提示する．

2Yahoo!デベロッパーネットワークhttp://developer.yahoo.co.jp/

(14)

図 2.3: プロトタイプシステムの全体像

またクライアント上のFirefox及びアドオンは，「VPをクリックするとページを別のタブに開いて，その部分までスクロールする」という機能をVPに設置している．タブを開く際に必要なVP クエリ，URL，何番目に発見されたVPクエリか，という情報はPHPによる検索結果生成の段階

で<img>要素の属性に埋め込んでいる．これよりユーザはクエリを入力すると検索結果を取得し，

VPのクリックでページを開いて表示範囲までスクロールされる．

2.3.2 プロトタイプシステムの仕様

プロトタイプシステムの他の仕様として，

• VPクエリは1語のみで空の場合には検索クエリ末尾の一単語，

• コンテンツ内で見つかったVPクエリが隣接する場合には1つのVPとしてまとめて提示，

• Yahoo!検索APIからの結果上位5件のページに対してVPの生成，

という仕様があげられる．なお，サーバPCはIntelはPentinum4 2.53GHzとメモリ１GBを搭載している．

2.3.3 プロトタイプシステムでの VP のソート

視覚的コンテキストによるVPのソートについて述べる．VPのソートはVPクエリが存在するエレメント(以下，VPエレメントとする)のフォント情報とDOM構造的なその親エレメントに注目し，5段階のランク付けを各VPに対して行っている．なお，同じランク内のVPについては出現順序がそのまま適用される．ここでの出現順序は，ページは検索エンジンの上位の結果のVP 程上位に提示され，ページ内で先頭に出現するVP程上位に提示されることを意味している．

5段階のランク付けについては表2.1の様にした．なお，ランクは数値が低いほど上位である．

(15)

表 2.1: VPのランク付け

ランク VPエレメントのフォントと親エレメントのタグ名

ランク0 <H1>など見出し語となるもの

<TABLE>に関するもの(<TH>や<TD>等)でボーダーのある物フォントサイズがページのデフォルトのサイズより3pt以上高い物

ランク1 <STRONG>など強調表示されているもの

ランク2 <LI>や<DT>など箇条書きとなるもの

ランク1より大きいのランク付けのものでも太字のもの

ランク3 <TABLE>に関するもの(<TH>や<TD>等)でボーダーのない物ランク4 <A>,<CITE>

フォントサイズがページのデフォルトのサイズより3pt以上低い物

2.4 プロトタイプシステムの使用例

具体例を元にプロトタイプシステムの使用方法について説明する．ここで，ユーザの目標は「電気通信大学の寮についての解説が欲しい」という状況を想定する．

従来の検索エンジンでは，

Step.1 検索クエリの入力，

Step.2 SERP上でページを選択–タイトル，URL，スニペットを参考，

Step.3 ページ内で手動のスクロール，

という3つのステップが必要となる．

これと同様の手順であるが，プロトタイプシステムでは，

Step.1 検索クエリとVPクエリの入力，

Step.2 SERP上でページを選択–主としてVPを参考，

Step.3 VPの表示内容まで自動スクロール，

プロトタイプシステムでは，検索クエリの他にVPクエリを入力し，SERP上でのページの選択の際に主としてVPを利用して行う．従って，検索クエリにより検索した結果ページにVPクエリが含まれている必要がある．そのためには，所望の情報が記載されているであろうページ内に存在する単語を十分予測する必要がある．

また，SERP上でページを選択する際にはどのページに存在しているかというページの敷居に縛られず，VPによりページ内部での実際の見栄えを参考に所望の情報を探索することができる．なお，VPにより表示されている箇所に情報がありそうであれば，クリックによりそのページを開いて表示箇所までスクロールが自動で行われる．そのため，従来システムでの結果ページを開いて自らスクロールして，スニペットに記載されていた箇所を探し直す手間を省くことが可能である．

実際の検索の流れは以下の様になる(図2.4)．

1. 検索クエリとVPクエリの入力，

(16)

• 検索クエリ「電気通信大学寮」とVPクエリ「寮」として入力，

• 検索クエリが複数語の場合には末尾の単語がVPクエリとして採用されるため今回の入力ではVPクエリを入力しなくても同様，

• 「Search」ボタンをクリックすると検索が開始，

• ユーザは「寮」というキーワードが見出し語でフォントが大きくなっていたり，特徴的に表現されているであろうページに所望の情報があると予測，

2. SERP上でページを選択，

• 「Search」ボタンを押して数秒から数十秒待つと結果が提示，

• 上部に検索結果上位5件のタイトルとURLを提示，

• 下部にページ内の出現順にVPを提示，

• 枠の色とURLの色からページを識別可能，

• VPのマウスオーバーで表示範囲を拡大，

• VPのソートをONにした場合には順序はソート順に従う，

• 「寮」というキーワードが見出し語になっているVPがあるのでそこに所望の情報があると判断可能，

3. VPの表示内容まで自動スクロール

• VPクエリが検索バーに入力されてページ内でハイライト，

• VPをクリックすると別タブにそのページを開いて対応箇所まで自動スクロール，

• その箇所の記事を読むことで目標は達成される,

(17)

図 2.4: プロトタイプシステムの使用例

(18)

17

第 3 _{章予備実験}

プロトタイプシステムの評価について述べる．本システムを利用した3つの検索タスクを行い，

総合的な使用感を評価した．被験者は電気通信大学の学生9名であり，全員日常的にWebブラウジングを行っている．本実験は，クライアント側の環境として解像度1920×1200のディスプレイとIntel Core2 Extreme 3.0GHz とメモリ2GBを搭載したPC上で行った．

なお，今回従来システムである一般的な検索エンジンと比較評価を行わなかったのは，あくまでもVPを実際にSERPに提示した場合のユーザの印象を調査したかったためである．

3.1 予備実験のタスク

評価実験の主旨およびシステム説明の後，練習のためタスク1ではゴールと検索クエリとVPクエリを指定，タスク2ではゴールのみ指定，タスク3ではゴールを被験者自ら考えて検索タスクを実行させた．実際には表3.1の様にタスクを設定した．

3.2 _{予備実験のアンケート}

総合的なアンケートの他に各タスク完了後にどの様な情報が出てくると予想し，実際の提示結果にどの様な感想を抱いたかを口頭で説明させた．これはアンケートでのタスク完了後のまとめとしての感想以外に，操作時に実際どの様に感じたかを直接把握したかったためである．なお，アンケートでは表3.2の項目を被験者に記入させた．

表3.1: 予備実験のタスクタスク内容

タスク1 [ゴール]「電通大の寮の解説記事を探そう」

[検索クエリ]「電気通信大学」

[VPクエリ]「寮」

タスク2 [ゴール]「ノートPC(ThinkPad SL300)の寸法を調べよう」

[検索クエリ]ユーザ任意 [VPクエリ]ユーザ任意タスク3 [ゴール]ユーザ任意

[検索クエリ]ユーザ任意 [VPクエリ]ユーザ任意

(19)

表 3.2: 予備実験のアンケート

質問内容方式

各タスクのユーザ任意のゴール，検索クエリ，VPクエリ記述各タスクでSERPが提示される前にどのように情報が存在していると予想したか

記述

感想(良かったとこ，悪かったとこ，改善案，その他意見，を5つ) 記述

3.3 予備実験の結果

主な意見として，「ページの中身を視覚的に見ることができたのは良い」，「処理の時間が長い」，

「欲しい情報がより具体的な場合に有効」というものが得られた．

他の意見として「VPクエリの入力は手間なので自動で生成してほしい」，「知っているページだとより探しやすい」，「VPのサイズはちょうど良い」，「クエリが適切でないと欲しい情報が得られない」というものも存在した．

以上の結果より，所望の情報がより具体的に表現されている場合もしくは一度訪れたことのあるページを対象とした場合，VPによりコンテンツを視覚的に提示することは有効である．

これは所望の視覚的コンテキストがVPに表示されるか，あるいは既知のページが表示された場合，VPにより所望の情報の有無を判断する事が容易になるが，それ以外では判断できないためである．

また，「クエリが適切でないと欲しい情報が得られない」という意見については「一回の検索では検索エンジンの上位5件の結果を対象にVPを生成する」という現状の仕様が原因である．これは

「処理の時間が長い」という意見と同様に処理能力が低いことが原因であり，処理の効率化を検討する必要がある．

3.4 予備実験の考察

3.4.1 VP の生成方法についての検討

3.3節の評価から，従来のスニペットでは得られなかった視覚的コンテキストをVPにより提示することは有効であった．

VPの表示はあるキーワード周辺の固定の一定範囲のスクリーンショットである．しかし，これはVPクエリの視覚的コンテキストが取れる範囲を経験則的に決めたものであり，検討が必要である．実際に生成されたプロトタイプでのVPは固定サイズであるため，ページ内にて同じ段落の文章であっても少し横にずらした箇所に同じVPクエリが存在した場合には別のVPとして生成されてしまった．よって，固定サイズではなく各々のページのレイアウトを考慮した大きさのVPを提示する必要がある．

ページのレイアウトは幾つかのペインで切り分けることができる．例えばウェブログページの場合，上部のペインはタイトル，左右のペインは著者プロフィールや他サイトのリンクや過去の記事へのリンクや広告，中央のペインには本来伝えたい記事が書かれている．たとえVPクエリが存在したとしても，メニューの中や他サイトへのリンクや広告の中にある場合にはそれをVPとして提示することは，ユーザにとって有益であるとは考えられない．そのため，本来の伝えたい記事である中央のペインから見つかったVPのみを提示し，余計なVPの表示を省く必要がある．

(20)

第3章予備実験 19

さらに中央のペインについても文章の段落，表，画像の表示，で幾つかのより細かいまとまりに分けられる．そこでVPの表示として，VPクエリ周辺を固定範囲で抜き出すのではなく，ページ内でVPクエリの存在するペイン単位でVPを生成する．このようにすることで，キーワードのある場所単位でなくキーワードのあるペイン単位で提示することができる．また，ペイン単位ではコンテンツのトピックもある程度まとまっていることが期待でき，トピック単位でページを断片的に把握することが可能となる．VPは従来のサイズに戻るように縮小してユーザに提示し，マウスオーバーした際には原寸大の大きさに拡大するよう提示する．これは複数のVPを提示する際に形が不揃いになり，一覧性が低下してしまうのを軽減し，必要に応じてVP内の文字も読むことを可能にするためである．これにより一覧性を保ちながら視覚的コンテキストを把握でき，かつマウスオーバーにより文章的コンテキストも十分把握可能となる．

3.4.2 SERP 上での VP の列挙方法

3.3節の評価より本システムが「知っているページだと探しやすい」という意見を得たのはVP の情報としての信頼性によるものであると考えられる．一度訪れたページではVPに表示された箇所が自分の求めていた場所か容易に判断を行うことができ，そうでない場合にはそれが困難である．

現状のシステムではページ単位でなく，VP単位での検索結果の提示となっている．従来のスニペットと同様にタイトルの下に配置することも検討したが，どのページにあるかは重要でないと考えた．これはすべてを混合し視覚的コンテストとして特徴的なものでソートをかけることで，複数のページ内の複数の話題の中からより容易に目標を達成できると考えたためである．その結果，

ページを跨いだ一覧性を保ちながら所望の情報を探すことが可能になった．

しかし，VPがどのページから作られたものであるか示さなかったため，その情報の信頼性を確保することができなかった．VPの枠の色で結果ページとの対応を提示したが，これはあくまで同一のページ内のVPであるかどうかの判断に役立てるためのものであった．

これは何か商品の仕様を検索する場合，公式ページと商品レビューサイトやウェブログといったページでは情報の信頼性が異なるということである．従来のスニペットではその上にタイトルが存在したため，信頼性を確保することができた．

よって，VPがどのページのものであるかを明確にし，その信頼性を確保するためには従来のスニペットと同様に提示する必要がある．また，ページ間での一覧性を確保するためにVPの表示数を一定の重要度で制限し，残りのVPはクリックされたら全てを表示する等の提示方法へ変更する必要がある．

3.4.3 視覚的コンテキストの順序付け

現状のシステムでの視覚的コンテキストによるソートは著者の経験則によるものであり，検討が必要である．VPクエリのHTML要素を調べることで視覚的コンテキストを機械的に認識している．具体的には2.3.3節の様に決定している．これは例えば，「表の一部」であれば<td>要素，「見出し語になって強調表示されている」であれば<h1>や<h2>要素，などの様に認識している．

そして，見出し語や表の一部であることよりもリンクの一部に表示されている方の重要度が低く，表でもレイアウトのために使われている枠線のないものは重要ではないという様に重要度を算出している．

そもそも視覚的コンテキストがどの様なものであるかあくまで著者の主観であり，一般的な認識としてどの様なものがあるか検討がなされていなかったと言える．

(21)

3.4.4 処理速度

3.3節の評価より処理時間が長いことが問題としてあげられている．現状では一回の検索で約10 秒程度かかる．本システムは本来検索エンジンと同様に実装し，VPの生成はユーザが検索をする前に行われているのが理想であるが，今回は実装の都合上評価のための試作としてリアルタイムに VPの生成を行っている．

そこで，従来の検索エンジンと同様にページを前もってクローリングし，インデックスを作成，

検索結果を提示するといった方式での実装が必要であると考えられる．そのためには，このクローリングの際にページ全体のキャプチャと含まれる単語のオフセット座標を計算しておく必要がある．

結果の提示の際にはページ全体の中からVPに該当する箇所だけ切り抜いて表示を行う．この様にすれば，容量は増えてしまうが多数のファイルを通信する必要がなくなり，またVP上のドラッグを行うと表示箇所を移動，すなわちパンニングさせるといったことも可能となる．

さらに，まずテキストの検索結果を表示し，Ajaxにより非同期にVPをロードすることでユーザの体感待ち時間は軽減される．これは現状の実装方法においても有効である．特に本システムは具体的な検索に特化しており，そうでない検索の際にまでVPを表示しておく必要がない．そこで，テキスト情報を見て実際の表示を見たい場合にはボタン等を設置し，それをクリックした際にのみVPを表示すると効果的である．

(22)

21

第 4 _{章提案システム}

4.1 設計

プロトタイプの設計及びその評価からシステムを提案する．

主な変更点としてプロトタイプでの考察から，

• 3.4.2節より，SERP上でのVPの列挙方法をVP単位からページ単位に変更，

• 3.4.1節より，VPの生成方法を固定サイズからページのペインを考慮したサイズで生成，

• 3.4.1節より，VPのマウスオーバーで表示領域拡大から予め縮小しておきマウスオーバーで

原寸大へ拡大，

という点が挙げられる．なお，その他のプロトタイプと同様の点は2.1節を参照．実際のシステムとしては図4.1の様になった．

VPの列挙方法としては，従来のSERPの各結果の下にVPを追加して提示する．この様に検索結果をVPとして列挙するのではなく，ページのタイトル，URLそしてスニペットと共にその下にまとめて提示することで，そのVPがどのようなページの中にあるものかを識別し易くした．なお，タイトルとVPの枠の色を対応させることで，ある結果ページについてのまとまりが把握しやすくなっている．

次に，VPの生成方法についてはページ内のレイアウトを考慮したペイン単位のサイズで生成する．これによりページの内容をよりトピック単位で認識でき，かつ提示するVP数を省くことができる．詳細については4.2.2節で後述する．

そして，VPのサイズをペイン単位にしたことでVPは大きくなってしまったが，一覧性と可読性を損なわないためにまず縮小してVPを提示して視覚的コンテキストを把握し，必要に応じてマウスオーバーで拡大して内容を読めるようになった(図4.2)．

4.2 _実装

4.2.1 概要

プロトタイプの実装からの変更点として，

• サーバ上のFirefoxアドオンでのVPの生成方法，

• PHPによる検索結果の提示方法，

• Yahoo!検索APIからの結果取得件数を上位5件から10件に変更，

(23)

図4.1: PatchworkVision:大学の寮についての解説記事を探す場合．

，という点が挙げられる．VPの生成については次節で述べる．PHPでの処理については大きく2 つの変更点が挙げられる．1つ目は，VPの列挙方法の変更に伴うSERP上でのタイトル，URL，

スニペット及びVPの提示順序を結果単位で整列することである．2つ目は，生成されたVPを予め縮小して提示し，マウスオーバーで原寸大に拡大させることである．

なお，2.3節のプロトタイプと根本的な処理は同様であり，

1. クライアント上でユーザが検索クエリ，VPクエリを入力，

2. サーバ上のCGIが検索クエリからYahoo!の検索結果上位10件を取得，

3. 結果ページをサーバ上のFirefoxで開く，

4. アドオンにてVPクエリからVPをPNGファイルとして生成，

5. CGIが結果を提示，

6. クライアント上のアドオンがユーザのVPクリックを検知して表示内容へのスクロール，

(24)

図 4.2: マウスオーバーでVPが拡大する様子．

という処理の流れとなる．

4.2.2 ペインに沿った VP の生成

例えば，結果ページ¹ にてVPにクエリ「円」の場合(ここでのゴールは「ニンテンドー3DSの価格を調べる」)，ペインに沿ったVPを生成は図4.3の様に，

1. ページをペインごとに分割し，VPクエリの存在するものを抽出(図4.3a)，

2. 抽出したペインが大きすぎる場合にはVPが存在する箇所で分割(図4.3b)，

3. VPとして保存(図4.3c)，

という流れで生成される．

具体的な手順としては，まずFirefoxのページ内での「検索」機能を利用して，VPクエリが見つかった箇所のelementを取得(以下，VPエレメントとする)してハイライトする．そして，そのVPエレメントのJavaScriptによるoﬀsetParentプロパティによりオフセット位置によるDOM における親elementをペインとしている．本来ならば親elementを求めるにはparentNodeプロパティが用いられるが，ここでoﬀsetParentを用いたのはあくまで配置上の親elementを取得する必要があったためである．これは例えば，ハイライトされた親elementが<SPAN>や<FONT>の場合には，親elementとハイライトされたelementの位置は変化しない．しかし，これが<DIV>

や<TABLE>等であれば，レイアウトが変化し，位置が変化することとなる．この様にオフセッ

ト座標が変化するelementを親として取得するために，oﬀsetParentプロパティを用いている．

ペインの大きさのしきい値としては高さが1000pxとし，大きすぎる場合にはそのペインから部分的にVPを分割することとなる．分割時にはVPの幅はそのペインの幅となるが，高さは状況

1 http://gigazine.net/news/20100929 nintendo 3ds chart/

(25)

により異なる．VPが1つならばそのペインの幅で上下各100pxのマージンを持ってVPが生成され，複数存在する場合にはその集まりで座標の最小値から最大値までが含まれるような高さに上下各50pxのマージンを持ったペイン幅のVPとなる．当然同じペイン内に複数の箇所に寄ったVP クエリの集まりが出来ることが想定されるが，VPクエリ間の距離が200px以上離れた場合には別の集まりとみなしている．なお，VPが生成されるサーバ上のFirefoxのウインドウサイズは1024

×800としている．

また処理速度の向上のため，サーバPCをプロトタイプシステムを稼働していたものから，Intel Core i7 2.8GHzとメモリ4GBを搭載したPCへと変更した．

図4.3: 提案システムにおけるVPの生成される様子．結果ページの薄い赤色の部分が VPクエリの含まれる箇所となる．

4.3 提案システムの使用例

具体例を元にプロトタイプシステムの使用方法について説明する．ここで，プロトタイプの場合と同じくユーザの目標は「電気通信大学の寮についての解説が欲しい」という状況を想定する．

(26)

プロトタイプシステムと同様の手順であるが，提案システムでは，

Step.1 検索クエリとVPクエリの入力，

Step.2 SERP上でページを選択–ページのタイトル，URL，スニペット，そしてVPを参考，

Step.3 VPの表示内容まで自動スクロール，

提案システムではVPを結果ページごとに提示するようにしたため，そのVPがどのようなページの中に存在するものであるかをページのタイトルやスニペット等から容易に判断することができる．そのため，3.4.2節で述べたようなVPの信頼性を向上させている．

また，VPは予め縮小されており，ユーザが必要に応じてマウスオーバーで拡大することができる．結果，表示量の節約による結果の一覧性を向上させている．これはVPとして提示される範囲がプロトタイプよりも比較的大きいものとなってしまったが，視覚的コンテキストがあくまで画像情報であり，その特性である縮小しても概観を捉えることが容易なことを利用しているためである．

そして，新しいVPの生成方式の適用により，よりページ内の内容にそったサイズでのVPを提示している．これはページ両サイドの，サイト内のナビゲーションや広告などを除外するだけでなく，キーワードが集中している箇所にはそれに関する話題の文章や画像が記載されている可能性が高いであろうと予測できるためである．

実際の検索の流れは以下の様になる．

1. 検索クエリとVPクエリの入力，

• プロトタイプシステムと同様，

• 検索クエリ「電気通信大学寮」とVPクエリ「寮」として入力，

• 検索クエリが複数語の場合には末尾の単語がVPクエリとして採用されるため今回の入力ではVPクエリを入力しなくても同様，

• 「Search」ボタンをクリックすると検索が開始，

• ユーザは「寮」というキーワードが見出し語でフォントが大きくなっていたり，特徴的に表現されているであろうページに所望の情報があると予測，

2. SERP上でページを選択(図4.1及び図4.2)，

• 「Search」ボタンを押して数秒から数十秒待つと結果が提示，

• 上部に検索結果上位10件のタイトル，URL，スニペット，そしてVPを提示，

• 枠の色とURLの色からページを識別可能，

• 予め縮小されているVPはマウスオーバーで大きさを拡大可能，

• 右端に縮小されていても「寮」というキーワードが見出し語になっているのが分かる VPが存在する，

• そのVPにマウスオーバーし，そこに所望の情報があると判断可能，

3. VPの表示内容まで自動スクロール

• VPクエリが検索バーに入力されてページ内でハイライト，

(27)

• VPをクリックすると別タブにそのページを開いて対応箇所まで自動スクロール，

• 拡大されたVPから十分ゴールは達成できたが必要に応じてページを開く，

• 関連する周辺情報などが把握可能，

(28)

27

第 5 _{章評価}

5.1 方法

提案システムの評価について述べる．本システムを利用した3つの検索タスクを提案システムと従来の検索エンジン(Google¹)を用い，タスク達成時間と使用感を評価した．被験者は電気通信大学の学生８名であり，全員日常的にWebブラウジングを行っている．本実験では，クライアント側の環境として解像度1920×1200のディスプレイとIntel Core2 Extreme 3.0GHzとメモリ 2GBを搭載したPC上でタスクを実行させた．

なお実装の都合上，検索にかかるシステムの処理速度は従来の検索エンジンと大きな開きがある．そのため検索・VP両クエリを入力して検索結果が表示されてからタスクが達成されるまでの時間を測定した．時間の測定方法としてはブラウザのステータスバーに設置したストップウォッチボタンを利用している(図5.1)．実際の操作としては，結果が表示されたら被験者は「Start!」ボタンをクリックし，被験者がタスクを達成したと判断したら「Finish!」ボタンをクリックすることとなる．これにより，SERP上での実際に検索にかかる時間のみを測定できるものと考えられる．

図5.1: 時間測定に用いたブラウザ右下に追加したストップウォッチボタン

5.1.1 評価実験のタスク

予備実験と同様に，評価実験の主旨およびシステム説明の後，2つのシステムを使ってそれぞれ 3つのタスクを実行させた．練習のためタスク1ではゴールと検索クエリとVPクエリを指定，タスク2ではゴールのみ指定，タスク3ではゴールを被験者自ら考えて検索・VP両クエリも自身で考えさせた．なお公正を期すために，システムの利用順序を半数の被験者ずつ入れ替えている．半分の被験者にはGoogleでタスク1から3を実行してからPatchworkVisionでタスク1から3を実行させ，もう半分の被験者には逆にPatchworkVisionでタスク1から3を実行してからGoogleでタスク1から3を実行させた．

実際には，表5.1のようなタスクを設定した．

その他の評価実験の仕様として，タスク内容を被験者に説明する際に被験者へ，

• ゴールが達成できたかどうかは自己判断，

• Googleで得たゴールの結果と提案システムで得たゴールの結果は同じである必要はない，

1http://www.google.co.jp/

(29)

表5.1: 評価実験のタスクタスク内容

タスク1 [ゴール]「電通大の寮の解説記事を探そう」

[検索クエリ]「電気通信大学」

[VPクエリ]「寮」

タスク2 [ゴール]「スマートフォン(galaxy s)のmicroSDの容量を調べよう」

[検索クエリ]ユーザ任意 [VPクエリ]ユーザ任意タスク3 [ゴール]ユーザ任意

[検索クエリ]ユーザ任意 [VPクエリ]ユーザ任意

• スニペット及びVPでゴールが達成できた場合にはページを必ずしても開く必要はない，

• 検索・VP両クエリを入れなおして検索する場合には測定時間をリセット，

という点を説明した．

タスク1や2では著者が被験者にゴールを強制しているが，本来調べ物検索は自発的に行われるものであるため，可能な限り指定した箇所以外の判断は被験者の自己判断に任せた．なお，4つ目の再検索における測定時間のリセットについては，本研究では検索クエリの最適化はその対象に含めてはおらず，あくまで検索結果上位10件の中に所望の情報が含まれるという前提で評価実験を行ったためである．

5.1.2 評価実験のアンケート

タスク達成後，被験者にシステムの使用感について4段階のリッカート尺度([強い否定]1-4[強い肯定])および記述方式で質問した(表5.2)．また，各タスクのユーザ任意のゴール，検索クエリ，

VPクエリ，及びタスク達成時間についても記入させた．

5.2 評価実験の結果

5.2.1 タスク達成時間

3つのタスクを達成するまでにかかった時間は以下のようになった(図5.2)．なお，図5.2におけるエラーバーは標準偏差により求めている．

タスク達成時間は個人による差が大きいため，統計的に有効性を検証する．各タスク達成時間に

対してWilcoxonの符号付き順位和検定を有意水準5%の片側検定として行った．その結果，タス

ク1では提案システムの有意差を確認できなかったが，タスク2及びタスク3では有意差を確認できた．

またタスク3について，ユーザ任意のゴールとしては「ニンテンドー3DSの価格」という様な製品の価格やスペックを調べるものが多かった．

(30)

第5章評価 29

表 5.2: リッカート尺度方式の評価実験のアンケート

問質問内容方式

問1 どちらが使いやすいと感じたか([Google]1-4 [PatchworkVision]) 4段階リッカート問2 VPをSERPに提示することは有効であるか 4段階リッカート問3 VPはページの中身を識別するのに役にたったか 4段階リッカート問4 VPの提示でページの中身を吟味して探せたと感じたか 4段階リッカート問5 スニペットとVPは両方あるべきか?片方だけの方がよいか? 記述問6 VPの提示により結果の一覧性(位置画面に表示できる結果数)がさ

がることについてどう思うか?

記述

問7 VPの表示内容に要望があれば(サイズ，表示して欲しいもの) 記述問8 今後のこのシステムを使ってみたいか? 4段階リッカート

問9 システムの良かった点と悪かった点記述

問10 その他何かあれば記述

5.2.2 評価実験のアンケート

問1から4，8の4段階のリッカート尺度を用いて質問したアンケートの結果については図5.3 の様になった．問5から7，9，10の記述式の質問の主な回答は表5.3の様になった．

5.3 評価実験の考察

5.2節により得られた評価結果から考察について述べる．

5.3.1 従来手法との比較

問1から4,8よりVPの提示は被験者とって好印象であり，またタスク達成時間からその短縮が可能となることが分かった．タスク2,3でのタスク達成時間が提案システムの利用により従来手法より短縮できたことが分かる．タスク1については練習のためのタスクであったが，それも同程度の時間でタスクを達成することができている．これにより結果ページにおけるVPにクエリの視覚的コンテキストを示すことは検索タスクを達成する上で有効であると言える．VPの提示によりページ内で所望の情報が存在するであろう箇所を即座に把握でき，ユーザの調べ物検索における負荷を軽減できた．

しかし，問7の要望や問9の「悪かった点」などから，提案システムの不満点としてプロトタイプの時と同様システムの処理が遅いという意見が存在した．これは本論では実装の都合上困難であるため，VPが提示されるまでの処理時間は評価に含めなかったが，3.4.4節の様に対処する必要がある．

5.3.2 VP とスニペットの両立

問5と6より，VPと従来のスニペットを共に提示することで各結果の一覧性が下がってしまうことについて被験者から不満の声は存在しなかった．むしろ，結果ページを別途開く必要がないな

(31)

図 5.2: 評価実験におけるタスク達成時間

図5.3: リッカート尺度を用いたアンケートの結果

らば，情報量は多い方がよく，VPにより十分所望の情報が存在するページもしくはそのものを見つけられるならば長くなっても問題ないという意見が多かった．

しかし，VPの提示における問題点として，従来のスニペットによりもVPは被験者の目を引いてしまうため，SERP上の情報を十分に把握するには慣れが必要であると2人の被験者は回答した．これはVPが画像であるため，被験者は反射的にテキストスニペットより優先的にVPを見てしまうためである．また，従来の検索の手順とは異なり，ページ検索の後でページ内で検索するためのキーワードであるVPクエリをページを選択するための検索の段階で指定する必要があるためである．

また，VPの提示のためには検索クエリをより具体的に指定し，さらにVPクエリを指定する必要がある．本システムの想定は調べ物検索のような所望の情報がより具体的な状況を想定しているため，検索に用いるキーワードを詳細に指定することはそもそも必要不可欠なことであった．しかし，これがユーザへの負荷となってしまっており，これを支援する必要がある．

(32)

第5章評価 31

表5.3: 記述方式のアンケートの結果問主な回答

問5 「両方いる」(5人)，「画像にすぐ目が行ってしまうのでVPだけ」

(2人)，「選べるとよい」(1人)

問6 「気にならない」(8人)，「VPで探せればよい」

問7 「Amazonなどの商品画像を提示して欲しい」

問9 良い点：「ページを開かなくていい」(5人)，「無駄な広告を見なくてすむ」，「VPをクエリのハイライト」

悪い点：「処理時間が遅い」(3人)，「検索クエリを多く指定する必要がある」，「VPクエリの指定が困難」，「VPの縮小率が高すぎて一つ一つ確認する必要がある」

問10 「慣れが必要」(2人)，「拡大したVPをスクロールしたい」，「Google で見つからなかった場合に価値がある」，「直接的な単語で探せるのがいい」

5.3.3 新しい VP の提示方法

問2から4のVPにより十分結果ページの中味を吟味して検索タスクを行えている点から，提案システムへのVPの提示方法の変更は有効であったと言える．

ペイン単位でのVPの生成については，一人の被験者は「サイズが的確であり，広告等不要な箇所を閲覧しなくていい」という意見を述べており，これが有効であったことを示している．これは問9の利点として「必ずしもページを開かなくてもよい」という意見が過半数以上から出ていることからも言え，プロトタイプでの固定サイズのVPでは結局ページを開く必要に迫らてしまっていたが，提案システムではよりVPの提示方法は的確な物となったと言える．

また問7から，ユーザの要望として商品に関する価格のページについて，「商品の写真を提示して欲しい」という意見があった．現状VPはVPクエリという単語を軸として提示しているが，従来のスニペットのように結果ページのサマリとなるような画像をVPとし提示することにより，よりユーザにとってページの内容を吟味しやすくなると考えられる．これは後述する関連研究[2][5]

の様にページ内のロゴや商品の画像など特徴的な画像を抽出して視覚的なスニペットとして提示する手法を採用することで実現できると考えられる．

さらに，上記の「VPの提示は選択できるべきである」という意見とともに，「VPが縮小されすぎている」という意見が存在した．これらの意見から，VPの提示として縮小率や表示すべき物をある程度ユーザ毎に設定できるべきである．

現状のVPの生成における実装について，VPはページ内のVPクエリに関わる箇所を把握するために十分有効なものとして生成できたと言える．しかし，人の目で見えるペインの区切りを完全に再現できたとは言えない．人の目で見えるペインの区切りは極めて意味的なものである．検索結果となるページでのそれをHTMLやCSS等で表現するための手法は不揃いであり，それらのページそれぞれの表現手法は異なるためである．

(33)

第 6 _{章関連研究}

6.1 サムネイルを利用したシステム

検索結果におけるスニペットを視覚的なものとして提示するための関連研究について述べる．検索対象の見栄えを提示するためにサムネイルは有効である．ページのサムネイルからは，リンクを開く前やタブを切り替える前等，表示を切り替える前に実際の表示を確認できる．そのため，ユーザが見たいと思ったページの選択に効果的である．

一般に使われているシステムとしてFirefox¹アドオンのSearchPreview²があげられる．SERPにおいて，各ページの先頭一画面分サムネイルをタイトルやスニペットの横に提示している（図6.1）．

これにより，ユーザは視覚的にページを選ぶ事ができる．過去訪れたことのあるページ，ページが自動生成されレイアウトが同様の物となる同一のWebサービスの場合には，このようなサムネイルを提示することで，そのページを見るべきかどうかの判断ができるためである．

図6.1: FirefoxアドオンのSearchPreview：SERP上に各結果のサムネイルが提示されている．

6.2 意味的なサムネイルを利用したシステム

前述の様なサムネイルでページの概観を取得することはできるが，それからページの中身についての詳細を得ることはできない．しかし，サムネイルは縮小表示のため，ページの詳細な内容を把握することはできず，この様に過去に訪問したページかデザインが共通のWebサービスであるか

1Mozilla Firefox http://mozilla.jp/firefox/

2SearchPreview https://addons.mozilla.jp/firefox/details/189