「いい検索」を考える

内田臣了氏(以下、内田):よろしくお願いします。「いい検索を考える」というタイトルで、リクルートテクノロジーズの内田が発表いたします。

まず自己紹介なんですけども、内田臣了(しんりょう)です。

けっこう珍しい名前だと言われます。2017年に株式会社リクルートに新卒で入社しまして、今はリクルートテクノロジーズというところで、リクルートグループの運営するWebサービスの検索改善業務をやっております。大学時代も情報検索をやっていました。

先に2点、お詫びしたいことがあって。1点目が、風邪をひきました。なので、聞き苦しかったら本当にすみません。2つ目なんですけど、資料を気合を入れて作りすぎて、内容が多いです。なのでちょっと早口で喋ります、すみません。

今日の内容なんですけれども、話すことは情報検索の基礎知識と、もう1つ、サービスの「いい検索」をデザインする上で考えることについてです。どちらかと言うと、手法というよりは思想の話をします。

一方で、話さないことなんですけれども、「リクルートでどういうことをやってるの?」というサービス事例は喋りません。もう1つ、検索エンジンについて、ElasticsearchとかSolrとか、検索エンジンについても今回は喋りません。では、始めさせていただきます。

そもそも検索とはなにか?

まず「いい検索」の前に、「検索とは?」という話をしたいと思います。

(スライドを指して)これは本に書いてあった定義なんですけど、「情報検索は通常、コンピューターに格納されている大規模なコレクションから、必要な情報を含む非構造的な資料を見つけることである」と書いてあります。どういうことだという話ですよね。

幼稚園児でもわかるような図を用意してきました。必要な情報ということで、この人はこのワンちゃんについて知りたいとします。図書館みたいなところに大量の本があったとして、その中からズバリ、この犬についての資料を見つけることができる。これが情報検索です。ひと言で言うとそうなります。そんな情報検索を実現する手段が、我々が日ごろ作っているような検索システムになります。

例えば、(スライドを指して)こういう博士みたいなシステムがいて、ユーザーに対して「あなたは何を探してますか?」と聞くとしましょう。人間も「私が探してるものは茶色い犬です」というような入力をします。そうするとこの博士が、大量のコレクションの中からいくつか候補を探してきて、それをユーザーに出します。

「この中にありますか?」と、(スライドを指して)こういう見せ方をしたとしましょう。ユーザーのほうも、その中に自分が探していたものがあれば、「それだ!」と見つけることができるというのが、検索システムの簡単な流れになります。

さっきのインタラクションの一連の流れを簡単に表すと(スライドを指して)こうなるんですけども。ユーザーが検索システムに対して「こういうものがほしいです」と入力を行います。すると検索システムは、持っているコレクションの中から、それに相応しいものを探してきます。最終的にユーザーに「この中にありますか?」というような見せ方をします。

何が言いたいかというと、2つの要素から成り立ってるということが言いたいのです。

「検索」というと、こっちを想像する方がいると思います。大量のコレクションの中から適切なものを引っ張り出してくる。フィルタリングとかランキングとか、アルゴリズムについてのところがよくイメージされる「検索」かなと思います。

それだけじゃなくて、ユーザーと検索システムの間のインタラクションを司る部分であるユーザーインタフェースも考えないといけません。

なので、検索システムというのは、フィルタリング・ランキングのアルゴリズムと、ユーザーインタフェースの2つを改善していくことで、「いい検索」を作っていくのが目標になります。

フィルタリングとはなにか

まず、フィルタリングの話をします。ひと言で言うと「莫大な候補から探したいものを絞り込む機能」になります。ズバリ、ユーザーが探している情報だけを過不足なく見つけられれば、本当に最強のフィルタリングです。

ですが、現実はそんなに甘くない。探している情報と検索の結果は、だいたいズレますね。なので、(スライドを指して)この四角が全ドキュメントの集合だとすると、検索システムはその中の一部を検索結果として返します。この青い丸の部分ですね。

