白完・編集プロジェクト・権利台帳をどう引き継ぐか―映像制作会社M&Aの素材・ライセンス・アーカイブ実務

1．なぜ映像アーカイブの引継ぎが企業価値を左右するのか

地方の映像制作会社では、過去案件の再編集が「小さく見えて継続性の高い売上」になっていることがあります。自治体の観光映像を今年度のロゴと統計値に差し替える、採用動画へ新しい社員インタビューを加える、周年映像から短尺のSNS版を作る、展示会用の16:9映像をサイネージ向け9:16に組み替える、といった依頼です。撮影をやり直さずに済むため発注者にも利点があり、過去の経緯と素材の所在を知る制作会社へ相談が戻ってきます。

ところがM&A後に、納品したMP4しか残っていない、担当ディレクターの個人ディスクに撮影素材がある、Premiere Proのプロジェクトはあるがリンク切れで開かない、使用したフォントが分からない、出演同意がウェブ公開まで含むのか確認できない、という状態になると、買い手は再編集の依頼を受けてもすぐに見積もれません。技術的には作れても、利用条件を説明できなければ公開判断を止めざるを得ない場合もあります。つまりアーカイブの不備は、ストレージの問題ではなく、顧客対応力、受注速度、原価、リスク管理の問題です。

逆に、案件番号を起点として、完成マスター、白完、撮影オリジナル、編集プロジェクト、権利台帳、契約・発注書、納品履歴、担当者メモが追える会社は、代表者の記憶に依存しにくくなります。買い手は「何年分の素材が何TBあるか」だけでなく、「どの範囲なら再利用の相談に応じられるか」「再編集に必要な環境を再現できるか」「誰の確認を得れば公開できるか」を把握できます。この可視性は、DDの説明を円滑にし、成約後の顧客離れや制作停止を抑える材料になります。

ただし、データが存在することと、自由に利用できることは同義ではありません。発注者へ著作権を移転した完成映像であっても、制作会社が実績として公開できるとは限りません。反対に、制作会社が撮影オリジナルを保管していても、被写体、ロケ地、音楽、ストック素材、機密情報などの条件により別用途への転用が制限される場合があります。M&Aで会社や事業を承継しても、個別契約やサービス利用権が当然に同じ形で移るとは限りません。したがって、「持っているデータ」と「説明できる利用根拠」をセットで引き継ぐ必要があります。

アーカイブ価値を四つに分けて考える

1. 再現価値：過去の番組、CM、企業映像、行政広報を同じ品質で修正・再出力できること。
2. 関係価値：案件の背景、発注者の確認手順、出演者や協力先との連絡経路が残っていること。
3. 証拠価値：いつ何を納品し、どの条件で許諾を得たかを契約、メール、台帳などで説明できること。
4. 学習価値：撮影設計、カラー、字幕、テロップ、音量、命名規則など、次回制作を速くする知見が残っていること。

譲渡企業にとっては「古いHDDの片付け」に見える作業でも、買い手にとっては将来の再受注能力を確認する作業です。譲渡を考え始めた段階で、まず重要顧客20社、直近3年、再編集頻度の高い案件から整えると、全件を一度に整理するより現実的です。譲渡企業側の準備全体は映像制作会社の売却を検討される方へ、支援範囲はサービス案内も併せてご覧ください。

2．「完成品」だけでは足りない―引き継ぐデータの全体像

映像案件のデータは、一つの「動画ファイル」ではなく、制作工程で役割が異なる複数の層から成ります。引継ぎでは、ファイル拡張子だけで分類せず、「何のために残すのか」「どの成果物を再生成できるのか」を明確にします。会社ごとの呼称差も大きいため、白完、テロップなし、クリーン、ノンテロップなどの言葉を台帳上で定義しておくことが重要です。

第一層：契約・企画・進行の記録

見積書、発注書、業務委託契約書、仕様書、企画書、絵コンテ、台本、香盤表、撮影許可、出演同意、楽曲や素材のライセンス証跡、校正履歴、納品書、請求書、完了報告書などです。自治体案件では、公募時の仕様書と最終的な変更指示が離れた場所に保存されていることもあります。契約文書だけを見て終わらせず、メールや議事録に残る追加条件、納品時に確定した公開媒体、公開期間、二次利用の相談履歴も索引化します。

第二層：撮影・収録オリジナル

カメラオリジナル、音声レコーダーのWAV、ドローン、写真、画面収録、ナレーション素材、ライブ配信のISO収録、代理店や発注者から受領した素材が該当します。プロキシだけが残り、オリジナルが別HDDにあるケースや、カメラカードのフォルダ構造を崩してコピーしたためメタデータ連携が失われているケースに注意します。カメラ機種、コーデック、フレームレート、色空間、撮影日、カード番号、チェックサムの有無を記録すると、将来の復元に役立ちます。

第三層：制作途中の資産

Premiere Pro、After Effects、DaVinci Resolve、Final Cut Proなどの編集プロジェクト、PhotoshopやIllustratorのデザインデータ、モーショングラフィックステンプレート、MAセッション、整音済み音声、カラーグレーディング情報、字幕原稿、翻訳対照表、サムネイルデータが該当します。プラグイン、LUT、フォント、リンク素材がなければ、プロジェクトファイル単体では再編集できません。使用バージョン、OS、外部依存物を一緒に残します。

第四層：中間マスターと派生物

白完、テロップ入りマスター、音声パラ、ME、ナレーションなし、BGMなし、字幕なし、字幕焼き込み、クローズドキャプション、放送用ファイル、ウェブ用圧縮版、縦型9:16、正方形1:1、短尺15秒・30秒、多言語版などです。中間マスターが揃っていれば、古い編集環境を完全に再現できなくても一定の改訂に対応できることがあります。逆に最終MP4しかないと、ロゴ差し替えのために映像全体を再構築する事態になり得ます。

第五層：運用・公開の情報

YouTubeやVimeoの公開設定、ウェブCMS、SNS、デジタルサイネージ、広告管理画面、動画配信プラットフォーム、アクセス解析、CDN、字幕ファイル、サムネイル、概要欄、公開日、終了日、限定公開URLなどです。完成ファイルを引き継いでも、公開先の所有者と管理者が不明なら更新や非公開化ができません。公開アカウントは、編集素材とは別にアカウント台帳で管理します。

「案件パッケージ」という単位を作る

実務では、案件ごとに最低限の引継ぎセットを定義すると漏れが減ります。たとえば「00_契約権利」「01_企画」「02_撮影オリジナル」「03_音声」「04_編集PJ」「05_デザイン」「06_中間マスター」「07_納品」「08_公開運用」「09_引継ぎメモ」という共通構造を用い、案件台帳にルートパスを記載します。フォルダ番号は絶対条件ではありませんが、検索結果だけに頼らず、人が初見で意味を理解できる構造が重要です。

同じ素材が複数案件に使われる場合は、コピーを無秩序に増やすのではなく、原本の管理場所と利用先案件を台帳で関連付けます。ただし、将来ストレージを分離する可能性がある場合、ショートカットやシンボリックリンクだけに依存すると移行後に切れるため、移行設計と一緒に決めます。「原本」「作業コピー」「納品コピー」の区別が曖昧な会社では、削除前にハッシュ値、容量、更新日時を比較し、重複候補を特定します。DD中に大胆な重複削除を行う必要はありません。まず所在と関係を把握し、削除はバックアップと承認手順を整えた後に行います。

3．白完・パラ素材・字幕・縦型・多言語版の整理

「白完がある」と聞いても、会社や放送局、案件によって指す内容が異なります。映像内のテロップを外したもの、字幕のみ外したもの、ロゴや図版まで外したもの、音声構成は完成版のままのものなど、同じ呼称でも中身は一定ではありません。引継ぎ時は用語だけで判断せず、ファイルを再生し、映像・音声・字幕の状態を項目別に記録します。

白完は「何が白いか」を明記する

