ログインして閲覧できる画面でも、自動取得して保存・共有する用途まで認められているとは限りません。スクリプトを書く前に、取得する情報、使うアカウント、保存先、実行方法を具体化します。
閲覧できる範囲と、自動取得してよい範囲を同じものとして扱わないことが、最初の確認点です。ログイン方法を実装した後でこの判断を始めると、不要な認証情報やデータまで扱うことになります。
取得する情報と用途を先に書く
例えば、社内で管理権限を持つシステムから、自分の担当部門の集計を取得したい場面を考えます。これは仮定の例で、特定サービスの許可を意味しません。
対象画面の名前、必要な項目、対象期間、件数、実行頻度、誰に渡すかを書き出します。顧客一覧全体が必要なのか、担当部門の合計だけで足りるのかによって、取得範囲は変わります。画面に見える全ての情報を、そのまま保存する設計から始めないようにします。
公式の取得方法を確認する
管理画面のCSV出力、データ連携機能、公式APIがあれば、目的の項目を取得できるか調べます。APIを使う場合も、認証、権限の範囲、利用制限、データの扱いは確認が必要です。APIという形式だけで全用途が許可されるわけではありません。
自動取得に関する利用条件や管理者の案内で、対象、頻度、アカウントの利用方法を確認します。条件が判断できない場合は、取得方法と用途を示して運営元や管理者へ確認する段階です。robots.txtの許可・禁止だけで、ログイン後のアクセス権やデータ利用の可否を判断しません。
認証状態をコードと一緒に配らない
Playwrightなどは認証後の状態をファイルへ保存して再利用できます。便利な一方、そのファイルには本人やテストアカウントとして操作できるCookieやヘッダーが含まれることがあります。公式資料も非公開・公開どちらのリポジトリにも認証状態を登録しないよう注意しています。
保存の必要がある場合は、保管場所、アクセスできる人、有効期限、失効時の処理を決めます。パスワードが入っていないJSONだから共有してよい、という判断はできません。ログやスクリーンショットにも、氏名、連絡先、トークンが写り込む可能性があります。
このページには認証状態を取得するコードや実際の認証情報を載せていません。手順を共有する際は、秘密を含まない設定例と、認証情報を別に用意する方法を分けます。
追加認証や拒否で止まる条件
多要素認証、CAPTCHA、アクセス拒否、アカウントロックの兆候が出たら、想定した手順で取得できていない状態です。別アカウントや経路へ自動で切り替えて継続する構成にせず、取得方法と権限を確認します。
ログイン成功の判定には、URLだけでなく、そのアカウントで期待する画面と対象範囲が見えることを使います。HTTP 200でもログイン画面が返る場合があるため、取得件数ゼロを通常の空データと同じ扱いにしないようにします。
運用を始める判断を残す
実行する前に、確認した取得条件の参照先と確認日、アカウントの管理者、対象項目、保存先、停止条件を記録します。担当者が変わった後も、なぜこの方法と範囲なのかを見直せる形です。
ログイン後の画面で動くことを確かめる作業は、許可されたテスト環境とアカウントで行います。認証できた事実、対象データを正しく取得した事実、業務で利用してよい判断を、それぞれ確認してから運用へ進めます。
関連する作業
取得前の条件確認と、ログインを使わないローカルのブラウザー練習は次の記事で確認できます。
