情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

モバイルカメラを用いたデバイス間
アドホックアプリケーション共有
萩原 拓真†1

高嶋 和毅†1 モルテン フィールド†2

北村 喜文†1

概要：モバイルカメラを用いたデバイス間のアプリケーション共有を実現する手法（CamCutter）を提案する．ユーザ
は，ホストデバイスのディスプレイ上に表示されているアプリケーションウィンドウをモバイルデバイス上のカメラで撮影するだけで，そのアプリケーションをそのモバイル上で操作・実行することができる．CamCutter は，従来のデバイス間での情報共有の方法やツールと比べ，簡単で素早く利便性の高い情報共有を可能とするため，アドホックなミーティングや協調作業場面の利用に適している．本稿では，CamCutter プロトタイプの実装とその性能評価，およびユーザスタディにより示される有用性について報告する．

A Cross-Device Application Sharing Technique using Mobile Camera
TAKUMA HAGIWARA†1, KAZUKI TAKASHIMA †1,
and YOSHIFUMI KITAMURA†1

MORTEN FJELD†2,

Abstract: We developed an ad-hoc cross-device interaction technique that allows the user to share an application window on ahost computer by using the camera of a handheld mobile device. This technique uses our computer vision algorithm to identify thetarget application window from the screen capture of the host computer. The interaction flow is coherent where the user cancontinuously use the mobile’s touchscreen to take a picture of a target window and interact with it. The interactions on the mobile
device are synchronized to the original application on the host by using screen mirroring technique. We implemented a prototype
and conducted a technical evaluation of its fundamental ability for desktop and meeting set-ups. A user study demonstrated thatour proposal was more preferred compared with commercial screen sharing and file sharing tools.

図１: CamCutter を用いたアドホックアプリケーション共有の例（a）ディスプレイ上のアプリケーションをカメラで撮影（b）撮影したアプリケーションを近くの人と共有（c）協調 3D モデリング（d）複数デバイスから大画面ディスプレイの操作
Figure 1 : Cross-device application sharing by using CamCutter

1. はじめにうな手順が必要であり，アドホックな（即時的な）利用には向かない．

電子メールを始め，リモートデスクトップやオンライン

そのため，同一空間内における複数のデバイス間通信を

ファイルホスティングサービスなど，複数のデバイスを跨円滑に実現するために様々な研究がなされてきた．例えば，いだデータやファイルの同期・共有が可能になってきた．

ペン型のデバイスを用い，ID を利用して情報を複数のディ

これらの技術は主に遠隔地間を結ぶ協調作業に向けて開発

スプレイに跨って管理する Pick-and-Drop[9]などがある．

されたものであり，通信やセキュリティの都合でユーザア

また，ユーザの位置情報やデバイス間の距離情報に基づいカウント制御や共有 URL の送受信などの手順が必要であた情報共有の手法なども提案されている[4][8]．その中でる．一方で一人が複数台のデバイスを持つ現代においては，も近年注目を集めているのが，デバイスに付属するのが当同じオフィス空間の中でも様々な形で身近なデバイス間のたり前のようになってきたカメラを利用して，ファイルを情報通信が必要となる場面も増えてきた．しかし，従来の共有したり，ディスプレイ上のコンテンツを操作したりすファイル同期ツールなどを利用した場合は遠隔地と同じよる方法である[5]．これは，カメラを利用することでデバイ†1 東北大学 電気通信研究所†2 Chalmers University of Technology, Dept. Applied IT.

© 2017 Information Processing Society of Japan1

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

スの特定や接続のトリガを簡単にしているだけではなく，バイス間通信の可能性を検討する．

カメラによる情報の記録という現実世界のメタファにも基

2. 関連研究づいているために有用性が非常に高いと考えられている．
しかし，これまで提案されてきたカメラを用いるデバイス

デバイス間のインタラクション（クロスデバイスインタ

間の情報交換技術はファイル共有に基づくため[5][7]，デラクション）に関する様々なシステムがこれまで提案されバイス毎に利用できるアプリケーションが異なる現状を考てきた．本章では，近年非常に盛んなモバイルデバイスのえると必ずしも最良の方法ではない．一方，リモートデス

カメラを用いたデバイス間接続とインタラクションに関す

クトップによるスクリーン共有やミラーリングを利用するる研究を紹介する．このような技術の背景には SIFT やことも考えられる．この方法ではデバイスにアプリケーシ

SURF などの画像処理特徴量技術の発展があり，我々も A-

ョンをインストールすることなく，他のデバイス上のコン

KAZE[1]を利用している．

