情報処理学会研究報告
IPSJ SIG Technical Report

TextAlive App API: 「リリックアプリ」の提案とプログラミング・コンテストでの実証実験
加藤 淳1,a)

後藤 真孝1,b)

概要：音楽に合わせてタイミングよく歌詞が動くリリックビデオは楽曲のプロモーション手段として一般化したが，いつ再生されても同じ内容を提示するため，視聴者は受動的に楽しむしかない．そこで我々は，ユーザとのインタラクションにより歌詞のテキストを再生のたびに異なる方法で提示でき，静的メディアの制約を取り払える歌詞駆動型のインタラクティブな視覚表現を「リリックアプリ」と定義する．そして，
この表現形式をプログラマやミュージシャンに開放するため，リリックアプリを開発・配信できる Web
ベースのフレームワーク「Lyric App Framework」を提案する．当該フレームワークは，我々が研究・開発・運営してきたリリックビデオ制作支援サービス「TextAlive」の Web インタフェースと，歌詞駆動の表現を開発できる機能をプログラマ向けに開放する「TextAlive App API」で構成される．当 API は，既存の，プログラマが使い慣れたクリエイティブコーディングのためのライブラリと相補的な役割を果たし，
インタラクティブなリリックアプリをすぐに開発可能である．我々は，2020 年に当 API を一般公開し，新たな表現形式の可能性を探ってきた．とくに，創作文化に関するイベント「マジカルミライ」ではプログラミング・コンテストが毎年開催され，最初の 2 回で 52 作品が集まった．これらの作品を分析して得られたリリックアプリのカテゴリ 8 種類と，音楽とプログラミングの未来に関する示唆を報告する．

1. はじめに
歌詞には，楽曲単体よりも感情表現を伝えやすくする力

験を共有するようになった (参加型文化 [4])．また，スマー
トフォンの普及により，多くの人々が楽曲との斬新なイン
タラクションを体験できるようになってきた [5]．

があり [1]，メディア技術の進歩とともに多様な方法で聴衆

こうした社会・文化・技術的背景を踏まえ，我々は本稿に届けられてきた．例えば，レコードやコンパクトディス

において，歌詞カードやリリックビデオに続く歌詞駆動メク (CD) には，グラフィックデザイナが歌詞を魅力的にデディアとして，楽曲と歌詞を目と耳でインタラクティブにザインした歌詞カードがついてきた．また，音楽動画や動楽しめる「リリックアプリ (lyric app)」(図 1) を定義する．

画共有サービスが一般化してからは，楽曲再生に合わせて

例えば，リリックアプリを起動したユーザは，楽曲を聴き歌詞が魅力的に動く「リリックビデオ (lyric video)」が人ながら，三次元コンピュータグラフィックス (3D CG) で気を博すようになった．リリックビデオにおいて文字が時動的に生成された情景を見ることができる．歌詞のフレー

系列で変形する表現形式は「キネティックタイポグラフィ

ズを表す視覚的オブジェクトが発声タイミングに合わせて(kinetic typography)」と呼ばれ，多くの場合，モーション登場するが，静的なリリックビデオとは異なり，ユーザはグラフィックデザイナが動きを手付けしているが，著者ら情景のなかを自由に動き回り，フレーズに触れることがでは，音楽理解技術を活用してその制作を省力化し，支援すきる．このように，ユーザは歌詞を読むだけでなく，歌詞るサービス「TextAlive」 [2] を研究，開発，運営してきた．

とインタラクションすることで，楽曲を再生するたびに一そして今や，ミュージシャンは多様なメディアを横断して度きりの情景を作り上げることが可能となる．リリックビ

聴衆に楽曲を届けるようになり (メディアコンバージェン

デオという静的メディアと比較すれば，リリックアプリにス [3])，聴衆は楽曲を聴くだけでなく，ソーシャルネット

は，インタラクションデザイン上，工夫の余地がはるかにワーキングサービス (SNS) への投稿などを通して自らの体多く存在する．

1a)b)

産業技術総合研究所
National Institute of Advanced Industrial Science and Technology (AIST)
jun.kato@aist.go.jp
m.goto@aist.go.jp

c 2023 Information Processing Society of Japan⃝

一方で，リリックアプリの開発においては，リリックビ
デオの制作とは異なる課題に取り組む必要がある．まず，楽曲再生に合わせて歌詞や視覚的表現を表示するためには，事前準備として歌詞やビート構造などの音楽的要素の1

情報処理学会研究報告
IPSJ SIG Technical Report
リリック
アプリ :

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

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 種類のカテゴリが明らかになった ( 6)

動画共有サービス

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

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

図 1: 「リリックアプリ」は，ユーザが歌詞駆動の視覚表現とインタラクションできるようにすることで，リリックビデオの限界を突破する新たな表現形式である．本稿で提案する「Lyric App Framework」はプログラマとミュージシャンによるリリックアプリ開発を支援する．
タイミング情報を手作業でラベル付け (アノテーション) しの一貫した開発体験を提供したこと．

ておかなければならない．また，音楽的要素に同期して見( 3 ) フレームワークを一般公開し，創作文化に関するイベ

える時間制約が厳しいインタラクションデザインは容易でント「マジカルミライ」でプログラミング・コンテス

はない．さらに，開発したリリックアプリをユーザに届け

トを 2020 年から毎年開催し，最初の 2 年で集まったる方法も自明ではない．

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

そこで我々は，リリックアプリの開発を支援し，この新テゴリを明らかにし，フレームワークの有効性を評価

たな表現形式の可能性を探るため，プロダクションレディ

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

(production-ready) なリリックアプリを構築するための一貫した開発体験を提供する Web ベースのフレームワーク

2. リリックアプリ「Lyric App Framework」 [6] を提案する．なお，ここでプ

本章では，我々が研究・開発・運営してきたリリックビ

ロダクションレディとは，プロトタイプ開発だけでなく一デオの制作支援サービス「TextAlive」を紹介し，インタラ

般ユーザによる利用にも耐える高い信頼性でのアプリの配クティブな表現形式「リリックアプリ」を着想した経緯を信までサポートすることを指す．具体的には，このフレー説明する．さらに，リリックアプリの典型的なインタラク*1 の
ムワークは，筆者らによる Web サービス「TextAlive」

ションデザインを具体例とともに紹介し，リリックアプリ

機能を活用することで，楽曲と対応する歌詞テキストを開発に際してプログラマが直面する課題を明らかにする．

入力として受け取ると，音楽理解技術により，歌詞タイミ
ングなどの音楽的要素の情報を自動的に推定する．そし2.1 リリックビデオからリリックアプリへて，楽曲の再生を制御し，楽曲中の特定のタイミングの2015 年に，我々は ACM CHI 2015 [2] (WISS 2014 [7])

音楽的要素の情報へアクセスするために新たに設計したで提案したインタラクションデザインをもとに，リリッ

API「TextAlive App API」*2 を提供する．こうして開発しクビデオを Web ブラウザ上で制作できる支援サービス

たリリックアプリは，スマートフォンやパソコン (PC) の「TextAlive」を開発して一般公開した*4 ．TextAlive は，単Web ブラウザで実行できる Web 標準に則った Web サイ

なる動画制作支援サービスではなく，歌詞の文字列をアニトとして配信できる．筆者らは，このフレームワークをメーションさせたり，グラフィックを描画したりするため「TextAlive for Developers」*3 という Web サイトで一般公の視覚的アルゴリズムをプログラマが開発できる機能を備

開済みである．

えた統合デザイン環境である．2023 年 2 月 6 日の時点で本研究の貢献は以下の 3 点である．

視覚的アルゴリズムが 1396 バージョン保存されており，( 1 ) リリックビデオを拡張して，楽曲と歌詞に関するイン

18,867 件の動画データが保存されている．プロ・アマチュ

タラクションを可能にする仕組みを加え，新たな表現

アを問わず，多くのミュージシャンが音楽作品のプロモー形式「リリックアプリ」を定義したこと．

ション用のリリックビデオ制作に活用する Web サービス( 2 ) Web ベースのワークフローと API (TextAlive Appとなっている．

API) を提供する新たなフレームワークを実装し，プ

ただし，ミュージシャンには有用であっても，プログラ

ロダクションレディなリリックアプリを構築するためマの観点では，TextAlive は創造性を充分に活かせない課
題が 2 つあることが分かってきた．まず，プログラマは

*1
*2
*3

https://textalive.jp
https://github.com/TextAliveJp/textalive-app-api
https://developer.textalive.jp

c 2023 Information Processing Society of Japan⃝*4

https://www.aist.go.jp/aist_j/press_release/pr2015/
pr20150908/pr20150908.html

2

情報処理学会研究報告
IPSJ SIG Technical Report

TextAlive のライブプログラミングなどの先進的な機能をなったように感じられる．さらに，リリックアプリの活用できる一方で，それ以外のプログラミング環境を使う中で，そのミュージシャンの別の曲を開くこともでき

自由がなかった．すなわち，自身が使い慣れた開発環境やる．アリスは，こうしたインタラクションを通して楽

クリエイティブコーディング用のライブラリを利用するこ

曲の世界観により深く浸り，個人的かつ唯一無二な体とができなかった．次に，プログラマは，ユーザがアルゴ

験を得られる．

リズムをカスタマイズするためのパラメタ (色や数値などの決められた型の変数) を定義することはできても，それ以2.3 リリックアプリ開発の課題と支援の必要性

上のインタラクティブな機能を実装することはできなかっ上記の筋書きを踏まえ，リリックビデオ制作とアプリ開た．リリックビデオという静的な表現形式が，プログラマ

発を比較することで，本節ではリリックアプリを開発するの足枷になってしまっていた．

際にプログラマが直面する 3 つの課題と，それぞれに望ま

これらの経験から，我々は，リリックビデオにインタラ

れる開発ツールによる支援について考察する．

クティブな機能を追加できる「リリックアプリ」という表

まず，リリックビデオとリリックアプリを含む歌詞駆動

現形式を着想した．我々は，プログラマに特定のプログラ

型の視覚表現は，楽曲再生と同期している必要がある．そミング環境の利用を強いるのではなく，好みの開発ツール

うした同期を実現するためには，通例，歌詞を含む音楽や環境を利用しながら「リリックアプリ」を開発できるフ的要素のタイミング情報を手作業でラベル付け (アノテーレームワークを提供する．また，ミュージシャンがリリッション) しなければならない．我々はリリックビデオの制

クアプリをカスタマイズして自身の楽曲を宣伝できるよう作支援に関する先行研究 [2, 7] において，音楽理解技術ににする．聴衆は，リリックアプリを通して楽曲を聴き，歌よる自動解析と，解析結果を修正するためのユーザインタ

詞を読み，歌詞とインタラクションできるようになる．

フェースを提案した．こうした半自動的な処理はリリック
アプリ開発においても有用だと思われるが，アプリの開発

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

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

前節では主にクリエータ (プログラマとミュージシャン

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

両者) の視点でリリックアプリがメリットのある表現形式

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

であることを紹介した．本節では，ユーザの視点で，リリッ

楽曲が一意に決まっており，時間軸に沿った場面展開も最クアプリによるインタラクティブなユーザ体験のイメージ

終的には一案に収束するため，モーショングラフィックデ

を，下記の「アリスが (架空の) リリックアプリを楽しんで

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

いる」という筋書きで例示する．

方，リリックアプリ開発では，プログラマは，何度実行さある日の午後，アリスはお気に入りのミュージシャ
ンの新しい SNS 投稿を見つける．投稿内のリンクを辿ると Web ブラウザがリリックアプリを起動し，新しくリリースされた楽曲が流れ始める．楽曲のジャケッ
ト画像とタイトルが 3D CG 空間内に浮かび上がる．
静的なリリックビデオとは異なり，アリスは画面をタッチして空間内を自由に動き回り，楽曲のテーマに合ったさまざまな視覚的オブジェクトを見つけることができる．そうしたオブジェクトはビートと同期してアニメーションしており，目を楽しませてくれる．歌
詞が発声するタイミングでは，歌詞のフレーズが視界に飛び込んでくる．そして，それを読むだけでなく，タッチ操作でつかんで好きなところに置いておくことができ，一度きりの情景を作りあげることができる．
サビではアニメーションの効果が派手になり，気持ちを盛り上げてくれる．
夕方，アリスがふたたびリリックアプリを開くと，同じ 3D CG 空間が夕闇のような暗い色で表示される．
歌詞のフレーズも昼間とは違った配置になり，楽曲とれても飽きないような視覚効果を生成するアルゴリズムを思いつく必要がある．クリエイティブコーディングのためのライブラリ (3.3 節) の助けを借りることはできるが，リリックアプリ特有の課題，すなわち，さまざまな音楽的要
素のタイミングや，歌詞の意味，そしてユーザ入力を考慮に入れる難しさは残る．したがって，クリエイティブコー
ディングの実践を邪魔しないようなツール支援が極めて重要である．
最後に，リリックアプリをユーザに届ける手段が明らかでない．創造性支援ツールの研究はラボスタディが中心で実用性の面で批判されることも多い [8]．しかし我々は，リリックアプリという新たな表現手段を提案するうえで，ラボ内に留まらず，プロダクションレディなアプリを開発できるような工学的視点を持つことが重要であると考えている．ミュージシャンが動画共有サービスを使ってリリック
ビデオを多数の視聴者へ配信できることと同様に，プログ
ラマやミュージシャンがリリックアプリをユーザに届けられるようにすることまで考慮するべきである．

