コスモネス・ソルジャー　Google Flowワークフロー詳細

を、より具体的に記載したワークフローです。

第1章：プリプロからルックデヴの核心 — PBRマップの分解とACES 2.0カラーサイエンス

1-1. Google Flow（Gemini Omni）による2D美術からのOpenUSD書き出しとデータ構造

　映像制作の初期段階（プリプロダクション）において、Google Flowにアップロードされた2Dのコンセプトアートや美術設定画像は、単に「見た目の立体化」が行われるだけではない。その中核にあるマルチモーダルモデル「Gemini Omni」は、描かれたオブジェクトの物理的な材質（木、金属、布、ガラスなど）や、3次元空間における奥行き、カメラのパースペクティブを物理シミュレーションベースで逆算・推論する。

　Google Flowのチャットインターフェース「Flow Agent」を介し、以下のような具体的なカメラマン・モデラー的プロンプトを投入することで、3Dアセット生成プロセスが起動する。

　このプロセスを経て出力されるOpenUSDファイルは、単一の静的な3Dモデルではない。形状情報を含む「ジオメトリ・レイヤー」、質感を定義する「マテリアル・レイヤー」、そして後述する「テクスチャ・メタデータ・レイヤー」が非破壊に積層された、ピキサー規格準拠の堅牢なシーングラフ構造（UsdStage）を保持した状態で書き出される。

1-2. テクスチャにおける「光と影」の衝突：AIデライティング（Delighting）の物理

　従来の画像生成AIアセットを3D空間に持ち込む際、最大の問題点となるのが「ベイクド・ライト（画像内にあらかじめ描き込まれてしまった光と影）」である。AIは2Dとしての見栄えを最優先するため、テクスチャ画像そのものに「太陽光のハイライト」や「建造物の陰影」を固定ピクセルとして焼き付けてしまう傾向がある。

　「汚れた」テクスチャを3D空間へ配置すると、既存の照明と混ざり合い、二重の影（Double Shadowing）や、ACES 2.0環境での不自然な白飛び・階調の濁りが発生する。Google Flowの「AIデライティング」機能は、光源を逆算し、影やハイライトを100%サスペンド（引き算）することで、純粋な物質固有の「デライテッド・アルベド」を抽出する。

1-3. 物理ベース（PBR）マップへの完全分離と各要素の役割

　AIは1枚の2D美術から、最高4K/8K解像度、16bit/32bit浮動小数点のOpenEXR形式で、以下のPBRマップを自動生成する。

マップ名フォーマットチャンネル物理的な役割・挙動アルベド　OpenEXRRGB光と影を除去した純粋な固有色。反射率（Reflectance）を定義。ラフネスOpenEXRGスケール(R)表面の粗さ（マイクロファセット）。
　光のボケ具合を制御。メタリックOpenEXRGスケール(G)金属（1）か非金属（0）かを示す導体・誘電体定義。ノーマルOpenEXRRGB(Tangent)法線ベクトルによる凹凸情報。立体感をレンダリングで再現。

1-4. ACES 2.0カラーマネジメントへの自動一括マッピングとOCIO設定の鉄則

　劇場・配信映画標準の「ACES 2.0 (ACEScg)」ワークフローでは、リニア環境で光を計算する必要がある。Google FlowはOpenColorIO（OCIO）を活用し、エクスポート時に適切な色空間変換を自動適用する。

⚠️ 現場のOCIOカラーアサイン・マトリクス（絶対厳守のルール）

1. アルベドマップ：役割「Color」としてACES 2.0 Input Transform (sRGB - Texture)を適用し、ガンマ(2.2)を解除。照明計算と整合させる。

2. ラフネス/メタリック/ノーマルマップ：役割「Non-Color (Raw)」を適用し、カラー変換を通さない。数値として読み込ませ、レンダリング破綻を防ぐ。

　このOCIO設定（UsdUVTexture）はOpenUSDファイルに非破壊で書き込まれ、次章で扱うNuke等のポスト処理パイプラインへ直接渡される。

第2章：理想と現実 — DaVinci Resolve（Fusion）一本化ワークフローにおける4つの技術的限界と罠

2-1. DaVinci Resolveにおける最新USDモジュール（uノード群）の概要

　近年のアップデート（DaVinci Resolve 18.5〜19以降）において、Blackmagic Designは「Fusionページ」内部におけるOpenUSD（Universal Scene Description）のネイティブサポートを劇的に強化した。従来のFBXやOBJを読み込む旧来の3Dノード（Merge 3D や Cook-Torrance 等）とは完全に分離された、頭文字に「u」を冠する「uノード（USD専用ノード）群」が実装されている。

　Google Flow（Gemini Omni）からエクスポートされたバイナリ形式のOpenUSD（.usdc）またはアスキー形式のOpenUSD（.usd / .usda）をFusionページに展開する場合、主に以下のノードパイプラインが構築される。

• uLoader（USDローダー）: USDファイルを直接タイムラインへ読み込む起点ノード。内部にPixarのHydraレンダリングアーキテクチャを内蔵しており、Google Flow側で書き込まれたPBRマップのメタデータ（シェーディングスキーマ）を自動で読み込み、手動接続なしで質感を100%再現する。

• uTransform（USDトランスフォーム）: 3D空間内におけるオブジェクトのトランスレーション（位置）、ローテーション（回転）、スケール（縮尺）を非破壊に制御するノード。

• uMerge（USDマージ）: 複数の uLoader から読み込んだ形状レイヤーや、ライトレイヤーを1つの3Dステージへと統合するノード。

