ゲーム開発エンジニアの年収相場｜Web系との評価の違いと企業タイプ差286万円

ゲーム開発エンジニアの年収は、「ゲーム業界だから低い」でも「ゲーム業界だから高い」でもありません。同じゲーム開発でも、勤め先の事業構造と自分が持っている担当領域で大きく変わります。検索して出てくる業界平均が自分に当てはまらないと感じるのは、平均が両方を混ぜた数字だからです。

先に結論を書きます。ゲーム開発の経験を年収へ変換できるかどうかは、開発費を誰が負担しているか（受託か自社の事業か）、実装だけを担当しているか設計や基盤まで持っているか、その経験を社外の人が読める形で説明できるか、の3点で決まります。ゲームエンジンを何年触ったかより、この3点のほうが効きます。

ゲーム開発の年収を決めるのは業界ではなく企業タイプと担当領域

結論から言えば、ゲーム開発エンジニアの年収を最も強く動かすのは企業タイプです。これはゲーム開発に限った話ではなく、このサイトが扱ってきた全職種で共通しています。事業の利益率と商流の深さが、その会社が人件費へ回せる金額の上限を決めるためです。

理由は単純で、受注した金額の何割が自社に残るかが会社ごとに違うからです。元請けとして企画から運用まで持つ会社と、工程の一部を請け負う会社とでは、同じ人数・同じ工数を投じても手元に残る金額が変わります。個人の技術力は、その残った金額の内側でしか反映されません（企業タイプ別の年収相場）。

具体例を挙げると、同じUnityでのクライアント実装を担当していても、自社タイトルの収益に責任を持つ会社の社員と、開発工数を人月で提供する会社の社員とでは、評価の原資が別物です。前者はタイトルが当たれば原資が増えますが、後者は契約単価が上がらない限り増えません。

注意点として、企業タイプは「大きい会社かどうか」ではありません。従業員数が多くても工程の一部を担う位置にいることはありますし、少人数でも自社IPの収益を直接受け取っている会社はあります。判断すべきは規模ではなく、開発費の出どころと意思決定の位置です。

ゲームソフトウェア業は統計上どこに入るのか

ゲーム会社の給与水準を調べるとき、どの統計を見ればよいのか迷います。結論としては、情報通信業の統計が最も近い参照値になります。

総務省の日本標準産業分類では、ゲームソフトウェア業は中分類「情報サービス業」の中の小分類「ソフトウェア業」に置かれた細分類で、大分類では情報通信業に含まれます。つまりゲームソフトの開発会社は、受託開発ソフトウェア業やパッケージソフトウェア業と同じ大分類に並びます。

そのため参照値としては、情報通信業の平均給与 660万円（令和6年（2024年）） が出発点になります。ただしこの数字は平均で、同じ産業の中に未経験から管理職までが含まれています。分布の真ん中に近い値として推計した中央値は 585万円 で、平均との間には開きがあります。1,000万円を超える人の割合が 13.2% あり、上側に引っ張られた平均になっているためです。自分の位置を測るときは、平均ではなく中央値のほうを基準にしてください。

注意点があります。ゲーム事業を持つ企業がアミューズメント施設の運営や玩具の製造を併せ持つ場合、その企業全体は別の産業に分類されることがあります。産業分類は事業所の主な活動で決まるため、「ゲームを作っている会社の統計」を一つの数字で代表させることはできません。参照値はあくまで出発点として扱ってください。

経験年数で推定レンジはどう動くか

産業平均は出発点にすぎないので、ここからは条件を揃えた推定レンジで見ます。上場・大手／東京勤務／スキル中位という条件を固定し、実務経験年数だけを変えるとこうなります。

この表の読み方は2つあります。1つは、経験年数が増えれば自動的に上がるわけではなく、条件を固定したときの水準を示しているという点です。もう1つは、各行が幅を持っているという点で、同じ年数でもスキルの評価によって上下します。

適用できないケースもあります。この表は企業タイプを上場・大手に固定しているため、受託中心の中小企業やSESの契約で常駐している場合は当てはまりません。また、年俸制で賞与が年収に含まれている会社と、月給＋賞与で変動幅が大きい会社とでは、同じ提示額でも受け取り方が変わります（年俸制は損か）。

