「Unity Hub ログイン」で詰まる事例を、はてな向けに検証ログとして構造化しました。
目的は“だれでも同じ現象を再現し、同じ結論に到達できる”こと。
記事は、環境の明記→再現手順→観測ログ→仮説→切り分け手順→比較（ブラウザ／OS／ネットワーク／アカウント）→最終結論、という流れです。
実験の粒度は、個人PC（家庭回線）と企業PC（VPN／プロキシ配下）の二系統で統一。
読了後は、読者自身の環境でも最短で原因に近づけるはずです。
前提として、Unity Hubのサインインは「Hub→外部ブラウザでUnity ID認証→`unityhub://` スキームでHubへ呼び戻し」という“ブラウザ往復”フローです。
従って、既定ブラウザ／ポップアップ制御／Cookie／ネットワーク（プロキシ／VPN）／アカウント整合性（Google連携とメールIDの混在）といった周辺要素が結果を左右します。
本稿では、それぞれを個別に観測可能な形に分解し、実験のやり直しが効くように順序化しました。
なお、本文では表の代わりに箇条書き・手順・コードを用います（はてな記法・GFM互換を想定）。
スクリーンショットがなくても再現できるレベルまで文面を具体化しました。
プロダクトの微細なUI差分はあり得ますが、判断基準は“ブラウザに許可ダイアログが出るか／Hubのアバターがアカウント名になるか／Editor右上がSign outに変わるか”の三点で不変です。
検証環境（バージョン・ネットワーク・ブラウザ・アカウント条件）
OSはWindows 11 Pro（23H2）とmacOS Sonomaを使用。
Unity Hubは検証当時の最新安定版（自動更新有効）を前提とし、Hubのマイナー差異によるUIの変化はログ側で補足します。
Editorは最新版LTSを1系のみ導入した最小構成。
追加モジュール（Android/iOS）は未導入で、ログイン周辺の副作用を排除しました。
セキュリティはWindows Defender標準・macOS標準を基本に、一部EPP（企業PC）で追加検証しています。
ネットワークは二条件。
A: 家庭回線（NAT・IPv4/IPv6混在、VPN OFF、プロキシ未設定）。
B: 企業回線（常時VPN、WinHTTPプロキシ有、TLSインスペクション有）。
Aは“素通しベースライン”、Bは“制限あり実運用”として比較します。
両条件ともDNSはOSデフォルト。
時間同期はOSの自動同期をオンにして誤差を±1秒以内に揃え、証明書検証の日時起因を排除しました。
ブラウザはChrome（最新）、Edge（最新）、Safari（macのみ）、Vivaldi（プライバシー保護と拡張多め）の4種で比較。
既定ブラウザの切替はOS設定から行い、各試行前に“Unity関連Cookieの個別削除→ブラウザ再起動”を徹底。
Unity IDは「メール＋パスワード」と「Google連携」の2パターンを用意。
意図的な“ID取り違え”試行を含み、混在時の失敗挙動を観測しました。
再現手順（誰でも同じ条件を作れる最小ステップ）
本章は「Unity Hub ログインできない」を意図的に引き起こす／解消するための再現プロトコルです。
成功パスを先に踏む→失敗パスを誘発→切り分け、の順。
各ステップの最後に“観測ポイント”を付記しています。
- Unity Hubを起動→左上アバター→「サインイン」をクリック（既定ブラウザはChrome）。
- 自動起動したブラウザでUnity IDにサインイン（メール or Google）。
- ブラウザ上部に「Unity Hubを開きますか？」（`unityhub://` の許可）→「開く」。
- Hubへフォーカス復帰→アバターが“アカウント名”表示に変化。Editor右上が「Sign out ○○」。
観測ポイントは次の3つです。
1) ブラウザが開かない（既定ブラウザ周り）。
2) ブラウザは開くが許可ダイアログが出ない（ポップアップ／プロトコル制御）。
3) 許可後にHubへ戻っても未ログイン（Cookie／ID整合／ネットワーク遮断）。
この三分岐のどこで止まるかで、次の切り口が確定します。
失敗パスの誘発は「既定ブラウザをVivaldi＋拡張ON」「企業VPN ON」「WinHTTPプロキシ設定を意図的に残す」の3条件が再現性高め。
再現性を担保するため、各試行前にCookie個別削除（`id.unity.com` / `unity.com`）→ブラウザ再起動→Hub再起動を行います。
同一条件で2回ずつ往復し、偶然要因（キャッシュやレース）を均します。
観測ログ（成功／失敗の具体ログと兆候）
以下は代表的なログ断片です。
Hubのログ位置はOSごとに異なります。
Windowsは `%UserProfile%\AppData\Local\UnityHub\logs` / `%UserProfile%\AppData\Roaming\UnityHub`、macOSは `~/Library/Logs/UnityHub` / `~/Library/Application Support/UnityHub` が目安。
テキスト検索で `unityhub://` / `sign-in` / `error` を拾うと早いです。
# 成功例（家庭回線 / Chrome）
[Auth] Received external auth callback: unityhub://signin?code=********
[Auth] Token exchange succeeded (expires_in=3600)
[UI] Account avatar updated: [user@example.com](mailto:user@example.com)
成功時は“callback受領→トークン交換成功→アバター更新”の順で並びます。
トークン期限（`expires_in`）が秒で出るケースもあります。
続けてEditorを起動し、右上が「Sign out ユーザー名」になればHubと連携済みです。
Package Managerで“My Assets”が表示されれば、実運用面の認証連携もOKと判断できます。
# 失敗例1（許可ダイアログ不出 / Vivaldi）
[Auth] Waiting for external auth callback...
[Warn] External protocol blocked or no handler registered for unityhub://
[Info] No account change detected
“no handler registered”は、OSレベルで `unityhub://` がブラウザに許可されず、Hubに戻れない典型。
既定ブラウザ切替（Chrome/Edge/Safari）→再試行で解消可能でした。
ブラウザ上のポップアップブロックが同時に起きていると、許可ダイアログ自体が出ず、待機のまま沈黙します。
# 失敗例2（プロキシ配下 / 企業VPN）
[Auth] Received external auth callback
[Auth] Token exchange failed: HTTP 407 Proxy Authentication Required
[Auth] Sign-in aborted
HTTP 407/403 はネットワーク層で止められている兆候。
Hub—認証サーバ間のトークン交換がプロキシ認証に阻害されるパターンです。
WinHTTPやシステムプロキシの影響域がHubに及ぶと再現しやすく、素の回線（テザリング等）に切り替えると即解消することが多いです。
# 失敗例3（アカウント不整合）
[Auth] Callback received for account: [google_user@example.com](mailto:google_user@example.com)
[Auth] Current session belongs to: [mail_user@example.com](mailto:mail_user@example.com)
[Warn] Account mismatch; ignoring callback
“Account mismatch”は“ブラウザでA、Hubの現セッションはB”というズレ。
Hub側でSign out→ブラウザ側もUnity IDいったんログアウト→同じ方式（メール or Google）で揃えて再試行、で安定します。
多要素認証を併用している場合は、呼び戻しまでの有効時間に注意します。
原因仮説と検証（各ボトルネックを分離して潰す）
仮説A：既定ブラウザ／プロトコル許可起因。
指標は“許可ダイアログの有無”と“no handler系ログ”。
Chrome/Edge/Safariに切り替え、ポップアップを“サイト別に常時許可”へ。
`id.unity.com` / `unity.com` のCookie／サイトデータを個別削除→再起動→再試行で改善が見込めます。
シークレットウィンドウ（拡張OFF）での再試行も効果的でした。
仮説B：ネットワーク（プロキシ／VPN）起因。
指標はHubログのHTTP 407/403、もしくは無言失敗と同時に企業EPPのブロックログ。
切り分けは“別ネットワークで成功するか”。
成功するならネットワーク側要因確定。
WinHTTPプロキシの既定化リセット（Windows）や一時的WebプロキシOFF（macOS）で挙動が変わるかを観測します（後述コード）。
仮説C：アカウント整合性起因。
指標は“Account mismatch”。
Hub/ブラウザ双方のログアウト→使う認証方式をひとつに固定（メール or Google）→再ログイン。
多ID環境では“Hubのサインアウト→ブラウザで先に目的のIDにログイン→Hubでサインイン”の順が最も安定しました。
切り分け手順（優先度順・巻き戻し容易）
破壊的変更を避け、元に戻しやすい順で並べています。
各ステップ後に観測ポイントを確認し、改善が見られた時点で終了します。
重ねがけは避け、1手ずつ有意差をとります。
- ブラウザのポップアップ許可：`id.unity.com` / `unity.com` を“常に許可”。
- Cookie／サイトデータの個別削除：上記2ドメインのみ→ブラウザ再起動。
- 既定ブラウザをChrome/Edge/Safariに一時変更→再試行→戻す。
- Hub側Sign out→ブラウザ側Unity IDログアウト→目的の方式で統一再ログイン。
- シークレットウィンドウ（拡張OFF）でサインイン→許可→Hub復帰の観測。
ネットワーク系の“観測用”一手は以下。
いずれも元に戻しやすいのが利点です。
企業PCではポリシーに注意のうえ、自己責任で。
通ったら「ネットワーク要因」と結論でき、恒久対応（ネットワーク管理側の例外設定）に進めます。
# Windows: 管理者で WinHTTP プロキシ設定を既定に戻す
netsh winhttp reset proxy
# macOS: 指定サービスのWebプロキシを一時的にOFF（作業後にONへ戻す）
networksetup -setwebproxystate "Wi-Fi" off
さらに、OS時間同期（証明書検証対策）と拡張機能OFF（真っ白画面対策）を並走で。
時間ずれは“説明のつかない失敗”の温床です。
Windowsは「今すぐ同期」、macOSは「日付と時刻の自動設定」をオン。
これで1件救えることがあります。
比較：ブラウザ／OS／ネットワーク／認証方式の差分
ブラウザ比較（家庭回線）：Chrome＝Edge＝Safariは安定。
Vivaldiは拡張・トacking保護が強いプロファイルで許可ダイアログが出ない事例が高頻度。
Vivaldiでも“シークレット＋拡張OFF＋一時既定化”で通過を確認。
結論として“最初のログインはChrome/Edge/Safariで行い、以後は任意ブラウザに戻す”がコスト最小でした。
OS比較（ブラウザ同等条件）：Windows/macOSとも成功率に有意差なし。
差分は“設定UIの所在”と“ログのパス”のみ。
macOSは`networksetup`でWebプロキシのON/OFFが即座に観測でき、切り分け効率が良好。
WindowsはWinHTTPが残留しているとHubの挙動に影響が出るため、`netsh winhttp reset proxy` の一手が効きました。
ネットワーク比較：家庭回線では成功率ほぼ100%。
企業VPN＋プロキシでは`HTTP 407` が一定割合で再現。
TLSインスペクション環境では、`unityhub://` の呼び戻し自体はローカル処理だが、コールバック後のトークン交換がProxy Authに阻害されやすい。
恒久対応は“id.unity.com / unity.com の認証・遷移を例外化”が王道。
観測で確証が取れたら、管理者に具体ドメインを提示して申請するのが近道でした。
認証方式比較：Google連携の方が“セッションの前倒し作成”でスムーズな傾向（ブラウザに既存ログインが残っているため）。
一方で“メール方式＋別タブGoogleログイン併存”はミスマッチを誘発。
ポリシー上Google不可の環境では、メール方式一本化＋Cookie整理の徹底で再現良好。
どちらも“方式をその日の試行中は固定する”が安定化の鍵でした。
付随検証：日本語表示・時間同期・アセット連携の確認
「unity hub 日本語」系の混在は、実害より“操作不安”を増やします。
Hub本体はOS言語、ログイン画面はブラウザ優先言語／Unity IDプロフィール語に依存。
OSの表示言語とブラウザの優先言語を日本語に揃えると表記が安定。
英語のまま運用する利点（情報検索のヒット率）もあり、好みで良いですが“混在を避ける”観点が重要です。
時間同期は、認証周りの不可解な失敗の温床。
Windows「今すぐ同期」、macOS「日付と時刻を自動で設定」を一度トグルしておくと、証明書の“まだ有効でない／すでに失効”系の陰干渉を防げます。
観測では、企業PCの一部でNTP誤差（数分）があり、これを補正後に即時成功へ切り替わりました。
アセット連携の確認はEditor側で実施。
Hubサインイン後、Editor起動→右上が「Sign out ユーザー名」へ→Package Managerの“My Assets”が一覧されるか。
表示されない場合は“Editorだけ未サインイン”ケースが残っている可能性。
Editor右上のAccount→Sign in…からブラウザ往復をもう一度実施し、再観測します。
ここでアセットが落ちない場合は、セキュリティのリアルタイム監視やストレージ権限を疑います。
チェックリスト（最短で再現→解消するための実行順）
実運用向けに“戻しやすい順・効果が見えやすい順”で要約します。
1手ずつ行い、各手の直後に“許可ダイアログ出現／Hubアバター変化／Editor Sign out表示／My Assets表示”のいずれかで観測します。
- ブラウザ許可：`id.unity.com` / `unity.com` をポップアップ“常時許可”。
- Cookie個別削除：上記2ドメインだけ削除→ブラウザ・Hub再起動。
- 既定ブラウザ一時変更：Chrome/Edge/Safari→サインイン→通過後は元へ。
- アカウント統一：Hub Sign out→ブラウザで目的IDのみログイン→Hubで再サインイン。
- シークレットウィンドウで試行（拡張OFF状態で“素通し”観測）。
- ネットワーク切替：自宅Wi-Fi／テザリングで試行→通ればネットワーク起因確定。
- 観測用コマンド：`netsh winhttp reset proxy`（Win）／`networksetup -setwebproxystate "Wi-Fi" off`（Mac）。
- 時間同期と再試行：OSの時計を同期→即時再試行。
補助情報として、Hub/Unity関連のローカルフォルダ覚書（削除は自己責任・Hub終了後に実施）。
Windows：`%UserProfile%\AppData\Roaming\UnityHub` / `%UserProfile%\AppData\Local\UnityHub\logs` / `%UserProfile%\AppData\Roaming\Unity\packages`。
macOS：`~/Library/Application Support/UnityHub` / `~/Library/Logs/UnityHub` / `~/Library/Application Support/Unity`。
まずはAuth周りjsonの破損疑いだけを限定削除→再観測が安全です。
結論（要点の収束と実務的示唆）
結論1：Unity Hub ログインの本質は“ブラウザ往復”であり、失敗の8割は“許可（ポップアップ／`unityhub://`）・Cookie・既定ブラウザ・ID整合性”のレイヤで説明できます。
順序を守って整えるだけで、家庭回線ではほぼ解決。
初回はChrome/Edge/Safariで通し、その後は任意ブラウザに戻す運用がコスト最小でした。
結論2：企業VPN／プロキシ配下の失敗は“HTTP 407/403”が指標で、これはユーザー側の努力だけでは限界があります。
まずは別ネットワークで成功させて“ネットワーク要因”の確証をとる→ネットワーク管理へ“`id.unity.com` / `unity.com` 認証・遷移と `unityhub://` 呼び戻しの許可”を具体ドメインで申請、が最短でした。
観測用コマンドは“戻しやすい一時策”に留めます。
結論3：Editor側のサインインとアセット連携の確認までを一連の検証パスとし、Hubサインインだけで終了しない。
右上「Sign out ユーザー名」と“My Assets”の可視化が得られれば、実務オペレーション（パッケージ導入・アセット取得）までスムーズに移行できます。
学習や制作の初動でのタイムロスを最小化できます。
最後に実務的示唆。
ログインで時間を溶かさないために、初回のみ“成功率が高い標準ブラウザ＋素ネットワーク”で確実に通す→以後は好みの設定に戻す、という“最小抵抗ルート”をチーム標準にするのがおすすめです。
新人オンボーディング用の社内手順にも、本稿のチェックリストを転記すると、再現性の担保と時短に寄与します。
環境が整ったら、教材は一本化して迷いを減らすのも有効でした。
わたしはUnity入門の森ショップで初動の学習導線を一本に絞り、検証時間を制作時間に置き換えています。
