50秒。

新しく作ったSubstack publication で、ぼくが Markdown 1本を「完全公開」状態まで持っていくのに測った実時間です。

ログイン済みの session を読み込んで、エディタを開き、TipTap に貼り付け、audience を「全員」に切り替え、「今すぐ全員に送信」を押し、「ボタンなしで公開」モーダルを通過し、share-center まで到達する。ストップウォッチで測って 50秒でした。

draft 保存だけなら 10秒。Gmail IMAP 経由の auto-login（passwordless）は 30秒。

これは机上の見積もりではありません。テスト用に作った検証専用 publication で、本番運用と同じ実装を回して測った実測値です。

※ 本書が想定する「月30分運用」は、安定運用フェーズ・月数本投稿時の数字です。初期構築には2〜3週末（実装・検証・session 取得・GHA 設定）が必要で、Substack の UI 改修月には selector 修復で1〜2時間溶ける可能性があります。期待値ギャップを最初に書いておきます。

そして、この50秒の裏には、教科書では一切触れられていない実装の核心が4つ埋まっています。

- TipTap の clipboard paste hack（Markdown → HTML → ClipboardItem 経由でないと構造が崩れる）

- paywall block を挿す UI 操作（「もっと見る」サブメニューを叩く）

- audience 切替の罠（paywall 有無で default が違う）

- 多段 publish dialog のモーダル順次対応（候補を配列で持って try する）

教科書を一通り読んで、いざ自分で「自動投稿パイプライン」を組もうとしたとき、ここで全員が止まります。

ぼくも止まりました。

価格について

| タイミング | 価格 |

|---|---|

| 公開初日（24時間限定） | ¥980 |

| 通常価格 | ¥3,980 |

公開から24時間限定で ¥980 で販売します。ランキング枠を取りたいので初日だけ赤字覚悟の特価です。

24時間経過後は通常価格 ¥3,980 に戻ります。さらに売れ行き次第で予告なく値上げする可能性があります（¥4,980 や ¥5,980 への引き上げを検討中）。

「あとで買おう」と思って数日空けると、初日特価分の¥3,000 が消えます。教科書を一通り読み切って「実装の解像度を一段上げたい」のであれば、初日の判断が一番得です。

スクリーンショットで価格を控えておいて、後で同じ値段か確認してみてください。

こんな状態で詰まっていませんか

ターミナルが触れて、git も叩けて、Substack の教科書も一通り読み終わったあなたに聞きます。

- 毎週金曜のニュースレター執筆で、気づくと2時間が溶けている

- TipTap エディタの編集が手作業で、Markdown コピペがうまく構造化されない

- paywall の設定を毎回間違える（audience が「有料購読者のみ」に固定される）

- 投稿予約したのに送信失敗していた、ということが過去に1回はある

- 記事の品質ブレを止められない（書く日のテンションで全然違う）

- Substack の教科書を読んだが「やり方の説明」止まりで、自分の publication にはどう実装するのか分からない

- post-by-email が新規 publication で撤去されているのを知って、自動投稿の道筋を見失った

- Claude Code を入れてはみたけど、「何を SKILL に切り出して、何を runtime で書くか」の判断がつかない

このうち3つ以上当てはまるなら、この記事はあなた向けです。

逆に、1つも当てはまらない場合は買わないでください。教科書をもう1周した方が早いはずです。

時間予算（実態ベース）

「月30分運用」は安定運用フェーズの数字です。フェーズごとの時間予算は以下のとおり：

| フェーズ | 内容 | 時間目安 |

|---|---|---|

| 初期構築（1回限り） | npm install / .env 設定 / Substack login session 取得 / Anthropic API key 取得 / Supabase 立ち上げ | 2〜3週末（合計10〜20時間） |

| GHA 運用化（1回限り） | session base64化 / Secrets 設定 / workflow.yml の調整 / 1回手動実行で動作確認 | 半日〜1日（4〜8時間） |

| 週次運用（毎週） | Markdown 記事を書く + GHA手動トリガー or cron任せ + 結果確認 | 5〜10分 |

| 月次運用（毎月） | session 期限切れ対応 + selector breakage 修復 + コスト確認 | 20〜40分 |

| UI改修月（不定期） | Substack の UI 変更時の selector 修正 | 1〜2時間 |

「月30分」は週次運用 + 月次運用の合計値です。初期構築は別予算で確保してください。

なぜ今、Substack 自動化なのか

