平成 25 年度
我が国経済社会の情報化・サービス化に係る基盤整備（ＣＧ・ＶＦＸ産業クラウド活用・高連携実証事業）
報

告書

平成 26 年 3 月

経済産業省

商務情報政策局

文化情報関連産業課

一般財団法人 デジタルコンテンツ協会

目
第1章

次

事業概要 ............................................................................................................. 1

1.1 本事業の目的 ........................................................................................................ 1
1.2 実施体制 ............................................................................................................... 2
1.2.1 実施体制 ......................................................................................................... 2
1.2.2 委員会 ............................................................................................................ 3
1.2.3

WG1 のメンバー ............................................................................................ 4

1.2.4

WG2 のメンバー ............................................................................................ 5

1.2.5

WG3 のメンバー ............................................................................................ 6

1.3 用語の説明............................................................................................................ 7
1.4 報告書の構成 ...................................................................................................... 10
1.4.1

2章

WG1：クラウド基盤を統合した商業映像制作プロジェクトの実施と実用性検証 ........................................................................................ 10
1.4.2

3章

WG2：クラウド運用でのデータ共有と効率的なプロジェクト

管理及びクラウドレンダリングの実証実験 ................................................. 11
1.4.3

4章

WG3：クラウドサービスを利用した CG データ共有化による

UGC サイクル活性化動向調査 .................................................................... 12
1.4.4

5章

まとめ ................................................................................................ 14

第 2 章 WG1：クラウド基盤を統合した商業映像制作プロジェクトの実施と実用性検証 .............................................................................................................. 15
2.1

WG1 の背景と目的 ............................................................................................. 15

2.2 アセットマネジメントとレンダリングのサービス手法 ...................................... 16
2.2.1 アセットマネジメントとは .......................................................................... 16
2.2.2 クラウドレンダリングの種類 ...................................................................... 18
2.3 実施概要 ............................................................................................................. 21
2.3.2 アセットマネジメントシステムを活用した制作プロダクションとクラウド間でのデータ同期.............................................................................. 21
2.3.3 クラウド上で行う CG・VFX 処理のテンプレート化とライブラリ化 ......... 22
2.4 検証環境の事前確認と検証内容 ......................................................................... 22
2.4.1 検証環境の事前確認 ..................................................................................... 22
2.4.2 検証の内容 ................................................................................................... 23
2.5 実証実験の内容 .................................................................................................. 23
2.5.1 システム構成 ............................................................................................... 24
2.5.2 スケジュール ............................................................................................... 27
2.5.3 環境構築 ....................................................................................................... 28
2.5.4 管理システムの紹介 ..................................................................................... 29
2.6 実証実験の結果 .................................................................................................. 36
2.6.1 検証結果 ....................................................................................................... 36
2.6.2 まとめ .......................................................................................................... 39

2.7 参加メンバーからのフィードバック .................................................................. 40
2.7.1

JCGS（システム開発会社）からのフィードバック .................................... 40

2.7.2 エヌ・デザイン（VFX 映像制作会社）からのフィードバック ................... 40
2.7.3 さくらインターネットからのフィードバック ............................................. 43
2.8 課題と提案.......................................................................................................... 45
2.8.1 課題 .............................................................................................................. 45
2.8.2 提案 .............................................................................................................. 49
第3章

WG2：クラウド運用でのデータ共有とクラウドレンダリングの実証実
験...................................................................................................................... 52

3.1

WG2 の目的........................................................................................................ 52

3.2 セキュリティ ...................................................................................................... 52
3.3 検証システムの全体像と構成要素 ...................................................................... 53
3.3.1 検証システムの全体像 ................................................................................. 53
3.3.2

VPN 回線 ..................................................................................................... 55

3.3.3 専用ネットワークソフト「Skeed 社 Silver Bullet」 .................................. 57
3.3.4 デジタル合成処理用アプリケーション「The Foundry 社 Nuke」 ............. 58
3.3.5 分散レンダリング ........................................................................................ 59
3.4 実証実験の結果について .................................................................................... 59
3.4.1

Silver Bullet によるデータ転送 ................................................................. 59

3.4.2

VPN 接続におけるデータ転送 ..................................................................... 60

3.4.3

VPN 接続での検証と結果 ............................................................................ 61

3.4.4

VPN を利用しない環境での検証と結果....................................................... 71

3.5 課題と提案.......................................................................................................... 74
3.5.1 課題 .............................................................................................................. 74
3.5.2 提案 .............................................................................................................. 77
3.6 操作マニュアル作成について ............................................................................. 78
第4章

WG3：クラウドサービスを利用した CG データ共有化による UGC サ
イクル活性化動向調査 ..................................................................................... 79

4.1 調査概要 ............................................................................................................. 79
4.2

WG3 の目的........................................................................................................ 79

4.3 調査内容 ............................................................................................................. 80
4.4 調査結果 ............................................................................................................. 80
4.4.1

3DCG データにおける著作権について ........................................................ 80

4.4.2

3DCG データのコンベンションについて .................................................... 84

4.4.3

Github によるデータ公開及び計測について ............................................... 87

4.4.4 データ公開に関するまとめ .......................................................................... 93
4.5 シンポジウム ...................................................................................................... 93
4.6 期待される効果 .................................................................................................. 95
4.7 今後の課題.......................................................................................................... 96
第5章

まとめ .............................................................................................................. 98

5.1 制作実証実験（WG1、WG2）のまとめ............................................................. 99
5.1.1 安定的かつ高速安価なネットワーク ............................................................ 99
5.1.2 セキュアなネットワークの確立と速度 ........................................................ 99
5.1.3 ファイル高速転送ソフトウェア等の有用性 ................................................. 99
5.1.4 確実なアセットマネジメントの重要性 ...................................................... 100
5.1.5 ソフトウェアのライセンス ........................................................................ 100
5.1.6 クラウドレンダリングの提供価格 ............................................................. 101
5.2 萌芽的な流通実証実験（WG3）のまとめ ........................................................ 102
5.2.1 著作権の設定 ............................................................................................. 102
5.2.2 データ利用者による著作権主張 ................................................................. 102
5.2.3 データの収集 ............................................................................................. 103
5.2.4 利活用システムの充実 ............................................................................... 103
5.3 総括 .................................................................................................................. 104【第 2 章参考資料】 ....................................................................................................... 105【資料 2-1】クラウドおよびレンダリングサービスの事例 ........................................ 105【資料 2-2】クラウドにおけるソフトウェアの使用許諾と最新のクラウド情報 ........ 106【第 3 章参考資料】 ....................................................................................................... 108【資料 3-1】Silver Bullet .......................................................................................... 108【資料 3-2】NUKE 分散レンダリング操作マニュアル .............................................. 118

第1章
1.1

事業概要

本事業の目的映画やテレビ番組、アニメなどに利用される VFX（映像視覚効果）や 3DCG などの制作には、コンピュータによる大量の描画処理が必要である。特に、近年は映像制作工程の急速なファイルベース化や映像の高精細化の流れが描画処理の増大に拍車を掛けている。
そのため、この分野で国際競争力を保持するには、データ処理能力を大幅に向上させるツールや設備、そしてこれらを使って効率的に作業を行うための基盤整備が必要なことは明らかである。しかしながらこの分野の国内企業の多くは中小企業であり、単独では必要十分な規模の機材投資ができていない。
また、他社と連携して事業を拡大展開するという前提での運営が進んでおらず、あくま
でも各社単独での取り組みの運営が多いため、企業間のノウハウやリソースを共有する仕組みがなく、それぞれは独自の高い技量を有するにも関わらず、横の連携をベースにした
制作フローの形成および規模の拡充が望めず、我が国の CG・VFX 産業の振興及びグローバル化推進の大きな障壁の一つとなっていると考えられる。
こうした課題を解決するには、この分野における共通基盤として、高性能のコンピュー
タや活用可能な素材を必要に応じて提供するクラウドサービスや、業界内の連携を進めるためのルール整備が有効である。
本事業では、実際の映像制作プロジェクトに、クラウドサービス及びそれに必要な制作工程に関するルールを適用した実証実験を行うことで、その実用性を検証することを目指した。また業務の中でクラウド活用がもたらす効率化、運営上の具体的な問題点、改善方法を明らかにすることを目的とした。

1

1.2
1.2.1

実施体制
実施体制

本事業の実施に当たり、学識経験者、CG・VFX 映像制作会社、アニメーション制作会
社、ポストプロダクションなど、CG・VFX 業界の各分野の有識者から構成する CG・VFX
共通基盤検討委員会を設置・開催した。また委員会の下部組織として、委員メンバーに当該分野の有識者を加えたワーキンググループを設置した。ワーキンググループとしては、「 WG1 ：クラウド基盤を統合した商業映像制作プロジェクトの実 施 と 実 用 性 検 証 」「WG2：クラウド運用でのデータ共有と効率的なプロジェクト管理及びクラウドレンダリ
ングの実証実験」「WG3：クラウドサービスを利用した CG データ共有化による UGC サ
イクル活性化動向調査」の 3 つの WG を設置・開催した。
委員会の委員以外にも CG・VFX 業界の興隆を支援する団体である「一般社団法人
VFX-JAPAN」や日本の映像産業の振興事業などを実施する団体である「一般社団法人日本コンテンツ振興機構」と連携して情報を共有することで、幅広く関係者から本事業に関する意見を集約できる体制とした。

図 1.2.1-01 実施体制図2

1.2.2

委員会

産学界の有識者からなる委員・オブザーバーで構成される「CG・VFX 共通基盤検討委
員会」を設置した。委員長には為ヶ谷秀一教授（女子美術大学大学院）、副委員長には三上浩司准教授（東京工科大学）が選出され、計 3 回の委員会を開催した。委員並びに事務局
は以下のとおり。
表 1.2.2-01 CG・VFX 共通基盤検討委員会 委員名簿

役割

氏名

会社/団体名委員長

為ヶ谷秀一

女子美術大学大学院

副委員長

三上浩司

東京工科大学委員

正富芳信

NTT コミュニケーションズ株式会社

委員

野﨑宏二

株式会社エヌ・デザイン

委員

三田邦彦

株式会社キュー・テック

委員

須藤武文

さくらインターネット株式会社

委員

鈴木勝

株式会社白組委員

野口光一

東映アニメーション株式会社

委員

根岸誠

東映ラボ・テック株式会社

委員

杉本健一

株式会社ドロイズ委員小山昌孝

一般社団法人日本コンテンツ振興機構

委員

痴山紘史

株式会社日本 CG サービス(JCGS)

委員

結城徹

一般社団法人 VFX-JAPAN

委員

今村理人

マーザ・アニメーションプラネット株式会社

委員

増尾隆幸

株式会社ルーデンス

オブザーバー

小松原繁

経済産業省

オブザーバー

中井健太

経済産業省

オブザーバー

小池正剛

株式会社エヌ・デザイン

オブザーバー

吉村富美嘉

The Foundry

オブザーバー

岩元浩志

The Foundry

オブザーバー

野口和紀

株式会社スタジオディーン

オブザーバー

新間敏雄

株式会社スタジオディーン

オブザーバー

北田能士

株式会社冬寂オブザーバー土田仁

東映ラボ・テック株式会社

事務局

加藤俊彦

一般財団法人デジタルコンテンツ協会

事務局

熊谷隆夫

一般財団法人デジタルコンテンツ協会

事務局

秋山貴彦

一般財団法人デジタルコンテンツ協会

事務局

須藤智明

一般財団法人デジタルコンテンツ協会

事務局

中村雅子

一般財団法人デジタルコンテンツ協会

31.2.3WG1 のメンバー

WG1 の座長には三上浩司准教授（東京工科大学）が選出され、計 4 回の会議を開催した。ワーキンググループメンバーは以下のとおり。
表 1.2.3-01 WG1 メンバー名簿

役割

氏名

会社/団体名座長

三上浩司

東京工科大学委員

小池正剛

株式会社エヌ・デザイン

委員

須藤武文

さくらインターネット株式会社

委員

鈴木勝

株式会社白組委員

痴山紘史

株式会社日本 CG サービス(JCGS)

オブザーバー

根岸誠

東映ラボ・テック株式会社

オブザーバー

今村理人

マーザ・アニメーションプラネット株式会社

オブザーバー

小松原繁

経済産業省

オブザーバー

中井健太

経済産業省

事務局

秋山貴彦

一般財団法人デジタルコンテンツ協会

事務局

須藤智明

一般財団法人デジタルコンテンツ協会

事務局

中村雅子

一般財団法人デジタルコンテンツ協会

41.2.4WG2 のメンバー

WG2 の座長には三上浩司准教授（東京工科大学）が選出され、計 5 回の会議を開催した。ワーキンググループメンバーは以下のとおり。
表 1.2.4-01 WG2 メンバー名簿

役割

氏名

会社/団体名座長

三上浩司

東京工科大学委員

根岸誠

東映ラボ・テック株式会社

委員

土田仁

東映ラボ・テック株式会社

委員

吉村富美嘉

The Foundry

委員

岩元浩志

The Foundry

オブザーバー

小松原繁

経済産業省

オブザーバー

中井健太

経済産業省

オブザーバー鈴木勝

株式会社白組

オブザーバー

今村理人

マーザ・アニメーションプラネット株式会社

事務局

秋山貴彦

一般財団法人デジタルコンテンツ協会

事務局

須藤智明

一般財団法人デジタルコンテンツ協会

事務局

中村雅子

一般財団法人デジタルコンテンツ協会

51.2.5WG3 のメンバー

WG3 の座長には三上浩司准教授（東京工科大学）が選出され、計 6 回の会議を開催した。ワーキンググループメンバーは以下のとおり。
表 1.2.5-01 WG3 メンバー名簿

役割

氏名

会社/団体名座長

三上浩司

東京工科大学委員

三田邦彦

株式会社キュー・テック

委員

須藤武文

さくらインターネット株式会社

委員

新間敏雄

株式会社スタジオディーン

委員

北田能士

株式会社冬寂委員小山昌孝

一般社団法人日本コンテンツ振興機構

委員

結城徹

一般社団法人 VFX-JAPAN

委員

今村理人

マーザ・アニメーションプラネット株式会社

委員

増尾隆幸

株式会社ルーデンス

オブザーバー鈴木勝

株式会社白組

オブザーバー

根岸誠

東映ラボ・テック株式会社

オブザーバー

小松原繁

経済産業省

オブザーバー

中井健太

経済産業省

事務局

秋山貴彦

一般財団法人デジタルコンテンツ協会

事務局

須藤智明

一般財団法人デジタルコンテンツ協会

事務局

中村雅子

一般財団法人デジタルコンテンツ協会

6

1.3

用語の説明

本報告書で使用する用語について説明する。なお、一部の用語について本事業の中で独自の呼び方をしているものは「※」を付けている。
表 1.3-01 用語一覧
DPX

Digital Picture eXchange（DPX）は、デジタルフィルム作業のためのファ
イルフォーマット。

EDL

編集データのリスト（Edit Decision List）。

Fusion-IO

Fusion-io 社のストレージの I/O（入出力）を高速化するストレージ技術。

Github

ISP

バージョン管理機能を持ったプログラムソフトウェア開発プロジェクトのための共有ウェブサービス。フォーク機能（公開されたデータを公開者以外の他者が改変し新たに Github 上に別のデータとして公開することができる機能）を持つことから、公開データのトレーサビリティが可能。
インターネットサービスプロバイダ（Internet Service Provider）。インタ
ーネット接続業者。

Render Spice

ネットワークレンダーノードの制御ソフトウェア。

STL ファイルフォーマット

3D system 社によって開発された三次元 CAD ソフト用のファイルフォーマット。
User Datagram Protocol（UDP）は、コネクションレス型のプロトコル。
TCP と比較して、信頼性が少ないが、高速に転送を行うことができる。

UDP
UGC
UGC サイクル
VPN

WebGL
アーカイブ
アーティストアセット
アセットマネジメント
アセットマネジメント
システム（AMS）
アプリケーションソフ
トウェア
インスタンス※
仮想化

ユーザーによって制作されたコンテンツ（User Generated Content）。
UGC 活動によって生み出されたコンテンツの循環過程。
バーチャル プライベート ネットワーク（Virtual Private Network）。イン
ターネットのような一般公衆ネットワーク上に、プライベートネットワーク
を構築する技術。専用線よりコストを抑えてセキュリティを向上させることができる。
ウェブブラウザで 3 次元コンピュータグラフィックスを表示させるための技術。
過去に制作した作品の映像原版・素材・データを、後世に残し再利用するために整理・保管すること。またはそのようにして保管されたもの。
映像作家のこと。映画監督、CM ディレクター、CG クリエイターなど映像制作に従事するもの。日本ではデザイナー、クリエイターと呼ぶこともある
が、欧米ではアーティストことが多い。
CG 等の映像制作における、その構成要素となるモデルデータやテクスチャ
データといった素材やリソースのこと。
映像制作に必要な素材やリソースを管理すること。アセットは一つでも欠けると正常にデータを再現することができなくなってしまうので、データ処理単位で厳密にパッケージとして管理を行う必要がある。
アセットマネジメントを行うシステム。アセットマネジメントシステムを導入することでクラウドレンダリングを利用する際に効率の良いデータの転送を行うことが可能になる。
コンピュータを利用する直接の目的となるソフトウェア。単にアプリケーシ
ョンともいう。
アプリケーションを実行できる仮想サーバ。
ハードウェアの物理的構成を抽象化して分割したり統合したりすることにより、1 台のコンピュータを複数台のコンピュータのように扱ったり、複数台のコンピュータを 1 台のコンピュータのように扱えるようにすること。

7

クラウド基盤を統合したシステム※
クラウドレンダリング※
クリエイティブ・コモ
ンズ・ライセンス
コンベンション※サービス利用型のクラウドレンダリング※

サンプルデータ
シェーディング
実データ※

システム構築型のクラウドレンダリング※シーンファイル
スケールアウトシステムソフトウェア
スタンドアロンレンダ
ラソフトウェアツールソフトウェアまたはユーティリティソ
フトウェア
ディレクトリストラクチャ

CG・VFX 映像制作ワークフローにおける、レンダリングやアセットマネジ
メントなどの機能をクラウド上に持たせ、それらを統合的な基盤として活用するためのシステム。
ネットワークを介し、データセンターなどの設備を使ってレンダリングを実行すること。
著作権のある著作物の配布を許可するためのライセンスのひとつ。クリエイ
ティブ・コモンズ・ライセンスを提供している国際的非営利組織とそのプロ
ジェクトの総称のこと。
本事業において、CG 制作工程及びデータ共有化の効率化をはかるための規約及びルールを総称し「コンベンション」と呼んでいる。
クラウドレンダリングサービスの一形態で、事業者によって環境が構築されており、決められた手順を踏むことで手間をかけることなく簡単に処理を行うことができるようになっているシステム。反面、決められた方法・システ
ムしか使用することができないために、サービス利用者側のアセットマネジ
メントシステムとの連携やレンダリング以外の応用的な用途には対応できない。
プログラムやアプリケーションなどの動作確認を行うためのデータ。
3DCG モデルに陰影を付けること。
商用目的の作品制作プロジェクトで実際に使用されたデータ。
サービス利用者が目的に合致するように環境を構築することで利用するク
ラウドレンダリング。そのため利用者側にある程度の技術力を必要とするが、その分柔軟な利用が可能である。特に既に稼働しているサービス利用者
側のシステムとの連携が可能で、アセットマネジメント、プロジェクト管理、
レンダリング以外の特殊用途への転用、レンダリングプロセスのカスタマイズなどを行うことができることが大きなメリットである。
オブジェクトやカメラや光源など一つのシーンを構成するのに必要なファイル。
サーバの数を増やすことで、サーバ全体のパフォーマンスを向上させること。
コンピュータのハードウェアの制御を行うソフトウェア。
3DCG 統合ソフトウェアを必要とせず、独立して動作するレンダリングソフ
トウェアのこと。
ハードウェア上で動作するプログラム。システムソフトウェア、アプリケー
ションソフトウェア、ツールソフトウェアの総称。
補助的に様々な機能を提供するソフトウェア。単にツール、ユーティリティともいう。
ファイルを整理・管理するための、階層構造。

データセンター※

インターネット用のサーバやデータ通信などの装置を設置・運用することに特化した施設。この報告書ではクラウドレンダリングを実施する場をデータセンターと表記している。

ネーミングコンベンシ
ョン※

コンベンションの内、ファイル名、オブジェクト名等の命名規則を指すもの。

ハッシュ値

ファイルベース・ワー
クフロー

データの受け渡しなどの際に、そのデータが改変されていないか確認するために使われる技術。元のデータからハッシュ関数と呼ばれる手法を使って、ハッシュ値と呼ばれるデータを作り、それを比較することで改変がないか確認している。データの容量に関わらずハッシュ値の比較だけで同一性を判定するため、判定に要する時間が少なくて済む。
主に編集などのポストプロダクション工程において、ビデオテープを使わないコンピュータ処理によるワークフローのあり方を指して使われており、「テープレス・ワークフロー」とも呼ばれる。また、一般的にデータだけですべての業務を完結させようという考え方は「データ・セントリック・ワー
クフロー」と呼ばれる。

8

プリレンダリング CG

事前にレンダリングされた CG。リアルタイムレンダリング CG に比較し、高画質な映像表現が可能。

ライセンスサーバ

アプリケーションソフトの使用許諾やライセンスを管理するサーバ。

リアルタイムレンダリ
ング CG
リグ
レポジトリ
レンダーファーム

レンダリングレンダリングサービス
レンダリングノード
ワークフロー

制作管理システム

リアルタイムにレンダリングを行い制作される CG。インタラクティブな映像表現ではリアルタイムのレンダリング処理が必須になる。プリレンダリン
グ CG よりも表現できる画質は劣ることが多い。
CG 制作における 3D モデルデータをアニメーションするための設定。
ソースコードや設計、データの仕様といった情報が保管されているデータベースのこと。
CG をレンダリングする目的で構築されたクラスタリング（複数のコンピュータを 1 つのコンピュータのように利用できるように結合すること）されたコンピュータのこと。
コンピュータのプログラムなどを用いて、画像を生成し表示させる描画処理のこと。特に 3D 形状のモデルデータやテクスチャデータ等に基づく演算によるもの。
レンダリング作業を請け負うサービス事業。
レンダリングシステムを構成する端末のこと。
コンテンツ制作における制作手順（フロー）を示す工程（ワーク）の遷移図
で、単にフローと呼ばれることもある。多くの工程（段階）を経て制作されるコンテンツでは、必ずワークフローが存在する。
制作のスケジュールや進捗状況、業務のアサインやスタッフの勤怠を管理するシステム。素材の閲覧なども可能であり、完成した作業の確認にも用いることができる。

9報告書の構成1.4

WG1：クラウド基盤を統合した商業映像制作プロジェク

本報告書は、次章以降「2 章トの実施と実用性検証」「3 章

WG2：クラウド運用でのデータ共有と効率的なプロジェク

ト管理及びクラウドレンダリングの実証実験」「4 章

WG3：クラウドサービスを利用した CG データ共有化による UGC サイクル活性化動向調査」「5 章まとめ」で構成されて

いる。

1.4.1

2 章 WG1：クラウド基盤を統合した商業映像制作プロジェクトの実施と実用性検証映像制作工程は大きく分けると、前半パートに 3DCG アプリケーションを用いた映像制作が行われ、後半パートに、撮影素材や CG 素材を使ったデジタル合成処理がなされる。
「2 章

WG1：クラウド基盤を統合した商業映像制作プロジェクトの実施と実用性検証」

では、特に前半パートに焦点を当て、株式会社白組が中心となって実施した、3DCG アプ
リケーションを利用した映像制作におけるレンダリングに関する実験について記述した。
昨年度実施した「平成 24 年度我が国情報経済社会における基盤整備事業(コンテンツ制
作基盤整備事業)」ではサンプルデータによる実験を行ったが、本事業ではより現実的な問題を抽出するため、アセットマネジメントシステムが導入された東京都内の VFX 映像制
作会社の株式会社エヌ・デザインと、北海道石狩市にデータセンターを保有する ISP であるさくらインターネット株式会社による協力の下、システム構築型のクラウドレンダリン
グ環境をベースに、実際の作品制作プロジェクトのデータを使用した検証を行った。
具体的には下記の検証を行った。
・ 制作プロダクション（東京都内）とデータセンター（北海道石狩市）とを結んで、ク
ラウドレンダリングの有効性の確認。
・ アセットマネジメントシステムを活用した制作プロダクションとデータセンター間でのデータ同期、およびクラウドレンダリングのための効率的データ転送の確認。
・ CG・VFX 処理のテンプレート化とライブラリ化。
実証実験の主な結果は以下の通り。
・ アセットマネジメントシステムを利用することで、修正が発生した際のデータ転送を必要最小限のデータで済ますことができ、効率的な運用が可能。
・ また複数のアーティストが同時に作業した際の整合性も保たれる。
・ 分散レンダリングのサーバの台数などの条件によってレンダリングに要する時間は左右されるものの、クラウドレンダリングの実用性が見えた。
・ 石狩と東京という離れた距離でもレンダリングを実行できた。
10

・ 定型業務の自動化や処理のテンプレート化をすることで、コンピュータに詳しくない
ユーザーでも簡単にクラウドを利用することができるようになる可能性がある。
また、こうした実証実験の結果から、「課金形態」「ソフトウェアライセンス」「インター
ネット回線」に関しての課題が明らかとなった。
そうした課題を解決するため以下の 3 つの提案がなされた。
・

クラウドレンダリング利用時の効率的データ転送の実現を視野に入れた業務の効率化を目的とした「アセットマネジメントの推進」

・

データセンターで必要とするソフトウェアやデータを最低限の構成にし、合わせてソフトウェアライセンス面での手続きを可能な限り簡略化するための、スタンドアロン
レンダラを中心とした「制作フローの抜本的な見直し」

・レンダリングコストを明確化し顧客に請求できるようにするための「レンダリングコ
ストの透明化」
短時間でより美しい映像を制作することが求められている中で、制作時間の短縮を実現するためには、レンダリングによる試行錯誤を繰り返すこと、シミュレーションなどで複数のバリエーションを同時に試すこと、そしてこれらの作業が自動化され、より良い結果が効率的に獲得できることの 3 点を改善することが必要となる。
「アセットマネジメント」
や「制作工程管理」などとの全体バランスも考慮しながら、3 年後、5 年後の制作フローがどうあるべきかを検討する良い時期と考えられる。