• uRender（USDレンダラー）: 統合された3D空間（USD Stage）を2Dのピクセルデータへラスタライズ（映像化）し、後続の「カラーページ」へ送出するための終端ノード。内部レンダラーとしてPixar標準の「Storm」または「Hydra互換デリゲート」を選択可能。

　このuノード群の登場により、DCC（Digital Content Creation）ツールを往復することなく、編集タイムライン上で直接AI生成3D背景をハンドリングできる「一気通貫の理想的ワークフロー」が理論上は完成した。しかし、これを映画製作、とりわけバーチャルスタジオ（ICVFX）を用いた商業プロダクションの現場へ実戦投入した場合、回避不可能な4つの深刻な技術的罠（ボトルネック）が牙をむく。

2-2. 罠1：Fusionの「USDマテリアル」とUE5（Substrate）間の物理シェーダー互換性エラー

　第1の罠は、DaVinci ResolveのFusionページが解釈するUSDマテリアル規格と、スタジオのLEDウォールを駆動するUnreal Engine 5（UE5）の最新マテリアルシステム（Substrateなど）との間で発生する「シェーディング・スキーマの不一致」である。

　Google Flowから出力され、Fusionの uLoader で展開されるマテリアルは、USDの標準規格である UsdPreviewSurface に準拠している。しかし、Fusionページ内部でディテールを追い込むためにマテリアルを調整したり、Fusion独自のテクスチャノード（uMaterialX など）を噛ませてルックを変更した場合、そのデータ構造はDaVinci独自のカスタムUSDスキーマへとラップされてしまう。

　これを .usd ファイルとして再エクスポートし、UE5の「USD Stage」へインポートすると、UE5側のマテリアル翻訳エンジン（UsdMaterialConverter）がFusion固有のノード情報を正しく解釈できず、以下のエラーが頻発する。

• テクスチャの完全な喪失（デフォルトのグレーマテリアルへの強制置換）

• 鏡面反射（Specular/Roughness）の極端なエラーによる白飛び、または光を一切反射しない「漆黒化（黒潰れ）」

• 法線（Normal）のR/Gチャンネル（反転問題）の誤認識による、立体感の凹凸の逆転現象

　結果として、「Fusionの画面で見えているルック」を、スタジオのLEDを鳴らすUE5側で再現することが物理的に不可能となる。

2-3. 罠2：カラープロセスの不整合 — 「カラーページ」の色調整が3Dデータ（USD）に直接反映されない構造的欠陥

　DaVinci Resolveを運用する上で、プロの技術者が最も深く嵌まるのが「カラーページ」と「3Dデータ空間（USD）」の構造的遮断という罠である。

　DaVinci最大の強みは「カラーページ」による世界最高峰のACES 2.0カラーグレーディング機能である。当然、アーティストはFusionページで読み込んだGoogle Flowの3D背景に対して、カラーページでシネマチックな色補正（Look Dev）を施そうとする。しかし、DaVinciの内部パイプラインにおいて、カラーページへ流れてくるデータは、すでに uRender ノードによって「2Dのピクセル（映像ストリーム）」へと平坦化（ラスタライズ）された後のデータである。

　したがって、カラーページでいくら高度な色調整、カラーマッチング、肌色の保護（セマンティックマスク）を行ったとしても、その色情報は3Dアセットそのもののテクスチャ（Albedoなど）を書き換えているわけではない。
　この状態から、撮影スタジオに持ち込むために「3DのUSDファイル」としてタイムラインからエクスポートしようとすると、書き出されるのはカラーページの処理が適用される前の、「Fusionページ（uLoader）に読み込んだ時点の、元の冷たいAIアセットの色」に戻ってしまう。

　これを回避するためには、カラーページで調整した色味を一度「2DのOpenEXRテクスチャシーケンス」としてバラバラにレンダリング（ベイク）し、手動でUSDファイルへテクスチャを1枚ずつ再アサイン（上書き接続）するという、非破壊ワークフローの利点を完全に破壊する、膨大な手作業と二度手間が発生することになる。

2-4. 罠3：高精細アセット処理時におけるグラフィックメモリ（VRAM）の枯渇とクラッシュ（TDRエラー）

　Google Flow（Gemini Omni）が生成するOpenUSDアセットは、地形の微細な割れ目や建造物のディテールにいたるまで、人間のモデラーでは不可能な超高密度なポリゴン（数百万〜数千万ポリゴン）と、高解像度（4K〜8K）のマルチチャンネルOpenEXRテクスチャを内包している。

　DaVinci Resolveは、本質的に「ビデオ（動画ピクセルデータ）のタイムライン処理」に最適化されたソフトウェアアーキテクチャを有している。
　Maya、Houdini、Blenderのような「3Dの頂点データやトポロジーを効率的にメモリへ配置・サスペンドする」ための3D専門の動的メモリマネジメント機構（スパース・テクスチャ・マッピングや、ジオメトリのカリング処理など）が背景で十分に機能していない。

　そのため、巨大なGoogle FlowのUSDステージをFusionの uLoader に常駐させたまま、エディットページやカラーページへ頻繁に行き来（ページ切り替え）を行うと、以下の現象が発生する。

1. システム全体のメインメモリ（RAM）およびグラフィックボードのビデオメモリ（VRAM）が瞬時に飽和。

2. Windows環境においては「TDR（Timeout Detection and Recovery）」、Mac環境においては「GPU Driver Crash」が誘発。

3. 何の前触れもなくDaVinci Resolveが強制終了（クラッシュ）し、保存前のシーンデータや、カラーページのノードツリーが消失する。

　商業映画のタイトな制作スケジュールにおいて、この「いつ落ちるか分からないVRAMの不安定さ」は、パイプラインの運用において最大のリスクとなる。

2-5. 罠4：インカメラVFX（ICVFX）に必要なカメラ・トラッキングメタデータの同期精度の低さ