Substack の教科書市場は、いま二次需要のフェーズに入っています。

「Substack の始め方」「ニュースレターの書き方」「最初の100人を集める方法」までは、書籍・Brain・note・YouTube で出尽くしました。検索すれば10本は出てきます。読んでおくべき土台です。

でもその先、つまり「教科書通りに始めた人が、実際に運営を続けるフェーズで何に詰まるか」を扱った教材が、極端に薄い。

ぼくが詰まったのも、まさにそこでした。

書く時間が無限に伸びる。週次の投稿サイクルを止められない。エディタ操作が毎回ちまちま手作業になる。paywall の設定ミスで全員に有料記事を送ってしまう、みたいな事故が起きる。

「手で運営すれば回せる」のは、最初の3ヶ月です。4ヶ月目から、運営は時間との戦いになります。

そしてここに、もう1つ大きな仕様変更が重なりました。

Substack は新規 publication で post-by-email を撤去しました。

post-by-email は「指定メールアドレスにメールを送ると、そのまま記事として下書きが立つ」という機能でした。これを使えば SMTP 経由で自動投稿できた。多くの自動化ツールがこの機能を前提に組まれていました。

それが、新規 publication では使えません。既存 publication でも、いつ閉じられるか分かりません。

つまり、Substack の自動投稿は今、browser automation 一択になりつつあります。Playwright で実 UI を叩いて、TipTap に貼り付けて、publish dialog を通過させる。これしか方法がない。

そして公式 API は、執筆時点で存在しません。reader API（読み取り）はあるけど、publish API は提供されていない。

「APIが無い、post-by-email も塞がれた、でも運営は続く」

この前提条件のもとで、Claude Code に大半を肩代わりさせて、人間の月次拘束時間を30分に近づける設計が、この記事のテーマです。

ターミナルで npm run weekly:publish を叩く。あるいは GitHub Actions の cron に毎週金曜10時を仕込んでおく。それだけで、記事が生成され、品質が評価され、Substack に投稿される。人間がやるのは「公開して良いか最終確認」だけ。

これは机上の構想ではなく、ぼく自身が回している運用です。実装が安定するまでには複数の週末を溶かしたし、規約のグレーゾーンも一個ずつ確認しました。その過程の全部を、この記事に詰めます。

ぼくが Substack 自動化に振り切った理由

ノウハウコレクター時代、ぼくは1年以上 Brain も note も Substack も「やった気」になっていました。

教材を読み込んだ気になって、Notion に整理しました。プロンプト集、AIライティング、副業ロードマップ、SNS運用論。どれも頭には入った気がしたけど、自分の手で publication 1つ動かし切ることはできませんでした。

特に Substack。発信を始めて、ぼくは毎週金曜の夜を執筆に溶かしていました。20時に書き始めて、構成を練って、TipTap に貼って、audience を確認して、paywall を仕込んで、送信ボタンを押すまでに気づくと2時間消えている。

「これ、続かないやつだ」

そこで気づきました。書きたいテーマは増えるのに、投稿サイクルが体力勝負で破綻する。週末を1日まるごと publication に持っていかれる。本業が止まる。

> ※ ここに、金曜夜の Substack 関連タスクで時間が溶けていた当時の作業記録スクショを差し込む予定です（著者後付け差し込み箇所）。

転機は、Claude Code を本気で触り始めた時でした。

最初は「ChatGPT の延長」くらいに思っていたんです。でも違った。Claude Code は「ターミナルで動くコーディング相棒」で、Anthropic の SDK を経由して、自分のプロジェクトディレクトリの中で勝手にコードを読み書きする。

「これ、Substack browser automation を書かせられるんじゃないか」

そう思って、Playwright のドキュメントと Substack のエディタ画面を Claude Code に見せながら、半分くらい肩代わりさせて実装し始めました。

最初の壁は TipTap でした。Markdown をそのまま貼り付けると、見出しも箇条書きも全部「ただのテキスト」になる。改行コードが消える。リサーチで分かった一般的に詰まりやすいポイントで、ぼくも例外なくここで止まりました。実装過程で確認したのはmarked で HTML に変換 → ClipboardItem に text/html で渡す → TipTap がリッチに解釈してくれる」という hack。これに行き着くまで、何度も貼り直しました。

> ※ TipTap 貼り付け後の実機スクショ。ぼくが新規作成したテスト用 publication で、Markdown を marked → ClipboardItem 経由で貼った直後の画面：

