macOS 27 ベータでChromeやBraveがサイトを読み込めない問題を解決

macOSTahoe ·
macOS 27 ベータでChromeやBraveがサイトを読み込めない問題を解決

Safariは動くのにmacOS 27ベータでChromeがサイトを読み込めない場合の原因と、順を追って試せる修正手順をまとめました。

macOS 27「Golden Gate」パブリックベータをインストールし、Chromeを開いてURLを入力したのに……何も起きない。タブはくるくる回り続け、ステータスバーにはConnecting…と表示されたまま動きません。しばらくすると ERR_CONNECTION_TIMED_OUT、ERR_NAME_NOT_RESOLVED、あるいはBraveの陽気なThis site can't be reachedが出てきます。別のサイトを試しても同じ。どのサイトも同じ。そして半ば習慣的にSafariを開いてみると——一発で、瞬時に読み込まれます。インターネットは明らかに正常です。Wi-Fiも正常です。それでもmacOS 27ベータでChromeがサイトを読み込めない問題があなたの午後をまるごと奪い、しかもBrave、Edge、Arc、Vivaldiでも同じことが起きています。

もしこれがあなたの状況なら、まず落ち着いてください。あなたのMacは壊れていませんし、ネットワークも壊れていません。これは現行のmacOS 27ベータで広く報告されている粗さの一つで、Chromiumベースのブラウザは何も読み込めないのに、Safariはすんなり通るというパターンです。Braveコミュニティフォーラム、Apple Discussionsのスレッド、MacRumorsのベータ掲示板でも見られており、共通しているのは常に同じ点です——WebKitブラウザは動き、Chromium系は動かない。この違いこそ、何が起きているのかを知るための最大の手がかりであり、以下の修正のほとんどが素早く元に戻せる、何も破壊しない理由でもあります。

このガイドは2つのことを行います。第一に、ベータにふさわしい留保をつけながら、Safari以外のブラウザだけが壊れる理由を正直に説明します。第二に、多くの人に効く30秒のトグルから、誰も口にしたがらない正直なフォールバック——ベータなのだから、時にはSafariに頼るか、Appleが新しいビルドを出すまで安定版Tahoeに戻るのが正解だということ——まで、順番に試せる修正のはしごを提供します。それでは、ブラウザを取り戻しましょう。

要点まとめ

  • SafariだけがつながりChrome、Brave、Edge、Arc、Vivaldiがすべて失敗するのは、このベータ問題の典型的な特徴です。 これは特定のブラウザ単体の問題ではなく、現行のmacOS 27ベータが非WebKitアプリのネットワークトラフィックをどう扱うか——DNS、ネットワーク拡張機能、アプリ単位のネットワーク経路——に関わっていることを示しています。
  • これはベータテスターによる報告であり、Appleが公式に認めたバグではありません。 Braveコミュニティ、Apple Discussions、MacRumorsのスレッドで言及されていますが、Appleは正式な声明を出していません。挙動はベータビルドごとに変わり得るため、アップデートのたびに再確認してください。
  • 最も効果が高い修正は単純で元に戻せるものです。 ブラウザのセキュアDNS（DNS-over-HTTPS）をオフにする、ネットワークフィルターやVPNのシステム拡張機能（Little Snitch、LuLu、社内フィルター、一部のアンチウイルス）を無効化する、IPv6をリンクローカルのみに設定する、DNSキャッシュをフラッシュする、といった対応です。
  • iCloud プライベートリレーとVPNを早めに確認してください。 iCloud プライベートリレーと中途半端に接続されたVPNトンネルは、このベータ上でSafariとChromiumアプリに対して異なる振る舞いをする、よくある原因です。
  • 正直なフォールバックはSafariを使うか、ロールバックするかです。 ベータでは、Appleの対応を待つしかない問題もあります。動作するChromiumブラウザがどうしても必要な場合は、ビルドと格闘するより安定版Tahoeへの巻き戻しを検討する価値があります。

まず確認: 本当にmacOS 27ベータを使っていますか？

設定を変える前に、この記事が対象としているベータに実際に乗っているか確認しましょう。ここで紹介する修正はベータ特有の挙動を狙ったものなので、安定版で試すと時間の無駄になったり、むしろ逆効果になったりする可能性があります。

正確なバージョンを確認する

