Claude Codeでの自動化を進めていると、「どこまで機械に任せて、どこから手動を残すか」という線引きに迷う場面が出てきます。この記事では、SNS投稿の自動化を実例に、その判断軸をどう決め直したかを紹介します。
WordPressとnoteを同じ扱いにしていた
ぼくの運用では、記事の下書き生成から各SNSへの投稿までをClaude Codeに任せています。ただ、しばらくの間、WordPressとnoteの投稿は同じ運用ルールで扱っていました。
具体的には、過去に一度、意図しないタイミングで記事が公開されてしまう事故があったこともあり、どちらも「下書きとして保存し、最終確認は自分の目で行ってから手動で公開する」という2段階の運用にしていたのです。慎重を期すという意味では悪くない判断でしたが、実はこれ、WordPressとnoteの裏側の仕組みの違いをきちんと考慮したうえでの判断ではありませんでした。
なぜ一律運用を見直すことになったのか
WordPressは公式APIで投稿している
改めて自分の実装を見直すと、WordPressへの投稿はアプリケーションパスワード認証を使った公式のREST API経由で行っていました。これは決められた手順で認証し、決められたエンドポイントにデータを送るだけの、仕組みとして安定した自動化です。過去の公開事故も、API自体の欠陥ではなく運用ルールの設定ミスが原因だったことが分かっていました。
noteには記事投稿用の公開APIが存在しない
一方noteには、記事投稿を行うための公式な公開APIが用意されていません。そのため、ブラウザを自動操作する仕組み（Playwright経由のChromiumなど）に頼らざるを得ない状態です。ブラウザ自動化は便利な反面、サイト側の画面変更やOS・ブラウザのアップデートの影響を受けやすく、API経由の自動化に比べると壊れやすい性質があります。
APIの有無で自動化の踏み込み方を変える
この違いに気づいてから、運用を次のように分けました。
WordPress：即時公開まで自動化
公式APIで安定して投稿できる場所なので、思い切って下書きを介さず即時公開まで自動化することにしました。仕組みとして信頼できる部分は、迷わず任せる方向です。
note：引き続き下書き保存までに留める
一方noteは、ブラウザ自動化という壊れやすい仕組みに頼らざるを得ないため、当面は下書き保存までに留め、公開は自分の目で確認してから手動で行う運用を続けることにしました。
この結果、「なんでも自動化する」でも「なんでも手動にする」でもなく、裏側の実装方式によって自動化の踏み込み方を変える、という基準が明確になりました。
実際の結果と気づき
この線引きに変えてから、WordPressの投稿作業がかなり軽くなった一方、noteについては「無理に自動化を広げなくていい」という納得感を持って運用できるようになりました。以前は「もっと自動化しなければ」という焦りが漠然とあったのですが、今は「任せられる場所を見極めて任せる」という考え方に落ち着いています。
自動化の判断に迷ったときは、「頻度」や「便利そうかどうか」だけでなく、「そもそも公式に安定した手段（API）が用意されているか」を最初に確認する。この視点を持つようになったのが、今回の一番の収穫でした。
よくある質問（FAQ）
Q. ブラウザ自動化は使わない方がいいのですか？
A. そういうわけではありません。公式APIがない場合の有力な選択肢ではありますが、壊れやすさというリスクを理解した上で、公開まで自動化するか・下書き止まりにするかを判断するのが大切だと感じています。
Q. WordPressの即時公開に切り替えて事故は起きていませんか？
A. 過去の公開事故は運用ルールの設定ミスが原因だったため、その部分を修正した上で切り替えています。今のところ意図しない公開は起きていません。
Q. この判断軸は他の自動化にも応用できますか？
A. できると思います。ツールやサービスを自動化する際、「公式に安定した手段が用意されているか」を確認する視点は、SNS投稿に限らず幅広く使えます。
まとめ
SNS投稿の自動化で、WordPressは即時公開・noteは下書き止まりと運用を分け直した実例を紹介しました。「なんでも自動化」ではなく、裏側にAPIがあるかどうかで踏み込み方を変える。この判断軸は、他の自動化を検討する際にも参考にしていただけると思います。
