2026 Perplexity Cometの自動化がログイン画面で止まる？開発者向け再現ガイド

ログイン画面で停止したら、まずユーザーの許可や手動操作が必要な状態かを確認し、その後、専用のテストアカウントでセッションとページ操作を切り分けてください。ログイン画面で止まることだけでは、サイトとの非互換を意味しません。画面の停止位置とブラウザーからの案内を記録してから原因を判断します。

フロントエンドエンジニアは、ログイン後のページで起きる異常を再現したいときに活用できます。
QA担当者は、アカウント状態やページ条件をそろえた検証手順を作る際に役立ちます。
プロダクトチームは、どの操作をユーザー確認に戻すべきかを決める材料にできます。

※最終更新日：2026年10月1日。Perplexityの公式案内と、本文中にリンクした認証・セッション管理の資料を確認しています。製品の操作方法や権限表示は更新されることがあるため、実際の画面で再確認してください。

公開ページを基準にして、指示と停止位置を記録する

いきなりログインが必要なページから検証すると、原因が認証なのか、タスクの伝え方なのか、ページ表示なのか判別しにくくなります。まずアカウント不要の公開ページで、内容の読み取りと通常のリンク移動を試し、後続の検証と比べる基準を作ります。

記録には、ブラウザーのバージョン、ページのURL、入力した指示、実際に止まった画面を含めます。指示は「ページを開く」「指定された内容を確認する」のように、観察できる操作に分けてください。「必要な作業をすべて終わらせる」だけでは、どの段階で期待と異なったか追いにくくなります。

Perplexityの公式案内では、Cometのアシスタントがブラウザー上の作業を支援する機能や、ユーザーが操作を管理する考え方が説明されています。ただし、特定のサイトでログインや操作が必ず完了するという保証とは分けて読みます。アシスタントの権限とユーザーによる管理についての公式説明とCometの公式利用案内を照合し、画面に実際に表示された指示を優先してください。

なぜPerplexity Cometはログイン画面で止まるのか

停止の見え方が似ていても、原因は一つとは限りません。少なくとも次の可能性を分けて記録します。

• ユーザーの引き継ぎが必要な状態： ログイン、権限の許可、本人による確認などを求められていないか確認します。案内が出ている場合は、その指示どおりユーザーが操作した前後を記録します。
• 認証情報やセッションの状態： 未ログイン、期限切れ、利用可能なテストセッションでは、遷移先や表示内容が異なることがあります。リダイレクト先と画面の変化を見比べます。
• ページ側の表示・操作条件： 読み込み待ち、モーダル、画面上の要素の重なり、ユーザー操作を起点にした表示変化が、次の操作を妨げていないか確認します。
• サイト側の制約： CAPTCHAや追加認証が出た場合は、回避を試みず、ユーザー確認が必要な工程として扱います。

Cometのログイン能力や引き継ぎ動作は、製品側の更新やサイトごとの実装で変わる場合があります。公式案内にある機能説明だけから、特定のログインページでの対応範囲を断定しないでください。

テストアカウントでログイン後の状態を比べる

ブラウザーのログイン状態を検証するときは、実在する利用者のアカウントではなく、許可された専用のテストアカウントを使います。氏名や住所などの入力が必要なら架空のテスト用情報に限定し、実際のパスワード、Cookie、セッショントークンを実行ログやスクリーンショットに残さないようにします。

比較対象は、ログイン済み、未ログイン、期限切れの3状態に分けると、同じページでセッションの違いを確認できます。セッション管理のセキュリティ指針を参考に、状態ごとにリダイレクト先や認証後の表示を記録してください。1回の実行で変える条件は一つに絞ると、どの変更が結果に影響したか追いやすくなります。認証情報を使うブラウザーテストの説明も、テスト用の認証状態を管理する際の参考になります。

CAPTCHAが表示されたら、認証を突破する自動化を試さず、手動確認が必要な地点として扱ってください。自動テスト向けの方法が用意されている場合も、対象サービスの公式手順とテスト環境の範囲内で利用します。自動テスト向けCAPTCHAの案内

テストアカウントでログイン後の流れを確かめる

次の手順で、ブラウザーのログイン状態テストを再現します。

1. 公開ページを使った基準テストの結果を保存します。
2. 専用アカウントの権限と、検証に使ってよいページを確認します。
3. ログイン済み・未ログイン・期限切れの状態を準備し、認証情報そのものは記録しません。
4. URL、タスク指示、アカウント状態をそろえ、各状態で同じ操作を実行します。
5. ログイン画面への遷移、ユーザーへの案内、その後の画面を記録します。
6. タブをまたぐ操作がある場合は、同じ条件のまま別タブで再現し、セッションや遷移先の違いを確認します。
7. 変更した条件と再実行の結果を残し、認証、権限、ページ状態、サイト側の操作条件に分類します。

認証失敗の記録を扱う際は、秘密情報をログに出さない設計も確認します。認証に関するセキュリティ推奨事項を参照し、テスト用アカウントの管理方法をチームで決めてください。

