PlaywrightのlaunchPersistentContextでログインセッションを永続化して自動投稿を安定させる

はじめに

Playwright で SNS や CMS への自動投稿を実装していると、「毎回ログイン画面を通すのが遅い・不安定」という問題に直面します。本記事では launchPersistentContext を使ってブラウザプロファイルを永続化し、一度ログインしたセッションを再利用する方法を整理します。

やりたいこと

• 初回だけ人間がログイン (パスワード・2FA・OAuth 同意)
• 以降は保存済みプロファイルを起動するだけでログイン済み状態を再現
• サービスごとにプロファイルを分離してアカウント混線を防ぐ

実装

import { chromium } from 'playwright';

const context = await chromium.launchPersistentContext('.session-service-a', {
  channel: 'chrome',        // 実Chromeを使う (検知回避 + 互換性)
  headless: false,          // 初回ログインはヘッド付きで
  locale: 'ja-JP',
  timezoneId: 'Asia/Tokyo',
});

const page = context.pages()[0] ?? (await context.newPage());
await page.goto('https://example.com/login');
// ここで人間がログイン → プロファイルにCookie/LocalStorageが保存される

2 回目以降は同じディレクトリを指定するだけでログイン状態が復元されます。

// 2回目: そのまま投稿画面へ
const context = await chromium.launchPersistentContext('.session-service-a', {
  channel: 'chrome',
  headless: true,   // 保存済みならヘッドレスでOK
});

ハマりポイント

1. storageState だけでは不十分なケース

context.storageState() で Cookie を JSON に書き出す方法もありますが、永続プロファイルの方が IndexedDB や Service Worker ごと保持できるため、SPA 系サービスでは安定します。

2. プロファイルロック

同じプロファイルを複数プロセスで同時起動すると ProcessSingleton エラーになります。サービスごとにディレクトリを分け、再起動時にロックファイルの残留を掃除する処理を入れておくと安全です。

3. OAuth の再認証

Google OAuth などを挟むログインは、セッションが生きていても consent 時にパスワード再入力を要求されることがあります。初回は必ず人間が通す前提の運用にしておくと詰まりません。

まとめ

• launchPersistentContext でプロファイルをディレクトリ永続化すれば、ログイン済み状態を使い回せる
• サービス × アカウント単位でプロファイルを分けるのが運用上のコツ
• 初回ログインは人間、以降は自動、という分担が最も安定

自動投稿パイプラインを組む際の参考になれば幸いです。