Playwright経由のGoogle OAuthは100%拒否される話
自動化スクリプトでGoogle OAuth を通そうとしている人へ、結論を先に置きます
ここでつまずく原因は、結局この3つに集約されます。
- Playwright / Puppeteer 経由で Google OAuth を通そうとする試みは 2026 年現在 100% 拒否される。3 週間試行錯誤して結論が「不可」だった経験から、設計時に最初から諦めるのが最も合理的
- Google の自動化ブラウザ検知は navigator.webdriver / fingerprint / behavior pattern / IP reputation の 4 層構造、stealth プラグインも 2-3 日で対策される
- 迂回策は明確: 各サービス独自の ID+PW 認証 / 公式 API + refresh_token 方式 / 初回手動 OAuth + トークン保存 の 3 択。Playwright での全自動 Google OAuth は時間の無駄
以下、3 週間の試行錯誤の全記録と、Google の自動化検知の仕組み、Puppeteer / Selenium との比較、テスト中ステータスの 7 日縛りまで含めて時系列で残します。
あなたが自動化スクリプトで 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 実装の応用例は技術ログに追記しています。
Google が Playwright を検知する仕組み — 4 層構造
3 週間の試行錯誤で、Google の自動化ブラウザ検知は単一の仕組みではなく、複数のシグナルを組み合わせた多層構造だと理解しました。公開されている情報 (Google Identity ドキュメント / Chromium ソースコード / 研究論文) ベースで整理します。
- レイヤー 1: ブラウザ指紋 (Fingerprint)
navigator.webdriverプロパティ (Playwright/Puppeteer はデフォルトでtrue)- User-Agent 文字列の
HeadlessChrome表記 - Permissions API の異常 (例:
notificationsがdenied固定) - WebGL / Canvas Fingerprint の一致性 (Playwright 標準環境は一意のパターン)
- Chrome 起動引数 (
--enable-automation等) の残骸
- レイヤー 2: 振る舞いパターン (Behavior)
- マウス移動の不自然さ (人間は曲線的、Bot は直線的)
- キーボード入力のタイミング (Bot は完全に等間隔)
- スクロール速度の異常 (一定速度 = 機械)
- ページ読み込み完了からアクション開始までの時間
- レイヤー 3: IP / ネットワーク信頼度
- データセンター IP (AWS / GCP / Vultr 等) は高リスク判定
- VPN プロバイダの公開 IP リストとの照合
- TLS / TCP 指紋 (JA3 / JA4 ハッシュ)
- IP の過去の不正使用履歴
- レイヤー 4: アカウントレベルの判定
- ログイン試行のパターン (新規 IP からの突発ログイン)
- 新規作成アカウントの即時利用
- 2 要素認証の有無 (なしは自動化と判定されやすい)
- 過去ログインデバイスとの不一致
4 層の すべて をクリアしないと Google OAuth は通りません。レイヤー 1 (指紋) だけ対策しても、レイヤー 3 (IP) で弾かれます。レイヤー 1-3 を完璧にしても、レイヤー 4 (新規 IP 異常検知) で警告画面が出ます。この 4 層は独立した防御線として機能していて、突破は理論的に可能でも実用には耐えません。
Puppeteer / Selenium / undetected-chromedriver を試した結果
Playwright で諦めた後、代替の自動化ツールも一通り試しました。結論は 全て同じ でしたが、参考までに比較結果を残します。
| ツール | 初回 OAuth 試行 | stealth 対策後 | 長期使用 |
|---|---|---|---|
| Playwright (デフォルト) | 即拒否 | 2-3日で対策 | 不可 |
| Puppeteer + puppeteer-extra-plugin-stealth | 一時通る | 2-3日で対策 | 不可 |
| Selenium WebDriver | 即拒否 | 同上 | 不可 |
| undetected-chromedriver (Python) | 一時通る (長め) | 1 週間程度 | 不可 |
| Real Chrome via DevTools Protocol | 条件付き通る | — | 条件付き |
undetected-chromedriver は他のツールより耐性があり、運が良ければ 1 週間程度持ちます。ただし長期運用には耐えず、定期的にメンテナンスが必要です。Google の検知ロジック更新の度に対策が必要で、本業の開発時間を食い続けます。
「Real Chrome via DevTools Protocol」は実物の Chrome ブラウザを CDP 経由で操作する手法で、最も検知されにくいですが、初回ログインに毎回手動操作が必要なので「全自動化」は実現できません。
テスト中ステータスの 7 日縛り問題
Google OAuth を諦めて「公式 API + refresh_token」方式に移行した後にも、もう 1 つ大きな罠がありました。Google OAuth Consent Screen の「テスト中」ステータスでは、refresh_token の有効期限が 7 日に強制制限される仕様です。
つまり初回手動 OAuth でトークンを取得しても、7 日後には自動的に失効、再認証が必要になります。本番運用するなら以下の選択肢が必要です。
- OAuth Consent Screen を「本番」ステータスに切り替え: Google による審査が必要 (機密スコープ使用時は最大 6 週間)、CASA 監査 + プライバシーポリシー + 利用規約の整備が必須
- 毎週手動で再認証: 個人運用なら現実的、ただし本人が忘れると Worker が止まる
- サービスアカウント方式 (Google Workspace): 一部のスコープのみ対応、組織管理者の権限委譲が必要
私の運用では YouTube アップロード Worker で「毎週月曜朝の手動再認証」を運用ルーチンに組み込んでいます。所要時間は 5 分、本人作業として確実に実行する仕組み (memory への永続化 + リマインダー) で運用しています。
業界統計 — Bot 検知の精度向上
Google だけでなく主要サービスの自動化検知精度は近年急速に向上しています (各社公式発表 + セキュリティ研究)。
- Cloudflare Bot Management: 2024 年時点で人間 / 自動化の判定精度 99% を公称、JS Challenge / Turnstile の組み合わせで突破困難
- Akamai Bot Manager: 200+ シグナルで判定、機械学習でリアルタイム更新
- Datadome / PerimeterX: 個人開発で遭遇する大手 SaaS で広く採用
- Imperva (旧 Distil Networks): e コマース系で標準採用
この傾向から、「自動化スクリプトで人間のフリをして大手サービスを操作する」アプローチは長期的に成立しないと判断しています。公式 API + 公式の認証フロー + 自動化ツール (例: GitHub Actions、各社公式 SDK) を使うのが現代の正解です。
個人開発での「自動化スコープ」判断基準
3 週間の Google OAuth トラップから学んだ「個人開発で自動化すべきもの / すべきでないもの」の判断基準は以下です。
| 判断軸 | 自動化 GO | 自動化 NG |
|---|---|---|
| 公式 API の有無 | API 提供あり | API なし or 認証強い |
| サービスの利用規約 | API 経由を明示的に許可 | Bot 禁止が明記 |
| 検知システムの強度 | 緩い (個人サイト等) | Cloudflare / 大手 SaaS |
| 長期メンテナンスコスト | 1 ヶ月以内に作って完了 | 毎週 stealth 対策必要 |
個人開発の自動化は「公式 API を使う or 諦める」の二択で考えるのが現実的です。「公式 API がないから Playwright で頑張る」アプローチは、3 週間後に「結局できなかった」という結果に終わる典型パターンです。
筆者: GRAMSHIFT — Instagram 自動運用 SaaS『GramShift』開発者、saas-diary.com / ai-pick.tech / lab.ai-pick.tech / host.ai-pick.tech 等 複数メディア運営。本記事内の試行錯誤記録 + 業界統計はすべて私が実際に検証 / 一次情報確認したものです。
次に読むなら
本記事の内容を踏まえて、以下のテーマに進むと理解が深まります。
よくある質問
undetected-chromedriver を使えば Google OAuth を通せますか?
一時的には通せますが、長期運用には耐えません。私の検証では undetected-chromedriver で 1 週間程度持ちましたが、Google の検知ロジック更新の度に対策が必要になり、メンテナンスコストが大きくなります。本業の開発時間を食い続けるため、最初から「公式 API + refresh_token」方式に切り替えるのが合理的です。
Google OAuth Consent Screen を「本番」に切り替えれば 7 日縛りは解消されますか?
はい、「本番」ステータスでは refresh_token の有効期限制限がなくなります。ただし機密スコープ (YouTube アップロード等) を使う場合は Google による審査が必要で、CASA 監査 (Cloud Application Security Assessment) + プライバシーポリシー + 利用規約の整備 + 申請から最大 6 週間の審査期間が発生します。個人開発で短期間に試したい場合は「テスト中」+ 毎週手動再認証の方が現実的です。
Playwright で Google 以外のサービスは自動化できますか?
Cloudflare Bot Management / Akamai Bot Manager 等を使っていないサービスなら可能です。具体的には、note (note.com) / アメブロ / 一部の独自運営サイトは Playwright で動きます。Threads / Instagram は Meta 系で検知が強化されており、note や YouTube ほどではないが慎重な運用が必要です。「公式 API があるか」「Bot 検知サービスを使っているか」を事前確認するのが必須です。
Google OAuth が必須な場合の最終手段は何ですか?
最終手段は「初回だけ手動でブラウザ操作して OAuth 認証を完了し、refresh_token を保存、以降は API でアクセス」のパターンです。これは Playwright で全自動化はできませんが、本人が初回 5 分の手動操作を許容できるなら最も確実です。YouTube アップロードや Gmail 操作はこの方式で長期運用可能です。「全自動 OAuth」を諦めて「初回手動 + 以降自動」の設計に切り替えるのが個人開発の現実解です。