サウンド制作の見積りは取れている。制作会社からもクラウドソーシングからも金額は返ってきた。それなのに発注に踏み切れない——ゲームサウンドエンジニアを業務委託で確保しようとしたとき、多くの発注担当者がこの状態で止まります。
止まる理由は、見積書の読み方が下手だからではありません。ほとんどの見積書に「音を作る費用」しか含まれておらず、「その音をゲームの中で鳴らす工程」が誰の担当なのかがどこにも書かれていないからです。BGM 20曲と SE 150点の WAV ファイルが納品されたあと、それをミドルウェアに登録し、シーン遷移に合わせてイベントを組み、ループ点を調整し、シーンごとの音量差を揃え、プラットフォームの容量制限に収める。この工程を誰がやるのかが空白のまま契約が進むと、最終的に手が空いているクライアントエンジニアが片手間で引き受けることになります。
その結果として起きるのが、ループが不自然に途切れる、シーンを移動するたびに音量が跳ねる、アプリ容量が想定を超える、といった手戻りです。しかもこれらはリリース間際の実機確認で初めて表面化するため、修正の余地がほとんど残っていません。さらに悪いことに、同じタイミングで「サウンドトラックを配信したい」「実況配信を許諾したい」という話が持ち上がり、権利の範囲を契約書に書いていなかったことが発覚します。
この問題は、発注のやり方を変えるだけで大きく減らせます。鍵は「音を作る人」と「音を鳴らす人」を最初から分けて考え、それぞれに適した契約形態とチャネルで確保することです。制作は成果物が明確なので曲単位の請負、実装は作業量が読みにくく仕様変更が前提なので稼働ベースの準委任、というように分けるだけで、見積書の空白が可視化されます。
本記事では、ゲームサウンドの工程分解と職種の見極めから、委託先チャネル4分類の比較、費用と契約形態の分け方、発注書に書くべき納品仕様と実装仕様、権利処理のチェックリスト、そして実機で検収する4週間の進め方までを、発注者の視点で順に整理します。読み終えたときに、社内の稟議とスケジュール表に落とせる状態になることをゴールとしています。
ゲームサウンドの外注が失敗する構造|「作る人」と「鳴らす人」の分断
ゲームサウンドの外注でつまずく原因の大半は、発注者の管理能力ではなく工程の分断にあります。まずはその構造を可視化します。
ゲームサウンドの工程を6つに分解する
ゲームのサウンドは、実際には次の6工程で構成されています。
# | 工程 | 主な作業内容 | 成果物 |
|---|---|---|---|
1 | 企画・サウンドデザイン方針 | 世界観に合わせた音の方向性決定、曲数・SE点数の洗い出し、リファレンス収集 | サウンド仕様書・曲リスト |
2 | 制作(作曲・SE制作) | BGM の作曲・編曲、効果音の制作、ジングル・サウンドロゴの制作 | WAV などの音源ファイル |
3 | 収録 | ボイス収録、生楽器レコーディング、ディレクション | 収録データ・編集済み音声 |
4 | 実装 | ミドルウェアへの登録、イベント・スイッチ設計、エンジン側の呼び出し組み込み | 動作するゲーム内サウンド |
5 | ミックス調整 | シーン間の音量バランス、ラウドネス統一、優先度制御 | 調整済みのサウンド設定 |
6 | 最適化 | 圧縮設定、同時発音数・メモリ・容量の調整、プラットフォーム別書き出し | 出荷可能なサウンドアセット |
制作会社やクラウドソーシングの見積りに含まれるのは、通常このうち工程2と、場合によっては工程3までです。工程4〜6は「ゲーム側の作業」として見積りの外に置かれます。これは制作会社が不誠実だからではなく、実装はプロジェクトのエンジン構成・仕様・スケジュールに強く依存するため、外から一律に見積もれないという事情によるものです。
実際、Wwise や CRI ADX2 を用いたデータ実装を独立したサービスとして提示している事業者も存在し、Studio10 のサウンド実装受託ページではミドルウェア実装・サウンドシステム構築・専用ツール実装が制作とは別の受託範囲として整理されています。実装は「おまけ」ではなく、それ自体が発注対象になる工程だということです。
発注者が踏みやすい3つの落とし穴
工程の分断を意識せずに発注すると、次の3つが繰り返し発生します。
落とし穴1: 実装工程の担当者が空白のまま契約する 納品物が WAV ファイルであることは合意しているのに、その WAV をゲーム内で鳴らす担当が決まっていません。結果としてクライアントエンジニアが本業の合間に対応し、ミドルウェアの学習コストを開発終盤に払うことになります。
落とし穴2: 納品仕様が「WAV でお願いします」で止まっている サンプリングレート、ビット深度、ループ点の指定方法、ラウドネスの基準値、ファイル命名規則が決まっていないと、納品後に全ファイルの再書き出しや一括リネームが発生します。150点の SE を後からリネームする作業は、それ自体がスケジュールリスクです。
落とし穴3: 権利の範囲を後回しにする 「著作権は買い取りで」とだけ発注書に書き、二次利用の範囲を列挙していないケースです。後述するように、作家側の事情で譲渡そのものが成立しないこともあり、リリース直前の交渉になると打てる手が限られます。
この記事で扱う発注の全体像
以降では、次の順序で意思決定を進めます。①自社に必要な職種を判定する、②その職種を確保できるチャネルを選ぶ、③制作と実装で契約形態を分ける、④発注書に納品仕様と実装仕様を書き切る、⑤権利範囲を発注前に確定する、⑥実機基準で検収する。この6つが揃えば、サウンドの外注は「発注してから祈る」作業ではなく、管理可能な工程になります。
ゲームサウンドの職種マップ|コンポーザー・サウンドデザイナー・実装エンジニアの違い

