Unreal Engine 案件の外注ガイド｜Unity以外のゲームエンジニア発注術

「Unity ではなく Unreal Engine（UE）で作ってほしい」— 経営層やクライアントからそう告げられた瞬間、Unity 発注に慣れた担当者ほど手が止まります。エンジンが違うだけで、なぜ発注ガイドをゼロから作り直す必要があるのか、いま社内にある Unity の稟議資料をどこまで流用できるのか、そもそも UE のエンジニアはどこにいるのか。断片情報だけで意思決定を先送りしているうちに、プロジェクトのキックオフだけが遅れていくケースは少なくありません。

UE 案件が Unity 案件と本質的に異なるのは、技術要件だけではありません。エンジニアの母集団が Unity より格段に小さく単価が高い、Epic Games のライセンス条項にロイヤリティ発生条件がある、Perforce 前提のアセット管理と C++ ビルド環境が必須になる、といった「発注構造そのものの差分」があります。これらを言語化できないまま Unity と同じ感覚で発注してしまうと、稟議段階で説明に詰まったり、契約後にロイヤリティやプラグイン費用で想定外の追加請求が発生したりする恐れがあります。

本記事は「Unity 発注は経験しているが、UE 発注は初めて」の担当者を想定し、稟議・契約・エンジニア調達・費用整理の実務に必要な差分だけを厳選して解説します。UE 発注ガイドを社内で新規に整備する際の下敷き資料として、また初回打ち合わせで発注先候補に的確な質問を投げるためのチェックリストとして活用いただける構成にしています。

前半では UE を選ぶ判断軸と費用相場を整理し、後半では調達手段・契約論点・追加費用の落とし穴・発注前に整理すべき情報項目を実務レベルで掘り下げます。Unity 案件との差分を意識した順序で並べていますので、既存の Unity 発注ガイドと突き合わせながら読み進めてください。

Unity ではなく Unreal Engine を選ぶべきユースケース

「なぜ Unity ではなく UE なのか」— 稟議で最初に問われるのはこの一点です。UE はライセンス条件・エンジニア調達難易度ともに Unity より重いため、UE を選ぶ必然性を言語化できなければ、意思決定者を納得させられません。ここでは Unity 発注経験者が UE を第一候補にすべき代表的なユースケースを整理し、逆に「Unity で十分な案件」との線引きを提示します。

UE が第一候補になる6つのユースケース

UE がプロジェクトの第一候補になるのは、以下のユースケースに該当する場合です。いずれも「UE5 の Nanite（超高精細ジオメトリの動的LOD）」「Lumen（動的グローバルイルミネーション）」「World Partition（広域マップの動的ロード）」「Chaos Physics（車両・破壊系物理）」といった、Unity では代替が難しい技術要件が絡んでいます。

1. フォトリアルなリアルタイム3D: 実写と見紛う映像品質を求められるハイエンドゲーム、CG映像制作の代替、ハイクオリティなプロダクトビジュアライゼーション
2. 広域屋外・大規模空間: 都市規模のオープンワールド、広大な自然環境、複数キロ四方の地形をシームレスに扱うシミュレーション
3. バーチャルプロダクション（LED ウォール撮影）: 撮影スタジオの LED パネル上に UE でリアルタイム背景を投影し、ポストプロダクションを短縮する映像制作手法
4. 自動運転・車載シミュレーション: 現実の道路環境を再現し、センサ・車両挙動を検証する開発用シミュレータ
5. 建築・不動産ビジュアライゼーション: 竣工前の建物内部を歩き回れるインタラクティブ内覧、都市計画の合意形成用モデル
6. 産業デジタルツイン・シミュレーション研修: 工場・プラント・大規模施設の動的可視化、危険作業の VR 訓練