　バーチャルスタジオにおける撮影（インカメラVFX）の絶対条件は、「実写のシネマカメラの物理的な動き（位置：XYZ、回転：HPR、焦点距離、レンズの歪み）」と、「リアルタイムエンジン（UE5）内の仮想カメラの動き」が、1フレームの遅延もなく100%完全同期していることである。少しでもパースや位置がズレれば、LED背景が実写の役者に対して滑る（スライド現象）が発生し、SFXとしての魔法が解けてしまう。

　撮影現場にデータを持ち込む前段階（プレ・コンポジット期）において、DaVinci Resolve（Fusion）のカメラトラッカー（CameraTracker）を用いて実写プレートからカメラの動きを解析し、それをUSDのカメラオブジェクトとして埋め込んでUE5へ渡そうとする際、同期精度の問題が浮き彫りになる。

　FusionのカメラトラッキングアルゴリズムおよびUSDエクスポート機能は、シネマカメラ特有の複雑なメタデータ（例：ARRIのLDSやREDのRMDに含まれる、レンズの焦点距離のミリ単位の動的変化、および非線形なレンズの歪み特性）を、USD標準のカメラプロパティへ正確にコンバート・焼き付け（Bake）する精度がNukeなどのハイエンドVFXソフトに比べて著しく低い。
　エクスポートされたUSDカメラをUE5のnDisplay（LED駆動システム）へ読み込ませた際、ワールド座標系の原点（ゼロポイント）のスケール感や、カメラの画角（FOV）の計算に微小な「丸め誤差」が生じ、現場でのキャリブレーション時に数センチ〜数十センチの壊滅的な位置ズレを引き起こす原因となる。

第3章：現実的なプロの最適解 — なぜ今、パイプラインの核に「Nuke」を据えるべきなのか？

3-1. ハリウッド標準の「USD/Hydraパイプライン」におけるNukeのアーキテクチャ的優位性

　商業映画やハイエンドなVFXプロダクションの現場において、Google Flow（Gemini Omni）が生成する巨大なOpenUSD（Universal Scene Description）アセットをハンドリングする際、パイプラインの核（ハブ）としてFoundry社のNuke（特にNukeX / Nuke Studio）を据えることは、もはや業界の共通認識となっている。

　第2章で解説したDaVinci Resolve（Fusion）一本化によるVRAMの枯渇やマテリアル崩れといった技術的限界に対し、Nukeはアーキテクチャの根本から異なるアプローチをとっている。近年のNuke（Nuke 14〜15以降）では、従来の3Dシステム（Scene や MergeGeo などの旧来のジオメトリ処理）とは別に、ピクサーが開発した最新のUSDネイティブな3Dアーキテクチャが内蔵されている。

　NukeのUSDシステムは、ビューアおよびレンダリングのバックエンドにピクサー標準のHydra（ハイドラ）エンジンをネイティブ採用している。数百万〜数千万ポリゴンにおよぶGoogle Flowの構造化されたUSDステージを読み込んだ際、Nukeは「シーングラフ構造」をそのまま保持しつつ、グラフィックボードのVRAMに対して「スパース（仮想化）読み込み」や、カメラの視界外にあるオブジェクトを計算から除外する「オクルージョン・カリング」を動的に実行する。

　これにより、DaVinci Resolveではシステムクラッシュ（TDRエラー）を引き起こしていた高精細なAI美術アセットであっても、Nuke環境下であればバックグラウンドでのメモリ消費を最小限に抑え、軽快かつ極めて安定した状態でハンドリングすることが可能となる。

3-2. 3D空間でのルックベイク：カラープロセスの破綻を克服するNukeのノード設計

　DaVinci Resolveにおける最大の罠であった「カラーページの色補正が3Dデータ（USD）に反映されない」という問題を、Nukeはその強力な3Dコンポジット機能によって完全にクリアする。

　Nuke内では、3D空間上のUSDアセットの表面テクスチャに対して直接カラーマネジメント（ACEScg）を適用し、それを再度アセットのUV座標に沿って焼き付ける（ベイクする）ワークフローが確立されている。具体的なノードパイプラインは以下のように構築される。

1. UsdIn（または ReadUSD）ノード: Google Flowから書き出された、マテリアルスキーマを含む .usd / .usdc ファイルを読み込む。

2. UsdMaterial および UsdPreviewSurface ノード: 読み込んだアセットのジオメトリとマテリアルを分離・再定義する。ここで、前述のカラーサイエンス（Albedoは ACEScg、Normal/Roughness/Metallicは Raw）を厳格にアサインする。

3. Bake3D（または ScanlineRender のUVモード）ノード: これがNuke運用の最大の核心である。3D空間に配置したAIアセットのテクスチャに対し、Nukeの強力なカラーノード（Grade、ColorCorrect、OCIOColorSpace など）を噛ませてルック（Color Grading）を追い込んだ後、Bake3D ノードを通過させることで、「ルック確定済みの、環境光やトーンが完全に調整されたOpenEXRテクスチャシーケンス」として、オブジェクトのUVに沿って直接レンダリング（ベイク）する。

4. UsdOut（または WriteUSD）ノード: ベイクされた新しいOpenEXRテクスチャを自動的に内包・参照させた状態の、クリーンかつ100%ルックが固定された新しい .usd ファイルとして最終エクスポートする。

　このフローを経ることで、Unreal Engine 5（UE5）へインポートした際にも「マテリアルが外れる」「色が元に戻って白飛びする」といった不整合を100%回避し、Nukeの画面で見ている映画品質のルックをそのまま撮影スタジオのLEDウォールへ持ち込むことができる。