Appleメニュー > このMacについてを開き、バージョン行を確認します。次に詳しい情報 > ソフトウェア・アップデート（またはシステム設定 > 一般 > ソフトウェア・アップデート）をクリックして、ベータシードに乗っているかどうかを確認してください。

  • macOS 27.0 beta（またはデベロッパー/パブリックベータのバナー）と表示されていれば、対象で間違いありません。パブリックベータは2026年7月中旬に登場し——Public Beta 1が7月13日、Public Beta 2が7月22日——本記事執筆時点での最新デベロッパーシードはbeta 4、ビルド26A5388g（7月20日）です。Appleはパブリックシードの固定ビルド文字列を公表していないため、特定の番号にこだわりすぎないようにしてください。「macOS 27パブリックベータ」という表現が最も正確です。
  • macOS 26.5.2（ビルド25F84）などと表示されている場合は、ベータではなく安定版Tahoeを使っています。この場合、Chromium全滅は既知のベータパターンではないため、通常のネットワーク問題として扱うべきです。以下のベータ専用の手順ではなく、まずはWi-Fi切断の完全対策ガイドとVPNトラブルシューティングガイドを試してください。

Intel Macユーザーへの注意

macOS 27「Golden Gate」はApple silicon専用（M1以降）です。今回のサイクルですべてのIntel Macが対象外となりました。Intelマシンを使っている場合、そもそもmacOS 27ベータを実行していることはあり得ないため、ブラウザの問題は別の原因によるものです。本ガイドはM系Macでベータを動かしていることを前提としています。

ここでの「ベータ」という言葉の意味

以下の内容はすべて、コミュニティフォーラムや報道で集約されたベータテスターの報告を前提にしています。いずれもAppleが認めた不具合として公式に修正されたものではありません。これには2つの意味があります。挙動はビルドごとに変わる可能性があること（Public Beta 2で必要だった修正が次のシードでは不要になるかもしれません）、そして一部のテスターにとって最終的な解決策は単にAppleを待つことだったということです。プレリリースOSであることを踏まえて期待値を調整してください。

なぜSafari以外のブラウザだけがmacOS 27ベータで壊れるのか

最も有用な診断上の事実は、SafariとChromiumの間のこの違いです。両者がなぜ異なる振る舞いをするのかを理解すれば、修正の方向性がはっきり見えてきます。これはコミュニティ報告に基づく推論であり、リバースエンジニアリングによる確証ではないという前提で見ていきましょう。

SafariとChromiumは異なるネットワーク経路を通る

SafariはWebKitをベースに構築されており、macOSに緊密に組み込まれています。システムのネイティブなネットワークスタック（NSURLSession、システムのリゾルバー、システムの信頼ストア）をAppleのフレームワークが想定する形で利用し、iCloud プライベートリレー、アプリ単位のネットワークポリシー、OSのDNSリゾルバーといったシステムレベルの恩恵を第一級の存在として受け継ぎます。

Chromiumブラウザ（Chrome、Brave、Edge、Arc、VivaldiはすべてChromiumエンジンを共有）は、そうした処理の多くを自前で行います。Chromiumは独自のネットワークサービス、多くの場合独自のDNS-over-HTTPSリゾルバー、独自のコネクションプーリング、そしてソケットの開き方に関する独自の考え方を持っています。この独立性は通常は強みですが、Appleがアプリ単位のネットワーキング、DNS、ネットワーク拡張機能のフィルタリングの挙動を変更しているかもしれないベータでは、弱点になります。Chromiumの前提とベータの新しい挙動がかみ合わなくなることがあり、これはデフォルトでApple流のやり方をするSafariには決して起こらないことです。

ネットワーク拡張機能とDNSの観点（留保付きの説明）

現行のmacOSは、アプリのトラフィックをネットワーク拡張機能フレームワーク経由でルーティングします。コンテンツフィルター、VPNクライアント、DNSプロキシ、ファイアウォールはすべてシステムネットワーク拡張機能として登録され、アプリ単位でトラフィックを検査、リダイレクト、あるいはゲートすることができます。ベータテスターがSafariは動くがすべてのChromiumブラウザは固まると報告するとき、コミュニティで有力な2つの説はいずれもこの領域にあります。

  1. Chromiumアプリだけでネームレゾリューションが失敗している。 ChromeやBraveが独自の**セキュアDNS（DNS-over-HTTPS）**を使っている一方で、ベータがDNS処理について何か新しいことをしている場合、名前解決が永遠にハングすることがあります——これはまさに終わらない*Connecting…*そのものです。システムリゾルバーを使うSafariはこれを回避します。ERR_NAME_NOT_RESOLVEDのようなエラーはこの説にきれいに当てはまります。
  2. ネットワーク拡張機能フィルターが非Safariトラフィックを静かにドロップしている。 Little Snitch、LuLu、社内コンテンツフィルター、一部のアンチウイルススイートなど、ネットワーク拡張機能としてインストールされるツールは、アプリ単位で接続性を裁定します。ベータで拡張機能の評価や承認方法が変わった場合、フィルターがSafariは通しつつChromiumアプリをブラックホール化してしまうことがあります。これはmacOS Tahoe 26.5.1のネットワーク拡張機能シャットダウン修正で取り上げたネットワーク拡張機能コンテンツフィルター周りのベータの摩擦と同じ系統のものです——症状は違いますが、負荷がかかっているサブシステムは同じです。

