社内ネットワークでスプレッドシートが開けない｜プロキシ

自宅のパソコンでは普通に開けるスプレッドシートが、会社のパソコンだけ真っ白なまま止まる。読み込みの輪が回り続ける、あるいは「エラーが発生しました」で止まる。この症状は、スプレッドシート側の不具合ではなく、社内ネットワーク（ファイアウォール・プロキシ・復号検査）の設定で説明がつくことが多いです。

ただし、社員の立場で直せる範囲はほとんどありません。だからこそ、ここでやるべきことは「自分で直す」ではなく「どこまでが自分の環境の問題でないかを証明して、情報システム部門に渡す」です。この記事は、その切り分け手順と、そのまま貼って送れる依頼文を作るためのものです。

結論：自宅で開けて会社だけ開けないなら、原因は3系統に絞れる

切り分けの出発点は「別のネットワークにつないだら開けるか」の一点です。Google ドライブ ヘルプも、読み込みが遅い・接続エラーが出る場合の最初の手順として「別のネットワークに接続し、ファイルを正しく読み込めるかどうか確認してください。」と書いています（Google ドライブに関する一般的な問題を解決する）。スマートフォンのテザリングにつなぎ替えて開けるなら、端末ではなく社内ネットワークが原因です。

そこから先の原因は、大きく次の3系統しかありません。①ネットワーク側（ファイアウォール・プロキシ・SSL インスペクション）、②ブラウザとアカウント側（拡張機能・キャッシュ・管理者によるサービスのオフ）、③端末側（日付と時刻のずれによる証明書エラー）です。①は情報システム部門しか直せず、②③は自分で確かめられます。

①が本当に疑われる根拠は公式にあります。Google Workspace 管理者向けのヘルプは「組織でファイアウォールを使用している場合は、組織内のユーザーが Google サービスを使用できるようにファイアウォールを設定してください。」「設定されていない場合、サービスへのアクセスがブロックされる可能性や、一部の機能を使用できない可能性があります。」と明記しています（ファイアウォールとプロキシの設定）。つまり「許可設定の漏れでブロックされる」は想定された挙動です。

まず3分でやる切り分け（この4つだけ）

順番に意味があります。①で社内ネットワークかどうかが分かり、②③で自分のブラウザ環境かどうかが分かり、④で Google 側の障害かどうかが分かります。4つ全部やっても3分で終わります。

②③の根拠も公式です。編集中のエラーのトラブルシューティングとして「Google アカウントにログインしてファイルを開くには、シークレット ブラウジングを使用します。」「エディタの動作の妨げになっている拡張機能を特定するために、1 つずつ拡張機能を無効にしてください。」「普段ご使用のブラウザでエラー メッセージが頻繁に表示される場合は、別のブラウザをお試しください。」と案内されています（Google ドキュメント、スプレッドシート、スライド、Vids、Pics の編集中に発生するエラーのトラブルシューティング）。

④のステータス確認は URL を間違えないでください。正しいのは https://www.google.com/appsstatus/dashboard/ です。ヘルプは「ドライブや Google サーバーのサービス停止が報告されている場合は、Google Workspace ステータス ダッシュボードで該当するサービス名の横に赤色の丸が表示されます。赤色の丸をクリックすると、問題の詳細が表示されます。」と説明しています。過去の障害を見たいときは、ダッシュボード下部の［履歴を表示］から過去365日分を辿れます（Google Workspace サービスのステータスを確認する）。

症状×原因×見るところの早見表

「開けない」と一口に言っても、どこで止まるかで疑う先が変わります。自分の症状に近い行を探してください。

エラーコードの意味は Chrome ヘルプの定義をそのまま引いています。「ERR_NAME_NOT_RESOLVED: ホスト名（ウェブアドレス）が存在しないか、IP アドレスが変更されています。」「ERR_CONNECTION_TIMED_OUT または ERR_TIMED_OUT: ページへの接続に時間がかかりすぎたため、タイムアウトになりました。」「ERR_CONNECTION_REFUSED: Chrome による接続がページで許可されなかったか、ページがブロックされました。」（Chrome の一般的なエラー メッセージに関するヘルプ）。自分が見ているコードを正確に伝えるだけで、情シス側の調査は一段速くなります。コードの一覧はアドレスバーに chrome://network-errors/ と入力すると出ます。

原因1：ネットワーク側で止められている

ここが本命です。そして、ここは自分では直せません。直せないものを調べ続けるより、何を許可してほしいのかを正確に書いて渡すほうが早く終わります。

