情報処理学会 インタラクション 2024
IPSJ Interaction 2024

INT24001
2024/2/28

Lyric App Framework: インタラクティブな歌詞駆動型視覚表現の開発用フレームワーク
加藤 淳1,a)

後藤 真孝1,b)

概要：音楽に合わせてタイミングよく歌詞が動くリリックビデオは楽曲のプロモーション手段として一般化したが，視聴者は再生操作でしかインタラクションできない．そこで我々は，ユーザとのインタラク
ションにより歌詞のテキストを再生のたびに異なる方法で提示でき，静的メディアの制約を取り払える歌
詞駆動型のインタラクティブな視覚表現を「リリックアプリ」と定義し，この新たな表現形式を開発・配信
できる Web ベースのフレームワーク「Lyric App Framework」を提案する．我々は，2020 年に当フレー
ムワークを一般公開して以来，創作文化に関するイベント「マジカルミライ」で毎年開催されるプログラ
ミング・コンテストを通して，新たな表現形式の可能性を探ってきた．本稿では，最初の 2 回で集まった52 作品の分析結果と，音楽とプログラミングの未来に関する示唆を併せて報告する．

1. はじめに
歌詞はメディア技術の進歩とともに多様な方法で聴衆にさらに，この新たな表現形式の可能性を探るため，プロダ
クションレディ (production-ready) なリリックアプリを構築するための一貫した開発体験を提供する Web ベースの届けられてきた．例えば，レコードやコンパクトディスク

フレームワーク「Lyric App Framework」 [4] を提案する．

(CD) には，グラフィックデザイナがデザインした歌詞カー

なお，ここでプロダクションレディとは，プロトタイプ開ドがついてきた．また，音楽動画や動画共有サービスが一発だけでなく一般ユーザによる利用にも耐える高い信頼性

般化してからは，楽曲再生に合わせて歌詞が魅力的に動くでのアプリの配信までサポートすることを指す．

「リリックビデオ (lyric video)」が人気を博すようになった．

本研究の貢献は以下の 3 点である．

リリックビデオにおいて文字が時系列で変形する表現形式( 1 ) リリックビデオを拡張して，楽曲と歌詞に関するインは「キネティックタイポグラフィ (kinetic typography)」とタラクションを可能にする仕組みを加え，新たな表現

呼ばれ，多くの場合，モーショングラフィックデザイナが形式「リリックアプリ」を定義したこと．

動きを手付けしているが，著者らは，音楽理解技術を活用( 2 ) Web ベースのワークフローと API (TextAlive App

してその制作を省力化し，支援するサービス「TextAlive」

API*1 ) を提供する新たなフレームワークを実装し，プ[1] を研究，開発，運営してきた．そして今や，ミュージ

ロダクションレディなリリックアプリを構築するためシャンは多様なメディアを横断して聴衆に楽曲を届けるよの一貫した開発体験を提供したこと．

うになり，聴衆は楽曲を聴くだけでなく，ソーシャルネッ( 3 ) フレームワークを一般公開*2 し，創作文化に関するイ

トワーキングサービス (SNS) への投稿などを通して自らのベント「マジカルミライ」でプログラミング・コンテ

体験を共有するようになった (参加型文化 [2])．また，スストを 2020 年から毎年開催し，最初の 2 年で集まった

マートフォンの普及により，多くの人々が楽曲との斬新な

52 個の応募作品をもとに，リリックアプリの 8 つのカ

インタラクションを体験できるようになってきた [3]．

テゴリを明らかにし，フレームワークの有効性を評価

こうした社会・文化・技術的背景を踏まえ，我々は本稿において，歌詞カードやリリックビデオに続く歌詞駆動メディアとして，楽曲と歌詞を目と耳でインタラクティブに楽しめる「リリックアプリ (lyric app)」(図 1) を定義する．

するとともに，今後の研究のための知見を得たこと．

2. リリックアプリ
本章では，典型的なリリックアプリの例をもとに，リリックアプリ開発でプログラマが直面する課題を示す．

産業技術総合研究所
a)jun.kato@aist.go.jpb)m.goto@aist.go.jp
1© 2024 Information Processing Society of Japan*1 https://github.com/TextAliveJp/textalive-app-api*2 https://developer.textalive.jp

1

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

リリック
アプリ :

プログラマ
ミュージシャン

INT24001
2024/2/28

Lyric App Framework (https://developer.textalive.jp)
Web ベースの開発ワークフロー ( 4.1)

リリックアプリのインタラクションデザイン用 API ( 4.2)
TextAlive App API (npm: textalive-app-api)

リリックアプリ ( Webサイト)
リリックアプリの大規模配信 ( 4.3)

アプリのユーザ(毎回異なる体験 )ミュージシャンが新しい楽曲を登録できる

リリックアプリは歌詞駆動型の新たな視覚的表現形式でありユーザとのインタラクションで都度異なる歌詞表現を表示できる ( 2)プログラマやミュージシャンが既存の楽曲から選択することもできる

リリック
ビデオ :

ミュージシャン

プログラミング・コンテストで集まった
リリックアプリ 52 作品を分析した結果
8 種類のカテゴリが明らかになった ( 5)

動画共有サービス

モーショングラフィックデザイナ

ビデオの視聴者(毎回同じ内容)

図 1: 「リリックアプリ」は，ユーザが歌詞駆動の視覚表現とインタラクションできるようにすることで，リリックビデオの限界を突破する新たな表現形式である．本稿で提案する「Lyric App Framework」はプログラマとミュージシャンによるリリックアプリ開発を支援する．

2.1 典型的なリリックアプリの例

ション) しなければならない．我々はリリックビデオの制

ある日の午後，アリスはお気に入りのミュージシャン

作支援に関する先行研究 [1, 5] において，音楽理解技術にの新しい SNS 投稿を見つける．投稿内のリンクを辿るとよる自動解析と，解析結果を修正するためのユーザインタ

Web ブラウザがリリックアプリを起動し，新しくリリース

フェースを提案した．こうした半自動的な処理はリリックされた楽曲が流れ始める．楽曲のジャケット画像とタイト

アプリ開発においても有用だと思われるが，アプリの開発

ルが 3D CG 空間内に浮かび上がる．

ワークフローの中へどう組み込むかは自明ではない．

静的なリリックビデオとは異なり，アリスは画面をタッ

次に，ユーザと楽曲および歌詞との効果的なインタラク

チして空間内を自由に動き回り，楽曲のテーマに合ったさ

ションデザインは容易ではない．リリックビデオでは対象

まざまな視覚的オブジェクトを見つけることができる．そ楽曲が一意に決まっており，時間軸に沿った場面展開も最うしたオブジェクトはビートと同期してアニメーションし

終的には一案に収束するため，モーショングラフィックデており，目を楽しませてくれる．歌詞が発声するタイミン

ザイナはその完成形に向けて試行錯誤するだけでよい．一

