第９部

Software Defined Media

第９部
Software Defined MediaSDM WGメンバー

第１章

メタデータを階層構造に整理し管理することを可能とはじめにする．一般的なメディア制作の流れは収録，編集，配信，再生の段階に分かれ，従来の提案であるSDM Ontology

Software Defined Media（SDM）
コンソーシアムは，2014

Version 1 [55, 56]では，メディアの収録段階における環年に設立され，オブジェクト指向のディジタルメディア

境や内容，対象に関する記述を可能とする設計となってと，インターネット環境が前提の映像・音響空間を用いいたが，収録段階に続く，編集，配信，再生の段階についたビジネス創造を目指してきた．昨年までの報告書でては記述対象外であった．今回，主にメディア編集・加工

は，SDMのコンセプトやアーキテクチャ，試作プラット段階に関する記述も対象範囲に含むようにSDMOntology

フォーム[51, 52]，データ収録[53]，収録データベース

Version 1の 構 造 を 見 直 し，修 正 お よ び 拡 張 し たSDM

設計[54, 55, 56]，SDMプラットホームを利用したアプ

Ontology Version 2 [54]を提案する．[54]の提案をもと

2

リケーションであるSDM360 [57, 58]やLiVRation [59,260]、Web360 [61]などを報告してきた．

に語彙の構造や命名規則を整理し，オントロジーを洗練させた．SDM Ontologyの記述可能な範囲の概要を図1に示す．

本報告書では，2020年度に実施した活動を報告する．
2.1
第２章

SDM Ontology Version 2.0の策定

要求事項

メディア収録の情報は静的であり，一度メタデータを階層構造化してしまえばアーカイブとして扱うことができる．したがって，収録段階のみを対象としていたSDM

SDMコンソーシアムが提案するSDM Ontologyは，メディ

Ontology Version 1では，静的データを記述することがアデータとともに様々な種類・粒度，かつ，膨大な量の可能な構造に設計されていた．一方で，メディアの編集・加工作業は収録されたデータや編集されたデータをもとに繰り返しおこなわれることも多く，一般に動的といえるため従来の静的データを記述するための構造設計では対応しきれない．
また，Version 1では，カメラやマイクなどの収録機器とメディアファイルは1対1関係で対応付けられることが前提となっていたが，編集段階を考えると必ずしもメディ
アファイルは収録機器だけが生成するものではなく，編図1

メディア制作フローの概要とSDM Ontologyの記述可

集用のソフトウェアやミキサーなどのメディアプロセッ

能な範囲．SDM Ontology Version 1では収録段階まサから生成される場合もある．さらには，編集作業に用で，SDM Ontology Version 2では収録段階および編いられるメディアプロセッサの情報を記述するための構

集・加工段階までを主な対象範囲とする．

造が設計にない．

71このような問題を解消するためにSDM Ontology Version

的な知識やイベント内容などの特に具体的な情報は適1の設計を見直して，オントロジーを修正・拡張する必要

宜外部オントロジーと組み合わせて記述することとすがある．修正・拡張に関する主な要求事項を以下に記す．

る．さらに，対象メディアを三次元映像・音声メディア前提だったものから「時空間情報をもつメディア」へと動的な情報を記述するための再帰構造の導入

抽象度を高め，センサー群によるデータメディアなど

メディアの編集・加工作業は多数の編集工程を経ておも表現対象となるようにオントロジーを拡張した．ここなわれる場合が多い．素材となる収録データを加工のような抽象化によってSDM Ontologyはより幅広い

して「1次加工物」を生成し，これを素材としてさらに加種類のメディアを取り扱い，メディアコンテンツの制工することで「2次加工物」を生成する．この過程を繰

作を管理する汎用性の高いオントロジーとなる．

り返して生まれた「n次加工物」がメディアコンテンツの最終的な完成形として世の中に出回っていくことが2.2

一般的である．繰り返しによる動的情報は再帰的な構

2.1で述べた要求事項をもとにオントロジーの修正・拡張

造によって記述することが可能であり，メディアデーをおこない，SDM Ontology Version 2を提案する．

SDM Ontology Version 2の概要

タの編集履歴を作成することが可能となる．また，再帰的記述は動的な構造の表現だけでなく包含関係の表

以下の各項では，オントロジーの構造を図2から図3，図現も可能とする．包含関係の表現は静的情報の記述に

4，図5までに示すように図示しながら説明する．図中の対しても非常に有効であり，Version 1では記述できな各ノードはオントロジーのクラスであり，赤字で記されかった詳細な情報構造を表現できるようになる．例えたクラスはSDM Ontologyにおいて特に重要な，オントロ

ば，マイクアレイとは，複数のマイクを配置し単一のジー構造の核である基本クラスを表し，青字のクラスはマイクだけでは得られない音の空間情報を収録する収その他のクラスを表す．クラスノード内に書かれた内容

録機器であり，マイクアレイ自体を1つの収録機器とはDatatype Property（データ型プロパティ）と呼ばれるオ

見ることもできれば，マイクアレイがもつ単一のマイントロジーの語彙（述語）であり，目的語に文字列や数値，

クを収録機器の最小単位としてマイクアレイはそれら

URIなどのリテラルをとる．ノード間をつなぐ黒色矢印を包含する収録機器である，と記述することもできる．

の傍らに書かれているのはObject Property（オブジェク

逆に，同じ対象を収録する収録機器群をグループ化しトプロパティ）と呼ばれる語彙（述語）であり，矢印の根本て収録機器グループを記述したり，収録機器グループ

側のクラスがもつ述語である．目的語には矢印が指す先群をさらにグループ化することで収録機器環境そののクラスインスタンスをとり，クラスインスタンス間のものを記述することも可能となる．このように再帰的関係性を表す．一方で，図3以降に描かれるノード間をつ記述の導入は，メディアの編集・加工段階の表現だけなぐオレンジ色矢印はクラスの親子関係を表し，矢印根

でなく詳細な情報の表現にも貢献し，SDM Ontology

本のクラスは矢印が指すクラスのサブクラスである．

Version 2における大きな変更点の1つである．
それぞれの語彙は原則として，SDM Ontologyのベース
時空間メディアへの抽象化

72

URIで あ るhttp://sdm.hongo.wide.ad.jp/sdmo/か ら の 相

不足していたメディア編集・加工段階の構造設計と並対URIで 示 し て い る．図2のMediaク ラ ス で は ノ ー ド に行して従来設計の見直しをおこなう．SDM Ontology“Media”と記されているが，正式にはhttp://sdm.hongo.