3. 関連研究

歌詞を新鮮に楽しむことができ，楽曲をもっと好きに
本章では，関連研究を紹介して本研究の貢献を明確にす

c 2023 Information Processing Society of Japan⃝3

情報処理学会研究報告
IPSJ SIG Technical Report

る．まず，リリックアプリに関連する先行事例を紹介する．

歌声を含む楽曲 (混合音) と歌詞の自動対応付けは，一そして，マルチメディアにおける複数トラックの自動同期

般に，講演などの音声と書き起こしの対応付けと比較して技術と，マルチメディアコンテンツを生成したりインタラ

技術的に困難である．これは，混合音から歌声を分離する

クション可能にしたりするためのプログラミング支援技術ことが難しく，歌声が多様なためである．LyricSynchro-を紹介する．

nizer [14] は，新たな信号処理技術を適用することで自動対応付けを行い，歌詞テキストをクリックすることで楽曲の3.1 リリックアプリに関連する先行事例

再生位置を操作できるユーザインタフェースを提供した．

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

TextAlive [2] は，さらにタイミングよく文字がアニメー体験が実現できる．カラオケは，歌詞のシンプルな字幕表

ションする Kinetic Typography という表現手法を活用し示を見ながら，歌詞を正確に覚えていなくても歌を歌ったリリックビデオを制作できるようにした．また，アニメーて，楽曲を楽しめる娯楽である．機器と楽曲によっては，ションに用いられるアルゴリズムをライブプログラミン

リリックビデオを再生することで没入感を高める工夫がな

グできるようにした．SyncPower [15]，Musixmatch [16]，されていることもある．リズムゲーム [9, 10] や，タイピン

そして LyricFind [17] は，歌詞テキストを取得するためのグや外国語を練習する音楽ゲーム [11] では，楽曲再生と同

API と，取得したテキストをカラオケのように表示するた

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

めのプチリリ機能，FloatingLyrics，そして Lyric Display

こうしたアプリケーションは，歌詞やビートなどの音楽と呼ばれる視覚的コンポーネントを提供している．本研究的要素のタイミング情報を利用しており，リリックアプリ

は，ベース手法としている TextAlive を除き，これらの先に関連する先行事例と捉えることができる．しかし，これ

行事例と 2 つの点で異なる．まず，先行事例では既存の楽らは，インタラクションデザインの観点では比較的狭い応

曲の情報を取得することしかできないが，本フレームワー

用範囲に留まっている．カラオケはインタラクティビティ

クでは，ユーザは新たな楽曲と対応する歌詞テキストを自がほとんどなく，ゲームはゲームプレイ自体の楽しさや由に登録できる．次に，既存の商用 API では，歌詞テキス

ゲーミフィケーションによる学習効果の向上に主眼が置かトを取得できても，タイミング情報に直接アクセスできなれている．我々は，リリックアプリにはこれらの先行事例

い．一方，本研究が提供する TextAlive App API では，歌を超えたポテンシャルがあると考えており，デザイン空間

詞のテキストや，歌詞を含むさまざまな音楽的要素のタイを 6 章で示すように探索するため，リリックアプリ開発を

ミング情報へ直接かつ統一的な方法でアクセスできる．こ支援するフレームワークを構築した．

の 2 点の新規性は，プログラマが好きな楽曲のリリックア
プリを開発できるようにする鍵となる．

3.2 自動同期技術

音と映像が同期したメディアコンテンツを自動的に生歌詞や音楽的要素と同期して感じられる体験は，リリッ

成するための技術やフレームワークも，研究されてきた．

クアプリに欠かせないものである．このように時系列に並MusicStory [18] は，楽曲を指定すると，その歌詞をインぶマルチメディアのコンテンツを自動的に同期したり生成

ターネット上で取得し，関連する画像を指定されたデータ

したりといった例は，過去にもある．

セットから探し出し，楽曲のテンポにあった間隔で表示す

音声付き動画を自動的に書き起こし，得られたタイミン

る動画を自動生成した．Crosscast [19] は，旅行に関するグ情報付きテキスト，音声，そして動画を統一的に扱える

ポッドキャストを与えると，その内容を自動的に書き起こようにするインタラクション技術は，長く研究されてき

し，関連する画像を自然言語処理とテキストマイニングをた．PodCastle [12] は自動音声認識をポッドキャストに適活用しながら探し出して動画を生成した．最近の例では，

用し，クラウドソーシングによるユーザ編集で精度を向上

楽曲を与えると，その内容に合ったカメラワークのシーケ

し，書き起こし内の全文検索機能を提供した．一方，本研

ンスを生成する研究 [20] があり，コンサートを多点撮影

究は，クラウドソーシングで精度を向上する同様の手法をした動画からマッシュアップを自動生成するような目的で採用し，さらにユーザによる編集結果のリビジョン管理を活用できる．本研究は，これらの手法と併用でき，静的な可能にしている．Video Digests [13] は，動画コンテンツ

コンテンツでは不可能なユーザとコンテンツのインタラクを要約するためのデータ構造を定義し，音声の書き起こし

ションを切り拓くものである．

に対するインタラクションによって要約結果を編集できる
ユーザインタフェースを提供した．本研究は同様にタイミ

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

ング情報付きのデータ構造を扱うが，一般的な音声でなくマルチメディアコンテンツを生成したりインタラクショ

歌声を対象としている．さらに，歌詞を含む音楽的要素をン可能にしたりするためのプログラミングを支援するツー

活用し，インタラクティブな表現形式を新たに提案するもルは数多く存在する．そうしたツールを用い，芸術的な目のである．

的で創造的にプログラミングすることは，しばしば「クc 2023 Information Processing Society of Japan⃝4

情報処理学会研究報告
IPSJ SIG Technical Report

リエイティブコーディング (creative coding)」と呼ばれな音楽を制作，開発してマス向けに配信する手段を実装しる．同様の活動は，応用領域や文脈によって「ジェネラたツールとして最初の試みの一つである．最近の例では

ティブアート (generative art) [21]」「アルゴリズミック

variPlay [33] があり，これはアルゴリズミックミュージッ

ミュージック (algorithmic music) [22]」「ジェネラティブ

クではなく，事前に録音された複数トラックの楽曲をカスデザイン (generative design)」「プロシージャルモデリン

タマイズして再生できるものである．これらの先行事例とグ (procedural modeling)」などの別名で呼ばれる．

異なり，本研究では楽曲そのものの音を編集することを目Processing [23] と openFrameworks [24] は著名なクリエ

的としていない．その代わり，既存の楽曲に対してインタ

イティブコーディングツールであり，インタラクティブなラクションする機能を追加することで，新しい歌詞駆動のアプリケーションをプロトタイピングするためによく使

芸術的体験を創り出せるようにする．

われる．また，美しい画像や動画，インタラクティブなグ

なお，我々が研究開発して公開中の Web ベースの大規

ラフィックを描画するためにも使われる．クリエイティブ

模音楽連動制御プラットフォーム「Songle Sync」 [34]*5 でコーディング用のライブラリには p5.js のように Web アプ

は，楽曲再生に合わせて多種多様な機器でのマルチメディ

リケーションを構築できるものもある．こうしたライブラ

ア演出を同時制御できる．我々は，Songle Sync およびそリは，Web ブラウザを備えた，スマートフォンをはじめとの先行研究である Songle Widget [35]*6 において，音楽的する端末で実行できるアプリケーションを容易に開発でき要素と連動する演出を手軽にプログラミングできるイベン

るため，人気を博している．こうしたライブラリはリリッ

ト駆動型の API を提供した．ただし，利用可能な音楽的クアプリの視覚表現を実装する助けになるが，プログラマ

要素はビート構造，楽曲構造 (サビ区間，繰り返し区間)，によって好みが分かれる．そこで本研究では，プログラマ

コード進行などであり，歌詞関連の情報は利用できない．

が好みのクリエイティブコーディング用ライブラリを選べ

また，後述 (4.2.2 節) のとおり，イベント駆動型の API にるように，フレームワークを設計している．

は高度な演出を開発しづらく，時間精度が落ちやすい問題

これまで研究者たちは，Web を使って新たな創造的表現
形式を実現してきた．D3.js [25] はデータ可視化のために開発され，Idyll [26] などの後続研究はユーザがインタラク
ション可能な Web 上の記事を構築するワークフローを探がある．本研究は，これらの技術的な制約を解消する APIを新たに提案するものである．

4. Lyric App Framework

求してきた．Webstrates [27] は，共有可能な動的メディア

2.3 節で整理したとおり，プログラマはリリックアプリ

を Web 上に実現し，同時に協力してデータを編集したり，開発において 3 つの課題に直面する．本章では，これらをインタラクションをプログラミングしたりできるようにし解決する Lyric App Framework を提案する．本フレーム

た．Videostrates [28] と Codestrates [29] は，Webstrates

ワークは，各課題を解決する 3 つの主要機能で構成され，をベース手法としながら，それぞれ動画編集や文芸的プロ一貫した開発体験をプログラマに提供する (図 1)．

グラミングに特化したインタラクションデザインを提案した．本研究はこれらの先行研究と同様に，Web を使った

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

創造的な表現の可能性を切り拓くものであり，とくに，リまず，楽曲中の音楽的要素と同期した演出開発を容易に

リックアプリという新たな表現形式のデザイン空間を明らするため，Web ベースのワークフローを提案する．このかにするために，フレームワークを一般公開してきた．

ワークフローでは，開発中いつでも新たな楽曲を扱えるよ

楽曲を活用したインタラクティブなアプリケーション

うにしたり楽曲を差し替えたりでき，プログラマやミューに関しては，これまでにも商業楽曲作品がスマートフォ

ジシャンのニーズに柔軟に対応できる特長がある．

ンアプリとしてリリースされたことがある．Björk の Bio-

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

philia [30] というアルバムは曲ごとにアプリ化され，ユー本研究で提案するフレームワークは，我々が研究開発しザがタッチ操作で音や映像を動的に編集できるものがあってきた能動的音楽鑑賞サービス「Songle」 [36, 37]*7 の機

た．Brian Eno の Reﬂection [31] は，起動するたび異なる能を拡張することで実現しており，楽曲と歌詞テキストのバージョンの曲が流れるため，誰もが自分自身の Reﬂection

自動対応付けを行い，楽曲の内容を自動解析してリリックを楽しめる (他の事例は Levtov の「大量消費を可能にすアプリ開発に役立つ情報 (表 1) を提供する．さらに，必要るアルゴリズミックミュージック」の記事 [5] を参照のこに応じて情報の誤りを修正できる．

と)．しかしながら，こうした作品はプログラマが一般的なプログラマやミュージシャンのワークフローは以下のとプログラミング用のツールを用いて開発している．対照的おりである．まず，フレームワークの Web インタフェースに，RjDj [32] は，スマートフォン上で Pure Data によって制作されたアルゴリズミックミュージックを演奏・編集できるようにしたもので，プログラマがインタラクティブ

c 2023 Information Processing Society of Japan
⃝

*5
*6
*7

https://api.songle.jp/sync
https://widget.songle.jp
https://songle.jp

5情報処理学会研究報告
IPSJ SIG Technical Report

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

説明

歌詞タイミング

歌詞テキストの各フレーズ，単語，文字が発声を開始し，終了するタイミング情報組を登録するタイミングはいつでもよく，柔軟な開発ワー
クフローが可能となっている．例えば，暫定的に既存の楽曲 URL を用いて開発を始めたリリックアプリにおいて，
後に新しく楽曲が登録された場合，ソースコード中の楽曲

URL を書き換えるだけで，リリックアプリが新しい楽曲で品詞

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

声量

歌声の音量の時系列変化

スの楽曲について，他の人がアクセスできないプライベー

音楽印象

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

ト楽曲の URL を用いてリリックアプリの動作を確認でき

arousal) 平面上の座標値の時系列変化

る．リリース時には，楽曲 URL を一般公開されたものに

四分音符に相当する各ビートや，各小節の先頭差し替えてリリックアプリを配信し，楽曲のプロモーショのタイミング情報ンに役立てることができる．

ビート構造

コード進行

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

楽曲構造

サビ区間や，楽曲中の繰り返し区間のタイミン
グ情報

動作するようになる．また，ミュージシャンは，未リリー

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

を通してリリックアプリで利用したい楽曲と歌詞テキスト

API*2 を提案する．本 API は楽曲再生の状態を管理できるの組を登録する．楽曲と歌詞テキストは新規にアップロー

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

ドすることもできるし，すでに Web 上にあって二次利用にを表示できる時刻駆動型の API に大別される．