どちらの説も報告内容と矛盾しませんし、正直なところ、おそらく単一の普遍的な原因ではなく、テスターごとに「Chromiumは独自のネットワーク経路を持つ」という共通の土台の上に異なるトリガーが重なっているのでしょう。これは修正にとって朗報です。自分がどちらのケースかを知る必要はありません。はしごを順に下っていけば、どこかの段で解決するはずです。

エラーメッセージを読み解く

Chromeが表示するエラーは原因をかなり絞り込んでくれるので、クリックし始める前に読んでおきましょう。このベータでよく見られるいくつかのエラーと、その意味は次のとおりです。

  • ERR_NAME_NOT_RESOLVED —— 純粋なDNS失敗です。ブラウザがドメインをIPアドレスにまったく変換できなかったことを意味します。これはFix 1（セキュアDNSをオフにする）とFix 4（キャッシュのフラッシュ）を強く示唆します。このベータパターンで最もよく見られる兆候です。
  • ERR_CONNECTION_TIMED_OUT —— 名前は解決したものの、接続自体が完了しなかったことを示します。ネットワーク拡張機能フィルター（Fix 2）、IPv6の競合（Fix 3）、あるいは中途半端に生きているVPN（Fix 5）が静かにトラフィックを飲み込んでいる可能性を示唆します。
  • ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET —— 何かが能動的に接続を切断しています。コンテンツフィルターやファイアウォール拡張機能を使っているMacでは、それがフィルターの判定途中であることを意味します——Fix 2に直行してください。
  • ERR_PROXY_CONNECTION_FAILED —— プロキシが設定されており（多くは残存する設定プロファイルやVPNアプリによるもの）、機能していません。Fix 5のプロファイル確認を参照してください。
  • エラーなくタブが永遠に回り続ける —— たいていは失敗ではなくハングしているDNSルックアップであり、これもFix 1とFix 4が対象です。

これらはベータ上で決定的なものではありませんが、すべてを順に試すのではなく、どの段から試すべきかを教えてくれます。

「ネットワーク拡張機能」とは平たく言うと何か

ネットワーク拡張機能という言葉に馴染みがなくても大丈夫です——ここで簡単に説明します。以下の修正の半分はこの仕組みに関わっているため重要です。数年前、トラフィックを検査・フィルタリングする必要があるアプリ（VPN、ファイアウォール、ペアレンタルコントロール、アンチウイルスのWeb保護機能）は、深いシステム権限で動作するカーネル拡張機能を使ってそれを行っていました。Appleはここ数リリースをかけて、それらをカーネルの外に出し、ネットワーク拡張機能と呼ばれるサンドボックス化されたユーザー空間フレームワークへ移行させてきました。今日、Little Snitch、社内フィルター、あるいはVPNをインストールすると、それはシステムネットワーク拡張機能として登録され、macOSはそのツールが接続を許可、ブロック、あるいはリダイレクトできるように——多くの場合アプリ単位で——トラフィックをそこ経由でルーティングします。

このアプリ単位の機能こそが要点です。ネットワーク拡張機能は原理的にSafariとChromeを異なる扱いにすることができ、接続がどう構成されているかをOSに教えてもらうことに依存しています。ベータが下回りの配管——拡張機能がどう承認されるか、アプリ単位のトラフィックがどうタグ付けされるか、拡張機能に各接続がどう渡されるか——を変更すると、Safariに対しては完璧に動作していた拡張機能が、誰も意図しないままChromiumのトラフィックをドロップしたり止めたりしてしまうことがあります。だからこそ「ネットワーク拡張機能を無効化して再テストする」という手順がここで重要な役割を果たし、ベータのアップデートのたびに拡張機能を再承認することが大切なのです。

なぜこれが「ブラウザが壊れている」ではなく「ベータのせい」だと言い切れるのか

もしChrome自体が壊れているなら、再インストールで直るはずですし、Brave/Edge/Arc/Vivaldiが足並みを揃えて失敗することもないでしょう。もしネットワークが壊れているなら、Safariも失敗するはずです。「すべてのChromiumブラウザが死んでいる一方でWebKitは正常、同じマシン、同じWi-Fi」をきれいに説明できる唯一のものは、この2種類のアプリを異なる扱いにするOSとネットワーク層にある何かであり、それはまさにプレリリースOSがやらかしがちな類のものです。Golden Gateベータの既知の問題まとめを読むと、このビルドにどれだけ粗さが残っているかの背景がわかり、参考になります。