「僕はこういう情報がほしいんだよなぁ」という、ユーザーが求めているドキュメントの集合があり、これが完全に一致すると最強なんですけど、だいたいズレてしまいます。じゃあ、ズレがあるんだったら、どれくらい一致しているかということで、フィルタリングの質を評価することができます。

本当に頻繫に使われる指標なんですけども、よくフィルタリングの評価に用いられる「適合率」と「再現率」を紹介します。

適合率というのは検索結果に含まれる正解の割合です。この青丸のうち、重なっているオレンジの部分がどれくらいあったかという割合が、適合率になります。もう1つ、再現率は、このユーザーが求めているドキュメントがあったとして、その中のどれくらいを検索結果がカバーしたかというものになります。

この適合率・再現率というのは頻繫に出てくる指標だと思います。なので、これら2つを高めていこうというのが、検索改善のステップになります。

適合率を上げるためにできること

じゃあ、適合率を上げるために何をしましょうか。いっぱいあるんですけども、ここで簡単にご紹介しておくと、クエリの意図推定というものがあります。

「アップル お菓子」と入れたら、この「アップル」は「りんご」のことだろうという意図推定を行う。そうすることで、世の中にある「アップル」という名前が付いているものの中から、「りんご」というものに対して絞り込みを行うことができます。

同様に「アップル 株価」だったら、この「アップル」は会社の「Apple」だなという絞り込みを行う。こういう意図推定を行う方法が1つあります。

もう1つ、例に挙げているんですけども、パーソナライズという手法です。どういう人が探しているかに注目する手法で、例えば、この人が渋谷区にいるとしましょう。「カフェ」と検索しました。探したいものはきっと「渋谷近辺のカフェ」なんだろうということで、カフェの中でも「渋谷近辺にあるカフェ」という絞り込みをする。そうすることで、適合率を上げることができます。

ほかにも、例えばこの人の年齢や、今までどういう検索をしてきたかの履歴を使う。そういったことで、パーソナライズを行うことができます。

もう1つ、再現率を上げるためにということで、ここで2つ紹介します。

1つ目が「同義語展開」と呼ばれるものです。例えば「PC」で検索したときに、「PC」だと「PC」と書かれている文書しか見つからないんですけど、ここで言う「PC」というのは「パソコン」のことでしょう。さらに言うなら「パーソナルコンピューター」のことでしょうということで、検索対象を広げてあげることで、よりユーザーが探したがっている情報を広く集めてくることができるようになります。

下の「クエリ正規化」という例も挙げています。例えばこういう……すごく雑な例なんですけど、「Made in JAPAN」と大文字で書かれていたり、全角だったりするものがあったとします。それを検索のときには、全部小文字で半角の「made in japan」に合わせてあげることで、書き方によって一部の結果が見つからないということを防げます。

適合率と再現率はトレードオフ

ここで注意しないといけないことは、さっき「適合率と再現率、両方上げていくことが検索のアプローチだ」と言ったんですけど、これら、一般的にはトレードオフの関係にあると言われています。なので、どちらかが上がるともう片方は下がりやすいという関係にあります。

これは例なんですけど、本当に極端なことを言ってしまうと、ユーザーが求めているドキュメントの中で1個だけ当てるというのは、そんなに難しくないと思います。なので、1個当てたら、1/1で当たったので「適合率は100パーセント、最大です」と言うことができる。でも、所詮1個しか返していないので、この場合の再現率はかなり低くなってしまいます。

もう1つ、極端な例だと、今回はなにも絞り込みません。絞り込まなかったときは、ユーザーが求めているドキュメントをすべてカバーするので、再現率は100パーセントになります。ですが、適合率がかなり小さくなってしまう。

だいたいそういう関係にあるので、検索結果の数を増やしながら、なるべくかぶっている部分を保ちつつ広げていくのが大事になります。

そのバランスの取り方なんですけれども、「F値」という概念をご紹介しておきます。

