ClaudeCodeとMakeで自動投稿を分担してみて気づいたこと

「全部自動化したい」と思ったとき、
最初にやりがちなのが、1つのツールにすべてを任せようとすることだと思います。

僕もそうでした。
Makeで全部回せるはずだと信じて設定を組み始め、
途中でどうしても詰まる部分が出てきて、
「なんでこれが動かないんだ」と頭を抱えた夜が何度もありました。

この記事では、Claude CodeとMakeをそれぞれの得意な役割に分けて運用してみて気づいたことを、
正直にお伝えします。
自動化は一気に完成させるものじゃなくて、
役割分担で少しずつ安定させていくものだ、
というのが今の僕の実感です。

1つのツールに全部任せようとして、壁にぶつかった
Claude CodeとMakeに、それぞれの仕事を持たせる
1. Claude Codeが向いている仕事
2. Makeが向いている仕事
役割分担で気づいた、自動化の本質
1. 「全部自動化」よりも「最適な分担」を目指す
2. 「完璧な設計」を待っていたら、永遠に動かない
実際の1日の運用フローはこうなっている
まとめ｜自動化は役割分担で、少しずつ安定させていくもの

1つのツールに全部任せようとして、壁にぶつかった

自動化を始めた頃、僕の頭の中にあったのは
「すべてがMakeで動く、完全自動の仕組み」でした。

記事の生成も、投稿も、SNSへの展開も、
全部Makeのシナリオの中に収めてしまえば、
あとは寝てても回り続けるはずだ、と。

実際、WordPressへの自動投稿やBufferを使ったSNS連携は、
Makeとの相性がよくて、スムーズに動かせました。
でも問題は「note」でした。

noteには公式のAPIが一般公開されていないため、
Makeからのアクセスが安定しない。
ブラウザを通じた操作が必要な部分が多くて、
ノーコードツールだけで完結させようとすると、
どうしても無理のある構成になってしまうんです。

そこで一度立ち止まって考えました。
「全部を1つのツールでやる必要は、本当にあるのか？」と。

その問いへの答えが、
Claude CodeとMakeの役割分担という形になりました。

Claude CodeとMakeに、それぞれの仕事を持たせる

今の僕の運用は、大きく2つの軸に分かれています。

朝と夕方はClaude Code（またはCodex）が動いて、
noteへの記事下書きとサムネイル生成を処理する。
昼間はMakeが動いて、
WordPressへの記事投稿とSNSへの展開を担当する。

この分け方にしてから、
「詰まる」場面が劇的に減りました。

Claude Codeが向いている仕事

Claude Codeは、コードを書いたり実行したりしながら
ブラウザ操作や複雑な処理を組み合わせることが得意です。

noteのように、APIが整備されていないプラットフォームへの投稿は、
ブラウザを通じた自動操作が必要になります。
これはMakeが苦手とする領域で、
Claude Codeなら「エージェント」として動かせるので、
柔軟に対応できるんです。

noteへの下書き保存・タイトル入力・本文流し込み
サムネイル画像の生成と設定
特定条件でのファイル操作やログ記録

特にサムネイル生成は、
Vertex AI Imagenを呼び出してローカルに保存する処理も含んでいるので、
コード実行が前提のClaude Code側で動かすのが自然でした。

Makeが向いている仕事

一方でMakeは、
APIが整備されているサービス間をつなぐのが圧倒的に得意です。

WordPressのREST APIは、
ConoHa WING環境でも`?rest_route=`形式を使えば安定して動かせる。
BufferはMakeとの公式連携があって、
投稿スケジュールの制御も視覚的にわかりやすい。

Google Gemini APIで記事本文を生成する
Vertex AI Imagenでアイキャッチ画像を生成する
WordPressへREST API経由で記事を投稿する
Bufferに投稿内容を送ってSNS展開する

この流れはすべてMakeのシナリオの中で完結していて、
毎日昼の決まった時間にトリガーが走るように設定してあります。
一度動き出したら、僕が何もしなくても記事が公開されていく。
これが「仕組みを作るということか」と実感できた瞬間でした。

役割分担で気づいた、自動化の本質

2つのツールを使い分けるようになってから、
「自動化」に対する見方が少し変わりました。

以前は、1つの完璧なシステムを最初から作ろうとしていました。
全部つながって、全部動いて、全部が自動で完了する状態を、
最初から完成させようとしていた。

でも実際は違って、
まず動く部分を作る、
そこに別の部分を継ぎ足す、
うまく動かない部分だけ別の手段で補う、
という積み上げ方の方が、ずっと早く安定するんです。

「全部自動化」よりも「最適な分担」を目指す

自動化を始めようとしている人がよく陥るのが、
「このツール1本で全部できるはずだ」という思い込みだと感じています。

正直に言うと、僕もそれで遠回りしました。
Makeだけで全部やろうとしていた時期は、
noteの投稿部分がどうしても安定せず、
シナリオを何度作り直してもエラーが出る。
「もしかして自分の設計が間違っているのか」と、
自信をなくしかけた時期もありました。

でも問題はMakeの使い方ではなくて、
「Makeに向かない仕事をMakeに頼んでいた」ことだったんです。

ツールにはそれぞれ得意なこと・苦手なことがある。
それを見極めて、適切な仕事を割り振ることが、
安定した自動化の設計において一番大切なことだと、
今は思っています。

「完璧な設計」を待っていたら、永遠に動かない

もう1つ気づいたことがあります。
完璧な仕組みを最初から作ろうとすると、
設計の段階で止まってしまう、ということです。

「どのツールを使うか」「どんな順番で処理するか」
「エラーが出たときはどうするか」……
考えれば考えるほど決断できなくなって、
結局何も動かないまま時間だけが過ぎていく。

僕が実際にやってみてよかったのは、
「今日動かせる一部分だけを作る」という割り切りでした。

最初はWordPressへの投稿だけをMakeで動かして、
それが安定してから、画像生成をつなぎ、
さらに安定してから、SNS展開を追加した。
noteへの投稿はその後で、Claude Codeという別の手段で対処した。

遠回りに見えて、一番の近道だと思っています。

実際の1日の運用フローはこうなっている

具体的に、今の運用がどんなタイムラインで動いているかをお伝えします。

朝の時間帯に、Claude Codeが起動して
note向けの記事コンテンツを下書き保存します。
サムネイル画像も同タイミングで生成されて、
投稿の準備が整った状態になる。

昼になると、MakeのスケジュールトリガーがONになって、
Google Gemini APIに記事本文の生成を依頼し、
Vertex AI ImagEnでアイキャッチ画像を生成、
WordPressにREST API経由で投稿、
Bufferに内容を送ってSNS投稿をスケジュールする、
という流れが自動で走ります。

夕方にも必要に応じてClaude Code側が動いて、
追加のコンテンツ処理やログの確認が行われる。