マニュアル

あらゆる日本語字幕の共通ルール。プロジェクト側で必要に応じて上書きする（例: Katto はショート 10文字に絞り込み）。

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

目安:

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

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

• 半角スペースの直後
• 格助詞（を / に / で / が / は / も / と）の 直後
• 接続助詞の 直前（けど / から / ので / たら）
• 連用形の 直後（〜して / 〜なので）
• 「て」「は」「も」「よ」の 直後（助詞直前は除く）

• 動詞活用の途中（撮り/たい、やっ/たら、して/きた、いただきた/いな）
• カタカナ複合語の途中（ワンシチュ/エーション）
• 格助詞が次行の 先頭 に来る位置
• 「ところ」「こと」「もの」等の途中
• 単語の途中（彼は毎日図 / 書館に通っている）

• 行の文字数は均等である必要なし。意味的完全性 > 視覚的バランス
• 上の行 ≦ 下の行（逆ピラミッド型を推奨）
• 2行目に短い助詞や1文字だけ残さない

• 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)

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 で行う（[20_projects/_project_template/](../20_projects/_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 を参照。

ASR JSON (character-level)
    ↓ ① セマンティック分割
  gap 境界でチャンキング
  → 意味単位の自然な切り位置を保証
    ↓ ② 固有名詞補正
  プロジェクト辞書を適用
  人名表記揺れ / 業界用語の統一
    ↓ ③ 話者ID付与
  speaker_N → 人物名マッピング
    ↓ ④ ブロック分割
  word-level タイムスタンプで
  5秒超 or 字数超ブロックを分割
    ↓ ⑤ ブロック結合
  同一話者・短ギャップ・合計上限以下 → 結合
    ↓ ⑥ カット点参照分割
  編集カット点でさらに細分割
    ↓ ⑦ 時刻補正
  短テキスト長尺ブロックの開始時刻を補正
    ↓ ⑧ 出力整形
  極短(<300ms)ブロックを前ブロックに吸収
  smart_linebreak（行字数 × 最大2行）
  話者ラベル除去（出力ポリシーに応じて）
  余韻 +300ms（次ブロック In-100ms でキャップ）
    ↓
  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 ステップ。

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)）。

• [05_transcription_pipeline.md](05_transcription_pipeline.md) — JSON → SRT 変換
• [08_multipass_correction.md](08_multipass_correction.md) — 多面一括修正
• 各プロジェクトの PROJECT_RESOURCES.md — 音声ソース・出力先・話者数

ElevenLabs 書き起こし（JSON / SRT）に対して、1 パスで 6 種類の修正を一気に適用する統合フロー。 従来「ルール検出 → 人手修正 → AI 検出 → 人手修正」のループを 1 ステップに圧縮。

• 固有名詞補正 — 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] | 撮りた／いよ | 撮りたいよ／みたいな | 活用が跨ぐ |

推奨: 第 1 パスは Haiku で全体を一気通貫 → 残った問題箇所だけ Sonnet で再パス。

1 リクエストに入れる SRT エントリ数の目安:

→ Context window を圧迫しないこと。辞書 + 制約 + 入力 + 出力 を全部入れて 50% 以下に収める。

複数 Part / Shorts を持つプロジェクトでは並列実行で時間短縮:

import asyncio
from anthropic import AsyncAnthropic

client = AsyncAnthropic()

async def correct_one(srt_path: Path, dict_text: str) -> str:
    # ...
    return corrected

async def main():
    parts = list(Path("Subtitles").glob("Part*_claude.srt"))
    dict_text = Path("Claude/DICTIONARY.md").read_text(encoding="utf-8")
    tasks = [correct_one(p, dict_text) for p in parts]
    results = await asyncio.gather(*tasks)
    # write back

# Part1 多面修正レビュー（2026-05-11）

## サマリ

| タグ | 件数 |
|---|---|
| [DICT] | 18 |
| [REPEAT] | 7 |
| [DATE] | 3 |
| [SPLIT] | 12 |
| [SPACE] | 5 |
| [TRIM] | 24 |
| **合計** | 69 |