3-3. PythonスクリプトによるPBRマップ自動アサインマトリクスの構築

　Google Flowから書き出されるアセットは、大量のPBRテクスチャマップ（Albedo, Roughness, Metallic, Normal）を内包している。これらを手動で1枚ずつ読み込み、カラー/Rawスペースを切り替えてノードを接続する作業は、ヒューマンエラー（設定ミスによるレンダリング破綻）の温床となる。

　Nukeでは、Python API（nuke モジュール）を活用することで、Google Flowのアセット構造を自動解析し、適切なカラースペースを設定してUSDノードへ一瞬で直結する自動化マトリクス（自動化スクリプト）を組むことができる。

🛠 現場で実用されるPython自動アサインスクリプトの構造例：

python

import os
import nuke

def import_google_flow_pbr(asset_dir):
    """
    Google Flowから出力されたPBRテクスチャ群を自動判別し、
    ACEScg/Rawの正しいカラースペースを設定してNukeのUSDノードへ接続する。
    """
    # ターゲットとなるPBRマップの定義
    pbr_files = os.listdir(asset_dir)
    
    # マテリアルノードの作成
    usd_material = nuke.createNode("UsdPreviewSurface")
    usd_material.setName("GoogleFlow_PBR_Material")

    for file_name in pbr_files:
        file_path = os.path.join(asset_dir, file_name).replace("\\", "/")
        
        # Readノードの作成
        read_node = nuke.createNode("Read")
        read_node["file"].setValue(file_path)
        
        # ファイル名から役割を自動判別し、厳格にカラースペースを設定
        if "albedo" in file_name.lower() or "basecolor" in file_name.lower():
            # 色情報にはACEScgを設定
            read_node["colorspace"].setValue("ACES - ACEScg")
            # UsdPreviewSurfaceのdiffuseColor入力に接続
            usd_material.setInput(0, read_node) 
            
        elif "roughness" in file_name.lower():
            # 数値データはRaw（変換なし）
            read_node["colorspace"].setValue("Utility - Raw")
            usd_material.setInput(1, read_node)
            
        elif "metallic" in file_name.lower():
            read_node["colorspace"].setValue("Utility - Raw")
            usd_material.setInput(2, read_node)
            
        elif "normal" in file_name.lower():
            read_node["colorspace"].setValue("Utility - Raw")
            # NormalMap処理用のノードを挟んでから接続
            usd_material.setInput(3, read_node)

    print("Google Flow PBRパイプラインの自動構築が完了しました。")

　このスクリプトをNukeのシステムに組み込んでおくことで、アーティストはアセットのパスを指定するだけで、一切のカラーエラーを起こすことなく、一瞬でハイエンドなUSDマテリアル環境を構築できる。

3-4. NukeからUnreal Engine 5（nDisplay）への寸分狂わないAxis（空間軸）変換とカメラ同期技術

　バーチャルスタジオ（ICVFX）における実写とCGの完全同期において、Nukeのカメラ解析力とエクスポート精度は決定的な役割を果たす。

　Nukeの CameraTracker ノードは、実写の撮影プレート（RAW/Log素材）から特徴点を極めて高精度に検出し、実シネマカメラのレンズの歪み（動的変化）、画角（FOV）、センサーサイズ（Aperture）をピクセル単位で正確に割り出す。しかし、ここで最大の問題となるのが、NukeとUnreal Engine 5における「空間軸（ワールド座標系）の根本的な不一致」である。

• Nukeの空間軸: 右手系・Yアップ（Xが横、Yが上、Zが奥行き）

• Unreal Engine 5の空間軸: 左手系・Zアップ（Xが前、Yが横、Zが上）

　この違いを考慮せずにカメラデータをUSDで出力すると、UE5にインポートした際に仮想カメラが90度横転するか、上下が反転し、位置座標のスケール感（メートルとセンチメートルの違いなど）も壊滅的に狂ってしまう。

　NukeからUE5へ正確にカメラデータを引き継ぐため、現場の技術者は UsdOut（または WriteUSD）ノードにおいて以下の設定を網羅・厳守する。

1. Axis / Transform 変換の固定: Cameraノードの直下に TransformGeo または Axis ノードを挟み、スケール値を一律で「100倍（Nukeの1ユニット＝1mから、UE5の1ユニット＝1cmへの変換）」に設定する。

2. UsdOut のインポート互換設定: UsdOut ノードのプロパティウィンドウにある空間トランスフォーム設定において、「Up Axis: Z-Up」 および 「Handedness: Left-Handed (Unreal compatible)」 のチェックボックスを有効化する。これにより、Nukeはエクスポートの瞬間に、内部のマトリクス計算を自動でUE5の左手系・Zアップ空間へとリアルタイム変換してUSDカメラストリームへ焼き付ける。

3. nDisplayへの正確な紐付け:
   UE5側でこの .usd カメラを読み込むと、Nukeで解析された位置・回転・レンズデータ（Focal Length）がキーフレームアニメーションとして完璧に再現される。これをスタジオのLED駆動システムである「nDisplay Config アクター」の View Point（視点コンポーネント） に直結（バインド）することで、実写スタジオのトラッキングセンサー（Mo-SysやOptiTrackなど）から送られてくるライブ座標と、Nukeから引き継いだベースのカメラ位置・パースペクティブが1ミクロンも狂うことなく、完全にマトリクス同期を果たす。

第4章：プロダクションの核心 — バーチャルスタジオにおける「TTL（カメラ越し）補正」の詳細

4-1. Through-The-Lens（TTL）における色彩不一致の物理的・光学的要因

