WISS2013

ネイティブ英語発話の日本人風の発音への変換による国際的な意識の促進
西田 健志∗
概要. 日本人は英語での読み書き能力の高さに比べて英語での会話を苦手にする傾向があると言われているが，その大きな障壁の一つにはリスニングやスピーキングにおける発音の問題が挙げられる．相手が話していることが聞き取れないことが会話を練習する大きな障害になるのはもちろんのこと，後天的にネイ
ティブと同等の発音が身に付くことが稀であるにも関わらずネイティブの発音を模倣する練習を繰り返させることが自分の発音への自信を失わせ，英語で話すことを恥ずかしいと感じさせてしまっている面がある．一方で，英語が国際的な場でのコミュニケーションのための言語として位置づけられ，世界中で様々な訛りを持つ英語を話す人が増える中で，自分たちと同じような発音しか受け入れず，訛った英語を話す人を低く見がちなネイティブの態度にも改められるべきところがあると考える．そこで我々は，ネイティブ英語
発話を日本人風の親しみやすい発音に変換することで，日本人の英語に対する心理的な障壁を緩和するとともに，ネイティブに対しては自分の発話よりも訛った発話の方が日本人には通じやすいという体験を通じて意識の改革を促す手法を提案する．本稿では，国際コミュニケーションを支援する様々な他の方法との関係性を議論するとともに，音声認識と TTS を組み合わせて発音の変換を実装した実験用アプリケーションとそれを利用してもらったときの日・米・中の出身者の感想を報告する．

1

はじめに

の訛った英語を聞き取れるように努力するといった歩み寄りの精神が求められるのは当然のことと思われる．
発音に寛容で歩み寄りを心がける人は少なくないが，ネイティブらしくない英語に対する忌避的な反応にも根深いものがある．たとえば，ネイティブ発話と同程度に聞き取れる発話であっても訛りがあると聞き取りにくいと評価される傾向 [1] や，訛った
英語で話す人が様々な差別を受けていること [6] が知られている．非ネイティブも発音の悪さを認識することだけはネイティブ並みにでき，訛った英語やその話者をネイティブと同様に低く評価する傾向があるが，自分と近い発音については比較的寛容であることが知られている [9]．
本研究では，日本人英語話者とネイティブ英語話者の意識ギャップを埋めるためにネイティブの英語
発話を日本人風の訛った英語発話に変換するシステ
ムを利用して，英会話の練習および実践を行うことを提案する．日本人にとっては日本訛りの英語が聞き取りやすい [2] のでリスニングが楽になる分，言いたいことを英語で言うことにより集中することができる可能性がある．また，ネイティブにとっては，
訛った発話の聞き取り練習に利用できるだけでなく，自分の元々の発音よりも訛った英語の方が日本人相手に通じやすいという，先入観が覆される体験を通じて，様々な発音の世界英語に対する寛容性を高めることが期待される．
本稿ではまず，提案手法の応用可能性について議論し，続いて様々な実験ができるように実装したア
プリケーションについて，利用した日本人，英語ネ

高校・大学入試での合格を最優先の目標とする英語教育の結果，文法理解や読解・英作文といった読み書きの能力に比べて，日本人は英会話を苦手にしていると言われている．その反省を踏まえ，ネイティ
ブの英語教師の採用増や小学校からの英会話授業の導入など，会話能力の獲得を中心とした英語教育の改善が議論されている．
英語での会話能力の獲得にあたって特に障害になりやすいのはリスニングや発話における発音の問題である．まず，語彙や文法の知識があったとしても相手が話していることを聞き取ることができなけれ
ば，自分が言いたいことを英語で話す練習をするス
タートラインにつくことすら困難である．また，発音についてはネイティブの発音を模倣する練習を重ねるのが通例となっているが，後天的にネイティブと同等の発音に達するのは例外的な少数の者だけであり，そのような練習を当然のように課すのは自信を失わせて学習意欲を削ぐばかりなので改められるべきだという声もある [2]．
英語をあくまで国際的なコミュニケーションの道具として捉える「国際語としての英語 (English as
an International Language)」の動きやインド英語やシンガポール英語など世界各地でそれぞれの訛りを持った「世界英語 (World English)」を話す人口が増えている現状を鑑みるに，英米などのネイティ
ブからも，相手が聞き取りやすいように話す，相手∗

Copyright is held by the author(s).
神戸大学大学院国際文化学研究科-1-

WISS 2013

イティブ，および中国人の声とともに報告する．さらに広範にわたる関連研究を提案手法との関係性・
利害得失・応用場面の違いの観点から整理し，最後に今後の課題をまとめる．

2の側からも相手に歩み寄るべき余地があることが実感され，様々な発音の世界英語に対する姿勢が改められることが期待される．
もちろん，提案手法はそのような意識改革がなされた後に訛った英語の聞き取りを練習するためにも利用することができる．ネイティブが非ネイティブの発話を聞き取れるようになるという目標は，非ネイティブにネイティブの発音を期待するよりは現実味があると言えるだろう．

考えられる応用例

本稿で提案するネイティブの発話を日本人風の訛った発話に変換する手法には，日本人には聞き取
りやすくなることによる効果およびネイティブには聞き取りにくくなることによる効果を活用した様々な応用が考えられる．

2.1

2.3

ネイティブと会話するための補助

まず，提案手法はリスニングがあまり得意ではな
い日本人が英語ネイティブと会話する際の補助として利用することができる．発音が日本人風に変換されるのを聞くことで，訛った発音で話す気恥ずかしさも軽減されるだろう．具体的には，音声を翻訳するスマートフォンアプリのようにボタンを押してから話すと話し終わった後に変換される利用形態や，補聴器のように自動的に変換を行う利用形態などが想定される．後者のような利用形態を実現するためには発話部分を精度よく自動的に切り出しリアルタ
イムに変換できる必要がある．
自転車の補助輪のように，いずれは補助が無くても会話ができるようになりたい人がまずはネイティ
ブと会話できる楽しさを味わいたいという場合にも利用できるだろう．そのような利用のためには，変換の程度を段階的に減らしていくことができる機能など，補助からの卒業しやすさも考慮することが望
ましいと思われる．

2.2

ネイティブに対するカルチャーショック体験

様々な訛りを持った「世界英語」を話す人口が増
え，TOEIC などの英語能力試験でも様々な発音が出題されるようになる中にあっても訛った発音で話す人を差別してしまうような人に対して，「発音で人を判断するのは良くない」，「訛った英語を聞き取れるように努力すべきだ」などと言葉で意識改革を求めるのには限界がある．
海外へ旅行や留学に行った際に言葉が相手に通じないという体験をすることは国際的な意識改革を促しやすいと思われるが，英語が国際語としての地位を確立しつつあることが影響して，英語ネイティブの中にはそのようなときにも「英語も通じないのか」と責任を相手に求めてしまう人もあるだろう．
英語ネイティブが日本人と話すときに，最初は自分の発音そのままで発話し，その後それを日本人風の発音に変換した音声をお互いに聞こえるように再生することで「元々の発音よりも訛った発音の方が日本人相手には通じやすかった」という体験ができるものと思われる．この体験を通じて，ネイティブ-2-

会議での参加格差の是正

リスニング能力が比較的高い日本人にとっても提案手法が有益と思われる状況としてはネイティブとの会議が挙げられる．たとえばオンラインの音声会
議においてネイティブの発言を日本人風の発音に変換するとネイティブだけが聞き取りに苦労するようになるため，日本人が議論のペースについていきや
すくなり，発言もしやすくなる可能性がある．ただし，このような応用を実現するためにはネイティブからの歩み寄りや平等な参加に対する大きな配慮が必要となるので，まずは日本人が聞く音声だけを日本人風に変換するというセットアップも考えられる．
また，逆に日本人の発話をネイティブ風に変換する手法を組み合わせることで格差をさらに小さくすることも期待できる．これらの応用を実現するためには発音の変換がリアルタイムに行えることが望ましい．

3

実験用アプリケーション

本章では，提案手法の効果を検証する様々な実験を行えるように実装した実験用のアプリケーション
について述べる．
現時点では一区切り話した後に変換した音声を再生するようになっており，2 章で議論した応用例のうち，2.1 節で述べた会話中の補助および 2.2 節で述べたカルチャーショック体験など少人数での利用に対応しているが，2.3 節で述べた会議などの多人数での応用には対応していない．

3.1

発音の変換方法

本アプリケーションでは音声認識プログラムとテキスト読み上げプログラム (text-to-speech; TTS)を用いることで日本人風の発音への変換を行う二つの方法 (図 1，2) を実装した．どちらの方法を用いても普通のノート PC を用いた場合，話し終えた直後に変換後の音声が再生される．音声認識にはWindows に英語の言語パックをインストールすることで利用できるもの，TTS には Microsoft Speech
Platform に含まれるものをそれぞれ利用した．
一つ目の方法は，ネイティブの発話を音声認識して得られた英語テキストを日本語 TTS に読み上げさせることで日本人風の発音に変換する方法である(図 1)．この方法は実装が非常に容易であるが，上ネイティブ英語発話の日本人風の発音への変換による国際的な意識の促進%&'()*!

!"##$%&'$(#)./01*!

!"!"#$

Hello, World

#$"
!!"

'+,-

表 1. 発音記号の変換ルールの例．発音記号の表記には国際発音記号 (IPA) を使用．

*+,.,/0)"

図 1. 変換方法 1: 英語音声認識の出力する英語テキス
トを日本語 TTS に読み上げさせる方法%&'()*!

!"

!"#

!"$

%

!"#

!"$

%

[ɑʌɒ]

a

sun

f

ɸ

fat

ɪ

iː

fit

v

b

vest

[uʊ]

ɯ

foot

θ

s

think

ɛ

e

bed

ð

z

the

ɔ

o

dog

ʧ

ʨ

cheep

r

l

right

ʍ

w

when

6789*!

həlo wɜld!"##$%&
'$(#)

!"

!"

!"#$

!!"

*+,.,/0!"1)"

halo walɯdo
*!+,
-./0
12345

図 2. 変換方法 2: 音声認識の出力する発音記号を文字列置換で変換したものを読み上げさせる方法

述の日本語 TTS を利用することで日本人が各単語をバラバラにカタカナ読みしているような発音に変換することができる．またこの方法では，他言語のTTS を用いることで日本人風以外の様々な訛りの発音に変換することができると思われる．
しかしこの方法は英語を日本語 TTS で読み上げる段階で利用している辞書の影響か冠詞の ”a” を「エイ」，”who” を「ダブリューヘイチオー」と読
むなど，望ましくない変換をしてしまう場合がある．
音声認識でも認識率向上のために辞書が利用される
ため同様の問題が発生しうる．
そこで，二つ目の方法として，音声認識プログラ
ムの出力する発音記号の文字列を文字列置換 (表 1)
によって変換し，変換した発音記号を TTS に指定
して読み上げさせる方法を用意した (図 2)．この方法では TTS の辞書に関わらず発音を変換することが可能である．また，音声認識の辞書にない単語や誤認識された語についても発音レベルで大きく外すことは少ないため，一つ目の方法よりは安定して発音を変換することができると思われる．
こちらの方法のもう１つのメリットとしては，文字列置換のルールを変えることで変換の種類や程度を調節できることが挙げられる．また，日本語 TTS
ではなく英語など他の TTS を利用しても日本人風の発音に変換することができるので，英語ネイティ
ブが日本人風の発音で話しているような音声などを得ることができる．その代わりに日本人風以外の発音に変換したい場合には，それぞれの訛りごとに変換ルールを用意する必要がある．
どちらの方法も TTS を利用しているので話者とは違う声になってしまう欠点がある．

-3-

!"#

!"$

%

ɪr, ɛr, ʊr

ɪa, ɛa, ʊaear!"#$%&'!"()"*+,-./0

s[iɪ]

ʃi

see

&'

()*'

%

o

vest

ɯ

vest

t[iɪ]

ʧi

tip

dt

t[uɯʊ]

ʦɯtoo

bfgklmpsvz

図 3. 実験用アプリケーションのスクリーンショット

3.2

実験用 UI

図 3 は，前節の変換方法を用いて様々な形態の実験ができるように作成した Windows アプリケー
ションのスクリーンショットである．ウィンドウには，変換パラメータの設定 UI（左上），マイク入力
か音声ファイルを指定する UI（左下），音声認識結果の履歴（右）がそれぞれ表示される．

3.2.1

変換パラメータの設定設定できる変換パラメータには，使用する音声認
識と TTS のエンジン，発音変換方法，そして話速度がある．
音声認識と TTS のエンジン 使用する音声認識エンジンを変更することで英語以外の言語を日本人風に変換する実験，TTS エンジンを変更することで様々な発音に変換する実験を行うことができる．

WISS 2013

発音変換方法 チェックボックス ”Japanizer” にチ
ェックを入れると前章の二つの発音変換方法のうち，発音記号の文字列置換を行う方法が使用される．
話速度 話速度の影響を調べることができるよう，全体の話速度を調節するスライダーと単語間を長くするチェックボックス ”Word by word” の二種類の設定を用意した．

3.2.2

4

入力と出力

4.1

音声認識結果の履歴

右側には音声認識結果の履歴が表示されており，カーソルを各結果の上に持って行くことで変換前後の発音記号を確認することができ，クリックすることで発音変換後の音声を再び聞くことができるようになっている．これにより，変換パラメータを変更
しながら様々な発音を聞き比べる実験や，音声認識
結果や発音記号を相手に見せながら会話するなど他の支援方法と比較する実験が可能である．

3.3

関連研究

外国語でのコミュニケーションを支援する方法の研究としては，機械翻訳や通訳者を利用する方法，
音声の変換を利用する方法に加え，その他様々なイ
ンタラクティブシステムによる支援方法がある．本章では提案手法との関係性，利害得失，および応用場面の違いについて議論する．

本アプリケーションはマイク入力によるその場での変換と録音済み wav ファイルの変換に対応している．マイク入力の場合は，マイクボタンを押してから発話が途切れるまでを１単位として認識し，それを変換した結果が直後に再生される．ファイル入力の場合には全体がまとめて認識，再生される．どちらの方法を利用した場合にも，変換前後の音声と認識結果をファイルに保存することができる．

3.2.3

他の訛りへの変換 中国語 TTS を利用して変換した英語音声を聞いてもらったところ，ネイティブ英語教員と中国人留学生のうち 1 人が，中国人の話す英語らしく聞こえると答えたが，日本人風の発音よりは微妙であったためか具体的にそのように感じた
ポイントを指摘した．その同じ音声について日本人大学生からは，かなりネイティブに近く感じられるとの一致した感想が得られた．

利用者の反応

本節では，実験用アプリケーションを日本人大学
生 4 人，日本の大学で英会話の授業を担当しているネイティブ英語教員 1 人，日本の大学への中国人
留学生 3 人に簡単に利用してもらった反応をまとめる．
発音変換の質 日本語 TTS をそのまま利用する一つ目の方法で変換した音声については紛れもなく日本人の話す英語らしく聞こえるが，発音記号を変換する二つ目の方法で変換した音声については，日本人らしく聞こえるものの一つ目の方法と比べるとやや聞き取りづらいことがあるとの反応で一致した．
応用可能性 ネイティブ英語教員から，自身の担当している英会話の授業で利用してみたいとの意見が得られた．自身の経験上，日本人訛りの英語が聞き取りづらいと感じるのは最初だけで，少し慣れれば聞き取りやすい部類に入ると思っているが，その割に英会話の授業などで恥ずかしがって話したがらな
い学生が多いので，そのようなときにこれを利用すると話しやすくなりそうだとの意見をいただいた．

-4-

機械翻訳を利用する方法

互いに使い慣れた言語を共有しない者どうしが意思疎通を図るときにもっとも手軽に利用できる方法のひとつが機械翻訳である．機械翻訳機能を搭載したテキストチャットに関する研究 [12, 11] に加え，
最近では Google 翻訳 [5] や docomo はなして翻訳[3] といった音声を入力すると翻訳後の音声を出力するスマートフォンアプリも登場している．しかし，機械翻訳の精度が向上しているといってもしばしば誤った翻訳をするという問題があり，特にチャットでの砕けた表現や話し言葉に対応することは現状でも容易ではない．
翻訳精度が高い場合にも，ある言語から別の言語へと翻訳された表現とそれを元の言語へ再翻訳した
表現とが一致しないせいで意思疎通が難しくなることが指摘されている [12]．たとえば，相手の使った表現を引用して返事をしたときに元々相手が使っていた表現とは異なる表現に訳されたり，一度お互いに通じると確認しあった表現であっても後にそれを短縮した表現を使ったときに異なる表現に訳された
りするせいで，コミュニケーションの基礎となる表現が安定しないことが問題となる．
機械翻訳を用いる際の問題点を克服するために機械翻訳の使い方を工夫する試みもなされてきた．まず，再翻訳した表現 (back-translation) を表示しながらコミュニケーションを行うとコミュニケーショ
ンが円滑になることが実験により明らかにされている [11]．五十嵐は，機械翻訳が失敗しがちな長く複雑な係り受けがある文章を翻訳する際に，文節の区
切りや係り受け関係を専用の UI を使って入力し，区切られた文節を別々に機械翻訳して視覚化することで伝わりやすくする手法を提案している [13]．
これらの研究に対して本研究は，翻訳を介するのではない新たな歩み寄りの形を提案するものである．
機械翻訳を利用すると相手の話す言語についての知ネイティブ英語発話の日本人風の発音への変換による国際的な意識の促進

識がほとんどなくてもコミュニケーションを取ることができるので便利であるが，いずれは補助を卒業したいと考えている人にとっては提案手法の方が向いているだろう．さらに，提案手法には，ネイティ
ブにカルチャーショック体験を与えて意識改革を促すという機械翻訳では実現できない応用がある．
技術的には，機械翻訳に付き物の翻訳ミスに比べると，発音変換の方が想定外の動作による影響を小さくできる可能性がある．特に音声入力の結果を翻訳する場合には，音声入力での認識エラーと翻訳エ
ラーの２種類のエラーが重なって発生することになるので両者の認識精度が極めて高い必要がある．

4.2

本人風に変換する方が容易である可能性が高いと思
われる．

4.4

人間の通訳を利用する方法

機械翻訳ではなく人間の通訳を利用することで，くだけた表現やその場面の文脈などへのより柔軟な対応が可能になるが，専門の通訳を用意するには高い人的コストがかかり，その場にいる人が対応するにしても高い負担がかかってしまうという問題がある．通訳にかかる負担への対処に関する研究として
は，多言語対面会議において少数派言語の参加者を
他の参加者が協同で支援することで一人一人の支援
負担を軽減する all-for-one 型支援システムが挙げられる [14, 15, 16]．
それに対して本研究で提案するのは，話している
ネイティブ自身による歩み寄りや配慮に期待する方
法である．

4.3

発音の変換を利用する方法

発話の音響的な性質を変換する研究分野で主流となっているのは，声質，つまり誰の声と認識されるかを変換するものであり，それと比べて発話の発音を変換する研究は多くはない [4]．またそのいずれも，訛りを取り除く，適切な抑揚を付加するなどして，ネイティブらしい発話に近づけることを目的としたものである [4]．
訛りを取り除く方法はネイティブに話が通じやすくなるので便利であるが，時代の趨勢に逆行して「美しい発音」への憧れをさらに強くしてしまう恐れがある．それを防ぐためにはあくまで「相手に一番通
じやすい発音」への変換を共通の技術目標として捉え，ネイティブ風への変換と日本人風への変換の両方の研究を進めていくことが適切であろう．
もちろん，ネイティブと非ネイティブがお互いに逆方向の変換を使うという形で組み合わせることもでき，そうした方が非ネイティブの訛りを除去するだ
けの場合よりもより公平な環境になると考えられる．
技術的には，ネイティブらしい発音の英語に対す
る音声認識の精度がかなり高くなっているのに対して，非ネイティブの発話を認識するためには様々な訛りの認識に対応するのが難しい [8] のと同様に，発音の変換についてもネイティブ発音を認識して日-5-

その他のインタラクティブシステムによる支援

単に発話速度が遅くなるように変換したり，音声認識結果を画面に表示するだけでも，リスニングが苦手な人にとっては大きな支援になるものと考えられる．音声訂正 [7] のように音声認識結果を手作業で修正する手法を組み合わせれば，4.1 節で述べた
認識エラーと翻訳エラーが重なる問題も大きく解消されうる．
しかし，これらの方法はどれも利用中の「自分たちは英会話ができない」というネガティブな印象が前面に出てしまいがちなのに対して，提案手法を利用することで「自分たちは訛っているけど英会話はできる」というポジティブさを前面に出すことができるのではないかと考えている．
多人数環境における非ネイティブの支援に着目した研究としては，少人数状況では英語で会話できる
非ネイティブであっても会議では議論の速さについていくことが難しく発言が少なくなりがちであることを改善しようとした研究がある [10]．その研究では，オンライン音声会議でネイティブ同士だけ音声伝達を 0.2-0.4 秒程度遅らせることで非ネイティブに時間的な余裕を与える手法が提案・評価され，確かに非ネイティブが議論に参加しやすくなる効果は認められるものの，発話の開始が重なりやすくなって進行が妨げられるという改善すべき点も確認されている．本研究もこの研究と同様に，ネイティブの側から非ネイティブに配慮することを促すことを重視しているが，より意識されやすい形を採ることで歩み寄りへの意識改革を促すことも狙っている．

5

まとめと今後の課題

本稿では英語ネイティブの発話を日本人風の発音に変換して日本人にとって聞き取りやすくする手法を提案し，日本人のリスニング支援や英語ネイティ
ブへのカルチャーショック体験などの応用可能性を議論した．さらに音声認識と TTS を利用して実装した実験用アプリケーションを異なる母国語を持つ人たちに利用してもらい，初期的なフィードバックを得た．
今後の課題としてはまず，日本人風変換を利用した英語発話の聞き取りおよび会話に対する効果について，より多くのネイティブと日本人が参加する実験により検証することが挙げられる．また，さらなる安定性，話者の声質保持，およびリアルタイムな変換などを実現するため，音声認識や TTS を利用するのではなく，音声信号を直接処理することによって発音を変換する手法を模索する．それらの成果を基にして最終的には，ネイティブに対するカル
チャーショック体験や会議での格差是正など，他の

WISS 2013

応用例についてのシステムを開発し，実証実験を行う計画である．

Japanese students for computer-assisted language learning system. In INTERSPEECH,
2002.
[9] P. Winke, S. Gass, and C. Myford. The Relationship Between Raters’ Prior Language Studyand the Evaluation of Foreign Language Speech
Samples. Technical report, Educational Testing
Service, 2011.
[10] N. Yamashita, A. Echenique, T. Ishida, and
A. Hautasaari. Lost in transmittance: howtransmission lag enhances and deteriorates multilingual collaboration. In Proc. CSCW ’13, pp.
923–934. ACM, 2013.
[11] N. Yamashita, R. Inaba, H. Kuzuoka, and
T. Ishida. Difficulties in establishing common ground in multiparty groups using machinetranslation. In Proc. CHI ’09, pp. 679–688.
ACM, 2009.
[12] N. Yamashita and T. Ishida. Effects of machine translation on collaborative work. In Proc.
CSCW ’06, pp. 515–524. ACM, 2006.

参考文献[1] T. M. Derwing and M. J. Munro. Accent, intelligibility, and comprehensibility: evidence fromfour L1s. Studies in second language acquisition,
19(01):1–16, 1997.
[2] T. M. Derwing and M. J. Munro. Second Language Accent and Pronunciation Teaching: A
Research-Based Approach. TESOL Quarterly,
39(3):379–397, 2005.
[3] N. docomo.
は な し て 翻 訳.
//www.nttdocomo.co.jp/service/communication/hanashite honyaku.

http:[4] D. Felps, H. Bortfeld, and R. Gutierrez-Osuna.
Foreign accent conversion in computer assisted
pronunciation training. Speech Communication,
51(10):920–932, 2009.

[13] 五十嵐 健夫. 文の構造を明示的に指定・表示することによる異言語間コミュニケーション. WISS2011 予稿集.
[14] 吉野 孝, 井出 美奈. All for one 型多言語会議支援システムの構築と評価. 情報処理学会論文誌,
51(1):36–44, 2010.
[15] 宮部 真衣, 吉野 孝. All for one 型対面会議支援システムのためのワークスペースアウェアネスの効果. 電子情報通信学会論文誌. D, 情報・システ
ム, 94(1):27–36, 2011.

[5] Google.
Google Translate.
https://play.google.com/store/apps/details?
id=com.google.android.apps.translate.
[6] M. J. Munro. A Primer on Accent Discrimination in the Canadian Context. TESL Canada
Journal, 20(2):38–51, 2003.
[7] J. Ogata and M. Goto. Speech Repair: Quick
Error Correction Just by Using Selection Operation for Speech Input Interface. In Proc. Eurospeech ’05, pp. 133–136, 2005.
[8] Y. Tsubota, T. Kawahara, and M. Dantsuji.
Recognition and verification of English by[16] 宮部 真衣, 吉野 孝. 多言語対面会議支援システ
ムのための All for one 型支援の効果. 情報処理学会論文誌, 52(1):90–96, 2011.

未来ビジョン

今こそ，まずは研究者コミュニティの中から，非先進地域も結構だがもっと身近な問題にも目を向けるべきだということ，そして言葉の問題に限らずコミュニケーションでは双方が互いに歩み寄るべきだということを示していくべきときである．
理解さえ得ることができればすぐにでも実現できるアイデアは多い．

我々日本の研究者も英語には散々苦い思いをさせられている．論文を読むにも書くにも何倍も時間をかけ，高い金を払って英文添削を受ける．国内の学会で発表された研究に類似した研究を国際学会の査読で見かけても指摘することができない．
「英語で発表しなければ意味がない」と発破をかける声が日本人の中からも常に出てくるが，片方に意思疎通の努力
責任をすべて押し付ける状況にこそ疑うべき点があるのではなかろうか．
奇しくもインタラクティブシステムの分野
では，CHI などの国際会議で文化の相違 (cultural difference) を標榜するセッションが必ずあり，不十分・不安定なインフラや低識字率など様々な問題を抱えた非先進地域に焦点を当てた研究が目立ち始めるなど，他の文化を理解しようという風潮に注目が集まっている．

• 日本の学会で発表された優れた研究を紹介するセッションを国際学会に設ける• 採択決定後に一括で英文添削する• 日本語で投稿と査読を行って，採択が決定してから英訳することを認める

そうしたことを実現していくためには，山下らの研究 [10] や本稿のように英語ネイティ
ブからの歩み寄りを求める研究を積極的に発表し続けることが役に立つと期待している．

-6-

WISS2013

SmartVoice: 言語の壁を超えたプレゼンテーションサポーティングシステム
李翔

暦本 純一∗

概要.
国際的イベントでは, 共通言語での講演が求められることが多い. しかし, 語学力を短期間に向上させることが難しく, 共通言語が母国語ではない講演者にとって負担になる. また, 同時通訳などの方法は,コストが高い上, 講演者本人の発表を聞いているわけではないため, プレゼンテーションの自然さを損なってしまう. 本論文では, 言語の壁を越えてプレゼンテーションを可能にするシステム「SmartVoice」を提案
する. SmartVoice は, 音声データ化した原稿を講演者の口の動きにあわせてスマートに送り出し, 講演者が自分のタイミングで講演できるようにする. 音声のイントネーションや強弱も, 口の位置と形状に基づいて制御するため, まるで講演者本人が直接喋っているように見える. 評価実験を行ない, 本人のプレゼンテー
ションと SmartVoice によるプレゼンテーションがほとんど区別できないことがわかった. SmartVoice のアプリケーションは, 多言語を用いるプレゼンテーションに限らず, 映像に音声・セリフを入れるアフター
レコーディングにも適用可能である. 本論文では, 他分野における SmartVoice の応用についても議論する.

1

はじめに

国際学会などのイベントでは, 共通言語, たとえば英語で講演することが求められる. しかし, 共通
言語が母国語ではない人にとって, それは大きな障壁となる. 仮に原稿を書いて読み上げることにしたとしても, 正しい発音で流暢に聞こえるためには多くの努力を要する.
言語が異なる講演のために, 同時通訳が利用されることがある. しかし同時通訳者を雇うコストや講演者とは異なるタイミングで音声が流れる不自然さなどの問題がある. また講演者の感情や非言語情報を伝達することが困難である. 予めプレゼンテー
ション原稿の音読を録音し, プレゼンテーションの時にそれを再生して口パクする方法もあり得るが,講演者は録音のペースに合わせる講演をすることになり, 講演の自由さが大きく制約されてしまう.
ボイスシンセサイザーを用いることで, 原稿のテ
キストファイルさえあれば, コンピュータがどの言語の単語でも正確な発音で読み上げてくれる. しかし, 文章を朗読する時のイントネーション, 抑揚が単調であり, 聞き疲れするため, 人間の声の代用とすることはできない. 例えば通常の講演では, 大事なところで間を開けて聴衆の注意をひきつける, などが行われるが, ボイスシンセサイザーではこのよ
うな演出をすることは難しい.
本論文では, これらの問題を解決する手段として,「スマートな口パク」に基づくシステムを提案する.
スマートな口パクとは, まず原稿をナレーターに読んでもらうか, ボイスシンセサイザーを利用するか

図 1. SmartVoice によるプレゼンテーション

して音声データにしておき, それを講演者の口の動きに合わせて送り出す方式である. 講演者は自分のタイミングでプレゼンテーションすることができ,
大事なところで間を空けるなど, 語速を自由に制御できるようになる. また, イントネーションや音の強弱などを, 口の位置や形状から制御するようにしている. この結果, 聴衆からすると, 講演者本人が直接喋っているように見え, 同時通訳のような不自然さがない. この方式での講演は, 共通言語でのプレゼンテーションに留まらず, 聴衆に合わせた言語での講演 (たとえば中国で中国語で講演する) にも利用出来る. この, スマートな口パクに基づくシステ
ムを SmartVoice と呼ぶことにする.

2

Copyright is held by the author(s).
∗Xiang Li, 東京大学大学院 学際情報学府 Jun Rekimoto,
東京大学大学院 学際情報学府, ソニーコンピュータサイ
エンス研究所

SmartVoice

SmartVoice は, 再生制御およびピッチ, スピード,
音量のリアルタイム調整をプレゼンターの口の動きとその他表情にマッピングし, 音声が口パクのペース-7-

WISS 2013に合わせて自然に流すシステムである. 言語の壁を越えたスピーチやプレゼンテーションのサポーティ
ングを始めとするさまざまなアプリケーションが考えられる. SmartVoice を用いたプレゼンテーショ
ンの様子を, 図 1 に示す.

2.1

2.2.1

実際に SmartVoice を使ってプレゼンテーション
する時に, ユーザとインタラクションするためにプ
ロンプターを利用している. ユーザがプレゼンター
画面を見て, 常に現在原稿のどこを読んでいるのかを確認することができる. そのために, 音声とテキストは, 正しく対応付けていることが必要である.
SmartVoice は, この対応付けをシステムが半自動的に処理する.
通常の講演では, 呼吸を入れることによって話のテンポを変えたり, 一時停止することがある. なお,
再生中の区切りに対し, 違和感を感じさせないためには, 最低限一つの単語の中での一時停止は避けるべきである. 本システムでは, 原稿テキストをカン
マやピリオドなどのパンクチュエーションを区切りとしてフレーズを抽出し, 音声データについては,
フレーズは音声中に音響レベルが全音声データの平均値の一割以下で持続時間 0.1 秒以上の箇所（以下ミュート区間とする）によって分離された区間とする. 一時停止は, ミュート区間内のみを許可する. ただし, 特に録音の場合, ミュート区間中に, 音響レベ
ルが高いが, 持続時間が極めて短いノイズは存在す
る. これらを見つけ出し, フレーズ抽出プロセスに無視されるよう, ノイズによって分断されるミュート区間が存在しないことを保証するためのアルゴリ
ズムも用意した. (図 2)
原稿と音声の両方からフレーズが抽出されたら,本システムは後述するマッチングプロセスを用いて,原稿テキストと音声データの phrase-to-phrase の対応付けを行う.
プロンプターに表示される原稿テキストは, フレー
ズ単位で音声と対応し, ひとつのフレーズの音声を送り出したら, プロンプター画面には, 自動的に次のフレーズのテキストに切り替わる. 講演者はプロンプ他に表示されるフレーズを「口パク」で読み上げるか, 概ねそのように口を動かすことで音声デー
タが順次送り出されていく.

SmartVoice を用いたプレゼンテーション

実際に SmartVoice を用いたプレゼンテーションの仕方について説明する.
まず, 講演原稿を用意し, それに基づいた音声デー
タを準備する. 音声データは, ユーザ自身もしくは自分以外のナレーターによって原稿を読み上げた録
音か, ボイスシンセサイザーによって自動生成される音声を想定している. 用意した原稿テキストファ
イル（.txt）および音声データをシステムに与えると, SmartVoice は半自動的に原稿と音声のプレー
ズレベルの対応付けを行う. そして音声と正しく対応付けられる原稿中のフレーズは, ハーフミラープ
ロンプターに表示される.
利用者は, 用意した音声データをシステムに与え,顔がカメラ領域に収められ, トラッキングできる状
態で, プロンプター画面を見て, 原稿中のフレーズを口バクすれば, そのフレーズと対応する音声が流れてくる. 一つのフレーズを読み終えて口を閉じると, 再生が止まり, プロンプターには次に読むべきフレーズが強調される. 再び口パクをすると, 今読
むべきフレーズと対応する音声が流れるが, それまでに持続時間任意の一時停止ができる. また, イン
トネーションも前述したように, 口パクのペース, 口の位置と眉毛の位置によってリアルタイムでコントロールできる.

2.2

音声の区切りおよび送り出し制御

SmartVoice におけるスマートな口パク

2.2.2

ピッチ, スピード, 音量の制御

音声データは講演者の口の動きによって送り出されていくが, さらに, そのピッチ, スピード, 音量も講演者の顔情報から制御できるようにした. 例えば,
ボイスシンセサイザー音声データを利用した場合でも, このようにして抑揚や感情表現を講演時に付与することができ, より自然な講演になる.
これらの制御は, 人間が実際に喋っている時の原理を考えて, 方針を決めた. 具体的に, ピッチについて, 頭を下げる時にピッチを下げ, 逆の場合はピッチを上げるようにした (図 3 - b). 次にスピードについて, 口の動きが激しければ激しいほど語速を高く設定する. 最後に, 音量について, 目の開き具合によってコントロールしようとしたが, 今回は眉毛の図 2. 音声と原稿からのフレーズ抽出と対応付け-8-

SmartVoice: 言語の壁を越えたプレゼンテーションさポーティングシステムにすることができる.

3.1.1 顔認識およびフェイストラッキング
SmartVoice は, 常時にプレゼンターの顔の位置,
口の動きおよび表情をトラッキングする. 本システ
ムにおいて, openframeworks[1] 用の Add-on である ofxFaceTracker[2] を用いて, 人間の顔およびその傾きや大きさ, さらには目や鼻, 口, 眉といった顔のそれぞれのパーツの位置や大きさを立体的に検知してトラッキングする. 本システムのプロトタイプ
では, Web カメラ付きノート PC を用いて, カメラから取得したリアルタイム映像からユーザの顔をトラッキングし, 画面にある顔および顔の各パーツの位置, 口の開閉パターンおよびそのペース, 眉毛の位置などを常時に記録し, 表示している.

図 3. (a) 音量のコントロール (b) ピッチのコントロール

Phrase-to-phrase の対応付け
前章で言及したように, 本システムにおいて, 原稿テキストと音声は, フレーズレベルで対応付けられている. この Phrase-to-phrase の対応付けの正しさを保証するために, 本システムの一部として半自動的マッチングツールを導入した.
マッチングツールはまず, 音声データ中のミュート区間を見つけ出し, フレーズを抽出し, 各フレー
ズの再生時間を配列にキャッシュする. 次に, 原稿テ
キストから抽出されたフレーズを, 順番にボイスシ
ンセサイザーにかけて, 生成された一時的音声デー
3.1.2

高さでコントロールすることにした（図 3 - a）. 理
由は後述とする.

3

システム構成本システムは, ホスト側とリモート側の 2 つの部分から構成されている. ホスト側は, ユーザの顔をトラッキングするためのカメラと, 音声を出すためのスピーカーが付いている諸処理を担当するノート
PC からなり, リモート側は, プロンプターとして使われるタブレット PC とプロンプタースタンドからなる. なお, 両部分の間は, 無線 LAN 通信でコミュ
ニケーションを取る.(図 4)

タの再生時間をそれぞれ取得して配列にキャッシュする.
ボイスシンセサイザーによって生成された音声の再生時間は, 語速の違いによって人間のナレーター
によるものと著しく異なる場合があるため, マッチ
ングツールは直接に前述の２つの再生時間の配列をマッチングするではなく, 音声データと原稿テキス
トのそれぞれ各フレーズの再生時間対総再生時間の比をマッチングの対象とする.

図 4. システム構成図

3.1

ホスト側

本システムは, プレゼンターに負担をかけず, より
自然なパフォーマンスを実現するために, 使用中に全ての操作は, 口の動きや表情のみを使い, ハンズフ
リーに行う. プレゼンターは, 再生の一時停止と再開を決めることが可能のほか, 音声のスピード, ピッ
チそして音量をリアルタイムで変えることによって,
ボイスシンセサイザーが生成した音声をより人間的図 5. 自動マッチング結果を示すマッチングツールの画面

マッチングには DP マッチングアルゴリズムを利用している. 図 5 のように, 黄色に塗りつぶされた-9-

WISS 2013

部分は Miss match を表している. Miss match の原因は, 原稿と音声から抽出されたフレーズの総数が一致しないことだと考えられ, 主に２つのケースがある. 一つは, 本来は区切りではないところで音声を止めてしまったため, ミュート区間とされた場
合. もう一つは, ナレーターが原稿中の区切りを無視して続けて喋った場合である. いずれのケースに対しても, 本システムは手動修正をしやすくするための GUI をユーザに提供する.

3.1.3

置が初期状態顔の位置との縦方向の差で計算する.
初期状態より顔を上げれば, ピッチが高くなり, 逆に, 頷くとピッチが低くなる（普通に喋る時に, 頷
くと声帯が圧迫されるため）. 音量の変更について,前章で述べたように, 今回はユーザの目の開き具合にマッピングしている. しかし, 直接目の広き具合を取ると, 変化率が小さいため, 瞼と連動する眉毛の上下位置を採用した. ピッチシフトと似ており,
再生時にユーザの眉毛の位置が初期状態眉毛の位置との縦方向の差で計算し, 初期状態より眉毛を上げれば, 音量が高くなり, 逆の場合は音量が低くなる.
スピード変更については, 再生時に口パクのペースにマッピングしている. 具体的に, 今のフレームと直前のフレームにおいて口の面積の変化率を取って,口の動きが激しければ, スピードを上げ, 逆にゆっ
くりと口を動かすと, スピードを落とす事が可能である.

再生コントロール, 感情表現付け

SmartVoice では, 一時停止の長さはユーザによって, 任意に決めることができる. ミュート区間中に一時停止するたびに, システムはそのミュート区間を丸ごと飛ばすことによって, ユーザが再び口を開くと, 音声がすぐ再生し, ディレイ無くプレゼンテー
ションを再開することが可能である.
前述の通り, ボイスシンセサイザーによるコンピュータボイスは, 自然なイントネーションに乏しく,自然に喋っているように聞こえない. そこで, 本シ
ステムは, 再生時にリアルタイムで音声の音量変更,
ピッチシフト, ピッチを変えずに再生スピードを変えることによって, プレゼンターの感情表現を付けることを可能にした. 音声のダイナミックピッチシ
フトおよびストレッチは, C/C++ベースのマルチプラットフォームで動作するタイム・ピッチマニピュ
レーションライブラリ Dirac3 を用いて実現している. [3] ピッチシフトについては, 0.2 刻みでもとのピッチから上下１半音の変動幅に制限し, ストレッチについては, 0.7 倍速から 1.6 倍速の幅に制限している. 音量について, 初期状態では 70 ％にセットし,再生時に 50 ％から 100 ％までの間で変化すること
ができる.

3.1.4

マッピング

本システムは, プレゼンターをプレゼンテーショ
ンに専念させるために, すべての操作パラメータは,トラッキングされているプレゼンターの顔のパーツにマッピングしている.
再生の一時停止と再開は, ユーザの口の開閉にマッピングする. フレーズ再生後にプレゼンターが口を閉じ, 再び口を開くと, 次のフレーズの再生が開始される. また, 再生途中, つまりミュート区間以外の位置では, ユーザの口の開閉を問わず, 再生し続ける. これによって, 音声がスマートにプレゼンターの口の動きに合わせて流れてくるによって, まるで
本人が喋っているように見えるという本システムのもっとも基本的な目的が実現される.
本システムでは, ピッチ, 音量およびスピードは,再生時リアルタイムに変更を加えることができる.
ピッチシフトについては, ユーザの顔位置にマッピ
ングしている. 具体的に, 再生時にユーザの顔の位

3.2 プレゼンテーション時のインターフェース
3.2.1 プロンプター
本システムにおいて, プレゼンテーション時にユー

ザと実際にインタラクションをとるユーザインター
フェースとして, 原稿を提示するためのプロンプターを設けている. なお, 本システムのプロトタイプ
SmartVoice では, タブレット PC(iPad) をプ ロン
プター画面とし, プロンプタースタンドとしてハーフミラーによるプロンプター台を利用している. ハー
フミラー付きプロンプターを使うことによって, プ
レゼンターは講演会場を自然に見渡しながら原稿を読むことが可能となる.

3.2.2 ホスト側との協同作業
SmartVoice では, リモート側のプロンプターの稼働環境として iPad を採用し, リモート側とホスト側の間は, 無線 LAN 通信を用いてコミュニケー
ションを取っている. その理由は, なるべくプロンプ
ターの機能をシンプルのままに保ち, プレゼンテー
ションできるまでの準備作業は, すべてホスト側で完結可能にしたいと考えているからである. そのために, プロンプターに表示すべき原稿は, ユーザが用意したテキストファイル (.txt) をホスト側プログ
ラムで読み込み, 講演時に無線通信によりリモート
側のプロンプター画面 (iPad) に伝送する.
実際にプレゼンテーションをする際に, ユーザとインタラクションをするのは, プロンプターであるため, ユーザは講演時にはプロンプター画面のみでシステムの挙動を確認できるようになっている. プ
ロンプター画面は, 図 6 - c で示しているように, ホ
スト側でうまく顔を認識しているか否かを, ラベル「DETECTED!」でユーザが知ることができる (認識できてない場合は「???」と表示).

音声と原稿テキストはフレーズレベルで対応付け- 10 -

SmartVoice: 言語の壁を越えたプレゼンテーションさポーティングシステム

ユーザテスト・評価

4

SmartVoice の効果を確認するために, 利用者評
価実験を行った. 通常のスピーチをしている動画と,SmartVoice を用いてスピーチをしている動画とをビデオ編集によって切り替えたものを実験参加者に見てもらい, どの部分が「口パク」（SmartVoice による箇所か）を判定してもらった. 判定結果はマウ
スボタンの押下により入力してもらった. 声色の変化による影響を避けるために, この実験では本人が読み上げた音声を, 本人が SmartVoice によって再生するということにした. 8 名（コンピュータサイ
エンス関係学科の大学院生）が実験に参加した.
図 6. プロンプター画面ているため, プロンプター画面にも, フレーズ単位で原稿をユーザに提示する. 具体的に, プレンゼン
ターが今読んでいるフレーズだけもっとも見えやす
くし, 読み終わったフレーズはスライドアップするようにしている. (図 6 - a)
ピッチや音量の変化のようなすぐに分かる変化と異なり, 本システムを用いてナレーションの再生ス
ピードを変える場合, 現在の再生速度の目安をユー
ザに提示する. プロンプター画面では, 口のイメー
ジ (図 6 - d) が, 喋る速度 (ナレーションの再生速度) に合わせて, 開閉アニメーションの速度が変わる. 一時停止の時は閉じるままである. また前述のように, 本システムにおいてスピードを決めるのは口の面積の変化率であるため, そのメタファとして,
図 6 - b で示す 2 つのバーをプロンプター画面に追加した. この 2 つのバーは, ダイナミックに口の高さと広さを表し, 今取られているパラメータをユー
ザに提示する.

3.3

図 7. 生声原稿読み上げ v.s SmartVoice の実験結果

実験結果を図 7 に示す. それぞれの参加者が SmartVoice によるものと判定した部分を白抜きの矩型で示す. この図から明らかなように, SmartVoice ではない部分も口パクと判断した箇所がある一方で,SmartVoice による部分も本人の生のプレゼンテー
ションだと判断している箇所もある. この実験から,
SmartVoice による音声対応は本人によるプレゼン
テーションと比較しても自然であることがわかった.

性能評価

本システムにおいて, フレーズレベルの音声と原稿テキストとの対応付けは, ホスト側が半自動的にしてくれる. ボイスシンセサイザーが生成するナレーションの場合, パンクチュエーションが遵守されるため, 対応付けは正しく行われる. ところが, 人
声によるナレーションの場合, 時々パンクチュエー
ションを無視したり, フレーズの途中で呼吸を入れたりするナレーションがあるため, 対応付けが乱れることがある. その場合, 本システムがのマッチン
グツールが提供するインタフェースを用いて対応付
けを手動修正することができる.
本システムに使われるノート PC に付いているカ
メラは, 最大解像度 720p で最大 30fps の撮影機能を備えている. 本システム稼働中, プレゼンターによるすべての操作に対し, ホスト側プログラムの FPS
は 55fps を上回っており, ディレイはほとんど感じ
られない.

5
5.1

議論

関連研究

フェイシャルアクションを使って, 何らかの制御にマッピングする前例として, Lyons らによる The
Mouthesizer がある. The Mouthesizer では, ミニ
ヘッドマウント CCD カメラを用いて, 口の中の影領
域をトラッキングし, MIDI のエフェクト付きや楽器の操作などをユーザの口の動きにマッピングしている. [4] また, 口の高さ, 広さの他, 舌の動きと位置も使われている. Lyons らは, 楽器を演奏するミュー
ジシャンに両手以外のコントローラーを与えた点では, The Mouthesizer はフットペダルと同じだが,- 11 -WISS 2013

Mouth コントローラーはペダルより直感的で身に着けやすいことを証明し, フェイシャルアクションによるマシンインターフェイスの可能性も言及した.
[5]SmartVoice はコンセプト上, The Mouthesizerのとシェアするが, 操作中に変わった表情などを取り入れていないため, プレゼンテーション中にユー
ザは自然な状態を保つことができる.
また, 同じくフェイストラッキングを用いるが, 音
声ではなく, リアルタイムで CG キャラクターの表
情を制御する研究もある. [6]5.2

チやプレゼンテーションに限らないはずだ.
例えば, カラオケと類似するプロンプターを有するため, 練習しやすい上, SmartVoice はリアルタイ
ムでピッチシフトとスピード変更もできるため, 音
感・リズム感の悪い人に, ピッチ感覚とリズム感を身に着けさせ, 歌が上手くなることができるかもしれない.
また, 外国語学習者の中で, その言語をできるだ
けネイティブっぽく喋れることを望む人ことが多い.
しかし, 発音やイントネーションを真似して, たくさん練習してそれを自分が喋る時の習慣とするのは結構大変である. 外国語学習者用に SmartVoice にネ
イティブ声との比較機能を付けることによって, ネ
イティブ風のイントネーションを身につけることができるかもしれない. さらにもっと細かな顔筋肉がトラッキングできれば, SmartVoice による発音矯正も不可能ではないと考えている.

ボイスシンセサイザーによるビデオ作品の音
声付け

従来, デモビデオなどにナレーションを入れたい場合, 特にナレーションが母国語ではない時に, 原
稿のテキストファイルを用意し, ボイスシンセサイ
ザーによって音声化する手法がある. しかし, 前述の通り, ボイスシンセサイザーは単語一つ一つをキレイに発音してくれるが, 抑揚に欠くため, 機械的に聞こえる難点がある. 本システムのように, 抑揚やタイミングを人間がコントロールすると, ボイス
シンセサイザーによる声をビデオのナレーション作
成やアニメーションの人声の作成などにも応用できると考えている.

5.3

6

本論文では, 言語の壁を超えたプレゼンテーショ
ンサポーティングシステム「SmartVoice」を提案した. 音声データを分析し, 原稿テキストとフレーズレベルの対応付けを実現することによって, ユーザの口の動きに合わせてスマートに音声を送り出すことを可能にした. また, ボイスシンセサイザーによる機械的なナレーションのイントネーションを, ユー
ザの口の形状・位置によってコントロールすることを実現した. 本システムの効果を検証するために,評価実験を行い, SmartVoice による音声対応は本人によるプレゼンテーションと比較しても顕著な不自然がないことがわかった. 今後, 他の分野における SmartVoice の応用が期待できると考えている.

アドリブの可能性

今まで述べてきたように, 本システムに使われる
音声は, 事前に作っておかないといけない. しかし,プレゼンテーションの場合, 最初から最後まで原稿に準して喋る必要がなく, 途中で雑談を挟むことも考えられる. SmartVoice による音声と生声のスイッチによる違和感を隠蔽し, それを気づかせないようにすれば, SmartVoice と生声の間で自在に切り替
え, プレゼンテーション中のアドリブも可能と考え
ている.

5.4

参考文献
[1] openframeworks.
http://www.openframeworks.cc/

アフターレコーディングの可能性

ドラマや映画の作成は, 撮影と音声はそれぞれ単独に収録し, プロの声優のアフターレコーティングによってセリフを映像に入れるのは一般で的である. 本
システムは, リアルタイムにカメラからキャプチャー
した映像に限らず, 収録済みの映像中のキャラクター
の顔をトラッキングして利用することもできるため,出来上がった映像を見ながらアフターレコーディン
グを行わなくても, SmartVoice を用いれば, タイミ
ング正しく映像に音声を入れることが可能である.

5.5

結論とまとめ[2] ofxFaceTracker.
http://github.com/kylemcdonald/ofxFaceTracker[3] Dirac3L. http://dirac.dspdimension.com/[4] L. Michael J., H. Michael, and T. Nobuji. The
Mouthesizer: A Facial Gesture Musical Interface. In Conference Abstracts, Siggraph 2001,
pp. 230, 2001
[5] L. Michael J., T. Nobuji. Facing the Music:
A Facial Action Controlled Musical Interface.
In Proceedings, CHI 2001, Conference on Human Factors in Computing Systems, pp. 309310, 2001
[6] W. Thibaut, B. Sofien, L. Hao and P. Mark.
Realtime Performance-Based Facial Animation.
In ACM SIGGRAPH 2011 Papers, SIGGRAPH
11, pp. 77:1-77:10, 2011

歌, 外国語練習への応用

繰り返しになるが, SmartVoice は「まるでその人が生で喋っているように見える」のようなシステ
ムの実現が目的である. 広義的な「人間が喋る」という点から, 本システムが支援できるのは, スピー- 12 -WISS2013ࢹ֮ো֐ऀͷͨΊͷࣸਅࡱӨɾӾཡɾ‫ڞ‬༗ΠϯλϑΣʔεઙ઒ ஐ‫ࢠܙ‬‫ ాݪ‬৏ࠤ౻ େհੴ‫ ݪ‬ୢ໵ߴ໦ ‫ܒ‬৳ ∗֓ཁ. ࣸਅ͸ࢹ֮తͳϝσΟΞͰ͸͋Δ΋ͷͷɼଟ͘ͷࢹ֮ো֐ऀ͕‫ه‬࿥΍੖‫ͱऀ؟‬ͷίϛϡχέʔγϣϯखஈͱͯ͠‫ڵ‬ຯΛ͍࣋ͬͯΔ͜ͱ͕໌Β͔ͱͳ͍ͬͯΔɽͦ͜Ͱຊ‫Ͱڀݚ‬͸ࢹ֮ো֐ऀͷχʔζௐࠪͷ݁Ռʹ‫͖ͮج‬ɼࣸਅͱԻ੠ϝϞɾपลԻΛ݁ͼ͚ͭͯ‫ه‬࿥͢Δ͜ͱͰɼඇࢹ֮తͳࡱӨɾӾཡɾ‫ڞ‬༗ΛՄೳʹ͢ΔεϚʔτϑΥϯɾΞϓϦέʔγϣϯ “Accessible Photo Album” (APA) Λ։ൃͨ͠ɽ೔ৗతͳঢ়‫Ͱگ‬ͷධՁͷͨΊɼ5 ਓͷࢹ֮ো֐ऀඃ‫ͱऀݧ࣮͕ऀݧ‬ϖΞͰ֎ग़ͯࣸ͠ਅΛࡱӨͨ͠͏͑Ͱɼผͷ࣮‫ࣸʹऀݧ‬ਅΛઆ໌͢Δͱ͍͏࣮‫ݧ‬Λߦͬͨɽͦͷ݁Ռɼ͢΂ͯͷඃ‫͕ऀݧ‬Ի੠ϝϞͱपลԻΛ‫ࡱͯ͠༻׆‬ӨɾӾཡɾ‫ڞ‬༗Λָ͠Ή͜ͱ͕Ͱ͖ͨɽ

1

͸͡Ίʹ

ࢹ֮ো֐ऀʹͱͬͯࣸਅ͸ຊ࣭తʹΞΫηεࠔ೉ͳϝσΟΞͰ͋Δɽ͔͠͠ɼιʔγϟϧωοτϫʔΫͷී‫ʹٴ‬ΑΓίϛϡχέʔγϣϯखஈͱͯ͠ͷ‫ڵ‬ຯ͕ߴ·͖ͬͯͨ [6]ɽถࠃͰ͸ɼࢹ֮ো֐ऀΛର৅ͱͨࣸ͠ਅ‫ࣨڭ‬΋͢Ͱʹ࣮ࢪ͞Ε͍ͯΔ [14]ɽࢹ֮
ো֐ऀ͕ࣸਅΛࡱӨ͢ΔͨΊʹ͸ɼྫ͑͹ߏਤͷܾఆɾ࿐ग़ɾϒϨ౳ͷ৘ใΛඇࢹ֮తʹͲ͏఻͑Δ͔ɼࡱӨͨࣸ͠ਅΛಠྗͰͲͷΑ͏ʹ؅ཧ͢Δ͔౳ͷٕज़త՝୊͕ࢁੵΈͰ͋Γɼ‫ʹط‬ଟ͘ͷ‫͕ڀݚ‬ใࠂ͞Ε͍ͯΔ [6, 11, 1]ɽ͔͠͠ɼࣸਅΛ‫ڞ‬༗͢ΔΠϯλϑΣʔεͷ‫ڀݚ‬͸ྫ͕ͳ͘ɼզʑ͕࣮ࢪͨ͠ΞϯέʔτௐࠪͰ͸ɼճ౴ऀͷ൒਺Ҏ্͕ɼࣸਅͷ‫ڞ‬༗ʹ໰୊Λ‫[ ͍ͨͯ͡ײ‬5]ɽ
͜ͷϝσΟΞͷΪϟοϓΛຒΊΔͨΊʹ͸ΞΫη
εՄೳͳ৘ใɼྫ͑͹Ի੠Λಉ࣌ʹ‫ه‬࿥͢Δํ๏͕ߟ͑ΒΕΔɽ‫͔͍ͭ͘ʹط‬ͷԻ੠࿥ԻՄೳͳΧϝϥ΍ΧϝϥɾΞϓϦέʔγϣϯ͕࣮༻Խ͞Ε͍ͯΔ[8, 9, 13, 16, 17, 18] ͕ɼ͜ΕΒ͸੖‫ऀ؟‬Λର৅ͱ
͍ͯ͠ΔͨΊΞΫηγϏϦςΟ্ͷଟ͘ͷ໰୊͕͋ΔɽϏσΦͰ୅ସ͢Δํ๏΋ߟ͑ΒΕΔ͕ɼࡱӨ࣌ʹର৅෺΍ਓʹରͯ͠Ұఆ࣌ؒΧϝϥΛ޲͚ଓ͚ͳ
͚Ε͹ͳΒͣɼॠؒతʹࡱӨՄೳͳࣸਅͱൺֱͯ͠
ࠔ೉ͳૢ࡞͕ཁ‫͞ٻ‬ΕΔɽ
ͦ͜Ͱຊ‫Ͱڀݚ‬͸Ի੠ϝϞ෇ࣸਅʹண໨͠ɼࢹ֮
ো֐ऀʹΑΔࡱӨɾӾཡɾ‫ڞ‬༗Λ࣮‫͢ݱ‬ΔͨΊͷεϚʔτϑΥϯɾΞϓϦέʔγϣϯ “Accessible PhotoAlbum”(APA) Λ։ൃͨ͠ɽAPA ͸εΫϦʔϯϦʔμΛ༻͍ͯૢ࡞͢Δ͜ͱ͕Ͱ͖ɼࡱӨ࣌ʹपลԻͱԻ੠ϝϞΛ࿥Ի͢Δ‫ػ‬ೳΛඋ͍͑ͯΔɽAPA Ͱ͸Ӿཡ࣌ʹԻ੠ʹՃ͑ͯ೔෇ɼ࣌ࠁɼGPS ৘ใ΋ඇࢹ֮తʹࢀরՄೳͳͨΊɼࣸਅΛ༰қʹࣝผ͢Δ͜
∗ͱ͕ՄೳͰ͋Γɼ͞ΒͳΔղઆΛՃ͑ͯͷ‫ڞ‬༗͕Մ
ೳͰ͋Δɽຊ࿦จͰ͸ؔ࿈‫ʹڀݚ‬ଓ͍ͯ APA ͷσβΠϯͱ࣮૷Λ঺հ͢Δɽͦͷ‫ޙ‬ɼධՁ࣮‫ͦͱݧ‬ͷ݁Ռʹ͍ͭͯใࠂͨ͠ͷͪʹɼࢹ֮ো֐ऀ͕ಠྗͰ৘ใΛൃ
৴͢Δखஈͱͯ͠ͷՄೳੑʹ͍ͭͯߟ࡯͢Δɽ

2

ؔ࿈‫ڀݚ‬

ࢹ֮ো֐ऀͷؒͰࣸਅࡱӨʹର͢Δ‫ڵ‬ຯ͕ߴ·͍ͬͯΔ [25, 10, 19, 20]ɽJayant ΒͷΞϯέʔτௐ
ࠪ [6] ʹΑΔͱɼΞϯέʔτʹ౴͑ͨ 70%ͷϢʔβ͕͖Ε͍ʹࣸਅΛࡱӨ͢Δ͜ͱʹ‫ڵ‬ຯ͕͋Δͱ౴͑ɼ΄΅ಉ਺͕࠷ۙࣸਅΛࡱӨͨ͜͠ͱ͕͋Δͱ౴͑ͨɽ
ࣸਅͷࣝผʹ͸‫ܞ‬ଳ‫ࣈ఺ܕ‬ϝϞ‫ػ‬Λซ༻ͯࣸ͠ਅΛࡱӨͨ͠ॱংʹ߹Θͤͯઆ໌จΛ‫ه‬࿥͢ΔɼࣸਅͷϑΝΠϧ໊ʹҙຯΛ࣋ͨͤΔ౳ͷํ๏Λͱ͍ͬͯΔɽ

2.1 Ի੠෇͖ࣸਅ
Frohlich ͱ Tallyn ͕ఏҊͨ͠Ի੠෇͖ࣸਅ͸ɼࣸਅͱͦΕʹ෇Ճ͞Εͨ࿥ԻԻ੠Λ 1 ͭͷϝσΟΞͱͨ͠΋ͷͰ͋Δ [3, 4]ɽ͜ͷԻ੠෇͖ࣸਅͷ֓೦͸ɼಛʹࢹ֮ো֐ऀͷͨΊʹߟҊ͞Εͨ΋ͷͰ͸ͳ͍͕ɼࢹ֮ো֐ऀ͕ࣸਅΛࡱӨɾӾཡɾ‫ڞ‬༗͢Δ্Ͱඇৗʹ༗ޮͰ͋Δͱߟ͑ΒΕΔɽ
Ի੠෇ࣸਅΛࡱӨ͢ΔͨΊͷεϚʔτϑΥϯ༻ΞϓϦέʔγϣϯ͸ɼ͢Ͱʹ͍͔࣮ͭ͘༻Խ͞Ε͍ͯΔ͕ [8, 9, 13, 16, 17, 18]ɼΞΫηγϏϦςΟ্ͷଟ͘ͷ՝୊͕͋Δɽྫ͑͹ɼεΫϦʔϯϦʔμ‫ػ‬ೳΛ༻͍Δͱ 1 ຕͷࣸਅΛࡱΔͨΊʹɼ35 ճͷδΣενϟೖྗ͕ඞཁͱͳΔɽ·ͨԻ੠෇ࣸਅΛࡱӨͰ͖ΔΧϝϥ΋ࢢൢ͞Ε͍ͯΔ͕ɼࢹ֮ো֐ऀ͕ૢ࡞Մ
ೳͳ੡඼͸චऀΒͷௐࠪͰ͸‫͔ͭݟ‬Βͳ͔ͬͨɽ

2.2 ࢹ֮ো֐ऀͷͨΊͷࣸਅࡱӨࢧԉiPhone ͷ VoiceOver[15] ΍ Android ͷ TalkBack

Copyright is held by the author(s).
Chieko Asakawa, Susumu Harada, Daisuke Sato, Tatsuya Ishihara, Hironobu Takagi, ೔ຊΞΠɾϏʔɾΤϜ‫ࣜג‬ձࣾ ౦‫ॴڀݚૅجژ‬౳ɼεϚʔτϑΥϯͷΞΫηγϏϦςΟ޲্ʹ൐͍ɼ- 13 -WISS 2013ࢹ֮ো֐ऀ޲͚ͷΞϓϦέʔγϣϯ͕֤छ։ൃ͞Ε
͍ͯΔɽࣸਅؔ࿈Ͱ͸ɼը૾ೝࣝ΍Ϋϥ΢υιʔγϯάΛ༻͍ͯɼࢹ֮ো֐ऀ͕ࡱӨͨࣸ͠ਅͷ಺༰Λೝࣝ͢ΔαʔϏε΋ར༻͕޿͕͍ͬͯΔ [2, 22, 24]ɽ͜ΕΒͷαʔϏεΛར༻͢Δ͜ͱʹΑΓɼϫΠϯɼҿΈ෺ͷ໏ฑɼༀͷछྨɼ༣ศ෺ͷ಺༰౳Λԕִ͔ΒͷαϙʔτʹΑΓ஌Δ͜ͱ͕Ͱ͖ΔɽࣸਅͷϒϨͷ‫ݕ‬ग़ [7]ɼࢹ֮৘ใΛԻ৘ใʹม‫͢׵‬Δٕज़ [23]ɼ
ࣸਅͷϒϨɼ҉͞ɼ܏͖ΛԻ੠Ͱ఻ୡ͢Δ‫[ ڀݚ‬12]౳΋ใࠂ͞Ε͍ͯΔɽ

3

環境音録音中

1 本指
スワイプ

ダブル
タップ

再録音開始

写真撮影
写真削除

メモ録音中

メモ再生中
1 本指
スワイプ

Accessible Photo Album(APA)ࢹ֮ো֐ऀ͕ࣸਅΛࡱӨɾӾཡɾ‫ڞ‬༗͢Δ͜ͱΛ໨తͱͯ͠ APA Λ։ൃͨ͠ɽAPA ͸ҎԼͷ 3 ͭͷํ਑ʹ‫͖ͮج‬ઃ‫ͨ͠ܭ‬ɽ

1 本指
スワイプ

メモ録音
写真保存

タップ &
ホールド

(a)

1. ૉૣ͘ࡱӨ͠ɼԻ੠ϝϞͱपลԻΛ࿥ԻͰ͖前後の写真に移動ΔΑ͏ʹɼඇࢹ֮తͳδΣενϟૢ࡞Λ࠷ద
Խ͢Δ

メモ音声 日付，時間，場所

1 本指
スワイプ

2. Ӿཡ࣌ʹૉૣࣸ͘ਅΛࣝผՄೳʹ͢ΔͨΊʹԻ੠ϝϞͷ࠶ੜΛޮՌతʹऔΓೖΕΔ

フルスクリーン
モードに移動3. ओମతʹ੖‫ࣸͱऀ؟‬ਅΛ‫ڞ‬༗Մೳʹ͢ΔͨΊʹઐ༻ͷϞʔυΛઃ͚ͯΠϯλϑΣʔεΛ࠷
దԽ͢Δ

3.1

メモ音声

環境音

࣮૷

ダブル
タップ
前後の写真に
移動
3 本指
スワイプ
1 本指
スワイプ

APA ͸ iPhone ͷΞϓϦέʔγϣϯͱ࣮ͯ͠૷
͠ɼಡΈ্͛ʹ͸ iOS ෇ଐͷεΫϦʔϯϦʔμͰ͋
Δ VoiceOver Λ༻͍ΔΑ͏ʹઃ‫ͨ͠ܭ‬ɽAPA ͸Χ

写真の付加情報読み上げϝϥϞʔυͱΞϧόϜϞʔυͷೋͭͷϞʔυΛ࣋ͭʢਤ 1ʣɽ‫ى‬ಈ௚‫ʹޙ‬ΧϝϥϞʔυʹભҠ͠पลԻͷ࿥Ի͕։࢝͞Εɼ1 ຊࢦͰԼεϫΠϓ͢Δ͜ͱʹΑΓࣸਅ͕ࡱӨ͞ΕΔɽ1 ຊࢦͰλοϓͯ͠ԡ͠ଓ͚
Δ͜ͱ (λοϓ&ϗʔϧυ) ͰԻ੠ϝϞͷ࿥Ի͕։࢝
͠ɼࢦ͕཭ΕΔ·Ͱͷؒ‫ه‬࿥͢Δ͜ͱ͕Ͱ͖Δɽ࿥
Իऴྃ௚‫ʹޙ‬࿥Իͨ͠Ի੠ϝϞ͕ࣗಈͰ࠶ੜ͞ΕΔɽ
ΞϧόϜϞʔυͰ͸೔෇ผʹιʔτ͞ΕͨࣸਅͷϦετ͕දࣔ͞ΕΔɽϦετؒͷҠಈʹ͸ 1 ຊࢦͰࠨӈεϫΠϓɼ೔෇ؒͷҠಈʹ͸ 1 ຊࢦͰ্Լ
εϫΠϓΛ༻͍Δɽ࣍ͷࣸਅ΁Ҡಈ͢ΔࡍʹɼରԠ
͢ΔԻ੠ϝϞ͕ࣗಈతʹ࠶ੜ͞ΕΔɽ࠶ੜͱಉ࣌ʹࣸਅ͕ࡱӨ͞Εͨ೔࣌ͱҐஔ৘ใ΋Ի੠߹੒ʹΑΓಡΈ্͛ΒΕΔɽҐஔ৘ใʹ͍ͭͯ͸ɼࣸਅ͕อଘ
͞Εͨ࣌఺ͷ GPS ৘ใΛ஍໊ʹม‫ͯ͠׵‬ಡΈ্͛
Δɽ੖‫ࣸͱऀ؟‬ਅΛ‫ڞ‬༗͢Δͱ͖ʹ͸ɼϦετ্ͷࣸਅͷҐஔͰμϒϧλοϓ͢Δ͜ͱͰϑϧεΫϦʔϯදࣔ͢Δ͜ͱ͕Ͱ͖ΔɽϑϧεΫϦʔϯϏϡʔͰ͸ VoiceOver ͷඪ४δΣενϟ‫ػ‬ೳͰ͋Δ 3 ຊࢦͷࠨӈεϫΠϓΛ༻͍ͯࣸਅؒΛҠಈ͢Δ͜ͱ͕Ͱ͖
Δɽ৽͍ࣸ͠ਅ͕දࣔ͞ΕΔͱɼԻ੠ϝϞͷ࠶ੜʹଓ͍ͯɼࣸਅͷ޲͖ (ॎํ޲·ͨ͸ԣํ޲) ͕ಡΈ্- 14 -(b)ਤ 1. (a) ΧϝϥϞʔυͷૢ࡞ํ๏ɼ(b) ΞϧόϜϞʔυͷૢ࡞ํ๏

͛ΒΕΔͷͰɼσόΠεͷํ޲Λओମతʹมߋ͢Δ
͜ͱ͕ՄೳͰ͋Δɽ4Ϣʔβ࣮‫ݧ‬5 ໊ͷࢹ֮ো֐ऀඃ‫ऀݧ‬ͷ‫ʹྗڠ‬ΑΓ APA ͷ༗ޮੑΛධՁͨ͠ɽ࣮‫Ͱݧ‬͸ҎԼͷ 3 ͭͷ఺ʹண໨ͨ͠ɽ
(a) ࣸਅͷࡱӨɼԻ੠ϝϞ΍पลԻͷ࿥ԻΛૉૣ࣮͘ߦͰ͖͔ͨ?
(b) ͦΕͧΕͷࣸਅͷࣝผΛ͠ͳ͕Βɼૉૣ͘ӾཡͰ͖͔ͨ?
(c) ੖‫ʹऀ؟‬ରͯ͠ओମతʹࣸਅΛ‫ڞ‬༗Ͱ͖͔ͨ?
4.1

ඃ‫ऀݧ‬

ඃ‫ऀݧ‬͸ɼஉੑ 3 ໊ɼঁੑ 2 ໊ɼ೥ྸ͸ 25 ࡀ͔Β 36 ࡀ·Ͱͷ 5 ໊ͰɼँྱΛࢧ෷ͬͨ (ද 1)ɽ

ࢹ֮ো֐ऀͷͨΊͷࣸਅࡱӨɾӾཡɾ‫ڞ‬༗ΠϯλϑΣʔεද 1. ඃ‫ऀݧ‬ϓϩϑΟʔϧ.

೥ྸ

P1
P2
P3
P4
P5

25
34
35
34
36

ੑผ
ঁੑ
உੑ
உੑ
ঁੑ
உੑ

ࢹྗ
ऑࢹ
શ໡
શ໡
ऑࢹ
શ໡

ࡱӨ‫ݧܦ‬
༗Γ
ແ͠
ແ͠
༗Γ
༗Γ

‫ڞ‬༗‫ݧܦ‬
༗Γ
༗Γ
ແ͠
༗Γ
༗Γ

4.1.1 ࣸਅࡱӨͷ‫ݧܦ‬P1ɼP4ɼP5 ͸ɼΧϝϥ෇‫ܞ‬ଳి࿩ͰࣸਅΛࡱͬͨ‫͕͋ݧܦ‬Γɼը૾ͷϑΝΠϧ໊Λมߋ͢Δ͜ͱͰࣸਅΛ؅ཧ͍ͯͨ͠ɽP1 ͱ P4 ͸ɼͦͷํ๏ʹൺֱతຬ଍͍͕ͯͨ͠ɼP4 ͸ɼॲཧ͕͋·Γʹ΋୯ௐͰ͋Δ͜ͱ͔Βɼ೔෇΍࣌ࠁͰ؅ཧ͢ΔΑ͏ʹͳΓɼ݁Ռͱͯ͋͠·ΓࣸਅΛࡱΒͳ͘ͳͬͨɽP2 ͱ
P3 ͸ɼ࣮‫ݧ‬తʹࣸਅΛࡱͬͨ‫͕͋ݧܦ‬ΔͷΈͰ͋ΔɽP3 ͸ɼࣗ෼ͷΧϝϥͰ༑ਓʹࣸਅΛࡱͬͯ΋Βͬͨ‫ݧܦ‬͸͋ͬͨɽશͯͷඃ‫͕ऀݧ‬ಠྗͰྑ͍ࣸਅ͕ࡱΕΔ͔Ͳ͏͔ෆ҆Λ͍࣋ͬͯͨɽࡱӨ‫ݧܦ‬ͷ͋Δඃ‫ऀݧ‬΋શһ͕੖‫ऀ؟‬ͷαϙʔτΛಘ͍ͯͨɽ

4.1.2 ࣸਅ‫ڞ‬༗ͷ‫ݧܦ‬P1ɼP4ɼP5 ͸‫ܞ‬ଳి࿩͋Δ͍͸ PC ͔Β e ϝʔϧఴ෇ʹΑΓଞऀͱࣸਅΛ‫ڞ‬༗ͨ͜͠ͱ͕͋ͬͨɽ
P4 ͸ࣸਅΛϒϩάʹ౤ߘͨ͠‫͕ͨͬ͋ݧܦ‬ɽP2 ͸ࣗ෼ͰࣸਅΛࡱͬͨ‫ݧܦ‬͸ͳ͍͕ɼ൴͕‫ڞ‬༗͍ͨࣸ͠ਅΛ༑ਓʹࡱͬͯ΋Β͍ͦͷ৔Ͱ SNS ʹ౤ߘͨ͠‫͕ͨͬ͋ݧܦ‬ɽ

4.2

࣮‫ݧ‬खॱ

࣮‫ݧ‬͸ 1 ਓ 1 ೔ (໿ 8 ࣌ؒ) Ͱߦ͍ɼҎԼͷ 4 ͭͷηογϣϯͰߏ੒͞ΕΔɽ1) ಋೖηογϣϯ

ͨɽ͋Β͔͡ΊܾΊΒΕͨ๚໰஍͸͋ͬͨ΋ͷͷɼ͍ͭҠಈ͢Δ͔ʹ͍ͭͯ͸ɼඃ‫ܾʹऀݧ‬ఆͤͨ͞ɽ
࣌ʹ͸ɼ‫ݩ‬ʑͷಓॱ͔Βେ͖͘֎ΕΔ͜ͱʹͳ͕ͬͨɼඃ‫͕ऀݧ‬ผͷ‫ڵ‬ຯΛ‫ʹ͖ͱ͚ͨͭݟ‬͸ͦΕΛ༏ઌͨ͠ɽ·ͨࣸਅΛࡱΔλΠϛϯά΋൴Βࣗ਎͕ܾ
ఆͰ͖ΔΑ͏ߟྀͨ͠ɽඃ‫ऀݧ‬͸޷͖ͳ৔ॴͰࣗ෼
ࣗ਎ͷࣸਅΛऔͬͯ΋Β͏Α͏࣮‫ʹऀݧ‬ґཔͰ͖Δ
͜ͱͱͨ͠ɽ͜ͷ৔߹ɼ࣮‫͕ࣸऀݧ‬ਅΛࡱΓԻ੠ϝϞ͸ඃ‫͕ऀݧ‬࿥Իͨ͠ɽඃ‫͕ऀݧ‬Χϝϥͷ޲͖Λ߹ΘͤΔखॿ͚Λඞཁͱͨ࣌͠ʹ͸ɼ࣮‫͕ऀݧ‬खॿ͚ΛߦͬͨɽΧϝϥͷ޲͖ΛखͰमਖ਼͢Δલʹɼ·ͣ‫ݴ‬༿Ͱ޲͖ͷमਖ਼Λखॿ͚ͨ͠ɽ͜Ε͸ɼ࣮ࡍʹࣸਅΛऔ͍ͬͯΔͷ͸ඃ‫ࣗऀݧ‬਎Ͱ͋Δͱ‫͡ײ‬ΒΕΔΑ͏ʹߟྀͨͨ͠ΊͰ͋Δɽ3) ࣸਅ‫ڞ‬༗ηογϣϯ
໿ 5 ࣌ؒͷ֎Ͱͷ࣮‫ݧ‬ऴྃ‫ޙ‬ɼඃ‫ऀݧ‬͸‫ʹॴڀݚ‬໭Γɼࣸਅ‫ڞ‬༗ηογϣϯΛߦͬͨɽࣸਅͷࡱӨ‫ݧܦ‬ʹؔ͢Δ؆୯ͳ࣭໰ͷ‫ʹޙ‬ɼඃ‫ऀݧ‬͸‫ऀ࡯؍‬ʢผͷ࣮‫ऀݧ‬ʣͱࡱӨ͖ͯͨࣸ͠ਅΛ‫ڞ‬༗͢ΔͨΊͷηογϣϯΛ࣮ࢪͨ͠ɽඃ‫ऀݧ‬͸ɼࣸਅΛ‫ڞ‬༗͠ͳ͕Βͦͷ೔‫ͱͨ͜͠ݧܦ‬Λ‫ڞʹऀ࡯؍‬༗͢ΔɽԻ੠ϝϞΛଞਓʹฉ͔ΕΔ͜ͱΛͨΊΒͬͨඃ‫͍͕ͨͨऀݧ‬ΊɼඞཁͰ͋Ε͹ΠϠϑΥϯͷ࢖༻ΛೝΊɼඃ‫ऀݧ‬͸‫ʹऀ࡯؍‬ฉ͔͍ͤͨͱࢥͬͨͱ͖ͷΈԻ੠Λ࠶ੜ
Ͱ͖Δ͜ͱͱͨ͠ɽ‫ऀ࡯؍‬͸ඃ‫ࣸͱऀݧ‬ਅΛ‫͕ͳݟ‬Βɼͦͷ೔ͷ‫͍ࣗͯͭʹݧܦ‬༝ʹձ࿩͢ΔΑ͏ࢦࣔ͞Εͨɽඃ‫֎ͱऀݧ‬ग़࣮ͨ͠‫ऀݧ‬΋ɼࣸਅ‫ڞ‬༗ηογϣϯʹಉ੮ͨ͠ɽ‫ऀ࡯؍‬͸ɼඃ‫͕ࣸऀݧ‬ਅʹ͍ͭͯͷઆ໌Λ࢝ΊΔ·Ͱ͸ɼίϝϯτ΍࣭໰Λ଴ͭΑ͏ࢦࣔ͞Εͨɽ͜Ε͸ɼඃ‫͕ऀݧ‬੖‫ऀ؟‬ͷॿ͚ͳ͠ʹɼҰਓͰࣸਅͷࣝผͰ͖Δ͔֬ೝ͢ΔͨΊͰ͋Δɽ
‫ऀ࡯؍‬͸ɼඃ‫͕ࣸऀݧ‬ਅͷࣝผ͕ࠔ೉ͳ࣌ͷΈɼख
ॿ͚͢ΔΑ͏ࢦࣔ͞Εͨɽࣸਅ‫ڞ‬༗ηογϣϯ͸ɼฏ‫ ۉ‬30 ෼લ‫ޙ‬Λཁͨ͠ɽඃ‫ऀݧ‬͸ɼ·ͣචऀΒͷ‫ࣄͯʹॴڀݚ‬લΠϯλ
ϏϡʔɾAPA ͷૢ࡞ํ๏ͷτϨʔχϯάɾ࣮‫ݧ‬खॱͷઆ໌Λड͚ͨɽ͜ͷಋೖηογϣϯ͸ฏ‫ ۉ‬1 ࣌ؒ൒Ͱ͋ͬͨɽ4) ࣮‫ޙݧ‬ͷΠϯλϏϡʔηογϣϯ
1 ೔ͷ࣮‫ݧ‬ͷ࠷‫ʹޙ‬ɼͦͷ೔ͷ‫ݧܦ‬΍ APA ʹؔ2) ࣸਅࡱӨηογϣϯ
ୈ 1 ηογϣϯऴྃ‫ޙ‬ɼඃ‫ऀݧ‬͸࣮‫ࣸʹڞͱऀݧ‬4.3

͢Δඃ‫͔ऀݧ‬ΒͷίϝϯτΛऩूͨ͠ɽ
࣮‫݁ݧ‬Ռ

ͦΕͧΕͷ࣮‫ݧ‬ͷ໨తʹ͍ͭͯɼϢʔβ࣮‫ʹݧ‬ΑΓಘΒΕͨ஌‫ݟ‬Λड़΂ΔɽਅΛࡱΔͨΊ͋Β͔͡Ίඃ‫ڵͱ͍͖ͨߦ͕ऀݧ‬ຯΛࣔͨ͠৔ॴʹग़͔͚ͨɽͦͷͨΊͦΕͧΕͷඃ‫ऀݧ‬͸ҟͳΔ৔ॴͰࣸਅΛࡱӨͨ͠ɽ͜Ε͸Մೳͳ‫ݶ‬Γ೔ৗʹ͍ۙঢ়‫گ‬ՄͰ࣮‫ݧ‬Λߦ͏ͨΊͰ͋Δɽ໨త஍Λܾఆ‫ޙ‬ɼ࣮‫ʹऀݧ‬Αͬͯಓॱ͕֬ఆ͞ΕΔɽ͜Ε͸୯ʹඒ͍͠෩‫͚ͩܠ‬ΛࣸਅʹࡱΔͷͰ͸ͳ͘ɼඃ‫ڵ͕ऀݧ‬ຯΛ࣋ͯΔ΋ͷɼྫ͑͹৮ָͬͯ͠ΊͨΓ௚઀‫͖Ͱݧܦ‬Δ΋ͷʹग़ձ͑ΔΑ͏ߟྀͨͨ͠ΊͰ
͋Δɽ࣮‫ऀݧ‬͸ɼඃ‫ʹऀݧ‬ಉߦ͢Δ͚ͩͰͳ͘ձ࿩
Λ͠ͳ͕Β֤஍఺ΛճΓɼपลͷ‫ڥ؀‬ͷઆ໌Λߦͬ(a) ࣸਅͷࡱӨɼԻ੠ϝϞ΍पลԻͷ࿥ԻΛૉૣ࣮͘ߦͰ͖͔ͨ?
VoiceOver ͷ‫͕ͨͬ͋ݧܦ‬ͷ͸ P3 ͷΈͰ͕͋ͬͨɼଞͷඃ‫ऀݧ‬΋ɼಋೖηογϣϯதʹ APA Λ࢖༻͢ΔͨΊʹඞཁͳ‫ج‬ຊతδΣενϟΛशಘ͢Δ͜
ͱ͕Ͱ͖ͨɽࣸਅࡱӨηογϣϯதʹࡱӨ͞Εͨࣸਅ͸ɼ13 ຕ͔Β 20 ຕͰ͋ͬͨ (ද 2)ɽ
7 ஈ֊ͷϦοΧʔτई౓ʹΑΔΞϯέʔτ݁ՌΛ

- 15 -WISS 2013
ද 2. ࣸਅͷࡱӨ৔ॴͱຕ਺.

P1
P2
P3
P4
P5

৔ॴ
γϣοϐϯάϞʔϧ/ϨδϟʔࢪઃϥϯυϚʔΫλϫʔ/ϨδϟʔࢪઃϫΠϯγϣοϓ/Ϩδϟʔࢪઃ࢙੻/ެԂத՚֗/γϣοϐϯάϞʔϧ

ද 3. Ξϯέʔτ݁Ռ
(1:શͦ͘͏ࢥΘͳ͍ɼ7:શͦ͘͏ࢥ͏)

ຕ਺

17
18
20
13
15

P1 P2 P3 P4 P5ද 3 ʹࣔ͢ɽ
ʮࣸਅͷࡱӨ͸༰қͰ͔͋ͬͨʯͱͷ໰͍ʹରͯ͠ɼ2 ໊ͷඃ‫ ͕ऀݧ‬7 Λɼͦͷଞ͸ 5 Ͱճ౴ͨ͠ɽʮԻ੠ϝϞͷ࿥Ի͸༰қͰ͔͋ͬͨʯͷ໰͍ʹରͯ͠͸ɼ2 ໊͕ 7ɼ2 ໊͕ 6ɼ1 ໊͕ 5 ͱճ౴ͨ͠ɽ‫ܞ‬ଳి࿩ͰࣸਅࡱӨͷ‫ ͕ͨͬ͋ݧܦ‬3 ໊ͷඃ‫ݧ‬ऀʹରͯ͠ɼҎલͷํ๏ͱɼAPA ͱΛൺֱ͠ɼԻ
੠ϝϞͷৄࡉ౓ɼεϐʔυɼ࢖͍΍͢͞ʹ͍ͭͯධՁΛґཔͨ͠ɽͦͷ݁Ռɼ3 ͭͷ߲໨શͯʹରͯ͠ɼશһ͕ APA ͕༏Ε͍ͯΔͱධՁͨ͠ɽ(b) ͦΕͧΕͷࣸਅͷࣝผΛ͠ͳ͕Βɼૉૣ͘Ӿཡ
Ͱ͖͔ͨ?
શͯͷඃ‫͕ऀݧ‬໰୊ແ͘Ӿཡૢ࡞Λߦ͑ɼࡱӨͨࣸ͠ਅΛࣝผ͢Δ͜ͱ͕Ͱ͖ͨɽΞϯέʔτʹ͓͍ͯ΋ʮӾཡ͸؆୯ͩͬͨʯɼ
ʮ໨తͷࣸਅΛ‫͚ͭݟ‬Δ
͜ͱ͕Ͱ͖ͨʯɼ
ʮࡱӨͨ͠ঢ়‫گ‬Λࢥ͍ग़ͤͨʯͱ͍
͏໰͍ʹରͯ͠ɼP2 Λআ͘͢΂ͯͷඃ‫͕ऀݧ‬ɼʮશͦ͘͏ࢥ͏ʯ·ͨ͸ʮͦ͏ࢥ͏ʯͱฦ౴ͨ͠ (ද 3)ɽ
P2 ͚ͩ͸ 2 ຕͷࣸਅΛࠞಉͨͨ͠Ίɼʮ໨తͷࣸਅ
Λ‫͚ͭݟ‬Δ͜ͱ͕Ͱ͖ͨʯͱ͍͏໰͍ʹରͯ͠ʮͲ
ͪΒ͔ͱ͍͏ͱͦ͏ࢥ͏ʯͱฦ౴͍ͯ͠Δɽ͜ͷ 2ຕ͸ɼγʔϯ͕ಉ͡Ͱ 1 ຕ͸࣮‫ͨͬࡱ͕ऀݧ‬ඃ‫ऀݧ‬ͱϥϯυϚʔΫλϫʔͷࣸਅͰ͋Γɼ΋͏Ұํ͸ඃ‫ͨͬࡱ͕ऀݧ‬ϥϯυϚʔΫλϫʔ͚ͩͰ͕͋ͬͨԻ
੠ϝϞ͕΄΅ಉ͡Ͱ͋ͬͨͨΊɼP2 ͸ͦͷ۠ผ͕Ͱ͖ͳ͔ͬͨɽ(c) ੖‫ʹऀ؟‬ରͯ͠ओମతʹࣸਅΛ‫ڞ‬༗Ͱ͖͔ͨ?

7
5
6
3

4
7
7
4

6
5
6
7

7
7
7
7

6
5
5
4

7
7
6

-

-

6
6
7

7
5
6

7
6

7
5

6
7

7
7

7
7

7

6

6

6

7

7

7

7

6

6

6

4

6

6

7

7
6

6
7

6
6

7
7

6
3

6

6

6

7

7

7

7

6

7

4

͍͍ͯͳ͔ͬͨʯͱɼ৽ͨͳൃ‫ݟ‬Λίϝϯτͨ͠ɽP1 ͱ P4 ͸ɼ౰ॳ‫ʹऀ࡯؍‬Ի੠ϝϞΛ‫ڞ‬༗͢Δ͜ͱΛͨΊΒ͍͕ͬͯͨɼ2 ຕͷࣸਅʹ͍ͭͯपลԻΛ‫ڞ‬༗ͨ͠ͱ͜ΖɼͦͷՁ஋ʹ‫ͱ͍ͨ෇ؾ‬ίϝϯτͨ͠ɽ͜ͷͱ͖ͷपลԻ͸ɼ෾ਫͱϒϥεόϯυͷԻͰ͋ͬͨɽ·ͨ P4 ͸ɼपลԻΛར༻͢Ε͹ࢹ֮ো֐ऀͷ༑ਓͱ΋ࣸਅΛ௨ͯ͠‫ݧܦ‬Λ‫ڞ‬༗Ͱ͖Δͱίϝϯτͨ͠ɽ

ʮࣸਅ‫ڞ‬༗ηογϣϯΛओମతʹߦ͏͜ͱ͕Ͱ͖
͔ͨʯͱ͍͏໰͍ʹରͯ͠ɼP2 Λআ͘͢΂ͯͷඃ‫͕ऀݧ‬ɼ
ʮશͦ͘͏ࢥ͏ʯ·ͨ͸ʮͦ͏ࢥ͏ʯͱฦ౴ͨ͠ (ද 3)ɽP2 ͸ɼલड़ͷ 1 ૊ͷࣸਅͷࣝผ͕Ͱ͖ͳ͔ͬͨ͜ͱ͔ΒɼʮͲͪΒͱ΋͍͑ͳ͍ʯͱ౴͑
ͨɽ͜ͷ൑அϛε͕ɼ൴ͷ APA શൠʹؔ͢ΔධՁʹͲͷఔ౓Ө‫ڹ‬Λ‫͔ͨ͠΅ٴ‬Λ൑அ͢Δ͜ͱ͸೉͍͕͠ɼଞͷ͢΂ͯͷࣸਅʹ͍ͭͯ͸ɼ໰୊ແ͘ৄࡉ
Λઆ໌Ͱ͖͍ͯͨɽ

4.4

ࣸਅࡱӨηογϣϯ
ࡱӨ͸ָ͔ͬͨ͠
ࡱӨ͸؆୯ͩͬͨ
ϝϞ࿥Ի͸؆୯ͩͬͨ
ಠྗͰࣸਅΛࡱΓ͍ͨͱࢥ͏Α͏ʹͳͬͨҎલͷํ๏ͱͷൺֱΑΓ؆୯ͩͬͨ
ΑΓૣ͘ϝϞΛ࢒ͤΔ
ΑΓৄࡉͳϝϞΛ࢒ͤΔ
ࣸਅ‫ڞ‬༗ηογϣϯ
Ӿཡ͸؆୯ͩͬͨ
໨తͷࣸਅΛ‫͚ͭݟ‬Δ
͜ͱ͕Ͱ͖ͨ
ࡱӨͨ͠ঢ়‫گ‬Λࢥ͍ग़ͤͨࣸਅΛ‫ͤݟ‬Δ͜ͱ͸ָ͔ͬͨࣸ͠ਅ‫ڞ‬༗ηογϣϯΛ
ओମతʹͰ͖ͨ
࣮‫ݧ‬શମʹ͍ͭͯࣸਅ‫ڞ‬༗͸ָ͍͠ಉ༷ͷΞϓϦΛ࢖ͬͯࣸਅΛ‫ڞ‬༗͍࣮ͨ͠‫ݧ‬લΑΓࣸਅΛࡱΓ͍ͨͱࢥ͏࣮‫ݧ‬લΑΓࣸਅΛ‫ڞ‬༗͍ͨ͠ͱࢥ͏

ओཁͳίϝϯτ
͢΂ͯͷίϝϯτ͸ࢴ໘ͷ੍‫͔ݶ‬Β‫͍ͳ͖Ͱࡌܝ‬ͨΊɼҎԼʹओཁͳ΋ͷΛ঺հ͢Δɽ
P1:ʮԻ੠ϝϞʹΑͬͯɼࣗ෼Ͱࣸਅͷ؅ཧ͕Ͱ͖ΔΑ͏ʹͳͬͨɽ͜Ε͸͢͹Β͍͠ਐาͰ͋Δɽʯ
P4:ʮͱͯ΋ָ͔ͬͨ͠ɽ͏·ࣸ͘ਅ͕ͱΕ͍ͯ
Δ͔Ͳ͏͔ෆ҆ͩͬͨͨΊɼࣸਅ‫ڞ‬༗ʹ͍ͭͯͷָ‫࡯؍‬पลԻͷ༗ޮੑ

P5 ͕த՚֗ͷ໳ͰࡱӨͨࣸ͠ਅΛ‫ڞ‬༗͍ͯͨ͠
࣌ɼपลԻͱͯ͠ਫ͠Ϳ͖͕࠶ੜ͞Εͨɽʮࣗ෼ͷ͙͢ྡͰͩΕ͔͕ਫ͠Ϳ͖Λ͍͋͛ͯͨ͜ͱʹ‫ͮؾ‬- 16 -

ࢹ֮ো֐ऀͷͨΊͷࣸਅࡱӨɾӾཡɾ‫ڞ‬༗ΠϯλϑΣʔε͠͞ͷධՁ͸ 6 ͱ͕ͨ͠ɼͦΕΛআ͚͹ૉ੖Β͍͠‫ͨͬͩݧܦ‬ɽ͜Ε·Ͱ͸ࣗ෼ͷ‫ݧܦ‬Λ‫ݴ‬༿Ͱ͔͠఻
͑ΒΕͳ͔͕ͬͨɼࣸਅΛ࢖͏͜ͱͰࢹ֮తʹ৘ใ͕఻͑ΒΕΔ͜ͱͷָ͠͞Λ஌ͬͨɽ͜Μͳ‫ݧܦ‬͸ॳΊͯͩͬͨɽ
ʯP5:ʮࣸਅ͕දࣔ͞Εͨͱ͖ɼ͙͢ʹͦΕʹ͍ͭͯͷ࿩͕Ͱ͖Δ͜ͱ͸ૉ੖Β͍͠ɽपลԻʹ࿥Ի͞ΕͨपΓͷ੠Λฉ͘ͱɼࣸਅΛ௒͑ͨ৘ใΛಘΔ͜
ͱ͕Ͱ͖ͨͱ‫͡ײ‬ΒΕͯɼͱͯ΋ྑ͍‫ؾ‬෼Ͱ͋Δɽ
ʯ

ߟ࡯

5
5.1

ओମతͳࣸਅ‫ڞ‬༗ԻΛ‫ؚ‬Ίͨৄࡉͳઆ໌͕෇༩Ͱ͖Δͱίϝϯτͨ͠ɽ͔֬ʹԻ੠ϝϞ͸࡞੒͕༰қͰ͋Δͱ͍͏େ͖ͳར
఺͕͋Δ͕ɼςΩετʹ͸ࣸਅͷ‫͕ࡧݕ‬༰қʹͳΔɼ
ωοτϫʔΫ্Ͱ‫ڞ‬༗͢Δͱ͖ʹ‫ط‬ଘαʔϏεͱ਌࿨ੑ͕ߴ͍ͳͲͷར఺͕͋Δɽࠓ‫ޙ‬ɼԻ੠ೝࣝͷར༻΋‫ؚ‬ΊͯςΩετΛԻ੠ϝσΟΞʹऔΓ૊Ήඞཁ͕͋Δɽ
·ͨɼೋਓͷඃ‫͕ऀݧ‬Ի੠ϝϞΛ‫Ͱޙ‬मਖ਼ͯ͠ৄ
ࡉ౓Λ޲্͍ͨ͠ͱίϝϯτͨ͠ɽP5 ͸ɼ‫ऀ࡯؍‬͔ΒͷίϝϯτΛԻ੠ϝϞʹ௥Ճ͢Δ͜ͱͰɼ͞Βʹࣸਅͷճ૝͕༰қʹͳΔͱड़΂͍ͯͨɽ͜ͷΑ͏ʹԻ੠ϝϞͷฤूʹର͢Δχʔζ͸ߴ͘ɼ‫ݕ‬౼ͷඞཁ͕͋Δɽ

APA ͷ໨తͷ 1 ͭ͸ɼࢹ֮ো֐ऀ͕ओମతʹ੖‫ͱऀ؟‬ͷࣸਅ‫ڞ‬༗ΛՄೳʹ͢Δ͜ͱͰ͋ͬͨɽͦͷ఺Ͱ P3 ͸࠷΋ओମతʹɼԋग़΋ަ͑ͯࣸਅ‫ڞ‬༗ηογϣϯΛָ͠ΜͰ͍ͨɽ͋ΔࣸਅΛ‫ͤݟ‬Δલʹɼ·ͣ‫ʹऀ࡯؍‬Ի੠ϝϞ͕ฉ͑͜ͳ͍Α͏ΠϠϑΥϯΛ
૷ண͠ɼ࣍ʹը໘͕‫͍ͳ͑ݟʹऀ࡯؍‬Α͏ iPhoneΛཪฦͨ͠ɽ
ʮଟ෼ࢲ͕ͲΜͳϘτϧΛ‫ۮ‬વΈ͚͔ͭͨ૝૾Ͱ͖ͳ͍ͱࢥ͍·͢Αʯͱ࿩ͨ͠‫ʹޙ‬ɼը໘Λ‫ʹݩ‬໭͠ʮίϯίϧυ‫ܕ‬ͷ΢ΟεΩʔͷϘτϧʯͷࣸਅΛ‫ͨͤݟʹऀ࡯؍‬ɽ͜ͷΑ͏ʹखʹ࣋ͭ͜ͱͷͰ͖ΔσόΠε͔ͩΒͦ͜Մೳͳࢹ֮తԋग़ΛɼͦͷޮՌΛ൑அ͢Δ͜ͱͷͰ͖ͳ͍ࢹ֮ো֐ऀࣗ਎
͕ͱͬͨͱ͍͏఺Ͱ࣮‫ऀݧ‬Βͷ༧૝Λ௒͑ͨߦಈͰ
͋ͬͨɽࠓ‫ޙ‬͸ɼ͜ͷΑ͏ͳ “ԋग़” ΋‫ؚ‬Ίͨࣸਅ‫ڞ‬༗ͷද‫্޲ྗݱ‬Λ໨ࢦͨ͠ΠϯλϑΣʔεͷ޻෉΍஌‫ݟ‬ͷ‫ڞ‬༗͕ඞཁͱͳΔͰ͋Ζ͏ɽ

5.2

ϢʔβΠϯλϑΣʔεͷվળԻ੠ϝϞ΍पลԻΛͲͷλΠϛϯάͰ࿥Ի͢Δ͔
͸ɼAPA ͷΑ͏ͳΞϓϦέʔγϣϯΛઃ‫͢ܭ‬ΔࡍʹॏཁͳཁҼͱͳΔɽ࣮‫ ͨ͠༻࢖ʹݧ‬APA Ͱ͸Ի੠ϝϞͱपลԻΛผʑʹऔΓѻͬͨɽγϟολʔ͕ԡ͞ΕΔ·Ͱͷ “पลԻ” ʹ͸੖‫ʹऀ؟‬ΑΔΧϝϥͷ
޲͖ͷࢦࣔ΍ɼपғͷঢ়‫گ‬આ໌ͳͲͷԻ੠͕‫·ؚ‬Εͯ͠·ͬͨͨΊɼ࣮ࡍʹ͸ࡱӨ‫ޙ‬ͷ “Ի੠ϝϞ” ͷ΄͏͕༗༻Ͱ͋ͬͨɽ
ͦ͜Ͱɼ࣮‫ ʹޙݧ‬APA ͷΠϯλϑΣʔεΛमਖ਼͠ɼγϟολʔલ࿥ԻΛഇࢭ͠ɼγϟολʔ‫ʹޙ‬Ϣʔβࣗ਎͕ “λοϓ&ϗʔϧυ” δΣενϟʹΑΓɼपลԻͱԻ੠ϝϞΛࣗ༝ʹ࿥ԻͰ͖ΔΠϯλϑΣʔεʹվྑͨ͠ɽ͜ͷ৔߹पลԻͱԻ੠ϝϞͷ‫ه‬࿥্ͷҧ͍͸ͳ͘ҰͭͷԻ੠ϑΝΠϧͱͯ͠อଘ͞ΕΔɽ͜ΕʹΑΓγϟολʔΛԡ͢ɼ“λοϓ&ϗʔϧυ”ͰϝϞͱपลԻΛ࿥Ի͢Δͱ͍͏γϯϓϧͳΠϯλϑΣʔεʹมߋ͞Εͨɽ

5.3

Ի੠ϝϞͱςΩετϝϞ

6·ͱΊຊ‫Ͱڀݚ‬͸ࢹ֮ো֐ऀʹΑΔࣸਅͷࡱӨɾӾཡɾ‫ڞ‬༗ΛՄೳʹ͢ΔεϚʔτϑΥϯɾΞϓϦέʔγϣϯ
“Accessible Photo Album”(APA) Λ։ൃ͠ɼධՁ
࣮‫ݧ‬ΛߦͬͨɽAPA Ͱ͸ࣸਅࡱӨͱಉ࣌ʹԻ੠ϝϞ΍पลԻΛ࿥Ի͠ɼӾཡɾ‫ڞ‬༗࣌ʹࣗಈతʹ࠶ੜ͢
Δ͜ͱͰࢹ֮ো֐ऀ͕ಠྗͰࣸਅΛࣝผ͠‫ڞ‬༗͢Δ͜ͱ͕ՄೳʹͳΔɽ࣮‫ݧ‬ͷ݁Ռɼ੖‫ͯͬ͋Ͱͱऀ؟‬΋ओମతʹࣸਅͷ‫ڞ‬༗͕ՄೳʹͳΔ͚ͩͰͳ͘ɼಠ
ࣗͷԋग़ද‫Ͱ·ݱ‬΋ՄೳʹͳΔ͜ͱΛ‫͖ͨͰ࡯؍‬ɽࣸਅ‫ڞ‬༗͸੖‫֮ࢹ͘ͳͰ͚ͩऀ؟‬ো֐ऀʹͱͬͯ΋Ձ஋͕͋Δ‫׆‬ಈʹͳΔ͜ͱ͕͜ͷ࣮‫Ͱݧ‬΋ཪ෇͚Δ
͜ͱ͕Ͱ͖ͨɽ
ࠓ‫ޙ‬ɼΑΓ๛͔ͳࣸਅମ‫ݧ‬Λࢹ֮ো֐ऀʹఏ‫ڙ‬͢ΔͨΊʹ͸ϝσΟΞͷΪϟοϓΛຒΊΔͨΊʹϝλσʔλͷ֦େ͕ॏཁͳ՝୊ͷҰͭͱͳΔɽྫ͑͹Ϣʔβ͕ࣨ಺ɾ֎Ͳ͜ʹ͍Δ͔ɼҐஔ৘ใɼίϯύεɼσʔλϕʔεΛ૊Έ߹Θͤͯࣸਅʹ͍ࣸͬͯΔ‫ݐ‬෺ͷৄࡉͳղઆͳͲ͕෇༩Ͱ͖ΔͰ͋Ζ͏ɽ͞ΒʹΫϥ΢υιʔγϯάͷΞϓϩʔνʹΑΓࣸਅͷৄࡉͳઆ໌Λ෇Ճ͢Δ͜ͱ΋Մೳʹͳ͖͍ͬͯͯΔɽࣸਅ͸ʮιʔγϟϧϝσΟΞ࣌୅ͷ৽ͨͳ‫͋Ͱޠݴ‬Δʯͱ΋‫ݴ‬ΘΕΔ΄Ͳɼͦͷॏཁੑ͕ߴ·͍ͬͯΔɽ
ࢹ֮ো֐ऀ΋ͦͷΑ͏ͳ࣌୅ʹಠࣗͷํ๏࿦Λ஝ੵͯ͠ίϛϡχςΟࢀՃͰ͖ΔΑ͏ʹ͢ΔͨΊͷٕज़։ൃ͕ࠓ‫ޙ‬΋ඞཁͱͳΔͰ͋Ζ͏ɽࢀߟจ‫ݙ‬[1] Baber, C., Cross, J., Khaleel, T., and Beale,
R. Location-based photography as sense-making.
P roc. BCS-HCI 2008, British Computer Society(2008), 133–140.
[2] Bigham, J.P., Jayant, C., Ji, H., et al. VizWiz:
nearly real-time answers to visual questions.
P roc. UIST 2010, ACM (2010), 333–342.
[3] Frohlich, D. and Tallyn, E. Audiophotography:
practice and prospects. E xt. Abstracts 1999,
ACM (1999), 296–297.

͜Ε·ͰࣸਅʹςΩετͰίϝϯτΛ͚͍ͭͯͨ
ඃ‫ऀݧ‬΋ɼԻ੠ϝϞ͸؆୯ʹɼૉૣ͘ɼͦͯ͠पล

- 17 -WISS 2013

[4] Frohlich, D.M. Audiophotography: Bringing photos to life with sounds. Kluwer Academic Pub,
2004.
[5] Harada, S., Sato, D., Adams, D. W., Kurniawan,S., Takagi, H., and Asakawa, C. Accessible photo
album: enhancing the photo sharing experiencefor people with visual impairment. P roc. CHI
2013, ACM (2013), 2127–2136.

[13] Luo Xu. Speature. http://itunes.apple.com/us/
app/speature/id401887412.
[14] Blind with Camera School of Photography.
http://www.blindwithcameraschool.org/.
[15] Apple - Accessibility - iOS - Voiceover. http://
www.apple.com/accessibility/ios/voiceover/.
[16] StoryMark Life.
http://www.storymarklife.com/.

[6] Jayant, C., Ji, H., White, S., and Bigham, J.P.
Supporting blind photography. P roc. ASSETS
2011, ACM (2011), 203–210.

[17] Voicepic. http://voicepic.me/.
[18] Storyrobe. http://storyrobe.com.

[7] Ko, J. and Kim, C. Low cost blur image detectionand estimation for mobile devices. P roc. ICACT
2009, IEEE Press (2009), 1605–1610.

[19] Photos by Blind Photographers - Photo
Essays - TIME. http://www.time.com/time/
photogallery/0,29307,1897093 1883579,00.html.

[8] Many Ltd. Picle. http://www.picleapp.com/.
[9] Robinson, S. Com-Phone Story Maker.
https://play.google.com/store/apps/
details?id=ac.robinson.mediaphone.
[10] UCR/California Museum of Photography. Sight
Unseen. http://www.cmp.ucr.edu/exhibitions/sightunseen/.

[20] Seeing Beyond Sight: Photographs by Blind
Teenagers. Book, video & TED Talk.
http://www.seeingbeyondsight.org/home/.

[11] Vazquez, M. and Steinfeld, A. Helping visually
impaired users properly aim a camera. P roc. ASSETS 2012, ACM (2012), 95–102.

[23] Seeing with Sound - The vOICe.
http://www.seeingwithsound.com/.

[12] White, S., Ji, H., and Bigham, J.P. EasySnap:
real-time audio feedback for blind photography.
P roc. UIST 2010, ACM (2010), 409–410.

[25] ҏ౻ ๜໌ɽ ࣣॏɼޫΛ͋Γ͕ͱ͏ɽՏग़ॻ๪৽
ࣾɼ2000[21] Blind With Camera.
http://www.blindwithcamera.org/.
[22] oMoby. http://www.iqengines.com/omoby/.

[24] TapTapSee. http://www.taptapseeapp.com/.

ະདྷϏδϣϯ
APA Λ༻͍ͯ࡞੒͞ΕͨԻ੠৘ใ‫܈‬Λ‫ڞ‬༗͢Δ͜ͱͰɼଞͷࢹ֮ো֐ऀͷ‫ݧܦ‬Λָ͠ΉϝσΟΞͱͯ͠ར༻Ͱ͖ΔՄೳੑ͕͋ΔɽϢʔβࣗ਎͕Ի੠৘ใΛࣸਅɾ஍ཧ৘ใͱ͋ΘͤͯιʔγϟϧωοτϫʔΫ্Ͱ‫ڞ‬༗͢Δ͜ͱͰɼࢹ֮ো֐ऀࣗ਎ͷखͰιʔγϟϧͳΦʔσΟΦσʔλϕʔεΛ࡞Γग़͢͜ͱ͕Ͱ͖Δɽ͜ͷΞϓϩʔνΛδΦϘΠελάͱ‫͢ͱͱ͜Ϳݺ‬Δɽྨࣅͨ͠αʔϏε͸͜Ε·Ͱ΋༷ʑͳ৔໘Ͱ
ٞ࿦͞Ε͖ͯͨɽ͔͠͠ɼςΩετλά΍ϑΥ
τλάͱൺֱͯ͋͠·Γ஫໨͞Ε͍ͯͳ͍ɽཧ
༝ͷҰͭ͸δΦϘΠελάΛར༻ͨ͠ΞϓϦέʔγϣϯ͕‫ݶ‬ΒΕΔͨΊͰ͋Ζ͏ɽࢹ֮ো֐
ऀʹͱͬͯ͸ঢ়‫͕گ‬ҟͳΔɽྫ͑͹ࢹ֮ো֐ऀ
͕੖‫ऀ؟‬ͷ༑ਓͱδΦϘΠελάΛฉ͖ͳ͕- 18 -

Βา͚͹ɼࢹ֮తʹ͸ಘΒΕͳ͍पล৘ใΛ
֫ಘ͢Δ͜ͱ͕Ͱ͖ɼΑΓର౳ͳཱ৔͔Βձ࿩Λָ͠Ή͜ͱ͕Ͱ͖Δɽ੖‫ऀ؟‬͸ҙਤతʹपล৘ใͷઆ໌Λ͢Δඞཁ͕ͳ͘ͳΓɼࢹ֮ো֐ऀ͸Ϩετϥϯ΍γϣοϓͷ৘ใɼͦΕΒͷධ൑ʹ͍ͭͯ΋ओମతʹձ࿩ΛϦʔυͰ͖Δ
Α͏ʹͳΔɽࢹ֮ো֐ऀ͕ҰਓͰ֗தΛา͘৔߹ͷφϏήʔγϣϯαϙʔτͷՄೳੑ΋͋Δɽ
͜ͷγφϦΦ࣮‫ʹݱ‬͸पลԻΛ๦͛ͳ͍ͰϘΠελάΛఏࣔ͢Δඞཁ͕͋Δɽࢹ֮ো֐ऀ
͸௨ৗɼंͷԻΛ͸͡Ίͱͨ͠पลԻΛԻ੠ϥϯυϚʔΫͱͯ֗͠தΛҠಈ͢ΔͨΊͰ͋Δɽ‫ڞ‬༗αʔϏεࣗମͷσβΠϯͱฒߦͯ͠ɼ࢖
༻ঢ়‫گ‬Λߟྀͨ͠ΠϯλϑΣʔε΍ɼιʔγϟϧϝσΟΞ্ͷ৘ใͱͷ༥߹ɼߴྸऀ౳ͷଞͷϢʔβ૚ʹ޲͚ͨϢʔεέʔεͳͲΛ‫ݕ‬౼͢
Δඞཁ͕͋ΔɽWISS2013

個人的な小さな幸せを実現するブラウザ上での動画編集・共有手法
中村 聡史∗

石川 直樹†

渡邊 恵太‡

概要. ニコニコ動画では，動画を一緒に楽しむだけではなく，もともとある動画をもとに，それを改良し，さらなる動画とする N 次創作がそのコミュニティの一体感と，動画の再発掘に有効に働いている．しかし，こうした N 次創作はある程度の創作が前提となっているものであり，例えば音量の変更や，音楽の変更や，部分的な音声の差し替え，音声の追加といった事だけでは創作とはなりえないものである．そうしたちょっとした編集だけを行った動画をアップロードすると，パクリとなじられるであろう．本研究では，そうした
微細な編集によって個人的な満足感を達成可能とするだけでなく，その編集を共有することで新たな動画視
聴体験を可能とする仕組みを実現する．ここでは，「ブラウザ中で視聴中の動画に対する音量増減や音声の付与などの編集手法」と「付与された動画の共有手法」を実現とする．これにより，部分的に音量を調整したり，音楽を差し替えたり，音声を足したり，部分的にスロー再生やスキップしたいなど個人的な嗜好に基づく動画編集および視聴を可能とする．

1

はじめに

YouTube1 やニコニコ動画2 に代表される動画共有
ウェブサイトが爆発的に成長している．YouTube では 2012 年 1 月時点で 1 秒あたりに動画長にして 1

時間分の動画が投稿され3 ている．また，ニコニコ動画でも，2012 年 11 月 20 日の中村らの調査 [1] によると，1 日あたりに約 5500 本の動画が，1 秒あたりに動画長にして約 47 秒分の動画が投稿されている．YouTube は 2012 年 1 月の時点で 1 日に 40 億
視聴，ニコニコ動画では 2012 年第 2 四半期に 1 日
あたり 1 億視聴，平均視聴者数は 786 万人で，ユーザの平均視聴時間は 102.5 分であるという4 ．
ニコニコ動画では，先人が創作した動画を活かし，新たな動画を創作するという N 次創作 [2, 3] が多く見られる．N 次創作では，元々VOCALOID などで作成および投稿された音楽に対して，それにマッチする映像を付けてさらにアップロードしたり，ピアノなどで曲を弾き直してみたり，曲はそのままに歌を自分が歌ったもので差し替えてみたり，踊りを考えて音楽に合わせて踊ってみたりなど，多様な発展が見られる．こうした N 次創作は，ニコニコ動画を発展させ，コンテンツをより良い物へと高めるとともに，愛されるコンテンツを生み出している理由の一つでもある．
Copyright is held by the author(s).
明治大学 総合数理学部, JST CREST†
東京農工大学 工学部‡
明治大学 総合数理学部, JST CREST
1
http://www.youtube.com/
2
http://www.nicovide.jp/
3
http://jp.techcrunch.com/archives/20120123youtubereaches-4-billion-views-per-day/4
http://dic.nicovideo.jp/a/ニコニコ動画∗

ここで，ニコニコ動画で N 次創作に参加するハードルについて考える．オリジナルのコンテンツに対して「歌ってみた」「演奏してみた」「踊ってみた」などタグが付けられているような動画は N 次創作の 1 つである．ちなみに，2013 年 8 月 29 日時点で，
ニコニコ動画上で「歌ってみた」で検索される動画
は 691,641 件，「演奏してみた」動画は 166,800 件，「踊ってみた」動画は 100,078 件ある．YouTube で「歌ってみた」で検索される動画は約 904,000 件，「演
奏してみた」動画は約 586,000 件，「踊ってみた」動
画は約 540,000 件ある．なお，海外での「歌ってみた」に相当する（吹き替えも含まれる）「Fandub」
で検索すると，その件数は約 1,960,000 件となる．
N 次創作は，オリジナルとなるコンテンツ（動画）を改良するものであるため，参入障壁は，コンテン
ツを最初から作成するよりは低いように感じられる．
しかし，この「歌う」「演奏する」「踊る」という事であっても技量が要求され，ハードルが高いといえる．さらに，アレンジする場合は，その技術力も必要となる．映像をつけるのも同様のハードルの高さが存在するであろう．結果として，N 次創作は行われているものの，そこに参入しているユーザの総数は限られる．また，動画編集ソフトウェアを用いた動画編集や，動画のエンコード，動画のアップロードなどにも障壁は存在する．
ここで，ユーザが動画を視聴している際に，その動画に対して微妙に編集したいと思うことがある．
例えば，ユーザが気に入っている楽曲動画なのだけれ
ど，音量が終盤でフェードアウトしておらず，ぷつっと切れてしまうためフェードアウトさせたいと感じることや，作業用 BGM として音楽のメドレーを聴いている際に，ある曲だけは苦手なのでスキップしたいと感じることなどもある．それ以外にも，折角- 19 -WISS 2013

図 1. （左）調味料をたさずにそのまま食べる（右）調
味料を足して自分好みに調整し食べるの素晴らしい演奏動画なのだけれど普通に終わってしまうため拍手や歓声などを入れたいなどと感じる
ことや，映像自体は好みなのだけれど BGM があまり好きなタイプではないため，BGM を差し替えたいなど様々である．しかし，仮に高価な動画編集ソフトウェアをもっており，編集能力が高いユーザであったとしても，他者が投稿した動画をダウンロー
ドし，音量を微調整だけしたり，部分的に音を追加したり，部分的にスキップしたりといった，微細な変更だけでアップロードするということは世の中から N 次創作として許容されるとは考えにくい．そうした動画をアップロードすると，他の視聴者から「パクリ」と糾弾されてしまうこともあるであろう．
そこで我々は，上記のような編集を，オリジナルの動画に手を加えるのではなく，システムによって再生している動画自体をコントロールすることによってコンテンツを個人化する手法を提案および実装する．また，他者と共有可能にすることによって，編集も 1 つのコンテンツとして楽しむことが可能な仕組みを実現する．これは，ラーメン屋などにラーメンを食べに行った時に，自分の好みに合うように調味料を足すことに似ている（図 1）．
本提案手法によって，N 次創作とは違う，よりカ
ジュアルに動画と係ることが可能な N 次装飾とも言える一つの動画の楽しみ方を提供する．

2

ブラウザ上でのカジュアルな編集と個人化

ここで，オリジナリティとクオリティが高い楽曲
や映像の動画があり，多くの人から評価されているが，ユーザ個人としては「微妙に気持ち悪いから修正して欲しい」とか，「もう少しこうであったら良いのに」などと感じることがある．実際，そうしたコ
メントはニコニコ動画中のコメントで現れていることも多く，不満コメントに対し「あなたが作りなおしてアップロードしたら良いじゃないか」という旨のコメントが付くことも珍しくない．不満を述べるだけというのは実際生産的ではないが，元々の動画の投稿者以外のユーザが，その高い品質の動画をダウンロードし，ユーザの個人的な好みに合わせて微調整だけした動画をアップロードするというのは，
N 次創作とは言いがたいものであり，他者からも受け入れられないであろう．
ここで，ユーザ自身がもつ，個人のための動画編
集のニーズを調べるため，ニコニコ動画や YouTubeなどに投稿されている不満や要求に対するコメント
を分類および整理し，ピックアップすると下記の通りとなる．

• 動画自体は質の高い映像コンテンツではあるものの，音楽が好みのものではないうえ，ユー
ザとしては映像と音楽が合っていないように感じている．そこで，映像はそのままに，音楽だけ好みのものに変更したい．

• ユーザが楽しんでいたストーリー性のある動画において爆発音が入っていたが，その爆発音の部分が好みに合わなかったため，他の爆発音と差し替えたい．

• N 次創作として「歌ってみた」や「演奏してみた」「踊ってみた」という動画は，オリジナルの同一楽曲を元に，各投稿者が歌ったり，演奏したり，踊ってみたりしたものである．このそれぞれの動画について，踊ってみた動画の映像と歌ってみた動画の音声を組み合わせ
たり，歌ってみた動画の音声とオリジナル動画の映像を組み合わせたり，ギターで演奏している動画とピアノで演奏している動画を組み合わせたりしたい．

• 作業用 BGM とタグ付けられている動画は，複数の楽曲をセットとして 1 動画とされていニコニコ動画に見られる N 次創作は，その創作のもととなるオリジナルのコンテンツに敬意を払いながら，利用するという点でとても良いコンテンツ
生態系を作り出していると言える．しかし，動画の作成者（N 次創作の作成者も含む）は，動画の視聴者数に比べたら圧倒的に少ない．これは，ニコニコ
動画自体にアップロードされている動画の平均的な質が高いために，気後れしてしまっているという点もあるが，そもそも動画作成および N 次創作のハードルの高さも原因の 1 つでもある．

るものであり，ユーザはこの動画を再生するだけで複数の楽曲を連続的に楽しむことができる．その楽曲の一部が気に入らないのでスキップしたり，ある曲だけ音量が低すぎてバランスが悪いため，その楽曲部分のみ音量を調整したい．

• 研究に関するデモビデオが無音であり面白みにかけていた．そこで，そのビデオに追加音
声や，音楽を付けて面白くしたい．

- 20 -

個人的な小さな幸せを実現するブラウザ上での動画編集・共有手法• ある素晴らしい出来の動画があるが，音声がついていない．みんなで音声を持ちよって，この無声動画に音を付与したい．

上記のニーズは一部に過ぎないが，その多くはオリジナリティがあるとは言いがたく，独自に動画を投稿した時に許容されるかどうかは怪しい．つまり，上記のニーズを満たすには，動画として再編集およびアップロードするのではなく，個々の編集情報だけを記録し，その編集記録を元に動画を視聴可能な仕組みの実現が必要となる．我々は，こうした動画の個人化（自身の好みに変更すること）をブラウザ上で実現可能とし，その超個人化された編集情報を他者と共有することを可能とするものである．

3
3.1

プロトタイプシステム
必要要件

ユーザ（視聴者）の嗜好に基づき，微妙に動画コンテンツを編集し，個人向けにしたいという欲求を満たすため，我々はウェブブラウザ上で，実際に視聴しながら編集することが可能な編集手法を実現す
る．システムとして求められる要件を整理すると，下記の通りとなる．

• 視聴中の動画の任意の再生時間に対して，ボリュームを上げる，下げる，消すなどの音量に対するコントロールを可能とする．

• 視聴中の動画の任意の再生時間に対して，一部スキップや，スロー再生などの再生に対す
るコントロールを可能とする．

• 視聴中の動画の任意の再生時間に対して，任意の音声，音楽追加を可能とする．

こで，コントロールの表示は，ページ中にコントロー
ル用のコードが含まれる DOM を挿入することで実現している．
音量の変更や，動画のスキップ，再生速度変更といった再生に関するコントロールは，ニコニコ動画
や YouTube の動画を再生するコントローラの APIを利用して操作している．また，付与される音声については，その音声がある URL 上の音楽／音声ファ
イルの場合は，そのファイルをロードし，時刻に合わせて同期的に再生させる．さらに，YouTube などの動画を追加音声として利用する場合は，別のタブとして動画をロードし，タイミングを合わせて再生するよう実装している．つまり，システムとしては
同時に複数のコンテンツを再生しているだけである．
なお，システムはニコニコ動画および YouTube
では，動画プレイヤをコントロールする API を利用しているだけである．そのため，ラッパーを作成するだけで，他の動画共有サイトなどにも適用可能
となる．

3.3

• 上記機能を Web ブラウザ上で実現可能とする．
• 動画と編集情報による，新たなる動画編集 ID（URL）で動画を管理する．

• 動画編集 ID をベースとして，他者と共有することを可能とする．

• 共有された編集情報を元に，さらなる編集を可能とする．

3.2

図 2. システム導入前（左）と導入後（右）実装方法

本提案システムを，Google Chrome の拡張としてプロトタイプシステムを実装した．本システムは，YouTube やニコニコ動画などのページで動画がロードされると，動画の ID を取得（YouTube やニコニ
コ動画上で動画を一意に識別する文字列）し，そのID に合致する編集情報の有無を確認する．編集情報が存在しない場合は，動画編集のためのコントロー
ルを提示し，編集情報が存在する場合は，その情報に基づきコントロール上に編集情報を提示する．こ- 21 -

操作方法

図 2 の左は，本プロトタイプシステムを導入す
る前の YouTube 上のオリジナルのインタフェース
で，右が本プロトタイプシステムを導入した後のYouTube 上のインタフェースである．
編集可能インタフェースは，音量コントロールグラ
フとシークバー，スキップ，再生速度，共有という 3
つのボタン，そして「Drop a media file here」という点線の四角形で囲まれた領域からなる．YouTube
では動画下部に編集インタフェースが追加され，ニ
コニコ動画ではシステムの都合上動画上部に編集イ
ンタフェースが追加される．
音量コントロールグラフでは，ユーザはグラフ上の点をマウスのドラッグ・アンド・ドロップ操作によって上下させることにより，その再生時間における音量を変更することが可能となっている．また，シークバーは，通常の動画のシークバーのインタフェー
スと同じく，動画の再生に応じて自動的に動いてい
くうえ，ユーザの操作によって任意の再生時間に移動することが可能である（図 3）．

WISS 2013

図 3. 編集インタフェースのみを拡大した状態

ユーザがスキップボタンを押すと，編集インタ
フェースに 1 つの時間軸が追加され，レンジスライ
ダー（灰色背景の部分）が現在の動画の再生場所を
左端に，そこから 10 秒後を右端にした状態で追加される．このレンジスライダーが指定されている部
分が自動にスキップされる区間となる．ここで，ス
キップ開始場所はレンジスライダー左端のドラッグ・アンド・ドロップ，スキップ修了場所はレンジスラ
イダー右端のドラッグ・アンド・ドロップによって変更することが可能である．
ユーザが再生速度ボタンを押すと，編集インタ
フェースに 1 つの時間軸が追加され，スキップボタ
ンの時と色が違うレンジスライダー（水色背景の部分）が追加される．現在は，この再生速度ボタンによって指定された部分は，0.5 倍速で再生される（プ
ロトタイプシステムでは固定）．
「Drop a media file here」という点線で囲まれたスペースに，ユーザがローカルのメディアファイルや，ウェブ上のメディアファイルの URL をドラッ
グ・アンド・ドロップすると，編集インタフェースに 1 つの時間軸が追加され，レンジスライダーが追加される．レンジスライダーは，現在の動画の再生
場所を左端に，そこからドロップしたファイルの長さ分後を右端にした状態で追加される．ここでは，ユーザがレンジスライダーの左端，右端どちらをド
ラッグ・アンド・ドロップしても，メディアファイ
ルの開始位置が変更される．また，ドロップされたファイルがどこから取り込まれたのかという情報は，
時間軸インタフェース上に合わせて提示される．これにより，リファレンス情報が明確になる．
ボタンの押し下げや，ファイルのドロップなどによる編集内容は，追加された時間軸の右端に登場する×ボタンを押すことにより削除することが可能となっている．また，対象となる動画をユーザがあらかじめ編集している場合は，その編集情報が自動的- 22 -

図 4. ニコニコ動画上のインタフェースにロードされる．
なお，編集情報はローカルに保存されるが，共有
ボタンを押すことによって，編集情報のみを他者と共有することが可能となっている．

3.4

利用例

図 4 は，本システムをニコニコ動画上で利用している様子である．ここでは，動画の最初の部分に大歓声を入れ，通常再生しサビ部分に向けて音量を徐々に上げている．また，1 つ目のサビ終了後，2 つ目のサビは飛ばしてすぐに音楽の終盤に飛び，音楽の最後では音量を下げるように指定されている．さらに，動画の最終盤に拍手と歓声が再生されるようになっている．
図 5 は，本システムを YouTube 上で利用している様子である．動画自体は，ある研究者が 20 個のテーマを 45 秒ずつ（トータル 15 分）で発表している様子である．ユーザがこの発表の動画を他者に紹介しようと思った際に，10 分しか紹介に使える時間がなかったため，紹介相手が興味をもってもらえなさそうなテーマについてはスキップするように指定する一方，あっという間に進んでしまってわかりにくい部分については，再生速度を変更しスロー再生することによって時間を長めにとっている．また，発表者の音量が大きかったり小さかったりとぶれがあったため，なるべく一定になるように音量コント
ロールインタフェースで変更している．さらに，全体的に音声が盛り上がりに欠けていたため，笑って欲しい所にラフトラックを入れたり，最後に盛大な拍手を入れることによって，盛り上がりを演出している．

個人的な小さな幸せを実現するブラウザ上での動画編集・共有手法

ンス情報を元にオリジナルコンテンツへのアクセスも可能にするものである．ウェブ上の動画などで，リソースの取得元を明記していないケースも多いうえ，仮に明記されていたとしてもアクセスは容易ではない．そういった点で，オリジナルの作成者も尊重しつつも，リファーしながら新たなコンテンツを生み出すことができる事が可能となっている．
これまで，ニコニコ動画など動画共有サイトでは，
オリジナル動画の作成者と，N 次創作をする動画の作成者，動画の視聴者という 3 つのタイプの利用者が存在していた．ここで，オリジナル動画の作成者
や N 次創作をする動画の作成者に比べ，動画の視聴者の数の方が圧倒的に多い．我々の手法は，この圧倒的に数が多い動画の視聴者自体に，編集という形で動画に積極的に関与することを可能にするものであり，動画コンテンツを中心とした生態系がより成長するのではないかと期待される．
一方，本提案手法はオンライン上での編集および視聴を可能とするものであるため，公式サイトから配信されているような動画コンテンツも，本手法を使うことによって擬似的に編集し，視聴することが可能となる．例えば，公式のチャンネルとして，アニメなどが配信されているものについて，オープニン
グやエンディングを飛ばしたり，ダイジェストシー
ンのみにするよう編集しておき，ダイジェストのみ
視聴といったことも可能となる．また，そうした公式の動画に対して，音声を付与したり，別の音楽に差し替えたりといった事も可能となる．また，本手法ではある公式動画の映像と，ある公式動画の音声の組み合わせを動画を違法にダウンロードして編集するのではなく，同期的に再生することで組み合わせとして楽しむことが可能となる．このような動画の使用は，コンテンツの世界を広げるものと期待される．
また，本提案手法を利用することによって，ユー
ザが好きなアーティストの楽曲を CD から取り込ん
で mp3 化し，ウェブ上のお気に入りの動画の映像に合わせて再生する（その動画の音声自体は消音にする）ということも可能となる．ここでは，ユーザはそうした mp3 ファイルをウェブ上にアップロー
ドして他者と共有するわけではなく，個人的に楽し
むだけであるため，著作権の侵害にも当たらず，楽しむことが可能となる．
現在は，YouTube とニコニコ動画のみに対応しているが，システムの処理としては YouTube やニ
コニコ動画の動画コントロールのための API を利用しているだけである．そのため，そうした API さ
え存在し，ラッパーとなるプログラムを書けば，他の動画サービスでも本手法を適用可能となる．例えば，Ustream などに保存されている，WISS の登壇発表などに対して，説明の音声を付与したり，発表と無関係なシーンを飛ばしたりといったことが動画

図 5. YouTube 上でのインタフェース

4

考察

本提案手法により，演奏してみた動画の最後に拍手を入れたり，踊ってみた動画の最後に歓声を入れたり，歌ってみた動画の途中途中に合いの手の声を入れたり，科学系の動画の途中途中に解説の説明を音声として入れたり，わかりにくい部分はスロー再生または停止して説明したりといった事が可能となった．この既にある動画に対する編集（装飾）は，その動画コンテンツを変質させる．例えば，ストーリー
性のある動画について，途中途中にラフトラック（笑い声）を挿入すると，より面白く感じるという事が実際のコンテンツ制作より観察された．今後は，その有効性をユーザ実験などによって明らかにしていく予定である．
動画の再生時間長が長い場合に，スキップや挿入した音声などがどこを指しているのかがわかりにく
く操作しづらいという問題があった．この問題については，動画編集ツールにありがちな時間軸を拡大縮小するようなインタフェースを導入することである程度解決可能であると考えられる．
今回提案している手法は，様々な所から集めてきたリソースを 1 つの動画としてコンテンツ内に取り込むのではなく，部品として外部に存在させつつも1 つの動画であるかのように振る舞わせることができるということである．つまり，どの音声，どの音楽がどこから来たのかというリファレンス情報が明確に存在しているということであり，そのリファレ- 23 -WISS 2013

を編集すること無く実現可能となる．

5

6

関連研究

Seek Rope[4] は，YouTube などの動画共有サイ
トにおいて，シークバーをロープのように取り出し，ロープを丸めることで繰り返し再生したり，ロープを繋げることで複数の動画をつなげたり，ロープを格子状に配置することでランダム再生を行ったりすることを可能とするシステムである．ウェブ上のコ
ンテンツを活用するという点で類似性があるが，本研究は再生のコントロールのみならず，音声や音楽，
他動画などによって装飾可能であるという点で違いがある．
ウェブ上のコンテンツを組み合わせて新たなコンテンツを作り出す試みとして Massh![5] がある．
Massh!では，楽曲同士をインタフェース上でつなぐことによってマッシュアップ音楽を作成可能としている．ウェブ上のコンテンツを組み合わせ，利用するという点で類似はあるが，我々の手法は個人的な欲求を満たすというものであり，その表現方法や目的は異なる．

MixBit[7] は，短い動画クリップ（16 秒）を組み合わせることで，新たな動画を作成可能とするシステムである．MixBit では，ユーザ自身が動画を撮
影せずとも他者が撮影した動画を活用して動画制作が可能となっており，動画制作のハードルを下げている．ただ，MixBit は閉じたコミュニティの中の動画を再生時間に沿って順に繋ぎ合わせるものである．
我々の手法は，コミュニティに閉じること無くすべてのオンラインコンテンツを対象としており，また映像と音声などの組み合わせも可能としている．
ラジへぇ[8] は，ラジオを聞きながらその音声に対して音声コメントをボタン 1 つで入れる事を可能にするものであり，コンテンツの他者との楽しみを強調するものである．本研究で提案する手法の一部
は，ラジへぇの音声付与に似ている．本提案手法は，編集を目的としており，ラジへぇのようなリアルタ
イムでのコミュニケーションは対象としていない．

SMIL[6] はウェブ上でのマルチメディアコンテン

ツの振る舞いを記述するマークアップ言語である．
SMIL では，同期的にマルチメディアコンテンツを再生するといった記述も可能であり，異なるフォー
マットの動画ファイルを並べて再生することなども可能である．我々の手法は，SMIL の仕様とは異なり，ブラウザ自体がウェブ上のリソースおよびプレイヤを直接操作する事が可能となっているため，多様な表現が可能である．ただ，SMIL の記述スタイ
ルは参考になる部分が多いため，今後編集情報の共有などにおいて参考にする予定である．

- 24 -

まとめ

本研究では，ウェブ上の動画に対して，ブラウザ
上で音量コントロールや，スキップ操作，音声や音楽の付与といった編集を可能とし，その編集情報に基づき視聴可能な仕組みを実現した．また，編集情報を他者と共有可能な仕組みを実現し，他者の編集を参考に視聴したり，他者の編集を利用して再編集したりといった事を可能とした．
今後は，本プロトタイプシステムをウェブ上で公開し，多くのユーザに利用してもらうことでフィードバックを集める予定である．また，現在の操作イ
ンタフェースおよび機能は，まだ十分に練られていないため，ユーザからのフィードバックなどを元に改良を行っていく予定である．
ユーザによる編集情報と，ニコニコ動画のコメン
トにはある程度の相関がある可能性がある．そこで，ユーザの編集情報と，ニコニコ動画のコメントを相互分析することによって，自動編集を可能とする仕組みも実現する予定である．

参考文献[1] 中村聡史，山本岳洋，後藤真孝．濱崎 雅弘: 視聴者
反応と音楽的特徴量に基づくサムネイル動画の生成手法, 情報処理学会論文誌（トランザクション）
データベース（TOD58）, Vol.6, No.3, pp.148-158(2013-06-28).
[2] 濱崎雅弘，武田英明，西村拓一：動画共有サイト
における大規模な協調的創造活動の創発のネット
ワーク分析-ニコニコ動画における初音ミク動画コミュニティを対象として-，人工知能学会論文誌，Vol. 25, No. 1, pp. 157-167 (2010).
[3] 濱野智史: アーキテクチャの生態系 ― 情報環境は
いかに設計されてきたか，NTT 出版（2008）.
[4] 佐藤剛, 宮下芳明: SeekRope: 曲げて切って結べるシークバー, インタラクション 2010 論文集, pp.
197-200 (2010).
[5] 徳 井 直 生:
Massh!,
http://www.sonasphere.com/mash/ (2008).
[6] W3C:
Synchronized
http://www.w3.org/AudioVideo/.

Multimedia,[7] mixbit: https://mixbit.com.
[8] 加藤由訓, 苗村健: ラジへぇ：ラジオ聴取時における感想共有システム, インタラクション 2013,
pp.32-39 (2013).

WISS2013

HirakuReader : 行間を拡張する電子書籍
中村 将達

西田 健志∗

概要.
本を読む時には，書かれている内容を鵜呑みにするのではなく批判的思考を持ち，関連する情報や異なる立場からの意見に触れるなどの学習を通じて広い視野を獲得する「能動的読書」を行うことが理想的だと言われているが，そのような読書習慣を身につけて持続させていくことは容易ではなく，誰しもができる
ものではない．こうした中，電子書籍は書き込みを読書間で共有できる機能や関連情報が素早く得られるという点から能動的読書を促す効果が期待されている．だが，電子書籍の書き込み共有機能が堅い意見交
換の場となってしまうことで堅い場が苦手な人々が避けがちになってしまうという問題があり，能動的読書の習慣のない人々はなおさらそのような傾向に陥る可能性がある．そこで，本研究では娯楽性を考慮したデザインによって堅い意見交換が苦手な人にも本への気軽な書き込みを促し，本に対する積極的な態度を喚起する HirakuReader を開発した．HirakuReader は，行間を拡張するインターフェースを用いることで本の中に存在する行間をメディアとして機能させることができ，読者による投稿によって書籍コンテンツが変容していく電子書籍リーダーである．行間を活用した情報提示によって，読者の投稿を促し，関連情報への素早いアクセスを実現する．本論文では能動的読書を実現するアプローチと，そのアプローチに基づいたHirakuReader のデザインと実装について述べる．

1

はじめに

本を読む時には，本に書かれている内容を鵜呑みにするのではなく批判的思考を持ち，関連する本や情報，異なる立場からの意見に触れるなどの学習を通じて広い視野を獲得する「能動的読書」を行うこ
とが理想的だと言われている [9]．しかし，そのよ
うな読書習慣の獲得が高等教育での目標のひとつとされていたり，読書法に関する啓発本が多数出版されていたりすることからもわかるように，そのような良い読書習慣を持つことは容易ではない．
それに対して能動的な読書を促す方法として注目されているのが，読んでいる本とともに様々な情報を提示することができる電子書籍である．たとえば，
Kindle や Kobo[6] といった主要な電子書籍リーダー
では，書籍中の特定箇所のハイライトや，特定のフレーズに対するメモや感想を他の読者と共有することができるようになっている．また，本の感想を共有するための SNS サービスも数多く存在している[15][14].

しかし，そのような既存のシステムは，ユーザを「変なことを投稿してはいけない」という気持ちにさせるなど堅苦しさを感じさせている可能性がある．
電子書籍へ注目が集まる一方で読書よりもテレビや
インターネットの手軽なコンテンツを好みがちな若い世代の読書量の低下が問題視されている中1 ，電子書籍が堅い意見交換の場となってしまってはます∗

Copyright is held by the author(s).
Masatatsu Nakamura，Takeshi Nishida，神戸大学大学
院 国際文化学研究科

ます読書から遠ざかる人が出てしまう恐れがある．
我々は，コメントの重畳表示などに見られる利用者の交流を最優先するニコニコ動画 [13] の精神に電子書籍も倣うべきだと考える．交流最優先の精神が生み出した弾幕やコメント職人といった新たな遊びは堅苦しさを払拭することで多くの人々を巻き込
み，その結果として政治のような堅い話題までもが語られる場を作り出すことに成功している．ニコニ
コ動画自身も，同じようなインタフェースで漫画や小説を楽しめるサービスを提供しているが [12]，文字が主体の情報にコメントを重畳するのはあまりに読みづらいため，電子書籍に対しては同様の精神を受け継ぎながらも異なるインタフェースをデザインする必要があると思われる．
その一試みとして本研究では，書籍中の行間を簡単なタッチジェスチャで広げて空間を作り出し，その空間を利用して関連情報を提示したり様々な情報を書き込んで共有したりできる電子書籍リーダー
HirakuReader を開発した．特に，行間に書き込まれる内容や量が変化する様子を徐々に太くなってい
く線や燃え上がるエフェクトなどで視覚化することで，コメントの内容うんぬんよりもとにかくコメン
トする楽しさ，他の読者と気楽にやり取りする楽しさを前面に出し，堅苦しさをなるべく感じずに交流できるように配慮している．読者の投稿によってインタラクティブに変化していく行間は文章そのものの可読性を落としうるが，読者がそのような破壊的1- 25 -

読書離れに関しては諸説あり [8][4]，読書離れが起きているとは一概には言えない．

WISS 2013

な行動を行うことは本から受けがちな権威的な印象を和らげ能動的読書を促す効果があるものと期待される．本論文では，まずデザイン目標を議論し，その後に HirakuReader の実装および関連研究を紹介
し，最後に今後の課題を述べる．

を喚起しており，積極的な読者が増えることで内容が日に日に更新されていくような本のあり方を実現することを狙った．

2.3

本を読んでいる際，元の文章だけでなく関連する情報を閲覧する場面がある．単語の意味，文章内に出てくる用語の詳細な説明といったものに限らず，他の読者たちの投稿した情報を参照することがあるだろう．その際，情報閲覧までにかかるステップが煩雑であるほど読書行為が阻害されてしまうため，
なるべく素早く，読書の邪魔をしないような情報提示が求められる．

デザイン目標2

本研究では行間を拡張するインターフェースのデザイン目標として以下のものを掲げている．

1. 本は与えられたまま読むものだという意識の破壊

2. 能動的な読者による書籍そのものの変化
3. 読書時の快適な情報量調節
2.1

本は与えられたまま読むものだという意識の破壊

電子書籍上での意見や注釈の共有機能は，付箋などといった紙の本のメタファーに則ったものとして実装されているものが多く，なるべく中身を汚さないようにするという紙の本の感覚が誘発され，本に対する受け身な態度を助長してしまう．
そこで我々は，読者の働きかけによってコンテンツが変容していき，書き込み行為自体が娯楽性を持
つような本を実現することで読者の積極的な読書態
度を促すことができるのではないかと考えた．
本研究では行間というスペースを活用することで，読者の働きかけが本のコンテンツを演出するような機能デザインを行った．HirakuReader では，本の中にある行間を「開く」ことで書き込みを行うことができ，そうして行われた書き込みは読者間で共有される．書き込みが行われた行間は光ったりアニメー
ションしたりすることで情報提示を行い，文章の見た目を変容させる．投稿によって変化する行間の表
現性や娯楽性によってさらなる投稿を促し，より読者を積極的に本に介入させることを狙った．

2.2

読書時の快適な情報量調整

能動的な読者による書籍そのものの変化

本には著作という概念が存在するため，第三者が内容を自由に書き換えることができないが，本研究では行間というスペースを用いて読者の投稿と情報提示を実現しているため，コンテンツそのものの書
き換えは行なっておらず，著作物を破壊することな
くコンテンツのさらなる充実を可能にしている．
本は時が立つにつれて書き換える必要がある部分などが出てくるが，そういった本は，概ね改訂版で内容が更新されたり，新版のまえがきなどに説明が付け足されたりする．電子書籍では，読者たちの投稿によって改訂版を待たずして内容の訂正などが可能になるが，そのためには読者たちに積極的な情報投稿を促す必要がある．本研究では書き込み行為に娯楽性を持たせることで，読者たちの積極的な態度

従来の電子書籍アプリケーションにおけるイン
ターフェースでは，単語部分の長押しや，画面上に現れるアイコンをタッチするなどといった操作を行
い，ポップアップウィンドウや画面端の領域に情報を提示するという手法が採用されている．しかし，そういった情報提示が行われる領域は文章表示の邪魔をしないために一定のサイズが保たれており，読者がもっと情報を得たいと感じた時には画面遷移を伴う必要がある．

HirakuReader のインターフェースでは，二本指で単語や行間を挟み込むことで選択し，そのまま指を広げていくことで文章のレイアウトを変化させて空間を作りだし，そこに様々な情報提示を行うこと
で関連情報へのアクセスを可能にしている．選択から検索までをスムーズに行うことができ，もっと情報を見たいと感じた際にはそのまま指を広げていく
ことでさらに多くの情報提示することができるため，閲覧する情報の量を快適に調整することができる．

3

HirakuReader

本章ではタブレット端末向けのアプリケーション
として実装した HirakuReader の機能について説明
を行う．

3.1

行間を広げるジェスチャインターフェース

行間を広げる操作は，二本の指で画面にタッチしている状態からそのまま指を広げるという動作で実行できる．このインターフェースは読書中でも素早く行うことができ，各種情報へのアクセスを素早く，容易にしている．行間を広げると文書のレイアウト
が上下に動いていき，ユーザが指を広げれば広げるほどそれに応じて行間が広がっていく．このインターフェースでは，二本指で画面に触れた際の指の真ん
中の位置がポインティング位置となっており，二本指の真ん中で単語や行を狙うことで選択を行う（図1）．

- 26 -

HirakuReader : 行間を拡張する電子書籍

といった情報を画像や動画などを交えて投稿することができる．こうして投稿された情報はアプリケー
ション間で共有され，読者の手によって行間に含まれる情報は充実していく（図 4）．投稿の際には文字のサイズや色，表示される際の位置などを指定することができ（図 5），提示される情報に表現の幅を持たせた．

図 1. 行間や単語の選択の際，二本指でタッチしている
位置の真ん中がポインティング位置となっている．

3.2

図 5. 投稿用のフォーム．文字の大きさや位置，色を設定することができ，画像も投稿できる．

行間を広げて関連情報を検索する機能

文章内の単語は二本指で挟み込むことで選択することができ，そのままピンチアウトすることでその単語が含まれる行を挟んで上下の行間を広げられる（図 2）．広げられた行間にはその単語に関する情報が提示され，辞書や各種 Web サービスでのその単語による検索結果を表示することができる．単語に関する情報は指をどれほど広げるかによって提示される内容が変化し，少し広げると辞書，もう少し広げると画像検索の結果や Wikipedia のページなどを閲覧することができ，指を広げるほど多くの情報を得ることができる．

3.3

3.4

行間へ追加された情報を視覚化する機能

読者によって情報が投稿されている行間は，閉じられている状態では線が引かれ，光る・アニメーショ
ンするなどの表現を行い，情報が埋め込まれていることを知らせる．投稿が少ない状態では，行間は細い点線で表示され，投稿が増えていくとしだいに線が太く点線が細かくなっていき，最終的には太い直線になる（図 6）．

広げた行間に情報を追加し，共有する機能

文章内に存在する行間も単語同様に二本指で挟み込むことで選択することができ，選択された行間を挟んで上下に広げていくことができる．誤って単語の選択が行われてしまわないよう，行間の選択には
ページ横の余白のスペースを利用し，その余白の中で任意の行間を二本指の真ん中で狙うという操作を行うことで選択を行えるようにした（図 3）．

図 6. 行間は投稿が少ない状態では細い点線で表され，投稿が増えるほど点線が細かく，太くなってゆき，行間が強調される

読者が設定できる投稿の情報には，文字のサイズ
や色，位置などがあり，投稿された書き込みの色に応じて行間の色が変化するなど，設定が直接反映されるような表現を実現している．行間の表現には燃え上がるなどの演出機能も用意しており，こうした強力な表現は本を破壊的に読むメタファーとして機能する（図 7）．
これらの機能によって読者の働きかけでインタラ
クティブに変化する行間を実現し，投稿する行為に

図 3. ページ横の余白領域（グレーの色がかかった領域）の中で任意の行間を二本指の真ん中で挟み込むことで行間の選択を行う．

この広げられた行間には，意見や内容の補足など- 27 -WISS 2013

図 2. 文章中の単語が選択され，検索されている様子．文章内の単語は二本指で挟み込むことで選択することができ，選択中の単語は黄色くハイライトすることでわかりやすくした．

娯楽性を持たせることでより積極的に本と関わろうとする読者の態度を誘発することを狙った．

トを利用し iOS アプリケーションとして実装した．
電子書籍のフォーマットには HTML ベースの標準的な EPUB3 を対象としており，CSS や JavaScriptを用いて書籍のデザイン調整などを行った．行間の表現などのダイナミックな部分は HTML を用いずに，iOS の API を用いて実現している．サーバ側
は Ruby を用いて実装を行っており，データベースには MySQL を用いた．

3.6

ユーザフィードバック

本システムのプロトタイプを同じ研究室の学生に使用してもらい，出てきた声をまとめる．

• 難しい本や退屈な本でも面白い書き込みがあることで読み進めようという気持ちになった• 一度読んだ本でも，自分の後から読んだ人の書
き込みが行われることでまた読みたくなった• 単語を選択して素早く検索できるため，本を読み進めるのが早くなった，またそれに伴って英語の本が読みたくなった• 単語を検索して出てくる画像などが面白く，本図 7. 情報が投稿された行間の表現．投稿の量や設定によって表現は変化し，行間が燃え上がるようなエフェクトもある．

3.5

を読み進める上で参考になる場面があった• 画面上下の端において，行間を広げる際に狙った箇所とは違う行間を広げてしまうことがあった

実装• 文字部分を長押しすることで選択する従来の本システムはサーバークライアントシステムとして実装を行った．クライアント側では，iPad タブレッ

文字選択手法に比べて，二本指で挟む手法は選択部分が指で隠れずに済み素早く選択する- 28 -

HirakuReader : 行間を拡張する電子書籍

図 4. 情報が投稿されている行間を選択して，情報を閲覧している様子．文章中の行間も単語同様二本指で挟み込んで選択することができ，選択中の行間は黄色くハイライトしている．

ことができたが，文字の細かい選択範囲が操作できないことに不便を感じた

ションしたいというニーズには応えることはできな
い．書き込み箇所を曖昧にしておくほうが気軽な書き込みを誘発できると我々は考えているが，アノテー
ションとの兼ね合いを考慮した書き込み箇所の指定方法についても考察する必要があるだろう．

面白い書き込みがあることで読み進めようという気持ちが促進されることや，検索の素早さから関連情報を得やすくなり本の理解度が増すなどの声がある一方で，行間を広げる操作を間違えてしまうなどの声もあり，インターフェースに改善の余地がある
ことを示唆している．

4

4.3

行間を広げるインターフェースは，二本指の真ん
中で単語や行間を狙って選択を行うが，文字範囲の選択に関して一つの課題がある．英語などの元々分
かち書きされている言語を対象とする場合には，一つの単語を容易にポインティングすることができる
が，日本語などの分かち書きされていない言語の場
合は困難が生じる．

今後の課題

本システムは，肝となる行間の表現や，文字選択
機能や行間に書き込まれた情報の共有機能に関して課題がある．

4.1

行間の表現

5

読者の投稿によって変化する行間の表現は娯楽性を引き出す上で重要であるが，どのような情報が投稿されるとどのような行間の演出が現れるかといった点については未だ検討中であり，これからの課題となっている．例えば，燃え上がるなどの表現（図7）は強力な演出となりうるが，いかにして読者の投稿と絡めて効果的に用いるかは検討していく必要
がある．

4.2

文字選択

関連研究

Schilit らの [9] は紙の本で行われる注釈やマーキ
ングといった書き込みをデジタルの文書でも行えるようにした．ペンによる自由な形式での注釈やマーキングをつけながらの読書は，文章の理解度を促進する効果があるが [18]，デジタル文書は紙の文書と違ってレイアウトが柔軟に切り替わるためにそうした情報は管理しにくく [3]，また大量の読者による情報共有は実現しづらいため，本研究ではフォームを用いた情報の投稿を採用した．
電子書籍上での注釈情報の共有は Johnson らに
よって教育上の効果があることが確認されており [5]，
電子書籍のこうした機能には教育ツールとしての可能性が期待されている [7]．
このようなユーザ間での注釈情報の共有は，書籍よりも Web ページを対象としたものが積極的に試みられている．その中には Web ページ上に重畳表

投稿の共有

電子書籍はデバイスの解像度や画面サイズ，設定された文字サイズによって行の長さが変化してしまうため，特定の行間に書き込んだとしても，他のデバイスや文字サイズで閲覧する際には書き込みが表示される位置が変化してしまう問題がある．
また，行間にしか書き込みを行えない現状のシス
テムでは文章中の特定の単語や節に対してアノテー- 29 -WISS 2013

参考文献

示する手法がいくつかあり，ペンデバイスを用いた
手書きのもの [17] や付箋メタファーを用いたもの [2]など，本に対して行われる書き込みを模倣した手法が多く，電子書籍での注釈共有を考える上で参考になる．
ニコニコ動画 [13] の動画を見えにくくするようなコメントシステムは，ユーザによるコメント投稿に娯楽性を持たせており，コメントそのものが動画コ
ンテンツの一部と化している．同じ動画共有サイトの YouTube[11] とニコニコ動画では，ユーザの行
動パターンに顕著な差が見られ [16]，ユーザの働きかけを積極的に引き出すシステムによって齎されるコンテンツの受容態度の変化が見て取れる．ゲームなどの娯楽性のあるシステムを用いることでユーザから効果的に情報を収集する研究 [10] もあり，娯楽
性や表現性といったものがユーザの積極性を引き出すという効果には期待ができる．本研究の電子書籍システムも，行間への書き込み行為が娯楽性を持つような機能やデザインを試みている．
本研究では，行間を広げることで情報提示を行ったが，文章のレイアウトを柔軟に変化させることで効果的な情報提示を行った研究として Chang らの[1] がある．本の脚注などの情報を見るためには，読んでいる部分から離れた位置まで視線を移動させる必要があり，読書の負担となる．Chang らは本文中に情報提示を行う空間を作りだすことでそうした問題を解決している．我々の手法では指を広げるという単一の動作で，レイアウトを変化させて情報提示
空間を作り出す機能と情報提示空間を広げていく機能を実現しており，情報への素早いアクセスが可能となっている．

6[1] B.-W. Chang, J. D. Mackinlay, P. T. Zellweger,
and T. Igarashi. A negotiation architecture for
fluid documents. In Proc. ACM ’98, UIST ’98,
pp. 123–132, New York, NY, USA, 1998. ACM.
[2] diigo. http://www.diigo.com.
[3] G. Golovchinsky and L. Denoue.
Movingmarkup: repositioning freeform annotations. In
Proc. ACM ’02, UIST ’02, pp. 21–30, New York,NY, USA, 2002. ACM.
[4] 日 本 人 の 読 書 離 れ は 進 ん で い る の か.
http://research.goo.ne.jp/database/data/000618/.
[5] T. E. Johnson, T. N. Archibald, and G. Tenenbaum. Individual and team annotation effects
on students reading comprehension, criticalthinking, and meta-cognitive skills. Computersin Human Behavior, 26(6):1496 – 1507, 2010.
[6] Kobo. http://kobo.rakuten.co.jp.
[7] D. G. Lebow and D. W. Lick. HyLighter: An effective interactive annotation innovation for distance education. In 20th Annual Conference on
Distance Teaching and Learning, pp. 1–5, 2005.
[8] 若者だけじゃない、各年代で進む読書離れ 30・
40 代女性の半数は 1 か月の本代 1,000 円未満.
http://moneyzine.jp/article/detail/206052.
[9] B. N. Schilit, G. Golovchinsky, and M. N. Price.
Beyond paper: supporting active reading withfree form digital ink annotations. In Proc.
SIGCHI’98, CHI ’98, pp. 249–256, New York,NY, USA, 1998. ACM Press/Addison-Wesley
Publishing Co.
[10] L. von Ahn, R. Liu, and M. Blum. Peekaboom:
a game for locating objects in images. In Proc.
SIGCHI ’06, CHI ’06, pp. 55–64, New York, NY,
USA, 2006. ACM.
[11] YouTube. http://youtube.com.

まとめ

本研究ではなるべく多くの人が能動的読書を達成するための試みとして，娯楽性によって読者を引き込んで本への積極的な態度を促すというアプローチ
を提案し，電子書籍リーダー HirakuReader を開発した．HirakuReader では行間をメディアとして活用することで読者による本への書き込みに娯楽性を持たせ，関連情報へ素早くアクセスできるようにした．今後は正式なユーザスタディを行い，娯楽性が読書態度をどれほど改善するのかといった点や，行間を広げるインターフェースの効果の調査等を行いたい．
電子書籍の浸透がきっかけとなり，今後の本のあり方に関して様々な議論が交わされているが，本研究が本のあるべき姿に一つの方向性を示すことを期待している．

[12] ニコニコ静画. http://seiga.nicovideo.jp.
[13] ニコニコ動画. http://nicovideo.jp.
[14] ブクレコ. http://bookreco.jp.
[15] ブクログ. http://booklog.jp.
[16] 沖松健太郎, 松本淳. 動画共有サイトにおけるユー
ザー参加型のオープン・クリエーションモデルー
YouTube とニコニコ動画の比較分析, 日本社会情報学会 第 23 回全国大会. 2008.
[17] 浜口拡輝, 加藤直樹, 山崎謙介. Web 上への手書
きメモが共有可能なブラウザ PerowserEx の開発. 情報処理学会研究報告, 2009, 2009.
[18] 浩成 野崎, 彩奈 吉橋, 恭子 梅田, 撤郎 江島. テ
キストへの自由な書き込み行為が文章理解に及ぼす影響. 日本教育工学会論文誌, 29:49–52, mar
2006.

- 30 -WISS2013

SuprIME: IME によるテキスト編集機能の統合
中園 翔

増井 俊之 ∗

概要. 計算機上で様々なテキストエディタが利用されているが，システムごとに編集方法や編集機能が異なっているのが不便である．本論文では，各国語入力のために OS に用意されている IME(Input Method
Editor) 機能を利用することにより，あらゆるテキストエディタにおいて同じ操作によるテキスト編集を可能にする方法を提案する．我々の手法を利用すると，異なるテキストエディタ上での編集操作が共通化されるだけでなく，テキスト編集時に便利な様々な機能をあらゆるエディタで利用することが可能になる．

1

はじめに

入力のみのために利用されているが，テキストの挿入/移動/削除といった編集操作も IME が受け持つようにすれば，様々なエディタ上で同じ操作で編集を行なうことが可能になると考えられる．
このような考えにもとづき，Mac 上の様々なテキストエディタにおいて同じキー操作によるテキスト編集を可能にする SuprIME システムを試作した．本
論文では SuprIME の実装と利用方法について述べ，
柔軟でユニバーサルなテキストエディタの構築について考察する．

計算機上でテキストを編集するために様々なテキストエディタが利用されている．文書を作成するときはワープロを利用し，メールを書くにはメールク
ライアントを利用し，文字端末でのプログラム開発には vim や Emacs を利用し，IDE を利用した開発では付属のエディタを利用し，ネット上でテキストを扱うにはブラウザのテキストフォームを利用するといったように，場合に応じて様々なエディタが利用されている．
エディタの機能や操作体系はエディタごとに異なっているのが普通である．ブラウザやワープロでテキストを 1 行消したい場合はマウスで行全体を選択してから削除キーを押せばよいが，vim では「d」キーを 2 回タイプして消すのが普通であり，Emacs では
Ctrl-K キーが利用される．Emacs に慣れたユーザがワープロ上でも Ctrl-K で行を消去したいと思っても，そのようなカスタマイズはできないのが普通であるし，機能拡張が可能なシステムを利用している場合でも，操作体系を完全に同じにすることは難しい．
あらゆるエディタの操作を統一することは難しいが，様々なエディタで共通に利用できるソフトウェア
層をユーザとアプリケーションの間に置くことができれば，異なるエディタの編集操作をある程度共通化できる可能性がある．現在のパソコンには IME(Input
Method Editor) と呼ばれる文字入力機構が用意されており，様々な言語のテキスト入力に利用されている．IME はエディタなどとは独立したソフトウェ
アであり，ユーザのすべてのキー入力を受け取って各国語に変換した結果をアプリケーションに送出す
る．IME はあらゆるアプリケーションで共通に利用されるので，たとえば日本語入力用の IME を利用する場合，Emacs でもブラウザでも IDE でも同じ操作で日本語を入力できる．IME は一般には各国語∗

2

SuprIME 使用例

2.1 日本語入力
SuprIME は，MacRuby1 で記述された日本語 IMEである「Gyaim2 」に様々な編集機能を追加したものである．図 1 は SuprIME による日本語入力の例
である．IME はアルファベット以外の文字を入力するときだけ有効にするのが普通であるが，SuprIME
は，編集操作を行うために常に有効であることを想定して実装した．そのため、英語入力と日本語入力の両方が可能である．

図 1. SuprIME による日本語入力の例

1

Ruby を Mac 用に拡張したもので，あらゆる Mac の API
を Ruby から利用することができる．
2
https://github.com/masui/Gyaim

Copyright is held by the author(s).
慶應義塾大学環境情報学部 環境情報学科，慶應義塾大学
環境情報学部- 31 -WISS 20132.2

ブロック移動

テキストの一部を別の場所に移動する操作はテキストエディタの重要な機能のひとつであるが，エディタによって操作方法が大きく異なっている．たとえば Emacs でテキストを移動させたい場合は，移動する領域をキー操作によって指定してから削除/コピー
し，カーソルを移動してからペーストするという手順を利用するのに対し，ブラウザの編集領域でテキストを移動させたい場合は，マウスで領域を指定した後で選択領域をドラッグして別の位置に移動することが多い．このように，テキスト移動のような基本操作でもエディタごとに操作が異なっているのは不便であり，操作ミスをしがちであるが，SuprIME
を利用するとあらゆるエディタにおいて同じ操作でテキストを移動することができる．
図 2 は Mac OS に標準登載されている「テキストエディット」でテキストを編集しているところである．

図 4. ブロック移動前の状態

図 5. Shift+↑キーを押した後の状態

このように，あらゆるエディタにおいて Shift+
矢印キーという共通の操作でブロック移動を行なう
ことができる．

図 2. ブロック移動前の状態

ここで Shift+↑キーを押すとテキストは図 3 のように変化する．

2.3

連続インデント

前述したブロック移動は，インデントを調整する機能も備えている．プログラミングを行なっている
時だけでなく，普通のテキストを編集している場合
でも行頭の空白やタブの量を調整するインデント処理は頻繁に行われるが，自動的にインデントを行う
エディタもあれば，コマンドを打ち込まなければな
らないものもあり，そのような調整機能を持っていないエディタも多い．SuprIME を利用すると，あらゆるエディタや入力フィールドでブロック移動と同時にインデントが自動で行われる．
図 6 は，Xcode 上で Python プログラムを書いている例である．Xcode は，Objective-C や Ruby な
どの言語で自動インデントの機能を備えているが，Python には対応していない．たとえば，図 6 のようなテキストに対して図 7 のように移動させたいブ
ロックを選択し，Shift+↓キーを入力することで、テキストは図 8 のように変化する．

図 3. Shift+↑キーを押した後の状態

図 4 はブラウザ上で Google Docs のテキストを編集しているところである．ここで Shift+↓キーを二度押すと，テキストは図 5 のように変化する．

- 32 -

SuprIME: IME によるテキスト編集機能の統合

図 6. ブロック移動前の状態
図 9. 単語置換ウィンドウの例

図 10 のように，入力語と置換語をテキストエリ
アに打ち込み，Replace ボタンを押すと，

図 7. テキストを選択した状態

図 10. 置換ウィンドウに単語を入力した例

テキストは図 11 のように置換される．

図 8. ブロック移動後の状態

このように，あらゆるエディタにおいて，ブロッ
ク移動を行う際に適切な空白とタブを自動で補完することができる．

2.4

図 11. 単語置換後の状態

このように，あらゆるエディタ上で検索と置換が可能である．

単語置換

多くのエディタが単語の検索/置換機能を持っているが，その操作方法はシステムごとに異なっている．例えば，コンソール上で検索と置換を行う時はgrep や sed コマンドを用いるが，多くのエディタソ
フトでは Control+F や Command+F が用意されている．
SuprIME を利用することでこの操作を共通化する例を挙げる．
あらかじめ割り当てたファンクションキーを押すと，図 9 のように SuprIME の単語置換ウィンドウが起動する．

2.5 Dynamic Macro
Emacs では lisp プログラムでエディタの機能を拡張することが出来るが，これらのスクリプトを IME上に実装することで，他のエディタ上でも Emacs と同様の拡張機能を動作させることができる．
以下に SuprIME で Dynamic Macro[7] を実現した例を挙げる．Dynamic Macro は，入力の繰り返しを自動化する Emacs 拡張であるが，SuprIME ではこれと同様の機能を Ruby で実装している．図 12のように，ユーザの入力操作が繰り返しになってい- 33 -WISS 2013

3

るとき，任意に設定したファンクションキーを押すと，テキストは図 13 のように編集される．

実装

SuprIME は MacRuby で記述された Mac 用のIME であり，ソースが 500 行程度とコンパクトであるにもかかわらず，他の IME に見られない機能を実装しており，本論文のような実験も容易である．

3.1

MacRuby による実装

MacRuby は，Mac OS 用のアプリケーションを開発するために拡張された Ruby 実行環境であり，Mac OS の Objective-C ライブラリを Ruby で扱うことが出来る．SuprIME では，Mac OS の IME フ
レームワークである InputMethodKit Framework
を MacRuby から呼び出すことによって基本的な
IME の機能を実装している．
図 12. Dynamic Macro 機能を使用する前のテキスト

3.2

修飾キーの扱い

エディタが編集機能のために用いる，Control や
Command などの修飾キーは IME がハンドルしないのが普通であるが，SuprIME では、一部のファン
クションキーと修飾キーの入力を受け取り，共通化
されたテキスト編集操作を実現している．
SuprIME のように，修飾キーの一部をハンドルする実装を行った場合，修飾キーの入力はエディタに送出されないため，エディタが同じキー入力を編
集操作の一部に割り当てている場合，それを利用することは出来なくなる．

3.3

テキストデータの取得

ブロック移動やインデントの処理といったテキス
ト編集の機能を，あらゆるテキストエリアで行う
ためには，テキストエリアに入力されている全文をIME が取得する必要があり，InputMethodKit はこの機能を備えていない．SuprIME では，ブロック移
動やインデントのコマンドが入力された際に，MacOS に実装されている，テキストエリアの全文を選択状態にするコマンドを AppleScript により送信している．
Mac OS では，多くのアプリケーションにおいて
テキストエリアは NSTextField Class のオブジェクトとして実装されており，この NSTextField に対してテキスト編集や入力の操作を行うための NSTextInput Protocol が存在する．このプロトコルには標準の実装として Command+A キーによる全
文選択の機能が備わっている．
SuprIME では，このキー入力を AppleScript によりテキストエリアに送信することにより，テキス
トエリアの全文を選択状態にしている．SuprIME では，NSTextInput の標準実装である Command+C
キーによる全文コピーの機能を AppleScript により送信することで，Mac OS のクリップボードにテキス
トエリアの全文を保存し，それを InputMethodKit

図 13. Dynamic Macro 機能を使用した後のテキスト

以下は SuprIME の Dynamic Macro 機能をブラウザのアドレスバー上で実行した例である．図 14のように，ユーザの入力に”abc”が繰り返されているとき，任意に設定したファンクションキーを押すと，テキストは図 15 のように編集される．

図 14. Dynamic Macro 機能を使用する前のテキスト

図 15. Dynamic Macro 機能を使用した後のテキスト

Emacs 上に実装された Dynamic Macro は Emacs
上でしか利用できないが，SuprIME 上に実装されたDynamic Macro はあらゆるテキストエディタの上で利用することができる．

- 34 -

SuprIME: IME によるテキスト編集機能の統合

Framework が読み込むことで，テキストエリアの全文を IME が取得している．
3.4

実装手法の問題点

しかし，このような手法で実装できる編集機能
や，IME としてのパフォーマンスには問題がある．
たとえば，対象とするテキストエリア自体が NSTextField Class を利用していない場合や，対象とするテキストエリアがテキストの全選択やコピーに割り当てるキーバインドを変更している場合，テキストエリアの全文を取得することが出来ない場合があり，SuprIME の持つ編集機能は有効に機能しな
い．また、どこまでの編集機能をエディタやテキス
トエリアから切り離し，どれだけの拡張性を持たせることができるか，という点において，IME の層での実装には問題がある．各国語入力のための枠組みである IME は，テキストエリアよりも先にユーザのキー入力をハンドルすることができるが，エディ
タが想定するキー入力を横取りして、エディタの機
能をを打ち消す実装になる可能性がある．前述した
Dynamic Macro の例のように、編集操作をマクロ化して行うことは多くあるので，IME とテキストエ
リアとの間に，テキスト編集のための枠組みを用意
し，機能拡張が容易に可能な OS と API 設計のレベルでの実装の修正が求められる．

4.3 高度な文書編集補助
SuprIME を利用すると，単純な文書編集作業が共通化できるだけではなく，より高度な編集補助を行なうことも可能である．たとえば，単語の言い換えを補助するために，図 16 のように類語を検索して入力することが出来る．

議論

4

図 16. SuprIME の類語変換機能の例

4.1 キー操作の統一の必要性
Xerox PARC の Larry Tesler が 70 年代に発明した [10] 「コピー/ペースト」は現在広く普及しており，ほぼすべてのアプリケーションにおいて同じ操
作 3 でテキストをコピーしたりペーストしたりできるようになっている．つまりコピー/ペーストに関しては 1 章で述べたような問題がほぼ存在せず，ユー
ザは混乱せずに様々なアプリケーション上でテキス
ト操作を行なうことが可能になっていることになる．
コピー/ペーストの操作がこのように標準化されているのに対し，テキスト移動のような処理が標準化されていないのは問題であるが，それが大きな問題だと認識されておらず，ユーザが様々なエディタの使い方を覚えることをシステムが強制していることはさらに大きな問題だといえるだろう．SuprIME のような手法を利用することによってシステム全体を統一的に利用できるようにする工夫はまだまだ重要だと考えられる．

4.2

図 17,18 は SuprIME の画像入力の例である．こ
こでは、「知らない」という入力語句について画像を検索し，入力候補として表示している．画像が埋め込めるテキストエリアであれば画像を埋め込み，
そうでなければ URL が入力される．

図 17. SuprIME で「知らない」という単語を入力した例

ユニバーサルな入力/編集

パソコンやスマートフォンで利用されている様々なテキスト入力システムは変換方式も使い勝手も全
く異なるのが普通になっているが，POBox[6] のよ
3

うな単純で柔軟な入力方式を利用すると，パソコン
でもスマートフォンでもほぼ共通の入力を行なうことが可能になる．Gyaim はこのような思想にもとづいて作成された IME であるが，Gyaim を拡張した SuprIME を利用すると編集操作も共通化することができるため，広い範囲の機器における入力と編集の共通化が期待できる．

Mac の場合は Command-C と Command-V- 35 -WISS 2013であることは間違いないので，操作を簡単化/共通化するための優れた枠組みの開発は重要な課題だと考えられる．

参考文献[1] TextEditors.org. http://texteditors.org/.

図 18. SuprIME の画像入力ウィンドウ

SuprIME を利用すると，このような高度なテキス
ト編者操作もあらゆるアプリケーションで共通に利
用できる．
4.4

テキスト入力/編集以外への応用

本論文ではテキストエディタに絞った説明を行なったが，IME はユーザのすべてのキー入力を直接受け取る窓口になっているため，キー操作をテキスト編集と関係無い仕事に割り当てることも可能である．たとえばシステム音量や画面の明るさなども SuprIME
から制御することが可能であり，システムで用意されたショートカット設定などが不要になる．

4.5 本手法の限界
IME は，テキストエリアが実装されたアプリケー
ションとは個別に実装されているため，現在の SuprIMEの実装ではアプリケーションの内部状態によって動作を変えたり，アプリケーションの振る舞いを制御したりすることはできず，表に出ているテキストの編集操作しかできない．
既存のシステム自体は変更せずに，皮をかぶせる
形で機能を拡張する手法はある程度有用ではあるが，問題の根本的な解決が必要な場合には限界がある．
テキスト編集の場合は根本的に解決しなければならない問題は多くないので，本論文の手法はとりあえず有効だといえるが，根本的な解決のためには，テキスト入力の枠組みである IME に加えて，各コン
ピュータがテキスト編集操作を一元化するための枠組みを用意する必要があるだろう．

5

結論

OS に標準装備された IME 機能を活用することにより，様々なテキストエディタにおける入力/編集操
作を共通化する手法を提案した．IME 機能はアプリ
ケーションから独立しているため，アプリケーショ
ン内のデータを操作することはできないが，様々なアプリケーションにおける入力/編集操作の多くの部分を共通化することができた．テキストの入力や編集は計算機利用における最も重要な仕事のひとつ[2] P. H. Dietz, B. Eidelson, J. Westhues, and
S. Bathiche. A practical pressure sensitive computer keyboard. In Proceedings of the 22nd annual ACM symposium on User interface software and technology, UIST ’09, pp. 55–58, 2009.
[3] C. Harrison, D. Tan, and D. Morris. Skinput:
appropriating the body as an input surface. In
Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’10,
pp. 453–462, 2010.
[4] F. C. Y. Li, R. T. Guy, K. Yatani, and K. N.
Truong. The 1line keyboard: a QWERTY layout in a single line. In Proceedings of the 24th
annual ACM symposium on User interface software and technology, UIST ’11, pp. 461–470,
2011.
[5] I. S. MacKenzie, R. W. Soukoreff, and J. Helga.
1 thumb, 4 buttons, 20 words per minute: designand evaluation of H4-writer. In Proceedings ofthe 24th annual ACM symposium on User interface software and technology, UIST ’11, pp.
471–480, 2011.
[6] T. Masui. An efficient text input method forpen-based computers. In Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, CHI ’98, pp. 328–335. ACM
Press/Addison-Wesley Publishing Co., 1998.
[7] T. Masui and K. Nakayama. Repeat and predict– two keys to efficient text editing. In Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, CHI ’94, pp. 118–
123, 1994.
[8] T. Murase, A. Moteki, N. Ozawa, N. Hara,
T. Nakai, and K. Fujimoto. Gesture keyboard
requiring only one camera. In Proceedings of the24th annual ACM symposium adjunct on Userinterface software and technology, UIST ’11 Adjunct, pp. 9–10, 2011.
[9] J. Rick. Performance optimizations of virtual keyboards for stroke-based text entry on
a touch-based tabletop. In Proceedings of the
23nd annual ACM symposium on User interface
software and technology, UIST ’10, pp. 77–86,
2010.
[10] L. Tesler. A personal history of modelesstext editing and cut/copy-paste. interactions,19(4):70–75, July 2012.
[11] D. Wigdor and R. Balakrishnan. TiltText: using tilt for text input to mobile phones. In Proceedings of the 16th annual ACM symposium on
User interface software and technology, UIST
’03, pp. 81–90, 2003.

- 36 -WISS2013

CapStudio: ϓϩάϥϜͷ࣮ߦը໘ͷ࿥ըө૾Λར༻ͨ͠౷߹։ൃ‫ڥ؀‬
ਂງ ޸໌

ࡔຊ େհ

Ճ౻ ३

‫ेޒ‬ཛྷ ݈෉ ∗֓ཁ. ௨ৗɼϓϩάϥϜ։ൃ͸ɼίʔυΤσΟλ্ͰϓϩάϥϜͷιʔείʔυΛฤू͢Δ͜ͱʹΑͬͯߦΘΕΔɽ͔͠͠ɼήʔϜ։ൃʹ͓͍ͯ͸ɼΩϟϥΫλը૾΍Ϙλϯͷ഑ஔͳͲ‫ͨݟ‬໨ʹؔΘΔ෦෼͸ήʔϜͷ࣮ߦը໘Λ‫͕ͳݟ‬ΒϦΞϧλΠϜʹฤूͰ͖ͨํ͕௚‫ײ‬తͰ͋ΔɽήʔϜΤϯδϯͷγʔϯΤσΟλ
ͱ͍ͬͨɼϓϨϏϡʔը໘্ͰύϥϝʔλΛฤूͰ͖ΔγεςϜ΋͋Δ͕ɼϑϨʔϜϫʔΫ্ͰܾΊΒΕ੍ͨ໿͕͋ΓɼήʔϜը໘ͷඳըͳͲͷϓϦϛςΟϒͳॲཧΛϓϩάϥϚ͕ฤूͰ͖ͣɼίʔσΟϯάͷࣗ༝౓͕௿͘ͳΔͱ͍͏໰୊͕͋Δɽͦ͜ͰɼຊߘͰ͸ήʔϜը໘ͷ࿥ըө૾Λϕʔεͱͨ͠ΤσΟλʢҎԼεΫϦʔϯΩϟετʣΛఏҊ͢Δɽ͜ΕΛίʔυΤσΟλͱ࿈‫ͤ͞ܞ‬Δ͜ͱͰɼϓϩάϥϚ͸ϓϩάϥϜશମΛίʔυΤσΟλͰ‫ه‬ड़ͭͭ͠΋ɼήʔϜը໘ͷσβΠϯʹؔΘΔఆ਺஋΍ϦιʔεϑΝΠϧΛεΫϦʔϯΩϟετ্ͰϦΞϧλΠϜʹฤूͰ͖Δɽ۩ମతʹ͸ɼఆ਺஋΍Ϧιʔε͕ฤू͞ΕΔͱଈ࠲ʹͦͷ݁Ռ͕εΫϦʔϯΩϟετʹ൓ө͞ΕΔɽ൓ରʹɼεΫϦʔϯΩϟετͷήʔϜΦϒδΣΫτ͔ΒରԠ͢Δίʔυย΍ϦιʔεϑΝΠϧ΁ΞΫηεͨ͠ΓɼήʔϜΦϒδΣΫτͷҐஔ΍αΠζΛ௚઀ૢ࡞ͯ͠ιʔείʔυதͷఆ਺஋Λௐ੔Ͱ͖ΔɽຊߘͰ͸ɼεΫϦʔϯΩϟετΛ૊ΈࠐΜͩ౷߹։ൃ‫ ڥ؀‬CapStudio Λ࣮૷͠ɼຊख๏ͷՄ༻ੑΛ‫ͨ͠ূݕ‬ɽ

1

͸͡Ίʹ

ήʔϜ։ൃͳͲɼϏδϡΞϧͳཁૉΛଟ͘࢖༻͢
Δϓϩάϥϛϯά։ൃʹ͓͍ͯ͸ɼΩϟϥΫλը૾΍Ϙλϯͷ഑ஔͱ͍ͬͨɼ‫ͨݟ‬໨ʹؔΘΔ෦෼ͷௐ੔͸ඇৗʹॏཁͰ͋ΔɽΩϟϥΫλը૾͸഑৭Λඍົʹม͑Δ͚ͩͰେ͖͘ҹ৅͕มΘΔ͠ɼϘλϯͳͲͷ GUI ෦඼ͷ഑ஔํ๏ʹΑͬͯήʔϜͷૢ࡞ੑ͸େ͖͘มԽ͢Δɽ͔͠͠ैདྷͷίʔυϕʔεͷ։ൃ‫͍͓ͯʹڥ؀‬͸ɼ͜ͷΑ͏ͳϏδϡΞϧཁૉͷ։ൃΛࢧԉ͢Δ࿮૊Έ͸΄ͱΜͲͳ͔ͬͨɽ͜ͷͨΊɼͨͱ͑͹ϓϩάϥϜͷฤूதʹ͸ήʔϜը໘͸දࣔ͞Εͳ͍ͨΊɼΩϟϥΫλը૾΍ϘλϯͷදࣔҐஔΛमਖ਼͢ΔͨͼʹϓϩάϥϜશମΛϏϧυɾ࣮ߦͯ͠ήʔϜը໘Λදࣔ͠ɼ‫ݟ‬ӫ͑Λ֬ೝ͢Δඞཁ͕
͋ͬͨɽҰํɼUnity [9] ͳͲͷۙ୅తͳήʔϜΤϯδϯ
Ͱ͸ɼϓϩάϥϜͷฤूதʹήʔϜͷϓϨϏϡʔը໘͕ৗʹදࣔ͞ΕΔɽϓϩάϥϚ͸ύϥϝʔλͷमਖ਼݁ՌΛϦΞϧλΠϜʹ֬ೝͨ͠Γɼը໘্ͷήʔϜΦϒδΣΫτΛ௚઀ಈ͔͢͜ͱͰҐஔύϥϝʔλΛௐઅ͢Δ͜ͱ͕Ͱ͖Δɽ͔͠͠ɼ͜ΕΒͷγες
Ϝʹ͸ϑϨʔϜϫʔΫ্ͰܾΊΒΕ੍ͨ໿͕͋ΓɼήʔϜը໘ͷඳըͱ͍ͬͨϓϦϛςΟϒͳॲཧΛϓϩάϥϚ͕ฤू͢Δ͜ͱ͕Ͱ͖ͣɼίʔυϕʔεͷ։ൃ‫ʹڥ؀‬ൺ΂ͯίʔσΟϯάͷࣗ༝౓͕Լ͕ͬͯ
͠·͏ͱ͍͏໰୊͕͋ΔɽຊߘͰ͸ɼैདྷͷίʔυϕʔεͷ։ൃ‫ʹڥ؀‬ର∗

Copyright is held by the author(s).
Koumei Fukahori, Daisuke Sakamoto, Jun Kato,
Takeo Igarashi, ౦‫ژ‬େֶ

- 37 -

ਤ 1. CapStudio ͷΠϯλϑΣʔεɽͯ͠ήʔϜΤϯδϯͷΑ͏ͳର࿩ՄೳͳϓϨϏϡʔը໘Λఏ‫͢ڙ‬Δ͜ͱΛ໨తͱ͢ΔɽͦͷͨΊͷγεςϜͱͯ͠ɼର࿩ՄೳͳήʔϜը໘ͷ࿥ըө૾Ͱ͋ΔεΫϦʔϯΩϟετΛ૊ΈࠐΜͩ౷߹։ൃ‫ڥ؀‬
CapStudio ΛఏҊ͢Δ (ਤ 1)ɽϓϩάϥϜͷ࣮ߦதɼ
CapStudio ͸ήʔϜը໘ΛόοΫάϥ΢ϯυͰ࿥ը
͢Δɽ࣮ߦ‫ޙ‬ɼ࿥ըө૾͸εΫϦʔϯΩϟετͱͯ͠දࣔ͞ΕΔɽεΫϦʔϯΩϟετ͸Ұൠతͳಈը
ϓϨΠϠͱಉ༷ʹɼө૾Λ࠶ੜͨ͠Γɼ࠶ੜ࣌ࠁΛγʔΫόʔͰมߋͰ͖Δɽ
ͨͩ͠ɼ࣮ࡍʹγεςϜ͕‫ه‬࿥͢Δ৘ใ͸ɼήʔϜΦϒδΣΫτͷඳըҐஔ΍େ͖͞ͱ͍ͬͨඳըཤ
ྺͰ͋ΓɼγεςϜ͸͜ΕΛ༻͍ͯ࿥ըө૾Λੜ੒͍ͯ͠Δɽ·ͨɼ͜ͷඳըཤྺΛ༻͍Δ͜ͱͰɼεΫϦʔϯΩϟετͱίʔυΤσΟλΛ‫ڠ‬ௐͯ͠ಈ࡞͞
ͤΔ͜ͱ͕Ͱ͖Δɽ۩ମతʹ͸ɼϓϩάϥϚ͕ιʔείʔυ΍ը૾ͳͲͷϦιʔεϑΝΠϧΛฤू͢Δ

WISS 2013ͱɼଈ࠲ʹฤू݁Ռ͕εΫϦʔϯΩϟετʹ൓ө͞ΕΔɽ൓ରʹɼεΫϦʔϯΩϟετ্ͷήʔϜΦϒδΣΫτΛબ୒͢Δ͜ͱͰɼରԠ͢Δίʔυย΍ϦιʔεϑΝΠϧ΁ΞΫηεͰ͖Δɽ͞ΒʹɼήʔϜΦϒδΣΫτͷҐஔ΍େ͖͞Λ௚઀ૢ࡞ͯ͠ɼιʔείʔυதͷରԠ͢Δఆ਺஋Λॻ͖͔͑Δ͜ͱ͕Ͱ͖ΔɽຊߘͰ͸࡞੒ͨ͠γεςϜʹ͍ͭͯड़΂ɼͦͷ࣮૷Λઆ໌ͨ͋͠ͱɼ̏ͭͷαϯϓϧϓϩάϥϜ
Λ༻͍ͯຊγεςϜͷՄ༻ੑΛٞ࿦͢Δɽ

2

ήʔϜΤϯδϯͷγʔϯΤσΟλ΍ Visual Studio[11] ͳͲͷ GUI ΤσΟλ͕͋Δɽ͜ΕΒͷ։ൃ‫ڥ؀‬Ͱ͸ɼϓϩάϥϜͷฤूதɼ࣮ߦը໘ͷϓϨϏϡʔ͕ৗʹදࣔ͞Εɼύϥϝʔλͷमਖ਼݁ՌΛϦΞϧλ
ΠϜͰ൓өͨ͠ΓɼϓϨϏϡʔը໘্ͷήʔϜΦϒδΣΫτΛ௚઀ಈ͔ͯ͠ҐஔύϥϝʔλΛௐઅͰ͖Δɽ͔͠͠ɼ͜ΕΒͷγεςϜʹ͸ϑϨʔϜϫʔΫ্ͰܾΊΒΕ੍ͨ໿͕͋ΓɼήʔϜը໘ͷඳըͱ͍ͬ
ͨϓϦϛςΟϒͳॲཧΛϓϩάϥϚ͕ฤूͰ͖ͳ͍
ͨΊɼίʔυϕʔεͷ։ൃ‫ʹڥ؀‬ൺ΂ͯίʔσΟϯάͷࣗ༝౓͕Լ͕ͬͯ͠·͏ͱ͍͏໰୊͕͋Δɽ·ͨ, ϓϨϏϡʔը໘಺ͷ࣌ؒͷྲྀΕ͸ෆՄ‫Ͱٯ‬ɼຊγεςϜͷεΫϦʔϯΩϟετͱҧ͍ɼγʔΫόʔΛಈ͔ͯ࣌ؒ͠Λ‫͖ר‬໭͢͜ͱ͸Ͱ͖ͳ͍ɽ

ؔ࿈‫ڀݚ‬

ຊ‫ڀݚ‬͸ 2012 ೥ͷ Bret Victor ʹΑΔσϞϏσ
Φʠ Inventing on Principle ʡ[1] ʹ‫͘ڧ‬৮ൃ͞Ε͍ͯ
Δɽ͜ͷϏσΦͰ͸ɼຊγεςϜͷΑ͏ʹϓϩάϥ
Ϝͷ࣮ߦը໘Λ։ൃ‫ʹڥ؀‬ຒΊࠐΈɼίʔυΤσΟλͱ࿈‫ͤ͞ܞ‬Δख๏͕঺հ͞Ε͍ͯΔɽͨͩ͠ɼ͜
Ε͸͋͘·ͰίϯηϓτϏσΦͰ͋ΓɼγεςϜͷ
۩ମతͳ࣮૷ʹ͍ͭͯ͸‫͞ٴݴ‬Ε͍ͯͳ͍ɽҰํͰɼຊߘͰ͸ɼ͜ͷΑ͏ͳ࣮ߦը໘ͱίʔυΤσΟλͷ
࿈‫ػܞ‬ೳΛɼεΫϦʔϯΩϟετΛ༻͍Δ͜ͱͰ࣮‫͠ݱ‬ɼͦͷ۩ମతͳ࣮૷Λ͍ࣔͯ͠Δɽ
࣮ߦը໘ͷ࿥ըө૾Λϕʔεͱͨ͠ΠϯλϑΣʔεΛ࣋ͭγεςϜͱͯ͠ɼWhyline for Java [5] ͱ͍͏σόοάπʔϧ͕͋ΔɽWhyline ͸࣮ߦ࣌ʹ‫ه‬࿥࣮ͨ͠ߦཤྺΛղੳ͠ɼϓϩάϥϜͷ‫ڍ‬ಈͷ‫ݪ‬ҼͱͳΔίʔυยΛಛఆ͢Δɽͨͱ͑͹ɼϓϩάϥϚ
͕࿥ըө૾্ͷήʔϜΦϒδΣΫτΛબ୒͢Δ͜ͱ
ͰɼͦͷΦϒδΣΫτͷ৭΍ҐஔΛܾఆͨ͠ίʔυҐஔ΁δϟϯϓ͢Δ͜ͱ͕Ͱ͖Δɽ͔͠͠ɼWhyline͸ຊγεςϜͱ͸ҧ͍ɼιʔείʔυͷฤूΛ໨తͱͨ͠πʔϧͰ͸ͳ͍ɽͦͷͨΊɼίʔυͷฤू݁ՌΛଈ࠲ʹ࿥ըө૾ʹ൓өͨ͠Γɼө૾಺ͷήʔϜΦϒδΣΫτΛಈ͔ͯ͠ιʔείʔυதͷύϥϝʔλΛॻ͖͔͑Δ͜ͱ͸Ͱ͖ͳ͍ɽ
ϓϩάϥϜΛ໌ࣔతʹ࠶࣮ߦͤͣʹιʔείʔυͷमਖ਼݁ՌΛ‫͢ࢉܭ‬Δख๏ͱͯ͠ɼόοΫάϥ΢ϯ
υͰϓϩάϥϜશମΛ࠶Ϗϧυɾ࠶࣮ߦͯ͠࠶‫ࢉܭ‬Λߦ͏ํ๏͕͋Δ [3, 4]ɽ͔͜͠͠ͷํ๏͸ɼ֎෦ϓϩηεͱ௨৴Λߦ͏ϓϩάϥϜΛ։ൃ͢Δ৔߹ɼ
҉໧తͳ࠶Ϗϧυɾ࠶࣮ߦʹΑͬͯɼҙਤͤͣʹ֎෦ϓϩηεͷঢ়ଶΛม͑ͯ͠·͏‫ڪ‬Ε͕͋ΔɽҰํɼຊߘͰఏҊ͢Δख๏Ͱ͸ඞཁͳ৘ใΛ͢΂࣮ͯߦ࣌ʹ‫ه‬࿥͠ɼ‫ه‬࿥ͨ͠৘ใͷΈΛ༻͍ͯ࠶‫ࢉܭ‬Λߦ͏ͨΊɼ༧‫֎͍ͳ͠ظ‬෦ϓϩηεɾϦιʔεͷվม͸‫͍ͳ͖ى‬ɽ·ͨ, ϓϩάϥϜͷฤूঢ়ଶͱ࣮ߦঢ়ଶ
Λ۠ผ͠ͳ͍ Live Programming ‫[ ޠݴ‬2, 6, 8] ΋ɼίʔυฤूͷ݁ՌΛ࠶࣮ߦͤͣʹ࣮ߦը໘ʹ൓ө͢Δ͜ͱ͕Ͱ͖Δɽ͔͠͠ɼ্‫ه‬ͷख๏ͱಉ༷ʹɺϓϩάϥϜͷฤूதʹ༧‫֎ͣͤظ‬෦ϓϩηεʹӨ‫ڹ‬Λ͓Α΅͢‫ڪ‬Ε͕͋Δɻ
·ͨɼຊγεςϜͱ΋ͬͱ΋ؔ࿈ͷ͋ΔγεςϜ
ͱͯ͠ɼUnity [9] ΍ Unreal Engine [10] ͱ͍ͬͨఏҊγεςϜ CapStudio

3

CapStudio ͷ࣮ߦը໘Λਤ 1 ʹࣔ͢ɽϓϩάϥϚ͸·ͣίʔυΤσΟλʹιʔείʔυΛ‫ه‬ड़͠ɼͦͷ‫ޙ‬ɼεΫϦʔϯΩϟετΛར༻ͯ͠ήʔϜը໘ͷσβΠϯΛमਖ਼͢ΔɽఏҊख๏ͷ࠷େͷϙΠϯτ͸ɼήʔϜΤϯδϯͷ
γʔϯΤσΟλͷΑ͏ͳύϥϝʔλௐ੔༻ͷΤσΟλΛɼίʔυϕʔεͷ։ൃ‫ʹڥ؀‬ରͯ͠ఏ‫͢ڙ‬Δ͜
ͱʹ͋ΔɽҰൠʹɼඳըॲཧΛ‫ؚ‬Ίͨ͢΂ͯͷιʔείʔυ͕ϓϩάϥϚʹΑͬͯ‫ه‬ड़͞ΕΔ৔߹ɼϓϩάϥϜͷ‫ڍ‬ಈΛ੩తʹ༧ଌͯ͠ϓϨϏϡʔը໘Λ
ੜ੒͢Δ͜ͱ͸Ͱ͖ͳ͍ɽͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼ࣮ߦ࣌ʹग़ྗ͞ΕͨήʔϜը໘ΛٖࣅతͳϓϨϏϡʔը໘ʹ‫ཱͯݟ‬Δɽ·ͣɼγεςϜ͸ήʔϜը໘ͷඳըཤྺΛ࣮ߦ࣌ʹ‫ه‬࿥͠ɼ͜ΕΛར༻ͯ͠ήʔϜը໘ͷ࿥ըө૾ΛεΫϦʔϯΩϟετͱͯ͠ੜ੒͢Δɽ͞Βʹɼ‫ه‬࿥ͨ͠ඳըཤྺΛར༻ͯ͠εΫϦʔϯΩϟετͱίʔυɾϦιʔεؒͷ࿈‫ػܞ‬ೳΛ࣮‫͢ݱ‬Δɽ

3.1

εΫϦʔϯΩϟετͷੜ੒ϓϩάϥϚ͸·ͣɼίʔυΤσΟλʹ Processing‫[ ޠݴ‬7] ͰιʔείʔυΛ‫ه‬ड़͢ΔɽCapStudio ͷίʔυΤσΟλ͸ެࣜͷ։ൃ‫ ڥ؀‬Processing IDE
ʢPDEʣͱ‫׵ޓ‬ੑ͕͋ΔɽPDE Ͱ࣮ߦͰ͖Δίʔυ͸ CapStudio Ͱ΋࣮ߦͰ͖ɼͦͷ‫ٯ‬΋ਅͰ͋Δɽϝχϡʔόʔͷ࣮ߦϘλϯΛԡ͢ͱɼϓϩάϥϜ͕Ϗϧυɾ࣮ߦ͞ΕήʔϜը໘͕දࣔ͞ΕΔɽ
ϓϩάϥϜͷ࣮ߦ࣌ɼγεςϜ͸όοΫάϥ΢ϯυ
ͰήʔϜը໘ͷඳըʹؔΘͬͨؔ਺ (ҎԼɼඳըؔ਺)ͷ‫ͼݺ‬ग़͠ཤྺΛ‫ه‬࿥͢Δɽͨͱ͑͹ɼਤ 2 ͷΑ͏ʹήʔϜը໘্ʹը૾͕ͻͱ͚ͭͩදࣔ͞ΕΔϓϩάϥϜͰ͸ɼήʔϜը໘ͷେ͖͞Λࢦఆ͢Δ size()ɼ
ը૾σʔλΛϑΝΠϧ͔ΒಡΈࠐΉ loadImage()ɼ
ը໘ΛΫϦΞ͢Δ background()ɼը૾Λඳը͢Δ
image() ͷ͍ͣΕ͔͕‫ͼݺ‬ग़͞ΕΔͨͼʹɼͦͷίʔυҐஔɼฦΓ஋ɼԾҾ਺ͷࣜʹ‫·ؚ‬ΕΔม਺ͷ஋ͱ͍ͬͨؔ਺‫ͼݺ‬ग़͠৘ใΛ‫ه‬࿥͢Δɽ͜ΕʹΑ

- 38 -CapStudio: ϓϩάϥϜͷ࣮ߦը໘ͷ࿥ըө૾Λར༻ͨ͠౷߹։ൃ‫ڥ؀‬

ਤ 2. εΫϦʔϯΩϟετͷੜ੒Γɼඳը͞ΕͨήʔϜΦϒδΣΫτͷҐஔ΍େ͖͞ɼ͓ΑͼͦΕΛඳըͨ͠ίʔυ͕ಛఆͰ͖Δɽͨͩ͠ɼ
ήʔϜը໘ͷඳըʹ͸ Processig ͕ެࣜʹఏ‫ͯ͠ڙ‬͍Δ API ؔ਺͚͕ͩ࢖ΘΕΔͱԾఆ͍ͯ͠Δɽͭ·ΓɼιʔείʔυதͷͲͷؔ਺͕ඳըʹؔΘ͍ͬͯͯɼͲͷҾ਺͕Ґஔ΍େ͖͞Λࢦఆ͢Δͷ͔ͱ͍͏API ͷ࢓༷͸γεςϜ͕͋Β͔͡ΊΘ͔͍ͬͯΔɽ
΋͠ OpenGL ΍ Java Swing ͳͲผͷඳը API Λ࢖͏৔߹͸ɼ֤ API ؔ਺ͷ࢓༷Λผ్γεςϜʹ
૊ΈࠐΉඞཁ͕͋Δɽ
ϓϩάϥϜͷ࣮ߦ͕ऴྃ͢ΔͱɼγεςϜ͸‫ه‬࿥͞Εͨඳըཤྺ͔ΒɼήʔϜը໘ͷ࿥ըө૾͕εΫϦʔϯΩϟετͱͯ͠ੜ੒͞ΕΔ (ਤ 3)ɽεΫϦʔϯΩϟετ͸ಈըϓϨΠϠͷΑ͏ʹɼ࠶ੜϘλϯʢ!ʣ
Λԡͯ͠࿥ըө૾Λ࠶ੜͨ͠ΓɼγʔΫόʔΛಈ͔ͯ͠࠶ੜ࣌ࠁΛมߋͰ͖ΔɽͷҾ਺ͱɼx0ɼy0 ͱ͍ͬͨఆ਺ͷ஋͕ϋΠϥΠτ
͞ΕΔɽϓϩάϥϚ͕͜ΕΒͷ͍ͣΕ͔Λॻ͖͔͑ΔͱɼγεςϜ͸࠶౓ιʔείʔυͷߏจղੳΛߦ͍ɼ৽͍͠Ҿ਺ࣜɾఆ਺஋͓ΑͼલઅͰ‫ه‬࿥ͨ͠ඳը
ཤྺʹ͕ͨͬͯ͠εΫϦʔϯΩϟετΛ࠶ඳը͢Δ(ਤ 4-a)ɽಉ༷ʹɼϓϩάϥϚ͕ը૾ͳͲͷϦιʔεϑΝΠϧΛฤू͢ΔͱɼγεςϜ͸ฤू͞ΕͨϦιʔεΛಡΈࠐΈ௚ͯ͠ɼεΫϦʔϯΩϟετΛ࠶
ඳը͢Δ (ਤ 4-b)ɽ

ਤ 4. ίʔυɾϦιʔεฤू݁ՌͷεΫϦʔϯΩϟετ
΁ͷ൓өɽ

3.3

ਤ 3. CapStudio Ͱ։ൃͨ͠ϓϩάϥϜͷྫɽंͷը૾͕ਫฏํ޲ʹ౳଎Ҡಈ͢Δɽ

3.2

ίʔυɾϦιʔεฤू݁ՌͷεΫϦʔϯΩϟετ΁ͷଈ࣌൓өϓϩάϥϜͷ࣮ߦ‫ޙ‬ɼγεςϜ͸ɼήʔϜը໘ͷσβΠϯʹؔΘΔιʔείʔυΛϋΠϥΠτ͢ΔɽήʔϜը໘ͷσβΠϯʹؔΘΔιʔείʔυͱ͸ɼຊߘͰ͸ɼ1) ඳըؔ਺‫ͼݺ‬ग़͠จͷҾ਺ɼ2) ఆ਺એ‫ࣜݴ‬ͷӈลɼͷ̎ͭΛࢦ͢ɽͨͱ͑͹ɼਤ 3 ͷίʔυͰ͸ɼloadImage()ɼimage() ͱ͍ͬͨඳըؔ਺

- 39 -

εΫϦʔϯΩϟετΛ༻͍ͨίʔυɾϦιʔεͷฤूεΫϦʔϯΩϟετ಺ͷήʔϜΦϒδΣΫτ͸͢΂ͯΫϦοΧϒϧͰ͋ΓɼΫϦοΫ͢Δ͜ͱͰରԠ
͢Δίʔυ΍Ϧιʔε΁ΞΫηεͰ͖ΔɽࠨΫϦοΫ͢ΔͱɼͦΕΛඳըͨؔ͠਺‫ͼݺ‬ग़͕͠੺͘ϋΠϥΠτ͞Εɼͦ͜΁Χʔιϧ͕Ҡಈ͢Δ (ਤ 5-a)ɽ
ӈΫϦοΫ͢ΔͱɼରԠ͢Δը૾ϑΝΠϧΛ։ͨ͘Ίͷϝχϡʔ͕දࣔ͞Εɼબ୒ͨ͠ը૾ϑΝΠϧ͕֎෦ͷը૾ฤूιϑτͰ։͔ΕΔ (ਤ 5-b)ɽલड़͠
ͨΑ͏ʹɼ͜ΕΒͷίʔυ΍ը૾ϑΝΠϧ͕ฤू͞
ΕΔͱɼଈ࠲ʹ݁Ռ͕εΫϦʔϯΩϟετʹ൓ө͞ΕΔɽ
·ͨɼεΫϦʔϯΩϟετ͔Βίʔυ಺ͷఆ਺஋ΛௐઅͰ͖ΔɽεΫϦʔϯΩϟετ্ͷ͢΂ͯͷήʔϜΦϒδΣΫτ͸Ґஔ΍େ͖͞Λυϥοάૢ࡞ͰมߋͰ͖Δ (ਤ 6-a)ɽ͜͏ͯ͠ήʔϜΦϒδΣΫτͷҐஔɾ

WISS 2013ਤ 5. εΫϦʔϯΩϟετ͔ΒίʔυɾϦιʔε΁ͷΞΫηεେ͖͞Λมߋ͢Δͱɼಉ༷ͷ݁ՌʹͳΔΑ͏ʹιʔείʔυ͕ࣗಈͰॻ͖͔͑ΒΕΔ (ਤ 6-b)ɽσϑΥϧτ
Ͱ͸ରԠ͢Δؔ਺‫ͼݺ‬ग़͠จͷҾ਺ʹఆ਺஋͕Ճ͑
ΒΕΔɽॻ͖͔͑ΒΕͨҾ਺ΛӈΫϦοΫ͢Δͱɼผ
ͷॻ͖͔͑ύλʔϯ͕ྻ‫͞ڍ‬ΕΔ (ਤ 6-c)ɽྻ‫͞ڍ‬Ε֤ͨύλʔϯ͸ɼҾ਺ͷࣜʹొ৔͢Δఆ਺Λॻ͖͔͑
ର৅ͱ͢Δɽͨͱ͑͹ɼimage(img,x0+vx*t,y,w,h)ͱ͍͏ؔ਺‫ͼݺ‬ग़͠ʹΑͬͯඳը͞Εͨը૾Λɼࠨ୺ͷ X ࠲ඪ͕ 150 ʹͳΔΑ͏ʹҠಈͨ͠ͱ͢Δɽͨ
ͩ͠ɼx0ɼvx, t ͷ஋͸ͦΕͧΕ 50ɼ25, 2 Ͱ x0,
vx ͕ఆ਺Ͱ͋Δɽ͜ͷͱ͖ɼ·ͣୈೋҾ਺ʹ໨త஋ (150) ͱ‫ࡏݱ‬ͷ஋ (100) ͱͷࠩ෼ (50) ͕Ճࢉ͞Εɼrect(img,x0+vx*t+50,y,w,h) ͱॻ͖͔͑ΒΕΔɽͦͷ‫ޙ‬ɼࣜ x0+vx*t+50 ͕ӈΫϦοΫ͞ΕΔͱɼఆ਺ x0, vx Λॻ͖͔͑ର৅ͱͨ͠ύλʔϯ͕ͦΕͧΕʮfinal float x0 = 100ʯʮfinal float vx =50ʯͱදࣔ͞ΕΔɽͨͱ͑͹લऀͷύλʔϯΛબ୒
͢ΔͱɼୈೋҾ਺͕ॻ͖͔͑લͷࣜ x0+vx*t ʹ໭Γɼx0 ͷએ‫ ͕ࣜݴ‬final float x0 = 100 ʹॻ͖͔͑ΒΕΔɽͨͩ͠ɼҾ਺ʹ‫ݱ‬ΕΔఆ਺ͷ಺ɼ࣍ͷ 2 ͭͷ৚݅Λຬͨ͢΋ͷ͕ॻ͖͔͑ର৅ͱͳΔɽ1) ඳըؔ਺ͷҾ਺ͷΈʹӨ‫ڹ‬Λ༩͑Δɽ2) ఆ਺͕ͲΜͳ஋ʹͳΔ
΂͖͔‫ࢉܭ‬Մೳɽͨͱ͑͹ if จͷ৚݅ࣜʹ࢖ΘΕΔఆ਺͸ॻ͖͔͑ର৅ʹ͸ͳΒͳ͍ɽ·ͨɼ‫ࡏݱ‬ͷ࣮૷Ͱ͸ɼҾ਺͕ࣜఆ਺ʹؔ͢Δઢ‫ࣜܗ‬ͷ‫ͯͬͳʹܗ‬
͍Δ৔߹ͷΈ໨ඪ஋Λ‫͖Ͱࢉܭ‬Δɽͭ·ΓɼҾ਺ͷ͕ࣜ a * c1 + b / c2 Ͱ c1ɼc2 ͕ఆ਺ͩͱ͢Δͱɼ
c1 ͷΈ͕ॻ͖͔͑ର৅ͱͳΔɽ

4

࣮૷ਤ 6. εΫϦʔϯΩϟετΛ༻͍ͨίʔυฤू঺հͨ͠‫ػ‬ೳʹ͍ͭͯɼ࣮૷ΞϧΰϦζϜΛड़΂Δɽ

4.1

࣮ߦ࣌ʹඳըཤྺΛ‫ه‬࿥͢ΔͨΊɼϓϩάϥϜ͕Ϗϧυ͞ΕΔલʹɼඳըؔ਺ͷ‫ͼݺ‬ग़͠จʹରͯ͠ίʔυॻ͖͔͕͑ߦΘΕΔɽιʔείʔυதͷඳըؔ਺‫ͼݺ‬ग़͠จͷલ‫ʹޙ‬ɼͦͷ‫ͼݺ‬ग़͠จͷίʔυҐஔɼ‫ͼݺ‬ग़࣌͠ͷฦΓ஋͓ΑͼҾ਺ͷࣜʹొ৔͢Δม਺ͷ஋Λ‫ه‬࿥͢Δίʔυ͕ࣗಈૠೖ͞ΕΔɽ
‫ه‬࿥͞ΕͨඳըཤྺΛ༻͍ͯɼ‫ࡏݱ‬γʔΫόʔ͕͍ࣔͯ͠Δ࣌఺ʢϑϨʔϜʣͷήʔϜը໘Λ࠶‫͢ݱ‬Δɽ·ͣɼϓϩάϥϜͷ࣮ߦ͕ऴΘΔͱɼγεςϜ͸࣮ߦ࣌ʹඳըؔ਺ʹΑͬͯಡΈࠐ·ΕͨϦιʔεϑΝΠϧΛ͢΂ͯಡΈࠐΉɽ࣍ʹɼίʔυΤσΟλʹ‫ه‬ड़͞ΕͨιʔείʔυΛߏจղੳ͠ɼఆ਺ͷ஋ͱඳըؔ਺ͷҾ਺ࣜΛநग़͢Δɽͦͯ͠ɼ࣮ߦ࣌ʹඳըؔ਺͕‫ͼݺ‬ग़͞Εͨͱ͖ͷҾ਺஋ΛɼҾ਺ࣜʹఆ਺஋ͱ࣮ߦ࣌ʹ‫ه‬࿥͞Εͨม਺஋Λ୅ೖ͢Δ͜ͱͰ‫ٻ‬ΊΔɽͦͷ‫ޙ‬γεςϜ͸ɼಡΈࠐΜͩϦιʔεͱ‫ٻ‬ΊͨҾ਺஋Λ࢖ͬͯɼ໨తͷϑϨʔϜͷؒʹ‫ݺ‬ͼग़͞Εͨඳըؔ਺Λॱʹ࠶࣮ߦ͢Δ͜ͱͰɼεΫϦʔϯΩϟετΛඳը͢Δɽ

4.2

CapStudio ͸ Processing 2.0 beta 8 ͷ։ൃ‫ڥ؀‬
Ͱ͋ΔɽΠϯλϑΣʔε෦෼͸ C#ͷ WinForm ΞϓϦέʔγϣϯͱ࣮ͯ͠૷͞Ε͓ͯΓɼWindows 7͓Αͼ Windows 8 Ͱಈ࡞͍ͯ͠ΔɽҎԼɼલষͰ

ඳըཤྺͷ‫ه‬࿥ɾεΫϦʔϯΩϟετͷੜ੒ίʔυɾϦιʔεฤू݁ՌͷεΫϦʔϯΩϟετ΁ͷଈ࣌൓өϓϩάϥϚ͕ίʔυ΍ϦιʔεϑΝΠϧΛॻ͖͔͑ΔͱɼεΫϦʔϯΩϟετ͸࣮ߦ࣌ʹಡΈࠐ·ΕͨϦιʔεϑΝΠϧΛ͢΂ͯಡΈࠐΈ௚͢ɽͦͷ‫ޙ‬ɼ

- 40 -CapStudio: ϓϩάϥϜͷ࣮ߦը໘ͷ࿥ըө૾Λར༻ͨ͠౷߹։ൃ‫ڥ؀‬ιʔείʔυͷߏจղੳΛ࠶࣮ߦ͠ɼఆ਺ͷ஋ͱɼඳըؔ਺ͷҾ਺ࣜΛߋ৽͢Δɽͦͷ‫ޙ‬ɼ৽͍͠ఆ਺
஋ɾҾ਺ࣜΛ༻͍ͯɼ֤࣌఺ʹ͓͚Δඳըؔ਺ͷҾ਺஋Λ࠶‫͢ࢉܭ‬Δɽͦͷ‫ޙ‬ɼ‫ࡏݱ‬ͷϑϨʔϜͰ‫ͼݺ‬ग़͞Εͨඳըؔ਺Λॱʹ࣮ߦ͠ͳ͓ͯ͠ɼεΫϦʔϯΩϟετΛ࠶ඳը͢Δɽ

4.3

εΫϦʔϯΩϟετΛ༻͍ͨίʔυɾϦιʔεͷฤूϓϩάϥϚ͕εΫϦʔϯΩϟετΛΫϦοΫ͢Δ
ͱɼ‫ࡏݱ‬ͷϑϨʔϜͰൃߦ͞Εͨඳըؔ਺ͷ‫ͼݺ‬ग़͠Λ͢΂ͯ૸ࠪ͠ɼϚ΢εΧʔιϧͱ઀৮͍ͯ͠Δ
ήʔϜΦϒδΣΫτΛ୳͢ɽ‫͔ͨͬͭݟ‬ΒɼͦΕΛඳըͨؔ͠਺‫ͼݺ‬ग़͠จΛϋΠϥΠτ͢Δɽ͋Δ͍͸Ҿ਺ʹϦιʔεΦϒδΣΫτ (PImage ‫ܕ‬ͷը૾ΦϒΤδΣΫτͳͲ) ͕༩͑ΒΕ͍ͯΔ৔߹͸ɼͦͷ‫ݩ‬ϑΝΠϧͷϑΝΠϧύεΛදࣔ͢Δɽಉ༷ʹɼϓϩάϥϚ͕εΫϦʔϯΩϟετ্ͷήʔϜΦϒδΣΫτΛυϥοά͢Δͱɼ·ͣ͢΂ͯͷඳըؔ਺‫ͼݺ‬ग़͠Λ૸ࠪͯ͠ɼυϥοά͞ΕͨήʔϜΦϒδΣΫτΛ୳͢ɽ࣍ʹɼϚ΢εͷҠಈྔʹԠͯ͡ήʔϜΦϒδΣΫτͷ৽͍͠࠲ඪɾେ͖͞Λ‫ٻ‬ΊΔɽͦͷ‫ޙ‬ɼͦͷҐஔɾେ͖͞Ͱඳը͞ΕΔΑ͏ʹରԠ͢Δඳըؔ਺ͷҾ਺ͷ஋Λ‫ٻ‬Ίɼ‫ࡏݱ‬ͷҾ਺ͷ஋ͱͷࠩ෼ΛҾ਺ࣜʹՃࢉ͢Δɽಉ࣌ʹɼผͷॻ͖͔͑ύλʔϯʹ͍ͭͯɼॻ͖͔͑ର৅ͱ͢Δఆ਺ͷ໨ඪ஋Λɼͦͷఆ਺ʹؔ͢ΔҰ࣍ํఔࣜΛղ͘͜ͱͰ‫ٻ‬ΊΔɽ

4.4

ਤ 7. εΫϦʔϯΩϟετੜ੒ख๏ͷԠ༻

5.1

ਤ 8-a ͸ήʔϜͷλΠτϧը໘ʹ໛ͨ͠ GUI ϓϩάϥϜͰ͋ΔɽλΠτϧɾϝχϡʔ߲໨͕ͦΕͧΕϥϕϧɾϘλϯͱͯ͠දࣔ͞ΕɼͦΕͧΕͷҐஔͱେ͖͞͸ιʔείʔυதͰఆ਺ͱͯ͠ࢦఆ͞Ε͍ͯΔɽ͜ΕΒͷΦϒδΣΫτΛҰ౓࣮ߦ࣌ʹදࣔͤͯ͞͠·͑͹ɼ͋ͱ͸εΫϦʔϯΩϟετͰΦϒδΣΫτΛυϥοάͯ͠Ґஔɾେ͖͞ΛௐઅͰ͖Δɽ΋ͪΖΜɼ‫ط‬ଘ GUI ΤσΟλ΍ήʔϜΤϯδϯͰ΋ɼ͜ͷΑ͏ʹ GUI ෦඼ͷϨΠΞ΢τΛ௚઀ૢ࡞͢Δ
͜ͱ͸Ͱ͖Δɽ͔͠͠ຊ‫Ͱڀݚ‬͸ɼιʔείʔυ͕͢΂ͯϓϩάϥϚʹΑͬͯॻ͔ΕͨϓϩάϥϜʹରͯ͠ಉ༷ͷૢ࡞ΛՄೳʹͨ͜͠ͱ͕ॏཁͰ͋Δͱߟ͍͑ͯΔɽ

εΫϦʔϯΩϟετੜ੒ख๏ͷԠ༻̎ষͰղઆͨ͠ίʔυɾϦιʔεฤूͷͨΊͷ‫ػ‬ೳʹՃ͑ͯɼεΫϦʔϯΩϟετͷੜ੒ख๏ΛԠ༻ͯ͠ɼ࣍ͷ̏ͭͷ‫ػ‬ೳΛ࣮૷͍ͯ͠Δ (ਤ 7)ɽ1) ͋ΔΫϥεͷϝϯόؔ਺ͷதͰ‫ͼݺ‬ग़͞Εͨඳըؔ਺
ͷΈΛબ୒ͯ͠࠶࣮ߦ͢Δ͜ͱͰɼͦͷΫϥεͷα
ϜωΠϧը૾Λੜ੒͢Δɽ2) ଞͷϑϨʔϜͰඳը͞ΕΔήʔϜΦϒδΣΫτΛ‫ࡏݱ‬ͷϑϨʔϜʹॏͶͯඳը͢Δ͜ͱͰɼήʔϜΦϒδΣΫτͷ‫੻ي‬Λ࢒૾ͱͯ͠දࣔ͢Δɽ͞Βʹɼ3) ήʔϜΦϒδΣΫτͷ
ඳըҐஔΛͣΒ͢͜ͱͰɼࢹ఺Λೋ࣍‫ݩ‬తʹҠಈͤ͞ɼը໘֎ʹඳը͞Ε͍ͯͨήʔϜΦϒδΣΫτΛදࣔͤ͞Δ͜ͱ͕Ͱ͖Δɽ

5

ήʔϜͷλΠτϧը໘

2D ΞΫγϣϯήʔϜ
ਤ 8-b ͸؆୯ͳ 2D ԣεΫϩʔϧΞΫγϣϯήʔ

5.2

αϯϓϧϓϩάϥϜ

࡞੒ͨ͠γεςϜͷՄ༻ੑΛ‫ݕ‬౼͢ΔͨΊ̏ͭͷαϯϓϧϓϩάϥϜΛ࡞੒ͨ͠ (ਤ 8)ɽ̍ͭ໨ͷྫͰ͸ήʔϜը໘ͷϨΠΞ΢τɼ̎ͭ໨ͷྫͰ͸Ϧιʔεฤूʹ͓͚ΔɼεΫϦʔϯΩϟετͷ༗༻ੑΛٞ
࿦͢Δɽ̏ͭ໨ͷྫͰ͸ɼ࣮ߦ࣌ʹ֎෦ϓϩηεɾϦιʔεͱ௨৴͢ΔϓϩάϥϜͷ։ൃʹ͓͍ͯɼຊ
γεςϜ͕༗ޮͳੑ࣭Λ࣋ͭ͜ͱΛࣔ͢ɽ- 41 -

ϜͰ͋ΔɽϢʔβ͸ΩϟϥΫλΛૢ࡞͠ɼಓதͷఢΛ஄‫Ͱؙ‬౗͠ͳ͕ΒΰʔϧΛ໨ࢦ͢ɽΩϟϥΫλ΍
ఢͱ͍ͬͨήʔϜΦϒδΣΫτ͸͢΂ͯɼ֎෦ϑΝΠϧ͔ΒಡΈࠐ·Εͨը૾Λ࢖ͬͯඳը͞ΕΔɽ͜
ΕΒͷը૾Λฤू͢ΔͨΊʹ͸ɼ௨ৗ͸ϑΝΠϧϚ
ωʔδϟ͔Βը૾Λอଘ͍ͯ͠ΔϑΥϧμ΁Ҡಈ͠ɼ໨తͷը૾Λ։͘ඞཁ͕͋ΔɽҰํɼຊγεςϜͰ͸ɼεΫϦʔϯΩϟετ্ͷήʔϜΦϒδΣΫτ͔Β௚઀໨తͷը૾Λ։͘͜ͱ͕Ͱ͖ɼϢʔβʹͱͬͯͷෛՙ͕େ͖ܰ͘‫͞ݮ‬Ε͍ͯΔɽಛʹɼ஄‫ؙ‬ͷΑ͏ʹҰॠ͔͠‫ݱ‬Εͳ͍ήʔϜΦϒδΣΫτ͸ɼ࠶ੜ࣌ؒΛ‫͖ר‬໭ͤͳ͍ө૾಺Ͱଊ͑Δ͜ͱ͸೉͘͠ɼήʔϜΤϯδϯͷγʔϯΤσΟλΛར༻ͨ͠৔߹Ͱ
΋ɼήʔϜΦϒδΣΫτ͔Βը૾Λ௚઀։͘͜ͱ͸೉͔ͬͨ͠ɽ͔͠͠ຊγεςϜͰ͸ɼγʔΫόʔΛಈ͔ͯ͠࠶ੜ࣌ࠁΛௐ੔͢Δ͜ͱͰɼͦͷΑ͏ͳΦϒδΣΫτ΋εΫϦʔϯΩϟετ্Ͱ؆୯ʹଊ͑Δ͜ͱ͕Ͱ͖ΔɽWISS 2013

ਤ 8. αϯϓϧΞϓϦέʔγϣϯɽ

5.3

ωοτϫʔΫΫϥΠΞϯτ

ਤ 8-c ͸ωοτϫʔΫ௨৴Λߦ͏؆୯ͳϝσΟΞΞʔτ࡞඼Ͱ͋ΔɽKinect ͔Βऔಘ͞Εͨࠎ֨σʔλΛ༻͍ͯɼਓؒͷख͔ΒύʔςΟΫϧΛ์ग़͢Δɽ
ͨͩ͠ɼKinect ͷެࣜ SDK ͸ Processing ʹରԠ͍ͯ͠ͳ͍ͷͰɼࠎ֨σʔλ͸֎෦ͷ C#ϓϩηεʹ
औಘͤ͞ɼTCP ௨৴Ͱ Processing ϓϩηε΁ૹ৴
͍ͯ͠ΔɽϓϩάϥϜͷ࣮ߦΛऴྃ͢ΔͱɼC#ϓϩηεͱͷωοτϫʔΫ઀ଓ͕ःஅ͞ΕɼProcessingϓϩηε͸৽ͨͳਓؒͷࠎ֨σʔλΛऔಘͰ͖ͳ͘
ͳΔɽ͜ͷͱ͖ɼؔ࿈‫ڀݚ‬ͷষͰ঺հͨ͠όοΫάϥ΢ϯυͰϓϩάϥϜશମΛ࠶Ϗϧυɾ࠶࣮ߦ͢Δख๏Ͱ͸ɼϓϩάϥϚ͕ιʔείʔυΛฤूͨ͠ͱ͖
ʹਖ਼͘͠ฤू݁ՌΛ‫͍ͳ͖Ͱࢉܭ‬ɽҰํຊγεςϜ͸ɼ࣮ߦ࣌ʹࠎ֨σʔλͷ৘ใ͕ඳըཤྺͱͯ͠‫ه‬࿥͞Ε͓ͯΓɼ͜ΕΛ࢖ͬͯ‫ࢉܭ‬Λߦ͏ͨΊɼίʔυͷฤू݁Ռ͕εΫϦʔϯΩϟετʹਖ਼͘͠൓ө͞ΕΔɽ

6·ͱΊͱࠓ‫ޙ‬ͷ՝୊ຊߘͰ͸ɼ ର࿩ՄೳͳϓϩάϥϜͷ࿥ըө૾Ͱ͋ΔεΫϦʔϯΩϟετΛ૊ΈࠐΜͩήʔϜ։ൃͷͨΊͷ౷߹։ൃ‫ ڥ؀‬CapStudio ΛఏҊͨ͠ɽεΫϦʔϯΩϟετ͸ैདྷͷίʔυΤσΟλͱ‫ڠ‬ௐͯ͠ಈ࡞
͠ɼϓϩάϥϚ͸શͯͷϓϩάϥϜίʔυΛίʔυΤσΟλͰ‫ه‬ड़ͭͭ͠΋ɼήʔϜը໘ͷσβΠϯΛ
εΫϦʔϯΩϟετ্Ͱ௚‫ײ‬తʹमਖ਼Ͱ͖ΔɽຊఏҊͷ໰୊ͱͯ͠͸ɼεΫϦʔϯΩϟετ͕ιʔείʔυͷಛఆՕॴͷมߋ݁Ռ͔͠൓өͰ͖ͳ͍͜
ͱ͕‫͛ڍ‬ΒΕΔɽ‫ݱ‬ঢ়ͷ࣮‫ํݱ‬๏Ͱ͸ɼඳըؔ਺ͷ‫ͼݺ‬ग़͠จͱఆ਺ͷఆٛࣜͷมԽͷΈτϥοΩϯά
͍ͯ͠Δɽ͕ͨͬͯ͠ɼήʔϜΦϒδΣΫτಉ࢜ͷিಥ൑ఆͱ͍ͬͨϩδοΫʹؔΘΔίʔυΛॻ͖͔͑ͯ΋ɼεΫϦʔϯΩϟετʹ͸൓ө͞Εͳ͍ɽຊγεςϜ͸͋͘·ͰήʔϜΦϒδΣΫτͷ഑ஔ΍৭߹͍ͱ͍ͬͨɼը໘σβΠϯͷमਖ਼Λࢧԉ͢Δ͜ͱ
Λ໨తͱ͍ͯ͠Δɽ
‫Ͱ఺࣌ݱ‬͸ɼProcessing ͷඳը API ͷ಺ɼಛʹ‫ݱ‬ࡏ͸ɼը૾ಡΈࠐΈɾը૾ඳըͱ͍ͬͨɼ2D ήʔϜͷ։ൃʹඞཁͳඳըؔ਺ͷΈʹରԠ͍ͯ͠Δɽ͕ͨͬ͠
ͯࠓ‫ޙ‬͸ɼ3D ϞσϧͷඳըΛ‫ؚ‬Ίͨ Processing ͷඳը API ͷϑϧηοτ΁ͷରԠΛ༧ఆ͍ͯ͠Δɽͦ
Εͱฒߦͯ͠ɼεΫϦʔϯΩϟετ্ͷήʔϜΦϒδΣΫτΛࡾ࣍‫ݩ‬తʹૢ࡞͢ΔͨΊͷΠϯλϑΣʔε΋࣮૷͢Δɽ͞ΒʹɼOpenGL ΍ Java Swing ͱ͍ͬͨɼΑΓ௿Ϩϕϧͳඳը API ΁ͷରԠ΋‫ݕ‬౼͍ͯ͠Δɽࢀߟจ‫ݙ‬[1] Bret Victor - Inventing
http://vimeo.com/36579366.

on

Principle.

[2] J. Edwards. Subtext: Uncovering the Simplicityof Programming. In Proc. OOPSLA ’05, pp.
505–518, 2005.
[3] B. Hartmann, L. Yu, A. Allison, Y. Yang, and
S. R. Klemmer. Design as exploration: creatinginterface alternatives through parallel authoring
and runtime tuning. In Proc. UIST ’08, pp. 91–
100, 2008.
[4] J. Kato, S. McDirmid, and X. Cao. DejaVu:
integrated support for developing interactive
camera-based programs. In Proc. UIST ’12, pp.
189–196, 2012.
[5] A. J. Ko and B. A. Myers. Debugging reinvented: asking and answering why and why notquestions about program behavior. In Proc.
ICSE ’08, pp. 301–310, 2008.
[6] S. McDirmid. Living it up with a live programming language. In Proc. OOPSLA ’07, pp. 623–
638, 2007.
[7] Processsing. http://processing.org.
[8] Welcome to Self - Self - the power of simplicity.
http://selflanguage.org/.
[9] Unity3D Game Engine. http://unity3d.com.
[10] Game Engine Technology
http://www.unrealengine.com/.

by

Unreal.

[11] Microsoft
VisualStudio.
http://msdn.microsoft.com/ja-jp/vstudio.

- 42 -WISS2013

順解析と逆解析を相互に利用する打楽器のインタラクティブなデザインインタ
フェース
山本 和彦

五十嵐 健夫概要.
本稿では, 打楽器の形状と音色のデザインを効率的に行うために, コンピュータによって物体形状からそれを叩いたときの音色を計算する順解析と音色からそれを再現可能な物体形状を推定する逆解析を交互に行い, その支援を行うインタフェースを提案する. 本インタフェースでは, ユーザが物体形状を編集した場合には音色を, 音色自体を編集した場合には対応する物体形状をそれぞれインタラクティブにユーザにフィードバックする. 従来の打楽器を始めとする生楽器の設計では形状データの作成, 解析による確認, 出力による評価の 3 段階のプロセス間の非常に煩雑なトライ&エラーを繰り返す. これを効率化するために, 形状モ
デリングと同時にその音を解析して, 結果をインタラクティブにフィードバックするインタフェースも過去に提案されているが, 提示された情報を基にユーザはさらにどのような操作を加えれば目的とするものに近づけていくことができるのか, ということを判断するのは困難であるという問題がある. 本システムでは提示された音色情報自体をさらにユーザが編集してその影響を物体形状に反映させることを繰り返すことによってこの問題を解決する. 本稿で提案するような順問題と逆問題を相互に解いてデザインの支援を行うア
プローチは楽器のみならず多くの一般的な製品の設計においても役立つ可能性がある.

1

はじめに

Drag

Edit the shape

現在, 打楽器を含む多くの生楽器の設計プロセス
は, 形状モデリング, 解析, 出力/評価の 3 段階から成り立っている. このプロセスでは, まず最初に CAD
で形状データを作成する. その後, それを有限要素法等で解析してその音の情報 (モード周波数, 振幅)
や実際にそれをものとして出力しても破綻が無いかなどを確認, 最後にそれを実際に物体として出力して今度はその実際の音や演奏感を評価する. しかしながらこの 3 つのプロセスはそれぞれが乖離しており, プロセス間を横断したトライ&エラーは非常に労力がかかる. 例えば, 解析の結果が気に入らなかった場合には再び形状を修正し直してから再解析を行うということを繰り返す. また, 解析プロセスを一度パスできたとしても, その後に出力して実際の出音が所望のものでなかった場合には再び形状モデリ
ングと解析のプロセスを繰り返すことになってしまう. これは非常に煩雑な作業であり, 設計者はプロ
セス間を横断したトライ&エラーに労力が割かれてしまい, 本来の創造的なデザインに集中することが困難になってしまっているという問題がある.
この煩雑さを解消するために, 梅谷ら [1] は形状モデリングと同時にそれを叩いたときの音の基本周
波数の情報を音としてユーザにフィードバックすることによって形状モデリングと解析のプロセスを統合した. しかし, これだけではフィードバックされObjectForwardRe-editAnalyze the timbre

InverseAmplitude

Edit the timbre

Optimized
Estimate the shapeFrequency

図 1. 順解析と逆解析を繰り返して形状と音色両面から打楽器をデザインするた情報を基にユーザは, さらにどのような形状変形
操作を加えれば目的とする音に近づけていくことができるのか, を判断することが困難であるというさらなる問題がある.
そこで, 本稿では, 打楽器の形状と音色のデザイン
を効率的に行うために, コンピュータによって物体形状からそれを叩いたときの音色を計算する順解析と音色からそれを再現可能な物体形状を推定する逆解析を相互に行い, その支援を行うインタフェースを提案する. 本システムではユーザが物体形状を編集した場合には音色を, 音色自体を編集した場合には対応する物体形状をそれぞれインタラクティブにユーザにフィードバックする. これを使ってユー
ザは, 形状編集操作に応じて提示された音色情報自Copyright is held by the author(s).
Kazuhiko Yamamoto, Takeo Igarashi, 東京大学

- 43 -WISS 2013

体をさらに編集してその影響を物体形状に再び反映させることを繰り返すことによって, 形状と音色両面から打楽器をデザインしていくことが可能である(図 1).
本稿で提案するような順解析と逆解析を交互に解いてデザインの支援を行うというアプローチは, ユー
ザが解析手法独特のノウハウ等の余計な問題に煩わせられることなく常にその時々で着目しているデザ
イン要素にのみ集中することができるようになるという利点がある. これは音だけではなく例えば剛性や熱伝導性能といった問題にも置き換えることで,楽器のみならず多くの一般的な製品の設計においても役立つ可能性がある.

2

ಞ৒ֻࢁ

ɢĘɉߎ஢ࣞ
?knjgrsbc/

ϟ࢑&ಳխɑɯĘȹɚȯɈɩɠ'

.

YFx[

図 2. プロトタイプ画面

関連研究

Bp_e

コンピュータによって物体の振動音を計算するための最も代表的な手法は, 物体を有限要素法で離散化して固有値解析を行い, 算出されたモード (固有振動) の線形和としてその振動を近似するものである[3]. 固有値解析は非常に計算コストが高く一般的には前計算としてのみ行われる処理であり, インタラ
クティブな速度で計算を行いデザインツールに利用するためには高速化のアルゴリズムが必要である.
梅谷ら [1] は求める固有値を最低次の固有値のみに限定することで, ユーザが物体形状をモデリング
すると同時にインタラクティブな速度で固有値解析を行い, その結果をフィードバック可能にした. この研究ではユーザが鉄琴の形状モデリングを行うと同時にその基本周波数の情報を音としてフィードバッ
クすることによって, 複雑な形状の鉄琴であっても容易にその音高を調整することができる. しかし, 提示される情報が基本周波数のみであり, 楽器としての評価を行うためには不十分であった. C.B.Maxwell
ら [4] は固有関数が既知である物体形状からの微小な変形による影響をモード空間に射影して自由度縮小を行うことで準インタラクティブな速度で基本周波数だけではなく高次の周波数成分も計算しており,音色の評価をすることも可能である. しかし, 元の形状からの変形が大きくなると計算が破綻してしまうという問題がある.
コンピュータによるインタラクティブな物理シミュ
レーションをデザインツールに利用する研究は近年盛んに行われているが [6][13], そのほとんどが順解
析か逆解析のどちらかを単独で利用するものである.
順解析とは, 原因を与えてそこから結果を計算する問題であり, 物体の運動シミュレーション等多くの問題がこれに属する. その逆が逆解析であり, 結果
から原因を推定する問題である. 本研究で扱う音色
からの物体形状の推定もこの逆問題に属する.
Design by Dragging[5] は順解析と逆解析両方を同時にデザインに利用できるように一つの環境に統合した最初の研究である. この研究では医療機器のAmlrpmjNmglr

ֻࢁೈߦ?knjgrsbc/

ȷȹɆɠǙϟ࢑ȟ‫ܭב‬

.

YFx[

図 3. マウスによる物体形状モデリング

形状を予め細かくパラメータ化しておき, 前計算したシミュレーション結果の中からユーザが現在編集している状況に近いものを検索, 補間することで, ユー
ザが物体形状を編集した際には構造への負荷が, 結果として表示された構造への負荷状況を編集した場
合にはそれによる形状への影響がインタラクティブにフィードバックされる. これによってデザイナーは
解析ノウハウを一切気にするこの無く本来のデザイ
ン作業に集中できる. しかし, 予め細かくパラメータ化された形状は編集の自由度に乏しく, デザイナー
はツール制作者の想定を超えるような形状を作ることができないという問題がある.

3

ユーザインタフェース

図 2 が本研究で提案するインタフェースのプロト
タイプ画面である. これによって打楽器の形状と音色を編集する. 中央に編集する打楽器の形状が表示してあり, 左側に現在の形状でのモード周波数を低周波数から順に表示, 下側には実際に音色を鳴らしたときの音のパワースペクトラムの時間方向の平均
値およびその編集画面が用意されている. パワース
ペクトラムは横軸に周波数 (リニアスケール), 縦軸に正規化されたパワーを示している. 横軸は一番低い周波数のピークと高い周波数のピークが操作しや- 44 -

順解析と逆解析を相互に利用する打楽器のインタラクティブなデザインインタフェース
Microphone

テーブルを叩く音

音色変換

音色評価

ȷȹɆɠǙֻࢁǸ௷΍?knjgrsbc/

Bp_e
AmlrpmjNmglr

ϟ࢑ೈߦ

.

図 5. テーブルをあたかも打楽器のように叩くことで現在編集している音色を鳴らして確認する.

YFx[

図 4. 周波数領域での音色編集

がその音を使って音楽を演奏して評価するのが妥当である. そこで本研究では Possessing Drums[10]の手法を音色フィードバックの手段として採用する.
これは音響信号処理によって, マイクから入ってきた音 (例えばテーブルを叩いた音) から駆動音 (テーブルの振動特性を差し引いたもの) を抽出した後に,任意の音響伝達特性を再現できるような共振器に通して音色変換をすることによって身の回りの物体に任意の音を割り当てる研究である. これによって現在編集している物体の伝達特性 (それぞれのモード
周波数を持つ共振器) にマイクからの音を通すこと
で, PC を使って設計を行っているユーザは目の前のテーブルを叩いてシミュレーションされた音色で音楽を試奏することでその評価を行うことが可能となる (図 5).

すいように全体がスケーリングされている.
ユーザは中央の画面において物体の周囲の制御点(赤い点) をマウスでドラッグして 2 次元的に物体形状を変形する (図 3). また, 制御点を結ぶ辺の中間をクリックすることで物体周囲の任意の位置に制御点を追加することも可能である. ユーザが物体形状を変更するとそれを叩いたときの音色が再計算され,モード周波数とパワースペクトラムの表示が更新される. 一方, 下側のパワースペクトラム表示画面には周波数軸上で現在の形状でのモード周波数の位置に制御点 (赤い点) が設けられており, ユーザはこれをマウスでドラッグすることによりモード周波数の位置を移動させて音色自体を編集することができる(図 4). 音色が編集されるとシステムは現在の形状からできる限り近い形状でその音色を再現できるような形状を計算して画面中央に表示する. 音色編集
はあまりにも大幅な変更を許してしまうと計算が収束しないか時間がかかってしまうので現在のモード
周波数の近傍に編集範囲を制限する. ユーザはこの形状操作と音色操作の 2 つの操作を繰り返して最終的な目標の形状と音色を同時に作成していく.
ここで, ユーザにとってモード周波数を直接操作することは音色操作の方法として決して最適では無い. しかし音色と形状を結びつけるパラメータであるモード周波数を操作することは, 提案手法を実現する上で最も直接的であるためこの方法を採用した. また, モード周波数の位置はパワースペクトラ
ムのピーク位置近傍となる場合が多いが, 減衰が早いモードではピークとして表れてこない場合もあり,ユーザにとって操作しにくくなってしまうこともある. この点については今後の改善が必要である.
さらに, 音色の確認についてはモード周波数やパ
ワースペクトラムを視覚的に表示するだけでは不十分であり, 実際に音として耳で聴いて評価する必要がある. しかし, 楽器としてその出音が音楽的かどうかという評価を行うためには規則的に音を鳴らしたり, マウスでボタンをクリックしたときに音を鳴らす, というだけでは不十分であり, 実際にユーザ

44.1

アルゴリズム

音色のシミュレーション

物体の振動音をシミュレーションするためには有限要素法で線形弾性体として離散化して固有値解析を行うのが一般的である. しかし, 従来固有値分解
によって最低モードだけではなく高次モードも含めて求めることは非常に計算コストが高く, インタラ
クティブな計算に利用することは困難であった. そこで本研究では部分構造合成法 [2] を応用した前処理付きの高速な固有値解析手法を提案する.
有限要素法で離散化された自由度 N の固有値問
題は次のような一般化固有値問題に帰着することができる.
Kφ = λM φ(1)

K は N × N の剛性行列, M は質量行列, λ は固有値, φ は固有ベクトルである. ここで任意の数
n(n << N ) だけ固有ベクトルを並べた行列 U に
よって K ! = U T K , M ! = U T M , φ! = U φ と定義
すると式 1 は,K ! φ! = λM ! φ!

(2)と変形することができ, 本来の問題に比べて非常に小さな自由度の簡単な問題として解くことができる.

- 45 -WISS 2013

D

B
Joint

A

E

•••

B

C

Divide22

図 6. 部分構造の接合 (左) と分割 (右)

D
変形後形状

=

未変形部分

+

-

図 8. 変更後の形状は, 変形されていない部分 + (変形された部分を覆う正方形領域 D - 変形された部分を除きかつ変形されていない部分を除く D 内領域(青色)) となる.

れた行列 K B ! を構造 B 単独の固有値分解を行うことなく求めることができる. この未知の構造 B を覆う構造 D として前計算した正方形領域の結果を使うと, 図 8 のように変形後の形状は, 変形されていない部分 + (変形された部分を覆う正方形領域 D 変形された部分を除き, かつ変形されていない部分
を除く D 内領域 (図 8 の青色部分) ), となる. この第一項は既知であり, 第二項も差分モード合成法の分割処理で計算すれば固有値分解は不要であるのでこれは最終的に自由度が大幅に縮小された後の全体の式 3 の固有値分解を一度解くだけで計算が完了す
る. これによって従来より高速な固有値解析が可能となる.
ここで, 計算精度に関してはそれぞれの部分構造においてどれだけ自由度を残しておくかに依存する.
これはユーザが形状をどれだけ大きく変更したかということと計算コストのトレードオフで決定する.

2

3
0
0
0
T
T
K total = 4 0 U AC K CC U AC U AC K CB U BC 5
0 U TB K BC U AC U TB K BB U B
2 T
3U A K AA U A U TA K AC U AC 0T
+ 4 U AC K CA U A
0
0 5 (3)000

各行列の添え字は節点の属する分系を表す. また,
U AC は分系 A の固有関数の C 節点要素, U BC は分系 B の固有関数の C 節点要素である. 質量行列に関しては同様の形となるため省略する.
本研究では, 図 6 左における部分構造 A はユーザが編集する前の固有関数が既知の形状, B をユーザが編集した後に加わった部分形状と考えることができる. しかし新たに付け加えた形状 B の固有関数は未知であるためこの方法をそのまま利用することはできない. そこで本研究では未知の構造 B の固有関数を高速に求めるために前計算法を導入する.
まず, 前処理として計算領域全体を 2 次元の場合には正方形格子の有限要素法で離散化する. これは3 次元の場合には立方体格子となる. あらかじめ十分な大きさ N をとり, 22 , 32 42 ...N 2 節点の大きさの正方形形状それぞれにおいて十分な数の固有ベクトルを求めておく (図 7). ここで, 差分モード合成
法 [7] では図 6 右のように固有関数 U D が既知である構造 D から構造 E を取り除いたときの構造 B の自由度縮小された剛性行列 K B ! は,K B ! = U TD K B U A = U TD K D U D − U TD K E U D

N2

図 7. 前計算を行うグリッド

この問題を部分構造合成法を使って解く.
部分構造合成法 [2] は解析対象の構造体を複数の分系に分割し, 分系ごとに自由度縮小して重ねあわせることによって高速に解析を行う手法である. その中でも特に差分モード法 [7] ではある分系の固有関数が既知であった場合にその分系に関しては自由度縮小を行ったまま他の分系と合成することで計算コストを大幅に抑えることができる.
まず, 図 6 左のように物体 A に物体 B を接合し,その共有する節点群を添字 C で表すとする. ここで,分系 A の固有関数 U A と分系 B の固有関数 U B がそ
れぞれ既知であるとすると, 全体の剛性行列 K ! total
は自由度を縮小することができ, AB 全体の構造を一度に計算するより大幅に省メモリかつ少ない計算コストで処理することができる.
!

42

32

4.2

所望の音色を実現するための形状最適化

いくつかのモード周波数, つまりは与えられた音
色からそれに近いモード周波数を実現するような形状を推定する手法について説明する.
本研究では, ユーザが現在編集している形状からできる限り近い形状で所望のモード特性が得られる解をレベルセット法による形状最適化で求める. レ
ベルセット法 [8] とは二つの相で構成される閉じた領域においてそれぞれの相の形態と形状を表現する方法である. 本研究の場合は物体表面からの距離関数 φ(x) がこれに相当し, 物体の内部で正, 外部で負の値を取り, 表面で零になる. レベルセット法に基づく構造最適化手法 [11] は, トポロジー最適化法に代表される他手法 [12] で問題となる形状の波打ち問題やグレースケール (物体と空洞の中間領域) 問題が発生せず, 計算コストも少ないという利点がある.
ここで, 通常, 構造最適化問題では, 得られる構造が(4)と表すことができる.
つまり, 図 6 右における未知の構造 B を覆う構造
D の特性が分かっていれば構造 B の自由度縮小さ- 46 -

順解析と逆解析を相互に利用する打楽器のインタラクティブなデザインインタフェース

初期構造に大きく依存してしまうことが問題として挙げられるが, 本研究ではユーザが現在編集している形状から最も近い最適形状を得ることを目的としているためにこの点はむしろ利点となる
最適化はレベルセットの関数である目的汎関数
F (φ(x)) を最小化することによって行う. 線形弾性体の固有モード最適化問題においては目的汎関数
は, 現在の固有値と目的とする固有値間の残差となる [11].
M inimize F (φ) =

s+1
X
k=0

(

wk

λk − λtarget,kλ2target.k!)

方法によって固有値解析をやり直し, 現在の固有値と固有ベクトルを設定し直す. また, レベルセット境
界を更新すると, 境界から離れたところのレベルセッ
トの値が無効になるので Fast Marching Method[9]等を用いて全体を再初期化する必要がある.
ここで, レベルセット法では物体形状を距離関数によって陰的に表現しているため, 計算が収束した
後にユーザがさらに形状を編集できるようにするためにはレベルセット法から明示的に物体表面のメッシュを生成してやる必要がある. 本研究では陰関数からのメッシュ生成には Marching Cube 法 [14] を用いた. さらに Marching Cube 法で生成されたメッシュはレベルセット格子と同程度の解像度となっているために細か過ぎてユーザが頂点を操作しにくくなってしまうという問題があるがスムージングを行い, 荒いメッシュに近似することでこれを解決した.

(5)

ここで λk は k 番目の固有値, λtarget,k は目標とす
る k 番目の固有値, wk は重みパラメータである. sは目標とする固有値モードの数であるが, s + 1 まで考慮しているのは, 最適化の過程で固有ベクトルの形状が変化して次数が入れ替わってしまうことを防ぐためである. この最適化はレベルセット境界に適切な法線方向速度参照領域 VN (x, t) を与えて陽解法
で移流させることで行う.
レベルセットの時間発展を表すレベルセット方程式の弱形式は参照領域 D において
Z

5
5.1

となる. ここで, Ψ は試行関数である. 形状最適化問題においては左辺第二項は目的汎関数のレベル
セット関数に関する変分

D

(
Z X
s+1
f (φ(x))ψdΩ =
2wk
D k=0

λk − λtarget,kλ2target.k!

× ($(uk ) : D : $(uk ) − λk ρuk · uk ))× δ(φ(x))H(φ(x)) ψdΩ

表 1. 固有値解析の時間 [ms]節点数 (追加節点数)

6588(1314)
9026(2475)
13576(3081)(7)で表される. この f (φ(x)) は目的汎関数の形状感度の被積分関数であり, # はひずみテンソル, uk は k
番目の固有ベクトル, D は弾性テンソル, H(φ(x))と δ(φ(x)) はレベルセット関数が −h ≤ φ ≤ h(hは任意の実数) の領域で値を持つ Heavisible 関数とDirac Delta 関数 [11] である. 式 6 は有限要素法で離散化して,
φt+∆t = φt − ∆tE −1 V tN
ne Z
[
E =
N T N dΩ

(8)

V tN

(10)

=

ne Z
[

既存手法

2000
18000
37000

提案手法

400
840
1030

増加に応じて計算時間が大幅に増加しているが, 提案手法では僅かな増加で済んでいる.
一方, 形状最適化の精度に関しても評価も行った.
最低次から 8 つのモードを対象として目標値を定め,初期状態から最適化を行った結果が表 2 である. 結
果の 6 次モードに新たなモードが入ってきており,
次数が変わっているが, 目標とする固有周波数群自体はほぼ得られてることが分かる. 8 次の目標値も達成するためには最適化の対象にするモードの数をさらに増やす必要がある.

(9)

Ve

f (φ(x, t))N dΩ

システムの速度と精度

本稿で提案する手法で形状変形を行いながらモード周波数を算出していった場合と, それと同じ形状で従来の固有値解析を行った場合の節点数とおよその処理時間の関係を表 1 に示す. 括弧内の数字は変形前後で追加された節点数である. 評価に使ったシス
テムは, CPU: Intel Core i7 Quad 3.4GHz, RAM:
32GB で C++で実装し, 各形状において最低次から
8 つの固有周波数を求めた. 既存手法では節点数のZ
φ(x, t + ∆t) − φ(x, t)ΨdΩ+VN (x, t)ΨdΩ = 0 (6)
∆t
D
D

Z

結果

Ve

に従って目的汎関数が収束するまで各節点のレベ
ルセット関数を更新することで解く. ここで, N は!
形状関数,
は要素の重ね合わせを表す.
アルゴリズムの手順としてはユーザが現在編集している固有関数が既知の形状を初期条件とし, 式 10にてレベルセットを更新する. 更新の度に 4.1 章の5.2

エンジニアによる試用

本システムを実際に CAD や解析ソフトウェアの使用経験のあるエンジニア数名に試用してもらった
後, インタビューを行った. 被験者には自分の好みの打楽器を作ることを想定してデザインを行うよう- 47 -WISS 2013

るという問題もある. このため予めユーザに編集可
能な範囲をシステム側から提示できることが好まし
いが, 最適化を行う前の段階ではその音色が実現可能がどうかを知ることは難しく, 今後の課題である.

表 2. 固有周波数最適化の結果 (単位 [Hz])

1st
2nd
3rd
4th
5th
6th
7th
8th

初期状態

440
674
758
1119
4305
8656
9912
11279

目標値

409
738
967
1367
4776
9500
10649
12567

結果

410
764
955
1312
4633
5342
9408
10610

参考文献
[1] 梅谷信行, 高山健志, 三谷純, 五十嵐健夫. 実時間固有値解析による対話的な鉄琴のデザイン. 情報処
理学会論文誌, Vol.52, No.4, pp. 1599–1607, 2011.
[2] 長松昭男, 大熊政明. 部分構造合成法. 培風館,
1991.
[3] Changxi Z., and Doug L. J. Toward High-Quality
Modal Contact Sound. In ACM Transactions on
Graphics, 30(4), 2011.

に指示した.
彼らは普段の設計では既に過去に実績のある CAD
データを雛型として, それに編集を加えていくこと
で新しい製品を作っていくことが多いとのことである. そのため, 本システムのアプローチは目的となる音色側からも操作を加えていくことができると楽器音に不快な成分が含まれていた場合に抑えるのが容易になったり, または新たな楽器音を探していく
際にも非常に便利である, と意見を述べた. また, 逆解析の結果得られた形状そのものを再びインタラク
ティブに修正していけるため, 普段使っている解析ツールにも本システムが取り入れられると作業が容易になるとの意見を得た.
しかし, 実際の楽器は対称な形状のものがほとんどであるので, 対称性を前提にしたインタフェースにしたほうがよいとの意見も得られた. さらに, 生
楽器では形状を自由に設計するという需要はあまり無く, 例えばスピーカ筐体等の設計に利用する方がより有用であるとの意見も多かった. これらは今後の課題とする.

6[4] Cynthia B. M., and David B. Modal Parameter
Tracking for Shape-Changing Geometric Objects.
In Proc. of the 10th Int. Conference on Digital
Audio Effects (DAFx-07), 2007.
[5] Dane C., Chi-Lun L, Arthur G. E., Daniel F.
K. Design by Dragging: An Interface for Creative Forward and Inverse Design with Simulation Ensembles. In Transactions on Graphics
27(3), 2008.
[6] Greg S., Manfred L., Mitani J., and Igarashi T.
SketchChair: An All-in-one Chair Design System
for End-users. In the fifth International conference on Tangible, Embedded and Embodied Interaction, pp. 260, 2011.
[7] Mochizuki T., and Ogawa M. Efficient Approachfor Structural Modi cation Analysis. In Review
of Automotive Engineering, Vol.27, No.1, pp. 75–
82, 2006.
[8] Osher S., and Fedkiw R. Level Set Methods andDynamic Implicit Surfaces. In Springer, 2002.
[9] Sethian J. A. Level Set Methods and Fast Marching Methods. Cambridge Monographs on Applied
and Computational Mathematics. In Cambridge
University Press, 2nd edition, 1999.
[10] Yamamoto K. Possessing Drums: An Interfaceof Musical Instruments that Assigns Arbitrary
Timbres to Personal Belongings. In Journal of
Information Processing, Vol.21 No.2, pp. 274–
182, 2013.
[11] Yamasaki S., Nishiwaki S., Izui K., andYoshimura M. A structural optimization method
based on the level set method using a new type of
re-initialization scheme. In International Conference on Computational Methods, pp. 260, 2007.
[12] Yang R. J., and Chung C. H. Optimal Topology
Design using Linear Programming. In Computers
and Structures, Vol.53, pp. 265–275, 1994.
[13] Umetani N., Igarashi T., and Niloy J. M.
Guided Exploration of Physically Valid Shapes
for Furniture Design. In ACM Transactions on
Graphics 31(4), 2012.

まとめと今後の課題

本稿では, 物体形状からそれを叩いたときの音色を計算する順解析と音色からそれを再現可能な物体
形状を推定する逆解析を相互に行うことで形状と音色両面からの効率的な打楽器デザインを行うことのできるインタフェースを提案し, 実際にエンジニアにも試用してもらうことでその創造的なデザインに役立つ可能性があることを確認した.
しかし, 本システムの有用性を評価するためには
ソフトウェア上での評価だけでは不十分であり, 今
後は実際に作成した打楽器を実物として出力して評価を行っていく必要がある. さらに, 実際の楽器では数多くの部品が組み合わされているため, 本稿の手法だけでは実用的とは言えない. 複数の部品の組み合わせを考慮することは今後の課題である. また,音色からの形状推定ではユーザの操作次第では物理的に実現不可能な音色が設定されてしまうことがあ[14] W.Lorensen, H.Cline. Marching Cubes: A High
Resolution 3D Surface Construction Algorithm.
In Computer Graphics, 21 (4), pp. 163–169, 1987.

- 48 -WISS2013

SensingFork：フォーク型センサを用いた食行動改善手法の研究
門村 亜珠沙

李 爭原

陳 嚴章

塚田 浩二

朱 浩華

椎尾 一郎∗

概要. 『ピーマンも食べてね』と小さな子供に言葉で説得するのは難しい．もし，嫌いな食材を食べたと
きや夕ご飯を全部食べたときに，やる気の出るフィードバックを返したら，好き嫌いの多い子供の食行動も楽しく改善できるかもしれない．そこで我々は，子供の食行動の改善を目的に，食行動（食事中の動作と大まかな食材の種類）を検出するフォーク型デバイス：センシングフォークを開発した．本論文では，センシ
ングフォークのプロトタイプ設計と実装，このセンシングフォークと連動し，子供の食習慣改善を目指すス
マートフォン用アプリケーション：腹ペコパンダ，および，本システムの性能評価について述べる．

1

はじめに

バランスの良い食事は健康を維持する上で重要な要因である．現在，世界各国で食事の摂取方法・食材の選び方・食に関する文化など，広い視野から食について教育すること，つまり食育が重要な課題となっている．特に，先進国では，政府が web サイ
ト上でも食にまつわる多くの情報を公開するなどして，食育を推進している1 2 ．日本でも，2005 年に，バランスの悪い栄養摂取や野菜摂取量の不足などの不健康な食習慣の増加を危惧し，人々が活発で健康的な生活を楽しむことができるように，食育基本法が制定された3 ．その結果，現在では，多くの幼稚園では食育活動を行っており，例えば，教諭らは子供たちに様々な種類の食材を食べることを促している．しかし，食育活動を引き続き家庭内で行うのは，
時間・知識不足などの理由から親子にとって難しい[11]．そこで，我々は小さな子供にとって身近な食器であるフォークに着目し，家庭内での親子の食育支援を行うシステムを構築する．フォークのような
身近な日用品を HCI 技術で拡張することで，子供たちが楽しく食習慣を自然に改善することを目指す．
本研究では，食事中の動作と大まかな食材の種類を検出するために，カラーセンサ／電極／マイコン／ Bluetooth ／バッテリーなどをフォーク自体に組み込んだデバイス：センシングフォークの設計と実装を行った．さらに，センシングフォークと連動し，子供の食習慣改善を目指すスマートフォン用のアプ
リケーション：腹ペコパンダを実装した（図 1，[4]）．
Copyright is held by the author(s).
Azusa Kadomura and Itiro Siio, お茶の水女子大学,
Cheng-Yuan Li, Yen-Chang Chen and Hao-Hua Chu,
国立台湾大学, Koji Tsukada, 公立はこだて未来大学
1
The U.S. Department of Agriculture:
http://www.choosemyplate.gov
2
British Nutrition Foundation:
http://www.nutrition.org.uk/
3
日本内閣府: http://www8.cao.go.jp/syokuiku/index.html∗- 49 -

図 1. システムの外観

2

関連研究

近年，HCI の分野において，食に関する多くの研究が発表されている．Grimes らは，食事をコン
ピュータで拡張する，Human-Food Interaction の可能性について調査・議論を行っている [3]．Parker
ら [9] は，食事のオンライン広告に，栄養素や適切な食べ合わせを併せて示した場合の，子供たちへの影響を調査している．Mansour ら [7] は，栄養バラ
ンスの良悪を楽しみながら学ぶことができる子供や若者向けのコンピュータゲームを開発している．これらの研究以外にも，食育支援のための様々なサー
ビス4 5 が存在するが，その多くは PC やスマートフォン上のみで動作するものだった．
一方，人の食行動に対応したインタラクションを実現するために，食事の場にセンサやコンピュータを組み込むなど，ユーザの食行動に関する研究も多数行われている．Playful Tray[6] は，皿の横に取り付けたディスプレイから食事の進行に合わせて
視覚的フィードバックを与えることで，食べるのが遅い子供を支援している．Dining Presenter[8] は，
テーブル上方にプロジェクタを設置することで，事45

Fatworld: http://www.fatworld.org/
Shokuiku Town: http://www.glico.co.jp/shokuiku/game/WISS 2013

前に記入した絵やメッセージをテーブルに映し出し，食事を楽しくする効果や食育支援を目指している．
Hapifork[1] は，食材を口に運ぶ頻度から早食い行動を感知し，振動で知らせるフォーク型デバイスである．また，本研究に先立って我々は，ユーザが食材を食べた瞬時に音フィードバックを返すことで，食行動改善を目指すフォーク型デバイスを開発してきた [5]．これらのシステムは，少数のセンサにより特定の食行動を検出しているため，アプリケーショ
ンが限定されていた．そこで本研究では，人の食行動（食事中の動作と大まかな食材の種類）を検出す
る多様なセンサを搭載したフォーク型デバイスと，これを用いたアプリケーションを開発した．

3

システム概要本システムは，センサを組み込んだフォーク：センシングフォーク（図 2 左）と，フォークと連携して動くスマートフォンアプリケーション（図 2 右）から構築される．スマートフォン上のソフトウェアには，主に 3 つのモジュールがある．!フォークのセン
サデータからユーザの食行動を推定する「食動作検出部」，"フォークと接触した食材を大まかに判別する「食材判別部」，および，#子供の食習慣の向上を目指した食育ゲーム：腹ペコパンダである．これらを組み合わせて，ユーザが「何を」「どのように」食べているのかを検出し，適切なフィードバックを返すことで食育を支援する．次に，センシングフォー
クのプロトタイプの設計と実装について述べる．

クの持ち手サイズは L80 × W25 × H15 mm に収めることで，小さな子供でも容易に握れるように設計した．以下，各モジュールについて詳細に説明する．

4.1
4.1.1

ハードウェア電極

センシングフォークは，先端部分と握り部分に計
3 つの電極を備える（図 2 左上）．先端部分の両端 2つの電極は，食材とフォークが接触したことを検出し，同時に食材の電気抵抗値を測定している．電気抵抗値は食材により異なるため，食材の推定に利用できる可能性がある．一方，握り部分の電極は，先端部分が食材を介してユーザの口に触れたとき，握り部分→手→腕→口→食材→先端部分と微弱な電流を流す．ここで，握りと先端の電極間の電気抵抗値を測定することで，フォークと食材がユーザの口に接触したこと（＝摂食動作）を検出できる．以上の電極部分の構成と，周辺回路について，図 3 に示す．

図 3. 電極とその周辺回路図!と"はフォーク先端部分の電極を示し，#はフォーク握り部分の電極を示している

4.1.2
図 2. システム構成
左：センシングフォーク本体のプロトタイプ
右：スマートフォン上のソフトウェア

4

センシングフォーク

図 2 に示すように，センシングフォーク本体は，様々なセンサやハードウェア部品を内蔵している．
得られたセンサデータは，スマートフォン上に送信され，そこで食動作と食材の検出が行われる．フォー- 50 -

カラーセンサフォークの先端部分中央には，カラーセンサと白色 LED を並べて組み込んだ（図 2 左上）．カラーセン
サ（Avago ADJD-S311-CR999）は L2.2 × W2.2
× H0.76 mm と超小型であり，フォークに接触した食材の色（RGB 各色と輝度）を 1024 段階で検出し，
I 2 C を介してマイコンに送信する．フォークが食材の中に差し込まれると，白色 LED が点灯し，食材からの反射光をカラーセンサで測定する．なお，先端部の電極・およびカラーセンサ基板は，白色レジンでフォークの形状に固定した後，透明レジンで表面をコーティングした．レジンは共に歯科用の素材を利用することで，食の安全と防水に配慮した．

SensingFork：フォーク型センサを用いた食行動改善手法の研究

図 4. フォークの状態から導かれる食動作の遷移

4.1.3

モーションセンサ

フォークの握り内部のメイン基板上には，モーションセンサ（3 軸加速度＋ 3 軸ジャイロセンサ:
InvenSense MPU-6050）を設置した．これらのセンサデータはフォークの動きを検出し，I 2 C を介してマイコンに送信され，食動作の推定に活用する．
食動作検出の詳細は，4.2.1 で説明する．

4.1.4

その他のモジュール

握り内部のメイン基板上にはマイコン，Bluetoothモジュール（SeeedStudio Serial port bluetoothmodule），リチウムイオン充電池，およびワイレ
ス充電機構を搭載した（図 2 左下）．マイコンは Atmel ATMega328 を利用し，Arduino 互換機として実装した．Bluetooth モジュールは，上述したセン
サデータをまとめてスマートフォンに送信する．リ
チウムイオン充電池はサイズを考慮して 120mAh のものを選択し，毎秒 10 回の無線送信を行っても 2 時
間以上連続動作することを確認した．バッテリーを内蔵し，無線通信機能を備えることで，通常のフォー
クとできるだけ同じように扱えるように配慮した．

• 把持状態（Holding）：

把持状態とは，食材を刺していないフォーク
をユーザが手に持っている状態のことである．
この状態からは，ユーザがフォークを持ち上げていて，何かしらの食材をフォークで食べようと考えていると推定できる．フォークのモーションセンサがフォークの動きや手振れを感知した場合，把持状態にあるとシステム
は判定する．

• 刺突状態（Poking）：

刺突状態とは，ユーザが食材をフォークで刺した状態のことである．この刺突状態からは，ユーザが食材を刺したが，まだ口に運んでいないことを推定できる．フォーク先端の 2 つの電極間に一定の電流が流れることで，刺突状態にあるとシステムは判定する．なお，刺突状態をトリガーとして，次項（4.2.2）で説明する食材判別を開始する．

• 摂食状態（Biting）：

4.2 ソフトウェア
4.2.1 食動作検出部

食動作検出は，フォークから Bluetooth 経由で送信されるセンサデータを元に，スマートフォン上のアプリケーションで判定する．本システムでは，
フォークの状態から以下の 4 種類のユーザの食動作を推定する．図 4 に食動作の一覧と遷移を示す．以下，食動作検出と推定方法について述べる．

• 休止状態（At-rest）:

休止状態とは，ユーザがフォークを握っていない（フォークが静止している）状態のことである．ユーザが使う食器がフォークだけと仮定すると，ユーザが食事のための動作をしていないと推定できる．フォークのモーショ
ンセンサが，一定時間動きを検出しない場合，休止状態にあるとシステムは判定する．

- 51 -

摂食状態とは，フォークに刺さっている食材がユーザの口に接している状態のことである．
この摂食状態からは，ユーザがフォークに刺さっている食材を食べていることが推定できる．フォーク握り部分の電極と先端部分の電極間に微弱な電流が流れることで，摂食状態にあるとシステムは判定する．

これら 4 つの食動作の判定をより正確にするために，次の 2 つの仕組みを導入した．まず，各状態の間の遷移に図 4 のような制約を設けることで，誤認識を軽減する．すなわち，休止状態からは把持状態へしか遷移せず，把持状態からは刺突状態か休止状
態へしか遷移しない．例えば，フォークで食材を刺さない（＝刺突状態にならない）限り，把持状態から摂食状態へは移行しない．これにより，例えば子供が食材を刺さずにフォーク先端をなめる動作と摂食動作を区別することができる．次に，摂食状態においては，フォーク握り部分と先端部分の電極に人体を介して微弱な電流が流れるため，フォークの把持者と摂食者が同一であることが判定できる．

WISS 2013

4.2.2

食材判別部

本研究では，ユーザにバランスの良い食事摂取を促す目的で，2 通りの手法を試作した．1 つ目は食材種類判別手法であり，食事前に初期化プロセスを設け，各食材の色と電気抵抗値を登録する．次に，ユーザが食事中，食材を刺す度に，初期データと照合することで食材種類の判別を行う．機械学習アル
ゴリズムとしては，サポートベクターマシーンを利用し，LIBSVM[2] を用いて実装した．2 つ目は食材
色判別手法であり，初期化は行わず，ユーザが食事中に食材を刺す度に，その食材の色を記録する．なお，ノイズを軽減するために，過去 15 回の色デー
タを平滑化して利用する．
食材色判別手法では，食事中に取得した色データ
を随時読み取ることで，色の絶対値から食材の大まかな種類を推定する．本手法では厳密に食材を判別することは難しくなるが，見た目の色の違う多くの食材を食べることで食育を支援する食材 5 色バラン
ス健康法 [10] も提案されており，色ベースとした判定手法には一定の有効性があると考える．また，初期登録の手間がないことから，導入や運用も容易である．よって，本論文では，食材色判別手法を用いて，後述の食育ゲームを実装した．

5

2. 子供が食材を刺すと，パンダも子供が刺した食材と同じ色8 の笹を持つ．
【刺突状態】

3. 子供がその食材を摂食すると，パンダもその笹を食べ『おいしい！』と話す．
【摂食状態】

4. フォークの状態が把持状態に移行すると，パンダは笹ポイントを取得し，笑顔になる．
【把持状態】

食育ゲーム：腹ペコパンダ

本章では，健康的な食生活のために様々な色の食材を摂取することを促す，センシングフォークと連動した食育ゲーム「腹ペコパンダ」について説明する（図 1，図 5）．腹ペコパンダでは，スマートフォ
ン画面上に表示されたパンダが，食材を把持したり，摂食したりなど，ユーザ（子供）と同じ食行動を行う．ここで，お腹を空かせたパンダに子供が共感することで，実際の子供の行動に影響を与えることを目指した．仮想ペットとしてパンダを題材とした理由は，アジア諸国の子供に親しまれているキャラク
ターだからである．腹ペコパンダは「偏食」「注意散漫」という子供の一般的な食の問題7 の改善を目指す．まず，子供が別の色の食材を食べると，ゲームの得点が増える．これにより，高得点を得るために，より多くの食材摂取を動機付ける．次に，子供が食事時間中に一定時間摂食行動を停止したときに，パンダが悲しむことで，子供に食事に戻ることを促す
フィードバックを返す．
以下に，フォークの状態と腹ペコパンダの画面（図5）の関係について説明する．

1. まず，お腹を空かせて悲しんでいるパンダが登場し，子供が食べ始めるまで，『僕は腹ペコ
パンダ、お腹が空いたよ。』と話す．
【フォークの状態：休止・把持状態】

7

図 5. 腹ペコパンダの画面例

5. 同様に，子供が別の食材を刺すと，パンダは子供が刺した食材と同じ色の笹を持つ．
【刺突状態】

6. 子供がその食材を摂食すると，パンダもその笹を食べ，『これもおいしいね！』と話す．
【摂食状態】

7. 子供が食事を中断すると（＝一定時間，休止・把持状態が続くと），パンダは泣きながら，『もっと食べたいよ！』と子供がまた食べ始めるまで訴えかける．
【休止・把持状態】

8. 子供が再び最初の食材を摂食すると，パンダは最初の笹と同じ色の笹を食べるが，笹ポイ
ントは増えない．
『他の食材も食べたいよ！』と話すことで，多様な食材の摂食を促す．
【摂食状態】

最後に，終了ボタンを押すと，腹ペコパンダが獲得した笹ポイントの数に対応したアニメーションが表示される．つまり，万遍なく食べることで得られる笹ポイントの数に従って，最後に表示されるアニ
メーションが変わる．これにより，子供がより多くの食材を摂食する動機付けを行っている．
8

厚生労働省：2005 年度乳幼児栄養調査結果
http://www.mhlw.go.jp/toukei/list/83-1.html- 52 -

現システムでは，カラーセンサが検出した RGB 値を予め設定した閾値で分類して，5 色バランス健康法に基づく
5 色【赤・白・黄・緑・黒】の笹にマッピングしている．

SensingFork：フォーク型センサを用いた食行動改善手法の研究
表 1. 各食動作認識の成功回数と各認識に要した平均時間

User A

User B

User C

User D

User E

User F

各状態の平均Holding 1【把持状態１】
Poking【刺突状態】
Biting【摂食状態】
Holding 2【把持状態２】
At-rest【休止状態】

5(0.3sec)
5(0.6sec)
5(0.3sec)
5(1.1sec)5(1.5sec)5(0.5sec)
5(0.3sec)
4(0.9sec)
5(1.8sec)
5(1.4sec)

5(0.3sec)
5(0.9sec)
3(0.9sec)5(1.5sec)5(1.5sec)5(0.5sec)
5(0.6sec)
4(1.2sec)
5(1.1sec)5(1.5sec)

5(0.6sec)
5(0.6sec)
4(1.1sec)5(0.5sec)
5(1.1sec)

5(0.4sec)5(0.5sec)
3(0.7sec)
5(1.2sec)
5(1.4sec)

5.0(0.4sec)
5.0(0.6sec)
3.8(0.9sec)
5.0(1.2sec)
5.0(1.4sec)

各ユーザの平均5.0(0.8sec)

4.8(1.0sec)

4.6(1.0sec)

4.8(1.0sec)

4.8(0.8sec)

4.6(0.8sec)

このように，本ゲームはセンシングフォークによって推定・検出されたユーザの食行動を基に，視覚・聴覚的なフィードバックを返し，食事時間中に食育を支援することを目指す．すなわち，子供は楽しく
食行動を改善でき，親はパンダの獲得した笹ポイン
トを見ることで，日々の子供の食行動を継続的に把握することができる．付随的な効果としては，子供の食行動が改善された場合には，本ゲームによるご褒美（笹ポイントと最後のアニメーション）に加えて，親がお菓子などのご褒美を子供に与えるなどして，親子が食育に楽しく取り組むきっかけにつながると期待できる．

6

評価実験

センシングフォークの性能を評価する基礎的な評
価実験を行った．本章では，食動作検出と食材判別の精度について述べる．

6.1

各認識に要した平均時間を表 1 に示す．ユーザ毎に25 回の食動作（上述した 5 食動作を 5 セット）が行
われた．その結果，全体としては 95%の認識率だっ
た．一方，【摂食状態】において 23%の誤認識があり，【刺突状態→摂食状態】と認識されずに【刺突状態→
把持状態２】と誤認識されていた．認識されなかったユーザの【摂食状態】をビデオ動画から観察した
ところ，誤認識された摂食時間の平均は 0.1 秒であり，正しく認識された場合の平均は 0.9 秒であった．
したがって，フォークを一瞬しか口につけなかった
場合に，誤認識が発生した．現在の実装では，バッ
テリーの消耗を考慮して，スマートフォンとの通信
頻度を秒間 10 回（0.1 秒間隔）に抑えており，この結果，ユーザが素早く行動した場合に十分な測定が行えなかったと考えられる．センシング頻度を上げることで，食動作の認識は改善できると考えている．
参考として，ユーザ C の食動作遷移例を図 6 に示す．

食動作検出について

食動作検出の精度を確認するために，6 人のユー
ザ（男女各 3 名，21〜28 歳）にセンシングフォーク
で食材（一口サイズのチーズ）を 5 回食べてもらった．一連の食動作の認識精度を確認するため，各ユー
ザには 1 回食べるごとに，フォークを机に置くように指示した．すなわち，一度食材を食べる度に【把持状態１→刺突状態→摂食状態→把持状態２→休止状態】の順で一連の食動作が行われた．なお，全てのユーザはセンシングフォークを初めて利用し，システムの機能も事前に説明しなかった．
実験では，各ユーザの動作とスマートフォン上の実験用ソフトウェア画面を同時にビデオ撮影した．
実験用ソフトウェアには，現在の食動作の状態とセンサデータがテキストで表示されている．実験終了
後，実際のユーザの行動とソフトウェア上に表示された食動作を PC 上でフレームごとに目視で比較した．なお，ユーザの食動作の遷移は，【把持状態１：
フォークが机から離れた瞬間】【刺突状態：フォー
ク先端が食材に触れた瞬間】【摂食状態：ユーザが食材を噛んだ瞬間】【把持状態２：ユーザの口からフォークが離れた瞬間】【休止状態：フォーク本体が机に置かれた瞬間】というフレームで判定した．
まず，各食動作が認識された回数と，システムが- 53 -

図 6. ユーザ C の食動作遷移の一例
上段が認識成功時，下段が認識失敗時の事例．各 2
列の横棒は上がシステムの認識結果，下が実際のユーザの食動作を示す．下段では，【摂食状態】が0.07 秒と短時間で行われため，認識されていない．

また，表 1 に示す通り，各動作認識に要した時間の平均は 0.9 秒であった．各動作の中でも，【休止状態】の認識は平均 1.4 秒と時間がかかった．この理由は，1 秒以上フォークが静止したときに【休止状態】と判断しているからである．こちらも待機時間を調整することで，認識速度を改善できる可能性はあるが，一般にフォークを机に置く／取る行為が高速で繰り返されることは少ないので，実用上問題ないと考えている．また，【把持状態２】も平均 1.2 秒

WISS 2013と時間がかかっているが，これは実験プログラムの不具合（摂食時に 2.2 秒程度のアニメーションが表示され，終了まで状態表示が更新されなかった）が原因であり，実際の認識は【把持状態１】や【刺突状態】と同程度の時間で完了できると思われる．

6.2 食材判別について
4.2.2 で述べた食材色判別手法の性能を確認するために，市販のお弁当から色が異なった食材を 5 種類（ハンバーグ【赤】，米【白】，かぼちゃ【黄】，
ブロッコリー【緑】，しいたけ【黒】）用意した．な
お，【】内の色は前述の食材 5 色バランス健康法 [10]での分類を示す．実験者は，各食材の同じ面の違う箇所を 10 回ずつセンシングフォークで刺し，RGB値を記録した．まず，同一食材毎の検出誤差（標準偏差）としては，米が平均 0.9，かぼちゃが平均 6.5と安定していたのに対し，ハンバーグは平均 14，しいたけは平均 15，ブロッコリーは平均 25 と誤差が大きくなった．これは，ハンバーグの上のケチャッ
プや，ブロッコリーの葉部分の隙間，シイタケの表面／内部の色の濃淡の違いといった食材の特性に影響を受けたと考えられる．

図 7. 各食材の RGB の平均値と標準偏差次に，現在の腹ペコパンダで採用している，各食
材を 5 色【赤・白・黄・緑・黒】にマッピングする方法を適用したところ，米【白】，カボチャ【黄】は10 回中 10 回，ブロッコリー【緑】は 9 回認識に成功した．一方，シイタケ【黒】は 10 回中 5 回，ハンバーグ【赤】は 10 回中 4 回しか認識出来ず，大半が相互に誤認識していた．現在の食材色判別手法は単純な閾値で判定しているため，今後は色空間上の距
離や機械学習などを利用して認識率を改良したい．

7

まとめと今後の課題

本論文では，センサ内蔵フォークを用いてユーザの食行動を検出するセンシングフォークの設計と実装について述べた．また，子供の食事中の「偏食」「注意散漫」といった問題行動を改善することを目指した「腹ペコパンダ」ゲームも実装した．さらに，- 54 -

フォークの基礎的な性能を検証するために評価実験を行い，食動作検出と食材の色による分類について，改良の余地はあるものの，一定の性能があることを確認した．
今後は，実際に子供を対象とした，家庭内での評価実験を計画している．さらに，食事中の更なる問
題行動を検出したり，食材の摂食順序を記録したりすることで，新たな食行動改善アプリケーションの可能性を探る．

謝辞
本研究は，JSPS 科研費 25・10205 と科学技術振興機構さきがけプログラムの助成を受けた．

参考文献[1] Hapifork. http://www.hapilabs.com/.
[2] C.-C. Chang and C.-J. Lin. LIBSVM: A libraryfor support vector machines. ACM Trans. Intell. Syst. Technol., 2(3).
[3] A. Grimes and R. Harper. Celebratory technology: new directions for food research in HCI. In
Proceedings of CHI ’08.
[4] A. Kadomura, C.-Y. Li, Y.-C. Chen, H.-H. Chu,
K. Tsukada, and I. Siio. Sensing fork and persuasive game for improving eating behavior. In
Proceedings of Ubicomp ’13.
[5] A. Kadomura, K. Tsukada, and I. Siio. EducaTableware: computer-augmented tableware
to enhance the eating experiences. In Extended
Abstracts on CHI ’13.
[6] J.-L. Lo, T.-Y. Lin, H.-H. Chu, H.-C. Chou, J.H. Chen, J. Y.-J. Hsu, and P. Huang. Playful
tray: adopting Ubicomp and persuasive techniques into play-based occupational therapy for
reducing poor eating behavior in young children.
In Proceedings of UbiComp ’07.
[7] A. Mansour, M. Barve, S. Bhat, and E. Y.-L.
Do. MunchCrunch: a game to learn healthyeating heuristics. In Proceedings of IDC ’09.
[8] M. Mori, K. Kurihara, K. Tsukada, and I. Siio.
Dining Presenter: Augmented Reality system
for a dining tabletop. In Proceedings of UbiComp ’09.
[9] A. G. Parker, I. McClendon, C. Grevet, V. Ayo,
W. Chung, V. Johnson, and E. D. Mynatt. I
am what i eat: identity & critical thinking in an
online health forum for kids. In Proceedings of
CHI ’13.
[10] 杉本恵子. 「生活習慣病は、『食材 5 色バランス
健康法』で予防・改善を」. In Kellogg’s Update,
第 82 巻, 2005.
[11] 鈴木秀子. 子どもから家庭へつなぐ食育〜保護者の「学び」からの検討〜. 会津大学短期大学部研究年報, 第 67 巻, 2010.

WISS2013

鍵盤上への演奏補助情報投影機能をもつ
ピアノ学習支援システムにおける熟達化プロセスに関する調査
竹川 佳成

椿本 弥生

平田 圭二 ∗

田柳 恵美子概要. 楽器の演奏技術の向上には多大な時間や労力を必要とするため，敷居の高さに利用を断念したり，習熟効率の低さから挫折してしまう演奏者が多い．この問題を解決するために，筆者らの研究グループは，鍵盤上部に設置したプロジェクタを用いて鍵盤上や鍵盤の周囲に打鍵位置情報など演奏補助情報を投影す
るピアノ学習支援システムを構築してきた．評価実験から比較手法である「光る鍵盤」の学習方法と比較して課題曲を効率的に学習できることが明らかになったが，「課題曲を効率的に学習できただけか，あるいは，ピアノ演奏そのものの演奏技術が向上したのか」「必要とする提示情報は熟達度に応じて変化するのか」といった提案する学習支援システムを使用した場合における熟達化プロセスは十分調査できていなかった．そこで本研究では，この問題を解決するために，ピアノ学習支援システムの熟達化プロセスの詳細な調査を目的とする．評価実験では，提案する学習支援システムを使いながら 5 日間かけて 6 人の被験者に 1 日 30
分間課題曲を練習してもらい，実験日ごとの熟達度を調査するためにシステムの補助がない状態で課題曲を演奏してもらった．練習中に記録した打鍵データや視線データなどをもとに熟達化プロセスを検証した．

1

はじめに

ピアノ演奏では，譜読み，指示されている鍵への正確な打鍵，適切な運指（指使い），リズム感覚，打鍵の強弱，テンポなど，さまざまな技術が求められ，それらの修得には長期間の基礎的な練習を必要とす
る．ピアノ演奏には多大な時間と労力を必要とするため，敷居の高さに利用を断念したり，習熟効率の低さから挫折してしまう演奏者が後を絶たない．特に初心者にとって，譜面上の音符および運指を見て，音符から鍵盤上の打鍵位置をイメージし，指示された運指で弾くという一連のプロセスは最初に立ちはだかる難関で，このプロセスに対する労力や精神的負荷の軽減が楽器演奏を楽しめ長続きさせる秘訣であるといえる．演奏初期段階（ピアノ初心者が初見の楽曲に対して運指や打鍵位置を覚えるために練習している段階）における敷居を下げるために，筆者らの研究グループは，鍵盤上部に設置したプロジェ
クタを用いて鍵盤上や鍵盤の周囲に打鍵位置情報など演奏補助情報を投影するピアノ学習支援システムを構築してきた [1]．評価実験から比較手法である「光る鍵盤の学習方法 [2, 3]」と比較して効果的に学習できることが明らかになった．しかし，「課題曲を効率的に学習できただけか，あるいは，ピアノ演奏
そのものの演奏技術が向上したのか」「必要とする
提示情報は熟達度に応じて変化するのか」といった提案する学習支援システムを使用した場合における熟達化プロセスは十分調査できていなかった．
そこで本研究では，この問題を解決するために，
ピアノ学習支援システムの熟達化プロセスの詳細な調査を目的とする．
評価実験では，提案システムを使いながら 5 日間
かけて 6 人の被験者に 1 日 30 分間課題曲を練習してもらい，実験日ごとの熟達度を調査するためにシステムを利用しない状況で練習後に課題曲を演奏してもらった．また，5 日間かけて練習してもらう課∗

Copyright is held by the author(s).
公立はこだて未来大学- 55 -

題曲とは異なる曲を実験初日と 5 日目に演奏してもらい，提案システムを使って練習したときのピアノ
演奏技術の熟達度を調査した．さらに，打鍵タイミ
ングや打鍵位置といった演奏データだけでなく，視線追跡装置を用いて鍵盤上や鍵盤の周囲のどこを見ていたか計測した視線データにより，熟達化プロセスにおける重要情報の変遷を分析する．
以下，2 章で関連研究について説明し， 3 章で実験計画について述べる．4 章で評価実験について述
べ，最後に 5 章で本研究のまとめを行う．

2

関連研究

これまでピアノ学習の支援につながる試みはいくつか行われている．蓄積した演奏データから演奏者の苦手な奏法を割り出し集中的にトレーニングするシステム [4] や，演奏を自動的に評価しアドバイス
文や誤りを譜面上に提示 [5] するシステムがある．これらは，打鍵ミス，打鍵の強さなどを主に打鍵情報から評価している．Piano Tutor[6] は演奏追従認識
による自動譜めくり機能や，ビデオや音声による模範演奏の提示や，演奏者の演奏データを解析し改善点をテキストなどで指示する機能などをもつ．先生と生徒のレッスン支援 [7] として，音量の変化やテン
ポ，スタッカートやレガートといったアーティキュ
レーションの具合等を示すシステムが提案されている．打鍵すべき鍵，運指，手本映像を表示するキー
ボードやソフトウェア [1, 2, 3] がある．これらはいずれも打鍵情報から演奏を評価し学習目的に必要な情報を提示している．本研究では，視線データと打鍵データを用いて演奏を評価している点で異なる．
学習者の視線の動きを観測する研究 [8] はいくつか行われている．特に，川崎ら [9] はピアノ学習者の視線の動きを観測し，プロフェッショナルのピアニストと初心者との視線の動きの違いを解析している．
本研究は初心者を対象としており，対象者という観点では川崎らの研究と類似する部分があるが，本研究のように鍵盤上にアノテーションが投影されるピ

WISS 2013

アノではなく，川崎らは一般的なアコースティック
ピアノを利用しているため，実験環境は大きく異なる．また，川崎らは楽譜上の視線追跡だけであったが，本研究では楽譜および鍵盤の視線を追跡しているという点でも異なる．

23<=>?@$AB-CD67$%&EF,GH'()*+,-./01&

2345
2345
67$%&

実験計画

3

'(67
$%&EF,GH!"#"$%&

筆者らの研究グループが提案するピアノ学習支援
システムは，ピアノ初心者を対象としており，五線譜やシステムが生成する補助情報を活用しながら学習者はある楽曲を一から練習し，できるだけ速く習熟し，最終的にシステムの補助なしで演奏できるよ
うになることをめざしている．このために，鍵盤上に次に演奏する打鍵位置や運指番号，譜読みを補助するために鍵盤の上部に提示した五線譜の音符とそれに対応する鍵を結ぶ線など多彩な情報を提示している [1]．1 章で述べたように，本研究では提案する
ピアノ学習支援システムを使用して学習したときにおける熟達化プロセスを調査するために詳細な評価実験を行う．

67$%&'(,6789:;!"#"'(

図 1. システム構成ことを提案システムの目的とし，この目的に特に有効な情報であった「鍵盤上への打鍵位置および運指
番号」
・
「楽譜」
・
「楽譜上に提示する現在の演奏位置」
のみ演奏補助情報として提示する．
実験システム
実験で使用した学習支援システムのシステム構成を図 1 に示す．鍵盤上部に設置したプロジェクタを用いて鍵盤上に演奏補助情報を提示する．また，演奏者の前方に視線追跡機能付ディスプレイを配置し，プロジェクタと同様に演奏補助情報を提示している．
システムは，MIDI データ（打鍵位置や打鍵強度）を入力とする．さらに，鍵盤部の視線を追跡するために鍵盤上部に視線追跡装置を設置し，演奏の様子を記録するためにビデオカメラを設置した．
映像生成およびディスプレイ視線データ記録用の PC として SONY 社の VGN-SR94VS を使用し，鍵盤部視線データ記録用の PC として SONY 社のVPCSA を使用した．また，MIDI 鍵盤として CASIO 社の PriviA PX-110 を使用した．鍵盤部の視線追跡装置として Tobii 社の X1 ライトを使用し，ディ
スプレイ部の視線追跡装置として Tobii 社の T60 を使用した．プロジェクタとして BenQ 社の MP776
ST を使用した．プロジェクタの鍵盤投影領域は 6オクターブ（72 鍵）で，プロジェクタの映像がよ
く見えるように黒鍵を白く塗った．PC 上のソフト
ウェアの開発は，Windows 7 上で Microsoft 社のVisual C++ 2010 を用いて行った．

3.2

実験方針
実験方針として以下があげられる．

3.1

ピアノ演奏技能の獲得 提案するピアノ学習支援
システムは，30 分間の評価実験から比較手法である「光る鍵盤の学習方法」と比較して打鍵ミス数が減り，提案するピアノ学習支援システムを使用しながら練習すれば効率的に課題曲を弾けるようになる．
しかし，「新規の楽曲を提案システムの補助なしで演奏できるようになる」といったピアノ演奏の汎用的な技能を修得できたかは検証されていない．
そこで，本研究では提案する学習支援システムを使って練習する前と，提案システムを使った後で，新規の楽曲をそれぞれ演奏してもらう．その演奏精度を計測することで，提案システムが学習者のピアノ演奏技能の向上に貢献するか調査する．
提示情報の重要度の変遷 提案する学習支援シス
テムは演奏を補助するさまざまな情報を提示しているが，例えば，「未熟な段階では打鍵位置が明確にわからないため手元の打鍵位置情報を頼りに演奏するが，熟達するにつれて打鍵位置情報に頼らず楽譜を見る」など熟達度によって情報の重要度は変わってくると思われる．
そこで，より効率的な学習支援システムの提案をめざして，熟達するにつれ必要とされる提示情報の変遷を明らかにする．具体的には，提案システムを使いながら 5 日間かけて 6 人の被験者に 1 日 30 分
間課題曲を練習してもらい，実験日ごとの熟達度を調査するためにシステムを利用しないで課題曲を演奏してもらう到達度テストをうけてもらう．また，
打鍵タイミングや打鍵位置といった演奏データだけでなく，視線追跡装置を用いて鍵盤上や鍵盤の周囲のどこを見ていたか視線データを計測する．これらのデータおよび実験中の観測から，熟達化プロセス
における重要情報の変遷を定量的・定性的に分析する．なお，実験結果を明確にするために，打鍵位置をシステムの補助なしでできるだけ速く習熟できる- 56 -

提示コンテンツ
図 2 を用いてシステムが提供したコンテンツについて説明する．図中の番号は，以下の箇条書き番号に対応している．

3.3

1. 既存の紙媒体の楽譜と同様の楽譜を提示する．
2. 現在の演奏位置を提示する．これにより，学習者は現在どこを演奏しているか直観的に理解できる．正しい鍵を弾いたときのみ演奏位
置は進むようになる．

3. 次に演奏する鍵上に色付枠を提示する．運指
情報は，運指番号（親指から小指にかけて 1から 5 の番号がそれぞれ割り当てられている）
ごとに対応している輪郭の色や，鍵上に運指番号を提示することで示す．これにより学習

鍵盤上への演奏補助情報投影機能をもつピアノ学習支援システムにおける熟達化プロセスに関する調査

!"#

H/0*+
IJKLG0$%&'()*+=>?@ABCD
EFG0:;<,-./01203456789,-./0120
6789

HMN()
OPG0

=>?@ABCD
図 2. 提示コンテンツ

被験者 実験に参加した被験者は 6 名で，五線譜がほとんど読めない鍵盤経験歴のない 20 代から 40 代の成人である．なお，各被験者にはあらかじめ楽譜
上に書かれている音符の意味や，各種機能の使い方を説明した．

者は容易に打鍵位置や運指を把握できる．また，ディスプレイにも鍵盤と同様の打鍵位置
情報や運指情報を提示する．ディスプレイには鍵の枠しか提示されないため，鍵盤上に提示された情報と比較して得られる情報は少な
く，直観性に欠ける．

4. 楽譜上に表示されている番号付きの黒塗りの四角形は，現在位置を変更するキューポイン
トである．これは，学習者が集中的に練習したい場合や，途中から演奏したい場合に有効である．キューポイントを切り替えるアイコンを，演奏で使用しない鍵の鍵盤上に投影し，その鍵を打鍵することでユーザが選択的に利用できるようにする．これをキューポイント
設定機能と呼ぶ．

手）を演奏してもらった．また，ピアノ演奏技術の熟達度を評価するために，J. S. Bach のメヌエット（BWV Anh. 114）の最初から 8 小節までを両手で演奏してもらった．

5. 提案システムは打鍵位置および運指情報を提示するかどうかを切り替える機能（打鍵位置
提示切替機能）をもち，この機能を操作する
アイコンを演奏で使用しない鍵の鍵盤上に投影する．打鍵位置提示切替は，割り当てられた鍵を押すごとにトグル式で切り替わる．また，提案システムは模範演奏を再生する機能（模範演奏再生機能）をもち，同様に演奏で使用しない鍵の鍵盤上に模範演奏再生機能に対応するアイコンを投影する．学習者が模範演
奏再生機能に割り当てられた鍵を押下すると模範演奏の再生が始まり，再生中にその鍵を再度押下すると模範演奏を途中で止められる．
なお，本論文では，キューポイント設定機能・
打鍵位置提示切替機能・模範演奏再生機能をまとめて付加機能と呼ぶ．

評価実験

4

課題曲 熟達化プロセスを評価するために，W. A.
Mozart のトルコ行進曲（最初から 17 小節目まで両実験方法 実験では，「トルコ行進曲を 30 分かけて練習し，到達度テストとして通し演奏（最初から最後まで一通り演奏すること）を行う」という試行を 1
日 1 回行った．これを連続 5 日間かけて繰り返した．
ピアノ演奏技能の上達を検証するために，「初日のトルコ行進曲練習前」および「5 日目のトルコ行進
曲到達度テスト後」にメヌエットの到達度テストを行った．練習中および到達度テスト中は，視線計測装置が生成する視線データ，MIDI 鍵盤が生成する打鍵データをシステムに記録し，演奏中の様子をビ
デオカメラで記録した．なお，メヌエットの到達度
テストは初日と 5 日目の両方に行ったが，被験者は初日に行ったメヌエットの演奏を覚えておらず，5 日目のメヌエットの到達度テストは，初日のメヌエッ
トの到達度テストに影響はない．
到達度テストでは，テスト中で計測している打鍵データをもとに打鍵ミス数を計測した．通し演奏時
は，両手法において前面にある楽譜のみ（現在の演奏位置も提示しない）提示した．また，誤打鍵（間違えて打鍵した場合），未打鍵（打鍵しない場合），余打鍵（余分に打鍵した場合）を打鍵ミスとみなした．
被験者への指示 30 分間の練習では「自然なテンポで譜面をみながらミスなく弾けることを意識して，機能を自由に使ってもらって 30 分間練習してください．また，この後，到達度テストを行います．到達度
テストは打鍵位置の情報などシステムからの補助情報がない状態で最初から最後まで弾いてもらいます．
実験中に質問があれば何でも聞いてください」と指示した．また，到達度テストでは「今から到達度テストを行います．最初から最後まで模範演奏にでき評価実験では，演奏初期段階（ピアノ初心者が初見の楽曲に対して運指や打鍵位置を覚えるために練習している段階）における提案システムを用いた際のピアノ演奏に関する熟達化プロセスを，打鍵デー
タや視線データをもとに分析する．
実験の手順
実験の手順を以下に示す．

4.1- 57 -WISS 2013

図 3. トルコ行進曲の到達度テスト - 打鍵ミス数および演奏時間

るだけ近いテンポでミスなく弾いてください．制限
時間は 5 分間です．わからないところがあれば飛ばしてもらってもかまいませんし，これ以上演奏できなければ言ってください．たとえ間違っても弾き直しをしないようにしてください」と指示した．なお，
難しすぎて練習を放棄した被験者はいなかった．
ピアノ演奏技能の獲得 - 実験結果と考察
トルコ行進曲の到達度テストにおける打鍵ミス数
および演奏時間（課題曲を「最初から最後まで」あるいは「最初からリタイア」するまでにかかった時間）を図 3 に，メヌエットの到達度テストにおける打鍵ミス数および演奏時間を図 4 に示す．
全体的に，トルコ行進曲の到達度テストにおける打鍵ミス数は実験が進むにつれて減少し，途中リタ
イアした場合を除き演奏時間も減っている．また，
メヌエットにおいては，打鍵ミス数が減少し演奏時間が短くなった被験者がいた一方，上達が見られなかった被験者もいた．この原因として被験者ごとの学習方略の違いが考えられる．
提案する学習支援システムは，打鍵位置情報を視覚的に提示することで，打鍵位置をできるだけ速く学習できることをめざしている．また，打鍵位置提示切替機能，模範演奏再生機能，キューポイント指定機能といった付加機能を使うことで学習の促進をねらっている．打鍵位置情報はデフォルトで提示されるが，これらの付加機能は選択的に利用される．
したがって，提案する学習支援システムは「提示された打鍵位置情報を活用し打鍵位置を学習し，学習効率を高めるために能動的に付加機能を活用する」という学習方略を理想としている．
被験者の学習方略は，「学習支援システムが提供する打鍵位置情報を利用し打鍵位置を学習するものの，付加機能をほとんど使わない学習方略（打鍵位置情報依存型）」「学習支援システムが提供する打鍵位置情報を利用し打鍵位置を学習すると同時に，付加機能を積極的に利用し熟達度に応じて学習方法を柔軟に構築する学習方略（システム方略適合型）」「学習
支援システムが提供する打鍵位置情報に頼らず，自身の過去の成功体験をもとに練習する学習方略（システム方略不適合型）」の 3 つの大きく分類できる．

4.2- 58 -

以降，各学習方略について考察する．
打鍵位置情報依存型 打鍵位置情報依存型の被験者

A は，他の被験者と比較して最も熟達度が低かった
被験者である．被験者 A の付加機能を使用回数は，他の方略の被験者と比べて少なく，打鍵位置情報を利用しながら練習していた．実験 3 日目以降に打鍵
位置提示切替機能を使用する様子が観測されるが，30 分間の訓練中 2 分〜3 分と短期間に，あるフレーズに対して打鍵位置情報を見ずに弾けるか確認をしただけである．被験者 A は実験が進むにつれてトル
コ行進曲の到達度テストの打鍵ミス数は少なくなっている一方，5 日目のメヌエットの打鍵ミス数は初日と比べて増えている．被験者 A は「PC 用キーボー
ドのタッチタイピングを修得するときに，タッチタ
イピング練習ソフトウェアで繰り返し練習をして習熟していった過去の成功体験があり，タッチタイピ
ングの練習と類似している実験の学習方法は，学習しやすかった」とコメントしている．また，「タッチ
タイピングでは，ミスなくタイピングできた単語もできなかった単語も区別なく均等に練習したため，今回の実験においても，間違えやすいところを集中的に訓練するといったことはやらなかった」とコメントしている．したがって，被験者 A は学習支援シ
ステムの学習方法に肯定的でストレスなく学習できていたが，学習支援システムを十分使い切れていたとはいえない．
一方，被験者 B は被験者 A より付加機能を使っておらず，システムが提示する打鍵位置を常に使いながら練習していた．被験者 B も，繰り返し練習に
より新たな技能を習得した過去の成功体験があり，
このような学習方略にいたった．被験者 B は被験者
A より受動的な学習方略であったにも関わらず，被験者 A と異なり実験が進むにつれて着実に熟達している．被験者 A の熟達が伸び悩んだ要因の調査は今後の課題である．
システム方略適合型 被験者 C や被験者 D は打鍵
位置情報をもとに打鍵位置を学習すると同時に，付加機能を使って難しい箇所を集中的に練習したり，
打鍵位置情報を使わずに修得できているか確認しな

鍵盤上への演奏補助情報投影機能をもつピアノ学習支援システムにおける熟達化プロセスに関する調査
#!!"
+!"
*!"
#$%&'
)!"

#$%()

(!"

#$%*'

'!"

+,-./0%&'&!"+,-./0%()%!"+,-./0%*'$!"+,-./0%12

#!"
!"
$!"

図 4. メヌエットの到達度テスト - 打鍵ミス数および演
奏時間

%!"

&!"

'!"

図 5. トルコ行進曲の練習中 - 実験日ごとの視線分布

がら練習していた．特に被験者 C は，打鍵位置提示切替機能やキューポイント選択機能を何度も使用
し，集中的に部分練習していた．実験が進むにつれて着実に到達度テストの打鍵ミス数が少なくなり，
途中リタイアを除き課題曲を弾き通すためにかかった時間も短くなり演奏テンポが速くなっていった．
メヌエットにおいても実験初日と実験 5 日目では打鍵ミス数は減少し，演奏テンポは速くなった．これにより，提案する学習支援システムは課題曲を効果的に学習できるだけでなく，ピアノ演奏技術の向上にも貢献できたことがわかる．メヌエットの到達度
テストにおいて，システム方略適合型被験者における打鍵ミス数増加率（「実験 5 日目の打鍵ミス数」
を「初日の打鍵ミス数」で割った値）が最も小さく，「システム方略適合型被験者における打鍵ミス数増
加率」および「システム方略不適合型被験者における打鍵ミス数増加率」間で有意水準 5%で有意差 (p値=0.047) が観測された．その他の組み合わせにおいて有意差は観測されなかった．
システム方略不適合型 システム方略不適合型の被験者 E や被験者 F の特徴として，実験が進むにつれてトルコ行進曲の到達度テストの打鍵ミス数は減少する一方，メヌエットの到達度テストにおける打鍵ミス数は，実験初日と実験 5 日目と比べて変化は小さい．
被験者 E は，提示された打鍵位置情報にはできるだけ頼らず，模範演奏を聴きこんだり，楽譜をじっ
くり見ながら打鍵位置を模索していた．被験者 C は，途中まで模範演奏を聴いて練習するという訓練を何度もやっていたため模範演奏再生回数は増えたが，被験者 E は模範演奏を最初から最後までじっくり聴いていた．被験者 E は声楽を学んでいた経験があり，「声楽の新曲に取り組むときその曲を繰り返し聴いて覚える」という成功体験をもつ．今回の実験においても，自身の成功体験を適用し聴覚中心の学習方
略で取り組んでおり，提案する学習支援システムの学習方略に適さなかった．
被験者 F も被験者 E と同様に，できるだけ打鍵位
置情報を使用しないで訓練していた．被験者 F は，
「トルコ行進曲の到達度テストでどうすれば打鍵ミ
スなく弾けるようになるか」を中心に考えるゴール
指向型の学習方略で取り組んでおり，到達度テスト- 59 -!",.(%*(!"#$%&'(!"#$%&'()"*'(%&+,.(%*()"*'(%&+

図 6. ディスプレイ部と鍵盤部における視線領域

では打鍵位置情報が提示されないことから，打鍵位置情報を見ずに演奏できるように練習していた．このため，到達度テストにおけるトルコ行進曲の打鍵
ミス数は減少しており，被験者 A〜被験者 F の中で最初に打鍵ミス数が 0 になったが，楽譜を中心に打鍵位置を考えながら弾いていたため演奏テンポは他の被験者と比べると遅い．また，トルコ行進曲用に組み立てられた学習方略はトルコ行進曲の到達度
テストにおいて効果的であったが，5 日間の練習後に演奏したメヌエットの到達度テストでは，5 日間の練習で得られたスキルを活かせず，練習前に演奏したメヌエットの到達度テストと変わらない結果となった．これにより，ピアノ演奏においては楽譜や鍵盤をよく理解する認知的側面の熟達も重要であるが，楽譜上の音符から打鍵位置を正しく演奏できるようになるといった身体行動の熟達も重要であるといえる．これらがバランス良く熟達することでピアノ演奏技術そのものも向上すると思われる．
提示情報の重要度の変遷 - 実験結果と考察「熟達度」と「提示情報の重要度の変遷」を分析するために，30 分間のトルコ行進曲の練習における

4.3

WISS 2013

視線の分布を調査した．上述したように学習方略の違いが見られたため被験者ごとに視線分布を分析することが望ましいが，紙面の制約のため，被験者 Bに着目して詳細に検討する．被験者 B を選定した理由は，実験日ごとの練習においてシステムが提供する付加機能を使用せず，提示される打鍵位置をもとに打鍵位置を覚える訓練淡々と繰り返しており，どの打鍵に対してどういう視線であるか特定しやすいためである．
図 5 に実験日ごとの視線分布を示す．実験で得られた視線データを図 6 に示す視線領域にマッピングすることで図 5 の視線分布を求めた．ディスプレイ
には打鍵位置だけを示す仮想的な鍵盤が提示されており，ディスプレイ上の仮想鍵盤と実際の鍵盤を演奏する手を基準に右手・左手・中央に領域をわけた．
トルコ行進曲は右手で弾く領域と左手で弾く領域が明確にわかれており，右手と左手の境界線は E6（Eは音名をおよび 6 はオクターブ数を意味する）である．視線認識精度の問題から，右手と左手の境界付
近は明確に右手左手どちらの領域を見ているか特定できないため，中央という領域を設けた．また，実験日が 2 日目から始まっている理由はシステムの不具合により初日の鍵盤部の視線がとれていなかったためである．
図 5 に示すように，熟達度が低い 2 日目ではディスプレイ部楽譜を見る頻度は少なく，鍵盤あるいは
ディスプレイ部右手を中心に見ている．4 日目になると楽譜を見る頻度はあがり，ディスプレイ部右手や鍵盤部右手を見る頻度は少なくなった．これにより熟達するにつれて，鍵盤に提示された打鍵位置情
報や，ディスプレイ上に提示された打鍵位置情報は不要となり，楽譜情報が重要となっていることがわ
かる．また，右手の打鍵位置に関してはディスプレ
イ部右手を見ており，左手の打鍵位置に関しては鍵
盤上の打鍵位置を直接見ている．被験者 B は「余裕があれば演奏中に楽譜を見つつ練習したいと思っており，できるだけ視線移動を少なくするために，右手の演奏はディスプレイを見ていた」とコメントしている．また，被験者 B は「右手は利き手であり，左手と比べて鍵間の距離が鍵盤を直接見ないでも予測できた」と述べており，右手は左手と比べて鍵盤のブラインドタッチ能力が高く，このような視線の動きになったと考えられる．5 日目は，4 日目とくらべて被験者の調子が悪かったと思われる．このため，5 日目の視線は，ミスを避けるために楽譜を見る頻度が低くなった．しかし，5 日目におけるトルコ行進曲の到達度テストは 4 日目の同楽曲の到達度
テストより成績が良くなっている．5 日目の 30 分間の練習においても着実に熟達度が向上したことがわ
かる．

5

まとめ

本研究では，学習者の視線に注目し，ピアノ学習
支援システムの熟達化プロセスの詳細な調査を行った．成人した 8 名の鍵盤楽器初心者に，学習支援シ
ステムを使いながら 1 日 30 分間トルコ行進曲を 5日間かけて練習してもらい，実験日ごとにシステムの補助を使わずに到達度テストを行ってもらった．
実験結果より，成人学習者は過去の成功体験から学習方略をもっており [10]，いずれの被験者も自身- 60 -の学習方略を基準にシステムを利用していた．自身の学習方略とシステムの学習方略が適合した被験者は，効率的に習熟でき，ピアノ演奏そのものの演奏技術の獲得までいたった．学習方略が部分的に適合した被験者は学習効果にばらつきが生じ，システムの学習方略に適合しなかった被験者はピアノ演奏技術の獲得まではいたらなかった．
さらに，1 名の被験者に対して解析した実験日ごとの視線データの結果から熟達するにつれて被験者が必要とする情報は打鍵位置情報から楽譜情報に遷移していることが明らかになった．
今後は，音符に着目した提示情報の重要度の変遷の調査，他の被験者を対象とした実験データの解析，
視線データを考慮した熟達度の算出，熟達度に応じて補助情報を適応的に提示する学習支援システムの構築などがあげられる．

参考文献[1] 竹川佳成, 寺田 努, 塚本昌彦：運指認識技術を活用したピアノ演奏学習支援システムの構築, 情報処
理学会論文誌, Vol. 52, No. 2, pp. 917–927 (2011年).
[2] CASIO：光ナビゲーションキーボード：
http://casio.jp/emi/key lighting/.
[3] ヤマハ株式会社: 光る鍵盤 EZ-J210：
http://www.yamaha.co.jp/product/
piano-keyboard/ez-j210/index.html.
[4] 大島千佳, 井ノ上直己：不得手要素を克服させるピ
アノ学習支援システムにむけて, 情報処理学会研究報告 (音楽情報科学研究会 2007-MUS-71), Vol.
2007, No. 81, pp. 185–190 (2007 年).
[5] 森田慎也, 江村伯夫, 三浦雅展, 秋永晴子, 柳田益造：演奏特徴の強調およびアドバイス文呈示によるピアノ基礎演奏の独習支援, 日本音響学会平成20 年度秋季研究発表会, pp. 933–934 (2008 年).
[6] R. B. Dannenberg, M. Sanchez, A. Joseph, P.
Capell, R. Joseph, and R. Saul: A ComputerBased Multi-Media Tutor for Beginning Piano
Students, Journal of New Music Research, 19(2-3), pp. 155–173, 1990.
[7] S. Smoliar, J. Waterworth, and P. Kellock:pianoFORTE: A System for Piano Education
Beyond Notation Literacy, Proceedings of theThird ACM International Conference on Multimedia, pp. 457–465 (1995).
[8] Wikipedia, Eye movement in music reading,
http://en.wikipedia.org/wiki/Eye movementin music reading[9] 川崎智子：ピアノ演奏時における読譜の為の眼球運動, 三重大学教育学部研究紀要教育科学, 第 33
巻, pp.49-66 (1982 年).
[10] W. W. Lee, D. L. Owens, 清水康敬：インストラ
クショナルデザイン入門–マルチメディアにおける教育設計, 東京電機大学出版局, p.38.

WISS2013

LumoSpheres: 複数浮遊物体の実時間追跡にもとづく映像投影
山口 裕明

小池 英樹∗

概要. 空中を浮遊する大量の粒子を実時間追跡し, 映像を投影することで, 体積型の立体ディスプレイを実現する構想を提案し, その基礎段階として, 運動している少数の球に実時間追跡にもとづいた映像の投影を行った. 構築したシステムの基本的な流れは, モーションキャプチャを用いて球の三次元位置を計測し, プロ
ジェクタを用いて球に映像を投影するという処理であるが, これらを処理している間も球は空中を移動しているため, その時間分だけ正しい位置に映像が投影されない. この問題に対して, 統計的に位置を推定するカ
ルマンフィルタと運動モデルを適用し, 軌道予測を行うことで安定した映像の投影を実現した. 現段階の応用例として, トスジャグリングの球に映像を投影する DigitalJuggling を実装した. そして, パーティクル型
立体ディスプレイのプロトタイプを実装し, 実現するために必要となる要素を議論した.

1

はじめに

プロジェクションマッピングは, 現実の物体の形状に沿ってプロジェクタから映像を投影する技法で,
近年イベントやメディアアートとして盛んに用いられている. 投影対象は机上, 壁, 床, 建築物, 造形物な
どの様々な形状であるため, その形状に合わせた映像の制作や位置合わせが重要である. そのため, プ
ロジェクションマッピングの投影対象は, 静止している物体や回転などの周期運動をする物体が使用されることが多く, 自由な運動や高速な運動をする物
体には一般的に用いられてこなかった.
一方, ビジョンセンサの性能やコンピュータを用いた物体認識の技術は年々進歩している. 物体を追跡するモーションキャプチャシステムは, カメラ数十台を同時に使用することができ, 数百 fps というフレームレートを用いて, 物体の三次元座標を実時間で計測することが可能である.
このようなプロジェクションマッピングの技術と物体認識の技術を合わせて, 運動している物体に対して映像を投影しようというのが本研究の目標である. 静止している物体へプロジェクションマッピン
グを適用すると, 投影範囲は物体の表面に限定されるが, 運動している物体へ適用すると (物体の表面であることは同様であるが), 物体を動かす範囲だけ
投影範囲を空間的に広げることができる. つまり,映像の表現範囲を平面から空間へ拡張することができる.
このような平面から空間へ映像を拡張するという考えから, 図 1 のようなパーティクル型立体ディスプ
レイを提案する. パーティクル型立体ディスプレイ
は, 大量の粒子を空中に飛散させ, それらをビジョン∗

図 1. パーティクル型立体ディスプレイの概念図. 立体
像に直接的なインタラクションができる裸眼立体
ディスプレイである.

センサで計測し, それぞれの粒子にプロジェクタから任意の色を投影することを繰り返し行うことで実現する体積型の裸眼立体ディスプレイである. 立体像が結像される領域を囲うように複数台のプロジェクタを設置すれば, 360 °どの方向からでも立体像を見ることができる. また, 粒子が質量の小さい物質
であれば, 立体像が結像される空間に直接的なイン
タラクションが可能である.
パーティクル型立体ディスプレイは, 空中に飛散している球の位置の計測と, その物体へ映像を投影するというのが基本的な処理となっている. しかし, それらの処理中も球は空中を移動しているため, 計測
した球の位置にそのまま映像を投影すると, 装置の処理時間やデータの転送時間だけ投影位置がずれる.
本研究ではパーティクル型立体ディスプレイの基礎段階として, そのディスプレイの最小要素 (平面ディスプレイであれば pixel に該当) である一つの球を用いて, 遅延対策の考案と実装, その評価を行った. 具体的には, 放物線運動を用いた軌道予測を行うが, 単純に運動モデルを用いて軌道予測をすると映像が乱れてしまう現象が発生するため, 統計的に

Copyright is held by the author(s).
Hiroaki Yamaguchi and Hideki Koike, 電気通信大学大学院 情報システム学研究科 情報メディアシステム学専攻- 61 -WISS 2013

位置を推定するカルマンフィルタと運動モデルを合わせた軌道予測を行い, 安定した映像の投影を実現
した.
現段階の応用として, トスジャグリングの球に映像を投影する DigitalJuggling をアプリケーションとして示す. そして, パーティクル型立体ディスプ
レイのプロトタイプを実装し, 実現するために必要な要素について探求する.

2

関連研究

図 2. LumoSpheres: 運動している複数の球に映像を投影するシステム.

Kimura らの “Laser produced 3D display in theair” はレーザの特性を利用した発光を空間中に行うことで, 体積的なディスプレイをつくっている [1].
Butler らの “Vermeer” は特殊なスクリーンを回転させることで体積的な投影対象の空間をつくり, そこへプロジェクタから映像を投影をしている [2]. こ
れらのディスプレイは裸眼で 360 °どの方向からも立体像を見ることができるが, レーザや回転機構に
より立体像が表れる空間が危険であるため, 立体像に対する直接的なインタラクションは工夫が必要である.
FogScreen は空中に霧の層を発生させ, プロジェ
クタからその層に映像を投影することで映像を結像させている [3]. Nakamura らの “bubble cosmos”
は煙を充満させたシャボン玉に映像を投影する [4].
Matoba らの “SplashDisplay” は空中に拭きあげた
発泡ビーズに映像を投影する立体的な表現のできる
ディスプレイである [5]. Barnum らの “A multilayered display with water drops” は水滴の落下とプロジェクタからの映像を同期させるディスプレイである [6]. 霧ではなく水滴を用いることで, 時分
割に水滴を落とす制御が可能となり, 4 層の体積的なディスプレイとなっている. 本研究では, 制御や計測のできる対象として球を用い, 投げ上げや自由落
下をしている球に対して映像を投影することで, 層ではなく体積的な映像表現を目指す.
プロジェクションマッピング [7] は机上, 壁, 床, 造形物など, 物体の形状に合わせてプロジェクタから映像を投影する技術であり, 1970 年頃からテーマ
パークで実用化され, 近年盛んにイベントやメディ
アアートとして用いられる. Parker の “lumarica”
は複数のひもに映像を投影する立体ディスプレイである [8]. Okumura らの “Lumipen” は高速視線制
御ユニットと高速ビジョンセンサを用いて, 運動している球に即時的な映像の投影を実現している [9].
高速な光軸制御により, 球に張り付いたような投影ができるが, 投影対象は高速視線制御ユニットに対して単数の球であり, 奥行き情報を得る場合も工夫が必要である. 本研究では, 複数の球に対して奥行
き情報を考慮した映像を投影することで, 体積的な映像の投影範囲を確保する.

図 3. システム構成 (俯瞰図).6 台のカメラで球を撮影し, PC で処理をした後, プロジェクタから球に映像を投影する.

3

LumoSpheres

運動している複数の球に映像を投影するシステム
を「LumoSpheres」と呼ぶ. 図 2 は三個の球に対して動作させている様子である. このシステムは現実
空間で運動している球に, 任意の映像を投影することができる. 平面的なプロジェクションマッピングの
空間的な拡張, スポーツの映像的な拡張, ビデオゲー
ムなどのエンタテイメントなどに応用が可能である.
図では, 1.5m3 の空間の中で三個の球にシステムを動作させているが, カメラからみた球の重なり (オクルージョン) が生じない限り三個以上も可能であり, 動作範囲は数十 m3 まで拡張可能である.

3.1 システム構成
LumoSpheres のシステム構成を図 3 に示す. 映
像の投影対象となる球, その球を動かす空間を囲むように配置した 6 台のカメラ (NaturalPoint OptiTrack S250e), 球の位置計測, 追跡を行うソフト
ウェア (NaturalPoint TrackingTools Ver.2.5), 予
測などの処理をする PC(Lenovo ThinkPad T530,
Intel Core(TM) i7 2.9 GHz, 8 GB RAM, Windows7 Service Pack 1), 映像を投影をするプロジェ
クタ (BenQ W1070, 60Hz, 1280 × 720pixel) で構成される. カメラ, PC, ソフトウェア, 予測プログラ- 62 -

LumoSpheres: 複数浮遊物体の実時間追跡にもとづく映像投影

図 4. 再帰反射シートを貼り付けた球 (左) とその反射
性能 (右). カメラから照射された赤外線光が再帰反射の性質により球から強く反射される.
図 5. キャリブレーションによる位置合わせ.(左) と (右)は位置が 1m ほど離れているが, 球の形状に沿った映像が投影される.

ムの間のデータ転送は UDP 通信で行われる.
モーションキャプチャの一般的な用途である, フルボディモーションキャプチャとして用いる場合は,
直径 1cm 程度の再帰反射性マーカを身体全体に装着するが, 本研究では, 任意の大きさの球に再帰反射シートを貼ることで, マーカの代わりとしている.
本システムに用いる再帰反射シートを貼り付けた直径 10cm の球と, その反射性能を図 4 に示す. シー
トは舟形多円錐図 (地球儀の展開図) に切り, 球に貼り付けている. 一つの球は 180g の重さがあるため,空中を運動する際の空気抵抗は無視できる.

3.2

プロジェクタとカメラのキャリブレーション

図 6. システムの流れで発生する遅延. 球をカメラで撮影してから, プロジェクタから投影するまでに遅延が発生するため, 軌道予測をする.

現実空間の球に合わせて適切に映像を投影するためには, モーションキャプチャから取得できる三次元座標とプロジェクタから投影する二次元映像の位置合わせが必要である.
プロジェクタはピンホールカメラと同様のモデルとして考える事ができるため, モーションキャプチャから取得できる三次元座標を (X, Y, Z), プロジェク
タから投影する二次元映像の座標を (u, v) とすると,
3 × 4 の投影変換行列を用いて式 (1) のように表すことができる (式は同次座標系で表している)[10].






 
 X
u
p11 p12 p13 p14  
 v  ∼  p21 p22 p23 p24   Y 
Z
1
p31 p32 p33 p34
1Z) からプロジェクタからみた球の三次元位置座標に変換することができる. この変換をすることにより,プロジェクタからみた球までの三次元的な距離がわ
かり, 映像を描く際のサイズを求めることができる.
キャリブレーション後に映像を投影した様子を図5 に示す. 現実空間で異なる位置に球を移動しても,球に合わせた映像が適切に投影される.

3.3

位置推定と運動モデルによる軌道予測

図 6 はシステムの流れを示している. 球をカメラで撮影してから, その球にプロジェクタから映像を投影する過程には, 各装置の処理時間とデータ転送時間が発生する. これらの装置の処理時間とデータ転送時間を合計した時間を, 本研究では遅延時間という. 遅延時間が発生している間も球は運動しているため, 単に取得した三次元位置に映像を投影しても, 球に正しく投影されない. そこで, 運動している球に合うように映像を投影するために, カルマンフィ
ルタを用いて球の状態を統計的に推定し, 運動モデ
ルを適用することで遅延の対策を行う.
カルマンフィルタは, 事前の観測値から現在や事後の確率を最大化するシステムの状態モデルを構築することができる [11]. つまり, 次々と得られる球(1)

この式は, キャリブレーションにより投影変換行列を求めることができれば, モーショキャプチャ座標(X, Y, Z) が与えられた時に, プロジェクタから投影する二次元座標のどの位置に球の映像を描けばよいかを示している. 投影変換行列は 12 個の要素からなるため, 座標 (X, Y, Z, u, v) を 6 組以上与えることで求めることができる. 本システムでは, 精度を上げるため座標 (X, Y, Z, u, v) を 12 組与え, 最小
二乗法により投影変換行列を求めている. また, 投
影変換行列を用いてプロジェクタの外部パラメータを求めることで, モーションキャプチャ座標 (X, Y,- 63 -WISS 2013の座標データを用いて球の状態 (位置, 速度, 加速度)を統計的に推定することができる. 球の位置ベクト
ルを式 (2) と表す.

pk = (Xk , Yk , Zk )T(2)

このとき, 球の状態を位置, 速度 (一つのドット), 加
速度 (二つのドット) で表すと, 状態ベクトルは式 (3)
と表す.
T
T T
xk = (pT
k , ṗk , p̈k )(3)

球の運動は等速度運動と仮定した場合の状態モデル
を式 (4) に示す (w はシステムノイズ, I は 3 x 3 の単位行列, ∆t はデータの取得周期).
  
  
1
2 

pk

図 7. 投げ上げている最中の数フレームの投影精度. 球全体の面積と投影部分の面積の割合により投影精度が算出される.

I ∆tI 2 (∆t) I
pk−1
0
I∆tI   ṗk−1  +  0  (4)
0 0
I
p̈k−1
w

 ṗk  =  0p̈k

観測マトリクスは式 (5) とし球の位置のみを観測する.
'(

H= I 00(5)

これらの式を用いてカルマンフィルタの予測フェー
ズと修正フェーズを繰り返し行うことで, 球の状態を推定する.
カルマンフィルタにより, 現在の状態を推定した
ら, システム全体の遅延時間を ∆T として, 式 (6) の運動モデルにより, 球の軌道予測をする.

1
pk+1 = p̈k ∆T 2 + ṗk ∆T + pk
2(6)

図 8. 投影精度 - フレーム数. カルマンフィルタにより位置推定をし, 運動モデルを適用することで投影精度は安定する.

投影精度の評価実験

4
4.1

評価の尺度

しきい値は球面積の半分に映像が投影されるように設定し, 球部分のヒストグラムから大津の二値化[12] を用いて事前に決定する.
図 7 は投げ上げ中のある連続したフレームの円抽
出と投影精度を表している.

球にどの程度の映像が正しく投影されたかを, シ
ステム外部からカメラを用いて評価する. 評価の尺度として, カメラ画像からみた球全体の面積 (半球)に対する, 投影映像の面積の割合を投影精度と定義
する. 例えば, 投影された面積が球全体の面積の半分ならば, 投影精度は 50 %となる.

4.2

4.3

評価実験の結果

実験は, 120fps のフレームレートで撮影できるカメラを使用し, 球を投げ上げてからつかむまでの一連の運動を記録した. システム全体の遅延時間は56ms と設定し単に運動モデルを適用した場合と, カルマンフィルタと運動モデルを合わせた場合の軌道予測を比較する. 遅延時間は球の個数により数 ms
変化するが, 今回は定数として任意に決定した.
図 8 は式 (6) の運動モデルを単に適用した場合と,カルマンフィルタで位置を推定した後に運動モデルを適用した場合の投影精度 - フレーム数のグラフである. カルマンフィルタと運動モデルを合わせた軌道予測では, 投げ上げの最高点 (35frame 前後) で球の速度が遅くなるため, 投影精度は 80%以上となる

評価のアルゴリズム

評価はカメラのグレースケール画像を以下の手順で処理することにより行う.

1. 球全体の面積を求める:
Hough 変換を用いて円抽出を行い, 円の面積
(pixel) を算出する.
2. 投影部分の面積を求める:
1 で円抽出をした領域をしきい値を用いて 2値化し, 投影部分の面積 (pixel) を算出する.
3. 投影精度を求める:(投影部分の面積 / 球全体の面積) を求めることにより, 投影精度を算出する.

- 64 -

LumoSpheres: 複数浮遊物体の実時間追跡にもとづく映像投影

図 9. DigitalJuggling: 本システムをトスジャグリングに応用した例. 映像の投影なし (左), 球状の映像を投影 (中), 非
球状の映像を投影 (右). トスジャグリング中も動的に映像を切り替えることができる.

が, 速度が速い投げ上げ直後とつかむ直前では投影精度がおよそ 40 %から 75%となる. 単に運動モデルを適用した軌道予測では, 球がどの位置であろうが, 投影精度はおよそ 30 %から 75%となる. カルマ
ンフィルタは過去のデータを統計的に計算するため,
計測時に発生するノイズの影響に強く, 単純に運動モデルを用いた場合と比較して安定した投影となった. 球の速度が速い時に投影精度が振動するのは, 球は時間的に連続して動いているにも関わらず, プロ
ジェクタが 60 Hz で動作しているのが原因である.

5

アプリケーション

図 10. パーティクル型立体ディスプレイのプロトタイ
プ.12 個の小球に割り当てた色を投影している.

本システムは, プロジェクションマッピングやディ
スプレイの空間的な拡張, スポーツの映像的な拡張,
ビデオゲームなどのエンタテイメントなど, コンテ
ンツ次第で様々な応用が考えられる. ここでは応用
例として, LumoSpheres をトスジャグリングへ応用した DigitalJuggling, パーティクル型立体ディスプ
レイのプロトタイプを示す.

5.1

させ, ランダムに色を割り振られた映像が投影されている.

6

LumoSpheres システムの構築を通して, 運動する
少数の物体に対して映像を投影する手法を探求した.
ここでは, パーティクル型立体ディスプレイを実現する上で必要な要素を議論する.

DigitalJuggling

図 9 に DigitalJuggling の様子を示す. システム
をトスジャグリングに応用した例である. 映像を投影しない場合は通常のジャグリング球であるが, 投影する映像次第で様々なテクスチャの球でトスジャ
グリングをしているように見える. テクスチャは, ビ
リヤードの球のような球状でも, 蝶のような非球状でもよい. 通常のジャグリング球を用いた場合と異なり, 動的なテクスチャの変化が可能である.

5.2

議論: システムの現状と利点, 問題点

6.1

プロジェクタのフレームレート

本システムは球の運動速度が速くなるにつれて,投影映像のちらつきが生じる. これは, 使用したプロジェクタの映像更新フレームレートが 60 Hz であることが原因である. 現実空間の球の運動は連続的であるのに対し, プロジェクタの映像更新は不連続である. 映像が更新された直後は球に映像が合っていても, 次の更新までに球が移動するため映像がちらついてみえる. これを解決するためには, 単純にプロジェクタのフレームレートを上げる, または,
Okumura らの研究 [9] のように高速に光軸制御をする装置を用いることで, プロジェクタからの映像

パーティクル型立体ディスプレイ

図 10 にパーティクル型立体ディスプレイのプロ
トタイプを示す. 小球は直径 10cm の球と同様に, 直
径 4cm のピンポン球に再帰反射シートを貼り付けている. 12 個の小球は, 人の手によって空中に飛散- 65 -WISS 2013の更新を連続的に近づける必要がある.

6.2

する手法を探求した結果, 議論で述べた通り, 様々な問題が浮かび上がってきた. 今後はこれらの問題点を改善しつつ, 多くの物体へ安定した映像が投影できるような手法を更に探求していきたい.

物体のオクルージョン本システムは少数の球であれば映像を投影できるが, 多数の球になると正確な位置に映像が投影されない. これはカメラの画像で球同士の重なりが生じると, カメラ同士でステレオマッチングができなくなり, 位置を正しく計測できなくなるのが原因である. これを解決するためには, 単純にカメラの台数を増やす, または, 単一の球のみではなく複数の球の相互関係を考慮した予測を行うことで解決できる. これは, 球同士の衝突により生じる急激な運動の変化に対しても有効であると考えられる.

6.3

参考文献
[1] Hidei Kimura, Taro Uchiyama, and Hiroyuki
Yoshikawa. Laser produced 3D display in the air.
In ACM SIGGRAPH 2006 Emerging technologies, July-August, 2006.
[2] Alex B., Otmar H., Shahram I., Steve H., David
M., David K., and Danny K.. Vermeer: directinteraction with a 360 ° viewable 3D display. In
Proceedings of the 24th annual ACM symposium
on User interface software and technology, October, 2011.
[3] FogScreen. http://www.fogscreen.com/.

遅延対策としての予測装置の処理時間やデータの転送時間が生じない理想的な装置であれば, 軌道予測をする必要はなく, 計
測した球の位置に瞬間的に映像を投影すればよい.
しかし, 今後もコンピュータやビジョンセンサの進
歩はあるものの, 遅延がなくなることはない. そのような意味で, Okumura らの研究 [9] のようにセン
サビジョン部分のハードウェアを工夫して高速にするというアプローチは重要であるが, コンピュータ
部分のソフトウェアを工夫した軌道予測によるアプ
ローチも意義のあるものであると考える.

6.4[4] Masahiro Nakamura, Go Inaba, Jun Tamaoki,
Kazuhito Shiratori and Junichi Hoshino. Mounting and application of bubble display system. In
Proceedings of the 2006 ACM SIGCHI international conference, June, 2006.
[5] Yasushi Matoba, Taro Tokui, Ryo Sato, ToshikiSato, Hideki Koike. SplashDisplay: volumetricprojection using projectile beads. In Proceedingsof the 2012 Virtual Reality International Conference, March, 2012.
[6] Peter C. Barnum, Srinivasa G. Narasimhan, andTakeo Kanade. A multi-layered display with water drops. In ACM Transactions on Graphics(TOG), v.29 n.4, July, 2010.

想定される構成と利点

以上を踏まえて, パーティクル型立体ディスプレイの想定される構成は, 連続してパーティクルを空中に飛散させる装置, その装置の周囲を囲むように配置した複数のカメラとプロジェクタ, そしてパー
ティクル全体をシミュレーションするプログラムが必要である. 本構想の最大の特徴は, 直接的なイン
タラクションが可能な裸眼立体ディスプレイであるが, その他の利点として, 球に貼り付けた再帰反射
シートの性質を利用して, 同じディスプレイ空間で複数人が異なる映像を見ることができる. 再帰反射の性質により複数台のプロジェクタから投影された映像が混合しないことを利用する. これは, 空中で色を発光させるような構造 [1] では実現できない.

7[7] Mine, M., Rose, D., Yang, B., Jeroen van Baar,and Grundhfer, A. Projection-Based Augmented
Reality in Disney Theme Parks. IEEE Computer45, 32-40, July, 2012.
[8] Matthew Parker. Lumarca. In ACM SIGGRAPH
ASIA 2009, December, 2009.
[9] Kohei Okumura, Hiromasa Oku, and Masatoshi
Ishikawa. Lumipen: Projection-Based Mixed Reality for Dynamic Objects. In Proceedings of the2012 IEEE International Conference on Multimedia and Expo, p.699-704, July, 2012.
[10] Richard Hartley, and Andrew Zisserman. Multiple View Geometry in Computer Vision. Cambridge University Press, 2003.
[11] Greg Welch, and Gary Bishop. An Introduction
to the Kalman Filter. University of North Carolina at Chapel Hill, 1995.
[12] Nobuyuki Otsu. A Threshold Selection Methodfrom Gray-Level Histograms. IEEE Transactions
on Systems, Man, and Cybernetics, Vol. SMC-9,
No. 1, pp. 62-66, 1979.

結論と今後の方向性

運動している複数の球に実時間追跡にもとづき映像を投影することで体積型の立体ディスプレイとなる, パーティクル型ディスプレイを提案し, その基礎段階として, 運動している少数の球に実時間追跡にもとづいた映像を投影するシステム, LumoSpheresを構築した. そして, LumoSpheres システムの応用例として DigitalJuggling を実装し, パーティクル型
立体ディスプレイのプロタイプを実装した.
今回の研究では, パーティクル型ディスプレイの基礎段階として, 球一つ一つに映像を合わせて投影- 66 -WISS2013

画像照合に基づく多メディア間の話題追跡システム
豊田 正史

伊藤 正彦 ⇤ Cai-Zhi Zhu

佐藤 真一

宇野 毅明 † 喜連川 優 ‡概要. 本論文では，Web と放送映像との間の画像の対応関係に基づき話題の追跡を行える新たなシステ
ムを提案する．社会事象を解析する際には，話題がどのメディアから始まったかを同定し，その話題がどのようにメディア間に広がっていったかを分析する必要がある．Web と放送映像との対応を取るため，Web
上のテキストと放送の字幕情報を用いることも可能であるが，字幕の量は十分ではなく，字幕が付けられていない番組も多数存在するため，映像情報の対応関係を解析する事が不可欠となる．提案するシステムでは，ブログ等の Web メディアに投稿された大量の画像から大きな話題になり多数出現した類似画像を抽出し，これが放送映像を起源とするものかどうかを放送映像アーカイブと照合して，話題の時差や露出の差を調査できる手法を実現した．本システムを用いて，大規模なブログアーカイブと放送映像アーカイブを分析した事例を幾つか示すことで本システムの有用性を示す．

1

はじめに

間で及ぼされる影響の分析が可能になる．

Web はその出現から約 20 年の間に，ニュースサ
イト，掲示板，ブログ，ソーシャルメディア，コン
テンツ共有サイトなど多数のメディアの集合体として進化を続けてきた．現在は，これら Web 上のメ
ディアとテレビや新聞などの従来型マスメディアを包含する多メディアが人々の社会活動を反映し，かつ影響を与えていると言える．こうした状況において，社会事象を分析する際には話題がどのメディアから出現したかを同定し，その話題がどのように多メディアの間に広がっていったかを分析する必要がある．現在においても Web メディアはマスメディ
ア，特にテレビ放送から受ける影響が大きく，Web
メディアとテレビ放送の間の話題追跡は重要な課題である．
従来，Web メディアとテレビ放送での話題分析においては，Web 上のブログやソーシャルメディアなどの記事および番組表や字幕など，テキスト情報を用いたものが主であった．しかし，これらのメディ
アでは積極的に映像・画像を用いることで，文章のみでは伝えることが困難なイベントや事件事故などの様子を伝えており，また字幕の量は十分ではなく，字幕が付けられていない番組も多く存在するため，
映像情報の対応関係を解析する事が不可欠となる．
Web 上で話題になった画像が，放送映像中では同じように現れているのか，また，その出現に前後関係はあるのか，話題や画像ごとに出現の仕方に違いや類似性があるのか，逆に特徴のある画像群は具体的にどのような話題を扱っているのか等を調査することにより，以下のような社会事象や多メディア
Copyright is held by the author(s).
東京大学生産技術研究所†
国立情報学研究所‡
東京大学生産技術研究所・国立情報学研究所⇤- 67 -• ニュースが各メディアにおいてどのような画像で扱われていたか，メディアにより現れる
画像に違いがあるかを調査する．

• イベントや集会などの模様や賑わいを視覚的に把握することで，メディアによる扱われ方の差があるかどうかを調査する．

• 商品画像の出現数の変化から，人気の度合い
やデザインの変化を把握する．

本論文では，Web メディアに投稿された大量の画像から大きな話題になり多数出現した類似画像を抽出し，これが放送映像を起源とするものかどうかを
放送映像アーカイブを照合して抽出し可視化することで，話題の時差や露出の差を調査できる手法を提案し，それを実現するシステムを実装する．本シス
テムを，大規模なブログアーカイブと放送映像アー
カイブに適用し，実際に観測された社会事象の事例を示すことで本システムの有用性を示す．
以下，第 2 節では関連研究について述べ，第 3 節
で提案システムの詳細を説明する．第 4 節において本システムを用いた実験結果を示し，第 5 節で本論文をまとめる．

2

関連研究

従来，Web メディアおよびテレビ放送における話題分析においては，単独のメディアを用いたものが多く，複数メディアを扱ったものでも Web 上のブログやソーシャルメディアなどの記事，および番組表や字幕などテキスト情報を用いたものが主であり，大規模な画像照合を用いて多メディア間の情報追跡を行えているものは筆者の知る限りでは存在しない．

WISS 2013

Adar らは，検索エンジンの検索クエリとテレビ
番組情報の出現時差の解析を行っており [1]，Yang
らは，ブログ，新聞，テレビ等の複数メディアにおける話題の時系列パタンを抽出しているが [7]，これらは基本的にテキストデータに現れる語やフレーズの出現頻度を用いたもので画像情報は用いられていない．Luo らは，大規模なニュース画像アーカイ
ブの可視化，および話題分析を行っているが [5]，複数のメディアにまたがる分析までは行えていない．

3

トピックを抽出する．さらに Web 画像トピックに含まれる Web 画像集合群に対応する放送
画像集合を集約することで，放送映像トピッ
クを抽出する．こうして得られた Web 画像ト
ピックとそれに対応する放送映像トピックの時間推移を 3 次元空間に可視化し，メディア間におけるトピックの推移およびその差を閲覧探索可能とする．
以下では，ほぼ同一画像のクラスタリング，放送
映像検索の実現方法，トピックの 3 次元可視化手法についてより詳細に説明する．

多メディア間話題追跡システム

本論文で提案するシステムは，大規模な Web メ
ディアのアーカイブを用いてユーザの指定した調査
対象に関連する記事および画像を抽出し，さらに放送映像のアーカイブを用いて画像照合を行い，抽出した Web 画像に対応する放送映像での露出を抽出することで，これら画像の頻度，時間推移，および出現時差を調査可能にするものである．本システムは，Web メディアアーカイブとして，ブログやソーシャ
ルメディアのように，各記事に対して書き手と書かれた時間が紐付けされた文書アーカイブを想定しており，全文検索インデックスによって記事が検索可能となっているものとする．また，放送映像アーカ
イブに関しては，画像を入力としてその画像に類似する映像が放送されたショットを検索可能とする検索インデックスを実現して用いている．
ユーザは，調査対象に関する複数の検索語を入力としてシステムに与え，システムは，以下のような手法で，画像抽出，分析，可視化を行う．

1. Web メディアアーカイブを検索し，与えられた検索語を含む記事の集合を取得する．各記
事はそれが書かれた時間，書き手，および記事本文を含む．

2. 取得した記事の本文に含まれている画像をすべて取得し，各画像の周辺のテキストを抽出する．

3. Web メディア上で話題となり数多くコピーされた画像を抽出するため，ほぼ同一とみなせる画像のペアを列挙しクラスタリングを行う．
この結果得られる Web 画像集合は単独の画像が多数出現したことを表し，画像に基づく話題を構成する要素となる．

4. 抽出した各 Web 画像集合を検索クエリとして用いて，放送映像アーカイブを検索し，類似画像が放送されたショットの集合を抽出する．
抽出された各ショットの集合を，便宜上 Web
画像集合に対応する放送画像集合と呼ぶ．

5. Web 画像集合を，それらの周辺テキストの類
似度を用いてクラスタリングすることで，高頻度で出現する画像の類似集合である Web 画像- 68 -

3.1 ほぼ同一画像のクラスタリング
Web 上の画像は，オリジナルの画像に対し拡大，縮小，回転や，切り取り，一部変更などの加工を経て公開されるものが多く，ほぼ同一の画像をクラスタリングするための類似度算出にはこうした加工に対し頑健な特徴量を用いる必要がある．本手法ではこうした状況に適した局所特徴量の 1 つである SIFT
特徴量 [4] を用いている．SIFT を用いた画像類似度
算出では，各画像から抽出された多数の SIFT 特徴
点の類似度を算出し，画像間でマッチする特徴点の数をカウントする必要がある．画像数は通常多数に及ぶため類似する SIFT 特徴点のペアを高速に列挙する手法を開発した．本列挙手法は，宇野による大規模部分文字列マッチングアルゴリズム [6] を基に
ノイズとなる特徴点の除去処理を加えて改良を施したものである．
各画像からは，サイズの正規化を行った上で，最大 100 個の SIFT 特徴点を抽出する 1 ．SIFT 特徴点
は，128 次元の数値ベクトルで表わされるが，各値を中央値以上か，それ以下かの 2 値に量子化し，128ビットのベクトルに変換する．さらにこの数値ベク
トルは 8 個の値からなる 16 のブロックから構成されることを考慮し，各 8 ビットを 1 文字とみなすこと
で書く特徴点を 16 文字の文字列と考える．宇野の類
似文字列列挙手法は，大量の固定長文字列から，ハミング距離が一定以下の文字列ペアを高速に列挙するもので，本手法ではほぼ同一の画像を抽出するため，ハミング距離 1 以下の類似特徴点のペアをマッチしたものと見做して列挙し，画像間でマッチする
特徴点の数を，画像ペアをキーとしたハッシュ表を用いて算出する．2 つの画像の類似度は，画像間でマッチする特徴点の数で表わされる．
SIFT 特徴点を用いた類似画像抽出においては，
非常に多数の特徴点とマッチする特徴点が，ノイズとして類似度の精度に悪影響を与えることが分かっ
1

ここでは特徴点の最大数を経験的に 100 個に定めたため，
これが最適であるとは限らない．しかし最大数をこれ以上大きくすると，ブログ用の縮小画像や携帯電話などで撮影した小さな画像に関して特徴点の数が多くなりすぎノイ
ズが増すことが実験から分かっている．

画像照合に基づく多メディア間の話題追跡システムており，本手法では，類似ペア列挙の途中段階で，
閾値以上の特徴点とマッチする特徴点をフィルタする処理を加えることで，ノイズに対して頑健な類似画像抽出を実現している．ノイズとなる特徴点の数は非常に少ないため，計算量を大きく削減するもの
ではないが，大量の類似特徴点のペアを出力した後フィルタする必要がなく直接類似画像ペアを出力できるため，中間出力を削減することができる．本手法は，4 百万画像から抽出した 4 億の SIFT 特徴点の集合を用いて類似画像ペア (閾値 1000 の場合，約1.35 億ペア) を列挙するのに，10GB のメモリと 20コアを用いて 2 時間程度しかかからないスケーラビ
リティを持っている．
類似する画像のペアが列挙できると，画像をノード，類似度をエッジとしたグラフを作ることが可能となる．本手法では，このグラフに対して，スター
クラスタリング [2] という簡易なクラスタリング手法を適用することで，画像集合を抽出している．ス
タークラスタリングは，次数の一番高いノードを中心とし，閾値以上の類似度を持つ隣接ノードを，中心と同じクラスタとして出力するという処理を繰り返す単純なものである．本手法では，あるノードについて後からより類似度の高い中心が見つかった場
合，元の中心からその中心へ所属を切り替えるという簡易な改良を施して用いている．スタークラスタ
リングの計算時間はノード数とエッジ数の和に比例しており，大規模なデータをインタラクティブにク
ラスタリングするのに適している．また，類似度の低いノードをあえてクラスタに所属させることは無
いため，ノイズの多いデータのクラスタリングにも適している．こうした理由から本手法ではスターク
ラスタリングを用いているが，他のクラスタリング
手法を用いても良い．

3.2

放送映像の検索手法

放送映像アーカイブ中のショットを任意の画像により問い合わせ可能な，問い合わせ画像中と同一の物体を含む映像を検索可能なシステムを [8] の手法に基づき構築した．まずオフライン処理として，放送映像アーカイブを構成する各映像クリップから，非常に密にフレーム画像を切り出し（例えば 3 フ
レームごとに 1 フレーム），各フレーム画像から密に SIFT 等の局所特徴量を抽出する（たとえば各フ
レーム画像から数百点，SIFT もしくは color SIFTを使用）．局所特徴量は階層的 k-means により，100
万コードブックというきわめて疎な離散化を行い，各クリップにつき一つの Bag of Feature (BoF) ベ
クトルを得る．次いで，検索時のオンライン処理では，与えられた問い合わせ画像から，同様に BoF ベ
クトルを得る．これとデータベース中の BoF ベク
トルとの間で L1 距離を求め，ランキングリストを得ることにより，検索を実現している．検索は転置- 69 -

索引により効果的に高速化可能である．
この方法で実際に検索を行うと，大規模なデータベースが対象となった場合，検索結果にノイズがきわめて多くなってしまうことが判明した．そこで，幾何整合性判定によりリランキングを行う技術 [3]を導入して，精度の向上を図っている．

3.3

多メディア間のトピック可視化・閲覧手法

本システムでは，Web メディアおよび放送映像から抽出されたトピックの時系列推移を可視化する
ことで，多メディア間の影響分析を視覚的に可能にする新たな可視化手法を提案する．
図 1 に本可視化手法の概要を示す．平面上に，時間軸とトピックの軸を持ち，各時間軸上に Web メ
ディアアーカイブから抽出された Web 画像集合，および放送映像アーカイブから抽出した対応する放送
画像集合をヒストグラムとして可視化している．画
像は単位時間ごと（例えば 1 日ごと）に集約され，その時間に出現した画像を高さ方向に積み上げることで，画像による棒グラフから構成されるヒストグ
ラムとして表現される．
画像の出現の時間差を認識しやすくするため，Web
メディアと放送映像の画像ヒストグラムは，図 1 のように並列して配置することもでき，また，図 3 のように上下にヒストグラムを反転させて配置することも可能である．
上記の手法で抽出された Web 画像集合は，さらにその周辺テキストを用いて意味的にトピックにまとめることも可能である．図 1 では，各 Web 画像集合に含まれる画像の周辺テキストをまとめて 1 文書とみなし，tf-idf で重み付けした単語頻度ベクトルを算出し，コサイン類似度を用いて上記のスター
クラスタリングを行い，Web 画像トピックにまとめている．Web 画像集合のクラスタリングに関して
は，スタークラスタリングの閾値をインタラクティ
ブに変更しながらクラスタリング結果を閲覧するシ
ステムを用意し，適切な閾値を選択可能としている(図 2)．こうして得られた Web 画像トピックに対し，放送映像側には各 Web 画像集合に対応する放送画
像集合をまとめて放送画像トピックとして表示している．
ユーザは，Web 画像数およびショット数の時系列に対する交差相関係数，コサイン類似度等のレンジをパラレルコーディネートを用いたダイナミックク
エリにより対話的に指定することで，様々な時間差をもつ画像クラスタを抽出し，容易に詳細を探索することが可能である．交差相関係数を用いると，指定したメディアで先行して（もしくは遅れて）現れた画像集合を抽出することができ，放送先行もしくは Web メディア先行で流行した話題を抽出することが可能になる．時系列間のコサイン類似度が高い
画像集合を抽出することで出現タイミングが似ていWISS 2013

図 1. 複数トピックの推移の概要を可視化る話題を抽出でき，類似度が低い画像集合からは，放送もしくは Web メディアのみで流行した話題を抽出することができる．

44.1

大規模ブログアーカイブおよび大規模放送映像アーカイブを用いた実験
データセット

前節のシステムを実装し，我々が東京大学生産技術研究所において収集している大規模ブログアーカ
イブおよび大規模放送映像アーカイブを用いた実験を行った．Web メディアとしては，我々が 2006 年から収集している延べ 200 万ブログを対象とした
RSS/Atom フィードのアーカイブを用いた．特に，社会分析のターゲットとして 2011 年 3 月から 2012
年 9 月に起きた，東日本大震災およびそれに引き続く原発事故，サッカー女子ワールドカップ，北朝鮮
ミサイル問題，ロンドンオリンピックなどを想定して，検索用のキーワードを約 90 個程度選出し，アー
カイブから抽出したブログ記事に含まれる約 400 万の画像を実験データとして用いた．
また，国立情報学研究所においてアーカイブした，2011 年 3 月より 2012 年 9 月までに放送された
全チャンネルのニュース番組，合計約 6000 時間分を対象として検索インデックスを構築した．検索イ
ンデックス構築対象の 6000 時間分のニュースに対- 70 -

し，連続フレーム間の色ヒストグラム差分に基づく
ショット分割を行い，約 300 万ショットを検出した．
これが検索対象の単位となる．さらに，各フレーム単位での詳細な物体検索を実現するため，1 秒おきに約 2000 万キーフレームを抽出した．局所特徴量数は約 200 億となる．こうして構築したデータベースに対し，ブログから想定したターゲットに関連するキーワードに基づいて抽出した 4000 の Web 画像
集合 (46000 画像) を問い合わせとして照合を行い，相互の影響解析につながる根拠となるような画像が数多く検出されたことを確認した．

4.2

事例

本節では上述のデータセットを用い，提案システ
ムを用いて抽出した多メディア間の話題追跡の事例を示す．
図 1 は，震災，原発，オリンピック等の検索語でブログアーカイブから抽出した Web 画像トピック，
さらに放送映像アーカイブから抽出した対応する放送画像トピック，それぞれをトピック毎，一日毎に集約し時間軸上に可視化している．全体像を俯瞰（図(a)）することで，トピック間の類似性や，ブログ・
放送映像間で同時にバーストしている期間などを観測できる．さらに，時系列に対する交差相関係数，
コサイン類似度等から様々な反応差をもつ画像集合を対話的に抽出し詳細を探索することが可能である．

画像照合に基づく多メディア間の話題追跡システム

図 2. Web 画像集合のクラスタリング結果の可視化

この中から，東日本大震災の際の福島第一原発事
故に関するトピックに着目し，拡大したものが図 3である．このトピックに含まれる画像の多くは，事故のあった建屋を撮影したもので，画像ヒストグラ
ムの形状，及び写真の出現順序を見ることで，これらがニュース番組において繰り返し使用され，その後ブログ上でも広まったことが見て取れる．同種の写真は，放送のみならず新聞等のメディアにおいても使用されており，この場合においてはマスメディ
アが先行して写真を掲示し，それがブログに広まったと解釈することができる．
本システムのダイナミッククエリ機能を用いると，
このトピックの中からブログが先行して用いた画像があるかどうかを調べることができる．図 4 は，交差相関係数を用いてブログが先行している画像クラスタを抽出したものである．この画像は，MIT の研究者によるブログにおいて福島第一原発事故解説に用いられた原子炉の透視図である．本記事が日本のブログにおいて翻訳され話題となり，その後 2 日遅れてニュース番組で用いられるようになったことが分かる．番組作成者が実際にブログを見てこの画像を発見したかどうかまでは不明であるが，これは画像の照合を用いることで初めて発見できる映像素材の原典追跡の事例となっている．メディア社会学と呼ばれる学問分野においては，映像の原典を探ることが重要なテーマの一つとなっており，本手法はそうした調査に有用である．
テレビとブログとでは，同じ話題に対する反応の大きさや勢いが異なり，それは国際問題，政治問題において顕著であることが今回の実験結果から分かっている．図 5 はその一例を示したものである．2012
年のオリンピックにおいて，試合の終了時にある選- 71 -

図 3. 福島第一原発事故に関するトピックのメディア比較

手が政治的なアピールをしたことが問題となった．
そのニュースは最初テレビで放送されたが，その画像の露出は少なかった．しかし，このニュースは多くのブロガーを刺激しブログ上ではこの画像が大量に使われることとなった．この大きな反応を受けて，テレビのニュースでもこの問題が大きく扱われるようになった．こうした，テレビとブログが相互に反応して話題が大きくなるケースは，センシティブな国際問題や政治問題において良く見られるパターン
である．

5

まとめ

本論文では，ブログ等の Web メディアに投稿された大量の画像から大きな話題になり多数出現した類似画像を抽出し，これが放送映像を起源とするものかどうかを放送映像アーカイブを照合して，話題の時差や露出の差を調査できるシステムを実現した．
さらに大規模なブログアーカイブと，放送映像アー
カイブを用いて実験を行い，様々な社会現象に関する多メディア間の情報追跡を行えることを示した．
本システムを用いることで，過去に起きた様々なイベントに対しての Web メディアと放送映像での反応の違いを学ぶことが可能であり，得られた知見

WISS 2013

は今後同種のイベントが起きた際にどのような反応が各メディアで起こるかを予想する際の手がかりとなり得る．また，一方のメディアで話題になっているのに，もう一方のメディアでは大きな話題にならないケースも，幾つか本システムで観測されており，その原因を探ることで企業や組織の広報活動に活用することも可能である．ここで示した事例は，本実験で得られた知見のごく一部であるが，本システムを用いることで多メディアに関わる様々な興味深い社会事象を捉えられる可能性を示せていると信じる．
現状では，Web 画像集合と対応する放送画像集合が算出された後はある程度インタラクティブに閲
覧・探索が行えるが，そのための事前計算には依然としてコストが高い．画像の特徴量抽出や放送映像
データベースの索引を事前に作成しておくことはできるものの，画像類似度の算出や，対応画像の検索
はインタラクティブに行えるほどではないため，一層の高速化が必要である．

図 4. ブログがテレビ放送に先行した画像の例

謝辞
本研究は，文部科学省「多メディアＷｅｂ解析基
盤の構築及び社会分析ソフトウェアの開発」，および JSPS 科研費 25280111 の助成を受けたものです．

参考文献[1] E. Adar, D. S. Weld, B. N. Bershad, and S. D.
Gribble. Why We Search: Visualizing andPredicting User Behavior. In Proceedings of
WWW’07, pp. 161–170, 2007.
[2] J. A. Aslam, E. Pelekhov, and D. Rus. The Star
Clustering Algorithm for Static and Dynamic Information Organization. Journal of Graph Algorithm and Applications, 8(1):95–129, 2004.
[3] K. Lebeda, J. Matas, and O. Chum. Fixing the
Locally Optimized RANSAC. In Proceedings ofBMVC, 2012.
[4] D. G. Lowe. Distinctive Image Features from
Scale-Invariant Keypoints. International Journalof Computer Vision, 60(2):91–110, 2004.
[5] H. Luo, J. Fan, J. Yang, W. Ribarsky, and
S. Satoh. Analyzing Large-Scale News Video
Databases to Support Knowledge Visualization
and Intuitive Retrieval.
In Proceedings of
VAST’07, pp. 107–114, 2007.
[6] T. Uno. Multi-sorting algorithm for finding
pairs of similar short substrings from large-scale
string data. Knowledge and Information Systems, 25(2):229–251, 2010.
[7] J. Yang and J. Leskovec. Patterns of Temporal Variation in Online Media. In Proceedings of
WSDM’11, 2011.
[8] C. Z. Zhu and S. Satoh. Large Vocabulary Quantization for Searching Instances from Videos. In
Proceedings of ICMR’12, pp. 52:1–52:8, 2012.

図 5. テレビとブログが相互に影響を与えた例- 72 -WISS2013੩ࢭը಺෺ମ΁ͷม‫ʹࣔࢦܗ‬ΑΔಈը‫ࡧݕ‬
઒ख ༟ଠ

Ԭ෦ ੣

ඌ಺ ཧ‫෉ل‬ฏ໺ ኍඒ ∗

֓ཁ. զʑ͸ಈը͔Βࢹௌ͍ͨ͠γʔϯΛૉૣ͘ɼ༰қʹ‫͢ࡧݕ‬ΔͨΊͷϢʔβΠϯλϑΣʔεΛఏҊ͢Δɽ‫ط‬ଘͷಈը‫ڞ‬༗αΠτͰ࢖༻͞Ε͍ͯΔ‫ࡧݕ‬Τϯδϯ͸ςΩετΛ࢖༻ͨ͠΋ͷͰ͋ΔͨΊɼࢹௌ͍ͨ͠γʔϯͷ༷ࢠ·Ͱ͸‫͢ࡧݕ‬Δ͜ͱ͕Ͱ͖ͳ͍ͱ͍ͬͨ໰୊఺͕ଘࡏ͢ΔɽզʑͷγεςϜͰ͸ɼϢʔβ͕ಈը಺ͷҰ࣌ఀࢭϑϨʔϜ౳ͷ੩ࢭըΛೖྗ͠ɼ੩ࢭը಺ͷ෺ମͷม‫ܗ‬Λ໼ҹ 2 ຊͷεέονʹΑͬͯࢦࣔΛ͢Δ͜ͱ͕Ͱ͖Δɽͦͷ‫ޙ‬ɼγεςϜ͸Ϣʔβ͕໼ҹͰࢦఆͨ͠ม‫ͨ͠ࣅྨʹܗ‬γʔϯΛ‫͠ࡧݕ‬ɼϢʔβ͸໨తͷγʔϯΛࢹௌ͢Δ͜ͱ͕Ͱ͖Δɽզʑͷख๏Ͱ͸ɼϢʔβ͕ࢹௌ͍ͨ͠໨తͷγʔϯΛ‫ࡧݕ‬
͢ΔͨΊʹ 2 ͭͷεςοϓΛ࠾༻͍ͯ͠Δɽୈ 1 εςοϓͰ͸ඪ४తͳը૾‫ٕࡧݕ‬ज़Λ࢖༻͠ɼೖྗ͞Εͨ੩ࢭ಺ͷ෺ମͱಉ͡֎‫؍‬ͷϑϨʔϜΛ‫͢ࡧݕ‬Δɽୈ 2 εςοϓͰ͸લεςοϓͰબ୒ͨ͠ϑϨʔϜ͔Βࣗಈతʹલ‫ޙ‬ϑϨʔϜ΁ͱૣૹΓͱ‫ר‬໭͠Λߦ͏͜ͱͰɼ໨తͷγʔϯΛ‫͢ࡧݕ‬ΔɽૣૹΓͱ‫ר‬໭͠Λߦ͍ɼϢʔβ͕ 2 ຊͷ໼ҹͰࢦఆͨ͠ม‫͞ݟൃ͕ܗ‬Εͨ৔߹ɼૣૹΓͱ‫ר‬໭͠Λఀࢭͤ͞ɼ໨తͷγʔϯΛ
ग़ྗ͢Δɽ͜ͷ 2 ͭͷεςοϓΛߦ͏͜ͱʹΑΓɼ੩ࢭը಺෺ମ͕ԣ޲͖ʹ΋͔͔ΘΒͣɼ֎‫؍‬ͷҟͳΔਖ਼
໘޲͖ͷ෺ମ͕өΔγʔϯΛ‫͢ࡧݕ‬Δͱ͍ͬͨ͜ͱΛՄೳʹͨ͠ɽզʑ͸͜ͷख๏͕ F1 Χʔͱഅɼඈߦ‫ػ‬
ͷ 3 छྨͷ෺ମʹ͓͍ͯ༗ޮͰ͋Δ͜ͱΛ֬ೝͨ͠ɽ

1

͸͡Ίʹ

ಈը‫ڞ‬༗αΠτͷී‫ʹٴ‬ΑΓɼΠϯλʔωοτ্Ͱࢹௌ͢Δ͜ͱ͕Ͱ͖Δಈըͷ਺͸೔ʹ೔ʹ૿Ճ͠
͍ͯΔɽϢʔβ͸ͦΕΒͷಈը͔Βࢹௌ͍ͨ͠γʔϯΛਝ଎͔ͭ༰қʹ‫͍ͯ͑ߟͱ͍ͨ͠ࡧݕ‬Δɽͨͩ
͠ɼYouTube1 ΍χίχίಈը 2 ͳͲͷಈը‫ڞ‬༗αΠτͷಈը‫ࡧݕ‬Τϯδϯ͸ɼςΩετͰ͔͠‫͢ࡧݕ‬Δ͜ͱ͕Ͱ͖ͳ͍ɽͦͷ‫ࡧݕ‬ΤϯδϯͰ͸ɼ֤ಈըͷλΠτϧ΍ׂΓ౰ͯΒΕ͍ͯΔςΩετλάͷ৘ใʹ‫ߦ͕ࡧݕ͍ͯͮج‬ΘΕ͍ͯΔɽैͬͯɼ͜ΕΒͷ‫ࡧݕ‬ΤϯδϯͰɼ‫߲ࡧݕ‬໨ͱͯ͠ࢹௌ͍ͨ͠෺ମ
ͷ༷ࢠʹؔͨ͠ςΩετΛೖྗͯ͠΋‫͍ͳ͖Ͱࡧݕ‬ɽྫ͑͹ɼʮࠨ্ʹඈΜͰߦ͘ඈߦ‫ػ‬ʯͱ͍͏ςΩετʹରͯ͠ɼYouTube ΍χίχίಈըͰ͸͍ͣΕ΋ɼ
ਤ 1 ͷΑ͏ͳࠨ্ํ޲΁ඈߦ͢Δඈߦ‫ػ‬ͷγʔϯΛ
औಘ͢Δ͜ͱ͸Ͱ͖ͳ͍ɽ͞ΒʹɼͦͷΑ͏ͳςΩετΛཧղͰ͖Δಈը‫ࡧݕ‬Τϯδϯ͕͋ͬͨͱͯ͠
΋ɼϢʔβ͕෺ମͷ༷ࢠΛ‫ݴ‬༿Ͱਖ਼֬ʹ‫ه‬ड़͢Δ͜
ͱ͸ࠔ೉Ͱ͋Γɼ໘౗Ͱ͋Δɽ͜ͷΑ͏ͳ໰୊Λղܾ͢ΔͨΊʹɼզʑ͸Ϣʔβ͕ਝ଎͔ͭ༰қʹࢹௌ͍ͨ͠෺ମͷ༷ࢠΛࢦఆ͢Δ
͜ͱ͕Ͱ͖Δ৽͍͠ϢʔβΠϯλʔϑΣʔεΛఏҊ͢ΔɽϢʔβΠϯλʔϑΣʔεͰϢʔβ͕‫ࡧݕ‬Λߦ͏ࡍͷྲྀΕ͸ҎԼͷ௨ΓͰ͋Δɽ

ਤ 1. ఏҊγεςϜ

1. ࢹௌ͍ͨ͠෺ମͷөΔಈըͷҰ࣌ఀࢭͷϑϨʔ
Ϝ·ͨ͸੩ࢭըΛೖྗ੩ࢭըͱ͢Δɽ

2. εέονΠϯλʔϑΣʔε (ਤ 1(a)) ʹͯɼ2ຊͷ྘໼ҹͷඳըͰೖྗ੩ࢭը಺ͷ෺ମͷม‫ܗ‬Λࢦఆ͢Δɽ

3. γεςϜ͕ಈըσʔλϕʔε͔Β‫݁ࡧݕ‬ՌͷީิͷγʔϯΛදࣔ͢Δ (ਤ 1(b,c,d))ɽ
Ϣʔβ͸ 2 ຊͷ྘໼ҹͰೖྗ੩ࢭը಺ͷ෺ମͷม‫ܗ‬Λࢦࣔ͢Δ͜ͱͰࢹௌ͍ͨ͠γʔϯΛΠϯλϥΫ
ςΟϒʹ‫͢ࡧݕ‬Δ͜ͱ͕Ͱ͖Δɽ·ͨɼ͜ͷ 2 ຊͷ྘໼ҹ͸ 2 ࣍‫ݩ‬ͷೖྗͰ͋Δ͕ɼԣ޲͖ͷೖྗ੩ࢭը͔Βਖ਼໘޲͖ͷγʔϯΛ‫͢ࡧݕ‬Δͱ͍ͬͨɼ3 ࣍‫Ͱݩ‬ม‫ͨͤ͞ܗ‬Α͏ͳγʔϯ΋‫͢ࡧݕ‬Δ͜ͱ͕Մೳ

Copyright is held by the author(s).
Yuta Kawate, ి‫ؾ‬௨৴େֶ, Makoto Okabe, ి‫ؾ‬௨৴େֶ/JST CREST, Rikio Onai, ి‫ؾ‬௨৴େֶ, Hiromi
Hirano, ָఱ‫ࣜג‬ձࣾ/ి‫ؾ‬௨৴େֶ1
http://www.youtube.com/
2
http://www.nicovideo.jp/∗- 73 -WISS 2013

ਤ 2. Ϟνϕʔγϣϯਤ 3. ఏҊ͢ΔϢʔβΠϯλϑΣʔεͰ͋Δɽ࣮‫͍͓ͯʹݧ‬ɼ͜ͷํ๏͕ F1 Χʔɼഅɼඈ
ߦ‫͍ͨͬͱػ‬ෳ਺ͷछྨͷ෺ମʹ༗ޮͰ͋Δ͜ͱΛ
֬ೝͨ͠ɽ

2

ؔ࿈‫ڀݚ‬

ଟ͘ͷಈը͔ΒΠϯλϥΫςΟϒͳ‫ࡧݕ‬ΛՄೳʹ͢Δ֎‫؍‬ϕʔεͷΠϯλϑΣʔεͷఏҊ͸ͳ͞Ε͍ͯΔɽbag-of-features Λ࢖༻͠ɼൺֱత௿࣍‫ݩ‬ͷϕΫτϧͱ֤ͯ͠ಈըͷϑϨʔϜΛද͢͜ͱʹΑΓɼೖྗͨ͠੩ࢭը͔Β੩ࢭը΍ಈըͷ‫͕ࡧݕ‬ఏҊ͞Εͨ [3, 15]ɽଟ͘ͷಈը΍੩ࢭը͔Βߏ੒͞Εͨ 3 ࣍‫ݩ‬ͷγʔϯΛϢʔβ͕ΠϯλϥΫςΟϒʹಈ͖·Θ
Δࣄ͕Ͱ͖ΔγεςϜ͕ఏҊ͞Εͨ [1, 5, 16, 17]ɽ͜ΕΒ͸ structure-from-motion Λհͯ͠γʔϯ΍ΧϝϥͷҐஔΛ 3 ࣍‫ߏ࠶ݩ‬੒Λߦͳ͍ͬͯΔɽ͔͠͠ɼ͜ΕΒͷํ๏͸ɼ‫ݐ‬෺ͳͲͷ੩ࢭ෺ମʹ͔͠ద༻͞Ε͓ͯΒͣɼҠಈͨ͠Γɼม‫ͨ͠ܗ‬Γ͢Δ෺ମ
ʹద༻͢Δ͜ͱ͸ࠔ೉Ͱ͋Γɼඇৗʹ‫͔͕ؒ࣌ࢉܭ‬͔Δɽ
ಈը಺ͷ෺ମΛૢ࡞͢Δ͜ͱͰɼ࿈ଓͨ͠୯Ұͷಈը಺ͷγʔϯͷΠϯλϥΫςΟϒͳφϏήʔγϣϯΛՄೳʹ͢ΔγεςϜ͕ఏҊ͞Εͨ [4, 7, 8, 9, 10]ɽϢʔβ͸ɼ୯Ұಈը಺ͷ෺ମΛυϥοάʹΑͬͯΠϯλϥΫςΟϒͳ࢟੎ͷૢ࡞͕Ͱ͖ɼφϏήʔτͰ͖Δɽ͜ΕΒ͸ɼ3 ࣍‫ߏ࠶ݩ‬੒Ͱ͸ͳ͘ɼ2 ࣍‫ݩ‬ͷը૾ॲཧٕज़͕ߦΘΕ͍ͯΔͷͰɼൺֱత‫ؒ࣌ࢉܭ‬͕গͳ͍ɽ͔͠͠ɼզʑͷγεςϜ͸୯Ұͷಈը͚ͩͰ͸ͳ͘ɼෳ਺ͷผʑͷಈը͔Β෺ମΛ‫͢ࡧݕ‬Δ
͜ͱ͕Ͱ͖Δɽ

3

ϢʔβΠϯλϑΣʔεզʑͷఏҊ͢ΔϢʔβΠϯλϑΣʔε͸ɼ͋Δ෺ମͷಈըͷࢹௌ࣌ʹผͷγʔϯ͕‫͍ͨͬͱ͍ͨݟ‬ɼ෺ମͷ༷ࢠΛ‫͢ࡧݕ‬ΔγεςϜͰ͋Δɽྫ͑͹ɼਤ
2(a) ͷΑ͏ͳ F1 Χʔ͕ࠨ͔Βӈʹ૸ߦ͢Δγʔϯͷࢹௌ͍ͯ͠Δ࣌ɼਤ 2(b) ͷΑ͏ʹਖ਼໘޲͖ʹ૸
ߦ͢Δ F1 ΧʔͷγʔϯΛࢹௌ͍ͨ͠ͱ͍͏ঢ়‫گ‬Λߟ͑ΔɽϢʔβ͸ͦͷΑ͏ͳγʔϯΛࢹௌ͢ΔͨΊʹɼૣૹΓ΍‫͖ר‬໭͠Λߦ͏͔ɼγʔΫόʔΛૢ࡞͢Δɽ΋͠ɼࠓࢹௌ͍ͯ͠ΔಈըʹͦͷΑ͏ͳγʔϯ͕‫·ؚ‬Εͳ͍৔߹ɼϢʔβ͕ଞʹॴ͍࣋ͯ͠Δ F1- 74 -

ΧʔͷಈըΛҰͭҰͭ‫ݟ‬Δඞཁ͕͋ΔɽͦΕͰ΋ൃ‫͔ͨͬͳ͖Ͱݟ‬৔߹ɼYouTube ౳ͷಈը‫ڞ‬༗αΠτͰ‫͚ͭݟ‬ग़͞ͳ͚Ε͹ͳΒͳ͍ɽͦͷ࡞‫ۀ‬͸ඇৗʹ໘౗Ͱ͋ΔɽզʑͷఏҊ͢ΔϢʔβΠϯλϑΣʔε͸໨తͷγʔϯΛૉૣ͘ɼ༰қʹ‫͕ࡧݕ‬ՄೳͰ͋ΔɽϢʔβ͕ೖྗ͢Δ΋ͷ͸ਤ 3(a) ͷΑ͏ʹɼࢹௌ͍ͨ͠ F1 Χʔ͕͍ࣸͬͯΔ੩ࢭըͱ 2 ຊͷ྘໼ҹ͚ͩͰ͋Δɽ͜ͷϢʔβΠϯλϑΣʔεʹ͓͍ͯϢʔβ͸ɼʮࢹௌ͍ͨ͠ F1 Χʔ͕‫͍ͯݟࡏݱ‬Δ F1 Χʔͷճసͨ͠όʔδϣϯͰ͋Δʯͱ͍͏ߟ͑Λ΋ͱʹ 2 ຊͷ྘໼ҹΛೖྗ͢Δɽ͜ͷߟ͑Λ΋ͱʹͯ͠ɼ3 ࣍‫ݩ‬ӈ޲͖ͷ F1 ΧʔΛਖ਼໘޲͖΁ճసͤ͞Δ͜ͱΛߟ͑ͨ৔߹ɼਖ਼໘޲͖ͷ F1 ΧʔΛ 2 ࣍‫ݩ‬ͷ੩ࢭը্Ͱ‫ݟ‬Δͱɼਤ 2(b) ͷΑ͏ʹ F1 Χʔͷલํ͸Լ෦ɼ‫ํޙ‬͸্෦ʹ഑ஔ͞ΕΔɽ͜ͷΑ͏ʹ F1 ΧʔΛճసͤͨ͞ͱ૝ఆͯ͠ 2 ຊͷ྘໼ҹͰม‫ܗ‬Λࢦఆ͢Δɽ͜͜Ͱ͸ɼϢʔβ͸ਤ 3(a) ͷΑ͏ʹ F1 ΧʔͷલํΛԼํ޲΁ɼ‫ํޙ‬Λ্ํ޲΁ͱ໼ҹΛೖྗ͢Δɽզʑ
ͷγεςϜ͸ͦͷ 2 ຊͷ྘໼ҹͰࢦఆͨ͠ม‫ྨʹܗ‬ࣅͨ͠໨తͷγʔϯ (ਤ 3(b)) Λ‫͢ࡧݕ‬Δɽ

4ΞϧΰϦζϜͷ֓ཁಈը΍੩ࢭը‫ࡧݕ‬ͷٕज़ʹ͓͍ͯɼࠓࢹௌͯ͠
͍Δγʔϯ (ਤ 2(a)) Λೖྗͱͯ͠ɼ໨తͷγʔϯ(ਤ 2(b)) Λ௚઀୳͠ग़͢͜ͱ͸ࠔ೉Ͱ͋Δɽྫ͑͹ɼSIFT ಛ௃ྔ [11] Λಈը͔Βநग़͠ɼࠓࢹௌ͠
͍ͯΔγʔϯͱ໨తͷγʔϯͷϚονϯάͷ‫ࢉܭ‬Λߦ͏ɽϚονϯάʹ F1 ΧʔΛ࢖༻ͨ͠৔߹ͷ݁Ռ͸ਤ 4 Ͱࣔ͢௨ΓͰ͋Δɽ
ӈ޲͖ͱࠨ޲͖ͷ F1 Χʔͱ͍ͬͨ֎‫͠ࣅྨ͕؍‬͍ͯΔࠨͷέʔεͰ͸ਖ਼֬ͳϚονϯά͕ଟ͘நग़
͞Ε͍ͯΔɽҰํͰɼӈ޲͖ͱਖ਼໘޲͖ͷ F1 Χʔͱ͍ͬͨӈͷέʔεͰ͸ෆਖ਼֬ͳϚονϯά͕நग़͞Ε͍ͯΔ͔ɼϚονϯάͷ਺͕গͳ͍ɽ͜͜Ͱ‫ڵ‬ຯਂ͍͜ͱʹɼਤ 4(a) ͱ (b) ͷϑϨʔϜ͸ਤ 5 Ͱࣔ͢௨Γಉ͡γʔϯʹଘࡏ͍ͯ͠Δɽ
ਤ 6(b) ͷΑ͏ͳೖྗ੩ࢭը (ਤ 6(a)) ͱ֎‫ྨ͕؍‬ࣅͨ͠ϑϨʔϜΛ୳͠ग़͠ɼͦͷϑϨʔϜ͔ΒಈըΛ‫͖ר‬໭͢͜ͱͰਤ 6(c) ͷΑ͏ͳ໨తͷγʔϯ (ਤ6(d)) Λ୳͠ग़͢͜ͱ͕Ͱ͖Δɽ‫͖ר‬໭͠Ͱਤ 5(d)੩ࢭը಺෺ମ΁ͷม‫ʹࣔࢦܗ‬ΑΔಈը‫ࡧݕ‬

ਤ 4. Ϛονϯάͷྫਤ 6. ΞϧΰϦζϜͷ֓ཁ

Visual Words Λ࢖༻ͨ͠ϚονϯάΛߦ͏ͨΊʹҎԼͷલ४උΛߦ͏ɽ
1. ‫ࡧݕ‬ର৅ͷಈըͷશϑϨʔϜ͔Β SIFT ಛ௃ྔΛநग़͢Δɽ

2. நग़ͨ͠ಛ௃ྔΛϥϯμϜʹબ୒͠ɼΫϥελϦϯάΛߦ͏ɽΫϥελϦϯάʹ͸ K-means๏Λ࢖༻͢Δɽ

3. ͦΕͧΕͷΫϥελͷத৺ͷσʔλ (VisualWords) Λࣙॻͱఆٛ͢Δɽ
4. ࣙॻΛ࢖༻͠ɼ࢒Γͷ SIFT ಛ௃ྔʹ͍ͭͯͲͷΫϥελʹ෼ྨ͞ΕΔ͔Λಛఆ͢Δɽ

ਤ 5. F1 Χʔ͕ਖ਼໘͔Βࠨ޲͖ʹͳΔಈը

͜ͷલ४උͰ‫ٻ‬Ίͨಈըͷ֤ϑϨʔϜͷΫϥελͷ
ಛఆ͕ߦΘΕͨ SIFT ಛ௃ྔ͸ɼϢʔβΠϯλϑΣʔεͷγεςϜ‫ى‬ಈ࣌ʹಡΈࠐ·ΕΔɽϢʔβΠϯλϑΣʔεͰ੩ࢭը͕ೖྗ͞Εͨ࣌ɼೖྗ੩ࢭըͱಈ
ըͷ֤ϑϨʔϜͱͷϚονϯά͸ҎԼͷྲྀΕͰߦ͏ɽͱ (a) Λؔ࿈෇͚Δํ๏ͱͯ͠ɼਤ 5 ͷ྘৭ͷ఺ͷΑ͏ͳ෺ମ্ʹ഑ஔ͞Εͨ఺Λ௥੻͢Δɽ‫ࡧݕ‬ΞϧΰϦζϜ͸ 2 εςοϓ͋Δɽ

1. ϑϨʔϜ‫ࡧݕ‬εςοϓ

1. ೖྗ੩ࢭը͔Β SIFT ಛ௃ྔΛநग़͢Δɽ

SIFT ಛ௃ྔΛ࢖༻ͨ͠ϚονϯάʹΑΓɼೖ

2. நग़ͨ͠ಛ௃ྔΛࣙॻΛ࢖༻͠ɼΫϥελͷ

ྗ੩ࢭը಺ͷ෺ମͱྨࣅͨ͠ϑϨʔϜΛ‫ࡧݕ‬͢ΔɽಛఆΛߦ͏ɽ

3. ಈը಺ϑϨʔϜ͔Βநग़͞Ε֤ͨಛ௃ྔͱΫ

2. ϑϨʔϜ௥੻εςοϓྨࣅϑϨʔϜ͔ΒૣૹΓɾ‫͖ר‬໭͠Λߦ͍ɼϢʔβͷೖྗ໼ҹͰࢦఆ͞Εͨม‫͠ࣅྨʹܗ‬ͨϑϨʔϜΛग़ྗ͢Δɽ

2 εςοϓʹ͍ͭͯ 4.1 ͱ 4.2 Ͱ‫ه‬ड़͢Δɽ
4.1

ϑϨʔϜ‫ࡧݕ‬ೖྗ੩ࢭըͱ SIFT ಛ௃ྔΛ࢖༻ͨ͠ϚονϯάΛߦͬͨ݁ՌɼϚονϯά਺͕࠷ଟͷϑϨʔϜΛྨࣅͨ͠ϑϨʔϜͱͯ͠બ୒͢Δɽͨͩ͠ɼSIFTಛ௃ྔΛͦͷ··Ϛονϯάʹ࢖༻͢Δํ๏Ͱ͸‫ܭ‬ࢉ͕͔͔࣌ؒΔɽ‫ؒ࣌ࢉܭ‬Λ‫ݮ‬Βͨ͢ΊʹɼVisualWords[15] Λ࢖༻ͨ͠ϚονϯάΛߦ͏ɽ͜ͷ‫ࢉܭ‬࣌ؒͷൺֱ͸ 5.1 Ͱ‫ه‬ड़͢Δɽ

- 75 -

ϥελͷ൪߸͕Ұக͢Δ৔߹ʹϚονϯάͱ͢ΔɽϚονϯά͸ଟ͘நग़͞ΕΔ͕ɼͦͷதʹ͸֎‫ͱ؍‬ൺֱ͢Δͱෆਖ਼֬ʹ‫͑ݟ‬Δ΋ͷ͕ଘࡏ͢ΔɽͦͷΑ͏ͳϊΠζΛ‫ݮ‬Βͨ͢ΊʹɼRANSAC[6] Λ࢖༻͢Δɽ
Visual Words Λ࢖༻͠ɼೖྗ੩ࢭըͱ֎‫ྨ͕؍‬ࣅͨ͠ϑϨʔϜΛϚονϯάΛߦͬͨ݁Ռͷྫ͕ਤ
7 Ͱ͋Δɽਤ 7 ԼͷϑϨʔϜΛ‫ؚ‬Ήಈըʹ͓͍ͯɼϚονϯά਺͕࠷ଟͰ͋ΔͷͰɼ͜ͷϑϨʔϜΛͦͷಈըͰͷྨࣅͨ͠ϑϨʔϜͱͯ͠બ୒͢Δɽͨͩ
͠ɼVisual Words Λ࢖༻ͨ͜͠ͱʹΑΓ SIFT ಛ௃ྔΛͦͷ··࢖༻ͨ͠৔߹ΑΓ΋ਫ਼౓͕௿Լ͍ͯ͠
ΔɽΑͬͯɼਓؒͷ‫ͨݟ‬໨ʹ͸ྨࣅ͍ͯ͠ͳ͍ʹ΋͔͔ΘΒͣɼϚονϯά਺͕ಈը಺Ͱ࠷ଟͷϑϨʔϜ͕ଘࡏ͢Δ͜ͱ͕͋Δɽ͜ͷ໰୊ʹରͯ͠ɼϚοWISS 2013
ද 1. ֤Ϛονϯάͷ‫( ؒ࣌ࢉܭ‬ඵ)ಛ௃ྔநग़Ϋϥελಛఆ
Ϛονϯά
߹‫ܭ‬

5

SIFT ಛ௃ྔ [12]
1.23
91.11
92.34

Visual Words
1.23
1.84
1.78
4.85

࣮‫ݧ‬

͢΂ͯͷ࣮‫ݧ‬͸ CPU Intel i7-3930k 3.20GHzɼϝϞϦ 16GB ͷύιίϯͰߦͬͨɽ༻ҙͨ͠શͯͷಈըͷେ͖͞͸ 640×360 Ͱ͋Δɽ

5.1 ‫ؒ࣌ࢉܭ‬ൺֱ
4.1 Ͱ‫ه‬ड़ͨ͠ϑϨʔϜ‫ࡧݕ‬εςοϓʹͯɼSIFT

ਤ 7. Visual Words Λ࢖༻ͨ͠Ϛονϯάͷྫνϯάͷ਺͕ଟ͍ॱ͔Βෳ਺ͷީิͷϑϨʔϜΛྨࣅͨ͠ϑϨʔϜͱͯ͠࢖༻͢Δɽ

4.2 ϑϨʔϜ௥੻
4.1 Ͱબ୒ͨ͠ྨࣅϑϨʔϜ͔Βલ‫ޙ‬ϑϨʔϜΛ୳ࡧ͠ɼϢʔβ͕໼ҹͰࢦఆͨ͠ม‫ʹܗ‬Ϛονϯά
ͨ͠ϑϨʔϜΛग़ྗ͢Δɽલ‫ޙ‬ϑϨʔϜͷ୳ࡧʹ͸
ਤ 5 ͷΑ͏ʹϑϨʔϜ্ʹ഑ஔ͞Εͨ఺Λ௥੻͢Δɽ௥੻఺Λநग़͢Δॲཧ͸༧Ίߦ͍ɼγεςϜ࣮ߦ࣌ʹ௥੻఺σʔλΛಡΈࠐΉΑ͏ʹ͢Δɽ෺ମͷ௥੻ʹ͸ particle video[13] Λ࢖༻ͨ͠ΞϧΰϦζϜͱɼ
SIFT ಛ௃ྔͷϚονϯάΛ࢖༻ͨ͠ΞϧΰϦζϜ
ͷ 2 छྨͷํ๏Λߦͬͨɽલऀ͸ਫ਼౓͸ߴ͍͕‫ࢉܭ‬͕࣌ؒඇৗʹ͔͔ΔͨΊɼ࣮‫Ͱݧ‬͸ SIFT ಛ௃ྔͷϚονϯάΛ࢖༻͢ΔɽSIFT ಛ௃ྔΛ࢖༻ͨ͠෺
ମͷ௥੻͸ଟ͘ߦΘΕ͍ͯΔ [2, 14] ͕ɼ؆ུԽ͠
ͨҎԼͷΑ͏ͳྲྀΕͰߦ͏ɽ

1. ಈը಺ͷ֤ϑϨʔϜͰ SIFT ಛ௃ྔΛநग़͢Δɽ

2. n − 1 ͱ n ϑϨʔϜɼn ͱ n + 1 ϑϨʔϜͷ
SIFT ಛ௃ྔͷϚονϯάΛͦΕͧΕ‫͢ࢉܭ‬Δɽ
3. n − 1 ͱ n + 1 ϑϨʔϜͱͷϚονϯά͕ଘࡏ͢Δ n ϑϨʔϜͷಛ௃఺Λ௥੻఺ͱ͢Δɽ
ͦͷΞϧΰϦζϜΛ࢖༻͠ɼ௥੻͸ҎԼͷΑ͏ʹߦ͏ɽ

1. 4.1 ͷϚονϯάͷ݁ՌΛ࢖༻͠ɼೖྗ໼ҹͷ࢝఺ͱରԠͨ͠ྨࣅϑϨʔϜ্ͷ఺ (ରԠ఺)Λ‫ٻ‬ΊΔɽ

2. ରԠ఺ͱۙ๣ͷ௥੻఺Λ‫ٻ‬ΊΔɽ
3. ϑϨʔϜΛҠಈͤ͞ɼೖྗ໼ҹͷऴ఺ͱ௥੻
఺͕࠷ۙࣅͷϑϨʔϜΛ‫ٻ‬ΊΔɽγεςϜ͸ɼ֤ಈըͷ࠷ۙࣅϑϨʔϜதɼ্Ґ 3ϑϨʔϜΛ‫݁ࡧݕ‬Ռͱͯ͠ग़ྗ͢Δɽ

- 76 -

ಛ௃ྔΛͦͷ··࢖༻ͯ͠ϚονϯάΛߦͬͨ৔߹
[12] ͱɼVisual Words Λ࢖༻ͨ͠ϚονϯάΛߦͬͨ৔߹ͷ‫ؒ࣌ࢉܭ‬͸ද 1 Ͱ͋Δɽͨͩ͠ɼಈըͷ
SIFT ಛ௃ྔ͸༧Ίநग़͓ͯ͠ΓɼͦΕͧΕͷϑϨʔϜ਺͸ 761 Ͱ͋Δɽ·ͨɼϊΠζΛ‫ݮ‬Βͨ͢ΊʹRANSAC[6] Λ࢖༻͍ͯ͠Δɽ
ද 1 ͷ݁Ռ͔ΒɼVisual Words Λ࢖༻ͨ͠Ϛονϯά͸ɼSIFT ಛ௃ྔΛͦͷ··࢖༻ͨ͠৔߹ΑΓɼϚονϯάΛߴ଎ʹߦ͏͜ͱ͕෼͔ͬͨɽ

5.2

ಈը‫ࡧݕ‬

զʑ͸ YouTube ্ʹ͋Δ F1 Χʔɼഅɼඈߦ‫ػ‬
ͷ 3 छྨͷ෺ମͷಈըͰγεςϜͷ࣮‫ݧ‬Λߦͬͨɽ
3 छྨͷ෺ମͷಈըΛμ΢ϯϩʔυͨ͠‫ޙ‬ɼ1 γʔϯ͝ͱʹಈըΛ෼ׂͨ͠ɽ֤෺ମ͝ͱʹ‫ࡧݕ‬ର৅͸
20 ຊͷಈըͰ͋ΔɽͦΕΒͷಈըͷશϑϨʔϜ͔
Β SIFT ಛ௃ྔΛநग़͠ɼVisual Words ϚονϯάͰ࢖༻͢ΔࣙॻͱͦΕͧΕͷ Visual Words σʔ
λɼSIFT ௥੻σʔλΛ࡞੒ͨ͠ɽ֤෺ମͷಈըʹ
͸ 20 छྨͷγʔϯ͕ଘࡏ͢Δɽ
ਤ 8 ͷ 1 ྻ໨͸੩ࢭըͱ໼ҹΛೖྗͨ͠ϢʔβΠϯλϑΣʔεͷը໘ɼӈͷ 3 ྻ͸֤ೖྗʹର͢ΔγεςϜͷ‫݁ࡧݕ‬ՌͰ͋Δɽ࣮‫ͨ͠༻࢖ʹݧ‬ಈըͷϑϨʔϜ਺ͱ‫ؒ࣌ࡧݕ‬͸ද 2 ʹࣔ͢௨ΓͰ͋Δɽ͜͜
Ͱɼಛ௃ྔͷநग़͸ 1 ຕͷೖྗ੩ࢭըʹରͯ͠ 1 ճ͚ͩߦ͑͹ྑ͍ͷͰɼ2 ճ໨Ҏ߱ͷ‫ࡧݕ‬͸நग़ͨ͠σʔλΛಡΈࠐΉΑ͏ʹ͍ͯ͠ΔͨΊɼ1 ճ໨ΑΓߴ଎ʹͳΔɽ(Ϋϥελ਺ɹ F1 Χʔ 2500ɼഅɾඈߦ‫ ػ‬500)
ਤ 8 ͷ 1 ߦ໨ͷ (a) ͸ F1 ΧʔͷಈըΛ‫ͨ͠ࡧݕ‬݁ՌͰ͋Δɽ͜ͷߦͰ͸ɼϢʔβ͕ਖ਼໘޲͖ʹҠಈ
͢Δ F1 ΧʔͷγʔϯΛ‫͠ࡧݕ‬Α͏ͱɼӈ޲͖ͷ F1
Χʔͱ 2 ຊͷ྘໼ҹΛೖྗͨ͠ɽͦΕΛ૝ఆͯ͠ɼ1ຊ໨ͷ໼ҹ͸ F1 ΧʔͷલํΛࢦఆͯ͠Լʹ޲͚ͯ
ೖྗ͢Δɽଓ͚ͯɼ2 ຊ໨ͷ໼ҹ͸ F1 Χʔͷ‫ํޙ‬੩ࢭը಺෺ମ΁ͷม‫ʹࣔࢦܗ‬ΑΔಈը‫ࡧݕ‬

ਤ 8. ‫݁ࡧݕ‬Ռ (a) ਖ਼໘޲͖ʹҠಈ͢Δ F1 Χʔͷγʔϯ (b) ࠨ޲͖ʹҠಈ͢Δ F1 Χʔͷγʔϯ (c) ӈ޲͖ʹҠಈ͢Δ
അͷγʔϯ (d) ਖ਼໘޲͖ʹҠಈ͢Δഅͷγʔϯ (e) ӈ޲͖ʹඈߦ͢Δඈߦ‫ػ‬ͷγʔϯ

ද 2. ‫ؒ࣌ࡧݕ‬ϑϨʔϜ਺ಛ௃ྔநग़ (ඵ)ಛఆ (ඵ)
௥੻ (ඵ)߹‫( ܭ‬ඵ)

F1 Χʔ
3941
7.08
3.29
0.97
11.34

അ

ඈߦ‫ػ‬

7018
7.04
2.86
2.29
12.19

3741
1.41
1.64
0.36
3.41

ਤ 9. ࠨ্΁ඈߦ͢Δඈߦ‫ػ‬Λࢦఆ্͠ʹ޲͚ͯೖྗ͢Δɽ‫݁ࡧݕ‬Ռ͸ೖྗ੩ࢭըͱϢʔβ͕ࢦఆͨ͠໼ҹʹۙࣅ্ͨ͠Ґ 3 ϑϨʔϜͰ͋Δɽ্Ґ 3 ϑϨʔϜͷதʹɼϢʔβ͕‫͠ࡧݕ‬Α͏ͱͨ͠ਖ਼໘޲͖ʹҠಈ͢Δ F1 Χʔͷγʔϯ͕
‫·ؚ‬Ε͍ͯΔɽҎ߱ͷߦͰ΋Ϣʔβ͕ࢹௌ͍ͨ͠ͱ
ࢥͬͨγʔϯ্͕Ґ 3 ϑϨʔϜͷதʹ‫·ؚ‬Ε͍ͯΔɽ
·ͨɼਤ 1 ΋ඈߦ‫݁ͨ͠ࡧݕ͍ͯͭʹػ‬ՌͰ͋Δɽ͜Ε͕զʑͷٕज़ͷ‫ݶ‬քΛ͍ࣔͯ͠ΔɽϢʔβ͸ਤ 9ͷΑ͏ͳࠨ্޲͖ͷඈߦ‫ػ‬ͷγʔϯΛൃ‫͠ݟ‬Α͏ͱ
2 ຊͷ྘໼ҹΛඳըͨ͠ɽ‫͞ࡧݕ‬Εͨ݁Ռ͸શͯͰࠨ্Λ޲͍͓ͯΓɼϢʔβͷࢦఆ͕ຬͨ͞Ε͍ͯΔɽ

- 77 -

͔͠͠ɼඈߦ‫ػ‬͸ͦͷલํͱ‫ํޙ‬Λ࣠ͱͯ͠ճస͠
͍ͯΔγʔϯ͹͔ΓͰ͋ΔɽϢʔβ͕ਤ 9 ͷΑ͏ʹඈߦ‫͕ػ‬ճస͍ͯ͠ͳ͍γʔϯΛ๬Ή৔߹Ͱ͋ͬͯ
΋ɼզʑͷγεςϜΛ࢖༻ͯ͠ɼඈߦ‫͕ػ‬ճస͍ͯ͠ΔγʔϯΛഉআ͢Δ͜ͱ͸ࠔ೉Ͱ͋Δɽ6·ͱΊຊ࿦จͰ͸ɼ੩ࢭը಺ͷ෺ମʹ 2 ຊͷ໼ҹΛඳը͢Δ͜ͱͰγʔϯͷ‫͖Ͱ͕ࡧݕ‬Δ৽͍͠ϢʔβΠϯλϑΣʔεΛఏҊͨ͠ɽ࣮‫͍͓ͯʹݧ‬ɼF1 Χʔɼഅɼඈߦ‫ ͍ͨͬͱػ‬3 छྨͷ෺ମʹ͓͍ͯ‫͖Ͱࡧݕ‬Δ͜ͱΛΛ֬ೝͨ͠ɽWISS 2013ࠓ‫ͯ͠ͱޙ‬ɼղܾ͢΂͖՝୊͕͋Δɽ·ͣɼ࣮‫ʹݧ‬͓͍ͯϢʔβ͕‫͠ࡧݕ‬Α͏ͱͨ͠γʔϯͱ͸ҧ͏ҙਤ͠ͳ͍γʔϯ͕ଘࡏͨ͠ͱ͍͏໰୊͕͋ΔɽSIFTಛ௃ྔΛͦͷ··࢖༻͠ɼParticle Video Λ࢖༻ͯ͠‫ࡧݕ‬Λߦͬͨ৔߹ [12] Ͱ͸ҙਤ͠ͳ͍γʔϯ͸͋·Γग़ͯ͜ͳ͔ͬͨɽ͜ͷΑ͏ͳਫ਼౓௿Լͷ‫ݪ‬Ҽ͸ɼ࢖༻͢ΔΞϧΰϦζϜΛมߋ͔ͨ͠ΒͰ͋Δɽ͔͠͠ͳ͕ΒɼϑϨʔϜ‫Ͱࡧݕ‬͸ 17 ഒɼϑϨʔϜ௥੻Ͱ͸ 1.5 ഒҎ্ߴ଎ʹͳͬͨͨΊɼΑΓଟ͘ͷಈըΛҎલΑΓ΋࣌ؒΛ͔͚Δ͜ͱແ͘‫ࡧݕ‬ର৅ʹ͢Δ͜ͱ͕Ͱ͖ΔɽΑΓଟ͘ͷಈըΛ࢖༻͢Δ͜ͱͰɼγʔϯͷछྨ͕૿͑ɼϢʔβͷҙਤʹ͍ۙಈը͕૿
͑Δ͜ͱʹΑΓɼҙਤ͠ͳ͍γʔϯ্͕Ґʹདྷͳ͘ͳΔͷͰ͸ͳ͍͔ͱߟ͑Δɽ࣍ʹɼ৭৘ใΛ࢖༻͍ͯ͠ͳ͍ͱ͍͏఺͕͋Δɽ
SIFT ಛ௃ྔͷϚονϯά΍௥੻ʹ͓͍ͯɼ৭৘ใ
Λ࢖༻͍ͯ͠ͳ͍ɽͦͷͨΊɼྫ͑͹ɼF1 ΧʔͷಈըΛେྔʹ༻ҙͨ͠৔߹ɼ‫ܗ‬͸ಉ͕ͩ͡৭͕ҟͳ
Δ F1 Χʔ͕‫݁ࡧݕ‬Ռͱͯ͠දࣔ͞ΕΔՄೳੑ͕͋
Δɽ͜ͷ৔߹ͷγεςϜͷରԠʹ͍ͭͯɼ৭ͷҧ͏ंΛ‫ڐ‬༰ͯ͠‫݁ࡧݕ‬ՌΛग़͢ͷ͔ɼ৭ͷҧ͍Λ‫͞ڐ‬ͣ৭৘ใΛ࢖༻͢Δํ๏Λ‫ݕ‬౼͢Δͷ͔౳Λߟ͑Δ
ඞཁ͕͋Δɽ
3 ఺໨ʹɼ‫͢ࡧݕ‬Δର৅͕߶ମͰಛ௃తͳ෦෼͕
ଘࡏ͠ͳ͍ͱ͏·͘ಇ͔ͳ͍఺͕͋ΔɽF1 Χʔ΍ඈߦ‫͍ͨͬͱػ‬৐Γ෺Ͱ͸৭΍໛༷͕ҟͳΔ͜ͱ͕͋Δ͕ɼ‫ܗ‬ঢ়ʹ͍ͭͯ͋·ΓมΘΒͳ͍ɽ·ͨɼλΠϠ΍ϩΰɼཌྷ౳ͱ͍ͬͨΑ͏ʹಛ௃తͳ෦෼͕ଘ
ࡏ͢Δɽഅ͸଍Λಈ͔͠‫ܗ‬ঢ়͕มԽ͢Δ͕ɼഅ᭏΍Ҍͱ͍ͬͨഅ۩Λ෇͚ΒΕͯ͜Ε͕ಛ௃తͳ෦෼ͱͳ͍ͬͯΔɽҰํͰɼখಈ෺΍‫ڕ‬Λ‫ࡧݕ‬ର৅ʹ࣮ͯ͠‫ݧ‬Λߦ͕ͬͨɼ͏·͘‫ػ‬ೳ͠ͳ͔ͬͨɽͦͷ‫ݪ‬Ҽ͸ɼಈը಺Ͱ‫ܗ‬ঢ়͕มԽ͠ɼಛ௃తͳ෦෼͕ଘࡏ͠
ͳ͍͔ΒͰ͋Δɽ‫ܗ‬ঢ়͕มԽ͢ΔͱɼSIFT ಛ௃ྔΛ࢖༻ͨ͠Ϛονϯά͕͏·͘‫ػ‬ೳ͠ͳ͍ɽ·ͨɼಛ௃తͳ෦෼͕ͳ͍ͱਖ਼֬ͳϚονϯά΋൑ఆ͢Δ
ͷ͕ࠔ೉Ͱ͋ΔɽͦͷΑ͏ͳ෺ମʹରͯ͠΋‫ࡧݕ‬Մೳʹ͢ΔͨΊʹ͸ɼ࢖༻͢Δಛ௃ྔʹ͍ͭͯ‫ݕ‬౼͢
Δඞཁ͕͋Δɽࢀߟจ‫ݙ‬

Video browsing by direct manipulation. In: Proc.
of CHI ʟ08. (2008) 237-246[5] J. M. Frahm, M. Pollefeys, S. Lazebnik, C. Zach,
D. Gallup, B. Clipp, R. Raguram, , C. Wu,
T. Johnson: Fast robust large-scale mappingfrom video and internet photo collections. ISPRS
Journal of Photogrammetry and Remote Sensing
65(6) (2010) 538-549[6] M. A. Fischler, R. C. Bolles: Random Sample Consensus: A Paradigm for Model Fittingwith Applications to Image Analysis and Automated Cartography. In: Comm. of the ACM
24(6) (1981) 381-395.
[7] A. Girgensohn, D. Kimber, J. Vaughan, T. Yang,
F. Shipman, T. Turner, E. Rieffel, L. Wilcox, F.
Chen, T. Dunnigan: Dots: support for effective
video surveillance. In: Proc. of ACM Multimedia.
(2007) 423-432[8] D. B. Goldman, C. Gonterman, B. Curless, D.
Salesin, S. M. Seitz: Video object annotation,navigation, and composition. In: Proc. UIST
2008. (2008) 3-12
[9] T. Karrer, M. Weiss, E. Lee, J. Borchers:
Dragon: a direct manipulation interface forframe-accurate in-scene video navigation. In:
Proc. of CHI ʟ08. (2008) 247-250[10] D. Kimber, T. Dunnigan, A. Girgensohn, F.
Shipman, T. Turner, T. Yang: Trailblazing:Video playback control by direct object manipulation. In: IEEE International Conference on
Multimedia and Expo. (2007) 1015-1018[11] D. G. Lowe: Distinctive image features fromscale-invariant keypoints. Int. J. Comput. Vision
60 (2004) 91-110[12] M. Okabe, Y. Kawate, K. Anjyo, R. Onai:
Video Retrieval based on User-Specified Appearance and Application to Animation Synthesis. In:
Proc. of MMM (2013)[13] P. Sand, S. Teller: Particle video: Long-range
motion estimation using point trajectories. In:
Proc. of CVPR ʟ06. (2006) 2195-2202[14] S. N. Sinha, J. M. Frahm, M. Pollefeys, Y. Genc:
Gpu-based video feature tracking and matching.
In: Workshop on Edge Computing Using New
Commodity Architectures (2006)[15] J. Sivic, A. Zisserman: Video google: a text retrieval approach to object matching in videos. In:
ICCV. (2003) 1470-1477[1] S. Agarwal, N. Snavely, I. Simon, S. Seitz, R.
Szeliski: Building rome in a day. In: ICCV 2009.
(2009) 72-79[2] S. Battiato, G. Gallo, G. Puglisi, and S. Scellato:
Sift features tracking for video stabilization. In
Proc. of International Conference on Image Analysis and Processing (2007) 825-830[3] R. Datta, D. Joshi, J. Li, J.Z. Wang: Image retrieval: Ideas, influences, and trends of the newage. ACM Comput. Surv. 40(2) (2008) 5:1-5:60[4] P. Dragicevic, G. Ramos, J. Bibliowitcz, D.
Nowrouzezahrai, R. Balakrishnan, K. Singh:[16] N. Snavely, S. M. Seitz, R. Szeliski: Photo
tourism: exploring photo collections in 3d. In:
ACM SIGGRAPH 2006 Papers. (2006) 835-846[17] J. Tompkin, K. Kim, J. Kautz, C. Theobalt:
Videoscapes: Exploring sparse, unstructured
video collections. In: ACM Transactions on
Graphics (Proc. of SIGGRAPH). (2012)- 78 -WISS2013ྉཧը૾ΛΞχϝʔγϣϯ͢Δ͜ͱʹΑΔັྗతͳྉཧಈըੜ੒γεςϜ
࡚ࢁ ᠳฏ

Ԭ෦ ੣

ඌ಺ ཧ‫෉ل‬ฏ໺ ኍඒ∗

֓ཁ. ຊ‫ڀݚ‬͸ɼ1 ຕͷྉཧը૾ΛΞχϝʔγϣϯ͢Δ͜ͱͰɼΑΓັྗతͳྉཧಈըΛ࡞੒͢ΔͨΊͷγεςϜΛఏҊ͢Δɽ๐΍౬‫ؾ‬ɼඈລɼ۩ࡐͷ༳ΕͳͲɼྉཧΛΑΓັྗతʹ‫ͤݟ‬Δཁૉ͸ଟʑ͋Δɽ͜
ΕΒͷཁૉ͸ಈ͖ͷதʹଟ͘‫ݱ‬ΕΔͨΊ੩ࢭըΑΓ΋ಈըͷํ͕ද‫͠ݱ‬΍͍͕͢ɼͦ͏ͨ͠ཁૉΛ͏·͘ଊ͑ͨಈըΛࡱӨ͢Δ͜ͱ͸ઐ໳ՈͰ΋ࠔ೉Ͱ͋Δɽྫ͑͹౬‫ؾ‬΍๐Λൃੜͤ͞Δʹ͸ɼ࣮ࡍʹՐΛ఺Ր͢Δͱ͍͏ํ๏͕‫͛ڍ‬ΒΕΔ͕ɼ͜͏ͨ͠ࡱӨΛߦ͏ͱྉཧͷঢ়ଶ͕ࡱӨதʹมԽͯ͠͠·͏ͨΊɼࡱӨͷλΠϛϯά͸‫ۃ‬ΊͯγϏΞͰ͋Γɼঢ়ଶͷมΘͬͯ͠·ͬͨྉཧ͸ೋ౓ͱࡱӨʹ༻͍Δ͜ͱ͕Ͱ͖ͳ͍ɽ
ͦ͜Ͱզʑ͸ɼ఺ՐͳͲͱ͍ͬͨྉཧͷঢ়ଶΛมԽͤͯ͞͠·͏ߦҝΛߦΘͣɼྉཧΛ‫ݟ‬ӫ͑Α͘ηοςΟϯά͚ͨͩ͠ͷঢ়ଶͰࡱӨ͞Εͨ੩ࢭըʹɼ͋ͱ͔Β౬‫ؾ‬΍๐ͳͲͷಈըΛ߹੒͢Δ͜ͱͰ͜ΕΛղܾ͢
Δɽ͜͏ͨ͠ಈըͷ߹੒Λߦ͏͜ͱͷͰ͖Δ‫ط‬ଘͷιϑτ΢ΣΞ͸ଘࡏ͢Δ͕ɼඇৗʹύϥϝʔλ͕ଟ͘ɼͦͷιϑτ΢ΣΞʹର͢Δઐ໳తͳ஌͕ࣝඞཁͳ͏͑ʹɼ਺ඵͷಈըͷ࡞੒ʹ΋๲େͳ࡞‫͕ؒ࣌ۀ‬ඞཁͱ
ͳΔɽͦ͜ͰຊఏҊͰ͸๐΍۩ࡐͷ༳ΕͷύϥϝʔλઃఆΛߦ͏ͨΊͷΞϧΰϦζϜΛಠࣗʹߟҊ͢Δ͜
ͱͰɼϢʔβͷΘ͔ͣͳೖྗΛ‫ʹج‬ɼ୹࣌ؒͰັྗతͳྉཧಈըͷ࡞੒ΛՄೳͱ͢ΔγεςϜΛ࣮‫ͨ͠ݱ‬ɽ

1

͸͡Ίʹ

‫ࡏݱ‬ɼྉཧళͷ WEB ϝχϡʔ΍ిࢠϝχϡʔɼγϣοϐϯάαΠτͷ঎඼Πϝʔδʹ͸੩ࢭը͕ଟ
͘࢖༻͞Ε͍ͯΔ͕ɼ͜ΕΒͷྉཧ੩ࢭըΛಈըʹஔ͖‫͑׵‬Δͱɼඒຯ͠͞ͷද‫ݱ‬ͷ෯͕͞Βʹ޿͕ΓɼίϯςϯπશମΛΑΓϦονʹ͢Δ͜ͱ͕Ͱ͖Δɽྉཧ͸ʮ‫͖׆‬ʯ͕͏·͘ද‫͞ݱ‬Ε͍ͯΔͱΑΓັྗతʹ‫͑ݟ‬Δͱ͞Ε͓ͯΓɼ৽઱ͳ໺ࡊΛణΔణɼάπάπͱ৯ࡐΛ༳Β͢๐ɼύνύνͱమ൘͔Β஄͚
ΔඈລͳͲɼྉཧͷ‫͖׆‬Λද͢ཁૉ͸਺ଟ͘ଘࡏ͢
Δ͕ɼ͜ΕΒͷଟ͘͸ಈ͖ͷதʹ‫ݱ‬ΕΔͨΊɼ੩ࢭըΑΓ΋ಈըͷํ͕ΑΓ๛͔ͳද‫͕ݱ‬ՄೳͰ͋Δɽ
͔͠͠ɼྉཧͷ‫͖׆‬Λࢥ͍௨Γʹද‫ͯ͠ݱ‬ಈըΛࡱӨ͢Δ͜ͱ͸େม೉͍͠ɽ
͜͜ͰɼྉཧࡱӨͷઐ໳Ո͕ɼࡱӨ͕ࠔ೉Ͱ͋Δ
ͱ͢ΔʮುྉཧʯΛྫʹઆ໌͢ΔɽುྉཧΛΑΓັྗతʹࡱӨ͠Α͏ͱͨ͠৔߹ɼುʹՐΛ͔͚ͯάπάπͱཱ͍ࣽͬͯΔঢ়ଶΛࡱӨ͢Δ͜ͱ͕࠷΋ҰൠతͰ͋Δ͕ɼ࣮ࡍʹುʹ఺Րͯ͠͠·͏ͱɼ೑ʹ͸Ր͕௨Γ͖ͬͯ͠·͍ࠇ͘ม৭͠ɼനࡊͳͲͷࡊͬ༿͸ҤΕ‫ݩ‬ͷ‫ܗ‬ঢ়͕ҡ࣋Ͱ͖ͣɼଟ͘ͷ۩ࡐ͸΍͕ͯεʔϓʹ௜ΜͰ͍ͬͯ͠·͏ (ਤ 1-a)ɽঢ়ଶ͕ม
Խͯ͠͠·ͬͨ۩ࡐ͸ೋ౓ͱࡱӨʹ͸࢖༻Ͱ͖ͳ͍
ͨΊɼࡱӨλΠϛϯά͸‫ۃ‬ΊͯγϏΞͰ͋Γɼઐ໳ՈͰ͢ΒັྗతͳಈըΛࡱӨ͢Δ͜ͱ͸ࠔ೉Ͱ͋Δɽ
ҰํͰɼਤ 1-b ͷΑ͏ͳ੩ࢭըͷࡱӨ͸ՄೳͰ͋Δɽ͜ͷ੩ࢭը͸ುʹྫྷ͍ͨਫΛுΓɼ۩ࡐΛ៉ྷ∗

Copyright is held by the author(s).
Shohei Sakiyama, ి‫ؾ‬௨৴େֶ, Makoto Okabe, ి‫ؾ‬௨৴େֶ/JST CREST, Rikio Onai, ి‫ؾ‬௨৴େֶ, Hiromi
Hirano, ָఱ‫ࣜג‬ձࣾ/ి‫ؾ‬௨৴େֶ- 79 -

ʹෑ͖٧ΊͯɼՐΛ͚ͭͣʹࡱӨͨ͠΋ͷͰ͋Δɽ
ՐΛ͚͍ͭͯͳ͍ͨΊɼ೑ʹ͸Ր͕௨Γ͖Δ͜ͱͳ
͘໌Δ͍৭Λอ͓ͬͯΓɼय़٠ͳͲͷࡊͬ༿͸ҤΕͣ৽઱͞Λอͪɼશͯͷ۩ࡐ͸εʔϓʹ௜Ή͜ͱͳ͘៉ྷʹฒΜͰ͍ΔɽࡱӨதʹ۩ࡐͷঢ়ଶ͕มԽ͢
Δ͜ͱ͕ͳ͍ͨΊɼΏͬ͘Γͱ࣌ؒΛ͔͚ͯߏਤΛܾΊͯࡱӨͰ͖Δ͏͑ɼԿ౓΋ࡱΓ௚͕͠ՄೳͰ͋
Δɽ͔͠͠ɼਤ 1-b ʹ͸๐΍౬‫ؾ‬ɼ۩ࡐͷ༳ΕͳͲͱ͍ͬͨཁૉ͕શ͘ଘࡏ͍ͯ͠ͳ͍ͨΊɼྉཧͷ‫׆‬͖͕‫͡ײ‬ΒΕͳ͍ɽ

ਤ 1. (a) ࣮ࡍʹುʹՐΛ఺Րͯ͠ࡱӨ͞ΕͨಈըͷҰ
෦. (b) ఺Րͤͣྫྷਫʹ۩ࡐΛฒ΂͚ͨͩͷঢ়ଶͰࡱӨ͞Εͨ੩ࢭը.

͜͜Ͱɼਤ 1-a ͷΑ͏ʹ۩ࡐͷ৽઱͞Λ͍ܽͯ͠·͏͜ͱͳ͘ɼਤ 1-b ʹɼਤ 1-a ʹ͋ͬͨΑ͏ͳ๐΍౬‫͍ͨͬͱͲͳؾ‬ཁૉΛՃ͑Δ͜ͱ͕Ͱ͖Ε͹ɼັྗతͳྉཧಈըͷ࡞੒͕ՄೳͰ͋Δɽ
ͦ͜Ͱզʑ͸ਤ 1-b ͷΑ͏ʹ‫ݟ‬ӫ͑Α͘ࡱӨ͞Ε
ͨ 1 ຕͷ੩ࢭըʹɼ͋ͱ͔Β๐΍౬‫ؾ‬ɼ۩ࡐͷ༳ΕͳͲΛ߹੒͢Δ͜ͱͰɼΑΓັྗతͳྉཧಈըΛ࡞
੒͢Δख๏ΛఏҊ͢Δɽ͜͏ͨ͠ಈը࡞੒͸ Adobe
After Effects[1] ͳͲͷ‫ط‬ଘιϑτ΢ΣΞͰ΋ՄೳͰ͋Δ͕ɼιϑτ΢ΣΞʹର͢Δઐ໳తͳ஌ࣝΛඞ

WISS 2013

ཁͱ͢Δ͏͑ʹɼΘ͔ͣ਺ඵؒͷಈըΛ࡞੒͢ΔͨΊʹ਺࣌ؒͷ࡞‫ؒ࣌ۀ‬Λཁ͢Δͱ͍͏໰୊͕͋Δɽ
ͦ͜ͰຊఏҊͰ͸ɼັྗతͳಈը࡞੒ʹ͓͍ͯಛʹද‫ࠔ͕ݱ‬೉ͱ͞ΕΔʮ๐ʯ΍ʮ۩ࡐͷ༳ΕʯΛத৺ʹɼ੩ࢭը 1 ຕͱϢʔβͷগͳ͍ೖྗΛ‫ʹج‬ɼ୹࣌ؒͰັྗతͳྉཧಈըΛੜ੒͢ΔγεςϜΛ։ൃͨ͠ɽ·ͨɼ࣮ࡍʹγεςϜΛ࢖༻ͯ͠ྉཧಈըΛ࡞੒͠ɼࣗવͰັྗతͳಈը͕࡞੒Ͱ͖Δ͜ͱΛ֬ೝͨ͠ɽ

2ؔ࿈‫ڀݚ‬

੩ࢭըΛΞχϝʔγϣϯ͢Δ‫ط‬ଘ‫ڀݚ‬͸਺ଟ͘ଘࡏ͢Δ [6, 5]ɽ͜ΕΒ͸ը૾ͷதʹೖ͍ͬͯ͘Α͏ͳ
3 ࣍‫ݩ‬తͳࢹ఺ͷมߋ΍ΩϟϥΫλΞχϝʔγϣϯʹศརͰ͋Δ͕ɼྉཧಈըͷ࡞੒ʹ͸ରԠ͍ͯ͠ͳ
͍ɽChuang Β͸੩ࢭըʹ֬཰తͳಈ͖Λ༩͑ɼਫ໘ͷ༳Β͗౳Λѻͬͨ [4]. ਫ໘ͷ༳Β͗͸๐ͷද‫ݱ‬ʹࣅ͍ͯΔ͕ɼզʑ͕ߦ͏๐ͷ഑ஔͰ͸ɼ๐ྖҬಉ࢜ͷؔ܎΍Ϣʔβ͕ೖྗͨ͠৘ใʹΑͬͯͦΕͧΕͷྖҬʹύϥϝʔλͷҟͳͬͨ๐Λ഑ஔ͢ΔͨΊɼ͜ͷख๏Λ࢖༻͢Δ͜ͱ͸Ͱ͖ͳ͍ɽԬ෦Β͸੩ࢭըʹྲྀମͷྲྀΕΔ޲͖Λεέον͢Δ͜ͱͰྲྀମΞχϝʔγϣϯͷੜ੒Λߦͬͨ [10]ɽ͜ͷख๏͸ɼྲྀମಈըͷ഑ஔ͕Ϣʔβͷεέονٕज़ʹґଘͯ͠͠·͏ͨΊɼࠓճѻ͏Α͏ͳྉཧ੩ࢭըΛೖྗͨ͠ͱ
͜ΖͰ࣭ͷߴ͍ΞχϝʔγϣϯΛಘΒΕΔͱ͍͏อূ͕ͳ͍ɽ·ͨɼϏσΦςΫενϟ߹੒ͷ‫ڀݚ‬΋ଟ͘ଘࡏ͢
Δ [13, 12] ͕ɼ͜ΕΒͰ߹੒ͨ͠ಈըͷ‫ͨݟ‬໨΍ಈ͖Λฤू͢Δͷ͸೉͍͠ɽBhat Β͸खॻ͖εέονʹ‫ྲྀ͍ͯͮج‬ମϏσΦΛฤूͨ͠ [3]ɽ‫ͨݟ‬໨ͷฤू΋Մೳ͕ͩը૾Ξχϝʔγϣϯ͸ѻ͍ͬͯͳ͍ɽ
͞Βʹɼຊ‫Ͱڀݚ‬͸۩ࡐը૾ΛͦͷछྨʹԠͯࣗ͡ಈͰ࿪·ͤΔ͜ͱͰɼ۩ࡐͷ༳ΕΛද‫͢ݱ‬Δɽը૾Λม‫ͤ͞ܗ‬Δ‫ڀݚ‬͸Ҏલ͔Βଟ͘ߦΘΕ͓ͯΓ [2]ɼ‫ेޒ‬ཛྷΒ͸͜ΕΛΠϯλϥΫςΟϒʹૢ࡞͢Δ͜ͱΛ࣮‫[ ͨ͠ݱ‬7]ɽͦͷ‫ޙ‬΋͜ͷख๏ͷ֦ுͳͲ͕ଟ
͘ߦΘΕ͍ͯΔ [11, 8]ɽ͔͠͠ɼຊ‫ڀݚ‬ͷΑ͏ʹྉཧը૾ʹಛԽ͠ɼ۩ࡐͷछྨʹԠͯࣗ͡ಈͰը૾Λ࿪·ͤɼ۩ࡐͷ༳ΕΛද‫͢ݱ‬Δͱ͍ͬͨख๏͸ଘࡏ͠ͳ͍ɽͦ͜Ͱຊ‫Ͱڀݚ‬͸Ϣʔβͷগͳ͍ೖྗΛ‫ʹج‬ɼ۩ࡐͷ༳Β͠Ξχϝʔγϣϯͷੜ੒ɼ֤๐ྖҬʹର͢
Δ๐ͷ഑ஔ‫ͼٴ‬ύϥϝʔλઃఆ౳Λߦ͏ͨΊͷΞϧΰϦζϜΛಠࣗʹߟҊ͢Δ͜ͱͰɼ୹࣌ؒͰྉཧಈ
ըΛ࡞੒͢Δ͜ͱ͕Ͱ͖ΔγεςϜΛ໨ࢦ͢ɽ

3γεςϜ֓ཁ

ຊख๏ʹ͓͚Δಈը࡞੒ͷయ‫ܕ‬తͳྲྀΕʹ͍ͭͯड़΂ΔɽϢʔβ͸·ͣϚ΢εΛ࢖༻ͯ͠ೖྗ੩ࢭը
(ਤ 2-a) ʹ؆୯ͳεέονΛߦ͍ɼ๐Λ഑ஔ͢Δྖ

- 80 -

Ҭ (๐ྖҬ) ͱ৯ࡐྖҬͷࢦఆΛߦ͏ (ਤ 2-b)ɽಉ͡
εέονͷํ๏Λ༻͍ͯɼਤ 2-b Ͱࢦఆͨ͠৯ࡐྖ
ҬΛɼ۩ࡐ͝ͱʹ෼ׂ͢Δ (ਤ 2-c). ࣍ʹϢʔβ͸ਤ
2-c Ͱ෼ׂͨ͠۩ࡐͦΕͧΕʹ͍ͭͯɼʮม‫ܗ‬ύλʔϯʯͱʮ‫ܗ‬ঢ়ʯͱ͍͏΋ͷࢦఆ͢Δ (ਤ 2-d)ɽม‫ܗ‬ύλʔϯʹ͸ʮม‫ܗ‬ɼඇม‫ܗ‬ʯͷ 2 ͭͷબ୒ࢶ͕ଘ
ࡏ͠ɼͦͷ۩ࡐ͕य़٠ͷΑ͏ʹॊΒ͔͘‫͕ܗ‬มΘΓ΍͍͢΋ͷͰ͋Ε͹ʮม‫ܗ‬ʯɼେࠜͷΑ͏ʹ‫ܗ͘ݻ‬͕มΘΓʹ͍͘΋ͷͰ͋Ε͹ʮඇม‫ܗ‬ʯΛબ୒͢Δɽ‫ܗ‬ঢ়ʹ͸ʮฏ໘ɼ‫ܗٿ‬ɼ๮ঢ়ɼ༿ྨɼ໙ྨʯͱ͍͏ 5ͭͷબ୒ࢶ͕ଘࡏ͠ɼͦͷ۩ࡐʹରͯ͠Ϣʔβ͕࠷΋ద੾Ͱ͋Δͱࢥ͏΋ͷΛ 1 ͭબ୒͢Δɽ͋ͱ͸”
߹੒”ϘλϯΛԡ͚ͩ͢Ͱ, Ϣʔβ͕ࢦఆͨ͠ྖҬ΍۩ࡐͷ৘ใΛ‫ʹج‬ɼγεςϜ͕ࣗಈͰ๐ͷҐஔ΍αΠζɼ଎͞ɼ۩ࡐͷ༳Β͠۩߹ͳͲΛܾఆ͠ɼಈըΛ߹੒͢Δ (ਤ 2-e)ɽ͜ͷͱ͖ɼಈըʹ෇༩͢Δ౬‫ؾ‬΍Իͷࢦఆ΋ߦ͏͜ͱ͕Ͱ͖Δɽ

ਤ 2. ಈը࡞੒खॱ.

4ϢʔβΠϯλϑΣʔε͜͜Ͱ͸࡞੒ͨ͠ϢʔβΠϯλϑΣʔεʹ͍ͭͯ
ड़΂Δɽ

4.1

๐ྖҬͱ৯ࡐ (۩ࡐ) ྖҬͷࢦఆϢʔβ͸؆୯ͳεέονͰೖྗ੩ࢭըʹର͠ɼ๐ྖҬͱ৯ࡐྖҬΛࢦఆΛߦ͏ (ਤ 2-a,b)ɽ͜ͷࢦఆʹ͸ɼεέονϕʔεͷྖҬ෼ׂ‫ث‬Λ༻͍Δ [14]ɽ
๐ྖҬΛࢦఆ͢Δ৔߹ɼϢʔβ͸ࠨΫϦοΫͰ๐ྖҬΛࢦఆ͠ɼӈΫϦοΫͰುͷԑ΍എ‫ܠ‬ɼ৯ࡐ෦෼
ͳͲͱ͍ͬͨ๐ྖҬҎ֎ͷྖҬΛࢦఆ͢Δ (ਤ 3-a)ɽ
͜ͷࢦఆ͸਺গͳ͍ετϩʔΫͰ࣮‫ݱ‬ՄೳͰ͋ΔͨΊɼ͜ͷૢ࡞͸਺ඵͰ‫ྃ͢׬‬Δ͜ͱ͕Ͱ͖Δɽಉ༷ͷࢦఆΛ৯ࡐྖҬʹ͍ͭͯ΋ߦ͏ (ਤ 3-b)ɽ
·ͨɼುྉཧͷΑ͏ͳࣽࠐΈྉཧͷ৔߹͸ɼ๐ͷൃੜͱ‫ʹڞ‬ʮ۩ࡐ͕༳Εʯ͕ੜ͍ͯͨ͡ํ͕ΑΓࣗવͰ͋Δɽͦ͏͍ͬͨྉཧͷ৔߹ɼਤ 3-b Ͱࢦఆͨ͠৯ࡐྖҬΛɼ͞Βʹ۩ࡐ͝ͱʹࡉ͔͘෼ׂ͢Δ (ਤ3-c)ɽ͜ͷૢ࡞΋ 1 ͭͷ۩ࡐʹର͓͓ͯ͠Αͦ 2 ετϩʔΫͷΈͰࢦఆΛߦ͏͜ͱ͕Ͱ͖ΔͨΊɼશͯͷ۩ࡐʹର͜͠ͷࢦఆΛߦͬͯ΋ɼ਺ඵ͔Β਺෼ͱ͍ͬͨ୹࣌ؒͰ‫ྃ͢׬‬Δ͜ͱ͕Ͱ͖Δɽ

ྉཧը૾ΛΞχϝʔγϣϯ͢Δ͜ͱʹΑΔັྗతͳྉཧಈըੜ੒γεςϜ۩ࡐͷ༳Ε͕ଘࡏ͠ͳ͍ྉཧ (ྫ͑͹ɼమ൘ͷ্Ͱδϡʔδϡʔͱম͚Δϋϯόʔάʹ͸۩ࡐͷ༳Ε͸ଘࡏ͠ͳ͍) ʹ͍ͭͯ͸ਤ 3-c ͷૢ࡞͸ඞཁͳ͍ɽ

ਤ 5. ๐ૉࡐಈը. (a) ਫ (b) ে༉ (c) ιʔε.

ਤ 3. (a) ๐ྖҬͷࢦఆ. ԫ৭ͷετϩʔΫ͕๐ྖҬ, ੨৭ͷετϩʔΫ͕๐ྖҬҎ֎. (b) ৯ࡐྖҬͷࢦఆ. (c) ۩ࡐͷ෼ׂ.

4.2

4.5

۩ࡐ৘ใͷೖྗ

Ϣʔβ͸෼ׂͨ͠۩ࡐ (ਤ 2-c) ͦΕͧΕʹରͯ͠ɼʮม‫ܗ‬ύλʔϯʯͱʮ‫ܗ‬ঢ়ʯͷࢦఆΛߦ͏ɽม‫ܗ‬ύλʔϯͱ͸ɼ۩ࡐͷ‫͕ܗ‬มΘΓ΍͍͔͢൱͔Λࣔ͢΋ͷͰ͋Γɼ
ʮม‫ܗ‬ɼඇม‫ܗ‬ʯͱ͍͏ 2 ͭͷબ୒ࢶ͕
ଘࡏ͢Δɽय़٠ͷΑ͏ʹͻΒͻΒͱॊΒ͔͘‫͕ܗ‬มΘΓ΍͍͢΋ͷ͸ʮม‫ܗ‬ʯɼେࠜͷΑ͏ʹ‫͕ܗ͘ݻ‬มΘΓʹ͍͘΋ͷ͸ʮඇม‫ܗ‬ʯΛϢʔβ͕બ୒͢Δɽ‫ܗ‬ঢ়ʹ͍ͭͯ͸ɼʮฏ໘ɼ‫ܗٿ‬ɼ๮ঢ়ɼ༿ྨɼ໙ྨʯ
ͱ͍͏ 5 ͭͷબ୒ࢶ͕ଘࡏ͠ (ਤ 4)ɼ͜ͷத͔Βɼͦͷ۩ࡐʹରͯ͠࠷΋ద੾Ͱ͋Δͱࢥ͏΋ͷΛ 1 ͭ
બ୒͢Δɽ͜ΕΒͷ৘ใ͸ɼ۩ࡐͷ༳Β͠ΞχϝʔγϣϯΛੜ੒͢Δࡍʹ࢖༻͢Δɽ

ਤ 4. ۩ࡐʹର͢Δʮ‫ܗ‬ঢ়ʯͷ෼ྨྫ.

4.3

ͱιʔεͰ͸ɼ೪ੑʹ͍ͭͯେ͖ͳ͕ࠩ͋ΔͨΊɼ๐ͷ๲ΒΈํʹҧ͍͕ΈΒΕΔɽϢʔβ͸ࣗ෼ͷ࡞੒͍ͨ͠ಈըͷ‫ײ‬৮ʹΑΓ߹ͬͨ๐ૉࡐಈըΛબ୒
͢Δ͜ͱ͕Ͱ͖Δɽ౬‫ؾ‬΍Իͷબ୒

࡞੒͢Δಈըʹ౬‫ؾ‬΍ԻΛՃ͑Δ͜ͱ͕Ͱ͖Δɽ͜ͷࢦఆ͸”߹੒”ϘλϯΛԡ͢લʹߦ͏ɽ౬‫ؾ‬ΛՃ͑Δ৔߹͸ɼ͍͔ͭ͘༻ҙ͞Εͨ౬‫ؾ‬ͷૉࡐಈըͷத͔Β޷͖ͳ΋ͷΛબ୒͠ɼΠϯλϑΣʔεʹදࣔ͞Εͨྉཧը૾ΛΫϦοΫ͢Δ͜ͱͰɼ౬‫ؾ‬ΛషΓ͚ͭΔҐஔΛܾఆ͢ΔɽԻΛ௥Ճ͢Δ৔߹͸ɼ༻ҙ͞Ε͍͔ͨͭ͘ͷԻૉࡐͷத͔Β޷͖ͳ΋ͷΛબ୒
͢Δ͚ͩͰΑ͍ɽϢʔβ͸Ր‫ݩ‬ͷҐஔΛࢦఆ͢Δ͜ͱ͕Ͱ͖ΔɽՐ‫ͱݩ‬͸ը૾தͰ࠷΋‫͘ڧ‬Ճ೤͞Ε͍ͯΔ఺Ͱ͋Γɼྫ͑͹ುྉཧʹ͓͍ͯɼುͷத৺ΛՐ‫ͯ͠ͱݩ‬ઃఆͨ͠ͱ͢Δͱɼುͷத৺෦ʹ࠷΋೤͕ՃΘ͍ͬͯΔ
͔ͷΑ͏ʹುͷத৺෦ʹ͸ܹ͍͠๐͕ൃੜ͠ɼುͷԑͷํͰ͸த৺෦ͱൺֱͯ͠Ժ΍͔ͳ๐͕ൃੜ͢Δɽ͜ͷՐ‫ݩ‬ͷҐஔͷࢦఆ͸ɼྉཧಈըࢹௌऀͷࢹઢͷ༠ಋʹͭͳ͕Δͱߟ͍͑ͯΔɽҰൠʹɼਓ͸ಈ͖ͷେ͖ͳ෦෼ʹண໨͢ΔɽຊγεςϜͰ͸Ր‫͕ͦݩ‬ͷ෦෼ʹ֘౰͢ΔͨΊɼಈըࢹௌऀʹಛʹ஫໨ͯ͠΄͍͠෦෼ΛՐ‫ʹݩ‬ઃఆ͢Δ͜ͱͰɼࢹௌऀͷࢹઢΛͦ͜΁༠ಋ͢Δ͜ͱ͕Ͱ͖Δɽ

4.6

๐ૉࡐಈըͷબ୒ಈըͷੜ੒͜͜·Ͱͷ৘ใΛೖྗ͢Ε͹ɼ͋ͱ͸”߹੒”ϘλϯΛԡ͚ͩ͢Ͱྉཧಈը͕ੜ੒͞ΕΔɽϢʔβ͸๐ͷҐஔ΍೪ੑɼ۩ࡐͷ༳Β͠ํͳͲɼࡉ͔ͳύϥϝʔλઃఆΛҰ੾ߦ͏ඞཁ͕ͳ͍ɽ‫ࢉܭ‬͸਺ेඵͰऴྃ
͠ɼྉཧಈը͕ग़ྗ͞ΕΔɽϢʔβ͸ग़དྷ্͕ͬͨ
ྉཧಈըΛ‫ͯݟ‬ɼ๐ͷঢ়ଶ΍۩ࡐͷ༳ΕํͳͲʹؔͯ͠‫ʹؾ‬ೖΒͳ͍఺͕͋Ε͹ม‫ܗ‬ύλʔϯ΍‫ܗ‬ঢ়ͱ͍ͬͨ৘ใΛมߋͯ͠ɼྉཧಈըΛमਖ਼͢Δ͜ͱ͕
Ͱ͖Δɽಈը࡞੒ʹඞཁͳ৘ใͷೖྗͷ΄ͱΜͲ (ྖҬ෼ׂҎ֎) ͸ϫϯΫϦοΫͰߦ͏͜ͱ͕Ͱ͖Δͨ
Ίɼಈը࡞੒͸͢΂ͯ߹ΘͤͯΘ͔ͣ਺෼Ͱ‫ྃ͢׬‬Δ͜ͱ͕Ͱ͖Δɽɹ

5ΞϧΰϦζϜ

͜͜Ͱ͸ɼ๐ͷ഑ஔ΍۩ࡐͷ༳Β͠ํͷܾఆɼ๐ͷϨϯμϦϯάɼԻ΍౬‫ؾ‬ͷ௥ՃͰ༻͍ͨΞϧΰϦζϜʹ͍ͭͯड़΂Δɽ

5.1
4.4

Ր‫ݩ‬Ґஔͷࢦఆ๐ͷ഑ஔΞϧΰϦζϜ

༻ҙͨ͠๐σʔλϕʔεʹ͸ਫɼে༉ɼιʔεͳͲෳ਺ͷӷମͦΕͧΕʹ͍ͭͯɼେ͖͞΍଎౓ͷҟͳΔ΋ͷ͕ଟ਺‫·ؚ‬Ε͍ͯΔ (ਤ 5)ɽຊγεςϜͰ͸͜ͷσʔλϕʔε͔Βద੾ͳ๐Λબͼग़͠ɼϢʔྉཧಈըͷ߹੒ʹ࢖༻͢Δ๐ૉࡐಈըΛมߋ͢Δ
͜ͱ͕Ͱ͖Δɽ༻ҙͨ͠๐ૉࡐಈըʹ͸ɼਫ΍ιʔεɼে༉ͳͲෳ਺ͷӷମͷ๐͕ଘࡏ͢Δɽྫ͑͹ਫ- 81 -WISS 2013β͕ਤ 2-b Ͱࢦఆͨ͠๐ྖҬʹରͯ͠഑ஔ͢Δɽ͜ͷ഑ஔΛߦ͏ͨΊʹಠࣗͷΞϧΰϦζϜΛߟҊͨ͠(ද 1)ɽ

2 Ͱ͸ɼͦͷΑ͏ͳ๐ʹରͯ͠खॱ 1 Ͱܾఆͨ͠଎
౓Λ 0.7 ഒ͠ɼ͜ΕΛॏΈ෇͚ͱ͢Δɽ
5.2

ುͷΑ͏ͳࣽࠐΈྉཧͰ͸ɼάπάπͱൃੜ͢Δ
๐ͱ‫͕ࡐ۩ʹڞ‬༳ΕΔɽຊγεςϜͰ͸͜ͷ༳ΕͷΞχϝʔγϣϯΛɼϢʔβ͕ਤ 2-d Ͱࢦఆͨ͠ʮม
‫ܗ‬ύλʔϯʯͱʮ‫ܗ‬ঢ়ʯʹԠͯࣗ͡ಈੜ੒͢Δɽ༳Β͠ํʹ͍ͭͯ͸ 2 ύλʔϯ༻ҙͨ͠ɽ1. ۩ࡐը૾Λม‫ͯ͠ܗ‬࿪·ͤΔ͜ͱͰ༳ΕΛද‫͢ݱ‬Δύλʔϯͱ, 2. ۩ࡐը૾ͷ࠲ඪΛҠಈͤ͞Δ͜ͱͰ༳ΕΛද‫͢ݱ‬ΔύλʔϯͰ͋Δɽਤ 2-d ʹ͓͍ͯɼϢʔβ͕ʮม‫ܗ‬ʯΛબ୒͍ͨ͠۩ࡐʹ͍ͭͯ͸ύλʔϯ
1 ͷ༳Β͠ํɼ
ʮඇม‫ܗ‬ʯΛબ୒ͨ͠۩ࡐʹ͍ͭͯ͸ύλʔϯ 2 ͷ༳Β͠ํΛదԠ͢Δɽ

ද 1. ๐ͷ഑ஔΞϧΰϦζϜ.

खॱ 1‫ج‬ຊ഑ஔ
खॱ 2ॏΈ෇͚ର৅ͷ๐ྖҬ഑ஔ͢Δ๐Ґஔ޿͞ ଎౓ αΠζՐ‫ۙ෇ݩ‬
‫ڱ‬
‫ۃ‬஗
খ
޿
஗
খ
Ր‫ݩ‬ԕ͘
‫ڱ‬
஗
‫ۃ‬খ
޿
଎
େ
৯ࡐྖҬͱͷ‫ڥ‬໨‫ͼٴ‬৯ࡐྖҬؒͷ๐ͷ଎౓ΛΑΓ஗͘͜ͷ๐഑ஔΞϧΰϦζϜ͸զʑ͕࣮ࡍʹುྉཧ΍మ൘ྉཧͳͲͱ͍ͬͨ๐ͷൃੜ͠΍͍͢ྉཧͷө૾Λෳ਺‫͠࡯؍‬ɼखಈͰྉཧಈըͷࢼ࡞ΛԿ౓΋ࢼΈͨ݁Ռఆٛͨ͠΋ͷͰ͋Δɽखॱ 1 Ͱ͸֤๐ྖҬʹ
഑ஔ͢Δ๐ͷ଎౓ɼαΠζɼ࠲ඪΛܾఆ͠ɼखॱ 2Ͱ͸खॱ 1 Ͱ഑ஔͨ͠๐ʹରͯ͠ॏΈ෇͚Λߦ͏ɽզʑ͕ௐࠪͨ͠ͱ͜Ζɼൃੜ͢Δ๐ͷಛ௃ͷҧ͍ʹ͸ɼͦͷ๐ͷྖҬͷՐ‫͔ݩ‬Β‫ͱ཭ڑ‬ɼͦͷ๐ͷྖҬͷ޿͕͞େ͖ؔ͘܎͍ͯ͠Δɽ‫ج‬ຊతʹՐ‫ۙʹݩ‬͍෦෼Ͱ͸ɼൃੜ͔Βফࣦ·Ͱͷ଎౓͕஗͘ɼॎԣ
ͷαΠζ͕খ͍͞๐͕ൃੜ͠΍͍͢ɽՐ‫͍ۙʹݩ‬෦෼ͷதͰ΋ಛʹɼଞͷྖҬͱൺֱͯ͠ྖҬͷ޿͕͞‫͍ڱ‬৔ॴͰ͸଎౓͕ΑΓ஗͍๐͕ൃੜ͢Δ܏޲͕‫ݟ‬ΒΕΔɽҰํɼՐ‫͔ݩ‬Β཭Εͨ෦෼Ͱ͸ྖҬͷ޿͞ʹΑͬͯൃੜ͢Δ๐ͷಛ௃͕େ͖͘ҟͳΔɽ‫ྖ͍ڱ‬ҬͰ͸଎౓͕஗͘ɼ‫ͭ׌‬Ր‫ൃͰۙ෇ݩ‬ੜ͢Δ๐ͳͲ
ͱൺֱͯ͠ΑΓαΠζͷখ͍͞๐͕ൃੜ͢Δͷʹର͠ɼൺֱత޿͍ྖҬͰ͸଎౓͕଎͘αΠζͷେ͖ͳ๐͕ൃੜ͢Δɽखॱ 1 ͸͜ΕΒͷಛ௃Λߟྀ͍ͯ͠Δɽ
खॱ 1 ΛຊγεςϜʹ͓͍࣮ͯ‫͢ݱ‬ΔͨΊʹɼ֤๐ྖҬͷϐΫηϧ਺ͱɼ֤๐ྖҬͷॏ৺͔ΒՐ‫·ݩ‬Ͱͷ‫཭ڑ‬Λ࢖༻ͯ͠ɼ֤๐ྖҬʹ഑ஔ͢Δ๐ͷαΠζɼ଎౓ͷύϥϝʔλΛܾఆ͢Δɽ๐ྖҬ i ͷϐΫηϧ਺Λ a(i), ॏ৺͔ΒՐ‫Ͱ·ݩ‬ͷ‫཭ڑ‬Λ d(i) ͱͨ͠ͱ͖ɼͦͷྖҬʹ഑ஔ͢Δ๐ͷαΠζ S(i), ଎౓V (i) ͸ͦΕͧΕ࣍ͷΑ͏ʹఆٛ͞ΕΔɽ

S(i) ∝ a(i) · d(i)a(i)
V (i) ∝d(i)۩ࡐͷ༳Β͠Ξχϝʔγϣϯੜ੒ύλʔϯ 1: ը૾ม‫ʹܗ‬ΑΔ༳Εͷද‫ݱ‬य़٠΍੨༿ͷΑ͏ͳ༿ྨ͕༳ΕΔͱ͖ɼ۩ࡐશମ
͕Ұ༷ʹ༳ΕΔͷͰ͸ͳ͘ɼ‫ܪ͍ݻ‬ͷ͋Δࠜຊ͸͋·Γಈ͔ͣʹɼॊΒ͔͍༿ઌ͚͕ͩ༳Ε͍ͯͨํ͕
ΑΓࣗવʹ‫͑ݟ‬ΔɽຊఏҊͰ͸ɼϦδοτม‫[ ܗ‬11]Λ༻͍ͯɼय़٠ͷࠜຊͷΑ͏ʹ‫ܗ‬ͷมΘΓʹ͍͘෦෼Λ‫ݻ‬ఆͨ͠͏͑Ͱɼ༿ઌͷΑ͏ʹ‫ܗ‬ͷมΘΓ΍͍͢ՕॴΛ࿪·ͤΔΑ͏ʹม‫͢ܗ‬Δ͜ͱͰɼ۩ࡐͷ༳ΕΛද‫͢ݱ‬Δɽ͜͜ͰɼϦδοτม‫ܗ‬Λߦ͏ࡍɼ‫ݻ‬
ఆ͢Δ఺Λ‫ݻ‬ఆ੍‫఺ޚ‬ɼ࿪·ͤΔ఺Λৼಈ੍‫ͱ఺ޚ‬͍͏ɽ֤۩ࡐʹର͢Δ‫ݻ‬ఆ੍‫ৼͱ఺ޚ‬ಈ੍‫఺ޚ‬ͷܾఆʹ͸ɼϢʔβ͕ਤ 2-d ʹͯࢦఆͨ͠ʮ‫ܗ‬ঢ়ʯͷ৘ใΛ࢖༻͢Δɽզʑ͸ɼ༻ҙͨ͠ 5 छྨͷ‫ܗ‬ঢ়ʹରͯ͠ɼ‫ݻ‬ఆ੍‫ৼͱ఺ޚ‬ಈ੍‫఺ޚ‬ΛͦΕͧΕͲͷΑ͏ʹઃఆ͢Δ͔ʹ͍ͭͯఆΊͨ (ਤ 6)ɽ

ਤ 6. ͦΕͧΕͷ‫ܗ‬ঢ়ʹର͢Δ‫ݻ‬ఆ੍‫( ఺ޚ‬தൈ͖ԁ:੺)ͱৼಈ੍‫( ఺ޚ‬ృΓͭͿ͠ԁ:ԫ৭) ͷҐஔ.

Ϣʔβ͕ೖྗͨ͠ʮ‫ܗ‬ঢ়ʯ৘ใͷΈΛ࢖༻ͯ͠ɼ
γεςϜ͕ࣗಈͰਤ 6 ͷΑ͏ʹ੍‫఺ޚ‬Λઃఆ͢Δʹ
͸ɼ۩ࡐը૾ͷ܏͖Λߟྀ͠ͳ͚Ε͹ͳΒͳ͍ɽྫ͑͹ਤ 6 ͷʮฏ໘ʯͷྫʹ͋Δ‫ڇ‬೑͸ɼԣ࣠ʹରͯ͠ਫฏͰ͸ͳ͘ɼࠨԼ͔Βӈ্ʹ޲͔ͬͯࣼΊʹԣͨΘ͍ͬͯΔͨΊɼ͜ͷ܏͖ʹԠ੍ͯ͡‫఺ޚ‬ͷ࠲ඪΛܾఆ͠ͳ͚Ε͹ɼม‫͕ܗ‬ෆࣗવͳ΋ͷʹͳͬͯ͠·͏ɽͦ͜Ͱɼຊख๏Ͱ͸ओ੒෼෼ੳ [9] ʹΑͬͯ͜ͷ܏͖Λਪఆͨ͠͏͑Ͱɼ੍‫఺ޚ‬ͷ࠲ඪΛܾఆ͢Δ (ਤ 7)ɽܾఆ͞Εͨৼಈ੍‫఺ޚ‬͸্Լࠨӈϥϯμ

(1)
(2)

͜͜Ͱɼ๐ྖҬ i ʹରͯ͠ɼαΠζ S(i) ͷ๐ΛάϦουঢ়ʹฒ΂Δɽ͜ΕʹΑΓͦΕͧΕͷ๐ͷ࠲ඪ͕‫·ٻ‬Δɽ͞Βʹɼ৯ࡐͱͷ‫ڥ‬໨ʹଘࡏ͢Δ๐΍ෳ਺ͷ৯ࡐྖҬͷؒʹ‫·ڬ‬Εͯଘࡏ͢Δ๐͸ɼͦͷपғͷ๐ͱൺֱͯ͠଎౓͕஗͘ͳΔ܏޲͕‫ݟ‬ΒΕΔͨΊɼखॱ- 82 -

ྉཧը૾ΛΞχϝʔγϣϯ͢Δ͜ͱʹΑΔັྗతͳྉཧಈըੜ੒γεςϜ6Ϝʹಈ͔͢͜ͱͰ۩ࡐ͕༳Ε͍ͯΔΑ͏ͳΞχϝʔγϣϯΛੜ੒͢Δɽ

ຊγεςϜΛ༻͍ͯ 4 ͭͷྉཧಈըΛ࡞੒ͨ͠(ਤ 9)ɽྉཧಈը aɼb ʹ࢖༻ͨ͠๐ૉࡐಈը͸ਤ5-aɼྉཧಈը cɼd ʹ࢖༻ͨ͠๐ૉࡐಈը͸ਤ 5-c
Ͱ͋Δɽਤ 7. ओ੒෼෼ੳΛར༻ͨ͠۩ࡐͷ܏͖ਪఆʹΑΔ੍‫ޚ‬఺࠲ඪͷܾఆ.

ਤ 9. ࣮‫ͨ͠༻࢖ʹݧ‬੩ࢭըͱಈը࡞੒ʹཁͨ࣌ؒ͠.

ύλʔϯ 2: ࠲ඪҠಈʹΑΔ༳Εͷද‫ݱ‬ܲ೑΍Χοτ͞ΕͨେࠜͷΑ͏ͳ‫ݻ‬Ίͷ৯ࡐ͕༳
ΕΔͱ͖͸ɼύλʔϯ 1 ͷΑ͏ʹ۩ࡐͷҰ෦͕༳ΕΔΑΓ΋ɼ۩ࡐશମ͕Ұ༷ʹ༳Εͨํ͕ΑΓࣗવʹ‫͑ݟ‬Δɽͦ͜ͰɼͦͷΑ͏ͳ۩ࡐʹؔͯ͠͸۩ࡐը૾શମΛ্ԼϥϯμϜʹ࠲ඪҠಈ͠༳ΕΛද‫͢ݱ‬Δɽ

5.3

ϨϯμϦϯά

࡞੒ͨ͠ྉཧಈը a-d ʹ͍ͭͯɼಈըશମ΍۩ࡐͷ༳ΕํͳͲͷࣗવ͞Λ֬ೝ͢ΔͨΊʹϢʔβςετΛߦͬͨɽϢʔβςετʹΑͬͯ֬ೝͨ͠ͷ͸
Q1-Q4 ͷ 4 ߲໨Ͱ͋Δɽ

Q1 ྉཧಈը͸੩ࢭըΑΓ΋ඒຯͦ͠͏ʹ‫͔ͨ͑ݟ‬.
Q2 ྉཧಈը͸શମతʹ‫ࣗͯݟ‬વͰ͔͋ͬͨ.
Q3 ๐͸ࣗવͰ͔͋ͬͨ.

๐ૉࡐಈըͱೖྗ੩ࢭըͷ๐ྖҬͷ৭͕ҟͳ͍ͬͯͯ΋๐͕ࣗવʹ‫͑ݟ‬ΔΑ͏ʹɼ๐ૉࡐಈըͷ๐ͷಈ͖͚ͩΛऔΓग़ͯ͠๐ྖҬʹ߹੒͢Δɽ͜Ε͸ਤ
8 ͷΑ͏ʹ HSL ৭ۭؒͷً౓ (Lightness) νϟϯωϧͷಈ͖ͷΈΛ༻͍Δ͜ͱͰ࣮‫ݱ‬ՄೳͰ͋Δɽͨͩ͜͠ͷͱ͖ɼೖྗ੩ࢭըͷ๐ྖҬʹଘࡏͨ͠Τοδ͕໨ཱͬͯ͠·Θͳ͍Α͏ɼ๐ྖҬʹରͯ͠ϒϥʔΛ͔͚ͨ͏͑Ͱ๐Λ߹੒͢Δɽ

Q4 ۩ࡐͷ༳Ε͸ࣗવͰ͔͋ͬͨ.
4 ͭͷྉཧಈը (ਤ 9 a-d) ʹର͠ɼQ1-Q4 ͦΕͧΕʹ͍ͭͯɼֶੜ 7 ਓʹ 5 ஈ֊ධՁΛߦͬͯ΋Βͬͨ (5:࠷ߴධՁ, 1:࠷௿ධՁ)ɽ
Ϣʔβςετͷ݁ՌΛਤ 10 ʹࣔͨ͠ɽͳ͓ɼྉ
ཧಈը d ʹؔͯ͠͸ө૾தʹ۩ࡐͷ༳Ε͕‫·ؚ‬Ε͍ͯͳ͍ͨΊɼQ4 ΁ͷճ౴͸ଘࡏ͠ͳ͍ɽ

ਤ 10. Ϣʔβςετͷ݁Ռ. ৭๮͸ฏ‫఺ۉ‬ɼ‫ࠩޡ‬๮͸ඪ४ภࠩɽ

ਤ 8. ً౓ͷ༳Β͗Λ෇༩͢ΔΞϧΰϦζϜ.

5.4

݁Ռͱߟ࡯

౬‫ͱؾ‬Իͷ߹੒Ϣʔβςετͷ݁ՌɼγεςϜͰ࡞੒ͨ͠ྉཧಈ
ը a-d ͢΂ͯʹ͓͍ͯɼ࡞੒ʹ࢖༻ͨ͠੩ࢭըΑΓ΋ඒຯͦ͠͏ʹ‫͑ݟ‬Δͱͷ݁Ռ͕ಘΒΕͨ (ਤ 10Q1)ɽྉཧಈը d Ҏ֎͸ඪ४ภࠩ΋খ͘͞ɼྉཧ੩
ࢭըΛγεςϜʹΑͬͯΑΓඒຯͦ͠͏ͳಈըʹ͢
Δ͜ͱ͕Ͱ͖ͨ͜ͱʹ͸ɼඃ‫ऀݧ‬ͷ΄΅શһ͕ಉҙͨ͠ͱ͍͑Δɽಈըશମͷࣗવ͞ɼ๐ͷࣗવ͞ɼ۩ࡐͷ༳Εͷࣗવ͞ͳͲΛ૯߹తʹ‫ͯݟ‬ɼ࠷΋ධՁ͕ߴ͔ͬͨͷ͸ྉཧಈը b Ͱ͋ͬͨɽྉཧಈը b ʹ࢖༻ͨ͠๐ૉࡐ
ಈը͸ਤ 5-a Ͱ͋Δ͕ɼ‫ݩ‬ը૾ͷ੺͍৭͕߹੒ͨ͠

౬‫ؾ‬͸๐΍۩ࡐͷ༳Εͱҧ͍ɼࡉ͔͍ύϥϝʔλͷઃఆΛ͠ͳͯ͘΋ɼ౬‫ؾ‬ͷૉࡐಈըΛ഑ஔ͢Δͩ
͚ͰɼಈըʹೃછΜͩద੾ͳ౬‫͑ݟʹؾ‬Δ৔߹͕΄ͱΜͲͰ͋ΔɽͦͷͨΊɼຊγεςϜͰ͸Ϣʔβ͕ࢦఆͨ͠Ґஔʹ౬‫ؾ‬ͷૉࡐಈըΛషΓ͚ͭΔ͚ͩͰ౬‫ؾ‬ͷ߹੒Λ‫ྃ͢׬‬ΔɽԻʹؔͯ͠΋ɼྉཧͷԻ͸δϡʔδϡʔ΍ύνύνɼάπάπͱ͍ͬͨന৭ੑ
ͷߴ͍΋ͷ͕΄ͱΜͲͰ͋ΔͨΊɼԻͱө૾ͷಉ‫ظ‬Λߟ͑Δඞཁ͸ͳ͘ɼϢʔβ͕બ୒ͨ͠ԻΛಈըʹ෇༩͢Δ͚ͩͰ߹੒Λ‫ྃ͢׬‬Δɽ

- 83 -WISS 2013๐ʹ͏·͘൓ө͞Ε͓ͯΓɼҧ࿨‫ײ‬Λ΄ͱΜͲ‫͡ײ‬ͤ͞ͳ͔ͬͨɽ۩ࡐͷ༳Εʹؔͯ͠΋ɼʮ๮ঢ়ʯͱࢦ
ఆͨ͠ωΪͳͲ͕ඇৗʹࣗવʹ༳Ε͓ͯΓɼଞͷ݁Ռͱൺֱͯ͠ධՁ͕ߴ͔ͬͨɽҰํɼ࠷΋௿͍ධՁͱͳͬͨͷ͸ྉཧಈը d Ͱ͋ͬͨɽྉཧಈը d ͸๐ͷ഑ஔ΋ಈըશମͱͯ͠΋ଟগෆࣗવͰ͋Δͱ͍͏ධՁΛड͚ͨ (ਤ 10 d-Q2, Q3)ɽྉཧಈը d ʹର͢Δඃ‫ऀݧ‬ͷίϝϯτʹ͸ʮ๐͕΅΍͚ͯ‫͑ݟ‬Δʯ
ͱ͍͏ҙ‫͕ݟ‬ଟ͔ͬͨɽ͜Ε͸ϨϯμϦϯά࣌ɼೖྗ੩ࢭըͷ๐ྖҬʹϒϥʔΛ͔͚͔ͯΒ๐ͷ߹੒Λߦ͍ͬͯΔ͜ͱ͕େ͖͘Ө‫͑ߟͱͨ͠ڹ‬ΒΕΔɽೖ
ྗ੩ࢭըͷ๐ྖҬͷ৭ͷ͕ܹ͍ࠩ͠ͱ͖΍ɼࢦఆͨ͠๐ྖҬ͕େ͖͍৔߹͸͜͏ͨ݁͠ՌʹͳΓ΍͍͢ɽྉཧಈը a, b, c ͷείΞΛ‫ݟ‬ΔͱɼͲΕ΋ಉ͡Α͏ͳ‫ܗ‬Λ͍ͯ͠Δɽ๐ͷࣗવ͞ (Q3) ͷείΞͷ
ߴ͕͞ɼ۩ࡐͷ༳Ε (Q4) ͷείΞͷ௿͞ʹҾͬுΒΕͨ݁Ռɼಈըશମͱͯ͠ͷࣗવ͞ (Q2) ͷείΞ͕Լ͕͍ͬͯΔͱ͍͏ߏਤ͕‫ͯݟ‬औΕΔͨΊɼ۩ࡐͷ༳Ε͕ࠓ‫ޙ‬վળ͞ΕΕ͹ɼಈըશମͱͯ͠ͷࣗવ͞΋޲্͢Δ͜ͱ͕‫ظ‬଴͞ΕΔɽ

7·ͱΊͱࠓ‫ޙ‬ͷ՝୊ຊ‫Ͱڀݚ‬͸ɼϢʔβͷগͳ͍ೖྗΛ‫Ͱؒ࣌୹ʹج‬ΑΓັྗతͳྉཧಈըΛ࡞੒͢ΔγεςϜΛఏҊ͠ɼϢʔβςετʹΑͬͯɼͦͷ༗༻ੑΛࣔͨ͠ɽ͜͜
ͰϢʔβςετʹ࢖༻ͨ͠੩ࢭը (ਤ 9 b, c) ʹ஫໨͍ͨ͠ɽ͜ΕΒͷ੩ࢭըʹ͸͋Β͔͡Ίʮྉཧը૾
ʹ౬‫ؾ‬Λ߹੒͢Δʯͱ͍͏Ճ޻͕ࢪ͞Ε͍ͯͨɽྉ
ཧը૾ʹ౬‫ؾ‬Λ߹੒͢Δͷ͸ɼྉཧΛΑΓඒຯ͘͠‫ͤݟ‬Δํ๏ͱͯ͠ϝδϟʔͳ΋ͷͰ͋Γɼ‫ࡏݱ‬ଟ͘ͷྉཧళͰ࢖༻͞Ε͍ͯΔ੩ࢭը͸͜ͷΑ͏ʹ౬‫ؾ‬͕߹੒͞Ε͍ͯΔ͕ɼͦ͏͍ͬͨՃ޻Λࢪ͢ΑΓ΋(͋Δ͍͸ࢪ্ͨ͠Ͱ) ຊγεςϜʹΑͬͯͦͷ੩ࢭըΛಈըʹͨ͠ํ͕ɼྉཧΛ͞Βʹඒຯͦ͠͏ʹ‫ݟ‬ͤΔ͜ͱ͕Ͱ͖ΔՄೳੑ͕ߴ͍͜ͱΛϢʔβςετͷ݁Ռ͸͍ࣔͯ͠Δ (ਤ 10 c, d-Q1)ɽͭ·Γɼ‫ࡏݱ‬ͷྉཧళͷϝχϡʔͳͲ͕ຊγεςϜʹΑΓಈըʹஔ͖‫׵‬ΘΕ͹ɼྉཧͷඒຯ͠͞ͷද‫ݱ‬͸ͦͷ෯Λ޿͛Δ͜ͱʹͭͳ͕Δͱߟ͑ΒΕΔɽࠓ‫ޙ‬ͷ՝୊ͱͯ͠͸ɼ۩ࡐͷ༳Β͠ΞϧΰϦζϜ
ͷվળͳͲ͕‫͛ڍ‬ΒΕΔɽ‫ݱ‬ঢ়ͱͯ͠ɼ۩ࡐͷ༳Εʹ͓͚Δए‫ׯ‬ͷෆࣗવ͕͞ಈըશମͱͯ͠ͷࣗવ͞Λଛͳ͍ͬͯΔͨΊɼࠓ‫ࡐ۩ޙ‬ͷ༳Ε͕վળ͞ΕΔ
͜ͱͰɼ͍·ͱಉ͡࿑ྗͰɼΑΓັྗతͳಈըͷ࡞੒͕ՄೳʹͳΔͱߟ͍͑ͯΔɽ͞Βʹɼࠓ‫ޙ‬͸ϢʔβΠϯλϑΣʔεʹ΋վྑΛՃ͑ɼγεςϜʹΑͬͯࣗಈੜ੒͞ΕͨಈըΛϢʔβ͕ΑΓࣗ෼ͷ‫ʹ֮ײ‬͋ͬͨಈըΛ௚‫ײ‬తʹඍௐ੔Ͱ͖ΔΑ͏ʹ͍ͨ͠ͱ
ߟ͍͑ͯΔɽ‫ࡏݱ‬ϨϯμϦϯάʹ਺ेඵͷ࣌ؒΛཁ͍ͯ͠Δ͕ཧ࿦తʹ͸ 2ɼ3 ඵఔ౓ͰՄೳͰ͋ΔͨΊɼϢʔβͷεέονΛॠ࣌ʹ݁Ռʹ൓ө͢ΔͳͲɼ
ΑΓΠϯλϥΫςΟϒͳγεςϜʹ͍͖͍ͯͨ͠ɽ

- 84 -

ࢀߟจ‫ݙ‬[1] Adobe After Effects. http://www.adobe.com/
jp/products/aftereffects.html.
[2] T. Beier and S. Neely. Feature-based image
metamorphosis. In ACM SIGGRAPH Computer Graphics, Vol. 26, pp. 35–42. ACM, 1992.
[3] K. S. Bhat, S. M. Seitz, J. K. Hodgins, and P. K.
Khosla. Flow-based video synthesis and editing. In ACM Transactions on Graphics (TOG),
Vol. 23, pp. 360–363. ACM, 2004.
[4] Y.-Y. Chuang, D. B. Goldman, K. C. Zheng,
B. Curless, D. H. Salesin, and R. Szeliski. Animating pictures with stochastic motion textures.
In ACM Transactions on Graphics (TOG),
Vol. 24, pp. 853–860. ACM, 2005.
[5] A. Hornung, E. Dekkers, and L. Kobbelt. Character animation from 2D pictures and 3D motion data. ACM Transactions on Graphics(TOG), 26(1):1, 2007.
[6] Y. Horry, K.-I. Anjyo, and K. Arai. Tour into
the picture: using a spidery mesh interface tomake animation from a single image. In Proceedings of the 24th annual conference on Computer graphics and interactive techniques, pp.
225–232. ACM Press/Addison-Wesley Publishing Co., 1997.
[7] T. Igarashi, T. Moscovich, and J. F. Hughes.
As-rigid-as-possible shape manipulation. In
ACM Transactions on Graphics (TOG), Vol. 24,
pp. 1134–1141. ACM, 2005.
[8] A. Jacobson, I. Baran, J. Popovic, andO. Sorkine. Bounded biharmonic weights forreal-time deformation. ACM Trans. Graph.,30(4):78, 2011.
[9] I. Jolliffe. Principal component analysis. Wiley
Online Library, 2005.
[10] M. Okabe, K. Anjyo, T. Igarashi, and H.-P. Seidel. Animating pictures of fluid using video examples. In Computer Graphics Forum, Vol. 28,
pp. 677–686. Wiley Online Library, 2009.
[11] S. Schaefer, T. McPhail, and J. Warren. Image deformation using moving least squares. In
ACM Transactions on Graphics (TOG), Vol. 25,
pp. 533–540. ACM, 2006.
[12] A. Schödl, R. Szeliski, D. H. Salesin, andI. Essa. Video textures. In Proceedings of the27th annual conference on Computer graphics
and interactive techniques, pp. 489–498. ACM
Press/Addison-Wesley Publishing Co., 2000.
[13] L.-Y. Wei and M. Levoy. Fast texture synthesis using tree-structured vector quantization. In
Proceedings of the 27th annual conference on
Computer graphics and interactive techniques,pp. 479–488. ACM Press/Addison-Wesley Publishing Co., 2000.
[14] ਗ਼໺ୡ໵, ྛ‫޺و‬, ඌ಺ཧ‫෉ل‬, ࡾᑍਖ਼༟, ৿ਖ਼໻.
վྑྖҬ֦ு๏ʹΑΔߴ଎ը૾੾ൈ͖ख๏ͷఏҊͱධՁ. ৘ใॲཧֶձ࿦จࢽ, 12(50):3233–3249,
2009.

WISS2013

SyncBlink: ಉ‫ʹܹࢗظ‬ΑΔφϏήʔγϣϯํࣜͷఏҊͱධՁ
ࢤຎ ॣհ

ҁ௩ ༞ೋ

ࣉా ౒

௩ຊ ণ඙∗

֓ཁ. ۙ೥ɼεϚʔτϑΥϯͷΞϓϦέʔγϣϯ΍ HMD (Head Mounted Display) ͳͲΛ༻͍༷ͨʑͳ
φϏήʔγϣϯγεςϜ͕։ൃɼ࢖༻͞Ε͍ͯΔɽϢʔβΛ༠ಋ͢Δ৘ใΛఏࣔ͢ΔγεςϜʹ͓͍ͯ՝୊
ͱͳΔͷ͸ɼఏࣔ৘ใͱ‫ੈ࣮ݱ‬քͱͷϚονϯάͰ͋Δɽྫ͑͹ɼը໘্ͷ஍ਤʹਐΉ΂͖ϧʔτ΍‫͕ۂ‬Δ
΂͖ަࠩ఺͕໌ࣔ͞Ε͍ͯͯ΋ɼͦΕΒ͕໨ͷલͷͲͷಓɼͲͷަࠩ఺ʹରԠ͢Δ͔Θ͔Βͳ͚Ε͹Ϣʔβ͸໎͏͜ͱʹͳΔɽͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼύʔιφϧσόΠεͱ‫ڥ؀‬ଆ͕࿈‫͠ܞ‬ɼಉ‫ܹࢗͨ͠ظ‬ΛϢʔβʹ
ఏࣔ͢Δ͜ͱͰφϏήʔγϣϯΛߦ͏ํࣜ SyncBlink ΛఏҊ͢Δɽ‫ڥ؀‬ଆͷ֤Ҋ಺දࣔͱϢʔβଆͷσόΠε͕ಉ‫ܹࢗͯ͠ظ‬Λൃ͢Δ͜ͱʹΑΓɼͲͷҊ಺ද͕ࣔ໨తͷ΋ͷͰ͋Δ͔Λ༰қʹࣝผͰ͖Δɽ·ͨɼෳ਺ͷϢʔβʹಉ͡ɼ·ͨ͸ҟͳͬͨҊ಺Λಉ࣌ʹఏࣔ͢Δ͜ͱ΋༰қͰ͋Γɼਓͷଟ͍‫Ͱڥ؀‬΋ར༻Ͱ͖Δɽຊ࿦จͰ͸ɼϢʔβ΁ͷܹࢗͱͯ͠ࢹ֮ɼௌ֮ɼ৮ܹ֮ࢗΛఏࣔ͢ΔϓϩτλΠϓσόΠεΛͦΕͧΕ࣮૷ͨ͠ɽධՁ݁Ռ͔ΒɼఏҊํ͕ࣜφϏήʔγϣϯख๏ͱͯ͠༗ޮͰ͋Δ͜ͱΛ֬ೝͨ͠ɽ

1

͸͡Ίʹ

ۙ೥ɼΧʔφϏήʔγϣϯ΍εϚʔτϑΥϯ্ͷาߦऀ޲͚φϏήʔγϣϯͳͲɼ༷ʑͳ৔໘ͰφϏήʔγϣϯγεςϜ͕࢖༻͞Ε͍ͯΔɽ͜ͷΑ͏ͳಓҊ಺Λఏࣔ͢ΔγεςϜʹ͓͍ͯେ͖ͳ໰୊ͱͳ
Δͷ͸ɼҊ಺৘ใͱϢʔβͷ໨ͷલͷ‫ੈ࣮ݱ‬քͱͷϚονϯάͰ͋Δɽྫ͑͹ɼը໘্ͷ஍ਤʹਐΉ΂͖ϧʔτ΍‫͕ۂ‬Δ΂͖ަࠩ఺͕໌ࣔ͞Ε͍ͯͯ΋ɼͦΕΒ͕໨ͷલͷͲͷಓɼͲͷަࠩ఺ʹରԠ͢Δ͔ʹࣗ৴͕΋ͯͳ͚Ε͹Ϣʔβ͸໎͏͜ͱʹͳΔɽ·ͨɼGPS Λ༻͍ͨϢʔβͷ‫ࡏݱ‬Ґஔͷ֬ೝ͸ɼ࣮ࡍͷҐஔͱͣΕͨҐஔΛࣔ͢͜ͱ͕͋ͬͨΓɼి೾ͷಧ͔ͳ͍஍ԼͰ͸ར༻Ͱ͖ͳ͍ɽ
Ұํɼ‫ੈ࣮ݱ‬քʹઃஔ͞Ε͍ͯΔҊ಺൘ͳͲͷ‫؀‬‫ڥ‬ଆͷφϏήʔγϣϯઃඋ͸ɼద੾ʹઃஔ͞Ε͍ͯΕ͹ରԠؔ܎ͷΘ͔Γ΍͍͢Ҋ಺ͱͳΓ͏Δɽ͔͠͠ɼ͜ͷҊ಺͸Ұൠతʹ༷ʑͳ໨తΛ΋ͭෆಛఆଟ
਺ͷਓʑʹରͯ͠ෳ਺ͷҊ಺৘ใ͕ۙ઀ͯ͠ఏࣔ͞
ΕΔͨΊɼ͋ΔϢʔβͷͨΊͷҊ಺͕ͲΕͰ͋Δ͔
Λ‫͚ͭݟ‬ग़͢ͷ͕೉͍͠ɽҰछྨͷҊ಺͔͠ͳ͍৔
߹Ͱ΋ɼͦΕʹ‫͘෇͕ؾ‬ͷ͕ࠔ೉ͳ৔߹΋͋Δɽ͜
ΕΒ͸ɼ࣮֬ʹϢʔβࣗ਎ͷͨΊʹఏࣔ͞ΕΔύʔιφϧσόΠε্ͰͷҊ಺ͱ͸ରরతͰ͋Δɽ
ͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼύʔιφϧσόΠεͱ‫ڥ؀‬ଆ͕࿈‫͠ܞ‬ɼಉ‫ܹࢗͨ͠ظ‬ΛϢʔβʹఏࣔ͢Δ͢Δ͜ͱʹΑΓɼ͜ΕΒͷܽ఺Λղফͨ͠φϏήʔγϣϯ
ํࣜ SyncBlink ΛఏҊ͢Δɽ͜ͷํࣜ͸Ϣʔβʹ࠷௿‫ݶ‬ͷܹࢗΛఏࣔͰ͖Ε͹Α͘ɼ·ͨύʔιφϧ∗

Copyright is held by the author(s).
Shunsuke Shima and Masahiko Tsukamoto, ਆ‫ށ‬େֶେֶӃ޻ֶ‫ڀݚ‬Պ, Yuji Ayatsuka, ‫ࣜג‬ձࣾి௨ࠃࡍ৘
ใαʔϏε, Tsutomu Terada, ਆ‫ށ‬େֶେֶӃ޻ֶ‫ڀݚ‬
Պ/Պֶٕज़ৼ‫͚͕͖͞ߏػڵ‬- 85 -

σόΠεଆ͸ࢹ֮తͳܹ͚ࢗͩͰͳ͘ௌ֮΍৮֮ͷܹࢗ΋‫͖Ͱ༻׆‬ΔͨΊɼγϯϓϧͰԠ༻ൣғ͕޿͍ɽҎ߱ɼ2 ষͰؔ࿈‫͍ͯͭʹڀݚ‬ड़΂ɼ3 ষͰ͸γεςϜઃ‫͍ͯͭʹܭ‬ड़΂Δɽ4 ষͰධՁ࣮‫ݧ‬Λߦ͍ɼ࠷‫ ʹޙ‬5 ষͰຊ࿦จΛ·ͱΊΔɽ

2ؔ࿈‫ڀݚ‬‫ڥ؀‬ଆͱಉ‫ͨ͠ظ‬ύʔιφϧσόΠεΛ༻͍ͨφϏήʔγϣϯγεςϜ͸͜Ε·Ͱʹ΋‫͞ڀݚ‬Ε͍ͯ
Δɽᖒ໺ΒʹΑΔ AR (Augmented Reality) Λ༻͍ͨΧʔφϏήʔγϣϯγεςϜ [1] Ͱ͸ɼंࡌΧϝϥ͔Βͷө૾Λ༻͍ͯಓ࿏୺Λநग़͠ɼ3 ࣍‫ ݩ‬CG
Λੜ੒࣮ͯࣸ͠ը૾ͱϚονϯά͍ͤͯ͞ΔɽߴాΒʹΑΔ΢ΣΞϥϒϧ AR γεςϜ [2] ͸ɼGPS ͱδϟΠϩηϯαʹΑΓϢʔβͷҐஔͱ޲͖Λೝࣝ͠ɼϢʔβ͕޲͍͍ͯΔํ޲ʹ͋ΔϨετϥϯͷ໊લ΍ϝχϡʔͳͲͷ৘ใΛఏࣔ͢Δɽ·ͨɼAR Λ༻͍ͨΧʔφϏήʔγϣϯ͸࣮༻Խ΋͞Ε͍ͯΔʢPioneerαΠόʔφϏ [3]ɼMapFan eye[4] ౳ʣ͕ɼԞߦ͖
ํ޲΋‫ؚ‬Ί࣮ͨ‫ͱܠ‬ఏࣔ৘ใͷϦΞϧλΠϜͷදࣔҐஔ߹ΘͤΛߴਫ਼౓ʹߦ͏ͷ͸ (ಛʹ࣮‫ܠ‬Λͦͷ··‫ͤݟ‬Δޫֶγʔεϧʔ‫ܕ‬ͷ৔߹) ೉͍͠ɽԾʹ‫׬‬ᘳͳҐஔ߹Θͤͱද͕ࣔͰ͖ͨͱͯ͠΋ɼਓؒͷԞߦ͖ํ޲ͷ஌֮ͷਫ਼౓͕‫ݶ‬ΒΕΔͷͰɼඞͣ͠΋ͦΕ͕‫ݟ‬΍͍͢ɼ൑Γ΍͍͢දࣔʹͳΔͱ͸‫ݶ‬Βͳ͍ɽ·ͨɼࢹք্ͷ޿͍ൣғΛ઎ΊΔ৘ใΛఏࣔ͢Δͷ͸҆શੑͷ໘Ͱͷ‫ݒ‬೦͕ੜ͡Δɽ
σόΠε͕ϢʔβʹܹࢗΛ༩͑Δ͜ͱͰϢʔβΛҊ಺͢Δํࣜ΋‫͞ڀݚ‬Ε͍ͯΔɽ௩ాΒʹΑΔ
Active Belt[5] ͸ɼ8 ํ޲ʹৼಈϞʔλΛ͚ͭͨϕϧτΛ༻͍ͯɼৼಈͤ͞ΔৼಈϞʔλͷҐஔͰ໨త஍ͷํ޲Λఏࣔ͠ɼৼಈͷ‫Ͱ͞ڧ‬໨త஍ͱͷ‫཭ڑ‬Λఏࣔ͢Δɽ͜ͷଞɼਫ໺ΒʹΑΔ৮֮φϏήʔγϣ

WISS 2013ϯ૷ஔ [6] Ͱ͸ɼ྆ࣖཪ෇ۙʹ૷ணͨ͠ፏฏ‫ܕ‬ภਊৼಈϞʔλʹΑΓ৮‫ʹ֮ײ‬ϑΝϯτϜηϯηʔγϣϯΛੜ‫͠ى‬ɼҐஔ৘ใͷ఻ୡΛࢼΈ͍ͯΔɽ
‫ڥ؀‬ଆͱύʔιφϧσόΠεΛ࿈‫Ͱڀݚͨͤ͞ܞ‬͸ɼদ‫ݪ‬ΒʹΑΔࢹ֮ো֐ऀ޲͚ର࿩‫ܕ‬৘ใఏ‫ڙ‬γεςϜ [7] ͕͋Δɽ͜ͷγεςϜͰ͸఺ࣈϒϩοΫʹຒΊࠐ·ΕͨҐஔ৘ใΛɼϢʔβ͕ઌ୺ʹΞϯςφͷ͍ͭͨ৛ͰಡΈࠐΈɼ‫ܞ‬ଳ୺຤૷ஔʹ఻ૹ͢Δ
͜ͱʹΑΓ‫ࡏݱ‬஍Λ஌Δ͜ͱ͕Ͱ͖Δɽ

3

SyncBlinkຊষͰ͸ɼఏҊํࣜ SyncBlink ͷ‫ج‬ຊతͳΞΠσΟΞΛઆ໌ͯ͠γεςϜͷཁ‫༷࢓ٻ‬Λ໌֬ʹͨ͠‫ޙ‬ɼσόΠεͷϓϩτλΠϓΛ঺հ͢Δɽ
ਤ 1. Ҋ಺൘ͱσόΠεͷಉ‫ظ‬ͷྫ

3.1 ‫ج‬ຊΞΠσΟΞ1 ষͰड़΂ͨΑ͏ʹɼ‫ڥ؀‬ଆͷҊ಺৘ใ͸ɼϢʔβ͕Ҋ಺৘ใͷଘࡏΛ஌͍֮ͯ͠Δ৔߹͸ͲΕ͕ඞཁͳ৘ใͰ͋Δ͔Λ൑ผͰ͖Δඞཁ͕͋Δɽ·ͨɼͦ΋ͦ΋Ҋ಺৘ใ͕Ͳ͜ʹ͋Δͷ͔ΛϢʔβ͕஌͍֮ͯ͠ͳ͍৔߹΋Ҋ಺৘ใͷଘࡏ͕Ϣʔβʹࣗવʹ఻ΘΕ͹Θ͔Γ΍͍͢Ҋ಺ͱͳΔɽ͕ͨͬͯ͠ྫ͑
͹Ҋ಺൘ͷඞཁͳ෦෼ΛޫΒͤɼ఺໓ͤ͞ΔͳͲͷํ๏Λ༻͍ͯɼϢʔβ͕ඞཁͱ͢ΔҊ಺͚ͩΛ໨ཱͨͤΕ͹͜ΕΒͷ໨త͸ୡ੒͞ΕΔɽҰํɼ͜ͷํ๏Ͱ͸ෳ਺ϢʔβʹରԠͰ͖ͣɼଟ͘ͷਓ͕༷ʑͳ
λΠϛϯάͰར༻͢ΔҊ಺৘ใఏࣔʹ͸޲͔ͳ͍ɽ
ͦ͜Ͱɼʮࣗ෼ʹ޲͚ͯͷ৘ใͰ͋Δ͜ͱʯΛɼ࣮֬ʹϢʔβʹ఻͑ΔͨΊʹɼϢʔβͷύʔιφϧσό
ΠεΛ‫͢༻׆‬Δɽ
චऀΒ͸Ҏલʮը໘্ʹෳ਺ͷࣸਅ͕λΠϧ্ʹදࣔ͞Ε͓ͯΓɼͦΕΒ͕ϥϯμϜʹߋ৽͞ΕΔ৔߹ɼ‫ۮ‬વಉ͡λΠϛϯάͰߋ৽͞Εͨ෦෼͸ؔ࿈͕
͋ΔΑ͏ʹ‫͡ײ‬ΒΕΔʯͱ͍͏஌‫ݟ‬Λಘ͍ͯΔ [8]ɽ͜ΕΛԠ༻͢ΔͱɼύʔιφϧσόΠε্ͰɼͦͷϢʔβ͕ඞཁͱ͢ΔҊ಺൘ͷ఺໓ͱಉ‫఺ͨ͠ظ‬໓Λఏࣔ͢Ε͹ɼඞཁͳ৘ใΛϢʔβʹೝࣝͤ͞ΒΕΔͱ
͍͑Δɽ·ͨɼ఺໓ʹΑΔࢹ֮తͳܹ͚ࢗͩͰͳ͘ɼ
ಉ‫ͯ͠ظ‬໐ΔԻ΍ৼಈʹΑΔ৮ܹ֮ࢗ΋ಉ͡Α͏ʹར༻Ͱ͖Δͱߟ͑ΒΕΔɽ͜ͷɼʮ‫ڥ؀‬ଆͷҊ಺ͷඞཁͳ෦෼ͷ఺໓ͱɼύʔιφϧσόΠε্Ͱͷಉ‫ظ‬ܹͨࢗ͠ʯʹΑΔφϏήʔγϣϯํࣜΛ SyncBlinkͱ‫Ϳݺ‬ɽ͜ͷํࣜ͸ɼਤ 1 ͷΑ͏ʹ‫ڥ؀‬ଆ͕ 1 ͭͰಉ࣌ʹෳ਺ͷϢʔβʹಉ͡·ͨ͸ҟͳΔҊ಺Λߦ͏(Ұରଟ) ͜ͱ΋ɼ‫ڥ؀‬ଆ͕ෳ਺Ͱෳ਺ͷϢʔβʹಉ͡·ͨ͸ҟͳΔҊ಺Λಉ࣌ʹߦ͏ (ଟରଟ) ͜ͱ΋ՄೳͰ͋Δɽ

3.2

ϓϩτλΠϓͷઃ‫૷࣮ͱܭ‬ఏҊํࣜΛ༻͍ͯৗ࣌ࣗવͳҊ಺Λߦ͏ͨΊʹɼ૷ண͢ΔσόΠε͸अຐʹͳΓʹ͍͘΋ͷͰ͋Δඞ
ཁ͕͋Δɽ·ͨɼఏҊํࣜ͸‫ڥ؀‬ଆσόΠεͱϢʔ- 86 -

ਤ 2. γεςϜߏ੒βσόΠε͕ਖ਼֬ʹಉ‫͢ظ‬Δඞཁ͕͋Δɽ͜ΕΒͷཁ݅Λߟྀͨ͠γεςϜߏ੒Λਤ 2 ʹࣔ͢ɽ͜ͷਤͷΑ͏ʹɼ‫ڥ؀‬ଆ͕௚઀Ϣʔβଆʹಉ‫ظ‬৴߸ΛૹΔ৔߹ͱɼ؅ཧαʔό͕‫ڥ؀‬ଆͱϢʔβଆ྆ํʹ৴߸ΛૹΔ৔߹͕ߟ͑ΒΕΔɽ·ͨɼਤ 3 ʹ࡞੒ͨ͠ɼ
ΠϠϗϯɼLED ɼৼಈϞʔλΛͦΕͧΕ༻͍ͨσόΠεͷϓϩτλΠϓͱɼͦΕΒΛ૷ண༷ͨ͠ࢠΛࣔ͢ɽΠϠϗϯΛ༻͍ͨσόΠεͰ͸‫ڥ؀‬ଆͱͷಉ‫ظ‬ͷλΠϛϯάͰϏʔϓԻ͕໐ΔɽLED Λ༻͍ͨσόΠε͸‫ڸ؟‬Λ͔͚ϔΞόϯυͰ಄ʹ૷ண͠ɼ‫؀‬‫ڥ‬ଆͱͷಉ‫ظ‬ͷλΠϛϯάͰ LED ͕఺౮͢ΔɽৼಈϞʔλΛ༻͍ͨσόΠε͸ϦετόϯυͰखटʹ૷ண͠ɼ‫ڥ؀‬ଆͱͷಉ‫ظ‬ͷλΠϛϯάͰৼಈϞʔλ͕ৼಈ͢ΔɽΠϠϗϯΛ༻͍ͨσόΠε͸ arduinonanoɼLED ͱৼಈϞʔλͷσόΠε͸ arduino fioͰ੍‫͠ޚ‬ɼXBee Ͱແઢ௨৴Λߦ͍ͬͯΔɽ‫ڥ؀‬ଆ͕఺໓ͷ։࢝࣌ʹɼແઢ௨৴Ͱ఺໓ͷִؒʢ਺஋৘
ใʣΛૹ৴͢ΔͱɼσόΠεଆ͸ड৴ִͨؒ͠ͷܹࢗΛఏࣔ͢Δɽෳ਺ͷσόΠεʹҟͳΔ৘ใΛఏࣔ
͢Δ৔߹͸ɼఏ͍ࣔͨ͠දࣔͷ఺໓։࢝࣌ʹͦΕͧΕ఺໓ִؒΛૹ৴͢Δɽ

4

ධՁ࣮‫ݧ‬

ఏҊํࣜͷ༗ޮੑΛධՁͨ͠ɽ·ͣɼSyncBlinkํࣜΛ༻͍ͯఏࣔ৘ใͷࣝผΛߦ͑Δ͔Λ֬ೝ͢Δ
ͨΊɼPC ը໘্Ͱͷ؆୯ͳ࣮‫ݧ‬Λߦ͍ɼ࣍ʹ૷ண‫ܕ‬σόΠεΛ༻͍ͨ৔߹ͷಛੑΛධՁ͢Δɽ࠷‫ʹޙ‬ɼ࣮ࡍʹҊ಺දࣔΛ‫ʹ಺ڥ؀‬ઃஔ͠ɼϢʔβΛ໨త஍SyncBlink: ಉ‫ʹܹࢗظ‬ΑΔφϏήʔγϣϯํࣜͷఏҊͱධՁ

ਤ 5. ࣮‫༻ݧ‬ΞϓϦέʔγϣϯ 2

ਤ 3. σόΠεͷϓϩτλΠϓ

ਤ 4. ࣮‫༻ݧ‬ΞϓϦέʔγϣϯ 1ʹҊ಺͢Δ࣮‫ݧ‬Λߦ͏ɽ

4.1

PC ͷΈΛ༻͍ͨධՁ

·ͣɼ૷ண‫ܕ‬σόΠε͸༻͍ͣʹɼࢹܹ֮ࢗͱௌ
ܹ֮ࢗΛ‫ݸ‬ผʹɼ΋͘͠͸ෳ߹తʹ༻͍ͨ৔߹ʹఏࣔ৘ใΛࣝผͰ͖Δ͔Λ֬ೝ͢ΔͨΊͷ࣮‫ݧ‬Λߦͬͨɽ࣮‫Ͱݧ‬͸ҟͳΔप‫఺Ͱظ‬໓͢Δෳ਺ͷԁΛ PC
ը໘্ʹදࣔ͠ (ਤ 4)ɼλʔήοτͱͳΔԁͷ఺໓ͱಉ‫ͯ͠ظ‬ʮ΢Πϯυ΢ͷ࿮Λ఺໓ͤ͞Δ (ࢹܹ֮ࢗ)ʯʮϏʔϓԻΛ໐Β͢ (ௌܹ֮ࢗ)ʯͷ͍ͣΕ͔ɼ΋͘͠͸྆ํ͕͋Δঢ়ଶͰɼϢʔβ͸λʔήοτΛಛఆ͠ΫϦοΫ͢Δɽ΢Οϯυ΢ͷ࿮Λ఺໓ͤ͞Δ
ͷ͸ɼ஫ࢹ఺Ҏ֎΁ͷܹࢗΛҙਤ͍ͯ͠Δɽԁ͸ͦΕͧΕ͕ҟͳΔ 1ʙ4 ඵఔ౓ͷҰఆͷप‫఺Ͱظ‬໓͠ɼ
2 ͭҎ্ͷԁ͕ಉ࣌ʹ఺౮͢Δ͜ͱ΋͋ΔɽλʔήοτΛΫϦοΫ͢Δͱԁͷपғ͕੺͘ɼλʔήοτͰ- 87 -

ͳ͍΋ͷΛΫϦοΫ͢Δͱԁͷपғ͕άϨʔʹͳΓɼඃ‫ऀݧ‬͸ਖ਼൱ΛೝࣝͰ͖ΔɽΫϦοΫ͢Δͱɼͦͷਖ਼൱ʹؔΘΒͣ࣍ͷλʔήοτʹਐΉɽ͜ͷλεΫΛɼa) ࢹ֮తܹࢗͷΈɼb) ௌ֮తܹࢗͷΈɼc) ࢹ֮తܹࢗʴௌ֮తܹࢗͷࡾछྨΛ֤ 10
ճ (͜ΕΛ 1 ࢼߦͱ͢Δ) ͣͭߦΘͤͨɽ։࢝લʹ͸ɼc ͷ৚݅Ͱઆ໌‫ ͼٴ‬10 ճͷ࿅शΛߦͬͨɽඃ
‫ऀݧ‬͸ 9 ਓʢஉੑ 6 ਓɼঁੑ 3 ਓʣͰɼaʙc ͷॱং͸ϥϯμϜ (ͨͩ͠ɼc ͸ৗʹ࠷ॳ͔࠷‫ͬߦʹ )ޙ‬ͨɽඃ‫ʹऀݧ‬͸ɼ଎͞ΑΓ΋ਖ਼֬ੑΛ༏ઌ͢ΔΑ͏‫ͨࣔ͠ڭ‬ɽද 1 ͕֤ඃ‫ऀݧ‬ͷ֤৚݅ԼͰͷฏ‫ۉ‬ͷճ౴࣌ؒɼ
ճ౴·Ͱͷฏ‫ۉ‬ͷλʔήοτͷ఺໓ճ਺ɼ‫ޡ‬౴ͷ਺Ͱ͋Δɽඃ‫ऀݧ‬ͷ൪߸͸ɼ‫ޡ‬౴ͷগͳ͍ॱʹιʔτͨ͠ɽ·ͣɼશͯͷ৚݅ʹ͓͍ͯ‫ޡ‬౴਺͕খ͍͜͞
ͱ͕Θ͔Δɽඃ‫ ऀݧ‬9 ͸‫ޡ‬౴͕ଟ͍͕ɼ࠷େͰ΋ա൒਺ʹ͸ୡ͍ͯ͠ͳ͍ɽ఺໓਺͕ 2 ճҎԼʹͳͬͯ
͍Δʢ͢ͳΘͪɼλʔήοτΛ‫ݟ‬ఆΊͨ͋ͱʹ࠶౓఺໓Λ଴ͪ֬ೝ͍ͯ͠ͳ͍ʣࢼߦͰ͸‫ޡ‬౴͕ଟ͍ɽ
9 ໊த 4 ໊͸શͯͷࢼߦΛ‫ޡ‬౴ͳ͠Ͱऴྃ͠ɼ8 ໊͸‫ޡ‬౴ͳ͠Ͱऴ͑ͨࢼߦ͕͋Δɽճ౴·Ͱͷ࣌ؒ͸λʔήοτͷ఺໓प‫ظ‬ͷ௕͞ʹґଘ͢ΔͷͰɼ఺໓ճ਺Ͱൺֱ͢Δͱɼશͯͷඃ‫֮ࢹ͍͓ͯʹऀݧ‬తܹࢗͷΈͷ৔߹͕΋ͬͱ΋఺໓ճ਺͕ଟ͍ɽ
͜ΕΒͷ݁Ռ͔Βɼௌ֮తܹࢗΛ༻͍ͨ৔߹ʹ͸ྼΔ΋ͷͷɼࢹ֮తܹࢗͷΈΛ༻͍ͯ΋ಉ‫͢ظ‬Δ
λʔήοτͷ‫ݕ‬ग़͕ՄೳͰ͋ΓɼఏҊํ͕ࣜ༗ޮʹ
࢖͑Δ͜ͱ͕ਪ࡯͞ΕΔɽ·ͨɼ‫ޡ‬౴ͷଟ͔ͬͨඃ‫ ऀݧ‬8ɼ9 ͸ճ౴·Ͱͷฏ‫ۉ‬ͷλʔήοτͷ఺໓ճ਺͕গͳ͍͜ͱ͔Βɼ‫ޡ‬౴͸֬ೝෆ଍͔Β‫͜ى‬Δ͜ͱ
͕ࣔࠦ͞ΕΔͷͰɼϢʔβʹର֬͠ೝΛଅ͢Α͏ͳΠϯλϑΣʔεͷઃ‫ܭ‬Λͨ͠ํ͕Α͍͜ͱ͕Θ͔Δɽ

4.2

ϢʔβσόΠεΛ༻͍ͨධՁ

લઅʹ͓͚Δ PC ্ͰͷධՁ݁ՌΛ;·͑ɼ3 ষͰड़΂ͨ૷ண‫ܕ‬σόΠεΛ༻͍ͯධՁ࣮‫ݧ‬Λߦͬͨɽલઅͷ࣮‫ͱݧ‬ಉ༷ʹɼ఺໓͢Δෳ਺ͷԁΛ PC ը໘্ʹදࣔ͢Δɽ‫ن‬ଇతɼ·ͨ͸ϥϯμϜͳॱংͰԁΛ఺໓ͤ͞ɼਤ 3 ʹࣔͨ͠σόΠεͷ͍ͣΕ͔Λ૷ணͯ͠ɼλʔήοτͱͳΔԁͷఏࣔͷλΠϛϯάͱσόΠεͷܹࢗఏࣔͷಉ‫ظ‬ͷࣝผΛ֬ೝͨ͠ɽ‫ن‬ଇWISS 2013
ද 1. PC ͷΈΛ༻͍ͨධՁͷ݁Ռඃ‫ ऀݧ‬1ඃ‫ ऀݧ‬2ඃ‫ ऀݧ‬3ඃ‫ ऀݧ‬4ඃ‫ ऀݧ‬5ඃ‫ ऀݧ‬6ඃ‫ ऀݧ‬7ඃ‫ ऀݧ‬8ඃ‫ ऀݧ‬9ࢹ֮తܹࢗͷΈ
࣌ؒ (s) ఺໓਺ ‫ޡ‬౴਺
6.52
2.9
0
7.38
2.6
0
8.45
3.3
0
10.8
3.8
0
8.73
3.4
1
5.85
2.1
0
12.0
5.4
3
5.00
2.1
0
6.11
2.3
3

ௌ֮తܹࢗͷΈ
࣌ؒ (s) ఺໓਺ ‫ޡ‬౴਺
5.56
2.2
0
4.76
2.5
0
6.93
3.3
0
7.80
3.3
0
6.94
2.8
1
4.23
2.1
0
7.44
3.4
0
4.24
1.4
2
2.20
1.1
2

ࢹ֮తܹࢗ + ௌ֮తܹࢗ
࣌ؒ (s) ఺໓਺ ‫ޡ‬౴਺
5.98
2.9
0
4.10
2.0
0
5.87
2.9
0
5.72
2.6
0
8.20
3.2
0
4.32
1.7
2
4.59
1.8
0
5.08
1.8
2
2.46
1.3
4

ද 2. ϢʔβσόΠεΛ༻͍ͨධՁͷ݁Ռ

ִؒແ

‫ن‬ଇత
ϥϯμϜ

ִؒ༗

‫ن‬ଇత
ϥϯμϜ

఺౮
ফ౮
఺౮
ফ౮

0.3(ඵ)
0.75
0.83
0.92
0.92
1.00
1.00

ΠϠϗϯ
0.2(ඵ) 0.1(ඵ)

0.75
0.75
0.75
0.83
1.00
1.00

0.50
0.33
0.58
0.67
0.83
1.00

తͳॱংͰ఺໓͢ΔදࣔͰ͸ɼਤ 5 ࠨͷ໼ҹͷॱংͰ఺໓͢ΔɽϥϯμϜͳॱংͰ఺໓͢Δ৔߹ͷΈɼ
ਤ 5 ӈͷΑ͏ʹఏࣔํ๏Λ఺౮Ͱ͸ͳ͘ফ౮ʹͨ͠৔߹ͷ࣮‫ݧ‬΋ߦͬͨɽ͜Ε͸ɼ‫ن‬ଇతͳॱংͰ఺໓
͢Δ৔߹͸ɼ࣍ʹ఺໓͢Δԁ͕Θ͔͍ͬͯΔͨΊ఺౮ͱফ౮Ͱೝࣝʹ͕ࠩͳ͍ͱ൑அͨͨ͠ΊͰ͋Δɽ
‫ن‬ଇతɼϥϯμϜ‫ʹڞ‬ɼ఺໓ͱ࣍ͷ఺໓ͷؒʹ఺໓࣌ؒͱಉ͡௕͞ͷִ͕ؒ͋Δ৔߹ͱͳ͍৔߹ʢྫ͑
͹఺౮ͱͷಉ‫ͳظ‬Βɼ͢΂ͯͷԁ͕ফ౮͍ͯ͠Δ࣌
͕ؒ͋Δ৔߹ͱͳ͍৔߹ʣͷ 2 ύλʔϯߦͬͨɽ఺
౮࣌ؒ͸ࢪߦதҰఆͰɼ0.3 ඵɼ0.2 ඵɼ0.1 ඵͱͨ͠ɽͨͩ͠ɼৼಈσόΠε͸ 0.1 ඵִؒͰ͸ৼಈ͕‫͜ى‬Βͳ͔ͬͨͨΊ 0.1 ඵ͸লུͨ͠ɽ఺໓ॱং
͕‫ن‬ଇతͳ৔߹Ͱ͸ɼಉ‫ظ‬৔ॴΛϥϯμϜʹܾఆͨ͠‫ ޙ‬3 प‫఺ظ‬໓ͤ͞Δಈ࡞ 3 ճΛ 1 ࢼߦͱͨ͠ɽ఺
໓ͷॱং͕ϥϯμϜͳ৔߹Ͱ͸ɼಉ‫ظ‬৔ॴͷ఺໓प‫͕ظ‬௕͍ͱͦͷ৔ॴ͕༧ଌͰ͖ͯ͠·͍ɼಉ‫ظ‬ճ਺͕ଟ͍΄Ͳ༧ଌͰ͖ΔՄೳੑ͕૿͢ͷͰɼ‫ن‬ଇతͳ৔߹ΑΓಉ‫ظ‬ճ਺Λ 1 ճ‫ݮ‬Β͠ɼ2 ճಉ‫͢ظ‬Δ·Ͱ఺໓Λߦ͏ಈ࡞ 3 ճΛ 1 ࢼߦͱͨ͠ɽ͜ͷΑ͏ʹɼલઅͷ࣮‫ͱݧ‬ҟͳΓਖ਼ղ͕෼͔ͬͨΒ͙͢ʹճ౴ͤ͞ΔͷͰ͸ͳ͘Ұఆ‫ؒظ‬ͷ఺໓ͷ‫ޙ‬ճ౴ͤ͞ΔΑ͏ʹͨ͠ཧ༝͸ɼલઅͷ࣮‫݁ݧ‬Ռ͔Β֬ೝෆ଍ʹΑΔ‫ޡ‬ճ౴͕ଟ͘ɼ·࣮ͨࡍͷ‫Ͱڥ؀‬΋ෳ਺ճͷ఺౮‫ظ‬͕ؒଘࡏ͢Δ͜ͱ͕ҰൠతͰ͋Δͱߟ͑ͨͨΊͰ͋Δɽඃ‫ऀݧ‬͸ 4 ਓʢஉੑ 3 ਓɼঁੑ 1 ਓʣͰɼਤ 5ࠨͷ໼ҹͷॱʹࠨ্ͷԁ͔Β 1ʙ9 ͷ൪߸ΛׂΓ౰ͯɼಉ‫ͨ͠ظ‬ԁͷ൪߸Λ౴͑ͯ΋Βͬͨɽ·ͨ‫ޡ‬ೝࣝͷ܏޲Λௐ΂ΔͨΊɼϥϯμϜͷ৔߹͸ಉ‫ظ‬৔ॴͷ఺໓ͷલ‫఺ʹޙ‬໓ͨ͠ԁͷ৔ॴΛ‫ه‬࿥ͨ͠ɽ0.3(ඵ)
0.75
0.83
0.83
1.00
1.00
1.00

LED
0.2(ඵ)
0.75
0.75
0.75
0.83
1.00
1.00

ৼಈ

0.1(ඵ)
0.50
0.25
0.50
0.67
0.67
0.92

0.3(ඵ)
1.00
1.00
1.00
1.00
1.00
1.00

ɹ

0.2(ඵ)
1.00
0.92
0.58
1.00
1.00
1.00

ද 2 ʹ࣮‫ݧ‬ͷ݁ՌΛ·ͱΊͨɽ਺஋͸ඃ‫ ऀݧ‬4 ਓͷฏ‫ۉ‬ਖ਼౴཰Ͱ͋Δɽ͜ͷ݁Ռ͔Βɼ0.3 ඵͱ 0.2 ඵͷ݁ՌͰൺֱ͢ΔͱɼৼಈϞʔλΛ༻͍ͨσόΠεͰͷೝࣝ཰͕ଞͷ 2 ͭͷσόΠεͰͷೝࣝ཰ͱൺ΂΍΍ߴ͍͕ɼ֤σόΠε‫͋ʹڞ‬Δఔ౓ߴ͍ਖ਼౴཰͕
ग़͍ͯΔͨΊɼ఺໓ִؒΛ௕͘͢Ε͹࣮֬ͳೝ͕ࣝ
Մೳͩͱਪ࡯Ͱ͖Δɽ·ͨɼ఺໓ִ͕ؒ 0.1 ඵͷ৔߹ɼৼಈҎ֎ͷσόΠεͰ఺౮ͱͷಉ‫ظ‬ΑΓ΋ফ౮ͱͷಉ‫ظ‬ͷํ͕Θ͔ͣʹೝࣝ཰͕ߴ͔ͬͨɽ͜ͷ͜ͱ͔Β఺౮ͱͷಉ‫ظ‬ΑΓফ౮ͱͷಉ‫ظ‬ͷํ͕ೝࣝ཰
͕ߴ͍ͱਪ࡯Ͱ͖Δ͕ɼ఺໓ִؒΛ௕͘͢Ε͹఺౮ɼফ౮ͱ΋ʹ࣮֬ͳೝ͕ࣝՄೳͰ͋Δɽ·֤ͨσόΠε‫఺ʹڞ‬໓ͱ఺໓ͷؒʹִ͕ؒ͋Δ৔߹ͷํִ͕͕ؒͳ͍৔߹ʹൺ΂ೝࣝ཰͕ߴ͔ͬͨɽ
͜ͷଞɼϥϯμϜͳॱংͷ৔߹ͷฏ‫ۉ‬ೝࣝ཰͸ɼ‫ن‬ଇతͳॱংͷ৔߹ʹൺ΂΍΍ߴ͔ͬͨɽ͜ͷͱ͖ɼ‫ن‬ଇతʹ఺໓ͤͨ͞৔߹ͷ‫ޡ‬ೝࣝͷ 78.4% ͕λʔήοτͷ఺໓ͷલʹ఺໓ͨ͠ԁͱͷ‫ޡ‬ೝࣝͰ͋ͬͨ
ʢϥϯμϜͷ৔߹͸ 47.3% ʣɽ͜ͷ͜ͱΑΓɼ‫ن‬ଇతͳॱংͰ఺໓ͤͨ͞৔߹ɼલ‫ޙ‬ͷ఺໓ͱ‫ޡ‬ղͨ͠৔߹ͷϦΧόϦ͕೉͘͠ͳΔ͜ͱ͕෼͔ΔɽϥϯμϜͳ৔߹͸ɼલ‫ޙ‬ͷ఺໓͕ຖճҟͳΔͨΊɼͦͷϛε͕‫͜ى‬Γʹ͔ͬͨ͘ͱߟ͑ΒΕΔɽΑͬͯɼ఺໓
ͷॱংΛ‫ن‬ଇతʹ͢Δ৔߹͸ɼ‫ޡ‬ೝࣝΛͳͨ͘͢Ί఺໓ͷִؒΛ௕͘͢Δඞཁ͕͋Δɽ

- 88 -

4.3

࣮ࡍͷҊ಺ʹΑΔධՁ

‫ڥ؀‬ଆͷදࣔͱ 3 ͭͷϓϩτλΠϓΛ༻͍ͯɼ࣮
ࡍʹϢʔβΛҊ಺Ͱ͖Δ͔ͷ࣮‫ݧ‬ΛߦͬͨɽલઅͷධՁΑΓɼ఺౮ͱͷಉ‫ͱظ‬ফ౮ͱͷಉ‫Ͱظ‬͸ɼফ౮

SyncBlink: ಉ‫ʹܹࢗظ‬ΑΔφϏήʔγϣϯํࣜͷఏҊͱධՁ

ਤ 6. Ҋ಺දࣔਤ 8. ໨త஍Ҋ಺࣮‫ݧ‬ͷ؆қਤ

ਤ 7. Ҋ಺࣮‫ݧ‬ͷ෩‫ܠ‬ͱͷಉ‫ظ‬ͷํ͕ೝࣝ཰͕ߴ͔ͬͨͨΊɼ࣮‫ݧ‬͸ফ౮ͱͷಉ‫ͨͬߦͰظ‬ɽ·ͨɼϥϯμϜͳॱংͰͷ఺໓Ͱ͸ɼϢʔβ͕දࣔΛ஫ࢹ͢Δඞཁ͕͋Γɼִؒͷ௕͍‫ن‬ଇతͳॱংͰͷ఺໓Ͱͷೝࣝ͸े෼࣮֬ͩͱਪ
࡯Ͱ͖ΔͷͰɼ࣮‫ݧ‬͸‫ن‬ଇతͳॱংͰͷ఺໓Ͱߦͬ
ͨɽ఺໓ͷִؒ͸ɼϢʔβ͕༰қʹࣝผͰ͖͔ͭ࣍
ͷఏࣔ·Ͱͷ଴͕ͪ࣌ؒ௕͍ͱ‫͍ͳ͡ײ‬Α͏ʹɼචऀͷ൑அͰ 0.7 ඵͱͨ͠ɽ࣮‫ݧ‬͸ҎԼʹࣔ͢ 3 छྨߦ͕ͬͨɼ‫ڥ؀‬ଆ͕ 1 ͭͷ৔߹͸ਤ 6 ࠨʹࣔ͢Ҋ಺൛Λ༻͍ɼෳ਺ͷ৔߹͸ਤ 6 ࠨͷҊ಺൘ͱӈͷ PC
ը໘্ͷදࣔͱΛซ༻ͨ͠ɽ·ͨෳ਺ͷϢʔβΛಉ࣌ʹҊ಺Ͱ͖Δ͔Λௐ΂ΔͨΊɼ֤࣮‫ ݧ‬2 ਓ·ͨ͸
3 ਓ 1 ૊Ͱߦ͍ɼಉ͡·ͨ͸ҟͳΔҊ಺Λఏࣔͨ͠ɽ
࣮‫ݧ‬෩‫ܠ‬Λਤ 7 ʹࣔ͢ɽ͜ͷਤͰ͸ඃ‫ऀݧ‬͸௚ਐΛఏࣔ͞Ε͍ͯΔɽԁ‫ʹ׈‬Ҋ಺Ͱ͖Δ͔ͷධՁาߦதͷϢʔβཱ͕ͪࢭΔ͜ͱͳ͘ԁ‫ʹ׈‬Ҋ಺͞Εͨํ޲΁ਐΊΔ͔Λௐ΂ΔͨΊɼ࣮‫ݧ‬Λߦͬͨɽඃ
‫ʹऀݧ‬෼‫ذ‬Λࣔ͢ेࣈ࿏͔Β໿ 16 m खલʹελʔτϥΠϯΛઃ͚ɼेࣈ࿏ͷ 1 m खલͷಓ୺ʹ௚ਐ·ͨ͸ӈࠨંΛఏࣔ͢ΔҊ಺൘Λઃஔ͠ɼาߦதͷඃ‫ࢭཱ͕ͪऀݧ‬Δ͜ͱͳ͘ेࣈ࿏ΛҊ಺͞Εͨํ޲ʹਐΊΔ͔Λௐ΂ͨɽඃ‫ʹऀݧ‬͸࢝Ίਐߦํ޲ͱ͸൓ରΛ޲͍ͯ΋Β͍ɼγεςϜΛ‫ى‬ಈͯ͠࠷ॳͷಉ‫ظ‬Λ‫͔ͯ͡ײ‬Βɼਐߦํ޲ʹਐΜͰ΋Βͬͨɽඃ‫ऀݧ‬
͸ 12 ਓͰ֤ඃ‫ͦऀݧ‬ΕͧΕ 3 ͭͷσόΠεͰ 1 ճ
ͣͭ 3 ճ࣮‫ݧ‬Λߦͬͨɽ࣮‫ݧ‬ͷ݁Ռɼาߦ଎౓ʹ͸‫ݸ‬ਓ͕ࠩ͋ͬͨ΋ͷͷɼͲͷσόΠεΛ༻͍ͯ΋ཱ
ͪࢭ·ͬͨඃ‫ऀݧ‬͸͍ͳ͔ͬͨɽ

ਤ 9. ෳ਺ද࣮ࣔ‫ݧ‬ͷ؆қਤ໨త஍΁ͷҊ಺ͷධՁ࣮ࡍʹϢʔβΛ໨త஍΁Ҋ಺Ͱ͖Δ͔Λௐ΂ΔͨΊɼඃ‫ ʹऀݧ‬2 ͭͷ෼‫ذ‬ΛਐΜͰ΋Β͏࣮‫ݧ‬Λߦͬ
ͨɽਤ 8 ͷΑ͏ʹ‫ڥ؀‬ଆͷදࣔ͸ɼҊ಺൘ͱ PC ϞχλʔΛ༻͍ɼ࢝ΊʹҊ಺൘Λ༻͍ͯ 3 ํ޲ͷ෼‫ذ‬Λɼ࣍ʹϞχλʔΛ༻͍ͯ 2 ํ޲ͷ෼‫ذ‬ΛਐΜͰ΋ΒͬͨɽελʔτҐஔ͔Β໨త஍·Ͱʹ͸ 2 ௨Γͷϧʔτ͕͋Γɼ࢝Ίͷ෼‫ͪͲͰذ‬Β͔ͷϧʔτΛఏࣔ͠ɼ2 ͭͷϧʔτͦΕͧΕʹ࣍ʹ͋Δ෼‫ʹذ‬ϞχλʔΛઃஔͨ͠ɽҊ಺൘ͱ PC Ϟχλʔͷதؒ஍఺෇ۙͰ͸ɼσόΠε͸྆ํ͔Βͷ৴߸Λड͚औΓɼҙਤͨ͠Ҋ಺ͱ͸ผͷܹࢗΛఏࣔ͢Δ͕ɼҊ಺൘ͱϞχλʔ͕ಉ࣌ʹࢹքʹೖΔ͜ͱ͸ͳ͘ɼͲͪΒ͔ͷද͕ࣔ͸͖ͬΓ‫͑ݟ‬Δ‫ͱͮۙ͘Ͱ·཭ڑ‬΋͏Ұํ͔Βͷఏࣔ͸ಧ͔ͳ͔ͬͨɽඃ‫ऀݧ‬͸ 10 ਓͰ͋Δɽ࣮‫ݧ‬ͷ݁Ռɼ͢΂ͯͷඃ‫ऀݧ‬Λҙਤͨ͠৔ॴ΁Ҋ಺Ͱ͖ͨɽதؒ஍఺෇ۙͰͷ྆ํ͔Βͷܹࢗͷఏࣔʹ͍ͭͯҧ࿨‫ײ‬Λ֮͑ͨඃ‫ऀݧ‬΋͍͕ͨɼ΄ͱΜͲͷඃ‫ऀݧ‬͸දࣔͷ‫͍ͳ͍ͯ͑ݟ‬஍఺ͰͷܹࢗͳͷͰ‫ͳʹؾ‬Βͳ͔ͬͨͱ౴͑ͨɽද͕ࣔ͸͖ͬΓ‫͑ݟ‬Δ
ͱ͜ΖͰ͸ยํ͔Βͷܹࢗͷఏ͔ࣔ͠ͳ͍͜ͱ͔Βɼؒҧͬͨํ޲΁ͷҊ಺͸‫͜ى‬Βͳ͔ͬͨɽ·ͨɼ͜ͷҧ࿨‫ײ‬Λ‫͡ײ‬Δ໰୊͸ɼ࣍ʹ࣮ࣔ͢‫ݧ‬ͷख๏Λ༻͍Δ͜ͱͰղܾͰ͖Δɽෳ਺ͷҊ಺ද͕ࣔಉ࣌ʹ‫͑ݟ‬Δ৔߹ͷධՁෳ਺ͷҊ಺ද͕ࣔಉ࣌ʹϢʔβͷࢹքʹೖΔ৔߹ʹɼϢʔβΛਖ਼͘͠Ҋ಺Ͱ͖Δ͔Λௐ΂ΔͨΊɼ୹

- 89 -WISS 2013ִ͍ؒͰ 2 ͭͷ෼‫͕͋఺ذ‬Δ‫ʹڥ؀‬Ҋ಺൘ͱ PC ϞχλʔΛઃஔͯ͠ඃ‫ऀݧ‬Λҙਤͨ͠৔ॴʹҊ಺Ͱ͖Δ͔ͷ࣮‫ݧ‬Λߦͬͨɽ࢝Ίʹӈ·ͨ͸ࠨํ޲΁ͷ෼‫͕͋ذ‬Γɼࠨํ޲ʹ͸৽ͨͳ෼‫ذ‬͸ͳ͘ɼӈํ޲΁ਐΜͩઌʹ͸͞Βʹ 3 ํ޲΁ͷ෼‫ذ‬Λઃ͚ͨʢਤ 9ʣɽ࠷ॳͷ 2 ํ޲΁ͷ෼‫ͱͮۙ͘΁ذ‬ɼ࣍ͷ 3 ํ޲΁ͷ෼‫ذ‬Λࣔͨ͠Ҋ಺൛͕‫͑ݟ‬ΔΑ͏ʹͨ͠ɽ2 ͭͷҊ಺ද͕ࣔಉ࣌ʹ‫ͯ͑ݟ‬΋ਖ਼͍͠Ҋ಺Λߦ͑ΔΑ͏ʹ͢ΔͨΊɼͦΕͧΕͷҊ಺൘ͷཁૉ਺ 2 ͱ 3 ͷެഒ਺ 6 Λ 1 प‫఺ͨ͠ͱظ‬໓ΛߦΘͤΔ͜ͱͰɼ͢΂ͯͷදࣔͷ૊Έ߹ΘͤʹରԠ͢Δɽྫ͑͹Ҋ಺͢Δ৔
ॴ͕ਤ 9 ͷ໨త஍ 1 ͷ৔߹ɼϢʔβଆͷσόΠε͸
࢝ΊͷҊ಺ͷࠨͷදࣔͰৗʹܹࢗΛఏࣔ͢Δ͕ɼ໨
త஍ 2ɼ3ɼ4 ͷ৔߹ɼ࢝ΊͷҊ಺͕ӈΛදࣔ͠ɼ࣍
ͷҊ಺͕Ϣʔβͷ໨త஍Λࢦ͢૊߹ͤͷ৔߹ʹͷΈܹࢗΛఏࣔ͢Δɽ͜ͷΑ͏ʹ͢Δ͜ͱͰɼܹࢗఏࣔ
ִؒ͸ԆͼΔ͕ɼϢʔβ͕ؒҧ͑ͨ৘ใΛड͚औΔ
͜ͱ͕ͳ͘ͳΔɽ͜ͷ࣮‫ݧ‬ͷ݁ՌɼҊ಺৔ॴ͕ਤ 9 ͷ໨త஍ 2ɼ3ɼ
4 ͷ৔߹ʹ͸࠷ॳͷ෼‫Ͱذ‬ͷ৘ใఏࣔʹଟগ࣌ؒ͸͔͔͕ͬͨશͯͷඃ‫ऀݧ‬ҙΛҙਤͨ͠໨త஍ʹҊ಺Ͱ͖ͨɽҰํɼࢹք಺ͷҊ಺൛਺͓Αͼ֤Ҋ಺൘ʹ͓͚Δબ୒ࢶ਺͕૿Ճ͢Ε͹ͦͷ૊߹ͤ΋๲େʹͳ
ΔͨΊɼܹࢗఏࣔͷप‫༻࣮͕ظ‬తͳϨϕϧʹอͯͳ
͘ͳΔՄೳੑ͕͋ΔɽͦͷΑ͏ͳ৔߹ɼϢʔβʹ࠷΋͍ۙҊ಺ද͔ࣔΒͷ৴߸ͱͷΈσόΠεΛಉ‫͞ظ‬ͤɼ͔ͭ‫ํޙ‬ͷҊ಺ද͔ࣔΒͷ৴߸Λड͚औΒͳ͍‫ߏػ‬΍ɼಉ࣌ʹ‫͑ݟ‬Δෳ਺ͷҊ಺දࣔ͸఺໓ͷप‫ظ‬Λૣ͘͢Δͱ͍ͬͨ޻෉͕ඞཁͱͳΔɽ

4.4

ߟ࡯

Ҏ্ͷ࣮‫ݧ‬ΑΓɼఏҊํࣜ͸࣋ͪӡ΂ΔσόΠε
Λ༻͍࣮ͯ֬Ͱԁ‫ͳ׈‬Ҋ಺͕Ͱ͖Δ͜ͱ͕֬ೝͰ͖
ͨɽ·ͨɼෳ਺ͷϢʔβʹಉ͡·ͨ͸ҟͳΔҊ಺͕ՄೳͰ͋Δ͜ͱ΋֬ೝͰ͖ͨɽ໨త஍΁ͷҊ಺ͷධՁʹ͓͍ͯɼඃ‫ʹऀݧ‬ಉ‫ظ‬ͷΘ͔Γ΍͔ͬͨ͢σόΠεʹ͍ͭͯฉ͍ͨͱ͜ΖɼΠϠϗϯΛ༻͍ͨԻͱ
ͷಉ‫͕ظ‬Ұ൪Θ͔Γ΍͍͢ͱ౴͑ͨඃ‫࠷͕ऀݧ‬΋ଟ
͘ 6 ਓͩͬͨɽ·ͨͦͷ͏ͪ 5 ਓ͕ɼৼಈʹ͍ͭͯ΋Իͱಉ͙͡Β͍Θ͔Γ΍͔ͬͨ͢ͱ౴͑ͨɽޫ
͕Ұ൪Θ͔Γ΍͔ͬͨ͢ͱ౴͑ͨඃ‫ऀݧ‬͸ 1 ਓ͚ͩͰɼͦΕҎ֎ͷඃ‫ऀݧ‬͸ޫ͕Ұ൪Θ͔Γʹ͔ͬͨ͘ͱ౴͑ͨɽ͜Ε͸ɼҊ಺൘ͷද͕ࣔࢹܹ֮ࢗͳͷʹର͠ɼಉ͡ࢹܹ֮ࢗΛ༻͍͍ͯΔ͜ͱ͔ΒɼҊ಺൘ͷදࣔͱσόΠεͷޫఏࣔ྆ํΛҙࣝ͢Δͷ͕೉͍͔͠Βͩͱਪ࡯Ͱ͖ɼϢʔβଆύʔιφϧσόΠε
ʹࢹܹ֮ࢗ͸ෆ޲͖ͩͱߟ͑ΒΕΔɽҰํɼ͜ͷ݁Ռ͔ΒԻ੠Ҋ಺౳ʹରͯ͠ࢹܹ֮ࢗʹΑΓϢʔβΛφϏήʔτ͢Δͱ͍ͬͨγεςϜ͕༗ޮʹͳΔՄೳੑ͕͋Δɽ͜ͷΑ͏ʹɼఏҊํࣜΛ༻͍ͯาߦதͷϢʔβΛԁ‫ʹ׈‬໨త஍ʹҊ಺Ͱ͖Δ͜ͱΛ֬ೝͰ͖ͨͨΊɼ- 90 -

Ҋ಺ํࣜΛ༻͍Δͱ௕࣌ؒ૷ண‫ܕ‬σόΠεʹ஫ҙΛ޲͚Δ͜ͱͳ͘ఏࣔΛࣝผͰ͖ΔՄೳੑ͕ߴ͍ɽ͠
͕ͨͬͯɼύʔιφϧϞϏϦςΟ΍ࣗಈंͳͲͷӡసதͷ࢖༻΋Մೳͩͱߟ͑ΒΕΔɽ5·ͱΊຊ‫Ͱڀݚ‬͸ɼύʔιφϧσόΠεͱ‫ڥ؀‬ଆ͕࿈‫͠ܞ‬ɼಉ‫ܹࢗͨ͠ظ‬ΛϢʔβʹఏࣔ͢Δ͜ͱͰφϏήʔγϣϯΛߦ͏ SyncBlink ΛఏҊͨ͠ɽ࣮‫݁ݧ‬ՌΑΓɼ‫ڥ؀‬ଆͷ֤Ҋ಺දࣔΛಠཱͨ͠λΠϛϯά
Ͱ఺໓ͤ͞ɼϢʔβ͕ඞཁͱ͢ΔҊ಺ʹಉ‫ࢗͨ͠ظ‬ܹΛ୺຤͔Βड͚औΔ͜ͱʹΑΓɼద੾ʹҊ಺͕ߦ
͑Δ͜ͱΛ֬ೝͨ͠ɽϢʔβ୺຤ଆͷܹࢗͱͯ͠͸ࢹ֮΍ௌ֮ɼ৮֮Λ‫͖Ͱ༻׆‬ɼาߦத͚ͩͰͳ͘ɼ
ύʔιφϧϞϏϦςΟͷӡసத౳ɼ͞·͟·ͳঢ়‫گ‬ʹରԠ͢Δ͜ͱ͕Մೳͩͱߟ͑ΒΕΔɽಉ͡·ͨ͸ผʑͷҊ಺Λෳ਺ͷϢʔβʹಉ࣌ʹߦ͏͜ͱ΋༰қͰ͋Γɼਓͷଟ͍‫Ͱڥ؀‬΋‫͖Ͱ༻׆‬Δɽࠓ‫ޙ‬͸ɼ͞·͟·ͳ‫ܗ‬ଶͰͷ࣮૷ΛਐΊΔɽͦͷ্Ͱ࣮‫Ͱڥ؀‬ͷ࣮‫ݧ‬Λߦ͍ɼ༗ޮੑΛ‫͢ূݕ‬Δ༧ఆͰ͋Δɽ

ࢀߟจ‫ݙ‬[1] ᖒ໺߂໌, Ԭా ູ: ֦ு‫ٕײ࣮ݱ‬ज़Λ༻͍ͨ࣍ੈ
୅ΧʔφϏͷͨΊͷಓ࿏୺நग़๏ͷ‫ݕ‬౼, ৘ใॲཧֶձ‫ڀݚ‬ใࠂ (άϥϑΟΫεͱ CAD ‫ڀݚ‬ձ), Vol.
2004, No. 121, pp. 103–108 (Nov. 2004).
[2] ߴాେี, খ઒߶࢙, ਗ਼઒ ਗ਼, ஛ଜ࣏༤: ਎ମಈ࡞ʹ‫͖ͮج‬ఏࣔ৘ใΛ੾Γସ͑ΔίϯςΩετΞ΢Σ
Ξͳ΢ΣΞϥϒϧ AR γεςϜ, ώϡʔϚϯΠϯλϑΣʔεֶձ࿦จࢽ, Vol. 12, No. 1, pp. 47–56(Feb. 2010).
[3] CyberNavi: http://pioneer.jp/carrozzeria/
cybernavi/.
[4] MapFan eye: http://www.mapfan.com/iphone/ar.
[5] ௩ాߒೋ, ҆ଜ௨ߊ: Active Belt: ৮֮৘ใΛ༻͍ͨϕϧτ‫ܕ‬φϏήʔγϣϯ‫ߏػ‬, ৘ใॲཧֶձ࿦จ
ࢽ, Vol. 44, No. 11, pp. 2649–2658 (Nov. 2003).
[6] ਫ໺౷ଠ, ಺ాխจ, Ҫग़ӳਓ: ৼಈܹࢗʹΑΔφϏήʔγϣϯ৘ใͷೝ஌ධՁ, ిࢠ৘ใ௨৴ֶձٕ
ज़‫ڀݚ‬ใࠂ (ME ͱόΠΦαΠόωςΟοΫε‫ڀݚ‬ձ), Vol. 106, No. 592, pp. 41–44 (Mar. 2007).
[7] দ‫޿ ݪ‬, ਂᖒ‫ࢠل‬, ‫ޙ‬౻ߒҰ: ࢹ֮ো֐ऀ޲͚ର
࿩‫ܕ‬৘ใఏ‫ڙ‬γεςϜͷ։ൃ, ৘ใॲཧֶձ‫ڀݚ‬
ใࠂ. ITS, [ߴ౓ަ௨γεςϜ], Vol. 2001, No. 83,
pp 75–82 (Sep. 2001).
[8] ҁ௩༞ೋ: ඳ͖଍͍ͯ͘͜͠ͱΛ‫ڧ‬ௐͨ͠खॻ͖ίϛϡχέʔγϣϯπʔϧ, ୈ 12 ճΠϯλϥΫςΟ
ϒγεςϜͱιϑτ΢ΣΞʹؔ͢ΔϫʔΫγϣοϓ(WISS 2004), pp. 9–12 (Dec. 2004).

WISS2013

Traxion: 仮想力覚提示デバイス
暦本 純一∗
概要.
仮想力覚を作り出す新しい触覚アクチュエータの構成について報告する．このデバイスは人間の振動刺激とその知覚の非線形な関係に基づき，振動波形を制御することで押したり引いたりといった「力」を感じさせる．既存研究と比較してアクチュエータのサイズや重量が非常にコンパクト (35.0 mm 5.0 mm
7.5 mm，5.2 g) で，力覚提示方向を迅速に変更することが可能である．振動アクチュエータへの入力信
号と，実際にアクチュエーターに発生している振動や加速度をレーザ測距装置で計測し，仮想力覚の発生原因を解析した．評価者実験の結果，すべての実験参加者が仮想力覚を感じることを確認した．仮想力覚の強さを評価するために，現実の錘と仮想力覚を比較する評価実験を行い，このアクチュエータが約 30 g の仮
想力覚を作り出していることを推定した．本研究は多様な場面でインタラクティブシステムに応用することが可能であると考えているが，本論文では歩行者ナビゲーションと，DLP(Digital Light Processing) プ
ロジェクター光による可視光通信で空中に力覚場を作り出す応用例についても報告する．

1

はじめに

触覚はわれわれが生活する上でとても重要な感覚である．触覚として知覚することで，われわれは現
実世界の物体の形状を把握し，物体の操作を精密に，正確に，そして素早く行うことができる．コンピュー
タなどの電子機器の操作においても，触覚フィード
バックを利用している研究事例は多い．
ここで，触覚によるフィードバックを２つに分類する．ひとつめは力覚フィードバックと呼ぶもので，実際に「力」を発生させるものである．機構部品（ロッドなど）により操作部に力を与えているもの [7, 9],
ワイヤーにより力を与えるもの [5] などが提案されている．もうひとつは，触覚ディスプレイあるいは振動フィードバックとよばれるもので，力は発生させずに，フィードバックとして振動を利用するものである．たとえばタッチパネル上のボタンをタッチしたときに，クリック感を振動によって提示するものなどが提案されている [4, 11].
これらの二種類はそれぞれの目的・用途があり，また長所・短所がある．力覚フィードバックは機構部品やワイヤーなどで固定物と接続する必要があり，装置が大掛かりになってしまうので，モバイル用途などに適用することができない．一方，触覚ディス
プレイでは本当の「力」を提示することができない
ので，現実での力覚を再現するような用途には向かない．また，フィードバックとして用いる場合も，利用者や操作部を特定の方向に導くために力の方向を利用することができない．
機構部品によらずに力覚を提示するいくつかの研究事例がある．2 ないし 3 個の偏心モーターによって慣性モーメントにより力覚を提示する装置を提案されている [14, 10, 3]. 雨宮らは刺激の認知の非線形性にもとづき，回転体とクランク機構によって非対称的な加速度パターンを生成し，力覚が感じられることを示している [2, 16]. これらの研究により，実際に物理的な力を発生させなくても，知覚としての力覚の提示が可能なことがわかってきた．しかし，従来提案されている機構はいずれも回転体やクランク機構などの機械部品からなっており，全体のサイズや重量の点で改良の余地がある．たとえば雨宮らのデバイスは単方向の力覚提示に 70 mm
200 mm 48 mm の装置を要し，重量も 250 g であった [2]．これらを組み合わせて２次元ないし３次元の力覚提示装置を構成するためには，さらに重量が増すことが予測される．
回転体やクランク機構による力覚提示のもう一つの問題は反応性である．回転方向を急に変化させたり逆転することは難しいので，インタラクティブなシステムにおいて力覚の量を迅速に提示することができない．クランク機構は，構造上，回転方向を逆にしても非対称な加速度のパターンは逆転しないので，一次元かつ単方向への力覚提示しか行えない．回転体ではモーターの回転方向を変えることで力覚の提示方向の変化が可能であり、小型モーターによってアクチュエータの小型化も可能なことが報告されている [10]。しかしモーターの回転を急激に停止・開始することは依然困難である。
本論文では，これらの問題を解決し，従来よりも飛躍的に小型軽量化された仮想力覚提示デバイ
ス，Traxion について報告する．Traxion の外形は7.5 mm35.0 mm
5.0 mm で重量は 5.2 g であり，双方向一次元の仮想力覚を創り出すことができる．また提示方向を変化させるのに要する時間も数ミリセカンド程度である．

2

Copyright is held by the author(s).
∗東京大学大学院情報学環・ソニーコンピュータサイエン
ス研究所

Traxion の動作原理

Traxion はアルプス社のゲームパッド用振動アクチュエータ (Force Reactor [1]) の入力信号を制御す- 91 -WISS 2013
'&*

7.5
mm


  

5mm


35
m
m


)(

!

'&*%$  #%$Bluetooth($)("! $!

(Arduino(pro(mini)((+(  

図 1. 振動子 (フォースリアクター) の構成

ることで仮想力覚を作り出している．Force Reactor
は，コイルが板バネで支えられた振動体が格納されている．ケースの両端には永久磁石が設置されている (図 1)．この構造でコイルに電流を加えると磁界が発生し，コイルが一定方向に移動し，加速度を生み出す．印加を停止すると板バネによってコイルが元の位置に戻る．この構造をゲームパッドに組み込
むと，様々な振動パターンを作り出すことができる．
実際にアクチュエーターに発生する加速度をレー
ザー測距装置 (キーエンス LK5000) によって測定した結果を図 2 に示す．指で保持した場合と，スポンジ，シリコン，ゴムの台上にアクチュエータを置き計測した場合を比較した．図では指で保持した場合と比較的加速度パターンが似ているスポンジ台での測定結果を示している．加速度計測周期は 50 μ s である．
図 2(1) は，コイルに直流電圧を印加したときのアクチュエーターに発生する加速度である，印加後コイルの移動にともない加速度が発生し，それが減衰していく様子がわかる．信号の印加／停止を周期的に繰り返すことで定常的な振動を作り出すことができる．図 2(2) は 125 Hz の正弦波を，(3) は同じ
く 125 Hz の矩形波（デューティー比 5:5) を加えた場合の加速度である．コイルに発生する磁界による運動と板バネによる減衰効果が組み合わさっており，
周期運動ではあるものの，入力信号がそのまま単純には加速度変化に反映しているわけではないことが観測される．この (2) と (3) の場合，アクチュエー
ターを指で保持しても，振動は感じられるものの，力を感じることはなかった．
次に，アクチュエータにデューティー比の異なる矩型信号を印加してみると，仮想力覚が感じられることを発見した．図 2 (4) がそれで，周波数 125Hz
でデューティー比 2:6(2 ms on,6 ms off) の信号を与えると，アクチュエータが一方向に引っぱられるよ
うな力を感じることがわかった．図からも明らかな
ように，このときアクチュエータが非対称な加速度運動をしていることがわかる．また，デューティー
比を変化させることで，仮想力覚の方向も制御できることがわかった．図 2(4) では下向きの力を感じ- 92 -

図 3. 試作システムの構成: マイクロコントローラー(Arduino) が Bluetooth 経由で命令を受信しアクチュエーター用の駆動波形を生成する．信号増幅にはオーディオ用デジタルアンプを利用している．

るが，(5) のデューティー比 6:2(6 ms on, 2 ms off)
では逆に上向きの力を感じる．以上の場合でも，コイルに印加された信号が単純に振動に反映されているわけではなく，コイルと板バネの効果が複合していることを指摘しておく．
ここで，仮想力覚の発生原因について考察する．ア
クチュエーターは外部と機構部や糸などで支えられている訳ではないので，振動加速度を一定時間積分すればその値はゼロになり，現実には力は発生していない．したがって感じられる力は人間の知覚機構によるある種の錯覚であると推定される．仮想力覚の発生原理については Stevens の冪法則 (Stevens’s powerlaw) [13] と呼ばれる，刺激とそれに伴う感覚の強さの関係によるものが仮説の一つである．Stevens の冪法則は，刺激 I による感覚の強さ S が S = kI αとなるというものである（ここで k は比例定数，αは刺激の種類により決まる係数）．測定された加速度の積分値はゼロになるが，このようにして知覚された感覚 S の積分値はゼロにはならず，力として感じられるのではないかと推測している．仮想力覚の発生原因として考えられる他の要因は、刺激のマス
キング効果である。強い刺激の直後の弱い刺激がマスクされるという現象である。図 2(4),(5) では大きな加速度の直後に（反対方向への）小さな加速度運動が連続しているので、この部分の知覚がマスキン
グ効果によって抑制されれば、やはり力覚を感じることになる。
今回のデバイスでは，アクチュエーターをデューティー比の異なる矩型信号で駆動した場合に、コイ
ルと板バネによる構成によりその駆動信号が変形された結果，力覚を感じる非対称な加速度を生み出していると推定される．
システム構成本研究で利用しているシステム構成を図 3 に示
す．駆動波形を発生させるマイクロコントローラー![!m/s2!]

Traxion: 仮想力覚提示デバイス

2

3

4

5

6

![!m/s2!]

1

図 2. Traxion によって駆動される振動形状：デューティー比が異なる入力信号により異なる加速度が形成される．(1)
単一パルス印加と対応する加速度 (2) 正弦波 (3) 矩形波（デューティー比 1:1) (4) デューティー比 2:6 (5) デュー
ティー比 6:2 (6) 加速度計測環境(Arduino) が Bluetooth 経由で指令を受け取りアク1"

チュエーターを駆動する．信号増幅のためにオーディ
オ用デジタルアンプを利用している．前章の実験により，仮想力覚を発生させるための波形は矩型で充分なことが分かったので，マイクロコントローラーの出力端子 (0V/5V を切り替え可能）を直接オー
ディオアンプの入力端子に接続し，DA 変化を省略することで構成の簡素化を実現している．

3

0.9"





0.8"
0.7"
0.6"
0.5"
0.4"
0.3"
0.2"
0.1"
0"

評価

3.1 実験 1: 一次元仮想力覚デバイス
Traxion の効果を確認するために利用者評価実験を行った．実験参加者は 10 名で，全員コンピュータ

640
1"

320
2"

160!
3"

!

80
4"![ms]

40!
5"

図 4. 実験 1: 一次元仮想力覚の評価実験環境および結果

サイエンス関係学科の大学院生である．参加者はアクチュエーターを指で保持し，仮想力覚が感じられたときにその方向を回答する．アクチュエーターを駆動する時間は 640，320, 160, 80, 40 ms で，正方向と逆方向の仮想力覚を作り出す２つの振動パター
ン (2 ms:6 ms と 6 ms:2 ms のデューティー比）との組み合わせを提示する．振動時間，振動パターンの組み合わせはランダムに選択されている．各参加者は，それぞれの振動時間に対して５回の刺激提示・
回答のタスクを行う．回答はゲームコントローラーのスティックによって入力する．振動以外の情報を遮断するため，参加者はアイマスクとノイズキャン
セルヘッドフォンを装着している（図 4:左).
評価結果を図 4(右) に示す．グラフに示されているように刺激時間が短縮されると若干正答率が落ちるものの，いずれも高い正答率を示しており，この- 93 -

仮想力覚が複数の実験参加者が同様に感ずる感覚であることが確認できた．
実験後のインタビューによると，多くの実験参加
者が，指で保持しているアクチュエーターを動かしてみると仮想力覚をより明確に感じられるという意
見が多く聴かれた．とくに力覚の方向にアクチュエー
ターを動かした時にこの効果は顕著だった．この効果に対する仮の説明は以下のようである．現実世界での牽引力，たとえばゴムやスプリングによるもの
は，牽引する方向に物体を動かすことで力が弱くなるものが多い．一方，仮想力覚の場合，移動させても感じられる力はとくに減らないので，それを「逆算して」元の力が強くなったと錯覚するのではないか，という可能性が考えられる．

WISS 2013

Traxion( 
(
(
)

Traxion( ((

図 5. 2 次元仮想力覚デバイスへの拡張
1"45




図 7. 実験 3:仮想力覚量の評価



0.8"
0.6"






0.4"
0.2"

!


0"
1"

2"

3"

4"

5"

6"

7"

8"

9"

10"

 
図 6. 実験 2: 二次元仮想力覚提示実験結果

3.2

実験２: 二次元仮想力覚デバイス

次に，本デバイスを組み合わせることで多次元の仮想力覚が提示可能か検証した．図 5 のように，２つのアクチュエーターを，それぞれの牽引方向が直角になるように接合した．このデバイスで，同時に加速力覚を提示した場合に，その合成方向に力覚が感じられるかを評価した．
実験 1 と同じ 10 名が評価実験に参加した．アクチュエータを指二本で保持し，力が感じられた方向を答える．この実験では 45 度ごとに 8 方向からいずれかを回答するようにした．刺激提示の時間は 640 ms
で固定し，デューティー比は 2 ms:6 ms を用いた．
縦横方向の仮想力覚はどちらか一つのアクチュエー
ターをその方向の力覚が提示されるように駆動し，斜め方向は両方のアクチュエーターを駆動した．参加者は実験 1 と同様，アイマスクとノイズキャンセ
ルヘッドフォンを装着し，ゲームスティックによって回答した．
この実験では，図 6 で示すように正答率はチャンスレベルを上回るものの，正しく力覚が感じられているとは言いがたい状況だった．複数のアクチュ
エーターを同時に駆動しても，全体の振動が斜め方
向を力覚を感じさせるような振動としては合成されないことが主な理由であると考えているが，複合ア
クチュエータでの実際の振動の解析を今後実施する予定である．

3.3

実験 3: 仮想力覚量の推定では，発生している仮想力覚の強さはどのくらいだろうか．これを評価するために実験３を計画・実施- 94 -

した．実験参加者は，仮想力覚を発生するアクチュ
エータと，振動はしているが仮想力覚が発生しない
ように印加信号を調整したアクチュエーターを両手で保持する．力覚が発生していないアクチュエーター
にテグスと滑車を介して錘を取り付け，牽引力が発生するようにしている．それぞれのアクチュエーター
を交互に駆動し，錘の重さを変え，ちょうど同じ位の牽引力だと感じたときの重さを記録する．実験参加者には，錘の重さを感じるために，それぞれのア
クチュエーターをゆっくりと前後に動かすことをお願いした．
それぞれの錘に対して，「錘の方が重い／軽い／同じ位」と回答してもらい，同じ位と答えた値を実験結果として記録した．実験 1,2 と同じ 10 名が実験に参加した結果，平均値は 29.8 g (0.292 N) 標準偏差は 8.5 g (0.083 N) だった．この実験により，発生している仮想力覚がおおむね 30 g 程度であると推定される．
ただし，この実験条件の場合，片方の手は錘の重量を常に支えているが，仮想力覚は振動しているときしか発生しない．したがってこの二つを単純に比較して正しいかどうかは疑問が残る．今後実験条件を変更するなどして仮想力覚の推定精度を上げてい
きたい．

4
4.1

応用

方向の提示

仮想力覚は，歩行者を誘導するために有効だと考える．たとえば指輪型のアクチュエータに仮想力覚を発生させて，誘導した方向へ牽引することができ
れば，視覚情報によらず空間ナビゲーションができるかもしれない．また，たとえば物の位置を何らかの手段で認識できるとすると，その物に向かって指先を牽引するデバイスなどが考えられる．また視覚障碍者のナビゲーション手段としても利用できるのではないかと考えている．
こういった位置誘導応用の可能性を検証するため

Traxion: 仮想力覚提示デバイス

2, 3] が，本論文が提案するデバイスと比較すると重図 8. Traxion アプリケーション例: (左) 歩行者の誘導．(right) 仮想力覚つき入力装置．プロジェクターの照射によって力場を作り出す．DLP プロジェク
ターにより力の方向を光の点滅パターンとして照射する．仮想力覚つき入力デバイスでその光をデコードし，力覚に変換する．

に，簡単な実験を行った．利用者はアイマスクを装着し，指で保持したアクチュエーターの牽引する方向に曲がるようにする．たとえば廊下の角に来た時に右に曲がるか左に曲がるかを仮想力覚によって支持する．今回の実験では，直進する場合には力覚は提示しなかった．また方向の支持はウィザードオブウォ
ズ方式で，実験参加者を目視して必要なナビゲーショ
ン支持をワイヤレスで与えるようにした (図 8(左))．
実験の結果，視覚情報にたよらずとも歩行が可能で，適切な場所で曲がれることが分かった．

4.2

仮想力覚つき入力デバイス

他の応用可能性として，仮想力覚による入力デバ
イスが構想できる．もしスタイラスなどに仮想力覚を組み込むことができれば，アプリケーションによって牽引力や斥力を発生させることが出来る 8(右)．従来の力覚付き入力デバイスはスタイラス全体をロッドによって保持してたため作業範囲に制約があった
が，仮想力覚ではその制限がない．
図の例では，作業空間に力の場を動的に作り出している．DLP プロジェクターの照射光で力場を定義する．DLP プロジェクターは，色ごとに光の点滅パターンが異なるので，簡易な可視光通信装置として使うことができる．入力デバイスのフォトトラン
ジスターでこの点滅を受信し，色ごとにことなった力の方向を発生させれば，プロジェクターで照射する図形によって力場を定義することができる [12]．
たとえば，手術をする際のメスの動きを仮想力覚によってガイドするような応用が考えられる．患者の体表に力場をプロジェクションし，メスに光センサーと仮想力覚アクチュエーターを装備すれば，切開すべき場所を力覚として感じることができるよう
になる．

5

関連研究

他の仮想力覚でバイスとの比較

前述したように，回転体やクランク機構によって仮想力覚を生み出すデバイスが提案されている [14,- 95 -

量やサイズが大きなものとなっている．また，回転体は急激に回転数を変化させたり逆転させることができない．このことにより，これらの装置では単方向の一定量の仮想力覚を作り出すことができても，その方向を逆転させたり，力覚量を制御することが難しい．これに対して，本論文で提案しているデバ
イスはより単純な構造ながら仮想力覚を提示することが可能で，既存事例から大幅に小型軽量化されている（重量比で約 40 分の 1) 点が利点と言える．
また，[2] では評価実験の結果，周期運動が 40 Hz以上になると仮想力覚が消失していくことを報告している．しかし，本論文のデバイスでは振動数が150 Hz 付近でも安定して仮想力覚が感じられた．したがって従来の回転体に基づく方式と本研究の構成
では仮想力覚の発生原理が異なっている可能性もある．これについては今後さらに精密な検証をすすめていきたい．
力覚によるナビゲーション

ActiveBelt はベルト状の装着型デバイスで，複数個のアクチュエーターの振動によって，利用者を誘導することができる [15]. 上述のように，Traxion
では方向を仮想力覚で提示することで，利用者を特定の方向に誘導することを試みている．
力覚提示素子触覚によるフィードバックは，タッチパネルに組み込まれたものが多く提案，実用化されている [4, 11].
われわれが利用している素子は，ゲームコントロー
ラー用に開発されたものである [1] が，他の原理による力覚提示素子でも仮想力覚が発生するかどうかは興味深い課題である．ワイヤーは機構を利用せずに触感フィードバックを発生させるものとしてアレ
イ状の超音波トランスデューサーによるものがある[6] が，本論文で示しているような力覚をつくりだ
すものではない．

6

結論・今後の課題

本論文では仮想力覚を生成する触覚アクチュエー
ター Traxion について報告した．振動子の駆動パターンを工夫することにより，仮想的な「力」を生成することが可能になった．評価実験によりこの効
果を複数の利用者によって確認した．また，仮想力
覚の大きさも評価し，約 30 g 相当の力が生成されていると推定した．このデバイスは既存事例の力覚装置と比較して重量比で約 1/40 であり，インタラ
クションデバイスとしての利用可能性が高まった．
仮想力覚は人間の刺激と知覚の関係に基づいて力覚を「錯覚」として感じさせるものであり，物理的な力は発生していない．また，従来の機構部品による力覚フィードバックのように，利用者の行動を束縛するほどの大きな力を作り出すことはできない．
一方，振動フィードバックとは異なり，明確に力の方向を感じることができる．したがって，従来の力WISS 2013

覚フィードバックとも振動フィードバックとも異なるタイプの触覚フィードバックだということができる．例えば，歩行者ナビゲーションで移動方向に牽引するアプリケーションを振動フィードバックで実現しようとすると，「右」「左」などの方向を特定の振動パターンと対応づける必要があり，利用者がこの対応づけを記憶理解しなければならない．仮想力
覚ではこのようなマッピングが不要で直接方向を感じさせることができる．
現状では既存の特定のタクタイルアクチュエー
ターの駆動パターンによって力覚が発生することを確認した段階だが，他の振動子でも同じ効果が発生するかどうかは興味ある課題である．実際，tactor [8]と呼ばれるコイル型の振動子でも力覚発生量は弱いながらも類似の仮想力覚が発生することを確認した．
また，今回利用したアクチュエーターは，上下方向に非対称の構造を持っており，上方向の力覚と下方向の力覚の量が若干異なるように感じられる．今後は各種のアクチュエーターの駆動信号と加速度を計測し，仮想力覚の発生原理をより厳密に確認していきたい．
一方，評価実験の結果，一次元の仮想力覚デバイ
スを単純に組み合わせても，合成力覚を作り出すことができないことが分かった．これについても振動子の運動や加速度を解析し，可能性を探求していきたい．
アプリケーションとして，DLP プロジェクター
による可視光通信により，プロジェクションされた
平面に容易に力場を形成できることを示した．これ
を仮想力場と呼ぶ．この発想を発展させると，各種のサーフェスコンピューティングにおいて，投影されている物体と現実のインタラクティブデバイスの間に引力や斥力を作り出すようなインタフェースが可能になる．また，現実の物体に投影した場合には，その物体の解析結果と仮想力場が対応するような応用が可能になる．たとえば，サーモカメラで撮影した温度映像から，温度勾配を力覚として感じるようなインタフェースや，手術の際のメスの力覚によるナビゲーションなどが考えられる．

D. Tan. GyroTab: a handheld device that provides reactive torque feedback. In Proceedingsof the SIGCHI Conference on Human Factors
in Computing Systems, CHI ’12, pp. 3153–3156,
2012.
[4] M. Fukumoto and T. Sugimura. ActiveClick:
Tactile Feedback for Touch Panels. In CHI 2001
summary, pp. 121–122, 2001.
[5] Y. Hirata and M. Sato. 3-dimensional Interface
Device For Virtual Work Space. In IEEE/RSJ
International Conference on Intelligent Robots
and Systems, pp. 889–896, 1992.
[6] T. Iwamoto, M. Tatezono, and H. Shinoda.
Non-Contact Method for Producing Tactile Sensation Using Airborne Ultrasound. In Proc. EuroHaptics 2008, Vol. 5024 of LNCS, pp. 504–513.
Springer, 2008.
[7] H. Iwata. Artificial reality with force-feedback:development of desktop virtual space with compact master manipulator. SIGGRAPH Comput.
Graph., 24(4):165–170, 1990.
[8] T. Labs. Haptuator Mark II Product specification. http://www.tactilelabs.com.
[9] M. Minsky, O. young Ming, O. Steele, J. Frederick P. Brooks, and M. Behensky. Feeling andseeing: issues in force display. SIGGRAPH
Comput. Graph., 24(2):235–241, 1990.
[10] N. Nakamura and Y. Fukui. Development ofFingertip Type Non-grounding Force Feedback
Display. In EuroHaptics Conference, 2007 andSymposium on Haptic Interfaces for Virtual
Environment and Teleoperator Systems. World
Haptics 2007. Second Joint, pp. 582–583, 2007.
[11] I. Poupyrev, S. Maruyama, and J. Rekimoto.
Ambient touch: designing tactile interfaces forhandheld devices. In ACM UIST 2002, pp. 51–
60, 2002.
[12] J. Rekimoto. SenseableRays: Opto-Haptic Substitution for Touch-Enhanced Interactive Space.
In CHI ’09 extended abstracts. ACM, 2009.
[13] S. Stevens. On the Psychophysical Law. Psychological Review, 64(3):153–181, 1957.
[14] Y. Tanaka, M. Sakai, Y.Khono, Y. Fukui, J. Yamashita, and N. Nakamura. Mobile Torque
Display and Haptic Characteristics of Human
Palm. In ICAT 2001, pp. 115–120, 2001.
[15] K. Tsukada and M. Yasumura. Activebelt:
Belt-type wearable tactile display for directionalnavigation. In in Lecture Notes in Computer
Science. Springer-Verlag GmbH, Oct 2004, pp.
384–399. Springer, 2004.

参考文献[1] ALPS.
Alps Electric Press Release Force
TM
Reactor . http://www.alps.com/e/news release/2005/0608 01.html, 2008.
[2] T. Amemiya, H. Ando, and T. Maeda.
Phantom-DRAWN: direction guidance using
rapid and asymmetric acceleration weighted by
nonlinearity of perception. In Proceedings ofthe 2005 international conference on Augmented
tele-existence, ICAT ’05, pp. 201–208, 2005.
[3] A. Badshah, S. Gupta, D. Morris, S. Patel, and[16] 雨宮 智浩, 杉山 久. ”牽引力錯覚を利用した牽引式羅針盤による視覚障がい者の歩行誘導の評価”.
信学技報, 109(27, WIT2009-43):215–220, 2009.

- 96 -WISS2013

HandyScope：引き出しジェスチャを用いたテーブルトップ用遠隔地操作
手法
栗原 拓郎

三田 裕策

大西 主紗

志築 文太郎

田中 二郎∗

概要. 大型のマルチタッチテーブルトップでは，ユーザはその大きさのため遠隔地に手が届かず，操作が困難である場合がある．そのような場合，ユーザはその領域に手が届く位置まで移動することを求められる．そこで我々は遠隔地操作手法である HandyScope を示す．HandyScope では，ユーザは手元から遠隔地を操作することができる．また，ユーザは手元と遠隔地の間にてオブジェクトを移動させることができる．加えて，HandyScope の起動，操作には引き出しジェスチャを用いることにより，ユーザは従来のマルチタッチ操作と競合することなく素速くポインティングを行うことができる．我々は HandyScope の性能を測るために従来のタッチ操作と比較実験を行い，遠隔地を選択する場合 HandyScope は有用であること
及び，オブジェクトまでの距離が遠くなると HandyScope がより有用な手法であることを確認した．

1

はじめに

大型のマルチタッチテーブルトップを使用する際，ユーザはテーブルトップの周りに立ち，その位置からタッチ操作を行う．このタッチ操作を行う範囲について，ユーザは自身の位置から 34cm 以内の位置においてその 90%を行っていると Toney らは述べており [11]，それ以上遠くに位置する手の届かない
領域（遠隔地）に対してタッチ操作を行うことは困難である．
そこで我々は遠隔地操作手法である HandyScopeを示す．HandyScope では，ユーザは 2 個の円形のウィジェットを用いて遠隔地を操作することができ
る．2 個のウィジェットとは，遠隔地へ送り操作範囲を決定するサークル（scope）と手元において操作するためのサークル（handler）である．scope 内の領域は handler にも表示され，ユーザは handlerに表示された領域を操作することにより遠隔地を操作することができる．また，ウィジェットを経由す
ることにより，ユーザは手元と遠隔地の間にてオブジェクトを移動させることができる．加えて，本手法では Control-Display（CD）比を動的に変更できるため，ユーザは素速く目標領域まで scope を移動させること（ポインティング）ができる．
本手法では吉川らの提案する，両手を用いた引き出しジェスチャ[13] を本手法の起動及び scope の位置を決定するために使用する．引き出しジェスチャ
では，ユーザは別のデバイスを使用せずに、タッチ操作のみにて使用することができる。また，引き出∗

Copyright is held by the author(s).
Takuro Kuribara and Yusaku Mita, 筑波大学大学院シス
テム情報工学研究科 コンピュータサイエンス専攻, Kazusa
Onishi, 筑波大学 情報学群 情報科学類, Buntarou Shizuki
and Jiro Tanaka, 筑波大学 システム情報系.

- 97 -

しジェスチャは従来のマルチタッチ操作と競合しないため，複数ユーザが同時に使用できる．テーブル
トップでは複数ユーザが同時に作業することも多く，
本手法はその際にも有用である．

2

関連研究

テーブルトップ環境における遠隔地ポインティング
手法については多くの研究がなされている．Parker
らは，スタイラスの先端の影を用いてポインティン
グを行う手法を示した [9]．また Banerjee らは片手の指を指す動作によってポインティングを行う手法を示した [2]．これらの研究は，ポインティング手法を実現するために追加のデバイスが必要となる．
一方，我々の手法は追加のデバイスを用いる必要がない．また，マルチタッチテーブルトップ環境における仮想マウスを提案した研究もある [4, 8]．これらの研究では手の接触形状を認識するマルチタッチ
テーブルトップが必要である．一方，我々の手法では手の接触形状を認識する必要がないため，複数のタッチ点を検出可能なマルチタッチテーブルトップ
のみにより実現できる．
また，両手を用いたポインティング手法の研究も行われている．I-Grabber[1] はマルチタッチインタ
ラクションにより操作するウィジェットである．両手を用いたポインティングを採用している点において我々の手法と同様であるが，我々の手法では CD 比を動的に変更でき，かつポインティング開始からポインティング先の決定までを一連のジェスチャにて行うことができる．そのため，ユーザは素速く正確にポインティングを行うことができる．所らは 2 つの加速度センサを用いた両手によるポインティング
手法を示した [10]．また，Malik らは画像処理を用いた両手によるポインティング手法を示した [7]．こWISS 2013

図 1. HandyScope の起動及び操作方法．a）2 本の指を置く，b）1 本の指にて 2 本の指の間を横切ることにより起動，
c）HandyScope の操作
Pi(x,y)れらの研究と異なり，我々の手法ではテーブルトッ
プを対象に，タッチを用いた両手によるポインティングを行う．そのため他のデバイスを必要としない．

3

G0

Gi-1(x,y)

S0

Si-1

Pi-1(x,y)

Vi-1

Gi(x,y)⊿VSi

図 2. サークルの位置

HandyScope

本節では，HandyScope の操作手法及び，HandyScope を用いたオブジェクトの操作手法について述べる．

3.1 起動及び操作方法
HandyScope の起動及び操作方法を図 1 に示す．
ユーザは最初に非利き手の 2 本の指（base-fingers）
をテーブルトップ上に置く（図 1a）．次に，利き手の 1 本の指（pull-finger）により base-fingers の間（base-segment）を横切る操作を行う（図 1b）と，
handler が pull-finger を中心とした位置に表示される．同時に，base-segment の中心点と pull-fingerの間（vector-pulled）の半直線上に scope が表示される．ユーザが vector-pulled を変更すると，その変更に応じて scope の位置が変更される．図 1c にHandyScope を用いた操作の様子を示す．HandyScope は base-fingers をテーブルトップから離すこ

3.3 CD 比の動的な変更
CD 比は base-segment の長さにより変更される．
図 3 に CD 比と base-segment の長さの関係を示す．
ユーザは CD 比の変更を行いながらポインティングを行うことができるため，大きな CD 比による大まかな操作と小さな CD 比による細かい操作を動的に切り替えて操作することができる．例えば，図 4 に示すように大きな CD 比により素早く scope を移動させ，小さな CD 比により微調整を行うことがで
きる．

CD比
Large

Small

図 3. CD 比と base-segment の長さの関係とにより終了される．

3.2 scope の位置の決定
base-segment が生成されてから i フレーム後における scope の位置 Pi は以下の式により決定される．
ここで S0 ，Si は図 2 に示すように base-segment の長さであり，S0 は base-segment が生成された時の長さ，Si は base-segment が生成されてから i フレー
ム後の長さである．また，Gi は base-segment の中心であり，Vi は Gi から pull-finger までの vectorpulled である．また，α は定数であり，ki は CD 比を表す．base-segment を拡大すると CD 比を表す kiが大きくなり，逆もまた同様である．すなわち，利き手もしくは非利き手を移動させることにより V を変化させると，その変位である ∆V i に基づき，scopeの位置が変化する．
i!

Pi = G0 +kj ∆Vj ,j∆Vi = Viki = αVi−1 ,
|Si |
.
|S0 |

(1)

- 98 -

図 4. CD 比の動的な変更による scope の操作．a）大まかな移動によるポインティング先の決定．b）細かな移動による精密なポインティング先の決定

3.4

サークルを経由した遠隔地の操作

図 5 に示すように，handler 内には scope 内の領域が表示されている．また，handler 内での操作は
全て scope 内に適用される．図 5a に遠隔地のオブジェクトを拡大縮小している様子を，図 5b にオブジェクトを回転している様子を示す．遠隔地に対する操作を全て handler 上にて行うことができるため，ユーザは自身が遠隔地に移動して操作することや，遠隔地のオブジェクトを手元に移動させることなく，遠隔地のオブジェクトを操作することができる．

HandyScope：引き出しジェスチャを用いたテーブルトップ用遠隔操作手法

3.8 HandyScope のメリット
HandyScope では，ユーザは非利き手の 2 本の指により CD 比を変更し，この 2 本の指の中心点と利図 5. 遠隔地のオブジェクトの操作．a）オブジェクトの拡大縮小，b）オブジェクトの回転

3.5 サークル間のオブジェクトの移動
handler 内のオブジェクトをタッチしてサークル外までドラッグ操作を行うと，遠隔地のオブジェク
トが手元に移動する．実際に移動している様子を図6a に示す．同様に，図 6b に示すように手元にあるオブジェクトを handler 内にドラッグすることにより遠隔地にオブジェクトを移動させることができる．
これにより，遠隔地と手元の間においてオブジェク
トの移動を素早く行うことができる．

き手の指の間の相対位置によりポインティング先を決定する．ポインティング先には scope を，手元には handler を表示し，ユーザはこのサークルを介して遠隔地に対するインタラクションを行う．これにより Frisbee[6] 及び Dynamic Portals[12] と同様に遠隔地を手元から操作することが可能になる．また，
Frisbee では任意の位置から起動できず，Dynamic
Portals では操作対象としたい遠隔地の指定に他者の協力を必要とするが，HandyScope では，ユーザ
は自身の操作のみにて任意の位置から起動し，動的な CD 比を用いて操作対象としたい遠隔地を素速く決定することができる．

実験

4

HandyScope の性能を調査するために，比較実験を行った．比較実験では HandyScope（HandyScope 条件）及び従来の直接タッチ（タッチ条件）の性能をテーブルトップ上の典型的な操作である選
択，回転，拡大縮小の 3 種類のタスクにおいて比較した．
図 6. サークル間のオブジェクトの移動．a）遠隔地から手元にオブジェクトを移動，b）手元から遠隔地にオブジェクトを移動．

4.1

3.6 サークルの再移動
HandyScope の起動時は pull-finger を中心としてサークルが表示されるが，一度 pull-finger をテー
ブルトップから離すと，handler 内に対する操作はscope 内に対する操作として扱われる．そのため，
図 7 に示すように再度サークルを移動させる場合には handler の中央ではなく，枠をドラッグする．これにより，scope の位置を移動させることができる．
3.7 サークルの大きさの変更
handler の枠をピンチ操作することにより．サー
クルの大きさを変更することができる．図 8 にサークルの大きさを変更している様子を示す．これにより，遠隔地の大きなオブジェクトを操作したい時や小さな範囲のみを操作したい時に対応することができる．

図 7. サークルの再移動

被験者及び実験環境

被験者は HandyScope を使用したことの無い 10
名（20 歳から 24 歳の大学生及び大学院生）であり，
右利き 9 名，左利き 1 名であった．実験環境を図 9に示す．実験に用いたテーブルトップは，画面サイズが 147cm 80cm の 60 インチディスプレイ（パイオニア社, PDP-607CMX1 ）に PQLab 社のマル
チタッチフレーム（PQ Lab，Multi-Touch G3 2 ）を装着することによりマルチタッチ機能を付したものである．なお，テーブルトップに関する幾つかの研究 [3, 5, 14] において，テーブルトップの高さを91cm から 105cm としていたため，本実験ではテー
ブルトップの高さをその範囲内である 93cm とした．
また，初期の CD 比にてテーブルトップの端までポ
インティング可能となるように式 1 における α を 12
とした．

4.2

実験手順

被験者には，選択タスク，回転タスク，拡大縮小
タスクをこの順に課した．タスクは，テーブルトッ
プ上でのポインティング手法を提案した研究 [2] に倣ったタスクである．各タスク前には，本番と同じタスクを本番の 1/4 の量だけ練習タスクとして課した．各タスクを行う際には，操作条件間の順序効果の打ち消しを狙い，被験者を HandyScope 条件を先

図 8. サークルの大きさの変更

1
2- 99 -

http://pioneer.jp/biz/karte/PDP-607CMX.html
http://multi-touch-screen.com/product g3.html

WISS 2013

4.3

被験者毎の所要時間において対応のある t 検定を行った結果，HandyScope 条件における操作が有意に速かった（t(9) = 2.72, p = .011 < .05）．
6000

所要時間（ms）に行う者とタッチ条件を先に行う者の 2 組に分けた．
被験者には全てのタスクを終了した後にアンケートに回答して貰った．なお，被験者 1 人あたりの実験
時間が約 1 時間半となったので，拘束時間に対する謝礼を渡した．
選択タスク

被験者には様々な位置に表示されるオブジェクトを選択して貰った．
まず，被験者は各試行の開始前にテーブルトップの短辺の中心（すなわち図 9 中の被験者の足元の床に，黒色のビニールテープにて示されている場所）に立つ．この状態から，テーブルトップ上のいずれかの提示位置に表示されるオブジェクトを選択する．
なお，試行の開始前に開始点及びオブジェクトは表示されている．
テーブルトップ上に表示される開始点及びオブジェクトの提示位置を図 10 に示す．
HandyScope 条件では，被験者は開始点上において HandyScope を起動させることにより試行を開始する．次にオブジェクトに scope を合わせ，オブジェクトをタップする．オブジェクトがタップされると 1 回の試行が終了し，フィードバックとしてビープ音が発生する．タッチ条件では，被験者は開始点をタップすることにより試行を開始する．次に表示されたオブジェクトに手が届く位置まで移動して，オブジェクトをタップする．
オブジェクトの提示位置

106.3
86.9

15°

5000

HandyScope条件
タッチ条件

4000
3000
2000
1000
0

選択タスク

回転タスク

拡大縮小タスク

図 11. 各タスク毎の 1 試行の所要時間

4.4

回転タスク

被験者には様々な提示位置に様々な角度にて表示されるオブジェクトを回転させて，目標（ドック）に合わせて貰った．ドックの表示位置をオブジェク
トと同位置，表示角度をオブジェクトと異なる角度とした．開始点及び提示位置，試行の開始方法は選択タスクと同じである．
HandyScope 条件では，被験者は HandyScope を使用してオブジェクトを回転させてドックに合わせる．オブジェクトとドックの角度が等しく（誤差 ±5 度以内）なるとオブジェクトの縁が赤色になる．この状態において操作を終了すると 1 回の試行が終了
し，フィードバックとしてビープ音が鳴る．タッチ
条件では，表示されたオブジェクトに手が届く位置まで移動して操作を行う．
本実験における独立変数は，開始点からドックまでの距離（86.9，106.3cm），開始点からドックまでの角度（ 15，0，15 度），ドックの大きさ（5.8，
7.7cm），回転角度（ 45，45 度），操作条件（HandyScope，直接タッチ）である．被験者は各独立変数の組み合わせにおいて試行を 2 回ずつ，合計 92 試
行（2 2 3 2 2 2）を行った．また，操作
条件以外の試行の順序はランダムであった．

開始点

図 9. 実験環境

実験結果

図 10. 開始点及び提示位置

両操作条件における 1 試行の所要時間を図 11 の中
央 2 つのグラフに示す．HandyScope 条件では所要時間は 4444ms，タッチ操作では所要時間は 4520msであった．被験者毎の所要時間において対応のある
t 検定を行った結果，操作手法による所要時間に有
意差はなかった（t(9) = .267, p = .397 > .05）．

本実験における独立変数は，開始点からオブジェクトまでの距離（86.9，106.3cm），開始点からオブジェクトまでの角度（ 15，0，15 度），オブ
ジェクトの大きさ（3.9，5.8，7.7cm），操作条件（HandyScope，直接タッチ）である．被験者は各独
立変数の組み合わせにおいて試行を 3 回ずつ，合計
108 試行（2 3 3 2 3）を行った．また，操作条件以外の試行の順序はランダムであった．

4.5

実験結果

両操作条件における 1 試行の所要時間を図 11 の左 2 つのグラフに示す．HandyScope 条件では所要時間は 1715ms，タッチ条件では 1943ms であった．

- 100 -

拡大縮小タスク

被験者には提示位置に表示されるオブジェクトを拡大縮小させて，ドックに合わせて貰った．ドック
はオブジェクトと同位置に異なる大きさで表示される．開始点及び提示位置，試行の開始方法は選択タ
スクと同じである．
HandyScope 条件では，被験者は HandyScope を使用してオブジェクトを拡大縮小してドックに合わHandyScope：引き出しジェスチャを用いたテーブルトップ用遠隔操作手法

実験結果

両操作条件における 1 試行の所要時間を図 11 の右 2 つのグラフに示す．HandyScope 条件では所要時間は 4438ms，タッチ条件では所要時間は 4278msであった．被験者毎の所要時間において対応のある
t 検定を行った結果，操作条件間における所要時間に有意差はなかった（t(9) = .935, p = .187 > .05）．

4.6

実験結果の考察

上述のように，選択タスクにおいては HandyScopeを使用した操作が有意に速く，回転及び拡大縮小タ
スクにおいては有意差が現れなかった．この結果より遠隔地を選択する場合，HandyScope は有用であると言える．
一方，回転及び拡大縮小タスクにおいて操作条件間に有意差が見られなかった原因として，HandyScope の再起動に時間がかかることが挙げられる．
実験において，被験者がオブジェクトをドックに合わせたつもりで HandyScope を終了したが，実際には合っていないため試行が終了せず，再度 HandyScope を起動してポインティングを行う様子が見られた．直接タッチ操作ではユーザがオブジェクト付
近に移動して入力を行うため，再度入力を行う際に時間がかからないが，HandyScope は一度終了してしまうとポインティングを再び行う必要がある．これにより，HandyScope による回転及び拡大縮小タ
スクに時間がかかったと考える．
また，HandyScope は遠隔地を操作することを想定して設計されているため，より遠くの位置に対する操作では大きな差が出ることが予想される．
HandyScope が遠距離の操作に対して有用な手法であることを確認するため，それぞれのタスクにおけるオブジェクトまでの距離毎の所要時間を用いて，操作条件における距離による特性を調べた．この結果を図 12 に示す．また，各タスクの各距離において，操作条件による有意差を確かめるため，対応のある t 検定を行った．選択タスクにおいて，オブジェクトまでの距離が 106.3cm の試行（t(9) =3.13, p = .006 < .01）は，距離が 86.9cm の試行（t(9) = 2.16, p = .029 < .05）と比較して，操作条
件間における所要時間の差がより大きかった．回転タ
スクにおいて，オブジェクトまでの距離が 106.3cmの試行（t(9) = .772, p = .230 > .05）と距離が86.9cm の試行（t(9) = .357, p = .364 > .05）
は共に操作条件による有意性が現れなかったが，所
要時間は距離が 106.3cm の試行では HandyScope
条件の方が速く，距離が 86.9cm の試行ではタッチ
条件のほうが速かった．拡大縮小タスクにおいて，オブジェクトまでの距離が 3.9cm の試行（t(9) =1.48, p = .086 > .05）と距離が 106.3cm の試行（t(9) = .321, p = .378 > .05）は共に操作条件による有意性が現れなかった．これらの結果から，オ
ブジェクトまでの距離が遠くなると HandyScope が有用な手法であることが確認できた．
本実験のタッチ操作において，遠隔地のオブジェ
クトを操作する際，ユーザはテーブルトップの外周に沿って 2，3 歩の移動を行っていた．オブジェク
トまでの距離が遠くなると歩数が増えるため，操作
条件間の有意差がより大きくなると考える．
また，本実験では HandyScope の初期の CD 比を，テーブルトップの端までポインティング可能となるように設定したため，CD 比の変更を行う被験者はほぼ見られなかった．このため，CD 比の動的な変更について評価を得るためには，改めて詳細な調査を行う必要がある．

- 101 -

6000
5000

所要時間（ms）

せる．オブジェクトとドックの大きさが等しく（誤差 ± 4.8mm 未満）なるとオブジェクトの縁が赤色になる．この状態において操作を終了すると 1 回の試行が終了し，フィードバックとしてビープ音が鳴る．タッチ条件では，表示されたオブジェクトに手が届く位置まで移動して操作を行う．
本実験における独立変数は，開始点からドックまでの距離（86.9，106.3cm），開始点からドックまでの角度（ 15，0，15 度），ドックの大きさ（5.8，
7.7cm），ドックに対するオブジェクトの拡大・縮小（1.5 倍，0.67 倍），操作条件（HandyScope，直接タッチ）である．被験者は各独立変数の組み合わせにおいて試行を 2 回ずつ，合計 92 試行（2 23 2 2 2）を行った．また，操作条件以外の試行の順序はランダムであった．

HandyScope条件
タッチ条件

4000
3000
2000
1000
0

86.9 cm

106.3 cm

選択タスク

86.9 cm

106.3 cm

回転タスク

86.9 cm

106.3 cm

拡大縮小タスク

図 12. 各距離毎の 1 試行の所要時間

4.7

アンケート結果とその考察

それぞれのタスクにおける，HandyScope とタッチ操作のどちらの手法が好みであったかのアンケー
ト結果を図 13 に示す．
選択タスクにおいては全ての被験者が HandyScope
が好みであると答えた．また，拡大縮小タスクにおいては 8 人の被験者が HandyScope が好みであると答えた．この内全ての被験者がその理由として，
タッチ操作ではオブジェクトに手が届く位置まで移動する必要があるが，HandyScope はその場にて操作を行うことができるためと答えた．
回転タスクにおいては好みが別れた．2 名の被験者は回転操作に両手を用いることができるため，タッWISS 2013

好みと答えた人数（人）

チ操作のほうが好みであると答えた．また，別の 2名の被験者は base-fingers を常にテーブルトップ上に接触させることが大変であったと答えた．別の被験者 1 名は試行の失敗時における HandyScope の再起動は手間であると答えた．
拡大縮小タスクにおいてタッチ操作が好みと答えた被験者 2 名は，その理由として常に base-fingers
をテーブルトップ上に接触させることが大変であったと答えた．
そのため，今後は base-fingers をタッチパネル上から離しても遠隔地の操作を続けられるように，サークルを固定させる機能を実装する．
10
HandyScope条件

8

タッチ条件

6
4
2
0

選択タスク

回転タスク

拡大縮小タスク

図 13. 手法の好みのアンケート結果

5

議論：引き出し方向

引き出しジェスチャは図 14 に示すように 2 種類の引き出し方向が考えられる．そこでどちらの引き出し方向が HandyScope に適しているかを調べるために，4.3 節に挙げた選択タスクを著者らが行った．その結果，図 14b の引き出し方向による操作が
図 14a の引き出し方向による操作よりも所要時間が短くなった．所要時間に違いが生じた理由として，
図 14a の引き出し方向では handler と scope 間の視線の移動距離が大きくなり，ポインティングが困難になることが考えられる．このため，HandyScopeの引き出し方向を図 14b の方向に決定した．今後
は被験者実験を行い，この妥当性を評価する予定で
ある．
(a)

6

まとめ

(b)

図 14. 引き出し方向

我々は新たな遠隔地操作手法として HandyScopeを示した．HandyScope を用いることにより，ユー
ザは 2 種類の円形のウィジェットを用いて遠隔地を素早くポインティングできる．ポインティング後は，遠隔地の直接操作や遠隔地と手元間におけるオブジェ
クトの移動が可能である．
評価実験の結果，遠隔地を選択する場合 HandyScope は有用であること及び，オブジェクトまでの距離が遠くなると HandyScope が有用な手法となることが確認できた．アンケートからは HandyScope
がユーザに好まれることを確認した．今後は，basefingers をテーブルトップから離しても遠隔地の操作- 102 -を続けられるように，サークルを固定させる機能を実装する．また，CD 比を動的に変更できることの詳細な評価や，オブジェクトの移動について評価を行う．さらに，複数のディスプレイを連携させた際の本手法の有用性についても調査していきたい．

参考文献[1] M. Abednego, J.-H. Lee, W. Moon, and J.-H.
Park. I-Grabber: expanding physical reach in alarge-display tabletop environment through theuse of a virtual grabber. ITS ’09, pp. 61–64.
[2] A. Banerjee, J. Burstyn, A. Girouard, and
R. Vertegaal. Pointable: an in-air pointing
technique to manipulate out-of-reach targets ontabletops. ITS ’11, pp. 11–20.
[3] N. Banovic, F. C. Y. Li, D. Dearman, K. Yatani,
and K. N. Truong. Design of unimanual multifinger pie menu interaction. ITS ’11, pp. 120–
129.
[4] T. Bartindale, C. Harrison, P. Olivier, and S. E.
Hudson. SurfaceMouse: supplementing multitouch interaction with a virtual mouse. TEI ’11,
pp. 293–296.
[5] G. Furumi, D. Sakamoto, and T. Igarashi.
SnapRail: a tabletop user interface widget foraddressing occlusion by physical objects. ITS’12, pp. 193–196.
[6] A. Khan, G. Fitzmaurice, D. Almeida, N. Burtnyk, and G. Kurtenbach. A remote control interface for large displays. UIST ’04, pp. 127–136.
[7] S. Malik, A. Ranjan, and R. Balakrishnan. Interacting with large displays from a distancewith vision-tracked multi-finger gestural input.
UIST ’05, pp. 43–52.
[8] J. Matejka, T. Grossman, J. Lo, and G. Fitzmaurice. The design and evaluation of multifinger mouse emulation techniques. CHI ’09, pp.
1073–1082.
[9] J. K. Parker, R. L. Mandryk, and K. M. Inkpen.
TractorBeam: seamless integration of local andremote pointing for tabletop displays. GI ’05,
pp. 33–40.
[10] Y. Tokoro, T. Terada, and M. Tsukamoto. A
pointing method using two accelerometers for
wearable computing. SAC ’09, pp. 136–141.
[11] A. Toney and B. H. Thomas. Applying reach indirect manipulation user interfaces. OZCHI ’06,
pp. 393–396.
[12] S. Voelker, M. Weiss, C. Wacharamanotham,and J. Borchers. Dynamic portals: a lightweight
metaphor for fast object transfer on interactive
surfaces. ITS ’11, pp. 158–161.
[13] T. Yoshikawa, B. Shizuki, and J. Tanaka.
HandyWidgets: local widgets pulled-out fromhands. ITS ’12, pp. 197–200.
[14] H. Zhang, X.-D. Yang, B. Ens, H.-N. Liang,
P. Boulanger, and P. Irani. See me, see you:a lightweight method for discriminating user
touches on tabletop displays. CHI ’12, pp. 2327–
2336.

WISS2013

ライフログによる記憶拡張のための探索手法とその実践
中村 聡史∗
概要. 技術の進歩により，短期作業記憶に格納したものの忘却してしまうような情報もデジタルカメラなどを利用することによって一部記録できるようになってきた．また，記録を何度も閲覧することにより長期記憶化することも可能となっている．近い将来，見たこと，聞いたこと，体験したことをすべて記録できるようになると期待される．しかし，記憶を記録できるようになったとしても，記録を検索して記憶として引き出すことができないようでは折角の記録も役に立たない．本稿では，デジタルカメラを利用してユーザ
自身のタイミングで記録をする一人称視点での主観写真ライフログに注目し，写真ベースの膨大なライフ
ログを効果的に活用する探索手法を提案および実装する．また，10 年近いライフログの利活用から見えてきた利点や問題点などを整理する．

1

はじめに

人間は記憶して，過去を振り返ることが可能な生き物である．
Atkinson ら [1] の二重貯蔵モデルによると，人間の記憶過程をまず入力刺激を瞬間的に記憶しすぐに忘れる感覚記憶，そして感覚記憶から選択的に入力され 20〜30 秒程度保持することが可能な短期作業
記憶，短期作業記憶から処理を行った結果を格納す
る長期記憶とに分類される．
短期作業記憶は 20〜30 秒しか保持することができないため，多くの場合情報が忘却されていってしまい，思い出すことができなくなる．長期記憶化す
ることによって思い出すことが可能となるが，長期記憶化にはリハーサルを繰返すことや，深い意味的処理を施すなどすることが必要であり，長期記憶を行うことは容易ではない．
ここで，短期作業記憶を長期的に記憶（記録）する方法として，デジタルカメラなどの記録装置を使う方法が考えられる．デジタルカメラにより，旅行で見かけた素晴らしい風景や現地で出会った印象的な人々，道端で出会った印象的な看板や参考になる
講演スライド，配布資料に書き込んだメモや田舎の
バス停の時刻表，日々食している料理からお店で食べた印象的な料理，友人と会うときに着ていた服や子どもの成長記録など，見て興味をもった様々なものを記録することが容易な時代になっている．つまり，すぐに揮発してしまうような短期作業記憶に記
憶される情報をデバイス上に記録することによって，いつでも引き出すことが可能となる．
ここで，記憶を記録し，記録から記憶を呼び覚ますことを目的として個人の一人称視点および興味でデジタル写真を撮影することを，本稿では主観写真∗

Copyright is held by the author(s).
明治大学 総合数理学部

図 1. 探している写真はどこに？

ライフログ[2] と呼び，記憶されたデジタル写真を
ライフログ写真と呼ぶ．著者は 1998 年頃より 2005
年までは何らかのイベント時にデジタル写真を撮影し，2005 年 6 月 2 日から現在に至るまでは毎日ライフログ写真を撮影および記録しており，2013 年
7 月 24 日時点で合計 254,899 枚となっている（約349GB）．緯度経度が付与されたものが 193,545 枚，
Google Picasa によって顔認識されている人の数が1,398 人，顔の数が 71,054 個となっている．
デジタル写真は手軽に撮影することができるため
主観写真ライフログが容易になっているにも関わらず，一般的になっていない．その一番の理由はそもそも記録や管理するのが面倒というものであるが，それ以外にも検索が難しいという問題がある．ライフログ写真には一般的にテキスト情報が付与されていないため，キーワード検索は困難である．また，ユーザは過去の事になればなるほど記憶が定かではなくなっており，目的とするライフログ写真の撮影
場所や撮影時間，一緒にいた人の名前などを忘れているだけでなく，間違って記憶していることも多い（図 1）．さらに，検索条件を明確にすることが難しいという問題もある．
そこで我々は，検索の問題を解決するため，時空間と人間関係を利用し，絞り込み探索を行うことで，目標とするライフログ写真への到達を支援する探索- 103 -WISS 2013

手法を実現する．また，ライフログ写真を長期記憶化するための受動的閲覧手法を実現する．さらに，長期的な利用からライフログ写真における人間関係がどの程度利用可能かといったことについて議論を行う．

2

写真ライフログ

ライフログにデジタル写真を使うメリットは，静止画であるため一覧化しやすく，現在発売されているデバイスを利用するだけで手軽にライフログを実践することが可能であることなどである．ここで，写真ベースのライフログは，主観的なライフログ（主観写真ライフログ）と客観的なライフログ（客観写真ライフログ）に大別される [2]．主観写真ライフ
ログとは，撮影時においてユーザの明確な意図があり，ユーザのタイミングと視点で空間を切りとるものである．
客観写真ライフログとは，システムにより自動記録されるものであり，SenseCam などウェアラブル
カメラを利用した自動記録がそれに相当する．また，
ユビキタスホームなどでのユーザの記録も客観的ライフログといえる．SenseCam は首から下げて利用する客観写真ライフログ用のカメラであり，1 分間に 2 回または，センサ（照度，地磁気，加速度セン
サなど）で取得した外界の状況に応じて自動撮影されるようになっている．客観写真ライフログは自動撮影されるため，自然に撮影できることや，何らかの作業中に撮影できることなどメリットがある．一方，撮影するだけではユーザの視点が抜け落ちるため，後に活用しようと思った際に何をキーとして探したらよいかわからないなどの問題がある．
主観写真ライフログと客観写真ライフログの特性の違いについて詳細に分析した研究は存在しないが，Gurrin らは SenseCam を用いた客観写真ライ
フログによる 1 年間の記録（100 万枚）から無作為に1000 枚を抽出および分析している [5]．その結果，客観写真ライフログには腕や手がよく写っており，仕事中（24.6 ％）や運転中（16.2 ％），会話中（13.3％）などの写真が多く，人を自然に記録できるとしている．また，インドアの写真が 73.4 ％と多く，風
景写真は 1.1 ％とかなり少ないことを報告している．
さらに，29.9 ％の写真に人が写っていることを報告している．一方，著者の主観写真ライフログの中から 1000 枚を無作為に抽出して調査したところ，作業中の写真はほとんどないが，作業の後などに撮影したものや，他人が作業している様子や，他の人が会話している様子を撮影していたものが多かった．
また，65.6 ％がインドア，34.4 ％がアウトドアの写真であり 13.2 ％が風景写真であった．さらに，44.0％の写真に人が写っていた．単純な比較はできない
が，主観，客観ともに人が写っている傾向が高いといえる．

- 104 -

図 2. ライフログ（外部記憶）により記憶拡張

図 3. ライフログによる記憶のモデル

ここで，基本的に人間は画像を膨大かつ長期的に記憶することが可能である [7] ものの，Isola らの写真の覚えやすさに関する研究 [6] によると，写真のタイプごとに記憶の容易性が異なり，人を含んだ写真を最も覚えやすく，次に人の大きさのオブジェク
トが被写体となっている写真を覚えやすいのに対し，風景のような写真は綺麗であっても覚えにくい事がわかっている．つまり，写真ライフログでは，時空間をベースとしつつも，人間関係を効果的に利用した探索手法および，人を考慮した長期記憶化手法が有効になるのではと考えられる．
そこで，本稿ではこのような人間関係を中心としたライフログ探索を可能とする仕組みを実現する．
ここでは，ライフログ写真から人間関係を抽出および可視化し，対話的に探索可能とする．

3

ライフログの外部記憶化手法

先述の通り，短期作業記憶はすぐに失われてしまうものであり，長期記憶への定着も難しい．ここで，
主観写真ライフログを記憶として使う（図 2）と，図3 のように消去しない限り短期作業記憶へ何度も呼び出すことが可能となる．そこで，本稿ではライフ
ログを外部記憶として扱うために，短期作業記憶へと呼び出すための探索手法と，何度もユーザに提示
し，リハーサルを行えるようにすることで長期記憶に定着させるための受動的閲覧手法を提案する．

ライフログによる記憶拡張のための探索手法とその実践

3.1

人間関係を利用した探索

デジタル写真を撮影すると，撮影日時やカメラの
機種名，各種撮影情報などが EXIF 領域に自動記録される．また，最近では GPS 搭載のデジタルカ
メラも増えており．撮影場所情報も自動的に記録されるようになっている．さらに，Google Picasa やApple iPhoto などのように，写真ライブラリ内の写真に対する顔画像認識を行うソフトウェアも近年広がりを見せている．我々は，こうした撮影日時，撮影場所，被写体情報を写真とともに取り込み，デー
タベースに格納し，時間，空間，人間での検索を可能とする．
しかし，人の記憶は曖昧であり，数ヶ月，数年前のこととなると，目標とするライフログ写真をいつ撮影したのか，どこで撮影したのか，誰と撮影したのかといった事も正確に覚えていない．つまり，目標とするライフログ写真への到達も一筋縄ではいかない．ライフログ写真の検索および探索においては，
それを思い出すきっかけとなる柔軟な絞り込みと周辺情報提示が必要となる．
ここで，ライフログ写真として蓄積されているものは，ユーザ（撮影者）が見て切り取ったものであり，それぞれの写真に写っている人物を認識すると，ユーザからみた人物関係（主観的視点におけるソー
シャルネットワーク）が見えてくる．つまり，人を 1つのノードとし，同一の写真に写っている人には関係があるとみなしてその人物間（ノード間）にエッ
ジをはり，そのエッジがどのようにはられているかということを分析してクラスタリングを行うことで，
コミュニティを検出することが可能となる．そこで，
本稿ではある時空間での写真集合からすべての人間関係を抽出し，その人間関係を Newman 法 [3] によってハードクラスタリングした結果とともに提示することにより，人間関係を考慮した探索を可能とする．
なお，ハードクラスタリングした結果の人間関係をバネモデルを用いて提示し，提示されている人間
関係をもとに検索する手法を実現する．ここでバネ
モデルにおけるノード間の引力はユーザ間の親密性の高さに基づき，強さを変更している．また，人と人との間の親密性については，「同じ写真に共起していること」「同じ時分に共起していること」「同じ時間に共起していること」「同じ日に共起していること」という 4 パターンを用意し，その共起頻度によって計算している．

3.2

受動的閲覧による長期記憶への格納

近年，横長の液晶ディスプレイが広く普及している．横長のディスプレイは，動画を視聴する場合や，ゲームをする場合などには効果的であるが，作業を行なっている場合には，2 つのウィンドウを表示す
るには少し狭すぎ，1 つのウィンドウを表示するに- 105 -

は広すぎる．ここで，1 つのウィンドウのみを表示
するのであれば，画面の両端に余裕がある．
受動的閲覧による，外部記憶からの長期記憶化では，こうした画面の両端のスペースを有効活用し，利用者とライフログ写真との遭遇を促進し，その事自体が短期記憶のリハーサルとして働くようにする
ことによって，長期記憶化を狙うものである．受動的閲覧において，システムは特に人間にフォーカスを当て，任意の人間を取り出し，その人間を中心とした写真（その人間と一緒に居た場所や，居た時間を利用）中心とした n 件のライフログ写真をデータベースから取り出し，1 枚ずつ写真を上から下にス
クロールさせながらアニメーション提示するもので
ある．

4

実装

提案システムを Microsoft Visual C++を利用して，データベースに SQLite を利用して実装した．
また，サムネイル画像を必要に応じて自動生成することにより，20 万枚以上でも問題なく動作する仕組みを実現している．さらに，データベースやサムネ
イルはバックグラウンドで自動的に構築および生成されるため，初めて利用する際にも特に負荷なく利用可能である．システムは LifelogViewer という名前で Web 公開している1 ．
図 4 は，カレンダーインタフェース，地図インタ
フェース，人間関係ビューを利用して時間および空間を指定しながら目的とする食事のライフログ写真を探索している様子である．カレンダーインタフェー
スで表示月を変更している際に提示される人間関係
ビューから，まずどの月かを限定し，次に地図イン
タフェースを用いてズームし表示領域を限定することで提示される人間関係のクラスタを限定している．
さらに，そこから目的とする人が含まれるクラスタを指定して検索し，最終的に目的の写真にたどり着くことができている．図 5 は，ライフログの受動的閲覧手法を利用して，作業中にライフログを提示している様子である．

5

考察

時間，空間，人間関係を考慮して 20 万枚の写真
ライフログを扱える環境は限られている．Apple のiPhoto は 1 操作辺りに数十秒かかるため利用できず，Google の Picasa も頻繁に固まってしまうという問題が生じた．速度面は無視して，著者がこれまでに必要とした様々なライフログ探索について提案システムと Picasa の比較を行った．大きな違いは，
Picasa ではユーザは明確に場所や時間，被写体を選べる場合は効果的に目標とするライフログ写真を探しだすことができるものの，少しでも記憶が曖昧な
1

http://calendar2.org/

WISS 2013

図 4. 時空間と人間関係を利用した写真探索
図 6. 人間関係の変化

図 5. ライフログの受動的閲覧（画面右端）

場合には探すことが困難であるという点である．一方，提案システムでは，ユーザの記憶が曖昧な場合
であっても対象となる写真の発見が可能であり，検索達成率は高かった．
本手法によってある特定の月の人間関係がどうなるかを示したものが図 6 である．上段は，私が京都大学から明治大学へと転職前（2013/02）と，転職後（2013/04）で大きな違いが現れており，2013/04 では転職先の大学での学生が登場し密なネットワークを作っている事がわかる．また，2013/03 では，転職元や転職先の方々，京都の友人の方々などとの交流があったため，様々な広がりのあるコミュニティができている．下段は，WISS が開催される 12 月について，2010，2011，2012 年を比較したものである．2010 は右上に，2011 は左下に，2012 は下にそれぞれ WISS のコミュニティが形作られている．また，2010 年は WISS のコミュニティは独立しているが，2011，2012 年については他のコミュニティとの関係が深まっていることが分かる．これは，2011
年，2012 年の 12 月にそれぞれ開かれたニコニコ学会に WISS 関係者が関与しているためである．
クラスタリングにおいて，知人と解釈する度合い
を「同じ写真での共起」「同じ時分での共起」「同じ
時間での共起」「同じ日での共起」と 4 つ用意し比較した．様々な時空間でのクラスタリング精度について実際に運用することで比較してみたところ，2005
年までは「同じ日での共起」，2006 年〜2008 年に- 106 -

ついては「同じ時間での共起」，2009 年以降については「同じ時分での共起」と「同じ写真での共起」
が良い結果となっていた．これは，撮影頻度と，被写体として人間を選ぶ度合いとに深く依存しているのではないかと考えられる．実際，2005 年までは
撮影頻度は高くなかったが，2006 年から 2008 年については撮影頻度があがり，2009 年以降も撮影頻
度はこれまでと大きく変化していないものの，著者の撮影スタイルが変化していき人が被写体となっている量が増加したことも理由の 1 つとして考えられる．撮影頻度や撮影場所によってイベントを分離することが可能になれば，本問題は解決する可能性を秘めている．
受動的閲覧が作業の邪魔になるかどうかを調べるため，1 年以上の長期的な利用を実践した．その結果として，受動的閲覧の仕組みは，作業中はほとん
ど目に入らず，ふと気が緩んだ時に目に入る程度であり，著者自身は問題がなかった．むしろ，集中して作業をし，気を抜いた時に，知人の楽しげな写真や，娘や妻などの写真が目に入り，休憩時の癒やしとなっていた．また，受動的閲覧で提示される写真の中のグラフなどから着想を得て，講義資料に取り込んだこともあった．以上のことより，長期記憶に定着させるための方法として有効であったかは不明
であるが，少なくとも受動的閲覧は有効であった．
この 1 年間でライフログが役に立った事例は多数あるが，そこから選別したものは下記の通りである．

• 出産育児一時金請求書を記入する際に医療施設の名称＆住所が必要となった．妻と沖縄で一緒だった時に出生届を書いた事を思い出し，
地図 UI を開いて「沖縄」を指定．表示される人間関係 UI から妻の顔をダブルクリックし，
カレンダー UI に提示された写真の中から妻がベッドに座っている写真を発見．そういえばこの時だったと，その日の写真を一覧化し出生届＆出生証明の写真とその情報を発見．

ライフログによる記憶拡張のための探索手法とその実践• 転居先の水道代自動引落しの手続き時に，銀行への届け出サインが必要に．銀行での契約時以降サインを使った覚えがないため日本語
か英語か記憶が無い．写真の GPS 情報がずれているのか契約した場所で検索しても写真が見つからない．口座を使い始めたのは入籍時である事を思い出し，入籍日あたりを探索．
契約後に，妻と飲みに行ったお店の店長が人間関係ビューに提示され，ふとその事を思い出して周辺を探索．書類を発見し，日本語だったことを確認して記入．

• 耐震工事のためのオフィスの一時的な引っ越しをしていて，1 年後に戻ることになった時，「前のオフィスに時計ってありましたっけ？」「あったとしたらどんなのでしたっけ？」という話になり，数名の同僚と一緒に時計が写っている写真を受動的閲覧で過去に見かけたことを思い出し，場所を人間関係 UI を提示しながら過去に遡ることによって，木の枠のこんなダサい感じの時計であったことを発見．
他にも，契約解除時にすでに忘れてしまった IDを調べたり，田舎で運行本数が極端に少ないバス停
でカメラに運行表を記録させ後で活用したり，著者の妻が著者の友人に会った時にどのような服を着ていたかを探したりなど，その活用方法は様々である．
こうした探索は，時空間や人間関係があったからこそ可能となっているものが多い．また，受動的閲
覧によって，何度も任意の人が被写体となっている
写真と，その人の周辺の写真（一緒に作業した記録
や，一緒に摂った食事，その前後のスケジュールに関するものなど）が連続的に提示されているため，自然と長期記憶に定着し，その定着した「人」と「周辺の写真」から目的とする写真を探索可能となっているケースも多い．
一方，長期的な利用から得られた問題としては，まず忘れることができないという事が大きな理由としてあげられる．例えば，ある時まで恋愛関係にあった人との別れは，その別れの前までは幸せな記録として残していたのに，別れの後では辛いものとしてただ存在するだけである．ライフログ写真の受動的閲覧では，こういった辛い過去もどんどん提示されてしまう．こういった，忘れることができない何かをどうするかというのは，今後の大きな課題の 1 つである．
また，美術館内や映画館内など，撮影できない場
所は多数ある．こういった状況において，本人としては記録した覚えがあるのだけれど，実際には撮影および記録しておらず，探索しても見つからないということがある．そうした，存在しないライフログ（見つからない記録）をどう提示するかというのは
課題の 1 つである．

- 107 -

ライフログを長く続けていくと，ライフログが無いと困るというライフログ依存症をといえるのではと思えることが多々ある．例えば，すぐにデジタルカメラにて記録することができるため，無理覚える必要がなく短期作業記憶が劣化しているように感じることや，受動的閲覧で何度でも見るため，ある出
来事が遠い過去のはずなのについ最近であるかのよ
うに感じることなどである．こういった問題は，今後ライフログが世の中に広まると，社会問題となるのではと考えている．
先日，著者のパソコンの SSD が突如読み込めな
くなってしまい，最後にバックアップを取った日から，20 日間分のライフログデータが失われてしまった．このようなデータの損失は，現代の記憶喪失といえるかもしれない．こういった戻せない記録をどう保管するか，また補完するかといったことも大きな課題となるのではないだろうか．

6

関連研究

SmartWrite/SmartCalendar[9] は，写真・メモ
ベースのライフログであり，時空間をベースとした
写真の探索を可能としているが人間関係は考慮されていない．我々の手法は時間のみならず，空間や人間関係を考慮した閲覧および検索を可能としており，対象の柔軟な探索が可能である．
五味らは，時間，空間，人間関係の 3 者を利用したライフログ写真の閲覧手法を提案している [10]．
しかし，五味らの手法では，あらかじめ時間ベース
で全ての写真のクラスタリングを行なってイベントを抽出し，イベントにおける共起度をもとに人物のクラスタリングを行なっているため，任意の時間や場所を指定した動的なクラスタリングは行えない．
捧ら [8] も，時間，空間，人間関係を利用してライフログ写真を閲覧する手法を提案している．ここでは，写真における共起性とその前後の写真から，人物同士の親密度を計算し，クラスタリングを行うというものである．ただし任意の時空間を対象とはしていないうえ，計算コストが高く，リアルタイムの分析には不適である．
Facebook，mixi などの SNS の友人関係からソーシャルグラフを作る試みは多数研究されている [4]．
しかし，こうした研究では，グラフは明示的なリンク（フォロー，友達として登録など）を元にしている．一方，ライフログの中には明確な友人関係に関する情報は存在していない．また，こうした人間関
係は日々変化するものであり，関係が強まったり（他機関の知人から同僚へ，赤の他人から人生の伴侶へなど），関係が弱まったり（交際相手からただの知人へ，クラスメートから他大学の友人へなど）する．
我々は，ライフログ写真の中から 2 者間の関係性の強さを計算し，人間関係の変化を考慮しつつ，探索を可能とする手法を実現するものである．

WISS 2013

7まとめ

本稿では，主観写真ライフログの能動的探索および受動的閲覧手法を提案および実装し，その有効性について検討を行った．主観的な評価にすぎないが，長期にわたって継続利用しており，今まで到達できなかった探索を可能となり，主観写真ライフログの記憶拡張としての可能性を明らかにした．
システムは Web 公開および雑誌などで紹介されており，多数のダウンロードがある．今後は，主観
写真ライフログを長期にわたって継続しているユー
ザに依頼し，システムの継続的な評価を行う予定である．

謝辞[3] M.E.J. Newman：Fast algorithm for detecting
community structure in networks. In Physical Review. E 69 (2004).
[4] Ken Wakita, Toshiyuki Tsurumi: Finding community structure in megascale social networks,
Proceedings of the 16th international conferenceon World Wide Web, pp. 1275-1276 (2007).
[5] Cathal Gurrin, Alan F. Smeaton, Daragh Byrne,
Neil O’Hare, Gareth J. F. Jones, Noel O’Connor:
An examination of a large visual lifelog, Proc. of
AIRS’08, pp. 537-542 (2008).
[6] Isola, P., Xiao, J., Torralba, A., and Oliva, A:
What makes an image memorable? Proc. of the
24rd IEEE Conference on Computer Vision and
Pattern Recognition, pp. 145-152 (2011).
[7] Lionel Standing: Learning 10,000 Pictures, Quarterly Journal of Experimental Psychology, vol.25,
pp.207-222 (1973).

本研究は文部科学省科学研究費補助金若手研究（A）（研究代表者：中村聡史，#23680006）の助成を受けたものです．

[8] 捧隆二, 佃洸摂, 中村聡史, 田中克己: 時間・空間・人
物情報に基づくインタラクションによるライフログ
画像の探索手法の提案, DEIM Forum 2012 D9-4.

参考文献[9] 美崎薫: SmartWrite/SmartCalendar 手軽に書けるメモとメモと写真を見続けるカレンダー環境の提案，情報処理学会ヒューマンインタフェース研究会報告 2005(71), 71-76 (2005).

[1] Atkinson, R.C., Shiffrin, R.M: Human memory:
A proposed system and its control processes, The
psychology of learning and motivation (Volume2), pp.89-195 (1968).
[2] 中村聡史: 身近になったライフログ 〜パソコンに眠る数万枚の写真をどう活用すればよいか〜, 情報
処理 54(2), pp.142-149 (2013).

[10] 五味愛, 伊藤貴之：「何時，何処で，誰と」3 つのメタ情報に基づく個人写真ブラウザ, 芸術科学会論文誌, Vol. 10, No. 1, pp. 36-47 (2011).

未来ビジョン
人の記憶は曖昧なものであり，過去に見聞きしたものを思い出せないことは多い．忘れることは必ずしも悪ではなく，痛ましい出来事や，
友人知人との別れ，恐怖を覚えた出来事や，昔の彼女との辛い思い出など，思い出したくな
いことも多々あるであろう．しかし，思い出せないことによって失敗をしてしまうことも少なくない．
今後，技術の進歩により，ウェアラブルコン
ピューティングが今の携帯電話のように人々にとってありふれた普通のものとなり，また生活の中での視線検出技術の進歩や脳波測定技術の進歩などにより，主観的なライフログ写真の記録がより簡単になり，ライフログ写真のインデックスもより深いものになると期待される．
将来，見聞きしたものを全て外部記憶に記録- 108 -

し，記録したものを検索などにより取り出すことも可能となるであろう．
つまり，忘れることができなくなる時代が到来することになる．もちろん，そうしたデバイスを使わないという選択しはありえるだろう．
しかし，記憶拡張された人と記憶力という面で圧倒的に差が広がってしまい，嫌々ながらもそうしたデバイスを使うユーザが増えるのではと考えられる．
本研究はこうした忘れることができなくなる
ことは，どういったメリットがあり，どういったデメリットがあるのかということを，実践的に取り組むものである．また，人の様々な記憶の仕組みとの関係を考えていくことにより，
ライフログによる記憶拡張がどのように記憶を変えていくのか，社会を変革させていくのかについて考えるものである．

WISS2013

EpisoPass: エピソード記憶にもとづくパスワード管理
増井 俊之 ∗
概要. 忘れる可能性が低いエピソード記憶にもとづく秘密の質問を使って強力なパスワードを生成/管理するシステム「EpisoPass」を提案する．EpisoPass は，ユーザが作成した秘密の質問への回答にもとづいてシード文字列を換字することによってパスワードを生成する．シード文字列や回答のバリエーションにより異なるパスワードが生成されるので様々なサービスに対して異なるパスワードを生成できることに加え，シード文字列を逆計算することにより既存のパスワードの管理もできる．適切な運用により，パスワードに関連するあらゆる情報を秘密にすることなく強力なパスワードの生成/管理が可能である．

1

はじめに

個人認証のためにパスワードが現在広く利用されている．パスワード認証には多くの問題があることが知られているが [21]，今後も長期にわたって利用され続けると予想されるため [8]，問題点を認識しつつ適切に運用するための工夫が必要である．
パスワードの長期的記憶が難しいことはパスワー
ド認証の大きな問題点のひとつである．安全に運用するためにはパスワードはランダムで長い文字列であることが望ましいが，そのようなものを頭の中に記憶しておくことは難しい．また複数のサービスを利用する場合，サービスごとに異なるパスワードを利用することが望ましいが，すべてのパスワードを記憶しておくことはほとんど不可能である．Florêncioの 2007 年の大規模な調査によれば，ユーザは平均
25 個のサイトで 6.5 個のパスワードを利用しており，3ヶ月間にユーザの 4.28%がパスワードを忘れていた [5]．また 2011 年の野村総研の調査によれば，
一般的なユーザがパスワード認証を行なうサイトは平均 19.4 個で，利用しているパスワードは平均 3.1個であった [23]．多数のパスワードを記憶することが困難であるため，多くのユーザが同じパスワード
を複数サイトで使い回しているのだと思われる．
異なるパスワードをすべて記憶することは不可能なのでどこかに記録しておく必要があるが，パス
ワード文字列をそのまま記録するのは危険なので，複数のパスワードを秘密情報として扱うためのパス
ワード管理システムが利用されている．パスワード
管理システムはひとつの「マスターパスワード」を利用して他のすべてのパスワードを管理するもので，暗号化されたデータベースにパスワードを格納する
もの [1][3][12] が多いが，サービス名をもとにマス
ターパスワードを変換することによって複数のパス
ワードを生成するシステム [18] もある．両者ともに∗

Copyright is held by the author(s).
Toshiyuki Masui, 慶應義塾大学 環境情報学部- 109 -

マスターパスワードの記憶が必須であり，マスター
パスワードを盗まれたり忘れたりする危険が常に存在する．
一般にユーザはパスワードを忘れがちであるため，多くのサービスにおいてパスワードを復元したり初期化したりする手段が用意されている．ユーザが秘密の質問に対する答を登録し，質問に正しく回答することによってパスワードを復元したりリセットできるサービスは多いし，秘密の質問に答えることによってパスワード管理システムのマスターパスワー
ドを復元するシステム [25] も提案されている．
新しく覚えた情報や新しく考えた情報はどうしても忘れてしまう可能性があるので，新しく作成したパスワード文字列を記憶して認証に利用することは本質的に無理がある．一方，既知で忘れることがない
エピソード記憶を秘密の質問として認証のために直接利用することができれば，認証に必要な情報を忘れてしまうことがないはずである．多くの画像認証システム [2][19] は秘密の質問に対して適切な操作を行なうことによって認証を行なっているためパスワー
ドのような特種な情報を記憶する必要がない．画像
認証システムはまだ普及しておらず，利用できる環
境は限られているが，忘れないエピソード記憶を利用した秘密の質問への回答を強力なパスワードに変換するシステムがあれば，通常のパスワード認証を用いた現在の様々なサービス上でも，認証方法を忘れる心配なく安全に認証を行なうことができるようになる．本論文ではこのようなシステム「EpisoPass」
について述べる．

2

EpisoPass

2.1 EpisoPass の原理
EpisoPass は，ユーザが忘れることがない個人的なエピソード記憶を文字列に変換することによって安全なパスワードを生成するシステムである．パス
ワード文字列は以下の手順で生成される．

WISS 2013

1. パスワード生成の「種」となる文字列を用意する．以下ではこれを「シード文字列」と表現する．

2. 忘れることがない個人的なエピソード記憶にもとづく秘密の質問を複数作成し，それぞれについてひとつの正答と複数の偽答を用意する．

3. 質問と回答の組にもとづいてシード文字列に換字操作を行なう．すべてに正しく回答した
とき生成される文字列をパスワードとして利
用する．

2.2
2.2.1

EpisoPass 利用例
ブラウザでの利用

筆者が twitter のパスワードを生成するためにブラウザで EpisoPass を利用している例を図 1 に示
す 1 ．シード文字列として「Twitter123456」という文字列を指定しており，4 個の秘密の質問に対する回答選択に応じて「Mfveabn574923」のようなパス
ワード候補が生成される．異なる答を選択したり異なるシードを指定すると全く異なる文字列が生成される．シード文字列の 8 文字目が数字である場合はパスワードの 8 文字目も数字になるなど，シード文
字列の文字種に対応したパスワード候補が生成される．パスワードとして大文字/小文字英数字と記号をすべて利用しなければならないサービスの場合はシード文字列に「PassWord123!@#」のような文字列を指定すればよい．
最初の秘密の質問は筆者の小学校の同級生に関するもので，最後の質問は数年前の体験に関するものである．これらの質問は古いエピソード記憶にもとづいており，筆者が将来答を忘れることはほとんど考えられないが，本人以外がこのような質問に答えることは難しいので正しいパスワードを得ることはできない．
秘密の質問と答はブラウザで編集でき，右上の「サーバにセーブ」ボタンを押すことによりシード
文字列，秘密の問題，答のリストがサーバにセーブされる．
「ファイルにセーブ」ボタンを押すと JSON
データをパソコンにダウンロードでき，パソコン上の JSON データをブラウザにドラッグ&ドロップす
るとサーバにアップロードできる．ユーザはどれが正答かを指定するわけではないので問題データを見てもユーザのパスワードはわからない．
シード文字列を「Facebook123456」に変更すると，生成されるパスワードは図 2 のように変化する．
このように，サービスごとに異なるシード文字列を利用することによって様々なパスワードを簡単に生成できる．
1

http://EpisoPass.com/masui- 110 -

図 1. ブラウザ上で Twitter のパスワードを生成.

図 2. FaceBook のパスワードを計算.

2.2.2

既存パスワードの利用

現在 “Masui1234” のようなパスワードを利用している場合，図 3 のようにパスワード欄に現在のパスワードを入力すればそれを生成するシード文字列が自動生成されるので，生成されたシード文字列を記録しておけばよい．

図 3. 既存のパスワードを利用.

既存のパスワード管理システムは，利用中のパスワードを記憶するもの [1][3][12] と新しいパスワー
ドを生成するもの [18] に分類されるが，EpisoPass
はこの両方をサポートしている．

EpisoPass: エピソード記憶にもとづくパスワード管理

2.2.3 Android アプリ
Web サービスを利用する場合，ブラウザとサーバとの間の通信を記録されたり盗み見されたりされる心配を完全に払拭することはできない．前述の例
において，パスワードはブラウザ内部で JavaScriptにより生成されるので，一度ページを表示した後はネットワークを遮断してもパスワード計算を行なえるようになっているが，最初から全く通信を行なわずにパスワードを作成できる方がより安心であろう．
このため，通信を全く行なわずにマシン単体でパス
ワード計算を行なうための Android アプリを用意した．ページの右上の「Android アプリ」ボタンを押すと，現在表示している秘密の問題と答を内蔵した Android アプリがサーバ上でビルドされてダウ
ンロードされる．
シード文字列を設定して Android アプリを実行すると図 4 のように質問がひとつずつ表示され，ボタンを押してすべて回答するとパスワードが計算され表示される．

の手法を使うと秘密の質問が通信路を通ることがな
いので安全であるが，アプリのセットアップの手間は増える．
パスワード文字列の計算方法

2.3

問題と回答から文字列を生成し，その MD5 値によってシード文字列を換字することによりパスワー
ドを生成している．パスワード文字列の計算方法は附録に示す．

議論

3
3.1

運用形態と安全性

パスワード管理システムにおいて最も重要なのは安全性である．EpisoPass は様々な運用方法が可能であり，運用形態によって安全性の評価が異なるので，利用例にもとづいて EpisoPass の安全性を考える．

EpisoPass の利用を秘密にする場合
パスワード管理に EpisoPass を利用していること

3.1.1

を公開せず，単なるパスワード生成機として利用する場合は，普通にパスワードを利用する場合に比べて安全度が低下することは無い．パスワードとして充分強力な文字列をシード文字列として利用すればEpisoPass によって換字された文字列もパスワード
として強力だと考えられるし，推測しやすい文字列
をシード文字列として設定した場合であってもランダムな換字操作によってより強力なパスワードが生成されるので，EpisoPass を利用するデメリットは無く，通常のパスワード管理システムと同様の方法
で利用できる．
図 4. Android アプリ.

3.1.2 シード文字列を秘密にする場合
EpisoPass の秘密の質問を公開した場合でも，シー

回答入力とパスワード計算は Android 端末で実行されるため，端末を「機内モード」に設定するな
どの方法でネットワーク接続を遮断した状態でもパスワードを計算することができる．EpisoPass をインストールした Android 端末を持っていれば常に各種のパスワードを計算できるので，他人のマシンや公共の場所に設置されたパソコンなどでも容易に
ネットサービスを利用することができる．
前述の方法で EpisoPass アプリをサーバからダウ
ンロードする場合は，ブラウザ上で秘密の問題をサーバに登録する必要があるが，秘密の問題を全くネット上に露出することなくアプリを利用することもできる．秘密の問題を含まない EpisoPass アプリ
を Google Play で公開 2 しているので，これを端末にインストールした後，ローカルマシンで作成した秘密の質問を端末に転送すれば EpisoPass.com からダウンロードしたアプリと同様に利用できる．こ2

ド文字列を通常のパスワードと同じレベルで秘密にしておけば SuperGenPass[18] と同じレベルの利便性と安全性が確保できる．

3.1.3

すべて公開する場合

秘密の質問を解くことが不可能であれば，シード
文字列と秘密の質問をすべて公開しても安全である．
この場合，ユーザは秘密の質問とシード文字列を通常のテキストデータと同じように管理できるし，パスワード管理のために新しく記憶しなければならな
い情報が皆無なので，ユーザはパスワード管理について注意を払う必要が無くなり気が楽になる．
秘密の質問を解くことを困難にするためには質問の数と偽答の数が多くなければならないし，自分だ
けが知っているエピソード記憶をうまく秘密の質問にするにはコツが必要である．良い秘密の質問を作る方法に関しては 3.3 で議論するが，すべての質問を公開するのが心配な場合や，秘密の質問の数や質

https://play.google.com/store/apps/details?id=com.
pitecan.episo pass

- 111 -WISS 2013

がが充分でないと感じられる場合は 3.1.1 や 3.1.2 の手法で運用し，徐々に運用方法を変えていけば良い
だろう．

3.2

問として利用すべきであり，以下のような性質をもつ記憶は秘密の質問として利用すべきではない．

秘密の質問の強度

パスワードは長年利用されているため強度や実際の運用に関して多くの研究が存在するが [7][11]，秘密の質問の強度に関しては充分な研究が行なわれていない．EpisoPass の運用実績は長くないが安全性などについて考察を行なう．
EpisoPass で選択枝が 10 個の秘密の質問を 8 個使用する場合，総当たりでパスワードを生成するには
1 億 (108 ) 通りの試行が必要であり，エントロピー
は 26.6 ビットとなる．英字からランダムに 8 文字を並べて作成したパスワードのエントロピーは 37.6
ビットになるが，“pmvixuzq” のように全く意味のないパスワードを記憶して利用することは少ないため，実際に利用されるパスワードのエントロピーは
20 ビット程度と考えられているので [14]，秘密の質問と選択枝の数を 10 個程度用意すれば通常のパスワードと同程度の強度が期待できることになる．
総当たり攻撃が可能なオフライン運用ではエントロ
ピーの大きさは重要であるが，オンラインサービス
ではパスワード入力を何度か間違えるとサービスがブロックされるのが普通なので，それほど長いパス
ワードを用意する必要は無いと考えられている [6]．
一方，秘密の質問を利用する認証の脆弱性を利用した攻撃が近年問題になっている．パスワードを忘れたときのために，あらかじめ設定した秘密の質問に答えることによってパスワードをリセットできる
サービスがあり，「母親の旧姓は?」や「最初に飼ったペットの名前は?」のような質問に対してユーザが答を登録するようになっている．このような問題は他人が調べたり推測したりすることが容易である
うえに秘密の質問の数は一般的に少なく，パスワー
ドよりも脆弱だといえる [15]．ユーザが作成した秘密の質問を使えばこのような問題はなくなるはずであるが，他人に解かれにくい問題をユーザが作成することは難しく，またユーザ自身が答を忘れてしまうことも多いと考えられている [10][16]．
EpisoPass では，他人には解くことが難しく自分
では忘れないような秘密の質問を自由にいくつでも利用できるようになっている．問題作成に慣れていないユーザには有効な秘密の質問を作成することは難しいかもしれないが，次節で述べるように，適切な質問を選ぶことによりこの問題を解決できるはず
である．

3.3

• 自慢になるもの (何かの機会にうっかり他人に話してしまう可能性がある)• ネット上に記録が残っているもの• 他人と情報を共有しているもの• 趣味や嗜好に関連するもの (他人に推測されやすいうえに嗜好が変化する可能性がある)

秘密の質問の選択

EpisoPass 利用において秘密の質問の選択は非常に重要である．他人が推測することが難しく，自分が決して忘れないようなエピソード記憶を秘密の質

このようなものではなく，「わざわざ人に話すことはないが自分の記憶に強く残っているような無難なエピソード記憶」を秘密の質問として利用するのが良いであろう．具体例としては以下のようなものがある．

• 昔のちょっとした怪我の場所や種類• 昔のちょっと悔しい思い出• 昔何かを見つけた場所

たとえば図 1 の 3 問目のような経験は他人に話したことが無いが，痛い思いをしたことは忘れないし，偽答の地名を並べるのも簡単なので，認証のための秘密の質問として適切であると考えられる．

3.4

偽答の作成方法

秘密の質問の種類によっては偽答を用意するのが難しい場合があるが，正答として人名や地名を利用する場合，正答に似た人名や地名をリストすることは難しくない．
「世田谷」が正答であるとき，「目黒」「杉並」のような偽答を用意するのは簡単である．正答と同じカテゴリに属する単語を自動的にリストすることができれば正答をもとにして簡単に偽答のリストを生成することができる．ひとつの単語もしく
は単語の集合と同じカテゴリに属する単語を検索する手法は「同位語検索」と呼ばれ，Web のデータを利用した様々な同位語検索システムが提案されている [17][24]．
人名や地名の偽答を作成したい場合は人名や地名のデータベースを利用して偽答を生成することができる．市町村の人口ランキングや位置関係のデータなどを利用すれば似た地名を偽答としてリストすることが可能であるし，人名ランキングを利用すれば似た苗字を偽答とすることができる．たとえば日本の名字ランキングの 40 位近辺に「長谷川」「近藤」
「石井」
「斉藤」
「坂本」
「遠藤」
「藤井」などの名字があるので，「石井」が正答のときこれらの名字を偽答にすればよい．しかし，「小学生のとき〜だった同級生は誰?」という秘密の質問の正答が「石井」であるときこの方法で偽答を生成すると，「長谷川」「近藤」などの同級生の存在を確認することにより正答が「石井」であることが判明してしまう可能性があるので注意が必要である．

- 112 -

EpisoPass: エピソード記憶にもとづくパスワード管理

3.5

パスワード漏洩時の問題

秘密の質問を公開している場合，シード文字列とパスワードの対応がひとつでも漏洩してしまうと，総当たり計算でチェックすることにより，すべて秘密の質問の正答が判明してしまう．秘密の質問の正答を知っていればシード文字列からパスワードを計算することができるので，漏洩した秘密の質問は利用不可能になってしまう．3.1.1 や 3.1.2 のような運用をしている場合はパスワードがひとつ漏洩しても他のパスワードは安全だが，3.1.3 のような運用をしている場合はひとつでもパスワードが漏洩するとあらゆるパスワードが漏洩してしまうことになる．
通常の Web サービスなどのパスワードが漏洩することは考えにくいが，「自転車の鍵番号」のように家族などで共有する可能性があるものに対して 3.1.3のような運用を行なうと，鍵番号を知っている人物が総当たり攻撃を行なうことによって秘密の質問の答が判明してしまう．シード文字列や秘密の質問を秘密情報として扱わない場合はパスワードを他人と共有しないように注意する必要がある．

3.6

4

結論

エピソード記憶に結びついた秘密の質問を利用してパスワードを生成/管理できるシステム EpisoPassを提案した．EpisoPass は単純な原理にもとづいて
おり柔軟な利用形態が可能であり，強力な秘密の質問を用意することにより秘密情報を全く覚えることなく安全な認証を行なうことができる．強力な秘密の質問を作成して安全に運用が可能かどうかを長期的に評価したいと考えている．

参考文献

画像認証の利用

忘れにくいエピソード記憶を利用する認証手法
として様々な画像認証システム [2][9][19] が提案されている．複数の画像の中から正答を選択するもの(Cognometric 方式)，ひとつの画像の中の特定の場所を指定するもの (Locimetric 方式)，画像の上で描画操作を行なうもの (Drawmetric 方式) が広く利用されているが [2][9]，EpisoPass は図 1 のように文字列のかわりに画像 URL を秘密の質問として利用する点が異なっている．Cognometric 方式はエピソー
ド記憶を効果的に利用できるが，多数の偽答画像が必要だという問題がある．Locimetric 方式はエピ
ソード記憶を効果的に利用できないことに加え，クリックしやすい「ホットスポット」は限られている
ため充分なエントロピーを確保できないことが問題になる [4]．また Drawmetric 方式もエピソード記憶を効果的に利用できないし，ユーザは似た傾向のス
トロークを選びがちであるため充分なエントロピーを確保しにくいことが知られている [13]．EpisoPassのように画像を秘密の質問として利用する場合，通常の秘密の質問の場合と同様に偽答を増やすことが容易であることに加え，画像に関連したエピソード
記憶を有効に利用できるという利点がある [22]．

[1] AgileBits Inc. 1Password. https://agilebits.com/
onepassword.
[2] R. Biddle, S. Chiasson, and P. Van Oorschot.
Graphical passwords: Learning from the firsttwelve years. ACM Comput. Surv., 44(4):19:1–
19:41, Sept. 2012.
[3] Dashlane, Inc. Dashlane. https://www.dashlane.
com/.
[4] A. E. Dirik, N. Memon, and J.-C. Birget. Modeling user choice in the PassPoints graphical password scheme. In Proceedings of the 3rd symposium on Usable privacy and security, SOUPS ’07,
pp. 20–28, 2007.
[5] D. Florêncio and C. Herley. A large-scale studyof web password habits. In Proceedings of the
16th international conference on World Wide
Web, WWW ’07, pp. 657–666, 2007.
[6] D. Florêncio, C. Herley, and B. Coskun. Do
strong web passwords accomplish anything? In
Proceedings of the 2nd USENIX workshop on Hot
topics in security, HOTSEC’07, pp. 10:1–10:6,
Berkeley, CA, USA, 2007. USENIX Association.
[7] E. Hayashi and J. Hong. A diary study of password usage in daily life. In Proceedings of the
SIGCHI Conference on Human Factors in Computing Systems, CHI ’11, pp. 2627–2630, 2011.
[8] C. Herley, P. C. Oorschot, and A. S. Patrick.
Passwords: If We’re So Smart, Why Are We Still
Using Them? In R. Dingledine and P. Golle eds.,
Financial Cryptography and Data Security, pp.
230–237. Springer-Verlag, 2009.

図 5 は本棚.org[20] のユーザのひとり 3 が利用している画像認証問題である．このユーザ以外には正答は見当もつかないが，本人にとっては忘れることがないエピソード記憶と結びついた画像だということであった．
3

図 5. エピソード記憶と深く結びついた画像.

http://hondana.org/Leiko- 113 -WISS 2013[24] 大島 裕明, 小山 聡, 田中 克己. Web 検索エンジ
ンのインデックスを用いた同位語とそのコンテキストの発見. 情報処理学会論文誌. データベース,
47(19):98–112, December 2006.

[9] Internet Safety Project.
Graphical Passwords.
http://www.internetsafetyproject.org/
wiki/graphical-passwords.
[10] M. Just and D. Aspinall. Personal choice andchallenge questions: a security and usability assessment. In Proceedings of the 5th Symposium
on Usable Privacy and Security, SOUPS ’09, pp.
8:1–8:11, 2009.
[11] S. Komanduri, R. Shay, P. G. Kelley, M. L.
Mazurek, L. Bauer, N. Christin, L. F. Cranor,and S. Egelman. Of passwords and people: measuring the effect of password-composition policies. In Proceedings of the SIGCHI Conferenceon Human Factors in Computing Systems, CHI’11, pp. 2595–2604, 2011.
[12] LastPass.com. LastPass. https://lastpass.com/.

[25] 平野 亮, 森井 昌克. パスワード運用管理に関する考察および提案とその開発. 電子情報通信学会技術研究報告. ISEC, 情報セキュリティ, 111(285):129–
134, November 2011.

附録: パスワード計算アルゴリズム
パスワードは，秘密の質問と回答の組合せにもとづいてシード文字列を換字することによって計算される．換字は文字種ごとに行なわれる．たとえばシー
ド文字列の 1 桁目が数字のときはパスワードの 1 桁
目は数字に変換され，シード文字列の 1 桁目が記号のときはパスワードの 1 桁目は記号に変換される．
数字の換字の場合、シード文字列内の数字 A は，換字関数 fN () によってパスワード内の数字 B に変換される．fN () は以下のような関数である．

[13] D. Nali and J. Thorp. Analyzing user choice ingraphical passwords. Technical Report TR-0401, School of Computer Science, Carleton University, Ottawa, 2004.
[14] National Institute of Standards and Technology.
Electronic Authentication Guideline. NIST Special Publication 800-63-1. http://csrc.nist.gov/
publications/nistpubs/800-63-1/SP-800-63-1.pdf,
2011.
[15] A. Rabkin. Personal knowledge questions for
fallback authentication: security questions in theera of Facebook. In Proceedings of the 4th symposium on Usable privacy and security, SOUPS’08, pp. 13–23, 2008.
[16] S. Schechter, A. J. B. Brush, and S. Egelman.
It’s No Secret. Measuring the Security and Reliability of Authentication via ‘Secret’ Questions.
In Proceedings of the 2009 30th IEEE Symposium
on Security and Privacy, SP ’09, pp. 375–390,
2009.
[17] R. C. Wang and W. W. Cohen. LanguageIndependent Set Expansion of Named Entities
Using the Web. In Proceedings of the 2007
Seventh IEEE International Conference on Data
Mining, ICDM ’07, pp. 342–350, 2007.
[18] C. Zarate. SuperGenPass. http://supergenpass.
com/.

fN (x) = (10 + N − x) mod 10

ここで N はシード文字列と回答の組み合わせから計算される自然数で，答の選択により変化する．たとえば N = 5 のとき，f5 (x) = (10+5−x) mod 10となるので，x と f5 (x) の対応は以下のようになる．

f5 (0) = 5
f5 (1) = 4...
f5 (8) = 7
f5 (9) = 6
fN () は N により変化するので，N がわからなけ
れば fN () もわからない．N はシード文字列と回答の組み合わせから計算される自然数で，秘密の質問の答とシードを知らなければ N を計算することはできない．EpisoPass では以下のようにして fN () を計算している．

[19] 小池 英樹, 増井 俊之, 高田 哲司. 画像を用いた個人認証手法. 情報処理, 47(5):479–484, May 2006.

1. 問題文字列と選択した答の文字列の組を連結した文字列 S を生成
2. S の MD5 ハッシュ値 M (16 進 32 桁の文字列) を計算3. シード文字列の k 桁目の文字に対し，M の(k − 1) × 4 文字目から (k − 1) × 4 + 3 文
字目までの部分文字列 (16 進 4 桁) を取得し，それを N とする．たとえばハッシュ値 M が12345678... だったとき，0x1234 = 4660 なので，1 桁目を計算する換字関数は f4660 (x)[20] 増井 俊之. 本棚通信: 控え目なグループコミュニ
ケーション. インタラクション 2005 論文集, pp.
135–142, February 2005.
マ イ 認 証.
Unix Magazine,[21] 増 井 俊 之.
21(3), March 2006. http://www.pitecan.com/
UnixMagazine/PDF/if0603.pdf.

[22] 増井 俊之. パスワードとの闘い - パスワードなし
認証システムの運用報告. コンピュータセキュリ
ティシンポジウム 2009 論文集, 2009.
[23] 野村総合研究所. 利用者登録する商品 · サービスを選別する傾向が強まった生活者と顧客情報の鮮度維持を望む事業者〜生活者と事業者を対象とした ID に関する実態調査〜. http://www.nri.co.jp/
news/2012/120208.html, February 2012.

となる．

- 114 -