UE5 は建築ビジュアライゼーション用途でも公式に強く推されており、Nanite と Lumen によりライトマップのベイクやポリゴン数削減の前処理が大幅に不要になったことで、フォトリアル案件のワークフローが根本的に変わりました（Unreal Engine 5 が建築ビジュアライゼーションの新しい扉を開く（Epic Games 公式））。自動車業界向けにも、Chaos Physics ベースの車両システムや Mass AI による交通シミュレーションが公式に提供されています（エンジンを始動させましょう — 自動車関連コンテンツが UE5 用にアップデートされました！（Epic Games 公式））。

Unity で十分な案件と UE を検討すべき案件の線引き

上記6ユースケースに該当しない場合、多くのプロジェクトは Unity で十分に成立します。以下の線引きを稟議資料に載せると、無用な UE 選定を回避できます。

「UE でしか実現できないか」を検証するチェックリスト

UE 選定の妥当性を最終確認するために、以下の6つの問いに YES/NO で答えてください。YES が3つ以上あれば UE の選定根拠として説明可能です。1〜2 個であれば、Unity でも同じ要件を満たせる可能性を再検討してください。

• ターゲットのターゲット解像度は 4K 以上、または LED ウォール投影を予定しているか
• 単一マップの広さが 1km 四方を超えるか
• 実写素材との合成、または実物と見分けがつかない映像品質を求められるか
• 車両・破壊・流体などの物理演算が本質的に必要か
• MetaHuman や Sequencer によるハイクオリティなキャラクター／シネマティック演出を必要とするか
• クライアント側または経営層が「UE で作ること」を明示的に指定しているか

Unreal Engine 案件の外注費用相場

UE 案件の費用相場は、Unity 案件と同じレンジで語ると必ず稟議で撥ねられます。エンジニアの単価水準・技術難易度・機材要件のいずれもが Unity より重いため、初期構築費・月次保守費とも 1.1〜1.5 倍を目安に組む必要があります。ここでは用途別と発注先タイプ別の2軸で相場を提示し、Unity との差分の根拠も示します。

用途別の費用レンジ

代表的なユースケース別に、初期構築費の目安を整理します（あくまで市場観測値の中央値であり、要件により大きく変動します）。

海外の市場観測では、UE のゲーム開発費用は Indie 規模で 10,000〜20,000 USD（約 150〜300 万円、開発期間 6〜12 ヶ月）、Mid-Level で 25,000〜80,000 USD（約 400〜1,200 万円、1〜2 年）、AAA タイトルで 100 万〜1,000 万 USD（約 1.5〜15 億円、2〜5 年以上）と、案件規模により相場帯が大きく分かれると報告されています（True Unreal Engine Game Development Cost in 2026（Juego Studio））。日本市場でも同様に、Indie/中規模/AAA で相場帯が明確に分かれます。Unity 案件の費用構造との比較はUnity開発の外注費用にまとめていますので、Unity 案件の見積根拠と突き合わせる際に参照してください。

発注先タイプ別の単価水準

同じ案件でも、発注先タイプによって単価水準は大きく異なります。日本市場の実勢をもとに月額単価の目安を整理します。

フリーランス市場では、Unreal Engine 案件のフリーランスエンジニア月額単価は平均 72 万円で、最低 35 万円〜最高 100 万円以上のレンジに広く分布しています（Unreal Engine のフリーランス案件・求人一覧（フリーランス Hub））。案件の要件難易度・実務経験年数によって振れ幅が大きく、シニアな UE エンジニアはレンジ上限付近に張り付く傾向があります。業界別・スキル別の詳細な単価内訳はUnreal Engine フリーランス単価の実態で扱っていますので、単価水準の背景を掘り下げたい場合はあわせてご覧ください。

Unity 案件と比べた費用差分の要因

「なぜ UE は Unity より高いのか」を稟議で説明するには、以下の3要因を根拠として提示します。

1. エンジニア母集団の希薄さ: UE エンジニアは Unity エンジニアの数分の1程度の規模しかいません。特に商用製品での UE5 実務経験者は極めて希少であり、市場原理として単価が上振れします
2. 技術習得コストの高さ: Blueprint と C++ の二層構造、Perforce によるバイナリアセット管理、UE5 の新機能（Nanite/Lumen/World Partition）の使いこなしなど、Unity より習得すべき技術スタックが広いため、シニア人材への依存度が高くなります
3. 機材・環境コスト: 高性能な開発マシン（GPU 上位モデル・大容量メモリ・大規模ストレージ）、コンパイル用ビルドサーバー、Perforce サーバー、LED ウォール等の特殊機材が案件によって必須になり、これらの償却が単価に反映されます

