note自動化2000アカ計画の崩壊。物量戦という幻想を捨てた日

「低品質でも、物量で攻めればどれかは当たる」そんな考えから、私はnoteの自動化に手を出した。1アカウントあたり月に数百円。それを2000アカウントに積み上げれば、理論上は月に数十万から百万円以上の不労所得が手に入る。数字の上では、極めて筋が通っていた。

だが結論から言う。この考えは幻想だった。私は約600アカウントを構築した段階で、全てを失った。警告も、通知も、段階的な制限もない。ある日突然、静かに、完全に、痕跡すら残さず消えたのだ。

これはその失敗の記録だ。精神論でも、武勇伝でもない。実際に手を動かし、金を払い、貴重な時間を溶かした人間の「技術的敗戦記録」である。

1. 無謀な挑戦の始まり：2000アカウント量産という発想

note自動化を考えた理由は単純だった。一つ一つの記事の品質が低くても、圧倒的な「数」で殴れば、確率論的に売れるのではないか。いわゆる「物量戦」だ。私は最初から、少数精鋭のアカウントを育てるつもりはなかった。最初の目標は明確に「2000アカウント」。当たるかどうかではない。当たるまで作り続ける前提だった。

1-1. アカウント量産の技術構成

量産のボトルネックは明確だった。「メールアドレス」「CAPTCHA」「IP」。ここを突破できれば、あとは機械作業だ。

メールアドレス対策: iCloudの3アカウントとGoogle Workspaceのキャッチオール機能を使用した。独自ドメイン1つで、理論上は無限にアドレスを生成できる。
CAPTCHA対策: 2captchaを導入。人間の介入なしで、画像認証やパズルを機械的に突破するパイプラインを組んだ。

1-2. IP対策とプロキシ戦略

IPは Dateimpulse の日本居住者IP（Residential Proxy）をローテーションで使用した。アクセスごとにIPを切り替え、足跡を分散させる。この時点では、正直こう思っていた。「ここまでやれば、プラットフォーム側は止められない。あとは時間の問題だ」と。

2. 静かすぎる異変：通知が“来なくなった”という宣告

BANに気づいたきっかけは、画面に並んだ真っ赤なエラーメッセージではない。そもそも、何の音沙汰もなくなったのだ。

2-1. 止まったエンゲージメント

私は記事の投稿だけでなく、アカウント同士のエンゲージメント（いいね、コメント、フォロー）も自動化していた。これらが正常に回っている限り、スマホの通知はうるさいほど届くはずだった。それが、ある日の昼下がり、パタリと止まった。

2-2. 「やっぱりか」という諦念

エラーも出ない。警告メールも来ない。VPSのログを見ても、リクエストは正常に飛んでいるように見える。だが、noteの画面を開いても、何も動いていない。数分、十数分、時間が経っても通知欄は無音のまま。その瞬間、すべてを理解した。「あ、全部やられたな」と。焦りはなかった。最初に来たのは、「やっぱりか」という乾いた諦めに近い感情だった。

3. 全BANという現実：部分的ではなく“全滅”の衝撃

個別に確認して分かった事実は、あまりにも冷徹だった。

生き残ったアカウントはゼロ: 構築した600超すべてが対象。
段階的な制限なし: 投稿禁止などの生ぬるい処置ではなく、存在そのものの抹消。
例外なしの完全全滅: 古いアカウントも、作ったばかりのアカウントも、平等に消えた。

これは「試行錯誤の余地がない」という意味でもある。一つ一つ原因を潰して改善する、という建設的なフェーズは、この瞬間に完全に断たれた。

4. 敗因分析：内部APIという最大のミス

今回の実装では、ブラウザを使っていなかった。noteの内部APIを直接叩く方式（Headlessリクエスト）を採用していた。これが最大の敗因だったと思っている。

4-1. 挙動が“人間ではない”事実

どれだけIPを偽装し、User-Agentをランダム化しても、APIを直接叩く挙動には「隙」が生まれる。

