Unityで新規プロダクトを立ち上げたい。しかし社内にUnity経験者はおらず、経営会議までに予算根拠を固めなければならない。そんな状況で「Unity開発 外注 費用」を検索した方は、相場を紹介する記事は数多く見つかったものの、いざ稟議書に書ける根拠まで落とし込もうとすると情報が足りないと感じたのではないでしょうか。
Unity開発の外注費用は、開発の規模だけでなく、対応プラットフォーム・グラフィック品質・ネットワーク要件・素材の調達方法など複数の変数で決まります。さらに発注後には仕様変更・プラットフォーム対応追加・ライセンス改定・保守運用・素材権利など、想定外の追加コストが発生しやすい領域も存在します。相場の数字だけを知っても、「なぜその金額になるのか」を上長や経営層に説明できなければ、稟議は通りません。
本記事では、初めてUnity開発を外注する発注担当者が、経営会議・稟議での金額根拠の言語化と、想定外の追加費用の予防、発注先選定の判断軸づくりを1本で完結できるよう、以下の観点を体系的に解説します。
- Unity開発の外注費用の全体像(開発費・ライセンス費・素材費・保守運用費の4層モデル)
- 開発規模別の費用相場と、その内訳の読み方
- 費用を決める4つの要素と、金額根拠として使う整理の仕方
- 発注先タイプ(システム開発会社・ゲーム制作会社・フリーランス・オフショア)の比較軸
- 追加費用が発生しやすい5つの落とし穴と、契約・要件定義で先回りする方法
- 発注前チェックリスト(要件定義・見積取得・契約形態・保守・フェーズ分割)
読み終える頃には、社内合意を取るための金額レンジと選択肢、そして3〜5社への見積依頼に進むための判断基準が手元に揃う構成になっています。それでは、最初に費用の全体像を整理していきます。
Unity開発を外注する前に押さえるべき費用の全体像
Unity開発の外注費用を検討するとき、多くの発注担当者がつまずくのが「開発会社に支払う金額=Unity開発の全費用」と考えてしまうことです。実際には、Unity開発を進めるうえで発生するコストは複数のレイヤーに分かれており、稟議書に載せるべき金額もそれらを合算した数字になります。ここでは、まず費用の構造を4層に分解して整理します。
発注費用は「開発費」だけではない — 4層モデルで整理する
Unity開発の外注費用は、以下の4層で構成されると理解しておくと社内説明がスムーズになります。
層 | 内訳の例 | 発注段階での押さえ方 |
|---|---|---|
1. 開発費用 | 要件定義・設計・実装・テスト・プロジェクト管理 | 発注先への見積依頼で最も大きな比重 |
2. Unity本体ライセンス費用 | Unity Pro / Unity Industry のシート数分の年額 | 発注元が負担する場合と発注先が負担する場合があるため契約書で明記 |
3. 素材・アセット費用 | Asset Store 購入費・外注イラスト/3Dモデル制作費・音楽/効果音制作費 | 見積書に「素材費」として計上されるか、実費精算になるかを確認 |
4. 保守運用費用 | 納品後のOS更新対応・不具合修正・機能追加保守 | 開発契約とは別建てで見積を取得することを推奨 |
稟議書には「開発費用」のみを記載しがちですが、Unity本体ライセンス費・素材費・保守運用費まで含めた総額で試算しておくと、リリース後に「想定外の請求が来た」という事態を避けられます。特に業務系のUnity開発(研修シミュレータ・製造業向け3Dビューアなど)ではUnity Industryのライセンス費が想定以上に大きくなるケースがあるため、初期の見積依頼段階で「ライセンス費の負担者と金額」を必ず確認しておきましょう。
Unity本体のライセンス費用と開発費用の違い
初めてUnity開発を発注する担当者が特に混同しやすいのが、「Unityというソフトウェアの利用料金」と「開発会社に支払う外注費用」の違いです。この2つは全く別のコストとして扱う必要があります。
Unityのライセンスプランは、2026年時点で以下のように整理されています(Unity公式 Plans & Pricing、クラウドソーシングTimes記事)。
- Unity Personal: 個人・小規模事業者向け。年間収益・資金調達額が20万米ドル未満であれば無料で利用可能
- Unity Pro: 商用ゲーム開発向けの標準プラン。年額30万円台(2026年1月に約5%の値上げが実施され、Unity Pro および Enterprise が改定対象になりました)
- Unity Industry: 自動車・建築・製造・医療などゲーム以外の産業向け(3Dシミュレーション・デジタルツイン用途)に特化した上位プラン
なお、ゲーム開発領域で議論の的となった「Runtime Fee(インストール課金)」は2024年秋に撤回され、現在は席(シート)数ベースの定額サブスクリプションモデルに戻っています(ゲームメーカーズ記事、2024年9月)。
発注時の契約書では「ライセンス費を発注元と発注先のどちらが負担するか」「必要なシート数」「ライセンスプランはPersonal/Pro/Industryのどれか」を明記する必要があります。特に業務系のシミュレーション開発ではPersonalやProではライセンス条件を満たさず、Industryが必要になるケースがあるため、要件定義の段階で発注先と相談することを推奨します。
Unity開発 外注費用の相場(開発規模別)