## 詳細

| エントリ | タグ | 修正前 | 修正後 | 理由 |
|---|---|---|---|---|
| 12 | [DICT] | 大金です | なべです | 自己紹介の誤変換 |
| 15 | [REPEAT] | ８月８月25日 | ８月25日 | 噛み |
...

## 要人手確認

以下は AI が修正を保留した箇所（自動修正できなかった）:

- エントリ 47: 文脈不明な英語断片「porque」（削除? 残す?）
- エントリ 83: 5.8 秒の長尺ブロック（分割点が見つからない）

• [05_transcription_pipeline.md](05_transcription_pipeline.md) — パイプライン全体
• [06_quality_review_workflow.md](06_quality_review_workflow.md) — Step1-4 検証フロー
• [07_elevenlabs_workflow.md](07_elevenlabs_workflow.md) — 上流の書き起こし
• プロジェクト側 DICTIONARY.md — 辞書ソース

YouTube / Shorts / TikTok / Instagram / X / Podcast 各プラットフォームのタイトル・キャプション・配信ルール。

• 最強キーワードを 先頭 50 文字以内 に
• 高 CTR + 低 retention のクリックベイトは YouTube が penalty
• 英語は Title Case（主要語を大文字化）
• 数字 > スペルアウト（3 > Three）
• 末尾の (Full Story), (Ep. 1) は SEO 影響なしで文脈追加
• ALL CAPS は禁止（叫び扱い → CTR 低下）

[Hook Line — タイトルを膨らませる 1〜2 文]

[Episode summary — 3〜5 文]

[Key timestamps]
00:00 Intro
xx:xx [Chapter 1]
xx:xx [Chapter 2]

[Series context — チャンネル / ドキュメンタリーの位置づけ 1〜2 文]

[Links: next episode, playlist, social]

[Hashtags — 3〜5 個、末尾]

• 先頭 2〜3 行が "Show more" 上に出る。ここで決める
• プライマリーキーワードを最初の文に自然に
• 人間優先・アルゴリズムは二次（YouTube の NLP は semantic intent を読む）
• Episode 番号で位置付け（Ep. 1 | <Series>）
• CTA を入れる（subscribe / next episode）
• Hashtags は末尾に 3〜5 個。先頭 3 個がメタデータに入る

• 最適: 150〜300 ワード
• 100 ワード未満 = SEO 損
• 500 ワード超 = 深くインデックスされない（diminishing returns）

ワンクリアフック: 質問・断定・POV フォーマット。

例:

• POV: You're making a movie with no money
• The hardest part of writing a screenplay (nobody talks about this)
• We built a film crew from zero. Here's how.

• 先頭 1 行がフック（"more" 前に見える）
• 可視部分は 150 文字以内
• 改行で読みやすく
• 末尾は質問 or CTA でコメントを誘導
• Hashtags 4〜6 個（broad + niche + 作品名）

#filmmaking #indiefilm #lowbudgetfilm #moviemaking #behindthescenes
#filmmakingtips #indiefilmmaker #screenwriting #directorscut #nobudgetfilm

• フックは 1〜2 秒で着地（視覚 / テキスト両方）
• 雑な・生っぽいトーン > 磨き上げ
• "Story time" / "POV" フォーマットが完了率を伸ばす
• トレンド音源で大幅にリーチ増（Shorts 再投稿時も検討）

• Visible 150 文字 / Max 2,200 文字
• 出落ち先頭: "We had no actors. No crew. No money. We made a movie anyway."
• Hashtags 3〜5 個まで（多すぎはスパム扱い）

• 個人的・脆さを見せる（filmmaker community に刺さる）
• 舞台裏 (BTS) フレーミング
• 一般向け投稿では業界ジャーゴンを減らす

X ポストは 「動画の宣伝」ではなく、本編の発言を引用しながら 業界 / 制作 / 社会の議論テーマを提示する 形で書く。