Version 1の設計では，音楽イベントに踏み込んだクラwide.ad.jp/sdmo/Mediaという絶対URIによって識別されスや語彙も多く用意していたが，それぞれの分野・イベ

る．また，Mediaクラスのノード内の“startAt”というデーントに特化した記述は，既存の外部のオントロジーと

タ 型 プ ロ パ テ ィ はhttp://sdm.hongo.wide.ad.jp/sdmo/

連携することで表現可能であると考える．Version 2でstartAtで識別される．ただし，外部オントロジーを利用

は，オントロジーの表現対象はメディアコンテンツのしている場合には「接頭辞+相対URI」の形で示してあり，

制作フローの核となる部分にとどめ，分野ごとの専門

例えば，接頭辞“schema:”がhttp://schema.org/ [62]を表し，相 対URIが“name”で あ る“schema:name”は，http://

義し，Geometryクラスではこの座標系における点（1, 2,

schema.org/nameと等価である．ベースURIや接頭辞の情3）を表現するなどして運用する．CoordinateSystemクラ報は図中では省略しているが，通常，オントロジー定義

スのインスタンスとGeometryクラスのインスタンスは*1を記述するOWL（Web Ontology Language） ファイルや

measures/measuredByプロパティで相互参照し座標系*2
RDF（Resource Description Framework）
データのファイ

定義をおこない，Geometryクラスのインスタンスは基ルの先頭にまとめて記述される．

本クラスの各インスタンスとgeometryOf/geometryAtプ
ロパティのリンクによって時空間メタデータを与える．

2.2.1

構造概要

CoordinateSystemクラスとGeometryクラスはそれぞれ，

SDM Ontology Version 2の構造概要を図2に示す．基本

ignf:CoordinateSystem [63]*4，geom:Point [64]*5 の サ ブ

クラスを設計するにあたり次の考察をおこなった．現

クラスとして定義しているが，SDM Ontologyを用いた実空間内での出来事は収録・編集作業によってデジタル

メディア管理の実運用時には座標系定義や座標記述よりデータに記録され，仮想空間内で取り扱うことが可能とも多くの時空間情報を表現しなければならないことが予なる．逆に，デジタルデータを用いて生成した仮想空間

想され，表現力の不足が懸念される．CoordinateSystem

は再生システムによって現実空間内で再生することがクラスとGeometryクラスの詳細な構造の検討や整備につ可能となる．SDM Ontologyはここでいうデジタルデー

いては今後の課題としたい．

*3

タをMediaと呼び，Mediaの収録，編集・加工，再生 の流れを包括的に記述するために設計したオントロジー

図2 右下にあるMediaEventクラスはMediaクラスの包含である．現実空間の事象をMediaに記録するシステムを関係を表現するための補助クラスであり，詳細は2.2.4でRecorder，Mediaを 編 集・加 工，ま た は，分 析，生 成 す述べる．

るシステムをProcessor，Mediaを再生するシステムを
Playerと呼ぶ．また，Mediaやこれらのシステムは様々な

2.2.2

Contextクラス

メタデータをもち，これをContextと呼ぶ．ここで述べた

Contextク ラ ス はSDM Ontologyの 基 本 ク ラ ス が も つ要素をすべてメディア制作において重要であると考え，様々なメタデータを包括的に記述するためのクラスでSDM Ontology Version 2ではこれらの要素を表現するたある．メタデータの種類を大別してSDMEventクラス，

めのContextクラス，Recorderクラス，Processorクラス，

Targetクラス，Programクラスをサブクラスとしてもつ．

Playerクラス，Mediaクラスの5つを基本クラスとする．

Contextクラス，および，そのサブクラスに関する構造図

基本クラスの詳細は2.2.2から2.2.4にかけて説明する．

を図3に示す．

2.1で 述 べ た よ う に，SDM Ontology Version2で は「時

SDMEventクラスは収録対象である現実空間内での事象

空間情報をもつメディア」を取り扱うことを前提とする（イベント）に関する日時や場所をはじめとする様々な収ため，メタデータの中でも特に時空間情報は重要な意

録環境のメタデータを記述し，Targetクラスは収録対象味をもつと考え，時空間メタデータの扱いに特化したである人物やモノを記述する．収録対象のイベントがもCoordinateSystemク ラ ス，Geometryク ラ ス を 定 義 し，

ついくつかの意味をもつ事象のまとまりをプログラムとContextクラスとは分離して表現する．CoordinateSystem

呼び，Programクラスではこれを記述する．例えば，あるク ラ ス で 時 空 間 座 標 系 を 定 義 し，Geometryク ラ ス にコンサートを記述する場合，コンサート名や開催日時・場

よって時空間座標系上の点（座標）を表現する．例えば，所はSDMEventクラス，指揮者や演奏者，楽器はTargetク

CoordinateSystemクラスで右手系のxyz空間座標系を定ラス，演目はProgramクラスのように整理して記述可能＊1

https://www.w3.org/OWL/＊2

https://www.w3.org/RDF/＊3

SDM Ontology Version 2は特に編集・加工段階の表現に注力して設計したが，後々必要になってくるだろう再生段階の記述に関しても最低限導入している＊4

http://data.ign.fr/def/ignf#CoordinateSystem＊5

http://data.ign.fr/def/geometrie#Point

73

図2

SDM Ontology Version 2の構造概要．各ノードはクラスであり，赤字は基本クラスを表し，青字はその他のクラスを表す．
ノード内に書かれた語彙はデータ型プロパティであり，ノード間をつなぐ黒色矢印はオブジェクトプロパティである．

図3

SDM Ontology Version 2のContextクラスの概要．各ノードはクラスであり，ノード内に書かれた語彙はデータ型プロパ
ティ，ノード間をつなぐ黒色矢印はオブジェクトプロパティである．また，ノード間をつなぐオレンジ色矢印はクラスの親子関係を表す．

74

である．ただし，プログラムを収録対象のモノであるとオカメラやスマートフォンがもつ映像収録機構を切りいう見方をすれば，Programクラスの内容はTargetクラ出してVideoRecorderクラスのインスタンス，ステレオ

スで記述することも可能であるため，将来的にProgram

音声収録機構を2chまとめて，あるいは，1chずつ切り

