マニュアル

素材、文字起こし、字幕、カット、アングル、音声、NLE納品を別々に作らない。1つの正本から派生物を作り、各段階でhash・FPS・フレーム範囲・未解決項目を記録する。

このワークフローの証拠分類は [docs/KNOWLEDGE_CLEANUP_20260809.md](../../docs/KNOWLEDGE_CLEANUP_20260809.md) が優先する。旧成功例は教師参照、失敗例は回帰証跡、未検証値は停止条件であり、どれも自動的に本番正本へ昇格しない。

原始JSON / 原始字幕
  ↓ 内容の校正
校正JSON / 校正字幕
  ↓ 句読点・表記・話者・時間軸の確定
マスターJSON / マスター字幕（本編）
  ↓ 本編用の編集判断
縮約字幕（本編）
  ↓ 構成案の cutFrames による時間軸変換
縮約JSON / 縮約字幕（ショート各回）
  ↓ メディアRegistry・アングル・音声レーンを解決
TimelineIR / Resolve用cut plan
  ↓ コードで新規DRTを生成（教師構造を限定置換）
DRT → Resolveへインポート → DRT/DRP/API読戻し → close/reopen → スクショQC

派生SRTをマスターへ逆流させない。元ファイルが見つからない層は unknown、意味が確定していない層は candidate とし、推測で known に昇格させない。

教師DRTと候補DRTは、まず次の二つを分けて照合する。

• 素材同一性: Media Storageの完全パス、Asset Registry、実測FPS、duration、必要ならhashが同じか。
• 編集グラフ同一性: track topology、record/source range、MediaRef、multicam selector、Transform/Crop、Composition、字幕形式が同じか。

同じ収録素材を参照していても、編集グラフが違えば同じ画面にはならない。教師DRTのV2/V3を「Angle 1/2」と一般化せず、教師内で観測したangle selection、話者フォーカス、幾何プロファイルを別々に保存する。

multicamは名前、FPS、解像度、VirtualAudioTracksBAが一致しても同一とはしない。DbId、UniqueMediaPoolItemId、FieldsBlob、nested Sequence、SeqContainerのhashが異なる再生成multicamでは、CurrentSelectorIdxを移植しただけで教師のAlt+2選択へ戻るとは限らない。正本候補は、教師multicamコンテナと参照Sequenceを構造ごと保持する経路、またはDRTから読んだAngle→raw camera file / offsetを使ってraw素材を実体化する経路の二つに限定する。

Resolveの生成経路は、教師DRTを構造テンプレートとして扱い、BG / Angle / Slide / Overlay、native subtitle、Text+ / Fusionの実在トポロジーを保持したうえで、master cutのrecord/source rangeと本文だけを限定置換する。AppendToTimeline、CreateEmptyTimeline、SetSetting、SetProperty、ImportFusionCompを使って本番構造を組み直す経路は正本にしない。これらは既存成果物の読戻し・原因切り分け用の実験に限る。

DRT直接編集は、既知のXML scalar、または教師と候補の一変数差分で一意に確認した領域だけをコードで新規DRTへ出す。EffectFiltersBA、CompositionBA、MediaTimemapBA、未知ID、字幕payloadは、サイズ・圧縮フラグ・内部長さを含む構造が解読済みでない限り書き換えない。Text+やFusionをPNGへ焼き付けて代替しない。Resolve API/GUIはそのDRTをインポートし、読戻し、スクリーンショット・レンダー・差分を取得するためだけに使う。APIの戻り値やSetPropertyの読戻し成功だけで画面一致とは判定しない。

現在のbuild_short_flat.py、bake_titles.py、apply_fusion.pyは、既存候補の監査・比較用の旧経路であり、この固定ルールの本番生成器ではない。コード側のDRT生成器で作った新規候補だけをResolveへ渡す。

• 構成案はマスターJSONをsourceとし、sourceSha256を保存する。
• 各ショートは本編の cutFrames を順番に連結する。未使用区間を暗黙に字幕へ残さない。
• 連結後の字幕は本編時刻をそのまま使わず、各カットの記録時刻へ再マップする。
• filler、重複、笑い、相づち、聞き手の反応は編集候補としてフラグ化する。自動削除を確定扱いにしない。
• 構成案が pending または provisional の場合、生成物は候補タイムラインと表示し、本番正本へ昇格させない。
• 字幕は合成SRTを一括投入し、Resolveの読戻しで件数・順序・start/end・位置を検証する。

メディアストレージ上の実ファイル、解像度、FPS、音声チャンネル、タイムコード、hashを入力Registryへ固定する。ファイル名や既存タイムライン名だけで素材を同一視しない。

ビデオ列は意味で管理する。

BG      背景・ベース
Angle   話者・全体・free のカメラ映像
Slide   スライド・挿入映像
Overlay ロゴ・黒線・装飾・補助映像

オーディオ列も意味で管理する。

Dialogue   統合マスター音声を基本とする
BGM        音楽
SE         効果音・演出音

必要な列数は素材の存在数で決める。音声の原音3ラインを加工した統合マスターを本編側のDialogueマスターとして保持し、ショートではその本編ラインをカットする。ショート全体を別音声へ再合成して置き換える設計を標準にしない。差し替え時は元ライン、派生ファイル、処理パラメータ、測定値をmanifestで紐付ける。

タイムラインFPSは素材・本編マスターの実測値を第一候補にする。24と23.976を名前だけで決めず、メディアとResolveの timelineFrameRate を照合し、変換する場合は変換比と丸め規則をmanifestへ保存する。

• マルチカムの選択情報と、選択後のPan/Tilt/Zoom/Cropを別のデータとして扱う。
• Alt+1 等のカメラ選択はアングルID、話者を画面内に収める位置は幾何情報である。
• 話者、顔、音声波形、カメラメタデータを組み合わせて候補を作る。3人を4人に分けた場合は、ディレクター音声か同一人物の重複かを候補として表示する。
• 人物名はプロジェクト全体の辞書とPart固有の辞書を分ける。確定できない話者は candidate / unknown のままにする。
• 同一カメラの中休み分割は、ファイル数ではなくメタデータ・時間軸・映像内容で同一性を判定する。
• 連続発話中の聞き手の反応、頷き、笑い声は reactionCue として構成案へ入れ、カメラ変更候補にする。

音声は原音保持、同期、EQ、ゲート、コンプレッサー、リミッター、ラウドネス測定を別工程にする。コンプを強くして音圧だけを稼がず、反響・ノイズ・ダッキングを含む測定結果を残す。未解決区間がある場合は生成を停止する。

HDRは素材がS-Log3 / S-Gamut3 / 10bitでも、自動でHDR納品へ昇格させない。Resolveの色管理、入力変換、出力色域、HDRメタデータ、HDR Light Level Report、実レンダー、close/reopen読戻し、テストチャート結果が揃って初めて適用する。推測値は使わない。

source hash / media hash
  → master hash
  → plan hash・FPS・cutFrames
  → short SRT cue readback
  → audio unresolved=0
  → Resolve API readback
  → DRT/DRP export
  → close/reopen readback
  → representative screenshots + reference comparison

どれかが未達なら、成果物の状態は candidate または blocked と表示し、「完成」とは呼ばない。

映像をResolveへ配置するときは、Fitを名前だけで扱わず、素材寸法・タイムライン寸法・入力スケーリング・旧正典の測定値を1つの契約として記録する。

• 素材実寸: ResolveのGetClipProperty()['Resolution']
• 素材FPS: ResolveのGetClipProperty()とMediaTimemap
• タイムライン実寸/FPS: timelineResolutionWidth/Height、timelineFrameRate
• 入力スケーリング: centerCropまたはscaleToFit
• 基準素材寸法と基準フレーム: 旧DRP/DRTから実測した値
• Transform: ZoomX/Y, Pan, Tilt, CropTop/Bottom/Left/Right

centerCropのfit倍率はmax(targetWidth/sourceWidth, targetHeight/sourceHeight)、scaleToFitはmin(...)である。倍率と同時に、実際に見える素材矩形をdisplayed_source_rect()で記録する。

基準素材と実素材のアスペクト比が同じなら、3840×2160と1920×1080のような画素数の違いだけではTransform値を変えない。これをしないと、同じ16:9素材のZoom/Pan/Tiltが誤って半分になる。

アスペクト比が違う場合だけfit倍率比でZoom/Pan/Tiltを変換し、Cropは出力フレームの設計値として保持する。変換後の素材矩形・倍率・実素材寸法はResolve監査JSONへ書く。解像度が取得できない場合は推測で配置せず停止する。

実装は[geometry_contract.py](../../tools/resolve-adapter/geometry_contract.py)に集約し、プロファイルのgeometryContractで基準値とinputScalingを指定する。Part1の正本は[Part1.json](../../templates/shorts/katto/Part1.json)である。

Transform値だけでは合格にしない。DRT再読戻しと代表フレームのスクリーンショットで、映像バンド上下境界、人物の頭部・肩、字幕安全領域、黒線、背景の露出範囲を比較する。差分が出た場合は、素材寸法・fit・表示矩形・Transformの順に原因を切り分ける。

2026-08-09 cleanup: this is a readback and experiment manual. It does not authorize API timeline construction. Current evidence status is maintained in [docs/KNOWLEDGE_CLEANUP_20260809.md](../../docs/KNOWLEDGE_CLEANUP_20260809.md).

対象版: DaVinci Resolve Studio 21.0.3.0007（Windows 11）

Python 3.13 / DaVinciResolveScript（fusionscript.dll）

このファイルは実測で確かめたことだけを書く。公式ドキュメントに無い挙動が大半で、

どれも 1 変数だけ動かして画を書き出し、px を数えて確定させたもの。

推測は書かない。分からないものは「未確認」と書く。

版が変わったら測り直す。下の値はすべて 21.0.3 での実測。 別の版で違う結果が出たら、この表を上書きせず版ごとに追記すること。

関連する正本:

• ショートの組み立て仕様 … docs/SOT.md から docs/SHORTS_CUTTER_SUBTITLES.md へ辿る
• ネイティブファイルを書かない規則 … docs/PLAN.md §0-4-7

実行順の入口: [DaVinci Resolve 実装マニュアル](README.md) → [DaVinci Resolve 実装ワークフロー](davinci_resolve_workflow.md)。

解析で確認した事実と未確定事項: [manual/knowledge/resolve/](../knowledge/resolve/README.md)。

2026-08-08 に丸一日を溶かした。原因は API ではなく、確認する場所を間違えたこと。

Timeline.GetSetting("timelineInputResMismatchBehavior") を読んで

「これが Timeline Settings > Format の Mismatched resolution だ」と決めつけた。

確かめていない。GUI を開けば 10 秒で分かったことを、値だけ見て判断した。

GUI には Mismatched resolution が 2 つある。

timelineInputResMismatchBehavior と timelineOutputResMismatchBehavior は

どちらを聞いても同じ値を返した（正典 4 本すべて）。

だから戻り値だけでは、どちらの欄を見ているのか判別できない。

画で測った結果（1080x1920 タイムライン、3840x2160 のマルチカム素材）:

SetSetting は効く。scaleToFit / centerCrop は True を返して反映される

（scaleToFill / stretchToAll は False）。

• 設定キーを使う前に、GUI のどの欄かを 1 度だけ目で確かめる。

値を変えて GUI がどう動くかを見る。同名・類似名のキーが複数ある前提で疑う

• 正典から 1 フレーム書き出し、作ったものと同じ方法で書き出して px を数える。

数値の一致ではなく絵の一致を関門にする。これを最初にやる

• `.drt` にタイムライン設定は入っていない。drt_*.py が読めるのはクリップの幾何だけ。

「学習した」と言うときは、何を読んで何を読んでいないかを明示する

SetProperty した値を GetProperty で読み戻して一致を確認するのはトートロジーで、

設定が効いたことしか示さない。絵がどうなったかは何も保証しない。

生成と判定が根拠を共有しているなら、それは遵守率であって正しさではない （~/.claude/CLAUDE.md 検証と報告）

正しさを測るなら独立な系統を使う。ここでは「レンダリングした画の px」。

import os, sys
API = r"C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting"
os.environ.setdefault("RESOLVE_SCRIPT_API", API)
os.environ.setdefault("RESOLVE_SCRIPT_LIB",
    r"C:\Program Files\Blackmagic Design\DaVinci Resolve\fusionscript.dll")
sys.path.insert(0, os.path.join(API, "Modules"))
import DaVinciResolveScript as dvr
app = dvr.scriptapp("Resolve")

Resolve にダイアログ（Project Settings 等）が出ていると、書き込み系の API が全部死ぬ。

エラーにならず None / False が返るので、気づかないまま先へ進むと原因不明の失敗が延々続く。

if app.GetCurrentPage() is None:
    raise SystemExit("Resolve にダイアログが出ている。閉じてから実行する")

プロジェクトマネージャ画面（プロジェクト未読み込み）でも None になる。

その場合は ProjectManager.LoadProject(名前) で開く。

pr = app.GetProjectManager().GetCurrentProject()
if pr is None or pr.GetName() != 期待する名前:
    raise SystemExit("開いているプロジェクトが違う。切り替えはしない")

スクリプトからプロジェクトを勝手に切り替えない。人が開いているものを尊重する。

r = item.ImportFusionComp(path)
if r:            # ← ダメ。成功しても False 扱いになる
if r is not None:  # ← 正しい

実測 2026-08-08: ImportFusionComp が 60/60 成功していたのに「60/60 失敗」と数えていた。

Composition オブジェクトが返っているのに bool() が False。

d[timeline_item] = x   # TypeError: unhashable type
d[id(timeline_item)] = (timeline_item, x)   # ← こうする

多くの API が失敗時に False ではなく None を返す。if not r: では区別できない。

tl = pool.CreateEmptyTimeline(name)
pr.SetCurrentTimeline(tl)
for k, v in (("useCustomSettings", "1"),          # ← 必ず最初
             ("timelineResolutionWidth", "1080"),
             ("timelineResolutionHeight", "1920"),
             ("timelineFrameRate", "24")):
    tl.SetSetting(k, v)

先に立てないと解像度は黙ってプロジェクト設定へ戻る。

実測: これを忘れて 13 本すべて 1920x1080 で作ってしまった。

UI には 4 択あるが、API から入るのは 2 つだけ（21.0.3 実測）。

Input Scaling / Mismatched Resolution / Resize Filter に相当する鍵は .drt のどこにも無い。

project.xml にも SeqContainer にも無い。プロジェクト設定側にある。

取り込んだタイムラインが `useCustomSettings=1` でも上書きされる。 21.0.3.7 実測

（2026-08-11、使い捨てプロジェクトで因果を確認）。

だから順序が決まる。Project Settings は全部の取り込みが終わったあとに当てる。

先に当てると、次の 1 本で黙って戻される。

これに気付かないと次のように見える —— 設定して SaveProject し、閉じて開き直して

1920x1080 を確認したのに、あとで読むと 1080x1920 に戻っている。**設定が

永続化されなかったのではなく、あいだの取り込みが書き換えている。**

追従しているタイムライン（useCustomSettings != 1）が 0 本なら、Project Settings を

動かしても既存のタイムラインは動かない。先に全部を現在値で固定してから当てる

（実測: 191 本すべて解像度変化 0）。

pool.AppendToTimeline([{
    "mediaPoolItem": item,
    "startFrame": src_in,
    "endFrame":   src_in + 尺,   # ← 排他
    "recordFrame": 置く位置,
    "trackIndex": 段番号,
    "mediaType": 1,              # 1=映像 2=音声。**省略すると両方**
}])

-1 すると尺が 1 足りず、クリップの間に 1 フレームの隙間が空く。

実測: 340 か所すべてに 1 フレームの隙間が出て、画面で見えた。

mediaType: 1 にすると音声が落ちる。実測: 13 本すべて音声 0 クリップになった。

置くと 72 フレームに丸まる。SetClipProperty("Frames"/"Duration") は False。

item.SetMarkInOut(0, 尺 - 1, "video")     # ← マークで尺を与える
pool.AppendToTimeline([{"mediaPoolItem": item,
                        "recordFrame": 位置, "trackIndex": 段, "mediaType": 1}])
                        # startFrame / endFrame は**渡さない**

• マークはプール項目に付くので、まとめて渡すと最後の 1 個の尺が全部に効く。1 枚ずつ置く
• ClearClipMarkInOut() は存在しない（NoneType で落ちる）
• 素材を再エンコードして尺を作るのはやってはいけない（浅尾却下 2026-08-07）

bg.png(1920x1080) と BG.png(4096x2160) が別プロジェクトに同居している。

小文字だけで引くと取り違える。完全一致の索引を先に引く。

見える高さ =（表示高 − cropTop − cropBottom）× zoom

表示高 = 出力幅 × 素材高 ÷ 素材幅        （scaleToFit のとき）

• crop は zoom の前に効く。単位はフレーム px（zoom 1 のとき）。素材の上端から測る
• tilt の移動量(px) = tilt × 表示高 / フレーム高
• pan の移動量(px) = pan × 表示幅 / フレーム幅
• crop は表示高で頭打ち

実測表（3840x2160 素材 / 1080x1920 タイムライン、表示高 607.5）:

z=1, crop=300 で上端が 300px、z=3, crop=300 で 900px 下がる（crop は zoom で拡大される）。

tilt=300 は zoom によらず 95px 動く（= 300 × 607.5/1920）。

pan=300 は 300px 動く（横合わせなので 1:1）。

CropTop は 608 以上を入れても全部 607.5 になる。

同じ数値でも素材が違えば別の絵になる。実測: 同じ CropTop 472 が、

マルチカム（縦いっぱい）では画の 25%、生ファイル（16:9 横合わせ）では 78% を削った。

zoom / tilt / pan = 元の値 × 基準フレーム高 / 表示高
crop              = 元の値 × 表示高 / 基準フレーム高

値だけを保存しない。必ず「何を基準に測った値か」を一緒に持つ。

native の実測: 台 bg.png(1920x1080) に comp の高さ 0.74 の矩形を無変形で載せると

799px = 0.74 × 1080。フィットなら 450、フレーム基準なら 1421 で、どちらでもない。

Fusion の台は出力と同寸の透明 PNG にする。そうすれば換算が不要になり、 comp の流し込みに失敗しても画面に何も出ない（有色の素材を台にすると全画面に出る）。

it.SetProperty("ZoomGang", False)   # ← 先に
it.SetProperty("ZoomX", 0.88)
it.SetProperty("ZoomY", 1.18)

実測: ZoomGang=True のまま ZoomY を書くと ZoomX も同じ値になり、両軸 2.0978 になっていた。

ZoomX/Y Pan Tilt RotationAngle AnchorPointX/Y CropLeft/Right/Top/Bottom

CropSoftness CropRetain Opacity FlipX/Y Scaling ResizeFilter Distortion

CompositeMode DynamicZoomEase MotionEstimation RetimeProcess Pitch Yaw ZoomGang

カラーページの Input Sizing は取れない。別系統。

• AppendToTimeline で置くと常に Angle 1
• SelectTakeByIndex / GetTakesCount は None（take として露出していない）
• アングル名は .drt の FieldsBlob に "Camera 1" のように入っているが、書く手段は無い
• CurrentSelectorIdx はアングルではない（全部 0）

差し替えるなら幾何の換算が必須。fps 違いも意識する。

.comp は Resolve 自身が ExportFusionComp で書き出すのと同じテキスト形式。

.drt / .drp のバイナリではないので、生成してよい（PLAN.md §0-4-7 の対象外）。

it.ExportFusionComp(path, 1)   # 1 = 何番目の comp か

読み取り操作なので、Resolve がモーダルでも通る。

ただし Sm2TiGenerator（Text+ の Rich）は GetFusionCompCount() が 0 で、書き出せない。

実測は 23.976。 Cam1/20260411_C0355.MP4 を ffprobe で見ると

rFrameRate = 24000/1001（dev/knowledge/part11-media-fps-evidence-20260809.json）。

書き起こしの timebase.drpFrameRate も 23.976 で一致する。

