１．担当ＰＭ

   原田　康徳　（NTT コミュニケーション科学基礎研究所　主任研究員）

２．採択者氏名

３．プロジェクト管理組織

　 NTT出版株式会社

４．委託金支払額

　 4,102,909 円

５．テーマ名

　 動 的キーワード抽出による映像コンテンツブラウズシステムの開発

６．関連Webサイト

　　http://otsubo.info/contents/mitou/mitou.html

７．テーマ概要

　大量に録画したＴＶ番組等の映像データを気の向くまま、文字通りブラウズするシステムを開発した。ユーザは画面上に表示されたキーワー ド、もしくは番組の中から興味を引くものを選択する。すると表示されるキーワード及びＴＶ番組が選択に応じて変化する。このような操作を繰り返すことによ り、自分が見たい番組を見ることができるのはもちろん、普段全く見ないような番組の面白さを発見する楽しみを得ることができる。

８．採択理由

　明確な願望がない場合でも，蓄積された映像を連続的なインタフェースで提示してくれるシステムの開発．これから の膨大なビデオコンテンツの時代にこのシステムは新しい視点をもって開発するもので，大いに期待できるシステムである．

９．開発目標

　昨今、ビデオにＨＤが搭載されること が一般化され、大量の番組映像を記録することが可能となっている。しかしながら、それを閲覧するインタフェースはそうした情報の閲覧に対して効果的である とは言えない。たとえば、SonyのVAIO-Xは一週間分、６チャンネルの番組を全て録画できることをうたっている。しかしながら、それを閲覧するため のインタフェースとして提供しているのは通常の番組表情報＋番組のサムネイルを提示するタイムマシン・ビューならびに、任意のキーワードに該当する番組を 表形式で提示するキーワードビューのみである。

　こうしたインタフェースはユーザが「明確な要望を持ち能動的に検索する」場合には効果的だ が、家庭でＴＶを見るような「特に明確な願望はなく、ただ面白いものが見たい」という場合にはその効果が薄い。そうした場合にはふと目にとまったシーンか ら関連する番組を探す。あるいは特に当ても無く「別のジャンル」といった検索（実際のＴＶ利用シーンでは“チャンネルを回す”に相当する）を行うが、既存 のインタフェースはそうした行為をサポートしていない。
　これに対し、提案者がWeb上の情報閲覧用として開発したGoromiのスクリーンイメージを以下に示す。

　Goromi では初期キーワードを検索エンジンに送り、返って来た検索結果から関連キーワードを抽出するとともに、検索結果ページのタイトル及びページ中に存在する画 像を重ね合わせて表示する。このページタイトル及び画像は自動的に下から上にスクロールし、ユーザは何ら操作をすることなく、それらの情報を眺めることが 可能である。また抽出されたキーワードを一つ、もしくは複数選択することにより、新たな検索を行うことができる。

１０．進捗概要

　本プロジェクトは、既存のビデオ閲覧 インタフェースの問題点を改善するため、前項で記述したGoromiのインタフェースを発展させ、ローカルに記録された映像情報が閲覧できるようなソフト を開発することを目的とした。
　その結果、開発されたソフトウェアは開発目標にほぼ近いものとなった。すなわち抽出されたキーワード、もしくは映像情報自体クリックすることにより、 ローカルに記録された映像情報を検索、閲覧することが可能であり、また、単に「別のジャンルの番組が見たい」といった曖昧な要求にも対応することができ る。更にどのような映像をクリックしたかの履歴も同時に表示され、数個閲覧する候補を挙げておき、その中から改めて選択を行う、といった操作も可能になっ ている。

１１．成果

　本プロジェクトで開発したシステムの各機能について以下の図を用いて説明する。

　まず、システムはユーザインタフェース機能を通 じてユーザ入力を受け取る。ユーザ入力は映像検索機能に渡され、予め、記録されていた映像データ及びそれを説明するタグデータ（これは自動的に生成された 番組表データもしくは手入力されたデータ）を検索し、検索結果を作成する。
　関連キーワード抽出機能はこの検索結果より関連キーワードを抽出する。ユーザインタフェース機能は、検索された映像情報ならびに抽出された関連キーワー ドをユーザに提示する。ユーザは表示された映像を閲覧し、その番組が気に入れば視聴するし、他の番組を閲覧したい場合には更に入力を行う。

　以下、上記説明中の映像検索機能、関連キーワード抽出機能、及びユーザインタフェース機能について詳細を記述する。

　１.データ収集機能　
　データ収集機能は、ＴＶ映像データをＨＤ上の映像ファイルに変換するとともに、インターネット上から番組表データを取得。対応する映像データ及び番組表 データを一つのディレクトリに保存する機能である。
　映像データのフォーマットとしては、Quicktimeが対応しているものであれば読み込むことができる。具体的にはMPEG-1,-2-4及び. mov形式である。
　番組表データとして通常のiEPGデータに加えて番組の説明文章をＷｅｂページから抽出し、コメントとして記録する。これはiEPGデータだけでは映像 コンテンツに関する情報量が少なく、後述する映像検索機能において有効な検索が行えないために必要となる処理である。
　ディレクトリの構造は、以下の３階層としており、最下部の階層に映像データと番組表データがまとめて保存される。