視聴者が「これ本当にそう」「いや違う」と反応したくなる構成にする。

{パワーワード見出し — 太字的な一行}
───
{本編の主張を噛み砕いて 3〜5 文で展開。断定調。
具体的な数字や事例を入れる。
最後に視聴者が考えたくなる問いかけ or 皮肉で締める。}

• 280 文字制限は無視してよい（Premium 長文前提）。ただし 400 文字以内 目安
• Hashtag は使わない（アルゴリズム上、Hashtag は X ではリーチを下げる）
• 1 行目がパワーワード。ここでスクロールを止める
• ─── (罫線) で区切る。視覚的にタイトルと本文を分離
• 本編の発言をそのまま引用せず、一般化・抽象化して議論テーマに昇華 させる
• 動画の宣伝感を出さない。業界全体への問題提起として書く
• ショート動画のリンクは別途添付前提。本文中 URL は入れない

• 断定調（「〜だ」「〜でしかない」）
• 業界の常識に切り込む（「誰も言わないけど」「本音を言うと」）
• 数字で裏付ける
• 皮肉・逆説
• 賛否が分かれる主張ほどリーチが伸びる

→ 詳細は [05_x_post_style.md](05_x_post_style.md) 参照。

• エピソード番号 + 主題（Ep. 1: <Topic>）
• 検索フレーズを含める
• 50〜80 文字

• 本編の概要 3〜5 文
• Show notes（リンク・人物・参考文献）
• タイムスタンプ（YouTube より細かく可）

ロング本編からショートを切り出すための汎用フレームワーク。プロジェクトのトンマナに合わせて評価軸の重み付けは調整可能。

理由: 編集でかなり短く切り詰めるため、セクション粒度の候補が多くても成立する。むしろ「ボツ前提で多めに出す」のが推奨。

ショートとして切り出す候補は以下 5 軸で評価する。3 軸以上が ◎ のもの を上位プライオリティとする。

各プロジェクトの既存ショートからパターンを抽出し、合致しないものは採用しない。

→ プロジェクト固有のトンマナは PROJECT_OVERRIDES.md の「既存ショート一覧」セクションで管理。

• テンションが低い区間（淡々とした事実列挙だけ）
• 視覚（リアクション・映像）に依存して音声だけで成立しない箇所
• 固有名詞の羅列が多すぎて文脈なしで追えない箇所
• 映像素材（オーディション映像・ロケ映像等）依存で音声だけで成立しない箇所

各 Part につき 5〜12 本 を以下フォーマットで出力。

### P{番号}「{ショートタイトル — 15文字以内}」
**切り口**: {既存ショートのどれに近いか / 業界問題提起・教育系・etc.}
**5軸評価**: フック◎ / 情報◎ / テンション○ / 汎用◎ / 共感○

**抽出区間**:

| SRT# | タイムコード | 内容 |
|------|-------------|------|
| {番号} | `{MM:SS〜MM:SS}` | {内容} ← **フック** |
| ... | ... | ... |
| {番号} | `{MM:SS〜MM:SS}` | {内容} ← **オチ/締め** |

**編集メモ**: {カットの繋ぎ方、テロップの入れ方、構成の意図}

提案された全ショートを 1 枚で見渡せるテーブル:

略号: F=フック力 / I=情報密度 / T=テンション / U=汎用性 / E=共感・議論

12 本提案する場合の制作方針:

• P1〜P4: 必ず作る（拡散用）
• P5〜P8: 作る方向で検討（ファン育成）
• P9〜P12: 余裕があれば（予備 / 変化球）

対象 Part の <name>_claude.srt を全文読む。オフセット分割で最後まで読み切る。

SRT パスは各プロジェクトの PROJECT_RESOURCES.md 参照。

以下のシグナルをメモする:

• 強調語: 「マジで」「めちゃくちゃ」「絶対」「一番」「これは」
• 数字の具体例（「80人」「2000万」「30秒」等）
• 業界への問題提起（「〜は無理」「〜だけは解せない」）
• 逆説・意外な展開（「蓋開けてみると〜」「実は〜」）