クラスは廃止される可能性がある．
SDM Ontology Version 1で はSDMEventク ラ ス やTarget
クラスは，Contextクラスと並ぶ基本クラスとして定義されていたが，いずれも大局的に見るとメタデータの記述をおこなう共通の働きをもつことからSDMEventクラスやTargetクラスをContextクラスのサブクラスとして定義し直した．また，Version 1は音楽イベントのメディア収録を前提として設計したオントロジーであったため，
音楽イベントに特化したクラスなど具体的で詳細なクラスがいくつか用意されていたが，Version 2では音楽イベ
ントに限らず「時空間情報をもつメディア」を取り扱うことのできるよう具体的なクラス・プロパティは削除し構造をシンプルに，抽象度を高めた．したがって，Version2を用いて音楽イベントのデータを記述する場合にはSDM Ontologyでメディア制作の核の部分を記述し，演奏された楽曲や演奏者，楽器などの情報は音楽を専門とする外部のオントロジーと連携して記述することになる．
2.2.3 Recorderクラス，Processorクラス，Playerクラス
Recorderクラス，Processorクラス，Playerクラスはそれぞれ図4に示すように用途を詳細に表現できるサブクラ
スと包含関係を記述するためのサブクラスをもつ．
Recorderク ラ ス，Processorク ラ ス，Playerク ラ ス のそ れ ぞ れ で 同 じ 構 造 を と る た め，こ こ で は 代 表 し てRecorderクラスについて述べる．Recorderクラスのサブ ク ラ ス に は よ り 用 途 が 詳 細 なDataRecorderク ラ ス，
AudioRecorderク ラ ス，VideoRecorderク ラ ス と 包 含 関
係を表現するCompositeRecoderクラスを定義する．例
えば，ビデオカメラやスマートフォンなどでの動画撮
影 で は，一 般 に 映 像 収 録 と ス テ レ オ（2ch）音 声 収 録 が同時におこなわれる．SDM Ontology Version 1ではこ

図4

SDM Ontology Version 2のRecorderクラス，

れ ら をRecorderク ラ ス，あ る い は，映 像 収 録 が メ イ ン

Processorクラス，Playerクラスの概要．各ノードはク

で あ る 場 合 はVideoRecorderク ラ ス の イ ン ス タ ン ス とラスであり，ノード内に書かれた語彙はデータ型プロ

して記述することは可能であった．Version 2では従来

パティ，ノード間をつなぐ黒色矢印はオブジェクトプ

通 り 単 純 にRecorderク ラ ス あ る い はVideoRecorderク

ロパティである．また，ノード間をつなぐオレンジ色

ラスのインスタンスと記述することもできれば，ビデ

矢印はクラスの親子関係を表す．

75

出 し てAudioRecorderク ラ ス の イ ン ス タ ン ス と し て 定

2.2.4

Mediaクラス

義し，ビデオカメラやスマートフォン自体はこれらのMediaクラスについてもRecorderクラス，ProcessorクラVideoRecorderクラス，AudioRecorderクラスインスタン

ス，Playerクラスと同様にサブクラスをもつ．ただし，メスを包含するCompositeRecorderクラスのインスタンス

ディア編集の記述のために図5に示すように，Recorderとして記述することも可能となる．2.1で述べたマイク

クラス，Processorクラス，Playerクラスの構造とは少しアレイの例も同様の方法で記述することができる．また，異なりMediaEventクラスとの連携が発生する．

カメラやマイクあるいはセンサなどのそれぞれ独立な収録機器が同じ対象を収録していた場合，これらをグルー

メディア管理においては，メディアデータの記録時刻をプ化したい場合がある．この場合にもCompositeRecorder

管理するための絶対的な時間軸（通常は現実空間内の時

クラスによる包含関係の記述によって収録機器グループ間軸）のほかに，記録されたメディアデータの再生区間の記述が可能であり，再帰的な包含関係の記述によってを表す相対的な時間軸など，複数の時間軸を意識する必

収録環境全体を1つのグループとして記述することも可

要があり，時間情報の取り扱いは重要である．Mediaク

能となる．Processorクラス，
Playerクラスでも同様であり，ラスには時間情報を扱うプロパティとして，メディア

包含関係を記述する“Composite”クラスの再帰的な特性にデータの記録を開始した時刻を表すmediaStartAtプロパ

よって収録，編集・加工，再生システムはそれぞれ機器の

ティ，メディアファイルの有効な再生区間を示すための最小単位（ミクロ）から複合系（マクロ）までユースケース

startAt/endAtプロパティを用意した．mediaStartAtプロにあわせた自由な粒度で記述することが可能となる．

パティが絶対時刻を記述するのに対して，startAt/endAt
プロパティはメディアファイルの先頭を原点とする相対時刻を指定することに注意されたい．画像データなど時

図5 SDM Ontology Version 2のMediaクラスの概要．
各ノードはクラスであり，ノード内に書かれた語彙はデータ型プロパティ，
ノード間をつなぐ黒色矢印はオブジェクトプロパティである．また，ノード間をつなぐオレンジ色矢印はクラスの親子関
係を表す．

76

間情報を区間としてもたないメディアデータについてはstartAt/endAtプロパティをともに0とし，再生時間を0と第３章

SDMO対応アプリと普及活動

定義することで表現することができる．
3.1

Web3602

メ デ ィ ア の グ ル ー プ 化 に お い て は，Recorderク ラ ス，

SDM Ontology Version 2の普及，および，コンテンツ制

Processorクラス，Playerクラスの包含関係とは異なり，作者の視点からオントロジーの構造を考察する目的で，グループ化した各メディアの時間的な配置も重要になる

SDM Ontology Version 2準拠のデータをもとに動作する場合が多いと考える．CompositeMediaクラスを用いてアプリケーションWeb3602の開発し，実験を通して評価

メディアの包含関係を記述する際には，原則として各メをおこなった．Web3602 [61, 65]は，インタラクティブ

ディアの配置位置を記すMediaEventクラスのインスタンに360°動画および立体音響を視聴体験できるWebアプスを包含対象として指定することで，包含するメディア

リケーションである．具体的にはWebブラウザ上で，収とその時間的な配置の組み合わせを表現することができ

録済みの360°動画を用いた自由視点視聴，および，視る．例えば，CDやDVD，Blu-rayディスク上の音声や映像，

聴者の動作に追従し，個別の音源をインタラクティブに

字幕情報などのメディアデータは複数のトラックあるい

制御することができる立体音響の提示を目指す．そのたはチャプターに分かれて時間軸上に配置されている．こめ，立体音響の手法として，従来より広く用いられていれらのメディアデータをトラックやチャプターを単位とるチャンネルベースや360°動画との相性がよいとされ

し て 適 切 なAudioMedia/VideoMedia/DataMediaク ラ ス

るHOA/アンビソニックスベースではなく，個別の音源ののインスタンスとして定義したのち，MediaEventクラス

