結論から書きます

当社（株式会社TOE）は、noteを2つのアカウントで無人運用しています。「補助金の鬼」（ユーザー名 jazzy_boar4126）と「AIの鬼」（ユーザー名 jojinja）です。cronから起動する公開スクリプト auto_publish.mjs が、Playwright/Chromeでnoteのブラウザ画面を操作して記事を公開します。APIは使っていません。

この構成で一番怖い事故は、公開の失敗ではありません。補助金の記事がAIのアカウントに載る、という「誤爆」です。 それを防ぐために、記事を公開する直前に、いま実際にログインしているアカウントのユーザー名をページから取得し、期待する名前と照合する工程を入れています。違っていたら、あるいはログインが切れていたら、その場で処理を停止して「ログインが違う/切れている」と記録し、公開しません。

その代わり、cookieが切れた日は投稿が止まります。この仕組みは「必ず公開する」ものではなく「誤爆を防ぐ」ものです。そこも正直に書きます。

用語を3つだけ

  • 無人投稿 … 人が画面を見ていない状態で、cron（時刻を決めた自動実行）からスクリプトがブラウザを操作し、noteに記事を公開することです。
  • Chromeプロファイル … ブラウザのログイン状態（cookie）を保存する入れ物です。当社はアカウントごとに専用のプロファイル（.chrome-profile）を用意し、物理的に分離しています。
  • urlname … noteのユーザー名です。当社なら jazzy_boar4126（補助金の鬼）と jojinja（AIの鬼）。公開直前に、ページからこの値を取得して照合します。

2アカウントの分離

項目 補助金の鬼 AIの鬼
noteユーザー名（urlname） jazzy_boar4126 jojinja
ログイン情報 専用のChromeプロファイル 専用のChromeプロファイル（別物）
公開方法 cronから auto_publish.mjs が無人で公開 同じ仕組み

プロファイルを分けているので、通常なら混ざりません。しかし「通常なら」を信用しないのが、この仕組みの出発点です。

公開直前の照合ガード

公開ボタンを押す前に、スクリプトは次の分岐を通ります。

ページから取得したurlname 判定 動作
期待する名前と一致（例：補助金の鬼なら jazzy_boar4126） 正しいアカウント 公開に進む
期待する名前と不一致 ログインがずれている その場で停止（die）。「ログインが違う」と記録し、公開しない
取得できない（ログイン切れ） ログインが切れている その場で停止。「ログインが切れている」と記録し、公開しない

公開に成功すると、https://note.com/jazzy_boar4126/n/<記事ID> のように、正しいアカウントのURLがログに残ります。 どちらのアカウントに載ったかが、あとから確認できます。

なぜ「止める」ほうを選んだか

ブラウザ自動操作は、cookie切れやログインずれが起きうるものです。ここで選択肢は2つあります。間違ったまま突き進むか、照合して違えば止めるか。

当社は後者を選びました。止まれば、その日の記事が公開されないだけです。しかし突き進んで誤爆すれば、補助金の読者にAIの記事が届く——読者への信頼に関わる、取り返しのつきにくい事故になります。「動き続けること」より「間違ったことをしないこと」を優先する、安全側に倒す設計です。

正直に書く、この仕組みの弱点

  • これは「誤爆を防ぐ」仕組みであって、「必ず公開する」仕組みではありません。 cookieが切れれば公開は止まり、その日は投稿されません。
  • 止まった日をどう拾い直すかは、この照合ガード自体の仕事ではありません。ガードは「間違った公開をしない」ことだけを保証します。

それでも、誤爆よりはるかにまし——これが当社の判断です。

関連する記録

まとめ

  • noteを2アカウント（補助金の鬼=jazzy_boar4126／AIの鬼=jojinja）で無人運用している。一番怖い事故は誤爆（取り違え投稿）。
  • ログインはアカウント専用のChromeプロファイルで物理的に分離。
  • さらに公開直前に、実際のログインユーザー名（urlname）を取得して期待値と照合。不一致・ログイン切れならその場で停止して記録し、公開しない。
  • 成功時は正しいアカウントのURLがログに残るので、あとから確認できる。
  • 弱点も正直に：cookieが切れればその日は投稿されない。ただし、間違ったまま突き進むより、止まるほうがはるかにまし。安全側に倒す設計である。