関する適切なライセンスが付与されているものなら URL

4.2.1 状態管理用のイベント駆動型 APIを指定するだけでもよい．登録から約 10 分後には，自動リリックビデオは常に単一の課題曲と紐づいているが，解析の結果がフレームワークの Web サーバ上で利用可能

リリックアプリは単一の楽曲向けのこともあれば，特定のになり，リリックアプリ上で読み込めるようになる．

楽曲セットで実行できたり（例: ユーザがプレイする曲目を

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

選べるリズムゲーム），任意の楽曲で実行できたり（例: イ

ング情報を Web インタフェースで確認し，必要に応じてンタラクティブなビジュアライザのついた音楽プレイヤー）修正できる．こうしたクラウドソーシングによる自動解析する．さらに，リリックアプリは，特定の操作をユーザに結果の修正はすでに Songle 上で可能であったが，我々は許可したり禁止したりできる．例えば，音楽プレイヤーは本研究や TextAlive の研究で，歌詞タイミングの修正も可

楽曲再生を一時停止したり，任意の再生位置にシークした能にしたほか，歌詞単語の品詞の自動検出や，タイミング

りできるが，ゲームはどちらの操作も禁止していることが情報のリビジョン管理まで可能な拡張を施した．

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

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

本フレームワークでは，楽曲の URL が歌詞テキストとこれらすべてのインタラクションシナリオの実装を支援

解析結果を取得するためのキーとなる．すなわち，リリッ

するために，我々はリリックアプリが取りうる状態の一覧

クアプリで利用する楽曲はそれぞれ固有の URL を持ってを図 2のように整理して定義した．TextAlive App API でいるという前提に立っている．プログラマは，楽曲 URL

は，これらの状態間の遷移を通知するイベント駆動の APIのリストを保持することでユーザに楽曲を選ばせることがを実装している．具体的には，API の JavaScript クラス

でき，単一のリリックアプリで複数の楽曲を開くことが可

Player が，Lyric App Framework の機能を利用する際の能となる．楽曲 URL だけを指定した場合，解析結果 (あエントリーポイントとなっている．

るいはユーザによる修正結果) の最新版が読み込まれるが，リリックアプリの起動後，フレームワークのサーバ

さらに数値型のリビジョン番号を指定することで，特定のに接続できると， onAppReady イベントが発行される．

版のデータを取得できる．これにより，クラウドソーシン

もし単一の楽曲向けのリリックアプリを開発したけれ

グで仮に悪意ある修正が行われた場合にも影響を受けずに済み，リリックアプリの動作の再現性を向上できる．このように，コンテンツの URL をキーとして用い，さらにオ
プションで解析結果のリビジョン番号を指定できるようにする手法は，シンプルながら強力である．本フレームワー

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

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

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

on{SongMap, Lyrics, ...}Load

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

onTimerReady

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

クに限らず，静的メディアにインタラクションを追加する
今後の研究でも有用であろう．
さらに，本フレームワークでは，楽曲と歌詞テキストのc 2023 Information Processing Society of Japan⃝

図 2: 本フレームワークは，リリックアプリの複雑な状態遷移を管理するためのイベント駆動型 API を提供する．

6

情報処理学会研究報告
IPSJ SIG Technical Report

ば，プログラマはこのイベントのコールバック関数内でベントについてリスナを定義し，情報をどこか別のロジッ

player.createFromSongUrl(songUrl) という API を呼び出クで集約してアニメーションさせる必要が生じて不便であして楽曲を明示的に読み込めばよい．ここで読み込みがる．最後に，イベント駆動型 API では時間精度が低くなり行われなかった場合，リリックアプリは，Lyric App Cus-

がちである．こうした API を提供するためには，フレーム

tomizer と呼ばれる Web インタフェースで読み込むべきワーク内にイベントループを設け，現在の再生位置と各種楽曲が別途指定されていないか確認する．本 Web インタ

イベントの時刻情報を比較し続けるという実装が典型的でフェースを使うことで，プログラマやミュージシャンは，ある．この場合，各種イベントは最悪値でイベントループ

開発とデプロイが終わったリリックアプリの振る舞いを事の実行間隔分，遅れて発行される可能性がある*8 ．このよ

後的にカスタマイズできるようになっている (4.3.2 節で詳

うに時間精度を保証できない API は，求める表現を得るう

述)．Customizer でも読み込むべき楽曲が指定されていなえで不充分なことがあり，時間精度が意図せずに低くなっかった場合，リリックアプリは待ち受け状態に入り，プロた場合に初学者が混乱する可能性もある．

グラマは任意のタイミングで先述の API を呼び出して楽曲

これらの課題を解決する (すなわち，未来に向けた準備のを読み込める．こうして，ユーザに楽曲リストを提示してロジックを容易に設計でき，複数の音楽的要素の情報を考慮

一曲を選んでもらうようなインタラクションが実現する．

に入れやすく，高い時間精度を実現できるようにする) ため

API を複数回呼んだ場合，最後に指定された楽曲が読み込に，我々は，引数にミリ秒単位の再生位置の数値を取り，そのまれる．これにより，複数の楽曲を切り替えて再生するリ引数で指定された時点での音楽的要素を開始・終了などの時

リックアプリが実装できる．

刻情報付きで返す「時刻駆動型 (time-driven) API」を提案す

楽曲の読み込みが終わると，楽曲の再生状態を制御できる．例えば，5 秒後に発声が始まる歌詞フレーズの情報を取るようになる．ユーザが再生を一時停止したり再生位置を得するには player.getPhrase(player.position + 5000) とシークしたりできるようにするか否かはプログラマに任いう API を呼び出せばよい．さらに，同じ引数で getBeat

されており，インタラクションシナリオに応じて自由にという API を呼ぶなどすれば，フレーズ，ビート，サビ区

決められる．楽曲の再生状態が変化した場合には，さまざ間の情報をすべて考慮に入れた視覚表現を実装できる．イ

まなイベントが発行される．例えば， onPlay ， onPause ，ベント駆動型と時刻駆動型 API の図入りの詳しい説明は，

onSeek ， onTimeUpdate などがある．

別途，付録 A.1に示した．
時刻駆動型 API は，インタラクティブな視覚表現を生

4.2.2 時間精度を要するインタラクションデザイン用の時刻駆動型 (time-driven) API

成する際に役に立つ，GUI やクリエイティブコーディング

グラフィカルユーザインタフェース (Graphical User In-

用のライブラリと相補的な役割を果たす．こうしたライブ

terface; GUI) 用のフレームワークや，我々が研究開発しラリでは，通常，描画すべき内容を定義するレンダリングた音楽連動制御のためのプラットフォーム「Songle Sync」

用の関数をプログラマが定義するようになっている．例え[34] では，イベント駆動型の API によって，時系列に発生

ば，Web API における requestAnimationFrame() ，React

するイベントに応じたインタラクション設計が行えるよう

における Components.render() ，p5.js における loop() ，になっている．しかし我々は，リリックアプリ用の API を

Three.js における renderer.render() などが挙げられる．

設計するにあたり，次に述べる 3 つの理由から，音楽的要プログラマは，これらの関数内で時刻駆動型 API を呼ぶこ

素のイベントをサポートしないことに決めた．

とで，複合的な音楽的要素を考慮した視覚表現を設計でき

まず，イベント駆動型の API において，イベントは通る．描画内容は，常に楽曲再生の最新の状態を反映してい常何かが起きた直後にのみ発行されるため，未来のイベンることが保証される．このように，本 API はプログラマがトに向けた準備をコーディングする目的には向いていな

好みの使い慣れたライブラリと併用できる特長がある．

い．例えば，歌詞の単語の発声開始イベントを使って，発声よりも充分前に画面内に滑り込み始めるような予備動作

4.3 リリックアプリの大規模配信を伴うアニメーションの設計には使えない．次に，イベン

最後に，ユーザにリリックアプリを届ける方法が自明でトは個々の音楽的要素に紐づいて提供されるが，魅力的なない課題に関して，本フレームワークは，プログラマや視覚表現は往々にして複数の音楽的要素と連動しているもミュージシャンがリリックアプリを Web サイトとして安のである．例えば，歌詞のフレーズが発声するタイミング

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

でその周囲に現れる水紋のような視覚表現を考える．水紋はビートに合わせてフェードインとフェードアウトを繰り返すかもしれないし，サビの歌詞かどうかによって色を変えたくなるかもしれない．イベント駆動型 API では，フレーズの発声開始，ビート，サビ区間といったすべてのイ

c 2023 Information Processing Society of Japan⃝*8

理論的な限界に加え，現在の Web ブラウザの実装では，CPU が過負荷になった場合，ブラウザのタブが非アクティブになった場
合，低バッテリーで省電力モードになった場合など，さまざまな要因によってプログラムの実行タイミングが影響を受けるという実用上の限界もある．

7

情報処理学会研究報告
IPSJ SIG Technical Report3

1

Lyric App Customizer

リックアプリの挙動をカスタマイズできるよう，TextAlive

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

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

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

えている (図 3)．Customizer のページでリリックアプリの

Web サイトの URL を指定すると，ページ内の <iframe>
リリックアプリを実行するための <iframe>

コンポーネント内でアプリが起動し，フレーム間通信の仕組みを通してアプリが制御される．例えば，4.2.1 節で紹

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

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

図 3: 本フレームワークを用いれば，リリックアプリを Webサイトとして大規模配信できるだけでなく，事後的にアプリをカスタマイズして新しい楽曲に対応させたりできる．

介した音楽プレイヤーのように，楽曲を自由に指定できる
リリックアプリの場合，ミュージシャン側で楽曲の URL
をカスタマイズできる．カスタマイズ結果は，最終的にはリリックアプリの URL に与えるクエリパラメータとして，?ta_song_url=NewUrl のように永続化できる．

また，楽曲 URL の他にも，プログラマは自由にカスタ
マイズ用パラメタのリストを定義することができる．例え

4.3.1 プロダクションレディなアプリ配信

ば，現在の実装では，数値や色，文字列 (自由入力または一般に，インタラクティブなメディアコンテンツの配信

選択式) といったパラメタがサポートされている．定義さは 2 つの観点で難しい．まず，ユーザを取り巻く情報環境

れたパラメタの一覧は，プログラマやミュージシャンがイ

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

ンタラクティブに調整できるように，Customizer 上でス

しめるような相互運用性を担保する必要がある．そして，ライダーやカラーパレットなどの GUI として表示される．

コンテンツの利用者数は時と場合によって大きく上下す

GUI が操作されてパラメタ値が調整された場合，リリックるため，一度に大量のアクセスがあった場合などにも対応

アプリ側では onParameterUpdate イベントが発行されるたできるスケーラビリティを確保しなければならない．我々め，これに対応するリスナをプログラマが実装することで，は，リリックアプリという新たな表現形式を提案するにあ

アプリの振る舞いをインタラクティブにカスタマイズできたり，プロトタイプ開発ができるだけでなく，これらの課るようになる．ミュージシャンは，Customizer でリリック

題解決まで考慮に入れ，高い信頼性でのアプリの大規模配アプリを自分好みにカスタマイズすることによって，より信までサポートしたいと考えた．

効果的な楽曲のプロモーションに繋げることができる．

そこで我々は，インタラクティブミュージックの大量流通に関する議論 [5] を参考にして，現状もっとも現実的な

5. 実装

解は，アプリを Web 標準に則った Web サイトとして配信

本章では Lyric App Framework の実装について説明すできるようにすることだと考えた．本フレームワークを使る．なお，本フレームワークは「TextAlive for Developers」

えば，プログラマが Web サイトを構築する技術さえ持っ*3 という Web サイトで一般公開済みである．

ていれば，上記のような大量流通が可能なプロダクション
レディのリリックアプリを実装できる．

5.1 フレームワークの Web サーバ

リ リ ッ ク ア プ リ は ，最 小 限 の ケ ー ス で は HTML/-

4.1 節で紹介した Web ベースのワークフローを実現する

JavaScript ファイルを配信できる静的な Web サイトだ

ために，REST (REpresentational State Transfer) モデル

が，プログラマのスキルとインタラクションシナリオのの API を提供する Web サーバと，Web インタフェース

ニーズ次第では，スタイルシートやメディアコンテンツ，を提供するためのクライアントアプリケーションが動作

サーバサイドのコードなどを含んだサイトとして実装すする Web サーバの 2 種類を実装した．これらのサーバはることも可能である．この際，プログラマは，楽曲，歌詞共にリリックアプリの情報（作者名，URL など）を保存

テキスト，音楽的要素に関する解析情報をスケーラブルにするためのデータベースと接続されている．また，REST

配信することに気を揉む必要はない．なぜなら，こうしたAPI を提供する Web サーバは，我々が研究開発してきたデータは，我々のフレームワークのサーバか，楽曲や動画

Songle [36, 37] のサーバや，その他の音楽的要素の情報をの共有サービスからユーザの手元へ直接届けられるため提供する外部サーバとも接続されている．本フレームワー

である．アプリの可用性や読み込み速度をさらに向上する