数式とかは全部省いちゃったんですけど、「適合率と再現率の重み付き調和平均」です。詳しい定義は調べてください。適合率と再現率が両方とも高いときに高くなるような平均の取り方をしてあります。

どっちを良くしたらどっちが下がるというバランスを考えるのが面倒くさいというときは、このF値という概念を計算してあげて、検索改善していくのがいいのではないかと思います。

では、フィルタリングのまとめです。

ユーザーが探している情報とシステムの検索結果が完全に一致すると最強です。その中の評価指標として、適合率と再現率というものをご紹介しました。フィルタリングの質を高めるために、このような手法があります。

最後に、適合率と再現率はトレードオフなので、F値というバランスを取るための指標を考えてあげるといいんじゃないかということで、フィルタリングを締めさせていただきます。

ランキングの評価指標

次に、ランキングです。ひと言で言うと「フィルタリングしたものを並び替える機能」になります。GoogleのようなWebサイト検索だと、100万件出したとしても、せいぜいランキングの上位数件しか閲覧されないことが多いという調査結果もあったりします。

なので、本当にランキングというのは大事で、探しているものをいくつ上位に含めることができたかが、ランキングの評価基準になります。探しているものが上位に入っていると、それはいいランキングであると言えます。

キーワードとの一致度や、時系列順に並べるなど、サービスによってどれが一番優れているかは変わります。ここは、本当に喋ろうと思えば無限に喋れちゃうところなんですけど、今回、ランキング手法については割愛させていただきました。

ランキングの評価指標についてご紹介します。

すごく簡単な例では、「Precision@k」というものがあります。これは、検索結果の上位k件だけで考える適合率です。例えば、探しているものを〇、探していないものを×とします。(スライドを指して)表の一番左の例だと「〇××〇〇」でした。つまり、5個のうち探しているものが3つあったので、「Precision@5は3/5」です、という計算をするやり方ですね。

すごく単純なやり方で気軽に扱えるのでいいと思います。ただ、順序をまったく考慮していない手法なので、例えば探しているものが3位にあった場合と5位にあった場合で、Precision@5は両方とも1/5になります。なので、順位をなるべく上に出したいという要求があるのであれば、これを使うのは適切ではないということです。

次に、上位の中でも何位に出たかを反映したいのであれば、ということでランキング評価指標の「MAP」を紹介します。

これは、探している文書が上に出れば出るほど高スコアになるような式になっておりまして、今回も数式は割愛したんですけども、基本的に上に「〇」が来ていれば高スコアになります。

計算のやり方を簡単にお話しすると、「〇××〇〇」だったとしたら、まず最初の〇が出たところまでで適合率を計算します。これは1/1です。次に、2つ目の〇が出たところまでで適合率を計算します。これは4位までの中で2個〇があるので、2/4です。3つ目についてもやりましょうということで、すべての適合文書について計算を行って、1つのランキングのAPと呼ばれるものを計算します。平均適合率(Average Precision)ですね。

それをいろんな検索で計算してあげて、最後にまとめて平均を取ることで、MAPが計算できます。

NDCGとMMR

ここで、「探しているかどうかを〇×だけでは決めきれないよね」という話もあると思います。僕は、この一番をめちゃくちゃほしかった、2個目は大してほしくなかった、みたいなかたちです。点数付けがしたいよね、という要求もあると思います。

そのときに使える指標が、NDCGというものです。

関連/非関連の2値だけじゃなくて、段階的な関連度を考慮することができます。例を挙げます。Aというものは10点付けて、Bは8点、Cは5点、Dは2点付けて、並べ替えたら(スライドを指して)こうなりました。

このときに、NDCGでは上位から下位にいくにつれて重みが少しずつ減っていくようなものを設定しておきまして、この点数と重みを掛けて、すべて足し合わせてあげます。そうして得られるスコアが12.7だとしましょう。それが、今回のランキングだとします。