60秒でできるトリアージチェックリスト

本格的なはしごに入る前に、この5つの簡単なチェックを実行してください。ほとんど手間をかけずに、当たりの修正へまっすぐ導いてくれることが多いです。

  1. Safariはサイトを読み込めますか？ はいなら、これはChromium特有のパターンだと確認でき、以下のはしごが当てはまります。Safariも失敗する場合、これはベータブラウザのバグではなく一般的な接続性の問題です——Wi-Fi切断ガイドへ進んでください。
  2. VPNやコンテンツフィルターは動いていますか？ メニューバーとシステム設定 > 一般 > ログイン項目と機能拡張 > ネットワーク拡張機能を確認してください。何かがあれば、それが第一容疑者です。
  3. iCloud プライベートリレーはオンですか？ システム設定 > [あなたの名前] > iCloud > プライベートリレーで、有効かどうかを確認してください。
  4. ドメイン名がダメでもIPアドレスは動きますか？ Chromeでhttp://1.1.1.1を読み込んでみてください。生のIPは読み込めるのにcloudflare.comは読み込めない場合、問題はDNSであり、Fix 1とFix 4があなたの狙い目です。
  5. まっさらなブラウザプロファイルでも同じ挙動になりますか？ Chromeで新しいゲストウィンドウを開いてください。それでも失敗するなら、原因はシステム全体にあり、プロファイル固有ではありません——ネットワーク系の修正へ進んでください。

この5つが何を示していようと、Fix 1から順番に始めても構いません。修正のたびにChromeを完全に再起動してください（Cmd+Qで、ウィンドウを閉じるだけでは不十分です）。そうしないと変更が実際に反映されません。

どこで壊れているかを正確に確認する（任意ですが有効です）

設定を変える前にどの層で失敗しているか確実に知りたいなら、5つの安全なターミナルコマンドが教えてくれます。いずれも何かを変更するものではなく、状態を読み取るだけなので、リスクなくすべて実行できます。ポイントは3つの問いを切り分けることです。ネットワークにそもそも到達できるか？ DNSは機能しているか？ Chromeでは動かないのにシステムレベルのHTTP経路は動くか？

1. 生のIPでインターネットに到達できますか？ これはDNSを完全にバイパスします。

ping -c 4 1.1.1.1

応答が返ってくれば、Macの接続性は正常であり、問題はもっと上のレイヤー（DNSまたはアプリ単位）にあります。これも失敗する場合はSafariも失敗するはずで、それはベータのブラウザパターンではなく一般的な接続性の問題です。

2. DNS解決は機能していますか？

ping -c 4 cloudflare.com

手順1が成功したのにこちらが解決できない、あるいはハングする場合、DNSの問題であることが確認できました——まさにFix 1とFix 4が狙う対象です。

3. リゾルバーに直接尋ねる。 digとnslookupはどちらもmacOSに標準搭載されており、システムリゾルバーが何を返すかを示してくれます。

dig cloudflare.com +short
nslookup cloudflare.com

ここで答えが返ってくるということは、システムのリゾルバーは正常であり、Chromium自身のDNS-over-HTTPSがハングしている張本人だという強いシグナルです——Fix 1（ブラウザのセキュアDNSをオフにして、この正常に動くシステムリゾルバーに委ねる）が効くという有力な証拠になります。

4. Chromeでは失敗するのに、システムのHTTPスタックはページを読み込めますか？ curlはmacOS自身のネットワーキングを使い、Safariが使うのと同じ種類の経路を通ります。

curl -I https://www.cloudflare.com

Chromeがハングしている間にcurlがヘッダー（HTTP/2 200など）を返すなら、それが診断そのものです。OS側の経路は動いていて、Chromium側の経路は動いていません。それがベータパターンであることの確認であり、以下のシステムレベルの修正が最善の対策だということを意味します。

5. システムは実際にどのDNSを使っていますか？

scutil --dns | grep nameserver
networksetup -getdnsservers "Wi-Fi"

これは、VPN、プロファイル、あるいはフィルターが、あなたの意図しないDNSサーバーへ静かに向けていないかを示してくれます。予期しないアドレスが見えた場合は、Fix 5のプロファイルとVPNのチェックに戻ってください。

この5つを実行すれば、設定に手を触れる前に、DNS、フィルター、アプリ単位の経路のどれを追いかけているかがわかります。ターミナルが苦手なら、このセクションはまるごと飛ばしても構いません——修正のはしごはこれなしでも問題なく機能します。