クと TextAlive のために，歌詞タイミングや歌詞単語の品

必要があれば，すべてのデータを単一の Web サイトにま詞の解析機能，タイミング情報のリビジョン管理，プライ

とめ，コンテンツ配信ネットワーク (Content Distribution

ベート楽曲と歌詞のアップロードを実現するためのスト

Network; CDN) 上に配置することも可能である．

レージ機能を，これらの外部サーバに新規実装した．歌詞

4.3.2 Lyric App Customizer
本フレームワークは，プログラマやミュージシャンがリ

c 2023 Information Processing Society of Japan⃝*9https://developer.textalive.jp/app/customize

8情報処理学会研究報告
IPSJ SIG Technical Report

タイミングの解析は当初，既存研究 [14] に基づいた技術でリリックアプリ側で onAppParameterUpdate イベントが発実現したが，後により精度の高い新規技術に差し替えた．

行され，プログラマの処理によってカスタマイズ結果がイ

また，単語の品詞解析は，日本語では Mecab [38] を，英語

ンタラクティブに反映される．

では Natural Language Toolkit (NLTK) [39] を用いた．
現在の実装では，歌詞は日本語，英語，日英混合を扱え

5.3 リリックアプリ開発用クライアントライブラリる．また，楽曲に関しては 10 分以内のものを扱える．解析

リ リ ッ ク ア プ リ 開 発 用 の TextAlive App API*2 は

結果は後述する Web インタフェースで修正できる．修正

JavaScript 用クライアントライブラリとして実装してあり，

結果は数値のリビジョン番号とともにサーバに記録され，“npm” パッケージをインストールするか <script> タグ

4.1.2 節で紹介したように，プログラマがその番号を指定すで読み込むことにより利用可能となる．

ることでリリックアプリの動作の再現性を向上できる．

リリックアプリで楽曲を読み込んだあと利用できるよう

我々は，本フレームワークの一般公開にあたり，当初はになるメディア情報には，フレームワークの Web サーバ

日本のコミュニティで活用されることを想定したため，日に登録したときに入力されるメタ情報 (楽曲 URL，歌詞

本語または日英混合で書かれた歌詞テキストをサポートし

URL，アーティスト名，楽曲タイトルなど) と，Web ペー

た．日本語は文字ごとに発声する音が明確な場合が多く，

ジ上に埋め込まれるメディアから取得できる実行時情報

文字ごとのタイミング情報を提供する合理性は高い．対照(楽曲長など) がある．また，リリックアプリで読み込め

的に，英語は文字ごとのタイミング情報を定義できない場る楽曲は現状，Web 上の MP3 ファイル (フレームワーク

合が多い．そこで，現在の実装では，日本語は文字レベルの Web サーバにアップロードされたプライベート楽曲か，

でタイミング情報を解析する一方，英語は単語レベルまで

ミュージシャンやプログラマが自身でホストしている楽曲)

タイミング情報を解析している．英語の文字ごとのタイミと，動画共有サービスにアップロードされた動画 (YouTube

ング情報は，便宜的に，単語レベルのタイミング情報を線とニコニコ動画) である．TextAlive App API は，これら形補完したものを提供している．

の楽曲の再生操作に必要な API (MP3 ファイルに関しては HTML DOM API，YouTube 動画に関しては YouTube

5.2 フレームワークの Web インタフェース

Player API，ニコニコ動画に関してはニコニコ動画プレイ

Web インタフェースには 3 つの役割がある．まず，フヤー API) の差分を吸収するラッパーライブラリを提供す

レームワークの Web ベースのワークフロー (4.1 節) のうる．一部の API は再生位置に関する情報を定期的にアッち，楽曲情報を管理する機能を提供する．すなわち，Web

プデートする仕組みになっているため，ラッパーライブラ

上の一般公開楽曲と歌詞の URL を登録して解析したり，

リの側では，アップデート処理が実行されるたびに再生位

新しく楽曲の MP3 ファイルと歌詞のプレーンテキストを置と UNIX タイムスタンプの情報を保持しておき，プログ

アップロードして解析したり，これらの楽曲の解析結果をラマが再生位置を取得しようとした際には，これらの情報閲覧したり修正したりできるようにする．次に，6.1.2 節でをもとになるべく精確な再生位置情報を補完して提供でき後述するとおり，フレームワークのチュートリアルや API

るようにしている．

リファレンスなどの参考資料を提供する．最後に，Lyric

フレームワークの音楽的要素の解析モジュールは，種類

App Customizer (4.3.2 節) を提供する．以下，Customizer

ごとに異なる時間精度を持っており (例えば歌詞タイミンの使い方とその実装手法について詳述する．

グは 10 ミリ秒，音楽印象は 15 秒など)，元データの精度

まず，プログラマは Customizer でリリックアプリのによらずミリ秒単位で情報にアクセスできるような補完処

URL を指定する．この際，必要に応じてリリックアプリ

理はクライアント側で行われる．具体的には，TextAlive

で開きたい楽曲の URL も指定できる．次に，Customizer

App API で各音楽的要素を表すクラスを定義しており，指はリリックアプリを <iframe> コンポーネント内で起動す

定された再生位置に対し近傍の解析結果を線形補完して返る．その際，楽曲 URL が指定されていた場合はリリック

す処理をクラス内に実装した．

アプリに渡すクエリパラメタで指定する．そして，リリッ

時刻駆動型 API は画面の更新頻度に合わせてリリック

クアプリ側でフレームワークのクライアントライブラリ

アプリ実行中に大量に呼ばれるため，充分高速に結果を返(5.3 節) が REST API サーバへの接続などを行ったうえ

せるよう，事前に時刻順にソートした音楽的要素のインス

で onAppReady イベント (図 2) を発行し，楽曲が再生可

タンスの配列からバイナリサーチを行うように実装した．

能な状態となる．Customizer はその後もフレーム間通信の Web 標準 API である Web Messaging API を用いてリ

6. プログラミング・コンテストでの実証実験

リックアプリと情報のやり取りを続け，再生位置やカスタ

リリックアプリという新たな表現形式のデザイン空間をマイズ用のパラメタ値を更新し続ける．Customizer 側に明らかにするために，我々は 2020 年 9 月 18 日に TextAlive

表示されているカスタマイズ用 GUI が操作された場合は，

App API を含む Lyric App Framework を一般公開し，実c 2023 Information Processing Society of Japan⃝9

情報処理学会研究報告
IPSJ SIG Technical Report

証実験として年次のプログラミング・コンテストを開催し票を受け付けた．投票は 1 人 1 回 1 作品まで，スマートてきた．本章では，プログラミング・コンテストについて

フォン用アプリ「ミクナビ」のユーザであれば誰でも行え

紹介するとともに，2 年分の応募作品 52 件を分析して判明た．プログラミング・コンテストの Web サイト上では，投したリリックアプリのカテゴリ 8 種類などの結果を報告す

票に際してユーザが実際に試せるよう，すべての入選作品

る．また，利用統計やソースコード分析，質的ユーザ評価

をデプロイし，その動作を録画したデモ動画も掲載した．

の結果を紹介し，本フレームワークの有効性を検証する．

また，「マジカルミライ」イベント会場 (大阪) での「入選作品紹介」のステージ*10 上で，著者ら (加藤，後藤) とコン

6.1 プログラミング・コンテストの概要

テストを主催するクリプトン・フューチャー・メディア株

プログラミング・コンテストは，年次の大規模イベント

式会社の代表取締役である伊藤 博之氏が，パネル形式で入『初音ミク「マジカルミライ」』の一環として開催された．

選作品を紹介して投票を呼び掛けた．1 週間弱の一般投票

本イベントは著名な歌声合成ソフトウェアでありバーチャの期間が終わってから，投票結果を踏まえて主催側で改め

ル・シンガーである「初音ミク」を生み出したクリプトン・て審査を行い，受賞作品 (最優秀賞 1 件，優秀賞 3 件) を選

フューチャー・メディア株式会社が主催し，「初音ミクたち定した．そして，後日の「マジカルミライ」イベント会場

バーチャル・シンガーの 3DCG ライブと，創作の楽しさを(東京) での「受賞作品発表」のステージ*11 の後，受賞した体感できる企画展を併催したイベント」 [40] である．

チームには賞状，グッズ詰め合わせなどが贈られた．受賞

本研究において，本コンテストでの実証実験には 3 つの目的がある．まず，創作文化を楽しみ，創作文化に貢献す

作品発表後に，事後アンケートを参加者にオンライン配布
しており，その結果は 6.3.3 節で報告する．

る人々が集まる場となっているイベントでコンテストを

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

開催することで，未来志向のプログラマとともにリリック(Web アプリケーションの演出が楽曲と同期して魅力的に

アプリのデザイン空間を探索することである．次に，本フ見えるか)，イノベーション (Web アプリケーションを支えレームワークが幅広いプログラミング経験を持つプログラ

るアイデアがユニークで，未来の創作文化を予感させるもマを効果的に支援できるか検証すること，そして，リリッのであるか)，完成度 (Web アプリケーションが一般的な

クアプリのコミュニティを活性化することである．

Web ブラウザで正常に動作するか，実装が技術的に優れて

6.1.1 コンテストのルールと進め方いるか) であった．3 つの評価軸はコンテストの公式 Web

コンテストは「初音ミク『マジカルミライ 2020』プログラミング・コンテスト」[41] および「初音ミク『マジカサイトに明記され，参加者はいつでも確認できた．

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

ルミライ 2021』プログラミング・コンテスト」[42] と呼我々は，Lyric App Framework を公開する際に，チュー称され，「マジカルミライ」イベント会場での入選作品紹

トリアルや API リファレンス，スライドの読み上げとデ介*10 と受賞作品発表*11 を除けばオンラインで進行した．

モを交えた説明動画などの参考資料を Web サイト*3 に掲

主催側でリリックアプリの開発に必要な権利処理が済んで載した．チュートリアルはフレームワークの概要を紹介すいる楽曲と歌詞を課題曲として提供することで，参加者がるとともに，リリックアプリの開発を始めるための手順を開発に集中できるようにした．コンテストの応募期間中，説明する内容であった．さらに我々は，フレームワークの本フレームワークのハンズオン (実習を伴う体験型イベン

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

ト) は対面とオンラインの別を問わず開催しなかった．そGitHub 上で MIT License のサンプルコードとして公開しの代わり，6.1.2 節で後述する参考資料をオンラインで提た*14 ．ここでは，うち 3 件を紹介する (図 4)．

供した．Twitter*12 や Gitter*13 でも参加者からの質問に適

1 つ目の例であるインタラクティブ歌詞カードでは，楽曲宜回答した．コンテストの応募に際して (参加は無料)，参

再生の進行とともに歌詞テキストが CSS アニメーションで加者は静的 Web アプリケーションのソースコードとビル

1 ．美しく読みやすい歌詞を表示する
徐々に表示される ○ド手順を提出した．サーバ側のプログラムを含まない静的

ために，歌詞テキストは単語の品詞に応じた色と大きさでアプリケーションに限ったのは，応募作品を主催側の Web

2 ．ユーザは，歌詞を読むだけでなく，単語を表示される ○

サーバに設置して誰でも楽しめるようにするためである．

クリックしてそこから再生できる．Lyric App Customizer

各年，応募を締め切ってからは，主催側の審査で入選作を使えば，背景の色味などを変更でき，カスタマイズした品を選定し，入選作品発表とともにオンラインでの一般投

3 ．このリリックアプ
歌詞カードを他の人と共有できる ○リには他にも，基本的な再生操作ができ，楽曲や歌詞の作*10

https://youtu.be/-t9AVVgZo5k (2020)
https://youtu.be/hvmDxCeyWU8 (2021)*11 https://youtu.be/Yz4Ucrw95bQ (2020)
https://youtu.be/MkILA_NC1T0 (2021)*12 https://twitter.com/TextAliveJp*13 https://gitter.im/textalive-app-api/communityc 2023 Information Processing Society of Japan
⃝

者情報を表示するユーザインタフェースが備わっている
5 ．
4 ．画面上部には半透明なシークバーもついている ○○*14

https://github.com/TextAliveJp

10

情報処理学会研究報告
IPSJ SIG Technical Report

4

5
2
10
9

7

1

8

3

A

11

6

インタラクティブ歌詞シート

B

歌詞タイル

C

ダンスするリリックアプリ

図 4: 本フレームワークで実装したサンプルコード 11 件中 3 件のスクリーンショット．(全件の概要は付録 A.2を参照．)
理解しやすいコードを書くことを心がけてコメントも多くの応募があった．提出された全 52 件のリリックアプリは挿入したが，本アプリは簡潔に 237 行 (コメントを除けばすべて完成して実行可能な状態であった．それらのリリッ

160 行) で実装されている．

クアプリの驚くほど豊かなデザイン空間を理解するため，

2 つ目の例である歌詞タイルは，HTML5 Canvas API で

我々は以下の手順で分類した．まず，各リリックアプリの画面全体に正方形のタイルで構成される二次元グリッドを内容を説明する短い文章を書いた．そして，これらの説明

