失敗談・教訓集

概要

過去の案件で発生した問題や失敗事例から得られた教訓をまとめています。同じ失敗を繰り返さないためのナレッジベースとして、また新メンバーの研修資料として活用してください。

インシデント記録との関係

インシデントが発生したら、まずスプレッドシートに記録してください。

インシデントマニュアル（Google スプレッドシート）: https://docs.google.com/spreadsheets/d/18KkZG3YaG1-weVOEfvjX0V-JOEGRKAGJMGY9hWcAdDM/edit

• 「インシデントレポートライン」シート — ランク（S/A/B/C）の分類基準と報告フローを確認する
• 「インシデントレポート」シート — 発生日・ランク・概要・対応履歴を記録する

このファイル（失敗談・教訓集）は、インシデントレポートに記録された事案の中から再発防止の教訓として汎化できるものをピックアップして掲載します。個別の事案の一次記録はスプレッドシートが正本です。

参照元

Google Drive 上の原本: スタジオボイス共有ドライブ/★資料/クリエイティブ資料/失敗談集2026.pdf

上記 PDF の内容をカテゴリ別に整理して掲載します。

収録に関する教訓

事例 1: 固有名詞の読み方を確認しないまま収録

• 何が起きたか: 海外案件で中国語由来のキャラクター名の読み方を台本資料で確認せず収録。クライアントから「読み方が違う」と指摘され全セリフリテイク
• 原因: 台本にフリガナがなく推測で読んだ。収録前の読み合わせ確認を省略
• 教訓: 海外案件の固有名詞は必ず事前にクライアントに読み方を確認。推測で収録しない
• 対策: アダプテーション時に全固有名詞の読みリストを作成→クライアント承認後に収録開始

事例 2: セッションファイル破損で収録データ消失

• 何が起きたか: 長時間収録中に Pro Tools がクラッシュ。自動バックアップ間隔が 30 分で、直近 30 分の収録が復旧不能に
• 原因: 自動バックアップ間隔が長すぎた。手動保存（Cmd+S）をしていなかった
• 教訓: こまめな保存を癖づける。自動バックアップは 5 分間隔を推奨
• 対策: 全スタジオの自動バックアップ間隔を 5 分に統一。長時間セッション時は NAS への中間バックアップも実施

事例 3: 声優交代時にセッションを切り替えず上書き録音

• 何が起きたか: 同日の複数キャラ収録で、前のセッションを閉じずに次の声優で録音を開始。前キャラのテイクが上書き
• 原因: 声優交代時のセッション切替チェックがなかった
• 教訓: 声優交代時は必ずセッション保存 → 新規セッション作成のフローを踏む
• 対策: 収録進行表に「声優交代時のセッション切替チェック」を追加

編集・QC に関する教訓

事例 4: リネーム時のファイル取り違えが納品後に発覚

• 何が起きたか: 手作業リネームでファイル紐づけを誤り、キャラAのセリフにキャラBの音声が入ったまま納品。実装後に発覚
• 原因: 手作業リネームで Excel との突合せが不完全
• 教訓: リネームは自動化ツール使用を標準とする。リネーム後にランダムサンプリングで確認
• 対策: 共用データ/【インストーラー系】/Excelリストでファイル名変更/ ツールを標準化。リネーム後スポットチェックを QC に追加

事例 5: ノイズ除去のかけすぎで音質劣化

• 何が起きたか: 軽微な空調ノイズ除去のため RX Voice De-noise のパラメータを上げすぎ、サ行・ハ行が金属的な音質に
• 原因: 「ノイズは完全除去すべき」という誤解。処理前後の A/B 比較不足
• 教訓: ノイズ除去は「目立たなくする」が目標。完全除去を目指さない
• 対策: まず控えめ設定で処理 → 必要に応じて段階的に強めるフローに変更

納品に関する教訓

事例 6: ファイル数不一致を見落として納品

• 何が起きたか: 台本 350 セリフに対し納品ファイル 348 個。エフォート系の短い音声 2 件が編集工程で抜け
• 原因: 台本セリフ数とファイル数の突合せを省略
• 教訓: 納品前のファイル数カウント → 台本セリフ数突合せは省略不可
• 対策: 納品チェックリスト の「ファイル数突合せ」必須化

事例 7: 納品フォーマットの認識相違（ビット深度）

• 何が起きたか: クライアント指定「WAV」にビット深度の明記なし。24-bit で納品→「16-bit で」と差し戻し
• 原因: 「サンプルレート・ビット深度・チャンネル数・ファイル形式」の 4 項目をセットで確認しなかった
• 教訓: フォーマット確認は必ず 4 項目セットで確認する
• 対策: 納品フォーマット確認手順 を活用