台帳には、画面テロップ、字幕、ロゴ、日付、価格表示、権利表記、モザイク、図表、商品パッケージなど、焼き込まれている要素と外されている要素を記載します。モザイクやぼかしはプライバシー・契約上必要な処理である場合があるため、「白完だから除去されている」と思い込むと危険です。白完にも必要なマスキングが残っているか、あるいはマスク前のクリーン素材なのかを区別します。

推奨するファイル名は、案件番号、言語、画角、尺、映像状態、音声状態、版数、日付が読み取れるものです。例として「A24031_JA_16x9_180s_CleanText_MEplusN_V05_20260331.mov」のように構成します。ただし既存案件を一括で改名すると編集リンクが切れるため、原本名を維持したまま台帳へ論理名を付ける方法も有効です。改名する場合は、編集プロジェクトのコンソリデート後やリリンク検証とセットで行います。

パラ素材は再編集の保険になる

音声のパラ素材には、ナレーション、出演者、インタビュー、現場音、BGM、SE、MEなどがあります。将来ナレーションだけを更新する可能性があるなら、ミックス済みマスターだけでなく、少なくともナレーションとその他音声を分けたステムがあると作業しやすくなります。放送・配信・自治体案件では納品仕様が異なるため、チャンネル割当、ラウドネス、サンプルレート、ビット深度、ピーク処理を納品票に残します。

映像側のパラ素材としては、テロップベース、ロゴアニメーション、背景ループ、地図、図表、人物切り抜き、アルファ付き素材、サムネイルなどがあります。After Effectsプロジェクトだけでなく、中間レンダーも残すことで、将来プラグインやフォントが使えなくなった場合の代替になります。ただし中間レンダーを別用途で使えるかは元素材の利用条件に左右されるため、権利台帳との関連付けが欠かせません。

字幕は「焼き込み」と「データ」を分ける

字幕焼き込み版しか残っていないと、誤字修正や言語差し替えのたびに映像を作り直すことになります。SRT、WebVTT、TTMLなどの字幕ファイル、タイムコード付き台本、固有名詞表、読み仮名、翻訳メモ、監修済み原稿を保存します。話者名、効果音表記、改行、文字数、漢字表記のルールも残せば、アクセシビリティ対応や別媒体展開で再利用しやすくなります。

自動文字起こしの未校正データは、承認済み字幕と混在させないよう状態を明記します。インタビューに未公開情報や個人情報が含まれる場合、文字起こしも機密データです。動画より検索しやすい分、アクセス範囲を狭める必要があることもあります。翻訳会社や字幕制作会社へ渡したデータ、外部サービスへアップロードした履歴も確認します。

9:16・1:1・短尺版は別成果物として管理する

横型16:9から縦型9:16を作る際は、単純なクロップだけでなく、人物の位置、テロップのセーフエリア、UIとの重なり、尺、冒頭のフック、BGMの長さが変わります。SNSプラットフォームごとの推奨仕様は更新され得るため、引継ぎでは「当時どの仕様で納品したか」を記録し、将来の再出力時は最新仕様を確認します。縦型用のシーケンス、再配置したグラフィック、サムネイル、投稿文を一つの派生版としてまとめます。

短尺版は、元の長尺版と権利範囲が同じとは限りません。出演者や楽曲の許諾が「自社ウェブサイト掲載」「イベント会場上映」など媒体を限定していると、SNS広告への展開には追加確認が必要になる場合があります。「元映像から作ったから使える」とせず、派生先の媒体、期間、地域、有償広告かオーガニック投稿かを台帳で確認します。

多言語版は翻訳の根拠まで残す

多言語版には、翻訳原稿、対訳表、固有名詞、監修者、校了日、ナレーター、音声収録条件、字幕ファイル、言語別サムネイルが必要です。観光・行政・製品説明では、施設名や制度名が後から変わることがあります。どの日本語原稿を起点に翻訳したか、どの版で監修を受けたかを残さないと、改訂時に差分を判断できません。

翻訳成果物の著作権や再利用条件、ナレーター音声の利用媒体・期間、合成音声サービスの利用条件も確認対象です。多言語版があること自体を権利クリアとみなさず、言語ごとに根拠文書へリンクします。ファイル名には言語コードを付け、たとえば「zh-Hans」と「zh-Hant」のように表記体系が異なるものを「中国語」で一括しない方が安全です。

4．権利台帳を案件フォルダと結び付ける

権利台帳は、法律用語を並べた一覧ではなく、現場が「この映像を来月のSNS広告へ再編集してよいか」を確認するための索引です。理想は、一つの案件番号から、契約原文、許諾書、素材ファイル、利用先、期限、要確認事項まで辿れることです。台帳だけが立派でも、原本へリンクできなければDDの検証に時間がかかります。反対に契約書が大量に保管されていても、どのカット・楽曲・出演者に対応するか分からなければ判断材料になりません。

権利台帳の基本項目

• 案件番号、案件名、発注者、代理店、制作期間、納品日
• 対象素材の名称、素材ID、ファイルパス、サムネイルまたはタイムコード
• 権利・許諾の種類、権利者または許諾者、契約当事者
• 利用媒体、利用目的、利用期間、利用地域、言語、改変・編集の可否
• 第三者への再許諾、発注者への納品、グループ会社利用、広告配信の扱い
• クレジット表記、報告義務、追加料金、更新手続、終了時の削除・返却
• 実績公開の可否、公開可能日、掲載媒体、事前承認の要否
• 証跡の種類、原本パス、締結・同意日、確認担当者、最終確認日
• 不明点、例外、次回利用前に確認すべき相手、専門家確認の要否

「無期限」「買い切り」「全部OK」といった略語は避けます。現場では便利でも、何が無期限なのか、誰が何を買い切ったのか、二次利用や実績公開を含むのかが読み取れません。原文の該当箇所を要約する場合は、要約と原文を区別し、原本のページ・条番号・メール日付を付けます。解釈が割れる条件は、台帳上で断定せず「要確認」として残します。

契約の主語を揃える

M&Aでは「誰が契約当事者か」が重要です。法人契約のつもりでも、ストック素材やクラウドが代表者個人の名義、出演依頼がディレクター個人のメール、ロケ許可が発注者名義ということがあります。株式譲渡、事業譲渡、会社分割などスキームによって確認事項は変わり、チェンジ・オブ・コントロール条項、譲渡禁止、事前通知・同意、契約更新などが関係する可能性があります。台帳に「契約名義」と「実際の支払者」「管理アカウント」を分けて記録し、最終判断は契約原文と専門家の助言で行います。

文化庁のひな型は「確認観点」を学ぶ入口にする

文化庁の著作権契約書作成支援システムには、会社イメージ映像や社員研修映像等のビデオ制作を想定した契約書式があります。同システム自身が、前提条件を読み、当事者間の条件に合わせて手直しする必要があること、提供されるものは契約書案であることを注意事項として示しています。また、制作者以外に映像全体の形成へ創作的に寄与した者がいる場合は、前提に応じた修正が必要と説明しています。既存契約を機械的に置き換えるのではなく、権利帰属、利用許諾、著作者人格権、素材の持込み、第三者権利など、確認観点を洗い出す入口として使うのが適切です。

証跡の強さを段階表示する

実務では、すべての古い案件で完璧な契約書が見つかるとは限りません。そこで証跡を「A：署名・押印済み契約書またはサービスのライセンス記録」「B：発注書・仕様書・許諾メール」「C：議事録・チャット・請求記録」「D：担当者の記憶のみ」「U：不明」のように段階表示します。これは法的効力を一律評価するものではなく、追加確認の優先順位を付けるための運用ラベルです。高頻度で再利用する素材がDやUなら、譲渡企業の担当者が在籍している間に関係者へ事実確認し、将来利用の都度承認を取る手順を整えます。

権利台帳は一度作って終わりではありません。納品時、実績公開時、二次利用依頼時、契約更新時に更新し、更新者と日付を残します。M&A後は買い手側の案件管理システムへ統合することもありますが、原本の台帳を読み取り専用で保全し、移行前後の対応表を残すと、情報が欠落した際に追跡できます。

