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

「Unity で見積もりを取ってきたが、要件変更で Unity 以外のエンジンも検討することになった」— そのような相談は、フォトリアル映像品質・広域屋外シーン・LED ウォールバーチャルプロダクション・オープンソース要件などが後追いで加わった案件で頻繁に発生します。Unity で外注した経験があると、体制・予算・契約の型はすでに社内にありますが、いざ別エンジンとなると「そもそもどのエンジンを候補に入れるべきか」「エンジニアが見つかるのか」「単価はいくらなのか」の勘所がありません。

一方で稟議の場では「Unity 以外の選択肢も並べて比較したのか」「なぜそのエンジンを選んだのか」を必ず問われます。ここで説明できる資料を持たないと、意思決定は先送りされ、要件変更に対応する時間が失われていきます。多くの発注担当者が困っているのは、実は「エンジンの選び方が分からない」ことではなく「稟議で説明できる形にまで意思決定を整理する枠組みがない」ことです。

本記事では、Unity での外注経験を持つ発注担当者を想定し、Unity 以外のゲームエンジニアを外注するための意思決定を4段階に分解して解説します。「Unity 以外を検討すべきかの判定」「候補エンジンの絞り込み」「調達ルートと費用相場の把握」「発注前の情報整理」を順に押さえることで、稟議に持ち込める形の意思決定資料が完成します。

なお、Unreal Engine を選定することが確定した後の詳細な契約論点・調達手段・RFP テンプレは別記事のUnreal Engine 案件の外注ガイドに集約しています。本記事は「UE を選ぶべきか」までを扱い、選択後の深掘りはそちらへ送客する構成です。

Unity以外を検討すべきかを判定する3レイヤー・チェックリスト

「Unity 以外のエンジンも検討したほうがよい」と直感的に感じても、それが本当に必要なのか、単なる杞憂なのかを言語化するのは意外に難しい作業です。ここでは、案件要件を「経営・ライセンス制約」「品質・スケールの技術限界」「業界固有の非機能要件」の3レイヤーに分けて、Yes/No で判定できるチェックリストを提示します。1つでも Yes があれば Unity 以外の検討価値がありますが、すべて No なら Unity 継続で問題ありません。

レイヤー1: 経営・ライセンス制約の判定

Unity は 2023 年のライセンスモデル変更以降、Unity 6 世代に向けて料金体系の見直しが継続しています。ライセンスや料金構造が経営判断に影響する案件では、Unity 以外を検討する動機が最初に生まれます。以下の4つの質問に Yes があれば、レイヤー1 で該当ありです。

• 成果物のソースコードを一部でもオープンソース化する必要があるか（例: 学術研究成果・自治体発注・OSS 貢献前提のプロジェクト）
• 経営判断としてサブスクリプション型ライセンス費用を継続支払いすることを避けたいか（買い切り型または完全無料の OSS を選ぶ経営方針か）
• 商用配布時のロイヤリティや将来的なランタイム課金の発生を回避することが契約要件に含まれているか
• IP を独占的に保有したい・エンジンベンダーへの依存を戦略的に減らしたいという経営方針があるか

Yes がある場合、Godot（MIT ライセンス、完全無料、ロイヤリティなし）や自社エンジンが第一候補になります。Unreal Engine もこの層ではライフタイム総収益が100 万ドルを超えた金額に対して 5% のロイヤリティが発生するため、経営判断とのすり合わせが必要です（Epic Games ロイヤリティに関する公式ドキュメント）。

レイヤー2: 品質・スケールの技術限界判定

Unity で頑張れば実現できないわけではないが、エンジン標準機能で対応できず追加実装コストが膨らむ領域があります。この層は「Unity で作れるかどうか」ではなく「Unity 標準機能で目標品質に到達できるか」を問うのがコツです。