1.4.2

3 章 WG2：クラウド運用でのデータ共有と効率的なプロジェクト管理
及びクラウドレンダリングの実証実験「3 章

WG2：クラウド運用でのデータ共有と効率的なプロジェクト管理及びクラウド

レンダリングの実証実験」では、東映ラボ・テック株式会社が中心となり、後半パートに位置づけられる「デジタル合成処理」をクラウド上で実現するための道筋を明らかにすることを目的として実証実験を実施した。
特にここではセキュリティに注目し、東映アニメーション株式会社および株式会社 4D
ブレインの 2 社の協力の下、VPN 環境と、VPN ではない環境とを準備し、下記の検証を行った。
・ VPN でない環境ではデータの暗号化処理が必須となるため、専用のネットワークソフト（Skeed 社 Silver Bullet）を使用した高速なデータ転送。
・ インターネット回線による拠点間 VPN 接続環境における高速なデータ転送。
・ クラウドレンダリングに必要な環境構築と進捗管理ツール Hiero による進捗管理の可視化。
11

実証実験の主な結果は以下の通り。
・ 専用ネットワークソフトを利用することにより、簡単な操作でデータを転送することができ、レジューム機能によってデータ転送の中断などにも対応できた。今回利用したソネット株式会社が提供する光ファイバー回線 NURO 1Gbps ベストエフォートは、今回のテスト結果を見る限り映像データの転送には適していると考えられる。
・ 今回の実験用に設置した VPN 回線は当初想定していたほどのスピードが出なかった。
・ VPN 接続を利用してデータセンターから直接ローカルのデータサーバにアクセスしながら 20 台で分散レンダリングを行った場合、ローカル 1 台でのレンダリングと比較して、約 3 倍の処理スピードとなった。
・ データセンターにデータを転送してから 20 台で分散レンダリングを行った場合、同様の比較で 10 倍以上の処理スピードが出た。
・ Hiero によるプロジェクトは問題なく作成／保存できることが確認されたが、クラウ
ド上からの読み込み再生は確認出来なかった。
実証実験の結果を通して、「通信回線」「使いやすさ」「VPN 環境」「ライセンス契約」「データセンターの利用費用」に関しての課題が明らかとなった。
そうした課題を解決しユーザーにとって利用しやすいクラウド環境を構築して行くために、クラウドレンダリングサービス提供者や、ソフトウェアメーカーに対して「ユーザーサポート環境の構築」、「利用価格の明示」、「時間と費用のシミュレータの構築」、「マニュアルの整備」「レンダリングライセンス契約」等に関する提案がなされた。

1.4.3

4 章 WG3：クラウドサービスを利用した CG データ共有化による UGC
サイクル活性化動向調査「4 章

WG3：クラウドサービスを利用した CG データ共有化による UGC サイクル活性化動向調査」では、マーザ・アニメーションプラネット株式会社が中心となり、3DCG
データ資産の共有化と蓄積化に必要となる、コンベンション（ルール）の統一化に関する調査、3DCG データの著作権調査、著作権の利益を放棄することが可能な 3DCG モデルデータの収集、WEB 上でのデータ公開活動の調査を行った。
WEB 上でデータを公開するに当たっては、利用時のルールの明瞭性、及び利便性を重視し、クリエイティブ・コモンズ・ライセンスの採用を行った。
現在、3DCG データについての明確な著作権が規定されておらず、特に制作過程における中間生成物については、権利の取り扱いに各社で大きなばらつきがある。今後、各制作
プロダクションが生成した CG データ、またはその中間生成物を資産として活用するためには、より明確な著作権の定義が必要になってくるものと考えられる。

12

今後、CG データのオープン化にかかわる活動が発展することにより、以下の 4 つの効果が期待される。
CG データ生産効率の向上①

統一ルールを用いて CG データを一元ライブラリ化することで、一定の生産性の向上を図ることが期待できる。
CG データの資産化②

制作プロダクション等が自ら制作したデータを活用することによる新たなビジネスモデ
ルが期待できる。
CG 制作者の人材育成③

CG データが気軽に扱えると認知され、産学間による協業が行われることによる教育の品質向上が期待できる。
CG データ需要の拡大④

CG データの利用価値が業界外にも認知され活用範囲が広がることにより、CG データ制
作の需要そのものが向上することが期待できる。
上記の期待される効果を実現するためには、以下の 4 つの課題に継続的に取り組む活動が必要であると考える。
①

著作権定義の活動の継続
今後も著作権の定義について、具体的な事例を元とした議論をすることが重要である。
共有化 3DCG データの収集活動の継続②

高品質なモーションキャプチャーデータや汎用性の高い中間生成物などの 3DCG デー
タを収集することが必要となる。
3DCG モデルデータのコンベンションの定義拡大③

リグやアニメーションなどのコンベンション定義が必要となる。
④

将来的なデータベースの構築検討（インフラの構築）
3DCG データを蓄積するため特化したデータベースプラットフォームが必要となる。
CG データの利用範囲が、従来の映像業界やゲーム業界などからさらに広がりを見せ、CG データそのものに対する注目が高まっている。この機会を生かし、他産業で CG デー
タを活用してもらうためには、業界関係者が協力し、他産業でも利用しやすいように、
3DCG データのコンベンションを定義し、利用ルールを整備することが重要であると考える。
一方、今まで利用価値が認められて来なかった、CG データ制作過程で生まれる中間生成物についても、明確な著作権定義を行い、利用ルールを整備することにより、再利用可
能なデータへと変換し得る。その結果、中間生成物に新たな価値が生まれ、CG 制作者にとって新たなビジネスモデルの創出につながると考えられる。

13

1.4.4

5章

「5 章

まとめ

まとめ」では WG1、WG2 の実証実験を制作実証実験として取りまとめ、WG3を萌芽的な流通実証実験としてまとめた。
本事業では、実際の制作現場においてクラウドサービスを利用する際の効果測定をすることができた。特に転送速度の比較や、クラウドサービスやネットワークレンダリングサ
ービスと自社でレンダリングシステムを運用する場合の比較は、様々な制作プロダクショ
ンにおいて、サービス選択の指標になり得る有益なものである。
制作プロダクションにとっては、レンダリングサービスやクラウドサービスがインター
ネット回線の速度と料金等の条件を満たすのであれば、物理的な距離は大きな問題にはならない。高品質なインターネット環境の低価格での利用は今後も重要な要因となり得る。
クラウドサービスに関しては、ソフトウェアの対応状況に左右される点が多く残されており、柔軟なレンダリングサービスへのソフトウェア提供の仕組みが重要視される。
CG・VFX 関連ソフトウェアのクラウド対応やそれを応用したクラウドサービスとしての展開は、UGC なども含めた産業界全体の活性化につながっていくと考えられる。
プロフェッショナルや一般利用を含めたクラウドサービスの利活用は今後も加速するものと考えられる。そのための環境の整備に関する調査を実施し、課題に対応する必要がある。

14

第 2 章 WG1：クラウド基盤を統合した商業映像制作プロジェクトの実施と実用性検証
2.1

WG1 の背景と目的

CG・VFX の領域では、例えば爆発や水のシミュレーションなど高度で複雑な物理計算を前提にした CG に見られるように、高い品質の映像表現が求められるようになってきている。また近年ではデジタルシネマの普及や、TV 放送においても 4K 映像さらには 8K 映像の開発など、映像の高解像度化が進んでいる。さらにフレームレート（1 秒あたりの映像の枚数）も 2 倍、4 倍になるなど、映像を構成するデジタルデータの量は増加の傾向にある。こうした背景から、レンダリングで必要となる計算処理の量も増加の一途をたどっている。
一方でスマートフォン、タブレットなどの小型デバイスの市場も拡大しており、そうしたデバイスに向けた様々な仕様の映像コンテンツ制作の需要も増加している。個々のレンダリング処理の量は少ないが、デバイスの多様化に対応することも今後の CG・VFX の課題である。
このような映像データの増加と映像ニーズの多様化により、映像制作のためのレンダリ
ングサーバの設備増強が必要となるが、以下のような要因から設備投資のための経営判断が難しくなっている。


需要の最大値を見込んだ設備投資が必要になるが、案件の受注時期と規模の変動により必ずしも一定水準以上の稼働率を維持できず、投資効果の予測が困難である。

コンピュータ本体以外にも「ソフトウェア費用」「電気代」「場所代」「空調費用」「管理スタッフ費用」などの付随経費が発生する。



制作プロダクションにおけるコンピュータの実際の耐用年数は、技術進歩の観点から
4 年が限界といわれており、会計上の耐用年数と異なるため設備投資計画の際に注意を要する。
一方、短期的な需要に対応する手法としてはコンピュータのリースという選択肢もあるが、付随経費の発生や、機器のセットアップの手間などは設備投資との差異はなく、むしろ一時的に場所や電源を確保することが障害となることも少なくない。
以上のことから、自社に設備を持たずに必要なときに必要な分だけレンダリングサーバとソフトウェアを利用できるクラウドサービスの活用は費用面で有益であると考えられる。
またデータセンターには様々な利用者に向けた運用を通してクラウドサービスとしてのノ
ウハウが蓄積されることになり、それらがサービスを利用する各企業に水平展開される点も業界全体としての生産性向上という観点から期待できる。
本事業では CG・VFX の映像制作工程を CG 映像制作とデジタル合成処理の 2 つのパートに分けて検証を進めた。WG1 は、その前半パートにあたる 3DCG 映像制作で期待され15ているクラウドレンダリングサービスについて、実際に運用するには具体的にどのような課題が存在し、それらをどう克服すべきかを明らかにすることを目的としている。そのためアセットマネジメントシステムを運用している VFX 映像制作会社（株式会社エヌ・デ
ザイン）と ISP（さくらインターネット株式会社）の協力のもと、実際の制作状況を踏まえた、より現実的な検証を行うために以下の要素を考慮したアセットマネジメントとクラウド基盤を統合したシステムにおけるクラウドレンダリングの有用性を検証する実証実験を実施した。
①

実際の商業映像制作プロジェクトを検証の対象にすること②

アセットマネジメントシステムとの連動③

遠距離環境での検証

2.2

アセットマネジメントとレンダリングのサービス手法

2.2.1

アセットマネジメントとはデータを適切に管理するためにはアセットマネジメントシステムを構築し、認証されたデータは必ずデータベースに登録してトラッキングを可能にする必要がある。
下図に管理されたアセットの例を示す。rev.001、rev002、・・・rev010 とリビジョンが上がっていくとそれぞれのリビジョンに対応したディレクトリが作成され、そのディレクトリを開くとその中に必要なファイルがすべて格納される。そのため、rev010 内には差分だけではなくすべてのデータが入っている。
このようにアセットは更新履歴を保持し、関連するファイルはすべて一つのディレクト
リ下に格納されるようになっている。そのため、ある時点で作成されたアセットの状態が常に保持されていることが保障される。

図 2.2.1-01 アセットマネジメント

16

(1)

アセットマネジメントシステムの重要性

アセットマネジメントシステムの導入により、以下のような効用が期待される。

(a) パッケージによる管理
アセットが常に「関連性を保持したデータのまとまり」としてパッケージで自動的に管理されるため、ユーザーはファイルの細かい構成や置き場所を意識することなく必要な作業に集中することができる。

(b) 修正作業の衝突の回避
複数の作業者が同じパスにあるファイルを同時に修正した場合、修正作業が衝突してしまい、最終的に残っているデータが正しいことを保証することができない。
特にクラウドレンダリングのようにデータの処理時間や転送時間が長くなる場合、特定のシーンをレンダリングしている間に関連するデータが修正されてしまうことで、レンダ
リング結果が変わってしまう場合もある。アセットマネジメントシステムでは、きめ細かいアクセス権の設定が可能なため、特定のシーンをレンダリングしている間に、一方で関連データが更新されてしまうといった弊害を防ぐことも可能となる。

(c) アセットの状態保持あるアセットの修正を行ったことで、そのアセットを使用している他のアセットが壊れてしまうという事態が起こった場合、影響が広範囲に及んでしまう可能性が高い。
長期にわたって稼働するプロジェクトでデータの不一致による事故を起こさないようにするためには、ある時点で作成したアセットが永続的にその時の状態が保持されていることが保障されていることが重要である。

(2)

拠点間転送システムとの連携

データが適切に管理され必要な情報を適宜引き出すことが可能になれば、複数拠点間で効率的なアセット共有が可能となる。
サービス利用型のクラウドレンダリングの場合、随時必要なファイルを収集・圧縮して転送し、転送終了後にレンダリングサービス側がファイルを解凍して処理を行うため、一部のデータを変更した場合でも、再度全データを転送する必要があり効率的でない。更新
されたファイルのみを抽出し手動で転送する方法もあるが、抽出忘れや間違ったファイル
転送などの人為的ミスが発生しやすい。
また、データの収集を行わずにサービス利用者側の環境と同等のディレクトリ構成をレンダリングサービス側に構築しディレクトリの同期を行う方法もある。ディレクトリ同期
ツールなどで更新されたファイルを限定して転送を行い効率化も図ることができるが、この手法は一人で全データを管理している場合のみに有効な手段であり、複数人の同時作業
17

によって様々なファイルが並行して更新されるチーム体制では、修正の衝突や相互参照するデータの不一致などの問題が多発するため適していない。
以上のことから、クラウドレンダリングを利用する場合、アセットマネジメントシステ
ムとの連携が重要な検証要素と捉えて取り組んだ。

2.2.2

クラウドレンダリングの種類

クラウドレンダリングには、大別するとサービス利用型のクラウドレンダリングとシス
テム構築型のクラウドレンダリングがある。その違いについて以下に解説する。なお、本年度の事業ではアセットマネジメントシステムとの連携を可能とするシステム構築型のク
ラウドレンダリングについての実験を実施した。

(1)

サービス形態毎の作業の流れ

サービス利用型のクラウドレンダリングはクラウドレンダリングサービスを提供する事業者によって環境が構築されており、決められた手順を踏むことで簡単に処理を行うことができるようになっている。反面、決められた方法・システムしか使用することができな
いために、サービス利用者側のアセットマネジメントシステムとの連携やレンダリング以外の応用的な用途には対応できない。
一方、システム構築型のクラウドレンダリングは、サービス利用者自身が一から環境を構築しなければいけないため、利用者側にある程度の技術力を必要とするが、その分融通が利く。特に既に稼働しているサービス利用者側のシステムとの連携が可能で、アセット
マネジメント、プロジェクト管理、レンダリング以外の特殊用途への転用、レンダリング
プロセスのカスタマイズなどを行うことができることが大きなメリットである。
以下では、手動、自動化の視点から両者を比較した。

図 2.2.2-01 手動と自動の表記

18

①

サービス利用型のクラウドレンダリング

図 2.2.2-02 サービス利用型のクラウドレンダリング

サービス利用型のクラウドレンダリングでは、レンダリングするための関連ファイルな
どがレンダリングサービスの環境に適合しているかを確認し、必要であればレンダリング
サービスに合うように書き換えることで計算を行っている。サービス利用者が提供されるサービスに合わせることで、単価としては安くできる部分があるが、繰り返しレンダリン
グを行って試す用途の場合、作業時間の負担が大きい。

②

システム構築型のクラウドレンダリング

図 2.2.2-03 システム構築型のクラウドレンダリング

システム構築型のクラウドレンダリングでは利用者側の環境に合わせてシステム全体を構築することが可能である。また、アセット単位で管理されることで試行錯誤による繰り返しレンダリングを行う際に必要な部分のみが更新されレンダリングできるため、アーテ
ィストの作業負担が少ない。

(2)

ファイルのアップロードによる違い①

サービス利用型のクラウドレンダリング
サービス利用型のクラウドレンダリングでは、下記の流れでファイルをアップロードした後にレンダリングを行う。

19

図 2.2.2-04 サービス利用型のクラウドレンダリングのファイル転送②

システム構築型のクラウドレンダリング
システム構築型のクラウドレンダリングでは、CG ソフトウェアからクラウドレンダリ

ング側を指定するだけで、サービス利用者側のレンダリングサーバと同様にクラウド側の台数を指定してレンダリングを自動的に行う。

図 2.2.2-05 システム構築型のクラウドレンダリングのファイル転送

アセットマネジメントシステムを導入することで、この一連の動作を自動化でき、シス
テム側で管理できるようになる。

(3)

システム構築型のクラウドレンダリングにおけるファイル転送以外の処理の自動化

システム構築型のクラウドレンダリングでは、ファイルの転送の自動化だけでなくレンダリングと関連した様々な処理の自動化も可能である。
例えば、全データを高速なストレージに保存する場合、ストレージ費用が高額になる。
そこで、アセットマネジメントシステムを活用して当面使用しないファイルを自動でより廉価な保存用ストレージに移すなどの応用が可能である。

20

レ ン ダリ ン グ

プ レ ビ ュ ー用の＞＞ムービー形式へ変換

よ り 低価格な
保管用スト レ ージに移動＞

次の処理用にスト レ ージ を 確保

.m o v.tif

ク ラ ウド 側

ク ラ ウド 側

メ イ ン フ ァ イ ルサーバ

メ イ ン フ ァ イ ルサーバ

.m a

.m a
.e x r.tif.e x r

図 2.2.2-06 システム構築型のクラウドレンダリングを活用したレンダリング以外の処理の例

2.3

実施概要

2.3.1

クラウドを利用した実用に耐える CG・VFX 制作環境の構築(1)

実データを使用した検証

昨年度実施した「平成 24 年度我が国情報経済社会における基盤整備事業(コンテンツ制
作基盤整備事業)」（以下「昨年度事業」）では主に設備の必要条件の抽出を行ったため、サンプルデータを利用した比較に留まったが、本年度は新たにアセットマネジメントの概念を導入し、データ転送量を減らすことによる効率的な運用を実現するという目標を踏まえて、実際の商業映像制作プロジェクトで利用されたデータを使用して検証を行った。

(2)

遠距離環境での検証

昨年度事業では、既存の回線を利用した東京都内での近距離でのテストを実施したが、本年度の実験では ISP が所有するデータセンター（北海道石狩市）と制作プロダクション（東京都内）を VPN によるインターネット回線で結んだ遠距離のクラウド環境を構築した上で検証を行った。

2.3.2

アセットマネジメントシステムを活用した制作プロダクションとクラウ
ド間でのデータ同期

クラウド上でレンダリング等の CG・VFX 処理を行うには必要なデータを過不足なく転送し、効率よくデータ処理する仕組みを構築することが重要である。
このような仕組みが無い場合、処理の度に膨大な容量のデータ収集を行った後に、ネッ21トワーク越しに転送を行うことになり、多くの時間と手間を要すこととなり、結果として全体の処理が低速になりクラウドサービスを利用するメリットが乏しくなる。
そのため WG1 では、効率よくデータ転送と処理を行うためのミドルウェアを利用し、この問題を解決するシステムの構築と実証実験を行った。

クラウド上で行う CG・VFX 処理のテンプレート化とライブラリ化

2.3.3

CG・VFX の制作工程では、データの収集、転送、レンダリング、ムービー化など複数の処理を連続して行うことが多々ある。特にクラウド上でレンダリングを行う際には、データの転送とレンダリングを自動化することで、業務の並列処理を推進し作業効率を高めることができる。こうした頻繁に行われる処理の集合をテンプレート化し、ライブラリとして再利用可能な形にすることは業務の効率化に大きく貢献する。これらのライブラリを、
CG・VFX 制作現場での今後の共通ルールとすべく検討を行った。

検証環境の事前確認と検証内容

2.4

検証は以下のフェーズに分けて行った。

2.4.1

検証環境の事前確認

検証を行うにあたり、実運用上の問題点を踏まえ、以下の事前確認を行った。
(1)

動作 OS の確認

レンダリングサーバの OS 環境として Microsoft Windows Server 2008 も検討したが、より新しい OS である Windows Server 2012 を選択した。検証用ファイルを使って、Windows Server 2012 上でレンダリングをし、エラーなくレンダリングされることを確認した。
(2)

データセンター環境の確認

レンダリングを行う前に、ISP の基準にしたがって動作検証を行い、ハードウェア、ソフトウェア、ネットワーク環境が正常であることを確認した。
(3)

インターネット回線品質の確認

ISP の所有するデータセンター(北海道石狩市)から東京都のインターネット相互接続点
までの回線品質を確認した。その先の制作プロダクション（東京都内）までの回線はベス
トエフォート回線のため、その都度速度が変化することも確認された。

22

2.4.2(1)

検証の内容

サービス利用者側とデータセンター側のレンダリングサーバの処理時間の比較

同一のシーンファイルのレンダリングを、サービス利用者側のレンダリングサーバとデータセンター上のレンダリングサーバで行い、それぞれ処理にかかった時間の比較を行った。
(2)

手動でのデータ転送

手動でデータ転送を行う場合、特定のシーンをレンダリングするために必要なデータを漏れなく抽出するのは非常に難しいため、アセットデータをすべて転送することとし、転送にかかった時間の計測を行った。
(3)

ツールを使用したデータ転送

レンダリングするシーンを決め、ツールを使用してシーンに関連する必要なアセットの抽出とアセットで使用されているファイルの抽出を行い、データ転送を行った。この時の時間と手動でデータを転送した際の時間との比較を行った。

2.5

実証実験の内容

下記のステップで実証実験を行った。

図 2.5-01 作業ステップ

23

2.5.1(1)

システム構成概要図（東京都内）（北海道石狩市）
図 2.5.1-01 概要図① アセットマネジメントシステム② VPN③ スケジューラ
④ 転送⑤ レンダリングサーバ⑥ ファイルサーバ

(2)

各構成詳細

(a) データセンターの場所
ISP が所有するデータセンター（北海道石狩市）に準備。

(b)

VPN 環境データセンター（北海道石狩市）と東京都大手町にあるインターネット相互接続点まで
は 1Gbps の VPN 環境で接続、インターネット相互接続点と制作プロダクション（東京都内）までは 1Gbps のベストエフォート型の回線で構築した。
24

(c) レンダリングサーバ環境
データセンター側のレンダリング環境として、下記の環境を用意した。
（搭載メモリはメ
モリ不足による不安定要素を除去するために 128GB 構成とした。）
サーバ台数： 4 台
CPU：Intel Xeon E5-2640 (2.50GHz, 6Core, TurboBoost 時 3.0GHz) x2

Memory：DDR3-1600 RDIMM 128GB（16GB x8 枚構成）

Network：

10GbE x2 & 1GbE x2

Storage：

4TB HDD x8 with RAID コントローラ

OS：

Microsoft Windows Server 2012

参考：Intel Xeon E5-2640 http://ark.intel.com/ja/products/64591/(d) ファイルサーバ環境
データセンター側の環境は、1 台をメインとして 2 台目はトラブル時のバックアップとして用意。また、ファイルサーバを Autodesk 製品のライセンスサーバとしても利用した（ライセンスサーバ機能は、ファイルサーバへの影響が少ないため兼用しても問題ないと判断した）。
サーバ台数： 2 台
CPU：Intel Xeon E5-2640 (2.50GHz, 6Core, TurboBoost 時 3.0GHz) x2

Memory：DDR3-1600 RDIMM 224GB（16GB x14 枚構成）

Network：

10GbE x2 & 1GbE x2

Storage：

512GB SSD x24 with RAID コントローラ

OS：

Microsoft Windows Server 2012

参考：Intel Xeon E5-2640 http://ark.intel.com/ja/products/64591/(e) ネットワーク環境
データセンター側の内部のネットワークに関しては、実運用の際の制作プロダクションの相互乗り入れを考慮して、すべてギガビット環境でファイルサーバとレンダリングサー
バを接続した。
スイッチ：

1/10GbE RJ45 ポート x48

VPN ルータ： YAMAHA RTX 1200
参考：YAMAHA RTX 1200 http://jp.yamaha.com/products/network/routers/rtx1200/

25

(f)

ソフトウェア① Autodesk Maya 2013
3D レンダリングソフトウェア（レンダラ）。
② Autodesk 3ds Max 2013
3D レンダリングソフトウェア（レンダラ）。
③ Autodesk Backburner
レンダラのジョブを管理するソフトウェア。
④ Thinkbox Deadline 6
レンダーファームを手軽に管理できるレンダリング管理ソフトウェア。
⑤ Chaos Software V-Ray for Maya
3D レンダリングソフトウェア（レンダラ）。
以上、①～⑤については、制作プロダクションの環境と合わせたバージョンをデータセ

ンター側のレンダリングサーバに用意した。
⑥ Asset Sync
JCGS が開発したツール。共有したいアセットを指定することでそのアセットに関連するデータやそのアセットで使用している他のアセットを抽出して、必要なファイルだけを効率的に転送する。
⑦ Render Heaven
JCGS が開発したツール。レンダリング環境の構築やインスタンス（アプリケーシ
ョンを実行できる仮想サーバ）の立ち上げなどを自動化する。

⑧ libScheduler
JCGS が開発したツール。アプリケーション間の違いを吸収し、同一のインターフェイスを用いてスケジューラにジョブを投入することを可能にする。

26

2.5.2

スケジュール

図 2.5.2-01 全体スケジュール(1)

タスク 1：全体(a) タスク 1-1：基本事項の確認
サーバの仕様および、VPN 環境の仕様を検討し決定を行った。
(b) タスク 1-2：検証用ライセンス取得
Autodesk 製品（Maya、3ds Max、Backburner）の検証用ライセンスの発行、および
その他検証に必要なライセンスをレンダリングマシンが取得できることを確認した。
(2)

タスク 2：データセンター（北海道石狩市）(a) タスク 2-1：サーバ準備
レンダリングサーバ 4 台、ファイルサーバ 2 台（うち 1 台は予備機）の設置、動作検証を行い、リモート操作ができる状態とした。
(b) タスク 2-2：VPN 接続確認
制作プロダクション側からリモート操作およびファイル転送できる状態を構築した。
(3)

タスク 3：JCGS（システム開発者）(a) タスク 3-1：JCGS ツール
データセンター側に JCGS ツール（Asset Sync）の実装、転送などの検証を行った。
27

(b) タスク 3-2：JCGS ツール
構築した環境で、転送からレンダリングまでの一貫した動作の検証を行った。
(4)