Step 2 でマークした区間を 5 軸評価し、上位 5〜12 本 を選定。

• フックとなる 1 文 を特定（ショートの冒頭）
• オチ / 締め 1 文 を特定（ショートの最後）
• その間を最短で繋ぐ（60 秒に収まるよう不要な脱線をカット）

セクション 5 のフォーマットで全本数分を出力。最後に企画一覧テーブル + SNS 投稿テーブル で締める。

各ショートに対する X / Instagram / YouTube Shorts / TikTok のタイトル + ディスクリプションを 1 つのテーブルにまとめて 出力。

→ フォーマット詳細: [06_shorts_sns_table.md](06_shorts_sns_table.md)

仮に 8 本作る場合の最適公開順:

1本目: P1（フック力最強 — 新規を掴む）
2本目: P2（残り強フック — 掴んだ視聴者を次へ）
3本目: P3（情報密度 — 「このチャンネル有益」と思わせる）
4本目: P4（感情に訴える — フォロー動機）
5本目: P5（深い知見 — ファン育成）
6本目: P6（業界裏側 — リピーター育成）
7本目: P7（変化球 — 新規層拡大）
8本目: P8（予備 or 季節ネタ）

鉄則:

• 序盤 2 本に最強カードを必ず使う
• 中盤で情報密度・感情を交互に
• 終盤は変化球 or リサイクル可能なネタ

各ショートに対して、SNS 各プラットフォーム分の投稿を 1 本ずつ 生成する：

→ ロング本編 1 本ではなく、ショート 1 本ごとに 1 行 をスプレッドシート / Notion で管理。

→ 出力テーブルフォーマット: [06_shorts_sns_table.md](06_shorts_sns_table.md)

• [01_platform_rules.md](01_platform_rules.md) — プラットフォーム別書式
• [03_thumbnail_title.md](03_thumbnail_title.md) — サムネタイトル方針
• [05_x_post_style.md](05_x_post_style.md) — X ポスト書式
• [06_shorts_sns_table.md](06_shorts_sns_table.md) — SNS 投稿テーブル出力フォーマット

YouTube サムネイル上に大きく表示されるテキストの設計。最大限に扇情的 が原則。

• 文字数オーバー（読めない）
• 抽象的（「すごい」「やばい」だけ）
• 数字がない
• 煽りなし（淡々とした事実列挙）
• ネタバレ過多（クリック後の retention 低下 = YouTube penalty）

YouTube Studio の thumbnail テスト機能で 3 案を回し、CTR × retention で評価。

高 CTR + 低 retention は penalty 対象なので注意。

• [01_platform_rules.md](01_platform_rules.md) §YouTube Title — タイトル本体（描画されるテキスト）の規則
• [02_shorts_planning_framework.md](02_shorts_planning_framework.md) — ショート企画

ロング本編の YouTube ディスクリプションに含めるチャプター（タイムスタンプ目次）を SRT から生成する手順。

→ プロジェクト固有のパスは各プロジェクトの LOCAL_PATHS.md 参照。

オフセットを分割して最後まで読み切る。

以下のシグナルを探す:

• 話題の明確な切り替わり（「次は〜」「ここから〜」）
• 司会者・サブの質問による話題転換
• 長い沈黙（SRT タイムスタンプギャップ）後の新トピック

SRT 形式: 00:17:49,296
   ↓
YouTube 形式: 17:49

• 秒単位 の精度（ミリ秒は切り捨て）
• 1 時間超は HH:MM:SS

• 25 文字以内 の日本語（英語は ~40 字）
• 内容を一目で伝える
• 釣りすぎず、正直に

00:00 オープニング
00:48 今回のテーマ：予算策定
02:27 英語脚本とローカライズの壁
05:33 キャスティングの裏側
...
33:11 まとめと次回予告

• 序盤は粒度を細かめに（視聴者が「中身」を判断する材料）
• 中盤は内容のまとまりで割る
• 締めは「まとめ」「次回予告」等で必ず作る
• 検索キーワードをタイトルに含めると見つかりやすい

