Chromeは100%なのにGoogleスプレッドシートだけ巨大化する──Preferencesの「ゴーストズーム」をコマンドで直す【macOS】

1. 結論：これは「Sheetsのズーム」ではなく、Chromeプロファイルに残ったサイト別ズームだった

macOS版Google Chromeで、特定のプロファイルを使ったときだけGoogleスプレッドシート、Googleドキュメント、GoogleスライドなどのUI全体が異常に大きくなることがある。Chromeのメニューは100%、Sheets内のズームも100%。ほかのWebサイトは正常なのに、90%へ下げるとGoogle Docs系だけちょうどよく見える——この組み合わせなら、Chromeプロファイルの Preferences に残った docs.google.com 固有のズーム値を疑う価値がある。

今回の実例では、次のエントリが残っていた。

{
  "partition": {
    "per_host_zoom_levels": {
      "x": {
        "docs.google.com": {
          "zoom_level": 1.2239010857415449
        }
      }
    }
  }
}

この数値は「122.39%」ではない。Chromiumは内部ズームレベル L を 1.2^L で表示倍率へ変換するため、1.2^1.2239010857415449 = 1.25、つまりちょうど125%である。Chromiumの現行ソースにも、ズーム倍率のプリセットとして125%があり、変換式がそのまま実装されている。^[9]

最終的な解決は、Chromeが問題プロファイルを使っていない状態で Preferences をバックアップし、partition.per_host_zoom_levels 配下にある docs.google.com の項目だけを削除することだった。Cookie、閲覧履歴、ブックマーク、保存パスワードを消す必要はない。

図1：同じMac・同じサイトでも、Chromeプロファイルごとのサイト別ズーム状態によって表示倍率が変わる。右のようにツールバーとグリッドの両方が大きいなら、Sheets内ズームだけの問題ではない。

この事象に当てはまりやすいチェックリスト

この記事は、通常のリセットが効かない場合に限って使う第2段階の修復手順である。まず第2章の読み取り専用診断を行い、該当エントリが確認できたときだけ第4章の削除へ進んでほしい。

2. 診断：三つの「100%」を分け、devicePixelRatioと保存値を確認する

Google系エディタでは「ズーム」が一つではない。ここを混同すると、100%へ戻したのに直らない理由が見えなくなる。

Googleの公式ヘルプも、ChromeのページズームとDocs/Sheets内の表示倍率を別の設定として案内している。Docs/Sheets側は50〜200%の値を持ち、Chrome側にはサイト固有のページズームがある。^[1][2]

2-1. DevToolsで devicePixelRatio を比較する

問題のGoogle Sheetsを開き、macOSでは Option+Command+I（または環境によりF12）でDevToolsを開き、Consoleタブで次を実行する。

console.log('devicePixelRatio:', window.devicePixelRatio)

初回だけ貼り付けが拒否された場合は、警告文を読み、内容を理解したうえで allow pasting を自分でタイプする。Chrome DevToolsの公式説明では、これは悪意あるコードを貼らせるSelf-XSS対策であり、出所不明のコードを実行してはいけない。^[3] 上の1行は値を表示するだけで、データ送信や設定変更はしない。

次に、同じMac、同じディスプレイ、同じ表示設定のまま、正常なChromeプロファイルでも同じコマンドを実行する。

重要なのは絶対値ではなく、問題側 ÷ 正常側が約1.25になるかである。devicePixelRatio は物理ピクセルとCSSピクセルの比で、ページズームを上げると値も上がる。一方、通常のピンチズームは devicePixelRatio を変えないとMDNは説明している。^[4] 外部ディスプレイへウィンドウを移しただけでも基準値が変わるため、比較条件をそろえる必要がある。

2-2. Preferences を変更せずにゴーストエントリを探す

まず、問題のChromeプロファイルで chrome://version を開き、「プロフィール パス（Profile Path）」を確認する。Chromium公式文書も、この欄をプロファイルディレクトリの確定方法として案内している。macOS版Chrome Stableの標準ルートは ~/Library/Application Support/Google/Chrome で、その下に Default、Profile 1、Profile 2 などがある。^[5]

