月10万の大学生が掛け持ちで60万に乗せ、会社都合で解雇されてゼロになり、半年かけて Claude Code の自律環境を組み上げて月商120万まで戻しました。その過程で学んだことは「自動化の成功体験」ではなく、自動化が壊れたときに何が起きるかの積み上げです。

2026年8月28日、Instagram の同じカルーセルが3本並びました。ショートコード DckjvpPoFRt・DckN-yYkIBsJ・DclaPYooPjB——13:58、17:55、21:54 JST。ジョブは3回とも「投稿がプロフィールに見つからない」と記録していましたが、Instagram API を直接確認すると3回とも投稿は成立していました。

成功しているのに「失敗」と誤判定する——偽陰性（false negative） が副作用を3回繰り返した事故です。

なぜこの仕組みが効くのか

「環境を作る」というのは、自分が操作する回数をゼロに近づけることです。

Instagram 自動化は launchd が定刻にスクリプトを呼び出し、キャプション生成から投稿・着地確認・台帳書き込みまでを人間の関与なしに完走します。全体で約171本のジョブが並走しており、Instagram へのカルーセル投稿はその1レーンです。「今日投稿できたか」をわざわざ確認しにいく必要はなく、台帳の ok:true と Discord の通知がそれを代わりに伝えます。

これが「作業」でなく「環境」である理由は、リトライも環境が判断するからです。

着地確認（_verify_landed()）が ok:false を返せば、次の定時実行で同じジョブが走ります。人間が「あ、失敗してたんだ。じゃあもう一度」と手動でやるかわりに、スケジューラが自動で再実行する。時間も労力もゼロです——判定が正しければ。

判定が間違っているとき、この仕組みは逆方向に動きます。投稿は成功しているのに ok:false が出続けると、スケジューラは「まだ投稿できていない」と解釈して同じ内容を再度送信します。副作用（投稿）が済んでいるにもかかわらず、検証層だけが「未実施」と言い張る。この状態でリトライが走れば、同じ投稿が何本でも積み上がります。

「止まる」より「増える」ほうが悪い

偽陽性（false positive）——「実は失敗していたのに成功と誤判定する」——は出荷ラインを止めます。これは見える失敗です。誰かが気づいて調べます。

偽陰性（false negative）——「実は成功していたのに失敗と誤判定する」——は出荷を増やします。これは見えない失敗です。台帳には ok:false が並び、表向きは「投稿が遅れている」状態に見えます。実際には同じ投稿が量産されていても、スクリプトは淡々と次のリトライを予約し続けます。

副作用のある操作に対する偽陰性は、「検証の失敗」ではなく「副作用の重複」が被害です。 間違えるたびに現実世界に痕跡が増えます。Instagram の場合、プロフィールに同一カルーセルが3本並ぶという形で。

学習ノートにはこう記録されています。「[[false-positive-stops-the-line]] は『誤検知が出荷を止める』型やったが、こっちは誤検知が出荷を増やす。止まるより悪い。」

環境が効く条件

171本のジョブが効率よく回るのは、各ジョブが「自分の仕事が終わったかどうか」を正確に判定できているからです。判定が正確なら、成功したジョブは1回で済み、失敗したジョブだけが再実行を受け取ります。

判定が壊れると、この前提が崩れます。成功したジョブも「失敗」扱いで再実行を受け取ります。副作用が冪等（何度やっても同じ結果）な操作なら問題ありません——が、SNS 投稿は冪等ではありません。1回送れば1本公開され、3回送れば3本公開されます。

「リトライ回数を何回にするか」より先に、「この操作は冪等か」を問わないといけない。 冪等でない操作に3回のリトライを付けることは、副作用を最大3回許容する宣言と同じです。リトライ設計の正典（retry-and-giveup-design.md）が「同じ失敗を3回投げても結果は変わらない」と言うのも同じ文脈です——問題が「判定の材料そのもの」にある場合、回数を増やしても何も変わりません。

全体の流れ

事故当日の動きをシーケンスで追います。

[launchd: 13:58 JST]
        │
        ▼
  ig_autopost.py
        │
        ├─ (1) キャプション生成・投稿実行
        │       IG カルーセル送信 ─────────────► 成功 ✓ (DckjvpPoFRt)
        │
        └─ (2) 着地確認: _verify_landed()
                │
                ├─ プロフィール DOM 取得
                │   キャプション先頭12文字: "👾 個人開発の量産..."
                │   IG レンダリング:         <img alt="👾"> ← inner_text に出ない
                │   照合文字列(DOM側):        " 個人開発の量産 v"  ← ズレる
                │
                └─ 照合NG → ok: false → 台帳: 「投稿されていない」
                        │
                        ▼
[launchd: 17:55 JST] ← スケジューラ「まだ未投稿」と判断・再実行
        │
        ├─ 同じキャプションで投稿 ──────────────► 重複1本目 (DckN-yYkIBsJ)
        └─ _verify_landed() → ok: false ← また偽陰性
                        │
                        ▼