もう1つ、点数の降順に並べるようなものも考えたとして、(スライドを指して)こういう理想順のときは、こういう点数でしたとなると、これらを比べてあげることで、最終的なスコアを出す。これがNDCGとなります。詳しくは調べていただけるといいかと思います(笑)。ここでは簡単な紹介に留めさせていただきます。

MAPやNDCGは、上位に関連文書が多く来れば高スコアになるんですけども、必ずしもそれが求められているものかというと、そうでもないこともあります。

例えば「ナス」を検索したとしましょう。多様性のないランキングだと、「ナスについて-百科辞書」「ナス-Wikipedia」で、これも百科辞書だと。「ナスの特徴」は、うーん、さっきも見たなぁ。「ナスとは」は、知ってると。「ナス-野菜辞書」は、これもさっき見たわみたいな。多様性のないランキングになってしまうんですね。

なので「ナス」で調べて、実際に探している情報だったとしても、ぜんぜんうれしくない。内容がかぶりまくっているのが、うれしくない場合があります。そうしたときに、多様性を考慮したランキングを考えてあげると、解決する場合もあります。

例えば、まず百科辞書、次はレシピ、次は保存方法、次は歴史、次はナス嫌いを克服する方法、というように、網羅的に集めてあげることが適している場合もあります。

その手法も簡単に説明すると、MMRという手法です。

これは、上位に既に出たものから、なるべく遠いものをランキングに含めてあげるというものですね。なので、1位が百科辞書だったとしたら、2位は百科辞書ではないものにしようと。そして、レシピになりました。じゃあ、3位は百科辞書でもレシピでもないものにしたい。そして、4位は百科辞書でもレシピでも保存方法でもないものにしたい……ということで、上から順番に、今まで検索結果に含まれていたものと似ていないものをチョイスしていくというやり方です。

ランキングのまとめになるんですが、基本的にはユーザーが探しているものが上位に来るといいランキングになります。そのための評価指標を3つ、紹介しました。ほかにもいろいろあるので、ぜひ調べてみてください。

基本的には、探しているものが上位に来ているといいランキングなんですが、場合によっては多様性のあるランキングが適する場合もあるので、そういったときは、そのための手法を使いましょう。

そして、忘れがちだと思うので、もう1回この図を出しておきます。

今まで、フィルタリング・ランキングという、(スライドを指して)この右側の世界の話をしました。これからお話しするのは、左側のユーザーインタフェースという世界です。

ユーザビリティの三要素

いいユーザーインタフェースって何だろうというお話をします。これは、すごくきっちりした規格で決められていて、ユーザビリティは「有効さ」「効率」「満足度」で決まると定められているそうです。

「有効さ」は、ある目標を達成する上でどれだけ正確に行動を行えたか。「効率」は、どれだけ速くそのタスクを完了できたか。「満足度」は、使っていて不快じゃなかったかという指標ですね。

なので、ひと言で言うと、正確に、効率的に、満足して使えれば、いいユーザーインタフェースだと言えます。

ただ、いい検索ユーザーインタフェースを設計するのはけっこう難しい。ここもまともに喋るとめちゃくちゃ長くなるので、かいつまんで話します。

(スライドを指して)よくある入力フォームとして、こういうものを見たことがあると思います。この単純な入力フォームは、思考停止して設置されがちなんですけども、意外と考えることはあります。

例を出してみたんですが、この入力インタフェースのいい点は、ここに挙げているとおり、「探したいものがはっきりしていると、周辺知識を調べやすい」というところ。もう1つは「条件の足し引きが容易」というところです。

例えば、このワンちゃんを探したいとして、名前が「ブリタニースパニエル」だと知っているとしましょう。知っている場合は、ズバリ「ブリタニースパニエル」と入力することができて、きっと求める情報が手に入るでしょう。

ほかにも、このワンちゃんの名前はわかんないけど、「フランスの中型の犬」であることがわかっていたとすると、こういう「フランス 中型 猟犬」という入力方法もあります。「フランス 中型」で検索して、ぜんぜん犬じゃないものが出てきたとしたら、そこに「猟犬」と、犬であるという情報を足すことができるので、条件の足し引きが容易である、という例になります。