• 目標としているレンダリング品質は「実写と見紛うレベル」「オフラインレンダリング相当」など、フォトリアル基準に達しているか（Unity HDRP でも対応可能だが、実装コストと制作会社の得意領域が課題になるか）
• 描画スケールは「都市規模の広域屋外」「地形数十 km 四方」「大規模群衆シミュレーション」など、Nanite / Lumen などの UE 標準機能が優位に働く領域か
• パフォーマンス目標として「ネイティブに近いフレームレート」「マルチスレッド前提の並列処理」「大規模メモリ効率」が Unity 標準では届きにくい水準か
• 描画対象が「LED ウォールバーチャルプロダクション」「映像制作用のインカメラ VFX」など、放送・映画業界の実績が求められるか

Yes がある場合、Unreal Engine が第一候補になります。フォトリアル・広域屋外・LED ウォールなどの UE 特化ユースケースは、UE 標準機能が Unity より一段強いことが業界で共有されている領域です。

レイヤー3: 業界固有の非機能要件判定

業界カテゴリを列挙するのではなく「非機能要件が Unity の得意領域から外れるか」を判定するのが本レイヤーの狙いです。特定業界の案件でも、非機能要件によっては Unity 継続で問題ないケースがあります。

• 外部システムとのリアルタイム連携が必須で、Unity の C# API では性能・遅延・スレッド安全性の面で不足があるか
• 特殊な機材（産業用センサ・車載 ECU・医療機器・XR ヘッドセットの特殊 SDK）との統合が必要で、Unity 側の連携実績・プラグイン成熟度が不足しているか
• シミュレーション精度として「物理演算の科学計算相当」「決定論的な再現性」「監査可能なログ出力」など、ゲームエンジン標準の想定を超える要件があるか
• 認証基準（ISO 26262、DO-178C、医療機器 IEC 62304 など）を通す必要があり、エンジンベンダーからの説明資料・ソースアクセスが必要か

Yes がある場合、UE または自社エンジン・C++スクラッチが検討対象になります。特に認証要件がある案件は、エンジンのソースコードにアクセスできるかが選定の決め手になります。

判定サマリ表: Yes/No で次のアクションを決める

3レイヤーの Yes/No で、次章以降のどこに進むかが決まります。

Unity以外の主要ゲームエンジン選択肢マップ

判定チェックリストで「Unity 以外を検討すべき」という結果が出た読者向けに、企業案件に耐える主要4選択肢を整理します。個人開発者向けの技術比較ではなく、「発注可能性」を軸に絞り込むのが本章の目的です。

Unreal Engine: フォトリアル・広域・産業シミュの第一候補

Unreal Engine は Epic Games 提供の商用エンジンで、Nanite（大規模メッシュ描画）・Lumen（リアルタイムグローバルイルミネーション）・World Partition（広域シーン管理）などの標準機能が強く、フォトリアル映像品質・広域屋外・LED ウォールバーチャルプロダクション・自動運転車載シミュレーターなどの領域で採用実績が積み上がっています。

企業発注視点では、ロイヤリティ計算方法として「ライフタイム総収益が 100 万ドルを超えた金額に対して 5% のロイヤリティが発生」というモデルを理解する必要があります（Epic Games ロイヤリティに関する公式ドキュメント）。ロイヤリティが発生しないシートベースのライセンス（人数課金）も選択できるため、案件性質に応じた選択が可能です。

エンジニア母集団は Unity より小さいものの、日本国内でも UE 特化のフリーランス・開発会社が一定数存在し、産業案件を中心に選択肢は増えています。単価は Unity より高めで、月額 35〜100 万円超（平均 72 万円）の水準に分布しています（後述の「エンジン別・調達ルート別の費用相場」で詳述）。

Godot: オープンソース・軽量・2D 強い・ロイヤリティ回避

Godot は MIT ライセンスの完全オープンソースエンジンで、商用利用・修正・再配布に制限がなく、ロイヤリティや手数料が一切かからないことが最大の特徴です（Godot 公式ライセンスページ）。2D 表現が強く、軽量・省リソースで動作するため、モバイル・インディー・組込・小〜中規模案件で選ばれます。

企業発注視点では「ロイヤリティが確実にゼロ」「エンジンベンダーへの依存がない」「ソースコードが全て公開されている」の3点が経営判断に直結します。学術研究や自治体発注、あるいは自社サービスの一機能として組み込むケースで採用されることがあります。