[launchd: 21:54 JST] ← さらに再実行
        ├─ 投稿 ───────────────────────────────► 重複2本目 (DclaPYooPjB)
        └─ _verify_landed() → ok: true ← ようやく成功判定

8時間で3本、すべて同一内容のカルーセル。スクリプトは3回とも「正しく動いた」という認識のまま終了しています。IG API で確認して初めて重複が判明しました。

真因：照合の材料が壊れていた

_verify_landed() はプロフィールページの DOM を取得し、本文先頭12文字をキャプションの先頭12文字と突き合わせていました。この設計の前提は「DOM の inner_text にキャプションが丸ごと出る」です。

ところが Instagram は絵文字を <img> タグにレンダリングします。キャプション冒頭が 👾 のとき、DOM 上では <img alt="👾"> になり、inner_text にはその文字が出ません。

キャプション文字列: "👾 個人開発の量産 vol..."
照合しようとした文字列(先頭12文字): "👾 個人開発の量産 vo"
DOM inner_text(先頭12文字):         " 個人開発の量産 vol."  ← 👾 が img に化けて消える

→ 永久に不一致

「押せたか（投稿できたか）」でなく、「何を照合したか」で壊れるのがこの種の偽陰性の本質です。照合の仕組みは動いています。ただし、照合の材料が破損しています。

修正の3本柱

1. キャプション正規化（絵文字・全角除去）

照合キーを DOM のレンダリングに依存しない形に変換します。キャプション文字列と DOM から取った本文の両側に同じ関数を通すことで、どちらが欠けても比較が成立しなくなります。

def normalize_caption_key(text: str) -> str:
    import unicodedata
    # 全角・半角空白を除去
    text = "".join(c for c in text if not c.isspace())
    # BMP外（絵文字 ord > 0xFFFF）と Unicode カテゴリ So/Sk を除去
    text = "".join(
        c for c in text
        if ord(c) <= 0xFFFF
        and unicodedata.category(c) not in ("So", "Sk")
    )
    # 先頭24文字（残りが24文字未満ならキャプション全体）
    return text[:24] if len(text) >= 24 else text

照合幅が 12 文字から 24 文字に延びているのは、正規化後に絵文字が間引かれた分のマージンです。もとの12文字ルールは未正規化の文字列に対して設計されていたため、正規化後の残りが同じ量の情報を持つには長くする必要があります。

「キャプションとページ本文の両側に同じ正規化をかける」——これが肝です。片側だけ正規化しても、変換後の文字列長が合わず別のズレを生みます。

2. API 先読みによる DOM フォールバック排除

DOM の inner_text は、IG がどうレンダリングするかに依存します。IG はいつでも仕様を変えられる。この不確実性をゼロにするのが API 先読みです。

ログイン済みページの ds_user_id cookie を使い、内部 API に直接問い合わせます。API が JSON を返した（＝正常に応答した）にもかかわらず該当投稿が見つからなければ、DOM に逃がさず失敗として確定させます。8回の問い合わせがすべて JSON でない（API が壊れている等）ときだけ、DOM を1回だけフォールバックとして使います。

API 問い合わせ (最大8回)
        │
        ├─ JSON 返答あり + 投稿あり  → ok: true
        ├─ JSON 返答あり + 投稿なし  → ok: false（DOM に逃がさない）
        └─ 8回とも JSON 以外         → DOM を1回だけ確認 → ok / false

「確認不能」を「未投稿」と誤訳しないための設計です。API が壊れているときに DOM に逃げれば、結局 inner_text の照合に戻ります。それでは偽陰性を再発させる可能性が残ります。

3. fail-closed 設計

API 確認が不能なとき、デフォルトを「投稿済み」として扱います。理由は非対称性です。

「未投稿と誤判定 → 再実行 → 重複」：今回実際に起きた被害（3本重複・後から消す手間）
「投稿済みと誤判定 → スキップ → 1回分遅延」：次の定時実行で自然に回収される

重複は後から消せますが、公開されていた時間と削除作業が発生します。遅延は次のジョブが補います。非対称な被害には、軽いほうをデフォルトにする fail-closed が適切です。

あわせて、すでに公開済みの投稿を「失敗」として台帳に残さないよう already-live 判定を導入しました。

# 既存投稿として検出した場合
return {"ok": True, "note": "already-live"}

ok:false で台帳に積まれると、次のリトライ判定で「未投稿」扱いになります。ok:true で記録することで、重複ガードが正しく機能します。

この3点の修正は IG へ一切接続せず、静的な実装変更と純関数テストだけで着地させました（pytest 12 passed）。投稿前の重複チェック（has_existing_caption()）もカルーセルとリールの両レーンに共通関数として配線し、API 確認不能時は同様に fail-closed で止まります。

実装の詳細

`normalize_caption_key` — なぜこの実装になったか