　バーチャルスタジオ（インカメラVFX：ICVFX）における最大の技術的障壁は、人間の目で見たときのスタジオのトーンと、シネマカメラのレンズおよびセンサーを通過した画面（Through-The-Lens：TTL）におけるトーンの「光学的な不一致（色彩の濁り）」である。

　LEDウォールに投影されたGoogle Flowの3D背景（OpenUSDアセット）が、人間の肉眼でどれほど手前の実物セットや役者と馴染んでいるように見えても、実写カメラのモニター（TTL画面）で確認すると「背景の緑が異常に浮き上がる」「役者の肌色がくすむ」「ハイライトが不自然に青みがかる」といった現象が100%の確率で発生する。

　この現象が起きる根本的な原因は、カメラの受光特性とLEDの発光スペクトルの乖離にある。

• シネマカメラのセンサー（例：ARRI ALEV 4センサー等）: 太陽光や白熱灯などの「連続スペクトル（すべての波長が均等に含まれる自然光）」を基準にカラーサイエンス（LogC4等）が設計されている。

• スタジオのLEDパネル（例：ROE Visual Black Pearl等）: 赤（R）・緑（G）・青（B）の3つの急峻な「輝線スペクトル（特定の波長だけが突出した人工光）」の混色によって白色を擬似的に表現している。

　この結果、カメラのCMOSセンサーのRGBカラーフィルター（バイエル配列）がLEDの固有の波長を過剰に拾う、あるいは特定の波長を落としてしまうため、物理計算上は正しい「ACEScg」の3D空間であっても、カメラを通過した瞬間に色度が歪んでしまう。この色彩の濁りを、撮影現場の限られた時間の中でリアルタイムに打ち消し、手前の被写体と奥のCGを完璧に融合させる処理こそがTTL補正（カメラ越しカラーキャリブレーション）である。

4-2. NukeとFlow Agent（Gemini Omni）を連動させたリアルタイムTTLキャリブレーション手順

　現場の進行を止めないため、最新のパイプラインでは手作業のカラーマッチングを排除し、「Nuke ➔ Google Flow（Flow Agent） ➔ Unreal Engine 5（nDisplay）」を完全に自動連携させたリアルタイム・キャリブレーション・システムを構築する。具体的な実務ステップは以下の通りである。

① スタジオにおける基準サンプルの撮影（キャプチャ）

1. スタジオのLEDウォールに、Google FlowおよびNukeで構築・ルックベイクを完了したOpenUSD背景ステージを全面投影する。

2. 実写のシネマカメラ（例：ARRI ALEXA 35、カラープロファイル：LogC4）の正面（被写体となる役者のポジション）に、物理的なマクベスチャート（X-Rite ColorChecker Videoなど）を配置する。

3. 同時に、LEDウォール側のCG空間内（カメラの画角内）にも、全く同じカラーチップの数値データを持つ「デジタル・カラーチャート（CG）」を同一サイズで並べて表示させる。

4. この状態で、実カメラから1カットのテストRAWスナップ（またはLogC4ビデオストリーム）を撮影し、キャリブレーション環境へと転送する。

② Flow AgentおよびNukeによるセンサー特性の逆算と3D LUT生成

1. 撮影されたLogC4の1フレームを、スタジオ内のローカル・パイプラインサーバーへ取り込み、Nukeのキャリブレーション・スクリプト（OCIO統合環境）へ読み込ませると同時に、AIエージェントである「Flow Agent」へストリーム接続する。

2. Flow Agent（Gemini Omni）は、あらかじめインプットされたシネマカメラの正確なプロファイル（「ARRI ALEXA 35 / LogC4 / ARRI Wide Gamut 4」）を基準として、実写画像内の「物理チャート」のRGB数値と「デジタルチャート（LED投影）」のRGB数値をピクセル単位で比較解析する。

3. システムは、「実カメラのセンサー（ALEV 4）を通過した最終結果において、デジタルチャートの色度が、物理チャートの色度（ACES 2.0が定義する正しいリニア数値）と100%完全に一致するための、LED発光制御の逆算マトリクス（補正値）」をミリ秒単位で計算する。

4. Nukeは、この補正値をシネマ業界標準の高精度な立方体カラーグリッドデータである「3D LUT（.cube形式、33x33x33または65x65x65）」、またはOCIOのカラー・トランスフォーム・ファイル（.ocio）として自動的にエクスポートする。

③ Unreal Engine 5（nDisplay）へのリアルタイム・フィードバック

1. Nuke/Flow Agentによって自動生成された補正3D LUT（またはOCIOファイル）は、ネットワーク（10GbE以上の高速LAN）を経由し、LEDウォールをリアルタイム駆動しているUnreal Engine 5のマスターPC（nDisplayクラスターノード）へ即座に送信・上書きロードされる。

2. UE5内の「nDisplay Config アクター」のプロパティにある OpenColorIO (OCIO) Configuration ウィンドウを開き、インナー・フラスタム（カメラが現在向いている撮影領域）の出力カラーシェーダーに対して、この生成されたTTL補正プロファイルを割り当てる。

3. これにより、LEDパネルから光が射出される「直前（描画の最終ステップ）」において、3D背景の色味がカメラセンサーの受光の癖を完全に打ち消す（相殺する）形へとリアルタイムに変形・補正（キャリブレーション）される。

　この一連の自動ループにより、カメラマンや監督が覗き込む「TTLモニター（ACES 2.0 / Rec.709表示）」上では、手前の役者と奥のAI生成背景が、色の分離や浮き上がりを一切起こすことなく、完全に1つの映画空間として「馴染んだ」状態での本番撮影（ロール）が可能となる。手作業で行えば数時間を要していたこのカラーマッチングは、Flow Agentの物理解析力によってわずか数十秒〜数分で完了する。