下の1行だけ、自分の表示に合わせて変更する。Finder上のプロファイル表示名ではなく、chrome://version に出た実フォルダ名を使う。

CHROME_PROFILE_DIR="$HOME/Library/Application Support/Google/Chrome/Profile 1"

続けて、読み取り専用の診断を実行する。

python3 - "$CHROME_PROFILE_DIR/Preferences" <<'PY'
import json, sys
from pathlib import Path

path = Path(sys.argv[1]).expanduser()
with path.open(encoding="utf-8") as f:
    data = json.load(f)

per_host = data.get("partition", {}).get("per_host_zoom_levels", {})
found = False

for partition_key, hosts in per_host.items():
    if not isinstance(hosts, dict) or "docs.google.com" not in hosts:
        continue
    entry = hosts["docs.google.com"]
    level = entry.get("zoom_level") if isinstance(entry, dict) else entry
    factor = 1.2 ** float(level)
    print(f"FOUND partition={partition_key!r}")
    print(f"zoom_level={level}")
    print(f"zoom_factor={factor:.6f} ({factor * 100:.0f}%)")
    found = True

if not found:
    print("No docs.google.com zoom entry found; do not run the repair yet.")
PY

次のように出れば、今回の事象と一致する。

FOUND partition='x'
zoom_level=1.2239010857415449
zoom_factor=1.250000 (125%)

何も見つからない場合は、この修復を実行しない。拡張機能、Chromeポリシー、macOSのアクセシビリティ拡大、ディスプレイ設定、別ホストのズーム値を調べるべきである。

3. 原因：ChromeのHostZoomMapへ復元される「ゴーストエントリ」

Chromiumは、ホスト名ごとのズーム値を partition.per_host_zoom_levels という辞書に保存する。現行の pref_names.h には「ホスト名をズームレベルへ対応付ける辞書」と明記され、標準値と同じホストは保存対象から外れる設計になっている。^[6]

起動時にはChromeの ChromeZoomLevelPrefs がこの辞書を読み、ストレージパーティションごとの HostZoomMap へ値を復元する。通常プロファイル直下のパーティションキーが x になる理由もソース上で確認できる。変更時には、標準ズームと異なる値だけが再びPreferencesへ書かれる。^[7][8]

図2：Google DocsがローカルのPreferencesを直接読むわけではない。Chromeが保存値をHostZoomMapへ復元し、その結果がページズームとdevicePixelRatioを含む描画環境へ現れる。

今回の観測を、確認済みの事実と推定に分けるとこうなる。

なぜGoogle Sheets/Docsだけが派手に壊れて見えるのか

第一の理由は単純で、保存されたキーが docs.google.com だからである。ほかのドメインにはこのhost-specific zoomが掛からない。Google Sheets、Docs、Slidesの編集画面は同じ docs.google.com 配下を広く使うため、複数サービスにまとめて波及する。

第二に、Chromeのページズームは、Sheets内の「100%」より外側でページ全体へ作用する。Sheets側を100%にしても、外側で125%が掛かればツールバー、数式バー、行列見出し、セルまで大きくなる。GoogleはDocsの文書描画をHTMLベースからcanvasベースへ移行したと公式発表している。canvasは鮮明さを保つために devicePixelRatio を使うのが一般的であり、MDNもその実装例を示している。^[10][4] ただし、Google Sheets/Docsの非公開実装が今回どの変数をどう使ったかまでは公開情報から断定できない。

つまり、正確な説明は「Google DocsがPreferencesファイルを読む」ではなく、Chromeの残存ズーム値がページの描画倍率を変え、複雑なエディタUIで異常が目立ったとなる。

4. 解決手順：バックアップして docs.google.com だけを安全に削除する

ここからはファイルを書き換える。診断で対象が見つかった場合だけ進む。スクリプトは次の安全策を入れている。

• 元の Preferences を日時付きでバックアップする
• docs.google.com 以外の設定を削除しない
• x と決め打ちせず、すべてのパーティションを確認する
• 一時ファイルへJSONを書き、検証後に同じ場所で置き換える
• 対象がなければ書き換えず終了する

