CLI 型のブラウザ自動化ツール（Playwright 系ラッパー等）でローカル画面をログイン済み状態で目視確認したいときの運用指針。

前提の落とし穴

• 自動化ツールが起動するブラウザは、普段使いのブラウザとは別インスタンスで、Cookie もセッションも共有しない。よって普段の画面のログイン状態はそのまま引き継がれない。
• 既定が使い捨て（in-memory）プロファイルのツールが多く、その場合は毎回未ログインから始まり、閉じると状態が消える。
• 既定がヘッドレス起動のツールもあり、ウィンドウが画面に出ない。手元で直接ログイン操作をしたいときはヘッドフル指定（ウィンドウ表示のフラグ）が必須。「ウィンドウが無い」と感じたらまずヘッドレス既定を疑う。

採用する運用

• プロジェクトごとに分けず、確認用の名前付きセッション＋固定ディレクトリの永続プロファイルを1つ用意し、全プロジェクトで使い回す。理由: ローカルの目視確認が主目的ならアカウントを使い分ける必要は薄く、管理が単純になる。将来「特定案件だけ別アカウント」が必要になったら、その時だけ別プロファイルを足せばよい（最初から作り込まない、可逆・最小から始める）。
• 一度そのプロファイルでログインすれば Cookie がディスクに残り、以後はログイン済みで開ける。ログイン操作自体（特にパスワード入力）は人が行う。
• 実ブラウザチャンネルを指定できるなら指定すると、OS キーチェーン由来の暗号化 Cookie を扱え、UI 差異も減って確認向き。

除外・注意

• 普段使いの本番プロファイルを直接指定する方式は、プロファイルの排他ロックで普段のブラウザを完全終了する必要があり、自動化フラグによる汚染リスクもあるため避け、コピーか専用プロファイルにする。
• プロファイルディレクトリや state 保存ファイルには認証トークンが入るので、バックアップや VCS 管理の対象にしない。

認証できているかの確認方法

認証必須のルートへアクセスし、ログイン画面へリダイレクトされない（目的ページがそのまま表示される）ことをもって認証済みと判定する。生の Cookie 値やトークンをダンプして確かめる必要はなく、リダイレクト挙動だけで十分。