書き出した FDX から戻ってこないものは何か
SlateX が書き出した FDX をこの App に再び読み込ませても、元のプロジェクトをそのまま積み直すことにはなりません。ファイル単位ではプロジェクト名を書き、シーン単位ではシーン番号、内/外、シーン名、時間帯、八分の一、改稿カラー、省略の状態、ページ番号、脚本項目を中心に取り交わします。この書き出し範囲に入っていない App データは、このファイルでは戻ってきません。それ以上に重要なのは、書き出し範囲に属する値でも、一部のものは「エクスポートして再び読み込む」操作のあとに、両側のコードから直接導ける書き換えを受けるという点です。
FDX で戻ってこられる上限は、まず書き出し範囲が決めます。範囲内の値であっても、一文字違わず元の形に戻ることを意味しません。
書き出した範囲がそのまま戻ってこられる上限になる
ファイル単位とシーン単位を合わせると、書き出し側はプロジェクト名を保ち、さらにシーン番号、内/外、シーン名、時間帯、八分の一、改稿カラー、省略の状態、ページ番号、脚本項目という 1 組の情報を保ちます。ショット、テイク記録、カメラ、タイムコード、メディアパスなどはこの FDX の書き出し構造に入っていないため、このファイルからそれらの現場記録を復元することはできません。
ここが『FDX は何を交換し、何を運ばないか』と本稿の役割分担です。親篇は交換範囲を説明し、本稿は同じ 1 つの脚本交換ファイルが出てから戻るだけを見て、範囲内の内容がどう変化するのか、どの内容には戻りの担い手自体がないのかを扱います。
3 か所の内容は往復のあと決定的に書き換わる
ひとつはシーンタイトルの重ね書きです。FDX から読み込んだシーンでは、シーン名に元のタイトルがまるごと残され、それとは別に内/外と時間帯が各自 1 つずつ保存されています。もう一度エクスポートするとき、書き出し側は「内/外の接頭辞 + 元のタイトルまるごと + 区切り文字 + 元の時間帯」でシーンタイトルを組み立て直すため、タイトルと時間帯のテキストがもう一遍重ねられます。App 内で手作業により新規作成したシーンはこの点で挙動が違い、3 つの部分はもともと別々に保存されているので、同じ重ね書きの出所が発生しません。
もうひとつはピリオドの重複です。読み取り側は INT. のような接頭辞をピリオド付きのまま保持することがあり、書き出し側はさらに内/外のうしろにピリオドを 1 つ足すため、1 回の往復でピリオドが 2 つ並んだ形が現れ得ます。ここで言っているのは両側の規則を合わせた結果であって、第三者のソフトウェアの挙動の推測ではありません。
3 つめは概要の置換です。読み込み時、メモ・概要類の内容がシーン概要に入ることがあり、そうした書き込み待ちの概要がないときは、先頭の動作または一般の段落が概要として使われることもあります。そのため概要に入るのは動作描写の全文であって、あらすじではありません。書き出し側はシーン概要を対応する属性へ書き戻さないため、再度読み込むと、この位置は再び先頭の動作または一般の段落に置換され得ます。
戻る経路の変化がほかにも 3 種類あり、分けて見る必要がある
シーンの八分の一が 0 のとき、書き出し側は長さ属性そのものを書きません。読み戻すときには長さがないものは 1/8 ページとして扱われるため、「0 または空」は 1/8 ページになります。再び読み込んだシーンの状態は「未撮影」として書かれ、FDX から元の撮影状態を復元することはできません。メモ・概要類の段落は脚本項目として元の位置に戻らず、脚本項目の順序も番号の採り直しになります。
これらの変化はファイルが壊れているという話ではなく、「このフォーマットが何を書くか」と「読み戻し時にどうオブジェクトを作るか」が同じ話ではないということです。『納品物における空の値の 4 つの形』は空文字列、属性の欠落、プレースホルダなどの形を区別する助けになりますが、ここでは引き続き FDX の往復だけを論じています。
硬い境界：コードから導けることは、第三者の往復で検証済みではないことを意味しない
シーンタイトルの重ね書き、ピリオド 2 つの重複、概要の置換は、いずれも書き出し側と読み戻し側の規則を組み合わせれば直接導ける結果です。こちらは実際の第三者の脚本ソフトで「開く、名前を付けて保存、再び読み込む」の 1 周りをまだ完走していないため、ここで確定できるのはたった 1 文だけです：往復は逐字の保存を保証しません。
この境界は外挿の範囲も同時に制限します。ここの確定的なコードの挙動を「ある第三者の脚本ソフトが必ずどうなるか」と書くことはできず、まだ通っていない実際の往復を検証済みと書くこともできません。受け取り側は実際の交換ファイルと、読み戻し後のシーンタイトル、長さ、概要、状態を自分で照合する必要があります。
往復は逐字の保存を保証しません。コードは書き換えの経路が存在することを示せますが、実際の第三者のソフトでの「開く、名前を付けて保存、再び読み込む」の操作は依然として 1 ファイルごとの照合が必要です。
FAQ
FDX はショットとテイク記録も一緒に戻してくれますか？
現在の書き出し構造からそれらの現場オブジェクトは得られません。この FDX の交換範囲に入っていないため、ファイルを再び読み込んでも何もないところから再作成はされません。
シーンタイトルに接頭辞と時間帯がもう 1 層増えるのはなぜですか？
FDX から読み込んだシーンは元のタイトルまるごと、内/外、時間帯を同時に保持していて、再エクスポートのときにこの 3 つをもう一度結合します。手作業で作ったシーンはこの点で挙動が違い、3 つの部分はもともと別々に保存されているためです。
概要が動作描写になってしまうのはなぜですか？
書き込み待ちのメモや概要がないとき、先頭の動作または一般の段落が概要として使われることがあり、しかも概要には対応する書き戻し経路がありません。そのため再読み込みのときにこの位置は動作描写の全文に置換され得ます。
これらの結論は第三者の脚本ソフトで往復が通ったことを意味しますか？
意味しません。第三者の実際のソフトでの完全な往復の検証はまだ完了していないため、受け取り側は実際のファイルを自分で照合する必要があります。対外的な境界は引き続き「往復は逐字の保存を保証しない」です。
Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。