6 ．各タイルには歌詞テキストは 1 文字しか表表示する ○
7 ．そこでユーザがマウスかタッチ操作で二示できない ○

文に繰り返し現れるキーワードから，あまりに一般的な次元グリッド上を滑らかに移動すると，歌詞の文字が発声る説明は繰り返し出現するので除いた．この時点で，拡の都度，画面中央近傍の空いているタイルに表示されてい張現実 (extended reality)，ジェネラティブリリックビデ

8 ．ユーザは，二次元グリッド上をさまざまな移動経く○オ (generative lyric video)，ゲーム (game) という 3 つの路で動き回ってタイルを歌詞で埋めていく．楽曲を再生す

カテゴリが得られた．次に，この 3 カテゴリに収まらない

る度に違う経路になるので，さながらピクセルアートを描

リリックアプリの説明文を注意深く分析し，創造的アプリ

くような創造的な体験ができる．

用語を除いた．例えば，歌詞テキストがアニメーションすケーション (creative application)，楽器 (instrument)，拡

3 つ目の例であるダンスするリリックアプリは，「ちび張音楽動画 (augmented music video) という 3 つのカテゴキャラ」と呼ばれるスタイルのキャラクタがステージ上でリを得た．この時点ですべてのリリックアプリが 6 カテゴ

楽曲に合わせて踊る様子を Three.js を使って実現したもの

リに収まったが，いくつかのカテゴリに関してはユーザが9 ．画面下部から浮かび上がってくるパーティクである ○インタラクションできる手段をもとにサブカテゴリに分けル効果と歌詞テキストの文字オブジェクトがステージを盛たほうが的確に分類できることが分かった．具体的には，

10 ．これらの動きのパターンは，ビート
り上げてくれる ○ジェネラティブリリックビデオにはユーザの入力を何も受や楽曲の繰り返し構造などを反映して動的に生成されていけ付けないものもあれば，インタラクティブなものもあり，る．Customizer を使えば，キャラクタを切り替えたり，ス

後者をインタラクティブリリックビデオ (interactive lyric

テージ上の配色を変更したりできる．Customizer が接続

video) というカテゴリに分けた．また，創造的アプリケー

されていない場合 (すなわち，このリリックアプリが直接ションにはシークや巻き戻しの操作を許さず即興的な体験

Web サイトとして読み込まれた場合) でも，これらのパラを重視するものもあれば，楽曲を聴き込みながら何らかの

メタを変更できるユーザインタフェースが表示される実装

コンテンツを作り込んでいく制作ツール (authoring tool)になっており，ユーザがアプリを常にインタラクティブにと呼ぶべきカテゴリのものもあった．

11 ．
楽しめるよう配慮されている ○こうして我々は，リリックアプリのカテゴリとして 8 種

我々はこれらのリリックアプリがフレームワークの代表類を発見した．52 件の応募作品は，9 件の拡張現実アプリ，

的な機能を活用したものになるよう注意深く設計したが，6 件の制作ツール，6 件の創造的即興アプリ，3 件の楽器ア

同時に，サンプルコードとして多くの人々の環境で動作す

プリ，6 件のゲーム，2 件の拡張音楽動画，5 件のインタラ

るよう，スマートフォンや PC，タブレット端末など多様

クティブリリックビデオ，16 件のジェネラティブリリック

な Web ブラウザ上で動作する互換性にも気を配った．そビデオに分類された．