5．出演・ロケ・BGM・フォント・ストック素材を確認する

映像には複数の第三者要素が重なります。映像全体の契約だけを確認しても、出演者、建物・施設、楽曲、写真、イラスト、フォント、テンプレート、地図、商品パッケージなどの条件が別に存在することがあります。DDでは「素材種別ごとの確認表」を使い、重要案件のタイムラインを見ながら第三者要素を抽出します。

出演者・ナレーター・インタビュー対象者

出演同意では、氏名・肖像・音声等について、対象作品、利用目的、媒体、期間、地域、編集・抜粋、字幕・翻訳、広告利用、第三者提供、実績公開、撤回や削除相談の窓口を確認します。社員出演であっても、退職後の利用を当然視しない方が安全です。通行人やイベント参加者が映り込む案件、未成年者、医療・福祉・教育現場、センシティブな体験談を含むインタビューは、撮影時の説明と公開範囲が一致しているかを丁寧に見ます。

口頭同意しかない古い案件は、直ちに全データを廃棄するのでも、無条件に利用継続するのでもなく、公開状況、識別可能性、契約主体、再利用予定、発注者の方針を整理します。必要なら買い手の法務・発注者と協議し、再同意、差し替え、ぼかし、公開停止などの選択肢を検討します。連絡先を引き継ぐ場合は、個人情報の取扱い、目的、アクセス権限にも配慮します。

ロケ地・施設・美術・商品

自治体施設、学校、病院、工場、寺社、商業施設、私有地、ドローン飛行を伴う場所などでは、撮影許可と公開・再利用の条件が異なることがあります。撮影日は許可されていても、広告利用、期間延長、別企業への素材提供、施設名の表示には追加確認が必要な場合があります。ロケ許可書、申請メール、担当部署、緊急連絡先、撮影可能範囲、公開前確認の有無を台帳に残します。

美術品、ポスター、モニター画面、商標、車両ナンバー、個人情報が映る書類などは、背景にあるだけでも公開時の確認対象になり得ます。白完や撮影オリジナルには、完成版で隠した情報がそのまま残っていることがあります。そのため、完成版を一般権限、白完を制作権限、未処理オリジナルを限定権限とするなど、データの機密度に応じて保存領域を分けます。

BGM・SE・楽曲・演奏

音楽は、作詞・作曲、音源、実演、編曲、ライブラリ利用など確認対象が複数あります。購入した音源の注文履歴、ライセンス証明、契約プラン、登録アカウント、利用作品、公開媒体、広告利用、放送、イベント上映、複製数、地域、期間、クレジット条件を記録します。「ロイヤリティフリー」は一般に無料や無制限を意味するとは限らず、各サービスのライセンス条件に従う必要があります。サブスクリプション期間中に取得した素材の扱い、解約後の既存作品、再編集・新規作品への使用、クライアントへの成果物引渡しなどはサービスごとに確認します。

買い手が同じサービスを契約しても、譲渡企業が過去に取得したライセンス証跡が自動的に買い手へ移るとは限りません。法人の同一性が維持される株式譲渡でも、アカウント名義や管理者変更の手続が必要な場合があります。事業譲渡では契約移転の同意が論点になることがあります。楽曲ファイルをコピーする前に、サービス名、契約名義、取得日、ライセンスID、対象作品を一覧化し、公式規約またはサポートへ個別確認します。

フォント

テロップやモーショングラフィックスで使うフォントは、完成映像へ画像として固定された状態と、編集可能データで再使用する状態を分けて考えます。フォントファイルを編集プロジェクトと一緒に無断コピーしてよいとは限りません。契約プラン、ライセンス取得者、利用端末・ユーザー、映像やWebフォントへの利用範囲、第三者への提供、契約終了後の扱いを公式EULAで確認します。モリサワ等の製品でも契約種別ごとに条件があるため、「以前使えていた」ことだけを根拠に買い手環境へインストールしません。

フォント引継ぎ表には、フォント名、ウェイト、提供元、契約種別、契約者、使用案件、代替候補、アウトライン済み素材の有無を記載します。再契約が必要な場合に備え、代表的なテロップを静止画またはアルファ付き中間レンダーで残し、デザイン確認用PDFも保存します。ただし、これらの中間物の作成・利用自体も契約条件に従います。

ストック写真・動画・テンプレート

Adobe Stockを含むストックサービスは、標準・拡張等のライセンス区分、エディトリアル専用素材、素材そのものを主価値とする配布、クライアントワークへの利用、ユーザー数などに条件があります。アセットID、プレビューではなくライセンス取得済みであること、取得アカウント、請求記録、対象案件を残します。色調補正やトリミングができる場合でも、禁止用途や人物・建物に関する注意が別にあることがあります。

動画テンプレートやプラグインでは、プロジェクトファイルへ素材本体が含まれていても、次の制作会社が編集利用できるとは限りません。譲渡企業のアカウントから買い手のアカウントへ単にログイン情報を渡すのではなく、公式のチーム機能、ライセンス移管、買い手側での再購入、レンダー済み中間素材の利用など、許容された方法を選びます。利用規約は更新されるため、DD時点と実際の移行時点で再確認します。

二次利用と実績公開

発注者が完成映像を利用できる範囲と、制作会社がポートフォリオとして公開できる範囲は別に確認します。公開前の事前承認、解禁日、掲載可能な尺、クレジット、受賞歴の表現、機密情報、出演者の許諾、広告キャンペーン終了後の削除などを記録します。ウェブサイトの実績ページだけでなく、営業資料、採用資料、SNS、コンペ応募、展示会リール、買い手側のウェブサイトへ移す場合も対象媒体が変わる可能性があります。

M&Aを発表する際に過去実績を買い手のブランドで紹介したいことがあります。しかし「制作会社の実績公開可」と「別法人・別ブランドでの掲載可」が同じとは限りません。重要事例は、成約前から発注者への説明タイミングと確認文面を準備し、秘密保持契約やM&A情報の管理に配慮しながら進めます。

6．編集プロジェクトを「開ける資産」にする

編集プロジェクトは、ファイルが存在するだけでは資産になりません。正しいアプリとバージョンで開き、リンク素材を認識し、フォント・プラグイン・LUT・コーデックが揃い、想定した映像と音声を出力できて初めて実用性があります。DDでは全案件を開くのではなく、売上規模、再編集頻度、主要顧客、制作時期、使用ソフトを考慮してサンプルを選び、復元テストを行います。

プロジェクトごとの環境票

• 編集アプリ、バージョン、OS、使用PCの概略
• シーケンス設定、解像度、フレームレート、色管理、音声設定
• リンク素材のルート、プロキシの有無、キャッシュと原本の区別
• 使用フォント、プラグイン、LUT、コーデック、テンプレート
• Dynamic Link、Fusion、外部MA、カラー、字幕ツール等の連携
• 最終レンダーに使用したシーケンスと書き出しプリセット
• 既知の警告、オフライン素材、代替済み素材、未確定箇所

Premiere Proではプロジェクトマネージャー等の収集機能、DaVinci Resolveではプロジェクトアーカイブ、Final Cut Proではライブラリとメディア管理など、アプリごとに集約方法があります。ただし、収集機能ですべての外部依存物やライセンスが移るわけではありません。圧縮、トランスコード、ネスト、Dynamic Link、クラウド同期、サードパーティプラグインなどにより結果が変わるため、コピー後に別端末で開き、短い検証レンダーを行います。

Adobe等のアカウントは「パスワード受渡し」で済ませない

Adobeの基本利用条件では、各ライセンスは一人のみが使用し共有できない旨などが示されています。またAdobeの公式サポートは、永続ライセンス製品の譲渡手続を案内する一方、Creative Cloud等のサブスクリプション製品はその譲渡手続の対象外としています。これは「どのAdobe製品も一切承継できない」ことを意味するのではなく、契約形態ごとに手続と可否を確認すべきことを示します。法人向け契約、チームメンバーの再割当、管理者変更、請求先変更、契約移管等について、契約書と公式サポートで個別に確認します。