タスク 4：NDESGIN（エヌ・デザイン、VFX 映像制作会社）(a) タスク 4-1：レンダリング動作検証
動作検証として、データセンター側の環境における単体レンダリングの問題について確認を行った。
(b) タスク 4-2：比較データのアップロード
アセットを管理していない状態で、必要なデータをアップロードする場合を想定したデータの転送を行った。
(c) タスク 4-3：レンダリング検証
実際にレンダリングを行ってテストをした。

2.5.3
(1)

環境構築

データセンター側の構築

データセンター側で、サーバの基本的な動作確認（ハードウェア、OS、ストレージ、ネットワーク）を行った上で、各種ソフトウェア・ツールなどのインストールや、リモート操作ができるように準備を行った。

(2)

ネットワーク環境の構築（VPN 環境構築）

VPN ソフトウェアである SoftEther やハードウェアの VPN ルータなど様々な方法を検討した結果、制作プロダクション側の VPN ルータに合わせてデータセンター側も同じ
VPN ルータを用意して接続を行った（今回利用した VPN ルータの実測値上限は約130Mbps）。その他、相互の MTU（1 回の転送で送信できるデータの最大値）の値などを確認し、設定上の違いが無い様に確認を行った。

(3)

各種ライセンス取得の確認

Autodesk 社から、Maya、3ds Max、Backburner の検証用途の期間限定ライセンスを取得し、データセンター環境上での動作を確認した。その他の Deadline や V-Ray などのAutodesk 社以外のソフトウェアに関しては制作プロダクション側でライセンスを取得して動作の確認を行った。

28

2.5.4(1)

管理システムの紹介

アセットを共有するためのシステム(a) 概要
複数の拠点間でアセットを共有するためのシステムとして Asset Sync がある。Asset
Sync は、共有したいアセットを指定することでそのアセットに関連するデータやそのアセットで使用している他のアセットを抽出して、必要なファイルだけを効率的に転送するシ
ステムである。ファイルの転送も既に同じ内容のものが転送先（データセンター側）に存在すれば極力それを使用してデータの転送量を削減することが可能である。ファイル転送の必要性を判断するために複数の段階を持っているのが特徴である。

(b) 内部処理共有するために必要な手続きとして、Asset Sync 内で以下のような処理を行う。

①

必要なアセットの抽出転送に使用したいシーンから紐づいているアセットを抽出する。

図 2.5.4-01 必要なアセットの抽出②

アセット毎の比較抽出したアセットとデータセンターに転送済みのアセットを比較し、未転送のものを検

出する。

③

転送が必要なファイルの抽出・転送
アセットの中のファイルをさらに調べ、ファイル単位で既に転送済のものとそうでないものをより分け、足りないものだけを転送する。
29

図 2.5.4-02 データセンターにアセットを構築する

ファイルの同一性は、ハッシュ値を比較して判断する。ハッシュ値はファイルをデータベースに登録する際に計算され、アセットの一部を構築する。また、元のファイルが数百
MB のサイズがあったとしてもハッシュ値は数 KB しかないので、相手先にデータを送ったとしても大した負荷にならない。
ハッシュ値はデータセンターのデータベースにも登録され、リビジョン（改訂）やアセットをまたいだ検索を行うことができる。これにより、アセットが更新されて転送が必要になっても、変更されていないファイルは既に転送済のものを流用することができ、転送に必要なデータ量を大幅に軽減することができる。
現実問題としてアセットが更新される場合、更新されるデータは一部であり、ほとんどのデータは既存のものを使用することになるので、実際に転送が必要なのはアセット全体の一部であることが多い。そのため、一度アセットを転送してしまえば二度目以降は高速に転送を終了することができる。

30

rev001

rev002更新されたファイル追加されたファイル転送が必要なのはこの部分のみ

アセットは徐々に作られていくため、差分は全体に⽐べてごくわずか
図 2.5.4-03 アセットマネジメントにおけるファイル管理(2)

クラウド上にレンダリングシステムを構築するためのシステム(a) クラウド上のリソース管理の問題
システム構築型のクラウドレンダリングを利用してシステムを構築する場合、基本的にはすべて自前で構築する必要がある。
例として、以下のような作業が必要になる。
・ 仮想ネットワークの構築
・ サービス利用者側の環境との VPN 接続
・ ファイルサーバの起動
・ ジョブ管理システムの起動
・ レンダリングサーバの起動
・ 起動したインスタンスへの IP アドレスの割り振り(b) クラウドを利用するために必要な定型業務の自動化ツール
これらの作業をすべて手動で行おうとすると、システムの起動から使用可能な状態にするまでに、多くの手間がかかり、誰にでも手軽にすぐに利用できるということにはならない。
31

しかしレンダリング環境の構築やインスタンスの立ち上げなどは定型業務であり、ほぼ100% 自動化が可能である。そのためのツールとして Render Heaven があり、今回はこれを使用した。以下の図が Render Heaven の GUI である。
熟練した作業者が手動で 10 台のレンダーファームを構築する場合、通常 30 分から 1 時
間ほどかかるが、このツールを使うと熟練作業者でなくても 10 分程度の時間で数 10 台のレンダーファームを構築することができる。

図 2.5.4-04 Render Heaven

この GUI 上から以下のような一連の作業を行うことができる。
・ 仮想ネットワークの作成
・ インスタンスの立ちあげ・ IP アドレスの割り当て
・ レンダーマネージャの起動
・ レンダリングサーバの起動
(3)

ジョブ管理

(a) 概要クラウド上のレンダリングでは、以下のような手順で複雑な処理をまとめて行う。
基本的な一連の流れを以下に示す。
32

①

ユーザーがローカルのスケジューラにジョブを投入②

関連するアセットの情報を集めて、アセットを共有するためのシステムを用いてデー
タを同期③

リモートのスケジューラに対してジョブを投入④

リモートのスケジューラでレンダリング処理の管理⑤

シーンをレンダリング⑥

レンダリングしたシーンをローカルのサーバに転送
これらの処理を毎回手作業で行うことは煩雑で難しく、現実的ではない。そこでレンダ

リング時に必要な定型作業をテンプレート化し、ユーザーはテンプレートを選ぶだけで、その後は計算機が自動的に処理を行ってくれるような仕組みを構築することで作業負荷が大幅に軽減できる。そのためのベースになるライブラリが libScheduler である。

(b)libScheduler の紹介

図 2.5.4-05 libScheduler

ユーザーは Maya や After Effects などの CG ソフトウェアを使用してジョブを投入するが、その際あらかじめ用意されたテンプレートを切り換えることで、投入されるジョブに対して所定の目的の処理を行うことができるようになっている。
スケジューラが、投入されたジョブ内のタスクを各サーバに割り振る。スケジューラはいくつか製品があるが、そのひとつである libScheduler は製品間の違いを吸収し、同一のインターフェイスを用いてスケジューラにジョブを投入することを可能にする。

33

(c) ジョブとタスクとジョブテンプレートの関係
一つのジョブは複数のタスクから成り、タスクは相互に依存関係を持つことができる。
ジョブテンプレートは、一つ一つのタスクの内容と タスク間の依存関係の定義を行う。
実際に行われる処理の例としては、下図のようなものがある。

図 2.5.4-06 ジョブテンプレート例

なお、それぞれのタスクで使用されるアプリケーションやコマンド体系は異なる。

(d) ジョブテンプレート
ジョブテンプレートは、ジョブ定義テンプレートファイルと、ジョブパラメーターファ
イルから成り立つ。ジョブの定義をテンプレート化することで、複雑な処理を簡単にレンダーファームに任せることができるようになる上、テンプレートを資産として蓄積していくことができる。

①

ジョブ定義テンプレートファイル
ジョブの内容を定義するためにテンプレートファイルを用意する。
テンプレートファイルは XML で記述され、ジョブ内のタスク、タスク間の依存関係、ジョブ内で使用されるパラメーターの定義が行われる。

34

<?xml version="1.0" encoding="utf-8"?><jobTemplate><!-- ジョブの名称、説明（省略不可）--><jobHeader name="Job_001" description="Job template for single task" version="1.0" /><!-- タスクを定義（省略不可）--><tasks><!-- タスクで実行するアプリケーションを定義（複数指定可）--><task

name="backburner_job_001"

description="Backburner

Batch

Job

exec="metascheduler-fileio-noparam.bat" /></tasks><!-- ジョブ・パラメーターと型、対応するタスク・パラメーターを定義（省略可能）--><args /></jobTemplate>

図 2.5.4-07 ジョブ定義テンプレートファイル②

ジョブパラメーターファイル
ジョブパラメーターファイルは、実行時に使用されるパラメーターを定義する。

<?xml version="1.0" encoding="utf-8"?><jobParameter><!-- ジョブ・パラメーターと型、対応するタスク・パラメーターを定義（省略不可）--><args /></jobParameter>

図 2.5.4-08 ジョブパラメーターファイル

35

1"

2.6
2.6.1

実証実験の結果
検証結果

検証結果を以下に示す。

(1)

レンダリング時間の比較

同一のシーンファイルのデータ（150 フレーム）のレンダリングに要した時間は A、B、C の 3 つのケースでそれぞれ以下の結果となった。

図 2.6.1-01 利用者環境とデータセンター環境でのレンダリング時間の比較

本実験で利用したサービス利用者環境内のサーバと、データセンター環境内のサーバとの性能を比較すると、データセンター側のサーバ（B）は 91.4%の性能であった。
またデータセンターから、サービス利用者環境内のデータに直接アクセスしてレンダリングした場合（上記 C）、4 時間 30 分かかった。B との比較では約 40 分余計に時間を要したが、この時間はネットワークの状況に大いに左右されるため、処理完了時刻の予想がつかないという問題につながる。ネットワーク越しにローカル側のデータにアクセスする方法は、データ転送を不要にするが、その効果はネットワーク回線の実効速度に依存する。
次にレンダリングサーバ 1 台に対して複数のジョブを投入した際の処理性能比較を行った。
データセンター側のレンダリングサーバで、同じ内容のジョブ（150 フレームのレンダリング）を複数投入し、ジョブ毎の処理時間を計測した結果が以下である。

36

表 2.6.1-01 複数台、複数ジョブ投入時処理時間の結果
時間の単位は時：分 （3:14 は 3 時間 14 分）

ジョブ数と
サーバー

Job1

Job2

Job3

Job4

Job5

Job6

Job7

Job8

台数

平均

ジョブ

一台あたり

処理

あたり

のスルー

時間

性能比

プット比

3:14

100.00%100.00%

1Job/1 台

3:14

2Job/1 台

4:07

4:22

4:14

76.20%

152.50%2Job/2 台

3:17

3:19

3:18

98.00%

98.00%

4Job/4 台

3:25

3:23

3:27

3:28

3:25

94.30%

94.30%

8Job/4 台

4:14

4:14

4:17

4:29

4:22

73.90%

147.80%

4:31

4:29

4:23

4:23

並行して処理するジョブが増えた場合の処理時間の変化

時：分

1Job/1台

2Job/1台

2Job/2台

4Job/4台

8Job/4台

図 2.6.1-02 並行して処理するジョブが増えた場合の処理時間の変化

37

一台あたりのスループット比

1Job/1台

2Job/1台

2Job/2台

4Job/4台

8Job/4台

図 2.6.1-03 一台あたりのスループット比

レンダリングサーバ 1 台で 1 ジョブを計算する時間を 100%とすると、1 台で 2 ジョブを行った場合 1 ジョブあたりの性能比は 76.2%であるが、1 台で 2 ジョブ行うことにより1 台あたりのスループットは、152.5%になる。さらにレンダリングサーバを 4 台に拡大した状態で計測した結果、1 台あたりのスループット比は 147.8%であった。このことからレンダリングサーバの台数確保や、ネットワーク環境の条件が揃えば、効率的な計算パワーが期待できるため、クラウドレンダリングの活用メリットがより大きくなることが推察される。
(2)

手動でのデータ転送

転送実験で利用するデータを含む関連ファイル総容量 3TB のデータを転送した結果、データ転送だけで約 1 週間の時間を要した。加えて、ネットワーク回線の大きな負荷による通常業務への影響も明らかになった。制作プロダクションの通常業務時間帯での大量のデータ送信は、他の事業活動へ少なからぬ影響を及ぼすことを十分考慮しなければならない。
(3)

アセットマネジメントシステムを使用したデータの転送

アセットマネジメントシステムを利用した場合、転送対象であるショットシーンのデー
タサイズは 649MB で、転送時間は 17 分 42 秒であった。続いて、アセットマネジメン
トシステムを利用しない場合を想定し、ショット内で参照している 12 個すべてのアセッ
トデータ 4.7GB を転送したが、その転送時間は約 1 時間であった。

38

2.6.2(1)

まとめクラウドレンダリングとアセットマネジメントシステムの実用性

クラウドを利用した、実用に耐える CG・VFX 制作環境の構築実験では、ISP の所有するデータセンター(北海道石狩市)と制作プロダクション(東京都内)という離れた距離をVPN で接続して仮想的なクラウド環境を構築し、実データを使った CG・VFX 制作を実現した。
またアセットマネジメントシステムを利用することで、一度アセットを転送した後は、システムによって変更が発生したデータを自動的に判別し転送することが可能となるため、レンダリングに必要なデータ転送を効率的に行うことができた。アーティスト自身がデータを収集し転送を行い、その上でレンダリングを行う、という従来の段取りと比較すると、制作作業の省力化と効率化に大いに貢献することが確認された。
この仕組みを利用し、同時に数百台規模のレンダリングサーバに計算をさせることで、今まで実現できなかったような速さでレンダリングの結果を受け取ることも期待され、クラウドレンダリング導入による大きなメリットの可能性を見出せた。
(2)

クラウド上で行う処理のテンプレート化とライブラリ化

CG・VFX で頻繁に行われる処理のテンプレート化、ライブラリ化を推進することで、同様の処理を手軽に再現できることを確認し、将来 CG・VFX 制作現場での共通ルール化を可能とするための検討を行った。
クラウドを利用するために必要な設定作業や処理手順を効率化する方法として、クラウ
ド上での仮想ネットワークの構築、インスタンスの起動といった定型業務を自動化するツールの開発と整備が有効と考えられる。これらのツールによって作業者の負担軽減だけでなく作業を開始するまでの時間も短縮される。また、クラウド利用に際して特殊な技術習得が必要でなくなり、コンピュータに詳しくないアーティストや制作進行などの管理スタ
ッフでも簡単に使用できるようになる。また一度作成したテンプレートを資産として蓄積・活用し、テンプレートの充実を図ることで、単なるレンダリングに留まらない複雑な処理をサーバ上で行うことができるようになる可能性も示された。
こうした活用を可能にするのがシステム構築型のクラウドレンダリングのメリットであり、サービス利用型のクラウドレンダリングでは実現できない部分である。

39

参加メンバーからのフィードバック

2.7
2.7.1
(1)

JCGS（システム開発会社）からのフィードバック

システム化の重要性

今回の検証の結果、プロジェクトで作成しているアセットがきちんと管理され、データをやり取りする際のシステム化を行うことができれば、外部のデータセンターを使用した
レンダリング環境の構築は十分実用範囲にあると考えられる。
ただし、そこに至るためのハードルはやはり高く、まずはサービス利用者側のアセット
マネジメント環境を整備して必要な情報を必要な時に即座に抽出できるようにしておくことが望ましい。このような管理体制を構築しないまま、クラウドレンダリングを試みた場
合、せっかくの環境を十分に生かすことができず、本来必要ない手順を踏む必要が生じた
り、データ転送のコストが膨大になったりしてしまうことが懸念される。

(2)

システム構築の課題

システムを構築する側の課題としては、正常なデータを処理する際にスムーズな処理ができるようにすることはもちろん、システムが当初予想していなかったような状況下に陥った時にリカバリーできるような体制を如何に構築するかも考える必要がある。
また、プロジェクトが長期にわたる場合、プロジェクト開始時に使用していたツールのバージョンが変わったりアセットの仕様が変更されたりしてしまうことがある。そのような状況にも対応できるようにしなければ、いざという時にデータの転送ができないなどの事故が起きてしまう。特にクラウドレンダリングのようなシステムを使用する場合は、制作期間が十分にない場合が想定されるため、このような例外的な状況にも対応できるよう、
過度なブラックボックス化は避け、ポイントを押さえたシステム化をすることが必要とな
る。

2.7.2

エヌ・デザイン（VFX 映像制作会社）からのフィードバック

今回の実証実験において、ローカルのレンダリング環境と変わらない使い勝手と、十分なジョブの処理速度を確認することが出来た。
このため、クラウド上でのレンダリングは技術的には既に実用段階にあると考える。
今回の実験を踏まえ、クラウドの実用に際して使用者（VFX 映像制作会社）に必要なこと、クラウドサービスや回線の提供者にお願いしたいことを以下にまとめる。

(1)

使用者（VFX 映像制作会社）に必要なこと

効率化を図る上での重要な要素の 1 つにデータの転送時間がある。これは使用者／提供者間のネットワーク環境はもとより、使用者がアップロードするデータの物理的容量に大40きく左右されるため、如何に過不足の無い必要最小限のデータにまとめるかが鍵となる。
その実現において必須となるのがサービス利用者側のアセットマネジメントであり、仮にアセットマネジメントが出来ていない場合には全プロジェクトデータをアップロードする必要が生じ、これには非現実的な時間を要すこととなる。アセットマネジメントさえしていれば、サービス利用者側のネットワークとクラウド間でのデータ同期が容易となり、クラウド利用の大きな恩恵を受けることができる。
以上から、使用者が最初に着手すべきはサービス利用者側のアセットマネジメントの徹底であると言える。

(2)

クラウド提供者にお願いしたいこと①

セキュリティ
映像制作会社は公開前の作品や重要な企業情報を取り扱っている。受注／委託を問わず扱う案件の機密性は非常に高く、クライアントとの機密保持契約の内容も非常に厳しいものとなっている。
そのためクラウド利用に際しては情報セキュリティ対策が絶対条件となり、暗号化技術による保護はもちろん、クラウドサービス提供者のデータセンター内の入退室管理、機器の廃棄時における確実なデータ抹消など、ソフト、ハード両面での機密保持対策が求めら
れる。

②

契約書
諸問題が起きた際の対処、役割と責任の明確化、機密保持、紛争の解決方法などを含む

詳細な取り決めを規定した契約書の存在が、クラウドサービスのスムーズな利用に繋がる
と考える。

③

コスト
レンダリングサービス事業においては、データセンターへアップロードするデータ容量は膨大だが、ダウンロードする容量は少ない。計算ノードに対する負荷は高く、数 10～
100GB クラスのメモリが必要ではあるが、反面ディスクのスピードや容量はほとんど要求されず、冗長性も不要である。処理の並列性も極めて高いため、これらの特性を最大限に生かした事業者視点での廉価なプランの提案を望む。

④

安定性
クラウド上のすべての機器が常時正常稼働する状況が理想であるが、CG などの映像制

作の現場にとっては、100%の安定性を保証した高額なサービスよりも、安定性はそこまで高くなくとも、利用料が比較的安価なサービスが求められる場合も多いと考えられる。

41

⑤

使いやすさ
映像制作会社においては専門技術スタッフを抱える企業は少数なのが実情である。技術者が不在でも、容易に取り扱える、レンダーファームに特化した導入パッケージの商品化の検討もお願いしたい。

(3) インターネット回線提供者にお願いしたいこと①

安定性
企業製品を扱う上では、たとえ一時的に遅くなったとしても回線が切断されないことが重要である。回線の断絶はクラウドファームの全停止を意味し、断絶の際も 1 時間以内の復旧が望ましい。

②

アップロード容量無制限
映像制作会社の扱うデータ量は 1 案件につき数テラ〜数 100 テラバイトになり、クラウ

ド利用ではこれら膨大なデータをアップロードする必要がある。そのため、アップロード
容量は実質無制限である必要がある。逆にダウンロードする量は少ない。
通常の家庭用回線とは特性が逆となっていることに注目されたい。

③

レイテンシ向上
前述の通り膨大なデータ量を扱うため、回線遅延（レイテンシ）が大きいと TCP の特性により理論帯域と実効帯域の解離が大きくなってしまう問題が顕著に現れてしまう。レ
イテンシの削減、または UDP ベースの転送を考える必要がある。

(3)

レンダリング管理システムにお願いしたいこと①

負荷に応じた起動ノード数の自動スケールアウト
自動スケールアウトが出来ないとコスト削減が見込めない。また、コストをかけてでも速く処理する必要がある場合には人的監視の必要があり、低効率で管理工数もかかってしまう。クラウドのメリットを上げるためにも自動スケールアウトは大切である。

②

簡単セッティング
前述の通り、専従の情報技術者が常駐している映像制作会社はわずかであるため、「容易な導入方法」は使用者には大きなメリットである。

③

プロジェクト毎の課金情報の提供
CG 業界において、これまでレンダリングコストというものは明確に数値化されておら42

ず、その結果「持ち出し」の状況が続いているため、プロジェクトごとにかかったレンダ
リング費用を算出する機能があると望ましい。
この機能により、適正な価格請求ができ、今後の成果物の質の向上、ひいては業界の活性化にも繋がると考えられる。

2.7.3

さくらインターネットからのフィードバック

以下に、今回の実証実験を踏まえ、さくらインターネットが CG・VFX 制作に向けたサービス提供に当たって取り組まなければならない課題について述べる。

(1)

セキュリティの確保

これまで述べられたように、CG・VFX の制作において情報漏洩は致命的なリスクとなり得るため、ISP はその責任範囲内においてそれを防ぐ仕組みが必要である。
さくらインターネットを含む ISP にとって、ユーザーの個人情報の保護を始めとするセキュリティの確保は必須の取り組みである。セキュリティに関する事故が社会問題につながった事例もあり、ISP に対するセキュリティ強化の要請は強まる傾向にある。
しかしながら、すべてのユーザーが最高のセキュリティを必要とするとは限らない。高いセキュリティを実現するためのコストを、それを必要としないユーザーにまで負担させては、適切なコストパフォーマンスを実現出来ない恐れがある。
そのため、高度なセキュリティはそれを必要とするユーザーが任意に選択できるものとし、それを必要としないユーザーには一定のセキュリティにとどめることが可能といった選択肢を提供することが重要となる。
その上で課題となるのが「情報の開示」と「適切なセキュリティレベルの設定」である。
前者については、ISP がどのようなセキュリティ確保の取り組みを行っているか（あるいはどこからがユーザーの責任範囲となるのか）について可能な限り情報を提供し、ユーザーが適切な判断を下すための支援を行う必要がある。後者については、今回の実証実験におけるセキュリティ確保の取り組みについて点検すると同時に、ユーザー意図の汲み取りを行い、ユーザーが必要十分とするセキュリティとはどのようなものか、品質とコストの両面から十分な検討を行う必要がある。

(2)

サポート体制

一度 ISP 側に構築したレンダーファームは、その特性上、別の ISP に移動させることが容易ではない。そのため、ISP 側の原因でレンダーファームに何らかの不具合が発生した
場合、ユーザーは別の ISP へレンダーファームを移動させることではなく、極力現在の ISPに解決を求めることで対処せざるを得ない。
ISP 側は、事前にこのような状況を想定し対策を講じておくことが望ましい。問合せや障害対応の 24 時間／365 日体制の整備といったオペレーション面、問題が起きた場合に43ユーザー自身が問題の把握や解決を可能にする Q&A の整備といったナレッジ面、また契約面でもこうした状況における対応についてユーザーとの合意を形成しておくことが重要
である。
(3)

ソフトウェアライセンス

CG・VFX の制作は、そのプロセスを商用アプリケーションに大きく依存している。
【資料 2-2】にあるように、Autodesk の製品については、クラウドなど WAN を越える利用におけるソフトウェアの使用許諾が無いため、実際の制作段階での実験を行うことはできなかったが、そうしたことが本実証実験の課題の一つとなっている。ソフトウェアメーカーに対して、ISP もユーザーとともにこの問題の解決に取り組むことが重要であると考える。

(4)

システム構築期間の短縮

今回の実証実験では、エヌ・デザインのローカルのレンダーファームに相当するシステ
ムをさくらインターネットのデータセンター（北海道石狩市）に作り上げることを目的として、ほぼ同等の使い勝手を実現しているとの評価を得た。その意味に関しては、おおよ
その目的を達成したと考えている。システムの構築に関する大きな課題として、ユーザーがレンダーファームの利用を開始できるまでの時間短縮が挙げられる。構築完了後のシステムに問題が無くとも、構築までに多大な時間を要してはその価値も損なわれる。今回の実証実験で行った構築に関する手作業の多くを、手順化・自動化等によって短縮することは必須課題となる。

(5)

制作環境の変化への対応

今回の実証実験で、データセンター（北海道石狩市）に置かれたシステムはエヌ・デザ
イン社内に置かれたシステムと同様のものであり、仮にこれがサービスと仮定した場合、エヌ・デザインにとってはレンダーファームを設置する面積、サーバの購入や電力消費にかかる費用、またそれを運用・管理する人的リソース等をサービスとして購入していることになる。これはあくまで現在までに行き着いた CG・VFX の制作の業務システムの一つの形であり、将来にわたって不変であるとは限らない。レンダーファームだけでなくワー
クステーションもデータセンターに置かれ、クリエイターはネットワークを介して転送されてくる画面上で制作業務を行う形や、制作用のアプリケーションもクラウドサービスで提供されるといった可能性も十分にあり得る。
いずれの方法にせよ、選ぶのは CG・VFX を制作するスタジオであり、ISP はその動向を注視し、最も価値ある形でサービスを提供することが望ましい。また、そういった制作
環境の変化が漸進的に進むことも考えられ、どの時期にどのようなサービスを提供するか（あるいはしないか）について十分に検討する必要がある。

44

課題と提案

2.8
2.8.1
(1)

課題

クラウドレンダリングの課金形態の課題

プロジェクトによってはクラウドレンダリングサービスを長期間にわたり利用する場合が想定されるが、レンダリングに使わないコンピュータリソースを解放することで、維持費用を下げることが考えられる。ただしファイルサーバについては、レンダリングを繰り返して試行錯誤する時の即時対応性と利便性を確保するために、データ量に応じて維持し続ける必要がある。
現在のクラウドレンダリングによるサービスでは、利用状況や課金状態が表示されるコントロールパネルなどが用意されており、課金に関する情報が把握できるようにはなっているが、標準の仕様に含まれないプラグインソフトウェアの追加においては、個別の問い合せ対応となっているなど金額面で不透明な部分もある。
レンダリングの課金単位（分、時間、週など）についても、それぞれの利用状況が異なるため、利用者である制作プロダクションの意見を取り入れることで改善できる要素は少なくないと考えられる。

