Photon Fusionとは？Fusion 2.1の3モードの違い・料金試算・PUN2からの移行【2026年10月】

Photon Fusion（フュージョン）は、Photon EngineがUnity向けに提供しているマルチプレイヤー用のネットワークSDKです。同じAPIのままShared・Host・Serverの3つの接続形態を選べる点が、旧来のPUN2との大きな違いです。この記事では、2026年10月時点の現行版Fusion 2.1.3を前提に、動作要件、3モードの選び方、同期手段の使い分け、料金の試算、PUN2や他のネットワークライブラリとの違い、Unityで最初のセッションを立ち上げるまでを、公式ドキュメントの記述に沿って整理します。

まとめ：Fusion 2.1の採用判断とモード選定

• Fusionは状態同期型のUnity向けネットワークライブラリで、クライアント側予測・ラグ補償・関心領域（AOI）を標準で持つ
• 現行の安定版はFusion SDK 2.1.3（2026年9月17日）。対応Unityは2021.3.45・2022.3.45・6.0.x・6.3.x
• モバイルとWebGLはShared、2〜4人で物理の多いゲームはHost、不正対策を重視する競技系はServer。Serverの専用サーバーはPhotonが提供しない
• 料金は開発用20CCUと1アプリ限定の100CCUが無料で、95ドルの12か月プランを重ねると200CCUまで広がる。月額は500CCU・125ドルから（英語版料金ページ）
• CCUはリージョンごとのピークの合算で数え、転送量の超過単価は日本を含むアジアが欧米の2倍。日本リージョンで月2.75TBを超えるなら、500CCU未満でも1000CCUプランのほうが安い
• PUN2はメンテナンス／LTS期で、新規開発ならFusionかQuantum。Unreal Engine・Godot向けのFusion 3はまだプレビュー版

以下、それぞれの根拠と判断の分かれ目を順に説明します。

Photon Fusionの位置づけと現行バージョン

Photon製品群の役割とFusionの位置づけ

「Photon」で検索すると複数の製品が並びますが、役割は分かれています。コードにPhotonNetworkクラスが出てくるのはPUN2で、FusionではNetworkRunnerが入口になります。

ECS（Entity Component System）を採っているのはQuantumで、FusionはECSではありません。

Fusionが標準で持つ同期の仕組み

公式の導入ページはFusionを「Unity向けの高性能な状態同期ネットワークライブラリ」と説明し、データ圧縮、クライアント側予測、ラグ補償を標準で備えるとしています。ラグ補償はHost／Server限定で、Hitboxの構成と専用クエリが別途要ります。

状態の転送は変化した部分だけを送る方式で、既定では1つのNetworkObjectの[Networked]プロパティがすべて同じティックで届く「Full Consistency」になっています。SimulationConfig.ObjectDataConsistencyをEventualにすると、プロパティごとに別のティックで届く代わりに帯域を減らせます。関心領域（Interest Management）で送る相手を絞る仕組みもあり、公式サンプルBR200は最大200人・60Hzのバトルロイヤルです。

SDKのバージョンと動作要件

公式のSDK配布ページには、2.1系が2.1.3（2026年9月17日）・2.1.2（8月13日）・2.1.1（6月30日）、2.0系が2.0.13（9月16日）まで並んでいます。2.0系から上げる場合は、先に2.0系の最新版へ更新してから2.1へ進むよう指定されています。

Unity 6.3系で組む場合は、エディタ側の変更点をUnity 6.3 LTSの新機能と変更点で先に確認しておくと、SDKの不具合とエディタの仕様変更を切り分けやすくなります。音声チャットのVoice 2.64はFusion 2.1用（Realtime 5版）とFusion 2.0用で別パッケージで、互換性はありません。

2.1系で変わった点（2.1.3まで）

2.0から2.1への更新と、2026年9月の2.1.3で入った変更のうち、設計に影響するものです（2.1のリリースノート）。