前半で示した正規化関数を、もう一段深く分解します。

def normalize_caption_key(text: str) -> str:
    import unicodedata
    text = "".join(c for c in text if not c.isspace())
    text = "".join(
        c for c in text
        if ord(c) <= 0xFFFF
        and unicodedata.category(c) not in ("So", "Sk")
    )
    return text[:24] if len(text) >= 24 else text

ord(c) <= 0xFFFF という条件の意味は、BMP（Basic Multilingual Plane）に収まる文字だけを残すということです。絵文字のほとんどは U+1F000 以上、つまり ord が 65535 を超えます。👾 は ord が 128126 なので即除外される。Unicodeカテゴリ So（Symbol, Other）と Sk（Symbol, Modifier）も除去するのは、BMP内にも装飾的な記号が混在しているからです。たとえば ★（U+2605, カテゴリ So）はBMPに収まっていますが inner_text に安定して出るとは言えない。

「24文字」という照合幅は実測から逆算しています。もとの12文字は未正規化の文字列で設計されていました。正規化後は絵文字が抜けた分だけ文字列が短くなります。キャプション冒頭が 👾 個人開発の量産 vol.XX —— のような場合、👾 が脱落した後の最初の12文字は 「個人開発の量産 v」 とかなり汎用的な文字列になります。24文字まで伸ばすと 「個人開発の量産 vol.18 ——」 まで読め、別の投稿と衝突しにくくなります。

肝は関数の適用対象です。「キャプション文字列」と「DOMから取ったページ本文」の両側に同じ normalize_caption_key を通します。片側だけ正規化しても、変換後の文字数がズレて新しいミスマッチを生みます。pytest で確認したのも「両側に通した結果が一致するか」というシナリオです。

# テストの骨格
def test_normalize_both_sides():
    caption = "👾 個人開発の量産 vol.18 —— "
    dom_text = " 個人開発の量産 vol.18 —— "  # IG が img に変換した後
    assert normalize_caption_key(caption) == normalize_caption_key(dom_text)

純関数なのでIGに一切接続せず検証できます。これが「IG未接続で pytest 12 passed」の実体です。

API 先読み — 「確認不能」と「未投稿」を分離する実装

前半で示したフローを実装に落とすと、判定の分岐は次のような形になります。

def _verify_via_api(shortcode: str, caption: str) -> dict:
    for attempt in range(8):
        resp = _fetch_profile_api(user_id=DS_USER_ID, cursor=...)
        if resp is None:  # JSON以外が返ってきた
            continue
        # JSONが返った = API正常
        for post in resp.get("edges", []):
            node_text = post["node"].get("edge_media_to_caption", {})
            key = normalize_caption_key(node_text.get("edges", [{}])[0].get("node", {}).get("text", ""))
            if key and key == normalize_caption_key(caption):
                return {"ok": True, "source": "api"}
        # JSONが返ったが該当なし → DOMへ逃がさない
        return {"ok": False, "source": "api", "reason": "not_found"}
    # 8回ともJSONでなかった → DOMを1回だけ
    return _verify_via_dom(caption)

核心は resp is None と return {"ok": False} の分岐の非対称性です。「APIが動いていてJSONが返ってきた」のに「該当投稿が見つからない」なら、それは投稿されていないという確定情報です。DOMへ逃げる理由はありません。「8回ともJSONが返らなかった」ときだけ、DOM確認にフォールバックします。

なぜ8回かというと、内部APIへのリクエストはInstagramのレート制限に引っかかることがあり、1〜2回失敗したあとに正常に返ることがあるためです。ただし8回ともJSONでないなら、APIが壊れているかセッションが切れているかのどちらかで、これ以上問い続けても結果は変わりません。

ds_user_id cookie を使う理由は、ログイン済みの内部APIはフォロー外のプロフィールに対しても投稿一覧をJSON形式で返すからです。ページネーションが必要な場合は after カーソルを使いますが、着地確認では直近投稿だけを確認するので1ページで足ります。

fail-closed と `already-live` の台帳設計

# API確認が8回とも不能 → DOMへ行ったが結果も不明 → fail-closed
def _verify_landed(shortcode: str, caption: str) -> dict:
    result = _verify_via_api(shortcode, caption)
    if result.get("source") == "api":
        return result
    # DOMフォールバックの結果
    dom_result = result
    if dom_result.get("ok") is None:  # 確認不能
        return {"ok": True, "note": "unverified-assumed-live"}
    return dom_result

ok: True, note: "already-live" の記録形式にしているのは、台帳の読み取り側が ok:true をスキップ判定に使っているからです。ok:false で記録すると、次のリトライ実行時に「未投稿」として再処理されます。note フィールドは人間が台帳を見たときに「なぜ成功扱いにしたか」を残すためのもので、スクリプトのロジックには使いません。この区別を入れておかないと、3ヶ月後に台帳を読んだとき「なぜここがtrue?」という疑問に答えられなくなります。

