アカウント登録を最初から最後まで実行すると境界が見えます。フォーム入力、日付選択、メールの認証コード取得は自動化できますが、動画セルフィー認証で止まります。完全自動化を追うより、各レイヤーのコスト差を理解する方が現実的です。
ブラウザ自動化に取り組む人は、工程を十分細かく分解すれば自動化できない処理はない、と考えがちです。
しかし一連のフローを最初から最後まで実行すると、事情は変わります。前半は驚くほど順調でも、最後に越えられない壁へぶつかることがあります。あるアカウント登録の実測では、フォーム入力、日付選択、認証コードの取得、セキュリティチェックまでを1分未満で完了でき、自動化率は約85%でした。残ったのは、カメラの前で本人が行う動画セルフィー認証です。
このフローをコストごとに分けて見ると、境界は想像以上にはっきりします。
1ページ内の決定的な操作は、スクリプトでほぼ安定して処理できる
氏名、メールアドレス、パスワード、生年月日のような入力は最も安定したレイヤーです。各フィールドの間に少し間隔を置いてキーボード入力を再現すれば、全体でおよそ5秒です。
唯一の落とし穴は要素の特定です。最近のフロントエンドでは、意味のある name 属性を持たない入力欄も多く、インデックスやDOM構造で取得する必要があります。きれいな書き方ではありませんが、自動化ではかえって安定することがあります。
これが第1のタイプです。ページ構造が固定され、操作が明確で、結果を予測できる処理です。この範囲にある操作は、スクリプトの成功率が高くなります。
カスタムコンポーネントでは、ページ構造そのものがコストになる
生年月日や性別のようなドロップダウン選択は、実際には時間を使う部分です。
見た目は通常の選択メニューでも、内部はアクセシビリティロールを使ったカスタムコンポーネントかもしれません。すると一般的な方法が次々に失敗します。標準の選択操作が効かず、アクセシビリティラベルで特定できず、対象要素への直接クリックも通らないことがあります。安定するのは、人間の操作順序をそのまま再現する方法です。ドロップダウンを開き、選択肢の描画を待ち、テキストで対象を見つけてクリックします。
コード自体は数十秒で書けても、デバッグに数時間かかる場合があります。このレイヤーの限界は技術力だけでなく、ページ構造がどれだけ協力的かに左右されます。カスタムコンポーネントに遭遇したら、通常の方法に固執しない方が時間を節約できます。
サイトをまたいで状態を維持すると、コストが明確に上がる
認証コードがメールに送られる工程のロジックは単純です。受信箱を開き、最新メールを見つけ、数字のコードを抽出し、入力欄へ戻します。全体でおよそ20秒です。
問題も複雑ではありませんが、起こりやすいものです。古いメールを読んでしまうとコードが違うため、時刻を基準に必ず最新の1通を取得する必要があります。
その後、多くのプラットフォームは追加の確認ページへ遷移し、新しいコードをもう一度送ります。処理ロジックは再利用できますが、前のコード値は使い回せません。
本当に面倒なのは、2つのサイトと2つのセッションが関わることです。メール側のログイン状態を維持し、プラットフォーム側のセッションを複数工程にわたって保持し、さらにプロキシIP、タイムゾーン、言語を環境と一致させる必要があります。サイト間の状態維持コストは、このように少しずつ積み上がります。各工程だけを見れば難しくなくても、つなげると失敗率が明らかに上がります。
ここでスクリプトは単なる実行役です。サイトからどのような識別情報で見えるかを自分で決めることはできません。デバイスフィンガープリントや、IPと環境が一致しているかどうかは、プラットフォームが判断に使う要素です。そのため複数アカウントを扱うチームは、環境分離を独立したレイヤーにすることがよくあります。各環境に独立したフィンガープリントとIPを持たせます。PurpleMarkのようなツールが担うのはこの環境レイヤーで、スクリプトはその内部で操作を実行します。
ページを理解する必要がある作業は、純粋なスクリプトでは分岐で耐えるしかない
さらに進むと、問題の性質が変わります。
ページの文言や構造がアカウント、地域、段階的な実験によって変わる場合、固定したセレクタはまとめて壊れます。選択肢は2つです。考えられる分岐をすべてコードに追加して保守を難しくするか、ページの意味を理解できるモデルにその工程を任せるかです。短い案内文やボタンの意味は人にとって常識でも、セレクタにとってはノイズです。
プラットフォーム側が能動的に変わると、純粋なスクリプトは何度でも使えなくなる
見落としやすいコストがもう1つあります。相手側も動き続けることです。
プラットフォームが見ているのは、フォームを埋められるかどうかだけではありません。デバイスフィンガープリントが自然か、IPとデバイス環境が一致しているか、動作が人間らしいか、一括操作の兆候がないか、といった点を確認することがあります。リスク管理が1回更新されるだけで、昨日まで動いたセレクタや操作パターンを作り直す必要が出るかもしれません。
つまり純粋なスクリプト方式には、本当の意味で「完成する日」がありません。一度納品して終わる仕組みではなく、継続的に追随する保守作業です。
顔認証のような工程は、単なる技術問題ではない
最後の関門は、本人がカメラの前で行う認証です。自動化はここで止まります。
スクリプトはフォーム入力、ボタンクリック、メールの読み取り、認証コード入力はできますが、人の生体特徴を必要とする操作を正当に代行することはできません。理由は技術不足だけではありません。この認証自体が、画面の前に実在する人がいることを確認するためのものであり、自動化の目的と正面から衝突するからです。顔認証を自動で通過できると主張する方法は、偽造した生体情報を伴うことが多く、コンプライアンスや法的リスクが得られる利益を大きく上回ります。
また、技術的に可能な工程でも、プラットフォームの利用規約で許可されているかを確認する必要があります。多くのプラットフォームは自動登録を明確に制限しています。これは技術力ではなく、ルール上の制約です。
結論は完全自動化ではなく、レイヤーごとにツールを選ぶこと
このフローをレイヤーごとに整理すると、選択は明確になります。
- ページが固定され、操作が決まっている処理はスクリプトに任せる。最も低コストで安定します。
- サイトをまたいでログイン状態やセッションを維持する必要がある場合は、ブラウザ環境を独立したレイヤーとして管理し、環境問題とスクリプトの不具合を混同しないようにします。
- ページ構造が固定されず、意味の理解によって次の操作を判断する必要がある場合は、コードに分岐を積み上げるよりモデルへ任せる方が実用的なことがあります。
- 実在する人が必要な工程や、利用規約で明確に禁止されている工程は、エンドツーエンド自動化を無理に行わないようにします。
まず全工程を手動で一度通し、越えられない箇所があるか確認してから、どれだけ開発へ投資するか決めるべきです。自動化の費用対効果が高いのは、反復的で、結果が決まり、判断を必要としない操作です。