個人Adobe IDを会社共通アドレスへ変える、同じパスワードを買い手へ渡す、といった処理は、規約、本人性、多要素認証、個人データ、他案件データの混在などの問題を招きます。まず法人と個人のアカウントを棚卸しし、会社管理のチーム環境へ正規に移す、新規ライセンスを買い手へ割り当てる、クラウドドキュメントを書き出して管理領域へ移すなど、サービスが認める方法を選びます。

依存物を三種類に分ける

1. 再取得可能：買い手が正規契約すれば同じバージョンや互換版を入手できるアプリ、フォント、プラグイン。
2. 代替可能：見た目や機能を確認し、別フォント、再レンダー、中間マスターで置き換えられるもの。
3. 代替困難：廃版プラグイン、作者不明テンプレート、個人アカウント限定素材、壊れた外部ディスクなど。

代替困難なものほど、譲渡企業の編集環境が動いている間に、最終版、白完、音声ステム、アルファ付きグラフィック、字幕データ、静止画リファレンスを書き出します。ただし、出力した中間素材の利用条件が元ライセンスを超えないよう確認します。古いMacやワークステーションをそのまま譲渡する場合も、端末内の個人情報、他社機密、OS・アプリライセンス、暗号化鍵、保守契約を確認し、資産譲渡リストへ記載します。

復元テストの合格基準

「開いた」だけで合格にせず、プロジェクト起動時の警告、オフライン素材数、フォント置換、プラグイン欠落、尺、冒頭・中盤・末尾の絵と音、字幕、カラー、音声チャンネル、書き出し結果を確認します。完成マスターと検証レンダーを波形・フレーム単位で完全一致させる必要がある案件もあれば、将来のテロップ修正が可能なら十分な案件もあります。用途別にA「完全再現」、B「主要修正可能」、C「中間マスターから限定修正」、D「完成版のみ」、U「未検証」と分類します。

検証結果には、テスト日、実施者、端末、アプリバージョン、出力ファイル、差異、次回の手順を残します。担当編集者が口頭で「たぶん開く」と説明するだけでは、退職後に再現できません。可能なら画面録画やスクリーンショットを添え、プロジェクトの開き方、オンライン化、書き出し先まで短いランブックにします。

7．NAS・クラウド・LTO・バックアップの棚卸し

映像会社のストレージは、編集用高速NAS、経理・契約書用ファイルサーバー、クラウドストレージ、持出しSSD、過去案件HDD、LTOテープ、編集者のローカルディスクに分散しがちです。M&Aでは容量だけでなく、「正本はどれか」「障害時に戻せるか」「誰が鍵を持つか」「保守が続くか」を確認します。

ストレージ台帳に必要な情報

• 機器・サービス名、設置場所、所有者、資産番号、購入・契約年月
• 総容量、使用量、ファイルシステム、RAID構成、暗号化、共有プロトコル
• 管理者、一般利用者、外部共有、サービスアカウント、認証方式
• 保存している案件範囲、正本・複製・バックアップの区分
• バックアップ先、頻度、世代数、オフサイト保管、最終復元テスト日
• 保守契約、保証期限、ファームウェア、障害履歴、交換ディスク
• 電源、UPS、ネットワーク帯域、VPN、リモートアクセス、ログ
• 廃棄・返却予定、リース、レンタル、第三者預託、持出し状況

RAIDはバックアップの代わりではない

RAIDは一部ディスク障害への可用性を高めますが、誤削除、ランサムウェア、ファイル破損、機器全損、火災・水害、管理者ミスまで自動的に防ぐものではありません。同期型クラウドも、削除が同期される設計なら単独では十分なバックアップにならないことがあります。正本とバックアップの障害原因が共通にならないよう、媒体、認証、場所、世代を分けます。

よく知られる「3-2-1」は、少なくとも三つのコピー、二種類の媒体、一つを別場所に置くという考え方です。ただし、案件の機密性、復旧時間、容量、費用、契約上の保存要件に応じて設計します。クラウドから大量データを復元する際の時間と転送料、LTOを読むドライブとソフトの世代、暗号化鍵、オフサイト保管先への入館手順まで含めなければ、緊急時に使えません。

NASの確認

NASでは、共有フォルダ一覧、アクセス制御リスト、スナップショット、レプリケーション、SMART情報、容量逼迫、重複排除、バックアップジョブ、通知先を確認します。代表者の個人メールへ障害通知が届く設定は、成約後に見落とされやすい箇所です。ローカル管理者が一人だけ、共通パスワード、インターネットから管理画面が直接公開、退職者アカウントが残存、といった状態は切替計画へ入れます。

共有名やIPアドレスを急に変えると、編集プロジェクトの絶対パスや自動バックアップが切れることがあります。旧パスを一時的にエイリアスで維持する、ドライブマッピングを揃える、プロジェクト収集後に新パスへリリンクするなど、編集ソフトと運用を踏まえて段階移行します。大容量コピー中は制作帯域を圧迫するため、営業時間外の転送、帯域制御、増分同期を検討します。

クラウドストレージの確認

Google Workspaceの共有ドライブは、ファイルが個人ではなくチームに属し、メンバーが離れても共有ドライブ内に残ると公式ヘルプで説明されています。一方、マイドライブから共有ドライブへの移動には、外部ユーザー所有ファイルなど制限があります。Dropboxのチーム向け機能でも、削除したメンバーのファイル移行には管理者権限、回数、履歴期間等の条件が示されています。Microsoft 365も、退職者のOneDriveへ別担当者がアクセスするための管理手順と保持上の注意を案内しています。

したがって、クラウド上に見えていることをもって会社資産として永続的に管理できるとは限りません。個人領域、チーム領域、外部所有、共有リンク、ゲスト、同期端末、保持期間、ごみ箱、バージョン履歴、リージョン、ダウンロード制限を確認します。M&Aの最終契約前に大量移動を始めると機密性や業務へ影響するため、DDでは一覧とサンプル確認を中心にし、実移行は権限と責任分界を定めてから実施します。

LTO・外付けHDD・オフライン媒体

LTOは長期保管に利用されますが、テープだけあっても、対応ドライブ、クリーニング、接続インターフェース、LTFSまたはバックアップソフト、カタログ、暗号化鍵がなければ復元できません。テープ番号、世代、作成日、内容、容量、保管場所、暗号化、検証日、複製有無を台帳化し、重要案件から読み出しテストを行います。ラベルと中身が一致するかもサンプルで確認します。

外付けHDDは、棚に並んだ台数だけでなく、電源アダプター、独自ケース、接続規格、暗号化、健康状態を確認します。同じ案件のディスクが複数ある場合、最終更新日だけで正本を決めず、ファイル一覧とハッシュで比較します。長期間通電していない媒体は、DDの場で唯一の原本に直接負荷をかけるのではなく、専門家の助言を得て複製・読み出しを行う選択肢もあります。

バックアップは「復元できた日」で評価する

管理画面に「成功」と表示されても、必要なフォルダが対象外、暗号化鍵が不明、世代が短い、復元先容量が足りないことがあります。重要案件、権利台帳、会計・契約文書、編集プロジェクトを選び、別環境へ復元して、ファイル数、容量、ハッシュ、アプリでの起動を確認します。目標復旧時間と許容損失時間を業務側と合意し、何を何時間で戻すかを明文化します。

8．DDで何を、どの順番で見るか

映像アーカイブDDの目的は、すべてのファイルを鑑賞することではありません。企業価値と成約後の事業継続に影響する論点を、限られた期間で検証可能な形にすることです。まず事業、顧客、契約、制作工程、システムの地図を作り、重要性と不確実性の高い領域へサンプルを当てます。秘密保持と個人情報に配慮し、必要以上の撮影オリジナルをデータルームへ複製しないことも大切です。

DD開始前に譲渡企業が用意する五つの一覧

