🎨 サムネ髪色を関数1つで5アカウント全部に固定した話

月10万円の大学生が気づいたら月商120万。その自動化基盤の細部を、手が止まった瞬間も含めて書いていきます。

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

SNSで量産型の記事ビジネスをやっている人が最初につまずくのは、「記事を量産すること」ではなくて「量産したあとのブランドが崩れること」です。

私は今、5つのnoteアカウントを並走させています。テーマはバラバラで、note1（@bokuwalily）はAI副業の実録、note2（@bokumolily）は書籍・商品レビュー、build（@watashiwalily）はSMBへのAI月額課金の話、affiliate（@watashimolily）はアフィリエイトのリアル、funnel（@lilydesu）は収益化ファネルの記録。ジャンルを分けているのは、アルゴリズムに刺さる文脈を増やすためです。

でも5アカウントを同じパイプラインで動かすと、ある問題が必ず起きます。**「どのアカウントから出た記事なのか、サムネを見ただけでは判別できなくなる」**というやつです。

記事の中身はLLMが書き分けてくれます。ところがサムネは別系統で生成していたので、キャラクターの髪色が毎回違う。build（青）レーンで出した記事なのに、キャラが赤髪で出てくる日もある。アカウントごとにアイコンの髪色を決めてあるのに、サムネがそれに従っていなかった。

これは見た目だけの問題ではありません。フォロワーがサムネでアカウントを認識する、という前提が崩れると、「この人の記事だから読む」という判断が起きなくなります。ブランドが積み上がらない。全部バラバラの他人に見える。

逆を言えば、サムネのキャラを各アカウントのアイコンと同じ髪色に固定するだけで、読者の記憶に「このアカウントの雰囲気」が刷り込まれていく。これは複数アカウント運用における、地味だが効く施策です。

当時、私は自動投稿スクリプトを毎日動かしていました。1日に5レーン合計で10本以上の記事が公開されるペースです。「サムネの髪色がバラバラになっている」に気づいたとき、すでに44本の公開記事が誤った髪色のサムネで出ていました。手で差し替えていたら丸1日潰れる量です。ここを自動化で解決したのが、今回書く話です。

全体の流れ

問題は3層に分かれていました。

【根本原因】
daily-codex-note.js がレーン→ソース変換で誤マッピング
  build   → 'note'  (赤髪になる)
  affiliate → 'note2' (黒髪になる)

        ↓ 修正: source = lane.key をそのまま渡す

【going-forward（新規記事）】
gen-codex-thumbnail.mjs の hairForSource(source) が
HAIR_BY_SOURCE テーブルを引いて正しい髪色を返す

        ↓ 並行して実行

【レトロフィット（過去44本）】
retrofit-hair-batch.mjs        → note2（黒髪）27本
retrofit-hair-codexlane.mjs   → build（青）6本 / affiliate（金）6本 / funnel（黄緑）5本
  └ API: GET /api/v2/creators/{urlname}/contents で公開記事一覧取得
  └ ensureCodexThumbnail() でサムネ再生成
  └ swap-eyecatch.js でPlaywright差し替え
  └ state/retrofit-hair-*.json で冪等（途中再開可）

hairForSource() の実装

修正の中心は src/gen-codex-thumbnail.mjs に追加した20行弱のコードです。

// 髪色は「記事を出すアカウントのアイコンの髪色」に合わせる(2026-07-20 ユーザー指示・以後固定)。
// note1=赤 / note2=黒 / build=青 / affiliate(AIサブスク)=金 / funnel(lilydesu)=黄緑。
export const HAIR_BY_SOURCE = Object.freeze({
  note:      { en: 'red-haired',          jp: '赤髪' },
  note2:     { en: 'black-haired',        jp: '黒髪' },
  build:     { en: 'blue-haired',         jp: '青髪' },
  affiliate: { en: 'blonde',              jp: '金髪' },
  funnel:    { en: 'yellow-green-haired', jp: '黄緑髪' },
});

export function hairForSource(source) {
  return HAIR_BY_SOURCE[source] || HAIR_BY_SOURCE.note;
}

Object.freeze() をかけているのは、スクリプトのどこかで誤って上書きされるのを防ぐためです。フォールバックは note（赤髪）にしてあります。未知のソースが来たときに黙って壊れるより、デフォルトに落とす方がデバッグしやすい。

この hairForSource() はサムネ生成のプロンプト組み立て部分に差し込まれます。