弱点はエンジニア母集団の希薄さで、日本国内では Unity や UE と比べて実務経験者が明確に少なく、「Godot 特化の開発会社」というカテゴリは事実上成立していません。調達はフリーランスや個人開発者経由が中心になります（後述の「Godot の調達ルート」で詳述）。

Cocos2d-x: モバイル 2D・ハイパーカジュアル・海外案件

Cocos2d-x は中国発のオープンソース 2D ゲームエンジンで、2010 年代のスマートフォンゲームブームで広く採用されました。C++ ベースで動作が軽量、iOS/Android/Web/PC のマルチプラットフォーム対応が特徴です。

現状は移行期にあります。2019 年以降、Cocos2d-x 本体の更新は縮小し、後継の Cocos Creator（3.x 系）に開発リソースが移っています。2025 年 11 月に COCOS が SUD に買収され、2026 年 1 月には COCOS 4 が MIT ライセンスで完全オープンソース化されるなど、直近もエコシステムに動きがあります。日本国内よりも中国・東南アジアでの採用実績が厚く、日本のエンジニア母集団は小さめです。

企業発注視点では「モバイル 2D のハイパーカジュアルゲーム」「アジア圏配信を主戦場にしたタイトル」「軽量な広告連携ゲーム」など、限定的な用途で選ばれます。日本国内で調達するより海外オフショア（後述）が現実的になるケースが多いのが実情です。

自社エンジン・C++スクラッチ: 大手ゲーム会社と産業特化研究開発

自社エンジン（大手ゲーム会社の独自最適化エンジン）や C++ スクラッチ開発は、汎用ゲームエンジンでは要件を満たせない特殊案件で選ばれます。例として、AAA タイトルのパフォーマンス最適化、決定論的シミュレーション、認証を要する産業システム、研究開発プロジェクトなどが挙げられます。

企業発注視点では「エンジン特化開発会社」が事実上存在しないという点が最大の特徴です。汎用エンジンではないため、調達は SIer 子会社・研究機関・C++ エキスパートフリーランス（大手ゲーム会社出身者など）に限定されます。単価は最高水準で、案件規模も数千万〜数億円になることが一般的です。

選択肢マップ比較表

企業発注視点の4軸で主要4選択肢を並べます。エンジニア母集団の相対規模は Unity を 100 とした肌感覚の目安であり、絶対的な統計値ではなく発注時の調達難易度を測る参考値として扱ってください。

エンジン選定の意思決定フレームワーク4ステップ

候補が絞り込めたら、次は稟議に持ち込める形で意思決定を整理する段階です。単に比較表を眺めるだけでは選定理由の言語化ができないため、以下の4ステップで進めることを推奨します。

ステップ1: 案件要件の言語化（必須要件とNice-to-Haveの切り分け）

要件定義書を「必須要件」と「Nice-to-Have（あると嬉しい）」に分けます。判断が難しい要件は「必須にすると Unity 以外を選ぶ理由になる」ものです。以下の観点で切り分けを進めます。

• ビジュアル品質: フォトリアル必須か、それともスタイライズド許容か
• 描画スケール: シーン規模はどのくらいか、動的ロードが必須か
• プラットフォーム: 配信先はモバイル／PC／コンソール／XR／組込のどれか
• ライセンス: ロイヤリティ許容か、OSS 化必須か
• 認証: ISO / DO-178C / IEC 62304 などの認証要件があるか
• 外部連携: どのシステム・機材と連携するか

このステップの成果物は「必須要件リスト」と「Nice-to-Have リスト」の2表です。ここが曖昧なままだと、次のステップ以降で判断がぶれます。

ステップ2: エンジン候補との突合（要件マトリクスによる絞り込み）

ステップ1で作った必須要件リストを縦軸に、候補エンジン（Unity ／ UE ／ Godot ／ Cocos2d-x ／ 自社エンジン）を横軸に置いた要件マトリクスを作成します。各セルに「◎（標準機能で対応）／○（追加実装で対応可）／△（可能だがコスト高）／×（対応困難）」を記入します。