テンツを閲覧・操作することが可能である．しかし，従来

2.1 リモートコントロールのリモートデスクトップをモバイルデバイスから利用する

ネットワーク経由で複数のデバイスを接続し，データの際には，デバイス間の解像度や操作方法の違いなどに課題

送受信，同期，遠隔操作を行う研究は多くなされている．

がある他，アカウント制御による接続が必要で，アドホッ

Boring らは離れた場所に置かれたディスプレイ上のコンテ

クな場面には向かない．

ンツに対して，モバイルデバイスのカメラファインダーをそこで本研究では，モバイルデバイスのカメラを用いて通してリアルタイムに操作可能とする Touch projector を提

ホストコンピュータ上に表示されているあらゆるアプリケ

案した[3]．また，Baur らはモバイルデバイスのカメラを用ーションウィンドウをアドホックにそのデバイス上に共有いてデスクトップ画面を認識し，モバイルデバイス上のデすることができる手法 CamCutter を提案する．

ータをデスクトップ画面に対して投影し，モバイルデバイ

なお，CamCutter はアドホックなデバイス間アプリケー

スの限られた画面を拡張する Virtual projection を提案してション共有のためのツールであるが，本研究では，このアいる[2]．最近では，Freitas らによって，プリンターやプロ

プリケーション共有を次のように定義する．

ジェクタ機器などをモバイルデバイスのカメラで撮影する

1.

特定のアプリケーションウィンドウのみをホストデことで，それらの機器をモバイルデバイス上から操作可能

バイスとクライアントデバイス間で共有する．スクリとする Snap-to-it が提案されている[6]．このようにカメラーン全体の共有に比べ画面が小さいモバイル上でもと画像処理を組み合わせることで，簡単に異なる複数のデアプリケーションウィンドウに対して操作が行いやバイス間で情報をやり取りできるが，例えば，Snap-to-it ですく，また，無駄なネットワークトラフィックを抑えは予め登録されたデバイスの画像に対してのみ動作をする

ることができる．

ため，動的な状況や変化するコンテンツには対応できない．

アプリケーションウィンドウはリアルタイムにデバ

2.2 ファイル共有

2.

3.

イス間で同期される．ファイルを共有する方法と比べ，複数のデバイス間でファイルを共有する際には USB メ

操作を開始するまでのオーバーヘッドが短く，クライ

モリなどの外部記憶装置や近年ではオンラインファイルホ

アントデバイス上で行った変更を再度ホストデバイ

スティングサービス（e.g., DropBox, Google Drive）が多くスに送信する必要が無い．

用いられている．Liu らはモバイルデバイスのカメラでデアプリケーションに対する操作は，ホストデバイスとスクトップ上のファイルアイコンを撮影することで，そのクライアントデバイスのいずれからも行うことが可ファイルをモバイルデバイス上に転送する技術を提案した

能である．

[7]．また，Chang らはデスクトップ上のアプリケーション

もしカメラを使って，手軽にこれらの機能を持つアプリ

ウィンドウをカメラで撮影することで，そのアプリケーシ

ケーション共有を実現することができれば，アドホックなョン情報を含め，データを転送する Deep Shot を提案した

状況において円滑なデバイス間でのデータ共有を実現し，[5]．しかしファイルを共有する際には，それぞれのファイ多様でダイナミックな作業をサポートできると期待できる．

ルに対応するアプリケーションがデバイス上にインストー

例えば，オフィスで行われるアドホックな情報の共有（図ルされている必要があり，この方法では，我々が目指すデ

１a, b）や，デザイナとエンジニアが一つのアプリケーショ

スクトップ上で動作するあらゆるアプリケーションに対応ンを共有する協調作業（図１c），プロジェクタや大画面デすることは難しい．

ィスプレイを用いたミーティング（図１d）などは，通常複2.3 スクリーン・アプリケーション共有

数台のデバイスが存在し，相互の情報のやり取りには手間スクリーン共有とは，あるデバイスのスクリーン全体をがかかる．本稿では，CamCutter の設計と実装およびユーザ

その他のデバイスから閲覧・操作を可能とする技術のこと

スタディについて報告し，カメラを用いたアドホックなデ© 2017 Information Processing Society of Japanであり， VNC や RDP などのリモートデスクトップソフト

2

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2(a) アプリケーションウィンドウ認識モード
Application window detection mode(b) インタラクションモード
Interaction mode

図２: 各コンポーネントとデータ遷移
Figure 2 : Components and data transition of CamCutter