function brandStyleForSource(source) {
  return `${BRAND_STYLE_BASE}, fixed young ${hairForSource(source).en} anime boy as the hero`;
}

Codexへ渡すプロンプトの中に「固定キャラ＝〇〇髪のアニメの男の子」が英語で注入され、画像生成器がその指定通りのキャラを描く。LLMがCLI引数を無視して値を捏造する事故が過去に起きていたので（ハンドルに実名が焼き込まれた件）、髪色も同様に環境から確定した値を直接プロンプトへ埋め込む方針にしています。

この関数は無料サムネ（gen-codex-thumbnail.mjs）と有料カバー（gen-paid-cover.mjs）の両系統に注入されています。二系統で定義を共有しているので、変えるときは1ファイルを直すだけです。

going-forwardバグの根本原因と修正

関数を作っても、呼び出し側が間違ったキーを渡していたら意味がありません。実際、daily-codex-note.js がまさにそれをやっていました。

コミット 7b78ca5 のdiffがそのまま証拠です。

- const source = lane.key === 'build' ? 'note' : lane.key === 'affiliate' ? 'note2' : 'funnel';
+ // (旧: build→note/affiliate→note2 に再マップしていたが、それだと赤/黒髪になり要望と食い違うため)
+ const source = lane.key;

修正前のコードは build を 'note'（赤髪）に、affiliate を 'note2'（黒髪）に変換していました。おそらく初期実装のときに「ソース名をサムネ系統の名前に合わせないといけない」という誤解があって、手動で変換テーブルを書いてしまったのだと思います。HAIR_BY_SOURCE を作った段階でその変換は不要になった——というより、むしろ邪魔になっていた。

修正はたった1行です。lane.key をそのまま source に渡す。hairForSource('build') が呼ばれれば青髪が返る。当たり前の話なのに、途中の間接変換が正しさを壊していた。

レトロフィットバッチの内側

going-forwardの修正はコミット1行で終わりました。問題はここからです。すでに公開されている44本の記事が、今も誤った髪色のサムネをつけたまま生きています。

手で44本を直す気は最初からありませんでした。サムネの差し替えはPlaywrightで自動化済みだったので、公開記事一覧を取得して、再生成して、差し替えるという3ステップを組めばいい。ただ、5レーン全部を1本のスクリプトに押し込むのは避けました。Playwrightのプロファイルが衝突する問題（後述します）があったので、note2用の retrofit-hair-batch.mjs と、build/affiliate/funnel用の retrofit-hair-codexlane.mjs を分けて作っています。

公開記事一覧をどうやって引くか

noteには非公式ながら実用的なAPIがあります。GET /api/v2/creators/{urlname}/contents に kind=note&status=published をつけると、そのアカウントの公開記事をページ番号順で返してくれます。レスポンスの data.contents の各要素に key（記事固有ID）、name（スラッグ）、eyecatch（現行サムネURL）が入っています。

スクリプトはこのAPIを page=1 から順に叩き、is_last_page: true が返ってくるまでページをめくります。note2だと27本がヒットしました。

async function fetchPublishedNotes(urlname) {
  const notes = [];
  let page = 1;
  while (true) {
    const res = await fetch(
      `https://note.com/api/v2/creators/${urlname}/contents?kind=note&status=published&page=${page}`
    );
    const json = await res.json();
    notes.push(...json.data.contents);
    if (json.data.is_last_page) break;
    page++;
  }
  return notes;
}

このAPIは認証不要で叩けます。自分のアカウントの公開記事を列挙するだけなので、Cookieなしで取得できる点が助かりました。

ensureCodexThumbnail() で再生成を積む

記事一覧が手に入ったら、各記事について ensureCodexThumbnail() を呼んでサムネを再生成します。この関数は gen-codex-thumbnail.mjs に実装されているもので、通常の記事投稿フローでも使っているものです。

動作の大筋は「~/content/note-thumbnail-pipeline/queued/ にJSONリクエストをenqueueする→watcher launchdが起動→Codexに生成を依頼→done/ に結果が届く→validate_thumbnail_delivery.py で検証→記事パスと同名の .png にコピー」という流れです。

レトロフィット用に変えたのは、記事のスラッグ（name）と source（note2、build 等）を引数で渡すだけで動くように呼び出し側を薄くした点だけです。

await ensureCodexThumbnail({
  title: article.name,
  source: lane.key,         // ← hairForSource() がここを参照する
  outputPath: tmpPngPath,
  maxWait: 120_000,
});

