WISS2013

研究分野と参照関係からたどる文献可視化インタフェース
中澤 里奈

伊藤 貴之

斎藤 隆文∗

概要. 研究を進めていく上で，論文サーベイは非常に重要である．しかし，初学者は検索する上で適切なキーワードを全て知っているわけではないため，検索エンジンを用いた方法では，検索ワードによっては見落としがおこる可能性がある．一方で，より視覚的に参照関係をたどりながら文献を調査する方法の一つとして，文献の参照関係の可視化の研究が数多く行われてきた．これらの研究では，文献をノードとして時系列に並べ，参照関係をエッジとしたグラフによって，参照関係の構造を表現している．このような手法は，研究分野をまたいだ複雑な接続関係が視認しづらく，参考文献をたどっていくにはやや不向きである．そこ
で本報告では，研究分野と参照関係からたどる論文探し支援のための参照関係可視化手法を提案する．提案手法では，文献の内容をもとに文献を分類し，これらの分類と参照関係にもとに，可視化手法 FRUITSNet を用いて文献の配置を決定，エッジバンドリングを用いて参照関係情報の要約可視化を行う．これにより，分野間の参照関係をより簡単に把握することで文献調査を支援できるのではないかと考える．

1

研究背景

2

研究を進めていく際の文献調査は非常に重要な要素である．調査方法としては，検索エンジンを用いたり，既に読んでいる論文の参考文献をたどっていったりするといった方法がある．しかし，研究を始めたばかりの学生は検索のための適切なキーワー
ドを全て知っているわけではないため，検索エンジンによる方法では，検索ワードによって見落としがおこってしまう上に，論文同士の関係を見いだすことができない．一方で，参考文献をたどることで視覚的に文献を調査する方法の一つとして，文献の参照関係の可視化の研究が数多く行われてきた [1] [2]．
これらの研究では，各文献をノードとして時系列に並べ，参照関係をエッジとしたグラフによって，参照関係の構造を表現している．このような手法では，研究分野をまたいだ複雑な参照関係をグラフとして描画すると，非常に多くのエッジ間の交差が生じて視認性に悪影響をおよぼす．そこで本報告では，研究分野と参照関係からの文献探しに適した参照関係
可視化手法を提案する．本手法では，文献の内容でクラスタリングされた参照関係グラフを描画し，クラスタ間の参照が多い場合にはエッジバンドリングを施す．この時，敢えて時系列順に並べないことでクラスタ間の参照関係の太さを視認しやすくする．
これにより，一つのキーワードに関係ある論文が複数の分野にわたっている時に，それらを見逃さずに網羅的に発見でき，その全体的な構図も理解しやす
くなると考えられる．

2.1

Copyright is held by the author(s).
Rina Nakazawa and Takayuki Itoh, お茶の水女子大学大
学院 人間文化創成科学研究科 理学専攻，Takafumi Saito,
東京農工大学大学院 工学研究院 先端情報科学部門

2.3

∗

提案手法

文献のカテゴリ分類

本手法では，文献の内容から文献を研究の分野別にカテゴリ分類するために，今回は一例として
潜在的ディリクレ配分法（LDA: Latent Dirichlet
Allocation）[4] を用いた．LDA は，一つの文書に対して複数のトピックの存在を想定した，文書生成
過程の確率的なトピックモデルである．LDA で推定されるトピックを一つの研究分野と見なし，各文献がどのような研究分野に属するかを分類する．LDAにおいて，トピック数は予め決めておく値であるた
め，今回はトピック数を 10 とした．

2.2

参照関係の要約可視化

続いて，LDA を用いて推定したカテゴリ分類をもとに，FRUITS Net[3] の配置アルゴリズムを用いることでノードの配置を決定する．これにより，参照関係がある文献同士を近く，同じ研究分野に属する文献同士を近く配置し，ノード同士の重なりを回避しつつ，画面配置占有面積を低減することができる．ノードの大きさはその文献の被引用数に比例する．その上で，エッジの視認性を向上するためにエッジバンドリングを施すことで，大量の線情報を束ね，要約する．エッジを束ねる本数はユーザが閾値をスライダによって設定することができる．カテ
ゴリ分類によってできた文献クラスタ間のエッジ本数を計算し，それが閾値以上であるならば，本数に比例させた太線を束として描く．閾値に満たない場
合はエッジをそのまま描画する．
ユーザインタフェース上での描画と操作

図 1 は，本ユーザインタフェースにおける表示
画面例である．ユーザは操作パネル上の (1)(3) で- 115 -WISS 2013

読み進めていけばいいということがわかる．従って，
本インタフェースを利用することで関係ありそうな論文を研究分野と参照関係から整理して，どの論文群から先に読むかを選択できるのではないかと考えられる．

図 1. インタフェース表示画面例

可視化結果の拡大縮小や平行移動操作，エッジバン
ドリング適用の有無，その閾値の設定を行うことができる．また，各文献であるノードをクリックすると，その文献のタイトルや発行年，アブストラクトなどの詳細情報を表示する．同時に，クリックされたノードが持つエッジと，それに接続するノードが持つエッジの二世代分の参照関係をハイライト表示
する．このエッジのハイライトは 2 つのノードについて同時に適用可能であり，これによって両ノードの接続関係を比較することができる．一方，最初に注目すべき文献を探すことは初学者にとっては容易ではない．そこでユーザは大まかな研究分野かキー
ワードを利用することで，画面上に表示させる文献をフィルタリングすることができる．自分の興味のある研究分野カテゴリを操作パネル上のボタンから選択した場合，選択した研究分野のみと分類された文献群をウィンドウ中央部に拡大表示される．また，(2) にキーワードを入力すると，入力された語がタイトル中に含まれている文献ノードのみが表示される．

3

実行結果

使用した文献データは 1990 から 94 年，2000 から2010 年までに SIGGRAPH で発表された論文 1072本である．例として，ユーザが写真や動画の処理関連の研究の文献を調査したい場合を考える．写真，
動画関連の研究分野カテゴリを選択すると，表示結果は図 2 のようになる．図 2 の (A) が写真，動画の処理関連の分野であり，(A) に接続する束を追っていくと，(A) には (B) と (C) のどちらかと参照関係を持つ文献が多く存在するということがわかる．
(B) は画像処理関連のクラスタ，(C) は大域照明，光反射や光拡散モデルなどと写真や動画の処理が組合わさったクラスタである．この結果から，写真や動画の処理に関する文献を探したい場合，優先して探したい内容がどちらかというと (B) の画像処理技術に関連寄りなのか (C) のライティング関連寄りなのかによって，その分野と接続している文献から先に- 116 -

図 2. カテゴリ選択時の表示結果

4

まとめと今後の課題

本報告では分野間の繋がりを考慮した文献参照
関係の可視化インタフェースを提案した．本手法によって，研究分野と参照関係から関連のありそうな文献を整理し，優先的に読むべき文献を選ぶことができるようになるのではないかと考えられる．現在
はエッジの方向性を考慮した描画を行っていないた
め，今後はエッジの方向性を表現したエッジバンド
リングと可視化を行っていく．さらに，今回手動で決定していたトピック数の推定や GUI 機能の拡充，評価実験なども進めていきたい．

参考文献[1] J. Matejka, T. Grossman, and G. Fitzmaurice. Citeology: visualizing paper genealogy. In
CHI’12 Extended Abstracts on Human Factors in
Computing Systems, pp. 181-190, 2012.
[2] 岡田, 渡部, 斎藤. 時系列に基づいた文献参照関係の可視化-文献のクラスタリング-. 情報処理学会第74 回全国大会, 3ZB-3, 2012.
[3] T. Itoh, C. Muelder, K. -L. Ma, and J. Sese.
A Hybrid Space-Filling and Force-Directed Layout Method for Visualizing Multiple-Category
Graphs. In Proceedings of IEEE Pacific Visualization Symposium, pp. 121-128, 2009.
[4] D. M. Blei, A. Y. Ng, and M. I. Jordan. Latent
Dirichlet Allocation, Journal of Machine Learning Research, Vol. 3, pp. 993-1022, 2003.

WISS2013‫ۮ‬વͷ࠶ձΛԋग़͢Δফ‫ۃ‬తͳਓ޲͚ਓؒؔ܎‫ܧ‬ଓࢧԉγεςϜև઒ ༸ฏɹɹࢁຊ ‫ࢠܠ‬ɹɹ૔ຊ ౸ɹɹ௰໺ Յ޺ ∗֓ཁ. पғͷਓͱੵ‫ۃ‬తʹަྲྀ͢Δ͜ͱ͕ۤखͳਓ෇͖߹͍ʹফ‫ۃ‬తͳਓ͸ɼ೔ৗੜ‫͍͓ͯʹ׆‬੮Λ‫ʹڞ‬ͨ͠ॳର໘ͷਓʹ࿈བྷઌΛฉ͘͜ͱ͕೉͘͠ɼͦͷͱ͖ʹ৽ͨʹߏஙͨ͠ਓؒؔ܎Λҡ࣋Ͱ͖ͳ͍ɽ͜ͷ৔߹ɼͦͷਓͱͷ‫ۮ‬વͷ࠶ձ͕ਓؒؔ܎Λ࠶։ɾ‫ܧ‬ଓ͢Δ͖͔͚ͬʹͳΔ͜ͱ΋͋Γ͏Δ͕ɼͦͷΑ͏ͳ͜ͱ͸Ίͬͨʹͳ͍ͱ͍͏໰୊͕͋Δɽ·ͨɼফ‫ۃ‬తͳਓ͸ͨͱ͑‫ۮ‬વͷ࠶ձΛ͢Δ͜ͱ͕͋ͬͯ΋ɼ૬खʹ͍ͭͯͷ‫ه‬Աͷᐆດ͞ɾਓҧ͍ͷ‫ة‬ዧͳͲ͔Β੠Λ͔͚ΒΕͣɼ݁‫ͦہ‬ͷ‫ػ‬ձΛ༗ޮʹ࢖͑ͳ͍ͱ͍͏໰୊΋
͋Δɽͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼҎલʹ੮Λ‫ͨ͠ʹڞ‬΋ͷͷɼͦͷͱ͖ʹ࿈བྷઌΛฉ͘͜ͱ͕Ͱ͖ͣɼͦΕҎ߱ʹ΋࿈བྷΛͱΔ͜ͱ͕Ͱ͖ͳ͍ਓͱͷؔ܎Λ࠶։ɾ‫ܧ‬ଓͤ͞Δ͜ͱΛ໨తͱ͢Δɽ͜ΕΛ࣮‫͢ݱ‬ΔͨΊʹɼ‫ۮ‬વͷ࠶ձΛফ‫ۃ‬తͳਓͷͨΊʹԋग़͢Δख๏ͱͯ͠ɼҎલʹ੮Λ‫ͨ͠ʹڞ‬ফ‫ۃ‬తͳਓಉ͕࢜ಉ͡৔ॴʹ޲͔͏Α͏ଅ͢৘ใΛఏ‫͠ڙ‬ɼۙ͘ʹ‫߹ډ‬Θͤͨͱ͖ʹ૬खͷଘࡏʹ‫͚ͮؾ‬Δ௨஌Λߦ͏γεςϜΛఏҊ͢Δɽ

1

͸͡Ίʹ

ࢲͨͪ͸೔ৗੜ‫͍͓ͯʹ׆‬ɼಉ͡໨తΛ࣋ͬͨਓಉ͕࢜ಉ͡৔ॴʹ‫߹ډ‬ΘͤͨΓɼ༑ਓͷ༑ਓͳͲͷ‫͕ܨ‬Γ͔Βަ༑ؔ܎͕޿͕ͬͨΓ͢Δ͜ͱʹΑͬͯɼॳର໘ͷਓͱ੮Λ‫͢ʹڞ‬Δ͜ͱ͕͋Δɽྫͱͯ࠙͠
਌ձ΍߹ίϯͳͲ͕‫͛ڍ‬ΒΕΔɽͦͷࡍʹɼॳର໘ͷਓͱҰॹʹձ࿩ͨ͠Γ͓ञΛҿΈަΘͨ͠Γ͢Δ͜ͱͰɼ৽ͨͳਓؒؔ܎Λߏங͢Δ͜ͱ͕Ͱ͖Δɽ͜ͷ৽ͨʹߏஙͨ͠ਓؒؔ܎Λҡ࣋͢Δखஈͱͯ͠ɼͦͷਓͷ࿈བྷઌΛฉ͖࿈བྷΛͱΓ͋͏͜ͱ͕‫ڍ‬͛ΒΕΔɽ͔͠͠ɼपғͷਓͱੵ‫ۃ‬తʹަྲྀ͢Δ͜
ͱ͕ۤखͳਓ෇͖߹͍ʹফ‫ۃ‬తͳਓʢҎ߱ɼʮফ‫ۃ‬త
ͳਓʯʣ͸ɼॳର໘ͷ૬खʹରͯ͠࿈བྷઌΛฉ͘͜ͱ͕Ͱ͖ͳ͍ɽ·ͨɼফ‫ۃ‬తͳਓ͸ɼ࿈བྷઌΛ஌ͬ
͍ͯΔ‫ڞ‬௨ͷ஌ਓ΍‫ࣄװ‬Λ‫ܦ‬༝͢Δ͜ͱͰɼ‫ޙ‬೔ʹ࿈བྷઌΛฉ͘͜ͱ΋Ͱ͖ͳ͍ɽͱΓΘ͚͜ͷΑ͏ͳঢ়‫گ‬͸ɼ࿈བྷઌΛฉ͖͍ͨ૬ख͕ҟੑͷ৔߹ʹଟ͘‫͜ى‬Γ͏Δɽ͜ͷΑ͏ʹɼফ‫ۃ‬తͳਓ͕ॳର໘ͷਓͷ࿈བྷઌΛฉ͘͜ͱ͕Ͱ͖ͳ͍ͱ͍͏໰୊ʢҎ߱ɼʮ໰୊఺ 1ʯʣ͕‫͜ى‬Δཧ༝ͱͯ͠ɼ• ؔ܎ͷઙ͍૬खʹରͯࣗ͠෼ͷ࿈བྷઌΛ‫͑ڭ‬• ૬खʹ͍ͭͯͷ‫ه‬Աͷᐆດ͔͞Β֬৴͕࣋ͯ
ͣɼผਓͩͬͨ৔߹Λ‫ة‬ዧ͢Δ

Δ͜ͱʹ఍߅Λ‫͡ײ‬ɼಉ༷ʹ૬खͷ࿈བྷઌΛฉ͘͜ͱʹ఍߅Λ‫͡ײ‬Δ• ࣗ෼͕૬खΛ͍֮͑ͯͯ΋૬ख͕ࣗ෼Λ͍֮͑ͯͳ͍͔΋͠Εͳ͍ͱ‫ݒ‬೦͢Δ• ৔ͷ੝Γ্͕ΓͳͲΛߟྀͯ͠ɼॳର໘ͷਓͱ͍͏͜ͱ͕ߟ͑ΒΕΔɽҎ্ΑΓຊ‫Ͱڀݚ‬͸ɼফ‫ۃ‬తͳਓ͕૬खͷ࿈བྷઌΛฉ͚ͳͯ͘΋ɼਓؒؔ܎Λ࠶։ɾ‫ܧ‬ଓ͢Δ͖͔͚ͬʹͳΔ‫ۮ‬વͷ࠶ձΛɼফ‫ۃ‬తͳਓͷͨΊʹԋग़͢
Δɽͦͷख๏ͱͯ͠ɼҎલʹ੮Λ‫ͨ͠ʹڞ‬ফ‫ۃ‬తͳਓಉ͕࢜ಉ͡৔ॴʹ޲͔͏Α͏ଅ͢৘ใΛఏ‫͠ڙ‬ɼۙ͘ʹ‫߹ډ‬Θͤͨͱ͖ʹ૬खͷଘࡏʹ‫͚ͮؾ‬Δ௨஌Λߦ͏γεςϜΛఏҊ͢Δɽ੢ాΒ [1] ΍ؓ໺Β [2] ΋ॳର໘ͷਓ͋Δ͍͸ؔ܎ͷઙ͍ਓͱͷަྲྀଅਐࢧԉγεςϜΛఏҊ͍ͯ͠ͷ࿈བྷઌΛฉ͘λΠϛϯάΛಀͯ͠͠·͏• ‫ޙ‬೔ʹ࿈བྷઌΛฉ͜͏ͱͯ͠΋ɼ‫ڞ‬௨ͷ஌ਓ΍‫ʹࣄװ‬୭ͷ࿈བྷઌΛ஌Γ͍͔ͨͱ͍͏ࣗ਎
ͷ‫ڵ‬ຯΛ‫͑ڭ‬Δ͜ͱʹஏ͔ͣ͠͞Λ‫͡ײ‬Δͱ͍͏͜ͱ͕ߟ͑ΒΕΔɽ
∗ͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼফ‫ۃ‬తͳਓ͕ɼҎલʹ੮Λ‫ڞ‬ʹͨ͠΋ͷͷɼͦͷͱ͖ʹ࿈བྷઌΛฉ͘͜ͱ͕Ͱ͖
ͣɼͦΕҎ߱ʹ΋࿈བྷΛͱΔ͜ͱ͕Ͱ͖ͳ͍ਓͱͷؔ܎Λ࠶։ɾ‫ܧ‬ଓ͢Δ͜ͱΛ໨తͱ͢ΔɽҰํɼ֗Λา͍͍ͯΔͱ͖ʹɼҎલʹ੮Λ‫͠ʹڞ‬ͨॳର໘ͷਓΛ‫ۮ‬વ‫͚͔ݟ‬Δ͜ͱ͕͋Δɽ͜ͷͱ͖ɼͦͷਓʹ੠Λ͔͚ͯ࠶ձ͢Δ͜ͱͰɼႢಹతʹͳ͍ͬͯͨਓؒؔ܎Λ࠶։ɾ‫ܧ‬ଓ͢Δ͖͔͚ͬΛ࡞Δ͜
ͱ͕Ͱ͖Δɽ͔͠͠ɼ֗Λา͍͍ͯΔͱ͖ʹҎલʹ੮Λ‫ॳͨ͠ʹڞ‬ର໘ͷਓΛ‫ۮ‬વ‫͚͔ݟ‬Δ͜ͱ͸සൟʹ‫͜ى‬Δࣄ৅Ͱ͸ͳ͍ɽ·ͨɼҎલʹ੮Λ‫ͨ͠ʹڞ‬΋ͷͷɼ࿈བྷΛऔΒͳ͔ͬͨਓΛ‫ۮ‬વ‫͚͔ݟ‬Δ·Ͱͷؒʹͦͷਓͷ‫إ‬΍༰࢟Λ๨Εͯ͠·͍ͬͯͨΓɼᐆດʹͳ͍ͬͯͨΓ͢
Δ͜ͱ͕͋Δɽͦͷ݁Ռɼফ‫ۃ‬తͳਓ͸྆ऀ͕͙͢
ۙ͘ʹ‫ډ‬Δʹ΋ؔΘΒͣɼͦͷਓʹ੠Λ͔͚ͣʹͦ
ͷ··͢Εҧͬͯ͠·͍ɼਓؒؔ܎Λ࠶։ɾ‫ܧ‬ଓ͢Δ‫ػ‬ձΛಀͯ͠͠·͏͜ͱʹͳΔɽ͜ͷΑ͏ʹɼফ‫ۃ‬తͳਓ͕‫ۮ‬વͷ࠶ձΛಀͯ͠͠·͏ͱ͍͏໰୊ʢҎ߱ɼʮ໰୊఺ 2ʯʣ͕‫͜ى‬Δཧ༝ͱͯ͠ɼ

Copyright is held by the author(s).
Youhei AkutagawaɼKeiko YamamotoɼItaru Kuramoto and Yoshihiro Tsujinoɼ‫ܳ޻౎ژ‬ણҡେֶ

- 117 -WISS 2013

ਤ 1. ఏҊγεςϜͷ௨஌ը໘දࣔྫ
ਤ 2. Ϟδϡʔϧؒͷؔ܎

Δ͕ɼ੢ాΒ͸ɼަྲྀͷ৔͔Β཭Εͨ‫ޙ‬΋ਓؒؔ܎Λ‫ܧ‬ଓͤ͞Δ͜ͱʹ͍ͭͯɼؓ໺Β͸ɼपғͷਓͱੵ‫ۃ‬తʹަྲྀ͢Δ͜ͱ͕ۤखͳফ‫ۃ‬తͳਓ͕γεςϜΛ࢖͏͜ͱʹ͍ͭͯ͸ߟྀ͍ͯ͠ͳ͍ɽ

2ఏҊγεςϜ

Ҏલʹ੮Λ‫ͨ͠ʹڞ‬ফ‫ۃ‬తͳਓಉ࢜ʹɼਓؒؔ܎
Λ‫ܧ‬ଓ͢Δ͖͔͚ͬʹͳΔ‫ۮ‬વͷ࠶ձΛఏ‫͢ڙ‬Δͨ
Ίʹɼਤ 1.a) ͷΑ͏ʹ൴Βʹಉ͡ళฮ΍ࢪઃͷ৘ใΛදࣔ͠ɼಉ͡৔ॴʹߦ͖΍͘͢͢Δɽ͜ΕʹΑΓɼϢʔβ͸ਓؒؔ܎Λ‫ܧ‬ଓ͢Δ͖͔͚ͬʹͳΔ‫ۮ‬વͷ࠶ձΛΑΓଟ͘͢Δ͜ͱ͕Ͱ͖Δͱߟ͑ΒΕΔɽ·ͨɼ͜ͷΑ͏ʹಉ͡৔ॴʹߦ͔͘΋͠Εͳ͍ͱ͍͏
Մೳੑͷ৘ใΛ௨஌͢Δ͜ͱͰɼ΋͔ͨ͠͠Β૬खʹձ͑Δ͔΋͠Εͳ͍ͱ͍͏‫ۓ‬ு‫ײ‬Λ࣋ͨͤΔ͜ͱ
͕Ͱ͖Δͱߟ͑ΒΕΔɽ͜ΕʹΑΓɼϢʔβΛ௻Γ‫ڮ‬ཧ࿦ [3] ͷΑ͏ͳঢ়ଶʹ͢Δ͜ͱ͕Ͱ͖ɼಛʹҟੑͷ৔߹ʹ͓͍ͯɼΑΓਂ͍ަ༑ؔ܎ʹ‫͛ܨ‬Δ͜ͱ
͕Ͱ͖Δͱߟ͑ΒΕΔɽ͜ΕΛ໰୊఺ 1 Λղফ࣮ͭͭ͠‫͢ݱ‬ΔͨΊʹɼϢʔβ͕௚઀૬खͷ࿈བྷઌΛฉ͔ͳͯ͘΋ɼγεςϜ͕Ҏલʹ੮Λ‫͍ͨͯ͠ʹڞ‬ਓΛࣝผ͠ɼϢʔβʹ‫ۮ‬વͷ࠶ձͷ‫ػ‬ձΛ༩͑ΔΑ͏ʹ͢Δɽ·ͣɼҎલʹ੮Λ‫͍ͨͯ͠ʹڞ‬ਓΛࣝผ͢Δख๏ͱͯ͠ɼ੮Λ‫ʹڞ‬͍ͯͨ͠Ϣʔβͷ‫ܞ‬ଳ୺຤ʹ‫ڞ‬௨ͷ IDʢҎ߱ɼʮΠϕϯτ IDʯʣΛ࣋ͨͤɼ͜ͷ ID Λ༻͍ͯ੮Λ‫ʹڞ‬͍ͯͨ͠Ϣʔβ͔Ͳ͏͔Λ൑ผ͢Δɽͦͯ͠ɼΠϕϯτͷ։࢝࣌ʹɼ͍ͭɾͲ͜ͷΠϕϯτʹࢀՃ͔ͨ͠ͱ͍͏৘ใͱΠϕϯτ ID Λ֤Ϣʔβͷ‫ܞ‬ଳ୺຤Ͱ‫ڞ‬༗ͤ͞Δɽ
·ͨɼ໰୊఺ 2 Λղফ͢ΔͨΊʹɼҎલʹ੮Λ‫ڞ‬ʹ͍ͯͨ͠ਓಉ͕࢜ͦͷ‫߹ډʹۙ͘ͼ࠶ޙ‬Θͤͨͱ͖ʹɼγεςϜ͕ਤ 1.b) ͷΑ͏ͳը໘දࣔͱԻ΍ৼಈʹΑΔ௨஌Λߦ͏Α͏ʹ͢Δɽ͜ͷΑ͏ʹɼ͍ͭɾͲ͜ͷΠϕϯτͰग़ձͬͨਓ͕͍Δ͔ͷ௨஌Λߦ͏͜ͱʹΑͬͯɼϢʔβ͕पғΛ‫ݟ‬ճͯ͠ಉ͡ΠϕϯτʹࢀՃ͍ͯͨ͠ਓΛ୳͖͔͚ͬ͢Λ༩͑ͨΓɼϢʔβ͕༰࢟Λ๨Εͯ͠·ͬͨΓᐆດʹͳͬͨΓ͠- 118 -

͍ͯͨ૬खʹ͍ͭͯ֬৴Λ࣋ͬͨΓ͢Δ͜ͱ͕Ͱ͖
Δͱߟ͑ΒΕΔɽ͞ΒʹɼγεςϜͷ௨஌ʹ‫͍ͮؾ‬ͯಉ͡Α͏ʹ‫ܞ‬ଳ୺຤Λ࣋ͬͯपғΛ‫ݟ‬ճ͍ͯ͠Δ
ਓ͕͍Δ͜ͱʹ‫͖ͮؾ‬ɼͦͷਓʹ஫໨͢Δ͜ͱͰɼ૬खΛಛఆ͠΍͘͢ͳΔͱߟ͑ΒΕΔɽ֤Ϣʔβͷ‫཭ڑ‬Λଌఆ͢Δख๏ͱͯ͠ɼ֤Ϣʔβ͕ॴ༗͍ͯ͠
Δ‫ܞ‬ଳ୺຤ͷҐஔ৘ใΛऔಘ͠ɼऔಘͨ͠Ґஔ৘ใΛαʔόʹૹ৴͠‫ܞ‬ଳ୺຤ؒͷ‫཭ڑ‬Λࢉग़͢ΔɽఏҊγεςϜ͸‫ܞ‬ଳ୺຤্͓Αͼαʔό্ʹ࣮૷͞ΕͨҎԼͷ 5 ͭͷϞδϡʔϧͰߏ੒͞ΕΔɽ

1. Πϕϯτ IDɾΠϕϯτ৘ใ‫ڞ‬༗Ϟδϡʔϧ
2. Ґஔ৘ใऔಘϞδϡʔϧ
3. ୺຤ؒ‫ࢉܭ཭ڑ‬Ϟδϡʔϧ
4. ࠶ձଅਐϞδϡʔϧ
5. ࠶ձ௨஌Ϟδϡʔϧ·ͨɼϞδϡʔϧؒͷؔ܎͸ਤ 2 ͷΑ͏ʹͳΔɽ

3

ࠓ‫ޙ‬ͷ՝୊

࠶ձͨ͠ͱ͖ͷަྲྀͷ͞ΒͳΔࢧԉͷͨΊʹɼఏҊγεςϜ͕ۙ͘ʹҎલ੮Λ‫ͨ͠ʹڞ‬ਓ͕‫ډ‬Δ͜ͱ
Λ௨஌͢Δ͚ͩͰͳ͘ɼ࠶ձͨ͠ͱ͖ʹ࿩͢಺༰ʹ
ର͢ΔࢧԉΛ͢Δ͜ͱ͕‫͛ڍ‬ΒΕΔɽ

ࢀߟจ‫ݙ‬[1] ੢ా ݈ࢤ, ᖛ࡚ խ߂, ‫ ݪ܀‬Ұ‫و‬. ௒ফ‫ۃ‬తͳਓͰ΋҆৺ͯ͠࢖͑ΔֶձͰͷަྲྀଅਐγεςϜ.
WISS2012, pp.103-108, 2012.
[2] ؓ໺ ҏ৫, ాத ೋ࿠. Πϕϯτ։࠵લ͔Β։࠵‫ޙ‬·ͰҰ࿈ͷྲྀΕʹԊͬͯίϛϡχέʔγϣϯΛࢧԉ͢ΔγεςϜ. ϚϧνϝσΟΞ, ෼ࢄ, ‫ڠ‬ௐͱϞόΠϧ (DICOMO2013) γϯϙδ΢Ϝ, pp.56-63,
2013.
[3] D.Dutton and A.Aron. Some Evidence for
Heightened Sexual Attraction under Conditionsof High Anxiety. Journal of Personality and Social Psychology, Vol.30, No.4, pp.510-517, 1974.

WISS2013

ThermoGuideɿද໘Թ౓෼෍Λར༻ͨ͠Ճ೤؅ཧࢧԉख๏੪౻ ਗ਼ོɹɹߴ‫ ڮ‬৳ɹɹాத ೋ࿠ ∗֓ཁ. ຊߘͰ͸ɼαʔϞάϥϑΟΛར༻͠ௐཧதͷϑϥΠύϯ΍৯ࡐͷද໘Թ౓Λ෼ੳ͢Δ͜ͱͰɼՃ೤
ௐཧΛࢧԉ͢Δख๏ΛఏҊ͢Δɽඇ઀৮ͰԹ౓৘ใΛऔಘՄೳͳαʔϞάϥϑΟΛར༻͢Δ͜ͱͰɼௐཧऀ
ͷ࡞‫ۀ‬Λ๦֐͢Δ͜ͱͳ͘Ճ೤ঢ়‫گ‬ͷ൑ผ΍ࡐྉ౤ೖͷ‫ݕ‬஌͕࣮‫ݱ‬ՄೳͱͳΔɽ·ͨɼఏҊख๏ͷదԠྫͱͯ͠ཛম͖࡞੒φϏήʔγϣϯγεςϜͷઃ‫૷࣮ͼٴܭ‬Λߦͬͨɽ͜ΕʹΑͬͯैདྷͷᐆດͳද‫͍༻͕ݱ‬ΒΕ͍ͯͨϨγϐͱ͸ҟͳΔɼఆྔతͳ൑அ‫ج‬४ʹ‫ͮ͘ج‬φϏήʔγϣϯͷՄೳੑΛࣔͨ͠ɽ

1

͸͡Ίʹ

Ճ೤ௐཧʹ͓͍ͯԹ౓؅ཧ͸ɼྉཧͷग़དྷ۩߹Λࠨӈ͢ΔॏཁͳϑΝΫλͰ͋Δɽ͔͠͠ͳ͕ΒɼҰൠతͳྉཧͰଟ͘ࢀߟʹ͞Ε͍ͯΔϨγϐจͰ͸ɼᐆດͳද‫͞ͳ͕ݱ‬Ε͍ͯΔ͜ͱ͕ଟ͘ɼௐཧॳ৺ऀ
͕ద੾ͳԹ౓؅ཧΛߦ͏্Ͱͷো֐ͱͳ͍ͬͯΔɽ
ҰํͰɼਖ਼֬ͳԹ౓؅ཧ͕ඞཁͳྉཧʹؔͯ͠͸Թ౓‫ܭ‬Λ༻͍ͯௐཧΛߦ͏͕ɼԹ౓‫͕ͤࢗܭ‬Δྉཧʹ‫ݶ‬ఆ͞ΕΔ্ɼૉૣ͍࡞‫͕ۀ‬ඞཁͳௐཧͰ͸ଌఆ͠
͍ͯΔՋ͕ͳ͍ͱ͍͏ܽ఺΋͋Δɽ৯ࡐͷԹ౓෼෍ͷมԽ͸Ұ༷Ͱ͸ͳ͘ɼ೤‫͔ݯ‬Βͷ‫཭ڑ‬΍৯ࡐͷछྨʹΑͬͯ΋·ͪ·ͪͱͳΔͨΊɼ1 ఺ͷԹ౓Ͱ͸஌ΓಘΔ৘ใ΋‫ݶ‬ΒΕͯ͘Δɽ
ͦ͜Ͱզʑ͸ɼඇ઀৮ͰԹ౓෼෍ΛऔಘՄೳͳαʔϞάϥϑΟΛར༻͠ɼௐཧதͷՃ೤؅ཧΛࢧԉ͢Δख๏ΛఏҊ͢Δɽ‫ط‬ଘͷ‫ͯ͠ͱڀݚ‬ϑϥΠύϯͷத৺Թ౓ʹ‫͍ͨͮج‬φϏήʔγϣϯγεςϜ [1] ͕͋Δ͕ɼຊ‫Ͱڀݚ‬͸ௐཧ໘ͷԹ౓Λ‫͢ࢹ؂‬Δ͜ͱͰɼશମͷՃ೤۩߹ͷ൑ผ͔Β‫ॴہ‬తͳࡐྉͷՐͷ௨Γ۩߹·Ͱ෯޿͍Ճ೤ͷαϙʔτΛ໨ࢦ͢ɽ·ͨɼఏҊख๏ͷద༻ྫͱͯ͠ཛম͖࡞੒φϏήʔγϣϯγεςϜͷઃ‫͓ܭ‬Αͼ࣮૷Λߦ͍ɼγεςϜʹؔ͢Δ࣮‫ݧ‬Λߦͬͨɽ

2ද໘Թ౓෼෍Λར༻ͨ͠Ճ೤؅ཧࢧԉ3

Copyright is held by the author(s).
Kiyotaka Saito, ஜ೾େֶେֶӃ γεςϜ৘ใ޻ֶ‫ڀݚ‬Պ ίϯϐϡʔλαΠΤϯεઐ߈, Shin Takahashi and Jiro
Tanaka, ஜ೾େֶ γεςϜ৘ใ‫ܥ‬- 119 -

ࢼ࡞ɿཛম͖࡞੒φϏήʔγϣϯγεςϜ

ຊ‫Ͱڀݚ‬ఏҊ͢ΔՃ೤؅ཧख๏ͷద༻ྫͷҰͭͱͯ͠ཛম͖࡞੒φϏήʔγϣϯγεςϜΛ࡞੒ͨ͠ɽ
ཛ͸‫·ݻ‬Γํ͕Թ౓ʹେ͖͘ґଘ͠ɼԹ౓ͷௐ੔ϛεʹΑΔࣦഊ͕ಛʹੜ͡΍͍͢ɽ·ͨɼཛશମ͕‫ݻ‬·Δ·Ͱ͔ͬ͠ΓՃ೤Ͱ͖͔ͨɼ෦෼తʹՃ೤͕͞Ε͍͗ͯ͢ͳ͍͔ɼͱ͍ͬͨঢ়‫گ‬͸ 1 ఺ͷԹ౓͚ͩͰ͸൑ผ͕೉͍͠ɽͦͷͨΊɼຊ‫Ͱڀݚ‬ఏҊ͢Δද
໘Թ౓෼෍Λ༻͍ͨঢ়‫گ‬ਪఆ͕‫͔͞׆‬ΕΔͱߟ͑ͨɽ

3.1

Ճ೤ௐཧΛͲΕ͚ͩͷ࣌ؒߦ͏΂͖͔͸ɼՐՃ‫ݮ‬ɼ৯ࡐͷྔɼௐཧ‫۩ث‬ͷछྨͳͲͷ৚݅ʹΑͬͯมԽ͢Δ [2]ɽͦ͜ͰɼՃ೤ঢ়‫܎ؔʹ઀ີͱگ‬ͷ͋Δද
໘Թ౓෼෍Λऔಘ͠ɼௐཧঢ়‫گ‬Λೝࣝ͢Δɽ۩ମతʹ͸ɼද໘Թ౓෼෍͔Β‫͖Ͱࢉܭ‬Δద౰ͳಛ௃ྔΛɼՃ೤Λे෼ʹߦ͔ͬͨͲ͏͔ͷࢦඪͱ͠
ͯ༻͍Δɽྫ͑͹ɼϑϥΠύϯͷ༨೤͕‫͔ͨྃ͠׬‬Ͳ͏͔͸ɼద੾ͳԹ౓ʹͳͬͨྖҬ͕े෼ʹ޿͕ͬ∗

͍ͯΔ͔Ͳ͏͔Ͱ൑அͰ͖Δɽ·ͨɼࡐྉͷ౤ೖ࣌ʹ͸ද໘Թ౓͸Ұ‫ݮʹؾ‬গ͢ΔͨΊɼߴԹྖҬͷ‫ݮ‬গʹΑͬͯ൑அՄೳͱͳΔɽ͜ͷΑ͏ʹɼௐཧͷࢦඪͱͯ͠ϑϥΠύϯ໘ੵʹର͢Δɼ͋ΔԹ౓Ҏ্/ҎԼͷྖҬͷׂ߹Λར༻͢Δɽ·ͨɼ୯७ͳࢦඪͱ͠
ͯௐཧྖҬͷ࠷௿Թ౓΍࠷ߴԹ౓΋ซͤͯར༻͢Δɽ͜ΕΒͷख๏Λ༻͍Δ͜ͱͰɼϑϥΠύϯࣗମͷՃ೤΍ࡐྉʹՐ͕௨͔ͬͨͲ͏͔ͷ൑ผ͋Δ͍͸Ճ೤Λ͠ա͗ͱ͍ͬͨԹ౓্ঢʹؔ͢Δ৚݅ઃఆ͕Ͱ
͖Δͱಉ࣌ʹɼ৯ࡐ͕ೖͬͨλΠϛϯάͷೝࣝ΍Ճ೤ͨ͠৯ࡐΛྫྷ·͢৔߹ͳͲԹ౓௿Լʹؔ͢Δ৚݅ͱͯ͠΋ར༻͢Δ͜ͱ͕ՄೳͱͳΔɽ͜ΕΒΛ༻͍
Δ͜ͱͰɼैདྷᐆດͳද‫͍༻͕ݱ‬ΒΕ͍ͯͨϨγϐจʹ͓͍ͯઈରతͳࢦඪΛઃ͚Δ͜ͱ͕ՄೳͱͳΔɽ

γεςϜ֓ཁ

ຊγεςϜͰ͸ɼน໘σΟεϓϨΠʹදࣔ͞ΕΔ
GUI ͓ΑͼεϐʔΧʔ͔ΒྲྀΕΔԻ੠ʹΑͬͯϢʔβΛφϏήʔτ͢ΔɽγεςϜར༻࣌ͷΩονϯ಺ͷ༷ࢠ͓ΑͼφϏήʔγϣϯ GUI Λਤ 1(a) ʹࣔ͢ɽGUI ࠨ෦ʹ͸ௐཧ࣌ͷө૾ͱͦΕʹରԠ͢ΔԹ
౓෼෍͕ॏ৞දࣔ͞Ε͍ͯΔɽ͜͜Ͱ͸໨ඪԹ౓ʹ
ୡ͍ͯ͠Δ෦෼ͷΈ೤ը૾දࣔΛߦ͓ͬͯΓɼՃ೤͕଍Γͳ͍෦෼͸ͦͷ··ௐཧө૾Λද͍ࣔͯ͠ΔɽͦͷͨΊɼͲͷՕॴͷՃ೤͕଍Γͳ͍͔Λͻͱ໨Ͱ
֬ೝ͢Δ͜ͱ͕ՄೳͱͳΔɽ·ͨɼγεςϜଆͰ͸ஞ࣍ௐཧঢ়‫گ‬Λ‫͓ͯ͠ࢹ؂‬ΓɼՃ೤ঢ়‫ʹگ‬Ԡͯ͡ୡ੒౓͕Πϥετͱ਺஋Ͱࣔ͞ΕΔɽͦͯ͠ɼୡ੒౓WISS 2013(a) φϏήʔγϣϯ GUI(b) γεςϜߏ੒ਤਤ 1. φϏήʔγϣϯγεςϜ

͕ 100 ˋʹͳΔͱࣗಈͰϨγϐ͕νΣοΫ͞Εɼ࣍ͷࢦࣔʹ੾ΓସΘΔͱಉ࣌ʹԻ੠ʹΑͬͯࢦࣔจ͕
ಡΈ্͛ΒΕΔɽͦͷͨΊɼϢʔβ͸γεςϜʹରͯ͠ೖྗ౳Λߦ͏ඞཁ͸ͳ͘ɼө૾΍ୡ੒౓ͱ͍ͬ
ͨ৘ใΛࢀߟʹ͠ͳ͕ΒɼࣗಈͰఏࣔ͞Ε͍ͯ͘φϏήʔγϣϯʹैͬͯௐཧΛߦ͑͹Α͍ɽ

3.2

γεςϜߏ੒

ຊ‫Ͱڀݚ‬͸Թ౓औಘͷͨΊɼνϊʔࣾ੡೤ը૾ηϯα TP-H0225AN Λ࢖༻ͨ͠ɽ͜ͷηϯα͸෺ମͷ੺֎ઢ์ࣹΤωϧΪʔΛ‫ݕ‬ग़͢Δ͜ͱͰඇ઀৮ͷԹ౓‫ݕ‬஌Λ࣮‫͢ݱ‬Δɽ
γεςϜߏ੒ਤΛਤ 1(b) ʹࣔ͢ɽΩονϯͷน໘ʹσΟεϓϨΠͱεϐʔΧʔ͕ઃஔ͞Ε͓ͯΓɼͦͷ্෦ʹαʔϞάϥϑΟͱ web Χϝϥ͕Լ޲͖Ͱ
‫ݻ‬ఆ͞Ε͍ͯΔɽweb Χϝϥ͔Βऔಘ͞Εͨө૾͸USB ‫ܦ‬༝ͰɼαʔϞάϥϑΟ͔Βऔಘ͞Εͨ৘ใ
͸ LAN ‫ܦ‬༝ͰͦΕͧΕίϯϐϡʔλʹૹ৴͞ΕΔɽ

4ධՁ࣮‫ݧ‬

4.1

࣮‫಺ݧ‬༰

γεςϜͷ࢖༻‫͕͍ͩͯͭʹײ‬ɼγεςϜ͕ௐཧঢ়‫گ‬Λೝࣝ͠ਐΈ۩߹ΛࣗಈͰνΣοΫ͢Δ‫ػ‬ೳ͸ඇৗʹ޷ධͰ͋ͬͨɽ·ͨɼୡ੒౓දࣔʹΑΓ‫ࡏݱ‬ͷ࡞‫͍͕ͭۀ‬ऴྃ͢Δ͔Λ͋Β͔͡Ί༧ଌͰ͖ͨͨ
Ίɼૉૣ࣍͘ͷ࡞‫ʹۀ‬ҠΔ͜ͱ͕Ͱ͖͍ͯͨ͜ͱ΋ར఺ͱͯ͠ߟ͑ΒΕΔɽ͔͠͠ɼௐཧதʹཛͷ‫͖ר‬ํͳͲಈ࡞ͷ໘ʹ͓͍ͯඃ‫͕ۤऀݧ‬ઓ͢Δ༷ࢠ͕‫ݟ‬ΒΕͨɽࠓ‫ޙ‬͸จࣈʹΑΔࢦ͚ࣔͩͰ͸ͳ͘ɼಈ࡞
ʹؔ͢ΔφϏήʔγϣϯ͕ඞཁͱߟ͑ΒΕΔɽ5·ͱΊͱࠓ‫ޙ‬ͷൃలຊ‫Ͱڀݚ‬͸ɼඇ઀৮ͰԹ౓෼෍ΛऔಘՄೳͳαʔϞάϥϑΟΛར༻͠ௐཧதͷՃ೤؅ཧΛࢧԉ͢Δख๏ΛఏҊͨ͠ɽ·ͨɼఏҊख๏ͷద༻ྫͱͯ͠ཛম͖
࡞੒φϏήʔγϣϯγεςϜͷઃ‫૷࣮ͼٴܭ‬Λߦ͍ɼ࣮‫ݧ‬Λ௨ͯ͡ैདྷͷϨγϐจʹ୅ΘΔΑ͏ͳఆྔత
ͳ‫ج‬४ʹ‫ͮ͘ج‬φϏήʔγϣϯͷՄೳੑΛࣔͨ͠ɽࠓ‫ޙ‬ͷൃలͱͯ͠ɼཛম͖Ҏ֎ͷద༻ྫΛ࣮‫͠ݱ‬ɼ༷ʑͳछྨͷྉཧʹ͓͍ͯ΋ఏҊख๏͕༗ޮͰ͋Δ
͔ʹ͍ͭͯ‫ূݕ‬Λߦ͍ͬͯ͘༧ఆͰ͋ΔɽφϏήʔγϣϯγεςϜΛ༻͍ͯௐཧॳ৺ऀͷඃ‫ʹऀݧ‬ཛম͖ͷ࡞੒Λߦͬͯ΋Βͬͨɽඃ‫ऀݧ‬͸ௐཧॳ৺ऀͷେֶੜɾେֶӃੜ 4 ໊ʢஉੑ 3 ໊ɼঁੑ1 ໊ʣͰ͋Γɼ͍ͣΕͷඃ‫ऀݧ‬΋ཛম͖ͷௐཧ͸ࠓճ͕ॳΊͯͰ͋ͬͨɽ

4.2

ਤ 2. ࣮‫ ݧ‬ௐཧ݁Ռ݁Ռͱߟ࡯ࢀߟจ‫ݙ‬

࣮‫Ͱݧ‬ඃ‫࡞͕ऀݧ‬੒ͨ͠ཛম͖ͷҰཡΛਤ 2 ʹࣔ͢ɽ͍ͣΕͷཛম͖΋ɼද໘͕য͍͛ͯͨΓཛ͕‫ݻ‬·Γ͖͍ͬͯͳ͍ͱ͍ͬͨ͜ͱ͸ͳ͘ɼ͓͓ΉͶௐཧΛ੒ޭ͢Δ͜ͱ͕Ͱ͖͍ͯͨɽ͜ͷ͜ͱΑΓɼࠓճॳΊͯཛম͖ʹ௅ઓͨ͠ඃ‫͍͓ͯʹऀݧ‬΋ຊ‫ڀݚ‬ͰఏҊ͢Δද໘Թ౓෼෍ʹ‫ͮ͘ج‬φϏήʔγϣϯʹΑΓద੾ͳௐཧखॱΛಋ͘͜ͱ͕Ͱ͖ͨͱ͍͑Δɽ

- 120 -

[1] D. Uriu, M. Namai, S. Tokuhisa, R. Kashiwagi, M. Inami, and N. Okude. panavi: Recipe
Medium with a Sensors-Embedded Pan for Domestic Users to Master Professional Culinary
Arts. In Proc. of CHI’12, pp. 129–138, 2012.
[2] ौ઒ ঵ࢠ. ௐཧʹ͓͚ΔՃ೤ͷ‫ج‬ຊ. ೔ຊ৯ੜ‫׆‬ֶձࢽ, 17(2):89–93, 2006.

WISS2013

Harry: ϖʔύʔΫϥϑτ͔Βͷ 3 ࣍‫ݩ‬Ϟσϧੜ੒ࡾӜ ‫∗تݩ‬ࢁຊ ক࢙†

֓ཁ. Ұൠʹɼ3D ͷϞσϦϯάΛߦ͏ͨΊʹ͸Ϛ΢ε΍ΩʔϘʔυΛ‫ٻ͕࡞ૢͨ͠࢖ۦ‬ΊΒΕΔͨΊෑ‫͍ߴ͕ډ‬ɽͦ͜Ͱզʑ͸ϖʔύʔΫϥϑτʢࢴ޻࡞ʣ͔Β 3D ϞσϧΛखܰʹߏங͢Δख๏ Harry ΛఏҊ͢Δɽମ‫͕ऀݧ‬ϖʔύʔΫϥϑτΛ࡞੒͢Δࡍɼࢴ͔Β‫ܗ‬ঢ়Λ੾ΓऔΔલʹɼ‫ܗ‬ঢ়ͷྠֲઢΛσΟδλϧϖ
ϯͰೖྗ͢Δɽͦͷ‫ޙ‬ɼࢴΛ૊Έ߹ΘͤͨΓ઀ணͨ͠ՕॴΛϖϯͰͳͧΔ͜ͱʹΑͬͯɼ‫ܗ‬ঢ়ಉ࢜ͷ઀ଓ఺΍ંΕઢΛ‫ʹػࢉܭ‬ೖྗ͢Δɽೖྗ͞Εͨྠֲઢ΍઀ଓ఺Λߟྀͨ͠෺ཧԋࢉΛߦ͏͜ͱʹΑΓɼ3 ࣍‫ܗݩ‬ঢ়Λߏ੒͢ΔɽγεςϜΛߏங͠ɼϥϑͳ 3D Ϟσϧ͕खܰʹ࡞੒Ͱ͖Δ͜ͱΛ֬ೝͨ͠ɽ

1

͸͡Ίʹ

ଟ͘ͷਓʹͱͬͯɼࢴ͸࠷΋਎ۙͰѻ͍΍͍͢‫ه‬࿥ɾද‫ݱ‬ഔମͰ͋Δɽ૷০΍Ճ޻͕༰қͰ͋Δ͜ͱ͔Βɼ༮ࣇ‫͔ظ‬ΒృΓֆ΍ંΓࢴɼ੾Γࢴ΍޻࡞౳ͷཱମ෺Λ‫ؚ‬Ή૑࡞‫׆‬ಈʹ༻͍ΒΕΔ͜ͱ͕ଟ͍ɽ
·ͨɼࢴͰͷ૑࡞‫׆‬ಈΛ֦ு͢ΔͨΊͷ‫ࢧػࢉܭ‬ԉ‫ڀݚ‬΍γεςϜ΋ఏҊ͞Ε͍ͯΔɽྫ͑͹ colAR
App[2] ͸ృΓֆΛλϒϨοτͷΧϝϥͰऔΓࠐΉ
ͱɼ3D ͷίϯϐϡʔλάϥϑΟοΫεʹม‫ͯ͠׵‬ɼΞχϝʔγϣϯදࣔ͢ΔΞϓϦέʔγϣϯͰ͋Δɽ
·ͨࡾ୩͸ 2 ࣍‫ݩ‬όʔίʔυ͕྆໘ʹҹ࡮͞ΕͨࢴΛ༻͍ͨɼࢴͷંΓ৞Έߏ଄Λਪఆɾೝࣝ͢Δख๏
Λߏங͍ͯ͠Δ [3]ɽҰൠʹɼ3DCG Λ੡࡞͢ΔͨΊͷϞσϦϯάιϑ
τ΍ CAD γεςϜ͸ߴ‫ػ‬ೳͰ͋Δ൓໘ɼૢ࡞͕ෳ
ࡶͰ͋ΔͨΊɼϚ΢ε΍ΩʔϘʔυΛ‫࡞ૢͨ͠࢖ۦ‬͕ඞཁͰ͋Δɽ͜ͷͨΊɼPC ૢ࡞ʹ‫׳‬Ε͍ͯͳ͍Ϣʔβʹͱͬͯɼ3D ͷϞσϧΛࣗࡏʹ࡞੒͢Δ͜ͱ͸ࠔ೉Ͱ͋Δɽզʑ͸ΑΓଟ͘ͷਓ͕ 3DCG ੡࡞ʹؔΘΓΛ΋ͯΔΑ͏ʹ͢ΔͨΊʹɼࢴ޻࡞Λ࡞੒
͢Δաఔʹ͓͍ͯσΟδλϧϖϯʹΑΔච‫ه‬৘ใΛ௥Ճ͢Δ͜ͱͰɼ3D ϞσϧΛੜ੒͢Δख๏ HarryΛఏҊ͢Δɽ

2ఏҊख๏ Harryզʑ͕ఏҊ͢Δ 3D ϞσϦϯάख๏ Harry ͸ɼϖʔύʔΫϥϑτΛ࣮ࡍʹ࡞੒͢Δաఔʹ͓͍ͯɼࢴͷύʔπͷྠֲ΍ύʔπͷ઀ଓ఺ΛσΟδλϧϖϯʹ
Αͬͯࢦఆ͢Δ͜ͱʹΑΓɼύʔπͷۭؒతͳؔ܎
Λ‫ه‬ड़͠ɼ3D ϞσϧΛੜ੒͢Δ΋ͷͰ͋Δɽ͢ͳΘͪɼࢴʹରͯ͠ด‫ۂ‬ઢΛ‫ه‬ड़͢Ε͹ɼ‫ʹ্ػࢉܭ‬͸ಉ͡Α͏ͳ‫ܗ‬Λͨ͠ด‫ۂ‬໘Λग़ྗ͠ɼࢴͷ্ͷ೚ҙͷೋ఺Λࢦఆ͢Ε͹ɼ‫Ͱ্ػࢉܭ‬͸ͦͷ 2 ఺Λͭͳཱ͍ͩମϞσϧΛग़ྗ͢Δɽ͜ͷΑ͏ʹɼσΟδλϧϖϯΛϖʔύʔΧολ΍εςʔϓϥʹ‫ཱͨͯݟ‬ૢ࡞Λߦ͏ͱɼ‫ࢴʹ্ػࢉܭ‬Λ໛ͨ͠ฏ໘͋Δ͍͸‫ۂ‬໘ͷϙϦΰϯϞσϧΛग़ྗ͢Δɽฏ໘·ͨ͸‫ۂ‬໘ͷ‫ܗ‬ঢ়͸ɼ‫ੈ࣮ݱ‬քͷࢴͷ‫ڍ‬ಈΛ໛ͨ͠෺ཧԋࢉʹΑͬͯਪఆ͢Δɽίϯϐϡʔλ্ʹग़ྗ͢Δ໘͸ɼࢴͷΑ͏ͳɼ‫ʹ͛ۂ‬ରͯ͠ͷ఍߅ʢϋϦʣ͕͋Δࡐ࣭Λ૝ఆ͍ͯ͠ΔɽͦͷͨΊɼฏ໘্ͷ 2 ఺Λͭͳ͙ͱ͍ͬͨૢ࡞ͷΈͰɼཱମతͳϞσϧΛੜ੒͢Δ
͜ͱ͕Ͱ͖Δɽਤ 1 ʹɼఏҊख๏ͷུ֓ਤΛࣔ͢ɽ

ਤ 1. ఏҊख๏ͷུ֓ɿσΟδλϧϖϯͰࢴͷ੾औΓ‫ܗ‬ঢ়ͱ઀ଓ఺Λࢦఆ͢ΔͱɼରԠ͢Δ 3D ϞσϧΛ
ੜ੒

2.1

࡞੒खॱ

Ϟσϧ࡞੒ऀ͸ɼ࠷ॳʹΞϊτํࣜͷσΟδλϧ
ϖϯͰࢴʹύʔπͷྠֲΛࣗ༝ͳด‫ۂ‬ઢͰ‫ه‬ೖ͢Δɽ
͢Δͱਤ 2 ࠨʹࣔ͢Α͏ͳฏ໘Ϟσϧ͕ը໘ʹදࣔ͞ΕΔɽ࣍ʹϞσϧ࡞੒ऀ͕ϖϯͰࢴ্ͷ 2 ఺Λλοϓૢ࡞Ͱࢦఆ͢Δ͔ɼࢴΛॏͶͨঢ়ଶͰ઀ଓ෦෼Λ
ͳͧΔૢ࡞ (εΩϟϯ) Λߦ͏ͱɼਤ 2 ӈʹࣔ͢Α͏ʹࢦఆ෦෼Λ઀ଓͨ͠ 3D Ϟσϧ͕ը໘ʹදࣔ͞Ε
Δɽͳ͓ը໘ͷฏ໘Ϟσϧʹରͯ͠Ϛ΢εͰ઀ଓ఺Λ௥Ճͨ͠Γɼ࡟আ͢Δ͜ͱ΋ՄೳͰ͋Δɽ

2.2

ఏҊख๏ͷར఺ͱܽ఺

ࢴʹରͯ͠ϖϯͰ‫ه‬ड़͢Δͱ͍͏࡞‫ۀ‬͸୯७Ͱ͋Γɼ͔ͭ 3D ϞσϦϯάʹؔ͢Δෳࡶͳ஌ࣝΛඞཁͱ͠ͳ͍ɽͦͷͨΊɼίϯϐϡʔλʹෆ‫׳‬Εͳਓ΋

Copyright is held by the author(s).
∗‫۝‬भ޻‫ۀ‬େֶ ‫ૅج‬Պֶ‫ܥڀݚ‬†‫۝‬भ޻‫ۀ‬େֶ ޻ֶ෎ ઌ୺‫ػ‬ೳγεςϜ޻ֶઐ߈- 121 -WISS 2013

ਤ 2. ฏ໘Ϟσϧ (ࠨ) ͱɼཱମϞσϧ (ӈ)‫ؚ‬Ίͨଟ͘ͷਓ͕ೃછΈͷ͋Δ༰қͳ࡞‫͋Ͱۀ‬Δͱ
ࢥΘΕΔɽ͜ͷ͜ͱ͔Βɼ͜ͷख๏Ͱ͸෯޿͍Ϣʔβ͕ɼൺֱత༰қʹϞσϧΛ੍࡞Ͱ͖Δ΋ͷͱࢥΘΕΔɽ
·ͨࢴͱϖϯΛ࢖༻͢Δ͜ͱʹΑΔར఺΋͋Δɽ
ϖϯσόΠε͸ɼϚ΢εͱൺ΂Δͱਓ͕ؒਖ਼֬ʹૢ
࡞͢Δ͜ͱ͕Ͱ͖Δ΋ͷͰ͋Δɽ͜ͷ͜ͱ͔Βɼด‫ۂ‬໘ͷ‫ܗ‬ঢ়Λࢦఆ͢Δૢ࡞ʹ͓͍ͯɼϢʔβ͸ΑΓਖ਼֬ʹɼෆշ‫͘ͳײ‬Πϝʔδͨ͠‫ܗ‬ঢ়Λද‫͖Ͱݱ‬Δ
ͱߟ͑ΒΕΔɽಛʹɼෳࡶͳԜತΛ࣋ͭΑ͏ͳด‫ۂ‬໘ͷ‫ܗ‬ঢ়Λೖྗ͢ΔࡍʹɼσΟδλϧϖϯ͸Ϛ΢ε
ΑΓ΋༰қʹೖྗ͕ߦ͑Δͱ͍͏ར఺͕͋Δɽ‫ه‬ड़ର৅͕ࢴͰ͋Γɼഁ‫غ‬ɾަ‫͕׵‬༰қʹՄೳͰ͋ΔͨΊɼ࣮ࡍʹ‫͛ۂ‬ΔɾંΔͱ͍ͬͨࢼߦࡨ‫͕ޡ‬༰қʹߦ͑Δͱ‫ͨͬݴ‬௕ॴ΋͋Δɽ͞Βʹɼࢴͱ͍͏࣮෺
ମΛૢ࡞͢Δ‫֮ײ‬Λ൐͏ͨΊɼλϯδϒϧ͔ͭ௚‫ײ‬తͳϝσΟΞͱ͍͏༏Ґੑ΋͋Δɽ
ͦͷ൓໘ɼఏҊख๏Ͱ͸ɼંΓํͷৄࡉʢࢁંΓɼ୩ંΓʣ΍‫཰ۂ‬ͷઃఆͱ͍ͬͨɼෳࡶͳཱମ‫ܗ‬ঢ়Λ੍࡞͢Δʹ͸ෆ޲͖Ͱ͋Δɽ͓͓·͔ͳ‫ܗ‬ঢ়Λ࡞੒͢Δஈ֊Ͱ͸ࢴͱϖϯΛ༻͍ɼࡉ͔ͳௐ੔ʹ͍ͭͯ͸Ϛ΢εΛ༻͍ɼը໘ͷมԽΛ‫͕ͳ͠࡯؍‬Βૢ࡞͢
Δํ๏͕ద੾Ͱ͋Δͱߟ͍͑ͯΔɽ

3

ؔ࿈‫ڀݚ‬

ࡾ୩ [3] ͸ɼંΓͨͨ·ΕͨࢴΛࡱӨͨ͠σΟδλϧը૾͔ΒંΓͨͨΈߏ଄Λೝࣝ͠ɼ‫ʹ಺ػࢉܭ‬ϞσϧԽ͢Δख๏ΛఏҊ͍ͯ͠Δɽ2 ࣍‫ݩ‬όʔίʔυΛදཪʹ֨ࢠঢ়ʹෳ਺ҹ࡮ͨ͠ࢴΛ༻͍ɼંΔૢ࡞Λߦ͏ͨͼʹࡱӨ͢Δ͜ͱʹΑͬͯɼࢴͷߏ଄Λೝ͍ࣝͯ͠Δɽࢴͷঢ়ଶΛஞ࣍‫ه‬࿥͠ɼ3D Ϟσϧߏ੒ͷͨΊͷೖྗʹ༻͍Δͱ͍͏఺͸ྨࣅੑ͕͋Δɽ
ͨͩ͠զʑͷख๏͸ࢴ͕ॏྗͰંΕ‫͕ۂ‬Δͱ͍ͬͨɼ
‫ۂ‬໘Λ‫ؚ‬ΉΑ͏ͳ‫ܗ‬ঢ়ʹ͍ͭͯ΋ߏ੒Ͱ͖Δͱ͍͏
఺͕ҟͳΔɽ
‫ेޒ‬ཛྷΒͷ Teddy[1] ͸ɼॳ৺ऀͰ΋༰қʹ 3D
ϞσϧΛ࡞੒͢Δ͜ͱ͕Ͱ͖Δखܰͳ 3D ϞσϦϯ- 122 -

άπʔϧͰ͋Δɽը໘ʹରͯ͠ྠֲ‫ܗ‬ঢ়Λඳ͘͜ͱͰɼ‫͕ػࢉܭ‬ద੾ͳ 3D ϞσϧΛਪଌ͠ग़ྗ͢Δɽ
3D Ϟσϧͷग़ྗ͸ϦΞϧλΠϜʹߦΘΕɼࢹ఺ͷมߋ΍ɼ௥‫ه‬Λߦ͏͜ͱ͕Ͱ͖ɼର࿩తʹϞσϦϯ
ά͕ߦ͑Δπʔϧͱͳ͍ͬͯΔɽఏҊख๏͸࣮ࡏ͢
Δʮࢴʯʹ৮Εɼૢ࡞͠ͳ͕ΒϞσϦϯάΛߦ͑Δ
ͱ͍͏఺͕ҟͳΔɽ
ೖྗσόΠεΛվྑ͢Δ͜ͱʹΑͬͯɼ௚‫ײ‬తͳϞσϦϯάΛՄೳʹ͢Δ‫ͯ͠ͱڀݚ‬ɼ࿬ాΒ͕ఏҊͨ͠ pSurface[4] Λ‫͛ڍ‬Δ͜ͱ͕Ͱ͖ΔɽpSurface͸ɼࣗ༝‫ۂ‬໘ͷϞσϦϯάΛߦ͏͜ͱ͕Ͱ͖Δ෍੡
σόΠεͰ͋Δɽ࣮ࡍʹखͰม‫ͤ͞ܗ‬Δ͜ͱͰɼͦ
ͷ‫ܗ‬ঢ়Λೖྗ͢Δ͜ͱ͕Ͱ͖Δɽ·ͨɼϚ΢εૢ࡞౳ʹΑͬͯϞσϧʹߦͬͨमਖ਼Λɼ࣮෺ମ্ʹϑΟʔυόοΫ͢Δ͜ͱ΋Ͱ͖ΔɽpSurface ΋࣮ମͷૢ࡞ʹΑΓ 3D ϞσϧΛૢ࡞͢Δ͜ͱ͕Ͱ͖Δ఺͸ྨࣅੑ͕͋Δ͕ɼηϯα΍ΞΫνϡΤʔλͷ੍໿ʹΑΓɼ࡞੒Մೳͳ‫ܗ‬ঢ়͸ຊఏҊख๏ʹൺ΂Δͱ‫ݶ‬ఆ͞ΕΔɽ

4·ͱΊͱࠓ‫ޙ‬ͷ՝୊ࢴͷಛੑͱσΟδλϧϖϯΛར༻ͨ͠ 3D ϞσϦϯάख๏ΛఏҊͨ͠ɽࢴͱϖϯͱ͍͏‫׳‬Ε਌͠ΜͩཁૉΛ༻͍Δ͜ͱʹΑΓɼ͜Ε·ͰΑΓ΋෯޿͍ํʑ
ʹ 3D ϞσϦϯά‫ڥ؀‬Λఏ‫͢ڙ‬Δ‫ج‬൫Λఏ‫͖Ͱڙ‬Δɽ
γεςϜΛߏங͠ɼϥϑͳ 3D Ϟσϧ͕खܰʹ࡞੒
Ͱ͖Δ͜ͱΛ֬ೝͨ͠ɽຊ‫Ͱڀݚ‬ड़΂ͨ಺༰͸ɼࢴͱϖϯͷಛੑΛར༻ͨ͠؆ศͳೖྗख๏ͷ 1 ͭͷద༻ྫͰ͋Δ͕ɼ൚༻ੑ͕ߴ͍ͨΊଞͷ૑࡞ࢧԉ΍ֶशࢧԉʹ΋ద༻ՄೳͰ͋Δͱߟ͍͑ͯΔɽँࣙຊ‫ڀݚ‬ͷҰ෦͸ JSPS Պ‫ݚ‬අʢ՝୊൪߸ 23680078ʣ
ͷࢧԉʹΑΔ΋ͷͰ͢ɽࢀߟจ‫ݙ‬[1] T. Igarashi, S. Matsuoka, and H. Tanaka. Teddy:a sketching interface for 3D freeform design.
In Proceedings of the 26th annual conference
on Computer graphics and interactive techniques(SIGGRAPH ’99), pp. 409–416, New York, NY,
USA, 1999. ACM Press/Addison-Wesley Publishing Co.
[2] Puteko
Limited.
colAR
App.
http://colarapp.com/ (2013 ೥ 10 ݄ 18 ೔ ֬ೝ).
[3] ࡾ୩ ७. 2 ࣍‫ݩ‬όʔίʔυΛ༻͍ͨࢴͷંΓͨͨΈߏ଄ͷೝࣝͱͦͷϞσϧԽ. ৘ใॲཧֶձ࿦จ
ࢽ, 48(8):2859–2867, Aug. 2007.
[4] ࿬ా ྰ, ্໺ ಓ඙, த໺ ѥ‫ر‬ਓ. pSurface: ࣗ༝‫ۂ‬໘ϞσϦϯάͱΞχϝʔγϣϯͷͨΊͷ෍੡ೖग़ྗσόΠε. ৘ใॲཧֶձ ΠϯλϥΫγϣϯ 2011,
Feb. 2011.

WISS2013࿩ऀʹΑΔਖ਼֬ͳϙΠϯςΟϯάͷͰ͖ΔϓϨθϯςʔγϣϯγεςϜएদ ᠳɹɹകଜ ‫࢘ګ‬ɹɹࡾྠ ଟ‫ࢠܙ‬ɹɹԬ෦ ਖ਼޾∗
֓ཁ. ϓϨθϯςʔγϣϯʹ͓͍ͯεϥΠυͷ͋Δ෦෼ʹௌऀͷ஫໨ΛूΊΔํ๏ͱͯ͠, ϙΠϯςΟϯ
άσόΠεͷར༻΍Ξχϝʔγϣϯͷ࢖༻͕‫͛ڍ‬ΒΕΔ. ࿩͍ͯ͠ΔՕॴͷ‫ڧ‬ௐ΍৘ใͷॱং΍ྲྀΕΛද‫ݱ‬Ͱ͖Δ͕, ࢖༻͢ΔλΠϛϯά΍ࢦ͍ͯ͠ΔՕॴΛ‫ޡ‬Δͱௌऀ͸࿩ͷྲྀΕ͕௫Ίͳ͔ͬͨΓ, ͦͷ‫ޙ‬ͷઆ໌ʹ͍͍͚ͭͯͳ͘ͳΔ‫ݥة‬ੑ͕͋Δ. ຊ‫Ͱڀݚ‬͸, ࿩ऀࣗ਎͕ϙΠϯςΟϯάσόΠεͱͳΓൃදΛߦ͏͜ͱ͕Ͱ͖ΔϓϨθϯςʔγϣϯπʔϧʹ͓͍ͯ, ࿩ऀ͕ࢦఆͨ͠Ґஔʹਖ਼֬ʹϚʔΩϯά͢Δํ๏Λࣔ͢.
࿩ऀͷಈ࡞ͱ࿈ಈ͠εϥΠυ্ͷදࣔϙΠϯτʹϚʔΧ͕഑ஔͰ͖ΔͨΊ, ໌ࣔతʹ஫໨ՕॴΛࣔ͢͜ͱ͕ՄೳͰ͋Δ. ͞Βʹ, ධՁ࣮‫ݧ‬Λߦ͍ҰఆͷධՁΛಘͨͷͰใࠂ͢Δ.

͸͡Ίʹ

1

ΛूΊΔࡍʹ༗ޮͰ͋Δ.

ۙ೥, ֶձ΍ษ‫ڧ‬ձͷϓϨθϯςʔγϣϯ͕࿥ը͞Ε, ωοτϫʔΫʹ഑৴͞ΕΔ͜ͱ͕੝ΜʹߦΘΕ͍ͯΔ. ͜ͷΑ͏ͳ഑৴ʹ͓͍ͯ, ձ৔ͷൃද෩‫ܠ‬Λ௚઀ࡱӨͨ͠΋ͷΛ഑৴͢Δ৔߹, ಈըͷϏοτϨʔτʹΑͬͯ͸εϥΠυ‫ͼٴ‬ϙΠϯςΟϯάͷ
໌ྎੑ͕ࣦΘΕͯ͠·͏. ·ͨ, ࿩ऀͷίϯϐϡʔλग़ྗͷεϥΠυͱ࿩ऀͷө૾Λ૊Έ߹Θͤͨ΋ͷΛ഑৴͢Δͱ͍͏ख๏΋͋Δ͕, ϙΠϯςΟϯάσ
όΠε͕഑৴্Ͱ͸൓ө͞Εͣ, ࿩ऀ͕‫Ͳࡏݱ‬ͷ৔ॴΛࢦ͍ͯ͠Δ͔͕෼͔Βͳ͍ͱ͍͏໰୊͕͋Δ.
͜ͷ໰୊ʹର͠, զʑ͸࿩ऀͷγϧΤοτΛεϥΠ
υͷഎ‫ͯ͠ͱܠ‬දࣔ͠࿩ऀࣗ਎͕ϙΠϯςΟϯάσ
όΠεͱͳΓൃද͕Ͱ͖ΔγεςϜͷ։ൃΛߦͬͨ

ਤ 1. ࿩ऀγϧΤοτΛഎ‫ͨ͠ͱܠ‬εϥΠυදࣔͱಈ࡞
ʹΑΔελϯϓͷ഑ஔ[3].
ຊߘͰ͸ҎલͷγεςϜʹ͚͍ܽͯͨදࣔλΠϛϯάͱΠϯύΫτʹॏ఺Λஔ͖, ϓϨθϯςʔγϣϯʹ͓͚Δ෼͔Γ΍͢͞Λ໨తͱͨ͠εϥΠυҐஔϚʔΩϯάͷ࣮૷ͱͦͷධՁʹ͍ͭͯड़΂Δ.

2γεςϜͷ֓ཁ

ຊγεςϜ͸࿩ऀө૾ΛγϧΤοτʹՃ޻͠εϥΠυʹॏͶͯදࣔ͢Δ͜ͱʹΑΓ, εϥΠυΛओ໾ͱͭͭ͠࿩ऀͷଘࡏ‫ͱײ‬ಈ࡞Λิॿͱͯ͠఻͑Δͱ͍͏΋ͷͰ͋Δ. ࿩ऀ͕εϥΠυ্ͷͲͷ෦෼Λઆ໌͍ͯ͠Δ͔Λ໌֬ʹ͢ΔͨΊʹ, ηϯα͔Βͷ‫ڑ‬཭Ԡͯ͡γϧΤοτͷҰ෦෼ͷ৭෇͚΋ߦ͍ͬͯΔ.
·ͨ, ηϯαʹ޲͔ͬͯखΛԡ͠ग़͢͜ͱʹΑͬͯ,ͦͷ෦෼ʹԁ‫ܗ‬ͷελϯϓΠϝʔδͷઃஔ͕ՄೳͰ͋Δ (ਤ 1). ͜Ε͸Ұఆ࣌ؒεϥΠυͷҰ෦ʹ஫໨∗

Copyright is held by the author(s).
Wakamatsu Sho and Umemura Kyoji, ๛‫ٕڮ‬ज़Պֶେֶ ৘ใɾ஌ೳ޻ֶ‫ܥ‬, Miwa Taeko, ๛‫ڮ‬૑଄େֶ ‫ֶࡁܦ‬෦‫ܦ‬ӦֶՊ, Okabe Masayuki, ๛‫ٕڮ‬ज़Պֶେֶ ৘ใϝσΟΞ‫ج‬൘ηϯλʔ- 123 -

3εϥΠυҐஔϚʔΩϯάεϥΠυ࡞੒࣌ʹ͋Β͔͡ΊελϯϓදࣔϙΠϯτΛઃఆ͓͖ͯ͠, ͦͷ෦෼ʹ࿩ऀͷγϧΤοτ͕৮ΕΔ͜ͱʹΑΓελϯϓΠϝʔδ͕දࣔ͞ΕΔ (ਤ
2). Ξχϝʔγϣϯ‫ػ‬ೳͱಉ༷ʹεϥΠυʹ૊ΈࠐΉͱ͍͏લ४උ͕ඞཁͰ͋Δ͕, ൃද࣌ʹ࿩ऀͷࢦఆՕॴʹਖ਼֬ʹελϯϓΛ഑ஔ͢Δ͜ͱ͕ग़དྷΔ.
ηϯαʹ޲͔ͬͯϓογϡಈ࡞͢Δ͜ͱʹΑΓελ
ϯϓΛઃஔ͢Δಈ࡞ϚʔΩϯάʹൺ΂, ελϯϓදࣔϙΠϯτΛத৺ʹਖ਼֬ʹελϯϓΛ഑ஔͰ͖, ͔ͭಈ࡞ϚʔΩϯάʹ͓͚Δελϯϓઃஔϛε͕ͳ͘ͳΔͨΊ, ೚ҙͷλΠϛϯάͰ࣮֬ʹ஫໨ՕॴΛࣔ͢͜ͱ͕Ͱ͖Δ. ελϯϓදࣔϙΠϯτ͸Ұ౓഑ஔͨ͠ελϯϓ͕͍ͭ·Ͱ΋࢒͍ͬͯΔͱεϥΠυࣗମͷ๦͛ͱͳΔͨΊ, ελϯϓ͸ঃʑʹಁ໌ʹͳ͍͖ͬͯ࠷ऴతʹ͸ը໘্͔Βফ͑Δͱ͍ͬͨ‫ڍ‬ಈΛߦ͏. ·ͨ, ௨ৗͷΞχϝʔγϣϯʹΑΔίϯςϯ
πͷಈ࡞͸ܾ·ͬͨॱংͰ͔͠ߦΘΕͳ͍͕, ࿩ऀͷΠϯλϥΫγϣϯʹΑΓίϯςϯπ͕഑ஔ͞ΕΔ
ͨΊ, ঢ়‫ʹگ‬Αͬͯมߋ͕ՄೳͰ͋Δ.

WISS 2013ஔϚʔΧͷ΄͏͕఻ΘΓ΍͍݁͢Ռͱͳͬͨ. ͜Ε͸, ࿩ऀγϧΤοτΛ༻͍ΔຊγεςϜͰ͸, γϧΤοτʹΑΔΠϯύΫτ͕ॆ෼͋ΔͨΊ, ஫໨Օॴʹ࣮֬ʹϚʔΩϯάΛߦ͏͜ͱ͕Ͱ͖ΔεϥΠυҐஔϚʔΩϯάͷ΄͏͕༗ޮͰ͋Δͱߟ͑ΒΕΔ.
ද 1. ֤ϚʔΩϯά‫ػ‬ೳͷධՁ݁Ռ (ඃ‫ऀݧ‬: 38 ਓ)఻ΘΓ΍͍͢ ఻ΘΓʹ͍͘p஋A ͱൺ΂ͯ C ͸
31
7
5.808 ʷ 10e-5
B ͱൺ΂ͯ C ͸
25
13
0.03647
A:࿩ऀͷγϧΤοτ + Ұ෦෼ͷ৭෇͚ (ϚʔΧͳ͠)
B:࿩ऀͷγϧΤοτ + Ұ෦෼ͷ৭෇͚ + ࿩ऀಈ࡞ϚʔΧC:࿩ऀͷγϧΤοτ + Ұ෦෼ͷ৭෇͚ + εϥΠυҐஔϚʔΧ

ਤ 2. εϥΠυҐஔʹΑΔελϯϓͷ഑ஔ

4

ධՁ

5

࣮૷ͨ͠εϥΠυҐஔελϯϓ‫ػ‬ೳ͕ຊγεςϜʹରͯ͠༗ޮͰ͋Δ͔ͷධՁ࣮‫ݧ‬Λߦͬͨ.
࣮‫ݧ‬ख๏͸, ࿩ऀ͕ఏҊγεςϜΛ༻͍ͯௌऺʹϓϨθϯςʔγϣϯΛߦ͍, ͦΕͧΕͷ‫ػ‬ೳΛ on/off
ͯ͠, ͕ࠩ͋Δ͔ΛධՁ༻ࢴʹ‫ه‬ೖͯ͠΋Β͏ͱ͍͏‫͋Ͱࣜܗ‬Δ. ࣮‫ݧ‬͸, ࿩ऀ͕લํʹཱͪௌऺʹ޲͚ͯઆ໌͢Δͱ͍͏ҰൠతͳϓϨθϯςʔγϣϯͷ‫ࣜܗ‬Λऔͬͨ. ࿩ऀ͸͋Δఔ౓γεςϜʹೃΕ͍ͯΔ΋ͷͰ͋Γ, εϥΠυ಺༰͸ௌऀʹͱͬͯ஌͕ࣝ
͋Δ෼໺Ͱ, εϥΠυ͸จࣈΛத৺ͱͨ͠γϯϓϧͳߏ੒ͷ΋ͷ, ·ͨԼ‫ه‬ͷ৚݅͝ͱʹ‫ڞ‬௨ͷ࿩୊Ͱ͸͋Δ͕಺༰͸ҟͳ͍ͬͯΔ, ϓϨθϯςʔγϣϯ࣌ؒ͸৚݅ຖʹ 10 ෼ఔ౓Ͱ͋Δ, ͱ͍͏৚݅ͷ΋ͱ࣮‫ݧ‬Λߦͬͨ.
ϓϨθϯํ๏͸ҎԼͷ 3 ύλʔϯͰ͋Δ.

ຊ‫ͱڀݚ‬ಉ༷ʹ, ࡞‫ͱۭؒۀ‬ਓ෺ը૾ͷ༥߹ΛߦͬͨγεςϜͱͯ͠͸ ClearBoard[1] ͕͋Δ. ຊγεςϜͰ͸, ‫ڠ‬ಉ࡞‫Ͱۀ‬͸ͳ͘ϓϨθϯςʔγϣϯͷ໰୊ઃఆͳͷͰ, ࿩ऀը૾ͷ৘ใΛγϧΤοτʹॖୀ͢Δઃ‫Ͱܭ‬γεςϜΛ࡞ͬͨ. ͜ͷͨΊ, ૬खͷࢹઢ, ද৘ͷΑ͏ͳਓ͕‫͍ͯ͑ݟ‬Δ͜ͱʹΑΔ఻ୡੑΛ‫ ͔ͨ͠׆‬ClearBoard ͱ͸໰୊ઃఆ͕ҟͳΔ. ຊγεςϜ͸࿩ऀͷಈ࡞͕εΫϦʔϯʹ౤Ө͞ΕΔͨΊ, ௌߨऀͷࢹઢͷҠಈͷྔ͕গͳ͘ͳΔ. ͜Ε͸,εΫϦʔϯͷલͰϓϨθϯςʔγϣϯΛߦ͏͜ͱΛࢧԉ͢ΔγεςϜͰ͋Δ MAEDE[2] ͱಉ༷ͳޮՌ
͕ಘΒΕΔ͜ͱ͕‫ظ‬଴Ͱ͖Δ. ຊ‫Ͱڀݚ‬͸, ࿩ऀ͕௚઀ࣔ͢͜ͱ͕Ͱ͖ͳ͍Α͏ͳେ‫ܕ‬ͷεΫϦʔϯͷར༻Λߟྀ͍ͯ͠ΔͨΊ, ͦͷ఺ͰҟͳΔ.

• A:εϥΠυ + ࿩ऀͷγϧΤοτ + Ұ෦෼ͷ

6

৭෇͚

·ͱΊ

ຊ‫Ͱڀݚ‬͸, ωοτϫʔΫ഑৴Ͱͷར༻Λ૝ఆͨ͠࿩ऀͷө૾ΛγϧΤοτʹม‫ͯ͠׵‬εϥΠυͷഎ‫ͯ͠ͱܠ‬දࣔ͢ΔϓϨθϯςʔγϣϯπʔϧʹ͓͍ͯ, γϧΤοτ͕৮ΕΔ͜ͱʹΑΓεϥΠυͷ஫໨ՕॴΛϚʔΩϯά͢Δํ๏Λࣔͨ͠. ·ͨ, ධՁ࣮‫ʹݧ‬ΑΓϚʔΧΛ༻͍ͨํ͕༗ޮͰ͋Γ, ຊγεςϜʹରͯ͠ͷ࣮૷͕ଥ౰Ͱ͋Δ͜ͱ͕෼͔ͬͨ.

• B:εϥΠυ + ࿩ऀͷγϧΤοτ + Ұ෦෼ͷ৭෇͚ + ࿩ऀಈ࡞ϚʔΧ• C:εϥΠυ + ࿩ऀͷγϧΤοτ + Ұ෦෼ͷ৭෇͚ + εϥΠυҐஔϚʔΧҎ্ͷ৚݅Λඃ‫ʹऀݧ‬ରͯ͠ C, B, A, C(࠶౓) ͱ͍͏ॱ൪ͰϓϨθϯΛߦ͍, B ͷऴΘΓ, A ͷऴΘΓ, C ͷऴΘΓ (࠶౓) ʹ௚ͪʹ఻ΘΓ΍͍͢৚݅͸ͲͪΒ͔ͱ͍͏ઃ໰ʹର͠, ͲͪΒ͕఻ΘΓ΍͍͔͢Λճ౴ͯ͠΋Βͬͨ. ݁Ռͷ෼ੳʹ͸ยଆ‫ݕ‬ఆͷූ߸‫ݕ‬ఆΛ࢖༻͢Δ.
4.1

ؔ࿈‫ڀݚ‬

ࢀߟจ‫ݙ‬[1] খྛູ, ੴҪ༟, ClearBoard-2 ʹ͓͚Δ‫ڠ‬ಉ࡞‫ۭۀ‬ؒͱձ࿩ۭؒͷγʔϜϨεͳ༥߹, ৘ใॲཧֶձ
৘ใॲཧֶձ‫ڀݚ‬ใࠂ, 1993, pp.43-50.

݁Ռͱߟ࡯[2] લా੖‫ݾ‬, ࠇᖒ༞໵, ‫ݪ܀‬Ұ‫و‬, ‫ٶ‬Լ๕໌, MAEDE:εΫϦʔϯલͰͷϓϨθϯςʔγϣϯελΠϧ,೔ຊιϑτ΢ΣΞՊֶձ‫ڀݚ‬ձ WISS2011, 2011,
pp.164-166.

ධՁ݁ՌΛද 1 ʹࣔ͢. ද 1 ΑΓϚʔΧͳ͠ͷ৔߹ʹൺ΂, εϥΠυҐஔϚʔΧ͕ՃΘͬͨ΋ͷͷํ͕఻ΘΓ΍͢͞ʹ͓͍ͯ౷‫ܭ‬తʹ༗ҙͰ͋Δ͜ͱ͕
෼͔ͬͨ. ·ͨ, εϥΠυ࡞੒࣌ʹϚʔΧͷग़‫ݱ‬ϙΠϯτΛઃஔ͓ͯ͘͠εϥΠυҐஔϚʔΧͱ, ࿩ऀͷϓογϡಈ࡞ʹΑΓελϯϓΛ഑ஔ͢Δ͜ͱ͕ग़དྷΔ࿩ऀಈ࡞ϚʔΧͷൺֱʹ͓͍ͯ΋ εϥΠυҐ[3] एদᠳ, കଜ‫࢘ګ‬, ࡾྠଟ‫ࢠܙ‬, Ԭ෦ਖ਼޾, ࿩ऀಈ࡞ʹΑΔ࣮֬ͳϙΠϯςΟϯάͷͰ͖ΔϓϨθϯ
ςʔγϣϯγεςϜ, ৘ใॲཧֶձ ΠϯλϥΫγϣ
ϯ 2013, 2013, pp.750-755.

- 124 -WISS2013「へやくる！」だらだらと賃貸物件情報をみることについて
大坪 五郎∗
概要. 従来の情報検索インタフェースは，「ユーザは詳細な条件を入力しそれに対する正確な回答を期待する」という前提に基づくものが多かった．しかしながら，日常的に行う検索においてはユーザがそもそも何を入力すれば良いのかのイメージを持っていない場合も多い．不動産情報の検索はそのような性質を持っているという想定の元，まずユーザに情報を提示し，そこから気が向くままに条件を加え，変更，削除してもらうことを目的とした iPad アプリ「へやくる！」を開発した．既存の不動産情報検索アプリと比較し，一つの条件を設定するのに必要な手順が劇的に削減されており，ユーザは不動産情報について学びつつ様々な探索を試みることができる．

はじめに

1

従来の情報検索インタフェースは，ある程度自分が何を探そうとしているかユーザが把握していることを前提とし，設定された詳細な条件に対して正確な結果を返すことを目標としたものが多かった．しかしながら，問題領域によってはユーザが自分が何を探そうとしているか明確に自覚しているとは限らない．筆者が開発した Gards[3] では「毎日のお昼に何を食べるか選択する」という極めて曖昧な問題意識の元では，とにかくユーザに情報を提示し，その後のフィードバックを受け付け，それに対した情報を素早く提示することでユーザが当初想定もしていなかった「回答」に辿り着けることを示した．筆者が現在勤務している企業は HOME’S[1] という不動産情報検索サイトを運営している．自分が住む場
所の選択というのは極めて重要な判断であるが，一生のうちに何度も行うものではなく普段は関心も薄い．その結果としてユーザは「自分が住みたいのはどのような物件か」「どのような物件に住めるのか」「そもそも条件として何が設定できるのか」といった問題に対して明確なイメージを持たずに検索を行
うこともあると考えられる．そのため Gards と共通するコンセプトに基づく検索インタフェースを提供することも有効ではないか，という仮説の元 iPad
アプリ「へやくる！」を開発した．

「へやくる！」について

2
2.1

コンセプト

前記の考察に基づくと，目指すべきユーザインタ
ラクションの特性が明らかになる．すなわちユーザ
はどのような物件情報がそもそも存在しているのか，あるいはどのような検索条件が設定可能であり，それが何を意味するのかについて十分な知識を持って∗

Copyright is held by the author(s).
（株）ネクスト- 125 -

いないと想定する．このような場合には情報検索イ
ンタフェースはモードレス [4] なインタラクション
で操作できることが必要であると考えた．すなわちユーザが自分の意思を反映させようとした際に，一連の手続きを強いる-すなわち特定の「モード」に入らせる-のではなく，興味，気分が赴くまま自由に最短手順での条件変更を可能とし，かつその結果をすぐに返す．これによりユーザは条件を設定すること
が，どのような意味を持つのか学びつつ物件情報を探索することができると考えられる．
このような特性を考慮し設計した「へやくる！」の画面イメージを図 1 に示す．このアプリでは，起動した瞬間から基本的に画面右側に物件情報が表示され続ける．ユーザはそれに対して，左側に並んでいるアイコンをドラッグ・アンド・ドロップすることで条件設定/解除を自由に行うことができる．多くの検索条件は最長２タップで設定，変更することが可能であり，変更後は即座に結果が変更される．
ユーザが興味をもった物件がでてきた場合には，その上をタップすることで詳細情報を閲覧することが
できる．

2.2

実装

「へやくる！」は iPad 上のアプリケーションとして実装されている．検索条件を指定した際のソー
トアルゴリズムは，HOME’S サイトと異なる独自の物を用いているため，サーバー側に専用モジュー
ルを追加している．

2.3

評価「へやくる！」は商用サービスとしてリリースするため，ユーザビリティテストを行い要改善点を洗い出しその結果を仕様に反映させた．また目標とした「モードレスさ」について，他社製不動産情報検索用 iPad アプリとの比較を行った．その結果，他社
製 iPad アプリでは一つの条件項目を設定，もしくWISS 2013

図 1. へやくる！の画面は変更するのに要する操作数は平均 4.3 であるのに対し，「へやくる！」では平均 1.7 であることが確認できた．このようにユーザが自分の意図を検索結果に反映させるために必要な操作数が少ないので，それだけユーザは思いつきを簡単に検索結果に反映させることができる．またインタフェースデザインには，開発とほぼ同時期に発表された iOS7 の新しいデザ
インコンセプトを反映している．アプリの主役はあくまでも物件情報（コンテンツ）であり，それ以外の不要な要素は極力排除し，画面デザインの面からも物件情報とユーザ間の距離を縮める事を狙っている．そうしたデザイン方針を徹底した結果，iOS7 全体のデザイン思想と合致した簡素で美しい画面デザインが実現できた．

3

関連研究

検索結果に対して，ユーザが能動的に自分の意図を反映させていく，という点では山本，中村らのRerank-By-Example[2] がある．一度でユーザが意
図する検索結果を得ることを期待せず，積極的にその意思を反映させることで望む結果にたどり着くことを目指している点が「へやくる！」と共通する．

4

まとめと今後の予定「へやくる！」は現状細かい条件設定が必須となっている不動産情報検索に「モードレスさ」を持込み，ユーザがより気ままに閲覧できることを可能とした試みである．

- 126 -

今後実際に使用されたログデータを蓄積し，我々の狙いがどの程度成功を収めたか．また今後どのような方向に進むべきかについて検討する予定である．

参考文献[1] HOME’S. http://www.homes.co.jp.
[2] 山 本 岳 洋 ，中 村 聡 史 ，田 中 克 己: Rerank-ByExample：編集操作の意図伝播によるウェブ検索結
果のリランキング情報処理学会論文誌（トランザクション）データベース, Vol.49, No.SIG7 (TOD37),
pp.16-28, 2008 年 3 月.
[3] 大坪五郎: Gards - 変化し続ける興味に対応する情報推 薦, WISS2005 論文集, pp.31-36, 2005.
[4] ソ シ オ メ ディア:「 モ ー ド レ ス 」
https://www.sociomedia.co.jp/326.

WISS2013ϙʔλϒϧϏδϡΞϧϓϨΠϦετ GRAPE ͷओ‫؍‬ධՁ‫ ాڕ‬஌ඒҏ౻ ‫و‬೭∗֓ཁ. ‫ݸ‬ਓ͕࣋ͪาָ͘‫਺ۂ‬͸๲େʹͳΓɼԻָίϨΫγϣϯͷ಺༰Λཧղ͢Δ͜ͱ͸ࠔ೉ʹͳͬͨɽ·ͨɼଟ͘ͷਓ͸Իָؑ৆ͷࡍɼ࣍ʹฉ͘‫ۂ‬Λ 1 ‫ͭͣۂ‬ஞҰબ୒͢ΔΑΓ΋ɼϓϨΠϦετ΍ΞϧόϜͱ͍ͬͨԻָͷ·ͱ·ΓΛબ୒͢Δ͜ͱ͕ଟ͍ͱߟ͑Δɽͦ͜ͰஶऀΒ͸ɼ‫ݸ‬ਓͷԻָؑ৆ͷૢ࡞Λࢧԉ͢ΔͨΊʹɼ๲େʹͳͬͨԻָίϨΫγϣϯΛϓϨΠϦετ୯ҐͰՄࢹԽ͢Δ GRAPE ΛఏҊ͍ͯ͠ΔɽGRAPEͰ͸ϓϨΠϦετΛߏ੒͢Δ֤‫ʹۂ‬ରͯ͠ɼಛ௃ྔʹ΋ͱ͍ͮͯ৭ΛׂΓ౰ͯɼಛ௃ྔͷྨࣅ౓ʹ‫͍ͮج‬ͯҐஔΛܾఆ͢Δ͜ͱʹΑΓɼϓϨΠϦετͷ಺༁Λάϥσʔγϣϯը૾Ͱද‫͢ݱ‬Δɽ͜ͷը૾‫܈‬Λจࣈ৘ใͷ୅ΘΓʹදࣔ͢ΔΠϯλϑΣʔεΛ౥ࡌͨ͠ԻָϓϨΠϠʔΛɼPC ্ͱ Android ԻָϓϨΠϠʔ্Ͱ࣮૷ͨ͠ɽຊใࠂͰ͸ɼ͍͔ͭ͘ͷϓϨΠϦετΛ༻͍ͯϢʔβςετΛ࣮ࢪͨ݁͠ՌΛࣔ͢ɽ

1

͸͡Ίʹ

Իָͷ಺༰Λ೺Ѳ͢Δʹ͸ɼ࣮ࡍʹฉ͘ඞཁ͕͋
ΔͨΊɼ಺༰೺Ѳʹ͸͕͔͔࣌ؒΔɽ๲େ͔ͭ࣌ؒ
తϝσΟΞͰ͋ΔԻָͷ಺༰Λ୹࣌ؒͰ௚‫ײ‬తʹ೺Ѳ͢ΔҰखஈͱͯ͠ɼը૾Ͱશମ૾Λද‫͢ݱ‬ΔՄࢹ
Խ͕༗༻Ͱ͋Δͱߟ͑Δɽ·ͨ༧උௐ͔ࠪΒɼԻָؑ৆Ͱ͸ָ‫ۂ‬Λ 1 ‫ʹͱ͝ۂ‬ஞҰબ‫͢ۂ‬Δํ๏ΑΓ΋ɼϓϨΠϦετ΍ΞϧόϜ౳ͷԻָͷ·ͱ·ΓΛબ୒͢Δํ๏ͷ΄͏͕Ұൠతͩͱߟ͑Δɽ͔͠͠‫ط‬ଘͷԻָՄࢹԽख๏͸Վख΍δϟϯϧʹ஫໨ͨ͠΋ͷ͕ଟ͘ɼΞϧόϜ΍ϓϨΠϦετʹண໨ͨ͠‫ڀݚ‬͸গͳ͍ɽಛʹϓϨΠϦετʹؔͯ͠͸ 2009 ೥࣌఺Ͱ0 ݅ͱࢦఠ͞Εͨ [1]ɽͦ͜ͰஶऀΒ͸ʮ1 ը૾Ͱ 1 ϓϨΠϦετʯΛද͢ϓϨΠϦετ୯ҐͷԻָͷՄࢹԽɼGRAPE (GRadation Arranged Playlist Environment) ΛఏҊ͍ͯ͠Δɽ‫ࡏݱ‬ͷԻָϓϨΠϠʔͰ͸ҰൠతʹɼϓϨΠϦετ͸ͦͷ໊લͷΈͰදࣔ͞ΕΔ΋ͷͰ͋Γɼͦͷ໊લΛ஌Βͳ͍৔߹ʹ͸ϓϨΠϦετͷશମ૾͸΋ͱΑΓɼϓϨΠϦετ಺ͷ‫ݸ‬ʑͷָ‫ۂ‬ͷҹ৅Λਪ࡯͢Δ͜ͱ͸೉͍͠ɽͦΕʹରͯ͠ GRAPE ͸ɼ৭ͷ͍ͭͨਖ਼ํ‫ܗ‬ͷλΠϧΛฒ΂ͯϓϨΠϦετΛ
ද‫͢ݱ‬Δ͜ͱͰɼϓϨΠϦετશମΛ௨ͯ͠ͲΜͳҹ৅Λ༗͢Δ͔ͱ͍͏શମ૾ͱɼ‫ݸ‬ʑͷ‫ۂ‬ͷҹ৅ͱɼ྆ํΛಉ࣌ʹද‫͢ݱ‬ΔɽຊใࠂͰ͸ɼGRAPE ʹؔ͢Δओ‫؍‬ධՁ݁ՌΛࣔ͢ɽ

2

GRAPE
GRAPE Ͱ͸ɼҎԼͷॲཧʹΑͬͯੜ੒͞ΕΔάϥσʔγϣϯը૾ʹΑΓɼϓϨΠϦετΛද‫͢ݱ‬Δɽ
·ָ֤ͣ‫ۂ‬ͷಛ௃ྔΛࢉग़͢Δɽଓ͍ͯநग़ͨ͠ಛ
∗Copyright is held by the author(s).
Tomomi Uota and Takayuki Itoh ͓஡ͷਫঁࢠେֶେֶӃ ਓؒจԽ૑੒Պֶ‫ڀݚ‬Պ ཧֶઐ߈,- 127 -

௃ྔ͔ΒɼϓϨΠϦετΛߏ੒͢Δָ֤‫ۂ‬ͷҐஔΛܾఆ͢Δɽಛ௃ྔ͕ྨࣅ͢Δָ‫ۂ‬Λۙ͘ʹ഑ஔ͢Δ
͜ͱͰɼϓϨΠϦετશମͷҹ৅Λࢹೝ͠΍͘͢͢Δɽ͞Βʹநग़ͨ͠ಛ௃ྔ͔Βɼָ֤‫ۂ‬ͷ৭Λܾఆ͢Δɽ͜ͷ֤৭ͰॴఆͷҐஔΛృΓͭͿ͢͜ͱͰɼ
ϓϨΠϦετͷՄࢹԽ݁ՌͱͳΔάϥσʔγϣϯը૾͕ੜ੒͞ΕΔɽ͜ͷը૾ΛϢʔβΠϯλϑΣʔε্ʹ౥ࡌ͢Δ͜ͱͰɼϙʔλϒϧϏδϡΞϧϓϨΠ
Ϧετͱͯ͠‫ػ‬ೳ͢Δɽॲཧͷৄࡉʹ͍ͭͯ͸ [2]Λࢀর͞Ε͍ͨɽՄࢹԽදࣔྫΛਤ 1 ʹࣔ͢ɽਤ 1. ՄࢹԽදࣔྫ (ࠨ)PC (ӈ)Android ΞϓϦέʔγϣϯ3

Ϣʔβςετ
ඃ‫ʹऀݧ‬ՄࢹԽ݁Ռը૾Λ‫ͯ͠࡯؍‬΋Β͍ɼҎԼ

2 ͭͷϢʔβςετΛ࣮ࢪͨ͠ɽ
!
Q1ɿ‫ط‬ଘͷָ‫܈ۂ‬ද‫ํݱ‬๏ͱͷൺֱ"ϓϨΠϦετ 1ɼ2ɼ3ɼ4 ʹରͯ͠ɼ(A)GRAPEʹΑΔը૾ɼ(B) δϟϯϧΞΠίϯɼ(C)CD δϟέοτΛਤ 2(ࠨ) ͷΑ͏ʹ༻ҙͨ͠ɽͦΕͧΕͷϓϨΠϦετʹରͯ͠ɼϓϨΠϦετͷத਎΍ϓϨΠϦετͷશମ૾͕ 1 ൪༧૝Ͱ͖બ‫ۂ‬ͷࢀߟʹͰ͖ͦ͏ͳ΋ͷ͸ͲΕ͔ɽʢճ౴਺ 138ʣ#$WISS 2013݁ՌΛਤ 2(ӈ) ʹࣔ͢ɽϓϨΠϦετ 1ɼ2ɼ3ɼ4ʹ͸ࢢൢ͞Ε͍ͯΔָ‫ۂ‬Λ࢖༻͍ͯ͠ΔͨΊɼϢʔβʹΑͬͯ͸ CD δϟέοτ͕‫ط‬஌Ͱ͋Γɼָ‫͕ۂ‬༧૝Ͱ͖ΔՄೳੑ͕͋ͬͨɽϓϨΠϦετ 3ɼ4 ʹ͍ͭͯ͸ (A) ΛબΜͩਓ͕ 1 ൪ଟ͍݁ՌͱͳͬͨɽϓϨΠϦετ 1ɼ2 ʹ͍ͭͯ͸ (A) ΛબΜͩਓ͸ (B)(C)ΑΓ͸গͳ͍ͱ͸͍͑໿ 4 ෼ͷ 1 ʹୡ͓ͯ͠ΓɼΑͬͯ (B)(C) ΑΓ΋ (A) Λࢧ࣋͢Δਓ͸Ұఆ਺͍Δͱ
ߟ͑ΒΕΔɽซͤͯઃ͚ͨίϝϯτཝʹ͸Լ‫د͕ه‬ͤΒΕͨɽൈਮͯ͠Լ‫঺ʹه‬հ͢Δɽ• ָ‫ۂ‬৭ΛϢʔβ͕ਖ਼֬ʹಡΈऔΕΔͷ͔ɼσϞ౳Ͱָ‫ۂ‬Λฉ͍ͯΈͳ͍ͱ GRAPE ͷ༗༻ੑ͕Θ͔Βͳ͍ (ྨࣅ 6 ݅)
• ΞϧόϜ୯ҐͰָ͔͠‫ۂ‬Λฉ͔ͳ͍ͨΊɼCDδϟέοτͰे෼ (5 ݅)• ಺༰͕Θ͔Βͳָ͍‫܈ۂ‬͸ͳ͍ͨΊɼ༗༻ੑΛ‫( ͍ͳ͡ײ‬4 ݅)• ਓͱָ‫܈ۂ‬Λ‫ڞ‬༗͢Δࡍʹ༗༻ͱ‫͡ײ‬Δ (3 ݅)• ௌ͖͍ͨ‫۩͕ۂ‬ମతʹ͖·͍ͬͯͳ͍ࡍɼCDδϟέοτͷΑ͏ͳ۩ମతͳ΋ͷΑΓɼGRAPEͷը૾ͷํ͕༗༻ͩͱ‫͡ײ‬Δ (3 ݅)࢖༻ͨ͠ 9 ͭͷϓϨΠϦετ͸ RWC ‫༻ڀݚ‬Իָσʔλϕʔε [3] ͷָ‫ۂ‬Λར༻ͯ͠࡞੒ͨ͠΋ͷͰ
͋Δɽ͍ͣΕͷඃ‫ऀݧ‬΋͜ͷԻָσʔλϕʔεͷऩ࿥‫ۂ‬Λௌ͍ͨ͜ͱ͕ͳ͘ɼGRAPE ͷՄࢹԽը૾͔
ΒಘΒΕΔ৘ใ͚ͩͰϓϨΠϦετΛબ୒ͨ͠ͱ‫ݴ‬
͑Δɽද 1 ʹ·ͱΊͨճ౴݁Ռ͔ΒɼશͯͷϢʔβʹ͓͍ͯɼϥϯμϜબग़͞ΕͨϓϨΠϦετΑΓɼGRAPE Λར༻ͯ͠બ୒ͨ͠ϓϨΠϦετͷධՁͷํ͕ߴ͔ͬͨɽ͜ΕʹΑΓɼGRAPE ͕ఏࣔ͢Δը
૾͸ϓϨΠϦετબ୒ʹ༗ӹͳ৘ใΛఏ‫͍ͯ͠ڙ‬Δ
͜ͱ͕֬ೝͰ͖ͨɽ
ද 1. Q2 ͷ݁Ռʢ‫ر‬๬ʹԊͬͨબ୒͕Ͱ͖ͨ 4 ˱Ͱ͖ͳ͔ͬͨ 1ʣඃϓϨΠϦετͷબ୒ํ๏
‫ݧ‬
GRAPE
ϥϯμϜબग़
ऀ PlaylistNo. ධՁ PlaylistNo. ධՁ

1
2
3
4
5
6
7
8
9

Ҏ্ͷίϝϯτ͔Βɼର৅Ϣʔβ΍࢖༻৔໘Λઃ໰தʹ໌֬ʹઃఆ͠ɼָ͔ͭ‫ۂ‬ΛࢼௌͰ͖Δ‫Ͱڥ؀‬࠶ௐࠪΛ͍ͨ͠ͱߟ͑Δɽ

4

7
2
5
7
6
5
2
7
2

4
3
3
2
4
3
4
4
3

8
5
8
1
7
1
9
3
6

2
2
2
1
3
2
3
2
2

·ͱΊͱࠓ‫ޙ‬ͷ՝୊ຊใࠂͰ͸ɼஶऀΒ͕‫ʹط‬ఏҊ͍ͯ͠ΔϙʔλϒϧϏδϡΞϧϓϨΠϦετ GRAPE ͷओ‫؍‬ධՁ݁ՌΛࣔͨ͠ɽϢʔβςετ͔Βɼ‫ط‬ଘͷָ‫܈ۂ‬ද‫ݱ‬ํ๏ʹର͢Δ͋Δఔ౓ͷ༗༻ੑͱɼະ஌ͷϓϨΠϦ
ετ‫܈‬બ୒࣌ͷ༗༻ੑʹ͍ͭͯٞ࿦ͨ͠ɽ
ࠓ‫ޙ‬ͷ՝୊ͱͯ͠ɼָ֤‫ۂ‬ͷ৭΍Ґஔ͕ɼਓ͕ؒ
௚‫ײ‬తʹ‫͡ײ‬Δ৭ɼͦΕʹ൐ͬͨ഑ஔʹۙͮ͘Α͏
޻෉͢Δ͜ͱ͕‫͛ڍ‬ΒΕΔɽ·ͨɼGRAPE ্Ͱ؆୯ʹϓϨΠϦετΛ࡞੒ɾࢼௌɾ‫ڞ‬༗Ͱ͖Δ‫ػ‬ೳΛઃ͚ɼGRAPE ͷޮՌ͕࠷΋‫ظ‬଴Ͱ͖ΔϓϨΠϦε
τʹΑΔԻָؑ৆‫׆‬ಈͷ‫ൃ׆‬Խʹ‫͍͖͍ͨͯ͛ܨ‬ɽࢀߟจ‫ݙ‬

ਤ 2. (ࠨ)Q1 ʹ༻͍ͨը૾ (ӈ) ݁Ռ!
Q2ɿϓϨΠϦετબ୒ͷຬ଍౓"

ਤ 1 ʹࣔ͢ϓϨΠϦετ 9 ͭͷத͔Βɼࠓฉ͖͍ͨϓϨΠϦετΛ GRAPE Λ༻͍ͯબ୒͠
ͯ΋Β͍ɼࣗ෼ͷ‫ر‬๬ʹԊͬͨϓϨΠϦετͰ͔࣮͋ͬͨࡍʹࢼௌͯ͠ධՁɽ·ͨಉ࣌ʹϥϯμϜʹબग़ͨ͠ϓϨΠϦετʹ͍ͭͯ΋ࢼௌͯ͠ධՁɽ
ʢ4 ஈ֊ධՁɼճ౴਺ 9ʣ
#$- 128 -

[1] J. Donaldson and P. Lamere. Using visualizations for music discovery. In Tutorial at the 10th
Int. Conf. on Music Information Retrieval, 2009.
[2] ‫ాڕ‬஌ඒ, ҏ౻‫و‬೭, GRAPE: άϥσʔγϣϯը૾ʹΑΔϙʔλϒϧϏδϡΞϧϓϨΠϦετ, ՄࢹԽ৘ใγϯϙδ΢Ϝ, B215, 2013.
[3] ‫ޙ‬౻ਅ޹, ‫ޱڮ‬തथ, ੢ଜ୓Ұ, ԬོҰ. RWC ‫ڀݚ‬༻Իָσʔλϕʔε: ‫ڀݚ‬໨తͰར༻Մೳͳஶ࡞
‫ॲݖ‬ཧࡁΈָ‫ۂ‬ɾָ‫ث‬Իσʔλϕʔε. ৘ใॲཧֶ
ձ࿦จࢽ, Vol. 45, No. 3, pp. 728-738, 2004.

肌マイクロスコープを用いた肌微細構造パラメータの診断
番場 文枝

猪股 真美

伊藤 貴之

豊田 成人

大高 瞳

笹本 裕美

概要
化粧品にはその様々な質感により肌を美しく演出する効果がある．肌の印象の違いは肌表面形状に起因しており，その効果を把握するために肌の微細構造と質感印象評価の関係を調べる必要がある．本報告
では，肌マイクロスコープという専用カメラで撮影した肌の実写画像から肌微細構造パラメータを診断する一手法を示す．本手法では実写画像に対し二値化処理を適用し，続いてテンプレートマッチングに類似した手法で黒領域を探索することで，毛穴半径・皮溝幅・皮溝角度依存性を診断する．

はじめに

肌微細構造パラメータの診断

化粧品は女性にとって不可欠な商品であり，今日では多くの商品が販売されている．肌の質感印象と肌の表面形状の関係性を調べることはメーキャップ
化粧品の効果を知る上でとても重要とされている．
しかし，現在の印象評価では実際のモデルに化粧品を塗布して撮影した写真を使った伝達方法が主である．この方法では多くのバリエーションを再現するのはコストがかかるとともに，工学的な変化に大きな影響がある肌微細形状の要因は考慮されにくい．
）
そこで我々は，コンピュータグラフィクス（を用いて微細形状を考慮した肌を生成し，肌の微細構造の違いによる肌質感変化のシミュレーションシの開発に取り組んでいる．
画像の採
ステム
用によって，従来よりも多彩な肌の印象評価が可能になると考えられる．本報告では上述の我々の研究のうち，肌撮影専用カメラの一種である肌マイクロスコープ（図 参照）で撮影した実写画像から，微細構造に関する数値を測定する手法を提案する．現時点での我々の実装では，まず肌の撮影画像を二値化して，続いてテンプレートマッチングに類似した手法で黒領域を検出し，これを毛穴や皮溝と判断する．以上の処理によって検出された毛穴や皮溝から，
毛穴半径・皮溝幅・皮溝角度依存性に関する測定値のヒストグラムを生成する．

本報告で提案する肌微細構造パラメータの診断手法は，実写画像を二値化した画像から円形領域を検出する，という単純な処理に基づいている．
二値化
まず入力画像に適応的二値化処理を適用する．各座標における値の総和が閾値以上の場合は黒画素に，さもなければ白画素に変換する．現時点
では我々の経験に基づいて閾値を固定しているが，将来的には判別分析などの諸手法を適用して動的に閾値を設定できるようにしたい．
毛穴検出
続いて，二値化後の白黒画像に対して円形の黒領域を検出し，これを毛穴とみなす．ここでは図 左に示すように，円形の黒領域をテンプレートとして，
テンプレートマッチングに類似した以下の手法で円形の黒領域を探索する．
円領域 直径を画像内の全ての領域に走査させて，各位置において以下を実行する．
円領域内部における黒画素数を集計する．
円内部における黒画素数が閾値以上であれば，その円を毛穴と判別し，中心座標と円直径を記録する．
毛穴と判別された円内部の黒画素を白画素に変換する．この変換は毛穴位置を除いた皮溝検出のために必要である．
直径

として

に戻る．

円の大きさがユーザ指定の最小値になるまでと を繰り返す．
図

肌マイクロスコープ．

以上により，各毛穴の中心座標，直径を記録する．
皮溝検出

お茶の水女子大学

続いて，毛穴以外の画素において細く伸びる黒領域を検出し，これを皮溝とみなす．ここでは図 右資生堂リサーチセンター- 129 -

に示すように， 方向の黒い線分のいずれかを引いた円をテンプレートとして，テンプレートマッチン
グに類似した以下の手法で細長い黒領域を探索する．
テンプレートを画像内の全ての領域に走査させて，各位置において以下を実行する．
テンプレートに引かれた黒い線分上における黒画素数を集計する．
黒画素数が閾値以下であれば，その領域
は皮溝ではないと判別し， に戻る．
さもなければ，その領域は皮溝であると判別する．テンプレートの平行移動によって皮溝の太さを推定し，テンプレートの中心座標，およびテンプレート上の線分の角度とともに記録する．
種類のテンプレート全てに

また， 枚とも毛穴の位置，毛穴の大きさ，皮溝の位置を概ね捉えられている．
続いて，検出された皮溝を角度別皮溝数で集計し，ヒストグラム化したものを図 に示す．横軸は種類の角度，縦軸はその角度における皮溝数を表している．乾燥肌では単峰性の分布，つまり特定の一方向の皮溝が極端に多いことを表しており，乾燥肌の典型的な特徴が読み取れる．健康な肌，毛穴の目
立つ肌では乾燥肌に比べ多峰性の分布を持ち，皮溝が流れていないことがわかる．
今後の課題として，実写画像から読み取れない立
体的なパラメータの推定手法の確立や，リアルタイ
実装等があげられる．
ム処理を実現するためのを適用する．

以上の処理により，各皮溝の中心座標，角度，太さを記録する．
!"#$%&$'$(')"*

!"#$

!"#$
%&##"'•!"#$%&'$%()*(+,-*%&$./,-&$•0"+1&%&'$%1+.2$*%"3%2,-(4%/)5$,6%)16)7$%&'$%&$./,-&$%-&%$-('%/"6)&)"1

図+,##"-%&$'$(')"*%&##"'

図

実写画像と検出結果． 左 健康な肌． 中 毛穴の目立つ肌． 右 乾燥肌．

図

角度別皮溝数のヒストグラム． 左 健康な肌． 中
毛穴の目立つ肌． 右 乾燥肌．

•!"#$%&'$%()*(+,-*%&$./,-&$•8"&-&$%&'$%6$9.$1&%)1%&'$%&$./,-&$•0"+1&%&'$%1+.2$*%"3%2,-(4%/)5$,6%"1%&'$%6$9.$1&%-&%$-('%/"6)&)"1

左 毛穴検出． 右 皮溝検出．

実行例
本報告では，実写画像として代表的な特徴を持つ肌の実写画像サンプル 枚を入力として実験結果を生成した結果を示す．
健康な肌 特徴として，皮溝から生成される三角形が正三角形に近い形をしており均一であることが挙げられる．
乾燥肌 皮溝が一方向へ流れるため三角形を生成できていない場合が多い．
毛穴が目立つ肌 各々の毛穴の直径が広い．
上述のサンプル画像 枚に対して毛穴と皮溝を検出した結果を図 に示す．毛穴を水色で，皮溝をピンクで色分けしてある．乾燥した肌では毛穴が少な
く皮溝も一方向に流れている様子が検出できている．

- 130 -

参考文献

WISS2013

多様性と類似性を重視したアパレル商品閲覧システム
小池 恵里子伊藤 貴之∗

概要. 現実の買い物では様々な商品を見て回る人は多く，特に女性にその傾向が強く見られる．本研究では，そのような買物に関する心理に着目し，効果的に商品を閲覧できるシステムを提案し，アパレル商品を例にした実装を示す．本手法では，キーワードの組み合わせに沿ってアイコンを生成し，対話型進化計算を用いた推薦アルゴリズムによって多様に選ばれたアイコンを表示することで様々な商品の閲覧を可能にする．一方でアイコンクリック時には画面を切り替え，アイコンに対応する類似商品を表示し比較しやすい商品提示を行う．このような，多様性と類似性に着目した商品提示を行うことで，現実のウィンドウショッピ
ングのように演出を行い，効果的な買物行動を支援する．

1

はじめに

現実の店舗では，ウィンドウショッピングという名前にある通り，買い物時に様々な商品を見て回る人は多い．特に女性にその傾向が強く見られ，原因として「要求が曖昧．
」「好きなもの以外にも注意が引かれやすい．
」「細かいデザインにこだわりたい．
」などがあげられる [1]．しかし，多くのサイトの検索シ
ステムはユーザが積極的にクエリを発する能動的検索になるため，要求が曖昧である場合には，クエリをつくる過程で精神的ストレスが生じることがある．
例えば，ユーザは「かわいいセータが欲しい」という曖昧な要求をもっていたとする．この時，ユーザ
は”セータ”というクエリをシステムに発行するが，検索結果の商品件数が多いと，ユーザは商品の件数を減らすために自分の曖昧な要求を明確化して，クエリを書き換えなければいけない．また，発したク
エリに何件の商品が検索されるか，ユーザは事前に知ることができないため，”該当する商品が無い”という最悪の状態も起こりうる．さらに，検索結果か
らその都度判断してクエリの修正を行うため，クエリ書き換え回数が過多になりやすい．その上，商品件数を絞って閲覧した後も”他の商品を見たい・気に入るデザインがなかった”というようなことから，検索は引き続き行われる．結果としてユーザ自身がかなり積極的になってクエリ修正を行わないと，様々な商品を閲覧することはできないということが起こる．これを解決するための一手段として，受動的に様々な商品を見ることができる商品閲覧システムを提案し，アパレル商品を例にした実装を示す．

2

気になる商品に近づいて詳しく見ることができる．
また，多くの店舗ではカテゴリ別（T シャツなど）
・
系統別（モード系など）というように類似した商品ごとに並べられ，近くで気になる商品を閲覧する際は，それらを細かく比較しながら自分の好みの商品を選ぶことができる．このような「遠くから見て多様な商品群を見る」と「近くから見て類似した商品を見る」という行為を繰り返すことによって「要求が曖昧でも様々なものを沢山見てみたい」という無意識な欲求を満たすことが可能である．このような現実の買物行動の観察から，以下の要件を満たすシ
ステムを提案する．
要件 1: 曖昧な要求に対しても満足できる買物ができるように，明確なクエリを必要としない．
要件 2: 様々なものに興味を引けるように，ユーザの嗜好に沿いつつも多様な商品群の提示を反復的に行う．
要件 3: 比較しやすいように商品を類似品ごとに分
類する．

3

研究概要

本研究では，開発者が用意したキーワードを各商品に付与し，そのキーワードを検索時に参照する．
また，前処理としてキーワードそれぞれにデザインを用意し，キーワードの組み合わせを列挙して合成したアイコンを生成する．図 1 は商品の種別（T シャツ），色（赤），柄（ドット）のデザイン画像の合成によってアイコン画像を生成した例である．

要件定義

現実の買物では要求が漠然としていても目線を遠くにすれば多様な種類の商品が目に入り，そこから図 1. アイコン生成の例

Copyright is held by the author(s).
∗お茶の水女子大学人文化創成科学研究科理学専攻- 131 -WISS 2013

【Step1】種アイコン集合 C を空にする．表示アイ
コン群 A を空にし，A が m 個となるように優先ア
イコン群 S から順に追加する．
【Step2】表示アイコン群 A を表示する．
【Step3】Rocchio のアルゴリズム [3] に用いられるフィードバック算出式に類似した以下の式を利用しq!i を更新する．
Di+ ：i 回目にお気に入りに入れた商品の集合
Di− ：i 回目に削除した商品の集合

本研究は商品の多様性と類似性を考慮するためにア
イコン画面と商品画面の２種類の画面にわける．図
2 にその表示例を示す． アイコン画面では Search!qi = !qi−1 +図 2. 左：アイコン画面

d!+ ∈Di+

右：商品画面

ボタンをクリックする毎に推薦アルゴリズムによって多様に選ばれたアイコンが表示することで要件１と要件２を満たす．また，アイコンのクリック操作
で商品画面に切り替わり，アイコンが示すキーワー
ド群と同じキーワードを有する商品を表示すること
で要件３を満たす．

3.1

d!+ −

!

d!− ∈Di−d!−(A)【Step4】ユーザが「お気に入り」に入れた商品の多いアイコンを，種アイコン集合 C に登録する．
【Step5】各々の種アイコン c ∈ C に対して以下の処理を実行する．

1. 種アイコン集合に属するアイコン c について，ユーザの嗜好ベクトルからルーレットを用意する．
2. ルーレットから y 番目のキーワードを選ぶ．
3. 種アイコン c にて dx = 1 であるキーワードのうち，y 番目のキーワードと排他的に出現すべき z 番目のキーワードについて dy = 0，dz = 1 としたベクトル d に対応するアイコン
を，派生アイコン集合に登録する．このとき派生アイコンは i 回までに使用したアイコンと重複が無いように選択する．
4. この派生アイコンを，優先アイコン群 S に追加する．
5. 2.〜4. を，派生アイコンの個数だけ反復する．
6. 1.〜5. を，種アイコンの個数だけ反復する．

アイコン画面の可視化

本手法では可視化手法 FRUITSNet[2] のアルゴリ
ズムをベースにして，類似したクエリをアイコン画
面上で近くに配置することにより，検索結果の全体的分布を直感的に表現する．FRUITSNet では関連性のあるアイコン間をエッジで連結したネットワー
ク構造に対して，以下の条件を満たす一覧性の高い
画面配置を実現する．
[配置条件１] 画像間の重なりの回避．
[配置条件２] 画像群の配置占領面積の低減．
[配置条件３] 関連性の高い画像群を近くに配置．

4
3.2

!

推薦アルゴリズム

本節では要件２を満たすために，以下の対話的進化計算アルゴリズムを導入している．
n: システムが用意するキーワード数
m: システムが一度に表示するアイコン数
d! = {d1 , ..., dn }: 各商品について，各キーワードの付与の有無を表すベクトル．
!q = {q1 , ..., qn }: ユーザの嗜好に関する各キーワードの重みを示すベクトル．Search ボタンを i 回押した時点での !
q の値を q!i とする．
A：現在表示されている x 個のアイコンの集合．
S ：システムが優先的に表示するアイコンの集合．
データ構造にキューを持つ．
C ：種アイコンの集合．
この処理手順のうち Step1〜Step6 は，ユーザが Search
ボタンを押すたびに実行されるものとする．
【Step0】ユーザの嗜好ベクトル q!0 と優先アイコン
集合 S を初期化する.

- 132 -

まとめと今後の課題

本報告ではウィンドウショッピングのような買物行動を考慮した検索支援システムを提案し，アパレル商品を例とした実装を示した．今後はユーザテストを行い，UI と推薦アルゴリズムの改善を行なって
いきたい．

参考文献
[1] 木田理恵，彼女があのテレビを買ったワケ―男がわからなかった 女が商品を選ぶ本当の理由 ，エク
スナレッジ，ISBN-978-4-7678-0697-6, 2008.
[2] T. Itoh, C. Muelder, K.-L. Ma, J. Sese: A Hybrid
Space-Filling and Force-Directed Layout Method
for Visualizing Multiple-Category Graphs, IEEE
Pacific Visualization Symposium(2009),121-128.
[3] G. Saltom, The SMART retrieval system - experiments in automatic document processing,
Prentice-Hall, 1971.

WISS2013

Touch-Shake:ߴྸऀͷίϛϡχέʔγϣϯΛଅ͢ΠϯλϥΫςΟϒγεςϜ
ͷ։ൃͱධՁࢁ‫ ޱ‬ཅฏɹ ༄ ӳࠀɹ ஛઒ Ղ੒ ∗֓ཁ.
ຊ‫ڀݚ‬͸ɼߴྸऀͷίϛϡχέʔγϣϯΛଅ͢ΠϯλϥΫςΟϒγεςϜʠ Touch-Shake ʡͷ։ൃͱධՁΛߦ͏ɽTouch-Shake ͸਎ମ઀৮Λ‫ݕ‬஌͢Δ๮ঢ়ͷσόΠεͰɼ࢖༻Ϣʔβͷ੩ి༰ྔʹԠͯ͡
Touch-Shake ຊମ͔Βൃ͢ΔԻͱޫ͕มԽ͢Δɽ·ͨɼϢʔβ͸઀৮૬ख΍ਓ਺ɼ‫ݸ‬ʑͷମ֨΍ମௐʹԠ༷ͯ͡ʑͳΠϯλϥΫγϣϯΛಘΒΕΔɽ͜ͷͨΊɼϢʔβ͸ Touch-Shake Λ༻͍ͨ਎ମ઀৮Λ൐͏ίϛϡχέʔγϣϯָ͕͘͠ͳΓɼ਌ີͳίϛϡχέʔγϣϯͷ‫ػ‬ձ͕૿͑ΔɽຊߘͰ͸հ‫ޢ‬࿝ਓอ݈ࢪઃͷೖ‫ऀډ‬͕ Touch-Shake Λ༻͍Δࢼ༻࣮‫ݧ‬Λ௨ͯ͡ɼίϛϡχέʔγϣϯͷଅਐʹؔ͢Δ༗༻ੑʹ͍ͭͯ‫ͨ͠ূݕ‬ɽ

1

͸͡Ίʹ

զʑͷίϛϡχέʔγϣϯʹ͸ɼ‫ͱޠݴ‬ඇ‫ޠݴ‬ͷ
େ͖͘ 2 छྨ͋Δɽඇ‫ޠݴ‬ίϛϡχέʔγϣϯʹ͸
ද৘΍ࢹઢɼ‫ٵݺ‬΍਎ମ઀৮ͳͲͷඇ‫ޠݴ‬৘ใ͕͋Γɼίϛϡχέʔγϣϯʹ͓͍ͯॏཁͰ͋Δɽಛʹɼ਎ମ઀৮Λ൐͏ର໘ίϛϡχέʔγϣϯ͸਌ີͳίϛϡχέʔγϣϯͰ͋Γɼհ‫ޢ‬࿝ਓอ݈ࢪઃͰ͸ɼೖ‫ʹऀډ‬ϦϥοΫεޮՌΛ༩͑ΔͨΊʹ༻͍ΒΕͯ
͍Δ [1]ɽ·ͨɼTatsumi Β [2] ͸ɼߴྸऀʹҙਤతͳ਎ମ઀৮Λ 3 ෼ؒߦ͏ͱɼߴྸऀ͸҆৺‫ײ‬ΛಘΔ͜ͱΛࣔͨ͠ɽ͔͠͠ɼ೔ຊਓ‫Ͱؒऀױͱࢣޢ؃‬਎ମ઀৮Λߦ͏࣌ؒ͸ɼίϛϡχέʔγϣϯΛߦ͏૯࣌ؒͷ 0.2%ͷΈ [3] ͱେมগͳ͍ɽ
ɹͦ͜Ͱຊ‫ڀݚ‬͸ɼ਎ମ઀৮ͱ͍͏਌ີͳίϛϡχέʔγϣϯΛଅ͢ΠϯλϥΫςΟϒγεςϜɼTouchShake ͷ։ൃΛߦ͏ɽTouch-Shake ʹ͸ɼ਎ମ઀৮
Λ‫ݕ‬஌͢Δ੩ి༰ྔηϯα͕౥ࡌ͞Ε͓ͯΓɼ࢖༻Ϣʔβ‫ݸ‬ʑͷମ֨΍ମௐɼ઀৮૬ख΍઀৮ͷ࢓ํʹԠͯ͡ޫ΍Իͷ൓ԠΛมԽͤ͞Δ‫ػ‬ೳΛ࣋ͭɽ͜ͷ‫ػ‬ೳʹΑΓɼϢʔβಉ࢜ͷ઀৮΁ͷϞνϕʔγϣϯ͕ߴ·Γɼձ࿩͕ੜ·Εɼ਎ମ઀৮ʹΑΔίϛϡχ
έʔγϣϯͷ‫ػ‬ձΛ૿΍ͤΔɽ·ͨɼຊߘ͸ TouchShake[4] Λߴྸऀ޲͚ʹԠ༻ͤͨ͞΋ͷͰ͋Δɽ

2ؔ࿈‫ڀݚ‬
Iida Β͕։ൃͨ͠ Enhanced Touch[5] ͸ɼਓମ௨৴Λ༻͍ͨ࿹ྠ‫ܕ‬ͷίϛϡχέʔγϣϯπʔϧͰɼਓͱ઀৮͢Δͱ LED ͕ޫΔɽBaba Β͕։ൃͨ͠
Freqtric Drums[6] ͸ɼਓʹ৮ΕΔ͜ͱͰ਺छྨͷυϥϜԻ͕໐Δిࢠָ‫͋Ͱث‬Δɽ
ɹ͜ΕΒ͸ɼਓͱ઀৮͢ΔͱԻ΍ޫΛൃ͠ɼର໘ίϛϡχέʔγϣϯΛࢧԉ͢Δ఺Ͱຊ‫ͯ͠ࣅྨͱڀݚ‬͍Δɽ͔͠͠ Touch-Shake ͸ɼ࢖༻Ϣʔβ‫ݸ‬ʑͷ∗

Copyright is held by the author(s).
ࢁ‫ ޱ‬ཅฏɹ ༄ ӳࠀɹ ஛઒ Ղ੒- 133 -

ମ֨΍઀৮૬खͳͲʹԠָͯ͡‫͕ޫͱۂ‬มԽ͢Δͨ
Ίɼ઀৮ߦҝʹ‫ۮ‬વੑΛऔΓೖΕΔ‫ػ‬ೳ͕͋Δɽ·ͨɼ઀৮தʹσόΠεΛৼͬͯԻ΍ޫΛൃ͢ΔͳͲɼ઀৮தʹ΋ίϛϡχέʔγϣϯΛָ͠ΊɼϞνϕʔγϣϯΛߴΊΒΕΔ఺΋ଞ‫ͱڀݚ‬ҟͳΔɽ

3Touch-Shake ͷ֓ཁ

3.1 γεςϜߏ੒
Touch-Shake ͷ֎‫༻࢖ͱ؍‬தͷ༷ࢠΛਤ 1 ʹࣔ͢ɽTouch-Shake ͸ 2 ຊͷ๮ঢ়ͷσόΠε͔Βߏ੒͞Εɼ1 ਓ͕ 1 ຊͷ๮Λ࣋ͬͯར༻͢Δɽ๮ঢ়Λબఆͨ͠ཧ༝͸ɼ
ʮߴྸऀ͸‫׳ݟ‬Εͳ͍෺Λ૷ண͢Δ͜ͱʹ఍߅‫ײ‬Λ๊͘ʯʮϚϥΧε΍λϯόϦϯͳͲɼ࣋ͬ
ͯ༡Ϳָ‫ث‬Λ৮Δ͜ͱʹ఍߅͸ແ͍ʯ͜ͱ͕ɼհ‫ޢ‬࿝ਓอ݈ࢪઃͷࣄલௐࠪͰ൑໌͔ͨ͠ΒͰ͋Δɽ

3.2 Touch-Shake ͷ‫ػ‬ೳ
3.2.1 ‫ػ‬ೳ (a)ਤ 2-(a) ʹࣔ͢Α͏ʹ਎ମ઀৮Λ‫ݕ‬ग़͢ΔͱɼεϐʔΧ͔Βָ‫࠶͕ۂ‬ੜ͞Εͯ LED ͕ޫΓɼ਎ମΛ཭͢ͱָ‫ۂ‬͸ࢭ·Γ LED ͸ফ౮͢Δɽָ‫ۂ‬͸ɼߴྸऀ͕ฉ͖‫׳‬Ε͍ͯΔಐག͔ͭɼTatsumi Β [2] ͷ‫ʹڀݚ‬Ԋͬͯ਎ମ઀৮͕࣌ؒ 3 ෼Ҏ্ʹͳΔΑ͏ 1‫ ۂ‬3 ෼Ҏ্ͷ‫ۂ‬Λબఆͨ͠ɽ
3.2.2 ‫ػ‬ೳ (b)ਤ 2-(b-1) ʹࣔ͢Α͏ʹɼ੩ి༰ྔηϯαͷ‫౓ײ‬ΛߴΊΔ͜ͱͰᮢ஋Λઃఆ͠ɼϢʔβ͕਎ମ઀৮͢
Δ͜ͱͰมԽͨ͠੩ి༰ྔʹ߹Θָͤͯ‫ ͱۂ‬LED ͕
มԽ͢Δɽ͜ͷಛੑΛ‫͠༻׆‬ɼ32 छྨͷָ‫ ͱۂ‬LEDͷޫ৭ύλʔϯΛ༻ҙ͢Δ͜ͱͰɼਤ 2-(b-2) ʹࣔ͢Α͏ʹϢʔβͷମ֨΍઀৮͢Δਓ਺ͳͲʹΑָͬͯ‫ۂ‬΍ޫ৭ύλʔϯ͕มΘΔɽ·ͨɼ઀৮໘ੵΛେ͖͘͠ɼ੎͍Α͘૬खͱ઀৮͢Δ͜ͱͰ΋ָ‫ޫͱۂ‬৭͸มԽ͢Δ (ਤ 2-(b-3))ɽ

WISS 2013͍͕ͨɼಛʹඃ‫ऀݧ‬͸େม‫ت‬Μͩ‫ Ͱإ‬Touch-ShakeΛ௨ͨ͡ίϛϡχέʔγϣϯΛަΘ͍ͯͨ͠ɽ͔͠
͠ɼ೉ௌͷͨΊԻ͕গ͠ฉ͑͜ʹ͍༷͘ࢠͰ͋ͬͨɽ
ͦͷ‫ޙ‬ɼඃ‫ऀݧ‬͸‫ ܭ‬9 ໊ͷํͱ‫ ʹڞ‬Touch-Shake Λ1 ೔ 15-20 ෼࢖༻͓ͯ͠Γɼ৺਎తʹྑޮՌΛಘΒΕΔͱ͞Ε͍ͯΔ 3 ෼Λେ෯ʹ௒͍͑ͯͨɽ·ͨɼʮ৭ʑͳਓͱ༡΂ָ͍ͯ͠ʯͱɼTouch-Shake Λ࢖༻͢ΔϞνϕʔγϣϯ΋อͨΕ͍ͯͨɽɹҎ্ͷ݁Ռ͔Βɼඃ‫ऀݧ‬͸ 1ϲ݄ͷ௕‫ظ‬త‫Ͱؒظ‬΋ϞνϕʔγϣϯΛอ͍ͬͯͨ͜ͱ͕൑໌ͨ͠ɽ·ͨɼ૬खͱָ͘͠ձ࿩΍ՎΛՎ্͍ͬͯͨʹɼ਎ମ઀৮
΁ͷ఍߅‫ײ‬Λ๊͍͍ͯͳ͔ͬͨɽ͜ΕΒΑΓɼ਌ີͳίϛϡχέʔγϣϯΛଅਐͰ͖ͨͱߟ͑ΒΕΔɽ‫ػ‬ೳʹؔͯ͠ɼ઀৮૬खʹΑͬͯԻ΍ޫͷԋग़͕ม
Խ͢Δ͜ͱʹָ͠͞Λ‫͡ײ‬ɼ༷ʑͳਓͱ઀৮͢ΔϞνϕʔγϣϯʹ‫͍͕ͨͯͬܨ‬ɽ·ͨɼTouch-Shakeࣗମʹରͯ͠΋఍߅‫ײ‬͸ແ͘ɼ‫ظ‬଴‫ײ‬Λ๊͍͍ͯͨɽ

スピーカ
LED
加速度センサ電極

ਤ 1. Touch-Shake ͷ֎‫جͱ؍‬൫ਤ
(a)

〜♪ ♪〜

Touch !

(b-1)

静電容量

(b-2)
〜

音・LED の色が変更
〜

A

〜♪ ♪〜

B

A

C

〜

♪

〜

A

B

C

5

音・LED の色が変更

(b-3)
〜

〜

A

B

Change !

〜♪

♪〜

A

B

ຊ‫Ͱڀݚ‬͸ɼߴྸऀͷίϛϡχέʔγϣϯΛଅ͢ΠϯλϥΫςΟϒγεςϜʠ’ Touch-Shake ʡΛߏஙͨ͠ɽ࣮‫݁ݧ‬Ռ͔ΒɼϢʔβ͸ Touch-Shake Λ༻͍ͨ਎ମ઀৮ʹΑΔίϛϡχέʔγϣϯָ͕͘͠ͳ
Γɼস‫Ͱإ‬૬खͱձ࿩΍ՎΛՎ͍ͬͯΔ༷ࢠ͕ଟ͘
‫ݟ‬ΒΕɼίϛϡχέʔγϣϯΛଅਐͰ͖ͨɽ

〜♪

(c)
効果音が鳴る

音量が変化

ਤ 2. Touch-Shake ͷ‫ػ‬ೳࢀߟจ‫ݙ‬

3.2.3 ‫ػ‬ೳ (c)ਤ 2-(c) ͷΑ͏ʹɼ઀৮தʹยํͷσόΠεΛৼΔͱޮՌԻ͕໐Γɼ΋͏ҰํΛৼΔͱԻྔௐઅͰ͖Δɽ

4

ධՁ࣮‫ݧ‬

4.1 ࣮‫ํݧ‬๏
Touch-Shake ͕հ‫ޢ‬࿝ਓอ݈ࢪઃͷೖ‫ऀډ‬ͷίϛϡχέʔγϣϯʹͲͷΑ͏ͳӨ‫ڹ‬Λ༩͑Δ͔࣮‫ݧ‬Λߦͳͬͨɽඃ‫ऀݧ‬͸ 80 ୅ͷํ 1 ਓͰɼ1ϲ݄ؒհ‫ऀޢ‬΍ೖ‫ऀډ‬ɼՈ଒ͱ Touch-Shake Λ࢖༻͍ͯͨ͠
͍ͩͨɽ࣮‫͢ݧ‬Δʹ͋ͨΓɼհ‫ऀޢ‬΍‫࢜ޢ؃‬ͷํʹඃ‫ऀݧ‬ͷ༷ࢠΛॻ͍͍͖ͯͨͩͳ͕ΒௐࠪΛߦͬͨɽ

4.2

·ͱΊ

݁Ռͱߟ࡯

࣮‫ॳݧ‬೔ɼඃ‫ऀݧ‬͸ॳΊͯ‫ݟ‬Δ Touch-Shake ʹରͯ͠ʮϫΫϫΫͯ͘͠ΔͶʯͱ‫ظ‬଴‫ײ‬Λ๊͍͍ͯͨɽॳ೔͸ೖ‫ ͱऀډ‬Touch-Shake Λ࢖༻͠ɼʮΑ͘ࢥ͍ͭ͘Ͷʯʮ໘ന͍ʯͳͲձ࿩Λ͠ͳ͕Β͓‫͍ޓ‬ָ͠ΜͰ͍ͨɽ࣮‫ ݧ‬3 ೔໨ʹ͸ Touch-Shake ͷ࢖༻ʹ‫׳‬ΕɼԻָʹ߹ΘͤͯՎΛՎ͍ɼ‫ت‬͹Ε͍ͯͨɽ·ͨɼ૬खʹΑָͬͯ‫ۂ‬΍ LED ͕มԽ͢Δ͜ͱΛෆࢥٞʹࢥ͍ͳ͕Β΋ɼস‫Ͱإ‬਎ମ઀৮Λߦ͍ͬͯͨɽଙͱ࢖༻ͨ࣌͠͸ɼ͓‫͍ޓ‬গ͠রΕস͍Λͯ͠- 134 -

[1] ઙҪ͓͞Γ, ా্໌೔߳, পຊ‫ࢠڭ‬, ੢ాਅणඒ,ߴాૣබ, հ‫ޢ‬࿝ਓอ݈ࢪઃͰͷ‫ޢ؃‬৔໘ʹ͓͚Δλονͷಛ௃, ࿝೥‫ ֶޢ؃‬: ೔ຊ࿝೥‫ֶޢ؃‬ձࢽ : journal of Japan Academy of GerontologicalNursing 7(1), 70-78, 2002-11.
[2] K. Tatsumi, Y. Adachi, Y. Yokota, M. Ashikaga, S. Tanaka, T. Sakai, Effects of Body Touching Therapy on the Elderly. In Proceedings of the
Journal of International Society of Life Information Science 18(1), pp. 246–253, 2000.
[3] ࢁ‫ޱ‬૑, ‫ࢣޢ؃‬-‫ؒऀױ‬ͷඇ‫ߦޠݴ‬ಈͷ࣮ࡍͱ՝୊
ʖ਎ମ৺ཧֶͷཱ৔͔Βʖ , ࡩඒྛ࿦ߟ. ৺ཧɾ‫ڭ‬ҭֶ‫ ڀݚ‬2, 73-83, 2011-03.
[4] Yamaguchi, Y. Yanagi, H., Takegawa, Y. TouchShake: Design and Implementation of a PhysicalContact Support Device for Face-to-Face Communication, Proceeding of IEEE Global Conference on Consumer Electronics (GCCE2013), pp.
170–174 (Oct. 2013).
[5] K. Iida, K. Suzuki. Enhanced Touch a Wearable
Device for Social Playware. In Proceedings of theACM 8th Advances in Computer Entertainment
Technology Conference, 2011.
[6] T. Baba, T. Ushiama, K.Tomimatsu, Freqtric
Drums : a Musical Instrument that uses Skin
Contact as an Interface. In Proceedings of the
7th international conference on New interfaces
for musical expression, pp.386–387, 2007.

WISS2013

倍音分析によるいい声作りの支援アプリに向けて
菅原 衣織

伊藤 貴之∗

概要. なぜこの人の演説は記憶に残るのか．なぜあの人の歌は心に響くのか．言葉やテクニックだけでは伝わらないこの熱い想い，それを伝えてくれるのが声色である．声色の表現次第でいい印象を与えることも悪い印象を与えることもできる．では，いい印象を与える声とはどんな声であるのか．我々は必要とされる声の印象は用途や状況によって変化するものであると考えた．そこで，本研究では倍音に着目し音声を分析し，倍音が与える印象に基づいて声の傾向を視覚化し提示することで，ユーザが自発的に各々の目指す声に近づけるような支援システムの開発を目標にしている．

はじめに

1
1.1

日常生活での声の役割

私たちが生活する上で切っても切り離せないコ
ミュニケーション．そのコミュニケーションを円滑にし，私たちの人柄をことば以上に伝えてくれるのが，声である．明るく明瞭な声で話している人にはいい印象を受けることが多く，逆にぼそぼそとはっ
きりしない声で話す人には好印象を受け難いことが多い．また，メラビアンの法則 [1] として従来から知られているように，コミュニケーションにおいて人の行動が他人にどのように影響を及ぼすかという実験では，言語情報が 7 ％，聴覚情報が 38 ％，視覚情報が 55 ％を占めるという考え方がある．このように，声の印象が自己の評価に与える影響は少な
くない．

1.2

告では「整数次倍音」と呼び，基音に対して非整数倍の周波数を持つ音の成分を「非整数次倍音」と呼ぶ．図 1 は整数次倍音が大きく含まれる声，図 2 は非整数次倍音が大きく含まれる声に対して，横軸を周波数，縦軸を音量として周波数分布を示したものである．尺八奏者の中村は著書 [2] の中で，整数次倍音が強いとカリスマ性や明朗性，豊かさが印象付
けられ，非整数次倍音が強いと情緒や親密感が印象付けられると述べている．本研究ではこれらの特徴を分析することで声色の印象を評価する．また本報
告ではこれ以降，非整数次倍音を含む広義の倍音を「倍音」と称する．

本研究におけるいい声

本研究では，声の印象，つまり声色の観点から「いい声」を追求し，これを支援するシステムの作成を目標にした．一般的に「いい声」と判断するためには，滑舌や話の速度，声の大きさなどいくつかの要
素が複雑に絡んでくると考えられる．しかし，滑舌は早口言葉の練習を積むことで良くなり，声の大きさは拡声器を使うことで補正が可能であるように，いくつかの要素は既存の手法を用いて改善される．
そこで本研究では声色の印象に絞って議論を進める．
声色の印象を左右する要素として，我々は倍音に着目した．音楽理論などにおいて倍音とは，楽音の音高とされる周波数に対して，2 以上の整数倍の周波数を持つ音の成分を指す．このとき楽音の音高を決定する成分を基音と呼ぶ．基音と倍音はフーリエ変換等の周波数変換手法を用いることで検出が可能である．以上のように定義される狭義の倍音を本報∗

図 1. 整数次倍音が大きく含まれる声図 2. 非整数次倍音が大きく含まれる声

2

関連研究

人間の発声に着目し，ユーザがいい声を出せるよ
うに身体的スキルの向上を促すメディアの提案を目

Copyright is held by the author(s).
お茶の水女子大学大学院人間文化創成科学研究科理学専
攻情報科学コース- 135 -WISS 2013

的とする発声のメタ認知促進システム”いい声マイク”の提案 [3] では，いい声を「音としてしっかりと発せられていて，響いている声」と定義している．
また，モテ声診断 VQ チェッカー [4] というウェ
ブサイトおよびスマートフォン用の人気アプリケー
ションがある．このサービスでは「声の高さ」「声の大きさ」「一音の長さ」「耳への入りやすさ」「滑舌の良さ」の 5 つの項目から声の良さを定義している．

3

いい声作りの支援アプリに向けて本研究では，ユーザが自身の声色を改善するための支援を目的としたアプリケーションを開発している．ユーザがモバイル端末上で本アプリケーション
を用いて日常的に自身の声を省みることができるよう，我々は Android 上で本アプリケーションを開発している．本アプリケーションでは，まず Androidの Visualizer クラスを用い音声に高速フーリエ変換を適用し，その周波数分布を取得する．そして取得した周波数分布から，倍音の傾向を導く指標として以下の二値を算出する．

を提示している．芸能人の倍音の特徴取得には，サンプルボイスやラジオやテレビ番組で取得した声，
そして中村の著書 [2] の内容を参考にしている．

3.2

視覚変数による提示

我々は現在，本アプリケーションを拡張し，より感覚的に倍音成分を理解できるように，倍音の傾向
や音圧などを視覚変数に割り当てて提示する機能を開発中である．この機能では，草間らの MusCat [5]のデザインを参考にした図 4 のようなデザインを採用している．

• 倍音を構成する各周波数領域の音圧の総計 Pt• 整数次倍音の音圧の倍音全体に対する比率 Pi

この算出結果により，自身の声にどの程度豊かな倍音が含まれているのか，また整数次倍音が強いのか
非整数次倍音が強いのか，といった情報を得ることができる．
本アプリケーションの処理手順を図 3 に示す．声色を示す倍音成分を視覚的にユーザに提示する方法として，我々は現在以下の 2 種類を開発中である．

図 4. 倍音成分を視覚変数に割り当てたデザイン

4

まとめと今後の課題

本報告では，個人のニーズに応じた声色改善の支援を目的として，倍音に着目した声色提示のアプリ
ケーションを提案した．本アプリケーションでは倍音成分の算出結果を，芸能人に喩える，視覚変数を用いる，の 2 種類を用いて提示する．今後の課題として，実際に被験者に本アプリケーションを一定期間使用してもらい，被験者の声がどのように変化するか観察したい．

参考文献[1] A. Mehrabian: Silent messages, Wadsworth, Belmont, California (1971).

図 3. 本アプリケーションの処理手順

3.1[2] 中村明一: 倍音 音・ことば・身体の文化誌, 春秋社(2010).

芸能人を例にした提示

本アプリケーションでは結果提示の際に，同じよ
うな倍音傾向にある芸能人を例に挙げて提示する．
例えば，整数次倍音成分が大きければ（＝ Pi が大きければ）タモリ氏や黒柳徹子氏を，非整数次倍音成分が大きければ（＝ Pi が小さければ）明石屋さんま
氏や桑田佳祐氏を，倍音成分が少なく基音に近い声の場合は（＝ Pt が小さければ）クリス・ペプラー氏- 136 -

[3] 矢島佳澄，筧康明，諏訪正樹: 発声のメタ認知促
進システム”いい声マイク”の提案，情報処理学会
インタラクション 2011 (2011).
[4] 声 総 研:
モ テ 声 診 断 VQ チェッカ ー,
http://www.koesouken.com/vqchecker/(2001).
[5] K. Kusama, T. Itoh, Abstract Picture Generation
and Zooming User Interface for Intuitive Music
Browsing, Springer Multimedia Tools and Applications, 10.1007/s11042-012-1108-y(2012).

WISS2013

Unisoner: ಉҰָ‫ۂ‬ΛՎͬͨҟͳΔՎ੠ΛॏͶ߹ΘͤΔ߹এ੍࡞ࢧԉΠϯλϑΣʔε౎ங ‫ܓ‬ଠɹத໺ ྙ༃ɹ‫ޙ‬౻ ਅ޹ɹࢁా ෢ࢤɹ຀໺ তೋ∗
֓ཁ. ຊߘͰ͸ɼWeb ্Ͱެ։͞Ε͍ͯΔʮҰͭͷ‫ۂ‬Λ༷ʑͳՎख͕ՎͬͨՎ੠ʯΛෳ਺ॏͶ߹Θͤͯ࡞ΒΕΔ߹এ࡞඼Λର৅ͱ͠ɼͦͷ੍࡞ͱؑ৆Λಉ࣌ʹ࣮‫͖Ͱݱ‬Δ߹এ੍࡞ࢧԉΠϯλϑΣʔε UnisonerΛఏҊ͢Δɽैདྷɼଟ༷ͳָ‫ۂ‬Λ૊Έ߹Θͤͯ৽ͨͳ࡞඼Λ੍࡞͢ΔΠϯλϑΣʔε͸ఏҊ͞Ε͖͕ͯͨɼ
ಉҰָ‫ۂ‬ͷҟͳΔՎ੠ΛॏͶ߹ΘͤΔ߹এ࡞඼ͷͨΊͷ΋ͷ͸ͳ͔ͬͨɽ·ͨɼ߹এ࡞඼Λ੍࡞͢ΔͨΊʹඞཁͳιϑτ΢ΣΞ΍ͦͷૢ࡞͸ઐ໳తͰɼ൐૗Իͷ཈੍΍೾‫͍ͨͮجʹܗ‬ख࡞‫Ͱۀ‬ͷҐஔ߹Θ͕ͤඞཁ
Ͱ͋Δ౳ɼ੍࡞ͷෑ‫͔ͨͬߴ͕ډ‬ɽUnisoner ͸Վ੠ͷग़‫ࠨͱࠁ࣌ݱ‬ӈνϟωϧͷԻྔൺΛϚ΢εૢ࡞͚ͩͰࢦఆͰ͖ɼઐ໳஌ࣝͷͳ͍ϢʔβͰ΋खܰʹ߹এ੍࡞Ͱ͖ΔɽϢʔβ͸ϦΞϧλΠϜʹੜ੒͞ΕΔ߹এ
Λௌ͖ͳ͕ΒɼՎ੠Λ੾Γସ͑ͨΓ௥ՃͰॏͶ߹ΘͤͨΓ͢ΔΠϯλϥΫγϣϯʹΑͬͯ߹এ੍࡞͢Δɽ

1

͸͡Ίʹ

ۙ೥ɼ༷ʑͳϢʔβ͕‫ط‬ଘͷָ‫ۂ‬ΛՎএͨ͠Իָ
࡞඼ʢҎԼɼ୯ʹʮՎ੠ʯͱ‫Ϳݺ‬ʣ͕ Web ্Ͱଟ਺ެ։͞Ε͍ͯΔɽ͜ΕʹΑͬͯɼಉҰָ‫ۂ‬Λଟ༷ͳՎ͍ճ͠΍੠࣭ͷՎ੠ͰԻָؑ৆Ͱ͖ΔΑ͏ʹͳΓɼ͜ΕΒΛ੾Γସ͑ͳ͕ΒॏͶ߹Θͤͨ߹এͷΑ͏ͳԻָ࡞඼ʢҎԼɼ୯ʹʮ߹এʯͱ‫Ϳݺ‬ʣ΋੍࡞͞ΕΔΑ͏ʹͳͬͨʢਤ 1ʣɽ߹এΛ੍࡞͢Δʹ͸ɼ·ͣ൐૗Λ཈੍ͯ͠‫ݸ‬ʑͷՎ੠Λநग़͢ΔʢΧϥΦέԻ‫ݯ‬౳Λར༻ʣɽͦͷ‫ޙ‬ɼͦΕΒෳ਺ͷՎ੠೾‫ܗ‬ͷ੾ΓషΓ΍ɼࠨӈνϟωϧͷԻྔൺௐ੔ͳͲઐ໳తͰ൥ࡶͳख࡞‫͕ۀ‬ඞཁͱͳΔɽͦͷͨΊɼઐ໳஌͕ࣝͳ͍ਓͷ߹এ੍࡞͸ෑ‫ډ‬͕ߴ͍ɽ΋͜͠ͷΑ͏ͳෑ‫ډ‬ΛԼ͛Δ͜ͱ͕Ͱ͖Ε͹ɼ୭Ͱ΋߹এίϯςϯπͷ૑࡞Λָ͠Ή͜ͱ͕Ͱ
͖Δɽ͞ΒʹɼͦΕͧΕͷՎ੠͕Ұͭͷ࡞඼Ͱ͋Δ
͜ͱ͔Βɼखܰͳ߹এ੍࡞͸Իָ૑࡞Ͱ͋Γͳ͕ΒೳಈతͳԻָؑ৆ [4] ͱͯ͠ͷՄೳੑ΋࣋ͭɽͦ͜ͰຊߘͰ͸্‫Ͱه‬ड़΂ͨΑ͏ͳख࡞‫ۀ‬ͷҰ෦ΛࣗಈԽ͢Δ͚ͩͰͳ͘ɼ௚‫ײ‬తͳՎ੠ͷॏͶ߹ΘͤΠϯλϥΫγϣϯ͕Մೳͳ߹এ੍࡞ࢧԉΠϯλϑΣʔε UnisonerʢΏʹͧͳʣΛఏҊ͢Δɽैདྷɼෳ਺ͷָ‫ۂ‬Λର৅ͱͯͦ͠ΕΒΛ࿈ଓతʹ࠶ੜ͢Δ
Α͏ͳԻָؑ৆ΠϯλϑΣʔε [5,7] ΍ɼָ‫ۂ‬ΛϚογϡΞοϓʢॏͶ߹Θͤʣ͢ΔΠϯλϑΣʔε [1–3]͸‫͞ڀݚ‬Ε͖͕ͯͨɼଟ༷ͳՎ੠ΛॏͶΔ߹এʹண໨ͨ͠ΠϯλϑΣʔε͸ͳ͔ͬͨɽ

∗ਤ 1. Վ੠ͱ߹এͷ೿ੜؔ܎ɽ

2खܰʹ߹এ੍࡞Ͱ͖Δ Unisoner

Unisoner ͷಈ࡞ը໘Λਤ 2 ʹࣔ͢ɽUnisoner Ͱ͸‫ݸ‬ʑͷՎ੠ΛΞΠίϯͰද͠ (ਤ 2 !
A )ɼͦΕΒΛεςʔδ্ (ਤ 2 !
B ) ʹ഑ஔ͢ΔΠϯλϥΫγϣ
ϯʹΑͬͯ߹এΛ੍࡞͢Δɽ͜ͷΑ͏ͳՎ੠ΞΠίϯ͸ࣗಈਪఆ͞ΕͨՎखͷੑผʹԠͯ͡৭͕ҟͳΔʢஉ੠͕੨ɼঁ੠͕੺ʣɽ͜͜ͰɼՎ੠Λ੾Γସ͑ͨΓɼ৽ͨʹॏͶΔՎ੠Λ௥Ճͨ͠Γͱ͍ͬͨ࣌ࠁͷࢦఆΛՎࢺʹ‫͍ߦ͍ͯͮج‬ɼͦͷΑ͏ͳ࣌ࠁؒΛηΫγϣϯͱ‫Ϳݺ‬ɽϢʔβ͸ϦΞϧλΠϜʹੜ੒͞ΕΔ߹এΛௌ͖ͳ͕ΒɼηΫγϣϯΛ۠੾ͬͨΓՎ੠Λ഑ஔͨ͠Γ͢Δ͜ͱͰɼ߹এͷ੍࡞Λߦ͏ɽҎ߱ɼͦͷΑ͏ͳ੾Γସ͑࣌ࠁͷࢦఆͱՎ੠ͷ഑ஔʹ͍ͭͯઆ໌͢Δɽ

Copyright is held by the author(s).
Keita Tsuzuki, ஜ೾େֶେֶӃ γεςϜ৘ใ޻ֶ‫ڀݚ‬Պ, Tomoyasu Nakano and Masataka Goto, ࢈‫ٕۀ‬ज़૯߹‫( ॴڀݚ‬AIST), Takeshi Yamada and Shoji Makino,ஜ೾େֶ γεςϜ৘ใ‫ܥ‬- 137 -

Վࢺʹ‫ͮ͘ج‬ηΫγϣϯͷࢦఆՎࢺ͸ָ‫ۂ‬தͷ࣌ࠁΛҰཡੑߴ͘೺Ѳ͢ΔͨΊʹ༗༻ͳ৘ใͰ͋ΔͨΊɼ͜ΕΛ‫͢༻׆‬Δɽैདྷͷ࣌ؒΛ༻͍ͨ࣌ࠁࢦఆʹൺ΂ͯಛఆͷՕॴͷ࠶ੜ͕͠΍͘͢ɼޮ཰͕ྑ͍ɽΠϯλϑΣʔεࠨଆʹදࣔ͞Ε͍ͯΔՎࢺ (ਤ 2 !
C ) ͸ʮηΫγϣϯ෼ׂϘλϯʯ!
(ਤ 2 D ) ʹΑͬͯ෼ׂͰ͖Δɽͦͷ۠੾ΓҐஔ͸ՎWISS 2013

ਤ 2. Unisoner ͷ࣮ߦը໘ͱΠϯλϥΫγϣϯͷྲྀΕɽεςʔδʹঁੑͷՎ੠ͱೋਓͷஉੑͷՎ੠Λ഑ஔͨ͠ྫɽ

ࢺ্ʹ఺ઢ (ਤ 2 !
E ) ͱͯ͠ද͞ΕɼϚ΢εͰυϥοά& υϩοϓ͢Δ͜ͱͰͦͷҐஔΛมߋͰ͖Δɽ
Վ੠ΞΠίϯͷεςʔδ্΁ͷ഑ஔ

Unisoner Ͱ͸ηΫγϣϯຖʹ഑ஔ͢ΔՎ੠΍ɼͦΕͧΕͷԻྔ‫ࠨͼٴ‬ӈνϟωϧͷԻྔൺΛɼՎ੠ΞΠίϯͷεςʔδ্΁ͷ഑ஔʹΑܾͬͯఆ͢Δɽ
Վ੠ΞΠίϯ͸Ұཡ (ਤ 2 !
F ) ͔Βબ୒͠ɼϚ΢εૢ࡞Ͱεςʔδ্΁഑ஔ͢Δ͕ɼͦͷࡍɼબ୒Λ
ޮ཰Խ͢ΔͨΊͷιʔτ‫ػ‬ೳͱϑΟϧλϦϯά‫ػ‬ೳΛ࣋ͭ (ਤ 2 !
G )ɽՎख໊ʢಈը౤ߘऀ໊Ͱ୅༻ʣɼ
࠶ੜ਺ɼϚΠϦετ਺ɼՎ͍ճ͠ͱ੠࣭ͷۙ͞ʹ‫ج‬ͮ͘ιʔτͱɼՎखͷੑผͱΩʔʢ૬ରతͳࠩʣʹΑΔϑΟϧλϦϯά͕ՄೳͰ͋Δɽεςʔδʹ͓͚Δલஈ‫ޙ‬ஈ͸Իྔͷେ͖͞Λද‫ݱ‬͠ɼલஈͷํ͕େ͖͍ɽ·ͨɼεςʔδͷࠨӈ͸ࠨӈνϟωϧͷԻྔൺʹରԠ͓ͯ͠Γɼྫ͑͹ࠨํ޲΁ಈ͔͢ͱࠨνϟωϧͷԻྔ͕େ͖͘ͳΔɽ
Unisoner ͷ࣮‫ํݱ‬๏
Unisoner Λ࣮‫͢ݱ‬ΔͨΊʹ͸ಉҰָ‫ۂ‬ʢ‫ۂݪ‬ʣΛՎͬͨෳ਺ͷՎ੠ͱɼͦΕΒՎ੠͔Β൐૗Λ཈੍͢ΔͨΊʹɼ൐૗Ի‫ͱݯ‬ͷ࣌ࠁ߹ΘͤͱΩʔͷҧ͍Λࣗಈਪఆ͢Δ৴߸ॲཧٕज़͕ඞཁͰ͋Δɽ͜ΕΒ৴߸ॲཧͷৄࡉ͸จ‫[ ݙ‬6] Ͱઆ໌͍ͯ͠Δɽ‫ࡏݱ‬ͷ࣮૷Ͱ͸ɼՎ੠ͷੑผ͸͜ͷΑ͏ͳ৴߸ॲཧ݁ՌʹΑͬͯɼ‫ۂݪ‬ͷԻߴͱൺֱͯ͠ΦΫλʔϒҟͳ͍ͬͯͨ
৔߹͸ɼ‫ͱۂݪ‬ҟͳΔੑผΛ෇༩ͨ͠ɽྫ͑͹ɼ‫ݪ‬‫ঁ͕ۂ‬ੑͰͦΕΑΓ΋ 1 ΦΫλʔϒ௿͍ԻߴͷՎ੠͸உੑͱͨ͠ɽΦΫλʔϒҎ֎ͷҟͳΓํΛ͍ͯͨ͠৔߹͸ɼ͍ۙੑผΛબ୒ͯ͠෇༩ͨ͠ɽ
Unisoner ͸χίχίಈը1 ʹ͓͍ͯɼ࠷΋ଟ͘Վ
1

http://www.nicovideo.jp- 138 -

ΘΕͨҰͭͷָ‫ۂ‬2 Λର৅ͱͯ͠ಈ࡞Λ֬ೝ͓ͯ͠
ΓɼͦΕҎ֎ͷָ‫ʹۂ‬ରͯ͠΋ӡ༻ՄೳͰ͋Δɽ͜͜Ͱ͸Վ੠ʹՃ͑ͯɼ࠶ੜ਺ɼϚΠϦετ਺ɼಈը౤ߘऀͷϢʔβ໊΋‫͢༻׆‬Δɽ

3

͓ΘΓʹ

ຊߘͰ͸߹এ੍࡞ࢧԉΠϯλϑΣʔεΛఏҊͨ͠ɽࠓ‫ޙ‬͸ɼͦΕͧΕͷՎ੠ͷ੠࣭΍Վ͍ճ͠ΛՄࢹԽ
͢Δ౳ɼ૑࡞ʹ༗ӹͳ৘ใΛఏࣔ͢Δ‫ػ‬ೳͷ֦ுΛ‫ݕ‬౼͍ͯ͠Δɽँࣙຊ‫ڀݚ‬ͷҰ෦͸ɼJSTʮOngaCREST ϓϩδΣΫτʯͷࢧԉΛड͚ͨɽ·ͨɼχίχίಈը্ͷָ‫ۂ‬Λѻ͏্Ͱ‫ྗڠ‬௖͍ͨᖛ࡚խ߂ࢯɼੴా‫ܒ‬հࢯʹ‫͢ँײ‬Δɽ

ࢀߟจ‫ݙ‬[1] M. Davies, et al. AutoMashUpper: An Automatic
Multi-Song Mashup System. Proc. ISMIR 2013, 2013.
[2] N. Tokui. Massh!—A Web-based Collective Music
Mashup System. Proc. DIMEA 2008, 2008.
[3] ‫ٶ‬ౡ. Music Mosaic Generator: ߴਫ਼౓࣌‫ྻܥ‬ϝλσʔλΛར༻ͨ͠ԻָϦϛοΫεγεςϜ. WISS 2007 ࿦จू, 2007.
[4] ‫ޙ‬౻. ԻָԻ‫ڹ‬৴߸ཧղʹ‫ͮ͘ج‬ೳಈతԻָؑ৆ΠϯλϑΣʔε. ৘ॲ‫ݚ‬ใ, 2007-MUS-96, 2007.
[5] ‫ޙ‬౻ ଞ. Musicream: ָ‫ۂ‬Λྲྀ͚ͯͬͭͯ͘͠ฒ΂Δ͜ͱͷͰ͖Δ৽ͨͳԻָ࠶ੜΠϯλϑΣʔε. WISS 2004
࿦จू, 2004.
[6] ౎ங ଞ. ༷ʑͳՎख͕ಉ͡‫ۂ‬ΛՎͬͨՎ੠ͷଟ༷͞Λ‫׆‬༻͢ΔγεςϜ. ৘ॲ‫ݚ‬ใ, 2013-MUS-100, 2013.
[7] ງ಺ ଞ. Song Surfing: ྨࣅϑϨʔζͰԻָϥΠϒϥϦΛࢄࡦ͢ΔԻָ࠶ੜγεςϜ. PIONEER R&D, 17(2),2007.
2χίχίಈըʹ͓͚Δಈը൪߸ sm15630734 Λ࢖༻ɽ2013೥ 10 ݄‫ࡏݱ‬ɼ͜ͷָ‫ʹۂ‬ରͯ͠ 5166 ‫ۂ‬ͷՎ੠͕͋Δɽ自由な筆記にロバストな手書き表認識システム
中洲 俊信

柴田 智行

井本 和範

三原 功雄

概要
自由に手書きされた表から，罫線，文字列，行や列などの表構造を安定して認識できる手法を提案する．手書きの表には，線の歪みや線同士の接続ずれなどの変動が生じる．変動にロバストな認識を実現するため，ユーザが手書きした多くの表から主要な変動パターンを洗い出し，それらに基づいて，罫線の抽
出，表構造の認識，セル内ストロークの抽出の３段階で表を認識する技術を開発した．手書きの表サ％を達成し，提案手法の有効性を示した．また，罫線の直線化
ンプルを対象とした評価実験で認識率や罫線同士が正しく接続するような修正により，表を視覚的に整える表整形インタフェースを試作した．

はじめに
近年，ペン入力に対応した携帯端末が注目され，タブレットやスマートフォンに書いた筆記をデジタ
ルデータとして処理することが可能になった．頭の中のアイデアを思いつくままに自由に書きとめ，それをすぐに整理・活用できることが価値の高い発想につながると考えられる．本稿では，様々な情報の関係性をわかりやすく可視化し情報整理に役立つツー
ルとして頻繁に使われる「表」に注目し，ユーザが自由に手書きした表から罫線，文字列，行や列などの表構造を認識し，即座に綺麗な表へと変換するシ
ステムを提案する（図 ）．
手書きの表は，線に歪みがあったり線同士の接続がずれていたりする．また，ユーザによって書かれる表の形式も様々である．手書き表認識に関する従来研究では，このような手書きの表に含まれる変動を広く洗い出して整理したものは少ない．本稿では，
事前検討として自由な手書きに伴う変動のパターンを洗い出し，主要な変動パターンに対してロバスト
な表認識手法を設計する．具体的には，筆跡の大まかな形状や関係性など特徴的な情報を利用し，単純な表のモデルに対応づけることでロバストに表罫線らによる従来技術
も手や表構造を認識する．
書きに対するロバスト性を考慮しているものの，図のように外周の罫線が書かれていない表を想定しておらず，認識が困難であった．本稿では，外周の罫線が書かれていない表も主要な変動パターンであると考え，認識できるように対応する．

入力例
図

認識・整形処理結果

筆者らが開発した手書き表認識システム

画の軌跡）を追記して１本の罫線が書かれている，
１本のストロークで複数の罫線が書かれているというパターンを抽出した．ここで， 本の罫線とは，表の左端から右端までを通る各行の境界，および，表の上端から下端までを通る各列の境界である．

手書き表認識手法
本提案手法では，ペンデバイスから得られた筆跡を入力とし，罫線の抽出，表構造の認識，セル内ス
トロークの抽出の ステップで表を認識する（図 ）．
：罫線の抽出手書きの表の特徴分析

長さが閾値以上で傾きが水平／垂直に近い線分を含むストロークを，罫線を構成するストロークとして抽出する．その後， 画で複数本の罫線が書かれている場合や複数画で 本の罫線が書かれている場合に対応できるよう，方向が変化する点でのストロー
ク分割や，同方向で位置的に近いストローク同士の統合を行い，水平／垂直の各罫線を認識する．

ユーザが手書きした表などを参考に，手書きの表に含まれる変動のパターンを洗い出した．抽出した事例を図 に示す．これらに加え， 複数のストローク（ペンが入力面に接してから離れるまでの１
株式会社東芝 研究開発センター- 139 -

図

手書きの表に含まれる変動パターン：表構造の認識
抽出した罫線を直線近似し，歪みのある罫線で構成された手書きの表を単純化する．その後，罫線の接続関係や，外周の罫線が省略された意図的な罫線
のはみ出しを認識する．意図的に罫線がはみ出して書かれている場合，はみ出し部分が相対的に長かったり，はみ出し部分で構築された領域に文字列が書かれていたりする．この知見から，罫線のはみ出し部分が他のセルのサイズに対して所定割合以上の長さである場合や，はみ出した罫線付近に閾値以上の
長さのストローク群が存在する場合に，意図的な罫
線のはみ出しと判定し外周罫線を補う．意図的なはみ出しと判定されなかった場合は，垂直（水平）罫
線の端点を最も端の水平（垂直）罫線に接続する．
：セル内ストロークの抽出
セル内の文字列の一部がセルからはみ出す場合も想定し，各セルに半分以上含まれるストロークをそのセルに内包するストローク群として抽出する．抽出したストローク群は一般の手書き文字認識技術に
より文字として認識する．

図

手書き表認識システムの処理過程

本提案手法の認識結果の再現率と適合率の調和平均％となり，様々として認識率を算出した結果，な形式の表を高精度で認識できていることがわかった．また，様々な書き方（罫線の歪み，接続のずれ，追記された罫線など）にも対応できていることが確認でき，本提案手法の有効性が示された．

まとめ

表整形インタフェースの試作
ユーザが手書きした表（図）に対し，罫線の直線化，外周罫線の補足，罫線の端点での接続処理を施し，即座に視覚的に綺麗な表へと変換する．また，セル内の文字列を所定のフォントに変換する．
なお，その場での表編集や，資料作成アプリの表オ）．
ブジェクトとしての活用も可能である（図

認識性能評価実験

手書きの表から罫線，文字列，表構造を認識可能な表認識技術を提案し，表整形インタフェースを試作した．なお，本技術はペン入力対応タブレットへの搭載という形で実用化された ．今後はシステ
ムの操作感に関するユーザ評価を予定している．
※本稿に掲載の商品，機能等の名称は商標として使用している場合があります．

参考文献

被験者
名が作成したサンプルの表を対象に，本提案手法の認識性能を調べた．これらのサン
プルは，外周の罫線が無いものやセル内が空欄になっ種類の多様な表を被験者が 回ているものなど
ずつ書き写して作成した．また，各表には，行数，
列数，罫線を構成するストローク，各セルに含まれるストローク群が特定できるように正解を教示した．

- 140 -

東 芝 製 ペ ン 入 力 タ ブ レット

東芝

WISS2013෦඼΁ͷϓϩδΣΫγϣϯϚοϐϯάʹΑΔ௨ి͠ͳ͍ిࢠ޻࡞ळࢁ ༾ɹɹ‫ٶ‬Լ ๕໌ ∗֓ཁ.
ఏҊγεςϜ͸ɼλονύωϧσΟεϓϨΠ্Ͱిࢠ෦඼ΛԾ૝తʹ݁ઢ͠ɼϓϩδΣΫγϣϯ
ϚοϐϯάʹΑ֤ͬͯछ LED ͳͲΛൃޫ͍ͯ͠ΔΑ͏ʹ‫ͤݟ‬Δిࢠ޻࡞‫͋Ͱڥ؀‬ΔɽԻ΍ΞχϝʔγϣϯʹΑΔϒβʔɾόΠϒϨʔλͷٙࣅಈ࡞ɼը૾ೝࣝͳͲʹΑΔೖྗૉࢠͷಈ࡞ʹ΋ରԠ͍ͯ͠ΔɽࢦΛۙͮ
͚Δͱ୺ࢠ͕֦େ͢Δ‫ػ‬ೳʹΑΓɼυϥοάૢ࡞͚ͩͰ݁ઢɾஅઢ͕ߦ͑Δɽిࢠ෦඼ళʹઃஔ͢Δ͜ͱͰະ։෧ͷ··෦඼ͷಈ࡞΍࢓༷Λ֬ೝͰ͖Δ΄͔ɼෳ਺ਓͰΘ͍Θ͍ͱ࡞‫ۀ‬Λߦ͏͜ͱ΋Ͱ͖Δɽ

1

͸͡Ίʹ

2

ిࢠճ࿏Λ࡞੒͢Δࡍʹɼ࡞੒ऀ͸ճ࿏ਤΛࢀরͯ͠ճ࿏Λ࡞੒͢Δ͕ɼ࣮ࡍʹ഑ઢΛ͢Δͱɼ೉͍͠৔߹͕͋Δɽͦ΋ͦ΋ճ࿏ਤ͸ɼ࣮ମ഑ઢਤͱ͸ҟͳΓɼճ࿏ਤ্ͰͷҐஔͱ࣮ࡍʹ഑ஔ͢Δ৔ॴ͕
ແؔ܎Ͱ͋Γɼճ࿏ਤͦͷ··ͷ഑ஔ΍݁ઢ͸‫࣮ݱ‬తͰ͸ͳ͍ɽ‫ʹނ‬ɼॳֶऀʹ͸ճ࿏ਤ͔Βճ࿏Λ࡞੒͢Δ͜ͱ͕೉͍͠৔߹͕͋ΔɽຊߘͰ͸ɼճ࿏ਤ௨Γͷ഑ઢΛՄೳͱ͢Δͱͱ΋ʹɼ෦඼ʹ௨ి͠ͳ
͍Ͳ͜Ζ͔ɼ෦඼Λ։෧͢Δ͜ͱ͑ͤͣ͞ʹిࢠ޻࡞Λߦ͑ΔγεςϜΛఏҊ͢ΔɽఏҊγεςϜ͸ɼిࢠ෦඼ʹϓϩδΣΫγϣϯϚοϐϯάΛߦ͏͜ͱʹΑͬͯɼLED ͳͲͷൃޫૉࢠ͕࣮ࡍʹಈ࡞͠ɼޫͬ
͍ͯΔΑ͏ʹ‫ͤݟ‬Δ΋ͷͰ͋Δɽ·ͨɼԻ΍ΞχϝʔγϣϯʹΑΔϒβʔ΍όΠϒϨʔλͷٙࣅಈ࡞ɼը
૾ೝࣝͳͲʹΑΔೖྗૉࢠಈ࡞ʹ΋ରԠ͍ͯ͠Δɽ
ʮճ࿏ਤ௨Γʹ഑ઢ͢Ε͹ྑ͍ͷͰʯɼॳֶऀ޲͚ͷిࢠ޻࡞πʔϧͱ͢Δ͜ͱ͕Ͱ͖Δͱߟ͍͑ͯΔɽ
υϥοάૢ࡞͚ͩͰߦ͑ΔσβΠϯΛ໨ࢦ͠ɼͦͷͨΊͷࢧԉ‫ߏػ‬Λ༻ҙͨ͠ɽਤ 1: ఏҊγεςϜશମਤ∗ఏҊγεςϜ͸λονύωϧσΟεϓϨΠͱϓϩδΣΫλΛ༻͍͍ͯΔʢਤ 1ʣɽλονύωϧରԠͷσΟεϓϨΠ͕ਫฏʹஔ͔Ε͓ͯΓɼ্෦ʹ͸ϓϩδΣΫλͱ web Χϝϥ͕ઃஔ͞Ε͍ͯΔɽϓϩδΣΫλͷදࣔൣғ͕σΟεϓϨΠʹͪΐ͏ͲॏͳΔΑ͏ͳߴ͞ʹϓϩδΣΫλΛ‫ݻ‬ఆ͠ɼදࣔҐஔͱλονҐஔΛ߹Θ͍ͤͯΔɽͳ͓ɼσΟεϓϨΠ໘ʹ͓͚ΔಁաޫʢόοΫϥΠτʣͱ൓ࣹޫʢϓϩδΣΫλʣͷόϥϯεΛͱΔͨΊʹσΟεϓϨΠ্ʹτϨʔγϯάϖʔύʔΛෑ͍͍ͯΔɽఏҊγεςϜ͸ɼϢʔβͷૢ࡞ɾ࡞‫ۀ‬ͷ಺༰Λ‫ݕ‬ग़͢Δೖྗ෦ͱɼૉࢠʹϓϩδΣΫγϣϯΛߦ͏ग़ྗ෦
ʹ෼͔Ε͍ͯΔɽఏҊγεςϜͷ࣮૷͸ ProcessingͰߦͬͨɽAR ϚʔΧʔΛ࢖༻ͯ͠σΟεϓϨΠͷ
දࣔྖҬͱΧϝϥͷը૾ͷҐஔ߹ΘͤΛ͢ΔͨΊʹ
NyARToolKit ϥΠϒϥϦΛ࢖༻͍ͯ͠Δɽ

2.1

ೖྗ

ఏҊγεςϜʹΑΔిࢠ޻࡞͸ɼϢʔβ͕ૉࢠͷҐஔΛઃఆ͢Δ͔ɼ͋Δ͍͸ϓϩάϥϜ͕ࢦఆ͢ΔҐஔʹૉࢠΛஔ͍͔ͯΒ࡞‫ۀ‬Λ։࢝͢Δɽ‫ࡏݱ‬ରԠ͍ͯ͠Δૉࢠ͸ɼ7 ηά LEDɾϚτϦΫε LEDɾϑϧΧϥʔ LEDɾ౾ి‫ٿ‬ͷൃޫૉࢠɼൃ
ԻૉࢠͳͲͷग़ྗૉࢠ͕͋Δɽ·ͨɼεΠονɼՄม఍߅ͳͲͷೖྗૉࢠʹ΋ରԠ͍ͯ͠Δɽೖྗૉࢠ
͸ɼͦͷҐஔͷϐΫηϧ͕ഽ৭͔Ͳ͏͔Λࣝผͯ͠ɼ
ࢦͷ༗ແΛೝࣝ͢Δ͜ͱͰ࣮૷͍ͯ͠Δɽ
ిࢠ෦඼ͷஔ͔Ε͍ͯΔσΟεϓϨΠΛυϥοά
͢Δ͜ͱͰઢΛҾ͖ɼԾ૝తͳδϟϯύઢͰ݁ઢΛߦ͏ɽ഑ઢ͢Δʹ͸ɼૉࢠͷ୺ࢠ͔Β୺ࢠ΁ͱυϥοά͠ɼஅઢ͢Δʹ͸ɼδϟϯύઢΛԣ੾ΔΑ͏ʹυϥοά͢Δʢਤ 2ʣɽࢦΛ͚ۙͮΔͱ୺ࢠ͕֦େ͢
ΔͳͲͷࢧԉ‫ػ‬ೳ΋౥ࡌ͍ͯ͠Δɽ

2.2

Copyright is held by the author(s).
Yoh Akiyamaɼ໌࣏େֶ ཧ޻ֶ෦ ৘ใՊֶՊɼHomei
Miyashita, ໌࣏େֶ ૯߹਺ཧֶ෦ ઌ୺ϝσΟΞαΠΤϯεֶՊ, ಠཱߦ੓๏ਓՊֶٕज़ৼ‫ߏػڵ‬, CREST

γεςϜ

ग़ྗ

ఏҊγεςϜ͸ɼ‫Ͱ఺࣌ݱ‬͸ૉࢠΛઃఆ௨Γʹઃஔ͢ΔͨΊͷΨΠυϥΠϯΛද͍ࣔͯ͠Δɽ͜Ε͸- 141 -WISS 2013ͨϞδϡʔϧ͕޿͘࢖ΘΕ͍ͯΔɽGainer ͸ϝσΟΞΞʔτʹ͓͚ΔࢧԉΛͻͱͭͷ໨తͱ͍ͯ͠Δɽଞʹ΋ Visible Breadboard[1] ΍ react3D Electric[2]ɼͦͯ͠ୈೋஶऀͷ HMMBB[3]ɼळాͷ LED
Tile ిࢠϒϩοΫͷΑ͏ʹɼAR తʹిྲྀΛՄࢹԽ
͢ΔγεςϜ͕‫͛ڍ‬ΒΕΔɽ

4
ਤ 2: Ծ૝తͳ݁ઢͱஅઢૢ࡞
࣮ߦ࣌ʹ͸ফ͢͜ͱ͕Ͱ͖Δɽग़ྗૉࢠɼಛʹൃޫૉࢠʹϓϩδΣΫγϣϯϚοϐϯάΛߦ͏͜ͱʹΑͬ
ͯɼਤ 2 ͷΑ͏ʹɼ࣮ࡍʹ௨ిͤͣʹಈ࡞͍ͯ͠ΔΑ͏ʹ‫ͤݟ‬Δ͜ͱ͕Ͱ͖ΔɽԾ૝తͳ݁ઢͰ͋ΔͨΊɼਤ 3 ͷΑ͏ͳૉࢠ͸ା͔Βະ։෧ͷ··ٖࣅಈ
࡞ͤ͞Δ͜ͱ΋ՄೳͰ͋Δɽ
LED ྨ͸ૉࢠͷઃఆҐஔʹ‫͢ޫൃ͍ͯͮج‬ΔՕ
ॴΛϓϩδΣΫλͰ౤Ө͢Δɽϒβʔ͸ɼ௨ి͞Εͨ࣌ʹύιίϯ͔ΒϒβʔԻΛग़ྗ͢Δ͜ͱͰ࣮૷
ͨ͠ɽόΠϒϨʔλʹ͍ͭͯ͸ϒβʔͱಉ͘͡όΠϒϨʔγϣϯͷಈ࡞ԻΛ໐Β͠ɼ͔ͭ਒͍͑ͯΔΑ
͏ͳΞχϝʔγϣϯΛपลʹදࣔ͢Δ͜ͱʹΑ࣮ͬͯ‫͍ͯ͠ݱ‬Δɽి஑͸‫ ࡏݱ‬9V ֯‫ిܕ‬஑ͱ୯ 3 ‫ిܗ‬
஑ͷ 2 छྨʹରԠ͍ͯ͠Δɽి஑্ʹ͸ϓϩδΣΫ
γϣϯϚοϐϯάΛߦΘͳ͍͕ɼϓϩάϥϜ಺෦Ͱ௨ిνΣοΫΛ͢Δ‫ͳͱ఺ى‬Δɽ
·ͨɼ഑ઢ͞Ε͍ͯΔՕॴͷϖΞΛදࣔ͢ΔδϟϯύઢΛදࣔ͢Δɽ഑ઢঢ়‫گ‬͸ճ࿏ߦྻͰอଘͯ͠
͍Δɽ௨ిνΣοΫΞϧΰϦζϜͱͯ͠͸ɼ‫ࡏݱ‬͸ిѹɾిྲྀɾ఍߅஋ͳͲͷ‫ࢉܭ‬͸͓ͯ͠Βͣɼดճ࿏
ͷ൑ఆͷΈߦ͍ͬͯΔɽి‫ݯ‬ૉࢠͷϓϥε‫ͬͳͱۃ‬͍ͯΔ௖఺͔Βਂ͞༏ઌ୳ࡧΛߦ͍ɼి‫ݯ‬ૉࢠͷϚ
Πφε‫ۃ‬ͷ௖఺ʹ୧Γண͍ͨ࣌ɼͦΕ·Ͱ௨ͬͨ௖
఺ʹ௨ి൑ఆΛग़͍ͯ͠Δɽ͓ΘΓʹ͜ͷγεςϜ͸ɼ‫ڭ‬ՊॻͳͲͷճ࿏ਤͱ࣮ࡍͷճ࿏੍࡞ͱͷΪϟοϓΛຒΊΔ͜ͱ͕Ͱ͖Δͱߟ͍͑ͯΔɽ·ͨɼ͜ͷγεςϜΛిࢠ෦඼ళʹઃஔ͢Ε͹ɼା͔Βະ։෧ͷ··෦඼ͷಈ࡞΍࢓༷Λ֬ೝͰ
͖ΔͨΊɼ෦඼બͼΛ͍··ͰΑΓշదʹߦ͑ΔΑ
͏ʹͳΔͱߟ͍͑ͯΔɽ·ͨɼෳ਺ਓͰճ࿏ΛऔΓғΈͳ͕ΒɼΘ͍Θ͍ͱ࡞‫ۀ‬Λߦ͏͜ͱ΋Ͱ͖Δɽ๯಄ʹड़΂ͨෳ਺ਓͰͷిࢠ޻࡞ͷՄೳੑͷଞʹɼγεςϜͷվྑ༧ఆΛ‫͢ه‬ɽ·ͣɼ֎෦ιϑτ΢ΣΞɼͨͱ͑͹ SPICE ΍ Virtual BreadBoard ͳͲͷγϛϡϨʔλͱ࿈ಈͯ͠ΑΓਖ਼֬ͳճ࿏γϛϡϨʔγϣϯ͕ߦ͑ΔΑ͏ʹվྑΛࢪ͍ͨ͠ɽ·ͨɼ
EAGLE ΍ PasS ͳͲͷ CAD ιϑτͱ࿈‫࣮͠ܞ‬ମ഑ઢਤͳͲΛग़ྗ͢Δ͜ͱʹΑΓɼϋϯμ෇͚ʹΑΔ੍࡞ʹͭͳ͛Δ͜ͱ͕Ͱ͖Δͱߟ͍͑ͯΔɽ‫ࡏݱ‬ɼఏҊγεςϜͰߏஙͰ͖Δճ࿏͸ʮ഑ઢʹద੾ͳ఍߅஋͕ઃఆ͞Ε͍ͯΔʯͱ͍͏લఏͰಈ࡞͍ͯ͠Δ͕ɼࠓ‫ޙ‬͸఍߅‫΁ث‬ͷରԠɼ఍߅஋ͷࢉग़ͳͲ͕ߦ͑ΔΑ͏ʹ͍ͨ͠ͱߟ͍͑ͯΔɽ͜Ε͸
SPICE ΍ Virtual BreadBoard ͳͲͷ֎෦ιϑτ΢ΣΞͱͷ࿈ಈʹΑΓ࣮૷Ͱ͖Δͱߟ͑Δɽ
վྑ༧ఆͱͯ͠ɼ2 ͭͷૉࢠΛબͿͱૉࢠಉ࢜ͷཧ૝తͱࢥΘΕΔ഑ઢΛ͢Δ޷ҙతղऍ‫ػ‬ೳͷ࣮૷͕͋Δɽ೚ҙͷ 2 ͭͷૉࢠʹ͍ͭͯɼ഑ઢํ๏ͷςϯϓϨʔτΛࣄલʹ༻ҙ͓ͯ͘͜͠ͱͰɼϢʔβ͕େࡶ೺ͳ഑ઢΛߦ͑ΔΑ͏ʹͰ͖Δͱߟ͍͑ͯΔɽ
‫Ͱ఺࣌ݱ‬ఏҊγεςϜ͕ରԠ͢Δૉࢠ΍‫ػ‬ೳ͸·ͩ‫ݶ‬ΒΕ͍ͯΔɽ͔͠͠ɼͦͷԠ༻Մೳੑ΍ɼ࣮ࡏ෦඼ͱԾ૝෦඼Λࠞࡏͤͨ͞ిࢠ޻࡞ͷੈքʹ͍ͭͯ͸ɼຊϫʔΫγϣοϓͰେ͍ʹٞ࿦͢ΔՁ஋͋Δ΋ͷͩͱߟ͍͑ͯΔɽࢀߟจ‫ݙ‬[1] མ߹ཅҰɽʮి‫͕ؾ‬Έ͑ΔʯσόΠε Visible Breadboard, ೔ຊόʔνϟϧϦΞϦςΟֶձ࿦จࢽ,Vol.15, No.3, pp.463-466, 2010.
[2] Frank Uhling. react3D Electric - Tangible User
Interface. http://www.youtube.com/watch?v=
6qTTQKWfV8Q

ਤ 3: ະ։෧ͷ 7 ηά LED ͱϚτϦΫε LED ΁ͷϓϩδΣΫγϣϯϚοϐϯά

3ؔ࿈‫ڀݚ‬

ϑΟδΧϧίϯϐϡʔςΟϯάΛ༰қʹ͢ΔΞϓϩʔνͱͯ͠ PhidgetsɼArduinoɼGainer ͱ͍ͬ- 142 -

[3] ‫ٶ‬Լ๕໌ɽϑΟδΧϧίϯϐϡʔςΟϯά΁ͷϞ
νϕʔγϣϯΛ޲্ͤ͞ΔϒϨουϘʔυɼՆͷϓϩάϥϛϯάɾγϯϙδ΢Ϝใࠂूɼpp.1-4ɼ
2010ɽ

WISS2013

VisualMimic: εΫϦʔϯγϣοτΛར༻ͨ͠ GUI ૢ࡞ࣗಈԽͷͨΊͷϏδϡΞϧ։ൃ‫ڥ؀‬
ਂງ ޸໌

ࡔຊ େհ

‫ेޒ‬ཛྷ ݈෉ ∗֓ཁ. ຊߘͰ͸ɼϚ΢εૢ࡞΍Ωʔૢ࡞ͱ͍ͬͨΠϯλϥΫςΟϒͳΞϓϦέʔγϣϯʹର͢Δૢ࡞ΛࣗಈԽ͢ΔͨΊͷεΫϦϓτ։ൃ‫ ڥ؀‬Visual Mimic ΛఏҊ͢ΔɽຊγεςϜͰ͸ɼϢʔβ͸ૢ࡞͍ͨ͠ GUI
ཁૉΛεΫϦʔϯγϣοτը૾Ͱࢦఆ͢Δ͜ͱͰɼಛఆͷ API ʹґଘ͠ͳ͍ GUI ૢ࡞Λ‫ه‬ड़Ͱ͖Δɽ۩ମతʹ͸ɼϢʔβ͸·ͣࣗಈԽ͍ͨ͠ GUI ૢ࡞ΛྫࣔʹΑΓ‫ه‬ड़͢Δɽͦͷ‫ޙ‬ɼੜ੒͞ΕͨεΫϦϓτ͸ά
ϥϑϕʔεͷϏδϡΞϧΤσΟλ্ʹදࣔ͞ΕɼϢʔβ͸υϥοάˍυϩοϓͰεΫϦϓτΛฤू͢Δɽ݁
Ռͱͯ͠ɼϢʔβ͸ैདྷͷ։ൃ‫ʹڥ؀‬ൺ΂ͯগͳ͍࿑ྗͰ GUI ૢ࡞ΛࣗಈԽ͢Δ͜ͱ͕ՄೳʹͳΔɽ

1

͸͡Ίʹ

GUI ΞϓϦέʔγϣϯ΍ PC ήʔϜͷΑ͏ͳΠϯλϥΫςΟϒͳΞϓϦέʔγϣϯ͸ɼϢʔβ͕Ϛ΢εૢ࡞΍Ωʔૢ࡞ͱ͍ͬͨ GUI ૢ࡞Λߦ͏͜ͱͰಈ
࡞͢ΔɽͦͷͨΊɼGUI ΞϓϦέʔγϣϯͷಈ࡞ς
ετ΍ɼRPG ήʔϜʹ͓͚ΔΩϟϥΫλͷϨϕϧ
্͛ͱ͍ͬͨ୯ௐͳ࡞‫ۀ‬Λߦ͏৔߹Ͱ΋ɼৗʹϢʔβ͕ύιίϯΛૢ࡞͚ͭͮ͠Δඞཁ͕͋ΓɼϢʔβʹେ͖ͳෛ୲͕͔͔ͬͯ͠·͏ɻAutomator [1] ͷΑ͏ͳ GUI ૢ࡞ΛࣗಈԽ͢ΔͨΊͷπʔϧ΋͋Δ
͕ɼઐ༻ͷ API Λར༻֤ͯ͠ΞϓϦέʔγϣϯͷΠ
ϯλϑΣʔεΛૢ࡞͢Δ͜ͱͰ࣮‫͓ͯ͠ݱ‬ΓɼFlashήʔϜ಺ͷϘλϯͷΑ͏ͳɼϢʔβ͕ಠࣗʹ࡞੒ͨ͠ GUI ཁૉ΁ͷૢ࡞͸‫ه‬ड़Ͱ͖ͳ͍ɽ
ҰํɼSikuli [2] ͱ͍͏ GUI ૢ࡞ͷࣗಈԽπʔϧͰ͸ɼૢ࡞͍ͨ͠ GUI ཁૉΛͦͷεΫϦʔϯγϣοτը૾Ͱࢦఆ͢ΔɽγεςϜ͸ࢦఆ͞Εͨը૾ΛσεΫτοϓը໘͔Β୳͠ɼϚονͨ͠ྖҬʹରͯ͠GUI ૢ࡞Λ࣮ߦ͢Δɽ͜ͷΑ͏ʹ GUI ཁૉͷ‫ͨݟ‬໨Λར༻͢Δ͜ͱͰɼ೚ҙͷ GUI ཁૉʹର͢Δૢ࡞Λ‫ه‬ड़Ͱ͖Δɽ͔͠͠ɼSikuli Ͱ͸֤ૢ࡞ΛςΩετϕʔεͷεΫϦϓτͱͯ͠‫ه‬ड़͢Δඞཁ͕͋Γɼϓϩάϥϛϯά͕ಘҙͰͳ͍Ϣʔβʹͱͬͯෛ୲͕
େ͖͍ͱ͍͏໰୊͕͋Δɽ
ͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼSikuli ΛΤϯυϢʔβ޲͚ʹվྑͨ͠։ൃ‫ ڥ؀‬Visual Mimic ΛఏҊ͢Δʢਤ 1ʣɽϢʔβ͸·ͣɺࣗಈԽ͍ͨ͠ GUI ૢ࡞ΛྫࣔʹΑΓ‫ه‬ड़͢Δɻੜ੒͞ΕͨεΫϦϓτ͸άϥϑϕʔεͷϏδϡΞϧΤσΟλʢҎԼΩϟϯόεͱ‫Ϳݺ‬ʣʹදࣔ͞ΕɼϢʔβ͸εΫϦϓτΛυϥοάˍυϩοϓͰฤूͰ͖Δɽຊ‫ڀݚ‬ͷ࠷େͷߩ‫ݙ‬͸ɼྫࣔϓϩάϥϛϯάͱϏδϡΞϧϓϩάϥϛϯάΛ༻͍Δ͜
∗Copyright is held by the author(s).
Koumei Fukahori, Daisuke Sakamoto, Takeo Igarashi,౦‫ژ‬େֶ

- 143 -

ͱͰɼϢʔβ͕࠷খͷ࿑ྗͰ Sikuli ͱಉ༷ͳ GUIૢ࡞ͷࣗಈԽεΫϦϓτΛ࡞੒Ͱ͖ΔΑ͏ʹͨ͜͠ͱͰ͋Δɽ

ਤ 1. VisualMimic ͷΠϯλϑΣʔε2Visual MimicϢʔβ͕ਤ 1 ࠨ্ͷ࿥ըϘλϯʢ”RECORD”ʣΛԡ͢ͱɼγεςϜ͸όοΫάϥ΢ϯυͰϢʔβͷϚ΢εɾΩʔૢ࡞ͷ‫ࢹ؂‬Λ࢝ΊΔɽϢʔβ͕Ϛ΢εΧʔιϧΛಈ͔͢ͱɼγεςϜ͸‫ࡏݱ‬Ϛ΢εΧʔιϧ͕઀৮͍ͯ͠Δ GUI ཁૉΛࣗಈͰ‫ݕ‬ग़͠ɼ੺৭
ͷۣ‫Ͱܗ‬ϋΠϥΠτ͢Δʢਤ 4-a ࠨʣɽϢʔβ͕Ϛ΢εΫϦοΫΛ͢Δͱɼ‫ࡏݱ‬ϋΠϥΠτ͞Ε͍ͯΔ
GUI ཁૉΛΫϦοΫ͢Δ໋ྩ͕Ωϟϯόε্ʹ௥Ճ͞ΕΔʢਤ 4-a ӈʣɽಉ༷ʹɼϢʔβ͕จࣈྻΛλΠϓ͢ΔͱɼΩʔૢ࡞໋ྩ͕Ωϟϯόεʹ௥Ճ͞ΕΔɽ
ͳ͓ɼϚ΢εΧʔιϧ͕઀৮͍ͯ͠Δ GUI ཁૉͷ‫ݕ‬ग़ʹ͸ɼσεΫτοϓը໘ͷըૉมԽΛར༻͠
͍ͯΔɽϚ΢εΧʔιϧ͕ಈ͍ͨॠؒʹɼΧʔιϧपลͰ৭͕มԽͨ͠ྖҬΛ GUI ཁૉͱͯࣝ͠ผ͢
Δʢਤ 2ʣɽγεςϜ͕๬·͍͠ྖҬΛϋΠϥΠτ
͠ͳ͍৔߹͸ɼΧʔιϧΛେ͖͘ԁঢ়ʹಈ͔͢δΣενϟʹΑͬͯɼखಈͰྖҬΛࢦఆ͢ΔϞʔυ΁Ҡߦ͢Δ͜ͱ΋Ͱ͖Δʢਤ 3ʣɽ

WISS 20133䝪䝍䞁᫬้ t– 1 䛾䝇䜽䝸䞊䞁⏬ീSt-1

᫬้ t 䛾
䝇䜽䝸䞊䞁⏬ീStར༻ྫ

ਤ 5 ͸ VisualMimic Λ༻͍ͯ࡞੒ͨ͠εΫϦϓτͷྫͰ͋Δɽਤ 5-a ͷεΫϦϓτͰ͸ɼGoogle
Chrome ͔Β GMail Λ։͖ɼWISS ͷ౤ߘγεςϜ͔Βಧ͍ͨϝʔϧΛΞʔΧΠϒ͢Δɽ·ͨɼਤ 5-b
͸ YouTube ಈըΛϦϐʔτ࠶ੜ͢ΔεΫϦϓτͰ͋Γɼಈըͷ࠶ੜ͕ऴΘΔͨͼʹϦϓϨΠϙλϯΛ
ࣗಈͰΫϦοΫ͢Δɽ͜ΕΒͷεΫϦϓτͰ͸ॲཧͷྲྀΕ͕໼ҹͰදࣔ͞Ε͓ͯΓɼςΩετϕʔεͷεΫϦϓτͱൺ΂ͯεΫϦϓτͷߏ଄͕ཧղ͠΍͘͢ͳ͍ͬͯΔɽ·ͨɼSikuli ͷΑ͏ʹϢʔβ͕ιʔείʔυΛॻ͘ඞཁ͕ͳ͘ɼൺֱతগͳ͍ख਺ͰεΫϦϓτΛ‫ه‬ड़Ͱ͖Δɽྫ͑͹ɼਤ 5-b ͷεΫϦϓ
τ͸ 6 ճͷϚ΢εΫϦοΫ͚ͩͰ࡞੒Ͱ͖ͨɽ

St-1, St 䛾ᕪศ⏬ീ

ਤ 2. GUI ཁૉͷࣗಈ‫ݕ‬ग़ΞϧΰϦζϜ

ਤ 3. ϋΠϥΠτྖҬͷखಈࢦఆྫࣔʹΑΓ‫ه‬ड़͞ΕͨεΫϦϓτ͸Ωϟϯόε্ʹάϥϑϕʔεͷϏδϡΞϧ‫ͯ͠ͱޠݴ‬දࣔ͞ΕΔɽ֤ϊʔυ͸ͻͱͭͷ GUI ૢ࡞ɼΤοδ͸εΫϦϓ
τͷॲཧͷྲྀΕΛද͢ɽϢʔβ͸೚ҙͷϊʔυ͔ΒεΫϦϓτͷ࣮ߦΛ։࢝Ͱ͖ɼγεςϜ͸Τοδʹ
ͦͬͯϊʔυΛͨͲΓɼରԠ͢Δ GUI ૢ࡞Λॱ࣍
࣮ߦ͢Δɽྫ͑͹ɼਤ 4-b ͷҰ൪্ͷϊʔυ͕࣮ߦ͞ΕΔͱɼγεςϜ͸·ͣσεΫτοϓը໘͔ΒϘλϯ̍ͷը૾Λ୳͠ɼϚονͨ͠ྖҬͷதԝʹϚ΢εΧʔιϧΛಈ͔͠ɼࠨΫϦοΫΛߦ͏ɽը૾Ϛονϯάʹ͸ OpenCV ͷ cvMatchTemplate() ؔ਺Λར༻͓ͯ͠Γɼࢦఆը૾ͱͷϚον཰͕ 80 ˋΛ௒͑ͨྖҬʹର֤ͯ͠ૢ࡞Λߦ͏ɽϢʔβ͸ϊʔυؒʹΤοδΛ௥Ճɾ࡟আ͢Δ͜ͱ
ͰεΫϦϓτͷॲཧͷྲྀΕΛฤूͰ͖Δʢਤ 4-bʣɽࢬ෼͔ΕΛ࡞ͬͨ৔߹ɼ‫ߦ࣮ࡏݱ‬Մೳͳ GUI ૢ࡞ͷํ΁ॲཧ͕ਐΉɽྫ͑͹ɼϘλϯ 1 ͷΫϦοΫૢ࡞͕ऴΘͬͨΒɼγεςϜ͸σεΫτοϓը໘͔ΒνΣοΫϘοΫεΛ୳͠ɼνΣοΫ͕͍͍ͭͯΔ৔߹͸ࠨଆͷϊʔυʹɼ͍͍ͭͯͳ͍৔߹͸ӈଆͷϊʔυʹॲཧ͕ਐΉɽ·ͨɼ‫ޙ‬ୀลΛՃ͑Δ͜ͱͰॲཧ
Λϧʔϓͤ͞Δ͜ͱ͕Ͱ͖Δɽ
ᯞศ䛛䜜

ᕥ䜽䝸䝑䜽
䝗䝷䝑䜾䛷
䜶䝑䝆㏣ຍ
ᚋ㏥㎶

(a) ౛♧䛻䜘䜛GUI᧯స䛾グ㏙(a) ≉ᐃ䛾ᕪฟே䛾䝯䞊䝹䜢䜰䞊䜹䜲䝤(b) YouTubeື⏬䛾䝸䝢䞊䝖෌⏕ਤ 5. VisualMimic Ͱ࡞੒ͨ͠εΫϦϓτͷྫ4ࠓ‫ޙ‬ͷ՝୊

‫ݱ‬ঢ়ɼຊγεςϜ͸ม਺Λѻ͏࢓૊ΈΛ༻ҙ͓ͯ͠ΒͣνϡʔϦϯά‫׬‬શͰͳ͍ɽ͕ͨͬͯ͠ࠓ‫ޙ‬͸ɼม਺Λѻ͏ͨΊͷΠϯλϑΣʔεΛΩϟϯόε্ʹ
࣮૷͢Δ༧ఆͰ͋ΔɽͦΕʹ൐ͬͯ for จ΍ if จͱ͍ͬͨߏจΛΩϟϯόε্Ͱ‫ه‬ड़Ͱ͖ΔΑ͏ʹ͢Δ͜ͱͰɼຊγεςϜͷߴ‫ػ‬ೳԽΛਐΊΔɽ
·ͨɼຊγεςϜͷ GUI ཁૉͷ‫ݕ‬ग़ख๏͸‫׬‬શͰ͸ͳ͍ɽ‫ࡏݱ‬ͷ࣮૷Ͱ͸ɼσεΫτοϓը໘ͷ৭มԽΛར༻ͯ͠ GUI ཁૉΛࣝผ͢ΔͨΊɼGUI ཁૉ͕৭มԽ͠ͳ͍৔߹΍ɼΧʔιϧ͕ಈ͍ͨॠؒʹGUI ཁૉͰͳ͍ΦϒδΣΫτ͕ͨ·ͨ·৭มԽͨ͠
৔߹ɼຊख๏͸ਖ਼͘͠ಈ࡞͠ͳ͍ɽࠓ‫ޙ‬͸୯७ͳ৭มԽ͚ͩͰ͸ͳ͘ɼଞͷσεΫτοϓը໘ͷը૾ಛ௃ྔ΋ར༻ͨ͠ GUI ཁૉͷ‫ݕ‬ग़ख๏ʹ͍ͭͯ‫ݕ‬౼͍͖͍ͯͨ͠ɽ

ࢀߟจ‫ݙ‬(b) 䜻䝱䞁䝞䝇ୖ䛷䛾䝇䜽䝸䝥䝖⦅㞟

[1] Automator. http://support.apple.com/kb/HT2488.
[2] T. Yeh, T.-H. Chang, and R. C. Miller. Sikuli:
using GUI screenshots for search and automation.
In Proc. UIST ’09, pp. 183–192, 2009.

ਤ 4. VisualMimic ্ͰͷεΫϦϓτͷ࡞੒- 144 -WISS2013

災害対策本部における記録・文書管理システムの提案
仙道 航 ∗ 瀬川 典久

澤本 潤

杉野 栄二 † 秋冨 慎司 ‡概要. 2011 年 3 月に日本で発生した東日本大震災から約 2 年半が経過した。現在、日本では東日本大震
災を受けて、将来に起こる災害に備えた検証を行うことが一つの課題となっている。東日本大震災のような大規模災害が発生した際に、様々な会議や組織が立ちあげられる。その中の一つに災害対応の要として運営される災害対策本部という組織がある。現在、災害対策本部では災害対応のための情報の集約は電話・無線通信・FAX、情報の共有はホワイトボードや展示用パネルへの紙文書の貼り付けによって行われている。
災害対策本部では発災初動期から職員が息つく暇なく働いているため、紙ベースでの情報の記録をリアル
タイムでデジタルに起こすことは難しい。我々は、災害対応中の記録が困難であるために検証のための記録が不足しているという問題を解決するために災害対策本部のための文書管理・追跡システムを開発した。

1

はじめに

現在、日本では東日本大震災での教訓を活かし将来に起こる災害に備えるための検証を行うことが一つの課題となっている。特に災害対応の要となる災害対策本部における意思決定や行動プロセス、運営に関する検証は将来に起こる災害のための検証として非常に重要なミッションであると考える。
現在、災害対策本部に関する検証を行っていくにあたって、議事録が未作成であったことが話題となっている [1]。このように、記録が不足している状況では、災害対策本部の指揮や下した命令が当時どのような情報を基に決定したのかが分からない。この問題に対し、当時の職員の振り返りによる議事録の作成を行っているが、人間の記憶に頼る物であり信頼性には欠ける。
災害対策本部における記録作業の障害の一つとして、発災初期（発災から 72 時間）の災害対応業務が非常に多いことが挙げられる。主な業務としては情報の集約と共有、関係機関との連携、集約した情報を基にした指揮と命令を下すことである。情報の集約は紙文書による FAX での送受信、共有は紙文書をホワイトボードやパネルに貼り付けることによって全体に共有したとすることが多い。災害対策本部
で作成される紙文書や関係機関から集約される紙文書には災害対応のための判断に必要な被災状況に関する情報や、各機関の人員や災害対応に関する情報などが含まれる。
これらは、災害対策本部や関係機関の指揮命令に関わる判断材料としてだけでなく、当時得られた情報による状況判断が正しかったのかどうか、将来起こる災害に向けて検証を行っていくための重要な材
Copyright is held by the author(s).
岩手県立大学大学院 ソフトウェア情報学研究科†
岩手県立大学 ソフトウェア情報学部‡
岩手医科大学∗- 145 -料である。
しかし、災害対応に追われながら災害対策本部に集約された紙文書の変遷を記録することや作成した紙文書がどこまで伝わったかを全て記録することは困難である。また、紙文書は電子メールや電子的なファイルと異なり、コピー（ex. スキャナによるコピー）や送受信 (ex. FAX, 人手による配布) のロ
グが文書を作成したコンピュータ上には残らず、後日、その軌跡を追うことは難しい。
こうした問題に対し、本研究では地震や津波といった大規模災害が発生した際に立ちあげられる災害対策本部のための文書管理・追跡システム（SID）を
開発した。

2

システム概要我々が開発した SID を災害対策本部に導入することで、紙文書が誰によってどのような情報を基に作成されたのかに関してコンピュータによって記録することが可能になる。また、紙文書に対しスキャ
ナによるコピーや FAX による送信及び受信が行われても継続して追跡が可能になる。つまり、デジタ
ルだけでなくアナログなインタラクションの記録が可能になる。
SID を災害対策本部に導入した際の紙文書に関する情報の流れを図 1 に簡潔に示す。
SID では、コンピュータ上で作成された (ex. Microsoft Office Word) 文書が印刷される際、プリンタに文書データが送信される前に文書に対し特殊なマーカ（QR コード）を付加する。この QR コードには作成者の情報や作成者の所属する組織の情報、文書が作成された時刻が埋め込まれている。印刷された紙文書に関する情報は印刷時点で外部サーバもしくはローカルサーバに送信されデータベースへと登録される。これにより、マーカを識別子として文書を一意に特定することができ、作成者や場所など

WISS 2013

マーカを付与する処理やサーバへの文書情報の送信処理を行う。その後、通常どおりプリンタへと印刷指示をする。つまり、ユーザは普段通り印刷ボタンを押下しただけであるが、印刷された紙文書にはす
でにマーカが付与され、紙文書に関する情報はすでに管理されているという状態になる。
次に、ユーザは文書をコンピュータ上に保存する。
保存された際、SID では印刷された紙文書（コンピュータ上では PDF として扱っている）に関する情報を起点としてユーザが現在保存した文書（.Docx）
を探索しサーバへと文書情報を送信する。探索の際には、文書内容の比較等を行っており、簡単な版管理のための処理を行っている。
サーバへと蓄積された情報は順次データベースへと登録される。文書の詳細や関連する文書等の関係を閲覧するための Web ページはデータベースに蓄積された情報を基に、新たな文書が管理（追加）される度に自動で生成される。

図 1. 紙文書に関する情報の流れの関連する情報の紐付けを行うことができる。
紙文書の作成者が所属する災害対策本部に貼り付けられた紙文書や他の災害対策本部や関連組織に送信され貼り付けられた紙文書を補足するために、災害対策本部内に全方位カメラを設置する。この全方
位カメラによる映像から付与されたマーカの解析を行う。解析が終わるとサーバと通信を行い、紙文書
がどの災害対策本部にいつ渡ったかといったようなログをサーバへと蓄積する。また、スマートフォンなどの QR コードリーダから QR コードを読み込んだ際には、該当する紙文書に関する情報を Web ブ
ラウザ上で閲覧することができる。
このように、紙文書の作成時におけるそれに関わる情報と紙文書が共有されていくフローでの情報をそれぞれ蓄積することでこれまで困難であった記録と追跡を実現する。

3

図 2. 紙文書の作成から管理までのフロー

システム実装SID では、紙文書にマーカを付与する、サーバとク
ライアント間での各種情報のやりとり、Web ビューの開発などに主として PHP や PEAR などを用いている。
本稿では、特に SID による紙文書が作成され管理されるまでのフローについて図 2 を用いて詳しく述べる。SID を利用する災害対策本部職員（以下、ユーザ）は基本的に普段コンピュータ上で文書を作成する手順に加えて特別な操作を行うことはない。
現在、文書を作成するためのアプリケーションとして MicroSoft Word for Mac 2011（以下、Word）
をターゲットにしているため、Word を例として作成フローの一例について述べる。
ユーザは Word を使用し、文書を作成するとホワイトボード等へ貼り付けるための共有などを行う
ため印刷ボタンを押下する。SID ではこの際、文書データを直接プリンタへは送らずに一度 PDF として
SID のワーキングディレクトリへと保存する。PDFには作成者やホスト、タイムスタンプを埋め込んだ- 146 -4

おわりに

本稿では、災害対策本部における災害対応中の記録が難しいという問題に対し、紙文書にマーカを付与することによる記録・文書管理システムの提案を行った。
今後は、ユーザビリティを損なわない範囲での機能拡張とエラーハンドリングの強化を行う予定である。また、現在使用しているマーカは近距離用に使われるマーカであるため、今後長距離用のマーカの利用もしくは新規に開発のいずれかも行う予定である。

参考文献[1] http://www.nikkei.com/article/
DGXNASFS2700A_X20C12A1MM0000/?dg=1，
震災 10 会議で議事録なし ずさんな文書管理，
2012/1/27，日本経済新聞

WISS2013

誰でも神プレイできるシューティングゲーム!
簗瀬 洋平 ∗!

概要. 本稿では，人間の感じる難易度と，実際のゲームの難易度の間には差がある事に着目し，実際の難易度に大きく影響しないやり方で見た目の難易度だけを変化させる2Dシューティングゲームのシ
ステムを提案する．多くの人間は，ゲームを遊ぶ際に格好良いプレイをしたいと考えるものである．
ゲームプレイの中でピンチを乗り切った際，あるいは自分が理想とする鮮やかな動きが出来た時，人はそこに喜びと達成感を感じ，ゲームを継続し，プレイに習熟していくための動機が得られる．しかし，この格好良い，うまくプレイ出来たという感覚は個人の能力や経験によって大きく異なる．そのため，上級者をターゲットにして難易度の調整を行えば初級者には難しすぎ，初級者をターゲットにすると上級者にはつまらないという状態になりがちである．このシステムを使用する事で，見た目の難易度を変えずに初級者と上級者，両方に対応する事が可能となる．

はじめに

1

過去，傑作と言われるゲームの中にはゼビウ
ス[1]，スターソルジャー[2]など多くの２Dシューティングゲームが含まれている．2Dシューティ
ングゲームは得点という一意の要素によって優劣が競われる点，画面上に存在する敵機の数，
敵弾の数によってその難易度を客観的に見て取れる点などにより，プレイヤーの上手下手を見極めやすいゲームジャンルとなっており，シュー
ティングゲームがうまいプレイヤーはゲームがうまいプレイヤーとして尊敬を勝ち得る事が出来た．
近年の2Dシューティングゲームにおいては，
画面中に敵弾が放出され，それを紙一重で避けながらプレイを続ける様はWeb上の動画投稿や実況などで多くの視聴者を魅了するようになったものの，内容は高難易度化の一途を辿り，初心者のプレイヤーが気軽に挑戦してもすぐにゲー
ムオーバーとなってしまうため，新規参入者が得られにくい．
そこで筆者は初心者でも上級者の様に多くの敵弾を避けながらプレイ出来るゲームシステムを考案し，デモ作成を行った．

!

2

2.1

ゲーム概要

ゲームデザイン

本稿のために作成したデモは，2Dシューティ
ングと呼ばれるゲームジャンルの作品である．
プレイヤーは立方体の自機を操作し，画面上に出現するカプセルを取る事で加点される．
カプセルを取るごとに画面上に出現する敵機の数が増え，出現した敵機は自機に向かって弾丸を発射する．この弾丸に自機が接触すると，
Copyright is held by the author.

* Yohei Yanase, Unity Technologies Japan- 147 -

自機は爆発し，ゲームオーバーとなる．ゲーム
オーバーとなるまでの間にどれだけの得点を取るかによって，成績の優劣を競う．

!!
!! 得点
敵機
!!
!!
敵弾
!! 自機
カプセル
!!
!!
!なお，一般的には上下左右に動け，自機から弾
図 1. ゲーム画面を発射して敵機を倒すデザインの2Dシューティ
ングゲームの方が多い．本稿においては，PCでゲームをプレイする場合，上下の操作を入れるとキー配置の問題で初級者の操作難易度が上がってしまう点と，敵を倒すという要素を入れる事
でプレイヤーの上手下手が判別しにくくなる点を考慮してこのような構成にしている．

!2.2 ゲームシステム

敵機は自機が画面下方より出現し，わずかでもキーを入れた瞬間から出現するようになる．
最初は1機のみ出現するが，カプセルを取得するごとに1機ずつ同時出現数が増えていく．
画面上方のランダムな位置に生成され，画面の左右，出現位置と反対の方向に向かって移動WISS 2013

プレイヤーに向かって飛んでくるという構成であり，特にタイプ2のような偏差射撃が行われる事は非常に稀であるため，上級者でも比較的早くゲームオーバーになってしまう．
次に，初級者にほとんどがタイプ3で時々タ
イプ1や2が混じった弾を撃つ設定でゲームをプレイしてもらう．先の上級者のプレイを見ていると，ゲームが難しいという印象を受けるが，実際にはさほど難しいものではないため，順調に得点を重ね，上級者の得点を超える事も容易となる．しかし，プレイしている本人，それを見ている先のプレイヤー共にゲームそのものは同じに見えているため，何故そうなるのか疑問を抱く事になる．

を開始する．敵機は画面から消える前に一発だ
け弾をプレイヤー方向に向かって発射する．
敵機が発射する弾は発射時点の自機の位置に向
かって移動するタイプ1 ，自機の加速と移動方向を加味しそのままのキー操作を続けたら必ず当たるタイプ２，発射時点での加速速度の状態からは絶対に当たらない境界手前に撃つタイプ
３の３種類である．
タイプ1の弾はプレイヤーを移動を移動させる消極的な動機として作用するが，このタイプの弾は一方向に移動し続ければ画面端での折り返し以外で接触する事がないため，避けるのが容易である．そこで，タイプ2の弾を使う意味が出て来る．タイプ2の弾は移動方向の先に向かって発射されるため，プレイヤーはその弾との接触位置を見極め，移動を中断する必要があ
る．タイプ1と2を混在させる事により，プレイ
ヤーは移動と停止のどちらが適切かを判断し，ゲームプレイを行う必要が出て来る．
タイプ3の弾はどれだけ数が増えても難易度にはほとんど影響しない．よって，タイプ3の弾のみを増やしていく事により，実質の難易度を変えずに見た目の難易度を上げていく事が出
来る．

３

!

4

問題点と今後の展望

本デモは現状実験を十分に行っていないた
め，タイプ1とタイプ2の弾の割合の変化による客観的，主観的な難易度の変化について定量的なデータを持っていない．また，一般的な2D
シューティングゲームのように上下左右に動け，敵を撃って倒せるようにした場合どのような変化があるのかという点についても予測がついていない．まずは本デモについての検証実験を行い，より実践的なゲームに活かせるよう知見を深めていくものとして位置づけている．

デモの流れ

デモにおいては，まず体験者のゲームの習熟度について質問をする．この際，上級者と初級者が混じった集団であるとより効果的である．
まず，上級者に対してはタイプ1と2のみが発射され，得点の増加と共に敵機の数が増え，難易度が上昇していくゲームを遊んでもらう．多くのシューティングゲームでは，弾はプレイヤーの動きとは無関係に発射され，少数の弾だけが

参考文献[1] NAMCO. XEBIOUS, 1983
[2] Hudson Soft. Star Soldier, 1986

未来ビジョン

例も散見されるが，実際の制作過程で使れているが，その多くは膨大なシステムのを明らかにしていく事で，最低限の面白

ゲーム制作には様々なHCI的知見が使わ中に埋もれており，ごく自然なゲーム体験の一部として受け入れられているためユー
ザーはもちろんゲームを研究している人間にすら知られていない．本研究はそれらを解き明かし，知見として共有するための一助とするべく行われている．
また，ゲームシステムや要素の提案を研究者が行う際，そのゲームが十分に良く出来ていない事により，本業の開発者に響かない，見向きもされないという事われている様々な技術や必須の要素などさを備えたデモの展示を実現し，デジタ
ルゲームにおける産学の連携をより推進していきたいという思いもある．
本研究で作成したUnityプロジェクトは今後のゲームあるいはゲームの要素を研究していく方々が利用出来るよう，誰でもダウンロード出来るよう公開し，研究目的でも改変，再配布などを可能とする予定である．

- 148 -WISS2013

叩打音を利用した操作インタフェースと浴槽への適用
伊藤 大毅∗

平井 重行†

概要. 手指で「叩く」操作を元にしたインタラクションを浴槽に適用し，その叩打位置（叩く場所）や叩
打音色（叩き方），叩打パターン（叩くリズム）の組み合わせに対応した操作を実現するシステムを提案する．それらの方法により，様々な機器やシステムの操作を行うほか，叩くこと自体をエンタテインメントとすることまでを考えている．本稿では主に叩打位置の検出処理について述べる．

1

はじめに

日常生活において快適さの追求だけでなく，エンタテインメント要素まで含めた QoL(Quality ofLife) 向上を目指した住環境の研究が行われている．
我々はこれまで，住環境の中でも特に水場である浴室での操作インタフェースと応用システムの研究を行ってきた．静電容量方式タッチセンサを浴槽裏側に設置して「触れる」インタフェースを構成する
TubTouch[1] では，給湯器や照明などの機器，音楽
プレーヤアプリの操作を浴槽縁で行うシステムを実現している．また，Bathcratch[2] では，浴槽裏側に設置したピエゾセンサで浴槽のこする音を検出することにより「こする」インタフェースを構成し，DJ スクラッチ演奏を行うアプリケーションを実現している．
本研究では，これらの操作に加え，浴槽を「叩く」ことによる操作インタフェースを提案する．ここでは，叩打位置（叩いた場所）と叩打音色（叩き方），
さらに叩打パターン（叩くリズム）を利用し，浴室
内の様々な機器やシステムの操作，さらに新たなア
プリケーションの実現を含めて，日常生活環境に埋め込まれた入力インタフェースの活用を目指す．

2

システム概要2.1

システム構成日本国内で一般に普及しているシステムバスの浴槽において，その縁の裏側にピエゾセンサを取り付
け，浴槽縁の叩打を元に様々な入力手法を実現する．
浴槽叩打音を浴槽の個体振動としてピエゾセンサで直接計測し，その音響信号をリアルタイム処理することで操作イベントを出力するシステム構成とする（図 1）．ここでは，叩打音の音響信号に対し，「叩打位置」の検出処理（複数のセンサの信号を利用），「叩打音色」の認識処理を行い，それぞれの情報に基づいて叩打パターンの認識処理を行う．以下，本Copyright is held by the author(s).
京都産業大学大学院 先端情報学研究科†
京都産業大学 コンピュータ理工学部∗- 149 -

図 1. 浴槽インタラクションシステム構成

稿においては主に「叩打位置」検出について述べる．

2.2

叩打位置検出手法

本システムでは浴槽裏側に設置したピエゾセンサ
によって叩打位置検出を行う．位置検出の仕組みとしては，センサ数の増加に伴う設置困難さと計算負荷の増加を考慮して，なるべく少ないセンサ数で実現できる方が良いと考える．このことから，ピエゾ
センサを多数連続的に並べるのではなく，一定距離で離して数個設置し，叩いた振動がセンサに伝搬するまでの時間差を利用して叩打位置を算出する方法[3] をとることにする．

2.3

初動検出処理時間差による位置検出を実現するためには，叩打による振動がセンサへ到達する時間を正確に求める必要がある．そのため，適切な閾値を設定して叩打音の振幅がそれを超えた時刻を初動（振動の到達時刻）として検出する．ただ，閾値によってはわずかな叩き方の違いで振幅の変化の仕方が著しく変わり，
検出時刻のばらつきが大きくなり十分な検出精度が得られない．そこでなるべく適切な処理を行うため，二乗平均平方根（RMS）により積分し，波形の時間変化をある程度平滑化して閾値処理する手法を用いる．これにより振動が増加し始める瞬間のみを的確に検出できる．

WISS 2013

5

叩打音伝搬時間
標準偏差
回帰直線
伝搬時間の範囲

図 2. 各叩打位置の伝搬時間の標準偏差と回帰直線

3

叩打音位置検出のための振動解析

叩打音の初動を検出する適切な閾値は未知であり，
ピエゾセンサの設置方法によってもかなり変化することが想定できる．また RMS 処理の際，波形を切りだす矩形窓の時間長も未知である．これら閾値とRMS 窓幅の長さの適切な値は，予め収録した叩打音
データを解析することで求めた．具体的には，浴槽を複数回叩打した音データを用意し，閾値と RMS 窓
幅を変化させながら，初動検出処理によって叩打位
置からセンサに振動が伝搬するまでの時間を求める．
この伝播時間の標準偏差が最小となる閾値と RMS
窓幅の値を適切な値とする．図 2 は，FRP の浴槽を指先で叩打した際の叩打音から求めた閾値と RMS
窓幅での各叩打位置の振動伝搬時間をプロットしたものである．この図は，叩打位置がセンサから 100〜300mm 離れた位置ならば伝搬時間が重複しておらず，その範囲までなら叩打位置が判別出来ることを示している．この結果から，適切な閾値，RMS 窓
幅，位置検出可能な距離の範囲（必要なセンサ数）を求められる．この解析手法と結果の利用は，新たに適用する浴槽環境に対するキャリブレーション手法として利用できる．

4

叩打音を利用するアプリケーション

本システムの応用例として，叩打位置と叩打音色に対応したサウンドを鳴らすエンタテインメントシ
ステム”BathDrum”を提案して実装している [4]．この BathDrum は現時点では叩打位置に合わせて単に音を鳴らすだけであるが，TubTouch や Bathcratchと同様に，浴室の天井裏設置のプロジェクタで浴槽
縁へ画面投影することで，より様々な応用や楽しみ方も実現できると言える．例えば，もぐらたたきゲー
ム，音楽に合わせて浴槽を叩くリズムゲームの表示などが考えられ，これに叩打音色や叩打パターンの認識も含めた処理を考えると応用も拡がる．また，
TubTouch システムではメニュー表示の On/Off を切り替える操作について，浴槽の特定位置を 2 度タップすることでユーザが明示的に操作するなど，他の操作手法と組み合わせる効果的な利用方法も考えられる．

- 150 -

おわりに

本論文では，浴槽を「叩く」インタフェースを提案し，そのシステム概要と叩打位置検出処理について述べた．現状では指先での叩打にのみ対応した処理であるため，手のひらや拳での叩打に対応させる予定である．また，検出精度向上のために周波数解
析や機械学習などの処理も検討し，処理の反応時間も調査する必要がある．そして，それらは叩打音色に関する処理も合わせて行うことを検討していく．
叩打音色の区別については，Lopes らのシステム [5]や Harrison らのシステム [6] で実装されているが，それらは多少のタイムラグが発生する手法のため瞬時の反応を必要とする処理にはあまり向いていない，
一方で PosessingDrums[7] ではリアルタイムの叩打
音色の変換を行っており，BathDrum のような瞬時の反応を必要とするシステムに応用できると考えている．それらの叩打音色の処理に加え，叩打パター
ン認識処理も合わせて応用できるようにしていく予
定である．

謝辞
本研究の一部は，中山隼雄科学技術文化財団の研究助成によって行われました．

参考文献[1] 榊原吉伸, 林宏憲, 平井重行,TubTouch: 湯水の影
響や自由 形状への適用を考慮した浴槽タッチ UI
環境, 情報処理学会論文誌 Vol.53, No.4, 2013.
[2] Shigeyuki Hirai, Yoshinobu Sakakibara and Seiho
Hayakawa. Bathcratch: Touch and Sound-Based
DJ Controller Implemented on a Bathtub, Proc.
of ACE2012, pp.44-56, 2012.
[3] Joseph A. Paradiso, Che King Leo, Nisha Checka,
Kaijen Hsiao. Passive acoustic sensing for tracking knocks atop large interactive display, Proc. ofthe 2002 IEEE International Conference on Sensors, pp.512-527, 2002.
[4] 伊藤大毅, 平井重行: 浴槽叩打音を利用したお風呂
ドラム BathDrum の叩打位置検出, 情処研究報告2013-EC-29-1, 2013.
[5] Pedro Lopes, Ricardo Jota, Joaquim A. Jorge.
Augmenting touch interaction through acoustic
sensing, Proc. of ITS2011, pp.53-56, 2011.
[6] Chris Harrison, Julia Schwarz and Scott E. Hudson. TapSense: Enhancing Finger Interaction on
Touch Surfaces. Proc. of UIST 11, pp.627-636,
2011.
[7] Kazuhiko Yamamoto. Possessing Drums: An Interface of Musical Instruments that Assigns Arbitrary Timbres to Personal Belongings, Journalof Information Processing, Vol.21, No.2, pp.274282, 2013.

WISS2013

住宅内の機器・サービスを統合するためのビジュアルプログラミング環境
橋岡 良∗

平井 重行†

概要. 家電や様々なセンサ，インターネットサービス（天気予報やニュース，SNS など），コンテンツまでを様々に組み合わせて統合的に連携・動作させることを目的とした機器やサービスが次々に登場し，住宅のスマートハウス化を進めている．本研究は，その流れにおいてエンドユーザが様々な機器やサービスをより柔軟で自由に組み合わせられるようにすべく，直感的でわかりやすい操作を実現するビジュアルプログラ
ミング環境を開発し，その内部処理を行うためのシステムも構築している．本稿では，そのシステム概要とビジュアルプログラミング環境について述べる．

1

はじめに

家電機器を中心に複数の機器を連携させるような統合制御を行うためのプログラミング手法およびそのユーザインタフェースの研究がある [1][2][3]．最近
では，エンドユーザが住宅内で扱う機器はセンサ類を含んだ家電や住宅設備に留まらず，スマートフォンの普及に伴って様々なインターネットサービス (例えばニュースや天気予報，SNS など) までもが操作対象となりつつあり，幅広い統合や柔軟な連携を実現する必要が出てきている．一方で，現時点で住宅内の家電製品などはあまり対象でないが，ネットワーク上のサービス同士やガジェットなどとの連携をルール記述の形式でエンドユーザが作成し，ある種のプログラミングが行える IFTTT1 や Zapier2 といったサービスがインターネット上で提供されるに至っている．本研究は，このサービスや機器を連携させて住宅のスマート化を進めるサービスに対し，
エンドユーザがより自由自在に動作を設定・連携させることができるビジュアルプログラミング環境とその動作を支えるシステムの開発を行っている．以下，本稿ではそのシステム概要と，ビジュアルプロ
グラミング環境について述べ，どのようなプログラ
ムが作成可能か例を挙げながら説明する．

2

ドユーザは PC やスマートフォン，タブレット機器などの端末を用いて，機器やサービスの連携をデー
タフロー型のビジュアルプログラミング環境でプログラムを作成し，そのプログラムは XML もしく
は JSON 形式で WebSocket を介してアプリケー
ションサーバへ送信，データベースに保存される．
アプリケーションサーバ側は，機器やサービスを統合制御するプログラムが動作しており，プログラムに従って状況に応じた機器制御やサービスを連係動作させる仕組みになっている．

エアコン

情報家電

給湯暖房機

YouTube

RSS
天気

照明

TV

Twitter

ホームサーバ
学習型リモコン

ECHONET Lite

各種インターネットサービス

DLNA

アプリケーション
サーバ

住宅内の
各種センサ
プログラム

データベース

XML

プログラム
実行部
WebサーバXML WebSocket

プログラミング環境

システム概要本研究システムはエンドユーザが利用するクライ
アント端末上で動作するビジュアルプログラミング
環境と，アプリケーションサーバとで主に構成される．アプリケーションサーバは住宅内の様々な機器・センサ類，またインターネット上の様々なサービスとの間で情報のやりとりを行う (図 1 参照) ．エン

PC, タブレット, etc

図 1. システム概要図3

Copyright is held by the author(s).
∗京都産業大学大学院 先端情報学研究科†
京都産業大学 コンピュータ理工学部
1
IFTTT : https://ifttt.com/
2
Zapier : https://zapier.com/

プログラミング環境

プログラミング環境は，Max/MSP や PureData，
vvvv などのデータフロー型ビジュアルプログラミ
ング環境として構成している．現時点で実装出来ているビジュアルプログラミング環境の外観は図 2 に- 151 -WISS 2013

示す．その画面内部では，左側に機器や設備，サービスなどを表すオブジェクトが表示され，右側にプログラミングを行うプログラムフィールドがある．
ここでは，オレンジ色のオブジェクトは，温度や扉の開閉など環境情報を知らせる機能，人の行動セン
シングに基づいて動作する機能，時間に伴って処理を行う機能などがあり，総じて入力オブジェクトと呼んでいる．水色のオブジェクトは，操作する機器や情報提示出力する機器・サービスを表す出力オブジェクトを表している．

図 4 では，複数の入力オブジェクトと出力オブジェクトが接続され，複数の処理が一つにまとめられている．place オブジェクトと temperature オ
ブジェクトがそれぞれ人の検出と設定温度範囲の条
件判定を処理する入力オブジェクトである．ここでは place オブジェクトでリビングルームに人が居るか判定し，その結果に応じて接続された Music オ
ブジェクトが音楽を再生する．一方で，place オブ
ジェクトから temperature オブジェクトへ接続され，さらに AirConditioner オブジェクトへ接続された部分では，人がリビングルームにいると共に室温が 20〜40 度の範囲にある場合に冷房を ON にする，という処理を意味する．
これらエンドユーザが記述したプログラムは，プ
ログラム作成者のユーザ ID と各プログラムに割り当てられた UUID と共に XML もしくは JSON のデータとしてサーバに送信し保存される．

4

オブジェクト

プログラム
フィールド

図 2. プログラミング環境概要図

ユーザは左側のオブジェクトリストからドラッグ
アンドドロップでプログラムフィールドへオブジェ
クトを配置し，オブジェクトのアウトレット (右下)と別オブジェクトのインレット (右上) との間をパッチコード (線) で接続することでプログラムを作成する．このパッチーコード間は，基本的にトリガー情報が流れることになり，そのトリガーを発する条
件は，各オブジェクトの左下エリアに記載された内容に応じるものとなっている．各オブジェクトは図 3のようにスライドバーで条件設定を行うことができる．なお，機器やサービスがオブジェクトの設定条件に合致した状態になっている場合には，オブジェ
クトの外枠と文字が赤くなる (図 4 参照)．
次に，プログラミング環境で作成したプログラム例を図 4 に示す．

図 3. オブジェクトの条
件設定例

図 4. プログラム例- 152 -

まとめ

本研究は，スマートハウス研究の 1 つとして，家電や住宅設備などの既存機器や，様々なインターネッ
トサービスを連携，統合的に制御するシステムと，そのためのエンドユーザが用いるプログラミング環
境について扱っている．現時点は，ビジュアルプロ
グラミング環境とバックエンドでプログラムを実行するサーバが一体化した形で，実際に幾つかのセン
サや家電機器を統合制御でき，プログラミングも実際に行える状況にある．今後は，プログラムをサーバ側で行えるようにする．また，プログラミング環
境については，操作方法や見た目のデザインについて改良を加えて，よりユーザが理解，操作しやすい形にし，PC だけでなくタブレット端末やスマートフォンでもプログラミングが行えるものにしていく予定である．

参考文献[1] Masui Toshiyuki, Itiro Siio. Real-world graphical user interfaces. In Handheld and Ubiquitous
Computing. Springer Berlin Heidelberg pp72-84,
2000.
[2] Kentaro Fukuchi, Takeo Igarashi, Maki Sugimoto, Charith Fernando, Masahiko Inami. Pushpins: Design-by-user Approach to Home Automation Programming. International Conference on Ubiquitous Computing, workshop 5,
2009.
[3] Shigeru Owada, Fumiaki Tokuhisa. Kadecot:
HTML5-based visual novels development system
for smart homes. Consumer Electronics, 2012
IEEE 1st Global Conference on, pp17-19, 2012.

WISS20131 ͭͷηϯαΛ༻͍ͨϚϧνλονδΣενϟηϯαਅು ޺޾∗
֓ཁ. 1 ͭͷηϯαΛ༻͍ͨখ‫҆Ͱܕ‬ՁͳϚϧνλονδΣενϟηϯαΛఏҊ͢Δɽ‫ݕ‬ग़ର৅δΣενϟ
͸λονͱεϫΠϓͰ͋Γɼ͞ΒʹεϫΠϓͰ͸ࢦͷຊ਺ͱํ޲Λࣝผ͢ΔɽϑΥτϦϑϨΫλΛ༻͍࣮ͨ૷Λߦ͍ɼ༗ޮੑΛ֬ೝͨ͠ɽ

1

͸͡Ίʹ

ෳ਺ͷࢦΛ༻͍Δ͜ͱͰɼೖྗͷࣗ༝౓Λ૿Ճͤ͞ɼෳࡶͳೖྗΛૉૣ͘ߦ͑ΔϚϧνλονδΣε
νϟ͸ɼ༷ʑͳσόΠε΁ͷೖྗख๏ͱͯ͠޿͘ར
༻͞Ε͍ͯΔɽλον‫ݕ‬ग़໘͕޿͍΄Ͳɼଟ͘ͷδΣενϟΛ૊ΈࠐΉ͜ͱ͕Ͱ͖Δ͕ɼ‫ݕ‬ग़໘͕খ͍͞
৔߹Ͱ͋ͬͯ΋ɼϚϧνλονδΣενϟ͸༗ޮͰ
͋Δɽྫ͑͹ɼϚϧνλονδΣενϟೖྗΛ࣮૷
ͨ͠ 1.5 Πϯν΄ͲͷσΟεϓϨΠΛඋ͑ͨԻָϓϨʔϠ΍ɼπϧͷ෦෼ͰδΣενϟΛߦ͏ϝΨω‫ܕ‬σόΠε͕͢Ͱʹࢢൢ͞Ε͍ͯΔɽ௨ৗɼଟ఺‫ݕ‬ग़Λߦ͏ͨΊʹଟ਺ͷηϯα͕ΞϨΠঢ়ʹฒ΂ΒΕ͓ͯΓɼλον‫ݕ‬ग़໘্ͷ೚ҙͷ৔ॴͰδΣενϟΛ
ߦ͑ΔΑ͏ʹͳ͍ͬͯΔɽҰํɼೖྗྖҬ͕খ͍͞΋͘͠͸ࡉ௕͍৔߹ͳͲɼδΣενϟ͕ಛఆͷ৔ॴͰߦΘΕΔ࣌ʹ͸ɼଟ਺ͷηϯα͸ඞཁͳ͍ɽຊߘ
Ͱ͸͜ͷ఺ʹண໨͠ɼ1 ͭͷηϯαͰϚϧνλον
δΣενϟΛ‫ݕ‬ग़͢Δख๏ΛఏҊ͠ɼϑΥτϦϑϨ
ΫλΛ༻͍࣮ͨ૷Λߦͬͨ݁ՌΛใࠂ͢Δɽ
ϑΥτϦϑϨΫλ͸খ‫͔҆ͭܕ‬ՁͰ͋Γೖख΋༰қͳηϯαͰ͋ΓɼͦΕΛ༻͍ͨೖྗख๏ͷ࣮૷͕਺ଟ͘ߦΘΕ͖ͯͨɽ1 ͭͷϑΥτϦϑϨΫλΛ༻͍ͨྫͱͯ͠ɼۙ઀ηϯα [2] ΍λονηϯα [4] ͱͯ͠ͷԠ༻ͳͲ͕͋Δɽ·ͨɼෳ਺ͷϑΥτϦϑϨ
ΫλΛ༻͍Δ͜ͱͰɼΑΓߴ౓ͳΠϯλϥΫγϣϯ
Λ໨ࢦͨ͠‫ڀݚ‬΋͋Δɽྫ͑͹ɼෳ਺ͷࢦΛ༻͍ͨΠϯλϥΫγϣϯ [1] ΍ɼࢦྠ‫ܕ‬σόΠε [3]ɼॊೈ
෺ମ΁ͷ઀৮‫ݕ‬ग़ [5] ͳͲ͕͋Δɽ

2

ఏҊख๏

ND filterphototransistor
photoreflector
IR LEDਤ 1. ੡࡞ͨ͠ϓϩτλΠϓɽϑΥτϦϑϨΫλͷ্໘൒෼ʹ͸ ND ϑΟϧλ͕ઃஔ͞Ε͍ͯΔɽ

‫౓ײ‬ΛεϫΠϓํ޲ʹԊͬͯมԽͤ͞Δ͜ͱͰɼ1ͭͷηϯαΛ༻͍ͨ৔߹Ͱ΋ํ޲‫ݕ‬ग़͕ՄೳͱͳΔɽఏҊख๏͸༷ʑͳηϯαʹద༻ՄೳͰ͋Δͱߟ͑ΒΕΔ͕ɼຊߘͰ͸҆ՁͰ࣮૷͕༰қͳϑΥτϦϑϨ
Ϋλ΁ͷద༻ΛࢼΈͨɽ

2.1

࣮૷

ϑΥτϦϑϨΫλͱͯ͠ɼ‫ݕ‬ग़‫ ਺͕཭ڑ‬mm ͷ
GENIXTEK TPR-105ʢ2.7 x 3.2mmʣΛ༻͍ͯϓϩτλΠϓΛ੡࡞ͨ͠ɽ‫ݕ‬ग़‫͍୹͕཭ڑ‬ηϯαΛબఆͨ͠ͷ͸ɼࢦͱࢦͱͷΘ͔ͣͳؒܺΛ‫ݕ‬ग़͢Δ
ͨΊͰ͋Δɽ·ͨɼεϫΠϓํ޲‫ݕ‬ग़Λ໨తͱͯ͠
ηϯα‫ʹ౓ײ‬มԽΛ΋ͨΒͨ͢ΊʹɼϑΥτϦϑϨ
Ϋλͷ্໘൒෼ʹ ND ϑΟϧλΛઃஔͨ͠ɽ͞Βʹͦͷ্໘ʹɼಁ໌ͷथࢷ൘ɼࢦ͢΂ΓΛ‫׈‬Β͔ʹ͢ΔͨΊͷϑΟϧϜΛష෇ͨ͠ɽϑΥτϦϑϨΫλͷ
ग़ྗ͸ΦϖΞϯϓͰ૿෯ͨ͠‫ʹޙ‬ɼ5kHz ͰαϯϓϦϯά͠ɼPC ͰॲཧΛߦͬͨɽਤ 1 ʹ੡࡞ͨ͠ϓϩτλΠϓΛࣔ͢ɽ·ͨɼηϯαग़ྗΛೝࣝ͠ɼ݁
ՌΛදࣔ͢Δ‫ػ‬ೳ΋Ճ͑ͨɽ

2.2

1 ͭͷηϯαΛ༻͍ͯɼλονͱεϫΠϓɼ͞Β࣮‫ݧ‬ϓϩτλΠϓΛ༻͍ͯɼλονɼ1/2/3 ຊࢦεϫΠϓΛߦͬͨ࣌ͷ‫ܭ‬ଌ݁ՌΛਤ 2 ʹ·ͱΊͯࣔ͢ɽλον࣌ʹ͸ൺֱత௕࣌ؒͷ൓Ԡ͕‫؍‬ଌ͞ΕΔͷʹର͠ɼεϫΠϓ࣌ʹ͸୹࣌ؒͷϐʔΫ͕ࢦͷຊ਺෼͚ͩ‫؍‬ଌ͞ΕΔɽλοϓΛߦ͏৔߹ɼࢦઌ͕ηϯαද໘ʹ઀৮ͨ͜͠ͱΛ஌֮ͨ͠‫ʹޙ‬ɼಈ࡞มߋΛߦ͏ඞཁ͕͋ΔͨΊɼࢦ͕ηϯαʹ৮Ε͍ͯΔ͕࣌ؒ
௕͘ͳΔɽҰํɼεϫΠϓΛߦ͏৔߹ʹ͸ɼҰ࿈ͷಈ࡞͸‫׈‬Β͔ʹߦΘΕΔͨΊɼࢦ͕ηϯαʹ৮ΕͯʹεϫΠϓΛߦͬͨࢦͷຊ਺ͱํ޲Λࣝผ͢Δख๏
ΛఏҊ͢ΔɽࢦͱࢦΛ‫઀͘ڧ‬৮ͤͨ͞৔߹Ͱ͋ͬͯ
΋ɼ྆ࢦͱλον‫ݕ‬ग़໘ͷؒʹ͸Θ͔ͣͳۭ͕ؒͰ
͖ΔɽͦͷؒܺΛ‫ݕ‬ग़͢Δ͜ͱ͕Ͱ͖Ε͹ɼࢦͷຊ਺Λ਺͑Δ͜ͱ͕Ͱ͖Δɽ·ͨɼ௨ৗͷํ޲‫ݕ‬ग़͸ෳ਺ͷηϯαΛ༻͍࣮ͯ૷͞ΕΔͷʹର͠ɼηϯα∗right swipe
left swipe

Copyright is held by the author(s).
NTT υίϞ ઌਐٕज़‫ॴڀݚ‬- 153 -

50ms

Elapsed timeਤ 2. ϑΥτϦϑϨΫλͷग़ྗྫɽϐʔΫͷ਺͕ࢦͷຊ਺ʹରԠ͢Δɽright swipe
left swipe

100%
90%

Slope of falling

Reaction of the photoreflector

touch
1-finger swipe
2-finger swipe
3-finger swipe

Reaction of the photoreflector

WISS 2013

10ms

right swipe with ND
left swipe with ND
right swipe without ND
left swipe without ND

10%
0%

0

Elapsed timeਤ 3. εϫΠϓํ޲ͷ‫ݕ‬ग़ɽεϫΠϓͷํ޲ʹΑΓ܏͖͕มԽ͢Δɽ͍Δ࣌ؒ͸ɼεϫΠϓͷ଎͞ʹґଘ͢Δ͜ͱʹͳΔɽͦͷͨΊɼ‫ʹ୺ۃ‬஗͍εϫΠϓΛআ͖ɼηϯαʹࢦ͕ৼΕ͍ͯΔ࣌ؒ͸εϫΠϓͷํ͕୹͘ͳΔɽ·ͨɼ‫ݕ‬ग़‫཭ڑ‬ͷ୹͍ϑΥτϦϑϨΫλΛ༻͍͍ͯΔͨΊɼࢦͱࢦͷؒʹͰ͖ΔؒܺʹΑΔ൓ࣹޫྔͷ‫ݮ‬গΛ໌֬ʹଊ͑Δ͜ͱ͕Ͱ͖͍ͯΔɽ
ਤ 3 ʹɼ1 ຊࢦͰͷӈ/ࠨεϫΠϓΛߦͬͨ࣌ͷ‫ܭ‬ଌ݁ՌΛࣔ͢ɽӈεϫΠϓ࣌ʹ͸ࠨεϫΠϓ࣌ͱൺֱͯ͠ɼ‫ٸ‬फ़ͳ্ཱ͕ͪΓͱ؇΍͔ͳཱͪԼ͕Γ͕‫؍‬ଌ͞ΕΔɽ͜ͷҧ͍͸ɼ࣍ͷΑ͏ʹੜ͡Δͱߟ͑ΒΕΔɽӈεϫΠϓΛߦ͏৔߹ɼࢦ͸ ND ϑΟϧλ͕ઃஔ͞Εͨํ޲͔Βηϯαʹ઀ۙ͢Δɽࢦ͕ ND
ϑΟϧλ্ʹ͋Δ࣌఺Ͱ͸ɼরࣹޫͱ൓ࣹޫͷ྆ํ͕‫ݮ‬ਰ͢ΔͨΊɼηϯαͷग़ྗ஋͸খ͍͞ɽ͜ͷঢ়ଶ͸͠͹Β͘ଓ͕͘ɼ͞Βʹࢦ͕ਐΉͱɼND ϑΟϧλͰ‫ݮ‬ਰ͞Εͳ͍‫͍ڧ‬রࣹޫ͕ࢦʹ͋ͨΔΑ͏ʹͳΔɽ͜ͷஈ֊Ͱɼ൓ࣹޫ΋‫ݮ‬ਰ͞Εͳ͘ͳΔͨΊɼग़ྗ஋͕େ͖͘ͳΔɽࢦ͕‫׬‬શʹϑΥτϦϑϨΫλ
Λ෴͍ͬͯΔؒɼηϯαͷग़ྗ஋͸΄΅ҰఆͱͳΔɽ͞ΒʹਐΉͱɼηϯαͷग़ྗ͸௿Լ͍͕ͯ͘͠ɼNDϑΟϧλʹΑΔޫͷ‫ݮ‬ਰ͕ͳ͍ͨΊɼࢦͱηϯαͷ‫͕͋཭ڑ‬Δఔ౓཭Εͯ΋ηϯαग़ྗ͸ߴ͘ͳΔɽ݁
Ռͱͯ͠ɼग़ྗͷ௿Լ͸؇΍͔ͳ΋ͷͱͳΔɽ
·ͨɼ1 ຊࢦʹΑΔࠨӈͷεϫΠϓΛͦΕͧΕ 50ճߦͬͨ࣌ͷɼϐʔΫͷ܏͖ͷ෼෍Λਤ 4 ʹࣔ͢ɽ্ཱ͕ͪΓ/ཱͪԼ͕Γͷ܏͖Λԣ/ॎ࣠ʹͯ͠ɼશͯ
ͷεϫΠϓΛϓϩοτͨ͠ɽͳ͓ɼϐʔΫͷ܏͖͸ɼ
ਤ 3 ʹࣔ͢Α͏ʹɼมԽྔ͕ 10-90%ͱͳΔ۠ؒʹରͯ͠ࢉग़ͨ͠ɽਤ 4 ʹ͸ɼND ϑΟϧλΛऔΓ֎ͨ࣌͠ɼͭ·ΓϑΥτϦϑϨΫλΛͦͷ··༻͍ͨ࣌ɼͷ݁Ռ΋ࣔͨ͠ɽND ϑΟϧλ͕ͳ͍৔߹Ͱ΋ɼࠨӈͷεϫΠϓؒʹΘ͔ͣͳҧ͍͕‫ݟ‬ΒΕΔ͕ɼ྆ऀΛਖ਼͘͠ೝࣝ͢Δ͜ͱ͸೉͍͠ɽҰํɼND ϑΟϧλΛઃஔͨ͠৔߹ʹ͸ɼͦͷҧ͍͕֦େ͠ɼ྆ऀ
ͷ෼෍͸໌֬ʹ෼཭͞Ε͍ͯΔɽͳ͓ɼND ϑΟϧλʹΑΓɼ൓ࣹޫྔ͕‫ݮ‬ΔͨΊɼϐʔΫ஋͕খ͘͞
ͳΓɼ܏͖΋খ͘͞ͳΔɽ·ͨɼਤதͷਫ৭ͷ࣮ઢ͸ɼ2 ͭͷ܏͖͕ಉ͡ʹͳΔ఺Λ݁ΜͰ͓ΓɼӈεϫΠϓ࣌ʹ͸্ཱ͕ͪΓͷํཱ͕ͪԼ͕ΓΑΓ΋܏͖͕େ͖͍ͱ୯७Խ͢Δ͜ͱ΋Ͱ͖Δɽ

- 154 -

3

Slope of risingਤ 4. ND ϑΟϧλͷޮՌɽద༻͢Δ
͜ͱͰํ޲‫ݕ‬ग़͕ՄೳͱͳΔɽධՁ

4 ਓͷඃ‫͕ऀݧ‬ɼ7 ͭͷδΣενϟʢλονɼӈ/ࠨํ޲ͷ 1/2/3 ຊࢦεϫΠϓʣΛͦΕͧΕ 10 ճͣͭߦͬͨɽ࣍ʹߦ͏δΣενϟ͸ϥϯμϜʹࢦࣔ͞
ΕΔɽશ 280 ࢼߦͰɼ7 ճͷ false negativeɼ2 ճͷδΣενϟͷΧςΰϦ‫ޡ‬Γʢ3 ຊࢦεϫΠϓΛ 2 ຊ
ࢦɼ1 ຊࢦεϫΠϓΛλονͱ‫ޡ‬ೝࣝʣɼ51 ճͷํ޲‫ޡ‬Γ͕͋Γɼೝࣝ཰͸ 79%Ͱ͋ͬͨɽεϫΠϓํ޲ͷ‫ݕ‬ग़ΛߦΘͳ͍৔߹ͷೝࣝ཰͸ 97%ɼ1 ຊࢦεϫΠϓͷํ޲ਖ਼ղ཰͸ 3 ໊ͷඃ‫ Ͱऀݧ‬100%ɼ4 ໊શһͰ΋ 90%Λ௒͑Δ݁Ռ͕ಘΒΕͨɽෳ਺ࢦͰͷεϫΠϓʹ͓͚Δํ޲‫ݕ‬ग़ͷೝࣝਫ਼౓޲্͕ඞཁͰ͋Δͱߟ͑ΒΕͨɽ

4·ͱΊϚϧνλονδΣενϟΛ 1 ͭͷηϯαͰ‫ݕ‬ग़͢
Δख๏ΛఏҊ͠ɼϑΥτϦϑϨΫλΛηϯαʹ༻͍࣮ͨ‫ʹݧ‬ΑΓɼ༗ޮੑΛ֬ೝͨ͠ɽࠓ‫ޙ‬ɼೝࣝਫ਼౓
ͷ޲্ɼ੩ి༰ྔࣜͷλονηϯαͳͲଞͷηϯα΁ͷద༻ʹऔΓ૊ΜͰ͍͖͍ͨɽ

ࢀߟจ‫ݙ‬[1] A. Butler, S. Izadi, and S. Hodges. SideSight:
multi-”touch” interaction around small devices.
In Proc. UIST ’08, pp. 201–204, 2008.
[2] K. Hinckley, J. Pierce, M. Sinclair, andE. Horvitz. Sensing techniques for mobile interaction. In Proc. UIST ’00, pp. 91–100, 2000.
[3] M. Ogata, Y. Sugiura, H. Osawa, and M. Imai.
iRing: intelligent ring using infrared reflection.
In Proc UIST ’12, pp. 131–136, 2012.
[4] V. Rana, N. Paliwal, and A. Chahar. Touch Sensor Assembly Using Infrared Radiations and its
Applications. In Proc. CICSyN ’09, pp. 96–98,
2009.
[5] Y. Sugiura, G. Kakehi, A. Withana, C. Lee,
D. Sakamoto, M. Sugimoto, M. Inami, andT. Igarashi. Detecting shape deformation of soft
objects using directional photoreflectivity measurement. In Proc. UIST ’11, pp. 509–516, 2011.

WISS2013ϥΠϑϩάʹ‫ͮ͘ج‬ԻָਪનγεςϜ MALL ͱͦͷ‫ݧ࣮ূݕ‬Ӊ໺ Ѫҏ౻ ‫و‬೭∗֓ཁ. ฉ͖͍ͨ‫ۂ‬ΛબͿࡍʹɼϝλσʔλ͔ΒબͿ͚ͩͰͳ͘ɼঢ়‫گ‬΍‫ڥ؀‬ʢྫ͑͹ɼఱ‫ؾ‬΍‫ق‬અɼ࣌ؒଳɼ৔ॴͳͲʣʹ߹ͬͨ‫ۂ‬Λબͼ͍ͨͱ͖͕͋Δɽ͜ΕΒͷঢ়‫گ‬΍‫ڥ؀‬ͷଟ͘͸ϥΠϑϩάσʔλͱͯ͠‫ه‬࿥ՄೳͰ͋ΔɽҰํɼզʑ͸೔ৗతʹ๲େͳָ‫ۂ‬Λॴ͍࣋ͯ͠Δ͜ͱ͕ଟ͘ɼঢ়‫ۂָͨͬ͋ʹگ‬Λͦͷ౎౓બͿͷ͸ࠔ೉Ͱ͋Δɽͦ͜Ͱզʑ͸ɼϥΠϑϩάσʔλ͔Β‫ݸ‬ਓͷબ‫ۂ‬ͷ܏޲Λ೺Ѳ͠ɼͦΕʹैָͬͯ‫ۂ‬Λࣗಈਪન͢Δ MALL (Music Adviser with Life Log) ΛఏҊ͍ͯ͠ΔɽMALL Ͱ͸ָ‫࠶ۂ‬ੜ࣌ͷϥΠϑϩά৘ใͱָ‫ۂ‬ಛ௃ྔΛর߹͠ɼͦͷ૬ؔੑϧʔϧΛಋग़͢Δɽ༷ͦͯ͠ʑͳঢ়‫ʹگ‬Ԡͯ͡૬ؔੑϧʔϧʹ֘౰͢Δָ‫ۂ‬Λਪન͢ΔɽຊใࠂͰ͸ MALL ʹؔ͢Δ‫݁ݧ࣮ূݕ‬ՌΛใࠂ͢Δɽ

͸͡Ίʹ

1

ԻָΛબ‫͢ۂ‬Δͱ͖ʹଟ͘ͷਓ͸ɼϝλσʔλΛಡΜͰ͍ΔɽͦΕʹରͯ͠ɼͦͷ৔ͷঢ়‫گ‬΍‫ʹڥ؀‬ద߹ָͨ͠‫ۂ‬Λબͼ͍ͨɼͱ͍͏ঢ়‫گ‬΋Α͋͘Δͱ
ߟ͑ΒΕΔɽ͔͠͠ҰํͰɼϙʔλϒϧԻָϓϨΠϠʔ౳ͷී‫ٴ‬ɼͦΕΒͷϝϞϦͷେ༰ྔԽʹ൐͍ɼ‫ݸ‬ਓ͕࣋ͪาָ͘‫ۂ‬ͷ਺͸૿େ͍ͯ͠ΔɽͦΕʹΑΓɼؑ৆࣌ͷঢ়‫߹ʹگ‬Θָͤͨ‫ۂ‬ͷΈΛखૣ͘୳͠
ग़͢ͷ͸ඞͣ͠΋؆୯Ͱ͸ͳ͍ͱߟ͑ΒΕΔɽ
ͦ͜Ͱզʑ͸ɼঢ়‫گ‬΍‫ʹڥ؀‬ద߹ָͨ͠‫ۂ‬Λࣗಈਪન͢ΔγεςϜ͕͋Ε͹ศརͰ͋Δͱߟ͑Δɽঢ়‫گ‬΍‫ڥ؀‬ͷมԽʹ࡞༻͢Δ΋ͷͷଟ͘͸ɼϥΠϑϩάσʔλͱͯ͠‫ه‬࿥͢Δ͜ͱ͕ՄೳͰ͋Δɽͦ͜Ͱզʑ͸ɼϥΠϑϩά͔Βબ‫ۂ‬ͷ܏޲Λ೺Ѳ͠ɼָ‫ۂ‬Λࣗಈਪન͢Δ MALL ΛఏҊ͍ͯ͠Δɽ͜ͷγεςϜͷ࣮‫ʹݱ‬ΑΓզʑ͸ɼঢ়‫߹ʹگ‬Θָͤͨ‫ۂ‬ͷࣗಈਪન͸΋ͪΖΜɼࠓ·Ͱ‫͔ͨͬͳ͔ͮؾ‬બ‫޲܏ۂ‬ͷ೺Ѳ΋ՄೳʹͳΔͱ‫ظ‬଴͢ΔɽຊใࠂͰ͸ɼMALL
Λ࢖ͬͨϢʔβςετ݁ՌΛࣔ͠ɼਪન݁Ռͷଥ౰ੑʹ͍ͭͯ‫͢ূݕ‬Δɽ

Λؑ৆͍ͯ͠Δਓ͕ɼͦͷ‫ࡏݱ͕ۂ‬ͷঢ়‫ͯͬ߹ʹگ‬
͍Δͱ‫ͨ͡ײ‬ΒॴఆͷϘλϯΛԡ͠ɼγεςϜ͸ͦͷ࣌఺ͰͷϥΠϑϩά৘ใͱҰॹʹͦͷ‫ۂ‬Λ‫ه‬࿥͢
Δɼͱ͍͏Α͏ͳॲཧखॱΛ૝ఆ͢Δɽ͜ͷΞϓϦέʔγϣϯͷಈ࡞ྫΛਤʹࣔ͢ɽਤͷӈԼʹ͋ΔԖ
චͷϘλϯ͕ϥΠϑϩά৘ใΛ‫ه‬࿥͢ΔͨΊͷϘλϯͰ͋Δɽ͜ͷϘλϯΛԡ͢͜ͱʹΑͬͯɼ೔෇ɼ༵
೔ɼ࣌ؒɼͦͷ࣌ฉ͍͍ͯͨ‫໊ۂ‬ɼͦͷ‫ۂ‬ͷΞʔςΟετ໊Λ‫ه‬࿥͢Δ͜ͱ͕Ͱ͖Δɽ͜ͷΑ͏ʹ MALL
Ͱ͸ɼԻָΛฉ͖ͳ͕ΒϘλϯΛԡ͢ͱ͍͏؆୯ͳ
ૢ࡞ͷΈͰϥΠϑϩά৘ใΛ‫ه‬࿥͢Δɽ

MALL ʹΑΔָ‫ۂ‬ਪન

22.1

ਤ 1. Android ΞϓϦέʔγϣϯͷಈ࡞ྫָ‫ۂ‬ಛ௃ྔநग़

զʑͷ࣮૷Ͱ͸ָ‫ۂ‬ಛ௃ྔநग़ιϑτ΢ΣΞ MIRtoolbox[0] Λ༻͍ͯɼָ֤‫ʹۂ‬ରͯ͠ RMS energy(Իྔͷฏ‫ۉ‬஋)ɼTempoɼRolloff(શମͷ 85%Λ઎ΊΔ௿ԻҬͷׂ߹)ɼBrightness(ߴԻҬͷׂ߹)ɼRoughness(ෆ‫ڠ‬࿨Իͷଟ͞Λࣔ͢஋)ɼSpectral irregularity(‫ۂ‬ͷมԽͷେ͖͞)ɼInharmonicity(ࠜԻʹै͍ͬͯͳ͍Իͷྔ)ɼMode(major ͱ minor ͷԻྔͷࠩ) ͷ 8 ͭͷಛ௃ྔΛநग़͍ͯ͠Δɽ
∗

2.2 ϥΠϑϩάσʔλऩूMALL Ͱ͸ɼϙʔλϒϧԻָϓϨΠϠʔ౳ͰԻָ

Copyright is held by the author(s).
Ai Uno and Takayuki Itoh, ͓஡ͷਫঁࢠେֶେֶӃ ਓؒจԽ૑੒Պֶ‫ڀݚ‬Պ ཧֶઐ߈- 155 -

2.3

૬ؔੑϧʔϧͷൃ‫ݟ‬ଓ͍ͯ MALL Ͱ͸ɼ2.1 અɼ2.2 અͰऩूͨ͠
ָ‫ۂ‬৘ใͱϥΠϑϩά৘ใͱͷؒͷ૬ؔੑϧʔϧ
(A → B) Λ‫ٻ‬ΊΔɽ۩ମతʹ͸ҎԼͷࣜ (1) Ͱࢉग़͢Δɽ͜͜ͰɼA ͸࣌ؒଳ΍‫ق‬અͱ͍ͬͨϥΠϑϩάʹؔ͢Δ৚݅ࣜΛɼB ͸ָ‫ۂ‬ಛ௃ྔͷ஋ͷൣғΛද͢ɽ૬ؔੑϧʔϧΛܾΊΔʹ͋ͨͬͯೋͭͷ਺஋ɼࢧ࣋౓ͱ֬৴౓Λ΋ͱʹ‫͢ࢉܭ‬Δɽ
ࢧ࣋౓͸, ϥΠϑϩά৚݅ͱָ‫ۂ‬ಛ௃ྔͷશͯͷ૊Έ߹Θͤͷத͔Β AɼB Λ‫ؚ‬Ήϧʔϧ͕ొ৔͢Δ

WISS 2013!
Ϣʔβ B ʹఏࣔͨ͠ϓϨΠϦετ

ස౓Λ P (A, B) ͷ֬཰Ͱࢉग़͢Δɽ·ͨࢧ࣋౓͚ͩ
Ͱ͸஋ͷ৴པੑ͕௿͍ͨΊ֬৴౓Λઃ͚Δɽ֬৴౓͸ P (B|A) Ͱࢉग़͢Δɽͦͯ͠ɼࢧ࣋౓ͱ֬৴౓ͷ૒ํ͕ߴ͍ A,B ͷ૊Έ߹ΘͤΛ૬ؔੑϧʔϧͱͯ͠બग़͠ɼͦͷϧʔϧʹ֘౰͢Δָ‫ۂ‬ΛϥΠϑϩά
৚݅͝ͱʹਪન͢Δɽਪન͞Εָͨ‫܈ۂ‬͸ͦΕͧΕϥΠϑϩά৚݅͝ͱʹϓϨΠϦετͱͯ͠Ϣʔβʹฦ͞ΕΔɽ‫Ͱ఺࣌ݱ‬ͷզʑͷ࣮૷Ͱ͸‫ݧܦ‬తʹɼࢧ
࣋౓ 0.05 Ҏ্ɼ֬৴౓ 0.15 Ҏ্ͱ͍ͯ͠Δɽ

A → B1 [a1min , a1max ]&B2 [a2min , a2max ]· · · Bn [anmin , anmax ]3• ேɿ5 ேʹ޷ΜͰฉ͘໌Δ͍‫ۂ‬΍͞Θ΍͔ͳ‫͕ۂ‬ଟ͔ͬͨɽ

• ໷ɿ4 ໷ʹ޷ΜͰฉ͘ΏͬͨΓͨ͠‫ۂ‬΍҉͍‫͕ۂ‬ଟ͔ͬͨɽ• ੖Εɿ3 ੖Εʹ߹͏໌Δ͍‫ۂ‬΋͕͋ͬͨɺ
҉͍‫ۂ‬΋ଟ͔ͬͨɽ• ͘΋Γɿ4 ໌Δ͗ͣ͢҉͗͢ͳ͍ɼ͘΋Γʹ͋ͬͨ‫͕ۂ‬ଟ͔ͬͨɽ
#$͜ΕΒͷ݁Ռ͔ΒɼϢʔβ B ͷʠ ੖Ε ʡʹର͢ΔϓϨΠϦετΛআ͖ɼMALL ͕ϥΠϑϩά৚݅͝ͱʹ߹͏ָ‫ۂ‬Λద੾ʹਪનͰ͖͍ͯΔ͜ͱ͕ࣔ͞
ΕͨɽϢʔβ B ͸ɼʠ ੖Ε ʡͷϓϨΠϦετʹ͸૬൓͢Δ 2 छྨͷҹ৅Λָ࣋ͭ‫·ؚ͕ۂ‬Ε͍ͯΔͱड़΂ͨɽϢʔβ B ͷʠ ੖Ε ʡʹ߹கͨ͠૬ؔੑϧʔϧΛදʹࣔ͢ɽҰͭ໨ͷָ‫ۂ‬ಛ௃ྔͷ૊Έ߹Θͤ͸ɼ
RMSenergyɼRoughness ‫ʹڞ‬ඇৗʹখ͍͞஋ͱͳͬ
͍ͯΔɽ͜ͷ৚݅ʹ͸ɼൺֱత७ਮͳϋʔϞχʔ͕࢖༻͞ΕΔΤϨΫτϦοΫͰͳָ͍‫͕ۂ‬ద߹͢Δɽ
ҰํͰɼೋͭ໨ͷ૊Έ߹Θͤ͸ɼRolloff ͸தؒ෇ۙͷ஋ɼBrightness ͸খ͍͞஋ͱͳ͍ͬͯΔɽͪ͜Βͷ৚݅ʹ͸ɼഒԻΛ͋·Γ‫͍ͳ·ؚ‬γϯϓϧͳΞϨϯδͷָ‫͕ۂ‬ద߹͢Δɽ͜ͷΑ͏ʹɼಠཱ͢Δ 2 ૊ͷԻָಛ௃ྔϖΞ͕Ϣʔβ B ͷʠ ੖Ε ʡϓϨΠϦε
τͷ૬ؔੑϧʔϧͱͯ͠બग़͞ΕͨͨΊɼ༷ʑͳҹ৅Λָ࣋ͭ‫ۂ‬Λଟ͘‫ؚ‬ΜͰ͠·͏݁Ռͱͳͬͨͱߟ
͑ΒΕΔɽࠓ‫ޙ‬ɼ͜ͷ݁ՌΛվળͤ͞Δํ๏Λ‫ݕ‬౼
͍ͨ͠ɽ

(1)

Ϣʔβςετ

զʑ͸ JDK1.6.0ɼAndroid SDK 2.3.3ɼADT ϓϥάΠϯΛ༻͍ͯԻָϓϨΠϠʔΛ࣮૷͠ɼSONYϙʔλϒϧԻָϓϨΠϠʔ NW-Z1050 Λ༻͍࣮ͯߦͨ͠ɽ·ͨ JDK 1.6 Λ༻͍ͯ૬ؔੑϧʔϧಋग़෦෼Λ࣮૷ͨ͠ɽͦͯ͠զʑ͸ɼঁࢠେֶੜ 2 ໊Λඃ‫ͯ͠ͱऀݧ‬ϢʔβςετΛ࣮ࢪͨ͠ɽඃ‫ʹऀݧ‬͸Ұϲ݄ؒԻָϓϨΠϠʔΛॴ࣋ͯ͠΋Β͍ɼϓϨΠϠʔʹೖ͍ͬͯΔԻָΛฉ͖ɼͦͷָ‫͕ۂ‬ঢ়‫گ‬ɾ‫؀‬‫͍ͯͬ߹ʹڥ‬ΔࡍʹॴఆͷϘλϯΛԡͯ͠΋Βͬͨɽָ‫ۂ‬σʔλ͸ɼRWC ‫༻ڀݚ‬Իָσʔλϕʔε [0] ʹऩ࿥͞Ε͍ͯͨ 313 ‫ۂ‬Λ࢖༻ͨ͠ɽ
ҎԼɼඃ‫ ऀݧ‬2 ໊ͷϥΠϑϩάσʔλΛ΋ͱʹ
MALL ʹΑͬͯਪન͞Εָͨ‫ۂ‬ͷओ‫؍‬ධՁ݁Ռʹ͍ͭͯड़΂Δɽඃ‫ͦʹऀݧ‬ΕͧΕͷϥΠϑϩάσʔλ͔Βਪન͞ΕͨϓϨΠϦετͷָ‫ۂ‬Λฉ͍ͯ΋Β͍ɼͦΕΒ͕ϥΠϑϩά৚݅ʹ߹͍ͬͯΔ͔Ͳ͏͔Λ 5 ஈ֊ͰධՁͯ͠΋ΒͬͨɽධՁ݁Ռͱίϝϯτ4 ·ͱΊ͸ҎԼͷͱ͓ΓͰ͋Δɽ!
"Ϣʔβ A ʹఏࣔͨ͠ϓϨΠϦετ
ຊใࠂͰ͸ɼϥΠϑϩάʹ‫͍ͯͮج‬ঢ়‫گ‬ɾ‫ʹڥ؀‬߹͏ָ‫ۂ‬Λࣗಈਪન͢Δ MALL Λ঺հ͠ɼϢʔβ• ໷ɿ5 ໷ʹ޷ΜͰฉ͘੩͔ͳ‫͕ۂ‬ଟ͔ͬςετ݁Ռ͔Βͦͷଥ౰ੑΛ‫ͨ͠ূݕ‬ɽϢʔβςεͨɽτͷ݁Ռ͔ΒɼMALL ʹΑΔඃ‫ ऀݧ‬2 ໊΁ͷָ‫ۂ‬ਪન݁Ռ͕֓Ͷଥ౰Ͱ͋Δ͜ͱ͕Θ͔ͬͨɽ·ͨɼ͋• ਫ༵ɿ4 ޷͖ͳ‫͕ۂ‬ଟ͔͕ͬͨɼਫ༵ಛ
·ΓΑ͘ͳ͍݁Ռ͕ग़ͨྫʹ͍ͭͯٞ࿦ͨ͠ɽ
༗ͷ܏޲͸ҙ͍ࣝͯ͠ͳ͔ͬͨɽ
ࠓ‫ޙ‬ͷ՝୊ͱͯ͠ɼਪન݁ՌΛ͞Βʹ޲্ͤ͞Δ• ੖Εɿ4 ੖Εͷ೔ʹ޷ΜͰฉ͘໌Δ͍‫ۂ‬ͨΊɼ૬ؔੑϧʔϧબग़ͷͨΊͷࢧ࣋౓ɾ֬৴౓ͷ΍͞Θ΍͔ͳ‫͕ۂ‬ଟ͔ͬͨɽ
ᮢ஋ͷ࠶ௐ੔Λߦ͍͍ͨɽ·ͨऩू͢ΔϥΠϑϩά
#$σʔλͷछྨʹ͍ͭͯ΋࠶‫ݕ‬౼͍ͨ͠ɽ

ࢀߟจ‫ݙ‬

ද 1. Ϣʔβ B ͷʠ ੖Ε ʡʹ߹கͨ͠૬ؔੑϧʔϧϥΠϑϩά৚݅

ָ‫ۂ‬ಛ௃ྔ

Sunny

RMSEnergy [0.03, 0.05]
Roughness [5.0, 55.0]
Rolloff [1500.0, 2000.0]
Brightness [0.16, 0.21]

Sunny

"

[1] O. Lartillot, ʠ MIRtoolbox ʡ, available fromhttp://www.jyu.fi/hum/laitokset/musiikki/en/
research/coe/materials/mirtoolbox[2] RWC Music Database, available fromhttp://staff.aist.go.jp/m.goto/RWC-MDB/- 156 -WISS2013

Autonomous Interactive Desk Environment ͷߏங౻ా ਅ߁ɹਡ๚ ത඙ɹ‫ ݪ܀‬૱ ∗֓ཁ. ΦϑΟε౳ʹ͓͚Δ PC Λ༻͍ͨσεΫϫʔΫʹ͓͍ͯ͸ɼ֤΢Οϯυ΢ͷ഑ஔ΍ɼ‫্ص‬ͷϊʔτɼϖϯɼϚάΧοϓͱ͍ͬͨΦϒδΣΫτͷ഑ஔಈ࡞ʹ൥Θ͠͞Λ‫͡ײ‬Δ͜ͱ͕͋Δɽ͜ͷ໰୊Λղফ͢Δ
ͨΊɼຊ‫Ͱڀݚ‬͸Ϣʔβͷ୅ΘΓʹ΢Οϯυ΢΍ΦϒδΣΫτͷ഑ஔɾ੔ཧ੔಴Λࣗ཯తʹߦ͏γεςϜɼ
AIDE (Autonomous Interactive Desk Environment) ΛఏҊ͢Δɽ௨ৗͷσΟεϓϨΠʹՃ͑ɼ‫ص‬ͷ෦෼ʹ΋λονύωϧΛ഑ஔ͠ɼߋʹϢʔβʹରͯ͠෺ཧతࢧԉΛߦ͏ͨΊͷϩϘοτΞʔϜ 2 ‫ߏͯʹج‬੒͞Εɼ֤΢Οϯυ΢ͱΦϒδΣΫτΛͦΕͧΕࣗ཯ΤʔδΣϯτԽ͠ɼϚϧνΤʔδΣϯτ‫ڠ‬ௐϝΧχζϜʹ‫ͮج‬͍ͯϢʔβʹର͢Δద੾ͳΠϯλϥΫγϣϯΛ࣮ߦ͢Δɽ֤ΤʔδΣϯτͷҠಈࢦඪΛઃఆ͢ΔͨΊɼϢʔβͷ࡞‫ۀ‬ϩά͔Βఆ‫ܕ‬తͳ࡞‫ۀ‬ύλʔϯΛநग़͠ɼ͜ΕΒͷσʔλΛऩू͢Δ͜ͱʹΑΓΤʔδΣϯτͷ
ҠಈઌͷֶशΛߦ͏ɽ

1

͸͡Ίʹ

ΦϑΟε౳ʹ͓͚Δ PC Λ༻͍ͨσεΫϫʔΫʹ͓͍ͯ͸ɼ֤΢Οϯυ΢ͷ഑ஔ΍ɼ‫্ص‬ͷϊʔτɼϖϯɼϚάΧοϓͱ͍ͬͨΦϒδΣΫτͷ഑ஔʹ൥Θ͠͞Λ‫͡ײ‬Δ͜ͱ͕͋Δɽ͔͠͠‫ݱ‬ঢ়Ͱ͸ɼ഑ஔ࡞‫ۀ‬͸खಈͰߦΘΕ͍ͯΔɽ
͜ͷΑ͏ͳਓखͷ࡞‫ۀ‬ΛϩϘοτ౳ͷΤʔδΣϯτʹΑΓࢧԉ͢Δ‫͕͋ڀݚ‬ΔɽDuan[1] Β͸ɼσεΫϫʔΫͷ 1 ͭͰ͋Δηϧੜ࢈૊ཱΛର৅ͱ͠ɼϩϘοτ͕෦඼Λ࡞‫ऀۀ‬ͷ΋ͱ·Ͱ഑હ͢Δɼ૊ཱ৘ใΛ‫ʹ্ص‬දࣔ͢Δ౳ɼ࡞‫ͱऀۀ‬γεςϜͱͷ‫ڠ‬ௐʹΑΔ૊ཱ࡞‫ࢧۀ‬ԉγεςϜΛఏҊ͍ͯ͠Δɽ͔͠
͜͠ͷγεςϜͰ͸ɼಈ࡞λΠϛϯάΛϢʔβ͕ࢦࣔ͠ͳ͚Ε͹ͳΒͣɼγεςϜ͕Ϣʔβͷ࡞‫ۀ‬ঢ়‫گ‬Λ‫཯ࣗͯݟ‬తʹಈ࡞͢Δͱ͍͏ࣄ͸Ͱ͖ͳ͍ɽΑΓਓͷෛՙΛ‫ݮ‬Β͢ʹ͸ɼϢʔβͷಈ࡞͔ΒϢʔβ͕࣍ʹԿΛ‫ٻ‬ΊΔ͔༧ଌ͠ɼࣗ཯తʹࢧԉ͢Δ͜ͱ͕
ඞཁͰ͋Δɽ
ͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼPC Λ༻͍ͨσεΫϫʔΫΛର৅ͱ͠ɼσεΫϫʔΫࢧԉγεςϜͱͯ͠ɼ΢Οϯυ΢΍σεΫ্ʹ͋Δ෺ͷ഑ஔɾ੔ཧ੔಴ΛϢʔβͷ୅ΘΓʹࣗ཯తʹߦ͏‫ܕص‬σόΠεɼAIDE (Autonomous Interactive Desk Environment) Λߏங͢Δʢਤ 1ʣɽ

2

AIDE ͷߏ੒

AIDE Ͱ͸ɼσΟεϓϨΠΛਖ਼໘ʹ 1 ୆ஔ͖ɼख
લʹ 3 ୆৸͔ͤɼ৸͔ͤͨ 3 ୆ͷσΟεϓϨΠΛ৘ใදࣔՄೳͳ‫ͯ͠ͱص‬ར༻͢Δɽຊ‫Ͱڀݚ‬͸ɼ‫ͱص‬ͯ͠ར༻͢ΔσΟεϓϨΠΛʮਫฏσΟεϓϨΠʯ
Copyright is held by the author(s).
∗ి‫ؾ‬௨৴େֶ େֶӃ৘ใγεςϜֶ‫ڀݚ‬Պ ࣾձ஌ೳ৘
ใֶઐ߈- 157 -

ਤ 1. AIDEͱ‫Ϳݺ‬ɽਫฏσΟεϓϨΠΛ༻͍Δ͜ͱʹΑΓɼຊ΍ॻྨɼϝϞॻ͖౳ͷख‫͋ʹݩ‬Δ෺ͱσΟεϓϨΠ
্ͷ৘ใΛ‫ݟ‬ൺ΂΍͘͢͢Δɽ·ͨɼखલͷ 3 ୆ͷϞχλʔ͸λονϞχλʔͱͳ͓ͬͯΓɼ௚‫ײ‬తͳૢ࡞ΛՄೳͱ͢Δɽ·ͨɼ‫্ص‬ͷঢ়ଶΛೝࣝ͢ΔͨΊɼ΢ΣϒΧϝϥΛઃஔ͢Δɽ·ͨɼ‫ص‬ͷԞɼࠨӈʹϩϘοτΞʔϜΛઃஔ͠ɼ΢ΣϒΧϝϥͱϩϘοτΞʔϜΛ༻͍ͯσεΫ্ͷ෺ͷ഑ஔ΍੔ཧ੔಴ͱ͍ͬͨ෺ཧతࢧԉΛߦ͏ɽ͞ΒʹɼϢʔβͷखͷಈ͖΍࢟੎ʹରԠͯ͠ΠϯλϥΫγϣϯΛ࣮ߦͤ͞ΔͨΊʹɼKinect Λઃஔ͠ɼϢʔβͷಈ࡞Λ‫ݕ‬ग़͢Δɽ

33.1

ఏҊγεςϜͷ֓ཁ΢Οϯυ΢ͷࣗ཯ΤʔδΣϯτԽσΟεϓϨΠ্ʹදࣔ͞Ε͍ͯΔ৘ใΛࣗಈతʹ഑ஔɾ੔ཧ੔಴Λߦ͏ͨΊɼ΢Οϯυ΢౳Λࣗ཯ΤʔδΣϯτԽ͢Δɽຊ‫Ͱڀݚ‬͸ɼࣗ཯ΤʔδΣϯτԽWISS 2013ͨ͠΢Οϯυ΢Λʠ΢Οϯυ΢ΤʔδΣϯτʡͱ‫Ϳݺ‬ɽ΢Οϯυ΢ΤʔδΣϯτͷ໨త͸ʠ Ϣʔβʹࣗ෼Λ‫ͯݟ‬΋Β͏ ʡ͜ͱͰ͋Δɽ͜ͷ໨తΛઃఆ͢Δ͜ͱΑΓɼ΢Οϯυ΢ΤʔδΣϯτ͸ࣗ਎ͷଘࡏՁ஋͕࠷΋ߴ͘ͳΔҐஔ΁ͱࣗΒҠಈ͢Δɽ
΢Οϯυ΢ΤʔδΣϯτͷҠಈઌީิ͸ɼա‫ʹڈ‬ࣗ਎͕഑ஔ͞ΕͨҐஔ΍Ϣʔβ͕Α͘ࢹઢΛૹΔҐ
ஔ౳͔Βઃఆ͠ɼ֤΢Οϯυ΢ΤʔδΣϯτ͸ͳΔ΂͘‫ر‬๬ॱҐͷߴ͍Ҡಈઌީิ΁Ҡಈ͠Α͏ͱ͢Δɽຊ‫Ͱڀݚ‬͸ɼσΟεϓϨΠ্ͷ͋ΔҐஔ΁Ϣʔβ͕ࢹઢΛૹΔස౓ΛɼͦͷҐஔʹ͓͚Δʠ ࢹઢස౓ ʡͱ‫Ϳݺ‬ɽ
͔͠͠ɼ্‫ه‬ͷઃఆ͚ͩͰ͸ෳ਺ͷ΢Οϯυ΢ΤʔδΣϯτ͕ಛఆͷՕॴʹूத͢Δͱ͍͏໰୊͕‫͜ى‬Δɽͦ͜Ͱ‫ݸ‬ʑͷ΢Οϯυ΢ΤʔδΣϯτʹʠ ༏ઌ౓ʡΛઃఆ͠ɼ༏ઌ౓͕ߴ͍΢Οϯυ΢ΤʔδΣϯτ΄Ͳɼࢹઢස౓͕ߴ͘ɼࣗ਎͕සൟʹ഑ஔ͞ΕΔҐஔ΁ͱҠಈͰ͖ΔΑ͏ʹ͢Δɽ༏ઌ౓͸ɼϢʔβͷ΢Οϯυ΢ૢ࡞ཤྺ͔ΒɼΞΫςΟϒ΢Οϯυ΢ঢ়ଶͷ࣌ؒ౳Λ༻͍ͯࢉग़͢Δɽྫ͑͹ɼϒϥ΢β΍
PDF ϑΝΠϧ౳ɼࢿྉͱͯ͠༻͍Δ͜ͱ͕ଟ͍ΞϓϦέʔγϣϯΑΓ΋ɼMicrosoft Office Word ΍Latex ౳ɼ࢓ࣄͱͯ͠༻͍Δࣄ͕ଟ͍ΞϓϦέʔγϣϯͷํ͕ΑΓ༏ઌ౓͕ߴ͘ͳΔΑ͏ʹ͢Δɽ‫ݸ‬ʑͷ΢Οϯυ΢ΤʔδΣϯτʹ༏ઌ౓Λઃఆ͢ΔࣄʹΑΓɼୈ 1 Ҡಈީิ͕ಉ͡Ͱ͋Δ΢Οϯυ΢ΤʔδΣϯτ͕ෳ਺ଘࡏͨ͠৔߹ɼ࠷΋ߴ͍༏ઌ౓Λ࣋ͭ΢Οϯυ΢ΤʔδΣϯτ͕ࣗ਎ͷୈ 1 Ҡಈީิ΁ҠಈͰ͖ɼ༏ઌ౓͕௿͍΢Οϯυ΢ΤʔδΣϯτୡ͸ࣗ਎ΑΓߴ͍༏ઌ౓Λ࣋ͭ΢Οϯυ΢ΤʔδΣϯτͱॏͳΔࣄΛආ͚ΔͨΊɼࣗ਎ͷҠಈઌީิͷத͔Β࣍ͷީิͷҐஔ΁ͱҠಈ͢Δɽ΢Οϯυ΢ΤʔδΣϯτʹ༩͑ΒΕΔ༏ઌ౓͸ɼ΢Οϯυ΢ΤʔδΣϯτ͕‫ى‬ಈͨ͠ͱ͖ʹઃఆ͞ΕΔɽ
·ͨɼϢʔβͷ΢Οϯυ΢ૢ࡞‫ه‬࿥Λऔಘ͢Δ͜
ͱͰɼ΢Οϯυ΢ಉ࢜ͷఆ‫ܕ‬తͳ഑ஔύλʔϯΛൃ‫͠ݟ‬ɼ΢Οϯυ΢ΤʔδΣϯτͷྦྷ‫ܭ‬ͷ༏ઌ౓͚ͩ
Ͱͳ͘ɼఆ‫ܕ‬తͳ഑ஔύλʔϯͷ͚࣌ͩͷ༏ઌ౓Λ‫͢ࢉܭ‬Δɽ͜ΕʹΑΓύλʔϯʹ౰ͯ͸·Δ΢Οϯυ΢ΤʔδΣϯτ͕‫ى‬ಈͨ͠ͱ͖ɼఆ‫ܕ‬తͳ഑ஔύλʔϯͷ࣌ͷ༏ઌ౓Λద༻͠ɼ΢Οϯυ΢ΤʔδΣϯτ͕ఆ‫ܕ‬తͳ഑ஔҐஔ΁Ҡಈ͢Δ͜ͱΛՄೳͱ͢Δɽ

3.2‫্ص‬ͷΦϒδΣΫτͷࣗ཯ΤʔδΣϯτԽϢʔβͷσεΫ্ʹ͸༷ʑͳ෺͕ଘࡏ͍ͯ͠Δɽຊ‫Ͱڀݚ‬͸ɼσεΫ্ʹ͋Δ෺Λʠ ‫্ص‬ΦϒδΣΫτ ʡͱ‫Ϳݺ‬ɽAIDE γεςϜͰ͸ɼσΟεϓϨΠΛ
σεΫͱͯ͠ར༻͢Δࣄ͔Βɼ΢Οϯυ΢ͱ‫্ص‬ΦϒδΣΫτ͕ॏͳͬͯ͠·͏ͱ͍͏ঢ়‫͜ى͕گ‬Γಘ
Δɽ΢Οϯυ΢ͱΦϒδΣΫτ͕ॏͳͬͯ͠·ͬͨ৔߹ɼϢʔβ͸࢓ࣄͷखΛࢭΊͯ΢Οϯυ΢ͱ‫্ص‬ΦϒδΣΫτͷॏͳΓΛղܾ͠ͳ͚Ε͹ͳΒͳ͍ɽͦ- 158 -

͜Ͱɼ‫্ص‬ΦϒδΣΫτͷҠಈखஈʹϩϘοτΞʔϜΛ༻͍Δ͜ͱͰɼ‫্ص‬ΦϒδΣΫτΛࣗ཯ΤʔδΣϯτԽ͢Δɽຊ‫Ͱڀݚ‬͸ɼΤʔδΣϯτԽͨ͠‫্ص‬ΦϒδΣΫτΛɼʠ ΦϒδΣΫτΤʔδΣϯτ ʡͱ‫Ϳݺ‬ɽΦϒδΣΫτΤʔδΣϯτʹ΋΢Οϯυ΢ΤʔδΣϯτಉ༷ʹɼϢʔβͷ࢖༻ස౓͔Β༏ઌ౓Λ‫͠ࢉܭ‬ɼࣗ਎ͷ഑ஔཤྺͱσΟεϓϨΠ্ͷࢹઢස౓ͷঢ়‫گ‬͔ΒɼҠಈઌީิΛઃఆ͢Δɽ

3.3

ΤʔδΣϯτͷҠಈࢦඪͷઃఆํ๏΢Οϯυ΢ΤʔδΣϯτͷ༏ઌ౓Λઃఆ͢ΔͨΊʹɼϢʔβ͕࢖༻֤ͨ͠ΞϓϦέʔγϣϯͷ΢Οϯ
υ΢αΠζ΍΢Οϯυ΢഑ஔ౳ɼ΢Οϯυ΢ૢ࡞৘ใΛ‫ه‬࿥͢Δɽ·ͨɼࢹઢස౓Λࢉग़͢ΔͨΊʹɼ
Kinect Λ༻͍ͯϢʔβͷ࢟੎΍ಈ࡞ɼ‫إ‬ͷҐஔɼࢹઢ౳΋‫ه‬࿥͢Δɽ͞ΒʹɼΦϒδΣΫτΤʔδΣϯτͷ༏ઌ౓Λઃఆ͢ΔͨΊʹɼ΢ΣϒΧϝϥΛ༻͍ͯΦϒδΣΫτͷ഑ஔ΍࢖༻ස౓౳ɼਫฏσΟεϓϨΠ্ͷঢ়‫گ‬Λ‫ه‬࿥͢ΔɽϢʔβ͕΢Οϯυ΢Λ഑ஔͨ͠Ґஔ͸ɼඞͣϢʔβʹͱͬͯ‫ݟ‬΍͍͢ҐஔͰ͋Δɽ·ͨɼKinect Λ༻͍ͯϢʔβͷ༷ࢠΛ‫؍‬ଌ͢ΔࣄʹΑΓɼϢʔβ͕σΟεϓϨΠ্ͷͲͷҐஔΛͲͷఔ౓‫͔͍ͨͯݟ‬೺ѲͰ͖Δɽ͜ΕΒͷσʔλΛऩू͢Δ͜ͱʹΑΓɼσΟεϓϨΠ্ͷ x-y ࠲ඪʹ͓͚Δࢹઢස౓͕ఆྔ
ԽͰ͖ΔɽσΟεϓϨΠ্ͷ x-y ࠲ඪʹ͓͚Δࢹઢ
ස౓ͷϚοϓΛ࡞੒͠ɼΤʔδΣϯτͷҠಈࢦඪͱ͢Δɽͦͯ͠ɼૢ࡞ϩά͔Βɼϝʔϧ࡞੒΍จষ࡞੒ɼ
ωοτ‫͍ͨͬͱࡧݕ‬ɼλεΫ୯ҐͰͷఆ‫ܕ‬తͳ΢Οϯυ΢഑ஔ΍σεΫ্ͷจ๪۩ͷ഑ஔ౳ͷύλʔϯΛநग़͠ɼఆ‫ܕ‬తύλʔϯద༻࣌ͷ༏ઌ౓Λઃఆ͢ΔͨΊͷࢦඪͱ͢Δɽ

4

͓ΘΓʹ

‫ࡏݱ‬ɼਤ 1 ͷ૷ஔͷ૊Έཱ͕ͯ‫׬‬੒͠ɼ͜Ε͔Βૢ࡞ϩάͷऔಘΛ։࢝͢Δɽ·ͨɼΠϯλϥΫγϣ
ϯͷͨΊͷϚϧνΤʔδΣϯτ‫ڠ‬ௐϝΧχζϜͷߏஙΛ։࢝͠ɼAIDE ΁ͷఏҊγεςϜͷ࣮૷Λ໨ࢦ͢ɽఏҊγεςϜΛ AIDE ʹ࣮૷ͨ͠‫ޙ‬ɼϢʔβͱ
AIDE ͱͷ‫ڠ‬ௐ࡞‫ؔ͢ʹۀ‬Δඃ‫ݧ࣮ऀݧ‬Λߦ͏‫ܭ‬ըͰ͋Δɽࢀߟจ‫ݙ‬[1] Feng Duan, Masahiro Morioka, Jeffrey Too
Chuan Tan, Ye Zhang, Kei Watanabe, Nuttapol
Pongthanya, Masao Sugi, Hiroshi Yokoi, Ryou
Nihei, Shinsuke Sakakibara and Tamio Arai, ”Multimedia based Assembly Supporting System
for Cell Production” , 2008

WISS2013

BrightFace: プロジェクションによる表情拡張システム
辻田 眸

暦本 純一∗

概要. 対人コミュニケーションにおいて，重要な役割を果たしているのは表情や身振り，声の調子などの非言語情報であると言われている．なかでも表情は自分の感情を表出し，また他者の感情を理解するために効果的な手段である．しかしながら人によっては自分の感情をうまく表現できなかったり，他者には伝わりにくいときもあるだろう．メールなどの文字メッセージでのコミュニケーションの場合，顔文字や絵文
字などを利用し，自分の感情をより効果的に伝えることができる．そこで実世界の対面コミュニケーショ
ンにおいても，文字メッセージで行われているようなアイコンを利用し，自分の表情を補足することができれば，より効果的に自分の感情を他者に伝達でき，コミュニケーションに役立つのではないかと考えた．
本研究ではユーザの表情に応じて，アイコンをユーザの顔に投影し，表情を拡張表現することで，対人コ
ミュニケーション支援を行うシステム「BrightFace」を提案・実装した．

1

はじめに

Mehrabian 氏らの研究 [1] によると，対人コミュ
ニケーションにおいて，表情やしぐさが他者の印象や感情を判断，理解するのに重要な役割を占めているとされている．しかしながら人によっては自分の感情をうまく表現できなかったり，また他者の表情を読み取れず，感情の読み間違いをしてしまうこともあるだろう．一方，メールやチャットなど，文字によるコミュニケーションにおいては，顔文字や絵文字など，自分の表情を表すアイコンを利用することで，相手に自分の感情や雰囲気を伝達する役割を果たしている．さらに漫画やアニメーションの世界
では，キャラクターの顔にアイコンを書き加えたり，頭上に線を書き足し強調して表現することで，絵に対する印象を変化させる表現技法が知られている．
そこで，日常生活での対面会話のときに，このよ
うな文字コミュニケーションで行われているアイコンの付加や漫画等で用いられている表現技法を利用し，ユーザの表現能力を拡張することで，お互いの感情理解を深め，コミュニケーション円滑化の支援になるのではないかと考えた．本研究ではユーザの表情に応じて，アイコンをユーザの顔に投影し，表現能力を拡張することで，コミュニケーション支援を行うシステム「BrightFace」の提案を行う．

2

BrightFace

BrightFace はユーザの表情に応じて顔にアイコンを投影させることで，ユーザの感情をよりわかりやすく他人に伝達できるシステムである．例えば図1 のように，ユーザが笑顔になったときにはその表∗

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

図 1. BrightFace システム．ユーザの表情を検出し，それに応じたアイコンをプロジェクションする．

情を拡張表現できるような幸せそうなハートアイコ
ンを，またユーザがやや悲しい表情をしたときには，
涙マークなどのアイコンを顔にプロジェクションする．ユーザの表情に応じて，リアルタイムに表情理解が容易にできるようなアイコンをユーザの顔に投影してあげることで，ユーザの表現能力を拡張し，他者の表情・感情理解を深め，コミュニケーション
円滑化につながるのではないかと考えた．
本論文では基本的感情表出の中の，「喜び・怒り・
悲しみ」に着目した．プロジェクションするアイコンについては，漫画でその表情を拡張表現するときに用いられているような一般的なアイコンを採用した（図 2）．ただし喜び（笑顔）のアイコンについては，様々なアイコンを投影し検討した結果，より表情理解が容易にできるような，図２のようなハートアイコンを投影することにした．表情拡張する感情の種類，提示するアイコンの適正については今後
評価実験を通じてさらに検討していきたい．

WISS 2013

用した．ユーザの表情検出には openframeworks のofxFaceTracker を利用した．またあらかじめユー
ザの表情を登録しておくことで，笑顔だけでなく，ユーザの表情に応じてアイコンを表出・プロジェク
ションし，ビジュアルフィードバックを与える．ア
イコンはユーザの顔の傾き，顔の大きさに応じてサイズを変え，ユーザの顔に位置にあうように工夫している．
図 2. プロジェクションするアイコンの例．

4

図 3. BrightFace のシステム構成．

2.1

プロジェクターでのアイコン投影

ユーザの表情に対してフィードバックを与える方
法はいくつか考えられる．例えば，ユーザの表情や会話の内容に関するフィードバックをディスプレイ
に投影したり，テーブルとディスプレイが一体となっているデバイスに，アニメーションを映し出したりすることも考えられる．しかしながら，そういった場
合，相手の顔から目線をはずすために，相手の表情とアイコンの両方を見ることは容易ではない．そこ
でユーザの目線をそらすことなく，また会話を阻害しないような形で，他者の表情理解の支援，また自分自身の表現能力の拡張を行い，感情を容易に相手に伝えることができるような表現方法を模索した．
その結果，顔に直接プロジェクションすることで，相手の表情とアイコンを同時に見ることができるので，ユーザの目線をそらすことなく，またプロジェ
クターによりアイコンだけでなく，様々な表現が可能になるため，会話を阻害せず，コミュニケーショ
ン支援に役立つのではないかと考えた．

3

システム構成BrightFace のシステム構成について述べる（図3）．USB カメラと小型プロジェクターが一体になっている．プロジェクターについては，小型でかつ，明るい室内においても，プロジェクションされたアイ
コンや効果がわかるように，サンワサプライ株式会
社の DLP 方式採用のモバイルプロジェクターを使用している．テーブル上においてもあまり圧迫された感じがなく，会話自体を阻害しない小型なものを採- 160 -

関連研究

これまでにも会話の可視化や，プロジェクション
マッピングによって人が受ける印象を変化させる研究は多くなされている．埴淵らは [2] ２者間の対面会
話環境において，笑顔アイコンをテーブル上のディス
プレイに提示することで，会話や顔面動作にどのような影響を与えるのかを検証した．IllumiRoom[?]
は，プロジェクターと Kinect を組み合わせ，テレ
ビの周囲に画面の延長となる映像や，画面と連動する映像を映し出すことで，ゲームの没入感を高めている．扇情的な鏡 [3] ではディスプレーに映し出されたユーザの顔をシステムが自動で目や頬の位置を変えることで，ユーザの表情とは関係なく，笑い顔
や悲しい顔に変形するシステムである．我々は人の顔に直接プロジェクションを行い，表情の表現能力を拡張することで，人の印象がどのように変化するのかを検証したり，コミュニケーション支援や会話の活性化を目指している．

5

まとめと今後の予定

ユーザの表情に応じて，アイコンをユーザの顔に投影し，表情を拡張表現することで，対人コミュニ
ケーション支援を行うシステム「BrightFace」を提案・実装した．USB カメラと小型プロジェクターを利用し，基本的感情表出の中の，「喜び・怒り・悲しみ」に着目し，それに応じたアイコンをユーザの顔に直接プロジェクションを行った．現在は卓上のシステムになっているが，将来的にはモバイルな参考文献[1] Mehrabian, A. Communication without words,
Psychology Today, 1968, 2 (4), 53-55.
[2] 埴淵俊平, 伊藤京子, 西田正吾. ソーシャルインタ
フェースの設計に向けた笑顔アイコン利用方法の検討, ヒューマンインタフェース学会論文誌, 201111-25, 13, 4, 365-375.
[3] S.Yoshida, S.Sakurai, T.Narumi, T.Tanikawa and
M.Hirose: Manipulation of an Emotional Experience by Real-time Deformed Facial Feedback,
AH2013, Stuttgart, Germany, Mar, 2013.

WISS2013

ボケる対話型システムの検討
藤本 浩介

岡部 誠

尾内 理紀夫∗概要. 本研究では，ボケる日本語の対話型システムを提案する．駄洒落やなぞかけ等，笑いに関するシステムの研究は数多く存在する．しかし，駄洒落やなぞかけ等は出力される文そのものが面白いということに対し，ボケやツッコミは対話そのものが面白いという違いがある．そこで，本研究では人間とコンピュータとの既存の対話型システムを参考にし，ボケる対話型システムを提案する．本システムは，テキスト情報を入力として受け取る．入力を解析した後，あらかじめ用意された辞書から類似した文字列を検索し，ボケを出力する．また，出力されたボケに対する入力からユーザがボケを理解できているのか，ボケに対しツッ
コミを入れているのか，ボケに便乗してボケているのかを判定し，それぞれの判定結果に適した出力を行う．さらに，音声合成や効果音，文字サイズの変更を用いて分かりやすく提示する．

1

はじめに

近年，Apple の Siri1 や，NTT ドコモのしゃべってコンシェル2 等の対話システムの普及により，人間とコンピュータが対話を行う機会が増えている．
人間とコンピュータが対話を行うにあたって，ユー
ザの要求したタスクをこなすことは実用性という面で重要であるが，親しみやすさという面では面白い対話を行うことが重要であると考える．しかし，面
白い対話を行うことを目的としたシステムは存在しない．そこで，我々は面白い対話を行う方法の 1 つとしてボケる対話型システムを提案する．なお，ボ
ケやツッコミには様々な種類が存在するが、本研究では「ボケ」とはわざと間違った発言をすること，「ツッコミ」とはボケの間違いを指摘することと定
義する．

2

関連研究

駄洒落やなぞかけ等の笑いに関するシステムの研究は数多く行われている [1, 2]．これらのシステム
は入力に対して駄洒落やなぞかけ等を出力するという一往復でユーザとのやりとりが完結されている．
駄洒落やなぞかけ等は出力される文そのものが面白さを含んでいるが，ボケやツッコミは対話そのものが面白さを含んでいるという違いがあるため，ユー
ザとの対話を行う必要性がある．
人間とコンピュータとの対話型システムに関する研究は多数存在する [3, 4]．対話型システムを実現する主流な方法の 1 つにルールベースがある．ルー
Copyright is held by the author(s).
Kosuke Fujimoto， 電気通信大学，Makoto Okabe， 電気通信大学/JST CREST， Rikio Onai， 電気通信大学
1
Siri: http://www.apple.com/jp/ios/siri/?cid=MARJP-GOOG-IPHONE
2
しゃべってコンシェル: http://www.nttdocomo.co.jp/
service/information/shabette concier/

ルベースとは，入力として与えられた文に代名詞が入っていた場合はこのような文を出力するといったようなルールをあらかじめ設定しておき，対話を実現する方法である．本システムはボケることに限定しているので，ルール記述のコストが小さいため，
ルールベースで対話を行う．

3

システム概要本システムは入力としてテキスト情報を受け取る．入力を解析し，ボケることが可能な場合にボケを出力する．その後，出力されたボケに対する入力からユーザがボケを理解できているのか，ボケに対しツッコミを入れているのか，ボケに便乗してボケているのかを判定し，それぞれの判定結果に適した出力を行う．対話の出力には音声合成を用い，シス
テムがボケを出力した場合やユーザがツッコミを入力した際には効果音を出力する．システムとの対話
例を表 1 に示す．
表 1. システムの対話例

ユーザ：やっぱり徳川家の家紋ってかっこいい
システム：チャラリ〜鼻から牛乳〜
ユーザ：嘉門達夫じゃねえよ．つかベタなぼけ
やなぁ．お前はお笑い芸人の新人かよ
システム：（耳が）でっかくなっちゃった！
ユーザ：それはお笑い芸人のマギー審司だろ
システム：良いツッコミです．話の続きをどうぞ

∗

4

実装

ユーザインタフェースを図 1 に示す．システムがボケたり，ユーザがツッコミを入れた部分は対話のログの部分で文字サイズを大きくすることにより，- 161 -WISS 2013

どこでボケやツッコミが行われたのかを分かりやすく提示する．

出力されたボケに便乗してボケている状態である．
「疑問」状態の判定はユーザ入力の中に「誰」や「なに」等疑問を表す言葉が出現する場合にユーザは「疑問」状態であると判定し，何故そのようなボケをしたのかの説明を出力する．
「ツッコミ」は入力の語尾から判定する．あらか
じめ漫才で用いられたツッコミを収集したテキスト
データから頻出の語尾を特定し，それらの語尾が出現していた場合，ユーザは「ツッコミ」状態だと判定し，入力に対してさらにボケることが可能ならばボケを出力する．
「疑問」でも「ツッコミ」でもないものは「ボケ」状態だと判定し，ユーザに話を続けるよう促す．
本システムは，音声合成と効果音を用いる．音声
合成はシステムによるボケ等の出力の際に用いる．
効果音は，システムがボケた時やユーザがツッコミを入れた時に拍手や笑い声等を出力する．

5

図 1. ユーザインタフェース

本システムはボケとして、わざと聞き間違いによるボケを出力する．その理由は，大島の研究により日本人が面白いと感じる話の傾向として「言い間違い・聞き間違い」による話の割合が一番高いということが判明しているからである [5]．
ボケを出力する際にはまず，入力されたテキスト
情報に対して形態素解析を行い，形態素ごとに分割する．それらをあらかじめ用意された辞書と比較し，辞書から文字列が類似している項目を検索する．辞書には，芸人や歌手，それらに関連するギャグや曲名等のテキスト情報を Web サイト3 4 を参考にし，登録している．
文字列の類似度はレーベンシュタイン距離を用いて判定している [6]．レーベンシュタイン距離は対象の文字列が，比較対象の文字列に変形するまでに文字の削除や挿入等の手順がどれほど必要かを求め，文字列の類似度を判定する手法である．類似した文字列の項目が存在した場合，その項目を用いて聞き間違いによるボケを出力する．
本システムは，ボケに対する入力からユーザの状態を判定する．ボケに対してユーザは，
「疑問」「
，ツッ
コミ」，
「ボケ」の 3 つの状態のいずれかになると仮定して判定する．
「疑問」とは出力されたボケが理解できていない状態であり，「ツッコミ」とはボケに対してツッコミを入れている状態であり，「ボケ」とは
3
4

音域.com: http://www.music-key.com/
Yourpedia: http://ja.yourpedia.org/wiki/- 162 -

まとめ

本研究ではレーベンシュタイン距離により類似した文字列をあらかじめ用意された辞書から検索することで，わざと聞き間違いによるボケを出力し，さらに，音声合成や効果音，文字サイズの変更を用いてユーザに分かりやすく提示するボケる対話型シス
テムを提案した．

参考文献[1] 田辺公一朗. 駄洒落のコンピュータによる処理:
駄洒落生成システムの基本設計. 産能大学紀要,
Vol. 26, No. 1, pp. 65–74, 2005.
[2] 前田実香, 鬼沢武久. 単語の関連性とおもしろさを取り入れたなぞかけ生成. 感性工学研究論文集,
Vol. 5, No. 3, pp. 17–22, 2005.
[3] 稲葉通将, 平井尚樹, 鳥海不二夫, 石井健一郎. 非タ
スク指向型対話エージェントのための統計的応答
手法. 電子情報通信学会論文誌 D, Vol. 95, No. 6,
pp. 1390–1400, 2012.
[4] 岡本昌之, 山中信敏. Wizard of oz 法を用いた対話型 web エージェントの構築. 人工知能学会論文
誌, Vol. 17, No. 3, pp. 293–300, 2002.
[5] 大島希巳江. 日本人がおもしろいと感じる話の傾
向: 日本一おもしろい話プロジェクト (2010 年 4 月
˜ 2011 年 3 月) の結果と分析. 笑い学研究, No. 18,
pp. 14–24, 2011.
[6] Vladimir I Levenshtein. Binary codes capableof correcting deletions, insertions and reversals.
In Soviet physics doklady, Vol. 10, pp. 707–710,
1966.

WISS2013ࢴ૭: ͦ͜ʹஔ͚ͩ͘Ͱૢ࡞ՄೳͳΧʔυΠϯλϑΣʔεՃ౻ ๜୓‫ٶ‬Լ ๕໌ ∗֓ཁ. ίϯϐϡʔλ্Ͱ࡞‫ۀ‬Λߦ͏ࡍɼෳ਺ͷΞϓϦέʔγϣϯΛಉ࣌ʹ࢖༻͢Δ͜ͱ͕͋Δɽ͔͠͠ɼ
ͦΕΒͷશ͕ͯ࡞‫ۀ‬શମΛ௨ͯ͠ඞཁͳ΋ͷͰ͸ͳ͘ɼ࢖༻ͨ͠Β͙͢ʹดͯ͡͠·͏Α͏ͳΞϓϦέʔγϣϯ΋গͳ͘ͳ͍ɽ͜͏ͨ͠؆୯ͳΞϓϦέʔγϣϯ͸ਂ͍֊૚ʹஔ͔Εͯ͠·͍͕ͪͰ͋Γɼ‫ى‬ಈʹ൥ࡶͳखॱ͕ඞཁͱͳͬͯ͠·͏৔߹͕͋Δɽຊ‫Ͱڀݚ‬͸ɼʮࠓͪΐͬͱ͚ͩ࢖͍͍ͨʯ؆୯ͳΞϓϦέʔγϣϯΛଈ࣌ʹ‫ى‬ಈ͢Δɼஔ͚ͩ͘Ͱૢ࡞ՄೳͳΧʔυΠϯλϑΣʔεΛఏҊ͢Δɽෳ਺ͷಋి෦Λ഑ஔͨ͠ΧʔυΛλονύωϧσΟεϓϨΠ্ʹ৐ͤΔ͜ͱͰ೚ҙͷΞϓϦέʔγϣϯ͕දࣔ͞ΕɼϢʔβ͸ΧʔυΛ௨ͯ͠ΞϓϦέʔγϣϯΛ࢖༻͢Δ͜ͱ͕Ͱ͖Δɽ

1

͸͡Ίʹ

ίϯϐϡʔλ্Ͱͷ࡞‫ۀ‬Λߦ͏ࡍɼ࡞‫ۀ‬ͷத৺ͱͳͬͯ࢖༻͞ΕΔΞϓϦέʔγϣϯͷଞʹɼෳ਺ͷΞϓϦέʔγϣϯΛಉ࣌ʹ࢖༻͢Δ͜ͱ͕͋Δɽ͠
͔͠ɼͦΕΒશͯͷΞϓϦέʔγϣϯ͕࡞‫ۀ‬શମΛ௨ͯ͠ඞཁͳ΋ͷͰ͸ͳ͘ɼ࢖༻ͨ͠Β͙͢ʹด͡ΒΕͯ͠·͏Α͏ͳɼ؆୯ͳ‫ػ‬ೳ͔࣋ͨ͠ͳ͍ΞϓϦέʔγϣϯ΋গͳ͘ͳ͍ɽ
‫͍ͯ͠ٴීࡏݱ‬ΔσεΫτοϓϝλϑΝΛऔΓೖΕͨ PC Ͱ͸ɼ৘ใΛσΟεϓϨΠ಺ʹฒ΂ͯ੔ཧΛߦ͏ɽ͔͠͠ɼ௣ඌΒ΋‫͏ݴ‬Α͏ʹɼଟ͘ͷϢʔβ͸σεΫτοϓ΍ઙ͍֊૚ͷσΟϨΫτϦΛɼ৔ॴʹ‫͍ͨͮج‬৘ใ੔ཧ͕ศརͰ͋Δͱ͍͏ཧ༝Ͱ޷
ΜͰ࢖ΘΕΔ͕ɼίϯϐϡʔλը໘͸༗‫͋Ͱݶ‬ΓɼҰ౳஍͸͙͢ʹ࢖͍ਚ͘͞Εͯ͠·͏ [1]ɽͦͷͨΊɼ‫ػ‬ೳͷগͳ͘ɼ࢖༻ස౓ͷ௿͍؆୯ͳΞϓϦέʔγϣϯ͸ਂ͍֊૚ʹஔ͔Ε͕ͪʹͳͬͯ͠·͏ɽ͜͏ͨ͠؆୯ͳΞϓϦέʔγϣϯͰ͋ͬͯ΋ɼҰ؏ͯ͠ಉ͡खॱͰ‫ى‬ಈΛߦ͏ඞཁ͕͋Δɽ৔߹ʹΑͬͯ͸ελʔτϝχϡʔΛ։͖ɼΞϓϦέʔγϣϯΛ୳͔ͯ͠Β‫ى‬ಈΛ͢ΔΑ͏ͳɼ൥ࡶͳखॱ͕ඞཁʹͳΓɼϢʔβʹ༨‫ͳܭ‬ෛ୲͕͔͔ͬͯ͠·͏ɽຊ‫Ͱڀݚ‬͸ɼ࡞‫ۀ‬ͷຊ‫Ͱے‬͸ͳ͍͕ʮࠓͪΐͬͱ͚ͩ࢖͍͍ͨʯΞϓϦέʔγϣϯΛଈ࠲ʹ‫ى‬ಈ͠ɼ࢖༻ՄೳͳΧʔυΠϯλϑΣʔεΛఏҊ͢ΔɽΧʔυʹෳ਺ͷಋి෦Λ഑ஔ͠ɼλονύωϧσΟεϓϨ
Πʹ৐ͤΔ͜ͱͰΧʔυʹରԠͨ͠ΞϓϦέʔγϣϯ͕දࣔ͞ΕΔ (ਤ 1)ɽΧʔυࣗମ͕ೖग़ྗΛ࣋ͭΠϯλϑΣʔεͱͳΓɼΧʔυΛσΟεϓϨΠʹஔ
͍͍ͯΔؒͷΈΞϓϦέʔγϣϯΛ࢖༻ՄೳͳͨΊɼΧʔυΛஔ͘ɾ཭͢ͱ͍ͬͨಈ࡞ʹΑͬͯγʔϜϨ∗

Copyright is held by the author(s).
Kunihiro Kato, ໌࣏େֶେֶӃཧ޻ֶ‫ڀݚ‬Պ৽ྖҬ૑଄ઐ߈σΟδλϧίϯςϯπ‫ܥ‬, Homei Miyashita, ໌࣏େֶ૯߹਺ཧֶ෦ઌ୺ϝσΟΞαΠΤϯεֶՊ, ಠཱߦ੓๏ਓՊֶٕज़ৼ‫ߏػڵ‬, CREST- 163 -εͳ࡞‫ۀ‬ͷ੾Γସ͕͑ՄೳͱͳΔɽ·ͨɼΧʔυͱ͍͏෺ཧΦϒδΣΫτΛ༻͍Δ͜ͱͰɼPC ͷσΟεϓϨΠͷΑ͏ͳ‫ݶ‬ΒΕͨ‫͘ͳͰڥ؀‬ɼ޿ʑͱͨ͠
‫࣮ݱ‬ͷ‫Ͱڥ؀‬ͷΞϓϦέʔγϣϯ؅ཧ͕ՄೳͱͳΔɽ

ਤ 1. ΞϓϦέʔγϣϯྫ

2ؔ࿈‫ڀݚ‬

࣮෺ମ͔Βίϯϐϡʔλ಺ͷ৘ใ΁ΞΫηε͢Δ‫ͯ͠ͱڀݚ‬ɼ௣ඌΒ͸ IconSticker ΛఏҊ͍ͯ͠Δ[1]ɽόʔίʔυΛҹ࡮ͨ͠ϥϕϧΛ࣮ੈքͷ෺ʹషΓ෇͚ɼϦʔμͰಡΈऔΔ͜ͱͰɼͦΕʹରԠͤͨ͞ιϑτ΢ΣΞ΍ϑΝΠϧΛ‫ͼݺ‬ग़͢͜ͱ͕Ͱ͖Δɽ࣮෺ମΛհͨ͠ΠϯλϑΣʔεͷ‫ͯ͠ͱڀݚ‬ɼRekimoto Βͷ DataTiles ͕͋Δ [2]ɽฏ໘σΟεϓϨΠ
্ʹແઢλάΛຒΊࠐΜͩಁ໌ͳλΠϧΛ഑ஔ͠ɼͦΕͧΕͷλΠϧ͕ҟͳͬͨΠϯλϑΣʔεͱͯ͠࢖༻Ͱ͖Δɽ͜ΕΒͷλΠϧʹ͸ૢ࡞ΨΠυͱͯ͠ߔ͕۷ΒΕͨ΋ͷ͕͋ΓɼϢʔβ͸ߔʹԊͬͯϖϯσόΠεΛಈ͔͠ૢ࡞͕Ͱ͖Δɽຊ‫Ͱڀݚ‬͸ DataTiles
ͱಉ༷ʹɼΧʔυΠϯλϑΣʔεʹૢ࡞ΨΠυͱͳ
Δ݀Λۭ͚ɼͦΕʹԊͬͯλονΛߦ͍ૢ࡞͢Δɽ੨໦Β͸ෳ਺ಋి෦Λ࣋ͭԁ‫ܗ‬ͷ෺ཧΦϒδΣΫτΛ
༻͍ɼͦΕΛճ͢ૢ࡞ʹΑͬͯ৘ใͷ֦େɾॖখͳͲ
ͷૢ࡞Λߦ͏͘ΔΈΔΛఏҊ͍ͯ͠Δ [3]ɽManuela
Β͸ AR ϚʔΧΛऔΓ෇͚ͨಁ໌ͳλΠϧΛ༻͍ͨςʔϒϧτοϓΠϯλϑΣʔε Tangible Tiles ΛఏҊ͍ͯ͠Δ [4]ɽMalte Β͸൒ಁ໌ͳγϦίϯ੡ͷΩʔϘʔυ΍εϥΠμͳͲͷ෺ཧΦϒδΣΫτΛWISS 2013λονεΫϦʔϯ্ʹஔ͘͜ͱͰɼͦΕͧΕʹԠͨ͡ૢ࡞͕Մೳͳ SLAP ΛఏҊ͍ͯ͠Δ [5]ɽYvonneΒ͸ɼλϒϨοτ୺຤্ʹ෺ཧΦϒδΣΫτΛ৐ͤΔ͜ͱʹΑΔେ‫ܕ‬σΟεϓϨΠ༻ΠϯλϑΣʔεͱͯ͠ Tangible Remote Controllers ΛఏҊ͍ͯ͠Δ[6]ɽ͜ΕΒͷ‫Ͱڀݚ‬͸ɼςʔϒϧτοϓ‫ڥ؀‬΍ɼλϒϨοτ୺຤্Ͱͷ࡞‫ʹۀ‬෺ཧΦϒδΣΫτΛ༻͍
͍ͯΔ͕ɼຊ‫Ͱڀݚ‬͸Ұൠతͳ PC ‫Ͱڥ؀‬ͷ࢖༻Λ໨తͱ͍ͯ͠Δɽ

3ఏҊख๏ఏҊख๏Ͱ͸ΧʔυΛλονύωϧσΟεϓϨΠ
ʹ৐ͤΔ͜ͱͰɼΧʔυຖʹରԠͨ͠ΞϓϦέʔγϣϯΛදࣔ͢Δɽ֤Χʔυ͸ͦΕͧΕҟͳͬͨσβΠϯͷ͕݀੾Γൈ͔Ε͓ͯΓɼϢʔβ͸ΧʔυΛஔ͍
ͨ··͔݀ΒσΟεϓϨΠΛλονͯ͠ૢ࡞Λߦ͏ɽλονύωϧσΟεϓϨΠʹ৐ͤͨΧʔυͷҐஔͷ‫ݕ‬ग़ͱࣝผΛߦ͏ͨΊɼਤ 2 ͷΑ͏ʹෳ਺ͷಋి෦ΛΧʔυʹ഑ஔ͠ɼͦΕΒશͯΛ઀ଓ͢ΔɽϢʔβ͕ΧʔυΛσΟεϓϨΠʹஔ͍ͨ··ɼද໘ͷಋి෦ʹ৮ΕΔ͜ͱͰΧʔυͷҐஔΛ‫ݕ‬ग़͢ΔɽΞϓϦέʔγϣϯ͸ɼΧʔυཪ໘ʹ഑ஔ͞Εͨ 4 ఺ͷಋి෦શ͕ͯσΟεϓϨΠʹ઀৮͍ͯ͠Δঢ়ଶͷ࣌ͷΈදࣔ͞ΕΔɽ·ͨɼ͜ͷ 4 ఺ͷಋి෦ͷ഑ஔύλʔϯʹΑͬͯΧʔυͷࣝผΛߦ͍ɼͦΕͧΕͷΧʔυʹରԠͨ͠ΞϓϦέʔγϣϯ͕දࣔ͞ΕΔɽ
Ϣʔβͷλονૢ࡞෦ͱͯ͠ɼΧʔυͷ಺ଆΛҰ෦੾Γൈ͍ͨɽ͜ͷࡍɼ֤ΧʔυʹׂΓ౰ͯΒΕͨΞϓϦέʔγϣϯͷΠϝʔδʹ߹ΘͤͨσβΠϯͰΧʔυΛ੾Γൈ͘ɽ͜ΕʹΑΓϢʔβ͸Χʔυͷ‫ݟ‬ͨ໨͔ΒׂΓ౰ͯΒΕͨΞϓϦέʔγϣϯΛ͋Δఔ
౓൑அ͢Δ͜ͱ͕Ͱ͖Δɽ

ਤ 2. ΞϓϦέʔγϣϯΧʔυ

4ΞϓϦέʔγϣϯྫϓϩτλΠϓͱͯ͠ి୎ɼϖΠϯτɼίϯτϩʔϧύωϧεϥΠμͷ 3 छྨͷΞϓϦέʔγϣϯΛ࣮૷ͨ͠ɽి୎ΞϓϦ (ਤ 1a) Ͱ͸ɼϘλϯ෦ͱͯ͠ 4*4 Ϛεʹ݀Λۭ͚ɼ਺஋දࣔ෦ͱͯ͠௕ํ‫ܗ‬ͷ݀Λۭ͚ͨΧʔυΛ༻͍ΔɽΧʔυΛσΟεϓϨΠʹ৐ͤΔ- 164 -

͜ͱͰɼϘλϯ෦ͷ݀ʹ਺஋΍ԋࢉࢠͳͲͷϘλϯ͕දࣔ͞ΕɼλονʹΑΓೖྗ͕Ͱ͖Δɽ·ͨɼΞϓϦऴྃ࣌ʹ‫݁ࢉܭ‬ՌΛΫϦοϓϘʔυʹ‫ه‬࿥͢Δɽ
ϖΠϯτΞϓϦ (ਤ 1b) Ͱ͸ɼ௕ํ‫݀ʹܗ‬Λۭ͚ͨ࿮‫ܕ‬ͷΧʔυΛ༻͍ΔɽϢʔβ͸Χʔυͷ࿮಺ʹࣗ༝ʹετϩʔΫΛඳ͘͜ͱ͕Ͱ͖ɼ؆୯ͳखॻ͖
ϝϞΞϓϦͱͯ͠࢖༻Ͱ͖ΔɽΧʔυΛσΟεϓϨ
Π͔Β཭͠ɼΞϓϦέʔγϣϯΛऴྃ͢Δࡍɼඳըͨ͠಺༰Λը૾ͱͯ͠อଘ͢Δɽ
ίϯτϩʔϧύωϧεϥΠμ (ਤ 1c) Ͱ͸ɼ਺Χॴͷࡉ௕͍݀Λۭ͚ͨΧʔυΛ༻͍Δɽ͜ͷΧʔυʹۭ͚͕ͨ݀ͦΕͧΕεϥΠμͱͳ͓ͬͯΓɼΧʔυ಺ͷ݀ʹԊͬͯσΟεϓϨΠΛλον͠εϥΠμΛಈ͔͢ɽ͜ͷεϥΠμʹΑΓɼPC ͷԻྔɼσΟεϓϨΠً౓ͷௐ੔Λߦ͏͜ͱ͕Ͱ͖Δ.

5

ಋిੑΠϯΫͷಋೖࠓճࢼ࡞ͨ͠ΞϓϦέʔγϣϯΧʔυ͸ɼࢴ੡ͷΧʔυʹಋి෦ΛషΓ෇͚࣮ͯ૷͕ͨ͠ɼ‫ݱ‬ঢ়ͷ໰୊఺ͱͯ͠ΧʔυΛ࡞੒͢Δख͕͔͔ؒΔ͜ͱ͕‫ڍ‬͛ΒΕΔɽͦ͜ͰɼΧʔυͷ࡞੒ʹಋిੑΠϯΫͱΠϯΫδΣοτϓϦϯλͷಋೖΛ‫ݕ‬౼͍ͯ͠Δɽಋ
ిੑΠϯΫΛ༻͍ͨϓϦϯλʹΑΓग़ྗ͞ΕͨΧʔυΛࢦࣔ௨Γʹ੾Γൈ͍ͨΓɼંΓ‫ͨ͛ۂ‬Γ͢Δͩ
͚Ͱ༰қʹΧʔυͷ࡞੒͕Ͱ͖Δͱߟ͑ΒΕΔɽ

ࢀߟจ‫ݙ‬[1] ௣ඌ Ұ࿠, ඒഅ ྄ٛ: IconStickerɿࢴΞΠίϯʹ
ΑΔ৘ใ੔ཧ, ίϯϐϡʔλιϑτ΢ΣΞ Vol.16,
No.6, pp.24-32, 1999.
[2] Jun Rekimoto, Brygg Ullner, Haruo Oba:
DataTiles: AModular Platform for Mixed Physical and Graphical Interactions, Proceedings of
CHI’01, pp.269-276, 2001.
[3] ੨໦ ྑี, ‫ٶ‬Լ ޿ເ, Ҫ‫ ݪ‬խߦ, େ໺ ݈඙, ઍ໌༟, খྛ ູ, ‫ޗ৻ ڸ‬: ͘ΔΈΔ: ෳ਺ಋి෦Λ΋ͭ࿮‫ܕ‬෺ཧΛ༻͍ͨλϒϨοτૢ࡞, ใॲཧֶձ
‫ڀݚ‬ใࠂ HCI, ώϡʔϚϯίϯϐϡʔλΠϯλϥ
Ϋγϣϯ‫ڀݚ‬ձใࠂ HCI-144, pp.1-8, 2011.
[4] Manuela Waldner, Jorg Hauber, Jurgen Zauner, Michael Haller, Mark Billinghurst: Tangible Tiles: Design and Evaluation of a Tangible User Interface in a Collaborative Tabletop
Setup, Proceedings of OZCHI’06, pp.151-158,
2006.
[5] Malte Weiss, Julie Wagner, Roger Jennings,
Yvonne Jansen, Ramsin Khoshabeh, JamesD.Hollan, and Jan Borchers: SLAP widgets:bridging the gap between virtual and physicalcontrols on tabletops, Proceedings of CHI’09,
pp.481-490, 2009.
[6] Yvonne Jansen, Pierre Dragicevic, Jean-Daniel
Fekete: Tangible Remote Controllers for WallSize Displays, Proceedings of CHI’12, pp.28652847, 2012.

WISS2013

擬音語アニメーションによる動画音響の可視化手法
王 方舟

柏野 邦夫

永野 秀尚

五十嵐 健夫∗

概要.
動画に含まれる音の情報は，動画の視聴体験を構成する重要な要素である．一方で，実際に視聴者が動画を視聴する際は，状況によっては必ずしも音を伴って視聴できない場合が存在する．従来，このような状況下で音の情報を視覚的に補う手段としては字幕が用いられてきたが，そのほとんどが人の発した声を文字に書き起こしたものであり，声以外の一般的な音の情報に関する表現力は非常に乏しいのが現状である．
本稿では，動画中に生起する音の種類を自動で判別し，擬音語（オノマトペ）を用いて可視化する手法を提案する．生成された擬音語は音の変化に合わせてアニメーションされる．これにより，動画中に含まれる一般的な音の種類およびそのダイナミクスを自然な形で可視化し，視聴者に伝えることが可能になる．

1

はじめに

多くの動画コンテンツにおいて，音は重要な役割を担う．人の話すセリフやナレーションなどの音声情報はそれ自体が不可欠な情報であるし，それ以外の音であっても，例えばカーチェイスのシーンでのエンジンの唸り，サッカーの試合のシーンでの人々の歓声など，様々な場面において音は視聴者の感情に影響を及ぼし，映像と合わせて一つの視聴体験を構築する．一方で，視聴者が動画を視聴する状況は様々であり，必ずしも常に音が聞き取れるとは限らない．そのような状況下では，動画本来の視聴体験が大きく損なわれることがある．
従来，このような状況下で音の情報を伝達する手段としては，字幕が使われてきた．一般的に使われている字幕は，静的なテキストをシーンの進行に合わせて画面下に表示するものであるが，1) 人手による事前の準備が必要であり，2) 人の声以外の効果音や環境音に対する表現力が低く，3) 音の生起のタイミングや変化を表現できない，などの問題点がある．特に，効果音や環境音については，単に「ガラスの割れる音」など音の状況を説明する文字列を配置するものが多く，音が本来持つ視聴体験を高める
働きは失われてしまっている．
この問題を解決するため，本研究では，動画中に生起する音の種類を認識して擬音語に変換することによって可視化し，さらに音の変化に合わせて適切にアニメーションする手法を提案する．提案手法は入力された動画から音の情報を自動で認識するために人手の介在が不要である．さらに音を自然な視覚表現である擬音語に変換した上で，音の変化に合わ

図 1. 擬音語アニメーションによる動画音響の可視化例

せて適切にアニメーションすることにより，音のな
い状況下でも豊かな視聴体験を提供することを可能
にする．

2

関連研究

音の種類を識別するための研究は従来より多くなされてきた [2] これに対し，石原ら [1] は擬音語の表現力に着目し，環境音を直接擬音語に変換する手法を提案している．山本ら [3] は，環境音を直接擬音語に変換し，音の大きさや質に応じた適切なフォントを用いて可視化する手法を提案している．一方で山本らの提案手法は極めて限定された実験環境を対象としており，単発の短音のみを対象とし，一度生成された擬音語表示は音の変化に対して静的であるなど，実在の動画に対して適用し得るものではない．

3

システム設計本研究で実装したシステムは，自動車のレース動画を対象とし，動画中のエンジン音，およびドリフ
トやブレーキの際に発生するスキール音の 2 種類の音を自動認識して擬音語アニメーションを付与するものである．生成する擬音語の種類およびアニメー

Copyright is held by the author(s).
∗Houshu Oh and Takeo Igarashi, 東京大学大学院 情報
理工学系研究科 コンピュータ科学専攻, Kunio Kashinoand Hidehisa Nagano, NTT コミュニケーション科学基礎研究所.

- 165 -WISS 2013

① 音カテゴリの識別

尤度

特徴ベクトル

...

へ変換

入力動画

② 音量変化の推定

エンジン音

...

音を細かく分割③ アニメーション生成
音カテゴリ別の音量変化

識別器

動画から抽出した音

特徴ベクトル

時間ごとの尤度

出力動画

図 3. 音カテゴリの識別方法

図 2. アルゴリズムの概要

ションのデザインは，考えうる最もシンプルな形として，1) 基本的な音の種類 (エンジン音またはスキール音) に応じてあらかじめ用意された擬音語画像を，
2) 映像の固定位置に表示し，3) 音の大きさに合わせた拡大および縮小アニメーションを行うものとする．

4

時間

...

音カテゴリ別の尤度

スキール音

アルゴリズム

提案するアルゴリズムは，音付きの動画を入力とし，擬音語アニメーションが付与された動画を出力するものである．アルゴリズムは大きく分けて，1)
音カテゴリの識別，2) 音量変化の推定，3) 擬音語
アニメーションの生成，の 3 つのステップをたどる(図 2)．
アルゴリズムはまず，入力された動画の音の種類を識別する．この際に用いる識別器は，ラベル付きの音データを用いて SVM で機械学習を行うことで事前に構築しておく．構築する識別器は，0.75 秒の音の断片から生成された特徴ベクトルを入力とし，その音の断片がどの音カテゴリに属するかの尤度を計算するものである．入力された動画の音データを
時間方向に細かく分割し，各断片を特徴ベクトルに変換して，構築した識別器に入力として与えること
により，動画の時系列に沿って音のカテゴリ別の尤度が計算される (図 3)．
アルゴリズムは次に，音のカテゴリ別に音量変化を推定する．推定は，前のステップで計算された音
カテゴリ別の尤度に，元の音の音量を掛け合わせる
ことによって行われる．
アルゴリズムは最後に，推定されたカテゴリ別の音量変化をもとに擬音語アニメーションを生成する．
アルゴリズムは入力動画を 1 フレームずつ見ていき，それぞれのフレームに対応する音のカテゴリ別音量を前ステップの結果から得る．次に，音量が一定の値以上を超えた音のカテゴリについて，擬音語画像を生成する．現実装では，システムが予め音の種類の数だけ準備した擬音語画像をそのまま用いる．最後に，生成した擬音語を対応する音カテゴリの音量の大きさに合わせて拡大・縮小し，映像に埋め込む．

- 166 -

5

議論と今後の課題

環境音から擬音語を生成する研究は以前よりなされてきたが，その多くは入力となる音を日本語に直接変換することを目的としている [1]．このような手法は擬音語表現が豊富な日本語に対しては有効であるが，一方で他の言語に適用しにくいというスケー
ラビリティの問題や，音の混合に弱いという問題を抱えている．本稿で提案した手法は音を言葉に直接変換するのではなく，音の「種類」を認識し，対応する擬音語に変換するという手法を採用している．
これにより，言語的な表現力を多少犠牲にしつつも，多言語拡張へのスケーラビリティと音の混合に対す
る一定のロバスト性を確保している．
今後の課題としては，音源物体の位置に合わせた擬音語の適切な配置がある．これは，一般物体認識の手法や Saliency 解析などを用いて行うことが考えられる．音の変化をより自然に捉えたアニメーショ
ンの生成も課題である．例えば，音量の起伏を複数の立ち上がりと減衰に分割することで，同一カテゴ
リの音についても複数の音がかぶさりあって生起している様子を捉えることが可能になると考えられる．
さらにはアニメーションの要素として，拡大・縮小だ
けではなく，ゆるやかな減衰部分についてはゆっく
りフェードアウトさせるなどといったより自然なア
ニメーションも実現できるようになると考えられる．

参考文献[1] K. Ishihara, T. Nakatani, T. Ogata, and
H. G. Okuno.
Automatic Sound-Imitation
Word Recognition from Environmental Sounds
focusing on Ambiguity Problem in Determining
Phonemes. PRICAI 2004: Trends in Artificial
Intelligence. Lecture Notes in Artificial Intelligence, 3157:909–918, 2004.
[2] D. Li, I. K. Sethi, N. Dimitrova, and T. McGee.
Classification of general audio data for contentbased retrieval. Pattern Recognition Letters,
22(5):533–544, 2001.
[3] 山本貴史, 松原正樹, 斎藤博昭. 擬音語と書体表
現を用いた環境音の可視化. 芸術科学会論文誌,
11(1):1–11, 2012.

WISS2013μϯεύϑΥʔϚϯεʹ͓͚Δ
2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯΛ༻͍ͨୂ‫ܗ‬࿅शࢧԉ
౔ా मฏ

ࣉా ౒

௩ຊ ণ඙∗

֓ཁ. ۙ೥ɼμϯεελδΦͷ૿Ճ΍ΩοζμϯεͷྲྀߦͳͲɼμϯεύϑΥʔϚϯεʹΑΔ਎ମද‫ݱ‬ೳྗ΍ϦζϜ‫ײ‬ͷ޲্ʹ஫໨͕ू·͍ͬͯΔɽμϯεͷॳ৺ऀͰ΋େਓ਺ͰμϯεύϑΥʔϚϯεΛ൸࿐͢Δ‫ػ‬ձ͕૿͍͑ͯΔ͕ɼෳ਺ਓͰͷμϯεύϑΥʔϚϯεͰ͸ԻָͱৼΓ෇্͚͕ख͘ϦϯΫ͍ͯ͠Δ΋ͷͰ͋ͬͯ΋ɼୂ‫่͕ܗ‬Ε͍ͯΔͱμϯεύϑΥʔϚϯεͱͯ͠ͷ࣭͕େ෯ʹ௿Լͯ͠͠·͏ɽͦͷͨΊμϯεύϑΥʔϚϯεʹ͓͍ͯɼୂ‫ܗ‬ͷ࿅श͸ৼΓ෇͚ͷशಘͱಉ༷ʹॏཁͳཁૉͱͳ͍ͬͯΔɽୂ‫ܗ‬Λ্ख͘ັͤΔͨΊʹ͸ɼόϥ͖ͭͳ͘ਓͱͷִؒΛอͭ͜ͱͱɼಉ͡λΠϛϯάͰಈ͘͜ͱΛҙࣝ͠ͳ͚Ε͹ͳΒͳ͍ɽ͔͠͠࿅शͷࡍʹҰਓͰ΋μϯαʔ͕͚ܽΕ͹ɼୂ‫ܗ‬ͷద౰ͳִؒΛ௫Ή͜ͱ͕ࠔ೉ͱͳ
Δɽͦ͜Ͱઌߦ‫[ ڀݚ‬1] ʹ͓͍ͯɼୂ‫ܗ‬࿅शʹ͓͚ΔҰ෦ͷμϯαʔ͕͚ܽͯ΋εϜʔζʹ࿅शΛߦ͏ͨΊͷࣗ૸‫ܕ‬εΫϦʔϯΛ༻͍ͨμϯε࿅शࢧԉγεςϜΛఏҊͨ͠ɽ͔͠͠ɼࣗ૸‫ܕ‬εΫϦʔϯ͸ෆ‫ن‬ଇͳҠಈʹΑΔա৒ͳଘࡏ‫ײ‬ɼεΫϦʔϯͱͷিಥͷ‫ڪ‬ΕͳͲͷཁҼʹΑΓਓͷҠಈΛඞཁҎ্ʹ੍‫ͨͨ͠ݶ‬ΊɼਓͱགྷΔࡍͷҐஔͷ࠶‫ݱ‬ੑ͕௿͔ͬͨɽͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼিಥͷ‫ڪ‬Ε͕গͳ͘ΑΓεΫϦʔϯΛਖ਼֬ʹҠಈͤ͞ΔͨΊʹɼεΫϦʔϯͷૉࡐ͕ॊΒ͔ͯ͘΋ྑ͘ɼҠಈํ޲͕ͣΕͳ͍ΧʔςϯϨʔϧʹண໨͠ɼө૾͕౤Ө͞Εͨ 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͱགྷΔख๏ΛఏҊ͢Δɽ

1

͸͡Ίʹ

μϯεύϑΥʔϚϯεΛ্ख͘ັͤΔͨΊʹ͸ɼόϥ͖ͭͳ͘ਓͱͷִؒΛอͭ͜ͱͱɼ࣍ͷୂ‫΁ܗ‬εϜʔζʹҠߦ͢Δ͜ͱΛҙࣝ͠ͳ͚Ε͹ͳΒͳ͍ɽ͔͠͠࿅शͷࡍʹҰਓͰ΋μϯαʔ͕͚ܽΕ͹ɼୂ‫ܗ‬ͷద౰ͳִؒΛͱΔ͜ͱ͕ࠔ೉ͱͳΔɽ͜Ε·ͰʹμϯεύϑΥʔϚϯεΛࢧԉ͢Δ༷ʑͳ‫ߦ͕ڀݚ‬ΘΕ͍ͯΔɽϞʔγϣϯΩϟϓνϟٕज़Λ༻͍ͨख๏ [2] ΍‫׳‬ੑηϯαΛ༻͍ͨख๏ͳͲৼΓ෇͚ͷशಘΛࢧԉ͢Δ΋ͷ͕‫͛ڍ‬ΒΕΔɽ͜Ε·ͰʹμϯεύϑΥʔϚϯεΛࢧԉ͢Δ༷ʑͳ‫ߦ͕ڀݚ‬ΘΕ͍ͯΔɽϞʔγϣϯΩϟϓνϟٕज़Λ༻͍ͨख๏΍‫׳‬ੑηϯαΛ༻͍ͨख๏ [3] ͳͲৼΓ෇͚ͷशಘΛࢧԉ͢Δ΋ͷ͕‫͛ڍ‬ΒΕΔɽ͔͠͠ɼୂ‫ܗ‬࿅शʹண໨ͨ͠‫ڀݚ‬͸ߦΘΕ͍ͯͳ͍ɽͦ͜Ͱઌߦ‫[ ڀݚ‬1] Ͱ͸ɼୂ‫ܗ‬࿅शʹ͓͚ΔҰ෦ͷμϯαʔ͕͚ܽͯ΋εϜʔζʹ࿅शΛߦ͏ͨΊͷࣗ૸‫ܕ‬εΫϦʔϯΛ༻͍ͨμϯε࿅शࢧԉγεςϜΛఏҊͨ͠ɽ͔͠͠ɼࣗ૸‫ܕ‬εΫϦʔϯ͸ෆ‫ن‬ଇͳҠಈʹΑΔա৒ͳଘࡏ‫ײ‬ɼεΫϦʔϯͱͷিಥͷ‫ڪ‬ΕͳͲͷཁҼʹΑΓਓͷҠಈΛඞཁҎ্ʹ੍‫ͨͨ͠ݶ‬ΊɼਓͱགྷΔࡍͷҐஔͷ࠶‫ݱ‬ੑ͕௿͔ͬͨɽͦ͜Ͱຊ‫Ͱڀݚ‬͸ɼিಥͷ‫ڪ‬Ε͕গͳ͘ΑΓεΫϦʔϯΛਖ਼֬ʹҠಈͤ͞ΔͨΊʹɼεΫϦʔϯͷૉࡐ͕ॊΒ͔ͯ͘΋ྑ͘ɼҠಈํ޲͕∗ਤ 1. 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷ഑ஔɼҠಈํ޲

ද 1. ࣗ૸‫ܕ‬εΫϦʔϯͱͷҧ͍
2 ࣠ҠಈՄೳͳ
ిಈΧʔςϯ

ܽ఺େ࢓ֻ͚ෳ਺ਓͰͷར༻͸೉͍ͣ͠Εͳ͍ΧʔςϯϨʔϧʹண໨͠ɼө૾͕౤Ө͞Ε
ͨ 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͱགྷΔख๏ΛఏҊ͢ΔɽҎ߱ɼ2 ষͰ͸ 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷઃ‫͍ͯͭʹܭ‬ड़΂ɼ3 ষͰ࣮૷ʹ͍ͭͯड़΂ɼ࠷‫ޙ‬
ʹ 4 ষͰ·ͱΊΛߦ͏ɽ2

Copyright is held by the author(s).
Shuhei Tsuchida and Masahiko Tsukamoto, ਆ‫ށ‬େֶେֶӃ޻ֶ‫ڀݚ‬Պ, Tsutomu Terada, ਆ‫ށ‬େֶେֶӃ޻ֶ‫ڀݚ‬Պ / Պֶٕज़ৼ‫͚͕͖͞ߏػڵ‬ར఺੍‫͕ޚ‬؆୯
ߴ଎ҠಈՄೳ

2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷઃ‫ܭ‬2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷ഑ஔɼҠಈํ޲ʹ͍ͭͯʹਤ 1 ʹࣔ͢ɽ2 ຊͷΧʔςϯϨʔϧΛฏߦ- 167 -WISS 2013
ද 2. ඃ‫ ऀݧ‬3 ਓͷ‫ࠩ཭ڑ‬ͷฏ‫ۉ‬஋ (mm)࣮‫ݧ‬൪߸ฏߦҠಈ઀ۙҠಈ

1 ਓͰགྷΔ56
74

ࣗ૸ϩϘοτͱགྷΔ
150
90ϓϩδΣΫλө૾ͱགྷΔ
83
188

ʹఱҪʹऔΓ෇͚ɼͦΕΒʹର͠ਨ௚ʹ৽ͨʹ 1 ຊͷΧʔςϯϨʔϧΛઌఔͷ 2 ຊͷΧʔςϯϨʔϧͰ௻Δ͍ͯ͠Δɽ͜ΕʹΑΓΧʔςϯΛ 2 ࣠ʹҠಈͤ͞Δ͜ͱ͕Ͱ͖Δɽࣗ૸‫ܕ‬εΫϦʔϯͱͷҧ͍Λද
1 ʹࣔ͢ɽΧʔςϯϨʔϧ͕‫ݻ‬ఆ͞Ε͓ͯΓҠಈํ޲͕ͣΕͳ͍ͨΊෆ‫ن‬ଇͳಈ͖Λ཈͑ΒΕΔ͜ͱɼ
্͔ΒεΫϦʔϯΛ௻Δͨ͢ΊεΫϦʔϯΛ‫ݻ‬ఆ͢
Δ࿮Λඞཁͱͤͣিಥͷࡍʹոզͷ‫ڪ‬Ε͕ܰ‫͖Ͱݮ‬Δ͜ͱɼ·ͨচΛ૸Δࣗ૸ϩϘοτΛඞཁͱ͠ͳ͍
ͨΊΑΓ͍ۙ‫͢Ͱ཭ڑ‬Εҧ͏Α͏ͳ࿅श͕Ͱ͖Δɽ͞ΒʹεΫϦʔϯͷॏྔ͕‫ͨͨͬݮ‬Ίʹࣗ૸‫ܕ‬εΫϦʔϯҎ্ͷεϐʔυΛग़͢͜ͱ͕Ͱ͖ɼॏྔ͕͋
ΔϞʔλ͝ͱҠಈͤ͞Δඞཁ͕ͳ͍ͨΊߴग़ྗͷ΋ͷ͕ར༻Ͱ͖ߋͳΔεϐʔυͷ্ঢ͕‫ظ‬଴Ͱ͖ΔͳͲͷར఺͕‫͛ڍ‬ΒΕΔɽ͔͠͠ɼࣗ૸‫ܕ‬εΫϦʔϯͱൺ΂ΧʔςϯϨʔϧΛఱҪ౳ʹઃஔ͢ΔͳͲ࢓ֻ͚
͕େ͖͘ͳΔ͜ͱɼෳ਺ਓͰͷར༻ํ๏͕‫ݶ‬ఆ͞Εͯ͠·͏͜ͱͳͲͷܽ఺͕‫͛ڍ‬ΒΕΔɽ͜ΕΒͷཧ༝ΑΓɼෳ਺ਓͰͷར༻ʹ͍ͭͯ͸‫ݶ‬ఆ͞ΕΔ΋ͷͷ 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯ͸ࣗ૸‫ܕ‬εΫϦʔϯͷ໰୊ΛղܾͰ͖Δ͚ͩͰ͸ͳ͘ɼࣗ૸‫ܕ‬εΫϦʔϯͰ͸ར༻͠ʹ͍͘࿅श΋Ͱ͖Δͱߟ͑ΒΕΔɽ·ͨɼΧʔςϯʹΑΔӨ‫ڹ‬Λௐ΂ΔͨΊʹߟ͑ΒΕΔ
ͦΕͧΕͷୂ‫ܗ‬࿅शख๏ʹ͓͍ͯɼ࣮ࡍʹμϯαʔͱೋਓͰགྷΔࡍͷ‫͔͏Ͳ͔͍ۙʹ֮ײ‬ධՁͨ͠ɽ݁
ՌΛද 2 ʹࣔ͢ɽ਺஋͕খ͍͞ఔೋਓͰགྷΔࡍͷҠಈʹ͍ۙͱ͍͑Δɽ

3

2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷ࣮૷࣮૷ͨ͠ 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷ֎‫؍‬Λਤ
2 ʹࣔ͢ɽԣํ޲ͷҠಈʹ͍ͭͯ͸φϏΦࣾͷిಈΧʔςϯϨʔϧ TV24 ͷճస෦෼ΛՃ޻ͨ͠Χʔςࣗ૸‫ܕ‬εΫϦʔϯͱགྷΔ
204109

ΧʔςϯͱགྷΔ
150
63

ਤ 2. 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷ֎‫؍‬

4

͓ΘΓʹ

ຊ࿦จͰ͸ɼઌߦ‫ڀݚ‬ΑΓಘΒΕͨ஌‫͔ݟ‬Βߟ͑ΒΕΔ 2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯͷར఺ʹ͍ͭͯड़΂ɼࣗ૸‫ܕ‬εΫϦʔϯͷ࣮૷Λߦͬͨɽࠓ‫ޙ‬γεςϜͷߋͳΔվળΛ໨ࢦ͠ɼෳࡶͰ௕͍ʹৼΓͰͷ࣮‫ݧ‬Λߦ͍ɼ2 ࣠ಈ࡞ՄೳͳిಈΧʔςϯʹΑΔӨ
‫͍ͯͭڹ‬ௐࠪ͢Δɽ·ͨɼୂ‫ܗ‬࿅शʹ͓͍ͯఏࣔ͢
Δଘࡏ‫ʹײ‬ΑΔৼΓͳͲ΁ͷӨ‫ڹ‬Λࡉ͔͘ௐࠪ͢Δ
͜ͱΛ໨ࢦ͢ɽ

ࢀߟจ‫ݙ‬

ϯϨʔϧΛར༻ͨ͠ɽճస෦෼͸ϞʔλͱΧʔςϯ͕ಈ࡞͢Δ෦෼ͱͷΩΞൺ͕௿͔ͬͨͨΊʹɼϞʔλͷճస͕௚઀ΧʔςϯϨʔϧΛಈ࡞͢Δ෦෼ͱ‫ܨ‬
͕ΔΑ͏Ճ޻ͨ͠ɽ͜ΕʹΑΓਓͷาߦ଎౓ఔ౓ͷεϐʔυͰҠಈͤ͞Δ͜ͱ͕Ͱ͖Δɽલ‫ͭʹ޲ํޙ‬͍ͯ͸ԣҠಈʹ࢖༻ͨ͠ిಈΧʔςϯϨʕϧͷ྆୺ʹਨ௚ʹ 2 ͭͷΧʔςϯΛऔΓ෇͚Δ͜ͱʹΑͬͯɼిಈΧʔςϯϨʔϧࣗମΛҠಈͤ͞Δ͜ͱʹΑͬͯՄೳʹ͍ͯ͠Δɽલ‫͍ͯͭʹ޲ํޙ‬͸‫ࡏݱ‬खಈͰͷҠಈͷΈͱͳ͓ͬͯΓɼࠓ‫ޙ‬ԣํ޲ͱಉ༷ʹϞʔλΛऔΓ෇͚ࣗಈԽΛ໨ࢦ͢ɽεΫϦʔϯ͸෩͕ൈ͚΍͍͢Α͏ϨʔεΧʔςϯΛ࢖༻͍ͯ͠Δɽ

- 168 -

[1] S. Tsuchida, et al.: A System for Practicing
Formations in Dance Performance Supported by
Self-Propelled Screen, Proc. of tthe 4th Augmented Human International Conference (AHI
’13), pp. 178–185 (Mar. 2013).
[2] L. Deng, et al.: Real-Time Mocap Dance Recognition for an Interactive Dancing Game, 2011
IEEE Computer Society Conference on Computer
Animation and Virtual Worlds (CASA ’11) Vol.
22, pp. 229–237 (Apr. 2011).
[3] ྛ ‫޺و‬, ඌ಺ཧ‫෉ل‬: ϞʔγϣϯΩϟϓνϟͱՃ଎౓ηϯαΛ༻͍ͨৼΓͷ࿅शࢧԉ, ి‫ֶؾ‬ձ࿦จࢽ E, Vol. 129, No. 6, pp. 173–180 (June 2009).

WISS2013

モチベーションの維持を考慮したピアノ学習支援システム
福家 悠人

竹川 佳成

柳 英克∗

概要. 楽器の演奏技術の向上には多大な時間や労力を必要とするため，敷居の高さに利用を断念したり，習熟効率の低さから挫折してしまう演奏者が多い．鍵盤演奏の敷居を下げるために，学習支援システムが提案されてきたが，学習者のミスに対して厳格で，打鍵ミスが続くと次に進めないためフラストレーションがたまり練習へのモチベーションが下がってしまう．そこで，本研究では，モチベーションの維持を考慮したピアノ学習支援システムの構築をめざす．

1

はじめに

ピアノ演奏では，譜読み，指示されている鍵への正確な打鍵，適切な運指 (指使い)，リズム感覚，打鍵の強弱，テンポなど，さまざまな技術が求められ，それらの修得には長期間の基礎的な練習を必要とす
る．ピアノ演奏には多大な時間と労力を必要とするため，敷居の高さに利用を断念したり，習熟効率の低さから挫折してしまう演奏者が後を絶たない．従来システムでは学習者がミスをしないように細心の注意を払わなければならず，打鍵ミスが重なると次の音符に進めない状態が続きフラストレーションがたまり学習者のモチベーション (熟達に向けて練習を続けたいと思う気持ち) が下がってしまう．
そこで，本研究ではモチベーションの維持を考慮したピアノ学習支援システムの構築をめざす．

2

関連研究

これまでピアノ学習の支援につながる試みはいくつか行われている．ビデオや音声による模範演奏の提示する，Piano Tutor[2] や打鍵すべき鍵，運指，手本映像を表示するキーボードやソフトウェア [1, 3]がある．これらはいずれも打鍵情報から演奏を評価し学習目的に必要な情報を提示しているが，本研究で提案するミスの許容度は考慮されていない．
演奏の敷居を下げる試みとして竹内らの Two Finger Piano[4] は，どの鍵を弾いても常に正しい音が出力される．これは，本研究で提案するミス許容度をすでに導入している事例であり，あたかも演奏しているように見せることができる．しかし，本研究のように段階的にミス許容度を変化させ演奏を学習するといった学習は考慮していない．

3

設計

3.1

システム構成提案する学習支援システムのシステム構成を図 1に示す．演奏者の前面にディスプレイを設置し，ディスプレイに楽譜や仮想鍵盤を提示する．また，MIDI
情報 (打鍵位置や打鍵強度) を入力とする．ディスプ
レイに表示された仮想鍵盤と実際の MIDI キーボー
ドとのサイズは一致しているため，仮想鍵盤の鍵上に提示された情報が MIDI キーボードのどの鍵と対応しているか直観的に理解できる．

3.2

学習方法

提案する学習方法は許容範囲内の打鍵ミスであれ
ば，学習者が本来弾くべき位置と異なる鍵を打鍵したとしても，練習している楽曲の音高データベース
から正しい音高データを取得し，ベロシティ・打鍵
タイミング・離鍵タイミングを残したままで，音高のみ正しい音高に差し替えて出力する．これにより，学習者が正確に打鍵できない低い熟達度であっても，完成度の高い演奏を行えるためモチベーションを維持しながら練習に取り組める．打鍵位置がミスの許容範囲外であった場合，誤りであることを意味する
効果音を出力することで学習者が誤りを認識できるようにする．なお，楽曲として単音の旋律を想定している．
学習モードの許容度が低くなるにつれ，学習者の打鍵ミスを許容する範囲が狭くなる．以下で説明する学習モードは初心者に向けて，順に許容範囲を狭くした学習モードである．
エニーキーモード エニーキーモードでは，学習者はどの鍵を打鍵したとしても正しい音高の音が出力されるモードである．ベロシティ，打鍵タイミン
グ，離鍵タイミングは学習者の操作がそのまま反映

1 章で述べたように，本研究ではピアノ初心者を対象としており，五線譜やシステムが生成する補助∗情報を活用しながら学習者はある楽曲を一から練習し，できるだけモチベーションを維持しながら習熟し，最終的にシステムの補助なしで演奏できるようになることをめざす．

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

鍵幅可変モード 鍵幅可変モードは本来打鍵する
べき打鍵位置および鍵の色 (白鍵か黒鍵か) を基準に指定した鍵数範囲内であれば正しい打鍵とみなし，正しい音高を出力する．例えば，許容範囲が± 1 であれば，本来打鍵すべき位置の両隣りまでを許容範囲とする．学習者は熟達するにつれ許容範囲を下げる．許容範囲 0 が，光る鍵盤 [1] と同じ難度になる．
学習者が前述したモードの練習後，鍵幅可変モード
で練習することを想定しており，前述したモードは
いずれも，現在の打鍵位置を基準に正誤判定を行っていたが，鍵幅可変モードは，楽譜上の音符に対応する鍵を基準に正誤判定を行う．

3
8

1234
!" # $%&'(!"/0891:;<)) $%/0)*+,+ -.

*+,+ 53637

図 1. システム構成される．すでに聞き慣れた楽曲を練習している場合，学習者はベロシティ，打鍵タイミング，離鍵タイミ
ングを十分に理解しており，単音の旋律であるため，
少しの練習で音長を制御しながら演奏できるようになる．これにより学習者は完成系をイメージでき，練習するモチベーションが向上する．ピアノ初心者が楽譜をみながら，楽譜通りの打鍵位置を正確に打鍵することが大変困難であることから，最も許容度の低いモードとして打鍵タイミングだけを意識できるエニーキーモードを提案する．
カラーモード カラーモードは，学習者が黒鍵の演奏に慣れるために有効なモードであり，鍵の色 (黒鍵あるいは白鍵) が正しければ，システムは打鍵ミスと判定せず正しい音高を出力する．鍵盤楽器の他の楽器と異なる特徴として白鍵と黒鍵の存在がある．
鍵盤をはじめて見た人でも分かる色の違いを楽譜上の記号から判断できるように慣れることを狙いとしている．本モードはエニーキーモードの次に許容度が低いモードとして設計している．
ディレクションモード ディレクションモードでは，打鍵位置の方向が正しければ，システムは打鍵ミスと判定せず正しい音高に差し替えた音を出力する．
次に打鍵する鍵と，現在演奏している鍵が同じ高さの場合，同じ鍵を弾く必要がある．初心者であっても，次に弾く音が現在の音よりも相対的に高いか低いかは認識しやすいため，楽譜における音符の高さが，鍵盤上の横の位置の対応関係にあることを理解することを狙いとしてディレクションモードを提案する．
ディレクションカラーモード ディレクションカ
ラーモードは，前述のディレクションモードとカラー
モードを統合したモードである．次の打鍵位置の方向に加え，鍵の色が正しければシステムは打鍵ミスと判定せずに正しい音高を出力する．本モードはディレクションモードとカラーモードの両方を学習した
後に利用されることを想定している．

- 170 -

打鍵位置提示無モード これは，打鍵ミスを許容せず仮想鍵盤上に打鍵位置を提示しないモードで，楽譜上に現在の打鍵位置を示す緑の実線のみを提示す
る．楽譜を見ながら練習する状況とほぼ同じである．

4

実装

3 章で述べた学習支援システムのプロトタイプを実装した．PC は TOSHIBA 社の dynabook CX/47Eを使用し，MIDI 鍵盤として M-AUDIO 社の eKeysを使用した．PC 上のソフトウェアの開発は，Windows Vista 上で Processing を用いて行った．

5

まとめ

本研究では，学習者のミスの許容度に注目しモチベーションの維持を考慮したピアノ学習支援システ
ムを構築した．段階的に難度を変更し，その都度，無理なく少しの練習で高い成功体験を得られるように学習方法を設計した．
今後は，両手演奏や和音を含む場合における学習
方法の拡張や，さまざまな世代を対象とした評価実験を行う予定である．

参考文献[1] CASIO：光ナビゲーションキーボード：
http://casio.jp/emi/key lighting/.
[2] 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).
[3] 竹川佳成, 寺田努, 塚本昌彦：リズム学習を考慮したピアノ演奏学習支援システムの構築, 情報処
理学会インタラクション 2012, pp. 73–80 (2012年).
[4] 竹内好宏, 片寄晴弘：Two Finger Piano による曲想の表現, 情報処理学会研究報告 (音楽情報科学), pp. 37–44 (2001 年).

WISS2013

Bezel Check: ベゼル上におけるダブルクロッシングジェスチャ
黒澤 敏文

志築 文太郎

田中 二郎∗

概要. 本稿では携帯型タッチスクリーン端末における新たなジェスチャである Bezel Check を示す．Bezel
Check によりユーザは 1 ストロークの動作にてデータを空間的に配置する事が可能となる．Bezel Check は
ベゼルを開始点として画面端を通過するダブルクロッシングジェスチャであり，以下に示す利点を持つ．1)
素早い操作を行う事が出来る．2) 従来のタッチジェスチャと共存出来る．3) データを空間的に配置出来る．
我々は Bezel Check によりテキストのコピーや Web ページのブックマークを行い，コピーされたデータを素早く使用出来るシステムデーモンを作成した．

1

はじめに

スマートフォンやタブレット端末等の携帯型タッチスクリーン端末はタッチやスワイプ等のシンプルなジェスチャの組合せにより用いられている．しかしながら，コピーやペースト等，頻繁に用いられるコマンドには操作に多くの時間を要するものがある．
例えば， Windows 8 タブレット上においてユーザがテキストをコピーするためには，テキストを選択し，ロングタップによりポップアップメニューを表示し，メニューから「コピー」を選ぶ必要がある．
本稿では，携帯型タッチスクリーン端末において
1 ストロークの動作にて素早くデータを空間的に配置する事が可能となるジェスチャである Bezel Checkを示す．Bezel Check はピンチやスワイプ等の従来のタッチジェスチャと競合せず，これらと共存する事が出来る．

2

関連研究

本手法にて用いられるジェスチャと同様にベゼルを開始点とするジェスチャが多く研究されてきた [2,3, 5, 4]．Bragdon らは，ベゼルを開始点とするジェス
チャはモバイル環境において最も速いジェスチャであり，ユーザに最も好まれる事を示した [1]．Roth らは，ベゼルからのスワイプにより従来のマルチタッチ
ジェスチャと競合せずに操作出来る手法 Bezel Swipeを提案した [4]．我々は，ベゼルをジェスチャの開始点としてのみならず終了点としても用いる事により，物理的空間へデータの配置を行う事を可能にした．

3

Bezel Check

Bezel Check は携帯型タッチスクリーン端末のベ
ゼル上におけるダブルクロッシングジェスチャであ∗Copyright is held by the author(s).
Toshifumi Kurosawa， 筑波大学大学院 システム情報工学
研究科，Buntarou Shizuki and Jiro Tanaka， 筑波大学 シス
テム情報系- 171 -

(a)

(b)

(c)

図 1. a) Bezel Check の実行 b) 仮想クリップボード（上部の矩形）の表示 c) ベゼルからのシングルクロッ
シングにより表示されるマーキングメニュー

る．ユーザはまず，テキストまたはウェブページ等のオブジェクトを通常通りの方法を用いて選択する．
続いて，ユーザはベゼル上にてダブルクロッシング
ジェスチャをする (図 1 左)．即ち，ユーザはチェックマークを描くようにタッチスクリーンのベゼルから画面内部へスワイプし，またベゼルへ指を戻す動作をする．すると，Bezel Check を行ったベゼル付近の画面端に仮想クリップボード (図 1b 上部の矩形)が作成され，選択されたオブジェクトのデータがそこに格納される．仮想クリップボードに格納されたデータを参照するには，ユーザはまずそのデータを用いるアプリケーションにフォーカスを移す．続いて，ベゼルから参照したいデータが格納されている
仮想クリップボードをクロッシングするようにスワイプする．すると仮想クリップボードを中心にマーキングメニューが展開されるので，ユーザはその中から実行したいコマンドを選択し，指を離す（図 1c）．
また，ユーザは画面端に配置された仮想クリップ
ボードに対して，移動/他の仮想クリップボードとの統合/消去を行う事が出来る．ユーザが統合された仮想クリップボードにタッチした際，その内容がその仮想クリップボードを中心に展開される（図 2 左）．
ユーザは統合された仮想クリップボード内のデータを用いたい場合，展開されたデータをベゼル部分からスワイプする事により選択し，表示されたマーキ
ングメニューからコマンドを選択し，指を離す（図2 右）．これにより，ユーザは容易に仮想クリップ

WISS 2013

ボードの位置関係の変更や，データのグルーピングを行う事が可能となる．

3.1

表 1. 各アプリケーションがアクティブである場合に展開されるマーキングメニューの内容

アプリケーション
テキストエディタWeb ブラウザ

利点

Bezel Check はベゼルからのダブルクロッシング
動作のみにより用いる事が出来るため，次に挙げる
利点を持つ．
1. 素早い操作：Bezel Check は 1 ストロークにて操作できるため，ユーザはコピー等の動作を通常の方法よりも素早く行う事が可能となる．
2. 従来のマルチタッチジェスチャとの共存：ベゼルからのスワイプ動作には，ピンチや通常のスワイプ等の従来のタッチジェスチャと競合せず，これらと共存出来るという利点を持つ [4]．
3. 空間的なデータ配置：ユーザは画面端の任意の位置にデータを配置する事が出来る．そのため，ユーザはデータをタッチスクリーンの四辺に分類して配置する事が出来る．また，デー
タは画面端に表示されるので画面の表示領域をあまり減少させない．

PDF ビューア

アクティブアプリケーションと仮想クリップボードとの間においてデータを送受信するために，システ
ムデーモンはキーイベントを送り， OS から提供されるクリップボードを中継地点として使用する．例
えば，ユーザがテキストエディタをアクティブにしBezel Check を実行すると，システムデーモンは選択されたテキストを OS から提供されるクリップボー
ドにコピーするために Ctrl+C のキーイベントを送る．その後，システムデーモンは OS から提供されるクリップボードから Windows API を用いてコピーされたテキストを取得する．また，ベゼル部分に保持されたテキストをエディタ上にペーストする際には，システムデーモンは Windows API を用いてそのテキストを OS から提供されるクリップボードにコピーし，その後 Ctrl+V キーイベントを送る．

5
図 2. (左) ベゼルからのスワイプによる，複数データが格納された仮想クリップボードの展開 (右) コマンド
の選択

3.2

アプリケーション

我々は携帯型タッチスクリーン端末において Bezel
Check を提供するシステムデーモンを開発した．本手法により展開されるマーキングメニューに表示されるコマンドは，端末上においてアクティブになっているアプリケーションに依存して決定される．今回の実装では，テキストエディタ・Web ブラウザ・
PDF ビューアの 3 種類のアプリケーションを対象にした．表 1 にそれぞれのアプリケーションがアクティブである場合に展開されるマーキングメニューの内
容を示す．

4

実装

我々は 3.2 節にて述べたシステムデーモンを Windows 8 タブレット上に C# .NET を用いて実装した．
ベゼル上におけるダブルクロッシングジェスチャを検出するために，我々は画面端にタッチ検出を行う
半透明ウィンドウを配置した．このシステムデーモ
ンは，常にアクティブアプリケーションを監視する．

- 172 -

マーキングメニューの内容
ペースト/テキスト検索
ペースト/テキスト検索
URL を開く/Web 検索
テキスト検索まとめと今後の予定

本稿では，携帯型タッチスクリーン端末において
1 ストロークの動作にて素早くデータを空間的に配置する事が可能となるジェスチャである Bezel Checkを示した．Bezel Check はピンチやスワイプ等の従来のタッチジェスチャと競合せず，これらと共存する事が出来る．
今後は，画像や一般ファイル等のテキスト以外のデータへの対応と，操作速度やエラー率等の定量的評価，また使用感等の定性的評価を行う．

参考文献[1] A. Bragdon, E. Nelson, Y. Li, and K. Hinckley. Experimental analysis of touch-screen gesture designs
in mobile environments. CHI ’11, pp. 403–412.
[2] K. Hinckley, J. Pierce, M. Sinclair, and E. Horvitz.
Sensing techniques for mobile interaction. UIST ’00,
pp. 91–100.
[3] S. Kim, J. Yu, and G. Lee. Interaction techniques for
unreachable objects on the touchscreen. OzCHI ’12,
pp. 295–298.
[4] V. Roth and T. Turner. Bezel swipe: conflictfree scrolling and multiple selection on mobile touch
screen devices. CHI ’09, pp. 1523–1526.
[5] M. Serrano, E. Lecolinet, and Y. Guiard. Bezel-Tap
gestures: quick activation of commands from sleep
mode on tablets. CHI ’13, pp. 3027–3036.

WISS2013

スマートフォンと MAD-SS を用いた長距離センサーノードの開発
内田 泰広

瀬川 典久

澤本 潤

杉野 栄二

矢澤 正人

後閑 政昭∗

概要.
センサネットワークで広域なネットワークを構築するには、一般的に利用されているセンサでは通信距離が短いため多くのセンサノードの設置が必要となり長距離通信可能なノードが必要である。また、山間部でのセンサネットワークインフラの構築では、周囲の環境に強く、電源が大容量バッテリーを持つノードが必要不可欠となる。本研究では広域なセンサネットワークを構築することを目的とし、数理設計研究所が開発した長距離通信可能なスペクトラム拡散通信技術を耐久性のあるスマートフォンを組み込み機として実装を行った。

1

はじめに

2

センサネットワークの研究が進化するにあたって、屋内などの限られたエリアから、屋外たとえば里山などの広域なエリアでのセンサネットワークの活用が考えられてきている。センサネットワークで屋外、広範囲での情報取得の需要として、線路の落石情報や、動物の行動パターンを監視したいというものがある。一般的なセンサネットワークを里山などで利用する場合、通信距離が 100m、長くても 1km程度であり、多くのセンサノードが必要となる
また、地形の影響により通信距離が短くなるという問題点があげられる [1]。
里山でのセンサノードの設置は電源の確保が困難であったり、金銭的コストや時間が多くかかってしまう。これより里山では少ないセンサノード数で、広範囲な情報を取得できることが理想である [2]。
本研究では数理設計研究所が開発した MAD-SSを活用し、長距離通信可能なセンサノードを開発することを提案する。過去に MAD-SS は、DSP を用
いた実装、ARM Cortex-M4F での実装が行われてきた。受信側では計算能力が求められるため、PC、
ARM マイコンで行われる。今後、さらなる広範囲
での情報取得のため、地形の影響を受けない高い高度に一時的に簡易な気球などに乗せる時、耐久性のあるセンサノードが必要となる。そこで、スマートフォンを利用した長距離通信可能なセンサノードの提案を行う。

MAD-SS

2.1 MAD-SS の特徴
MAD-SS は、数理設計研究所が開発した「スペクトラム拡散通信の高速同期法」による長距離通信可能な技術である。送信方法は一般的なスペクトラム
拡散通信の一つである直接拡散方式であり、受信側で高速で受信するために特殊な方法を用いている。
通信速度は (10bit/sec) であるが、超低出力で長距離通信可能である。微弱電波を使用しているため、免許不要で運用することができる。通信速度は低速であるがセンサネットワークで扱う情報量は潮位や温度、湿度などで問題にはならない。
免許不要時の超低出力 (50nW) で MAD-SS を用いた場合の通信距離と、免許を受けた場合に運用できる MAD-SS の通信距離を表 1、表 2 に示す。里山で十分な電波の受信を行えるために高度でも動作可能なスマートフォンに MAD-SS を実装することを試みている [3]。
表 1. MAD-SS を用いた場合の通信距離 (50nW)

送信アンテナ
高さ
1.5m
6.0m

受信アンテナ高さ
高さ
1.5m
1.5m

周波数
150MHz150MHz

距離
0.5km
1.2km

表 2. MAD-SS を用いた場合の通信距離 (10mW)

送信アンテナ
高さ
1.5m
6.0m

Copyright is held by the author(s).
∗Yasuhiro Uchida, 岩手県立大学 ソフトウェア情報学部
ソフトウェア情報学科, Norihisa Segawa, Jun Sawamoto,and Eiji Sugino, 岩手県立大学,Masato Yazawa,Masaaki
Gokan- 173 -

受信アンテナ高さ
高さ
1.5m
1.5m

周波数
150MHz150MHz

距離
7km
14km

WISS 2013

2.2

MAD-SS の受信手続きの高速同期法はネイティブコード (C/C++) を用いる。MAD-SS の中核となる高速フーリエ (FFT) はネイティブコードで行う。

従来のスペクトラム拡散通信の受信方法であるス
ライド法を用いた場合、同期を確立するために時間がかかってしまう。MAD-SS では受信を高速に行えるように工夫がなされている。以下に MAD-SSの受信方法（高速同期法）の手順を示す [5]。

まとめとの課題について

4

本研究では MAD-SS の受信部をスマートフォンに移植を行い、自然環境に強く、大容量バッテリーを搭載しているセンサノードの開発について提案している。今後として、里山や大気圏まで飛ぶ簡易な気球上 (図 1) などで正常に受信を行えるかを実験を行い、センサノードとしての有用性を調べる必要がある。長距離通信可能なセンサノードを開発することで里山などで必要とされる情報を幅広く取得でき
ることを目的としている。

1. 変調符号が変化する位置（トグル点）を検出
2. 拡散コードを一周期分のトグル点をあらかじ

め生成しておき、１と相互相関させて拡散コー
ドのズレ量を推定

3. 2. で求めたズレ量を用いて復調（逆拡散）4. 逆拡散した搬送波を確認し、受信したスペクトラムが有効なら取得

従来のスライド法では、拡散符号をスライドさせつつ逆拡散を行う。一方、MAD-SS の高速同期法では同期位置の推定をしてから、逆拡散を行う。MADSS の受信アルゴリズムの一つとして高速フーリエ変換 (FFT) があり、負荷がかかる処理は DSP を用
いて、省電力、小型化を目的とされた研究がされてきた。

3

スマートフォンを用いた長距離センサノー
ド

3.1 Android NDKAndroid NDK は、Android SDK と利用される開発キットである。Android アプリケーション

図 1. MAD-SS の受信機を気球に乗せたイメージ例の一部をネイティブコードで作成が可能で既存のC/C++のコードを再利用することができる。Android NDK のライブラリを使用することで Androidの Application framework を介さずに、Android の
内部構成の最下層である Linux のレイヤーの機能を使えるため、Java で実行するより高速となる [4]。

3.2

参考文献
[1]

システムについて

瀬川典久, 澤本潤, 松原和衛, 出口善隆, 大石明広,
山本信次, 東淳樹, 青井俊樹:里山での活動を支援するセンサネットワーク環境構築の提案, 電子情報通信学会技術研究報告. USN, ユビキタス・センサ
ネットワーク, pp.141-146 , (2009)[2] 柏田師宏, 瀬川典久, 澤本潤, 玉置晴朗, 矢澤正
人:MAD-SS と DSP を用いた長距離通信可能なセンサーノードの開発, ソフトウェア情報学研究科修論,(2012)本システムでは、処理の高速化、既に開発された (C/C++) のソースコードの一部を用いることが可能である Android NDK を使い JNI(Java Native Interface) を利用した。Cygwin を用いること
で (C/C++) のソースコードはビルドを行い共有モジュール (*.so) を生成し、Java 側で作成したネイ
ティブのライブラリをロードする。これにより、android アプリからネイティブコードを通常のメソッドとして利用可能である。
実装においては、電波の受信部を Java、MAD-SS[3] 澤 田 直 哉, 瀬 川 典 久, 澤 本 潤, 杉 野 栄 二, 玉 置
晴 朗, 矢 澤 正 人, 後 閑 政 昭: Coretex-M4F とMAD-SS を使用した長距離センサーノードの開発,WISS2012,(2012)[4] AndroidNDK.
http://developer.android.com/tools/sdk/ndk/index.html.
[5] 数理設計研究所. http://www.madlabo.com/ss/.

- 174 -WISS2013҉‫ֶه‬शͷͨΊͷจઅͱϞʔϥ਺ʹ‫͍ͨͮج‬ସ͑Վࣗಈੜ੒γεςϜ
ҏ౻ ༔ਅ

ࣉా ౒

௩ຊ ণ඙ ∗

֓ཁ. ৘ใॲཧٕज़͕ਐల͠ɼ͞·͟·ͳֶशࢧԉγεςϜ͕։ൃ͞Ε͍ͯΔɽಛʹɼֶशऀͷ҉‫ه‬Λࢧԉ͢ΔͨΊͷҰൠతͳख๏ͱͯ͠͸ɼ‫ݩ‬ͷจࣈྻΛଞͷҙຯͷ͋Δจࣈྻʹஔ͖‫͑׵‬Δ‫ޠ‬࿊߹Θ͕ͤΑ͘༻͍ΒΕɼͦͷ‫ޠ‬࿊߹ΘͤΛࣗಈͰੜ੒͢ΔγεςϜ͕ଘࡏ͢Δɽ͔͜͠͠ΕΒͷγεςϜʹ͸จࣈ਺΍҉‫ه‬ର৅ʹ੍‫͕͋ݶ‬Γɼ൚༻తʹ҉‫ֶه‬शʹ࢖͑Δͱ͸͍͑ͳ͍ɽҰํͰɼ҉‫ֶه‬शͷͨΊʹସ͑ՎΛ༻͍Δͱ͍͏ख๏͸ɼ‫ޠ‬࿊߹Θͤͱಉ༷ʹ޿͘஌Ε౉͍ͬͯΔख๏Ͱ͋Δ͕ɼସ͑ՎΛੜ੒͢ΔҰൠతͳख๏͸චऀΒͷ஌Δ‫ݶ‬Γཱ֬͞Ε͓ͯΒͣɼֶशऀ͕҉‫߲͍ͨ͠ه‬໨ʹରࣗ͠༝ʹସ͑ՎΛੜ੒͢Δ͜ͱ͕Ͱ͖ͳ͍
ͱ͍͏໰୊͕͋Δɽ͕ͨͬͯ͠ຊ‫Ͱڀݚ‬͸҉‫ֶه‬शͷͨΊͷସ͑Վࣗಈੜ੒γεςϜͷߏஙΛ໨తͱ͢ΔɽఏҊख๏Ͱ͸ɼֶशऀࣗ਎ͷ஌͍ͬͯΔָ‫͔ۂ‬ΒͳΔָ‫ۂ‬σʔλϕʔεʹର͠ɼֶशऀ͕҉‫߲͍ͨ͠ه‬໨Λೖྗ͢Δͱɼָ‫ۂ‬σʔλϕʔεதͷ͍͔ͭ͘ͷ‫ۂ‬ͷՎࢺʹ҉‫߲͍ͨ͠ه‬໨ׂ͕Γ౰ͯΒΕͯସ͑Վͱͯ͠ग़ྗ͞ΕΔɽຊ‫Ͱڀݚ‬͸ɼ͜ͷׂΓ౰ͯʹָ‫ۂ‬ͷϦζϜͱ҉‫߲ه‬໨ͷϞʔϥ਺Λ༻͍Δख๏ΛఏҊͨ͠ɽ

1

͸͡Ίʹ

提案システム
楽曲データベース

৘ใॲཧٕज़͕ਐల͠ɼ͞·͟·ͳֶशࢧԉγεςϜ͕։ൃ͞Ε͍ͯΔɽಛʹɼֶशऀͷ҉‫ֶه‬शΛࢧԉ͢ΔͨΊͷ‫ݩͯ͠ͱྫڀݚ‬ͷ୯‫ޠ‬ͷཏྻΛ಄จࣈΛ‫͛ܨ‬ΔͳͲͯ͠ଞͷจࣈྻʹஔ‫͢׵‬Δ‫ޠ‬࿊߹ΘͤΛࣗಈͰੜ੒͢Δͱ͍͏΋ͷ͕͋Δ [1]ɽ͜ΕΒͷ‫Ͱڀݚ‬͸ɼ4 ‫͔ݸ‬Β 8 ‫ݸ‬ͷ୯‫ʹޠ‬ର͠‫ޠ‬࿊߹ΘͤΛੜ੒͍ͯ͠Δ͕ɼଟ਺ͷ୯‫ޠͰޠ‬࿊߹ΘͤΛੜ੒ͨ͠৔߹ɼੜ੒݁Ռ͕ෆࣗવʹͳΔͱ͍͏໰୊͕͋ΔɽҰํɼ҉‫߲͍ͨ͠ه‬໨Λ‫ط‬ଘͷָ‫ۂ‬ͷϝϩσΟʹ
৐ͤͯ҉‫͢ه‬Δସ͑ՎʹΑΔख๏͸‫ޠ‬࿊߹Θͤͱಉ༷ʹ޿͘஌Ε౉͍ͬͯΔख๏Ͱ͋Γɼ༗༻ੑ͕ࣔ͞Ε͍ͯΔ [2]ɽ͔͠͠ɼ҉‫༻ه‬ͷସ͑ՎΛੜ੒͢Δख๏͸චऀΒͷ஌Δ‫ݶ‬Γཱ֬͞Ε͓ͯΒͣɼֶशऀ͕
҉‫߲͍ͨ͠ه‬໨ʹରࣗ͠༝ʹସ͑ՎΛ࡞੒Ͱ͖ͳ͍
ͱ͍͏໰୊͕͋Δɽ
ͦ͜Ͱຊ‫Ͱڀݚ‬͸҉‫༻ه‬ͷସ͑Վࣗಈੜ੒γεςϜΛߏங͢ΔɽఏҊख๏Ͱ͸ɼସ͑Վͷ‫ͳͱݩ‬Δָ‫ۂ‬σʔλϕʔεΛอ࣋͠ɼֶशऀ͕҉‫͍ͨ͠ه‬୯‫ޠ‬ͷϦετʢҎԼ҉‫ه‬ϦετͱΑͿʣΛೖྗ͢Δͱɼָ‫ۂ‬σʔλϕʔεதͷ͍͔ͭ͘ͷ‫ۂ‬ͷՎࢺʹ҉‫ه‬Ϧετׂ͕Γ౰ͯΒΕͯग़ྗ͞ΕΔɽຊ‫Ͱڀݚ‬͸ɼՎࢺͷจઅͱՎࢺͷϦζϜʹண໨ׂ͠Γ౰͓ͯΑͼׂΓ౰ͯ࣌ͷมߋ౓߹͍Λܾఆ͍ͯ͠Δɽ

2

ઃ‫ܭ‬

ਤ 1 ʹఏҊγεςϜͷॲཧͷྲྀΕΛࣔ͢ɽ·ͣɼਤ 1 ʹࣔ͢Α͏ʹγεςϜ͸ָ‫ొ͕ۂ‬࿥͞Εָͨ‫ۂ‬∗

Copyright is held by the author(s).
Yuma Ito and Masahiko Tsukamoto, ਆ‫ށ‬େֶେֶӃ޻ֶ‫ڀݚ‬Պ, Tsutomu Terada , ਆ‫ށ‬େֶେֶӃ޻ֶ‫ڀݚ‬Պ / Պֶٕज़ৼ‫͚͕͖͞ߏػڵ‬・替え歌の元となる楽曲を保持・学習者の知っている曲や好みの曲で構成

暗記リストの入力
楽曲データベース中の全ての楽曲と暗記リストが割り当てられるか判断

学習者

暗記リストが割り当てられる
楽曲を替え歌リストに追加

替え歌リスト
替え歌リストの出力ਤ 1. ఏҊγεςϜͷॲཧͷྲྀΕσʔλϕʔεΛอ͓࣋ͯ͠Γɼσʔλϕʔεதͷָ‫͔ۂ‬Βସ͑Վ͕࡞ΒΕΔɽจ‫[ ݙ‬2] ΑΓɼ‫هʹط‬Ա͍ͯ͠Δָ‫ʹۂ‬ର͠ସ͑ՎΛੜ੒͢Δ͜ͱ͕ॏཁͰ
͋ΔͨΊɼຊ‫Ͱڀݚ‬͸ָ‫ۂ‬σʔλϕʔε͸Ϣʔβ‫ݸ‬ਓ͕‫ه‬Ա͍ͯ͠Δָ‫ۂ‬΍޷͖ͳָ‫ߏͰۂ‬੒͞Ε͍ͯ
Δɽֶशऀ͕҉‫ه‬ϦετΛγεςϜʹೖྗ͢Δͱɼ
γεςϜ͸σʔλϕʔεதͷָ֤‫ه҉ͱۂ‬ϦετͰԻූ਺ͳͲͷ৚݅Λ‫ʹݩ‬ସ͑Վ͕ੜ੒Մೳ͔Ͳ͏͔Λ൑அ͢Δɽੜ੒ՄೳͰ͋Ε͹ସ͑ՎϦετʹੜ੒݁ՌΛ௥Ճ͠ସ͑Վͱͯ͠ग़ྗ͢Δɽ͞Βʹɼจ‫ݙ‬[2] ΑΓɼੜ੒͞Εͨସ͑Վ͕‫هʹط‬Ա͍ͯ͠Δָ‫ۂ‬ͱ͍͏৚݅Λຬͨͨ͢Ίʹɼସ͑Վͷ‫ͳͱݩ‬Δָ‫ۂ‬ͱੜ੒͞Εͨସ͑Վͷؒʹେ͖ͳࠩҟ͕Ͱͳ͍Α͏ʹઃ‫͢ܭ‬Δඞཁ͕͋Δɽຊ‫Ͱڀݚ‬͸֤ସ͑Վʹର͠ʮมߋ౓ʯͱ͍͏‫ݴ‬༿Λఆٛ͠ɼ҉‫ه‬ϦετΛָ‫ۂ‬ͷՎࢺʹׂΓ౰ͯΔࡍʹ‫ݩ‬ͷָ‫ۂ‬ΛͲΕ͚ͩมߋ͠
͔ͨͷ஋ΛఆྔԽ͢Δ͜ͱͰɼখ͍͞΋ͷ͔Βॱʹ‫͔ۂָݩ‬ΒͷมԽ͕খ͍ࣗ͞વͳସ͑Վͱͯ͠ग़ྗ
͢Δɽ
ຊ‫Ͱڀݚ‬͸ָ‫ۂ‬ͷՎࢺͷจઅ͝ͱʹ҉‫ه‬Ϧετͷׂ౰ͯΛߦ͏ɽ‫ݪ‬ଇͱͯ͠ɼ֤จઅʹ‫·ؚ‬ΕΔԻූ

- 175 -WISS 2013
Exportボタン

楽曲の歌詞
1

2

3

4

5

6

・・・

1

2

3

4

5

6

・・・

曲選択用コンボボックス

元の歌詞

暗記リスト

ਤ 2. ҉‫ه‬Ϧετͷׂ౰ͯྫྻʹର͠҉‫ه‬Ϧετͷ 1 ߲໨ͷϞʔϥΛ‫ۉ‬౳ʹׂΓ౰ͯɼԻූ਺ͱϞʔϥ਺ͷࠩʹΑͬͯมߋ౓Λఆٛ
͢Δɽ͜͜ͰɼϞʔϥͱ͸೔ຊ‫ޠ‬ͷഥͱ‫ݺ‬͹ΕΔ΋ͷ
Ͱɼ௨ৗ 1 ରͷࢠԻͱ฼Ի͔Β੒Δɽྫͱͯ͠ʮνϣίϨʔτʯΛϞʔϥͰ෼͚ΔͱʮνϣɼίɼϨɼʵɼτʯͱͳΓɼϞʔϥ਺͸ 5 ͱͳΔɽ·ͨɼԻූ਺͕
଍Γͳ͍৔߹ɼԻූྻதͰ࠷௕ͷԻූΛ෼ׂ͢Δ͜
ͱͰԻූ਺Λ૿΍͢ɽԻූΛ෼ׂ͢Δ৔߹ɼ16 ෼ԻූΑΓ୹͍ԻූͰ͸ׂΓ౰ͯΒΕͨϞʔϥ͕ฉ͖औΓʹ͘͘ͳΔͷͰɼ͜ΕҎ্͸෼ׂ͠ͳ͍ͱ͢Δɽ
ΑͬͯશͯͷԻූ͕ 16 ෼Իූʹͳͬͯ΋ׂΓ౰ͯ
ΔԻූ͕଍Βͳ͍৔߹Λʮׂ౰ͯෆՄೳʯͱ͠ɼͦ
ΕҎ֎Λʮׂ౰ͯՄೳʯͱ͢Δɽ࣍ʹɼָ‫ۂ‬શମͰͷจઅ͓Αͼ҉‫ه‬ϦετͷׂΓ౰ͯํΛਤ 2 Λ༻͍ͯઆ໌͢Δɽਤ 2 ্෦ͷۣ‫ܗ‬͸ָ‫ۂ‬ͷՎࢺͷจઅΛද͠ɼԼ෦ͷۣ‫ܗ‬͸҉‫ه‬Ϧετͷ֤߲໨Λද͢ɽ͞Βʹɼ੨৭໼ҹ͸҉‫߲ه‬໨͕ͦͷ໼ҹͷࢦ͢จઅʹରׂ͠౰ͯՄೳͰ͋Δ͜ͱΛද͠ɼ੺৭໼ҹ͸ׂ౰ͯෆՄೳͰ͋Δ͜ͱΛද͢ɽ
ਤ 2 ʹࣔ͢Α͏ʹɼఏҊγεςϜ͸ָ‫ۂ‬ͷՎࢺͷ࠷ॳͷจઅ͔Βॱʹ҉‫ه‬Ϧετͷ֤߲໨ׂ͕౰ͯՄ
ೳ͔Ͳ͏͔Λ൑அ͢Δɽׂ౰ͯՄೳͷ৔߹͸ɼ࣍ͷจઅ͓Αͼ࣍ͷ҉‫ه‬ϦετͰׂ౰ͯՄೳ͔Λ൑அ͠ɼׂ౰ͯෆՄೳͷ৔߹͸ɼ࣍ͷจઅͰׂ౰ͯՄೳ͔Ͳ
͏͔Λ൑அ͢Δɽ͜ͷΑ͏ʹͯ͠ɼ࠷‫ޙ‬ͷจઅ΋͘͠͸࠷‫ޙ‬ͷ҉‫ه‬ϦετͰͷׂ౰ͯՄೳ͔Ͳ͏͔͕൑
அ͞ΕΔ·ͰॲཧΛଓ͚ɼ࠷ऴతʹ͜ͷָ‫ۂ‬Λସ͑ՎϦετʹՃ͑Δ͔Ͳ͏͔ΛҎԼͷΑ͏ʹ൑அ͢Δɽ• ҉‫ه‬Ϧετ͕શͯՎࢺͷจઅʹׂΓ౰ͯΒΕͨ৔߹ׂ౰ͯΒΕͳ͔ͬͨจઅ͸ɼͦΕΒͷશͯͷԻූʹର͠ʮϥʯΛׂΓ౰ͯΔ͜ͱͱ͠ɼ͜
ͷָ‫ۂ‬Λସ͑ՎϦετʹ௥Ճ͢Δɽ͜ͷͱ͖ɼָ‫ۂ‬શମͷมߋ౓Λจઅ͝ͱͰͷมߋ౓ͷ૯࿨Ͱఆٛ͢Δɽ• ҉‫ه‬Ϧετ͕શͯՎࢺͷจઅʹׂΓ౰ͯΒΕͳ͔ͬͨ৔߹
͜ͷ৔߹͸͜ͷ҉‫ه‬Ϧετͱָ‫Ͱۂ‬͸ସ͑Վ͸ੜ੒Ͱ͖ͳ͍ͱ͠ɼ‫ࡏݱ‬ͷ‫ۂ‬Λସ͑ՎϦετʹ͸௥Ճ͠ͳ͍ɽ

生成結果ビュー

暗記リスト

ਤ 3. ϓϩτλΠϓγεςϜͷ֓‫؍‬3࣮૷

2 ষͰड़΂ͨସ͑Վࣗಈੜ੒γεςϜͷϓϩτλ
ΠϓΛ࣮૷ͨ͠ɽਤ 3 ʹϓϩτλΠϓγεςϜͷ֓‫؍‬Λࣔ͢ɽਤ 3 ʹࣔ͢΢Πϯυ΢Ͱ͸ࢦఆͨ͠҉‫ه‬Ϧετ͕ͲͷΑ͏ʹָ‫ۂ‬ͷՎࢺʹׂΓ౰ͯΒΕ͍ͯ
Δ͔Λ‫ݟ‬Δ͜ͱ͕Ͱ͖Δɽ͞Βʹɼ্෦ͷίϯϘϘο
Ϋεʹ͸ସ͑ՎϦετ͕֨ೲ͞Ε͓ͯΓɼ͜ͷબ୒Λ੾Γସ͑Δ͜ͱͰɼϢʔβ͸Ͳͷָ‫Ͱۂ‬ͷସ͑ՎΛ҉‫͍༻ʹه‬Δ͔બͿ͜ͱ͕Ͱ͖Δɽ·ͨɼࠨ্ͷ
Export ϘλϯʹΑΓ musicXML ‫ࣜܗ‬ͷϑΝΠϧΛ
ग़ྗ͢Δ͜ͱ͕Ͱ͖ɼ͜ͷϑΝΠϧΛָේ࡞੒ιϑτ΍Վ੠߹੒ιϑτ΢ΣΞʹೖྗ͢Δ͜ͱͰੜ੒݁
ՌΛָේ΍Ի੠ʹม‫͖Ͱ׵‬Δɽ4·ͱΊຊ‫Ͱڀݚ‬͸҉‫ֶه‬शͷͨΊͷସ͑Վࣗಈੜ੒γεςϜͷઃ‫૷࣮ͱܭ‬ΛߦͬͨɽఏҊγεςϜ͸ָ‫ۂ‬தͷՎࢺͷจઅ͝ͱʹɼՎࢺͷϦζϜͱ҉‫ه‬ϦετͷϞʔϥ਺Λߟྀͯ͠҉‫߲ه‬໨ΛׂΓ౰ͯΔ͜ͱͰɼସ͑Վੜ੒Λߦ͍ͬͯΔɽࠓ‫ޙ‬ͷ՝୊ͱͯ͠͸ɼ҉‫ه‬ϦετΛସ͑Վͷ༗ແͦΕͧΕͰ࣮ࡍʹඃ‫ͤ͞ه҉ʹऀݧ‬ɼ҉‫ֶه‬शʹରͯ͠ఏҊख๏͕༗ޮͰ͋Δ͔ͷධՁ࣮‫͑ߟ͕ݧ‬ΒΕΔɽ·ͨɼϞʔϥ਺΍จઅͷԻූ਺ʹΑͬͯ͸ෳ਺ͷจઅʹ·͕ͨͬͯ୯‫ޠ‬ΛׂΓ౰ͯΔख๏΋‫ݕ‬౼͢
Δඞཁ͕͋Δɽࢀߟจ‫ݙ‬[1] Ԭ҆༏໻΄͔: ඼ࢺʹΑΔจධՁΛ༻͍ͨ೔ຊ‫ޠ‬‫ޠ‬࿊ࣗಈੜ੒ख๏, ৘ใॲཧֶձ૑ཱ 50 प೥‫ه‬೦ (ୈ 72 ճ) શࠃେձ, pp. 511 – 512 (2010).
[2] R. Hale-Evans: Mind Performance Hacks: Tips
& Tools for Overclocking Your Brain, O’Reilly
Media (2006). (Ն໨ େ༁: MIND ύϑΥʔϚϯε HACKS-೴ͱ৺ͷϢʔβʔϚχϡΞϧ, ‫ࣜג‬ձࣾΦϥΠϦʔɾδϟύϯ (2007)).

- 176 -WISS2013ೈΒ͔ͯ͘Α͘஄Ήηϯα಺ଂϘʔϧͷ։ൃࠤ౻ ढ़थ ∗
֓ཁ.
ຊ‫Ͱڀݚ‬͸ɺυοδϘʔϧ౳ͷ‫ٕٿ‬ͷ֦ுʹ༻͍Δ͜ͱ͕ՄೳͳೈΒ͔ͯ͘Α͘஄Ήηϯα಺ଂϘʔϧΛఏҊ͢ΔɻϘʔϧ͸Ϙʔϧ֎ൽɺ಺ൽɺηϯαϢχοτɺηϯαίΞ‫ݻͼٴ‬ఆ༻όϧʔϯ͔Β੒Γɺ֤छηϯα͕֨ೲ͞ΕͨηϯαίΞ͸ɺίΞ্ʹຒΊࠐ·Εͨ‫ݻ‬ఆ༻όϧʔϯʹΑΓϘʔϧத৺ʹॊΒ͔͘‫ݻ‬ఆ͞ΕΔɻ͜ΕʹΑΓɺϘʔϧͷೈΒ͔͞ͱ஄ྗੑΛҡ࣋ͭͭ͠ɺམԼ࣌ͷিܸ΍֎͔ΒͷՃॏʹରͯ͠ߴ͍଱‫ٱ‬ੑΛ࣋ͭηϯα಺ଂϘʔϧΛ࣮‫͢ݱ‬Δ͜ͱ͕ՄೳʹͳΔɻຊ࿦จͰ͸͜ΕΒͷ‫ʹࡍ࣮ͱߏػ‬։ൃͨ͠ϓϩτλΠϓʹ͍ͭͯड़΂ɺ‫఺࣌ݱ‬ͷ՝୊ͱࠓ‫ޙ‬ͷల๬ʹ͍ͭͯड़΂Δɻ

͸͡Ίʹ

1

ۙ೥σδλϧٕज़Λ༻͍ͨεϙʔπ֦ுʹ஫໨
͕ू·͍ͬͯΔɻैདྷͷεϙʔπʹ֤छηϯα΍ແઢٕज़Λ૊Έ߹ΘͤΔ͜ͱͰ‫ط‬ଘεϙʔπͷϧʔϧ֦ு΍શ͘৽͍͠εϙʔπ΍ΤΫααΠζɺ਎ମతཁૉΛ༻͍ͨήʔϜͷ૑଄͕‫ߦʹൃ׆‬ΘΕΔΑ͏ʹͳ͖ͬͯͨɻεϙʔπ֦ுٕज़ͷதͰ΋ɺಛʹϘʔϧͷ֦ு͸͜Ε·Ͱ࠷΋‫ߦʹൃ׆‬ΘΕ͖͓ͯͯΓɺ‫ۀا‬ͷ੡඼΍ίϯηϓτϞσϧΛ‫ؚ‬Ί༷ʑͳηϯα಺ଂϘʔϧ͕ଘࡏ͢Δ [1][3]ɻ
࣮ࡍʹεϙʔπ΍ΤΫααΠζɺ༡ٔͰ࣮༻Մೳ
ͳηϯαϘʔϧΛ։ൃ͢ΔͨΊʹ͸͍͔ͭ͘ͷٕज़త՝୊͕͋Δɻ·ͣɺ಺ଂ͢Δηϯα΍ϚΠίϯ౳͕ϘʔϧʹՃΘΔ‫͍ڧ‬িܸͰյΕͳ͍Α͏ʹ͢Δඞ
ཁ͕͋Δɻ࣍ʹɺηϯα౳Λ಺ଂ͢Δ͜ͱͰϘʔϧ͕ඞཁҎ্ʹॏ͘ͳͬͨΓɺ஄·ͳ͘ͳͬͨΓ͢Δ
͜ͱ΋ආ͚ͳ͚Ε͹ͳΒͳ͍ɻ·ͨɺ಺ଂ͢ΔσόΠεʹΑΔॏ৺ͷภΓ΍ɺ‫ܗ‬ঢ়ͷม‫ܗ‬΋཈͑ͳ͚Ε͹ͳΒͳ͍ɻͦ͜Ͱຊ‫Ͱڀݚ‬͸ɺ͜ΕΒͷ໰୊Λߟྀͨ͠৽͍͠ηϯα಺ଂϘʔϧΛఏҊ͢Δɻ

1.1

ఏҊͱ࣮૷

ຊ‫Ͱڀݚ‬͸ਤ 1 ͷΑ͏ͳόϧʔϯ‫ߏػ‬Λ༻͍ͨηϯα಺ଂϘʔϧΛ։ൃͨ͠ɻ͜ͷ‫ߏػ‬ͷେ͖ͳಛ௃
͸ɺ‫ݻ‬ఆ‫͋Ͱྔ͕ܰߏػ‬Δ͜ͱɺিܸ΍Ճॏʹର͢Δ଱‫ٱ‬ੑ͕ߴ͍͜ͱͰ͋Δɻ͞ΒʹϘʔϧ಺ͷۭ‫ؾ‬ʹΑΔ஄ྗੑΛଛͳΘͣɺ҆Ձʹ࣮‫ݱ‬ՄೳͰ͋Δ͜ͱ΋‫͛ڍ‬ΒΕΔɻҎԼͰ͸ɺ࣮ࡍʹ։ൃͨ͠ϓϩτλΠϓγεςϜʹ͍ͭͯड़΂ͳ͕Βຊ‫ߏػ‬ͷৄࡉΛઆ໌͠ɺ࠷‫ޙࠓʹޙ‬ͷల๬ʹ͍ͭͯड़΂Δɻ

1.2ϋʔυ΢ΣΞ

ఏҊ͢ΔϘʔϧ͸ɺϘʔϧ֎ൽɺϘʔϧ಺ൽɺηϯαίΞɺίΞ‫ݻ‬ఆ༻όϧʔϯɺ‫ͼٴ‬ηϯαϢχο
∗Copyright is held by the author(s).
ి‫ؾ‬௨৴େֶ

- 177 -

ਤ 1. Ϙʔϧ಺‫ߏػ‬τ͔Β੒ΔɻηϯαϢχοτ͕֨ೲ͞ΕΔηϯαί
Ξʹ͸ɺ4 ͭͷ‫ݻ‬ఆ༻όϧʔϯϢχοτ͕‫ݻ‬ఆ͞Ε͍ͯΔ (ਤ 2(ӈ))ɻόϧʔϯϢχοτ͸ίΞ্ʹ‫ۉ‬౳ʹ෼ࢄ഑ஔ͞Ε͓ͯΓɺ͜ΕΒʹ‫ۉ‬౳ʹѹॖۭ‫ؾ‬ΛૹΓࠐΉ͜ͱͰ๲Β·͠ɺϘʔϧத৺ʹίΞΛ‫ݻ‬ఆ͢Δɻ͜Εͱಉ࣌ʹɺҰൠతͳۭ‫ࣜؾ‬Ϙʔϧͱಉ༷ʹɺίΞΛแΉϘʔϧͷ಺ൽʹ΋ۭ‫ؾ‬ΛૹΓࠐΈϘʔϧશମΛ๲Β·ͤΔɻ։ൃͨ͠ϓϩτλΠϓϘʔϧΛਤ 2(ࠨ) ʹࣔ͢ɻࠓճͷϓϩτλΠϓ࣮૷ʹ͓͍ͯ͸ɺ֎ൽͱͯ͠ 7Πϯνͷແ৭ಁ໌ΰϜϘʔϧɺ಺ൽͱͯ͠ 16 Πϯνͷ෩ધɺίΞ‫ݻ‬ఆ༻όϧʔϯͱͯ͠ 9 Πϯνͷ෩ધΛ༻͍ͨɻ·ͨɺηϯαίΞ͸ 3D ϓϦϯλΛ༻͍ͯABS थࢷ੡Ͱ࡞੒ͨ͠ɻ‫ݻ‬ఆ༻όϧʔϯʹۭ‫ؾ‬ΛೖΕΔͨΊʹ͸ɺͦΕͧΕͷόϧʔϯʹ઀ଓͨ͠‫ࢧٯ‬ห෇͖ͷνϡʔϒΛ༻͍ͨɻ͜ͷνϡʔϒ͸ɺίΞ಺෦Λ௨Γ಺ൽ༻όϧʔϯͷ‫ूʹޱ‬தͤ͞ɺ಺ൽ༻
όϧʔϯͱಉ࣌ʹۭ‫ؾ‬ΛૹΓࠐΊΔΑ͏ʹͨ͠ɻϓϩτλΠϓγεςϜͰ͸ೖख੡ɺՃ޻ੑΛߟྀ͠ࢢൢͷ෩ધΛ༻͍͕ͨɺϘʔϧͷό΢ϯυɺน΁ͷ౤͚͛ͭ౳ʹΑΔিܸΛՃ͑ͯ΋ׂΕΔ͜ͱ͸ແ͘ɺ

WISS 2013಺ଂ͍ͯ͠Δηϯα͕յΕΔ͜ͱ΋ͳ͔ͬͨɻ·ͨ஄Έํ΋ҰൠతͳΰϜϘʔϧͱ΄΅ಉ౳Ͱ͋ͬͨɻ
֎ൽʹ͸ίΞΛऩೲ͢Δࡍͷ੾ΕࠐΈΛೖΕΔඞཁ
͕͕͋ͬͨɺ಺ൽ͑͞ด͡ΒΕ͍ͯΕ͹ɺϏχʔϧςʔϓ౳Ͱͷ؆୯ͳ੾ΕࠐΈͷิ‫ڧ‬ͷΈͰ౤͛ͯ༡
Ϳ͚ͩͷे෼ͳ‫͕౓ڧ‬ಘΒΕͨɻ

ਤ 2. ϓϩτλΠϓϘʔϧ (ࠨ) ‫ͼٴ‬ίΞ (ӈ)

2‫఺࣌ݱ‬ͷ՝୊ͱͯ͠͸ɺিܸʹΑΓίΞ͕த৺͔Βए‫ͣׯ‬Εͯ͠·͏໰୊͕͋Δɻͦ͜ͰίΞͱ‫ݻ‬ఆ༻όϧʔϯΛΑΓ‫ݻ͘ڧ‬ఆͰ͖ΔΑ͏ͳ‫ݻ‬ఆํ๏Λ։ൃ͍ͨ͠ͱߟ͍͑ͯΔɻ࣍ʹɺίΞΛϘʔϧத৺ʹ‫ݻ‬ఆ͢ΔͨΊʹ͸ɺ‫ݻ‬ఆ༻όϧʔϯͷେ͖͞Λ‫ۉ‬Ұʹ͢Δඞཁ͕͋Γɺ·ͨ‫ݻ‬ఆ༻όϧʔϯͷۭ‫ؾ‬ѹ͕ߴա͗ΔͱϘʔϧ͕ม‫͏·ͯ͠͠ܗ‬ɻ͔͠͠‫ࡏݱ‬͸‫ݻ‬ఆ༻όϧʔϯʹ‫ࢭٯ‬หΛ૷ண͍ͯ͠ΔͨΊۭ‫ؾ‬ͷௐઅ͕ࠔ೉Ͱ͋Δͱ͍͏໰୊͕͋Δɻͦ͜Ͱόϧʔϯͷۭ‫ؾ‬ѹௐઅΛ༰қʹ͢ΔͨΊͷόϧϒ‫ߏػ‬ͷ։ൃ΋ߦ͍͍ͨͱߟ͍͑ͯΔɻ·ͨόϧʔϯͷ‫ܗ‬ঢ়΍ૉࡐʹ͍ͭͯ΋࣮‫ݧ‬ɺௐࠪΛߦ͍ɺΑΓదͨ͠΋ͷʹվྑ͍͖͍ͯͨ͠ͱߟ͍͑ͯΔɻࠓ‫ޙ‬ͷల๬ͱͯ͠͸ɺ࣮ࡍʹ࣮༻͠վྑ‫ͼٴ‬ੑೳͷධՁΛߦ͏ͱಉ࣌ʹɺϘʔϧΛ༻͍ͨεϙʔπ֨ௐٕज़ʹ͍ͭͯ΋։ൃΛߦ͍͍ͨͱߟ͍͑ͯΔɻ

3
1.3

಺ଂηϯαϢχοτ

͜ΕΒͷৄࡉͳߏ੒Λਤ 1 ʹࣔ͢ɻ࣍ʹɺϘʔϧʹ಺ଂ͢ΔηϯαϢχοτͷ։ൃΛߦͬͨɻηϯαϢχοτ͸ϚΠΫϩίϯτϩʔϥɺແઢϞδϡʔϧɺηϯα‫ͼٴ‬όοςϦ͔Βߏ੒͞ΕΔ (ਤ 3)ɻࠓճͷ࣮૷Ͱ͸ɺϚΠΫϩίϯτϩʔϥ‫ͼٴ‬ແઢϞδϡʔϧʹέΠπʔిࢠ੡ WCU-C2543 ЖΛ༻͍ͨɻ·ͨηϯα͸Ճ଎౓ηϯα (ADXL345)ɺδϟΠϩη
ϯα (ITG3200) ʹՃ͑ɺѹྗηϯα (MPL115A2)
΋಺ଂͨ͠ɻఏҊϘʔϧ͸ηϯα͕‫׬‬શʹີด͞Ε
͍ͯΔͨΊɺѹྗηϯαΛ౥ࡌ͢Δ͜ͱͰϘʔϧ಺ͷۭ‫ؾ‬ѹͷมԽΛଌఆՄೳͰ͋Δɻ͜ΕʹΑΓՃ଎౓ηϯαͰ͸‫ܭ‬ଌ͕ࠔ೉ͳϘʔϧʹՃΘΔ‫͍ڧ‬িܸΛ‫ݕ‬ग़ͨ͠ΓɺϘʔϧΛʮ৮ΔʯɾʮѲΔʯ౳ͷϘʔϧʹ֎ྗΛՃ͑ΔཁૉΛ࣋ͭϓϨΠϠʔͷ਎ମಈ࡞Λ‫ݕ‬ग़͢Δ͜ͱ΋ՄೳʹͳΔͱࢥΘΕΔɻ͜ΕΒͷϘʔϧ಺ηϯαΛ༻͍ͨ‫ݕ‬ग़ٕज़ͷ։ൃʹ͍ͭͯ͸Ҿ͖ଓ͖ߦ͍ͬͯ͘༧ఆͰ͋Δɻ՝୊ͱల๬ؔ࿈‫ڀݚ‬

ηϯα಺ଂϘʔϧ‫ڀݚ‬ͷ୅දతͳ΋ͷͱͯ͠ɺࣇ
‫ۄ‬Βͷ௓Ͷ੕͕͋Δ [2]ɻ௓Ͷ੕͸ηϯαྨΛಁ໌ΰϜͰ෴͏͜ͱͰอ‫͍ͯ͠ޢ‬Δ͕ɺΰϜ૚͕ް͘ͳΔͱϘʔϧࣗମ͕ॏ͘ͳΔͱ͍͏ܽ఺͕͋Δɻ࣍ʹɺηϯα಺ଂͷτϨʔχϯά༻όεέοτϘʔϧ
94Fifty[3] ͕։ൃ͞Ε͍ͯΔɻ94Fifty Ͱ͸ɺηϯαϞδϡʔϧ͸ඇৗʹখ‫͋Ͱܕ‬Γόϧϒ෦෼ʹ૷ண͞Ε͍ͯΔ͕ɺՃ଎౓ηϯα౳͕Ϙʔϧճస࣌ʹൃ
ੜ͢Δԕ৺ྗͷӨ‫ڹ‬Λड͚ΔͨΊɺηϯα͸Ϙʔϧத৺ʹҐஔͨ͠ํ͕ཧ૝తͱߟ͑Δɻ·ͨɺAdidasͷ Smart Ball[1] ͷΑ͏ʹॊೈੑͷ͋Δඥ (λΠ) ঢ়ߏ଄෺Λ༻͍ͨ‫ݻ‬ఆํ๏΋ଘࡏ͢Δɻຊ‫͍༻Ͱڀݚ‬͍ͯΔίΞ૷ணࣜόϧʔϯΛ༻͍ͨख๏͸ɺϘʔϧͷத৺ʹηϯαΛ‫ݻ‬ఆ͢ΔΑΓ҆ՁͰ༰қͳख๏Ͱ͋ΓɺϘʔϧ಺ଂηϯα։ൃͷͨΊͷϓϩτλΠϐ
ϯάʹ΋ద͍ͯ͠Δͱߟ͍͑ͯΔɻ࠷΋खܰͳख๏
ͱͯ͠ൃ๒΢Ϩλϯ੡ϘʔϧΛ੾Γ։͍ͯηϯαΛ
಺ଁ͢Δख๏΋͋Δ͕ɺۭ‫ࣜؾ‬ͷϘʔϧͱൺֱͯ͠
஄ྗੑʹྼΓɺॏ͞΍ख৮Γ΋ಠಛͰ͋Δͱ͍͏໰୊͕͋Δɻࢀߟจ‫ݙ‬[1] addidas. addidas Smart Ball, May 2013.
[2] O. Izuta, J. Nakamura, T. Sato, S. Kodama,
H. Koike, K. Fukuchi, K. Shibasaki, and
H. Mamiya. Digital sports using the ”Bouncing Star” rubber ball comprising IR and full-color
LEDs and an acceleration sensor. In ACM SIGGRAPH 2008 new tech demos, SIGGRAPH ’08,
pp. 13:1–13:1, New York, NY, USA, 2008. ACM.
[3] I. S. Technologies. 94Fifty Basketball, March2013.

ਤ 3. ηϯαϢχοτ (ӈ) ͱͦͷߏ੒ (ࠨ)- 178 -WISS2013

Overview Scrollbar: ページ全体を概観として表示するスクロールバー
溝口 晃

坂本 大介

五十嵐 健夫∗

概要. 画面に収まり切らない縦長のドキュメントを表示する際，多くのアプリケーションは画面の端にス
クロールバーを表示する．しかし，現在使用されているスクロールバーの殆どは古典的なものであり，改善の余地が多分に存在する．本研究ではひとつの改善策として，スクロールバー上にページ全体の概観を表示する手法，Overview Scrollbar を提案する．このような手法を取った時，縦長のページを閲覧する場合に概観をどのように縮小して表示するのかが問題となってくる．なぜなら縦長ドキュメントのアスペクト比を維持しつつ概観を表示しようとすると，その横幅が非常に細くなってしまうからである．我々はドキュメン
トの長さに関わらず概観の横幅を一定に保って可読性を維持するために，部分的に縮小率を変化させて概観を描画する手法を新たに提案し，Overview Scrollbar の性能や問題点を調査するためにユーザスタディを
実施した．

(a)

図 1. ドキュメントと Overview Scrollbar

1

(c)

(d)

図 2. (a)Uniform Scaling (b)Vertical Compression (c)Fisheye (d)Perspective

はじめに

現在使用されているスクロールバーの多くは，ドキュメントの表示領域を狭めないようにウィンドウの端に細長く表示されるようになっている．しかし，
近年ディスプレイの解像度が上昇し，また横長のディスプレイが増えてきているため、必ずしもスクロー
ルバーを細長く表示する必要は無くなってきている．
そこで我々は，ページ全体の概観を縮小して表示する幅の広いスクロールバー，Overview Scrollbar を提案してきている (図１)[2]．
Reader’s Helper[1] や Popout Prism[3] では我々の Overview Scrollbar と似たインタフェースが実装されているが，これらはドキュメントが縦長の場合にどう概観を縮小するのかという問題について深く言及していない．そこで我々は，単純な２種（Uniform
Scaling, Vertical Compression）に加え，新たな縮∗(b)Copyright is held by the author(s).
Ko Mizoguchi, Daisuke Sakamoto, and Takeo Igarashi
東京大学大学院情報理工学系研究科- 179 -

小方法を取り入れた２種のスクロールバー（Fisheye, Perspective）を実装し，計４種の Overview
Scrollbar の性能や問題点を調査するためにユーザ
スタディを実施した．

2

提案手法

我々は，概観の縮小方法別に４種類のスクロールバー（Uniform Scaling, Vertical Compression,
Fisheye, Perspective）を設計した (図２)．以下に，それぞれのインタフェースがどのようにドキュメン
トを縮小して概観を表示するか述べる．
(a)Uniform Scaling: ドキュメントのアスペ
クト比を維持して縮小する．そのため，ドキュメン
トが縦長の場合にスクロールバーが細くなってしまう事がある．
(b)Vertical Compression: 基本的にはドキュ

WISS 2013

図 3. 実験結果: (左) タスクにかかった時間の平均 (右) アンケート結果の平均

メントのアスペクト比を維持するが，横幅はウィン
ドウの 20%に固定されており，ドキュメントが一定
以上縦長の場合，縦方向にのみ縮小する．
(c)Fisheye: スクロールバー上に焦点領域と背景領域が存在する．焦点領域ではアスペクト比を維持して概観を比較的大きく表示する一方で，背景領域では縮小率を徐々に上げて行き，魚眼レンズのよ
うな視覚効果を出す．ユーザはスクロールバー上で右クリックすることで，焦点領域を自由に動かすことが出来る．
(d) Perspective: 基本的には Fisheye と同様のインタフェースとなっているが，Perspective では全体を通して横幅が一定で，ウィンドウの横幅の20%に固定している．

3

はその中から指定された条件に合う変数を探してクリックする．

3.2

アンケートを通じて参加者の好みを収集した．使いやすさ・使い慣れやすさ・適切さ・使いたさをそれぞれ５段階で評価してもらい，感想・印象などの任意のコメントも収集した．

4

ユーザスタディOverview Scrollbar の性能や問題点を調査するためにユーザスタディを実施した．参加者は 12 名
で全員従来のスクロールバーを使用した経験があった．スタディを通して，参加者がそれぞれのタスクにかかった時間を計測した．
3.1

アンケート

タスク

大きなドキュメントの中から，ある対象を探してクリックするタスクを４種類設計した．
(1) 画像探索: 参加者は初めに探す対象となる画像を提示され，その画像をドキュメント内から探してクリックする．
(2) 商品探索: 参加者は初めに探す対象となる商品を指定され，その商品をドキュメント内から探してクリックする．商品は色，形などの外見上の特徴を文章によって指定される．
(3) 往復: 参加者は大きなドキュメント上に設置された２つのリンクを，上下にスクロールしながら交互に合計 6 回クリックする．
(4) ソースコード探索: １つの変数がソースコー
ド中の全ての箇所でハイライトされており，参加者

結果とまとめ

実験結果を図３に示す．タスクにかかった時間では往復タスクに有意な差が確認され，従来のスクロー
ルバーが最も遅く，Vertical Compression が一番早かった．またアンケート結果では使いやすさでは
Fisheye，Perspective が低く評価され，慣れやすさ
では Vertical Compression が高く評価される傾向にあった．
全体を通して高性能だった Vertical Compressionは既に実用的であると考えられる．Fisheye や Perspective の性能はそれほど高くなかったが，焦点領域を移動するインタフェースをユーザにとってより直感的にすることで，性能が上昇する余地は存在すると考える．

参考文献[1] J. Graham. The reader’s helper: a personalized
document reading environment. In Proc. of CHI’99, pp. 481–488. ACM, 1999.
[2] K. Mizoguchi, D. Sakamoto, and T. Igarashi.
Overview Scrollbar: A Scrollbar Showing an Entire Document as an Overview. In Proc. of INTERACT ’13, pp. 603–610. Springer Berlin Heidelberg, 2013.
[3] B. Suh, A. Woodruff, R. Rosenholtz, and
A. Glass. Popout prism: adding perceptual principles to overview+detail document interfaces. In
Proc. of CHI ’02, pp. 251–258. ACM, 2002.

- 180 -WISS2013

行動ログの入力を支援するユーザインタフェースの設計と実装
鈴木 孝宏∗

美馬 義亮†

概要. 本稿では，スマートフォンを利用した行動ログの入力作業を支援するユーザインタフェースを提案
し，それを用いたプロトタイプシステムのアイディアを示す．ここで提案するユーザインタフェースは，現実世界に存在する様々な状況を一般化して二次元平面に構成したものであり，その平面をユーザがタップすることによって行動ログの入力を可能にするものである．このユーザインタフェースを用いたプロトタイプ
システムでは，ユーザのタップ操作をトリガーに行動を報告するテキストを自動的に生成し，行動を適切に言語化して記録可能にする．これにより，生成されたテキストを日記に使用したり，Twitter に投稿してライフログとするなど，行動記録を目的とした文章作成・入力にかかる負担を軽減できる可能性がある．

1

はじめに

本稿では，スマートフォンを利用した行動ログの入力作業を支援するユーザインタフェースを提案する．ここで提案するものは，現実世界に存在する様々な状況を二次元平面に構成したものであり，それをユーザがタップすることによって行動ログの入力を可能にするものである．このユーザインタフェース
を用いて実装したプロトタイプシステムでは，ユー
ザのタップ操作をトリガーに行動を報告するテキス
トを自動的に生成し，行動を適切に言語化して記録可能にする．これにより，日記の文章作成が容易になったり，Twitter に投稿してライフログとするな
ど，行動記録を目的とした文章作成・入力にかかる負担を軽減できると予想している．

1.1

スマートフォンを利用したライフログ

ライフログは，日常生活のすべてをデジタルデー
タで記録することである．デジタルで記録することにより，いつでも過去に遡って記憶を取り出せるメ
リットがある．記録のテーマは行動を書き留めた日
記にとどまらず，日々の食事，訪れた場所，体調管理，育児記録などと多岐にわたる．記録のためのツー
ルは，カメラや GPS 機能の付いたスマートフォン
であることが多い．スマートフォンではライフログを目的としたアプリケーションも多く存在し，人気の具合を知ることができる．
本稿で扱う行動ログは，日々の行動のすべてを記録するライフログであり，日記に近い．しかしながら，ログを記録しようとする度にテキスト入力や位置情報の入力などユーザの操作が必要で，記録にかかる負担が大きい．センサ情報を用いてログを自動記録するアプリケーションや，記録するテーマに合わせた独自のユーザインタフェースを備えたものも存在するが，記録がセンサ情報に限定されたり，言語化して記録できるものはまだ少なかったりと課題がある [1]．このことから，行動記録に必要な操作ス
テップを減らし，テキストも自動生成することにより，記録にかかる負担を軽減できると考える．
本稿で提案するプロトタイプシステムでは，スーパーマーケットでの行動記録を対象とした．行動記録を支援するためのユーザインタフェースを用い，少ない操作ステップでユーザの行動を適切に言語化する．このことにより，行動ログの記録にかかる負担の軽減，テキストとして記録する際の文章作成の負担を軽減する可能性がある．

2

行動ログの入力を支援するインタフェース

本稿で提案するインタフェースは，現実世界に存在する状況を二次元平面に構成し，タップ操作によって行動ログを記録できるようにしたものである．図
1 左の例では，スーパーマーケットに買い物に訪れた際に，どんな買い物をしたかを記録する用途に特化させたインタフェースを用いたプロトタイプシス
テムである．

店内マップ

品名表示領域

Copyright is held by the author(s).
公立はこだて未来大学大学院システム情報科学研究科†
公立はこだて未来大学システム情報科学部

図 1. スーパーマーケット店内のイラストによるインタ
フェース（左）と，パラメータ設定画面（右）∗- 181 -WISS 2013

2.1

インタフェースの設計

図 1 左で示したインタフェースは，スーパーマー
ケットの店舗全体の配置を表現している．これは，特定のスーパーマーケット店内を意図したものではなく，一般の店舗に共通して存在するコーナーを配置したものである．このことは，ユーザの持っている一般的な店舗イメージを反映していると言え，また特定の店舗に依存しない行動ログの記録を可能にしている．
画面最下部には 3 つのテキスト (品名表示領域) を配置した。ここに表示された 3 つの品名から 1 つをユーザが選択することで，購入する品物の数や大きさを決める画面（図 1 右）に遷移する．その画面で各パラメータを設定することで，行動ログとなる文書が自動的に生成される．

2.2

文章の生成

行動ログとなる文章は，予め用意したテンプレー
トに，品名・大きさ・数量を挿入することで生成している．今回のプロトタイプで生成する文章のテン
プレートは，「(大きさ)(品名) を (数量) 買った。」という形式で用意した．これによって，「大きいじゃがいもを 4 つ買った。」などの文章を自動で生成することが可能である．
品名については，ユーザに提示する店内全体のイ
ラストと対応する縦 10 ×横 10 のセルを持った商品名リストに用意してある（図 2）．店内イラストは拡大縮小して表示することが可能である．このため，品名表示領域に表示する 3 つのテキストは，画面に表示されているイラストの範囲に対応するリストからランダムにピックアップすることで表示している．
店内マップ（全体）

品名リスト

店内マップ（拡大）10 x 10 のセルを用意

図 2. 店内のイラストマップと商品名リストの対応

3
3.1

対してユーザの持っているイメージを崩さぬまま操作できる工夫であると言え，システム操作にかかる負担軽減にも繋がると考えている．
行動ログの負担軽減と記録できる行動の追加

3.2

ユーザの負担軽減のためには，ユーザの行動パターンを学習し，ユーザの次の行動を予測してユー
ザインタフェースを提示する必要がある．そのためには，スーパーマーケットだけでなく日常生活のあらゆる状況を二次元平面に構成し，感情も記録できるようにするなど，より多くの行動記録に対応することが課題である．記録できる行動が増えることで，ユーザの行動パターンを学習でき，その履歴から次に使用するインタフェースの予測が可能となる．
文章生成のアルゴリズムの検討

3.3

このシステムでは，行動記録となる文章のテンプ
レートと状況を関連づけているが，数多くの文章表
現に対応するには工夫が必要である．予め用意する
文章のテンプレートに多数の表現を持たせるには，正規表現で記述したテンプレートを用意する方法を用いることで，似たような意味や構造を持つ文章を大量に生成することができる．さらに，それらの文章をセンサ情報等をもとにフィルタリングすることで，より適切な文章生成が可能になると考えている．この考え方は，展開ヘルプ [2] で用いられた Generate
and Filter という手法を参考にしている．

4

まとめ

本稿では，スマートフォンを利用した行動ログの入力作業を支援するユーザインタフェースの設計と，それを用いて実装したシステムのアイディアを提案した．このシステムは，ユーザの行動記録にかかる
タップ操作を減らし，行動記録のテキストを自動的に生成する．システムが自動的に言語化することは，行動ログのための文章作成・入力にかかるユーザの負担軽減にも繋がる．記録できる状況・行動の種類が増えていけば，終日の行動記録をもとに日記を自動生成することも可能になり，日記執筆の負担軽減も可能になるのではないかと考えている．

謝辞
本稿における研究は IPA2013 年度未踏 IT 人材発
掘・育成事業の支援のもとで行われている。

今後の展望と課題システムの特徴と可能性

参考文献

本稿で提案した行動記録を支援するユーザインタ
フェースは，現実世界に存在する状況を二次元平面に構成するために，状況を一般化したイラストをインタフェースに用いた．これにより，特定の状況に依存せず，類似する様々な状況に対応できるものを設計できる可能性がある．このことは，ある状況に[1] C. G. Bell, J. Gemmell, and 飯泉恵美子. ライフ
ログのすすめ: 人生の「すべて」をデジタルに記録する!, pp.257-311, 早川書房, 2010.
[2] 増井俊之. 展開ヘルプ. インタラクション 2012 論
文集, pp.89-96, March 2012.

- 182 -WISS2013

ペイントアプリケーションにおけるタッチアクションを用いたエフェクトの
提案
武藤 寛

井川 裕貴

瀬川 典久

杉野 栄二

澤本 潤∗

概要. 近年タブレット端末が普及してきているとともに、タブレット端末用のアプリケーションを用いて絵を書く人が増えてきた。従来のペイントアプリケーションでは、画面上のキャンバスの上部や側部にペンの種類や色、太さを変更するためのツールバーが表示されている。しかし、これらの機能性が操作を複雑にし、自由な発想を妨げていた。そこで本研究では、シンプルなインターフェースを持つ enchantMOON を用いて、自由な発想を実現する操作方法として手を使った鉛筆エフェクトを提案する。

1

はじめに

本格的なイラスト描画を行うデジタルデバイスとしてペンタブレットや液晶タブレットが挙げられる
が、近年タブレット端末が普及してきているとともに、タブレット端末用のアプリケーションを用いて絵を書く人が増えてきた。タブレット端末で絵が描ければ、改めて機材を買い揃える必要がなく、趣味や遊び目的で絵を描く人にも容易に環境が整う。
従来のペイントアプリケーションでは、インターフェースとしてウィンドウの中央に描画用のキャンバスがあり、上部や側部にツールバーというレイア
ウト構成がほとんどである。それらのツールを使って描いたものに対してエフェクトをかけるが、その操作は直感的なものではなく、使い方を覚える必要がある。これでは単純に絵を書くことが目的であるのにも関わらず、手間が増えてしまった。そして、この手間がユーザにストレスを感じさせていた。デッサンやアイディアスケッチの場合このようなストレスを感じることは発想の妨げになってしまう。
本研究ではシンプルなインターフェースを持つ
enchantMOON を用いて、自由な発想を実現する
操作方法として手を使った鉛筆エフェクトを提案する。具体的にはツールバーの代わりに手によるタッチイベントを用いる手法である。ここで手を使う意
味として、現実世界で絵を描く際に紙と鉛筆を使うというシチュエーションを想定している。筆跡の周りをぼやかしたいときは紙を指で擦るようにデジタ
ルデバイスも画面を擦ることでぼやけるのが理想だと考えた。
今回の研究で用いた enchantMOON は iPad や
Android タブレットとは異なる斬新なインターフ
ェースで話題を呼んだ。iPad や Android について
も従来のパソコンと比べて直感的な操作が可能ではあるが、まだまだ使いこなせないという声も多く耳Copyright is held by the author(s).
∗
岩手県立大学ソフトウェア情報学部- 183 -にする。そこで本研究の延長で鉛筆に限らずに様々なエフェクトについても現実世界に近いアクション
で行うことにより、デジタルデバイスをアナログと同様な操作ができればユーザへの負担を解消できると考えられる。

2

関連研究ペイントアプリケーションのツール選択のイン
ターフェースとしてユーザが自由にレイアウトを変更できるシステム [1] や音声入力を用いる研究 [2] がある。音声入力を用いる手法ではオノマトペを用いることで、感覚的にツールを選択することができ、絵を描く事が楽しくなる。音声入力では場所を選んでしまうという欠点があった。本研究では手の動作を用いることでこの欠点を改良することができた。

3

enchantMOON

本研究で用いる enchantMOON[3]（図 1）とは、ユビキタスエンターテイメント社が開発したタブ
レット端末である。ほとんどの操作をデジタイザー
ペンによる手書きと指のタッチ（図 2）のみで行う
シンプルなインターフェースである。筆跡ストロークのデータ構造は、X,Y の座標と筆圧の 3 つで構成されていて JSON 形式で保存される。ストロー
クはオブジェクトとして扱うことができ、さらに、
JavaScript で記述したプログラムを機能として追加することができる。本研究の実装にあたってこのイ
ンターフェースとストロークに対する動作への機能追加の容易性から、enchantMOON が最適であると考えた。、

4
4.1

提案するシステム構成
システム概要本システムは enchantMOON のシールを用いて機能を追加するので、JavaScript で実装される。以WISS 2013

ることができた。

5

まとめと今後の課題

本研究では enchantMOON を用いて、自由な発想を実現する直感的な操作方法として手を使った鉛筆エフェクトを提案・試作を行った。これによりユー
ザは現実世界に近い紙と鉛筆を用いる感覚でデッサ
ンやアイディアスケッチが可能となる。
今後はエフェクト処理について調査を進めて、より鉛筆に近い表現ができるように改良を加えていきたい。

図 1. enchantMOON 全体図

参考文献[1] 飛田博章 磯 大輔 暦本淳一 VelvetPath:スケッチとペイント操作によるレイアウトデザインシステム,
情報処理学会論文誌 44(11), 2528-2537, 2003-1115[2] 神原 啓介 塚田 浩二 オノマトペン 第 16 回インタ
ラクティブシステムとソフトウェアに関するワー
ク ショップ (WISS2008), http://www.wiss.org/
WISS2008Proceedings/papers/paper0023.pdf

図 2. enchantMOON における指での指示例[3] enchantMOON ; The Hypertext Authoring
Tablet http://enchantmoon.com/

下に動作フローを示す。図 3 に、本システムの動作を示す。

1. ペンで絵を描く。
2. タッチしてシールを実行。
3. 指で筆跡を擦る。
4. 擦った部分の筆跡がぼやける。
本システムは、ペンで書くという動作と擦るという動作を区別する。それぞれペンイベントとタッチ
イベントで異なる処理を施す。ペンイベントでは描画を行う。タッチイベントでは指が画面に接したタッ
チダウンイベント、そこから移動するタッチムーブ
イベント、指を離すまでのタッチアップイベントの3 段階に分けられる。エフェクト処理はムーブイベ
ントに対して行う。
エフェクト処理はプロトタイプのため筆跡スト
ロークデータの筆圧を下げることで、筆跡を薄くす

図 3. 本システムの動作フロー- 184 -WISS2013

デジタルコンテンツ生成のためのクラウドソーシングによるパラメタ最適化
小山 裕己

坂本 大介

五十嵐 健夫∗

概要. 写真補正，スライドの作成，CG 技術による画像生成など，多くのデジタルコンテンツ制作の過程には，パラメタ最適化，すなわち最適なパラメタセットを探索するという作業が含まれている．この作業は，人間の美的感覚に基づいて実行されるため，機械のみによって自動化することが困難である．本研究では，クラウドソーシング技術によるヒューマンコンピュテーションを用いることで，このようなパラメタ最適化を自動化する手法を提案する．我々の手法は，最適化のために必要なタスクを，2 つのパラメタセット
間の相対的なランク付けという単純なマイクロタスクに分割するという点が特徴的である．

1

はじめに

CG 技術を用いて画像や映像を制作する際，制作者は各種パラメタの微調整に多くの時間を取られることが問題となっており，多くの研究者がこの問題に取り組んでいる．また CG 技術に限らず，一般のデジタルコンテンツ生成においてもこのようなパラ
メタ最適化の作業が多く見られ，専門家，一般ユー
ザ問わずこのような作業には多大な時間をとられてしまう．こうしたパラメタ最適化は機械による自動化が困難であることが多い．その理由は，パラメタセットの良し悪しの評価が人間の美的感覚に基づいていることが多いためであると考えられる．
そこで本研究では，特に近年注目されているマイクロタスク型のクラウドソーシングを用いたヒュー
マンコンピュテーションをシステムの内部で活用することにより，従来は困難であった美的感覚に基づ
くパラメタ最適化の自動化を行う手法を提案する．

2

関連研究

ヒューマンコンピュテーションとは，人間を明確に計算資源と見做して問題解決の手段として用いることである．またクラウドソーシングとは，不特定多数の人からなる群衆 (crowd) に対し，主にインター
ネットを通して業務を外部委託 (outsourcing) することである．近年，Amazon Mechanical Turk1 な
どのサービスの登場により，例えば数秒から数分程
度で終えることができるような非常に小さなタスク，
すなわちマイクロタスクを，数百や数千という大量のワーカに安価に行ってもらうなどといった，大規
模かつ流動的な雇用が可能となっている．
このようなマイクロタスク型クラウドソーシングを用いてヒューマンコンピュテーションを実現する
Copyright is held by the author(s).
Yuki Koyama, Daisuke Sakamoto, and Takeo Igarashi,
東京大学1
http://www.mturk.com/∗- 185 -という研究が近年多く提案されている [3]．これらの研究の多くは，コンピュータビジョン，自然言語
処理，データベースにおけるタグ付け処理，機械学
習における教師データの生成などにクラウドソーシ
ングを活用するという，主にコンテンツの理解のための研究に分類される．本研究の目的はコンテンツの理解ではなく生成であり，これらの研究とは目的
が異なる．

3
3.1

提案手法
想定するパラメタの種類

本研究で対象とするパラメタとは，写真補正における明るさやコントラスト，CG におけるマテリア
ルの設定，カメラの姿勢，要素の配置，手続き的モ
デリングのパラメタなど、コンテンツ生成のためにユーザが指定する連続的な値の集合である．特に数百次元や数千次元といった，パラメタ空間の次元が高い場合も想定する．

3.2

マイクロタスク

クラウドソーシングでは不特定多数の人間にタスクを委託するため，タスクそのものは特別なスキルを必要としないできるだけ単純なタスク，すなわちマイクロタスクとすると効果的である [2]．そこで本研究でもマイクロタスクを採用する．
まず，対象とするパラメタ空間からランダムに 2点選出し，それぞれのパラメタセットに対応する画像を生成しておく．それぞれのマイクロタスクでは，
これら 2 枚の画像を同時に見せ，相対的にどちらの方が「好み」の度合いが大きいかを点数付けしてもらう．Gingold ら [2] や Chaudhuri ら [1] の手法と同様に，度合いの相対値を点数付けしてもらうことによって，1 枚の画像に対して度合いの絶対値を点数付けしてもらう場合よりも，より妥当な結果が得られることが期待される．

WISS 2013

3.3

パラメタ空間の解析

上述のマイクロタスクによって得られるデータは，パラメタ空間における 2 点における相対的な「好み」の度合いの差の集合である．このようなデータから，パラメタ空間全体の「好み」の分布を推定するために，本手法では適切なエネルギーを定義し，エネル
ギーの最小化問題として定式化するというアプロー
チをとる．エネルギーの定義は，連続的なパラメタ空間を扱うという仮定から近傍のパラメタセットの「好み」の度合いをスムージングする項，及び「好み」の度合いの相対的な差を保つような制約を表す
項の 2 つを足し合わせたものとする．

4

図 1. 実際のタスクの様子．

実験

本研究のアプローチの妥当性を確認するため，写真補正を例に簡単な実験を行った．今回の実験では，
明るさ，コントラスト，彩度の 3 つのパラメタからなるパラメタ空間を対象とした．
クラウドソーシングのプラットフォームとしては，CrowdFlower2 で利用可能な全てのサービス，地域を対象とした．また，クラウドソーシングにおける回答の品質管理については，本実験では duplicationと呼ばれる手法 [2] を使用した．

(a)

(b)

図 2. (a) 元の写真．(b) 実験で得られた最適なパラメ
タセットに基づいて生成された写真．
高

条件： 今回の実験ではパラメタ空間中から 2000 点をランダムにサンプリングし，その中からランダムに 2 点ずつペアにして，合計で 1000 ペアについての比較結果を集めた．図 1 に比較，及び評価を行う
ために実際に使われた画面の例を示す．
結果： 図 2 (a) に示す写真を入力として実験を行った結果として推定された最適なパラメタセットを元に，図 2 (b) に示す写真が得られた．本実験では合計
で 4.00 USD の報酬がクラウドワーカに支払われた．

5

考察

我々は実験結果としてある程度期待通りのものが得られたと考えているが，コンテンツ生成には厳密な正解があるわけではないため，本手法の妥当性の評価方法は本研究の大きな課題であると考えている．
また本手法の有用性の評価としては，機械による自動最適化との比較，及び同額の報酬という条件下でクラウドによって生成された結果と専門家によって生成された結果との比較という 2 つの方法を考えている．
手法の改善課題としては，パラメタ空間において最適解が存在すると思われる領域を重点的にサンプリングすることによって，より少ない比較回数で，結果としてより安価に同等の結果を得ることができると考えている．そのために，前のクラウドワーカの2

http://crowdflower.com/- 186 -

低

図 3. 推定した「好み」の度合いを可視化した様子．横軸は明るさ，縦軸はコントラストを表している．こ
こでは二次元画像として可視化するため，彩度に関して適切な断面を選び，その付近を表示している．

回答結果を元に，次のクラウドワーカのタスクを動的に生成するような手法を考案していく予定である．

参考文献[1] S. Chaudhuri, E. Kalogerakis, S. Giguere, andT. Funkhouser. Attribit: content creation withsemantic attributes. In Proc. of UIST ’13, pp.
193–202, 2013.
[2] Y. Gingold, A. Shamir, and D. Cohen-Or. Microperceptual human computation for visual tasks.
ACM Trans. Graph., 31(5):119:1–119:12, 2012.
[3] A. J. Quinn and B. B. Bederson. Human computation: a survey and taxonomy of a growing field.
In Proc. of CHI ’11, pp. 1403–1412, 2011.

WISS2013

UnReC：文字入力に基づいた Undo/Redo
大江 龍人

志築 文太郎

田中 二郎∗

概要. テキストエディタの Undo/Redo では，ボタンやショートカットを用いて履歴を一度ずつ操作する
手間があり，Undo/Redo 操作後に文章を上書きした際 Undo/Redo が不可能な場合がある．この問題を解決するために，我々は履歴から任意の時点を選択し Undo/Redo を行うことが可能であるインタフェースの有効性を調査している．現在，この目的のために文字入力に基づいた Undo/Redo インタフェースである
UnReC を開発している．UnReC を用いることにより，ユーザは過去に入力した文字列をキーとして履歴内を検索し，その時点まで Undo/Redo を行うことが可能である．本論文では UnReC を用いた操作手法と実装を示す．

序論

1

履歴から任意の時点を選択する Undo/Redo を可能にした Selective Undo [1] は，選択した時点のみの Undo/Redo を可能にしたが，一般的な線形の履歴に対応していない．また Regional Undo [2] は，一部の範囲内のみに Undo/Redo の対象を絞ることを可能にしたが，任意の時点に戻ることが出来ない．
任意の時点に戻ることが可能である木構造の履歴に対応したものとして，Emacs の Undo Tree1 や Vimの Gundo2 が挙げられる．しかし，これらの環境においてユーザは，ある時点へ到達するために木を探索する必要がある．
我々は履歴から任意の時点を選択し Undo/Redoを行うことが可能であるインタフェースの有効性を調査している．現在，この目的のために文字入力に基づいた Undo/Redo インタフェースである UnReCを開発している．図 1b に示す様に UnReC を用いる
ことにより，ユーザは過去に入力した文字列をキーとして履歴内を検索し，その時点まで Undo/Redoを行うことが可能である．なお，我々は UnReC の名前を Undo/Redo by Characters Input（文字入力に基づいた Undo/Redo）の頭文字から命名した．

テキストエディタにおいて Undo/Redo を行う場
合，ユーザは図 1a に示す様に線形の履歴から一度ずつ操作する．この Undo/Redo 操作において目的の時点へ Undo/Redo を行うためには，ユーザは複数回の操作を用いて履歴を探索する必要がある．またこの環境では，履歴から任意の時点を選択することが出来ないため，複数回の操作を用いて履歴を探索する手間がある．さらに，ユーザが Undo/Redo
操作後に文章を上書きした際 Undo/Redo が不可能な場合がある．

a

TargetHistory
Traditional Undo/Redob

Input shortcut

History2

UnReC

UnReC を実際に使用している例を図 2 に示す．
図 2 に示す様に，ユーザはテキストエディタと共に
UnReC を使用する．UnReC の文字入力フォームに文字列を入力すると，過去の文字入力時点のスクリーンショットが閲覧出来る．そのスクリーンショッ
トをマウスクリックすることにより，その時点まで
Undo/Redo することが可能である．

Reach the past point using characters input
UnReC
図 1. a）通常の Undo/Redo，b）UnReC を用いた
Undo/Redo．

Copyright is held by the author(s).
Tatsuhito Oe, 筑波大学大学院システム情報工学研究科,
Buntarou Shizuki and Jiro Tanaka, 筑波大学システム情報系
1
http://www.emacswiki.org/emacs/UndoTree
2
http://www.vim.org/scripts/script.php?script_
id=3304∗

3

UnReC の応用
UnReC の応用として「簡易なバージョン管理」と「過去の文章の再利用」が挙げられる．それぞれ
以下に説明する．

- 187 -WISS 2013
履歴から「コミット」と入力した時点を検索

a

関数を定義

b
c

定義した関数を参照

図 3. 過去の文章の再利用例．a）コーディング中に関数を定義する，b）必要な際に定義した関数を参照す
る，c）過去の関数を現在のコードに再利用する．

図 2. UnReC の使用例．この例において，ユーザは「コミット」と文字入力した時点を履歴から検索し，そこまで Undo を実行しようとしている．

UnReC を用いることにより，あらかじめメタな文字列を入力し，その時点まで Undo/Redo を行う
簡易なバージョン管理が実現可能である．例えば図 2において，ユーザはコーディング中に戻りたい時点を定義するために「//ここでコミット 1」や「//コ
ミットしとく 2」等の文字列を入力している．その後 UnReC の文字入力フォームに「コミット」と入力し時点を検索する．最後に，出現したスクリーン
ショットをマウスクリックすることにより，コミッ
トした時点まで Undo 可能である．
UnReC の別の応用として，図 3 に示す過去の文章の再利用がある．この例においてユーザはコーディ
ング中に関数を定義し（図 3a），その後，関数が不要だと考え削除し，数時間コーディングを続けているものとする．ここで改めて関数が必要になった場
合，ユーザは UnReC の文字入力フォームに関数名や定義時のコメントを入力し（図 3b），UnReC 上に表示されるスクリーンショットをクリックしさえすれば，過去の関数の参照及び再利用が可能である（図 3c）．

4「全文章」，「スクリーンショット」から構成される．
この保存処理は，通常の Undo/Redo では削除される文章も全て保存するため，任意の時点におけるUndo/Redo が可能になる．
検索：UnReC の入力フォームに文字列が入力されると，システムはその文字列が検索用の 1 行文字列に含まれているか否かの判定を行う．含まれている
場合，保存したスクリーンショットを表示する．この際スクリーンショットの順序は，1 行文字列と入力フォームの類似度順にて表示される．ユーザがスクリー
ンショットを選択すると，システムは Undo/Redo
処理を実行する．
Undo/Redo 処理：現在の全文章を全て削除し，過去の全文章を貼り付けることにより，Undo/Redo
を行う．

実装

UnReC の実装は保存，検索，Undo/Redo 処理から構成される．今回，我々は Ubuntu 上の Gedit
テキストエディタのプラグインとして UnReC を実装した3 ．
保存：エディタにおいて 1 行分の文字列が入力されるごとに，システムはその時点における状態を保存する．保存する内容は，「検索用の 1 行文字列」，
3

関数の再利用

svn checkout https://subversion.assembla.com/
svn/oe_public_projects/Gedit_UnReC

5

結論と今後の発展

本論文では，履歴から任意の時点を選択し Undo/
Redo を行うことが可能であるインタフェースである UnReC を示し，さらに UnReC を用いた操作手
法と実装を示した．
今後は UnReC を様々なユーザに使用してもらう．
実際に使用したユーザの意見を反映させることにより，UnReC をより実用的なシステムとする．

参考文献[1] T. Berlage. A Selective Undo Mechanism for
Graphical User Interfaces Based on CommandObjects. ACM Trans. Comput.-Hum. Interact.,
1(3):269–294, 1994.
[2] Y. Kawasaki and T. Igarashi. Regional Undo for
Spreadsheets. In Proc. UIST 2004 Demostration
Abstract, pp. 1–2. ACM, 2004.

- 188 -WISS2013

どこでも「いいね！」ボタン:位置評価情報の提示によるユーザの興味に関する研究佐々木 佳祐寺田 実∗

概要. ニュースや新聞から得られる情報には速さと正確さが求められるが, 新製品やイベントなどの情報を公開する側は, ユーザの興味を引きつけておくためにあえて少ない情報を公開するという方法を選ぶことも多い. そこで本稿では,「入手するまでの速度は速いが内容がある程度隠れている情報」はユーザの興味を引くであろういう仮説を立てた. さらに, 仮説の検証のために適していると思われる情報として緯度や経度といった位置情報に着目し, スマートフォン上に現在地点に関する好感/嫌悪感の二値評価を投稿, 集約,
表示するアプリケーションを作成, 運用することで, 仮説の妥当性について考察を行った.

1

はじめに

仮説 1. 実世界においてユーザは, 自分以外の誰かが「良い」「悪い」といった評価を下したある地点について何らかの興味を持つはずである

昨今の情報通信技術と Twitter を始めとするソー
シャルネットワーキングサービスの普及により, 「今,どこで何が起きているのか」という情報を限りなくリアルタイムに取得することが可能となってきている. ネットワークを通じて友人の行動や催し物の情報を把握し, その日の予定を立てるといったことも珍しくない.
一方, 新製品やイベントの情報などを公開する側の情報提供者は, 情報の一部を隠しつつ小出しに公開する, という手法を用いる場合がある. 代表的な例として「ティザー広告」という手法が挙げられる.
広告は一般的に, 商品の名称や機能, 外観, 価格などのセールスポイントとなる部分を打ち出すものだが,ティザー広告では具体的な情報を敢えて隠し, 消費者が能動的に注意を向けることを目的としている. 大
手企業やイベントなど, ブランド力の高いベンダーによるティザー広告は, それ自体が大きな話題となる場合も多い.
以上 2 つの要素を組み合わせると,「リアルタイ
ムでありながら一部が隠れている情報」は, 正確な情報の全貌が明らかになるまでは消費されず残るために情報の寿命が長く, よりユーザの興味を引けるのではないかと考えられる.
そこで本稿では, 情報を制限することによるユー
ザの興味について以下の 2 つの仮説を立案し, 仮説を基にした「最もユーザ興味を引くことのできる情報の隠し方」について検討するため, 我々の生活において身近な情報である緯度, 経度の情報を利用した実世界におけるリアルタイムな位置評価情報共有システムを提案, 手始めに情報の隠蔽度を最大限に高めたシステムを実装し, 運用実験を行った.
∗

仮説 2. ある地点で起きている事象全ての情報と, 仮
説 1 における二値の情報の間に, ユーザの興味を最も換気するポイントが存在する

2
2.1

提案システム概要

本研究における仮説を検討するために,「実世界における位置評価情報共有システム」を提案する (図1). システムは,GPS 機能を持った携帯端末から, ある緯度および経度に対して, ユーザがその位置に対して抱いた「好感」または「嫌悪感」の二値の情報を収集する. また, 収集された二値の情報は, システ
ムが表示する地図上に散布される (図 2(a), 2(b)).
本システムでは, 仮説 1 における「リアルタイム性」と「制限された情報」の両者を満たしていると考えられる. リアルタイム性においては,• 地図を開いた際にリアルタイムな評価の情報がすぐに取得できる情報の制限という面では,• 「誰が」評価したのかわからない• 「何故」評価されたのかわからない• そこに「何があるのか」は実際に行ってみないとわからないという点が挙げられる. ユーザに提示される情報はあくまで「誰かが好感, または嫌悪感を抱いた位置」
のみである. 情報を敢えて二値に設定することで,実際にその場で何が起こっているのかをユーザに想起させる狙いがある. この「制限された情報」が提示された際にユーザがどのような行動を起こすかを,実際にシステムを運用して明らかにしていく.

Copyright is held by the author(s).
Keisuke Sasaki and Minoru Terada, 電気通信大学大学
院 情報理工学研究科- 189 -WISS 2013

2.3

運用

アプリケーションを実際に公開し, 不特定多数のユーザにアンケート調査を行ったところ, 他人の評価について興味を持ったユーザ数は 4 割に上った.
しかしながら実験に参加したユーザ数は 17 名と統計的なデータとするには不十分な値であったため,
実験方法の見直しやアプリケーションの機能の洗練が今後の課題となった.

3

本システムが目指す地点は, 「ユーザがアプリケー
ションを起動すると常にどこかの位置に評価データが集中しており, 近場であれば足を運び, 距離がある
場合はその地点で何が起きているのか能動的に調査を行う」という状況を発生させるところにある. そのためには莫大なユーザ数が必要となるが, twitterや Foursquare など既に普及している SNS のデータを用いるなどして規模を拡大していく.
また, ユーザの興味を最も喚起させられる適度な情報の隠し方を探るために, さまざまな手法を考案,
実装, 実験を行う. 現在,「実際に足を運ぶ」ことが容易なシチュエーションである学園祭での実験を計画しており, そのために位置精度の向上, 低解像度に加工された写真の添付といった機能追加を行っている.

図 1. システムとユーザの振る舞い

4(a) 地図及び評価アイコン (b) 評価送信後のフィード
バック画面
図 2. 実装したアプリケーションの画面

2.2

今後の展望

スマートフォン用アプリケーション

近年爆発的に普及しているスマートフォンはそのほとんどが GPS 機能, 地図表示機能を搭載しているため, システムはスマートフォン用アプリケーションとして実装するのが望ましいと思われる. そこで提案システムは, スマートフォンに備えている地図表示機能を拡張し, 地図および評価情報の散布表示
機能, またユーザの現在地の評価情報を送信する機能を備えたアプリケーションとして設計を行った.
アプリケーションは以下の機能を備えており, 今
度も機能追加を行う.

• 評価データの送受信• 自身の評価データ送信履歴• 評価データに対するリアクション機能
リアクション機能とは, 散布された評価データに対し「同意」のリアクションを送信することが可能となっている. 自身が行った評価にフィードバックがあることで, 評価データの送信を促進する狙いがある.
リアクションの形式についても今後検討していく.

- 190 -

まとめ

本研究では, 実世界におけるある地点について, 敢
えて情報を制限してユーザに提示することで興味を引けるのではないか, という仮説に着目し, ある地点について誰かが好感, または嫌悪感を感じているという情報のみを提示する手法を提案し, Android
OS 用のアプリケーションとして実装した. 実装したシステムを運用し, 可能性, 有効性, 問題点などを明らかにした. 今後は被験者を増やし, 大人数によるユーザテストを実施する予定である. また, 情報の制限量を変更した際にユーザが抱く興味にどのような相関が現れるか, といった調査も引き続き検証
していく.

WISS2013

SmarTrackBallɿεϚʔτϑΥϯͷΞ΢τΧϝϥΛ༻͍ͨτϥοΫϘʔϧਂ௡ Ղஐࢤங จଠ࿠ాத ೋ࿠∗

֓ཁ.
εϚʔτϑΥϯͷΞ΢τΧϝϥΛ༻͍ͯτϥοΫϘʔϧͱಉ༷ͷૢ࡞ΛՄೳͱ͢ΔγεςϜ
SmarTrackBall ʹ͍ͭͯࣔ͢ɽSmarTrackBall Ͱ͸ɼϢʔβ͸εϚʔτϑΥϯͷഎ໘Ͱૢ࡞Λߦ͏ͨΊɼεϚʔτϑΥϯͷը໘Λ࠹͙͜ͱͳ͘ૢ࡞Λߦ͏͜ͱ͕Ͱ͖ΔɽՃ͑ͯɼϋʔυ΢ΣΞΛண୤Ͱ͖Δɼ·ͨɼยखͰૢ࡞Ͱ͖Δͱ͍͏ར఺Λ࣋ͭɽຊγεςϜͷϓϩτλΠϓΛ࡞੒͠ɼຊγεςϜΛ༻͍ͨ 2 छྨͷΞϓϦέʔγϣϯΛ࡞੒ͨ͠ɽ

1

͸͡Ίʹ

ैདྷͷεϚʔτϑΥϯૢ࡞ʹ͓͍ͯ͸ɼओʹɼλονεΫϦʔϯʹࢦΛ৮ΕΔ͜ͱʹΑΔλονૢ࡞͕ߦΘΕΔɽ͜Εʹର͠ɼεϚʔτϑΥϯʹγϯϓϧ
ͳϋʔυ΢ΣΞΛ௥Ճ͢ΔͷΈʹΑΓɼλονૢ࡞Ҏ֎ͷଟ༷ͳૢ࡞ΛՄೳʹ͢Δ‫ߦ͕ڀݚ‬ΘΕ͍ͯΔɽզʑͷఏҊγεςϜ SmarTrackBall Ͱ͸ɼεϚʔτϑΥϯͷΞ΢τΧϝϥ্ʹϚʔΧ෇ͷΞΫϦϧϘʔϧΛ࣋ͭϋʔυ΢ΣΞΛऔΓ෇͚Δ͜ͱʹΑΓɼτϥοΫϘʔϧͱಉ༷ͷૢ࡞ʢҎԼɼτϥοΫϘʔϧૢ࡞ʣΛՄೳʹ͢Δɽ
ຊߘͰ͸ɼSmarTrackBall ͷ֓ཁɼϓϩτλΠϓ
ͷઃ‫ܭ‬ɼΞϓϦέʔγϣϯʹ͍ͭͯड़΂Δɽ
ਤ 1. SmarTrackBall

2ؔ࿈‫ڀݚ‬

εϚʔτϑΥϯʹγϯϓϧͳϋʔυ΢ΣΞΛ௥Ճ͢ΔͷΈʹΑΓɼλονૢ࡞Ҏ֎ͷଟ༷ͳૢ࡞ΛՄ
ೳͱ͢Δ‫ߦ͕ڀݚ‬ΘΕ͖ͯͨɽYu Β [4] ͸ɼλονεΫϦʔϯͷ୺ʹಋిੑΰϜͰͰ͖ͨ෺ཧϘλϯ Clipon Gadgets ΛऔΓ෇͚Δ͜ͱʹΑΓɼ෺ཧϘλϯΛԡ͢ૢ࡞ͷೝࣝΛ࣮‫ͨ͠ݱ‬ɽ౉෦Β͸ [5]ɼϚʔΧΛຒΊࠐΜͩ஄ੑମΛεϚʔτϑΥϯͷ಺ଂΧϝϥ্ʹऔΓ෇͚ɼϢʔβ͕஄ੑମʹྗΛՃ͑ͨࡍͷϚʔΧͷҠಈྔΛޫֶࣜྗ෼෍ଌఆख๏ [2] ʹΑΓଌఆ͢Δ͜ͱʹΑΓɼϙΠϯςΟϯά΍ԡ͠ࠐΈૢ࡞Λ࣮‫ͨ͠ݱ‬ɽSpelmezan Β [1] ͸ɼѹྗηϯαͱۙ઀ηϯαΛ૊Έ߹Θͤͨ෺ཧϘλϯΛεϚʔτϑΥϯଆ໘ʹऔΓ෇͚Δ͜ͱʹΑΓɼεϚʔτϑΥϯΛย
खૢ࡞͢ΔͷͨΊͷ 6 छྨͷ਌ࢦδΣενϟͷೝࣝΛ࣮‫ͨ͠ݱ‬ɽYang Β [3] ͸ɼεϚʔτϑΥϯͷΠϯ
ΧϝϥʹશํҐΧϝϥΛऔΓ෇͚ɼपลࢹ֮Λ‫ݕ‬ग़͢Δ͜ͱʹΑΓɼपล‫ڥ؀‬ͷೝࣝɼपล෺ͷೝࣝɼϋϯυδΣενϟೝࣝɼϢʔβͷಈ͖ͷೝࣝͳͲΛ࣮‫ͨ͠ݱ‬ɽզʑͷఏҊγεςϜ SmarTrackBall Ͱ͸ɼεϚʔτϑΥϯͷΞ΢τΧϝϥ্ʹϚʔΧ෇ΞΫϦϧϘʔϧΛऔΓ෇͚ɼϢʔβ͕ࢦͰϘʔϧΛస͕ͨ͜͠ͱΛΞ΢τΧϝϥΛ༻͍ͯ‫ݕ‬ग़͢Δ͜ͱʹΑΓɼτϥοΫϘʔϧૢ࡞Λ࣮‫ͨ͠ݱ‬ɽ

3

SmarTrackBall
SmarTrackBall ͸ɼεϚʔτϑΥϯͷΞ΢τΧϝ

ϥΛ༻͍ͯτϥοΫϘʔϧૢ࡞ΛՄೳͱ͢Δγες
ϜͰ͋Δʢਤ 1ʣɽຊγεςϜͷར఺ΛҎԼʹࣔ͢ɽ• Ϣʔβ͸εϚʔτϑΥϯͷഎ໘Ͱૢ࡞Λߦ͏ͨΊɼεϚʔτϑΥϯͷը໘Λ࠹͙͜ͱͳ͘
ૢ࡞Λߦ͏͜ͱ͕Ͱ͖Δɽ• ϋʔυ΢ΣΞΛண୤ՄೳͳͨΊɼγεςϜΛ

࢖༻͠ͳ͍࣌ʹϋʔυ΢ΣΞΛ֎͓͚ͯ͠͹ɼ௨ৗͷૢ࡞ͷ๦͛ʹͳΒͳ͍ɽ• Ұํͷख͕࠹͕͍ͬͯΔ৔߹Ͱ΋ɼยखͰૢ

Copyright is held by the author(s).
∗Yoshitomo Fukatsu, ஜ೾େֶେֶӃ γεςϜ৘ใ޻ֶ‫ڀݚ‬Պ, Buntarou Shizuki and Jiro Tanaka, ஜ೾େֶ γεςϜ৘ใ‫ܥ‬

࡞Ͱ͖Δɽ

- 191 -WISS 2013ϓϩτλΠϓγεςϜ

4໘ͷτϥοΫϘʔϧΛస͕ͯ͠εΫϩʔϧૢ࡞Λߦ͏ͨΊɼϢʔβ͸ը໘Λ࠹͙͜ͱͳ͘ૢ࡞Λߦ͏͜ͱ͕Ͱ͖Δɽ

ϓϩτλΠϓγεςϜ͸ɼΞ΢τΧϝϥ্ʹऔΓ෇͚Δϋʔυ΢ΣΞɼ‫ͼٴ‬ɼτϥοΫϘʔϧͷಈ͖Λ‫ݕ‬ग़͢Διϑτ΢ΣΞ͔Βߏ੒͞ΕΔɽ

4.1

5.2 Ϛ΢εૢ࡞
SmarTrackBall ΛϚ΢εύου্Ͱૢ࡞͢Δ͜ͱϋʔυ΢ΣΞ

ʹΑΓɼैདྷͷϚ΢εͱಉ༷ͷૢ࡞Λߦ͏͜ͱ͕Ͱ
͖Δɽຊૢ࡞͸ɼैདྷͷϚ΢εૢ࡞ͱൺ΂ɼεϚʔτϑΥϯͷλονεΫϦʔϯΛ༻͍ͯɼϚϧνλον
δΣενϟΛߦ͏͜ͱ͕Ͱ͖Δɼ·ͨɼࢹ֮తϑΟʔυόοΫΛ༩͑Δ͜ͱ͕Ͱ͖Δͱ͍͏ར఺͕͋Δɽ

ຊγεςϜͷϋʔυ΢ΣΞ͸ɼತϨϯζʢ௚‫ ܘ‬21mmɼ֦େ཰ 3 ഒɼ2 ຕʣɼϚʔΧ෇ΞΫϦϧϘʔϧʢ௚‫ ܘ‬10 mmʣɼͦΕΒΛ‫ݻ‬ఆ͢Δᝑମ͔ΒͳΔ
ʢਤ 1ʣɽ͜ͷϋʔυ΢ΣΞΛεϚʔτϑΥϯʢApple
iPhone4SʣͷΞ΢τΧϝϥ্ʹऔΓ෇͚ͨɽ

4.2

6ιϑτ΢ΣΞ

·ͱΊͱࠓ‫ޙ‬ͷ՝୊εϚʔτϑΥϯഎ໘ʹ͓͍ͯτϥοΫϘʔϧૢ࡞ΛՄೳͱ͢ΔγεςϜ SmarTrackBall ʹ͍ͭͯड़΂ͨɽSmarTrackBall Λ༻͍Δ͜ͱʹΑΓɼϢʔβ͸ɼεϚʔτϑΥϯͷը໘Λ࠹͙͜ͱͳ͘τϥοΫϘʔϧૢ࡞Λߦ͏͜ͱ͕Ͱ͖Δɽզʑ͸ɼϓϩτλΠϓγεςϜΛ࡞੒͠ɼτϥοΫϘʔϧૢ࡞Λ༻͍
ͨ 2 छྨͷΞϓϦέʔγϣϯΛࣔͨ͠ɽࠓ‫ޙ‬͸ɼϋʔυ΢ΣΞ‫ͼٴ‬ιϑτ΢ΣΞͷվྑʹ
ΑΔೝࣝਫ਼౓ͷ޲্ɼ·ͨɼΞϓϦέʔγϣϯͷධՁΛߦ͏ɽຊγεςϜͷιϑτ΢ΣΞ͸ɼΞ΢τΧϝϥ͔Βऔಘͨ͠ը૾͔ΒɼΞΫϦϧϘʔϧͷಈ͖Λ‫ݕ‬ग़͢
Δ͜ͱʹΑΓɼϢʔβͷૢ࡞Λೝࣝ͢Δɽ۩ମతʹ͸ɼ·ͣɼΞ΢τΧϝϥ͔Βऔಘͨ͠ RGB ը૾ʢਤ2aʣΛάϨʔεέʔϧը૾ʢਤ 2bʣʹม‫͢׵‬ΔɽຖϑϨʔϜຖʹɼલͷϑϨʔϜͱ‫ࡏݱ‬ͷϑϨʔϜʹ͓͚ΔάϨʔεέʔϧը૾ͷΦϓςΟΧϧϑϩʔΛ‫ܭ‬ࢉ͢Δ͜ͱʹΑΓɼΞΫϦϧϘʔϧͷಈ͖Λ‫ݕ‬ग़͢
ΔɽΦϓςΟΧϧϑϩʔͷ‫ʹࢉܭ‬͸ɼΦʔϓϯιʔεͷίϯϐϡʔλϏδϣϯϥΠϒϥϦ OpenCV1 Λ༻͍ͨɽࢀߟจ‫ݙ‬

ਤ 2. Ξ΢τΧϝϥ͔Βऔಘͨ͠ը૾ɽaʣRGB ը૾ɼbʣάϨʔεέʔϧը૾ΞϓϦέʔγϣϯ

5

SmarTrackBall Λ༻͍ͨ 2 छྨͷΞϓϦέʔγϣϯΛ࡞੒ͨ͠ɽ

5.1

εϚʔτϑΥϯഎ໘ͷτϥοΫϘʔϧʹΑΔεΫϩʔϧૢ࡞

Ϣʔβ͸ɼεϚʔτϑΥϯΛ༻͍ͯ΢Σϒϒϥ΢
βͳͲͷεΫϩʔϧը໘ΛӾཡ͢ΔࡍʹɼεΫϩʔϧૢ࡞Λߦ͏ɽैདྷͷλονૢ࡞Ͱ͸ɼϢʔβͷ‫ݟ‬
͍ͯΔը໘Λλονૢ࡞Λߦ͏ࢦͰ࠹͍Ͱ͠·͏໰୊͕ੜ͡ΔɽఏҊγεςϜͰ͸ɼεϚʔτϑΥϯഎ
1[1] D. Spelmezan, C. Appert, O. Chapuis, and
E. Pietriga. Controlling widgets with one powerup button. In Proceedings of the 26th annual
ACM symposium on User interface software andtechnology, UIST ’13, pp. 71–74, New York, NY,
USA, 2013. ACM.
[2] K. Vlack,
T. Mizota,
N. Kawakami,
K. Kamiyama, H. Kajimoto, and S. Tachi.
GelForce: a vision-based traction field computerinterface. In CHI ’05 Extended Abstracts on
Human Factors in Computing Systems, CHI EA’05, pp. 1154–1155, New York, NY, USA, 2005.
ACM.
[3] X.-D. Yang, K. Hasan, N. Bruce, and P. Irani.
Surround-see: enabling peripheral vision on
smartphones during active use. In Proceedings ofthe 26th annual ACM symposium on User interface software and technology, UIST ’13, pp. 291–
300, New York, NY, USA, 2013. ACM.
[4] N.-H. Yu, S.-S. Tsai, I.-C. Hsiao, D.-J. Tsai, M.H. Lee, M. Y. Chen, and Y.-P. Hung. Clip-on
gadgets: expanding multi-touch interaction areawith unpowered tactile controls. In Proceedingsof the 24th annual ACM symposium on User interface software and technology, UIST ’11, pp.
367–372, New York, NY, USA, 2011. ACM.
[5] ౉෦ ཅҰ, ࠤ౻ ࠀ੒, ຀໺ ହ࠽, લ໺ ོ࢘. ޫֶࣜྗଌఆख๏Λ༻͍ͨ‫ܞ‬ଳ‫ܕ‬λονύωϧ୺຤༻ೖྗσόΠεͷఏҊ. ΠϯλϥΫγϣϯ 2012, pp.
521–526. Ұൠࣾஂ๏ਓ৘ใॲཧֶձ, 2012.

OpenCV: http://opencv.org/- 192 -WISS2013

人間の表情を活用するライフログ閲覧
高井 啓

志築 文太郎

田中 二郎∗

概要. ライフログの閲覧に人間の表情を活用するシステムを提案する．リアルタイムに生成されるライフ
ログデータは膨大なものとなる．我々はこの問題を解決する為に，ライフログの閲覧に表情を活用するシステムを実装した．提案システムはライフログデータと同期してユーザの表情を記録する．これにより，表情をキーとしたライフログデータの検索を可能とする．我々はケーススタディとして，PC の画面を記録し続けたライフログデータを，提案システムを使って閲覧した．本稿ではその結果を元に，表情を活用したライ
フログの閲覧の有効性について考察する．

1

背景と目的

人間の行動を記録し続けることによって生成されたライフログデータを利用し，ユーザの行動の振り
返りや記憶支援に役立てる研究が存在する．その中でも，コンピュータの操作ログやユーザの視界を撮り続けるログ等，リアルタイムに生成されるライフ
ログデータは膨大なものとなるため，効率的にデー
タを閲覧する為には，大量のデータの中からユーザが必要としている部分を抽出する必要がある．
ユーザが必要としている部分を抽出する研究の例として，Datchakorn ら [2] による研究がある．
Datchakorn らは，動画，GPS，心拍数等，様々なセンサを利用して作られたライフログから，コンテ
キストに注目してサマリを作成した．これにより，会話等，ユーザにとって重要な意味を持つ部分を抜き出すことが可能になった．また，福本ら [1] は，目
元の筋肉の動きから笑顔を認識するメガネ状のデバイスを作成し，その情報を元に，ウェアラブルカメ
ラによるライフログから，ユーザが笑顔の時に見ていた部分を取得し，提示する方法を提案した．
本研究はライフログの閲覧に人間の表情を活用するシステムを提案する．表情は感情を表す最も基本的な要素であり，記憶と感情は結びついている．その為表情が動いた時，即ち感情が動いた時のライフ
ログデータは他のライフログデータに比べ，ユーザ
にとってより有益な情報を含んでいると考えられる．
そこで，提案システムはライフログデータと同期してユーザの表情を記録する．これにより表情をキーとしたライフログデータの検索を可能とする．この検索を用いることにより，ユーザは自分の行動を見返したり，隠れた好みを見つけ出すことが出来ると考える．

∗

Copyright is held by the author(s).
Hiromu Takai, 筑波大学大学院システム情報工学研究科,
Buntarou Shizuki and Jiro Tanaka, 筑波大学システム情報系- 193 -

図 1. システム構成

2

システム

システムは記録部と解析部によって構成される．
図 1 にシステム構成を示す．
記録部は表情とライフログデータの記録を行う．
我々は表情を記録する為に，Kinect とそれに付随するライブラリを利用した．なお今回我々はライフロ
グとして，PC の画面のスクリーンショットを記録し続けるライフログ（以降，画面ログ）を採用した．
これはユーザが何を見ていたかが直ぐに解る為，実験やデバッグに適していると考えたからである．

WISS 2013結果

図 2. 解析ソフトウェア

解析部は記録した表情を解析し，ライフログデー
タを提示する．ユーザはこの解析部を利用してライフログを閲覧する，これにより自分の行動を見返す，
または自分の隠れた好みを見つけ出すことが出来る．
解析部のうち，ユーザにライフログのデータを提示する解析ソフトウェアのスクリーンショットを，図2 に示す．表情を数値で表したデータがグラフで表示され（図 2 上）またその下に，スライダで指定された時点での表情（検索キー）（図 2 左下）と，その表情に似た表情（以降，類似画像）が表示される（図 2 中央下），類似画像を提示した理由はユーザが指定した時点によく似ている時点を探すことが出来るようにする為である．これは似ている表情の瞬間は似ている状況にあるという仮説に基づいている．
そして，似ている状況を探すことができれば，行動の分析に便利であると考える．そこで表情を表すパラメータ同士の標準ユークリッド距離を類似度として類似画像の提示を行った．

3

ユーザは解析ソフトウェアを利用して画面ログの中から手作業で表情が笑顔になっている時点を一箇所選択した所，解析ソフトウェアによってその顔と似ていると判断された時点の表情が表示された．そこで，ユーザはその時点を選択し，さらにそれと似ている表情となっている時点を探してみた．結果として，一度笑った表情を見つけた後は，類似画像を利用して似た表情をしている時点を簡単に抽出することができた．
また，画面ログ中，映画を見ている間の画面ログにおいて同様の作業を行った所，画面ログ自体は静止画のみにも関わらず，その映画のどのシーンで笑ったか，さらに映画のそのシーンの内容まで思い出すことが出来た．
一方，プログラミングを行っている間の画面ログにおいては，映画を見ている時のような内容の抽出を行うことは出来なかった．この原因を調べるためにプログラミングを行っている間の表情を観察した
所，顔は笑顔を浮かべていなかった．これが抽出に失敗した原因だと考えられる．また，映画のスクリー
ンショットとは異なり，プログラミングを行っている時のスクリーンショットを見ても，この表情の時にどんな作業を行っていたかということは，映画とは異なり思い出すことが難しかった．

4

まとめと今後の課題

ある表情に似た表情をしていた時点をライフログ
データから検索することが可能なシステムを作成した．ケーススタディを行った所，映画（動画）鑑賞
時に於いて，ユーザによって印象的なシーンを抽出することができた．今後は提案システムのライフロ
グ閲覧に於ける有用性を調べて行きたい．

参考文献

ケーススタディこのシステムを利用し，画面ログの閲覧を行った．
保存した画面ログは 1 秒間につき 1 枚のスクリーン
ショットから構成される．利用したデータは 2012 年
10 月 15 日 20 時から 2013 年 8 月 23 日 16 時までであり，その内容は，解析部のプログラミングをしている時や，PC を使用して動画又はウェブサイトを閲覧している時，また論文のサーベイを行っている時の情報を含んでいる．閲覧した動画には，映画のDVD の他，ニコニコ動画で配信されていたコメン
ト付き動画も含む．
類似画像を用いてライフログデータを検索できる
ことの有効性を確かめるために，ケーススタディとして，様々な閲覧作業を行った．

- 194 -

[1] K. Fukumoto, T. Terada, and M. Tsukamoto. A
smile/laughter recognition mechanism for smilebased life logging. In Proceedings of the 4th Augmented Human International Conference, AH’13, pp. 213–220, New York, NY, USA, 2013.
ACM.
[2] D. Tancharoen, T. Yamasaki, and K. Aizawa.
Practical experience recording and indexing ofLife Log video. In Proceedings of the 2nd ACM
workshop on Continuous archival and retrievalof personal experiences, CARPE ’05, pp. 61–66,
New York, NY, USA, 2005. ACM.

WISS2013

音楽の構造情報を反映したミュージックビデオを簡単に制作・共有できる
Web サービス
中嶋 誠

五十嵐 健夫 ∗概要. 本稿では，音楽の構造情報を反映したミュージックビデオを簡単に制作できる Web システムを提案する．音楽の区間・小節・拍に同期したエフェクトや映像切り替え効果には，手動で煩雑な作業が必要だ
が，先行研究の songle システムと連携することで簡単に実現可能となった．また Web システムの特性を生かすことで，素材映像の収集・管理と，制作物の共有が容易である．加えて，音楽構造に対する映像の連動
方法を抽象化して定義することにより，自分の好きな音楽に好きな映像セットを組み合わせた視聴が可能
な，新しい種類のコンテンツである．

1

はじめに

近年コンテンツのリッチ化が進み，多くのユーザ
が，音楽に加えて映像の付いたミュージックビデオ
を楽しむようになっている．また作曲人口の増加や，動画共有サイトなど発表の場の拡大も，音楽に付随する映像の重要性を高める要因になっている．しかし，このような需要の増加に対し，供給が追いついていないという問題がある．なぜなら通常ミュージッ
クビデオは，一つの楽曲に対して一つの映像が職人的な手作業で制作されるため，労力とコストの問題
で大量生産が難しいからである．
そこで我々は新たに，ユーザが簡単に音楽と連動する映像を制作して，視聴・共有できる Web システ
ムを提案する．提案システムには以下の利点がある．

• songle システム [1] を利用する事で，音楽の構造情報を反映した映像を Web 上で簡単に制作できる• システムを Web 上に構築する事で，ユーザは映像素材の管理や制作物の共有にかかる手間を大幅に減らす事ができる• 音楽と映像の一対一対応ではなく，音楽構造に対する映像の連動方法を抽象化して定義するので，自分の好きな音楽に好きな映像セッ
トを組み合わせて視聴できる

2

提案システムが目指す音楽映像

提案システムが目指すのは，音楽の構造情報（区
間・小節・拍）と連動した映像である．これらの情報は，ユーザに音楽と映像の高い連動性を感じさせる重要な特徴量である．岩宮 [2] は，各種音楽特徴
量と映像要素を連動させて提示し，マッチしている∗曲のビートに対する
視覚要素の表示ルールを決める

使うルール、動画、曲を選ぶ

選んだ曲に合わせてタイミングよく動画が再生される

図 1. 提案システムのコンセプト図と感じる度合いを被験者に尋ねる心理学実験を行った．その結果，音楽の拍情報と，映像の切れ目が同期しているとき，ユーザは高い調和度を感じることが報告されている．また既存のミュージックビデオ
でも，小節の切れ目や，拍に合わせて映像を切り替える演出がしばしば見られる．既存システムとして，音楽の拍情報と連動した図形アニメーションを表示
する songle 外部埋め込みプレイヤーがある 1 。提案
システムは，この埋め込みプレイヤーのエフェクトを動画に拡張し，かつユーザが Web 上で動的にエフェクトを定義できるようにしたものである．
音楽映像表現の一つに，音響信号をリアルタイム
で変換し映像として表示するビジュアライザがある．
提案システムはそれと異なり，あらかじめ用意した動画素材を組み合わせて表示する．これはビジュア
ライザほど音響信号に直結した表現はできない代わ
りに，レンダリングに時間のかかる 3D モーション
グラフィクス素材や，あらかじめ加工した実写素材など，多様な映像素材を利用可能である．
1

Copyright is held by the author(s).
東京大学- 195 -

http://staff.aist.go.jp/m.goto/Songle/songle_
embedded_player_demo.html

WISS 2013

楽構造情報と，音楽の再生状態を取得し，描画する
動画素材を制御している．
プレイヤー画面での映像表示について，具体的には，小節ごとに表示する映像素材の切り替え，不透明度を利用した重ね合わせ，リピート区間で拍に連動したズーム効果，サビ区間で小節頭に連動したフラッシュ効果を適用している．
図 2. 動画素材一覧画面

図 4. 動画セット一覧画面

33.1

図 3. 動画セット作成画面

4

図 5. プレイヤー画面

システムの詳細
ユーザインタラクション

まずユーザは，提案システムの Web インタフェー
スにより，動画素材をアップロードする．アップロードされた動画素材は，動画素材一覧画面 (図 2) に表示される．将来的には，他のユーザがアップロードした動画を利用する仕組みも考えられる．次にユーザ
は，アップロードされた動画の中から好きなものを選び，動画セットを作る (図 3)．作成された動画セッ
トは，動画セット一覧画面に表示される (図 4)．動画
セット一覧画面で，各動画セットの横にある show ボ
タンを押すと，その動画セットを再生するプレイヤー
画面に遷移する (図 5)．プレイヤー画面には songle
埋め込みプレイヤーが表示され，再生ボタンを押すと音楽が始まり，同時に映像が連動して再生される．
またデフォルト曲以外にも，songle の曲 URL を右側フォームに入力し，Play this ボタンを押す事で，songle システムで解析済みのものであれば任意の音楽に，映像セットを連動して再生できる．
ユーザが作成した動画セットは，それぞれが固有のURL を持つので，その URL を共有する事で，他のユーザも視聴できる．またアドレスの末尾に songleの曲 URL を追加して，再生する音楽を指定できる．
つまり使用する動画セットと音楽の組み合わせを，一つの URL として表現する事ができる．この URLを他のユーザと共有し，この曲にはこの映像がマッチすると教え合う使い方も可能である．

3.2

実装

提案システムの実装には，Ruby on Rails フレー
ムワークを使用した．動画ファイルのミックス再生には，HTML5 Canvas を利用している．Javascript
で songle システムの埋め込みプレイヤーから，音まとめと今後の課題

本稿では，音楽の構造情報に連動したミュージック
ビデオを制作する Web システムを提案した．songle
システムを利用する事で，これまで手動で煩雑な作業が必要だった，音楽の区間・小節・拍に同期した映像切り替え表現やエフェクトが簡単に実現できる．
また Web システムの特性を生かし，素材映像をユー
ザが持ち寄る事で，素材集めと管理の手間が減った．
また作った物を共有する手間も少なくなった．加えて，音楽の構造情報を利用することで，調和度を保ったまま，任意の音楽と映像の組み合わせを試す事ができる，自由度が高いシステムになった．
今後の課題は，まず映像の表示ルールをユーザが編集できるインタフェースの実装である．現在は 3
つの映像素材からなる映像セットを，ハードコーディ
ングされた表示ルールによって，音楽の構造特徴に連動させて表示している．音楽特徴とエフェクトのマッピングを，ユーザが Web 上で自由に編集しプ
ログラムできるインタフェースがあれば，もっと自由度が高まり，かなりクリエイティブな表現が実現可能と考えられる．
また別の点として，提案システムで制作したミュー
ジックビデオの構成を，AfterEffects など既存の動画編集ソフト向けにエクスポートする機能が望まれる．ミュージックビデオのクリエイターに話を伺った
ところ，音楽構造の把握と映像への利用は，今のところほぼ手作業であり，非常に大変とのことであった．そのため支援効果の大きい分野だと考えられる．
提案システムは Web サービスなので，比較的容易にユーザに試用してもらう事ができる．そのために早い段階での一般公開が望ましい．その過程で，ユーザがどのような音楽と映像の組み合わせを好む
か，嗜好のデータが収集できるので，データに基づいた学習システムや，サジェストシステムも今後の発展が予想される．

参考文献[1] 後藤 真孝, 吉井 和佳, 藤原 弘将, M. Matthias, 中
野 倫靖. Songle:音楽音響信号理解技術とユーザによる誤り訂正に基づく能動的音楽鑑賞サービス. 情報処理学会論文誌, 54(4):1363–1372, 2013.
[2] 岩宮 眞一郎. 音楽と映像のマルチモーダル・コミュ
ニケーション 改訂版. 九州大学出版会, 2011.

- 196 -WISS2013

実世界オブジェクトへの機能拡張によるインタフェースの提案
松嶌 信貴

赤池 英夫

角田 博保∗

概要. 近年登場したメガネ型デバイスにおける新たなインタフェースを提案する．従来のメガネ型デバイ
スにおけるインタフェースにはそれぞれ問題点が挙げられる．音声やジェスチャを使った手法にはコマンドの種類が制限される問題がある．複雑な操作を可能とするポインティング手法については空中や自分の身体に表示・操作する手法があるが，前者では触覚フィードバックが得られず，後者では身体の一部を専有される問題がある．いずれの手法もユーザの周辺の環境を活用してはいない．そこで本研究では周辺にある実世界のオブジェクトを活用し，各オブジェクトの特徴やアフォーダンスに応じた機能を拡張するインタフェースを提案する．カメラを用いてユーザ視界からオブジェクトを認識するとともに，ユーザインタ
フェースを重畳表示し，直接触ることによる操作を実現する．物体を動かす，傾ける，回転させる，表面へのタッチ等さまざまな操作を割り当てることができ，広く応用が考えられる．未来ビジョンとしては，現実
世界と仮想世界をシームレスに利用する方法として，実世界オブジェクトの機能を拡張する手法を示した．

1

はじめに

本研究では，ユーザの周辺にある実世界オブジェ
クトを活用することによる，メガネ型デバイスにおける新たなインタラクションを提案する．
ウェアラブルなコンピュータであるメガネ型デバイスが登場し，多様なアプリケーションが開発されている．メガネ型デバイスへの代表的な操作手法には，
空中での手・指による操作があるが，触覚フィード
バックを得られない．また視線による操作では Midas
Touch Problem が知られている．いずれの手法についても，ユーザの周辺の環境を活用してはいない．
そこで本研究では，ユーザの周辺にある実世界のオブジェクトを活用し，直接触って操作できる機能
拡張インタフェースを提案する．

2

図 1. タイマー: カップ麺の拡張

提案手法

ユーザの周辺にある実世界オブジェクトにその特徴やアフォーダンスに応じたインタフェースを拡張
し，直接触っての操作を実現する．カップ麺のような円筒型オブジェクトを活用する例を考えると，垂直軸で回転させることにより，タイマーの時間を設定する機能が拡張（図 1）できる．物体への操作は
他にも，動かす，傾ける，表面へのタッチ等の操作を割り当てることができ，広く応用が考えられる．

3

実装システム

ユーザ視界に情報を表示するためにヘッドマウン
トディスプレイを使用する．周辺にある実世界オブジェクトや手・指を認識するために，ヘッドマウン∗

トディスプレイに併せて頭部に RGB・深度カメラを装着する．
現在の試作では，オブジェクトに貼付した AR マーカから ARToolKit1 を用いて実世界オブジェクトを認識し，深度ビットマップから OpenNI2 の手・指認識ライブラリを用いて手・指を認識している．RGB・
深度カメラには PrimeSense 社の CARMINE 1.09
3を使用している．
認識したオブジェクトには，その特徴に応じたユー
ザインタフェースをヘッドマウントディスプレイに
より重畳表示する．オブジェクトの形状に沿って表示することにより，実世界のオブジェクトに機能が拡張されたように感じられる表示を目指す．ヘッド
1

Copyright is held by the author(s).
電気通信大学大学院 情報理工学研究科 情報・通信工学専攻

http://www.hitl.washington.edu/artoolkit/
http://www.openni.org/
3
http://www.primesense.com/
2- 197 -WISS 2013

マウントディスプレイには，Sony 社のヘッドマウ
ントディスプレイ HMZ-T24 を使用している．また，画像処理や提示するユーザインタフェースの生成のためにパーソナルなコンピュータを使用している．
システムを軽量化ワイヤレス化するため，現在スマートフォンによる実装にとりかかっている．スマー
トフォン画面はレンズを通して見ることにより，ヘッドマウントディスプレイのような表示器として使用できる．スマートフォン内蔵のカメラ画像から AR
ライブラリ vuforia5 を用いてオブジェクトを認識し
ている．

4

関連研究

周辺の環境を活用したインタフェースには，C. Harrison らの OmniTouch[1] がある．ウェアラブルな深度カメラと小型プロジェクタにより，ユーザ前方の平面に対してインタフェースを投影し，操作できる．しかし，平面へのタッチ操作のみを対象としており，物体に対するタンジブルな操作を実現する本研究とは異なる．
周辺にあるオブジェクトに機能を拡張し，タンジブルな操作を実現した研究として，J. Huber らのLightBeam[2] がある．深度カメラとプロジェクタ
により，紙やマグカップにインタフェースを提示し，直接触れることによるタンジブルな操作を提案して未来ビジョン

本研究が目指すのは現実世界と仮想世界を区別なく便利に利用できる世界である．本研
究では，メガネ型デバイスを用いて実世界オ
ブジェクトに情報を付加するだけではなく，オ
ブジェクトの機能を拡張する．
カップ麺のタイマーは一例に過ぎず，日常的に使っているさまざまなオブジェクトに機能を追加することが考えられる．実世界オブジェ
クト向け拡張機能をアプリケーションとして，メガネ型デバイスからダウンロードして使える仕組みをつくれば，製品を製造している企業が機能拡張アプリケーションを提供することもできるし，第三者が開発し公開することも考えられる．
実世界オブジェクトを認識し，対応するアプ
リケーションを探すのが困難となりそうである
が，例えば製品バーコードの情報を使用することでオブジェクトを特定でき，アプリケーショ- 198 -いる．しかし，手に把持またはテーブル上に配置した状態での使用方法の調査が主であり，ウェアラブルなメガネ型デバイスを使用する本研究とは異なる．
周辺オブジェクトを活用した現実拡張インタフェー
ス [3] は著者らの試作を発表したものである．

5

おわりに

本稿では，メガネ型デバイスにおけるインタラク
ション手法として，周辺にある実世界オブジェクトに機能を拡張する手法を提案した．当日は実装した
アプリケーションのデモを行う．

参考文献[1] C. Harrison, H. Benko, and A.D. Wilson. OmniTouch: Wearable Multitouch Interaction Everywhere. UIST 2011, pp.441-450, 2011.
[2] J. Huber, J. Steimle, C. Liao, Q. Liu, and
M.Muhlhauser. LightBeam: Interacting with
Augmented Real-World Objects in Pico Projections. MUM 2012, Article No. 16, 2012.
[3] 松嶌, 赤池, 角田. 周辺オブジェクトを活用した現
実拡張インタフェースの提案. ヒューマンインタ
フェースシンポジウム 2013, pp.545-548, 2013.
45

http://www.sony.jp/hmd/products/HMZ-T2/
https://developer.vuforia.com/

ンとともに特徴量情報等のオブジェクト情報をダウンロードすることで解決できる．ユー
ザ自身が周囲のオブジェクトに好みの機能を設定してもよいだろう．
実世界オブジェクトを認識し，アプリケー
ションのダウンロードが自動で行われるようになると，現実世界と仮想世界とをシームレスに利用できるようになるだろう．

WISS2013

खຊσʔλΛࣗಈநग़͢ΔӡಈࢦಋγεςϜ
ࠇా मฏ

ೖߐ ӳ࢚

٢Ӭ ౒ ∗

֓ཁ. ਓ͕৽͘͠ӡಈΛֶͼ࢝ΊΔ৔߹ɼҰൠతʹ͸ͦͷӡಈͷख़࿅ऀ͔ΒࢦೆΛड͚Δɽࣗ෼ࣗ਎Ͱ͸‫͍͘ʹ͖ͮؾ‬ӡಈͷ‫ޡ‬ΓΛɼख़࿅ऀʹਖ਼ͯ͠΋Β͏ͨΊͰ͋Δɽ͔͠͠ɼख़࿅ऀΛཁ͢Δ͜ͱ͸ɼ‫ػ‬ձ΍ίετͷ໘Ͱशಘͷෑ‫ډ‬Λ૿Ճͤͯ͞͠·͏ɽख़࿅ऀʹ୅Θͬͯɼίϯϐϡʔλ͕Ϣʔβͷӡಈͷ‫ޡ‬ΓΛࢦೆͰ͖Ε͹ɼଟ͘ͷϢʔβͷӡಈशಘΛࢧԉ͢Δ͜ͱ͕Ͱ͖Δɽͦ͜Ͱզʑ͸ɼਓؒͷؔઅ࠲ඪΛऔಘͯ͠ϢʔβͷӡಈͷྲྀΕΛ‫ݕ‬ग़͠ɼӡಈͷਖ਼͠͞Λࣗಈతʹ൑ఆͯ͠ࢦಋ͢ΔγεςϜΛఏҊ͍ͯ͠Δɽ͜ͷγεςϜ͸ಈ͖Λ͍͔ͭ͘ͷϙʔζͷ࿈ଓͱͯ͠ͱΒ͑ɼҰͭҰͭͷϙʔζʹ͍ͭͯɼϢʔβ͕ਖ਼͍͠ମ
੎Λͱ͍ͬͯΔ͔൑அ͢Δɽ͜ͷ൑அʹ͍ͭͯɼզʑͷఏҊ͍ͯ͠Δ૬ରνΣοΫϙΠϯτΛ༻͍Δ͜ͱʹΑΓɼମ֨ʹΑΒͣʹࡉ΍͔ͳӡಈ൑ఆΛߦ͏͜ͱ͕Ͱ͖Δɽ͔͠͠૬ରνΣοΫϙΠϯτ͸खಈͰ࡞੒ͤ
Ͷ͹ͳΒͣɼଥ౰ͳνΣοΫϙΠϯτ࡞੒ʹ͸ӡಈͱγεςϜ૒ํ΁ͷਫ਼௨Λඞཁͱ͢Δɽ·ͨɼ৽͍͠ӡಈʹର͢ΔνΣοΫϙΠϯτ‫ه‬ड़ʹଟେͳ͕͔͔࣌ؒͬͯ͠·͏ɽͦ͜Ͱຊ࿦จͰ͸ɼ࿅श͍ͨ͠ӡಈͷؔઅ࠲ඪ‫੻ي‬σʔλ͔ΒɼνΣοΫϙΠϯτΛࣗಈੜ੒͢Δख๏
ΛఏҊ͢ΔɽϑϨʔϜؒྨࣅੑʹண໨ͨ͠ཁ໿ٕज़Λར༻ͯ͠ಛ௃తͳΩʔϑϨʔϜΛநग़͠ɼͦͷΩʔϑϨʔϜதͷؔઅ࠲ඪσʔλ͔Β૬ରνΣοΫϙΠϯτΛੜ੒͢Δɽ͜ΕʹΑΓɼ༷ʑͳӡಈͷࢦಋ͕ͨͬ
ͨҰճͷ‫ࢣڭ‬ͷ͓खຊʹΑΓͰ͖ΔΑ͏ʹͳΔɽ·ͨ‫ࢣڭ‬σʔλͷ഑৴ʹΑΓɼଟ͘ͷਓʹͱ༷ͬͯʑͳӡಈͷ࿅श͕਎ۙͳ΋ͷͱͳΔɽ

1

͸͡Ίʹ

ਓ͕৽͘͠ӡಈɼମૢɼμϯεͳͲΛशಘ͠Α͏
ͱ͢Δ৔߹ɼಠྗͰͷ࿅शΛ೉͘͢͠Δཧ༝ʹɼࣗ਎্͕ख͘Ͱ͖͍ͯΔ͔ͷ൑அ͕೉͍͜͠ͱ͕‫͛ڍ‬ΒΕΔɽ͜ͷͨΊɼΠϯετϥΫλʔͳͲɼͦͷӡಈʹਫ਼௨ͨ͠ऀͷ‫ྗڠ‬Λಘͯɼਖ਼͍͠ϑΥʔϜΛࢦಋͯ͠΋Β͏͜ͱ͕ޮՌతͱ͞Ε͍ͯΔɽ͔͠͠ɼ
ଞऀʹ‫ྗڠ‬Λ‫ٻ‬ΊΔࡍʹ͸ɼ֎෦ཁҼͷ੍໿ʹΑΓࣗ༝ͳ࣌ؒʹ‫͖ͣͰ͕ͱ͜Ϳֶʹܰؾ‬ɼ݁Ռͱͯ͠
ӡಈΛֶͿ‫ػ‬ձ͕๦͛ΒΕΔɽ
զʑ͸ಠྗͰͷӡಈͷ্ୡΛଅ͢΂͘ɼϢʔβΛࣗಈͰࢦಋ͢ΔγεςϜΛ։ൃ͍ͯ͠Δɽࢀߟͱͳ
Δٕज़ͱͯ͠͸ Chaves Βͷӡಈೝٕࣝज़ [1] ͱಉ༷ʹɼର৅ͱͳΔӡಈΛίϚׂΓ͠ɼಛ௃తͳϙʔζͷ࿈ଓͱͯ͠ද‫͢ݱ‬Δɽಛ௃తͳϙʔζΛɼҰఆͷ࣌ؒ಺ʹಉ͡ॱ൪ͰͱΔ͜ͱ͕Ͱ͖Ε͹ӡಈʹ੒ޭͨ͠ͱ൑ఆ͢Δɽզʑ͸ɼؔઅؒͷ૬ରతͳҐஔؔ܎Λ૬ରνΣοΫϙΠϯτͱ͢Δ͜ͱͰɼ༷ʑͳ
ମ֨ͷϢʔβͷӡಈΛࣝผͰ͖ΔΑ͏ʹ͠ɼϢʔβΛࢦಋ͢ΔγεςϜΛఏҊͨ͠ [2]ɽ΋͠Ϣʔβ͕ਖ਼͍͠ӡಈΛߦ͑ͳ͚Ε͹ɼ֘౰ՕॴΛ൓෮࿅श͞
ͤɼӡಈͷ্ୡΛଅ͢ɽຊ࿦จͰ͸ɼఏҊγεςϜΛ༷ʑͳӡಈʹରԠͰ
͖ΔΑ͏ʹҎԼͷ՝୊ʹऔΓ૊Ήɽ·ͣɼ૬ରνΣο∗

Copyright is held by the author(s).
Shuhei Kuroda, Hidetsugu Irie, Tsutomu Yoshinaga,ి‫ؾ‬௨৴େֶେֶӃ৘ใγεςϜֶ‫ڀݚ‬Պ৘ใωοτϫʔΫγεςϜֶઐ߈

- 199 -

ΫϙΠϯτͷଥ౰ੑͰ͋ΔɽϢʔβ͕ޮՌతͳशಘ
Λߦ͏ͨΊʹޮՌతͳνΣοΫϙΠϯτͷநग़͸ख़࿅ऀͷϊ΢ϋ΢ʹґଘ͍ͯ͠Δɽ࣍ʹνΣοΫϙΠ
ϯτఆٛͷ࣌ؒతίετͰ͋ΔɽνΣοΫϙΠϯτ
͸ͦΕͧΕखಈͰఆ͓ٛͯ͠Γɼ৽͍͠ӡಈ΁ͷରԠʹ͕͔͔࣌ؒͬͯ͠·͍ͬͯΔɽ͜ΕΒͷ՝୊ʹର͠ɼಛ௃ϑϨʔϜநग़ٕज़Λ༻
͍Δ͜ͱʹΑΓɼ্‫ه‬ೋͭͷ఺Λվળ͠ɼϢʔβ͕๬Ήӡಈͷ࿅शΛޮՌతʹߦ͏γεςϜΛ࣮‫͢ݱ‬Δɽ

2

ఏҊख๏

ӡಈࢦಋγεςϜ [2] ΛΑΓਖ਼֬ʹɼ͔֦ͭுੑ
ΛߴΊΔͨΊɼզʑ͸νΣοΫϙΠϯτࣗಈੜ੒ख๏
ΛఏҊ͢Δɽ·ͣϢʔβ͸ɼ͓खຊͱͳΔӡಈͷؔઅ࠲ඪͷ‫੻ي‬σʔλΛಘΔɽ͜Ε͸σʔλͱͯ͠഑෍͞Εͨ΋ͷΛऔಘ͢Δ΄͔ɼϑϨʔϜຖͷؔઅ࠲ඪΛऔಘͰ͖ΔσόΠεͷલͰɼӡಈΛशಘࡁΈͷਓؒʹ࣮ࡍʹӡಈΛߦͬͯ΋ΒͬͯಘΔɽ࣍ʹͦͷσʔλ͔Βɼྨࣅ౓ͷ௿͍͍͔ͭ͘ͷϑϨʔϜʢΩʔϑϨʔϜʣΛநग़͠ɼͦ͜ʹ‫ه‬࿥͞Εͨؔઅ࠲ඪͷ૬ରతͳҐஔؔ܎ΛνΣοΫϙΠϯτͱͯ͠ੜ੒͢
Δʢਤ 1ʣɽଞͷϑϨʔϜͱྨࣅ͠ͳ͍ϑϨʔϜ͸ɼӡಈͷதͰ΋ಛ௃తͳॏཁϙʔζͷϑϨʔϜͱߟ͑ΒΕɼଥ౰ͳνΣοΫϙΠϯτநग़ͷࣗಈԽ͕ՄೳͱͳΔɽ

WISS 2013ඪؒͷ૬ରతͳҐஔؔ܎Λ૬ରνΣοΫϙΠϯτͱͯ͠ੜ੒͠ɼ[2] ʹ૊ΈࠐΉɽ4γεςϜߏ੒

ຊγεςϜͰ͸ɼϢʔβͷؔઅ࠲ඪΛऔಘ͢Δ
ͨΊʹ Kinect Λ༻͍ΔɽKinect ͸Ϣʔβͷશ਎Λ
RGB Χϝϥͱ੺֎ઢηϯαʔͰଊ͑ɼ20 ‫ݸ‬ͷؔઅ࠲ඪΛऔಘ͢Δ͜ͱ͕ՄೳͰ͋ΔɽKinect Λ‫ػࢉܭ‬ʹ઀ଓ͠γεςϜΛ‫ى‬ಈ͢ΔͱɼϢʔβ΁ͷࢦಋΛදࣔ͢Δ΢Οϯυ΢ɼRGB ΧϝϥͰࡱӨͨ͠Ϣʔβͷؔઅ্ʹ੺͍ϚʔΧΛඳը͢Δ΢Οϯυ΢ɼͦͯ͠ಉ༷ʹ RGB ΧϝϥͷࡱӨͷ༷ࢠͷ্ʹϘλϯ͕දࣔ͞Εͨ΢Οϯυ΢͕ϙοϓΞοϓ͞ΕΔɽ͜
ͷϘλϯ͔Βӡಈࢦಋ͔ɼखຊσʔλ࿥ըΛબΜͰɼ
Kinect ʹөΔΑ͏ӡಈ͢Δɽ

5ະདྷϏδϣϯ

νΣοΫϙΠϯτࣗಈੜ੒ख๏Λ༻͍ͨӡಈࢦಋγεςϜཱ͕֬͞ΕΕ͹ɼਓʑ͸ख़࿅ऀͷࢧԉʹཔΔ͜ͱͳ͘ɼ༷ʑͳӡಈΛ্ୡͤ͞Δ͜ͱ͕Ͱ͖Δ
Α͏ʹͳΔɽ͜ΕʹΑΓɼਓʑʹͱͬͯӡಈ͸ΑΓ਎ۙͳ΋ͷͱͳΓɼεϙʔπ΍μϯεͳͲ͕੝ΜʹߦΘΕΔΑ͏ʹͳΔɽ͜ΕΛ௨͡ɼզʑ͸ਓʑͷ‫ڝ‬ٕεΩϧͷ޲্ͷΈͳΒͣɼਓʑͷ݈߁౓ͷఈ্͛Λਤ͍ͬͯ͘ɽ
ਤ 1. ఏҊख๏֓ཁ3ࢀߟจ‫ݙ‬

ΞϧΰϦζϜ

[1] Thiago Chaves, Lucas Figueiredo, Alana Da
Gama, Cristiano de Araujo, Veronica Teichrieb,”Human Body Motion and Gestures Recognition Based on Checkpoints ʡ, Virtual and Augmented Reality 2012 14th Symposium, 28-31
May 2012

ΩʔϑϨʔϜͷநग़ʹ͋ͨΓɼHuang Β͕ఏҊ͠
ͨɼ3D ϏσΦͷϑϨʔϜؒͷྨࣅؔ܎Λ‫ʹݩ‬ΩʔϑϨʔϜͷநग़Λߦ͍ɼࣗಈతʹ಺༰Λཁ໿͢Δγ
εςϜ [3] ͱಉ༷ͷΞϧΰϦζϜΛ༻͍Δɽ·ͣɼԿຕͷΩʔϑϨʔϜΛநग़͢Δͷ͔ͷϨʔτΛఆٛ͢Δɽ·ͨɼ3D ϏσΦͷϞσϧΛߏ੒͢ΔϘΫηϧ
ΛͻͱͭͻͱͭΛɼϞσϧͷॏ৺Λத৺ͱͨ͠‫࠲ٿ‬ඪ‫( ܥ‬r, φ, θ) ʹม‫͢׵‬Δɽ࣍ʹɼର৅ͱͳΔ N ຕͷϑϨʔϜதʹ͋Δɼ೚ҙͷϑϨʔϜ i,j ؒͷྨࣅ౓ΛɼϘΫηϧؒͷϢʔΫϦου‫཭ڑ‬ͷ߹‫ࢉͯʹܭ‬ग़͢Δɽ͜ͷྨࣅ౓ͱ͸ɼϑϨʔϜ j ͷϞσϧΛ 360
˃ճͯ͠ɼϑϨʔϜ i ͷϞσϧͱϢʔΫϦου‫཭ڑ‬తʹ΋ͬͱ΋͍ۙͮͨͱ͖ͷࠩҟͷ࿨Ͱ͋Δɽ͍࣍Ͱ͜ͷྨࣅ౓Λ‫ʹݩ‬ɼϑϨʔϜ i ͔Β j ·ͰͷؒશͯͷϑϨʔϜͱɼϑϨʔϜ i ͔ΒϑϨʔϜ i-j ·ͰͷશͯͷϑϨʔϜͱͷؒʹੜ·ΕΔ࿪ΈίετΛ‫ٻ‬ΊΔɽ͜ͷ࿪ΈίετΛ‫ʹݩ‬ɼ3D ϏσΦͷཁ໿ʹ࠷దͱͳΔΩʔϑϨʔϜΛࢉग़͢Δɽ
Huang ΒͱҟͳΓɼզʑͷख๏Ͱ͸ؔઅಉ࢜ͷ‫ڑ‬཭ʹண໨͢ΔͨΊɼϑϨʔϜ i,j ؒͷྨࣅ౓Λࢉग़͢ΔͷʹϞσϧΛ 360 ˃ճసͤͨ͞ΓͤͣɼͦΕͧΕͷؔઅ࠲ඪಉ࢜ͷϢʔΫϦου‫཭ڑ‬Λ༻͍Δɽ·ͨ‫ٻ‬ΊΒΕͨΩʔϑϨʔϜʹ‫ه‬࿥͞Ε͍ͯΔؔઅ࠲

[2] ࠇాमฏɼ์஍޺Ղ, ٢‫ݟ‬ਅ૱, ٢Ӭ౒, ೖߐӳ࢚, ”૬ର࠲ඪΛ༻͍ͨӡಈࢦಋγεςϜ”, DICOMO2013 γϯϙδ΢Ϝ (2013).
[3] Peng Huang, Adrian Hilton, Jonathan
Starck,”Automatic 3D Video Summarization:
Key Frame Extraction from Self-Similarity”,
3DPVT’08 - the Fourth International Symposium on 3D Data Processing, Visualization andTransmission(2008).

- 200 -WISS2013

EnchantMoon を利用した漢字・部首認識を活用した描画補助ツールの提案
若林 花見 ∗

井川 裕貴

武藤 寛

瀬川 典久

杉野 栄二

澤本 潤†

概要. 近年タブレット端末が普及してきているとともに、タブレット端末用のアプリケーションを用いて絵を書く人が増えてきた。従来のペイントアプリケーションでは、画面上のキャンバスの上部や側部にペンの種類や色、太さを変更するためのツールバーが表示されている。しかし、これらの機能性が操作を複雑にし、自由な発想を妨げていた。そこで本研究では、シンプルなインターフェースを持つ enchantMOON を用い、enchantMoon に部首認識機能を追加し、部首と手書き描画機能をつなげることで、描画補助を行う
仕組みを提案する。

1

はじめに本格的なイラスト描画を行うデジタルデバイスとしてペンタブレットや液晶タブレットが挙げられる
が、近年タブレット端末が普及してきているとともに、タブレット端末用のアプリケーションを用いて絵を書く人が増えてきた。タブレット端末で絵が描ければ、改めて機材を買い揃える必要がなく、趣味や遊び目的で絵を描く人にも容易に環境が整う。
従来のペイントアプリケーションでは、インターフェースとしてウィンドウの中央に描画用のキャンバスがあり、上部や側部にツールバーというレイア
ウト構成がほとんどである。それらのツールを使って描いたものに対してエフェクトをかけるが、その操作は直感的なものではなく、使い方を覚える必要がある。
これでは単純に絵を書くことが目的であるのにも関わらず、手間が増えてしまった。そして、この手間がユーザにストレスを感じさせていた。デッサンやアイディアスケッチの場合このようなストレスを感じることは発想の妨げになってしまう。
そこで、我々の研究グループでは、油絵などで絵を描くときに利用するパレット (図 1）を参考にシステムを実装する。パレットは、絵を書く人がパレッ
ト上に絵の具を置いてパレット上で色を混ぜて、欲しい色を作成しその色を塗っていく。
本研究で目指すのは、手書きタブレットに適したパレットみたいな機能を実装することである。本研
究では、部首認識を行う部品を画面の自由なところに設置し、利用者が漢字を書くことで、機能を追加できるシステムを提案する。
本研究で用いる enchantMOON[1] とは、ユビキ
タスエンターテイメント社が開発したタブレット端末である。ほとんどの操作をデジタイザーペンによる手書きと指のタッチ（図 2）のみで行うシンプル

図 1. パレット

なインターフェースである。筆跡ストロークのデータ構造は、X,Y の座標と筆圧の 3 つで構成されていて JSON 形式で保存される。ストロークはオブジェ
クトとして扱うことができ、さらに、JavaScript で記述したプログラムを機能として追加することができる。本研究の実装にあたってこのインターフェー
スとストロークに対する動作への機能追加の容易性から、enchantMOON が最適であると考えた。

図 2. enchantMOON における指での指示例

本稿では、EnchantMoon を用い、部首認識を使
いその部首の組み合わせで、機能を追加する仕組みについて提案を行う。

2

関連研究

手書き認識の研究 [2, 3] は、様々行われており、実用化もされている。そのため、本研究ではそれら

Copyright is held by the author(s).
カンガルースタジオ†
岩手県立大学ソフトウェア情報学部∗- 201 -WISS 2013の知見を利用して実装を行っている。
また、手書きをユーザインタフェースとして利用している一つの例として、[4] があげられる。利用者
が、手書きでジェスチャーを書くことで、機能を呼び出すことを実現している。

3

する。この文字は、部品として扱われるので、利用者はこの「消」を触れるだけで、ストロークの消去が可能になる。

プロトタイプシステム概要

利用者は、本プロトタイプシステムを実装したプ
ログラムを起動し、画面上に表示する（図 3）。
図 5. システム動作例

そして、この部首の組み合わせで、さまざまな機
能の割り当てを行う。例えば、「へん」が機能で「つくり」がパラメータを表すなどである。この漢字は、当然の事ながら、創作漢字も含まれる。今後は、認識される部首と、機能の関係を決める文法を定めて実験を行う。

4

おわりに

本研究では、enchantMoon を用い、部首認識を行う部品を、画面上に設置し、そこに漢字を記述することで、描画補助機能を自由に配置し、起動できることを示した。今後は、さまざまな機能を実装し、部首と機能の関係の文法を決定し、さまざまな実験を行う。

図 3. プロトタイプシステムの起動図 3 で示すように、シンプルな四角が画面上に表示される。利用者は、この四角を自由な場所に移動し、配置することが可能である。
本システムは、次にあげる動作を行（図 4）。

参考文献

1. 利用者が、四角の中に、漢字を記述する。その記述した物は、部品として画面上に置かれる。

2. 利用者は、必要なときに、漢字の表面を指で[1] enchantMOON ; The Hypertext Authoring
Tablet http://enchantmoon.com/[2] 伊藤 等, 中川 正樹:Hidden Markov Model に基づ
くオンライン手書き文字認識 , 電子情報通信学会
技術研究報告. MVE, マルチメディア・仮想環境基礎 97(207), 95-100, 1997-07-25

触れる。

3. 漢字の認識を部首単位で行い、機能が呼び出される。

[3] 福島 貴弘, 中川 正樹:確率モデルに基づくオンラ
イン枠なし手書き文字列認識電子情報通信学会技術研究報告. PRMU, パターン認識・メディア理解
98(489), 25-30, 1998-12-17[4]

図 4. 部首認識

本システムの認識は、DP マッチングを用い実装している。DP マッチングを用いたのは、実装が容易であるのと、すべての漢字を認識させるわけではなく、限られた部首を認識するためだけに利用するので、必要十分に動作するからである。
図 5 は、システムの動作例である。利用者が、四角の中に「消」の文字を記述しておきその文字を触れることで、今まで書いた手書きストロークが消去- 202 -

坂東 宏和, 福島 貴弘, 加藤 直樹, 中川 正樹:枠なし
手書き文字列認識における誤認識訂正インタフェー
ス情報処理学会論文誌 43(6), 1996-2005, 2002-0615

WISS2013ߨٛதͷ൘ॻΛࢧԉ͢Δਓ෺൒ಁ໌ԽΧϝϥͷ࣮૷ࢁࠜ ‫ܙ‬࿨ɹɹԬ෦ ਖ਼޾ɹɹകଜ ‫∗ ࢘ګ‬
֓ཁ. ௨ৗɼߨٛͳͲͷ৔ʹ͓͍ͯɼࠇ൘΍ϗϫΠτϘʔυΛ༻͍ͯઆ໌Λߦ͏ͱ͍͏‫ͱ͕ࣜܗ‬ΒΕ͍ͯ
Δɽ͜͜Ͱͷ໰୊͸ɼߨٛऀ͕ࠇ൘΍ϗϫΠτϘʔυʹจࣈ΍ਤΛॻ͍͍ͯΔͱ͖ɼߨٛऀͱจࣈ͕ॏͳΔ
ࡍʹɼडߨऀ͔Β͸ɼࠇ൘ͷจࣈ͕‫ݟ‬Εͳ͘ͳΔ͜ͱͰ͋Δɽͦ͜ͰຊγεςϜͰ͸ɼडߨऀ͕ɼߨٛऀ͓
ΑͼߨٛऀʹΑΓःΒΕͨจࣈΛಉ࣌ʹ‫ݟ‬Δ͜ͱ͕Ͱ͖Δʮ൒ಁ໌ਓؒΧϝϥʯΛఏҊ͢Δɽจࣈ΍ਤ͕ॻ͔Εͨࠇ൘ͱ൒ಁ໌ԽΛࢪͨ͠ߨٛऀͷө૾ΛผεΫϦʔϯ΁ग़ྗ͢Δ͜ͱͰɼडߨऀ͸ͦͷεΫϦʔϯΛ‫ݟ‬Δ͚ͩͰߨٛऀʹΑΓःஅ͞Εͯ‫ݟ‬Δ͜ͱ͕ෆՄೳͰ͋ͬͨจࣈ΍ɼߨٛऀͷઆ໌ՕॴΛਖ਼֬ʹ೺Ѳ͢Δ͜ͱ͕ՄೳͱͳΔɽ

1

͸͡Ίʹ

ߨٛ΍ձٞͳͲͷ৔Ͱ͸ɼࠇ൘΍ϗϫΠτϘʔυΛ࢖༻ͨ͠આ໌͕ओྲྀͰ͋Δɽ࠷ۙͰ͸ిࢠࠇ൘ͳ
ͲͷిࢠϘʔυ΋஫໨ΛूΊ͍ͯΔ͕ɼ͍ͣΕ΋ߨٛऀ͕จࣈ΍ਤΛॻ͘ɼ·ͨ͸ॻ͍ͨ΋ͷΛઆ໌͢Δͱ͖ʹɼߨٛऀͷख΍਎ମʹΑΓจࣈ΍ਤ͕ःณ͞Εͯ͠·͍डߨऀ͔Β‫ͳ͘ͳ͑ݟ‬Δ໰୊͕͋ΔɽిࢠϘʔυΛѻ͏৔߹ʹ͸ɼॻ͖ࠐΈ΍อଘͳͲͷ‫ػ‬ೳͷ੾Γସ͑ΛϚϧνλονͰߦ͏͜ͱͰɼ࿹΍ମͷҠಈΛ࠷খ‫ͯ͠ʹݶ‬จࣈ΍ਤͷःณΛ๷ࢭ͢Δ
ιϑτ΢ΣΞ͕͋Δ [1]ɽ͔͠͠ɼ͜ͷํ๏Ͱ͸ɼߨٛऀͷ༷ࢠ͸‫ݟ‬Δ͜ͱ͕Ͱ͖Δ͕ɼిࢠϘʔυͷલʹߨٛऀ͕͍Δ͜ͱͰःณ͞ΕͨจࣈΛ‫ݟ‬Δ͜ͱ͕
Ͱ͖ͳ͍఺΍ɼిࢠϘʔυҎ֎Ͱ͸ద༻Ͱ͖ͳ͍఺
͕‫͛ڍ‬ΒΕΔɽ͜ͷΑ͏ͳ໰୊Λղܾ͢ΔͨΊʹɼຊγεςϜͰ͸डߨऀ͕ߨٛऀʹΑͬͯःΒΕͨจࣈͱɼߨٛऀͷಈ͖Λಉ࣌ʹ‫ݟ‬Δ͜ͱ͕Ͱ͖Δʮ൒
ಁ໌ਓؒΧϝϥʯΛఏҊΛ͢Δɽ͜ͷγεςϜʹΑ
Γɼਂ౓৘ใʹΑΓߨٛऀΛ൑ผͯ͠൒ಁ໌ԽΛߦ͍ɼεΫϦʔϯʹग़ྗ͢Δ͜ͱͰɼडߨऀ͸ɼεΫϦʔϯΛ௨ͯ͠ߨٛऀͷӄʹ͋Δจࣈ͓Αͼߨٛऀͷ༷ࢠΛಉ࣌ʹ೺Ѳ͢Δ͜ͱ͕ՄೳͱͳΔ (ਤ 1)ɽ

2‫ط‬ଘγεςϜͷ໰୊

Kinect Λ༻͍ͯਓ෺Λೝࣝ͠ɼͦͷ෦෼Λഎ‫ܠ‬ը૾ʹΑΓϚεΫ͢Δ͜ͱͰਓؒͷಁ໌ԽΛߦ͏γεςϜ͕ଘࡏ͢Δ [2]ɽ͔͠͠ɼ͜ͷγεςϜͰ͸ɼߨٛऀΛಁ໌Խ͢Δͱ͖ʹߨٛऀͷྠֲ͕࢒ͬͯ͠
·͏໰୊΍ɼഎ‫ܠ‬ը૾ͷߋ৽͕ͳ͍ͷͰಁ໌Խ͞ΕͨྖҬͰ͸ࠇ൘ͷจࣈ͕ߋ৽͞Εͳ͍ͱ͍͏໰୊͕
͋Δɽ·ͨɼߨٛऀͷ༰࢟Λ‫׬‬શʹফ‫͢ڈ‬Δ͜ͱ͸ɼ∗

Copyright is held by the author(s).
Yamane Yoshikazu and Umemura Kyoji, ๛‫ٕڮ‬ज़Պֶେֶ ৘ใɾ஌ೳ޻ֶ‫ܥ‬, Okabe Masayuki, ๛‫ٕڮ‬ज़Պֶେֶ ৘ใϝσΟΞ‫ج‬൫ηϯλʔ- 203 -

ਤ 1. ൒ಁ໌ਓؒͰͷߨٛͦΕΛ‫͍ͯݟ‬ΔडߨऀʹͱͬͯෆࣗવͰ͋Γɼ஫ҙ͕ࢄອͯ͠͠·͏‫ڪ‬Ε͕͋Δɽͦ͜ͰຊγεςϜͰ͸ɼߨٛऀͷ͍ΔྖҬΛ֦େͨ͠‫ޙ‬ɼߨٛऀͷফ‫ڈ‬͓Αͼ৭෇͚Λߦ͏ͱ‫ʹڞ‬ɼߨٛऀҎ֎ͷྖҬΛৗ࣌ߋ৽͢Δͱ͍͏ΞϓϩʔνΛਤͬͨɽ

3γεςϜͷ֓ཁ

ਤ 2 ʹຊγεςϜͷߏ੒Λࣔ͢ɻຊγεςϜ͸ɼΧϝϥʹΑΓ RGBɾਂ౓৘ใΛऔಘ͠ɼऔಘͨ͠৘
ใΛ‫ ʹج‬PC ʹΑΓߨٛऀΛ൒ಁ໌ԽΛࢪͨ͠‫ޙ‬ɼεΫϦʔϯʹग़ྗ͢ΔॲཧΛϦΞϧλΠϜͰߦ͏ɽγεςϜ‫ى‬ಈ࣌ɼΧϝϥʹ͸ࠇ൘͕ը໘தԝʹөΔΑ͏ʹɼΧϝϥΛ഑ஔ͢Δɽͳ͓ɼγεςϜ‫ى‬ಈ࣌ʹɼഎ‫ྖܠ‬Ҭͱ൑அ͢ΔͨΊͷ‫཭ڑ‬Λܾఆ͢ΔͨΊɼߨٛऀ͸ը໘ʹөΒͳ͍Α͏ʹ͢ΔɽPC Ͱ͸ɼऔಘ͞Εͨਂ౓σʔλʹΑΓɼߨٛऀΛϚεΫ͢Δྖ
Ҭͱɼࠇ൘΍จࣈͳͲͷഎ‫ྖܠ‬ҬΛ൑ผ͠ɼߨٛऀ
ͷ൒ಁ໌Խ͓Αͼࠇ൘ʹॻ͔Εͨ৘ใͷߋ৽Λߦ͏ɽPC ʹΑΓߨٛऀ͕൒ಁ໌Խ͞Εͨө૾͸ɼεΫϦʔϯ΍֎෦ϞχλͳͲʹग़ྗ͞ΕΔɽडߨऀ͸ɼग़ྗ͞Εͨө૾Λ‫ݟ‬Δ͚ͩͰॠ࣌ʹɼࠇ൘ͷจࣈͱߨٛ
ऀͷ༷ࢠΛଊ͑Δ͜ͱ͕ՄೳͱͳΔɽWISS 20134.2

ਤ 2. γεςϜߏ੒

4γεςϜͷ࣮૷

ຊγεςϜ͸ɼೖྗ૷ஔͱͯ͠ Microsoft ࣾͷ
Kinect Λ༻͍࣮ͯ૷Λߦͬͨɽkinect ʹΑΓऔಘͨ͠ਂ౓σʔλΛ‫ʹج‬ɼϚεΫྖҬͱഎ‫ྖܠ‬ҬΛׂΓ౰ͯΔ͕ɼͦͷํ๏ͱͯ͠ɼਂ౓σʔλͷᮢ஋Λ༻͍ͯྖҬΛ൑ఆͨ͠ɽਂ౓σʔλͷᮢ஋ͷܾఆ͸ɼը૾தԝ෇ۙͷਂ౓σʔλΛ༏ઌతʹαϯϓϦϯά
͠ɼͦΕΒͷฏ‫ۉ‬஋ʹΑΓܾఆ͍ͯ͠ΔͷͰɼࠇ൘͕Χϝϥը໘ͷத৺ʹ͋Δ৔߹ɼΧϝϥͱࠇ൘ͷؒͷ‫͕཭ڑ‬ᮢ஋ͱͳΔɽ͋Δըૉʹ͓͚Δਂ౓͸ɼᮢ஋Ҏ্Ͱ͋Ε͹എ‫ྖܠ‬Ҭɼᮢ஋ະຬͰ͋Ε͹ϚεΫ
ྖҬͱׂͯ͠Γ౰ͯΒΕΔɽͳ͓ɼഎ‫ྖܠ‬Ҭ͸ࠇ൘΍ϗϫΠτϘʔυͳͲʹ૬౰͠ɼഎ‫ܠ‬ը૾ͱͯ͠ਵ࣌ߋ৽͢ΔྖҬͰ͋Δɽ·ͨɼϚεΫྖҬ͸Χϝϥͱࠇ൘ͷؒʹଘࡏ͢ΔΦϒδΣΫτ (ߨٛऀͳͲ) ʹ૬౰͠ɼͦͷΦϒδΣΫτͷഎ‫ྖܠ‬ҬʹΑΓϚεΫ
Λߦ͍ɼΦϒδΣΫτΛ৭෇͚͢Δ͜ͱͰ൒ಁ໌Խ
Λߦ͏ྖҬͰ͋Δɽ࠷৽ͷը૾ʹରͯ͠ɼͦΕͧΕͷྖҬʹԠͨ͡ॲཧΛߦ͏͜ͱͰɼߨٛऀΛ൒ಁ໌
Խ͢Δ͜ͱ͕ՄೳͱͳΔɽ

4.1

ਂ౓ը૾ͷ෼ׂ

Kinect ͔Βͷ֤छ৘ใ͸ 30fps Ͱऔಘ͍ͯ͠Δ͕ɼ֤ϑϨʔϜʹରͯ͢͠΂ͯͷըૉΛ୳ࡧ͠ɼ1pixel͝ͱͷॲཧΛߦ͏͜ͱ͸ɼϝϞϦ࢖༻ྔ͕ଟ͘ͳΔ͜ͱ΍ɼ‫૿͕ؒ࣌ࢉܭ‬Ճ͢Δ͜ͱͰॲཧ͕ॏ͘ͳΔͨΊ‫࣮ݱ‬తͰ͸ͳ͍ɽͦͷͨΊɼpixel ͝ͱͷਂ౓σʔλΛ͍͔ͭ͘ͷϒϩοΫʹ·ͱΊΔ͜ͱͰɼѻ͏ըૉΛ‫ݮ‬গͤͨ͞ɽͳ͓ɼ1 ϒϩοΫ͸ 10 ʷ 10 ϐΫηϧͱͯ͠ਂ౓ը૾ͷ෼ׂΛߦ͍ɼ֤ϒϩοΫ಺ͰαϯϓϦϯάσʔλΛબͿɽͦͯ͠ɼͦͷϒϩοΫ͕എ‫ྖܠ‬Ҭ·ͨ͸ϚεΫྖҬͷͲͪΒʹଐ͢Δͷ͔Λଟ਺ܾΛߦ͏͜ͱͰܾఆ͠ɼ֤ϒϩοΫͷ஋Λഎ‫ྖܠ‬Ҭ·ͨ͸ϚεΫྖҬʹׂΓ౰ͯΔɽ͜ΕʹΑΓɼྖҬͷׂΓ౰ͯΛߴ଎Խ͢Δ͜ͱ͕Ͱ͖ΔͷͰɼߨٛऀͷ൒ಁ໌Խ͓Αͼഎ‫ܠ‬ͷߋ৽ΛϦΞϧλΠϜͰॲཧ͢Δ͜ͱ͕ՄೳͱͳΔɽ

- 204 -

ϚεΫྖҬͷ֦େྖҬΛׂΓ౰ͯͨࡍʹɼഎ‫ྖ৽ߋܠ‬ҬͱϚεΫྖҬͷ‫ڥ‬ք໘Ͱ͋Δߨٛऀͷྠֲ෦෼͕ɼྖҬͷ‫ޡ‬෼ྨʹΑΓ൒ಁ໌ॲཧ͞Εͣʹදࣔ͞Εͯ͠·͏ɽྫ͑͹ɼਤ 3 ࠨதԝͷ‫Ͱؙ‬ғΜͩ෦෼ͷΑ͏ʹɼ࿹΍खʹϚεΫྖҬͷׂΓ౰͕ͯͳ͍Օॴ͕ଘࡏ͢ΔͷͰɼ͜ͷ෦෼͕ফ‫͞ڈ‬Εͣʹ࢒ͬͯ͠·͏ɽͦ͜Ͱɼ
ϚεΫྖҬͷ֦େΛߦ͏͜ͱͰ໰୊Λղܾͨ͠ (ਤ3)ɽຊγεςϜͰ͸ɼ༨෼ʹϚεΫྖҬͷׂΓ౰ͯΛߦͬͯ΋ɼ൒ಁ໌ԽͷࡍʹΦϒδΣΫτͷΈΛ৭
෇͚͢ΔͨΊɼγεςϜͷಈ࡞ʹӨ‫ڹ‬͸͠ͳ͍ɽਂ
౓σʔλʹΑΓׂΓ౰ͯΒΕͨϚεΫྖҬʹରͯ͠ɼͦΕͧΕ 8 ํ޲ʹ 1 ϒϩοΫ͚ͩγϑτͨ͠ϚεΫྖҬΛ࡞੒͠ɼͦΕΒͷ࿦ཧ࿨ΛऔΔ͜ͱͰϚεΫྖҬͷ֦େͷ࣮૷ΛߦͬͨɽϚεΫྖҬΛ֦େ͢Δ
͜ͱͰɼߨٛऀΛফ‫͢ڈ‬ΔྖҬ͕޿͕ΔͨΊɼྠֲΛ࢒͢͜ͱͳ͘ߨٛऀΛফ‫͢ڈ‬Δ͜ͱ͕Ͱ͖ΔɽϚεΫྖҬʹΑΓফ‫ޙͨ͠ڈ‬ɼΦϒδΣΫτʹ৭෇͚Λߦ͏͜ͱͰ൒ಁ໌Խ͢Δ͜ͱ͕Ͱ͖Δɽ

ਤ 3. ϚεΫྖҬͷ֦େɽ(ࠨ):‫ݩ‬ը૾ɼ(ӈ):ΦϒδΣΫτͷ৭෇͚

5·ͱΊຊ‫Ͱڀݚ‬͸ɼߨٛͳͲͷ৔ʹ͓͍ͯɼडߨऀ͕ɼ
ߨٛऀʹΑͬͯःΒΕͨจࣈͱɼߨٛऀͷ༷ࢠΛಉ࣌ʹ‫ݟ‬Δ͜ͱ͕Ͱ͖ΔγεςϜͷ։ൃΛߦͬͨɽ‫ط‬ଘͷγεςϜʹ͓͚Δɼಁ໌Խͨ͠ࡍʹߨٛऀͷྠֲ͕දࣔ͞Εͯ͠·͏໰୊΍ɼߨٛऀͷ༷ࢠ͕೺ѲෆՄೳʹͳΔ໰୊ɼ͓Αͼഎ‫͞৽ߋ͕ܠ‬Εͳ͍໰୊ʹରͯ͠ɼϚεΫྖҬͷ֦େͱ৭෇͚ɼഎ‫ྖܠ‬Ҭͷৗ࣌ߋ৽Λߦ͏͜ͱʹΑΓղܾͨ͠ɽຊγεςϜʹ
Αͬͯߨٛऀͷ൒ಁ໌ԽΛߦ͏͜ͱʹΑΓɼ࣮ࡍͷߨٛͳͲͷ৔ͰɼߨٛऀʹΑΓःஅ͞Εͯ‫ݟ‬Δ͜ͱ
͕ෆՄೳͰ͋ͬͨจࣈɼ͓Αͼߨٛऀͷ༷ࢠΛ‫ݟ‬Δ͜ͱ͕Ͱ͖Δը‫ظ‬తͳߨ͕ٛՄೳͱͳΔɽࢀߟจ‫ݙ‬[1] Ӭ໺௚, ‫ݪ܀‬Ұ‫و‬, ౉ล༟ଠ, ౻ଜ༟Ұ, օ݄তଇ,ྛल඙. Ϛϧνλονిࢠࠇ൘ʹΑΔ‫ࡐڭ‬ఏࣔੑೳͷվળ, ໐໳‫ڭ‬ҭେֶ৘ใ‫ڭ‬ҭδϟʔφϧ No.7,
pp. 23–27, 2010.
[2] தଜ‫܆‬, ాத࿨‫ر‬, ‫ٶ‬৓ӳਓ. ल࿨γεςϜ. Kinect
for Windows SDK ϓϩάϥϛϯά C# ฤ, pp.
153–162, 2012.

WISS2013ු༡ϊʔτγεςϜʹ͓͚ΔಓҊ಺‫ػ‬ೳͷ࣮૷খ໺ᖒ ਗ਼ਓɹɹɹೖߐ ӳ࢚ɹɹɹ٢Ӭ ౒ ∗֓ཁ. ϩϘοτ͕‫׆‬༂͢Δ৔͸ɼ࢈‫ۀ‬ͷΑ͏ͳઐ໳తͳ‫͕ڥ؀‬ଟ͘ɼૢ࡞͢ΔͨΊʹ͸ಛผͳ஌ࣝ΍ٕज़͕ඞཁͰ͋ͬͨɽ͔͠͠ɼۙ೥ʹͳΓࣗಈ͓૟আϩϘοτͷΑ͏ͳ୭Ͱ΋؆୯ʹૢ࡞͢Δ͜ͱ͕Ͱ͖ΔϩϘοτ͕ొ৔͠ɼਓؒͷੜ‫׆‬Λαϙʔτ࢝͠Ί͍ͯΔɽզʑ͸ɼϩϘοτ͕Ϣʔβͷ༷ʑͳखॿ͚Λߦ͏ʮු༡ϊʔτʯγεςϜͷఏҊɾ࣮૷ΛਐΊ͓ͯΓɼ͜ͷγεςϜʹ͓‫͍ݣ‬ɾಓҊ಺‫ػ‬ೳΛ࣋ͨͤΔͨΊͷφϏήʔγϣϯγεςϜΛߏஙͨ͠ɽ͜ͷγεςϜͰ͸ɼεϚʔτϑΥϯͱ࿈ಈͯ͠஍ਤλοϓͱ͍͏؆୯
ͳૢ࡞ͰϩϘοτͷ໨త஍Λઃఆ͠ɼࣗಈઃ‫͞ܭ‬Εͨ‫ܦ‬࿏ΛϩϘοτ͕ࣗ཯ඈߦ͢Δɽ͔͠͠ɼ࣮૷ͨ͠ΞϧΰϦζϜͰ͸ɼ‫͍ڱ‬ಓͳͲ GPS ͕औಘͮ͠Β͍஍఺Ͱͷ౸ୡࣦഊ͕ଟ͍ɽ·ͨ෩ͷӨ‫ʹڹ‬ΑΓਐΉํ޲͕มԽ͠ɼ໨త஍ʹ౸ୡ͠ͳ͍͜ͱ͕͋Δɽͦ͜ͰຊߘͰ͸ɼඈߦϩϘοτͷҠಈਪఆ΍Ճ଎౓ηϯαΛ༻͍ͨϑΟʔυόοΫγεςϜΛ࣮૷͠ɼఏҊφϏήʔγϣϯγεςϜͷϩόετੑΛߴΊΔɽՃ଎౓ηϯα‫ͼٴ‬ա‫ڈ‬ͷ GPS ͷ஋͔Β‫ࡏݱ‬஍Λਪఆ͠ɼ࣮ࡍͷ஋ͱେ͖ͳ͕ࠩ͋Δ৔߹ʹ͸ɼGPS ͷଌఆϛεͱ൑அ͠ɼਪఆ஋ΑΓφϏήʔγϣϯΛߦ͏ɽ·ͨɼૢॎࢦࣔͱҟͳΔ‫ػ‬ମͷಈ͖ΛՃ଎౓ηϯαʹΑΓ‫ݕ‬஌͠ɼҠಈʹิਖ਼Λ͔͚Δɽ͜ΕΒͷγεςϜΛߏஙɾಋೖ͢Δ͜ͱͰɼφϏήʔγϣϯγεςϜͷਫ਼౓޲্Λߦ͍ɼಓҊ಺‫ػ‬ೳΛ࣮‫͢ݱ‬Δɽ

1

͸͡Ίʹ

ʹ૝ఆ֎ͷ৔ॴ΁ඈߦͯ͠͠·ͬͨɽࣗಈφϏήʔγϣϯՄೳͳු༡ϊʔτʹΑΔ͓࢖͍‫ػ‬ೳ࣮‫ͦͱݱ‬ͷΞϓϦέʔγϣϯΛ‫ݕ‬౼͢ΔͨΊʹ͸ɼ͜ΕΒͷ՝୊Λղܾ͠ͳ͚Ε͹ͳΒͳ͍ɽͦ͜ͰຊߘͰ͸෩ʹྲྀ͞Εͨͱ͖ͷิਖ਼‫ͼٴ‬ෆਖ਼֬ͳGPS σʔλऔಘͷରࡦΛ࣮૷͢Δɽ‫ػ‬ମ͕෩ʹྲྀ͞Εຊདྷͷࢦࣔͱ͸ҟͳͬͨํ޲ʹਐΉ͜ͱΛՃ଎౓ηϯαʹΑΓ‫ݕ‬஌͠ɼิਖ਼ΛՃ͑φϏήʔγϣϯೳྗͷ޲্ΛਤΔɽ·ͨɼGPS σʔλͷ‫ޡ‬औಘΛ๷͙ͨΊʹ GPS ͷ஋ͷҠಈਪఆΛߦ͏ɽऔಘͨ͠
GPS ͷ஋ͱਪఆ஋ʹ͕ࠩ‫ݟ‬ΒΕΔ৔߹͸ɼGPS ͷਫ਼౓͕ѱ͍ͱ൑அ͠ɼਪఆ஋Λ༻͍ͯφϏήʔγϣϯΛߦ͏ɽ͜ΕΒͷఏҊΑΓɼφϏήʔγϣϯγε
ςϜͷ໨త஍౸ୡ཰ͷ޲্Λߦ͍ɼಓҊ಺‫ػ‬ೳͷ࣮‫ݱ‬Λ໨ࢦ͢ɽ໨ࢦ͍ͯ͠ΔಓҊ಺‫ػ‬ೳ͸ɼ‫ܞ‬ଳ৘ใ୺຤Ͱ‫ࡏݱ‬஍΍໨త஍Λ֬ೝ͠ͳͯ͘΋ɼϩϘοτͷ‫ޙ‬Λ௥͑͹໨త஍ʹ౸ண͢Δ͜ͱͷͰ͖Δγες
ϜͰ͋ΔɽϩϘοτ͸‫ࢪྗࢠݪ‬ઃͷอक΍Ӊ஦։ൃɼ࢈‫ͳۀ‬Ͳઐ໳తͳ‫Ͱڥ؀‬ͷར༻͕ओྲྀͰ͋Γɼ͜ΕΒΛૢ࡞͢Δਓؒʹ΋ಛผͳ஌ࣝ΍ٕज़͕ඞཁͱ͞Ε͖ͯͨɽ͔ۙ͠͠೥ʹͳΓɼࣗಈ૟আϩϘοτͷΑ͏ʹ୭Ͱ΋Ͱ͖Δ؆୯ͳૢ࡞Ͱɼਓؒͷੜ‫׆‬Λαϙʔτ͢ΔϩϘοτ͕ొ৔͍ͯ͠Δɽզʑ͸ɼϩϘοτ͕ਓؒͷύʔτφʔͱͯ͠ଘࡏ͠ɼϢʔβΛ༷ʑͳ৔໘Ͱखॿ͚͢ΔকདྷΛ໨ࢦ͠ɼʮු༡ϊʔτʯγεςϜΛఏҊ͍ͯ͠Δ [1]ɽ͜ͷγεςϜ͸ɼ‫ܞ‬ଳ৘ใ୺຤ΛඈߦϩϘοτ͕೺࣋ͯ͠Ϣʔβͷ๬ΉҐஔʹ଺ۭ͢Δ͜ͱʹΑΓɼ྆ख͕࢖͑ͳ͍৔໘΍໨͕཭ͤͳ͍৔໘Ͱ΋༰қʹ৘ใ୺຤Λར༻Ͱ͖Δ͜ͱ
Λ໨ࢦ͓ͨ͠‫ڙ‬ϩϘοτͰ͋Δɽ‫ࡏݱ‬զʑ͸ʮු༡ϊʔτʯγεςϜͷߋͳΔ‫ػ‬ೳ֦ॆΛ໨ࢦͯ͠ɼ͓
‫͍ݣ‬ɾಓҊ಺‫ػ‬ೳΛ։ൃ͍ͯ͠Δɽ‫૷࣮ͨͬߦʹط‬Ͱ͸ɼख࣋ͪͷεϚʔτϑΥϯͱ࿈ಈ͠ɼϢʔβ͕໨త஍Λ஍ਤ্Ͱλοϓ͢Δ͜ͱʹΑΓɼ‫ܦ‬࿏Λࣗಈੜ੒͠ɼGPS ‫ͼٴ‬ίϯύεηϯαΛར༻ͯ͠ϩϘοτΛ໨త஍΁౸ୡͤ͞Δ [2]ɽεϚʔτϑΥϯͰͷ໨త஍ઃఆ͸ɼͲͷϢʔβʹରͯ͠΋؆୯ͳૢ࡞Λ࣮‫͕ͨ͠ݱ‬ɼϩϘοτͷ໨త஍౸ୡ཰͸ 50% Ͱ͋ͬͨɽओͳ‫ݪ‬Ҽ͸‫ݐ‬෺Ԋ͍ͷ‫͍ڱ‬௨࿏ͳͲ GPS ͷਫ਼౓͕ѱ͍஍఺Ͱͷෆਖ਼֬ͳҐஔσʔλͰ͋ͬͨɽ·ͨɼ෩ʹΑΓ‫ػ‬ମ͕ྲྀ͞Εͦ͏ʹͳͬͨ৔߹͸ GPS ʹΑΔ੍‫͕ޚ‬௥͍͔ͭͣ
∗

2
2.1

ఏҊख๏
Ճ଎౓ʹΑΔҠಈํ޲ϑΟʔυόοΫఏҊ͢Δಈ࡞Λਤ 1 ʹࣔ͢ɽՃ଎౓ηϯαΛར༻
͢Δ͜ͱͰɼඈߦϩϘοτͷ଎౓Λࢉग़Ͱ͖ΔɽφϏήʔγϣϯʹΑΓલਐ΍ટճͷࢦࣔΛग़͢ͱ͖ͷՃ଎౓ͷ஋ͱɼඈߦϩϘοτ͕ࢦࣔΛड͚ͨ‫ޙ‬ͷՃ଎౓ͷ஋Λൺֱ͠ɼड͚ͨࢦࣔͱ͸ҟͳΔํ޲ʹਐΜͩ͜ͱ͕‫ݕ‬஌Ͱ͖ͨ৔߹ɼ෩ʹྲྀ͞Εͨͱ൑அ͠ɼ
‫ͯͬޡ‬ਐΜͩํ޲ͱ͸‫͖޲ٯ‬ͷҠಈࢦࣔΛग़͢͜ͱ
Ͱิਖ਼͢Δɽ

Copyright is held by the author(s).
Kiyoto Onozawa, Hidetsugu Irie, Tsutomu Yoshinaga,ి‫ؾ‬௨৴େֶ େֶӃ৘ใγεςϜֶ‫ڀݚ‬Պ ৘ใωοτϫʔΫγεςϜֶઐ߈

- 205 -WISS 2013Δঢ়ଶΛࣔ͢ɽ͜ͷ࣌ɼۙࣅͨ͠ਪఆ͕ਖ਼͍͠ͱ൑
அ͠ɼଌఆ஋Λར༻ͯ͠φϏήʔγϣϯΛߦ͏ɽ࣍ͷ஍఺ͷਪఆʹ͸ଌఆ஋Λར༻͢Δɽ

3φϏήʔγϣϯγεςϜͰͷඈߦϩϘοτ΁ͷࢦࣔ͸ɼટճͱલਐͷΈߦΘΕΔɽՃ଎౓ηϯαʹΑ
ΓࢦࣔҎ֎ͷҠಈΛ‫ݕ‬஌ͨ͠৔߹ɼͦͷํ޲ͱ͸‫ٯ‬޲͖ͷํ޲΁Ҡಈ͢ΔࢦࣔΛग़͢ɽඈߦϩϘοτʹ໋ྩΛग़͢ࡍɼͲͷఔ౓ͷ଎౓ͰҠಈ͢Δ͔Λܾఆ͢Δ͜ͱ͕Ͱ͖ΔɽͦͷͨΊɼҠಈํ޲ϑΟʔυόοΫΛߦ͏ࡍɼҠಈલ‫ޙ‬ͷ଎౓ൺֱʹΑΓɼͲͷఔ౓ҟͳΔํ޲ʹਐΜ͔ͩΛ‫͠ࢉܭ‬ɼਐΜͩ‫ʹ཭ڑ‬Ԡͨ͡଎͞ͰҠಈ͢Δ໋ྩΛग़͢ɽGPS σʔλͷ‫ࡏݱ‬஍ਪఆʹ͓͍ͯɼGPS ͷ஋͕ߋ৽͞ΕΔ࣌ؒͷִؒ‫͜ͼٴ‬ͷ࣌ؒ಺ͷҠಈ଎౓͔ΒҢ౓ɼ‫౓ܦ‬ͷਪఆ஋Λࢉग़͢Δɽ͜ͷ݁ՌΛར༻͠ɼఏҊख๏Ͱࣔͨ͠ҠಈਪఆΛߦ͏ɽ͜ΕΒͷ੍‫ޚ‬ΞϧΰϦζϜΛු༡ϊʔτʹ௥Ճ͠ɼφϏήʔγϣϯγεςϜΛར༻࣮ͨ͠‫ݧ‬Λߦ͏ɽ௚ઢ‫ܦ‬࿏ɼ‫͕ۂ‬Δ஍఺Λ‫ؚ‬Ή‫ܦ‬࿏ɼGPS Λऔಘͮ͠Β͍஍఺Λ໨ࢦ͢‫ܦ‬࿏ͦΕͧΕͷ‫ܦ‬࿏ΛφϏήʔγϣϯͤ͞ɼ໨త஍౸ୡ཰͕ͲͷΑ͏ʹվળ͞ΕΔ͔ධ
Ձ͢Δɽ͞ΒʹɼಓҊ಺ΞϓϦέʔγϣϯͷ࣮‫ݧ‬Λߦ͍ɼϢʔβ͕ඈߦϩϘοτͷ੻Λ௥͏͜ͱͰࢦఆ͠
ͨ໨త஍ʹͨͲΓண͚Δ͔Ͳ͏͔Λ‫ূݕ‬ɾධՁ͢Δɽ

ਤ 1. Ճ଎౓ηϯαʹΑΔิਖ਼

2.2

࣮૷ͱධՁํ๏

GPS ʹΑΔҠಈਪఆφϏήʔγϣϯΞϧΰϦζϜͷ‫ج‬ຊಈ࡞Ͱ͸ɼͦͷ࣌ͷ GPS ‫ͼٴ‬ίϯύεσʔλΑΓ໨త஍·Ͱͷ‫౓֯ͼٴ཭ڑ‬Λ‫͠ࢉܭ‬ɼલਐ·ͨ͸ટճͷࢦࣔΛग़ͯ͠໨త஍౸ୡΛ໨ࢦ͢ɽ͜ͷφϏήʔγϣϯͷ࣮ߦதʹ GPS ͷଌఆʹ֎ཚ͕͋Δ͜ͱΛ૝ఆ͠ɼͦ
Ε·Ͱऔಘͨ͠ඈߦϩϘοτͷ଎౓σʔλ‫ͼٴ‬ա‫ڈ‬ͷ GPS σʔλΑΓ‫ࡏݱ‬஋Λਪఆ͢Δɽਤ 2.2 ʹਪఆΛߦ͍ͳ͕ΒɼҠಈ͢ΔྫΛࣔ͢ɽ

4

ਤ 2. GPS ͷ࣮ଌ஋ͱਪఆ஋ͷਪҠ

case1 ͷΑ͏ʹɼଌఆ஋ͱਪఆ஋͕ۙࣅ͢Δঢ়ଶ
ͷ࣌ɼଌఆ஋Λར༻ͯ͠φϏήʔγϣϯΛ‫ܧ‬ଓ͢Δɽ
case2 ͷΑ͏ʹଌఆ஋ͱਪఆ஋ͷ͕ࠩେ͖͍ঢ়ଶ
ͷ࣌ɼGPS ͷଌఆϛεͱ൑அ͠ɼਪఆ஋ΛϩϘοτ
ͷ‫ࡏݱ‬஍ͱ૝ఆͨ͠φϏήʔγϣϯΛߦ͏ɽ࣍ͷ஍఺ͷਪఆ͸ࠓճͷਪఆ஋Λ‫ͨ͠ͱݩ‬΋ͷͱɼଌఆ஋
Λ‫ͨ͠ͱݩ‬΋ͷͷೋ௨ΓΛ༻ҙ͢Δɽ
case3 ͸ɼશͯͷਪఆ஋ͱଌఆ஋͕ҟͳΔঢ়ଶΛࣔ͢ɽ͜ͷ৔߹͸ɼGPS ͷଌఆϛεͱ൑அ͠ɼ2 ͭͷਪఆ஋ͷ͏ͪଌఆ஋ʹ࠷΋͍ۙਪఆ஋Λ‫͠ͱࡏݱ‬ͯ૝ఆ͠ɼφϏήʔγϣϯΛߦ͏ɽ࣍ͷ஍఺ͷਪఆ͸ଌఆ஋‫͞୒࠾ͼٴ‬Εͨਪఆ஋Λ‫͢ࢉܭʹݩ‬Δɽ
case4 Ͱ͸ɼ͍ͣΕ͔ͷਪఆ஋ͱଌఆ஋͕ۙࣅ͢

- 206 -

ະདྷϏδϣϯ

Ҡಈํ޲ϑΟʔυόοΫγεςϜʹΑΓɼ҆ఆͯࣗ͠཯ඈߦ͢Δු༡ϊʔτγεςϜ͕࣮‫͢ݱ‬Ε͹ɼ͓‫ڙ‬ϩϘοτʹΑΔ༷ʑͳੜ‫ࢧ׆‬ԉΞϓϦέʔγϣϯΛ҆ఆ࣮ͯ͠૷͢Δ͜ͱ͕Ͱ͖Δɽ͜ͷ͜ͱʹΑΓϢʔβͷՙ෺Λ೚ҙͷ৔ॴʹಧ͚Δ͜ͱ΍ɼϢʔβ͕ं಺ͷौ଺ͳͲͰ਎ಈ͖͕औΕͳ͍࣌ʹɼ୅ΘΓʹ೚ҙͷ஍఺ͷ༷ࢠΛ‫͔ͤߦʹݟ‬ΔͳͲɼਓʑΛ༷ʑͳ‫Ͱܗ‬αϙʔτ͢Δ͜ͱ͕Ͱ͖ΔΑ͏ʹͳΔɽ
զʑ͸ɼ͜ͷΑ͏ͳφϏήʔγϣϯΛߦ͏ΞϓϦέʔγϣϯΛ։ൃ͠ɼ
ʮු༡ϊʔτʯγεςϜΛൃలͤ͞ɼ
ϩϘοτ͕ਓؒͷύʔτφʔͱͯ͠ଘࡏ͢ΔະདྷΛ໨ࢦ͢ɽࢀߟจ‫ݙ‬[1] ࣳ੕ൕ:ʠ ඈߦ‫ܕ‬ϩϘοτͱ‫ܞ‬ଳ৘ใ୺຤Λར༻ͨ͠ʮු༡ϊʔτʯγεςϜͷఏҊ ʡ, ৘ใγεςϜֶ‫ڀݚ‬Պ ৘ใωοτϫʔΫγεςϜֶઐ߈म࢜࿦จ (2012).
[2] খ໺ᖒਗ਼ਓʠ: λονࢦࣔʹΑΔ͓‫ڙ‬ϩϘοτφϏ
ήʔγϣϯ ʡ,DICOM2013 γϯϙδ΢Ϝ (2013).
[3] Tianmiao Wang:ʠ Autonomous Control And
Trajectory Tracking Of Quadrotor Helicopter ʡ,IEEE International Conference(2012).