Bluesky Botを「止まれる設計」にする：4日間の自動いいねログで決めた5つのルール

Blueskyの操作を自動化してみて、いちばん大事だったのは「何件できるか」ではありませんでした。画面が想定と違ったときに、Botが自分で止まれるかどうかです。

私は自分のBluesky運用で、夜のいいね作業をPlaywrightから実行しました。4日分の結果は、目標39件に対して実行36件。3日間は目標どおりでしたが、1日だけ8件中5件で停止しました。

止まった原因はBlueskyの利用上限ではありません。画面上に開いたメニューがボタンの手前に重なり、クリックを3回続けて失敗したためです。以前なら「残り3件も何とか押す」ことを優先していました。今は、予定数を達成することより、同じエラーを繰り返さず終了することを正常動作として扱っています。

この記事では投稿数を増やす方法ではなく、私が実際の失敗ログから決めた5つの運用ルールを紹介します。現在検証できているのは自動いいねです。自動投稿や自動返信まで安全に検証できたようには書きません。

4日間の実行結果

2026年7月1日から4日までの実行ログを集計すると、次のようになりました。

実行日	目標	実行できた数	結果
7月1日	10件	10件	完了
7月2日	8件	5件	3回連続エラーで停止
7月3日	10件	10件	完了
7月4日	11件	11件	完了
合計	39件	36件	達成率92.3%

7月2日に記録されたエラーは、クリック対象が見つからないというものではありません。いいねボタンは表示されていましたが、「コンテキストメニューの背景」が手前にあり、クリックを受け取っていました。

Playwrightのログには、要約すると次の状態が残っていました。

like button: visible / enabled / stable
click result: another element intercepts pointer events
consecutive_errors: 1 -> 2 -> 3
final result: liked 5 / target 8, skipped=true

ここで強制クリックを使えば、表面上は先へ進めた可能性があります。しかし、何が開いているか分からない状態でクリックだけを通すと、別のボタンを押したり、同じ投稿へ重複操作したりする危険があります。そのため、3回続いた時点で終了する設計を残しました。

ルール1：実行より先にドライランを標準にする

私の実行入口は、--executeを付けない限り実際のいいねを行わないようにしています。通常コマンドは候補を確認するだけです。

python3 scripts/engage/daily_engage.py \
  --platform bsky \
  --slot night \
  --no-jitter

実際に操作する場合だけ、明示的に--executeを付けます。

python3 scripts/engage/daily_engage.py \
  --platform bsky \
  --slot night \
  --no-jitter \
  --execute

この差は小さく見えますが、誤ってテスト用コマンドを本番操作にしてしまう事故を防げます。安全側を標準にし、外部へ影響する操作だけ追加指定にする考え方です。

自動投稿でも同じです。まず文章生成、重複検査、下書き保存までを標準にし、公開は別の実行条件へ分けた方が戻しやすくなります。

ルール2：技術上限ではなく、自分の運用上限を決める

Blueskyの公式ドキュメントにはAPIのレート制限が掲載されています。ただし、技術的に受け付けられる回数と、自然な運用として適切な回数は同じではありません。

公式のRate Limitsにも、大量またはスパム的なフォロー・いいねはコミュニティガイドラインに反すると明記されています。Community Guidelinesでも、会話やサービス利用を妨げる反復投稿、人工的な反応操作、スパムを禁止しています。

そこで私は、APIの最大値を目標にせず、時間帯ごとの小さい範囲を設定しました。

{
  "morning_likes": [3, 5],
  "night_likes": [6, 10],
  "daily_likes": [8, 12]
}

これはBlueskyが推奨する公式件数ではなく、私の個人運用で使っている内部上限です。「上限まで使えるから使う」のではなく、少ない件数で動作と内容を確認するための設定です。

また、検索対象はテーマを限定しています。ただし、キーワードが一致しただけで内容まで適切とは限りません。特定の相手へ機械的に反応し続けたり、数字を増やす目的だけで無差別に操作したりしないことを、件数設定より上位のルールにしています。

ルール3：3回連続で失敗したら、未達でも正常終了する

7月2日の実行では、目標8件に対して5件で止まりました。残り3件を取り返す再試行はしていません。

実装では、成功すると連続エラー数を0へ戻し、失敗すると1ずつ増やします。3になったら、その実行をskipped=trueとして閉じます。

consecutive_errors = 0

while completed < target and consecutive_errors < 3:
    try:
        click_next_candidate()
        completed += 1
        consecutive_errors = 0
    except Exception:
        consecutive_errors += 1

return {
    "completed": completed,
    "target": target,
    "skipped": consecutive_errors >= 3,
}

ポイントは、失敗を握りつぶして成功扱いしないことです。5件できた事実と、3件できなかった事実を両方残します。