許可が必要なホストとポート（公式の一覧から）

Google Workspace 管理者ヘルプの「ファイアウォールとプロキシの設定」には、ドライブと Google サイト向けに許可すべきホストが列挙されています。スプレッドシートに関係するものを原文の表記のまま挙げます。

• www.google.com:443/HTTPS、accounts.google.com:443/HTTPS
• drive.google.com:443/HTTPS、*.drive.google.com:443/HTTPS、googledrive.com:443/HTTPS
• docs.google.com:443/HTTPS、*.docs.google.com:443/HTTPS、*.c.docs.google.com:443/HTTPS
• sheets.google.com:443/HTTPS、slides.google.com:443/HTTPS
• script.google.com:443/HTTPS、apis.google.com:443/HTTPS
• *.googleapis.com:443/HTTPS、*.googleusercontent.com:443/HTTPS、*.gstatic.com:443/HTTPS、*.gvt1.com:443/HTTPS
• *.clients[0～9].google.com:443/HTTPS、clients[0～9].google.com:443/HTTPS、lh[0～9].google.com:443/HTTPS、[0～9].client-channel.google.com:443/HTTPS
• drive.usercontent.google.com:443/HTTPS、drive-data-export.usercontent.google.com、drive-data-export-eu.usercontent.google.com
• takeout.google.com:443/HTTPS、gg.google.com:443/HTTPS、inputtools.google.com:443/HTTPS、video.google.com:443/HTTPS、s.ytimg.com:443/HTTPS、ssl.google-analytics.com:443/HTTPS
• sites.google.com:443/HTTPS、sites.google.com:80/HTTP、*.sites.google.com:443/HTTPS、*.googlegroups.com:443/HTTPS
• ipv4.google.com:443/HTTPS、ipv4.google.com:80/HTTP

角かっこ付きのホストには注意書きがあります。「ホストに [0–9] が含まれる場合、ホストに 1 桁の 10 進数を 1 つずつ許可する必要があります。」つまり *.clients0.google.com から *.clients9.google.com まで個別に許可する、という意味です。ここを「*.clients[0-9]」のまま機器に入れると効かないことがあります（ファイアウォールとプロキシの設定）。

もうひとつ見落とされがちなのが、管理コンソール側でサービスを切っていても許可は必要だという一文です。「これらのホストとルートは、Google 管理コンソールで対応するサービスを無効にしている場合でも、許可されていなければなりません。」と書かれています。「うちはサイトを使っていないから sites.google.com は不要」という整理は、公式の指示とは異なります。

ポートについては、別の管理者ヘルプが用途まで明記しています。TCP ポート 443（HTTPS）は「認証と API 呼び出しのためのメイン URL へのアクセス」、TCP ポート 80（HTTP）は「CRL チェックと OCSP チェックの許可」です。証明書失効の確認に使う crl.pki.goog / c.pki.goog / ocsp.pki.goog は HTTP で引かれるため、443 だけ開けて 80 を塞ぐ構成だと証明書の確認が通らないことがあります（Google Workspace のホスト名の許可リストを設定する）。

なお、WebSocket や QUIC（HTTP/3）をどう扱うべきかは、上記のドライブ／ホスト名許可リストのページには記載がありません。公式に書かれていない仕様なので、この記事では断定しません。許可リストに載っているのは HTTPS（443）と HTTP（80）です。

SSL インスペクション（復号検査）が挟まっている

社内で HTTPS を復号して中身を検査している場合、スプレッドシートは「開けない」だけでなく「証明書エラーで止まる」形で失敗します。Chrome ヘルプは、この状況をかなり具体的に書いています。

プロキシが設定された職場のパソコンで、HTTPS インターセプトを行うプロキシ（ZScaler、Palo Alto Networks、Fortinet など）を経由する際に「NET::ERR_CERT_AUTHORITY_INVALID」エラーが表示される場合は、このエラーは通常、プロキシ サーバーからの必要な証明書が不足しているか、システムにインストールされていないことを意味します。この問題を解決するには、管理者にお問い合わせください。

同じ箇所に「証明書をご自身でインストールすることは、通常はセキュリティ上のリスクがあるためおすすめしません。」とも書かれています。ここは自力で何とかしてよい場所ではない、と公式が線を引いているわけです（Chrome の一般的なエラー メッセージに関するヘルプ）。