費用の全体像を押さえたところで、次は稟議書に書く金額レンジの目星をつけるための相場を整理します。ここで示す数字は、複数の発注比較サイト(比較ビズ、imitsu、発注ナビ など)で示されているレンジをベースに、Unity固有の変動要因を織り込んで再構成したものです。実際の見積は必ず複数社から取得したうえで判断してください。
小規模(プロトタイプ・ミニゲーム): 100〜300万円
新規事業の初期検証(PoC)や、社内向けデモに使う小規模プロトタイプの相場帯です。このレンジで実現できるのは、単一プラットフォーム対応・限定機能のプレイアブルプロトタイプ、社内デモ用の2Dシンプルゲーム、既存Asset Storeアセットを活用したミニアプリ、といったスコープです。
内訳の目安は以下のとおりです。
項目 | 費用の目安 | 補足 |
|---|---|---|
要件定義・設計 | 20〜50万円 | 1〜2週間のプリセールス相当 |
実装(1〜2名 × 1〜3ヶ月) | 60〜200万円 | 単価40〜80万円/月 × 稼働期間 |
テスト・納品対応 | 20〜50万円 | 主要動作確認とバグ修正 |
このレンジは「まずUnityで動くものを作って、社内で意思決定材料にしたい」ケースに適合します。ただしプロトタイプの段階で作り込みすぎると本開発時に作り直しになる可能性があるため、「何を検証するためのプロトタイプか」を明確にしてから発注することが重要です。PoC段階での外注費用の考え方は PoC開発の外注費用相場 でも整理していますので、初期予算試算の参考にしてください。
中規模(アプリ・研修シミュレータ・XR PoC): 500〜1,500万円
一般消費者向けのスマホアプリゲーム、法人向けの研修シミュレータ、XR(VR/AR)の実用PoCなど、リリースを前提とした中規模開発の相場帯です。iOS/Android両対応、複数キャラクター・複数ステージ、簡易的なオンライン機能、外注イラスト・3Dモデル、といった要素を含みます。
内訳の目安は以下のとおりです。
項目 | 費用の目安 | 補足 |
|---|---|---|
要件定義・設計 | 80〜200万円 | 1〜2ヶ月のディスカバリー |
実装(3〜5名 × 3〜6ヶ月) | 350〜1,000万円 | チーム開発体制 |
素材制作(イラスト・3Dモデル・音楽) | 50〜200万円 | 内製できない場合の外注費 |
テスト・審査対応・納品 | 50〜150万円 | ストア審査・受入テスト |
この規模になるとPM・デザイナー・プログラマー・QAといった専門職の稼働が発生するため、開発体制の構成と各職能のアサインが金額を大きく左右します。見積比較のときは「何名 × 何ヶ月」の内訳を必ず確認しましょう。人月単価と工数の妥当性を発注者側で検証する観点は 工数見積もりの根拠の出し方 にまとめています。
大規模(本格ゲーム・大規模XR): 1,500万円〜数億円
商用の本格ゲーム、大型の法人向けXRトレーニング、複数プラットフォーム同時展開の大規模プロダクトなどが該当します。1,500万円は最小値であり、コンシューマゲーム機対応・フォトリアルグラフィック・オンラインマルチプレイ・大規模サーバーインフラなどが加わると、億単位に達するケースも珍しくありません。
このレンジではもはや「Unity開発の外注費用」というより、プロジェクト全体の予算計画として捉える必要があります。単発の見積依頼ではなく、フェーズを分割してPoC → プリプロダクション → 本開発 → 保守運用と段階的に発注する型が一般的です。
相場表の使い方 — レンジで社内合意を取り、詳細化はフェーズ分割で
上記の相場帯は「見積依頼を出す前に、稟議で示す予算レンジを決める」ための土台として使うものです。実際の見積金額は要件によって上下するため、社内説明では以下の順で数字を提示すると納得感が得られやすくなります。
- 開発規模の分類: 小規模/中規模/大規模のどこに位置するかを説明
- 想定レンジの提示: そのカテゴリの費用帯(例: 中規模なら500〜1,500万円)
- 上振れ・下振れ要因の説明: プラットフォーム対応数、グラフィック品質、ネットワーク要件による幅
- フェーズ分割の提案: 最初はPoCとして◯◯万円で開始し、成果を見て本開発に進むかを判断する型
このアプローチであれば、経営層に対して「見積依頼の前段階で、なぜこのレンジなのか」を根拠付きで説明できます。次はさらに一歩踏み込み、費用を決める要素を4つに分解します。
Unity開発の外注費用を決める4つの要素