図3：修復対象はPreferences全体ではなく、サイト別ズーム辞書のdocs.google.comエントリだけ。先にバックアップを作り、問題があれば戻せるようにする。

手順1：プロファイルパスを確定する

chrome://version の「プロフィール パス」から、問題プロファイルのディレクトリをコピーする。例：

CHROME_PROFILE_DIR="$HOME/Library/Application Support/Google/Chrome/Profile 1"

Default なら末尾を Default に変える。Chrome Beta、Dev、Canaryは親ディレクトリ名も異なるので、推測せず chrome://version の実値を使う。

手順2：Chromeを終了する

少なくとも問題プロファイルのウィンドウをすべて閉じる。バックグラウンドアプリや共有ブラウザプロセスによる再書き込みを避けるには、最も安全なのはCommand+QでChrome全体を終了することである。念のため次を実行し、何も表示されないことを確認する。

pgrep -x "Google Chrome" || echo "Google Chrome is not running"

Chrome起動中に編集すると、メモリ上の古い設定でファイルが再保存され、削除した項目が復活する可能性がある。

手順3：バックアップ付き修復スクリプトを実行する

先ほど設定した CHROME_PROFILE_DIR が同じTerminalセッションに残っている状態で、次をそのまま実行する。

python3 - "$CHROME_PROFILE_DIR/Preferences" <<'PY'
import json, os, shutil, sys, tempfile
from datetime import datetime
from pathlib import Path

path = Path(sys.argv[1]).expanduser()
if not path.is_file():
    raise SystemExit(f"Preferences not found: {path}")

with path.open(encoding="utf-8") as f:
    data = json.load(f)

per_host = data.get("partition", {}).get("per_host_zoom_levels", {})
removed = []

for partition_key, hosts in per_host.items():
    if isinstance(hosts, dict) and "docs.google.com" in hosts:
        removed.append((partition_key, hosts.pop("docs.google.com")))

if not removed:
    print("No docs.google.com zoom entry found. Nothing changed.")
    raise SystemExit(0)

stamp = datetime.now().strftime("%Y%m%d-%H%M%S")
backup = path.with_name(f"Preferences.backup-{stamp}")
shutil.copy2(path, backup)

fd, temp_name = tempfile.mkstemp(prefix="Preferences.", suffix=".tmp", dir=path.parent)
try:
    with os.fdopen(fd, "w", encoding="utf-8") as f:
        json.dump(data, f, ensure_ascii=False, separators=(",", ":"))
        f.flush()
        os.fsync(f.fileno())
    shutil.copymode(path, temp_name)
    with open(temp_name, encoding="utf-8") as f:
        json.load(f)
    os.replace(temp_name, path)
except Exception:
    if os.path.exists(temp_name):
        os.unlink(temp_name)
    raise

for partition_key, old_value in removed:
    print(f"Removed docs.google.com from partition {partition_key!r}: {old_value}")
print(f"Backup: {backup}")
print("Done. Start Chrome and verify Google Sheets at 100%.")
PY

手順4：再起動して二つの100%を確認する

Chromeを起動し、同じプロファイルでGoogle Sheetsを開く。

1. Chromeメニューのズームが100%
2. Sheets上部のズームが100%
3. window.devicePixelRatio が正常プロファイルと同じ
4. ツールバー、数式バー、行列見出し、セルが適正サイズ

ここまでそろえば修復完了である。

ロールバック方法

予期しない問題が出たらChromeを完全終了し、スクリプトが表示したバックアップパスを使って戻す。

cp "$CHROME_PROFILE_DIR/Preferences.backup-YYYYMMDD-HHMMSS"    "$CHROME_PROFILE_DIR/Preferences"

日時部分は実際のファイル名へ置き換える。候補は次で確認できる。

ls -lt "$CHROME_PROFILE_DIR"/Preferences.backup-* | head

5. なぜCmd+0、Cookie削除、ズーム設定削除では直らなかったのか