source に正しい lane.key を渡すことで、hairForSource('build') が青髪を返し、生成されるサムネが正しい髪色になります。going-forwardの修正と根が同じです。

swap-eyecatch.js でPlaywright差し替え

サムネが手元に生成されたら、次は公開済み記事に貼り替えます。これを担うのが src/swap-eyecatch.js です。

手順は「記事の編集画面を開く→既設アイコンのdeleteボタンをクリック→ファイルインプットに新しいPNGを渡す→「更新する」ボタンを押す」という4ステップです。各ステップでスクリーンショットを保存しているので、途中で止まったときに目視できます。

Playwright側のコードで気をつけたのは、「削除ボタンが出ない記事」への対処です。最初からアイキャッチが設定されていない記事は削除ステップをスキップして、いきなりアップロードへ飛びます。これをやらないと、存在しないボタンを探してタイムアウトします。

const deleteBtn = await page.$('button[aria-label="アイキャッチ画像を削除"]');
if (deleteBtn) {
  await deleteBtn.click();
  await page.waitForTimeout(500);
}
// 削除の有無に関わらずアップロードへ

冪等性をstate JSONで担保する

レトロフィットで一番怖いのは「途中で死んだとき、どこまで終わったかわからなくなる」ことです。27本を順番に処理していて、15本目でネットワークが切れたりPlaywrightがクラッシュしたりすると、最初からやり直すのも怖い（二重差し替えになる可能性がある）し、放置するのも怖い。

対策として state/retrofit-hair-note2.json に進捗を書いておく方式にしました。

{
  "processed": [
    { "key": "nXXXXXX", "status": "done", "ts": "2026-07-20T04:12:00Z" },
    { "key": "nYYYYYY", "status": "done", "ts": "2026-07-20T04:14:30Z" }
  ]
}

スクリプトの先頭でこのJSONを読み込み、processed に含まれる key はスキップします。「どこで止まっても node retrofit-hair-batch.mjs を再実行すれば続きから動く」状態です。

build/affiliate/funnel用の retrofit-hair-codexlane.mjs も同様に state/retrofit-hair-codexlane.json を使っています。

レーン別の実績

最終的な実績は以下の通りです。

レーン	アカウント	髪色	対象本数	完了
note2	@bokumolily	黒	27	27/27
build	@watashiwalily	青	6	6/6
affiliate	@watashimolily	金	6	6/6
funnel	@lilydesu	黄緑	5	5/5

合計44本。note1（赤髪）はもともと正しかったので対象外です。note1だけは誤マッピングの被害を受けなかった。daily-codex-note.js の変換テーブルが build と affiliate に対してのみ間違っていたので、source='note'（note1）と source='note2' はそのまま通っていたからです。

---

私が詰まった話

実装の大枠は上に書いた通りですが、一発で動いたわけではありません。詰まった箇所を3つ、症状・原因・直し方のセットで書いておきます。

詰まり① --limit が全然効かない

テスト実行でいきなり27本を処理したくなかったので、--limit 5 をつけて小さく回そうとしました。コマンドはこんな感じです。

node retrofit-hair-batch.mjs --urlname bokumolily --limit 5

結果、27本全部が処理されました。--limit 5 が完全に無視されています。

原因を探ってみると、引数パーサーに典型的なミスがありました。

// バグのあったコード
for (let i = 0; i < argv.length; i++) {
  if (argv[i] === '--limit') {
    opts.limit = parseInt(argv[i + 1]);
  }
}

// 使う側
if (count >= opts.limit) break;

--limit が引数列の末尾に置かれた場合、argv[i + 1] は undefined になります。parseInt(undefined) は NaN を返します。そして count >= NaN は 常に false です。どれだけカウントが増えても上限に引っかかりません。

ループの終了条件がずっと成立しないまま全記事を処理してしまいました。

直し方は2ステップです。まず parseInt の結果が NaN のときにエラーを投げるようにして、引数ミスを即座に気づける状態にします。次に --limit を --urlname より前に置くよう引数の順序を決め打ちにしました。

opts.limit = parseInt(argv[i + 1]);
if (isNaN(opts.limit)) throw new Error(`--limit の次に数値が必要です: ${argv[i + 1]}`);

気をつけてほしいのは、この状態で再実行したときです。state JSON に「done」が27本書かれているので、--limit 5 をつけて再実行しても5本がスキップされるだけで新規処理はゼロになります。state JSONを消して最初からやり直す必要がありました。冪等性は助かる仕組みですが、「全部やり直したい」ときには邪魔になります。state JSONは --reset フラグで削除できるようにしておくべきでした。