ウェアで用いられてきた．ファイルを共有する場合とは異ルとホストの接続が確立する．そして，撮影したホスト上なり，リモート側には操作したいアプリケーションがインのアプリケーションの画像情報が逐次的にモバイルデバイ

ストールされていなくてもホスト側のアプリケーションをス上に表示されることになる．なお，その画像に対する操利用することができ，Skype（閲覧のみ）や TeamViewer [10]作も可能であり，その操作はホスト上のアプリケーションなどのソフトウェアが一般にも広く用いられている．しかにも反映される．CamCutter では，タブレット上のタッチス

し，画面サイズの小さなモバイルデバイス上でデスクトッ

クリーンを用いてアプリケーションをカメラで撮影し，そプ画面全体を操作することは難しい．また，一般的にこれのままタッチスクリーン上でアプリケーションを利用でき

らのソフトウェアではデバイス間をアカウントによって接るので，ユーザは撮影からアプリケーションの操作に素早続制御しているが，これはアドホックな場面においては大く移行することができる．以降では，カメラを使ったアプ

きなオーバーヘッドになってしまう．なぜなら，アドホッ

リケーションの特定とアプリケーション共有のための双方クな場面では，複数のユーザが自身のまたは他人のデバイ

向通信について述べる．

スに簡単に素早くアクセスすることが望まれるからである．

3.1 基本構成

一方，アプリケーション共有は，１章で定義したように，

本システムはホストデバイスとクライアントデバイス

デスクトップ画面全体ではなく，特定のアプリケーションで構成され，無線ネットワークを通じてデータをやり取り

のみを複数のデバイス間で共有する技術である．アプリケ

する．プロトタイプではホストアプリケーションを Widowsー シ ョ ン の み を 共 有 す る と い う 点 で は ， Google

Form アプリケーションで，クライアントアプリケーション

Docs/Sheet/Slides [11]などのウェブサービスも強く関連すを Unity で作成した．本システムはアプリケーションウィ

るが，これらは特定のアプリケーションに限定されており，

ンドウ認識モード（図２ a）とインタラクションモード（図我々の目指すあらゆるアプリケーションを共有するための２ b）の２つのモードを持ち，複数のホストデバイス，ク仕組みはない．

ライアントデバイス間で動作するように設計する．

以上，まとめると，我々の知る限りでは，アドホックな

3.1.1 アプリケーションウィンドウ認識モード

場面において起動中のアプリケーションを複数のデバイス

図２ (a)，クライアントの CamCutter によってアプリケ

間で簡単に素早く共有する手法はこれまで提案されていな

ーションウィンドウの画像が撮影される．撮影された画像

い．CamCutter はこのような場面でユーザがあらゆるアプ

データはネットワークに接続されている全てのホストアプ

リケーションを素早く共有でき，複数のデバイスを跨いだ

リケーションの Network Manager へと送信される（図３）．

ダイナミックな作業形態をサポートする．

Network Manager は受信した画像を Application Detector へ

3. システム設計と実装と渡す．Application Detector はホストデバイス上で展開されている全てのアプリケーションウィンドウ画像を取得し，CamCutter における基本的な共有の手順は次の通りであ

画像処理技術 A-KAZE を用いて受信した画像データの特徴

る．まず，モバイルデバイスのカメラで異なるホスト上の量を抽出して，それぞれのアプリケーションウィンドウ画

アプリケーションウィンドウを撮影すると，それらモバイ像と比較する．その後，Application Detector は最も類似し© 2017 Information Processing Society of Japan3

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