一方のデメリットを考えます。そもそもこの犬について、あまり知らなかったとしましょう。画像としてのイメージだけあって、そこでなにか入力したいと思ってもなかなか難しいです。なので、知識がなかったら、「かわいくて茶色い犬」と入れるしかないんです。すると、かわいい茶色い犬なんて無限にいるので、探したいものが出てこないわけです。つまり、充分な知識が必要とされて、クエリを作るのがけっこう難しいと。

もう1つ、「表記ゆれが起きやすい」とスライドに書いているんですけども、「茶色くてかわいい犬」という入れ方もあるし、「茶色いキュートな犬」という入れ方もある。そういう入力のブレも起きやすいので、気を付ける必要があります。

ほかにも、この枠が横にどれだけ長いかによって、ユーザーが入れるキーワードの長さが変わるという調査結果もあったりします。なので、すごく短いフォームなら2~3キーワードしか入れないけれど、長くすると4~5キーワード入れるということもあります。

入力インタフェースを考える

けっこう考えることがありますね。

今、いろんな入力インタフェースがあります。カテゴリだと表記ゆれは起きないし、どの属性がどの値であるかがしっかり明示されていて、それはそれでいいんですけど、逆に選択肢に網羅性がなかったら「探したいもの、この中にないんだけど」という話になります。

「じゃあ、選択肢を100万個見てください」と言われたら、「そんなの見てられないよ」という話にもなります。では、その数をいくらにするか、網羅性をどれだけにするかを考えなければいけません。

BOTなどは流行りのインタフェースですけども、対話で検索することができるので、最初にどう検索していいかがわからないユーザーにとっては非常に助けになります。ただし、一度入力の解釈を間違えてしまうと、BOTが何を言っているかがわからなくなって、検索のプロセスが泥沼になってしまいます。

それぞれでいい点・悪い点がありますので、どれがサービスに合っているかを考えて選ぶ必要があります。

結果の出し方もいろいろあります。

例えば「ブリタニースパニエル」で検索したとして、(スライドを指して)こういうタイトルだけを出すやり方が1つあります。タイトルだけ出すと、1画面にいっぱい結果を出すことができるので、一覧性がいいですよね。

ただ「フランス 中型 猟犬」で検索した人は、こういう出され方だと、自分が探しているものがブリタニースパニエルかどうかがわからないわけです。そういう人には、「内容のどこどこに一致しました」というものを出してあげるといいかもしれないですね。

極論の「茶色くてかわいい犬」で検索した人は、「タイトルのみ」でも「一致部を表示」でもわからないので、一番下の「百科辞書式」みたいな見せ方で出してあげると、「この犬だよ、この犬!」ということで、わかるかもしれない。

見せ方ひとつで、自分が探しているものがあるかどうかは変わっていく。その判断のしやすさが変わっていく。だから、どう見せるかも大事で、サービスによって選んであげる必要があります。ユーザーに合わせて入出力のインタフェースを設計しましょう。ただ、絶対的な正解はありません。

そして、検索なんですけども、基本的には1回で終わりません。探したいものがあったとして、そのクエリを作って、検索欄に入力し始めて、検索を実行して結果を見ます。見た結果「探してるものとちょっと違うな」と思ったら、またクエリの修正をする。

そもそも、探しているものはこの世に存在しないこともあります。例えば、六本木の駅近なのに家賃3万円がいいですと言っても、そんな物件はないわけですね。そうすると、探したいものそのものを変える必要が出てきます。

ということで、検索行動というのは1回で終わらず、何回も何回もやり直すものであるという前提があります。この繰り返しを支援するのも、UIの役割だったりします。

例えば「ブリタニース『ニパ』エル」で検索して、「1件も見つかりませんでした」となると悲しいので、「もしかしてブリタニースパニエルですか」と出してあげる。ほかには「ブリタニースパニエル」で検索したときに、「あなたが探しているのは飼い方ですか? ブログですか? トリミングですか?」と出してあげる。もしくは、関連するキーワードで「ブリーダー」はどうでしょうといった見せ方もあります。そうすることで、検索のインタラクションを支援できます。

