Transcript Fixer

二段階の修正パイプライン: 決定的な辞書ルール (瞬時、無料) の後に AI 搭載のエラー検出を実行します。修正は ~/.transcript-fixer/corrections.db に蓄積され、時間とともに精度が向上します。

前提条件

すべてのスクリプトは PEP 723 インラインメタデータを使用します — uv run は自動的に依存関係をインストールします。uv が必要です (インストールガイド)。

クイックスタート

# 初回: データベースを初期化
uv run scripts/fix_transcription.py --init

# 単一ファイル
uv run scripts/fix_transcription.py --input meeting.md --stage 1

# バッチ: 複数ファイルを並列処理 (シェルループを使用)
for f in /path/to/*.txt; do
  uv run scripts/fix_transcription.py --input "$f" --stage 1
done

Stage 1 の後、Claude は出力を読み取ります。残りの ASR エラーをネイティブに修正します (API キーは不要):

1. すべての Stage 1 出力を読み取ります — 修正を提案する前に全トランスクリプトを読みます (後のコンテキストが前のエラーを曖昧性を解く)
2. ASR エラーを特定します — ファイル全体で修正をコンパイルします
3. sed でバッチ修正を適用し、diff で各修正を検証します
4. 最終化: _stage1.md を .md に名前変更し、元の .txt を削除します
5. 安定したパターンを辞書に保存して今後の再利用に備えます

具体的な入出力のチュートリアルについては references/example_session.md を参照してください。

代替: API バッチ処理 (Claude Code なしで自動化する場合):

export GLM_API_KEY="<api-key>"  # https://open.bigmodel.cn/ から取得
uv run scripts/fix_transcript_enhanced.py input.md --output ./corrected

コアワークフロー

持続的な学習を備えた二段階パイプライン:

1. 初期化 (1回): uv run scripts/fix_transcription.py --init
2. ドメイン修正を追加: --add "誤った単語" "正しい単語" --domain <domain>
3. Phase 1 — 辞書: --input file.md --stage 1 (瞬時、無料)
4. Phase 2 — AI 修正: Claude が出力を読み取ってエラーをネイティブに修正するか、GLM_API_KEY で --stage 3 を使用して API モード
5. 安定したパターンを保存: 各セッション後に --add "誤った単語" "正しい単語"
6. 学習したパターンを確認: --review-learned と --approve で高信頼度の提案

ドメイン: general、embodied_ai、finance、medical、またはカスタム (例: 火星加速器) 学習: ≥3 回出現し ≥80% の信頼度のパターンは、AI から辞書に自動昇格します

修正後、常に再利用可能な修正を辞書に保存します。 これはスキルの中核的な価値です — 完全なチェックリストについては references/iteration_workflow.md を参照してください。

修正後の辞書追加

ネイティブ AI 修正後、適用されたすべての修正を確認し、保存するものを決定します。この決定マトリックスを使用します:

パターンタイプ	例	アクション
非単語 → 正しい用語	克劳锐→Claude、cloucode→Claude Code	✅ 追加 (偽陽性リスクなし)
稀な単語 → 正しい用語	潜彩→前采、維星→韋青	✅ 追加 (実在しない単語であることを確認)
人名/企業名 ASR エラー	宋天航→宋天生、策马攀山→策马看山	✅ 追加 (安定、ユニーク)
一般的な単語 → コンテキスト単語	争→蒸、钱财→前采、报纸→标品	❌ スキップ (偽陽性リスクが高い)
実在のブランド → 異なるブランド	Xcode→Claude Code、Clover→Claude	❌ スキップ (他のコンテキストでは実在の単語)

複数の修正をバッチで追加:

uv run scripts/fix_transcription.py --add "誤った1" "正しい1" --domain tech
uv run scripts/fix_transcription.py --add "誤った2" "正しい2" --domain business
# 効率のため && でチェーン

偽陽性防止

間違った辞書ルールを追加すると、将来のトランスクリプトが暗黙のうちに破損します。特に短い単語 (≤2 文字) または通常のテキストで正しく表示される一般的な中国語の単語の修正ルールを追加する前に references/false_positive_guide.md を読んでください。

ネイティブ AI 修正 (デフォルトモード)

Claude Code 内で実行する場合、Phase 2 に Claude 自身の言語理解を使用します:

1. すべてのファイルで Stage 1 (辞書) を実行 (複数ある場合は並列)
2. Stage 1 を検証 — 元と出力を diff で比較。辞書が偽陽性を導入した場合は、元のファイルから作業します
3. 修正を提案する前に、すべての Stage 1 出力を完全に読んでください — 後のコンテキストが前のエラーを曖昧性を解くことが多くあります。大きなファイル (>10k トークン) の場合、チャンクで読みますが、修正を特定する前に全体を読み終わります
4. ファイルごとに ASR エラーを特定 — 信頼度で分類:
   • 高信頼度 (直接適用): 非単語、明らかなガーブル、製品名バリアント
   • 中信頼度 (レビュー用に提示): コンテキスト依存の同音異義語、人名
5. 修正を効率的に適用:
   • グローバル置換 (「克劳锐」→「Claude」のようなユニークな非単語): 1 つのコマンドで複数のパターンを持つ -e フラグで sed -i '' を使用
   • コンテキスト依存 (「争」→「蒸」を蒸留コンテキストでのみなど): より長いコンテキストフレーズで sed を使用してユニーク性を確保するか、Edit ツールを使用
6. diff で検証: diff original.txt corrected_stage1.md
7. ファイルを最終化: *_stage1.md を *.md に名前変更し、元の .txt を削除
8. 安定したパターンを辞書に保存 (下の「辞書追加」を参照)
9. Stage 1 に偽陽性があった場合はそれを削除

一般的な ASR エラーパターン

AI 製品名はしばしばガーブルされます。これらのパターンはトランスクリプト間で繰り返されます:

正しい用語	一般的な ASR バリアント
Claude	cloud、Clou、calloc、克劳锐、Clover、color
Claude Code	cloud code、Xcode、call code、cloucode、cloudcode、color code
Claude Agent SDK	cloud agent SDK
Opus	Opaas
Vibe Coding	web coding、Web coding
GitHub	get Hub、Git Hub
prototype	Pre top

人名と企業名も、セッション間で一貫した ASR エラーを生成します — 常に確認された名前修正を辞書に追加します。

効率的なバッチ修正戦略

複数ファイルを修正する場合 (例: 1 日の 5 つのトランスクリプト):

1. Stage 1 を並列実行: すべてのファイルを同時に辞書に通す
2. すべてのファイルを最初に読む: 何かを修正する前に、スピーカー、トピック、繰り返される用語のメンタルモデルを構築します
3. グローバル修正リストをコンパイル: 同じセッション (同じスピーカー、同じトピック) からの多くのエラーがファイル間で繰り返されます
4. 最初にグローバル修正を適用 (複数の -e フラグで sed)、その後、ファイルごとのコンテキスト依存の修正
5. すべての diff を検証し、すべてのファイルを最終化してから、1 回の辞書追加パスを実行

拡張機能 (ネイティブモードのみ)

• インテリジェント段落ブレーク: トピック遷移時に \n\n を追加
• フィラー単語削減: 「这个这个这个」 → 「这个」
• インタラクティブレビュー: 適用する前に修正を確認
• コンテキスト認識判定: 全体のドキュメントコンテキストが曖昧なエラーを解く

API モードを代わりに使用する場合

バッチ処理、Claude Code なしのスタンドアロン使用、または再現可能な自動処理には GLM_API_KEY + Stage 3 を使用します。

レガシーフォールバック

スクリプトが [CLAUDE_FALLBACK] を出力する場合 (GLM API エラー)、自動的にネイティブモードに切り替わります。

ユーティリティスクリプト

タイムスタンプ修復:

uv run scripts/fix_transcript_timestamps.py meeting.txt --in-place

トランスクリプトをセクションに分割 (各セクションを 00:00:00 にリベース):

uv run scripts/split_transcript_sections.py meeting.txt \
  --first-section-name "课前聊天" \
  --section "正式上课::好，无缝切换嘛。" \
  --rebase-to-zero

単語レベル diff (修正のレビューに推奨):

uv run scripts/generate_word_diff.py original.md corrected.md output.html

出力ファイル

• *_stage1.md — 辞書修正を適用
• *_corrected.txt — 最終版 (ネイティブモード) または *_stage2.md (API モード)
• *_対比.html — ビジュアル diff (ブラウザで開く)

データベース操作

データベース操作を行う前に references/database_schema.md を読んでください。

sqlite3 ~/.transcript-fixer/corrections.db "SELECT * FROM active_corrections;"
sqlite3 ~/.transcript-fixer/corrections.db "SELECT value FROM system_config WHERE key='schema_version';"

ステージ

ステージ	説明	速度	コスト
1	辞書のみ	瞬時	無料
1 + ネイティブ	辞書 + Claude AI (デフォルト)	~1分	無料
3	辞書 + API AI + diff レポート	~10秒	API 呼び出し

バンドルリソース

スクリプト:

• fix_transcription.py — コア CLI (辞書、追加、監査、学習)
• fix_transcript_enhanced.py — インタラクティブ使用用の拡張ラッパー
• fix_transcript_timestamps.py — タイムスタンプの正規化と修復
• generate_word_diff.py — 単語レベル diff HTML 生成
• split_transcript_sections.py — マーカーフレーズでトランスクリプトを分割

リファレンス (必要に応じて読み込み):

• 安全性: false_positive_guide.md (ルール追加前に読む)、database_schema.md (DB 操作前に読む)
• ワークフロー: iteration_workflow.md、workflow_guide.md、example_session.md
• CLI: quick_reference.md、script_parameters.md
• アドバンス: dictionary_guide.md、sql_queries.md、architecture.md、best_practices.md
• 運用: troubleshooting.md、installation_setup.md、glm_api_setup.md、team_collaboration.md

トラブルシューティング

uv run scripts/fix_transcription.py --validate はセットアップヘルスをチェックします。詳細な解決策については references/troubleshooting.md を参照してください。

次のステップ: ミーティング議事録への構造化

トランスクリプトを修正した後、コンテンツが会議、講義、またはインタビューからのものである場合、それを構造化することを提案します:

トランスクリプト修正完了: [N] 個のエラーが修正され、[output_path] に保存されました。

これを決定事項と行動項目を含む構造化ミーティング議事録に変換しますか?

オプション:
A) はい — /meeting-minutes-taker を実行 (会議/講義に推奨)
B) PDF としてエクスポート — 修正されたテキストに対して /pdf-creator を実行
C) 結構です — 修正されたトランスクリプトで十分です