CamCutter でモバイルデバイスへと移行し（図１a），B さんのデスクへと向かう．彼のデスクに到着すると，手元のモ
バイルデバイスを見せながら B さんの意見を資料に反映させる（図１b）．この時点で A さんのデスクトップ PC 上の資料データも同時に変更される．ミーティングが終わるとA さんは自分のデスクに戻る途中で C さんから製品デザイ
ンの確認を依頼され，その場で CamCutter を用いてアプリ
ケーションウィンドウを撮影して自分のデスクへ持ち帰る．
また，確認したデザインをエンジニアのデスクへ持って行
き，話し合いをしながらデザインを変更する（図１c）．
図３: 複数ホストデバイスとクライアントデバイスの通信
Figure 3 : Multi-host and client architectureているアプリケーションのウィンドウハンドルを保持し，Network Manager に対して合致した特徴量データを送信する．Network Manager はクライアント側に特徴量データとアプリケーションウィンドウの Z-オーダから計算される
スコアを渡す．クライアント側はすべてのホストデバイス
からのスコアを受信した後，最大スコアを返したデバイスとの接続を確立し，インタラクションモードへと移行する．
同一またはよく似た外観のアプリケーションがデスクトップ上に展開されており，どちらかのウィンドウを撮影した場合，スコアに含まれる Z-オーダによってウィンドウは選択される．また，極めて類似するウィンドウが複数ある場合に正しいウィンドウが選択される確率は，A-KAZEの性能に依存している．
3.1.2 インタラクションモード
図２ (b)，ホスト側の Application Duplicator はアプリケー
ションウィンドウ画像データ（スクリーンショット）を上で述べた例のように，利用するデバイスや場所が動的に変化する場合にも即自的に適応できるデバイス間インタ
ラクション手法は今まで提案されていない．なぜなら，従来の手法やサービスの多くはユーザアカウントによって制御されているために，接続に時間を要したり，利用できる
アプリケーションが限定的だったりするからである．なお，
実際には，TeamViewer など既存のスクリーン共有ソフトを利用したとしても，ユーザアカウントを保存するなどすれば，ログインに時間がかからないものもある．しかし，基本的なセッティングでは，スクリーン全体の共有であり，
モバイルデバイスのために洗練されたものではない．
CamCutter が日常的に利用される場合，ユーザは常に正面からアプリケーションウィンドウを撮影できるとは限らない．他者のディスプレイを撮影する場合には，斜め横から撮影する場合も考えられる．そこで我々は，CamCutter の認識精度を次の章で検証し，アカウント制御を用いた従来手法と CamCutter を６章で比較する．

5. 性能評価

30fps でクライアントデバイスへと送信する．前後のフレー3 章で述べたプロトタイプについて，モバイルデバイス

ム間でアプリケーションウィンドウに変化がない場合はこのカメラを用いたアプリケーションウィンドウ認識精度とのステップはスキップされる．ユーザがクライアントデバ

反応時間を評価する．

イス上のアプリケーションウィンドウ画像をタッチ操作す

5.1 実験機器と環境

ると，タッチ位置情報はネットワークを介してホスト側の４章で述べた CamCutter が使用されることが想定される

Network Manager へと送られ，Input Agent がタッチ位置情

デスクトップセットアップとミーティングルームセットア

報をホストディスプレイ上にマッピングし，OS へと通知

ップの２つの環境について実験を行う．

される．Input Agent は排他制御されており，複数のクライ

5.1.1 デスクトップセットアップ

アントからの入力に対応する．クライアントデバイス上で本実験では，クライアントデバイスとして iPad Air 2（カ入力されたキー情報も同様に Input Agent を介して OS へ通

メラ解像度 1920×1200）を，ホストデバイスとして Windows

知される．

10 PC (Core i7 2600, 16GB RAM)と 27 インチディスプレイ

4. CamCutter の利用場面（1920×1200）を使用する．実験者は手にクライアントデバ

本章では CamCutter の実際の利用場面について例を示して説明する．
A さんは会社のオフィスへ着き，自分のデスクトップ PC
で文章作成の仕事を始めた．その後，同僚の B さんと共同で 進 めて い る 作 業 のミ ー テ ィ ン グを 行 う た め に資 料 を© 2017 Information Processing Society of Japan

イスを把持し，ディスプレイ上のアプリケーションウィン
ドウがカメラファインダーに映るようにして写真を撮影する．撮影された画像がホストデバイスに送信されると，ア
プリケーションウィンドウ認識が開始される．ここでは，日常的に利用されることを想定した際に発生する撮影角度
によるアプリケーションウィンドウ画像の歪みに対するロ

4

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

ィンドウ撮影の際に，カメラビュー全体にアプリケーショ
ンウィンドウが収まるように光学ズーム機能を利用する．
5.2 結果と考察
5.2.1 デスクトップセットアップ
図５に，撮影された画像から抽出した特徴点とデスクト
ップ画面上のアプリケーションウィンドウの特徴点とのマッチング結果の例を示す．また，実験によって得られた認
図 4: 実験条件（左：デスクトップセットアップ，
右：ミーティングルームセットアップ）
Figure 4 : Conditions in technical evaluation

識精度の一覧を表１に示す．表より，0 度条件の場合にはすべてのコンテンツにおいて 100%の精度で正確にウィンドウを認識できた．水平方向 45 度条件の場合は 2 つの異バスト性と，ユーザが写真を撮影してからクライアントデ

なる文章は 50%の認識率であり，それ以外のコンテンツでバイス上にアプリケーションウィンドウが獲得されるまでは 100%に近い精度で認識が可能であった．垂直方向 60 度の応答時間を検証する．

の条件では，2 つの異なる文章の場合 50%の認識率であり，