同じ「Unity開発」でも、費用は数百万円から数億円まで大きく変動します。その変動を稟議で説明できる形に分解しておくと、質疑応答で「なぜ他社より高い/安い見積になったのか」に答えやすくなります。ここではUnity開発の費用を決める4つの要素として、プラットフォーム、グラフィック品質、ネットワーク・オンライン機能、素材・アセットを取り上げます。
要素1 プラットフォーム(iOS / Android / Windows / macOS / コンソール / XRデバイス)
Unityの強みはマルチプラットフォーム対応ですが、対応プラットフォームが増えるほど、以下の追加工数が発生します。
- 各プラットフォーム固有のUI/操作系(タッチ、コントローラー、視線入力など)の最適化
- 端末の性能差に合わせたパフォーマンスチューニング
- 各ストア(App Store、Google Play、Steam、Meta Storeなど)の審査対応
- 各プラットフォームのSDK・アカウント年会費(Apple Developer Program、Meta Quest Developer Hub等)
経験則としては、単一プラットフォーム対応と比較して、2プラットフォーム対応で1.5〜1.8倍、3プラットフォーム以上で2倍以上の工数が発生するケースも見られます(実際の倍率は要件・共通化しやすさ・既存コード資産により大きく変動するため、目安として捉え、必ず発注先に個別確認してください)。「最初はiOSのみで出し、需要を見てAndroid対応を追加する」という段階的リリース戦略は、費用最適化の観点で有効です。
要素2 グラフィック品質と表現(2D / 3D / リアルタイム3D / フォトリアル)
Unityは2Dゲームからハイエンドな3D表現まで対応できますが、グラフィック品質のレベルによってアーティストの稼働・レンダリング要件・端末対応の負荷が大きく変わります。
グラフィック品質 | 特徴 | 費用への影響 |
|---|---|---|
2D | イラスト・スプライトベース | 費用は最も抑えられる |
ローポリ3D | シンプルな3Dモデル | 標準的な費用帯 |
リアルタイム3D | 動的ライティング・シェーダー活用 | モデリング・シェーダー開発の稼働増 |
フォトリアル | 実写ライクの表現 | 専門アーティストと専用パイプラインが必要で費用は大幅増 |
稟議段階では「どのグラフィック品質を目指すのか」を先にビジュアルリファレンスと合わせて提示すると、見積の解像度が上がります。
要素3 ネットワーク・オンライン機能(オフライン単体 / マルチプレイ / サーバー連携)
オンライン機能の有無は、開発費用だけでなくランニングコスト(サーバー費用)にも直結します。
- オフライン単体: 追加インフラ不要。開発費用も抑えられる
- 簡易オンライン: ランキング・ログイン程度。BaaS(Firebase、PlayFab等)活用で工数と費用を抑制可能
- リアルタイムマルチプレイ: 専用サーバー・マッチングロジックが必要。開発費用は大きく増加し、月額のサーバー費用も発生
- 業務システム連携: 社内API・SSO連携などが必要な場合、認証・セキュリティ要件の実装工数が加算
稟議書には初期開発費だけでなく「月額運用費(サーバー・BaaS等)」も試算しておきましょう。
要素4 素材とアセット(自作 / Asset Store購入 / 外注イラスト・3Dモデル)
Unityの費用構造で見落とされがちなのが、素材の調達方法です。
- 自作: 内製アーティストがいる場合の選択肢。外注では発生しにくいためほぼ全ケースで外注が発生
- Asset Store購入: Unity公式マーケットプレイスから既製品を購入。1点数千円〜数万円と比較的安価だが、独自性のあるビジュアルは作りにくい
- 外注イラスト・3Dモデル: 独自ビジュアルが必要な場合。キャラクター1体で数万円〜数十万円、大量になると素材費だけで数百万円に達することもある
Asset Store購入を活用する場合は、ライセンス条件(商用利用可否・再配布可否)を必ず確認し、契約書上で権利帰属を明確にしておくことが重要です。
Unity開発の発注先タイプと費用構造の違い