構成そのものの制約も公式に記載があります。ChromeOS デバイス向けの案内ですが、「透過型（インライン）プロキシはサポートされていませんが、ご利用になる場合は、google.com へのすべてのリクエストを TLS インスペクションなしで通過させるために、*.google.com を許可リストに登録します。ただし、この設定はサポートされていません。」とあり、さらに「Server Name Indication（SNI）は現在サポートされていません」「TLS インスペクションが有効になっている場合、ユーザーはマルチログイン アクセスを利用できません」と並んでいます（ChromeOS デバイスでの TLS（SSL）インスペクションについて）。Windows や macOS のブラウザ全般について同じ記述があるわけではないので、そこは混同しないでください。

パソコン版ドライブ（デスクトップアプリ）を併用している環境では、もう3行ぶん効いてきます。公式には「復号プロキシを使用する場合は、パソコン版ドライブ用に TrustedRootCertsFile 設定を構成してください。」「バッファリングされたプロキシを使用する場合は、ホスト fcmconnection.googleapis.com のプロキシでバッファリングを無効にする必要があります。」「パソコン版ドライブでは、パスワードを使用した認証プロキシはサポートされていません。」と書かれています。プロキシ認証を必須にしている社内環境でパソコン版ドライブが同期しないのは、設定ミスではなく仕様です。

情報システム部門にそのまま渡せる確認依頼の雛形

ここがこの記事の本題です。「開けません」だけの連絡だと、情シス側は再現も原因究明もできません。以下は、公式に根拠のある項目だけを並べた依頼文です。角かっこを自分の状況に置き換えて、そのまま送れます。

件名：Google スプレッドシートが社内ネットワークから開けない（ネットワーク設定のご確認のお願い）

お世話になっております。［部署・氏名］です。Google スプレッドシートが社内のパソコンからのみ開けない状態です。切り分け結果と、ご確認いただきたい点をまとめました。

【切り分け済みの事実】
・スマートフォンのテザリングに切り替えると同じURLが開けます（社内ネットワーク経由のみ失敗）
・シークレット ウィンドウでも同じ症状です（ブラウザ拡張機能は無関係）
・別のブラウザ（［Chrome／Edge など］）でも同じ症状です
・Google Workspace Status Dashboard（https://www.google.com/appsstatus/dashboard/）はドライブ／ドキュメントとも正常表示です
・表示されるエラー文／コード：［例：NET::ERR_CERT_AUTHORITY_INVALID］
・発生端末／OS／ブラウザのバージョン：［　］、発生開始日時：［　］

【ご確認いただきたいこと】
1. ファイアウォール／プロキシで、Google Workspace 管理者ヘルプ「ファイアウォールとプロキシの設定」のドライブと Google サイト向けホストが許可されているか。とくに docs.google.com、*.docs.google.com、*.c.docs.google.com、sheets.google.com、drive.google.com、*.drive.google.com、*.googleapis.com、*.googleusercontent.com、*.gstatic.com、clients[0～9].google.com、[0～9].client-channel.google.com、drive.usercontent.google.com
2. 上記のうち [0～9] を含むホストが、0〜9 を1つずつ展開して登録されているか（ワイルドカードのままでは効かないと公式に注記があります）
3. ポートは TCP 443（HTTPS）のほか、TCP 80（HTTP）が CRL／OCSP チェック用に開いているか。あわせて crl.pki.goog、c.pki.goog、ocsp.pki.goog への到達可否
4. SSL インスペクション（HTTPS 復号検査）を実施している場合、検査用ルート証明書が当該端末に配布済みか。配布が難しい場合、Google のドメインを検査除外にできるか
5. プロキシ認証（ID・パスワード）を必須にしているか。パソコン版ドライブはパスワードによる認証プロキシに対応していないため、併用している場合は除外設定が必要か
6. 管理コンソールの［アプリ］→［Google Workspace］→［サービスのステータス］で、私の所属する組織部門／グループに対してドライブとドキュメントがオンになっているか
7. 同じ時刻のプロキシ／ファイアウォールのブロックログに、上記ホスト宛の拒否が残っていないか

お手数をおかけしますが、ご確認のほどよろしくお願いいたします。

補足として、Google は端末側のブラウザ情報をまとめて出せる Google 管理者ツールボックスの Browser info を公開しています。ブラウザやネットワークの情報を自分で書き写すより、この画面を見せたほうが正確です。

ネットワークが直るまでの間、同じ表を手作業で回し続けるのはしんどいものです。社内からしか触らない集計表なら、スプレッドシートに依存しない入力画面に置き換えたほうが、許可リストの交渉より早く安定することもあります。記事の途中で恐縮ですが、Mihata ではそうした作り替えもしています。