図４左に示すように，４方向からアプリケーションウィ

その他の条件では高い精度で認識することが可能であったンドウを撮影する（0 度，水平方向 45 度，水平方向 75 度，（95.8%）．水平方向 75 度の条件では，画像のほうが文章よ垂直方向 60 度）．水平方向は複数人で利用する際に横方向り良い認識率という結果となった（画像：83.3%，文章：0%）．

から撮影する場面を想定し，垂直方向はユーザが直立した

これらの結果は，本研究の目的である日常的な使用におい状態のまま撮影することを想定している．全ての条件におては十分に満足できるものであると思われる．やや特殊ないてモバイルデバイスとスクリーンの距離は 65cm である．

状況である水平方向 75 度の文章条件においては，さらに5.1.2 ミーティングルームセットアップ

精度の高い画像処理手法を用いることで改善すると考えら

ミーティングルームセットアップでは，デスクトップセ

れる．

ッアップで用いたコンピュータを使用し， ディスプレイのまた，特徴点を抽出し，それぞれの画像を比較するまで代わりに DLP プロジェクタ（PT-DW740, 7000 lm, WXGA）にかかった時間は全ての条件で平均 302 ms（SD=94 ms）でを用いて 130 インチの壁掛けスクリーンへデスクトップ画

あり，画像をホストデバイスに送信するまでの時間は平均面を投影する．クライアントデバイスはデスクトップセッ

84 ms（SD=28 ms）であったので，モバイルデバイス上にア

トアップと同一のものを使用する．

プリケーションウィンドウが表示されるまでの時間はトー

図４右に示すように，角度は 0 度（正面）と水平方向 30

タルで平均 386 ms であった．これは 1 秒以下でアプリケー

度，距離はスクリーンから 400cm と 700cm の条件で撮影をションウィンドウを取得することが可能であることを示し，行う．ミーティングルームセットアップでは垂直方向へのアドホックな場面に対して十分な速さであると考えられる．

変化条件は用いない．

これらの結果はネットワーク環境にも依存するので，関連

5.1.3 表示コンテンツ

研究との単純な比較を行うことは不可能であるが，Deep

ホストデバイスのディスプレイ上に表示するコンテンツ

Shot はデータを移行するのにかかる時間を 7.7 秒と報告しとして，文章のみ，写真のみ，２つの異なる文章，２つのたのに対して十分な速度であると考えられる．

異なる写真，文章と写真，の 5 つを採用する．ディスプレ

5.2.2 ミーティングルームセットアップ

イ上に表示されるコンテンツが１つのみの場合はフルスク

表２には，ミーティングセットアップにおけるウィンド

リーンモードで表示し，２つのコンテンツが表示されていウ認識精度を示す．全ての条件の平均値は 99.2%となった．

る場合，画面を２分割するように表示した．文章には Lorem

最も認識が難しい 700cm かつ 30 度の条件のときのみ平均

ipsum を用い，フォントは Times New Roman 14 ポイント，
白地に黒色の文字を利用した．写真はフルカラーの Lennaとグレースケールのクッキーの写真を利用する．

表 1：デスクトップセットアップにおける認識精度
Table 1 : Application detection accuracy in desktop setup

5.1.4 実験方法

コンテンツ/角度

0度

45 度

75 度

60 度

文章

100%

100%

0%

100%

写真

100%

100%

100%

100%

２つの異なる文章

100%

50%

0%

50%

２つの異なる写真

100%

100%

50%

100%

文章と写真

100%

100%

50%

83%

実験者がディスプレイ上に表示されたアプリケーショ
ンウィンドウを各５回撮影し，正しいアプリケーションウ
ィンドウが取得できたか，ウィンドウを取得するまでの時間を計測する．表示コンテンツが２つの場合は，モバイル
デバイスに近いウィンドウ，遠いウィンドウのそれぞれに対して３回ずつ撮影を行う．実験者はアプリケーションウ© 2017 Information Processing Society of Japan5

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

図 5: 特徴点抽出・画像マッチングの例．黄色い線の左側は撮影された画像，右側はアプリケーションのスクリーンショット．
１: 文章のみ（0 度），２: 写真のみ（0 度），３: 文章のみ（45 度），
４: 異なる２つの文章（45 度），５: 写真のみ（75 度），６: 文章のみ（75 度）
Figure 5 : Examples of feature extraction and image matching

83.3%となったが，その他の条件では 100%に近い精度でアケートによる主観評価と，実験参加者の頭部に取り付けたプリケーションウィンドウを取得することができた．距離カメラで撮影した操作の様子から，定量的にタスク完了時に関してはカメラの性能に大きく依存するため，今後モバ間を評価する．また，参加者に 2 つの既存のアプリケーシ