必須要件で×が付いたエンジンは自動的に候補外です。△が多いエンジンも、追加実装コストの見積もりが必要になります。この時点で候補は 1〜2 個に絞り込めるはずです。

ステップ3: 制約条件との照合（予算レンジ・納期・社内体制・過去実績）

技術的に対応可能なエンジンでも、以下の制約条件と合わないと選定できません。

• 予算レンジ: 想定 PoC 予算・本開発予算にエンジニア月額単価が収まるか
• 納期: 調達リードタイム（次章参照）が納期に収まるか
• 社内体制: 発注後の運用でエンジニアが社内にいる／いないによって選ぶべきエンジンが変わる（社内に UE 経験者がいなければ、外注先の説明責任が重くなる）
• 過去実績: 社内に「そのエンジンで動くコードを引き受けたことがある担当者」がいるか

この時点で「技術要件は満たすが、社内体制で維持できないから外す」という判断が入るケースも珍しくありません。

ステップ4: 稟議用の選定理由書化（3つのテンプレ視点）

最終選定したエンジンについて、稟議書に落とし込む選定理由書を「技術」「費用」「リスク」の3視点で書きます。テンプレートは以下の通りです。

• 技術: なぜこのエンジンが必須要件を満たせるか（ステップ2の要件マトリクスから抜粋）
• 費用: 予算内に収まるか、他候補と比較した費用差はどう説明できるか（ステップ3の予算照合結果）
• リスク: エンジニア調達リスク・契約リスク・将来的な保守リスクをどう軽減するか（のちほど「Unity以外のゲームエンジニアを外注する際の3つのリスクと稟議での押さえどころ」で扱う整理を活用）

この3視点でまとめられていれば、稟議での質疑応答にも対応できます。

Unity以外のエンジン別・調達ルートの違い

エンジンを選定した後、次に問題になるのが「そのエンジンで案件を引き受けられる相手をどこで探すか」です。Unity と同じ感覚で「開発会社／フリーランス／SIer／オフショア」の4ルート全てが機能するのは実は UE までで、Godot 以降はルートが大きく偏ります。エンジン別に主流の調達ルートを整理します。

Unreal Engine の調達ルート: 詳細は既存ガイドへ

UE は「開発会社／フリーランス／SIer／オフショア」の4ルート全てが機能する例外的なエンジンです。エンジン特化開発会社、UE 経験のあるフリーランス、産業案件を扱う SIer 子会社、アジア圏の UE オフショア開発会社のいずれからも調達可能です。

各ルートの詳細（特化開発会社の探し方・フリーランス直接発注の契約論点・SIer の得意領域・オフショア発注時の注意点）は別記事のUnreal Engine 案件の外注ガイドに集約しています。UE を最終選定した読者は、そちらを稟議準備のインプットにしてください。

Godot の調達ルート: なぜフリーランス・OSSコミュニティ経由が主流か

Godot は「特化開発会社」というカテゴリが事実上成立していません。エンジニア母集団が Unity や UE と比べて明確に小さく、開発会社が Godot 特化で事業を成立させるだけの案件件数がないためです。

現実的な調達ルートは以下の2つです。

• フリーランス直接発注: Godot での個人開発実績を持つエンジニアに直接発注する。案件経験というより「OSS 貢献」や「個人ゲーム開発の実績」が判断材料になる
• OSS コミュニティ経由: Godot 公式コミュニティ・GitHub コントリビューター・海外の Godot 特化スタジオ経由でスカウトする

Unity 発注の感覚で「開発会社に相談する」と進めると、まず適切な相手に辿り着けません。フリーランス調達には契約論点の複雑さ（のちほど「契約論点の複雑化」で扱うリスク）が伴うため、Unity と比べて初期の体制構築コストが増えることを想定しておく必要があります。

Cocos2d-x の調達ルート: なぜ海外オフショアが現実的か

Cocos2d-x は中国発の OSS で、日本国内よりもアジア圏（特に中国・ベトナム）に開発者コミュニティが厚い状況です。日本国内の Cocos2d-x エンジニア母集団は小さく、Unity 発注の感覚で国内調達しようとするとほぼ相手が見つかりません。