投稿数デルタによる二重確認も合わせて入れています。投稿前後のプロフィール投稿数を取得し、差分が +1 ならキャプション照合と独立して成功判定します。これはキャプション正規化が何らかの理由で一致しなかった場合のセーフティネットです。2つの確認が同じ内部APIを使いながら、見ている「材料」が別（キャプション vs 件数）になっているので、片方が壊れても判定が完全には死にません。

私が詰まった話

修正の翌日、今度は空の投稿が16本並んだ

8月28日の修正（正規化＋API先読み＋fail-closed）を入れた翌々日の8月30日、今度は 本文のないカルーセルが16本公開されました。同じ2パターンが8ラウンドずつです。

症状は「また重複が出た」ですが、今度の原因は照合ではなく投稿側でした。ig_autopost.py の keyboard.insert_text がキャプション欄に入っておらず、スクリーンショットには 0/2200 のまま「シェア」を押した記録が残っていました。

この事故が前回よりたちが悪かったのは、学習ノートに書いた通りです。

🔴 投稿前の重複ガード（has_existing_caption）と投稿後の着地照合（_verify_landed）は、同じ内部APIと同じ24字キー（normalize_caption_key）を共有している。 本文が空だと両方とも一致しない → 重複ガードが「まだ出ていない」と言い、着地照合が「出ていない」と言う → 失敗扱いで同じIDを再投稿。

8月28日に「投稿前の重複チェックを共通関数に切り出した」ことは正しい判断でした。ただし共通化した結果、壊れ方まで共通になった。関数が1つであることは再利用性の観点では正解で、キャプションが正常に入っている限り問題ない。ただしキャプションが空になるという経路に対して、共有している全てのガードが同時に無力化されます。

直しは2段階でした。

第一段：投稿前にキャプションが入ったことを確認する。

def insert_caption_with_verify(page, caption: str) -> None:
    # 手段1: keyboard.insert_text
    # 手段2: clipboard経由でpaste
    # 手段3: JSでvalue直接セット
    for method in [_keyboard_insert, _clipboard_paste, _js_set_value]:
        method(page, caption)
        actual = page.locator('[data-lexical-editor]').inner_text()
        if len(actual) >= len(caption) - 5:  # 5文字マージン
            return
    raise RuntimeError(f"キャプション投入失敗: 期待{len(caption)}文字/実測{len(actual)}文字")

「入れた」の判定を keyboard.insert_text の戻り値でなく、フィールドの実際の文字数で行います。APIが「入れた」を返しても、DOMのレンダリングが追いついていない場合があります。実走確認では キャプション投入 1257文字 / 期待1257文字 と出てから着地確認13秒で成功しました。

第二段：照合キーが空になる経路を入口で止める。

def normalize_caption_key(text: str) -> str:
    # ...（前述の正規化）
    result = text[:24] if len(text) >= 24 else text
    if not result:
        raise ValueError("照合キーが空: 投稿前に中止してください")
    return result

空キーは「一致しない」ではなく「照合が成立していない」という第3の状態です。「成立していない照合」の結果を ok:false として台帳に積むと、リトライが走って副作用が増えます。入口で止めて明示的にエラーにすることで、「照合不能 → 再投稿」という連鎖を断ちます。

TikTok が15日連続でエラーを吐いていたが、投稿は全部できていた

9月8日に発覚したのは、post_reel_tiktok.py が9月24日以降ずっと RuntimeError で終了していたという話です。15日間、台帳には毎日 ok:false が積まれていました。ところがTikTokのダッシュボードを確認すると、投稿は全部成功していました。

原因は、成功判定がベンダーの固定文言に依存していたことです。スクリプトは投稿ボタン押下後、ページbodyに5種類の固定文言が出るまで120秒ポーリングしていました。

SUCCESS_TEXTS = [
    "動画が投稿されました",
    "投稿を作成しました",
    "コンテンツが公開されました",
    # ...他2種
]

TikTokは投稿後に投稿管理ページ（URLに /tiktokstudio/content を含む）へ遷移していましたが、その画面のサイドバーの語は「管理する」ではなく**「管理」**に変わっていました。いずれの SUCCESS_TEXTS にも一致しないので、毎回 RuntimeError を投げて終わっていた。

15日間に気づかなかった理由が2つあります。第一に、台帳の skip 判定が ok:true のエントリしか見ていなかったこと。ok:false として記録された動画IDは、次回実行時に「まだ投稿していない」として再処理の候補になります。ただし実際には投稿済みなので、仮に再実行が走れば同じ動画が2本公開されていました。たまたま重複が出なかったのは、台帳に ok:false が積まれた動画IDがキューの最後に来ておらず、新規の動画優先で処理が回っていたからです。

第二に、失敗時の例外にページのURLもbody先頭も載せていなかったこと。RuntimeError: タイムアウト: 成功文言が見つかりません という1行だけでは、「TikTokが文言を変えた」という診断ができません。エラーが出たとき現場に証拠が残らないと、復旧に要する時間が膨らみます。15日かかったのはこの記録の欠如が原因です。

