JupyterLab 4.6.4でリモートMacにアクセスできない場合の対処法：2026

最初に選ぶべき方法は、単独利用ならJupyter Serverをlocalhostだけで待ち受けさせ、SSHトンネル経由で接続することです。認証を無効にしたり、保護されていないサービスを外部へ直接公開したりしないでください。複数人で使う場合は、個人用サーバーを共有せず、多人数向けの構成を別に検討します。

この手順は、実験室にMacがなく、遠隔MacでJupyterLabを使いたい大学院生に向いています。
ページが開かない、認証に通らない、接続が途切れる研究者にも役立ちます。
研究室の技術担当者は、個人用の接続設定とグループ利用の境界を確認できます。

最終更新とバージョン確認

最終更新：2026年9月30日。JupyterLabの安定版ドキュメント、Jupyter Serverの認証・公開サーバー文書を照合しています。公式の安定版ドキュメントでは、対象バージョンをJupyterLab 4.6.4として確認できます。利用中の版が異なる場合は、画面の見え方だけで判断せず、サーバー側のバージョンも確認してください。(JupyterLabの安定版ドキュメント)

ページ、サーバー、カーネルは同じものではありません。ブラウザーに表示されるJupyterLabは画面、Jupyter Serverはリクエストを受け付けるプロセス、カーネルはコードを実行するプロセスです。画面が開かないなら、まず接続経路とサーバーを確認します。ページは表示されるのにセルが実行できない場合は、カーネル側の問題として切り分けます。

症状から接続箇所を切り分ける

ページが開かないとき、最初に何を確認しますか。

ブラウザーのアドレスが、遠隔Macではなく手元のPC自身を指していないか確認します。SSHトンネルを使う場合、ブラウザーの接続先は通常、手元のPCのlocalhostです。接続方法、完全なエラーメッセージ、発生した時刻を記録し、遠隔Mac上でサーバーが動作中かを確認してください。

遠隔Macのターミナルで、Jupyter Serverが登録している接続先を確認します。

jupyter server list

出力例は次のようになります。これは形式を示す例であり、トークンは実際の環境で確認してください。

http://localhost:8888/?token=（省略） :: /作業ディレクトリ

この表示がなく、サーバーのプロセスも確認できない場合は、ブラウザーやトンネルの設定を変更する前にサーバー側を調べます。プロセスが動作しているのにページが開かないなら、次に待受アドレスと接続経路を確認します。

localhost待受とSSHトンネル

Jupyter Serverがlocalhostだけで待ち受ける設定は、起動していないことを意味しません。別のPCから遠隔Macへ直接アクセスできないのは、そのPCから見た待受先が異なるためです。単独利用では、全ネットワークインターフェースに公開するのではなく、SSHでポートを転送する方法を優先します。待受やポートに関する設定値は、Jupyter Serverの設定項目リファレンスで照合できます。

localhostだけで待ち受けているサーバーに、別のPCから接続するにはどうしますか。

まずSSHで遠隔Macにログインできることを確認し、手元のPCで次の形式のトンネルを開きます。利用者名と遠隔Macの接続先は、実際の環境に置き換えてください。

ssh -N -L 8888:127.0.0.1:8888 利用者名@遠隔Macの接続先

-Lは手元のポートから遠隔側の指定先へ転送する指定です。OpenSSHのポート転送仕様は公式マニュアルで確認できます。トンネルを維持したまま、手元のブラウザーで http://127.0.0.1:8888/lab を開きます。Jupyter Serverのポートを変更している場合は、コマンドの両方のポート番号と接続先を、実際の設定に合わせてください。

手順を混同しないため、以下の順番で確認します。

遠隔Mac上で jupyter server list を実行し、サーバーが起動していることを確認します。
同じMac上でlocalhost宛ての接続先が表示されるか確認します。
手元のPCからSSHログインができるか確認します。
SSHトンネルを開いた状態で、ブラウザーの宛先を手元のlocalhostにします。
認証後にNotebookを開き、カーネルが起動することを確認します。
終了時はNotebookの保存を確認してからトンネルを閉じ、再接続後に必要なファイルが残っているか確認します。

SSH接続そのものが失敗する場合、JupyterLabの設定を繰り返し変えても解決しません。SSHの接続先や認証、機関ネットワークの制限を確認します。SSHは接続できるのにブラウザーが開かない場合は、ローカル側と遠隔側で転送ポートが一致しているかを調べてください。

注意： Jupyter Serverのトークンを含むURLは認証情報です。公開ログ、共有文書、誰でも閲覧できるチャットに貼り付けないでください。

認証エラーと繰り返すリダイレクト

Jupyter Serverの公式セキュリティ文書では、トークン認証が既定で使われることと、公開時のリスクが説明されています。(認証とセキュリティの公式説明) トークンが違う、サーバー再起動後に古いURLを使っている、パスワード認証を設定している、ブラウザーに古いセッション情報が残っている、といった原因を分けて確認してください。