詰まり② Playwright プロファイルが衝突する

retrofit-hair-codexlane.mjs（build/affiliate/funnel 用）は、各レーンの Playwright プロファイルを開いてサムネを差し替えます。プロファイルは profiles/codex-build・profiles/codex-affiliate・profiles/note3 の3つです。

問題は、これらのプロファイルは毎日の投稿ジョブでも使われているということです。daily-codex-note.js が朝の特定時刻に起動してPlaywrightを立ち上げます。Chromiumは同一のプロファイルディレクトリを複数プロセスが同時に使えません。レトロフィットスクリプトがジョブの実行中に走ると、Chromiumが起動すらできずに死にます。

症状はわかりやすくて、こんなエラーが出ます。

Error: Failed to launch chromium because another instance is already running.

最初は「投稿ジョブが終わってから手動で実行すればいい」で済ませようとしました。でも深夜に実行するとなると、「今ジョブが動いているか」を毎回確認するのが面倒です。

対策として ps aux でプロセスを検査するコードを入れました。

async function waitForProfileFree(profileDir, maxWaitMs = 30 * 60 * 1000) {
  const start = Date.now();
  while (Date.now() - start < maxWaitMs) {
    const { stdout } = await execa('ps', ['aux']);
    if (!stdout.includes(profileDir)) return; // 使用中プロセスなし
    console.log(`プロファイル使用中: ${profileDir} → 60秒待機`);
    await sleep(60_000);
  }
  throw new Error(`${maxWaitMs / 60000}分待ってもプロファイルが空きませんでした`);
}

プロファイルパスが ps aux の出力に含まれていなければ空きと判断し、含まれていれば60秒待って再チェックします。最大30分待つ設計です。これで「投稿ジョブの実行中にうっかりレトロフィットを走らせる」ミスを防げます。

実際に試したら、朝8時台に走らせたとき、ちょうど daily-codex-note.js が動いていて12分待機してから再開、という挙動を確認しました。state/retrofit-hair-codexlane.json の進捗が残っているので、待機後の再開も完全に冪等です。

詰まり③ サムネのアニメキャラに🐾が豆腐になる

レトロフィットでサムネを再生成していたとき、一部の記事でサムネの文字が□（豆腐）になる問題が起きました。具体的には funnel レーンの記事タイトルに絵文字が含まれているものです。

たとえばタイトルが「🐾 AIが書いたアフィリ記事で実際に売れた話」のとき、サムネ上の文字合成スクリプト overlay_note_text.py がヒラギノ角ゴW9で描画しようとして🐾が豆腐になります。ヒラギノはSFシンボルや絵文字フォントを内包していないので、U+1F43E（肉球）を表示できません。

症状は静かです。スクリプトは正常終了し、PNG自体は生成されます。ただ、そのPNGを目で見ると文字の先頭に□がある。サムネとして公開されてから気づくパターンです。

修正は sanitize_text() 関数に絵文字除去を追加しました。

import re

EMOJI_PATTERN = re.compile(
    "["
    "\U0001F300-\U0001F9FF"   # 顔・物・動物・食べ物・場所
    "\U00002600-\U000027BF"   # その他記号（☀🌙等）
    "\U000023F0"              # 目覚まし時計（U+27BFの除外漏れ対策）
    "]+",
    flags=re.UNICODE
)

def sanitize_text(text: str) -> str:
    return EMOJI_PATTERN.sub('', text).strip()

--title と --kicker に渡す前に sanitize_text() を通すことで、絵文字が消えた状態で描画されます。

これは根本解決ではありません。「絵文字対応フォント（Noto Color Emoji等）を合成に組み込む」が本来の直し方ですが、合成スクリプトのフォントスタックを変えるとすべてのサムネの品質に影響するため、当面は除去で運用することにしました。

なお、この修正が効いているかの確認方法として、同じ絵文字ありタイトルで修正前後の PNG を生成して SHA-256 を取り、除去した場合のハッシュが一致しているかを確認しました。絵文字の有無で見た目は変わりますが、除去後の結果が決定論的に同じになるかのチェックです。修正前後で除去済みバージョンのハッシュが一致したので回帰なしを確認できました。

---

実装を振り返ると、今回の作業で一番密度が高かったのはレトロフィットではなく、根本原因を1行の修正で封じたあと、その1行が効いているかを44本の実記事で証明する部分でした。hairForSource() の実装は20行、source = lane.key の修正は1行。でもレトロフィットを含む全体の作業量は300行超のスクリプト2本です。