• ティックレート：Host／Serverでは8Hz〜256Hzの任意値に。Sharedの上限は32Hz。送信レートはティックレートを割り切れる範囲で1/8まで下げられる
• Forecast Physics：物理を完全には予測せず、外挿で各プレイヤーのローカル時間に置く方式。2.1.3でデッドゾーン内の挙動をLocal PhysicsとMatch Targetから選べるようになった
• 送信の間引き：NetworkObject.SetPriority(player, 2)なら送信ティック2回に1回
• 権限の一括移動（2.1.3）：BatchRequestStateAuthority（要求）とBatchReleaseStateAuthority（解放）で、最大16個のNetworkObjectの状態権限を全部成功か全部失敗の1回の呼び出しで扱える
• マスタークライアントの交代：応答しないマスターをRequestMasterClientReassign()で交代させられる。しきい値を0にすると応答中のマスターも奪えるため、公式はセッション乗っ取りに悪用されうると警告している

2.1.3では同時に読み込めるシーン数が8から31に増え、[Networked]な文字列のCapacity(30)に28文字しか入らなかった不具合も直りました。

Fusion 3（Unreal Engine・Godot版）の状況

Unity向けのFusion 2とは別に、Fusion 3としてUnreal Engine版とGodot版が公開されています。Unreal版3.0.0はUE 5.4〜5.8向けで、配布ページの最新ビルドは2026年10月12日付です。Godot版3.0.0はGodot 4.6以降向けです。どちらも配布ページで「プレビュー」とされ、リリースするゲームには使わないよう明記されています。AppIdもFusion 3用が別に要ります。

3つのネットワークモードの違いと選び方

Fusionでは接続形態を「Mode」と呼び、Dedicated Server・Client Host・Shared Authorityの3つに加えて、ネットワークに接続しないSingle Playerモードがあります（公式のNetwork Topologies）。コードの書き方はServerとHostで共通、Sharedだけが権限の持ち方が異なります。

最初にどのモードで作るかを決める理由は、権限の持ち方がゲームロジックの書き方そのものを変えるからです。公式の移行ガイドも、PUNの知識がそのまま通じるのはSharedだけで、Host／Serverには当てはまらないと明記しています。

Shared Mode：モバイルとWebGLの第一候補

Sharedでは、各クライアントが自分でスポーンしたオブジェクトの状態権限（State Authority）を持ち、Photonクラウド上のルームが権限の移動と状態の完全なコピーを管理します。接続先はクラウドなので、プレイヤー同士のNAT越えは発生しません。

公式はモバイルの推奨モードをSharedとし、WebGLでも強く推奨しています。再シミュレーションを実行しない唯一のモードで、CPU負荷が低いことが理由です。ブラウザ向けの書き出しはWebGLの仕組みとUnity WebGLビルドの手順も参考になります。

Host Mode：少人数で物理を多用するゲーム

プレイヤーの1人がサーバーとクライアントを兼ねます。サーバーのホスティング費はかかりませんが、ホストは任意の値を書き換えられるため、ホスト本人の不正は防げません。

接続はUDPのNATパンチスルーでホストへ直接つなぎ、失敗したプレイヤーだけがリレー経由になります。公式の目安では、リレーになるのはおよそ10人に1人です。モバイル回線はパンチスルーの成功率が低くホストの離脱も多いため、公式はモバイルでのHostを特殊な用途以外は推奨していません。GameMode.AutoClientOrHostなら最初の入室者が自動でホストになります。

Server Mode：不正対策を優先する競技系

Unityプロジェクトからヘッドレスのサーバービルドを作り、それが全オブジェクトの状態権限を持ちます。クライアントは入力の送信かRPCでしか状態を変えられないので、入力やRPCの内容をサーバー側で検証する設計にすれば、クライアントのメモリ改ざんを権威あるゲーム状態へ直接反映させずに済みます。公式が「残りうる」とするのはエイムボットとウォールハックで、後者は関心領域で緩和できます。

注意点は費用です。Photonは専用サーバーのホスティングを提供していません。セッションごとにUnityインスタンスを動かすサーバーを自社で運用するか、PlayFabのような外部のゲームサーバーホスティングを別契約で用意します。公式もモバイルでのServerは「ARPUの高いタイトル向け」としています。

Sharedを選ぶべきでない条件

手軽さからSharedで始めたくなりますが、次に当てはまるなら最初からHostかServerで設計したほうが作り直しを避けられます。

• 対戦結果にランキングや報酬が絡む：Sharedは各クライアントが自分のオブジェクトの値やRPCを自由に送れるため、追加の対策なしでは改ざんを防げない。Hostもホスト本人の不正は防げないので、この条件ならServerを選ぶ
• 遠距離の撃ち合いで当たり判定の公平性が要る：ラグ補償はServerとHostでしか使えない
• 32Hzを超えるティックレートが要る：Sharedは2.1でもティックレートと送信レートの上限が32Hz