トンネルは接続できるのに認証に失敗するときは、何を見直しますか。

遠隔Macの jupyter server list を再実行し、現在の接続URLと認証方式をサーバー側で確かめます。過去にコピーしたURLを使っている場合は、現在の出力と比較します。パスワードを設定した環境では、トークン入力を繰り返すのではなく、そのサーバーに設定された認証方法を確認してください。ブラウザーに古いセッションが残っている可能性もあるため、別のプライベートウィンドウで再現するかを試します。

認証を無効にして通過する方法は採用しません。修正後は、正しい利用者だけが認証を通過できることを再確認してください。Jupyter Server公式の公開サーバー運用文書も、公開方法と安全性の確認に使えます。

接続後のポート、プロキシ、HTTPS

接続が確立しても画面が正常に動かない場合は、SSH転送、リバースプロキシのパス、HTTPSの設定を切り分けます。アドレスのパスを変更している構成では、プロキシ側とJupyter Server側の設定が一致しないと、画面の一部が読み込めないことがあります。ログのエラーと実際のアクセス先を照合し、ネットワーク構成に合わないポート開放を一律に試さないでください。

HTTPSを使う場合は、ブラウザーが開いているプロトコルとサーバー側のTLS設定、証明書が一致しているかを確認します。Jupyter Serverの設定項目は公式設定リファレンスを参照し、大学のファイアウォールやプロキシが関係する場合は、許可された接続経路をネットワーク管理者に確認してください。原因が特定できず、設定変更が機関ネットワークに影響する可能性がある場合は、独断で公開範囲を広げずに作業を止めます。

単独サーバーと研究室共有の判断

個人用Jupyter Serverは、多人数向けの共有基盤と同じではありません。ひとつのプロセスや作業領域を複数人で共有すると、ファイルの上書き、カーネルの取り違え、認証情報の共有が起きる可能性があります。機密性のある研究データでは、遠隔接続できることだけで学内規定への適合が証明されるわけではありません。データの保存先や外部アクセスの扱いを、所属機関のルールと照らし合わせます。

研究室の複数人で、同じJupyterLabを使ってもよいですか。

各自のアカウント、作業領域、カーネルを分離できないなら、個人用サーバーを共有する方法は避けます。利用者ごとに環境を提供する必要がある場合は、JupyterHubなどの多人数向け構成、または大学が認めた共有環境を検討してください。JupyterHubの単独ユーザーサーバーの説明とセキュリティ設計文書は、個人用サーバーとの役割の違いを確認する資料になります。

接続方式を決めるチェックリスト

以下を上から確認し、該当する条件に沿って接続方法を決めます。公開範囲を広げる設定は、単に接続が簡単になるという理由で選ばないでください。

[ ] 利用者が1人で、SSH接続が許可され、研究データの扱いも学内規則に合う場合：Jupyter Serverをlocalhostで待ち受けさせ、SSHトンネルを使います。
[ ] 利用者が複数で、各自の認証・作業領域・カーネルが必要な場合：個人用サーバーを共有せず、JupyterHubまたは大学が認めた多人数向け基盤を選びます。
[ ] SSH接続が許可されていない場合：ポートを直接公開せず、大学が承認する接続経路をネットワーク管理者に確認します。
[ ] データの保存先や外部接続の可否が不明な場合：実データを置かず、研究室の責任者または情報管理担当に確認します。
[ ] ページは開くがカーネルが起動しない場合：接続設定の変更を止め、カーネルとサーバーログを別に調べます。

必要な分離や機関承認を満たせない場合は、接続設定を追加で緩めず、利用を保留して適切な共有環境へ切り替えます。

最小ノートブックでの再確認

設定を直した後は、短いノートブックで接続から保存までを一続きで確かめます。画面表示だけを成功基準にすると、認証やカーネル、保存の問題を見落とします。新規ノートブックを開き、簡単な計算を実行して結果を保存し、ページを再読み込みして保存内容が残るか確認してください。

確認項目は、ページ表示、認証の維持、カーネル起動、ノートブック保存、トンネル切断後の再接続です。再接続後にサーバーが停止していた場合は、起動方式やセッション管理を確認します。長時間の処理や機密データを扱う前に、実際の研究作業に近い小さな課題で、アクセス経路と保存先を記録しておくと、失敗時にどの層から調べるか判断できます。

実験室のWindowsやLinuxだけではmacOS上の挙動を確認できず、ローカルMacの購入には初期費用や管理負担が伴います。一方、SSH接続の制約や学内のデータ規則は、Macを用意するだけでは解消しません。macOS上での動作確認が必要で、手元にMacがない場合は、SFTPMACのリモートMac環境やレンタル料金の案内を確認し、まず最小ノートブックで接続・認証・保存を検証してから研究環境に組み込むか判断してください。