Unreal Engine エンジニアを外注する4つの調達手段

UE エンジニアは希薄な人材市場のため、「探せば見つかる」前提で発注計画を組むと必ず遅延します。ここでは実務で頻用される4つの調達手段の特徴と、案件フェーズ別の使い分け方を整理します。

UE 特化開発会社（映像プロダクション出身系・ゲーム制作会社系）

もっとも安定した調達手段は、UE 開発ラインを常設している国内の開発会社への発注です。大きく2系統に分かれます。

• 映像プロダクション出身系: バーチャルプロダクション・建築ビジュアライゼーション・産業デジタルツインに強い。フォトリアル・シネマティック演出のノウハウが厚い一方、ゲームロジック実装は弱い場合があります
• ゲーム制作会社系（UE ライン）: PC/コンソールゲーム制作でパイプラインを保有。ゲームロジック・ネットワーク・マルチプラットフォーム対応に強い一方、映像制作系の案件では割高になる場合があります

いずれも案件規模が中〜大（1,000 万円以上）でないと受注してもらえないケースが多く、PoC 段階では次項のフリーランスエージェント経由を並走させる運用が現実的です。

フリーランス直接発注（案件エージェント経由 vs 直接）

即戦力の UE エンジニアを短期・中期で確保する場合、フリーランスエージェント経由の準委任契約が主流です。

• エージェント経由: 週2〜5日の稼働で調達可能。契約・請求・稼働報告はエージェント側が一元管理するため、発注側の事務工数は小さくなります。単価は先ほどのフリーランス Hub 実勢に沿って月 35 万〜100 万円超のレンジで振れ、シニア UE エンジニアはレンジ上限帯に固まります
• 直接発注: 単価を10〜20%圧縮できる代わりに、契約書・請求書処理・稼働管理の負荷が発注側に返ってきます。UE 案件の場合、まず信頼関係のある少数のエンジニアと直接契約でスタートし、規模拡大時にエージェント経由を混ぜる形が多く見られます

いずれの場合も、成果物範囲の切り分け（.uproject ソース・ビルド済み配布物・ドキュメント）を契約書で明示することが重要です。詳細は次章の契約論点で扱います。

SIer・大手SI子会社（産業案件・自動車シミュ向け）

自動車 OEM／製造業／金融／官公庁向けなど、社内セキュリティ・調達プロセスの制約が厳しい案件では、大手 SIer またはその子会社への発注が現実的な選択肢になります。

• メリット: 品質保証プロセス（テスト計画・レビュー・ドキュメント整備）が標準装備。既存の情シス調達フローに乗せやすい
• デメリット: 月額単価が 150 万〜250 万円と高く、UE 実務経験者を安定的にアサインできる SIer は限られる。UE5 の最新機能を能動的に使いこなす体制は薄い場合があります

産業案件は「エンジンの選定より、既存業務システムとの接続と運用体制」が重視されがちです。UE の技術に固執せず、SI の統合力を優先して選定する判断が必要になります。

オフショア（ベトナム・フィリピン・インド）の現実

Unity 案件では有力な選択肢だったオフショアも、UE 案件では慎重な運用が求められます。

• UE 実務経験者の絶対数がオフショア各国でも少なく、Unity と同じ感覚で「安価な人月」を大量調達することは困難です
• Blueprint 主体の案件は現地エンジニアでも回りやすいですが、C++ ネイティブ層に踏み込む案件（プラグイン開発・エンジン改造）はブリッジエンジニアの技術力に強く依存します
• Perforce による大容量アセット同期は、拠点間の回線速度・タイムゾーン差の影響を受けやすく、運用設計を発注側でリードする必要があります