　ＴＶ局　−　日付（年月日）　−　番組開始時間


　２.映像検索機能
　映像検索機能はハードディスクに記録された映像コンテンツ及びそれに関連づけられたタグデータ（番組表データもしくは手入力したデータ）を対象として、 任意のキーワード、もしくは映像コンテンツを用いて検索を行い、順位付けして結果を返す機能である。

　タグデータは以下の項目からなる。
　　1） 放送局もしくはカテゴリー名
　　2） 放送日
　　3） 放送時間
　　4） 映像の長さ
　　5） 題名
　　6） コメント（自由記述文）


　本機能では検索キーとなるタグデータ、もしくは単語データと検索対象となるタグデータの関連性を以下に示す２種類の方法で評価、その結果を統合して関連 性の高いものから順位付けを行う。

　２．１　一致単語数評価
　前述したタグデータのうち５）、６）は形態素解析され、名詞及び未知語だけが検索の対象となる。１）項の内容は、設定された単位で形態素解析されず、検 索対象となる。（すなわち「NHK総合」を「NHK」と「総合」に分割しない）検索キーとなるタグデータもしくは単語データと一致する単語を有しているタ グデータには、一致する単語数に応じて評価値を与える。

　２．２　時間類似度評価
　前述したタグデータのうち、2)3)4)については時間に関するデータであり、前項で記述した単語に関する一致評価とは異なる評価方法を採る必要があ る。こうした時間データの一致度を評価する方法として、例えば、4)映像の長さ（時間）について、いくつかの閾値を設定し、同じ区間に属する長さを持つ映 像には評価値を与えるといった処理が考えられる。
　しかしながら、ＴＶ番組はその時々によって長さが微妙に伸び縮みする性質を有する。例えば、我々が一時間番組と認識している番組であっても前の時間の 55分からスタートし、終わりにニュースがはさまれるため50分で終了するといったことがありえる。そのため、仮に１時間（＝６０分）を閾値として区間を 設定した場合、５５分の番組が１時間の番組を異なったカテゴリーに分類されることになるがこれはユーザの直感とは適合しない。
　そのため、以下のような類似度評価を行うこととした。

　1． 評価対象となる二つの時間のうち長い方を基準値として選択する。
　2． 基準値として選択されなかった映像の長さが、選択された基準値から一定の割合（映像の長さであれば７５％）以上の長さであれば、一致とみなし評価値を与え る。

　実例を用いて説明する。例えば、４６分の番組と６０分の番組とがあった場合、より長いのは６０分の番組である。その７５％は４５分であるから、選択され なかった４６分の番組はこれ以上の長さを有しており、一致とみなす。仮に比較が３０分の番組と６０分の番組であった場合には、閾値となる４５分以下の長さ であるため、一致とはみなさない。
　同様の評価方法は、放送された日時についても用いられる。日常我々は直近の日時については細かい単位（今日、昨日、今週、、）で考えるが、過去に遡れば 遡るほど大まかな単位でくくる傾向が有る（今年、去年、８０年代、、）前述した方式では、過去の番組であればあるほど、一致としてみなす幅が大きくなるの で、こうした日常の間隔と合致する評価が可能になったと考えられる。


　３.関連キーワード抽出機能
　２.項の検索機能から返された結果より関連キーワードを抽出する機能である。具体的には以下の処理を行う。
　★ 英単語及び日本語の単語、記号ごとに設定された「対象外ワード」を形態素解析結果から除外し、

　　　各番組情報ごとに有する単語のリストを作成 しておく。
　★ 画面に表示されている映像情報を対象として、単語の出現頻度を計算、一定の閾値以上の単語リストを作成する。
　★ 項で作成した単語リストを乱数によってシャッフルし、設定された個数の単語を抽出する。

　この３）は中間報告時のフィードバックを反映して追加した処理である。それ以前は単に単語の出現頻度のみを用いて関連キーワード抽出を行っていたが、そ れではよく使われる単語だけが抽出されてしまい、映像の閲覧も自然とワンパターンに陥ってしまう。
　本システムの目的は「普段見ようとも思わない番組の思わぬ楽しさを発見する」ことにあると考えればこうした傾向は好ましくない。そのため、一定以上の単 語出現頻度という枠をはめた上でキーワード選択にランダム性を持たせることとした。


　４.ユーザインタフェース機能

　関連キーワードならびに関連する映像データ、番 組表データを容易に把握、操作できるインタフェースをユーザに対して提供する機能である。

