ソニーゲームプログラマー面接の完全記録：C#、Unityとゲームアルゴリズムの深い評価
2年経験ゲーム開発者のソニー面接完全振り返り。技術3ラウンドの実際の問題を網羅。C#高度機能、Unityアーキテクチャ、ゲームアルゴリズム、レンダリングパイプライン等の問題まとめと対策アドバイス付き
背景紹介
まずは私の経歴からお話しします。大学では計算機科学を専攻し、卒業後は中規模のスマホゲーム会社にUnityクライアント開発者として入社し、約2年間働きました。その間、リリースされたスマホゲームタイトルに2本関わりました——カードRPGとカジュアルパズルゲームです。技術スタックは基本的にC# + Unityで、日常的にはゲームロジックの実装、UIシステムの構築、簡単なパフォーマンス最適化などを担当していました。
正直なところ、スマホゲーム会社で2年間働きながらも、ずっとコンソールゲームへの夢がありました。2026年3月中旬、ソニー・インタラクティブエンタテインメント（Sony Interactive Entertainment）がPlayStationゲームプログラマーを募集しているのを見つけました。職務記述書にC#、Unity、ゲームアルゴリズムといったキーワードがあり、私のバックグラウンドと合致していたので、ダメ元で応募してみることにしました。驚いたことに、わずか1週間後にHRから電話がかかってきて、技術一次面接の日程を調整することになりました。
面接プロセスは全部で3回の技術面接があり、4月上旬から4月中旬まで、約2週間にわたりました。以下、各ラウンドの問題、私の回答、面接官の反応を詳しく振り返ります。同じくソニーでゲーム開発を志す方の参考になれば幸いです。
第1回 技術一次面接（約60分）
一次面接は4月3日の午後2時からでした。面接官はPlayStation開発チームのシニアエンジニアで、30代半ばくらいの方でした。穏やかな話し方でしたが、質問は容赦ありません。主にC#の基礎とUnityのコア知識が問われました。
Q1：Unityスクリプトのライフサイクルについて説明してください。Awake、Start、Updateの違いと実行順序を教えてください。
これはUnityの定番問題です。Awakeはスクリプトがインスタンス化された直後に呼ばれ、自身の参照の初期化に使います。Startは最初のUpdateフレームの前に呼ばれ、他オブジェクトに依存する初期化に使います。Updateは毎フレーム実行されます。さらにFixedUpdateは物理更新用、LateUpdateは追従ロジック用であることも補足しました。面接官は頷き、「AwakeとStartは互いに代替可能か」とフォローアップしました。私は「いいえ」と答えました。Awakeの実行タイミングはStartより早いため、2つのスクリプトが互いに依存している場合、Startで参照を取得しないと正確性が保証できないからです。
Q2：C#の値型と参照型の違いは何ですか？ゲーム開発においてこの違いはどのような影響を与えますか？
値型はスタックに格納され、参照型はヒープに格納されます。値型の代入はコピー、参照型の代入は参照の受け渡しです。ゲーム開発では、頻繁なボックス化・ボックス化解除がGC圧力を生み出します。structは値型なのでヒープ割り当てを減らせ、Vector3のような高頻度で呼ばれる数学演算に適しています。面接官が「UnityでVector3がstructなのはなぜか」と追問したので、ベクトル演算のたびにGCが発生するのを防ぐためで、ゲームループでは極めて重要な設計だと答えました。
Q3：Unityのコルーチン（Coroutine）について説明してください。スレッドとの違いは何ですか？
コルーチンはUnityのイテレータベースの疑似非同期機構で、メインスレッド上でフレームをまたいで実行され、yield returnで一時停止と再開を制御すると説明しました。スレッドとの違いは、コルーチンは真の並行処理ではないためスレッドセーフの問題はありませんが、CPU集約的な計算には向かないことです。面接官が「バックグラウンドで重い計算をしたい場合はどうするか」と聞いたので、C#のTaskやUnityのJob Systemを使えるが、メインスレッドとワーカースレッド間のデータ同期に注意が必要だと答えました。
Q4：C#のデリゲートとイベントの違いは何ですか？ゲーム開発でどう使いますか？
デリゲートはタイプセーフな関数ポインタで、イベントはデリゲート上のpub-subパターンです。eventキーワードにより、外部からは+=と-=しかできず、直接Invokeすることはできません。ゲーム開発では、UIインタラクション、実績トリガー、シーン遷移などの疎結合シナリオでイベントシステムがよく使われます。例として、キャラクター死亡時にOnPlayerDeathイベントが発火し、UI、サウンド、セーブシステムがそれぞれ独立して購読する——互いに参照を持つ必要がない、と説明しました。
Q5：Unityのオブジェクトプール（Object Pool）とは何ですか？なぜ使うのですか？
オブジェクトプールは、オブジェクトを事前に作成して再利用するデザインパターンで、頻繁なInstantiateとDestroyによるGCスパイクを防ぐと説明しました。シューティングゲームの弾丸やエフェクトなど、高頻度で生成・破棄されるオブジェクトに特に有効です。面接官から簡単なオブジェクトプールの疑似コードを書くよう言われたので、Queueを使ったジェネリック版を書きました。Getでキューから取り出し、Releaseでキューに戻すというものです。面接官は「いいね」と言い、「プール内のオブジェクトの状態をリセットする必要がある場合はどうするか」と聞いたので、Release時にResetメソッドを呼んで、位置や速度などを初期値に戻すと答えました。
Q6：C#のusingステートメントの役割は何ですか？IDisposableとどう関係していますか？
usingは構文糖衣で、IDisposableオブジェクトがスコープを抜ける際に自動的にDisposeメソッドを呼び出し、リソースを解放することを保証します。例外が発生しても確実に解放されます。ゲーム開発では、ファイルストリーム、ネットワーク接続、UnityのAssetBundle読み込みなど、すべてタイムリーな解放が必要です。面接官が「usingを使わずに手動でDisposeする場合、どんな問題があるか」と聞いたので、呼び出しを忘れやすい、例外時にDisposeがスキップされてリソースリークにつながる、と答えました。
Q7：UnityのPrefabとは何ですか？Prefabを動的にロードする方法には何がありますか？
Prefabはコンポーネントとプロパティ設定を含む再利用可能なゲームオブジェクトテンプレートです。動的ロードの方法には、Resources.Load（シンプルだが柔軟性に欠ける）、AssetBundle（ホットアップデートに適する）、Addressables（Unity推奨の新アプローチ、AssetBundleをラップ）があります。面接官が「Resources.Loadの欠点は何か」と聞いたので、Resourcesフォルダ以下のすべてのリソースをバンドルに含めてしまうため、オンデマンドロードができず、ホットアップデートにも対応しないと答えました。
Q8：UnityのScriptableObjectの用途と利点について説明してください。
ScriptableObjectはデータコンテナで、GameObjectにアタッチする必要のない設定データ——キャラクターのステータステーブル、武器データ、ステージ設定など——の保存に適しています。利点は、GCが発生しない、エディタで編集できる、複数のオブジェクトが同じデータインスタンスを共有してメモリを節約できることです。面接官が「JSON設定ファイルと比べて何が有利か」と聞いたので、ScriptableObjectはインスペクターでビジュアル編集しやすく、シリアライズ後はランタイムでそのまま使えるため、JSONパースのオーバーヘッドがないと答えました。
第2回 技術二次面接（約70分）
二次面接は4月9日の午前10時からでした。面接官はチームのテックリードに交代しました。より実践的なスタイルで、問題もより深く、主にゲームアルゴリズム、レンダリング、パフォーマンス最適化に焦点が当てられました。この回は一次ほどスムーズにいかず、2問で詰まってしまいました。
Q1：A*経路探索アルゴリズムの原理を説明してください。Dijkstra法との違いは何ですか？
A*はヒューリスティック探索アルゴリズムで、f(n) = g(n) + h(n)でノードの優先度を評価すると説明しました。g(n)はスタートから現在ノードまでの実際のコスト、h(n)は現在ノードからゴールまでのヒューリスティック推定コストです。Dijkstra法との違いは、Dijkstra法にはヒューリスティック関数h(n)がなく、h(n)が常に0のA*と等価であるため、良いヒューリスティック関数があればA*は探索範囲がより小さく効率的です。面接官が「ヒューリスティック関数はどう選ぶか」と聞いたので、4方向移動ではマンハッタン距離、8方向移動ではユークリッド距離が一般的で、重要なのはヒューリスティック関数が実際のコストを超えて推定してはならないこと——そうしないと最適解が保証できないと答えました。
Q2：有限状態機械（FSM）はゲームでどう使われますか？ビヘイビアツリーとの优劣は？
FSMはキャラクターAI、UI状態管理、ゲームフロー制御などによく使われます。各状態には进入、更新、退出の振る舞いを定義し、条件によって状態遷移をトリガーします。ビヘイビアツリーと比べると、FSMは実装がシンプルで直感的ですが、状態が増えると遷移関係が複雑になりすぎます（状態爆発問題）。ビヘイビアツリーはより柔軟で、複合ノードで複雑なロジックを構成でき、再利用性も高いですが、学習曲線が急です。面接官が「どう選ぶか」と聞いたので、シンプルなAIにはFSM、複雑なAIにはビヘイビアツリー、ハイブリッドもありだと答えました。
Q3：Unityのレンダリングパイプラインはどうなっていますか？Forward RenderingとDeferred Renderingの違いは？
この問題はうまく答えられませんでした。Forward Renderingはオブジェクトごとにレンダリングし、各オブジェクトですべてのライティングを計算するため、光源が多いとパフォーマンスが著しく低下すると説明しました。Deferred RenderingはまずG-Buffer（位置、法線、色など）をレンダリングし、その後スクリーンスペースでライティングを一括計算するため、多光源シーンに適しています。しかし、面接官が「UnityのURPとHDRPはそれぞれどのレンダリングパスを使っているか」と深掘りしたとき、URPのデフォルトがForward+、HDRPのデフォルトがDeferredであることしか分からず、詳細を説明できませんでした。面接官は「大丈夫です」と言い、Tile-Based Renderingについて後で調べておくようアドバイスしてくれました。
Q4：ドローコールとは何ですか？ドローコールを減らすにはどうしますか？
ドローコールはCPUからGPUに送られるレンダリングコマンドで、レンダリングAPIを呼び出すたびに1つのドローコールが発生すると説明しました。削減方法には、スタティックバッチング（Static Batching）、ダイナミックバッチング（Dynamic Batching）、テクスチャアトラス、マテリアル種類の削減、GPU Instancingがあります。面接官が「Static BatchingとDynamic Batchingの違い」を聞いたので、Static Batchingはビルド時に静的オブジェクトのメッシュを結合する——頂点数制限はないがメモリが増える。Dynamic Batchingはランタイムで小さなメッシュを自動結合する——頂点数制限（通常300以下）があると答えました。
Q5：ゲームのメモリリークはどう調査しますか？Unity Profilerの使い方は？
Unity ProfilerのMemoryモジュールでヒープメモリの割り当てとGCの状況を確認でき、CPUモジュールでフレームごとの関数呼び出し時間を見られると説明しました。メモリリーク調査の手順：まずProfilerのGC Alloc列でフレームあたりの割り当てが最も多い箇所を特定し、次にMemory Profilerでスナップショットを取得し、2つのスナップショットの差分からリークオブジェクトを見つけます。よくあるリークの原因には、イベント購読の解除忘れ、静的リストに追加し続けてクリアしない、コルーチンのStopAllCoroutines忘れなどがあります。
Q6：ECS（Entity Component System）パターンについて説明してください。UnityのDOTSとの関係は？
この問題でも詰まってしまいました。ECSはデータ指向のデザインパターンで、EntityはID、Componentは純粋なデータ、Systemは処理ロジックであることは知っていました。UnityのDOTS（Data-Oriented Technology Stack）にはEntitiesパッケージ（ECS実装）、Job System（マルチスレッド）、Burst Compiler（コード最適化）が含まれています。しかし、面接官が「なぜECSは従来のMonoBehaviourよりパフォーマンスが良いのか」と聞いたとき、「データが連続して格納されるためCPUキャッシュにフレンドリー」としか言えませんでした。面接官はSIMD自動ベクトル化や仮想関数呼び出しのオーバーヘッド回避なども補足し、Burstコンパイルの原理を深く勉強しておくようアドバイスしてくれました。
Q7：シェーダーとは何ですか？バーテックスシェーダーとフラグメントシェーダーの役割を簡単に説明してください。
シェーダーはGPU上で実行されるプログラムです。バーテックスシェーダーは各頂点の位置変換（モデル空間→ワールド空間→クリップ空間）を処理し、フラグメントシェーダーは各ピクセルのカラー計算（テクスチャサンプリング、ライティング計算、ブレンディングなど）を処理すると説明しました。面接官が「カスタムシェーダーを書いたことはあるか」と聞いたので、スマホゲームプロジェクトで円形マスクやグラデーション効果などのシンプルなUIシェーダーを書いたことはあるが、複雑なライティングシェーダーは書いたことがないと答えました。面接官は「大丈夫、入社後に学ぶ機会がある」と言ってくれました。
第3回 技術三次面接＋総合面接（約55分）
三次面接は4月14日の午後3時からでした。面接官は部門マネージャーで、この回は深い技術問題とソフトスキルの評価が混ざっていました。前2回より雰囲気はリラックスしていて、より会話に近い感じでした。
Q1：スマホゲームプロジェクトで最もチャレンジングだった技術的問題は何ですか？どう解決しましたか？
カードRPGプロジェクトのバトルリプレイシステムについて話しました。各操作を記録し、リプレイ時に正確に再現する必要がありましたが、浮動小数点精度と乱数シードの同期が難点でした。私の解決策は、浮動小数点の代わりに固定小数点を使い、決定論的乱数ジェネレーターを用い、操作をバイナリデータにシリアライズして保存するというものでした。面接官はこれに興味を示し、固定小数点の実装詳細を深掘りしました。整数で小数をシミュレートし、スケーリングファクター（例えば10000）を掛け、演算後に割り戻すと説明しました。
Q2：スマホゲーム開発とコンソールゲーム開発の技術的違いについてどう考えますか？
スマホゲームはローエンドデバイスの互換性、パッケージサイズ、ホットアップデートを考慮する必要があると答えました。コンソールゲームはハードウェアが統一されているため、より極限のグラフィックと物理効果を実現できますが、コード品質とパフォーマンスの要件がより高く、コンソールのフレームレートは通常60fps、場合によっては120fpsなので、エラーの許容範囲が小さいです。面接官は、コンソールゲームにはTRC（Technical Requirements Checklist）コンプライアンス要件もあると補足しました。例えばPSプラットフォームにはソニーの認証基準があり、クラッシュ率やロード時間に厳しい基準があるとのことでした。
Q3：ゲームのスキルシステムを設計するとしたら、どうアーキテクチャしますか？
データ駆動のアプローチを使うと答えました。スキル設定はScriptableObjectに保存し（ダメージ値、クールダウン、エフェクトパスなど）、ランタイムではスキルマネージャーが設定に基づいてスキルインスタンスを生成し、各インスタンスはFSMで詠唱フローを管理し（前モーション→発動→後モーション）、効果はイベントシステムで他モジュールに通知します。面接官が「スキル間のコンボ効果はどう処理するか」と聞いたので、Buffシステムを使える——スキル発動時にBuffを追加し、Buff同士はスタックまたは排他可能で、タグシステムで互換性を管理すると答えました。
Q4：普段どうやって新しい技術を学んでいますか？最近は何を見ていますか？
主に公式ドキュメント、GDCトーク、GitHubのオープンソースプロジェクトを通じて学んでいると答えました。最近はUnity DOTSの公式チュートリアルとECSのBest Practice Guideを見ていて、『ゲームプログラミングパターン』という本も読んでいます。面接官は「GDCは良いリソースだ」と言い、ソニー自身のGDCトーク——Decima EngineやPS5 SSD技術に関するもの——を見ることを勧めてくれました。
Q5：なぜスマホからコンソールゲーム開発に移りたいのですか？
スマホ開発はペースが速く、機能のイテレーションが優先され、技術的な深さには限りがあると答えました。コンソールゲームは品質とパフォーマンスをより重視し、技術的に成長できる余地が大きいです。それに、子どもの頃からずっとPlayStationのゲーマーで、自分が愛するプラットフォームのゲーム制作に参加できるという達成感は別格です。面接官は笑って「分かります、チームの多くも元々ゲーマー出身です」と言ってくれました。
面接問題まとめ
第1回（C#基礎＋Unityコア）
- Unityスクリプトライフサイクル（Awake/Start/Updateの違い）— Unity基礎 — ★★☆
- C#値型と参照型のゲーム開発への影響 — 言語基礎＋パフォーマンス意識 — ★★★
- コルーチンとスレッドの違い — Unity非同期機構 — ★★★
- デリゲートとイベントのゲーム開発での応用 — C#機能＋デザインパターン — ★★★
- オブジェクトプールパターン — パフォーマンス最適化＋デザインパターン — ★★★
- usingステートメントとIDisposable — リソース管理 — ★★☆
- Prefabの動的ロード方法 — リソース管理 — ★★★
- ScriptableObjectの用途と利点 — データ駆動設計 — ★★★
第2回（ゲームアルゴリズム＋レンダリング＋パフォーマンス）
- A*経路探索アルゴリズムの原理 — 古典アルゴリズム — ★★★★
- FSMとビヘイビアツリーの比較 — AIアーキテクチャ — ★★★★
- レンダリングパイプライン（Forward vs Deferred）— グラフィックス基礎 — ★★★★★
- ドローコール最適化 — レンダリングパフォーマンス — ★★★★
- メモリリーク調査 — デバッグ能力 — ★★★★
- ECSパターンとDOTS — アーキテクチャ設計＋新技術 — ★★★★★
- シェーダー基礎 — グラフィックスプログラミング — ★★★★
第3回（深い技術＋ソフトスキル）
- プロジェクトの課題と解決策 — 実践経験 — ★★★★
- スマホとコンソール開発の違い — 業界理解 — ★★★
- スキルシステムアーキテクチャ設計 — システム設計 — ★★★★★
- 学習方法と成長 — 自己駆動力 — ★★☆
- キャリアの動機 — カルチャーフィット — ★★☆
感想とアドバイス
1. 基礎はしっかりと、でも「なぜ」を理解することがもっと重要
ソニーの面接ではAPIの呼び出し方は聞かれません。基礎原理を聞かれます。Vector3がstructなのはなぜか、A*のヒューリスティック関数が過大評価してはいけないのはなぜか——この「なぜ」が差別化のポイントです。一つの知識を学ぶたびに、「なぜこのように設計されているのか」と一段深く考えることをお勧めします。
2. グラフィックスとレンダリングの知識はコンソールゲーム面接の大きなプラス
私はこの領域の準備不足で、レンダリングパイプラインの問題で詰まってしまいました。スマホからの転身でコンソールを目指すなら、グラフィックスの基礎を必ず補強してください。少なくともレンダリングパイプラインの各段階、ForwardとDeferredの优劣、シェーダーの基本原理は押さえておきましょう。『Unity Shader入門精要』やLearnOpenGLサイトをお勧めします。
3. システム設計問題は早めに練習する——アルゴリズムだけやらない
「スキルシステムを設計せよ」というような問題はLeetCodeには出ません。実際のプロジェクト経験とアーキテクチャ思考が必要です。普段から自分のプロジェクトのアーキテクチャ設計をまとめ、再設計するならどうするか、どのようなトレードオフがあるかを考えることをお勧めします。
4. 正直であること——分からないなら分からないと言う
ECSとレンダリングパイプラインの2問で詰まりましたが、適当な答えを捏造しませんでした。知っている部分を話し、「この領域はもっと深く勉強する必要があります」と正直に認めました。面接官は後で、何でも知っていることより学習能力と姿勢を重視しているとフィードバックしてくれました。最終的に4月20日にオファーを受け取りました。給与は前職より約40%アップで、非常に満足しています。
FAQ
Q1：ソニーのゲームプログラマー面接で日本語は必要ですか？
ポジションによります。日本本社のポジションは通常N2以上が求められますが、中国スタジオ（例：ソニー・インタラクティブエンタテインメント上海）の技術職は日本語が必須ではなく、英語でコミュニケーションできれば大丈夫です。私が面接したのは上海スタジオで、全過程中国語での面接でした。
Q2：スマホゲーム開発経験はコンソールゲーム面接でプラスですか、マイナスですか？
間違いなくプラスです。スマホゲーム開発はパフォーマンス最適化とリソース管理に高い要求があり、その経験はコンソール開発でもそのまま活かせます。面接官は以前どのプラットフォームをやっていたかより、技術の深さと学習能力を重視します。
Q3：ソニーの面接でアルゴリズム問題は出ますか？
出ますが、LeetCodeのような純粋なアルゴリズム問題ではなく、ゲーム関連のアルゴリズムに偏っています。A*経路探索、状態機械、衝突判定などです。数百問のLeetCodeを解くより、ゲーム分野の古典的アルゴリズムを重点的に準備することをお勧めします。
Q4：ソニーの面接ではUnityとUnreal、どちらが有利ですか？
ソニーのファーストパーティスタジオは主に独自エンジンを使っていますが、面接で独自エンジンの経験は求められません。UnityでもUnrealでも構いません。重要なのは、使っているエンジンへの理解の深さです。私はUnityポジションで面接しました。Unrealポジションなら、面接官はUnreal関連の問題を聞きます。
Q5：面接の期間はどのくらいですか？
履歴書を提出してからオファーを受け取るまで約1ヶ月でした。一次面接後3営業日で二次面接の通知、二次面接後4営業日で三次面接の通知、三次面接後6営業日でオファーを受け取りました。全体のペースは速くも遅くもないので、焦らず待てば大丈夫です。
