受け取り側は現場の納品物を使い続けられるとどう判断するか
現場の納品物をそのまま使えるかどうかを判断するのは、「ファイルが開けるか」から始めるべきではありません。次の 3 層の順序で照合します。まず素材へ対応付けられるか、次にシーン・ショット・テイクへ対応付けられるか、最後に現場の判断が本当にこの生成物まで書き込まれているかです。SlateX が渡せるのは、各生成物に実際に書き込まれた文字どおりの値と、その由来の関係までです。下流の流れへ入れるに足るか否かは、引き続き受け取り側が自分のインポート用テンプレートと素材の状況で判断します。
検収とは、ファイルに「合格」の印を押すことではなく、「身元が不明、関係が合わない、判断を追跡できない」という 3 種類のリスクを順番に除外していくことです。
まず問う：この行は本当に素材へ対応付けられるか
最初に素材の身元と時間上の位置を見ます。リール番号、クリップ名、カメラ、入り点、長さ、フレームレートは、素材または現場の記録へ戻って出所を確認する必要があります。あるフィールドは人の入力から、あるフィールドはソフトウェアの派生から、あるフィールドは値が欠けたときにフォールバックの文字列で補われます。受け取り側は、今見ている値がどれなのかを先に知ったうえで、その値をマッチングの根拠に担わせられるかを決めます。
ここで構文的に正しいことを事実として正しいものと取り違えません。形の正しいタイムコードの文字列でも、欠値のあとのフォールバックである場合があります。ある終り点の位置も、入り点と長さの計算から来ていて、独立に測った値ではないことがあります。個々の受け入れソフトがこれらの列をどう解釈するかまでは、現在の証拠では次の 1 文の境界しか支えられません。受け取り側は自分のインポート用テンプレートで列ごとに照合します。
この段階で素材の身元または時間の出所がそもそもたどれないなら、後続の並び順やテイク評価を論じる必要はありません。出所のはっきりしない値へ受け入れ側で新しい説明を足し続けるより、まず元の記録へ戻って確認するほうが確実です。
2 番目の問い：シーン・ショット・テイクへ対応付けられるか
素材を識別できるようになったら、次に同じ 1 件の記録がシーン・ショット・テイクの関係に沿って現場の記録へ戻せるかを確認します。4 種類の生成物は同じ表の別の見た目ではないため、ある 1 枚のファイルの行番号を別のファイルの位置キーとしてそのまま使うことはできません。
抜き取り検査では、シーンごとに一部のテイク記録を選び、身元が完整でカメラがはっきりしている記録から始めて、複数のカメラや欠値のある場合までカバーします。このやり方の目的は、固定の抜き取り比率を出すことではなく、1 枚の全行を人の手で見る人手コストを避けつつ、ある生成物から別の生成物へ主要な関係がたどれるかを確認することです。
この層で知っておく必要がある事実は「行数と順序が違い得る」だけであって、個々の並び順の規則まではここで展開しません。実際に突き合わせで使うのはシーン・ショット・テイクの身元で、行番号ではありません。並び順の差異の仕組みは、別の篇で専ら説明しています。
3 番目の問い：現場の判断はこの生成物まで出てきたか
素材にも対応付けられ、シーン・ショット・テイクにも対応付けられるようになって、はじめて現場の判断が追跡できるかを確認します。ここで特に「ファイルに列が 1 本ある」と「その列が現場の判断」を分けます。
構造化リストにはテイク評価の列がないため、それ単体から現場の Circle、Keep、Hold、N/G の判断を復元することはできません。表形式の生成物には Rating と Circle がありますが、Circle はそのテイクが Circle にマークされたときだけ TRUE を書き、その他は一律 FALSE を書くので、現場で「Circle 印を付けられた」ことの意味すべてと等しくはありません。人が読む日報は 1 本の take に 1 行で、各行は 1 台のカメラの一部のパラメータだけ取っています。すべてのカメラのパラメータの集計ではありません。脚本の工程ファイルは脚本の構造までしか戻らず、撮影結果・テイク記録・カメラ・タイムコードはいずれも入っていません。
同じ 1 件の記録が複数の生成物に「どれも有るように見える」ことは、それらが同じ種類の判断情報を担っていることを意味しません。
4 種類の生成物はそれぞれどこまで担えるか
構造化リストはカメラごとの素材の身元・タイムコード・シーンとテイクの関係を検査するのに向いていますが、テイク評価の列はなく、素材のパスもチャンネルマップも持ちません。表形式の生成物はさらに多くの現場フィールドとテイク評価のテキストを担いますが、派生列と現場の意味が別物であることに引き続き注意が必要です。人が読む日報は、1 本の take の概観を目で眺めるのにより向いていますが、マルチカメラでは 1 台のカメラの一部のパラメータしか表示しません。脚本の工程ファイルが担うのは脚本構造の交換で、撮影結果の書き戻しは担いません。
これらの差は、受け取り側が 4 種類の生成物に互いにマスごとに複製させることはできないことを意味します。正しい検収の目標は、各ファイルが自分の一区間の責務を担い、主要な身元が元の記録へ戻って照合できることです。
通らないとき、どの層で止まるか
素材の身元または時間の出所が合わなければ、素材の照合という層で止めて、まず出所へ戻ります。素材は合うがシーン・ショット・テイクの関係が作れないなら、身元の関係という層で止めます。前の 2 層が成立しているのに現場の判断が対象の生成物にそもそも存在しないか意味が違うなら、ファイルが表していない結論を代わりに補うことはしません。
現在の証拠では、撮影日別の集計や撮影日別の書き出しを検証済みの能力として扱うこともできません。したがってこのやり方は「ある 1 日の集計ファイル」を検収の前提にしません。実際に生成される 4 種類の生成物と、そこに既にある文字どおりの値だけを検査します。
検収は最終的に受け取り側の仕事です。SlateX が渡せるのは、検証できる値・派生の関係・既知の境界までで、「検収通過」の証明ではなく、下流の結果を保証するものではありません。
FAQ
納品物を受け取るとき、まず何を照合しますか？
最初に素材の身元と時間の出所を照合します。リール番号、クリップ、カメラ、入り点、長さ、フレームレートが素材または現場の記録へ戻って確認できないなら、後続のシーン・ショット・テイクの関係もテイク評価の判断も信頼できる前提を欠きます。
なぜ 4 枚のファイルを行番号でそのまま突き合わせられないのですか？
生成物ごとに行数と並び順の仕組みが別々だからです。受け取る際はシーン・ショット・テイクの身元を共通キーにし、あるファイルの行番号が別のファイルでも同じ記録を表すとは想定しません。
表形式の生成物の Circle を現場の Circle 印の状態として扱えますか？
そのまま等しくはできません。現在の Circle 列はそのテイクが Circle にマークされたときだけ TRUE を書き、その他は一律 FALSE です。現場の他のマーク状態が同じ文字値になるとは限らないため、受け取り側は Rating と元の記録を併せて照合する必要があります。
この流れは、ファイルが下流の検収を通ったことを証明できますか？
証明できません。あれが提供するのは照合の順序と追跡の条件までで、具体的なインポートの挙動と下流への影響は、引き続き受け取り側が自分の環境で検証する必要があります。
Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。