現実的な調達ルートは以下の2つです。

• 中国系開発会社: Cocos2d-x を主力にする中国系ゲーム開発会社への発注（日本法人経由での契約が実務的）
• ベトナム・東南アジアのオフショア開発会社: Cocos2d-x 実績のあるオフショア開発会社

言語障壁と契約実務の違い（時差・請求通貨・NDA・IP 譲渡条項）に注意が必要です。国内 SI とは別の稟議承認プロセスが必要になるケースもあります。

自社エンジン・C++スクラッチの調達ルート: SIer子会社・研究機関・希少なフリーランス

自社エンジン・C++スクラッチ開発は、汎用エンジンではないため「エンジン特化開発会社」が成立しません。主な調達ルートは以下の3つに限られます。

• SIer 子会社: 産業案件を主戦場にする SIer の子会社が C++ スクラッチ開発を担う（自動車・防衛・シミュレーターなどが得意領域）
• 研究機関: 大学研究室・国立研究所との共同研究プロジェクト（学術発表や特許化とセットになるケースが多い）
• C++ エキスパートフリーランス: 大手ゲーム会社出身の元エンジンプログラマーなど、極めて希少な人材への直接発注

いずれも通常のゲーム開発発注とは異なるプロセスが必要で、稟議・契約・体制構築のリードタイムが長くなります。

エンジン別調達難易度サマリ表

Unity を基準にした調達難易度の相対比較を1表にまとめます。

エンジン別・調達ルート別の費用相場

既存の外注費用相場記事の多くが Unity 前提で書かれています。本章では Unity 基準を軸に、UE / Godot / 自社エンジンの相対単価差を提示します。稟議準備の起点として使えるレンジを示しますが、案件規模・稼働率・スキル階層で大きく変動するため、目安として活用してください。

エンジニア月額単価の相対差（Unity=100 とした場合）

フリーランス・業務委託のエンジニア月額単価を、Unity 中央値を 100 とした相対値で比較します。絶対値は 2026 年時点の公開集計データに基づくレンジであり、案件性質で上振れ／下振れします。

Unity と UE の単価は上限側では大きく変わらないケースもありますが、UE は平均レンジが Unity 中央値より高い位置に張り付く傾向が業界共通の肌感覚となっています。Godot と自社エンジンは母集団の希薄さから、案件によって上振れ／下振れの振れ幅が大きい点に留意してください。

開発会社への発注時の初期構築費レンジ（用途別）

エンジンや調達ルートが同じでも、初期構築の規模で費用は大きく変わります。以下は用途別の目安レンジです（PoC〜初期リリースまでを想定）。

• モバイル 2D ゲーム（Unity / Cocos2d-x / Godot）: 500 万〜 2,000 万円
• モバイル 3D ゲーム（Unity / UE モバイル向け）: 1,500 万〜 5,000 万円
• PC/コンソール 3D ゲーム（UE 中心）: 3,000 万〜 数億円
• 産業向けシミュレーター（UE / 自社エンジン）: 3,000 万〜 数億円
• LED ウォールバーチャルプロダクション用途（UE）: 5,000 万〜 数億円

いずれもプロトタイピングフェーズ・本開発フェーズ・運用フェーズで見積もりを分ける前提です。

月次保守・運用費のレンジと固定費要素

初期構築後の月次保守・運用費で見落としがちな固定費要素があります。

• エンジニア月額単価（前掲）
• エンジンライセンス費（UE は前述のロイヤリティ／シート課金、Unity は Pro/Enterprise 課金）
• 機材費（LED ウォール用途では GPU サーバ、産業シミュレーターでは特殊機材）
• サーバー・インフラ費（オンライン対戦・データ同期がある場合）
• オンコール体制費（24 時間対応が必要な場合）

Godot・自社エンジンはエンジンライセンス費がゼロですが、エンジニア母集団の希薄さから引き継ぎコスト・後任確保コストが月次で積み上がるケースがあります。

隠れ費用（エンジンバージョンアップ・プラグイン・機材・ライセンス条件）

見積もり段階で見落とされがちな費用項目を挙げます。