のため，実験的な Web 標準 API (位置測位，加速度セン6.2.1 拡張現実アプリ (extended reality)

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

このカテゴリは，仮想的な 2D・3D の情景における没入感のある体験に重点を置いている．カメラ入力を活用し6.2 リリックアプリの 8 種類のカテゴリて，実世界の情景に歌詞駆動の視覚的演出レイヤーを追加

2 回のプログラミング・コンテストはそれぞれ 47 日間するものもある．ユーザは楽曲の世界観の中にいるようにと 77 日間にわたって応募期間が設けられ，32 件と 20 件感じられる．例えば，特定の楽曲のために作り込まれた，

c 2023 Information Processing Society of Japan⃝11

情報処理学会研究報告
IPSJ SIG Technical Report1

拡張現実アプリ

2

制作ツール

3

創造的即興アプリ

4

楽器アプリ

5

ゲーム

6

拡張音楽動画7

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

8

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

図 5: プログラミング・コンテスト応募作品の分析で判明したリリックアプリのカテゴリ 8 種類と，その代表例のスクリー
ンショット．付録 A.3に 12 件を追加掲載．(スクリーンショット提供: クリプトン・フューチャー・メディア株式会社)
1 ) があっ学校の教室の中を自由に動き回れる作品 (図 5 ○えば曲を聴きながら曲の終わりまで絵を描ける作品 (図 5

た．この作品では，教室の中に歌詞のストーリーと関連の3 ) や，タッチ操作で画面上に音符を置いていくとサビで○ある隠し要素が配置されており，これを見つける楽しみ方

その音符が踊りだす作品，キャラクタを操作して仮想空間もできるようになっていた．別の作品では，WebVR API

内を移動させることができ，その軌跡に花を咲かせて絵やを使って VR ヘッドセットで仮想空間に飛び込めるものや，

14 ) などがあった．
文字を構成できる作品 (図 A·3 ○AR.js を使ってカメラ画像の手前に歌詞がタイミングよく

6.2.4 楽器アプリ (instrument)

表示される立方体を映し出すもの，Tensorﬂow.js を使ってこのカテゴリは，ユーザが楽曲演奏に能動的に関与するユーザの姿勢情報を取得し，カメラ画像の上に視覚的なエための楽器や道具の役割を果たす．例えば，MediaPipe.js

フェクトを表示するものなどがあった．

を用いたカメラ入力の画像処理によってユーザの手の動き

6.2.2 制作ツール (authoring tool)を推定し，画面上の仮想的なペンライトに割り当てた作品

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

4 )．また，Web MIDI API を用いて接続があった (図 5 ○し，作り込み，場合によっては他の人と共有することまでされた MIDI 機器の信号を読み取り，楽曲再生と同時に演可能にする．例えば，リリックビデオを構成する視覚的要

奏ができる作品があった．ユーザのクリック操作のタイミ

素を画面上に配置していくことで，音楽動画を作り上げ

ングで既定の音を鳴らす作品もあった．

12 )．視覚的要素は，ることが可能な作品があった (図 A·3 ○6.2.5 ゲーム (game)

歌詞テキストが表示されるプレースホルダやパーティクル

このカテゴリは何らかのルールや得点制を採用してお効果，キャラクタがアニメーションする画像などの中からり，ユーザにゴールしたり高得点を取ったりしたいと思わユーザが自由に選べるようになっていた．さらに複雑な例せるような仕掛けが実装されている．典型的なゲームアプ

として，プロジェクションマッピング用のコンテンツを制

リでは，本フレームワークを活用することでユーザが課題

2 )．ユーザは，曲ごとの内容
作できる作品があった (図 5 ○曲を選べるようになっている．ゲームに分類された応募作を踏まえて定義された仮想的な 3D 空間で，特定の平面上品のすべてが，次々に出現する歌詞テキストとうまくインに視覚的要素を配置していくことができた．こうして作り

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

上げた 3D の情景は，実世界で同様の平面を再現すれば実ある作品は，ユーザがライブステージ上のキャラクタを操際のプロジェクションマッピングに活用できるようになっ

作して，飛んでくる歌詞テキストにタイミングよく触れるていた．さらに別の作品では，3D 空間内でキャラクタが5 )．また別の作品は，歌詞のフレーズ
ゲームだった (図 5 ○楽曲を歌唱しながらアニメーションしており，さまざまなごとに動的に生成された曲線上に文字が並んでおり，これ設定項目でその様子をカスタマイズできるようになっていらをタッチ操作でタイミングよくなぞっていくゲームだっ11 )．
た (図 A·3 ○16 )．どの作品も，ユーザと歌詞の文字の間のた (図 A·3 ○6.2.3 創造的即興アプリ (creative application)

ユニークなインタラクションを追求していた．

このカテゴリは，ユーザが再生中の楽曲と創造的にイン6.2.6 拡張音楽動画 (augmented music video)

タラクションできるようにしてくれる．制作ツールと異な

このカテゴリは対象楽曲の音楽動画を表示し，その再生り，このカテゴリでは基本的にシーク操作が許可されておと同期したインタラクティブな体験を提供する．例えば，らず，その代わり即興的な体験に重点が置かれている．例

特定の楽曲の音楽動画が画面右下に表示され，その情景を

c 2023 Information Processing Society of Japan⃝12

情報処理学会研究報告
IPSJ SIG Technical Report

参考にしたインタラクティブな視覚的要素が画面の他のムワークの評価を行うことに関しては，大きく分けて 2 点

6 )．キャラクタが領域に表示される作品があった (図 5 ○の制約がある．まず，コンテストの応募前につまづいた作

画面左から右に歩くシーンでは，ユーザがカーソル操作で品は含まれない．したがって，フレームワークが一定数のキャラクタを左右に動かせるようになっていた．また，操プログラマに利用されたことのエビデンスにはなるが，必り人形が操られて変形するシーンでは，ユーザがマウス操

ずしも初学者に使いやすいことを示すわけではない．ただ作で変形の仕方をコントロールできるようになっていた．

し，後述するプログラミング・コンテスト後のアンケート

他にも，音楽動画が額装されて画面中央に表示され，そのの結果によれば，初学者が問題なく動作するリリックアプ

周辺にステージのような情景が広がり，画面下部には客席リを応募できていることが分かった．例えば，参加者には

17 )．楽曲再生とが多数表示される作品もあった (図 A·3 ○Web アプリケーションの開発経験がまったくない人々が含同期して歌詞などがステージに表示され，座席の観客もアまれていた．

ニメーションするようになっていた．さながら映画館で作

次に，コンテストの競争的なフォーマットは，参加者に品鑑賞しているような演出であった．

対して，審査員映えするリリックアプリを開発するプレッ6.2.7 インタラクティブリリックビデオ (interactive

シャーを与えてしまう．プレッシャーにより，(a) フレー

lyric video)

ムワークの評価に影響が出る可能性と，(b) 応募作品の多

このカテゴリは，リリックビデオを動的に描画したうえ

様性が狭まる可能性がある．問題 (a) に関しては，フレー

で，ユーザがインタラクションできるようにしたものであムワークの開発者である我々が審査員を務めることで，フる．例えば，歌詞テキストが 3D の仮想空間内を右から左

レームワークに関する技術的な問題が指摘しづらくなるリにスクロールする情景を描いた作品では，ユーザがテキス

スクがあると考えており，以下のとおり対処した．(1) 審トをマウスかタッチのドラッグ操作でつかんで左右に動か査員のうち半数をフレームワーク開発者以外とした．(2)7 )．別し，再生位置を変更できるようになっていた (図 5 ○技術的な課題についてオープンに議論できるオンラインの作品では，発声された歌詞の文字が徐々に 3D 空間の中

フォーラムを開設し，プログラミング・コンテストでは開発央に集まっていき，再生が進んでサビに到達すると文字が過程は評価対象にならないことを明示して，フレームワー

一気に散り散りになる演出がプログラムされており，ユークに問題があった場合にためらわずに報告できるよう配慮

ザはドラッグ操作で画面中央の文字の塊を自由な角度からした．(3) 応募作品のソースコードを読み，フレームワー

見ることができるようになっていた．

クの致命的な問題に対する対処がないことを確認した．

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

問題 (b) に関しては，近年の創造性支援研究の文脈 [8]で批判されてきた，統制が取れた環境で短期間ツールを利このカテゴリはリリックビデオをプログラムによって動用してもらうような評価実験と比較すれば，むしろ条件は的に描画するもので，単なる動画であればアスペクト比や恵まれている．なぜなら，フレームワークが一般公開されフレームレートが固定であるのに対し，それらをユーザのており，多様な技術的背景のユーザに利用の機会が開かれ閲覧環境に応じて柔軟に変更できるものが多い．シーク操てきたためである．また，一般公開から 2 年以上が経過し，作のような基本的な再生操作は可能だが，それ以外のイン長期間にわたる学習も可能な環境であった．さらに我々

タラクションには対応していない．このカテゴリの典型的は，多様なリリックアプリが応募されるよう，プログラミなリリックアプリはリリックビデオと似た体験をユーザにング・コンテストの評価軸を工夫してきた．仮に評価軸がもたらすが，好みのスタイルにカスタマイズできる作品がリリックアプリの美しさだけを重視するものであったな

ある他，視覚表現として見たときに，歌詞のタイミングやら，コンテストはデザイナやイラストレータの関与が求めその他の音楽的要素に合わせてアニメーションする同期られるような性質のものになっていただろう．また，仮に的演出が多用される特徴がある．なお，リリックビデオで評価軸がリリックアプリの実装の完成度だけを重視するもは見られない表現を追求した例外的な作品もあった．例えのであったなら，コンテストは，競技プログラミングのよば，楽曲全体を特定の数のパートに分割し，イラストも同

うに技術的課題を解くことが得意なプログラマが活躍する

数のパネルに分割して，それぞれパズルのピースに見立てものになっていただろう．我々はコンテストがこのいずれ

8 )．楽曲の再生が進むにつれ，ピー
た作品があった (図 5 ○にも偏ることがないよう 3 つの評価軸 (6.1.1 節) を定めた．

スが画面上の適切な場所にはめこまれ，楽曲再生が完了す

このような多角的な評価軸を明示することで，参加者側にるタイミングでイラストが完成する演出となっていた．ま作品制作で重視するポイントを選択してもらえるようにな

た，歌詞テキストを同じ音素数の別の単語に置き換えて替り，結果として多様な応募作品が集まることを狙った．

え歌を生成し，画面上に表示する作品もあった．

6.2.9 プログラミング・コンテストの制約
プログラミング・コンテストの応募作品を分析し，フレーc 2023 Information Processing Society of Japan
⃝6.3 フレームワークの有効性評価
本節では上記以外に追加で行った評価について報告する．

13

情報処理学会研究報告
IPSJ SIG Technical Report

6.3.1 利用統計

高い天井 (low threshold and high ceiling)」 [43] の特長を本フレームワークの一般公開は 2020 年 9 月 18 日に始兼ね備えていたこと，すなわち Web アプリケーション開

まった．リリックアプリ開発の利用統計を取るため，2021

発の初学者から熟練者まで幅広い技術的背景を持つプログ

年 9 月 22 日より，リリックアプリごとにアクセスキーをラマに活用されていたことを示している．

発行し，REST API サーバにアクセスする際にはアクセ

さらにソースコードを読み込んだところ，多くの応募作

スキーをリクエストに含めるようにした．この記録によれ品で独自の「シーンマネージャ」が実装されていることがば，2022 年 9 月 13 日の時点で 396 人のユーザが 448 個の分かった．典型的なケースでは，このマネージャはリリッ

リリックアプリを開発している．古いバージョンのリリッ

クアプリが楽曲を読み込んだ時点で初期化処理をし，楽曲クアプリが問題なく動作するよう互換性を保つため，アク再生中の映像演出を事前に準備する役割を果たしていた．

セスキーがなくても REST API サーバへのアクセスを許その初期化内容としては，楽曲構造を分析してイントロ，

すようにしており，実際にはこれより多くのアプリが開発

繰り返し区間，アウトロなどに区間分割し，視覚的要素をされていることになる．

表すオブジェクトをインスタンス化して再生時の演出に備

また，GitHub によればフレームワークのリポジトリはえていた．そして楽曲の再生中は，マネージャは楽曲構造

78 個のスター (リポジトリへの興味と称賛を表す指標) をの遷移を監視し，視覚的要素の表示状態を管理していた．

獲得しており，67 個以上のリポジトリでフレームワークがこのリリックアプリの典型的なデザインパターンのため利用されている．さらに，2 年間のプログラミング・コンに，フレームワーク側でできる拡張を 7.1.3 節で議論する．

テスト参加者のうち 30 名が応募作品をオープンソース公6.3.3 質的ユーザ評価

開し，リリックアプリの開発コミュニティを盛り上げよう

我々はプログラミング・コンテスト参加者に自由記述でとしてくれている．全体として，これらの客観的な統計値のアンケート回答を依頼し，各年に 21 件と 15 件の回答がは，フレームワークが大きな問題なく利用されてきたこと寄せられ，コンテストに参加した動機やフレームワークにを示している．

関するコメントなどの質的フィードバックを収集できた．

6.3.2 ソースコード分析

例えば，プログラミング・コンテストが創造的な文化にプ

我々は 52 個の応募作品のソースコードを読み，内容をログラミングの力で貢献する貴重な機会となっていること分析した．16 個が我々の提供したサンプルコードの内容を大きく評価する旨のコメントがあった．フレームワーク

から部分的に派生したコードを含んでいたが，どの場合もに対しては肯定的な感想が大部分を占めたものの，致命的差分があり，多くの場合で Web アプリケーションのビル

ではないが修正すべきバグに関する報告も寄せられた．

ド方法 (Parcel を使ってファイルをまとめ，一般公開用の

2 年目のアンケートでは参加者のプログラミング経験にコードを生成していた) が共通しているだけであった．他

ついて詳細に尋ねた．回答によれば，まったくの未経験かの，例えばインタラクションデザインや見た目に関しては，

ら 6 年の JavaScript 実務経験まで多様で，ソースコード分

コンテスト参加者自身が工夫を凝らしていた．

析 (6.3.2 節) で示されたフレームワークの「低い敷居と高フレームワークが提供している時刻駆動型 API は，さい天井」を裏付ける内容だった．とくに，回答者の実に 3

まざまなクリエイティブコーディングや GUI のライブラ

分の 1 が JavaScript を用いたプログラミングの経験がほぼ

リと併用できていた．例えば p5.js，Three.js，Create.js，ゼロであったことは驚きであり，それでもコンテストに参PixiJS，glslify，GSAP，PlayCanvas，そして Phaser などの加した動機について 7.2 節で考察する．

クリエイティブコーディング用ライブラリが利用されていこのアンケートでは，参加者が時刻駆動型 API に満足してた．また，GUI ライブラリとして jQuery，React，Vue.js，いるか，そして歌詞などの音楽的要素に対するイベントリス

そして Svelte などがリリックアプリをインタラクティブに

ナ ( player.addEventListener("phraseEnter", listener) なする目的で活用されていた．Tweakpane や dat.gui などのど) の必要性を感じているかについても質問した．回答はユーザインタフェースのコンポーネントライブラリを活用

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

して，ユーザがリリックアプリの振る舞いをカスタマイズに 4.2.1 節のイベント駆動型 API は利用しているものの，できるようにしている例も見られた．さらに，多くの応募

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

作品が静的画像，Web フォント，スタイルシートなどをタイムなマルチメディア演出において有用であると考えてリリックアプリに同梱しており，魅力的な見た目を実現しいた．一人の回答者はイベントの種類が多いほどよいと回ていた．Lottie という，Adobe After Eﬀects で制作したア

答していたが，他の回答者からはそういった要望はなかっ

ニメーションを Web アプリケーションで使えるようにすた．別の回答者は，複雑なシーン管理を実現したいが，そるツールを活用している例もあった．これらの多様な結果のためには現在の API 設計では不充分であるとコメントしは，フレームワークが単に問題なく利用できていたというていた．これはソースコード分析 (6.3.2 節) で述べたシーだけでなく，プログラミング用の道具として「低い敷居とンマネージャの必要性を改めて示しているものである．

c 2023 Information Processing Society of Japan⃝14

情報処理学会研究報告
IPSJ SIG Technical Report

7. 議論「リリックアプリ」という表現形式は，我々が提案したもので，現状研究対象としてはニッチと言えるかもしれな
い．しかし本研究は，3 つの幅広い観点で研究上の知見を提供するものである．

利用可能なコンポーネントとして扱うデザインパターンに沿ったものが，コード全体のモジュール性を向上できており，複雑で魅力的な画面演出に成功している傾向にあった．

7.1.2 時区間駆動型 (time-range-driven) API
リリックアプリ開発においては，前述のような再利用可
能コンポーネントのライフサイクルが，音楽的要素の可聴

まず第一に，音楽情報処理の研究者，より広くは音楽業

時区間 (ビートから次のビートまでの区間やフレーズの発界の人々にとって，音楽コンテンツを取り巻くインタラク

声区間など) に紐づいていることは注目に値する．応募作

ティブな体験の重要性は従前より指摘されており ( [44] な品のソースコードの中で我々は，現在の再生位置がそうしど)，リリックアプリはそうした体験を提供する有望な一手た可聴時区間の中に入ったか，あるいは外に出たことを検段となる．本フレームワークはリリックアプリの開発を支出する機能がたびたび実装されていることを発見した．例

援する初めての取り組みであり，これは，リリックアプリ

えば，ある作品では，画面上のパーティクルの出現を管理すをニッチから文化的メインストリームへ押し上げる重要なるパーティクルマネージャが，前回の player.findPhrase

技術的マイルストーンである．

関数の呼び出し結果を保存しており，前回と今回の結果を次に，本フレームワークで提案した時刻駆動型 API は，

7.1 節で後述する通り，リリックアプリに限らず精密な時比較することで，パーティクルを表すオブジェクトを初期化するか破棄するか決定していた．

刻同期が必要なインタラクションデザイン全般で有用でこうしたデザインパターンは，フレームワークに新たなある．最後に，本フレームワークを利用した実証実験は，API を実装することで支援できる．例えば，時区間を引数

7.2 節で後述する通り，音楽とプログラミングという 2 つに与える次のような API が考えられる:の創造的な活動の距離を近くする新技術によって，ミュー
ジシャンとプログラマの新たな協業の機会が生まれたこと

player . f i n d P h r a s e C h a n g e ( previousPosition ,cu rr e nt Po s it io n ) ;を明らかにしたものである．
返り値は，その時区間で発声を終えたフレーズの配列，発7.1 時刻駆動型 API に関する知見
6.3.3 節で紹介したとおり，時刻駆動型 API はユーザか声を始めたフレーズの配列，そして発声中のフレーズとなる (詳しくは付録 A.1を参照のこと)．

ら肯定的に評価された．当該 API により，楽曲中の多様な

時刻駆動型 API を拡張した「時区間駆動型 (time-range-

音楽的要素を考慮に入れたインタラクションの実装が効果

driven) API」によって，リリックアプリ開発において以下的に支援できた．本節では，さらにソースコードを分析すのような利点が得られる．まず，プログラマが自身のコーることで得られた知見を報告する．すなわち，高度な演出

ドで能動的に情報を取りに行く API の特長が保たれるたをプログラミングするには再利用可能なコンポーネントがめ，さまざまなクリエイティブコーディングや GUI のラ重要性であること (7.1.1 節)，そうしたデザインパターン

イブラリと併用できる．次に，時区間を引数で与える APIを支援するためには，新たな API 設計が有用な可能性があ設計により，プログラマが任意の時区間を自ら定義して音ること (7.1.2 節，7.1.3 節) である．

楽的要素を探すことができる．これはアニメーション遷移

これらの知見は，精密な時刻同期が必要なインタラク

をプログラミングするうえで有用である．例えば，サビ区

ションデザイン全般に応用できる．例えば，音と映像を同間に突入する 5 秒前に遷移を始めたければ，以下のように期させる演出の他，センサとアクチュエータを活用した実時区間駆動型 API を呼び出せばよい:

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

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

player . f i n d C h o r u s C h a n g e ( previousPosition ,cu rr e nt Po s it io n + 5000) ;プログラミング・コンテストの応募作品のほとんどが，クリエイティブコーディングや GUI のライブラリ (4.2.2

7.1.3 ユーザ定義時区間節) のためのレンダリング用関数を定義して画面演出をプ

応募作品の多くが，楽曲全体を複数の区間に区切って，ログラミングしている．このようなジェネラティブなアル

それぞれ固有の歌詞駆動演出を表示するように実装されてゴリズムは単一の巨大な関数内で多様な情報を組み合わせ

いた．とくに，6.3.2 節でも紹介したとおり，区間ごとの演るようなコードを書くことでも実装できるが，こうした方出の遷移を管理する「シーンマネージャ」を実装して，楽法は単調な映像表現に繋がりやすく，我々はアンチパター

曲再生の進行と演出とのマクロな対応付けを行うという実ンの一種だと考えている．

装パターンが典型的なようであった．こうした時区間は，

我々が分析したコードベースの中では，こうした関数を演出を組み立てるプログラマが独自に考えつく創造的な努

細分化して多くのサブルーチンに分け，サブルーチンを再力の成果であり，フレームワーク側であらかじめ定義して

c 2023 Information Processing Society of Japan⃝15

情報処理学会研究報告
IPSJ SIG Technical Report

おくことはできない．そこで，プログラマが自身で時区間ことと同様に，リリックアプリはミュージシャンがプログを定義したうえで再生位置と比較する API を提供できれラマと協力する新たな機会を生み出している．「プログラば，こうしたシーンマネージャの実装を支援できる．例え

ミング環境」はコンパイラやエディタ，デバッガなど，単ば次のような API が考えられる:なるソフトウェアの集合として見なされがちだが，実際のプログラミングはもっとソーシャルな活動であり，プログ

const timeRange = player . creat eTimeRange (startTime , endTime ) ;player . fi n d T i m e R a n g e C h a n ge ( timeRange ,previousPosition , curre ntPosition ) ;ラミング環境は人々とソフトウェアが織りなす共創的な環
境なのである [45]．実際，拡張音楽動画のリリックアプリ
6 ) を開発した参加者は，元の楽曲と音楽動画の作(図 5 ○

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

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

プログラミング・コンテストの受賞者を発表する「マジリリックアプリ開発は，コードエディタ上でプログラム

カルミライ」の企画展ステージにおいて，コンテストを主をまっさらな状態から書く体験とは少し違っている．なぜ催するクリプトン・フューチャー・メディア株式会社の代なら，既存の楽曲に対して新しくインタラクションする機

表取締役であり，音楽業界に詳しい伊藤 博之氏は，音楽能を追加するプロセスだからである．本節では，こうした，と技術の密接な関係に以下のように言及した．『ミュージ既存のコンテンツを拡張するプログラミング体験が持つ利シャンが聴衆に音楽を届ける方法は常に科学的発明の影響点と，今後の研究に向けた興味深いトピックを議論する．

を受けてきた．ピアノを製造するための木工技術から，シ

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

ンセサイザーや歌声合成ソフトウェアの技術まで，枚挙に我々は，プログラミング・コンテストを通して，本フ

いとまがない．これらの技術はミュージシャンの新たな創

レームワークが典型的なクリエイティブコーディングのコ

作の機会となってきたし，音楽コンテンツは常に技術の変ミュニティよりも広範なコミュニティに訴求できており，化に適応してきた．さらに，近年では，ミュージシャンが参加者が開発成果を公開することを促進できていると感じ

歌声合成ソフトウェアで楽曲を作り，イラスト，歌唱，さた．ある参加者は，通常であればこうしたコンテストには

まざまな動画をみんなが作って共有する創作文化がニコニ参加しようと考えないし，参加できなかっただろうとコメ

コ動画や YouTube などの動画配信サービスで培われ，メントしていた．コンテストで設定されていた課題曲への愛

インストリームの文化になってきた．リリックアプリは，が，こうした参加者にリリックアプリ開発とコンテスト参プログラマが創作文化に貢献できる機会を増やす新しいプ加を促していた．クリエイティブコーディングは近年コン

ラットフォームであり，今後の展開に期待している．
』（抜

ピュータ科学教育や芸術的意義の観点で注目を集めている

粋の上、要約して掲載）

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

7.2.3 創造的文化に関する今後の研究

ディングを楽しめるほどに) 充分「創造的 (クリエイティ
ブ)」だという自信を持っているわけではない．
リリックアプリには，そうしたプログラマが「創造的」創造性支援の研究は長らく，技術的新規性に偏重したものが多く，評価実験もラボスタディなど統制的な環境が主流で，「在野 (in the wild)」での研究が不足していると批な部分で既存の楽曲の力を借りて，結果として自身の創造判されてきた [8]．多様なメディアを横断してコンテンツ性を発揮するキックスターターにできるポテンシャルががユーザの手元に届くメディアコンバージェンス [3] の時ある．我々は，プログラミングという活動それ自体が充分