制御が容易なオブジェクトベース方式を採用する．[61,のインスタンスにそれぞれのメディアが配置されるべき65]を発表した時点では，視聴体験可能なコンテンツの情

時間位置（トラックやチャプターの開始位置）を指定し，報やメディアデータはすべてソースコードに埋め込まれCompositeMediaクラスにグループ化していくことでCDていたが，現行バージョンでは，SDM Ontology Version

やDVD，Blu-rayディスク全体のメディアデータを記述す

2との連携によってLODから情報を取得するよう実装さることが可能となる．

れている．また，JavaScriptのフレームワークであるVue.
js*6を用いてUI（User Interface）/UX（User Experience）
デ

一方で，MediaEventクラスを介することなく直接Media

ザインを含めて刷新した．

クラスのインスタンスを包含するような記述も可能であり，この場合は時間的な配置を気にしない単なる包含関

Web3602はGithub Pages*7にて公開している．関連する係を示すことができるほか，暗黙的に包含するすべてのアプリケーションとWeb3602の比較概要を表1にまとめメディアを再生区間の時刻0（原点）の位置に配置するこる．現行バージョンでの視聴位置の移動は実験段階のβとを表す．この表現方法では，同じメディアデータ内に機能であり，視聴位置の切り替えにはネットワーク環境

映像と音声が同時に記録されている場合や複数のチャンに依存した遅延が起こる．

ネルをもつ音声を，映像・音声ごとや音声チャンネルごとに分離して個々のメディアインスタンスとして定義した

3.1.1

のち，CompositeMediaクラスで包含関係を表現するな

先に述べた目的を踏まえてWeb3602の要求事項として以

要求事項

どの運用方法が考えられる．

下を想定した．
SDM Ontology Version 2準拠のデータの活用：
SDM Ontology Version 2の 普 及 が 前 提 に あ る た め，
SDM Ontology Version 2準拠のデータの活用は必須事＊6

https://vuejs.org/＊7

https://sdm-wg.github.io/web360square-vue/

77

項である．

スしON/OFFの切り替えができる．これらの機能により，視聴者の興味関心に基づいた自由度の高い視聴体験がWebアプリケーション：

可能となる．

専用のアプリケーションをインストールすることな
く，Webブラウザから直接利用可能な手軽さを目指す．

ストリーミング配信：

SDM Ontology Version 2の普及において，誰でも手軽に

360°動画をHTTP Live Streaming（HLS）でストリーミ体験できることは望ましいと考える．

ング配信する．ストリーミング配信に対応することで，再生開始までの待機時間の短縮や余計な通信を省くこ

自由な映像音声の視聴：とが可能となる．

視聴者が自由に視聴位置や視聴角度を決めることができ，位置・角度および視聴オブジェクトがもつ3次元位置

3.1.2

設計

情報をもとに自動で適切な映像・音声をレンダリングしWeb3602のシステム設計概要を図6に示す．視聴者の動作て提示できる．

や音声オブジェクトへのタッチ操作を入力として受け付
け，操作に応じた映像や音声をシステム内でリアルタイム

インタラクティブ性：にレンダリングして出力することでインタラクティブ性

ジャイロセンサ搭載デバイスでは，インタラクティブなを実現する．映像・音声のメディアファイルはそれぞれ独

視聴角度の変化を体験することができる．また，視聴者立しており，システム内で同期をとりながら再生する．映の操作によって，各音源のオブジェクトに個別にアクセ

像ファイルに360°動画，音声ファイルにはAudioSprite*8

図6Web3602のシステム設計．ユーザのインタラクティブな操作に応じてリアルタイムに映像・音声をレンダリングする．視聴コンテンツの情報はSPARQLクエリを用いてRDFストアに問い合わせて取得する．

＊878https://github.com/tonistiigi/audiospriteによって各音源ファイルを1つにまとめた音源群が収録

ムの活動の一環で過去に収録したデータであり，[53, 55]

されている．AudioSpriteは複数の音声ファイルを，時間に，それぞれの収録環境や収録方法が記述されている．

間隔をとりながら並べて1つの音声ファイルにまとめる技術であり，再生の際のリクエスト数を減らすことがで

Web3602で活用するために，収録当時に記録していた収きるため読み込み時間を短縮することができる．また，録に関する環境や内容の情報をもとに，SDMOntology

すべての音声が1つのファイルにまとまっていることで，

Version 2準拠のRDFデータファイルを，簡潔で可読性の音声ごとの読み込み遅延を気にする必要がなくなり，音高いTurtle記法で作成・整理し，SDMコンソーシアムが声間の同期がとりやすいことも利点として挙げることが運用するGraphDB*9で構築されたRDFストア*10にデータできる．

を登録した．例えば，図7に示すように収録対象や収録機
器，生成されるメディアファイルとその編集・加工の過360°動画はHLSでストリーミング配信され，視聴者を中程など，様々な情報を整理・分類する．図8は各素材デー

心とする仮想的な球面内側に投影して再生される．また，

タ収録時の収録機器の配置を表し，このような収録に関

音声オブジェクトのもつ3次元位置情報に基づいて，動する情報を整理して図9に表すRDFデータを作成および画を投影する仮想的な球内部の各地点に音声可視化オブ登録した．Web3602は，RDFストアにWebAPIを通じてジェクトを描画し，各音声の強弱を表現したり，タッチ

SPARQLクエリを発行することでアプリケーションの動操作によってON/OFFを切り替えることができる．視聴

作に必要なデータを取得し，活用することができる．

者の動作は端末に搭載されたジャイロセンサを通してシ
ステムに入力され視聴角度が変更される．視聴角度とON

3.1.4

実装

状態にある各音声オブジェクトの位置関係から聴こえる

Web3602は，JavaScriptのフレームワークであるVue.js

べき音声を生成し出力する．

をベースに，WebVRのフレームワークであるA-Frame*11とWeb上で高度なオーディオ処理などを実行できるWeb

3.1.3

素材データ

Audio API*12を用いて実装した．コンテンツ視聴部分の実

Web3602の開発に用いた素材データは，2016年1月10

装概要を図10に示し，視聴体験中のスクリーンショット

日に慶應義塾大学日吉キャンパス内に建つ藤原洋記念を図11に示す．

ホールで開催された慶應義塾大学コレギウム・ムジク
ム古楽アカデミーのコンサートの収録データ，および，SPARQLクエリによる動的なデータ取得

2017年1月26日に六本木ミッドタウン内にあるBillboard