• 00:00 Intro のみで終わる
• すべて 30 秒刻みで機械的
• チャプタータイトルが長すぎてスマホで切れる
• ネタバレ過多

ショート動画とセットで投稿する X ポストの専用スタイル。動画の宣伝ではなく、議論喚起のスタンドアロン投稿 として書く。

X ポストは「ショート動画の宣伝」ではなく、本編の発言を引用しながら業界 / 制作 / 社会の議論テーマを提示する スタイルで書く。

視聴者が「これ本当にそう」「いや違う」と反応したくなる構成にする。

{パワーワード見出し — 太字的な一行}
───
{本編の主張を噛み砕いて 3〜5 文で展開。断定調。
具体的な数字や事例を入れる。
最後に視聴者が考えたくなる問いかけ or 皮肉で締める。}

アイドル出演させりゃ売れる
───
「最近の邦画はアイドル映画ばかりでつまらない」って文句言う人多いけど、無名監督のオリジナル脚本なんて誰も1円も出資しない。でも「〇〇が出ます」と言った瞬間、中身スカスカでも数千万集まる。パトロンが欲しいのは作品の質じゃなくて、ファン数の確約。

海外直談判
───
日本の映画配給に持ち込んでも「実績がない」で門前払い。日本の狭いムラ社会で顔色うかがって映画作るくらいなら、最初から世界狙った方がいいと、国際映画祭の裏のマーケットで、海外配給会社に直接売り込んだ。結果全滅だったが、閉鎖的な日本で消耗するより全然マシだと思えた。

• 断定調（「〜だ」「〜でしかない」）
• 業界の常識に切り込む（「誰も言わないけど」「本音を言うと」）
• 数字で裏付ける（「2000万」「80人」「30秒」）
• 皮肉・逆説を効かせる（「無名監督のオリジナル脚本なんて誰も1円も出資しない」）
• 共感と反発の両方 を狙う（賛否が分かれる主張ほどリーチが伸びる）

• ふんわりした感想（「面白かったです」「考えさせられました」）
• 動画の宣伝口調（「ぜひ見てください」「リンクはこちら」）
• ハッシュタグ（#映画 #インディーズ 等）
• URL 直貼り（本文中に）

───

U+2500 (BOX DRAWINGS LIGHT HORIZONTAL) を 3 個。

代替: ___ (アンダースコア 3)、--- (ハイフン 3) でも可。X 上で見やすい区切りを選ぶ。

• [ ] 1 行目だけでスクロールが止まる
• [ ] 罫線で見出しと本文が分離されている
• [ ] 数字 or 具体例が入っている
• [ ] 断定調
• [ ] 業界 / 社会への抽象化ができている
• [ ] ハッシュタグ・URL なし
• [ ] 400 文字以内
• [ ] 動画の宣伝ではなく、独立した主張として読める

1 ショート企画に対して X / Instagram / YouTube Shorts / TikTok の各投稿（タイトル + ディスクリプション）を 1 つのテーブルで スマートに表示するためのフォーマット仕様。

ショート企画を出した後、必ずこのテーブルを出力する。

| P | ショート企画 | プラットフォーム | タイトル / 1行目 | ディスクリプション / 本文 | 文字数 | ハッシュタグ |
|---|---|---|---|---|---|---|
| P1 | {ショートタイトル} | YouTube Shorts | {タイトル本文} | {キャプション本文} | {len} | {tags} |
| P1 | 〃 | TikTok | {タイトル本文} | {キャプション本文} | {len} | {tags} |
| P1 | 〃 | Instagram | — | {キャプション本文} | {len} | {tags} |
| P1 | 〃 | X | {パワーワード見出し} | {罫線+本文} | {len} | — |
| P2 | {ショートタイトル} | YouTube Shorts | ... | ... | ... | ... |
| ... |

→ 詳細ルールは [01_platform_rules.md](01_platform_rules.md) と [05_x_post_style.md](05_x_post_style.md) 参照。