「ゲームサウンドエンジニア」という言葉は、発注者ごとに指している対象が違います。作曲家を指す場合もあれば、ミドルウェアを扱う実装担当を指す場合もあります。サウンドクリエイターを業務委託で確保するとき、この曖昧さがそのまま採用要件の曖昧さになり、期待とスキルのミスマッチにつながります。ここでは4つの職種を、担当工程・成果物・典型的な契約単位で切り分けます。
コンポーザー(BGM・ジングルの作曲/編曲)
BGM、ジングル、サウンドロゴなどの楽曲を作る職種です。担当するのは前掲の工程2で、成果物は楽曲ファイル。契約単位は「1曲いくら」の請負が基本で、曲の尺・アレンジの複雑さ・生楽器の有無によって単価が変動します。
コンポーザーは作曲の技能で選ぶ職種であり、ミドルウェアの知識を持っているかどうかは人によります。ゲーム向けの作曲経験が長い方はループを前提とした構成やインタラクティブな展開(レイヤー分けした音源の納品など)に慣れていますが、それは要件として明示しなければ標準では期待できません。
サウンドデザイナー(SE制作・ボイス編集・音の世界観設計)
効果音の制作、環境音のデザイン、ボイスの編集・整音、そしてタイトル全体の音の世界観を設計する職種です。ゲームでは SE の点数が BGM の数倍から十数倍になることが多く、量の管理とネーミングの一貫性がそのまま品質に直結します。
ゲーム業界では、サウンドデザイナーがミドルウェアの操作まで担当するケースが少なくありません。求人・案件情報でも DAW と Wwise の両方を要件に挙げるものが見られ、サウンドクリエイターのフリーランス案件一覧では制作と実装を横断する募集が確認できます。ただしこれは「サウンドデザイナーなら実装もできる」という意味ではなく、あくまで個人差があるため、候補者ごとにミドルウェアの実務経験年数と担当範囲を確認する必要があります。
サウンド実装エンジニア(Wwise / FMOD / CRI ADX2 とエンジン組み込み)
納品された音源をゲーム内で鳴らす職種です。Wwise・FMOD・CRI ADX2 といったサウンドミドルウェアにアセットを登録し、シーンやプレイヤーの状態に応じてどの音がどう鳴るかを設計し、Unity や Unreal Engine 側から呼び出す仕組みを組み込みます。ループ処理、クロスフェード、同時発音数の制御、メモリと容量の最適化もこの職種の守備範囲です。
Wwise エンジニアを業務委託で確保しようとするとき最初に直面するのが、母数の少なさです。ゲームエンジンのクライアント開発者と比べて絶対数が限られており、フルタイム常駐を前提にすると候補が急速に狭まります。逆に言えば、週2〜3日の稼働や特定フェーズ限定の関与であれば現実的に見つかる可能性が高く、この職種は「稼働時間を柔軟にすること」が確保成功率を上げる最大のレバーになります。
なおミドルウェアを使わず、エンジン標準のオーディオ機能だけで実装する選択肢もあります。小規模タイトルで音の状態遷移が単純なら、その方が学習コストも導入コストも低く済みます。ミドルウェアの採用可否自体を、この職種の候補者に相談してから決めるのも有効な進め方です。
オーディオプログラマー(エンジン側の音響処理・DSP・独自ツール開発)
音響処理そのものをコードで実装する職種です。独自の DSP エフェクト、リアルタイムのミキシングシステム、社内向けサウンドツールの開発などを担当します。実装エンジニアがミドルウェアの設定でデータを組むのに対し、オーディオプログラマーはその土台となる仕組みを作ります。
中小規模のタイトルでこの職種が必要になるケースは多くありません。「独自の音響表現がゲームの核になる」「既存ミドルウェアで実現できない要件がある」といった明確な理由がない限り、まずは実装エンジニアの確保を優先してください。
自社に必要な職種を判定する5つの質問
次の質問に答えると、確保すべき職種の優先順位が決まります。
- 社内にサウンドミドルウェアの実務経験者がいますか。 いなければ、実装エンジニアの外部確保を制作と同時に検討します。
- シーンやプレイヤーの状態に応じて音が動的に変化しますか。 戦闘の激しさで BGM が変化する、環境で残響が変わる等がある場合、実装工数は単純な再生の数倍になります。
- プラットフォームの容量・メモリ制約は厳しいですか。 スマートフォン向けでアプリサイズに上限がある場合、圧縮設定と同時発音数の設計が必須工程になります。
- BGM と SE の点数はどのくらいですか。 SE が100点を超えるなら、命名規則とアセット管理を設計できるサウンドデザイナーの関与価値が高くなります。
- ボイス収録はありますか。 ある場合は収録ディレクション・整音・尺調整の担当を、制作側の見積りに含めるか別立てにするかを先に決めます。
1に「いいえ」、2〜3に「はい」が付く場合、実装を外部に出さない選択はリスクが高くなります。これが、制作と実装を分離して発注すべきかどうかの最初の判断点です。
委託先チャネル4分類の比較|実装まで頼めるのはどこか