イルデバイスのカメラの性能が向上するに従い，精度もよョン（TeamViewer, Google Apps）で同様のタスクを行ってり良くなると考えられる．

もらい，CamCutter と比較する．今回，TeamViewer（スクリ

計算時間は，全条件平均 241 ms（SD=48 ms）という結果

ーンシェアリング）を比較対象として選んだ理由は，安定が得られた．また，写真の転送速度は 34 ms（SD=16ms）でして動作するフリーソフトウェアであり，モバイルデバイ

あった．これは，撮影の際に光学ズーム機能を用いて撮影

ス上でも利用が可能であることと，CamCutter が想定するを行ったことで画像サイズが小さくなった為と考えられる．

アプリケーション共有が実現できるためである．同様に

以上，2 つの代表的なセッティングにおける実験結果か

Google Apps も，特定の場面（文章作成やスライドの編集なら，CamCutter を利用することで，正確に素早くウィンドウ

ど）において CamCutter と同様に複数人で，そしてデスクを特定して獲得できることが分かった．

トップ・モバイルを問わず使用できるため比較対象とした．

6. ユーザスタディ

参加者は情報科学分野の学生 12 人（男性 9 名，女性 3 名）
で，７名が日常的にタブレット型デバイスを利用しており，

次に，実験参加者に CamCutter を利用してもらい，アン
表 2：ミーティングルームセットアップにおける認識精度
Table 2 : Application detection accuracy in meeting room setup

４名が TeamViewer を，7 名が Google Apps を以前利用した経験があった．実験環境は性能評価で用いた構成と同じである．各手法間でカウンターバランスを取った．
6.1 実験方法コンテンツ

距離 (cm)

400
文章
700
400
写真
700
400
２つの異なる文章700
400
２つの異なる写真
700
400
文章と写真
700

角度(度)

実験で用いる手法は TeamViewer（スクリーン共有，マウ

精度

0

100%

30

100%

0

100%

スポインタ操作），Google Apps（アプリケーション共有，タッチ操作），CamCutter（アプリケーション共有，タッチ操

30

80%

作）の３手法である．実験は 2 つのタスク（リーディング

0

100%

タスク，コラボレーションタスク）から構成され，リーデ

30

100%

0

100%

ィングタスクは CamCutter の個人での利用を想定し，コラ

30

100%

ボレーションタスクは CamCutter を用いた複数人での協調

0

100%

作業を想定している．実験が開始される前に年齢，スクリ

30

100%

ーン共有の経験の有無などの一般的な項目に関するアンケ

0

100%

30

83%

0

100%

ェーズ，事後アンケートの３段階に分かれている．次にそ

30

100%

れぞれのタスクを詳細に説明する．

0

100%

1.

30

100%

0

100%

ート調査を行う．２つのタスクは，共有フェーズ，作業フ

共有フェーズ
リーディングタスク: まず，デスクトップ画面上に

30

100%

はアプリケーションが何も表示されていない状態から

0

100%

実験は開始する．参加者はキーボードの Win+D キーを

30

50%

押下することで，タスクアプリケーションウィンドウ© 2017 Information Processing Society of Japan6

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

図６: 3 手法に対する５段階リッカート尺度を用いた主観評価
Figure 6 : Subjective evaluation of three tools by 5-point Likert scaleとその他の２つのアプリケーションウィンドウがディ

TeamViewer: モバイルデバイス上のクライアントアプリケ

スプレイ上に表示される．参加者はタスクアプリケーーションを起動する．画面上に表示されたホストマシンをションウィンドウ上に表示された短い文章（500 文字

選択し，接続ボタンを押す．（３ステップ）程度）の第一段落（250 文字程度）を読む．

GoogleApps: モバイルデバイスでアプリケーションを起動

コラボレーションタスク: 実験開始に伴い，参加者する．“実験”というフォルダを選択し，“タスク１”というは実験者のいるデスクへ向かう．実験者は，参加者にフォルダを選択する．文章ファイルを選択する．
（４ステッ

対して共有するアプリケーションとその共有手法を指

プ）

示する．

CamCutter: モバイルデバイスでクライアントアプリケー

共通: 参加者は３手法の内の指定された手法で，手元のモバイルデバイス上にディスプレイ上のタスクア
プリケーションウィンドウを共有する．
2.

作業フェーズ

次にコラボレーションタスクにおけるそれぞれの手法の操作方法を説明する．