1. 案件一覧：直近3〜5年を目安に、顧客、売上、制作種別、納品日、再編集実績、保存先を記載する。
2. ストレージ一覧：NAS、クラウド、HDD、LTO、ローカル端末、外部編集者保管を含める。
3. アプリ・サービス一覧：編集、MA、フォント、ストック、配信、ファイル送付、校正、パスワード管理等を契約名義とともに記載する。
4. 権利・契約一覧：基本契約、個別発注、出演・ロケ、楽曲・素材、実績公開、秘密保持を関連案件と結ぶ。
5. 担当者一覧：営業、プロデューサー、ディレクター、編集、IT管理、外注先について、属人化している作業を示す。

一覧作りの段階で不明な項目が出ても、空欄を隠さず「不明」「確認中」「推定」と区別します。DDで問題になるのは不明点があること自体よりも、不明点の範囲と対応策が見えないことです。たとえば「2018年以前の撮影原本はHDD棚にあるが、権利台帳なし。主要5社分を優先確認中」と説明できれば、買い手は追加調査の費用と時間を見積もれます。

フェーズ1：事業とデータのマッピング

最初に、売上上位顧客、継続案件、利益率の高い案件、再編集が多い案件、自治体・放送・医療等の取扱注意案件を抽出します。それぞれについて、受注から企画、撮影、編集、校正、納品、保管、二次利用までの流れを一枚に描きます。どの段階でどのシステムを使い、誰が承認し、何を成果物として残すかを確認すると、単なるファイル一覧から業務継続の地図へ変わります。

次にデータ量を把握します。総容量だけでなく、年別、顧客別、媒体別、ストレージ別、正本・複製別に集計します。100TBある会社と聞いても、その大半が重複バックアップなのか、撮影オリジナルなのか、復元不能な古い媒体なのかで意味が違います。ファイル数が極端に多い案件は、クラウド移行の時間や課金、ウイルススキャン、権限継承にも影響します。

フェーズ2：重要案件のサンプルテスト

サンプルは、売上上位だけでなく、古い・新しい、自治体・企業・放送、内製・外注、Premiere・Resolve等を混ぜます。一例として、上位顧客各2件、再編集頻度上位10件、直近四半期5件、5年以上前5件、高機密案件3件を候補にし、重複を除いて20〜30件を深掘りします。会社規模とDD期間に応じて増減し、選定理由を記録します。

各サンプルでは、契約と仕様書、権利証跡、撮影オリジナル、編集プロジェクト、完成マスター、白完、字幕・多言語、納品記録を突合します。ファイルを開き、プロジェクトを再リンクし、30秒程度の検証レンダーを作り、マスターと比較します。完成ファイルのメタデータ、ファイル名、納品書の記載が一致するかも見ます。差異があれば、その案件だけの例外か、全社的な運用かを追加サンプルで確認します。

フェーズ3：契約・利用条件の突合

権利DDでは、台帳の記載を鵜呑みにせず、重要項目を原文と突合します。特に、著作権・成果物の帰属、第三者素材、二次利用、改変、再許諾、実績公開、契約上の地位・権利義務の譲渡、秘密保持、個人情報、データ返却・消去、保存期間を確認します。サービス利用規約は契約時点と現在で異なる場合があるため、購入日、プラン、注文履歴、当時のライセンス証明が重要です。

契約の解釈を制作担当者だけで決めず、法務担当または専門家へ渡す論点表を作ります。論点表には、事実、原文、現場の理解、想定する二次利用、確認したい質問を分けて記載します。「著作権は発注者に帰属」と書かれている一方で、制作会社の実績公開が長年黙認されている、といった事実も、権利の断定ではなく経緯として整理します。

フェーズ4：セキュリティと運用の確認

制作データには、未発表製品、経営者インタビュー、児童・患者、工場内部、位置情報、従業員名簿などが含まれることがあります。アクセス権、外部共有、公開リンク、退職者アカウント、共通パスワード、端末暗号化、持出し、ログ、マルウェア対策、バックアップを確認します。DD用にデータをコピーすると複製先が増えるため、閲覧権限、ダウンロード可否、透かし、期限、削除証跡も設計します。

外注先やフリーランスの端末に原本が残る場合は、契約上の返却・削除条件と実態を確認します。長年の信頼関係を否定するのではなく、成約後も同じ人と仕事を続けられるよう、会社管理の受渡し領域、案件終了時の返却確認、秘密保持、バックアップ責任を整えます。個人所有機器を買い手が無断で調査することは避け、当事者の合意と適切な手順を取ります。

DDで見つかりやすい赤信号

• 主要顧客の完成マスターが担当者の個人クラウドにしかない。
• 白完はあるが、完成版で隠した個人情報が見える状態で全社員に共有されている。
• ストック素材の取得アカウントが退職者名義で、購入履歴にアクセスできない。
• 同一のAdobe IDやNAS管理者パスワードを複数人で共有している。
• バックアップジョブは稼働しているが、過去一年に復元テストがない。
• LTOテープはあるが、対応ドライブ、カタログ、暗号化鍵の所在が不明。
• 編集PJに大量のリンク切れがあり、元素材のHDD番号と対応していない。
• 出演・ロケ許諾の利用期間が終了している可能性があるのに、公開が継続している。
• 発注者素材と自社撮影素材の区別がなく、別案件へ流用されている。
• 共有リンクに有効期限がなく、退職者や外部協力者が継続アクセスできる。

赤信号が見つかったときは、ただちに「取引中止」と結論付けるのではなく、影響範囲、発生可能性、検知可能性、是正費用、顧客影響、対応期限を評価します。成約前に解決する事項、価格や契約条件へ反映する事項、成約後100日で改善する事項、当面受注を制限する事項に分けます。対応策と責任者が明確なら、リスクは管理可能な課題へ変わります。

DD成果物

最終成果物は、①システム・データ地図、②案件・権利・アカウント・媒体台帳、③サンプルテスト記録、④ギャップとリスク一覧、⑤移行概算、⑥成約前条件、⑦Day1と100日計画、⑧専門家への確認事項、の八点を基本とします。進行全体はご相談から成約・引継ぎまでの流れも参考に、M&Aの他のDDとタイミングを合わせます。

9．データ移行とカットオーバーの設計

データ移行は「古いNASから新しいNASへコピーする作業」ではありません。制作を止めず、ファイルの完全性、権限、リンク、権利情報、検索性を保ち、問題時に戻せる状態で管理基盤を切り替えるプロジェクトです。成約日と同日に全データを一括移行する必要はありません。Day1に必要な運用と、長期アーカイブの移行を分けます。

移行の基本原則

1. 正本を宣言する：移行前に案件ごとの正本と複製を決め、コピー元を固定する。
2. 削除しながら移行しない：重複整理は別工程とし、まず完全に複製・検証する。
3. チェックサムで確認する：ファイル数と容量だけでなく、可能な範囲でハッシュ値を比較する。
4. 小さく試す：実案件のパイロット移行で、速度、権限、文字化け、リンク、クラウド制限を確認する。
5. 差分を管理する：初回コピー後に更新されたファイルを増分同期し、最終切替時の差を小さくする。
6. 戻り道を残す：旧環境を一定期間読み取り専用で保持し、ロールバック条件を決める。

ステップ1：プリフライト

コピー元と先の容量、ファイル数上限、禁止文字、パス長、権限モデル、タイムスタンプ、拡張属性、シンボリックリンク、クラウドプレースホルダーを確認します。macOSとWindows間、NASとクラウド間では、ファイル名の大文字小文字、不可視ファイル、濁点、特殊文字、リソースフォークなどが影響する場合があります。数百万ファイルのキャッシュや自動保存をそのままクラウドへ上げると、同期が長期化し課金が増えるため、業務上必要なものを分類します。

移行対象を「稼働中」「再編集頻度高」「長期アーカイブ」「法務・契約」「廃棄候補」「保留」に分けます。廃棄候補も、契約上の保存・返却、紛争対応、個人情報、発注者指示を確認するまでは消去しません。ファイルのマルウェアスキャンを行い、感染や不審な実行ファイルが見つかった場合は隔離手順に従います。

