Webサイトの自動ログインがブロックされる理由【reCAPTCHA・Cookie暗号化を実例で解説】

1. きっかけ：記事投稿の自動化を試みた

あるコンテンツ投稿サービスに、AIエージェント経由でブラウザ自動化ツール（Playwright）を使ってログインし、記事を下書き保存するところまで自動化しようとしました。ログインフォームの構造自体は簡単に確認できました。

<input placeholder="mail@example.com or note ID">
<input type="password">
<button>ログイン</button>

フォームにメールアドレスとパスワードを入力し、ログインボタンをクリックするだけの、一見単純な処理です。

2. 第一の壁：フォーム自動入力がブロックされる

実際に自動入力→クリックを実行すると、ログインには成功せず、フォーム下に赤字でこう表示されました。

パスワード自体は合っていましたが、ログインは拒否されました。画面右下にはreCAPTCHAのバッジも表示されており、これはreCAPTCHAやそれに類するbot検知の仕組みが、機械的なフォーム送信を検知してブロックしたと考えられます。

典型的な自動化コードは、値の入力が一瞬（人間のタイピング速度ではなくミリ秒単位）で行われ、マウスの動きやスクロールといった人間らしい操作の痕跡もありません。多くのサービスはこうした挙動を機械的にスコアリングして、怪しいと判断したアクセスを制限します。

3. 第二の壁：Cookieを再利用してもログイン状態にならない

フォーム経由のログインを諦め、次に試したのが「既にログイン済みのブラウザのセッション（Cookie）を再利用する」方法です。手順は次の通りです。

1. 普段使っているブラウザで手動ログインする（人間の操作なのでreCAPTCHAも問題なく通過）
2. そのブラウザのプロファイル（Cookie等が保存されたフォルダ）をコピーする
3. 自動化ツールでそのプロファイルを読み込んで起動する

実際にCookieがディスク上に存在することも確認しました。

note.com関連Cookie件数: 11
('.note.com', '_note_session_v5', is_secure=1, is_httponly=1, ...)
('.note.com', 'note_gql_auth_token', is_secure=1, is_httponly=0, ...)

セッションを維持するためのCookieは確かに存在しています。ところが、このプロファイルを使って自動化ツールでサイトを開いても、画面右上には「ログイン」ボタンが表示されたままでした。ログイン状態は復元されませんでした。

4. なぜCookieをコピーしても復元できないのか

ブラウザ（特にmacOS版のChrome）は、Cookieの値をそのまま平文でディスクに保存しているわけではありません。OSのキーチェーン（Keychain）に保存された鍵を使って暗号化しています。

プロファイルのフォルダ自体をコピーしても、そのCookieを正しく復号する処理は、元のブラウザプロセス・OSのキーチェーンアクセス権限と密接に結びついています。単純なファイルコピーだけでは、この暗号化の連鎖が保たれず、サービス側からは「有効なセッションではない」と判断されてしまうと考えられます。

加えて、セキュリティに敏感なサービスほど、Cookieの値だけでなく、接続元のIPアドレスや端末の特徴（フィンガープリント）も含めてセッションの正当性を検証している可能性があります。これも、別プロセスから同じCookieを持ち込んだだけでは通用しない理由の一つです。

5. この経験から分かること

今回の一連の失敗は、裏を返せば「アカウント乗っ取りや自動なりすましを防ぐ仕組みが、実際にきちんと機能している」ことの証明でもあります。

• reCAPTCHA・bot検知：機械的なフォーム送信パターンを検知し、短時間の連続試行を制限する
• Cookieの暗号化：ファイルをコピーするだけでは、他のプロセスからセッションを乗っ取れないようにしている

逆の立場（自分がサービスを運営する側）で考えると、こうした多層防御は参考になります。ログインフォームにレート制限をかける、Cookieを保存する際は暗号化する、といった対策は、今回のような素朴な自動化の試みすら防げるほど効果があるということです。