グでは，歌詞のフレーズが視界に飛び込んでくる．そして，方，リリックアプリ開発では，プログラマは，何度実行さそれを読むだけでなく，タッチ操作でつかんで好きなとこれても飽きないような視覚効果を生成するアルゴリズムをろに置いておくことができ，一度きりの情景を作りあげる

思いつく必要がある．クリエイティブコーディングのためことができる．サビではアニメーションの効果が派手になのライブラリ (3.3 節) の助けは有用だが，リリックアプリ

り，気持ちを盛り上げてくれる．

特有の課題として，さまざまな音楽的要素のタイミングや，

夕方，アリスがふたたびリリックアプリを開くと，同じ歌詞の意味，そしてユーザ入力を考慮に入れる難しさは残3D CG 空間が夕闇のような暗い色で表示される．歌詞のる．したがって，クリエイティブコーディングの実践を邪フレーズも昼間とは違った配置になり，楽曲と歌詞を新鮮

魔しないようなツール支援が極めて重要である．

に楽しむことができ，楽曲をもっと好きになったように感

最後に，リリックアプリをユーザに届ける手段が明らかじられる．さらに，リリックアプリの中で，そのミュージでない．創造性支援ツールの研究はラボスタディが中心でシャンの別の曲を開くこともできる．アリスは，こうした実用性の面で批判されることも多い [6]．しかし我々は，リインタラクションを通して楽曲の世界観により深く浸り，

リックアプリという新たな表現手段を提案するうえで，ラ

個人的かつ唯一無二な体験を得られる．

ボ内に留まらず，プロダクションレディなアプリを開発できるような工学的視点を持つことが重要であると考えてい

2.2 リリックアプリ開発の課題と支援の必要性

る．ミュージシャンが動画共有サービスを使ってリリック

上記の筋書きを踏まえ，リリックビデオ制作とアプリ開

ビデオを多数の視聴者へ配信できることと同様に，プログ発を比較することで，本節ではリリックアプリを開発する

ラマやミュージシャンがリリックアプリをユーザに届けら際にプログラマが直面する 3 つの課題と，それぞれに望まれるようにすることまで考慮するべきである．

れる開発ツールによる支援について考察する．
まず，リリックビデオとリリックアプリを含む歌詞駆動

3. 関連研究

型の視覚表現は，楽曲再生と同期している必要がある．そ

本章では，リリックアプリに関連する先行事例や，自動うした同期を実現するためには，通例，歌詞を含む音楽