必要な職種が見えたら、次はどこで確保するかです。多くの記事は「制作会社かクラウドソーシングか」の2分類と価格比較で終わりますが、発注者が本当に知りたいのは「実装まで引き受けてくれるのはどこか」「どのくらいの期間で人が決まるか」「権利の条件を交渉できるか」です。ここでは4チャネルをその観点で比較します。
クラウドソーシング(曲・SE単位のスポット発注に強い)
ランサーズやココナラなどのプラットフォームで、個人のクリエイターに直接発注する方法です。ランサーズのゲーム音楽カテゴリのように、ゲーム向けの作曲を専門に受けている出品者が多数登録されており、曲単位・SE単位のスポット発注に向いています。
強みは着手までの速さと価格の柔軟性です。一方で、実装工程まで一貫して依頼できる人材は限られ、権利条件もプラットフォームの標準規約に依存する部分があるため、二次利用範囲を細かく設計したい場合は個別交渉が必要になります。進行管理とクオリティコントロールは発注者側の負担になる前提で計画してください。
サウンド制作会社・スタジオ(制作から実装まで一括で受けられる場合がある)
サウンド制作を専業とする会社に発注する方法です。曲・SE・収録を一括で任せられ、進行管理やディレクションも会社側が担うため、発注者の管理負荷は最も軽くなります。ジーアングルのサウンド制作サービスでは、BGM が最短2〜3週間、サウンドロゴが1ヶ月、歌ものが1.5〜2ヶ月という納期の目安が公開されており、スケジュールを組む際の基準として参考になります。
実装まで対応できるかは会社によって異なります。ミドルウェア実装を明示的にサービス範囲としている事業者もあるため、問い合わせ時に「Wwise / FMOD / CRI ADX2 のデータ実装まで対応可能か」「エンジンへの組み込みはどちらの担当か」を最初に確認してください。この1問で、見積書の空白を発注前に潰せます。
クリエイター専門エージェント(実装経験者の継続稼働を確保しやすい)
ゲーム・クリエイティブ職に特化したフリーランスエージェントやマッチングサービスを通じて、稼働ベースで人材を確保する方法です。サウンド実装エンジニアのように母数が少ない職種では、このチャネルが最も現実的な選択肢になります。週2日・週3日といった部分稼働の案件も流通しており、フルタイムを前提としない設計が可能です。
サウンドデザイナーをフリーランスとして確保する場合の単価感も、このチャネルが最も掴みやすくなります。フリーランスHub の Wwise 関連案件一覧では、サウンドデザイナーやサウンド実装まわりの案件で月額40万〜75万円というレンジが掲載されています。これはフルタイム稼働を想定した金額であり、週2日で確保するなら稼働比率に応じて見積もるのが出発点になります。曲単位でコンポーザーに発注する場合と比べて総額が大きく見えますが、そもそも比較しているものが違う点に注意してください。曲単位の発注は「納品される曲の数」に対する対価であり、月額での確保は「実装・ミックス・最適化を含めて開発期間中ずっと動いてもらう時間」に対する対価です。実装まで頼めるチャネルを選ぶかどうかは、この時間に費用を払う前提を持てるかどうかとほぼ同義になります。
エージェント経由は単価が個人直契約より高くなる傾向がありますが、契約書・稼働管理・トラブル対応の枠組みが用意されているため、社内に法務やフリーランス管理の体制が薄い場合はむしろ総コストが下がります。ボイスや音声合成まわりを含めて音関連の人材確保を検討している場合は、ボイス・音声AIエンジニアの業務委託確保も併せてご覧ください。
個人との直接契約(コストは抑えられるが権利処理と進行管理は自社負担)
過去の取引先やコミュニティ経由で、個人と直接業務委託契約を結ぶ方法です。仲介手数料が乗らないためコスト効率は最も高く、関係性ができていれば意思疎通も速くなります。
一方で、契約書の作成、権利範囲の設計、稼働管理、支払い実務、そして万一の離脱リスクへの備えはすべて自社の負担です。特に権利処理は個人ごとに事情が異なるため(後述の管理事業者への信託など)、契約前の確認項目を標準化しておく必要があります。
4チャネル比較表
比較軸 | クラウドソーシング | サウンド制作会社・スタジオ | クリエイター専門エージェント | 個人との直接契約 |
|---|---|---|---|---|
確保リードタイム | 数日〜2週間 | 2週間〜1ヶ月(見積・与信を含む) | 2週間〜1ヶ月(面談を含む) | 関係性次第(既知なら数日) |
実装まで依頼できるか | 限定的(個人のスキル次第) | 会社による(要事前確認) | 可能性が高い(要件指定で探せる) | 個人のスキル次第 |
権利処理の柔軟性 | プラットフォーム規約に依存 | 交渉可能(社内規程あり) | 交渉可能(契約書の枠組みあり) | 交渉可能だが自社で設計が必要 |
向くプロジェクト規模・フェーズ | 小規模・追加発注・試作 | 中〜大規模・一括発注 | 中規模以上・実装の継続稼働 | 小〜中規模・継続的な関係 |
単価水準の傾向 | 低〜中 | 中〜高 | 中〜高(手数料込み) | 中(仲介手数料なし) |
発注者の管理負荷 | 高 | 低 | 中 | 高 |
現実的な組み合わせとして有効なのは、制作を制作会社またはクラウドソーシングで、実装をエージェント経由のフリーランスで、並行して押さえる構成です。制作会社1社に一括で任せられるならそれが最も管理は楽ですが、実装まで対応できるかは必ず事前確認してください。対応不可であれば、その時点で実装側の打診を並行して始めることでリードタイムのロスを防げます。
費用と契約形態|曲単位の請負と実装工数の準委任を分ける
チャネルが決まったら、費用の組み立て方と契約形態を設計します。ここでの基本方針はシンプルです。成果物が明確に定義できるものは請負、作業量が読みにくく仕様変更が前提のものは準委任。ゲームサウンドではこの線が「制作」と「実装」の間に引かれます。
制作(BGM・SE)は曲/素材単位の請負で見積もる
BGM や効果音は「何をいくつ納品するか」を事前に定義できるため、曲単位・素材単位の請負が適しています。ゲーム BGM 制作の依頼費用については、スマホゲームの BGM 制作費用相場に関する解説で、30秒までのショート BGM が7万円から、2〜3分の通常 BGM が10万円からという制作会社の相場が示されています。同じ記事では、個人クリエイターの場合に1曲5,000円程度から依頼できるケースにも言及されています。価格帯が20倍近く開くのは、アレンジの複雑さ、生楽器の使用有無、制作者の実績、そして修正対応の範囲が異なるためです。
効果音の制作を外注する場合、単価は BGM より低いのが一般的ですが、点数が多いため総額では BGM に匹敵することがあります。効果音制作会社の比較記事のような一覧を参考にしつつ、見積り依頼の段階で「SE 150点、うちUI操作音30点・戦闘音60点・環境音20点・その他40点」のように内訳を提示すると、精度の高い見積りが返ってきます。
数値はいずれも公開情報に基づく目安であり、実際の金額は要件によって変動します。相場は「妥当性を判断する基準」として使い、絶対的な予算根拠にはしないでください。
実装・ミックス・最適化は準委任(稼働日数・月額)で確保する
実装工程は、仕様変更・シーン追加・バランス調整が開発終盤まで続くことを前提とすべき領域です。「Wwise へのイベント登録一式でいくら」という請負にすると、調整のたびに追加見積りと合意形成が発生し、かえって進行が遅くなります。稼働日数や月額での準委任契約にして、開発の進行に合わせて調整できる体制を作る方が実態に合います。
単価水準の目安は、委託先チャネルの比較で挙げた月額40万〜75万円のレンジが基準になります。求められる経験年数・担当範囲・稼働率によって幅があるため、週2日稼働であればその比率に応じた金額感で設計してください。月額での契約が難しい場合でも、「人日単価 × 想定稼働日数」で上限を設ける形にしておくと、仕様変更が続いても予算がコントロール可能になります。
実装の受け皿となるクライアント側の開発工数についても、あわせて見積りの前提を揃えておくと精度が上がります。エンジン側の開発費用についてはUnity開発の外注費用で整理しています。
収録(ボイス・生楽器)が入る場合の費用の分け方
ボイス収録や生楽器レコーディングがある場合、費用は次の4つに分解して見積りを取ると比較しやすくなります。
- スタジオ費用: 時間単価。収録時間の見積り精度がそのままコストに直結します
- 出演料: 声優・演奏者への報酬。使用範囲(ゲーム内のみか、プロモーション利用を含むか)で条件が変わります
- ディレクション費: 収録現場での演技指示・テイク判断。制作会社に含まれる場合と別立ての場合があります
- 編集・整音費: ノイズ処理、尺調整、ファイル分割、命名。ボイスの点数が多いほど比重が上がります
このうち編集・整音費は見落とされやすく、「収録は終わったのに使える状態のファイルが揃わない」という事態を招きます。収録の見積りを取るときは、納品されるのが未編集の素材なのか、ゲームに組み込める状態のファイルなのかを必ず確認してください。
「安すぎる見積り」で確認する5つのチェックポイント
複数社から見積りを取ると、金額が大きく離れることがあります。安い見積りが悪いわけではありませんが、次の5点は必ず確認してください。
- 実装工程が含まれているか: 含まれていないのであれば、その分の費用と担当者を別途確保する必要があります
- 修正回数の上限とリテイクの定義: 「イメージと違う」による作り直しが何回まで無償か。方向性変更は修正ではなく再制作として扱われるのが一般的です
- 権利の範囲: 譲渡か利用許諾か、二次利用(サントラ・配信・続編)が含まれるか
- 収録費と編集費の内訳: 収録ありの場合、編集済みファイルの納品まで含まれるか
- プラットフォーム別書き出しの有無: iOS / Android / コンシューマで求められる形式や圧縮設定が異なる場合、書き出し作業が誰の担当か
この5点を揃えて再見積りを依頼すると、各社の金額差の理由が説明可能になります。安い見積りの多くは「安い」のではなく「範囲が狭い」だけです。
サウンド発注書の書き方|曲リスト・納品仕様・実装仕様を1枚にまとめる