Web3602は，3.1.3項で言及したように，収録に関するLive Tokyoで 開 催 さ れ たMusilogue Bandの ジ ャ ズ セ ッ

様々な情報をまとめたRDFデータを格納するRDFストア

ションの収録データである．いずれもSDMコンソーシアにSPARQLクエリを発行してアプリケーションの動作に

表1

Web3602と関連するアプリケーションとの比較＊9

http://graphdb.ontotext.com/＊10

本稿では，RDFのデータを保存・格納するトリプルストア，および，RDFのクエリ言語であるSPARQLを用いてデータの問い合わせをするSPARQLエンドポイント＊11

https://aframe.io/＊12ttps://www.w3.org/TR/webaudio/の機能を有するサービスのことを指す．https://sdm.hongo.wide.ad.jp:7200/で運用している．

79

必要なデータを取得する．現状，発行するクエリは以下

理が必要になる．同期のためにそれぞれのメディアファの2種類である．

イルの長さの情報なども必要である．このように，視聴画面をレンダリングするためには選択されたあるイベン

1. 視聴体験可能なイベントの取得

トに対して様々な情報が必要であり，Web3602では，図2. あるイベントに関する映像・音声メディアファイルや14のSPARQLクエリを用いて収集する．

座標情報などの取得
A-Frameを用いた処理概要
視聴体験可能なイベントの取得
2

A-Frameを用いて，図10の右点線枠の手順で360°動画

Web360 にアクセスすると，はじめに図12のようなイベの投影や音声可視化オブジェクトの描画をおこなう．

ント選択画面が表示される．この画面に表示されるイベ

360°動画はHLSでストリーミング配信され，A-Frameのントの各情報は，アプリケーションからRDFストアに向a-videosphereオブジェクトを用いて，カメラの座標を基

けて図13のSPARQLクエリを発行し取得される．

点に広がる球面内部に映像を投影する．HLSはSafariやEdge，一部のモバイル端末用ブラウザではネイティブサ

あるイベントに関する映像・音声メディアファイルや座

ポートされているが，ChromeやFirefox，IEなどサポー

標情報などの取得

トしていないブラウザも多く存在するため，hls.js*13をイベント選択画面から1つのイベントを選択してタップあるいはクリックすると，図11のような視聴画面に遷移する．視聴画面では視点に対して音声可視化オブジェク
トがそれぞれ正しい配置でレンダリングされる必要があ
るため，360°動画や各音声のメディア以外に，それらの座標情報が必要となる．また，映像・音声はそれぞれ独立したメディアファイルを用いるため映像と音声の同期処

図7

SDM Ontology Version 2に準拠するデータ作成の80

慶應義塾大学コレギウム・ムジクム古楽アカデミーの概要．メディアの収録や編集・加工について，SDMコンサート（上），および，Musilogue Bandのジャズ

Ontology Version 2が定義するクラスやプロパティ

セッション（下）の収録機器の配置を表す[55]．

を用いて整理・分類し，RDFデータを作成する．
＊13

図8

https://github.com/video-dev/hls.js/

用いて対応した．音声の可視化はWeb Audio のAnalyser

じて，A-Frameが自動的に適切な相対位置を計算しながノードから提供される各音声の周波数領域データを用い

らレンダリングするが，Web Audio上で音声オブジェクて表現している．

トは視聴角度の変動を自動追従できないため，カメラの視聴角度と絶対座標から相対座標を随時計算してPanner

また，視聴者のインタラクティブな操作は主にA-Frame

ノードに受け渡すことで音声の追従性を実現する．例えが担う処理を介して入力される．視聴者の頭部動作は端ば，視聴角度に対して音声オブジェクトが右側に存在す末に搭載されたジャイロセンサに検知され，A-Frameのれば右側で音が鳴っているような音声を生成することがカメラオブジェクトに入力されることで視聴角度が変更できる．また，各音声の周波数領域データはAnalyserノー

される．タッチ操作はA-Frameでレンダリングしたオブドで計算され，A-Frameの音声の可視化処理に用いる．

ジェクトにタッチすることで入力として認識され，各音以上の処理までは各音源ごとにされ，最後にマスターゲ

声のON/OFF状態を変更することができる．

インとなるGainノードやDynamicsCompressorノードでまとめられバイノーラル出力される．

Web Audio APIを用いた処理概要
図 10 の 左 点 線 枠 に 示 す よ う に，Web Audio の

音声の可視化

AudioContext上で各ノードを鎖状に繋いでいき，視聴位

音声可視化オブジェクトは音声の周波数領域データに置・角度とON状態の各音声オブジェクトから聴こえるべ

対応する棘状オブジェクトをもち，対応する周波数デー

き音声をリアルタイムレンダリングする．はじめに各音タの大きさによって長さや色を変化する．この棘状オブ源が1つにまとめられたAudioSpriteのファイルデータかジェクトは[67]のアルゴリズムを参考に球面上に可能なら各音源を抽出し，Buffer Sourceノードに入力する．次限り均等に配置している．ただし，[67]では球面の極周のGainノードでは，OFF状態の音声のゲインを0にする

辺における分布のずれの補正に関する言及があるが，配ことで音声のON/OFF状態を表現する．映像はある視聴置に関してそこまでの精度を必要としないことから補正

位置に対して視聴角度と各オブジェクトの絶対座標に応項の導入はおこなっていない．音声可視化オブジェクトがもつ棘の数は32としているため，図15に示す対応する
音声の周波数領域データを32個の値に変換する処理が必要である．
Web AudioのAnalyserノードでは，時間領域データやFFT（Fast Fourier Transform，高速フーリエ変換）による周
波数領域データを取得することができ，AnalyserNode.
getByteFrequencyData()メ ソ ッ ド を 用 い て 周 波 数 デ ー
タを取得する．周波数データの取得は音声可視化オブジ ェ ク ト を 構 成 す るA-Frameコ ン ポ ー ネ ン ト のtickハン ド ラ を 用 い て 毎 秒20回 程 度 の オ ー ダ ー で 繰 り 返 し
お こ な わ れ る．Web Audioの デ フ ォ ル ト の サ ン プ リ
ン グ 周 波 数 はOSや ブ ラ ウ ザ に 依 存 す る 値 で，一 般 には44,100Hzま た は48,000Hzで あ り，AnalyserNode.
getByteFrequencyData()メソッドによってナイキスト周

図9

素材データ収録をSDM Ontology Version 2に準拠す

波数22,050Hzまたは24,000Hz以下の周波数データが得るように記述したRDFデータ．例として収録機器配置られるが，極端な高周波数帯・低周波数帯にはあまりデーに関する記述の一部を抜粋している．データはTurtle

