2026/04/13Claude Code

Skills活用AI活用

Claude CodeでSNS投稿を自動化する方法｜Browser Use CLIから現行構成へ

【2026年8月13日更新】この記事は公開当初、note・X Articlesへの自動投稿を Browser Use CLI で実装した手順として書いていた。その後、2026年5月にnote側のエディタ変更でBrowser Use CLI経由の本文挿入が通らなくなり、noteはPlaywright Python SDKへ、X Articlesは2026年7月にXのDeveloper API直叩きへ移行している。当時のBrowser Use CLI手順はそのままでは再現できないため、経緯と2026年8月時点の構成に書き改めた。

「コンテンツ生成」と「コンテンツ投稿」の間にある壁

Claude Codeでブログ記事を自動生成する。サムネイル画像も自動で作る。ここまでは多くのエンジニアが実現している。しかし、「SNSプラットフォームに自動投稿する」段階で手が止まる人は多いのではないだろうか。

理由は明確だ。記事生成はファイル操作とAPI呼び出しで完結するが、SNS投稿にはブラウザ操作が必要になる。ログイン、画像アップロード、テキスト入力、投稿ボタンのクリック。これらはAPIが公開されていないプラットフォームでは、ブラウザ自動化なしに実現できない。

私はこのパイプラインを最初にBrowser Use CLIで組み、その後noteはPlaywright、X ArticlesはAPI直叩きへと2回作り直した。この記事では、その経緯と2026年8月時点で動いている構成を共有する。同じ壁にぶつかる人が、最初から壊れにくい方を選べるようにするためだ。

結論：2026年8月時点の構成

先に現行の構成を示す。媒体ごとに投稿手段が違うのがポイントで、1つのツールで全媒体を賄う構成はもう取っていない。

note投稿: Playwright Python SDK。永続プロファイルでログインを維持し、本文はクリップボード経由でペースト、画像はfile inputへ直接セットする
X Articles投稿: XのDeveloper API（Articlesの下書き作成・公開エンドポイント）を直接呼ぶ。ブラウザは起動しない
MicroCMS（自社ブログ）投稿: MCP経由。こちらも当初からブラウザ操作なし
Browser Use CLI: リッチテキストエディタへの本文挿入からは外した。セレクタを事前に書けない未知サイトの探索・データ抽出に用途を絞っている

以下は、この構成に至るまでの経緯だ。

読者特典・無料ダウンロードClaude Codeを「素のまま」使うな無料でダウンロード →

Browser Use CLIとは

ブラウザ操作をAIに任せるツール

Browser Use CLIは、AIエージェントにブラウザ操作を実行させるオープンソースツールだ。Chromiumベースのブラウザを起動し、ページの読み込み・要素のクリック・テキスト入力・スクリーンショット取得などを自然言語の指示で実行できる。

Claude Codeとの組み合わせでは、Claude CodeのSkillsからBrowser Use CLIを呼び出す形で連携する。Skillが記事を生成し、画像を作成し、その後Browser Use CLIでSNSにログインして投稿するという流れだ。

2026年4月時点で、なぜBrowser Use CLIを選んだか

Claude Codeで使えるブラウザ自動化ツールは複数存在する。Claude in Chrome（Anthropic公式のChrome拡張）、Playwright MCP（Microsoft）、Chrome DevTools MCPなどだ。

その中で、2026年4月の選定時点でBrowser Use CLIを選んだ理由は以下の通りだ。

永続セッション: ログイン状態を保持できるため、毎回ログインし直す必要がない
ファイルアップロード対応: 画像のアップロードが安定して動作する
Claude Code Skillsとの親和性: CLIツールなのでSkillsのbashコマンドから呼び出せる

この判断自体は、当時わかっていた情報の範囲では間違っていなかったと今も思っている。誤っていたのは「1つのツールがすべてのサイトに効く」という前提のほうだった。

note自動投稿：Browser Use CLIで作り、Playwrightで作り直した

最初にnoteから始めた理由

SNS自動投稿の実装は、noteから着手した。noteは記事投稿のUIがシンプルで、投稿フローのステップ数が少ないため、練習台として最適だったからだ。

noteでの基本的な投稿フローは以下の通りだ。ここは今も変わっていない。

noteにログイン（初回のみ。以降はセッション維持）
「投稿」ボタンをクリック
タイトルを入力
本文をペースト
サムネイル画像をアップロード
公開設定を確認して投稿

ファイル選択ダイアログ問題と解決策

noteの自動投稿で最初に苦労したのが、サムネイル画像のアップロードだ。

通常、画像アップロードボタンをクリックするとOS標準のファイル選択ダイアログが開く。しかしこのダイアログはブラウザのウィンドウではないため、ブラウザ自動化ツールからは操作できない。