同期技術，マルチメディアのためのプログラミング支援技的要素のタイミング情報を手作業でラベル付け (アノテー術を紹介して，本研究の貢献を明確にする．

© 2024 Information Processing Society of Japan2

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

3.1 リリックアプリに関連する先行事例

INT24001
2024/2/28

3.3 クリエイティブコーディング

視覚と聴覚のメディアが同期することで，没入感のある

マルチメディアコンテンツを生成したりインタラクショ体験が実現できる．カラオケは，歌詞のシンプルな字幕表

ン可能にしたりするためのプログラミングを支援するツー示を見ながら，歌詞を正確に覚えていなくても歌を歌っ

ルは数多く存在する．そうしたツールを用い，芸術的な目て，楽曲を楽しめる娯楽である．機器と楽曲によっては，的で創造的にプログラミングすることは，しばしば「クリリリックビデオを再生することで没入感を高める工夫がな

エイティブコーディング (creative coding)」と呼ばれる．

されていることもある．リズムゲーム*3 や，タイピングや

クリエイティブコーディング用のライブラリは Process-

外国語を練習する音楽ゲーム*4 では，楽曲再生と同期して

ing [11] のようにネイティブアプリケーションを構築でき

歌詞を表示できるものもある．

るものだけでなく，p5.js のように Web アプリケーション

これらは歌詞やビートなどの音楽的要素のタイミング情を構築できるものもある．こうしたライブラリは，Web ブ報を利用しており，リリックアプリに関連する先行事例とラウザを備えた端末で実行できるアプリケーションを容易捉えることができる．しかし，これらは，インタラクショに開発でき，人気を博している．リリックアプリの視覚表

ンデザインの観点では比較的狭い応用範囲に留まってい現を実装する助けになるが，プログラマによって好みが分る．カラオケはインタラクティビティに乏しく，ゲームはかれる．そこで本研究では，プログラマが好みのクリエイ

ゲームプレイ自体の楽しさやゲーミフィケーションによる

ティブコーディング用ライブラリを選べるように，フレー

学習効果の向上に主眼が置かれている．我々は，リリック

ムワークを設計している．

アプリには先行事例を超えたポテンシャルがあると考えてなお，我々が研究開発して公開中の Web ベースの大規

おり，デザイン空間を 5 章で示すように探索するため，リ

模音楽連動制御プラットフォーム「Songle Sync」 [12]*5 でリックアプリ開発を支援するフレームワークを構築した．

は，楽曲再生に合わせて多種多様な機器でのマルチメディ
ア演出を同時制御できる．我々は，Songle Sync およびそ3.2 楽曲と歌詞の自動同期技術の先行研究である Songle Widget [13]*6 において，ビート

視覚表現と楽曲が同期したリリックアプリならではの体などの音楽的要素と連動する演出を手軽にプログラミング

験を実現するアプリケーション開発を支援するためには，歌できるイベント駆動型の API を提供した．ただし，歌詞関

声を含む楽曲 (混合音) と歌詞などの音楽的要素を自動対応

連の情報や声量などは利用できない．また，後述 (4.2.2 節

付けする技術が必要となる．LyricSynchronizer [7] は，楽) のとおり，イベント駆動型の API には高度な演出を開発

曲と歌詞の自動対応付けを行い，歌詞テキストをクリックす

しづらく，時間精度が落ちやすい問題がある．本研究では，ることで楽曲の再生位置を操作できるユーザインタフェー

これらの技術的制約を解消する API を新たに提案する．

スを提供した．TextAlive [1] は，さらにリリックビデオを制作でき，アニメーション用アルゴリズムをライブプログ

4. Lyric App Framework

ラミングできる統合制作環境を実現した．SyncPower [8]，2.2 節で整理したとおり，プログラマはリリックアプリ

Musixmatch [9]，そして LyricFind [10] は，歌詞テキスト

開発において 3 つの課題に直面する．本章では，各課題をを取得するための API と，取得したテキストをカラオケの解決する 3 つの主要機能を備えたフレームワーク「Lyric

ように表示するためのプチリリ機能，FloatingLyrics，そApp Framework」を提案する (図 1)．

して Lyric Display と呼ばれる視覚的コンポーネントを提供している．

4.1 Web ベースの開発ワークフロー

本研究は，ベース手法としている TextAlive を除き，これまず，楽曲中の音楽的要素と同期した演出開発を容易にらの先行事例と 2 つの点で異なる．まず，先行事例では既するため，Web ベースのワークフローを提案する．この存の楽曲の情報を取得することしかできないが，本フレー

ワークフローでは，開発中いつでも新たな楽曲を扱えるよムワークでは，ユーザは新たな楽曲と対応する歌詞テキスうにしたり楽曲を差し替えたりでき，プログラマやミュートを自由に登録できる．次に，既存の商用 API では，歌ジシャンのニーズに柔軟に対応できる特長がある．

詞テキストを取得できても，タイミング情報に直接アクセ

4.1.1 自動解析とクラウドソーシング

スできない．一方，本研究が提供する TextAlive App API

本フレームワークは，我々が研究開発してきた能動的音

では，歌詞のテキストや，歌詞を含むさまざまな音楽的要

楽鑑賞サービス「Songle」 [14, 15]*7 の機能を拡張するこ

素のタイミング情報へ直接かつ統一的な方法でアクセスでとで，リリックアプリ開発に役立つ情報 (表 1) を提供し，きる．この 2 点の新規性は，プログラマが好きな楽曲のリ必要に応じて誤りを修正できるようにする．

リックアプリを開発できるようにする鍵となる．
*5 https://api.songle.jp/sync*3 http://miku.sega.jp/flick*6 https://widget.songle.jp*4 https://lyricstraining.com*7 https://songle.jp© 2024 Information Processing Society of Japan3

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

表 1: リリックアプリがアクセスできる解析結果の一覧
解析結果

説明

歌詞タイミング

歌詞テキストの各フレーズ，単語，文字が発声を開始し，終了するタイミング情報

品詞

歌詞テキストの各単語の品詞

声量

歌声の音量の時系列変化

音楽印象

音楽の印象の移り変わりを表す V/A(valence

arousal) 平面上の座標値の時系列変化
ビート構造

四分音符に相当する各ビートや，各小節の先頭のタイミング情報

INT24001
2024/2/28

リリックアプリの初期化
onAppReady

アプリのカスタマイズ
onAppMediaChange
onAppParameterUpdate

楽曲の読み込み
解析結果の読み込み

on{SongMap, Lyrics, ...}Load

楽曲再生のための DOM 要素埋め込み

onTimerReady

楽曲の再生コントロール
onPlayonPauseonSeekonVolumeUpdate...

図 2: 複雑な状態管理を支援するイベント駆動型 API

4.2 リリックアプリのインタラクションデザイン用 API
次に，ユーザと楽曲・歌詞の間のインタラクションデ
ザインを支援するため，プログラマ向けの TextAlive App

API*1 を提案する．本 API は楽曲再生の状態を管理できる

コード進行

コード名と各コード区間のタイミング情報

イベント駆動型の API と，楽曲再生と精密に同期した演出

楽曲構造

サビ区間や，楽曲中の繰り返し区間のタイミンを表示できる時刻駆動型の API に大別される．

グ情報

4.2.1 状態管理用のイベント駆動型 API
リリックビデオは常に単一の課題曲と紐づいているが，プログラマやミュージシャンのワークフローは以下のとリリックアプリは単一の楽曲向けのこともあれば，特定のおりである．まず，フレームワークの Web インタフェース

楽曲セットで実行できたり（例: ユーザがプレイする曲目をを通してリリックアプリで利用したい楽曲と歌詞テキスト

選べるリズムゲーム），任意の楽曲で実行できたり（例: イの組を登録する．楽曲と歌詞テキストは新規にアップロー

ンタラクティブなビジュアライザのついた音楽プレイヤー）

ドすることもできるし，すでに Web 上にあって二次利用にする．さらに，リリックアプリは，特定の操作をユーザに関する適切なライセンスが付与されているものなら URL

許可したり禁止したりできる．例えば，音楽プレイヤーはを指定するだけでもよい．登録から約 10 分後には，自動楽曲再生を一時停止したり，任意の再生位置にシークした解析の結果がフレームワークの Web サーバ上で利用可能

りできるが，ゲームはどちらの操作も禁止していることがになり，リリックアプリ上で読み込めるようになる．

多い．楽曲の物語性を強調するアプリケーションでは，一

その後，歌詞を含む音楽的要素の自動解析されたタイミ

時停止は可能でも，シークは禁止されていたりする．

ング情報を Web インタフェースで確認し，必要に応じてこれらすべてのインタラクションシナリオの実装を支援修正できる．こうしたクラウドソーシングによる自動解析するために，我々はリリックアプリが取りうる状態の一覧

結果の修正はすでに Songle 上で可能であったが，我々はを図 2のように整理して定義した．本 API では，JavaScript本研究や TextAlive の研究で，歌詞タイミングの修正も可

クラス Player が，フレームワークの機能を利用するエン能にしたほか，歌詞単語の品詞の自動検出や，タイミング

トリーポイントとなっており，そのインスタンスにイベン

情報のリビジョン管理まで可能な拡張を施した．

トリスナを登録すれば，状態間の遷移が通知される．

4.1.2 キーとしての楽曲 URL

4.2.2 時間精度を要するインタラクションデザイン用の本フレームワークでは，楽曲の URL が歌詞テキストと時刻駆動型 (time-driven) API

解析結果を取得するためのキーとなる．プログラマは，楽グラフィカルユーザインタフェース (Graphical User In-

曲 URL のリストを保持することでユーザに楽曲を選ばせterface; GUI) 用のフレームワークや，我々が研究開発しることができ，単一のリリックアプリで複数の楽曲を開く

た音楽連動制御のためのプラットフォーム「Songle Sync」

ことが可能となる．ミュージシャンは，未リリースの楽曲[12] では，イベント駆動型の API によって，時系列に発生について，一般には非公開の暫定 URL でアプリの振る舞するイベントに応じたインタラクション設計が行えるよういを確認し，リリース時には公開 URL に差し替えて，楽になっている．しかし我々は，リリックアプリ用の API を曲のプロモーションに役立てることができる．

a に設計するにあたり，次に述べる 3 つの理由から，図 3 ○なお，楽曲 URL だけを指定した場合，解析結果 (あるい示す音楽的要素のイベントをサポートしないことに決めた．

はユーザによる修正結果) の最新版が読み込まれるが，さまず，イベント駆動型の API において，イベントは通常

らに数値型のリビジョン番号を指定することで，特定の版

何かが起きた直後にのみ発行されるため，未来のイベントのデータを取得できる．これにより，クラウドソーシングに向けた準備をコーディングする目的には向いていない．

で仮に悪意ある修正が行われた場合にも影響を受けずに済例えば，歌詞の単語の発声開始イベントを使って，発声よむ．本節のような工夫は，本フレームワークに限らず，静りも充分前に画面内に滑り込み始めるような予備動作を的メディアにインタラクションを追加する今後の研究でも伴うアニメーションの設計には使えない．次に，イベント有用であろう．

は個々の音楽的要素に紐づいて提供されるが，魅力的な視© 2024 Information Processing Society of Japan4

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

ビート
歌詞単語
歌声の
声量
a

INT24001
2024/2/28

3

外的要因 ( CPU の過負荷など ) によりイベントの精確な発行が妨げられうる

onBeat...
onBeatonBeat“I”

onBeat(7 イベント )“think”

onWordLeave
onWordEnter
onWordEnter

“of”

1

本フレームワークでのアプリ開発

音楽的要素に関するイベントは，しばしば
on{Type}{Enter,Leave} のように分割する必要がある

イベント駆動型 API ( 典型的な実装 )歌詞単語

カスタマイズ可能なパラメタの一覧と GUI

外的要因で画面が描画できなかった間のビートは無視できる

findBeat(position)“I”“think”“of”

findWord(position)

歌声の声量

リリックアプリで開きたい楽曲の URL

リリックアプリを実行するための <iframe>

onVocalAmplitudeUpdate 音楽的要素のなかには時系列で値が変化するものがあり，
onVocalAmplitudeUpdate 滑らかな演出のためにイベントを頻繁に発行する必要がある

ビート

Lyric App Customizer

2

Webサイトとしてのデプロイによる大規模配信

図 4: Web サイトとして大規模配信した後の，事後的なカ

getVocalAmplitude(position)

レンダリング関数 プログラマは再生時刻に紐づいた情報を好きなときに好きなだけ問い合わせでき，

スタマイズを可能にする Lyric App Customizer

複数種類の情報を考慮に入れながら，常に最新の再生状態を反映した演出を行えるb

時刻駆動型 API ( 本研究での提案 )ビート

Beat[1]
Beat[3]Beat[2]
Beat[4] ...
A

findBeatChange(A, B)

B

C

...

...

...

...

...

...

...

...

D

{ current: Beat[1], entered: [ ], left: [ ] }findBeatChange(C, D){ current: Beat[4], entered: [Beat[4]], left: [Beat[3]] }findBeatChange(A, D){ current: Beat[4], entered: [Beat[2]~[4]], left: [Beat[1]~[3]] }c

時区間駆動型 API ( 実証実験で新たに考案された設計 ; 6.1.2 で詳述 )図 3: 精密な時刻同期が必要なインタラクションデザインを支援する API の 3 類型

成する際に役に立つ，GUI やクリエイティブコーディング用のライブラリと相補的な役割を果たす．こうしたライブ
ラリでは，通常，描画すべき内容を定義するレンダリング
用の関数をプログラマが定義するようになっている．例えば，Web API における requestAnimationFrame() ，p5.js における loop() ，Three.js における renderer.render() などである．プログラマは，各関数内で時刻駆動型 API を呼ぶことで，複合的な音楽的要素を考慮した視覚表現を設計できる．描画内容は，常に楽曲再生の最新の状態を反映し覚表現はしばしば複数の音楽的要素と連動している．例えていることが保証される．このように，本 API はプログラ

ば，歌詞のフレーズ発声時に周囲に現れる水紋のような視c
マが好みのライブラリと併用できる特長がある．図 3 ○覚表現を考える．水紋はビートに合わせてフェードインとで示した API 設計の拡張に関しては 6.1.2 節で後述する．

アウトを繰り返すかもしれないし，サビの歌詞かどうかによって色が変わるかもしれない．イベント駆動型 API で

4.3 リリックアプリの大規模配信

は，フレーズの発声開始，ビート，サビ区間といったすべ

最後に，ユーザにリリックアプリを届ける方法が自明でてのイベントについてリスナを定義し，情報をどこか別のない課題に関して，本フレームワークは，プログラマやロジックで集約してアニメーションさせる必要が生じて不ミュージシャンがリリックアプリを Web サイトとして安便である．最後に，イベント駆動型 API では時間精度が低

定的に大規模配信できる仕組みを提供する (図 4)．

くなりがちである．こうした API を提供するためには，フ4.3.1 プロダクションレディなアプリ配信

レームワーク内にイベントループを設け，現在の再生位置

一般に，インタラクティブなメディアコンテンツの配信と各種イベントの時刻情報を比較し続けるという実装が典は 2 つの観点で難しい．まず，ユーザを取り巻く情報環境型的である．この場合，各種イベントは最悪値でイベント

は千差万別であり，多くのユーザがインタラクションを楽

ループの実行間隔分，遅れて発行される可能性がある．こしめるような相互運用性を担保する必要がある．そして，のように時間精度を保証できない API は，求める表現を得コンテンツの利用者数は時と場合によって大きく上下する

るうえで不充分なことがあり，時間精度が意図せずに低くため，一度に大量のアクセスがあった場合などにも対応でなった場合に初学者が混乱する可能性もある．

きるスケーラビリティを確保しなければならない．

これらの課題を解決するために，我々は，引数にミリ秒

そこで我々は，インタラクティブミュージックの大量流

単位の再生位置の数値を取り，その引数で指定された時通に関する議論 [3] を参考にして，現状もっとも現実的な点での音楽的要素を開始・終了などの時刻情報付きで返す

解は，アプリを Web 標準に則った Web サイトとして配信b ) を提案する．例「時刻駆動型 (time-driven) API」(図 3 ○できるようにすることだと考えた．本フレームワークを使えば，5 秒後に発声が始まる歌詞フレーズの情報を取得すえば，プログラマが Web サイトを構築する技術さえ持っるには player.getPhrase(player.position + 5000) というていれば，上記のような大量流通が可能なプロダクション

API を呼び出せばよい．さらに，同じ引数で getBeat とレディのリリックアプリを実装できる．

いう API を呼ぶなどすれば，フレーズ，ビート，サビ区間

4.3.2 Lyric App Customizerの情報をすべて考慮に入れた視覚表現を実装できる．
時刻駆動型 API は，インタラクティブな視覚表現を生© 2024 Information Processing Society of Japan

本フレームワークは，プログラマやミュージシャンがリ
リックアプリの挙動をカスタマイズできるよう，TextAlive5

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

Lyric App Customizer*8 という Web インタフェースを備え

INT24001
2024/2/28

5.1.1 コンテストのルールと進め方ている (図 4)．例えば，4.2.1 節で紹介した音楽プレイヤー

コンテストは「マジカルミライ」イベント会場での入のように，楽曲を自由に指定できるリリックアプリの場合，選作品紹介と受賞作品発表を除けばオンラインで進行しミュージシャン側で楽曲の URL をカスタマイズできる．

た．主催側でリリックアプリの開発に必要な権利処理が済

カスタマイズ結果は，最終的にはリリックアプリの URL

んでいる楽曲と歌詞を課題曲として提供することで，参に与えるクエリパラメータとして， ?ta_song_url=NewUrl

加者が開発に集中できるようにした．コンテストの応募のように永続化できる．

期間中，5.1.2 節で後述する参考資料をオンラインで提供

また，楽曲 URL の他にも，プログラマは自由にカスタマ

し，Twitter*10 や Gitter*11 で参加者からの質問に適宜回答

イズ用パラメタのリストを定義でき，定義されたパラメタのした．コンテストの応募に際して (参加は無料)，参加者は

一覧は，Customizer 上でスライダーやカラーパレットなど

静的 Web アプリケーションのソースコードとビルド手順の GUI として表示される．GUI が操作されてパラメタ値がを提出した．サーバ側のプログラムを含まない静的アプリ

調整された場合，リリックアプリには onParameterUpdate

ケーションに限ったのは，応募作品を主催側の Web サー

イベントが通知されるため，対応する処理をプログラマがバに設置して誰でも楽しめるようにするためである．

実装すれば，アプリの振る舞いを誰でもインタラクティ

各年，応募を締め切ってからは，主催側の審査で入選作

ブにカスタマイズできるようになる．ミュージシャンは，品を選定し，入選作品発表とともにオンラインでの一般投

Customizer でリリックアプリを自身の楽曲向けにカスタ票を受け付けた．1 週間弱の一般投票の期間が終わってか

マイズして，プロモーションに繋げることができる．

ら，投票結果を踏まえて主催側で改めて審査を行い，受賞

5. プログラミング・コンテストでの実証実験
我々は 2020 年 9 月 18 日に TextAlive App API を含む

作品 (最優秀賞 1 件，優秀賞 3 件) を選定した．受賞作品発
表後に，事後アンケートを参加者にオンライン配布しており，その結果は 5.3 節で報告する．

Lyric App Framework を一般公開し，年次のプログラミン

なお，主催側の審査の評価軸は，クリエイティビティ

グ・コンテストを開催してきた．これは実証実験として，(Web アプリケーションの演出が楽曲と同期して魅力的に

以下の 3 つの目的を持つ．第一に，創作文化を楽しみ，創見えるか)，イノベーション (Web アプリケーションを支え作文化に貢献する人々が集まるイベントでのコンテスト開るアイデアがユニークで，未来の創作文化を予感させるも催により，未来志向のプログラマとともにリリックアプリのであるか)，完成度 (Web アプリケーションが一般的なのデザイン空間を探索する（事例を収集，分析し，リリッ

Web ブラウザで正常に動作するか，実装が技術的に優れてクアプリの特徴について理解を深める）．第二に，本フレーいるか) であった．3 つの評価軸はコンテストの公式 Web

ムワークが，4 章で述べた設計により，初学者から熟達者

サイトに明記され，参加者はいつでも確認できた．

まで幅広いプログラマを支援できることを確かめ，よりよ

5.1.2 フレームワークの参考資料

い API 設計などの示唆を得る．第三に，リリックアプリ

我々は，Lyric App Framework を公開する際に，チューが，音楽を題材にプログラミングに取り組める新たな機会

トリアルや API リファレンス，スライドの読み上げとデモを生み，プログラマの創作コミュニティ参入を後押しし，を交えた説明動画などの参考資料を Web サイト*2 に掲載

同コミュニティを活性化できる，という仮説を検証する．

した．チュートリアルはフレームワークの概要を紹介する

以降，本章では，プログラミング・コンテストについてとともに，リリックアプリの開発を始めるための手順を説紹介するとともに，2 年分の応募作品 52 件を分析して判明明する内容であった．さらに，フレームワークの使い方をしたリリックアプリのカテゴリ 8 種類などの結果を報告す

デモするために 11 件のリリックアプリを開発し，GitHub

る．また，質的ユーザ評価の結果を紹介する．

上で MIT License のサンプルコードとして公開した*12 ．
我々はこれらのリリックアプリがフレームワークの代表

5.1 プログラミング・コンテストの概要的な機能を活用したものになるよう注意深く設計したが，プログラミング・コンテストは，年次の大規模イベント

同時に，サンプルコードとして多くの人々の環境で動作す『初音ミク「マジカルミライ」』の一環として開催されてきるよう，スマートフォンや PC，タブレット端末など多様

た．本イベントは著名な歌声合成ソフトウェアでありバーな Web ブラウザ上で動作する互換性にも気を配った．そチャル・シンガーである「初音ミク」を生み出したクリプのため，実験的な Web 標準 API (位置測位，加速度セン

トン・フューチャー・メディア株式会社が主催し，「初音ミ

サ，Bluetooth など) は利用していない．

クたちバーチャル・シンガーの 3DCG ライブと，創作の楽しさを体感できる企画展を併催したイベント」*9 である．
*10 https://twitter.com/TextAliveJp*8 https://developer.textalive.jp/app/customize*11 https://gitter.im/textalive-app-api/community*9 https://magicalmirai.com*12 https://github.com/TextAliveJp© 2024 Information Processing Society of Japan6

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

INT24001
2024/2/28

1

拡張現実アプリ

2

制作ツール

3

創造的即興アプリ

4

楽器アプリ

5

ゲーム

6

拡張音楽動画7

インタラクティブリリックビデオ

8

ジェネラティブリリックビデオ

図 5: プログラミング・コンテスト応募作品の分析で判明したリリックアプリのカテゴリ 8 種類と，その代表例のスクリー
ンショット (スクリーンショット提供: クリプトン・フューチャー・メディア株式会社)

5.2 リリックアプリの 8 種類のカテゴリ
2 回のプログラミング・コンテストはそれぞれ 47 日間とこうして作り上げた 3D の情景は，実世界で同様の平面を再現すれば実際のプロジェクションマッピングに活用でき

77 日間にわたって応募期間が設けられ，32 件と 20 件の応るようになっていた．

募があった．提出された全 52 件のリリックアプリはすべ

5.2.3 創造的即興アプリ (creative application)て完成して実行可能な状態であった．それらのリリックア

このカテゴリは，ユーザが再生中の楽曲と創造的にインプリの驚くほど豊かなデザイン空間を理解するため，我々タラクションできるようにしてくれる．制作ツールと異なは各リリックアプリの内容を説明する短い文章を書き，そり，このカテゴリでは基本的にシーク操作が許可されておの説明文をもとにしたテーマ分析的な手続きを経てリリッ

らず，その代わり即興的な体験に重点が置かれている．例

クアプリを 8 種類に分類した．52 件の応募作品は，9 件のえば曲を聴きながら曲の終わりまで絵を描ける作品 (図 5

拡張現実アプリ，6 件の制作ツール，6 件の創造的即興ア3 ) や，タッチ操作で画面上に音符を置いていくとサビで○プリ，3 件の楽器アプリ，6 件のゲーム，2 件の拡張音楽動

その音符が踊りだす作品などがあった．

画，5 件のインタラクティブリリックビデオ，16 件のジェ

5.2.4 楽器アプリ (instrument)

ネラティブリリックビデオに分類された．

このカテゴリは，ユーザが楽曲演奏に能動的に関与する

5.2.1 拡張現実アプリ (extended reality)

ための楽器や道具の役割を果たす．例えば，MediaPipe.js

このカテゴリは，仮想的な 2D・3D の情景における没入を用いたカメラ入力の画像処理によってユーザの手の動き

感のある体験に重点を置いている．カメラ入力を活用しを推定し，画面上の仮想的なペンライトに割り当てた作品て，実世界の情景に歌詞駆動の視覚的演出レイヤーを追加

4 )．また，Web MIDI API を用いて接続があった (図 5 ○するものもある．ユーザは楽曲の世界観の中にいるようにされた MIDI 機器の信号を読み取り，楽曲再生と同時に演感じられる．例えば，特定の楽曲のために作り込まれた，奏ができる作品があった．ユーザのクリック操作のタイミ

1 ) があっ学校の教室の中を自由に動き回れる作品 (図 5 ○ングで既定の音を鳴らす作品もあった．

た．この作品では，教室の中に歌詞のストーリーと関連の5.2.5 ゲーム (game)

ある隠し要素が配置されており，これを見つける楽しみ方

このカテゴリは何らかのルールや得点制を採用しており，もできるようになっていた．別の作品では，WebVR API

ユーザにゴールしたり高得点を取ったりしたいと思わせるを使って VR ヘッドセットで仮想空間に飛び込めるもの

ような仕掛けが実装されている．典型的なゲームアプリでや，AR.js を使ってカメラ画像の手前に歌詞がタイミング

は，本フレームワークを活用することでユーザが課題曲をよく表示される立方体を映し出すものなどがあった．

選べるようになっている．ゲームに分類された応募作品の5.2.2 制作ツール (authoring tool)

すべてが，次々に出現する歌詞テキストとうまくインタラ

このカテゴリは，楽曲と同期した派生コンテンツを制作

クションすることを目指す音楽リズムゲームであった．例

し，作り込み，場合によっては他の人と共有することまで

えば，ユーザがライブステージ上のキャラクタを操作して，可能にする．例えば，プロジェクションマッピング用のコ

飛んでくる歌詞テキストにタイミングよく触れるゲーム作

2 )．ユーザは，ンテンツを制作できる作品があった (図 5 ○5 )．
品があった (図 5 ○曲ごとの内容を踏まえて定義された仮想的な 3D 空間で，5.2.6 拡張音楽動画 (augmented music video)

特定の平面上に視覚的要素を配置していくことができた．

© 2024 Information Processing Society of Japan

このカテゴリは対象楽曲の音楽動画を表示し，その再生

7

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

INT24001
2024/2/28と同期したインタラクティブな体験を提供する．例えば，

ついて詳細に尋ねた．回答によれば，まったくの未経験か

特定の楽曲の音楽動画が画面右下に表示され，その情景をら 6 年の JavaScript 実務経験まで多様で，フレームワー

参考にしたインタラクティブな視覚的要素が画面の他の領クの敷居が低く，天井が高い (熟達者の創造性を制限しな

6 )．キャラクタが画面域に表示される作品があった (図 5 ○い) ことを示している．とくに，回答者の実に 3 分の 1 が左から右に歩くシーンでは，ユーザがカーソル操作でキャ

JavaScript を用いたプログラミングの経験がほぼゼロでラクタを左右に動かせるようになっていた．また，操り人あったことは驚きであり，それでもコンテストに参加した形が操られて変形するシーンでは，ユーザがマウス操作で動機について 6.2 節で考察する．

変形の仕方をコントロールできるようになっていた．

5.2.7 インタラクティブリリックビデオ (interactive
lyric video)

このアンケートでは，参加者が時刻駆動型 API に満足しているか，そして歌詞などの音楽的要素に対するイベントリス
ナ ( player.addEventListener("phraseEnter", listener) な

このカテゴリは，リリックビデオを動的に描画したうえど) の必要性を感じているかについても質問した．回答はで，ユーザがインタラクションできるようにしたものであ

現状の API 設計に肯定的で，リリックアプリの状態管理用

る．例えば，歌詞テキストが 3D の仮想空間内を右から左に 4.2.1 節のイベント駆動型 API は利用しているものの，にスクロールする情景を描いた作品では，ユーザがテキス

我々の提案する時刻駆動型 API は合理的であり，リアルタ

トをマウスかタッチのドラッグ操作でつかんで左右に動かイムなマルチメディア演出において有用であると考えてい7 )．
し，再生位置を変更できるようになっていた (図 5 ○た．一人の回答者のみ，イベントの種類が多いほどよいと

5.2.8 ジェネラティブリリックビデオ (generative lyric

回答していたが，他の回答者からはそうした要望はなかっvideo)
このカテゴリはリリックビデオをプログラムによって動的に描画するもので，単なる動画であればアスペクト比やフレームレートが固定であるのに対し，それらをユーザのた．別の回答者は，複雑なシーン管理を実現するためには
現在の API 設計では不充分だとコメントしていた．

6. 議論

閲覧環境に応じて柔軟に変更できるものが多い．シーク操「リリックアプリ」という表現形式は，我々が提案した作のような基本的な再生操作は可能だが，それ以外のインもので，現状研究対象としてはニッチと言えるかもしれな

タラクションには対応していない．

い．しかし本研究は，3 つの幅広い観点で研究上の貢献がこのカテゴリの典型的なリリックアプリはリリックビデある．まず，音楽情報処理の研究者，より広くは音楽業界

オと似た体験をユーザにもたらすが，好みのスタイルにカの人々にとって，音楽コンテンツを取り巻くインタラク

スタマイズできる作品がある他，視覚表現として見たときティブな体験の重要性は従前より指摘されており [16]，リに，歌詞のタイミングやその他の音楽的要素に合わせてア

リックアプリはそうした体験を提供する有望な一手段とな

ニメーションする同期的演出が多用される特徴がある．なる．本フレームワークはリリックアプリの開発を支援する

お，リリックビデオでは見られない表現を追求した例外的初めての取り組みであり，実証実験の第一の目的であったな作品もあった．例えば，楽曲全体を特定の数のパートにデザイン空間の探索が実施できたことも含めて，リリック

分割し，イラストも同数のパネルに分割して，それぞれパ

アプリをニッチからメインストリームへ押し上げる重要な

8 )．楽曲のズルのピースに見立てた作品があった (図 5 ○技術的・文化的マイルストーンである．

再生が進むにつれ，ピースが画面上の適切な場所にはめこ次に，実証実験の第二の目的であるフレームワークの有まれ，楽曲再生が完了するタイミングでイラストが完成す

効性検証の結果，6.1 節で後述するとおり，幅広い熟達度る演出となっていた．

のプログラマにとって有用であることが分かっただけでな
く，精密な時刻同期が必要なインタラクションデザイン全5.3 質的ユーザ評価

般で有用な知見が得られた．最後に，実証実験の第三の目

我々はプログラミング・コンテスト参加者に自由記述で的であった，リリックアプリがプログラマの創作コミュニのアンケート回答を依頼し，各年に 21 件と 15 件の回答がティへの参画機会を生むという仮説は，6.2 節で後述する寄せられ，コンテストに参加した動機やフレームワークにとおり検証できたと言ってよく，さらに，創造的文化に関関するコメントなどの質的フィードバックを収集できた．

する今後の研究への示唆も得られた．

例えば，プログラミング・コンテストが創造的な文化にプ
ログラミングの力で貢献する貴重な機会となっていること

6.1 時刻駆動型 API に関する知見を大きく評価する旨のコメントがあった．フレームワーク

5.3 節で紹介したとおり，本フレームワークは幅広い熟に対しては肯定的な感想が大部分を占めたものの，致命的達度のプログラマが利用でき，とくに時刻駆動型 API は肯ではないが修正すべきバグに関する報告も寄せられた．

定的に評価された．本節では，さらにソースコード分析で2 年目のアンケートでは参加者のプログラミング経験に© 2024 Information Processing Society of Japan

得られた知見として，高度な演出をプログラミングするに

8情報処理学会 インタラクション 2024
IPSJ Interaction 2024は再利用可能なコンポーネントが重要性なこと (6.1.1 節)，

INT24001
2024/2/28

6.2 静的メディアへのインタラクティビティ付与

そうしたデザインパターンを支援するために，新たな API

リリックアプリ開発は，プログラムを何もない状態から設計が有用な可能性があること (6.1.2 節) を報告する．

コーディングし始める体験とは異なっている．なぜなら，これらの知見は，精密な時刻同期が必要なインタラク

既存の楽曲に対して新しくインタラクションする機能を追ションデザイン全般に応用できる．例えば，音と映像を同加するプロセスだからである．本節では，こうした，既存期させる演出の他，センサとアクチュエータを活用した実のコンテンツを拡張するプログラミング体験が持つ利点

世界インタラクションの開発支援でも有用だと考えられる．

と，今後の研究に向けた論点を議論する．

6.1.1 リリックアプリにおける再利用可能コンポーネント

6.2.1 創造性のキックスタート

コンテスト応募作品のほとんどが，クリエイティブコー

我々は，実証実験を通して，本フレームワークが典型的

ディングや GUI のライブラリのレンダリング用関数 (4.2.2

なクリエイティブコーディングのコミュニティよりも広範

節) を利用して画面演出をプログラミングしていた．このなコミュニティに訴求できており，参加者の開発成果公開

ようなジェネラティブなアルゴリズムは，単一の巨大な関を促進できていると感じた．ある参加者は，通常であれば数としても実装できるが，こうした方法は単調な映像表現

こうしたコンテストには参加しようと考えないし，参加でに繋がりやすく，我々はアンチパターンだと考えている．

きなかっただろうとコメントしていた．コンテスト課題曲

我々が分析したソースコードの中では，関数を細分化しへの愛が，こうした参加者にリリックアプリ開発とコンテて多くの再利用可能なコンポーネントとして扱うデザイン

スト参加を促していた．クリエイティブコーディングは近パターンに沿ったものが，モジュール性を向上できており，

年コンピュータ科学教育や芸術的意義の観点で注目を集め

複雑で魅力的な画面演出に成功している傾向にあった．

ているが，すべてのプログラマが，自身が (クリエイティ

6.1.2 時区間駆動型 (time-range-driven) API

ブコーディングを楽しめるほどに) 充分「創造的 (クリエイリリックアプリ開発において，前述のような再利用可能ティブ)」だという自信を持っているわけではない．

コンポーネントのライフサイクルが，音楽的要素の可聴時

リリックアプリには，そうしたプログラマが「創造的」区間 (ビートから次のビートまでの区間やフレーズの発声な部分で既存の楽曲の力を借りて，結果として自身の創造

区間など) に紐づいていることは注目に値する．我々は，性を発揮するキックスターターにできるポテンシャルが分析したソースコードの中で，現在の再生位置が可聴時区ある．我々は，プログラミングという活動それ自体が充分間から出入りしたことを検出する機能がたびたび実装され「創造的」であると考えており，より多くの人々が創造性ていることを発見した．例えば，ある作品では，画面上のを発揮するきっかけにリリックアプリがなってきたことをパーティクルの出現を管理するパーティクルマネージャが，嬉しく思っている．こうしたリリックアプリ開発は，コン

前回の player.findPhrase 関数の呼び出し結果を保存し，ピュータ科学教育のカリキュラムでも役立つはずである．

前回と今回の結果を比較することで，パーティクルを表す

さらに，音楽以外の静的メディアコンテンツに対してもイ

オブジェクトを初期化するか破棄するか決定していた．

ンタラクティビティを付与するようなクリエイティブコー

こうしたデザインパターンは，次のような「時区間駆動c ) で支援できる:型 (time-range-driven) API」(図 3 ○player . f i ndP h ras eChange ( previousPosition ,cu rr ent Po sitio n ) ;ディングへの発展も，今後の研究として興味深い．

6.2.2 コミュニケーションとしてのプログラミング
リリックアプリの開発過程で，プログラマは何度も繰り返し楽曲を聴き，歌詞を読むことになる．こうした体験を通して，プログラマは魅力的な歌詞駆動型の演出を思いつ

返値は，その時区間で発声を終えたフレーズ群，発声を始くのかもしれない．リリックビデオがミュージシャンとデめたフレーズ群，そして発声中のフレーズの三つ組となる．

ザイナの協力関係を可能にしたことと同様に，リリックア

この API は，リリックアプリ開発において次の観点で有プリはミュージシャンがプログラマと協力する新たな機会用である．まず，プログラマが自身のコードで能動的に情を生み出している．
「プログラミング環境」はコンパイラや報を取りに行く API の特長が保たれるため，さまざまなク

エディタなど単なるソフトウェアの集合と見なされがちだ

リエイティブコーディングや GUI のライブラリと併用でが，実際には人々と人工物（ソフトウェアと，参考資料なきる．次に，プログラマが任意の時区間を自ら定義して複どのコミュニケーション媒体）が織りなす共創的な環境で雑なシーン管理を実現できる．例えば，サビ区間に突入すある [17]．例えば，拡張音楽動画のリリックアプリ (図 5

る 5 秒前にアニメーションを始めたければ，以下のように6 ) を開発した参加者は，元の楽曲と音楽動画の作者に問○時区間駆動型 API を呼び出してシーン変化を監視できる:

い合わせを行い，派生作品の共創的な開発を楽しんでいた．

player . f i ndC h oru sChange ( previousPosition ,cu rr ent Po sitio n + 5000) ;プログラミング・コンテストの受賞者を発表する「マジカルミライ」の企画展ステージにおいて，コンテストを主催するクリプトン・フューチャー・メディア株式会社の代© 2024 Information Processing Society of Japan9

情報処理学会 インタラクション 2024
IPSJ Interaction 2024

INT24001
2024/2/28

表取締役であり，音楽業界に詳しい伊藤 博之氏は，音楽と技術の密接な関係に以下のように言及した．『ミュージシャ
ンが聴衆に音楽を届ける方法は常に科学的発明の影響を受[4]けてきた．リリックアプリは，プログラマが創作文化に貢献できる機会を増やす新しいプラットフォームであり，今後の展開に期待している．』（抜粋の上，要約して掲載）

6.2.3 創造的文化に関する今後の研究
創造性支援の研究は長らく，技術的新規性に偏重したも[5]のが多く，評価実験もラボスタディなど統制的な環境が主流で，「在野 (in the wild)」での研究が不足していると批判されてきた [6]．コンテンツの価値が，派生作品や聴衆[6]の SNS での関与なども含めて総体的に評価されるユーザ
参加型文化 [2] の時代において，コンテンツを取り巻く生
態系はますます広がりを見せており，その実態を踏まえた研究のためにも，在野での研究の重要性は増している．

[7]

本フレームワークは一般公開されており，まさに在野での取り組みと見なすことができるが，本稿で報告した実証実験でも，コンテスト形式に起因する制約はまだ残っていた．例えば，サーバサイドのプログラムを含められなかっ
たり，ソーシャルな機能の実装や実験的な API の採用が見送られがちだったりした．我々は，本フレームワークの研

[8]
[9]
[10]

究開発を続け，在野での活用を支援し続けることで，新たなリリックアプリのカテゴリが切り拓かれ，創造的文化に関する構成論的研究をさらに進められると信じている．

[11]

謝辞 プログラミング・コンテストはクリプトン・フュー
チャー・メディア株式会社が運営した．こうした取り組み[12]は，新しい技術が人々の創造性に貢献するという信念を共有した信頼・協力関係のもとで可能となったものである．
また，継続的なコンテスト開催は，情熱的な参加者による応募がなければ実現しなかった．参加者の尽力に感謝する[13]とともに，リリックアプリの可能性を切り拓く学術的取り組みの中で応募作品を紹介できたことを嬉しく思う．
本フレームワークの Web ベースのワークフローに貢献
した産総研の関係者各位にも感謝したい: 中野 倫靖 (歌詞[14]

同期エンジン)，渡邉 研斗 (形態素解析 API)，川崎 裕太・
井上 隆広 (Songle および Songle API)．本研究の一部は以下の支援を受けた: JST CREST (JPMJCR20D4)，JST[15]

ACCEL (JPMJAC1602)，JST ACT-X (JPMJAX22A3)．
参考文献
[1]

[2]

[3]

Kato, J., Nakano, T. and Goto, M.: TextAlive: Integrated Design Environment for Kinetic Typography,
Proceedings of the 33rd Annual ACM Conference on
Human Factors in Computing Systems, CHI ’15, pp.
3403–3412, DOI: 10.1145/2702123.2702140 (2015).
Jenkins, H.: Confronting the challenges of participatory
culture: Media education for the 21st century, The MIT
Press (2009).
Levtov, Y.: Algorithmic Music for Mass Consumption
and Universal Production, The Oxford Handbook of Al-© 2024 Information Processing Society of Japan

[16]

[17]

gorithmic Music (McLean, A. and Dean, R. T., eds.),
Oxford University Press, chapter 34, pp. 627–644, DOI:
10.1093/oxfordhb/9780190226992.013.15 (2018).
Kato, J. and Goto, M.: Lyric App Framework:
A Web-Based Framework for Developing Interactive
Lyric-Driven Musical Applications, Proceedings of the2023 CHI Conference on Human Factors in Computing Systems, CHI ’23, pp. 124:1–124:18, DOI:
10.1145/3544548.3580931 (2023).
加藤 淳，中野倫靖，後藤真孝： TextAlive: インタラク
ティブでプログラマブルな Kinetic Typography 制作環境，第 22 回インタラクティブシステムとソフトウェアに関するワークショップ，WISS ’14, pp. 39–44 (2014).
Frich, J., Mose Biskjaer, M. and Dalsgaard, P.:
Twenty Years of Creativity Research in HumanComputer Interaction: Current State and Future Directions, Proceedings of the 2018 Designing Interactive Systems Conference, DIS ’18, pp. 1235–1257, DOI:
10.1145/3196709.3196732 (2018).
Fujihara, H., Goto, M., Ogata, J. and Okuno, H. G.:
LyricSynchronizer: Automatic Synchronization System
Between Musical Audio Signals and Lyrics, IEEE Journal of Selected Topics in Signal Processing, Vol. 5, No. 6,
pp. 1252–1261, DOI: 10.1109/jstsp.2011.2159577 (2011).
株式会社シンクパワー： 歌詞データ関連事業「01. 同期歌
詞（プチリリ機能）」，https://syncpower.jp (2023).
Musixmatch s.p.a: Musixmatch Developer API, https://developer.musixmatch.com/ (2022).
LyricFind Inc.:
Products — Lyric Display ―LyricFind，https://www.lyricfind.com/products/
lyric-display (2023).
Reas, C. and Fry, B.: Processing: A Programming
Handbook for Visual Designers and Artists, Second
Edition, The MIT Press (2014).
Kato, J., Ogata, M., Inoue, T. and Goto, M.: Songle
Sync: A Large-Scale Web-Based Platform for Controlling Various Devices in Synchronization with Music,
Proceedings of the 26th ACM International Conference on Multimedia, MM ’18, pp. 1697–1705, DOI:
10.1145/3240508.3240619 (2018).
Goto, M., Yoshii, K. and Nakano, T.: Songle Widget: Making Animation and Physical Devices Synchronized with Music Videos on the Web, 2015 IEEE International Symposium on Multimedia (ISM), pp. 85–88,
DOI: 10.1109/ISM.2015.64 (2015).
Goto, M., Yoshii, K., Fujihara, H., Mauch, M. andNakano, T.: Songle: A Web Service for Active Music
Listening Improved by User Contributions, Proceedingsof the 12th International Society for Music Information
Retrieval Conference, ISMIR ’11, pp. 311–316 (2011).
後藤真孝，吉井和佳，藤原弘将，Mauch, M.，中野倫
靖： Songle: 音楽音響信号理解技術とユーザによる誤り訂正に基づく能動的音楽鑑賞サービス，情処学論， Vol. 54,
No. 4, pp. 1363–1372 (2013).
Goto, M. and Dannenberg, R. B.: Music Interfaces
Based on Automatic Music Signal Analysis: New Ways
to Create and Listen to Music, IEEE Signal Processing Magazine, Vol. 36, No. 1, pp. 74–81, DOI:
10.1109/MSP.2018.2874360 (2019).
Kato, J. and Shimakage, K.: Rethinking Programming”Environment”: Technical and Social Environment Design toward Convivial Computing, Conference Companion of the 4th International Conference on Art, Science, and Engineering of Programming, Programming’20, pp. 149–157, DOI: 10.1145/3397537.3397544 (2020).

10