(a) 現状のクラウドレンダリングの金額形態の分析
クラウドレンダリングサービスを提供する各社のサービス価格を時間単位の条件で並べると下記のようになる。
（制作プロダクションの視点で実際に利用する場合に選ぶと思われるサービスで比較している。）

45

表 2.8.1-01 レンダリングサービス
時間当た
サービス名

プラン

課金単位

仕様

備考

りの価格

ZYNC

Render Rocket

ZYNC 8$2.69

時間

2.8GHz 8 コア
15GB RAM

時間単位プランZYNC 16$3.69

時間

2.8GHz 16 コア
30GB RAM

時間単位プランZYNC 32$4.99

時間

2.8GHz 32 コア
60GB RAM

時間単位プランTIER 1

$0.70

28 日間

2.8GHz 16 コア
30GB RAM

2 台で 28 日間 $950

TIER 2$0.89

2.8GHz 16 コア
30GB RAM

5 台で 28 日間 $3,000

TIER 3$0.86

2.8GHz 16 コア
30GB RAM

12 台で 28 日間 $6,900

TIER 4

$0.82

28 日間

2.8GHz 16 コア
30GB RAM

25 台で 28 日間 $13,750

LAUNCH PAD

$5.60

時間

8 コア換算 8GB
RAMCore 単価 $0.70
前払いで、最大 30%オフ

SPACE
STATION

$0.59

週単位

8 コア

1 週間 $99 として

SPACE
STATION

$0.41

月単位

8 コア

1 ヶ月 $297 としてMental Ray

$4.80

実時間

12 コ ア 14GB
RAM

Core 単価 $0.40

V-Ray

$4.80

実時間

12 コ ア 14GB
RAM

Core 単価 $0.40

PlanA

$1.36

実時間

2.4GHz 24 コア
24 - 64GB RAM＊レンダリング 1 枚あたりの課金なので、30 分で終わ
れば 0.5 倍で済む

週、月単位

16 コア
48GB

週、月での契約で台数単位
での契約

時間

2.8GHz 6 コア

GreenButton

Fox
Render Farm

rebusfarm

Render Core

Plan B$1.03

Plan C$0.57

Weekly$1.03

Monthly$0.80

Economy$1.70

Business$2.16

5 node

$1.46

28 日間

2.4GHz 12 コア
24 - 32GB RAM

5 台で 28 日間 $4,904.47

100 node

$1.05

28 日間

2.4GHz 12 コア
24 - 32GB RAM

20 台で 28 日間 $14,095.19

Economy$1.08

時間

3.0GHz 12 コア
32 - 96GB RAM

Premium$1.89

30 Days$1.01

2.8GHz 6 コア

3.0GHz 12 コア
32 - 96GB RAM
30 日間

46

3.0GHz 12 コア
32 - 96GB RAM

コインの事前購入割引き
で、$20,000 購入した場合の 55%オフの価格
5 台で 30 日間 $3,500

事前にある程度の金額をポイントなどの形で購入するなど、事前支払いでの値引きが大きい傾向がある。週、月単位で購入することで単価が下がる傾向にある。課金方法が 1 時
間単位のものから、実際に利用した時間で計算されるものまでがあり、使い方によっては最終的な金額が大きく左右されると考えられる。

(b) クラウドレンダリングを使った場合の金額について
サ ン プ ル と し てZYNCの 料 金 計 算 機 能 の ペ ー ジ（https://www.zyncrender.com/calculator/）で時間単位での利用で料金シミュレーションしてみたところ、結果は表 2.8.1-02（レンダリング枚数 150 フレーム）と表 2.8.1-03（レンダリング枚数 300 フレーム）のとおりとなった。ここでは、プラン ZYNC 8 で、1 時間
あたり$2.69 をベースとしてシミュレーションを行った。
表 2.8.1-02 ZYNC の料金シミュレーション 1

1 フレームあたりのレンダリング処理に必要な時間が短い場合は、クラウドを利用せずにサービス利用者側でレンダリングした方がコスト、効率面ともに有利な場合もあるが、1 フレームあたり 30 分、1 時間かかるようなレンダリングに関しては、時間を節約するという意味ではサービスを利用した方が有効な場合もあると思われる。
例えば、1 フレーム 30 分かかる処理を 150 フレーム計算する場合、1 台では 3 日と 3時間かかるが、100 台で計算すれば、1 時間ですべてのレンダリングを終わらせることができる。また、1 フレーム 60 分かかる処理を 150 フレーム計算する場合、100 台で 2 時
間かけるよりも、150 台で 1 時間で終わらせた方が全体のコストを下げることができる。
表 2.8.1-03 ZYNC の料金シミュレーション 2

1 フレーム 60 分かかる処理を 300 フレーム計算する場合、1 台では 1 週間と 5 日と 1247

時間かかり、150 台では 2 時間で終わるが、両者で料金は変わらない。こうした計算感覚を合わせ持つことで、プロダクションコストを軽減できる可能性もあるが、これはあくま
でも処理時間を事前に想定し得る場合の話であり、こうしたことをアーティストが常に考えながらレンダリングをかけるということの負担と困難さも考えなければならない。
一方、経営の視点からは、こうした取組姿勢はプロジェクトを計画通りに進捗させ、深夜残業などによるコストを削減するなどの効用が期待される。

(2)

ソフトウェアライセンスの課題(a)

CG・VFX に使用するライセンスについて

ソフトウェアライセンスの課題に関しては、The Foundry 社の MODO など正式にクラウドレンダリングの利用を提示しているツールも増えつつあり、時間が解決してくれる可能性が高い。また、小規模の制作プロダクションで 4K などの案件が発生した際にレンダリングサービスを利用するケースが増えてきており、そうした需要も後押しになっていると考えられる。

(b)

OS の提供形態について

クラウドでレンダリングするためには、CG・VFX で使用するソフトウェア以外に、OSのライセンスも必要である。今回の検証では、OS については制作プロダクションと同じ環境である Windows OS について検討を行った。
ISP からの OS の提供形態を検討した結果、ライセンス所有者と利用者が異なるため、サービス提供者がサービス利用者にライセンスを提供する SPLA（Service Provider
License Agreement）方式で Microsoft Datacenter エディションを提供してもらい、デー
タセンターでのレンダリングサーバ、ファイルサーバの OS として利用した。
参照：Microsoft Datacenter エディション
https://www.microsoft.com/ja-jp/server-cloud/windows-server/buy.aspx
参考：Microsoft Service Provider License Agreement
http://www.microsoft.com/ja-jp/server-cloud/windows-server/licenseguide/spla-01.aspx(c) 管理目的でサーバを利用するための SAL（Subscriber Access License）などのライセンス
について
テスト、保守または管理目的としてログオンをして画面上で作業をする場合は、2 名までであれば管理目的としてサーバを利用できる。また、ログオンをして画面上で作業せず（GUI を使用せずに）レンダリング作業に利用する場合、追加のライセンスは必要ないことが確認できた。
サービスプロバイダ製品使用権説明書の P.22 に「テスト、保守、および管理のためのアクセス」として、下記の様に記載されている。
48

テスト、保守、および管理のためのアクセス

お客様は、オペレーティング システム環境 (OSE) で実行中の各インスタンスについて、
最大 2 人までの他のユーザーに対し、グラフィカル ユーザー インターフェイスを直接または間接的にホストする目的で Windows Server 2012 R2 Remote Desktop Servicesの機能またはその他のテクノロジを使用して本サーバー ソフトウェアを使用すること、または本サーバー ソフトウェアにアクセスすることを許可できるものとします。かかる使用は、使用許諾された製品をテスト、保守、または管理する目的でのみ認められます。かかるユーザーには、Windows Server 2012 R2 Remote Desktop Services SAL は必要ありません。
参考：サービスプロバイダー製品使用権説明書（日本語版 2014 年 1 月版）
http://download.microsoft.com/download/5/D/9/5D9CAD87-76BC-41E2-BCEF-0176CB
8084CA/ServicesProviderUseRights(Worldwide)(Japanese)(January2014)(CR).pdf
このような細かな条件についても、サービスを提供する際に定義する必要があり、また使用許諾などはその都度変更が行われることがあるので、ポイントをリスト化し重要な項
目が常に変更されていないかなど確認することも重要である。

回線の課題

(3)

本年度は制作プロダクション 1 社でのテストだったが、ベストエフォート型のサービスの場合はその都度回線の状況が変化するので、テストした時点では問題なくとも、実際に利用する際に問題なく利用できるかどうかは定かではない。しかしながら、データセンタ
ーから制作プロダクションまでのすべての回線で不確定要素を排除するには、専用回線を敷設する選択肢しかなくコストが高くなってしまうため現実的ではない。
一般的なインターネット利用では、利用者からデータセンターへの転送（アップロード）
よりもデータセンターから利用者への転送（ダウンロード）のほうが、利用頻度が高く転送されるデータ量が多いが、CG レンダリングの場合は逆であることが多い。またインターネット回線の混み具合は深夜など時間帯によって比較的空いていることもある。そうした利用頻度の低い時間帯や回線などを組み合わせることで、より利用しやすい料金形態について ISP と一緒に検討するということも考えられる。

2.8.2
(1)

提案

アセットマネジメントの推進システム構築型のクラウドレンダリングを本格的に活用する前に、アセットマネジメン
トの取り組みを強化することは制作作業効率の面でも良いと考えられる。
また、アーカイブする上においても、ファイルサーバの低価格化や高速化が進むことで、

49

サーバ上で管理するファイル数が増大し、アセットマネジメントの重要度は高くなって来ている。

制作フローの抜本的な見直し(2)

データセンターで処理を行う場合、ソフトウェアのライセンス問題も含めて統合ツールで作成したデータをそのまま使用しようとすると問題が生じる。
この問題に対応するためには制作フローを抜本的に見直し、データセンターで必要とするソフトウェアやデータを最低限のものに絞った構成にしておくことが望ましい。このよ
うな体制を構築するのに最も有効な手段は、3DCG ソフトウェアに統合されたレンダラに完全に依存するのではなく、スタンドアロンのレンダラを中心としたレンダリング体制を構築することである。
スタンドアロンのレンダラを使用できるようにすることで、データセンターでの処理に必要なソフトウェアはレンダラとシェーダ、必要なデータはレンダラの扱うシーンデータとそれに付随するデータとなり、各種ライセンスの処理やシステム構築の負荷が軽減される。
スタンドアロンのレンダラを使用した制作は、以前は一般的に行われていたが、近年
Maya や 3ds Max といった統合ソフトウェアが主流になるにつれて日本ではほとんど行
われなくなってしまった。そのおかげで映像制作の敷居が下がったという良い面もあるが、その反面ライセンスやプラグイン、ソフトウェア間のバージョンなど複雑な問題を引き起こす原因にもなっている。
統合ソフトウェアの便利さは享受しつつ、シンプルな形でもデータを扱うことができる
ように複合的な体制を構築することが今後は必要とされるようになる。

(3)

レンダリングコストの透明化

SD から HD に変わった際には、一時的にレンダリングコストの増加について制作費に追加できた場合もあったが、その後のレンダリングコストの増加については、主に制作プ
ロダクションがレンダリングに対する投資や効率化の工夫で吸収しているのが実情である。
外部のサービスを利用することになれば、こうしたレンダリングコストを明確にすることができるため、顧客に対して実際にかかった経費を請求できるようになる。そのためにも、
現在社内で行っているレンダリングについても明確にコストを提示する必要がある。
その算出のためには、下記の主要な 4 項目について明確にしておく必要がある。
・

場所代（月額で固定のため算出し易い）・

電気代（サーバの種類ごとに 1 時間あたりの単価を算出）

・

レンダリングサーバ代（購入のサイクルに合わせ、1 時間あたりの単価を算出）

・

ライセンス費用（保守、アップグレードを考慮した費用から算出）

50

場所代は、制作プロダクションの所在地によって大きく異なるため除くが、例えば、レンダリングサーバ代とライセンス費用そして電気代から、下記のような形で、レンダリン
グサーバの維持コストを算出できる。
表 2.8.2-01 制作プロダクションにおけるレンダリングサーバ維持コスト例
Dual Xeon

Single Xeon

コンピュータ仕様 CPU

2.8GHz3.0GHzコンピュータ仕様 RAM

64GB

32GB

¥800,000¥300,000

¥30

¥11

購入金額
1 時間あたり（3 年で分割として）Mental Ray や Render Man の平均的なレンダラ（保守 1 年として）¥100,000¥100,000

1 時間あたり

¥11

¥11

消費電力

4A

2A

保守参考価格として最大パワーで計算した際の想定として常にフルパワーで稼働しているとは限電気代（1Kwh=25 円として）

¥10

¥5

1 時間あたり¥52¥28

24 時間あたり¥1,245¥668

30 日間あたり¥37,337¥20,03851

らないが、最大値として

第3章

WG2：クラウド運用でのデータ共有とクラウドレンダリン
グの実証実験

3.1

WG2 の目的WG2 では、映像制作工程の後半パートにあたる「デジタル合成処理」をクラウド上で実現するための道筋を明らかにすることを目的に、実証実験を実施した。具体的には、「必要レベルのセキュリティを確保した上、制作コストを抑制しつつ、現場技術者・利用者の負担を軽減し、誰もが手軽に扱えて、制作時間を短縮できること」を目指した内容になっ
ている。

3.2

セキュリティ

CG・VFX プロダクションが送受信するデータは、作品公開前の極めて機密性の高いデータであることが多い。そのため例えば専用回線のように高いレベルのセキュリティが確保されていることが望ましいが、その導入コストは高く、国内の制作プロダクションにとっては現実的ではない。そのため B フレッツ光などの「100Mbps ベストエフォートタイ
プ」のような一般的なインターネット回線の使用を前提で考えることが現実的であるが、その場合下記のようなセキュリティ対策を講じる必要がある。WG2 では以下の 2 つの環境について検証を行った。

(1)

VPN 接続一般公衆インターネット回線を利用するが、データを送受信する両拠点に専用の VPN
機器を設置することで、仮想的に専用線を構成しセキュリティを確保する手法。WG2 では、データセンターと東映アニメーション間に VPN 回線を構築し実験を行った。

(2)

専用ネットワークソフトによる暗号化処理

暗号処理をすることで一般公衆回線でもセキュリティを確保しデータ転送する方法。
WG2 では、そのための専用ネットワークソフト（Skeed 社 Silver Bullet）を使用した。
実際にはデータセンターと株式会社 4D ブレインとの間で実験を行った。

52

検証システムの全体像と構成要素

3.3

今回の検証システムの全体像と、その中で重要な要素を以下に記述する。

3.3.1

検証システムの全体像

WG2 のシステムは一般的なインターネット環境を利用することを前提として、東映デジタル・ラボ株式会社が運用しているデータセンターを拠点とし、以下の様な考え方に基づいて構成した。
①

データセンターは株式会社 IDC フロンティアに委託されており、またデータセンターを運用管理している東映デジタル・ラボ株式会社との間は NURO（1Gbps のベスト
エフォート）回線が利用している。

②

データセンターと東映アニメーション株式会社との間に VPN 接続環境を構築した。
構築に当たっては、株式会社 IDC フロンティアがデータセンター側を、東映アニメー
ション株式会社が同社側を担当した。また一時的に NURO（1Gbp のベストエフォート）回線を契約し利用した。

③

VPN を利用しない検証のため、データセンターと株式会社 4D ブレインを一般インターネット回線で結び、実証実験を行った。

次頁にシステムの全体図を記す。

53

図 3.3.1-01 WG2 実証システム全体図

54

3.3.2

VPN 回線

通常、VPN 接続の構築には 1 年以上の契約期間が必要だが、今回の実験では、ソネッ
トビジネスアソシエイツ株式会社の協力で 3 ヶ月限定の NURO（1Gbp のベストエフォート）回線の環境を用意した。また今回の VPN 接続に使用するルータは、バリオセキュア
株式会社の協力の下に同社のハードウェアルーターを用意した。

図 3.3.2-01 NURO_VPN 回線

55

VPN 設置の流れは以下の通り。
表 3.3.2-01 VPN 接続網設置のスケジュール

2013 年 10 月 11 日

回線及び機器関係の使用申請書を提出

10 月 17 日

現地調査を行う（IDCF データセンター）

10 月 30 日

現地調査を行う（東映アニメーション）

11 月 15 日

東映アニメーション側の NURO 回線工事

11 月末まで

各種設定及びテスト

12 月初旬VPN 設定を含むすべての設置完了

なお、拠点間 VPN 接続と同時に、クラウドレンダリングの高速化を目指した高速サーバの検証を行うこととした。このため東京エレクトロンデバイス株式会社と株式会社日立製作所の協力を得て、日立製 HS8000 サーバに Fusion-IO を搭載したストレージを用意した。
本来このサーバはクラウド側のレンダリング用ファイルサーバとして使用するのが効果的だが、今回の実験ではその環境構築が間に合わなかった。そのためこの実験では、東映アニメーション株式会社側のファイルサーバとして設置することとなった。以下にその概要と利用した機器を記す。

図 3.3.2-02 接続概念図56

図 3.3.2-03 利用機器説明図

3.3.3

専用ネットワークソフト「Skeed 社 Silver Bullet」

暗号化によるセキュリティ確保と同時に高速転送を可能とする、専用ネットワークソ
フト Silver Bullet を使って検証した。その主な特徴は以下である。
(1)

大容量データ対応

マルチアップロード機能により、GB、TB クラスの大容量データのアップロードが可能。
(2)

セキュリティ

アルゴリズムにより暗号化しながらデータを高速に転送する。途中でデータを抜かれても復元できない。
(3)

レジューム機能回線障害などにより一旦転送が止まっても、回線が回復した時点で、止まった箇所からデータ送信を再開する機能。改めて最初からデータ転送することによる時間の増大リスクを回避するという点で極めて重要である。

57

下図は Silver Bullet を用いたデータ転送の際の暗号化のイメージを示す。

図 3.3.3-01 暗号化のイメージ

3.3.4

デジタル合成処理用アプリケーション「The Foundry 社 Nuke」

今回は 3DCG アプリケーションとの親和性が高いと言われている、デジタル合成処理用
アプリケーション The Foundry 社の Nuke を利用した。実験に当たっては The Foundry
社と株式会社ボーンデジタルの協力で、クラウドレンダリング実施のために 3 ヶ月間限定のライセンス契約を締結した。
さらにこうした合成処理作業の進捗管理を簡素化する目的で The Foundry 社が提供している管理用アプリケーションである Hiero についても合わせて検証を行った。
以下に簡単なワークフローを記す。

図 3.3.4-01 ワークフロー概念図

58

3.3.5

分散レンダリングクラウド上でのレンダリングを検討するとき、現状のネットワーク環境ではアップロー
ドとダウンロードのデータ転送にかかる時間は大きなマイナス要因となる。しかしながら現状の日本国内の一般的なインターネット回線を考えると、回線スピードの向上は簡単に期待できない。そこで WG2 では、レンダリング処理を高速化し、転送処理と合わせた総合時間を短縮することを目指して、「分散レンダリング」の効果についても検証することとした。分散レンダリングのアプリケーションは、東映ラボ・テック株式会社が After Effectsのクラウドレンダリング分散処理に使用している株式会社フジテレビジョン製 Render
Spice を使用した。Render Spice は、Nuke の分散レンダリングに標準対応している。
以下に今回の分散レンダリングの概念図を記す。

図 3.3.5-01 分散レンダリング概念図

3.4
3.4.1

実証実験の結果について
Silver Bullet によるデータ転送

専用ネットワークソフト Silver Bullet を使用し、東映デジタル・ラボとデータセンター
間で、昨年秋より利用している NURO（1Gbp のベストエフォート）回線を使って、データ転送実験を実施した。
その結果、Silver Bullet は、「操作が簡単で使いやすいこと」「レジューム機能の有効性」
が確認されたが、その反面、データ転送時に他のデータを追加転送出来ないなど、いくつかの問題点も明らかになった。以下に、転送実験の結果を記載する。

59

表 3.4.1-01 インターネット一般回線（NURO）を使用した場合の転送速度

データ量

ダウンロード転送時間

アップロード転送時間/ 転送速度/ 転送速度

約 1GB

1 分 12 秒 / 114.9 Mbps

1 分 50 秒 / 74.7 Mbps

約 5GB

4 分 59 秒 / 133.6 Mbps

8 分 50 秒 / 75.9 Mbps

約 10GB

9 分 05 秒 / 146.7 Mbps

18 分 05 秒 / 74.0 Mbps

上記データの測定は、1GB、5GB、10GB のファイルのアップロードとダウンロードをそれぞれ 3 回繰り返し、転送完了時のスループットと転送時間を記録した後、3 回の測定
値の中間値を採用したものである。なおベストエフォートタイプのため、回線状況によっては同様の結果が出ることを保証するものではなく、参考数値と考えていただきたい。
測定結果から、Silver Bullet の転送スピードが安定していることが良くわかる。また
NURO 回線は、今回のテスト結果を見る限り映像データの転送には適していると思われる。
NURO 回線のように 1Gbps ベストエフォートタイプがリーズナブルな価格で利用できることは歓迎すべきことである。NURO 回線のスペックを考慮すれば、ネットワークルー
タや転送ソフトの改良などにより、転送速度向上の余地があるとも考えられる。

3.4.2

VPN 接続におけるデータ転送

以下に、データセンターと東映アニメーション株式会社間の、実験用 NURO-VPN 回線を使用した転送スピードに関する結果を記載する。
表 3.4.2-01 アップロード転送時間

データ量
約 1.22GB

約 19.34GB

約 58.39GB

検証回数

転送時間

１回目

2 分 50 秒/

58.7Mbps

２回目

2 分 18 秒/

72.5Mbps

３回目

2 分 19 秒/

71.6Mbps

１回目

39 分 24 秒/

67.3Mbps

２回目

39 分 44 秒/

66.4Mbps

３回目

37 分 58 秒/

69.5Mbps

１回目

1 時間 55 分 30 秒/

69.0Mbps

２回目

1 時間 59 分 11 秒/

66.9Mbps

３回目

1 時間 56 分 38 秒/

68.3Mbps60表 3.4.2-02 ダウンロード転送時間

データ量
約 2.20GB

約 3.24GB

約 3.42GB

検証回数

転送時間

１回目

10 分 44 秒/

27.9Mbps

２回目

9 分 47 秒/

30.6Mbps

３回目

9 分 42 秒/

30.9Mbps

１回目

19 分 49 秒/

22.3Mbps

２回目

17 分 57 秒/

24.6Mbps

３回目

13 分 36 秒/

32.3Mbps

１回目

2 分 53 秒/

162.0Mbps

２回目

2 分 47 秒/

167.8Mbps

３回目

2 分 47 秒/

167.8Mbps

実験の結果、今回設置した NURO-VPN 回線では、当初想定していたほど速度が出ていないことが判明した。その要因としては回線状況の不安定性が考えられるが、一方で VPN
ルータの設定の変更で改善する可能性も想定される。
また、「表 3.4.2-02

ダウンロード転送時間」の 3.42GB の部分だけが転送スピードで大きく変化しているのは、ベストエフォート回線の不安定性に起因するものと思われるが、
ローカル側のネットワーク環境の要因も否定出来ない。
これらの問題については、今後も引き続き原因究明のための検証作業が必要と考えられ
る。

3.4.3

VPN 接続での検証と結果

東映アニメーション株式会社とデータセンター間の VPN 回線を利用した実証実験の検証内容とその結果を以下に報告する。

（1）クラウドレンダリングにおける分散レンダリングの効果の検証
クラウドレンダリングはデータセンターのレンダリングサーバがデータ処理をすることで成立するが、そのデータの所在は必ずしもデータセンターにある必要はない。

61

図 3.4.3-01 クラウド側にデータをすべて転送してからレンダリング

通常は図 3.4.3-01 のようにローカルにあるデータをすべてデータセンターに転送した上でレンダリング等の処理を行い、結果をローカル側で受け取る。

図 3.4.3-02 データを仮想的にマウントして直接レンダリング

他方、VPN 環境を利用するメリットとして考えられるのが、図 3.4.3-02 の形態である。
これはデータセンターから VPN 越しにローカル側のファイルサーバを、ネットワークド
ライブとしてマウントすることで認識し、データを直接読み出してクラウド側でレンダリングする手法である。この方法ではあらかじめデータセンターへすべてのデータをアップロードする必要がないため、様々な面で効率的な作業と運用が期待される。しかしながら実際に運用するためにはネットワーク環境が十分高速である必要がある。WG2 では今回構築した VPN 環境で果たしてどこまで理論通りに動作するかも検証対象とした。
なお、検証データは以下の 3 つのケースを準備して実施した。

62

表 3.4.3-01 検証データの種類

ケース 1
ケース 2
ケース 3

入力データ量

約 19.30GB/ ファイル数

22,189出力データ量

約 2.20GB /入力データ量

約 58.30GB

出力データ量

約 3.24GB /

ファイル数

494

入力データ量

約 1.22GB /

ファイル数

1,933

出力データ量

約 3.42GB /

ファイル数

522

ファイル数

335

/ ファイル数

40,104

またローカル環境でPC1台でレンダリングした場合の所要時間は以下の表の通り。この数
値は分散レンダリング所要時間の比較基準として使用するが、クラウドレンダリングで使用したPCとはスペックが異なるので、絶対値は比較できず、参考程度に考えていただきたい。
表 3.4.3-02 ローカル環境での PC1 台でのレンダリング時間

ケース 1

19 分 12 秒

ケース 2

1 時間 26 分 27 秒

ケース 3

34 分 45 秒

次頁以降に分散レンダリングマシン 20 台を使ったレンダリング時間の結果を示す。
なお便宜上「ローカル側のファイルサーバをネットワークドライブとしてマウントし、VPN 越しに直接データにアクセスしてレンダリング」する形態を「VPN マウント型レンダリング」、「クラウド側にデータをすべて転送してからレンダリング」する形態を「データ転送型レンダリング」と表記する。

63

表 3.4.3-03 VPN マウント型レンダリング：ケース 1 の検証結果

1 回目
winserver
1
winserver
2
winserver
3
winserver
4
winserver
5
winserver
6
winserver
7
winserver
8
winserver
9
winserver 10
winserver 11
winserver 12
winserver 13
winserver 14
winserver 15
winserver 16
winserver 17
winserver 18
winserver 19
winserver 20
MIN-MAX
レンダリング時間
レンダリング
平均時間