オフショアを使うなら、まず PoC を国内フリーランスまたは開発会社で回して要件と成果物を固め、量産フェーズでオフショアに切り出す二段構えが現実的です。

案件フェーズ別の使い分け（PoC → 本開発 → 長期運用）

上記4手段を単純に並列比較するのではなく、案件フェーズと組み合わせて使い分けます。

長期運用フェーズでは、UE そのものの実装だけでなくゲーム／サービス運営基盤（課金・カスタマーサポート・LiveOps）の外注設計も同時に必要になります。運用系機能の外注では「監査ログ・承認フロー・SLA を発注側が握った上でパートナーに載せる」設計が定石で、ゲーム業界の運営・課金基盤の外注に具体的なパターンを整理しています。

Unreal Engine 案件で押さえるべき7つの契約論点

本記事の中核となる章です。UE 案件では、Unity 発注では顕在化しない契約論点が複数存在します。稟議通過後に契約書レビュー段階でトラブルにならないよう、発注前に法務と共有すべき7つのチェックポイントを整理します。

Epic Games ライセンス条項の理解（Standard / Creators / Enterprise の使い分け）

UE の商用利用は Epic Games のライセンス条項に従います。用途別に3つのプランが存在し、正しく選ばないと後述のロイヤリティ発生条件やシート課金モデルが発注側の想定と食い違います（Unreal Engine (UE5) licensing options（Epic Games 公式））。

• Standard: ゲーム・エンターテインメント用途向け。100 万ドル閾値以下は無償、超過分に対して 5% のロイヤリティが発生
• Creators: 学生・個人クリエイター・小規模スタジオ向け
• Enterprise（シート課金）: 建築・製造・自動車・産業デジタルツインなど非ゲーム用途向け。年間売上 100 万ドル超の企業はシート課金の対象になります

自社案件が「ゲーム」なのか「非ゲーム」なのかで適用プランが変わるため、企画段階で Epic Games または販売代理店に確認しておくことを推奨します。

ロイヤリティ発生条件（100万ドル閾値）と発注側の負担範囲

ゲーム用途では、プロダクトの生涯累計売上が 100 万ドル（USD）を超えた時点から、超過分に対して 5% のロイヤリティが発生します（2025年1月以降、Epic Games Store で他ストアと同時またはそれ以前に配信する場合は 3.5% に減額）（Submit and Manage Unreal Engine Royalties（Epic Games 公式）、Epic Games to cut royalty rate on Unreal Engine games（CG Channel、2024年10月））。

発注側が押さえるべきは以下の点です。

• ロイヤリティの支払い義務者は原則として「製品を販売する事業者」であり、開発を受託した会社ではありません。したがって発注側（自社）が支払い義務を負うケースが多数です
• 開発会社に「ロイヤリティ込み」で見積もらせると、100 万ドル閾値未達なら支払いが発生せず二重取りになるため、契約段階で切り分けることを推奨します
• 非ゲーム用途はロイヤリティではなくシート課金モデルになるため、開発中の同時利用シート数を見積もっておく必要があります

ソースコードアクセス権（EULA と Enterprise 契約の違い）

UE はエンジンソースコードを GitHub で公開しており、EULA を受諾したユーザーは基本的にソースコードにアクセスできます。ただし発注側が押さえるべき論点があります。

• 「エンジン改造版を継続的にメンテナンスする体制」は開発会社側の資産になりがちで、開発会社が離脱した瞬間にビルドできなくなるリスクがあります
• Enterprise 契約では、より厳密なサポートとカスタムビルドの権利が含まれる場合があります。産業案件・車載シミュレーション等では Enterprise 契約が実質的に必須になります
• 契約書には「エンジン改造の有無」「改造版のメンテナンス責任」「開発会社離脱時のエンジンビルド再現性」を明記することを推奨します

独自プラグイン・Marketplace 素材の IP と再利用可否

UE 案件は Marketplace（Fab）で購入した有償プラグイン・アセットに依存するケースが多く、契約段階で扱いを整理しないと後で揉めます。