タが存在せず，有効な値が含まれる周波数の範囲は限ら記法で記述されている．

れていることが多い．そこで，一度でも有効な値が現れ81

たことがある周波数の上限・下限をとり，この範囲を有

緑，黄，オレンジ，赤と変化していく．

効周波数帯とする．有効周波数帯は再生開始から周波数データが取得される度に更新される．有効周波数帯の中負荷軽減に含まれるデータを周波数の高さの順に可能な限り要素

音源1つにつき32本の棘状オブジェクトをもつ音声可数が均等な32グループに分けて，グループ内で平均値を視化オブジェクトを生成し，さらにそれらがすべて独立計算する．得られた32グループそれぞれの平均値は音声に長さや色を変化させるため，デバイスがおこなうべき

可視化オブジェクトの32本の棘の長さと色に変換され計算処理は非常に大きくなる．使用するデバイスの計算て描画される．周波数の高さ順と音声可視化オブジェク

能力によっては，レンダリングのカクつきが起こりQoE

トの棘の配置順を対応させて描画してみたところ，近接（Quality of Experience）の低下につながる可能性が高い．

する周波数グループ同士に相関があるために部分的に棘Web3602では，以下の3つの負荷軽減のための対策を導が盛り上がるような不格好な形状となったため，周波数入している．

の32グループと音声可視化オブジェクトの32本の棘の配置の対応関係はランダムに定まるようにした．また，

1. 音声可視化処理のFPS（Frames Per Second）の低減

OFF状態の音声可視化オブジェクトの棘の色はグレーでA-Frameコンポーネントのtickハンドラはデフォルト

あり，ON状態では平均値が大きくなるにつれて青，水色，

では毎秒60回から120回程度のオーダーで実行される

図10

Web3602の実装概要．

Web Audio APIを用いた処理（左点線枠）とA-Frameを用いた処理（右点線枠）を連携して実装している

82

が，音声可視化オブジェクトにおけるtickハンドラは断した．

毎秒20回程度のオーダーで実行されるように実行回数を低減している．様々なオーダーを試してみたが，音2. 死角にある棘状オブジェクトの非表示

声可視化オブジェクトが十分滑らかに更新されるため

音声可視化オブジェクトがもつ棘状オブジェクトは中には毎秒20回程度実行される必要があると主観的に判

心から全方位に均等配置で伸びているため，視聴位置

図11

視聴体験中のWeb3602のスクリーンショット．画面右側にコントロールパネルがあり，再生や一時停止，早送り，巻き戻しなどの基本操作ができる．ジャイロセンサ搭載デバイスでは，動作にあわせて視聴角度が変動する．音声は個別管理されていて，タップ（クリック）操作によってそれぞれ独立にON/OFFを切り替えることができる．視聴位置の変更操
作は実験的な機能である．

図12

Web3602のイベント選択画面のスクリーンショット．
イベントの情報は図13のSPARQLクエリによってRDFストアから動的に取得する．

図13

Web3602におけるイベント情報取得クエリ

83

の反対方向に伸びている棘は常に視聴者の死角にあすることでポリゴン構造を荒くすることができる．たる．死角にある棘状オブジェクトを図16のように非表

だし，あまりに構造が荒いとタップ（クリック）の反応

示にすることで，32本の棘のうちレンダリングすべき範囲に違和感が現れるため，A-Frameのa-sphereオブ

棘はおおよそ20本程度になり計算処理を軽減できる．

ジェクトのデフォルトセグメント数の半数に設定している．

3. 音声可視化オブジェクトの球体セグメント数の削減
音声可視化オブジェクトは中心に透明な球体をもち，映像と音声の同期処理

この球体にタップ（クリック）による音声のON/OFF切

映像・音声のメディアファイルはそれぞれ独立している

り替え操作を紐付けている．球体自体は透明であるた

ため同期をとりながら再生する必要がある．映像の再め球体に滑らかさは不要であり，セグメント数を削減

生 時 間 はJavaScriptのHTMLMediaElement.currentTime
プロパティによって取得・設定することができる．一方，音 声 に つ い て はWeb Audio APIに 読 み 取 り 専 用 のAudioContext.currentTimeプ ロ パ テ ィ が 用 意 さ れ て い
る が，こ れ は 音 声 の 再 生 時 間 で は な くWeb Audio のAudioContextが生成されてからの経過時間を示す．音声 が 停 止 中 で あ っ て もAudioContext.currentTimeプ
ロ パ テ ィ の 値 は 単 調 に 増 加 し 続 け る た め，シ ス テ ム
内 で は 音 声 の 再 生・停 止 を 管 理 す るWeb Audio APIの AudioBufferSourceNode.start() メ ソ ッ ド お よ び
AudioBufferSourceNode.stop()メソッドが呼び出される際にAudioContext.currentTimeプロパティの値を記録するなどして音声の再生時間を算出している．

図15

音声を可視化する処理．1）
周波数データを取得して有効周波数帯を更新する．2）有効周波数帯を可能な限り要素数が均等な32 グループに分けて，平均値を求める．
3）32個の平均値と音声可視化オブジェクトの棘を対応させてレンダリングする．以上，1）
から3）
までの手

図14

84

2

Web360 における視聴情報取得クエリ

順を毎秒20回程度のオーダーで繰り返しおこなう．

再生開始時やループ再生により先頭に戻った際には算視聴位置の移動

出された音声の再生時間をもとに映像の再生時間を強視聴位置の移動は実験段階のβ機能である．現行バー

制同期させる．また，視点を管理するA-Frameのカメラ

ジョンでは，再生中の視聴位置以外の360°動画は読みオブジェクトがもつtickハンドラによって毎秒60回か込まず，視聴位置移動の操作があってから動画の読み込

ら120回程度のオーダーで現在の音声の再生時間を算出

みが始まるためネットワーク環境に依存した遅延が起こ

し，映像の再生時間との差分を管理する．差分値に対しる．この問題はすべての視聴位置の動画を事前に読み込て閾値を設定し，閾値を超えたときに映像の再生時間をんでおくことで解決することができるが，視点位置の数

音声の再生時間に強制的に同期させる対応は可能ではに比例して通信量が大きくなってしまう．このように視あるが，同期処理が入るたびに映像再生の滑らかさが失点移動の滑らかさと通信量はトレードオフである．

われ，QoEを損なってしまう．そこで，現行バージョン
では差分の閾値を0.1秒として，閾値よりも映像が遅れ