4-3. 撮影後のポストプロダクションを考慮したカラーデータの保全とNukeへの引き継ぎ

　TTL補正は「撮影現場での一発馴染ませ」に絶大な威力を発揮するが、これはあくまでLEDウォール側を一時的に「狂わせる」ことでカメラのセンサーに適合させる処理である。そのため、撮影された映像データを最終的なポストプロダクション（仕上げVFX・コンポジット）工程へ戻す際には、データの解釈を誤ると重大なカラー破綻を招く。現場の技術責任者（デジタル・イメージング・テクニシャン：DIT）およびVFXスーパーバイザーは、以下の鉄則を厳守しなければならない。

• カメラ収録データのRAW/Log維持:
  LED背景にどれほど強力なTTL補正（色味の変更）をかけたとしても、シネマカメラ側の収録設定（例：LogC4やREDCode RAWなど）を変更したり、カメラ内部に補正LUTを焼き付けて（Bakeして）記録してはならない。カメラは常にセンサーが捉えたピュアなRAWデータ（ダイナミックレンジ17ストップ等の情報量を維持した状態）のままカードへ記録する。

• nDisplayのTTL-LUTをNukeへ「逆アサイン」する仕組み:
  撮影現場で使用された「nDisplay用のTTL補正3D LUT」は、カットごとのメタデータ（タイムコード、レンズの焦点距離など）と完全に紐付けられた状態で、アセット管理サーバーへ保存される。
  撮影が終了し、最終的なポストプロ（Nukeでの追加VFX合成やマットペインティング、DaVinci Resolveでの最終シネマチックカラーグレーディング）のフェーズに入った際、VFXアーティストはNuke内で実写プレート（RAWからACEScgへ変換されたクリップ）の後段に OCIOFileTransform（または Vectorfield）ノード を配置し、現場でLEDに適用したあの「TTL補正LUT」を読み込ませる。

　これにより、Nukeのコンポジット画面上において、「撮影現場で監督とカメラマンがLEDの光線と役者の肌を見て納得した、あの完璧なACES 2.0のルック」がデジタル上で100%の精度で完全再現される。
この状態をベースラインとすることで、AIが識別したセマンティック領域分離（肌色の隔離保護）の恩恵を最大限に受けながら、背景の微調整や追加の3Dフォグ（霧）の合成といった、高度なフィニッシング作業を「1ルックも色を狂わせることなく」安全に進行させることが可能となる。

第5章：ポスプロの自動化と一括編集 — 文脈理解と役者の肌色（スキンフリック）保護技術

5-1. 「Flow Agent」による編集タイムラインの文脈理解と自然言語一括グレーディングの自動化

　バーチャルスタジオ（ICVFX）でのインカメラVFX撮影が完了した後、すべての実写収録素材（実写プレート）およびUE5から出力されたメタデータストリームは、最終工程であるポストプロダクションへと集約される。

　この仕上げフェーズにおいて、Google Flowのバックエンドに控える「Gemini Omni」は、その最大の特徴である超長文文脈ウィンドウ（Long Context Window）をフルに駆動させる。従来のカラーグレーディングやVFX処理では、カット（クリップ）ごとに手作業でカラーマッチングを行い、タイムラインの並び順に応じて手動でルックをコピー＆ペーストしていく必要があったが、本ワークフローではAIエージェント「Flow Agent」への自然言語（プロンプト）による指示で、タイムライン全体の「文脈」を解釈した一括処理が実行される。

　Nukeのタイムラインエディタ（Nuke Studio）またはDaVinci Resolveの編集タイムラインと連携したFlow Agentに対し、アーティストは以下のような「ストーリーの文脈（コンテクスト）」を含んだ抽象的かつ映画演出的なプロンプトを入力する。

　このプロンプトを受けたFlow Agentは、映像を単なるピクセルの連続ではなく、役者の表情、シーンの緊迫度、時間軸の遷移といった「物語の文脈」として完全に物理・心理理解する。

　AIは、各カットに配置されたNukeの OCIOColorSpace または Grade ノードに対して、ACEScg空間におけるカラーマトリクス（オフセット、パワー、スロープの数値）を自動計算し、タイムライン全体へ一瞬でルックのベース（ファーストパス）を適用する。これにより、従来であればシニアカラーリストが数日間かけて行っていた「ルックの方向性決め」の作業が、わずか数分へと短縮される。

5-2. AI一括処理の罠：グローバル・フィルタリングによる肌色（スキントーン）の破壊現象

　AIによる全自動カラーグレーディングには致命的な技術的課題が存在する。背景色をシネマティックブルーなどへ一括変更する際に、AIは画面全体のピクセルを一律に処理するため、役者の肌色（スキントーン）までが不自然に染まり、作品のクオリティが崩壊するリスクがある。

　映画表現において、どんな過酷な照明環境下でも、役者の自然な肌の質感（スキンフリック）を維持することは観客への没入感に不可欠である。AIに肌色（スキントーン）とそれ以外の背景要素を厳密に区別させ、スキン領域を保護（隔離・マスク）しながら周囲のトーンを変化させる高度な技術的解決が、実用化の鍵となる。

5-3. 解決手段：Gemini Omniのセマンティック領域分離とACES 2.0肌色保護技術

① セマンティック・セグメンテーションによるレイヤーの自動完全分離

　前述した画面全体を一律に染めてしまうグローバル・フィルタリングの弊害（役者の肌が青紫に変色し、生体としての実在感が失われる現象）を技術的に解決するため、本パイプラインでは「Gemini Omni」が持つ意味論的領域分離（セマンティック・セグメンテーション）のアルゴリズムをNukeのコア・ノードツリーへ直結させる。

