結論から

Google ドライブの WebDAV URL は存在しません。隠しエンドポイントでもベータ版でもなく、Workspace 管理コンソールのスイッチでもありません。2026年9月に Google 公式ドキュメントを確認したところ、ブラウザ以外から Drive に到達する手段として公開されているのは Drive REST API と Drive for desktop の2つだけです。API 概要ページに並ぶのは REST API、Picker API、Apps Script、Activity API、Labels API で、WebDAV という語は出てきません。

Google が公開している Drive アクセス手段（2026年9月確認）
手段	Google 自身の記述	WebDAV
Drive REST API	アプリから Drive ストレージを使うための REST API	なし
Drive for desktop	stream / mirror の2モード、Windows と macOS のみ	なし
ブラウザ版 Drive	Linux では the desktop version isn't available	なし
WebDAV エンドポイント	ドキュメントに記載なし	存在しない

なぜ「Google ドライブ WebDAV」を探すことになるのか

プロトコル名で検索する人は、たいてい具体的な困りごとを抱えています。典型は3つです。

NAS のバックアップジョブ。 Synology も QNAP も WebDAV クライアントを持っていて、遠くのストレージを指定する最も汎用的な宛先が WebDAV です。Drive も URL ひとつで指定できそうに見えます。
WebDAV しか話せないアプリ。 文書管理システム、古い CAD や会計ソフト、スキャナーのファームウェア。リモート保存先の入力欄が1つだけで WebDAV アドレス専用という製品は今も珍しくありません。
Linux。 Google のシステム要件ページははっきり書いています。Linux については「the desktop version isn't available. Instead, you can use Google Drive on the web.」です。Linux のファイルマネージャーには WebDAV クライアントが標準で入っているので、自然な逃げ道に見えます。

どれにも現実的な答えはあります。ただしその答えは、Google が出す WebDAV URL ではありません。

方法1：Drive for desktop（stream か mirror）

Google 公式クライアントです。最初に理解すべきなのは2つのモードの違いです。

ヘルプセンターの定義は明確です。stream では「files are primarily stored in the cloud, but will be made available offline when accessed」で、ファイルは「on a virtual Drive on your computer」に置かれます。mirror では「mirrored files will always be stored on your computer and in the cloud」で、置き場所は「in a folder on your computer」です。stream はディスクをほぼ消費せず、mirror は容量を使う代わりに本物のオフラインアクセスが手に入ります。

2026年9月時点の公開要件は、64-bit の Windows 10 以降または Windows Server 2016 以降、ARM64 は Windows 11 以降、macOS は Ventura 13.0 以降。Windows では「requires Microsoft WebView2, which is usually included in Windows 11 and most Windows 10 devices」とあります。Linux ビルドはありません。

代償： Linux 非対応、アカウントごとに別マウント、NAS やアプリに渡せる WebDAV URL は手に入りません。

方法2：rclone serve webdav を Drive リモートの前に置く

「どうしても Drive に届く WebDAV URL が必要」への正直な答えです。WebDAV サーバーを自分で動かし、rclone が WebDAV と Google API を橋渡しします。

bash

rclone config
rclone serve webdav gdrive: --addr 127.0.0.1:8080 --user alice --pass secret

rclone 公式ドキュメントで2026年9月に確認した事実が3つ。第一に --addr の既定値は 127.0.0.1:8080 で、初期状態では同じマシンからしか届きません。外に出すなら --addr を変え、TLS は自分の責任になります。第二に認証は単一アカウントなら --user と --pass、Apache 形式なら --htpasswd、リバースプロキシ配下なら --user-from-header。第三に Drive では最重要の点として、Drive バックエンドのページに「the shared client_id is being retired and will stop working during 2026」「creating your own is now strongly recommended」とあります。Google API Console で自分の client_id と client_secret を作らずに組むと、期限が予告された仕組みの上に運用を載せることになります。

同じページにもう1つ重要な数字があります。「Drive has quite a lot of rate limiting. This causes rclone to be limited to transferring about 2 files per second only.」これは Drive の API 側の性質で、クライアントを変えても消えません。

代償： 常駐プロセス、設定ファイル、自前の OAuth 認証情報、外に出すなら TLS、Drive のレート制限はそのまま。ただし FUSE は不要で、rclone mount と違ってドライバーを入れません。比較は rclone mount の代替にあります。

方法3：Nextcloud を挟む案は「ドキュメントにない」