解決策はCDP（Chrome DevTools Protocol）経由でfile input要素に直接ファイルパスをセットする方法だ。ファイル選択ダイアログを開かず、プログラム的にファイルを指定できる。

この考え方はツールが変わっても有効で、現行のPlaywrightでも同じことをしている。Playwrightの set_input_files() は内部でCDPの DOM.setFileInputFiles を直接発行するため、ラッパー層を経由せずにファイルを渡せる。「ファイル選択ダイアログ問題」はブラウザ自動化では頻出する課題だが、答えは一貫してCDPだ。

2026年5月、合成イベントが弾かれて止まった

1ヶ月ほど順調に動いた後、noteへの投稿が突然通らなくなった。タイトルとサムネイルだけが入り、本文0文字の空の下書きが量産されるという壊れ方だった。

原因は、noteのエディタがProseMirror系のリッチテキストエディタで、JavaScriptで生成した合成イベント（synthetic event）を「本物のユーザー操作ではない」と判定して黙殺することだった。合成ClipboardEventの発火も、execCommand の直接呼び出しも、innerHTML の書き換えも、すべて素通りされる。ProseMirrorはnote以外にNotion・Substack・Linear・Confluenceなどでも採用されているため、これらの媒体では同じ壁にぶつかる。

ここでツールを乗り換えた。Playwrightのキーボード操作はCDPの Input.dispatchKeyEvent を呼ぶため、ブラウザから見てハードウェア入力に近い扱いになる。userActivationを獲得した状態でクリップボードのペーストを実行できるので、ProseMirrorの権限ゲートを通過できる。書き直したnote投稿スクリプトは2026年5月から現在まで稼働している。

移行時の調査過程と、Playwright側で見つかった非自明なノウハウは別記事にまとめている。noteやSubstackのようなリッチエディタを自動化する予定があるなら、先にこちらを読んでおくと同じ4時間を溶かさずに済む。

Claude Codeブラウザ自動化｜Playwrightとbrowser-use比較

X Articles：エディタ自動操作からAPI直叩きへ

当初はnoteの経験をそのまま応用した

noteでブラウザ自動化の扱いに慣れた後、X Articles（X上の長文記事）への自動投稿に取り組んだ。基本的なアプローチはnoteと同じで、エディタをブラウザ経由で操作する方式だった。当時ぶつかったX Articles固有の注意点は以下の通りだ。

カバー画像のクロップ: X Articlesではカバー画像の下部が切り取られる。そのため、画像生成時にテキストやアイコンを上半分〜中央に寄せて配置する必要がある。これは表示側の仕様なので、投稿手段を変えた今も同じ設計にしている
リッチテキストエディタ: エディタ経由で投稿していた頃は、HTMLをそのままペーストすると意図しない整形が入ることがあり、セクションごとに分割してペーストしていた
下書き保存: 自動投稿では公開ではなく下書き保存を基本とする。最終確認は人間が行う。この原則は今も変えていない

2026年7月にAPI直叩きへ切り替えた

X Articlesについては、2026年7月にブラウザ操作をやめ、XのDeveloper APIで下書きを作成し、必要なら公開まで行う方式に切り替えた。カバー画像・本文中の挿絵・太字やリンクまで、すべてAPIのリクエストで入る。

切り替えた理由は3つある。エディタのDOM変更で壊れるリスクが消えること、実行が速いこと、そしてブラウザを起動しない分だけ失敗の切り分けが簡単なことだ。公開APIがある媒体では、ブラウザ自動化を選ばない。これが2回の作り直しから得たいちばん大きな判断軸だった。

なお、XのAPIは従量課金のプランがあり、コストは契約するプランによって変わる。最新の料金・利用条件はX公式の開発者向け料金ページで確認してほしい。

パイプライン全体像と、その変化

初期構成（2026年4月時点）

下図は最初に組んだ構成だ。データ収集から記事執筆、画像生成、CMS投稿、SNS投稿までを1本の流れとして描いている。

ただしnote投稿・X Articles投稿の2工程（Browser Use CLI）と、サムネイル生成（Gemini API）の計3箇所は、現在いずれも別の方式に置き換わっている。この図は当時の記録として見てほしい。現行の構成はこの下に示す。

現行構成（2026年8月時点）

データ収集: SEOキーワードCSV・既存記事CSV・実績DBを読み込み（変更なし）
記事執筆: HTML形式でSEO記事を生成（変更なし）
サムネイル生成: gpt-image-2をサブスクリプションの利用枠経由で呼び出す方式に変更（旧: Gemini API）
挿絵生成: HTML/CSS→Puppeteerスクリーンショットで図解を生成（変更なし・コスト0円）
MicroCMS投稿: MCP経由で画像をアップロードし、記事を下書き投稿（変更なし）
note投稿: Playwrightを使う独立したスキルに分離（旧: 同一スキル内でBrowser Use CLI）
X Articles投稿: XのAPIを使う独立したスキルに分離（旧: 同一スキル内でBrowser Use CLI）