ステップ2：パイロット移行

典型案件、最大案件、古い案件、多言語案件、機密案件、外部共有が多い案件を選びます。コピー後、ファイル一覧、総容量、ハッシュ、アクセス権、サムネイル、字幕文字、編集PJ、MA、最終マスターを確認します。ユーザー受入テストでは、ディレクターが検索し、編集者が開き、営業が完成版を閲覧し、管理者が権限を変更する一連の流れを試します。

速度測定は理論値でなく実ファイル構成で行います。大きなカメラファイルと多数の小さなプロジェクトファイルでは速度が異なります。クラウドへのアップロードでは回線の上り帯域、API制限、再試行、夜間の自動バックアップとの競合を確認します。必要に応じて物理搬送サービスや段階的な同期を検討しますが、暗号化、輸送、受領確認、消去の責任分界を明確にします。

ステップ3：本番コピーと増分同期

案件群ごとにバッチを分け、開始・終了時刻、対象、担当者、ログ、エラー、再実行を記録します。編集作業中のプロジェクトは、コピー時にファイルが変化すると不整合が起きるため、案件責任者と停止時間を合意するか、アプリが推奨する方法でパッケージ化します。初回コピー後は旧環境の更新を監視し、最終カットオーバー前に差分同期します。

権限は、旧環境の設定を無条件に複製しません。過去に積み重なった例外や退職者権限まで引き継ぐ恐れがあるためです。新環境の役割を「営業閲覧」「制作編集」「機密案件限定」「権利・契約」「システム管理」などに再設計し、必要最小限で付与します。ただし、急な権限縮小で制作が止まらないよう、業務責任者の確認と一時申請手順を用意します。

ステップ4：カットオーバー

切替日時、凍結対象、旧パス、新パス、問い合わせ先、障害時の判断者を事前通知します。進行案件は、編集者が作業を保存し、差分同期完了を確認してから新環境で再開します。外部協力者には、新しい共有リンクと期限を発行し、旧リンクを失効させます。自動処理、バックアップ、監視、納品アップロード、校正サービス連携も忘れず切り替えます。

リンク切れ対策として、一定期間は旧共有名を読み取り専用で維持する方法がありますが、旧・新双方を編集可能にすると版が分岐します。「どちらが正本か」を画面上でも明示し、旧環境へ警告フォルダやアクセス制限を設定します。ロールバックは、重大なファイル欠落、制作不能、権限事故など具体的な発動条件と判断期限を決めます。

ステップ5：検収と旧環境の終了

検収では、件数、容量、ハッシュ一致率、エラー解消、代表案件の起動、権限、バックアップ、復元、監査ログ、ユーザー承認を確認します。不一致ファイルは、再コピー、意図した除外、アクセス不能、破損を区別します。検収報告書には、未解決項目と暫定運用も記載します。

旧環境の廃止は、検収直後ではなく、合意した並行期間と法務・業務確認の後に行います。機器を再利用・売却・廃棄する場合、データ消去方法、暗号化鍵破棄、証明書、リース返却条件を確認します。クラウド契約を解約する前に、請求書、監査ログ、ライセンス証明、サポート履歴など、後で必要になる記録を保全します。

10．アカウント・権限・認証情報の切替

映像会社の引継ぎで、データ以上に危険なのがアカウントの取りこぼしです。代表者個人のメールにドメイン更新通知が届く、元編集者の携帯電話で多要素認証する、YouTubeチャンネルが個人Googleアカウントに紐づく、NASの管理者が一名のみ、といった状態では、データがあっても運用を継続できません。アカウント台帳は、サービス名だけでなく所有と回復経路を記録します。

アカウント台帳の項目

• サービス名、用途、URL、契約プラン、契約番号、更新日、費用
• 契約法人・個人、請求先、支払方法、販売代理店、サポート窓口
• 主管理者、副管理者、一般ユーザー、外部ゲスト、サービスアカウント
• ログインIDの種類、会社ドメインか個人メールか、SSOの有無
• 多要素認証方式、回復メール・電話、バックアップコードの保管責任者
• 保持データ、連携アプリ、APIキー、Webhook、公開リンク、監査ログ
• 譲渡・管理者変更の手続、事前同意、解約時のデータ、確認日
• Day1に必要か、移行可能か、新規契約か、廃止予定か

認証情報そのものをDD資料へ書かない

台帳へパスワードや多要素認証の秘密鍵を平文で記載し、データルームへ置くことは避けます。DD段階ではアカウントの存在、所有、管理方法、移行可否を確認し、実際の認証情報は成約条件と権限に応じて、安全なパスワード管理基盤や正式な管理者追加機能で移します。共有パスワードが残るサービスでは、引継ぎ後に新しい長いパスワードへ変更し、不要セッション、アプリパスワード、APIトークンを失効させます。

多要素認証は解除して渡すのではなく、買い手側管理者を追加し、回復手段を会社管理に変更し、テストログイン後に旧管理者を外す順序が基本です。旧担当者を先に削除すると管理不能になるため、必ず二名以上の管理者と緊急回復手順を確認します。高権限アカウントの操作は、日時、実施者、承認者、変更内容を記録します。

ドメイン・メール・公開チャネル

ドメインレジストラ、DNS、SSL証明書、ウェブホスティング、WordPress、メール、問い合わせフォーム、迷惑メール対策、アクセス解析は相互依存します。DNSを一度に移すとウェブとメールが同時に止まる可能性があるため、ゾーン情報、TTL、送信ドメイン認証、フォーム送信先、バックアップを確認し、段階的に切り替えます。更新期限が近いドメインは、名義変更前に失効リスクを下げる措置を検討します。

YouTube、Vimeo、SNS、広告アカウントでは、チャンネル所有者、ブランドアカウント、管理者ロール、収益化、支払、著作権申し立て、限定公開動画、外部代理店を確認します。公開動画を新チャンネルへ再アップロードするとURL、再生数、埋込み、字幕、コメント、検索評価が変わるため、公式の所有・権限変更機能を優先します。発注者所有チャンネルを制作会社が代行管理している場合は、M&Aを理由に勝手に所有変更せず、発注者へ管理者体制を確認します。

編集・素材・フォント・配信サービス

Adobe、フォント、ストック、BGM、レビュー、データ送付、ライブ配信などは、ライセンス単位が「法人」「チーム」「ユーザー」「端末」「プロジェクト」「アセット」と異なります。契約主体が同じでも、ユーザー再割当や管理者変更が必要な場合があります。契約主体が変わる場合は、移管できるか、販売代理店の同意が必要か、新規契約とデータ移行になるかを確認します。公式ヘルプに手順がない場合は、サポートへ契約番号と想定スキームを示して問い合わせ、回答を保存します。

最小権限と職務分離

小規模会社では一人が営業、制作、ITを兼ねますが、少なくとも高権限操作の承認と記録は分けられます。日常編集者にNAS全体の削除権限を与えない、経理契約書を制作共有から分ける、管理者アカウントを日常利用しない、外部協力者のアクセスに期限を設ける、APIキーをプロジェクトへ直書きしない、といった基本を100日計画へ落とします。

権限変更は、譲渡企業を排除することのためではなく、顧客データと従業員を守り、誰が何をできるかを説明可能にするためです。代表者やキーパーソンが一定期間残る場合も、個人の善意に頼らず、会社管理アカウント、代理承認、緊急連絡、退任日の失効計画を明文化します。

11．成約後100日計画

成約後100日は、すべてを買い手標準へ統一する期間ではありません。顧客への納品を止めず、重大な権利・セキュリティ事故を防ぎ、属人知識を組織知へ変える期間です。速さを優先する対象と、現場検証を優先する対象を分けます。以下は一般的な枠組みであり、事業規模、取引スキーム、システム、契約条件に応じて調整します。

成約前〜Day1：止めないための最低条件