2 回目

3 回目

開始時刻
0:14:01
0:14:03
0:14:04
0:14:05
0:14:06
0:14:07
0:14:09
0:14:09
0:14:10
0:14:11
0:14:12
0:14:14

終了時刻
0:21:33
0:21:33
0:21:220:21:34
0:21:58
0:22:08
0:22:06
0:22:23
0:23:39
0:23:15
0:22:57
0:22:54

開始時刻
0:24:43
0:24:44
0:24:44
0:24:46
0:24:47
0:24:47
0:24:49
0:24:50
0:24:51
0:24:53
0:24:53
0:24:54

終了時刻
0:28:47
0:28:53
0:28:40
0:28:55
0:29:19
0:29:21
0:29:27
0:29:37
0:30:56
0:30:32
0:30:23
0:30:14

開始時刻
0:39:11
0:39:12
0:39:13
0:39:15
0:39:16
0:39:17
0:39:18
0:39:19
0:39:20
0:39:21
0:39:23
0:39:24

終了時刻
0:43:11
0:43:18
0:43:09
0:43:21
0:43:42
0:43:48
0:43:55
0:44:12
0:45:48
0:44:53
0:44:59
0:44:33

0:14:16
0:14:17
0:14:18
0:14:20
0:14:20
0:14:22
0:14:23
0:14:01

0:22:28
0:22:10
0:22:03
0:22:06
0:21:52
0:21:52
0:22:05
0:23:39

0:24:57
0:24:57
0:24:59
0:25:00
0:25:01
0:25:02
0:25:04
0:24:43

0:29:42
0:29:32
0:29:02
0:29:17
0:29:11
0:29:09
0:29:16
0:30:56

0:39:25
0:39:27
0:39:28
0:39:29
0:39:30
0:39:31
0:39:32
0:39:11

0:44:04
0:43:59
0:43:33
0:43:44
0:43:41
0:43:33
0:43:48
0:45:48

0:09:38（9 分 38 秒）

0:06:13（6 分 13 秒）

0:06:37（6 分 37 秒）
7 分 29 秒

図 3.4.3-03 VPN マウント型レンダリング：ケース 1 の検証イメージ

PC1 台でのローカル環境でのレンダリング時間（19 分 12 秒）と比較すると、VPN マ
ウント型レンダリング：ケース 1 のレンダリング平均時間（7 分 29 秒）は約 2.6 倍のスピ
ードアップという結果であった。なお winserver13 については、動作不良により数値が取れなかったため、網かけとしている。

64

表 3.4.3-04 VPN マウント型レンダリング：ケース 2 の検証結果

1 回目
winserver
1
winserver
2
winserver
3
winserver
4
winserver
5
winserver
6
winserver
7
winserver
8
winserver
9
winserver 10
winserver 11
winserver 12
winserver 13
winserver 14
winserver 15
winserver 16
winserver 17
winserver 18
winserver 19
winserver 20
MIN-MAX
レンダリング
時間

開始時刻
17:05:19
17:05:20
17:05:22
17:05:22
17:05:24
17:05:25
17:05:27
17:05:27
17:05:28
17:05:30
17:05:31
17:05:31
17:05:33
17:05:34
17:05:35
17:05:36
17:05:37
17:05:38
17:05:40
17:05:41
17:05:19

終了時刻
17:20:22
17:20:42
17:23:49
17:25:42
17:26:00
17:26:15
17:24:26
17:23:43
17:25:28
17:24:05
17:24:52
17:26:37
17:26:22
17:29:18
17:25:16
17:23:20
17:24:37
17:22:54
17:23:02
17:26:43
17:29:18

2 回目
開始時刻
18:12:41
18:12:42
18:12:43
18:12:44
18:12:46
18:12:47
18:12:48
18:12:49
18:12:50
18:12:52
18:12:52
18:12:53
18:12:55
18:12:55
18:12:56
18:12:57
18:12:59
18:13:00
18:13:01
18:13:02
18:12:41

終了時刻
18:32:16
18:32:49
18:35:48
18:37:47
18:37:34
18:38:09
18:35:22
18:36:13
18:33:39
18:32:27
18:32:49
18:35:18
18:34:38
18:37:55
18:41:53
18:40:51
18:43:13
18:42:00
18:42:11
18:45:40
18:45:40

3 回目
開始時刻
20:09:29
20:09:31
20:09:32
20:09:33
20:09:34
20:09:36
20:09:37
20:09:38
20:09:39
20:09:40
20:09:41
20:09:42
20:09:43
20:09:44
20:09:46
20:09:47
20:09:47
20:09:48
20:09:50
20:09:51
20:09:29

終了時刻
20:28:03
20:28:36
20:31:51
20:33:08
20:33:16
20:33:45
20:31:32
20:32:26
20:29:29
20:28:04
20:28:12
20:30:27
20:30:07
20:33:35
20:37:46
20:36:17
20:38:37
20:37:29
20:37:23
20:41:28
20:41:28

0:23:59

0:32:59

0:31:59（23 分 59 秒）（32 分 59 秒）（31 分 59 秒）

レンダリング

29 分 39 秒

平均時間

図 3.4.3-04 VPN マウント型レンダリング：ケース 2 の検証イメージ

PC1 台でのローカル環境でのレンダリング時間（1 時間 26 分 27 秒）と比較すると、VPN
マウント型レンダリング：ケース 2 のレンダリング平均時間（29 分 39 秒）は約 2.9 倍のスピードアップという結果であった。

65

表 3.4.3-05 VPN マウント型レンダリング：ケース 3 の検証結果

1 回目
winserver
1
winserver
2
winserver
3
winserver
4
winserver
5
winserver
6
winserver
7
winserver
8
winserver
9
winserver 10
winserver 11
winserver 12
winserver 13
winserver 14
winserver 15
winserver 16
winserver 17
winserver 18
winserver 19
winserver 20
MIN-MAX

開始時刻
21:53:35
21:53:36
21:53:37
21:53:39
21:53:40
21:53:40
21:53:42
21:53:43
21:53:43
21:53:46
21:53:46
21:53:47
21:53:49
21:53:49
21:53:50
21:53:51
21:53:53
21:53:54
21:53:55
21:53:56
21:53:35

終了時刻
22:13:32
22:13:34
22:13:27
22:13:26
22:13:24
22:13:22
22:13:17
22:13:10
22:13:08
22:13:06
22:13:09
22:13:09
22:13:07
22:13:08
22:12:42
22:12:41
22:12:40
22:12:39
22:12:40
22:12:38
22:13:34

開始時刻
22:29:06
22:29:07
22:29:09
22:29:10
22:29:11
22:29:12
22:29:13
22:29:14
22:29:15
22:29:17
22:29:18
22:29:19
22:29:20
22:29:21
22:29:22
22:29:23
22:29:24
22:29:25
22:29:27
22:29:28
22:29:06

終了時刻
22:33:46
22:33:49
22:33:42
22:33:42
22:33:40
22:33:39
22:33:36
22:33:25
22:33:24
22:33:23
22:33:26
22:33:26
22:33:22
22:33:24
22:33:02
22:32:59
22:32:56
22:32:57
22:32:57
22:32:51
22:33:49

3 回目
開始時刻
22:34:22
22:34:24
22:34:25
22:34:26
22:34:27
22:34:28
22:34:29
22:34:30
22:34:31
22:34:33
22:34:34
22:34:35
22:34:36
22:34:37
22:34:38
22:34:39
22:34:40
22:34:42
22:34:43
22:34:44
22:34:22

終了時刻
22:39:07
22:39:09
22:38:58
22:38:59
22:38:56
22:38:55
22:38:51
22:38:42
22:38:39
22:38:39
22:38:42
22:38:41
22:38:39
22:38:41
22:38:16
22:38:14
22:38:14
22:38:15
22:38:12
22:38:06
22:39:09

0:19:59

0:04:43

0:04:47（19 分 59 秒）（4 分 43 秒）（4 分 47 秒）

レンダリング時間

2 回目

レンダリング

9 分 50 秒

平均時間

図 3.4.3-05 VPN マウント型レンダリング：ケース 3 の検証イメージ

PC1 台でのローカル環境でのレンダリング時間（34 分 45 秒）と比較すると、VPN マ
ウント型レンダリング：ケース 3 のレンダリング平均時間（9 分 50 秒）は約 3.5 倍のスピ
ードアップという結果であった。

66

表 3.4.3-06 データ転送型レンダリング：ケース 1 の検証結果

1 回目
winserver
1
winserver
2
winserver
3
winserver
4
winserver
5
winserver
6
winserver
7
winserver
8
winserver
9
winserver 10
winserver 11
winserver 12
winserver 13
winserver 14
winserver 15
winserver 16
winserver 17
winserver 18
winserver 19
winserver 20
MIN-MAX
レンダリング
時間

2 回目

3 回目

開始時刻
21:46:37
21:46:38
21:46:39
21:46:41
21:46:42
21:46:42
21:46:44
21:46:45

終了時刻
21:48:21
21:47:52
21:47:36
21:48:09
21:48:12
21:47:57
21:47:59
21:48:07

開始時刻
21:06:34
21:06:35
21:06:36
21:06:38
21:06:38
21:06:40
21:06:41
21:06:42

終了時刻
21:08:16
21:07:48
21:07:31
21:08:06
21:08:07
21:07:54
21:07:56
21:08:03

開始時刻
21:40:20
21:40:21
21:40:23
21:40:24
21:40:25
21:40:26
21:40:27
21:40:29

終了時刻
21:42:02
21:41:35
21:41:17
21:41:52
21:41:55
21:41:40
21:41:44
21:41:50

21:46:47
21:46:49
21:46:50
21:46:50

21:48:31
21:48:39
21:48:39
21:48:28

21:06:44
21:06:46
21:06:46
21:06:47

21:08:28
21:08:36
21:08:35
21:08:24

21:40:31
21:40:31
21:40:33
21:40:34

21:42:13
21:42:22
21:42:22
21:42:12

21:46:53
21:46:53
21:46:55
21:46:56
21:46:57
21:46:58
21:46:37

21:48:19
21:48:10
21:48:08
21:48:09
21:48:09
21:48:12
21:48:39

21:06:49
21:06:51
21:06:52
21:06:53
21:06:54
21:06:55
21:06:34

21:08:16
21:08:10
21:08:05
21:08:05
21:08:05
21:08:09
21:08:36

21:40:36
21:40:37
21:40:38
21:40:39
21:40:40
21:40:42
21:40:20

21:42:02
21:40:37
21:41:52
21:41:52
21:41:52
21:41:55
21:42:22

0:02:02

0:02:02

0:02:02（2 分 2 秒）（2 分 2 秒）（2 分 2 秒）

レンダリング

2分2秒

平均時間

図 3.4.3-06 データ転送型レンダリング：ケース 1 の検証イメージ

PC1 台でのローカル環境でのレンダリング時間（19 分 12 秒）と比較すると、データ転送型レンダリング：ケース 1 のレンダリング平均時間（2 分 2 秒）は約 9.4 倍のスピード
アップであった。なお winserver9、および 14 については、動作不良により数値が取れな
かったため、網かけとしている。

67

表 3.4.3-07 データ転送型レンダリング：ケース 2 の検証結果

1 回目
winserver
1
winserver
2
winserver
3
winserver
4
winserver
5
winserver
6
winserver
7
winserver
8
winserver
9
winserver 10
winserver 11
winserver 12
winserver 13
winserver 14
winserver 15
winserver 16
winserver 17
winserver 18
winserver 19
winserver 20
MIN-MAX
レンダリング
時間

2 回目

3 回目

開始時刻
22:52:46
22:52:47
22:52:48
22:52:50
22:52:51
22:52:51
22:52:52
22:52:54

終了時刻
22:55:40
22:55:39
22:55:42
22:55:55
22:56:02
22:55:58
22:55:34
22:55:33

開始時刻
23:00:41
23:00:42
23:00:43
23:00:44
23:00:46
23:00:47
23:00:47
23:00:49

終了時刻
23:07:03
23:06:58
23:07:04
23:07:18
23:07:25
23:07:18
23:06:43
23:06:37

開始時刻
23:22:18
23:22:18
23:22:20
23:22:21
23:22:22
23:22:23
23:22:24
23:22:26

終了時刻
23:28:39
23:28:33
23:28:39
23:28:55
23:29:00
23:28:51
23:28:20
23:28:10

22:52:56
22:52:57
22:52:59
22:52:59

22:55:38
22:55:41
22:55:46
22:56:03

23:00:51
23:00:52
23:00:53
23:00:54

23:04:17
23:04:26
23:04:40
23:04:38

23:22:27
23:22:29
23:22:30
23:22:31

23:25:50
23:25:57
23:26:01
23:26:08

22:53:01
22:53:02
22:53:04
22:53:05
22:53:06
22:53:07
22:52:46

22:56:08
22:55:57
22:56:04
22:55:53
22:56:00
22:56:07
22:56:08

23:00:56
23:00:57
23:00:58
23:01:00
23:01:01
23:01:02
23:00:41

23:06:29
23:06:16
23:06:23
23:06:26
23:06:29
23:06:39
23:07:25

23:22:33
23:22:34
23:22:35
23:22:37
23:22:37
23:22:39
23:22:18

23:27:59
23:27:39
23:27:54
23:27:49
23:27:56
23:28:06
23:29:00

0:03:22

0:06:44

0:06:42（3 分 22 秒）（6 分 44 秒）（6 分 42 秒）

レンダリング5 分 36 秒

平均時間

図 3.4.3-07 データ転送型レンダリング：ケース 2 の検証イメージ

PC1 台でのローカル環境でのレンダリング時間（1 時間 26 分 27 秒）と比較すると、データ転送型レンダリング：ケース 2 のレンダリング平均時間（5 分 36 秒）は約 15.4 倍のスピードアップという結果であった。なお winserver9、および 14 については、動作不良
により数値が取れなかったため、網かけとしている。

68

表 3.4.3-08 データ転送型レンダリング：ケース 3 の検証結果

1 回目
winserver
1
winserver
2
winserver
3
winserver
4
winserver
5
winserver
6
winserver
7
winserver
8
winserver
9
winserver 10
winserver 11
winserver 12
winserver 13
winserver 14
winserver 15
winserver 16
winserver 17
winserver 18
winserver 19
winserver 20
MIN-MAX
レンダリング
時間

2 回目

3 回目

開始時刻
0:27:47
0:27:47
0:27:49
0:27:50
0:27:52
0:27:52
0:27:54
0:27:55

終了時刻
0:32:06
0:32:02
0:31:59
0:31:59
0:31:58
0:31:59
0:31:56
0:31:52

開始時刻
0:38:20
0:38:21
0:38:22
0:38:23
0:38:24
0:38:25
0:38:26
0:38:27

終了時刻
0:42:38
0:42:34
0:42:31
0:42:32
0:42:30
0:42:33
0:42:29
0:42:23

開始時刻
0:44:51
0:44:52
0:44:53
0:44:55
0:44:56
0:44:57
0:44:58
0:44:59

終了時刻
1:18:12
1:18:05
1:18:02
1:18:02
1:18:02
1:18:04
1:18:00
1:17:54

0:27:57
0:27:58
0:27:59
0:28:00

0:31:50
0:31:54
0:31:55
0:31:52

0:38:30
0:38:31
0:38:32
0:38:33

0:42:23
0:42:26
0:42:27
0:42:25

0:45:01
0:45:02
0:45:03
0:45:04

1:17:53
1:17:56
1:17:58
1:17:55

0:28:02
0:28:03
0:28:05
0:28:05
0:28:07
0:28:08
0:27:47

0:31:28
0:31:29
0:31:25
0:31:25
0:31:23
0:31:14
0:32:06

0:38:35
0:38:36
0:38:37
0:38:39
0:38:40
0:38:41
0:38:20

0:42:01
0:42:01
0:41:58
0:41:58
0:41:56
0:41:46
0:42:38

0:45:07
0:45:08
0:45:09
0:45:10
0:45:11
0:45:12
0:44:51

1:17:32
1:17:31
1:17:28
1:17:29
1:17:26
1:17:17
1:18:12

0:04:19

0:04:18

0:33:21（4 分 19 秒）（4 分 18 秒）（33 分 21 秒）

レンダリング

13 分 59 秒

平均時間

図 3.4.3-08 データ転送型レンダリング：ケース 3 の検証イメージ

PC1 台でのローカル環境でのレンダリング時間（34 分 45 秒）と比較すると、データ転送型レンダリング：ケース 3 のレンダリング平均時間（13 分 59 秒）は約 2.5 倍のスピードアップであった。ただし、3 回目の実績はレンダーノードのトラブルと思われるのでこれを除くと実質レンダリング時間は約 8.1 倍のスピードアップとなる。なお winserver9、および 14 については、動作不良により数値が取れなかったため、網かけとしている。
69

以上の測定結果を一覧にしたのが以下の表である。ただしデータ転送型レンダリング：
ケース 3 では、3 回目のデータは採用していない。
表 3.4.3-09 分散レンダリング時間検証結果一覧

VPN マウント型
測定値

基準時間

PC1 台でのデータ転送型
測定値

との比較

基準時間

レンダリング

との比較

基準時間

ケース 1

7 分 29 秒

2.6 倍

2分2秒

9.4 倍

19 分 12 秒

ケース 2

29 分 39 秒

2.9 倍

5 分 36 秒

15.4 倍1 時間 26 分 27 秒

ケース 3

9 分 50 秒

3.5 倍

4 分 19 秒

8.1 倍

34 分 45 秒

3.0 倍

平均

11.0 倍ローカル側のファイルサーバとクラウドレンダリング環境を VPN 接続してマウントした状態で、20 台を利用して分散レンダリングを行った場合は、約 3 倍の処理スピードであった。またこの数値は、データセンター側にデータ転送した上で分散レンダリングする場合に比較して 1/3～1/4 の速度向上にとどまっている。
これは、回線状況の不安定さなどによる実効回線速度が、LAN 内のネットワーク速度に比較して十分高速でないためと思われ、この VPN マウントによる形態でのクラウドレン
ダリングの利用は、総合的な所要時間を勘案すると、まだ導入による実効性が確認できる
状況にはないと考えられる。

(2)

高速サーバの検証「3.3.2 VPN 回線」で述べたように、高速サーバの検証を試みたが、今回の実験環境
ではクラウド側に高速サーバを設置出来なかったことから、充分な検証が出来なかった。
それでも、東映アニメーション株式会社側でのファイルサーバとしてはレスポンスの良さを体感することが出来た。

（3）Hiero の検証「3.3.4 デジタル合成処理用アプリケーション「The Foundry 社 Nuke」」で触れた進捗管理に関する検証では、進捗管理ソフトウェアである Hiero の持つ可能性を検証した。
もともと Hiero は、共同作業による VFX ワークフローのためのソフトウェアと言われており、EDL などの編集済みリストを元にデータをコンフォーミング（編集作業の再構成）
し、VFX カットを発注先別やアーティスト別に割り当てて管理することで作業の進捗管理を簡素化させるツールとして適している。

70

今回は以下の手順を検証した。
①

データをクラウドサーバ上から直接読み込む②

プレビュー用などの軽いデータは作成せず、レンダリングした DPX を使用③

同条件の DPX をローカルサーバにおき、そこから読み込む

この結果、プロジェクトは問題なく作成、保存できることが確認されたが、再生に関しては、ローカルサーバから読み込んでの再生はうまく行ったが、クラウド上からの読み込
み再生はうまく出来なかった。具体的な原因は究明できなかったが、VPN 回線の設定など
いくつかの問題が考えられる。将来的には合成作業のバージョン管理ツールとして、以下のワークフロー実現を目指した検証作業が必要と考えられる。

図 3.4.3-09 Hiero ワークフロー概念図

3.4.4

VPN を利用しない環境での検証と結果

株式会社 4D ブレインとデータセンターとを、VPN を利用しないインターネット回線で結んで行った検証の実施内容と結果を以下に記述する。

(1)

検証作業スケジュール

本年（2014 年）3 月公開の劇場用作品の実際の作業に利用することで、クラウドレンダ
リングの有効性を試した。公開時期が迫っていたため、実験というよりも納期に間に合わせるためにどうするのか、と言ったまさに実践さながらの検証作業となった。
71

表 3.4.4-01 株式会社 4D ブレインでの検証作業のスケジュール

11 月 14 日

ファイルサーバ 1TB 及びレンダーノード 10 台構築完了

11 月 15 日

株式会社 4D ブレインにて Nuke 用の分散レンダリングマニュアルを使い使用方法を説明

11 月 16 日

Nuke でのクラウドレンダリング開始

12 月 04 日株式会社 4D ブレインより、After Effects でのクラウドレンダリング
環境構築の要請が出る

12 月 11 日

After Effects を使用した分散レンダリング環境を構築し運用開始（レンダーノードを 10 台追加作成）
株式会社 4D ブレインにて After Effects 用の分散レンダリングマニュ
アルを使って使用方法を説明

12 月 25 日

すべての作業を終了
プロジェクトのバックアップ作業に入る

12 月 30 日

(2)

作業終了

ローカル作業環境とネットワーク回線環境

ローカル作業環境とネットワーク回線環境は以下の通り。

図 3.4.4-01 4D ブレイン内のローカル作業環境とネットワーク回線環境図

72

(3)

クラウドレンダリングの検証手順と結果

表 3.4.4-02 クラウドレンダリングの手順と結果

素材

手順

劇場用作品実写（epic4K サイズ、2k サイズ他）
ローカルサーバ↓
Skeed Silver Bullet 経由でクラウドファイルサーバにアップロード↓
クラウドレンダリング（10 台のレンダーノード使用）↓
Skeed Silver Bullet 経由で出力結果をローカルサーバにダウンロード
約5分
約4分
約5分

結果

・アップロード・クラウドレンダリング
・ダウンロード

参考

ローカル環境でレンダーノード 1 台でレンダリングした場合

合計約 14 分
約 40 分転送速度については、平均で 80Mbps という驚異的な数字が出たが、10Mbps の場合もあった。内部環境の再起動で速くなる場合もあれば、回線状態によっては遅くなる場合もあった。レンダリング処理のためのデータのアップロード、およびレンダリング結果のダ
ウンロードにかかった平均時間はそれぞれ約 5 分、クラウドレンダリング（10 台のレンダ
ーノードを使用）に要した時間は約 4 分の合計約 14 分である。これはローカルのレンダ
リングマシン 1 台でのレンダリング時間約 40 分と比較すると、データ転送の時間を加味
しても 3 倍近いスピードが出たことになる。合成処理(コンポジット)系のクラウドレンダ
リングでは、特に画像データの転送における通信速度がボトルネックになると予測されたが、今回のように比較的安価な通信環境においても複数台での同時レンダリングを行うことで、充分に実用的な結果を得ることが実証できた。
4K 映像のクラウドレンダリングに関しては、ほぼ問題なく作業が完了したが、5K 映像の場合にレンダリングスピードが著しく低下するという現象が発生した。この原因としては、レンダリングノードに使用したマシンスペックが要因のひとつと考えられる。今回使用したマシンスペックは、CPU(Intel Xeon X5675 3.07GHz×2) / memory 8GB RAM であったが、5K の場合は memory 12GB RAM〜16GB RAM 程度が妥当と思える。
上記の結果のようにクラウドレンダリングでは、データのアップロード、ダウンロードに要する転送時間という負の要因を克服するためには、複数台マシンの同時使用による分散処理が必須となるが、そのためにはマシンのスペックや台数、加えてそれに対応するライセンスの用意が必要となり、こうした要素が直接運用コストに影響してくるため、データのボリュームなど、作業量に合わせた適切な機器の選択と台数の確保が重要となる。
(4)

VFX 映像制作会社の感想

以下に今回実際に作業を担当した「株式会社 4D ブレイン」の感想を記す。
73

小規模の制作プロダクションやインハウススタジオのような作品単位での CG・VFX 制
作の現場において、作業に使用するマシンやライセンスの確保は必須となる。だがレンダ
リングマシンの保有に関しては、一定の台数以上に潤沢に揃えることがそもそも難しい。
通常のレンタルマシンサービスなどの利用に関しても、ハイエンドな CG・VFX の制作においてはハイスペック CPU 及び大容量メモリを必要とするため、短期での利用はコスト
パフォーマンス的に厳しい。こうした状況において、クラウドレンダリングのように一時的に複数台での作業環境が確保できるサービスの存在は、プロダクションコストの抑制やスケジュール短縮の上でも非常に有用であると言える。特に長時間レンダリングを必要とするような CPU 負荷の高い CG 映像のレンダリングについては、一度に何百台ものマシンを使い短期間でレンダリング結果が得られることは大変ありがたい。
今回は Nuke を使った合成処理のレンダリング実験であったので、クラウドの使用に当
たっては社内のアセットマネジメント、データのアップロード、ダウンロードなども含めた通信環境の整備が重要であった。例えば、クラウドの運用開始直後に、契約しているプ
ロバイダーのアップロード容量制限に引っかかり、作業がストップする事態が発生した。
急遽プロバイダーを変更したり、社内ルータやスイッチャーを買い替えたりするなど、プ
ロジェクトを進行させながらの対応となったが、些細なところでも色々と経験値が得られ
た。

課題と提案

3.5
3.5.1
(1)

課題

使用する通信回線での課題

最初の重要な課題は通信回線の問題となる。一般的には 100Mbps ベストエフォートタ
イプが普及しているので、現状ではこれを前提にせざるをえない。この回線を最大限有効活用することが重要だが、同時にこの帯域以外の回線についても検討する必要がある。
こうした問題の検討のためには以下の点に注意をする必要がある。

(a) インターネット回線業者の選定
今回の実験で検証した NURO 回線（1Gbps ベストエフォート）は、利用しやすい価格帯であり、十分検討に値する回線と言える。業務用としての価格（2013 年 10 月現在）は
NURO アクセススタンダード（基本使用料金）で月額 18,857 円である。
ただし、この回線は利用可能な地域が限定されているため、今後の利用地域の拡大が期待される。また、その他のプロバイダーがより高速な帯域を安価に提供して行く流れが加速して行くことも期待したい。

(b) それぞれの企業内のルータ設定の最適化
今回の実験で、転送速度の阻害要因の一つが、各企業に設置してあるルータにあること
74