同じ実務10年以上でも企業タイプで286万円開く

経験年数を実務10年以上に固定し、企業タイプだけを変えると次のようになります。ゲーム開発は一つの会社に長く在籍する人が比較的多い領域なので、年数が積み上がったときに何が起きるかを見ておく意味があります。

上端と下端で 286万円。10年以上かけて積み上げた経験が、企業タイプの違いだけでこれだけ離れます。実務3〜5年の時点でも同じ構造の差はありますが、年数が増えるほど差は開きます。倍率で効く係数だからです。

ここから読めるのは、ゲーム開発を長く続けること自体は年収の保証にならないということです。同じ年数を過ごしても、開発費の出どころが変わらなければ、上端へは近づきません（経験年数だけ増えて年収が止まる型）。

ただし表の下端にいる人がすぐ上端へ移れるという意味ではありません。上端の企業タイプでは求められる責任範囲も変わるため、移動には担当領域の拡張が伴います。この後の見出しで、その拡張が何を指すのかを具体的に見ます。

受託開発と自社IPで、伸び方が変わる理由

受託開発と自社IPでは、年収の伸び方の形が違います。受託は安定して積み上がりやすく、自社IPは会社の業績に連動して振れ幅が大きくなります。

理由は原資の決まり方です。受託の場合、売上は契約時点でおおむね確定しており、社員の給与は人月単価と稼働率から逆算されます。自社IPの場合は、タイトルの売上や課金収入が原資になるため、当たった年と当たらなかった年で会社が配分できる金額が変わります。

具体例として、賞与の設計に差が出ます。受託中心の会社では賞与が基本給の何か月分という形で安定しやすく、自社IPを持つ会社では業績連動の比率が高くなる傾向があります。提示年収が同じでも、確定部分がいくらかは違います。賞与比率が高い会社を比べるときは、月給ベースに直してから並べてください（賞与比率が高い会社と低い会社）。

例外もあります。受託でも、開発の上流から入って仕様やアーキテクチャを決める立場であれば、工程の一部を請け負う場合とは単価が変わります。受託か自社かの二分法ではなく、商流のどこにいるかで見るほうが正確です（一次請けと二次請け）。

プラットフォームと収益モデルで評価が変わる

同じゲーム開発でも、家庭用ゲーム機向け、スマートフォン向け、PC向けでは求められる技術と、会社の収益モデルが違います。これが評価の差につながります。

家庭用ゲーム機やPCのタイトルは、買い切りの売上が中心になりやすく、発売までの開発期間が長くなります。この形では、描画性能やメモリ制約の中で品質を出す実装力が評価の軸になります。一方、スマートフォン向けで運営型のタイトルを持つ場合は、リリース後も継続的に機能を追加し、同時接続を支えるサーバとデータ基盤が必要になります。

したがって、運営型タイトルを抱える会社では、クライアント実装だけでなくサーバサイドやインフラの経験を持つ人の評価が上がりやすくなります。ここはWeb系の職種と技術が重なる領域で、SRE・インフラエンジニアの年収相場で扱っている責任範囲の考え方がそのまま当てはまります。

注意すべきなのは、プラットフォームの違いを「どちらが高い」と単純化しないことです。買い切りのタイトルでも大規模な開発体制を持つ会社はありますし、運営型でも小規模なチームはあります。プラットフォームは収益モデルを推測する手がかりであって、年収を決める変数ではありません。

クライアント専任か、サーバ・基盤まで持つか

担当領域は、企業タイプの次に効く変数です。実装に閉じているか、設計と基盤まで持っているかで、同じ会社の中でも等級が変わります。

理由は、会社が代替しにくい仕事ほど高く評価されるからです。仕様が固まった機能を実装する作業は、人を増やせば進みます。対して、どのアーキテクチャを選ぶか、通信量とサーバ費用をどう抑えるか、障害時に何を切り捨てるかといった判断は、経験を持つ人に集中します。この違いは職種を問わず表れます（技術選定・アーキテクチャ責任と年収）。