　従来のVFX工程において、背景と手前の人物を切り分け、特定のルックから役者の肌を守るためには、エッジを1フレームずつ手動で囲う「ロトスコープ（Roto）」や、高度なカラーキーイング（Keylight や Primatte による特定の肌色抽出）が必要であった。しかし、激しいカメラワークやライティングの変化（LEDからの環境光の照り返し）があるバーチャルスタジオの収録素材では、手動マスクのズレやキーイングの甘さによる輪郭の「黒フチ（エッジ・アーティファクト）」が避けられず、手戻りの原因となっていた。

　Nukeのコンポジット・パイプライン上に組み込まれたGoogle Flowの自動処理ノード（内部的にGemini OmniのAPIを駆動するカスタムC++プラグイン、または Inference ノード）は、実写プレート（RAW/LogからACEScgへInput Transformされたクリップ）が入力された瞬間、ピクセル群を単純なカラー値としてではなく、メタデータと文脈を伴った「構造体」としてディープラーニングベースでスキャンする。

1. 3次元バウンディングとオプティカルフローの統合:
   AIは単一フレームの静止画解析ではなく、時間軸の前後フレーム（コンテクスト）およびオプティカルフロー（画素の移動ベクトル）を同時に監視する。これにより、撮影カメラが激しくパン（横移動）したり、役者が背景のLEDパネルの手前を高速で横切ったりした場合でも、モーションブラー（被写体ブレ）に含まれる半透明な境界線を正確に追従する。

2. マルチレイヤー・マットの自動生成（ディープ・データ化）:
   Gemini Omniは、画面内の要素を「Human_Skin（人間の肌）」「Human_Hair（頭髪）」「Garment（衣装・衣服）」「Props（小道具）」「Virtual_Background（LEDウォールに投影されたOpenUSD背景）」というように、セマンティックな意味ごとにインテリジェントに個別分離する。
   この結果、Nukeの内部ストリームへは、RGBチャンネルとは完全に独立した形で、エッジのアンチエイリアスが完全にクリーンアップされた16bit浮動小数点の「スキン・アルファマスク（Skin Matte）」が動的に生成・送出される。頭髪の微細なほつれや、衣装と肌の境界線といったマクロなディテールにいたるまで、人間のロトアーティストが数週間を要するレベルのマスククオリティが、フレームの読み込みとほぼ同時にバックグラウンドで完成する。

　この自動分離された高精度なスキン・アルファマスクが、Nukeのチャンネル構造（matte.skin などのカスタムレイヤー）へ格納されることで、次ステップである「肌色トーンの厳格な隔離保護と、周囲の背景要素のみのシネマティックカラーシフト」を数学的に正しく実行するための絶対的な下地が整う。

② ACES 2.0「肌色専用領域」の隔離保護（マトリクス・サスペンド）のノード設計とロジック

　5-3の①で生成された高精度な「スキン・アルファマスク（Skin Matte）」は、Nukeの内部ストリーム（matte.skin レイヤー）を経由し、カラープロセスの破綻を数学的に防ぐための「マトリクス・サスペンド（行列演算の局所的一時停止）」プロセスへと投入される。

　映画標準の色管理規格「ACES 2.0」への完全準拠を前提とする本パイプラインにおいて、Flow Agent（Gemini Omni）が提案するシネマティックな一括色補正（例：シャドウからミッドトーンにかけての深夜のブルーへのシフト）は、内部的にはACEScgリニア空間上のRGB3×3変換行列（Color Matrix）や、ルックアップテーブル（3D LUT）の乗算として実行される。この補正を単純に画面全体（実写プレート）へ適用すると、役者の肌を構成する重要な色度座標が、ACES 2.0の広色域領域から不自然な色域（色空間の隅）へと押し込まれ、生体としての自然なトーンが崩壊する。

　これを防ぐため、Nukeのコンポジットノードツリー上では、以下のような厳格なコンポーネント構造が自動構築され、肌色の保護が実行される。

1. カラー補正ノードの分岐（スプリット・パイプライン）:
   Input Transform（ACES 2.0 IDT）を通過したオリジナルの実写プレートは、Nuke内で一度2つのラインに分岐される。

   • ラインA（バックグラウンド・衣装用）: Flow Agentが算出した「深夜のシネマティックブルー」のトーン（Grade または OCIOColorSpace ノード）が100%適用され、衣服やOpenUSD背景がドラマチックに変色するライン。

   • ラインB（肌色保護用）: 現場のシネマカメラ（LogC4等）が正しく記録し、TTL補正によって最適化された、ピュアなACEScgの肌色（生体としての健康的なカラー階調）を完全に無傷のまま維持（サスペンド）するライン。

2. Keymix ノードによる数学的マージとACES 2.0マスター領域のロック:
   これら2つのラインを統合する中核として、Nukeの Keymix ノード を配置する。

   • Keymix の A 入力に「色補正済みのラインA」を、B 入力に「無傷のラインB」を接続し、Mask 入力に対して5-3の①で抽出した matte.skin（スキン・アルファマスク）をダイレクトに直結する。

   • この接続により、Keymix ノードの内部演算では、マスク値が「1（完全な肌領域）」のピクセルに対しては、ラインAのカラーマトリクス演算（青色へのシフト）を完全にバイパス（無効化）し、ラインBの数値を100%出力する。

　このノードロジックの最大の技術的強みは、ACES 2.0の色管理下において、観客が最も視線を注ぐ役者の「肌のマスター領域（スキントーン・アイランド）」を、環境光の極端なルック変化から物理的に隔離・保護できる点にある。

