Unityを触っていると、いつの間にか「Unity Hubのアップデート来てます」って右上にちょこんと出てきますよね。
押していいのか、一旦様子見か、毎回ちょっと迷う…。
この記事では「Unity Hub アップデート」をテーマに、Hubそのものの更新とUnity Editor（エディタ）の更新を分けて整理しつつ、わたしが実際にやっている手順・ハマりどころ・比較の観点をまとめます。
Qiita向けに軽めの独白を混ぜつつ、でも技術は正確に、を心がけます。

前提として、Unityの“アップデート”は二層あります。
①ランチャー兼マネージャであるUnity Hub、②各プロジェクトで使うUnity Editor（2022 LTS、Unity 6 LTSなど）の二つ。
通知が来たときに「どっちの話？」が曖昧だと事故ります。
本文ではまずこの切り分けから入り、再現手順→注意点→トラブル時の復旧→アップデート手法の比較→古い（特定）バージョンの導入という流れでいきます。

ターゲットは「Unity Hub アップデート方法」「Unity Hub アップデートできない」で検索してたどり着いた方、そして「Unity Hub 最新バージョンは？」「Unity Hub バージョン確認ってどこを見るの？」が気になっている方。
プロジェクトを壊さないための“儀式”も包み隠さず書きます。

まずは切り分け：HubのアップデートとEditorのアップデートは別物

Unity Hubは“本体管理アプリ”、Unity Editorは“開発アプリ”です。
Hubを更新しても、既存プロジェクトのEditorは勝手に入れ替わりません。
逆に、Editorを追加・更新してもHubは古いまま動き続けます。
通知の文言も似ているので、ここを混同すると「プロジェクトが勝手に上がった？」みたいな誤解が起きがち。
まずは自分がどちらのレイヤを触っているのか、意識的に見分けます。

わたしは通知を見たら最初にHub左下（または右上プロフィール付近）の“歯車”から[環境設定]→[バージョン情報]（About）を開き、Hubの現在バージョンをメモします。
次に[インストール]タブでEditorの並びと各バージョンを眺め、プロジェクト側の要件と突き合わせ。
これを30秒でやるだけで、判断ミスの半分は消えます。

現場では「EditorはLTS固定、Hubは追従でOK」という運用が多いです。
Hubの更新は機能追加というよりUI改善・バグ修正・証明書更新の比率が高く、比較的影響が軽い。
一方でEditor更新はAPI差分・AssetDB・シリアライザの変更などの地雷が潜むので、プロジェクト単位で計画的に行います。

バージョンを確かめる：HubもEditorも“見える化”してから動く

「Unity Hub バージョン確認」は[環境設定]→[バージョン情報]でOK。
ここに表示されるHub番号（例：3.x / 4.x など）と同時に、[環境設定]→[ライセンス]で認証状態もざっと見ておきます。
Hub更新のあと、まれに再ログインやライセンス再取得が必要になることがあるので、事前に状態を把握しておくと焦りません。

Editor側は、Hubの[インストール]タブに並ぶ“エディター一覧”が一次情報です。
プロジェクトごとに必要なバージョンは[プロジェクト]タブ→対象プロジェクト行の“Editor version”欄で確認できます。
古いプロジェクトだと“このバージョンは未インストール”と出ることも。
そういうときは慌てず“バージョンを追加”→該当バージョンを追加します。

Hubが起動できない等で確認できない場合は、プロジェクト直下のProjectSettings/ProjectVersion.txtを見るのが確実。
テキストには使用中のEditorバージョンが書かれています。
わたしはこのファイルをGitで必ず追跡させ、レビュー時に人間の目でも差分を監視する運用にしています。

# ProjectVersion.txt の例
m_EditorVersion: 2022.3.32f1
m_EditorVersionWithRevision: 2022.3.32f1 (xxxxxxxxxxxx)

わたしはこうやりました：Unity Hubを“安全に”アップデートする再現手順

ここからは実際の手順。
今回は「Hubのマイナー更新が来たので上げたい」という想定です。
ポイントは“プロジェクトを閉じてから”と“Hubキャッシュを一応知っておく”の二つ。
わたしはプロジェクトを完全に閉じ、バックグラウンドでEditorが残っていないかタスクマネージャ（もしくはアクティビティモニタ）で確認してから始めます。

Hub右上の通知、または[環境設定]→[バージョン情報]から[更新]を選択。
Windowsの場合は途中でWindows Defenderのファイアウォール確認が出ることがあり、Privateネットワークは許可にしています（社内規定がある人は従ってください）。
MacではGatekeeperの確認が出たら[開く]。
インストーラはHub自身を再起動してくれます。
再起動後、[環境設定]→[バージョン情報]でもう一度番号を確認。
ここでHubが起動しない・白画面で固まるケースにたまに遭遇します。
そんなときに備えて、Hubのキャッシュ場所も把握しておくと復旧が早いです。
消しすぎると再設定が必要なので、まずはログを眺めるところから。

