失敗談・学び

Playwright経由のGoogle OAuthは100%拒否される話

公開: 2026-05-19 · 著者: Sasaki Ryuji

自動化スクリプトでGoogle OAuth を通そうとしている人へ、結論を先に置きます

Playwright経由のGoogle OAuthは100%拒否される話

あなたが自動化スクリプトで Google アカウントのログインを通したいと考えているなら、この記事を3分だけ読んでから判断してください。結論から言うと、Playwright や Puppeteer 経由の Google OAuth は2026年5月時点で100%拒否されます。私はこれを GramShift 開発の派生スクリプト (note 自動投稿、YouTube 自動アップロード等) で約3週間試行錯誤した末に確信しました。この記事ではその試行錯誤の全記録と、最終的に取った迂回策を残します。

最初の壁 — 通常のChrome起動では即拒否される

最初の試みは、Playwright のデフォルト Chromium で accounts.google.com にアクセスして、メールとパスワードを入力する、というシンプルなコードでした。結果はすぐに分かります。パスワード入力後、「このブラウザまたはアプリは Google で安全にログインできない可能性があります」という警告画面が表示され、ログインボタンは無効化されたままです。

Google は navigator.webdriver プロパティ、特定の User-Agent 文字列、ブラウザ起動引数、画面解像度パターン、その他多くのシグナルを組み合わせて自動化ブラウザを検知しています。デフォルトの Playwright Chromium は HeadlessChrome や Playwright 固有の指紋を残すため、ほぼ即時に検知されます。

試した対策15個と結果

私が約3週間で試した対策は概ね以下の通りです。すべてダメでした。

  • headless: false にする (UI 表示モード) → 検知される
  • User-Agent を本物の Chrome 文字列に偽装 → 検知される
  • navigator.webdriver を JavaScript で undefined に上書き → 検知される
  • playwright-extra + stealth プラグインを使用 → 当初は通ったが2日で対策された
  • persistent context で本物のプロファイルディレクトリを指定 → 既存ログイン状態は維持できるが、新規ログインは弾かれる
  • Chrome の実バイナリ (system Chrome) を使用 → 検知される
  • 異なる解像度・viewport で起動 → 検知される
  • マウス動作を人間らしくシミュレート → 検知される
  • VPN 経由で別IPから接続 → 検知される
  • セッションクッキーを別ブラウザからエクスポート・インポート → 一時的に通るが2-3日で失効

とくに playwright-extra + puppeteer-extra-plugin-stealth は一時期最も期待値の高い対策で、ネット上の記事でも「これで通る」とされていますが、Google は2024年後半から指紋検知を強化しており、現状ほぼ通りません。一時的に通っても数日で対策されます。

迂回策 — IDとパスワードで直接認証

Google OAuth を諦めた後、私が取った迂回策は単純です。SaaS の自動投稿スクリプトは Google OAuth 経由でなく、各サービス独自のメール+パスワードログインを使う、という方針に切り替えました。例えば note や YouTube の場合、Google OAuth を選ぶのではなく、note 専用のメールアドレスとパスワードでログインするフォームを使えば、Playwright でも普通に通ります (note の場合)。

YouTube は Google アカウントが必須なので、別のアプローチを取りました。YouTube Data API v3 でアップロード機能を実装し、初回だけ手動で OAuth 認証して refresh_token を取得、以降はサーバー側でその token を使ってAPIアクセス、という構成です。これだとブラウザ自動化は不要で、Google の検知も回避できます。

結論 — 設計時に「Google OAuth 経由は最初から諦める」と決める

個人開発で SaaS の自動投稿スクリプトを設計する段階で、Google OAuth 経由の自動化は最初から選択肢から外すのが最も合理的です。試行錯誤に3週間かけて結論が「不可」だと、開発時間という最も貴重なリソースを失います。代替手段としては以下の3つがあります。

  • 各サービス独自のメール+PW認証を使う (note、Threads等で利用可能)
  • サービス公式の API + refresh_token 方式 (YouTube、Google Drive等)
  • OAuth が必須なら、初回だけ手動でブラウザ操作して認証情報を取得し、以降はトークンで自動化

「Google OAuth 経由で完全自動化できないか」という発想は捨てて、運用設計を初期段階で組み直すのが最善です。3週間の試行錯誤を経た者からの率直な助言として残します。

同様のブラウザ自動化のハマりどころは失敗談カテゴリに、Playwright 実装の応用例は技術ログに追記しています。