リーティングタスク: 参加者はアプリケーションウ

TeamViewer: モバイルデバイスのクライアントアプリケー
ションを起動し，ソフトウェアキーボードを用いて実験者認したあと，同じ室内にいる実験者のもとへ向かう．

から説明された ID とパスワードを入力する．接続ボタン

実験者は，参加者が持つ短い文章に関する５つの質問を押す．（３ステップ）を行う．この際，実験参加者は手元のデバイスで文章

GoogleApps: モバイルデバイスでブラウザアプリケーショを確認しながら回答してよい．

ン（safari）を起動し，ソフトウェアキーボードを用いて共有 URL を打ち込む．画面上にファイルが表示された後，スの画面上に表示された図形の色と位置をタッチ操作“アプリで開く”ボタンを押す．（３ステップ）

で変更し，実験者はそれらを組み立てて，家や車など

CamCutter: モバイルデバイスでクライアントアプリケーの図形を作成する．

ションを起動する．デスクトップ画面上のアプリケーショ

事後アンケート

ンウィンドウを撮影する．（２ステップ）

共通：実験参加者は，先ほど使用した手法について，

4.

ンウィンドウを撮影する．（２ステップ）

ィンドウがモバイルデバイス上に共有できたことを確

コラボレーションタスク: 参加者はモバイルデバイ

3.

ションを起動する．デスクトップ画面上のアプリケーショ

6.2 結果と考察

共有の簡単さ，速さ，協調作業のしやすさ（コラボレ

本実験で得られたデータはコルモゴロフ–スミルノフ検ーションタスクのみ）を５段階リッカート尺度で評価

定により正規分布に従わないと判定されたため，ウィルコする．

クソンの符号順位検定を用いてそれぞれの手法間で一対比

インタビュー

較を行った．図 6 のグラフにおいてリーディングタスクで全ての試行が終わった後，今回行った２つのシナリ

は，共有の簡単さと共有の速さ，コラボレーションタスク

オを日常的に行うか，どの手法が最も使いやすかった

では，共有の簡単さ，共有の速さと協調作業のしやすさをかを質問する．

5 段階のリッカート尺度で実験参加者が評価した値を表し次にリーディングタスクにおけるそれぞれの手法の操作方法を説明する．リーディングタスクでは，個人使用の場面を想定しているため，アカウントのログインは自動で行
われるものとした．

© 2017 Information Processing Society of Japanた．グラフ間のバーは有意差が見られたことを示している．
（* p < 0.05, ** p < 0.01）
リーディングタスクでは，図６左から分かるように，共有の簡単さと速さの両方で CamCutter とその他の２つの手

7

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

デスクトップ画面上で反映されたため，うまく協調作業が行えないと実験参加者が感じたと考えられる．ビデオコー
ディングの結果は，TeamViewer（98.4 秒），GoogleApps（69.8秒），CamCutter（60.8 秒）であった．実験参加者の主観評
価とビデオコーディングによる定量的な評価の両面から見て，CamCutter は有意に最も良い手法であった．
２つの実験を通して多くの実験参加者は CamCutter が一番使いやすいと感じた（図７上段）．また，75%の実験参加
者がリーディングタスクで体験したような自分のコンピュータ上のアプリケーションやファイルを自分の席から離れて利用することが週に数回以上あり，50％の実験参加者がコラボレーションタスクで行ったような複数人での協調作
業を週に数回以上行っていることが分かった（図７下段）．
図７: 総合的に最も優れていた手法（上段），
実験シナリオと同じような状況をどれくらいの頻度で経験しているか（下段）Figure 7 : “Preferred tool” (top). “Users’ answers to ‘how often do you
meet this kind of situation’” (bottom)

7. まとめ以上，モバイルデバイスのカメラを用いたアドホックア
プリケーション共有手法を提案した．本研究で行った性能法の間に有意差が認められた．共有の簡単さの観点では，
this kind of situation’”評価により，複数のデバイス間で CamCutter が素早く，正GoogleApps は文章を共有するまでに，複数のディレクトリ

確にアプリケーションを共有できることを示した．また，階層を探索し，文章ファイルを見つける必要があったため，

ユーザスタディにより，我々が想定したアプリケーション

その他の手法に比べて簡単だと被験者が感じなかったと考シナリオにおいて，代表的な従来手法に比べ簡単に，素早えられる．また，TeamViewer は GoogleApps に比べて簡単

く ユー ザ が CamCutter を扱 え るこ と を 明 らか に し た ．

