Plastic SCMは、Unityが買収したバージョン管理システムで、2023年に「Unity Version Control（UVCS）」へ名前が変わりました。この記事では、2026年10月時点の公式ドキュメントをもとに、エディター統合パッケージ2.13系の導入、cmコマンドでのリポジトリとワークスペースの作成、ignore.confの書き方、ロックルールの設定、Gitからの移行手順を、コピーして使えるコマンド付きで示します。2026年3月1日に座席課金が廃止された新しい料金体系と、Git＋Git LFSで足りる場面との線引きも判断基準として整理します。
まとめ：Plastic SCM（現Unity Version Control）を選ぶ条件とGitで足りる場面
Unity Version ControlはPlastic SCMそのものの後継で、中身の仕組みは引き継がれています。検索で見つかる「Plastic SCM」の手順は、名称と料金の記述を読み替えれば多くがそのまま通用します。ただし料金は2026年3月1日に大きく変わり、無料枠は25GB・座席数は無制限になりました。
採用を勧めるのは、テクスチャや3Dモデルなどのバイナリ資産が多く、アーティストとプログラマーが同じリポジトリを触るUnityのチームです。ファイルロックと部分ワークスペースが標準で使える点が、Gitとの差になります。逆に、コード中心でCIやレビューをGitHubに寄せているチームは、Gitを続けた方が運用は軽く済みます。
Plastic SCMとUnity Version Controlの関係と改称後の提供形態
まず名称の整理です。古い記事と新しい公式ドキュメントで呼び名が違うため、ここを押さえないと手順の新旧を見分けられません。
2023年の改称とVersion Controlパッケージ2.13系の位置づけ
エディター統合パッケージcom.unity.collab-proxyの変更履歴には、2.0.1（2023年2月17日）で「Plastic SCM」から「Unity Version Control」へ表記を改めたと記録されています。CLIの実行ファイル名はcmのまま、設定ディレクトリもplastic4のままで、内部には旧名が残っています。
Unityのパッケージレジストリで確認すると、2026年10月4日時点の最新は2.13.6（2026年8月6日公開）で、対応するエディターはUnity 6（6000.0）以降です。スタンドアロンのクライアントとCLIは、今もplasticscm.comのダウンロードページから入手します。
Gitとの設計差：大容量バイナリと排他ロックを前提にした構造
Gitは各開発者が全履歴を手元に持つ分散型で、大きなバイナリは拡張機能のGit LFSで外に逃がします。Unity Version Controlはサーバー側に履歴を置く中央型の運用を基本とし、ファイル単位のロックと、必要なファイルだけを取得する部分ワークスペースを最初から備えています。
もう一つの差は履歴の扱いです。公式のGitからの移行ガイドは、UVCSは履歴を書き換えない設計だと明記しています。Gitのrebaseで履歴を整える文化に慣れたチームは、この前提を最初に共有しておきます。ブランチの考え方そのものはブランチの仕組みと使い方と共通です。
Unity Version Control導入：エディター統合とcmコマンドの準備手順
導入経路は2つあります。エディター内で完結させるならパッケージ、スクリプトやCIから操作するならCLIのcmを使います。
Unity 6でのVersion Controlパッケージ追加手順
Unity 6のプロジェクトでは、Package Managerで「Unity Version Control」（パッケージ名com.unity.collab-proxy）を追加します。旧来のAsset Store版Plastic SCMプラグインが残っているプロジェクトは、パッケージと二重にならないよう、プラグインを削除してから入れ替えます。
追加後はエディターのメニューからUnity Version Controlのウィンドウを開き、Unity IDでサインインして組織とリポジトリを選びます。対応するエディター版を先に固めたい場合は、Unity 6.3 LTSの変更点とサポート期限で現行LTSの条件を確認してください。
cmコマンドでクラウドのリポジトリとワークスペースを作る初回設定例
CLIのcmは、スタンドアロン版をインストールすると使えるようになります。workspace createのリファレンスにあるとおり、クラウドのリポジトリは「リポジトリ名@組織名@cloud」の形で指定します。以下は、組織myorgにリポジトリを作り、ローカルに作業領域を用意して初回の取り込みをするまでの流れです。
# リポジトリを作成（サーバー指定は 組織名@cloud）
cm repo myorg@cloud MyGame
# ワークスペースを作成し、そのディレクトリへ移動
cm wk mk MyGame-wk C:\work\MyGame MyGame@myorg@cloud
cd C:\work\MyGame
# Unityプロジェクトを置いたら、未登録（private）を含めて状態を確認
cm status
# private項目も含めてチェックイン
cm ci . --private -c="初回取り込み"checkinのリファレンスでは、--privateがワークスペース内の未登録ファイルを含める指定、--allが変更・移動・削除を含める指定です。初回は先に次のignore.confを置いてから実行しないと、Libraryまで登録されてしまいます。用語の前提はリポジトリの仕組みとコミットの粒度とメッセージ設計で補えます。
ignore.confでLibrary・Tempを除外する設定とアップロード済みファイル
公式の無視ファイルの説明は、Unityが自動で作り直すディレクトリを除外するよう勧めています。中でもLibraryとTempはファイル数が多く、数GBになることがあります。公式の例から主要部分を抜き出すと次のとおりです。
# Unityが再生成するディレクトリ
Library
Temp
Obj
Build
Builds
UserSettings
Logs
# IDEが生成するファイル
*.csproj
*.sln
*.suo
*.user注意点は1つです。ignore.confが効くのは未登録のファイルだけで、すでにサーバーへ上げたファイルには効きません。誤ってLibraryを登録した場合は、無視設定を足すだけでは消えないため、削除をチェックインしてから無視の対象にします。ignore.conf自体をリポジトリに登録すれば、他のメンバーにも次回の更新で配られます。
チーム運用の設定：ロックルールとGluonで資産の上書きを防ぐ方法
Unity Version Controlを選ぶ最大の理由が、この章のファイルロックです。マージできないバイナリの同時編集を、仕組みで止めます。
Unity Dashboardのロックルールで拡張子ごとに排他チェックアウト
クラウド版のロックルールは、組織設定のドキュメントのとおり、Unity Dashboardの「DevOps」→「Settings」→「Lock Rules」で設定します。組織全体に効くルールは1つだけ作れ、リポジトリ単位のルールがあればそちらが優先されます。
設定画面の「Generate common rules」を押すと、よく使われる拡張子が自動で入ります。そこへ自社で使う.psdや.fbxなどを足し、ロックを適用するブランチを選んで保存してください。自動処理や試作用のブランチは「Exclude branches」で外せるので、ロック待ちでビルドが止まる事態を避けられます。オンプレミス版では同じ内容をlock.confに書きます。
Gluonの部分ワークスペースでアーティストが必要なファイルだけ扱う運用
Gluonは、ブランチを使わずに必要なファイルだけを取得して編集する、アーティスト向けのクライアントです。Gluonのチェックアウトとロックの説明には、チェックアウトがファイルをロックするのはサーバーにロックルールがある場合だけ、と書かれています。
ルールが無い環境で確実に押さえたいときは「Lock and checkout」を選び、フォルダ単位なら「Checkout recursively」を使います。CLIではcm partial checkoutが対応します。運用で事故が起きやすいのは、ロックルールを作らずにGluonを配ったケースです。チェックアウトしたつもりで実はロックされておらず、同じテクスチャを2人が上書きします。導入初日にルールを作ってからクライアントを配ってください。
GitからUnity Version Controlへの移行：cm syncの手順と制約
既存のGitリポジトリは、履歴ごとUVCSへ取り込めます。取り込んだ後もGit側と同期を続けられるため、段階的な移行が可能です。
cm syncで履歴を取り込みGitと並行運用するコマンド例
syncコマンドのリファレンスによると、初回はGitのURLの指定が必須で、2回目以降は同じコマンドで差分だけを取り込みます。コミット・ブランチ・タグ・マージの情報も移ります。
# 取り込み先のリポジトリを用意してから、GitHubの履歴を取り込む
cm repo myorg@cloud MyGame
cm sync MyGame@myorg@cloud git https://github.com/myorg/mygame.git
# Gitのユーザーとメールの対応（Windows: %LOCALAPPDATA%\plastic4\gitsync.conf）
[email-mapping]
taro = [email protected]Gitの作成者名と時刻を残したいときに付けるオプションは--authorです。大きなリポジトリをGitへ送り返す処理は、既定で1,000チェンジセットずつに分けて実行され、--gitpushchunkで単位を変えられます。.gitattributesのGit LFS設定は既定で解釈され、無視したいときだけ--skipgitlfsを付けます。
rebaseとfast-forwardマージが使えない制約とブランチ名の変換
並行運用中は、Git側でgit rebaseとfast-forwardマージを使わない取り決めが要ります。移行ガイドは、マージ時にgit merge --no-ffを使うよう求めています。履歴を書き換える操作は、UVCS側の履歴と食い違うためです。
ブランチ名も、同期時に変換される対象です。UVCSの/mainはGitのmasterに、階層の区切りの/は-になり、/main/scm005はmaster-scm005として見えます。GitとUVCSで同じブランチを同時に変更した場合、UVCSは取り込み時にサブブランチを作るので、UVCS側でマージして解消します。解消の考え方はコンフリクトの解消手順と予防設計と同じです。
2026年3月の料金改定：座席課金廃止とストレージ従量課金の中身
ここは古い記事と最も食い違う部分です。2026年3月1日から、クラウド版の課金の軸が「人数」から「保存量と転送量」に移りました。
無料枠25GB・転送100GBと超過単価0.14ドル・0.10ドルの試算
Unityの料金改定ページとサポート記事の料金解説によると、無料枠は保存25GB・転送100GB（いずれも月あたり）で、座席は無制限です。Unity Personalの利用者に課されていた無料3席の上限も無くなりました。
| 項目 | 無料枠（月） | 超過分の単価 | 保存60GB・転送300GBの場合 |
|---|---|---|---|
| ストレージ | 25GB | 0.14ドル／GB | 35GB超過で4.90ドル |
| 転送量（egress） | 100GB | 0.10ドル／GB | 200GB超過で20.00ドル |
| 座席 | 無制限 | 課金なし | 0ドル |
表の試算では月24.90ドルです。転送量は、2026年3月と4月の分が全額免除され、5月から請求が始まっています。メンバー全員が毎日大きな資産を取得するチームでは転送量が先に膨らむため、部分ワークスペースで取得範囲を絞る運用が費用にも効きます。
旧記事の「無料5GB・GB時間」の記述が古くなった点と請求の見方
2024年頃までの解説記事には、無料枠5GBや「GB時間」で保存量を数える説明が残っています。料金改定ページでは、保存量の単位がGB時間からGBに統一されたと説明されており、この計算はもう当てはまりません。
サポート記事は、旧来のPlastic SCMの契約やオンプレミス構成には別の条件が適用される場合があるとも注記しています。改定前から契約しているチームは、自社の契約がクラウドの新体系に移っているかをDashboardの請求画面で確かめてください。
Unity Version ControlとGit＋Git LFSの採否判断
最後に、両製品の使い分けについて、採用する条件と見送る場面を示します。判断の軸は、バイナリ資産の比率と、アーティストが日常的にコミットするかどうかの2点です。
アート資産が多くロックが必要な制作チームで採用する際の判断基準
| 条件 | Unity Version Control | Git＋Git LFS |
|---|---|---|
| アーティストが毎日コミットする | Gluonで扱いやすい | CLIやGit操作の教育が要る |
| マージできない資産の同時編集を防ぐ | ロックルールで拡張子ごとに強制 | LFSのロックを個別に運用 |
| コードレビュー・CIの連携先 | Unity DevOps中心 | GitHub・GitLabの機能をそのまま使える |
| 費用の増え方 | 保存量と転送量の従量 | ホスティング先の席数とLFS容量 |
アート資産がリポジトリ容量の大半を占め、アーティストが3人以上いるなら、Unity Version Controlを選びます。ロックを人の注意に頼らず仕組みで止められる効果が、乗り換えの手間を上回ります。
Unity Version Controlを選ばない方がよい場面とGit運用の継続判断
コードが中心で、プルリクエストのレビューやCIをGitHubやGitLabで回しているチームには勧めません。UVCSへ移すと、レビューや自動テストの連携を組み直す必要が出ます。Git側の選択肢はGitHubとGitLabの料金・CI/CDの比較で検討できます。
既存のGit運用を、名前が変わったから、無料枠が増えたからという理由だけで移すのも見送ります。移行の対象は、資産の上書き事故が実際に起きている、またはアーティストのGit操作が作業を止めている場合に限定する方針です。開発体制ごと外部に任せる場合は、ゲームアプリ開発で、バージョン管理の方式選びから相談できます。
Plastic SCM・Unity Version Controlのよくある質問
Unity Plastic SCMの使い方と料金について検索されやすい疑問に、短く答えます。名称の違い、料金、Gitとの関係、導入時の注意点をまとめました。
Plastic SCMとUnity Version Controlは別の製品ですか？
同じ製品です。Unityが開発元を買収した後、2023年に名称をUnity Version Control（略称UVCS）へ変えました。エディター統合パッケージの変更履歴では、2.0.1（2023年2月17日）で表記を改めています。CLIのcmや設定ディレクトリplastic4など、内部には旧名が残っています。
Unity Version Controlは無料で使えますか？
2026年3月1日以降のクラウド版は、保存25GB・転送100GBまでが毎月無料で、座席数は無制限です。超過分は保存が1GBあたり月0.14ドル、転送が1GBあたり0.10ドルの従量課金になります。旧来のPlastic SCM契約やオンプレミス構成は別条件の場合があるため、契約内容を確認してください。
Plastic SCMとGitの違いは何ですか？
Gitは全履歴を各自が持つ分散型で、大きなバイナリはGit LFSで扱います。Unity Version Controlはサーバー中心の運用が基本で、拡張子ごとのファイルロックと、必要なファイルだけを取る部分ワークスペース（Gluon）を標準で備えます。また、履歴を書き換える操作をしない設計です。
GitHubのリポジトリをPlastic SCMへ移行できますか？
GitHubのリポジトリからの移行は可能です。cm syncにリポジトリとGitのURLを指定すると、コミット・ブランチ・タグ・マージ情報を取り込めます。2回目以降は同じコマンドで差分だけを取り込めるので、並行運用しながら移行できます。並行運用中はGit側でrebaseとfast-forwardマージを使わないでください。
ignore.confに書いたのにLibraryフォルダが登録されてしまうのはなぜですか？
ignore.confは未登録のファイルにしか効かないためです。一度サーバーへ上げたファイルは、無視設定を足しても管理対象のまま残ります。Libraryを誤って登録した場合は、削除をチェックインしてから無視の対象にしてください。初回の取り込み前にignore.confを置くのが確実です。
関連記事
- ゲーム開発会社の選び方は？費用相場と内製・外注の判断基準を発注者視点で解説：Unity案件を外注する前に押さえる全体像
- ブランチとは？バージョン管理で開発を分岐させる仕組みと使い方を実装視点で解説：UVCSのブランチ運用の前提
- Unity 6.3 LTS（6000.3）の新機能と6.2からの変更点｜サポート期限・対応OS・移行の注意点：パッケージが対応するエディター版の確認
- UnityMCPとは｜AIでUnityエディタを操作するMCPサーバーと導入手順【2026年版】：AIでエディター操作を自動化する周辺ツール
- GitHubとGitLabの違い｜料金・Free枠・CI/CD・セルフホストを比較【2026年版】：Gitを続ける場合のホスティング比較