>

> ![tiptap-after](https://image.brain-market.com/store/eaeaa2603cad0923d32050e53a0950d9.png)

>

> ※ Markdown 直貼りとの比較は paid_body 章4を参照。

次の壁は、publish dialog の多段モーダル。

「続けるボタン → audience 選択 → 送信ボタン → 確認モーダル → share-center 到達」という流れを Playwright で踏むんですが、Substack はモーダルの文言を頻繁に変えます。「ボタンなしで公開」「公開してメール送信」「すぐに公開」みたいな候補が、A/Bテストやらアップデートやらで入れ替わる。

これを乗り切るには、モーダル候補を配列で持って、上から順次 try するしかない。1つだけハードコードすると、ある日突然落ちます。

実装過程で確認した結果、最終的にぼくが組んだ仕組みはこうなりました。

- Markdown 1本を投げると、Anthropic SDK 経由で記事生成 → 8軸評価器で採点 → Substack に投稿

- session は Gmail IMAP 経由で約30日サイクルで自動再認証（passwordless ログインを browser automation で踏む）

- GitHub Actions の cron で週次自動実行（session を Secrets に base64 で持つ）

- 落ちた時は debug screenshots を artifact にアップロードして Slack に通知

月次の人間拘束時間は、設計目標として30分を置いています。実機検証では「自動投稿1本50秒・auto-login 30秒・draft 保存10秒」までは確定しました。週次運用全体としての月次拘束時間は、この記事で設計の根拠と実数値を全部開示します。

> ※ ここに、GitHub Actions の週次 workflow 実行履歴（連続成功ログ・実行時間）のスクショを差し込む予定です。

教材の章立てとロードマップ

全8章 + Day 0/1/2/3 の段階ロードマップで構成しています。

「最短で動かす → 品質ゲートを足す → 完全運用化する」の3段階で組み立てているので、まず Day 1 で「とりあえず1本自動投稿成功」体験を取ってから、Day 2 で品質、Day 3 で運用化に進めます。

Day 0（章1）: 全体図と最短ルート

- 完全自動化の5フェーズ（生成→評価→承認→投稿→分析）

- 最短ルート（章1+4+6 だけで30分動く状態）

- Claude Code セットアップ

Day 1（章2 + 章4）: とりあえず1本自動投稿成功

- 章2: 記事生成エンジン（SKILLs パターン・system prompt cache・Opus 4.7 と Haiku の使い分け・実コスト ¥20-70/記事）

- 章4: Substack 自動投稿の核心（TipTap clipboard paste hack・paywall block UI 操作・audience 切替・多段 publish dialog・session storage state 保存）（最重要章）

Day 2（章3）: 品質ゲートを追加

- 章3: AI評価ゲート（8軸採点・致命ヒット3カテゴリ・読者価値3問・voice drift z-score 検知・anchor/archive 分離・統合 Haiku 1回呼び出し）

Day 3（章5 + 章6）: 完全運用化

- 章5: Gmail IMAP 自動再認証（passwordless login の仕組み・imapflow + mailparser・6桁コード抽出・session 30日サイクル）

- 章6: GitHub Actions 完全運用化（週次cron + workflow_dispatch・session base64 + Secrets・session 有効性チェック→期限切れなら auto_login → upload_session・debug artifacts）

必読（章7）: 規約遵守と落とし穴20選

- ToS 実条文の抵触リスク評価（5箇所）と回避設計

- 技術10 + 運用10 の落とし穴を「症状/原因/解決」セットで解説

- ぼくが実機検証で踏んだ4件もここに統合（mg-d0 ドメイン変更／Confirm subject 除外／Stripe 未連携で paywall 項目消失／check_session の false negative）

任意（章8）: 拡張

- Threads 派生自動投稿（Substack→Threads）

- Tier 1-4 段階自動化（完全自動化は6ヶ月後を推奨）

- マルチニッチ展開設計

- Supabase で月次レポート可視化

各章の最後に、その章だけで動く状態に持っていくためのチェックリストを置いています。途中で詰まっても、章末チェックリストで現在地が分かる構造です。

この記事に含まれるもの（実態ベース）

「7大特典」みたいな煽り見出しは使いません。実際に記事の中に入っているものだけを書きます。

- 本編約20,000字 / 全8章 — Day 0/1/2/3 のロードマップ付き

- Substack browser automation 全コード（TypeScript） — substack_browser.ts 約350行を全文掲載＋解説

- 8軸評価器の全コード — Haiku 1回呼び出しで採点する実装

- voice drift 検知器（独自軸） — anchor fixtures からの z-score 計算ロジック

- Gmail IMAP auto-login スクリプト — imapflow + mailparser の実装、subject regex の落とし穴含む

- GitHub Actions workflow.yml — 週次cron + workflow_dispatch + session auto-refresh の完成形

- Supabase スキーマ — 投稿履歴テーブル（評価結果・コスト記録を JSONB で持たせる拡張可能なベース設計）

- 落とし穴20選チェックリスト — 各落とし穴に「症状／原因／解決」セット

- 実機検証スクショ8枚 + 図解画像7枚 — エディタ画面・publish dialog・モーダル順次・share-center 到達までを実機画像と構成図で解説

- 実機検証データ — 自動投稿50秒／draft 10秒／auto-login 30秒／IMAP メール検索 6秒（全てストップウォッチ実測）

特典コミュニティや個別サポートはありません。書いてある通りに動かして、自分の publication で実装を完成させてください。

対象者・非対象者

対象者（こんな人向け）

- ターミナル・git・Node.js を触れる（npm install / .env 編集 / npx tsx scripts/foo.ts が読める水準）

- Substack で publication を運営している、または運営する予定がある

- 教科書系を1冊読み終えて、次の「実装の解像度」を欲しがっている

- Claude Code を入れたけど、Substack 運用に組み込む手順が分からない

- 月次の人間拘束時間を30分台まで圧縮したい

- 規約のグレーゾーンを「グレー」と認めた上で、自分のリスク判断で踏み込みたい

非対象者（こんな人にはおすすめしない）

- ターミナルを触ったことがない、Node.js を入れたことがない（先に環境構築の入門記事を読んでください）

- Substack ではなく note メインで運営している（note の自動化は別アプローチが必要です）

- 「ボタン1つで全部終わるツール」を探している（この記事は実装書で、コードを読み書きする前提です）

- ToS のグレーゾーンに踏み込むこと自体が許せない人（章7で正直に書きますが、リスクはゼロにはなりません）

- Claude Code を入れていない／入れる予定もない（生成パートが回りません）

環境構築（Node.js / TypeScript / Playwright のインストール）は前提として扱います。Playwright Chromium のダウンロード（約250MB）は記事内で触れますが、各ツールの入門解説は割愛します。

価格比較

この記事は通常価格 ¥3,980（公開初日24時間限定で ¥980）。¥3,980 で買ったとして、何と等価か並べてみます。

- Buffer（投稿予約 SaaS）月額 ¥1,500-2,000 × 12ヶ月 = ¥18,000-24,000/年 — しかも Substack には対応していない

- Make.com（自動化 SaaS）月額 $9-29 × 12 = $108-348/年 — Substack 連携テンプレは無い、自分で組む

- 同等システムを開発委託 = ¥30万円以上（browser automation + GHA + Supabase 連携で見積もると、フリーランス相場で30-50万）

- 時間で換算ニュースレター執筆まわりで週2時間溶けていた → 月8時間 → 年96時間。時給¥3,000で換算しても¥288,000/年

¥3,980で実装書とコード一式が手に入って、年96時間が浮く計算（※時給¥3,000換算の理論試算。成果には個人差があり、運用状況・実装の踏み込み具合で前後します）。

ただし、Claude API のコストは別途発生します。記事生成1本あたり ¥20-70（Opus 4.7 + Haiku 評価器の合算実測）。月4本投稿で ¥80-280/月です。これは記事内で詳しく開示します。

追伸

教科書の次に進むのは、いつも怖いです。

実装書という呼び方をしているのは、ここから先は「読んだだけ」では何も起きないからです。ターミナルを開いてgit clone して.env を埋めてnpm install してnpx tsx scripts/auto_login.ts を叩く。その手を動かすところまで一緒にやる前提の記事です。

逆に言えば、その手間さえ取れる人なら、来月のニュースレター運営は今月とは別物になります。金曜の夜2時間が30分に戻ってきます。

公開初日24時間は ¥980。それ以降は通常価格 ¥3,980 に戻り、売れ行き次第で予告なく値上げします。今がいちばん下限です。

それでは、章1で会いましょう。

第1章: 全体図と「最短で動かす」ルート（Day 0）