# よく使うパス（読み取り目的からスタート）

# Windows

%APPDATA%\UnityHub\logs
%APPDATA%\UnityHub
%LOCALAPPDATA%\UnityHub\Cache

# macOS

~/Library/Application Support/UnityHub/logs
~/Library/Application Support/UnityHub
~/Library/Caches/com.unity3d.UnityHub

# Linux

~/.config/UnityHub/logs
~/.config/UnityHub
~/.cache/UnityHub

ログ上でエラーがなければOK。
Hub更新はここで終了。
わたしはこのタイミングでEditor側の“モジュール（Android SDK/NDKやiOS Build Supportなど）”の有無もざっと見直します。
Hub更新直後は気持ち的にメンテナンスモードに入っているので、ついでに棚卸しすると効率がよいです。

Editorの更新は別便：プロジェクトを壊さない“段取り”

「Unityアップデートゲーム」という検索で来た方は多分ここが本命。
Editor更新はプロジェクトへ直接影響します。
わたしは“ブランチを切る→バックアップ→アセット再インポートに時間がかかる覚悟”の三点セットを必ず用意。
CIがあるプロジェクトなら、ビルド用マシンのEditorも同時に揃える段取りを先に組みます。

手順はHubの[プロジェクト]から対象行の“Editor version”をクリック→候補一覧から目的のバージョンを選択→[Open with …]。
このときEditorが未インストールならHubが追加インストールに誘導してくれます。
初回起動時は「Upgrade required」のダイアログが出るので[Continue]。
ここでプロジェクトのメタ情報が更新され、基本的にダウングレードは不可になります。

更新直後はConsoleが赤くなることも。
ScriptedImporterの挙動変更やAPI廃止が要因です。
わたしは「差分を小さく」する方針で、LTS→LTSの“マイナー番手を少しだけ上げる”を繰り返す運用にしています。
複数番手まとめて飛ばすと、修正工数がボディーブローのように効いてきます。

「Unity Hub アップデートできない」系の対処：実際に効いた手筋

Hub更新が走らない・途中で失敗する・真っ白になる…。
わたしも何度か踏みました。
まず効きやすいのは「管理者権限で一度だけ起動（Windows）」「ネットワークのフィルタを疑う」「セキュリティソフトの一時除外（自己責任）」の三つ。
企業ネットワークだとプロキシでブロックされることもあるので、手動インストーラに切り替えます。

白画面のときは、キャッシュとGPUアクセラレーションの相性も疑います。
起動オプションでGPU無効を試すと症状が変わるケースがありました。
ショートカットに引数を付けるか、コマンドラインで起動して挙動を切り替えます。

# GPUアクセラレーションを切る例（お試し）

# Windows（ショートカットのターゲット末尾に）

"Unity Hub.exe" --disable-gpu

# macOS（ターミナルから）

/Applications/Unity\ Hub.app/Contents/MacOS/Unity\ Hub --disable-gpu

それでもダメなら“クリーン再インストール”。
ただし、いきなり全消しはやりすぎ。
まずはアンインストール→再インストール。
復旧しない場合のみ、ログを退避しつつUnityHubフォルダの中身を段階的に削減して再起動…の順でやります。
ライセンス情報・エディタ本体は別階層にあるので、Hubの再導入でプロジェクトが消えることは基本ありません。

比較して選ぶ：自動更新／手動更新、LTS／TECH、そして“いつ上げるか”

Hubの更新方法は大きく“自動（アプリ内通知から）”と“手動（公式サイトのインストーラ）”。
自動は最短で、再起動まで一気に進みます。
手動は社内ポリシーやオフライン環境で重宝。
わたしは通常は自動、社用PCは手動（インストーラを検証＆保管）という運用にしています。

Editorは“LTS（長期サポート）”と“TECH（最新機能寄り）”。
安定運用ならLTS一択。
新機能を先取りしたい検証用ブランチでTECHを使うのはアリですが、製品ブランチへは基本持ち込まないようにします。
リリース直後のLTSは若干の荒れがあることもあるので、わたしは数パッチ様子を見る派です。

“いつ上げるか”。
わたしは「小さく、こまめに」を推します。
半年に一度、作業が薄い週に“メンテ回”を作り、依存関係（Burst/Collections/Input System/Addressablesなど）と合わせて一気に棚卸し。
バージョン間の距離を短く保つことで、移行コストとリスクを分散できます。

古い（特定）バージョンの入手と共存：過去プロジェクトの保守のために