小さいバグが積み上がった44本の負債を返済するコストは、バグを書いた瞬間のコストより何倍も大きい。これは今回の話に限らず、自動化パイプラインを複数並走させるときに常に意識しておくべきことだと思っています。

つまずきポイント

前半・中段で詳述した3点（--limit のNaN問題、Playwrightプロファイル衝突、絵文字豆腐）に加え、実装全体を振り返って見えてきた落とし穴をまとめます。「実装中に詰まった瞬間」だけでなく「あとから気づいた設計ミス」も含めています。

① going-forward 修正 → 動作確認 → retrofit の「順序」を守らないと二重修正になる

source = lane.key の1行修正（commit 7b78ca5）をしてからレトロフィットスクリプトを走らせないと、retrofit で正しい髪色に直した過去44本に対して、翌日の daily-codex-note.js が古いマッピング（build → 'note'）で新サムネを生成して上書きします。つまり「直したはずなのにまた戻っている」という状態になります。今回は going-forward 修正後に build レーンで新規記事を1本投稿して青髪が出ることを目視確認してからバッチを走らせましたが、これを明示的に「手順」として定義しておかなかったため、確認作業が属人的な記憶に依存していました。「バグ修正が新規データに正しく適用されていることを確認してから、過去データを修正する」という順序はルールとして文書化すべきでした。

② hairForSource() のフォールバックが赤髪だと「バグの生き残り」と区別できなくなる

フォールバック先を note（赤髪）にしたのは「未知のソースが来たとき黙って壊れるより、デフォルトに落ちる方がデバッグしやすい」という判断です。ただしそもそものバグが「build の記事が赤髪で出ていた」というものだったので、going-forward 修正後に build レーンの新規記事に赤髪のサムネが出てきたとき、それが「フォールバック発火＝未知の source が来た」なのか「修正がまだ反映されていない」なのかを目視だけで判断できませんでした。事後的に考えると、開発・テスト環境だけ process.env.STRICT_HAIR_SOURCE が設定されていたらフォールバック時に例外を投げる切り替えを入れておくと、修正が正しく機能しているかの検証が格段に楽になります。本番はデフォルトフォールバックを維持しながら、テスト時だけ strict モードで動かすという2段構えが理想です。

③ retrofit 完了後の「本当に直っているか」を自動検証する手段がなかった

swap-eyecatch.js は「Playwright が更新するボタンをクリックできた」という確認しかしていません。ボタンが押せたことと、アップロードした PNG が正しい髪色になっていることは別の主張です。実際にはアップロード先の URL を fetch してピクセル値を検査するか、少なくともサムネの URL が変わっていることを確認するアサーションが必要でした。今回は44本を手作業で目視確認しましたが、100本・300本のスケールになると目視は現実的ではありません。「スクリプトが exit 0 で終わった」と「期待する成果物が実在する」は別の命題として扱い、レトロフィット系のスクリプトには必ず事後検証ステップを組み込む必要があります。

④ Object.freeze() を忘れると別スクリプトからの誤上書きが無音で通る

export const HAIR_BY_SOURCE = Object.freeze({
  note:      { en: 'red-haired',          jp: '赤髪' },
  build:     { en: 'blue-haired',         jp: '青髪' },
  // ...
});

Object.freeze() なしでエクスポートした場合、インポートした別ファイルで HAIR_BY_SOURCE.build = { en: 'red-haired', jp: '赤髪' } のような代入が実行時に何のエラーも出さずに通ります。本番で実際に起きたわけではありませんが、5レーン以上のスクリプトが1つのテーブルを参照するコードベースでは、freeze が静的な防波堤として機能します。特に Codex に実装を委譲しているとき、Codex が「使いやすさのために」テーブルのエントリを追加したり書き換えたりするコードを生成する可能性があるので、freeze で物理的に防ぐ意味があります。

⑤ ページネーション API で is_last_page だけを終了条件にすると危ない

fetchPublishedNotes() のループはレスポンスの json.data.is_last_page が true になるまでページをインクリメントします。note API がネットワーク障害や一時的な5xx でエラーレスポンスを返した場合、json.data が存在しない状態で is_last_page を参照すると undefined になります。undefined は true と等しくないのでループは止まりません。今回は note の API が安定していたので実害はありませんでしたが、if (!json?.data?.contents?.length) break という安全弁を追加することで、空のページが返ってきた場合も正常に終了できます。

