デジタルコンテンツのアノテーション基盤技術とそれに基づく音楽情報処理に関する研究
梶 克彦
名古屋大学 情報科学研究科 メディア科学専攻
PDF版 [kaji_doctoral_thesis.pdf]
目次
概要
近年，音楽・ビデオ・写真などのコンテンツが爆発的に増え続けており，そのコ
ンテンツの種類も多様化してきている．このようにWeb 上に存在しているコンテ
ンツを単に視聴するだけでなく，ユーザに適したコンテンツの検索・推薦や，コ
ンテンツ変換など，高度に利用したいという欲求が高まっている．そのためには，
それぞれのコンテンツの構造や関連性といった意味情報を計算機が把握する必要
がある．しかし，コンテンツの種類によって異なる論理構造が存在しており，ま
たコンテンツが持つ潜在的な曖昧性により，複数の解釈が可能な場合があるとい
う問題から，コンテンツを機械的に解析して意味を推論するだけでは，コンテン
ツの理解には限界がある．そこで，人手によってコンテンツに対するメタ情報を
付与するアノテーションの研究が進められている．
本論文では，まずWeb 上に存在するコンテンツへのアノテーションのあり方を考
察する．一般的なコンテンツを，1．コンテンツそのもの，2．時間や長さ等に関する
連続メディア，3．ビデオのシーンや音楽の音符・小節などの論理的構造を持つ離散的
なメディアという3 種類の側面を持つものと捉えると，それぞれに対するアノテー
ションを付与するには連続メディアや離散メディアの任意の内部点を指し示す必要
がある．そこでコンテンツの任意の内部点を指し示す手法であるElementPointer
と，RDF を拡張してアノテーション自身が識別子を持つアノテーションを管理す
る基盤技術としてAnnphony を提案する．Annphony がElementPointer を採用す
ることで，コンテンツの内部構造に対する多様な解釈の柔軟な定義・作成・管理
を実現する．Annphony により，コンテンツの種類によらず，その構造や解釈に基
づく検索やコンテンツ変換が可能になるとともに，複数のコンテンツを同時に利
用したアプリケーションの構築が容易になる．Annphony の設計・構築を通して，
計算機がコンテンツの構造・解釈・関連性を横断的に扱うために，コンテンツの内
部を指し示す手法と，コンテンツの多義性を扱う必要があること，アノテーショ
ンとその定義を統合的に扱う必要があることを明らかにする．
一般に音楽は必ずしも解釈を一意に決定できず，その楽曲を捉える人によって
異なる解釈を見出すことがしばしばみられる．そこで，このように解釈が多義的
になりやすいコンテンツの一つである音楽を題材とし，音楽に関するアノテーショ
ンを収集するためのシステムを提案する．本システムはユーザによって異なる多義
的な解釈を獲得するため，Web 上の多数のユーザからアノテーションを収集する．
収集されたアノテーションはAnnphony によって管理する．またコンテンツは，連
続メディアとして，離散的メディアとしてなど，それぞれの側面ごとに表示形態が
異なり，さらに付与される補足情報の種類も異なってくる．そのためそれぞれに
対応する1. 書誌情報などの楽曲自体に対するアノテーション(Tune Annotator)，
2. 連続メディアに対するアノテーション(Timeline Annotator)，3. 音楽の論理構
造である楽譜に対するアノテーション(Score Annotator) の3 種類のエディタを備
える．収集すべきアノテーションは，そのアノテーションの応用の形態によって
異なるため，Annphony に登録されるアノテーション定義に応じて，収集するアノ
テーションを変更することが可能である．このように，様々な種類のコンテンツ
のアノテーションを獲得するためには，コンテンツのメディア形式に応じてアノ
テーションエディタを構築する必要があることを示す．また評価実験をつっじて，
多義的なアノテーションをWeb 上のユーザからオンラインで収集することが可能
であることを明らかにする．
また楽曲に対する多様な解釈に関するアノテーションを用いることで様々な応
用が実現可能であることを示すため，認識系応用として楽曲検索システムを，生
成系応用として楽曲再構成システムを構築する．楽曲検索システムは，音符や歌
詞など楽曲の論理構造に基づく要素に付与されたアノテーションを用いて，キー
ワード検索・印象検索・コード進行検索・楽曲の構造に基づく絞込み検索を実現
する．特に印象検索では，検索を行うユーザと嗜好の類似するユーザが付与した
アノテーションを優先して検索対象とすることで適切な楽曲を発見する．楽曲再
構成システムは，サビ・イントロなどの楽曲の構造に関するアノテーションを用
いて，例えば「イントロ-A メロ-サビ-B メロ-エンディング」という構造の楽曲を，
ユーザの要求に応じて「イントロ-サビ- エンディング」のように変換する．これ
らの応用は，楽曲の論理構造に対する，ユーザごとに異なる解釈のアノテーショ
ンを用いることで可能となる．
近年Web 上ではe-mail・オンラインチャット・ブログ・SNS(Social Networking
Service) などのコミュニケーションツールを通じて，文書や絵，写真などのコンテ
ンツがコミュニケーションメディアとして意思の伝達に用いられている．このよ
うに，コンテンツは人同士のコミュニケーションにおいて利用されるものである
といえる．そのためコミュニケーションの活発化に応じて，Web 上に存在するコ
ンテンツが爆発的に増加してきている．コンテンツを介したコミュニケーション
を支援することが，人同士のコミュニケーションをより円滑にし，同時にコンテ
ンツの作成・利用を促進することにつながると考えられる．そこで，近年携帯型音
楽プレイヤの普及などにより注目されてきているプレイリスト(再生曲目リスト)
をコミュニケーションメディアとして利用する．プレイリストを介したコミュニ
ケーションをPlaylist-Mediated Communication と名付け，その実現を目指し，プ
レイリスト作成支援システムを提案する．
本システムは楽曲の特徴量として歌詞に加え，ユーザの楽曲解釈の情報である
楽曲情景と鑑賞状況に関するアノテーションを利用することにより，ユーザの嗜
好と状況に合わせたプレイリストを作成する．本システムに利用されるアノテー
ションも，楽曲検索システムや楽曲再構成システムと同様，音楽アノテーション
システムにより収集する．プレイリスト作成の手順は，まず基となるプレイリス
トを協調フィルタリングにより発見する．次に，よりユーザの嗜好に適合するよ
うトランスコーディングを行い，ユーザにプレイリストを提示する．ユーザはプ
レイリスト中の各楽曲に対して，嗜好に合っているか，状況に合っているかといっ
た情報をフィードバックすることによりプレイリストが洗練される．同時にシス
テムはこの情報を用いてユーザプロファイルを更新し，各ユーザの嗜好に適合さ
せる．また，プレイリストを介してコミュニケーションを行うために，プレイリ
スト中の楽曲に対してライナーノーツ(解説文) を記述したり，他のユーザにプレ
イリストを推薦する機能を持つ．本システムによって，ユーザの嗜好と状況に適
応するコンテンツ推薦のために，コンテンツごとに，ユーザによって異なる解釈
に関するアノテーションを収集し利用することが有効であることを明らかにする．
また，プレイリストがコミュニケーションを円滑にする可能性があることを示す．
1. 序論
1-1. 背景
現在，Web上には音楽・ビデオ・写真など膨大な量のコンテンツが溢れている．
また，それまではコンテンツを消費する側であったユーザが，ブログや
SNS(Social Networking Service)など，CGM(Consumer Generated Media)サービ
スを用いてユーザ自身によってコンテンツを発信するようになり，コンテンツの
増加・多様化が進んでいる．そのためWebのユーザ数や年齢層の拡大により，様々
な属性のユーザがコンテンツを扱う機会が増加している．さらに計算機のウェア
ラブル・ユビキタス化に伴い，コンテンツを生活のあらゆる場面で楽しむ環境が
整いつつある．
このような現状では，計算機が行うコンテンツ処理には個人適応と状況適応が必
要である．ユーザごとに異なる嗜好を踏まえるとともに，ユーザがどのような環
境に置かれているかを考慮することで，その時，そのユーザにとって適切な検索
や推薦，コンテンツ変換などのコンテンツ処理が実現されるだろう．
個人適応・状況適応の必要なコンテンツの代表例に音楽が挙げられる．音楽は，
ユーザごとにジャンルやアーティストなど好みの違いが顕著に現れるコンテンツ
である．利用可能な楽曲も，iTunes Store [1]やAmazon [2]
からの楽曲購入が容易となり，音楽定額制配信サービス等も現れたため，個人が
利用可能なデジタルコンテンツとしての楽曲が大幅に増加した
[3][4]．さらにiPod等のポータブル音楽プレイヤの
出現により，音楽を持ち歩き，いつでもどこでも手軽に音楽を鑑賞できるように
なった．また日常生活における音楽との接し方から推測されるように，例えば
「夏の海で大勢で楽しむ時に聴きたい曲」と「クリスマスの夜恋人と聴きたい曲」
は大きく異なるだろう．このようにユーザの置かれている状況が，楽曲検索や推
薦に強く依存すると考えられる．
従来の音楽情報処理の多くは，音響メディアやMIDIなどの構造化メディアなど，
単一のメディア形式を対象として研究が進められてきたが，音楽情報処理研究を
さらに発展させるためには，複数のメディアの形式を同時に扱わなければならな
いだろう．例えば楽曲検索を例にとってみると，音メディアから認識可能なテン
ポや音量等の音響特徴量に加え，テキストである歌詞の情報や，画像であるアル
バムのジャケットイメージの情報，映像であるプロモーションビデオの情報など，
他のメディアを対象とした検索を実現することで，ユーザが目的の楽曲にたどり
着く可能性が高まる．このように，音楽に関する研究を行う際に，他のメディア
も横断的に利用することが求められる．また複数のメディアを同時に扱う必要性
は，音楽情報処理に限らない．Tim O'Reillyが提唱したWeb 2.0にお
いても，Web 上のサービスやリソースが互いに連動することによってコンテンツ
処理全般が発展すると述べられている[5]．
膨大な量のコンテンツからの検索や推薦，複数の種類のコンテンツの組み合わせ
などを行うには，計算機の支援が無くては困難である．特に重要なコンテンツの
意味内容として，構造・解釈・関連性が挙げられる
[6][7]．構造に基づく検索や，要約などのコンテン
ツ変換を行うためにはそれぞれのコンテンツの構造を考慮しなければならず，人
によって異なるユーザの嗜好や感性を扱うために，コンテンツに対する多様な解
釈を扱う必要がある．また種類の異なるコンテンツ同士を横断的に扱うために，
コンテンツ同士の関連性を把握する必要がある．例えば撮り溜めた写真を用いて
自動でアルバムを作成する場合に，写真間の関係や撮影の意図などを無視して，
色ヒストグラムの類似する画像を表示しても，ユーザにとって整理されたアルバ
ムを作成することができない．このように，意味的なつながりや個人嗜好にそぐ
わないコンテンツ処理となってしまう．
そこでTim Berners-Leeは計算機がWeb上のコンテンツの意味内容を把握するため
に，セマンティック・ウェブを提唱した[7]．適切なアノテーショ
ン(メタ情報)を各コンテンツに持たせることによって，コンテンツの意味を計算
機が利用可能にするというものである．現在ではその必要性からアノテーション
の管理・収集・利用などに関する研究が進められている[6]．これか
らアノテーションの研究動向と，個人の嗜好・状況への適応を目指した音楽情報
処理に関する研究動向を述べる．
1-
1-
1. アノテーションに関する研究動向
コンテンツの意味内容を機械的な処理に適用可能な形式で取り込むために，アノ
テーションに関する研究が進められている．アノテーショ
ンとは，図1に示されるように，あるコンテンツに対
して関連付けられるメタ情報である．
図1.
コンテンツとアノテーションの関係
アノテーションに関する研究を分類すると，主に1. 規格化，2. 収集，3. 応用
の3種類に分類されると考えられる．
[アノテーションの規格化]：
アノテーションの規格化は，コンテンツに付与されるメタ情報の記述能力を左右
する重要な点であるといえる．コンテンツの種類に依存したアノテーション形式
と，コンテンツの種類に依存しないアノテーション形式に二分される．
コンテンツの種類に依存する形式としては，GDA(Global Document
Annotation)[8]やMPEG-7[9]が挙げられる．GDAはテキストに対
する構文・意味情報を詳細に記述するための形式である．MPEG-7はマルチメディ
ア・コンテンツに対するメタデータの表記方法に関する国際標準規格である．正
式名称をMultimedia Content Description Interface という．マルチメディア・
コンテンツの検索の際に直接の検索対象となる画像・音響特徴データを規格化さ
れた手段で表現可能である点が特徴である．MPEG-7によって画像データのメタデー
タを記述した例を図2に挙げる．MPEG-7は，{Mpeg7}タグから始ま
るXML形式で記述され，{description}タグ内に画像から抽出される色ヒスト
グラム情報や，撮影日時，コンテンツ管理など，規格として定められた属性を入
力することができる．
図2.
MPEG-7の記述例
これらの形式は，コンテンツ内部の意味内容に関するアノテーション
を記述することを目的としており，それぞれがコンテンツの種類に依存する形式
となっている．そのため，横断的にこれらのコンテンツを扱うためには，専門性
の高いそれぞれのアノテーション形式を熟知しなければならない．またコンテン
ツの種類は多様化を続けているため，コンテンツの種類の追加に伴い定義される
新しいアノテーション形式に対応しなければならない．
一方で，コンテンツ自体の情報や，コンテンツ同士の関連性などを記述するアノ
テーション形式として，RDF (Resource Description Framework)[10]が標
準化されている．URI(Uniform Resource Identifier)[11]を持つリソース
であれば，コンテンツの形式を問わずアノテーションの対象に指定可能であるた
め，異種類のコンテンツ間の関連性を表現することができる．従来，コンテンツ間
の関連は，HTMLのハイパーリンク構造により導き出されることが一般的であるが，
ハイパーリンクには，リンクの意味を記述することができない点が問題であった．
RDFのデータ構造は，図3に表すように，主語・述語・目的語の組みによっ
て，ラベル付き有向グラフとして表現される．例えばある楽曲の制作者を記述す
る場合，楽曲のURIを主語に，制作者のURIを目的語に，それらの間の関連性とし
て，制作者であることを示す{dc:creator}という述語を記述する．
またアノテーションの述語に相当する部分の柔軟な定義が可能であり，様々な関
連性に関する情報を表現することができる．このことから様々な種類のコンテン
ツ同士の関連の把握を容易にし，多様なアプリケーションに適用可能な形式であ
るといえる．しかしURI によってコンテンツを指し示すため，それ以上に詳細な
コンテンツ内部に関する記述が困難である．そのためコンテンツの種類を横断す
るアノテーション形式であるRDF はコンテンツの内部構造までを扱うことができ
ない．
図3.
RDFのデータ構造
図1に示すように，コンテンツの内部構造を記述するためのアノテーショ
ン形式であるGDAやMPEG-7はコンテンツの種類に依存する．また新規のコンテン
ツが出現した場合には，そのコンテンツに特化した新しいアノテーション形式が
提案されるだろう．一方でコンテンツ間の関連性を記述するためのRDFには，一般に
コンテンツの内部構造を扱うことができず，双方の間には大きな壁が存在
する．このように多様化するコンテンツとその内部構造や，コンテンツ同士の関
連性を統一的に扱う仕組みが求められるが，現在そのような仕組みが存在しない
という問題がある．
図1.
アノテーションの枠組みの間の壁
また，アノテーションには計算機によって自動的に生成されるものと人間の手に
よって作成されるものが存在する．計算機の自動解析によってコンテンツの構造
を認識する研究が多く存在するが，一方では自動解析によって得ることの困難な
情報を，人間の手によって付与するシステムに関する研究が盛んになってきてい
る[6][12][13]．アノテーションを付与するための
特別なエディタを用意し，詳細な構造情報等を付与するというものである．
[アノテーションの収集]：
人手によるアノテーションには，アノテーションの付与のコストという問題が存
在する[14]．人手により詳細な情報を付与可能である反面，膨大な量
のコンテンツをアノテーションの対象としなければならない．その解決策の一つ
としてFolksonomy [15] が挙げられる．del.icio.us
[16]やFlickr [17]において，Web 上の多くのユーザがそ
れぞれのコンテンツにタグと呼ばれる分類キーワードを付与することで，そのタ
グを基に分類やコンテンツへのアクセスを可能にする仕組みを構成している．
Web上の文書や写真といったコンテンツに何が表現されているかは，計算機がそ
れを自動解析することが困難であるが，その制作者や閲覧者は容易に理解するこ
とができる．そのような情報を幅広いユーザの手によって記述することで，アノ
テーション付与のコストを軽減することが可能である．このように多くの人の分
類作業を蓄積して再利用可能にする仕組みをFolksonomy と呼ぶ．またWeb上の文
書に対して，多くのユーザから少しずつ文書情報を収集するシステムも研究が進
められており[18][19]，一般大衆から得られる情報を蓄積
することで形成される「集合知」に期待が寄せられている．
[アノテーションの応用]：
アノテーションの応用としては，ビデオのシーン検索など，膨大な量のコ
ンテンツの内容を考慮したコンテンツ検索がある．またアノテーションを
用いることで，目的に合わせてコンテンツを変換することも可能になる．文書に
対する構文や単語の意味に関するアノテーションを用いた応用として，
SemCode[6]がある．それは文書の翻訳・要約・音声化・言い換えや，表示端末へ
の適応を行っている．また複数のコンテンツを組み合わせることで新しいコンテ
ンツを生成するための規格化[20]や研究[21]が進められて
いる．
以上のことから，現状では多様なコンテンツを対象とした場合にはコンテンツの
内部に関する情報を扱うことが困難であり，逆にコンテンツの内部構造を扱うた
めにはコンテンツの種類を横断することが困難であることが分かる．今後は多様
なコンテンツを対象とし，かつコンテンツの内部に関する情報を扱うことが求め
られようになると思われる．
1-
1-
1. 音楽に関するメディア形式とアノテーションの研究動向
音楽は個人の嗜好・状況への適応が強く求められるコンテンツであり，機械的に
音楽利用を支援する研究が進められている．以下に音楽情報処理研究の動向を述
べる．
音楽メディアは，MP3等の音響信号などの連続メディア以外に，音楽の離散的な
構造を記述する形式が提案されている．特に音楽の詳細な楽譜構造を表現する形
式として，WEDELMUSIC XML[22] とMusicXML[23]がある．こ
れらの形式は楽譜を構成する情報を記述することができ，またXML形式で
記述されているため，計算機は音符や小節，楽器パートなどの詳細な楽曲構造を
把握でき，また楽曲の一部を変更するなどのコンテンツ変換の操作が容易に実現
可能である．また音楽の構造化に関する研究も進められており[24]，今
後も変更・拡張されていくだろう．そのため音楽のみを扱ったコンテンツ処理で
あっても，このような多様なメディアに横断的に対応しなければならない．
楽曲のタイトルやアーティスト・ジャンルなどのアノテーションを付与する方法
として，MP3はID3タグを埋め込む方式をとっている．一方CDDB[25]や
MusicBrainz[26]は楽曲の書誌情報などを外部アノテーションとして
一括管理し，そのアノテーションを対象とした楽曲検索が可能である．CDDBは拡
張性に乏しく，新しい属性を追加することができないが，MusicBrainzで
はRDFをデータ形式として利用しており，新しい属性を定義することで，
柔軟に拡張することができる．このような拡張性は，アノテーションの利用法を
特定せず，幅広いアプリケーションに適用可能になるという利点がある．一方で，
柔軟に定義可能なアノテーションは，あらかじめ定義が固定されたアノテーショ
ンと比較して，他人が定義したアノテーションをどのように共有し，利用を支援
するかに関して問題があるといえる．
音楽コンテンツの意味内容の中には，自動認識することの困難な情報が多く存在
する．例えば楽曲から受ける印象は，テンポや曲調，歌詞の内容，時代背景など
を踏まえて判断する必要があり，一般に自動的に解析することが困難である．ま
た音楽は特に芸術作品としての側面を持ち，コンテンツ自体に多義性が残されて
いることが多く，人が解釈することによって初めてコンテンツの内容を把握する
ことが可能になる場合が多い．そのため音楽は人手によるアノテーション付与が
特に有効となる．音楽に関するアノテーションを人手により付与する研究
がいくつか存在するが[][28][29]，コンテンツ
の内部構造に対するアノテーション付与ができない，人によって異なる解釈を管
理することができないなどの問題点が存在し，音楽の意味内容を記述するために
は不十分である．
また音楽のメディア形式の多様性や拡張性の点から，図1に示したアノ
テーションの壁は，音楽のみを対象とした場合も存在しており，音楽を対象とし
てこの壁を取り除くことは，一般的なコンテンツに対するアノテーションの壁を
取り除くことにもつながると考えられる．
1-
1-
2. 音楽コンテンツの応用に関する研究動向
音楽コンテンツの応用として，楽曲の推薦
[2][30][31]や配信[1]など，
楽曲単位あるいはその集合単位の利用法に関するサービスや研究が盛んに行われ
ている．近年，特にiPodなどのポータブル音楽プレイヤの普及によりプレイリスト
の有効性が注目されている．また，様々なCGMの中でも，作曲や演奏をしたり，
小説を書くといった敷居の高いコンテンツ制作に比べ，作成が容易であるプレイ
リストは，より手軽な音楽を楽しむ手段として注目されている．
プレイリストとは，ユーザによって事前に選択された曲目リストである．プレイ
リストを利用することで，一曲ずつ再生する楽曲を決定するといった煩雑な操作
を必要とせず，より容易に楽曲が鑑賞できるようになった．そのためプレイリス
トの自動作成や推薦に関する研究が進められている
[32][33][34][35]．これらの研
究では，音楽の音響信号の類似度や，ジャンル・アーティストといった基本情報，
ユーザの嗜好，またユーザ同士の類似度などを用いることで，それぞれのユーザ
に適合したプレイリストを作成，推薦している．
音楽以外の他の種類のコンテンツにも，プレイリストと同様の概念が存在する．
写真のアルバム，複数人の作品を集めた歌集や詩集，テレビのコマーシャ
ルフィルムを集めたCM集などである．また，あるテーマに関連したコンテンツを列
挙させるプレイリストなど，プレイリストを構成する要素が複数の種類になる場
合も考えられる．これらのことから，プレイリストの作成や利用に関する研究は，
音楽情報処理の枠を超えて，コンテンツ処理に関する研究全体に対して貢献する
と考えられる．
このように，音楽コンテンツを利用したアプリケーションとして，プレイリスト
作成の計算機による支援や，作成されたプレイリストの他のユーザへの推薦などの
研究を進めることは非常に有意義であり，コンテンツの種類を横断するクロスコ
ンテンツ処理へ発展する可能性もある．
1-2. 本論文の目的
以上の背景を踏まえ，本論文では計算機がコンテンツの意味を把握し，様々な応
用が実現可能になることを最終的な目標とする．また前提条件として，
本研究で扱うコンテンツはWeb上で公開され，利用可能であることと設定する．
特に着目するコンテンツとして音楽を選ぶ．音楽は特に個人の嗜好と状況への適
応に対する要求が高く，多様なメディア形式や意味内容を統一的に扱う必要のあるコン
テンツである．
以上の背景を踏まえ，本論文では計算機がコンテンツの意味を把握し，様々な応
用が実現可能になることを最終的な目標とする．また前提条件として，
本研究で扱うコンテンツはWeb上で公開され，利用可能であることと設定する．
特に着目するコンテンツとして音楽を選ぶ．音楽は特に個人の嗜好と状況への適
応に対する要求が高く，多様なメディア形式や意味内容を統一的に扱う必要のあるコン
テンツである．
また，特に楽曲に対する構造や解釈・関連性に関するアノテーションを獲得すること
を目的とする．自動認識の困難な楽曲情報を収集するため，Web上の一般ユーザ
を対象とした，オンラインでアノテーションを獲得するシステムを提案し，音楽に限らず，他の
コンテンツに関するオンラインアノテーション収集システムを実現する際の指針
を示す．
さらに，実際に構造や解釈に関するアノテーションを用いた複数の音楽アプリケー
ションを提案することにより，
計算機がユーザのコンテンツ制作・利用を支援するため
の手法を示し，また音楽以外のコンテンツへの応用可能性を示すことを目的とす
る．
1-3. 本論文の構成
本論文の構成を以下に示す．
まず2章では，コンテンツに対するアノテーションを管理する基盤技術について
述べる．Web上の任意のコンテンツに対するアノテーションのための基盤として
Annphonyと呼ばれるシステムを提案する．コンテンツの内部要素を指し示す形式
としてElementPointerを提案し，さらに既存のアノテーション形式であるRDFを
拡張することで，コンテンツの構造・解釈に関する情報を扱えるようにする．ま
た記述可能なアノテーションの種類を特定せず，柔軟なアノテーション記述を実
現するために，RDFのスキーマ言語であるRDFS(RDF Schema)[36]によって
記述されるアノテーション定義の管理を行っている．
3章では，アノテーションに基づく音楽情報処理を目指し，音楽に関するアノテー
ションを獲得するためのシステムを提案する．楽曲情報には，自動認識すること
の困難な情報が多く存在している．それらの情報を収集するため，Web上のユー
ザを対象とし，人手によるアノテーション収集を支援する．本システムは2 章で
述べたAnnphonyをアノテーションの管理に利用することで，楽曲
の構造や解釈・関連性に関するアノテーションを収集する．またAnnphonyで管理
されるアノテーション定義
を，アノテーション収集のためのシステムに適用する
ことで，収集するアノテーションを柔軟に追加・変
更することが可能である．これにより特定のアプリケーションに限定されないア
ノテーション収集が実現される．
4章，5章では，音楽アノテーションを複数のアプリケーションで利用する手法に
ついて述べる．まず4章では楽曲検索・楽曲再構成システムについて述べる．これら
のシステムで利用されるアノテーションを定義し，3章の音楽アノテーションシ
ステムに適用することで，印象や楽曲構成などのアノテーションを収集し，利用
する．5章では新しい音楽の利用形態として，プレイリストを介したコミュニケー
ション(Playlist-Mediated Communication)を提案する．
一般的に音楽のプレイリストは作成が手軽であり，プレイリストへの解説や感想
が頻繁にやり取りされるため，Web上のユーザによるプレイリストを中心として
コミュニケーションが成立すると考えられる．そこで，嗜好と状況に適合するプ
レイリスト作成の支援を行い，さらにそのプレイリストに対する感想や解説を投
稿し合うことで，ユーザ同士がオンラインでコミュニケーションを行うシステム
を実現する．本システムでは，楽曲そのものから認識することが困難な情報であ
る楽曲情景(楽曲中で表現されている情景)・鑑賞状況(その楽曲を鑑賞したい状
況)というアノテーションを音楽アノテーションシステムによって収集し，利用
している．
さらに6章では関連研究について述べ，7章で本論文をまとめ，今後の課題について述べる．
また将来展望として本論文で提案する音楽を軸としたアプローチが，
音楽情報処理以外にも適用可能であることを述べる．
2. 任意のコンテンツに対するアノテーション基盤
Web上に存在する大量のデジタルコンテンツを有効利用するため，テキストや音
楽などのコンテンツに対してメタ情報(アノテーション)を付与し利用する研究
が盛んに行われている[6][12]．これらの研究から，
コンテンツの意味内容を考慮し，それぞれのユーザに適したコンテンツ処
理を行うことの重要性と，そのためにはコンテンツの構造に加えコンテンツの詳細
部分にまで踏み込んだ個人の解釈・嗜好情報が必要であることがわかる．
しかし，1.1.1節で述べたように，現在までに提案されているデジタルコンテン
ツに対するメタデータの表現形式は，コンテンツの構造を記述するためにコンテ
ンツの種類に強く依存した形式となる仕組みと，異なるコンテンツ間の関連性を
記述することができるがコンテンツの内部構造に踏み込むことができない仕組み
の二通りに分断されてしまっている．またコンテンツの種類も多様化を続けてお
り，画像・音楽・文書などのコンテンツを横断的に利用し，意味内容と個人性を
考慮した応用研究を進めるにあたっての障害となっている．
また，横断的にコンテンツを扱うためには，それぞれのコンテンツの意味内容を
記述するためのアノテーション定義を共有しなければならない．同時に，コンテ
ンツの種類は多様化を続けているため，コンテンツの種類の追加に伴い定義され
る新しいアノテーション形式に対応しなければならない．
本章では，1．任意のコンテンツに対するアノテーションを実現するために必要
な要素について，2．我々が構築しているアノテーション基盤Annphony(アンフォ
ニー) におけるアノテーションとそのスキーマの形式について，3．Annphonyに
おいてアノテーションやスキーマの利用・共有を支援する機能について述べる．
2-1. 任意のコンテンツに対するアノテーションについての問題点
現在デジタルコンテンツに対するアノテーションの記述形式がいくつか提案され
ている．例えばテキストに対する構文・意味情報を詳細に記述するための
GDA(Global Document Annotation)[8]や，テキストコーパスに対するア
ノテーション形式であるCES(Corpus Encoding Standard)[37]などがある．
Flickr[17]はWeb上で写真を共有するサービスであるが，独自のアノテー
ション形式により画像の矩形部分に対するコメント付与を実現している．これら
の形式はコンテンツの種類に閉じており，例えばFlickrにおいて記述されたコメ
ントに対して，GDAによる詳細な言語構造を記述するといった，あるコンテンツ
のアノテーションを異種コンテンツに適用することが困難である．このように，
現在提案されているコンテンツの内部構造にまで踏み込んだアノテーション形式
は互換性が乏しいといえる．
一方で，コンテンツ全般に対するアノテーションの形式としてリソース間の関係
をグラフ構造で記述するRDF(Resource Description Framework)[10]では，
URI(Uniform Resource Identifier)[11]を持つ対象をリソースと呼び，そ
のリソースに対するメタ情報を主語・述語・目的語の組で表現する．つまり，ど
のようなリソースであってもそれをURIで表現することができれば，そのリソー
スに対するアノテーションを記述することが可能である．
コンテンツの意味情報を扱うためには，そのコンテンツの詳細な部分へのアノテー
ションを実現しなければならない．なぜなら，コンテンツの構造の一部に対し，
その部分がコンテンツの他の部分や，他のコンテンツとどのような関係性を持っ
ているか，またその部分は人によってどう解釈されるかという情報を付与する必
要があるからである．そこで，まずコンテンツの構造を表現するために，コンテ
ンツの任意の箇所を指し示す方式としては，XMLの特定のノードを指す
XPointer[38]や，ビデオ・オーディオなどの連続メディアの任意の
箇所を指し示すURI time interval specification [39] など，いくつか
の形式が提案されており，今後も新しいメディア形式が提案されると予想される．
しかし，未知のメディア形式を含むそれらの全てを網羅するアノテーション形式
は存在しない．さらに，提案されている形式では指し示すことのできない場合が
多く存在する．そのため，「MIDIの特定のチャンネルにおける時間範囲」といっ
た，任意のコンテンツの，任意の箇所を指し示すことのできる柔軟な表現形式が
必要である．
図4に示すように，音楽や絵画などの芸術作品には，
鑑賞者によって解釈は様々に異なる場合が多い．また楽曲の構造化を行う
GTTM(Generative Theory of Tonal Music)[24]では，楽曲の構造を一意
に決定することができない場合がある．そのため複数の解釈に基づく構造が存在
する可能性がある．そのような多義性のある構造の一部に，関連性や解釈などの
意味情報を付与するためには，同一のメディア形式が複数の構造を持つことを許
す必要がある．しかしRDFやGDAでは，一つのメディア形式に対する複数の構造を
扱うような柔軟な関連性記述ができないという問題がある．
図4.
同一のリソースに対する解釈の多様性
また構造や解釈といった様々なアノテーションを定義する際には，既存の定義を
利用・拡張することで，アノテーションの再利用性が高まると考えられる．例え
ば異なるコンテンツ間で共通の属性を定義し，各コンテンツのアノテーショ
ンでその属性を利用することで，コンテンツの種類にこだわらずそのプロ
パティを利用することができるだろう．そのためアノテーションのスキーマの存
在が必須となる．
Flickrではアノテーションを利用するためのFlickr APIが用意されており，また
RDFに関してはProt\'{e}g\'{e}[40]やRDF Gravity[41]な
ど，RDFの記述・検索・可視化を行うアプリケーションが提供されている．様々
な種類のアノテーションを幅広く収集し，利用可能にするためには，これらのシ
ステムのように，幅広いユーザが利用可能なアノテーション管理基盤が必要であ
る．しかしこれらのシステムでは，任意のコンテンツの内部要素に対するアノテー
ションを扱えない．
2-2. ElementPointer
前節で述べたように，コンテンツの内部構造に対するアノテーションを扱うため
には，そのコンテンツのセグメントを指し示す手段が必要である．任意のメディ
アの任意のセグメントを指し示す形式としてElementPointer を提案する．
2-
2-
1. ElementPointer の形式
ElementPointerをXPointerの書式を参考にして定義する．
XPointerは以下の形式でXMLドキュメントの任意のノードを指し示す．
[Content]\#xpointer([XPath])
コンテンツのURIである[Content]に続き，{\#xpointer}以降
[XPath]にXMLドキュメント内部ノードを指し示す手段として標準化されている
XPath [42]を記述することで，内部構造への言及を可能にしている．
全ての中括弧は表記には含まない． 例えば図5 のように，XML ドキュ
メント(http://localhost/test.xml)の，ルートノード(doc)の子ノードである
person の中で，id属性がkajiであるものを指し示すXPointerが示されている．
XPointer は一般的に以下のように表現される．
図5.
XMLドキュメントの内部ノードのXPointerによる指示
一方で，任意のコンテンツの任意の箇所を指し示すXPathに相当する形式が存在
しない．そこでElementPointerではコンテンツ内部を指し示すための定義を別途
用意し，その定義を引用する．また，例えば図6でハイライト
されている，「MIDIのチャンネル１における，楽曲開始後10秒から20秒までの時
間範囲」のようなセグメントを指し示すためには，MIDIのチャンネル番号，開始
時間，終了時間という属性名，属性値が必要となる．そこで，ElementPointerは
以下のように，定義と，属性名・属性値の組を列挙する形式をとる．
図6.
MIDIファイルの時間区分
[Content]\#epointer([Schema](([Prop1],arg1),([Prop2],arg2),...))
コンテンツのURIである[Content]に続き，以降にフラグメント識別子としてコン
テンツのどの部分を指し示すかを記述する．本手法では，コンテンツの内部は，
[Schema] で表されるElementPointer定義のURI以降に，[Prop1],[Prop2],...で
表される有限個の属性のURI とその値を列挙することにより指し示される．これ
らの属性はコマンドに対する引数の役割を持つ．実際にはURIとしての妥当性を
保つため，{[Schema](([Prop1],arg1),([Prop2],arg2)...)}の部分をURLエ
ンコーディングする．URLエンコーディングによって，URIに含めることのできな
い文字を妥当な文字に変換することができる．
アノテーション共有の必要性から，ElementPointerの定義は共有に適した一般的
な形式で記述されるべきである．ElementPointerは，コンテンツの任意の内部要
素を指し示すことで，コンテンツの構造を表現するための形式であるため，意味
的なアノテーションの一つであるといえる．そこで，リソース間の関係を表すた
めのフレームワークであり，一般的なアノテーション形式として知られている
RDFのスキーマ言語であるRDFS(RDF Schema)[36]をElementPointerの定義
に採用した．リソース間の関係をグラフ構造として表現するRDFやRDFSを用いる
ことで，その検索言語であるSPARQL(SPARQL Query Language for
RDF)[43]によって，コンテンツの構造を扱う際に有効なグラフ検索が
可能になる．そのためElementPointerの定義を共有することに適していると考え
られる．Annphonyにおいてその定義の検索や利用を支援し，任意のユーザによる
ElementPointerの定義の利用を支援する．
ElementPointerの具体例を示す．前述の「MIDIのチャンネル１における，楽曲開
始後10秒から20秒までの時間範囲」を指し示すため，MIDIチャンネル別の時間範
囲を表すElementPointerを定義する．本定義で利用される属性とそのデータ型と
して，MIDIのチャンネル番号(1から16までのinteger型)，時間区分の開始時間
(double型)，終了時間(double型)を記述する．また時間区分の開始時間，終了時
間は楽曲の演奏の開始からの秒数であることを同時に記述する．具体的なRDFSの
書式については2.3.2節において述べる．こうして記述された定義はWeb上に公開
するか，Annphonyに登録し，URIを持たせることで利用可能になる．便宜的に
「MIDIの特定のチャンネルにおける時間範囲」に対するElementPointer の定義
のURIを[Schema]，チャンネル番号，時間区分の開始時間，終了時間の各属性の
URIは[Content]，[From]，[To]と表現すると，ElementPointerにより，あるMIDI
データ(http://foo/bar.mid)における，チャンネル番号が1番の，10.0 秒から
20.0秒までの範囲を指し示すElementPointerは以下のように表現される．
http://foo/bar.mid\#epointer([Schema](([Channel],1),([From],10.0),([To],20.0)))
実際にはURIの規格に準拠するため，URLエンコーディングを施す．[Schema]，
[Channel]，[From]，[To]にURIを埋め込み，URLエンコーディングを行った具体
的な例を以下に示す．
http://foo/bar.mid\#epointer(http\%3A\%2F\%2Flocalhost\%2Fannphony\%2F
schema\%2Fmidi.rdfs\%23midi\%28\%28http\%3A\%2F\%2Flocalhost\%2F
annphony\%2Fschema\%2Fmidi.rdfs\%23channel\%2C1\%29\%2C\%28
http\%3A\%2F\%2Flocalhost\%2Fannphony\%2Fschema\%2Fmidi.rdfs\%23from\%2C
10.0\%29\%2C\%28http\%3A\%2F\%2Flocalhost\%2Fannphony\%2Fschema\%2F
midi.rdfs\%23to\%2C20.0\%29\%29)
また，例えば画像の矩形範囲を指定するためには，画像のX 座標，Y座標，幅，
高さが決定される必要がある．そこで同様にX座標，Y座標，幅，高さの4種類の
属性を記述し，さらにそれぞれの値のデータ型を指定する．またそれぞれ
の値は，画像の左上を頂点とし，それぞれの数値がピクセル単位であることを記
述することで，画像の矩形範囲を表すElementPointerを定義する．
2-
2-
2. ElementPointer プロセッサ
またElementPointerによって指し示された部分を扱う処理系を同時に作成し，後
述するElementPointerの定義へのアノテーションとして関連付けを行えば，
Annphonyにおいてそのセグメントのプログラム中での取得・利用が可能になる．
ElementPointer プロセッサは，指定された部分の存在確認や，実際に指定され
た部分の取得など，部分同士の演算を行うためのメソッドで構成される．例えば
上記の例のように矩形範囲指定により二次元のメディアを指し示す
ElementPointerプロセッサとして，その矩形範囲の画像を取得して表示するプロ
グラムを用意しておくことで，該当部分が抜き出された画像を容易に扱うことが
可能になる．
2-3. Annphony
楽曲に対する複数の解釈を管理するために，任意のデジタルコンテンツに対する
アノテーションを扱う基盤であるAnnphony を構築
した．以下に概要を述べる．
2-
3-
1. 構造と解釈のためのアノテーション形式
リソースの関係を有向グラフで表現するアノテーション形式としてRDFが提案さ
れている．1.1.1節で述べたように，URIを持つリソースであれば，コンテンツの
形式を問わずアノテーションの対象に指定可能であるため，異種類のコンテンツ
間の関連性を表現することができる．しかし2.1節で述べたように，RDF は一意
の解釈や定義の記述を目的とした形式であり，多様な解釈を記述することに適し
ていない．一方RDFを拡張した形式として提案されているNamed Graphs
[44] は，任意のグラフのまとまりを一意に識別し，他と区別するために，
グラフのまとまりに識別子を付与することができる．図3のように，RDF
では「この楽曲は(主語) Aさんに(目的語) 作成された(述語)」といった，主語・
述語・目的語の3つ組みで記述されるが，Named Graphs はそれに加え，そのアノ
テーションの識別子であるアノテーションURIを持った4つ組みで表現される．本形
式は一つ一つの解釈が区別されることから，複数の解釈を扱う形式として適して
いると考えられる．そこでAnnphonyではNamed Graphsをアノテーション形式の基
礎に採用した．Web上で普及しているURI の枠組みに基づいてアノテーションを
指し示すため，アノテーションの再利用性が高まり，任意のアプリケーションに
よるアノテーションの利用を可能にする．
Annphonyが扱うアノテーションは人により記述されるため，アノテーション自体
の情報が不十分であったり，誤っている場合が考えられる．そのため，そのよう
な人が記述した不十分な解釈のアノテーションに対して，そのアノテーションを
補足するさらなるアノテーションが必要になるだろう．しかしどのようなアノテー
ションに対してさらなる情報が必要であるかを事前に予測することは不可能であ
るため，あらかじめ最小単位のアノテーションに対して識別子が付与される必要
がある．Named Graphsでは，ある楽曲T1と別の楽曲T2についての関連性と，楽曲
T3と楽曲T4についての関連性とを同時に記述し，それらをまとめて一つのURIで
表現することが可能であったが，T1とT2の関連性に対して言及する際に，直接そ
の部分を指し示すことができない．そこでAnnphonyでは任意のグラフのまとまり
に対して識別子を付与することができるというNamed Graphsの機能に制限を加え
る．Named Graphs では，Named Graphsでは図7の右側のようにA，B，
Cの各部分を分離してURIを付与することも可能であるが，左側のようにA，B，C
というアノテーションをまとめたものに対して一つの識別子を付与することもで
きてしまう．この場合識別子が付与されていないA，B，Cの各部分への言及が困
難である．Annphony では，図7 の右側のように，それぞれのリソー
ス記述を明確に分離する．具体的には，あるアノテータが，ある主語(リソース)
に対して述語・目的語の組を列挙したものを一つのアノテーションとし，それぞ
れのアノテーションにURI を発行する．
図7.
Named Graphs(左)とAnnphonyアノテーション(右)
音楽のプレイリスト中に含まれる複数の楽曲を対象としてコメントを付与する場
合など，複数の楽曲という単一ではないリソースを主語としたアノテーションが
想定される．そこでAnnphonyではアノテーションの主語として複数のリソースを
指定することを許可している．また図7の左側においてA，B，C
が何らかの意図を持ってまとめられていたということも，A，B，Cという
複数のリソースを主語とするアノテーションにより表現可能である．
コンテンツの代表的な構造として，グルーピング構造，ツリー構造，グラフ構造
が挙げられる．RDFはリソース間の関係をグラフ構造で表現する形式であり，グ
ラフ構造はツリー構造を内包するため，RDFはこれらの構造を扱うことのできる
形式であるといえる．しかしRDFでは，主語に直接複数のリソースを指定できな
いという，グルーピング構造を表現するために問題がある．そこでAnnphonyでは
それに加え，前述のElementPointerによるコンテンツのセグメント指定と，主語
に複数のリソースの記述を許すアノテーション形式により，コンテンツのグルー
ピング構造を表現する．例えば楽譜中に表れる音符や休符群をまとめて，そのグ
ループに対してイントロやサビなどの楽曲構成情報などを関連付けることが可能
になる．以上よりAnnphonyはコンテンツの代表的な構造に関する情報を扱える基
盤である．
2-
3-
2. アノテーション定義に基づくアノテーション管理
従来のコンテンツの内部構造に言及するアノテーション記述形式
[8][9]は，アノテーション記述のための全ての仕様が固定され
ており，拡張性が低い．そのためこれらの形式で記述することのできないアノテー
ションを利用することが困難である．そこで，Annphonyのアノテーション形式の
ベースであるRDFのスキーマ言語であるRDFSを，アノテーション定義のための言
語に採用した．取得すべきアノテーションの形式をRDFSで記述することにより，
Annphonyはそれに基づく検索やアノテーション利用を支援する．
スキーマ(アノテーション定義)とはデータの構造を決定するものである．図
8にRDFにおけるスキーマとデータの関係を示す．左側のRDFSで
は，アノテーションの種類として「楽曲の基本情報」を定義し，その中では，アー
ティストやタイトルなど複数の属性の記述を許可する．また各属性
のデータ型の指定を行う．図8の右側は，そのスキーマに基づ
いたRDFである．RDFSで定められた「楽曲の基本情報」というアノテーション定
義に則り，アーティストやタイトルなどの属性を指定されたデータ型で記
述する．また，どのリソースを対象としたアノテーションであるかを同時に記述
する．
図8.
RDF SchemaとRDFの関係
Annphonyにおけるアノテーション定義の記述方法を以下に述べる．例として，事
前に決められた「陽気」「刺激的」「厳格」という3種類の印象語のいずれかを値
として持つ「印象情報」という名前のアノテーションを定義する場合を挙げる．
まずこれら3種類の印象語のうちいずれかの値のみを許可するデータ型を定義する．
データ型の定義はXML Schema [45]により記述される．XML Schemaは
XML文書の構造を定義するスキーマ言語の一つであり，柔軟にデータ型を拡張す
ることができる特徴を持つ．一般的にRDFSではXML Schema において定義される
データ型が利用されている．図9に実際のデータ型の定義を示す．
XML Schemaにおいて定義された語彙を{xsd:} という接頭辞を用いて利用す
る．データ型の拡張には{simpleType}を用いる．この例ではXML Schemaで定
義された基本データ型であるstring型を{xsd:restriction} という語彙で拡
張している．{xsd:enumeration}により列挙された3種類の語の中から一つを選
択するためのデータ型が定義されている．
図9.
データ型定義の例
次に，これらの印象語を値として持つアノテーションの定義を図10
のように記述する．RDF，RDFSにより定義されている語彙は，{rdf:}や{\bf
rdfs:}という接頭辞を用いて利用している．RDFSにおいて新しいアノテーション
定義を行うために，まず{rdfs:Class}を記述する．属性として，その定義を
利用するために必要なURIを，{rdf:about}という属性において記述する．
{rdfs:label}にはその定義の名前を，{rdfs:comment} にはさらに詳細
な説明を自然言語で記述する．次に，{rdf:Property}において，利用可能な
属性を定義する．属性にも同様に，属性のURI，名前，説明を記述する．また，
どの定義に対してこの属性が適用されるかを{rdfs:domain}の属性である
{rdf:resource}において指定する．さらに，その属性がどのようなデータ型
であるかを{rdf:range}において指定する．rdfs:Classである{\bf
impression}，rdfs:Propertyである{impression_term}，impression_term
のデータ型である{impressionType}間の関係は図11のように
なる．impression_termのドメインとしてimpression が，rangeとして
impressionTypeが指定されていることがわかる．ここで指定されているデータ型
であるimpressionTypeは，図9において定義した3種類の印象語か
らいずれかを選択するデータ型として定義されている．以上で印象情報のアノテー
ションが定義された．
図10.
''impression''アノテーション型の定義の例
図11.
''impression''アノテーション型の定義間の関係
上記のアノテーション定義に基づいた実際のアノテーションの例を図
12に示す．{an:}はAnnphonyで定義されている語彙を，{def:}
は上記のアノテーション定義を利用するための接頭辞である．この例では図
12で定義した印象情報アノテーションを表す{def:impression}が
指定され，ある楽曲(http://bar/tune.mp3)に「厳格」というアノテーションを
付与している．属性である{rdf:about}のURIは，Annphonyが自動的に発行す
るアノテーションの識別子である．アノテーションの対象となるリソースは{\bf
an:target}に，また，アノテータのURIは{an:annotator}において指定され
ている．楽曲そのものに対してのアノテーションである場合は，{\bf
an:target}としてその楽曲のURIを，ある楽曲の区間に対するアノテーションの
場合，2.1節で述べたElementPointer のURIを記述する．またそれらのリソース
の集合を対象とする場合，図13 のように，RDFのコレクション表現の
ための形式である{rdf:Seq}(順序付リスト)，{rdf:Bag}(順序無し集合)，
{rdf:Alt}(代替表現リスト)を用いて複数の対象を列挙する．印象語を記述
する属性である{def:impression_term}には，図9において定
義された範囲の値を記述する．
図12.
Annphonyにおけるアノテーションの例
図13.
複数のアノテーション対象の指定
このようにAnnphonyはアノテーション定義に基づくアノテーションを管理する．
アノテーション定義は任意のユーザにより記述されるため，Annphony によりコ
ンテンツの内部構造や解釈に対する幅広い種類のアノテーションを管理すること
ができる．2.1節で述べたElementPointer の定義も，本アノテーション定義と同
様の形式で記述されることで，有限個の属性を列挙する定義によって任意のコン
テンツの任意の部分を指し示すことが可能になる．
2-
3-
3. Annphonyの機能
幅広くアノテーションを共有・利用するためには，アノテーションを利用する
環境を整備しなければならない．Annphonyでは，アノテーションやそ
の定義を容易に共有・検索・作成・利用する機能，またコンテンツの構造・解釈
を扱うために必要となる機能を提供する．さらに，アノテーションが潜在的に抱
える問題に対処するための機能を備えている．以下にAnnphonyの主要
な機能について述べる．
[ElementPointerの利用支援]：
AnnphonyはElementPointer を扱う機能を備える．ElementPointer定義のURIと対
象コンテンツのURIを指定し，またElementPointerの定義に沿った属性の値を全
て設定することでElementPointer URIが生成される．逆にElementPointer のURI
から，コンテンツのURIや各引数の値を取得することも可能である．さらに，
ElementPointer定義に記述されるElementPointerプロセッサを登録し，利用する
ための機能を備える．
[アノテーション定義へのアノテーション]：
アノテーションの定義が登録される際，定義の作成者はその定義へのアノテーショ
ンを同時に記述する．具体的には定義者情報，自然言語による利用例などの説明，
「Jazz」，「ニュース」，「判例」など複数のタグによる適用可能なコンテンツ
の列挙を行う．
どのような場面においてその定義が利用可能であるかという情報は，定義の作成
者本人が全て網羅することは困難である場合が多い．そこでAnnphony
では，定義者以外の複数のユーザがそのスキーマに対して利用例やタグなどのア
ノテーションを行うことを許している．またElementPointerの定義へのアノテー
ションの場合，上記のアノテーションに加え2.2節で述べたElementPointerプ
ロセッサを指定する．
またAnnphonyはそれらのアノテーションに基づくアノテーション定義
の検索機能を備えている．アノテーション定義を発見したいユーザは，キーワー
ドでの検索や，適用するコンテンツのタグ情報から絞り込むことで，目的の定義
の発見や，利用・拡張定義が可能となる．
[アノテーション定義に基づくアノテーションの検索]：
幅広いコンテンツへのアノテーションを扱う環境では，動的にアノテーションの
定義が増加することが予想されるが，アノテーションの定義が追加される度に，そ
の定義に基づくアノテーションを利用するようアプリケーションを対応させるこ
とは非常に高コストになる．
Annphonyでは，アノテーション定義の継承関係を考慮し，着目した定
義の継承元や継承先のアノテーションに関しても検索対象とすることができる．
また，ある特定の属性に着目し，その属性が利用されている定義に
基づくアノテーション全てを検索対象にするなど，アプリケーションが，動的に
追加されたアノテーション定義に基づくアノテーションを利用できる機能を備え
ている．
[コンテンツの構造記述]：
様々なコンテンツの構造化に関する研究が行われているが，それらに多く見られ
る手法として，コンテンツのグループ化，または階層化が挙げられる
[8][24]．AnnphonyではElementPointerの採用により，コンテン
ツの任意の箇所のグループ化に対応している．また，コンテンツやアノテーショ
ンを一つのノードとみなし，それらの関係をツリー形式で記述し，そのツリーを
利用する機能を備える．さらに，アノテーションの基本構造としてRDFを採用し
ているため，他のコンテンツとの間の複雑なグラフ構造の関係を扱うことができ
る．
[アノテーション信頼度の導入]：
アノテータに関する情報は，コンテンツの変換や推薦など，個人の嗜好や解釈を
踏まえた応用を実現する際に必須となる．Annphonyではそれぞれのア
ノテータにURI を持たせ，そのプロファイルをアノテーションとして管理する機
能を提供する．
また，あるコンテンツに対し複数の解釈が存在する場合，それぞれの解釈が正確
であるか，または信頼できる情報であるかを判断する必要がある．そこで各アノ
テーションとアノテータに「信頼度」という属性を付与する．信頼度の算出に関
しては，文献[12]において提案された手法を採用した．
アプリケーションはアノテーションの信頼度に基づき，複数のアノテーションの
中から最も信頼性の高いアノテーションを採用したり，信頼度が閾値以上である
全てのアノテーションを採用したりするなど，複数の解釈の扱いを決定することができ
る．
2-4. アノテーションが持つ諸問題に関する考察
2-
4-
1. 埋め込み式アノテーションと外部アノテーション
MP3形式の音楽ファイルにはアーティストやタイトルなどのメタデータをそのファ
イル自身に埋め込むことができ，Exif(Exchangeable Image File Format)形式の
画像には，撮影日時やその画像についての情報を埋め込むことができる．このよ
うなコンテンツの内部にアノテーションを埋め込む方式の場合，コンテンツとア
ノテーションが切り離されないため，利用が容易であるが，コンテンツとアノテー
ションを同時に管理する必要がある．しかし様々な種類のコンテンツを対象とし
たアノテーションを扱う場合，必ずしもコンテンツとアノテーションが同時に管
理されるとは限らない．そのためAnnphonyではコンテンツとアノテーションを切
り離した管理方法を採用している．
2-
4-
2. Orphan/Misleading Annotation への対処
コンテンツとそのアノテーションが分離されている場合，コンテンツの改変・移
動・削除によって，そのコンテンツに関連付けられたアノテーションがOrphan
Annotation(指し先の無いアノテーション) やMisleading Annotation (誤解を生
むアノテーション)になってしまう危険性が指摘されている[18]．
そこでAnnphonyではこれらの問題の発生を抑えるために以下の機能を
提供する．
コンテンツとそのアノテーションが分離されている場合，コンテンツの改変・移
動・削除によって，そのコンテンツに関連付けられたアノテーションがOrphan
Annotation(指し先の無いアノテーション) やMisleading Annotation (誤解を生
むアノテーション)になってしまう危険性が指摘されている[18]．
そこでAnnphonyではこれらの問題の発生を抑えるために以下の機能を
提供する．
一般的にポータルサイトと呼ばれるページや，Webニュースのトップページなど
は，頻繁に更新される．このように，対象となるコンテンツやアノテーションが
編集されることで，そのリソースを指し示しているアノテーションが意味をなさ
なくなったり，別の意味になったりしてしまうことをMisleading Annotationと
呼ぶ．Annphonyでは，アノテーションが編集・再登録された場合，そのアノテー
ションに関連するアノテーションを取得し，それらの確認・編集を管理者に促す．
また一定時間ごとに登録されたアノテーションを巡回してコンテンツの編集の有
無を確認し，編集や削除が確認されたコンテンツに関連するアノテーションに関
しても同様にそれらの確認・編集を促す．
2-5. 実装
実装環境を表14にまとめる．Annphonyは様々なアプリケーション
やアノテーションエディタによるアノテーションやアノテーション定義の登録や
検索の要求などをブラウザなどのWebクライアントから受け付けるため，Webサー
バとして実装されている．Annphony はXML-RPC(XML-Remote Procedure Call)
[46]によって要求を取得し，検索結果の送信などを行う．また，クラ
イアント側はAnnphony APIを用いることでサーバへの要求や，アノテーションの
生成を行う．RDFをJavaで扱うためのAPIとして，Java によるセマンティックWeb
アプリケーション開発のためのフレームワークであるJena[47] を利用し
ている．
図14.
実装環境
2-6. Annphony と各システム間の関係
図14にAnnphonyと後述する音楽アノテーションシステム，アプリケー
ションとの関連を示す．アプリケーション開発者は収集するべきアノテーション
の定義を行い，Annphonyに登録する．既に必要なアノテーションの定義が別アプ
リケーションの開発者により登録されている場合は新たに定義を行う必要は無い．
次章で述べる音楽アノテーションシステムの各アノテーションエディタは，自身
に適用可能であるというアノテーションの付与された全てのアノテーション定義
をAnnphonyから受け取る．アノテーションエディタは取得した定義群から，それ
ぞれの定義がどのようなデータ型の属性を持つかをAnnphony APIを利用し
て解析し，さらに，ユーザが入力可能なアノテーションメニューを動的に構成す
る．メニューの動的な構成法はアノテーションエディタにゆだねられている．例
えばアノテーションエディタは，HTML のフォームを自動生成したり，右クリッ
クメニューを変更したりするなどの処理を行う．ユーザからのアノテーションの
入力を音楽アノテーションシステムのサーバが受け取ると，Annphonyにアノテー
ションを登録する．アプリケーションは，アノテーションエディタを用いて収集
されたアノテーションをAnnphonyを通して取得し利用する．
図14.
Annphonyと各システム間の関係
Annphonyにおいてアノテーションとその定義を管理することで，従来強い依存関
係にあったアノテーション定義とアノテーションエディタ，またアノテーション
とアプリケーションをそれぞれ独立させる．Annphonyにおいて管理されるアノテー
ション定義を参照し，動的にアノテーションエディタを構成することで，柔軟な
アノテーションの取得が見込まれる．またAnnphonyにおいて管理されるアノテー
ションはアプリケーションの種類を問わず利用可能であるため，類似するアノテー
ションを重複して収集する必要がなくなり，アノテーション作成のコストを抑え
られる．
Annphonyは音楽以外のコンテンツへのアノテーションも同時に管理することがで
きる．音楽のアプリケーションのために収集されたアノテーションを，別のコン
テンツのアプリケーションが利用するなど，コンテンツの種類を横断するアプリ
ケーションの実現を支援する基盤であるといえる．
2-7. Annphony がもたらす効果
[メタコンテンツの統合的処理]：
様々な種類のコンテンツに対して付与された，統一した形式による内部構造及び
個人の解釈情報を利用することで，図15のようにそれぞれのコ
ンテンツをメディアの種類によらないメタコンテンツとして捉えることが可能に
なる．今後はメタコンテンツの処理に関する研究が盛んに行われることが期待さ
れる．
図15.
コンテンツからメタコンテンツへ
具体的な応用例としては，例えばビデオのテロップに対するアノテーションに，
テキスト処理のために定義されたアノテーション定義を利用するなど，異種コン
テンツ間でアノテーションを共有し，互いに利用したり，音楽プレイリストを拡
張し，音楽に限らない複合メディアのプレイリストを作成・配信したりするといっ
た，従来困難であった複数のコンテンツの意味内容と個人嗜好を考慮した統合メ
ディア処理が実現されるだろう．
本研究では，特に音楽コンテンツを対象としているが，今後の展望として，現在
複数のコンテンツを横断したアプリケーションとして，ビデオと辞典を組み合わ
せたシステムを構築中である．本システムについては7.3節において述べる．
[オントロジ構築へのアプローチ]：
アノテーションは，人間がコンテンツに対し詳しい意味記述を行うものである．
そのため大量のアノテーションを用いてその解析を行うことにより，リソースの
分類体系やその関係，推論のためのルールなどを定義するオントロジの構築を
実現する可能性を秘めている．
トピックマップ[48]ではリソース全体についてのオントロジ構築を
目指しているが，コンテンツの任意の箇所を分節化するElementPointer は，よ
り詳細なオントロジの構築に役立つと期待される．また図15に
示されるように，アノテーションがコンテンツの種類に依存しない共通の形式で
記述されるため，Webにおける様々なコンテンツにまたがる意味関係を記述され
たアノテーションが増加することになるだろう．Annphonyが様々なコンテンツ管
理システムに組み込まれ，横断的なアノテーションが大量に収集されることで，
それを解析し，様々なコンテンツにまたがったオントロジが構築されるだろう．
2-8. 本章のまとめ
本章では，任意のデジタルコンテンツに対しコンテンツの構造と個人の解釈に関
するアノテーションを作成・利用するアノテーション基盤であるAnnphony
について，アノテーションとそのスキーマの形式と，それらを管理するための機
能に関して述べた．
任意のコンテンツの内部を指し示すElementPointerを提案し，Annphonyに適用し
た．またコンテンツの種類に依存しないアノテーション形式であるRDFを拡張す
ることにより，任意のコンテンツの構造や解釈・関連性を統一的に扱うことがで
きるようになった．またAnnphonyはアノテーション定義の管理を行う
ことで多様化を続けるコンテンツへのアノテーションを柔軟に追加することがで
きる．Annphonyにより，コンテンツの内部を指し示す手法の一般化と，任意のコ
ンテンツに対するアノテーションの枠組みが実現されたことで，図1で
示した既存のアノテーション形式の壁を取り払い，横断的にコンテンツの意味内
容を扱う環境が実現されたと言えるだろう．
今後はネットワーク上にAnnphonyが複数存在する分散環境における協調機能や
アノテーションのアクセス・編集ポリシーについて検討すると共に，実際にアノ
テーションを付与した異種コンテンツによる応用を実現していく予定である．
3. 音楽アノテーションシステム
本章では，音楽に関する多様な解釈を取得するためのシステムとして，音楽アノ
テーションシステムを提案する．まず音楽アノテーションを取得するために必要
な条件を考察し，それに基づいて構築した音楽アノテーションシステムの機能を
述べる．
3-1. 音楽アノテーションの獲得
音楽は嗜好・状況への適応が強く求められるコンテンツであるため，計算機はそ
れを支援するためにコンテンツの意味内容に関するアノテーションを獲得する必
要がある．
一方で，1.1.2節でも述べたように，音楽コンテンツの意味内容の中には，自動
認識することの困難な情報が多く存在する．例えば楽曲から受ける印象は，テン
ポや曲調，歌詞の内容，時代背景などを踏まえて判断する必要があり，一般に自
動的に解析することが困難である．そのため音楽は特に人手によるアノテーショ
ン付与が有効であると考えられる．また同一のリソースに対する異なる解釈を管
理することが必要となる．
現在音楽コンテンツを表現するための様々なメディア形式が提案されている．表
16に主なメディア形式を挙げる．現在広く普及しているMP3等
の音響メディア以外に，単純な文字列列挙によってメロディや和音を表現する
MMLや，楽曲データを電子楽器などとやり取りする規格であるMIDI ，音楽の詳細
な楽譜構造を表現する形式であるWEDELMUSIC XMLやMusicXML が提案されている．
MIDIは図17に示すように，複数のチャンネルごとにイベントとデルタを
記述する形式となる．イベントには，音高や音量など，音を発生させるための情
報を，デルタには何秒間待機するかという情報を記述する．またMusicXMLは図
18に示す構造を持つ．まずタイトルや作曲者などの楽曲の基本情報
を記述し，以降に楽器パートごとの楽譜情報を記述する．各楽器パートは小節ご
とに区切られ，小節内では音符情報が列挙される．このように音楽を表現するメ
ディアには，連続メディアと離散的な構造を持ったメディアといった多様な形式
が存在する．それぞれのメディアは，最小オブジェクトの単位が音符であったり，
サウンドサンプルであったりするなど，粒度も異なる．また今後も新しい形式が
提案されることもあるだろう．そのため音楽という単一種類のコンテンツを扱う
場合であっても，このような連続メディアと離散的な構造を持ったメディアへの
対応や，粒度の異なるオブジェクトへの対応を行わなければならない．
図16.
デジタルコンテンツとしての音楽の主な記述形式
図17.
MIDIの内部構造
図18.
MusicXMLの内部構造}
一般的にコンテンツは，ビデオにおけるシーンや音楽における音符・小節など離
散的な論理的構造を持っており，コンテンツの意味内容に関するアノテーション
を記述するためには，コンテンツの内部構造へのアノテーションが必要となる．
しかしこれらの音楽メディアの持つ情報量や楽曲構造はそれぞれ異なる．それぞ
れアノテーションエディタは，利用する音楽メディアにあわせたインタフェース
を提供し，楽曲の内部へのアノテーションを支援する必要があるだろう．例えば
MusicXMLは楽譜情報を保持しているため，アノテーションエディタはユーザに楽
譜を提示することで，楽曲の詳細な内部に対するアノテーションが記述可能とな
る．
また，どのような種類のアノテーションを利用するかは，実現するアプリケーショ
ンによって異なるため，音楽アノテーションを収集するためのシステムはアノテー
ションの種類を固定してはならない．例えばジャンル情報を固定された10種類の
中から選択するシステムを構築してしまうと，今後新たなジャン
ルが現れた際，そのジャンルを入力することができない．
3-2. 音楽アノテーションシステムの機能
前節からわかるように，音楽アノテーションを獲得するためのシステムは，多様
な音楽メディアに対応し，人手によって様々な種類のアノテーションを付与する
ことが必要である．これらの点を踏まえて，オンライン上のユーザから多くの楽
曲に関するアノテーションを収集するための音楽アノテーションシステムを構築
した．以下に本システムの機能を述べる．
3-
2-
1. Annphony の利用
前章で述べたAnnphonyの有用性を向上させることと，音楽を具体的な題材として，
一般のコンテンツに対するアノテーション獲得・管理するための指針を示すため
に，アノテーション管理のための基盤としてAnnphonyを利用した．また多様なア
ノテーションを収集するために，Annphonyで管理されるアノテーション定義に基
づくアノテーションを収集するシステムとなっている．アノテーション定義とア
ノテーションシステムを分離し，Annphonyにおいて管理されるアノテーション定
義に基づいてアノテーションのメニューを動的に構成するため，収集するアノテー
ションの種類を限定せず，幅広いアプリケーションで利用可能なアノテーション
収集を支援する．
3-
2-
2. Web ブラウザを通したアノテーション
本システムではメタ情報を幅広いユーザから集め，その情報を様々に応用して
いくことを目的としている．しかしアノテーション獲得のためのシステムがスタンドアロン
のシステムであった場合，ソフトウェアのインストール作業やサーバへの接続
作業などに手間がかかるためユーザがそのシステムを利用する際の足かせとな
り，結果多くの情報を集めることが困難である．
そこで，ネットワークにつながっている人なら煩雑な手続き無しでアノテーショ
ンが行えるように，Webブラウザベースシステムの形態をとった．多数のユーザ
から少量のライトウェイト・アノテーションを収集することにより，一人一人に
かかる人的コストを低く抑える．
多人数のユーザを対象とする場合，アノテーションの信頼性を考慮する必要が
ある．そのため前準備として，ユーザはあらかじめユーザ登録を行い，本シス
テムを利用する際にはベーシック認証を通してログインする．誰がどのアノテー
ションを作成したかを全て記述するためである．
3-
2-
3. 3 種類のアノテーションエディタ
様々な種類のアノテーションを取得するために，対象となるリソースの粒度に応
じたエディタを構築する必要がある．楽曲に対するアノテーション付与の代表例
として，CDDB [25]やMusicBrainz [26]が挙げられる．これら
のように，書誌情報などの基本情報を楽曲自体に対するアノテーションが必要で
あり，一方でコンテンツの意味内容に基づく応用のためには，コンテンツ
の内部構造に関するアノテーションが必要である．
そこで我々は，楽曲の形態や取得するアノテーションの種類に応じて様々な粒度
のアノテーション取得を支援するため，1．Tune Annotator，2．Timeline
Annotator，3．Score Annotatorの3種類のエディタを構築した．図19
は音楽アノテーションシステムのトップページである．システムは登録されてい
る楽曲を列挙し，さらにそれぞれの楽曲のメディア形式から，適用可能なアノテー
ションエディタを識別してそれぞれのアノテーションエディタへのリンクを生成
する．それぞれのアノテーションエディタを利用する前提と，付与されるアノテー
ションの粒度を表20に示す．ユーザは本ページを通してアノテー
ションを行う楽曲とエディタを選択する．アノテーション対象となる楽曲は随時
追加可能である．
図19.
音楽アノテーションシステムのトップページ
図20.
各エディタを利用する前提とアノテーション対象となる要素の粒度
以下にそれぞれのアノテーション
エディタの詳細を述べる．
[Tune Annotator]：
Tune Annotatorは書誌情報など楽曲自体に関する情報を収集するためのエディタ
である．タイトルやアーティスト情報などの，楽曲の基本情報の記述にとどまら
ず，楽曲の推薦度やアンケートなどの柔軟なアノテーション取得を支援する．図
21にTune Annotatorの画面例を示す．画面の左側には，タイトルや
アーティストなどの楽曲の基本情報，再生用のプレイヤが配置され，右側にはア
ノテーションメニューがHTMLのフォームとして表示され，ユーザはこのフォーム
を通してアノテーションを記述する．
図21.
Tune Annotatorの画面例
ユーザは記述するアノテーションの項目を動的に変更することができる．図
21の左側はタイトルやアーティストなどの楽曲の基本情報を入力す
るためのアノテーションメニューが表示されているが，ユーザが「アノテーショ
ンの種類」の部分のプルダウンメニューから，記述したいアノテーションの種類を
選択すると，Tune Annotatorは図21の左側のように自動的に該当す
るアノテーションの属性のフォームに変更する．
図21.
アノテーションメニューの動的な変更
本エディタを利用するための条件は，楽曲がURIで表現されることである．つま
り，Web上に存在する全てのメディア形式の楽曲に対してTune Annotatorを利用
したアノテーション収集が可能である．
[Timeline Annotator]：
楽曲の最も単純なセグメンテーション手法は時間による区分であり，エンドユー
ザにとって直感的に理解可能である．そこで，MP3などの連続メディアに
対する時間的なセグメンテーションと，セグメントに対しアノテーションを付与
するエディタであるTimeline Annotatorを構築した．図22に
Timeline Annotatorの画面例を示す．上部の音楽プレイヤで楽曲を鑑賞しながら，
[FROM][TO]ボタンにより開始，終了時間を指定することで時間的なセグメントを
切り出す．さらに[ANNOTATE]ボタンを押すと，図23に示すアノテー
ションフォームが現れる．ユーザはアノテーションの種類を選択すると，アノテー
ションの属性の入力フォームを自動的に構成する．ユーザが各項目に入力
することでアノテーションを行う．図23に例示した音符情報は，3.3
節において連続メディアの構造化を行うためのアノテーションの一つである．
図22.
Timeline Annotatorの画面例
図23.
Timeline Annotatorのアノテーションメニュー例
付与されたアノテーションは，図22の下部にリンクとして表示
され，リンクにマウスポインタを当てることで内容の確認を行う．
楽曲の時間区分の表現形式として，前章で述べたElementPointerを利用している．
セグメントの開始時間，終了時間という二つの属性を持つElementPointer
を定義することで，楽曲の時間的な区間をURIにより表現することが可能になる．
Timeline Annotatorはこの連続メディアの時間区分を表すElementPointer URIを
対象としたアノテーションを記述することで，楽曲の内部へのアノテーションを
実現している．
全ての小節にアノテーションを付与する場合など，開始時間，終了時間の指定を
一定の間隔で行うために，本エディタは一括で時間的セグメンテーションを行う
機能を備えている．図24に表れるセグメント幅と開始時間の秒数を
指定して，「自動セグメント切り出し」ボタンを押すことによって，画面下部に
一定間隔で切り出されたセグメントが表示される．ユーザはそれぞれのセグメン
トをクリックし，そのセグメントへのアノテーションを記述する．
図24.
時間的セグメントの一括切り出し
本エディタを利用するためには，1．楽曲がURIを持ち，2．音楽プレイヤで再生
可能な連続メディアである必要がある．広く普及しているMP3やMIDIなど
のメディア形式に対応するため，実用性の高いエディタであるといえる．
[Score Annotator]：
Score Annotatorは，楽譜に現れる要素の集合に対するアノテーションを付与す
るためのエディタである．アノテーションの付与が可能な楽譜の要素は，各楽器
パートの音符，歌詞，タイトル，作詞者，作曲者，発想記号である．ユーザには
図25のように楽譜とアノテーションを可視化したオブジェクトが重ね
て表示される．ユーザがブラウザに表示された楽譜から，マウスのドラッグによ
り矩形の範囲指定を行うと，矩形内に存在する要素または要素集合が選択され，
赤色で強調表示される．複数の矩形範囲を同時に選択することも可能であるため，
楽譜上で遠い位置に存在する要素に対して同時にアノテーションを付与すること
が可能である．次に図26のように，矩形上でマウスを右クリックし，出
現するメニューからアノテーションの種類を決定し，その後具体的な情報を記述
する．
図25.
Score Annotatorの画面例
図26.
選択したオブジェクトへのアノテーション付与
感想や解説などのアノテーションは，人間が記述する情報であるために，それが
不十分であったり誤っていたりする場合があるだろう．2.3節で述べたように，
Annphonyで管理されるアノテーションには，全て識別子が自動的に付与されるた
め，アノテーションに対するアノテーションを付与可能である．しかしアノテー
ションエディタにもアノテーションへのアノテーションを行う仕組みが必要であ
る．そのため本エディタは，アノテーションを補足，修正するために，画面に出
現するアノテーションオブジェクトに対してアノテーションを関連付ける機能を
持つ．
アノテーションを楽譜上に重ね合わせる場合，アノテーションの量が増えると楽
譜が見づらくなってしまうという問題がある．そこで，本エディタでは表示する
アノテーションを，アノテータやアノテーションの種類からフィルタリングする
機能を持つ．図27は本エディタの左側に表れるアノテーション表
示のメニューである．このメニューから，楽譜上に表示するアノテーションをマ
ウスクリックにより選択すると，表示されるアノテーションをフィルタリングす
る．図28は，kaji，shimizuというアノテータが付与した，和音情報
と楽曲の大まかな構造に関するアノテーションのみを表示した例である．
図27.
アノテーション表示メニュー部
図28.
アノテーションのフィルタリング
本エディタを利用するためには，1．URIを持ち，2．メディア形式が
MusicXML [23] である必要がある．MusicXMLは楽譜を形成するために
十分な情報が記述されており，楽曲の構造を表現する形式であるといえる．音楽
的に構造化されたメディアに対するアノテーションを行うことにより，楽曲その
ものや時間区分といった大まかな対象ではなく，楽譜という音楽の論理構造に基
づいた詳細な対象への言及を実現している．音楽的に意味のある箇所へのアノテー
ションにより，楽曲の意味内容に基づく，より高度な音楽アプリケーショ
ンの実現が期待される．
3-3. 連続メディアの構造化支援
前節で述べたように，音楽アノテーションシステムは楽曲の意味内容に基
づく応用のため，Score Annotatorによるアノテーション付与を実現しているが，
本エディタはMusicXMLという楽曲の論理構造を表す形式でなければ利用できない
という大きな制約がある．現在Web上に存在するメディアの多くはMP3などの連続
メディアであり，音楽の意味内容を考慮したアプリケーション実現のため
に，それらのメディアを構造化する必要がある．そこで連続メディアに対する構
造化の支援を行う機能を構築した．
楽曲の構造化を行うために，タイトルやアーティストなどの基本情報に関するア
ノテーション定義に加え，楽譜生成のために十分な情報をアノテーションとして
記述するための，楽器パートや発音列(音高，音長，音符のタイプ)，歌詞などの
アノテーション定義を用意した．また，それぞれのアノテーション定義をTune
AnnotatorとTimeline Annotatorに適用した．ユーザは楽曲の基本情報をTune
Annotatorを用いて記述する．次にTimeline Annotator を用いて，構造化を行う
連続メディアを時間的にセグメントし，各セグメントの音符情報や小節の情報を
入力する．一つの音符や歌詞の一単語など，一つ一つのアノテーションは楽曲の
断片情報を表現しているに過ぎないが，ある楽曲に付与されたこれらのアノテー
ションの集合から，楽曲全体の楽譜を生成することができる．
次に，音楽アノテーションシステムはこれらのアノテーション集合を解析し，
MusicXMLとそれに対するアノテーションを以下のように生成する．アノテーショ
ン集合から読み取られる，メロディや小節の情報を元に，その楽曲を表
すMusicXMLを生成し，同時にMusicXMLに現れる音符や小節に関する各ノードと，
それに対応する連続メディアの時間区分を対応付けるアノテーションを生成する．
連続メディアを構造化し，MusicXMLを生成することにより，Score Annotatorへ
の適用が可能になる．本機能により，連続メディアを用いた論理構造に基づく応
用を実現することができる．
連続メディアの構造化には音楽的な知識が必要なため，専門性が高い．そのため，
連続メディアの構造に関するアノテーションはWeb上から幅広く収集することが
困難であると予想される．本システムでは人間が作成するアノテーションに加え
て機械が自動的に生成する情報も扱うことができる．
今後はビートトラッキング[49] などの採譜に関する自動処理の結果を
取り込み，その結果を人手により修正することで容易に構造化を行うことができ
るよう機能拡張する予定である．
3-4. システム構成
図29に音楽アノテーションシステムのシステム構成を
示す．アノテーション，アノテーション定義と共に，ユーザ情報をAnnphonyによ
り管理する．音楽アノテーションシステムはWebシステムとして構築されており，
サーバはユーザからのアノテーション対象の楽曲とエディタの種類の要求に応じ
て，Tune Annotator，Timeline Annotator，Score Annotatorのいずれかのエディ
タを提示する．その際システムは対象となる楽曲をアノテーションエディタに取
り込み，同時にアノテーションメニューはAnnphonyのアノテーション定義に基づ
き生成する．ユーザはそれぞれのアノテーションエディタを通してアノテーショ
ンを記述し投稿すると，それを受け取ったWebサーバはユーザ，アノテーション
対象となる楽曲の部分，アノテーションの種類とその内容を基にAnnphonyで管理
する形式のアノテーションを生成し，Annphonyにアノテーションを格納する．
図29.
音楽アノテーションシステムの構成
図29では，同一の楽曲に対するアノテーションをTune
AnnotatorとTimeline Annotatorという二つのエディタにより取得している．こ
のように，同一の楽曲を対象とし，その楽曲自体に対するアノテーションや楽曲
内部のアノテーションなど粒度の異なるアノテーションを取得することが可能で
あるため，より多角的な楽曲の意味内容の把握が可能となる．
3-5. 多様な解釈の顕在化に関する実験
ユーザや楽曲の特性によって解釈に多様性が存在し，個人に適応するアプリケー
ションを実現するために解釈の多様性と個人性を扱う必要があること，またその
ような解釈の多様性を音楽アノテーションシステムによって顕在化させることが
可能であることを実証することを目的とした.
3-
5-
1. 実験方法
「ハイライト」の認識に関する実験を行った．
楽曲のどの部分を，どのような理由でハイライトと認識するかが解釈に相当する．
本実験では，ハイライトの定義を「楽曲の最も印象的な部分」とした．以下に実
験の詳細を述べる．またハイライトと認識する理由の一つに「サビである」とい
う理由が予想されるが，本実験ではサビの定義を「楽曲の中で繰り返しの最も多
い区間」としている．
実験に利用する楽曲は，過去5年におけるオリコン年間売り上げの上位10曲ずつ，
計50曲であり，被験者は20代の男女10名である．それぞれの被験者は，時間区分
に対するアノテーションエディタであるTimeline Annotatorを用い，各楽曲につ
いて，ハイライトであると認識した時間区分を切り出し，同時にその部分をハイ
ライトであると認識した理由を自然言語により記述する．ハイライト区間は，各
楽曲につき一箇所であり，切り出しの長さに制限を設けていない．50曲の楽曲に
対して500箇所のハイライト区間と，645個の理由を収集した．ハイライトである
と認識した理由には複数の記述を許しているため，理由の合計は500個を超えて
いる．
3-
5-
2. 実験の結果と考察
収集されたアノテーションを基に，ハイライトと認識した理由を人手で分類した
ところ，以下の9種類に分類された．
-
サビである
-
聴いたことがある
-
歌詞が良い
-
歌い方が特徴的
-
盛り上がるから
-
メロディが良い
-
リズム・テンポが良い
-
個人的な思い入れ
-
演奏が特徴的
図30はハイライトと認識した理由ごとのハイライト区間の数を表して
いる．従来からハイライトであることが多いとされる「サビである」という理由
以外にも，「聴いたことがある」「歌詞が特徴的」「歌い方が特徴的」という理
由に基づく認識が多いことが分かる．
図30.
理由ごとのハイライト区間数
次にユーザごとのハイライト認識理由の個人性について考察する．図
31にユーザAが，図32にユーザB がハ
イライトだと認識した理由の割合を示す．ユーザAは「サビである」「聴い
たことがある」という理由でハイライトであると認識された箇所が多く，一方ユー
ザBは「歌詞が良い」，「歌い方が特徴的」という理由でハイライトであると認
識する可能性が高いことが読み取れる．このようにユーザごとのアノテーション
を解析することにより，それぞれのユーザの個人性を浮き上がらせることができ
ることを確認した．
図31.
ユーザAにおける理由ごとのハイライト区間数
図32.
ユーザBにおける理由ごとのハイライト区間数
次に切り出されたハイライト区間についての考察を行う．図33
に，ある楽曲のサビ区間と理由別のハイライトを可視化した図を示す．楽曲中で，
多くの被験者がハイライトだと認識した区間ほど濃い色で表されている．一段目
には理由に関わらずハイライトだと認識された区間を表示し，二段目にはサビで
あるという理由で，三段目には歌詞が特徴的であるという理由で認識されたハイ
ライト区間を表示している．一段目から，ハイライトであると認識された区間は
楽曲の多くの区間に渡っていることが分かる．また二段目と三段目には重複する
区間が少なく，大きな違いがあることが分かる．このことからハイライトと認識
する理由によって切り出される区間の多様性を，アノテーションの分類という統
計的な処理によって浮き上がらせることができたといえる．
図33.
ハイライトと認識された区間の分布
楽曲の解釈に関する多様性や個人性を利用することにより，それぞれのユーザに
適応するアプリケーションの実現が可能になると考えられる．例えば楽曲のハイ
ライトを試聴支援に用いる場合，サビを高い確率でハイライトと認識するユーザ
A にとっては，図33の区間A，Bを中心に試聴させることが効果
的であり，歌詞に基づきハイライトを認識するユーザBにとっては区間Cを中心に
試聴を促すことが効果的であると考えられる．実際に図33には
ユーザAが本実験で切り出したハイライト区間Dは，ユーザAにとって試聴支援に
効果的であると思われる区間A，Bに含まれており，またユーザBのハイライト区
間Eも同様に，試聴支援に効果的であると思われる区間Cに含まれている．
本実験により，楽曲の内部構造に関する解釈の多様性と各ユーザの個人性を，本
システムで収集されるアノテーションを解析することによって浮き上がらせるこ
とが可能であること，またこうして導き出された個人性をアプリケーションに適
用可能であることが確認された．
3-6. 本章のまとめ
本章では，音楽を題材として，Web上のユーザから様々な解釈を獲得する音楽ア
ノテーションシステムを構築した．本システムでは，多様な種類の音楽メディア
に対応するために連続メディアの構造化をサポートし，楽曲のメディア形式と取
得するアノテーションの種類に関連して，1:書誌情報などの楽曲自体へのアノテー
ションエディタ(Tune Annotator)，2: 連続メディアに対するアノテーションエ
ディタ(Timeline Annotator)， 3: 楽曲の内部構造に対するアノテーションエディ
タ(Score Annotator)の3種類のエディタを備え，様々な粒度のアノテーション収
集を支援する．またアノテーション定義とアノテーションエディタを独立させる
ことにより，様々なアプリケーションに適用可能なアノテーションを柔軟に収集
することができる．
また，
本システムはMP3等の音響メディアに対しても，Tune AnnotatorとTimeline
Annotator を用いてこれらのメディアの構造化を支援し，音響メディアに対応す
るMusicXML を生成する機能を備える．MusicXMLを生成することで，音響メディ
アに対してもScore Annotatorによる楽譜による音符や歌詞の一部など楽曲の詳
細な要素へのアノテーション付与が可能になる．
本システムを用いることで，楽曲の内部構造に関する解釈の多様性と各ユーザの
個人性を，本システムで収集されるアノテーションを解析することによって浮き
上がらせることが可能であることを実験によって確認した．
今後の課題としては，楽曲に対する多様な解釈の傾向を分析し，他者の解釈への
依存度や解釈の変化の時間的推移などの特徴を明らかにし，多様な解釈を総括す
る解釈を導くこと，また音楽以外のコンテンツに対しても複数の解釈を収集し，
コンテンツの種類を横断するアプリケーションを構築することなどが挙げられる．
4. 楽曲の解釈・構造を用いたアプリケーション
音楽アノテーションシステムにより，様々なアプリケーションに適用可能な音楽
の意味内容に関するアノテーションをWeb上から収集することが容易になった．
楽曲に対する多様な解釈を用いることで，ユーザの個人性に基づくアプリケーショ
ンを実現可能であることを確認するために，楽曲検索システムと楽曲再構
成システムを構築した．以下に詳細を述べる．
4-1. 検索・再構成システムのためのアノテーション定義
楽曲の論理構造に基づく検索のために，Score Annotatorを用いて楽譜に出現す
る要素集合に対するアノテーションを収集した．アノテーションの定義として，
以下の5種類を設定した．
解説や，意見・感想は，楽曲をキーワードで検索する際に有効であると考えられ
る情報である．そこでこれらの情報を自然言語による記述により収集する．また，
ユーザによる解釈のばらつきが多くみられ，個人の感性に適応する楽曲検索に利
用可能であると考えられる情報として，楽曲を鑑賞した際に受ける印象が挙げら
れる．そこで，楽曲の各部分に対し，ユーザが楽曲を鑑賞して受けた印象を
Hevner [50] が提唱した8 種類の印象語(陽気, 刺激的, 厳格, 元気,
悲しい, 夢想的, 穏やか, 上品) から選択し，収集することにした．また，音楽
の構造に基づく検索に有効であると考えられる，楽曲の構成の情報を収集する．
楽曲の構成は，ポップスなどに見られるイントロやサビといった，その曲の大ま
かな構成を記述するためのアノテーションであり，試聴支援[51]
などに利用される価値の高い情報である．コードは楽曲の各セグメントがどのよ
うな和音構成であるかを，基音・サフィックス・ベース音の組により記述する．
コードは，同一の楽曲であっても出版社によって異なる箇所があることから，複
数の解釈が可能な情報の一つと言えるだろう．
楽曲の論理構造に基づく応用を実現するために，ここでは音楽メディアの形式が
MusicXMLである楽曲に限定し，アノテーションを収集した.
4-2. 楽曲検索システム
楽曲の構造や多様な解釈のアノテーションを利用することで，個人の感性に合わ
せた楽曲の内部検索が可能になる．そこで我々は，サビやイントロなどの楽曲の論
理構造に基づき，ユーザの感性に合わせて楽曲の印象検索を行うシステムを構築
した．
4-
2-
1. 検索システムのインタフェース
ユーザが本検索システムにログインすると，図34のように検索フォー
ムが提示される．検索フォームの「アノテーションを用いた検索」では，左側の
リストボックスから楽曲の構造を，右側のリストボックスからキーワードの記述，
印象や楽曲構造，コードを指定することにより，ユーザの検索要求がシステムに
送信される. 検索結果は図35のように，検索ランクが上位の楽
曲から順に列挙される．
図34.
楽曲検索システムの検索フォーム}
図35.
楽曲検索システムでの検索結果
4-
2-
2. キーワード検索
タイトル，作詞者，作曲者，印象，意見・感想，解説の情報に関してキーワード
検索を行うことができる．楽曲の基本情報であるタイトルや作詞・作曲者情報か
らの検索以外に，Web上のユーザが付与したアノテーションに基づく検索が実現
されている．楽曲の基本情報以外の，楽曲の鑑賞を通じて得られた感想などによ
る検索は，ユーザが目的の楽曲にたどり着く支援となると考えられる．
4-
2-
3. コード進行に基づく検索
楽曲の論理構造に基づく検索の例として，コード進行検索を実装した．本検索機
能は作曲の際に参考となる楽曲を参照したり，ある楽曲のコード進行と類似する
楽曲を検出して楽曲同士のミキシングを行うなど，幅広いアプリケーションでの
利用が期待される．
検索要求としてコード進行を入力すると，システムはまず各コードの基音とベー
ス音を相対値に変換する．例えば「C G/B Dm C」というコード進行の場合は
「0,-5/-1,2m,0」となる．次にそれぞれの楽曲のコード進行に対してDPマッチン
グを行い，検索要求との距離を計算し，距離の近い順に正答の候補とする．検索
ランクはDPマッチングの距離の逆数を正規化した値を利用しているため，コード
進行が完全一致する楽曲だけでなく，類似するコード進行が出現する楽曲が検索
結果として提示される．
4-
2-
4. 個人の感性に適応する検索
楽曲に対する多様な解釈を利用し，個人の感性に適応する検索機能として，印象
に基づく楽曲検索機能を構築した．印象情報はユーザ間の競合がしばしば見られ
る情報であるが，類似する感性を持つユーザ同士は，同一楽曲やセグメントから
類似する印象を受ける．そこで本検索システムでは，検索するユーザと，ある閾
値以上感性の類似するユーザが付与した印象アノテーションのみを利用し，楽曲
検索を行う．それぞれのユーザがどのような感性であるかというユーザモデルと
ユーザ間の類似度の閾値は，5章において述べるプレイリスト作成支援システム
のものを用いた．
一般的な楽曲検索の場合，検索結果のランクは検索要求との適合度のみによって
ランキングされるが，本検索システムではアノテータに合わせたアノテーション
のフィルタリングを行うことで，例えばある二つの楽曲に，等しい数の「悲しい」
という印象が付与されていた場合，嗜好の類似したユーザによるアノテーション
が多い楽曲の方が上位にランクされる．ユーザの感性に合わせた検索結果のラン
キングを行うことで，それぞれのユーザが要求する楽曲を適切に提示する．
4-
2-
5. 楽曲の構成に基づく絞込み検索
サビやイントロなどの楽曲の構成は，エンドユーザが容易に認識可能な楽曲の内
部構造であるといえる．そこで本検索システムでは，多くのアノテーション収集
を期待される楽曲の構成情報を用いて，絞込み検索を行う機能を実装した．
「サビが悲しい曲」という検索要求を受け取った場合，「サビ」が絞込みを行う
楽曲の構成であり，検索対象は「悲しい」という印象である．まず，楽曲の構成
以外の検索要求である「悲しい」について，前述の印象に基づく検索を行う．こ
の時の検索結果のランクを計算する．この時の検索結果のランクを
$\mathrm{priorrank}$とする．次に，絞込む楽曲の構成「サビ」の部分に対する
「悲しい」などの含有率$\mathrm{contains}$を計算し，含有率に基づき絞込み
検索のランクを決定する．
「サビ」のアノテーションが付与されている音符，休符などの音楽オブジェクト
が$o_i$，$o_j$，…の要素であり，その要素数は$k$であるとする．また，「悲
しい」というアノテーションが付与されている音楽オブジェクトは，$o_l$から
$o_m$までで，その要素数は$n$ であるとし，これら二つのアノテーションが共
通して付与されているオブジェクトの要素数は$p$であるとすると，含有率
$\mathrm{contains}$は以下の式で求める．
\mathrm{contains}=\max\left(\frac{p}{k},\frac{p}{n}\right)
「サビ」の部分に多く「悲しい」の要素が含まれている場合，または「悲しい」
と関連付けられた要素が多く「サビ」に含まれている場合に
$\mathrm{contains}$が高くなる．最終的な絞り込みの検索ランクは以下の式で
表される．
\mathrm{rank}=\mathrm{contains}\times\mathrm{priorrank}
本機能により，楽曲の論理的なセグメントの検索が可能となり，引用・要約など
様々なアプリケーションにおいてそのセグメントを利用可能に
なる．
本節で述べた個人適応された楽曲の内部検索は，楽曲要約や編曲など様々な音楽
アプリケーションにおいて，利用する楽曲やその部分を選出する導入部として利
用可能であると考えられる．
4-3. 楽曲再構成システム
本研究で実装する再構成システムは，MusicXMLが元から持っている歌詞・楽器パー
トの情報に加え，ユーザからアノテーションとして収集した楽曲の構成情報を用
いて，楽曲の鑑賞したい部分を選択することにより，曲を再
構成し，ユーザに提示するシステムである．例えばサビだけ抜き出したいといっ
た要求や，「イントロ-サビ-エンディング」というように，曲を要約したいといっ
た要求に応える．以下に本システムのインタフェースと実装を述べる.
4-
3-
1. 楽曲再構成システムのインタフェース
再構成システムを実現するために，曲の構成というアノテーションが必要とな
るが，前述の音楽検索システムのため，既に曲の構成のアノテーションが作成さ
れているので，簡単のため，再構成用に新しくアノテーション定義XMLを記述せ
ず，検索用に生成されたアノテーションを利用する．
ユーザは再構成を行いたい曲を選択することで再構成システムにログインする．
図0はログイン直後の再構成システムの画像である．本再構成システ
ムは，曲の構成，楽器パート，歌詞による音楽コンテンツの再構成を行う．
図36.
再構成前の画面
左のフレームが再構成システムのメニューとなっている．曲の構成による再構成
を行いたい場合は，＜パート＞の部分にある曲の構成から，表示したい部分を選
択する．歌詞の有無を変更したい場合は，＜歌詞＞の部分のセレクトボックスに
チェックを行い，楽器パートを選びたい場合は，＜楽器パート＞の部分にあるチョ
イスボックスから，表示したい楽器パートを選択する．選択が終了したら「再構
成」のボタンをクリックすると，曲の構成，歌詞の有無，楽器パートの選択を反
映させた楽譜が表示される．
また，こうして再構成された音楽コンテンツのMusicXMLをダウンロードすること
も可能である．
上記のように，歌詞，楽器パート，曲の構成により再構成したMusicXMLが生成さ
れる．このMusicXMLからブラウザに表示できるSVG(Scalable Vector
Graphics)[52]形式の楽譜を生成しブラウザに表示し，同時に，再構成済
みのMusicXMLをファイルとしてサーバに保存し，ユーザはそれをダウンロード
することができる．再構成後の画面は図37のようになる．図中の左側に表示さ
れる，再構成メニューから，Aメロ(verse-a)とサビ(chorus) の二つのパートが
選択されており，それらのパートのみを抜き出して短縮された楽譜が表示されて
いる．
図37.
再構成後の画面
4-
3-
2. 楽曲再構成システムの実装
MusicXMLには，歌詞や，楽器パートの情報が含まれているため，歌詞と楽器パー
トによる再構成は，元の音楽コンテンツであるMusicXMLのみを利用して実現する．
歌詞はMusicXMLでは図38のように音符であるnoteタグの内部にlyricタ
グとして記述されている．
図38.
MusicXMLにおける歌詞の記述
また楽器パートは，MusicXMLでは図39のように，part-listとして定義
し，さらにそれぞれの楽器パートについて演奏情報が記述される．楽器パートに
よる再構成では，P1，P2といった楽器パートのIDを取得し，MusicXML の
part-listタグから残しておくID以外のscore-partタグを削除し，さらに
part-list以降に記述されているpartタグも，残しておくIDのもの以外は削除す
る．
図39.
MusicXMLにおける楽器パートの記述
アノテーションである楽曲の構成情報に基づく再構成について説明する．例えば
音楽コンテンツが「きらきら星」であり，その楽曲を「イントロ- サビ-エンディ
ング」という再構成するよう要求された場合，まずシステムはアノテーションが
格納されたデータベースから，「きらきら星」の内部要素に対して付与されたア
ノテーションのうち，「イントロ」「サビ」「エンディング」という楽曲構成の
アノテーションを全て検索する．次にそれらのアノテーションの指し先である楽
譜中の要素を全て抜き出し，「イントロ-サビ- エンディング」という順番にそ
れらを列挙した新しいMusicXMLを作成し，再構成した楽譜をユーザに提示する．
同一の要素に対して，複数のユーザが異なる楽曲構成アノテーションを付与して
いる場合，再構成システムを利用しているユーザの嗜好と類似するユーザが付与
したアノテーションを優先させる．多様な解釈から，ユーザにとって適切なアノ
テーションを選出することで，本システムも楽曲検索システムと同様に，個人の
解釈に適応させる．また本システムは，楽曲の論理構造であるサビやイントロな
どの大まかな構成，楽器パート，歌詞などの情報を基に，楽曲を容易に再構成す
ることから，コンテンツの意味内容に基づきコンテンツ変換を行うアプリケーショ
ンの一つであるといえる．
4-4. 本章のまとめ
音楽アノテーションシステムにより収集が容易になった楽曲アノテーションを用
いたアプリケーションとして，楽曲検索システムと楽曲再構成システムを構築し
た．
まずそれぞれのシステムで利用するアノテーションをAnnphonyに登録し，音楽ア
ノテーションシステムを通して楽曲の構成や意見などのアノテーションを収集し
た．楽曲検索システムではそれらの情報を用いて，楽曲の論理構造であるコード
進行に基づく検索や，楽曲の構成による絞込み検索を行う機能を持つ．また検索シ
ステムを利用するユーザの解釈に類似するユーザが付与したアノテーションを優
先的に用いることによって，楽曲の印象検索などをユーザの感性に適応させる．
また楽曲再構成システムは，楽曲の論理構造であるサビやイントロなどの大まか
な構成，楽器パート，歌詞などの情報を基に，楽曲を容易に再構成するシステム
であり，楽曲検索システムと同様に，ユーザの解釈と類似するユーザが付与した
アノテーションを優先的に利用し，ユーザの感性に適応させる．
これらのシステムから，音楽アノテーションシステムを用いて獲得されたアノテー
ションを用いて，楽曲の論理構造やユーザの感性に適合させるアプリケーション
を実現可能であることが示された．今後の課題としては，これらのシステムを評
価するための実験を行い，ユーザの感性に適合させるために必要なシステムの要
素を検討することが挙げられる．
5. コミュニケーションメディアとしてのプレイリスト
近年大容量の携帯音楽プレイヤが登場し，インターネット上に多数の音楽コン
テンツが存在するようになり，いつでもどこでも容易に音楽を楽しむことが可能
になった．またネットラジオなどのデジタルコンテンツを自動的にiPodに転送す
るPodcastingというサービスが現在利用可能である．自分に合ったコンテンツを，
インターネット上の膨大なコンテンツの中から自動的に携帯音楽プレイヤに取り
込みたいという要求が高まっている．
そのため楽曲推薦やプレイリストの自動生成に関する研究が盛んに行われている．
既にiTunes Storeなどのインターネットを通じた音楽配信サービスがいくつか利
用可能である．また近い将来，定額制サービスが音楽配信にも適用されるだろう．
そのような環境下では，多くのユーザ間において，楽曲のIDのみで構成されるプ
レイリストが共有されることになるだろう．
また現在ブログやSNSにより，インターネット上での
テキストや絵，写真などによる活発な個人間コミュニケーションが行われている．
音楽は多くの人にとって容易に作成できないメディアであるが，プレイリストは
テキストや写真などと同様，容易に作成することができ，また作成者の意図や感
情を込めることができる．我々は今後プレイリストがテキスト・絵・写真と同様，
重要なユーザ間のコミュニケーションメディアになると考えている．以降プレイ
リストを介したコミュニケーションをPlaylist-Mediated Communicationと呼ぶ
ことにする．
従来の楽曲推薦に関する研究は，協調フィルタリングによるプレイリスト生成シ
ステム[30][32] やジャンル，アーティストなどの情報
を利用したプレイリスト生成[53]などがある．しかし，楽曲推薦やプレ
イリスト生成に有効である情報の中には収集することが困難であるいくつかの主
観的・個人的な情報が存在する[54]．そこで，3章で述べた音楽アノテー
ションシステムにより，プレイリスト作成に有効な情報をWeb上のユーザから取
得し，利用する．
Playlist-Mediated Communicationを実現するために必要な要素は，プレイリス
トの作成・推薦・鑑賞といった活動を活発にすることであると考え，そのための
プレイリスト推薦の手法を提案する．本システムの実現により，プレイリスト作
成・推薦の促進を実現することができるであろう．プレイリストをコミュニケー
ションメディアとして利用されるようにするためには，あるユーザが作成したプ
レイリストを，他のユーザが容易に参照可能である必要がある．そこで本システ
ムをWebサービスとして設計する．Webサービスであれば，インターネットを介し
た他のユーザとの円滑な意見交換やプレイリスト推薦の実現が期待される．
本章ではPlaylist-Mediated Communicationを実現するために，構築したプレイ
リストの作成とコミュニケーションを支援するためのシステムについて述べる．
まずプレイリストの作成支援のために必要な楽曲特徴量を考察し，それに基づい
てアノテーション定義を用意する．次にそれらのアノテーションを用いて，楽曲
群からプレイリストの作成支援を行う仕組みについて述べる．さらにそうして作
成されたプレイリストを介して解説や感想などを交換し合うコミュニケーション
機能について述べる．最後に本システムによって作成されるプレイリストがユー
ザの嗜好や状況に適応しているかどうかを確認するための実験を行う．
5-1. プレイリスト作成支援システムのためのアノテーション定義
ジャンルやアーティスト，歌詞など，一般的に楽曲推薦に利用すると効果的であ
るとされている楽曲の特徴量がいくつか存在する
[55][56]．一方，日常生活における音楽との接し方から
推測されるように，リスナの置かれている状況が，推薦するべき楽曲の選択に強
く影響すると考えられる．そこでリスナの嗜好と状況に合ったプレイリスト推薦
システムを実現するために，楽曲の特徴量として歌詞・表現している情景(楽曲
情景)・聴きたい状況(鑑賞状況)の3種類を採用した．
楽曲情景は，「片思いの心象を歌った曲」や「卒業・別れの曲」など，その楽曲
がどのような情景を表現しているかという情報であり，個人嗜好への適応に有効
であると考えられる．鑑賞状況は，「海に大勢で遊びに来ている時」，「恋人と
二人のクリスマスの夜」など，その楽曲をどのような状況で聴きたいかという情
報であり，状況への適応に有効であると考えられる．楽曲情景，鑑賞状況に関す
る情報はリスナによる楽曲の解釈に強く関わる情報であるため，楽曲の音響情報
を自動解析して得ることが困難である．そこで，3.2.3節で述べたTune
Annotatorにより各楽曲に対して楽曲情景と鑑賞状況の情報を収集した．
楽曲情景・鑑賞状況アノテーションの定義にあたり，事前の予備実験において，
どのような楽曲情景，鑑賞状況が存在するかを調査し，いつ・どこで・どのよう
な心理状態であるかという項目を設定した．表40に，収集した鑑
賞状況アノテーションの項目を示す．例えば「いつ」に関しては，朝，昼，夜，
春，夏，秋，冬などの項目が設定されており，それらの中からその楽曲を鑑賞す
るのに適した時間・時期を選択する．各楽曲に対するこれらの情報をAnnphonyに
アノテーション定義として登録し，音楽アノテーションシステムのTune
Annotatorを用いてアノテーションを収集した．
図40.
鑑賞状況に関するアノテーション項目
5-2. 歌詞とアノテーションによる楽曲・ユーザ間の類似度推定
歌詞のTF*IDF [57]，楽曲情景，鑑賞状況の3種類をそれぞれの楽曲の特
徴量とした．$l_{t_i}$， $c_{t_i}$，$s_{t_i}$を歌詞・楽曲情景・鑑賞状況の
各特徴量空間における楽曲$t_i$の特徴ベクトルとする．$l_{t_i}$， $c_{t_i}$，
$s_{t_i}$は以下のように列ベクトルで表される．
l_{t_i}=(f(t_i,x_1),f(t_i,x_2),...,f(t_i,x_n))
c_{t_i}=(f(t_i,y_1),f(t_i,y_2),...,f(t_i,y_o))
s_{t_i}=(f(t_i,z_1),f(t_i,z_2),...,f(t_i,z_p))
TF*IDFによって求められたキーワードの数は$n$であり，$x_j$は$j$番目のキー
ワードを表している．$f(t_i,x_j)$は楽曲$t_i$の歌詞中に，キーワード$x_j$が
含まれていれば1，含まれていなければ0となる．$o$，$p$はそれぞれ楽曲情景，
鑑賞状況アノテーションに設定された項目数であり，$y_j$，$z_j$は，それぞれ
楽曲情景，鑑賞状況アノテーションの$j$番目の項目を表している．また
$f(t_i,y_j)$，$f(t_i,z_j)$は，楽曲$t_i$に対する楽曲情景，鑑賞状況アノテー
ションとして，$y_j$，$z_j$の項目が選択されている場合は1，選択されていな
い場合は0となる．
各特徴量空間における楽曲間の類似度は，特徴ベクトル同士のコサイン距離によ
り得られる．また歌詞・楽曲情景・鑑賞状況の特徴量空間で得られた各コサイ
ン距離の重み付き和を，最終的な楽曲間の類似度とした．
一方，各ユーザとプレイリストも各特徴量空間にマップされる．
ユーザ$u_j$の特徴量は以下の式により求められる．
l_{u_j}=\frac{\sum _{i}l_{t_i}}{i}
c_{u_j}=\frac{\sum _{i}c_{t_i}}{i}
s_{u_j}=(f(u_j,z_1),f(u_j,z_2),...,f(u_j,z_p))
ユーザ$u_j$が嗜好に適合するとシステムに申告された$t_i$で表される楽曲の集
合に対して，特徴量の平均をそのユーザの嗜好に最も適合する楽曲であるとし，
ユーザは歌詞・楽曲情景の特徴量空間にマップする．さらにユーザ自身が現在置
かれている状況をシステムに入力した時点で鑑賞状況の特徴量空間にもユーザが
マップされる．プレイリストも同様に，プレイリスト要素である楽曲の鑑賞状況・
歌詞ベクトルの平均値と，そのプレイリストが作成された状況から，それぞれの
特徴量空間にマップされる．
l_{p_k}=\frac{\sum _{m}l_{t_m}}{m}
c_{p_k}=\frac{\sum _{m}c_{t_m}}{m}
s_{p_k}=\frac{\sum _{m}s_{t_m}}{m}
プレイリスト$p_k$中に含まれる楽曲$t_m$で表される楽曲の集合に対して，各特徴量
の平均をそのプレイリストの特徴量とする．楽曲間の類似度計算と同様に，コサ
イン距離の重み付き和により，楽曲とユーザ間，ユーザとプレイリスト間などの
類似度が算出される．
5-3. プレイリスト作成支援システム
図41にプレイリスト作成の流れを示す．まずユーザは本システムに，
「冬の夜，一人で考え事をしている」といった現在ユーザが置かれている状況を
図42の状況入力フォームから該当する項目を選択することにより
申告する．システムは，データベース中のプレイリストからユーザに適したプレ
イリストを選出する協調フィルタリングを行う．次に選び出されたプレイリスト
を，よりリスナの嗜好に適合させるトランスコーディングを施しユーザにプレイ
リストを提示する．さらにシステムとリスナのインタラクションによりリスナの
嗜好に適応していく．以下に詳細を述べる．
図41.
プレイリスト作成の流れ
図42.
状況入力フォーム
5-
3-
1. 協調フィルタリングによる基プレイリストの絞込み
ユーザの置かれている状況をシステムが受け取ると，まずシステムは過去に作成
されたプレイリストの中から，ユーザの嗜好モデルと類似し，さらに現在のユー
ザの状況と類似する状況で作成された基プレイリストをデータベースから選出す
る協調フィルタリングを行う．
システムはそれぞれのユーザのプレイリスト作成履歴から，そのユーザの嗜好に
合った楽曲集合を保持している．ここで，ユーザにとって最も嗜好に合う楽曲が
存在し，その楽曲はユーザの嗜好に合った楽曲集合を元に推測できると仮定した．
そして歌詞と楽曲情景の特徴量に関してそれぞれユーザの嗜好に合った楽曲集合
の平均を計算し，図43のようにそれぞれの特徴量空間にマップする．
また，ユーザの置かれている状況に関しては，本システムの鑑賞状況入力フォー
ムからの入力に基づき，ユーザを鑑賞状況の特徴量空間にマップする．鑑賞状況
入力フォームの項目は，5.1節で述べた各楽曲に対する音楽アノテーションシステム
における鑑賞状況の項目と同等である．
図43.
歌詞・楽曲情景・鑑賞状況の特徴量空間
5-
3-
2. 基プレイリストの個人への適応
次に基プレイリストをさらにユーザの嗜好に適合させるトランスコーディングを
施す．具体的には，ユーザが過去に嗜好に合わないとシステムにフィードバック
した楽曲を取り除き，楽曲データベースから代わりの楽曲を選んで追加する．同
時に，ユーザが鑑賞経験のない楽曲を3割の割合で含ませている．聴き慣れ
た楽曲の中に適度に鑑賞経験のない楽曲を挿入することで，ユーザの嗜好の幅を
徐々に広げる効果が期待される．
嗜好に合わない楽曲などの代わりに追加する楽曲は，ユーザの嗜好と，置かれた
状況から，各特徴量空間におけるユーザと楽曲の類似度を踏まえて選出される．
ユーザと楽曲間の類似度は，5.2節で述べた楽曲間の類似度計算と同様の計算式
から導き出される．
5-
3-
3. インタラクションによるプレイリスト更新
以上の処理を経てユーザには図44のようにプレイリストが提
示される．作成されたプレイリストは左側に，プレイリストを介したコミュニケー
ションを行う部分は右側に表示される．ユーザはプレイリスト上部に埋め込まれ
たプレイヤから，通常の音楽プレイヤと同様の操作でプレイリストを楽しむこと
ができる．
図44.
ユーザに提示されるプレイリスト
ユーザは実際にプレイリストを鑑賞し，各楽曲が嗜好に合っているか，状況に合っ
ているかといった情報をフィードバックする．画面左側に楽曲リス
トと共に表示される「○」「×」を選択して申告する．また現在のプレイリスト
から，入れ替えを行いたい楽曲の「入替」のボックスをチェックする．システム
はユーザからのフィードバックを受け取り，気に入らない・現在の状況に適して
いない楽曲の入れ替えを行い再度ユーザにプレイリストを提示する．
このように協調フィルタリングとトランスコーディングによって自動的にプレイ
リストを生成し，そのプレイリストをユーザとのインタラクションによって洗練
していくことで，ユーザが大量の楽曲群からプレイリストとなる楽曲を選択する
よりも低いコストでプレイリストを作成することができる．
5-
3-
4. プレイリストの人手による編集
図44の左下に現れる''manual edit''ボタンを押すと，図
45のようにユーザ自身が登録楽曲中から選択した楽曲を追加
したり，プレイリスト中の楽曲を削除するプレイリスト編集ページが表示される．
登録されている楽曲のアーティスト，アルバムのリストが上段左側と上段中央に
表示され，それらを選択し，プレイリストに追加する楽曲の候補を絞り込むこと
により下部左側に選択されたアーティスト・アルバムの楽曲一覧が表示される．
ユーザは楽曲タイトルの右に現れるaddボタンを押すと，楽曲一覧の右側に現れるプレイ
リストに楽曲が追加される．またプレイリストの楽曲タイトルの左に現れる
delete ボタンを押すと，編集中のプレイリストから該当する楽曲が削除される．
また楽曲を選択し，矢印のボタンを押すことによりプレイリスト中の楽曲の順序
を変更することができる．
図45.
プレイリスト編集画面
プレイリストを人手により作成・編集する際に最も時間を要するのが，膨大な量
の楽曲の中からどの楽曲を選択したらよいかを決定する作業である．そこで本シ
ステムではその作業の時間を短縮するよう，嗜好と状況に基づいてプレイリスト
に追加する候補となる楽曲を自動的に絞り込む機能を備える．画面上部右側に現
れるフィルタリングのメニューから，絞り込む楽曲数を入力し，ボタンを押すこ
とでユーザの嗜好とユーザの状況に最も適合する楽曲から，指定された数までの
楽曲を検索し，画面下部左側に表示する．
5-
3-
5. インタラクション内容に基づくユーザモデルの更新
ユーザの嗜好モデルは，本システムに対して，それぞれの楽曲が嗜好に合うかど
うか，また状況に合っているかどうかというフィードバック情報を用いて順次更
新される．TF*IDFで得られるキーワード数が$x$である場合，歌詞の特徴量空間
における初期状態の基底は，$x$次元単位行列と同等の標準基底である．ユーザ
が嗜好に合っているとフィードバックした楽曲群と，合っていないとフィードバッ
クした楽曲群を用い，各ベクトル空間の基底をユーザの嗜好に適応させる．その
ためベクトル空間の基底はそれぞれのユーザについて異なる．以下は歌詞の特徴
量空間における基底をフィードバックに応じて変化させるための式である．
\mathrm{b}_{u}\leftarrow\mathrm{normalize}(\mathrm{b}_u+\mathrm{diag}(\delta\frac{s
l_{f}-l_{u}}{|l_{f}-l_{u}|}-\delta\frac{l_{d}-l_u}{|l_{d}-l_u|}))
$\mathrm{b}_{u}$はユーザ$u$の歌詞の特徴量空間における基底である．$l_{f}$
はフィードバックによって嗜好に合っているとされた楽曲の歌詞特徴ベクトルの
平均であり，$l_{d}$ は嗜好に合わないとされた楽曲の歌詞特徴ベクトルの平均
である．$l_u$は，ユーザ$u$がこれまでに嗜好に合っているとフィードバックし
た楽曲全体の歌詞特徴ベクトルの平均である．一回のフィードバックにおいてど
れだけ基底を変化させるかを決定する変換レートは$\delta$で表されている．本
システムでは経験的に$\delta$ の値を設定している．$\mathrm{diag}$は列ベク
トルを対角行列に変換する関数である．
例えばユーザが「愛」というキーワードの入った楽曲を嗜好に合うとし，「死」
というキーワードの入った楽曲を嗜好に合わないとフィードバックした場合，上
記の基底変換により，歌詞の特徴量空間は図46に示すように愛の要素が
短縮され，死の方向へ拡張される．特徴量空間を嗜好に合った楽曲の方向に短縮
し，嗜好に合わない楽曲の方向に拡張することで，ユーザの好む楽曲とユーザの
間の距離を縮め，逆にユーザと嗜好に合わない楽曲同士を遠ざける．楽曲情景と
鑑賞状況の特徴量空間についても同様に，アノテーションの項目数を$y$，$z$と
した場合，$y$，$z$次元単位行列を初期状態とし，ユーザからのフィードバック
ごとに基底をユーザに適応させる．ユーザ間の類似度計算の際の基底変換には，
プレイリストを作成する主体となるユーザの基底を用いる．
図46.
歌詞の特徴量空間の基底変換前(左)と後(右)
5-4. プレイリストを介したコミュニケーション
後に6.3節で述べるように，コンテンツはコミュニケーションのために必要不可
欠な存在である．そのためコンテンツの作成支援を行うことは人間同士のコミュ
ニケーションを支援することにつながる．しかし，計算機はコミュニケーション
のためのコンテンツを作成する支援を行うだけではなく，作成されたコンテンツ
を用いた実際のコミュニケーションに対しても支援を行うことが必要であると考
えられる．そこで本システムは前節で作成したプレイリストを中心としたコミュ
ニケーションを行うために，プレイリストを共有し検索する機能，解説や感想な
どを記述するための機能を備える．以下に詳細を述べる．
ユーザが作成したプレイリストはデータベースに保管され，他のユーザによる検
索・鑑賞が可能である．図47にプレイリストの検索画面
を示す．ユーザはプレイリストに含まれる楽曲の情報や，プレイリストの作成者，
プレイリストに対するライナーノーツなどからの検索を行うことができる．
図47.
プレイリスト検索画面
ユーザは作成したプレイリストや，検索し鑑賞したプレイリストが気に入った場
合，図44の左側上部に現れるボタンを押すことで，そのプレ
イリストを他のユーザに推薦することができる．プレイリスト推薦の情報は，基
プレイリストを選出する協調フィルタリングの際に，プレイリストの重みとして
利用される．多くの嗜好の類似するユーザに支持されるプレイリストは基プレイ
リストとして選出されやすくなる．
またプレイリストやそれに含まれる複数の楽曲に対するライナーノーツ(解説)や
感想の記述が可能である．他のユーザにより記述されたライナーノーツは左側の
下部に表示されている．それぞれのライナーノーツをクリックすると，右側の該
当する楽曲がハイライトされる．ユーザは図44の左側に現れ
る入力フォームから，そのプレイリスト全体に対するライナーノーツを記述する．
プレイリスト中の複数の楽曲に対してライナーノーツを記述する場合は，右側の
プレイリストから複数の楽曲を選択すると，入力フォームが出現し，選択した楽
曲に対するライナーノーツを記述することができるようになる．
以上のようにプレイリストの作成とプレイリストを中心としたコミュニケーショ
ンを支援する機能を備えることで，プレイリストに対する意見交換などのコミュ
ニケーションに触発されて，そのプレイリストから新たなプレイリストが派生さ
せるユーザが増加することになるだろう．多くのプレイリストの派生は，プレイ
リストを中心としたコミュニケーションの促進につながると考えられる．このよ
うに本システムはコンテンツの増加・価値の向上とコンテンツを中心としたコミュ
ニケーションの間の正の循環を促す可能性がある．
5-5. ユーザモデルの適応に関する評価実験
5-
5-
1. 実験方法
評価実験に利用した楽曲はRWC音楽データベース[58]のPOPS100曲と，一般
のPOPS130曲である．事前に各楽曲に対して，5.1節で述べた楽曲情景・鑑賞状況
に関するアノテーションを収集し，その情報を楽曲の特徴量として利用した．
構築したシステムの評価を行うため，7人の被験者に対して以下の手順で評価実
験を行った．まず自由に自分の置かれている状況を設定してもらい，本システム
の鑑賞状況入力フォームから入力してもらう．システムは各被験者の嗜好と，入
力した鑑賞状況に適したプレイリストを提示する．そこで実際にプレイリストを
鑑賞してもらい，各楽曲に対して嗜好に合っていたか，状況に合っていたかの情
報をチェックしてもらい，システムにフィードバックしてもらう．システムは受
け取った情報を基にプレイリスト作り変え，再びユーザにプレイリストを提示す
る．以上の行為をプレイリストのすべての楽曲が嗜好・状況共に合ったものにな
るまで繰り返してもらう．以上のプレイリスト作成プロセスを，3回繰り返して
もらった．
本システムによってユーザの嗜好・状況に合っているプレイリストを作成されて
いるかどうかを確認するため，各プレイリスト作成プロセスにおいて，鑑賞状況
入力後提示されるプレイリスト中に，嗜好に合う楽曲・状況に合う楽曲・嗜好と
状況に合う楽曲はそれぞれ何曲存在したか，またすべての楽曲が嗜好と状況に合
うまで行ったインタラクションの回数を評価した．
5-
5-
2. 実験の結果と考察
評価実験の結果を図48に示す．それぞれのグループは3種類のバー
によって構成されており，左から1回目，2回目，3回目のプレイリスト作成プロ
セスにおける評価値である．各バーの頂点の矢印は各評価値の標準偏差を表して
いる．
図48.
評価実験の結果}
図48の左から2番目に表される嗜好に合った楽曲数のグラフと，
左端の嗜好・状況共に合った楽曲数のグラフからは，プレイリスト作成プロセス
を重ねるにつれてユーザに合った楽曲数が増加していることが読み取れる．また
右端のインタラクションの回数は，徐々に減少していることがわかる．このこと
から本システムを長く利用するユーザほど，嗜好と状況に合ったプレイリス
トを，少ないインタラクションにより得ることができるといえる．
一方，左から3番目のグループに現れている，状況に合った楽曲数のグラフでは，
1回目，2回目，3回目とプレイリスト作成を繰り返すことによる増加傾向は見ら
れない．鑑賞状況に合った楽曲提示については，プレイリスト作成を繰り返すこ
とにより改善されているとはいえない結果であった．
この結果は以下の2つの問題点が原因となって起こったと考えられる．一つ目は
本システムで入力を要求する鑑賞状況項目の組み合わせが，利用できる楽曲数に
比べて非常に多いという点，二つ目に，各楽曲に対して収集した楽曲情景・
鑑賞状況のアノテーションは各楽曲に均一に付与されているわけではな
いという点である．
前者の問題点に対しては，より多くの評価実験を繰り返し，鑑賞状況項目をより
効果的な項目に絞り込み，同時にプレイリストの要素として利用可能な楽曲数を
追加することで対応できると考えられる．後者の，情報の偏りに関する問題は，
一般ユーザを対象としたアノテーション獲得のためのシステムにおいては，コンテンツの人気
などにより頻繁に発生する問題である．この問題を解決するために，ユーザをア
ノテーションが不足しているコンテンツに誘導したり，リスナの鑑賞履歴などを
利用することでアノテーションの均一化を図る仕組みが必要となる．
しかし鑑賞履歴のような情報は，アノテーション獲得のためのシステムから付与された情報と
比べて一般的に信頼性に劣るため，そういった情報を適用するためには，各アノテー
ションの重みを考慮する必要がある．
5-6. 本章のまとめ
音楽アノテーションシステムにより収集されたアノテーションを用いて，個人の
嗜好と状況に適合する音楽アプリケーションを実現した例として，プレイリスト
にまつわる作成・推薦・鑑賞といった活動を活発にすることで
Playlist-Mediated Communicationが実現されると考え，プレイリストの作成支
援とプレイリストを中心としたコミュニケーションを行うシステムを構築した．
本システムは，ユーザの嗜好と状況に適応するプレイリストの作成支援を行うた
めに，楽曲情景・鑑賞状況に関するアノテーションを定義し，音楽アノテーショ
ンシステムに適用した．プレイリストを作成する際には，既存のプレイリスト中
から嗜好・状況の類似するプレイリストを選出し，さらにユーザに適応するトラ
ンスコーディングを行いユーザに提示する．ユーザは提示されたプレイリストに
対して嗜好・状況に適合しているかどうかをシステムにフィードバックすること
で，プレイリストを徐々に洗練していく．またプレイリストに対してライナーノー
ツや感想を記述することで，プレイリストを中心としたコミュニケーションを促
す．
本システムは，評価実験を通して，アノテーションがユーザの心的状態や置かれ
ている状況，またユーザと楽曲間の関係を正確かつ動的に表すために有効である
と確認された．嗜好・状況に適応するために，楽曲情景・鑑賞状況アノテーショ
ンを利用することが有効であることが明らかになったといえる．同時に，協調フィ
ルタリング・トランスコーディング・インタラクションの組み合わせがユーザの
嗜好に合ったプレイリスト推薦に有効であることが明らかとなった．本システム
により，プレイリスト作成と推薦を促す仕組みが実現できたといえる．
6. 関連研究
本章では，本研究と関連する研究を挙げ，その差を比較することにより本研究の
優位性を示す．
6-1. マルチメディアアノテーション
2章でアノテーション基盤であるAnnphonyと関連する研究として，
デジタルコンテンツへのアノテーションを対象としたアノテーションの枠組みに
関する研究が存在する．
Staabら[59]は，人物紹介ページに現れる人物の属性や人間関係
など，Webコンテンツに存在する様々なオブジェクトのオントロジを構築するた
め，アノテーションを記述するための仕組みを提案している．Webコンテンツ内
のオブジェクトに対するアノテーションはアノテーションエディタである
OntoAnnotateを通して記述する．オブジェクトの属性情報やオブジェクト間の関
連はRDFSにより定義されるため，様々なオブジェクトの情報を記述することがで
きる．
この仕組みは，任意のコンテンツに対して，そのコンテンツを構成するオブジェ
クトの詳細な情報記述に適していると考えられるが，それらのアノテーションか
ら構成されるオントロジは，コンテンツとは切り離されたオブジェクト間の関係
性である．そのため，それぞれのコンテンツがどのような構造をしているか，コ
ンテンツ同士にどのような関連性があるかといった，コンテンツ自体の意味内容
を扱うことには適していない．一方Annphonyは，任意のコンテンツの意味内容に
基づく処理を実現するために，コンテンツ自体の構造や関連性を記述するための
仕組みである．
またBargeronら[60]の提案するアノテーションのためのフレームワー
クでは，外部に用意されたライブラリを参照することで，ドキュメントの一部や
画像の一部を指し示す仕組みを備える．指し先の情報はXLinkにより管理され，
その指し示した部分に対するアノテーションを記述することができる．またその
ライブラリを利用することによって指し示されたコンテンツの内部をプログラム
中で利用することも可能である．これはElementPointerとElementPointerプロセッ
サに相当する仕組みであるといえるが，外部ライブラリの利用支援のための機能
がない点がElementPointerと異なる．
コンテンツ内部の指し示し方は，コンテンツの種類に特化しており，専門性が高
い．外部ライブラリの利用支援の仕組みがない場合，それぞれの種類のコンテン
ツを熟知し，かつその外部ライブラリの存在を知っていなければならず，幅広い
ユーザが任意のコンテンツの横断的なアプリケーションを構築することができな
くなってしまう．一方ElementPointerの定義やそのプロセッサは，Annphonyにお
いて管理され，どのようなコンテンツに対してどのようなElementPointerを利用
可能であるか，またどのように利用するかという情報を提供する機能を持つ．
またここで挙げた関連研究は，双方とも事実や関係性など，一意に決定される情
報のみを扱うことを想定しているため，個人によって異なる多様な解釈を扱うこ
とには適していない．コンテンツを扱うユーザ層の拡大によって，個人の感性へ
の適応した応用が求められているが，これらの枠組みによって記述されたアノテー
ションを用いて個人の感性に適応することは困難である．一方Annphonyでは，個
人によって異なる多様な解釈を記述可能であるため，アノテーションをユーザご
とに管理したり，特定の傾向を持つアノテーションに分類するなど，
個人適応につながる処理が可能である．
6-2. 音楽アノテーション
3章で提案した音楽アノテーションシステムに関連する研究として，
MoodLogic[]，CUIDADO(Content-based Unified Interfaces and
Descriptors for Audio/music Databases available Online)[61]，
CLAM Annotator[28]
を挙げる．
MoodLogicはWeb上のユーザコミュニティと専門家によって楽曲に対するタイトル・
アーティストなどの基本情報に加えて，テンポや印象情報を収集し，「アップテ
ンポなロック」や「ロマンチックなブルース」など，印象情報に基づく検索やプ
レイリスト作成を支援する．
音楽アノテーションシステムとMoodLogicの比較について述べる．まず，
MoodLogicではユーザから収集した印象・ジャンルなどの情報を統計し，その楽
曲の印象・ジャンルを一意に決定している．一方音楽アノテーションシステムで
収集され，Annphonyで管理される複数の解釈に関するアノテーションの利用法は，
アプリケーションごとにゆだねられている．MoodLogicと同様に，統計をとり一
意の値を取得することもできるが，それぞれのアノテーションにはアノテータ情
報が付与されているため，本研究のプレイリスト作成支援システムのように，楽
曲の嗜好に関するユーザモデルを用いることで，あるユーザと類似するユーザが
付与したアノテーションを優先的に利用したり，特定のユーザが付与したアノテー
ションに特に注目するなど，ユーザごとに個人化したアノテーション利用が可能
になる．
またMoodLogicでは楽曲検索とプレイリスト作成支援にのみ利用されるアノテー
ションを収集しており，また他のアプリケーションがその情報を利用することは
困難である．このことから，アノテーション定義の柔軟性と，アノテーション共
有に関して問題があるといえる．一方音楽アノテーションシステムはアノテーショ
ン定義をアプリケーション開発者が定義することで，アノテーション収集のため
のエディタが動的に構成されるため，様々なアプリケーションに適用するアノテー
ションを収集することが可能である．
CUIDADO は，オンライン音楽データベースの
統一的なインタフェースを提案し，楽曲ブラウジング・検索・オーサリングの支
援を目指すプロジェクトである．メタデータの記述形式はMPEG-7 を参考にして
おり，タイトルやアーティストなどの基本情報を収集し統計的なインデキシング
を行い，さらにオーディオデータからテンポや音響パワーなどの特徴量を自動抽
出し管理する．
アプリケーションの一つとして，音楽制作者のための検索・編集・処理ツールで
あるSound Paletteが提供されている．ユーザはメロディやリズムに基づく類似
楽曲検索で得られる楽曲ファイルをインポートし，自動でセグメント化された楽
曲の断片を利用することができる．またテンポの異なる二つの楽曲をミックスさ
せる際に，自動的にテンポを同期させるなど，音楽の意味内容に基づいた
編集を支援する．
このプロジェクトでは，楽曲の内部構造に関する情報は自動的に抽出されている
が，楽曲編集に有効な情報は，必ずしも自動的に抽出されるとは限らない．その
ため音楽アノテーションシステムのように楽曲構造に関するアノテーションを人
手により付与する必要があると考えられる．また，本論文のシステムのように本
質的に自動的に抽出できない楽曲の特徴を収集するためにはユーザによるアノテー
ションは不可欠だと思われる．
CLAM Annotatorは，楽曲の音響信号の解析結果に関するアノテーションを付与す
るための仕組みである．楽曲の一部の音程の情報や和音情報，小節などの区間情
報，楽曲の構成などの記述が可能である．CLAM Annotatorの画面には，音響信号
の波形が表示され，波形の一部を選択することで，時間区分に対するアノテーショ
ンを記述する．記述可能なアノテーションの種類は固定されておらず，アノテー
ションの定義を用意することで，様々なデータ型のアノテーションを扱えるよう
になる．
音楽アノテーションシステムと異なる点として，ユーザに提示する音楽の形式が
音響信号の波形情報であることが挙げられる．音楽アノテーションシステムでは，
時間区分に対するアノテーションエディタとしてTimeline Annotatorを構築した
が，ユーザが特定の時間区分を選択するための視覚情報として，CLAM Annotator
のように波形を提示することは有効であると考えられる．しかしCLAM Annotator
は，音メディア以外の形式の楽曲には適用することがでない．一方音楽アノテー
ションシステムでは，MIDIやMusicXMLなど，音楽メディアの様々な形式に対応し
ている．
またCLAM Annotatorは，信号解析の結果などの楽曲に対する事実を記述するため
のエディタであるため，人によって異なる解釈を記述することができない点も，
音楽アノテーションシステムと異なる．和音情報や楽曲の構成などは，人によっ
て解釈が異なるため，そのような多様な解釈を収集する必要がある．
6-3. コミュニケーションシステム
計算機を通じたコミュニケーションの形態は日々変化しており，その中で最も重
要な役割を担っているのがコンテンツであるといえる．Norman[62]は，
飛行機におけるパイロットのコミュニケーションの古さについて述べ，共通のタ
スクを実現しようとするユーザ間では言葉以外のコンテンツによって無意識にや
り取りされるコミュニケーションの重要性について述べており，
Nelson[63]は，社会的な発展に応じてこのようなコミュニケーション
のためのコンテンツは拡張・改良されていくと指摘している．
コミュニケーションコンテンツの作成に関する代表例として，Apple Computerが
開発したHyperCard[64]が挙げられる．HyperCardはハイパーテキス
トのノードにはカードを，カード間をつなぐリンクにボタンを用い，グラフィカ
ルにマルチメディアアプリケーションを作成できるシステムである．現在もイン
タラクティブ性や，アプリケーション作成の容易さから幅広く普及している．ま
た田中らのIntelligentPad[65]は，計算機をメタメディアと
みなし，文化遺伝子(ミーム)を持ったメディアという意味のミームメディアを作
成するシステムであり，モックアップシステムを顧客と開発者間で議論しあう際
などに，顧客の目前でのデザインを容易に変更するといったことが可能になる．
このように，コミュニケーションのためにコンテンツは必要不可欠な存在である
といえる．以降では特に楽曲を用いたコミュニケーションシステムについての関
連研究について述べる．音楽は言葉として表現できないあいまいな情報を伝える
ことのできるコンテンツであり，今後そのコミュニケーションへの利用価値の認
識が高まると予想される．
5章で提案したプレイリスト作成支援システムのように，ユーザ間で楽曲を推薦
し合うための仕組みがいくつか存在する．ここではその代表例として，
Last.fm[66]とPANDORA[67]，iMix[68]を挙げ，本研
究とのアプローチとの違いを述べる．
PANDORAはシステム上で提示される楽曲が嗜好に合っているかどうかを繰り返し
答えることによって，ユーザの嗜好に合わせたラジオ局を開設する
システムである．楽曲の特徴量として，メロディ・ハーモニー・リズム・歌詞・
使用している楽器など約400種類を用いるが，それらの情報は音楽の専門家によ
り付与される．
一方Last.fmも，ユーザの嗜好に合わせたラジオ局の開設が可能なシステムであ
る．Last.fmでは，audioscrobbler[69]によって取得・管理さ
れるユーザの日常的な楽曲の鑑賞履歴を基にユーザの嗜好を形成する．PANDORA
とは異なり，アーティスト・タイトル・アルバムなど楽曲の基本情報のみを楽曲
の特徴量としている．
これらのシステムはSNSと連携し，友人や嗜好の類似するユーザのラジオを
楽しむことができる．協調フィルタリングを用いて嗜好の類似するユーザを提示
する．嗜好の類似するユーザのラジオを鑑賞することで，自分の嗜好に合った楽
曲を多く推薦されることが可能となる．
これらのシステムでは楽曲そのものを推薦することができるが，ユーザ自身が明
確に他のユーザへの推薦の意図を伝えることができないという問題点がある．一
方プレイリストは，それを作成するユーザが容易に意図を込めることができるメ
ディアであり，プレイリストを推薦しあうことは，それぞれの楽曲へのリンク情
報のみを保持していればよいため，楽曲そのものをやり取りする必要が無い．ま
た楽曲そのものの推薦よりも効率が良いため，楽曲推薦の仕組みとしてプレイリ
ストは有効であることがわかる．
プレイリストを共有するサービスの代表的なものに，iMixが挙げられる．iMixで
はiTunes上で作成されるプレイリストを，ユーザ間で共有し，評価しあうことが
できる．しかしプレイリストを作成するための支援が無く，iTunes Store上に存
在する膨大な楽曲の中からプレイリストの要素となる楽曲を選出することが困難
である．一方，本研究で提案したプレイリスト作成支援システムでは，ユーザの
嗜好やユーザの状況に合わせて楽曲を自動的に絞り込む機能を持っているため，
プレイリストに含める楽曲を選出する作業を容易に行うことができる．
またプレイリスト作成支援システムでは，共有されたプレイリストに対する解説
やコメントを記述することができ，またプレイリストを派生させて新たなプレイ
リストを容易に作成することができる．このように新しいプレイリストを作るモ
チベーションにつなげるための仕組みを備えているため，多くのプレイリストの
作成と推薦が行われると考えられる．
7. 結論
本章では，本論文で紹介した研究成果のまとめを述べ，今後の課題と将来の展望
について述べる．
7-1. まとめ
本論文では，計算機がコンテンツの意味を把握し，様々な応用が実現可能になる
ことを最終的な目標とし，特にその研究対象として個人の嗜好と状況への適応の
要求が特に高いコンテンツであり，様々なコンテンツの意味内容を同時に扱う必
要性がある音楽に着目した．
2章では音楽情報処理の研究を発展させるために必要である任意のコンテンツの
意味内容を同時に扱う仕組みとして，任意のデジタルコンテンツに対するアノテー
ションを管理するための基盤技術であるAnnphonyを提案した．
任意のコンテンツの内部要素を指し示すElementPointerを提案し，Annphonyに適
用した．またコンテンツの種類に依存しないアノテーション形式であるRDFを拡
張することにより，任意のコンテンツの構造や解釈・関連性を統一的に扱うこと
ができるようになった．またAnnphonyはアノテーション定義の管理を行うことで，
ますます多様化するコンテンツへのアノテーションを柔軟に定義することができ
る．Annphonyにより，1章で述べた既存のアノテーション形式の間の壁を取り払
い，横断的にコンテンツの意味内容を扱う環境が実現された．
3章では，音楽に対する意味内容に関するアノテーションを，Web上の多くのユー
ザから獲得する音楽アノテーションシステムを提案した．本システムでは，1:
書誌情報などの楽曲自体へのアノテーションエディタ(Tune Annotator)，2: 連
続メディアに対するアノテーションエディタ(Timeline Annotator)， 3: 楽曲の
内部構造に対するアノテーションエディタ(Score Annotator)の3種類のエディタ
を使い分けることで，様々な楽曲のメディア形式と，取得するアノテーションの
対象の粒度に応じたアノテーション収集を支援する．またアノテーション定義と
アノテーションエディタを独立させることにより，様々なアプリケーションに適
用可能なアノテーションを柔軟に収集することができる．
またMP3等の音響メディアに対しても，Tune AnnotatorとTimeline Annotator を
用いて音響メディアの構造化を行い，音響メディアに対応するMusicXML を生成
する機能を備える．MusicXMLを生成することで，音響メディアに対してもScore
Annotatorによる楽譜による音符や歌詞の一部など楽曲の詳細な要素へのアノテー
ション付与が可能になる．
また，音楽アノテーションシステムを用いることで，多様な解釈が顕在化される
ことを確認する実験を行い，楽曲の内部構造に関する解釈の多様性と各ユーザの
個人性を，本システムで収集されるアノテーションを解析することによって浮き
上がらせることが可能であることを確認した．
4章では音楽アノテーションシステムにより収集が容易になった楽曲アノテーショ
ンを用いたアプリケーションとして，楽曲検索システムと楽曲再構成システムを
提案した．
まずそれぞれのシステムで利用するアノテーションをAnnphonyに登録し，音楽ア
ノテーションシステムを通して楽曲の構成や意見などのアノテーションを収集し
た．楽曲検索システムではそれらの情報を用いて，楽曲の論理構造であるコード
進行に基づく検索や，楽曲の構成に基づく検索結果の絞込みを行う機能を持つ．
また検索システムを利用するユーザの解釈に類似するユーザが付与したアノテー
ションを優先的に用いることによって，楽曲の印象検索などをユーザの感性に適
応させる．また楽曲再構成システムは，楽曲の論理構造であるサビやイントロな
どの大まかな構成，楽器パート，歌詞などの情報を基に，楽曲を容易に再構成す
るシステムであり，楽曲検索システムと同様に，ユーザの解釈と類似するユーザ
が付与したアノテーションを優先的に利用し，ユーザの感性に適応させることも
できる．
これらのシステムから，音楽アノテーションシステムを用いて獲得されたアノテー
ションを用いて，楽曲の論理構造やユーザの感性に適合させるアプリケーション
が実現可能であることを示した．
5章では，プレイリストにまつわる作成・推薦・鑑賞といった活動を活発にする
ことで，プレイリストを介したコミュニケーション(Playlist-Mediated
Communication)が実現されると考え，プレイリストの作成支援とプレイリストを中
心としたコミュニケーションを行うシステムを提案した．
本システムは，ユーザの嗜好と状況に適応するプレイリストの作成支援を行うた
めに，楽曲情景・鑑賞状況に関するアノテーションを定義し，音楽アノテーショ
ンシステムに適用した．プレイリストを作成する際には，既存のプレイリスト中
から嗜好・状況の類似するプレイリストを選別し，さらにユーザに適応させるトラ
ンスコーディングを行いユーザに提示する．ユーザは提示されたプレイリストに
対して嗜好・状況に適合しているかどうかをシステムにフィードバックすること
で，プレイリストを徐々に洗練していく．またプレイリストに対してライナーノー
ツや感想を記述することで，プレイリストを中心としたコミュニケーションを促
す．
本システムは，評価実験を通して，アノテーションがユーザの心的状態や置かれ
ている状況，またユーザと楽曲間の関係を正確かつ動的に表すために有効である
と確認された．同時に，協調フィルタリング・トランスコーディング・インタラ
クションの組み合わせがユーザの嗜好に合ったプレイリスト推薦に有効であると
確認できた．本システムは，プレイリスト作成と推薦を促す主要な枠組みである
といえる．
これは，音楽アノテーションシステムにより収集されたアノテーションを用いて，
個人の嗜好と状況に適合するアプリケーションを実現した例の一つである．
本研究により，計算機が横断的なコンテンツのアノテーションを統一的に扱うこ
とで，音楽情報処理の研究を発展させること，また音楽以外のコンテンツへも適
用されることを示した．計算機によるデジタルコンテンツの意味内容を把握し，
様々な応用を実現可能な環境に一歩近づいたといえる．
7-2. 今後の課題
今後の課題として，2章で述べたAnnphonyを一般公開し，様々なコンテンツ管理シス
テムに適用される環境を構築することが挙げられる．様々な種類のコンテンツに
対するアノテーションを収集し，そのアノテーションを共有することで，コンテ
ンツの種類に横断的なアプリケーションを実現することが可能となる．
また3.3節で述べた連続メディアの構造化支援のために，ビートトラッキングな
どの採譜のための研究を取り入れ，自動採譜結果を人手で修正することができる
ように拡張する予定である．本機能により，連続メディアから離散的な構造を持っ
たメディアへの変換のためにかかる人的コストを大幅に軽減させることができる
と期待できる．
また，4章で述べた楽曲の検索・再構成システムの評価を行い，ユーザの感性に
適合させるために必要なシステムの要素を検討することが挙げられる．また，5
章で述べたプレイリスト作成支援システムを用いることによってプレイリストの
作成やコミュニケーションが活性化することを確認するための評価実験を行う必
要がある．
7-3. 将来展望
音楽に限らない，異種コンテンツ同士を横断的に扱った具体的な応用
を検討した[70]．
複数のコンテンツを同時に利用する際に最も問題となるのは，どの組み合わせで
コンテンツを利用すればよいかという点である．様々な種類のコンテンツを組み
合わせるためには，関連性の認められるコンテンツ同士を選出することが必要と
なる．そこで我々は，Nelson[63]もその重要性を指摘する引用情報に
着目した．あるコンテンツ内で同時に引用される複数コンテンツ間には明らかに
意味的な関連性を認めることができることから，引用・被引用情報が有効である
と考えられる．またコンテンツの部分引用の情報は，コンテンツの意味的な構造
把握に有用な情報となるだろう．
また近年ブログやビデオ投稿システムなど，消費者がコンテンツを作成し投稿す
るCGM(Consumer Generated Media)サービスが盛んになってきており，今後Web
上のコンテンツの多くはCGMサービスによって管理されることになると予想され
る．しかし現在のCGMサービスはコンテンツの部分的な引用・被引用を行うため
に十分な機能を備えていない．
そこで，CGMサービスにAnnphonyを適用し，コンテンツの任意の箇所の部分引用
を可能にし，その引用・被引用情報を扱う．具体的には引用先のCGMサービスと
してブログに，引用元のCGMサービスとしてビデオ共有システム
Synvie[71]と，試作中（一般には未公開）の認知科学辞典
[72]Web版にAnnphonyを適用し，部分引用を可能にする．またブログで
同時引用されるビデオと辞典の項目を用いて，事例ベース辞典システムを実現す
ることを検討した．
7-
3-
1. CGMサービスの拡張
今後Web 上のコンテンツの多くはCGMサービスによって管理されることになると
予想されるため，AnnphonyをCGMサービスに適用することで，様々なコンテンツ
同士の引用と，その引用情報の共有を可能にする．
例えば，引用元のCGMサービスとしてビデオ共有システムSynvie
とオンライン辞典システムである認知科学辞典Web版にAnnphonyを適用する．コ
ンテンツの種類はCGMサービスによって異なるため，コンテンツ内部を指し示す
ElementPointer の定義はCGMサービスごとに用意する．ビデオ共有システムでは
ビデオの時間区分を指し示すためには，開始・終了時間が必要であるため，その
旨をElementPointerの定義に記述した．またオンライン辞典システムの各専門用
語は，文書の言語構造を表現するための言語であるGDA(Global Document
Annotation)[8]形式で保持されているため，単語・文節・文など，文書
の論理構造に基づく部分を指し示すための定義を記述する．
また引用先となるCGMサービスとして，ブログを採用した．ブログシステムに
Annphonyを適用し，ブログにビデオや辞典などの他のコンテンツを部分引用した
記事を投稿する際に，その部分引用の情報をAnnphonyに保存する．図49
はブログにおいてビデオ・辞典を引用した記事を投稿した画面例である．図では，
ある分野の詳細な解説として，参考となるビデオと辞典の一部を引用している．
このように同時に引用されるビデオと辞典には，明らかな関連性を認めることが
できる．
図49.
ブログでのビデオ・辞典の同時引用
一般的にユーザは，あるコンテンツと他の様々なコンテンツとの多項関係を完全
に把握してはいないため，一人のユーザによって網羅的な関連性を記述すること
は困難である．そのため，一般ユーザが記述可能な同時引用の情報は二項，三項
関係といった少数の関連性にとどまると考えられる．しかしCGMサービスを通じ
て同時引用の情報を広く収集することにより，コンテンツ間の多項関係に拡張す
ることができる．
7-
3-
2. マッシュアップコンテンツ
関連する複数コンテンツを自動的に統合して新たなコンテンツを生成することを
マッシュアップと言う．Webコンテンツを用いてマッシュアップコンテンツを自
動生成する例として，オンライン辞典システムを拡張し，ビデオ用例付き辞典シ
ステムを構築する．本システムでは，各専門用語の項に，ブログにおいて同時引
用された，用例の一つと見なされるビデオを提示することで，その専門用語の理
解を深めることができる．
キーワード検索の要求を本システムが受け取ると，オンライン辞典システム・ビ
デオ共有システムに対して，検索要求のキーワードが存在する辞典の項目・ビデ
オを検索する．次にそれらがブログにおいて過去に同時引用されているかを検索
し，同時に引用されたことのあるビデオの一部と辞典項目の一部の組を列挙する．
またブログに対してもキーワード検索を行い，検出されたブログエントリ内で同
時引用されているビデオの一部と辞典項目の一部の組を列挙する．
こうして列挙されたビデオの一部と辞典の項目の一部の組を用い，辞典の項目中
の同時引用された文以降に，ビデオへのリンクを埋め込む．図50はビ
デオが埋め込まれた辞典の項目の例である．辞典の項目中に具体的な例であるビ
デオを埋め込むことで，その項目をより深く理解することができる．
図50.
ビデオ用例付き辞典システム
このように同時引用の情報を用いることにより，ビデオやオンライン辞典の項目
といった異種類のコンテンツ同士を結びつけることで，付加価値を持ったコンテ
ンツを作成することが可能である．これも本研究の成果から自然に導かれる結論
の一つである．
謝辞
本論文は，名古屋大学大学院情報科学研究科長尾研究室に在籍していた期間中
に行われた研究です．本研究を遂行するにあたり，多くの方々の御指導，ご支援を
頂きました．ここに心から感謝の意を表します．
長尾確教授には，自由な研究環境を提供して頂き，また日頃より懇切丁寧な御
指導と御鞭撻を頂きました．さらに，研究者としての姿勢や考え方など，今後の研
究活動を行っていく上でも有益となるような，多くの貴重なご意見を頂きました．
大平茂輝助手には，日頃の研究に関する様々な相談に常に親身になってご助言，
ご支援を頂きました．
NTT コミュニケーション科学基礎研究所の平田圭二氏には，本研究の初期の段
階より，研究方針や論文執筆に関する御指導を頂きました．
武田一哉教授には，本論文の審査の場を通じて，幅広い角度からの御助言，御
示唆を頂き，本論文をまとめる上で有益なものとなりました．
長尾研究室秘書の金子幸子さんには学生生活ならびに研究活動のための様々な
サポートを頂きました。また長尾研究室の皆様には本研究を進めるにあたり有益
な議論と様々な励ましを頂きました．
本論文をまとめることができたのは，このような多くの方々の御支援のおかげ
です．ここに，改めて心から御礼申し上げます．
参考文献
[
1] Apple Computer, Inc.. iTunes Store. http://www.apple.com/jp/itunes/music/..
[
2] Amazon. http://www.amazon.co.jp/.
[
3] Yahoo! Music Unlimited. http://music.yahoo.com/.
[
4] Napster Japan. http://www.napster.jp/.
[
5] T. O’Reilly. What Is Web 2.0 -Design Patterns and Business Models for the Next Generation of Software. http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html. 2005.
[
6] K. Nagao.. Digital content annotation and transcoding. Artech House Publishers, London. 2003.
[
7] T. Berners-Lee, J. Hendler, O. Lassila.. The Semantic Web. Scientific American. 2001.
[
8] 橋田浩一. GDA:意味的修飾に基づく多用途の知的コンテンツ. 人工知能学会誌, Vol.13, No.4,. pp.528-535. 1998.
[
9] P. Salembier and J. R. Smith.. MPEG-7 Multimedia Description Schemes. IEEE Transactions on Circuits and Systems for Video Technology Vol. 11, No. 6. 2001.
[
10] W3C. Resource Description Framework. http://www.w3.org/RDF/. 1999.
[
11] T. Berners-Lee, R. Fielding and L. Masinter.. Uniform Resource Identifiers (URI): Generic Syntax.. RFC 2396. 1998.
[
12] 山本大介, 長尾確. 閲覧者によるオンラインビデオコンテンツへのアノテーションとその応用. 人工知能学会論文誌, Vol.20, No.1. pp.67-75. 2005.
[
13] M. Kipp.. Anvil - A Generic Annotation Tool for Multimodal Dialogue. In Proceedings of the 7th European Conference on Speech Communication and
Technology (Eurospeech). pp.1367-1370. 2001.
[
14] I. Dagan, S. P. Engelson.. Committee-Based Sampling For Training Probabilistic
Classifiers. In Proceedings of International Conference on Machine
Learning. pp.150-157. 1995.
[
15] A. Mathes. Folksonomies - Cooperative Classification and Communication Through Shared Metadata. http://www.adammathes.com/academic/computer-mediated-communication/folksonomies.html. 2004.
[
16] del.icio.us.. http://del.icio.us/.
[
17] Flickr. http://www.flickr.com/.
[
18] K. Marja-Riitta, P. Eric, R.S. Ralph.. Annotea: An Open RDF Infrastructure
for Shared Web Annotations.. In Proceedings of International World Wide Web Conference (WWW). 2001.
[
19] 坂本竜基, 伊藤禎宣. annpoly. http://blog.phase8.jp/annpoly/. 2005.
[
20] W3C. Synchronized Multimedia Integration Language (SMIL 2.1). http://www.w3.org/TR/SMIL/. 2005.
[
21] S. Boll, W. Klas, Jochen Wandel. A Cross Media Adaptation Strategy for
Multimedia Presentations. ACM Multimedia No.1. 1999.
[
22] P. Bellini, P. Nesi. WEDELMUSIC format:An XML music notation format
for emerging applications. In Proceedings International Conference on WEB
Delivering of Music (WEDELMUSIC). pp.79-86. 2001.
[
23] M. Good. MusicXML in Practice: Issues in Translation and Analysis. In
Proceedings of International Conference Musical Application using XML. pp.47-54. 2002.
[
24] R. Jackendoff, F. Lerdahl. A Generative Theory of Tonal Music. MIT Press. 1996.
[
25] Gracenote. CDDB. http://www.gracenote.com/gn_products/cddb.html.
[
26] MusicBrainz. http://www.musicbrainz.org/.
[
27] MoodLogic. http://www.moodlogic.com/.
[
28] X. Amatriain, J. Massaguer, D. Garcia, I. Mosquera. The CLAM Annotator:
A Cross-platform Audio Descriptors Editing Tool. In Proceedings of International
Conference on Music Information Retrieval (ISMIR). 2005.
[
29] P. Herrera, O. Celma, J. Massaguer, P. Cano, E. Gomez, F. Gouyon, M.
Koppenberger, D. G. Garcia, J. Mahedero and N. Wack. MUCOSA: A Music
Content Semantic Annotator. In Proceedings of International Conference on
Music Information Retrieval (ISMIR). 2005.
[
30] U. Shardanand, P. Maes.. Social Information Filtering: Algorithms for Automating
“Word of Mouth”. In Proceedings of Conference on Human Factors
in Computing Systems (CHI). 1995.
[
31] A.Field, P. Hartei, W. Mooij. Personal DJ, an Architecture for Personalised
Content Derivery. In Proceedings of World Wide Web Conference (WWW). 2001.
[
32] M. Anderson, M. Ball, H. Boley, S. Greene, N. Howse, D. Lemire, and S. Mc-
Grath. Racofi: A rule-applying collaborative filtering system. In Proceedings
of Center for Ocean-Land-Atmosphere Studies. IEEE/WIC. 2003.
[
33] B. Logan. Content-Based Playlist Generation: Exploratory Experiments. In Proceedings of International Conference on Music Information Retrieval
(ISMIR). 2002.
[
34] M. Alghoniemy, A. H. Tewfik. A Network Flow Model For Playlist Generation. In Proceedings of IEEE International Conference on Multimedia and Expo
(ICME). 2001.
[
35] J. J. Aucouturier, F. Pachet. Scaling Up Music Playlist Generation. In Proceedings
of IEEE International Conference on Multimedia and Expo (ICME). 2002.
[
36] W3C. RDF Schema. http://www.w3.org/TR/rdf-schema/. 2004.
[
37] MULTEXT Project. Corpus Encoding Standard. http://www.cs.vassar.edu/CES/.
[
38] W3C. XML Pointer Language. http://www.w3.org/TR/WD-xptr. 2001.
[
39] S. Pfeiffer, C. Parker, A. Pang. Specifying time intervals
in URI queries and fragments of time-based Web resources. http://www.annodex.net/TR/URI_fragments.txt. 2003.
[
40] Prot´eg´e. http://protege.stanford.edu/.
[
41] G. Sunil, W. Rupert. RDF Gravity (RDF Graph Visualization Tool). http://semweb.salzburgresearch.at/apps/rdf-gravity/index.html.
[
42] W3C. XML Path Language. http://www.w3.org/TR/xpath.html. 1999.
[
43] W3C. SPARQL Query Language for RDF. http://www.w3.org/TR/rdf-sparql-query/. 2006.
[
44] W3C. Named Graphs. http://www.w3.org/2004/03/trix/. 2004.
[
45] W3C. XML Schema. http://www.w3.org/XML/Schema. 2001.
[
46] Userland Software. XML-RPC. http://www.xmlrpc.com/. 1999.
[
47] HP. Jena - A Semantic Web Framework for Java. http://jena.sourceforge.net/. 2006.
[
48] SC34/WG3. Topic Maps. ISO/IEC 13240. 2002.
[
49] 後藤真孝, 村岡洋一. 音楽音響信号を対象としたビートトラッキングシステ
ム-小節線の検出と打楽器音の有無に応じた音楽的知識の選択-. 情報処理学会
音楽情報科学研究会研究報告, 97-MUS-21-8, Vol.97, No.67. 1997.
[
50] K. Hevner. Experimental Studies of the Elements of Expression in Music. American journal of psychology, Vol. 48. pp.246-268. 1936.
[
51] 後藤真孝. SmartMusicKIOSK: サビ出し機能付き音楽試聴機. 情報処理学会
論文誌, Vol.44, No.11. pp.2737-2747. 2003.
[
52] W3C. Scalable Vector Graphics(SVG). http://www.w3.org/Graphics/SVG/. 2003.
[
53] S. Pauws, B. Eggen. PATS: Realization and user evaluation of an automatic
playlist generator. In Proceedings of International Conference on Music Information
Retrieval (ISMIR). 2002.
[
54] J. H. Lee, J. S. Downie. Survey of Music Information Needs, Uses, and Seeking
Behaviours: Preliminary Findings. In Proceedings of International Conference
on Music Information Retrieval (ISMIR). 2004.
[
55] E. Daniel, B. Whitman, A. Berenzweig, S. Lawrence. The Quest for Ground
Truth in Musical Artist Similarity. In Proceedings of International Conference
on Music Information Retrieval (ISMIR). 2002.
[
56] B. Logan, A. Kositsky, P. Moreno. Semantic Analysis of Song Lyrics. In Proceedings of IEEE International Conference on Multimedia and Expo (ICME). 2004.
[
57] G. Salton, C. S. Yang. On the specification of term values in automatic indexing. Journal of Documentation. pp.29:351-372. 1973.
[
58] 後藤真孝, 橋口博樹, 西村拓一, 岡隆一. RWC研究用音楽データベース: ポ
ピュラー音楽データベースと著作権切れ音楽データベース. 情報処理学会音楽情報科学研究会研究報告2001-MUS-42-6. pp.35-42. 2001.
[
59] S. Staab, A. Maedche, S. Handschuh. An Annotation Framework for the SemanticWeb. In Proceedings of the First Workshop on Multimedia Annotation. 2001.
[
60] D. Bargeron, A. Gupta, A.J. B. Brush. A Common Annotation Framework. Microsoft Researh MSR-TR-2001-108. 2001.
[
61] H. Vinet, P. Herrera, F. F. Pachet. The CUIDADO Project. In Proceedings of International Conference on Music Information Retrieval (ISMIR). 2002.
[
62] D. A. Norman. Things That Make Us Smart. Perseus Books. 1993.
[
63] T. Nelson. Computer Lib/Dream Machines. マイクロソフト出版. 1987.
[
64] D. Goodman. The Complete HyperCard Handbook. Bantam Books. 1987.
[
65] 田中譲. ミームメディア・アーキテクチャIntelligentPad とその応用. 情報処理学会論文誌，Vol.38, No.3. pp.222-231. 1997.
[
66] Last.fm. http://jp.last.fm/.
[
67] PANDORA. http://www.pandora.com/.
[
68] Apple Computer, Inc.. iMix. http://www.apple.com/jp/itunes/playlists/.
[
69] audioscrobbler. http://www.audioscrobbler.net/.
[
70] 梶克彦，長尾確.. 部分引用の管理に基づくWeb コンテンツのマッシュアップ. 情報処理学会第69 回全国大会. 2007.
[
71] 山本大介，清水敏之，大平茂輝，長尾確.. Synvie:ブログの仕組みを利用したマ
ルチメディアコンテンツ配信システム. 情報処理学会第68 回全国大会. 2006.
[
72] 日本認知科学会. 認知科学辞典. 共立出版. 2002.
|