もう1つよく勧められるのが、自前の WebDAV サーバーを Drive の前に置く方法です。Nextcloud の外部ストレージに Drive を追加し、クライアントは Nextcloud を向く構成です。2026年9月に確認した Nextcloud 管理マニュアルの外部ストレージ一覧は Amazon S3、FTP/FTPS、Local、Nextcloud、OpenStack Object Storage、SFTP、SMB/CIFS、WebDAV。Google Drive は入っていません。 旧バージョンに Google Drive バックエンドがあったという投稿は見かけますが、現行ドキュメントに記載のないものの上に運用は組めません。本題が Nextcloud 側の速度なら Nextcloud の WebDAV が遅い理由が役に立ちます。

方法4：Google との間に WebDAV を挟まない

そもそもその WebDAV URL は何のためだったのかを考え直す価値があります。目的が「Drive のファイルを Finder やエクスプローラーで見たい」なら、WebDAV は最後の1区間でよく、Google と話す区間である必要はありません。

AnyStorage はその形です。Google ドライブは接続タイプの1つで、アプリ内で Drive 自身の OAuth サインインを通すため、Drive が WebDAV を話すふりはしません。マウントしたボリュームが欲しければ、アプリが自分のマシン上で WebDAV サーバーを動かします。サイドバーの Services、WebDAV タブ、Start。既定アドレスは http://127.0.0.1:3211、HTTP Basic 認証は常に有効で、ユーザー名は anystorage、パスワードは初回起動時に生成される24文字です。開いている接続はすべてそのルート直下のフォルダーとして並ぶので、Drive が S3 バケットや SFTP ホストと同じマウントに同居します。macFUSE も WinFsp も管理者パスワードも不要です。

正直に書くと、これは 0.2.x の若いアプリです。無料プランは接続2つまでで、このマウントは読み取り専用（閲覧・再生・コピーアウトは可、書き戻しは Pro）。商用利用は無料プランでも可能です。動作環境は macOS 11+、Windows 10+、Ubuntu 20.04+ で、Google の「Linux はブラウザで」という回答が理由でここに来た人にはこの一行が効きます。手順は Google ドライブをネットワークドライブとしてマウントする、一般論はクラウドストレージをローカルドライブとしてマウントするにあります。

それぞれの代償を並べる

4つの手段の比較（2026年9月）
手段	WebDAV URL が手に入る	Linux	常駐プロセス	主な落とし穴
Drive for desktop	いいえ	非対応	Google のクライアント	アカウントごとに1マウント
`rclone serve webdav`	はい	対応	rclone を常駐	2026年以降は自前の OAuth 必須
Nextcloud を挟む	はい	対応	Nextcloud 一式	Drive バックエンドが未記載
ローカル WebDAV を持つクライアント	はい（loopback）	対応	アプリ本体	無料プランは読み取り専用

最後の列で決まります。NAS や機器から Drive に届かせるなら常時稼働の rclone serve webdav、自分のファイルマネージャーで開くだけなら loopback を持つクライアントです。

Finder に貼れる Google ドライブの WebDAV URL はありますか

ありません。2026年9月時点で Google は Drive 向けの WebDAV エンドポイントをどのドキュメントにも公開しておらず、Drive API の概要ページにプロトコル名すら出てきません。それらしいアドレスは第三者のブリッジのもので、Google のものではありません。

昔の Google ドライブは WebDAV に対応していた？

確認できるドキュメントの範囲では対応していません。現行ドキュメントには REST API と Drive for desktop しかなく、WebDAV サービスの開始や終了を告知したベンダーページも見つかりません。旧エンドポイントを語る投稿は未検証として扱ってください。

Synology や QNAP から WebDAV なしで Google ドライブへバックアップできますか

できますし、そのほうが筋が通っています。Synology の Cloud Sync は「sync and share files among your Synology NAS and multiple public cloud services」のための機能で、ヘルプ本文でも Google Drive を例に挙げています。WebDAV の代用品ではなく、ベンダーがサポートする Drive API 接続です。逆方向は NAS の WebDAV 設定にまとめました。

rclone serve webdav はインターネットに公開しないといけませんか

クライアントが別のマシンにある場合だけです。公開されている既定値 --addr は 127.0.0.1:8080 で loopback のみです。外に出すなら、公開アドレスを選び、TLS を自分で用意し、--user と --pass、--htpasswd、プロキシ配下の --user-from-header のいずれかを選ぶことになります。

どの方法でも Drive が遅いのはなぜ

ボトルネックが Drive の API だからです。rclone の Drive ドキュメントは「Drive has quite a lot of rate limiting」と明言し、ファイル単位の処理は「about 2 files per second only」に制限されると書いています。同じ API の手前でプロトコルを替えても上限は上がりません。効くのはファイル数を減らすことだけです。

次に読むもの

クライアント選びが本題だったなら WebDAV クライアントの選び方がハブです。Windows なら Windows 11 の無料 WebDAV クライアントで、2023年11月の Microsoft による非推奨化が何を変えたかを扱っています。

Google ドライブは WebDAV 非対応：代わりに使える4つの方法