⑥ sanitize_text() が retrofit パスにも必要かを最初から設計に入れていなかった

絵文字豆腐の対策として sanitize_text() を overlay_note_text.py の描画入口に置いたことで、going-forward でも retrofit 経由の呼び出しでも自動で絵文字が除去されます。ただし「この関数は描画パイプラインの入口に置いてあるので呼び出し元で sanitize しなくていい」というドキュメントが存在しなかったため、retrofit スクリプトを書くときに「こちら側でも sanitize が必要か」を調べる時間が発生しました。「どこに何の責任を持たせているか」の設計意図を一行でいいのでコード内に書き残す、または README に記録しておく習慣が必要でした。

⑦ state JSON に --reset フラグがないと「全部やり直し」ができない

state/retrofit-hair-note2.json は処理済み記事の key を記録し、再実行時にスキップする冪等設計です。これ自体は正しいのですが、--limit NaN バグで全件処理されてしまったあと「最初の5本だけ改めて処理したい」という要求が生まれたとき、state JSON を手動で削除する以外の方法がありませんでした。state JSON を削除するということは「どこまで終わったか」の記録も消えることになります。--reset フラグで state JSON だけクリアしてからフローに入る選択肢と、--only-keys key1,key2 で特定記事だけ再処理するオプションがあれば、後からの調整が大幅に楽になりました。

⑧ 5レーンのプロファイルパスをハードコードすると追加レーン時に全スクリプトを直すことになる

comment-lanes.json でレーンとプロファイルの対応を集約する前、各スクリプトが個別にプロファイルパスを持っていた時期がありました。funnel レーンを新規追加したときにプロファイルの書き換えが必要なスクリプトが6本以上あり、書き換え漏れがプロファイル衝突の原因の一つになりました。設定の1点集中管理は「変更漏れ」を防ぐ構造的な解で、これを後付けで導入するより最初からやった方がコストが低い。

⑨ レトロフィット中に daily ジョブが起動するタイミングは予測できない

retrofit-hair-codexlane.mjs の実行中に daily-codex-note.js が朝のスロット（build 7:15、affiliate 8:15、funnel 10:40）に起動するとプロファイルが衝突して即クラッシュします。waitForProfileFree() を入れて ps aux でプロファイルのパスを60秒ごとにチェックする設計にしましたが、これはあくまでレース状態を「検知して待つ」アプローチです。より確実なのは、daily ジョブの実行スロット外の時間帯にのみ retrofit を走らせるよう launchd のスケジュールに制約を入れるか、グローバルなロックファイルを使って「誰かが Playwright を使っている」状態を管理することです。

⑩ 修正が going-forward に効いているかを確認する前に「完了」と判断しそうになった

source = lane.key の修正はdiffが1行です。コードレビューだけ見ると「これで動くはず」という感覚が強くなります。ただし「動くはず」と「実際に動いた」は別命題で、今回は修正後に新規記事を1本実投稿して青髪のサムネが出ることを確認してからretrofitに移りました。自動化パイプラインの修正は、「コードが変わった」という確認より「正しい出力が実際に生成された」という確認で完了と判断するべきです。ステージング環境がない場合は「本番で1本だけ投稿して確認」という手順をチェックリストに入れておく。

⑪ going-forward バグに気づいたのが44本たまってからだった

サムネの髪色バグに気づいたのは、記事が44本公開されたあとでした。1日10本ペースで自動投稿していたので、約4〜5日間のブランクです。サムネを毎日目視チェックする運用フローがなかったため、「なんか色がバラバラだな」という印象が記憶に積み上がるまで検知できませんでした。自動化パイプラインには「出力品質のサンプリング確認」を日次または週次で実施する運用ルールが必要です。今回であれば「各レーンの最新記事のサムネが正しい髪色かを毎朝確認する1分のチェック」で44本が4〜5本に抑えられていました。

---

ベストプラクティス

今回の実装から抽出した、複数アカウント自動化パイプラインで繰り返し使える設計原則です。「なぜそうするか」まで書かないと次に迷ったときに使えないので、原則と理由をセットで記録します。

① ソース識別子は途中で変換しない