(スライドを指して)ここは参考程度に挙げたんですが、検索ユーザーインタフェースのガイドラインも存在するらしいです。この資料はWebに上がっているので、あとで見てみてください。

まとめです。

検索UIですが、正確に、効率よく、満足して使えればいいユーザーインタフェースだと言えます。ユーザーに合わせて、入出力のインタフェースを設計してあげるのが大事です。また、探している条件を直感的に入れられる入力、そして検索結果に探しているものがあるかが判断しやすい出力をちゃんと設計してあげる必要があります。

インタラクションを支援する機能を用意しようということで、検索は1回では終わらないので、繰り返し作業しやすいような仕組みを用意してあげる必要があります。

サービスにおける「いい検索」

最後に、サービスにおける「いい検索」というテーマで、今まで「いい検索」とは何だろうということで学術的な話を多くしてきたんですが、実際にサービスに検索機能を作り込み、それを磨き込んでいくときに、学術的な情報検索の評価指標だけ考えていればいいのかというお話をします。言ってしまえば「探しているものが上位に出てれば、それでいいのか」という話です。

これは例で挙げているんですけども、例えば図書館の書籍検索サービスを作ったとしましょう。ユーザーは検索条件を入れて本を借ります。図書館側は、どの本が借りられていても別に構いません。調査の結果、上位5件までに入った本が借りられやすいので、高評価数が多い順にランキングを作りました。そういうシステムを作ったとしましょう。

すると、高評価数順に並んでいて、利用者は上から順番に借りていくわけですから、評価が高いものから借りていく。図書館側も、好きな本が借りられていればいいので、これはお互いに「win-win」だと言えます。

図書館の書籍検索サービスの場合は、利用者、検索する側が満足すればいいので、検索の指標で評価してあげればいいです。

では、動画投稿サービスはどうでしょう。動画の視聴者は、気になる題材について動画を視聴します。動画投稿者は、見てもらうために動画を上げます。そして、同じく上位に出るとよく視聴されます。ここでも高評価数が多い順にランキングを作ったとします。

そうすると、先ほどと同じように、上位の動画がめちゃくちゃ視聴されるという状況ができるわけです。さっきの図書館の例では、別にこれでもよかったんです。検索の指標としても、上位が多くクリックされるのはかなりいい状況です。上位のクリック率が高いので、情報検索的にはかなりいいランキングであると言えます。

ただ、動画の投稿者のほうなんですけど、サービスとして考えたときに、上位の人たちはめちゃくちゃ視聴されてうれしいと思うでしょう。しかし、上位5件以下はぜんぜんクリックされなかったとしたら、自分の動画は見つけてもらえないし、視聴数も伸びません。視聴数が伸びなかったら高評価も増えないから、逆転することは一生起こり得ない。

するとこの人たちは、もしかしたら動画を投稿しなくなって、ぜんぜん動画がない動画投稿サービスになってしまうかもしれないわけです。

この場合、何がダメだったかという話です。動画投稿サービスの場合は、動画の視聴者、つまり検索する人だけじゃなくて、動画を投稿する人、検索される人の満足度も考えないといけません。なので、検索の指標だけでは不充分であると言えます。

じゃあ、この場合はどういう検索がよかったのか。この動画投稿サービスの場合は、検索者と被検索者、検索する側とされる側の両方に貢献するのがいい検索と言えるでしょう。

図書館の場合は、検索する側の満足度だけ考えればよかったんですが、この場合は両方考えないといけない。つまり、サービスによって「いい検索」の定義は変わります、ということを伝えたいわけです。

動画を視聴する側は、自分の好みの動画を見つけたい。投稿する側は、多くの人に自分の動画を見てもらいたいという欲求があります。なので、この2つに貢献するように検索を作らないといけないと思います。