Sharedでもサーバー側で検証を挟む手段として、2.1からShared Mode Custom Plugins（Photonサーバー上でコードを実行する機能）が追加されましたが、利用にはEnterprise Cloudの契約が必要です。

同期手段の使い分け：Networked Property・RPC・Input・Data Streaming

Fusionでピア間にデータを送る方法は4つあります（公式のData Transfer）。最初に決めておくべきなのは「その値は状態か、出来事か」です。

使い分けで一番効くのはRPCのページにある注意です。RPCは状態を持たないため、途中参加したプレイヤーや再接続したプレイヤーには届きません。チャットのように消えてよいもの以外は、RPCを受けた側が[Networked]プロパティに結果を書き残す形にします。RPCのメソッド名は「RPC」で始めるか終えるかが必須で、通常のチャネルは512バイトまでです。2.1のRpcChannel.ReliableLargeDataは上限を超えられますが、ティックへの整列と順序は保証されません。

次のコードは、公式マニュアル（Networked Properties・Change Detection・RPC・TickTimer）の例を1つのクラスにまとめた構成例で、この組み合わせでの実行は確認していません。NetworkObjectを付けたプレハブに追加し、bodyにはInspectorでMeshRendererを割り当てます。RPC_SetColorは入力権限を持つ本人のクライアントから呼ぶ想定で、Host／Serverではスポーン時にそのプレイヤーへInput Authorityを割り当てておきます。Sharedでは入力権限と状態権限が同じクライアントにあるため、RPCを介さずPlayerColorへ直接書けます。

using Fusion;
using UnityEngine;

public class Player : NetworkBehaviour
{
    // 値が変わると描画側でOnColorChangedが呼ばれる
    [Networked, OnChangedRender(nameof(OnColorChanged))]
    public Color PlayerColor { get; set; }

    [Networked] public TickTimer RespawnTimer { get; set; }

    public MeshRenderer body;

    public override void Spawned()
    {
        // OnChangedRenderは初回スポーン時に呼ばれないので自分で呼ぶ
        OnColorChanged();
    }

    public void OnColorChanged()
    {
        body.material.color = PlayerColor;
    }

    // 入力権限を持つ本人が送り、状態権限を持つ側で実行される
    [Rpc(RpcSources.InputAuthority, RpcTargets.StateAuthority)]
    public void RPC_SetColor(Color color)
    {
        PlayerColor = color;
    }

    // 状態権限を持つ側で呼ぶと3秒後に期限切れになる
    public void StartRespawn()
    {
        RespawnTimer = TickTimer.CreateFromSeconds(Runner, 3f);
    }

    public override void FixedUpdateNetwork()
    {
        if (RespawnTimer.Expired(Runner))
        {
            RespawnTimer = TickTimer.None;
        }
    }
}

色はRPCで1回だけ送られますが、受けた側がPlayerColorに書くので、後から入ったプレイヤーにも現在の色が届きます。Change DetectionのページによるとOnChangedRenderはスポーン直後には呼ばれないため、Spawnedで初期化する1行が要ります。TickTimerは残り時間を減らしていく値ではなく目標ティックを1回書くだけなので、タイマー作動中に帯域を使いません。Host／Serverで移動などを予測させたい場合は、状態の変更をFixedUpdateNetworkの中に置き、操作はOnInputで集めた入力として送ります。

Photon Fusionの料金プランとCCUの考え方

Fusionの料金・CCU上限・転送量一覧（2026年10月時点）

課金の単位は同時接続数（CCU）です。以下はゲーム向けプランの2026年10月26日時点の英語版料金ページの表記です。

95ドルの100CCUプランは単独でも、無料100CCUや月額プランに重ねても使えます。無料100CCUに重ねれば200CCU、500CCUプランに重ねれば600CCUです。100CCUまでのプランは上限を超えた接続がMaxCcuReachedで切断されるので、無料枠でリリースする場合はこの切断を受けて「混雑中」と案内する処理を用意しておきます。500CCU以上は超過分を受け入れて翌月の請求に載せますが、最初のバーストから48時間以内にプランを上げないと、Photonの判断でCCUを契約数に制限されることがあります。

このほか、使用量課金のPremium Cloud（1CCUあたり0.50ドル、最低月額1,000ドル）と、個別見積もりのEnterprise Cloudがあります。

