transcript-fixer について
transcript-fixerは、人やエージェントのワークフローで音声認識の文字起こしを修正するスキルです。確定的な辞書修正に続いてネイティブAIで全文を確認し、承認済みの反復修正を再利用できる形で蓄積します。
主な機能
- 01段階的な文字起こし修正
- 02ネイティブAIによる全文確認
- 03未解決項目のキュー登録
- 04反復修正のルール化
- 05一括処理とエージェント不在時のAPI経路
活用シーン
- 01会議文字起こしのASR誤り修正
- 02人名や専門用語の確認
- 03不確かな文字起こし箇所の処理
- 04自動化パイプラインでの修正実行
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ daymade/ claude-code-skills --skill transcript-fixerインストール後、Claude Code で/transcript-fixerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
.gitignoreCHANGELOG.mdreferences/advanced_correction_evidence.mdarchitecture.mdbest_practices.mddatabase_schema.mddictionary_guide.mddictionary_identity_and_context.mddomain_context_guide.mdexample_session_dji_minutes.mdexample_session.mdfalse_positive_guide.mdfile_formats.mdglm_api_setup.mdinstallation_setup.mditeration_workflow.mdnative_action_details.mdnative_ai_full_workflow.mdnative_correction_application.mdnative_entity_triage.mdnative_historical_evidence.mdnative_metadata_provenance.mdnative_queue_finalization.mdnative_review_packets.mdnative_second_pass.mdnative_transcript_comparison.mdnative_upstream_provenance.mdpending-continuation.mdquick_reference.mdreview_queue_dashboard.md詳細
Transcript Fixer
修正ループを使用します。
- ステージ 1 では、決定的な既知の修正を適用します。
- Native AI Correction では、トランスクリプト全体を読み込み、単発の誤りを修正し、不確かな固有表現を確認して、再利用可能な修正を蓄積します。
Native AI Correction がデフォルトです。ステージ 1 だけでは不十分です。 ステージ 3 API は、Claude/Codex エージェントを利用できない自動化専用です。
運用契約
- ステージ 1 → ネイティブ AI 補正 → 複合的に確認された反復修正を完了してください。ステージ 1 だけで文字起こしがクリーンになったと報告してはいけません。
- 人間がこの実行を辞書の確認のみに明示的に限定している場合、または日付入りの成果物によって、まさにこの文字起こしに対してネイティブ AI がすでに実行されたと証明できる場合に限り、ネイティブ AI をスキップしてください。
- Claude Code または Codex では、ステージ 3 を実行しないでください。ステージ 1 とネイティブワークフローを使用してください。
- 流暢さを理由に発話を書き換えてはいけません。修正では、もっともらしい ASR の誤りを説明し、誰が何を言ったかを保持する必要があります。
- 別の箇所にある標準用語や既知の参加者は候補の根拠にはなりますが、この箇所で実際にその表現が使われた証拠にはなりません。初回パスとコールドレビューでは、ネイティブレビューパケットにある箇所固有の対比を適用し、判別材料がない場合は元の表記を保持してください。
- 名前の表記揺れが一致すると判断する前に、会社名/氏名のスロット全体を確認してください。最低限の出現箇所チェックに従ってください。名前形式ガードで拒否された通常の表現には、捏造したユーザー/音声の引用ではなく、範囲を限定した書面表現ルートのみを使用してください。
- デフォルトでは、話者の身元を推測したり、割り当て直したりしてはいけません。話者ラベルの行を保持してください。人間が確認したラベルとユーザーの判定が優先されます。タスクの範囲を明示したユーザーの許可によって身元の推測が認められた場合に限り、別個の派生リーダーブランチを使用できます。実行前に範囲限定の話者推定を読んでください。この許可は推測を認めるものであり、身元を確定するものでも、他の文字起こしに適用できる許可でもありません。
- 人名を修正する前に、設定済みのグローバル人物名簿と、該当プロジェクトの明示的な身元名簿または別名台帳を両方とも直接読んでください。ステージ 1 が自動読み込みするのはグローバルな
ASR 变体エントリーのみです。プロジェクト名簿は読み込まず、抑制、無効化、未掲載のエントリーも表示しません。必要な情報源が欠けている場合、または情報源同士が矛盾する場合は、名前を変更せず、キューに追加するか、一度だけ確認してください。出現頻度を身元の証拠にしてはいけません。名前を確定する前にreferences/dictionary_identity_and_context.mdを読んでください。 - エスカレーションする前に、利用可能な証拠から疑問を解決してください。音声のダウンロードは証拠の一つであり、ネイティブ補正の前提条件ではありません。利用できない場合は、証拠の選択とエスカレーションに従ってください。ユーザーにダウンロード権限の変更を求めたり、保留中のすべての行をユーザーにしか答えられない質問として扱ったりしてはいけません。
- 本当に解決できないテキストは変更せず、キューに追加してください。流暢でも誤った推測をするより、目に見える文字化けのままにするほうが安全です。保留行は不確実性を記録するものであり、自動的に人間へ引き継ぐものではありません。
- 見慣れないトークンは、誤りではなく未知のものとして扱ってください。まずローカルの証拠の段階をすべて確認してください。重要なトークンが未解決のまま残る場合、クリップ単位の複数認識エンジンによる確認段階を使えるのは、元の音声と許可された第 2 エンジンがすでに利用可能な場合のみです。それ以外の場合は、上記のエスカレーション方針に従って利用可能な証拠をもとに作業を続けてください。実際に異なる認識エンジンのファミリー同士で一致した場合、音声を強く裏付けますが、同音異綴りの選択には使えず、人名の確認ゲートを覆すこともできません。使用前に、ネイティブワークフローのステップ 4、段階 7 を読んでください。解決手段を使い切った保留項目の山積みは、この段階をバッチで適用するケースです。ネイティブパス後にローカルで解決できない行のキューが残った場合、そのキュー全体をユーザーに渡してはいけません。
verify_queue_audio.pyで確認してください(文字起こし 1 件、元の音声 1 件、第 2 エンジン 1 つ、各行につきクリップ区間 2 つ)。このスクリプトは音響的な証拠を添付できますが、判定を記録することはありません。同一のクリップや、争点となっている単語境界を裏付けない読みは、判定待ちのままです。オペレーター向けマトリックスとタイムスタンプ対応付けの落とし穴については、advanced_correction_evidence.md § 保留項目の高度なバッチ判定を参照してください。 - 1 行の
asr_note値は修正の由来を示すものとして扱ってください。旧形式を意図的に記載しており、照合対象から除外されます。複数行の YAML 台帳値はマスクされません。キーワード、タイトル、その他の ASR 由来メタデータ、本文は引き続き修正対象です。 - ネイティブパスを実行する前に、references/native_ai_full_workflow.mdをすべて読んでください。連続した重複のない読み取りでファイル全体を確認できます。応答が途中で切れた場合は、作業を進める前に欠落した範囲を読んでください。
catを実行しただけでは、出力全体を受け取ったことの確認にはなりません。各アクションに対応する前に、以下で指定されたタスク固有の参考資料を読んでください。それらのファイルも、範囲を限定し、途中で切れない形で読み取ってください。
実行コンテキスト
すべてのエントリーポイントを uv run 経由で実行してください。サードパーティ製の Python パッケージが必要なエントリーポイントでは PEP 723 を使って依存関係を宣言し、標準ライブラリまたは内部機能のみを使うユーティリティではメタデータブロックを省略できます。このスキルの実行時に表示されたスキルディレクトリからコマンドを実行するか、すべてのスクリプトパスの先頭にそのディレクトリを付けてください。すべての実行環境で使用できるとは限らないため、$CLAUDE_SKILL_DIR に依存しないでください。
バンドルの場所が本当に不明な場合は、references/installation_setup.md のインストール先解決手順を使ってください。広範な find の最初の結果を選ばないでください。キャッシュ、バックアップ、古いバージョンが共存している可能性があります。
クイックスタート
以下で明示するファイル引数を設定する前に、コンテキストの場所を使って <domain-context.md> の場所を特定してください。
# Initialize once
uv run scripts/fix_transcription.py --init
# Stage 1 for one project domain. --apply-domain trusts that explicitly
# selected, human-curated project domain at every risk level.
uv run scripts/fix_transcription.py \
--input meeting.md --stage 1 \
--domain myproject --apply-domain --json
# Several sibling domains may be loaded as one union.
uv run scripts/fix_transcription.py \
--input meeting.md --stage 1 \
--domain myproject,myproject-alt --apply-domain --json
# Preview without writing the Stage 1 output.
uv run scripts/fix_transcription.py \
--input meeting.md --stage 1 --domain myproject --dry-run
# Scan all documented context traps after the native read-through.
uv run scripts/fix_transcription.py --scan-traps \
--context-file "<domain-context.md>" \
--input meeting.md
セーフモードが Stage 1 のデフォルトです。低リスクのルールは適用され、中リスク/高リスクの一致は *_needs_review.md と永続的なレビューキューに回されます。Applied: 0 は有効な結果であり、トランスクリプトに問題がないことを示すものではありません。
Stage 1 の JSON コントラクトは次のとおりです。
{
"applied": 0,
"deferred": 0,
"output_path": null,
"needs_review_path": null,
"input_unchanged": true,
"review_enqueued": 0,
"stage1_only_incomplete": true,
"stage2_total_chunks": 0,
"stage2_failed_chunks": 0,
"stage2_degraded": false,
"boundary_refused": 0,
"boundary_check_active": true
}
結果のすべてのフィールドを確認してください。boundary_refused は、単語境界チェックによってこの実行で適用を拒否された辞書の一致数です。適用も保留もされていないため、呼び出し元は実行間で比較し、保留が消えた理由を把握できます。--apply-all を指定すると、このチェックは無効になります。stage1_only_incomplete は元の呼び出し元コントラクトに追加されたフィールドで、Stage 1 スクリプトの実行では true のままでなければなりません。これを完了にできるのは、Native AI を実行するか、エージェントを使わない Stage 2/3 の経路を明示的に選ぶ呼び出し元だけです。stage2_* のテレメトリフィールドは常に存在します。Stage 1 では 0、0、false が報告され、Stage 2/3 では実際の API 結果に置き換わります。サイドカーの有無から何も行われなかった、または成功したと推測しないでください。
Native によるエンドツーエンドの例については、references/example_session_dji_minutes.md を読んでください。
経路を選ぶ
| 経路 | 使用する場面 | 必読資料 |
|---|---|---|
| 保留の続行 | このファイルを対象とする日付入りの Native/レビューの証拠があり、不確かな行だけが残っている場合、またはユーザーが判定を提示した場合 | pending-continuation.md。完了済みの対象範囲は変更せず再利用してください |
| Native の高速処理 | 短い/平易なトランスクリプト、話者が判明している、リスクが低い場合 | このファイルと native_ai_full_workflow.md |
| Native の完全処理 | 専門性の高い分野、馴染みのないエンティティ、話者が 3 人以上、長いトランスクリプト、または意思決定に関わるトランスクリプト | native_ai_full_workflow.md、および以下のキューと証拠に関する資料 |
| 範囲を限定した話者推論 | ユーザーがこのトランスクリプト/タスクでの身元推論を明示的に許可している場合 | scoped_speaker_inference.md。通常の ASR 修正は Native の経路で行ってください |
| 呼び出し元との統合 | 別のスキルまたは取り込みパイプラインが Stage 1 を呼び出す場合 | 以下の「スキル間の呼び出し元コントラクト」 |
| レビューキュー/ダッシュボード | 不確かな項目がある場合、または音声が必要な場合 | review_queue_dashboard.md |
| エージェントを使わない API | エージェントを利用できない CI/バッチ自動化 | glm_api_setup.md と workflow_guide.md |
| 複数ファイルのバッチ処理 | 関連するトランスクリプトが複数ある場合、特に 10 ファイル以上の場合 | advanced_correction_evidence.md |
優先度の判断には、語彙とリスクを主な指標として使ってください。長さは同点の場合の判断材料にします。5 分間の医療面接では完全処理が必要になることがありますが、長い平易な 2 人のメモなら高速処理を使えます。
ネイティブ修正チェックリスト
修正する前に、必須のネイティブ手順を最後まで読んでください。 この手順では、出所の確認、エンティティのトリアージ、編集、コールドレビューからの復旧、 キューの判断、最終処理について、それぞれの実行時に参照すべき資料を案内しています。
- 入力に人が読める最終パスを付け、元の出所を復元して差分を確認します。
- プロジェクトのコンテキストを読み込み、トランスクリプト全体を読み、Stage 1を実行して差分を確認します。
- 候補をトリアージし、出現箇所による裏付けがある最小限の修正だけを適用します。
- トラップスキャンを実行し、Full-tierのコールドレビューを完了して、その残件を裁定します。
- 対象ファイルが一致するキュー項目を解決し、作業を繰り返す前に人間による状態を読み取ります。
- 編集したファイルを検証し、最終的な主張や高品質の主張には保留項目がゼロであることを必須とし、 サイドカーを機械的にクローズし、安定したパターンを抽出してエンティティの反映状況を確認します。
対応するキュー、学習、または同一ファイルのエンティティ一括確認を行う前に、
ネイティブ操作の詳細を読んでください。
特に、人名の正規表記は--noteではなく--authority/--authority-recordに指定してください。
文単位の修正が、そのまま再利用可能なルールになるとは限りません。
スキル間の呼び出し契約
呼び出し元のパイプラインでは、次の処理が必要です。
- 明示的に設定されたプロジェクトドメインと
--apply-domain、--jsonを指定してStage 1を実行します。deferred > review_enqueuedの場合は、レビューサイドカーを一時ディレクトリ以外に保存するか、この欠落を失敗として提示します。 - このスキルを読み込んだ状態でNative AIを実行するか、
Stage 1 only — incompleteと報告します。エージェントを使わない自動化では、代わりにStage 3を使用できます。 - 出力先のストレージ契約に基づいてレポートの保存先を選択します。レビュー用レポートには
--sidecar-dir DIRを使用し、実行出力は既存の--output契約に従って保存します。省略した場合は隣接先/デフォルトの出力動作が維持されます。--close-sidecarsがクローズを判断するまで、保留中のレポートを保持してください。クローズ処理では、登録済みのカスタムレポートディレクトリが検出されます。復旧時には--sidecar-dirを明示的に指定することもできます。すべてのプロジェクトにレポートを1つの固定サブディレクトリへ移動させないでください。
標準的な呼び出し:
uv run scripts/fix_transcription.py \
--input "$staged" --stage 1 \
--domain "$domains" --apply-domain --json
スクリプトのパスだけを接続する呼び出し元では、この契約は読み込まれません。そのため、スクリプトパスだけの統合は、トランスクリプト修正ではなくStage 1の事前フィルターにすぎません。
プロジェクトドメインを常に最新の状態に保ってください。ネイティブ処理で確認された繰り返し発生する修正はすべて、適切なプロジェクトドメイン、名簿、またはコンテキストファイルに追加してください。
条件付きアクション
操作する前に該当するセクションを確認してください。以下は既存のサポート対象ジョブです。
| アクション | 必要な詳細 |
|---|---|
| 辞書/コンテキストルール、名簿のバリエーション、または繰り返し発生する誤りを追加する | 辞書とアイデンティティの安全性、アイデンティティ/コンテキストの担当者、誤検出ガイド |
| キューに登録する、承認する/上書きする/維持する/スキップする、権威ある情報を添付する、再アンカーする、統合する、または台帳の判定を記録する | レビューキューの安全性、キュー/ダッシュボード。すでにレビュー済みのファイルには、保留項目の続行を使用してください |
| 数値、作成済み成果物、並行録音、クリップのクロスチェック、またはバッチ | 数値、成果物、バッチ、高度なエビデンス |
| 出力を昇格する、サイドカーを閉じる、アーカイブする、または最終品質を検証する | 最終処理、キュー/最終処理の詳細 |
| エージェントを使わない API 自動化(劣化した出力の処理を含む) | エージェントなしの API 経路、API のセットアップ、ワークフローガイド |
| 不確かな箇所を抽出する、プリセットをインポートする、タイムスタンプを修復する、分割/リベースする、差分を表示する、収集する、セットアップを検索または検証する | ユーティリティコマンド、CLI パラメーター |
| 重複/重なりのある文字起こしを比較する、または話者ターンを解析/カウントする | 文字起こしの比較/解析 |
検出とキューへの登録は、修正ではありません。最終版/高品質との主張には、対象ファイルの stats.pending_total == 0 が必要です。ファイルの編集内容を読み戻した後、保留行がゼロであることも必要です。未解決のファイルは draft / unresolved — incomplete のままにしてください。サンプリングしたクリップで確定できるのは、そのクリップにアンカーされた項目だけです。ベースライン音声が利用可能で、完全な/より良い文字起こしを求める重要度の高い複数録音の依頼では、/daymade-audio:asr-transcribe-to-text を読み込み、最も明瞭な録音全体を対象にしてください。同じ音声認識器で証明できるのはソース全体の網羅性であり、独立した裏付けではありません。
ユーザーの判定で該当箇所は確定しますが、置き換え表現が再利用可能になるわけではありません。文単位でまれに発生する聞き間違いは、そのファイル内に限って扱います。
リファレンスマップ
同梱スクリプトはコンテキストに読み込むのではなく、実行します。主なエントリーポイントは fix_transcription.py、scan_numeric_consistency.py、fetch_minute_audio.py、review-dashboard/server.py と、上記の差分/タイムスタンプ/分割ユーティリティです。
引き継ぎ
修正後、ユーザーが構造化された要約を希望する場合に限り、/daymade-audio:meeting-minutes-taker に引き継ぎます。議事録を自動で作成しないでください。文字起こしの修正と要約は、別々の作業範囲です。