いちばん大きな変化は「1スキル全部入り」をやめたことだ。SEO記事のスキルはCMSへの下書き投稿までで完結させ、note・X Articlesはそれぞれ独立したスキルにした。媒体ごとに最適な手段（Playwright／API）が違ううえ、1媒体が壊れたときにパイプライン全体が止まるのを避けたかったからだ。

変えていない部分もある。挿絵生成にAI画像生成APIを使わず、HTML/CSS→Puppeteerで生成している点だ。テキスト主体の図解画像なら、HTMLで作る方が品質が安定し、かつコストが0円になる。ここは初期から一貫している。

パイプラインの設計思想

このパイプラインは「Thin Harness, Fat Skills」の設計パターンに沿っている。CLAUDE.mdには「SEO記事はこう書け」とは一切書かない。スキル内に記事執筆ルール・画像生成手順・CMS投稿手順がすべて定義されており、スキルを呼び出すだけで工程が実行される。

共通の処理（画像アップロード、CMS投稿等）は共通コンポーネントとして切り出し、SEO記事スキル・X記事スキル・note記事スキルから共有参照する構造だ。投稿手段だけを媒体ごとに差し替えられるのは、この分離があるからでもある。

運用のポイント

/scheduleで定期実行する

コンテンツ制作パイプラインは定期実行と相性が良い。Claude Codeの/schedule機能を使えば、指定した時間に自動でスキルを実行できる。

私の運用では、GSCデータの定期取得（週1回）と組み合わせている。GSCで伸びているキーワード周辺の記事を自動生成し、内部リンクで繋げる施策だ。「資産の状態確認」としてWebサイトやサービスの状態を定期モニタリングする用途に、/scheduleは非常に使いやすいと実感している。

remote-controlでスマホから確認する

パイプラインの実行状況はremote-control機能でスマホから確認できる。基本的にremote-controlをONにしておき、外出先からいつでもタスクの進行状況を確認し、必要があれば追加の指示を出す。

1人経営で外出も多い私にとって、「PCの前にいなくても仕事が進む」のは大きなメリットだ。記事の自動生成が完了したら、スマホで下書きを確認して公開判断をするだけでよい。

「投稿」は常に下書きにする

自動パイプラインで重要なルールが1つある。自動投稿は必ず下書き（draft）状態にすることだ。

AIが生成した記事には、事実確認が必要な箇所や、微妙なニュアンスの調整が必要な箇所がある。Hooksで品質チェックを自動化していても、最終判断は人間が行うべきだ。自動化の範囲は「下書き作成まで」とし、公開判断は人間が行う。これが安全な運用ラインだ。

記事の反応と品質の関係

noteに投稿した記事には実際にいいねが多くつき、どの記事も見てもらえている実感がある。自動化しているからといって品質が低いわけではない。

品質を保てている理由は明確だ。浅い情報を大量生産するのではなく、実績・知見 × 公的データ × トピックの深い知識を組み合わせた記事を書いているからだ。自動化しているのは「作業工程」であって「思考工程」ではない。記事の骨格となる実体験やデータは事前にデータベースに蓄積しており、スキルはそれを適切に組み合わせて記事にするだけだ。

まとめ

Claude CodeでSEO記事の執筆からSNSプラットフォームへの投稿まで自動化することはできる。ただし投稿手段は媒体ごとに選び直す必要があり、一度組んだら終わりではない。1年弱で2回作り直した経験から得た要点は以下の通りだ。

公開APIがある媒体はAPIを使う。X ArticlesはDeveloper API直叩きに切り替えて、UI変更で壊れる要因そのものを消した
APIが無い媒体（note）はPlaywright。ProseMirror系のリッチエディタは合成イベントを黙殺するため、JavaScript経由で本文を流し込む方式では通らない
ファイル選択ダイアログ問題はCDP経由でfile inputに直接セットして解決する。ツールが変わっても考え方は同じ
挿絵はHTML/CSS→Puppeteerで生成すればコスト0円。ここは1年近く変えていない
自動投稿は常に下書き。公開判断は人間が行う
1スキル全部入りにしない。媒体ごとにスキルを分けておくと、1媒体が壊れても他が止まらない

自動化の本質は「作業を省く」ことではなく、「判断に集中できる環境を作る」ことだ。記事の骨格を考え、データを蓄積し、公開の判断をする。その間の作業工程をAIに任せることで、1人でも持続可能なコンテンツ運用が実現する。壊れたら壊れた箇所だけ差し替える——そのために、媒体ごとに切り離しておくことが効いてくる。

記事生成そのものの自動化と、Search Consoleのデータを起点にしたSEO運用については、こちらの記事で解説している。