← ブログに戻る
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

セッション管理によるパースと自動化：12時間以上セッションを維持する方法

長寿命セッションの設定に関する完全ガイド：プロキシの選択、ブラウザの構成、接続切断の問題解決。

📅2026年2月10日
```html

あなたがマーケットプレイスのパースを夜間に実行したり、Facebook Adsアカウントを8時間ファーミングしたり、Instagramでの大量投稿を自動化したりしている場合、セッションの切断の問題に直面したことがあるでしょう。プロキシがIPを変更し、ブラウザがクッキーを失い、スクリプトが3時間目で落ちてしまいます。このガイドでは、数時間から24時間まで停止せずに動作するタスクのために、安定した長寿命セッションを設定する方法を説明します。

セッション管理とは何か、なぜ必要なのか

セッション管理とは、あなたのツール（ブラウザ、スクリプト、ボット）とターゲットサービスとの接続状態を長期間にわたって管理することです。短時間のタスク—5分で100商品をパースする場合—にはそれほど重要ではありません。しかし、タスクが数時間にわたって実行される場合、次のものを保持することが重要です:

  • 同じIPアドレス — サイトがデバイスの置き換えを疑わないように
  • クッキーとlocalStorage — 認証とアクションの追跡のため
  • ブラウザのフィンガープリント — デバイスの特性のセット（User-Agent、画面解像度、WebGL）
  • スクリプトの状態 — どのページが処理されたか、エラー時にどこで停止したか

プロセス中に少なくとも1つのパラメータが変更されると、サイトはアカウントをブロックしたり、CAPTCHAのパースを中断したり、認証セッションをリセットしたりする可能性があります。

一般的な長時間タスク: Facebook Adsアカウントのファーミング（6-12時間のウォームアップ）、Wildberriesのカテゴリ内のすべての商品をパース（3-8時間）、50のInstagramアカウントへの大量投稿（遅延を含む4-10時間）、競合他社の価格の24/7モニタリング。

長時間セッションの一般的な問題

長寿命セッションを破壊し、タスクを停止させる原因となる一般的な問題を見ていきましょう:

1. プロキシのIPアドレスのローテーション

多くのプロキシサービスはデフォルトで5-15分ごとにIPを変更します。認証なしでのパースには問題ありませんが、Facebook Adsアカウントにログインしている場合、セッションの途中でモスクワからサンクトペテルブルクにIPが変更されると疑念を抱かれます。プラットフォームはログイン確認を要求し、電話にコードを送信するか、疑わしい活動のためにアカウントをブロックします。

解決策: スティッキーセッション（Sticky Sessions）を使用する — プロキシが10分、1時間、または24時間の間、同じIPを提供するモードです。詳細は以下のセクションで説明します。

2. プロキシ側の接続タイムアウト

一部のプロキシプロバイダーは、10-30分間アクティビティがないと接続を切断します。スクリプトがアクションの間に一時停止する場合（例えば、人間を模倣して5分間商品を見てから次に進む場合）、プロキシが接続を閉じる可能性があります。作業を再開しようとすると、スクリプトはエラーを受け取り、落ちてしまいます。

解決策: keep-aliveリクエストを設定する（プロキシに2-3分ごとにpingを送信する）か、厳しいタイムアウトのないプロバイダーを選択します。レジデンシャルプロキシやモバイルプロキシは通常、データセンターよりも長く接続を維持します。

3. ブラウザのフィンガープリントの変更

アンチデテクトブラウザを再起動するか、スクリプトが新しいブラウザのインスタンスを作成すると、フィンガープリントが変更されます。同じIPを使用しても、サイトはUser-Agent、画面解像度、フォントリスト、またはキャンバスフィンガープリントが前回のセッションと異なることを認識します。これは不正防止システムをトリガーします。

解決策: ブラウザのプロファイルを保存する（Dolphin Anty、AdsPower、Multiloginでは自動的に行われます）し、毎回新しいものを作成しないようにします。SeleniumやPuppeteerを使用している場合は、クッキーや設定を含むUser Data Directoryを保存します。

4. エラー時のスクリプト状態の損失

スクリプトが6時間パースし、10000商品のうち8000商品を処理した後、ネットワークエラーで落ちてしまいました。進行状況を保存しないと、最初からやり直す必要があります。これは特に12時間以上のタスクにとって重要です。

解決策: 中間結果をデータベースまたはファイルにN回の反復ごとに保存します（例えば、100商品ごと）。再起動時にスクリプトは最後に保存した位置から続行します。

長時間タスクに適したプロキシ

すべてのプロキシタイプが長時間セッションに同じように適しているわけではありません。以下は、安定性とIPの寿命に関する比較です:

プロキシタイプ IPの寿命 安定性 適している用途
データセンター 無制限（静的IP） 高いが、簡単に検出される 認証なしのパース、価格モニタリング
レジデンシャル 10分〜24時間（スティッキーセッション） 中程度（プロバイダーによる） アカウントのファーミング、認証付きのパース
モバイル 5-30分（オペレーターのタイマーによる変更） 低い（頻繁なIP変更） 短時間のソーシャルメディアタスク、厳しいブロックの回避
ISPプロキシ 無制限（静的レジデンシャルIP） 非常に高い 認証付きの長時間タスク、プレミアムアカウントのファーミング

選択に関する推奨事項:

  • 認証なしのマーケットプレイスのパース（Wildberries、Ozon、Yandex.Market）には、静的IPのデータセンターが適しています。安価で高速で、サイトがデータセンターを厳しくブロックしない限り、12時間以上のタスクに対応できます。
  • Facebook Ads、TikTok Ads、Google Adsのアカウントのファーミングには、スティッキーセッションで24時間のレジデンシャルまたはISPプロキシのみが適しています。モバイルは頻繁なIP変更のため適していません。
  • Instagram、TikTokの自動化には、1-6時間のスティッキーセッションを持つレジデンシャルプロキシが適しています。短時間のタスク（1時間で10アカウントへの投稿）にはモバイルも適しています。
  • 24/7のモニタリング（競合他社の価格追跡、ニュースのパース）には、ISPプロキシまたはデータセンターが適しています。サイトがそれらをブロックしない場合。

重要: モバイルプロキシは長時間タスクには適していません！ IPは5-30分ごとにモバイルオペレーターのタイマーによって変更され、これを制御することはできません。短時間のタスク（アカウントの登録、一度限りの投稿、CAPTCHAの回避）にのみ使用してください。

スティッキーセッション: 24時間IPを固定する方法

スティッキーセッション（Sticky Sessions）とは、指定された時間（10分、1時間、6時間、または24時間）の間、同じIPアドレスを取得するプロキシの動作モードです。これは認証付きのタスクにとって重要です。

スティッキーセッションの仕組み

通常、スティッキーセッションはプロキシのURL内のセッションIDを介して実現されます。標準の形式の代わりに: 

http://username:password@proxy.example.com:8000

あなたはセッションパラメータを追加します: 

http://username-session-mysession123:password@proxy.example.com:8000

これで、mysession123という識別子を持つすべてのリクエストは、セッションの寿命が切れるまで同じIPを通過します（通常、デフォルトでは10-30分）。より長いセッションが必要な場合、プロバイダーは時間パラメータを提供することがあります: 

http://username-session-mysession123-lifetime-1440:password@proxy.example.com:8000

ここで、lifetime-1440は1440分（24時間）を意味します。

人気サービスでのスティッキーセッションの設定

レジデンシャルプロキシ: ほとんどのプロバイダーは、ユーザー名のパラメータを介してスティッキーセッションをサポートしています。プロバイダーのドキュメントで形式を確認してください。一般的なオプション:

  • username-session-ABC123 — デフォルトの時間（10-30分）でIPを固定
  • username-session-ABC123-sessionduration-60 — 60分間固定
  • username-country-us-session-ABC123 — アメリカのIPを固定

ISPプロキシ: 通常、デフォルトでIPは静的で、スティッキーセッションは必要ありません — 手動でプロキシを変更しない限り、常に同じアドレスを取得します。

データセンター: IPは静的で、追加の設定は必要ありません。

アンチデテクトブラウザでの使用例

例えば、Dolphin AntyでFacebook Adsアカウントをファーミングしているとします。タスクは8時間のウォームアップ（サイトの遷移、動画の視聴、いいね！）です。設定は次のとおりです:

  1. Dolphin Antyでブラウザのプロファイルを開く
  2. 「プロキシ」セクションに移動
  3. タイプを選択: HTTPまたはSOCKS5
  4. プロキシのホストとポートを入力
  5. 「ログイン」フィールドに次のように指定: username-session-farm001-sessionduration-480（480分 = 8時間）
  6. パスワードを入力
  7. 「プロキシを確認」をクリック — IPが認識されることを確認
  8. プロファイルを保存

これで、8時間の間、このプロファイルからのすべてのリクエストが同じIPを通過します。ブラウザを閉じて1時間後に再度開いても、同じセッションID（farm001）を使用すれば、同じIPを取得します。

アドバイス: タスクに関連するわかりやすいセッションIDを使用してください。例えば、farm-fb-account-001、parse-wb-electronics。これにより、並行して多数のタスクがある場合のデバッグが簡単になります。

長時間セッションのためのアンチデテクトブラウザの設定

アンチデテクトブラウザ（Dolphin Anty、AdsPower、Multilogin、GoLogin、Octo Browser）は、長寿命セッションを保持するために特に設計されています。しかし、8時間以上のタスクにとって重要な設定のニュアンスがあります。

1. ブラウザプロファイルの保存

ブラウザプロファイルは、クッキー、localStorage、フィンガープリント（User-Agent、キャンバス、WebGL、フォント）のセットです。すべてのアンチデテクトブラウザは、閉じるときにプロファイルを自動的に保存します。重要なのは、タスクを実行するたびに新しいプロファイルを作成しないことです！

正しいアプローチ:

  • 特定のタスクのためにプロファイルを一度作成する（例えば、「FBアカウントのファーミング #1」）
  • スティッキーセッションのプロキシを設定する
  • 最初の実行を行い、アカウントにログインする
  • ブラウザを閉じる — プロファイルが保存される
  • 次回の実行時には同じプロファイルを開く — 認証とフィンガープリントが保存される

間違ったアプローチ:

  • 同じタスクのために毎日新しいプロファイルを作成する
  • 実行間でクッキーを手動で削除する
  • タスクの途中でフィンガープリント（User-Agent、画面解像度）を変更する

2. 安定性のためのフィンガープリントの設定

長時間のタスクには、プロキシに対応したリアルなフィンガープリントを選択してください。プロキシがロシア（モスクワ）からの場合、英語ロケールのMacBook ProのUser-Agentを設定しないでください。より良いのは:

  • OS: Windows 10または11（ロシアで最も人気）
  • ブラウザ: 最新版のChrome（アンチデテクトで自動的に更新）
  • 画面解像度: 1920x1080（最も一般的）
  • 言語: ru-RU、タイムゾーン: Europe/Moscow
  • WebRTC: 無効にするか、プロキシのIPに置き換える（実際のIPが漏れないように）

Dolphin AntyやAdsPowerには「ランダムフィンガープリントを作成する」機能があります — これは信頼性のあるパラメータの組み合わせを生成します。長時間のタスクには、手動で設定するよりも安全です。

3. 自動更新と再起動の無効化

タスクが12時間動作する場合、次のことを確認してください:

  • コンピュータがスリープモードに入らないようにする（Windows/macOSの電源設定でオフにする）
  • ウイルス対策ソフトが更新のためにシステムを再起動しないようにする（更新を延期する）
  • アンチデテクトブラウザがタスクの途中で自動的に更新されないようにする（設定で自動更新を無効にするか、夜間に設定する）

4. 自動化のためのアンチデテクトブラウザのAPIの使用

Dolphin Anty、AdsPower、Multiloginは、スクリプトからプロファイルを管理するためのAPIを提供しています。これにより、次のことが可能になります:

  • Python/Node.jsスクリプトからブラウザプロファイルを起動する
  • SeleniumやPuppeteerを介して接続する
  • 長時間のタスクを実行する
  • 完了時にプロファイルを自動的に閉じる

APIを介してDolphin Antyプロファイルを起動する例（Python）: 

import requests
from selenium import webdriver

# Dolphin Antyを介してプロファイルを起動
profile_id = "123456"
response = requests.get(f"http://localhost:3001/v1.0/browser_profiles/{profile_id}/start")
data = response.json()

# Seleniumを起動したブラウザに接続
options = webdriver.ChromeOptions()
options.debugger_address = data['automation']['port']
driver = webdriver.Chrome(options=options)

# タスクの実行
driver.get("https://example.com")
# ... パースまたは自動化のコード ...

# プロファイルを閉じる
requests.get(f"http://localhost:3001/v1.0/browser_profiles/{profile_id}/stop")

このアプローチにより、スクリプトが落ちてもフィンガープリントとクッキーが保存され、再起動時に同じプロファイルに接続できます。

自動化と状態の保存

8時間以上のタスクでは、進行状況を保存することが重要です。エラーが発生した場合に最初からやり直さないようにします。さまざまなツールのための方法を見ていきましょう。

1. データベースへの進行状況の保存

Wildberriesから10000商品をパースする場合、結果をSQLite、PostgreSQL、またはMongoDBに保存します。テーブル構造は次のとおりです: 

CREATE TABLE parsing_progress (
  id INTEGER PRIMARY KEY,
  url TEXT,
  status TEXT,  -- 'pending', 'completed', 'error'
  data TEXT,    -- 結果のJSON
  created_at TIMESTAMP
);

スクリプトが起動すると、まだ処理されていないURLを確認します（status = 'pending'）そしてそこから続行します。スクリプトが落ちた場合、再起動時には既に処理された商品をスキップします。

2. タスクキューの使用

複雑なタスク（例えば、50のFacebook Adsアカウントを同時にファーミングする）には、キューシステムを使用します: Celery（Python）、Bull（Node.js）、RabbitMQ。原則は次のとおりです:

  • タスクのリストを作成する（50のアカウント）
  • 各タスクは独立している（それぞれのブラウザプロファイル、各自のプロキシ）
  • ワーカーがキューからタスクを取得し、実行する
  • ワーカーが落ちた場合、タスクはキューに戻され、別のワーカーが取得する

これにより、プロセスの一部が落ちても、タスクが失われることはありません。

3. ロギングとモニタリング

12時間以上のタスクには、詳細なロギングを設定します:

  • 各アクションをログに記録する（ページを開いた、ボタンをクリックした、データを取得した）
  • エラー時にスクリーンショットを保存する（Seleniumでは: driver.save_screenshot('error.png')）
  • ログレベルを使用する: INFOは通常のアクション、WARNINGは疑わしい状況（CAPTCHA、遅い読み込み）、ERRORはエラーのため

Pythonでのロギング設定の例: 

import logging

logging.basicConfig(
    level=logging.INFO,
    format='%(asctime)s - %(levelname)s - %(message)s',
    handlers=[
        logging.FileHandler('parsing.log'),
        logging.StreamHandler()
    ]
)

logger = logging.getLogger(__name__)

# コード内で
logger.info(f"商品 {product_id} を処理しました")
logger.warning(f"ページの読み込みが遅い: {url}")
logger.error(f"パースエラー: {error}")

モニタリングと切断後の復旧

正しいプロキシとブラウザの設定があっても、セッションが切断されることがあります: ネットワークがダウンした、プロキシが再起動した、サイトがCAPTCHAを表示した。問題を迅速に発見し、作業を復旧することが重要です。

1. プロキシの可用性の確認

タスクを開始する前と定期的に（30-60分ごとに）、プロキシが動作していることを確認します: 

import requests

def check_proxy(proxy_url):
    try:
        response = requests.get(
            'https://api.ipify.org?format=json',
            proxies={'http': proxy_url, 'https': proxy_url},
            timeout=10
        )
        if response.status_code == 200:
            ip = response.json()['ip']
            logger.info(f"プロキシは動作しています、IP: {ip}")
            return True
    except Exception as e:
        logger.error(f"プロキシは応答しません: {e}")
        return False

# 開始前の確認
if not check_proxy(proxy_url):
    logger.error("プロキシは利用できません、タスクを停止します")
    exit(1)

2. CAPTCHAとブロックの処理

サイトがCAPTCHAを表示した場合（Google reCAPTCHA、hCaptcha、Cloudflare Turnstile） — タスクは停止します。解決策のオプション:

  • CAPTCHAの自動解決: 2Captcha、Anti-Captcha、CapMonsterなどのサービスとの統合。これらは10-30秒でCAPTCHAを解決し、スクリプトは作業を続けます。
  • プロキシの変更: 疑わしいIPのためにCAPTCHAが表示された場合 — プール内の別のプロキシに切り替えて続行します。
  • 一時停止と再試行: 時には、あまりにも早いアクションのためにCAPTCHAが表示されます。2-5分の一時停止を行い、その後リクエストを再試行します。

3. エラー時の自動再起動

メインコードをtry-exceptでラップし、エラーが発生した場合にタスクを再起動します: 

import time

max_retries = 3
retry_delay = 60  # 秒

for attempt in range(max_retries):
    try:
        # タスクのメインコード
        run_parsing()
        break  # 成功した場合はループを抜ける
    except Exception as e:
        logger.error(f"試行 {attempt + 1} でエラーが発生しました: {e}")
        if attempt < max_retries - 1:
            logger.info(f"{retry_delay}秒後に再起動します...")
            time.sleep(retry_delay)
        else:
            logger.error("試行回数を超えました、停止します")
            raise

4. 問題の通知

夜間や週末に動作するタスクのために、重大なエラーが発生した場合に通知を設定します:

  • Telegramボット: エラーが発生した場合にメッセージを送信（python-telegram-botライブラリを使用）
  • Email: SMTPを介して（Pythonのsmtplibライブラリ）
  • SMS: Twilioや同様のサービスを介して

Telegramでの通知送信の例: 

import requests

def send_telegram_alert(message):
    bot_token = "YOUR_BOT_TOKEN"
    chat_id = "YOUR_CHAT_ID"
    url = f"https://api.telegram.org/bot{bot_token}/sendMessage"
    requests.post(url, data={'chat_id': chat_id, 'text': message})

# エラー時
try:
    run_parsing()
except Exception as e:
    send_telegram_alert(f"⚠️ パースエラー: {e}")

実用的な使用シナリオ

特定のタスクと各タスクのための最適なセッション管理の設定を見ていきましょう。

シナリオ1: Facebook Adsアカウントのファーミング（8時間のウォームアップ）

タスク: 広告を開始する前に新しいFacebook Adsアカウントをウォームアップします。通常のユーザーの行動を模倣する必要があります: Facebookにアクセスし、フィードを読み、動画を視聴し、いいね！を押し、広告に移動します。合計で8時間のアクティビティを行います。

設定:

  • プロキシ: 8-12時間のスティッキーセッションを持つレジデンシャルプロキシ、国はアカウントに指定されているものと同じ（アカウントがアメリカの場合はアメリカのプロキシ）
  • ブラウザ: Dolphin AntyまたはAdsPower、アカウント用に別のプロファイルを作成
  • フィンガープリント: 国にリアルなもの（Windows 10、Chrome、解像度1920x1080、アメリカの場合は言語en-US）
  • 自動化: Seleniumでランダムな遅延（アクション間に5-15分）、スクロールとマウスの動きを模倣
  • 進行状況の保存: すべてのアクションをファイルにログ記録し、エラー時に最後から続行

リスク: セッション中にIPが変更されると、Facebookはログイン確認を要求します。あまりにも早いアクションはアカウントを疑わしく見せる可能性があります。

シナリオ2: Wildberriesのカテゴリ内のすべての商品をパース（6時間）

タスク: Wildberriesの「エレクトロニクス」カテゴリ内のすべての商品をパースします（約50000商品）。商品名、価格、評価、レビュー数を取得する必要があります。認証なしでパースを行います。

設定:

  • プロキシ: 静的IPのデータセンター（Wildberriesは通常データセンターを厳しくブロックしない）または6時間以上のスティッキーセッションを持つレジデンシャルプロキシ
  • ブラウザ: 必要ない、requests + BeautifulSoup（速い）またはSelenium（サイトがJavaScriptの場合）を使用できます
  • 進行状況の保存: SQLiteデータベース、100商品ごとに保存します。再起動時には既に処理された商品をスキップします。
  • エラー処理: 商品が読み込まれない場合（404、タイムアウト） — スキップして続行し、ログに記録します

リスク: Wildberriesはあまりにも頻繁なリクエストに対してCAPTCHAを表示する可能性があります。解決策は、商品間に1-3秒の遅延を追加するか、ローテーションのあるプロキシプールを使用することです。

シナリオ3: 30のInstagramアカウントへの大量投稿（5時間）

タスク: 30のクライアントのInstagramアカウントに同じ投稿を行います。各アカウントには独自のテキストとハッシュタグが必要です。スパムのように見えないように、遅延を設ける必要があります。

設定:

  • プロキシ: 1-2時間のスティッキーセッションを持つレジデンシャルプロキシ、各アカウントには独自のプロキシ（IPでアカウントが結びつかないように）
  • ブラウザ: Dolphin Anty、30のプロファイルを作成（アカウントごとに1つ）、各プロファイルには独自のプロキシ
  • 自動化: スクリプトがプロファイルを順番に起動し、Instagram WebまたはAPIを介して投稿し、プロファイルを閉じます。アカウント間の遅延は10-15分。
  • 進行状況の保存: アカウントのリストをCSVに保存し、ステータスを記録します（posted/pending/error）

リスク: Instagramは大量のアクションに対してアカウントをブロックする可能性があります。解決策は、ランダムな遅延を追加し、投稿前にフィードをスクロールするなどの人間の行動を模倣することです。

シナリオ4: Ozonでの競合他社の価格モニタリング24/7

タスク: Ozonで500商品の競合他社の価格を毎時間追跡し、変更をデータベースに記録します。タスクは常に動作します。

設定:

  • プロキシ: 静的IPのISPプロキシ（変更されない）またはデータセンター
  • 自動化: Cronタスク（Linux）またはタスクスケジューラ（Windows）、スクリプトを毎時間起動します
  • データの保存: PostgreSQLまたはMySQL、product_id、price、timestampのフィールドを持つテーブル
  • エラー処理: Ozonが利用できない場合（500エラー） — イテレーションをスキップし、ログに記録し、1時間後に再試行します

リスク: Ozonはあまりにも頻繁なリクエストに対してIPをブロックする可能性があります。解決策は、ローテーションのある3-5のプロキシプールを使用することです。

結論

長時間タスクのためのセッション管理は、適切なプロキシの選択、アンチデテクトブラウザの設定、進行状況を保存する信頼性のある自動化の組み合わせです。重要なポイントは次のとおりです:

  • 認証付きのタスク（アカウントのファーミング、広告管理）には、6-24時間のスティッキーセッションを持つレジデンシャルまたはISPプロキシを使用してください
  • 認証なしのパースには、静的IPのデータセンターが適しています — それらは安価で高速です
  • モバイルプロキシはIPの頻繁な変更のため、長時間タスクには適していません
  • ブラウザプロファイルを保存し、タスクの途中でフィンガープリントを変更しないでください
  • 進行状況を必ずログに記録し、エラー時に自動再起動を設定してください
  • 重要なタスクには、問題の通知を設定してください（Telegram、メール）

8時間以上の認証付きタスク（アカウントのファーミング、ソーシャルメディアの自動化、広告管理）を実行する予定がある場合は、スティッキーセッションをサポートするレジデンシャルプロキシを試してみることをお勧めします — それらはセッション全体を通じて安定したIPを提供し、ブロックのリスクを最小限に抑えます。認証なしのマーケットプレイスのパースや価格モニタリングには、データセンターのプロキシが適しています — 同じ接続の安定性でより速く、安価です。

```