CAPTCHAが出た場合は、突破ではなく引き継ぎを検証する

「AIブラウザーでログイン時のCAPTCHAをどうテストするか」という課題では、自動入力できるかではなく、検出後に安全に停止し、ユーザーへ判断を戻せるかを確かめます。テストでは、CAPTCHAの表示前、表示中、手動確認後の状態をそれぞれ記録し、画面の変化とアシスタントの案内を残します。

非同期で読み込まれるCAPTCHAは、ページの初期表示時点ではまだ現れていないことがあります。CAPTCHAの読み込みに関する公式ドキュメントを参考に、画面が表示された瞬間だけでなく、読み込み後に要素が現れるかも確認します。認証を迂回する試行や、実利用者の認証情報を使った検証は行いません。

動的ページは、表示・操作・確認の順に切り分ける

SPA、遅延読み込みの一覧、ポップアップを含む画面では、表示が整う前に次の操作へ進んでいないかを確認します。「ページを開けたか」だけで判断せず、失敗した操作の直前と直後の状態を分けて記録します。

• 要素が表示されない： 読み込み待ちなのか、未ログインによる非表示なのか、表示条件が未成立なのかを確認します。
• 要素が見えるが操作できない： モーダルや別要素に覆われていないか、操作の前提となる入力や選択が済んでいるかを見ます。
• 操作後に状態が変わらない： 保存通知、画面遷移、エラー表示など、操作が受理されたことを示す変化があるか確認します。

スクリーンショットを共有するときは、アカウント名や個人情報を隠します。遅延読み込みのページでは、読み込みタイミングによって要素の有無が変わる場合があるため、ページの状態と実行した指示を一緒に残してください。動的ページの問題を「Cometが操作できない」とだけ報告せず、どの画面で、何が見えず、直前に何を操作したかまで記述します。

変更や送信を伴う操作は、ユーザー確認までを合格条件にする

フォーム送信、登録情報の変更、注文に関わる操作などは、完了率だけで合否を決めません。自動化が確認前に処理を確定していないこと、確認が必要な場面でユーザーへ引き継げること、誤操作があった場合に取り消しや復旧ができることを確認します。

「入力内容の確認」までは進み、その後の送信は利用者へ戻す、といった境界をテストケースに明記してください。確認画面がない場合や取り消し手段が用意されていない場合は、自動処理の成否よりも、ページ設計上のリスクとして報告します。

条件分岐で原因と次の対応を決める

再現結果を次のチェック項目に当てはめると、原因の分類と次の対応を決めやすくなります。該当する項目にチェックを付け、判断に迷う場合は一つ前の条件に戻って比較してください。

• [ ] 公開ページでも読み取りやリンク移動に失敗する： 指示、読み込み、画面上の要素を見直し、認証以外の再現条件を記録します。
• [ ] 公開ページは動くが、ログイン時に引き継ぎ案内が出る： 故障と決めつけず、ユーザー操作が必要な工程として記録し、案内後に状態が変わるか確認します。
• [ ] 有効なテストセッションでは動き、期限切れ状態だけ失敗する： セッションの違いによる結果として分類し、秘密情報なしで再現できる手順を共有します。
• [ ] 表示済みの要素を操作できない： 遮蔽、ページ状態、操作の前提条件を調べ、該当画面の情報を添えてサイト側の問題として切り分けます。
• [ ] 送信や変更の確定前に確認できない： 自動化の成功とは扱わず、ユーザー確認と取り消し経路を含む改善課題として扱います。

この分岐を使えば、Perplexity Cometの機能制限、ユーザーの権限要求、サイトの状態、画面操作の問題を同じ「ログイン失敗」にまとめずに済みます。

チームで使い回せる再現記録を残す

再現記録には、ブラウザーのバージョン、ページURL、テストアカウントの状態、実行前のページ条件、入力した指示、停止位置、画面に表示されたユーザー向け案内、再実行時の変更点を含めます。認証情報や個人情報は記録から除外し、共有が必要な画像やログはマスキングしてから保管します。

再現しない場合も「問題なし」とだけ書かず、どの状態で何を試したかを残してください。プロキシーなど通信経路の制約が疑われるなら、ページの表示不良やセッション期限切れとは別の項目に分けます。ログイン状態やページ条件をそろえた再現環境を継続して使うなら、手元の端末だけで条件を保つ方法と、Macを使った独立環境のどちらが運用に合うかを比べます。

手元の環境だけで試すと、端末の共有状態や設定差が記録に残りにくく、別の担当者が同じ条件を作り直しにくいことがあります。一方、長時間の常時負荷があるテストや、物理ポート・周辺機器への接続が前提なら、レンタルは適しません。専用アカウントでの短期的な再現や、チームで条件を分けて確認する目的なら、Mac環境を独立させられるかを検討し、日本向けMacレンタルの案内で利用条件を確認してください。利用前の疑問はヘルプセンターで確認できます。まずは機密情報を含まないテストアカウントで一度再現記録を作り、その条件を維持できる場合に限って、ZavCloudのMacレンタルを検証環境の選択肢に加えると判断しやすくなります。