いっぽう dev/short-plan/*.json は 13 本すべて `fps: 24.0`（残り 4 本は null）。

丸めた値が入っている。

0.1% のずれは秒からフレームへ直すたびに積む。10 分地点で約 14 フレーム（0.58 秒）。

Angle の割り当ては秒で持つので、ここを取り違えると列の境界が全体に平行移動する。

被覆の検査（穴・重なり）は平行移動を検出できないので、通ってしまう。

秒 → フレームの換算に `short-plan` の `fps` を使わない。

--angle-fps の既定 24000/1001 は実測に合わせてある。

（2026-08-12 の監査でここは「実測は全部 24」と報告されたが、逆だった。

実測証跡を読み直して確認した。指摘をそのまま採らずに測って良かった例。）

同じ .comp・同じコード・同じタイムラインで、台を変えるだけで結果が変わる。

`.comp` を流し込む台は Fusion Composition クリップでなければならない。

Text+ 生成子は見た目が同じ「文字の台」でも受け取らない。

これは §6-3（session 途中で効かなくなる）とは別の原因。None が返ったときに

まず疑うのは台の種類で、再起動ではない。

Fusion Composition の台へ make_textplus_comp.py の出力を流し込み、

12 フレームだけレンダリングして 1 枚抜いた。黄色の文字が出た。

戻り値では確かめられない（§6-1 に「成功を返すのに描画されない」実測がある）。

ExportCurrentFrameAsStill も Edit ページからは真っ黒が返るので、

レンダリング → ffmpeg でフレーム抽出が唯一の確認手段。

Text+ の Size を BezierSpline で動かそうとした。構文は正しい。描画されない。

確かめたこと:

書き戻した中身は、Resolve が自分で解釈し直した形になっていた。

TemplateSize = BezierSpline {
  KeyFrames = {
    [86400] = { 0,    RH = { 86403.33, 0.0367 }, Flags = { Linear = true } },
    [86410] = { 0.11, LH = { 86406.67, 0.0733 }, RH = { 86780.67, 0.11 }, ... },

`SizeAnim` は `TemplateSize` へ改名され、ハンドル（LH / RH）は Resolve が足した。

つまり .comp は正しく解析され、アニメーションのデータは保持されている。

それでも画に出ない。

3 通り試した。全部出ない。

対照実験をした。 同じ手順で静止の comp を入れ直すと描画される。

つまりレンダリングは生きていて（キャッシュではない）、**spline を入れたときだけ

本当に出ていない。**

InsertFusionTitleIntoTimeline はリップル挿入なので本番では使えないが、

捨てて良いタイムラインなら割れて困るものが無い。 そこへ内蔵タイトルを入れて

ExportFusionComp すれば、実物のアニメーション構文が手に入る

（tools/resolve-adapter/harvest_builtin_titles.py）。

採れた実物は templates/fusion/reference/ に置いた。

実物から分かったこと:

• 時間は 0 起点（RenderRange = { 0, 119 }、キーは [2] [14] [90] [117]）。

一度「絶対フレーム」と読んだのは誤りで、そう見えたのはたまたま手元の書き出しが

タイムライン中ほどのクリップだったため

• キーは Flags を使わず LH / RH ハンドルだけを持つ
• 参照は Opacity1 = Input { SourceOp = "HeadingOpacity1", Source = "Value", }。自作と同じ
• 内蔵タイトルは Text+ を直接動かしていない。Scroll は

InstanceOutput / UserControls を挟んだテンプレート構造になっている

自作の BezierSpline を直す方向は捨てた。 4 通り試して全部描画されない

（0 起点 + Flags / 絶対フレーム + Flags / 0 起点 + ハンドル / 開始 Size を 0 でなく微小値に）。

切り分けが答えを出した。 builtin-Scroll.comp（実物）をそのまま同じ台へ

流し込むと、動いて描画される。 つまり台もレンダリングも正常で、自作の comp が悪い。

だから静止版と同じやり方に寄せた。 静止版が line.comp（実物の書き出し）を

骨格にしているのと同じで、**動きも実物を骨格にし、文言・フォント・大きさだけ差し替える。

構造・キーフレーム・ノードには触らない。**

python tools/resolve-adapter/make_textplus_comp.py \
  --text "撮り直し不可能カット" --out out.comp \
  --animated-template templates/fusion/reference/builtin-Scroll.comp \
  --font "Noto Sans JP" --style Black --size 0.09

画で確認済み。 パワーフレーズが左から滑り込んで定位置に収まる（フレーム 8/12/16/20）。

フォントは必ず差し替える。 内蔵テンプレートは Open Sans で、

日本語のグリフを持たない（差し替えないと豆腐になる。実測）。

なぜ自作の spline が描画されないかは未解明のまま。 構造（スプラインの階層・

SourceOp / Source の書き方）は実物と同じで、Resolve は受理して書き戻しもする。

解く必要が無くなったので追っていない。

同じコード・同じ .comp で 60/60 成功した後、以降はどの段・どの台でも None を返すようになる。

組み直したタイムラインでも 0/60。再生ヘッド位置・Fusion ページ・上段の無効化・

台の置き直しを試したが変わらない。Resolve の再起動が要るとみられる。

対策: 台は組み立て中に全部置き、.comp の流し込みは別プロセスで 1 回だけ走らせる。

`Composition { ... Tools = { Template = TextPlus { Inputs = { StyledText, Font, Style, Size,

Center, VerticalJustificationNew, HorizontalJustificationNew, Red1/Green1/Blue1 } },

MediaOut1 = Saver { Input = Template } } ... }`

Size はフレーム高に対する比（例 55px / 1920 = 0.0286）。

Center は {X, Y} の 0〜1。Fusion は Y 上向き（0.545 が 0.482 より上）。

実測: 810 件のうち 784 件がずれ、後半 7 本は字幕ゼロになった。

ショート内の隙間は保たれるが、ショート間の大きな空白だけ詰められる。

• Timeline.ImportIntoTimeline は SRT を受け付けない（3 通り試して全部 False）
• 字幕アイテムに開始位置を書く API は無い
• recordFrame は字幕に効かず、必ず末尾へ足される

過去の手作りタイムラインにText+字幕が存在しても、それを標準経路へ一般化しない。現行は合成SRTをnative subtitle track（ST1）へ一括投入し、生成DRTの再読戻しで件数・record frame・duration・ショート間隔を検証する。Text+は教師DRTで実在するタイトル／アニメーション要素に限定する。

字幕をText+やPNGへ変換して位置問題を隠さない。隙間をダミー字幕で埋めて辻褄を合わせない（docs/SOT.md の字幕owner）。

src_item.CopyGrades([tgt_item, ...])

サイジング（寄り）は運ばれない。実測で色は変わり、フレーミングは変わらなかった。

• 音声トラック（Sm2TiTrack）にゲイン・パン・EQ・ダイナミクスの鍵は 1 つも無い
• OutputAudioGain は 0
• dB はクリップの `EffectFiltersBA`（種別 124 / id95）にだけ存在する
• 「トラックごとのゲイン」に見えるものは、そのトラックの全クリップに同じ dB を書いた結果

Fairlight のクリップ FX はクリップの `FieldsBlob` の `FL::ClipFX`（zlib、68B レコード列）。

bmd:Dialogue Leveler と bmd:Fairlight EQ のパラメータが入る。

API から音量を書く手段は見つかっていない（未解決）。

Historical API-era rule: the original Audio TimelineItems were preserved as the source layer and the integrated WAV was treated as a derivative. This is retained as evidence only. The current contract preserves those items muted on A1 and places the hash-verified integrated WAV on A2; API placement is allowed only as a readback experiment, never as the production writer.

現行の音声経路は、A1に元Resolve Audio TimelineItemsを保持してミュートし、A2へ未解決区間0・SHA-256一致済みの統合WAVをDialogue · Masterとして配置する。A3/BGM、A4/SEはPart profileの宣言に従う。preserve_source_audio.pyは原音保持の証跡、API配置はreadback実験に限定し、manifestまたはA2読戻しが欠ける場合は本番昇格しない。

「`.drt` から学習した」と言うときは、必ずこの表を添える。

読めない項目を黙って落とすと、後段で「学習したはずなのに合わない」が起きる（実測 2026-08-08）。

幾何は API の実値を正とする。.drt の値は正規化されていて、

基準（フレーム幅か高さか）を推測すると外す。

API の GetProperty("Pan") などと 1 度突き合わせて、換算式を確定してから使う。

MpFolder.xml の Sm2MpTimelineClip は 1 つとは限らない。

本編の .drt には Part1 / Part1_digest / OP / LogoMotion copy が同居する。

最後の 1 つを採ると入れ子の別タイムラインを読む（実測: LogoMotion copy を読んで

「V1 に braw が 1 枚」という無関係な結果になった）。`<Name>` で選ぶ。

seq = next(s for n, s in candidates if n == "Part1")   # 名前で選ぶ

マルチカムのクリップは実ファイルを指していない。パスは空。

`MediaRef`（プール項目 ID）で追う。撮り直して別マルチカムに切り替わっていても

名前とクリップ数では見えない（実測: Part12 は 1 Part の中で C0356 と C0357 を使っている）。

実ファイルのフレーム = `srcIn` + `origin` + `offset`。

origin はマルチカム内部シーケンスの原点で、実測では 86400（= 01:00:00:00 @24fps）。

足し忘れると wav 秒が負になり、1 件も当たらない。

旧出力仕様にあった「カラーグレード。.drt に値が無い」は誤り。

`.drt` を読み込むとグレードが乗る以上、入っていないはずがない。

その指摘（浅尾 2026-08-08）から探し直して見つけた。

書いてある記述を検証せずに繰り返していたのが原因。

<pLmVerTable>
  <ListMgt::LmVersionTable>
    <pActive>…</pActive>                どのバージョンが有効か
    <Locals><Element>
      <ListMgt::LmVersion>
        <Name>Version 1</Name>          カラーバージョン名
        <HasCorrection>true</HasCorrection>
        <Body>81 28b52ffd …</Body>      **グレード本体**
        <LinkedGroup>…</LinkedGroup>    カラーグループ

`Body` の容器は `[0] 0x81` + zstd（28 b5 2f fd がマジックナンバー）。

§9-2 の容器仕様「0x81 = zstd」そのもの。解凍すると protobuf。

読める（実測 Part1_Master、104 クリップすべて解凍成功）:

まだ分かっていないこと: protobuf のフィールド ID と数値の対応。

ノード名と FX の種類は取れるが、各パラメータの値がどれかは未解読。

色を再現するにはそこまで解く必要がある。

読む道具: tools/resolve-adapter/drt_grades.py

ZIP。中身は project.xml / MediaPool/Master/MpFolder.xml / SeqContainer/<uuid>.xml。

ルートの並びの辿り方:

MpFolder.xml の Sm2MpTimelineClip → Sm2Sequence の DbId → その id を <Sequence> に持つ SeqContainer。

<ListMgt::LmVersionTable> は XML として不正。パース前に "::" → "__CC__" に置換する。

[0:4] uint32 BE = 2      バージョン
[4:8] uint32 BE          以降の長さ
[8]   0x80 非圧縮 / 0x81 zstd
[9:]  protobuf

field1 = フィルタ / field1 varint = 種別 / field9 = パラメータ（空でも 4a 00 で残る）

/ field1 varint = ID / field3→field1→field2(tag 0x11) = IEEE754 double LE

バイト位置は固定ではない。省略されたパラメータがあると後ろが全部ずれるので、

ID を見ながら protobuf を歩く。

In / Duration が 22329|0000f753e3a5d33f（フレーム | サブフレームの double）になる。

int() が落ちるので split("|")[0] を挟む。

EffectFiltersBA の中に uint32 長さ(=2n+4) + UTF-16LE 本体。

読むときの罠:

• 偶数・奇数の両方の境目から読む（開始位置が素材ごとに動く）
• ASCII 2 バイトが漢字に化ける（Regular → 刀攀最甀氀愀爀）。

下位バイトが 0x00 の文字が 7 割を超える連続は捨てる

tools/resolve-adapter/drt_decode.py は、DRTを編集せずに次の層を一つのJSONへ抽出する。

• ZIPエントリ、XMLタグ、MediaPool、タイムライン名とSeqContainerの対応
• Video / Audio / Subtitle track、clipの Start / Duration / In / Out の原値
• FieldsBlob と SequenceSetup（1080x1920 / 24fps / input・output mismatch）
• EffectFiltersBA の kind / slot / parameter ID / 値
• grade Body のzstd展開とResolveFX文字列
• trackごとのrecord-frame範囲、空白フレーム、最大空白

52本の実運用DRTを並列スキャンした結果、構文エラーは0件だった。これは「全バイト列の意味が確定した」という意味ではない。次の分類を守る。

再現コマンド：

python tools/resolve-adapter/drt_decode.py input.drt `
  --timeline-name Part1_Shorts --json output.json
python tools/resolve-adapter/drt_batch_summary.py D:/path/to/export `
  --workers 8 --json dev/drt/batch.summary.json
python tools/resolve-adapter/resolve_schema_scan.py `
  --json dev/drt/resolve-embedded-schema.json

複数タイムラインを含むDRTは、検証時も必ず名前を指定する。Outは現在確認したDRTには保存されないため、終了位置は Start + Duration として扱い、素材側の終端は In と MediaTimemapBA を別層で照合する。

Resolve 21.0.3.0007 の Resolve.exe には内部protobuf descriptorが28ファイル分埋め込まれている。Sm2Filter.proto の EffectParam（dbid、value、defaultvalue、range、keyframesba）と、Sm2TiItem.proto の RetimeKeyframeProto（x、y、bezier）、依存する BtCommon / OfxParams を抽出できる。ただしこれは同一バイナリへの静的照合であり、Blackmagic公式のDRT仕様公開ではないため、未知IDのUI名は引き続き推測しない。

• DRT未知IDは known / candidate / unknown で管理する。未公開numeric kind／dbidへUI名を推測で割り当てない。
• 字幕は合成SRTを一括投入し、生成DRTを再読込して全cueのrecord frame、duration、ショート間隔を照合する。
• マルチカムの重複区間は先勝ちで統合し、source FPSからtimeline FPSへのframe変換をAppend前に行う。
• A1には元Resolve Audio TimelineItemsを保持してミュートし、Dialogueの編集再生正本はA2のhash検証済み統合WAVとする。未解決区間があれば生成を停止し、元音声のDRT／DRP／tl_map、TimelineItems、統合WAVのSHA-256をレポートへ残す。
• HDRは推測設定を使わない。公式仕様、テストチャート、HDR Light Level Report、Resolve設定のread-back、close/reopen後の再確認を満たした候補だけを採用する。

タイトル段のtrack番号はグローバル規則ではなく、プロジェクト／Partプロファイルの trackLayout が正典である。Part1は templates/shorts/katto/Part1.json の logo=V8、titleLower=V9、titleUpper=V10 を使用する。タイトルmanifestは内容を供給し、track番号の正典ではない。

ギャラリーが汚れる（浅尾の指示 2026-08-07）。

ギャラリーを経由せず PNG を書く。画面も乗っ取らない。

tl.SetCurrentTimecode("00:02:32:15")
pr.ExportCurrentFrameAsStill(str(path))

2026-08-07 の遠回りは全部「別の瞬間・別のクリップを目で見比べていた」ことが原因。

• 同じ素材フレームで比べる（タイムラインの位置ではなく、素材の何フレーム目か）
• 映像帯の高さを数値で測る（黄色でも黒でもない行の連続区間を数える）
• 1 変数だけ動かして 2 枚撮り、差分を計算する

この節だけを見て、他人がゼロから通せること。 2026-08-12 の監査で、必要な入力が

4 つ書かれていないことが分かったので全面的に書き直した。段 0〜3 は同日に実際に走らせて

確かめた（Part11 / P1）。Resolve へ繋ぐ段 4〜6 はこのセッションでは走らせていない。

下の「未確認」を必ず読む。

git ls-files '*.drt' は 0 件。教師も素材も全部リポジトリの外にあり、

clone しただけでは 1 本も組めない。 所在は下の表（2026-08-12 に実在・SHA-256・

中のタイムライン名を実測。SHA は

[manual/knowledge/resolve/15_part11_p1_session_handoff_20260811.md](../knowledge/resolve/15_part11_p1_session_handoff_20260811.md)

の表と一致した）。

字幕は 42 本（P1〜P42）が同じ階層にある。**source と字幕はタイムラインが 2 本ずつ入って

いるので、名前を渡さないと止まる**（止まるのが正しい。推測で選ばない）。

**DRT だけではない。dev/knowledge/* は .gitignore で丸ごと除外されている**（例外的に

7 ファイルだけ追跡されている）。段 0 の --fps-evidence と段 1 の --words は

その中にあり、clone した人の手元には無い。

秒 → フレームの fps は §2-5 が正本。 ここに数値を書き写さない。

--angle-fps の既定はそこに合わせてあるので、普通は渡さない。

編集案（.plan-drafts/PartN.compact.json）は extracts しか持たず、

TimelineIR（dev/short-plan/PartN.json）は ranges しか持たない。**どちらもそのままでは

DRT を組めない。**

python tools/resolve-adapter/materialize_plan_cut_frames.py \
  --plan .plan-drafts/Part11.compact.json \
  --master .transcripts/Part11.master.json \
  --fps-evidence dev/knowledge/part11-media-fps-evidence-20260809.json \
  --timeline-fps 24000/1001 \
  --output dev/short-plan/Part11.cutframes.json

• --master は .plan-drafts/*.compact.json の sourceSha256 と一致するファイル。

違えば「plan sourceSha256 does not match」で止まる（Part11 は .transcripts/Part11.master.json）

• --fps-evidence の全 video ストリームのレートが --timeline-fps と一致しないと止まる
• --output は既にあると上書きせずに止まる

実測（2026-08-12、Part11）: 42 ショート / 476 範囲、最小テキスト類似 0.474（1 件が 0.5 未満）。

**出力の frameRatePolicy.status と cutMaterialization.productionPromotion は candidate /

blocked のまま出る。**「通った」と「本番に上げてよい」は別。

P1 の 12 範囲 [426,489] … [21703,21760]（計 1105f）は、出荷済み候補 P1 v3 の cut ranges と

完全に一致した。この経路がその DRT を作った経路である。

決着（浅尾確定 2026-08-19）: 系統 A（字幕 TC 起点）が正本。B は監査器へ降格。 詳細は [docs/DRT_SRT_CYCLE.md](../../docs/DRT_SRT_CYCLE.md) §3。 A がずれた原因は A の入力にあり（読んでいた SRT が最終 DRT 由来ではなかった）、A の設計ではない。 最終 DRT を読み戻して record 時刻を写した SRT を A の入力にする。 B は捨てず、A の出力を語境界で検算する相手として残す。以下は決着前の記録。 （旧・未決）`cutFrames` の作り手が 2 つある。 tools/resolve-adapter/plan_short_cuts.py も cutFrames を書く。あちらは 字幕 TC 起点で、プロジェクト CLAUDE.md と manual/L2_sns/15_shorts_composition_workflow.md §4 の「字幕 TC が上流」に一致する。いっぽう materialize_plan_cut_frames.py は extracts をマスターの語境界へスナップし、TimelineIR の `ranges` を権威として受け付けないと 明記している。同じ Part11 P1 で結果が違う（materialize 12 範囲 / 1105f、plan_short_cuts 7 範囲 / 1387f）。どちらを正本にするかは浅尾の判断待ち。 上のコマンドは、出荷済み P1 v3 と一致したほうを書いている。 なお plan_short_cuts.py は編集構成が未承認だと止まる（--allow-provisional で候補生成）。

python tools/resolve-adapter/export_angle_plan.py \
  --words dev/knowledge/part11-condensed-23976-20260809-v3.json \
  --out dev/angle/Part11.angle.json \
  --min-seconds 20 \
  --speaker-name speaker_0=中央 --speaker-name speaker_1=右

• --words はその Part の本編先頭を 0 秒とする軸の、話者付き語 JSON。

生カメラの軸のものを入れない（編集で抜けた尺が階段状に効く。正本

manual/L1_subtitle/13_speaker_attribution.md）

• --min-seconds は合計発話がこれ未満の話者を列にしない。落とした話者は dropped に残る
• 話者名は推測で埋めない。 渡さなければ ID がそのまま列名になる

実測（2026-08-12、Part11）: 語 1572 → turn 171、列 3（speaker_0 1583.9s / speaker_1 798.6s /

overview）。speaker_2 は 10.4s で落ちた。列 1 が V2 に乗る。

1 本落ちても残りは続く。 落ちたものは最後に必ず出る。

python tools/resolve-adapter/build_all_shorts.py \
  --plan-json dev/short-plan/Part11.cutframes.json \
  --out-dir build/part11-shorts-20260812/ \
  --name-template "Part11_{short}_20260812" \
  --source-drt "D:/zFilms Dropbox/z Films/Directors'Katto/drp/export-20260807/reference/Part11.drt" \
  --source-timeline Part11 \
  --master-drt "D:/zFilms Dropbox/z Films/Directors'Katto/drp/auto-part11-20260810/master-layout/Katto_Master_Layout_Production.drt" \
  --layout-drt "D:/zFilms Dropbox/z Films/Directors'Katto/drp/export-20260807/reference/Part11_Shorts_old.drt" \
  --part-offset-frames 1145 \
  --subtitle-drt "D:/zFilms Dropbox/z Films/Directors'Katto/drp/auto-part11-20260810/production42-v1/raw-drt/Part11_Production42_{short}.drt" \
  --subtitle-timeline "Part11_Production42_{short}" \
  --angle-plan dev/angle/Part11.angle.json

{short} は P1…P42 に置き換わる（--name-template / --subtitle-drt /

--subtitle-timeline / --layout-* / --angle-* などで使える）。

`--angle-fps` は渡さない（既定が §2-5 の実測に合っている）。

build_all_shorts.py は --allow-unframed を持たないので、**--layout-drt を忘れると

42 本すべてが失敗として出る。**

1 本だけ組むなら build_short_drt.py を直接呼ぶ。--timeline-name と --output が要る。

python tools/resolve-adapter/build_short_drt.py \
  --source-drt ".../Part11.drt" --source-timeline Part11 \
  --master-drt ".../Katto_Master_Layout_Production.drt" \
  --layout-drt ".../Part11_Shorts_old.drt" \
  --plan-json dev/short-plan/Part11.cutframes.json --short-id P1 \
  --part-offset-frames 1145 \
  --angle-plan dev/angle/Part11.angle.json \
  --subtitle-drt ".../Part11_Production42_P1.drt" \
  --subtitle-timeline "Part11_Production42_P1" \
  --timeline-name "Part11_P1_20260812" \
  --output build/part11-shorts-20260812/Part11_P1_20260812.drt

実測（2026-08-12、P1、段 0 の 12 範囲ではなく plan_short_cuts 側の 7 範囲で確認）:

timeline-origin 86400（master の V1 から導出）/ source-body-origin 87545（ソース開始

86400 + 1145）/ 出力 1387f。Angle は V2 speaker_0 8 片 1211f、V3 speaker_1 2 片 139f、

V4 overview 3 片 37f で被覆 1387/1387f。字幕は入力 24 → 出力 24。

python tools/resolve-adapter/verify_resolution_contract.py \
  build/part11-shorts-20260812/Part11_P1_20260812.drt

DRT はタイムライン自身の解像度を持たない（ImgWidth/ImgHeight は -1 = 継承）。

ここで確かめられるのはメディアプール側の縦横の分離までで、

「P1 が 1080x1920 か」は実機でしか分からない。

import_drts.py はプロジェクトを切り替えない（正本 §11-4）。開いているものが

--project と違えば何もせず止まる。Resolve 側で先に開くこと。

python tools/resolve-adapter/import_drts.py \
  --project "Part11_Part12MasterLayout_20260810_v2" \
  --dir build/part11-shorts-20260812/ \
  --out dev/knowledge/part11-import-20260812.json

• タイムライン名はファイル名で決まる（Resolve の仕様。--name-template がそのまま名前になる）
• 同名が既にあれば飛ばす。--replace は無い（黙って上書きすると、どちらが新しいか分からなくなる）
• 既定で SaveProject する（--no-save で止められる）

ImportTimelineFromFile は取り込んだタイムラインの解像度で Project Settings を上書きする

（§2-4）。先に当てると次の 1 本で黙って戻される。

python tools/resolve-adapter/set_timeline_format.py \
  --expect-project "Part11_Part12MasterLayout_20260810_v2" \
  --suffix _20260812 --width 1080 --height 1920 --go

既定は DRY RUN で、--go を付けたときだけ実際に書く。useCustomSettings を先に立てないと

黙って戻る（§2-1）。Project Settings 側（1920x1080 に戻す）を書く道具はこの階層に無い。

python tools/resolve-adapter/export_drp.py \
  --project "Part11_Part12MasterLayout_20260810_v2" \
  --out dev/exports/Part11_20260812.drp

ExportProject は Bool しか返さないので、このツールは書き出した .drp を zip として

開き直してエントリ数と bin 数を数える。保存はしない。未保存の変更は DRP に入らないので、

保存は呼び出し側の仕事（段 4 が既定で保存している）。

字幕が無いショートは字幕なしで組む。 映像・音声・トポロジは字幕に依存しない。

導けなければ止める。既定値で埋めない。 実測: Part11.drt には Part11 と

Part11_Digest の 2 本があり、名前を渡さないと正しく止まる。

導出版と旧・決め打ち版で counts / cutRanges / 原点 / Angle / 字幕がすべて一致する

（86400 と 87545 が導出でそのまま出る）ことを確認済み。

• 段 4〜6 を走らせていない。 Resolve へ繋いでいないので、上の 3 つのコマンドは

スクリプトの実装（引数・fail-close の条件）からしか書いていない。実機での再現は未確認。

• `--part-offset-frames` が 1145 か 1144 か決まっていない。 段 0 の出力は 1144

（24 → 23.976 の直し）、書き起こしと編集案は 1145。出荷済み P1 v3 は 1145 で組まれている。

• `cutFrames` の正本が 2 つある（段 0 の注記）。
• `--power-word-json` を作る経路が無い。 受け側が読む形の JSON を出す道具が

リポジトリに見つからなかった。

• 画で確かめていない。 --layout-drt の有無で絵がどう変わるかは、今回

レンダリングしていない。§10-3 のとおり px を数えるまでは「framing が当たった」と言わない。

• 任意の`.drt` / `.drp` / `.prproj`を推測生成しない。ただし本番Resolve経路では、教師DRTをコードで読み、既知の構造と限定置換だけから新規DRTを生成する。DRPはResolve自身のexport／readbackを正本とし、手書き生成や元ファイル上書きはしない。
• `GrabStill()` を使わない
• 素材を再エンコードして API の制限を回避しない
• スクリプトからプロジェクトを切り替えない
• 推測で数値を埋めない。測っていないものは「未実測」と出して止める

Resolve.Quit() も、ウィンドウへの通常の閉じる要求も無視されることがある。

ダイアログも出ていない。API からの終了手段が無い状態になる。

pm.ExportProject(プロジェクト名, str(出力先))   # .drp

実測: 48.8MB / 29 秒。これをせずに強制終了すると、直前に作ったタイムラインが消える。

実際に 1 本失った（SaveProject() が False を返していたのが前兆だった）。

起動直後はプロジェクトマネージャ画面で GetCurrentPage() が None。

pm.LoadProject(名前) で開いてから作業する。

23.976fpsは、画面のタイムライン設定だけを23.976にする話ではない。入力の実測、字幕TC、cutFrames、DRTの外側タイムライン、SequenceSetup、Resolveの保存後読戻しを同じ値で通す。

• 生MP4／音声の実測証拠から 24000/1001 を確定する。未測定の素材へ一律に適用しない。
• 字幕TCを上流にして、半開区間 [startFrame, endFrame) の cutFrames を作る。秒を丸めた24fpsのplanを後から23.976へ読み替えない。
• build_short_drt.py は測定済みの23.976値で外側のショートタイムラインを生成する。現在の24.0生成物は旧証跡であり、23.976版の完成品とはみなさない。
• 既存DRTを補正する場合は、tools/resolve-adapter/set_drt_frame_rate.py で対象タイムラインの <FrameRate> と FieldsBlob 内の SequenceSetup を同時に更新する。24000/1001 のレートコードは23である。片方だけを変更しない。
• 新規Resolveプロジェクトへ読み込み、保存後にclose/reopenする。GetSetting('timelineFrameRate') と、プロジェクト／タイムラインの設定が23.976へ戻っていることをAPIで読み戻す。読み戻しが無い間は完成判定にしない。

render probeでは、1秒のMark In/Out計算に使うフレーム数は整数24としてよいが、証跡のframeRateは23.976の実値を保持する。23.976を24へ丸めた報告は、FPSのreadback証拠として使わない。

実行経路の最小例は次のとおり。--in-place は元DRTを上書きするため、出力先とハッシュを先に固定する。

python tools/resolve-adapter/set_drt_frame_rate.py `
  --input C:\tmp\shorts-23.976\Part1_P3.drt `
  --output C:\tmp\shorts-23.976\Part1_P3_23976.drt `
  --fps 24000/1001

この手順はSequenceSetupを書き換える道具であり、字幕TC、連続素材、Angle、音声の正しさを自動的に証明するものではない。各証跡とResolve readbackをそろえて初めて昇格する。

この手順の正本は、Master SRT → 構成案 → カット／話者／反応 → NLE読戻しである。固定FPSやAPI応答だけで完成とは判定しない。

• Master SRTの時間を字幕とカットの正本にする。
• 対象素材のFPSはffprobeまたはResolveで実測し、$sourceFpsへ入れる。24fpsや23.976fpsを全素材へ固定適用しない。
• 構成案は dev/short-plan/Part1.json、候補の正本は .plan-drafts/<Part>.compact.json を使う。
• 短尺の生成基準は、最新の意味選定JSON（.plan-drafts/<Part>.semantic-selection.json）の keep にある source range との一致だけとする。Score、尺、タイトル、構成案の抽出は source range を追加・削除・補間する根拠にしない。

$sourceFps = <ffprobe または Resolve の実測値>

npx tsx scripts/build-shorts-from-master.mts `
  --part Part1 `
  --master .transcripts/Part1.master.json `
  --plan dev/short-plan/Part1.json `
  --selection .plan-drafts/Part1.semantic-selection.json `
  --out dev/shorts-from-master/<run-id> `
  --timeline-fps $sourceFps `
  --source-fps $sourceFps `
  --audio-manifest dev/audio/Part1_integrated_profile_v1.report.json `
  --selection-boundaries hard `
  --allow-provisional

--allow-provisionalは候補生成だけを許可する。productionReady=false、話者・反応・Angle・音声の未解決が残る状態でResolveへ本番適用しない。

Videoは BG / Angle / Slide / Overlay、Audioは Dialogue / BGM / SE を基幹列とする。必要列数はPartの素材構成から決め、空列を無目的に増やさない。

• Angleはマルチカムの切替情報、話者フォーカス、位置・ズームを別々に記録する。
• 同じカメラが分割ファイルになっている場合はメタデータと時間で統合候補を作る。
• 話者、reaction、聞き手カット、笑い、字幕表示尺は構成案のカット単位へ付ける。
• SlideがないPartではSlide列を作らず、必要な挿入素材だけをOverlayまたはSlideとして登録する。

生成DRTは候補であり、次の順番で確認する。

• --selection に渡した最新意味選定JSONの keep と、生成された各短尺の source range が完全一致していることを確認する。欠落、追加、補間、境界の相違があれば停止する。
• DRTをResolveへ読み込む。
• Native subtitle、Text+、Fusion、MediaRef、Angle、音声列を構造として確認する。
• close/reopen後に同じ内容を読戻す。
• Master SRTの時間、実測FPS、字幕表示尺、カット数、話者・反応フラグを比較する。
• 音声マニフェストがpass、productionReady=true、読戻し証跡が揃ったものだけを本番候補に昇格する。

APIのAppend／Buildだけで構造保持を証明したことにはしない。Premiere、CapCutも同じTimeline IRを入力にし、各NLEの読戻し検証が終わるまで互換性を「完了」と表示しない。

• DRTはZIP/XMLを含むResolveのタイムライン交換ファイルである。
• timelineとSeqContainerの対応、Video / Audio / Subtitle track、clipのStart / Duration / In / Outを読み取れる。
• SequenceSetup、FieldsBlob、EffectFiltersBA、grade Body、CompositionBA、MediaTimemapBAを解析対象にできる。
• CompositionBAは4-byte lengthとzlib展開でFusion本文を抽出できる。
• MediaTimemapBAにはv1辞書構造とv2の9/41-byte layout、float64 offset、reserved bytesがある。
• Resolve 21.0.3.0007から埋込みprotobuf descriptorを抽出し、field pathを記録できる。

• kind=4 / param=47 → RotationAngle
• kind=6 / param=54/55 → CropLeft / CropRight
• kind=124 / param=97/98 → AudioFadeIn / AudioFadeOutFrames

これらは単一操作のResolve差分が不足しているためcandidateのままにする。

• Resolveが公開していないnumeric kind / dbidの意味名
• MediaTimemapのYMin / YMax / XMaxと一部slotのUI上の意味
• grade Bodyのnumeric leafと実際のGUI項目の完全な対応
• DRTだけに存在するIDを、公式APIの項目名へ推測で割り当てること
• Part1旧DRTのmulticam selector値を、Angle 1/2や人物名へ直接割り当てること

幾何は Resolve の API から直に読める。DRT を復号する必要は無い。

• `TimelineItem.GetProperty('ZoomX' | 'ZoomY' | 'Pan' | 'Tilt' | 'RotationAngle' |

'CropLeft' | 'CropRight' | 'CropTop' | 'CropBottom' | 'Opacity' | 'AnchorPointX' | 'AnchorPointY')`

• Part1 の composite 30 本で実測した値（トラックごとに固定）:

3 本とも同じ素材（Part1 - Angle 1 / Angle 2）を横位置だけ変えて切っている。

読めないもの（この日の実測）

• UI 系（OpenPage / SetCurrentRenderFormatAndCodec / AddRenderJob）は

背景から起動した Resolve では全部 `None` を返す。描き出しには対話セッションが要る

• GetProperty も時間が経つと None を返し始めた。読めた値と読めなかったことを分けて数える

`Pan` の換算式は未確定。符号がどちらへ動かすかを実機の描き出しと 1 度突き合わせるまで、

クロップを別の道具（ffmpeg 等）で再現してはいけない（正本「正規化された値は基準を推測しない」）。

templates/shorts/katto/Part1.json は角度ごとに幾何を並べているが、

実機は人ごとのトラックで持っている。そのため片方から他方を引けない。

宣言 angle 1 → trackIndex 2（幾何を 2 つ持つ: pan −129 と pan 274）

angle 2 → trackIndex 3（pan 64 / cropTop 846）

実機 V3 pan +274 / V4 pan −286 / V5 pan −129

`pan −286`（Nabe）は宣言に無い。trackIndex も一致しない。

scripts/audit-template-vs-resolve.py がこれを全数で検算する（Resolve の実機が要る）。

drt_decode.pyは解析値と意味付けを分離する。意味名が未確定の値はunknownとして保存し、検証器がunknownを正解として通さない。新しい意味名を追加するには、公式仕様または1変数だけを変えたResolve実機差分とread-backを残す。

参照:

• scripts/audit-template-vs-resolve.py（宣言と実機の全数突き合わせ）
• tools/resolve-adapter/drt_decode.py
• tools/resolve-adapter/drt_control_diff.py
• docs/archive/DRT_CONTROL_DIFF_REPORT.md（2026-08-10 時点の調査報告。規則ではない）
• manual/L4_tools/davinci_resolve_api.md §9

• Part1の候補は30本のショートで構成される。
• ショート間の空白は時間値を正本とし、対象timelineのFPSでframe化して検証する。Kattoの現行素材候補は23.976023976fpsであり、旧24fps DRTはhistorical candidateとして扱う。360Fは24fps固定のグローバル値ではない。
• 字幕は合成SRTの一括投入が必要で、cue単位のAppendは記録位置を壊す可能性がある。
• WaveformFocus候補は字幕810/810、start/duration差0F、verify_short.py 17 passed / 0 failedだった。
• マルチカムの重複は同一target区間の先勝ちで統合する。
• 素材FPSはAppend前にtimeline FPSへ変換する。
• 話者ASRラベルとカメラAngleは別情報であり、片方からもう片方を推測しない。

• 波形照合による話者フォーカスは、known区間だけを自動適用する。
• candidate / unknown区間はwideへ戻す。
• 強い波形不一致だけで話者や笑いを確定しない。

• timeline名、FPS、resolution、track数
• short数、開始位置、360F gap
• subtitle count、start、duration
• source frame / record frame
• スクリーンショットによる画の確認

参照:

• tools/resolve-adapter/verify_short.py
• tools/resolve-adapter/verify_subtitle_timing.py
• dev/resolve-live-20260808/*subtitle-verify.json
• [docs/SOT.md](../../../docs/SOT.md) から辿れるTimelineIR・Project profile

素材FPSはProject Masterのsource-derivedを既定とし、Media Registryで実測したCFRの分数をTimelineIR・編集プリセットへ渡す。実測前の24や23.976を推測で固定しない。例外的にexplicitを選ぶ場合は、DRP/メディア証跡と一致するFPSを必須入力にする。

The current production contract is:

• A1 Source · Dialogue (muted): original Resolve Audio TimelineItems retained for Fairlight and source-range audit.
• A2 Dialogue · Master: one hash-verified integrated WAV generated from the raw microphone sources.
• A3 BGM: original music items with source and record ranges.
• A4 SE: sound-effect and theme items with source and record ranges.

A short cuts A2–A4. It does not regenerate or replace the original source

audio. A1 remains available but muted so the raw dialogue is not double-played.

Audio generation and Resolve promotion stop when any item is missing:

• authoritative part-level raw microphone map;
• source file existence and SHA-256;
• synchronization and speaker mapping with unresolvedCount=0;
• completed integrated-audio report;
• integrated WAV SHA-256;
• A2 DRT readback pointing to that exact WAV;
• DRT / DRP / tl_map hashes recorded in the run manifest.

The read-only gate is

[audit_drt_audio_authority.py](../../../tools/resolve-adapter/audit_drt_audio_authority.py).

The overlay probe cannot use --production unless this gate passes.

• Part1 has an authoritative three-microphone map in

dev/audio/tl_map.json. Its completed report is

dev/audio/Part1_integrated_profile_v1.report.json, and the output is

dev/audio/Part1_integrated_profile_v1.wav (-14.0 LUFS / LRA 2.1 / TP -1.0).

This is an audio-derivative verification only; it does not certify the full

visual timeline.

• Part11 has teacher/reference audio topology, but no verified raw-mic map and

no completed integrated-audio manifest. Part11 integrated audio is therefore

unverified/unknown; generation must stop instead of reusing OP/camera

fragments or guessing the microphone mapping.

EQ, gate, leveling, compression, limiting, and loudness normalization are

derived processing. Their profile, measured I/LRA/TP, input hashes, output hash,

and comparison result are stored separately. -14 LUFS is a delivery target,

not proof that the source dynamics were preserved. A/B listening and numerical

comparison are both required before choosing a less-compressed profile.

Relevant implementation:

• tools/audio/integrated_audio.py
• tools/audio/integrated_master_audio.py
• templates/audio/katto-v1.json
• templates/audio/katto-v2-open.json
• tools/resolve-adapter/apply_master_audio_lane.py

Historical claims that A1 original audio alone is the current editable master

are retained in docs/AUDIO_SOURCE_PRESERVE.md as historical evidence. They do

not override the A1-muted / A2-integrated contract above.

• 1080×1920の縦型タイムラインを基準にする。
• 素材→タイムラインのスケーリングと、タイムライン→出力のスケーリングは別設定である。
• 正典の入力スケーリングはcenterCrop相当で、GUIの実測フレームを基準に判定する。
• Part1のタイトル段はtrackLayoutを正典とし、V8/V9/V10を確認する。
• Fusionのline、scrim、Text+は.compとして保存し、DRTのComposition本文と画で確認する。
• dev/fusion/titlesにはPart1〜Part30のタイトル候補がある。

• .master.jsonとraw audio波形を照合した話者フォーカス。
• waveform overrideは候補として保存し、global speaker mapを上書きしない。
• 明示的な笑いマーカーがない場合、音量や無音だけからreaction cutを作らない。
• Part1旧DRTのV2 45区間は、話者フォーカス列の素材としては使えるが、V2のopaque selectorをAngle 1と断定する根拠にはしない。
• V2〜V5のPart1プロファイルはframingColumn（wide/Fujii/Nabe/Asao）であり、multicamのcameraAngleSelectionとは別の証拠として扱う。

• cameraAngleSelection: Resolve multicamのAlt+1/Alt+2に相当するselector。DRTのnumeric値がopaqueならunknown。
• framingColumn: 話者・全体・freeのフォーカス、crop、position、zoomを持つ出力列。
• timelineRole: BG / Angle / Slide / OverlayというNLE共通の意味列。番号はPartごとに異なる。

この3層を一つのV2/V3番号へ圧縮しない。自動でspeaker→cameraを昇格するには、元multicam定義、波形、代表フレームの三系統を揃える。

• 中央フレームだけでなく、Asao / Fujii / Nabeの代表フォーカスフレームを保存する。
• 背景、映像帯、クロップ、字幕、Fusion line、logo、Text+ titleを同一フレームで確認する。
• 数値の読戻しだけでなく、独立したPNGを比較する。

参照:

• tools/resolve-adapter/apply_fusion.py
• tools/resolve-adapter/learn_angle_geometry.py
• tools/resolve-adapter/learn_multicam_angles.py
• dev/frames/waveform-focus-final/
• templates/shorts/katto/fusion/

• HDRの正本はタイムライン単体ではなくResolveプロジェクト設定である。
• Sony S-Log3 / S-Gamut3 / 10-bit素材を前提に調査している。
• HLG候補ではRec.2020、Rec.2100 HLG、1000 nit作業輝度、203 cd/m² reference whiteを候補値として記録している。
• ITU-R BT.2100、BT.2408、BT.2166、Blackmagic公式資料を根拠として整理している。
• verify_hdr_evidence.pyは公式資料、チャートhash、実レンダーmetadata、MaxCLL / MaxFALL、HDR Light Level Report、Resolve close/reopen read-backを要求する。

• Katto-Codex-HDR-Candidate.drp
• Katto_Codex_HDR_HLG_Candidate_20260808_v4.drp
• Part1_Shorts_Final_Integrated_HLG_Candidate_20260808_v4.drt

これらは旧候補であり、存在するだけでは最終HDRとは呼ばない。

• HDR Light Level Reportの実機PDFとhash
• 実HDRレンダーのRec.2020 / HLG / 10-bit metadataの完全なread-back
• Resolve close/reopen後のプロジェクト設定の完全一致
• PQを採用する場合のマスタリングディスプレイ、MaxCLL、MaxFALL

上記が揃うまで、HDRはcandidateまたはblockedとして扱う。推測値でDRP/DRTを完成版に昇格させない。

参照:

• docs/HDR_PROJECT_CANDIDATE.md
• docs/HDR_RESOLVE_PROCEDURE.md
• tools/hdr/verify_hdr_evidence.py
• resolve_hdr_project_apply.py

Research date: 2026-08-09 JST

This note separates vendor requirements from project policy. A candidate is not promoted to verified merely because a setting exists in a DRP/DRT.

The official Resolve workflow is based on color management with explicit input, timeline, and output color spaces. The production candidate for S-Log3 / S-Gamut3 / 10-bit material is:

camera input -> RCM / DaVinci Wide Gamut Intermediate -> HDR output (PQ or HLG) -> tagged render -> report and playback evidence

• HDR10 uses PQ / SMPTE ST.2084 with an absolute luminance target.
• HLG uses Rec.2100 HLG and does not rely on HDR10 static metadata in the same way.
• The project must record input color space, timeline color space, output color space, transfer function, mastering luminance, bit depth, codec, and file tags.
• HDR scopes must be inspected in nits. An HDR Light Level Report is a PDF QC artifact; it is not itself the file's HDR metadata.
• A calibrated external HDR display through a supported video I/O device is the color-critical check. A PC preview is not sufficient evidence.
• Test charts and HDR Light Level Reports are project QC requirements here, not claims that Blackmagic makes every one of them universally mandatory for every delivery.

Sources: [Resolve 21 Reference Manual](https://documents.blackmagicdesign.com/UserManuals/DaVinci_Resolve_21_Reference_Manual.pdf), [Resolve 21 New Features Guide](https://documents.blackmagicdesign.com/SupportNotes/DaVinci_Resolve_21_New_Features_Guide.pdf), [DaVinci Wide Gamut Intermediate](https://documents.blackmagicdesign.com/InformationNotes/DaVinci_Resolve_17_Wide_Gamut_Intermediate.pdf).

SOURCE_RAW is immutable. EQ, microphone gate, compression, limiter, loudness normalization, and the integrated mix are derived artifacts with their own hashes. The derived file is never used as a replacement for the original timeline source.

• Measure with an ITU-R BS.1770-compliant meter and keep integrated, momentary, short-term, LRA, sample peak, and true peak separate.
• EBU R 128 gives -23 LUFS and -1 dBTP as broadcast-oriented references. It says LRA is not recommended for programmes shorter than one minute because the sample count is too small.
• -14 LUFS / -1 dBTP is a selectable delivery profile, not a universal YouTube rule. YouTube's upload guidance does not define a single LUFS target.
• Gate for microphone bleed and the loudness-meter relative/absolute gate are different mechanisms and must remain separate in the profile and report.
• Re-measure after AAC/Opus export when the delivery path uses lossy encoding.

Sources: [ITU-R BS.1770-5](https://www.itu.int/rec/R-REC-BS.1770-5-202311-I/en), [EBU R 128-2023](https://tech.ebu.ch/files/live/sites/tech/files/shared/r/r128.pdf), [YouTube recommended upload encoding settings](https://support.google.com/youtube/answer/1722171).

OTIO is the editorial cut interchange layer: clips, timing, tracks, transitions, markers, metadata, and external media references. It does not embed the media and it is not a lossless representation of Resolve Fusion/Text+, Premiere MOGRTs, plug-ins, or application-specific easing.

The project therefore keeps three layers:

• TimelineIR / OTIO for editorial decisions.
• Caption IR plus SRT for text and timing; SRT import is followed by Resolve readback verification.
• Motion IR for text styling, keyframes, and easing, converted by an NLE-specific adapter or baked to alpha video when fidelity cannot be guaranteed.

DRP/DRT are handled only through Resolve's own import/export APIs. Their binary internals are not a write target.

Sources: [OpenTimelineIO documentation](https://opentimelineio.readthedocs.io/en/latest/index.html), [Adobe export to Final Cut Pro XML](https://helpx.adobe.com/premiere/desktop/render-and-export/export-files/export-a-project-as-a-final-cut-pro-xml-file.html), [CapCut subtitle import](https://www.capcut.com/help/how-to-import-subtitles).

Upload, processing, publish, and public readback are separate states. The queue stores a platform-neutral pathname and immutable source/fix hashes; it creates a short-lived signed URL only when a platform requires one.

• YouTube supports resumable upload and status.publishAt; readback must check processing status and privacy/publication state.
• X, Threads, Instagram, and TikTok have different asynchronous media flows; do not model them as a single synchronous publish() call.
• For platforms without an official API schedule field, the scheduler calls the publish API at the due time and records the provider receipt.
• note and Spotify remain UI/RSS boundaries until an approved official write API is available.

Sources: [YouTube videos.insert](https://developers.google.com/youtube/v3/docs/videos/insert), [YouTube video processing status](https://developers.google.com/youtube/v3/guides/implementation/videos), [X Create Post](https://docs.x.com/x-api/posts/create-post), [Threads publishing](https://developers.facebook.com/docs/threads/reference/publishing), [TikTok Direct Post](https://developers.tiktok.com/doc/content-posting-api-reference-direct-post).

• known / candidate / unknown is mandatory for unresolved Resolve IDs and NLE capabilities.
• No audio output is accepted with an unresolved source interval, and the run records DRT/DRP/tl_map/profile hashes.
• HDR is blocked until settings, tagged render, chart evidence, HDR Light Level Report, and close/reopen/readback evidence are present.
• A successful compile or API response is not a completed production run; the final gate requires structure readback, render evidence, and the appropriate platform receipt.

Resolveの設定値を「触れるもの」と「意味がまだ確定していないもの」に分け、アプリから編集要求を作り、Resolve実機で適用して、API読戻し・DRT/DRP・スクリーンショットの三方向で検証する。

教師データは、成功実績のある次のDRTを基準にする。

• D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part10_Short_old.drt
• D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part11_Shorts_old.drt
• D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part12_Shorts 2_old.drt

同じファイル名のDownloads版はバイト同一ではないため、教師データとは別の候補として扱う。

両軸は同じ意味に潰さない。公式キーがknownでもDRT raw IDがcandidateなら、公式APIで適用し、raw IDはcandidateのまま追加証跡を要求する。unknownはアプリから編集できない。

機械可読な正本は [lib/nle/resolve/parameter-registry.ts](../../../lib/nle/resolve/parameter-registry.ts) である。主なknown項目は次の通り。

• Project/Timeline: timelineFrameRate、解像度、timelineInputResMismatchBehavior
• TimelineItem: Pan、Tilt、ZoomX、ZoomY、ZoomGang、RotationAngle、4辺Crop、Opacity
• 逆解析で既知だが公式編集面が未確定の音声gain/fadeはaudit-only
• Text+のraw protobuf IDはunknown。Text+は.compとFusion compositionの公式面で編集する

値の範囲は、公式資料に記載された範囲をマニフェスト生成時に検証する。素材サイズ依存のPan/Tilt/Cropは、タイムライン解像度を明示しない要求を拒否する。

• /projects/{slug}/settings/resolve-parametersでタイムライン、対象トラック、開始フレーム、値を入力する。
• アプリが公式status、reverse status、型、範囲、対象クリップを検証する。
• immutableなresolve-parameter-manifest/1をprivate artifactとして保存し、SHA-256を返す。
• tools/resolve-adapter/apply_parameter_manifest.py --manifest ...をdry-runする。
• 本番の書き込みはコード側DRTを正本とする。apply_fusion.py、apply_geometry_contract.py、apply_master_audio_lane.py、apply_dialogue_textplus.pyなどのResolve API writerは通常の--goでは停止する。比較実験だけ、使い捨てタイムラインに対して--lab-only-api-writer --goを明示する。
• 各SetSetting/SetPropertyの直後にGetで読戻し、SaveProject後にDRTを書き出す。
• Resolveをclose/reopenし、同じtimelineを再読戻しする。DRT/DRP hash、tl_map、代表フレームのスクショをrunへ記録する。
• API読戻しだけではverifiedにしない。DRT構造と見た目が教師データ／正典スクショと一致した場合のみ昇格する。

python tools/resolve-adapter/drt_teacher_diff.py `
  --teacher "D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part11_Shorts_old.drt" `
  --candidate "candidate.drt" `
  --out dev/resolve-roundtrip-20260809/teacher-vs-candidate.json

known / candidate / unknownを出力し、未知IDをrenameしない。CompositionBA、MediaTimemapBA、FieldsBlob、EffectFiltersBAなどのopaque payloadはcandidateとして記録する。教師DRTをコピーして差分0になることは、コピーの完全性証明であって、Part1が正しい証明ではない。

• 公式APIの対象・型・範囲が台帳にある
• unknown raw IDを推測していない
• 対象トラック・開始フレーム・素材解像度がマニフェストにある
• API読戻しが一致する
• DRT/DRPとhashを保存する
• close/reopen後も値・字幕・音声・Fusion/Text+が残る
• 教師スクショと代表フレームのクロップ、タイトル台、字幕位置、グレーディングを比較する

• ローカル公式資料: C:\ProgramData\Blackmagic Design\DaVinci Resolve\Support\Developer\Scripting\README.txt
• [DaVinci Resolve公式マニュアル](https://www.blackmagicdesign.com/welcome/en/W-DRE-03)
• [Blackmagic Design公式トレーニング](https://www.blackmagicdesign.com/products/davinciresolve/training)

Part11を最初の教師ラウンドトリップにする場合は、次を実行する。

python tools/resolve-adapter/resolve_teacher_roundtrip.py `
  --project __Codex_Reference_Visuals_20260809 `
  --timeline "Part11_Shorts_old 2" `
  --teacher-drt "D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part11_Shorts_old.drt" `
  --teacher-analysis dev/resolve-roundtrip-20260809/teacher-Part11_Shorts_old.json `
  --out dev/resolve-roundtrip-20260809/Part11_teacher_api_roundtrip.json

officialTimelineItemPropertyPresenceはResolveのGetProperty()で見えている値、reverseTeacherAnalysisのEffectFilters statusはDRT側のknown/candidate/unknownである。両者が異なることは失敗ではなく、直接protobufを書き換えず、公式APIで操作してDRTとスクショで確認するための境界である。

original transcript JSON
  -> proofread master JSON / master subtitle
  -> approved master cut plan
  -> condensed main-program subtitle
  -> condensed short subtitle per episode
  -> TimelineIR / media registry / audio manifest
  -> code-generated teacher DRT candidate
  -> Resolve import and readback
  -> close/reopen, DRT/DRP hash, screenshot QC

The master JSON and master subtitle are the content and timing authorities.

Condensed subtitle layers are derived outputs. A short SRT is generated from

the short cut's record-time frames; it is never used to invent the cut range.

C:/Users/akihi/Downloads/Part12_Shorts 2_old.drt is a useful historical

teacher because it preserves BG / Angle / Slide / Overlay topology, native

subtitle/Text+ structure, Fusion carriers, and measured geometry better than a

generic API-built timeline. The independent check was 15 pass / 2 fail,

including a missing V10 result and an A2 link issue. It is therefore

historical-success/candidate, not a complete production reference.

The similarly named Part12_Shorts.drt is a different artifact and must not be

merged into the teacher profile without identity and graph-hash checks.

Inputs:

• .transcripts/Part11.master.json
• .plan-drafts/Part11.compact.json
• dev/master-srt-j/Part11.master.srt
• dev/master-srt-j/Part11.shorts.srt

The current Part11 plan has 42 shorts and 360-frame spacing, but it remains a

candidate until the source-to-cut mapping, approved speaker/angle mapping,

audio authority, and Resolve readback gates all pass.

The file

dev/resolve-live-20260809/Part11_candidate_teacher_overlay_probe_20260809_v12_teacher_text_control.drt

is failed evidence, not the final file. Its decoded audio has A2 with 65 OP or

camera fragments and no integrated Part11 WAV authority. The screenshot from

that timeline must not be used as a completion reference.

• Verify master JSON, master subtitle, plan, media registry, and audio manifest

hashes before writing.

• Copy a teacher DRT in code. Replace only measured known regions: record and

source ranges, approved text payloads, and explicitly verified geometry.

• Preserve native ST1 subtitle structure. Do not convert captions into PNG or

Text+ unless the teacher itself uses Text+ for that specific design layer.

• Preserve the teacher's BG / Angle / Slide / Overlay topology and the

angle-selector plus per-angle geometry as separate fields.

• Resolve API is limited to import, readback, render, screenshot, diff, and

close/reopen verification. It is not the production timeline constructor.

• Stop before writing when audio has an unresolved interval, when A2 does not

point at the manifest WAV, or when a DRT parameter is candidate or

unknown.

The overlay probe supports lab investigation without an audio manifest, but

its report is probe-only-unverified-audio. --production fails closed until

the A2 gate passes. Passing that gate still does not replace Resolve visual,

subtitle, close/reopen, or screenshot QC.

masterToShortPlan, short SRT completeness, audio unresolvedCount=0, Resolve

readback, close/reopen readback, DRT/DRP hashes, and representative screenshot

comparison must all be present in the same run manifest. Until then the result

is candidate or blocked, never complete.

Part10・Part11・Part12のDRTは、数字をコピーするためのテンプレートではない。

成功したタイムラインが成立した条件を、次の4層に分けて再現するための教師データである。

• 素材同一性: 同じ実ファイル、解像度、FPS、音声源が使えること。
• 編集グラフ: BG / Angle / Slide / Overlay、各トラック、カットの順序、マルチカム選択が成立していること。
• 表現形式: native subtitle、Text+、Fusion、Grade、EffectFiltersBAが教師と同じ役割で存在すること。
• 実機証跡: DRT読戻し、Resolve close/reopen、代表フレーム、音声A2、ハッシュが一致すること。

Part12の参照版とDownloads版はバイトが異なるが、素材・編集グラフ・トラック構造は一致した。

これはResolveがID、コンテナ名、時刻、MediaPoolメタデータを再生成するためであり、バイト差分だけで教師失敗とは判定できない。

一方、Part11候補は素材集合、内容選択、編集グラフ、トラック本数が教師と一致しない。

さらに候補はA2にカメラ／OP断片を持ち、統合WAVを音声正本として指していない。

したがって、Part12のTransform値やText+の一部を移植しても、成立条件を再現したことにはならない。

• 1回の実験で変更する宣言領域は1つだけにする。
• DbId、UUID、SeqContainer名、アーカイブメンバー、opaqueなFieldsBlob / CompositionBA / MediaTimemapBA / EffectFiltersBAを、意味名を推測して書き換えない。
• 差分に複数のフィールド族、アーカイブ構造変更、unknown IDが出たら自動で blocked にする。
• バイト同一は「コピーが完全」の証明であり、別シーンの正しさの証明ではない。
• APIの成功戻り値は証跡ではない。構造生成は本番経路にせず、APIはimport/readback/render/screenshot/close-reopenに限定する。

tools/resolve-adapter/teacher_graph_contract.py は、教師と候補を次の2つに分けて返す。

• semanticStatus: トラック集合、native字幕、映像ジェネレータ、Geometry payloadの文脈が維持されているか。
• productionStatus: 上記に加えて、統合音声manifestとResolve実機の再読戻しがあるか。

この判定器は dev/knowledge/production-route-policy-20260810.json の

drt-teacher-graph-contract として登録された監査専用ルートである。

semanticStatus=passでもproductionStatus=blockedになり得る。これは正常な安全側判定である。

音声未解決、字幕のPNG化、Angle selector欠落、素材FPS未確定、close/reopen未確認のいずれかがあれば本番昇格しない。

python tools/resolve-adapter/teacher_graph_contract.py `
  --teacher "D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part12_Shorts 2_old.drt" `
  --candidate candidate.drt `
  --out dev/knowledge/teacher-graph-contract.json

tools/resolve-adapter/code_side_teacher_drt.py is the only code-side DRT

patch route currently admitted to the cleaned knowledge base. It copies the

teacher ZIP without XML reserialization and changes only declared safe scalar

fields. Each clip patch requires the exact DbId and the exact old value.

The following are blocked in this route: FieldsBlob, EffectFiltersBA,

MediaTimemapBA, CompositionBA, CurrentSelectorIdx, MediaRef, grade,

Fusion, subtitle payloads, and audio graph fields. These are the fields that

previous API/probe routes changed too broadly and they are the reason a

Part11 candidate can look structurally complete while being visually wrong.

The Part12 copy proof is only a byte-level proof. It is classified as

candidate/unverified until Resolve import, DRT readback, close/reopen, and

screenshot comparison pass. A same-material Part12 graph may pass the

semantic contract; a Part11 graph with different observed video materials is

blocked unless an independent geometry/source-context contract is supplied.

このレポートはDRTを書き換えない。productionStatus=passにするには、別途audio manifestとResolve close/reopen証跡を同じRun Manifestに記録する必要がある。

Part12の成功例をPart11へ数値コピーしてはいけない。Part12で確認できたのは、同一タイムラインの構造をコード側で保ったまま複製できることだけである。Part11は素材・カット数・字幕数・音声レーンが異なるため、教師から再利用するのは検証済みの表現だけに限定する。

Part12のコード側コピーが成立した条件は、ZIPの変更がMediaPoolのタイムライン名だけで、MediaRef、selector、geometry、Fusion、grade、subtitle、audio、不透明payloadを変更しなかったことである。これは完全コピーの証明であり、別Partへの移植可能性の証明ではない。

Part11では、教師が8ショート・ST1 191・A1 97+A2 8なのに対し、候補は42ショート・ST1 1,091・A2 65+A3 6である。同名のC0355 MulticamでもDbId、UniqueMediaPoolItemId、FieldsBlob、nested Sequence、SeqContainer hashが異なる。したがって、素材名一致だけではAlt+1/Alt+2 selectorの同一性を証明できない。

tools/resolve-adapter/drt_teacher_overlay_probe.py は候補側のカット範囲、MediaRef、マルチカムselector、音声、ST1字幕を保持し、教師の装飾表現を限定移植する。

• V2（Angle 1）には教師V2、V3（Angle 2）には教師V3を別々に適用する。同じマルチカム素材でもV2/V3のTransform値を混ぜない。
• V2/V3はEffectFiltersBAのkind/parameterスキーマが完全一致しない限り停止する。素材解像度・input fit・座標系が違う場合、同じ数字を入れても同じ画面位置にならないためである。
• V1/V6/V7の固定装飾とV8/V9のRich generatorは、教師の表現を候補の時間・本文へ限定移植する。
• ST1の字幕はnative Sm2TiGenerator、PrettyType=Subtitle、RenderTextEnabled=trueを維持する。字幕をText+やPNGへ変換しない。
• MediaRef、FieldsBlob、CompositionBA、MediaTimemapBA、selector、音声は候補側の正本を保持し、未照合の置換をしない。

tools/resolve-adapter/verify_teacher_overlay_probe.py は次を読み取り専用で検証する。

• V2/V3等に教師EffectFiltersBAが適用されていること。
• 候補のStart/Duration/In/Out/MediaStartTime/MediaRef/selector/FieldsBlob等が変わっていないこと。
• ST1がnative字幕のままであること。
• DRTの対象XMLとMediaPool以外のopaque archive memberが変わっていないこと。

このゲートがpassしても、生成物はcandidateのままである。統合A2 WAVのhash、Resolve import/save/close-reopen、DRT読戻し、クロップ境界を含むスクリーンショット比較が揃うまでproductionへ昇格しない。

今回のPart11候補は、V2/V3のAngle別ジオメトリ適用と不変領域検証までは通過した。しかし教師と候補でV4/V8/V9の素材・生成器、字幕件数、音声レーンが異なるため、全体のteacher graph contractは引き続きblockedである。

Each round is recorded by tools/resolve-adapter/teacher_feedback_cycle.py.

It keeps the narrow DRT verifier, semantic graph, teacher applicability, audio

authority, and Resolve round-trip as separate gates. A passing narrow verifier

never promotes a candidate by itself; the blocked reasons and next actions are

written to dev/knowledge/part11-feedback-cycle-*.json.

The current record is dev/knowledge/part11-feedback-cycle-20260810-v4.json.

The v1 record is historical and superseded. A Resolve round-trip gate is not

passed by a screenshot, a DRT file, or file existence alone. Accepted evidence

must be structured native readback with verified import/save, close/reopen,

stable-field comparison, DRT/DRP identity, and screenshot comparison. The

current Part11 candidate has no such evidence and remains blocked from

production.

更新: 2026-08-10

Partごとの新規ショートは、空のタイムラインをAPIで組み立てない。まず同じ素材系統の教師DRTを選び、アーカイブをコード側でコピーする。今回の標準処理では、教師DRTの構造を保持したまま、Resolveで識別できるタイムライン名だけを変更する。

旧batch manifestは現行treeに無く、再び正本へ戻さない。採用中の証跡だけを

[resolve-evidence-registry-20260809.json](../../../dev/knowledge/resolve-evidence-registry-20260809.json)

から辿り、manifestが無い実績は未測定として扱う。

python tools/resolve-adapter/format_teacher_drt_batch.py `
  --manifest dev/knowledge/teacher-drt-batch-manifest-20260810.json `
  --out-root dev/knowledge/teacher-baselines/20260810 `
  --report dev/knowledge/teacher-drt-batch-format-20260810-v1.json `
  --workers 8

2026-08-10の実績は 12/12 formatted、DRT read-only batch decode は 12 files / 0 errors である。各出力は dev/knowledge/teacher-baselines/20260810/PartN.teacher-baseline_20260810.drt に置く。

• FieldsBlob、CompositionBA、MediaTimemapBA、EffectFiltersBA
• MediaRef、multicam selector、grade、Fusion、native ST1字幕
• Dialogue / BGM / SEを含む教師側の音声トラック構造
• BG / Angle / Slide / Overlay / Text / Logoのトラック順
• ZIP内の上記以外の全メンバーのペイロード

変更するのは MediaPool/Master/MpFolder.xml の明示したタイムライン名だけである。クリップのDbId、Transform、Crop、Zoom、FPS、MediaRef、字幕文言、音声参照、未知DRT IDはこの処理で変更しない。

formatStatus=pass は「教師アーカイブの名前だけを安全に整え、他のメンバーが保持された」という意味である。完成品・本番正本を意味しない。今回のPart1〜12の選定はすべて teacherStatus=candidate とし、次の確認が終わるまで昇格させない。

• ResolveへDRTをimport-onlyで投入する
• ST1、Text、Logo、Fusion、BG、Angle、音声トラックを画面とreadbackで確認する
• close/reopen後に同じタイムラインとpayloadを再読戻しする
• Master JSONのcut、素材MediaRef、実測FPS、話者↔Angle、source座標系のGeometry、統合Dialogue Master WAVを別ゲートで照合する
• 教師スクリーンショットとの比較が通ったものだけ known / production候補へ進める

DRTの容量は判定基準にしない。Part12の教師は約326KB、Part11は約382KBであり、候補側が1MB超でも容量だけでは失敗原因にならない。重要なのはSeqContainerのクリップ密度、ST1件数、MediaRef/selector、opaque payload、Resolveの応答性である。Resolveが応答しない場合は再投入せず、該当候補を隔離する。

• CreateEmptyTimeline、AppendToTimeline、SetSetting、SetPropertyで本番タイムラインを作らない
• APIで教師構造を再構成しない
• native字幕をPNGやText+へ変換しない
• 数値Transformを別解像度・別fit座標系へそのまま移植しない
• unknownを推測して名前付けしない
• 出力DRTを上書きしない。再実験は新しい日付・revisionで出す

このバッチは「全Partを同じ入口に揃える」ための教師フォーマット層であり、字幕縮約、話者判定、Angle精査、音声統合、HDR、最終Resolve QCを置き換えない。

更新: 2026-08-10

生成DRTは、コード側のdecode／narrow verifierがpassしても、Resolveで起動・読戻しできるまでは実行可能な成果物ではない。教師DRTだけが開いていたのは、教師を正本フォーマットとして先に確認し、生成候補はこの実機ゲートを通っていなかったためである。

• Resolve API: 読み取り専用のtimeline名、track、clip、media、setting、item属性の構造QCに使う。
• コード側DRT: バイト保持コピーと、測定済みの最小パッチに使う。CreateEmptyTimeline、AppendToTimeline、SetSetting、SetPropertyは本番経路で使わない。
• UI／OS操作: DRTをResolveへ投入し、Viewerの実ピクセル、ST1、Text、Fusion、BG、Angle、黒帯、クロップ、音声波形を確認するためだけに使う。
• したがって、スクリーンショットはAPIの代替ではなく、APIで表現できない見た目の証跡である。

Part11_MasterJSON_TeacherGeometry_v4.drt はコード側の狭い検証にはpassしたが、Resolve 21.0.3.0007を空の状態から起動しても、生成タイムラインを表示する前にResolveプロセスが終了した。教師ベースラインは4 ZIP entries／1 timeline／673 unique blobsで読戻しできたのに対し、候補は5 ZIP entries／2 timelines／2668 unique blobsであった。

この差は、単にTransform値を間違えたという段階ではない。候補が教師と異なるタイムライン・opaque payload・メディアグラフを持つため、narrowVerifier=passをResolve互換性の証明として扱ってはいけない。旧個別JSONは現行treeに無いため、採用状態は [resolve-evidence-registry-20260809.json](../../../dev/knowledge/resolve-evidence-registry-20260809.json) だけから辿る。

• 同じ素材系列の、Resolveで読戻し済み教師DRTを1タイムラインの基底にする。
• ZIPをXML再シリアライズせずコピーする。
• 変更は旧値・DbId・track・新値が測定済みのフィールドだけに限定する。
• 候補のtimeline数、SeqContainer数、MediaRef、selector、FieldsBlob、CompositionBA、MediaTimemapBA、EffectFiltersBA、native ST1、Fusion、grade、audio graphを教師との差分として記録する。
• 1ファイルだけResolveへ投入し、プロセス応答、timeline readback、Viewerスクリーンショット、close/reopenを記録する。
• どれか一つでも失敗した候補は blocked のまま隔離し、productionへ渡さない。

Part11は、1本の外側タイムラインに42ショートを順番に配置する。各ブロックはカット、アングル、音声、タイトル、ST1字幕を持つ。P1〜P42の別タイムラインや、Part11_Content_Only_v1のコンパウンド化は完成形にしない。

Katto_Master_Layout_Productionが全Part共通のレイアウト正本である。V1 bg.png、V6 Fusion Composition、V7 Logo_Black.png、V8/V9のRich/Text generatorは、XML/Fusion payloadを再生成せず、そのまま複製する。変更してよいのは各ブロックのStart/Duration、Part固有の映像カット、音声、タイトル文言、ST1文言とタイミングだけである。

自動DRTマージは構造readbackを通っても、Fusion payloadの描画がマスターと一致しないケースがあった。そこでResolveの完成マスターをDuplicateTimelineで複製し、手動修正用の基準を作成した。

• 基準タイムライン: Part11_MasterCopy_20260810_v1
• DRT: build/part11-manual-baseline-20260810/Part11_MasterCopy_20260810_v1.drt
• 共有DRT: D:/zFilms Dropbox/z Films/Directors'Katto/drp/auto-part11-20260810/manual-baseline/Part11_MasterCopy_20260810_v1.drt
• 範囲: 86400–87822 / 1080x1920 / 24fps
• 正本トラック: V1/V6/V7/V8/V9、各1 native item。placeholder 0
• Resolve検証: Save → close → reopen後も構造一致。レンダーで黄色テクスチャ、区切り線、タイトル、ロゴを確認済み
• 旧版参照: 同じResolveプロジェクトにPart11_Shorts_oldを保持。canonical DRTはD:/zFilms Dropbox/z Films/Directors'Katto/drp/export-20260807/reference/Part11_Shorts_old.drt。比較用コピーはD:/zFilms Dropbox/z Films/Directors'Katto/drp/auto-part11-20260810/manual-baseline/Part11_Shorts_old.drt

• Part11_MasterCopy_20260810_v1を開き、同じ1本の外側タイムラインへPart11の42ブロック、496カット、アングル、A1音声、タイトル、ST1字幕を反映する。
• V1/V6/V7/V8/V9のレイアウト・Fusion payload・generator設定は触らない。
• 編集後にDRTをexportし、基準DRTと一緒に保存する。
• 編集後DRTを受け取ったら、カット/アングル/音声/タイトル/ST1だけを許可差分として比較し、次の自動生成器へ反映する。
• 編集後DRTが戻るまでは、自動生成物を完成版と呼ばない。この時点で自動側の作業はいったん停止し、手動編集後のDRTを次の入力にする。

Part11_Production42_P1 importはResolveが受理した検証用timelineだが、V2とA1がPart11_Content_Only_v1 import 1というTimeline/compound clipになっている。これはflatなカット配置ではないため、そのまま教師データにしない。手動で使う場合は複製後にV2/A1をDecompose in Place（またはnested timelineを開いて外側へ実クリップを移動）し、V2/V3/V4とA1が直接見える状態にしてからDRTをexportする。V1/V6/V7/V8/V9とST1のnative layoutは触らない。

以前のv3〜v5はV1/V6/V7/V8/V9やST1の件数が揃っていても、直接レンダーでマスターと違う黒帯・中央映像・崩れたタイトルが出た。したがって、構造件数だけで合格にせず、マスターと同じフレームの直接レンダーを必須ゲートとする。

2026-08-11訂正: 本文中のPart11_MasterCopy_ContentOnly_20260810_v3.drt安全評価は撤回する。MediaPool/Master/MpFolder.xmlがnested EmbeddedAudioVec/<Element>の正規表現切断で未閉鎖だった。現行の実機再開手順は [15_part11_p1_session_handoff_20260811.md](./15_part11_p1_session_handoff_20260811.md) を正とする。

DRT/DRPは特殊な独自圧縮形式ではない。どちらもZIP + DEFLATEで、Resolve固有のXMLとopaqueなバイナリblobを格納する。

• DRT: 1タイムラインの縮約スナップショット。project.xml、MediaPool/Master/MpFolder.xml、SeqContainer/*.xmlを含む。
• DRP: プロジェクト全体のスナップショット。多数のSeqContainerとMediaPoolを含む。DRTをDRPへ変換する形式ではなく、別プロジェクトとして開く。
• 圧縮を解凍できても、Resolveが参照グラフを解決できなければ黒画面・空タイムライン・既存タイムライン返却になる。

Part12はResolveが書き出した完成グラフをほぼbyte-preservingで複製した。Part11の旧writerは、42本のnative装飾を再構成し、placeholder Fusionと大量のSeqContainerを追加したうえ、Multicamのnested SeqContainerと4カメラ素材の参照を落とした。

確認済みの旧候補:

• Part11_FlatNativeMasterFromClone_20260810_v2.drt: 681 SeqContainer、697 MediaPool要素、placeholder 360件。
• canonical one-block master: V1/V6/V7/V8/V9各1、placeholder 0。
• 正しいPart11 content closure: Multicam、Part11.mp3、raw MOV、4カメラ素材の計7 MediaRef + nested SeqContainer/1905b9af-4e3f-4795-b887-0c3128f3a262.xml。

つまり形式が読めないのではなく、MediaRef → MediaPool → nested SeqContainerのclosureを欠いたsynthetic graphがResolveの受理条件を満たしていなかった。

build/part11-master-content-only-20260810/Part11_MasterCopy_ContentOnly_20260810_v3.drt は、canonical masterのV1/V6/V7/V8/V9を各1つだけ保持し、V2/V3/V4=355/153/47、A1=496、ST1=1091を追加した静的候補である。placeholderと追加Fusionは0、closure SeqContainerは1、MediaPool追加は7。

ただし、API importが「新timeline名」を返すことだけでは合格にしない。Resolve画面で次を確認する。

• 新規timeline名が作成される（既存名の返却は失敗）。
• MediaPoolにplaceholderがない。
• Timeline先頭・中盤・末尾をスクリーンショットで確認する。
• V1/V6/V7/V8/V9はnative masterの1ブロック、V2/V3/V4/A1/ST1は正本順。
• Save → Close → Reopen後も同じtrack count、clip count、字幕表示である。

今回の実機ゲートは未合格である。v3 importは新規timelineを返さず既存timelineへフォールバックし、Resolve画面の自動取得もsky.list_windows()のspawn EPERMで停止した。ユーザー提供スクリーンショットの「応答なし」状態は、失敗候補を完成証跡に使ってはいけないことの実機証拠として記録する。

APIは構造を新規生成するために使わない。import、readback、export、close/reopen、画面確認だけに使う。根拠は [manual/L4_tools/davinci_resolve_api.md](../../L4_tools/davinci_resolve_api.md)、実装は [tools/resolve-adapter/build_part11_master_content_only.py](../../../tools/resolve-adapter/build_part11_master_content_only.py)、closure/rekeyは [tools/resolve-adapter/merge_part11_flat_st1_drt.py](../../../tools/resolve-adapter/merge_part11_flat_st1_drt.py) を参照する。

DRPをXMLに変換しても、Fusion、Color、Text+のopaque payload、Project Settings、native subtitle representationは完全には移植できない。Premiereへ渡すのはカット・素材・音声・SRTを中心にし、レイアウト／エフェクトの正本はResolveのDRT/DRPとする。

現行の関連仕様は [docs/SOT.md](../../../docs/SOT.md) からTimelineIR、NLE receipt、Project profileのownerへ辿る。

素材パスはMediaPool/Master/MpFolder.xmlの通常XMLにあり、MediaRefの文字列を追えば読める。一方、レイアウトやエフェクトは同じclipの中にあるFieldsBlob、EffectFiltersBA、CompositionBAへ分散している。さらに、clipのDbId、MediaRef、UniqueMediaPoolItemId、nested SeqContainerは相互参照であり、1つをコピーしても閉じたグラフにならない。したがって、パス抽出が成功しても、同じ見た目の編集可能timelineが得られたことにはならない。

Part12はResolve-authoredの完成グラフをほぼそのまま複製したため、opaque payload、track Sequence、MediaPool closureが一致した。Part11の旧writerは42ブロックをコードで合成し、native itemのDbId重複、placeholder Fusion、Multicam closure欠落、outer／nested Sequenceの混在を起こした。これはDRTが一般的でないからではなく、再構成側がResolveの内部グラフ契約を破ったためである。

Resolveが実際に受理したPart11_Production42_P1 importをグラフの入口にする。ただし、現在のP1 importはV2/A1にPart11_Content_Only_v1というTimeline clipを持つcompound構造である。次のwriterはこの構造をそのまま再利用し、外側のnested Sequence（MediaPoolの<Sm2Sequence DbId>とSeqContainerのroot）を維持したまま、以下だけをflat置換する。

• V2/V3/V4へPart11の実clip、A1へ496音声clip、ST1へ42 Partの字幕generatorを挿入する。
• compoundのTimeline itemだけを除去する。MediaPoolのcontent/multicam closureは参照が残る限り削除しない。
• V1/V6/V7/V8/V9はmasterのnative payloadを42回使うが、各clipのDbIdだけを新規化する。EffectFiltersBA、FieldsBlob、CompositionBA、MediaRef、UniqueMediaPoolItemIdは保持する。
• 全trackの<Sequence>を外側Containerではなく、MediaPool timeline clipのnested Sequence IDへ統一する。
• 新しいtimeline identityでimportし、返却名が既存timelineでないこと、V2/V3/V4/A1/ST1の数、placeholder=0、画面、close/reopenを確認する。

現行のbuild_part11_master_content_only.pyはcanonical one-block rootへ直接差し込む方式で、静的には整合してもResolveの受理グラフにならない場合がある。build_part11_flat_native_from_accepted_drt.pyをaccepted P1 root対応へ拡張するのが次の実装箇所であり、手動教師を作ることが本質的な解決策ではない。

次セッションは42本へ進まず、まずP1の1本を完成させる。

現在の最良候補は Part11_P1_FromHorizontalSource_20260811_v3 である。正本の横長Part11素材から映像・音声を切り出し、縦長マスターレイアウトと旧Shortsの画角だけを重ねた。Resolveへの新規importと実映像レンダーまでは通った。ただし、以下が未完了なので完成DRTではない。

• live Project Settingsが1920x1080であることの実機確認
• 映像と音声の同期確認
• katto_subtitle相当のST1表示・スタイル確認
• source側のカラー／Multicam効果が維持されていることの確認
• Save → Close → Reopen後の同一性確認
• ResolveからのDRT/DRP再書き出し

最終目標はPart11の1本のまとめタイムラインに42ショート・496カットをflat配置することだが、P1の上記ゲートが通るまでP2以降へ展開しない。

Project Settings、short timeline、source Multicamを混同しない。

縦長マスターのproject.xmlをProject Settingsの正本にすると、Multicamまで1080x1920として解釈され、crop、scale、カラー、音声同期が連鎖して崩れる。縦長にするのは完成Short timelineだけである。

DRT内の設定が正しくても、既存のResolveプロジェクトへimportしただけではlive Project Settingsが直った証明にならない。次セッションではProject Settings画面またはproject.GetSetting()のreadbackとスクリーンショットを必ず残す。

注意: C:\Users\akihi\Downloads\Part11.drt（SHA-256 9f5a54f3ba028765e7632da2bd8fbf4124b2a4d5600314c4073b7b8c3ee9ebca）は、現物解析ではPart11と20260411_C0355 Multicamが1080x1920になっている。横長正本としては使わず、上表のexport-20260807/reference/Part11.drtを使う。

• DRT: build/part11-full-20260811/Part11_P1_FromHorizontalSource_20260811_v3.drt
• SHA-256: 666b3dc162dc7b191c732eba1b7b57771f4645e17a0616fbe89b55574dbb647e
• manifest: build/part11-full-20260811/Part11_P1_FromHorizontalSource_20260811_v3.manifest.json
• decode: build/part11-full-20260811/Part11_P1_FromHorizontalSource_20260811_v3.decode.json
• Resolve import report: build/part11-full-20260811/p1-horizontal-v3-import.json
• Resolve project: Part11_Part12MasterLayout_20260810_v2
• imported timeline: Part11_P1_FromHorizontalSource_20260811_v3
• render: build/part11-full-20260811/render-p1-v3/unique/zfilms-probe-unique.mov
• render SHA-256: 19e65396111851d38daa22d24427d8fd160ffbf9869a00fc17ecfaf7501c9ed6
• frame: build/part11-full-20260811/render-p1-v3/p1-v3-frame-025.png

静的構造とimport readback:

• 外側timeline: 1080x1920 / 24fps / [86400,87505) / 1105F
• source nested 20260411_C0355 Multicam: 1920x1080 / 24fps
• V1=1、V2=12、V3=0、V4=0、V6=1、V7=1、V8=1、V9=1
• A1=12、ST1=7
• V2/A1はtimeline clipやcompoundではなく、外側timelineへ実clipを直接配置
• project.xmlは横長Part11正本からbyte保持
• V1/V6/V7/V8/V9はcanonical masterから保持
• V2 framingだけPart11_Shorts_oldの既存EffectFiltersBAを適用
• real videoのResolve renderは成功

dev/short-plan/Part11.jsonのP1を使用した。

[426,489] [498,591] [632,733]
[20224,20368] [20384,20546] [20561,20688]
[20918,20965] [21095,21169] [21187,21296]
[21310,21390] [21492,21540] [21703,21760]

現在のwriterはsourceBodyOrigin=87545、timelineOrigin=86400として同じsource rangeからV2とA1を切り出す。コード上は映像・音声のrecord Startが一致するが、実再生での同期とcut境界の1〜2F丸めはまだ合格していない。

現行Resolve project Part11_Part12MasterLayout_20260810_v2は、ユーザー確認時にProject Settingsが1080x1920だった。P1 v3のDRT archiveは横長sourceのproject.xmlを保持するよう修正したが、既存projectへimportしただけではlive Project Settingsは変わらない可能性がある。

次セッションは、共有projectをさらに変更する前に複製または検証専用projectを用意し、次を別々にreadbackする。

• Project Settings = 1920x1080
• P1 short timeline = 1080x1920
• nested C0355 Multicam = 1920x1080

P1 v3はV2/A1を同じ横長Part11 source clipと同じcut rangesから生成した。旧候補より構造は正しいが、音声を含むレンダーの視聴、cutごとのStart/Duration/In比較、cut境界の波形確認が未完了である。

ST1 trackは7 itemとしてimportされたが、1秒probe renderでは字幕が見えなかった。katto_subtitleのtrack presetを手動版から一時的に参照しているが、完成条件にはしていない。

次セッションでは次の順で切り分ける。

• ST1 cueが存在するフレームへplayheadを置き、Edit pageで字幕が表示されるか確認する。
• ST1 track自体にkatto_subtitleをResolve上で適用し、preset適用後DRTを差分取得する。
• subtitle burn-inを明示したレンダーで表示を確認する。
• Save → Close → Reopen後にも同じstyle、位置、本文が残ることを確認する。

ユーザー手動DRTは差分教材であり、映像・音声・angleをコピーして完成扱いにしない。

現在のV8/V9はcanonical masterの既存native payloadを保持しており、P1固有タイトルの最終反映は未完了である。過去にText+ opaque payloadを直接書換えてResolveをクラッシュさせたため、推測書換えを再開しない。Resolve-authored one-variable diffを取得してから限定変更する。

カラーはsource Multicam closureとclip payloadを保持しているが、live Resolve上でsource本編とP1の同一フレームを比較して最終確認する。

• Project Settingsとtimeline settingsを混同した。 縦長masterのproject shellを使ったため、source Multicamまで1080x1920扱いになった。
• 違うPart11 DRTをsourceにした。 Downloads版は横長authorityとhash・SequenceSetupが違った。
• MediaRefだけを差し替えた。 旧short clipのMediaStartTime、MediaTimemapBA、selector、effectを残したまま本編素材へrebindし、映像・音声・angleを壊した。
• MediaPool XMLを正規表現で切った。 nested EmbeddedAudioVec/<Element>を最初の</Element>で切断し、ContentOnly v1/v2/v3/FromAcceptedのMpFolder.xmlを壊した。
• native itemを42回同一DbIdで複製した。 placeholder 360件、SeqContainer 681件、outer/nested Sequence不一致を生んだ。
• compoundを完成形にした。 Part11_Content_Only_v1 import 1をV2/A1へ1clipで置いたため、外側からcutを編集できなかった。
• 字幕itemとtrack styleを同一視した。 raw ST1 itemを置くだけではkatto_subtitle presetは付かない。

DRT/DRPの外側はZIP + DEFLATEであり、形式が解凍できないことが原因ではない。問題はXML内のMediaRef closure、nested Sequence、DbId、FieldsBlob、EffectFiltersBA、CompositionBAを異なる正本から混ぜたことにある。

次の成果物をproduction inputに戻さない。

• Part11_MasterCopy_ContentOnly_20260810_v1/v2/v3/FromAccepted
• MediaPool/Master/MpFolder.xmlが未閉鎖。Resolve基盤に使わない。
• Part11_MasterBased_42x496_Candidate*
• Part11_FlatNativeMasterFromClone*
• duplicate DbId、placeholder、参照不整合がある。
• Part11_Production42_P1〜P42
• V2/A1がnested/compoundの検証物。
• build_part11_full_from_horizontal_source.pyで作った42本v4候補
• importしてもvideoがblank。旧aggregate metadataを残したMediaRef rebind経路。
• FCPXML、PNG字幕、__zfilms_fusion_placeholder.png

Set-Location 'C:\Users\akihi\OneDrive\ドキュメント\ZFILMS\zfilms-subtitles-part11-handoff'
git status --short --branch

branchはCodex/part11-claude-handoff-pr-20260810。dirty worktreeの変更を消さない。計画の正本はdocs/PLAN.md、この文書は実機再開手順である。

再生成より先に、検証専用projectでProject Settingsを1920x1080にしたうえで既存v3をimportする。Resolveエラー時に別window／Untitled Projectへ移ることがあるため、毎回--expect-projectでfail-closeする。

python tools/resolve-adapter/import_drt.py `
  --expect-project '<1920x1080の検証project名>' `
  --drt 'build\part11-full-20260811\Part11_P1_FromHorizontalSource_20260811_v3.drt' `
  --expect-timeline 'Part11_P1_FromHorizontalSource_20260811_v3' `
  --report 'build\part11-full-20260811\p1-v3-clean-project-import.json' `
  --go

同名timelineが既にあるprojectではfresh importにならないため、clean projectか新しいtimeline identityで再生成する。

build_short_drt.pyだけを現行writerとして使う。出力は上書き拒否なので、v4など新しい名前へ出す。

python tools/resolve-adapter/build_short_drt.py `
  --source-drt "D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part11.drt" `
  --master-drt "D:\zFilms Dropbox\z Films\Directors'Katto\drp\auto-part11-20260810\master-layout\Katto_Master_Layout_Production.drt" `
  --layout-drt "D:\zFilms Dropbox\z Films\Directors'Katto\drp\export-20260807\reference\Part11_Shorts_old.drt" `
  --subtitle-drt "D:\zFilms Dropbox\z Films\Directors'Katto\drp\auto-part11-20260810\production42-v1\raw-drt\Part11_Production42_P1.drt" `
  --plan-json 'dev\short-plan\Part11.json' `
  --short-id P1 `
  --timeline-name 'Part11_P1_FromHorizontalSource_20260811_v4' `
  --output 'build\part11-full-20260811\Part11_P1_FromHorizontalSource_20260811_v4.drt' `
  --manifest 'build\part11-full-20260811\Part11_P1_FromHorizontalSource_20260811_v4.manifest.json'

--subtitle-style-drtは現時点では手動比較資料への依存になる。最終候補では、Resolve上のkatto_subtitle適用済みtrackを正規のstyle authorityとしてexportできるまで省略または検証専用とする。

ユーザーはResolveのSave、close/reopen、必要な再起動、スクリーンショットによる自動確認を許可済みである。ただしResolveエラーで別windowやUntitled Projectが開くことがあるため、操作の前後で対象project名とtimeline名を必ず再確認する。

• Project Settings、P1 timeline settings、nested Multicam settingsを別々にreadbackし、スクリーンショットを保存する。
• source Part11とP1の同じ発話点を並べ、映像・音声同期、angle、crop、カラーを確認する。
• ST1 cue上でkatto_subtitleの本文、位置、font、stroke、shadowを確認する。
• subtitle burn-inを含む全尺レンダーを作る。先頭だけでなくcut後半も見る。
• verify_close_reopen_counts.pyでSave → Close → Reopenを実行する。
• export_timelines.pyでResolve-authored DRTとDRPを書き出し、再importして同一性を確認する。

python tools/resolve-adapter/verify_close_reopen_counts.py `
  --project '<検証project名>' `
  --timeline '<合格させるP1 timeline名>' `
  --out 'build\part11-full-20260811\p1-close-reopen.json'

python tools/resolve-adapter/export_timelines.py `
  --expect-project '<検証project名>' `
  --out-dir 'build\part11-full-20260811\resolve-export' `
  --timeline '<合格させるP1 timeline名>' `
  --drp `
  --drp-path 'build\part11-full-20260811\resolve-export\Part11_P1_verified.drp'

次の全項目を満たして初めてP1完成とする。

• [ ] live Project Settings 1920x1080 / 24fps
• [ ] target timeline 1080x1920 / 24fps
• [ ] nested C0355 Multicam 1920x1080 / 24fps
• [ ] V2/A1がflatな12実clipで、Start/In/Durationと再生が同期
• [ ] 正しいangle、crop、scale、カラー
• [ ] V1/V6/V7/V8/V9がcanonical masterと同じ描画
• [ ] P1固有タイトル
• [ ] ST1本文とkatto_subtitle styleが表示
• [ ] placeholder 0、compound/nested content clip 0
• [ ] 全尺レンダーの目視合格
• [ ] Save → Close → Reopen後に構造・描画一致
• [ ] Resolve-authored DRT/DRPを書き出し、再import合格

P1合格後だけ、同じ構造を1本のproduction timeline上でP2〜P42へ順に拡張する。

• worktree: C:\Users\akihi\OneDrive\ドキュメント\ZFILMS\zfilms-subtitles-part11-handoff
• branch: Codex/part11-claude-handoff-pr-20260810
• 既存dirty変更がある。git reset --hard、git checkout --、無差別削除をしない。
• 今回の実装入口: tools/resolve-adapter/build_short_drt.py
• 古い42本writerを修正し続ける前に、P1 writerと実機ゲートを完成させる。

この分類が字幕の統制の起点。以降のすべての工程が、どの層を入力にし、どの層を出力にするかを明示する。層を混ぜたことが、これまでの不具合の大半の原因だった。

浅尾確定（2026-08-03）。

ショートは縮約字幕からのみ作る。 他の層からは作らない。

収録
 └→ オリジナル ──校正──→ 校正字幕 ──軽いカット──→ マスター ──縮約──→ 縮約字幕
                                                                        ├→ 本編（16:9）
                                                                        └→ ショート（9:16）

層4 は 2026-08-07 に足した。 それまで層が 3 つしか無かったため、本文が逐語のまま

組版へ入り、CPS が話速そのものになっていた（全 error の 75% がこれ）。

縮約は Part 単位で 1 回。本編用とショート用に分けない。 分けた瞬間に本文が 2 つになり、

下の §2 が壊れる。幅が変えるのは改行位置であって、字数の密度ではない。

ショートは本文のコピーを持たない。マスターへの参照だけを持つ。

コピーを持たせると、こうなる（2026-08-03 に全部実際に起きた）。

マスターが確定すれば、ショートは二度と校正しなくてよい。 それがこの分類の目的。

カットなしのオリジナルレベルのものを、まず ElevenLabs に当てる。

編集後の音声を書き起こすと、その書き起こしはオリジナルではなくマスター相当になる。層が 1 つ潰れ、どこを削ったのかが永久に分からなくなる。

校正字幕からマスターへ移る際のルールを、これまで持っていなかった。

そのため、マスター時点の編集後に ElevenLabs 書き起こしをしているものが混ざっている。 その回では：

• 手元の「書き起こし」は実質マスター相当であって、オリジナルではない
• オリジナル字幕が存在しない
• 削った区間が分からないので、マスターとオリジナルの差分が取れない

回ごとに、その書き起こしがどの層なのかを判定してから使うこと。 判定せずに「オリジナル」として扱うと、時間軸が本編とずれる。

実際に起きた例（2026-08-03 実測）:

いずれも「どの層のどの版か」を明示していなかったために起きている。

13 Part すべてが編集後の音声に ElevenLabs を当てたもので、オリジナル字幕は 1 本も無い。

測り方と根拠の全文は docs/PLAN.md「2026-08-04 手元の書き起こし 13 Part が字幕の三層のどれかを 1 話ずつ判定した」。

.transcripts/<Part>.{corrected,proofread,repaired}.json は Part ごとに先頭・末尾が完全一致で、

校正で時間軸は動いていない。 三層の定義どおりに動いている。

Part12 だけ、冒頭 9〜25 秒にマイク調整の生のやり取りが残っている。 マスター化で落とす候補だが、

§7 の規則が空なので機械で落とさない。

各成果物に、どの層か・何から作られたかを必ず持たせる。

layer          original | proofread | master
derivedFrom    元にした成果物の識別子とハッシュ
rulesVersion   校正なら辞書と規則の版、マスターならカット規則の版

lib/subtitle/rules-hash.ts が字幕の数値ルールで同じことをやっているので、その作法に揃える。

2026-08-04 に scripts/materialize-master-subtitles.mjs を追加し、13 Part＋Special1について

.transcripts/<Part>.master.json を生成した。校正本文をそのまま保持し、layer: master、

derivedFrom、rulesVersion、DRP offset、保留理由を成果物へ付けている。未確定の区間は削除していない。

校正字幕とマスター字幕は、外部ツールなしで Claude Code の規則だけで作れる。

• 校正 → lib/katto/corrections.ts lib/katto/dictionary.ts と manual/L1_subtitle/08_multipass_correction.md
• マスター化 → 何をテクニカルトラブルとみなして落とすかの規則。ここはまだ書かれていない（本ファイルの §7）

落とす対象をここに列挙する。確定するまで、マスター化で機械削除しない。

初期 materialization rule は「proofread本文を保持し、未確定区間を pendingReview に記録する」である。

これは最終的な編集済みマスターの完成を意味しない。

未記入。浅尾の判断を待つ項目：

• 機材トラブル・撮り直しの宣言
• 長い沈黙（何秒から落とすか）
• 収録の中断・再開の前後
• 進行上の打ち合わせ（本編に不要なもの）
• 言い直しのうち、前半を落とすか両方残すか

現時点の保留:

• Part9: Final/Part9.mp4はあるが、動画音声と本文に115.647秒差があり、DRP offsetと本文の突合が未完了
• Part12: 冒頭9〜25秒のマイク調整を残すか削るか未決定
• Special1: DRP上のダイジェスト／OP構造が未確認

規則が空のまま機械で落としてはいけない。 何を落としたかが分からなくなる。

• 05_transcription_pipeline.md — 書き起こしの実行手順
• 07_elevenlabs_workflow.md — ElevenLabs の当て方
• 08_multipass_correction.md — 校正の多段処理
• manual/L2_sns/02_shorts_planning_framework.md — ショートの構成（マスターから作る）

あらゆる日本語字幕の共通ルール。1 行の字数と行数は案件ごとのパラメータで、 正本が持つのは動かしてよい範囲である。

単一の正解値は無い。 案件・画面比・テロップ設計で変わるので、正本は範囲を持ち、

実際の値はプロジェクト設定から渡す。

範囲の外は例外にする。黙って丸めない（SubtitleLayoutOutOfBoundsError）。

丸めると、頼んだ値と焼き込まれた値が違うのに誰も気付かないまま出荷される。

行数を増やしたら容量も増える。 maxLines だけ 2→3 にして容量が据え置きだと、

3 行目は一度も使われないまま「3 行に対応した」ことになる。容量を別に決めたい案件は

maxTotalChars を明示する。実装は lib/subtitle/thresholds.ts の JA_LAYOUT_BOUNDS、

検証は tests/lib/subtitle-layout-bounds.test.ts。

この決定は「正本 10 字 / 実装 13 字」の食い違いを閉じたもの。 どちらか一方を選ぶ

問いではなく、両方とも範囲の内側の妥当な既定値だった。

範囲を決めた根拠。そのまま使う値ではない。

ラテン文字には当てない。 6〜16 は全角基準で、半角は幅が約半分。英語字幕は

1 行 42 字（Netflix / AVTpro 系）で、可変域も別に持つ（LATIN_LAYOUT_BOUNDS）。

カウント方法: 全角=1、半角=0.5。

下の表は業界の目安であって、この案件が使う値ではない。

実際に出荷している CPS は本文末尾の「規則値（自動生成）」が持つ（lib/rules/registry.ts が正本）。

目安:

• 4 CPS = 快適
• 6 CPS = 許容上限
• 7+ CPS = 読み取り困難（特別な配慮が必要）

実装は lib/subtitle/cueTiming.ts の applyLeadOut。

• 次のキューが来るならそちらが優先。 次の入り − 最小ギャップを超えて伸ばさない
• 次が無ければ言い終わり +0.5秒
• それでも最短表示時間（500ms）に届かなければ 1.0秒まで
• 最大表示時間で頭打ち

伸ばすのではなく、切り詰めるのが主な仕事。 出荷済みは「言い終わってから次の人が

喋り出すまで」を 1 枚が抱えていて、末尾の無音が最大 3.48 秒、尺が最大 18.44 秒あった。

この規則を通すと 0.50 秒 / 7.00 秒で頭打ちになる。

0.5〜1.0 秒を超える余韻は業界標準を外れる。 意図して外すとき以外は使わない。

実測すると、句読点だけで切った生成は 4 秒超のキューが人手の 4 倍出た。

上限を超えたら文節境界で割る（§4「1 枚に収まらないとき」）。

scripts/compare-cue-timing.mts で測る。

切ってよい位置のレベル（L0 強調フレーズ ／ L1 話者交代 ／ L2 意味のまとまり ／ L3 改行ポイント ／ L4 音節）は、 グローバル正本 `docs/SHORTS_CUTTER_SUBTITLES.md` が持つ。 レベルを付けるのは LLM、禁則の検算と幅の適用は機械（lib/subtitle/break-levels.ts）。 以下の禁止事項と罰点は今も有効で、機械側の検算がそのまま使う。 工程の順番は 09_break_priority.md（段0〜段4）。段は工程、L0〜L4 は位置の種類で別物。

意味のまとまり（文節）で区切る。絶対に助詞から始めない。

行の文字数は均等である必要なし。意味的完全性 > 視覚的バランス。

均等に割れるからという理由で文節の途中を選んではいけない。

実装は lib/subtitle/breakPoints.ts。切ってよい位置を全部出し、それぞれに罰点を付ける。

行幅を決め打ちして改行位置を焼き込まない。 位置と罰点だけ先に出しておけば、

10 字でも 13 字でも同じデータから組み直せる。罰点は小さいほど良い切れ目。

補助動詞の直後は「切ってよい」ではない。

補助動詞は基本切りたくないな。完全にどうしても切れない場合だよ。（浅尾確定 2026-08-14）

独立した語なので禁則にはしない（候補には立つ）。**罰点を音節改行と同じ 90 にして、

他に候補があるかぎり選ばれないようにする。** 縮約形（〜てた 〜てる 〜てへん 〜てく

〜てまう 〜とく）は 1 語なので候補にすらしない（禁則）。みる は 〜て、見る と

字面で区別できないので対象外（罰点 16 のまま）。詳細と実測は

09_break_priority.md §2「補助動詞の直後は『切ってよい』ではない」。

句読点は表示しないが、切る判断には使う。 先に落とすと罰点 0 と 8 のいちばん強い切れ目が

消え、合法率が 54% で止まる。組んでから落とす。

罰点 55「カタカナ語の音節境界（N 字以上続く語）」は 2026-08-11 に撤去した。

候補を出す側（findBreakPoints）は行幅を知らない。幅を知らないまま「6 字以上なら割ってよい」と

言うと、その行に載る語まで割れる。 実測 2026-08-11（全 13 Part / 34,000 キュー / 本番経路

build-master-srt）: katakana_break 405 件のほぼ全部がこの段の出力で、

タイムラ|イン（6 字・上限 13）キャラク|ター プロジェ|クト サラ|リーマン のように、

割る必要のない語が割れていた。下の「改行してはいけない位置」が名指しで禁じている

「カタカナ複合語の途中」そのものである。

いまは幅を持つ syllableBreakPoints（罰点 90）だけが受け持ち、

候補と候補のあいだが 1 行に収まらないときにしか立たない。字種は問わないので、

カタカナ以外の長い語も同じ経路で割れる（浅尾指示 2026-08-11:「6文字以上の長い単語やカタカナ語」）。

全部ひらがなの区間には字種の変わり目も助詞の直後も無い。罰点モデルだけでは

「映画これから撮りたいよみた|いな人がいた時に」のように語の途中で折れる。

そこを埋めるのは LLM の L3 改行ポイント付与である（lib/subtitle/break-levels.ts）。

文節モデル（BudouX 等）は使わない（2026-08-16）。 実測で

ぜひよろしくお願いしますはいじゃあ に対し はい を は｜い と割る位置を優先候補として返し、

本当の切れ目 します｜はい は候補にすら立たなかった。

LLM が語頭と申告した位置は、1 文字助詞の禁止を解除する。

字面で助詞を判定すると語頭が同じ字の語を巻き込む。やばい『やっぱ』は「や」、

ところ『という』は「と」で始まるため、解除しないと行頭に置けない。

実害として 倫理的に|やばいやろって は候補が 1 件も立たなかった。

申告が効いた回数を数えて出す（全部に付けて回る応答はそこに出る）。

• 動詞活用の途中（撮り|たい、やっ|たら、ご飯食べ|ましょう）
• 活用語尾の途中（関係な|い、です|、〜な|かった）

1 文字の助詞を字面で見ると活用語尾を取り違える。関係 が漢字なので「な」を

格助詞と判定し 関係な|い を候補に出してしまう。禁則として持ち、

候補の生成だけでなく機械折り返しにも効かせる

• LLM が 1 語と申告した短い塊の内側（6 字以下の塊）。

長い塊には掛けない。「空気変えてくれる」（8 字）を丸ごと守ると

変えて|くれる が使えなくなり、他に候補が無い本文で詰む

• 送り仮名の途中（漢字→ひらがなの境界は候補にしない）
• カタカナ複合語の途中（タ|イミング、ワンシチュ|エーション）
• 格助詞が次行の先頭に来る位置
• 形式名詞の途中（ところ / こと / もの / という / みたいな / っていう）
• 連語（複合助詞）の途中（と|して、に|おいて、に|よって、に|関して）。

ただし意志形と擬態語は別（作ろうと|して、ピリッと|して は と までが前の語）

• 名前と敬称のあいだ（齋藤|君、デューク|氏）。左が漢字・カタカナ・英数字のときだけ
• 固有名詞の内部（辞書の語は範囲ごと保護する）
• 数字と助数詞のあいだ、英数字の途中
• 行頭禁則（小書き仮名・長音・約物）、行末禁則（開き括弧）

案件ごとに決める。 実装は pyramidWeight（既定 0 = 掛けない）。

2 行目に 1 文字だけ残さない。

規則違反は出さない（浅尾確定 2026-08-10）。順に試す。この 3 つで必ず解ける。

• 改行。 候補（下の罰点表）から組む。1 行の字数は案件ごとのパラメータで、

13 字も 10 字も同じ実装（layoutLinesDetailed）が扱う。幅を決め打ちした改行器を別に作らない。

• カット。 どう組んでも 1 枚に入らない本文がある。

「映画これから撮りたいよみたいな人がいた時に」（24 字）は合法な切れ目が 6 / 15 / 17 字目で、

どれで割っても片側が 13 字を超える。候補を増やしても解けない。

1 枚に詰め込まず、カットを入れて次へ続ける（映画字幕と同じ扱い）。

• 音節改行。 1 語が 1 行に載らないときだけ。

コミュニケーション を 5 字幅に置くようなときは、その語の中をモーラ境界で割る。

行頭に来られない字（小書き仮名・長音・撥音・約物）と活用語尾は避ける。

1 行に載る語は割らない。字種は問わない（カタカナ限定ではない）。

この 3 段は layoutLinesDetailed が outcome: 'fit' | 'cut' | 'syllable' で返す。

②を③より先に置く。 逆にすると、カットで解ける本文を音節で解いてしまい②が飛ばされる。

カットできる呼び出し側には、音節へ降りる前に fits: false / outcome: 'cut' を返す。

幅で機械的に折り返す経路は持たない。 そこには禁則もモーラ規則も無く、

消え|る、 関係な|い めちゃめ|ちゃ はすべてそこから出ていた（docs/PLAN.md 2026-08-10）。

2026-08-11 に等分割（splitByLength）を削除して経路ごと閉じた。

1 枚に収まらない本文は切れ目候補でだけ割り、どの候補でも収まらないときは

はみ出しがいちばん小さい合法な位置を選ぶ。幅を超えるほうが、語を割るよりよい。

カットを入れられない出口（焼き込みタイトルなど）は、組めなかったことを報告して出さない。

それでも出す場合、はみ出すのは幅であって切れ目ではない（切れ目は常に合法）。

はみ出しの許容（旧 `overflowTolerance`、既定 2 字）は 2026-08-11 に型ごと削除した。

上限を超えた行が出るのは「はみ出しを許した」のではなく「組めなかったのに出した」ときだけなので、

検証側は 1 字でも `char_limit`（error）にする。warning へ落とす階層は無い。

scripts/check-line-breaks.mts で測る。改行位置が上の候補に入っているかを数える。

上限超過は 0 件。 本番経路 scripts/build-master-srt.mts / 全 13 Part / 33,556 キュー

（2026-08-12 実測）。行数超過・総字数超過・句読点・重なりも 0 件で、

同じ SRT を独立実装で数え直しても同数だった。

違反件数を成果として読む前に、その件数が本物かを確かめる。 全 error 1,374 件を

種別ごとに読んだ結果、過検出が 174 件（12.7%）あった。原因は 1 つに集約できる。

検証側だけが句読点を見ていなかった。 表示では 、。 を落とすので、出力の行だけを見ると まあしゃあないよな。｜いや。 が な＋い = ない の分断に見える。 §4 の罰点表は句点の直後を 0 点（最良の切れ目）と定めているのだから、 そこを違反に数えるのは検出側の誤りである。

直し方は、生成に使った句読点つき本文を検証にも渡すだけ

（validateSubtitles の bodies、cuesFromSource が前から返している）。

min_gap は日本語の問題ではない。生成側が start = 前の end + minGapSec と置いた値を

検証側が引き算し直すと、浮動小数の丸めで 1 ナノ秒だけ下回る。

規則どおりに置いた位置が全部違反になっていた。

**残り 55 件（katakana_break 39 ／ particle_start 16）は 1 件ずつ読んで

「正本上そうなるしかない」ことを確かめてある。** うち 6 件は

lib/subtitle/compound-lexicon.ts に継ぎ目が無いだけの過検出

（キャスティング｜コール 革ジャン｜アメリカ ウェスタン｜ベース

スペース｜マーケット キャンディ｜チューン フォーカス｜マン）で、

語彙を足すかは人が決める（L1-09 §9 のループ）。残る 49 件は本物である。

過検出だけ直すと「検出器が甘くなった」だけになる。 全長から等間隔に 300 箇所

抜いて目で読み、検出器が拾えていない違反を数えた。

1 回目に見つけた 7 件のうち 3 つの型は表に無いだけだったので足した（実測 193 件が消えた）。

2 回目に残った 6 件はまだ表に無い型である。

推定 recall は約 13%（検出 55 件 ／ 推定総数 55 + 300 分の 6 × 18,031 ≒ 416）。

「規則違反 0」と書けるのは、この recall が上がってからである。

器は [scripts/audit-recall.mts](../../scripts/audit-recall.mts)。**出荷 SRT と 1 バイト一致を

照合してから数える**ので、測るものと出荷されるものが同じ経路から出ている。

抜く位置の位相は van der Corput 列で周ごとにずらす（同じ 300 箇所を読み続けても新しい型は出ない）。

記録は dev/knowledge/recall-rounds-20260813.json。

「消えた箇所」の合計は 12 周で 690。「誤検出の増加」は 12 周とも 0

（出荷される SRT の particle_start は 16 のまま、katakana_break は 38 のまま、

verb_break と char_limit の新規はいずれも下で説明した 1 件だけ）。

減り方の曲線は 2 通りに測れて、答えが違う。

① 出力に残っている違反の数は落ちる。ただしどの検出器で数え直したかで値が変わる。

7 周目の検出器で数えた:  監査前 250 → 3周後 194 → 4周後 129 → 5周後 92 → 6周後 14 → 7周後 0
12 周目の検出器で数え直す: 7周後 150 → 8周後 93 → 9周後 70 → 10周後 37 → 11周後 5 → 12周後 0

「7 周後に 0」は「7 周目までに知っていた型が 0」という意味でしかなかった。

同じ出力を 12 周目の検出器で数え直すと 150 件ある。

曲線の 0 を「違反が無い」と読んではいけない。

② 目の当たり率（300 箇所あたり）は 7 / 6 / 5 / 9 / 7 / 8 / 6 / 8 / 3 / 4 / 5 / 4。

1〜8 周の率は 7.07 / 300 で、そのポアソン帯（両側 95%）は [2, 13]。

9〜12 周の 3・4・5・4 はどれも下限を割っていない。

ただし率そのものは下がった。 9〜12 周は 1,200 箇所で 16 件。

1〜8 周の率なら期待値 28.3 件で、これ以下になる確率は 0.9%。

族の出方も変わった。 3〜8 周は毎周ちがう族が出ていたが、

9・11・12 周は既知の族の再出だけ（新しい族が出たのは 10 周目の 2 つだけ）。

頭打ちの判定は「まだ下がっていない」。 判定の条件は

①2 周連続でポアソン帯の下限を割る かつ ②新しい族が出ない の両方で、

②は 11・12 周で満たしたが、①は 12 周とも満たしていない。

推定残存は 241 箇所（95% 区間 138〜391）。 9〜12 周の率 × 母集団 18,082 箇所。

残っているのは族ではなく語の裾である。 8〜12 周で語彙に足した 21 語の

1 語あたりの件数は中央値 2、最大 19（じゃあ）、最小 1。

この裾は機械化できない。 正本 §4 が名指ししている「1 語と見た

短い塊（6 字以下）の内側」を検証側にも入れて測ったが、母集団に当たる 98 件の大半が

〜あんねん｜けど（罰点 12「接続助詞の直前」＝合法）で、塊 4 字以下まで絞ると 4 件中 3 件が合法だった。

足した型（3〜12 周目、計 51 型 / 690 箇所）

過検出は 12 周とも 1 件も増えていない。 出荷される SRT の particle_start は 16 のまま、

katakana_break は 38 のまま、verb_break は 0 のまま

（particle_start は 2026-08-14 の提案 4 型で 9 になった。下の表）。

`char_limit` が 1 件だけ増えた。 2ヶ月ぐらいかかってんねん（12.5 字 / ショート上限 10）に

切れ目候補が 1 つも立たない（breakPoints.ts の助詞表に ぐらい が無く、月｜ぐらい は

漢字→ひらがなとして字種の段から外れ、かかっ｜て は促音便の禁則）。

正本 §4「幅を超えるほうが、語を割るよりよい」に従えばこの 12.5 字の行のほうが正しい

（それまでは 月ぐら｜い と語を割っていた）。検出器の過検出ではない。

禁則は族ごと塞がないと、同じ語の中で 1 字ずれるだけになる。 11 周目にラ行を

る/れ だけで塞いだら やら｜れてる が や｜られてる へ、

プロダクションや｜ろう が プロダクショ｜ンやろう 側へ動いた。ら/ろ も同時に入れて解消した。

提案 7 型のうち 4 型を入れた（2026-08-14。浅尾承認）。送り仮名は入れない。

残りは dev/knowledge/recall-rounds-20260813.json の remaining.proposals。

出荷される SRT はこうなった（本番経路 scripts/build-master-srt.mts / 全 13 Part。

SRT と 1 バイト一致を照合してから数えた）。

規則違反を 231 箇所ぶん直して、検出される error は 5 件減った。

particle_start の −7 は連語の頭の に を格助詞と数えていた過検出

（〜｜に対しての不満ってさ）。+1 は のみで の位置が動いたもので、これも

のみ を副助詞として扱って解消した。

送り仮名は仕分けが済んだ。入れてはいけない。 「漢字→ひらがなの境目 231 箇所が未仕分け」

としてあったものを 12 周目の出力（162 箇所）で等間隔に 20 件読んだところ、

興行収入｜ありきで かませ犬｜みたいな 生活｜できひんねんな のように全部が名詞＋別の語だった。

生成側は findBreakPoints の字種の段でも syllableBreakPoints でも漢字→ひらがなを外しており、

この型は既に塞がっている。残る 162 箇所は助詞・文節・語頭の段から立った合法な切れ目である。

`て形＋補助動詞` は浅尾の判断で決着した（2026-08-14）。

補助動詞は基本切りたくないな。完全にどうしても切れない場合だよ。

正本 L1-09 §2 が「独立した語（くれる もらう いただく ある くる）なら切ってよい」と

書いていたのを取り消し、音節改行と同じ「最後の手段」（罰点 90）にした。

名指しの有無で分けていた 341 件の区別は要らなくなる。

`で` は て形のときだけ。 撥音便（死んで）とイ音便（急いで）だけが て形で、

格助詞の で は違う。緩めた版を測ったら違反 22 件のうち 7 件が全部この過検出だった

（に一発で｜いくとい な感じで｜いきまし 最後まで｜いけねえ はどれも本動詞の 行く）。

擬態語は表どうしが矛盾している。 ATOMIC_KATAKANA は擬態語（ギリギリ ノロノロ

ネチョネチョ）を「繰り返しに意味があるので割らない」として入れているのに（2026-08-07）、

repetitionSeams は同語反復を「割ってよい継ぎ目」として免除する（2026-08-12）。どちらが正か。

どれも規則を変えたのではなく、規則が要求する候補が無かっただけ。

継ぎ目を登録した語は、辞書の語でもそこで割れる。 これは新しい例外ではなく

breakPoints.ts が最初から持っている規則で、パラノーマル\|アクティビティ

ブレアウィッチ\|プロジェクト は前からこう振る舞う。上書きしてよいのは

継ぎ目の語が保護範囲そのものと一致するときだけで、じゃんけんデス\|ゲーム

（内側の デス＋ゲーム の継ぎ目）は依然として違反である。

2026-08-11 に残っていた 4 件。改行・カット・音節改行のどれでも解けなかった。

（すべてショート 10 字幅。2026-08-12 現在は 0 件）

共通の形は「7〜9 字の 1 語＋語尾」で、語の直後が行頭禁則の字か助詞。

この 4 件は改行では解けなかった。残る手は縮約（L1-10）で語尾を落とすことで、

縮約は本文を変えるので、字幕フォーマットの側で勝手に決めない。

⚠️ 「候補に入っているか」だけでは足りない。 指標は罰点モデルと同じ判定を使うので、

モデル側の取り違えは合法と数えられる。関係な|い は 100% の中に隠れていて、

実物を目で見て初めて見つかった。 数値を通したうえで、全長から等間隔に 20 件ほど抜き出して読む。

実測（ディレクターズ葛藤 全 13 Part / 18,363 キュー / 2 行 6,840 件）: 99.91%、行数超過 0。

配線前の出荷済み字幕は 19〜25% だった。

1 行の文字数はプロジェクト設定のパラメータ（6 以上。§1）。 下は

katto-shorts（ディレクターズ葛藤）の設定値で、固定値ではない。

この案件では 10 字 × 最大 2 行（浅尾確定 2026-08-07）。

かつてここには「本書 10 字 / 実装 13 字」の食い違いが残っていたが、

実装（lib/subtitle/thresholds.ts の KATTO_SHORTS_JA）は 2026-08-07 に 10 字へそろえてある。

設定値と実装が一致している。

13 字の根拠だった「手仕上げ Part10 の行長 p95=13 / max=17」は

機械の折り返し幅（1 行目が常に上限値）で、人の判断ではなかった。

10 字に絞ると手仕事版の約 3 分の 1 の行が組み直しになりキュー数は増えるが、正本を採る。

CPS 上限 12 も実測で決めた。10 では浅尾自身の手仕事の 17.8% が違反する（12 なら 3.6%）。

実測 p90=11.08 / p95=11.69。測り方は scripts/measure-human-cps.mts。

数値を動かすと rulesHash が変わり、生成済みのプランと spec は作り直しになる。

• Netflix 日本語 Timed Text スタイルガイド
• AVTpro 日本語字幕スタイルガイド (2024-03-20)
• NHK / 民放慣行（田村幸彦 1931 由来）
• 学術: 古後・岸 (1996), Sasaki (2017)
• 参照: [03_japanese_typography.md](03_japanese_typography.md), [05_transcription_pipeline.md](05_transcription_pipeline.md)

最小表示時間は 0.4 秒を採る。全体の既定 500ms からの上書きで、このマニュアルがそれを認可する。

根拠（浅尾確定 2026-08-18）: Part1 の実測で 本編 5 件・ショート 16 件が 0.5 秒未満、最小 0.196 秒。

0.5 のままだと、次の発話に押されて規則を守れない箇所が残る。**守れない規則を掲げるより、

守れる値へ下げて違反を実数で数えられるようにする。**

CPS 上限は 18 を採る。上の業界目安（8/10）からの上書きで、このマニュアルがそれを認可する。

根拠（浅尾確定 2026-08-18）: 本編で実測した。Part1 本文 10,422 字、上限超過 28 件の分布は

12.1〜17.3 / 中央 14.0。いちばん速いのは ワンシチュエーション の 10 字 0.58 秒 = 17.3 字/秒で、

28 件すべて 12 字以下の短いキュー。発話がそこだけ速いという素材の事実で、縮約では減らない

（文字が少ないので削る余地が無い）。

閾値を上げても出力は 1 バイトも変わらない。12 / 14 / 15 / 16 / 18 の 5 通りで SRT の長さが

31,122 / 37,541 のまま同一だった。本編の経路では検証の閾値としてしか使われない。

測る順序に注意。時刻を按分から実測へ直したあとで測ること。按分のままだと分母が水増しされ、

違反が甘い方向に隠れる（実測 2026-08-17: 同じ Part1 で reading_speed が按分 20 件 / 実測 28 件、

CPS の最大が按分 32.0 / 実測 17.3。32.0 は 4 字を 0.125 秒に押し込んだ按分の産物で、素材の速さではない）。

この節の表は `lib/rules/registry.ts` から生成される。手で書き換えると `yarn rules:docs --check` が落ちる。

値を変えるときは実定数を変え、yarn rules:docs で吐き直す。

全体の既定から外す場合は、このマニュアルに根拠を書いてから authorizedBy を埋める（正本 §7）。

<!-- generated:rules:subtitle-shorts-ja -->

字幕（ショート・日本語 / `SHORTS_JA_DEFAULT`） — この表は lib/rules/registry.ts から生成される。手で書き換えない（yarn rules:docs）。

• maxCharsPerLine: 正本は範囲を持つ。10 は葛藤ショートの既定値
• cpsMax: 業界の目安（8/10）は劇映画・ロング向け。この案件は実測で 18 を採る
• minDuration: 守れない規則を掲げるより、守れる値へ下げて違反を実数で数える

<!-- /generated:rules:subtitle-shorts-ja -->

Netflix / BBC / TED / EBU 基準に準拠した英語字幕の共通ルール。

Best practice: 可能なら 1 行に収める。2 行にする場合は bottom-heavy pyramid（上短・下長）。

WPM 換算:

• BBC: 一般 160〜180 WPM / 成人 250 WPM
• 180 WPM ≈ 15 CPS

字幕間ギャップ (Netflix, 24fps):

• 最小 2 フレーム / 3〜11 フレームは禁止（2F に詰める） / 12F (0.5s) 以上は OK

• 句読点の後（period, comma, semicolon）
• 接続詞の 前（and, but, or, so, yet）
• 前置詞の 前（at, by, for, from, in, of, on, to, with）
• 自然な節境界
• 発話の自然な区切り

• 冠詞（a, an, the）の後
• 冠詞と名詞の間
• 形容詞と名詞の間
• 動詞と主語の間
• 動詞と助動詞の間
• 代名詞と動詞の間
• 所有代名詞の後
• 人名（first / last の間）

• "linguistic wholes" を保つ
• 2 行は可能な限り視覚的バランスを取る

• 通常の文 = Sentence case
• 固有名詞・人名・地名 = 大文字
• Netflix: "Black", "Deaf", "Indigenous" は人種・属性を指すとき大文字
• ALL CAPS は禁止（強制的な画面テキスト等の例外を除く）

• 米: "..."、内側 '...'、ピリオド・カンマは閉じ引用符の内側
• 英: '...'、内側 "..."

Netflix 規則:

• ブラケットは 小文字（固有名詞は除く）
• 名前を優先。不明話者は [man], [woman on phone], [man 1] [man 2]

含めるもの:

• 全対話
• 話者識別（明らかでないとき）
• 意味のある効果音
• 音楽説明 / 歌詞
• トーン（皮肉・叫び等、文脈に必要なとき）
• オフスクリーン音
• 重要な沈黙

書式:

• 効果音: [door slams], [phone ringing]
• 音楽: [suspenseful music playing] または ♪ *Lyrics here* ♪
• トーン: [sarcastically], [whispering]
• 沈黙: [silence], [long pause]

イタリック化する:

• ナレーション・ボイスオーバー
• 内心独白
• 歌詞
• 電話 / TV / ラジオ / AI の声（話者が見えないとき）
• 作品タイトル（書籍・映画・番組・新聞）
• 馴染みのない外国語
• 強調（句読点で足りないとき）

しない:

• 話者ブラケット [John]
• 効果音ブラケット [door slams]
• 辞書登録済み外来語（rendezvous, café, déjà vu）

Note: Netflix の言語ガイドの 25% 以上（韓・中・希・印・尼・タイ）は イタリック非推奨。

• フォント: Arial, Helvetica, Verdana 系 sans-serif、白文字+黒縁
• 配置: 画面下部・中央揃え
• TTML: ピクセル値禁止、% 指定のみ

• Netflix Timed Text Style Guide (English)
• BBC Subtitle Guidelines v1.2.3 (2024-06)
• TED Subtitle Guidelines
• ISO/IEC 20071-23:2018
• EBU Tech 3264 (EBU-STL)
• Code of Good Subtitling Practice (Ivarsson & Carroll, 1998)

字幕中の文字種・句読点・数字・記号の扱い。フォーマット規則は [01_subtitle_format_jp.md](01_subtitle_format_jp.md) を参照。

理由: 句読点は「テキストを読んでいる」感覚を生み、字幕の理想（直接発話を聞いている錯覚）を破る。

• バリアフリー字幕（SDH）では使用可
• 書面引用・画面内テキスト翻訳では使用可

• 漢字 20〜30% : ひらがな 70% : カタカナ 0〜10%
• 別ガイド: 6:3:1（ひらがな:漢字:カタカナ）

• 常用漢字のみ 使用
• 一般に読めない難しい漢字は避ける
• 参考: NHK「新用語辞典」/「ことばのハンドブック」、共同通信「記者ハンドブック」、朝日「用語の手引き」

• 助動詞
• 副詞
• 抽象名詞:
• 時 → とき
• 事 → こと
• 物 → もの
• 為 → ため

映画字幕では原則使用しない。

• 混乱を招く読み（曖昧な漢字読み）
• 固有名詞（珍しい読みの人名・地名）
• 専門用語（発音ガイダンスが必要）

• 対象視聴者の読解レベルに応じて使用可
• 学習補助としても機能

字幕プロジェクト全体で一貫させる:

→ 辞書管理は各プロジェクトの DICTIONARY.md で行う（雛形 _project_template/ はこのリポジトリへは未移植）。

• Netflix 日本語 Timed Text スタイルガイド
• NHK ことばのハンドブック
• 共同通信 記者ハンドブック
• 日本字幕業界慣行（1931 田村幸彦以降）

言語ペアを問わず適用する翻訳の基本原則。トーク番組・ドキュメンタリー・字幕翻訳すべての共通土台。 映画 / ドラマ特有のキャラクター訳・ジャンル別スタイルは [04b_film_translation_subs.md](04b_film_translation_subs.md) を参照。

• 簡潔性 (Brevity): 限られた文字数で本質を伝える
• 自然性 (Naturalness): 翻訳臭のない自然な表現
• 等価性 (Equivalence): 原文の意図・感情・トーンを等価に再現

• 冗長表現を削除（「〜という風に」→「〜と」、「させていただいております」→「しております」、「っていうところ」→「って」）
• 自明な情報を省略（視覚で分かる情報、文脈で明らかな主語）
• 修飾語を簡略化
• 複文を単文に分割

原文: "I really, really need you to understand that this is extremely important."
直訳: 「本当に本当に これが極めて重要であることを理解してほしいんだ」
凝縮: 「頼む これは本当に重要なんだ」

1. 同等概念あり → 置換
2. 説明なしで理解可能 → そのまま
3. 文脈で推測可能 → 軽い補足
4. 理解不能 → 意訳 or 注釈（最終手段）

例:

原文: "She threw a baby shower."
処理: 「出産祝いのパーティーを開いた」（日本では馴染みが薄いため説明的に）

• 主語省略: 文脈で明らかなら省略（"I went... I bought... I came home." → 「店に行って牛乳を買って帰った」）
• 時制: 厳密でなくて良い。現在形で済むなら現在形
• 受動 → 能動: 推奨（「ジョンがドアを開けた」）

• 省略主語の補完: 英語では明示が必須
• 敬語: フォーマルな語彙選択 / "sir", "ma'am"
• オノマトペ: 「ドキドキする」→ "My heart is pounding" / 「シーン」→ [silence]

• [ ] 文字数が制限内（日: 13/行、英: 42/行）
• [ ] CPS 適切（日: 4、英: 20）
• [ ] 表示時間 0.833〜7秒
• [ ] 改行位置が自然

• [ ] 原文の意味が正確
• [ ] 自然な日本語/英語
• [ ] 感情・ニュアンスが保持
• [ ] 文化的誤解がない

• [ ] 専門用語が統一
• [ ] 固有名詞処理が統一

→ 用語統一は各プロジェクトの DICTIONARY.md で管理。

→ キャラクター口調・ジャンル別スタイル（映画/ドラマ用）は [04b_film_translation_subs.md](04b_film_translation_subs.md) を参照。

• Netflix Timed Text Style Guide (各言語)
• TED Translators Wiki
• 学術: 通訳翻訳研究 (JAITS), Sasaki (2017)

適用範囲: 劇映画・ドラマ・アニメの字幕翻訳。 トークドキュメンタリー / 教育動画 / SNS ショートには通常 適用しない（必要に応じて部分的に参照）。 汎用の翻訳原則は [04_translation_principles.md](04_translation_principles.md) を参照。

• 敬語: 〜です / ます、〜でございます、〜ですわ（お嬢様）、〜ですの（軽め）
• カジュアル: 〜だ / だよ、〜よ / わ（女性）、〜だぜ / ぞ、〜じゃん / っしょ（若者）、〜っす（体育会系）
• 特殊: 〜じゃ（老人・博士）、〜のだ（解説・中二病）、〜でござる（侍）、〜なのです（丁寧な解説）、〜にゃ / 〜なの（萌え系）

• [ ] 一人称が統一されている
• [ ] 二人称が関係性に適切
• [ ] 語尾パターンが一貫
• [ ] 感情変化時の口調変化が自然
• [ ] 敬語/タメ口の使い分けが適切

• テンポ重視（長い字幕は避ける）
• ボケとツッコミのタイミングを逃さない
• 言葉遊びは等価効果を追求

NG:

• 説明的すぎる翻訳
• ジョークの解説
• 笑いのピークを過ぎた字幕表示

• 緊張感を維持する短い文
• 情報の出し方に注意（ネタバレ厳禁）
• 不穏な雰囲気を言葉で演出

原文: "Someone is watching."
標準:    「誰かが見ている」
サスペンス調: 「…見られている」

• 感情表現を豊かに
• 詩的な美しさを保持
• 過剰にならない自然さ
• "I love you" → 状況に応じて「好きだ」「愛してる」を使い分け

• 短く、インパクトのある表現
• 一言で状況を伝える
• 叫び声は視覚効果と調和

原文: "Get down! They're shooting at us!"
字幕: 「伏せろ！」（状況は視覚で伝わる）

• 専門用語・造語の統一
• 世界観を損なわない表現
• 用語集（DICTIONARY.md）の徹底管理

• 不気味な雰囲気を文体で演出
• 曖昧さを残す（説明しすぎない）
• 静寂の効果を活かす

テクニック:

• 体言止め: 「…誰かが、いる」
• 省略: 「まさか…」
• 不自然な間: 文を短く区切る

注意: 流行語は陳腐化が早い。作品の時代設定に合わせる。

字幕翻訳の品質チェック（映画/ドラマ用）:

• [ ] キャラクターの口調が一貫しているか
• [ ] 感情変化時の口調変化が自然か
• [ ] ジョークのタイミングが適切か
• [ ] ネタバレになっていないか
• [ ] 視覚情報と矛盾していないか
• [ ] 音楽・SE との調和が取れているか

• 劇映画字幕（特に翻訳作業）
• ドラマ字幕
• アニメ字幕

• 実在人物のトーク番組（出演者は本人なので口調は変えない）
• ドキュメンタリー（証言は元発話を尊重）
• 教育動画 / 講演（中立的なナレーション）
• SNS ショート（短すぎてキャラ口調が意味を持たない）

→ これらは [04_translation_principles.md](04_translation_principles.md) のみで足りる。

音声書き起こし（ElevenLabs / Whisper 等）から放送品質 SRT までの汎用パイプライン。 プロジェクト固有のスクリプトパスや辞書は各プロジェクトの LOCAL_PATHS.md / DICTIONARY.md を参照。

各段に機械で測れる合格条件を置く。 散文で守るのではなく、通らなければ止める。

実装は scripts/ 配下。既定は DRY RUN で、--go で書き込む。

ElevenLabs は時刻を潰すことがある。 何十文字もが同じ時刻に貼り付き、

時間情報がまったく無い範囲が出る。しかもその本文は数秒後に正しい時刻で再出力される。

これを直さずに先へ進むと、二重の本文と使えない時刻が全段に流れる。

直すのは生データの段で。 補正済みファイルでは潰れた文字が 1 語へ連結され、

重複した部分と固有の部分が同じ塊に混ざって境界が取れなくなる。

見つけ方と直し方は L1-08 §「時刻の潰れ」を参照。

直した件数は品質を表さない。 2 つを別に測る。

precision（直したもののうち正しかった割合）

適用した修正から無作為に 20〜30 件抜き、独立な根拠で 1 件ずつ検証する。根拠は別系統の ASR、校正済み字幕、クレジット、キャスト表、脚本。実測では提案 160 件のうち 5 件（3%）が「原文が正しく、提案が誤り」だった。 precision を測らないと、この 3% が全長へ広がる。

recall（残っている誤りのうち見つけた割合）

無作為に区間（合計 3,000 字程度）を抜き、独立な系統でもう一度誤りを探し、1 回目が見落とした数を数える。recall を測っていないなら「校正できた」と言わない。

系統間の不一致率が残存誤りの上限。 同じ音源の書き起こしが複数あるなら、全系統が一致する箇所は実発話とみなせる。割れている箇所の割合が、まだ残っている誤りの上限になる。これは全長に対して機械的に出せるので、抜き取りより強い。

ASR JSON (character-level)
    ↓ ① セマンティック分割
  gap 境界でチャンキング
  → 意味単位の自然な切り位置を保証
    ↓ ② 固有名詞補正
  プロジェクト辞書を適用
  人名表記揺れ / 業界用語の統一
    ↓ ③ 話者ID付与
  speaker_N → 人物名マッピング
    ↓ ④ ブロック分割
  word-level タイムスタンプで
  5秒超 or 字数超ブロックを分割
    ↓ ⑤ ブロック結合
  同一話者・短ギャップ・合計上限以下 → 結合
    ↓ ⑥ カット点参照分割
  編集カット点でさらに細分割
    ↓ ⑦ 時刻補正
  短テキスト長尺ブロックの開始時刻を補正
    ↓ ⑧ 出力整形
  極短(<300ms)ブロックを前ブロックに吸収
  smart_linebreak（行字数 × 最大2行）
  話者ラベル除去（出力ポリシーに応じて）
  余韻 +0.5秒（次ブロックが来るならそちら優先。L1-01 §3）
    ↓
  output.srt + review.md

→ プロジェクト側で文字数上限など上書き可（例: Katto 本編 = 26字, ショート = 20字）。

各プロジェクトの DICTIONARY.md に記載された:

• 誤変換 → 正表記マッピング
• カタカナ ⇄ ひらがな統一
• 作品名・人名・業界用語の正式形

を 全置換 で適用。

辞書更新は 処理のたびに育てる こと（[06_quality_review_workflow.md](06_quality_review_workflow.md) 参照）。

• 最新版: <name>_claude.srt（常にこのファイル名が最新）
• 退避: <name>_<日付>_claude.srt にリネームして _archive/ へ

レビューファイルに以下を記録:

ルールベースでは検出できない 言語としての自然さ を AI で修正。

• 噛み・繰り返し（「８月８月25日」→「８月25日」）
• 数字補完（「４月１から」→「４月１日から」）
• 単語分断（活用が改行を跨ぐ）
• 不自然なスペース（語句途中のスペース）
• STT アーティファクト（意味不明な英語断片）
• 冗長表現の圧縮（CPS 過大エントリ）

• Haiku: コスト効率重視（バルク処理向け）
• Sonnet / Opus: 重要パートのみ

ASR がブロック全体を長い単一セグメントとして認識し、かつ:

• JSON 単語タイムスタンプも該当区間に存在しない
• カット点も無い

→ 分割根拠なし。スロー発話 / 沈黙区間として許容。

文章を時間比例で分割する副作用（形態素境界と一致しない）。

DaVinci カット点 / セマンティック gap で補正するが限界あり。

ASR が word-level / character-level JSON を出さないケース（短尺ショート等）は、SRT 単独依存となり長いブロックが残りやすい。

→ 検証手順は [06_quality_review_workflow.md](06_quality_review_workflow.md) 参照。

パイプライン出力後の検証フロー。validator → AI レビュー → 再検証 の 4 ステップ。

「実測」「完成版」と呼ばれているデータが、実は機械の出力であることがある。

そこへ寄せると品質が上がったように見えて、機械の癖を再現しているだけになる。

どれかが当たれば教師データではない。

完成ショートの 2 行キュー 142 件は 73% が `ceil(n/2)` ちょうど、

本編 2,624 件は 1 行目が常に 13 字（2 行目が 1 文字のものまである）。

めちゃめ|ちゃ『タ|イミング』ご飯食べ|ましょう と語が割れており、どちらも人の改行ではなかった。

さらに悪いことに、過去のセッションが同じ罠にはまった結論をコードのコメントに残していた——

「熟語・送り仮名・数字＋助数詞を割らない」を入れたら一致率が 97% → 95% へ落ちたので外した、と。

一致率を上げるほど機械的になる指標だったので、指標ごと捨てた。

正本（本マニュアル）を根拠にし、測るのは「規則違反の数」に切り替える。

「人と同じか」ではなく「規則上ゆるされる位置か」なら教師データ無しで測れる。

実装は scripts/check-line-breaks.mts。

Step 1: パイプラインで SRT 生成（機械処理）
Step 2: validator で 0 errors を確認
Step 3: Claude AI レビューで日本語/英語品質を修正
Step 4: validator 再確認 → 0 errors で完了

→ [05_transcription_pipeline.md](05_transcription_pipeline.md) のフローを実行。

プロジェクト固有のコマンドは各プロジェクトの LOCAL_PATHS.md を参照。

Part1: 0ms=0 <300ms=0 行>13=0 5s+=0 ラベル=0  ✅

errors があれば Step 1 のスクリプトを修正して再生成。SRT を直接いじらない（次回パイプライン実行で消える）。

Python では検出できない 言語としての自然さ を LLM が直接チェック・修正。

50 エントリずつ SRT を読み、Edit ツールで直接修正。

Step 2 と同じ validator を実行し、0 errors を確認して完了。

[05_transcription_pipeline.md](05_transcription_pipeline.md) §5 のフラグを参照。

• ルールベース検出セクション（✂️ 切り位置 / 🗣 話者交代）は 上書き（重複しない）
• AI レビュー（🤖）も上書き
• 手書きの修正メモは別セクションを設けて保存

→ 大量処理は Haiku、品質重視は Sonnet 以上を使い分け。

処理のたびに辞書を育てる。

• 新しい固有名詞・表記揺れ・誤変換パターンを発見したら即追加

• 新固有名詞: プロジェクトの DICTIONARY.md の適切なカテゴリに行追加
• 新誤変換パターン: 誤変換テーブルに行追加
• ファイル末尾の 最終更新: 日付を更新

SRT 生成中に以下を発見したら、処理完了後に 自動で `DICTIONARY.md` を更新 する:

• 辞書にない人名・作品名・組織名・専門用語
• ASR が繰り返し誤変換しているパターン
• 初登場のエピソード固有用語

ElevenLabs Scribe API を使った音声 → SRT / JSON 書き起こしの汎用フロー。 全プロジェクト共通の入り口。プロジェクト固有のパス・パラメータは各プロジェクトの PROJECT_RESOURCES.md を参照。

• 環境変数: ELEVENLABS_API_KEY（User scope）
• 参照方法:
• PowerShell: $env:ELEVENLABS_API_KEY
• Python: os.environ["ELEVENLABS_API_KEY"]
• Node.js: process.env.ELEVENLABS_API_KEY
• 再設定（漏洩時 or 新キー発行時）:

```powershell

[System.Environment]::SetEnvironmentVariable("ELEVENLABS_API_KEY", "<new-key>", "User")

```

→ ターミナルから直接実行。チャットに値を貼らない。

→ 通常は scribe_v1 を使う。

音声ファイル (mp3 / wav / m4a / mp4 / webm)
        ↓
   ① ElevenLabs Scribe API 呼び出し
   - model: scribe_v1
   - diarize: true（話者分離）
   - timestamps_granularity: word（or character）
   - tag_audio_events: false（無音/笑い等のタグ）
        ↓
   ② レスポンス取得
   - text: 全テキスト
   - words[]: 単語ごとのタイムスタンプ + speaker_id
   - language_code, language_probability
        ↓
   ③ JSON 保存（後段パイプラインの正規ソース）
   ↓ <name>_書き起こし_<date>.json
        ↓
   ④ SRT 生成（必要なら）
   - 単純: 一定区切りで改行
   - 推奨: semantic_srt パイプライン経由
       （詳細: 05_transcription_pipeline.md）
        ↓
   ⑤ 多面修正パス
   → 08_multipass_correction.md

import os
import requests
import json
from pathlib import Path

API_KEY = os.environ["ELEVENLABS_API_KEY"]
ENDPOINT = "https://api.elevenlabs.io/v1/speech-to-text"

def transcribe(audio_path: Path, language: str = "ja", num_speakers: int = 3) -> dict:
    with open(audio_path, "rb") as f:
        files = {"file": (audio_path.name, f)}
        data = {
            "model_id": "scribe_v1",
            "language_code": language,
            "diarize": "true",
            "num_speakers": str(num_speakers),
            "timestamps_granularity": "character",
        }
        headers = {"xi-api-key": API_KEY}
        r = requests.post(ENDPOINT, headers=headers, files=files, data=data, timeout=600)
        r.raise_for_status()
        return r.json()

if __name__ == "__main__":
    import sys
    audio = Path(sys.argv[1])
    result = transcribe(audio)
    out = audio.with_suffix(".json")
    out.write_text(json.dumps(result, ensure_ascii=False, indent=2), encoding="utf-8")
    print(f"Wrote: {out}")

import fs from "node:fs";
import path from "node:path";

const API_KEY = process.env.ELEVENLABS_API_KEY;
const ENDPOINT = "https://api.elevenlabs.io/v1/speech-to-text";

export async function transcribe(audioPath, { language = "ja", numSpeakers = 3 } = {}) {
  const form = new FormData();
  form.append("file", new Blob([fs.readFileSync(audioPath)]), path.basename(audioPath));
  form.append("model_id", "scribe_v1");
  form.append("language_code", language);
  form.append("diarize", "true");
  form.append("num_speakers", String(numSpeakers));
  form.append("timestamps_granularity", "character");

  const res = await fetch(ENDPOINT, {
    method: "POST",
    headers: { "xi-api-key": API_KEY },
    body: form,
  });
  if (!res.ok) throw new Error(`ElevenLabs API ${res.status}: ${await res.text()}`);
  return res.json();
}

{
  "language_code": "ja",
  "language_probability": 0.99,
  "text": "全テキスト...",
  "words": [
    {
      "text": "こんにちは",
      "start": 0.12,
      "end": 0.48,
      "type": "word",
      "speaker_id": "speaker_0",
      "characters": [
        { "text": "こ", "start": 0.12, "end": 0.18 },
        { "text": "ん", "start": 0.18, "end": 0.24 },
        ...
      ]
    },
    ...
  ]
}

• Scribe: 約 $0.40 / 時間（2026 時点）
• 60 分番組 1 本 ≈ $0.40
• 月 20 本書き起こし ≈ $8

10 分超の音声は API timeout のリスクがあるため、推奨はチャンク分割:

# ffmpeg で 10 分ごとに分割
ffmpeg -i input.mp3 -f segment -segment_time 600 -c copy chunk_%03d.mp3

分割後、各チャンクの words[].start にオフセット（チャンク番号 × 600 秒）を足してマージ。

→ プロジェクトの DICTIONARY.md § ASR 誤変換パターン に追記して育てる。

代表的な誤り（日本語）:

→ 多面修正パスで一括除去（[08_multipass_correction.md](08_multipass_correction.md)）。

ASR の `speaker_N` を入力にしない。話者はマイクから決める。

ダイアライゼーションは同じ人を複数ラベルに割り、無音や被りを別人として立て、

被りの少ない人をいちばん取りこぼす。

実測 2026-08-12（ディレクターズ葛藤、全 12 Part / 語 20,559 件）:

Fujii のラベリアは他マイクとの相関が 0.17〜0.29（Asao↔Nabe は 0.63〜0.81）。

席が離れて被りが無い。被りで人を分ける方式は、被りの無い人を落とす。

ラベリアが鳴っていれば本人なので、マイクから決めればこの失敗は原理的に消える。

• 識別 — どのファイルが誰のマイクか。置き場が人名なら known（Audio/Asao/…）。

機材名の置き場（Audio/Wireless1/…）は unknown のまま残す。人名へ寄せない

• 同期 — 本編の時刻 → 生マイクの時刻。推定し直さず、区間写像を読む

（Final/Audio/_partmix/<Part>_mix_source.json の editMap.placements[].intervals[]）。

原点を 0 と決め打たない。 書き出しの開始 TC（Part9〜12 は 01:00:00:00）と、

本編音・字幕の版ずれが乗る。軸のずれは測る。検算は 3 点以上（グローバル正本 L4）

• 割り当て — 語ごとに全マイクの SNR（自分の暗騒音からの上げ幅）を比べ、首位を採る。

マイクごとにゲインが違うので、生のレベルで比べない

• 確定 — 一致率 70% 以上かつ票 5 以上
• 誤検出 — 測れているのに首位が立たない / 票が複数のマイクへ割れる。人名へ寄せない
• 未確定 — 測れた語が少なすぎる。誤検出とは別物として残す
• 同じマイクへ確定した speaker_N が複数あれば統合する

差が小さいものを黙って 1 位へ落とさない。

最尤は入れてよいが、1 位と 2 位の差（dB）と絶対レベルを添えて印を付ける。

下流（ショートのアングル確定など）が自分で判断できるようにする。

「既定のアングルに落とさない」は「印を付けずに落とすな」の意味。

Part ごとに: 軸のずれと検算した点数 / 同期の検算 / 語の確定率 / 一致率（ASR との突き合わせ） /

precision と recall を別に / 拾えた秒（引き算ではなく区間の集合差） /

確定できなかったものを理由別に。

画面に映らない声（ディレクターなど）は話者として立てつつ、

表示は （カッコ）付きにする。話者数を音声だけで決めない（本編の静止画で人数を目で確かめる）。

この表はプロジェクトと Part の二層で持つ。ゲストが変わる案件があるので、

手動登録の口を必ず用意する。

音は名前を出せない。 マイクから保証できるのは「同じ人が同じマイク」までで、

Audio/Wireless1/ や Audio/TX_MIC001_20250217_025120/ のような機材名の置き場には

外から名前を入れるしかない。 探す順（強い順）と、実測で分かったこと。

`.drt` / `.drp` に話者名テロップは無い。 ディレクターズ葛藤.drp（306 エントリ）に

StyledText は 0 件で、Part9〜12 の Master の映像段にも話者名の段が無かった。

lib/nle/layout/service.ts の 'V8 - 話者名' はこれから組む本番タイムラインの設計であって、

人手の完成品には存在しない。焼かれた映像から読む。

送信機番号（`TX01` / `TX02` / `TX03`）をセッションをまたいで運ばない。

260215 は Audio/Asao=TX01 / Audio/Fujii=TX02 / Audio/Nabe=TX03 だが、

260411 でこの対応は成立しない（TX02 のカードが Asao、TX01 が Nabe）。

機材の通し番号を人の同一性として使うと逆の答えが出る。

置き場が人名の Part1〜8 は正解が分かるので、同じ手順を当てて precision を測れる。

外れた 2 件はどちらも「あさおです」というテキストで、実測は Nabe だった。

**自己紹介は 3 人が 1 秒ずつ続けて言うので、キューの区切りが崩れると 1 つのキューが

2 人ぶん・3 人ぶんを抱える**（Part4 #24 は 3.88 秒あり、同じ窓に Nabe / Fujii / Asao が入っていた）。

キューの長さを見ずにレベルだけ測ると、いちばん長く鳴っていた人が出てくる。

同じ人が 2 本のマイクに票を持つ、同じマイクに 2 人の票が入る場合は

多数決で潰さず、両方を残して確定にしない（decideFromIntroVotes が 1 対 1 を課す）。

Final/Audio/Part11.mp3（マスター字幕と 1 対 1。字幕の末尾 2503.62s / mp3 2503.97s）を

Final/Part11.mp4 へ相関で当てると、

で、字幕 1000〜1100s のどこかに 88.4 秒の段差がある（mp3 にあって映像に無い塊）。

台帳 speaker-confirmation-20260812.json は Part11 に単一の −44.3s を当てているので、

前半（字幕 0〜約 1020s）のマイク割り当ては 88.5 秒ずれている。

Part11 の ASR 一致率が全 Part 最低（0.39〜0.67）なのはこれで説明がつく。

`--verify` の 3 点検算は、3 点が同じ側に寄っていると段差を見逃す。

scripts/infer-speaker-names.mts は --astats のときだけこの区間に測り直した軸を当てる。

台帳側は直していない。

npx tsx scripts/confirm-speakers.mts --all          # 台帳と話者インデックスを作る
npx tsx scripts/confirm-speakers.mts --verify       # 別経路（ffmpeg astats）で標本を測り直す
npx tsx scripts/infer-speaker-names.mts             # 自己紹介から人名を引いて報告（書かない）
npx tsx scripts/infer-speaker-names.mts --astats    # 別経路（ffmpeg astats）で intro を測り直す
npx tsx scripts/infer-speaker-names.mts --write     # dev/knowledge/speaker-people.json を書く

出力は dev/speakers/<Part>.mic.json（framing_track() が読む形の上位互換）と、

台帳 dev/knowledge/speaker-confirmation-20260812.json、

人名の表 dev/knowledge/speaker-people.json。

マスター字幕は書き換えない。話者は別ファイルで持つ。

speaker-people.json は confirm-speakers.mts が --people で読む手動登録ファイルそのもの。

第一階層は note / project / parts だけにする（parseOverrides の ignoredKeys を空に保つ）。

各エントリは person / displayName / onScreen / note に加えて

`confidence`（`confirmed` = 2 系統以上が一致 / `estimated` = 1 系統）と `sources` と `evidence` を持つ。

sources に manual が入っているエントリは再生成で上書きしない（人が入れた印）。

• [05_transcription_pipeline.md](05_transcription_pipeline.md) — JSON → SRT 変換
• [08_multipass_correction.md](08_multipass_correction.md) — 多面一括修正
• [../L2_sns/15_shorts_composition_workflow.md](../L2_sns/15_shorts_composition_workflow.md) §6 — 話者とアングルの割り当て
• 各プロジェクトの PROJECT_RESOURCES.md — 音声ソース・出力先・話者数

ElevenLabs 書き起こし（JSON / SRT）に対して、1 パスで 6 種類の修正を一気に適用する統合フロー。 従来「ルール検出 → 人手修正 → AI 検出 → 人手修正」のループを 1 ステップに圧縮。

ASR は時刻を潰すことがある。 何十文字もが同じ時刻に貼り付き、時間情報がまったく無い

範囲が出る。しかもその本文は数秒後に正しい時刻で再出力される。これが「二重出力」の実体。

日本語の話速は 8 字以上の語で 中央 8.5 / p90 13.2 / p99 20.0 字/s。

潰れた語は 21〜833 字/s になる。20 字/s を超える語があれば潰れている。

音イベントのタグ（(笑い) (拍子木の音)）は発話ではないので長さから除く。

生データの段で直す。 補正済みでは潰れた文字が 1 語へ連結され、重複した部分と

固有の部分が同じ塊に混ざって境界が取れない。生なら幅ゼロの並びがそのまま境界になる。

範囲まるごとではなく文字ごとに、近傍 ±90 秒に再出力があるかを 12 文字の並びで見る。

• 大半（50% 以上）が覆われている範囲 → 端の削り残しごと落とす
• 覆われていない固有の内容 → 落とさず、前後の語のあいだへ時刻を等分で割り直す

端を残すと「それティッ一発で挟む。ヒ俺らもその感じ分かってま」のような読めない断片になる。

照合の前に約物を落とす。 句読点そのものが幅ゼロで出力されるので、時刻を持つ語だけを

集めた側には句読点が 1 つも残らない。素のまま突き合わせると、同じ本文でも一致率が

26% に見える。約物を外すと 90% になる。

• 時刻の巻き戻りを探す。 潰れは時計が止まるだけで戻らない（実測 0 箇所）
• 範囲をまるごと消す。 固有の内容が混ざる。落とす前に必ず再出力の有無を確かめる
• 機械的な言い直し除去。 畳語を壊す（そうそう→そう、いろいろ→いろ）

辞書は成果物ではなく、最初に作る道具。 新しい案件の辞書は空から始まる。

「辞書を当てたら誤変換が 100% 消えた」は同語反復で、品質を何も示さない

（その辞書は同じ書き起こしから作ったのだから消えて当然）。測るのは辞書の作り方の再現性。

1 件ずつ人に尋ねる前に、必ず 2〜4 を全部やる。 実測では残り 160 件のうち

123 件（77%）が制作資料だけで解けた。先に聞くのは相手の時間を捨てている。

• 同じ読みで表記が複数ある語（回をまたいで揺れているもの）
• 文脈上は人名・作品名・会社名のはずなのに、一般語として書かれている語
• 頻出するのに一般的でないカタカナ語
• ASR が音写に失敗した痕跡（不自然な漢字の並び、意味を成さない語）

同じ音源の書き起こしが複数あることを前提にする。 そして日本語の正式表記は、日本語の書類にしか無い。

2 と 3 を見ずに「資料に無い」と結論しない。 クレジットは英語で作ることが多いので、漢字は別の書類にしか無い。

生出力が同じ数分の中で同じ語を違う表記で書いているなら、それは辞書に入れるべき語。

実測例: 同一 3 分窓に「ウエスタン」と「ウェスタン」が混在していた。

候補収集（段 1）でこれを自動で洗い出す。 人の目に頼らない。

実測（13 回ぶん）: 別系統 ASR が 5 本、校正済み字幕が 8 本。Part9 以降は材料ゼロ。

材料が無い区間で confident を出す条件を先に決める。音と文脈だけで確定してよいのは、既知パターン表に載っている形と、資料で確定した語の別表記だけ。 新しい固有名詞を材料なしで confident にしない。

「直した件数」を混ぜて数えると水膨れする。実測の内訳は 資料で解ける固有名詞 23 / 発話どおり保持 5 / 表記統一の判断 9 / 数字 5 / 現場ネタ 5。

種類ごとに解決手段が違う。 固有名詞は資料、表記統一は案件の方針決定、数字は音、現場ネタは実物か人。混ぜると「音で粘る」を全部に当ててしまう。

1 回で作ろうとしない。 実測（同じ 36 分・同じ手順・独立 2 系統）:

1 回では半分しか拾えない。 ただし同じ語に違う答えを当てた例は 0 件だった。

割れているのは「拾ったか」であって「何と読んだか」ではない。だから和集合を取ってよい。

一致率が低いのは候補収集（段 1）の差。候補さえ挙がれば確定は再現する（矛盾 0 件がその証拠）。

ただし候補収集は機械化できない。 実測（scripts/term-candidates.mts）:

使えるスイートスポットが無い。 recall 82% を得るには 4,944 件を出すことになり、

98% がノイズ。それを読むのは書き起こしを全部読むのと同じ。

理由は 2 つ。固有名詞の大半は 1〜2 回しか出ない。 そして

メルカリ『フォード』インパラ は普通のカタカナ語と統計的に区別できず、

清水『東映』高円寺 は敬称の付かない漢字 2 字で一般語と同じ形をしている。

だから LLM のパスは置き換えられない。 検出器の役どころは「LLM の代わり」ではなく

「LLM が見落としたものを後から拾う網」。精度が出るのは次の 2 つだけ。

• 同一区間のカタカナ表記ゆれ（ウエスタン と ウェスタン が同じ 3 分に同居）
• 敬称つきの漢字列（さん / くん / 氏 が続く）

漢字列の頻度と 1 文字違いは使わない。貪欲に切ると動詞語幹が混ざり（映画作る → 映画作）、

漢字で 1 文字違いは別語（映画作『映画館』映画好 は変種ではない）。

再現性は N 回回して和集合を取ることで上げる。 機械化ではなく回数で稼ぐ。

ソウ（映画 Saw）は ひらがな「そう」に化けていた。一般語と同形になるので、頻度でも表記ゆれでも系統間比較でも引っかからない。

見つかったのは企画書の競合表と Part1 の画面の数字が一致したから（$1M → $102M ↔「1ミリオン…150億」）。

企画書・競合表・資料に出る数字と、本文の数字を突き合わせる段を入れる。 音では絶対に取れない語がここで取れる。

ここが品質のボラティリティの本体。 以下はすべて 2026-08-03 の実作業で実際に起きたもので、

仮定ではない。同じ入力・同じ正本でも、判断者が変われば結果が変わる箇所。

確定しない。 unresolved に落として人へ回す。

もっともらしい候補を confident に上げるのが、最も損害が大きい失敗

（後段の全工程がその誤りを前提に進む）。

• 固有名詞補正 — DICTIONARY.md の置換ルール適用
• 噛み・繰り返し除去 — 「８月８月25日」→「８月25日」
• 数字・日付の補完 — 「４月１から」→「４月１日から」
• 単語分断の修正 — 改行/エントリ跨ぎの活用形を結合
• 不自然なスペース除去 — 語句内の不要スペース
• STT アーティファクト除去 + 冗長表現の凝縮
• 意味不明な英語断片 → 削除 or 日本語化
• 「させていただいております」→「しております」
• 「っていうところ」→「って」

パス1: 固有名詞補正 (ルール) → 出力
パス2: 噛み除去 (AI) → 出力
パス3: 改行修正 (ルール) → 出力
パス4: 凝縮 (AI) → 出力
...

→ パスごとに差分レビュー / API コスト / 待ち時間が発生。コンテキストも分断される。

入力 SRT / JSON
    +
プロジェクト辞書 (DICTIONARY.md)
    +
ルール (L1-06 §Step3 の 6 項目)
    ↓
[Claude AI] 1 リクエストで 6 種類の修正を同時適用
    ↓
出力 SRT + review.md（修正ログ）

修正種別を タグ付き で記録するため、後から問題箇所を見分けられる。

あなたは映像字幕の校正専門家です。
以下の SRT ファイルに対して、6 種類の修正を **1 パスで** 同時適用してください。

## 修正種別

| タグ | 内容 |
|---|---|
| [DICT] | 固有名詞補正（辞書置換） |
| [REPEAT] | 噛み・繰り返し除去 |
| [DATE] | 数字・日付の補完 |
| [SPLIT] | 単語分断の修正（改行 / エントリ跨ぎ） |
| [SPACE] | 不自然なスペースの削除 |
| [TRIM] | STT アーティファクト除去 + 冗長表現の凝縮 |

## プロジェクト辞書

<DICTIONARY.md の内容を貼る>

## 制約

- 1 行: <プロジェクト規定値> 文字以下
- 行数: 最大 2 行
- 句読点: 不使用（プロジェクト規定に従う）
- CPS 上限: <値>
- 話者ラベル: <出力ポリシー>

## 入力 SRT

<対象 SRT の本文>

## 出力フォーマット

修正後の SRT を出力した後、修正ログを以下のフォーマットで出力:

| エントリ番号 | タグ | 修正前 | 修正後 | 理由 |
|---|---|---|---|---|
| 12 | [DICT] | 大金です | なべです | 自己紹介の誤変換 |
| 15 | [REPEAT] | ８月８月25日 | ８月25日 | 噛み |
| 23 | [SPLIT] | 撮りた／いよ | 撮りたいよ／みたいな | 活用が跨ぐ |