CCUの数え方とリージョン設計

プランの判定に使うCCUは、全リージョンのピークの合計です。料金ページの例では、欧州のピークが420CCU、米国が230CCUなら合計650CCUで、1000CCUプランが必要になります。2つの地域のピークが別の時間帯に来て、実際の同時接続が最大500人だった月でも、請求は650CCUで判定されます。

接続先のリージョンは、PhotonAppSettingsで指定しなければ「Best Region」（pingで自動選択）になります。公式のRegionsページは、Best Regionは決定的でなく、同じネットワークにいるクライアントでも別のリージョンにつながることがあると書いています。日本のプレイヤーだけを想定するタイトルなら、東京（コードjp）に固定するか、DashboardのRegion Allowlistをjpのみに設定するのが確実です。マッチングの母数が地域ごとに割れるのを防げるうえ、課金の基準になるピークも1リージョンにまとまります。

転送量込みの試算：1000CCUプランのほうが安くなる境目

月額プランに含まれるトラフィックは契約CCU1あたり月3GB（1000CCUプランなら3TB）で、超えた分は欧州・米国・カナダが1GBあたり0.05ドル、日本を含むアジアやオーストラリアなどが0.10ドルです。ここから、月額プランを1段上げたほうが安くなる転送量の境目を計算できます（基本料＋超過GB×単価で比較）。

たとえば日本リージョンでピーク450CCU、1CCUあたり月8GBを使うゲームなら転送量は3.6TBです。500CCUプランでは超過2.1TB分の210ドルが加わって335ドル、1000CCUプランなら超過0.6TB分の60ドルで310ドルになり、CCUに余裕があっても上のプランが安くなります。1CCUあたり月5GBなら、500CCUプランが200ドル、1000CCUプランが250ドルで逆転しません。欧米リージョンは超過単価が半分なので、転送量がいくら増えても下のプランのほうが安く、上のプランの付属枠を超えた後も50〜100ドルの差が残ります。1CCUあたりの転送量はティックレートや同期するオブジェクト数で大きく変わるため、開発中に統計表示で実測した値で計算してください。

無料の100CCUは公式の目安で月間アクティブユーザー約4万人規模です（1CCU≒DAU20人、DAU1人≒MAU20人の経験則）。Serverモードでは専用サーバーの費用が別にかかります。

Fusionを選ばないほうがよい場面と他のライブラリ

Unityのマルチプレイには、Fusion以外にUnity純正のNetcode for GameObjects（NGO）や、ソースが公開されているMirror（MITライセンス）・FishNet（ゲーム用途は無償だが、他のネットワークライブラリへの流用を禁じる独自ライセンス）があります。違いが一番出るのは、何に対して課金されるかです。

Unity Gaming Servicesの料金ページでは、Relayは月平均50CCUまで無料で、超えた分が平均CCUあたり0.16ドルです。Relayの転送量は1CCUあたり3GiB（月150GiBまで）が無料で、超過はアジア・オーストラリアが1GiBあたり0.16ドル、米国・EUが0.09ドルです。NGOでSharedに近い使い方をするDistributed Authorityは月6,000接続時間まで無料、以降は1接続時間0.001ドルで、送信100GiBを超えた分に同じ地域別の単価がかかります。接続数の課金だけを比べると、夜だけ混むゲームのようにピークと平均の差が大きいほど、ピークで課金されるPhotonが不利です。総額は転送量の単価と無料枠まで含めて比べてください。逆に、予測・ラグ補償・関心領域をそろえて作るなら、Fusionはそれらを最初から持っている点で工数が減ります。

NGOは3.0（2026年9月）からNetcode for Entitiesが必須の依存になり、EntitiesやBurstも一緒にプロジェクトへ入ります。Unityのパッケージレジストリでは3.x系の最小対応版が6000.7.0b1、2.13系が6000.0と登録されており、ドキュメントの「Unity 6.0+」と食い違っています。Unity 6.6以前のプロジェクトでは2.13系を前提にし、Package Managerで実際に入る版を確かめてください。

Fusionを選ばないほうがよいのは、次のような場合です。