| P | ショート企画 | プラットフォーム | タイトル / 1行目 | ディスクリプション / 本文 | 文字数 | ハッシュタグ |
|---|---|---|---|---|---|---|
| P1 | 邦画はアイドル映画 | YouTube Shorts | アイドル出ない映画は売れない…無名監督の現実 | 「最近の邦画つまらない」とは言うけど、無名監督のオリジナル脚本に1円も出資されないのが現実。/ Full episode → | 87 | #映画 #邦画 #インディーズ映画 #映画制作 |
| P1 | 〃 | TikTok | アイドル出ない映画は売れない問題 | 邦画が「アイドルばっか」って言われる本当の理由。出資の構造を業界の中の人が話します。 | 64 | #映画 #邦画 #インディーズ |
| P1 | 〃 | Instagram | — | 邦画がアイドル映画ばかりなのは、無名監督に1円も出資されないから。/ 出資する側は作品の質じゃなく「ファン数の確約」を買っている。/ Full episode link in bio | 92 | #映画 #邦画 #インディーズ映画 #filmmaking #映画好きと繋がりたい |
| P1 | 〃 | X | アイドル出演させりゃ売れる | ───<br/>「最近の邦画はアイドル映画ばかりでつまらない」って文句言う人多いけど、無名監督のオリジナル脚本なんて誰も1円も出資しない。でも「〇〇が出ます」と言った瞬間、中身スカスカでも数千万集まる。パトロンが欲しいのは作品の質じゃなくて、ファン数の確約。 | 187 | — |

このテーブルは:

• スプレッドシート に貼り付け → タブ区切り (TSV) に変換
• Notion にコピー → そのまま Notion テーブルになる

# Markdown table → TSV
lines = md_table.strip().split("\n")
header = [c.strip() for c in lines[0].strip("|").split("|")]
rows = [[c.strip() for c in r.strip("|").split("|")] for r in lines[2:]]
tsv = "\n".join(["\t".join(header)] + ["\t".join(r) for r in rows])

→ 文字数列を 2 つに分ける（タイトル / 本文）と、各プラットフォーム制約のチェックが楽。

Notion テーブルは Markdown コピーで直接貼れる。

プロパティとして:

• Title: P 番号 + ショート企画名（例: P1 邦画はアイドル映画）
• Platform: Select (YouTube Shorts / TikTok / Instagram / X)
• Status: Select (Draft / Final / Published)
• Caption: Text
• Hashtags: Multi-select
• Posted at: Date
• URL: URL

→ 各プロジェクトの Notion DB URL は PROJECT_RESOURCES.md に記載。

// セル D2 に "タイトル"、F2 にその文字数を入れたい場合
=LEN(D2)

• [ ] P1〜P{N} 全部に 4 プラットフォーム × 1 行 = 合計 4×N 行ある
• [ ] X だけハッシュタグ無し（—）
• [ ] 各プラットフォームの文字数制約を超えていない
• [ ] X は罫線（───）で見出しと本文を分離している
• [ ] Instagram のタイトル列は —、本文に集約している
• [ ] TSV 化したときに改行・タブが本文に混入していない（セル分割が壊れる）

Instagram キャプションや X 本文は 複数行 で書きたいことが多い。

セル内改行を含むテキストは ダブルクォートで囲む:

def q(s): return '"' + s.replace('"', '""') + '"'
tsv_cell = q("1行目\n2行目\n3行目")

ダブルクォート内のダブルクォートは "" でエスケープ。

セル内改行は <br/> を使う:

| ... | ... | ───<br/>本文1行目<br/>本文2行目 | ... |

Notion はセル内 \n を自動で改行扱い。

• [01_platform_rules.md](01_platform_rules.md) — 各プラットフォームの詳細ルール
• [02_shorts_planning_framework.md](02_shorts_planning_framework.md) — ショート企画フレームワーク
• [05_x_post_style.md](05_x_post_style.md) — X ポスト書式
• プロジェクト側 PROJECT_RESOURCES.md — スプレッドシート / Notion DB URL

