4 エピソード検証表
エピソード 2 「CD を買う」
【WHAT】
1‑3‑2：商品性質はインデックス設定不可
「ジャジャジャジャーーン」って曲 2‑1‑1：商品カテゴリ独立
「ジャジャジャジャーーン」って曲 3‑1‑2：複数の会社の商品から選択購入 このような曲ならどこのメーカのでも良い
【課題】
・特に Kiosk 端末という不特定多数の話者の一連 の話を理解することは、音声辞書の整備など音声 認識の精度向上が必須と思われる。
・また、音声−＞テキスト変換、及びテキストの 意味理解、さらにここから検索条件をテキストと 音声に適切に分離し検索条件を組み立てるために は、音声理解、分脈理解、検索条件類推などの知 的エージェントが現状レベルよりさらに発展する 必要がある。
・また、数あるＣＤ店の中から音声検索ができる ＤＢを備えているサイトを特定するには、検索可 能な情報を公開するような標準的仕組みを用意す る必要がある。
・音声検索では、波形の一致や周波数の一致など パターンマッチングの類似度検索技術の適用が予 想されるが、人の音声とＣＤの音とから類似度を 決定する仕組み確立する必要がある。
Ｐ
【HOW】
1‑3：顧客志向型販売、検索
「ジャジャジャジャーーン」って曲
2‑3‑2：ニーズ創造型販売、顧客のニーズを誘 発
アフターフォローによる、更なる購買、利用 促進、顧客の利用条件によるマーケティング
（個人ＰＣなし、ＭＤあり、個別ジャンルに 詳しくはないが、流行に敏感等）
【対策・対応の提案】
当面、音声よりキーボード入力による文字列検索 などを想定したほうが良い。曲、クラッシクなど のキーワードから、シソーラスによる下位語、関 連語への展開、ユーザへの提示など、辞書の整備 と絞り込み階層方式の検索と組み合わせ、最終的 にサウンドファイルによる音の提示でユーザに情 報を提供するなどの当面の対応策が考えられる。
またサーバサイドでは、メタデータによる検索ス キーマの広告方式とこれに基づいたデータベース 検索のためのデータベース構築（ディレクトリサ ービス）などコード情報ベースでのプラットフォ ーム整備が必須と思われる。
4.3.2
サブエピソード 2‑2 「今ＴＶでやっていた安室奈美恵の最新アルバムが欲しい」
1.1.1
エピソード検証表：2‑2 「今ＴＶでやっていた安室奈美恵の最新アルバムが欲しい」
想定シナリオ：
おっと、今この銀座の街頭ＴＶで流れてる曲なかなかじゃん。あれ、アムロだよな。すぐに欲しいな、
どこで売ってるんだろう。ＰＤＡで判るかな。携帯電話をつないでっと、音楽サイトにアクセスして、
曲名は判らないから「アーティスト」を選んで、「安室奈美恵」っと。おお、出てきた出てきた。最新 アルバムはこれか。ちょっとさわりだけ聞いてみよう。おお、曲が出たぞ。そうそう、これこれ。で、
このへんで売ってるのかな？「販売店」を選んで、いつも行くのは渋谷のＴレコードだから、その系列 店で。あった、あった、数寄屋橋か、地図が出てるな、みるとすぐちかくだわ。いまから行ってみよっ と。おや？何かメッセージが出ているぞ「安室奈美恵の最新アルバムについて継続的に情報を送付しま すか？」、うーん、もう結婚しちゃったからな、いらんわ。
【要素技術】
番号 技術名称
研 究
実 証
商 用
【WHO】
1‑2‑1：購入ターゲットは特定
「安室奈美恵の最新アルバム」
2‑2‑2：ひとつの商品の提示から決定
「そうそう、これこれ」
3‑1‑2：アシスタント不要
曲名は不明だが、曲はわかってるので探せる はず
U0‑07 P3‑02 P3‑07
WindowsCE
リレーショナル DB
メタデータ ○
○
○
【WHERE】
1‑3‑1：可搬型軽量
「自分のＰＤＡ」
2‑1‑1：データ格納は可搬型
「自分のＰＤＡ」
3‑1‑1：キャラクタ入力 3‑1‑3：音声入力 3‑2‑1：キャラクタ出力 3‑2‑3：音声出力
【課題】
・既存技術の組み合わせにより実現は可能であ る。
・音楽データに対するメタデータの付与の仕方が サービス主体毎に異なると、各サービスで検索の 仕方が変わってしまうなど、ユーザにとって不利 益が生じる可能性がある。
Ｃ
【WHAT】
1‑3‑2：商品性質はインデックス設定不可 曲名は不明だが、曲はわかってるので探せる はず
2‑1‑1：商品カテゴリ独立
「安室奈美恵の最新アルバム」
Ｐ
【HOW】
1‑3：顧客志向型販売、検索
「安室奈美恵の最新アルバム」
2‑4‑1：単独商品のプッシュ
さらなる同一関連商品の継続的情報の提供に よる、顧客のつなぎ止め
【対策・対応の提案】
メタデータの標準化により、より容易に実現が可 能となる。