Unity開発の発注先は、大きく分けて「システム開発会社」「ゲーム制作会社」「フリーランス」「オフショア開発」の4類型に整理できます。それぞれ得意分野・費用構造・ガバナンスの効かせやすさが異なるため、案件の性質に合った類型を選ぶことが発注成功の鍵になります。
システム開発会社への発注 — 業務システム・非ゲーム系Unity案件に向く
システム開発会社は、Unity単体ではなくシステム全体の設計・実装・運用を得意とする発注先です。研修シミュレータ、製造業向け3Dビューア、社内業務システムとの連携が必要な案件など、Unity開発だけでなくバックエンド・データベース・認証などのシステム統合が発生するケースに適しています。
- 費用感: 中〜高。プロジェクト管理・品質保証の体制が整っているため単価は高めだが、ガバナンスは効かせやすい
- 強み: 業務要件の整理力、システム全体の設計力、既存システムとの連携
- 注意点: ゲーム的な表現(演出・UX)は必ずしも得意ではないため、エンタメ寄りの案件では要事前確認
ゲーム制作会社への発注 — エンタメゲーム・企画伴走が必要な案件に向く
ゲーム制作会社は、企画・シナリオ・キャラクターデザイン・演出まで含めた総合的な制作を得意とする発注先です。コンシューマゲーム、スマホゲーム、企業のプロモーションゲーム、教育ゲームなど、エンタメ要素が重要な案件に適しています。
- 費用感: 中〜高。企画伴走型のため要件定義段階から稼働が発生
- 強み: ゲームデザイン、演出、キャラクター表現、ユーザー体験の設計
- 注意点: 業務システムとの統合案件では、システム設計力の面で他類型のほうが向くケースがある
フリーランスへの発注 — 小規模・PoC・追加改修に向く(準委任前提)
フリーランス(個人)への発注は、小規模プロトタイプや特定機能の追加改修に適しています。既製のシステムに新機能を追加したい、既存プロダクトの保守運用を1名体制で回したい、といったニーズに柔軟に対応できます。
- 費用感: 単価は月額60〜100万円前後が中心(FOSTERNET NAVI の Unity案件単価データ参照)。開発会社発注に比べて安価
- 強み: コスト効率、機動力、専門領域への深いスキル
- 注意点: 稼働リソースが1名に依存するためスケール性・継続性のリスクがある。契約は準委任契約が中心で、成果物保証の観点では請負より弱い
複業クラウド型のプラットフォーム(TechBand等)を通じて、企業側でガバナンスを効かせながら複数のフリーランスをチームアサインする方法も選択肢のひとつです。
オフショア開発への発注 — 大規模量産・コスト圧縮に向く
海外の開発会社に発注する形態です。ベトナム・フィリピン・インド等の開発拠点を活用することで、日本国内発注よりコストを圧縮できる可能性があります。
- 費用感: 日本国内発注の6〜7割程度に抑えられるケースが多い
- 強み: コスト効率、量産型開発の対応力
- 注意点: コミュニケーション・時差・品質管理のリスクがあり、ブリッジSEの体制構築が成否を分ける。小規模案件では管理コストが上回るため、大規模・長期案件向き
発注先タイプの比較表(費用/品質/ガバナンス/立ち上がり速度)
4類型を4軸で比較すると次のようになります(◎: 得意、○: 対応可、△: 案件による、×: 不向き)。
類型 | 費用効率 | 品質保証 | ガバナンス | 立ち上がり速度 | 適した案件 |
|---|---|---|---|---|---|
システム開発会社 | △ | ◎ | ◎ | ○ | 業務システム連携型 |
ゲーム制作会社 | △ | ◎ | ○ | ○ | エンタメゲーム・演出重視 |
フリーランス | ◎ | ○ | △ | ◎ | 小規模・PoC・追加改修 |
オフショア開発 | ◎ | △ | △ | △ | 大規模・量産型 |
自社の案件がどこに位置するかをこの表で仮判定してから、複数類型から見積を取得すると比較検討が進めやすくなります。
Unity開発の外注で追加費用が発生しやすい5つの落とし穴
Unity開発の外注で最も避けたいのが「稟議を通した金額を超える追加費用の請求」です。ここでは、実際に発注後に追加費用が発生しやすい5つの典型パターンと、それぞれ発注前に対策する方法を整理します。
落とし穴1 仕様変更 — 要件定義の粒度と変更管理プロセス
Unity開発の追加費用で最も件数が多いのが仕様変更です。「動くものを見たら追加したい要素が出てきた」「経営層のレビューで方針変更が入った」といった変更は、大きな追加見積を発生させます。
対策: 要件定義書の粒度を機能単位までブレイクダウンし、変更管理プロセス(変更要求フォーム・追加見積の合意フロー)を契約書に含めておく。変更ゼロは現実的でないため、変更の許容範囲と手続きを事前に定義することが重要です。
落とし穴2 プラットフォーム対応追加 — 後から両対応にすると倍近くなる
「まずはiOSだけでいい」と発注した後に、「やっぱりAndroidにも対応したい」となるケースは頻出します。前述のとおり、後からプラットフォーム対応を追加すると単純に工数が倍近くなるだけでなく、既存コードの再設計が必要になることもあります。
対策: 要件定義段階で「将来的な対応プラットフォーム候補」を洗い出し、初期実装時からマルチプラットフォーム前提の設計を発注先に依頼する。初期見積が多少上がっても、後追いより総額は抑えられます。
落とし穴3 Unityバージョンアップ・ライセンス改定
Unityは年次でメジャーバージョンがリリースされ、LTS(長期サポート版)の切り替えタイミングでバージョンアップ対応が必要になるケースがあります。また、Unityのライセンス料金体系自体も改定されることがあり、2024年のRuntime Fee騒動や2026年1月のPro/Enterprise 5%値上げ(Unity Pricing Changes)が実例です。
対策: 発注時にUnityのバージョン指定と、バージョンアップ対応の費用負担者を契約書に明記する。ライセンス費についても「初年度は発注先負担、次年度以降は発注元負担」など、切り替えタイミングを事前に合意しておきます。
落とし穴4 保守運用費用 — 納品後のOS更新対応・不具合修正の切り分け
「納品後もiOS/Androidの新OSがリリースされたら動作確認と修正が必要」という点を発注段階で見落とすと、リリース半年後に想定外の保守見積が届くことになります。
対策: 開発契約と保守運用契約を別建てで見積依頼する。保守契約には「対応範囲(OS更新、不具合修正、機能追加)」「対応SLA(平常時/緊急時)」「月額費用」を明記します。目安としては、開発費用の年間15〜20%程度を保守運用費として見込むという考え方が一般に言われますが、実際の比率は対応範囲・SLA・運用体制によって大きく変動します。必ず発注先と個別に協議して算定してください。
落とし穴5 素材ライセンスと権利帰属
Asset Storeで購入した素材や、外注イラスト・音楽の権利帰属を曖昧にしていると、リリース後に権利関係のトラブルや、追加のライセンス料請求が発生することがあります。
対策: 契約書で以下を明記する。
- Asset Store購入素材のライセンス費負担者と、商用利用可否の確認
- 外注イラスト・3Dモデル・音楽の著作権譲渡または利用許諾の範囲(プラットフォーム・期間・地域)
- 二次利用(プロモーション動画、グッズ展開等)の可否
素材周りの権利関係は、発注元の法務レビューを必ず経由することを推奨します。
Unity開発を発注する前の判断基準チェックリスト