• Marketplace アセットのライセンスは「シート単位」「プロジェクト単位」で条件が異なります。発注先が購入したアセットを自社の別プロジェクトで再利用できるかは、原則としてライセンス次第です
• 開発会社が自社の独自プラグインを組み込む場合、その部分の IP が開発会社側に残ることが一般的です。成果物を第三者に譲渡・再委託する予定がある場合、契約書で IP 帰属を明示してください
• 使用したプラグイン一覧・ライセンス費用の発注側負担範囲は、初回打ち合わせで必ず確認する項目です

Perforce・大容量アセット管理環境の準備責任分界

UE 案件は Git ではなく Perforce（Helix Core）をバージョン管理に採用するケースが大半です。バイナリファイル（テクスチャ・モデル・オーディオ）が数百 GB 単位で発生するため、Git の LFS では運用が破綻します。

• Perforce サーバーを発注側で持つのか、開発会社側で持つのかを契約段階で決めます。データの最終所有権を明確にするには、発注側で持つのが原則です
• Perforce のライセンス費用（Helix Core は無料枠あり、超過分は有償）、ストレージ費用（数TB〜数十TB）、バックアップ体制を予算に含めてください
• リポジトリの引き渡し方法（プロジェクト完了時に発注側が受け取る形式）を契約書に明記します

C++ ビルド環境の共有（Windows / macOS / Linux / コンソール）

UE の C++ プロジェクトは、各ターゲットプラットフォーム向けに個別のビルド環境が必要になります。

• 開発マシン（Windows 中心）に加え、コンソール向けビルドには各コンソールメーカーの開発者アカウント・SDK が必須です。取得・登録には数週間かかる場合があります
• ビルドサーバー（Jenkins・TeamCity・Buildkite 等）の構築責任・費用負担を契約書で切り分けます
• 発注側が最終成果物を自前でビルドし続ける想定なら、ビルド手順書とビルド環境構築マニュアルを納品物に含めることを推奨します

成果物範囲（.uproject 構造・ソース／ビルド済み配布物の切り分け）

「納品物とは何か」を UE 案件で正確に定義するには、Unity 案件より一段細かい記述が必要です。

• .uproject プロジェクトフォルダ一式（ソースコード・アセット・設定）
• ビルド済み配布物（Windows/Mac/コンソール向けバイナリ）
• ドキュメント（ビルド手順書・環境構築マニュアル・使用プラグイン一覧・アーキテクチャ概要）
• Perforce リポジトリのダンプまたはアクセス権譲渡

上記のうち、どこまでを納品物とするかを契約書に明示します。特に「ビルド済み配布物のみ納品」で契約するとソースコードが手元に残らず、後続の改修・保守が発注先に固定化されるリスクがあるため、案件終了時のリスク移管を意識した契約設計が必要です。

Unreal Engine 案件で発生しやすい追加費用と回避策

UE 案件では「想定外の追加費用」が発生しやすい5パターンがあります。いずれも Unity 案件では見過ごされがちですが、UE 案件では契約段階で対策を織り込んでおかないと稟議差し戻し要因になります。

UE エンジンバージョンアップ（UE4 → UE5、UE5.x → 5.x+1）の再検証コスト

UE のマイナーバージョンアップ（5.3 → 5.4 など）でも、Nanite・Lumen の挙動変更、プラグイン互換性、レンダリング品質の差分が発生します。開発期間中にエンジンを追随更新するか、あるトップバージョンで固定するかを事前に決めます。

• 回避策: 契約書に「開発期間中のエンジンバージョンは着手時点で固定」「バージョンアップ対応は別途スコープ・費用として扱う」旨を明記。長期運用案件は年次アップデート枠を予算化してください

有償プラグイン依存（Marketplace・サードパーティ）の追加ライセンス費

Marketplace で購入するアセット・プラグインが数十点に及ぶことがあり、合計ライセンス費が数十万〜数百万円に達する場合があります。

• 回避策: 契約書に「使用予定プラグイン一覧と累計ライセンス費」を添付。継続課金型のプラグインは月額 vs 年額の切り分けも明示