直しは判定の多重化です。

def _is_posted_successfully(page) -> bool:
    # 判定1: 従来の成功文言（TikTokが変えるかも）
    if any(t in page.inner_text("body") for t in SUCCESS_TEXTS):
        return True
    # 判定2: URLがuploadを離れてcontentに着いた
    if "/tiktokstudio/content" in page.url:
        return True
    # 判定3: 自分が投げたキャプションの先頭12文字が本文にある
    if normalize_caption_key(caption)[:12] in page.inner_text("body"):
        return True
    return False

判定3の「自分が投げたキャプションで確認する」というアプローチが一番壊れにくいです。ベンダーがUIを変えても、投稿したのが自分なら自分のテキストは画面に出ます。ベンダーの語彙に依存する判定1と2はフォールバック扱いになります。

学習ノートにはこう記録しました。

ベンダー文言に依存する判定は、落ちたときの現物を残さないと直せない

エラーの記録設計は、リトライ設計と同じくらい重要です。page.url と body 先頭200文字を必ず例外に載せるようにしたのはこの事故からです。

X（旧Twitter）の引用ポストが5日間ずっと「0件」に見えた

9月10日に気づいたのは、9月5日以降の引用ポストがすべて quoted=0 で計上されていたことです。実際には投稿されていましたが、着地照合スクリプトが全件 unverified を返して件数を積まなかった。

原因はPlaywrightのstrict modeとDOM構造の変化でした。

// 変更前
const tweetText = await article.locator('[data-testid="tweetText"]').innerText()

引用ポストのarticle要素には tweetText が2個入っています。自分の本文と、埋め込まれた元ポストです。Playwrightの innerText() はstrict modeでは要素が複数あるとエラーを投げます。このエラーがcatchされて空文字になり、照合が unverified に倒れ、quoted=0 で計上されていました。

直しは .first() で先頭要素だけを読むことです。

const tweetText = await article.locator('[data-testid="tweetText"]').first().innerText()

1行の変更ですが、5日分の偽アラートが止まりました。health.mjs が「本日0件」の通知をデスクトップに出し続けていたので、5日間は「引用ポストが全部コケているが原因不明」という状態でした。実際には何も壊れておらず、投稿は全部成功していた。

この事故はTikTokの15日連続exit 1と完全に同じ構造です。「ベンダー側DOMが1要素→複数要素に変わると、strictな照合が失敗に倒れて偽陰性になる」——構造は同じでも、発生したのは別のプラットフォームで2週間後のことです。1箇所で学んだパターンを横断してチェックできていれば、5日ではなく0日で塞げました。

これが最も痛かった詰まりの話です。「同じ壊れ方を知っていた」にもかかわらず、別プラットフォームでの再発を防げなかった。修正を入れたあと、同型の照合を使っている全レーンの reply.mjs にも同じ .first() を予防的に足しましたが、それは事故後の処置です。

3つの失敗に共通しているもの

8月30日の空キャプション16本、TikTokの15日連続exit1、X引用ポストの5日間0件——3つに共通しているのは「照合器が壊れていることを、照合器自身が教えられない」という構造です。

スクリプトは ok:false を返し続けます。台帳には失敗が積まれます。スケジューラは再実行を予約します。この連鎖のどこにも「判定の材料が壊れている」という信号は出ません。スクリプトは正しく動いています——ただし、間違った材料を使って。

リトライ設計の正典（retry-and-giveup-design.md）には次の一文があります。

同じ失敗を3回投げても結果は変わらない。回数でなく渡している内容を疑う。

今回の3つはすべてこのケースです。リトライ回数を2回に減らしても、3回のままでも、照合の材料が壊れている限り結果は変わりません。判定が3回とも同じ方向に倒れ続ける場合——偽陰性が連続する場合——、まず疑うべきは「何を照合材料にしているか」です。

inner_text のレンダリング依存、固定文言のベンダー変更、strict modeの要素数変化——3つとも「自分が書いた照合ロジックは正しいが、外側の環境が照合を無効化した」という型です。この型に対するリトライ回数の増減は無力です。材料を変えるか、照合の仕方を変えるか、どちらかしかありません。

今の環境では、着地確認が失敗した場合に即リトライするのではなく、「なぜ失敗したか」を別経路で問うステップを挟んでいます。失敗のときにAPIを直接叩いて「投稿が存在するか」を確認し、存在すれば already-live として記録します。存在しなければ初めて「本当に未投稿」と確定します。この「確認してから判断する」一手間が、副作用の重複を防ぐ最後の壁です。

つまずきポイント

自分が実際に踏んだ地雷を網羅します。どれも「スクリプトは正常に終了しているのに現実の世界だけが壊れる」という型です。

