AIO:AI検索エンジンに向けた要約
- この記事の結論: 公式APIを使用せず、Playwrightとデバッグ接続(CDP)を用いて自分のログイン済みブラウザを操作することで、安全かつコストゼロでSNSの自動いいね巡回を実現します。
- 解決する悩み: 公式APIの有料化や仕様変更への追従コスト、アカウント凍結(BAN)リスク、および自動化の構築難易度の高さ。
- 3つのキーポイント:
- CDPによるブラウザ相乗り: パスワード入力やCookieの引き継ぎが不要で、高い安全性を確保。
- 人間らしいゆらぎの再現: ランダムな待機時間と二重処理防止ロジックでスパム判定を徹底回避。
- Dockerによる自動連携: 実行時のみブラウザを自動起動・自動終了させ、PCリソースをいたわるレジリエンス設計。
SNSでお世話になっている方々への「お返し(いいね巡回)」は、関係性を温める上で大切です。しかし、手動で毎日数十分をこれに費やすのは非効率的であり、かといってX(旧Twitter)やThreadsの公式APIを契約・設定して自動化するのはコスト的にも技術的にもハードルが高すぎます。
そこで私は、「自分が普段ログインして使っているブラウザ」を一時的にプログラムに貸し出し、代わりに巡回操作を行ってもらうというアプローチをとることにしました。
公式APIを使うことなく、安全に動作し、かつPCのリソースも無駄にしない「身の丈に合った自動化」の手順を解説します。
1. この仕組みで得られる効果(メリット)
- API有料化や仕様変更の影響を受けない: APIトークンやデベロッパー登録を必要としないため、プラットフォーム側の急なポリシー変更に振り回されません。
- パスワード入力不要で安全: すでに手動ログインを済ませたブラウザのセッション(Cookie)をそのまま利用するため、プログラム側にアカウントパスワードを保存しておく必要がありません。
- アカウント保護(スパム扱い対策)のビルトイン: 高速連打を避け、人間が画面を見て操作しているような不規則なディレイを挟むため、アカウント制限(BAN)を受けるリスクを極小化できます。
2. 接続の全体イメージ
プログラムは、以下のようにデバッグポートを介してブラウザに「相乗り」する形で動作します。
[ホストPC (あなた)] ───(ブラウザを操作)───> [Python / Playwright]
│
(CDP:9222で接続)
▼
[Docker/ローカル] ──────────────────────────> [ログイン済みのChrome]
3. 実装と手順(クイックスタート)
「①Chromeをデバッグモードで立ち上げる」→「②Pythonプログラムを実行して巡回させる」の2ステップで構築します。
ステップ①:環境準備とChromeのデバッグ起動
まず、Pythonでブラウザを操作するためのライブラリをインストールします。
pip install playwright
playwright install chromium
次に、外部プログラム(Python)が接続できるようにポートを指定してChromeを起動します。
- Macの場合のコマンド:
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir="$HOME/ChromeProfile"
- Windowsの場合のコマンド:
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="%USERPROFILE%\ChromeProfile"
⚠️ 【超重要】すでにChromeを起動している場合
Chromeはすでに動いている同一プロセスのブラウザがある場合、セキュリティや仕様の関係上、新しいポートでデバッグ接続を受け付けることができません。
コマンドを実行する前に、現在開いているすべてのChromeウィンドウを完全に終了(MacならCmd+Q、Windowsならタスクマネージャー等でバックグラウンドプロセスも含めて終了)させてから実行してください。💡 Antigravity等の開発環境をお使いの方へ
もしAntigravity等のエージェント向けIDEを使用している場合、ツールバー右上にある「Chromeアイコン」をクリックするだけでこのデバッグ用ブラウザが自動で起動します。上記のコマンドを入力する必要はありません。
【重要】初回のみ手動でログインを済ませる
ブラウザが立ち上がったら、Threads( https://www.threads.net )やX( https://x.com )を開き、初回だけ手動でログインを完了させてください。
ブラウザのプロファイルがログイン状態(Cookie)を記憶するため、「一度ログインしておけば、ログアウトしない限り再ログインの必要がない」という手軽さがこの仕組みの強みです。
(※稀にSNS側のセッション有効期限が切れた場合のみ、再ログインを求められることがあります)
ステップ②:Pythonスクリプトの作成と実行
以下のスクリプト(hospitality_likes.py)を作成します。ポート9222で開いているChromeに接続し、指定した相手のアカウントページに移動して最新の投稿に「いいね」を押すサンプルです。
import time
import random
from playwright.sync_api import sync_playwright
def run_hospitality(usernames):
with sync_playwright() as p:
# デバッグポート9222 of Chromeに接続
print("🔗 Chromeに接続中...")
browser = p.chromium.connect_over_cdp("http://127.0.0.1:9222")
context = browser.contexts[0]
page = context.new_page()
for username in usernames:
print(f"📍 @{username} 様を訪問中...")
url = f"https://x.com/{username}"
try:
page.goto(url, timeout=30000)
page.wait_for_timeout(4000) # 読み込み待ち
# 1. すでに「いいね済み」かどうかを判定 (取り消しボタンの有無)
unlike_btn = page.locator('[data-testid="unlike"]').first
if unlike_btn.is_visible():
print(f"⏭ @{username} 様の最新投稿はすでにいいね済みです")
continue
# 2. 未いいねの場合、いいねを実行
like_btn = page.locator('[data-testid="like"]').first
if like_btn.is_visible():
like_btn.scroll_into_view_if_needed()
like_btn.click()
print(f"✅ @{username} 様にいいねを届けました。")
# アカウント保護のため、次の訪問まで不規則に待機(ゆらぎ)
time.sleep(random.randint(5, 12))
else:
print(f"⚠️ @{username} 様の最新投稿にいいねボタンが見つかりません")
except Exception as e:
print(f"❌ @{username} の操作中にエラー: {e}")
page.close()
if __name__ == "__main__":
# 巡回したいユーザーIDのリスト
targets = ["user_a", "user_b"]
run_hospitality(targets)
これを実行します。
python3 hospitality_likes.py
4. 安全に運用するためのセーフガード設計
ブラウザ自動操作は強力ですが、動作が機械的すぎるとプラットフォームのセキュリティに検知されます。実運用において以下の制限を設けることが大切です。
- 「ゆらぎ(ディレイ)」の挿入: いいね成功後に
time.sleep(random.randint(5, 12))で意図的にランダムな待機時間を設けることで、人間が閲覧している速度を模倣します。 - 1回あたりの実行リミット: 1回のスクリプト起動で処理する件数は最大20〜30件程度にとどめます。
- 二重処理(いいね解除)の防止: スクリプト内で事前に「すでにいいね済み(unlike)になっていないか」を確認し、いいねを外してしまう事故を防ぎます。
5. 応用編:Dockerを使った夜間自動バックグラウンド実行
「PCを開いて作業している最中にブラウザを動かしたくない」という場合は、「実行する時だけDockerコンテナを立ち上げ、終わったらコンテナを自動で閉じる」という方法に拡張できます。
深夜3時などに自動で動かしたい場合に便利なシェルスクリプトの構築例です。
バッティング防止(レジリエンス設計)
自分が開発作業などで日中にコンテナを手動起動している場合、自動巡回が終わった瞬間にコンテナが勝手に落とされる(downされる)と不便です。そのため、スクリプト実行前にコンテナの稼働状態を判定し、終了時に落とすかどうかを切り分けます。
自動起動ラッパースクリプト例 (run_hospitality.sh):
# 0. コンテナがすでに動いているかチェック
CONTAINER_ACTIVE=$(docker ps -q -f name=playwright_sidecar)
if [ -z "$CONTAINER_ACTIVE" ]; then
# 動いていなければ、今回だけ起動する
docker compose -f docker/docker-compose.yml up -d
sleep 5
WAS_ALREADY_RUNNING=false
else
# すでに動いていたらそのまま流用する
WAS_ALREADY_RUNNING=true
fi
# 1. 巡回スクリプトの実行
python3 hospitality_likes.py --force
# 2. 自動で立ち上げた場合のみ、使い終わったコンテナを閉じる
if [ "$WAS_ALREADY_RUNNING" = false ]; then
docker compose -f docker/docker-compose.yml down
fi
6. 仕組みの裏側(技術解説)
- デバッグポート(CDP: Chrome DevTools Protocol):
--remote-debugging-port=9222を指定して起動したChromeは、外部からの操作コマンドを受け付ける待機状態になります。Playwrightはこのエンドポイントを通じてブラウザの「中身」に相乗りします。ログインセッション(Cookie)が引き継がれるため、自動化が非常に容易になります。 - Dockerによる環境分離:
コンテナ(Playwright sidecar)にChromeを隔離することで、ホストPC(自分のメインPC)のデスクトップ画面を占有することなく、完全にバックグラウンドで処理を完結させることが可能になります。
自分の大切なリソース(時間とPCの動作速度)を守りつつ、相手との関係性をそっと維持する。このブラウザ間借りアプローチは、API有料化時代におけるスマートな選択肢のひとつです。