
最終更新: 2026-04-28
ChatGPT で作業が減らない理由と Python 自動化への移行術
ChatGPT を使い始めて最初に感じたのが「あれ、手作業増えてない?」だった。
文章を投げる。生成される。コピーする。WordPress に貼る。タグを手動でつける。サムネを別ツールで作る——気づいたら「生成AIを使う手作業」が一工程増えていた。3ヶ月その状態で回して、1日に消えた手作業時間を計算したら1〜2時間。自動化する前とほぼ変わらない数字が出てきた。この記事では、その構造的な理由と、私が実際に Ollama(qwen3.5:9b)+ Claude Code + launchd で組んだパイプライン構成を書く。note.com の自動投稿が安定するまでに3回壊れた話もついてくる。
コピペ運用 vs 自動化:数字で見ると歴然
私が手元で計測した数字を並べる。
| 項目 | ChatGPT コピペ運用 | Python 自動化 |
|---|---|---|
| 1記事あたりの工数 | 15〜30分 | 2〜3分(確認のみ) |
| 投稿までのステップ数 | 8〜12ステップ | 1コマンド |
| スケール上限 | 体力依存 | スクリプト次第 |
| 失敗検知 | 自分で気づく | ログ + Discord 通知 |
| 再現性 | 低い(毎回微妙に違う) | 高い |
| 初期コスト | 低い | 高い(数時間〜数日) |
コピペ運用が悪いわけじゃない。「今日1本書く」なら十分通用する。問題はスケールしないこと。私が3ヶ月試して出した結論は、1日2本が体力の限界で、それ以上やろうとすると質から先に落ちる——というものだった。
なぜ ChatGPT を使っても作業が減らないのか
人間がボトルネックのまま抜け出せていないから。それだけだ。
ChatGPT は生成してくれる。でもその出力を受け取って確認して、コピーして、貼り付けて、整形して、投稿する——この流れを毎回人間が回す構造は変わっていない。「高性能な入力補助ツール」と本質的に変わらない。3ヶ月コピペ運用して、詰まったパターンが3つあった。
ひとつは出力品質のバラつき。同じプロンプトを投げても毎回文体が微妙にずれる。それを読んで修正する時間が地味にかかった。15分の節約が確認と手直しで10分溶ける——そういう状態が2ヶ月続いた。
もうひとつはコンテキストの揮発。ChatGPT のセッションは使い捨てで、昨日の設定を今日は覚えていない。「私はこういうスタイルで書いています」と毎回説明し直すのが面倒になって、結局テンプレをコピペするだけになった。そうなると ChatGPT を使う意味がほぼない。
最後が投稿先との断絶。ChatGPT は文章を生成してくれるが、WordPress や note への投稿は自分でやる。画像貼り付け、タグ設定、公開設定——このラストワンマイルが意外と長い。全部手作業のまま残る。
実証:note投稿が安定するまでに3回壊れた
私の環境で、note への自動投稿が安定するまでに3回壊れた。
1回目。storage_state.json でセッション管理していた初期バージョン。クッキーが21個中15個期限切れになった時点で静かに死んだ。エラーも出ない。「投稿成功」のログだけ残って、実際には何も投稿されていない。「あれ、note に何も載ってない」と気づくまで2日かかった。
# ダメだったやつ(storage_state は期限切れで無音死する)
context = await browser.new_context(storage_state="note_session.json")
2回目は Playwright の headless Chromium で再挑戦した。今度は note.com の UI が変わっていて、下書きプレビュー URL(?app_launch=false)を公開済みと誤検出した。ログには「公開完了」と出ているのに実際には下書きのまま。これも2日後に気づいた。2回連続で同じパターンで詰まったとき、さすがに設計が悪いと気づいた。
3回目でようやく安定した。Brave CDP に切り替えて、日常使いのブラウザのセッションをそのまま流用する方式にした。
# 安定版の骨格(コピペ可)
from playwright.sync_api import sync_playwright
from cdp_browser import connect_cdp_sync
with sync_playwright() as pw:
browser, ctx = connect_cdp_sync(pw)
page = ctx.new_page()
page.goto("https://note.com/")
# Brave の既存セッションをそのまま使うので再ログイン不要
browser.close()
肝は「ブラウザを新規起動しない」こと。日常使いの Brave に既にログインしているなら、そのセッションを CDP で操作するのが一番安定する。クッキーの期限切れ問題がそもそも発生しない構造になる。
Ollama で量産、Claude で品質管理の分業制
投稿の自動化ができたとして、次の問題は「何を投稿するか」だ。
今は Ollama と Claude を目的で使い分けている。量産は Ollama(qwen3.5:9b)に任せて、品質チェックだけ Claude Haiku を通す。
投稿候補の生成 → Ollama (qwen3.5:9b) で量産
↓
品質チェック・採点 → Claude Haiku
↓
S/A/B/C/D/F でスコアリング → ファイル名に埋め込む
↓
高スコアから自動投稿
Ollama は API 代がゼロで、レート制限もない。1日100本生成しても課金されない。品質は Claude Sonnet 4.6 に比べると落ちる。ただスコアリングでフィルタリングすれば実用になる。S/A/B を投稿キューに積んで、C 以下を別フォルダに退避——この仕組みを作るのに2日かかったが、稼働してからは放置で回る。
Claude は「少量・高品質」なタスクに絞った。記事の最終仕上げ、品質採点の基準設計、判断系の作業。量産は Ollama、Claude Code は判断に使う分業で、API コストを月2,000〜3,000円に抑えながら1日10〜20本のコンテンツを回している。
コピペで使える:最小構成の自動投稿スケルトン
launchd で毎日決まった時間に実行する場合の最小構成を貼っておく。
<!-- ~/Library/LaunchAgents/com.taito.autoposter.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.taito.autoposter</string>
<key>ProgramArguments</key>
<array>
<string>/usr/bin/python3</string>
<string>/path/to/your/poster.py</string>
</array>
<key>StartCalendarInterval</key>
<array>
<dict>
<key>Hour</key><integer>7</integer>
<key>Minute</key><integer>0</integer>
</dict>
</array>
<key>StandardOutPath</key>
<string>/tmp/autoposter.log</string>
<key>StandardErrorPath</key>
<string>/tmp/autoposter_err.log</string>
</dict>
</plist>
登録は launchctl load ~/Library/LaunchAgents/com.taito.autoposter.plist の1行だけ。Mac を再起動しても自動で起動する。
cron と違って launchd はスリープ中に起動時刻を過ぎても、次の起動時に実行してくれる。MacBook で運用するならこっちが圧倒的に安定する。cron で運用していた頃は、蓋を閉じて外出するたびに投稿が飛んでいた。1週間分の投稿が抜けていることに後から気づいたとき、詰めが甘かったと思った。
よくある質問
ChatGPT と Ollama、品質の差はどのくらい?
SNS 投稿レベルなら Ollama(qwen3.5:9b)で十分だと思っている。読んで「AI臭い」とわかる文章は出てくるが、スコアリングと少し手直しで使える。長文記事になると Claude Sonnet 4.6 との差は明らかで、文章の流れが全然違う。用途で使い分けるのが現実的だ。
自動化の初期コストはどのくらいかかった?
Python、Playwright、launchd それぞれ「動くまで」に2〜3日ずつかかった。特に note.com の自動投稿は UI 変更で2回やり直した。最初の1ヶ月は手作業より時間がかかる——それは覚悟しておいたほうがいい。1ヶ月を越えてからようやく「減った」実感が出てきた。
CDP・Brave で自動化するメリットは?
セッション管理から解放されること——それに尽きる。日常使いの Brave でログインしたままにしておけば、スクリプト側でセッションを気にしなくていい。クッキーの期限切れがそもそも発生しない構造になる。headless Chromium で新規ブラウザを立ち上げる方式は、ログインが必要なサービスで毎回詰まる。
Ollama はどのスペックのマシンが必要?
qwen3.5:9b なら M シリーズの MacBook Pro(16GB 以上)で動く。私は M5 32GB で動かしていて、生成速度は Claude に比べるとやや遅いが実用範囲。gemma4:26b は重すぎてパイプラインには入れていない。16GB でも動くが、他のアプリと並行すると詰まることがある。
まとめ
ChatGPT コピペ運用の問題は AI の質じゃない。人間がボトルネックのまま抜け出せていない構造にある。生成→コピー→貼り付け→投稿の流れを毎回人間が回す限り、スケールしない。
Python + launchd で実行を自動化して、Brave CDP でブラウザのセッション管理を省いて、Ollama と Claude を量産・品質管理で分業する——この構成に落ち着くまでに3〜4ヶ月かかった。最初の1ヶ月は手作業より時間がかかる。それは投資だと割り切るしかない。
✨
この記事を読んだあなたに:
– Ollama ローカルLLM 比較2026:qwen3.5 vs gemma4 実測レポート
– launchd 使い方 入門:cron より安定するMac自動化の基本設定
– Claude Code 専属CTO活用術:非エンジニアが全部任せる方法