が判明した。インターネット回線を受けるメインルータやそこからの社内 LAN 用への分
配用ルータの設定の不備が数多く見受けられた。運用形態に合わせてルータの設定を変更することによって、転送速度が改善される事例や、古いルータから新しいルータへの入れ替えによって改善した事例もあった。ルータの最適化が重要な要素であることを再認識した。

(2)

ユーザーの使いやすさとしての課題

データのアップロード、クラウド上でのデータ共有とレンダリング、そしてデータのダ
ウンロードといった一連の操作が安易にできることが望ましい。

(a) 転送ソフト Silver Bullet の操作性の向上
Silver Bullet を利用することで転送速度が安定することが判明したが、操作性の向上のためには、映像データの転送に特化したアプリケーションの開発が望まれる。可能であれ
ば、それぞれのユーザー固有のカスタマイズが可能な環境が構築できることがさらに望ま
しい。

(b) 分散レンダリングソフト Render Spice の操作性の向上
Render Spice を用いた分散レンダリングが有効に機能していることが判明したが、操作性の向上のためには、操作性と効率的な分散処理の両面での改良が求められる。そのためには更に多くのユーザーの要望を聞き出す努力が必要となる。

(3)

VPN 環境の有効性と課題

データのセキュリティ面を考えると、VPN 環境は効果的な手段と言える。
今回テストしたハードウェア VPN ルータは、想定していた転送速度まで到達することが出来なかった。改善の可能性はあるため今後に期待をしたい。
参考までに今回の実験で使用した VPN ルータのコスト（2013 年 10 月現在）は以下の通り。
・データセンター側ルータ費用（レンタル料金）

月額 9,000 円

・東映アニメーション側ルータ費用（レンタル料金）

月額 18,000 円(4)ライセンス契約での課題

現状でのソフトウェアライセンス契約のほとんどが期間を限定（1 ヶ月など）して許諾を与える方式になっている。また、レンダーノードの台数分のソフトウェアライセンス取得を事前に申請することが求められているケースが多い。この契約形態ではコスト面での負担が大きく、クラウドレンダリングサービスの実情に適合していない。なぜならクラウ
ドレンダリングのメリットは、短期間に多くレンダリングノードを使って処理が可能な所
75

にあるからである。ユーザーにとっては、必要な時に必要な台数のレンダリングノードが確保出来れば良く、料金は実際の使用時間で支払うことができれば利用しやすい。
他方、クラウドレンダリングサービスを提供する側にとっては、現状のライセンス契約の形態ではコストがかかりすぎてビジネスとして成立しにくい状況にあり、ライセンス契約の見直しが必要と考えられる。
今回実験に協力してくれた The Foundry 社の Nuke はこうした考え方にに前向きなた
め、今後に期待したい。

(5)

データセンターの利用における課題

クラウドレンダリングサービスを利用する上で最も費用がかかるのが、データセンターの利用費用である。今回の実験では、ファイルサーバに関しては月単位と時間単位の両方の料金形態を組み合わせて利用し、ストレージについては時間計算で利用した。合成作業の場合は CG 制作作業よりも、使用する素材のデータ量が多くなる。一方、ファイルサー
バとストレージの現在の利用価格は、映像業界のポストプロダションにとっては決して安くはない。とりわけデータ共有などに利用するストレージは、合成作業の場合はテラバイ
ト（TB）単位を数ヶ月利用することが多いため、現状では利用しにくい価格設定となっている。そのため価格の低下は切実な課題となっている。また、レンダーノード用のマシンについても同様に現在の利用料金は高価なものとなっている。データセンターの利用料金の低価格化が熱望される。下記に、今回利用した IDC フロンティアの利用価格（2013 年
10 月現在）をあげておくので、参考にされたい。
表 3.5.1-01 IDC フロンティアの利用価格

ファイルサーバ

時間計算（1 時間）¥17.85（1CPU/4GB メモリ）

月額固定費用

¥10,400

ストレージ費用
（従量制）

1GB

1 時間

¥0.084500GB

1日¥1,008

500GB

30 日

¥30,240

1TB

1日¥2,016

1TB

30 日¥60,480

時間計算（1 時間）¥32.55

停止時計算（1 時間）¥16.28

時間計算（1 時間）¥92.40

停止時計算（1 時間）¥46.20レンダーノード

2CPU/8GB メモリ

レンダーノード

4CPU/16GB メモリ

76

3.5.2(1)

提案

クラウドレンダリングサービス提供者への提案

ユーザーにとって利用しやすいクラウド環境を構築して行く上で、以下の点を解決して行く必要があると考えられる。

(a) ユーザーサポート環境の構築
クラウドとのデータのアップロード、ダウンロードが容易に出来て、ユーザー自身が使っているインターネット回線をさらに有効に使うためのサポートをする環境が必要。
具体的には以下の取り組みが有効と考えられる。
①

クラウドサービスを利用するユーザーそれぞれのインターネット環境を最適化するための調査及び改善提案をサービス業務に組み込む。

②

個々のユーザーが使いやすいデータ転送用のアプリケーションを提供できるようにする。

(b) 利用価格の明示
クラウド上でデータ共有のためのファイルサーバとストレージを使う場合の価格が明示されていることが必要。具体的には以下の取り組みが有効と考えられる。
①

利用したいファイルサーバのスペックを一覧表示し、それぞれの利用価格を月額使用価格と従量課金（時間単位）で明示する。

②

利用したいストレージ容量の使用料金が一覧表示され、増設が簡単にできるようにする。

(c) 時間と費用のシミュレータの構築
レンダリングサービスにおいては、ユーザー自身が実行しようとするプロジェクトの費用を予測できる機能が必要。具体的にはユーザー自身が実行しようとするレンダリングプ
ロジェクトの 1 フレーム当りのレンダリング時間をもとに、レンダーノードのスペックと台数を指定して総フレーム数を入力すると、概算レンダリング時間と費用が表示される様なシミュレータの構築が求められている。

(d) マニュアルの整備
クラウドレンダリングの特徴である分散レンダリングを、ユーザー自身がより簡単に実行できる環境を構築することが必要。そのためのシステム構築はもちろん、ユーザーが理解するためのマニュアルの整備も重要である。そのため今回の実験で作成した操作マニュ
アルをさらに改良し、ユーザーの要望を反映したより使いやすい形に仕上げて行く必要がある。

77

データセンターへの提案(2)

クラウド上でデータ共有を行うためにはファイルサーバとストレージは必須のものとなるので、この価格設定が重要である。小規模の制作プロダクションを取りまとめて利用することでクラウドサービスの需要が拡大すれば、運用価格の低価格化につながると考える。
レンダーノードに関しては価格の低下とともに、CPU やメモリ等のスペックの選択が自由にできることが望ましい。
具体的には以下の取り組みが有効と考えられる。
①

レンダーノードの基本価格を下げると同時に、利用台数の増加に応じた低価格設定があることが望ましい。
CPU やメモリ等スペックの選択が簡単に出来、その利用金額が表示されることが望ま

②

しい。
③

レンダーノードの停止に対応する価格の考え方は存在するが、レンダリング作業をしていない時間についても、待機価格という料金体系があると望ましい。

ソフトウェアメーカーへの提案(3)

レンダリングライセンス契約の工夫が必要。具体的には以下の取り組みが有効と考えられる。
①

ライセンス契約期間は固定とせず、実際に使用した時間に対する課金方法とすることが望ましい。

②

レンダーノードの本数の増減に関しては、これも使用実績に応じた課金とすることが望ましい。
以上により、緊急時にレンダーノードを柔軟に増設することが可能となり、利用しやす

くなる。

3.6

操作マニュアル作成についてユーザーがクラウドレンダリングにかかわる操作を自身で実行できる様にすることが、クラウドレンダリングを普及させる上で重要である。そこで、今回の検証では実際にユーザー自らが実行できる環境整備を目指し、Silver Bullet および Nuke の操作マニュアルを作成した。詳細は、【第 3 章参考資料】に掲載したので、それを参照されたい。

78

第4章

WG3：クラウドサービスを利用した CG データ共有化による UGC サイクル活性化動向調査

4.1

調査概要

WG3 では、二次利用及び改変利用が可能な 3DCG データを、一定のルール（「コンベンション」と呼ぶ）に基づいて WEB 上で公開し、ユーザーの二次利用促進の可能性を調査した。その際ユーザーは、コンベンションに抵触しない限り断りなく無償でデータを使用できるものとした。並行して、3DCG データのオープン化（公開による資産共有化）のためのコンベンション定義、及び 3DCG データの著作権の扱い方についても調査を行った。

4.2

WG3 の目的

3DCG は、現在は映画やテレビ番組、アニメなどに利用されているが、今後は 3D プリ
ンターの発展等により、さらにその利用価値が高まることが期待されている。すなわち
3DCG は広い領域での経済効果が期待できる技術であり、本来再利用性、利活用性の高い
データ資産である。しかしながら一般的に、3DCG を制作している制作プロダクションは、受託による事業形態をとるため、制作した 3DCG データの著作権を保持しないことが多い。
その結果 3DCG データのオープン化の事例は非常に少ないものとなっている。その一方、同じくデータ資産として捉えられるソフトウェアのプログラムソースコードについては、
昨今オープンソースの思想が一般的に受け入れられ、オープン化に関して一定の成果を上げている。
またアマチュアの世界では特定のコミュニティでの 3DCG データの UGC（User
Generated Content：ユーザーによって制作されたコンテンツ）活動が盛んになってきて
おり、UGC によって制作されたデータ資産をコミュニティ内で蓄積し、再利用する活動が行われつつある。
そこで、その 3DCG データの UGC 活動に着目し、制作された高品質な 3DCG データ
を、利用規約の範囲内であれば断り無く使用できる状態で一般公開し、データ資産の蓄積を行うスキームを構築することにより、業界全体の生産効率性を高め、業界外においても3DCG データによるクリエイティブ活動が活性化すると仮定し、調査を行った。
なお、ここで想定するクリエイティブ活動とは、以下の図で示すクリエイティブサイク
ル構想を指している。本事業においては、このクリエイティブサイクルのうち、インフラとして CG・VFX 産業に大きく貢献できると考えられる、「データ共有の場」に関しての調査を行った。

79

図 4.2-01 3DCG コンテンツクリエイティブサイクル構想

調査内容

4.3

WG3 では、3DCG データの蓄積と共有に必要となる、コンベンション（ルール）の統一化に関する調査、3DCG データの著作権調査、著作権の利益を放棄することが可能な
3DCG モデルデータの収集、データ公開用の WEB サイトである Ark Project（http://www.ark-project.jp/）によるデータ公開活動の調査を行った。なお 3DCG データの WEB 上での公開については、データ利用のトレーサビリティの高さを評価し、WEB
上でプロジェクトやソースコードのバージョン管理を行うシステムである Github（https://github.com/）を利用した。

調査結果

4.4
4.4.1
(1)

3DCG データにおける著作権について

3DCG データにおける著作権についてWG3 では、データを公開するにあたり、クリエイティブ・コモンズ・ライセンスを採用した。クリエイティブ・コモンズ・ライセンスを利用することで、作者は著作権を保持したまま作品を自由に流通させることができ、受け手は「表示」「非営利」「改変禁止」「継承」といった条件の範囲内で再配布や改変などをすることが可能となる。クリエイティブ・
コモンズ・ライセンスについては、様々なデジタルコンテンツにおいて採用例が多く、認知度も高いため、3D データの著作権定義において利用者の認知促進に効果が高いと判断し、本調査におけるデータ公開において採用した。こうしてクリエイティブ・コモンズ・80

ライセンスに基づき、データ提供者が自由に条件を決定できるようにした。
3DCG データはその性質上、複数の著作物から成り立つことが多い。そこで制作プロダ
クション側の権利である「CG データ」とキャラクタデザインをした制作者の著作権を明確にするため、「キャラクタデザイン」と「CG データ」に分けた状態でライセンス表記を行うことを推奨するものとした。なお、ワーキンググループ内では、「CG データ」についてもさらに著作権を細分化して定義する必要があるという意見もあり、今後継続した議論が必要と考えられる。
データを共有し、二次利用するためには、著作権についての考え方が極めて重要なものとなるが、これまで 3DCG データそのものについて明確な著作権が定義されたり、または議論されたりした事例は非常に少ない。特に制作過程における中間生成物については著作権の捉え方が難しいため、その二次利用に関する考え方は各社で大きなばらつきがある。
しかしながら中間生成物の著作権を明確に定義できれば、これまで制作活動上で再利用することが困難であった中間生成物を制作プロダクション側の資産として捉えることができるようになり、中間生成物自体のデータ販売サービスをすることや、3D プリンター等のビジネスに利用するなどが考えられる。

(2)

クリエイティブ・コモンズ・ジャパン NPO 法人コモンスフィアからのコメント

クリエイティブ・コモンズ・ライセンスの採用を行うにあたり、クリエイティブ・コモ
ンズ・ジャパン NPO 法人コモンスフィア 常務理事である渡辺智暁氏へのヒアリングを実施した。そのコメントを下記に記載する。

(a)

CG データの共有と著作権の扱いについて

3DCG データの共有に当たっては、著作権の扱いに留意する必要がある。創作物の共有に関して一般的にあてはまることだが、3DCG データも、共有に当たっては著作権の扱いを間違えると著作権侵害が起きる可能性がある。

(b) 法的な事情：他人の著作物は無断で利用できない
著作権法の大原則は、他人の著作物を無断で利用してはいけない、というものである。
著作権法にはこの原則に対する例外も多く含まれているものの、社内利用や様々な非営利利用なども含めて、一般人の感覚に照らして問題ないと考えられるような行為や、広く行われている行為が違法であることもある。検索エンジンを合法にするための例外規定が導入されたのは 2009 年の著作権法改正であり、それ以前は違法ともとれる状態にあった。
他人のウェブページを職場のプリンターでプリントアウトするなどは、今でも合法とは断言し難い状態にある。

(c) 著作物の範囲の広さ
日本の著作権法では、著作物は思想や感情の創作的な表現とされる。表現が保護の対象
81

なので、そこで表現されているアイディアそのものは著作物とはみなされない。他人のアイディアを盗用することは、少なくとも著作権法には反することがない。ただし、何がアイディアで何が表現かを厳密に区別することは難しい。小説の言葉の使い方は表現で、これを無断でコピーすれば著作権侵害になるだろう。だが、言葉づかいを少し変えて話の運びなどがすべて同じだったらどうか。これも「内面的な表現形式」をコピーしたとして著作権侵害として判断される可能性がある。
創作的でない表現であれば、他人の表現であっても無断で利用しても、著作権法に反することはない。創作的でないというのは、ありふれている表現や誰がやっても同じになる
ような表現である。ただ、ここでも注意が必要で、ある表現が創作的であるためには独創的であるというようにレベルの高さを求められるわけではなく、裁判例によっては、かな
り凡庸な表現の類でも著作権を認めている。
3DCG データの中には写実的なものも考えられるところだ。写実的であれば誰がやっても同じようなものになるため、創作性が認められにくくなる傾向はあろう。だが、写真の著作権についての判例を見ると、構図や照明などに撮影者の創作性を認めるものもあるので、断言はしづらいだろう。なお、今日の天気や物理法則、コップに入った水の様子など
事実そのものについて著作権が認められることはない。

(d) 共有のためのツールとしてのライセンス
著作権を無断で利用すると問題になるが、利用してもよいという許諾を権利者が与えることで、問題を回避することができる。オープンソース・ソフトウェアやフリーソフトウ
ェアと呼ばれるように、ソフトウェアの分野ではこのようなライセンスが用いられるのが普通で、最もよく知られたものに GPL (General Public License)がある。
ソフトウェア以外の分野ではクリエイティブ・コモンズ・ライセンスと呼ばれるライセンス群がよく知られ、また用いられている。例えば写真共有サイトの Flickr にはクリエイ
ティブ・コモンズ・ライセンスの下に提供されている画像がおよそ 3 億点存在している。
また、データの共有に関しても、昨今、日本、欧米諸国をはじめ世界の様々な国や自治体で実施されているオープンデータの取り組みの際に、クリエイティブ・コモンズ・ライセ
ンスが採用されることがある。具体的にはオーストラリア、ニュージーランドが採用し、また、フランスやイギリスは、独自のライセンスを策定したものの、それらのライセンスがクリエイティブ・コモンズ・ライセンスと互換性を持つように配慮した内容となっている。
(e)3DCG 共有の取り組み例

クリエイティブ・コモンズ・ライセンスによる 3DCG の取り組み例が、海外には存在している。比較的小規模なものでは、数十点程度のモデルを提供するサイトがある。個人や特定の会社などによる提供で、5 年程度の活動実績があるものもある。
その一例は Free 3D Models < http://free3dmodels.org/> である。このサイトは、商業利用を許諾範囲から除外する、クリエイティブ･コモンズの表示・非営利ライセンス(CCBY-NC)と呼ばれる種類のライセンスを用いている。建造物、インテリア、アクセサリー
82

など 40 点ほどの作品が提供されている。
Scopia <http://resources.blogscopia.com> でも同様に 100 点ほどの作品が提供されており、ライセンスはクリエイティブ・コモンズ 表示ライセンスになっている。これは営利利用も含めた幅広い利用を許諾するライセンスである。クレジット表記が主な利用条件となっている。
著名な企業の中では、2014 年 1 月にはホンダが自社自動車の 3DCG モデルを CC BY-NC
ライセンスで提供している。
（ただし販売されているモデルではなく、コンセプト・モデル
を 3DCG モデルにしたものである。
）これは 3D プリンターの普及を踏まえたものである
ことが、プレス発表からは伺える。
コミュニティの活動を形成する求心力を秘めているという点で興味深いのは、Blender
Foundation < http://www.blender.org/> であろう。Blender は 3DCG アニメーションの製作ツールで、従来商業ベースで販売されていたものを、クラウドファンディングを通じてオープンソースとし、さらにそれをサポートするための非営利組織として Blender
Foundation を設置したという経緯がある。 アムステルダムを拠点とするこの団体は物理的スペースとしてのスタジオも所有し、さらにこれまでにこのソフトウェアを利用したショート 3DCG アニメーションフィルムの製作を 5 本手がけている。製作されたフィルムもクリエイティブ・コモンズ・ライセンスで提供されており、また、ウェブ上では映画の素材にあたるデータも同様にオープンにライセンスされたコンテンツとして提供している。
選択されているライセンスは、クレジット表記を主な利用条件とするタイプで、クリエイ
ティブ・コモンズ・ライセンスの中でも最も利用者の自由度が高いものである。これら映画製作プロジェクトはまた、製作ツールである Blender の機能拡張の機会としても活用され、映画の製作を通じてソフトウェアのコードベースも充実してきている。 こうした映画
製作にかかる費用は DVD の売上げや助成金などを含め様々な収入源を組み合わせることでまかなっており、映画作品やそのベースとなるコンテンツを含めたオープン化を実現している。
Ark Project とは方向性が異なっているものの、示唆的な事例としては、近年注目を集めるに至った 3D プリンターをめぐるデータ共有であろう。
立体構造を持った物品のデータの共有に広く用いられているサイトとしては、Thingiverse <http://www.thingiverse.com/> が知られている。このサイトは誰でも投稿できるユーザー投稿型のサイトであり、2013 年夏には投稿総数が 10 万件を超えるに至っている。このサイトは、YouTube のようなほかの分野の投稿型サイトと同様、外部のプロジ
ェクトや団体がレポジトリとして利用する例もある。ライセンスは GPL や、各種クリエ
イティブ・コモンズ・ライセンスの中から投稿者が選択できるようになっている。同サイ
トにはカスタマイザーと呼ばれる 3D オブジェクトのデザインをサイト上で加工・再投稿する機能も用意されている。3D プリンターなどを販売もしている Makerbot Industriesという企業が運営するサイトである。

83

4.4.2(1)

3DCG データのコンベンションについて

3DCG データのコンベンションの必要性
データの二次利用を促進するためには、一定のコンベンションに基づきデータ蓄積を行うことが効率的であり、本事業の中で、3DCG データ共有化を実現するための 3DCG デー
タのコンベンションを策定した。
また将来的に 3DCG モデル（形状）データだけではなく、モーション（動き）データの再利用までを考慮したコンベンション定義を行った。3DCG データのコンベンションの定義を行う上で、3DCG データフォーマットの選択が重要な意味を持つが、今回は汎用性を持ち、かつ多くの情報量を保持することが可能な Autodesk 社の FBX フォーマットを採用した。UGC 活動で一般的に利用される MMD フォーマットは、プロフェッショナルワークで使用されることが非常に少ないことから採用を見送った。
3DCG データのコンベンションについては、業界内においては、各社ごとに独自のルールを採用するケースが多いが、ベースとなるルールは非常に近い仕様となっており、独自性による優劣は少ないものと考えられる。しかしながら各社で独自のコンベンションを適用した、オリジナル制作管理ツールを開発し運用しているケースも多く、軽微なものであってもコンベンションを変更することは開発コストを考えると容易ではない。また今までに自社で制作したデータを自社内で再利用する際にも、コンベンションの変更は障害となる。これらの事情により、本来であれば、業界全体でコンベンションの統一を行うことが重要であると認識されているにもかかわらず、コンベンションが統一されていない。そのため比較的変更が容易なネーミングコンベンションをベースとして、Ark Project における「3D モデルデータコンベンション」を策定した。なお、コンベンションは今回定義を行ったものを v1.0 とし、今後も継続してバージョンアップを行っていくものとする。

(2)

3D モデルデータコンベンション（v1.0）(a) 目的と概要
Ark Project において 3D データを公開するにあたり、利用者がデータの内容、状態の把握、及び機械判読を容易とするために、コンベンションを策定する。

(b) コンベンションにおける基本方針
コンベンションの策定にあたり基本方針とした事項を以下に列記する。
・

データの著作権情報を明確にするため、ライセンス情報を同ディレクト

リに配置することを推奨する。
・

利用者がデータの内容、状態を把握するためのドキュメント情報及び機械判読を容易とするためのメタ情報を同ディレクトリに配置することを推奨する。
・

ファイル名、ディレクトリ名については、機械判読の効率性を優先し、日本語名（2 バイト文字）は使用せず、アルファベット名（1 バイト文字）を使用することを推奨する。
84

・

コンベンションにおいて、3D データフォーマットについての定義は行

わないものとする。ただし当プロジェクトにおいては FBX フォーマットにてサンプ
ルデータを公開するものとする。

(c) コンベンション定義を行う 3D データの範囲
本プロジェクトでコンベンション定義を行う 3D データは下記のものを想定する。
・

オブジェクトモデルデータ（ジオメトリデータ）

・

テクスチャデータ・

シェーディングデータ

・

リギングデータ・

アニメーションデータ
なお、今後の活動として以下のコンベンション定義についても包括することを想定する。

・

シーンデータ（オブジェクト配置データ）

・

ライティングデータ

・

カメラデータ(d) ディレクトリストラクチャについて複雑化する複数のファイルデータを機械判読に適した形で効率的に管理するため、決められたディレクトリーストラクチャ（階層構造）を持つことを推奨する。

(e) 推奨するディレクトリストラクチャ+root---------------------------- ルートディレクトリ

+ model/ -------------------- 3D モデルデータ配置ディレクトリ
+ tex/-------------------- テクスチャデータ配置ディレクトリ

+ anim/-------------------- アニメーションデータ配置ディレクトリ

Document.txt
Metadata.xml
License.txt
Thumbnail.png
基本ファイルについて(f)

ルートフォルダ直下には、以下の 4 種類のファイルを置き、利用者が内包するデータについての概要を把握できるようにする。

①

Document.txt

・

制作者名
85

・

制作日

・

更新日

・

ファイル構成

・

制作者情報

・

データファイル出力環境情報

・

3D データフォーマットのバージョン情報②

Metadata.xml
機械判読に適した XML 形式において、下記の情報を記載する。

・

メタ情報のバージョン

・

制作者名

・

ライセンス情報

・

制作日

・

更新日

・

データファイル出力環境情報

・

3D データフォーマットのバージョン情報③

License.txt
公開されるデータがどのような著作権を持っているかの情報を記載する。

④

Thumbnail.png
公開されるデータのサムネイル画像ファイル（800×800 を推奨）(g) ファイルネーミングコンベンション

表 4.4.3-01 ファイルネーミングコンベンションの具体例

ファイルネーミングコンベンションの形式

大崎一番太郎のファイル名<Category>_<Original Name>_<LOD>.拡張子

CH_Osakitarou_MD.fbx

Category①

下記の定義に基づき 3D データのカテゴリ（種類）を記載する。
・

CH（キャラクタ 3D データ）

・

ST（背景 3D データ）・

PR（小物、乗り物等のプロップ 3D データ）②

Original Name
オブジェクト名称を記載する。任意のオリジナルファイル名を、先頭の文字を大文字に
86

（キャピタライズ）した状態で記載する。ただし、機械判読性を妨げるため名称内でのアンダースコア「_」の使用は禁止する。
LOD③

下記の定義に基づき、データがもつ粒度情報を記載する。
HI（ハイモデルの略称：一般的にプリレンダリング CG において使用を想定されるモ・

デルデータ。1 万ポリゴン以上の精細な粒度を持つ。）
・MD（ミドルモデルの略称：プリレンダリング CG からリアルタイムレンダリング CG
用途まで幅広く使用されることが想定されるモデルデータ。2 千から 1 万未満ポリゴ
ンの粒度を持つ。）

・ LO（ローモデルデータの略称：主にゲームや WEB 等で使用されるリアルタイムレン
ダリング CG への使用が想定されるモデルデータ。2 千未満ポリゴンの粒度を持つ。）

4.4.3

Github によるデータ公開及び計測についてWG3 では、Github を利用してデータの公開を行った。Github とは、バージョン管理機能を持った、プログラムソフトウェア開発プロジェクトのための共有ウェブサービスである。Github を採用した理由は、オープンソースの共有プラットフォームとして認知度が非常に高いこと、フォーク機能（公開されたデータを公開者以外の他者が改変し、新たに Github 上に別のデータとして公開することができる機能）を持つこと、公開データのトレーサビリティが可能なプラットフォームであるなどである。なお Github と併用する
形で以下のサイトを立ち上げ、データ公開に対する告知とアクセス数などの計測を行った。
・データ公開告知用のウェブサイト（http://www.ark-project.jp/）
・Facebook ページ（https://www.facebook.com/pages/Ark-Project/240722439422511）
なお WG3 において公開された 3DCG データ及び計測結果は以下の通りである。