具体的には、次のような担当が「設計と基盤まで持っている」側に入ります。データ設計とセーブデータの移行方針を決める、同時接続のピークに合わせてサーバ構成とコストを見積もる、ビルドと配信のパイプラインを整備して開発全体の待ち時間を削る、といった仕事です。いずれもタイトルの面白さではなく、開発と運営が成立する条件を作る側の仕事です。

例外として、クライアント実装であっても、描画パイプラインの最適化や独自エンジンのコア部分のように、代替しにくさが高い領域はあります。実装か設計かという肩書きではなく、その仕事を他の人に引き継ぐのにどれだけ時間がかかるかで考えるほうが実態に合います。

ゲームエンジンの経験はどう評価されるか

ゲームエンジンの経験は、ゲーム開発の求人では前提として扱われ、社外へ出ると評価のされ方が変わります。ここを誤解したまま転職活動を始めると、経歴書が読まれません。

ゲーム開発の求人では、エンジンの習熟は応募の入口であって差別化になりにくい要素です。多くの候補者が同じエンジンを使った経験を持つため、選考で見られるのは、そのエンジンで何を解いたかになります。フレームレートが落ちる原因を特定して描画の呼び出し回数を削った、メモリの断片化を避けるために確保の方針を変えた、といった内容です。

社外、特にWeb系の求人では、エンジン名そのものは評価の対象になりません。評価されるのは、負荷やメモリという制約の下で計測して改善した経験があるかどうかです。エンジンの機能名で書かれた経歴書は読み替えられませんが、制約と計測と改善の順で書き直せば、Web系の面接官にも読める実績になります（職務経歴書で提示年収が変わる理由）。

注意点として、エンジンを使わない独自基盤の開発経験を持つ人が、必ずしも有利になるわけではありません。独自基盤の知識は社外へ持ち出しにくいことがあり、その場合は言語やアルゴリズムなど、汎用的に説明できる部分を軸に組み立てる必要があります。

Web系へ移るとき、評価される経験・されにくい経験

ゲーム開発からWeb系へ移る場合、評価される経験とされにくい経験がはっきり分かれます。ここを把握しておくと、移動の前に何を積むべきかが決まります。

評価されやすいのは、性能に責任を持った経験です。処理時間やメモリの上限が厳しい環境で計測し、ボトルネックを特定して改善した経験は、Web系でもレスポンス速度やインフラ費用の文脈でそのまま通じます。同様に、運営型タイトルでのサーバ設計、データベースの負荷対策、リリース手順の整備は、職種名が変わっても評価の軸が変わりません。

評価されにくいのは、ゲーム固有の文脈に強く依存した経験です。特定タイトルの仕様に合わせたツール整備や、社内独自のワークフローへの習熟は、移った先で再現しにくいものとして扱われます。これは価値がないという意味ではなく、面接の場で説明のコストが高いという意味です。説明のコストが高い実績を最初に置くと、話が持ち時間の中で終わりません。

具体的な組み立て方としては、応募先が抱えている制約に近い経験を先頭に出します。トラフィックが伸びているサービスであれば負荷対策の経験を、コスト圧縮が課題であればサーバ費用を削った経験を先に置きます。同じ経歴でも、並べ方で読まれ方が変わります。

例外として、ゲーム開発の経験を求めているWeb系の求人もあります。3D表現やリアルタイム通信を扱うサービス、シミュレーションを含む業務系の開発などです。この場合はゲーム固有の経験がそのまま評価されるため、応募先の選び方で結果が変わります。

Web系からゲーム開発へ移る場合

逆方向の移動も同じ構造です。Web系からゲーム開発へ移るとき、評価されるのはサーバとデータ基盤の経験で、評価の対象になりにくいのはクライアント実装の細部です。

運営型タイトルを持つ会社では、リリース後の継続的な機能追加、負荷対策、データ分析の基盤づくりが常に課題になります。Web系で積んだ設計と運用の経験は、この領域にほぼそのまま対応します。一方、描画やアニメーション、入力の実装はゲーム特有の蓄積が必要で、移った直後は評価しにくい部分です。