一般的なズーム不具合なら、Google Chrome公式が案内する Cmd+0 または設定画面の「ズームレベル」削除で直る。^[1] 今回直らなかったこと自体が、通常状態ではない手掛かりだった。

今回の「ゴーストエントリ」は、ChromeのUI層が認識する状態と、Preferencesに永続化された状態がずれたと考えると整合する。実際、ChromiumのコードではHostZoomMapの変更通知を受けてPreferencesを書き換え、標準ズームと等しければhostを削除する。^[7] どこかで削除通知、保存、プロファイル終了のいずれかが完了しなければ、ファイルだけに古い値が残る余地はある。

ただし、この記事の実測だけで「Chromeの特定バージョンに存在する再現済みバグ」とまでは言えない。UIから消えてファイルに残る現象が再現可能なら、Chromeのバージョン、macOSのバージョン、再現手順、修復前の該当JSONを添えてChromium Issue Trackerへ報告する価値がある。

削除しても再発するときの切り分け

1. chrome://policy で組織ポリシーが適用されていないか確認する。
2. すべての拡張機能を一時停止し、再発するか確認する。
3. 新規Chromeプロファイルで同じ docs.google.com を開く。
4. 同じディスプレイ上で devicePixelRatio を比較する。
5. macOSの「アクセシビリティ→ズーム」と「ディスプレイ」の設定を確認する。
6. 削除後のPreferencesへ同じhostがいつ戻るか、Chrome終了前後で読み取り専用スクリプトを再実行する。

新規プロファイルでも全サイトが大きいなら、今回のhost-specific zoomではなくOS表示倍率やChrome全体の既定ズームが本命である。逆に、特定プロファイルの docs.google.com だけなら、今回の条件にかなり近い。

6. Windows・ほかのGoogle Docs系サービス・再発防止

WindowsのPreferencesパス

Chromium公式文書によるChrome Stableのユーザーデータルートは、Windowsでは %LOCALAPPDATA%\Google\Chrome\User Data である。^[5] したがってPreferencesは通常、次のいずれかになる。

%LOCALAPPDATA%\Google\Chrome\User Data\Default\Preferences
%LOCALAPPDATA%\Google\Chrome\User Data\Profile 1\Preferences

ただし、今回の直接修復はmacOSで実地確認したものだ。WindowsでもJSON構造はChromium共通と考えられるが、本記事では未検証である。Windowsでも必ず chrome://version のProfile Pathを正とし、Chromeを完全終了し、Preferencesをコピーしてから同じPythonロジックを使ってほしい。企業管理PCでは編集前に管理者へ確認する。

Sheets以外にも影響する理由

問題のキーはサービス名ではなくhost名の docs.google.com である。次の編集画面は同じhostを使うため、一緒に影響する可能性が高い。

• Google Sheets
• Google Docs
• Google Slides
• Google Drawings
• Google Formsの一部画面

一方、Google DriveやGmailは別hostなので正常なことがある。この「Google製品全部ではなく、Docs系エディタ群だけ」という境界も診断材料になる。

再発防止

• Chromeのページズームを変える Cmd+Plus / Cmd+Minus と、Docs/Sheets内ズームを区別する。
• 意図せず大きくなった直後は、まず Cmd+0。直らなければ値を下げてごまかさず、正常プロファイルとDPRを比較する。
• 複数プロファイルを使う場合、chrome://version のProfile Pathをメモしておく。
• Preferencesを直接編集するときは、対象hostだけを削除し、必ずバックアップする。
• トラックパッドのピンチは通常のページズームと挙動が異なる。DPRを変える永続的な125%は、単発のピンチより Cmd+Plus などChromeページズーム操作との整合性が高いが、発生操作は今回確定していない。

最後に、最短の判断フローをまとめる。

このトラブルの厄介さは、画面に見える「100%」が診断の終点ではなかったことにある。UI表示、実際の描画倍率、ディスク上の保存値を別々に観測する。そこまで分ければ、再インストールやプロファイル全消去へ進む前に、一つのゴーストエントリだけを安全に取り除ける。

参考文献 / References