• エンジンバージョンアップ対応: UE 5.x → 5.y の対応工数、Unity LTS 移行工数
• 商用プラグインライセンス: Unity アセットストア／UE マーケットプレイスの商用条件（アセットごとに配布形態の制限が異なる）
• 特殊機材のライセンス: LED ウォール用の nDisplay ライセンス、特殊 SDK の年間ライセンス費
• ロイヤリティ計算対応: UE のロイヤリティ発生分の計算・Epic Games への報告体制構築

これらは初回見積もり時に「予備費 10〜20%」として稟議段階で確保しておくことを推奨します。

発注前に整理すべき情報項目（エンジン非依存の共通チェックリスト）

発注先候補と初回打ち合わせをする前に、発注側で言語化しておくべき情報項目を整理します。エンジン共通の必須項目と、選定エンジンによって追加すべき項目に分けて示します。

エンジン共通の必須整理項目

以下 5 項目は、どのエンジンを選んでも初回打ち合わせで必ず問われます。事前に社内で言語化しておくと、見積もり精度が上がり、複数社比較の際の判断基準が揃います。

• プロジェクト概要: 目的・想定ユーザー・ビジネスモデル（B2C / B2B / 社内利用）
• 配信プラットフォーム: モバイル（iOS / Android）／PC（Steam / 自社配信）／コンソール（PS / Xbox / Switch）／XR（Quest / Vision Pro など）／組込
• 目標品質基準: フレームレート・解像度・レンダリング品質・ロード時間・想定端末スペック
• 成果物範囲: ソースコード納品／実行ファイル納品／アセット納品／ドキュメント範囲／保守期間
• KPI / SLA: 稼働率・応答時間・不具合対応 SLA・運用開始後の変更対応範囲

エンジン別の追加整理項目

エンジンによって、追加で言語化すべき項目があります。

• Unreal Engine: ロイヤリティ課金モードとシート課金モードのどちらを選ぶか、Epic Games への報告体制、Epic Games Store 配信の可能性
• Godot: OSS への貢献ポリシー（自社改造分を Godot 本体にアップストリームするか、社内フォークとして維持するか）、ライセンス表記の掲載場所
• Cocos2d-x: 海外契約時の準拠法・請求通貨・IP 譲渡条項・NDA 実施範囲
• 自社エンジン・C++スクラッチ: ソースコード開示範囲、認証取得のためのドキュメント要件、研究成果の学術発表・特許化の扱い

発注先候補への初回打ち合わせで確認すべき質問リスト

初回打ち合わせで発注先候補から聞き出しておきたい情報です。稟議での説明材料になります。

• 過去の同エンジンでの案件実績（規模・期間・成果物公開可否）
• 想定するチーム構成（担当エンジニア人数・スキルレベル・稼働率）
• リードタイム（契約締結から着手まで、キックオフから初回リリースまで）
• 障害発生時の対応体制（時間帯・SLA・エスカレーションフロー）
• 契約形態の希望（請負／準委任／ラボ型）
• IP・成果物の帰属条項の希望
• エンジンバージョンアップへの対応方針
• 撤退時の引き継ぎ範囲（ソースコード・ドキュメント・運用手順）

Unity以外のゲームエンジニアを外注する際の3つのリスクと稟議での押さえどころ

Unity 発注では顕在化しなかった3つのリスクが、Unity 以外のエンジンでは前面に出てきます。稟議で経営層に説明を求められた際、リスクを言語化できず意思決定を先送りするケースが少なくありません。ここでは3リスクとそれぞれの対策をセットで整理し、稟議資料の「リスクと対策」欄に転用できる形にします。

リスク1: エンジニア母集団の希薄さ（引き継ぎ・スケール・後任確保）

Unity 以外のエンジンでは、エンジニア母集団の絶対数が小さいことがすべてのリスクの根本原因になります。具体的には以下の 3 場面で顕在化します。

• 引き継ぎリスク: 初期実装を担当したエンジニアが離任した後、後任の確保に時間がかかる
• スケールリスク: プロジェクト拡大時にチームを増員したくても、市場から追加人材を確保しにくい
• 後任確保リスク: 数年後の保守フェーズで、当時のエンジニアが引退・転職しており、後任がゼロから学習する必要がある