　背景や衣服がどれほど冷徹なサイバーパンク・ブルーやネオンカラーへと染まろうとも、役者の顔や手の肌色が持つ本来の血色感（ヘモグロビンやメラニンの光学的反射特性に基づいた、リニアな輝度・色度バランス）はマトリクス的にロックされる。結果として、AIによる超高速な一括グレーディングの利便性を享受しながらも、従来の「AI一括フィルター」で頻発していた、役者がゾンビのように青ざめて人間味が失われるというクオリティ破綻を100%回避することが可能となる。

③ 統合コンポジットとスマート・カラーなじませ（マージ）のエッジ処理技術

　5-3の②において、Keymix ノードを用いて「色補正済みの背景・衣装（ラインA）」と「無傷のACES 2.0肌色領域（ラインB）」を数学的に分離・保護した状態のままでは、コンポジットのクオリティとしてまだ未完成である。なぜなら、肌の色を100%完全に保護して隔離した結果、逆に背景の深夜のブルーの環境光（Ambient Light）が肌のエッジに一切干渉しなくなり、実写の人物が3D空間から浮き上がって見える「合成の貼り付け感（切り貼り感）」という別の視覚的破綻が生じるためである。

　この光学的な不自然さを解消し、隔離された肌色を維持しながらも周囲の空間へと完璧に「なじませる」ため、Nukeのパイプラインでは以下の高度なエッジ・インタラクション（相互光演算）処理を自動実行する。

1. LightWrap（ライトラップ）による動的環境光の回り込み演算:

   • Nuke内に最新のUSD対応 LightWrap ノード（またはGemini Omniが光学シミュレーションを行うカスタムライトラップノード）を生成する。

   • このノードの Background 入力にカラー調整済みの背景映像（ラインA）を、Foreground 入力に保護された人物映像（Keymixの出力）を接続する。

   • AIは背景の明るい要素（この場合は深夜のネオンやシネマティックブルーのハイライト成分）を解析し、肌の輪郭（エッジ）の内側に向かって、光が物理的に回折・ブレンドされるような「ライトラップ・マット」を動的に生成する。

   • この回り込みのカラー処理には、当然 ACEScgのリニアな輝度スケール がそのまま適用されるため、光の強度が不自然に白飛びすることなく、実写の肌の上に「背景の青い光がうっすらと照り返している」という光学的に正しいルックがミクロ単位で合成される。

2. セマンティック・エッジ・ディレイティング（Edge Delighting）とカラーマッチング:

   • バーチャルスタジオのLEDウォールから役者の肌の輪郭に照射されてしまっていた「撮影現場の古い光（現場のLEDの色濁り）」を打ち消すため、エッジ領域に対してのみ、ピンポイントでカラーマッチングを施す。

   • 5-3の①で生成した matte.skin の輪郭部分を EdgeBlur および Dilate/Erode ノードで数ピクセル分だけ内側に侵食させ、その境界部分に対して、背景のブルーの補色または同系色を微量にブレンド（乗算・加算）する。

3. スマート・マッチムービングとグレイン（粒状感）の再統合:

   • AI生成アセットやLEDウォールの映像はデジタル由来でノイズ（グレイン）が存在しないか均一であるのに対し、実写カメラ（ARRI等）のRAWデータにはセンサー固有の美しいシネマグレインが含まれている。

   • 肌領域を保護したことで分断されたグレインの連続性を維持するため、Keymix の最終出力の直後に DasGrain（またはNuke標準の ScannedGrain）ノードを配置。実写の肌から抽出したグレインの周波数（RGBそれぞれのノイズパターン）を、カラー調整された背景や衣装の領域に対しても100%正確に再合成（再適用）する。

　この一連のエッジ処理技術により、「役者の肌本来の健康的なカラー階調（ACES 2.0のマスター領域）は100%保護して隔離」されているにもかかわらず、手前の役者と奥の環境が同一の空気感、同一の光、そして同一のシネマテクスチャを共有する。

　結果として、AIによる超高速・大雑把な「自然言語一括グレーディング」をパイプラインの最上流で走らせながらも、最終的な画面出力（TTL画面およびマスター出力）においては、ハリウッドの熟練コンポジターが数日かけて精緻に手作業でなじませたかのような、破綻の全くない最高峰の映画クオリティのコンポジットが、全自動かつノンストップで完了するのである。

6. おわりに：AIと人間が織りなす「最適化された」共同製作の未来

　本稿で詳解した「Google Flow」および「Gemini Omni」を核とした次世代3D映像制作パイプラインは、単なる制作期間の短縮や効率化のツールに留まるものではない。それは、かつて数億ドルの巨額な資金と数百人規模の専門VFXエンジニアを必要としていた「ハリウッド映画並みの高度なデジタル非破壊パイプライン」を、インディーズの制作チームや個人のクリエイターの手の中に完全に民主化したという、本質的な映像革命の記録である。

　本パイプラインは、2D設定からACES 2.0に対応した高品質なOpenUSD（.usd）を生成し、リアルタイムでのLED投影やAIによるセマンティック分離技術を用いた高度なポストプロダクションまでをシームレスにつなぐ。これにより、技術的なボトルネックを解消し、映像制作の民主化を実現する。

　AIが複雑なトポロジー処理やカラー管理といった「クリエイティビティの前段階にある障壁」を担うことで、人間は物語性、演出、ルック開発といった「本質的なクリエイティビティ」に集中できる環境が整う。

「AIか、人間か」の対立は終焉し、AIの計算力と人間の創造性がOpenUSDとACES 2.0を介して融合する真の共同製作時代が到来したと言える。

関連記事：

関連マガジン：

#コスモネス・ソルジャー #GoogleFlow #OpenUSD #Nuke #DaVinciResolve #UnrealEngine5 #インカメラVFX #ACES #OpenEXR #GeminiOmni #映画制作