クライアント対応に関する教訓

事例 10: メールの宛名を間違えて送信

• 何が起きたか: 担当者が変更されていたにもかかわらず、旧担当者宛にメールを送信。先方から「担当が変わっています」と指摘を受けた
• 原因: クライアント担当者が変わったことを把握していなかった。過去の送受信メールを確認せず、記憶に頼って宛名を記入した
• 教訓: 担当者は変わることがある。特に久しぶりの連絡時や引き継ぎ後は、最新の担当者を必ず確認してから送信する
• 対策: 送信前にCC先・宛名をダブルチェックする習慣をつける。メール送信前に直近のメール履歴を確認し、担当者名を確認する。Briskine などのメールテンプレートツールを活用する場合も、宛名部分は毎回手入力で確認する

事例 11: 声優名の読み方を間違えた

• 何が起きたか: 声優の名前の読み方を誤った状態で、事務所・スタッフ間で使い続けた。収録当日に声優本人の前で呼び間違えて気まずい状況になった
• 原因: 読み方を確認せず、漢字から推測して使い続けた
• 教訓: 声優名の読み方は必ず正式な読み方を確認する。初回対応時・新規キャスティング時に確認するのがベスト
• 対策: キャスティング確定後、事務所連絡時に読み方も含めて確認する。案件管理シートの声優名欄にフリガナを記載する習慣をつける

事例 12: 複数部署関与案件の引き継ぎミス

• 何が起きたか: 映像部やプロデュース部も関わる複合案件を引き継いだ際、他部署との調整ラインが不明確なまま進行。連絡漏れが発生し収録日程の変更が生じた
• 原因: 引き継ぎ時に「誰がどこに連絡するか」の役割分担が明確に伝わっていなかった
• 教訓: 複数部署が関わる案件は引き継ぎ難易度が高い。引き継ぎ時に関係者・連絡フロー・過去の経緯を丁寧に共有する
• 対策: 引き継ぎ時はデータ引継ぎ手順に沿って実施する。特に NextNinja（東方LostWord）・コロプラ（黒猫）・韓国クライアントなど引き継ぎが複雑な案件はクライアント別ルールを事前に確認すること

事例 8: NDA案件で正式タイトル名が漏洩しかけた

• 何が起きたか: 声優事務所へのスケジュール連絡時に、コードネームではなく正式プロジェクト名を記載して送信
• 原因: コードネーム使用ルールの周知不足
• 教訓: NDA 案件では常にコードネームを使用。メール送信前にプロジェクト名を再確認
• 対策: メールテンプレートに注意書き追加。NDA 案件フラグ管理の徹底

設備・機材・システムに関する教訓

事例 13: 支払い用iPadのAirPayアップデートで2段階認証が取れずお客様をお待たせ

• 何が起きたか: 収録当日、クレジットカード決済時にAirPayのアップデート要求が発生。パスワードはチャット履歴を探して何とか入力できたが、2段階認証コードの送信先デバイスが分からず、チームメンバーに連絡を取りながら対応。お客様・社内スタッフに迷惑をかけた
• 原因: ①Apple IDのパスワードと2段階認証先が文書化されていなかった ②認証情報が特定のエンジニアの口頭知識に依存していた ③アプリのアップデート有無を事前に確認する習慣がなかった
• 教訓: 業務ツールの認証情報は必ず一元管理する。「自分が知っていれば大丈夫」は引き継ぎが発生した瞬間に崩壊する
• 対策: ①アカウント・認証情報管理スプレッドシートを整備し、全業務アカウントを登録 ②AirPayを使用する日は収録前にアップデート確認を実施（→ AirPayマニュアル）③月1回のアップデート点検を習慣化

スケジュール・リソースに関する教訓

事例 9: 運営タイトルの追加収録で声優確保が間に合わず

• 何が起きたか: 長期運営タイトルの急な追加収録依頼。メインキャストの声優が 2 ヶ月先まで多忙で納期に間に合わず
• 原因: 追加収録の発生を予測せず仮押さえをしていなかった
• 教訓: 運営タイトルは定期的な追加収録が発生する前提でスケジュール管理する
• 対策: 主要キャストについて月 1 回程度の仮収録日を事務所と事前調整

教訓の追加方法

新しい教訓を追加する際は、以下のフォーマットに従ってください:

### 事例 N:
- **何が起きたか:**
- **原因:**
- **教訓:**
- **対策:**

更新履歴