音声可視化オブジェクトをはじめとする視聴オブジェク

たら映像の再生速度を2倍にし，閾値よりも映像が先行

トを正しい位置にレンダリングするために，映像・音声

したら映像の再生速度を0.5倍にすることで，映像と音の座標情報などを取得している．360°動画を内部に投声の再生時間のずれが徐々に閾値以内に収束するよう影するA-Frameのa-videosphereオブジェクトは常に視な比較的制約のゆるい同期をとっている．再生速度の変点を管理するカメラオブジェクトを中心とする性質があ

調は多少の違和感を生じてしまうが，映像再生の滑らかる．視聴位置の移動の実装の方法として2つの方針が考さを保つことができる．映像の再生速度はJavaScriptのえられる．

HTMLMediaElement.playbackRateプ ロ パ テ ィ に よ っ て設定する．ここで，映像と音声が，映像の速度変調による

1. カメラオブジェクトを映像の座標まで移動して，音ゆるい同期では時間を要するほど大きくずれてしまった

声可視化オブジェクトは取得した座標情報通り配置

場合，視聴者に与える違和感も大きくなってしまうため，する

やむを得ず映像の再生時間を音声の再生時間に強制的に同期させる．強制同期を発動する再生時間差分の閾値は

2. カメラオブジェクトを固定して，音声可視化オブジェ

1秒としている．

クトを映像の座標情報を原点とする相対座標で配置する
前者はカメラオブジェクトのみを移動すればよく単純
であるが，映像の位置情報だけでなく姿勢情報も含めてカメラオブジェクトに適用する必要がある．カメラオブジェクトの姿勢が過度に傾いている場合，ジャイロセン
サによる視聴角度操作が滑らかにおこなわれないことがあったため，Web3602では，カメラオブジェクトを固定する後者の音声可視化オブジェクトの相対座標配置を採

図16

死角にある棘状オブジェクトを非表示にする処理の概用している．

要．視聴位置から音声可視化オブジェクトの中心へと＊14

向かうベクトルを法線ベクトルとするような平面を音

3.2

LODチャレンジ

声可視化オブジェクトの中心から半径の半分だけ後方

LODチャレンジ*14はLOD（Linked Open Data）の普及促進に置く．棘状オブジェクトの根本がこの平面よりも後を目的に2011年から毎年開催されているイベントであ方にある場合，死角にあると判定して非表示にする．

る．LODチャレンジ2020ではアイデア部門，アプリケー

https://2020.lodc.jp/

85

ション部門，データセット部門，データ分析・可視化部

カメラを用い，撮影した場所をサービス上で三次元デー門，基盤技術部門の5つの部門について，2020年7月1日

タ，点群を作成できるクラウドサービスである．これをから10月18日まで作品募集しており，SDMコンソーシ

用い，東京大学工学部二号館，エービー白河事業所，またアムからはLODに興味・関心のある人々を中心に我々のNTTCOMスマートシティラボについて撮影を行った．

活動を周知してもらう目的で，アプリケーション部門に
Web3602，デ ー タ セ ッ ト 部 門 にSDM Ontology Version

4.1.1

2準拠のオープンデータを提出した．データセット部

Matterportを用い，東京大学工学部二号館のB1Fから13F

門へ提出したオープンデータについて，SDM Ontologyまでを撮影した．ただし，4F，10F以外の階では階段かVersion 2による記述の構造的正確さや表現力が評価さ

らエレベーターホールまでの短い区間のみを撮影した．

れ，最優秀賞およびスポンサー賞の受賞に至った（図17）．

4Fでは，それらに加えて講義室や実験室を撮影し，10F

図17

第４章

東京大学キャンパスマップ

授賞式の様子BIM共通基盤とアプリケーション

この章では，施設のBIM化のための初めの一歩として行っている，3Dモデルの作成について触れた後，作成した3Dモデルに付与するメタデータやそれらデータを外部から

図18

東京大学工学部二号館4F

図19

東京大学工学部二号館10F

参照するためのAPIについて活動報告を行う．最後に，共同研究先であるCIMXと共に製作している工場の可視化
ツールについて説明を行う．
4.1

3Dマップ作成

学内には各建物の図面があり，一意の共通IDで部屋を指定することができるが，混雑度の情報提示のみならずさまざまな建物の管理情報を一元的に管理できるBIM（Building Information Modeling）が望まれている．その一環として，コンピュータ上に現実と同じ建物と立体モデルを構築するための3次元マップを作成する．この節では，3Dモデルの作成について触れていく．三次元デー
タ作成にMatterport*15というクラウドサービスを使用
し て い る．Matterportは3Dス キ ャ ニ ン グ が 行 え，専 用

＊15

86

https://matterport.com/

では，研究室を撮影した．図18は，撮影を行った工学部が挙げられる．本節では，工場内の情報の可視化等に活二号館4Fのデータを，図19は，撮影を行った工学部二号用するため作成した3Dモデルについて説明する．撮影を館10Fのデータを上部から見た画像である．4Fの撮影に行なった場所はエービー白河事業所で，ここではプラス

は約5時間（撮影回数:350回），10Fの撮影には約2時間（撮

チック金型制作などが行われている．工場内には大型の

影回数:120回）かかった．撮影した講義室のデータの一部

機械などが多く，オクルージョンが多く発生したため，を図20に示す．このように，Matterportで生成できるファ撮影には多くの地点を要した．撮影に要した時間は4時間

イルは，簡単なメッシュデータとテキスチャデータであ半程で，139地点での撮影情報を用いた．に工場を上かる．これらの3Dモデルを用いて，3Dマップを構築してら見た画像を示す．また，工場内には環境センサやLidar

いく．撮影に使用したMatterportPro2というカメラでは，センサが複数箇所に設置されており，温度，湿度，照度，

一度に35mの範囲を撮影できるのだが，図18を見てもら

騒音や機械の電力といった情報を取得することが出来る．

えばわかるように，長距離の撮影であると，誤差が蓄積してしまい，図の上部と下部で閉ループが構築できない

4.1.3という問題が発生してしまっている．

東大グリーンICTプロジェクト（GUTP）*16にてディジタ

NTTCOMスマートシティラボのマップ

ルツインアプリケーション開発のためのワークフロー
4.1.2

エービー白河事業所マップ