• 格闘ゲームやRTSのように、全員の入力から同じ結果を再現する必要がある：同じPhotonでもQuantumの領域
• 自前の専用サーバーを既に運用していて、クラウドのCCU課金を避けたい：MirrorやFishNetならライブラリ自体は無料
• Unreal EngineやGodotで今すぐ製品を出す：Fusion 3はプレビューなので、エンジン標準のネットワーク機能が先になる

音声も載せる予定なら、Photon VoiceとUnityのVivoxでは課金の単位がさらに異なります。比較はボイスチャットの実装方法（WebRTC自作とVivox・Photon Voice等SDKの比較）にまとめています。

PUN2との違いと移行で詰まりやすい点

PUN2の現状と公式の推奨

PUN2のドキュメントには「メンテナンス／LTSモードであり、修正以外の機能追加は予定していない」と明記されています。既存のPUN2プロジェクトは引き続き動きますが、新規プロジェクトではFusionかQuantumを検討するよう案内されています。

PUN2とFusionのAPI対応

公式の移行ガイド（Coming from PUN2）にある対応表のうち、書き換えの頻度が高いものを抜き出しました。

この表はSharedモードへ移す際の対応であり、名前の置換だけで移行できるわけではありません。PUNは全クライアントが共有するルームでの分散権限モデルしか持たないため、Host／Serverへ移るなら入力と状態権限の設計からやり直すことになります。

PUN2移行時の識別子・設定・コールバックの変更

• プレイヤー番号：移行ガイドには「PlayerRefは0からMaxPlayers - 1、ホストはMaxPlayers - 1」とあるが、これはFusion 1の仕様。Fusion 2では接続ごとに固有の値が振られて退出者の値は再利用されず、ホストは1になる（Fusion 1からの移行資料に明記）。番号を配列の添字やチーム分けに使うと壊れる
• 設定ファイル：PUNのPhotonServerSettingsに相当する内容が、接続情報のPhotonAppSettingsと、ティックレートや最大人数を持つNetworkProjectConfigに分かれる
• コールバック：Network RunnerのGameObject（とその子）に付けたコンポーネントはStartGame時に自動で登録される。セッション単位はINetworkRunnerCallbacks、オブジェクト単位はNetworkBehaviourのSpawnedなどで受け取る

Unityでの始め方：AppId発行から最初のセッションまで

Fusion SDKのインポートとAppId・シーンの設定

1. Photon DashboardでFusion 2用のAppIdを発行する
2. SDK配布ページからFusion SDK 2.1.3のパッケージを取得し、対応バージョンのUnityプロジェクトへインポートする
3. Project Settings > Editor > Asset SerializationのModeをForce Textにする
4. Fusion HubでAppIdを設定する（PhotonAppSettingsに保存される）
5. Sharedなら、Hierarchyの右クリックメニューからFusion > Scene > Setup Networking in Sceneを選び、Prototype RunnerとPrototype Network Startを追加する

SDKを更新するときは、プロジェクトをバックアップしてPhotonフォルダを削除し、新しいパッケージをインポートしたあと、NetworkProjectConfig.fusionとPhotonAppSettings.assetの変更を元に戻します。エディタを日本語表示で使っている場合はメニュー名が英語の手順書と一致しないので、Unityの日本語化とエディタ言語設定の手順を参考に、導入中だけ英語表示へ戻しておくと迷いません。

Host／Serverでセッションを開始するコード

Host／Serverでは、NetworkRunnerのStartGameをコードから呼びます。公式チュートリアル（Host Mode Basics）のBasicSpawnerから抜粋しました。Fusion・UnityEngine・UnityEngine.SceneManagementのusingが要り、シーンはBuild Settingsに登録しておきます。原典のScene = sceneは、組み立てたsceneInfoを渡すよう1行変えています。

private NetworkRunner _runner;

async void StartGame(GameMode mode)
{
    // Create the Fusion runner and let it know that we will be providing user input
    _runner = gameObject.AddComponent<NetworkRunner>();
    _runner.ProvideInput = true;

    // Create the NetworkSceneInfo from the current scene
    var scene = SceneRef.FromIndex(SceneManager.GetActiveScene().buildIndex);
    var sceneInfo = new NetworkSceneInfo();
    if (scene.IsValid)
    {
        sceneInfo.AddSceneRef(scene, LoadSceneMode.Additive);
    }

    // Start or join (depends on gamemode) a session with a specific name
    await _runner.StartGame(new StartGameArgs()
    {
        GameMode = mode,
        SessionName = "TestRoom",
        Scene = sceneInfo,
        SceneManager = gameObject.AddComponent<NetworkSceneManagerDefault>()
    });
}