契約形態が決まったら、発注書に落とします。ここが手戻り防止の最大のレバーです。サウンド発注リストの書き方として広く共有されているのは楽曲発注の記述粒度についてですが、実装まで含めた発注では「曲リスト」「納品仕様」「実装仕様」の3ブロックを1枚にまとめる形が実務的です。
曲リスト・SEリストの粒度
曲・SE の一覧には、最低限次の列を持たせます。
列 | 記載内容の例 |
|---|---|
ID |
|
用途・シーン | タイトル画面、戦闘(通常)、戦闘(ボス)、ショップ、勝利ジングル |
想定尺 | 90秒(ループ)、3秒(ワンショット) |
ループ有無 | ループあり/なし。ループありの場合はイントロの有無 |
リファレンス | 参考にしたい楽曲・雰囲気の指定 |
優先度 | 先行実装テストに使う曲を明示(高/中/低) |
備考 | レイヤー分納品の要否、特殊な要件 |
優先度の列は特に重要です。全曲が同時に納品されるわけではないため、「どの曲が最初に必要か」を発注時点で示しておくと、後述する先行実装テストのスケジュールが立てられます。
納品仕様(WAV・ループ点・ラウドネス・ファイル命名規則)
ゲームサウンドの納品フォーマットは、次の項目を発注書で確定させてください。
- ファイル形式・サンプリングレート・ビット深度: マスターは非圧縮の WAV で受け取り、圧縮はプロジェクト側で行うのが基本です。48kHz / 24bit といった具体値を明記します
- ループ点の指定方法: ループ開始・終了位置をどう伝えるか(ファイル名、別紙のリスト、マーカー埋め込み等)。ここが曖昧だと「ループが不自然」という典型的な手戻りが発生します
- ラウドネス基準: 統一した基準値を指定します。ゲームのラウドネスについてはゲームサウンドのラウドネス基準に関する議論が公開されており、家庭用ゲーム機とスマートフォンでは想定される値が異なることが知られています。プラットフォームごとに事情が変わるため、自社タイトルの配信先を踏まえて基準値を決め、全曲・全 SE でそれを揃えることが重要です
- ファイル命名規則:
BGM_001_title.wavのように、ID・分類・内容が読み取れる形式を発注時点で定義します。150点の SE を後からリネームするコストは、規則を先に決めるコストの何十倍にもなります - プラットフォーム別書き出し: 圧縮形式や複数解像度の書き出しが必要な場合、担当と納品形式を明記します
実装仕様(ミドルウェア指定・イベント設計の分界・同時発音数・容量上限)
実装側の発注書には、次を書き込みます。
- 使用ミドルウェア: Wwise / FMOD / CRI ADX2 / エンジン標準機能のいずれか。バージョンとライセンス形態も併記します
- イベント・スイッチ設計の担当分界: サウンド側がミドルウェア内のイベント設計まで担当し、ゲーム側はイベントを呼ぶだけにするのか、それとも設計もゲーム側が持つのか。ここが最も揉めやすい境界です
- 同時発音数の上限: プラットフォームごとの想定値と、超過時の優先度制御ルール
- メモリ・容量の上限: サウンド全体で使えるメモリと、最終的なアセット容量の上限値
- プラットフォーム要件: 対象プラットフォームの音声仕様、バックグラウンド再生時の挙動、他アプリの音との共存ルール
- 確認環境: 実機確認に使う端末・機種、確認できる状態をいつまでに用意するか
実装仕様のうち特に「イベント設計の担当分界」は、1行書くだけで数十時間の手戻りを防げます。発注前に、社内のクライアントエンジニアと外部の実装担当の間で、どちらがミドルウェアを開くのかを合意しておいてください。
リファレンスの共有方法(プレイ動画・コンテ動画・世界観資料)
音の方向性を言葉だけで伝えるのは困難です。最も伝達精度が高いのは、実際のゲームプレイ動画を共有することです。ミドルウェアベンダーが公開しているサウンド発注リストの書き方に関する解説でも、リファレンスとしてプレイ動画やコンテ動画を共有する方法が紹介されています。
まだ動く画面がない場合は、絵コンテや仮映像、既存タイトルの動画に「この場面のような雰囲気」と注記する方法が次善策になります。加えて、世界観資料・キャラクター設定・UI のトーンといった資料を渡すと、作曲者側が自力で解像度を上げられます。逆に、リファレンスとして既存楽曲を挙げる場合は「どの要素を参考にしてほしいのか」(テンポ感なのか、楽器編成なのか、感情の方向性なのか)を添えないと、意図しない模倣になるリスクがあります。
修正回数とリテイク条件を先に決める
修正の扱いは、発注書で必ず定義します。決めるべきは次の3点です。
- 無償修正の回数: 1曲あたり何回までか。制作会社によっては、当初の発注範囲内であれば回数無制限としている場合もあります
- 修正と再制作の線引き: 「音色を少し明るく」は修正、「ジャンルごと変更」は再制作、といった基準を言語化します
- フィードバックの締切: 発注者側がいつまでに確認を返すか。ここを決めないと、制作側のスケジュールが読めなくなり納期全体が後ろ倒しになります
3番目は発注者側の義務を定義する項目であり、社内の確認フローを事前に整えるきっかけにもなります。誰が音の可否を判断するのか(プロデューサーか、ディレクターか、合議か)を決めておいてください。
権利処理チェックリスト|「買い取り」が通らないケースと二次利用範囲
サウンドの発注で最も後回しにされ、最も高くつくのが権利処理です。ゲーム音楽の著作権を「買い取り」で処理する慣習は業界に根強く残っていますが、これが常に成立するとは限りません。なお、業務委託契約における成果物の著作権帰属や著作者人格権の扱いといった一般論は業務委託の著作権の注意点で整理しているため、本記事ではゲーム音楽に固有の論点に絞ります。
「買い取り」が通らないケースがある(著作権譲渡と利用許諾の違い)
作曲家が著作権管理事業者に楽曲の管理を委託している場合、その楽曲の著作権を発注者に譲渡できないことがあります。管理を委託した時点で、著作権の一部または全部が事業者の管理下に置かれるためです。作家側が「買い取りには応じられない」と回答してくるのは、値段の問題ではなくこの構造によることがあります。
また、ゲーム音楽の権利処理には業界固有の事情があります。JASRAC のゲーム製作向けの案内では、ゲームに供する目的で行う複製について、事前に楽曲の著作権を管理する権利者へ利用の可否や使用料の条件を確認する必要があることが示されています。ゲーム音楽の委嘱作品をめぐる管理範囲の考え方については、ゲーム音楽と著作権に関する解説でも取り上げられています。
発注者が取れる現実解は「著作権の譲渡」だけではありません。独占的な利用許諾を受けたうえで、利用できる範囲を契約で列挙するという選択肢があります。譲渡が成立しなくても、事業上必要な使い方が全て許諾されていれば実務上の支障は生じにくくなります。どちらの形にするかは、必ず契約締結前に法務および権利者と確認してください。ここに挙げているのは確認すべき論点であり、個別案件の法的判断を示すものではありません。
先に決める二次利用範囲(サントラ・配信・実況・海外版・続編)
譲渡・許諾のいずれを選ぶ場合でも、次の利用範囲を発注前にリスト化し、契約書に書き込んでください。あとから追加するには再交渉が必要になります。
- サウンドトラックの販売・音楽配信: 物理・デジタルの両方。配信プラットフォームの範囲
- 動画配信・実況の許諾: プレイ動画に楽曲が含まれる形での第三者による配信を許諾するか
- プロモーション利用: トレーラー、SNS 広告、イベント上映、店頭 BGM
- 海外版・移植・リマスター: 対象プラットフォーム・地域・言語版の拡張
- 続編・スピンオフでの再利用: 同一シリーズ内での流用可否
- クレジット表記: 表記名・表記位置・表記義務の有無
- アレンジ・改変: 尺の変更、レイヤーの抜き差し、リミックスの可否
このリストは、発注前のチェックリストとしてそのまま使えます。特に「実況配信の許諾」はリリース後のマーケティング計画に直結するため、企画段階でマーケティング担当に確認を取っておいてください。
効果音ライブラリ・音源素材・AI生成音のライセンス確認
制作者が既存の効果音ライブラリやサンプル音源、ソフト音源を使用している場合、その素材のライセンス条件が成果物にも及びます。確認すべきは次の3点です。
- 商用利用とゲームへの組み込みが許諾されているか(ライブラリによってはゲームへの利用に別条件がある場合があります)
- 再配布に該当しないか(素材をほぼそのまま納品する形は、ライブラリによって扱いが異なります)
- クレジット表記義務があるか
近年は AI による音声・楽曲生成ツールを制作過程で使うケースも出てきています。ツールごとに生成物の権利帰属と商用利用条件が異なるため、AI 生成物を含むかどうか、含む場合はどのツールを使ったかを発注時に申告してもらう運用にしておくと、後の確認が容易になります。
ボイス収録がある場合の出演契約と再収録の扱い
ボイスが入る場合は、著作権とは別に実演家の権利と出演契約の設計が必要です。決めておく項目は次のとおりです。
- 使用範囲: ゲーム内のみか、プロモーション映像・SNS・イベントでの使用を含むか
- 期間・地域: 使用期間の制限、海外展開時の扱い
- 追加収録の条件: 追加ボイスが発生した場合の単価とスケジュール確保の方法
- 再収録(リテイク)の負担: 台本の変更や仕様変更に起因する録り直しの費用負担
- AI 音声への利用可否: 収録音声を機械学習や音声合成の素材として使用するかどうか
特に追加収録は、開発が進むほど発生確率が上がります。初回の収録契約時に追加収録の条件を含めておくと、後の日程調整が格段に楽になります。
検収とオンボーディング|実機で鳴らして確認する4週間の進め方