「毎日必ず実行する」と「毎日予定数を達成する」は別です。予定数を達成するために危険な再試行を増やすより、未達の理由を残して翌日の修正材料にした方が、長期運用では壊れにくくなりました。

ルール4：件数だけでなく、止まった理由を保存する

成功件数しか残していないと、5/8で止まった日が単なる不調に見えます。実際には「メニューの背景がクリックを遮った」という、次の修正に使える情報がありました。

私は1回の実行で、最低限次の項目を残しています。

実行開始時刻
対象プラットフォーム
目標件数
実行できた件数
ドライランか実操作か
連続エラー数
最後に止まった理由
正常終了か、途中停止か

エラー全文には画面要素や内部情報が大量に含まれることがあります。公開記事へそのまま貼らず、秘密情報、アカウント情報、不要なHTMLを除いて「何が操作を遮ったか」だけを短く残します。

日次サマリーは、次のような形なら翌日に判断できます。

bsky: liked=5 requested=8 runs=1 skipped_runs=1
stop_reason: overlay intercepted pointer events 3 times
next_action: close unexpected menu before selecting the next button

Bot運用で必要なのは、成功を大きく見せるレポートではありません。次回に同じ失敗を繰り返さないためのレポートです。

ルール5：自動化が開いたタブだけを閉じる

ブラウザ操作では、投稿内容だけでなくタブの扱いも事故原因になります。ログイン済みブラウザの前面タブをそのまま使うと、ユーザーが見ていた画面を突然別ページへ移動させてしまいます。

そのため、自動化では専用タブを作り、そのタブだけを操作対象にします。終了時も自動化が所有するタブだけを閉じ、ブラウザ本体や既存タブは閉じません。

私の処理では、成功時だけでなく途中停止時もfinallyで後片付けします。

page = None
browser = None

try:
    browser, page = open_owned_tab()
    run_small_bounded_task(page)
finally:
    if page:
        page.close()
    if browser:
        browser.close()

ここでいうbrowser.close()は、Playwrightが接続した自動化側の接続を閉じる処理です。普段使っているブラウザを終了・再起動して直す設計にはしていません。ログイン状態、2段階認証、CAPTCHA、期待アカウントの不一致が出た場合も、別ブラウザへ勝手に切り替えず停止します。

自動投稿・自動返信へ広げる前の境界

今回の4日分で確認したのは自動いいねです。投稿文の自動公開、他人への自動返信、DM送信まで安全性を証明したものではありません。

外部への影響が大きい順に考えると、私は次のように分けます。

操作	自動化しやすさ	人間確認
公開情報の読み取り	高い	原則不要
投稿案のローカル生成	高い	品質確認に使う
ドライラン・候補抽出	高い	対象確認に使う
少数のいいね	条件付き	ログと停止条件が必要
公開投稿	影響が大きい	重複・出典・アカウント確認が必要
返信・DM	文脈依存が強い	原則として送信前確認

特に返信は、同じ文章でも会話の流れによって意味が変わります。生成できることを理由に、自動送信まで一気につなげない方が安全です。

今日確認できるチェックリスト

Blueskyの自動運用を始める前に、次の7項目を確認します。

標準動作がドライランになっている
実操作には明示的な実行指定が必要
1回と1日の内部上限を小さく設定している
同じ失敗が3回続いたら未達でも止まる
成功数と失敗理由を同時に保存する
自動化が作った専用タブだけを閉じる
投稿、返信、DMはいいねと同じ許可範囲にしない

加えて、Blueskyの公式API documentationとCommunity Guidelinesは定期的に確認します。レート制限やルールは変更される可能性があるため、この記事の数字を恒久的な公式上限として使わないでください。

まとめ

4日間の結果は36/39件でした。数字だけなら、3件未達です。しかし、7月2日に3回連続エラーで停止できたことで、画面状態が分からないまま強制操作を続けずに済みました。

私が残したルールは次の5つです。

ドライランを標準にする
技術上限より小さい内部上限を使う
3回連続失敗で止まる
未達件数と停止理由を保存する
自動化が開いたタブだけを閉じる

Botは、止まらず動くほど優秀なのではありません。想定外の画面や文脈に出会ったとき、外部へ余計な影響を出す前に止まれることが、毎日使える自動化の条件だと考えています。

今回の背景にある、1つのコンテンツを媒体別に作り直す考え方は、Kindle本『1つのコンテンツを5媒体で展開する転用戦略』にもまとめています。この記事だけでも停止ルールは設定できます。ブログ、SNS、動画、電子書籍へ展開する時の役割分担まで確認したい場合だけ、続きとして利用してください。

※リンクには広告属性を付けています。価格、レビュー数、ランキングなどの変動情報は本文では扱いません。

1つのコンテンツを5媒体で展開する転用戦略をKindleで見る