実体フォルダ: D:\zFilms Dropbox\z Films\Directors'Katto\

映画『グーチョキデッド』(英題: Rock, Paper, Death!) の制作過程を、素人 3 人チーム（あさお / ふじい / なべ）が振り返るトークドキュメンタリー YouTube シリーズ。

フル尺本編（Part1〜Part8+）、ショート（1-1〜3-5）、英語字幕、Podcast を展開。

値は記録しない。環境変数名のみ。

参照方法は [SubtitleMaker/00_base/07_elevenlabs_workflow.md](file:///D:/zFilms%20Dropbox/z%20Films/App/SubtitleMaker/00_base/07_elevenlabs_workflow.md) 参照。

L1 / L2 マスターからの主な逸脱:

→ 詳細は実体側 [Claude/SUBTITLE_RULES.md](file:///D:/zFilms%20Dropbox/z%20Films/Directors%27Katto/Claude/SUBTITLE_RULES.md) を参照。

→ [Claude/PROJECT_REFERENCE.md](file:///D:/zFilms%20Dropbox/z%20Films/Directors%27Katto/Claude/PROJECT_REFERENCE.md) §4-1〜4-11

主要カテゴリ:

• 制作チーム（あさお / ふじい / なべ / トニー / ケニス / リナ 等）
• 番組・作品名（ディレクターズ葛藤 / グーチョキデッド / Rock, Paper, Death!）
• 参照映画（グラディエーター / イカゲーム / レザボア・ドッグス 等）
• 業界用語（プリプロ / シーンブレイクダウン / Tiffcom 等）

→ [SUBTITLE_MANUAL.md](file:///D:/zFilms%20Dropbox/z%20Films/Directors%27Katto/SUBTITLE_MANUAL.md) §固有名詞辞書

主要パターン:

• URL: https://docs.google.com/spreadsheets/d/1kK14gdwjUd2myIpvbgLtZlELUHEUlyQOxeND-P03hh0/edit
• 列構成: [CONTENT_GENERATION.md §1](file:///D:/zFilms%20Dropbox/z%20Films/Directors%27Katto/Claude/CONTENT_GENERATION.md) 参照
• 書き込み手順（Chrome DevTools MCP 経由）も同ファイル §4

• URL: https://www.notion.so/zfilms/Subtitle_Shorts-35dbd1f2cc818097b45ad8eba877b3b1
• 用途: ショート企画 + 各プラットフォーム投稿の一元管理
• 投稿テーブルフォーマット: [SubtitleMaker/10_content/06_shorts_sns_table.md](file:///D:/zFilms%20Dropbox/z%20Films/App/SubtitleMaker/10_content/06_shorts_sns_table.md)

新規セッションで Katto の作業を始めるとき:

1. SubtitleMaker マスター読込:
   D:\zFilms Dropbox\z Films\App\SubtitleMaker\README.md
   D:\zFilms Dropbox\z Films\App\SubtitleMaker\00_base\<必要なもの>
   D:\zFilms Dropbox\z Films\App\SubtitleMaker\10_content\<必要なもの>

2. Katto 登録ポインタ（このファイル）:
   D:\zFilms Dropbox\z Films\App\SubtitleMaker\20_projects\directors_katto.md

3. Katto 実体側 MD:
   D:\zFilms Dropbox\z Films\Directors'Katto\Claude\PROJECT_REFERENCE.md
   D:\zFilms Dropbox\z Films\Directors'Katto\Claude\SUBTITLE_RULES.md (字幕作業時)
   D:\zFilms Dropbox\z Films\Directors'Katto\Claude\CONTENT_GENERATION.md (SNS作業時)
   D:\zFilms Dropbox\z Films\Directors'Katto\SUBTITLE_MANUAL.md (パイプライン詳細)

*最終更新: 2026-05-11 — Notion URL / Spreadsheet / ELEVENLABS_API_KEY 反映、L1 04b 適用外フラグ追加*