対策としては、契約段階で「保守フェーズを見越したドキュメント納品を必須にする」「ソースコードコメントの日本語化を条件にする」「発注先が保守を継続的に受けられる体制であることを事前確認する」の3つが有効です。

リスク2: エンジン固有の追加費用（バージョンアップ・プラグイン・機材要件）

エンジンごとに、Unity では発生しなかった追加費用が発生します。

• UE: ロイヤリティ計算・Epic Games への報告、Epic Games Marketplace の商用プラグイン費、LED ウォール用途では nDisplay 対応機材
• Godot: OSS 上流への貢献対応工数、自社フォークのメンテナンス工数
• Cocos2d-x: 海外調達時の為替リスク・送金手数料
• 自社エンジン・C++スクラッチ: エンジン自体の保守工数・認証取得コスト

対策として、稟議段階で「エンジン固有の追加費用予備費」を初期予算の 10〜20% で確保しておくことを推奨します。この予備費項目を稟議書に明記しておくと、実際の支出発生時にも追加承認プロセスが不要になります。

リスク3: 契約論点の複雑化（ライセンス・IP・ソースアクセス・成果物範囲）

Unity では標準的だった契約テンプレートが、他エンジンではそのまま使えないケースがあります。

• ライセンス条項: エンジンライセンスの継承範囲、成果物への影響（OSS ライセンスの伝播）
• IP 帰属: 成果物ソースコードの IP、OSS 貢献分の帰属、研究成果の帰属
• ソースアクセス: 認証案件では、エンジンソースへの発注者アクセスが必要かどうか
• 成果物範囲: バイナリのみか、ソースコードを含むか、ドキュメントの言語・粒度

対策として、契約締結前にエンジン別の契約テンプレートを法務レビュー済みの状態で用意しておくこと、フリーランス直接発注ではフリーランス新法（フリーランスが安心して働ける環境づくりのための法律、2024年11月からスタート！ 政府広報オンライン）で定められた支払期日ルール（給付を受けた日から 60 日以内、かつできる限り短い期間）を遵守する体制を整えることが必須です。

稟議での押さえどころ（3リスクを3対策とセットで提示するテンプレ）

稟議書の「リスクと対策」欄に転用できるテンプレを示します。

まとめ｜Unity以外のゲームエンジニアを外注する4ステップ

Unity 発注経験者が Unity 以外のゲームエンジニアを外注する際の初動 1〜2 週間で押さえるべきステップを再整理します。

1. 要件確認: 本記事の判定チェックリスト（3レイヤー）で、Unity 継続でよいか Unity 以外を検討すべきかを Yes/No で判定する
2. エンジン選定: 選択肢マップ（UE / Godot / Cocos2d-x / 自社エンジン）で候補を 1〜2 個に絞り、4ステップの意思決定フレームワークで最終選定する
3. 調達ルート選定: エンジン別の主流調達ルートを確認し、Unity と同じ感覚で進められない部分（Godot の特化開発会社不在、Cocos2d-x の海外オフショア主流など）を稟議で共有する
4. 発注前準備: 共通チェックリスト（プロジェクト概要・配信プラットフォーム・目標品質・成果物範囲・KPI/SLA）とエンジン別追加項目を言語化し、3 リスク × 3 対策のテンプレを稟議書に組み込む

Unreal Engine を最終選定した読者は、契約論点・費用相場・調達手段・RFP テンプレを詳細に扱ったUnreal Engine 案件の外注ガイドを次のインプットにしてください。Godot ・ Cocos2d-x ・ 自社エンジンを選定した場合は、本記事の「Unity以外のエンジン別・調達ルートの違い」で扱った調達ルートの整理と、「Unity以外のゲームエンジニアを外注する際の3つのリスクと稟議での押さえどころ」で扱ったリスク対策の整理を稟議資料の骨子として活用できます。「Unity で見積もった前提が要件変更で崩れた」という状況から、稟議で説明できる意思決定資料までの距離が、この4ステップで一気に縮まります。