原因2・3：ネットワーク以外で止まっているとき

テザリングでも開けなかった場合は、こちらを順に見ます。どれも公式ヘルプに手順があるものだけに絞りました。

拡張機能・キャッシュ・ウイルス対策ソフト

拡張機能はシークレット ウィンドウで切り分け、そのうえで1つずつ無効にして特定します。閲覧データの削除も公式手順にあり、「閲覧データ、Cookie、キャッシュされたファイルを消去してください。」「閲覧データを削除した後、アカウントに再度ログインする必要があります。」と案内されています。ウイルス対策ソフトも無関係ではなく、「ローカル システムのウイルス スキャン ソフトウェアや広告ブロック機能は、Google ドキュメント、スプレッドシート、スライドなどのドライブ ファイルの動作に影響を与えることがあります。」と書かれています。とくに「HTTPS 保護」「HTTPS スキャン」といった機能を持つ製品は、証明書エラーの原因として Chrome ヘルプに名指しで挙げられています。

なお、エラーが出てから何もせず5分待つだけで解決する場合もあります。公式に「5 分待ってからページをもう一度読み込んでください。」という手順がある程度には、一時的な事象も多いということです。

管理者がサービスをオフにしている（アカウント側の組織ポリシー）

同じ社内でも「開ける人と開けない人がいる」なら、ネットワークより先にこちらを疑います。管理者はユーザー単位でサービスを切り替えられ、「該当するアカウントにログインしたユーザーには、自分に対して有効になっているサービスのみが表示されます。」という挙動になります。設定場所は管理コンソールの［アプリ］→［Google Workspace］→［サービスのステータス］で、「変更が反映されるまでに最長で 24 時間ほどかかることがありますが、通常はこれより短い時間で完了します。」とされています（Google Workspace ユーザー向けにサービスを有効または無効にする）。直したその日に反映されないことがある、という点は依頼時に覚えておくと揉めません。

似ているけれど別物なのが、ファイルそのものの共有設定で弾かれているケースです。会社のアカウントでは権限がなく個人アカウントでは開ける、という形で「ネットワークのせい」に見えることがあります。画面に権限の文言が出ているなら、スプレッドシートで「アクセス権が必要です」と出るときの直し方のほうが近道です。

端末の日付と時刻がずれている（証明書エラー）

見落としがちな第3の系統です。Chrome ヘルプは「「時計が遅れています」、「時計が進んでいます」、「NET::ERR_CERT_DATE_INVALID」」について「このエラーは、パソコンまたはモバイル デバイスの日付と時刻が正確でない場合に表示されます。」「エラーを解決するには、デバイスの時計を開き、日付と時刻を正しく設定します。」と書いています。社内ネットワークで時刻同期（NTP）が塞がれていると、電源を入れた直後だけ時刻がずれて HTTPS が全滅する、という形で現れます。

似て非なる症状との違い

「開けない」と「開くけれどおかしい」は原因がまったく別です。ここを間違えると、情シスに関係ない依頼を出して時間を失います。

まず、開くけれど保存が通らない場合。Google が公式に文言を載せているメッセージは「変更内容を保存できません。最近の編集内容をコピーしてから変更を元に戻してください」で、原因は「サーバーでの変更の保存に時間がかかりすぎたこと」と説明されています。対処も具体的で、「保存されなかった変更をすべてコピーします。」「シートを再読み込みします。」「変更内容を貼り付けます。」「このエラーが再び表示された場合は、インターネット接続を一旦切断し、もう一度接続してください。」という順です（変更内容を保存できません のトラブルシューティング）。ちなみに「接続が不安定です」という文言そのものは、確認した Google ヘルプの該当ページには見つかりませんでした。公式に記載があるのは上記の保存エラーと、「エラーが発生しました。このページを再読み込みするか、数分後このページをもう一度開いてみてください。」「サーバーエラーが発生しました。ブラウザの [再読み込み] を押してください。」です。保存系の症状に心当たりがあるなら、スプレッドシートで「接続が不安定です」と出て保存できないときの対処にまとめています。

次に、開くけれど極端に遅い場合。これはネットワークではなく、シートの作りが原因のことが多いです。行数・数式・条件付き書式・画像の量で重くなっていくタイプの症状なので、スプレッドシートが重い・開かないときに軽くする手順のほうが当たります。公式にも、サイズが大きすぎると読み込まれないことがある旨の注意と、大きいデータは貼り付けではなく IMPORTRANGE などの IMPORT 関数で取り込む推奨が書かれています。