発注が完了したら、最初の4週間の進め方で成否がほぼ決まります。ここで重要なのは、納品物の確認を「ファイル」ではなく「実機で鳴っている状態」で行う設計にすることです。
Week1: キックオフと仕様凍結(発注書の読み合わせ)
初週は、発注書を制作側・実装側・社内エンジニアの三者で読み合わせます。目的は仕様の凍結です。特に確認すべきは、納品仕様(ループ点の指定方法、ラウドネス基準、命名規則)と実装仕様(ミドルウェア、イベント設計の担当分界、容量上限)が、全員の理解として一致しているかどうかです。
この場で必ず決めるのは、次週の先行実装テストに使う代表シーンと対象楽曲です。曲リストの優先度列で「高」を付けた曲が、そのまま候補になります。あわせて、実装担当者が触れる開発環境(リポジトリ、ビルド、実機端末)の準備期限を確定させてください。環境準備の遅れは、最も頻度が高く最も無駄なロスです。
Week2: 代表シーンの先行実装テスト(縦の串刺し)
2週目は、代表シーン1つを企画から実機まで縦に串刺しします。BGM 1曲と SE 数点だけを先行納品してもらい、ミドルウェアに登録し、実機で鳴らすところまでを通します。全体の1〜2%の量ですが、ここで検出できる問題は全体に効きます。
このテストで確認するのは、ループが自然につながるか、SE と BGM の音量バランスが想定どおりか、シーン遷移で音が破綻しないか、ファイル命名規則が実装側のワークフローに適合するか、想定した容量・メモリに収まる見込みがあるか、の5点です。ここで仕様の不備が見つかれば、残り全曲の制作が始まる前に修正できます。逆にこの工程を省くと、150点の SE が全て納品されたあとに命名規則の不備が発覚する、という最悪のケースが起こり得ます。
Week3: 一括納品とミックス・ラウドネス調整
3週目は本納品と調整のフェーズです。納品されたアセットをミドルウェアに登録し、シーンをまたいだ音量バランスとラウドネスを揃えます。この段階では個々の曲の良し悪しではなく、連続してプレイしたときの一貫性を評価軸にしてください。1曲ずつ聴くと問題がなくても、シーンを移動すると音量が跳ねる、というのは典型的な症状です。
同時に、圧縮設定と同時発音数の調整を行い、容量とメモリの実測値を取ります。この時点で上限を超えていれば、圧縮設定の変更か、アセットの整理(バリエーションの削減、共通化)で対応します。
Week4: 実機ベースの検収基準と継続契約の判断
最終週は検収です。検収基準は「WAV ファイルが仕様どおりか」ではなく、「実機で通しプレイしたときにサウンドが破綻しないか」に置きます。具体的な合格条件の例は次のとおりです。
検収項目 | 合格条件の例 |
|---|---|
ループ | 対象楽曲を3周以上再生してもつなぎ目が知覚されない |
シーン遷移 | 主要な遷移経路を通しても音量差・音切れ・二重再生が発生しない |
ラウドネス | 全楽曲・全 SE が発注書で定めた基準値の許容範囲に収まる |
同時発音 | 想定される最大負荷シーンで音抜け・優先度の誤りが発生しない |
容量・メモリ | サウンド全体が発注書で定めた上限に収まる |
ファイル管理 | 命名規則どおりで、リストと実ファイルが一致する |
この基準を満たしていれば、以降の追加発注も同じ枠組みで回せます。実装担当を準委任で確保している場合は、この時点で継続稼働の要否と稼働日数を判断してください。リリースまでの調整量を考えると、実装担当は制作が終わったあとも一定期間残す設計にしておくのが現実的です。
まとめ|今週から動かす3ステップ
ゲームサウンドエンジニアを業務委託で確保する際に決定的なのは、単価の比較ではなく「音を作る工程」と「音を鳴らす工程」を分けて設計することです。最後に、今週から動かせる3ステップに整理します。
ステップ1: 今週中に、必要な職種の判定と発注書の1枚化を終える。 先に挙げた5つの質問で、実装エンジニアの外部確保が必要かどうかを判定します。そのうえで、曲リスト・SEリスト、納品仕様(WAV・ループ点・ラウドネス・命名規則)、実装仕様(ミドルウェア・イベント設計の分界・同時発音数・容量上限)を1枚のドキュメントにまとめます。この1枚が、以降のすべての交渉の基準になります。
ステップ2: 制作と実装で契約形態を分け、チャネルに並行打診する。 制作は曲・素材単位の請負、実装は稼働日数ベースの準委任。制作会社に問い合わせる際は「実装まで対応可能か」を最初の質問に置き、対応不可であればその場でエージェント経由の実装担当探索を並行して開始します。同時に、権利の扱い(譲渡か独占的利用許諾か)と二次利用範囲のリストを法務と確認しておきます。
ステップ3: 先行実装テストを工程に組み込み、実機基準で検収する。 契約後2週目に代表シーン1つを縦に串刺しして実機で鳴らし、仕様の不備を全曲納品前に洗い出します。検収基準はファイル仕様ではなく実機でのプレイ品質に置きます。
この3ステップを踏めば、「見積りは取れているのに発注に踏み切れない」状態から、社内の稟議とスケジュール表に落とせる状態まで進めます。サウンドは開発終盤に集中しがちな領域だからこそ、発注設計の前倒しがそのままリスク低減になります。
関連情報
外部人材の活用や発注設計の進め方をまとめた資料をご用意しています。社内での検討材料としてお使いいただける内容ですので、お役立ち資料の一覧からご確認ください。
サウンドを含めたゲーム開発の体制設計や、業務委託での人材確保についてご検討中の場合は、お問い合わせフォームからご相談いただけます。要件が固まりきっていない段階でもご相談を承っています。
ゲーム開発の外注全般については、以下の記事もあわせてご覧ください。
よくある質問
- ゲームサウンドの「制作」と「実装」は同じ人・同じ発注先に任せてはいけませんか?
一括で任せられる制作会社もありますが、必ず「Wwise / FMOD / CRI ADX2 のデータ実装まで対応可能か」を発注前に確認してください。対応不可なら、実装担当を別チャネルで並行して確保する前提で計画するのが安全です。
- Wwiseなどのサウンド実装エンジニアはフルタイムでないと確保できませんか?
いいえ、母数が少ない職種のため、むしろ週2〜3日など稼働を柔軟にする方が候補が見つかりやすくなります。ゲームエンジンのクライアント開発者と比べて絶対数が限られ、フルタイム常駐を前提にすると候補が急速に狭まるためです。クリエイター専門エージェント経由なら、部分稼働を前提にした募集が現実的な選択肢です。
- 作家から「著作権の買い取りはできない」と言われた場合、発注自体を諦める必要がありますか?
諦める必要はありません。著作権管理事業者に信託している場合など譲渡が成立しないケースがありますが、独占的な利用許諾を受けたうえで必要な利用範囲を契約に列挙すれば、実務上は問題なく運用できます。譲渡が成立しなくても、事業上必要な使い方が全て許諾されていれば支障は生じにくいため、どちらの形にするかは契約締結前に法務および権利者と確認してください。
- 発注書の実装仕様で、最初に決めておかないと後で揉めやすい項目は何ですか?
イベント・スイッチ設計をサウンド側とゲーム側のどちらが担当するかという分界です。ここが未確定のまま進むと開発終盤で押し付け合いになりやすいため、契約前に社内エンジニアと実装担当の間で合意しておいてください。
- サウンドの検収は、全曲・全SEが納品されてから一括で行えばよいですか?
いいえ、それでは仕様不備の発見が遅れます。契約後2週目に代表シーン1つを縦に串刺しして実機で鳴らす先行実装テストを行い、命名規則やループ処理の問題を全曲納品前に洗い出しておくことが重要です。この工程を省くと、全曲・全SEが納品されたあとに命名規則の不備が発覚するといった、修正の余地がほとんど残らない最悪のケースが起こり得ます。