であったが，モバイルデバイス上で TeamViewer を起動しCamCutter はアプリケーション共有とモバイルデバイスのた後にログインの時間（10 秒程度）がかかったため，共有カメラを組み合わせることで，図１に示したようなアドホの速さにおいて低いスコアとなった．ビデオコーディング

ックな場面において優れた効果を発揮することを確認した．

によって，それぞれの手法が共有フェーズを開始してから，性能評価において，文章ウィンドウの認識精度が十分で完了するまでに掛かった時間を測定したところ，はない結果が得られた．これは，我々がプロトタイプで用

GoogleApps（7.8 秒）と CamCutter（10.8 秒）の間に有意差いた A-KAZE などの画像処理技術の発展に伴い，更なる精が見られ，CamCutter と TeamViewer（21 秒）の間にも有意度で認識が可能になると考えられる．

差が見られた．ビデオコーディングによる結果は，実験参プライバシやセキュリティに関する問題はカメラを利用

加者の共有の速さにおける主観評価の結果と異なるものでする際の一般的な問題であるため，本研究ではこれについあった．これは，GoogleApps はアプリケーションを共有すて特に言及をして来なかったが，あらかじめ認証されているまでにファイルの探索をするため，心理的にはそれほどない端末では利用できない，写真を撮影した際にポップア

素早く感じなかったものと考えられる．

ップ（アラート）を表示するなどの対策が考えられる．まコラボレーションタスクでは，CamCutter は TeamViewer

た，写真の撮影された角度と距離を推定することで機密性と GoogleApps よりも簡単に速く共有できるという結果をの高い情報を持つアプリケーションは有効範囲を狭め，プ得られた．これらの結果から協調作業の場ではカメラでア

レゼンテーションなどのパブリックな環境では広い範囲か

プリケーションウィンドウを撮影するという操作がより速らの撮影を許可する，などの運用ポリシーを設定すること

く，適していると考えられる．ビデオコーディングの結果も考えられる．本稿では，複数ホストデバイスと複数クラによっても CamCutter の速さは明らかである（TeamViewer:

イアントデバイス間でのインタラクションを検討しなかっ40.6 秒，GoogleApps: 62.9 秒，CamCutter: 10.2 秒）．また，たが，今回提案したシステムは，これらの可能性を考慮し協調作業のしやすさにおいては，CamCutter は他の 2 つのた上で設計されており，実効速度やトラフィックの調査な手法に比べて有意に良いという結果が得られた．

どが今後の課題である．

TeamViewer においては，インタビューで実験参加者はマウスカーソルをスワイプで動かす操作方法が難しかったと述べ，結果に影響したと考えられる．GoogleApps においては，
タブレット上で操作を行ってから少しの遅延の後，変更が© 2017 Information Processing Society of Japan8

情報処理学会 インタラクション 2017
IPSJ Interaction 201717INT001
2017/3/2

参考文献[1]

Alcantarilla, P., Nuevo, J., and Bartoli, A. Fast Explicit
Diffusion for Accelerated Features in Nonlinear Scale
Spaces. Proc. BMVC'13, 13.1–13.11.

[2]

Baur, D., Boring, S., and Feiner, S. Virtual projection:
exploring optical projection as a metaphor for multi-device
interaction. Proc. CHI ’12, 1693–1702.

[3]

Boring, S., Baur, D., Butz, A., Gustafson, S., andBaudisch, P. Touch projector: mobile interaction throughvideo. Proc. CHI’10, 2287–2296.

[4]

Bragdon, A., DeLine, R., Hinckley, K., and Ringel, M.
Code space: touch + air gesture hybrid interactions forsupporting developer meetings. Proc. ITS ’11, 1–10.

[5]Chang, T.-H. and Li, Y. Deep shot: a framework for
migrating tasks across devices using mobile phone
cameras. Proc. CHI'11, 2163–2172.

[6]

Freitas, A.A. De, Nebeling, M., Chen, X.A., et al. SnapTo-It : A User-Inspired Platform for Opportunistic Device
Interactions. Proc. CHI ’16, 5909–5920.

[7]

Liu, Q., McEvoy, P., and Lai, C.-J. Mobile camera
supported document redirection. Proc. MULTIMEDIA ’06,
791-792.

[8]Marquardt, N., Hinckley, K., and Greenberg, S. Crossdevice interaction via micro-mobility and f-formations.
Proc. UIST ’12, 13-22.

[9]

Rekimoto, J. Pick-and-drop. Proc. UIST ’97, 31–39.

[10] TeamViewer. https://www.teamviewer.com/.
[11] Google Apps. https://apps.google.co.jp/.

© 2017 Information Processing Society of Japan

9