修正のはしご

上から順に試してください。各ステップの後に再テストし、サイトが復活した時点でやめて構いません。ここでの各ステップはすべて元に戻せます。

Fix 1: ブラウザのセキュアDNS / DNS-over-HTTPSをオフにする

これはこのベータパターンに対して最も効果が高い単一の修正です。Chromium内蔵の暗号化DNSは、まさにベータOSと同期がずれやすい自前管理のネットワーキングの典型例だからです。ブラウザに、名前解決を自前で行うのをやめてシステムに委ねるよう指示します。

Chrome、Brave、Edge、Vivaldiの場合:

  1. 設定 > プライバシーとセキュリティ > セキュリティを開きます。
  2. セキュアDNSを使用するまでスクロールし、完全にオフにします。（プロバイダーを切り替えるだけでなく、オフにしてブラウザがOSのリゾルバーを使うようにしてください。）
  3. ブラウザを完全に終了し（Cmd+Q）、再度開きます。

Arcの場合: Arc > Settingsを開き、プライバシー/セキュリティのセクションを探して同じ方法でセキュアDNSを無効化してください。ArcはChromiumのこの設定を自身のメニューの下に公開しています。

トリアージチェックで生のIPが読み込めてドメインは読み込めなかった場合、この一手だけで解決することが非常に多いです。

macOSでブラウザのセキュアDNSを無効化する

Fix 2: ネットワークフィルター、VPN、コンテンツフィルターの拡張機能を無効化または削除する

Little Snitch、LuLu、社内コンテンツフィルター、DNSフィルタリングアプリ、あるいはWeb保護機能付きのアンチウイルススイートを使っている場合、それはほぼ確実にシステムネットワーク拡張機能として自身をインストールしており、このベータでSafariを通しつつChromiumをブロックしている主犯候補です。

  1. システム設定 > 一般 > ログイン項目と機能拡張に移動し、ネットワーク拡張機能の横にある**（i）をクリックします（古いパスではネットワーク拡張機能またはコンテンツとプライバシー**、ビルドによって異なります）。
  2. サードパーティのネットワークフィルター/VPN/ファイアウォール拡張機能を1つずつオフにします。
  3. トグルするたびにChromeを完全に終了して再度開き、再テストします。

一つを無効化してChromeが復活したら、犯人を特定できたということです。そこから、Appleが修正版のビルドを出すまでオフのままにしておく、ツールを最新バージョンに更新する（ベンダーはベータ向けのパッチを素早く出すことが多いです）、あるいはベンダーのベータ互換性に関する情報を確認する、といった選択肢があります。管理された職場のMacを使っている場合、自分で社内フィルターを無効化できないこともあります——それはIT部門に相談すべきケースであり、ベータを見送る正当な理由にもなります。ネットワーク拡張機能コンテンツフィルターの解説記事では、OSが下回りで変化したときにこうした拡張機能がどう振る舞うかをさらに深掘りしています。

Fix 3: アクティブなネットワークサービスのIPv6をリンクローカルのみに設定する

複数のテスターが、Chromiumのデュアルスタック（IPv4 + IPv6）接続レースが、IPv6が誤動作するとベータ下でハングする一方、Safariはそれに耐えると報告しています。ネットワークサービスをフルIPv6から外すことで、正常に動くIPv4経路にトラフィックを押し出せます。

システム設定経由（推奨、穏やかな方法）:

  1. システム設定 > ネットワークでアクティブなサービス（Wi-FiまたはEthernet）を選択し、**詳細…**をクリックします。
  2. TCP/IPタブに移動します。
  3. IPv6の設定をリンクローカルのみに設定します。
  4. OKをクリックし、Chromeを完全に終了して再度開きます。

ターミナル経由（同等の方法、コマンドラインを好む場合）: まずサービス名を一覧表示し、使っているものについてIPv6をオフにします。-setv6offはGUIの「リンクローカルのみ」よりも完全にIPv6を無効化しますが、この問題を切り分けるにはどちらでも機能します。

# See the exact network service names
networksetup -listallnetworkservices

# Turn IPv6 off for Wi-Fi (use your exact service name)
sudo networksetup -setv6off "Wi-Fi"

後で通常のIPv6に戻すには:

sudo networksetup -setv6automatic "Wi-Fi"

macOSのネットワーク設定パネル

Fix 4: DNSキャッシュをフラッシュする