87

(1)

大崎一番太郎（大崎西口商店街提供）

図 4.4.3-01 大崎一番太郎

大崎一番太郎については、モデルデータもデザインも CC0 のライセンスで公開された。
CC0 とは、クリエイティブ・コモンズ・ライセンスの定義で、「いかなる権利も保有しない」という意味を表している。
CC0 とは、科学者や教育関係者、アーティスト、その他の著作権保護コンテンツの作者・所有者が、著作権による利益を放棄し、作品を完全にパブリック・ドメインに置くことを可能にするもの。CC0 によって、他の人たちは、著作権による制限を受けないで、自由に、作品に機能を追加し、拡張し、再利用することができるようになる。
（参考）http://sciencecommons.jp/cc0/about・ 2014 年 1 月 25 日にデータ公開
・

モデルデータライセンス

・

デザインライセンス

CC0

CC0

公開された大崎一番太郎の 3DCG データを利用した二次創作物が動画投稿サイトに投稿されるなど、大崎一番太郎コミュニティにおいての活動が活発化した具体的事例も生まれている。このように利用規約の範囲内であれば断り無く使用できる CG データが増える
ことにより、二次創作だけでなく、CG データが一般的に利用されるゲームやアプリなどのサービスへの活用や展開についても期待される。

①

計測結果

・

Ark Project（公開後 3 日間）・

WEB ページビュー数

560PV（通常 10〜20PV／日）

GitHub（2014 年 3 月 12 日時点）
WEB ページビュー数累計

235PV
88



②

ユニークユーザー数（利用者数）122 人

参考情報
Impress Watch において「大崎一番太郎 3D データ公開」記事として取り上げられる。
記事ツイート数 155 （2014 年 3 月 12 日時点）。
※ Impress Watch における記事ツイート数は通常 20〜30 が目安
http://internet.watch.impress.co.jp/docs/news/20140131_633208.html③

ユーザー活用事例

・「大崎一番太郎を blender で弄っていたり」
ユーザーにより Blender で出力されたレンダリング画像が再配布可能な形で公開された。
http://blawat2015.no-ip.com/~mieki256/diary/201402021.html

・「大崎一番太郎とニシナガレで Love&Joy」
ユーザーにより、公開された CG データを活用したムービーが作成され Youtube へ投稿された。
https://www.youtube.com/watch?v=HqcRl8Dq8zw&feature=share

・「【MMD】大崎一番太郎がみっくみくにしてやんよ！」
ユーザーが公開した FBX モデルを MMD モデルへコンバートを行い、ニコニコ動画に映像が投稿された。）
http://www.nicovideo.jp/watch/sm23067946④

大崎一番太郎

キャラクターデザイナー

犬山秋彦氏のコメント

3DCG データが公開された直後にネットニュースで取り上げられたおかげか、ニュースが掲載された当日に NHK から「クリエイティブ・コモンズに関する下取材を行っている」という電話と、品川経済新聞からの取材依頼が来ました。また、知的財産関連のサービスを掲載するパテントサロン（http://www.patentsalon.com/）でも、大崎一番太郎のニュースがネットで取り上げられるたびにリンクが貼られるようになり、著作権に関心のある
人々から今回の試みが注目されているのは間違いありません。
また J タウンネットの「ご当地キャラ「大崎一番太郎」著作権放棄という挑戦の重要さ」という記事（http://j-town.net/tokyo/sanpo/sanpocolumn/094883.html）では日本が TPPに正式参加した場合、「著作権の非親告罪化」によってもたらされる諸問題の解決策として「CC0」の可能性が紹介されています。
さらにファンからの反応としては、大崎一番太郎はこれまでもクリエイティブ・コモン
ズ・ライセンスに基づいて著作権を一部開放していましたが、「著作権放棄」によって一般の人たちにとっては理解しやすくなったようで、自主的に手作りグッズを作りたいと申し出てくれる人たちも増え、作品点数は急速に増えています。さらに、3DCG データは使用されていませんが、「著作権放棄」をした個人の手によって子供用ゲームアプリも作成され89ました。3DCG を使用した例としては MMD 用の PMD 形式に変換されたアニメーション
動画がニコニコ動画と YOUTUBE にアップされ、それによって Twitter のフォロワーの中でも利用したいという声が高まっています。さらに「会社にある 3D プリンターで出力してみたい」など、当初こちらで想定していた使われ方も、自発的に広がっています。
一方で、個人からの反応は非常に良いものの、メーカーの反応はいまひとつで、知り合いのゲームメーカーなどにぜひ使ってほしい旨を伝えても、「本当に大丈夫なの？ 勝手に使って、あとから訴訟されたりしないの？」など半信半疑な反応が多く、さらにキャラク
タ自体の知名度がくまモンやふなっしーほど高くないので、企業側が使うメリットも薄いと判断されてしまっているようです。今後、個人の間で 3DCG の利用が急速に拡大し、大崎一番太郎自身の知名度があがることで、企業による利用が促進できればいいなと期待し
ています。

(2)

蒼姫ラピス（株式会社スタジオディーン提供）

蒼姫ラピスについては、モデルデータは CC0 のライセンスで公開したが、デザインは
CC-BY-NC-SA（非営利目的であり、かつ原作品の条件と同じ CC ライセンスを付けて公開するのであればリミックス・操作・改変を許可するという条件）での公開とした。
・2014 年 2 月 17 日にデータ公開

・

モデルデータライセンス

・

デザインライセンス

CC0

CC-BY-NC-SA

図 4.4.3-02 蒼姫ラピス

①

計測結果：

・

Ark Project（公開後 3 日間）・

WEB ページビュー数

411PV（通常時 10〜20PV／日）

GitHub（2014 年 3 月 12 日時点）
WEB ページビュー数累計

605PV
90



②

ユニークユーザー数（利用者数）325 人

株式会社スタジオディーン

プロデューサー

新間敏雄氏のコメント

株式会社スタジオディーン、および一般社団法人 日本コンテンツ振興機構（CPO-JP）
は、Ark Project へ参加協力し、「蒼姫ラピス」に関する著作権の一部（3DCG データ）を開放することを積極的に推進して参りました。
Ark Project に参加する最大のモチベーションは、映像制作にかかわる制作プロダクシ
ョンと個人クリエイターとの「距離感」を縮め、「新たな接点＝真のクリエイターズ・コミ
ッティやユーザー・コミュニティ」を創出できる可能性があると期待しているためです。
弊社は来年 2015 年に設立 40 周年を迎え、再編消滅を繰り返すアニメーション業界においては「老舗プロダクション」としての地位を堅持することが出来ております。この状況に甘んぜず、現在アニメーション制作の主流になっている「フル・デジタル制作のプロダ
クション・ワークフローの構築」に対し積極的に取り組んでゆく姿勢でおります。
しかしながら、この「フル・デジタルによるプロダクション・ワークフロー構築」には、「クリエイター・リソース」が最も大きな壁となって立ちはだかっております。
「恒常的な
デジタル・クリエイターの人材確保や育成、維持」というのは、最終的な企業内投資として設備投資以上のコストリスクとなるであろうことが懸念事項となっております。勿論、ハリウッド並みの大型映像・映画制作プロジェクトが恒常的に担保されているならば、この問題は最大懸念とは成り得ませんが、日本の映像業界において「それ」を望むべくして構築される企業経営・運営はあまりにも非現実的な状況であることは紛れもない事実であります。
さて、弊社においては、3 年前から「ボーカロイドの事業化」を「新規事業」と位置付
け取り組んでまいりました。今回データ公開を致しました「蒼姫ラピス」もその「ボーカロイド、新規事業」から生み出されたキャラクタです。
その新規事業を進めるにあたり今日まで、最も驚愕した事実として「ボーカロイドを巡る産業規模の急激な躍進」「それを支えるクリエイター・コミュニティの自然発生的成長」の 2 点が挙げられます。特に後者の「クリエイター・コミュニティ＝CGM、UGC」の参
加クリエイターの作品の質（クオリティ）や制作モチベーションは、ある部分においては
我々老舗アニメーション会社を凌駕する勢いで構成されております。
このコミュニティに対し、これまで我々制作プロダクション側が「なんの手立てもなく、
ただ、ただ静観している」のは「コミュニケーションをとるべき言語や知見、場所が不足している」というほかありません。本プロジェクトの主旨は、クリエイター・リソース確保のソリューションの一つとして、クリエイター・コミュニティとの「共有の場」を構築する機会として、大きな期待を寄せられるものであると考えられます。
2014 年 2 月 17 日より Ark Project（http://www.ark-project.jp/）のサイト上にて「蒼姫ラピス」3DCG モデルデータを提供し、その当該データ著作権をフリーにて開放致しました。早々、いくつか「B2B での使用許諾、問合せ」という形で、その効果が具現化しつつあります。
「CG 教材向け素材として使用したい」という教育系出版からの問い合わせも頂
いております。今後は弊社主催の各種イベント（音楽ライブ＆プロモーション、同人系展
91示会）等にて、積極的に B2C やクリエイター・コミュニティ（CGM、UGC）に向けてプ
ロモーションを展開してゆく所存です。

(3)

からす天狗うじゅ（うじゅ製作委員会提供）

からす天狗うじゅについては、マーザ・アニメーションプラネット株式会社の CG ディ
レクターの指示のもと、立命館大学映像学部学生がモデルデータの制作を行い、そのデー
タを公開する予定である。この試みを通して、一般的に業界で使用されるコンベンションに基づきながら学生指導を行う、という教育的側面の成果があった。
モデルデータ、デザインともに CC-BY-NC-SA（非営利目的であり、かつ原作品の条件と同じ CC ライセンスを付けて公開するのであればリミックス・操作・改変を許可するという条件）での公開を行う予定。
・2014 年 3 月下旬データ公開予定

・モデルデータライセンス

・

デザインライセンス

CC-BY-NC-SA

CC-BY-NC-SA

図 4.4.3-03 からす天狗うじゅ

今まで CG・VFX 業界で一般的に利用されているデータの内部構造やコンベンションについて体系化された状態で外部に情報が公開される事例は存在しなかった。今回の活動を通して、業界で一般的に利用されているデータ構造、コンベンションを事例として学びな
がら制作活動が行われたことは、学生指導において非常に大きな効果があったと考えられる。制作プロダクションが新規に学生を採用する際は、入社後にデータ構造、コンベンシ
ョンに関する一定の教育時間を設ける必要がある。しかし上述のような教育が一般化すると、制作プロダクション内の教育にかける時間を削減できる。このように、データ構造、
92

コンベンションを体系化し情報公開を行った上で、教育に活用することは、今後、CG・VFX 業界にとって、即戦力となる人材を確保するための手段として有益であると考えられ
る。

①

立命館大学

映像学部映像学科

中村彰憲教授のコメント

本プロジェクトは、1 ヶ月という期間と、明確な完成形態を共有した上で、進められた。
これは、社会においては、ごく一般的におこなわれることだが、自身の研究を突き詰めるスタイルに慣れた学生にとっては、全く違った視点になる。
CG 制作という極めて特殊な技能を求められる業務内容は、インターンシップすら見つけることが困難という現状において、このように企業と学生が緩やかな形で連携し、何かを実現するというのは、学生にとって大きな学びになる機会を与えることになる。企業にとっても、人を雇用する際、如何にスクリーニングをしても雇用のミスマッチが起こり得るが、このような極小プロジェクトを学生との協力で実施するのは、その学生の就業態度を垣間見ることができる分、ミスマッチを回避しやすい。したがって、今後、ここで培ったモデルを体系化すれば企業にとっても負担が少なく、学生たちにとっても学びの機会が多いという Win-Win の教育環境を築き上げることが可能になると思われる。

4.4.4

データ公開に関するまとめ

Github 上で 3D キャラクタ及びアニメーションデータの公開を行ったところ、特に大崎一番太郎については、公開から 10 日ほどが経過したところで、想定していた第三者による二次制作活動が発表され始めた。利活用性の高い 3DCG データを公開し、それらのデー
タを元に新たな制作活動が行われることは、ゼロから制作を行うことに比べ、比較的容易であるためと考えられる。
またデータ公開の活動に対し、CG・VFX 業界以外から、データを提供したい、または
データを利用したいという問い合わせも発生している。3DCG データの利用価値に対する興味は、業界外にも強くあるため、3DCG データを公開することによるキャラクタのプロ
モーション効果や、映像以外の利用についても一定の需要があるものと考えられる。
こうした一定の効果が認識できた一方、データの汎用性についての課題もある。今回公開されたデータはキャラクタデータとそれに付随するアニメーションデータのみであったが、今後、多くの CG・VFX プロダクションの直接的な生産効率性につなげるためには、キャラクタデータだけでなく、汎用的な人型の素体データ、景観モデルデータ等を数多く収集し、公開する必要がある。

4.5

シンポジウム本事業の外部告知プロジェクトとして、Ark Project を立ち上げ、プロジェクトキック
オフシンポジウムを開催した。
93

シンポジウムでは、司会からのプロジェクトの趣旨説明の後、オープンデータの取り組
みについて庄司昌彦氏（国際大学 GLOCOM 主任研究員、一般社団法人オープン・ナレッ
ジ・ファウンデーション・ジャパン代表理事）から、クリエイティブ・コモンズ・ライセ
ンスによる公開コンテンツの権利処理の取り組みについて渡辺智暁氏（クリエイティブ・
コモンズ・ジャパン NPO 法人コモンスフィア 常務理事）から、東京大学空間情報科学
研究センターにおける情報共有事例について柴崎亮介氏（東京大学空間情報科学研究セン
ター 教授）から紹介いただいた。
また、CG キャラクタの利用事例と問題点について、新間 敏雄氏（一般社団法人 日本
コンテンツ振興機構、株式会社スタジオディーン

プロデューサ）、犬山秋彦氏（キャラクタ研究家／株式会社アイアカデミー「大崎一番太郎プロジェクト」）、秋山貴彦氏（一般社
団法人 VFX-JAPAN 代表理事）、北田能士氏（株式会社冬寂 代表取締役）を交えてディスカッションを行い、CG データの著作権の扱われ方や、今後の CG データを利用したビ
ジネスモデルについての討論、意見交換を行った。
なお、シンポジウムには CG・VFX 業界だけでなく、IT 業界を含む様々な業界からの参加があり、CG データの資産化に関する注目度は業界内外を通して非常に高いものである
ことが推測された。
以下にシンポジウムの実施概要を記載する。
日時：平成 26 年 1 月 25 日（土） 13：00～18：00
会場：東京大学駒場第Ⅱキャンパス（生産技術研究所内）An 棟 301・302 会議室
主催：マーザ・アニメーションプラネット株式会社：一般財団法人デジタルコンテンツ協会：東京大学 空間情報科学研究センター
司会：今村 理人（マーザ・アニメーションプラネット株式会社）
講師：庄司 昌彦（国際大学 GLOCOM 主任研究員、一般社団法人オープン・ナレッジ・
ファウンデーション・ジャパン代表理事）：渡辺 智暁（クリエイティブ・コモンズ・ジャパン NPO 法人コモンスフィア 常務
理事）：柴崎 亮介（東京大学空間情報科学研究センター 教授）：新間 敏雄（一般社団法人 日本コンテンツ振興機構、株式会社スタジオディーン

プ

ロデューサ）：犬山 秋彦（キャラクタ研究家、株式会社アイアカデミー「大崎一番太郎プロジェクト」）：秋山 貴彦（一般社団法人 VFX-JAPAN 代表理事 ）：北田 能士（株式会社冬寂 代表取締役）
参加者：61 名94

図 4.5-01 シンポジウムの模様

4.6

期待される効果

WG3 では、業界内の有識者が集まり活発な意見が交わされた。その中でも一番多く討論がされたのは、CG データに関する著作権の考え方と、制作者の権利の守り方についてである。
データを公開し著作権の利益を放棄するという行為は、CG データに明確な著作権を発生させることが前提となっている。著作権の明確化については、CG 制作者、制作プロダ
クションなどが CG 制作を事業活動として行っていく上で非常に重要な課題として捉えられているが、議論の余地が多い分野でもある。
またシンポジウム等の活動を通して、CG データのオープン化にかかわる活動は業界外の人々にとっても非常に関心が高い分野であることが顕在化した。これまで、CG データ
制作は、映画、CG、ゲーム業界などの限られた業界の中で発展、活用されることが多かったが、3D プリンターや、WebGL などの登場により、立体造形や WEB などを手掛ける業
界においても CG データの資産活用について興味が高いことが伺えた。
今後、こうした CG データのオープン化にかかわる活動が発展することにより、以下の4 つの効果が期待される。

(1)

CG データ生産効率の向上

コンベンションを用いて CG データを一元ライブラリ化することで、CG データの生産95

効率の向上を図ることが期待できる。また一方で今回の事業で公開を行ったキャラクタ
CG データ以外の汎用データ、例えば地形データや、人型の素体データのような、より多くの生産活動に寄与できるデータの収集が必要であることが WG3 で提案された。

(2)

CG データの資産化

今までは制作の受託、つまり役務の提供により事業を行っていた制作プロダクションが、自ら制作したデータ資産、特に中間生成物を活用できるようになることで、新たなビジネ
スモデルが生まれることが期待される。そのためには、これまで中間生成物として著作権が未定義であったものに対し、新たな著作権定義や、利活用方法について議論、検討していくことが必要である。

(3)

CG 制作者の人材育成

業界の発展のためには優秀な人材の育成は欠かすことができない。今回の立命館大学との取り組みのように、業界として一般的であるコンベンションに則った、プロフェッショ
ルが制作した高品質でデータ構造が明確な CG データを教材として利用することにより、
CG データ制作における教育の品質向上が期待できる。また、オープンソースで提供された CG データが誰でも自由に扱えるデータであると認知されることで、身近に CG データを活用する人が増え、今後の CG 制作者人口の拡大に寄与すると考えられる。

(4)

CG データ需要の拡大

CG データは本来、3 次元データを仮想空間上で構築するためのデータであり、従来のコンテンツ業界以外にも活用できるデータである。しかしながら今まではコンテンツ業界の中で制作されたデータがコンテンツ業界以外の分野において活用されることはほとんどない状況であった。今回の活動のような取り組みが増えることにより、CG データの利用価値が業界外にも認知され、その活用範囲が広がり、CG データ制作需要が喚起されることが期待される。

4.7

今後の課題

3DCG データによるクリエイティブ活動の活性化を推進させるためには、下記の 4 つの課題に継続的に取り組む活動が必要であると考える。

(1)

著作権定義の活動の継続

利用時のルールの明瞭性を重視し、クリエイティブ・コモンズ・ライセンスの採用を行ったが、3DCG データは複数の著作者から成り立つ複合成果物であることが多く、どのよ96

うに著作権の定義を行うことができるかという点については議論の余地が多い。今後も継続的に具体的な事例を元に議論していくことが重要であると考える。

(2)

共有化 3DCG データの収集活動の継続

著作権者である複数の企業及び団体から、今回の取り組みに賛同頂く形で 3DCG キャラ
クタモデルデータの提供を頂き、データ公開を行った。モデルデータだけでなく、一部のモーションデータについても同時公開を行っているが、今後は、モーションキャプチャー
によるモーションデータなど、より高品質なデータのオープン化についても期待する声が多い。
また固有のキャラクタモデルデータだけでなく、より汎用性の高いデータを蓄積していくことも重要である。そのひとつとして特に注目されるのが CG 制作過程で生まれる中間生成物であり、中間生成物を利活用することが、今後の CG 生産効率を向上させるための重要な位置づけと考えられる。そのような汎用性の高い中間生成物を収集し、著作権の定義を行うことも今後の課題となっている。

(3)

3DCG モデルデータのコンベンションの定義拡大

3DCG モデルデータのコンベンション定義を行ったが、今後モーションデータの再利用を視野に入れた場合、新たに 3DCG モデルデータのリグや、アニメーションデータのコン
ベンションを定義する必要があると考えられる。

(4)

Github の限界と将来的なデータベースの構築検討（インフラの構築）

データ公開のプラットフォームとして、オープンソースプラットフォームとして一般的である GitHub によるデータ公開を行ったが、3DCG データを扱うプラットフォームとしては容量や、可視化（ビュアー）機能等において多くの制限が発生している。
そもそも Github はプログラムソースコードを共有化するためのプラットフォームであり、3DCG データのような大容量のバイナリデータを扱うことは想定されていない。
Github 上にも 3DCG データを扱うための専用ビュアーが機能として実装されているが、現状では CAD 用に使用される STL フォーマットのみが対象であり、一般的に CG・VFX
業界で使用されるシェーディングデータやアニメーションデータのような高品質なデータを扱うことはできない。
また、データ提供者側より、公開した 3DCG データがどのように利用されたかをトレースできる機能の要望が上がっている。3DCG データの公開を促進するためには、このようなトレーサビリティについても検討する必要があると考えられる。
こうした状況から、将来的には 3DCG データを蓄積・公開するために、より特化したデータベースプラットフォームが必要となることが想定される。

97

第5章

まとめ

VFX や 3DCG などの制作においては、近年の急速なワークフローのデジタル化や映像の高品位化により作業量が増加し、コンピュータの処理能力もさらに高度化が必要になってきており、高い国際競争力を維持するためには、最先端のハードウェアやソフトウェア、さらにはネットワーク環境が必須となっている。世界的に競争力の高い、北米や他の地域と比較して、この分野の国内企業は中小企業が多く、また、それらが集積して環境を利用するような体制にもなっていない。そのため、高い技術力を有していても、国際的な作業の受注や大規模な制作体制を構築することが困難になっている。
こうした問題を打破するためには、この分野における共通基盤として、クラウドサービ
スの環境を整備し、技術力の高い企業がその能力を発揮できるようにすることは重要である。本事業では、実際の映像制作プロジェクトなどに様々なクラウドサービスを活用し、その中から現時点での可能性や今後の課題を探ることを目的とした。
WG1 では、「クラウド基盤を統合した商業映像制作プロジェクトの実施と実用性検証」
を実施し、実際の商業プロジェクトでの活用を想定し、映像加工工程の前半パートでのク
ラウド利用を想定した実証実験を行った。映像加工工程の前半パートであるため、素材の更新が頻繁に行われる。そのため、シームレスなアセットマネジメントとクラウドサービ
スの連携が大きな課題になる。
WG2 では「クラウド運用でのデータ共有と効率的なプロジェクト管理及びクラウドレ
ンダリングの実証実験」と題して、映像加工工程の後半パートでのクラウド利用を想定した実証実験を行った。映像加工工程の後半パートであり、撮影済みの素材データやそれらに対するデジタル処理などが行われるため、一度に大量のデータを送信し、画像処理を行う必要がある。高速でセキュアなデータ転送が大きな課題になる。
WG3 では上記の WG1、WG2 のような従来の BtoB におけるクラウド利用ではなく、CG・VFX プロダクションの財産であるデジタルデータを、クラウドを利用して管理流通させることで新たな収益源を生み出す萌芽的なビジネスモデルを検討した。具体的には「クラウドサービスを利用した CG データ共有化による UGC サイクル活性化動向調査」と題して、プロトタイプのシステムを構築し、CG・VFX プロダクションが制作した 3DCG データを一般に向けて公開し、その利用動向を探るとともに、一連のプロセスにおける課題とその対策の重要性を明らかにした。
本章では、WG1、WG2 の実証実験を制作実証実験として取りまとめ、WG3 を萌芽的な流通実証実験としてまとめを述べる。

98

5.1

制作実証実験（WG1、WG2）のまとめ

5.1.1

安定的かつ高速安価なネットワーク

今回は WG1、WG2 ともに 1Gbps のベストエフォート型の回線を利用した。専用線と比較すれば回線の品質は高くないが、今回の実証実験では十分利用可能な回線速度が出ていることが確認できた。
しかし、データセンターは高速なネットワーク網が整備されているのに対し、CG・VFX
プロダクションの立地条件は様々である。今回利用した回線は、まだサービスを開始してから日が浅いため、利用者もそれほど多くない。そのために十分な帯域が確保できたとも考えられる。常に安定した回線速度を保つのであれば専用線が必要になってくる。
しかし、専用線の敷設は固定費として制作プロダクションに大きくのしかかってくる。
そのため解決策には、「ダークファイバーなどの優遇回線の安価な提供」や「大規模な集積地の整備と誘致」などが挙げられる。
現実的には、すべての素材をネットワークで制作プロダクションから直接転送するのではなく、素材データを一旦、高速な HDD などに記録した上で、データセンターと高速なネットワークでつながれた営業所などに持ち込み、そこからアップロードするなどの方法が考えられる。

5.1.2

セキュアなネットワークの確立と速度

今回、WG2 の実証実験で明らかになったこととして、VPN を利用した通信において大規模な速度の低下が見られたことが挙げられる。CG・VFX プロダクションが送受信するデータは公開前の機密性の高いデータである。そのため、インターネット回線を利用する
場合でも VPN 接続によりセキュアな回線の確立が望まれる。今回、VPN ルータを手配し利用したが、期待した速度が得られなかった。
データのセキュリティに関しては当然確保しなければならない問題である。しかし、一切の危険性を排除して高速の通信を行うのは、コスト的にも非常に高額になる。そのため、セキュリティレベルを一定にとどめながら、速度を優先していくことも考慮する必要がある。また CG・VFX プロダクションがやり取りする素材データが万が一漏れたとしても、問題がないように、暗号化されたデータとそれを復号するキーを別々で転送するなど様々な対策が考えられる。

5.1.3

ファイル高速転送ソフトウェア等の有用性

今回の実験では WG2 において専用ネットワークソフト（Skeed 社 Silver Bullet）を使用した高速なデータ転送を実施したり、クラウドレンダリングの制御システムに専用のシステム（Renderspice）を用いたりして、その有用性を実証した。その結果、これらが有効に作用することが確認できた。
99しかし、これらのクラウドレンダリングを利用するのは現時点ではまだ容易ではない。
そのため、今回は WG2 でクラウドレンダリングの設定に関連してマニュアルの整備も行った。今後はマニュアル整備に加え、データ転送やクラウドレンダリングのテンプレート
化などについても検討していく必要がある。クラウドレンダリングを利用するための十分な速度が確認されたため、その利益を誰もが容易に享受できるように、標準的な利用をより簡潔にすることは重要である。

5.1.4

確実なアセットマネジメントの重要性

