最終更新: 2026-04-28
はじめに
正直に言う。最初の3ヶ月は何も稼げなかった。
ブログを書いて、SNSを更新して、KDPで本を出して——全部手動でやっていた。ある日、作業ログを見返したら朝7時から夜中の1時まで動いていた日があった。コンテンツ生成だけで4時間以上使っていた。本業もある。睡眠も削れない。「継続が大事」とよく言うが、私が一番続かなかった。
転機は「このままだと詰む」と気づいた瞬間だ。どこかを自動化しないと、3ヶ月目にやめることが確定していた。
そこから半年。Python + launchd + Claude Code を組み合わせて、今は1日30分も触らずにコンテンツが動いている。月収が5万円に届いたのは、頑張ったからじゃなくて、仕組みを積み上げたからだと思っている。
この記事では、私が実際に組んだ6つの自動化パイプラインを書く。コードも出すし、失敗の話もする。
1. SNS投稿を1日3回自動化した話
BlueSky・X・note に毎日投稿するのは、想像以上にきつかった。ネタを考えて、文章を書いて、タイミングを計って——これを毎日3回やると、本業がある日は夜中の2時まで作業することになる。2ヶ月目に一度、1週間まるごと投稿が止まった。そのとき「手動は無理だ」と確信した。
解決策は launchd で 7:00 / 12:30 / 20:30 の3回、投稿スクリプトを自動起動すること。plist に StartCalendarInterval を書いて、sns_post_launcher.sh が各プラットフォームのスクリプトを叩く構成だ。
<!-- /Library/LaunchAgents/com.taito.sns-post.plist の骨子 -->
<key>StartCalendarInterval</key>
<array>
<dict>
<key>Hour</key><integer>7</integer>
<key>Minute</key><integer>0</integer>
</dict>
<dict>
<key>Hour</key><integer>12</integer>
<key>Minute</key><integer>30</integer>
</dict>
<dict>
<key>Hour</key><integer>20</integer>
<key>Minute</key><integer>30</integer>
</dict>
</array>
投稿文の生成は Claude Haiku に任せている。当初 Sonnet 4.6 を使っていたが、1ヶ月で API コストが跳ね上がった。Haiku に切り替えたら 1/8 以下に落ち着いた。コスト以上に、Haiku のほうが変な修飾をつけないので、文体が自然になりやすかった。
詰まったのは「同じ文体の投稿が3日連続する」問題だった。Haiku に渡すプロンプトが固定だったので、出力パターンが収束していた。Ollama の qwen2.5:3b に切り替えてみたら、むしろ個性が出すぎてバラツキが増えた。今は Claude Haiku(品質重視の朝枠)と Ollama qwen2.5:3b(量産の昼・夜枠)のハイブリッドで動かしている。
2. ブログ記事を品質スコアで管理するようにした
記事を自動生成しても、クオリティがバラバラだと意味がない。
品質ゲートを作ろうと思ったきっかけは具体的だ。公開済み記事を見直していたとき、h2 が2つしかない 700 字の記事が出てきた。結論が「まとめると以上のことが言えます」で終わっていた。自分で生成して自分で公開していたのに、一切確認が入っていなかった。「これ誰が読むんだ」と思った瞬間に、品質ゲートの必要性を確信した。
生成→チェック→採点のパイプラインを作った。採点は S/A/B/C/D/F の6段階で、スコア高い順にストックして上から公開していく仕組みだ。
# content_scorer.py の採点ロジック骨子
grades = {"S": 90, "A": 80, "B": 70, "C": 60, "D": 50, "F": 0}
filename = f"s{score:03d}_{grade}_{today}_{slug}.json"
F 判定の記事は trash/ に退避して公開キューには入らない。D 以下は手動レビューが必要というルールにしている。
AdSense 申請前にブログを棚卸ししたとき、公開済み14本の平均が 2,430 字で全記事が AI・自動化テーマに揃っていた。品質スコア管理を入れた後に生成した記事は平均 3,100 字以上——数字で見ると、仕組みが機能している実感がある。
3. KDP出版を毎日1本自動化した
Kindle 本の出版を毎日1本自動化している。
「毎日1本って嘘でしょ」と思われるかもしれないが、本文生成→表紙生成→epub 変換→出版キュー追加がスクリプト1本で動く。
python3 01_Scripts/kdp/kdp_ai_book_generator.py
表紙は Gemini Web 経由で生成している。他の生成サービスと比べて日本語テキスト入り画像の品質が高く、文字化けが格段に少ない。プロンプトを英語で書きながら overlay_text: "Claude Code 自動化入門" の形式で日本語テキストを明示するようにしてから、品質が安定した。
本文は Claude Sonnet 4.6 に書かせている。KDP は「量×質」の掛け算なので、ここだけはコストをケチらない判断をした。
失敗は章立てで起きた。最初の頃、プロンプトに構成を指定せずに投げたら「第1章:はじめに」「第2章:概要」「第3章:まとめ」という3章しかない 10 ページの本が出てきた。KDP 的に本と呼んでいいか怪しいレベルだ。章立てテンプレートをプロンプトに埋め込んでからは、最低8章・30ページ以上の構成が安定して出るようになった。
4. DiscordをCTOの報告画面にした
launchd で動いているスクリプトが40個を超えてから、ステータス確認が大変になった。
どのスクリプトが動いて、どれが止まっているか——ログファイルを1個ずつ開いていたら、確認だけで30分かかっていた。スクリプトが増えるほど管理コストも増える。これはスケールしない。
解決策は Discord Bot 経由の集中管理だ。!status で全パイプラインの稼働状況が返ってくる。
X: 投稿1本完了(v_visual_ollama_vs_claude_api)、次は114分待機
BlueSky: エンゲージ6件完了
note: クールダウン中(前回投稿から3時間未満)→次投稿は自動待機
KDP: キュー残3本 / 本日出版済み1本
スマホで確認できる。外出中でも状況を把握できる。ボットに自然言語で話しかけると Claude Haiku がコマンドを解釈して実行してくれる設計にもした。「今日の投稿状況は?」と聞けばサマリーが返ってくる。
地味に効いているのが AivisSpeech での音声読み上げ機能だ。ボイスチャンネルに入って「KDP 出版が完了しました」の声が流れると、ちゃんと動いている実感がある。テキスト通知は見逃す。声だと気づく——これだけで自動化への安心感がぜんぜん違う。
5. ブログのAdSense対策をスクリプトで一括処理した
AdSense の申請を通すために、ブログの整備が必要だった。
WordPress の管理画面を開いたら、重複ページが5本あった。privacy-policy、privacy-policy-2、privacy-policy-3——プラグインを変えるたびにページが増殖していた。テストドラフトも12本残っていた。これを手作業で直すと半日消える。全部スクリプトに任せた。
重複ページの非公開化とテストドラフトのゴミ箱送りは WordPress REST API で処理した。メタディスクリプションの自動挿入と内部リンク注入は inject_internal_links.py で全記事を走査している。
# inject_internal_links.py の骨子
for post in published_posts:
content = inject_links(post["content"], related_posts)
update_post(post["id"], content)
内部リンクの注入は、関連キーワードが含まれる段落を検出して、対応する記事の URL を自動で埋め込む処理だ。手動でやると絶対にサボる作業なので、スクリプトに任せてよかった。
結果は AdSense 準備度 78/100。Search Console 登録→申請まであと少しのところまで来た。この数字が出たとき、地道に整備してきたことがスコアとして可視化された感じがして、少し安心した。
6. ココナラ納品の承認ゲートを実装した
ここは少し特殊な話だ。
ココナラで自動返信・自動納品パイプラインを組んでいるが、「AI が直接クライアントに送信する」のはリスクが高い。文脈ズレや誤送信が1回でも起きたら信頼を失う——副業初期に信頼を失うのは、収益以上に痛い。
解決策は Discord DM 経由の承認ゲートだ。自動生成された返信文が Discord DM に「送る/却下」ボタン付きで届いて、私が「送る」を押した時点で初めてクライアントに送信される。
実装は3ファイル構成だ。approval_queue.py がキューを管理して、request_approval.py が Discord に送って、post_approved.py が承認済み件を実送信する。
# post_approved.py の送信ロジック骨子(state更新→lock解放→outbox更新の順)
def process_approved_item(item_id):
update_state(item_id, "sending")
release_lock(item_id)
add_to_outbox(item_id)
send_to_client(item_id)
デッドロック回避のために state の更新→lock の解放→outbox の更新という順序を徹底した。最初にこの順序を間違えたとき、承認済みのメッセージが2重送信されるバグが出た。クライアントに同じ文章が2回届いて「通知のテストですか?」と返信が来た。冷や汗をかいた。
自動化しながらも人間が最終確認するという設計は、副業初期には特に必要だと思っている。スピードより信頼。ここだけは妥協しなかった。
まとめ
6つの仕組みを一言で言えば「生成→品質管理→配信→監視→人間確認」の流れだ。launchd でコンテンツ生成を動かして、Discord で状態を把握して、承認ゲートで品質と送信を制御する——この構造が今の基盤になっている。
全部を一気に作ったわけじゃない。詰まるたびに修正して、壊れるたびに直して、半年かけて今の形になった。最初の自動化は launchd で SNS スクリプトを動かすだけだった。それだけでも当時は十分すぎる変化だった。
月5万円というのは、正直まだ安定していない月もある。ただ、仕組みが動いている限り「ゼロになることはない」という感覚は出てきた。稼いだ金額より、止まらないシステムを持てたことの方が収穫かもしれない。
次は Search Console 登録からの AdSense 申請を自動化できないか考えている。たぶんどこかで詰まって、その話を記事にする。✨
関連記事
- macOS の launchd で Python スクリプトを定時実行する完全設定手順【詰まりポイントまとめ】
- launchd × BlueSky自動エンゲージ、429エラーと日次上限に詰まった記録
- Claude Code 使い方 完全ガイド 2026年版——インストールから実戦運用まで