チュートリアルでは、OnGUIのボタンからGameMode.HostとGameMode.Clientで呼び分けます。Serverを渡せば専用サーバーとして起動します。

Sharedでプレイヤーを出現させるコード

Sharedでは各クライアントが自分のアバターを自分でスポーンし、そのオブジェクトの状態権限を持ちます。公式チュートリアル（Shared Mode Basics）のスポーン処理です。PlayerSpawnerをPrototype Runnerと同じGameObjectに追加し、NetworkObjectを付けたプレハブをPlayerPrefabに割り当てます。位置も同期する場合はプレハブにNetworkTransformを追加します。

using Fusion;
using UnityEngine;

public class PlayerSpawner : SimulationBehaviour, IPlayerJoined
{
    public GameObject PlayerPrefab;

    void IPlayerJoined.PlayerJoined(PlayerRef player)
    {
        if (player == Runner.LocalPlayer)
        {
            Runner.Spawn(PlayerPrefab, new Vector3(0, 1, 0), Quaternion.identity);
        }
    }
}

player == Runner.LocalPlayerの判定がSharedの権限モデルを表しています。この条件を外すと、誰かが入室するたびに全クライアントがアバターを生成してしまいます。

Multi-Peer Modeによる複数クライアントの動作確認

動作確認のたびにビルドを作る必要はありません。公式のMulti-Peer Modeを使うと、1つのUnityエディタの中で独立したNetworkRunnerを複数動かせます。メニューのFusion > NetworkProjectConfigでPeer ModeをMultipleにし、Tools > Fusion > Windows > Network Runner Controlsから各Runnerの表示切り替えと、どのRunnerが入力を受け取るかを選びます。表示切り替えには、各NetworkRunnerのGameObjectまたはプレハブにRunnerEnableVisibilityコンポーネントを追加しておく必要があります。

全Runnerが同じプロセスで動くため、シミュレーションに影響するstatic変数やシングルトンは衝突します。公式も避けるよう強く勧めており、Multi-Peerで壊れるコードは設計を直す合図です。AudioListenerやEventSystemはEnableOnSingleRunnerで1つのRunnerだけに残します。

ゲーム全体の開発体制やサーバー側の運用まで含めて外部に相談したい場合は、ゲームアプリ開発の支援内容も参考にしてください。

よくある質問

Photon Fusionは無料で使えますか？

開発中は20CCUまでの開発専用プランが無料です。リリース後も1顧客1アプリに限り、100CCUまでのプランを無料で使えます（2026年10月時点の英語版料金ページ）。95ドルの12か月プランを重ねると200CCUまで広げられます。Serverモードの専用サーバー費用はこれとは別です。

Fusion 2.0のプロジェクトはそのまま2.1に上げられますか？

公式は、先に2.0系の最新版（2026年10月時点で2.0.13）へ更新してから2.1へ上げるよう指定しています。音声チャットのVoiceパッケージは2.0用と2.1用で互換性がないため、あわせて差し替えが必要です。

Host Modeはプレイヤー同士のP2P接続ですか？

ホストへの直接接続をNATパンチスルーで試み、失敗したプレイヤーはPhotonのリレー経由でつながります。公式の目安では、リレーになるのはおよそ10人に1人です。

専用サーバーはPhotonが用意してくれますか？

用意されません。公式ドキュメントに、専用サーバーのホスティングはPhotonが提供しないと明記されています。自社運用か外部のホスティングサービスを使います。

Unreal EngineやGodotでもFusionは使えますか？

Fusion 3としてUnreal Engine 5.4〜5.8向けとGodot 4.6以降向けのSDKが配布されていますが、2026年10月時点ではどちらもプレビューで、リリースするゲームには使わないよう案内されています。Unityで使う現行版はFusion 2.1系です。

関連記事

• PlayFabとは？料金プラン・無料枠・Unity SDKの導入手順
• ボイスチャットの実装方法｜WebRTC自作とVivox・Photon Voice等SDKの比較
• Unity 6.3 LTS（6000.3）の新機能と変更点
• ゲーム開発の言語の選び方：Unity・Unreal・Godot・Webのエンジン別に比較
• WebGLとは？仕組み・対応ブラウザの確認・動くコードとUnity WebGLビルドの手順