代には，コンテンツの価値はそれ自体で閉じない．派生作「創造的」であると考えており，より多くの人々が創造性

品や，聴衆の SNS での関与なども含めて総合的に考えるを発揮するきっかけにリリックアプリがなってきたことを必要がある．コンテンツを取り巻く生態系はますます広が嬉しく思っている．こうしたリリックアプリ開発は，コンりを見せており，その実態を踏まえた研究のためにも，在

ピュータ科学教育のカリキュラムでも役立つはずである．

野での研究の重要性は増している．

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

本フレームワークは一般公開されており，まさに在野でンタラクティビティを付与するようなクリエイティブコーの取り組みと見なすことができるが，本稿で報告したプロ

ディングへの発展も，今後の研究として興味深い．

グラミング・コンテストでもまだ制約はあった (6.2.9 節)．

7.2.2 コミュニケーションとしてのプログラミング

例えば，サーバサイドのプログラムを含められなかったり，

リリックアプリの開発過程で，プログラマは何度も繰りソーシャルな機能の実装や実験的な API の採用が見送ら

返し楽曲を聴き，歌詞を読むことになる．こうした体験をれがちだったりした．我々は，本フレームワークの研究開

通して，プログラマは魅力的な歌詞駆動型の演出を思いつ発を続け，在野での活用を支援し続けることで，新たなリ

くのかもしれない．リリックビデオがミュージシャンとリックアプリのカテゴリが切り拓かれ，創造的文化に関すモーショングラフィックデザイナの協力関係を可能にしたる構成論的研究をさらに進められると信じている．

c 2023 Information Processing Society of Japan⃝16

情報処理学会研究報告
IPSJ SIG Technical Report

8. おわりに[8]

本稿では，リリックアプリという新たな表現形式を提案
し，その特徴を明らかにして，プログラマが開発するうえでの技術的課題を整理した．そして，そうした課題を解決[9]するフレームワークを開発し，一般公開して，プログラミ
ング・コンテストでの実証実験を行った．これにより，リリックアプリのカテゴリ 8 種類や，今後の研究のための知[10]見を得ることができた．
謝辞 プログラミング・コンテストはクリプトン・フュー
チャー・メディア株式会社が運営した．こうした取り組み[11]

は，新しい技術が人々の創造性に貢献するという信念を共有した信頼・協力関係のもとで可能となったものである．

[12]

また，継続的なコンテスト開催は，情熱的な参加者による応募がなければ実現しなかった．参加者の尽力に感謝するとともに，リリックアプリの可能性を切り拓く学術的にも大きな意義を持つ取り組みの中で応募作品を紹介できたこ[13]とを嬉しく思う．
本フレームワークの Web ベースのワークフローに貢献
した産総研の関係者各位にも感謝したい: 中野 倫靖 (歌詞同期エンジン)，渡邉 研斗 (形態素解析 API)，川崎 裕太・[14]

井上 隆広 (Songle および Songle API)．本研究の一部は以下の支援を受けた: JST CREST (JPMJCR20D4)，JSTACCEL (JPMJAC1602)，JST ACT-X (JPMJAX22A3)．
[15]

参考文献
[1]

[2]

[3]
[4]

[5]

[6]

[7]

Stratton, V. N. and Zalanowski, A. H.: Aﬀective Impact of Music Vs. Lyrics, Empirical Studies of the Arts,
Vol. 12, No. 2, pp. 173–184, DOI: 10.2190/35T0-U4DTN09Q-LQHW (1994).
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.: Convergence Culture: Where Old and New
Media Collide, New York University Press (2006).
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 Algorithmic 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).

c 2023 Information Processing Society of Japan
⃝

[16]

[17]

[18]

[19]

[20]

[21]
[22]
[23]

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).
TuneWiki, Inc.: Lyric Legend, https://web.archive.
org/web/20110208002254/http://www.lyriclegend.
com/ (2011). 2022 年 9 月 13 日にアクセス (2011 年 2 月
8 日のアーカイブ).
株式会社セガゲームス： Miku Flick-ミクフリック-｜初音ミクが、ついに iPhone に降臨！，https://miku.sega.
jp/flick (2012). 2023 年 7 月 30 日にアクセス.
LyricsTraining.com:
Learn
Languages
withMusic Videos,
Lyrics and Karaoke!,https://lyricstraining.com/ (2011).
2022 年 9 月 13
日にアクセス.
Goto, M., Ogata, J. and Eto, K.: PodCastle: a web 2.0
approach to speech recognition research, Proceedings of
the 8th Annual Conference of the International SpeechCommunication Association, INTERSPEECH ’07, pp.
2397–2400 (2007).
Pavel, A., Reed, C., Hartmann, B. and Agrawala,
M.: Video Digests: A Browsable, Skimmable Format
for Informational Lecture Videos, Proceedings of the27th Annual ACM Symposium on User Interface Software and Technology, UIST ’14, pp. 573–582, DOI:
10.1145/2642918.2647400 (2014).
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).
2023 年 7 月 30 日にアクセス.
Musixmatch s.p.a: Musixmatch Developer API, https://developer.musixmatch.com/ (2022). 2022 年 9 月 13
日にアクセス.
LyricFind Inc.:
Products — Lyric Display ―LyricFind，https://www.lyricfind.com/products/
lyric-display (2023). 2023 年 7 月 30 日にアクセス.
Shamma, D. A., Pardo, B. and Hammond, K. J.: MusicStory: A Personalized Music Video Creator, Proceedings of the 13th Annual ACM International Conference on Multimedia, MM ’05, pp. 563–566, DOI:
10.1145/1101149.1101278 (2005).
Xia, H., Jacobs, J. and Agrawala, M.: Crosscast: Adding
Visuals to Audio Travel Podcasts, Proceedings of the
33rd Annual ACM Symposium on User Interface Software and Technology, UIST ’20, pp. 735–746, DOI:
10.1145/3379337.3415882 (2020).
Lin, J.-C., Wei, W.-L., Lin, Y.-Y., Liu, T.-L. andLiao, H.-Y. M.: Learning From Music to Visual Storytelling of Shots: A Deep Interactive Learning Mechanism, Proceedings of the 28th ACM International Conference on Multimedia, MM ’20, pp. 102–110, DOI:
10.1145/3394171.3413985 (2020).
Pearson, M.: Generative Art: A Practical Guide Using
Processing, Manning Publications Co. (2011).
McLean, A. and Dean, R. T.: The Oxford Handbook of
Algorithmic Music, Oxford University Press (2018).
Reas, C. and Fry, B.: Processing: A Programming
Handbook for Visual Designers and Artists, Second
Edition, The MIT Press (2014).

17

情報処理学会研究報告
IPSJ SIG Technical Report

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

Lieberman, Z., Watson, T. and Castro, A.: openFrameworks, https://openframeworks.cc/ (2022). 2022 年 9月 13 日にアクセス.
Bostock, M., Ogievetsky, V. and Heer, J.: D3: DataDriven Documents, IEEE Transactions on Visualization and Computer Graphics, Vol. 17, No. 12, pp. 2301––2309, DOI: 10.1109/TVCG.2011.185 (2011).
Conlen, M. and Heer, J.: Idyll: A Markup Language
for Authoring and Publishing Interactive Articles on theWeb, Proceedings of the 31st Annual ACM Symposium
on User Interface Software and Technology, UIST ’18,
pp. 977–989, DOI: 10.1145/3242587.3242600 (2018).
Klokmose, C. N., Eagan, J. R., Baader, S., Mackay,
W. and Beaudouin-Lafon, M.: Webstrates: Shareable
Dynamic Media, Proceedings of the 28th Annual ACM
Symposium on User Interface Software & Technology,
UIST ’15, pp. 280–290, DOI: 10.1145/2807442.2807446(2015).
Klokmose, C. N., Remy, C., Kristensen, J. B., Bagge,R., Beaudouin-Lafon, M. and Mackay, W.: Videostrates:
Collaborative, Distributed and Programmable Video
Manipulation, Proceedings of the 32nd Annual ACM
Symposium on User Interface Software and Technology,
UIST ’19, pp. 233–247, DOI: 10.1145/3332165.3347912(2019).
Rädle, R., Nouwens, M., Antonsen, K., Eagan, J. R.
and Klokmose, C. N.: Codestrates: Literate Computing
with Webstrates, Proceedings of the 30th Annual ACM
Symposium on User Interface Software and Technology,
UIST ’17, pp. 715–725, DOI: 10.1145/3126594.3126642(2017).
björk: björk: full biophilia app suite, https://www.
youtube.com/watch?v=dikvJM__zA4 (2011). 2022 年 9月 13 日にアクセス.
Opal Limited:
Brian Eno:
Reﬂection, https://apps.apple.com/us/app/brian-eno-reflection/
id1180524479 (2016). 2022 年 9 月 13 日にアクセス.
Reality Jockey Ltd.: RjDj, https://web.archive.org/
web/20120730133514/http://rjdj.me/ (2012). 2022
年 9 月 13 日にアクセス (2012 年 7 月 30 日のアーカ
イブ).
Paterson, J. and Toulson, R.: Interactive digital music:
enhancing listener engagement with commercial music,
Innovation in Music II (Paterson, J., toulson, R., Hodgson, J. and Hepworth-Sawyer, R., eds.), KES Transactions on Innovation in Music, Vol. 2, Future Technology
Press, pp. 193–209 (2015).
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: 音楽音響信号理解技術とユーザによる誤り訂c 2023 Information Processing Society of Japan
⃝

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

付

正に基づく能動的音楽鑑賞サービス，情処学論， Vol. 54,
No. 4, pp. 1363–1372 (2013).
工 藤 拓： MeCab: Yet Another Part-of-Speech andMorphological Analyzer, https://taku910.github.
io/mecab/ (2013). 2022 年 11 月 11 日にアクセス.
Loper, E. and Bird, S.: NLTK: The Natural Language
Toolkit, Proceedings of the ACL-02 Workshop on Eﬀective Tools and Methodologies for Teaching Natural Language Processing and Computational Linguistics, pp.
63–70, DOI: 10.3115/1118108.1118117 (2002).
ク リ プ ト ン・フ ュ ー チ ャ ー・メ デ ィ ア 株 式 会 社： 初
音 ミ ク「 マ ジ カ ル ミ ラ イ 」ポ ー タ ル サ イ ト ，https://magicalmirai.com/ (2023). 2023 年 7 月 30 日にア
クセス.
クリプトン・フューチャー・メディア株式会社： 初音ミ
ク「マジカルミライ 2020」プログラミング・コンテスト，
https://magicalmirai.com/2020/procon (2020). 2023
年 7 月 30 日にアクセス.
クリプトン・フューチャー・メディア株式会社： 初音ミ
ク「マジカルミライ 2021」プログラミング・コンテスト，
https://magicalmirai.com/2021/procon (2021). 2023
年 7 月 30 日にアクセス.
Myers, B., Hudson, S. E. and Pausch, R.: Past, Present,
and Future of User Interface Software Tools, ACM
Trans. Comput.-Hum. Interact., Vol. 7, No. 1, p. 3–28,
DOI: 10.1145/344949.344959 (2000).
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).