「Unity Hub 古いバージョン」「Unity Hub 古いバージョンインストール」周りは少しややこしいですよね。
ここで言う“古い”がHubなのかEditorなのかで話が変わります。
Hubの旧版は基本的に最新を使うのが無難（認証や配信の都合があるため）。
Editorはプロジェクト保守のために“ピン留め”が必要になるので、必要な番手を個別に共存インストールします。

共存のコツは“Hub任せ”。
Hubの[インストール]→[別バージョンをアーカイブから追加]（環境によって表記差あり）で、必要な番手だけを追加。
エディタ本体はOSごとに別ディレクトリへ入るので、複数同時起動も可能です。
昔のようにUnity.appをリネームする力技はもう不要。

どうしてもHub経由で出てこないピンポイント番手は、公式のアーカイブから.unityhubリンク（または各OS用インストーラ）を取得してHubに渡します。
チームでは“使ってよい番手のリスト”をリポジトリに置いて、合意形成を取っておくと混乱が減ります。

アップデート前後の“こまごま”：アセット＆ビルド環境の整え直し

Editorを上げると、初回起動でアセット再インポートが走ります。
プロジェクト規模次第で数十分かかることもあるので、時間帯を選ぶのが吉。
わたしはLibraryフォルダを消さず、まずは通常起動。
壊れた気配がある場合のみLibrary再生成（削除）に踏み切ります。
再生成は強力ですが、必要な場合だけにします。

外部ツール（Xcode/NDK/SDK/Gradle等）との相性も再確認。
Hubの“モジュール”追加画面で不足分を足し、ビルドマシン（CI）側のEditor番手とモジュールを鏡写しにします。
ここがズレると“ローカルでは通るのにCIで落ちる”地獄に。
わたしはEditor更新のPRに“モジュール一覧のスクショ”を必ず添付するルールにしています。

パッケージ（Package Manager）も要チェック。
manifest.jsonとpackages-lock.jsonの差分をレビューし、com.unity.render-pipelines.*やcom.unity.inputsystemのような重い依存は慎重に。
必要ならscopedRegistriesの解決も合わせてテストします。

小ネタ：CLIでサクッと確認＆復旧の助けにする

GUIが動かないときはCLIでの起動・ログ確認が役立ちます。
HubやEditorはコマンドライン引数を受け付けるので、最小構成で立ち上げて症状を切り分けるのが早道。
ビルドマシンのスクリプト資産があるなら、ローカルでも同じコマンドで再現すると“環境差分”に気づきやすいです。

# Unity Editor をバッチモードで起動（例）
/Applications/Unity/Hub/Editor/2022.3.32f1/Unity 
-projectPath "/path/to/Project" 
-batchmode -nographics -quit -logFile ./Editor.log

# Windows 例（PowerShell）

& "C:\Program Files\Unity\Hub\Editor\2022.3.32f1\Editor\Unity.exe" `  -projectPath "D:\Work\Project"`
-batchmode -nographics -quit -logFile ".\Editor.log"

Hub側のログは前述のlogsディレクトリに出ます。
更新直後に不可解なクラッシュが続くなら、--disable-gpuオプションや、VPN/プロキシを一時的に外して挙動が変わるかチェック。
ネットワーク由来かUIレンダラ由来か、当たりを付けてから次の一手を選ぶと消耗が減ります。

余談ですが、WindowsでHubの自己更新が失敗しがちなマシンに遭遇したとき、イベントビューアでWindows Installerのログを見たら古い残骸が邪魔していました。
アンインストール→再インストールで解決。
Hubは“設定”より“健全に起動すること”が最優先なので、割り切りも大切です。

まとめ：落ち着いて分解すれば、Unity Hubの更新は怖くない

ここまでの要点です。
①Hubの更新とEditorの更新を分けて考える、②更新前に“今の状態（バージョン・ライセンス）”を目視、③Hubは自動更新でOK、ダメなら手動インストーラ、④Editorはブランチを切って小刻みに上げる、⑤困ったらログ→ネットワーク→GPU無効→クリーン再導入の順で切り分け、です。

わたしのやり方は“過剰に用心深い”側かもしれません。
でも、Unityアップデートは小さな投資で大きな事故を回避できる領域。
数十分の準備で、後日の数日の復旧を丸ごと消せます。
Hubは普段の作業を支えるインフラなので、健康診断のつもりでこまめにメンテしてあげると、開発の体感がじわっと良くなります。

最後にもう一度だけ。
プロジェクトを壊すのは“急なEditor更新”です。
Hubの更新はむしろ心身にやさしい部類。
焦らず、分けて、記録して、戻せる体制で。
この記事が、次に「アップデート来たな…どうしよう」のときの背中押しになればうれしいです。

もしUnityの教材や便利ツールを探しているなら、わたしは最近Unity入門の森ショップをのぞくことが多いです（アップデート後の検証用サンプル探しにちょうどよい）。