lane.key を source に変換する間接テーブルを1箇所でも書いたら、そのテーブルが「真実の単一源泉」を持つことになります。今回のバグは build → 'note'、affiliate → 'note2' という変換テーブルが HAIR_BY_SOURCE の追加後も生き残っていたことで起きました。source = lane.key のように「識別子はそのまま渡す」を原則にすれば、変換テーブルが腐ることはありません。マッピングが必要なら hairForSource() のような専用関数に閉じ込め、呼び出し側は「識別子をそのまま渡す」だけにする。

② 定数テーブルは Object.freeze() で保護する

複数ファイルから import される定数オブジェクトは Object.freeze() をかける。インポート側からの誤代入を TypeError で即座に検知できます。特に Codex に実装を委譲しているとき、Codex が「利便性のために」テーブルを拡張するコードを書く可能性があるため、物理的に変更できない状態にしておくことで「意図しない拡張」を防げます。

③ フォールバックの「動く間違い」を開発環境でだけ厳格にする

フォールバックが本番と同じ状態（今回は「赤髪で出る」）で動作する場合、going-forward バグの生き残りとフォールバック発火を区別できなくなります。process.env.STRICT_HAIR_SOURCE = '1' のような環境変数で「未知のソースが来たら即例外」モードに切り替えられる設計にしておく。テスト実行時は strict モードで走らせると、修正が正しく機能しているかを確認しやすくなります。

④ going-forward 修正 → 新規データで動作確認 → 過去データ修正の順番を守る

バグ修正と過去データの修正は「バグ修正が新規データに正しく反映されているとことを確認してから、過去データを直す」の順番を守る。逆の順序で作業すると、retrofit 完了後も古いコードが動き続けて誤ったデータが再生産され、修正済みのはずの記事が翌日には元に戻ります。「1本だけ本番で動作確認してから大量処理に移る」という中間ステップをルール化する。

⑤ バッチ処理は「冪等 + state JSON + --reset フラグ」を最初から設計に入れる

state/retrofit-hair-*.json のような進捗ファイルを最初から設計に含め、再実行すると未処理分だけが実行される冪等設計にする。合わせて --reset フラグで state JSON をゼロクリアしてから再実行できるオプション、--only-keys key1,key2 で特定のアイテムだけ処理できるオプションを用意しておく。後付けで冪等設計を追加するほど、state JSON のフォーマットと既存ロジックの整合を取る修正コストが上がります。

⑥ CLI 引数パーサーは parse 直後に NaN チェックを入れる

opts.limit = parseInt(argv[i + 1]);
if (isNaN(opts.limit)) throw new Error(`--limit の次に数値が必要です: ${argv[i + 1]}`);

parseInt(undefined) は NaN を返し、count >= NaN は常に false です。どの数値より大きくても判定が成立しないので、上限がなくなります。引数 parse は「ユーザー入力のバリデーション」と同等のレベルで扱い、型チェックと即エラーを parse 直後に入れる。

⑦ Playwright プロファイルの競合は事前検知してポーリングで回避する

Chromium は同じプロファイルディレクトリを複数プロセスが同時に開けません。バッチ実行の前に ps aux で当該プロファイルのパス文字列を検索し、見つかったら60秒ポーリングで空きを待つ設計にする。最大待機時間（今回は30分）を設定してタイムアウトで例外を投げることで、永久待機を防ぐ。このパターンは「同じリソースを複数スクリプトが奪い合う」状況全般に転用できます。

⑧ 絵文字・非対応文字の除去は「描画パイプラインの入口」に置く

sanitize_text() を呼び出し側に置くと、going-forward・retrofit・手動実行のすべての経路で同じ関数を呼ぶ必要が生じます。描画ロジックの内部入口（今回は overlay_note_text.py の render() 冒頭）に置けば、どの経路から呼ばれても自動的に適用されます。「防御処理は入口に近い方から置く」という原則の具体例です。

⑨ 設定の1点集中管理でスクリプト間の「書き換え漏れ」を防ぐ

レーン・プロファイル・アカウント URL の対応表は config/comment-lanes.json のような1つのファイルに集約する。各スクリプトはこのファイルを読んで自分のプロファイルパスを動的に引く設計にする。新しいレーンを追加するとき、ファイル1つを更新するだけで全スクリプトに設定が伝わります。ハードコードは「変更先」と「変更漏れ箇所」を同時に生みます。

⑩ 「スクリプトが正常終了した」と「期待する成果物が正しい」は別のアサーション

swap-eyecatch.js の exit 0 と「アップロードしたサムネが正しい髪色になっている」は別命題です。大量処理スクリプトには「処理件数と実際の成果物を突き合わせる事後検証ステップ」を必ず含める。今回は目視確認でしたが、スケールする前に「差し替え後の画像 URL を fetch してピクセル属性を検査するステップ」を組み込んでおくことで、将来の100本・300本の処理でも品質が担保できます。