絵文字以外の記号もinner_textから消える。★（U+2605・Unicodeカテゴリ So）はBMP内の文字ですが、IG のレンダリングで inner_text に安定して出るとは言えません。ord(c) <= 0xFFFF で足りると思っていましたが、カテゴリ So（Symbol, Other）と Sk（Symbol, Modifier）を追加除去する理由はここにあります。正規化の条件を「BMP内かどうか」だけで決めると次の事故が来ます。
照合キーを片側しか正規化しない。キャプション文字列だけ正規化してDOM取得側を生のまま比較すると、絵文字が消えた分だけ文字数がずれ、新しいミスマッチが生まれます。normalize_caption_key を必ず両側に通す——これは実装の中で最も忘れやすいポイントです。
照合キーが空になる経路を潰していない。8月30日に本文のないカルーセルが16本公開された根本原因がこれです。ig_autopost.py の keyboard.insert_text がキャプション欄に入らず、0/2200のまま「シェア」を押しました。投稿前重複ガード（has_existing_caption）と投稿後着地照合（_verify_landed）は同じ24字キーを共有しているので、空キーになった瞬間に両方が同時に無力化されます。結果、重複ガードが「まだ出ていない」と言い、着地照合が「出ていない」と言い、同じ内容をリトライし続けました。
「防止」と「検知」が同じ照合器を共有している。コードの再利用性という観点では正しい設計でも、その関数が壊れた瞬間に防止と検知が同時に死にます。単一障害点が隠れています。少なくとも一方は別の材料（投稿数のデルタ・API件数）で確認する必要があります。
ベンダーの固定文言に依存した成功判定。TikTokが投稿後にページ遷移し、サイドバーの語が「管理する」から「管理」に変わっただけで、登録していた5種類の固定文言すべてに一致しなくなりました。post_reel_tiktok.py は投稿するたびに RuntimeError を投げ、15日間 ok:false を積み続けました。TikTokのダッシュボードを直接開いて初めて「全部投稿できていた」とわかりました。
失敗例外にページURLもbody先頭も残していない。RuntimeError: タイムアウト: 成功文言が見つかりませんの1行だけでは「TikTokが文言を変えた」という診断ができません。page.url と body 先頭200文字が例外に入っていなかったせいで、切り分けに15日かかりました。
Playwright strict modeで複数要素がthrowする。X（旧Twitter）の引用ポストのarticle要素には [data-testid="tweetText"] が2個あります——自分の本文と、埋め込まれた元ポストの本文です。innerText() がstrict modeでthrowし、空文字を返し、照合が unverified に倒れ、9月5日以降の引用ポストがすべて quoted=0 で計上されました。.first() を1行追加するだけで解決しましたが、5日間気づきませんでした。
「確認不能」を「未投稿」と誤訳する設計。APIが壊れているときにDOMへフォールバックすると、結局 inner_text の照合に戻ります。「APIがJSONを返したのに投稿が見つからない」は確定情報（未投稿）ですが、「8回ともJSONが返らなかった」は単に確認できなかっただけです。この2つを区別せずにDOMへ逃げると、偽陰性の再発経路が残ります。
同じ失敗を回数を増やして3回投げる。note-autolikeのrewriteが3日間ゼロ件だったのは、バリデータが58字超を弾くのに生成プロンプトに字数制限が一言も書かれていなかったためです。askClaude は失敗しても同一プロンプトを3回投げ直すだけで、3回とも同じ63字タイトルを返しました。制約はバリデータと生成プロンプトの両方に書かなければ機能しません。
スロット取得失敗で即exit 0する。browser-slot.sh がグローバル枠（3本）を取得できなかった瞬間に SKIP: global limit reached を出して即終了していたため、12時台12件・09時台9件・11時台8件が起動すらせず消えました。600秒待機オプションを追加し、再試行間隔を15〜45秒のランダムにしてから空振りはほぼゼロになりました。固定間隔にすると全ジョブが同じ瞬間に殺到する（thundering herd）ので、ランダム幅は必須です。
フォールバックの降り先が同じ壁に当たる。gen_note_thumbs.py で実Chrome→同梱chromium→env の3段降り先を追加しましたが、3段目まで同じ90秒 rc=-9 で終わりました。症状が同じでも原因は同じとは限りません。降り先を追加する前に「その降り先は元と別の壁に当たるか」を1回実測してから配線すべきでした。
IG delete APIが200を返しても削除されていない。セッション（sessionid）が切れた状態でdeleteAPIを叩くと、200を返しながらHTMLを戻します。8月28日の重複3本を削除しようとして1件も消えていませんでした。「APIが200を返した」を成功の定義にしない——この教訓は投稿確認と全く同じです。
best-effort素通りで下流でしか気づかない。IGリールのクロップ比率選択で、query_selector がNoneを返しても黙って素通りする分岐がありました。ラベルが「オリジナル」「Original」「9:16」「元の写真」「元の比率」と日によって揺れる一方、コード側の候補リストは固定でした。9:16が選ばれず1:1のまま「次へ」に進み、グリッドで左右が切れた動画が公開されました。選択・切替の操作は、選択できたことを実測で確認してから次のステップへ進む必要があります。
note CTAの貼付結果を信用した。9月2日にnote.comが引用ブロックを落とす仕様変更をしました。スクリプトは末尾の署名文字列の一致で検証していたので、落とされた記事を「未反映」と判定して貼り直し続け、重複CTA 59本＋署名欠落31本が発生しました。エディタの「入れた」という記録でなく、公開ページを実際に読み戻して検証するべきでした。
同型のバグを別プラットフォームで再発させる。「DOM1要素→複数要素に変わると strict な照合が失敗に倒れて偽陰性になる」という構造は、TikTokで学んでいました。にもかかわらず2週間後にXで同じ構造を踏みました。修正時に全レーンの同型箇所を予防的に直す習慣がなかった結果です。1箇所で学んだパターンを横断してチェックできていれば、5日ではなく0日で塞げました。