マウス操作の欠如: 画面上の座標移動が存在しない。
スクロールの不在: 記事を読み飛ばす速度が異常。
クリック間隔の画一性: ミリ秒単位での不自然な規則性。
パケット構造の固定: ブラウザが生成する複雑なヘッダー順序を完全再現できていなかった。

4-2. フィンガープリントの壁

プラットフォーム側から見れば、「人間の皮を被っていないアクセス」を特定するのは、もはや造作もないことだったのだ。彼らは私たちが思っている以上に、接続元の「人間性」をシビアに判定している。

5. 「じゃあブラウザ操作すればいい」という新たな地獄

次に考えたのは当然これだ。「なら、本物のブラウザを自動で動かせばいい」。だが、ここには実運用における現実的な壁が立ちはだかっていた。

5-1. 通信コストの爆発

内部APIなら一回のリクエストは数KBで済む。しかし、本物のブラウザをシミュレートすれば、画像やスクリプトが読み込まれ、通信量は数MB単位に跳ね上がる。これをローテーションプロキシ経由で行うとどうなるか。プロキシの従量課金が、得られるであろう収益を確実に上回る。つまり、**「やればやるほど赤字」**という、ビジネスとして破綻した構造に陥る。

5-2. SeleniumやCDPの限界

「Seleniumを使えば検知を回避できる」というのは幻想だ。

Selenium: 特有のJavaScript変数をチェックされれば終わり。
CDP（Chrome DevTools Protocol）: 操作用のポートを開けているだけで、検知フラグが立つ。もはや、ありきたりな自動化ツールでプラットフォームの防壁を抜ける時代は終わっている。

6. 理論上の完全回避策と、その不可能性

理屈の上では、次のような構成なら可能だろう。

Chromiumの独自ビルド: ソースコードを書き換え、自動化の痕跡を完全に消去する。
Unixドメインソケット使用: ネットワーク経由の制御を隠蔽する。
TLSフィンガープリント / Canvas / WebGLの完全偽装: 通信の「指紋」からグラフィックボードの特性まで、すべてをランダム化する。

だが、はっきり言う。これを個人の副業でやるのは、あまりにも割に合わない。 数カ月かけてこのシステムを構築しても、noteがAPIやUIを少し変更するだけで、すべてがゴミになる。個人のリソースを注ぎ込む先として、これほど効率の悪い投資はない。

7. GoLoginという選択肢と、採算の壁

GoLoginなどのアンチ検知ブラウザ（Anti-detect Browser）を使う案も検討した。確かにBANの確率は下がる。だが、結論はこうだ。「できるかどうか」ではなく**「やる意味があるか」**の問題に突き当たる。高額な月額固定費を払い、重いプロキシ代を払い、それでもなお「低品質なコンテンツ」を垂れ流し続けて、一体いつ初期投資を回収できるのか。その計算式が成り立つ未来は見えなかった。

8. 結論：ルール外の物量戦は消耗戦にしかならない

全BANされた時、私は驚かなかった。「いつか来る」と思っていたからだ。ただ、この身をもって体験したことで、一つの真実がはっきりした。 ルール外の自動化は、必ず破綻する。

少数アカウントをローカルで大事に回すことは、技術的には可能だろう。だがそれは、自分のPCを24時間占領され、エラーのたびに呼び出され、プラットフォームの顔色を伺い続ける「不自由な生き方」だ。

最後に一言

自動化の目的は、自由を得ることだったはずだ。だが、物量戦に走った私は、いつの間にか最も不自由な場所にいた。

BANに怯え、常にスマホを確認する。
止まった通知に絶望し、ログを漁る。
対策されるたびに、新しい回避策に頭を抱える。

だから、私はこの物量戦という幻想を捨てた。次にやるのは、プラットフォームのルールを理解し、彼らと「共存」しながら、自分の時間を増やしていくための賢い自動化だ。

それ以外は、ただの消耗戦でしかない。この記録が、同じような幻想を抱いている誰かの目を覚ますきっかけになれば幸いだ。