• 進行中案件、今後30日の納品、撮影、公開、請求、外注予定を一覧化する。
• 会社ドメイン、メール、NAS、クラウド、編集アプリ、主要公開チャネルの管理者を二名以上確保する。
• 重要ストレージのバックアップ状態を確認し、少なくとも契約・権利台帳と進行案件を別系統へ保全する。
• 譲渡企業・買い手の連絡網、障害時判断者、顧客説明の責任者を決める。
• Day1に変更する認証情報と、変更しないシステムを明確にする。
• アカウントや契約の事前同意・通知が必要なものを専門家と確認する。

Day1に全パスワードを無計画に変更すると、ライブ配信、アップロード、自動バックアップ、外部編集が止まります。一方、退任者だけが知る管理者認証を放置することもできません。高リスク・高重要度から順に、管理者追加、回復手段確認、テスト、旧権限失効の手順で切り替えます。変更一覧と戻し方を残します。

Day2〜10：可視化と封じ込め

最初の10日は、進行案件と重大リスクへ集中します。共有リンクの全停止のような乱暴な対応ではなく、公開範囲が不明、退職者が所有、高機密、期限なしのリンクを優先確認します。NAS容量、ディスク障害、バックアップ失敗、クラウド支払エラー、ドメイン更新期限を監視します。編集者ごとにローカル保管中の進行素材を申告し、会社管理領域へ同期します。

主要顧客ごとに、担当者、案件ルート、納品仕様、過去マスター、権利注意事項、次回予定を一枚へまとめます。買い手の営業がすぐ連絡できるだけでなく、譲渡企業側担当者が同席して「どこまで引き継がれたか」を説明できる状態を作ります。顧客への案内内容は、M&A契約、秘密保持、ブランド方針に合わせます。

Day11〜30：重要案件の復元と台帳完成

売上上位、再編集頻度上位、進行案件について、完成マスター、白完、編集PJ、権利証跡を確認します。少なくとも主要10〜20案件で復元テストを実施し、A〜Uの再現レベルを付けます。権利不明の素材は、削除ではなく隔離・要確認ラベルを付け、営業が新用途を即答しない運用にします。

同時に、アカウント台帳、ストレージ台帳、権利台帳、外注先台帳を完成させます。完璧な古い情報を待たず、重要度、証跡レベル、次回確認日を付けます。買い手標準の管理ツールへ移す場合も、譲渡企業の元台帳を読み取り専用で保管し、項目対応表を残します。

Day31〜60：パイロット移行と標準化

一つの顧客群または一年度を選び、買い手側ストレージへのパイロット移行を行います。命名規則、フォルダ、権限、バックアップ、検索、プロジェクトリンク、外部共有を検証します。旧会社の運用で優れている点を残し、買い手標準との違いを一覧化します。「買い手の規則に合わせる」こと自体を目的にせず、制作速度、事故防止、顧客説明、保守性で判断します。

新規案件には、納品時アーカイブチェックを導入します。契約・権利、撮影原本、編集PJ、白完、パラ、字幕、マスター、納品記録を揃え、案件責任者が完了を承認します。古い案件の整理だけでは、毎月新しい未整理案件が増えてしまうためです。フォントやストック素材は、会社契約の候補を絞り、ライセンス証跡を案件番号へ自動または半自動で紐付けます。

Day61〜100：本番移行・訓練・改善

パイロットの結果を反映して本番移行を進め、重要案件から検収します。旧環境は読み取り専用とし、一定期間後の廃止判断を行います。復元訓練では、NAS障害、クラウドアカウント停止、担当者不在、誤削除を想定し、権利台帳と編集PJを別環境へ戻します。訓練で見つかった連絡先、鍵、容量、手順の欠落を修正します。

100日目には、経営者へ、移行率、復元可能率、権利不明件数、個人所有アカウント数、期限なし外部共有数、バックアップ成功・復元テスト、主要顧客の引継ぎ状況を報告します。数字は会社間比較のためでなく、改善の基準点として使います。未解決事項には責任者、期限、予算、受注上の制限を付けます。

100日計画の役割分担

経営責任者は優先順位と予算、制作責任者は案件と品質、IT責任者は移行・権限・バックアップ、法務担当は契約・権利、営業責任者は顧客説明、人事は在籍・退職者対応を担います。小規模会社で兼務する場合も、役割として分けて記載します。外部ベンダーがデータコピーを行う場合、権利判断や正本決定まで委ねず、会社側の承認者を置きます。

12．案件類型別の引継ぎポイント

同じ「映像制作」でも、地域の顧客、媒体、契約、制作工程によってアーカイブの意味は変わります。ここでは代表的な案件類型ごとに、DDと引継ぎで見落としやすい点を整理します。

自治体・観光・地域プロモーション

自治体案件では、仕様書が納品物を詳細に定めることがあります。完成映像だけでなく、撮影オリジナル、編集プロジェクト、シナリオ、絵コンテ、音声、未使用素材等を求める公募例もあります。実際の義務は各案件の契約・仕様書によるため、過去案件を一括して同じ扱いにせず、納品リストと保存データを突合します。年度、事業名、担当課、財源、検査日、公開チャンネルを記録すると、次年度改訂の問い合わせへ対応しやすくなります。

観光映像は、四季、祭り、文化財、店舗、住民、ドローン、外国語ナレーションが重なります。祭りの開催形態や施設名称、交通情報は変わり得るため、素材の撮影年月を画面で確認できるようにします。店舗や出演者の許諾、ドローン関係の記録、多言語監修、BGM、公開地域、広告配信を確認します。地域事業者との関係は台帳だけで置き換えられないため、譲渡企業担当者による紹介と連絡経緯も引き継ぎます。

企業VP・採用・研修

企業映像では、退職社員、旧制服、廃止製品、工場設備、取引先ロゴ、未発表技術が含まれます。再編集依頼が多い一方、最新版の判断を誤ると古い情報を公開します。完成マスターへ「公開中」「公開終了」「改訂要」「機密」の状態を付け、発注者の公開URLと照合します。社員出演、協力会社、撮影施設の条件を確認し、採用サイトからSNS広告へ展開する場合は媒体差をチェックします。

研修映像は、社内限定を前提に第三者素材が使われている場合があります。買い手企業内で視聴することと、譲渡企業の顧客が社内配信することを混同しません。LMS、限定公開URL、視聴者アカウント、字幕、テスト問題、SCORM等の関連データも対象にし、機密性に応じて権限を制限します。

テレビ番組・CM・代理店案件

放送案件では、局・代理店・制作会社・出演者・技術会社・音楽等の契約関係、放送用納品仕様、素材返却、二次利用、アーカイブ、クレジットを確認します。完成版と白完、テロップ原稿、音声チャンネル、ラウドネス、CM尺、考査資料、放送日を関連付けます。局や代理店のシステム上でのみ交付された資料がある場合、保管可否を契約に従って確認します。

CMの素材を企業VPやSNSへ流用できるとは限りません。タレント、楽曲、ナレーター、ストック、媒体、期間、地域、競合、広告出稿の条件を案件単位で見ます。契約期間満了後に編集PJが残っていても、新規公開へ使えると判断しません。営業が過去CMを実績リールへ入れる場合も、別途実績公開の根拠を確認します。

イベント・ライブ配信

ライブ配信では、完成アーカイブのほか、各カメラISO、PGM、スライド、登壇者資料、コメント、チャット、字幕、配信キー、プラットフォーム録画が存在します。配信キーやAPIトークンは終了後に失効し、映像データと分離して管理します。登壇資料に個人情報や第三者画像が含まれる場合、オンデマンド公開の可否と期間を確認します。

地域イベントは多数の一般参加者が映ることがあります。撮影・配信の告知、会場掲示、個別同意、撮影除外エリア、子どもの映り込み、後日公開の範囲を確認します。未編集ISOは公開版より機密度が高いため、一般制作共有へ長期放置しません。発注者の保存方針に沿って保管・返却・削除を決めます。

学校・医療・福祉