DNSが原因の場合（このベータではよくあります）、古くなった、あるいは壊れたリゾルバーのキャッシュが、設定を変更した後もルックアップの失敗を固定してしまうことがあります。それをクリアしましょう。これは標準的で安全なmacOSのコマンドペアです——キャッシュをフラッシュし、マルチキャストDNSレスポンダーを再起動します。

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

管理者パスワードの入力を求められます。成功しても目に見える出力はありません——それは正常です。その後Chromeを終了して再度開き、サイトを試してください。最良の結果を得るにはFix 1（セキュアDNSをオフにする）と組み合わせてください。この2つを合わせることで、このベータで報告される最も一般的なDNS失敗パターンに対処できます。

Fix 5: プライベートリレー、VPN、設定プロファイルを確認する

iCloud プライベートリレーとVPNはどちらも、Macから出ていくトラフィックの形を変え、どちらもSafariとChromiumアプリで扱われ方が異なります——これは非対称な失敗の典型的な容疑者です。

  • iCloud プライベートリレー: システム設定 > [あなたの名前] > iCloud > プライベートリレー。一時的にオフにしてChromeを再テストしてください。プライベートリレーはSafariと一部のシステムトラフィックのみをルーティングしますが、トグルすることでChromiumが引っかかっていたネットワーク状態がリセットされることがあります。
  • VPN: VPNが接続されている場合、完全に切断してください（アプリを最小化するだけでは不十分です）。そして再テストします。中途半端に接続された、あるいはベータと互換性のないトンネルは、「ブラウザが永遠にハングする」原因として非常によくあるものです。VPNが原因だと判明した場合は、macOS VPNトラブルシューティングガイドを試してください。ほとんどのVPNクライアントはベータに対応したアップデートが必要です。
  • 設定プロファイル: システム設定 > 一般 > デバイス管理（またはプライバシーとセキュリティ > プロファイル）で、心当たりのない、あるいは不要な古いDNSやプロキシのプロファイルを削除してください。残存するプロファイルが不適切なDNSサーバーを固定してしまうことがあります。

Fix 6: 一部のテスターが有効だと言うFaceTime / 「他のデバイスでの通話」トグル

これは奇妙で、確証もありませんが、一部のフォーラム投稿者が自分のChromiumブラウザを復活させたと報告しているため、30秒かける価値はあります。理論としては、このContinuity機能をトグルすることで、ベータが不良な状態のままにしてしまったアプリ単位の経路をネットワークスタックが再初期化する、というものです。

  1. FaceTime > 設定を開きます（メニューバー: FaceTime > 設定）。
  2. iPhoneからの通話 / 他のデバイスでの通話を許可を見つけ、オフにしてからオンに戻します。
  3. あるいはiPhoneで: 設定 > 電話 > 他のデバイスでの通話で、あなたのMacをオフにしてからオンに戻します。
  4. Chromeを再テストします。

これは一部の人にたまたま効く言い伝えのようなものであり、確実な修正とは考えないでください。コストはゼロで即座に元に戻せるので、試す価値はあります。

Fix 7: ブラウザのネットワーク設定をリセットする、または新しいプロファイルで始める

システムレベルの修正で解決しない場合、特定のブラウザプロファイルが壊れたネットワーク状態を保持していないか切り分けます。

  • Chrome/Brave/Edge: 設定 > 設定をリセット > 設定を元のデフォルトに戻すを開きます。これはブックマークやパスワードに触れることなく、カスタムのDNS、プロキシ、起動時の調整をクリアします。
  • 新しいプロファイルでのテスト: 新しいプロファイルを作成する（プロフィールアイコン > 追加）か、ゲストウィンドウを開いてサイトを試してください。新しいプロファイルで動作するなら、問題はプロファイル固有のものです——古いプロファイルをリセットするか、新しいプロファイルに移行してください。
  • ソケット/ホストキャッシュのクリア: Chromeでchrome://net-internals/#socketsにアクセスしてFlush socket poolsをクリックし、続いてchrome://net-internals/#dnsでClear host cacheをクリックします。（BraveとEdgeも同じページをそれぞれ独自のスキームで公開しています。例: brave://net-internals。）

Fix 8: ブラウザをクリーンに再インストールする

ネットワーク系の修正の後も特定の1つのブラウザだけが残っている場合は、それをクリーンに再インストールしてください。Chrome、Brave、Edge、Arc、Vivaldiはすべて同じエンジンを共有しているため、これは1つのブラウザだけが他より遅れている場合にのみ行ってください——システム的な原因は再インストールでは治りません。

  1. ブラウザを終了します（Cmd+Q）。
  2. アプリケーションフォルダからゴミ箱にドラッグします。
  3. ベンダーから直接最新のビルドをダウンロードします——ベータ互換性の修正はブラウザのアップデートで絶えず配信されているため、現行ビルドはすでにこのベータをうまく扱えるようになっているかもしれません。
  4. 再インストールして再テストします。サインインし直せば、同期されたデータ（ブックマーク、パスワード）は戻ってきます。