年収がどう動くかは、やはり企業タイプで決まります。同じ実務年数のまま同程度の企業タイプへ移れば、大きくは動きません。下がる方向の移動を受け入れるかどうかは、下げ幅を何年で回収できるかで判断してください（年収が下がる転職を受けてよい条件）。

勤務地と働き方の影響

ゲーム開発の職場は都市部に集中しやすく、勤務地の条件が年収に与える影響も無視できません。実務3〜5年・上場大手・スキル中位という条件を固定し、勤務地だけを変えるとこうなります。

表の読み方として、地域差は物価や生活費の差と一体で見る必要があります。手取りの絶対額だけを比べても、住居費が違えば手元に残る金額は変わります。またフルリモートの行は、リモートを前提に採用している会社の水準であり、出社前提の会社が一時的に在宅を認めている場合とは条件が違います。

適用できないケースもあります。ゲーム開発では実機での検証や大容量アセットの取り扱いが必要な工程があり、職種によっては出社が前提になります。リモート可否は会社単位ではなく工程単位で決まることがあるため、求人票の記載だけで判断せず、自分が担当する工程での運用を確認してください（地方移住でエンジニアの年収を維持する条件）。

年収が止まっていると感じたときの確認手順

同じ会社で年数だけが積み上がり、年収が動かなくなったと感じたときは、順番に確認します。感覚で転職を判断する前に、社内で動かせる余地が残っているかを先に見ます。

1. いまの等級の上限額と、次の等級へ上がる要件を人事制度上の資料で確認する
2. 直近1年の担当範囲を書き出し、実装に閉じているか、設計や基盤の判断を含むかを分ける
3. 会社の賃上げの実績を給与明細で確かめ、定期昇給とベースアップのどちらで動いたかを見る
4. 同条件（経験年数・企業タイプ・勤務地）の推定レンジと、いまの年収を並べる
5. 上の4つを踏まえて、社内で埋められる差か、応募先を変えないと埋まらない差かを判定する

判定の目安はこうです。等級の上限がまだ遠く、次の要件も示されているなら、社内で動かせます。上限が近い、要件が示されない、担当範囲も広がっていないという状態が重なっているなら、差の原因は個人の努力ではなく構造の側にあります。情報通信業の賃金改定率は 3.9%（令和7年（2025年）） で、在籍を続けて得られる伸びの目安はこの水準です（昇給額は妥当か給与明細で確かめる）。

求人票と面接で確認する項目

応募先を比べるときは、提示額そのものより、その額が何で構成されているかを確認します。ゲーム開発の求人で特に見落としやすいのは次の項目です。

• 提示額に固定残業代が含まれるか、含まれる場合は何時間分か
• 賞与が業績連動か固定か、直近の支給実績が示されるか
• 担当するのはタイトルの実装か、共通基盤か、どちらも含むか
• 開発費の出どころが自社タイトルか受託か、その比率
• 等級制度があるか、提示額が何等級の下端か上端か
• リリース直前期の稼働と、その分の割増賃金の扱い

このうち等級の位置は特に重要です。同じ提示額でも、等級の下端で入るのか上端で入るのかによって、次の昇給までの距離が変わります。上端で入ると、昇格しない限り動かない期間が生まれます。求人票の年収レンジがどこで提示されるかは求人票の年収レンジを読む確認点で扱っています。

面接では、これらを条件交渉としてではなく、役割の確認として聞きます。「共通基盤の設計まで担当範囲に含まれますか」「そのポジションは何等級に当たりますか」という質問は、金額の交渉より前の段階で自然に出せます。金額の話は提示が出た後に回すほうが噛み合います。

まとめ

• ゲーム開発の年収を決めるのは業界ではなく企業タイプと担当領域。実務10年以上でも企業タイプだけで286万円開く
• 受託か自社IPかで原資の決まり方が変わり、賞与の確定部分に差が出る。月給ベースに直して比べる
• エンジンの経験は社内では前提、社外では読み替えが必要。制約・計測・改善の順に書き直すと評価される