ベストプラクティス

上の詰まりを経て今の環境で実際に適用しているパターンを整理します。

1. 照合キーは必ず両側に同じ正規化関数を通す

def normalize_caption_key(text: str) -> str:
    import unicodedata
    text = "".join(c for c in text if not c.isspace())
    text = "".join(
        c for c in text
        if ord(c) <= 0xFFFF
        and unicodedata.category(c) not in ("So", "Sk")
    )
    return text[:24] if len(text) >= 24 else text

キャプション文字列とDOM取得テキストの両側に同じ関数を通します。片側だけでは変換後の文字数がずれ、新しいミスマッチが生まれます。

2. 照合キーが空になる経路を入口でエラーにする

result = text[:24] if len(text) >= 24 else text
if not result:
    raise ValueError("照合キーが空: 投稿前に中止してください")
return result

空キーは「一致しない（ok:false）」ではなく「照合が成立していない」第3の状態です。ok:false として台帳に積むと次のリトライが走って副作用が増えます。

3. 副作用のある操作の確認は「相手側の実体」で行う

def _verify_via_api(shortcode: str, caption: str) -> dict:
    for attempt in range(8):
        resp = _fetch_profile_api(user_id=DS_USER_ID, cursor=...)
        if resp is None:
            continue
        for post in resp.get("edges", []):
            key = normalize_caption_key(...)
            if key and key == normalize_caption_key(caption):
                return {"ok": True, "source": "api"}
        return {"ok": False, "source": "api", "reason": "not_found"}
    return _verify_via_dom(caption)

「APIがJSONを返したのに投稿が見つからない」は確定情報で、DOMへ逃がしません。8回ともJSONが返らないときだけDOMを1回だけ使います。「確認不能」と「未投稿」は別の状態です。

4. fail-closed設計で確認不能時は「投稿済み」扱いにする

重複（後から消す手間・公開されていた時間）と遅延（次のジョブが補う）の被害は非対称です。確認できないときは軽いほうを選び、{"ok": True, "note": "unverified-assumed-live"} として台帳に積みます。ok:true で記録することで、次のリトライが走りません。

5. 「防止」と「検知」に別の材料を使う

投稿前重複ガードと投稿後着地照合が同じ24字キーを共有すると、一方が壊れれば両方が死にます。投稿数デルタ（投稿前後のプロフィール投稿数の差分）を独立した確認材料として並走させます。キャプションと件数という2つの材料が独立して動いているため、片方が壊れても判定が完全には死にません。

6. キャプション投入は「フィールドの実際の文字数」で判定する

def insert_caption_with_verify(page, caption: str) -> None:
    for method in [_keyboard_insert, _clipboard_paste, _js_set_value]:
        method(page, caption)
        actual = page.locator('[data-lexical-editor]').inner_text()
        if len(actual) >= len(caption) - 5:
            return
    raise RuntimeError(f"キャプション投入失敗: 期待{len(caption)}文字/実測{len(actual)}文字")

「入れた」の判定はAPIの戻り値でなく、フィールドの実際の文字数です。3手段試して読み戻しで検証する——実走確認ではキャプション投入 1257文字 / 期待1257文字と出てから着地確認13秒で成功しました。

7. 成功判定はベンダー文言でなく「自分が投げたテキスト」で行う

def _is_posted_successfully(page, caption) -> bool:
    if any(t in page.inner_text("body") for t in SUCCESS_TEXTS):
        return True
    if "/tiktokstudio/content" in page.url:
        return True
    if normalize_caption_key(caption)[:12] in page.inner_text("body"):
        return True
    return False

判定3の「自分が投げたキャプションで確認する」が最も壊れにくいです。ベンダーがUIを変えても、自分が投稿したテキストは画面に出ます。固定文言はフォールバック扱いです。

8. 失敗例外には必ず page.url とbody先頭200文字を載せる