機材要件の想定違い（開発マシン・LED ウォール・キャプチャ機材）

UE5 の Nanite/Lumen をフル活用するには高性能な開発マシンが必要になります。バーチャルプロダクション案件では、LED ウォール・カメラトラッキング機材・GPU 拡張サーバーの手配も発生します。

• 回避策: 発注先の推奨機材スペック・開発マシン所有者（発注側 or 開発会社）・特殊機材の調達責任者を契約書に明記

コンソール・XR プラットフォーム移植の追加コスト

「まず PC 向けに作って、あとから PS5 / Meta Quest / Vision Pro に展開」というプロジェクトは、コンソール／XR 対応のプラットフォーム認証・SDK 統合・機材要件で追加費用が発生します。

• 回避策: 「移植先プラットフォームは着手時点で固定」「後追いのプラットフォーム追加は別スコープ」と契約書に明記。プラットフォームメーカーの開発者アカウント取得責任者も明示

ライティング・ポストプロセス品質の再調整（Lumen / Nanite / Ray Tracing）

フォトリアル案件では「制作中盤にクライアントから映像品質のダメ出し」が入り、Lumen 品質設定・Nanite の閾値・ポストプロセスチェーンの再調整が数週間単位で発生することがあります（Nanite やLumen の仕組みや注意点を解説（ゲームメーカーズ、2023年12月））。

• 回避策: 契約書に「ライティング品質は着手時点のリファレンス画像でロック」「後続の品質チューニングは別スコープ」旨を明記。マイルストーンごとのビジュアルレビューを設定し、大幅な差戻しを防ぐ

発注前に整理すべき情報（UE 案件向け RFP テンプレート）

初回打ち合わせの前に、発注側で言語化しておくべき情報を項目化します。Unity 案件用の RFP テンプレをそのまま流用できない UE 固有項目に絞りました。以下をそのまま社内資料にコピーして、部門横断で埋めていくと初回打ち合わせが格段にスムーズになります。

プロジェクト概要（配信プラットフォーム・目標フレームレート・解像度）

• ターゲットプラットフォーム: PC（Windows/Mac/Linux）／PS5／Xbox Series X|S／Nintendo Switch／Meta Quest／Vision Pro／モバイル／LED ウォール
• 目標フレームレート: 30fps／60fps／90fps／120fps（VR/ARは90fps下限を想定）
• 目標解像度: 1080p／1440p／4K／8K／VR ヘッドセット別ネイティブ解像度
• リリース想定時期・段階リリースの有無

必要な UE 機能（Nanite / Lumen / Chaos / MetaHuman / World Partition / Sequencer）

以下から必要機能をチェック（複数選択）。案件により不要な機能を落とすと、対応可能な発注先候補が広がります。

• Nanite（超高精細ジオメトリの動的LOD）
• Lumen（動的グローバルイルミネーション）
• Chaos Physics（車両・破壊・流体）
• MetaHuman（フォトリアルキャラクター）
• World Partition（広域マップの動的ロード）
• Sequencer（シネマティック演出）
• Niagara（VFX）
• MassAI（大量AI・群集）
• Blueprint 主体 or C++ 主体

資産管理・開発環境（Perforce の運用体制・ビルドサーバー・機材）

• Perforce サーバーの所有者（発注側 or 開発会社）・想定ストレージ容量・バックアップ体制
• ビルドサーバーの構築責任者（発注側 or 開発会社）
• 開発マシンの調達責任者（発注側支給 or 開発会社自己所有）
• 特殊機材の一覧と調達スケジュール

権利帰属・ソースコードの取り扱い（EULA 遵守と成果物の所有権）

• Epic Games EULA の遵守は前提。プランは Standard／Creators／Enterprise のいずれか
• ロイヤリティ支払い義務者（原則発注側）と、開発会社への通知タイミング
• ソースコード・アセットの著作権帰属先
• 独自プラグイン・Marketplace アセットの IP 帰属と再利用可否
• 案件終了時の Perforce リポジトリ譲渡方法