ここまで整理してきた内容を、実際の稟議書・上長説明にそのまま使える形でチェックリスト化します。以下の項目に自社の回答を書き込めば、経営会議に向けた発注準備の骨格が完成します。
要件定義の粒度をどこまで詰めてから見積依頼するか
発注担当者が最初に判断すべきなのが、要件定義の粒度です。粒度が粗すぎると見積のブレが大きくなり、細かすぎると要件定義段階だけで時間とコストが膨らみます。
推奨基準: 「主要機能一覧+想定ユーザーフロー+対応プラットフォーム+グラフィック品質のリファレンス」まで固めて見積依頼するのが現実的です。詳細画面設計は発注先と一緒に詰める前提で問題ありません。
見積取得は3〜5社に依頼し、金額の内訳比較で発注判断する
1社見積は金額の妥当性を判断できません。3〜5社から見積を取得し、金額の内訳(人月単価×工数、素材費、テスト費など)を横並びで比較してください。比較時に着目すべき観点や差異の読み解き方は 相見積もり比較ガイド を参照してください。
内訳が極端に異なる場合は、要件の解釈が発注先ごとに違っている可能性があるため、要件書の追加補足や見積再依頼を検討します。
契約形態の選び方 — 準委任と請負の使い分け
Unity開発の発注では、契約形態の選定が総費用と発注リスクを左右します。
- 準委任契約: 稼働時間ベースで支払う契約。要件不確定なPoC・プロトタイプ段階に適す。仕様変更に柔軟だが、成果物保証はない
- 請負契約: 成果物ベースで支払う契約。要件確定後の本開発に適す。成果物保証はあるが、仕様変更のたびに追加見積が必要
推奨されるパターンは「PoC・要件不確定段階は準委任 → 要件確定後の本開発は請負」というフェーズ別の使い分けです。両契約の判断基準は発注者視点で 請負と準委任の違い にまとめていますので、契約書レビュー前に一読することを推奨します。
保守運用契約は開発契約と切り分けて別建てで見積依頼する
保守運用費を開発費用に紛れ込ませると、リリース後の費用構造が見えなくなります。契約書は開発契約と保守運用契約を別文書として用意し、それぞれ独立した見積を取得しましょう。
フェーズ分割発注(PoC → 本開発 → 保守運用)の型
大規模な予算を一気に承認するのが難しい場合、フェーズを分割して段階的に発注する型が有効です。
- フェーズ1: PoC(100〜300万円) — 準委任契約でコアな仕様を検証
- フェーズ2: 本開発(500〜1,500万円) — 請負契約で仕様を確定させて実装
- フェーズ3: 保守運用(月額数十万円) — 保守運用契約で継続対応
この型であれば、フェーズごとに成果物を評価してから次の投資判断に進めるため、大失敗のリスクを抑えられます。フェーズ分割・スコープ分割の具体的な設計方法や、フェーズごとの契約形態選定の考え方は スコープ分割・フェーズ分け発注 にまとめていますので、あわせてご確認ください。
発注前チェックリスト(稟議書用に転記できる箇条書き)
最後に、稟議書・上長説明に直接転記できる形の発注前チェックリストを整理します。
- 開発規模を「小規模/中規模/大規模」で分類し、想定費用レンジを提示できる
- Unity本体ライセンス費(Personal/Pro/Industry)の負担者を契約書で明記する予定である
- 対応プラットフォーム(iOS/Android/PC/コンソール/XR)を要件定義書に明記している
- グラフィック品質(2D/3D/リアルタイム3D/フォトリアル)のリファレンスを準備している
- ネットワーク・オンライン機能の必要性と、サーバー運用費の月額試算を含めている
- 素材の調達方法(自作/Asset Store/外注)と権利帰属を契約書で明記する予定である
- 発注先タイプ(システム開発会社/ゲーム制作会社/フリーランス/オフショア)の選定理由を説明できる
- 3〜5社から見積を取得し、内訳を横並びで比較する予定である
- 契約形態(準委任/請負)をフェーズ別に使い分ける方針である
- 開発契約とは別に保守運用契約を別建てで見積取得する予定である
- 追加費用が発生しやすい5つの落とし穴について、契約・要件定義で対策を織り込んでいる
このチェックリストを埋めた状態で経営会議に臨めば、「なぜこの金額になるのか」「想定外の追加費用はどう防ぐのか」に根拠を持って答えられるはずです。Unity開発の外注は、規模も選択肢も幅広い分野ですが、費用の全体像・変動要素・落とし穴・判断基準を体系的に押さえておけば、初めての発注でも失敗リスクを大きく抑えられます。まずは自社の企画を4層モデルとチェックリストに当てはめ、複数社への見積依頼へ進んでみてください。
よくある質問
- 見積もりが3〜5社で大きくバラついた場合、どう判断すればよいですか?
金額差が大きい場合はまず内訳(人月単価×工数、素材費、テスト費など)を横並びで比較してください。差の多くは要件解釈の違いから生じるため、対応プラットフォームやグラフィック品質などの補足情報を要件書に加えて再見積もりを依頼するのが安全です。極端に安い見積もりには工数不足や後出しの追加費用リスクがないかも、契約前に確認しておきましょう。
- Unity本体のライセンス費用は、開発費とは別に予算を確保すべきですか?
はい、別枠で確保してください。ライセンス費は発注元・発注先どちらが負担するかで金額の出所が変わるため、契約書で負担者・プラン(Personal/Pro/Industry)・シート数を明記しておく必要があります。
- プラットフォーム対応を後から追加すると、費用はどのくらい増えますか?
対応機種を追加すると既存コードの作り直しが発生することがあり、実際の増加率は共通化のしやすさによって大きく変わります。目安として2機種で1.5倍前後、3機種以上でさらに増える傾向はありますが、この数値だけを鵜呑みにせず、発注先に「後から追加した場合の概算差分」を事前に見積もってもらい、契約前に書面で確認しておくと追加発注時の交渉がスムーズになります。
- 保守運用費用はどのくらいを目安に見込んでおけばよいですか?
保守運用費は一般に開発費用の年間15〜20%程度が目安とされますが、対応SLA(平常時・緊急時の対応スピード)や監視体制の有無で大きく変動します。稟議段階では一律の料率で見積もるのではなく、開発契約とは別建てで保守運用契約の概算見積もりを取得し、対応範囲とSLAを契約書に明記した上で金額を確定させることをおすすめします。
- 初めての発注で、いきなり本開発から始めても問題ないですか?
要件が固まっていない段階での本開発発注はリスクが高いため推奨しません。PoC(準委任契約)で仕様やUX、技術的な実現性を検証してから、要件を確定させた本開発(請負契約)に進むフェーズ分割型のほうが、後からの仕様変更による追加費用や手戻りのリスクを抑えられます。予算が限られる場合は、まず100〜300万円規模のPoCから着手する方法も検討してください。