最後に、オフライン機能まわりの固有エラー。「別のユーザーがすでにこのパソコンでオフライン アクセスを有効にしています。」のように、ブラウザ プロフィールとアカウントの組み合わせが原因のものがあります。タブやアカウントが絡むエラーが出ているなら、スプレッドシートのオフライン・別のタブのエラーの読み解き方を先に見てください。

開けない間にできること（そして、できないこと）

最初に正直に書きます。オフライン編集は、開けなくなってから設定できません。公式の「オフライン アクセスを有効にする前に」の条件に「インターネットに接続する必要があります。」と明記されているためです。ほかにも、Google Chrome または Microsoft Edge を使う、シークレット ブラウジングは使わない、「Google オフライン ドキュメントの Chrome 拡張機能」をインストールして有効にする、デバイスに十分な空き容量がある、という条件が並んでいます（オフライン時に Google ドキュメント、スプレッドシート、スライドで作業する）。

手順自体は簡単です。Google ドライブを開き、右上の設定アイコン →［設定］→［オフライン］を有効にします。特定のファイルを確実に持たせるには、ホーム画面でそのファイルの「その他アイコン」→［オフラインで使用できるようにする］をオン、またはファイルを開いて［ファイル］→［オフラインで使用可能にする］です。社内ネットワークが不安定な会社では、開ける今のうちによく使う数本をオフライン対象にしておく、これが唯一効く備えです。

ただし、ここにも組織ポリシーの壁があります。「オフライン同期は管理者によって無効にされています。」というメッセージが出る場合、「このアカウントではオフライン機能を使用できません。」とされており、自分では解除できません。この一行も、先ほどの依頼文に足しておくと話が早いです。

今まさに開けない状況での現実的な手は、次のどれかに限られます。①テザリングなど別回線で開いて必要なぶんだけ取り出す、②編集権限を別のアカウントと共有してそちらで作業する、③ドライブ上でファイルのコピーを作成する、④ダウンロードしてローカルで作業する。②〜④はいずれも公式のトラブルシューティングに載っている手ですが、コピーやダウンロードは「変更履歴などの一部の機能が利用できなくなります」という注意が付きます。戻すときの手間を含めて選んでください。

再発防止：会社として一度やっておくこと

同じ騒ぎを毎回やらないために、効果が大きい順に3つだけ挙げます。どれも1回やれば効きます。

1つめは、情報システム部門が許可リストを「サービス単位」ではなく公式の一覧に合わせて整備することです。前述のとおり、使っていないサービスのホストも許可が必要だと公式に明記されています。機器を入れ替えたときに一覧ごと移し替える運用にしておくのが安全です。

2つめは、障害アラートの受け取り口を作っておくことです。ステータス ダッシュボードには RSS フィードと JSON の履歴があり、管理者は管理コンソールの［ルール］からシステム定義ルール「アプリケーションの停止警告」を設定して、アラート センターやメールで通知を受け取れます。公式には「これらのアラートは、RSS フィードの更新より遅れて届く場合があります。」という注意付きで、RSS の購読が推奨されています。「Google が落ちているのか自社なのか」を毎回人力で調べる必要がなくなります。

3つめは、よく使うシートのオフライン対象化を、新入社員の初期設定に入れてしまうことです。前述のとおり事前にしかできない設定なので、本人が困ったときに案内しても間に合いません。

そのうえで、ひとつ正直に書いておきます。ネットワーク制限が厳しい会社では、許可リストの調整そのものが社内調整として重く、数週間かかることもあります。業務が止まっている期間が長引くなら、その表を外部サービス前提のまま使い続けるか、社内に閉じた仕組みへ寄せるかという判断を、技術の話とは別に一度したほうがいいと考えています。

まとめ

「自宅では開けるのに会社だけ開けない」は、スプレッドシートの問題ではなく社内ネットワークの問題である可能性が高いです。テザリング・シークレット・別ブラウザ・ステータス ダッシュボードの4点で3分で切り分け、エラーコードを添えて情報システム部門に渡すのが最短ルートです。

渡すときは、許可が必要なホストと TCP 443／80 の用途、SSL インスペクションの証明書配布、プロキシ認証の有無、管理コンソールのサービスのステータスという5点に絞ると、調査がぶれません。自分で証明書を入れるのは公式に非推奨とされているので、やらないでください。

そして、開けるうちにオフライン対象を数本仕込んでおくこと。これだけが、次に止まったときに自分を助けてくれます。