従来の検索の指標は、探される側に意思がないことを仮定とすることが多いです。ただ最近のサービス……TikTokも自分で動画を上げるものですし、Instagramも自分で写真を上げるわけです。よって、探される側に意思があるサービスが増えてきているので、注意する必要があると思います。

目指すべき指標はなにか?

じゃあ、どういう指標がいいのか。

探す側は、もう検索の指標で大丈夫でしょう。探される側……例えば、視聴数がどうなっているのか。あとは、検索結果の上位にどれくらい出てきたかも測ることができます。さらに言うと、視聴数が規定値以下の動画数はいくらあるか、ちゃんと平等に見られていて、その上で評価されているかといったことも測ることができます。

なので、サービスの役割に合わせるということです。今回のサービスの役割は「好みの動画を見つけさせること」、もう1つは「多くの人に動画を見てもらうこと」になるので、それらに合わせて指標を設計する必要があります。

問題が起きたときは、それをランキングとUIという両面から解決することができます。

例えば、いつも上位は同じ動画しか出ていないという問題があったとしたら、上位に出た回数が少ない動画のスコアを高くすることで、ランキングで改善するということもできます。また、関連動画に視聴数が少ない動画を出すことで、UIで改善することもできます。なので、ランキングとUIの両面から、検索を改善することができるのです。

まとめです。

サービスにおける「いい検索」は、サービスごとに定義がまったく異なります。従来の検索の評価指標は、被検索者に意思がある場合を考慮していないことが多いので、サービスでそれが求められる場合は、そちらにも注意する必要があります。

サービスの役割と紐づくように指標を設定して、それに貢献するように設計してあげるのが大事です。解決の方法も、フィルタリング・ランキングというアルゴリズム面の改善と、ユーザーインタフェースの両面から改善できます。

サービスの役割を意識して、指標を決める

最後に、まとめです。

検索システムはフィルタリング・ランキングと、ユーザーインタフェースという2つの軸で成り立っているというお話をしました。

探しているものを速く見つけられれば、いいフィルタリング・ランキングになります。なので、上位に出ているとよかったりします。

もう1つ、正確に、効率よく、満足して使えれば、いいユーザーインタフェースだと言えるでしょう。

ただし、そればかりを追い求めていると、たまにサービスの役割を忘れてしまうことがあります。サービスの役割をしっかり意識して、指標をちゃんと決めてあげましょう。そして、使っている人の満足度に結びつくような指標を決めてあげましょう、その上で検索をデザインするのが大事です。これらが、今回伝えたかったことになります。

以上です。ありがとうございます。

(会場拍手)

検索結果の点数付けについて

司会者:ありがとうございます。最初に相応しいような、ダイジェストみたいな発表でした。1つか2つくらい質問があれば。

(会場挙手)

質問者:発表ありがとうございます。1つ質問したいのは、評価指標のところで、「この検索結果の点数が高い」みたいな評価指標があったと思うんですけど、その点数付けみたいなのはどういう感じで行うんですかね。実際にサービスでやってるときとか……。

内田:(スライドを指して)この話ですか。

質問者:はい。その点数付けをするとき、どういうログからそういうふうに取るかとか、決め打ちでいくのかみたいなところです。

内田:一番原始的なやり方なんですけど、例えば、学術界隈だと何人かバイトを雇って実際に検索してもらって、その結果ごとに点数を付けてもらうということを行っていることが多いです。

ただ、実際のサービスですとクリックのログとかが見られたりするので、検索に今まで出たもの……例えば今までこういうランキングを出していたとして、何回検索されたうちの何回クリックされたかを測ることができます。それだったら、それをもって点数とするというやり方もあると思います。

質問者:ありがとうございます。

司会者:ほか、ありますかね。風邪をひいて懇談会に最後まで出られるかわからないんですけど、捕まえていろいろ聞いてください(笑)。サービス的な部分の話とかもできると思います。ありがとうございます。

(会場拍手)