ベンダー文言に依存する判定が壊れたとき、現場に証拠がなければ診断に15日かかります。例外の1行に page.url と page.inner_text("body")[:200] を必ず載せます。

9. Playwright strict modeは .first() を明示し、全レーンに予防的に入れる

// 変更前: strict modeでthrow
const tweetText = await article.locator('[data-testid="tweetText"]').innerText()
// 変更後
const tweetText = await article.locator('[data-testid="tweetText"]').first().innerText()

修正した時点で、同型の照合を使っている全レーンを確認して同じ修正を入れます。「1箇所で学んだが別プラットフォームで再発」を防ぐための習慣です。

10. 同じ失敗が3回続いたら、回数でなく渡している内容を疑う

retry-and-giveup-design.md に書いた通りです——「同じ失敗を3回投げても結果は変わらない。回数でなく渡している内容を疑う。」 決定論的な失敗（バリデーション違反・ログイン切れ・ベンダー文言の変化）はリトライ前に失敗の種類を分類しなければ、回数を増やすことは資源を焼くだけです。

11. リトライ回数は「副作用を何回起こしてよいか」で決める

冪等でない操作に3回リトライを付けることは、副作用を最大3回許容する宣言と同じです。SNS投稿のリトライを設計する前に「この操作は冪等か」を問います。冪等でなければリトライ前に必ず現在の状態を確認する手順を挟みます。

12. スロット待ちは即SKIPでなく最大600秒待機する

BROWSER_SLOT_WAIT_SEC=600  # 0にすれば従来の即skip
# 再試行間隔はランダム（thundering herd 防止）
sleep $((RANDOM % 30 + 15))

BROWSER_SLOT_WAIT_SEC=0 で従来の即skipと完全一致するため、既存の30本以上のlaunchdジョブとの後方互換を保てます。

13. 「待った/諦めた/スキップした」を台帳のログで区別する

waited=600s で諦めた記録と、exit 0 で何もせず終わった記録が同じ行に見えると「効率が悪い」と「そもそも走っていない」の区別がつきません。偽陰性の連続が「照合が壊れている」なのか「本当に走っていない」なのかを台帳から判定するために、ログに理由を必ず残します。

14. リトライを追加したら、フォルト注入を同じコミットに入れる

# 本番では無効、注入時だけ有効
WA_API_FAIL_ONCE=2 node index.js
# → "api retry attempt=1/3" → "attempt=2/3" → exit 0 で完走
# 未設定なら retry ログが1行も出ない

フォルト注入なしでリトライを「追加した」と言っても、間欠障害が再現できないため実際に経路を通ったことを示せません。git diff を見せて終わりにしない。

15. 公開ページを読み戻してから「反映された」と記録する

エディタの「入れた」という戻り値を信用しません。noteのCTA重複90本はこの確認ステップがなかったことで発生しました。reader-state-not-self-record の原則——自分の送信ログでなく相手側の実体で判定する——は投稿確認と貼り付け確認の両方に適用します。

まとめ

8月28日から約2週間で3つのプラットフォームが連続して同じ型の壊れ方をしました。IG の3本重複・TikTok の15日連続exit 1・X引用ポストの5日間ゼロ件——どれも「照合器が正常に動いているのに照合の材料が壊れている」という構造です。

スクリプトはエラーを投げません。台帳には ok:false が積まれ続け、スケジューラは淡々と再実行を予約します。「ジョブが壊れている」という信号はどこにも出ません。気づくのは外から現実を直接見たときだけです——プロフィールに3本並んだカルーセル、ダッシュボードで確認した投稿一覧、1週間分のゼロカウント通知の後でようやく開いた台帳。

retry-and-giveup-design.md の一文がこの構造を端的に言い切っています。

同じ失敗を3回投げても結果は変わらない。回数でなく渡している内容を疑う。

今の環境では着地確認が失敗したとき、即リトライではなく「なぜ失敗したか」を別経路で問うステップを挟みます。APIを直接叩いて投稿の存在を確認し、存在すれば already-live として ok:true で記録します。存在しなければ初めて「本当に未投稿」と確定します。

この「確認してから判断する」一手間が、171本のジョブを自律させる前提条件です。環境を作るとは、自分が操作する回数をゼロに近づけることです。そのゼロを保つには、判定の材料が何であるかを問い続けることが必要です。照合器は壊れません。壊れるのは、照合器が見ている材料です。

仕組みの全体像・月120万の内訳・30日手順は有料noteにまとめています。
📕 Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート

Lily（@bokuwalily）― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています

制作物・記事は bokuwalily.com にまとめています🖥️
AIで「寝てても回る仕組み」を作って月120万にした話は noteの有料記事に💰
OSS: github.com/bokuwalily 🐙
最新情報・お問い合わせは X @bokuwalily へ🌍
AI導入・自動化の相談と実装テンプレ7本の配布は公式LINE から💬

皆さんの ❤️ やシェアが励みになります！