今回、WG1 においてはプロダクション段階での利用を想定した実験を行った。そのため、アセットマネジメントシステムを導入している CG・VFX プロダクションに協力を依頼し、アセットマネジメントシステムによりデータセンターとの間で、効率の良いデータの更新、転送を実験した。まとめて高速データ転送サービスなどを利用して送るケースもあるが、特に CG プロダクションでは、アセットが頻繁に更新されるため、データのバー
ジョン管理などを的確に行わなければ、無駄なデータ転送が増加してしまう。WG1 では
アセットマネジメントシステムを利用し、その利用ルールを徹底した中で運用を行った結果、データの差分のみを的確に転送し、複数人の同時アクセスにも耐える仕組みを実証することができた。
プロダクション段階でのレンダリングにおいてアセットのバージョン管理には多くの手間がかかる。特にクラウドサービスを利用する場合は、アセットの管理が重要になる。そのためアセットマネジメントシステムを利用することで、より容易にクラウドレンダリン
グを利用できる可能性が広まると考えられる。昨今では、中小規模のスタジオでも 4K サ
イズのアセットを取り扱う事例が増えてきている。アセットマネジメントを浸透させることで、中小規模の制作プロダクションが初期の段階から積極的にクラウドレンダリングを利用できるようになる。

5.1.5

ソフトウェアのライセンス

クラウドサービス利用の際のソフトウェアのライセンスについては、進展があるものの、まだ大きな課題が残る。特に WG1 が実証実験を行った統合 3DCG ソフトウェアのクラウド対応が待たれる。今回 WG2 で利用した合成用ソフトウェアはすでに正式にクラウド対応となっていたため、実際の商用作品での利用実験も行うことができた。
これらのソフトウェアが正式にクラウドサービスに対応したとしても、そのソフトウェ
アに付随するプラグインソフトウェアについても同様に対応が必要になる。近年では、統合 3DCG ソフトウェアに含まれるレンダリング機能だけでなく、独立したレンダリングソ
フトウェアを利用するケースも増えてきている。利用するソフトウェアを見直し、すでにクラウドサービスに対応しているレンダリングソフトウェアに移行していくのも選択肢のひとつである。また、数多くのプラグインを利用するのではなく、極力それらを利用せずに実現する画作りを目指していくことも、可能性のある対策のひとつである。
100実際に、ソフトウェアがクラウドサービスに対応したとしても、その提供形態についても検討が必要である。ソフトウェアの契約形態には、パーマネントのものや、年間契約、月単位の契約など様々な形態が存在する。クラウドレンダリングに利用するライセンスの数量や期間はあらかじめ、ある程度の予測はできるものの、流動的な部分も多い。そのため、週単位や一日単位、時間単位や出力の尺や枚数単位での利用など様々な契約形態に対する要望がある。また、現在は事前にソフトウェアを契約するケースがほとんどだが、その利用に係る契約に時間を要するケースもある。必要な時に必要な数量だけ利用できるライセンス形態の実現はクラウドレンダリングの普及に大きな役割を持つと考えられる。

5.1.6

クラウドレンダリングの提供価格

ソフトウェアのライセンスの話題のほかに、クラウドレンダリングサービスやストレー
ジなどの料金体系などについても、普及のための大きな課題である。現状のクラウドサー
ビスや遠隔レンダリングサービスの料金情報や、自社でサーバを運用する場合のコストの検討を WG1 で実施した。
レンダリングサービスに際しては、事前にサーバの設定と予約を行い、その設定を有効にして実際に稼働させている際の料金と、いつでも稼働できる状態にしておく際の 2 階建ての料金体系がある。これに加えて、いつでも稼働できるがレンダリングを実際にしていない待機状態の料金を設定することで、より納得感のある料金体系になると考えられる。
また、ストレージも同様に、クラウドサービスを合わせて利用されることが多い。ストレージは利用する容量単位の料金設定が望ましい。頻繁にレンダリングが行われる時期は高速なストレージも重要な要素である。しかし、修正のレンダリングや、アーカイブとして残すケースでは、多少の速度を犠牲にしてでも安価なほうが望まれることもある。
また、ソフトウェアライセンスの今後の動向にもよるが、CG・VFX プロダクションサ
イドにはソフトウェアやハードウェアを設置せずに、クラウド上のソフトウェアやハード
ウェアを動かし、その結果だけ画像として転送するような仮想化の普及も考えられる。今後ますますクラウドサービスの需要が期待されるところである。
しかしこうした需要が生み出されるのを妨げている要因のひとつは価格であるといわざるを得ない。価格の低下は多くのユーザーの利用につながり、データセンターの稼働率も上がり収益も見込める。クラウドサービスやネットワークレンダリングには国境の概念が少なく、十分な計算速度と転送速度が確保できるのであれば、海外の事業者を選択することも考えられる。そのため、国内の制作プロダクションの利用に即した提供価格の設定が実現しない場合は、レンダリングの国内空洞化も懸念される。
一方、レンダリングの適切な価格設定は、制作プロダクションの予算要求の面から見ても重要な要素である。作品の仕様が決まれば比較的正確にレンダリングにかかる費用が想定できるため、レンダリングの透明性確保につながり、正しいレンダリング予算の請求と確保につながっていくと考えられる。

101

5.2

萌芽的な流通実証実験（WG3）のまとめ

WG3 では、CG・VFX プロダクションの資産でもある 3DCG データの利活用についての実証実験を行った。近年、コンテンツ制作用ソフトウェアの高性能化、低価格化が進み、一般ユーザーによるコンテンツ制作である UGC（User Generated Contents）が高まりを見せている。UGC では、すべての素材をユーザーが制作するのではなく、ネット上で流通している素材データを利用し、ユーザーが独自に改変し楽しむという文化が形成されつつある。今後は、クラウドサービスが発達する中、ソフトウェアやハードウェアなどあらゆるサービスがクラウド化されることが想定される。その結果として、一般ユーザーがク
ラウドサービスを利用して、プロフェッショナルと同じ環境を利用するケースが増えていくであろう。
この現状を背景に、CG・VFX プロダクションの資産である CG データを、ネットを通じて一般ユーザーや同業他社に提供することで、あらたな収益を生み出すことを想定した。
本 WG では実証実験として 3DCG データの提供環境を構築し、実際にユーザーに利用してもらった。この一連のプロセスの中でいくつかの課題が見えてきた。

5.2.1

著作権の設定本実験において著作権は重要な問題である。すでに UGC の中で広まりつつあるクリエ
イティブ・コモンズの仕組みを利用し、様々なレベルで再利用可能なデータを提供した。
ここで課題となったのが「CG データは著作権の複合体」であることである。特に顕著なのは、キャラクタの 3DCG モデルである。モデルそのものは CG・VFX プロダクションの資産である。しかし、原作者やデザイナーがいる場合には、キャラクタのデザインは原作者やデザイナーの資産であり、3DCG データのみが CG・VFX プロダクションの資産になる。そのため、キャラクタデザインと CG データが異なる条件下で利用が可能になるケースもある。こうした 3DCG データについては、権利表記を別々に記載して設定する必要が
ある。

5.2.2

データ利用者による著作権主張

本システムのターゲットユーザとして、当初は、裾野の拡大を主眼に一般ユーザーを想定していた。しかし、制作環境のクラウド化が進み、高品位なデータが流通するようにな
ると同業他社の利用も大いに想定される。データ提供者が著作権に関して寛大にデータを提供し、多くの利用者が利用していく中で、この利用者が諸外国などで商標登録を行い、他のデータ利用者や大元のデータ提供者に対して、権利の侵害を主張することも考えられる。すでに、日本で制作されたコンテンツのコピー商品が、他国で勝手に他社によって商標登録をされてしまったケースが存在している。再利用するユーザーを想定し CC0 で提供された自由で権利上安全な CG データが、逆にリスクのある CG データとなってしまうことも想定される。権利を持つデータを提供する場合は現状と同じだが、CC0 のように自由102

に改変可能な状態でデータ提供する場合は、むしろ、CC0 とした記録を明確に残していく
必要性がある。またデータがどのように利用されたかをトレースできる機能も重要である。
クリエイティブ・コモンズのライセンスに沿った著作物の利用は、一定のルール化で著作物の利用に際して活用する点は適している。しかし、提供者の権利を守るという点では、提供形態に応じて様々な対処が必要であることがわかった。
こうしたシステムを提供する際には、提供者の権利を守る概念と多くの利用者に安全に利用してもらうという概念の 2 つを成立させる必要がある。

5.2.3

データの収集今回の実証実験では、WG 参加者などが制作した 3DCG キャラクタモデルのデータが提供された。本システムの利用を促す点からも、最もインパクトのあるキャラクタモデルを利用して実験を行った。キャラクタモデルはすでに述べたとおり、複雑な権利を有しているケースも多い。今後も様々なデータを収集し、公開していくことでさらに課題が明らかになっていくと考えられる。
また、本年度は上記の理由からキャラクタ中心に 3DCG データを提供した。さらに幅広く再利用可能なモデルの提供により、様々な利用形態とそれに付随する課題も明らかになると考えられる。具体的には、町並みを生成する際の 3D モデルやキャラクタのモーショ
ンデータ、CG のエフェクトなどの設定データなども想定される。
また、その際にはコンベンションの定義についても拡張していく必要がある。今回はモデルデータに関するもののみ定義付けを行った。今後、提供するデータの種類の増加に伴い、リグに関するコンベンションなど新たなルールが増えていくと考えられる。

5.2.4

利活用システムの充実

今回の実証実験では、モデルデータを提供する形式として、プロフェッショナルな制作
現場で汎用性の高い FBX 形式のモデルを採用した。アマチュアや学生で CG 制作の経験のあるユーザーであれば容易に高品質なデータにアクセスできる。しかし、FBX 形式のモ
デルは UGC などで主流となっているソフトウェアで利用可能な形式ではない。そのため、今後は幅広いデータ形式での利用や、ユーザーによるデータ形式の変換や提供などの仕組みを考えていく必要がある。
今回、データを提供するプラットフォームとして、プログラムのソースコードを共有流通させるフレームワークである「Github」を利用した。Github では、プログラムソースの継承や改変による枝分かれ（フォーク）などができるため、UGC での利用に適した仕組みを持っていた。そのため本実験ではこの仕組みを利用して、実証実験用のシステムを構築した。Github そのものにはビューワーがない。そのため、どのようなデータなのか、データをダウンロードして確認するまで判断ができない。今後の普及のためにファイルの内容を閲覧するビューワー機能と著作権に係る表示機能を持つ新たな利用システムの必要性も明らかになった。
103

5.3

総括

本事業では、CG・VFX プロダクション各社の参加により、実際の制作現場においてク
ラウドサービスを利用する際の効果測定をすることができた。特に転送速度の比較や、クラウドレンダリングサービスと自社でレンダリングシステムを運用する場合の比較は、様々な制作プロダクションにおいて、サービス選択の指標になり得る有益なものである。
現時点では、クラウドレンダリングを採用するには多くの課題が残っているものの、プロジェクトによっては十分利用価値のあるサービスになってきている。
クラウドレンダリングをはじめとしたサービスにおいて、制作プロダクションにとって重要なのは、回線の速度と料金である。今回の実験では、ISP 事業者の協力により、国内のネットワークで実証実験を行うことができた。しかし、遠隔地のレンダリングサービス
やクラウドサービスでは、回線の速度と料金等の条件を満たすのであれば、物理的な距離は大きな問題にはならない。実際に、北米のレンダリングをアジアで実施している事例もあり、高品質なインターネット環境の低価格利用は今後も重要な要因となり得る。
現状のクラウドサービスに関しては、ソフトウェアの対応状況に左右される点が多いた
め、今後は、レンダリングサービスへの柔軟なソフトウェア提供の仕組みが重要視される。
現在は、レンダリング関連のソフトウェア以外でも、ソフトウェアのクラウドサービスとしての利用のケースが増えている。CG・VFX 関連ソフトウェアのクラウド対応や、それを応用したクラウドサービスとしての展開は利用者の環境の向上につながり、UGC なども含め産業界全体の活性化につながっていくと考えられる。プロフェッショナルや一般利用を含めたクラウドサービスの利活用は今後も加速するものと考えられる。そのための環境の整備に関する調査を実施し、課題に対応する必要がある。

104

【第 2 章参考資料】【資料 2-1】クラウドおよびレンダリングサービスの事例
(1)

ZYNC

Amazon EC2 を活用したサービス。Atomic Fiction をはじめ、既に数々の作品の事例も多い。最近では、Shotgun との連携などのサポートも追加された。
サービスの種類は、8Core 15GB、16Core 30GB、32Core 60GB という構成。時間単価では割高となるが、28 日間のプランでは安価な設定になっている。
ストレージは、標準で 10GB 付いており、月額$25 で 100GB の追加が可能。
https://www.zyncrender.com/(2)

Green Button

RenderMan on Demand で知られたサービス。コア単価という価格形態で、8Core、14GB
RAM が標準構成になる。UDP を利用した Cloud Sync というツールを作っているのも特徴的。
http://www.greenbutton.com/(3)

Render Rocket

FTP のアップロードなど、レンダリングサービス的な形だが、LaunchPad という転送やモニタリングやツールなども提供している。また、上位のサービスとして 24h/7days に対応した制作プロダクションがメインに使うサービスなどもある。プリペイドによる 5%〜30%の大幅な値引きもある。いくつかの映画制作での実績がある。
https://www.renderrocket.com/(4)

Cloud Fuzion

EnFuzion というレンダリング管理ツールを作っている会社で、データ転送においてもFastTrack という UDP を使った独自の転送ツールを提供している。この EnFuzion をベースに Amazon EC2、HP Cloud、Microsoft Azure を使用することができる。
http://www.cloudfuzion.com/index.html(5)

Fox Render Farm

実際にレンダリングにかかった時間を請求するというサービスを実施している。また、アップロードしたファイルを解析したり、中国語、韓国語、日本語のファイルを自動的に105

英語にリネームするといった機能などを有している。サポートするソフトウェアだけでな
く、プラグインの種類も豊富で、独自のプラグインも受け入れている。日本語のホームページや、Facebook アカウントの対応など、積極的に活動しているのも特徴的。
http://www.foxrenderfarm.jp/about-profile.html(6)RebusFarm

こちらも、日本語のホームページがある。ソフトウェアをインストールすることで、ア
プリケーションからのファイルチェックや、レンダリング状況を確認することができる。
また、モバイルアプリをリリースしており、モバイルでレンダリング状況を確認できる。
GHz 単位で価格を設定していることも他のサービスと比較して特徴的といえる。また、時間単価だけでなく、5、10、20、50、100 日のプランもある。
http://www.rebusfarm.net/ja/(7)

RenderCore JP

ここも日本語メニューが充実している。こちらは 1Core=1 コインという単位で、1 時間単位で計算される。プリペイドによる割引率は高く、10%〜80%と幅広い。時間単位以外にも、1 週間、30 日プランも用意されている。
https://www.rendercore.jp【資料 2-2】クラウドにおけるソフトウェアの使用許諾と最新のクラウド情報(1)

現状のライセンスでのクラウドでの使用許諾の制限

現状、Autodesk 社では、クラウドでの利用におけるライセンスの付与がされない状態になっている。

2.1.1 ライセンス付与の排除/許諾されない行為(d)オートデスクが書面で別段の許諾をした場合を除き、ライセンシーが所有またはリース
しかつライセンシーが管理しているコンピュータ以外のコンピュータにライセンス対象マ
テリアルをインストールすることができるライセンス(g) 特定のライセンス タイプに関して別段の明示的定めのある場合を除き、ワイド エリア
ネットワーク(WAN)、仮想プライベートネットワーク(VPN)、仮想化、ウェブホスティン
グ、タイムシェアリング、サービスビューロー、サービスとしてのソフトウェア、クラウ
ドサービス、クラウド技術またはその他のサービスもしくは技術に関連しての使用を含め、
インターネットその他の非ローカルネットワークでのオートデスクマテリアルのインスト
106

ールもしくはアクセスまたはかかるインストールもしくはアクセスを許容するライセンス
引用元： http://images.autodesk.com/adsk/files/2012-m_e_lsa-japanese.pdf(2)

最新のクラウド事情①

Autodesk, Amazon, OTOY and NVIDIA による実験
Autodesk、Amazon, OTOY そして NVIDIA が実験として、Firefox ブラウザのみでク

ラウド上にある Autodesk の 3ds Max などを動かす実験を 2013 年 12 月末まで行った。

“Autodesk Provides 3D Design in a Browser, an Industry First Collaboration with
Amazon Web Services, OTOY and NVIDIA Enables Developers to Access Powerful 3D
Modeling from Anywhere, Anytime, with Any Device Using a Simple Web Browser”
http://news.autodesk.com/press-release/architecture-engineering-construction-civil-inf
rastructure-and-natural-resources/aut-1
http://www.mozilla.jp/blog/entry/10346/②

Autodesk Character Generator
SIGGRAPH2013 の際に Autodesk のクラウドの取組として Autodesk Labs で公開されていた Project Pinocchio が、正式に Character Generator として公開された。ブラウザ
経由で様々な種類ライブラリから組み合わせて人間の 3DCG モデルが生成できる。
Autodesk 製品である Maya や 3ds Max だけでなく Unity 用などにも出力できる。有償でよりディテールが細かい medium や high のモデルの FBX 出力や、顔の表情のブレンドシ
ェイプやリグなどにも対応する。

“Drastically reduce the time needed to create customized, rigged and ready-to-animate
3D characters with Autodesk® Character Generator; a new, easy-to-use, web-based
service. With Character Generator, users have control over a character’s body, face,
clothes and hair, and can then generate their customized character for use in popularanimation packages: Autodesk® Maya®, Autodesk® Maya LT™, and Autodesk® 3ds
Max® software as well as in game engines like Unity.”
http://area.autodesk.com/products/features/charactergenerator107

【第 3 章参考資料】【資料 3-1】Silver Bullet(1)

インストールマニュアル

東映ラボ・テック株式会社から送ったインストールツールを実⾏します。
【Windows】の場合は「SetupSkeedSilverBulletClient_2.1.0.1.exe」をダブルクリックし、実⾏します。

するとランゲージ選択のウィンドウが表⽰されます。

「Japanese」が選択されていることを確認し、「OK」ボタンをクリックします。

セットアップウィザードのウィンドウが表⽰されます。

「次へ」ボタンをクリックします。

108インストール先を選択するウィンドウが表⽰されます。

デフォルト設定のまま「インストール」ボタンをクリックします。

インストール完了のウィンドウが表⽰されます。

「完了」ボタンをクリックし、インストールを終了します。
これでWindows版のインストールが完了しました。

【Mac】の場合は「SetupSkeedSilverBulletClient_2.1.0.1.dmg」をダブルクリックし、実⾏します。

クライアントソフトをアプリケーションフォルダーへインストールするウィンドウが表⽰されます。

109

SkeedSilverBullet アイコンをドラッグし、Applications フォルダーへドロップします。
これで Mac 版のインストールが完了しました。

110

(2)

設定マニュアル【Windows】の場合、「スタート」→「プログラム」→「Skeed」→「SilverBulletClient」→「SkeedSilverBulletClient」
を実⾏します。
【Mac】の場合、「アプリケーション」→「SkeedSilverBullet」を実⾏します。

SkeedSilverBullet が起動されました。
メニューの⾔語が英語の場合、ウィンドウ右下の「English 英語」のトグルボタンから⽇本語に変更できます。

接続先のサーバを設定します。

「＋新規」ボタンをクリックします。

111

接続先のサーバ情報を⼊⼒するウィンドウが表⽰されます。

①ホスト名

：

こちらからお伝えするホスト名を⼊⼒します。

②ポート番号：

5100 （常に 5100 です。
）③ユーザー名：こちらからお伝えするユーザー名を⼊⼒します。

④パスワード：こちらからお伝えするパスワードを⼊⼒します。

①〜④の⼊⼒が完了したら、「⾃動ネットワーク設定」ボタンをクリックし、接続先のサーバとの通信を調整します。

数⼗秒後に⾃動調整の完了を伝えるウィンドウが表⽰されます。

「OK」をクリックします。

112

先ほどの接続先サーバ情報を⼊⼒するウィンドウに戻ります。

「保存」をクリックします。

設定したサーバ情報を保存するウィンドウが表⽰されます。

セッションの保存名は、デフォルトのまま「パスワードを保存する（⾮推奨）」チェックし、「OK」ボタンで実⾏します。
次回サーバへ接続したときにパスワードを聞かれません。
お客様単体のパスワードですので、情報漏洩については⼗分気を付けてください。
ここまでで接続サーバの設定が完了しました。

113

(3)

Silver Bullet 操作マニュアル

サーバへ接続し、ファイルのアップロード、ダウンロードを⾏います。

先ほど設定したサーバを選択し、「ログイン」ボタンをクリックし、サーバへ接続します。

サーバへログインした状態でSkeedSilverBullet GUIが起動されました。

左側が⾃分のPCのローカルになります。右側が接続サーバになります。

サーバへファイルを転送する場合、最初にファイルのある場所へ移動します。
クライアントソフト内のローカル側の「移動」ボタンをクリックしします。
新たにフォルダーを選択するウィンドウが表⽰されます。

114

⽬的のフォルダーをクリックし、「選択」をクリックします。

転送するファイルを選択し、右側のフォルダーへドラッグします。
または、アップロードボタンを押します。

ファイル転送の確認ウィンドウが表⽰されます。

115

「転送ファイルを暗号化する」にチェックが⼊っていることを確認し、「はい」を選択します。
ファイル転送が実⾏されます。
ここまでがファイルのアップロードです。続けてダウンロードついてお伝えします。

転送するファイルを選択し、左側のフォルダーへドラッグします。
または、ダウンロードボタンを押します。

ファイル転送の確認ウィンドウが表⽰されます。

「転送ファイルを暗号化する」にチェックが⼊っていることを確認し、「はい」を選択します。

116

ファイル転送が実⾏されます。
以上がファイルのアップロード、ダウンロードになります。

続けて転送時のエラーについてお伝えいたします。
ファイルの転送途中でネットワークが遮断した場合は、瞬断ならそのまま転送を継続します。
ある程度の時間転送が出来なかった場合、⾃動的にサーバへ接続を繰り返し⾏い、ネットワーク復帰後に続けて転送を開始します。

ネットワークが遮断する前までに送ったデータはそのまま保存されています。

また転送を途中で⽌めてもその続きから転送を⾏うレジューム機能があります。

117

【資料 3-2】NUKE 分散レンダリング操作マニュアル■リモートデスクトップ
リモートデスクトップにてクラウド上に作成したレンダリングサーバにアクセスします。
「すべてのプログラム」→「アクセサリ」→「リモートデスクトップ接続」を選択します。

「コンピュータ名」に今回使⽤するサーバの IP アドレスを⼊⼒します。
「接続」をクリックします。
接続の信頼を尋ねるダイアログが表⽰されますので、「接続」をクリックします。

「別のアカウントを使⽤」をクリックし、
ユーザー名：こちらからお伝えするユーザー名
パスワード：こちらからお伝えするパスワードと⼊⼒し、OK をクリックします。

118

サーバの証明書が信頼された認証機関のものではないと警告画⾯が表⽰されます。
「はい(Y)」を選択します。
これでクラウドサーバにリモートデスクトップで接続できましたので、普段⾃分が利⽤しているクライアント PC のようにクラウドサーバ上で NukeX を実⾏します。

■NukeX を実⾏する
Skeed Silver Bullet にてアップロードした Nuke プロジェクトを開きます。
デスクトップ上の NukeX アイコン

をクリックします。

NukeX が起動しますので、レンダリングを実⾏したいプロジェクトを読み込みます。

NukeX のメインメニューに RENDER SPICE ⽤のメニューが表⽰されています。

119

「RENDER SPICE」→「RenderSpiceClient」を実⾏します。

プロジェクトの情報をあらかじめ読み込んだ状態で RenderSpiceClient が実⾏されます。

シーンファイル名とフレームレンジなどがあらかじめプロジェクトから読み込まれた状態でメニュー画⾯が起動され
ます。

120

ここでは、実際にレンダリングする開始フレームと終了フレームを⼊⼒します。
フレームレンジとレンダリングノード（レンダリングを字実⾏するサーバ）を⼊⼒します。

レンダーノードから「⼀括接続」をクリックします。
新たにノードリストが表⽰されます。

使⽤したいレンダリングノードのチェックボックスをクリックし、選択します。
選択したら「接続」をクリックします。

選択されたサーバがグリーン表⽰されます。

121

「開始」をクリックし、レンダリングを実⾏します。
レンダリングする総フレーム数をノードで分割したフレーム数単位で各ノードにレンダリングが⾃動で分散されます。

開始
各部の⼊⼒・選択が終わったら、「開始」ボタンを押すとレンダリングが始まります。

停⽌
レンダリングを途中で⽌めたいときに押してください。

再開「停⽌」ボタンで⽌めたレンダリングをその箇所から「再開」します。

終了
アプリケーションを終了します。

RenderSpiceMonitor でレンダリングしている状況を確認することができます。

つづけて複数のプロジェクトをまとめて連続して実⾏させることができます。
これを使えば夜中などにレンダリング処理をまとめて実⾏することができ、効率的です。

122

「実⾏登録」ボタンを押します。

連続で実⾏するプロジェクトを登録するウィドウが表⽰されます。

「追加」をクリックし、今開いているプロジェクトを登録します。

「ファイルに保存」を選択し、ファイルを登録します。
これで⼀つ⽬のジョブが登録されました。
「閉じる」でウィンドウを閉じます。

123新たなプロジェクトファイルを選択します。
「選択」をクリックします。

新たに登録するプロジェクトファイルを選択し、読み込みます。
レンダリングする「開始フレーム」、「終了フレーム」を設定します。

「実⾏登録」ボタンを押します。

先ほどと同様に「追加」でプロジェクトを登録し、「ファイルに保存」で先ほど保存したファイルに上書き保存します。

124

これで連続実⾏する準備が整いました。
レンダリングノードから「⼀括選択」でレンダリングノードを選択し、接続します。

選択されたサーバがグリーンで表⽰されます。

「連続実⾏」にチェックを⼊れます。

「開始」ボタンで登録されたジョブを連続実⾏します。

⾃動再配分「実⾏登録」に登録されたジョブを効率よくレンダリングを⾏いたいときにチェックします。
⼀定の時間が経つと指定したマシンの中でレンダリングが終わっているマシンを追加し、残りフレームのレンダリングの効率をあげるようになっています。

125