BIMの活用分野の一つにファクトリーオートメーションの検討および実証実験が進められている．ディジタルツ
インアプリケーション開発の最初の段階として，今回NTTCOMスマートシティラボにて撮影を行なった．この撮影では，Matterport Pro2に加え，BLK360も用いられた．両者で撮影をしえられた点群の比較では，主に密度に差があり，物体の形状などはBLK360の方が精度が上であった．例えば，床に貼られたテープが，BLK360では一直線となっていたが，Matterport Pro2では途中で途切れるなどしていた．一方で，今回撮影を行なった規模

図20

図21

＊16

241講義室エービー白川事業所

図22

NTT Com実証実験ラボ

https://www.gutp.jp/

87

では，部屋全体の精度としてはそれほど大きな差は出な

い画像ファイルを生成する．最後にその画像ファイルをかった．今回の撮影に要した時間は1時間ほどで，撮影地

Base64形式でユーザに返却するといった構成になって点は48箇所であった．今後，この3Dモデルを用いてディいる．

ジタルツインアプリケーションの開発を進めていく．
4.3
4.2

3DマップAPIとオントロジ

Factory Automation関連アプリケーション

株式会社CIMXと共にFactory Automation（FA）について，

4.1.1にて作成した東京大学工学部2号館の3Dマップに建Matterportや各種センサを用いて行えることを模索して物情報などをメタデータとして付与し，外部から情報をいる．この節では，FAの初めの一歩として，現在作成し取得するAPIを作成した．

ている工場の可視化ツールについて説明していく．この可視化ツールでは，4.1.2で紹介したエービー白川事業所

4.2.1と提携しており，3Dモデルと機械や通路に設置したIoT

オントロジ

工 学 部2号 館 の 内 の 位 置 関 係 は，Building Topology

センサを利用している．

Ontology（BOT）[68]を用いて記述した．BOTは建物の構造情報を表すオントロジーであり，今回は主にキャンパ

4.3.1

ス，建物，フロア，部屋の位置関係を記述している．また，可視化ツールはUnityを用いて作成しており，図23に示し

各部屋に対して，部屋の名称，ID，glbファイルのパスをたUIを持つアプリケーションである．これは，鹿島建設

与えている．

株式会社が作成したリアルタイム現場管理システム「3D

工場可視化ツール*18
K-Field」
を参考にし作成しているが，これに加えてBIM

4.2.2のような詳細なメタ情報が含まれていない3Dモデルから

3DマップAPI

前節で記述したメタデータ及び部屋の画像を取得するこもこの可視化ツールを利用できる簡便なシステムを目指とのできるAPIをDocker内にFastAPIを用いて作成した．

している．工場では，いくつかの区画に分かれており，ここのAPIは，キャンパス内の混雑具合を表示するアプリのアプリケーションでは，Matterportを用いて作成したケーションのMOCHA*17などと連携することを想定して3Dモデルを与えられた空間情報に応じて，分割し表示すいる．3Dマップからの画像の取得はpythonを用いた手ることが出来る．そして，その3Dモデルの上に，Unity上法とUnityによる手法の2種類の手法を用いて実装を行で自動生成された各種センサを示すオブジェクト（図23

なった．Pythonを用いた実装では，VM上にXvfbによる上では，赤いオブジェクトで示されている）やLiDARセン

仮想ディスプレイを作成し，pygameを用いてobjファイ

サで取得した点群データ24を重ねて表示する．これに加ルを読み込み，指定された視点からの仮想ディスプレイ

えて，環境センサから取得した温度情報を利用して，温のキャプチャを行なっている．視点の向き，視点の位置，度ヒートマップを同空間上に描画すること（図26）や，同部屋はPOSTリクエストにより指定している．
Unityを用いた実装では，FastAPIを通したPOSTリクエス
トからUnityへアクセスする．POSTリクエストには，上部から撮影するか斜部から撮影するかといった情報やどの部屋を撮影するかといった情報を含んでいる．POST
リクエストを受け取った後は，Xvfbを用いて仮想ディ
スプレイを作成し，ビルド済みのUnityアプリケーショ
ンデータを用いて3Dモデルを配置し，キャプチャを行
図23

88

＊17

https://mocha.t.u-tokyo.ac.jp/＊18

https://www.kajima.co.jp/news/press/202010/28a1-j.htm

工場可視化ツールモデルの描画方法を変更し，空間上でのセンサデバイス

バージョンとセンサの種類，センサーのIDと取得時間（直の位置を見やすくしたワイヤーフレーム表示（図27）など

近，指定した30分間など）にて取得する情報を指定するが行えるようになっている．このような3Dでの描画のみことが出来る．アプリケーションでは，起動と同時にAPI

ならず，実際に工場内に設置された各種センサにアクセを使用するため，与えられたユーザでログインし，そのスし，温度，湿度，照度，騒音，電力，信号灯などと言っ後に各種センサ情報を取得し，アプリケーション終了時

たデータをリアルタイムに取得，表示することができるにログアウトする形で利用している．

（図25）．
4.3.2

REST API

この各種センサにアクセスするためのAPIは株式会社
CIMXが作成しており，REST APIの形式で構築されている．このAPIの一部を図28に示す．このAPIでは，APIの

図27

図24

点群データの可視化

図25

点群データの可視化

図26

温度ヒートマップの表示

図28

ワイヤーフレーム表示

工場可視化ツールREST API

89

4.3.3

利用方法

このアプリケーションは，WebGLやiOSなどと言ったス
マート端末向けにデプロイ可能となっており，ユーザが株式会社CIMXが用意したサーバにデプロイされたWeb
アプリやiPadなどを用いて閲覧することを想定している．このアプリケーションを用いて，工場内の情報を現
在の状態はもちろん，履歴から過去の情報を可視化する
ことや，温度ヒートマップやLiDARからの点群情報を用いて動的に変化するデータを3D空間上で閲覧することが
出来る．
4.3.4

今後について4.3.1で記述したように，詳細なメタ情報を含まない3Dモ
デルからもこのシステムを利用可能にすることを一つの目的としている．そのため，今回エービー事業所をモデルとしてこのツールを作成しているが，今後4.1.3で記述したNTTCOMスマートシティラボや美術館などといった様々な場所をモデルとして，このツールが転用可能であることを示していく予定である．

第５章

まとめ

本報告書では，2014年より開始したSDMコンソーシア
ムで進めて来た，視聴空間サービスのソフトウェア制御による研究で，2020年度に行なった活動について報告した．
SDMコンソーシアムでは，ソフトウェア処理による視聴空間の制御，映像音声を制御するネットワーク機器，インタラクティブ・ユーザインターフェイス，SDMプラットホームを利用したコンテンツ作成など，共同研究活動に参加するパートナーを募集しています．
ご協力をよろしくお願いいたします．

90