KPI と SLA 目標（納品品質基準・パフォーマンス指標）

• 目標フレームレート達成率（例: 主要シーンで 60fps を 95% 維持）
• ロード時間の許容範囲
• メモリ使用量の上限
• クラッシュ率の許容範囲（例: セッションクラッシュ率 0.5% 未満）
• 保守運用フェーズの応答時間・稼働時間

Unity・Unreal Engine 以外の選択肢の位置づけ

「Unity 以外」というテーマの派生として、UE 以外にも存在するゲームエンジンが発注検討の対象になるケースを短く整理します。本記事のスコープは UE 中心ですが、UE ありきで検討を進めた結果「実は別の選択肢が最適」というケースを見落とさないための保険としてお読みください。

Godot が候補になるケース

オープンソースかつ完全無料（ライセンス料・ロイヤリティなし）のゲームエンジンです。2D 表現・軽量アプリ・独自ライセンスを避けたいプロジェクトで採用されます。

• 向いている案件: インディーゲーム、教育コンテンツ、社内ツール、シンプルな 2D シミュレーション
• 不向きな案件: フォトリアル 3D、AAA タイトル、大規模チーム開発

Cocos2d-x が候補になるケース

モバイル 2D ゲーム・ハイパーカジュアルゲーム向けに強いオープンソースエンジンです。中国・東南アジア市場では特に高いシェアがあります。

• 向いている案件: モバイル 2D ゲーム、軽量ハイパーカジュアル
• 不向きな案件: 3D 表現、コンソール展開、複雑な物理演算

自社エンジン・独自技術の選択肢（大手ゲーム会社・産業特化）

大手ゲーム会社や産業特化領域では、UE でも Unity でもなく自社エンジンや独自技術を選定する場合があります。

• 向いている案件: 極めて特殊な要件（低レイテンシ通信・独自ハードウェア）、長期的な技術戦略上エンジン内製化が必要な案件、大手 IP タイトル
• 不向きな案件: 短期リリース、社外パートナーとの共同開発、コスト最小化案件

自社エンジン選定は数億円規模の初期投資と数十人規模の内製チームが前提となるため、多くの発注検討ケースでは選択肢から外れます。ただし「自社エンジンで作りたい」というクライアント要望が出た場合、この判断軸を持っていると初期の意思決定を早められます。

まとめ｜Unreal Engine 案件の発注前に確認する4ステップ

本記事の要点を「Unity 発注経験者が UE 発注に踏み込む最初の1週間」の実務ステップに落とし込みます。以下の4ステップを順に進めれば、稟議・発注準備の初動を効率化できます。

1. UE 選定の必然性を言語化する: 先ほど整理した6つのユースケースと6問チェックリストで、「なぜ Unity ではなく UE か」を稟議資料に落とし込みます。YES が3つ未満なら Unity 継続を再検討してください
2. 費用レンジと単価水準を稟議資料に組み込む: 用途別・発注先タイプ別の相場テーブルを元に、初期構築費・月次保守費のレンジと Unity 案件比の差分要因（母集団の希薄さ・技術習得コスト・機材費）を明示します
3. 調達手段をフェーズ別に組み合わせる: PoC はフリーランス、本開発は開発会社、長期運用はフリーランス小規模チーム、産業案件は SIer 主契約、といった案件フェーズ別の使い分けを事前に計画します
4. 契約論点と RFP テンプレを法務・情シスと共有する: Epic Games ライセンス条項、ロイヤリティ発生条件、Perforce 運用体制、成果物範囲の切り分けを、初回打ち合わせ前に法務・情シスと共有し、発注先候補に投げる質問リストとして整えます

Unity 発注のノウハウをそのまま流用できない領域はここで整理した通り限定的で、差分を押さえれば大部分の実務は既存のプロセスに乗せられます。UE 案件を「未知の領域」ではなく「差分を織り込んだ Unity 発注」として扱えれば、意思決定の先送りは解消できます。本記事が、社内 UE 発注ガイドの下敷きとして役立てば幸いです。