Unityエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのUnityエンジニアがつまずきやすいのは、請負での「完成」と修正の範囲があいまいなまま受けること、機材やライセンスの負担を決めずに参画すること、既存プロジェクトの作法を知らずに壊すこと、版やパッケージを軽く扱うこと、提出前の稼働の膨らみです。どれも、会社員なら社内の決まりや先輩が受け止めてくれた部分を、外部の立場で一人で抱えることから起きます。

対策の基本は、つまずきの種を契約と参画初期の取り決めで小さくしておき、現場では記録と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、Unityならではの場面と対策を整理します。契約前に確かめたい項目の一覧はUnityエンジニアの案件の選び方で扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

請負で受けたのに「完成」の定義がない

展示用のアプリや小規模なゲームの制作では、準委任ではなく請負で受けることがあります。請負は成果物の完成を約束する契約のため、どこまでできたら完成なのかがあいまいだと、修正の依頼が終わらなくなります。「動きが思っていたのと違う」「演出をもう少し足してほしい」といった依頼が、追加の報酬なしで続く形です。

対策：対応する機種と画面の解像度、実装する機能の一覧、検収の方法と期間、修正に応じる回数や範囲を、契約の前に書面で決めておきます。準委任と請負の違いは準委任と請負の違い、範囲が広がったときの扱いは業務範囲が変わったときの記事をご覧ください。

自作のツールや購入アセットの権利があいまいになる

自分で作ったエディタ拡張やライブラリを案件で使ったところ、納品物と一緒に権利が発注側に移る契約になっていた、ということが起こりえます。また、自分の名義で買ったアセットを発注側のプロジェクトに入れると、ライセンスの条件に合わないことがあります。

対策：案件の前から持っているコードやツールを使う場合は、権利を自分に残すことを契約で取り決めておきます。購入アセットは、発注側の名義で買ってもらうのが基本です。権利の考え方はフリーランスの著作権の記事で解説しています。

機材とライセンスの負担を決めていない

検証用の端末、XRのヘッドセット、作業に使うUnityのライセンス（シート）を誰が用意するかを決めずに参画すると、自分で買うことになったり、届くまで作業が止まったりします。

対策：参画前に、機材とライセンスの用意、貸与品の扱い、自分で用意した場合の費用の負担を確かめます。貸与PCを使うときの注意は貸与PCの記事にまとめています。

現場でのつまずき

既存プロジェクトの作法を知らずに壊す

UnityのシーンやPrefabは、複数人が同時に触ると衝突しやすく、マージで内容が失われることもあります。現場ごとに、誰がどのシーンを触るか、Prefabをどう分けるか、アセットの置き場所や命名をどうするか、といった決まりがあります。これを知らずに作業すると、他の人の作業を壊してしまいます。

対策：最初の数日は、リポジトリの構成、ブランチの運用、シーンやPrefabの担当の決め方を、リードに確かめてから作業します。決まりが文書になっていない現場では、聞いた内容をメモにして共有すると、次に入る人の助けにもなります。

デザイナーやプランナーとの受け渡しがずれる

Unityの開発では、アートの素材やゲームの調整用のデータを、他の職種から受け取って組み込む作業が多くあります。受け取る形式や、どこまで調整できる仕組みを用意するかがずれると、手戻りが増えます。

対策：素材の形式、命名、調整してほしい値の範囲を、受け渡しの前に相手と確かめます。プランナーが自分で値を変えられる仕組み（調整用のデータやエディタの画面）をどこまで作るかも、作業の範囲として決めておきます。

未発表の情報や画面を不用意に扱う

ゲームや製品の開発では、未発表のタイトル名や画面、機材そのものに守秘義務がかかります。私物の端末で画面を撮る、作業中の画像をSNSに載せる、といった行動は、契約違反にあたるおそれがあります。

対策：参画時に、持ち出せる情報と端末の範囲、画面の撮影やポートフォリオへの掲載の可否を確かめます。迷ったら使わない、が基本です。

技術でのつまずき

プロジェクトと違う版で開いてしまう

手元に新しいUnityの版しか入れていないと、プロジェクトを開いたときに自動で変換が走り、元の版に戻せなくなることがあります。そのまま変更を上げると、チーム全体の作業に影響が出ます。

対策：参画したら、まずプロジェクトが固定している版を確かめ、同じ版を入れてから開きます。Unityは2026年10月時点で、LTS版を年1回出し、短い周期でUpdate版を出しているため、手元に複数の版を入れておくのが現実的です。版の動向はUnityエンジニアの将来性で整理しています。

パッケージやプラグインを独断で更新する

不具合を直すためにパッケージを新しくしたところ、別の機能が動かなくなった、というのはよくある場面です。プラグインやネイティブのライブラリは、プラットフォームごとに動作が違うこともあります。

対策：パッケージの更新は、目的と影響範囲をリードに伝え、合意してから行います。更新した場合は、確認した機種と内容を記録に残します。

エディタ上で性能を判断してしまう

エディタ上では快適に動いても、実機のモバイル端末やヘッドセットでは重い、発熱する、メモリが足りない、ということは珍しくありません。エディタの数字だけで「問題なし」と報告すると、後から大きな手戻りになります。

対策：性能の確認は、対象の実機でProfilerを使って行い、どの機種で、どの場面を、何で計測したかを添えて報告します。実機が手元にないときは、その旨を報告に書き、確認の段取りを相談します。求められる性能の知識はUnityエンジニアに求められるスキルをご覧ください。

お金でのつまずき

提出前やイベント直前の稼働超過が精算されない

ストアへの提出前、展示やイベントの直前、不具合の対応では稼働が延びやすく、精算幅を大きく超えることがあります。超えた分の扱いを決めていないと、報酬に反映されないまま負担だけが増えます。請負で受けている場合は、時間をかけても報酬は変わりません。

対策：稼働を日々記録し、精算幅を超えそうな段階で窓口に伝えます。精算の仕組みは精算幅の記事で解説しています。

機材やライセンスの費用が積み重なる

検証用の端末、Mac、ヘッドセット、有料のツールなどを自分で用意すると、案件ごとに費用がかさみます。報酬だけを見て受けると、手元に残る額が想定より少なくなることがあります。

対策：案件を比べるときは、月額の報酬と一緒に、自分で用意する機材やライセンスの費用を見積もります。事業に使うものは経費になりうるため、記録と領収書を残しておきます。扱いに迷う場合は税理士にご相談ください。

リリースや版上げの区切りで契約が終わる

リリースや版上げが終わった時点、運営の体制を縮小した時点で、契約が更新されないことがあります。フリーランス法では、6か月以上続く業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会の案内による）。

対策：契約期間と開発の節目を並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

よくある質問

参画してから、聞いていた作業と違うと気づきました。どうすればよいですか？

まずは、何が違うのかを具体的に書き出し、契約で決めた業務の範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。我慢して続けると、範囲外の作業が当たり前になり、後から戻しにくくなります。

自分の変更で不具合を出してしまったら、どうすればよいですか？

気づいた時点で、何を変えて、どこに影響が出ているかをリードに伝え、元に戻すか直すかを相談します。隠したまま直そうとすると、他の人の作業と重なって影響が広がることがあります。原因と再発を防ぐための手順を短くまとめて共有すると、信頼を保ちやすくなります。

請負の案件で修正の依頼が終わりません。どう伝えればよいですか？

契約で決めた機能の一覧と検収の条件を示し、今の依頼がその範囲の中か外かを相手と確かめます。範囲の外であれば、追加の作業として見積もりを出し、合意してから進めるのが基本です。契約の書き方に不安がある場合は、弁護士などの専門家にご相談ください。