Fix 9（ベータの現実を踏まえたフォールバック）: Safariを使うか、Tahoeに戻す

ここからは正直な話です。これはベータであり、ブラウザの全滅はベータテスターが報告したものでAppleが認めたものではなく、一部のテスターは、Appleが新しいビルドを出すまで上のはしごのどれも完全には定着しないと感じています。はしごを最後まで試してもChromiumが死んだままなら、賢明な選択肢は2つです。

  • 当面はSafariに頼る。 動作しますし、速く、ブックマークもインポートできます。ベータが成熟するまでの数週間、日々のブラウジングをSafariで行うのは十分理にかなったつなぎであり、新しいシードが出るたびにChromeを再テストし続けることができます（挙動はビルドごとに本当に変わります）。
  • 安定版Tahoeに戻す。 動作するChromiumブラウザが譲れない条件——仕事のため、拡張機能のため、移行できないワークフローのため——であるなら、最もクリーンな解決策はベータを離れることです。データを失わずにmacOS 27ベータをTahoeにダウングレードする手順ガイドに従ってください。もしベータを検討中なだけなら、この一件は別ボリュームに安全にインストールすることの強い論拠になります。そうすれば、日常使いのシステムが壊れることは決してありません。

これらのどれを選んでも恥じることはありません。ベータはあなたが自ら志願してテストするプレビューであり、壊れたブラウザに耐え続ける約束ではないのですから。

よくある問題のトラブルシューティング

問題: ベータ環境でChromeが一部のサイトは読み込めるが、他は固まる

解決策: 部分的な読み込みは、ほぼ常に完全なブロックではなくDNSを意味します。一部の名前はキャッシュから解決されますが、新しいルックアップはハングします。Fix 1（セキュアDNSをオフにする）とFix 4（DNSキャッシュのフラッシュ）を一緒に実行し、Chromeを完全に終了してから再試行してください。それでも続く場合は、システムDNSをシンプルなリゾルバーに設定してください——システム設定 > ネットワーク > 詳細 > DNSで1.1.1.1と8.8.8.8を追加し、OSがベータで不具合を起こしているリゾルバーに依存しないようにします。

問題: 動いていたのに、ベータのアップデート後に再び壊れた

解決策: これは想定内です。新しいシードごとにネットワーク拡張機能の承認とトグルの挙動がリセットされることがあります。macOS 27ベータのアップデート後は、システム設定 > 一般 > ログイン項目と機能拡張 > ネットワーク拡張機能でネットワーク拡張機能を再承認し、Fix 1とFix 4を再実行してください。これは公式に認められていないベータの挙動なので、前回の修正がまだ有効だと想定するのではなく、ビルドごとに一から診断し直すつもりでいてください。

問題: 職場や学校のMacで必要な修正がブロックされる

解決策: 管理されたMacは、自分では無効化できない社内コンテンツフィルターや設定プロファイルを強制しており、そうしたフィルターはSafariは動くのにChromiumは失敗するという分裂の有力な容疑者です。MDMと戦わないでください。IT部門に連絡し、macOS 27ベータでChromiumアプリだけブラウザが失敗すると伝え、フィルターのベンダーにベータ互換のビルドがあるか確認してもらいましょう。ない場合、これは本番/管理対象のMacがまだベータに乗るべきではないという明確なサインです。

問題: ネットワーク拡張機能を無効化したらChromeは直ったが、そのツールは動かし続けたい

解決策: 犯人は特定できました——今度は正しい方法で保護を復元しましょう。ベンダーはベータ互換パッチを素早く出すことが多いので、ツール（Little Snitch、LuLu、アンチウイルス）を最新バージョンに更新してください。ベンダーのリリースノートやフォーラムでmacOS 27に関する記載を確認してください。互換ビルドがまだない場合、このベータではそのツールとChromiumのどちらかを選ぶことになります——Tahoeへの巻き戻しを検討する正当な理由です。

よくある質問

なぜmacOS 27ベータでSafariは動くのにChromeやBraveは動かないのですか？

SafariはネイティブのネットワーキングとネイティブのmacOS DNSを使うため、ベータが変更した内容をそのまま受け継ぎます。Chromiumブラウザは自前でDNS、ソケット、接続ロジックを管理しており、これがベータの新しいアプリ単位のネットワーク処理と同期しなくなることがあります。同じマシン、同じWi-Fiでも、ネットワーク経路が異なるため、片方は動き、もう片方はハングします。