　起動すると画面左側に初期キーワードが表示され る。ユーザはこの中から任意のキーワードを選択する。すると２.項で記述した映像検索機能により、選択候補となる映像データが右側に示される。この表示は 一定時間操作を行わないと自動的にスクロールし、ユーザは操作することなしにそれらの映像情報を眺めることができる。
　ここで各番組の情報は以下の要素で構成される。
　　・ 番組の題名
　　・ 映像サムネイル（最大４枚）
　　・ 番組概要テキスト
ここからキーワードをさらに選択することにより、二つのキーワードを用いたand
検索を行うことができる。またキーワードを長押しすると、そのキーワード単独で検索を行う。
　また右側に表示された番組を選択すると、選択された番組データは左側中央に移動し選択された番組の動画が表示される。また関連キーワード及び関連映像情 報が更新される。
　このようにして自分が少しでも気に入った番組を選択していくことにより、視聴する番組を決めることができる。また選択された番組の一覧は履歴として、画 面左端に薄く表示されていく。このため画面を見る際の邪魔にならず、かつ自分が選択した番組の中から改めて見たい番組を探す、といった使用法も可能となっ ている。
　ここで選択した番組をじっくり見たい、という際には動画をクリックすると選択された動画が全画面表示となり、右側に流れる表示にわずらわされることな く、視聴することが可能となる。

　また、キーワードもしくは番組を選択し、それに 関連する映像情報が表示されはしたが、それらとは別の情報を見たい、いわゆる「気が変わる」といった事態も想定される。そうした場合のために今回作成した システムでは２種類の操作をサポートしている。
　1）今の傾向と同じ番組情報をもっと見たい場合：キーボードの下矢印キー（↓）を押す。すると現在表示されているものより、下位にランクされた番組情報 が順々に表示される。これは既存のリストインタフェースにおけるスクロールに相当する操作である。
　2）もう少し違った傾向の番組情報を見たい場合：キーボードの右矢印キー（→）を押すと現在表示されている番組情報と「類似しない」情報を表示する。こ れは前述の映像検索機能で評価した結果を最下位から順に表示することで実現している。

　これら一連の操作過程において、常に画面上には 番組情報が表示され続けている。これは今回作成したシステムが既存の検索インタフェースと最も異なる点である。明確な要求を持たず、番組を閲覧している ユーザは、とにかく気に入ったものが目に入れば、それで満足することが期待できる。従って、検索を行う間、映像の表示を停止するのではなく、どんどん候補 を提示し続けることにより、ユーザが「面白い」と思える番組に出会えることを狙っている。

１２．プロジェクト評価

　従来の映像データ閲覧インタフェースは、ユーザ側が具体的に「これを見たい」、といった要求を持っている際にうまく機能するが、要望自体があいまいな場 合には十分機能しないものであった。これを具体的に述べれば、仮にキーワードなどを用いて番組を分類したところでユーザは自分がどのようなキーワードで検 索を行えばよいのかがわからない。またキーワード同士の関連も不明であるため、選択したキーワードから関連する他のキーワードに興味を移行させていく、と いった閲覧方法も実現不可能であった。
　それに対し今回作成したインタフェースでは、以下の特徴を持っている。
　・ 常にキーワードが画面上に表示され、またユーザの選択結果により、そのキーワードがアップデートされる。
　・ 選択されたキーワード及び映像に関連する映像情報が常に画面上に表示され、またユーザが特段の操作を行わない場合には自動的にスクロールする。
　
　このような特徴により、何を見たいのか自分でも解っていない場合でも画面に表示された情報から触発されて「これを見たい」といった願望が掘り起こされ映 像を閲覧することが可能となった。

　完成したシステムは非常に見栄えがし，この考え方の部分はHDDレコーダなどの他のプラットフォームにもすぐ通用するし，PC用のシステムとしてみても 十分実用的である．表示のリッチと比べて，入力をあえてリモコンでも操作可能になるように単純化した点も面白い．開発者の提案した目標に加えて，PMが追 加した目標（複数のプラットフォームに対応してほしい）もクリアした．

１３．今後の課題

　今回開発したシステムを広く普及させ るためにはいくつかの課題をクリアする必要がある。
　まず、ＴＶをＰＣに録画するハード、ソフトは数多く製品化されているが、番組の録画フォーマット、ファイル構成に関しては標準が存在しない。そのため、 本システムで必要とする形に情報を格納するためには、それぞれの製品ごとに対応を行う必要がある。
　また、現在は番組表を公開しているサイトから番組表を取得しているが、ＴＶ番組に関する情報は番組表としてだけ、存在しているわけではない。個人が感想 などを記載したブログに存在する情報も有益であると考えられる。そのため取得する情報の対象をそうした個人サイトに広げることも必要になると考えられる。
　またマルチプラットフォーム対応を狙いシステムをJavaで記述しているが、これも製品化するにあたっては見直す必要があるだろう。Javaはその生産 性の高さとマルチプラットフォーム対応というメリットを持っているが、その実行速度並びに描画速度はそれほど高くない。従って、製品化する際にはプラット フォーム依存の開発環境（Ｃ＋＋等）で書き直すことにより、よりレスポンスの早いシステムが得られると考えられる。