⑪ ブランド設計はコードより先に確定させる

「各アカウントのアイコンの髪色は何色か」というブランド定義が先にあって、HAIR_BY_SOURCE テーブルはその実装です。定義が後から変わると、今回のような大量レトロフィットが必要になります。5アカウントを並走させる前に「各アカウントのカラーアイデンティティ」を決め、コードに反映させる順番が正しい。記事を量産してからブランドを変えることの返済コストを最初から意識しておく。

⑫ going-forward と過去データの両方に修正を適用する責任を最初から想定する

今回のような「識別子の誤マッピング」バグが自動投稿パイプラインに潜んでいた場合、修正には going-forward の1行と、過去データのレトロフィットの2つが必要です。「コードを1行直したら終わり」ではなく「過去に積み上がったデータも直す必要がある」という視点を最初から持っておくと、修正計画が立てやすくなります。特に毎日数十本を自動生成するパイプラインでは、バグが潜んでいた期間のデータ件数を即座に見積もれる状態にしておく。

⑬ 有料カバーと無料サムネで定義を共有する

hairForSource() は gen-codex-thumbnail.mjs（無料サムネ）と gen-paid-cover.mjs（有料カバー）の両方から import されています。色の定義を1箇所に集めることで、5色のうち1色を変えるときは HAIR_BY_SOURCE テーブルの1行を直すだけで両系統に反映されます。定義の重複は「片方だけ直して整合が取れなくなる」事故の温床です。生成系スクリプトを複数並走させるときは、共通する設定値の管理場所を最初に決めておく。

---

まとめ

今回やったことをひとことで言えば、「1行のバグを修正するために300行超のスクリプトを書いた」です。

daily-codex-note.js の誤マッピング（build → 'note'、affiliate → 'note2'）は、実装当時の判断ミスです。HAIR_BY_SOURCE テーブルが存在しなかった時代に書いた変換ロジックが、テーブルを追加したあとも生き残っていた。「仕様が変わったのにコードが変わらなかった」という、自動化パイプラインで特によく起きるパターンです。

問題の根深さは、自動化パイプラインが「間違った仕様でも毎日動き続ける」ことにあります。手で記事を書いていれば「このサムネ、色がおかしい」と気づく機会があります。でも1日10本のサムネが自動で生成されていると、出てきたものを一本一本確認するコストが高すぎて見落としが続く。気づいたときには4〜5日分、44本の負債が積み上がっています。

修正そのものは hairForSource() の20行と source = lane.key の1行でした。しかし実際に問題を解決するまでに必要だったのは、公開記事一覧の取得ロジック、冪等な state JSON、Playwright のプロファイル衝突検知、絵文字除去、引数パーサーの NaN チェック——という「バグを返済するための周辺コード」です。レトロフィットスクリプト2本の合計行数は300行超になりました。

このコストの非対称性が今回の一番の教訓です。自動化のスループットが高いほど、設計ミスの返済コストも高くなる。月商120万という数字の裏側には、こういう「間違えてから直す」往復が何十回もあります。「動いているから大丈夫」という判断を何週間も続けた結果、あるときまとまった負債が顕在化する。

これは自動化に限った話ではありませんが、自動化は特にその効果が増幅されます。Object.freeze() で定数を保護する、NaN をチェックする、state JSON で冪等性を担保する、プロファイル衝突を事前検知する——一つ一つは地味な作業です。でもこれが積み上がって「サムネが毎日正しい髪色で5アカウント分出てくる」という状態が維持されます。

月商120万を継続させるのは「最初に動いた仕組み」ではなく、「壊れたときに素早く直せる仕組み」です。コミット 7b78ca5 の1行修正はすぐに書けましたが、44本のレトロフィットを安全に実行できる冪等な基盤がなければ、修正中に別のバグを踏んでさらに大きな負債になっていました。自動化の品質は「どれだけ速く動くか」ではなく「壊れたときにどれだけ制御された方法で直せるか」で決まると今回改めて実感しました。

---

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

---

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

• 制作物・記事は bokuwalily.com にまとめています🖥️
• AIで「寝てても回る仕組み」を作って月120万にした話は noteの有料記事 に💰
• OSS: github.com/bokuwalily 🐙
• 最新情報・お問い合わせは X @bokuwalily へ🌍

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