これはAppleの公式バグで、修正が来る予定ですか？

公式にはそうではありません。この問題はBraveコミュニティ、Apple Discussions、MacRumorsでベータテスターによって報告され、報道でも集約されていますが、Appleは正式な声明を出していません。プレリリースビルドで起きていることなので、新しいシードのたびに挙動が変わる可能性があり、macOS 27ベータのアップデートのたびに再テストしてください。

セキュアDNSをオフにすると、ブラウジングのプライバシーは低下しますか？

わずかに、一時的にです。ブラウザのDNS-over-HTTPSを無効化すると、名前解決は暗号化されたものではなくシステムリゾルバーを使うようになります。ベータの回避策としては十分に妥当なトレードオフであり、AppleがChromiumとうまく連携するビルドを出したらセキュアDNSを再度有効にできます。HTTPSのページトラフィック自体はどちらの場合も暗号化されたままです。

macOS 26.5.2を使っていてベータではありません。これらの修正は当てはまりますか？

おそらく当てはまりません。Chromiumの全滅はベータのパターンです。安定版のTahoe 26.5.2（ビルド25F84）でブラウザがサイトを読み込めない場合、通常の接続性の問題、VPN、あるいはフィルターである可能性のほうが高いです。ここで紹介したベータ専用の手順ではなく、まず上記のWi-FiガイドとVPNガイドから試してください。

Chromeを再インストールするだけで直りますか？

この問題に関してはめったにありません。Brave、Edge、Arc、VivaldiがすべてChromeと一緒に失敗する場合、原因はシステムレベルにあり、1つのブラウザを再インストールしても効果はありません。1つのChromiumブラウザだけが他より遅れている場合にのみ再インストールしてください——その際は必ず最新ビルドを取得してください。ブラウザのアップデートはしばしばベータ互換性を追加します。

これを理由にTahoeへ戻すべきですか？

動作するChromiumブラウザが日常に不可欠で、修正のはしごが効かなかった場合は、はい、それは妥当な判断です。上記のダウングレードガイドに従えば、データを失わずに巻き戻せます。数週間Safariで生活できるなら、ベータに留まって新しいシードのたびに再テストするほうが手間の少ない選択肢です。

まとめ

macOS 27ベータでChromeがサイトを読み込めないのにSafariは完璧に動くとき、あなたが直面しているのは壊れたMacでも壊れたブラウザでもなく、Chromiumの独立したネットワーク経路をWebKitとは異なる形で扱うプレリリースOSです。この一つの洞察こそが、修正のほとんどが素早いトグルで済む理由です——ブラウザのセキュアDNSをオフにする、ネットワークフィルター拡張機能を無効化する、IPv6をリンクローカルのみに設定する、DNSキャッシュをフラッシュする、そしてプライベートリレーとVPNを確認する。これらのうちどれか一つが、ほとんどのテスターにとって当たりとなり、そのすべてが数秒で元に戻せます。

ただし、正直な前提は常に忘れないでください。これはベータテスターが報告した挙動であり、Appleが確認したバグではなく、ベータにおける最終的な解決策は時に忍耐であるということです。挙動はビルドごとに変わるため、新しいシードのたびに再テストしてください。そして、動作するChromiumブラウザがどうしても手放せないものなら、Safariに頼るか、安定版Tahoeへの巻き戻しを選んでAppleが解決するのを待つことに何の恥もありません。あなたはプレビューをテストすることを自ら志願したのであり、壊れたブラウザを「次のビルドを待つ」状況として扱うのは、まさに正しい判断です。

最後に一つ、実践的な習慣として。ベータのペースを見守ってください。Appleはおよそ1〜2週間ごとにシードを出しています——Public Beta 1は7月13日、Public Beta 2は7月22日に登場し、デベロッパーベータ4（ビルド26A5388g）は7月20日でした——そしてネットワーキングの挙動はシードごとに本当に変化しています。ですから、賢いやり方は、効いている修正をそのまま維持し、どの段で解決したかをメモしておき、新しいビルドが出るたびにその回避策を一時的に無効化してChromeを再テストすることです。もしあるシードが根本的な問題を静かに解決していたら、セキュアDNSとIPv6を永久に変更したままにするのではなく、通常の設定に戻したくなるはずです。ベータは動き続けるもので、あなたの回避策は永久であるべきではありません。

はしごを上から順に試し、サイトが復活した最初の段でやめてください。そして、そもそもGolden Gateに留まるべきかどうかを検討しているなら、既知の問題ガイドと安全なインストール手順が、はっきりした視点で判断する助けになるはずです。