録

A.1 イベント・時刻・時区間駆動型 API
4.2.2 節と 7.1.2 節への補足として，精密な時刻同期が必要なインタラクションデザインを支援する API の 3 類型について，図 A·1とともに説明する．A.1.1 節で紹介する
イベント駆動型は既存手法，A.1.2 節の時刻駆動型は本研
究で提案した設計，A.1.3 節の時区間駆動型は実証実験を踏まえて新たに考案した設計である．

A.1.1 イベント駆動型 (event-driven) API
イベント駆動型 (event-driven) API は，何かが起きたときに「イベント」を発行し，リスナに通知する．この「push」
型の API 設計は，アニメーションが楽曲再生中の特定のタイミングで開始するシンプルなユースケースでは便利である．例えば，ビートのイベントに対応するリスナを実装す
れば，ビートごとに波紋のアニメーションを再生できる．
しかし，4.2.2 節で議論したとおり，これは未来に向けた準備のロジックの設計や，複数の音楽的要素を考慮に

18

情報処理学会研究報告
IPSJ SIG Technical Report

入れた演出のプログラミングがしづらく，時間精度にも自然な表現になっており，A.1.1 節で述べたようなデメリッ

課題がある．さらに，音楽的要素のなかには，再生時刻にトが生じない．例えば，歌詞の単語は発声が始まる時刻か

紐づいたデータであるにもかかわらず，特定のタイミン

ら終わる時刻までの時区間として表現される．ビートはそグで発行されるイベントとして表現しづらいものがある．

の開始時刻から次のビートの開始時刻直前までの時区間とこうした不適合によって，プログラマがリスナを大量になる．その他，連続的に値が変化する声量などの音楽的要書かざるを得なくなるなどのデメリットがある．例えば，

素は，楽曲の再生開始から終了まで続く時区間となる．

表 1に示した音楽的要素の中には，歌詞の単語の発声区
間やコード進行のように特定の時区間を表すものがあり，

A.1.3 時区間駆動型 (time-range-driven) API

これらは onWordEnter と onWordLeave ， onChordEnter と7.1.2 節で，我々はユーザフィードバックとソースコー

onChordLeave のように 2 種類のイベントに分割して表現

ド分析の結果を受けて新たに「時区間駆動型 (time-range-

する必要がある．さらに，時系列で値が変化する声量など

driven) API」を提案した．時刻駆動型 API が指定されたの音楽的要素に関しては， onVocalAmplitudeUpdate のよう

再生時刻と音楽的要素の時区間との重複を探索し，見つなイベントを頻繁に (例えば 10 ミリ秒ごとなどに) 発行しかった最初の音楽的要素を返すのに対して，時区間駆動型

なければ，なめらかな演出をプログラミングできない．

API は指定された時区間との重複があるすべての音楽的要素を探索して返す．典型的なユースケースでは，プログラ

A.1.2 時刻駆動型 (time-driven) API

マは画面を描画するレンダリング関数の中で現在の再生時

4.2.2 節において，我々は「時刻駆動型 (time-driven) API」

刻を保存し，次に関数が呼ばれた際にそれまでに起きたこを提案した．これは，特定の時刻情報を引数に与えて APIとを知るために時区間駆動型 API を呼ぶことができる．

を呼び出せば，そのタイミングに関する時系列データが返時区間駆動型 API の返り値は current ， entered ，そされる「pull」型の設計である．フレームワーク側で，結して left のタプルである．プログラマはこの結果から，果を高速に返せるよう工夫する (例えば，我々の現在の実

entered に含まれる音楽的要素に対応する視覚的要素を初

装では，情報を時刻でソートされたバイナリツリーとして期化し， current に対応する音楽的要素の状態情報を用い保持しておく) 必要はあるが，プログラマが好きなときにて視覚的要素の見た目を更新し，最後に left に対応する

情報を問い合わせられるメリットは大きい．

視覚的要素を破棄する．なお， current は null または

イベント駆動型 API ではデータが特定の時刻と紐づい

単一の音楽的要素であり， entered および left は可変

た個別のイベントとして表現されるのに対し，時刻駆動型

長配列となる．例えば (0, duration) を引数として渡す

API では特定の時区間として表現される．これはデータのと，それぞれに null ，全要素，全要素が格納された結果が返ってくる．

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

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

onBeat...
onBeatonBeat“I”

onBeat(7 イベント )“think”

onWordLeave
onWordEnter
onWordEnter“of”

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

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

イベント駆動型 API ( 典型的な実装 )

ビート
歌詞単語

“I”

“think”“of”

findWord(position)

歌声の声量

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

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

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

findBeatChange(A, B)

B

C

件に加え，図 A·2に他の 3 件のスクリーンショットも示す．
なお，すべてのサンプルコードが GitHub Pages 上にデサイトにアクセスするだけでリリックアプリの振る舞いをすぐ確認できるようになっている．一部のサンプル (イン合開発環境である CodePen 上にコピーされており，プログラマは Web 上でソースコードを編集し，TextAlive App

API の動作を確認できる．
...

...

...

...

...

...

...

...

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

サンプルコード全 11 件の内容を以下にまとめる．図 4の 3

タラクティブ歌詞カードなど) は内容が Web ベースの統

getVocalAmplitude(position)

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

6.1.2 節への補足として，本フレームワークで開発したプロイされ，一般公開されており，プログラマはその Web外的要因で画面が描画できなかった間のビートは無視できる

findBeat(position)

A.2 サンプルコードの詳細

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

c 2023 Information Processing Society of Japan⃝A) インタラクティブ歌詞カード．ビルドツール不使
用，DOM 操作と CSS アニメーションにより視 覚
A で紹介したもの．図 4 ○A，効果を実装．6.1.2 節 ○GitHub:TextAliveJp/textalive-app-lyric-sheet．
B) 歌詞タイル．Parcel でビルド，HTML5 Canvas API
B で紹介したもの．図 4 ○B，で画面描画．6.1.2 節 ○GitHub:TextAliveJp/textalive-app-lyric-tiles．

19

情報処理学会研究報告
IPSJ SIG Technical ReportC) ダンスするリリックアプリ．Parcel でビルド，Three.js
C で紹介したもの．図 4 ○C，で画面描画．6.1.2 節 ○本 サ ン プ ル と ほ ぼ 同 じ 見 た 目 だ が ，Lyric App

Customizer (4.3.2 節) で 配 色 な ど を 調 整 可 能 ．

GitHub:TextAliveJp/textalive-app-dance．
D) 歌詞文字キューブ．Parcel でビルド，Three.js で画

GitHub:TextAliveJp/textalive-app-params．
J)

フ レ ー ズ と ビ ー ト の 同 期 サ ン プ ル ．Parcel で ビ ル

面描画．シンプルなワイヤフレームで描画された立ド ，DOM 操 作 で 視 覚 効 果 を 実 装 ．基 本 サ ン プ ル

方体が画面中央に表れて回転する．各面は発声中のをベースに，発声中のフレーズを表示するように

歌詞テキスト一文字をアニメーションさせながら改変し，ビートと同期した視覚効果が表示される．

表示している．フレームワークと 3D CG 用クリエ

GitHub:TextAliveJp/textalive-app-phrase．

イティブコーディングライブラリの組み合わせでK) フレーズとビートの同期サンプル (script タグ使用)．

D，
もっともシンプルな例として実装された．図 A·2 ○ビルドツール不使用，DOM 操作で視覚効果を実装．

GitHub:TextAliveJp/textalive-app-char-cube．

ひとつ前のサンプルコードと同じ機能と見た目だ

E) 歌詞モザイク．Parcel でビルド，HTML5 Canvas APIが，ビルドツールを使わず，HTML の script タグでで画面描画．発声中の歌詞テキスト一文字がモザイク

TextAlive App API を読み込んでいる．ビルドツー

状のパターンで表示される．内部処理としては，まず，ル不要で，素の HTML/JavaScript/CSS ファイルを

歌詞中のすべての文字が既定サイズのオフスクリーン

テキストエディタなどで編集するだけでリリック

バッファにレンダリングされ，塗りつぶされたピクセ

アプリが開発できることを示すために実装された．

ルの数の順に並び替えられる．次に，ブラウザの画面

GitHub:TextAliveJp/textalive-app-script-tag．

が適切なサイズのタイルを敷き詰めたグリッドに分割される．楽曲再生中は，発声中の歌詞テキスト一文字

A.3 プログラミング・コンテストの応募作品

を画面全体に最大化表示する代わりに，グリッドの各マ

6.2 節への補足として，プログラミング・コンテストのスの濃さに近い文字がランダムに選択されマス内に表

応募作品の多様性を示すため，図 5の 8 作品に加え，さらE ，GitHub:TextAliveJp/textalive示される．図 A·2 ○に 12 作品のスクリーンショットを図 A·3に示した．
なお，これらの 20 作品は，以下の URL から，デモを閲

app-mosaic．
F) p5.js サンプル．Parcel でビルド，p5.js で画面描画．

覧したり実際に試したりできる．

画面中央に p5.js によるキャンバスが表示され，歌詞
テキストのシンプルなアニメーションが表示される．

A.3.1 図 5

著名なクリエイティブコーディングライブラリである1)

https://youtu.be/NqszHM1g9xE

p5.js のシンプルな活用事例として実装された．図 A·2
F ，GitHub:TextAliveJp/textalive-app-p5js．
○

2)

https://youtu.be/z_M1uBCV0tc

3)

https://youtu.be/XzYZr_urn3IG) 基本サンプル．Parcel でビルド，DOM 操作で視覚効

4)https://youtu.be/hvmDxCeyWU8?t=3911

果を実装．画面中央に発声中の歌詞単語が表示される．

5)

https://youtu.be/r26c6Og7r9k

基本的な再生コントロールの他，歌詞の最初の一文字

6)

https://youtu.be/5BlFr6Ma70wの発声が始まる箇所の頭出しができるボタンや，サビ7)

https://youtu.be/_yAlLiIGByIの頭出しができるボタンなどのユーザインタフェース

8)

https://youtu.be/bvRqBNwZBEMが表示される．初学者向けのサンプルとして実装された．GitHub:TextAliveJp/textalive-app-basic．

H) Lottie サンプル．Parcel でビルド，Lottie でアニメーI)

A.3.2 図 A·3
9)https://youtu.be/sYyGA_4YbwM

ションを表示．基本サンプルをベースに，Lottie ファ10) https://youtu.be/vnginTMqg0Y

イルを読み込むことで歌詞テキストの背景に魅力的な

11) https://youtu.be/LiHmw7m5bCs

アニメーションが表示される．Lottie は Adobe After12) https://youtu.be/2dopnxQrWGc

Eﬀects で制作可能なアニメーションのフォーマットで13) https://youtu.be/KQc3FCelKNo

あり，Web プログラマとモーショングラフィックデザ

14) https://youtu.be/hvmDxCeyWU8?t=3859

イナの協業でしばしば使われる．リリックアプリ開発

15) https://youtu.be/10qkhB_NYEw

においても従来のモーショングラフィック用制作ツー16) https://youtu.be/VaCmJWSiNBg

ルを活用可能であることを示すサンプルとして実装さ

17) https://youtu.be/-t9AVVgZo5k?t=3061

れた．GitHub:TextAliveJp/textalive-app-lottie．

18) https://youtu.be/W-Sb5FbnvZI

パ ラ メ タ 調 整 サ ン プ ル ．Parcel で ビ ル ド ，Re-19) https://youtu.be/cs9qxULFARg

act で DOM 操 作 す る こ と で 視 覚 効 果 を 実 装 ．基20) https://youtu.be/hvmDxCeyWU8?t=3802

c 2023 Information Processing Society of Japan⃝20

情報処理学会研究報告
IPSJ SIG Technical ReportD

歌詞文字キューブ

E

歌詞モザイクF

p5.js サンプル

図 A·2: オープンソース公開しているサンプルコード 11 件中 3 件のスクリーンショット．

10 拡張現実アプリ

11

12 制作ツール

13 創造的即興アプリ

14 創造的即興アプリ

15 ゲーム16 ゲーム17 拡張音楽動画

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

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

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

9

拡張現実アプリ制作ツール

図 A·3: 多様な視覚的スタイルとインタラクションデザインを実装したプログラミング・コンテスト応募作品 12 件のスクリーンショット．(スクリーンショット提供: クリプトン・フューチャー・メディア株式会社)c 2023 Information Processing Society of Japan⃝

21