平成 24 年度我が国情報経済社会における基盤整備事業（コンテンツ制作基盤整備事業）

報

告

書

平成 25 年 4 月

経済産業省

目

次

第 1 章 事業概要................................................................................................................1
1.1 本事業の目的 ...........................................................................................................1
1.2 実施体制 ..................................................................................................................2
1.2.1 実施体制 ...........................................................................................................2
1.2.2 委員会 ...............................................................................................................3
1.2.2 制作工程管理システム検討 WG .......................................................................4
1.2.3 クラウドを活用したレンダリングシステム検討 WG ......................................5
1.3 事業概要 ..................................................................................................................6
1.4 用語の整理 ............................................................................................................10
第 2 章 カテゴリ別制作本数実態調査 .............................................................................12
2.1 調査の目的 ............................................................................................................12
2.2 調査項目 ................................................................................................................122.2.1 カテゴリ .........................................................................................................122.2.2 調査項目 .........................................................................................................13
2.3 調査結果 ................................................................................................................132.3.1 制作期間 .........................................................................................................15
2.3.2 予算規模 .........................................................................................................15
2.3.3 尺 ....................................................................................................................16
2.3.4 制作人数（人月） ...........................................................................................16
2.3.5 外注数（会社及び個人） ................................................................................172.3.6 外注比率 .........................................................................................................172.3.7 元請／下請 ......................................................................................................18
2.4 調査結果分析 .........................................................................................................19
2.5 まとめ....................................................................................................................21
第 3 章 制作工程管理システム ........................................................................................22
3.1 調査概要 ................................................................................................................22
3.1.1 概要.................................................................................................................22
3.1.2 背景.................................................................................................................22
3.1.3 調査体制 .........................................................................................................23
3.2

調査内容 ................................................................................................................24

3.2.1 ワークフロー運用ルール標準化に関する調査 ...............................................24
3.2.2 制作工程管理システム導入に関する調査 ......................................................24
3.2.3 既存プロダクション実態調査.........................................................................24
3.3

運用ルールに関する標準化 ...................................................................................25

3.3.1 CG・VFX のアセットデータ管理と運用方法の効率化 .................................25
3.3.2

カラーマネジメントのワークフロー及びデータフローの確立 .....................27

3.3.3

カメラのメタデータ供給のための標準化 ......................................................30

3.4

既存ツールの検証 .................................................................................................33

3.4.1 調査項目の選定 ..............................................................................................33
3.4.2 システムの重要性 ...........................................................................................34
3.4.3 ディレクトリ管理機能とアセットマネージャー機能検証 .............................35
3.4.4 プロジェクトマネージャー検証 .....................................................................43
3.4.5 レビューシステム検証 ...................................................................................67
3.4.6 既存アプリケーションの情報収集と分析 ......................................................78
3.4.7 導入に当たってのチェックポイント..............................................................81
3.4.8 既存ツールに無い機能の拡充.........................................................................83
3.5 プロダクションヒアリング ...................................................................................84
3.5.1 ヒアリング先の選定と実施 ............................................................................84
3.5.2 プロダクション事例 .......................................................................................86
3.6 まとめ..................................................................................................................106
3.7 参考文献 ..............................................................................................................107
第 4 章 クラウドを活用したレンダリングシステム .....................................................108
4.1 調査概要 ..............................................................................................................108
4.1.1 調査の背景と目的 .........................................................................................108
4.1.2 調査体制 .......................................................................................................109
4.2 調査内容 ..............................................................................................................110
4.2.1 調査項目の選定 ............................................................................................110
4.3 調査と分析 ..........................................................................................................112
4.3.1 クラウドレンダリングサービスの課題 ........................................................ 112
4.3.2 プロダクションの環境調査 .......................................................................... 114
4.3.3 クラウドでの課題の分析 ..............................................................................130
4.3.4 実証実験 .......................................................................................................139
4.3.5 クラウドレンダリングの課題のまとめ ........................................................148
4.4 考察 .......................................................................................................................151
4.4.1 調査と分析結果の考察 .................................................................................151
4.4.2 クラウドレンダリングサービスの仕様検討.................................................159
4.4.3 経営者にむけて設備投資の提案 ...................................................................160
第 5 章 海外動向調査 ....................................................................................................164
5.1 調査の目的 ..........................................................................................................164
5.2 米国・カナダ動向調査 ........................................................................................165
5.2.1 米国の CG・VFX プロダクションに対する調査 .........................................166
5.2.2 カナダの CG・VFX プロダクションに対する調査 .....................................184
5.2.3 米国・カナダの CG・VFX プロダクション以外の関係機関に対する調査 ..................................................................................................................193
5.3 欧州（英国・仏国）動向調査 .............................................................................199
5.3.1 英国の CG・VFX プロダクションに対する調査 .........................................200
5.3.2 仏国の CG・VFX プロダクションに対する調査 .........................................205

5.3.3 欧州（英国・仏国）の CG・VFX プロダクション以外の関係機関に対する調査 .......................................................................................................214
5.4 海外動向調査まとめ ............................................................................................2205.4.1 人材について ................................................................................................220
5.4.2 開発環境について .........................................................................................2205.4.3 ハリウッドからの受注の可能性について ....................................................2215.4.4 取り組むべき課題 .........................................................................................222
第 6 章 まとめ ...............................................................................................................223
付属資料索引 ...................................................................................................................228【資料 1】メタデータ統合 ............................................................................................229【資料 2】ARRI RAW メタデータ................................................................................232【資料 3】RED ONE/EPIC メタデータ .......................................................................233【資料 4】Sony F65RS メタデータ ..............................................................................235【資料 5】Canon EOS C500 RAW （.RMF）メタデータ ..........................................236【資料 6】EOS C500 RAW （XML）メタデータ .......................................................237【資料 7】XF/XA/C300/C500 MXF （.MXF）メタデータ.........................................238【資料 8】XF/XA/C300/C500 MXF （.CIF）メタデータ...........................................239【資料 9】XF/XA/C300/C500 MXF （XML）メタデータ ..........................................240【資料 10】Autodesk FBX KFbxCamera クラス........................................................241【資料 11】EXIF 2.3 メタデータ .................................................................................243【資料 12】既存ソフトウェア比較表 ...........................................................................245

第1章
1.1

事業概要

本事業の目的

アニメーションや映画を始めとする日本の映像コンテンツは世界的に人気を博しており、多数の作品が制作されている。特に、複雑な工程が必要とされるコンピューターグラフィ
ックス（CG）を利用した映像視覚効果（VFX）やアニメーション制作の技術に関しては、欧米と比べ、一人で複数の工程をこなすことができる高い技術力を持つ人材（ジェネラリ
スト）が豊富であり、そのコストパフォーマンスの高さなどから高い評価を得ている。
一方、昨今は映像コンテンツの高精細映像、立体映像などの需要の増加に伴い、CG や
VFX による映像の加工が不可欠となり、これまで以上に質の高い映像表現が求められている。そうした中で、従来以上の情報量を持った映像作品を作り上げるには、複数の人材による共同作業が必要とされ、マンパワーに頼った制作体制で行うには限界が来ている。また、従来型の産業構造そのものの変化に伴い、制作費の縮減が強く要求される一方、求められる品質の映像を制作・加工するための設備に対する投資に必要な額は年々増加し、映像制作・加工事業者の経営を圧迫する事例が現れてきている。
このような状況を打開するため、CG・VFX 業界においてコンテンツ制作に必要なソフ
トウェアやハードウェアといった基盤を効率的に整備することで、各社の投資負担の低減が期待される。本事業は、このような共通基盤整備のため、共通基盤に必要となる機能、規模、運用方法等について検討を行うと共に、必要な仕様を提案することを目的とする。

1

1.2

実施体制

1.2.1 実施体制
本事業の実施に当たり、学識経験者、CG・VFX 制作会社、アニメーション制作会社、
ポストプロダクションなど、CG・VFX 業界の各分野の有識者から構成する CG・VFX 共通基盤検討委員会を設置・開催した。また委員会の下部組織として、委員メンバーに当該分野の有識者を加えたサブワーキンググループを設置した。サブワーキンググループとしては、クラウドを活用したレンダリングシステムについての検討を行うための「クラウドを活用したレンダリングシステム検討 WG」と CG・VFX 制作工程管理システムについての検討を行うための「制作工程管理システム検討 WG」を設置・開催した。
委員会の委員以外にも CG・VFX 業界の興隆を支援する団体である「一般社団法人
VFX-JAPAN」や日本の映像産業の振興事業などを実施する団体である「一般社団法人日本コンテンツ振興機構」と連携して情報共有を行うことで、幅広く関係者から本事業に関する意見を集約できる体制を構築した。

図 1.1

実施体制図

2

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

CG・VFX 共通基盤検討委員会

委員名簿

役割

氏名

会社/団体名委員長

為ヶ谷秀一

女子美術大学大学院

副委員長

三上浩司

東京工科大学委員

野﨑宏二

株式会社エヌ・デザイン

委員

迫田憲二

株式会社オムニバス・ジャパン

委員

三田邦彦

株式会社キュー・テック

委員

鈴木勝

株式会社白組委員

野口和紀

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

委員

小山昌孝

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

委員

野口光一

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

委員

杉本健一

株式会社ドロイズ委員

結城徹

一般社団法人 VFX-JAPAN

委員

今村理人

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

委員

増尾隆幸

株式会社ルーデンス

事務局

秋山貴彦

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

事務局

加藤俊彦

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

事務局

村田雅俊

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

事務局

須藤智明

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

事務局

中村雅子

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

31.2.2 制作工程管理システム検討 WG
CG・VFX 共通基盤検討委員会の委員並びに当該分野の有識者 13 名で構成される「制作工程管理システム検討 WG」を CG・VFX 共通基盤検討委員会のサブワーキンググループとして設置した。座長には三上浩司准教授（東京工科大学）が選出され、計 5 回の会議を開催した。サブワーキンググループメンバーは以下のとおり。
表 1.2

制作工程管理システム検討 WG メンバー名簿

役割

氏名

会社・団体名座長

三上浩司

東京工科大学WG メンバー

西野憲司

株式会社アニマ

WG メンバー阪上和也

株式会社エヌ・デザイン

WG メンバー

四倉達夫

株式会社オー・エル・エム・デジタル

WG メンバー

三田邦彦

株式会社キュー・テック

WG メンバー鈴木勝

株式会社白組WG メンバー飯嶋浩次

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

WG メンバー斎藤成史

株式会社スタジオ雲雀

WG メンバー杉本健一

株式会社ドロイズ

WG メンバー痴山紘史

株式会社日本 CG サービス

WG メンバー松橋祥司

日本ケーブルビジョン株式会社

WG メンバー

大屋哲男

株式会社ピクチャーエレメント

WG メンバー中嶋雅浩

株式会社ボーンデジタル4

1.2.3 クラウドを活用したレンダリングシステム検討 WG
CG・VFX 共通基盤検討委員会の委員並びに当該分野の有識者 11 名で構成される「制クラウドを活用したレンダリングシステム検討 WG」を CG・VFX 共通基盤検討委員会のサブワーキンググループとして設置した。座長には鈴木勝氏（株式会社白組）が選出され、計 5 回の会議を開催した。サブワーキンググループメンバーは以下のとおり。
表 1.3

クラウドを活用したレンダリングシステム検討 WG メンバー名簿

役割

氏名

会社・団体名座長

鈴木勝

株式会社白組WG メンバー野﨑宏二

株式会社エヌ・デザイン

WG メンバー

四倉達夫

株式会社オー・エル・エム・デジタル

WG メンバー宮本逸雄

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

WG メンバー斎藤成史

株式会社スタジオ雲雀

WG メンバー牧野祐市

デジタルハリウッド株式会社

WG メンバー大河原哲

株式会社デジタル・メディア・ラボ

WG メンバー園田哲也

日本アイ・ビー・エム株式会社

WG メンバー痴山紘史

株式会社日本 CG サービス

WG メンバー中嶋雅浩

株式会社ボーンデジタル

WG メンバー今村理人

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

5

1.3

事業概要

本報告書は、次章以降「2 章 カテゴリ別制作本数実態調査」「3 章 制作工程管理シス
テム」「4 章 クラウドを活用したレンダリングシステム」「5 章 海外動向調査」「6 章 まとめ」で構成されている。
各章の概要は以下のとおり。

(1)

2章

カテゴリ別制作本数実態調査「2 章 カテゴリ別制作本数実態調査」では、本事業のテーマである制作工程管理シス
テムやクラウドを活用したレンダリングシステムのあるべき姿について検討する際に、まずは CG・VFX 業界の劇場公開作品から CM まで様々なカテゴリ別の作品について、その尺や制作人数などがどういった分布を構成しているかを調査する必要があるとの提言に基づき、カテゴリ別制作本数の実態調査を実施した。
10 社から 2010 年 7 月～2012 年 6 月までの間に納品又は検収が終了した 1,744 作品についての回答を得た結果を元に、本事業でターゲットとして考えるべきカテゴリについて分析を行うと、予算規模の多さや尺の長さなど複数の項目について、アニメ（テレビシリーズ）とアニメ（劇場作品）が当てはまる結果となった。

(2)

3章

制作工程管理システム「3 章 制作工程管理システム」では、CG・VFX 制作工程管理を効率的に行うための方策について整理した。具体的には、実証実験を行い、既存の CG・VFX 制作工程管理シ
ステムの検証、及びパイプラインツールの導入により制作工程管理がどの程度効率化され、実際のコスト削減やクオリティアップなどにつながるかを検証すると共に、今後開発が望まれる機能や、標準化が必要な部分について検討している。
多くの映像素材がデジタル化され、その容量が膨大なものとなっている。そのためアセット管理やショットと関連するカラーマネジメントとメタデータの共通化又は相互に変換できるルールの整備を行うことは急務である。
いくつかの企業においては、制作工程管理システムの導入に積極的であり、それぞれの社内事情にあわせるため独自開発が行われる一方、アニメ業界では、カット袋を用いたア
ナログによる作業効率化が極限まで発達し業界内に浸透し過ぎている結果、デジタルでの新たな工程管理システムの導入は難しいと思われる。
北米を中心とした海外大手プロダクションでは、長年に渡った努力により制作工程管理システムが確立されてきた。しかしながら 10 名程度の組織と 100 名の組織では注力すべき部分が変わってくる。組織の規模やレベルに合わせて段階的にシステム化をしなければ、
6

制作工程管理システムの構築はうまくいかない。また、システムを構築するに当たって既存のソフトウェアでは足りない部分を補うための努力は常に行う必要がある。
今後は、国内映像企業の発展のために、日本国内向けの制作工程管理システムの構築及び導入・運用のためのサービスが必要だ。同時に、映像制作に必要なアセット、メタデー
タ、タスクの呼称などの情報を集約し、それぞれの名称を統一するなど規格標準化することにより、合理的かつより進歩的な制作工程管理システムの構築が可能となる。それにより、社内の管理だけでなく、社外間での共同作業を行う際にも高度でスピーディーなコミュニケーションの連携が生まれると考えられる。

(3)

4章

クラウドを活用したレンダリングシステム「4 章 クラウドを活用したレンダリングシステム」では、CG・VFX 業界における映像制作工程の中で非常に高いウェイトを占める、レンダリングに係るリソースの最適化に必要なシステムの検討に必要な調査と実証実験を実施した結果を取りまとめた。
現状を把握するための調査、考察、分析と、クラウドレンダリングを前提にしたジョブ
管理、レンダリング、データ転送の実証を行った。本事業の実施により、クラウドレンダ
リングの可能性と課題を明確にし、サービス利用者のパイプラインの改善並びに今後のサービス提供事業者の事業展開の参考となる指針を示している。
なお現在、国内で継続的にクラウドを用いたレンダリングサービスを行なっているプロ
ダクションはない。現状ではクラウド環境の構築にはライセンス問題（CG ソフトに関しては世界的にみて一部の例外はあるが許可が下りていない）など様々な課題があるため、サービス自体が存在しないからである。
本検証によって、ライセンス問題は残るものの、クラウドレンダリング検証で仮説としたアーキテクチャは米国事例も含めて正しいことが分かり、本格運用に向けたサービス化のステップに移行して良いということが確認出来た。米国でも先進事例となっている仮想
OS によるレンダリングに引き続き注目し、継続検証項目として調査、実証を行う必要があることが確認された。
レンダリング性能は最新ハイエンド CPU をもってしても未だ 4K レンダリングには日
本国内では許容出来ない時間（想定 1 時間以上）がかかっており、CPU の性能向上、
GPGPU、
Phi をはじめとした CPU と連携する専用演算機を含めてレンダリング性能向上を待つ必要がある。
上記結果から、ユーザー（サービス利用者）から求められるクラウドレンダリングサー
ビスの仕様について検討を行った。
すぐに使えるユーザビリティの優れているフレキシブルな課金制度（PC１台につき毎時
50〜100 円程度）のサービスが提供されることが求められており、そうしたサービスが導入されることにより、トータルコスト削減や制作力の向上（レンダリングリソースの最大
7

利用、高解像度・高フレームレートへの対応、遠隔地のアーティストとのコラボレーショ
ン、シミュレーションへの対応など）が期待される。 またライセンスの問題を解決する
ための可能性としては、下記の 4 つの方向性が考えられる。
(1) 3DCG ソフト、プラグインのクラウド環境での使用許諾を得る(2) 人の手を介するコンバート作業をもったサービス(3) シーン変換の自動化（コンバータの作成）(4) ユーザーによる既存の環境にのった運用

(4)

5章

海外動向調査「5 章 海外動向調査」では、海外の CG・VFX 会社の現状を調査し、日本との違いを明らかにすることを目的としている。特に、経営に関わる部分としてスタッフの契約状況
や、他のプロダクションとの関係などを調査した。またシステムに係る部分として、開発
環境やパイプライン、クラウドを活用したレンダリングシステムなどについて調査した。
その他、政府の支援体制や人材育成、海外と日本の映像制作環境の違いなどについても調査を行った。
米国（ロサンゼルス・サンフランシスコ）・カナダ（バンクーバー）の CG・VFX プロ
ダクション 10 社と関係 4 団体及び欧州（英国・仏国）の CG・VFX プロダクション 10 社と関係 4 団体についての調査結果を取りまとめた。
人材については、米国・カナダの大手プロダクションではスペシャリストが求められるが、小規模なプロダクションでは日本同様に基本的にジェネラリストが求められることが多かった。欧州では大手プロダクションであってもジェネラリストを求めている会社もあった。契約形態はフリーランスの割合が多い。
開発環境については、制作工程管理については、大手プロダクションでは制作工程管理システムが導入されているが、小規模なプロダクションでは統一された制作工程管理シス
テムが導入されておらず Excel や Filemaker などが利用されている場合もあった。レンダ
リングサーバについては、遠隔地にレンダリングサーバを設置してレンダリングを行っている事例は何社かあったが、他社とレンダリングサーバを共有しているプロダクションはほとんどなかった。
ハリウッドからの受注の可能性については、かつてはハリウッドのスタジオが、VFX プ
ロダクションに仕事を割り振っていたが、それではスタジオのマネジメントが大変なため、
最近は、ハリウッドのスタジオから包括的にマネジメントとクオリティ管理をしてくれる
大手の VFX プロダクションに仕事が割り振られ、そこから中小の VFX プロダクションに流れているといったように受注フローには大きな変化が起こっていることが分かった。
そうした仕事を獲得するためには、デモリールによる PR が必要だが、日本ではその PRも難しいという問題がある。
8

(5)

6章

まとめ

「6 章 まとめ」では 2 章から 5 章までを横断的に総括し、CG・VFX 業界が、将来にわたって国際的競争力を高めていくために、重要となる課題について述べている。また、それらの課題の中から、具体的に将来にわたって取り組むべき基盤的な項目について、本事業を通じて明らかになった点について述べている。

9

1.4

用語の整理

映像制作を 1 社で行う場合、独自の用語を社内で使用しても問題はおこらない。しかしながら、複数の企業や顧客との間でやり取りを行う場合、用語を一致させることはワークフローを円滑に進める上で重要な意味を持つ。また、映画の主要マーケットである北米で通用している用語に合わせることは、日本国内企業との受発注がより円滑になり、意思疎通が強力なパートナーシップを築く礎となる。
ここでは、本事業に関連があると考えられる用語について説明を行う。

①

アセットマネジメントシステム

映像制作に必要な素材やリソースを管理するシステムの総称。

②

パイプラインシステム

映像制作の各工程の作業をする際にデータをストレージから作業者へ届けたり、作業結
果を回収したりするネットワークインフラ。よりセキュアにデータの受け渡しを行うためにシステム化されるのが一般的である。単にパイプラインともいう。

③

制作管理システム

制作のスケジュールや進捗状況、
業務のアサインやスタッフの勤怠を管理するシステム。
素材の閲覧なども可能であり、完成した作業の確認にも用いることができる。

④

ワークフロー

コンテンツ制作における制作手順（フロー）を示す工程（ワーク）の遷移図で、単にフローと呼ばれることもある。多くの工程（段階）を経て制作されるコンテンツでは、必ずワークフローが存在する。

⑤

アーカイブ

過去に制作した作品の映像原版・素材・データを、後世に残し再利用するために整理・保管すること。又はそのようにして保管されたものをさす。

⑥

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

主に編集などのポストプロダクション工程において、ビデオテープを使わないワークフ
ローのあり方を指して使われており、「テープレス・ワークフロー」とも呼ばれる。また、
一般的にデータだけで全ての業務を完結させようという考え方は「データ・セントリック・
ワークフロー」と呼ばれる。
10

⑦

アーティスト

映像作家のこと。映画監督、CM ディレクター、CG クリエイターなど映像制作に従事するものをさす。日本ではデザイナー、クリエイターと呼ぶこともあるが、欧米ではアーティストという。

⑧

ソフトウェアハードウェア上で動作するプログラム。システムソフトウェア、アプリケーションソフ
トウェア、ツールソフトウェアの総称。

⑨

アプリケーションソフトウェア

コンピュータを利用する直接の目的となるソフトウェア。単にアプリケーションともいう。

⑩

ツールソフトウェア又はユーティリティソフトウェア

補助的に様々な機能を提供するソフトウェア。単にツール、ユーティリティともいう。

⑪

レンダリングサービス

基本として受託業務としてレンダリング作業を請け負うサービス事業。

⑫

クラウドレンダリング

ネットワークを介して仮想環境へアクセスしてレンダリングを実行すること。

11

第2章
2.1

カテゴリ別制作本数実態調査

調査の目的

CG・VFX 共通基盤検討委員会 において本事業のテーマである制作工程管理システムやクラウドを活用したレンダリングシステムのあるべき姿について検討する際に、まずはCG・VFX 業界の劇場公開作品から CM まで様々なカテゴリ別の作品について、その尺や制作人数などがどういった分布を構成しているかを調査する必要があるとの提言に基づき、カテゴリ別制作本数の実態調査を実施した。
なお本調査は、カテゴリごとの業界全体の分布、リソースの活用状況等の把握を目的と
している。

2.2

調査項目

2.2.1 カテゴリ
調査に当たり CG・VFX 業界の企業が制作に関係するコンテンツのカテゴリを以下の 15
種類に分類した。
表 2.1

CG・VFX 業務カテゴリ分類

アニメ（劇場作品）
フル CG アニメ
（劇場作品）VFX 実写（テレビシリーズ）
放送用
オンエアグラフィックス

劇場作品 VFX

OVA アニメ

アニメ（テレビシリーズ）
フル CG アニメ
（テレビシリーズ）

OVA 実写VP・CM・
デジタルサイネージ

12

プレゼンテーション映像
ゲーム（プリレンダー）ゲーム（リアルタイムムービー）アトラクション、
博展映像（ライド）
遊技台液晶コンテンツ

2.2.2 調査項目
上記カテゴリ別に下記項目についての調査を実施した。
調査に当たっては下記の条件で記入を依頼した。








尺は、制作した分数を選択
制作予算は外注費も含めた受注額を選択
制作期間が 2 年以上の作品の予算は、総予算を選択
制作人数（人月）は外注先の人月も含める
データ納品のように、尺での計測が困難な仕事については、「データ納品」を選び、作品単位で本数を記入
回答が難しい場合には「回答不可」を選択
表 2.2

元請・
下請

回答不可
10 人未満
10 人〜30 人未満
30 人〜50 人未満
50 人〜150 人未満
150 人〜300 人未満
300 人以上

外注比率

回答不可
5 分未満
5 分〜10 分未満
10 分〜30 分未満
30 分〜60 分未満
60 分〜120 分未満
120 分以上
データ納品

外注数（会社及び個人）

2.3

制作人数（
人月）

予算規模

回答不可
100 万円未満
100 万〜1000 万円未満
1000 万〜5000 万円未満
5000 万〜1 億円未満
1 億〜3 億円未満
3 億円以上

尺

制作期間

回答不可
1 週間未満
1 週間〜1 ヶ月未満
1 ヶ月〜半年未満
半年〜1 年未満
1 年～2 年未満
2 年以上

カテゴリ別制作本数調査の選択肢一覧

回答不可
無
1〜5 社未満
5〜10 社未満
10 社以上回答不可
無1～20%未満
20～40%未満
40～60%未満
60～80%未満
80%以上
回答不可
元請
下請

調査結果

10 社から 2010 年 7 月～2012 年 6 月までの間に納品又は検収が終了した 1,744 作品についての回答を得た。その結果を表 2.3 にまとめる。
13

表 2.3

CG・VFX カテゴリ別制作本数実態調査
アニメ（
テレビシリーズ）

放送用オンエアグラ
フィックス
実写（
テレビシリ
VFX
ーズ）
アニメ（
テレビ
CG
シリーズ）

アニメ
OVA

実写
OVA

VFX

アトラクション、博展
映像（
ライド）
ゲーム（
リアルタイム
ムービー）
ゲーム（
プリレンダ
ー）
プレゼンテーション映
像
・ CM
・
デジタルサ
VP
イネージ

遊技台液晶コンテンツ

0
0
15
11
0
0
0

0
0
407
518
175
96
3

0
0
3
4
24
0
0

1
11
89
0
0
0
0

0
0
0
0
0
0
10

0
1
6
5
0
0
0

0
0
4
0
0
0
0

1
49
124
0
0
0
20

0
0
4
12
0
0
0

0
1
10
3
2
0
2

1
7
16
3
0
0
0

0
0
3
0
0
0
0

0
3
40
15
5
0
15

3
73
725
585
208
100
50

合 計
100 万円未満
100 万〜1000 万円未満
1000 万〜5000 万円未満
5000 万〜1 億円未満
1 億〜3 億円未満
3 億円以上
回答不可

20
0
1
1
1
16
1
0

5
1
2
1
0
1
0
0

26
4
9
12
1
0
0
0

1,199
61
219
691
84
142
0
2

31
1
2
28
0
0
0
0

101
7
71
22
0
0
0
1

10
0
10
0
0
0
0
0

12
1
6
5
0
0
0
0

4
0
0
4
0
0
0
0

194
84
104
6
0
0
0
0

16
0
4
12
0
0
0
0

18
1
3
7
2
0
0
5

27
9
13
5
0
0
0
0

3
1
1
0
1
0
0
0

78
3
23
15
5
20
1
11

1,744
173
468
809
94
179
2
19

尺

合 計
5 分未満
5 分〜10 分未満
10 分〜30 分未満
30 分〜60 分未満
60 分〜120 分未満
120 分以上
データ納品
回答不可

20
1
0
1
0
14
1
3
0

5
1
0
1
1
1
0
0
1

26
0
0
1
6
2
0
9
8

1,199
63
80
698
13
0
341
4
0

31
2
0
4
0
24
0
1
0

101
1
5
12
13
22
12
36
0

10
10
0
0
0
0
0
0
0

12
0
6
5
0
0
0
1
0

4
0
0
0
1
1
2
0
0

194
182
1
0
0
0
0
11
0

16
2
13
0
0
0
0
1
0

18
12
2
2
0
1
0
1
0

27
0
0
0
0
0
0
27
0

3
0
0
0
1
1
1
0
0

78
13
13
16
4
1
0
31
0

1,744
287
120
740
39
67
357
125
9

制作人数
（
人月）

合 計
10 人未満
10 人〜30 人未満
30 人〜50 人未満
50 人〜150 人未満
150 人〜300 人未満
300 人以上
回答不可

20
1
0
5
9
1
0
4

5
1
2
0
0
1
1
0

26
11
6
9
0
0
0
0

1,199
286
63
462
156
0
232
0

31
3
0
28
0
0
0
0

101
37
64
0
0
0
0
0

10
10
0
0
0
0
0
0

12
1
0
6
5
0
0
0

4
0
0
0
0
0
0
4

194
193
0
0
0
0
0
1

16
3
0
0
0
0
0
13

18
10
5
0
3
0
0
0

27
23
1
3
0
0
0
0

3
0
1
1
1
0
0
0

78
32
9
7
12
0
2
16

1,744
611
151
521
186
2
235
38

外注数
（
会社及び個
人）

合 計
無
1〜5 社未満
5〜10 社未満
10 社以上
回答不可

20
1
8
1
9
1

5
2
2
0
1
0

26
2
21
3
0
0

1,199
2
740
0
164
293

31
2
5
24
0
0

101
58
42
0
0
1

10
0
10
0
0
0

12
1
0
0
6
5

4
0
4
0
0
0

194
72
121
1
0
0

16
2
14
0
0
0

18
2
6
4
1
5

27
16
11
0
0
0

3
0
0
2
1
0

78
9
32
18
6
13

1,744
169
1,016
53
188
318

外注比率

合 計
無
1～20%未満
20～40%未満
40～60%未満
60～80%未満
80%以上
回答不可

20
1
0
6
0
6
7
0

5
2
1
0
1
0
1
0

26
2
0
6
3
7
8
0

1,199
2
1
382
126
654
33
1

31
3
0
0
28
0
0
0

101
58
0
12
0
0
30
1

10
0
10
0
0
0
0
0

12
1
0
6
0
5
0
0

4
0
0
0
0
0
4
0

194
71
7
38
73
4
1
0

16
2
1
0
0
0
13
0

18
2
4
2
4
1
0
5

27
17
0
2
8
0
0
0

3
0
0
0
0
1
2
0

78
8
13
19
10
3
14
11

1,744
169
37
473
253
681
113
18

元請・
下請

合 計
元請
下請
回答不可

20
12
7
1

5
0
5
0

26
11
15
0

1,199
741
458
0

31
30
1
0

101
55
46
0

10
0
0
10

12
5
7
0

4
4
0
0

194
22
171
1

16
14
2
0

18
9
9
0

27
11
16
0

3
3
0
0

78
42
36
0

1,744
959
773
12

合

20

5

26

1,199

31

101

10

12

4

194

16

18

27

3

78

1,744

計

劇場作品

アニメ（
劇場
CG
作品）
0
1
2
1
0
1
0

フル

アニメ（
劇場作品）
0
0
2
13
2
3
0

制作期間

1 週間未満
1 週間〜1 ヶ月未満
1 ヶ月〜半年未満
半年〜1 年未満
1 年～2 年未満
2 年以上
回答不可

予算規模

フル

カテゴリ

14

合計

2.3.1 制作期間
比較的制作期間が長い業務（2 年以上）がある、又は制作期間平均の長い（半年以上の割合が50%を超えるもの）カテゴリとしては、アニメ（劇場作品）、フル CG アニメ（劇場作品）、アニメ（テレビシリーズ）、フル CG アニメ（テレビシリーズ）、プレゼンテーション映像がある。

図 2.1

カテゴリ別

制作期間

2.3.2 予算規模
比較的予算規模が大きい業務（1 億円以上）があるカテゴリとしては、アニメ（劇場作品）、フル CG アニメ（劇場作品）、アニメ（テレビシリーズ）、遊戯台液晶コンテンツがある。特にアニメ（劇場作品）の 8 割以上が 1 億円を超える規模であることは特徴的である。

図 2.2

カテゴリ別

15

予算規模

2.3.3 尺
比較的尺の長い業務（120 分以上）がある、又は尺の平均の長い（60 分以上の割合が 50%を超えるもの）カテゴリとしては、アニメ（劇場作品）、アニメ（テレビシリーズ）、フル CG アニメ（テレビシリーズ）、VFX 実写（テレビシリーズ）、OVA 実写、アトラクション・博展映像（ライド）がある。

図 2.3

カテゴリ別

尺

2.3.4 制作人数（人月）
比較的制作人数の多い業務（300 人以上）がある、又は制作人数の平均が多い（50 以上の割合
が 50%を超えるもの）カテゴリとしては、アニメ（劇場作品）、フル CG アニメ（劇場作品）、アニメ（テレビシリーズ）、アトラクション・博展映像（ライド）がある。

図 2.4

カテゴリ別

16

制作人数（人月）

2.3.5 外注数（会社及び個人）
比較的外注数が多い業務（10 社以上）がある、又は外注数の平均が多い（5 社以上の割合が50%を超えるもの）カテゴリとしては、アニメ（劇場作品）、フル CG アニメ（劇場作品）、アニメ（テレビシリーズ）、フル CG アニメ（テレビシリーズ）、OVA アニメ、ゲーム（プリレンダ
ー）
、がある。

図 2.5

カテゴリ別

外注数（会社及び個人）

2.3.6 外注比率
比較的外注比率の平均が多い（60%以上の割合が 50%を超えるもの）カテゴリとしては、アニメ（劇場作品）、劇場用作品 VFX、アニメ（テレビシリーズ）、OVA 実写、プレゼンテーション
映像、アトラクション・博展映像（ライド）がある。

図 2.6

カテゴリ別

17

外注比率

2.3.7 元請・下請
カテゴリ別の元請・下請の割合は下記のとおり。

図 2.7

カテゴリ別

18

元請・下請

2.4

調査結果分析
表 2.4

カテゴリ別分析一覧

制作
期間

予算
規模

※1

※2

アニメ（劇場作品）○○

フル CG アニメ（劇場作品）
劇場作品 VFX
アニメ（テレビシリーズ）

○

○

○※7

○※7

○※7

フル CG アニメ（テレビシリーズ）

○※7

※7

○※7

VFX 実写（テレビシリーズ）

※7

※7

○※7

※3

制作
人数

○

尺

※5

外注
比率

○

○

○

○

○

※4

○

放送用オンエアグラフィックス
OVA アニメ
OVA 実写

外注数

○

※6

○
○

○
○

VP・CM・デジタルサイネージ
プレゼンテーション映像○

ゲーム（プリレンダー）○

ゲーム（リアルタイムムービー）アトラクション、博展映像（ライド）
遊技台液晶コンテンツ

○

○

○

○

※1 比較的制作期間が長い業務（2 年以上）がある、又は制作期間平均の長い（半年以上の割合が 50%を超えるもの）カテゴリに○をつけている※2 比較的予算規模が大きい業務（1 億円以上）があるカテゴリに○をつけている※3 比較的尺の長い業務（120 分以上）がある、又は尺の平均の長い（60 分以上の割合が 50%を超えるもの）カテゴリに○をつけている※4 比較的制作人数の多い業務（300 人以上）がある、又は制作人数の平均が多い（50 以上の割合が 50%を超えるもの）カテゴリに○をつけている※5 比較的外注数が多い業務（10 社以上）がある、又は外注数の平均が多い（5 社以上の割合
が 50%を超えるもの）カテゴリに○をつけている※6 比較的外注比率の平均が多い（60%以上の割合が 50%を超えるもの）カテゴリに○をつけている※7 テレビシリーズ（アニメ、フル CG アニメ、VFX 実写）の制作期間、予算規模、尺については、シリーズ全体としての回答と各話ごとに回答が混在している。そのため本表では、実際の回答に応じて記載している。フル CG アニメや VFX 実写の中には、○に該当するケースも考えられる。

19

「2.3 調査結果」を元に、本事業でターゲットとして考えるべきカテゴリについて分析を行うと、制作工程管理システムやクラウドを活用したレンダリングシステムについては、社内的には制作期間の長い業務や制作人数の多い業務、社外との関係では外注数や外注比率の多い業務に導入すべきであると考えられる。アニメ（劇場作品）とアニメ（テレビシリーズ）では全ての項
目があてはまる結果となった。
またカテゴリ別の合計予算規模について、全体の合計予算規模に占める割合をグラフ化した結果、8 割近くをアニメ（テレビシリーズ）が占める結果となり、遊戯台液晶コンテンツの 7%、
アニメ（劇場作品）の 5%で 9 割以上を占めていることがわかり、このことからも、アニメ（テレビシリーズ）とアニメ（劇場作品）がターゲットとして取り組むべきカテゴリであると考えら
れる。

1.1%
0.3%
0.1%
1.5%

0.5%
0.5%

0.3%

合計予算規模

0.1%
7.5%

5.1%

0.3% 0.7%

アニメ（劇場作品）
フルCGアニメ（劇場作品）

1.2%

劇場作品VFX
アニメ（テレビシリーズ）
フルCGアニメ（テレビシリーズ）
VFX実写（テレビシリーズ）
放送用オンエアグラフィックス
OVAアニメ
VP/CM/デジタルサイネージ
プレゼンテーション映像
ゲーム（プリレンダー）
ゲーム（リアルタイムムービー）80.6%

アトラクション、博展映像（ライド）
遊技台液晶コンテンツ

図 2.8

合計予算規模

20

2.5

まとめ

従来から、日本の制作体制は比較的小規模なプロダクションが多いといわれている。また、それらの小規模なプロダクションが連携しながら一つの作品を仕上げていくといわれていた。今回実施した最新の調査においてもその傾向を確認することができた。
今回の調査は、本事業において検討の対象として想定した CG・VFX 産業における、各社の業
務の規模や傾向を理解することを目的としている。そのため、市場や業界を網羅的に明らかにするものではなく、CG・VFX に関わる企業の、通常の業務規模を大まかに把握するために実施した。これらの調査の結果は、第 3 章、第 4 章の実証実験や、第 5 章の海外調査の際に、調査項目の設定の一つの目安として利用している。
今回の調査を通じて、現状においては日本の制作が比較的小規模のチームで実施されていることが確認できた。また、多くのケースで多数の外注企業が存在していることが分かった。そのため、大規模な制作案件では、「制作工程管理」や「クラウドレンダリング」については、各プロ
ダクションの独自の事情のみでなく、協業する他のプロダクションとの連携についても考慮する必要があることが明らかになった。
カテゴリごとでは、劇場作品やテレビシリーズでは、予算、制作人数が多く、複数年にわたる
プロジェクトが多数を占める一方、VP・CM に代表されるように、小規模なプロジェクトを短期間で実施するケースも多い。そのため、「制作工程管理」や「クラウドレンダリング」に関してスケーラブルな視点での検討が必要なことが分かった。
また、一部のプロジェクトでは、予算や制作期間、制作人数の規模が大きく、外注比率の少ないプロジェクトも存在していることも分かった。そのため、北米を中心とした大規模制作における「制作工程管理」や、クラウドレンダリングを含めた「レンダリング」体制についても調査する必要が明らかになった。
これらを踏まえ、3 章と 4 章の実証実験においては、様々なプロジェクトの規模においての「制作工程管理」や「レンダリング」体制などを、ヒアリングする。また、実証実験の実施やそれらの取りまとめに際し、プロジェクトの規模の視点を考慮に入れることとした。また 5 章の海外調査においても、大規模なハリウッド映画の事例に加え、小規模のプロジェクトにかかわる企業の調査を行うこととした。

21

第3章
3.1

制作工程管理システム

調査概要

3.1.1 概要
本章では CG・VFX 制作工程管理を効率的に行うための方策について整理する。具体的には、実証実験を行い、既存の CG・VFX 制作工程管理システムの検証及び制作工程管理ツールの導入により制作工程管理がどの程度効率化され、実際のコスト削減やクオリティアップなどにつながるかを検証すると共に、今後開発が望まれる機能や、標準化が必要な部分について検討する。
以上により今後の制作工程管理システムが満たすべき条件を示すことで、我が国の CG・VFX
業界が国際競争力を持った業界へ変化させていくことが期待される。

3.1.2 背景
現在、イギリス・ニュージーランド・カナダなど、英語圏のプロダクションが政府からの助成金や税制優遇などによりハリウッドからの仕事を大量に受注している。また、インド・中国・韓国・シンガポールなどアジアの国々も、欧米のプロダクションを誘致するなど、続々とインターナショナルな制作体制を整え外貨の獲得に乗り出している。一方、日本の映像産業は、需要と供給のバランスがある程度国内で取れているということもあり、国外との協業は進んでいないと言える。
日本の CG・VFX などの映像制作を取り巻く環境に関して、映像制作に必要な資金、設備、人材について欧米のプロダクションと比較する。まず、資金に関しては、映画産業の規模の差による制作費の差が大きい。次に、設備に関しては、ハードウェア、並びにソフトウェアのそれぞれに違いがあり、ハードウェアに関しては、コンピュータの導入台数に差がある一方、ソフトウェ
アに関しては、欧米のプロダクションで個々のアーティストが使っているツールの多くは国内でも手にすることができる市販のソフトウェアであり、その違いは少ない。最後に、人材に関しては、実際にハリウッドのプロダクションには、世界中から優秀な人材が集まっているが、国内のプロダクションと決定的な差はないと思われる。
大規模な作品制作には、大人数での制作体制が必要であり、それには、必然的に分業を行うためのワークフローとそれを円滑に進めるための制作工程管理システムが重要となる。ハリウッドの大規模プロダクションでは、そうした制作工程管理システムが導入されているが、日本では、大規模な作品制作の機会が少なく、そのような技術を開発は進んでいない。

22

一つのショットをつくり上げるために数人から数十人が関わる映像制作では、様々な市販のツール群を取りまとめ、円滑な作業を行うための制作工程管理システムの導入が極めて重要である。
この制作工程管理システムは、欧米では各プロダクションの制作体制に合わせ、自社で抱えているテクニカルプログラマーがそれぞれ独自に開発しているケースが多い。一方、日本の中小規模
プロダクションでは、制作予算の縮減から、プログラマーの人件費をプロジェクトごとに確保するのが難しい。そのため、直接生産に関わるアーティストの人数は確保されるが、直接生産に携わらないプログラマーは内部に抱えられない場合が多い。
ハリウッドのプロダクションでも大規模な制作体制を恒常的に維持するのは難しい。ハリウッ
ドの大手プロダクションでも大規模なプロジェクトが終わるたびに多くのスタッフを解雇する
ことによりプロダクションを維持している。日本の雇用体系では、そのようなやり方で会社を維持していくことは困難である。そこで、様々なプロダクションの制作工程管理システム構築を専門で引き受ける開発者集団の結成に需要があるとも考えられる。また、大規模なプロジェクトを行うには中小規模のプロダクションと提携した集合離散型のビジネス形態でのニーズも高まっている。そのような複数のプロダクションの間でのコラボレーション作業を円滑、効率的に行うためにも、共通の基盤整備と制作工程管理システムの構築が重要と考えられる。

3.1.3 調査体制
本調査は、平成 24 年度我が国情報経済社会における基盤整備事業（コンテンツ制作基盤整備事業）の一環として、「CG・VFX 共通基盤検討委員会」の下部組織である「制作工程管理システ
ム検討ワーキンググループ」によって実施された。実施に当たり以下の調査チームを作成した。


実施期間2012 年 11 月 6 日～2013 年 2 月 6 日



要員

大屋 哲男

株式会社ピクチャーエレメント 代表取締役

齋藤 精二

株式会社ピクチャーエレメント

道木 伸隆

株式会社ピクチャーエレメント痴山 紘史

株式会社日本 CG サービス 代表取締役社長

江畑 勝

株式会社エム・ソフト 映像事業部 映像部 課長代理

23

3.2

調査内容

本事業報告書では大きく 3 つの内容で構成されている。それぞれの概略をあげる。

3.2.1 ワークフロー運用ルール標準化に関する調査
ワークフローの違いや、使用するシステムによって制作工程管理の仕組みや構築する内容は当然異なる。
また、各会社間でのデータや成果物のやり取りの仕方についても、千差万別の方法が取られている。こうした状況を踏まえ、アセット管理と運用を効率的に行うに当たって、運用ルール
やデータの標準化を行うことにより効率化が図れるかどうかの検証を行う。

3.2.2 制作工程管理システム導入に関する調査システムを構築するに当たって必要なアプリケーションを調査・分類し、実際にそのアプリ
ケーションを利用することで、アプリケーションの有効性の検証を行う。ディレクトリ機能、アセットマネジメント機能、プロジェクト管理機能、レビュー機能を有する代表的なツールについての調査を行う。それらの中かから幾つかを選定し実際に検証を行う。

3.2.3 既存プロダクション実態調査
現時点での運用されているシステムの調査分析を行うため、いくつかの企業にヒアリングを行う。プロダクション内での運用ルールやインハウスツールについての調査、メリット・デメ
リット、将来の展望など調査する。
また、2D アニメプロダクションについては、ワークフロー上デジタル化できないためにおこる制作工程管理システム導入の障壁について調査する。

24

3.3

運用ルールに関する標準化

ワークフローの違いや、使用するシステムによって制作工程管理の仕組みや構築する内容は当然異なる。
また、各会社間でのデータや成果物のやり取りの仕方についても、千差万別の方法が取られている。こうした状況を踏まえ、アセット管理と運用を効率的に行うに当たって、運用ルールやデータの標準化を行うことにより効率化が図れるかどうかの検証及び提案を行う。

3.3.1 CG・VFX のアセットデータ管理と運用方法の効率化
(1)

従来の方式

現在、日本の実写映画制作のCG・VFX作業において
DPX 1というデジタル画像ファイルフォーマットが主に用いられている。
その理由として、数年前まではフィルム撮影が主体であったため、フィルムからのデジタルデータに変換（フィルムスキャン）を行うときに、より多くの色情報を格納する上で 10bit log というビット深度（色範囲）に対応しているファイルフォーマットを選択する必要があったこと、また ANSI 及び SMPTE 標準に規格されていることから、幅広い映像制作用のアプリケーシ
ョンでサポートされていたことも理由に上げられる。
デジタル撮影が増えてきた昨今においても撮影されたデータは上記の DPX 10bit log にデータ変換を行い、CG・VFX 作業に用いることが多いのが実情である。
なお、DPXの利用にはメタデータを付帯することができるという利点もあるが、現状では多くの場合、Reel
ID 2、Timecode 3といった素材の整理や編集管理での活用に限られている。

図 3.1

CG・VFX におけるワークフロー

加えて、昨今のデジタル撮影への移行に伴い、カメラの記録上でカメラ本体やレンズ等の各種セットアップといった幅広いメタデータを撮影時に記録することが可能となっているにもかかわらず、作業に於いて必要な様々な情報（撮影時のカメラ情報）は、現状、撮影時に人の手によ
1

Digital Picture Exchange

2撮影メディア毎の ID

3映像のコマ毎の所在時間とフレーム番号25

って記録、データベース化を行っている。

(2)

問題点

より多くの色情報を確保する目的でログ 4の状態で色情報を持たせたデータであるが、CG・VFX作業時のモニタリングのためにLUT 5というログからリニア 6への変換用データを当てて作業しなければならず、またアプリケーションなどの作業環境によっては、擬似的な作業用モニタ
リング環境上の色再現に過ぎず、本当に正しい最終的な色を見ながらの作業ができないこともある。
撮影された画像データに関しては上記のようにログという計算式を利用することで、より多くの色情報を確保する方法があるが、VFX 作業において 3DCG やデジタルマットペイントなど、デジタ
ル（PC）で生成される VFX 用素材については、作業環境やその成果物についてリニアの色範囲が基本になるので、色空間の違う「実写素材」と「CG素材」とを掛け合わせる VFX ショットの場合、色管理に時間や手間がかかることが多い。

(3)

改善提案

映画制作のVFX作業において、今後のデジタル
画像ファイルフォーマット候補として挙げられるがOpenEXRフォーマット 7である。
このフォーマットは様々な情報をマルチチャン
ネルで格納することが可能となっており、例えば
前述のような様々な撮影上のメタデータや、プリビズでの CG カメラ情報などをポストプロダク
ションに移行することが可能となる。

図 3.2

ワークフロー

以下に、撮影時及び編集時のメタデータを活用した場合のいくつかの事例を挙げる。
①

Camera ID：カメラ本体の情報
カメラ本体の ID を活かすことで、その映像がどのカメラで撮影されたかが判別できる。現在一つの作品の中で、多種多様なカメラが混在した撮影が行われているが、それぞれのカメラの特4対数表現された値。logarithm の略。

5ルックアップテーブル（Look Up Table）。ここでは色の値を変換する配列のデータ構造を意味する。
6線形性のある値。
7 Copyright (c) 2002-2011, Industrial Light & Magic, a division of Lucasfilm
Entertainment Company Ltd. All rights reserved. http://www.openexr.com/
26

性が異なるため、各ソフトの設定を個々に変える必要がある。それらを自動判別できるようになることで、ポストプロダクションや VFX 作業において、素材の検索や必要なアプリケーションのセットアップの効率を上げることができる。

②

Lens Data：レンズの情報撮影時に使用されたレンズの焦点距離や画郭という情報は、CG 合成など VFX ワークに広く活用されているが、これらのデータは各アプリケーション間でメタデータとして共有化できる。

③

Color Space：色空間の定義

映像品質の評価において、どの表示デバイスで評価するか、また、色空間についてどの規格で統一するかは非常に重要である。
撮影のデジタルカメラのセットアップはどの規格をターゲットにして行うかが決められるので、そのメタデータを活用することで、モニタのキャリブレーション等の各作業環境をどの規格で統一すればよいかを判断できる。
色空間の規格として、Rec.709 8やDCI 9といったものが挙げられるが、これらの規格を満たす
ハード・ソフトが自動的に必要なセットアップをロードできる形が理想的である。

④

EDL：編集情報

現状、VFX ショットの本編集への入れ込み作業は、1 カット毎に本編集オペレーターが手作業にて行っている。
各々のカットが最終的な編集上、何時何分何秒何フレームに位置するかといった情報（EDL情報）を、VFX ショットにメタデータとして付加させることで、本編集作業における VFX カッ
トのコンフォーム作業時間の短縮につながる。また、手作業によって起こりうる人為的なミスの軽減にもつながると期待できる。

(4)

調査

(1)～(3)を踏まえて、ファイルフォーマットとカラーマネジメント、メタデータについてそれぞれより詳細な調査を行う。

3.3.2 カラーマネジメントのワークフロー及びデータフローの確立(1)

従来の方式・歴史

映画におけるカラーマネジメントは、最終的な上映がフィルムだったため、これまではフィルムを念頭に行われてきた。その結果として、フィルムメーカーとラボ（現像所）に依存したワー
ITU-R Recommendation BT.709-5 http://www.itu.int/rec/R-REC-BT.709
Digital Cinema Initiatives によるデジタルシネマ用色空間
http://www.dcimovies.com/specification/
8927

クフローになっていた。現像にはケミカル処理での様々なコントロールが発生するため、規格化することは難しく、各ラボが独自のカラーマネジメントシステムを構築し、VFX プロダクション
はそのシステムに合わせた環境を個々に調整してきた経緯がある。
方式としては、スキャンニングされたデータに対して、各表示デバイスや環境に応じた LUT
をラボに作成してもらっていた。フィルムは、非常に高性能なメディアであり、モニタやプロジ
ェクタといった別の表示デバイスで再現することは難しく、カラーマネジメントもシミュレーシ
ョンのレベルに留まっていた。特に CG やマットペイントといったデジタル上でゼロから作成するものに関して、フィルム上での再現をコントロールすることは非常に難しかった。
近年のデジタルカメラの進歩や上映システムのデジタル化に伴い、それらの依存からは次第に解放されつつある。撮影から上映までが一貫したデジタルフローになることで、カラーマネジメ
ント環境をデジタルで統一的に管理することが可能になってきている。

(2)

問題点

多種多様なデジタルカメラが登場し、記録フォーマット等が独自のものになるケースが増えてきているため、それらを統一させるフォーマットの選択やワークフローの構築が必要となっている。
表示デバイスのスペック選択やキャリブレーションの慣習はカラーマネジメントにおいて重要な要素であるが、これまでのラボへの依存から、その他の環境では認知がまだ浅い。
CG やマットペイントの作成環境は入出力に対し比例したリニア環境であるが、撮影素材はフィルムからの流れもありログという対数の環境で取り扱うことが未だ多い。そのためそれらを一つに合成する際に、相互変換を伴うため、カラーマネジメントが複雑になってしまっている。

28

(3)

改善提案

最新のデジタルカメラは映像以外にメタデータとして、様々な情報を記録できるよ
うになっている。そのメタデータにカラー
マネジメントに付随する情報を埋込み、ポ
ストプロダクション・VFX 作業用フォーマットへ統一する際にそれらを継承することで、一貫したカラーマネジメント環境を構築できると考えている。
表示デバイスとしての規格として、
Rec.709 及び DCI を推奨規格（参照）とし、それらの規格表示を満たす表示デバイス導入を推進する。特に DCI はデジタルシネマの現在の世界統一規格であり、スペックを満
図 3.3

たすモニタの選択とキャリブレーションを

カラースペース

維持することで、上映条件に対する正確なカラーマネジメントを施すことができる。
また現在標準のフォーマットとなっている DPX（10bit log）から、scene-linear 環境構築が可
能な OpenEXR HF（16bit linear）への移行を推進する。

(4)

検証

A 社（VFX プロダクション）に対して、撮影オリジナルデータより、以下のメタデータを埋め込んだ形で、VFX 作業用に OpenEXR フォーマットを作成した。
「カラースペース」…DCI

「ガンマ」…gamma 2.6

「色温度」…撮影時の色温度「マッピングレンジ」（full range）

A 社の作業ソフトにインポートする際に上記メタデータが識別され、自動で同設定に対応するセットアップがロードされた。モニタに関しては DCI に対応したハードが設置されており、高い再現性を確認できた。また、「色温度」のように、撮影時の照明光源の計測値が分かることで、3DCG のライティングに活用ができた。

(5)

分析

カラーマネジメントのメタデータ活用において、ソフトウェア上の利便性を見出すことが確認できた。ハードウェアも含めた自動制御まで拡充できれば、より管理しやすい環境が構築できる。
またSMPTE 10が策定した「ACES 11」という色管理の規格もOpenEXRを利用したワークフロー
10

米国・映画芸術科学アカデミー
29

を提唱しており、同規格の普及が期待される。

3.3.3 カメラのメタデータ供給のための標準化
(1)

従来の方式

映画用フィルムでの映画撮影は現在も続いている。撮影時にはスクリプター（記録係）がカメ
ラ設定やシーン・カット・テイク番号などを紙に残していく。フィルムを回しスレートを映してから撮影本番がスタートする。記録したものは、あとで表計算ソフトなどを利用してデジタル化することもある。フィルムはスキャニングされデジタル化される。
近年、映像撮影において業務用カメラのデジタル化は隆盛し、活用される場が増えている。メ
モリカード、HDD、SSD に記録する映像データには、カメラから様々な情報（メタデータ）が付加される。しかしながら、収録された映像データの形式がメーカーごとに様々あり、メタデー
タも同様である。
一方、3DCG による映像制作も増え、実写との合成も多く行われている。合成において、仮想空間におかれたカメラと実カメラのレンズ情報などを一致させる必要がある。メタデータを VFX
作業者へ伝達することは重要な課題であるが、機材が変わるごとにその都度対応しなければならない。
完全な仮想空間を撮影する技法として、実写カメラと同様に扱えるバーチャルカメラという技法がある。この場合、カメラのパラメータやどのように空間を動かしたかというトラッキング情報は、3DCG ソフトウェアに取り込まれた形で保存される。

(2)

問題点



映像制作のパイプラインが進む過程でメタデータが欠損、消滅することがある。



カメラのメタデータは、メーカーごとに、又は製品の世代が変わるごとに変化する。



カメラのファームウェアによっても変わることがある。



カメラ用の専用アプリケーションが必要である。



3DCG では各種ソフトウェア間で読み書きできる Autodesk FBX 形式が用いられる。

スクリプターによるヒューマンエラーの危険性がある。

(3)

情報収集

現時点でデジタルシネマにおいて一般的に使用される業務用カメラを調査対象とし、それぞれのメタデータをリストアップする。3DCG では Autodesk FBX 形式を調査対象とした。

調査リスト

11

Sony F65RS

Academy Color Encoding Specification
30



ARRI Alexa

RED ONE-MX/EPICCanon C500/C300



Autodesk FBX

調査した詳細は付属資料を参照のこと。

(4)

分析

各社メタデータから、対応表を作成した。（付属資料として添付）
ここまでの調査から、以下の問題が分かった。


全てのメタデータの項目を含む形式は存在しない。



同一項目であっても、単位や表現方法が違うことがある。 例えば、シャッタースピードは小数、分数、周波数といった表現の違いがある。

(5)

メタデータを読み取るために専用アプリケーションが必要なケースがあった。

標準化に向けた提案

撮影後のポストプロダクションでの作業において、カメラのメタデータがパイプラインを正しく伝達することは、効率改善と品質向上に役立つと考えられる。どのカメラを使用しても、必要な情報を同じフォーマットで読み込むことができれば、作業者はカメラの違いを気にする必要もなくなる。フィルム撮影においては、スクリプターの独自記録法ではなく規格化された形式でのこすことができれば、これもまた同じことが言える。
ここでは規格化に向け、必要と考えられるメタデータのエレメントを提案する。
なお、一般社団法人カメラ映像機器工業会（CIPA）では、写真用のメタデータを含む画像ファイルフォーマットとしてExif 12規格（付属資料 11）を規格化している。映像業界の機材と近い関係でもあり、参考にすべきと思われる。

12

Exchangeable image file format。対応画像形式は JPEG、TIFF、JPEG XR（HD Photo）。
31

表 3.1
カテ ゴ リ

メタデータ規格標準化のための提案

名称

タイプ

カテ ゴ リ

名称

タイプ

TimeCode開始

String

日時

String

TimeCode終了

String

リール名

String

デュレーション

Integer

カメラ番号

String

アスペクト比フレームレート
ドロップフレーム

Float
Integer
Boolean

クリップ番号
クリップ名
プロダクション名StringStringString

解像度

Integer

監督名

String

シャッタースピード

Float

撮影監督名

String

ISO感度

Integer

プロジェクト名String

色温度

Integer

サークル名

String

撮影距離
露出（絞り）

Float
Float

シーン名
カット名

StringString

アパーチャー

Float

テイク名

String

焦点距離
ガンマ

Float
Float

ショット名
説明

StringString

ゲイン
シフト

Float
Float

場所
カメラのチルト

StringFloat

カーブ
カメラのセッ彩度
ティング情報色合い
コントラスト

Float
Float

カメラのロール
カメラのパン

Float
Float

Float
Float

Float
Float

ブライトネス

Float

カメラのX座標
カメラの位
カメラのY座標
置・動き
カメラのZ座標

デノイズ
NDフィルター

Float
Float

GPS高度
GPS経度

Float
Float

赤外線
手ぶれ補正

Float
Flag

GPS緯度

Float

電子ズーム
画角
カメラ情報

Flag
Float
-

レンズ情報

-

基本情報

文字情報

32

Float

3.4

既存ツールの検証

システムを構築するに当たって必要なアプリケーションを調査・分類し、実際にそのアプリケーションを利用することで、アプリケーションの有効性の検証を行う。ディレクトリ機能、アセットマネジメント機能、プロジェクト管理機能、レビュー機能を有する代表的なツールについての調査を行う。それらの中から幾つかを選定し実際に検証を行う。

3.4.1 調査項目の選定
本調査の実施に当たっては、ウェブサイト・展示会などから広く情報を集め調査アプリケーシ
ョンを選定した。実証実験では、リストアップしたアプリケーションから国内外で多く使われていると思われるものを優先して採用した。 また、メーカーからの貸出などの協力が得られることも考慮した。
表 3.2
製品名

メーカー名

JCGS Library

日本 CG サービス

RedmineJean-Philippe Lang

GanttProject

GanttProject Team

OmniPlan

The Omni GroupTACTICSouthpaw
Technology

5th Kind

5th Kind

ShotgunShotgun Software

RV

Tweak Software

COPRA

CinePostproduction

HIERO

THE FOUNDRY

wiredrive

wiredrive

Keyframe
Concept

Drylab調査アプリケーション

選定理由
ディレクトリ管理機能とアセットマネジメント機能を有する、日本で唯一の専用サービスであるため。
ヒアリングの結果、ソフトウェア開発や web サイト制作など IT プロジ
ェクトでの利用で広く使われていたため。また、上記以外の業務でも使用されることも多く、映像業界での応用の可能性を持っていると考えられる。
オープンソース・ソフトウェアとして入手性もよく、機能が絞りこまれており、あらゆる業種で使用出来るため。
ヒアリングの結果、過去の映像作品の制作に導入された実績があったため。また、映像制作専用のソフトウェアとの比較対象としても必要であった。
ヒアリングの結果、北米での制作工程管理システムとしてはよく知られていたため。また、オープンソース化され調査がしやすいことも考慮した。
北米で 2012 年に発表され、多くの最新機材に対応しているため。
ヒアリングの結果、海外のプロダクションも含め、ハリウッド作品を手がけるプロダクションで最も多く使用されていたため。
ヒアリングの結果、Shotgun と連携して使用されていることが多かったため。
独 Cine Postproduction 社の協力により、無償にて調査を実現できたため。
海外作品での実績もあり、実用に耐えうると考えられることも考慮した。
the Foundry 社の協力により、無償にて調査を実現できたため。
また、同社の編集ソフトウェア・Nuke が国内複数の事業者で導入されている点も考慮した。
映像クリップ管理機能を有し、レビューシステムとしての使用が見込まれるため。
映像クリップ管理機能を有し、レビューシステムとしての使用が見込ま
れるため。

33

3.4.2 システムの重要性(1)「映像制作のためのシステム」を作る

映像制作のための制作工程管理システ
ムは、ベースになるシステムやアセット管理、プロジェクト管理が有機的に連携をして一つのシステムとして稼動して初めて意味をなす。システムを構成する個別のツールに関しては既存のものでいいものがあれば利用することで、開発や保守のためのコストを削減することができる。また、開発コストも別の部分に割り当てることができる。
本事業で検証するのは、図 3.4 の明るい
青色の部分である。システムとして構築す

図 3.4

映像制作のためのシステムるに当たって特に注力しなければいけな
いのが、情報のやりとりを示す青色の矢印の部分である。この部分をしっかりと作ることで、各要素が連携したシステムとして稼動することを可能にする。更にもう一つ重要なのが、このような"システム"はそれを運用するための人材やルール、教育などがあって初めて正常に稼動するということである。例えて言うならば、新幹線というシステムを構築・運用するには時速 300Kmで走行できる車体が必要なのは当然として、それを走らせるためのレールや、時刻表通りに運用するための現場の教育、トラブルを未然に防ぐためのチェック体制などが一体となって初めて日々の運行が可能となる。ここまで含めて初めて「システム」と言うことができる。

(2)

システムの重要性の認識

大企業の生産工場ではミスを防ぎ、品質を上げ、生産効率を上げるために古くから生産管理シ
ステムが導入され、今日では中小規模でもシステム導入がなされている。近年では、大規模農場
経営においても管理システムの導入のための研究がなされるなど、あらゆる業界において、IT化による管理システムの導入は世界的なスタンダードであると言える。
映像業界も例外ではなく、既に欧米の大手プロダクションを中心に制作工程管理システムが導入され、徐々に業界全体に浸透し始めている。一方、日本国内では、長い歴史の基に成長してきた独自の商習慣や決め事があり、実写・CG・アニメといった業界ごとでもそれぞれ事情が異なっており、管理システムの導入は進んでいない。これらの障害を乗り越えるため、以下の提案をする。
ファイル・パスのネーム・コンベンションの統一

34



ヒューマンエラーを防ぐためのパイプラインの自動化



プロジェクト管理システムの導入



共通のファイル形式(OpenEXR 等)へ移行



新しい色管理(ACES)の今後の普及と速やかな対応

メタデータの統一



セキュリティの確保

制作工程管理システムの導入のためには、社内 SE が必要となる。間接部門に相当するため、経営層とのコンセンサスが必要である。いかに導入と運用コストを見積もり、総合的にみてコスト低減を図るかが重要である。

3.4.3 ディレクトリ管理機能とアセットマネージャー機能検証(1)

ディレクトリ構造解説①

ディレクトリ構造を定義する意味

制作体制を構築する上で最初に着手しなければいけないのが、アーティストが制作したデータを格納するためのディレクトリ構造の決定である。ディレクトリ構造が決められないとデータがサーバ内に散乱してしまい、どこにどのデータがあるのか、最新のものはどれなのかといった状況の把握が困難になってしまう。
また、個々人やプロジェクト毎に統一性のないディレクトリ構造を採用してしまうとシステム化もできなくなってしまう。そのような状況下で、あるプロジェクトで開発したツールを別のプ
ロジェクトで流用しようとするとプロジェクト毎の修正や開発を行う必要が出てしまい、ツール化したメリットを十分享受することができなくなってしまう。
そのような事情もあって、海外の大手プロダクションではプロジェクトに依存しない社内共通のディレクトリ構造が採用されている。また、このディレクトリ構造は細かな差異はあっても基本構造はどこも似たようなものとなっている。
プロジェクトで使用するディレクトリ構造は論理的に階層化をされ、誰が見ても一目で構造が把握できるようにしておくべきである。こうすることで、以下のようなメリットが生じる。


構造を明示的に決めておくことで、説明が簡単になる

プロジェクトをまたいで仕事をしても戸惑うことがないドキュメントを統一できるので、ドキュメンテーションコストの削減と品質の向上を期待できる

一度ツールを作成すれば他のプロジェクトでも使い回しが可能になる

35



階層化をしておくことで、必要がなくなったデータのみを選択してバックアップや削除を行うことができる②

通常のプロダクションで使用される構造

日本のプロダクションの場合はツールを使用してデータにアクセスしない場合が多いので、プロジェクト階層の浅い部分に大量のディレクトリを作成してそこで作業を行うことが多い。また、プロジェクトの管理自体が人ベースで行われるので、プロジェクト階層直下に user や work といったディレクトリを作成し、その下にアーティスト毎のディレクトリを作成してその中で作業が行われる。そして、これらの構造は社内で統一されていることはほとんどない。そのため、多くの場合どこに何のデータがあるか把握できるのは作業者のみとなってしまう。
作業者自体もどこにどのようなファイルがあるのか把握ができるかというと実はそれも難しい。日本では一人のアーティストがモデリングからレイアウト、アニメーション作成、レンダリ
ング、コンポジットまで全ての段階で関わることが普通なので、必然的に作業ディレクトリ内にもそれらのデータが混在することになる。そのような中から必要なデータを探し出すのは困難であり、ましてやプロジェクト終了時に必要のないデータを整理して最小限のファイルのみバック
アップを取るのは非常に難しい。
その結果、安全のためにプロジェクトが終わるまで可能な限り全てのデータをサーバに残すよ
うにし、データ整理の必要性に迫られた場合には、ある程度のリスクを認識しながらデータを消すこととなる。

③

階層化されたディレクトリ構造

本事業において提案するディレクトリ構造は以下のような形となっている。

図 3.5

ディレクトリ構造36データが整理できなくなる一番の原因は、異なる分類のデータを脈絡なく同一の場所に格納してしまうことにある。そこで、構造化したディレクトリ構造を導入し、一貫性を持ってデータの管理を行うことが重要である。
assets と shots、それぞれの階層の構造や深さは同一になっている。また、情報を階層化して階層を順に辿ることで簡単に必要なデータにアクセスすることができるようになっている。
階層化された分類の中では、同一階層には異なる概念・粒度のものは配置しないようにする。
図中のオレンジの部分は通常は一般のアーティストが作成・管理を行うことはせず、プロジェ
クトマネージャー（PM）やコーディネーターといった制作管理を行うスタッフが管理する。何かアセットを作成する場合、まずは管理スタッフが DB への登録やディレクトリの作成を行い、その後タスクをアサインされたスタッフが work 以下に自分の作業用ディレクトリを作成し、そこ以下で作業を行う。work 以下の構造については後述する。

(a)assets と shots

大きな分類として assets と shots に分かれている。
assets はアセットと呼ばれるキャラクタや武器、背景などプロジェクトを通して汎用的に使われるものを格納する。対して、shots はアニメーションやエフェクト、コンポジットデータなどカット毎のデータを格納する。

(b)

assetsassets 階層の下には大分類で分けるための category 層がある。まずはここでアセットを大まかに分類する。例として、human、BG、weapon、rig などが考えられる。大分類で分ける場合、あまり細かく分けすぎても大まかに分けすぎてもどこに何があるのかわかり辛くなってしまう
ので、適切な粒度で分類することを心がける必要がある。
category 層の下には elements 層がある。アセットとしては、この部分が一つの種類になる。
例として sato、car、AK47、meetingRoom などがある。
elements 層の下には variation 層がある。この variation 層で、アセットのバリエーションを作る。例えば、佐藤というキャラクタでも状況によって服装が違うことがある。また、小物によっては壊れたり変形したりすることもある。このような違いをこの階層で分類する。例として
Hero、Suit、Break などがある。Hero（ヒーローモデル）は英雄的な姿をしているものを指すのではなく、一般的に最もよく使われ、最も作りこまれているものを指す名前である。
分類を行っているとどこに所属させるべきなのか迷うものが必ず出てくるが、そこはあまり深く考えすぎずに近いと思われるものの中に配置するようにしておけばよい。
この階層の目的はアーティストに大きな負担を掛けずにアセットを探すことができるようにすることが目的なので、それを常に念頭に置いて配置を行う。

(c)

shots

shots 階層の下は話数や OP、ED のような大まかな分類を行う episode 層が存在する。その下には sequence、shot（日本で一般的に言うカット）と続く。

37

(d)

作業ディレクトリ

assets、shots 共にアーティストは work ディレクトリ以下に自分の作業領域を作成して、そこで関連する作業を行う。work 以下の緑色の領域はユーザーが作成し、その中の構成も各自で管理を行う。通常はアプリケーション用のワークスペースを作成し、その中で作業を行うことになる。ワークスペースに関してはアプリケーション名で作成する方法もあるが、一つの作業スペー
スに複数ワークスペースを作成したい場合に問題になるのであまり推奨しない。model、rig のように作業名でワークスペースを作成するのが望ましい。
このように各アセットやショット毎に作業領域を作成するので、アーティスト一人につき複数の作業スペースができる。

(2)

既存プロジェクト情報収集①

アセット情報収集

下図は、実際のプロダクションにおいてアセット管理システムで取得できる情報の集計をとったデータの一部である。全てのアセットはバージョン管理されており、ある段階で承認が取れた
らパブリッシュを行う。この表は、パブリッシュされた日付やその時のリビジョン番号、関連するファイル数、リビジョン全体のファイルサイズの集計を行っており、この情報がプロジェクト全体の全てのリビジョンについて記録されている。
左側が取得した生のデータで、右側はそれを使用しやすいように加工を行ったものである。今後は、このデータを集計し、情報をまとめていく。

図 3.6

アセット管理情報集計

38

(a)

プロジェクトのアクティビティ

プロジェクトのアクティビティを視覚化するには、一定期間ごとにパブリッシュされたリビジ
ョンの数を集計するのが目安になる。
図 3.7 を見ると、アセット作成が 2011 年 48 週前後（11 月頃）に最初のピークを迎え、次に2012 年 30 週（7 月頃）にもう一度活発になっていることがわかる。週に 100 回ほどパブリッシ
ュされている週があるがこれは前後の情報と比べてあまりにも突出しすぎているので、ツールのテストやその他何らかの理由により極端にパブリッシュが行われたのではないかと推測される。
この週を除けば、ピークでも週に 50 回ほどパブリッシュされる程度の作業量があり、これがチーム全体の最大の生産力だと推測される。

図 3.7

(b)

週毎のパブリッシュ回数（アセット）

プロジェクトの効率

一つのアセットに対して何度も承認とパブリッシュが行われているものは手戻りが多数発生している可能性があるという指標になる。この情報をグラフ化した。

図 3.8

アセット毎の最大リビジョン番号39

ほとんどのアセットは 1～3 回程度のパブリッシュで済んでいるが、中には 30 回以上修正を繰り返しているアセットも存在する。このようなアセットが見つかった場合、なぜそのようなことが起こったのか確認をする必要がある。

(c)

プロジェクトの規模

プロジェクトの規模に関しては、アセット数、総リビジョン数、ファイル数や総ファイルサイ
ズにより集計することができる。以下が基本情報になる。
表 3.3

プロジェクトの規模の基本情報

項目

値

アセット数

732

総リビジョン数

638

リビジョン当たりの平均フィルタ数

51.18

リビジョン当たりの平均データサイズ

430 MB
35

最大リビジョン番号

もちろん、これ以外にも更に詳細な情報や別の視点からの情報も必要に応じて確認することができる。図 3.9 は本事業の統計調査の結果から、ディスクの論理最大使用量をグラフ化したもの
である。

図 3.9

累積サイズ（アセット）

このグラフから、プロジェクトを通してアセット管理システムで管理されているアセットのト
ータルのサイズは最大でも 600 GB であり、最大でもこの全てのファイルをバックアップすればプロジェクト内で使用されているアセットは全てカバーできることが分かる。
ただし、600 GB という容量は何度もパブリッシュされたファイルの情報が重複してカウントされており、実際に消費しているディスクスペースはこの数分の一から数十分の一サイズであると考えられる。

40

また、何度もパブリッシュされてリビジョンが重ねられたアセットのほとんどは最新リビジョ
ンのみがショットで使用されていることを考えると、適切に管理されたアセットマネジメントシ
ステム上では数 10 GB 程度のファイルさえ保持しておけばプロジェクトで必要なアセットデー
タが全て保持できるということになる。
なお、本調査でモデルとしたプロジェクトではアセット管理システムで管理されていない付加
データもバックアップを行っており、そのサイズは 10 TB であった。これほどのデータ量のバッ
クアップは難しいが、このうちアセットデータは 600 GB、ショットデータを含めても最大で 2
TB 程度のデータ量となることが分かった。
この程度のデータ量であれば、バックアップのための負荷も大幅に軽減することができる。

②

ショット情報ショットの情報も、アセット同様に集計した。

図 3.10

図 3.11

週毎のパブリッシュ回数（ショット）

ショット毎の最大リビジョン番号41

図 3.12③

累積サイズ（ショット）

まとめ

これまでプロジェクトの管理者の勘と経験によってのみ把握されていた制作管理に関する情報が数値化され、集計されることの意義は非常に大きい。
本事業で集計した情報は、アセット管理システムから得られるもののうちほんの一部である。
このような情報を適切に集計し、プロジェクトの形をはっきりとさせることはプロジェクト管理を行う上で非常に重要なことである。
更に、一つのプロジェクトだけではなく年間を通して全てのプロジェクトに対して同様な情報を集計し、組織全体の形を明確にすることが、その後の組織運営のための指針となる。そのためには自ら情報をコントロール下に治め、必要な情報を必要な時に取り出すことができるようにしておく必要がある。

④

プロジェクト情報収集時に遭遇したトラブル（ファイルに張られたハードリンクの数を取得できない）

ツール側でディスク容量を削減するためにハードリンクを多用する構造になっているが、Windows Server と Windows の組み合わせでファイル共有を使用していると、どのファイルが幾つハードリンクを作られているのか把握ができないという症状に遭遇した。
ハードリンクの数を取得することができれば、ハードリンク数×ファイルサイズを計算することで本来必要だったディスク容量と実際に使用されている容量を知ることができ、具体的にどれだけ容量が削減されているか調査をすることができる。
本事業で計測を行っている環境ではそのような精度の高い計測を行うことができなかったた
め、同一内容のファイルがどれだけ存在するかという情報を収集し、そこからディスク使用量の上界と下界を推計することとした。

42

3.4.4 プロジェクトマネージャー検証(1)

プロジェクトマネージャーにおけるROI（Return On Investment） 13①

ROI 計測の必要性

プロジェクトマネジメントシステムを導入するに当たって最初の課題となるのは、「そのシステムを導入することでどの程度コスト削減ができるのか」ということである。この情報を客観的な数値として判断するのは難しく、そのためにシステムの絶対的な金額によってのみ高い・安いという判断が行われがちである。
しかし、実際には絶対的な価格の高低というのは判断基準としては適切ではない。本来判断すべきは、掛けた投資に対してどの程度リターンが得られたかという視点である。ここでは、具体的な例を用いてシミュレーションを行う。

②

Shotgun × Zoic Studio

Shotgun SoftwareがZoic Studioでの導入事例 14を紹介している。このケースを例にシミュレーションを行ってみる。
この資料の中で、ROI について以下のような言及がされている。
“In the last six months we’ve realized truly astronomical labor cost savings. In a
6-month period the tools were used about 13,000 times, reducing our labor hours
from 24,000 hours to 150 hours. That translates into important, significant costsavings.”
この例によると、6 か月のプロダクション期間でツールが 13,000 回使用され、ツールが無け
れば 24,000 時間必要とされた作業が 150 時間にまで削減されたということになっている。
24,000 時間が 150 時間というとにわかには信じられない数値であるが、もう少し具体的な数値で考察を行う。
テレビシリーズの大規模プロダクションということで、100 人ほどのスタッフが 1 日 10 時間、
月 20 日稼働したとする。すると、6 か月の プロダクション期間で 100(人)×10(時間)×20(日)×6(月)=120,000(時間)の時間が費やされたことになる。
この総計 12 万時間のうち 2 万 4000 時間が削減されたということであり、全体としては 20%程度の効率化となる。これをグラフにすると図 3.13 のようになる。
この例を見てみると、それほど現実離れした数字ではないということが確認できる。

13
14

投資利益率。Return On Investment。
http://shotgunsoftware.com/docs/Shotgun_Zoic_CaseStudy_Aug-2010.pdf
43図 3.13③

Shotgun 導入前後で必要時間の比較

ROI シミュレーション

ROI の計測についてもう一つ重要なのは、得られたリターンが投資に対して適切なものであるか。という評価である。前述の Zoic Studio の例では 24,000 時間の削減が得られたが、このための費用は適切なものであろうか。
まずは、作業にかかる時間を削減することで減らすことのできる費用を計算してみる。映像制
作プロダクションで最もコストがかかるのはアーティストの給料である。そこで、平均で月$10,000 のコストが一人当たりにかかるという前提でシミュレーションを行ってみる。前述の前提条件として月当たりの稼働時間は 10(時間)×20(日)であるため、時給換算では$50 となる。合
計 24,000 時間が削減されたとすると、$50×24,000=$1,200,000 の削減効果があったということになる。
Shotgun はアーティスト一人当たり毎月$80 のコストがかかる。つまり、6 か月のプロダクシ
ョンでは 80×100×6=$48,000 のコストがかかっている。また、Shotgun と社内のパイプライ
ンをインテグレートするための専任のエンジニアも必要であり、これが二人いるとすると、そのための費用として$10,000×2(人)×6(ヶ月)=$120,000 がかかるので、総計で$168,000 のコストがかかっている。この前提であれば、$168,000 の投資に対して$1,2000,000 のリターンが得られたことになるので十分な効果が挙げられているということになる。

④

日本でのケース

日本でのケースをシミュレーションしてみる。
日本では海外プロダクションに比べて低賃金・長時間労働の傾向が高いため、月$5000、一日
12 時間労働と仮定する。また、Shotgun にかかる費用は同等（ソフトウェアライセンス代+エン
ジニア一人ないし二人）とする。
この前提で、プロダクションの規模を変えながらシミュレーションを行ってみる。

44

(a)

ケース 1：小規模プロダクション

小規模のプロダクションとして 5 人程度のプロダクションを例にすると以下のようになる。ただし、エンジニアは一人とする。
ライセンスの導入と、専任エンジニア 1 名を雇用した場合、全体的なコストとしては 21.6%増加する。具体的には一人当たり毎月 51.84 時間の削減効果があるか、が判断基準となる。
このように規模が小さいとシステム導入のためのコストの、全体に対するインパクトが非常に大きくなってしまう。
月当たりの運営費用 : $5000×5=$25,000
Shotgun 導入時の月当たりの運営費用 : $5000×5+$80×5+$5000×1=$30,400
差額: $30,400-$25,000=$5,400(21.6%の増加)
ライセンスの導入と、専任エンジニア 1 名を雇用した場合、全体的なコストとしては 21.6%増加する。具体的には一人当たり毎月 51.84 時間の削減効果があるか、が判断基準となる。
このように規模が小さいと、システム導入のためのコストの全体に対するインパクトが非常に大きくなってしまう。

(b)

ケース 2：中規模プロダクション(1)

中規模のプロダクションとして 50 人程度のプロダクションを例にすると以下のようになる。
月当たりの運営費用 : $5000×50=$250,000
Shotgun 導入時の月当たりの運営費用 : $5000×50+$80×50+$5000*2=$264,000
差額: $264,000-$250,000=$14,000(5.6%の増加)
ライセンスの導入と、専任エンジニア 2 名を雇用した場合、全体的なコストとしては 5.6%増加する。そのため、それ以上の削減効果が得られれば導入するメリットがあると言える。具体的には一人当たり毎月 13.44 時間の削減効果があるか、が判断基準となる。

(c)

ケース 3：中規模プロダクション(2)

中規模のプロダクションとして 100 人程度のプロダクションを例にすると以下のようになる。
月当たりの運営費用 : $5000×100=$500,000
Shotgun 導入時の月当たりの運営費用 : $5000×100+$80×100+$5000×2=$518,000
差額: $518,000-$500,000=$18,000(3.6%の増加)
ライセンスの導入と、専任エンジニア 2 名を雇用した場合、全体的なコストとしては 3.6%増加する。そのため、それ以上の削減効果が得られれば導入するメリットがあると言える。具体的には一人当たり毎月 8.64 時間の削減効果があるか？が判断基準になる。

45

⑤

シミュレーション結果まとめ

上記シミュレーション結果をグラフにすると図 3.14 のようになる。
グラフを見ての通り、人件費を含める各種費用の上昇に比べてシステム導入コストは安いので、規模が大きくなればなるほど導入に対する敷居は下がっていく。大まかに一割程度業務が改善されればペイできると考えれば、25～30 人規模のプロダクションであれば導入を検討する意味が出てくると考えられる。

図 3.14

ROI シミュレーション結果

46

(2)

Redmine①

Redmine 機能検証

Redmine の検証を行うに当たって、本プロジェクトで実際に Redmine を導入し、運用しながら機能やより良い使用方法の検証を行っている。また、Redmine の外部プラグインである
Backlogs も併せて使用している。

(a)RedmineRedmine は、主にソフトウェア開発の現場で使用されているソフトウェアである。オープン
ソース・ソフトウェアとして開発されており、誰でも自由に使用・改変を行うことができる。
Redmine 上ではプロジェクトを完遂するためにこなさなければいない作業をチケットとして管
理する。

(b)

Backlogs プラグイン

Backlogs プラグインは、Redmine 上でアジャイル開発の手法を実現するためのものである。
Backlogs を使用することで、実現すべき内容のリストアップ（Story）、一定期間内にこなすべきタスクの管理（Sprint）、タスクを完了するために消化しなければいけないチケットの一覧（Task board）などの管理を行うことができる。
(ⅰ) 注意本事業はプロジェクトの項目が最初に決まって、スプリントなどアジャイル手法は使用しないので本来の Backlogs プラグインの使い方とは違うものになってしまっている。
(ⅱ) Master Backlog の表示
Redmine のプロジェクトページを開くと、Backlogs(日本語ではバックログ) メニューが表示されているので、そこを開く。
すると、マスターバックログが表示される。
マスターバックログで大項目と中項目の管理を行う。

図 3.15Backlogs メニュー47

図 3.16

Backlogs マスターバックログ(ⅲ) Task board の表示とタスクの管理
大項目の左上メニューから Task board を選択すると、細かいタスク管理を行うための画面に移動する。

図 3.17

Backlogs タスクボードを開く

ここで中項目毎のタスクの管理を行う。

48

図 3.18

Backlogs タスクボード

中項目やタスクの詳細を知りたい場合は、数時の部分をクリックするとチケット管理画面に移動してより詳細な情報を見ることができる。

(c)

Redmine+Backlogs の問題点

WBS で作成したタスクの階層関係と Sprint で扱う階層関係が異なるが、どちらか一方でしか管理ができない

特定の日をマイルストーンとして扱うことができない（Version を使用するという運用方法はある）



Forum、Documents、Wiki の扱いをどのようにするか、少々混乱を招く。

Document を使用するより、Wiki にもファイルを添付できるのでそちらを利用した方がい
いのでは?



②

Gantt chart はあるものの、表示だけで直接スケジュールの編集ができない

Redmine のカスタマイズ

Redmine は映像制作管理のためのシステムではないので、映像制作を行う上で必要な機能が十分に揃っていない。例えばサムネイルの表示や、ムービーのプレビュー機能、実ファイルとカッ
トリストの連携などである。
本項ではそれを補う一例として、Redmine の表示をカスタマイズしてサムネイル表示に対応した事例を紹介する。

49

図 3.19

Redmine のカスタマイズ

この例では HTML 生成部分を改変し、ファイルへのパスが存在したら画像を表示するようにしている。また、表示項目も幾つか追加を行ってプロダクションで必要な情報を表示するようにしている。
このような改変を行うためには開発に関するある程度のスキルを必要とするが、必要であれば機能を追加して運用できるというのは、Redmine がオープンソースで開発が行われていて全てのソースコードにアクセスできるからである。
ただし、カスタマイズを行えば行うほどメンテナンスをするためのコストも増加するため、得られるメリットとその他デメリットとの比較を慎重に行って、本当にカスタマイズが必要なのか、
ワークフローを変更することで対応できないのかといったことを検討する必要がある。

③

Redmine と Excel の複合環境の検証

(a)

検証概要

通常、プロダクションで制作管理を行う場合は Excel が使われることが多い。これは、以下のような理由からである。


どこのプロダクションでも使用されており、データのやりとりがしやすい

使用することのできる人材が豊富

長年使われてきて、現場のスタッフも慣れている

その場その場に応じた、シートの細かいカスタマイズが可能

50

反面、数人～数十人若しくはそれ以上が関わるプロジェクトでは Excel 管理の限界に突き当たってしまう。



複数人で同時に編集・更新ができない

しばしばファイルがロックされてしまい、仕方なく別名保存されることでマスターがどれかわからなくなってしまう

上記理由により、パイプラインに組み込んで自動的に情報を更新することができない

がんばれば何でもできるが、一般的なプロジェクト管理に向いた機能（例えばガントチャート）というものは存在しない

これらの問題を解決するため、他業種では Microsoft Project (MS Project)が、ソフトウェア開発の現場では Redmine のようなオンラインでタスクを管理できるシステムが導入され、活用されている。
MS Project は非常に強力ではあるものの、映像業界内での普及率は低く、プロダクション間でのデータのやりとりに使用するのは現実的ではない。また、MS Project を使いこなせるだけの知識を有する人材も少ないため、導入して即座に活用するということも難しい。
そこで、現時点での現実的な案として、制作管理の現場では Excel を引き続き使用し、制作チームでは Redmine を用いたタスクの管理を行うことを目指す。

(b)

メリット

この方法の利点は、現状の流れを大幅に変更することなく Excel と Redmine 双方の欠点を補うことができることにある。
制作管理者は高々数名程度であり、普段から近い位置で仕事を行うことが多い。この程度の規模であれば Excel の欠点である同時編集が不可能というものも注意して回避することができる。
また、制作現場は Excel シートを開かなくても Web ブラウザで現在の状態をリアルタイムかつ多角的に認識することができ、フィルタリングを行うことで自分に必要な情報を得ることができる。更に、ツールを使用して Redmine の情報を自動的に更新することができるようになれば、進捗情報のまとめなどの煩わしい作業から解放され、よりクリエイティブな部分に意識を集中で
きる。

(c)

xlgan

日本 CG サービス（JCGS）が開発した xlgan は、
各種プロジェクト管理情報を一元管理するための Hubに な る ツ ー ル で 、 こ れ を 介 す る こ と で Excel 、GanttProject、Redmine などで自由にやり取りすることができる。
元々は Excel と GanttProject 間の連携を行うためのツールとして開発を行い、Redmine への対応も順次進めら
れている。

51

図 3.20

xlgan

(d)

検証内容

具体的には以下のような流れを検証する。
1.

制作管理者が Excel でアセットリストやカットリストからタスクリストを作成する。

2.

Excel で作成したタスクリストを Redmine に登録する。この際、Redmine に登録された時点でチケット番号が割り振られるので、Excel 上のタスクにも番号を割り振る。

3.

アーティストは Redmine の情報を元に作業を行う。

4.

publish を行ったタイミングなどで Redmine の進捗情報を更新する。

5.

制作管理者は、日々更新される進捗情報を Excel に書き戻す。

6.

Excel で更新された情報のうち、必要なものを Redmine にアップロードする。

(ⅰ) Redmine REST API の有効化
Redmine に対して外部からアクセスするには、REST API 経由で行う。デフォルトではこの機能は有効になっていないため、このための設定を行う必要がある。
まずは、Redmine 上で REST 経由での制御を有効にする。Administration メニューの中にある、Setting-Enable REST web service にチェックを入れる。

図 3.21

Redmine Settings52

(ⅱ) API Access Key の取得
続いて、アクセスキーの取得を行う。自分のアカウント設定画面右側に API Access key という項目が増えている。ここで、 Show をクリックするとアクセスキーが取得できる。プログラム
からアクセスするときには、このキーを用いて行う。

図 3.22

Redmine My Account(ⅲ) xlgan
xlgan では、異なる環境やプロジェクトでも利用できるよう、設定ファイルで Excel シートのどの部分を使用するか決めることができるようになっている。Excel の設定では、日付の開始セ
ル、id やタスク名、タスクの開始日などが記述されているセルを指定する。

図 3.2353

xlgan

Excel 表には各プロダクションや個人毎にバリエーションは存在するものの基本となる形は全て同じなので、このような設定ファイルを用いて違いを吸収することでどのようなケースでも対応可能になる。

(ⅳ) 実データを用いた検証
プロダクションにて使われた実データを元に、xlgan の動作検証を行った。実データにアクセスできる環境では Excel が用意できなかったため、その場では Redmine と GanttProject 間で情報のやりとりを行
い 、 GanttProject で 更 新 し た ス ケ ジ ュ ー ル を
Redmine に反映できることを検証した。
検証に用いた xlgan は開発中のため、コマンドライ
ンから動作をする。図 3.24 は、動作中の画面である。

図 3.24xlgan のコマンド実行画面(ⅴ) Redmine の情報を GanttProject データとして書きだす
Redmine に登録されている情報を GanttProject のデータとして出力するための検証を行った。
GanttProject は外部から直接データを更新する手段が提供されていないため、xlgan はRedmine か ら 取 得 し た デ ー タ を 基 に GanttProject の プ ロ ジ ェ ク ト フ ァ イ ル を 生 成 し 、GanttProject はそのファイルを読み込むようにする。
xlgan を実行することで Redmine の情報が読み込まれ、GanttProject のデータが生成される。
このデータを開くと、下図のように GanttProject 上で情報が再現されている。

図 3.25

Redmine から GanttProject へ変換出力

54

(ⅵ) GanttProject 上でスケジュールを調整した上で Redmine の情報を更新する
xlgan によって生成された GanttProject のプロジェクトファイルを読み込み、GanttProject
上でスケジュールの調整を行い、ファイルに保存する。
xlgan は GanttProject のプロジェクトファイルを解析し、Redmine の情報の更新を行う。
この操作を行った結果が下図である。GanttProject で変更されたスケジュールの情報がRedmine 上で再現されている。

図 3.26

GanttProject から Redmine へ変換出力(ⅶ) Excel と Redmine の連携の検証
実データを用いた検証では Excel との連携が検証できなかったので、本事業で使用しているタ
スクのデータを用いて別途 Excel との連携の検証を行った。

55

(ⅷ) Excel の情報を Redmine に登録する
管理スタッフが Excel にまとめたタスクリストを Redmine に登録することを想定して、Excelの情報を Redmine に登録することを行った。
下図が、xlgan を使用して Excel のデータを Redmine に登録した結果である。
このように、xlgan を使用することで制作管理を行う側は使い慣れた Excel で情報整理を行い、アーティストは Redmine でタスクの確認を行うというフローが実現できるようになる。

図 3.27

Excel の情報を Redmine に登録

56

(ⅸ) Excel の更新内容を Redmine に反映する
プロジェクトの情報は日々更新され、それに合わせてスケジュールも調整されていく。調整されたスケジュールは Redmine にも反映され、全員で共有できるようにする必要がある。この機能の検証を行う。
Excel でタスクの開始日を変更したのち、その情報を Redmine に登録を行った。

図 3.28

Excel の更新内容を Redmine に反映

以上で、Excel と Redmine 間でシームレスに情報の更新を行うことが確認できた。このようなシステムを用意すればその場その場で適切なツールを使いつつ、ミスなく情報の共有と更新を行うことができるようになる。

57

(e)

課題

(ⅰ) スケジュール調整のためのソリューション
Excel + Redmine を使用すれば、現状のタスク一覧と進捗状況をチーム全体で共有・更新するという目標は達成できる。唯一課題として残っているのが、スケジューリングである。
通常、スケジューリングはガントチャートを表示しながらスケジュールとリソースのバランスを取りながら行う必要がある。Excel には標準でこのような機能がなく、各自苦労しながらほぼ手動で調整を行っているのが現状である。
特に手間がかかるのがリスケジュールをする際に休日をまたぐなどして営業日は変わらない
ものの実日数が変化してしまうケースについての対応と、依存関係にあるタスクの同時編集である。専用のツールであれば当然このような機能は存在するが、Excel にはそのような機能は存在しないため、非常に手間がかかる。この部分をどのように解決するかは今後の検討を要する。
最も一般的な解決方法は MS Project や Gantt Project のような専用ツールを導入することである。ただ、この方法は有料のアプリケーションであればそれなりのコストが発生することと、管理を行うスタッフが新しいソフトウェアに対応する必要性や、Excel や Redmine と相互にデー
タをやり取りする必要が生じるなどの理由により使用者からの反発が非常に強く、導入は困難な場合が多い。
また、現在はそもそもこのようなツールを使うためのトレーニングを受けた人材もほとんど存在しないので、ツールを導入しても正しい使い方を身につけ、適切に運用するためのノウハウが存在しないことも大きな障害となっている。
(ⅱ) ドキュメント整理のハードルの高さ
Redmine の Wiki でドキュメントを書く場合、Wiki 記法を使用する必要がある。Wiki 記法は
章や節、リストなどを記号で記述するものである。
Wiki 記法の例
h2. 検証内容
具体的には以下のような流れを検証する。
# 制作管理者が Excel でアセットリストやカットリストからタスクリストを作成する# Excel で作成したタスクリストを Redmine に登録する#* この際、Redmine に登録された時点でチケット番号が割り振られるので、Excel
上のタスクにも番号を割り振る# アーティストは Redmine の情報を元に作業を行う# publish を行ったタイミングなどで Redmine の進捗情報を更新する

58

前記ドキュメントを表示するとこのようになる。

検証内容
具体的には以下のような流れを検証する。
1.

制作管理者が Excel でアセットリストやカットリストからタスクリストを作成する

2.

Excel で作成したタスクリストを Redmine に登録する


この際、Redmine に登録された時点でチケット番号が割り振られるので、Excel 上のタスクにも番号を割り振る

3.

アーティストは Redmine の情報を元に作業を行う

4.

publish を行ったタイミングなどで Redmine の進捗情報を更新する

5.

制作管理者は、日々更新される進捗情報を Excel に書き戻す

このような書き方をプログラムに熟練していない一般のアーティストや制作進行に強制するのは非常にハードルが高い。もっと手軽にドキュメントをまとめることができるように、ワープ
ロソフトのようにメニューと GUI を用いて文章を作成するための機能は必須と言える。
いくつかのプラグインで、画面で見ながら編集作業ができる WYSIWYG 環境を実現するものもあるが、既存の記法を使えない、安定性に問題があるなど、実用には更に調整が必要である。
この点に関しては Redmine の Wiki を使用せずに別の Wiki システムとの連携を取る解決策もある。例えば、MoinMoin というシステムであれば Wiki 記法での記述はもちろん、GUI での編集環境が整っているため、慣れないスタッフでもある程度簡単に文章の編集を行うことができる。

59

図 3.29

MoinMoin のドキュメント編集画面

60

(3)

Shotgun①

アプリケーションの諸元
開発元：Shotgun Software
国籍：米国
アプリケーション名：Shotgun
バージョン番号：4.2②

Shotgun 機能検証

Shotgun は、米 Shotgun Software 社が開発・販売を行っているプロジェクト管理ソフトウェ
アである。Shotgun 自体はプロダクションに特化した特殊な機能を提供しているわけではなく、データを登録・加工するためのフレームワークというべきものである。
Shotgun は細かい部分までカスタマイズが可能であり、標準で提供されるプロジェクトのための枠組みも Shotgun 上で構築されたテンプレートとして提供されている。そのような形態のため、プロダクションで使用するためにはカスタマイズを行うことが前提となっている。特に、日々更新されるプロジェクトの情報を Shotgun に登録する部分は、ツール化をして自動的に更新することは必須と言える。もちろん、このような機能を利用せず手作業で情報の更新を行って運用することは可能であるが、そのような運用方法では Shotgun を使う意味が半減してしまう。

(a)

テーブル間の関係を構築する

Shotgun で情報をまとめるというのは、各テーブル間の関係性を構築し、様々な方面から検索・分析することができるようにするということである。
例としてあげると、映像を制作する場合にはショット中にはキャラクタや背景、小物など多数のアセットが存在し、ショット作業の進捗はアセットそれぞれの進捗に依存する。
あるショット作業を行ったときにアセットの不具合が見つかってアセットの修正を行う場合、ショットの更新はアセットの更新が終わらないと行うことはできないのはもちろん、更新したア
セットに依存しているショットも更新を行う必要がある。
このような依存関係を調査することは Excel のようなスプレッドシート式の管理ツールでは人力に頼る部分が多く、プロジェクトが大規模になると管理が破綻してしまう大きな一因となる。
Shotgun ではこのような管理を簡単に行うことができるようになっている。図 3.30 の例ではbunny_010_0100 というショットが必要としている情報を表示している。
この画面を見ることで、このショット中でどのようなアセットが使用されているか、各アセッ
トの進捗状況がどのようになっているかを一目で確認することができる。

61

図 3.30

Shotgun(1)同様に、別の視点としてあるアセットがどのショットで使用されているかという別の視点から状況を把握することもできる。下図の例では、Bunny という主人公のキャラクタがどのショットで使用されているかリスト表示している。

図 3.31

Shotgun(2)

62

(b)

レビュー情報を登録する

レビューのための情報を登録するのも、同様の考え方で行う。
(ⅰ) アセット若しくはショットに Version を登録する

図 3.32

Shotgun(3)(ⅱ) Play List に Version を登録する

図 3.33

Shotgun(4)63(ⅲ) Review ページに Play List 一覧が表示されるので、必要な Play List を選択する

図 3.34

Shotgun(5)(ⅳ) Play List を順に表示・再生しながらレビューを行う。必要であればメモを登録し、OK であれば進捗状況を更新する

図 3.35(c)

Shotgun(6)まとめ
以上のように、これまでの Excel ベースで行っていた一覧表形式での管理とは全く異なる考え方でプロジェクトの管理を行う必要がある。管理システムとしては表形式のものに比べられないほど強力なものであるが、同時に慣れていない人員にとっては概念の理解が大変であり、この部分が大きなハードルとなってしまう。

③

利点

Shotgun はハリウッドの現場で最も使用されているプロジェクト管理システムであり、実績も十分ある。そのため、大規模なプロジェクトに関する経験も豊富であり、Shotgun Software 内
で蓄積しているノウハウを流用できるということは大きなメリットである。
また、従来の管理手法とは全く違う次元で高度かつ柔軟な情報の管理・分析を行うことができるので、複雑かつ大規模なプロジェクトの管理を行う際に強力な効果が期待できる。

64

④

問題点

(a)

コスト

Shotgun 自体はデータを格納するためのフレームワークという側面が強く、実際にプロダクシ
ョンで使用するためには多くのカスタマイズを行う必要がある。カスタマイズを行わないで素のまま使用するのであれば、「オンライン版 Excel＋α」と同等の力しか発揮することができない。
カスタマイズのためのコストは決して安くはなく、専任のエンジニアが一年掛かりで行うようなものである。Shotgun 本体の費用とあわせて、これらのコストは日本のプロダクションとしては決して安いものであるとは言えない。

(b)

日本のプロダクションの体制

前述の通り、Shotgun 自体は入れ物でしかなく、その入れ物に何を入れてどのように運用するのかはユーザーに委ねられている部分が大きい。そのため、そもそも入れるものが整理されていないと Shotgun を導入したとしても宝の持ち腐れになってしまう。
Shotgun 導入以前に、そういった基礎部分の構築を行っておく必要があるが、残念ながら中小のプロダクションでそのような体制が作られているケースは少ない。
また、Shotgun を十分に活用するためには社内のパイプラインと接続をして、日々更新される
情報を自動的に Shotgun に登録できるようにする必要がある。そのための開発を行うためにも社内のパイプラインが整備されている必要がある。このような体制が整っていない状態で導入しても必要な情報を全て手で入力することになり、オンライン版 Excel 以上の使い方をすることができないばかりか、データ入力のための手間が増えるだけでおわってしまう。

(c)

ユーザーインターフェース

Shotgun はその他のツールと比べてユーザーインターフェースが特に見劣りをするというわけではないが、やはり幾つかの点で使い勝手に悪影響を及ぼしている部分が見受けられる。特に、情報を表示する際のレスポンスはそれほど軽快と言えず、アーティストにストレスになりかねない。ただし、これは実証環境が Shotgun Software 社が提供するサーバ内でネットワークを介して行ったことが原因になっていることも考えられるので、導入の際には実環境でテストを行う必
要がある。

⑤

分析

(a)

これまでと異なる情報の分析方法

日本のプロダクションでは Excel（一枚の表）が使用されてきた経緯があり、情報を検索・フィルタリングして多方面から分析しながら管理することは少なかった。表管理は全ての情報を一覧できるというメリットがあるものの、より多くの情報を柔軟に管理するためには限界もある。
Shotgun を使用する場合、フィルタを駆使して情報の絞り込みを行い、その情報を読み解くという、これまでと異なったスキルが必要となる。この部分のトレーニングを十分に行って身につけることで初めて使いこなすことができる。
65

そのような土壌が無い中では、例え導入したとしても Excel＋α以上の使い方を見つけることはできない。

(b)

総括

Shotgun は世界中で利用され、ユーザーも多く運用のための経験も豊富である。その点では、安心して導入できるシステムであると言える。
だが、プロダクションの体制が整っていない状態で Shotgun の導入を行ったとしても十分な力を発揮できないばかりか、導入したことにより負荷がかかってしまって効率が悪くなってしまうということが起こりえる。そうならないように使用する側の知識レベルの向上が最も重要で、導入のための障壁になってしまう部分である。

66

3.4.5 レビューシステム検証
(1)

COPRA

①

アプリケーションの諸元

開発元：CinePostproduction GmbH
国籍：ドイツアプリケーション名：COPRA
バージョン番号：4
動作環境
サーバ：PHP が動作する Web サーバ
クライアント：Apple iPad シリーズ
ライセンス形態
クラウドサービス（独・米）、サーバー・ストレー
ジの使用量による課金
サーバーインストール型、作品単位での課金②

調査実施方法調査の実施に当たり、メーカーより、試用版の提供と図 3.36

COPRA 画面(1)

図 3.37

COPRA 画面(2)サポートの協力を得た。
実施日：2012 年 11 月 21 日
サーバ設置場所：ピクチャーエレメント オフィス
用意したマシンへ、CinePostproduction 社がリモートでセットアップを行った。
クライアントの iPad は個人が所有するものを利用し
た。

③

実施結果

パッド型のモバイル端末を利用した、ネットワーク型のレビューシステムである。機能的には
YouTube のようなオンラインでの再生と似ている。
本来は、colorfront 社の On-Set Dailies と連携すると利便性が向上するように作られているが、67

メーカーは広く使えるように改良していく意向を持っている。
実証実験では、PC のウェブブラウザで接続しウェブアプリケーションから実作品のクリップ
をアップロードする。ウェブアプリケーションでは、プロジェクト、タスクといった階層があり分類できる。 その後、クライアントでサーバ設定を行い、再生や様々な機能の試験を行った。
クライアントは、社内 LAN 内、遠隔地の Wi-Fi、3G や LTE のようなモバイル通信といった条件を変えて使用した。
アップロードでは、映像のデータ転送速度(bps)調整に手間取った。Full HD で 80 Mbps といった高品質の場合、再生されるまで数十分かかった。キャッシュさえされれば、再生がもたつ
くことはなかった。 現実には 5 Mbps 前後が使いやすかった。そのため細かい品質チェックを行う目的では使えない。

④

利点



オンライン状態であれば、遠隔地で映像の確認と指示出しができる。



タップやフリックなどで簡単に操作できる。



ムービーはストリーミング再生するが、クライアントにキャッシュされるため 2 回目以降の再
生が速い。



テキストによるメッセージが残せる。



一時停止したフレーム中に、手書きによる書込ができる。色や太さが変更できる。機能が絞られている分、直感的でわかりやすい。



クライアントの機種が限定されているため、色味が違ってしまうといった問題が発生しない。



クライアントが日本語に対応している。

⑤


問題点
EDL や Final Cut Pro の XML といったエディットされた順番で再生できない。ファイル名順に再生される。



再生されるまでの時間は、ネットワークの速度に依存する。

Android 機や Windows for Mobile などのクライアントがない。

オリジナルと VFX 後の比較のようなバージョン管理がない。

⑥
分析
パッド型のモバイル端末による簡単な操作と、遠隔地での再生機能は他に類のないシステムであった。コンピュータに不慣れな人でも、すぐに慣れて使用できそうである。



手書きによる映像への書込は、指示を出すときの手助けにはなる。しかし、これだけで全てを伝えられるわけではないので、別途口頭で話す必要がありそうだ。



シンプルな分、素性が良いように思われる。プロジェクト管理システムとの連携がないため別途システム開発が必要の可能性があるが、対応しやすいかもしれない。

68

(2)

HIERO

①

アプリケーションの諸元

開発元：The Foundry
国籍：イギリス（ロンドン）
アプリケーション名：HIERO
バージョン番号：1.5
動作環境
Mac OS X Snow Leopard 10.6.8 or newer

Linux




HIERO 実験の様子

Mac OS X

図 3.38Linux RHEL 5.4 64-bit

Windows


MS-Windows 7 64-bit

ライセンス形態


スタンドアロン・サーバークライアント



スタンドアロン ネットワークフローティング

対応フォーマット

②



RED



ARRI



DPX



OpenEXR

調査実施方法調査の実施に当たり、メーカーより、試用版の提供と詳しい説明の協力を得た。
実施日：2012 年 12 月 11 日
場所：ピクチャーエレメント オフィス
使用 PC：Windows 7 Pro 64bit エディション

③

実施結果

このソフトウェアは、ショット管理、コンフォーム、VFX のプレイバックをするものであり、厳密にはレビューツールではない。

69

インストールは数分程度で終わる。基本的に同社製品である Nuke と連携するように作られている。Nuke はコンポジットソフトウェアであり、エディット機能を持たない。それを補完するソフトウェアとして HIERO が開発した経緯があるという。
当アプリケーションは、社内ネットワークのような閉域での使用が前提となっている。インターネットを通じたオンラインでの使用や、複数の拠点間は考慮されていない。複数の拠点での仕様が必要であれば、VPN のようなネットワーク共有が必要と考えられる。

④

利点



EDL や Final Cut Pro の XML のインポート

メインは Nuke だが、AE などに対応するようカスタマイズ可能OpenColorIO が導入されているため、ACES（アカデミー色符号化仕様：Academy Color
Encoding Specification）がサポートされる

HDR 映像に対応



VFX 作業のスナップショットやバージョン対応。オリジナル映像や、複数の作業映像を切り替えてプレビューできる。



ディレクトリ構造のカスタマイズ機能



内蔵の Python スクリプトによる拡張機能

⑤

問題点



編集した部分だけの EDL の読み込みには対応していない 2.0 で対応予定

ライセンスファイルの設定でつまずきやすい。別のアプリケーションとして 2 種類あり、どちらを使うかわかりづらい。



メタデータを扱う機能がない。次期バージョンにてアノテーション機能が搭載される予定。



ステレオ 3D 映像に対応していない。検討中。

⑥
分析
プロジェクト管理機能を有していないため、外部ツールの連携が必要となる。Shotgun とあわせて使用されることが多いという。



Nuke と HIERO をあわせて使用するように設計されているため、他のソフトウェアを使用し混在している環境では導入しづらい。メーカー側の話によると、他社製品と連携するようにカ
スタマイズは可能であるそうだ。ただし、設定変更や内蔵スクリプトの開発が必要であり難易度は高くなるとのことだった。



映画のような尺の長い作品に合わない様に感じられた。CM のような短い作品に向いていると
思われる。



まだバージョンも若く、次バージョンも開発中とのこともあり、将来に期待したい。

70

(3)

RV

①

アプリケーションの諸元

開発元：Tweak Software
国籍：イギリス（ロンドン）
アプリケーション名：RV
バージョン番号 3.12.19
動作環境


Mac OS X



Linux



Windows

②

検証作業

(a)

Shotgun と RV の連携

RV は正確にはレビューシステムではなく、連番ファイルや動画の再生をするためのプレイヤーである。ただし、ただのプレイヤーとしてだけではなくスクリプトによる高いカスタマイズ性や標準で備えている豊富な機能から、Shotgun や Nuke など外部のアプリケーションと連動して使用されることが多い。
本検証では Shotgun と RV の連携を行って、一連のレビュー環境の構築を行う。

(b)

RV 環境整備

RV のインストール後、他のアプリケーションや OS との連携を行うために rvlink プロトコルの設定を行う必要がある。
Windows

etc ディレクトリ以下にある rvlink.reg を実行して、レジストリに登録を行う。

Mac OSX

一度、rv を"-registerHandler"オプション付きでコマンドラインから起動することで登録が行われる。



Linux


bin ディレクトリにある rv.install_handler を実行することで KDE 並びに Gnome デスクトップ環境に RV が登録される。Linux の場合、アプリケーション毎に制限や注意事項がある場合があるので随時マニュアルを参考にするとよい。

71

(c)

Shotgun と RV の連携
Shotgun+RV Installation Guide 151 を参考に設定を進める。
Shotgun+RV Package のインストール
1.

RV の起動2.

RV > Preferences メニュー選択

3.

Packages タブを選択

4.

Shotgun Integration パッケージの、"Installed" and "Load"チェックボックスをオンにする

図 3.39

RV > Preferences メニュー

5.

Preferences を閉じて RV を再起動する

6.

メニューバーに Shotgun メニューが表示され、Shotgun パッケージが使用可能になる※本検証の際にこの手順で Shotgun Integration の登録を行ったのだが、RV を再起動す
るとプラグインのロードする設定が消えてしまい、正常に動作しないという現象に見舞われた。使用した RV のライセンスが体験版だったのが理由かもしれないが、未検証である。ひ
とまずの対策として File > New Session メニューを選択して、新しいセッションを起動すると Shotgun Integration の有効になった RV が起動するので、そちらを使用することにした。

15

https://support.shotgunsoftware.com/entries/125696#install-the-shotgunrv-integration-package
72

(ⅰ) Shotgun の設定
Shotgun 側で RV を使用できるように設定を行う。
1. Shotgun に管理者権限でログインする
2. Site Preferences を開き、Advanced セクションを開く

図 3.40

Shotgun Admin

3. Enable RV integration のチェックボックスで yes を選択する

図 3.41

Shotgun Site Preferences

4. "Save Changes" ボタンを押して変更を保存する

73

(ⅱ) RV から Shotgun にアクセスできるようにする

図 3.42

Shotgun Admin

1. Admin > Scripts ページにアクセスする
2. "rv"という名前のスクリプトがなければ作成する
3. 作成したスクリプトの詳細表示をするとアプリケーションキーがあるのでコピーする

図 3.43

Application Key(ⅲ) RV 用設定ファイルのダウンロードとインストール
Shotgun+RV Configuration Guide 内のリンクからダウンロードできる。
shotgun_fields_config_custom.mu をダウンロードする。
1. ファイルをテキストエディタで開いて、Shotgun サイトの URL と先ほど取得し た ア プリ ケー シ ョンキ ー を 入力 する 。 入力す る 場 所は "// ADD YOURSERVER INFO HERE" というコメントで示されている
2. shotgun_fields_config_custom.mu を、RV が見つけることのできる場所に保存する。RV は、デフォルトでは以下の場所を探す

74



Linux

$ ~/.rv/Mu$ RV_HOME/plugins/MuWindows> ~/Application Support/RV/Mu> RV_HOME/plugins/MuMac$ ~/Library/Application Support/RV/Mu$ RV_HOME/PlugIns/Mu※RV_HOME 変数は RV のインストール先
ここで、一旦 RV を再起動する。

(ⅳ) RV の起動と Shotgun との接続
1. RV を起動
2. Shotgun > Preferences > Set Shotgun Config Style をクリック
3. "custom"と入力

図 3.44

RV (1)

4. RV 再起動
※再生しようとしているファイルが、ローカル若しくはネットワークドライブ上に存在することを確認しておく
5. Shotgun サイトにログイン

75

6. Version ページに移動
7. 1 つ以上のバージョンを選択
8. 右クリックメニューから"Play in RV"を選択

図 3.45

RV (2)

9. RV からファイルが再生できたら、設定が完了
検証環境では 64bit 版の RV を使用していたせいか、"Play in RV"を選択した際に RV の場所を指定するためのダイアログが表示されてしまった。下図の通り、32bit 版のためのパスが指定されていたので "Chose..."ボタンから正しい実行ファイルの場所を選択してアプリケーションを登録しなおした。
また、ダイアログ左下の Remember my choice for rvlink links にチェックを入れておけば、この設定が保存される。
以上の設定を行うことで、Shotgun から RV を起動することに成功した。

図 3.46③

RV (3)

実施結果

以上の環境を構築することで、Shotgun と RV を使用したレビュー環境の構築を行うことができた。Shotgun と連携を行うことで、アーティストが更新した情報をレビューのためのリストに76

登録し、レビュー時に再生・確認、コメントや修正内容の記入、アーティストのためのフィード
バックという一連の流れを行うことができる。

④

利点

一つのシステム内でプロジェクト管理に関する一連の流れを処理することができるのは、情報の管理の面からも使用感の面からも大きなメリットがある。

⑤

問題点

RV は単体のソフトウェアであるため、全アーティストが使用するためには必要なだけのライセンスを購入し、全てのマシンで使用できるように上述のセットアップを行う必要がある。これは、環境によってはかなりの負担になる。

77

3.4.6 既存アプリケーションの情報収集と分析
調査結果については、別紙参照とし、ここでは分析結果を解説する。

①

アプリケーションの機能表

3 つのジャンルについて、それぞれのアプリケーションがカバーしているかを表している。△
印は十分な機能を有してない、別途アドオンが必要といったケースである。
表 3. 4
製品名

アプリケーションの機能表

アセットマネージャー

プロジェクトマネージャ

レビュー

ーJCGS Library○

Redmine○GanttProject○

OmniPlan○

TACTIC○

5th Kind○○○

Shotgun

○

△

RV

○

COPRA

○

HIERO

△

○

wiredrive○

Keyframe Concept○

ア セッ ト マネジメ ン ト②

アプリケーションの連携

前項の表を図式化している。アプリケーションをグループ化している。赤枠はアセットマネジメント機能を有しているアプリケーションである。緑枠はプロジ
ェクト管理機能を有しているアプリケーションである。
青枠はレビュー機能を有しているアプリケーションである。

プ ロ ジェ ク ト 管理

矢印はそれぞれ連携を示している。破線は正式に連携を表明しているわけではないが、可能であることを

Dailiesシステムと 連携示している。
Shotgun や Redmine は API を提供しているため、

レ ビュ ー

連携機能を開発しやすい。
図 3.4778

アプリケーション連携図

③

ワークフローでの適応範囲

アセットマネジメント（アセット管理）、プロジェクトマネジメント（プロジェクト管理）、レビューシステムが、ワークフロー中のどこで一般的に使用しているかを図に示す。今後、適応範囲が広がる可能性もある。

図 3.48④CG・VFX ワークフロー（簡易版）

コスト分布

粋にアプリケーションやシステムに発生するコストを、
イニシャルコストとランニングコストに分けて分類している。
実際には様々なコストが加わるため、この図からトラ ンニングコ スト

人的コストや、インフラのコストなどを除いた、純ータルコストはわからない。次項で総合的な費用について分類する。
オープンソース・ソフトウェアはそもそも無料なので左下に配置されている。オープンソース・ソフトウ
ェアであっても、有償サポートを提供している場合はライ ニシ ャ ルコ スト

図 3.49コスト分布図ンニングコストが発生するものとしている。ライセンス
期間やサポート期間が設定されているアプリケーションは定期的に費用がかかる。

79

⑤

トータルコスト

人的コスト、開発コスト、教育コストなどを含めた
フ リ ーソ フ ト

導入にかかる費用全てを比較した図である。これは一例であって、導入個数や期間によって見え方が変わる
可能性がある。

市販ソフト（パッケージ）

フリーソフトは、それ自体のコストはかからないが、使いこなすための情報は自ら探さなければならない。
ただし、オープンソース・ソフトウェアの場合は、ソ市販ソフト（ライセンス型）

ースコードを改変することで、機能の変更や追加することが可能である。
システム導入支援企業

パッケージ販売されている市販ソフトのグループは、
比較的廉価である。サポートはあるが、基本的には購入者が学習する必要がある。ゼロから導入なら、トータルでは少々割高になる可能性がある。

低

図 3.50ト ータ ルコ スト

高トータルコスト図（人的コスト・開発コスト・教育コストなどを含んだもの）

ライセンス型は、月又は年単位で契約し、サポートが充実している傾向にある。バージョンア
ップやアップデートも提供される。パッケージ販売ソフトよりきめ細かいサポートが得られる可能性があるので、活用出来ればトータルコストは下がる。
システム導入支援企業によって導入とサポートを一手に引き受けてもらう場合は、ノウハウを学ぶ必要がないためトータルコストは低くなる可能性がある。一種のコンサルタントと捉えるとわかりやすい。

⑥

難易度

フリーソフトは、導入にも運用にも難易度が高くなる傾向があると言える。また、高機能なアプリケーション

運用難易度

導入までの難易度と、運用中の難易度の分布図である。

も難易度が高めである。
難易度が低ければ、学習や教育によるコストが低くなる。社内に普及させ、安定して使ってもらえるよう定着させやすい。
導入難易度

図 3.2

80

難易度分布図3.4.7 導入に当たってのチェックポイントシステム導入に当たって考慮すべきポイントをあげる。

①

規模の違い

会社の規模又はプロジェクトの規模により導入の可否を見極める。既に導入されている企業のヒアリングや海外動向調査から、10 名以下の小規模の場合は効果が現れにくく、逆に非効率でコストに見合わなくなることがあるようだ。効果が如実に見えてくるのは 30 名くらいからと言える。これは他業種でも同じことが言え、生産管理システムのアウトソーシングは 10 名以上から規模に合わせて決められている。
複数の企業がからむプロジェクトの場合、関わる人間の総数で考えるとよい。この場合、拠点が分散するのでインターネット上のクラウドによるアクセス性の確保が必要である。会社ごとに違う仕組みをいかに吸収するかは課題である。前述の提案よりパイプラインのギャップを減らすことが重要である。

②

既存ソフトウェアか、自社開発か生産工場では、生産管理システムのインテグレーションをする会社が数多く存在する。企業規模によって様々なシステムが存在する。そういった専門会社にアウトソーシングすることも考えられる。しかしながら、映像業界の商習慣や業務形態を深く理解している会社はほとんど存在しないと考えられる。そこで既存のソフトウェアを活用するか自社で新たに開発かの選択となる。
プロジェクト管理システム導入の場合のチェックポイントをあげる。




欧米発の既存ソフトウェア


海外プロダクションと取引がある場合は効果が期待できる

高機能であるが、使いこなすのが難しい

ローカライズされていない

ウェブアプリケーションとして Java・PHP・ASP.NET などで構築


社内運用ルールに合わせて構築できる

SaaS・PaaS のようなクラウドサービスが使える

高度な専門知識が要求される

他のウェブアプリケーションとのマッシュアップが可能

FileMaker Pro、MS-Access といった RDBMS による業務システム構築


プログラミングの知識が少なくてもそれなりに構築できる



表計算アプリケーションからの移行がしやすい

アセットマネジメントでは、日本国内にもシステムインテグレーターが存在しているので、チェックポイントをあげる。


システムのアウトソース


十分なスキルをもつ開発人員を雇用できるか

81



③



アウトソース側のシステムにある程度柔軟に社内運用ルールを変更できるか

導入費と運用費は別々に発生する

自社開発


開発者のスキルは十分か

社内運用ルールに合わせて構築可能

その他

その他、システム導入に向けて注意するべき点を上げる。


システムのユーザーインターフェースは、極力シンプルであることが望まれる。



教育コストが発生することを考慮すること（システムがシンプルであることは、ここにつながる話でもある）。

82

3.4.8 既存ツールに無い機能の拡充
システムの構築には不足している機能があることが分かった。ここでは、将来何が必要となるかを整理し提案する。

①

アセットマネジメント補助ツール

各工程をつなぐパイプラインをアセットが流れる。アセットマネジメントをサポートするツールの拡充が必要と考えられる。工程ごとに使用されるアプリケーションは複数あり、何を採用するかは会社やプロジェクトの都合により様々である。同じメーカーの製品同士であればよいが、メーカーが違う場合はデータの互換性の問題が発生する。仕様上、標準では機能が備わっていな
いといったこともあった。そこで、製品ごとにプラグインやアプリケーション内蔵スクリプトを開発することによってパイプラインを潤滑に流れるようにする。

②

OpenEXR 関連ツール

OpenEXR 形式の画像ファイルは多くのモードを持つ柔軟な形式であるが、まだ使用するための環境が整っていない。
例を以下にあげる。


OpenEXR に内包される複数のチャンネルをレイヤーとして扱えるビューワソフト



OpenEXR に内包される複数のチャンネルを結合・削除・変更といった編集できるソフトウェア

メタデータの付加、編集

ファイルフォーマットの正当性チェック③

カメラのメタデータコンバーター・データベース

様々なカメラのメタデータを分析し、フォーマットに合わせてデータベースを作るソフトウェ
アが必要と考えられる。カメラメーカーや 3DCG ソフトウェアメーカーの利害もあるため、すぐにメタデータの統一の流れになることは考えにくい。それぞれのメタデータをコンバートし、集積する基盤から入ることを提案する。

④

日本の実情に沿った新規プロジェクト管理システムの構築

シンプルで使いやすく、日本の映像業界の現状に合わせたプロジェクト管理システムの構築を行っていく必要がある。それぞれのパーツは実績のあるソフトウェアを導入することも検討しつつ、足りない部分を適切に補い、トータルで運用することのできるシステムを構築することで国内へのシステムの普及とプロダクションのレベルアップに繋げることができると考えられる。

83

3.5

プロダクションヒアリング

現時点で運用されているシステムの調査分析を行うため、いくつかの企業にヒアリングを行う。
プロダクション内での運用ルールやインハウスツールについての調査、メリット・デメリット、
将来の展望など調査する。
また、2D アニメプロダクションについては、ワークフロー上デジタル化できないためにおこる制作工程管理システム導入の障壁についてヒアリングを行なっている。

3.5.1 ヒアリング先の選定と実施
映像会社はそれぞれ得意分野がある。実写・3DCG アニメーション・2D アニメーションでは置かれている状況も、制作工程管理システムの導入度合いも変わってくる。 会社の規模によっても状況は変化すると考えられる。 ヒアリングの実施に当たって、なるべく多くのケースをカバーできるようにした。

(1)






3DCG アニメーションの業務に関わる企業
株式会社アニマ

実施日：2013 年 1 月 7 日

協力者：西野憲司 プロダクションマネージャー／開発主任

選定理由：「Pallet System」を独自開発しているため。

株式会社オー・エル・エム・デジタル実施日：2013 年 1 月 8 日

協力者：四倉達夫 研究開発部門 博士（工学）

選定理由：「CDVis」を独自開発しているため。

合同会社ダンデライオンアニメーションスタジオ

実施日：2013 年 1 月 17 日

協力者

：西川和宏 代表／CG ディレクター
服部剛 CG テクニカルディレクター

選定理由

(2)

：
「syncrat」を独自開発しているため。

2D アニメーションの業務に関わる企業

2D アニメーションを手がける企業 6 社で合同ヒアリングを開催した。選定には、当委員会とワーキンググループに参加している企業である。ただし、（株）オー・エル・エム・デジタルは
既に 3DCG アニメーションとしてヒアリングしているが、2D アニメーションも手がけているた84

め再度ヒアリングに参加となった。
（株）カラーは委員会参加企業ではないが、趣旨の賛同が得られたためヒアリングに参加している。
実施日：2013 年 1 月 22 日
株式会社オー・エル・エム・デジタル

四倉達夫 研究開発部門 博士（工学）株式会社カラー

瓶子修一 デジタル部 部長／プロデューサー
緒方智幸 制作部 制作部長／プロデューサー
岡島隆敏 制作部 制作デスク


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

飯嶋浩次 デジタル部部長／プロデューサー
株式会社スタジオ雲雀

齋藤成史 システム管理 チーフ／プログラマー


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

野口光一 企画営業本部 映像企画部次長 兼 映像企画室 プロデューサー


株式会社プロダクション・アイジー

安芸淳一郎 制作部 システム管理・開発課 課長

85

3.5.2 プロダクション事例(1)

事例：株式会社アニマ

訪問日：2013 年 1 月 7 日

場所：株式会社アニマ（東京都新宿区高田馬場）

協力者：西野憲司 プロダクションマネージャー／開発主任

①

業務内容

テレビ、映画、ゲーム、プロモーションビデオ、アミューズメント機器などの CG アニメーションを中心に制作
している。

②

社内インフラストラクチャ

会社は東京・石川・中国大連の 3 拠点であり、本社の社員のいる居室は 2 階フロアを広く使用している。3 階フロ

図 3.52anima

アには、会議室、モーションキャプチャー室、サーバ室が配置されている。サーバ室に各種サーバを集約し、共有ス
トレージは 400TB（非 RAID 換算）の容量がある。デザイナーが使用するクライアント PC は、
主に MS-Windowsである。導入している工程管理システムはウェブアプリケーションであり、全て自社専用にフルスクラッチで作成し
ている。

③

経緯

5 年前に開発部を立ち上げ、エンジニア 1 名を配置し、分業とクオリティの均一化を図るため、パイプラインの効図 3.53

サーバー室率化への取り組みは初期の頃からあった。現在のシステム
は 2 年前に始まっている。当初、Shotgun、Redmine を検討した。運用コストや言語、機能が多すぎることによる使いにくさが問題であった。開発には、従来の手法からスムーズに移行できる
こと、デザイナーのストレスにならないようなわかりやすいインターフェイスを主眼としている。
開発に先立って、社内のワークフローの視覚化を約半年かけて作成している。作業項目を細かい単位まで分割し、マネージャーによるチェックポイントは色分けすることで視認しやすくなっている。ワークフロー図が完成することにより作業内容が透明化され、セクション間の意識共有ができた。また、ワークフロー図の中に必要と思われるツールを書き込むことで、作業効率化のために何がどの優先度で必要かが認識できるようになった。

86

図 3.54

ワークフロー全体図

図 3.55

ワークフロー拡大図

また、作業に要するデータはパイプライン上を行き来するため、パス名・ファイル名の規則を確立することは重要である。命名時にヒューマンエラー発生や、パイプラインの工程ごとにリネームが発生するケースをなくす必要がある。

87

④

開発

開発項目


デザイナーが作業に使っているアプリケーションのスクリプトやプラグイン



アセット・ショット管理ツール（ウェブアプリケーション）

パイプライン構築において、実作業に必要な最低限のスクリプトやプラグインに関してはほぼ完成している。
管理ツールは実運用しているが、随時機能の追加を行っている。主要機能の開発の工期は約半
年だが、テストに調度良いプロジェクト待ちによる待機状態があったため 2 年ほどかかっている。
開発コストは、他の開発と平行作業であったこともあり正確には算出していないが、およそ 10
人月であった。

⑤

制作工程管理ツール「Pallet System」アセット版(モデル管理）

CG モデルの制作工程を管理するツールである。ウェブアプリケーションとして動作する。動
作環境は MS-Windows の Internet Explorer。
基本画面は、縦軸にモデル、横軸が工程別に左から右へパイプラインがつながるように配置された表である。


表中の項目は、おおまかにアサイン・モデル作成・チェック・完了のステータスを持つ。



モデル作成が完了したときに、マネージャーにチェックを依頼するメッセージ機能を有している。

チェックで NG がでると差し戻され、OK になるまで繰り返される。

ステータスの変更履歴がわかるようになっている。

ステータスが進むごとに項目のバックグラウンドカラーが赤・黄・青と変わっていき、表を見たときにどこが完了しているか視認しやすいように工夫されている。



コメントをつける機能

サーバー・ストレージのパスへのリンクがあり、直接フォルダを開くことができる。



他者を呼び出す機能。IP Messenger の代わりとして機能する。



Excel 形式によるインポート・エクスポート機能。



チェックのフローや制作工程はプロジェクトごとにドラッグ・アンド・ドロップでカスタマイズ可能。

CG 制作以外にも応用可能。

コメント機能に関しては、あくまでも遠隔地とのやり取りやや履歴の意味合いが強く、特に社内においては、実際のリテイク指示は直に話をすることが多い。
担当者別ページは、縦軸にパイプライン順に作業項目が並び、横軸にモデルが並ぶ。一日の作業すべきアイテムがひと目で分かるようになっている。

88

図 3.56「Pallet System」アセット版：アセット管理画面の一覧

図 3.57

メモ機能

図 3.59図 3.58アサイン変更

個人のタスク画面

CAT SHIT ONE -THE ANIMATED SERIES(C)2010 小林源文/アニマ・IDA

89

⑥

制作工程管理ツール「Pallet System」ショット版(ショット管理）

基本的にはモデル管理ツールとベースは同一である。モデル管理ツールに加える特徴を以下に挙げる。


複数のカットをグループ化し、まとめてステータスを変更できる。関連する複数のカットを同時進行で作業することはよくあることで、1 つずつステータスを変更しなくてもよいようにな
っている。



制作進行、ディレクターなどといった役割に応じて、必要な項目だけを画面上に表示されるよ
うにカスタマイズできる。煩雑さを軽減するのに役立つ。



デュレーション設定機能

カット分割機能

カットごとの難易度レベル設定機能。レベルとデュレーションを掛け合わせるなどして工数計算を出来るようにすることで、プロジェクトの運営や経営に役立つ。



全体を見渡すために工程ごとに進捗度をパーセンテージで表示する機能

基本的に会社は完成したカットを素材として提供する立場であり、エディティング業務はあまり行わないため、ノンリニア編集に必要な EDL は重要ではない。そのためカットの順番はさほど考慮されていないが、自社開発であるため、必要であればソート機能の改善が容易に行える。

図 3.60「Pallet System」ショット版：シーン管理画面の一覧

図 3.61

個人のタスク画面（シーン用）
CAT SHIT ONE -THE ANIMATED SERIES(C)2010 小林源文/アニマ・IDA

90

図 3.62

3. 63⑦

シーンごとの進捗管理画面

個人タスクのグループチェック画面改善効果

モデル作成では、モデル作成を忘れるようなケアレスミスが減った。
モデル作成において、5 体以上あると効果を感じられる。1 体作成に 3〜4 名で分担している。

⑧

問題点



Gantt 機能がない

デザイナーが作業に使っているアプリケーションからパブリッシュするためのツールがまだないため、アセット管理ツール・ショット管理ツールの自動更新がされない。アニメーターはやり取りが多いため、二度手間になりやすく使いにくさを感じることがある。



1〜2 分程度の短い作品では、管理ツールを使うことによるオーバーヘッドが大きくなる。20名以上が参加するプロジェクトでは効果がわかる。

⑨

今後の取組

モデル管理ツールは 30 名ほどのプロジェクトで運用した。アニメーション管理ツールでは 10名ほどで運用した。それぞれ実行速度による不満は出ていない。ただし、大規模なプロジェクト

91

CAT SHIT ONE -THE ANIMATED SERIES(C)2010 小林源文/アニマ・IDA

での使用はこれからなので、未知数な部分もある。
現状、Pallet System は社内ネットワークでのみ使用可能な状態にしている。同システムを利用し、クライアントが品質チェックできる機能への拡張を考えている。その際、サーバは社外向けに設置せず、VPN 接続を用いてアクセスすることにより、開発コストをかけずにセキュリテ
ィを確保することを検討している。
将来的に、スケジュールや予算なども踏まえた全体のシステムを管理するツールが必要であると考えている。これまでのツールと同様にウェブアプリケーションにすることを検討している。

92

(2)

事例：株式会社オー・エル・エム・デジタル

訪問日：2013 年 1 月 8 日

場所：株式会社オー・エル・エム・デジタル（東京都世田谷区若林）

協力者：四倉達夫 研究開発部門 博士（工学）

①

業務内容

数多くの TV・劇場アニメーションのほか、映画や CMなどの CG を作成する。TV ドラマや映画などの実写映像、立体映像の制作なども行う。

②

社内インフラストラクチャ

オー・エル・エム、オー・エル・エム・デジタルと分かれているが、社屋は同一の別階に入っている。オー・エル・
エム・グループの一つである Sprite Animation Studio は
米国ロサンゼルスに拠点を置いている。オー・エル・エム、

図 3.64

OLM

オー・エル・エム・デジタルはインフラを共有している。
専用のサーバ室を持ち、基幹ネットワークはフロア間を
20 Gbps でつないでいる。
バックボーン
レンダリングサーバ：250 以上 (1800 コア以上)
MS-Windows、Linux
ストレージ：300 TB 以上 (実効容量)
デ ザ イ ナ ー が 使 用 す る PC は 200 台 以 上 、

図 3.65

サーバー室

MS-Windows・Linux・Mac がプロジェクトにより使い分けられている。
サーバー・ストレージは、一つのパーティーションに見えるようになっており、全ての PC で同じように見えるようにマウントされる。CG データは全ての作品がサーバー・ストレージに集約され、ツールを使って決められたルールでディレクトリ構造が作成される。作業ファイルはローカルディスクの使用を禁止し、ツールを経由してサーバー・ストレージの決められた場所に保存する。サーバー・ストレージのツールを使用しない直接的な操作は運用ルールで禁止されてい
る。

③

体制

R&D 部門により開発され、各部署に導入を行う。

93

構成

④



研究：3 名

開発：3 名

SI：4 名経緯

2008 年頃から開発はスタートし、現在も続いている。常時、大小あわせて 10 本程度の作品が同時進行しているため、パイプラインの効率化やマネジメントのサポートツールが必要であった。

⑤

開発

社内のパイプラインを効率化するためのツールを、全て R&D 部門により作成されている。各
種ツールを総称して OLM パイプラインツール、CDVis (Creator's Desktop Visualization)と呼称している。
CDVis は以下のツールを含んでいる。


OLM Setup

Dir Maker

AM ToolUp ToolMosaic Tool

PM Tool

システム構築の指針として、データを中心としたアセット管理から工程管理を目指している。
基本方針としてデータベースは使用しない。データベースのスペシャリストがいないため、リ
スクを回避するための処置である。専門家がデータベース設計と管理をするものであり、優秀な開発者であっても構成変更をしたときの混乱が予想されるためである。

⑥

CDVis

(a)

OLM Setup

プロジェクト開始時に R&D 部門から関係者へ配布される。作業開始に先立ってツールを実行することにより、デザイナーが使用するアプリケーションのセットアップを自動的に行える。手作業になる部分はないため、プロジェクトに関わるデザイナーのマシン環境は統一される。
当ツールは以下の機能を有している。


プラグインをサーバから自動コピー
プロジェクトで使用するプラグインの種類とバージョンが自動的に設定される。



バッチファイルからアプリケーション実行
バッチファイルにプロジェクト用の環境変数が設定され、アプリケーションが起動するようになっている。

94

(b)

DirMaker

規定されたディレクトリ構造を自動的に作成するツール。Maya や 3dsMax といったアプリケーションから実行する。
Element ディレクトリ作成で Element 名に自動的にプ
レフィックスとしてアルファベット 1 文字が付与される機能を持つ。同じ Element でもパターン違いを作成することがあるためである。

(c)

AM Tool

アプリケーションのプロジェクトファイルのロード・セーブを行うツール。
プロジェクトファイルにはバージョン番号が付与される。バージョンは、メジャーとマイナーの 2 つに分けられる。メジャーバージョン番号は、マネージャーの決めた運図 3.66

DirMaker用ルールで使用する。マイナーバージョン番号は、個々人が自由に使用する。
Up Scenes ボタンは、メジャーバージョン番号が自動的に 1 増える。Share ボタンは、共有ス
ペース（Share ディレクトリ以下）へ保存される。メモを残すことができる。フォルダに HTMLとして出力される。

図 3.67

AM Tool for Maya

モデル・シーン・ライティング・アニメーションなどのプロジェクトは個別に保存される。シーンにモデルを配置するときは、モデルデータはリファレンスとして持ち、プロジェクトファイ
ルには取り込まない。AM Tool には、何をリファレンスとするかを管理する機能を有している。

95

この機能により、次のような効果がある。

(d)

データサイズ削減

データが分散されないため一元管理できる。例えばモデルデータの変更時に効果的。

エレメントデータの一覧

エレメントデータを一覧表としてウェブブラウザで参照する。オリジナルは Excel で管理しているが、HTML 形式に変換し見やすいよう最適化がされる。ムービーを連続再生する機能を有し、簡易的なレビューができる。エレメントデータにはメモを付けることができる。

(e)

Up Tool

チェック・納品のためのツールである。レンダリングが終わった連番画像ファイルを、アプリ
ケーションにドラッグ・アンド・ドロップすると規定のパスにコピーされる。同時に QuickTime
形式や 2-3 プルダウンを自動的に行うこともできる。

図 3.68(f)

Up Tool

Check Viewer

エレメントのリリース忘れがないかをチェックするツール。
通常、デザイナーは AM Tool でプロジェクトを作成し、ホームフォルダで作業する。完成すると同ツールでリリースする。リリースするとシェアフォルダにコピーされる。このツールによりリリースされていないエレメントのチェックや、まだ作業中のエレメントを自動的に検出して一覧することができる。
アニメーション制作では、1 話約 15TB の容量を使用している。膨大なファイルを手作業でチェックすることは困難である。

96

図 3.69(g)

Check Viewer

Mosaic Tool

ステレオ 3D 映像編集をサポートするツールである。ステレオ 3D 作品では、単眼用と立体用
として左目用（L）と右目用（R）の 3 種を編集しなければならなかった。このツールでは、単眼用に編集した EDL をもとに、LR 映像の EDL と連番画像ファイルを自動的に収集・生成を行う。

(h)PM Tool

プロジェクト管理を行うツールだが、現時点で未完成である。事前の調査によると、10〜12名程度だと、プロジェクト管理システムを導入すると工数が増えるという。これよりも大きなプ
ロジェクトの場合、プロジェクト管理システムが必要となる。

⑦

改善点



ヒューマンエラーが発生しやすい場所を減らすことが出来た。



自動化により高速化した。

⑧


問題点
このシステムは、全プロジェクトの作品で運用されているが、アニメ・フル CG・実写に特化したシステム設計になっていない。そのため、例えば実写専用のツール・パイプライン構築までは至っていない。



このシステムは 1 箇所の拠点で作業が完結する前提で作成しているため、多地点での作業に対応していない。

⑨

今後の取組

作成済みのツールに関して、これ以上の機能追加はしない方針である。ツールの使い方を説明するためのチュートリアルを用意してはいるが、機能追加により複雑化してしまうと、教育コストが増大してしまうためである。
現時点で工程管理システムを導入していないが、その代わりとして研究・調査中の PM Toolを開発予定である。基本的に自社開発を行う。海外ソフトウェアの TACTIC が無償化したため、今後このソフトウェアについても研究したいと考えている。

97

(3)

合同会社ダンデライオンアニメーションスタジオ

ヒアリング日：2013 年 1 月 17 日

場所

：経済産業省

協力者：西川和宏 代表／CG ディレクター
服部剛 CG テクニカルディレクター

①

業務内容

劇場映画・テレビシリーズ等を中心とした CG アニメ企画・制作
スタジオ。
2D・3D に関わらずデジタルアニメーション全般を行う。

②

社内インフラストラクチャ

スタッフ数約 50 名の中規模な体制で、主に CG スタッフの制作
スペースとなる本社スタジオと、管理業務スタッフのいる第二スタ
ジオの間を、上り 100 Mbps/下り 200 Mbps で繋ぐ。
バックボーン

ファイルサーバ：QNAP 社の NAS を 4 台導入し、そのうち 3 台がプロジェクト用のサーバ 1 台がバックアップ
用のサーバとなる。

図 3.70社屋風景

図 3.71サーバー

1 台当たりの実行容量：5.4 TB（計 20 TB 以上）


レンダリングマシン：26 台（Windows7 64Bit）

クライアントマシン：33 台（Windows7 64Bit）



その他、PM などの制作スタッフ用に 32bit マシンやノート PC など

また、最近は、計算処理や一時ストレージとして Amazon EC2
クラウドを使用している。

③

体制

R&D・システムチーム（計 5 名）により、パイプライン～3D ツールなど全般的に開発し各セクションで導入している。
構成
メイン開発：1 名（サポート 1 名）
各種アプリケーション開発：4 名
ベーシックな機能実装は 2 名で 3 ヶ月の工数がかかっている。運用を開始し、並行して追加の機能実装を行った。ここからは 1 名で 6 ヶ月ほどかけているが、他の開発項目と並行作業であり

98フルタイムではなかった。 3 ヶ月ほどで必要機能の実装は完了する。
メイン開発は 1 名、サポート 1 名であるが、作品ごとのセッティングにはプロジェクトマネー
ジャークラスが行えるようになっている。

④

経緯

プロジェクト数とスタッフ数の増加に伴い、2011
年末から手動の Excel 管理から Google Docs を利用した自動巡回システムへ移行するため随時必要な機能を開発。

⑤

図 3.72

開発

社内風景

プロジェクト管理システム syncrat を、codelight 社との協業により新規開発した。

(a)

概要

syncrat は、Google Spread Sheet のリストとプロジェクトディレクトリを指定した間隔で同期させることにより、プロジェクトの状態を正しく把握するためのシステムである。

(b)

動作環境

プロジェクトディレクトリと Google Spread Sheet 同期するアプリケーションは Python で作成され、MS-Windows で動作している。クライアントはウェブブラウザを用いる。

図 3.73

Google spreadsheets での操作画面

99

(c)

(d)

機能


ファイルの存在確認やその名前の自動表示。



進捗状態や更新日時を自動表示。



該当ファイルのユーザー名の自動表示。

図 3.74syncrat 画面（1）

図 3.75syncrat 画面（2）Google Spread Sheet を選択した理由
プログラム処理・制作進行・作業担当者などが同時に編集可能



リストを手動で編集した結果を、サーバ上のデータに反映させることも可能（例：OKなどの進捗状態）

インターネット環境があれば世界中どこにいても閲覧、共有、更新ができる。



パソコン、スマートフォンなど閲覧デバイスを問わない。（推奨ブラウザは Google
Chrome）



ユーザー個別のアクセス管理ができる。



Excel で作成されたファイルがあれば、アップロードして利用も可能。基本的にコストがかからない。

100

⑥


改善点
同期のためのアプリケーションの動作には、インターネットにアクセス可能なパソコンであれ
ば最低限の Python 環境で利用可能。



作業用のパソコンではウェブブラウザのみを使用。



手動で更新する項目と、自動で更新する項目が共存できるため柔軟なリストが作成できる。



最低限のルールで稼動できる為、当システムを使う為の大きなワークフローの改変が不要。



システムを停止することなくチェック項目のような機能追加が可能。



自動化により時間の節約、情報のリアルタイム化が進み、ヒューマンエラーによるミスがなく
なる。



⑦

ノウハウの蓄積が強力なワークフロー構築の叩き台になる。

問題点



ルールに添えないような場合に正しく機能しない。イレギュラーな状況に弱い。



1 ファイルで複数カット作るような場合、ディレクトリ管理は不適切である。



状態を反映させるシステムな為、｢初回」、「二回目」などの情報が必要な場合に注意が必要。



ディレクトリ名を活用することで成立しているので名前の判定に厳しい。(大文字小文字など)

Google のサービス上に情報を載せることをセキュリティ上どうとらえるか。

Google のサービス又は Google の提供する API に大きく左右される。

⑧


今後の取組
Google のアプリケーションなどと今後組み合わせていくことで、集計リストなどをグラフィカ
ルすることも可能（プロデューサーなど俯瞰情報を見たい人向け）



複数社で同一システムを共有できるようになれば仕事の大小にかかわらず共同作業が円滑に進められる。



プロジェクトサーバー（ストレージサーバー）もクラウド上に設置できればどこにいても同一の環境で作業ができる。



codelight 社との協議を踏まえて、ベースのシステムを無償で公開する可能性もある。（各社用のマイナーチェンジや保守などは codelight 社での管轄）

101

(4)

2D アニメプロダクション合同ヒアリング

ヒアリング日：2013 年 1 月 22 日

場所

：東宝スタジオ センターホール C

協力者：株式会社オー・エル・エム・デジタル 四倉達夫
株式会社カラー 瓶子修一、緒方智幸、岡島隆敏
株式会社スタジオディーン 飯嶋浩次
株式会社スタジオ雲雀 齋藤成史
東映アニメーション株式会社 野口光一
株式会社プロダクション・アイジー 安芸淳一郎①

目的

これまでは主に実写関連と CG 関連の企業の制作工程管理システムについての調査であった。
同じ映像であるアニメプロダクションは、歴史的な理由から導入が難しくなっているということについてヒアリングによる調査を行った。

②


制作工程管理システムについて
マイクロソフト社の Excel に代表される表計算ソフトを利用し、手入力による管理を行なっている。



過去に制作工程管理システムの導入実験を行ったが事実上失敗した。



個々のアニメーターにコンピュータ操作のスキルを求めてこなかったため、扱えない人がいる。



2D アニメーションと 3DCG の両方が含まれる作品であっても、作業は切り離して管理している。

3DCG のカットを 2D アニメーションのシステムに合わせてカット袋に入れて受け渡しをして
いる。



③

2D 側のルールが既に完成されているため、3DCG 側が合わせている。

カット袋



カット袋に書かれた情報を見ることで、どういう状況で誰が何をしたかを容易に把握できる。



カット袋には複数の役割があり、カット袋自体がデータベースとなっている。



カット袋は非常にプリミティブな制作工程管理を実現している。



カット袋を使ったアナログの工程が完成しており、それで満足している部分はある。



歴史ある会社ほど現状のままでよいと考えると思われる。



カット袋はディズニーの発明品であり、アニメーション初期の頃から使われていた。長い年月により最適化が進んだ。



日本からの海外発注している分について、同じカット袋のシステムを使用している。



過去にカット袋のデジタル化を取り組んだことがあったが失敗に終わった。

102



海外ではディズニーが 2D アニメ制作から 3D アニメ制作に移行したため、カット袋を使用しなくなった。

図 3.76④


カット袋

図 3.77

カット袋(リテイク指示あり)

タイムシート
タイムシートは主にアニメーターがつくる。ただし、作画以降で変更されることもあり複数の段階がある。



紙で作画する段階でタイムシートをつくるため、紙の方がロスなく都合が良い。



デジタル化されればタイミング変更が容易になるのでメリットはある。



鉛筆での入力と同等又はそれ以上の使い勝手があれ
ばデジタル化される。

⑤

背景美術



背景美術についてはデジタル化が進んでいる。



アニメーターに比べての作業量が少ないため集約しやすくデジタルに向いていた。



デジタル化が普及したのはあるプロダクション がAdobe Photoshop の導入を強力に進めたため。このと図 3.78き、適切なコストで高クオリティであったことが証明され一気に普及した。
⑥

8〜9 割くらいは Adobe Photoshop が使用されている。

用語

2D アニメの用語はほぼ統一化されている。



見積もり時の項目についても、ほとんどの会社で用語が同じである。

103

タイムシート⑦


デジタル化
仕上げ・撮影・編集ではデジタル化が進んだ。その一方で、上流工程の作画はほとんどデジタ
ル化されていない。



デジタル化されないのは紙で絵を描くための最適化がなされているため。



紙と鉛筆で描くことの生産性とコストのバランスがとれているため、現状ではデジタル化する必然性がない。



その一方、若い世代がデジタルで作画している。彼らが 10 年後、20 年後に制作工程管理シス
テム導入を考える可能性がある。



作画の段階では手戻りが発生することがある。規定のワークフローに当てはまらないため、システム化しにくい。



ワークフローを固定化しないほうがスムーズにいくこともある。



デジタル化の成功例を作れば一気に広まると思われる。



東映アニメーションでは、フィリピンでの作画をデジタル化している。

⑧

開発力とコスト

日本のアニメ制作会社には北米のような開発力を持っていない。



現状で制作費が安いため、制作工程管理システムやデジタル化導入がコスト削減の目的になりえない。



デジタル化にはクオリティを上げるため、共通基盤として利用するためといった明確な理由が必要。

2D アニメではコストのかけ方やルックの違いが明確であるが、3DCG はリテイクがしやすい
ためどこまで手を加えるかの調整が問題となっている。そのため、コストが 4〜5 倍かかってしまっている。必然的に効率化によるコスト削減が求められている。

⑨

問題点



表計算ソフトで管理する場合、1〜2 名がチェックするだけであり、ミスが発生しやすい。



管理者の中にはコンピュータスキルが足りないため、表計算ソフトを扱えない人もいる。



フリーランスのアニメーターの管理に苦労している。

フリーランスのアニメーターのために機材導入コストをかけることができない。



カット袋をつかったシステムが完成されているため、デジタル化するメリットが見つからない。



他社と足並みがそろわないとデジタル化できない。



作画を再利用することは難しい。デジタル化によるコピーのメリットを受けられない。



いままで手書きで作画している人をデジタルへ移行することは難しい。

⑩

将来の展望



デジタル化によって制作進行の人に依存しない又は減らすことで効率化したい。



2D アニメは効率化が進んでいるため、横の連携やボトルネックの解消などに期待している。

104



スマートフォンとの連携はあると思われる。

SIGGRAPH のディズニーによる「紙ひこうき」(Paper Man）は、3DCG に 2D の技法が融合した新しい方法であり研究の価値がある。日本の市場にも 2D と 3D のハイブリッドアニメには需要があると思う。

⑪

まとめ

アニメ制作現場において、カット袋とタイムシートが長い年月により完成されたものであることが、制作工程管理システムを導入する動機になり得ない理由であった。作画が紙とエンピツで描かれており、アナログであるため、デジタルである制作工程管理システムと相性が悪いと言える。また一社でデジタル化を進めることは、予算の点と他社との連携という点において難しい。
新しいデジタル世代が台頭してくる時代を待てば変化は期待できる。また、北米市場では 2Dと 3D の融合の試みもあり、日本でも需要が発生する可能性がある。それに伴い、作画のデジタ
ル化が進むことになれば、制作工程管理システムの導入が求められることもあると考えられる。

105

3.6

まとめ

3DCG は、誕生時からデジタルデータによる管理が前提であった。実写映像の場合、VFX な
どはデジタルであったが、その他の部分はフィルムによって管理されていたが、近年デジタルシ
ネマカメラの普及とフィルム撮影の減少により、撮影から納品までの全ての工程がデジタルとなりつつある。2D アニメーションは、手書きによる作画はいまだアナログではあるが、彩色・背景美術・撮影・編集はデジタル化された。多くの映像素材はデジタル化され、その容量は膨大なものとなっている。そのためアセット管理やショットと関連するカラーマネジメントとメタデー
タの共通化や相互に変換できるルールの整備を行うことは急務であると言える。

図 3.79

分野によるデジタル化の相違

いくつかの企業においては、制作工程管理システムの導入に積極的であり、それぞれの社内事
情にあわせるため独自で開発している。また、基本的に紙と鉛筆による作業が大半を占めるアニ
メ業界では、カット袋を用いたアナログによる作業効率化が極限まで発達し業界内に浸透し過ぎた結果、デジタルでの新たな工程管理システムの導入には難しさがうかがえた。これに関しては、
次世代の制作工程管理システムの必要性が問われる反面、書き手（作画スタッフ）の世代交代や、紙と鉛筆に代わるデバイス（タブレット）などの浸透と合わせて今後検討していく課題であると思われる。
北米を中心とした海外大手プロダクションでは、長年に渡った努力により制作工程管理システ

106

ムが確立されてきた。最近はこれまでのノウハウをパッケージ化したソフトウェアを日本でも入手することはできるようになっているが、購入したソフトウェアを自分たちの仕事の流れの中に取り込み、時には自らのやり方を変えながらシステムを構築するということは非常に難しい。それでも、これまで長年に渡って蓄積されたノウハウ
や技術は貴重なものであり、積極的に取り入れていくべきである。
システムを導入するに当たっては、規模に応じて実現すべきレベルが変わってくる。これを図3.80 に示す。10 名程度の組織と 100 名の組織では注力すべき部分が変わってくる。組織の規模やレベルに合わせて段階的にシステム化をしなけ

図 3.80

プロジェクト規模と導入レベル

れば、制作工程管理システムの構築はうまくいかない。また、システムを構築するに当たって、既存のソフトウェアでは足りない部分を補うための努力は常に行う必要がある。
今後は、国内の映像業界の実状に合わせた制作工程管理システムの基盤整備と普及を行っていく必要がある。国内映像企業の発展のために、日本国内向けの制作工程管理システムの構築及び導入・運用のためのサービスも必要である。同時に、映像制作に必要なアセット、メタデータ、タスクの呼称などの情報を集約し、それぞれの名称を統一するなど規格標準化することにより、合理的かつより進歩的な制作工程管理システムの構築が可能となる。それにより、社内の管理だ
けでなく、社外間での共同作業を行う際にも高度でスピーディーなコミュニケーションの連携が生まれることが予想される。

3.7

参考文献



ディジタル映像表現 ―CG による映像制作― （画像情報教育振興協会）



プロフェッショナルのための「デジタルアニメマニュアル 2009」 （デジタルアニメ制作技術研究会）



平成 18 年度広域的新事業支援連携等補助事業「新商品・技術評価事業」「アニメーション制作における物流管理等に関する実態調査」 （財団法人デジタルコンテンツ協会）



SHOTGUN CASE STUDY http://shotgunsoftware.com/docs/Shotgun_Zoic_CaseStudy_Aug-2010.pdf （Shotgun
Software Inc.）

ITU-R Recommendation BT.709-5 http://www.itu.int/rec/R-REC-BT.709 （ITU）



Digital Cinema System Specification Version 1.2 with Errata as of 30 August 2012 Incorporated, dated 10 October
2012 http://www.dcimovies.com/specification/ （Digital Cinema Initiatives, LLC）

107

第4章
4.1

クラウドを活用したレンダリングシステム

調査概要

本章では、CG・VFX 業界における映像制作工程の中で非常に高いウェイトを占める、レンダ
リングに係るリソースの最適化に必要なシステムの検討と、そのために実施した調査及び実証実験についてまとめた。現状を把握するための調査、考察、分析と、クラウドレンダリングを前提にしたジョブ管理、レンダリング、データ転送の実証を行った。本事業の実施により、クラウド
レンダリングの可能性と課題を明確にし、サービス利用者のパイプラインの改善並びに今後のサービス提供事業者の事業展開の参考となる指針を示す。
現在様々なレンダリングサービスが存在するが、ハードウェアやシステム構成において、ほぼ同様となっていると考えられ、その差別化は難しい。あえて、差別化を図るのであれば、仮想環
境にアクセスした際のコントロール機能の優劣を基準とする必要がある。既存のレンダリングサービスは、原則としてレンダリング事業者がレンダリングを請け負い、その環境内（ソフトウェ
アのライセンスを保有）でレンダリングが実行される。本事業で検討対象とするクラウドを用いたレンダリングとは、要約するとユーザーからのアクセスを許し、他社の環境（他社のライセンス）での作業を行うというものと、定義される。実質的には、既存のレンダリングサービスもオンラインでのジョブ管理に対応しており、クラウド化が進んでいる。

4.1.1 調査の背景と目的
今日のアニメ、映画、ゲーム、遊技機のコンテンツに欠かせない 3DCG 映像は、ハードウェア
並びに制作ソフトウェアの進化と相まって、高品質化、高解像度化によって処理量が増加し、制作するプロダクションにとって、レンダリングパワー、エンコードパワー、ストレージ不足が常に制作進行上の深刻な課題となっている。高品質な 3DCG 映像を効率よく短時間で生成するために、制作コストの多くをインフラ構築に投資する必要がある。多くの制作費を割り当てられない
日本の現状では、プロダクションが所有するレンダリングファームの維持管理の負担は大きく、コンテンツ制作における国際競争力の低下と産業衰退の原因にもなりかねない。3DCG 映像制作
パイプラインの改善は急務であり、新規参入者の妨げにもなると考えられる。プロダクションのコスト削減に貢献する可能性のあるクラウドレンダリングの基盤整備は、日本の映像コンテンツ制作事業者の競争力を強化できるばかりか、国、地方自治体にとっては雇用促進、人材育成、産業育成にも貢献すると考えられる。
そのため、本事業では、CG・VFX 業界におけるレンダリングに係るリソースの最適化のために必要なシステムの検討に当たっての調査及び実証を行い、クラウドレンダリングの可能性を探る。
108

4.1.2 調査体制
本調査は、一般社団法人日本コンテンツ振興機構のメンバーを中心としたコンソーシアムにて
実施した。

図 4.1



体制図

実施期間
2012 年 11 月 6 日～2013 年 2 月 6 日



要員

村上 徹

株式会社ボーンデジタル

石橋 俊雄

株式会社ボーンデジタル

中嶋 雅浩

株式会社ボーンデジタル

渡辺 英樹

株式会社ボーンデジタル／株式会社ワークスコーポレーション

鈴木 勝

株式会社白組斎藤 成史

株式会社スタジオ雲雀

宮本 逸雄

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

109

4.2

調査内容

本調査では、現状把握と実証実験の 2 つに大別して調査と分析を実施した。現状把握は、業界が置かれている状況を把握すること、課題や問題点を把握すること、今ある技術を理解することに主眼をおいて調査分析を実施した。実証実験は、実際にクラウド環境を想定した実環境を作り、実際に運用できるのか、どんな問題が発生するのか、実際のサービス運営に必要な課題は何かな
どをプロダクションが利用することを前提として実験を実施した。詳細に関しては、後述の「4.3
調査と分析」のとおり。

4.2.1 調査項目の選定
現状把握内容は、以下のとおり。


先ずクラウドレンダリングサービスの課題を考察。



日本のプロダクションの現状を理解するため、個別アンケート及び聞き取り調査を行うことによって、プロダクションの規模、ワークステーションの環境、レンダリングマシンの環境、利用ソ
フトウェアの環境、プロダクションにおけるクラウド及びレンダリングサービス事例の調査、プ
ロダクションが抱えるレンダリングの課題を調査。



クラウドでの課題の分析を行うため、3DCG ソフトのライセンスの調査、プラグインのライセンスの調査、ジョブ管理システムの調査、ネットワーク高速化技術の調査分析、クラウドライセン
スの価格の調査。

実証実験としては、下記の環境と内容を実施。


IBM 幕張にレンダリングサーバを設置、デジタルハリウッド御茶ノ水にレンダリングを実行する環境を構築、外部のクライアントマシンからデジタルハリウッド御茶ノ水にレンダリング及び転送を実施。詳しくは「4.3.4

実証実験」を参照。

110

図 4.2



実証実験システム機材概要

IBM 幕張とデジタルハリウッド御茶ノ水の機材を利用したジョブ管理システムの実証。利用する
ジョブ管理アプリケーションは Backburner を使用。レンダリングソフトウェアは mental ray、Maya 2013、3ds Max 2013 を使用。



デジタルハリウッド御茶ノ水の機材を利用したレンダリング実証。仮想マシンと実マシンによるレンダリングの差異を検証。



外部スタジオとデジタルハリウッド御茶ノ水の機材を利用したファイル転送実験。使用アプリケーションは、Aspera、Skeed、FileZilla を使用。

111

4.3

調査と分析

4.3.1 クラウドレンダリングサービスの課題
クラウドレンダリングの共有基盤環境を構築するに当たっては、様々な技術的課題が存在する。ここでは課題を解決するため、要素の分析並びに検証を行った。
IT インフラの性能向上度合いを主に決定する PC パーツの技術進展について表に示す。
表 4.1

比較パーツ

PC パーツ別比較表

1997 年

2012 年

性能向上率

CPU

Pentium 200 MHz

Xeon E5-2680 2.7 GHz

2,600 倍(演算性能比)

メモリ56.3 万円/GB

515 円/GB

1,093 倍(GB 単価比)

ハードディスク

1.5 万円/GB

3.4 円/GB

4,412 倍(GB 単価比)

ネットワーク56 Kbps

1 Gbps

18,725 倍(帯域比)IT インフラの技術進展を上記 4 パーツで記したが、全てのパーツが 15 年度で向上率が1000 倍を超えている。レンダリングの要となる CPU 演算性能も 2600 倍向上し、現在では実写と判別がつかないほどの劇場映画も制作可能になっている。特に、ネットワークの速度は桁違いに向上している。
映像コンテンツ制作業界の IT インフラの特徴としてレンダリングシステムの存在がある。
このレンダリングシステムは、コンテンツ制作を円滑に進めるうえで欠かせないものであるが、ハリウッド映画大作級の制作に利用されたレンダリングシステムは多いものでは4000 台規模のサーバで構成されているなど、スーパーコンピュータ級のシステムの場合が多く、また利用者も限定されるので、投下資本の効率的運用という点で問題があった。
また、劇場映画などの複数企業が連携して制作する事例では、国内プロダクション間の映像素材データの受け渡しは、未だ物理メディアの運送に頼っている場合が多い。これは素材データが大きいものでは数 GB、シーン及びカット数が数百に渡る場合があるが、デー
タを取り扱うための回線やファイル転送システムが整備されていないためである。レンダ
リング自体が数時間で終わる場合も、素材データの配送に 2 日程度必要となるなど、業務効率を上げるためにも改善の必要がある。

(1)

レンダリングシステムに適したハードウェアのサイジング

CG・VFX 業界向けのクラウドレンダリングシステムを構築するに当たっては、WEB 業
界等で既に活用されているクラウドサービスよりもハイパフォーマンスの機材を準備する
112

必要がある。現在、映像制作分野のレンダリングシステムは、①高速な CPU 速度、②大容量のメモリ、③大容量の 2 次記憶領域、といった傾向のハードウェアを、複数台で分担してレンダリング作業を行っている。
そして、個々のノードでは①単一のタスクが実行される、②タスクは長時間に渡り高負荷の状態で計算される、③ノードは一つのタスクが占有し、他の計算が並列で動くことは無い、といった傾向でレンダリングが進むこととなる。
ところがこの傾向は、現在運用されている WEB 業界向けクラウドサービスとは異なる。
WEB 業界向けのクラウドサービスは、①大量のリクエストが発生する、②個々のタスクはごく短時間で完了する、③小さなタスクが並列で動作する、といった傾向が強いため、映像業界向けには独自のハードウェアサイジングが必要であると考えられる。
そこで、現在映像制作を行っている CG プロダクションの現在のレンダリング環境を調査・分析し、適切な機器構成の選定を行う。

(2)

仮想 OS でのパフォーマンス調査

昨今のクラウドサービスにおいては、OS の仮想化技術が利用されている。
仮想 OS で大規模なレンダリングシステムを運用できるならば、ハードウェアの動的なスケーリングが可能となるため、非常に有用であると考えられるが、仮想 OS 上では実 OS に比べ若干パフォーマンス低下すると予想される。
そこで、実 OS と仮想 OS で CG アプリケーションの動作比較を行い、レンダリングを行った際に、どの程度パフォーマンスの変化が起こるかの検証を行う。

(3)

各種ソフトウェアのライセンス形態の調査

映像制作用アプリケーションは非常に高額であり、ライセンス形態も多種多様である。
また、そのライセンス形態によっては、譲渡や賃借、また事業所外の遠隔地で使用した場
合等で、ライセンス違反となるソフトウェアもある。そのため、主要ソフトウェアの現状を調査すると共に、クラウドレンダリングでの使用時の契約上の問題の調査を行う。また、関連するソフトウェア（プラグイン等）も同様の問題があるため、これも調査を行う。

(5)

ジョブ管理システムに関する調査と検証

レンダリングを管理するためのジョブ管理システムには、既存のソリューションがいく
つか存在する。これらのソフトは、一般的には社内 LAN 等の閉じられたネットワークで利用されることが多いが、近年遠隔地でのレンダリング管理も視野に入れた製品もいつくか登場している。
クラウドレンダリングシステムを実際の作業現場で使用する場合、社内 LAN から、遠隔地にあるレンダリングノードに対し、インターネット経由でジョブを投入する必要があるが、この際、映像制作を行うアーティスト側からは特に意識することなく、シームレスに113

社内ネットワークと、クラウド側のネットワークの接続が行えることが望ましい。
そのため、既存のレンダリング管理システムを使用した構成を検証する必要がある。

(6)

ネットワーク構築と、効率的なファイル転送

遠隔地でのレンダリング作業を行うためには、大容量の元素材データを各レンダリング
ノードから参照する必要があるまた、レンダリングされた映像データの書き戻しも必要もあるため、大量のデータ転送が発生することとなる。
また、遠隔地とのデータ授受を、セキュリティを考慮しつつも高速に行いたいというニーズもあるため、現状のネットワーク転送技術に加え、高速ファイル転送ソリューション
の検証を行う。

4.3.2 プロダクションの環境調査(1)

調査目的とヒアリング先の選定理由

(a)

調査概要

国内のレンダリング規模並びに概要を計る参考とするために、プロダクションを 9 社ピ
ックアップし、制作環境調査を実施した。調査対象となったプロダクションには、大規模から小規模に渡るまで対象を設定している。


大規模プロダクション：150名以上



中規模プロダクション：50名〜150名



小規模：50名以下①

選定方法について選定するに当たって、映画、アニメ、テレビ、ゲーム、遊技機という CG 制作業界の主な業種をカバーするように選定した。

②

調査項目について調査項目としては、ワークステーションの数とスペックとその作業内訳、レンダリング
マシン数とスペック、制作に使用するアプリケーション数となっている（詳細は以下）。

114

(b)


調査項目
ワークステーション：マシンスペック（メーカー、CPU、クロック数、ソケット数、コア数、RAM、GPU、OS）とその導入台数と使用する作業

レンダリングマシン：マシンスペック（メーカー、CPU、クロック数、ソケット数、コア数、RAM、GPU、OS）とその導入台数と使用する作業

レンダリング仕様と管理：レンダリング解像度及びフォーマット、導入しているレンダリ
ング管理ソフト名、カスタマイズの有無ソフトウェアとプラグイン：導入している 3DCG ソフト・プラグイン、バージョン、台数

クラウドレンダリング及び遠隔地レンダリングの実績：実績の有無（有の際はその概要）(2)

プロダクション環境調査(a)

プロダクション環境調査一覧① A 社（所在地：東京渋谷区

スタッフ数：250 名）

業務内容：映画、ゲーム、遊技機
表 4.2
メーカー

CPU

ワークステーション（A 社）

クロック数 ソケット コア数 RAM

GPU

GPU（品番）OS

台数

DELL Prescision T5400 Intel Xeon E5430 2.66 GHz

2

4

12 GB NVIDIA Quadro

FX 3700

Windows 7 64bit 101

DELL Prescision T7400 Intel Xeon X5482 3.2 GHz

24

16 GB NVIDIA Quadro

FX 4600

Windows 7 64bit

DELL PrescisionT5500

Intel Xeon E5620 2.4 GHz

2

4

12 GB NVIDIA Quadro

FX 3800

Windows 7 64bit 71

DELL Prescision T5500 Intel Xeon X5670 2.93 GHz

2

6

24 GB NVIDIA Quadro

FX 3800

Windows 7 64bit 124

HP Z600

Intel Xeon E5620 2.4 GHz

2

4

12 GB NVIDIA Quadro

FX 3800

Windows 7 64bit 21

HP Z600

Intel Xeon E5620 2.4 GHz

2

4

12 GB NVIDIA Quadro

4000

Windows 7 64bit 100

HP Z600

Intel Xeon X5675

2

6

24 GB NVIDIA Quadro

4000

Windows 7 64bit

GPU（品番）

OS

3 GHz

表 4.3

2

レンダリングマシン（A 社）

メーカー

CPU

クロック数 ソケット コア数 RAM

DELL T5400

Intel Xeon E5430

2.66 GHz

2

4

12 GB NVIDIA Quadro

FX 3700

Windows 7 64bit 101

DELL T7400

Intel Xeon X5482

3.2 GHz

2

4

16 GB NVIDIA Quadro

FX 4600

Windows 7 64bit

4

DELL T5500

Intel Xeon E5620

2.4 GHz

2

4

12 GB NVIDIA Quadro

FX 3800

Windows 7 64bit

71

DELL T5500

Intel Xeon X5670

2.93 GHz

2

6

24 GB NVIDIA Quadro

FX 3800

Windows 7 64bit

12

115

GPU

台数

HP Z600

Intel Xeon E5620

2.4 GHz

2

4

12 GB NVIDIA Quadro

FX 3800

HP Z600

Intel Xeon E5620

2.4 GHz

2

4

12 GB NVIDIA Quadro

4000

Windows 7 64bit 100

HP Z600

Intel Xeon X5675

3 GHz

2

6

24 GB NVIDIA Quadro

4000

Windows 7 64bit

2

HP Z600

Intel Xeon E5620

2.4 GHz

2

4

24 GB

V3800

Windows 7 64bit

30

HP SL2x170z G6Intel Xeon E5640

2.66 GHz

2

4

12 GB 不明(オンボード)

Windows 7 64bit

32

表 4.4

ATI FirePro

Windows 7 64bit

ソフトウェア・プラグイン（A 社）

3DCG ソフト&コンポジットソフト

本数

プラグイン

本数

Autodesk Maya 2013

177 V-Ray for 3dsMax 2.0

20

Autodesk 3ds Max 2013

23

V-Ray for Maya 2.0

15

Autodesk Softimage 2013

71

3Delight

24

Adobe After Effects CS5

153 FumeFX 3

5

Nuke X

1

2

Nuke 7

10

Autodesk MotionBuilder

51

Vue 6

3

Vue 7

1

Vue 8

3

Adobe Creative Suite Produciton Premium CS6

3

Adobe Creative Suite Produciton Premium CS5.5

12

116

Pencil+ 3

21

②

B 社（所在地：東京都渋谷区ほか

スタッフ数：230 名）

業務内容：映画、ゲーム、遊技機
表 4.5

ワークステーション（B 社）

メーカー

CPU

クロック数 ソケット コア数 RAM

DELL Vostro 460

Intel Core i7

3.4 GHz

Single4

16 GB NVIDIA Geforce

GTX 460

Windows 7 64bit 115

DELL Vostro 470

Intel Core i7

3.4 GHz

Single432 GB NVIDIA Geforce

GTX 660

Windows 7 64bit

37

DELL T3500

Intel Xeon

3.0 GHz

Single4

6 GB

FX 1800

Windows 7 64bit

45

DELL T7600

Intel Xeon

2.4 GHzMulti

16

64 GB NVIDIA Quadro

4000

Windows 7 64bit

5

HP Z200

Intel Xeon

2.6 GHZ

Single4

8 GB

NVIDIA Geforce

4000

Windows 7 64bit

33

HP Z800

Intel Xeon

2.6 GHZ

Multi

12

24 GB NVIDIA Quadro

4000

Windows 7 64bit

34

HP Z820

Intel Xeon

2.4 GHzMulti

16

64 GB NVIDIA Quadro

4000

Windows 7 64bit

5

HP Z820

Intel Xeon

2.4 GHzMulti

16

64 GB NVIDIA Quadro

4000

Windows 7 64bit

5

HP Z820

Intel Xeon

2.4 GHzMulti

16

64 GB NVIDIA Quadro

4000

Linux

9

GPU（品番）OS

台数

HD 3450

Windows 7 64bit

30

表 4.6

GPU

GPU（品番）NVIDIA Quadro

OS

台数

レンダリングマシン（B 社）

メーカー

CPU

クロック数 ソケット コア数 RAM

DELL Optiplex 980

Intel Core i7

2.9 GHZ

Single4

16 GB ATI Radeon

DELL Optiplex 990

Intel Core i7

3.4 GHz

Single

4

16 GB

内蔵

内蔵

Windows 7 64bit

319

DELL Optiplex 9010

Intel Core i7

3.9 GHz

Single

4

32 GB

内蔵

内蔵

Windows 7 64bit

88

HP DL160 G6Intel Xeon

2.6 GHZ

Multi

12

32 GB

内蔵

内蔵

Linux

10

表 4.7

GPU

ソフトウェア・プラグイン（B 社）

3DCG ソフト&コンポジットソフト

本数

プラグイン

本数

Autodesk Entertainment Creation Suite Premium 2013（Maya）

33

mentak ray 201311

Autodesk Entertainment Creation Suite Standard 2013（Softimage）

9

V-Ray for 3dsMax 2

44

Autodesk Maya 201315

3Delight

4

Autodesk 3ds Max 2013

134 FumeFX 3

25

Adobe Creative Suite Produciton Premium CS6

157 Pencil+ 3

16Adobe Creative Suite Produciton Premium CS5.5

57

Adobe Creative Suite Master Collection CS3

1

Nuke X

8

Nuke

1

VueExtream v7.5

3

117

③

C 社（所在地：東京都千代田区

スタッフ数：70 名）

業務内容：遊技機、ゲーム、その他
表 4.8
メーカー

CPU

ワークステーション（C 社）

クロック数 ソケット コア数 RAM

GPU

GPU（品番）
FX 570OS

台数

HP xw4600

Core2Duo E8500 3.16 GHz Single

2

8 GB NVIDIA Quadro

Windows XP 64bit 8

HP xw4600

Core2Quad Q9550 2.83 GHz Single

4

8 GB NVIDIA Quadro FX 3700 Windows XP 64bit 10

HP xw6400

Xeon 5160

3.00 GHz Multi

2

6 GB NVIDIA Quadro FX 3500 Windows XP 64bit 19

HP xw6600

Xeon E5450

3.00 GHz Multi

4

8 GB NVIDIA Quadro FX 1700 Windows XP 64bit 9

HP Z210

Xeon E31225

3.10 GHz Single

4

8 GB NVIDIA Quadro

400

Windows 7 64bit

1

HP Z400

Xeon W3540

2.93 GHz Single

4

8 GB NVIDIA Quadro

FX 580Windows 7 64bit

9

HP Z420

Xeon E5-1620

3.60 GHz Single

4

16 GB NVIDIA Quadro

2000

Windows 7 64bit

1

HP Z600

Xeon X5570

2.93 GHz Multi

4

12 GB NVIDIA Quadro FX 1800

Windows 7 64bit

17

HP Z600

Xeon X5650

2.67 GHz Multi

6

24 GB NVIDIA Quadro

4000

Windows 7 64bit

7

HP Z620

Xeon E5-2640

2.50 GHz Multi

6

24 GB NVIDIA Quadro

4000

Windows 7 64bit

1

DELL Precision T1600

Xeon E31225

3.10 GHz Single

4

4 GB NVIDIA Quadro

600

Windows 7 64bit

1

DELL Precision T3500

Xeon W3550

3.07 GHz Single

4

12 GB NVIDIA Quadro

2000

Windows 7 64bit

3

DELL Precision T3500

Xeon W3680

3.33 GHz Single

6

12 GB NVIDIA Quadro

4000

Windows 7 64bit

4

DELL Precision T3500

Xeon W3690

3.46 GHz Single

624 GB NVIDIA Quadro

4000

Windows 7 64bit

7

DELL Precision T5500

Xeon X5670

2.93 GHz Multi

6

24 GB NVIDIA Quadro

4000

Windows 7 64bit

6

DELL Precision T5500

Xeon X5675

3.07 GHz Multi

6

24 GB NVIDIA Quadro

4000

Windows 7 64bit

4

DELL Precision T5600

Xeon E5-2650

2.00 GHz Multi

8

32 GB NVIDIA Quadro

4000

Windows 7 64bit

5

OS

台数

表 4.9

レンダリングマシン（C 社）

メーカー

CPU

クロック数 ソケット コア数 RAM GPU GPU（品番）HP BL460c

Xeon X5355

2.66 GHz

Multi

4

20 GB なし

Windows 7 64bit

7

HP BL460c G6Xeon E5540

2.53 GHz

Multi

4

20 GB なし

Windows 7 64bit

5

HP BL460c G6Xeon X5670

2.93 GHz

Multi

6

24 GB なし

Windows 7 64bit

8

DELL PowerEdge R410

Xeon X5660

2.80 GHz

Multi

6

16 GB なし

Windows 7 64bit

4118表 4.10

ソフトウェア・プラグイン（C 社）

3DCG ソフト&コンポジットソフト

本数

プラグイン

本数

Autodesk Entertainment Creation Suite Premium 2013（Maya）

5

V-Ray for 3dsMax 2.1

9

Autodesk Maya 2013

23

V-Ray for Maya

7

Autodesk 3ds Max 201334

FumeFX

5

Autodesk Softimage 2013

17

Pencil＋ 3

8Cinema 4D R14

1

Adobe Creative Suite Produciton Premium CS5

26

Adobe After Effects CS5

64

Nuke 6

3

Vue 8

1

Vue 101④

D 社（東京都豊島区

スタッフ数：35 名）

業務内容：遊技機、ゲーム、その他
表 4.11
メーカー

CPU

ワークステーション（D 社）

クロック数 ソケット コア数 RAM

GPU

GPU（品番）OS

台数

Dell PrecisionT1600

Intel Xeon 3.4 GHz

Single4

16 GB NVIDIA Quadro

不明

Windows 7 32bit

35

DELL T3500

Intel Xeon 2.8 GHZ

Single

4

8 GB

不明

Windows 7 32bit

17

GPU（品番）OS

台数

表 4.12メーカー

CPU

レンダリングマシン（D 社）

クロック数 ソケット コア数 RAM

Dell PrecisionT1650 Quad Xeon E3 3.4 GHz Single
DELL T3500

Quad Xeon

NVIDIA Quadro

2.8 GHZ Single

GPU

4

16 GB NVIDIA Quadro

不明

Windows 7 64bit

30

4

12 GB NVIDIA Quadro

不明

Windows 7 64bit

30

119

表 4.13

ソフトウェア・プラグイン（D 社）

3DCG ソフト&コンポジットソフト

本数

プラグイン

本数

Autodesk Maya 2013

3

V-Ray 239

Autodesk 3ds Max 201341

FumeFX 3

3

Autodesk Softimage 2013

1

Pencil+ 3

11Adobe After Effects CS5.5

8

Nuke 6

1

Vue 9

2

⑤

E 社（所在地：東京都杉並区

スタッフ数：103 名）

業務内容：アニメ
表 4.14

ワークステーション（E 社）

メーカー

CPU

クロック数

ソケット コア数

RAM

GPU

GPU（品番）OS

台数

HP Z600

Intel Xeon

2.4 GHz

Multi

8

12 GB

NVIDIA Quadro

4000

Windows 7 64bit

7

HP Z600

Intel Xeon

2.4 GHz

Multi

8

12 GB

NVIDIA Quadro

4000

Windows 7 64bit

26

HP Z600

Intel Xeon

2.4 GHz

Multi

8

12 GB

NVIDIA Quadro

2000

Windows 7 64bit

28

HP Z620

Intel Xeon

2.4 GHz

Multi

8

16 GB

NVIDIA Quadro

4000

Windows 7 64bit

5

HP Z620

Intel Xeon

2.4 GHz

Multi

8

16 GB

NVIDIA Quadro

2000

Windows 7 64bit

9

表 4.15レンダリングマシン（E 社）
GPU

GPU（品番）OS

台数

NVIDIA Quadro

600

Windows 7 64bit

14

NVIDIA Quadro

2000

Windows 7 64bit

2

メーカー

CPU

クロック数

ソケット コア数

HP Z800

Intel Xeon

3.5 GHzMulti

HP Z600

Intel Xeon

2.4 GHz

Multi

RAM

その他 その他
8

12 GB

120

表 4.16

ソフトウェア・プラグイン（E 社）

3DCG ソフト&コンポジットソフト

本数

プラグイン

本数

Autodesk Maya 2013

16

V-Ray 1.55SP6

5

Autodesk 3ds Max 201330

FumeFX 3

3

modo

10

Pencil+ 3

27

Lightwave 10

2Afterburn12

Adobe Creative Suite Produciton Premium CS5

24

DreamScape

1

Adobe After Effects 7〜CS5.5

88

Nuke 6

3

Vue 9

1

Autodesk MotionBuilder

10⑥F 社（東京都武蔵野市

スタッフ数：200 名）

業務内容：アニメ
表 4.17

ワークステーション（F 社）

メーカー

CPU

クロック数

ソケット コア数 RAM

GPU

GPU（品番）OS

台数

HP Z200

Intel Xeon

2.8 GHZ

Single4

8 GB

NVIDIA Quadro

NVS295

Windows XP 64bit

13

その他

Intel Xeon

2.8 GHZ

Multi

4

8 GB

NVIDIA Quadro

Windows XP 64bit

6

表 4.18レンダリングマシン（F 社）

メーカー

CPU

クロック数

ソケット

コア数

RAM

その他

Intel Xeon

2.4 GHz

Single4

その他

Intel Xeon

2.4 GHzMulti

4

表 4.19GPU

GPU（品番）

OS

台数

8 GB

Windows XP 32bit

24

8 GB

Windows XP 32bit

3

プラグイン

本数

ソフトウェア／プラグイン（F 社）

3DCG ソフト&コンポジットソフト

本数

Autodesk 3dsMax 2011?

V-Ray 1.5

5

Autodesk Maya 2008

2

FumeFX 20113

Adobe Creative Suite Produciton Premium CS3

8

Pencil+ 2

6Adobe After EffectsCS3

20

121

⑦

G 社（所在地：東京都練馬区

スタッフ数 120 名）

業務内容：アニメ
表 4.20ワークステーション（G 社）

メーカー

CPU

クロック数 ソケット コア数 RAM

HP Z400

Intel Xeon

2.6 GHZ

Single4

その他

Intel Core i7

3.3 GHz

Single

その他

Intel Core i7

3.3 GHz

Single

表 4.21GPUGPU（品番）

OS

台数

16 GB

NVIDIA Quadro

2000

Windows 7 64bit

12

4

16 GB

NVIDIA Quadro

2000

Windows 7 64bit

20

4

16 GB

NVIDIA Geforce

500 系

Windows XP 64bit

13

レンダリングマシン（G 社）

メーカー

CPU

クロック数

ソケット

コア数

RAM GPUGPU（品番）

OS

台数

その他

その他

3.0 GHz

Single48 GBIntel HD3000

Windows 7 64bit

10

その他

Intel Core i7

3.3 GHz

Single48 GBIntel HD3000

Windows 7 64bit

10

表 4.22

ソフトウェア・プラグイン（G 社）
プラグイン

本数

3DCG ソフト&コンポジットソフト

本数

Autodesk Entertainment Creation Suite Standard2011/2012

3

V-Ray 2.0〜

4

Autodesk Entertainment Creation Suite Ultimate

1

Pencil+ 3.0〜

8

Autodesk 3ds Max 2011~201319

FumeFX 3.0〜

3Adobe Creative Suite Produciton Premium CS3〜CS5.5

43

CellFX

22

Adobe After Effects CS3

18

AfterBurn 4.1〜

3122

HairFarm

若干

TrapCodeSuite2011

20

ReelSmart

10

OpticalFlare

5

LensCare5

⑧

H 社（所在地：東京都豊島区

スタッフ数：15 名）

業務内容：遊技機、PV、その他
表 4.23
メーカー

CPU

その他

ワークステーション（H 社）

クロック数 ソケット コア数

RAM

GPU

GPU（品番）OS

台数Intel Core i7

3.0 GHz

Single4

24 GB

NVIDIA Quadro

FX 4000

Windows 7 64bit

4

その他Intel Core i7

3.2 GHz

Single6

16 GB

NVIDIA Geforce

580GTX

Windows 7 64bit

4

その他Intel Core i7

3.2 GHz

Single4

12 GB

NVIDIA Geforce

不明

Windows 7 64bit

4

その他Intel Xeon

3.0 GHz

Multi

4

8 GB

NVIDIA Quadro

FX 2000

Windows 7 64bit

1

その他

Intel Xeon

2.8 GHZ

Multi

4

32 GB

NVIDIA Quadro

FX 500Windows 7 64bit

1

その他

Intel Core i7

3.0 GHz

Single6

8 GB

NVIDIA Geforce

不明

Windows 7 64bit2

表 4.24
メーカー

CPU

その他

レンダリングマシン（H 社）

クロック数 ソケット コア数

RAM

GPU

GPU（品番）OS

台数Intel Core i7

3.3 GHz

Single6

12 GB

NVIDIA Geforce

不明

Windows 7 64bit

2

その他Intel Core i7

3.3 GHz

Single6

24 GB

NVIDIA Geforce

不明

Windows 7 64bit

2

その他Intel Core i7

3.2 GHz

Single6

16 GB

NVIDIA Geforce

不明

Windows 7 64bit

4

その他Intel Core i7

3.2 GHz

Single632 GB

NVIDIA Geforce

不明

Windows 7 64bit

4

プラグイン

本数

表 4.25

ソフトウェア・プラグイン（H 社）

3DCG ソフト&コンポジットソフト

本数

Autodesk Entertainment Creation Suite Premium 2010~2013

1

V-Ray for Maya 2

2

Autodesk Maya 2011〜2013

10

V-Ray for 3dsMax 2

2

Autodesk 3ds Max 2011〜2013

1

FumeFX 2

1

HoudiniFX 12.1.77

2

Pencil+ 3

1

Houdini Batch 12.1.77

5

Nuke 7

2

Nuke render node 7

10modo 601

1

Lightwave 92

Vue xStream v9

1

Adobe Creative Suite Master Collection CS42

Adobe Creative Suite Produciton Premium CS4

5

Adobe After Effects CS4

8

123

⑨

I 社（東京都練馬区

スタッフ数：15 名）

業務内容：アニメ
表 4.26
メーカー

CPU

DELL

Intel Core i7

不明

SingleDELLIntel Core i7

不明

DELL

Intel Core i7

不明

ワークステーション（I 社）

クロック数 ソケット コア数

RAM

GPU

GPU（品番）

OS

台数

4

24 GB

NVIDIA Quadro

不明

Windows 7 64bit

10Single6

16 GB

NVIDIA Geforce

不明

Windows 7 64bit

4Single4

12 GB

NVIDIA Geforce

Windows 7 64bit

4

表 4.27

レンダリングマシン（I 社）

メーカー

CPU

クロック数

ソケット

コア数

RAM

GPU

OS

台数

不明

Intel Core i7

不明

Single

6

16 GB

なし

Windows 7 64bit

2

不明Intel Core i7

不明

Single

6

20 GB

なし

Windows 7 64bit

2

不明Intel Core i7

不明

Single

6

24 GB

なし

Windows 7 64bit2

表 4.28

ソフトウェア・プラグイン（I 社）
プラグイン

本数

3DCG ソフト&コンポジットソフト

GPU（品番）不明

本数

Autodesk Maya 2011〜201320

FumeFX 2

1

Adobe After Effects CS4

8

Pencil+ 3

1

124

(b)

調査のまとめメーカー比率

CPU比率

2%

6%
23%

52%
Intel Core i7

DELL
HP

42%

75%

Intel Xeon

その他

0%
12%

メモリ比率
12%

10%

その他

1%

4%

64GB
32GB
24GB
16GB
12GB
8GB
6GB
4GB

8%

20%
34%

3% 3% NVIDIAシリーズ比率
11%

36%
35%
11%

2000
4000
FX1000番台
FX3000番台
FX4000番台
FXその他番台
その他

グラフィックボード比率
23%77%
NVIDIA Quadro
NVIDIA Geforce
図 4.3

ワークステーションのスペック調査結果

図 4.3 はアンケートから各種比率を割り出したものである。作業マシンの選定に当たって、特に重視されるのが、メモリ、グラフィックスボードである。メモリ容量としては、16 GBが全体の 20%、12GB が 34%を占め、標準的なメモリ量となっている。グラフィックスボ
ードに関しては、NVIDIA Quadro が 77%となり、スタンダードとなっている。シリーズの内訳としては、Quadro 4000 が 35%、次いで FX3000 が 36%となり、ミドルレンジにあたるモデルが作業マシン選定の基準であると推測される。

125

メーカー比率

CPU比率

7%

10%

23%

47%
70%

DELL
HP
その他

Intel Core i743%Intel Xeon
その他

メモリ比率

1%
5%

10%
6%

1%

37%
40%

図 4.4

32GB
24GB
20GB
16GB
12GB
8GB
その他
レンダリングマシンのスペック調査結果

図 4.4 は調査を行った各社のレンダリングマシンのメーカー、CPU、メモリの比率をグラフにしたものである。レンダリングで重視されるメモリに関しては、16 GB、12 GB が合わせて 80%近くを占めている。

126

4%

ソフトウェア比率

7%
13%

37%
Autodesk Maya
Autodesk 3ds Max
Autodesk Softimage
Autodesk Entertainment Creation Suite

39%

その他
レンダラ（スタンドアロン）比率

合成ソフト比率
5%6%

Adobe After
Effects
Nuke／Nuke X

95%

15%

79%

3Delight
V-Ray
mental ray

レンダラ（ソフトウェア付属含む）
3%
17%

3Delight
V-Ray
mental ray

80%

図 4.5

ソフトウェア・プラグインのシェア

図 4.5 はソフトウェア・プラグインのシェアを示したものである。3DCG ソフトに関して
は、オートデスク製品が 90%を占めていた。また、レンダラに関しては、スタンドアロン（単体で動作する製品）のライセンスでは、V-Ray が 80%を占めるが、ソフトウェアに付属するレンダラを含めると、mental ray が 80%となった。

(3)

プロダクションにおけるクラウド及びレンダリングサービス事例の調査

現状ではクラウド環境の構築にはライセンス問題など様々な課題からサービス自体が一般的ではなく、継続的にクラウドを用いたレンダリングサービスを活用している国内プロ
127

ダクションは調査時点では見あたらなかった。ただし、肥大化するレンダリングのボリュームをこなすため、遠隔地レンダリングはいくつかのプロジェクトで活用されている。その中には、国外のレンダリングサービスなどを活用した事例もあった。その他、複数のス
タジオを持つプロダクションでは、その拠点間での遠隔地レンダリングなども行なわれていた。例として、調査を行ったプロダクションの一つの遠隔地レンダリングの事例について以下に紹介する。

(a)

プロダクション事例：遠隔地レンダリング

①

実施理由

従来からレンダリングコストがかからない工夫を行なってきていたが、VFX 映画に対してエフェクト需要が増し、シミュレーションの活用が増えてきた。シミュレーションでは、
トライ＆エラーの回数も必要で、キャッシュされるデータの量も多くなり大規模な設備が必要になる。当初は同じスタジオで計算できるようにとマシンルームの工夫を検討したが、シミュレーション全体の量が多く、スペースと電力の問題で別のスタジオで計算をすることになった。

②

シミュレーションを遠隔地で行う際の課題

シミュレーションの設定データは軽いが、計算した後のキャッシュデータが大きく、それを全て同期してスタジオに戻すのがかなり難しかった。そこで、シミュレーションからその後のレンダリングまでを別のスタジオで計算を行ない、最終的にレンダリングしたものを戻すという方法をとった。フレームごとのレンダリングが完了するタイミングを使って転送を行う分には、転送の時間差があまり多くならないので、現状のネットワークを使った環境としては、これが現実的であった。

128

図 4.6遠隔地事例(4)

プロダクションが抱えるレンダリングの課題(a)

レンダリングにおける課題

調査アンケートから各プロダクションで抱えるレンダリングにおける課題については、
以下のような声があった。


ボリュームによってはしばしばメモリが不足する。



長編プロジェクトでは社内のマシンだけでは全く足りないので外のファームを使っている。



外部のレンダーファームとやり取りする際に、データの漏洩などが懸念される。



普段使用している RoyalRender にかなり依存したフローとなっている為、そのソフトがな
いファームでレンダーするのは非常に手間が増える。



予測レンダー時間の算出方法が不明確で大まかなものしか立てられない。



複数案件のレンダリング処理が重なった時、非常に大きな処理能力の要求が瞬間的に発生し、自社対応が難しいことがある。今後もそのような事態はいつでも起きうる状態であることが懸念材料。

129

OpenEXR などの大規模シーケンスをレンダリングする際のストレージ及びネットワーク

などのトラフィックが大きくなる。また、シミュレーションなどでも、非常に大きなデー
タになるので、ストレージなどのボトルネックが大きい。


使用しているレンダリング管理ソフトがコア単位でのジョブの割り振りが行えないため、マルチコアマシンでのレンダリングを効率的に行おうとする場合は、別のソフトでノード自体を論理的に分割する必要があり不便。

ディストリビュートレンダリングを行う場合、使用しているレンダリング管理ソフトがリソースを奪い合ってしまい、効率のよい負荷分散ができない。



映像編集・制作ソフトの監視フォルダとレンダリング管理ソフトの組み合わせによっては、どちらかに占有してリソースを割り当てなければならず、使用効率が下がる。



レンダリング管理ソフトによるジョブ管理が安定しない。



レンダリング管理ソフトでのエラー状況の把握に時間を要する。



映像編集・制作ソフトでのレンダリングを、レンダリング管理ソフトを活用してサーバへ投げるのに、プラグイン環境の展開や使用者への技術的な熟練を要する。



どのくらいの計算力で何台程度持つべきかを見極め、レンダリングサーバの導入規模を判断するのが難しい。

(b)

レンダリングの問題点及び課題のまとめ

レンダリング処理量は増加する傾向にあり、自社でもつリソースでは対応するのが難し
くなっている。しかし、作業のボリュームの変化に対応するためにレンダリングファーム
をどの程度準備し維持するかの判断は難しく、多すぎればロスが発生し、少なすぎれば社内で対応しきれない事態が生じることとなる。
外部レンダリングサービスの活用は、社内サーバの維持コストを低減し、必要に応じてリソースを確保できるため、メリットは大きい。ただし、外部との通信の際にデータの漏洩が懸念されるなどの課題も多く、サービスの導入にも判断を要する。
また、レンダリングにおいては管理の面も重視され、カスタマイズ性に優れるジョブ管理システムの導入も求められる状況であった。

4.3.3 クラウドでの課題の分析(1)

3DCG ソフト・プラグインのライセンス調査「4.3.2 プロダクション環境調査」の結果を受け、レンダリングに主に使用されるプラグインに関して、クラウドでのライセンスに関して調査を行なった。
調査の結果、CG ソフトに関しては世界的にみて一部の例外はあるが、ほとんどの場合ク130

ラウドでの利用については契約上許可されていない。国内の主要なツールであるオートデ
スク製品は全て使用不可となっている。それに伴い各ソフト内で使用されるプラグインもクラウドでは原則使用不可となる。将来的にもメーカーとして許可されることは難しいと推測される。オートデスクとしても現在クラウドサービスを展開し始めたところで、今後
レンダリングを含めたサービスに発展する可能性もあり、メーカー主導のサービスが開始される可能性はあるが、第三者のサービスへの使用許可の実現性は薄いと言える。
一方で、レンダー系のプラグインは使用できるものが、調査の時点でいくつかあった。
Render Man、3Dlight は海外では既にクラウドレンダリングサービスの主幹レンダラとして活用されているほか、国内での活用頻度の高い V-Ray もクラウドでの利用が可能となっている（要問い合わせ）。なお、V-Ray は、数年前までは 3ds Max のみに対応していたが、V-Ray for Maya の登場もあり、より利用しやすくなっていると言える。
なお、CG ソフトをクラウドで利用することが許可されないのは、基本的にライセンス規約に基づくものである。例えば、オートデスク製品では、ライセンス付与の排除・許諾されない行為として、「ライセンシーが管理しているコンピュータ以外のコンピュータにライ
センス対象マテリアルをインストールすることができるライセンス」と「ワイド エリア ネットワーク（WAN）、仮想プライベート ネットワーク（VPN）、仮想化、ウェブ ホスティ
ング、タイム シェアリング、サービス ビューロー、サービスとしてのソフトウェア、ク
ラウド サービス、クラウド技術又はその他のサービス若しくは技術に関連しての使用を含
め、インターネットその他の非ローカル ネットワークでのオートデスク マテリアルのインストール若しくはアクセス又はかかるインストール若しくはアクセスを許容するライセ
ンス」が取り上げられており、仮想環境での使用はこの利用許諾に抵触する。
表 4.29

クラウドでのライセンスに関して調査結果

3DCG ソフト

レンダラ

利用可

RenderMan
3Dlight
V-Ray
mental ray

利用不可

Autodesk Maya
Autodesk 3ds Max
Autodesk Softimege
Houdini131(2)ジョブ管理システムの調査

ジョブ管理システムの代表的なシステムとその特徴について調査を行なった。

(a)

Qube

対応 OS：Windows/Linux/Mac OSX
対応アプリケーション：Maya、Softimage、3dsMax
主な特徴：

Maya、XSI、3dsMax など主要アプリケーションに対して、ジョブタイプと呼ばれる専用の UI と、ジョブがファームで実行される際の専用のバックエンドが提供される。



上記により、ジョブ投入の際にフレームレンジをあらかじめ分割するのではなく、フレー
ム単位での効率的な処理が可能になる。



各ジョブにプライオリティを指定して投入できる（投入後の変更も可能）。



チャートで容易にレンダリングファームの運用の分析が行える。iPad/iPhone により外部からのモニタリングも可能。

(b)

Deadline

対応 OS：Windows（XP、Vista、7、Windows Server 2003/2008）、Max OS X（10.5/10.6/10.7）、
Linux（Red Hat、Fedora、CentOS、SuSE、OpenSuSE、Debian、Ubuntu）
対応アプリケーション：Maya、Softimage、3dsMax、Houdini、Cinema4D、Nuke、Toxik、
Vue、RealFlow（前述アプリケーションのスクリプト言語で作成されたカスタム GUI が付
属）
主な特徴：


統合化された Monitor UI を実装



ジョブの優先度を数値で表し、マシン群をグループとして管理、グループ単位でアクセス制限を設け、ジョブ単位でマシンのアクセス管理機能などで柔軟なジョブ割り当てが可能。



管理機能を使用する権限はユーザーの設定するパスワードにより保護される。

オプションで遠隔エラー報告が受けられる（レンダリングのエラーや一般的なアプリケー
ションにおける問題は Thinkbox Software 社に直接送信され、Thinkbox Software 社のスタッフが送信された情報からフィードバックが受けられる）。



ジョブを Monitor UI から Deadline のジョブ監視ツールにドラッグ&ドロップすることで自動に更新される進捗情報を確認することができる。特定したジョブの進捗を Monitor UI
から更新させることなく追跡可能。

132

(c)

Backburner

対応 OS：Windows（XP、Vista、7、Windows Server 2003/2008）、Max OS X（10.5/10.6/10.7）
対応アプリケーション：Maya、Softimage、3dsMax、Houdini、Cinema4D、Nuke、Toxik、
Vue、RealFlow
主な特長：

Autodesk 製品に概ね無償バンドル。



日本語 GUI を提供。



ブロードキャスト通信により最小限のシステム構築が非常に簡便。

Python など、特別なサブシステムは不要。



レンダリングに必要なデータ一式を各計算ノードに転送して処理するため、ファイルサー
バアクセス障害による計算ミスが起こらない（3ds Max のみ）。



管理ノードは各計算ノードの処理状況に応じダイナミックに計算対象フレームを割り当てる。これによりシーン展開のオーバーヘッドを最小限にし、効率的な計算を実現している（3ds Max のみ）。



汎用コマンドインターフェイス（cmdjob.exe）により、コマンドラインのインターフェイスを持つアプリケーションへ柔軟に対応できる。



レンダリングジョブに対する計算マシンの割当が柔軟。

(3)

ネットワーク高速化技術の分析(a) ネットワーク高速化技術の必要性
現在のインターネットの光回線は 100 Mbps のサービスが広く普及しつつある。加えて
近年ではより高速なサービスも手に入りやすくなっており、各 CG プロダクションでは、200 MB/sec や 1 GB/sec といったより高速な回線の導入も進んでいる。通信速度が飛躍的に伸びている背景としては、プロダクションがより大量のデータ授受を行う必要性が生じていることが理由として挙げられる。現状各社では、高速な回線を利用し、一般業務用のインターネット通信に加え、自社で保有する FTP サーバ等を使用して大量のデータ授受を行っている。
これに加え、社外にあるクラウドレンダリングシステムを活用する場合、より大量のデータ転送が発生することとなるが、専用の回線を増強するとなると追加のコストが掛かる。
回線を共用した場合、一般業務用の帯域の低下につながることにもなる。こうした問題を解決するためには、より効率の良いデータ転送を模索する必要がある。

133

(b)

クラウドレンダリングサービスに必要なネットワーク帯域

クラウド上でレンダリングを行う場合、まず、その構成素材となるデータ群が、各レンダリングノードから参照可能な位置にアップロードされ、計算の終わった映像データがダウンロードされることとなる。
クラウドレンダリングを行う場合、これらのデータはインターネットを経由して大量に送受信されるため、プロダクション側で必要なインターネットの帯域を予め想定しておく必要がある。

(c)

レンダリング素材のファイルサイズ傾向

レンダリングを行うためのデータサイズはクオリティや解像度等で大きく変動するため、具体的な数字を出すことは難しいが、一般的な 3DCG 処理と、素材となるファイルサイズの関係は、概ね以下の通りとなる。
表 4.30

一般般的な 3DCG 処理と、素材となるファイルサイズの関係

処理の内容

素材の総容量構成ファイル数生成されるデータ

流体計算や爆発等のシミュレーション

少ない

少ない

大量の計算データ

キャラクターアニメ等のレンダリング処理

中程度

中程度

映像データ

CG 合成等の VFX 処理

多い

多い

映像データ

最も大量にデータを必要とするのは、数多くの映像データを合成する CGI・VFX 処理である。制作される内容によって総量は大きく変動するが、10 秒の映像を制作するために、数十 GB の映像データが必要になるケースも想定される。
一般的なキャラクタや背景といった 3DCG のレンダリングに関しては、元データとなる
素材の量はそれほど多くなることはない。事前に行った制作プロダクションのヒアリング
内容を分析したところ、ある工程の作業で使用するファイル総量は現状では多くとも 100
MB 以内には収まる傾向にあり、複雑なカットでも 1 GB を超えるケースは稀である。
流体や爆発等のシミュレーション処理に関しては、更に軽量のデータから計算が行われる傾向がある。しかし、シミュレーション結果のデータは、元データに比して莫大な量となる。その大きさは、計算規模と精度によって大きく変動するが、比較的小規模なシミュ
レーションでも 1 フレーム当たりのファイルサイズが 1 GB に達するケースは珍しくない。
映像のレンダリングは解像度に応じたほぼ一定のデータ量が生成されるのとは対照的である。映像データをレンダリングした場合、ハイビジョン画質の物でも 1 フレームで 10 MB
を超えることは考えにくく、両者の計算結果の傾向の違いが表れていると言える。

134

(d)

光回線を使用したデータ転送速度

比較的一般的な 100 Mbps の回線を利用した場合、理論上どの程度のファイルの転送が可能かを表 4.30 に示す。
表 4.31

100 Mbps の光回線を使用した際の、理論上最大のデータ転送速度

転送ファイルサイズ

秒数

換算時間

1 GB

81.92 秒

約 1 分半

4.7 GB(DVD)385 秒

約 6 分半

25 GB(blu-ray)2048 秒

約 34 分

100 GB

8192 秒

約 2 時間 16 分

1000 GB

81920 秒

約 22 時間 45 分
※100 Mbps = 12.5 MB/sec

以上のように、100 Mbps のネットワーク帯域を完全に利用できた場合、理論的には 1TBのデータが約 1 日で転送可能である。1 TB というデータサイズは、プロダクションの制作
規模にもよるが、1 日で生産されるデータとしては過分な量であるため、遠隔地とのデータ同期を行うのに十分な速度であると言える。
また、この光回線を使い 100 MB 程度のレンダリング素材をクラウド環境に投入する場
合でも、約 10 秒程度で転送が完了するため、比較的高速なレスポンスが確保出来る。
しかし、映像データを合成する CGI・VFX 処理をクラウド上で行おうとする場合、元となる素材を送受信するためには、100 Gbps の回線では、負担が大きいことが予想される。
この場合、1 Gbps 級の回線を利用することで改善が図れる可能性もある。それでも十分なレスポンスが得られない場合は、プロダクションとクラウド間でのデータの同期を毎回行
わずに、クラウド上のデータを元に作業を行うようなワークフローを採用する可能性が生
じる。

(e)

実際のインターネット通信速度

前項では 100 Mbps というネットワーク速度を理論限界まで使用した場合のデータ転送量を想定したが、実際にインターネットでのファイル転送を行った場合、下記のような様々な要因からその帯域を 100%使い切ることは困難である。
①

回線の品質や、共有による帯域の圧迫②

ネットワーク上の通信経路による遅れ③

ファイル転送プロトコルや、暗号化通信のためのオーバーヘッド

135①と②に関しては、ネットワークの物理的な制約から来る問題である。
①に関しては、より良質なサービスを選択することで解決され、②に関しては、ネットワーク的に近い地域間で通信を行うことで解決される。
対して、③はソフトウェアな問題である。一般的には、シンプルな構造のプロトコルを採用すればデータの転送効率は上がり、セキュリティ等を重視し、強度の高い暗号化を施した場合、トータルとしてのデータ転送量は低下することとなる。

(f)

ファイル転送プロトコル

インターネットでのファイル転送に関しては様々なプロトコルが存在する。
この中でも、歴史が古く一般的なプロトコルとしては FTP が挙げられる。しかし FTP は、
認証情報等を暗号化せずに送受信するため、ネットワーク上で通信が傍受され、パスワー
ド等が漏洩する可能性がある。そのため、認証の暗号化に対応した FTPS や、SSH を利用した SFTP への移行が進んでいる。
セキュリティ上の問題は抱えつつも、FTP を使用してデータを授受するプロダクション
は比較的多い。
最近では中小企業向けの NAS に FTP の機能が標準搭載された製品も多く、自社の専用サーバを持たずとも手軽に運用が可能である点も上げられる。
FTP は TCP ベースのプロトコルとしては、非常に転送効率が良い。しかし、遠隔地とのデータ授受に関しては速度の低下が大きくなる。これは FTP に限らず TCP でのデータ通信全般に言えることで、他の TCP ベースのデータ転送プロトコルでも同様の問題が発生する。

(g)

TCP によるファイル転送の特徴

ネットワークを経由したファイル転送は、一般的に TCP を用いて行われてきた。
TCP によるデータ通信の特徴としては、下記のような点が上げられる。


データ転送の順序が保証されている



パケットが失われた際に再送される



誤り検出

しかしこういった特徴は、データが遠隔地に存在していたり、通信環境の安定していな
い地域からアクセスしようとしたりする場合、サーバからの応答に時間がかかってしまい、
高速にファイル転送が行えないという問題が発生する。これは特に海外とのデータ送受信
で顕著に表れるが、国内でもインターネットの基幹線が入り組んだ地域とのデータ通信は双方の拠点の回線速度が高速でも、十分なパフォーマンスが得られないケースもある。これを解決するため、ネットワーク遅延の影響を抑え、TCP ではなく UDP を使用すること
で高速にファイル転送方式を行う方式がある。
136

(h)

UDP によるファイル転送の特徴

現状、UDP によるデータ通信は、映像データのインターネットストリーミング放送や、
VoIP 等で多く利用されている。UDP によって送信されるパケットは、到達順序やデータの完全性をプロトコルとしては保証しないため、UDP を使用したファイル転送ソリューショ
ンでは、アプリケーション独自の実装で処理を行う必要がある。その代わりとして、TCP
特有の制約に縛られる必要が無くなるため、サーバからの応答を待つこと無くパケットを並列で送信することが可能となる。その際、パケット単位の暗号化に関しても独自の実装
で行っており、セキュリティに関しても配慮がされている。こうしてサーバ側は到達したパケットを順不同で取り込み、ファイルの全ての構成要素が揃った時点で、ファイルの復元を行い転送が完了する。以上のような方法でファイル転送の高速化を実現している。

(4)

クラウドレンダリングサービス事業調査(a)

クラウドレンダリング

前述した通り、国内ではクラウドレンダリングサービスは存在しないが、海外ではいく
つかのサービスが展開されている。3D ソフトウェアのクラウドでの使用は日本と同じく海外でも NG となり、レンダラでのパイプラインが敷かれている。つまり 3GCG シーンをレ
ンダラのシーンに置き換えてレンダリングが実行される。そうした中で 3DCG ソフトから
クラウドレンダリングまでのパイプラインをうまく繋げたサービスも出現した。その例として、ZYNC 並びに本サービスを活用した Atomic Fiction の事例を報告する。

①

Atomic Fiction

図 4.7

Atomic Fiction（http://atomicfiction.com/）137

THE FOUNDRY の JAPAN TOUR で紹介された Atomic Fiction が、クラウドを全面的に活用して作品を手がけていたことが分かった。

②

クラウドの活用の理由

ハリウッドの作品でも、制作時期の波があり、また常に最新機材を導入し続けることの負担が大きくなってきた。また、スタッフの雇用についてもスケーラブルに拡大、縮小する必要も高くなってきた。特に、夏は制作が終わるタイミングが重なるので、新たな仕事が始まるまでに設備を固定費として維持することのデメリットをクラウドで回避していた。
コアメンバーは、20 人程度で、2 本ほど同時進行する作品はカバーしており、4 本に増えた際には、場所を借りて拡張し、50～60 人体制で仕事をするスタイルをとっている。また仕事が完了すれば、その拡張したスタジオは閉鎖して、コアメンバーだけになるという仕組みである。拡張したスタジオは VPN で接続しているが、計算についてはクラウドで行うので、トラフィックも少なくて済む。拡張したスタジオ分の作業マシンは、Atomic Fictionの機材で運用とのこと。
Maya と Nuke のチームが、クラウドでレンダリングを行っており、3ds Max のチームは社内にあるマシンで計算を行なっているという。3ds Max が活用される場合は、エフェク
ト効果の仕事が多くなるようで、シミュレーションなどのキャッシュデータも大きくなる
ので、うまく使い分けられている。
クラウドサービスとしては、ZYNC を活用しており、ZYNC 自体はクラウドの設備を持
つのではなく、クラウド管理とライセンス管理、そして使用した料金の管理を行っている。
ZYNC が提供しているものは、以下 2 点。


クラウドの管理ツール



アプリケーション毎のクラウドレンダリングの為のソフトウェア

Nuke の例では、作業しているカット単位でクラウドのストレージにデータを同期しながらアップしてあり、レンダリングをしたい時にすぐにレンダリングを実行できる環境を整えている。Atomic Fiction 側も無駄にデータを同期しないように、同期するフォルダを明確にしており、通信量を必要最低限にするように管理している。
また、Nuke については、プラグインをなるべく使わないようにしており、クラウド利用をより確実に行え、また金額も大きくならないように工夫している。時間単価で比較すると、ローカルに持った方がコストを削減できるが、利用した分だけ料金を支払うことで全体としては、コスト削減に繋がっている。
アーティストはある程度のコスト管理を行っているが、クラウドで管理することで使っている金額が明確になる。管理側は、一元管理することでコストがオーバーしないように
アーティストと連携をとっている。
138

③

ZYNC

図 4.8

ZYNC（http://zyncrender.com/）

対応 3D アプリケーション：Maya、3ds Max、Softimage、Cinema 4D
対応 2D アプリケーション：Nuke、After Effects、Smoke for Mac、Fusion
対応レンダラ：V-Ray、mental ray、RenderMan、Arnold
上記のようなアプリケーションに対応するが、Maya などそのままシーンで投げるのではなく、前述した「アプリケーション毎のクラウドレンダリングの為のソフトウェア」を用いてレンダーシーンへとコンバートされる。

4.3.4 実証実験
実際にクラウド環境を想定した実環境を作り、実際に運用できるのか、どんな問題が発生するのか、実際のサービス運営に必要な課題は何か等について、プロダクションが利用することを前提として、以下の実証実験を実施した。


ジョブ管理システムのクラウド環境での運用性

レンダリング実証並びに実マシンと仮想マシンの比較



転送実験

139

(1)

実証実験環境実証実験環境の概要は以下の通り。

図 4.9

(a)

実証実験システム機材概要

設置機材

デジタルハリウッド大学 レンダリングサーバ x3650M2 2 台(物理マシン用、仮想マシン用
CPU：Xeon L5520 2.26GHz×2

8Core

Mem

：48 GBHDD：C ドライブ146 GB（RAID1）：F ドライブ

1TB（RAID5）NIC：1 Gbps×2

物理マシン OS：Windows 7 Enterprise SP1 64 bit Build 7601

仮想マシン

：VMware ESXi Ver. 5.1.0

ゲスト OS：Windows 7 Enterprise SP1 64bit Build 7601

CPU リソース：1/2 ソケット、1～16 コアまで調整可能

Mem リソース：1 GB～48 GB まで調整可能

HDD リソース：C ドライブ 200 GB をアサイン

レンダリング：Maya2013 64bit mental ray 使用

140

(b)

設置機材

ヘッドノード（1 台）
IBM System x3650 M2 （M/T:7947-42J ）CPU:

Xeon L5520 2.26 GHz (4Core) ×2

Memory:4 GB DDR3 1066 MHz ×6

HDD:

300 GB SAS 10K RPM ×8

C ドライブ: 300 GB （2 玉 RAID1 構成）
D ドライブ: 1.8 TB （6 玉 RAID0 構成）(c)

計算ノード（20 台）

IBM Systems x iDataPlex dx360 M2 （M/T:7323-22X ）CPU:

Xeon X5550 2.66 GHz (4Core) ×2

Memory:4 GB DDR3 1066 MHz ×8

HDD:

300 GB SAS 10K RPM ×2

C ドライブ: 300 GB （2 玉 RAID1 構成）
全てのノードに 0S として Windows Server 2008 R2 Standard（評価版）を導入
設置場所：日本 IBM 幕張(2)

ジョブ管理システムの実証

3DCG 制作のレンダリング工程において広く使われているレンダリング管理ソフトとして、オートデスクの Backburner のクラウドにおける動作を検証した。

図 4.10本実証実験で用いたデータのレンダリング画像（左）、IBM 幕張〜デジタルハリウッ
ド間でのレンダリングモニター状況。tighvnc にて監視を行なった（右）

141

(a)

懸案事項

レンダリング管理ソフトが制御する各マシン間の通信は遠隔拠点に跨るため、LAN と比較すると以下の差異が生じる。
① 拠点間の通信は遅延が大きい② 拠点間の通信は暗号化される（VPN）③ サブネットを超えた通信が必須

(b)

検証環境

(ⅰ) 拠点

管理サーバの所在地：御茶ノ水（東京都）



計算ノード、ファイルサーバの所在地：幕張（千葉県）



クライアント：都内(ⅱ) ソフトウェア
Autodesk Backburner 2013（管理サーバ、計算ノード、クライアントに設置）



Autodesk Maya 2013（計算ノードに設置）



Autodesk 3ds Max 2013（計算ノードに設置）（ⅲ） 検証フロー①

クライアントより、レンダリングに必要なユーザーデータをファイルサーバへ転送。

②

クライアントより、管理サーバの Backburner へレンダリングジョブを投入。

③ Backburner により、計算ノードにて Maya、3ds Max によるレンダリングが実行されることを目視確認。
(ⅳ) 検証結果
懸案事項①（拠点間の通信は遅延が大きい）：本事業の検証環境で確認された程度の遅延
は、Backburner の動作に影響を認められず。レンダリングに必要なユーザーデータの送信
は遅延、帯域の影響を受ける。よって CIFS プロトコル等、LAN 上で用いられる一般的なファイル転送は実用的でない。この問題は事前に予測できたため、別途高速ファイル転送
ソフトウェア（Aspera、Skeed）の実用性を検証し、問題を解決。
懸案事項②（拠点間の通信は暗号化される（VPN））：LAN 上の通信と遜色なく、問題点は認められず。
懸案事項③（サブネットを超えた通信が必須）：Backburner による管理サーバ、計算ノード、クライアント間の通信及び各サブネットとの通信を確立するため、以下の設定が必要。
Backburner の通信モードをユニキャストに設定変更（既定はブロードキャスト）。

142



管理サーバに静的なルーティング設定を追加（複数のネットワークインターフェイスで各
サブネットと通信するため）。

(3)

レンダリング実証

(a)

実験概要

仮想環境でのレンダリングが行なえるかを実証。また、実マシンと仮想マシンでレンダリングを実行した際の速度の面での比較検証を行なった。VMware ESXi 5.1 上に Windows
7 64bit クライアント OS をインストールし、全く構成が同じ Windows 7 64bit クライアン
ト OS を導入したサーバとの比較を行い、結果は下記のとおりである。
【検証用レンダリングサーバ】
デジタルハリウッド大学 レンダリングサーバ x3650M2 2 台(物理マシン用、仮想マシン用
CPU：Xeon L5520 2.26GHz×2

8Core

Mem

：48 GBHDD：C ドライブ146 GB（RAID1）：F ドライブ

1 TB（RAID5）NIC：1 Gbps×2

物理マシン OS：Windows 7 Enterprise SP1 64bit Build 7601

仮想マシン

：VMware ESXi Ver. 5.1.0

ゲスト OS：Windows 7 Enterprise SP1 64bit Build 7601

CPU リソース：1/2 ソケット、1～16 コアまで調整可能

Mem リソース：1 GB～48 GB まで調整可能

HDD リソース：C ドライブ 200 GB をアサイン

レンダリング：Maya2013 64bit mental ray 使用【テストデータ】
3d Render.com 社提供 Maya プロジェクトファイル
出力形式 ：png
解像度：256×256

使用メモリ量：360 MB（仮想マシンのメモリ量のリソース変動に影響を与えないレベル）

レンダリング時間：i7-3930K(3.2 GHz 6Core、HT on)にて 120 秒でレンダリング完了(参考)143図 4.11

物理マシン、仮想マシンでのレンダリング時間の比較(3 回平均値)

結果 1：全検証ケースにおいてアプリケ－ション、OS の致命的なエラーは無かった。
結果 2：レンダリング時間の短縮効果は物理マシン、仮想マシン共に確認できた。
結果 3：Intel Hyper Threading によるレンダリング処理用スレッド増加は実コア数以上の処理能力向上は確認できなかった。
結果 4：仮想マシンでのレンダリングにおいて演算時間の異常値が出現した。
上記レンダリング解像度を 256×256 ピクセルからレンダリング解像度のみ 4096×4096 ピク
セル(ピクセル数 256 倍)に拡大したレンダリング検証も行った。結果は下記表の通りである。
表 4.32
レンダリングマトリクス

4K×4K レンダリング時の処理時間比較（秒）
1 回目

2 回目

3 回目

平均

基準マシン(8Core/16 スレッド)

30179.45

29978.79

30108.14

30088.79

i7-3930k(6Core/6 スレッド)

10296.00

10760.45

10585.76

10547.40

結果 1：両ケース共に正常に 4K×4K 解像度のレンダリングが行えた。
結果 2：最新 CPU でも 3 時間弱のレンダリング時間がかかっており、4K 映像のフル 3DCG
映像制作は 30 秒 CM レベルが現時点での商用受注の限界と思われる。
144

表 4.33 物理マシン、仮想マシンのレンダリング比較の実測表（秒）レンダリングマトリクス

基準マシン(物理)検証マシン(VMware)

メモリ量

1 core2 core4 core8core

16 core(1Way)(2Way)(2Way)(2Way)(2Way)

48 GB

1277.27688.75368.03250.70203.4248 GB

1407.64914.05548.96233.14234.544 GB

1397.94734.52369.81233.31235.04

2 GB

1393.55

737.89556.85233.56238.791 GB

1423.89741.05378.42245.56255.37

注 1) 3 回実施平均を取る
注 2) Windows7 推奨最低メモリは 1 GB(検証では 768 MB でもレンダリングは実行出来ている)
1 回目
レンダリングマトリクス

基準マシン(物理)検証マシン(VMware)

メモリ量

1 core2 core4 core8core

16 core(1Way)(2Way)(2Way)(2Way)(2Way)

48 GB

1293.98685.61356.04234.18203.7948 GB

1413.08

752.90929.53253.59253.524 GB

1427.48756.99388.97260.07254.16

2 GB

1400.19759.04927.14260.45257.17

1 GB

1450.87755.25393.27260.07274.10

2 回目
レンダリングマトリクス

基準マシン(物理)検証マシン(VMware)

メモリ量

1 core2 core4 core8core

16 core(1Way)(2Way)(2Way)(2Way)(2Way)

48 GB

1270.14710.68368.69262.71202.5848 GB

1420.05

720.57349.22221.44225.22

4 GB

1388.48712.81362.46219.24227.702 GB1380.85716.63365.21221.19231.201 GB1384.92

724.58369.65241.46252.38

3 回目
レンダリングマトリクス

基準マシン(物理)検証マシン(VMware)

メモリ量

1 core2 core4 core8core

16 core(1Way)(2Way)(2Way)(2Way)(2Way)

48 GB

1267.68

669.97379.35255.22203.8948 GB

1389.80

1268.69368.12224.40224.87

4 GB

1377.85733.75358.01220.63223.252 GB

1399.60

738.01378.19219.04228.001 GB

1435.87743.33372.33235.15239.63

145

(b)

検証結果

物理サーバと仮想 OS サーバでの CPU(コア数)変動による性能差にほぼ差は無く、仮想OS マシンも物理サーバと同様の演算ポテンシャルを持っていることを示唆している。ただし、VMware 上では原因不明の大幅な演算遅延(物理サーバの 2 倍以上)が検証内で 3 件発生した。仮想 OS でのレンダリングの実用化にはレンダリング時間大幅遅延の現象を再現し、原因究明及び解消する必要がある。

(4)

転送実験

(a)

実験概要

クラウドサービスを受ける際にはクラウド上へのデータ転送が必ず行われる。そうした転送速度による検討を行うため、デジタルハリウッドのサーバに対し、複数のプロダクション
から転送実験を行なった。なお、転送には追加コストなど投入することのない現実的な手段として一般的な FTP 転送に加え、UDP によるファイル転送として Aspera と Skeed の 3 つの方法で実験を試みた。

図 4.12

シーケンス画像146

使用回線： 下り：1000 Mbps speedtest.net

下り：302.8 Mbps

上り：1000 Mbps

上り：109.1 Mbps
表 4.34単 品 容ファ イル
量数

1 Gbps

総容量 Aspera

ダウンロードSkeed

FTP:FileZilla FTP:FFFTP 理論上限

25 分 42 秒、 59 分 37 秒、 62 分 32 秒、 セッション切
4K/24P ムービー

66.7 GB 1

66.7 GB 354.4 Mbps

152.8 Mbps

145.6 Mbps

断のため計 546.4 秒（9 分 6 秒）
測できず

1080/24P ムービー 16.6 GB 1

16.6 GB

720/24P ムービー

7.4 GB

7.4 GB 1

05 分 51 秒、 15 分 46 秒、 13 分 42 秒、 14 分 20 秒、387.2 Mbps

144.0 Mbps

166.4 Mbps

102.4 Mbps

02 分 58 秒、 07 分 36 秒、 06 分 37 秒、 06 分 47 秒、
340.8 Mbps

132.0 Mbps

152.8 Mbps

148.8 Mbps

136.6 秒（2 分 15 秒）
60.4 秒（1 分）

29 分 33 秒、 セ ッ シ ョ ン 切 31 分 07 秒、 124 分 26
4K 24fps シーケンス 47.4 MB 1440

1080/24P シー ケ ン
ス

66.7 GB 308.0 Mbps

断 の た め 計 292.8 Mbps

秒 、 73.6 546.4 秒（9 分 6 秒）

測できず

Mbps

07 分 46 秒、 セ ッ シ ョ ン 切 08 分 18 秒、 セッション切
11.8 MB 1440

16.6 GB 292.0 Mbps

断 の た め 計 272.8 Mbps

断のため計 136.6 秒（2 分 15 秒）

測できず

測できず

03 分 24 秒、 セ ッ シ ョ ン 切 04 分 05 秒、
720/24P シーケンス 5.27 MB 1440

7.4 GB 296.8 Mbps

断 の た め 計 247.2 Mbps
測できず

表 4.35

1 Gbps

16 分 26 秒、
61.6 Mbps

60.4 秒（1 分）

アップロード単 品 容ファ イル
総容量 Aspera
量

Skeed

FTP:FileZilla FTP:FFFTP 理論上限数24 分 54 秒、 30 分 33 秒、 27 分 47 秒、 27 分 16 秒、4K/24P ムービー

66.7 GB 1

66.7 GB

546.4 秒（9 分 6 秒）
365.6 Mbps

282.4 Mbps

328.0 Mbps

334.4 Mbps

06 分 20 秒、 08 分 22 秒、 23 分 23 秒、 07 分 03 秒、1080/24P ムービー 16.6 GB 1

16.6 GB

136.6 秒（2 分 15 秒）
357.6 Mbps

154.4 Mbps

96.8 Mbps

321.6 Mbps

02 分 41 秒、 03 分 40 秒、 09 分 59 秒、 03 分 07 秒、
720/24P ムービー

7.4 GB 1

7.4 GB

60.4 秒（1 分）
376.8 Mbps

240.8 Mbps

100.8 Mbps

324.0 Mbps

24 分 54 秒、 30 分 36 秒、 12 分 28 秒、 59 分 57 秒、4K 24fps シーケンス 47.4 MB 1440

66.7 GB

546.4 秒（9 分 6 秒）
365.6 Mbps

1080/24P シー ケ ン

297.6 Mbps

730.0 Mbps

152.0 Mbps

06 分 20 秒、 08 分 02 秒、 03 分 15 秒、 17 分 09 秒、
11.8 MB 1440

16.6 GBス

136.6 秒（2 分 15 秒）
357.6 Mbps

282.4 Mbps

697.6 Mbps

132.0 Mbps

02 分 58 秒、 04 分 12 秒、 01 分 35 秒、 08 分 05 秒、
720/24P シーケンス 5.27 MB 1440

7.4 GB

60.4 秒（1 分）
340.8 Mbps

240.8 Mbps

147638.4 Mbps

124.8 Mbps

(b)転送実験結果ベストエフォートの光回線を使用したため、計測結果にはばらつきがみられた。
また UDP によるファイル転送に関しては、プロダクションに設置されたファイヤーウォー
ルの影響も受けたため、検証先からのアクセスが途中で中断される、著しく速度が低下す
るなどの影響も出た。そのため、比較的安定したデータ転送を行えたファイヤーウォール（UTM）を介していない部分のデータを掲載した。
調査対象としたクライアントが都内にあり高速回線を利用していたため、TCP による転送と UDP による転送で明確な差異は現れなかった。専用線を用いることで、より安定したデータ転送が出来ることも予想されるが、速度については、一般的なインターネット回線を用いても十分な転送速度を得られると言える。条件によっては旧来の FTP による通信の方が高速な転送結果を得られるケースもあったが、特に海外とのデータ転送では、経路上にボトルネックが存在し、速度が低下することが予想される。
調査を行ったプロダクションの一つはアジア地域に支社をもち、国内のスタジオとのデータのやり取りのため 2012 年に Aspera を導入している。この事例では、一般回線ではデータ転送に多大な時間がかかっていたが、UDP によるデータ転送によって大幅にその問題が改善された。

4.3.5 クラウドレンダリングの課題のまとめ
本調査並びに実験を通じて、クラウドレンダリングを実現するためにはソフトウェア・
プラグインのライセンスの問題を解消する必要がある。そのため、以下でレンダリングにおける 3DCG データのフローを考慮した上で、解決方法について検討する。

148

総合環境
3dsMaxMaya
Softimage他

レンダリング専用環境（スタンドアロン）

3DCGソフト
ネイティブ
データ

コンバータ
プラグイン

プラグイン

ＯＢＪ
プラグイン

mental Ray
RenderMan
V-Ray
他

レンダラ

図 4.13

3DCG データの流れの例

上図は 3DCG データの流れを示した概略図である。自社内でレンダリングする場合は、統合環境で 3DCG ソフト及び付属するレンダラ（図の赤枠部分）によって作業することとなる。具体的には 3DCG ソフトで制作されたネイティブデータを、ソフトに付属するレンダラによってレンダリングする。一方、レンダリングを外部の環境で行う場合は、単体で動作するレンダラ（スタンドアロン）によってレンダリングする。その際、3DCG のネイ
ティブデータは使用できないため、スタンドアロンのレンダラのシーンへコンバートする必要がある。一般的には 3DCG のネイティブデータからレンダラシーンへの変換はある程度スムーズに行うことができる。ただし、現実的には静止データが最も効率的であり、アニメーションデータやリグ、シミュレーションを用いた変化するデータ及び独自ツールを用いたデータなどはコンバートの効率が落ちる。また、映像制作の場合、コンバート時にはフレーム単位で出力するためデータ量が肥大化するという問題がある。
上記のような流れを踏まえ、現在は 3DCG ソフト及びそれに付属するレンダラとプラグ
インはクラウド環境での使用が認められていない一方、スタンドアロンのレンダラでは利用が可能ということから、実現の可能性を考えると以下の 4 つの方向性が示される。
(1) 3DCG ソフト、プラグインのクラウド環境での使用許諾を得る(2) 人の手を介するコンバート作業をもったサービス(3) シーン変換の自動化（コンバータの作成）
149

(4) ユーザーによる既存の環境に沿った運用(1)

3DCG ソフト、プラグインのクラウド環境での使用許諾を得る

最も有効な方法として、クラウド用のライセンスがメーカーより提供されることである。
なお、クラウド用ライセンスの提供先には、ユーザーとサービス事業者の 2 つが考えられるが、クラウドでの環境でシステム・ライセンスが整備された状態でユーザーが使用することが本調査による仮説でも有効であると考えられ、サービス事業者に対して提供されるようになることが望ましい。

(2)

人の手を介するコンバート作業をもったサービス前提としては、既存のライセンスにのっとった形でのサービス（クラウド上ではレンダ
ラのみを動かす）に、3DCG ソフト・プラグインで作成されたデータを人の手によって変換して乗せる。レンダラシーンに変換するサービスの構築、あるいはユーザー側で変換を行った上での利用となる。ただし、人件費がかかる上、変換には多大な時間を要するため、結果的にレンダリングコストの増大に繋がり効果的な利用とは言えない。

(3)

シーン変換の自動化（コンバータの作成）(2)と同じく前提としては、既存のライセンスにのっとった形でのサービス（クラウド上
ではレンダラのみを動かす）での運用だが、人の手を介さずに自動化する。それには 3DCG
データのみならず、プラグインで作成されたデータなど全てを変換するコンバータの開発が必要となる。各ソフト・プラグインメーカーの協力も必須な上、開発には時間を要する。
なお、こうした形でサービスを提供しているのが、ZYNC であるが、現在のところ全てのソフト・プラグインを網羅しているわけではない。

(4)

ユーザーによる既存の環境に沿った運用

既存のライセンスにのっとった形でのサービス（クラウド上ではレンダラのみを動かす）をそのまま運用する。それにはまず素材の出し方やデータの作成方法などのルール化並びにパイプラインの整備が必要となる。また、前述の通り、アニメーションデータやリグ、
シミュレーションデータは変換しにくいため、利用するのは静止データ（あるいはそれに類似したデータ）のみとなる。本来アニメーションデータやリグ、シミュレーションデー
タなど負荷のかかるシーンを外部でレンダリングすることがユーザーにとってのメリットとなるため、クラウドレンダリングの必要性には反する。

150

4.4 考察4.4.1 調査と分析結果の考察(1)

国内 3DCG 制作の歴史的展開

国内でのクラウドレンダリングは 1990 年代前期頃に黎明を迎えた。それ以前は SGI
Origin/Onix/Octain など、高額 Unix 機材での 3DCG 制作が中心となり 3DCG 制作自体も高額投資事業であったため、国内でも限られたプロジェクトメンバーしか制作に関わることが出来なかった。例えば、1985 年のつくば万博にて披露された『ザ・ユニバース』は、当時の技術の粋を結集して制作されたが、スタッフは少数のトップメンバーに限られていた。
このような高額機材向けに販売されていた 3DCG 制作ソフトウェアも同様に高額であり、第 3 者転用が出来ないよう、利用条件許諾にソフトウェアを運用する場所を事業所から一定距離以内に限るなどの制限も存在していた。この制限もあり、ごく少数の大手事業者のみが事業所を跨いでレンダリングシステムを遠隔からネットワークで操作していた。この時期はまだデータセンター事業者が認知されておらず、事業所外に業務機材を配置し、ネットワーク接続によって運用することが想定されていなかった。これがクラウドレンダリ
ング技術進展の阻害要因の一部となっていた。
1990 年台後期以降、高額だった 3DCG 制作ソフトウェアの Unix から Linux/Windowsへの移植、PC 向け販売、及び低価格戦略を打ち出したオートデスクによって、中小企業レベルでの 3DCG 映像制作業務が可能となり、3DCG 市場の規模が急拡大した。市場規模拡大に貢献したのは PlayStation(1994 年発売)、Nintendo64(1996 年発売)、Dreamcast(1998
年発売)などの国産家庭用ゲーム機、及びアミューズメント業務機器(両方を総称して国産ゲーム機とする)の普及である。 国産ゲーム機が世界市場に広く展開するにつれて、国内の2D/3DCG 制作者は 30 万人規模に拡大し、アーティスト派遣業者、ゲーム開発請負企業も現れた。
その後も 3DCG の需要は家庭用ゲーム機の普及によって引き続き堅調に支えられ、加えて 2004 年頃からはアミューズメント機器のパチンコ、パチスロ向けコンテンツ需要も発生した。国内 5000 億円市場規模の家庭用ゲーム産業に加え、国内 20 兆円市場規模のパチン
コ、パチスロ市場が加わり、関連する市場規模は大幅に拡大した。
パチンコ、パチスロ産業向け 3DCG 映像制作業務を経営の柱の一つに位置付けた映像制
作プロダクションの中にはゲーム、アニメの受注と合わせて業績を堅調に伸ばし、数百名規模のアーティストを擁する企業にまで成長し、劇場版映像も制作する事例もある。一方
で、映像制作に向けた大規模な設備投資が行われることは少なく、フル 3DCG 劇場映画製
151

作において度々トラブルが発生することもある。具体的には 1 年規模の制作遅延や、制作
納期短縮の為の制作委託の分散化とそれに伴う制作物管理の問題である。
3DCG 映像は PC 単体での制作も可能ではあるが、長尺(24 分～120 分)、高解像度(劇場
向け 2K サイズ)の映像では、膨大な演算が必要となるため、大規模な設備投資が必要となる。例えば 2001 年に公開された世界初のフル 3DCG 映画『Final Fantasy』では、日本とハワイでの国際共同制作となり、制作費は 150 億円規模となった。その後、ハリウッドを中心とした映画での 3DCG シーン活用は活発になり、2001 年には北米興行成績トップ 10
作品の内、3DCG を活用した映画は 7 本にもなり、3DCG 映画は消費者や投資家に認知されていった。
北米では投資ファンドが中心となり世界配給を前提としたビジネスモデルを構築し、制
作費が 200 億円を超える作品も制作されている。このような大規模投資によって映画制作のための専用データセンターを設立し、数百～数千 CPU の大規模 3DCG レンダリングシ
ステムを北米内の各スタジオとネットワークで接続することで、レンダリングシステムや、映像や素材を管理するファイルシステムの共有化を行う事例もある。
国内で数百～数千 CPU 規模の設備を運用・管理している組織としては 2000 年代前半では独立行政法人などが中心であった。2006 年には、産業技術総合研究所が遠隔レンダリン
グサービスの試験提供を行っている。ただし、独立行政法人は運用規約により公共財の営
利目的利用制限されているため、大規模レンダリングサービスの本格的な商用提供は国内
産学官連携では未だ実現していない。
他の商用クラウドレンダリングサービスの例としては日本 IBM が 2008 年から運用開始
し、汎用 HPC システムをインターネット VPN 越しに提供している事例がある。レンダリ
ングサービスとしては 2013 年 2 月までに、試験提供も含めて映像制作会社に利用された実績が５件あった。このサービスはクラウドサービスとして先行運用開始されたが、運用される汎用 HPC システムは実演算システムそのものであり、仮想 OS を遠隔提供する IT 用語として定着したいわゆるクラウドとは違い、『インターネット VPN 経由のオフサイト
HPC システム運用』と表現するのが妥当なものであった。
2010 年代に入り、3DCG 映像はオンデマンドビデオ配信、演出が高度化する劇場映画、テレビ版アニメでの 3DCG の積極利用など、ニーズは更に高まっている。実際のフル 3DCG
映画制作においては、数百 CPU 規模の機材調達が必要となるが、十分な機材を保有しているプロダクションは少なく、レンタル機材(業者 1 社の在庫は数十台程度)での充当も間に合わないため、アジアを中心とした国外でレンダリング用機材を調達する事例が発生している。
近年、アジア諸国では中国、韓国、マレーシア等で映像制作センターが国策として設立され、一部では 100CPU を超える専用機材によるクラウドレンダリングサービスの海外提供を開始している。これらにはハリウッドも注目し、採用を検討している事例もある。
現在、国内では上述した問題に対する抜本的解決策は成されておらず、大幅な予算超過
152

や制作遅延による業績悪化となって映像制作会社の経営の負担となっている。今後 4K の映像が一般的になれば、コンテンツ制作業界の対応が困難となる。

(2)

CG・VFX 業界の現在おかれている状況

CG・VFX 業界ではパソコンやスマートフォンを含めたコンテンツ表示端末の普及の結果、紙、鉛筆で制作する業態から IT 設備を活用してデジタルで制作する業態に変化しつつある。
デジタル制作を主とする業態に変化したコンテンツ業界では、IT 設備投資型モデルに変
革しきれないまま制作受注を請け負う状況となり、財務が不安定になる事例がある。更に、コンテンツ業界ではフル 3DCG の映画やテレビ番組の普及、立体視対応コンテンツの普及が加速しており、コンテンツ制作会社に要求される制作量が急増している。このため、近年、大規模な制作遅延が発生し、制作遅延による経営が悪化するといった事例がしばしば発生している。
表 4.36

レンダリング時にワークステーションが生成するシーケンスファイルサイズ
1 フレームの24 fps で 1 分間のファイルサイズ（TIFF）

ファイルサイズ

1280×720 HD 720（16 bit 非圧縮）

55 MB

7.9 GB

1920×1080 HD 1080（16 bit 非圧縮）

12.5 MB

18 GB

4096×2160 4K HD（16 bit 非圧縮）

53.1 MB76.5 GB※ RGB 各 16 bit でアルファチャンネルは含まない

国内のコンテンツ制作は民間ファンドとしての役割を持つ製作委員会で資金調達を行うものが多いが、海外ファンドと比較し資金調達能力に乏しく、十分な設備投資を行えるだ
けの資金を獲得することが出来ない場合が多い。海外プロダクションとの IT インフラ設備
規模の差は、国内コンテンツの国際競争力低下に繋がりかねない。クラウドレンダリング
基盤があれば、それを活用して IT インフラを確保し、ない場合は制作資金のうち、適切な割合を高品質な 3DCG 映像を迅速に生成する為の IT インフラ投資に向ける必要がある。
クラウドレンダリング基盤は国内映像制作企業のコスト削減や高品質の映像制作に貢献するが、現時点では実用化されていない。本調査の結果、クラウドレンダリング基盤を民間企業が運用するには 1CPU 当たり毎時 200 円程度の利用料が必要とされるのに対し、映像制作企業は毎時 60 円程度に抑える必要があるなど、課題が多く残されている。

クラウドレンダリング基盤の実現に際して、個別のプロダクションでは経費負担が難し
い設備費、運営費を業界全体で効率化できるため、クラウドレンダリングサービスが成立
153

することが映像制作業界全体の底上げにつながる。また、映像制作に関わる小規模プロダ
クション、教育機関が大規模プロダクションと同等の制作環境を利用することが可能となる。
本調査では、各種高速データ転送ツールを用いてデータ転送テストを実施し、最高実効転送速度 700 Mbps を達成した。これは映像制作分野で大きな障害となっていた数百 MB～数 GB 程度の大容量データの転送を技術的にクリアするものだった。また、データ転送
ツールも機能強化がなされており、遠隔拠点のファイルサーバ同士を高速データ転送で非同期 Sync させる機能が追加され、本調査でもその機能が正常に動作することが確認された。
クラウドレンダリング基盤を効率する際に課題となる、遠隔拠点間のファイルシステムの統合は実現可能なことが、本調査で実証された。したがって、クラウド技術の適用によって複数のスタジオ間でレンダリングシステムを共有し、さらに拠点をまたがる高速回線
網上に仮想的なファイルシステムを構築することによって、迅速なデータの共有、映像制
作業務の効率化が可能になると考えられる。
映像制作の高品質化、高解像度化による処理量やストレージ容量の増加に対応するには、
現状ではハードウェアの増設以外に方法がないが、クラウドレンダリングサービスを活用
すれば、負荷が大きい時だけ柔軟にシステム構成を増やせるようになる。この場合、ユーザーの初期投資は定常状態の負荷に対応したシステム構成だけで済み、設備投資コストを従来以上に抑えることができる。さらに、定常状態のシステムはユーザーのローカル環境にあっても、データセンターに一括して設置されていても、問題なく活用できる。
ハードウェアの追加には通常セットアップに時間を要するが、クラウドシステムでは OSからアプリケーションのデプロイまで自動化がなされており、ユーザーはアーカイブからデプロイしたいシステムイメージを選択するだけで、数百台規模のシステムを 1 時間以内
でセットアップすることも可能となる。また、データセンターでは、入退館の管理も含めて情報管理が厳格になされる上、システムの状況が常時監視されるため、迅速なトラブル対応が可能となる。
このように、高速ネットワークを活用した大容量データ転送型のシステムサービスをク
ラウド技術と組み合わせて実現することで、企業の抱えている多くの問題に対して対応できる。事実、米国では、上記のようなクラウドレンダリングサービスが限定顧客向け、若しくは特定プロダクション間での提供が開始されている。

(3)

解決すべき問題に対する施策

レンダリングに必要な経費の増大等の CG・VFX 業界が抱える課題を解決するためには、
154

以下に例示するような方法で国内プロダクションが映像制作に活用できるクラウドレンダ
リングの基盤を整備していくことが有効である。

① 映像制作に関するインフラの共有化とその運用技術の整備
地域振興策と連携したクラウドレンダリング基盤の導入など、映像制作に関するインフラの共有化とその運用に必要な技術の整備を進める。
② 映像制作に向けたソフトウェアライセンス管理とその運用技術の整備
レンダラの遠隔利用については、本検証において正常動作することを確認できた。海外の事例ではクラウドレンダリングサービス向けソフトウェアライセンスの整備も進捗しているが、ビジネスモデルの構築と各事業者間の契約交渉が更に必要となる。
③ クラウドレンダリング基盤運用コスト適正化及び人材育成の推進
今後、クラウドレンダリング基盤をサービスとして自立する為に必要なコスト積算、ビ
ジネスモデルを精査すると共に、クラウドレンダリング基盤を運用・活用する人材の育成を進める。

クラウドレンダリング基盤【クラウドレンダリング基盤】

図 4.14 クラウドレンダリング基盤概略図(4)

IT 技術の現状と将来予測

IT 性能向上に向けたロードマップは各分野において企業及び作業部会が策定している。
レンダリングの演算を主に行う CPU については、民間企業が 2015 年以降までのロードマ
155

ップを発表している。
1997 年販売された Pentium 200 MHz はプロセスルール（半導体チップ上の回路の幅）が 350 nm、トランジスタ数は 550 万個だったのに対し、現在の Xeon E5 シリーズ（1CPU、8 Core 搭載）はプロセスルールが 32 nm、トランジスタ数は 22 億 7000 万個まで増加している。さらに、2015 年にはプロセスルールが 10～14 nm まで縮小され、実装可能なトラン
ジスタ数も引き続き増加して行くことが見込まれる。
表 4.37
コードネームPentiumIntel Xeon シリーズの歴史的変遷と将来ロードマップ

Drake

CascadesCascadesFosterPrestonia

Prestonia

NoconaIrwindaleクロック

200 MHz

400 MHz

550 MHz

1 GHz

2 GHz

2.8 GHz3.06 GHz

3.6 GHz

3.8G Hz

コア数

1

1

1

1

1

1

1

1

1

トランジスタ数

550 万

750 万

950 万

2810 万4200 万5500 万プロセスルール

350 nm

250 nm

250 nm

180 nm

180 nm

130 nm

90 nm

90 nm

90 nm

1997

1998

1999

2000

2001

2002

2003

2004

2005

Woodcrest

Harpertown

Harpertown

Gainestown

クロック

3.0 GHz

3.2 GHz

3.4 GHz3.33 GHz

3.33 GHz

3.47 GHz

3.1 GHz

2.8 GHz

コア数

2

2

2

4

6

6

8

10

2 億 9100 万 8 億 2000 万 8 億 2000 万 7 億 3100 万 11 億 7000 万 11 億 7000 万 22 億 7000 万

30 億以上40 億以上発売年

コードネームトランジスタ数

WestmereWestmere

1 億 900 万 1 億 2500 万 1 億 6900 万

Sandy-B

IVY Bridge

Haswell

プロセスルール

65 nm

45 nm

45 nm

45 nm

32 nm

32 nm

32 nm

22 nm

22 nm

発売年

2006

2007

2008

2009

2010

2011

2012

2013

2014

コードネームBroadwell

Skylake- Skymont---

トランジスタ数

40 億以上50 億以上100 億前後

プロセスルール

14 nm

14 nm

10 nm

7nm

5nm

5nm

発売年

2015

2016

2017

2018

2019

2020

クロック
コア数

また、元来グラフィックス表示補助パーツであったグラフィックボード（GPU）も、多数の演算コアを搭載可能となり、CUDA（OpenACC）、OpenCL 等の言語によって CPU を超える高速演算が可能になっている。これによって、グラフィックボードの汎用利用（GPGPU）も活用されつつある。
高性能 GPGPU ボードの一つである Tesla K20x は単精度浮動小数点演算用コア（CUDA
コア）を 2,688 個搭載している。Tesla K20x は CUDA コアを 192 コア内蔵した演算パッ156

ケージであるストリーミングマルチプロセッサ（SMX）を 14 基搭載している。さらに倍精度浮動小数点演算コアを 64 コア搭載している。Xeon が 1CPU で同時に演算ができるのが最大 16 スレッドなのに対して、Tesla K20x では内蔵されている SMX 単体でも理論上最大
2048 スレッドの演算実行が可能となっている。
このトレンドに対して、GPGPU に対抗する CPU と連携する演算ユニットも開発され、販売が開始されている。例えば、Intel Phi は 22nm プロセスルールで製造されており、60コアを演算ユニットとして内蔵している。
これらの CPU と専用演算機とのハイブリッドシステムは、今後、高速演算システムの一分野として発展していくと考えられるが、課題もある。
ハイブリッドシステムを実際のレンダリングに利用するには、プログラムを修正し、ア
プリケーションを最適化する必要がある。レンダリングの際はプラグインも同時にレンダ
リング時に実行される為、最適化されていないプラグインが実行されると、動作不良や大幅な演算遅延が発生する可能性がある。その為、実際にレンダリングに活用するには全プ
ラグインがハイブリッドシステムに対応する時期を待つか、特定のプロジェクトで利用する全てのプラグインをユーザーがチューニングする必要がある。
ただし、既にレンダリングにも活用が進められており、mental ray、iRay、 V-Ray、V-Ray
RT 等は既に GPGPU に対応している。
また、ハイブリッドシステムは価格も従来の CPU に比べ高価であるため、注意する必要がある。
今後のレンダリングシステムの構築を検討するためには、ハイブリッドシステムへのア
プリケーションの対応動向と価格の推移を注視していく必要がある。汎用的なレンダリン
グを行う場合、今後数年間は CPU を中心としてレンダリングを行い、要求される制作コン
テンツの内容と必要な演算性能を精査し、必要な演算リソースをクラウドサービスから調達するのが望ましい。このような利用に対応できる、高速データ転送とファイル同期ツー
ルを活用したオフサイト利用型のクラウドレンダリングシステムが将来の主だったクラウ
ドレンダリングサービスの構成になると考えられる。

(5)

調査のまとめ

近年、4K などの高精細映像の需要が増え、映像制作プロダクションにとって、演算処理量を増やす必要性が高まっている。例えば 4K 画像では、最新のハイエンド CPU を利用しても未だレンダリングに 1 時間以上の時間がかかっており、短縮には CPU、GPGPU、CPUと連携する専用演算機の性能向上を待つ必要がある。GPGPU 等のメニーコアテクノロジーの更なる普及が進めば、2016 年頃には 4K レンダリングの一般商用受注が可能な程度に性能が向上する可能性がある。
一方、ハードウェアの性能向上のほか、クラウドサービスを用いて利用するハードウェ
157

アの総量を拡張する方法も考えられ、実際に、北米では汎用クラウドサーバーを活用したクラウドレンダリングサービス事業者が現れている。このようなクラウドレンダリングの実際について動作検証も含めて確認するため、本調査において実証実験を行なった。
本調査で検証を行った物理サーバ及び VMware での仮想 OS サーバは 2009 年に一般的なデータセンターに大量導入された低消費電力汎用サーバと同じ CPU を搭載している。
物理サーバと仮想 OS サーバでの CPU（コア数）変動による性能差は無く、仮想 OS マ
シンも物理サーバと同様の演算が可能であることを示唆している。
2012 年発売のハイエンド CPU i7-3930K（6Core）搭載ワークステーションでのレンダ
リング時間約 120 秒に対して、検証サーバ の 1CPU（4Core）のレンダリング時間は約 370秒となり、Standard Performance Evaluation Corporation が公開する CPU 性能指標値の性能差、約 2.5 倍にほぼ比例した結果となった。現在、データセンターに納品されている
CPU は 2Way システムとして運用可能なものが一般的であるが、2Way 構成の場合、レンダリング性能は一般的なハイエンドの CPU より高速となる。例えば、E5-2630L 2Way 構
成サーバ 20 台をクラウドレンダリングシステムとして利用した場合、i7-3930K 搭載ワー
クステーション 34 台分の演算能力となる。これは運用、価格面において映像制作プロダク
ションにとって利用価値のあるものであり、クラウドサービス提供事業者にとっても自立して運営できる可能性があると言える。
国内プロダクションでは、制作納期確保の為に必要な数百台規模のワークステーション
を国内では全て調達できず、海外からも調達する事例がある。プロダクションにとって、このような事例に柔軟に対応できるクラウドレンダリングサービスの潜在的ニーズは高く、サービス提供事業者にとっても複数事業者と契約しても運用上必要となるサーバの台数は数百〜千台規模であり、現実的に運用可能な規模だと言える。

158

4.4.2 クラウドレンダリングサービスの仕様検討
プロダクションに対するアンケートや、ヒアリング結果などから、ユーザー（サービス利用者）から求められるクラウドレンダリングサービスの仕様についてまとめる。
まず「すぐに使える」という点が最も重要となる。計算ノード、スペックを含め、サービス自体のキャパシティに余裕があるということは当然として、クラウドを用いたレンダ
リングを行なう際に、設定などを都度行なうことなく、すぐにレンダリングを実行できるということが、利用者にとって重要となる。
それを可能にするために、事前にテストジョブを投げ、テスト環境を設定できる環境にしておく必要がある。主に契約形態によって解消できる事項だが、例えば期間での利用契約を結んだ上で月に数時間は自由にテストを行なえるなどが、利用者にとっては大きなメリットとなる。
また、各社のプロファイル情報を保存できようにすることで更に利便性が増す。ヘッド
ノードは契約期間借り切りにすることで、プロジェクトにあったテストを行なった上で、そのプロジェクトに適したプロファイルをヘッドノードに残しておくことが可能となる。
なお、こうしたシステム設定を行なう際、プロダクション側にシステムエンジニアがいな
い場合も多いため、サービス側がエンジニアを派遣できることが望ましい。
利用に当たっては、まずアーティストのユーザビリティが最も重要である。仮想マシン
へのアクセスが確保されれば、アーティストは実マシンと同様に使用できるが、ジョブ管
理ソフトなども既存のジョブ管理システムと同様に使えることが望ましい。また、管理については、エラーが発生した際の適切な対応がなされるかも重要である。
また、レンダリングの演算量も場合によって大きく変わるため、前述したヘッドノードを確保した上で、演算に割り当てる計算ノード、メモリなどを柔軟に調整できることが望ましい。また、セキュリティが確保されていることも必要である。ネットワーク上のセキ
ュリティに加え、使用後のデータの管理（削除）なども規約が明示されていることが望ましい。
課金形態については、細かい従量課金であることが最も望ましい。一日数時間の利用から対応できるような課金形態となっていることが、利用の促進にもつながる。テストやファイナルなど、レンダリングの目的によって利用時間が大きく変動するため、フレキシブ
ルな形態であることが重要である。レンダリングにかかる料金についても、明確にアカウ
ンティングできるような仕組みも必要となる。なお、料金に関しては、PC１台につき毎時
50〜100 円というのが概ねの要望であった。

159

4.4.3 経営者にむけて設備投資の提案
漫画、アニメ、映画、ゲームといったコンテンツ産業の制作業態は、紙や鉛筆を用いた手作業からコンピューターシステムを活用したデジタルの作業に変化し、コンテンツ表示
端末の多様化、高解像度化などに伴って、設備としての高速、かつ大規模なコンピュータが必要となる「設備投資事業」化している。今後、4K 化など更なる画質の高精度化が進む
ことでコンテンツ制作に求められるデジタル処理量は、更に増加していくと考えられる。
コンテンツ制作企業の経営者は、制作費を抑えると同時に、ある程度のコストをかけて競争力のある高品質なコンテンツを制作することが求められるという、相反する課題への対応を迫られている。加えて、コンテンツ制作におけるコンピュータ利用量については「ピーク性（例：コンテンツ制作時のレンダリング、エンコーディング処理など）」や「季節変動性（例：長尺映画制作『夏、冬公開映画』 に向けた制作処理など）」を持っており、これらに対応するためには常にピーク時を想定したコンピュータ資源を自社で保有せざるを得ないのが現状である。
このような状況下、海外では自社ではまったくコンピュータ資源を保有せず、レンダリ
ングに必要なコンピュータ資源は全てクラウド上のレンダリングサービスを利用するといった企業も出現している。そうした中でクラウドの活用がどのような効果を生み出し、どう運用するかについて提案する。

(1)

クラウド利用によるトータルコスト削減(a)

クラウドレンダリングサービスによるコストメリット

クラウドレンダリングサービスの利用により、以下のようなメリットが考えられる。
①

ピーク時を想定した設備投資コストの削減により、年間を通じた固定費を削減できる。

②

環境に制約されずに、プロジェクトに合わせてチームを構成できる。

③

設備の更新を行わなくても、最新設備が利用できる。

④

レンダリングに使用するハードウェアのメンテナンスが必要なくなる。

⑤

設備費を作品の直接費として整理できる。

特に、①については実際に当てはめて導入の効果を概算する必要がある。コストの算出に当たっては、ソフト、ハード、電源や場所等のインフラに分類できる。それぞれについて詳細に算出する必要はないが、概要を把握することが重要である。
ソフトウェアにかかるコストについては、保守があるものは 1 ヶ月単位で計算、保守が160

ないものは約 2 年でバージョンアップすることが多いため、24 ヶ月に分割して計算して見積もられる。ハードウェアにかかるコストは、チーム毎やスタジオ毎の割当台数に 1 台当たりの月額コストを乗じて算出する。なお、有償のディスパッチャーなどの利用によりレンダリングマシンを管理できるだけでなく、プロジェクト毎の結果を詳細に出力できる。
インフラについては、例えば電気使用料は、前期の合計を 12 ヶ月で割った上で、ファイル
サーバは定量とし、残りをレンダリングマシンの数で按分するなど、サーバの台数単位で大まかに算出すると良い。
このようにレンダリングに関わるコストを洗い出すことが重要である。現在、制作費としてレンダリングコストを見積もることは稀であるが、以上の結果から予測することでより精度の高い金額を算出でき、制作費として計上しやすくなる。
クラウドを効果的に活用するためには、計画的な利用が必要である。そのためには、まずクラウドを活用することを前提として、予算計画と人員計画を立てる必要がある。その中で、プロジェクト準備段階からクラウドサービスを利用することを想定し、クラウドに効率的に活用できるようなソフトウェア、ツール、データ管理方法を選定しておく必要がある。運用面では、アーティスト一人一人がクラウドとローカルのコスト特性の違いを正確に把握し、適切に活用する必要がある。また、プロジェクトを管理するスタッフが予算も一括して管理することも重要となる。ただしクラウドのレポート機能を利用することで、これらの業務の大半は自動化できる。

(2)

クラウドを活用による制作力の向上

北米の大手プロダクションのレンダリングリソースは、ローカルスタジオだけでもかな
り大きく、さらに電力の限界等から遠隔地も併用して活用している場合もある。しかし、そのようなプロダクションも開発段階から常に多くのリソースを使っている訳ではなく、複数の作品を抱え続けることでリソースを運用している。日本の場合、常に大規模な設備を持ち続けるのではなく、クラウドサービスを活用して必要な時だけリソースを拡張できるようにすることで、北米のプロダクションに対抗できる可能性がある。
大規模なレンダリングリソースを持つと、それを維持すること自体が大きな負担になる可能性が高く、逆に身動きが取りにくくなってしまう。また、日本のレンダリングリソー
スの使い方はプロジェクトの後半に集中する傾向にある。そうしたピークが複数重なった
場合にローカルではリソースが足りなくなり、結果的に作品のクオリティを下げる要因となる場合がある。一方、クラウドサービスを活用すれば、年間を通じてコストを削減することができるとともに、一時的なピークにも対処でき、作品のクオリティの維持も可能となる。
161

クラウドレンダリングを最大限に活用するには企画段階からクラウドの利用を想定する必要がある。一時的な大規模の演算処理にはクラウドで対応するように計画されていれば、演算処理の遅延が作業に影響を与えずに計画通り終了する可能性が高くなる。作業が遅延すると、その分だけ経費が増えるだけでなく、その先に進むプロジェクトにも影響を与えてしまう。その連鎖によって製作費が圧迫される事態を回避することが経営上重要である。
例えば、10 台のレンダリングマシンで 2 日かかる作業は、40 台であれば半日ですむ。これは、レンダリングの結果を見て修正の有無を判断するのに、これまで 2 日間の時間を要していた工程が、その日の内に次の作業への指針が決まるようになり、単純に演算にかかる時間を短縮できるほかに、作業の無駄の縮小による効率化も期待できる。このようなレンダリングリソースの最大利用により、以下の(a)～(c)のような効果が期待できる。

(a) 高解像度、高フレームレートへの対応
4K 放送の開始時期が明らかになるなど、高解像度映像の需要増加に伴い、レンダリング
時間がますます増加することが見込まれる。HD の解像度と比較して 4K は画素数が 4 倍ある。また、従来の毎秒 24 フレームだけでなく、48 フレーム、60 フレームという要求も出てきた場合にクラウドの計算力はとても有利になる。特に、1 秒当たりの枚数が増える場合
は、それぞれを分散して処理するのは比較的容易である。48 フレームならば 2 倍の台数を用意すれば、理論的には 24 フレームと同じ時間で計算できる。このように、クラウドを活用して台数を確保することで高解像度、高フレームレートの映像も迅速に制作できると考えられる。

(b) 遠隔地のアーティストとのコラボレーション
遠隔地のアーティストがプロジェクトに参加する際に、スタジオのローカル環境と同等の環境を準備することは難しい。そこで、クラウドを活用してレンダリング環境を遠隔地のアーティストと共用することで、プロジェクトに柔軟性が高まる。

(c) 重要化するシミュレーションへの対応
実写撮影や表現が難しい水、爆発、破壊などはシミュレーションの利用が進んでいる。
シミュレーションは計算で動きを導き出すため、計算力に依存する部分が大きい。シミュ
レーションソフトは、多くのリソースが必要なだけでなく、利用するコンピュータの台数分だけ、ライセンスが必要になる。ライセンスを多数維持するのは過大なコストとなるため、一般のプロダクションが個別に利用するのは難しく、結果としてシミュレーションを活用できる人材が限られることとなる。シミュレーションは、トライ＆エラーの経験によ162

るノウハウが作業効率に大きく影響するため、専門人材の確保が問題となる。
これらの問題に対してクラウドを活用することで、ライセンスの維持費を負担せずに十分なリソースの確保でき、一般のプロダクションでもシミュレーションに特化した人材を育成できる。
なお、シミュレーションの場合は容量の大きなファイルが生成されるため、クラウドとの連携には転送にも注意する必要がある。
クラウドを活用したレンダリングは、多くのメリットを得られ、映像産業の高度化に有効なインフラとなるが、運用開始には課題も多い。そのような問題は、制作者側とメーカーなどの相互協力によって解決していく必要がある。

協力
オートデスク株式会社
レンダリングの実証実験に使用するための Autodesk Maya 2013、Autodesk 3ds Max 2013、mental ray、Backburnerのライセンス提供並びに実証実験期間内に限定した特別使用許可をいただいた。

株式会社ネットマークス
ファイル転送実験に使用するための Aspera ソフトウェア運用の提案並びに設定にご協力いただいた。

3dRender.com
レンダリングの実証実験に使用する Maya、3ds Max のシーンデータの使用を許可いただいた。

谷 雅彦／Industorial Light & Magic
転送実験に使用するシーケンスファイル並びにムービーファイルの提供。

163

第5章
5.1

海外動向調査調査の目的

本章では海外の CG・VFX 会社の現状を調査し、日本との違いを明らかにすることを目的としている。特に、経営に関わる部分としてスタッフの契約状況や給与体系や、他のプ
ロダクションとの関係などを調査する。またシステムに係る部分として、開発環境やパイ
プライン、クラウドを活用したレンダリングシステムなどについて調査する。その他、政府の支援体制や人材育成、海外と日本の映像制作環境の違いなどについても調査を行った。
具体的には、米国（ロサンゼルス・サンフランシスコ）・カナダ（バンクーバー）の CG・
VFX プロダクション 10 社と関係 4 団体について、また欧州（英国・仏国）の CG・VFX
プロダクション 10 社と関係 4 団体についての調査を行い、その結果を取りまとめた。
なお、以下に記載する内容は調査の際に得られた情報を記したものであり、調査対象者の主観が含まれている可能性がある。
米国・カナダの調査では、三上浩司副委員長と事務局の秋山貴彦、須藤智明の 3 名に加え、通訳兼アテンドをロサンゼルスやカナダのトロントの CG プロダクションでの勤務経験があり、映画「はやぶさ 遥かなる帰還」ではカナダの VFX プロダクションと日本の映画会社のコーディネーターを務めた溝口稔和氏（バンクーバービジュアルアソシエイツ
代表）に依頼した。欧州の調査では、パリの CG プロダクションと共同制作の実績があり
欧州の動向に詳しい近藤左千子氏（株式会社 pH スタジオ 代表）と事務局の秋山貴彦、須藤智明の 3 名に加え、通訳兼アテンドをパリ在住のアニメーションプロデューサーで、仏国や英国の CG プロダクションでの勤務経験がある Erika Forzy 氏に依頼した。

164

5.2

米国・カナダ動向調査
表 5.1

月日

曜日

米国・カナダ動向調査

場所

訪問先

訪問者

DreamWorks AnimationSKG
New Deal Studios

12 月 5 日 水

12 月 6 日 木

12 月 7 日 金

12 月 11 日 火

12 月 12 日 水

有馬真作氏ほかDavid Sanger(Head of Production)
Ron Fischer(Technical Director,
Production Services)
Universal Studios（Virtual
Rami Rank(Production Services
ロサン Stage 見学）
Representative, Universal Studios
ゼルス
Operations Group)
Rhythm & Hues Studios
Sei Nakashima(Art Director)（R&H）
Todd Davidovich(Director ofOperations)
Method Studios
Jeff Werner(Manager of Digital Studio)
Olivier Ozoux(Director of Technology)
Industrial Light & Magic
Dennis Cooper(Director, Global（ILM）
External Production)
サンフ
Yusei Uesugi(Senior Digital Matte
ランシ
Artist)スコ Industrial Light & Magic
Akira Orikasa(Digital Artist)
Masahiko Tani(Digital Artist)
Digital Domain

12 月 10 日 月

主な訪問先

Jason Dowdeswell(Head of Production)
Francois Latremoille(VFX Supervisor /Creative Director)
Ryo Sakaguchi

Exile VFX

Digital Domain
British Columbia FILM andバンク
Richard Brownsey(President & CEO)
Media
ーバー
Jimmy Ockey(Recruting Coordinator)
Image Engine
Yuta Shimizu(Lighting lead)
Curtis Staples(Partner)
Digital FILM Central
James Tocher(President)
Sam Trounce(DI Producer)
USC Institute for Creative Paul Debevec(ACM SIGGRAPH Vice
Technologies
President)
ロサン
Ken Maruyama(Vice President,
Sony Pictures Imageworks
Recruiting Academic Relations)
ゼルス
Walt Disney Animation
Hidehiro Hirase(Senior Development
Studios
Software Engineer)165

5.2.1 米国の CG・VFX プロダクションに対する調査(1)

DreamWorks Animation SKG

1994 年にジェフリー・カッツェンバーグ、スティーヴン・スピルバーグ、デヴィッド・
ゲフィンの 3 名によって DreamWorks SKG が設立された。
DreamWorks は 1995 年に PDI（Pacific Data Images）と共同制作契約を結び、CG を使った長編映画を手掛けるようにな っ た 。 2000 年 に は 、 定 期 的 に 長 編 ア ニ メ 映 画 を 制 作 す る た め に 新 部 門 と し てDreamWorks Animation SKG が設立され、2001 年の『シュレック』は史上初のアカデミ
ー賞長編アニメ映画賞を受賞している。
Q:スタッフの人数はPDI とあわせて 2000 人以上。ここの場所だけで 1300 人以上いる。開発スタッフも 100
人以上はいる（PDI は除く）
。Intel と提携してヘルプできている場合もある。ソフトウェ
ア開発も含まれている。アーティストでもツールを開発する者もいる。
R&D 部門はある。R&D 部門はアニメーションテクノロジーと呼んでいる。市販のツールも使っているが、自社でもツールを開発している。レンダラは自社ツール。
Q:社外との連絡方法はどのように行っているのか
VFX プロダクション間での契約はほぼない。インドのテクニカラーの会社には、同じパイプラインを利用している。モデリングについては 25%程度をインドに渡している。
インドとはコミュニケーションは困らない。香港もやりやすい。
データの受け渡しはするが、社外のプロダクションとパイプラインを共有することはな
い。
Q:スタッフの契約形態・給与体系はどのようになっているのか
社員は少ない。期間単位であったり、プロジェクト単位であったり。アーティストはア
ニメーションユニオンのベネフィットになる。PDI の場合は PDI/DREAMWORKS のベネフィット。
保障された時給制でほぼ残業はない。話の変更があるようなプロジェクトの場合は残業があるケースもある。週に 40～50 時間。40 時間以上はオーバータイムで 1．5 倍になる。
自社でコントロールができるのでスケジューリングは楽なのではないか。
平均時給はユニオンの WEB サイトに掲載されている。朝食とランチは無料。残業時には夕食も出る。
はじめの 2 週間くらいはホテルを借りてくれる。

166

Q:海外のプロダクションと取引があるかテレビの仕事は海外に発注することはある。特に中国は力を入れている。
例えば中国は市場を狙っているという部分がある。中国の場合は外国映画本数の規制があって共同制作だとそれからはずれる。将来的にはローカライズした映像を作ることもできる。中国と Coproduction すると入って来る収入が違う。デメリットとしては技術流出の問題がある。
Q:日本のプロダクションに対してどう思っているのか
日本に進出できない理由として社長から下記の意見を聞いた。


言語と就労環境と DREAMWORKS の映画があまりヒットしていないため。



インドや中国に比較して経済的なメリットがないため。

Q:日本のプロダクションが海外のプロダクションから受注するために必要な要件はどういったものがあるのか
テレビシリーズであれば日本の VFX プロダクションに発注されている。営業力やコネも重要。英語のできるアーティストも重要。
ブラーのようにショートムービーを作成して YOUTUBE 等にアップしてはどうか。
リモートでログインして作業ができる。ライティングなどを自宅にいながらできるようになるかもしれない。それが進むとどこにいても仕事ができるようになるのではないか。
ハリウッドで仕事をしているとスペシャリストが多いので、日本のようにジェネラリストが必要とされる職場では働きにくい。
Q:政府の支援体制はどのようなものがあるのか一部の州では政府の支援がある。Sony Pictures Imageworks はニューメキシコの支援があるということでスタジオを作ったことがある。
インドの会社では、実質上は Dream Works の仕事をしている。
Q:周辺で協力している教育機関や企業との関係はUSC とは協力している。その他いくつかの教育機関と講演やトレーニング等で協力している。古くなったコンピュータを寄付したりしている。アウトリーチといって卒業した人
材を対象にインターンのように受け入れる制度がある。開発環境は HP や Intel と協力している。HP とはタイアップもしている。
Q:パイプラインシステムについて利用している。オーバーザヘッジの制作の際の 2003～2004 年くらいに導入している。
PDI が開発したシステムを利用している。
167

Q:パイプラインシステムのメリット、デメリットについて
人を変更したときに対応ができる。ちょっと変わった事をしようとすると面倒。パイプ
ラインのメンテナンスが専門の人材でないとできないようになっている。アーティストの
やりたい事が制限されることもある。
Q:クラウドレンダリングシステムについて利用している。基本的には利用しないが、忙しいときには利用する。GPU レンダリングはまだやっていない。
ラスベガスやニューメキシコのレンダリングサーバを利用する。利用する場合はアーテ
ィストが選択できる。
Q:クラウドレンダリングシステムのメリット、デメリットについて
やはりレンダリングサーバは遅い。また途中で落ちてしまうこともある。背景 1 枚のレ
イヤーでレンダリング時間は 3～10 時間。長いものだと 1 レイヤーで 24 時間以上かかることもある。
Q:CG・VFX 関連の人材育成についてどのような取り組みを行っているのか
1 ヶ月間のトレーニングがあった。パイプラインが特殊なためトレーニングの必要がある。
教育用の部署もある。新しいツールの教育などもしてくれる。そうしたビデオも見ることができる。絵の授業などや業界関係者による講演などもある。
Linux の基本からパイプラインのトレーニングまであった。

(2)

New Deal Studios

1995 年に設立、2000 年に New Deal Studio を開設、2005 年にデジタル部門をスタートした。マーティン・スコセッシ監督や ILM との関係が強く、Aviator をはじめ大作のミニチュア制作を多数手掛けている。一般的な VFX プロダクションではなく特殊なプロダクシ
ョンであるため他のプロダクションとは多少異なる観点でヒアリングした。
Q:スタッフの形態・プロダクション規模はプロダクションのスタッフはプロジェクト制で変動する。5 人程度しかいない時もあれば100 名を超えるようなチームになるときもある。
ミニチュア制作においては実際のミニチュアを制作する場合と 3DCG モデルで制作する場合がある。どちらかでなくてはならないという考えは持っていない。合成などのデジタ
ル処理も含めて、過去のプロジェクトでは、20 台の PC を使って 200 ショットというのが最も大きいプロジェクト，
168

Q:使用しているソフトウェアについて
基本的にはツールは Maya とコンパチブルなソフトウェアを利用しており、カスタムメ
イドのソフトウェアやレンダラは利用していない。3DCG のモデル制作では Maya や
3dsMax、
さらには Rhino なども利用する。合成には Maya、
Nuke、レンダラは mental ray、
RenderMan を利用する。
Q:パイプラインやマネジメントについて
全社的に統一したシステムのようなものは特にない。これまでにも Project trucker、
Filemaker、Excel、Scene Cronize、Movie Magic など様々なものをプロジェクトごとに採用してきた経緯がある。また、デジタル部門では Web ベースの管理システムをカスタムメ
イドして利用している。
管理の方法としてはアーティスト個人ではなく、Shot cordinator が基本的に管理している。タスクリストを作ってそれをトラックしながら政策を管理している。
Q:レンダリングについて
小規模なレンダーファームを社内で有しており、ほとんどのケースで社内のシステムで賄うことができている。現時点では特別な仕組みが必要にはなっていない。
Q:人材について
プロダクションで働くスタッフに関しては、基本的にジェネラリストが求められている。

(3)

Rhythm & Hues Studios（R&H）

1987 年に設立された米国の VFX 制作会社。1995 年の『ベイブ』でアカデミー視覚効果賞を受賞した。2012 年に台湾の高雄市に新たに VFX センターを新設することを正式に発表している。高雄市の VFX センターでは、R&H 主導による人材育成&トレーニングが行われる。約 200 人規模の台湾人アーティストの雇用が見込まれ、ここでハリウッド映画のVFX 制作を行う予定とされている。
Q:社外との連絡方法はどのように行っているのか。
海外の自社外のプロダクションとの取引は無い。一部、モーションキャプチャーやプリ
ビズやインフェルノなどについてはアウトソーシングしている。
現場からは、ほとんど直接連絡を取らない。マネージメントチーム（プロダクションチーム）の人間が連絡を取る。シネシンク（ラストサムライのときに開発）というツールを使っている。

169

Q:スタッフの契約形態・給与体系はどのようになっているのか
プロジェクトに参加しているときは、社員と同等の扱いをされる。有給休暇が無いだけで、保険等もある。期間限定ではあるが、ほとんど社員と同等の契約となっている。
時給 15～20 ドルスタート、インターミディエートで 50 ドル、スーパーバイザーで 100
ドルなど時給に幅がある。時給は、入社の際にマネジメントの人間と交渉して決める。ス
キルが時給につながる。テクニカル系は時給が高いが、アーティストはここのところ時給が下がっている。時給平均は 40～45 ドルくらいではないか。
Q:日本のプロダクションが海外のプロダクションから受注するために必要な要件はどういったものがあるのか。
ほとんどのハリウッドの CG・VFX プロダクションは、日本の CG・VFX プロダクショ
ンに対しては、何も思っていないのではないかと思う。日本の VFX プロダクションが良く陥る間違いだが、VFX プロダクションから仕事の発注が来ることはあまり無い。VFX の仕事は映画会社の VFX スーパーバイザーから仕事をもらわないといけない。
Q:政府の支援体制はどのようなものがあるのか
TAX インセンティブは米国国内にもある。50 州のうち 7 州がライブアクションに対する制度がある。ライブアクションがある場合、VFX の支援の制度があるところもある。
Q:周辺で協力している教育機関や企業との関係はインターンシップは夏休み（新学期前）にやることが多い。USC などから学生が来る。
成績が優秀な学生に限って受け入れる。インターンシップに参加したからといって就職できるとは限らないが有利にはなる。大学等の研究機関との付き合いはあるが、ネットワー
ク系のシステム関連を除くと、テクノロジー関連の企業とのつきあいはあまりない。
Q:CG・VFX 関連の人材育成についてどのような取り組みを行っているのか
タイムカードの使い方など、会社としてのルールを教えることはするが、CG・VFX の教育はしない。ただし必要に応じてツールの教育をする部署はある。
ハリウッドの会社は人材育成のためのカリキュラムはほとんど無い。基本的にスキルア
ップは自己責任。
Q:ジェネラリストがどのように進化しているのか。
規模が大きなプロジェクトではジェネラリストでは通用しない。スペシャリストが中心
となる。

170

Q:海外と日本の映像制作環境の違いについて
例えばハリウッドでは時給の概念が強く、アプライされた人間しか残業はできない。自主的に残業をしていても見つかると怒られてしまう。一方、ロンドンのプロダクションは残業代が無いといっている。テレビから映像産業が発達した日本とロンドンと、映画から映像産業が発達したハリウッドの違いがあるのかもしれない。
Q:レンダーファームのロケーションについてR&H では、台湾でレンダーファームを立ち上げ、それによって、コストを下げつつも、早いスピードでのレンダリングを行っている。これは、台湾という国が官民一体（政府、コンピューター会社、電力会社等）となって、Visual Effect 業界への進出に力を入れる為に、R&H へアプローチを働きかけた結果によるものである。安く、大量のハードウェアを持っているが、その使い道が分からないという台湾と、ハリウッド大手 VFX 会社、R&Hのソフトウェア面での技術供給が合体してできたものとなる。
現在、R&H の世界中にある全支社が今、台湾にあるこのサーバーシステムを利用している。クラウドサービスまではまだ行っていないが、開発準備中である。
Q:サーバについてレンダリングのジョブを送る際に時間が掛かるため、基本はミラーサーバーデータを使用している。データベースでアセットを管理し、一連の動作が台湾で行われている。
データの行き来は、超高速回線を利用しているため台湾～米国間のほうが、米国～カナダ間より早い。これも、台湾が官民一体で取り組んでいるため、普通であれば利用が難し
いネットワークを提供してもらっていることによるものである。
しかし、データの行き来は効率の問題でもある。技術だけの問題ではなく、会社の中でのポリティカルな問題、無駄な作業を省くことによって解決できる。また、ローカルでのサーバも性能を良くしておくことが重要である。
インドにある支社との仕事の場合も、台湾のサーバが出来る以前は、インド支社はローカルサーバーを使用していた。これは時差を上手く利用し効率よくできていた。
クラウドにはローカルの何十倍もレンダリングリソースがある。しかし、作業過程で、どの形で進むのかという、試行錯誤の段階ではローカルを使用し、この方法で進む、と決定した時にクラウドを使用する、というように、ローカルとクラウドを上手く使い分けると効率よく作業が進む。
台湾にあるデータサーバーは Linux で動いている。R&H は、ほぼ Linux、Linux 以外
は Mac である。

171

Q:パイプラインについて
R&H はマルチスレッド・プロセッサ、あるいはシングルスレッド・プロセッサでレンダ
リングを行う。R&H は CPU も GPU も同じように使える自社ソフトを持っている。
コマーシャル部門は映画部門と全く別のパイプライン、Maya だけで完結、というものも使用している。というのも、コマーシャルは人数も少なく、スケジュールもタイトなため、スタートアップに時間が掛かる映画のパイプラインを使用したくはない為。
だが、将来的には、大きな CPU を要する、30 人程の小さなプロダクションでも、クラウドを使った大きなパイプラインを使えるようにするのが理想である。
日本で複数の会社が一つのプロジェクトに取りかかる際、社外間で共有できる一つのパイプラインがあると理想なのだが、という質問に対し、テクニカルパイプラインをコントロールするグループをそれぞれの会社に別個に作る必要性がある、との回答。
Q:ライセンス獲得について
Mantra Rendering License は Houdini を購入すれば無料でコア数分のライセンスが獲得できる。
Houdini ライセンスの使用数を抑えるために、出来るだけ多くのタスクのレンダリングに一つの Houdini ライセンスを使用するようにしている。ライセンスをいかに効率良く獲得するか、また、どのライセンスが空いているのかを含めて、使用する優先順位を決める
管理体制が重要である。だが、願うところは、ライセンス獲得がもっとフレキシブルになってくれるのが一番である。
Q:これからの台湾のレンダーファームの動き
現在は、R&H のみのサーバーシステムであるが、将来的には、データセンターをカスタ
マイズして、一般に使ってもらえるようにしようとしている。パイプラインはお客様の会
社独自のものを使えるようにカスタマイズしていこうとしている。この大きなデータセン
ターを通して、それぞれの小さな会社が自分たちのソフトウェアも使えるようにする。
台湾としてはハリウッドとのコネクションを作り、ノウハウを得た後に、R&H 以外の人たちにも使ってもらいビジネス化するという動きである。
また、ハード面はできたが、ソフト面での需要がなかったので、R&H にプロダクションを作ってもらい、R&H に台湾の若手を人材育成してもらう。
これは日本の、土地の安い地方でも出来たことではないだろうか。
日本でのアウトソーシングには、TAX インセンティブや助成などの制度もなく、コストが掛かり、能力はあるが、高いという固定観念を持たれている。

172

Q:R&H の日本進出の可能性について
R&H は海外展開が速かった。社風として世界中から人を集めるという考え方がある。
以前社長に日本展開の提案を持ちかけたことがある。そのときは物価が高いと言われた。
雇用状況や給料体系や物価を調査して去年再度提案をした。時間効率として見た時に日本人の効率が高いことをアピールした。R&H では、日本人のエフェクトアーティストが 10人以上いる。結果としては、政府の援助がないところには行かないという話しになった。
ブラジルや中国からもオファーを出されているが、それは政府からのオファーである。
新潟の学校と話をしたが、地方であれば可能性はあるという話を聞いた。立地についても、都内や関東でなくても、熱心に誘致してくれる自治体と話をしたい。
単価という切り口ではなく、クリエイティビティという切り口も考えられる。R&H が関与することによって、日本のコンテンツを世界に通用するようにすることができるのではないかと考えている。
会社の経緯としてナムコと関係があったこともあり、社長は日本に対し好意的。
会社としては名前だけ使われて終わりということを一番恐れている。そのため民間レベ
ルでは難しい。
日本の現場の制作の仕方が良いと思っている人は日本には多いと思っている。そうした
日本の制作手法に慣れている人を海外の制作手法に変えることは難しいと思っている。それよりも、将来性のある若い人を教育するのが良いのではないかと考えている。
習慣を変えるためには、よほどの事がないとできない。そのためには海外の企業が日本側に出て行くということもあるのではないか。それによって、労働環境も含めて、海外の企業の働き方が波及できるのではないかと思う。
トップの企業を持ってくることで、パイプラインもソフトウェアも人材もついてくる。
今現在 R&H が進出しているのは全て英語圏。言語の問題はあると思うが、画を作れる人
材が多ければ、言語の問題はサポートできるのではないかと思う。
カナダやインドの現地人材は、憧れの仕事に就けたということで、非常に熱心に取り組んでくれている。
カナダのオファーは、2 年くらい考えたが、台湾のオファーに関しては条件が非常に良かったので、2 つ返事であった。長い期間の保障が欲しい。台湾としては切り口がクラウドシ
ステムであったりコンテンツのファンディングであったりというオファーであった。
米国で活躍している VFX アーティストで、日本で働きたいという人は多い。そうした人が戻れる受け皿があっても良い。ただし現状では、労働環境の問題もあってなかなか帰ることができない。例えばスーパーバイザーとして、そうした米国で活躍したアーティスト
173

を雇用して、日本の若手を教育してもらうということも考えられる。最初の 1 社ができれば、他の会社も展開を考えるのではないか。
R&H は家族経営の会社。従業員が自国に展開をしてもらいたいという提案を受け入れてくれる社長がいる。利益重視でない部分があって、そのため海外展開が上手くいっている。
R&H ではアーティストが中心と考えているので、マネジメントはあまり待遇が良くない。
勤務体系は基本的にフレックス。日本ではマネジメントやビジネスサイドの人材が非常に弱いという話もあるが、世界配給を考えた際に、そうした人材が必要になる。
R&H では日本の規模のバジェットではできない。ただし一緒に企画を考えることで日本発の世界向けの映画が作れる可能性がある。日本のアニメーションプロダクションと共同で出資するということも考えている。それによって日本の仕事も共同で受けられるようになる。
日本のためになる方向で関与できたらと考えている。単に雇用が生まれるだけでなく、産業が世界で競争するための基盤ができればと考えている。
重要な時は、日本でこうした話をしたいと考えている。ここ 1 年が勝負だと思っている。

(4)

Method Studio

Method Studio は 98 年に 20~30 人規模でサンタモニカにスタジオを構えるところから始まった。その後、いくつかのプロダクションと合併し成長していった。現在はポストプ
ロダクション会社の Deluxe が親会社であり、Method Studio は VFX 部門のブランドである。
現在、本社であるサンタモニカスタジオには約 200 人が働いている。
他にもバンクーバー、ニューヨーク、アトランタ、シカゴ、ロンドン、シドニーにスタジオを構えており、これら全てのスタジオでは総計 1000 人近くのアーティストが働いている。
提供するサービスは各スタジオによって異なり、米国の各スタジオでは CM 制作、ロスアンゼルス、ニューヨーク、バンクーバー、ロンドン、シドニーでは劇場公開映画向けのVFX サービスを提供している。
Q：本拠に 1000 人規模の大きなスタジオを構えるのではなく、世界各地に中規模のスタジ
オを点在させている理由は？
Method Studio は世界各地にスタジオを構えているが、その理由としてまず不動産物件の観点から 1000 人を収容できるオフィスを確保するのが難しいため。
また人材確保の面から誰もが LA に住みたいと思っているわけではない。既に子供などが174いるアーティストの場合は出来れば仕事による転居などをせずに、住み慣れた街で働きた
いという人も多い。米国の主要都市にスタジオを構えることによりこういった優秀なロー
カルの人材を雇いやすいという点がある。
もう一つのポイントとして各地域のスタジオはそれぞれセールスの機能をもたせており、地元の仕事を受注する際に地元に密着した営業ができるという点がある。
さらに各地域の税制優遇措置を利用することをクライアントに求められた場合に税制優遇を有する都市にスタジオを構えていると、仕事が受注しやすいという面もある。
例えばニューヨークの税制優遇を利用したい場合、ニューヨークで撮影され、ポスプロ
もニューヨークで行われなければならない。
それら地域の税制優遇制度を利用する際に、主要都市に登記されたスタジオを所有しているというのは大きなアドバンテージとなる。
LA で作業するには採算が合わないようなプロジェクトの場合は税制優遇の利用できる
バンクーバーで作業をすることもある。
Q：大きな仕事を受けた際にはスタジオ間でどのように作業を分担するのか？
ケースによって異なるが、スタジオ間でシークエンスごとに分担している。簡単なマッチムーブは外注することもある。マットペインティングに関してはスペシャリストのいる
ロンドンの Method Studio に発注することが多い。しかしながら大概の作業はロサンゼル
スで終えることが可能となっている。
Q：同じ作品を他社とショットを分け合うときにどのようにデータの共有をしているのか？
モデル、テクスチャまで、リグなどは共有することはない。
Q：トレーニングについて
特別なトレーニングプログラムはなく、ある程度経験のある人を雇う。
経験の浅いアーティストにはオン・ザ・ジョブトレーニングを行っている。
Q：R&D について
サンタモニカスタジオでは 10 人ほどの人間が働いている。
Q：日本にスタジオを構えようと思うか？
今までに何人かの優秀な日本のアーティストと働いてきたことがあるので彼らには能力があるのは知っている。ただ今まで日本にスタジオを構えようと考えたことは無かった。
一つのスタジオが複数のロケーションにスタジオを構えるには主に二つの理由がある。
175

一つは先に話したように、そのエリアのローカルは広告や VFX の仕事を受注すること。
もう一つは Rhythm & Hues がインドに構えたように、かなり低いコストで才能のあるタレントを雇えること。
東京の場合はインドや中国のようにオフィスの家賃や人件費が安いというわけではない。
また英語を母国語としないのでコミュニケーションの問題もでてくると思う。
LA の本社よりディレクターからの指示があるので、言葉を含めたコミュニケーションの問題が重要になると思う。
Q：ソフト

パイプラインについて

基本的には Maya, Houdini, Nuke など業界水準のソフトを使用している。それに合わせていくつかのインハウスのプログラムを使っている。パイプラインは自社で開発したもの
で常に進化させている。
プロダクションマネージメントには Shotgun を使っている。
プロジェクトのスケジュールに関しては「ザイテック・スケジューリング」 「FileMaker」
を、雇用計画や事業予測などに関してはエクセルスプレッドシートを使っている。
クラウドレンダリングは使っておらずインターナル・レンダ―ファームで対応している。
Q：使用しているレンダラについて
サンタモニカ：V-Ray、Mantra
バンクーバー：mental ray、Mantraなどスタジオによって使い分けている。

(5)

ILM

ILM はジョージ・ルーカスが創設した現在最も権威ある VFX プロダクションの一つであり、スターウォーズ・シリーズの VFX をはじめ、多くのハリウッド映画の VFX を手掛けている。現在サンフランシスコに本社スタジオを構え、約 1000 人のアーティストが働いている。その他、北米ではロスアンゼルスとカナダのバンクーバーにも「ポッド」と呼ばれるサテライトオフィスがあり、アジアにはシンガポールに拠点をもつ。
今回インタビューに応じてくれたトニー氏は受注した仕事を海外の VFX プロダクションにアウトソースするプログラムを開発し、発注先の選定や円滑な意思疎通が行われるように管理している。
Q:どのような基準で発注先となる VFX プロダクションが選定されているのか？
176

ILM では仕事を発注する VFX プロダクションを「パートナー」と呼んでいる。
ILM のパートナーはスターウォーズ（クローンウォーズ）などを手掛けた台湾の CGCGなどアジアにいくつかあるが、ヨーロッパ、カナダのモントリオールなどに広がっている。
一般にパートナーとして仕事の発注を検討するプロダクションには、まずその会社のデモリールを見てそのプロダクションが過去に制作した仕事の出来などの実績を確認している。またその会社にある程度の規模の仕事を受けられるキャパシティがあるかどうかも判
断材料となる。また、優れた人材が確保できるように地域に優れたアート系の教育機関があるかどうか、同じ地域にほかにも VFX プロダクションがあるかどうかなどを調査している。
しかし最も重要なことは、やはりそのプロダクションのあげてくる仕事のクオリティであり納期を守るという信頼があること。
これまでにメジャーなハリウッド映画の VFX を手掛けたことのないプロダクションに仕事をふることはほとんどない。
私たちが特定の地域や特定の会社に発注するにはそれぞれ要因がある。
地域によって異なる税制優遇があり、また税制優遇を別にしても制作コストが変わってくる。ILM のクライアントである映画製作会社は、VFX の仕事を発注する際に例えば、「現地で撮影するので、モントリオールやロンドンの税制優遇を利用して VFX を制作してほしい」などといった注文をしてくる。
それらクライアントの要求に答えるために、税制優遇のある地域にオフィスを構えるプ
ロダクションとの関係を持つ必要がある。そのために様々な地域のプロダクションとの関係を保っている。また優れたアート系の大学のある地域のプロダクションとも関係をもつこともある。
たとえデモリールに素晴らしい作品が載っていてもそれだけで発注を決めるということはない。100 ショットほどを予算内にまた期限内に仕上げることができるかという点も重要となる。
実績があるように見える会社であっても仕事を発注する場合は、少量の仕事の発注するところから始める。そして信頼がおけるようであれば徐々に発注量を増やしていく。
Q：セキュリティ管理の問題
映画の仕事は映画スタジオとの機密保持契約があるため、外注先の IT セキュリティの状
況、機密事項の取り扱い方針なども審査の対象となる。
ネットワークをどのようにしているか、部外者がネットワークに侵入できないようになっているか、また自然災害や火災などに備えてどのようにデータをバックアップしているかなどもチェックしている。
177

Q：社員の雇用形態
そのほかにもその会社の雇用形態がどのようになっているのか、プロジェクト契約なのか、長期契約なのか、をチェックする。それによって今までの優れた仕事をしたスタッフ
がまだ会社に残っているのかがわかる。会社の規模が必要に応じて拡張可能かどうかも審査の対象となる。
またどのようにアーティストをトレーニングしているかも審査の対象となる。
使用しているソフトやパイプラインも聞くが、これらはそれほど重要な要因ではなく、それよりは上がってくる仕事の成果が重要となる。
Q:一つの映画のショットを数社に外注する時にどのように絵の統一性を持たせるか？
一つのシークエンスを一つの会社が担当するように発注している。
パートナーにはモデリングやテクスチャのスタイルガイドを供給すると共に、ILM が数
ショット作成したものを参考として渡し、それらを参考に作業を進めてもらっている。
アートディレクションに関しては ILM のスーパーバイザーが統括している。ILM ではパートナーに仕事を発注して、出来た仕事を受け取って終りということではなく、発注先をチームの一員として捉え、一緒に作業を進めていくようにしている。
しかしながら、パートナーからクリエイティブに関しての質問を受けるのはいいが、あまりに技術的な質問や問題解決の要求をしすぎてくる会社は対応が難しい。
Q：パートナーとデータのシェアはどうしているのか？
モデルといくつかのテクスチャは供給している。
リグはシェアしていたこともあったが、リグに関しては各社独自の制作スタイルを持っており、供給しても結局は使われないことが多かったので現在はやっていない。
シェーダに関してもパートナーは各社独自のものを使っている場合があるので、シェアしていない。
Q:ILM の海外戦略について
Rhythm & Hues や Method Studios、MPC などは積極的に海外に進出し拠点を構えているのに対し、業界最大手ともいえる ILM はサンフランシスコの本社以外に LA、バンクーバーなどの「ポッド」と呼ばれるサテライトオフィス、シンガポールにプロダクションを構えているのみであり、他の大手プロダクションとは異なった海外戦略をとっているよ
うに見える。そのあたりをトニー氏に尋ねてみた。
現在 LA のポッドには約 75 人のアーティストが働いている。ILM では LA のサテライト
オフィスはあくまでも「テンポラリー」（一時的なもの）という位置づけになっており、アーティストもほとんどがプロジェクトベースでの契約となっている。
LA をテンポラリーとしている理由は、私たちの業界ではコンスタントにいつも同量のプ
178ロジェクトの受注があるわけではなく、仕事の多い時、少ない時の波がある。そのためプロジェクトが少なく、多数の人員が必要ない時にオーバーヘッド（固定費）を低く抑えておく必要がある。
このような状況に対応するためサテライトオフィスは調整弁としての機能を果たしており、仕事量が増えサンフランシスコ本社にアーティストの作業スペースがなくなれば、各サテライトオフィスで人を雇い、同じネットワークを使って作業することができる。また
サテライトオフィスではモニタのみでコンピュータ本体は設置されておらず、作業するアーティストは遠隔地から本社のコンピュータにアクセスして作業している。
LA には多くの優秀なデジタルアーティストが住んでおり、これらのアーティストを雇用する際にコストをかけてサンフランシスコに呼び寄せる必要がなく、LA でそのまま働いてもらうことができるのも利点となる。
バンクーバーは LA スタジオと基本的には同じ機能を果たしているが、それに加えて BC
州の実施する税制優遇を受けることができるという点が加わる。
世界の様々な都市で実施されている税制優遇の状況も刻々と変化している。まずロンド
ンで映像制作会社にむけた税制優遇が実施され、その後バンクーバー、モントリオール、それぞれ後発の地域がより条件のよい税制優遇政策を実施してきている。
これら新しい都市が提示するより魅力的な税制優遇を各々追いかけて、次々とスタジオをオープンしていくのは難しい。それよりは税制優遇を実施している都市にある VFX プロ
ダクションとパートナー関係を結んだほうがより素早く対応できると考えている。
Q：インハウス（ILM 内）各スタジオでどのように仕事を割り振るのか？
サンフランシスコで重要な仕事を行い、LA やバンクーバーなどのポッドに簡単な仕事を割り振っているというわけではない。ILM では普段 4 本から 8 本の映画の VFX を制作しているが、同じスーパーバイザーが LA やバンクーバーもマネージしており、サンフランシスコと同じように重要なショットを割り振っている。一つのポッドでは 1 本から 4 本くらいのエフェクトの制作をしている。
Q：パートナーとなる VFX プロダクションに求めるサイズとは？
5~10 人規模では難しいかもしれないが 20～50 人規模であれば OK。必ずしも 100 人規
模以上などの大きい必要はない。
Q：パートナーに選定された会社が仕事を受注する際に入札はするのか？
パートナーには一応ビッド（入札）をしてもらう。
たとえ、仕事を発注したい会社が決まっていたとしても入札をしてもらい予算内、期限内に納品できるということを確認してから発注している。
179

Q：パートナーの選定に当たって、VFX プロダクションの税制優遇はどれほど重要なのか？
実際のところ ILM にとって税制優遇はあまり重要ではない。
それよりは定められた予算、期限内にこちらの要求するクオリティの仕事が納品できるかどうか？という点のほうが重要な要素となる。
私たちよりは、私たちのクライアントである映画製作会社のほうが税制優遇を重視している。やはり年々高騰する VFX 制作のバジェットが最大で 35%ほど節約できるというのは映画製作会社にとって大きな魅力となっている。
実写の撮影、編集などを行うことで税制優遇を提示し、さらに同じ国や地域で VFX などのデジタルプロダクションを行うとさらなる税制優遇特典を付与するという場合が多くの都市である。映画製作会社はこの制度を利用し、例えば既にオーストラリアで撮影を行い、一定の税制優遇を得ているときに、VFX の制作をオーストラリアで行うことでさらなる税制優遇を得ることができる。
Q：かつてのパートナーがコンペティター（競合する関係）にソフトの向上により、各社の開発力が上がった。多くの会社がハイエンドの仕事ができる状況となった。ピクソモンドはかって ILM のパートナーであったが、現在はコンペティ
ターである。
Q:日本の VFX 業界もハリウッドの仕事を取りたいと考えている。アドバイスがあれば。
日本が税制優遇を使って海外のプロジェクトを受注することを目指すのであれば、仕事を発注する映画スタジオが利益を得ることを考えるべきだと思う。
そうすれば彼らは日本で撮影するかもしれない。また ILM などに仕事を発注する際に日本にパートナーを作って発注するように要請してくるかもしれない。
税制優遇は国や地域によって様々なポリシーがあるが、私は日本で登記された会社がリベートを受け取れるようにして、その差額分をディスカウントし、クライアントが利益を享受するようにするというやり方が良いと思う。
それがクライアントである映画スタジオがシンプルに税制優遇の特典を享受できる方法だと思う。その手法であれば日本国内に会社を残しておけるし、また海外の会社が日本にスタジオをオープンするかもしれない。
これは日本の VFX プロダクションにのみ言えることではないが、最初の仕事を得るのはどこにあったとしてもとても難しい。
私たちは既に多くのパートナーを持っているので、新しいパートナーを探すのにあまり時間はかけることはしない。しかしもし優れた仕事をする VFX プロダクションがあれば興味はある。
最初にも述べたが、いきなりメジャーなハリウッド映画の VFX の仕事を受注するのは難しいので、コマーシャルや比較的低予算のハリウッド映画や米国以外の映画、ショートフ
180ィルムなどを通して VFX の技術のアビリティを見せるところから始めれば良いと思う。
外国映画で VFX を手掛けて、まずはある程度のショット数の量の仕事をある程度のクオ
リティをあげてできることを証明することができれば仕事を受注できる可能性が高まる。
学校や組織、一つの会社が地域で一番になってそこがハリウッドの仕事を受注する。
その後、一つのエリア（例えば東京）が注目され始めれば、東京にある他の VFX 会社も受注することにつながっていくというシナリオもありえると思う。
Q:日本人は英語が母国語ではなく、英語が苦手な日本人も多いがそのあたりはコミュニケーションを取る上でネックとなるか？
プロデューサーやスーパーバイザー、リードクラスのアーティストなどキーとなるポジ
ションにいる人は英語でコミュニケーションが取れなければならないが、それ以外のポジションでは必ずしも英語ができなくともかまわない。
Q:ディズニーの買収によって影響はどのようにみているのか？
現時点ではこのディズニーによるルーカスアーツ関連会社の買収案件は米国の SEC による承認を待っている状態。私たちはこの買収案件に対する不安はなく、それよりも大きな期待を持っている。
ルーカスアーツはスターウォースなどのテレビシリーズやゲームのマーチャンダイズなどの権利を所有している。今までは独自のディストリビューションを行ってきたが、ディズニーは世界にディストリビューションのネットワークを持っているので、より大きなビ
ジネスにつながるのではと思っている。またディズニーは以前より ILM のクライアントであり、ディズニーが買収したマーベル系の映画の VFX も多く手掛けている。そういったこともあり、特に不安は感じていない。

(6)

Sony Pictures Imageworks

Sony Pictures Imageworks（SPI）は、視覚効果及びキャラクターアニメーションの制作会社。1992 年に設立された。2004 年に「スパイダーマン 2」 がアカデミー視覚効果賞を受賞している。本社はカリフォルニア州カルバーシティ。インドのチェンナイやカナダのバンクーバーに支社がある。
ソニー・ピクチャーズ・エンタテインメントのグループ会社で、ソニー・ピクチャーズ・
デジタル・プロダクションの一部門であるが、ソニー・ピクチャーズ以外の他社作品の視覚効果にも参加している。ソニー・ピクチャーズ・アニメーションは、プリプロダクショ
ンなどの映画の企画製作を行う部署であり、ソニー・ピクチャーズ・イメージワークスは、
ポストプロダクションカンパニーである。

181

Q：バンクーバーの優位性
バンクーバーは TAX クレジットのインセンティブのお陰もあり、ここ 2、3 年で大きく進化した。タイムゾーンが同じで、FILM プロフェッショナルのタレントがいる。VFX のノウハウをどんどんインポートしている。Sony Pictures Imageworks VANCOUVER は非
常に早く発展した。現在 250 人のアーティストが来年(2013 年)には 300 人になる。
Q：アルバカーキの閉鎖について
アルバカーキに作ったスタジオは 3 年くらいで閉じた。理由は TAX インセンティブがなくなってしまったから。バンクーバーも TAX インセンティブができて軌道に乗ったが、何年続くかはわからない。
Q：ソフトウェアについて
モデリングやアニメーション、ライティングは Maya 中心。その他 KATANA、Houdini、Arnold、Nuke などを利用している。
Q：パイプラインについてShow に合わせたパイプラインを作るには多くのノウハウが必要になる。
Q：人材育成について
トレーニングプログラムはパイプラインとツールのスキルセットに関するもの。ベース
は Linux を知っていて CG ができること。昔は新規スタッフのトレーニングに 2、3 週だったが、今は 2、3 日。
大体他の会社からきているので、KATANA とか Arnold のような既存のツールについては知っていると考えている。
Q:開発スタッフについて
ディベロップグループに、Houdini などを使ったエフェクトアニメーションのためのソ
フトウェアを制作する人が 30～40 人いる。
Chief Architect Engineer として、KATANA、Houdini、Arnold、Nuke、Creature Rigなどの開発をアサインされている人が 12 人ぐらい。
Q:受注状況の変化について
ILM は、ImageEngine に発注するなど、下請けのポストプロダクションカンパニーをマ
ネジメントして、仕事を回している。Battle Ship など、そのほか 2、3 のプロジェクトで成功した。
元締めとなるメジャースタジオ（フォックス、ワーナー、ユニバーサルなど）は、部分
182

的に各社に発注してコントロールするのは大変だから包括的にマネジメントとクオリティ
管理をしてくれる一社に発注してそれをプロダクション間で分けてもらうようになりつつある。
我々も ILM がやっているように，外注してそれを統括するような仕事の仕方も考えていく必要があるのではないかと考えている。VFX のプロダクションは、プロジェクトによって雇用人材の増減を繰り返す傾向になるので、仕事の無い時期のオーバーヘッドのリスクや効率性を考えればそれも仕方ない。ただし、人件費が最も比率の高い支出であるため、どうマネージするかは非常にクリティカルである。
Q:外注先について
Shotproduction だと規模が大きくなるし，コミュニケーションも非常に困難になる。ス
ーパーバイザーがチェックするにしても大変。だから小さいチームで済むセクションの仕事をまとめて発注するのがいい。
（シンガポールでは）ILM もそれに困っていた。日本にもいつでもチャンスはあると思っている。
Q:日本への進出の可能性について
日本の会社はアジアの他社に比べて人件費が高い。中国など人件費の安い国に行っている。韓国も日本と同様に人件費が高いのであり得ない。
韓国の KOCCA が韓国の VFX プロダクションの代表としてきた。Sony のアウトソースが欲しいと言っていた。

(7)

Walt Disney Animation Studios

1929 年にウォルト·ディズニー·プロダクションズとして設立され、1937 年には、世界初のカラー長編アニメーション映画である「Snow White and the Seven Dwarfs」を制作している。1985 年には、劇場用長編アニメーション専門の会社であるウォルト·ディズニー·フィーチャー·アニメーションとなり、2006 年にピクサーの買収を機にウォルト·ディズニ
ー·アニメーション·スタジオとなった。本社はカリフォルニア州バーバンク。
Q:ソフトウェアについて
Render Man、Maya、Houdini を使っている。それらソフトウェアにプラスアルファして利用している。
ディスパッチャーは、一般的なディスパッチャーシステムを使ってカスタマイズして利用していたが、今は自前で開発をしている。
プレイバックシステムはインハウスで開発している。プレイバックシステムは制作管理
183

システムとリンクしている。
映像のソースは JPEG2000 を使っている。
Q:レンダリングサーバについて
レンダリングサーバは自社のみ。レンダリングサーバは数千台あるが、増減している。
社内と同等のスピードの専用線を確保できる前提であれば、社外のレンダリングサーバを使うことも検討している。
ディズニーとピクサーの技術的交流はあまりない。レンダリングサーバをやり取りしているくらい。
Q:制作工程管理について
最近（3 年位前から）は Shotgun を使い始めた。一度でも利用した制作工程管理システ
ムは、変えたくないというのがプロデューサーやディレクターなどの意見。制作工程管理システムの導入には、3 年はかかる。
導入に当たってアーティストからの反対は特になかったが、ディレクターが文句を言う場合があった。導入以前にアクセスできたデータにアクセスできなくなることや、新しいプロジェクトの開始と同時に導入する場合でも自分の Show で実験するのを嫌う事例があった。
Shotgun の開発者が 5 人、うち Shotgun のスペシャリストが 1 人いる。

5.2.2 カナダの CG・VFX プロダクションに対する調査
(1)

Exile

Exile Studio はバンクーバーのダウンタウンの東側に位置する古い街並みの残るガスタ
ウンにスタジオを構える社員 17 人ほどのプロダクションである。こちらでは「ブティック
スタジオ」と呼ばれる小規模スタイルの VFX プロダクションで、竜巻など自然災害などのエフェクトを得意とし、現在は主として北米向けケーブル放送の Sifi チャンネルで放映される映画やテレビシリーズの VFX ショットを手掛けている。Exile Studio がオフィスを構えるガスタウンは一時期さびれていたが、2010 年冬季オリンピックを契機に再開発が行われ、現在ではすっかりおしゃれな街並みとなり、近くには Zoic Studio, Pixar, ILM などもスタジオを構えており、VFX プロダクションが集まりつつあるエリアになっている。
今回は VFX Supervisor, Creative director の Francois Latremoille 氏に、小規模プロダ
クションの立ち上げ、運営などに関して話を聞いた。

184

Q:どのようにこの会社を始めたのか？
以前は今のビジネスパートナーと共にトロントの VFX 会社で働いていた。その頃からい
つかは自分の会社を立ち上げたいと思っていた。
バンクーバーにいる知人が VFX プロダクションを始めるのというので、トロントよりバ
ンクーバーに移ってきて彼が始めた VFX プロダクションで働き始めた。
その VFX プロダクションでは TV の SF シリーズの VFX を制作していたが、経営方針を巡って幹部間でのいざこざがあり、その会社はクローズした。その後、今のパートナーと 3台のマシンを購入して独立した。
以前働いていた会社と取引があった SF テレビシリーズのプロデューサーから連絡があり、仕事を受注することができた。その後次第に口コミで仕事がとれるようになった。
Q:小規模 VFX プロダクションの予算について
当社で VFX を担当している SF もののテレビ映画は一作当たり 200~250 万ドルで製作されており、そのうち VFX 制作には総予算の約 10%が割り振られる。
通常 90 分のショーには 100~120 の VFX ショットが含まれている。
会社を始めた頃は 1 ショット当たり 1500 ドルの値段で仕事を請け負っていた。
現在では少し値上げして 20 万ドルで 120 ショットを約 4 カ月かけて制作している。
バンクーバーの他のプロダクションは同じ仕事量で 50 万ドルくらいの見積もりを出すと思う。
当社では「B 級映画の予算で A 級映画のクオリティを」をモットーに低予算で出来るだ
けクオリティの高い仕事を上げるようにしている。
会社のランニングコストは月約 5 万カナダドル。
Q:人材について
当社の予算では経験のあるシニアクラスのアニメーターを雇うのは難しいので、学校を出たての素質のあるジュニアクラスのアーティストを雇い、トレーニングしながら仕事をしてもらっている。
大手の VFX プロダクションはジュニアクラスのアーティストは最初の 2 年ほどロトスコ
ープやマッチムーブなどの仕事をやらされるが、当社ではジュニアクラスのアニメーターにもう少し高度な仕事を与えている。
それによりアーティスト達はジェネラリスト的に働くことができ、CG 制作を全般的に学ぶことができる。そういう事情もあって、一度は大手 VFX プロダクションに移籍したアーティストが経験を求めてここにまた戻って来るケースもある。うちで数年の経験を積んだ185

アーティストであれば大手の VFX プロダクションでは時給 30 ドルでミドルクラスのコンポジターとして働くことができるだろう。
また大手の VFX プロダクションであるようなレイオフは今までのところほとんどしていない。
Q:プロダクション制作についてEXILE では主に SIFI チャンネルのテレビシリーズを手掛けている。
通常 2 つのプロジェクトを同時進行させている。
現在 SF がメイン低予算の HDTV 向けを映画の VFX を制作している。クライアントは
LA にあるテレビシリーズの製作会社。
彼らはバンクーバーで実写部分を撮影し、また VFX もここバンクーバーで制作することでカナダ連邦、及び BC 州のタックスクレジットを得て、制作費を節約している。
現在制作中の作品は米国でテレビ放映された後、世界で配給される予定。
Q:ソフトについて
ソフトは業界水準の Maya をメインに、エフェクトは Houdini、合成は Nuke を使っている。スケジュール管理はエクセルを改良したスプレッドシートで行っている。
Q：最近、アジアなどにも VFX 産業ができているがどう思うか？
アジアの VFX プロダクションに仕事を発注した知人の話ではまだクオリティに問題があるということであった。例えば上海ではデジタルアーティストを月給 500 ドルくらいで雇うことができると聞いている。安さは魅力的だが、ある程度のクオリティの仕事をあげるにはこちらからスーパーバイザーを派遣してオンサイトで管理しなければならないと思っている。
当社にもインドの会社からロトスコープ 100 ショットを 1 万ドルでやるというオファーもあった。
いずれにせよ、アジアなど新興国の VFX プロダクションは安さだけでなく、こちらが求
めるクオリティを達成できるという信頼を勝ち得るところから始めなければならないと思う。
今現在はクオリティ面で北米の VFX プロダクションに優位性があるが、アジアなどの新興国の VFX プロダクションは急速な発展を遂げているので、このままいけば 5 年後追いつくことになると思う。

186

(2)

Digital Domain Vancouver

デジタルドメインはジェームズ・キャメロンにより創設されたロスアンゼルスのベニスに本拠を構える大手 VFX プロダクションである。過去に「タイタニック」や「パイレーツ・オブ・カリビアン」、「トロン」などの VFX を手掛けており、一時期フロリダ、サンフラン
シスコ、バンクーバーとオフィスを構えたが近年経営危機により中国系の資本に買収され、2012 年にフロリダオフィスをクローズした。現在はベニス、ロスアンゼルス、サンフラン
シスコ、バンクーバーと北米西海岸に 4 つの拠点を構えている。今回はバンクーバースタ
ジオのヘッド・オブ・スタジオの Jason 氏及び、スーパーバイザーを務める坂口氏に話を聞いた。
Q:日本の VFX 業界はハリウッド映画の仕事を取りたいと考えているがそのためにどうすればよいか？
Jason 氏：「ハリウッド映画の仕事を受注したいが、なかなかうまくいかない」という日本にある問題は同じようにここ北米にもある。
ここバンクーバーではカナダ国内市場の仕事だけに頼っていたのでは経営は成り立たない。ほとんどの仕事は私たちにとって外国であるハリウッド映画スタジオのクライアントが占めている。
最近でこそバンクーバーでメジャーなハリウッド映画の VFX が制作されることが一般的になってきているが、この税制優遇が始められた当初、この制度を利用してトータルで VFX
プロダクションの制作費が 35%までセービングができるとしてもハリウッドのスタジオエ
クゼクティブは二の足を踏んでいた。それはディレクターが求めるクオリティの仕事ができるという信頼がなかったためである。
大手映画スタジオの発注担当者は失敗が許されない。そのため以前に一緒に仕事をしたことがあり、実績のある信用できる VFX プロダクションのみを使った。
また信頼を勝ち得た会社よりも、信頼を得た人に発注されることもよくある。
ハリウッドの大手映画製作会社のエクゼクティブが過去に仕事を発注したことがある
VFX プロデューサーがいたが、その VFX プロデューサーがバンクーバーの VFX プロダク
ションに移ってきたため、その仕事がバンクーバーのそのプロデューサーがいる VFX プロ
ダクションに来た。
そうした現実を踏まえると、バンクーバーも当初はスタジオエクゼクティブの信頼を勝ち得るまでは一筋縄ではいかなかった。

187

Q:パイプラインの構築について
Jason 氏：ある程度の規模の仕事をこなすためには、やはりパイプラインの構築が必要となる。パ
イプラインのファンダメンタル（基礎）はアセットマネジメントにつきると思う。作業するもの皆が同じデータベースを共有し、作業のバージョンをコントロールする、無断でオーバーライトしない。アーティストが作業する際には最新の正しいデータを引き出すことができる。変更が行われた際には即座にそれが反映され、みんなに知らされる。といった作業をスムーズに行える仕組みのこと。
私が以前責任者を務めていた Image Engine では仕事を受注する前の 2 年間を 6、7 人のプログラマーがクリーチャーのパイプラインを構築するのに費やした。その後タイミング
良く「第九地区」のエフェクトの仕事を受注した。
また、ドイツ資本のスキャンラインは 4 年かけて、流体シミュレーションのパイプラインを開発して、その分野でのスペシャリストになった。
中規模程度の VFX プロダクションにとって、パイプラインを一定以上のものにするためには開発に時間がかかりすぎるリスクがある。優れたパイプラインを構築できたとして、将来それを活かすことができるような仕事が受注できるかどうかは未知数であるため。
坂口氏：
私はデジタルドメインの本社であるベニス、その支社であるデジタルドメイン・バンク
ーバーの二つのスタジオで働いてきた。その経験を基に言えることは、フランチャイズのように同じ看板を掲げて、同じソフト、同じパイプラインをもつ支社においても、同じよ
うなクオリティの結果を出すことは困難だということ。
またこの業界において「一緒に働いたことがある」という安心感、信頼などはとても重要な要素となる。例えばデジタルドメイン内でベニスとバンクーバーの間で仕事をしていて、バンクーバーで何か問題があった場合、ベニスのスーパーバイザーは問題の当時者に直接連絡するのではなく、以前ベニスで一緒に仕事をしたことがある私に連絡をしてきて「どういう状況になっているのか」と聞いてきた。やはり一緒に働いたことがあるという信頼感はとても重要な要因なのだと思う。
またディレクターや VFX スーパーバイザーがハリウッドにいて、VFX の作業を離れている場所で行われるということは、近年ではかなり一般的にはなってきた。しかしコミュニ
ケーションや、問題があればすぐに直接話し合うことができるかどうかなど、主に心理面でまだ難しい面があると思う。
Jason 氏：
私はこのビジネスに長く携わってきたが、特に最近の過去 5 年間、VFX プロダクション
は利益を確保するためには、いかにオーバーヘッド（固定費）を低くするかということの188

必要性を痛感している。
VFX プロダクションを運営していくに当たって、人件費以外にもソフトの購入、データのストレージ、レンダリング用のライセンスなど多額の出費が必要となる。
コストを抑えるために現場が要求する数のソフトのライセンスを購入できないこともあり、時にはマネジメントと現場の人間との間で衝突になることもある。
最近、そういった問題を解決するために、バンクーバーではインフラを共有するという動きが起きている。実際、デジタルドメイン、Image Engine といくつかのプロダクション
でレンダーファームをシェアしている。
この会社はセキュリティもしっかりしていて、他の会社からは当社のデータにはアクセスできないようになっている。それぞれのプロダクションによって忙しい時期がずれるので、このシステムは今のところうまくいっている。
Q：日本の VFX 業界がハリウッドの映画の仕事を受注するには？
坂口氏：
例えばデジタルドメインは過去数々の大作の VFX を手掛けてきており名声も実績もある。
またスタッフは全員英語が話せる。しかしバンクーバーのスタジオで、ベニスと同じクオリティの仕事を出すには苦労がある。
お金さえあればハリウッド映画の VFX の仕事を成し遂げられるというものではない。
例えばコマーシャルデパートメントは通常 30 秒の作品を作るが、その規模を単純に大きくするだけでは映画の VFX 制作で 1000 ショットの作業がこなせるというわけではない。
また 50 人の優秀なジェネラリストがいても VFX の 2000 ショットはうまく処理できないと思う。
これらの作業は経験あるプロダクション運営、優れたパイプライン、それに経験あるリーダーシップがあって初めて可能となる。
Q：最近の多くの仕事が LA からバンクーバーに移っているという傾向について
坂口氏：
現在多くの仕事が LA からバンクーバーに流れている。
バンクーバーに仕事が来るということは LA の仕事量が減るということで、この傾向に関して LA のデジタルアーティストは不安を抱えている。
Sony Pictures Imageworks で働く私の知人は、マネジメントから「バンクーバーに移ってソニーで働き続けるか、辞めるか？」どちらかを選ぶようにと言われた。
Q：「第九地区」のエピソード
Jason 氏：
私が以前責任者を務めていた Image Engine での話だが、ニール・ブロンカンプ監督の「第189

9 地区」の VFX を担当した。この映画は「キング・コング」や「ロード・オブ・ザ・リング」のピーター・ジャクソンがニール・ブロンカンプに 3000 万ドルの予算を与えて作るよ
うに指示したもので、そのうち、VFX にさける予算は 800 万ドルだった。
ニールはバンクーバー中の VFX プロダクションに見積もりを取って回ったが、どこも2000 万ドルほどかかるとのことだった。Image Engine はプロジェクトをみて、エイリア
ンの毛皮をなくすなど、削れるところを削ってどうにか 800 万ドル以内で VFX を仕上げた。
映画は大ヒットして、ブロンカンプ監督の次回作の VFX も Image Engine で担当している。
後日談
面談の後、坂口氏個人にヒアリングする機会を得て、Digital Domain としてではなく、日本から海外で働く人材として、どのようにしたらハリウッドをはじめとした海外の仕事を日本のプロダクションが得ることができるのか聞いた。その要点について記す。
数年前までは、VFX の仕事は縦割り的に直接クライアントから各 VFX プロダクションに発注されてきた。しかし、「トロン：レガシー」あたりをきっかけに、現在は大手 VFX 会社が受注し、その VFX スーパーバイザーが品質を管理する役目を負い、その上で仕事を各
VFX プロダクションに分散させるスタイルが主流になりつつある。もちろん、その VFX ス
ーパーバイザーが所属するプロダクションでもショットを埋め持つ。こうした流れは ILMのヒアリングからも受け取ることができた。
したがって、日本のプロダクションがハリウッドなどの VFX の仕事を得るためにはこのVFX スーパーバイザーから信頼を得る必要がある。スーパーバイザーの信頼を得る上で最も重要な位置づけにあるのがデモリールである。過去の作品やオリジナルのショートフィ
ルムなど、そのプロダクションが持つ技術力をアピールするデモリールが、そのプロジェ
クトの求める水準にあるかどうかが、最も重要な判断基準になる。それに加え、コミュニ
ケーションパートナーの存在や、プロダクションの規模、安定したアウトプットができる
パイプラインを有しているかなどが加わり判断される。
余談だが、もちろん、この VFX スーパーバイザーに日本人がなるというのも一つの選択肢である。しかし、技術面だけでなく幅広い面の知識を持ち、なおかつビジネス面での信頼も得る VFX スーパーバイザーはプロデューサー的な能力も必要である。このレベルに達している人材は日本人にはいないと坂口氏は話す。また過去に、関係者からの強い推薦やコネクションがあって、海外のプロダクションに発注したケースもあった。しかし、うまくいかず、結果的に上記のような条件の重要性が再確認された。

190

(3)

Image Engine

Image Engine は昨今のバンクーバーの中堅以上の VFX プロダクションの中では珍しい
カナダ資本の VFX プロダクションで、現在 160 人規模で主としてハリウッド映画の VFX制作を行っている。代表作は「第九地区」（ディストリクト 9）やジョン・カーペンターの名作「遊星からの物体 X」の続編「遊星からの物体 X・ファーストコンタクト」（The Thing）などがあり、クリーチャー系のアニメーションを得意としている。
現在は「第九地区」のニール・ブロンカンプの新作「Elysium」やゾンビ映画「RIPD」などの VFX を作業中。
また東映の「はやぶさ、遥かなる帰還」の VFX の一部を手掛けるなど日本とのゆかりもあるプロダクションである。
ライティング・リードの清水雄太氏、Recruiting Coordinator であるジミー氏に話しを聞いた。
Q:どうやって日本にハリウッドの仕事を持ってくるか？
Image Engine も最初はハリウッドの仕事をとるのには苦労した。そこでピーター・マイ
ザーという実績のあるプロデューサーを雇いハリウッド映画の VFX の仕事をとることができた。また当初は技術面、アート面でもスーパーバイズできる人材がいなかったので、MPC
ロンドンで勤務していたカナダ人のスーパーバイザーをロンドンから招へいした。
大手のスタジオのクライアントも一緒に働いたことのあるプロデューサー、VFX スーパ
ーバイザーがいることで安心して仕事を発注するようだ。
Image Engine の創業期は、ビジネス面でもプロダクション面でもロンドンの MPC で働いていた人達を中心に基礎が築かれた。
日本でも海外で働き実績のある日本人を呼び戻して、海外の仕事を取るという方法があると思う。
Image Engine はカナダ資本の会社だが、他のバンクーバーにある会社は、LA かロンド
ンからのフランチャイズ。したがって、日本でもフランチャイズを誘致するという方法もあると思う。
最近 Image Engine では「バトルシップ」の VFX を手掛けた。この仕事は ILM がクライアントで、映画会社からすれば孫請けという図式となる。ILM から信頼を勝ち得るために約 2 年間はかかったと思う。
現在作業中のゾンビ映画「RIPD」は、映画会社が Image Engine と Rhythm & Hues に直接発注をした。
Image Engine も長い時間をかけてハリウッドスタジオからの信頼を勝ち得てきている
と思う。

191

Q:パイプラインについて
Image Engine ではパイプライン構築に力をいれてきた。当社のパイプラインの基礎は、
ロンドンの MPC 出身のプログラマーを中心に 6 人のプログラマーが 2 年の歳月をかけて構築された。現在はフィルム用のパイプラインと TV 用のパイプラインの二つがある。最初に時間とお金をかけてパイプライン構築するという面でリスクはあったが、パイプラインが完成した頃に大きなプロジェクトを受注することができた。
パイプラインの基礎として 3 年くらい前から Shotgun を導入しており、一人のプログラ
マーが専任で管理している。現時点ではパイプラインは Shotgun につながっている部分とつながっていない部分が存在している。
Q:クラウドレンダリングについて
バンクーバーのプロダクション数件がバンクーバーにあるクラウドサーバーを共有している。現状では Digital Domain が 7 割、Image Engine が 3 割くらいの割合で使っている。
レンダリングに関しては専属のチームが管理している。遠隔地ではあるが、データのやりとりの問題はなく、感覚としてはインハウスのものを使うのとは遜色ない。
Q:レンダラについて
Image Engine では現在 3Delight を使っているが、その理由としてはやはりレンダーマン
より安いという点がある。また足りない機能は自分たちで開発した。
最近では好みとしてレイトレースのレンダリング「Arnold」や「V-Ray」に向かってきている。レンダリングタイムは Arnold のほうが長いが、その代わりアーティストが少なくていいのが特徴。レンダリングのマネージメント（グローバル・イルミネーション）を使うとなると 3D テクスチャを使うなど管理が多いが、レイトレースになると簡単になる。実際
ライティングの手間が 3 分の 1 くらいになる。
現在「Arnold」と「Katana」を導入するか、このまま自分たちのパイプラインを使っていくかを検討中。
Q：開発チームについて
現在、開発チームのメンバーは 10 人くらい。
Q:人材教育について
特に人材教育のプログラムはない。本人に OJT で任せている。
Q:教育機関との連携は？
VFS（バンクーバーフィルムスクール）から多くの人材を雇っている。マッチムーブ、
ロトスコープなどの比較的単純な作業は VFS の新人を使って行っている。
192

Image Engine はカナダ人だけでは十分な人材を確保できないので、世界中から人材を探している。
Q:「ハヤブサ・遥かなる帰還」について
20 ショットぐらいを手掛けたが、パイプラインを用いた作業をしたので、作業環境が整うまでの時間がかかったが、それがいったん整備されれば作業はスムーズに進んだ。
Q:他社との共同作業について
サンフランシスコのマットペインティングの会社との遠隔でやりとりをしたことがある。
やはり遠隔地のやりとりは難しい。
現在の「RIPD」プロジェクトでは Rhythm & Hues とアセットの共有している。

5.2.3 米国・カナダの CG・VFX プロダクション以外の関係機関に
対する調査
(1)

Universal Studio（Virtual Stage）

Universal Studio Virtual Stage（以下「USVST」）は、Universal Studio が常設設置したバーチャルカメラのためのスタジオである。近年、VFX が複雑化するに従い、プレビズ（Pre-Visualization）の重要性が高まってきている。CG 作品であれば、3DCG のシーンでシミュレーションできるが、実写と CG が複雑にからむ VFX ショットでは、現実世界のカメラの動きと CG のカメラの動きをからめたプレビズなども要求されてきた。
こうした流れを受けて、考案された仕組みがバーチャルカメラである。スタジオで俳優やセットを撮影するカメラの動きを、MOCAP システムや画像認識を応用したシステムでデータ化し、3DCG のカメラと連動させる仕組みである。従来は、こうした仕組みが必要な場合に、その仕組みを特別にスタジオにセットアップしていたが、USVST はそれを常設化した初めてのスタジオである。
USVST で導入されているバーチャルカメラのシステムは、画像認識とジャイロセンサー
を組み合わせた仕組みである。天井に取り付けられた巨大なマーカーにより、カメラ位置を取得している。これに加え、位置や姿勢の取得には，ジャイロセンサーのついた特殊な検出用のカメラを利用している。
USVST のシステムでは Motion Capture を利用していないため，照明などについても特に制約はない．そのため、背後にある広大なグリーンバックのステージでリアルタイムの合成などが高品位かつ容易に可能である。カメラと PC は HD-SDI で接続，1,200 万ポリゴ
ン程度はリアルタイムで処理可能となっている。このスタジオを利用するに当たっては、
193

スタジオの使用料金として、一日当たり$9,000～$12,000、さらに、オペレーションに必要なスタッフは一日当たり$8,500 程度が必要になる。

(2)

British Columbia FILM and Media（BCFILM）

BC フィルムはカナダのブリティッシュコロンビア（BC）州にあるフィルムコミッションである。カナダ（BC 州）映画の振興、及び BC 州の映像産業の振興のために様々な活動を行っている。今回は BC フィルムのプレジデントであるリチャード氏にバンクーバー映像
産業の発展と税制優遇について話を聞いた。
Q:バンクーバー映像産業の発展と税制優遇について
バンクーバーVFX 業界は過去 5 年間に劇的な発展を遂げてきた。現在、メジャーVFX プ
ロダクションのほとんどがバンクーバーにスタジオを構えている。それと共にカナダ国内の会社も成長を遂げており高いレベルで海外資本の会社と競合している。このような発展を遂げた背景には、一つではなく、複数の要因があると思っている。
まず、一つめの要因として、バンクーバーは過去 25 年間において実写のプロダクション産業が存在したということがある。実写プロダクションに必要な人材、インフラ、ポスプ
ロなどが既に存在しており、これらの基盤がないところで、いきなり VFX プロダクションの中心になろうとするのは大変難しいと思う。
次にこれまでの実写制作に対するものに加え、デジタルで行われる仕事に対して特別な税制優遇を与えたことがある。当初はデジタルアニメーションの仕事のみに追加の税制優遇を与える予定だったが、デジタル・エフェクトの仕事に関しても与えることにした。
次にバンクーバーが立地的にハリウッドの近隣に位置しているということがある。映画
スタジオが集結するハリウッドとタイムゾーンが同じ位置にあるということは重要な要因となる。LA と同日、同じ時間帯にあり、飛行機で 2 時間半ほどの距離に位置しているので、なにか問題が生じた場合には朝にバンクーバーに来て、夕方に LA に戻るという日帰りも可能である。
次に教育システムが映像業界に必要な人材を輩出しているということもある。大学や専門学校では映像制作のコースを拡張しており、これらが人材育成、配給に役立っている。
また BC 州では、連邦政府と交渉してシニアクラスの人材にワークビザが早く下りるようにしている。ジュニアクラスの人材は育てるのに時間がかかる。シニアクラスで仕事も持って来ることができるような人材に世界各地から迅速にカナダに入国してもらい、働いてもらえるような環境を作ることも重要。私たちはカナダ連邦政府と、BC 州政府とに長い時間を費やして、これらシニアクラスの人々のビザが敏速に発給されるように交渉してきた。
これは、映画の公開に合わせたデジタル作業の締め切りに間に合わせるなど時間的なことを考えると、かなり重要な要因と言える。このシニアクラスのアーティストへの敏速なビザ発給に関して、私たちは BC 州のために連邦政府と交渉したが、結果として BC 州以外の194

州もこの恩恵を被っている。
また BC フィルムが主導して LA に出向いて VFX プロダクションにバンクーバーに出資してスタジオを構えるように交渉してきた。バンクーバー進出に興味を示した LA の VFX
プロダクションがあると、こちらのほうから現地に出向き、BC に進出することに関しての説明、（オフィスの場所や移民政策、税制優遇に関して）を行ってきた。
ピクサー、ソニー、DD など主要な会社がバンクーバーに進出したのち、バンクーバーで何かが起こっているということを業界に印象づけることができた。それにより他の会社もバンクーバーにオフィスを構えることを検討し始めた。
海外から VFX プロダクションを誘致するに当たってどこか特定の一社に特別な便宜を図るということはしていない。一つの会社に認めた便宜はどこの会社にも認めるようにして公平性を保つようにしている。全ての会社に同じ透明性の高いフェアな条件で進出してもらっている。例えばバンクーバーに進出を検討している会社が何か改善してほしい件を要求したとすれば、その会社のみだけでなく、全ての会社に平等に改善してきた。
私は BC 州の税制優遇をはじめとした様々な映像業界の誘致政策には確実性があると思っている。それはある会社には適用されるが、別の会社には適用されないといった不確実なものではなく、一定の条件を満たせばどの会社にも適用されるという部分で、その確実性はバンクーバーに進出を検討している会社にとっては重要な要素であると考えている。
Q:税制優遇を実施して、優遇した分の税金を補うだけのリターンはどのようなものか？
一つ目は個人、法人から得られる税金収入がある。また不動産賃貸やハードウェアの購入によって生じる税収もある。
二つ目は長期的な視点によるリターンがある。簡単にいえば BC 州の産業の質の転換と言える。現在 BC 経済はその多くを材木や鉱物などの天然資源に依存している状況で、この政策にはこれら第一次産業に依存した BC 州経済の構造を長期的にハイテク産業に変換していくという狙いがある。これらの構造変換によって、高い教育を受けた若い世代がここで働こうと思うようになると望んでいる。
つまりこの政策の狙いは短期的には税収の増加であり、長期的には一次産業に依存した経済からハイテク産業とのバランスを保ち、BC 州の経済を発展させていくことである。
Q:BC 州の税制優遇はどのように決められたのか？
1990 年の中盤からカナダ連邦政府レベルで税制優遇があった。それはカナダの独自コンテンツを振興し、米国の文化的侵略からの独立を守るためのものだったが、結果は、一部のプロデューサーを利しただけでうまく機能したとはいえなかった。
96 年に連邦政府は労働ベース（要した予算のうち人件費部分のみの税金を優遇する方式）の税制優遇を始めた。96 年に私が BC 州政府にも同じような税制優遇政策を始めるように働きかけ、98 年に BC 州政府独自の税制優遇政策が始まった。現在ではこの労働をベース
195

にした税制優遇システムが、カナダをはじめ、多くの国で実施されている税制優遇のモデルとなっている。いくつかの地域では制作費の全ての出費に対する税制優遇を行っているが、ほとんどは労働ベースの税制優遇となっている。
BC の他の州も独自の税制優遇で追随した。ほとんどの州政府の税制優遇措置は連邦政府の税制優遇と共有できるもので、どの州も根本的には似たようなプログラムを実施し、それなりに機能していると思う。
Q:税制優遇政策は効果が出ているのか？
政府の投資と雇用はリンクしているという調査報告がある。
先にも述べたように当初はカナダの映像産業が単なる米国の下請けとならないように、
カナダの産業育成としてフィルムと TV 業界を助成しようと始めた。特に VFX 業界を発展させようと思って選んだというわけではなかった。当初はカナダ文化の保護に必要な措置として始めたのだが、それが税制優遇につながった。デジタルコンテンツに対する優遇が2002 年に始まったときにはデジタルアニメーションを期待していた。デジタルプロダクシ
ョンということで、アニメーションに固定せずに VFX も含むことにした。今考えるとその決定には多少の運もあったが、もちろん VFX が盛んになることも予測していた。
Q:ゲーム業界はオンタリオ、ケベックに流れているが？
オンタリオとケベックの州政府はかなりアグレッシブな数字を提示している。
これらの魅力的な税制優遇のため、いくつかのゲーム会社がバンクーバーからオンタリ
オ、ケベックに移って行った。
ゲーム業界は今も BC の州政府と税制優遇の税率を上げるように交渉している。
BC 州はゲーム業界に関して税率を上げる必要はないと考えているようだが、今後どのような結末になるかはわからない。
Q:バンクーバーの映像産業は今後どうなると思うか？
この傾向が今後ともが続くかどうかはわからないが、バンクーバーの映像業界、中期的には安定しているとみている。
例えば数年前にソニー・イメージピクチャーズがニューメキシコ州のアルバカーキに進出したが、うまくいかず撤退した。アルバカーキには先に述べた映像業界としてのインフラや人材、またアーティストに選択を与えることができる複数の VFX プロダクションが無かった。複数の会社があるところは人が集まってくるもので、一つの会社にレイオフされたとしても他の街に転居することなく同じ業界で就職活動が行える。そういった意味で、
バンクーバーの優位性はしばらくの間は動かないとみている。
Q:この優遇措置はどのくらい続くのか？
196今のところこの税制優遇措置が今後どのくらい続くのかは分からない。
ただ「いつ終了する」という明確な期限を設けると VFX プロダクションが不安を感じる
ので州政府に交渉して、期限を設けないようにしてもらっている。
Q:BC 州政府はこの政策にいくら費やし、いくらくらいのリターンがあるのか？
1 年に 200 ミリオンドル（約百八十億円）以上使っている。どのくらいの効果があるのか
は計算方法によってかわってくるので、定義するのが難しい。またどのような計算方法を選ぶかによって変わってくる。どのような計算方法がいいかまだ確定していないので、いくらくらいのリターンがあるのかという問いには簡単に答えられない。

(3)

Digital Film Central

デジタル・フィルム・セントラルは 1999 年にバンクーバーにおいて創業され、主としてバンクーバーの VFX プロダクションに向けて映像データのカラーグレーディング、トラン
スコーディング、イメージプロセッシング、ノイズリダクションなどのサービスを提供している。同社の特徴は本来、deluxe や MPC、テクニカラーなど大手のポストプロダクシ
ョンが独自で開発し、自社内のみ使用しているようなツールやサービスを一般の VFX プロ
ダクションに提供している点である。
複数の VFX プロダクションが同じ映画の VFX を制作する際にデジタル・フィルム・セ
ントラルがカラーマネジメントやプレートを統一し、各プロダクションに提供することにより、複数の VFX プロダクションの作品の仕上がりに統一感を持たせることに一役買っている。また同社ではカメラやフィルムによって異なるアスペクトレイシオ（縦横比）やピ
クセルレイシオなどの統一も行っている。実際、バンクーバーにある VFX プロダクション
もそれぞれ会社によって、多忙期、閑散期にばらつきがある。各社とも仕事の入り方によって必要とされる機材や人材が変わってくる。
これら全ての会社が 12 カ月それぞれフルのキャパシティでソフトやハードを自社で所有する必要はない。街の中に一つそういったサービスを提供する会社があれば、各社とも必要な時にそれらのサービスを利用できるのである。
デジタル・フィルム・セントラルのエクゼクティブによると今までこのようなサービスを提供する会社はなかったという。この会社のサービスを利用することで、20～40 人規模の会社が共同で一つのプロジェクトに当たり、大手のメソッドや MPC などに対抗できるよ
うにしている。そうすることによりバンクーバーの VFX 業界をより強くする。LA やロン
ドンに勝てるようにするのが同社の理念でもある。

(4)

USC Institute for Creative Technologies

USC Institute for Creative Technologies（USCICT）は USC の設置する研究機関であ197

る。Paul Devebec 氏は Imagebased 技術、HDR（High Dynamic Range）技術、GI（Global
Illumination）技術などで世界的にも著名な研究者である。その研究成果はハリウッドの作品の中で利用されるケースもあり、VFX 産業との産学連携事例が多数ある研究組織である。
USC には VFX 人材のみならずハリウッドの映画産業の人材の大きな供給源であるシネ
マティックアーツ学部（School of Cinematic Arts）やコンピュータサイエンス学部（Computer Science, School of Engineering）があるがこれらとは独立した機関である。
そのため、研究に特化しており教育などの仕組みはない。そのため、日本の大学の研究室などとは形態が異なり、大学の附置研究所の研究室といった位置づけである。
Q:研究室の人員体制は？
現在は 12 名のプロパーの研究員がいる。これらの研究員には給与をフルタイムで支払っている。そのほか、世界中からインターンシップで参加している研究者もいる。コンピュータサイエンス学部の大学院の学生が、研究員として参加している事例などもある。
Q:研究テーマの設定について
研究テーマの設定についても、原則として USCICT や所属する研究院が独立して研究テーマを設定して進めるのが一般的である。
USCICT が独自で設定するテーマ以外に、企業側から研究テーマが用意される研究（いわゆる受託研究）もある。その場合は、用意された研究テーマにアカデミックな研究意義があるかどうかという点が重要な判断基準になる。最終的にアカデミックな成果（SIGGRAPH の Technical Paper など）に繋がるのであれば、実施することもある。また、
アカデミックな成果にならないとしても、産業界の技術標準になるような取り組みであれば実施することもある。
Q:研究資金の供給源は？
一般的には産学連携のイメージが強いが、研究の原資となる研究資金は政府からの助成金が圧倒的である。これに加え大学からの資金提供があり、企業からの研究費はこれに比べるとごくわずかであると Devebec 氏は述べている。
企業からの資金については、上記のような受託研究のようなスタイルのほか、研究成果であるシステムを利用する利用料のような形で提供される場合もある。
Q:産業界との結びつきについて？
Devebec 氏は VES（Visual Effect Society）のメンバーを 10 年続けており、アカデミッ
クな立場から産業界との連携を密接にしている。また、SIGGRAPH などでの活動も活発であり、学術界と産業界の双方において活躍をしている。産業界と密接な関係を保つことで、198

産業界のニーズを把握できたり、自らの考えている研究テーマの意義を確認できたりするなど多くのメリットがあり、非常に重要であると述べている。

5.3

欧州（英国・仏国）動向調査
表 5.2

月日

2月4日

曜日

欧州（英国・仏国）動向調査

場所

月

訪問先

訪問者

LES GOBELINS

Cecole Blondel(International relations )MIKROS IMAGE

Gilles Gaillard(MD)Marc Bodin-Joyeux (rep)

FORTICHE

2月5日

仏国

Pascal Charrue (co-founder)

パリ MAC GUFF

Jean-jacques Benamou(EP)火ONE MORE PROD

Benjamin Darras (CEO)BUF COMPAGNIE

Pierre Buffin(CEO)Jon Chads(business development director)

The Mill
2月6日

主な訪問先

水

Laetitia Beaujard-Ramoo(producer)

UK Screen association Sarah Mackey(Chief Executive)
Escape Studios

Garreth Gaydon(Recruitment Manager)

英国
ロンド MPCン
2月7日

Ben Cyzer(HEAD OF CREATIVE STRATEGY)
Grahame Andrew

LOLA

Michelle Martin

木
GLASSWORKS

Hector McLeod(CEO)Jason Nicolas(Head of CG)

PASSION PICTURES

Samantha Plaisted(Senior Producer)

仏国
2月8日

金

ヴァラ
ンシエ

SUPINFOCOM LUBIKA

ンヌ

199

5.3.1 英国の CG・VFX プロダクションに対する調査
ロンドンのプロダクションは SOHO と呼ばれるエリア、ピカデリーサーカスの側に大きな会社小さな会社も殆ど固まっている。今回は大手プロダクションとして、The Mill とMPC(Motion Picture Company)、中小プロダクションとして、Passion Pictures、グラスワークス、Lola というプロダクションを訪れた。
フランスのプロダクションと違うのは、フランスはプロダクションとポストプロダクシ
ョンに明確な差（プロダクションは企画、製作を行う、プロデューサー、及びディレクタ
ーが属している会社であり、ポストプロダクションは実際の映像制作を行うアーティスト
や機材を抱えている会社である）があり、小さな会社以外はどちらかに属するが、ロンドンはどちらの機能も持つ会社が多い。
また、ユニークなのは Runner という徒弟制度のようなシステムで、業界に入りたい若い子は学校卒業した後、希望の職種をみつけるためプロダクションに入り RUNNER（その名の通り使いっ走り）をさせられる。
Runner の経験を経て、プロダクションの流れ、仕組みを理解し、そして未来の自分を映し目標を持つとのこと。
大きな会社だと、Runner だけでも 30 名近く抱えるが賃金が安いため、基本的にはそれは本人の奉仕活動になる。
人件費の高いイギリスではこのようなシステムが無いと新人をいきなり雇って教育するのは難しいので、このシステムで大分成り立っているかもしれない。
仕事は「フィルム」という映画関連の仕事、「テレビ」は放映する全ての仕事、そしてその他の映像といった分類をしており、フィルム産業では英語という共通語もあり、昔から
米国、カナダのメジャーな映画作品の仕事を受注している。テレビ産業は TV シリーズやCM のような国内の広告代理店からの仕事が主な仕事になっている。
また映像プロダクション（CG 及び VFX を含む）が出資しあって、くじのお金をうまく運営する組織によって産業がサポートされている。

(1)

The Mill

The Mill は 23 年前に設立した。伝統的な VFX 制作会社で、400 名程度のスタッフがいる。元々は、U2 のレコーディングスタジオのようなことから始まっており、現在でも U2が出資している。
2011 年の 9.11 の後は経営が難しくなったが、その後 LA や NY に進出したりして盛り返した。またシカゴは米国で第 2 の広告の都市のため、シカゴにも支店を出した。
制作の割合としては、80 パーセントがテレビや CM で、劇場映画の VFX は 5～10 パーセ
ント程度。その他、切手のデザインなどやイベント映像なども手がけている。
200

NIKE や Google など大手スポンサーの CM も手がけている。キャラクターデザインも手がけており、Audi や RANGE ROVER のブランドデザインなども手がけている。
カラーグレーディングの仕事も得意としており、4 名のカラーリストを抱え、カラーグレーディングルームを 3 部屋有している。
Q：ツールやマネジメントシステムについて
3DCG ソフトは Maya と XSI を使っている。最近は MAC を使って制作をすることも多い。制作工程管理には Google Docs も利用している。
R&D チームが 3DCG のレンダリング、シェーダ、テクスチャなど全てに関して管理している。またプロダクションマネージメントも全て管理されている。
今のマネジメントシステムは 1～2 年で落ち着いたが、いつも小さな変更がされている。
Q：レンダリングサーバについて
レンダリングサーバは、Linux で構築している。レンダリングシステムはカスタマイズされているので、外のレンダリングサービスは使っていない。
After Effects は、クライアントへのプレゼンが多いのでそれに関して外部のレンダリン
グサーバが使えると思い、NIKE の CM で利用したが上手くいかなかった。
Q：人材の採用について
CM の仕事が多いので、3D のアーティストは基本ジェネラリストを求めている。プロジ
ェクトごとにスタッフを求めており、特にテクニカルな才能を持つ人材を幅広く探している。また LES GOBLINS からは、手書きのできるアーティストも採用している。
Q：常勤とフリーランスの割合は
CG アーティストだけで、30 名の常勤に対して 100 名以上のフリーランスがいる。フリーランスを雇うかどうかについてはリーダーがジャッジしている。
Q：フリーランスが多い状況でクリエイティビティのレベルをどう維持しているのか
クリエイティビティのレベルを維持するために、フリーランスとの良い関係を築くようにしている。特にキーデザイナーとの関係は重要である。10 名のプロデューサーがフリー
ランスも含めたスケジュールの管理を行っている。
Q：教育機関との関係について良い学校とは常にインターンシップや exchange を行っている。新人の採用はあまり行っておらず、年に 3～5 人程度をそれぞれ違う学校から採用するようにしている。

201

インターンシップや exchange では、ランナー（雑用係）からはじめてもらう。ランナーの給料は非常に少ない。ランナーを経験することでワークフローが見られるので、どのポジションにつく場合でも重要になる。現在 10～30 名くらいのランナーがいる。
教育機関については、スウェーデンとノルウェーの学校が新しい取り組みをしているので面白いと思っている。
Q:海外との共同制作について
海外との共同制作では、例えば香港で上映してロンドンでディレクションするなど離れたところでディレクションする場合もある。離れたところでディレクションする場合は、同じものを見ることができるようにするためのカラーマネジメントなどが重要になる。アムステルダムに広告代理店が多いので、そこに人とファシリティを送って、そこと仕事をすることもある。なお海外との共同制作の場合は税制優遇がある。
Q：日本に対してどう思っているか
CM の市場は 80%がアジアと言われている。今後は日本も含めたアジアに力を入れることを前向きに考えたい。

(2)

MPC

英国の大手 VFX プロダクションの一つで、1970 年にビデオポストプロダクションとして設立された。1997 年からフィルムの仕事（まずはタイトルワークから）を始めた。現在
では、アニメーション、フィルム、広告、その他映像など幅広く映像制作を行っている。
ロンドン（700 名）のほか、バンクーバー（300 名）、LA（75 名）、NY、バンガロール（250 名）に支社がある。なお LA の 75 名の社員のうち、9 名がプリビズをやっている。
最近のフィルムの VFX の仕事としてはプロメテウス（400 ショット）やライフオブパイ（150 ショット）を制作した。
CM の仕事では、NIKE の 1 分半のスーパーボールの CM のように、LA、NY、ロンド
ンと総がかりで手がけることもある。
また複数のカメラを利用して、マクラーレンの車の流体のビジュアル化の映像を制作したように、単純な 3DCG でない、ハードウェアを利用した映像制作もしている。
Q：受注先について
広告の 30～40%が海外からの発注、フィルムは 100%海外（ハリウッド）からの発注で、広告に関しては代理店から若しくはディレクターの指名で仕事が来るが、ファッションシ
ョーやサイネージなどの新しい分野の仕事は直接クライアントから仕事が来るように変化している。フィルムはハリウッドのスタジオから仕事が来ている。
202

Q：ツールやマネジメントシステムについて
ソフトウェアは Maya と RenderMan を使用している。またオリジナルで流体のソフト
ウェアやクリーチャーライブラリー（映画で使用したモンスターや動物の映像を、肌の色を変えることなどでテレビなどに流用できるようにしているライブラリ）を制作している。
アセットマネジメントシステムは、MPCTV というブラウザベースでクライアントがチェックするためのシステムと、社内のオリジナルの工程管理システムがある。
パイプラインはフィルムと広告は別のものを構築している。
Q：常勤とフリーランスの割合は30%が常勤のスタッフで、70%がフリーランス。R&D 部門は 20 名。
Q：人材育成についてシニアがジュニアを教える体制もあるが、インターネットで様々なカテゴリの研修用のビデオを見られる。また月に一回外部の講師を呼んで講演を行っている。

(3)

LOLA

12 年前に（元 TheMill の）2 名でスタートした。最初はコマーシャルのプレビズを手がけていた。現在は、TV ドラマの中のハイエンド TV ドラマやロングバージョン TV ドラマを多く手がけており、1 シーズンで 500 ショットくらいの VFX を手がけており、大手のVFX 制作会社から下請けをすることも多い。また CM やアニメーションやゲームの制作も行っている。
スタッフの人数はコアメンバーが 10 名で、プロジェクトによって 30 名くらいになる。
主にジェネラリストを採用している。
発注先は、30～40%が英国で、60～70%が米国から。様々な国の仕事をしているが、日本の仕事はまだしていない。国によっては相手がこだわるポイントが異なっている。
自社の PR 用にデモリールを作成しているが、デモリールに関しては大手からの下請けであっても自分たちの手掛けた部分を明確にわかるようにして確認を取って利用している。

(4)

GLASSWORKS

20 年前に 6 人でスタートした。元々は、ポストプロダクションサービスから始めた。
今は英国内で 45 名、他にアムステルダム（25 名）とバルセロナ（6 名）に支社があり、これからベルギーにも進出する予定。現在、英国内のシニアとジュニアのスタッフの割合
は 50：50。小さいプロダクションなためコミュニケーションが良く取れている。

203

仕事の内訳としては、TV コマーシャルが 65%、インタラクティブコンテンツとメディカ
ルシミュレーションが 35%くらい。バルセロナのチームでは、Kinect を使ったプロジェク
ションマッピングのシミュレーションシステムなどインタラクティブな映像も制作している。CM の仕事を同時に 3 つくらいやっているが、フィルムの仕事は、120 名くらいの人数が必要なのでできない。
Q：レンダリングサーバについて
クラウドレンダリングに関しては興味があるが利用していない。各サテライトとは、レンダリングサーバは、それぞれのサテライトでやっていることが違うため、共有していな
いが、SOHO ネットという 1 GB の線でサテライトスタジオとつながっている。料金は月3000 ポンド。
Q：人材の採用について
インターンシップに積極的に取り組んでいる。ドイツ人のインターンシップは非常に上手くいった。またランナーを 6 ヶ月ごとに採用している。
Q: メディカルシミュレーションについて
心臓疾患を発見するための内視鏡と連携した医療研修用のリアルタイムシミュレーター
を開発している。ドクターが 3 人関わって開発している。これはクライアントからの要求
で、システムも含めて提案した。

(5)

PASSION PICTURES「ロジャー・ラビット」に関わっていたメンバーで、1987 年に設立。2D アニメーションから始めた。
現在はコマーシャルとテレビとドキュメンタリーの 3 つのセクションがあり、ドキュメンタリーでアカデミー賞を受賞している。パリ、ニューヨーク、オーストラリアに支社がある。最近では、CM で制作したミーアキャットのキャラクタが英国で大ヒットした。
Q:スタッフについて
10～20 名が常勤のスタッフで、50～55 名がフリーランス。R&D が 5～6 名で、うちShotgun の担当が 1 名いる。
Q：ツールとマネジメントシステムについて
ツールは Softimage、MODE、v-ray、Nuke、Hero、Final Cut Pro を使っている。またアニメーションは Toon Boom やトゥーンズなどを使っている。
204

制作工程管理には、Shotgun を使っている。また以前制作工程管理に利用していた
FileMaker もまだ少し使っている。
Q：英国の仕事と海外の仕事の割合は70%が英国で、20%が米国からの発注。残りの 10%がその他（パリ、ニューヨーク、オーストラリアなど）からの発注となっている。

5.3.2 仏国の CG・VFX プロダクションに対する調査
フランスでは 1990 年代に設立された大手 VFX プロダクションである、
BUF、
Mac GUFF、
MIKROS IMAGE の 3 社と、小規模で設立されたばかりではあるが注目を浴びている
Fotiche や、 BUF から独立したメンバーが他のポストプロダクションと組んで立ち上げた
One More Production を訪問した。
フランスは、フライトシミュレーションといった軍事開発から CG の開発が進み、その後日本やカナダと同じように 1980 年代から多くの CG のプロダクションが発生し、独自の発展をしていった。
多くの良い学校が出来たことで、優秀な人材が育成され、アーティスティックな感性を持つ作品が次々と生まれた。そうした優秀な人材が育ったことから、アメリカの映画に関わるようになり、プロダクションはアメリカに支店を出したり、アメリカから投資されたりすることで、関係を強化してきたが、それも最近は他の国々がより良い条件で仕事を誘致するので、生き残りが難しい状況だ。
フランスは外国との価格競争を避け、また国の産業が発展するように独自の映像支援組
織「映像エコシステム」という方法を採っている。このお陰で、若手アーティストの育成
や、実験的な作品、技術開発等がしやすい環境となり産業自体を大きく助けている。
また、外国からの仕事でフランス国内に作業が発生する場合も減税できる方法がとられ、海外からの仕事を受け易くしている。

(1)

MIKROS IMAGE

1985 年に Maurice Prost（モーリス・プロスト）によって当時はフィルム、ビデオの編
集ポストプロダクションとして設立。ハイエンドの VFX の会社としてフランス国内はじめ世界的にもトップクラスの会社として知られており、ミクロスのアニメーション部門チームが制作した「LOGORAMA」は 2010 年にアカデミー賞短編アニメーション賞を獲得した。
パリ市内に 2 社、ヨーロッパの各都市、ベルギーのリエージュ、ブリュッセル、そしてカナダのモントリオールに支社がある。

205

グループ全体で、180 名のフルタイムスタッフと約 100 名のフリーランスのアーティス
トを抱えており、全てのプロジェクトは今回私たちが訪問した、副社長でもありゼネラル
マネージャーの Gilles Gailard 氏によって管理されている。
仕事内容は、映像分野での全てのフィールドをカバーしており。映画、短編映画、テレ
ビ CF、ビデオゲーム、音楽ビデオ、劇場映画の VFX など年に 400 以上のプロジェクトに携わっており、冒頭に述べたアカデミー賞はじめカンヌのパルムドール、セザール賞など、数多くの世界的な賞を取っている。最近ではクリスチャンディオールの往年の女優達が登場する「The Bear and Dior J'adore.」という CF もカンヌと米国の VFX 賞を取り、話題になっている。
近藤氏が 1997 年に訪れた時は、当時値段の高いインフェルノやヘンリーといったクオン
テル社の編集室を夜間若いアーティスト達に解放して彼らの作品作りに協力していたのが印象的だったとのことである。そのお陰で、多くのフランスの若いアーティスト達が育っていった。勿論彼らが成長して、また将来この会社に仕事を落とすという関係も多くあるのだろうと、会社全体の良い姿勢を感じた。
ベルギーのブリュッセルに進出したのは、EU の中心でもある場所でヨーロッパとしての活動を考えたという。またコマーシャルの編集室を持っている。
米国のポストプロダクションともパートナーシップを持ち、そちらは主に劇場映画のVFX の仕事を手がけている。同じくベルギーのリエージュ、スイスのプロダクションともパートナーシップを結んでいる。モントリオールにも 2012 年フランク・キッシェ監督の映画専用のスタジオをオープンしている。
今後は”Freestudios+Mikros image.”というブランドを立ち上げ、各国のプロダクショ
ン、ポストプロダクションとパートナーシップを行いたいと考えている。
Q：海外の会社と提携したり、支店を出したりマネージングはどのように行っているのか？
パリの 2 社はそれぞれ光ケーブルを引いて、やりとりをしている。実はこの近くにも先日映画用のオフィスを作り、そこでも 80 名くらいのスタッフが現在作業している。
マネージングに関しては会社全体のプロジェクトを管理やアーカイブ、品質、ソースの共有などそれぞれを管理するシステムは僕が手がけている。また遠隔地において、カラー
グレーディング作業ができるなど独自で開発したシステムでやっている。
Q：制作工程管理のソフトウェアは？
独自に開発したオクトパスというソフトでプロジェクト管理、データ管理などをして安定した質を保っている。Shotgun は賢いソフトでプロジェクト管理としてはとても良いが、もう少し広い用途で仕組みもシンプルなものになっている。
206

Q：それも政府の資金で開発したのか？
政府は直接開発の支援をしてくれるわけではなく、開発に当てる分の税金を免除してくれる。なので、このソフトはオープンソースとして将来的には使えるようになると思う。
またモニターキャリブレーションのソフト、カラーマスターに関しても独自のソフトを開発しており、一度日本でもそのシステムを使ったことがある。
（日仏共同制作の「夜な夜なペンギン」の作品）
Q：何名の R&D がいるのか？
純粋にシステム開発しているのは 18 名。
Q：何名のプロダクションマネージャーが居るのか？
本社では 4 名のプロダクション マネージャーが、それぞれのセクション、劇場映画、キャラクターアニメーション、TVCF、ポストプロダクション部門にいる。
また制作システムに関して、キャラクターアニメーションの部門では Maya でエレメントを作って Nuke で調整するということが日常行われているのだか、各スタッフの Maya
上での更新も常に共有され自動で Nuke にも反映されるような独自のパイプラインも開発した。
この後、Gilles 氏によって本社を隅々まで見学させてもらった。迷路のような回り込んだ
場所に色々な部門があって、それぞれ使い勝手が良さそうであった。以前はメディアがフィルム、ビデオ、データと複雑に別れていたため多くの人と場所を必要としたが、今は最小限の機材を残してすっきりしていた。
フランスは日本よりもまだフィルムが多く残っているので、このような本来のマルチメ
ディアに対応できる貴重な会社とも言える。

(2)

FORTICHE

パリのアパートの一階、中庭にある事務所は数日前に越したばかりで準備が整っていな
いと創立者のパスカルとジェロームがすまなそうに挨拶。
パッションピクチャーズはロンドンにあるアニメーション制作会社でそこのパリ支社のプ
ロデューサ マーク氏も立ち会う。
3 人ともデザインから企画、そして CG のジェネラリストというクリエィティブプロダク
ション。
最近のパッションピクチャーズが手がけた実写と組み合わせた Gorillas のプロモーショ
ンビデオ「Do Ya Thing」のキャラクターアニメはこのチームがパリで手がけた作品。
つまりパッションピクチャーズのディレクターとして作品契約をしているが、アニメータ
ーとしては Fortiche として受けられるという契約らしい。
207

日本と違って自分が関わった作品はホームページに乗せることができるので彼らのHomepage で観ることができる。
ジェロームは監督兼 3dsMax のジェネラリスト。そして Pascal も監督権 Softimage のア
ニメーター。Arnoux も 3dsMax のジェネラリスト。他にも数名のフリーランスアニメータ
が入れ、作品によっては 20 名くらいになることもある。
作品を見せてもらったが、どれも個性があってアニメーションのセンスはとても高かった。VFX だけでなく、キャラクターアニメーションを得意とした CG アニメーションに力を入れている。

(3)

MAC GUFF

Mac Guff は 1985 年に映画学校の 5 名の学生によって作られた VFX 及び CG の会社。
Mac Guff Ligne という名前は、ヒッチコックの映画用語で「重要な小道具」の意味。その創立者の Jacques BLED（ジャック・ブレッド）は社長。
当時あった大きな CG プロダクションに比べ、Mac Guff はアーティスティックな完成度
で TVCF や音楽ビデオで有名になり、ジャン=バティスト・モンディーノ、フィリップ・ス
タルク、ヤン・クーネン等、多くの有名なアーティスト達から支持を受けて成長していった。
1990 年後半から劇上映画の VFX、キャラクターアニメーションなども手がけ、ヤン・クー
ネン氏の「ドーベルマン」、ミッシェル・オズローの劇場アニメーション、フル CG 作品により「怪盗グルーと月泥棒」等に参加し、それ以降ユニバーサルと契約し、スタッフの数
も 50 名から 270 名と急激に大きくなった。
ユニバーサルなど、世界配給の作品を数本今でも制作中だが、本来のフランスのクライ
アントや監督達の仕事が受けることが出来なくなってしまったので、2011 年にアニメーシ
ョン映画は Mac Guff、従来のスピリットと仕事に戻るため"Illumination Mac Guff"という会社を新たに立ち上げ、共にジャック・ブレッドが社長に兼任。
Q：最近はどのような作品を手がけているのか？
アカデミー賞のドキュメンタリー部門に「The GATEKEEPERS」という作品がノミネートされたので、来週から米国に渡る。「The GATEKEEPERS」は、シークレットサービスの人がリタイヤをしてからのドキュメンタリー。残されている写真から CG のアニメーシ
ョンでリアルに再現した。
Q：フランス政府からの支援なども受けているのか？
フランスには制作者や作家を守る良い法律があって、テレビで放映する度に制作者（プロデューサを含む）に放映権のパーセンテージが支払われる。
208

また CNC との関係で新しい事を試みる時、SFX（VFX）、技術開発に対して助成金が支払われるシステムがある。
Q：学校とのかかわり合いは？
勿論毎回フランスにある有名な CG 学校、アニメーション学校の学生作品の審査や教育などにも深く関わっている。若い学生の作品を見て、それを社内でプロフェッショナルなアドバイス、機材を使って完成させる手助けをすることもある。
Q：フリーランスとの関わりは？
映画制作があるので数多くのフリーランスが働いている。
ファイナルイメージとコンポジットは社内で必ず行うがそれ以前のプロダクションは各
自の自宅で作業することも許されている。
Q：使用ソフトはどうしているか？またマネジメントシステムに関しては？
以前は開発陣が多く常駐していたので、ソフトも自社開発をして、そのソフトが 3D ア
ニメーションからコンポジットまで出来、また管理システムも独自で作っていた。
その後米国映画を手がけるようになって、既存のソフト Maya、Nuke を使うようになったら、開発チームは外に行ってしまった。
最近はイルミネーションを立ち上げて以来開発チームがフリーとして戻ってきて、定期的に管理システムをオーダーしている。
その後会社案内をしてもらうが、同じ管理者の会社とはいえ、MGL と MGL イルミネー
ションは自由に行き来ができないようになっている。この夏公開される「怪盗グルーと月
泥棒 2」の制作の為、MGL には入れず、そこには 300 名近いスタッフが働いているという。
イルミネーションだけでも今では 70 名近くのスタッフが作業していた。

(4)

ONE MORE PROD

凱旋門の近くにあるパリのアパルトマンの一室にある設立 5 年というまだ小さなプロダクション。ただしここは引っ越すまでの仮事務所で、そこは以前パリとベトナムにあった
大きな CG・VFX 会社の SNARX（元は SPARKS という社名）というポストプロダクショ
ンの会社と組むとのこと。創始者であるベンジャミン氏にインタビューをした。
Q: ONE MORE PROD について
歴史的にはまだ浅く、ジョニーというディレクターと、マティアスというアーティスト 3
人で会社を始めて今年で 5 年目になる。
209

以前は BUF にアーティストとしてつとめていて、「バッドマン＆ロビン」や「パニックルーム」の VFX を担当。その後 BUF はリュック・ベッソンと組んでもっとキャラクター
アニメーションの方に力を入れるようになったので、「アーサーとミニモイ」の第 1 弾の後退社しここを立ち上げる。
フランスではポストプロダクションとプロダクションの違いがはっきりしていて、ここはポストプロダクション。しかしながらディレクターとアーティストもいるので企画段階から最終までフルサービスの VFX の会社。
短編映画はもっと作りたいけれど、フランスで一度短編映画のプロダクションと見なされると、CF のような高い仕事が受けにくくなる。今はクリエイティブというよりサービスの会社として位置づけている。
また 2012 年に SNARX というポストプロダクションと組んだことで編集室のファシリテ
ィが揃ったため、今度引っ越しを予定している。
「PIXEL」というタイトルの作品を見せてもらったが、ショートフィルムの作品のセンスがとても良かった。今は小さい会社であるが、今後が期待される。

(5)

BUF COMPAGNIEBUF は創立以来 25 年の間、世界的にもユニークで最も質の高いデジタルプロダクショ
ンの一つとされている。
BUF が知られるようになったのは 1995 年のジャン=ピエール・ジュネとマルク・カロ監
督「ロストチルドレン」という映画の VFX を担当し、以来ハリウッドに進出し、
「エイリ
アン 4」
、
「バッドマン＆ロビン」、「ファイトクラブ」、「セル」を始め、「ダークナイト」といった作品で、独特な映像世界を手がけている。フランスの監督ミシェル・ゴンドリーもここの出身だ。
世界的にもその創造性でずっと注目されている BUF だが、設立者のピエール・ブッファ
ンはインタビュー嫌いでも知られており、貴重なインタビューとなった。
Q：私たち日本の映像制作者は「ロストチルドレン」以降、BUF の数々のアーティスティ
ックな映像にはファンが多い。
5 年くらい前までは制作費の殆どを技術開発にあてていた。でも、最近はアーティスティックな感覚こそが（技術を超えて）リードするということに自信が持てるようになった。
Q：あなたが成果物である映像を全てチェックしているのか？
自分自身は全てではないが、基本的に 4 名の熟練者が映像の監修をし、エフェクトやク
オリティをチェックしている。
また常にスタッフがどのようなエフェクトが良いか提案するよう常に考えさせている。
210

Q：CG 業界ではアーティストを確保するのが難しいが、どのように映像品質を管理しているのか？
正直なところ、ヨーロッパ内で良いアーティストを囲うことはとても難しくなっている。
アーティストが育って行くと、殆どが米国へ行くことを考えだす。勿論彼らは自由であり、自分達もそれを尊重するが、常に良いプロジェクトを探し、彼らのモチベーションをあげるよう努力してもやはり外へ出てしまう。それでもいずれフリーランスとして作品契約で戻ってくることも多い。私自身もアーティストを常駐として留める努力はしていない。
現在、常駐メンバーは技術開発のチームだけで、アーティストは 6 ヶ月以上の契約の者ばかりだ。フランスでは殆どのアーティストはそのようなフリーランスの者が多い。
Q：BUF はオリジナルのソフトを使用している点で、他の会社とコラボレーションしたり、また外からのアーティストを入れたりするのは難しいのでは？
新人を採る際に、社内のソフトの研修を受けてもらう。若いアーティストの方がソフトの習得が早く、特に美術学校や CG の学校を卒業したての人は 1 ヶ月で使いこなすようになる。他から既に経験者として入った人達でも 6 ヶ月を目安としてマスターしていく。
ソフトはプロジェクトごとに調整しているので、基本的にはどれも扱いやすいインターフェイスで作られている。
基本的にはアーティストにはモデリング、ライティング、質感、アニメーション、そしてコンポジットと完全にシーンを任せたいと考えている。ジュネラリストの方が、プロダクションとしてもスケジュールの管理がしやすいし、彼らのモチベーションもあがる。
中途採用者もあまり専門家を採ることはない。社内ソフトを一から覚えてもらうというより、スーパーバイザーやプロジェクトマネージャーとして参加することが多い。
多くのプロダクションもそれぞれ社内ソフトを使っているので、オリジナルソフトでも抵抗は少なく、またインターフェイスはシェアしやすいように作られている。
「Life of Pi」という作品は、いくつものプロダクションが国をまたがって関わっており、多くの素材を共有しなければならずそこは多少難しかった。
Q：レンダリングのキャパシティや方法はどうしているのか？
BUF の全てのプロダクションを会わせれば 3000 の CPU があり、それぞれ自動で管理されている。つまりアーティストがそれぞれレンダリングオーダーを出すと自動的に管理ソフトでプライオリティが決められ回りだす。
ここ 5 年間はリュック・ベッソンとの 3D アニメーション作品「アーサーとミニモイ」のシリーズを 3 作品手がけたので、その際に、外のレンダリングサービスを利用しようと色々検証してみたが、そのようなサービスは基本的に CPU の使用によって値段がかかるので使用しなかった。我々は一つのシーンでも何度も試行錯誤を行うし、最終的な絵に仕上げるまでいくつものレイヤーを計算させなければならないので、結局割高になってしまう。
211

それならレンダーファームは自社に持っていた方が扱いやすいので、結局プロジェクト
ごとに買い足していくようになった。
Q：つまりレンダリングの値段は、ソフトのライセンスによっても大きくなってしまうということか。
全くそうだ。以前は 1000 本以上の mental ray のライセンスを維持していたので1,000,000€（1 億 2 千万円）かけていたけれど、技術開発部が 2、3 年かけてオリジナルのシェーダを作ればそれ以下のコストで済む。
例えば映画のプロジェクトだったら、メーカーからスポンサーされることもあるが、基本的にはオリジナルの制作にもっと力を入れている方が良い。
Q：つまり今でも開発をしているのか？
今は私自身が年齢的な理由もあって以前のように開発しているわけではない。そしてこのソフトをワールドワイドにした方が良いかと考えている。難しい判断に迫られている。
私の考えでは、今まで開発してきたソフトをフリーウエア（オープンソース）にしてしまって、それぞれのアーティストが使用してまた開発してくれれば良いかと思っているのだが、私の共同経営者はそれに賛同していない。またアーティストがソフトを購入できず作品的にもリミットのようなものがあるのに疑問を持っている。
基本的には BUF のオリジナルソフトは長い年月と情熱を注いで開発してきたのだが、開発に携っていた人間が後に他社でそのソフトの特許を取ってしまったので、理想的な考えを実現する前に多少の法的な問題を解決する必要がある。
BUF はそのツールの特許件を主張しなかったので、第 3 社が特許をとってしまうと、自分達用に開発したカメラトラッキング（カメラマッピング）といった独自のツールでさえフリーウエアにしてしまうと色々問題が発生してしまう。
Q：国からの支援はあるのか？
研究開発という事柄に関して、税金から 30%支払われる仕組みになっているので、社内開発をするのに役立っている。
（つまり法人税を払うと、開発費が 30%まで支払われるのでR&D の殆どは国に支払ってもらっていることになる。）
この制度のお陰で、独自ソフトを作ることを奨励でき、そして国内の産業を活性化させるので、国にとっても良い。
例えば ILM といった大きな会社がディズニーに買収されると、彼らの活動は既に米国だ
けのものにならないはず。
その開発してきた財産は、既にどこかの国に渡ってしまう可能性がでてきている。

212

また別に、海外のプロダクションがフランス国内で行われると 20%減税（タックスシェ
ルター）される。このお陰で少し余裕ができるけれど、他の海外の国がもっとより良い条件を出して競争してくるので、将来的には難しくなってくる。
例えば、カナダは 45%の減税、そしてシンガポールはそれ以上申し出ている上に、中国がどの国より 20%安い価格で提案するようになってきた。
このような世界的競争の中ではクリエイティビティを高めるというものでは無くなってきているので、自国で開発し続けるということが重要になってくるだろう。
今の所、研究開発に当てられる国からの支援はとても重要だ。
他にも日本や海外のプロダクションにとって有利なことがある。もし海外のプロダクシ
ョンがフランス国内で映画を作りたい場合、政府観光省が資金を援助する。フランスの宣伝になり後に海外からの観光客が増えることにつながるからである。
日本は美しい国だし、そこに良いアーティストも多くいるのが解っているけれど、そこに辿りつくまでは高額で入りにくいイメージがある。
ギャスパー・ノエ監督の作品で”Into the Void”に関わった時、イメージの世界で歌舞伎町の上空を飛ぶシーンがあったが、国内の制作チームは香港で撮影するアイデアがあり、最終的には BUF が CG で作成した。
日本は海外の人をもう少し啓蒙する必要があるかもしれない。勿論一度出来上がったイ
メージを変えて行くのは努力がいる。
Q：日本と共同で制作をすることはあるか？
近藤：以前いくつかの CF をお願いした時にインフェルノアーチストが「日本人はあまりにもこだわりすぎる」と言っていたのが印象的だが。
日本ともっと制作と技術開発をやっていきたいと考えている。多くの知人が日本、そして日本のアニメーションに魅せられている。それは世界的にもトップレベルだと思う。
日本の CF のクライアントは確かにものすごくこだわっているが、CF 自体が本質的に認識されるものなので、他の国でも同じことが言える。どこがどう違うと一言に言えないが、
例えばオランダの人と仕事をする時もまた違うこだわりを感じることもある。
Q：海外にパートナー会社はあるか？
無い。支社は L.A とカナダにあるが業務をアウトソーシングはしていない。
「アーサーとミニモイ」の映画 3 部作では、CG アニメーションは全てパリの BUF で担当した。第一作では、70 名から多い時は 150 名ものスタッフがいて、その後 2 作、3 作目
は既に多くの部分の開発が終わっていた為、それよりは少ない人数で制作したが、それぞれ違った方法で新しいことを試した。実写撮影も含め新しい体験は積極的にやって行きたい。

213

1988 年の創立以来、そして 2000 年に入ってから多くのハリウッド映画に携わるようになり、年間 29 百万€の売り上げがある。

5.3.3 欧州（英国・仏国）の CG・VFX プロダクション以外の関係機関に対する調査
今回の調査では、欧州の CG・VFX 関係の教育機関として、フランスは LES GOBLINS（ゴブラン）、と Supinfocom（シュパンフォコム）を、ロンドンでは Escape studio という
SOHO のプロダクションで働く人材を送り出している専門学校の調査を行った。
LES GOBLINS と Supinfocom の両校の学生は、アヌシー国際アニメーション映画祭などの世界的に有名な映像際に、クオリティの高い学生作品（主にショートフィルム）を在校中に制作して出展していることで有名である。
LES GOBLINS や Supinfocom は、地方自治体や商工会議所の資金から作られたもので、バカロレア（高等学校卒業資格）の後、作品面接や試験を受け 40 倍〜50 の倍率をくぐり抜けて入学し、映像制作に関する知識を 5 年間かけて習得する。
勿論、美術大学はあるのだが、そちらはもっとアカデミックな教育を行っており、実践を 伴 う プ ロ フェ ッ シ ョナ ル を 育 て る教 育 機 関と し て は 、 今回 の LES GOBLINS や
Supinfocom のような専門校にはかなわない。
企業もこうした学校に対して協力的で、学校のイベントにも忙しい時間の中から経営者
やディレクターといった決定権のある人間が、学生のプレゼンテーションや、作品審査などに深く関わっている。
実際、今回訪問した Supinfocom では就職合同企業説明会が行われており、その日はフランスはじめ国外からもプロダクションが参加していた。参加企業も ILM、DreamWorks、Double Negative、PASSION PICTURES、Sony Pictures、R&H、といった世界的な大手
プロダクションで、プロデューサー、ディレクター達が立ち会い、学生たちの作品を評価していた。
これらの学校は昔から日本のアニメーションに感心をよせ、日本との交流を持ちたいと考えており、学生の日本での就職、インターンシップなども考えているが、各企業で英語を話す者が居ないために断られたり、これらの学校が大学ではなく、日本でいう専門学校の扱いになってしまうので、就労ビザの取得が難しかったりするため、あまり上手くいっていない。こうした世界的な土俵で力を発揮できる学生達をうまく受け入れることができれば、日本のビジネスの良いパートナーとなることが期待できるので、そのための方法を
考えたい。

214

(1)

LES GOBELINS

1963 年に設立した。パリの地域の学校。大学ではなく美術学校としての存在だが、日本
では専門学校のカテゴリとなる。パリ市内だけでなく、郊外のユーロディズニーの側 Noisyにも学校があり、そちらでは大きな印刷用機械など最新の設備を取り入れた教育を行っている。学生が最高の環境で学べるよう最新の機材を導入しており、3 年ごとに機材の見直しをしている。
この学校は全ての映像、画像に関する仕事をする人向けに、「プロフェッショナルな教育を」を徹底している。Animation Film Making、 Interactive and Digital Communication、Motion and Graphic Design、 Print and Graphic Art Industries、 Photography 、Video
Game 、Video and Broadcast Technology といったコースがあり、なかでも Animation
Film Making コースは有名で、ベストショートフィルムアニメーションのカテゴリでオス
カーにノミネートされた作品（Oktapodi）の制作者など、毎年世界的に活躍するアーティ
ストが多く卒業している。
そうした優秀な卒業生によるネットワークが構築されている。そうしたネットワークが仕事上でも役立ったり、卒業生が在校生の就職の手助けをしたりしている。
高校を卒業した後すぐにはなかなか入れない。非常に狭き門。例えば Animation Film
Making では 600～1000 人の応募者の中で 25 人しか選考されない。厳しい選考をしてできる人しかいないからモチベーションが高い。
選考される人材は、クリエイティブスキル、テクニカルスキル、プロフェッショナルス
キルの 3 つの基礎を持っている人で、例えば Photography コースでは既に写真家としての知識や経験を持つ人材が、Video Game コースでは入学する前に既にプログラムの基礎を理解している人材が選考される。Video Game コースでは 10 名しか選考されない。
常にグループでのチームワークで仕事をすることを覚えさせるため、授業は全部プロジェクトベースで進められる。グループプロジェクトでは、インディビジュアルスキルとチームワークスキルを開発するように設計している。卒業資格は最終作品を作ることで得られる。
積極的に世に出ることを後押ししていて、プロモーションやフェスティバルに出展するように支援している。例えば 2 年生で、アヌシーのアニメーションフェスティバルに出展するショートフィルムを制作している。アヌシーの会場で流れることができれば注目されるため、モチベーションが高く数々の名作が生まれている。
学校のプロモーションをすることは、学校の宣伝になるだけでなく、外から講師を呼びやすくすることにつながっている。
常駐で 45 名の教師がおり、アーティストやプロデューサーやディレクターや役者など
400 名の多様なゲスト講師がいる。

215

企業のプロジェクトに近いことを習得することが大切と考えられており、授業内容は非常に実践的なもので、
例えば Interactive and Digital Communication や Print and Graphic
Art Industries コースは授業の半分を学校で、後の半分を企業で行う。
具体的には、Photography コースの学生のワークショップでは、有名なファッションデ
ザイナーの服を利用して撮影を行い、メイクアップアーティストの協力としてメイクアッ
プして、Print and Graphic Art Industries コースの学生が本にするなどを実践している。
海外との関係としては、10 のパートナー（ドイツ、英国、米国、デンマーク、ハンガリー）があり、・プロフェッショナルとして海外（香港、ケープタウン、マナウスなどいろいろ）で働いているアニメーターが参加するインターナショナルのサマースクールも開催している。
アーティストだけでなく、アーティストとしての才能もあるプロダクションマネージャ
ーも育てている。彼らは映像の出資のメンバーになったりもする。
このように LES GOBELINS の学生は非常に優秀であるが、LES GOBELINS は大学では無く卒業資格がマスターでないため日本のビザが取りにくいという問題がある。

(2)

UK Screen association

The UK Facilities Sector (UK 施設部門)は年間￡2.2B (22 億ポンド)の売り上げがある。
従業員数は 2 万 5 千人以上（フルタイム労働に換算した場合）。輸出所得は￡290M(2 億 9千万ポンド)以上、大蔵省への貢献は￡262M（2 億 6 千 2 百万ポンド）、そして￡1.6B (16億ポンド)の GVA（粗付加価値）がある。過去 3 年間において 15%の成長率を示しており、何よりもオーディオビジュアル作品の制作と供給を促進する主な発信源であり、クリエイ
ティブ産業における最新テクノロジーとスキルをほとんど総括している。
UK スクリーン協会（以下 UKSA）は、映画、TV コマーシャル等のスクリーン業界にサービスを提供する会社の代理を務める貿易機構。UKSA は独立した団体で、その運営資金は業界内のポストプロダクション、ビジュアルイフェクト、フィジカル特殊効果、音声、
カメラ、照明、フリーランスのタレントが所属する会員会社から得ている。
UKSA はネット―ワーク、トレーニング、ビジネスや法的アドバイス、助成金や節約に関する情報提供のセッションなど幅広いサービスやイベントを行う。
UKSA の最も重要な役割は、業界内の重要な意見を統括し、政府、放送局、スタジオ、製造者、プロダクションチームなどに対して業界を代理して発言すること。
UKSA との主な取引先は、DCMS、BIS、PACT、BFI、Film London、 The British Film
Commission、 Skillset、 Next Gen、 The Digital Production Partnership、 BSAC、 The
Production Guild、入国管理局など。
UKSA は TV や映画プロダクション関連会社のサポートを行うコンサルティング団体として広く認識されている。
216

Q：英国内の VFX の会社の規模は？
国内の VFX 大きな会社は 5 社ある。


Double Negative (映画用のスタッフ数：900 名)Cinesite



MPC



Framestore (スタッフ数：200 〜400 名)



The Mill（for TV and CF 出約 400 名）

その他、15～30 ほどの小から中サイズのプロダクションがあるが、これらはプロジェク
トベースで存在しており、繁忙期には小規模の会社や個人を含めると 100 団体に伸びる可能性がある。
Q：英国政府からの援助はどのようなものか？
BFI 協会はショートフィルム又は文化的価値が認められる（非営利的な）ショーに対して資金援助を行う。
（これらの資金は政府が運営するクジの利益金が使われる。）
BF コミッションは米国のプロダクションが英国内で撮影を行うかの相談を受け、そしてこれらの作品が全世界で英国に対する好印象を得るかを判断する。また英国での撮影が25%以上を占める場合、税金控除を受けることができる。
新しいツールの研究やデザインを行った場合、そして新しい技術が使われた長編作品又はフィクション（非営利目的の作品）は最高 20%までの法人税の控除が受けられる。
その他の資金は企業がインターン制度などを導入した場合、英国貿易産業プログラムから提供される。
今までの全資金は 2 年間で 2 億 1500 万ポンド（日本円で 311 億 7500 万円）。
そのうち 1 万ポンド（1 億 4500 万円）は例えば VFX の 1 企業に対してではなく、全セ
クターに計上することができる。この予算を得た場合は、協会所属のメンバーのよってどのように分配されるかが決断される。
Q：新しい技術を使っている VFX 会社はクレジット税の控除を受けているわけではないのか？
はい。直接的ではない。
これらの優遇は海外のプロダクションが英国に来て仕事をする、又は英国の VFX 産業を利用することを促すための措置となっている。
この措置はカナダ、ニュージーランド、オーストラリア、シンガポール、その他の国々からのオファーを上回り英国を選択するための役割も果たしている。

217

プロジェクトの予算を集めるプロデューサーは英国内の VFX に仕事を発注することにより、このベネフィットを受けることができる。
これは直接的なベネフィットではないが、雇用を生み出し、評判を上げることができる。
率直に話すと、ヨーロッパ各地からヨーロッパ内でのフェアな競争が行われるべきとの驚異的同意書が多く存在する。これらの同意書では柔軟な税金控除の余地がない。各国での税金逃れの考えは投資家に興味を持たせる。フィルム業界では税金は 1 企業が作った 1 作
品に対して対処される。

(3)

Escape Studios

2002 年に 3 名で設立された教育機関。コンピュータグラフィックスプロダクションの技
術トレーニングを行い、CG や VFX のプロダクションの即戦力を育てている。
Visual Effects
Production、Visual Effects Professional、Compositing for Production、Compositing
Professional の 4 コースがある。
フルタイムのコースでは、月曜から金曜の午前 10 時から午後 5 時まで授業がある。パー
トタイムのコースとして、午後 7 時から午後 10 時まで週 2 回のコースもある。また 12 週
間で Nuke や Maya を教える集中コースもある。集中コースで、授業料が 1000 ポンドと2000 ポンド。大学より授業料は安いが、ただし奨学金は無い。
3D だけでなく、2D（コンポジティング）についても教えている。講師は実際に業界で働いているベテランが、業界に必要なスキル、キャリアの書き方、ショーリールの作り方等も含めて教える。ただし、アニメーターとしてアプライするにはこの学校のカリキュラム
だけでは不十分。
未経験受講生については、事前に 3～6 ヶ月の入門コースを受けてから入ることが多い。
入門コースでは、Maya Core を 6 週間、Visual Effects を 6 週間、ソフトウェアは Maya、
Photoshop、3DE、Mudbox、Nuke を利用している。
75～80%が卒業後に職を得ており、MPC やフレームストアなどの大手 VFX プロダクシ
ョンにも就職している。また卒業後、3 ヶ月間はおさらいの授業を受けることができる。

(4)

SUPINFOCOM LUBIKALES GOBELINS と並んで、フランスでは有名なディレクターCG アーティストを育てる
学校で、地方商工会がスポンサーとなって設立された。
北フランスのベルギーと国境の近くにあるヴァランシエンヌは、もともと炭坑と絹の街として知られていたが、時代の移り変わりと共に産業が衰退し、長いこと寂れていた。そこで地方行政や商工会が地方の活性化の為、1987 年にデジタルデザインの学校が設立された。
218

その学校教育方法なのか、（娯楽が何も無い）街の環境のせいか、学生達の才能なのか、当初から驚くべき質の高い学生作品が世界各国の映像フェスティバルを賑わすようになった。
その後南フランスのアルル校が設立され、そしてインドのムンバイの郊外のプネーという街にインド校が設立された。
また映像だけでなくゲームもデザインから開発を学ぶ Supinfocom game 校も設立された。
Supinfocom game 校では、今度日本の名古屋にある専門学校と提携も考えているとのことである。
5 年間のカリキュラムのうち、デッサン、企画、絵コンテ、演出、仕上げといった映像制
作を最初の 3 年間でみっちり学び、その後アニメーション、ディレクター＆プロダクショ
ンマネージメント、アートディレクター&VFX という専門にコースに分けられ、映像に関わる様々なこと、例えば音楽やナレーション、撮影、シナリオ、エフェクトなども学び、学生同士が協力しながら短編作品を作り上げていく。最後の 1 年間で卒業制作を行うが、この時も共同制作を重視し、学生同士評価し合うのは勿論、企業からもディレクター、プロデューサーが呼ばれ学生プレゼンテーションの場に立ち会う。
共同制作をすることによって、客観的な判断が出来、より良い作品にする為のディスカッションがかわされる。この経験が後に就職した後でとても役に立つ。日本の教育方法と異なり大変興味深い。
訪問日である 2013 年 2 月 8 日は、企業の就職合同説明会の日で、UBI ゲーム、MIKROSImage、Mac Guff といったフランス国内はじめ海外からも多くの企業が参加して、熱心に
プレゼンテーションをしていた。
Supinfocom の 3 校ともレベルが高く、世界の大手市場で多くの卒業生が活躍している。
日本の企業での就職を希望する者も多く、この日もゲーム科の学生から日本の企業での就職についての相談を受けた。こうしたレベルの高い教育を受けた学生達が日本の企業が受け入れられるためにはどうすべきかが、今後の課題となる。

219

5.4

海外動向調査まとめ

5.4.1 人材について
米国・カナダの大手プロダクションではスペシャリストが求められるが、小規模なプロ
ダクションでは日本同様に基本ジェネラリストが求められている。欧州では大手プロダク
ションであってもジェネラリストを求めている会社もあった。
契約形態に関しては、期間単位であったりプロジェクト単位であったりするが、フリー
ランスが多く社員は少ない。そのため時期によってスタッフの数が増減する。米国の大手
プロダクションの場合、福利厚生面は社員と同等であることもある。
英国の大規模なプロダクションでは、インターンシップや echange などで学校から人材を採用している。新人の採用はあまり多くなく、採用した場合ランナーと呼ばれる雑用係からはじめることになる。ランナーを経験することで、全体的なワークフローを見ることができるのでランナーを経験することは重要になる。
新人教育は 1 ヶ月というところもあったが、1 日というところもあり、基本的にはプロフェッショナルが集まるため OJT というところが多い。ただ大手プロダクションでは教育が受けられるための環境は別途整えられている場合が多い。
そうした人材を輩出する好例として、仏国ではプロフェッショナル向けの教育を行う教育機関がいくつかある。そうした教育機関は選考も厳しく入学も狭き門である。授業はプ
ロジェクトベースで行われている。卒業後は仏国だけでなく他国のプロダクションからもオファーが来ている。優秀な人材が集まっているため卒業生のネットワークが仕事や就職に役立ったりもする。ただしそうした学校は専門学校であるため、専門知識を持つ優秀な人材ではあるが日本でのビザが取れないという問題もある。
また米国の USC には教育を行わず研究に特化した機関があり、その研究成果はハリウッ
ドの作品の中でも利用されている。

5.4.2 開発環境について
開発に関しては、大手プロダクションでは R&D 部門を持つところが多く、自社でツールを開発している場合も多い。
制作工程管理については、大手プロダクションでは制作工程管理システムが導入されているが、小規模なプロダクションでは統一された制作工程管理システムが導入されておらず Excel や Filemaker などが利用されている場合もあった。
大手プロダクションでは自社開発のソフトや Shotgun を利用しているケースが多い。制作工程管理システムは継続したアップデートが必要となるため、Shotgun を利用する場合
220

でも、開発を行うための Shotgun スペシャリストなどを開発部門に抱えていた。大手プロ
ダクションでの制作工程管理システムの構築には数年がかりで取り組んでいるとのことであった。また映画とコマーシャルでは制作工程管理システムが異なる場合もあった。
なお他の VFX 企業とデータの受け渡しについては、例えデータの受け渡しは行っていても、制作工程管理システムまで共有しているといったケースは無かった。
レンダリングサーバについては、米国では遠隔地にレンダリングサーバを設置してレンダリングを行っている事例はあるが、他社とレンダリングサーバを共有している事例はなかった。カナダでは、いくつかのプロダクションでレンダーファームをシェアしているという事例があった。そのレンダーファームはセキュリティがしっかりしており、他社のデータにはアクセスできないようになっているとのことだった。

5.4.3 ハリウッドからの受注の可能性について
欧州の VFX プロダクションが二極化しているように、ハリウッドからの仕事を受注できるかできないかがプロダクションの規模に大きく影響する。
そのハリウッドからの受注フローには大きな変化が起こっていることが分かった。今まではハリウッドのスタジオが、VFX プロダクションに仕事を割り振っていたが、それではスタジオのマネジメントが大変なため、最近は、ハリウッドのスタジオから包括的にマネジメントとクオリティ管理をしてくれる大手の VFX プロダクションに仕事が割り振られ、そこから中小の VFX プロダクションに流れているとのことである。
そうした仕事を獲得するためには、VFX スーパーバイザー又は VFX プロデューサーの信頼を勝ち取ることが重要となる。まずはデモリールによる実績の確認がされ、それからある程度の規模の仕事の受注が可能かどうか。また同地域に教育機関や VFX プロダクション
が他にもあるかなどがあるといったことや、IT セキュリティや機密事項の取り扱いなどを確認される。ただし最も重要なことはクオリティや納期とのことである。またクライアン
トであるスタジオから税制優遇を利用して欲しいという注文があるケースもあるとのことである。
実際に発注される場合、まずは小規模な仕事が発注され徐々に発注量が増えていくとのことであった。
しかしながら、日本のプロダクションに対するイメージは、日本人に優秀なアーティス
トがいるということは認められている一方、日本のプロダクションは残念ながらほとんど注目されていなかった。理由としては、コストが高い（と思われている）ことや、英語を母国語としないためのコミュニケーションの問題などが挙げられた。
また最初に用意するデモリールについても海外の場合、大手からの下請けであっても自分たちの手がけた部分を明確にわかるようにして、確認を取ることで利用できるが、日本の場合はデモリールを WEB 等にアップロードして自社の PR をすることも難しいという現221

実もある。
実際に受注する際には一緒に仕事をした実績はとても重要な要素になることから、大手
VFX プロダクションの VFX スーパーバイザーに日本人がなるというのも一つの選択肢だが、実際には非常に難しい。
そのため海外の実績のある日本人を日本のプロダクションに呼び戻すということも一つの手法であり、その受け皿として海外の大手プロダクションの支社を日本に誘致することも考えられる。
税制優遇というのはそうしたプロダクションの誘致の際の大きな動機づけとなる。こうした税制優遇は海外でも州政府規模で実施している場合もあり、日本の場合も都道府県や市町村といった地域レベルでそうした活動ができないかを検討する必要がある。

5.4.4 取り組むべき課題
今後の発展の為に早急に解決すべき問題は、CG・VFX 業界が世界発信する為のデモリー
ルのオープン化、また海外からの優秀な人材を受け入れる為のビザ供給の緩和などが挙げられる。また、海外のプロデューサーやクライアント向けの海外プレゼンテーションの企
画、産学連携の人材育成、外国語（英語）を使いこなすことが出来るプロデューサーの育成、海外からの帰国組の雇用による経験則やコネクションの拡張、海外プロダクションの誘致、制作管理による合理化や独自の映像開発を行うことによるクオリティのアップなどを積極的に行っていく必要がある。

222

第6章

まとめ

本事業では、アニメーションや映画を始めとする日本の映像コンテンツ世界的な人気を背景に、近年ますます需要の増えてきたコンピューターグラフィックス（CG）を利用した
映像視覚効果（VFX）やアニメーション制作産業を対象に調査検討を行った。
日本国内は従来から小規模な映像制作会社が多く、それらの会社が連携しながら特徴ある映像作品を生み出してきた。しかし、近年は世界規模で CG や VFX などの映像表現の質と量の両面において需要が拡大しており、それに伴いプロジェクトの規模も大きくなっている。国内においても、求められる制作・加工の業務量の増加や海外の業務の受注などを視野に、従来のジェネラリストによる制作から、スペシャリストに特化した制作への変革の必要性と、それに伴う制作管理体制の強化がしばしば議論されるようになってきた。また、映像表現の高度化と業務量の増加に伴い、映像を高品質で制作・加工するためのシス
テム投資が膨大となり、特に制作の終盤に負荷が集中するレンダリングでは、遠隔地のサーバ利用やクラウドコンピューティングの必要性も議論されるようになってきた。
このような状況を受けて、本事業では日本国内の CG・VFX の現状の業務形態を調査すると共に、国際的な協業を視野に入れた「制作工程管理システム」のあり方や、「クラウド
コンピューティングを活用した、レンダリングサービスの有用性」を重点的に調査することとした。さらに、CG・VFX 業界の共通基盤の整備のため、必要となる機能、規模、運用方法等について検討を行うと共に、必要な仕様を提案し、我が国のコンテンツの国際競争力向上と発展に寄与することを目指した。
本事業に際しては CG や VFX 企業に加え、アニメ制作会社、ゲーム開発会社、システムインテグレーター、ソフトウェア販売会社など、多岐にわたる業種から委員並びにオブザーバが参加した。そのため、多岐にわたる CG や VFX 関連産業について、多様な業態の現状を横断的に理解できた。

(1)

日本の制作プロダクションの大半は小規模で協働作業

第 2 章の「カテゴリ別制作本数実態調査」では、CG や VFX が必要とされるコンテンツ
をカテゴリごとに分けて、それぞれのカテゴリのプロジェクトの予算規模や期間、関わる
人数、さらには外注の比率などについて調査した。この調査の結果、日本の制作が比較的小規模のチームで実施されていることが確認できた。また、多くのケースで多数の外注企業が存在していることが分かった。そのため、大規模な制作案件では、「制作工程管理」や「クラウドレンダリング」については、各プロダクションの独自の事情のみでなく、協業する他のプロダクションとの連携についても考慮して設計する必要があることが明らかに
なった。

223

(2)

スケーラブルな制作工程管理システムの導入と基盤部分の標準化

第 3 章の「制作工程管理システム」の調査では、現在利用可能な市販又は無償の制作工
程管理システムについて、比較検討した。また、主要なシステムに関しては、実際に運用することでそのシステムの機能や導入における課題などについて明らかにした。この調査の中で、制作管理システムに関わるコストとして、初期導入コストのみでなく、ランニン
グコスト（製品のメンテナンスや運用のためのスタッフの人件費や外注費）が必要になることが分かった。また、近年北米のプロダクションでの導入事例の増えている Shotgun な
どの多機能なシステムを導入する場合も、メンテナンスのための人材が必要であることが分かった。
また、既に独自で制作管理システムを開発している企業にヒアリングを行い、各社の開発したシステムの機能、開発体制や、メンテナンスの体制などについて調査した。さらに、手描きの素材が多く含まれるアニメの制作プロダクション各社にもヒアリングを行い、ア
ナログ素材とデジタル素材の同時管理という課題が存在していることが確認できた。その結果、アニメ制作会社の中でも電子的な制作工程管理システムを運用している会社もある
が、それらのシステムも基本的にはデジタル素材のみを対象としていることも明らかになった。
こうした、各社の事例調査から、制作工程管理システムを導入する場合は、そのプロダクションやプロジェクトの人数規模が目安になることが分かった。10 名前後の小規模のプ
ロジェクトからディレクトリの命名規則などを管理するシステムが必要となり、30 名規模
ではアセット管理、100 名程度からプロジェクト管理と、規模に応じて必要な機能を検討していくことが重要であることが分かった。これは第 5 章の海外ヒアリングでも同様である
ことが確認されており、国や地域の違い以上に、制作会社の規模による差異が大きいことが確認できた。
市販の製品や各社独自の開発の事例が増える一方で、プロダクションの規模に応じて管理体制を移行したり、様々な企業との協業を容易にしたりする上でも、システム間での情報のやり取りや、移行が簡易になるような共通の基盤整備の重要性が確認できた。
その重要性はこの章で記載したシネマ用カメラのメタデータの調査でも明らかになった。
多くのメーカーがカメラの様々なメタデータを記載しており、VFX 制作作業の際に有用なデータも多い。しかし、それらのメタデータは各社独自の仕様によって記載されている。
これらを変換しながら連携するためのシステムなどを整備することで、独自性のあるパラメータを有したカメラであっても、その情報を容易に活用できるようになると考えられる。

224

(3)

クラウドレンダリングのカギはソフトウェアライセンスと高速ネットワーク

第 4 章「クラウドを活用したレンダリングシステム」では、大規模プロダクションだけ
でなく、数十人規模のプロダクションや東京以外の地域のプロダクションとの連携にも効果が見込まれるクラウドレンダリングシステムについて検討した。レンダリングに必要なリソースが増加する中、作業のピーク時に必要なリソース量に合わせた設備投資は、定常的な管理コストの増加を招き、プロダクションの経営を圧迫し、次の投資への動きを鈍らせてしまう。また技術面でもシミュレーション利用の増加や高解像度、高フレームレート化によって、レンダリングコストは更に増加する傾向にある。これらについて、クラウド
コンピューティングを活用することで設備投資の負担を軽減できる可能性に着目し、実証実験を行った。
まず始めに制作プロダクションの協力のもと、現状の作業環境とレンダリング環境について調査を行った。その中では、クラウドと同様に遠隔地のサーバを利用してレンダリングを行った事例を基に、課題を明らかにした。また、海外で既にクラウドを活用したレンダリングの事例があることから、これらについても現状を調査した。
これらの調査を基にクラウドを活用したレンダリングシステムの実証実験を行い、レンダリング管理システムの動作、レンダリングの速度、転送にかかる時間や、想定された問題に対しての対策などについて確認することができた。
調査の結果、今後実用化に向け、ソフトウェアのライセンスが課題となることが分かった。第 4 章の現状調査の結果の通り、現在制作プロダクションで主流として利用されている 3DCG ソフトウェアはクラウドを活用したレンダリングシステムには対応していない。
遠隔地に所在する自社が所有する機材でのレンダリングや、自社で契約したレンダリング
サーバを利用する場合は対応できるが、クラウドを利用したレンダリングシステムでは利用できない。これはソフトウェア開発会社の使用許諾で規定されており、一ユーザーの要
望だけでは変更は難しく、日本の業界全体として働きかけをしていく必要がある。一方、
レンダラ単体であれば、多くの場合クラウドレンダリングに対応したライセンス設定となっており、既に活用が可能である。
クラウドレンダリングに際してはデータの転送が必須であり、ネットワーク転送の速度も問題となる。様々な工夫やパイプラインの構築により必要となるデータを絞ることで、ある程度は転送する帯域を減らすことはできるものの、ある程度のネットワークの速度は必要になる。
第 5 章の海外調査でも触れているが、海外のプロダクションでは「Dark Fiber」と呼ばれる独立した高速回線をサーバへのデータ転送などに利用しているケースが多い。
このようなインフラをクラウドの形体で共有することは、多くのプロダクションのメリッ
トにつながる今後の課題であると言える。こうした特殊なネットワーク環境はクラウドを含めた遠隔レンダリングで課題となる、データのセキュリティにも大きく関連する。制作225

プロダクションの多くは自社の制作データを社外と通信することによる漏えいのリスク縮減を課題と考えている。これを、それぞれが独自に取り組むよりもクラウドサービスに集約することで改善できる可能性がある。

(4)

二極化する海外の事情（北米や欧州との相違）

第 5 章の海外調査では、北米（ロサンゼルス、サンフランシスコ、バンクーバー）と欧州（ロンドン、パリ、ヴァランシエンヌ）のプロダクションを訪問した。それぞれの地域
で大規模なプロダクションから小規模なプロダクションまで、幅広くヒアリングを行った。
その結果、大規模な制作工程管理システムやパイプラインを整備、保持しているのは、ハリウッドの劇場作品などのプロジェクトを受注している比較的大規模なプロダクションであることが分かった。そして、これらのプロダクションでは、制作工程管理やパイプラインに関わるエンジニアのチームを多く抱え、専門の部署を設けてその対応に当たっている。一方、北米でも欧州でも、ハリウッドの劇場作品を受注しないプロダクションは、たとえプロダクションの人数が多くても一つのチームのサイズが小さくなる。そのため、小規模なエンジニアチームや兼任のエンジニアが、第 3 章で取り上げたような市販の制作工程管理システムをうまくカスタマイズすることで、自社のスケールとワークフローに合わせて運用している。さらに、小規模なプロダクションでは、汎用性の高い Excel や Google
Document、Wiki などを利用するケースもみられる。
欧州では北米に比べて制作プロダクションの二極化が顕著であることが分かった。欧州
でも、ハリウッドの映画を受けるプロダクションは 120 名以上の規模が必要と述べており、そうした一部のプロダクションは制作工程管理システムや強固なパイプラインを有している。そしてそれらのプロダクションは、次々に受注を繰り返しプロダクションの規模が大きくなっている。しかし、多くの欧州のプロダクションでは、日本の中小規模のスタジオと同じような規模でジェネラリストが中心となっていた。

(5)

国際的な業務の受注と世界を巻き込む制作チェーン

昨今では税制優遇やインフラの提供など、何らかの形でインセンティブのある地域へのプロダクションのシフトが進んでいる。そのようなインセンティブだけでは持続的効果は小さいが、人材の供給や生活の環境、時差など様々な条件が整った地域であれば成功しやすい。カナダのバンクーバーはこれらのインセンティブを利用して、CG や VFX の中核的な都市となることができた。シンガポールや台湾などは時差の壁を越えて、ネットワーク
インフラや施設を充実させることでハリウッドの業務を引き寄せている。
国内プロダクションが、海外から仕事を得る上で、重要視すべき点は何より制作のクオ226

リティである。そのためには、日本の CG や VFX プロダクションは自社が手掛けた作品やオリジナル作品のデモリールの高品質化が重要である。制作に携わった作品のデモリール
での利用に際して、欧米のように極力契約段階から権利を調整し、自由な裁量を確保することも国際競争に際して重要であることが分かった。
また、上記のような海外からの業務の受託だけではなく、日本が主体となるプロジェク
トにとっても、制作工程管理や、レンダリング体制の強化は重要である。特に東南アジア
をはじめとした新興国を巻き込んで、ビジネス展開や共同制作を進めるケースは今後増大していくと考えられる。その際に、既にこれらの新興国が海外の仕事を受注していることからも、国際的なビジネス形態に合わせた制作工程管理手法やシステムを持ち、国際的な協業が容易に実現できることは日本の制作プロダクションにとって重要になる。また、このような共同制作においては、品質面の保持のためにも、データの転送速度やセキュリテ
ィ対策を十分に講じたレンダリング環境の整備が重要である。これらの整備は、日本を主体とした国際的な映像制作チェーンの構築を可能にし、日本の映像産業が協業によって国際的な競争力を維持するために必要な対策であると考えられる。

(6)

今後に向けてCG・VFX 業界の発展のためには、CG・VFX 業界が世界発信する為のデモリールのオー
プン化、また海外からの優秀な人材を受け入れる為のビザ供給の緩和などが挙げられる。
また、海外のプロデューサーやクライアント向けの海外プレゼンテーションの企画、産学連携の人材育成、外国語を使いこなすことが出来るプロデューサーの育成、海外からの帰国組の雇用による経験則やコネクションの拡張、海外プロダクションの誘致、制作管理による合理化や独自の映像開発を行うことによるクオリティのアップなどを積極的に行っていく必要がある。そしてそれらのことを達成する為の支援が必要であると思われる。
今回の調査を通じて、国際的な CG、VFX の進展の流れに我が国の産業界が同調し更に発展していくには、日本の制作プロダクションの特徴を生かしつつ、国際的な受発注に対応できるような制作管理システムの基盤整備が重要であることが明らかになった。各社の実情に合わせた、段階的なシステム導入においてもスケーラブルに対応できるような仕組みが必要である。さらに、各社の独自の制作管理体制を許容しながら、他社のシステムや管理手法と互換性を保てるような仕組みも重要である。そのためにも、用語の統一や管理項目の共通タグ化など基盤的な整備を産業界全体で図っていく必要がある。
また、様々な規模のプロダクションが、スケーラブルに利用できるようなクラウドレン
ダリングサービスの環境は、プロジェクトや進捗段階により必要なリソースが異なる CG、VFX 産業において有効な仕組みである。そのためにも、インフラの整備やソフトウェアのライセンスの問題など解決すべき課題が多くある。

227

付属資料索引【資料 1】メタデータ統合 ...................................................................................... 229【資料 2】ARRIRAW メタデータ .......................................................................... 232【資料 3】RED ONE/EPIC メタデータ................................................................. 233【資料 4】Sony F65RS メタデータ........................................................................ 235【資料 5】Canon EOS C500 RAW （.RMF）メタデータ.................................... 236【資料 6】EOS C500 RAW （XML）メタデータ................................................. 237【資料 7】XF/XA/C300/C500 MXF （.MXF）メタデータ .................................. 238【資料 8】XF/XA/C300/C500 MXF （.CIF）メタデータ .................................... 239【資料 9】XF/XA/C300/C500 MXF （XML）メタデータ.................................... 240【資料 10】Autodesk FBX KFbxCamera クラス ................................................. 241【資料 11】EXIF 2.3 メタデータ ........................................................................... 243【資料 12】既存ソフトウェア比較表 ..................................................................... 245

228

【資料 1】メタデータ統合
TimeCode 開始

Sony
Start
開始タイムコード

ARRI
RED
LTC_TC_perFrame
Abs TC
タイムコード開始タイムコード
LTC_UB_perFrame
LTC の User Bits を使ったタイムコー
ド
End Abs TC
終了タイムコード

TimeCode 終了

End
終了タイムコード

デュレーション

Duration
デュレーション

アスペクト比Aspect Ratio
アスペクト比フレームレート

Format fps
フレームレート
Capture fps
1 秒当たりの撮像フレーム数

Fps_perFrame
フレームレート
SensorFps_perFrame
センサーフレームレート
ProjectFps_perTake
プロジェクトフレームレート

ドロップフレーム

Drop Frame
ドロップフレームの有無
Resolution
解像度

Dropped Frame Count
ドロップフレーム数（ARRIMetaExtract 1.6.2 では表示さ Resolution
解像度
れないが、情報は存在する）

シャッタースピード

Shutter Speed Angle
シャッター開角度（分）Angle_perFrame
シャッター角度
ShutterAngle_perFrame
シャッター角度
Shutterangle_perTake
シャッター角度ISO 感度ISO Sensitivity
ISO 感度ISO
ISO 感度

色温度

White BalanceWhiteBalance_perTake
色温度（K）で表したホワイトバランス 色温度の設定値

Kelvin色温度

撮影距離

Focus Distance
最短撮影距離（集束距離）
Near Focus Distance
焦点範囲の開始端Far Focus Distance
焦点範囲の終了端

FocusDistance_perFrame
最短撮影距離（集束距離）
FocusUnit_perTake
最短撮影距離（集束距離）

Focas Distance
焦点距離

露出（絞り）

Exposure Index
ライトメータに設定する EI 値

ExposureIndex_perTake

露出インデックス

Exposure
絞り

Aperture Scale Setting
絞り目盛の設定
Aperture Value
アパーチャー

Aperture_perFrame
アイリス（T ストップの値）

Aperture
アパーチャー

解像度

アパーチャー

ExposureTime_perFrame
露出時間(ms/10)

Duration
デュレーション
Media Duration
メディア・デュレーション
Aspect Ratio
アスペクト比Aspect Ratio Numerator
アスペクト比 の分子
Aspect Ratio Denominator
アスペクト比の分母
Pixel Aspect Ratio
ピクセルのアスペクト比
Frame Rate
フレームレート
Record Frame Rate
記録時のフレームレート

Shutter(deg)シャッター角
Shutter(ms)シャッタースピード(ms)Shutter(1/sec)
シャッタースピード(1/sec)

229

Canon
RAW XML - StartTimecode
クリップの先頭タイムコード
CIF - Start_Time_Code
クリップ先頭タイムコード

FBX

RAW XML - StopTimecode
クリップの最終タイムコード
CIF - Stop_Time_Code
クリップ末尾タイムコード
RMF XML - VideoFrameCount
ビデオフレーム数（RAW ファイル数）

CIF - Aspect_Ratio
アスペクト比RMF - Playback_Frame_Rate
再生フレームレート
RMF - Capture_Frame_Rate
キャプチャフレームレート
CIF - Frame_Rate
ビデオフレームレート
Variable_Frame_Rate
バリアブルフレーム記録時の fps

AspectRatioMode
アスペクト比のモード
AspectWidth
カメラのアスペクトの幅
AspectHeight
カメラのアスペクトの高さ
PixelAspectRatio
ピクセルのアスペクト比（レンダリング時に指定）（レンダリング時に指定）
RMF - Capture_Height（レンダリング時に指定）
現像後の有効画像高さ
RMF - Capture_Width
現像後の有効画像幅
CIF - Video_Format
ビデオ解像度RMF - Shutter_Speed_Angle
シャッタースピード(度単位)
RMF - Shutter_Speed_Time
シャッタースピード(sec)
RMF - Shutter_Speed_Hz
シャッタースピード(Hz 単位)
RMF - Shutrter_Speed_Mode
秒/角度/周波数
MXF - Shutrter_Set_Mode
シャッタースピードの設定モード
MXF - Shutter_Speed
秒単位のシャッタースピード(sec)
MXF - Shutter_Value
角度又は周波数単位のシャッタースピー
ド
RMF - ISO_Speed
ISO 感度設定値
MXF - ISO_Speed
ISO 感度設定値
RMF - WB_Mode
ホワイトバランス設定モード
RMF - WB_Preset
ホワイトバランスのプリセットモード
RMF - Color_Temperature
色温度
MXF - WB_Mode
ホワイトバランス設定モード
MXF - WB_Preset
ホワイトバランスのプリセットモード
MXF - Color_Temperature
色温度
CIF - WB_Mode
ホワイトバランス設定モード
CIF - WB_Preset
ホワイトバランスのプリセットモード
CIF - Color_Temperature
色温度
RMF - Focus_Mode
FocusSource
フォーカスモード
フォーカスソースのタイプ
RMF - Focus_Position
FocusAngle
被写体までの距離（m）※C500 未使用
焦点の角度
MXF - Focus_Mode
FocusDistance
フォーカスモード
焦点距離
MXF - Focus_Position
被写体距離（m）
RMF - F_Number
FilmWidth
絞り値
カメラのレンズ絞りの幅
MXF - F_Number
FilmHeight
絞り値
カメラのレンズ絞りの高さ
FilmAspectRatio
カメラのレンズ絞りのアスペ
クト比
FilmSqueezeRatio
カメラのレンズ絞りの圧縮比
FilmFormat
カメラのレンズ絞りのフィル
ムフォーマット
ApertureMode
絞りモード

焦点距離

Sony
Effective Focal Length
有効焦点距離 (EFL)
Hyperfocal Distance
過焦点距離

ARRI
FocalLength_perFrame
焦点距離、1/1000mm 単位

ガンマ

CDL Power
SxSGamma_perTake
ASC CDL V1.2 の Power 値(RGB)SxS カラーガンマ
Gamma For CDL
ASC CDL を適用するカラースペース
の名称

ゲイン

CDL Slope
ASC CDL V1.2 の Slope 値(RGB)シフト

CDL Offset
ASC CDL V1.2 の Offset 値(RGB)

カーブ

彩度

CDL Saturation
ASC CDL V1.2 のサチュレーション
(彩度)

色合い

WhiteBalanceTint_perTake
緑/マゼンダの色合い調整

コントラストブライトネスデノイズ
ND フィルタ

Focal Length
撮影距離

RED

LGG: Gamma: Red
LGG：ガンマ：赤LGG: Gamma: Green
LGG：ガンマ：緑
LGG: Gamma: Blue
LGG：ガンマ：青Gamma Space
ガンマスペース
Red Gain
ゲイン(赤)
Green Gain
ゲイン(緑)
Blue Gain
ゲイン(青)
LGG: Gain: Red
LGG：ゲイン：赤LGG: Gain: Greem
LGG：ゲイン：緑
LGG: Gain: Blue
LGG：ゲイン：青LGG: Lift: Red
LGG：リフト：赤LGG: Lift: Green
LGG：リフト：緑
LGG: Lift: Blue
LGG：リフト：青Curve: Luma
カーブ：輝度Curve: Red
カーブ：赤Curve: Green
カーブ：緑
Curve: Blue
カーブ：青

RMF - ND_Filter
ND フィルタ状態
MXF - ND_Filter
ND フィルタの減光率
RMF - Infra_Red_Mode
赤外線撮影モード状態
MXF - IR_Status
赤外線撮影モード状態
CIF - IR_Mode_Flag
赤外線撮影モード状態
RMF - Image_Stabilizer
手ぶれ補正状態
MXF - Image_Stabilizer
手ぶれ補正状態
RMF - Electric_Zoom
電子ズーム拡大率
MXF - Electric_Zoom
電子ズーム拡大率

赤外線

手ぶれ補正

電子ズーム

Horizontal Field Of View
水平画角

カメラ情報

Cameraカメラ識別子Camera Attributes
カメラの機種名とシリアル番号

CameraModel_perTake
カメラモデル名
SerialNumber_perTake
カメラのシリアルナンバー
CameraID_perTake
固有のカメラ ID

FocalLength
焦点距離

FBX

Tint
色合い
Contrast
コントラストBrightness
ブライトネスDenoiseデノイズ

ND Filter Wheel
内蔵 ND フィルタの透過率

画角

Canon
RMF - Focal_Length
焦点距離
RMF - Focal_Length_35mm
35mm フィルム換算値
MXF - Focal_Length
35mm 換算の焦点距離(mm)RMF - Gamma_Setting
ガンマ設定値RMF - Log_Gamma_Type
ログガンマの種類
CIF - Log_Gamma_Flag
Log ガンマ設定モード
CIF - Gamma_Setting
Log ガンマの種類
MXF - Gain_Mode
ゲイン設定のモード
Master_Gain
マスターコントロールのゲイン値
Master_Gain_Delta
マスターコントロールのゲイン値

Camera Model
カメラモデル名
Camera Model ID
カメラ ID
Camera Network Name
カメラのネットワーク名
Camera PIN
カメラの PIN コード
Media Serial #シリアルナンバー

230

RMF - Device_Model_Name
カメラのモデル名
RMF - Device_Firmware_Version
カメラのファームバージョン
RMF - Device_Serial_Number
カメラのシリアル番号
RMF XML - Manufacturer
デバイスメーカー名（"CANON")RMF XML - SerialNo
デバイスのシリアル番号
RMF XML - ModelName
デバイスのモデル名
RMF XML - FirmVersion
デバイスのファームウェア・バージョン
CIF - Maker_Name
デバイスメーカー名
CIF - Model_Name
デバイスモデル名
CIF - Serial_Number
デバイスシリアル番号
CIF - Firm_Version
ファームウェア・バージョン
MXF XML - Manufacturer
デバイスメーカー名（"CANON")MXF XML - SerialNo
デバイスのシリアル番号
MXF XML - ModelName

PreScale
デジタル的なカメラズーム

FieldOfView
視野角
FieldOfViewX
視野角 X 値
FieldOfViewY
視野角 Y 値

Sony

ARRI

レンズ情報

Lens Attributes
レンズのシリアル番号

日時

Creation Date
UserDate_perTake
作成日
収録日
Last Update
UserTime_perTake
最終更新日
収録時間
UMID
MediaUUID_perTake
ソニーF65 カメラメタデータセットの クリップの UUID
識別子

Date
日付

リール名

*Reel
リール番号

カメラ番号

*Camera Index
CameraIndex_perTake
撮影したカメラを識別するためのイン カメラインデックス (A...Z)
デックス

Reel
リール番号
Reel ID Full
リール ID（フルサイズ）
Reel ID 8 Character
リール ID（8 文字）

固有 ID

LensType_perTake
レンズ名LensSerialNumber_perTake
レンズのシリアルナンバー

RED

ReelName_perTake
SxS リール名

クリップ番号
クリップ名
プロダクション名
監督名
撮影監督名
プロジェクト名
サークル名
シーン名
カット名
テイク名
ショット名
説明

場所
カメラのチルト
カメラのロール
カメラのパン
カメラの X 座標
カメラの Y 座標
カメラの Z 座標
GPS 高度GPS 経度GPS 緯度*Production
プロダクションハウスの名称*Director Name
監督の名前
*Director Of Photography Name
撮影監督の名前*Project
プロジェクトの名称*Circle
サークル名*Scene
シーン番号
*Cut
カット番号
*Take
テイク番号
*Shot
ショット番号*Description
コメントエリア

ProductionName_perTake
プロダクション名
CinematographerName_perTake
ディレクター名
DirectorName_perTake
撮影ディレクター名

Lens
レンズ
Lens Mount
レンズマウント
Lens Height
レンズ高

Clip
クリップ番号
Name
クリップ名
Production Name
プロダクション名
Director
ディレクター名
Director Of Photography
撮影ディレクター名
Project
プロジェクトCircle
サークル名
Scene
シーン

Take
テイク
Shot
ショット
Scene Description
シーン説明

LocationName_perTake
撮影場所
VfxTilt_perFrame
カメラのチルト角
VfxRoll_perFrame
カメラのロール角VfxPan_perFrame
カメラのパン角
VfxX_perFrame
カメラの X 座標
VfxY_perFrame
カメラの Y 座標
VfxZ_perFrame
カメラの Z 座標

Location
場所

Canon
デバイスのモデル名
MXF XML - FirmVersion
デバイスのファームウェア・バージョン

RMF - Lens_ID
レンズ IDRMF - Lens_Name
レンズ名
RMF - Lens_Serial_Number
レンズののシリアル番号
RMF - Lens_Type
レンズの種類RMF - Focal_Length_Tele
レンズの望遠端の焦点距離
RMF - Focal_Length_Wide
レンズの広角端の焦点距離
RMF - AV_Open
レンズの解放絞り値の F ナンバー
RMF - AV_Minimum
レンズの最小絞り値の F ナンバー
RAW XML - Lens
装着されているレンズ名
RAW XML - DateAndTime
クリップが作成された日時
CIF - Record_Time_And_Date
クリップ作成日時
RMF - Related_Clip_ID
関連クリップのクリップ ID
RAW XML - ClipID
クリップの UID231

FBXHeaderExtension:Creatio
nTimeStampRMF - Related_Clip_Name
関連クリップのクリップ名

RAW XML - Description
クリップのコメントや説明など
MXF XML - Description
クリップのコメントや説明など
MXF XML - PlaceName
撮影場所情報MXF XML - Altitude
高度
MXF XML - Longitude
経度
MXF XML - Latitude
緯度

GpsLongitude_perFrame
経度
GpsLatitude_perFrame
緯度FBX

FBXHeaderExtension:SceneI
nfo:MetaData:Comment:

UpPosition
上方向の XYZ 座標指定
Roll
ロール角
InterestPosition
注視点 XYZ 座標
Position
XYZ 座標Position
XYZ 座標Position
XYZ 座標【資料 2】ARRI RAW メタデータ
番号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

タグ
FrameNum_perFrame
LTC_TC_perFrame
LTC_UB_perFrame
Proj_TC_perFrame
Proj_TC_w_Offset_perFrame
Fps_perFrame
Angle_perFrame
Flags_perFrame
SysImageCreationTime_perFrame
UserDate_perFrame
ExposureTime_perFrame
ShutterAngle_perFrame
SpeedRampStartFrame_perFrame
SpeedRampEndFrame_perFrame
SensorFps_perFrame
Master_TC_perFrame
Ext_LTC_FreeRun_perFrame
Ext_VITC_FreeRun_perFrame
IntFreeRunToD_TC_perFrame
IntFreeRunUserDefined_TC_perFrame
RecRunEdgeCode_TC_perFrame
RecRunClipCode_TC_perFrame
RecRunRegen_TC_perFrame
DigitalKeykode3_2_1_0_perFrame
FocusDistance_perFrame
FocalLength_perFrame
Aperture_perFrame
GpsLatitude_perFrame
GpsLongitude_perFrame
VfxX_perFrame
VfxY_perFrame
VfxZ_perFrame
VfxPan_perFrame
VfxTilt_perFrame
VfxRoll_perFrameWhiteBalance_perTake
WhiteBalanceTint_perTake
ExposureIndex_perTake
SxSGamma_perTake
ActiveLookFile_perTake
LookFileApplied_perTake

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

Sensorfps_perTake
Shutterangle_perTake
CameraModel_perTake
SerialNumber_perTake
CameraSupVersion_perTake
CameraID_perTake
CameraIndex_perTake
ProjectFps_perTake
SxSSerialNumber_perTake
ProductionName_perTake
CinematographerName_perTake
DirectorName_perTake
LocationName_perTake
UserInfo1_perTake
UserInfo2_perTake
UserDate_perTake
UserTime_perTake
MasterSlaveInfo_perTake
EyeIndex_perTake
ReelName_perTake
SoundReel_perTake
LensType_perTake
FocusUnit_perTake
LensSerialNumber_perTake
MediaUUID_perTake

説明
カメラ起動後からのフレーム番号
タイムコードLTC の User Bits を使ったタイムコード- future use - future use フレームレート
シャッター角度- future use - future use - future use 露出時間(ms/10)
シャッター角度- future use - future use センサーフレームレート- future use - future use - future use - future use - future use - future use - future use - future use - future use 最短撮影距離（集束距離）、FocusUnit_perTake の 1/1000
焦点距離、1/1000mm 単位
アイリス（絞り）（T ストップの値）- future use - future use - future use - future use - future use - future use カメラのチルト角
カメラのロール角
色温度
緑/マゼンダの色合い調整
露出インデックス
SxS カラーガンマ
ARRI ルックファイル名（ARRI LOOK Creator 用?）
QuickTime の ProRes 内に生成された ARRI ルックファイル
名センサーフレームレート
シャッター角度カメラモデル名
カメラのシリアルナンバー
ソフトウェアバージョン
固有のカメラ ID
カメラインデックス (A...Z)
プロジェクトフレームレート
SxS カードシリアルナンバー
プロダクション名
ディレクター名
撮影ディレクター名
撮影場所
その他のユーザー情報 1
その他のユーザー情報 2
収録日
収録時間
2D/3D 用設定：OFF, MASTER, SLAVE
2D/3D 用設定： SINGLE, LEFT, RIGHTSxS リール名
AUDIO > OPTIONS > Soundroll
レンズ名
最短撮影距離（集束距離）、メートル又はフィート
レンズのシリアルナンバー
クリップの UUID

232

【資料 3】RED ONE/EPIC メタデータ
番号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

タグ
Name
Filename
Path
Camera
Clip
Reel
Date
Abs TCEnd Abs TC
Duration
FramesResolution
Frame Rate
Record Frame Rate
Rating
REDCODEHDR Mode
HDR Stops Over
Shutter(deg)Camera Model
Camera Model ID
Camera Network Name
Camera PIN
Dropped Frame CountMedia Serial #Sensor Name
Sensor ID
Aperture
Focal Length
Focas DistanceLens
Lens Mount
Lens HeightTimestamp
Edge TC
End Edge TC
Media Duration
Clip In
Clip Out
Poster Frame
Notes
Owner
Project
Scene
Shot
Take
CircleCopyright
Script Notes
Camera Notes
Edit Notes
FilterScene Description
Unit
Production Name
Location
Director Of Photography
Director
Camera Operator
Audio Timecode
Audio
Audio Slate
Video Slate
Audio Scene
Audio Take
Audio Tape
Audio Note
Frame Guide X
Frame Guide Y
Frame Guide Width
Frame Guide Height
Flip Horizontal
Flip Vertical
Aspect Ratio
Aspect Ratio Numerator

タイプ
stringstringstringcharacterstring (length:3)
string (length:3)
string (length:8)
TCTC
TC
integer
width x height
float
float
integerstring
enum
float
float
stringintegerstringstringintegerstringstringstring
float
float
float
stringstringfloat
integerstringstringstringinteger
integer
integerstringstringstringstringstringstringstringstringstringstringstringstringstringstringstringstringstringstringstringstring?
integer
integerstringstringstringstring
float
float
float
float
integer
integerfloat
integer

233

説明
クリップ名
ファイル名
保存先パス名
カメラ識別子クリップ番号
リール番号
日付
開始タイムコード
終了タイムコード
デュレーション
フレーム数
解像度
フレームレート
記録時のフレームレート
重要度
REDCODE のタイプ
HDR モード
HDR で露出を上げた段数
シャッター角カメラモデル名
カメラ ID
カメラのネットワーク名カメラの PIN コード
ドロップフレーム数
シリアルナンバー
センサー名
センサーID
アパーチャー
焦点距離
撮影距離
レンズ
レンズマウント
レンズ高タイムスタンプ
開始エッジタイムコード
終了エッジタイムコード
メディア・デュレーション
クリップ開始フレーム番号
クリップ終了フレーム番号
ポスター画像フレーム番号
メモ
オーナー
プロジェクト
シーン
ショット
テイク
サークル
著作権情報
スクリプターメモ
カメラメモ
エディットメモ
フィルタ
シーン説明
ユニット
プロダクション名場所
撮影ディレクター
ディレクター
カメラ・オペレーター
音声タイムコード
音声
音声スレート
映像スレート
音声シーン
音声テイク
音声テープ
音声メモ
フレームガイド X 座標
フレームガイド Y 座標
フレームガイド幅
フレームガイド高さ
水平フリップ垂直フリップ
アスペクト比アスペクト比の分子

番号
76
77
78
79
80
81
82
83
84
85
86
87
88
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127

タグ
Aspect Ratio Denominator
3d Offset
3d XOR
Frame Guide Name
Genlock Setting
Jamsync Setting
Linked Camera Setup
Pixel Aspect Ratio
Stereo Setup
Firmware Version
Firmware Revision
Camera Audio Channels
File Segments
Shutter(ms)Shutter(1/sec)
Lock Name
KelvinTint
Exposure
Red Gain
Green Gain
Blue Gain
Contrast
Brightness
DRX
FLUT
Shadow
LGG: Lift: Red
LGG: Lift: Green
LGG: Lift: Blue
LGG: Gamma: Red
LGG: Gamma: Green
LGG: Gamma: Blue
LGG: Gain: Red
LGG: Gain: Green
LGG: Gain: BlueISO
Gamma Space
Color Space
Curve: Luma
Curve: Red
Curve: Green
Curve: Blue
DetailOLPFCompensation
Denoise
Label
Reel ID Full
Reel ID 8 Character
Original Filename

タイプ
integer
integer
integerstring
enum
enum
enum
float
enum
stringstringinteger
integer
integer
integerstringinteger
integer
float
float
float
float
float
float
float
float
float
float
float
float
float
float
float
float
float
float
integer
enum
enum
配列
配列
配列
配列
enum
on/offon/offstringstringstring (length:8)
string234

説明
アスペクト比の分母
3D オフセット3D XOR
フレームガイド名
Genlock 設定
Jamsync 設定
Linked Camera 設定
ピクセルのアスペクト比
ステレオセットアップ
ファームウェア・バージョン
ファームウェア・リビジョン
カメラオーディオのチャンネル数
ファイルセグメント
シャッタースピード(ms)シャッタースピード(1/sec)
ロック名
色温度
色あい
絞り
ゲイン(赤)
ゲイン(緑)
ゲイン(青)
コントラストブライトネス
DRX 機能（ハイライトリカバリー）
浮動小数点ルックアップテーブル
シャドウ
LGG：リフト：赤LGG：リフト：緑
LGG：リフト：青LGG：ガンマ：赤LGG：ガンマ：緑
LGG：ガンマ：青LGG：ゲイン：赤LGG：ゲイン：緑
LGG：ゲイン：青ISO 感度ガンマスペース
カラースペース
カーブ：輝度
カーブ：赤
カーブ：緑
カーブ：青
ディテール
OLPF(Optical Low Pass Filter)補償
デノイズ
ラベル
リール ID（フルサイズ）
リール ID（8 文字）
オリジナルファイル名

【資料 4】Sony F65RS メタデータ
番号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

タグ
Creation Date
Last Update
UMID
Start
End
Duration
Drop Frame
Video Codec
Resolution
Aspect Ratio
Format fps
Capture fps
Number Of Audio Channels
Audio Codec
Audio Bit Depth
Audio Sampling Rate
Exposure Index

説明
作成日
最終更新日
ソニーF65 カメラメタデータセットの識別子
開始 TimeCode
終了 TimeCode
デュレーション
ドロップフレームの有無
映像のコーデックの種類
解像度
アスペクト比フレームレート
1 秒当たりの撮像フレーム数
オーディオのチャンネル数
オーディオのコーデック
オーディオのビット深度
オーディオのサンプリングレート
ライトメータに設定する EI 値

18
19
20
21
22
23
24
25
26
27
28
29
30
31

ND Filter Wheel
Image Sensor Readout Mode
Shutter Speed Angle
ISO Sensitivity
White Balance
Capture Gamma Equation
Gamma For CDL
Camera Attributes
Effective Marker Aspect Ratio
Rotary Shutter Mode
Raw Black Code
Raw Gray Code
Raw White CodeMonitoring Characteristics

32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

Monitoring Descriptions
Lens Attributes
Focus Distance
Aperture Value
Aperture Scale Setting
Effective Focal Length
Hyperfocal Distance
Near Focus DistanceFar Focus Distance
Horizontal Field Of View
Entrance Pupil Position
Normalized Zoom Value
Cooke Protocol User Metadata*Description*Circle*Project*Director Name
*Director Of Photography Name
*Production*Camera Index*Reel*Scene
*Cut
*Take
*Shot
*Mark In
*Mark OutCDL Slope
CDL Offset
CDL Power
CDL Saturation

内蔵 ND フィルタの透過率
イメージセンサーの読み出しモード
シャッター開角度（分）ISO 感度
色温度（K）で表したホワイトバランスの設定値
本体映像に適用されたガンマカーブの種類
ASC CDL を適用するカラースペースの名称
カメラの機種名とシリアル番号
有効画素数のアスペクト比
ロータリーシャッター
基準ブラックレベル（遮光時）のコード値
反射率 18%のチャートを適正な露出で撮影したときのコード値
反射率 90%のチャートを適正な露出で撮影したときのコード値
モニタリングの特性を示す 16 バイトの UID。F65 では LUT のガンマレベル
が入る
VFSDI 出力に適用された LUT の名称
レンズのシリアル番号
最短撮影距離（集束距離）
アパーチャー
絞り目盛の設定
有効焦点距離 (EFL)
ハイパーフォーカルディスタンス (過焦点距離)
焦点範囲の開始端
焦点範囲の終了端
水平画角
入射瞳位置
正規化されたズーム値
Cooke /i プロトコルで定義されたレンズポジションデータ
コメントエリア
サークル名
プロジェクトの名称
監督の名前
撮影監督の名前
プロダクションハウスの名称
撮影したカメラを識別するためのインデックス
リール番号
シーン番号
カット番号
テイク番号
ショット番号
IN 点
OUT 点
ASC CDL V1.2 の Slope 値(RGB)ASC CDL V1.2 の Offset 値(RGB)ASC CDL V1.2 の Power 値(RGB)ASC CDL V1.2 のサチュレーション(彩度)235【資料 5】Canon EOS C500 RAW （.RMF）メタデータ
Length
Type
1
UInt8

Item Name
Compression_TypeDefinition
RAW フレーム(Bayer)の圧縮タイプ

2
3

2
2

UInt16
UInt16

Capture_Height
Capture_Width

現像後の有効画像高さ
現像後の有効画像幅

4
5

2
2

UInt8 * 2
UInt8 * 2

Playback_Frame_Rate
Capture_Frame_Rate

6

1

UInt8

7
8

30
30

ASCII
ASCII

9
10

30
2

ASCII
UInt16

11
12

80
12

ASCII
ASCII

再生フレームレート
キャプチャフレームレート
バリアブルの場合、再生フレームレートと異なる
Bit_Per_Sample
サンプルの bit 深度
0 : 8-bit
1 : 10-bit
2 : 12-bit
Device_Model_Name
カメラのモデル名
No Information 時は All 00h
Device_Firmware_Versi カメラのファームバージョン
No Information 時は All 00h
on
Device_Serial_Number カメラのシリアル番号
No Information 時は All 00h
Lens_ID
レンズ ID
0-65534 : レンズ ID
65535:No Information
Lens_Name
レンズ名
No Information 時は All 00h
Lens_Serial_Number
レンズののシリアル番号
No Information 時は All 00h

13

1

UInt8

Lens_Type

142

UInt16

Focal_Length_Tele

15

2

UInt16

Focal_Length_Wide

16
17
18

4
4
32

RATIONAL AV_OpenRATIONAL AV_Minimum
ASCII
Related_Clip_Name

19

32

UMID32

Related_Clip_ID

20

2

UInt16

Focal_Length

21

2

UInt16

Focal_Length_35mm

222

UInt16

Electric_Zoom

23

1

UInt8

Focus_Mode24

4

Float32

Focus_Position

25

4

RATIONAL F_Number

26

2

UInt16

ND_Filter

27

1

UInt8

Shutrter_Speed_Mode

28
29
30
31

4
4
4
1

RATIONALRATIONALRATIONAL
UInt8

Shutter_Speed_Angle
Shutter_Speed_Time
Shutter_Speed_Hz
WB_Mode番号1

Values0 : Log Compression Type1 （ Canon
LOG)
255 : No Information

Example of values

4096x2160、3840x2160 : 0870h
4096x2160 : 1000h
3840x2160 : 0F00h

01h : C500 は 10-bit のみサポート

0: 単焦点レンズ
1: ズームレンズ
255:No Information
レンズの望遠端の焦点距離。
0-65534 : 焦点距離値
単焦点は Tele/Wide 同じ値が入る
65535 : No Information
焦点距離 = 焦点距離値/10 (mm)35mm 換算でない値をいれる。
レンズの広角端の焦点距離。
0-65534 : 焦点距離値
単焦点は Tele/Wide 同じ値が入る
65535 : No Information
焦点距離 = 焦点距離値/10 (mm)35mm 換算でない値をいれる。
レンズの解放絞り値の F ナンバー例）F2.8 の場合は{28,10}
レンズの最小絞り値の F ナンバー例）F32 の場合は{32,1}
関連クリップのクリップ名
CF に MXF 記録をしている場合にクリップ ID("AA0001"など）をセット。
記録していない場合は All 00h をセット。
関連クリップのクリップ ID
CF に MXF 記録をしている場合に、CFに記録中のクリップの UID をセット。記録していない場合は All 00h をセット。
レンズの焦点距離情報。
0-65534 : 焦点距離値
電子ズーム時は、合成焦点距離をセット 65535 : No Informationする。レンズ焦点距離が 50mm で、電子 焦点距離 = 焦点距離値/10 (mm)ズームが 2 倍の場合、100mm の値をセットする。
35mm 換算でない値を入れる。
Focal_Length の値の 35mm フィルム換 0-65534 : 焦点距離値
65535 : No Information
算値を入れる。
焦点距離 = 焦点距離値/10 (mm)電子ズーム拡大率
0 : 電子ズームオフ
0-65534 : 電子ズーム値
65535 : No Information
電子ズーム拡大率 = 電子ズーム値/10
フォーカスモード
0:マニュアルフォーカスモード
1:オートフォーカスモード
255:No Information
被写体までの距離（m）
00000000h : 超無限C500 では未使用
00000001h-FFFFFFFDh : フ ォ ー カ ス
距離（m）
FFFFFFFEh : 無限遠
FFFFFFFFh : No Information
絞り値例）F2.8 の場合は{28,10}
F32 の場合は{32,1}
ND フィルタ状態
0 : ND フィルターオフ
1-65534 : ND 値
65535 : No Information
減光率＝1/ND 値
0:秒（Second）
1:角度（Degree）
2:周波数（Hz）
255:No Information
シャッタースピード(度単位)
No Information 時は All 00h
シャッタースピード(sec)
No Information 時は All 00h
シャッタースピード(Hz 単位)
No Information 時は All 00h
ホワイトバランス設定モード
0 : オートホワイトバランス
1 : 色温度指定
2 : ワンプッシュ
3 : プリセット
254 : Other Mode
255 : No Information
レンズの種類

236

番号
32

Length
Type
1
UInt8

33

2

UInt1634

4

UInt32

35

1

UInt8

36

1

UInt8

37

1

UInt8

38

1

UInt8

39

1

UInt8

Item Name
WB_Preset

Definition
Values
ホワイトバランスのプリセットモード
0 : キャンドル
WB_Mode が"Preser"の場合のみ有効。そ 1 : 白熱電球
れ以外の場合は、"No Information"をセッ 2 : 蛍光灯（低色温度）トする。
3 : 蛍光灯（高色温度）
4 : 太陽光
5: 曇
6 : 日陰254 : その他
255 : No information
Color_Temperature
色温度0-65534 : 色温度値（K)65535: No Information
ISO_Speed
ISO 感度設定値
00000000h-FFFFFFFEh : ISO 感度設定
値
FFFFFFFFh : No Information
Gamma_Setting
ガンマ設定値
0 : Log Gamma
1 : Normal Gamma
FF:No Information
Log_Gamma_Type
ログガンマの種類
0:Canon Log Gamma
FF:No Information
Gamma_Setting が"Log Gamma"じゃない時は、No Information をセットする。
Image_Stabilizer
手ぶれ補正状態
0:Image Stabilizer OFF
1:Lens Image Stabilizer ON
FF:No Information
電子手ぶれ補正、センサー手ぶれ補正な
どが今後あれば値を追加。
Peripheral_Ilumminatio 周辺光量落ち補正状態
0：Processed
n_Correction
1：Not Processed
Infra_Red_Mode
赤外線撮影モード状態
0:赤外線撮影モード OFF
1:赤外線撮影モード ON【資料 6】EOS C500 RAW （XML）メタデータ
番号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

タグ 1
<VideoClip>

タグ 2<Device><TimeInformation>

タグ 3<ClipType><ClipVersion><ClipTitle><Creator><Description><Manufacturer><SerialNo><ModelName><Lens><FirmVersion><DateAndTime><StartTimecode><StopTimecode><ClipID><VideoFrameCount><AudioFileCount>

説明
クリップのタイプ（C500 の RAW は”MovieType1”)
クリップのバージョン
クリップのタイトル
クリップの作成者
クリップのコメントや説明など
デバイスメーカー名（"CANON")
デバイスのシリアル番号
デバイスのモデル名
装着されているレンズ名
デバイスのファームウェア・バージョン
クリップが作成された日時
クリップの先頭タイムコード
クリップの最終タイムコード
クリップの UID
ビデオフレーム数（RAW ファイル数）
オーディオファイル数(BWF ファイル数)

237

Example of values

【資料 7】XF/XA/C300/C500 MXF （.MXF）メタデータ
LengthType

Item NameMPEG Video Descriptor

番号
1

-

2

-

-

AES3 Audio Descriptor

3
4
5
6

4
2
2
2-bit

Float32
UInt16
UInt16Focus_Position
Focal_Length
Electric_Zoom
Focus_Mode

7

2-bit

Image_Stabilizer

8

2-bit

Shutrter_Set_Mode

9
10
11
12

4
3
4
3-bit

13

5-bit

14

2

15

1-bit

16

7-bit

Uint

Master_Gain

17

4-bit

Uint

Master_Gain_Delta

18
19

1
2-bit

UInt8

ND_Filter
IR_Status

20

4

UInt32

ISO_Speed-

RATIONALRATIONALRATIONAL

Shutter_Speed
Shutter_Value
F_Number
WB_Mode

WB_Preset

UInt16

Color_Temperature
Gain_Mode

Definition
ValuesSMPTE ST381 で 規定 され てい る MPEG
Video Descriptor
SMPTE ST382 で 規 定 さ れ て い る AES3
Audio Essence Descriptor
被写体距離（m）
35mm 換算の焦点距離(mm)電子ズーム拡大率
フォーカスモード00(2 : マニュアルフォーカス
01(2 : オートフォーカス
手ぶれ補正状態
00(2 : 手ぶれ補正オン
01(2 : 手ぶれ補正オフ
シャッタースピードの設定モード
00(2 : 秒（Second）
01(2 : 角度（Degree）
10(2 : 周波数（Hz）
11(2 : No Information
秒単位のシャッタースピード(sec)
No Information 時は All 00h
角度又は周波数単位のシャッタースピード
分子：UInt16、分母：UInt8 の RATIONAL
絞り値
ホワイトバランス設定モード
000(2 : オートホワイトバランス
001(2 : 色温度指定
010(2 : ワンプッシュ
011(2 : プリセット111(2 : No Information
ホワイトバランスのプリセットモード
00000(2 : キャンドル
WB_Mode が"Preser"の場合のみ有効。それ 00001(2 : 白熱電球
以外の場合は、"No Information"をセットす 00010(2 : 蛍光灯（低色温度）
る。
00011(2 : 蛍光灯（高色温度）
00100(2 : 太陽光
00101(2 : 曇
00110(2 : 日陰
11110(2 : その他
11111(2 : No information
色温度0-65534 : 色温度値（K)65535: No Information
ゲイン設定のモード
0 : AGC モード
1 : マニュアル設定モード
マスターコントロールのゲイン値
20h = 0db
△1LSB = 0.5db
マスターコントロールのゲイン値の補助値
0 = 0db
Master_Gain から算出される値に加算して △1LSB = 0.1db
使用する
ND フィルタの減光率
赤外線撮影モード状態
00(2 : 赤外線撮影モード OFF
01(2 : 赤外線撮影モード ON
ISO 感度設定値
00000000h-FFFFFFFEh : ISO 感度設定値
FFFFFFFFh : No Information

238

【資料 8】XF/XA/C300/C500 MXF （.CIF）メタデータ
番号
1
2
3

Length
4-bit
4-bit
4-bit

4

Type

Item NameVideo_Type
Aspect_Ratio
Video_Format

Definition
ビデオエンコーディングタイプ
アスペクト比ビデオ解像度

4-bit

Frame_Rate

ビデオフレームレート

5

4-bit

Audio_Type

オーディオエンコーディングタイプ

6

4-bit

Sampling_Frequency

オーディオサンプリング周波数

7

4-bit

Audio_Channel

オーディオチャンネル数

8
9
10
11
12
13
14
15

32
32
32
8
8
4
4
1

Maker_Name
Model_Name
Serial_Number
Firm_Version
Record_Time_And_Date
Start_Time_Code
Stop_Time_Code
Recording_Rate

デバイスメーカー名
デバイスモデル名
デバイスシリアル番号
ファームウェア・バージョン
クリップ作成日時
クリップ先頭タイムコード
クリップ末尾タイムコード
ビデオ記録レート

16

16-bitRecording_Mode

17

2-bit

Interval_Unit

18

1

UInt8

Interval_Time

19

1

UInt8

Frame_Rec_Num

20

2

UInt16

Variable_Frame_Rate

211

AE_Mode22

3-bit

WB_Mode23

5-bit

WB_Preset

24

2

25

1-bit

ASCII
ASCII
ASCII

UInt8

UInt16

Color_Temperature
IR_Mode_Flag

Values0001(2 : MPEG20001(2 : 16:9
0001(2 : 1920x1080
0010(2 : 1280x720
0011(2 : 1440x1080
0001(2 : 59.94i0010(2 : 50i
0011(2 : 29.97p0100(2 : 25p0101(2 : 23.98p0110(2 : 59.94p
0111(2 : 50p
1000(2 : 23.98p (pull down)
1001(2 : 24p0000(2 : No Audio
0001(2 : LPCM
0000(2 : No Audio
0001(2 : 48KHz
0000(2 : No Audio
0001(2 : 2-ch0010(2 : 4-ch

1 : 25 Mbps
2 : 35 Mbps
3 : 50 Mbps
特殊記録モードを示すビットマップフィー High Byte
Low Byte
msb
msb
ルド
Pre-Recording
Reserved
記録時の特殊記録モード設定に応じて、該当
Loop_Recording
Reserved
する箇所のビットがセットされる
Variable_Frame_Recording
Reserved
Interval_Recording
Reserved
Frame_Recording
Reserved
Double_Recording
Reserved
Reserved
Reserved
Reserved
Reserved
lsb
lsb
インターバル記録時(Interval_Recording)の 01(2 : 秒(Second)
インターバル設定時間の単位
10(2 : 分(Minute)11(2 : 時間(Hour)
インターバル記録時(Interval_Recording)のインターバル設定時間
フレーム記録モード(Frame_Recording)時の
1 回の記録シーケンスで記録されたフレーム数
バ リ ア ブ ル フ レ ー ム 記 録(Variable_Frame_Recording) 時 の ビ デ オ サンプリングフレームレート(fps)
露出設定モードを示すビットマップフィー msb
Full Auto Mode
ルド
ビット値が 0 の場合はその項目が Auto 設定 Irisであることを、ビット値が 1 の場合はその項 Shutter
Gain
目がマニュアル設定であることを示す
ND Filter
Reserved
Reserved
Reserved
lsb
ホワイトバランス設定モード
000(2 : オートホワイトバランス
001(2 : 色温度指定
010(2 : ワンプッシュ
011(2 : プリセット111(2 : No Information
ホワイトバランスのプリセットモード
00000(2 : キャンドル
WB_Mode が"Preser"の場合のみ有効。それ 00001(2 : 白熱電球
以外の場合は、"No Information"をセットす 00010(2 : 蛍光灯（低色温度）
る。
00011(2 : 蛍光灯（高色温度）
00100(2 : 太陽光
00101(2 : 曇
00110(2 : 日陰
11110(2 : その他
11111(2 : No information
色温度0-65534 : 色温度値（K)65535: No Information
赤外線撮影モード状態
00(2 : 赤外線撮影モード ON の映像がクリップに含まれない
01(2 : 赤外線撮影モード ON の映像がクリップに含まれ

239

番号

LengthType

Item Name

Definition

Values
る

26

1-bit

Log_Gamma_Flag

Log ガンマ設定モード

0 : Log ガンマが適用されていない
1 : Log ガンマが適用されている
0000(2 : Canon Log

27
28

4-bit
4-bytex100

Gamma_Setting
Shot_Mark29

8-bytex100

Event_Mark

Log ガンマの種類
ユーザーが任意のフレームにセットできるマーク。
2 ビットのマーク種別＋3 バイトのフレーム番号で構成。
1 クリップに最大 100 か所までセット可能
クリップ撮影時にカメラがイベントを検出 イベント種別
した場合に自動でフレームにセットされる - 顔を検出した- ホワイトバランスが変更されたマーク。
4 バイトのイベント種別＋4 バイトのフレー - ゲイン/ISO 設定が変更された- 赤外線撮影モードが変更された
ム番号で構成。
1 クリップで最大 100 か所までセットされる。

【資料 9】XF/XA/C300/C500 MXF （XML）メタデータ
番号
1
2
3
4
5
6
7
8
9
10
11
12

タグ 1
<VideoClip>

タグ 2<Device><Location>

タグ 3<Title><Creator><Description><Manufacturer><SerialNo><ModelName><FirmVersion><Lens><Altitude><Longitude><Latitude><Source>

13<PlaceName>

説明
クリップのタイトル
クリップの作成者
クリップのコメントや説明など
デバイスメーカー名（"CANON")
デバイスのシリアル番号
デバイスのモデル名
デバイスのファームウェア・バージョン
装着されているレンズ名
高度
経度
緯度
位置情報のソース情報
CREATED : 撮影後に手動で入力
CAPTURED : 機器上の GPS デバイスから取得
DIVERSED : 別体の GPS システムから取得
撮影場所情報240

【資料 10】Autodesk FBX KFbxCamera クラス
番号
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

タグ
タイプ
Position
vector
UpPosition
vectorInterestPosition
vectorRoll
doubleOpticalCenterX
doubleOpticalCenterY
doubleBackgroundColor
double[3]TurnTable
doubleDisplayTurnTableIconbool
UseMotionBlur
bool
UseRealTimeMotionBlur
bool
MotionBlurIntensity
doubleAspectRatioMode
EAspectRatioMode
AspectWidthdoubleAspectHeight
doublePixelAspectRatio
doubleApertureMode
EApertureMode
GateFit
EGateFit
FieldOfView
doubleFieldOfViewX
doubleFieldOfViewY
doubleFocalLength
doubleCameraFormat
EFormatUseFrameColor
bool
FrameColor
double[3]ShowNamebool
ShowInfoOnMoving
bool
ShowGrid
bool
ShowOpticalCenter
bool
ShowAzimut
bool
ShowTimeCode
bool
ShowAudiobool
AudioColor
double[3]NearPlane
double
FarPlanedoubleAutoComputeClipPlanes
bool
FilmWidth
doubleFilmHeight
doubleFilmAspectRatio
doubleFilmSqueezeRatio
doubleFilmFormat
EApertureFormat
FilmOffsetX
doubleFilmOffsetY
doublePreScaledoubleFilmTranslateX
doubleFilmTranslateY
doubleFilmRollPivotX
doubleFilmRollPivotY
doubleFilmRollValue
doubleFilmRollOrder
EFilmRollOrder
ViewCameraToLookAt
bool
ViewFrustumNearFarPlanebool
ViewFrustumBackPlaneMode EFrontBackPlaneDisplayMode
BackPlaneDistancedoubleBackPlaneDistanceMode
EFrontBackPlaneDistanceMode
ViewFrustumFrontPlaneMode EFrontBackPlaneDisplayMode
FrontPlaneDistancedoubleFrontPlaneDistanceMode
EFrontBackPlaneDistanceMode
LockModebool
LockInterestNavigation
bool
BackPlateFitImagebool
BackPlateCrop
bool
BackPlateCenter
bool
BackPlateKeepRatio
bool
BackgroundAlphaTresholddoubleBackPlaneOffsetX
doubleBackPlaneOffsetY
doubleBackPlaneRotation
doubleBackPlaneScaleX
doubleBackPlaneScaleY
doubleShowBackplatebool
BackgroundTexture
FbxReference
FrontPlateFitImage
bool
FrontPlateCrop
bool
FrontPlateCenterbool

説明XYZ 座標上方向の XYZ 座標指定
注視点 XYZ 座標
ロール角
光軸 X 値
光軸 Y 値
カメラの背景色(RGB)
ターンテーブルの角度 モデル作成中の確認目的に使用
ターンテーブルアイコンを表示するかモーションブラーの ON/OFF
リアルタイム・モーションブラーの ON/OFF
モーションブラー強度(pixel)
アスペクト比のモード
カメラのアスペクトの幅(R/O)
カメラのアスペクトの高さ(R/O)
ピクセルのアスペクト比
絞りモード
フィルムゲートのモード
視野角
視野角 X 値
視野角 Y 値
焦点距離
カメラのフォーマット(HD, NTSC などピクセルサイズ)
カメラから見える範囲の境界を表示するか
カメラから見える範囲の境界の色
カメラの名前を表示するか移動中に情報を表示するか
床面にグリッド（格子）を表示するか
光軸を表示するか
経緯度方向に回転した視線を表示するかTimeCode を表示するかオーディオを表示するかオーディオの色カメラからの距離によるクリッピング範囲の近い方カメラからの距離によるクリッピング範囲の遠い方
クリッピング範囲を自動計算するか
カメラのレンズ絞りの幅
カメラのレンズ絞りの高さ
カメラのレンズ絞りのアスペクト比
カメラのレンズ絞りの圧縮比
カメラのレンズ絞りのフィルムフォーマット
フィルムオフセット X 値
フィルムオフセット Y 値
デジタル的なカメラズーム
デジタル的なカメラパン X 値
デジタル的なカメラパン Y 値
再生フィルムの中心からのピボットポイント X 値
再生フィルムの中心からのピボットポイント Y 値
再生フィルムを中心とした回転量
フィルムロールの順序
カメラの注視をするか
クリッピングプレーンを表示するか
バックプレーンに表示するモード
バックプレーンの距離
バックプレーンの距離のモード
フロントプレーンに表示するモード
フロントプレーンの距離
フロントプレーンの距離モード
カメラ設定をロックするフラグ
カメラが注視するポイントをロックするフラグ
バックプレートに画像をフィットさせるか
バックプレートをクロップするか
バックプレートの中心フラグ
バックプレートのキープ率
背景アルファの閾値
バックプレーンのオフセット X 値
バックプレーンのオフセット Y 値
バックプレーンの回転角
バックプレーンの拡大率 X 値
バックプレーンの拡大率 Y 値
バックプレートを表示するか
背景テクスチャフロントプレートに画像をフィットさせるか
フロントプレートをクロップするか
フロントプレートの中心フラグ

241

番号
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105

タグ
FrontPlateKeepRatio
ShowFrontplate
FrontPlaneOffsetX
FrontPlaneOffsetY
FrontPlaneRotation
FrontPlaneScaleX
FrontPlaneScaleY
ForegroundTexture
ForegroundOpacity
DisplaySafeArea
DisplaySafeAreaOnRender
SafeAreaDisplayStyle
SafeAreaAspectRatio
Use2DMagnifierZoom_2DMagnifierZoom_2DMagnifierX_2DMagnifierY
ProjectionType
OrthoZoom
UseRealTimeDOFAndAA
UseDepthOfField
FocusSource
FocusAngle
FocusDistance
UseAntialiasing
AntialiasingIntensity
AntialiasingMethod
UseAccumulationBuffer
FrameSamplingCount
FrameSamplingType

タイプ
bool
bool
doubledoubledoubledoubledoubleFbxReference
doublebool
bool
ESafeAreaStyle
doublebool
doubledoubledoubleEProjectionType
doublebool
bool
EFocusDistanceSource
doubledoublebool
doubleEAntialiasingMethodbool
int
ESamplingType

説明
フロントプレートのキープ率
フロントプレートを表示するか
フロントプレーンのオフセット X 値
フロントプレーンのオフセット Y 値
フロントプレーンの回転角
フロントプレーンの拡大率 X 値
フロントプレーンの拡大率 Y 値
前景テクスチャ
前景の不透明度
セーフエリアを表示するか
レンダリング時にセーフエリアを表示するかセーフエリアのスタイル
セーフエリアのアスペクト比
2D 画像としてズームするか
2D 画像としてのズーム率
2D 画像としてのズーム率 X 値
2D 画像としてのズーム率 Y 値
プロジェクション・タイプ
平行投影によるズーム値
リアルタイムに被写界深度とアンチエイリアス処理を行うか
被写界深度処理を使うかフォーカスソースのタイプ
焦点の角度
焦点距離
アンチエイリアス処理を使うか
アンチエイリアス強度
アンチエイリアスの処理方式
アキュムレーションバッファを使うか
アンチエイリアスでオーバーサンプリング数
アンチエイリアスでオーバーサンプリングする場合の方式

242

【資料 11】EXIF 2.3 メタデータ
番号
タグ
1
ImageWidth

画像の幅

種別 1
TIFFRev.6.0 の付属情報

説明

2

ImageLength

画像の高さ

TIFFRev.6.0 の付属情報

3

BitsPerSample

画像のビットの深さ

TIFFRev.6.0 の付属情報

4

Compression

圧縮の種類

TIFFRev.6.0 の付属情報

5

PhotometricInterpretation

画素構成

TIFFRev.6.0 の付属情報

6

Orientation

画像方向

TIFFRev.6.0 の付属情報

7

SamplesPerPixel

コンポーネント数

TIFFRev.6.0 の付属情報

8

PlanarConfiguration

画像データの並び

TIFFRev.6.0 の付属情報

9

YCbCrSubSampling

YCC の画素構成(C の間引き率)

TIFFRev.6.0 の付属情報

10

YCbCrPositioning

YCC の画素構成(Y と C の位置)

TIFFRev.6.0 の付属情報

11

XResolution

画像の幅の解像度

TIFFRev.6.0 の付属情報

12

YResolution

画像の高さの解像度

TIFFRev.6.0 の付属情報

13

ResolutionUnit

画像の幅と高さの解像度の単位

TIFFRev.6.0 の付属情報

14
15
16
17
18
19

StripOffsets
画像データのロケーション
RowsPerStrip
1 ストリップ当たりの行の数
StripByteCounts
ストリップの総バイト数
JPEGInterchangeFormat
JPEG の SOI へのオフセット
JPEGInterchangeFormatLength JPEG データのバイト数
TransferFunction
再生階調カーブ特性

TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報

20

WhitePoint

参照白色点の色度座標値

TIFFRev.6.0 の付属情報

21

PrimaryChromaticities

原色の色度座標値

TIFFRev.6.0 の付属情報

22

YCbCrCoefficients

色変換マトリクス係数

TIFFRev.6.0 の付属情報

23

ReferenceBlackWhite

参照黒色点値と参照白色点値

TIFFRev.6.0 の付属情報

24
25
26
27
28
29
30
31
32
33

DateTime
ImageDescription
Make
Model
Software
ArtistCopyright
ExifVersion
FlashpixVersion
ColorSpace

ファイル変更日時
画像タイトル
画像入力機器のメーカー名
画像入力機器のモデル名
ソフトウェアアーティスト
撮影著作権者/編集著作権者
Exif バージョン
対応フラッシュピックスバージョン
色空間情報

TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
TIFFRev.6.0 の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報

34

Gamma

再生ガンマ

Exif IFD の付属情報

35
36
37
38
39
40
41

ComponentsConfiguration
CompressedBitsPerPixel
PixelXDimension
PixelYDimension
MakerNote
UserComment
RelatedSoundFile

各コンポーネントの意味
画像圧縮モード
実効画像幅
実効画像高さメーカノート
ユーザコメント
関連音声ファイル

Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報

42
43
44
45
46
47
48
49
50
51
52
53
54
55

DateTimeOriginal
DateTimeDigitized
SubSecTime
SubSecTimeOriginal
SubSecTimeDigitized
ExposureTime
FNumber
ExposureProgram
SpectralSensitivity
PhotographicSensitivity
OECF
SensitivityType
StandardOutputSensitivity
RecommendedExposureIndex

原画像データの生成日時
ディジタルデジタルデータの作成日時
DateTime のサブセック
DateTimeOriginal のサブセック
DateTimeDigitized のサブセック
露出時間
F ナンバー
露出プログラム
スペクトル感度
撮影感度
光電変換関数
感度種別
標準出力感度
推奨露光指数

Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報

243

種別 2
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像データの構成に関するタグ
画像の記録位置に関するタグ
画像の記録位置に関するタグ
画像の記録位置に関するタグ
画像の記録位置に関するタグ
画像の記録位置に関するタグ
画像データの特性に関するタグ
画像データの特性に関するタグ
画像データの特性に関するタグ
画像データの特性に関するタグ
画像データの特性に関するタ
グ
その他のタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグバージョンに関するタグ
バージョンに関するタグ
画像データの特性に関するタグ
画像データの特性に関するタグ
構造に関するタグ
構造に関するタグ
構造に関するタグ
構造に関するタグ
ユーザ情報に関するタグ
ユーザ情報に関するタグ
関連ファイル情報に関するタグ
日時に関するタグ
日時に関するタグ
日時に関するタグ
日時に関するタグ
日時に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ

番号
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131

タグ
ISOSpeed
ISOSpeedLatitudeyyy
ISOSpeedLatitudezzz
ShutterSpeedValue
ApertureValue
BrightnessValue
ExposureBiasValue
MaxApertureValue
SubjectDistanceMeteringMode
LightSource
Flash
FocalLength
SubjectArea
FlashEnergy
SpatialFrequencyResponse
FocalPlaneXResolution
FocalPlaneYResolution
FocalPlaneResolutionUnit
SubjectLocation
ExposureIndex
SensingMethod
FileSource
SceneType
CFAPattern
CustomRendered
ExposureMode
WhiteBalance
DigitalZoomRatio
FocalLengthIn35mmFilm
SceneCaptureType
GainControl
Contrast
Saturation
Sharpness
DeviceSettingDescription
SubjectDistanceRange
ImageUniqueID
CameraOwnerName
BodySerialNumber
LensSpecification
LensMake
LensModel
LensSerialNumber
GPSVersionID
GPSLatitudeRef
GPSLatitude
GPSLongitudeRef
GPSLongitude
GPSAltitudeRef
GPSAltitude
GPSTimeStamp
GPSSatellites
GPSStatus
GPSMeasureMode
GPSDOP
GPSSpeedRef
GPSSpeed
GPSTrackRef
GPSTrack
GPSImgDirectionRef
GPSImgDirection
GPSMapDatum
GPSDestLatitudeRef
GPSDestLatitude
GPSDestLongitudeRef
GPSDestLongitude
GPSDestBearingRef
GPSDestBearing
GPSDestDistanceRef
GPSDestDistance
GPSProcessingMethod
GPSAreaInformation
GPSDateStamp
GPSDifferential
GPSHPositioningError

種別 1
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
Exif IFD の付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報
GPS に関する付属情報

説明ISO スピード
ISO スピードラチチュード yyy
ISO スピードラチチュード zzz
シャッタースピード
絞り値
輝度値
露光補正値
レンズ最小 F 値
被写体距離
測光方式
光源
フラッシュ
レンズ焦点距離被写体領域
フラッシュ強度
空間周波数応答
焦点面の幅の解像度
焦点面の高さの解像度
焦点面解像度単位
被写体位置
露出インデックス
センサ方式
ファイルソース
シーンタイプ
CFA パターン
個別画像処理
露出モード
ホワイトバランス
デジタルズーム倍率35mm 換算レンズ焦点距離
撮影シーンタイプ
ゲイン制御
撮影コントラスト
撮影彩度
撮影シャープネス
撮影条件記述情報
被写体距離レンジ
画像ユニーク ID
カメラ所有者名
カメラシリアル番号
レンズの仕様情報
レンズのメーカー名
レンズのモデル名
レンズシリアル番号GPS タグのバージョン
北緯(N)or 南緯(S)
緯度(数値)
東経(E)or 西経(W)
経度(数値)
高度の基準
高度(数値)
GPS 時間(原子時計の時間)測位に使った衛星信号
GPS 受信機の状態
GPS の測位方法
測位の信頼性
速度の単位
速度(数値)
進行方向の単位進行方向(数値)
撮影した画像の方向の単位
撮影した画像の方向(数値)測位に用いた地図データ
目的地の北緯(N)or 南緯(S)
目的地の緯度(数値)
目的地の東経(E)or 西経(W)
目的地の経度(数値)
目的地の方角の単位
目的の方角(数値)
目的地までの距離の単位
目的地までの距離(数値)
測位方式の名称
測位地点の名称
GPS 日付GPS 補正測位
水平方向測位誤差244

種別 2
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
撮影条件に関するタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグ
その他のタグGPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ
GPS に関するタグ

【資料 12】既存ソフトウェア比較表
大項目
アセット

カット単位の機能

プレビュー

スケジュール

小項目
Asset 管理機能の有
無ファイル命名規則
ディレクトリ命名
規則
パブリッシュ機能
カット管理機能
サムネイル表示
動画再生

JCGS Library◯

Redmine－GanttProject－

OmniPlan－

TACTIC◯

5th Kind◯

Shotgun
－

RV
－

COPRA
－

HIERO
－

wiredrive－

Keyframe Concept
－

◯
◯

－
－

－
－

－
－

?
?

?
?

－
－

－
－

－
－

－
－

－
－

－
－

◯
－
－
－

－
－
－
－

－
－
－
－

－
－
－
－

?
－
－
－

?
－
－
－

－
◯
◯
◯

－
－
◯
◯

－
◯
◯
◯

プレイリスト作成
メタ情報登録
メタ情報編集
コメント機能
ソース映像の対応
フォーマット

－
－
－
－
－

－
－
－
－
－

－
－
－
－
－

－
－
－
－
－

－
－
－
－
－

－
－
－
－
－

－
－
－
◯
◯
－
◯
◯
◯
Revolver/RV で 対
◯
◯
応
?
◯
◯
◯
◯
◯
◯
◯
－
◯
◯
◯
Revolver/RV で 対 DPX,
Cineon, H264 QT
OpenEXR, TIFF,
応
IFF,
JPEG,
ARRIRAW, R3D,
AVI, WMV, MP4,
QuickTime

対応レゾリューシ
ョン

－

－

－

－

－

－

Revolver/RV で 対 ハ ー ド ウ ェ ア に 依 FullHD存
応ステレオ 3D 対応

－

－

－

－

－

－

バージョン管理
オーディオ

－
－

－
－

－
－

－
－

－
－

－
－

動画再生

－

－

－

－

－

◯

動画へのマーカー

－

－

－

－

－

◯

タイムライン表示

－

－

－

－

－

?

レイヤー操作

－

－

－

－

－

?

カラーコレクション
HDR 対応

－

－

－

－

－

?

－

－

－

－

－

?

スケジュール機能
ワークフロー編集
ステータス設定
進捗%
カレンダー表示Gantt 表示
アラート

－
－
－
－
－
－
－

◯
◯
◯
◯
◯
◯
◯

◯
－
－
◯
◯
◯
－

◯
－
◯
◯
◯
◯
◯

◯
◯
◯
◯
◯
◯
?

－
－
－
－
－
－
－

Revolver/RV
応◯
Revolver/RV
応
Revolver/RV
応
Revolver/RV
応
Revolver/RV
応
Revolver/RV
応
Revolver/RV
応
Revolver/RV
応
◯
◯
◯
◯
◯
◯
◯

245

で 対 Active and Passive

－

◯
－
◯
◯
－
◯
－
－
◯
◯
◯
?
ARRIRAW,
AVI, QuickTime, WMV, QuickTime
CIN, DPX, GIF, FLV, PDF, JPG,
Radiance, JPEG, PNG, GIF, AI,
IFF,
OpenEXR, PSD
PNG,
PSD,
QuickTime, RAW,REDCODE, SGI,SoftImage
PIC,
TIFF,
TARGA,
RLA, XPM, YUV
R3D:5120×2700?
?
ARRIRAW:2880×2
160
－
－
－

で対

◯
◯

－
◯

○
◯

－
◯

?
◯

で対

◯

◯

◯

◯

◯

で対

◯

◯

◯

－

?

で対

◯

－

◯

◯

◯

で対

－

－

－

－

?

で対

◯

－

－

?

で対

◯

－

OpenColorIO に対
応
－

－

?

－
－
－
－
－
－
－

－
－
－
－
－
－
－

－
－
－
－
－
－
－

－
－
－
－
－
－
－

?
?
?
?
?
?
?

大項目

小項目
履歴管理
コ ミ ュ ニ ケ ーショ メッセージ送信
ン
メール送信

JCGS Library－－－

アプルーブ（承認）検索絞込み（フィルタ）
グループ化

－
－
－
－

ユーザー管理の有無パーミッション設定
バジェット（予算） バジェット機能
単価設定
分析
外部連携
エクスポート－編集

ユーザー管理－－－－－Redmine◯－無し,
メール通知のみ

－

API

－

使用形態

スタンドアロン
ネットワーク
サーバの設置形態◯－－

セキュリティ

セキュリティ方式－

サポート

メーカーからの教◯育
サポート日数
契約による

無し

導入日数
専任人員の人数
保守契約の形態

その他

使用プロダクショ NDesign
ン

－
◯
◯
◯

有り,
Outlook が 起 動 さ
れる
－
－
－
－

◯

－

OmniPlan
TACTIC－?
インスタントメッ
?
セージ
メール通知
メール通知

5th Kind－◯

Shotgun
◯
◯

RV
－
◯

COPRA
－
－

HIERO
－
－

wiredrive－－

Keyframe Concept
?
?

◯

◯

◯

－

－

◯

?

◯
◯
◯
◯

?
?
?
?

◯
◯
◯
◯

?
－
－
－

?
?
?
?

◯
◯
◯
◯

－
－
－
－

－
－
－
◯

◯

◯

◯

◯

－

◯

－
－
－
Tag 付けによるグ
ループ
－

◯

－

?

◯

－

◯

－

◯

－

－
－
－
?

－
－
－
Excel

－
－
－
－

－
－
－
－

－
－
－
EDL, XML

－
－
－
－

?
?
?
?

?

Excel

－

－

EDL, XML

－

?

?

◯

－

－

Python API

－

?

－
◯
?

－
◯
メーカーサーバー
自前でインストール
パスワード, ssl

◯
－
－

－
◯
○
－
メーカーサーバー－
自前でインストール
サーバ：SSL とパス－
ワード
クライアント：デバ
イス ID 登録
◯
講習会など

－
◯
クラウド型

インストール時,－－◯
Windows では不要
－
－
◯
－
－
－
◯
－
－
－
－
－
Atom,
PDF, MS Project, PNG, iCal, CSV, MS CSV
HTML, TXT, PNG, JPEG,
CSV, Project Exchange
CSV
HTML, PDF
(MPX), MS Project(XML),HTML,
OmniOutliner,
OmniGraffle－MS
Project, XML, MPX, MS CSV
GanttProject,
Project,
txt, csv
OmniOutliner,
OmniGraffle, CSV
RESTMS
Project,－－
HTML, PDF,
スプレッドシート
－
－
◯
－
◯
◯
◯
◯
自前でインストー 自前 で イ ン ス ト ー メーカーサーバー, 自 前 で イ ン ス ト ールル
webdav
ル

インポート

現場との調整なし
月ごとの保守契約

GanttProject－－

パスワード, ssl

パスワード, ssl－

パスワード, ssl

?

－

－

1,500 ドル/日

?

1 年間

－

－

1日
1 名以上
ファーエンドテク
ノロジー社によるテクニカルサポー
ト：105,000 円
?

－
－
－

－
－
Tel,E-Mail

?

?

?

◯

?
サーバ管理者 1 名
?

?
?
?

Web, Mail, Twitter－など－
1 年, 以降 1 年毎に?
保守費用を払う
1日
1日
数日程度
1 名以上
1名
1名
オンライン
ライセンスは初年?
度の保守費用を含むLegend3D,
MarvelStudios, 北米多数
Saatchi & Saatchi Warner
Bros. 国内はあまりない
LA,
Lockheed Pictures,
Walt
MartinDisney Pictures

246－

Industrial Light & 国内はない
Magic,
Weta
Digital,Digital
Domain256 ビット SSL 暗
号化

?

オンライン

?

サ ブ ス プ リ ク シ ョ 月毎
ン1年
30 分
1日
－
－
価格は 1 年のサブ メンテナンス,
ス ク リ プ シ ョ ン を アップデートなど
含む
国内はない

◯
－
スタンドアロン

?

?
?
?
?

?

大項目
メーカー情報TACTIC
5th Kind
ShotgunAeronautics, 等
販売元国籍
日本
OSS
OSS
米国
カナダ
米国
米国
メーカー名
日本 CG サービス Jean-Philippe
GanttProject
The Omni Group Southpaw
5th Kind
Shotgun Software
Lang
Team
Technology
URL
http://jcgs.co.jp
http://www.redmin http://www.ganttp http://www.omnigr http://www.southp http://www.5thkin http://www.shotgu
e.org/
roject.biz
oup.comawtech.com
d.com
nsoftware.com
関連製品
－
－
－
OmniGraffle,Omn－
CORE,
ARC, Revolver, TANK
iFocus,OmniOutli
DIGISCOPE
ne
対応デバイスアプリケーション PC, モバイルを含 ウェブブラウザ
Mac,iPad
PC
PC
PCの動作環境に依存 む
ウェブブラウザ
対応プラットフォ アプリケーション クロスプラットホ Windows, Linux, MacOSX,iOS
クロスプラットホ?
CentOS, RHEL
MacOSXーム
ームの動作環境に依存 ーム
小項目

JCGS Library

ライセンス形態

契約期間の使用

販売方法

相談

リリース時期・間隔
価格

RedmineOmniPlan

GNU
General GNU
General 購入
Public License v2 Public License－－－

GanttProject－2.2.0 [2012/12/18] 最新：2.6－－

オープンソース?

月極

オンライン販売－?

オンライン販売

最新：2$199.99

最新：3.9.0.rc04
－

RV

COPRA

HIERO

米国
Tweak Software

wiredrive

Keyframe Concept

ドイツ
イギリス
CinePostproductio THE FOUNDRYn
http://www.tweaks http://copra.de
http://www.thefou
oftware.com
ndry.co.uk
RVIO, RV-SDI
On Set Dailies
Nuke米国
wiredrive

PC

MacOSX, iPhone, MacOSX, iPhone,
iPad
iPad

iPad, iPad mini

Cross Platform 64 PHP の動作する
bit, Linux, Mac HTTP サーバ
OSX, Windows

PC

ノルウェー
Drylabhttp://www.wiredr http://www.drylab.
ive.comno－
Cam Report
Keyframe Dailies

Mac OS X (10.6.8－
or later), Windows
7 (64 bit) , Linux(RHEL 5.4) 64-bit
購入, 1 年毎に保守 サーバ貸しは HDD 購入
SaaS
容量
自前はプロジェクト単位
sales@tweaksoftw 未定
リ セ ラ ー に よ る 販 オンライン販売
are.com
売

Mac OS X, iOS?

Cam Report: App
Store
Keyframe
Dailies: ?
?
最新：4.2?
最新：4
最新：1.5 / 1.6β?
最新：2.6.1
必 要 な セ ッ ト ア ッ 1 ユ ー ザ ー : ラ イ セ ン ス ： ク ラ イ ア ン ト は 無 ノ ー ド ロ ッ ク ： 月額：$349/15GB?
プ と 多 く の 機 能 に $19~$149
償$299,$5,000
メ
ン
テ
ナ
ン
ス
：
依存
$99/year247