児童生徒、患者、利用者を含む案件では、一般の企業映像以上に慎重な権限と再利用判断が必要です。顔を隠した完成版があっても、撮影オリジナルには識別情報が残ります。撮影目的、同意、保護者・本人への説明、発注者の指示、保存期間、外部委託先、クラウド保存先を確認します。M&AのDD担当者へも必要最小限の情報だけを開示します。

「地域密着だから皆知っている」という関係性は、許諾の代わりにはなりません。一方で、過去の事情を理解せず一律削除すれば、発注者が保存を求める記録を失う恐れがあります。判断を急がず、案件責任者、発注者、専門家と確認し、アクセス制限下で保全します。

不動産・建築・ドローン

建物や土地の映像では、竣工前後、入居者、施工情報、設計図、セキュリティ設備、ドローンの飛行記録などが含まれます。ロケ許可、施設管理者、飛行に関する申請・調整、公開可能範囲、物件販売終了後の利用を整理します。位置情報を含む撮影メタデータやフライトログは、目的と必要性を考えてアクセスを制限します。

完成マスターから位置情報が見えなくても、オリジナルやプロキシ、撮影表に残ることがあります。買い手が別顧客の営業素材へ転用することは避け、発注者との契約と個別許諾を確認します。空撮素材集として再販売していた場合は、その契約、被写体、提供先、期間、プラットフォーム条件も権利台帳へ入れます。

13．台帳テンプレートと実務チェックリスト

ここからは、譲渡企業が譲渡準備を始める際、買い手がDD質問票を作る際、PMI担当が100日計画を進める際に使える項目をまとめます。表計算でも案件管理システムでも構いません。重要なのは、案件IDを共通キーにし、原本へのリンク、確認日、確認者、証跡レベルを持たせることです。

案件マスター

• 案件ID、正式案件名、略称、顧客、代理店、担当部署、顧客担当者
• 営業、プロデューサー、ディレクター、撮影、編集、MA、外注先
• 受注日、撮影日、初稿日、校了日、納品日、検収日、公開日、公開終了日
• 制作種別、尺、言語、画角、納品媒体、公開媒体、広告利用
• 契約金額、再編集実績、次回更新見込、重要度、機密区分
• 案件ルートパス、正本ストレージ、バックアップ、LTO/HDD番号
• 権利台帳ID、アカウントID、編集環境票ID、顧客引継ぎ票ID

アセット台帳

• アセットID、案件ID、種別、論理名、原ファイル名、パス、容量
• 作成日、更新日、撮影日、撮影者、カメラ、コーデック、フレームレート
• 言語、画角、尺、版、承認状態、納品状態、公開状態
• 正本・作業・複製・バックアップ、チェックサム、検証日
• 機密区分、個人情報、権利制限、保存期限、削除予定、法的保全
• 関連プロジェクト、派生版、使用素材、代替可能性、復元レベル

権利台帳

• 権利ID、案件ID、対象アセットID、タイムコード、素材サムネイル
• 出演、ロケ、BGM、SE、写真、映像、フォント、テンプレート、その他
• 権利者・許諾者、契約当事者、取得担当、取得日、証跡レベル
• 目的、媒体、期間、地域、言語、改変、抜粋、翻訳、広告、再許諾
• クレジット、追加料金、報告、更新、終了時措置、実績公開
• 原本リンク、該当条項、要約、未確認事項、次回確認日、確認責任者

編集環境票

• アプリ名、版、OS、プロジェクト形式、起動確認日
• シーケンス、色空間、解像度、フレームレート、音声構成
• リンクルート、オフライン数、プロキシ、キャッシュ、外部連携
• フォント、LUT、プラグイン、コーデック、テンプレート、取得元
• 収集・アーカイブ手順、最終シーケンス、書き出しプリセット
• 検証レンダー、完成版との差異、再現レベル、既知の問題、担当者

アカウント台帳

• サービス、用途、契約名義、管理者、請求、更新、販売店
• ユーザー・端末・アセット等のライセンス単位、割当数、未使用数
• SSO、多要素認証、回復方法、監査ログ、データ保持、外部共有
• 移管・管理者変更の可否と手続、公式確認先、確認日、回答記録
• Day1対応、100日対応、廃止、新規契約、データ書出し、責任者

DDチェックリスト―譲渡企業

1. 主要顧客と再編集頻度の高い案件を選んだか。
2. 完成版、白完、撮影原本、編集PJ、字幕、パラ音声の所在を示せるか。
3. 「白完」の定義を案件ごとに説明できるか。
4. 契約書、仕様書、変更指示、納品記録が案件IDで繋がっているか。
5. 出演、ロケ、BGM、フォント、ストックの証跡があるか。
6. 実績公開と二次利用を区別しているか。
7. 個人名義のアプリ、クラウド、公開チャネルを特定したか。
8. 退職者や外注先にしかないデータを確認したか。
9. NAS、クラウド、HDD、LTOの正本・複製・バックアップを区別したか。
10. 重要データの復元テストを実施したか。
11. 不明事項を隠さず、重要度と対応案を付けたか。
12. DD資料に平文パスワードや不要な個人情報を含めていないか。

DDチェックリスト―買い手

1. 会社全体の容量だけでなく、事業継続に必要な案件を特定したか。
2. サンプル選定に古い案件、外注案件、異なるアプリを含めたか。
3. 台帳記載を原契約とサンプル突合したか。
4. データ保有と利用権限を混同していないか。
5. アカウント・契約が取引スキーム上どう扱われるか確認したか。
6. 編集PJを別環境で開き、検証レンダーを作ったか。
7. クラウド移行時間、転送料、ファイル数制限を見積もったか。
8. 旧環境の保守、LTOドライブ、暗号化鍵を評価したか。
9. 成約前、Day1、100日、長期改善に課題を分けたか。
10. 顧客への通知・同意、秘密保持、個人情報を専門家と確認したか。
11. 譲渡企業の優れた運用を残す余地を設けたか。
12. 移行費、再契約、ストレージ、専門家、教育の予算を計上したか。

納品時アーカイブチェックリスト

1. 承認済み完成マスターとファイル仕様を記録する。
2. 白完の有無と除去・残置要素を記録する。
3. 音声ステム、字幕、翻訳原稿、縦型・短尺版を整理する。
4. 編集PJを収集し、リンク切れと依存物を確認する。
5. 撮影オリジナルと発注者支給素材を区別する。
6. 出演、ロケ、BGM、フォント、ストック証跡を台帳へ登録する。
7. 納品書、送付記録、検収、公開URLを保存する。
8. 実績公開の可否と承認経路を登録する。
9. 正本を指定ストレージへ移し、バックアップを確認する。
10. 外部共有を整理し、不要リンクと一時データを規程に従って処理する。
11. 案件責任者以外が検索・復元できるか確認する。
12. 次回改訂時の注意事項を100〜300字で残す。

移行当日チェックリスト

1. 責任者、承認者、作業者、問い合わせ先が揃っている。
2. コピー元のバックアップとスナップショットを確認した。
3. 進行案件の編集停止・保存を確認した。
4. 最終差分の範囲と完了時刻を記録した。
5. ファイル数、容量、ハッシュ、エラーログを取得した。
6. 新環境の権限をテストユーザーで確認した。
7. 代表案件の編集PJ、字幕、マスターを開いた。
8. バックアップ、監視、通知、ログを有効化した。
9. 外部協力者へ新リンクを発行し、旧リンクを計画どおり失効した。
10. 旧環境を読み取り専用にし、正本表示を行った。
11. ロールバック条件に該当しないことを承認者が確認した。
12. 未解決事項と翌営業日の確認予定を全員へ共有した。

権利判断を依頼するときの質問票

専門家や契約相手へ「この素材は使えますか」とだけ聞くと、前提不足で答えにくくなります。対象ファイル、元案件、契約当事者、取得経緯、証跡、現在の利用、予定する新用途、媒体、期間、地域、編集内容、公開主体、広告か否か、M&Aの取引スキームを整理して質問します。回答日と前提を台帳へ保存し、別用途へ無条件に横展開しません。

14．よくある質問