Claude Codeは個人開発の速度を別次元に引き上げる。だが、コスト爆死・暴走・沼化という代償も同時にやってくる。良い面だけ書いてある記事を読んで始めると痛い目を見るので、両面を記録しておく。

ムラサキ

「確認しますか？」→「まって」→「進めちゃいました」の流れ、本当にきつい。これだけで記事1本書けるレベルの話がある。

何を作ったか

ゲームのマッチングサービス

ゲームプレイヤー向けのマッチングWebサービスを作った。「欲しいもの」と「出せるもの」を登録するだけで交換相手が自動で見つかる双方向マッチングが特徴だ。OCRで画像からデータを読み取る機能、Google/Facebook/Apple OAuthとマジックリンク認証、Web Push通知、複数言語対応を実装した。

技術スタックと開発規模

フロントはReact + Vite + Tailwind CSS、バックはExpress + MongoDB（Mongoose）、インフラはRender + MongoDB Atlasで構成した。開発期間は半月未満、コミット数は200件超。認証・通知・OCR・複数言語対応まで含めるこの規模を個人開発で実現できたのはClaude Codeなしでは難しかった。

Claude Codeが本当に強かった場面

テストとリファクタリングを自動でやってくれるのと同様に、コードレビューもLLMに任せられる。4手法ベンチマークで検出率94%を実測した方法で詳細を解説している。

中規模機能が1セッションで動く速度

通常なら数日かかる機能が1セッションで動く。OCR連携、Web Push、複数言語対応——これらの機能を組み込むだけで動く成果物が出てくる。個人開発のボトルネックだった「実装の遅さ」が解消される。

上記のClaude Codeの時間は実行時間ではなく人間系の確認なども含めたタスク終了までの時間です。動作はほとんどが1分未満で終わります。

体感で5〜10倍速。これは誇張ではない。

Claude DesignからのhandoffでUIモックを受け取り、既存の自前コンポーネントと整合性を取りながら統合した実例はClaude Design→Code｜handoffで既存プロジェクトに統合にまとめた。

テストとリファクタリングを自動でやってくれる

CLAUDE.mdに「修正したらテスト必須」と書いておくと、Vitest/Jestのテストを生成してくれる。カバレッジが自然と上がる。

ただしリファクタリングは危険な面もある。本番公開時に環境変数の重複エラーが発生した原因は、同じ役割のファイルがふたつ存在していたこと。無駄なファイルを生成していたのはAIだ。「良かれと思って」別ファイルを作った結果、本番でトラブルになった。リファクタリング周りは改善と悪化が表裏一体だ。

バグ報告を投げるだけで原因特定してくれる

コンパイルエラーや型エラーの修正も時間がかかる作業だが、Claude Codeはこれを自分で検知して修正する。受け取ったコードはすでに動く状態だ。

不具合調査も同じ。バグ番号と症状を投げるだけでコードを読んで原因を特定する。あるケースではSMTPの送信処理を同期的に待っていたことが原因で、送信完了を待たずに次の処理に進む方式に修正した。メール送信の完了を待つ必要がなくなるパターンで、「どこが悪いかわからない」という調査の最も時間がかかるフェーズを削減できるのが大きい。

困りどころ——誰も教えてくれなかった現実

セッション間の忘却は単一プロジェクトならCLAUDE.mdで吸収できるが、複数プロジェクトをまたぐと別の設計が要る。4プロジェクト横断で知識を蓄積するKarpathy式Second Brainの実装パターンをまとめたので、同じ悩みを持つ人は参考になるはず。

画像のみ貼り付けたターンが原因でセッション全体が400エラーで詰む現象も、Claude Code 2.1系で頻発するハマりどころの1つです。再現条件と400エラー復旧と外出先での限界を別記事にまとめました。

コスト爆死の話

Claude Codeの定額プラン（Pro/Max）とClaude APIの従量課金は別物だ。定額プランで使う分には上限内で収まるが、スクリプトからAPIを直接叩く処理は別途従量課金が発生する。この区別を意識しないままAPIを使い続けると、請求書を見るまで気づかない。

定額プラン内にも使用量の上限がある。Proは特に制限が厳しく、毎日フル活用すると週の後半には上限に達する。Max 5x（月$100）に移行してからも、リモートセッションで沼って使い続けると上限に近づく。

月の途中でProからMaxへアップグレードする場合、Proの残り分が日割りで差し引かれてMaxの料金が請求される。二重払いにはならない。コスト追跡を仕組み化するなら、/costコマンドのモデル別分析をレッスン13で習得するのが手っ取り早い。

当時はモデルを使い分ける発想がなく、Opusで全部回していました。同じ轍を踏まないためのOpus・Sonnet・Haikuの3層スタック運用を、その後に整理しています。

暴走する話

指示したスコープ外のコードを勝手にリファクタリングする、コメントを追加する、確認もせずにタスクをクローズ済みに更新する——これがClaude Codeの暴走だ。指示が曖昧だと「良かれと思って」勝手に動く。

対策はCLAUDE.mdへの明記だ。「周辺コードをリファクタしない」「コメントを勝手に追加しない」「クローズはユーザーが判断する」と書いておくと頻度は下がる。ただし完全には防げない。CLAUDE.mdに「ユーザーの確認を待つ」と書いても、確認を取らずに進めることがある。ルールは補助的なものに過ぎず、確認が必要な局面では自分が能動的に判断を止める必要がある。

忘れる話

長期開発ではコンテキストが溢れてcompact（会話の圧縮）が走り、直前の作業内容が消える。セッションをまたぐ情報はCLAUDE.mdとBUGS.md/FEATURES.mdに外部化する運用が現実解だ。

同じ間違いを何度も繰り返すのはこのためだ。前のセッションで試した失敗パターンがリセットされ、また同じアプローチを試みる。「うまくいかなかった方法」もCLAUDE.mdに記録しておくことで対策できる。

Windowsの改行コード問題

Edit toolでCRLFのファイルを編集するとマッチングに失敗することがある。Windowsで開発している場合はnode -eで直接書き換えるなど回避策が必要になる。最初にCRLF/LF設定を統一しておくことを勧める。

沼になる——リモートセッションの危険性

Claude Codeのリモートセッション機能を使うと、スマートフォンから自宅PCのClaude Codeを操作できる。外出先でも開発が続けられるのが沼の入り口だ。

どこでもできるから止まらない。電車の中でも、寝る前でも、構想がすぐ形になる楽しさに歯止めが効かなくなる。生産性は出るし確かに面白いが、使用量の上限に達するのも早い。睡眠時間を削ってまで使う羽目になりやすい。「今日はここまで」を決める自制が必要——これは道具の問題ではなく、使う人間の問題だ。

ムラサキ

リモートセッション始めると本当に沼。色々できて楽しすぎて、構想がすぐ形になる感覚はやめられない。ただコスト消費が速いので使用量の上限との戦いになる。

結局どう使うのが正解か

CLAUDE.mdとBUGS.mdが命綱

CLAUDE.mdはAIへの「仕事の説明書」。技術スタック・コーディング規約・禁止事項・よく使うコマンドを書いておくと品質が安定する。BUGS.mdは不具合の状態管理ファイルで、セッションをまたいでもバグの状況が保持される。この2ファイルなしで長期開発は困難だ。

確認はオーナーがやる——役割分担の徹底

実装・テスト・デプロイはClaude Codeに任せ、企画・設計・最終確認はオーナーが担当する。この分業が最も効果的だ。役割分担をCLAUDE.mdに明記しないと、AIが完了判定を独断で進めてしまう。デプロイの完了確認や外部サービスの審査結果確認はAIに判断できないため、必ずオーナーが確認する。

Pro→Max移行の現実と料金の仕組み

Proは個人開発でフル活用すると使用量の上限に達する。毎日使うならMax 5x（2026年4月時点で月$100・約16,000円）への移行を検討すべきだ。月の途中でアップグレードしても日割り差額のみの支払いになり、Proで使った分は差し引かれる。制限にぶつかったその日に移行して構わない。

ただしMaxに移行しても使用量の上限は存在する。リモートセッションで沼ると週の後半に上限が近づく。「Maxなら無制限」という誤解は危険で、使い方のコントロールは引き続き必要だ。Anthropic公式の料金ページで最新プランを確認してから判断しよう。

Max移行後にClaude Code上でOpusをどこまで使うかの判断は、モデル性能とレート上限のバランスで決まる。Opus 4.7リリース後のモデル使い分け基準はOpus 4.7とSonnet 4.6の使い分けで整理している。

よくある質問

まとめ

静的サイトの大量生成という別の使い方については、Claude Codeで3日・713ページのpSEOサイトを作った話にまとめています。

Claude Codeは個人開発の速度を変える。ただし使い方を間違えるとコスト爆死・暴走・沼化に陥る。この3点を最初から意識するかどうかで、最初の1ヶ月の体験がかなり違う。

ポイントは3つ。CLAUDE.mdとBUGS.mdを最初に整備する。API課金と定額プランの違いを把握する。確認はオーナーがやるという役割分担を明文化する。この3点を守ると、「優秀だが放置できないエンジニア」を活かし切れる。

2026.03.24 更新：Xの文字カウント仕様（Weighted Character Counting）の説明を修正、Makeの課金単位「クレジット」への名称変更を反映、FAQをCocoonブロック形式に変更

MakeでWordPressに記事を下書き投稿している人は多いと思います。しかし、X（旧Twitter）への投稿テキストとハッシュタグは別管理になっていませんか？

この記事では、SE歴20年・3サイトをMakeで運用している筆者が、WordPressのカスタムフィールドにX投稿用のテキスト（x_post_text）とハッシュタグ（x_hashtags）を持たせ、MakeのHTTPモジュールで記事投稿と同時に一括書き込みする仕組みを構築します。スプレッドシートにデータを入力すれば、記事本文もX投稿データもWordPressに一発で登録できるようになります。

コードはすべてコピペで実装可能です。WordPress側の準備は10分、Make側の修正は5分で完了します。まだMakeの初期設定が済んでいない方は、先にMake副業自動化入門の全手順でAPI Key取得まで完了させてください。

ムラサキ

3サイトすべてにこの仕組みを導入して1ヶ月運用しています。一度設定すれば記事投稿のたびにX投稿テキストも自動でWordPressに入るので、公開前の確認がとても楽になりました。

なぜカスタムフィールドでX投稿データを管理するのか

まず、なぜわざわざカスタムフィールドを使うのか。スプレッドシートで管理するだけではダメなのかを整理します。

スプレッドシート管理の限界

スプレッドシートにX投稿テキスト列とハッシュタグ列を設けておく方法は、記事の生成段階では合理的です。しかし、実際にXに投稿するタイミングでは問題が起きます。

MakeのWordPress Watch Postsトリガーは、WordPressの記事公開を検知して発火します。このとき取得できるのはWordPressの投稿データ（タイトル、本文、カテゴリ、カスタムフィールドなど）です。スプレッドシート上のX投稿データはWordPress側に存在しないため、Watch Postsトリガーからは直接参照できません。

スプレッドシートから読み取るには、別途Google Sheetsモジュールで「該当する記事のX投稿テキスト列・ハッシュタグ列を検索して取得する」シナリオを追加する必要があります。これはクレジット数が増え、シナリオも複雑になります。

カスタムフィールドなら記事と投稿データが1か所で完結する

WordPressのカスタムフィールド（post meta）にX投稿データを保存すれば、Watch Postsトリガーで記事データと一緒にX投稿テキストも取得できます。スプレッドシートを参照する追加モジュールは不要です。

さらに、WordPress管理画面の記事編集画面からもX投稿テキストを直接確認・修正できるため、公開前の最終チェックも容易になります。

全体像｜スプレッドシートからX投稿までのデータの流れ

実装に入る前に、データがどう流れるかの全体像を把握しておきましょう。

データフロー図

全体の流れは以下の5ステップです。

各ステップで何が起きるか

ステップ1：スプレッドシートにデータを入力。記事管理用のスプレッドシートに、記事データ（タイトル、本文、メタ情報など）に加えて、X投稿テキスト列（x_post_text用）とハッシュタグ列（x_hashtags用）にもデータを入力します。列の位置はスプレッドシートの構成に合わせて自由に設定してください。

ステップ2：Makeの記事投稿シナリオが実行される。HTTPモジュールでWordPress REST API（POST /wp-json/wp/v2/posts）にリクエストを送信します。このとき、リクエストボディのmetaフィールドにX投稿テキスト列・ハッシュタグ列の値を含めます。

ステップ3：WordPressに下書き記事が作成される。記事本文とともに、カスタムフィールド（x_post_text、x_hashtags）にX投稿データが保存されます。

ステップ4：手動で内容を確認し、記事を公開する。WordPress管理画面で記事内容とX投稿テキストを最終確認し、公開ボタンを押します。

ステップ5：X投稿シナリオが発火する。別のMakeシナリオ（WordPress Watch Posts → Buffer）がWordPressの公開を検知し、カスタムフィールドからX投稿テキストとハッシュタグを読み取り、Bufferを経由してXに投稿します。

この記事で扱うのはステップ1〜4までです。ステップ5のBuffer連携については前回の記事で解説しています。

▶ Make→X自動投稿の代替手段と Buffer連携の全体像はこちら
Make→X自動投稿の代替手段3選｜モジュール廃止後の実践ガイド

STEP1｜WordPress側の準備（functions.phpにカスタムフィールドを登録）

WordPressのREST APIでカスタムフィールドを読み書きするには、事前にそのフィールドを「REST APIに公開する」設定が必要です。register_post_meta関数を使います。

register_post_metaでREST APIに公開する

WordPressのREST APIは、デフォルトではカスタムフィールドを返しません。register_post_meta関数で明示的に「このフィールドはREST APIで読み書きできる」と宣言する必要があります。

ポイントは show_in_rest パラメータを true にすることです。これにより、REST APIのレスポンスにmetaフィールドが含まれるようになり、POSTリクエストでの書き込みも受け付けるようになります。

コピペ用コード全文

WordPressテーマのfunctions.php（子テーマを使用している場合は子テーマのfunctions.php）に以下のコードを追加してください。

add_action( 'rest_api_init', function() {	 
 register_post_meta( 'post', 'x_post_text', array(	 
 'type' => 'string',	 
 'single' => true,	 
 'show_in_rest' => true,	 
 'description' => 'X投稿用テキスト',	 
 ) );	 
 register_post_meta( 'post', 'x_hashtags', array(	 
 'type' => 'string',	 
 'single' => true,	 
 'show_in_rest' => true,	 
 'description' => 'X投稿用ハッシュタグ',	 
 ) );	 
} );

コードの内容を説明します。’post’ は通常の投稿タイプ（post）に対してフィールドを登録する指定です。固定ページにも登録したい場合は ‘page’ に対しても同様のコードを追加してください。’single’ => true は1つの投稿に対して1つの値を持つことを意味します。’type’ => ‘string’ はテキストデータであることを示します。

登録できたか確認する方法

コードを追加したら、ブラウザで以下のURLにアクセスして確認します。

https://あなたのドメイン/wp-json/wp/v2/posts/記事ID

レスポンスのJSONに “meta” オブジェクトが含まれ、その中に “x_post_text” と “x_hashtags” が表示されていれば成功です。まだ値を書き込んでいない段階では空文字（””）が表示されます。

STEP2｜スプレッドシートにX投稿データ列を追加する

次に、記事管理用スプレッドシートにX投稿データ用の列を追加します。列の位置はスプレッドシートの既存構成に合わせて決めてください。この記事では便宜上、X投稿テキスト列を「x_post_text列」、ハッシュタグ列を「x_hashtags列」と呼びます。

x_post_text列の設計ルール

x_post_text列にはX投稿のテキスト本文を入力します。設計ルールは以下の通りです。

x_post_text列テキスト ＋ x_hashtags列ハッシュタグ ＋ URL（23文字換算）＋ 改行・スペース（4文字）の合計が280文字以内に収まること。x_post_text列単体の目安は180文字前後です。

投稿テキストは3パート構造で書きます。1行目はフック（疑問形・あるある・意外性でスクロールを止める）。2〜3行目はベネフィット（記事を読むと何が得られるかを具体的に書く）。最終行はCTA（「↓」でURLへ誘導する一言）。絵文字は1〜2個まで。記事タイトルをそのまま使わないこと。MakeでURLを末尾に自動付与する前提のため、x_post_text列にURLは書きません。

x_hashtags列の設計ルール

x_hashtags列にはハッシュタグを入力します。3〜5個を半角スペース区切りで記述します。構成はメインキーワード系1〜2個、カテゴリ系1個、サイトブランドタグ1個です。

280文字チェックの考え方

Xの投稿上限は重み280です。XはWeighted Character Countingという仕組みを使っており、半角英数字・半角記号は重み1、日本語（CJK）・絵文字は重み2でカウントされます。URLはt.co短縮で常に重み23固定です。

つまり日本語だけで書いた場合、実質140文字が上限になります。投稿テキスト（x_post_text列）＋ハッシュタグ（x_hashtags列）＋URL（重み23）＋改行・スペース（重み4）の合計重みが280以内に収まる必要があります。

スプレッドシートで重みを正確に計算するには、LEN関数では不十分です。日本語の文字数にはLENB関数を使い、以下のような重み計算式を入れておくと便利です。

=LENB(A1) - LEN(A1) + LEN(A1) + 23 + 4

この式は「マルチバイト文字の数 × 2 ＋ シングルバイト文字の数」を概算します。厳密にはUTF-8のバイト数と重みは異なりますが、日本語中心のテキストであれば実用上十分な精度です。2026年3月時点の仕様に基づいています。

STEP3｜MakeのHTTPモジュールにmeta書き込みを追加する

ここが本記事の核心です。既存のMakeシナリオで、WordPress REST APIにPOSTリクエストを送信しているHTTPモジュールのBODYの、metaフィールドに項目を追加します。

MakeのHTTPモジュールの設定画面で、Body content typeが「JSON (application/json)」でBody input methodが「JSON string」になっている前提で説明します。

Body contentのJSONテンプレート内で、”meta” 内の値にスプレッドシートのx_post_text列・x_hashtags列の変数をマッピングします。Makeのマッピングパネルで、Google Sheetsモジュールから取得した値を選択し、”x_post_text” と “x_hashtags” にそれぞれ割り当てます。

テスト実行と確認

MakeのHTTPモジュールを修正したら、「Run once」でテスト実行します。テスト用のスプレッドシート行にダミーデータ（x_post_text列：「テスト投稿テキスト」、x_hashtags列：「#テスト #確認用」）を入力しておきましょう。

実行後、MakeのHTTPモジュールの出力でHTTPステータスコード201（Created）が返っていれば成功です。レスポンスボディのmetaオブジェクト内に x_post_text と x_hashtags の値が含まれていることを確認してください。

ムラサキ

筆者が最初にテスト実行したとき、JSONボディ内のmeta部分でカンマの位置を間違えて400エラーが出ました。MakeのHTTPモジュールの出力ログでリクエストボディ全文を確認すると原因が特定しやすいです。

STEP4｜投稿後にカスタムフィールドを確認する方法

テスト実行でWordPressに下書きが作成されたら、カスタムフィールドが正しく書き込まれているか確認しましょう。

WordPress管理画面での確認

WordPress管理画面で該当の下書き記事を開き、記事エディタ（ブロックエディタ）の右上にある縦三点メニュー → 設定 → パネル → 「カスタムフィールド」をオンにします。初回はページのリロードが必要です。

リロード後、記事エディタの下部にカスタムフィールドのセクションが表示されます。ここに x_post_text と x_hashtags が表示され、スプレッドシートから入力した値が入っていれば成功です。

この画面からX投稿テキストを直接編集することもできます。記事公開前の最終チェックで「このテキストでXに投稿して大丈夫か」を確認し、必要に応じてここで修正してから公開してください。

REST APIレスポンスでの確認

ブラウザで https://あなたのドメイン/wp-json/wp/v2/posts/記事ID にアクセスすると、JSONレスポンスの “meta” 内に値が入っていることも確認できます。MakeのWatch Postsトリガーが取得するデータも、これと同じ構造です。

よくある質問

まとめ

WordPressのカスタムフィールドにX投稿データを持たせることで、記事と投稿テキストを一元管理できるようになりました。

この仕組みにより、スプレッドシートにデータを入力 → Makeで下書き投稿 → 手動確認・公開 → 自動でXに投稿、という一連のワークフローが完成します。

ムラサキ

カスタムフィールドの設定は地味な作業ですが、一度やれば全記事で恩恵を受けられます。まずはテスト用のダミーデータで試してみてください。

Makeの基本操作やシナリオの組み方から知りたい方はMake副業自動化入門の全手順を、MakeのXモジュール廃止後にBuffer経由でX投稿を再開する方法は代替手段3選の実践ガイドを参照してください。

2026.03.20 更新：Makeの課金単位「オペレーション」→「クレジット」への名称変更を反映、料金比較表を2026年3月時点の情報に更新

副業でブログを書いている会社員が直面する問題があります。「記事を書く」以外の作業が多すぎることです。WordPress への投稿、X への告知、管理表の更新、アイキャッチ画像のリサイズ。1 記事あたり 15〜20 分かかるこの「地味な手作業」を、筆者は Make というノーコード自動化ツールでほぼゼロにしました。

本記事では、SE 歴 20 年・副業ブログ 運営の筆者が、Make の無料プランで実際に動かしている 2 つのシナリオを図解付きで公開します。最も需要が高い「スプレッドシート → WordPress 自動投稿」は、Step ごとにスクショ挿入箇所を設けたので、読みながらそのまま再現できます。

記事を書いた後の「作業」、毎回やっていませんか？

ブログ記事を 1 本公開するまでの流れを思い出してください。下書きを書く。WordPress にログインして本文を貼り付ける。アイキャッチ画像を設定する。カテゴリとタグを選ぶ。メタディスクリプションを入力する。公開ボタンを押す。そして X を開いてタイトルと URL を貼り付けて投稿する。さらに管理用のスプレッドシートや Notion に公開日とタイトルを記録する。

記事を書くこと以外の手作業が週末の可処分時間を圧迫していました。「記事を書くこと」に集中するために、それ以外の工程を自動化する必要がありました。そこで導入したのが Make です。

Makeとは？副業ブロガーが知るべき3つのポイント

ノーコードでアプリ同士をつなぐ「配線ツール」

Make（旧 Integromat）は、異なるWebサービスをノーコードで連携させる自動化プラットフォームです。WordPress、X、Googleスプレッドシート、Notionなど 3,000 以上のアプリに対応しています。画面上でモジュールと呼ばれるパーツを線でつなぐだけでワークフローが完成します。

同種のツールに Zapier がありますが、Make は分岐やループを視覚的に組める点が強みです。副業で使う程度の複雑さなら、どちらでも問題ありません。ただし無料プランの太っ腹さでは Make に軍配が上がります。

無料プランでできること・できないこと

2026年3月時点の情報です。2025年8月にMakeは課金単位の名称を「オペレーション」から「クレジット」に変更しました。非AIアプリでは1 operation = 1 creditの1:1換算で料金は変わりませんが、AIアプリ（Make AI Agents等）を使う場合はトークン消費に応じてクレジットが動的に変動します。最新の料金はMake公式料金ページで確認してください。

Make の料金プランは公式サイトで確認できます。

※ 2026年3月時点の価格です。最新情報はMake公式料金ページで確認してください。

副業ブロガーに向いている理由

副業ブロガーが日常的に使うツールは WordPress・X・Googleスプレッドシート・Notion の 4 つに集約されます。Make はこの 4 つすべてに公式モジュールを用意しています。つまり、副業ブロガーのツールスタックにそのままはまる自動化基盤です。

【実例公開】筆者が実際に動かしている2つのシナリオ

ここからは筆者が 実際に使っている Make シナリオを公開します。すべて無料プラン内で運用できています。

シナリオ1｜スプレッドシート → WordPress自動投稿

ポイントは、スプレッドシートに「x_post_text」と「x_hashtags」の列を設けておくことです。この 2 つは後述のシナリオ 2 で X 投稿に使うデータです。記事を書く段階で SNS 投稿文まで一緒に用意しておくことで、公開からSNS告知までの一連の流れが全自動になります。

シナリオ2｜WordPress公開 → Buffer経由でX自動投稿

以前は Make の X モジュールで直接投稿可能でしたが、2025 年 5 月に X モジュールが廃止されました。現在は Make → Buffer → X という構成に切り替えて運用しています。Buffer は SNS 投稿管理ツールで、無料プランでも X への投稿が可能です。Make には Buffer モジュールが標準で用意されているため、追加費用なしで連携できます。

カスタムフィールド（x_post_text / x_hashtags）を導入し、「フック → ベネフィット → CTA」の3パート構成でX投稿テキストを管理する仕組みに移行済みです。スプレッドシートにX投稿テキストを入力すれば、記事投稿と同時にWordPressのカスタムフィールドに書き込まれ、公開時にWatch Postsトリガーで自動取得されます。実装手順はWordPressカスタムフィールドでX投稿テキストを管理する手順で解説しています。

Make の X モジュール廃止の経緯、Buffer 連携の詳細手順、HTTP モジュールで X API を直接叩く方法など、X 自動投稿の代替手段については代替手段3選の実践ガイドで詳しく解説しています。

PC側の自動化に興味がある方はSE歴20年が実務で使っている業務自動化テクニックも参考になります。

【図解】シナリオの作り方を完全ステップ解説

ここからは「WordPress 公開 → Buffer 経由で X 自動投稿」の構築手順を解説します。シナリオ 1（スプレッドシート → WordPress）の構築は WordPress モジュールの設定までは同じ手順のため、まずはこの Step を完了させてください。

Step 1｜Makeアカウント作成とWordPress接続

Make の公式サイト（[make.com](http://make.com/)）で Google アカウントまたはメールアドレスでサインアップします。ダッシュボードが表示されたら「Create a new scenario」をクリックし、最初のモジュールとして「WordPress」を検索して追加します。

WordPress との接続には Make Connector プラグインの API Key を使います。まず WordPress 管理画面の「プラグイン」→「新規追加」で「Make Connector」を検索してインストール・有効化します。有効化すると左メニューに「Make」が追加されるので、クリックして表示される API Key をコピーしてください。

Make に戻り、WordPress モジュールの「Create a connection」画面で以下を入力します。

URL の末尾は「/wp-json」です。「/wp-json/」のようにスラッシュを付けても動作しますが、統一しておくとトラブルが減ります。入力したら「Save」をクリックしてください。

Step 2｜Buffer接続とXへの投稿設定

2025 年 5 月に Make の X モジュールが廃止されたため、X への投稿には Buffer を経由します。Buffer は SNS 投稿管理ツールで、無料プランでも利用可能です。X Developer Portal での API キー取得は不要です。

まだ Buffer アカウントを持っていない場合は buffer.com で無料登録し、設定画面から X アカウントを接続しておいてください。

Make のシナリオ画面に戻り、WordPress モジュールの右の「＋」をクリックします。検索窓に「Buffer」と入力し、「Create a Status Update」アクションを選択します。「Create a connection」をクリックすると OAuth 認証のポップアップが表示されるので、Buffer アカウントでログインして許可してください。

接続が完了したら、Profile（投稿先）で X アカウントを選択します。Text フィールドには WordPress モジュールから取得できる変数を直接組み合わせて投稿文を組み立てます。たとえば「記事タイトル＋改行＋記事 URL」のように設定します。今後カスタムフィールド（x_post_text / x_hashtags）を導入すれば、より訴求力のある投稿文に切り替えることも可能です。

Step 3｜テスト実行と本番稼働

画面左下の「Run once」をクリックしてテスト実行します。WordPress で記事を 1 本公開し、X に投稿が作成されることを確認してください。

成功したらシナリオのスケジュールを ON にします。無料プランでは 15 分間隔が最短です。副業ブログの公開頻度なら十分です。エラー発生時にメール通知が届くよう、シナリオ設定の「Notifications」も有効にしておきましょう。

無料プランで運用するコツと注意点

Make の無料プランは副業ブログ運営に十分な容量がありますが、いくつか気をつける点があります。

筆者の運用では、シナリオ 1（スプレッドシート → WP）とシナリオ 2（WP → Buffer → X）の 2 つを使い分けています。Make の無料プランではアクティブシナリオが 2 つまでのため、ちょうど枠内に収まります。シナリオ 2 は記事公開時だけ ON にし、投稿確認後に OFF にする半手動運用で、クレジットの消費を抑えています。

クレジット消費の目安は、シナリオ 1 本の実行で 2〜3 クレジットです。月 30 記事 × 2 シナリオでも約 180 クレジット。無料枠の 1,000 に対して余裕で収まります。

スプレッドシートの操作自体を効率化したい場合はExcel業務効率化15選にまとめたテクニックが役立ちます。

よくある質問（FAQ）

Claude Codeのヘッドレスモードやフック機能を活用すれば、Makeとの連携もさらに柔軟になる。詳しくはClaude Code /powerup入門を参照。

まとめ｜「記事を書く以外」は全部自動化していい

本記事で紹介した 2 つのシナリオを導入した結果、1 記事あたりの「記事を書く以外の作業時間」は約 15 分から 1 分以下になりました。月 30 記事換算で約 7 時間の節約です。浮いた時間は記事の質を高めるリサーチに充てており、この仕組みで実際に1ヶ月運営した結果は副業ブログ1ヶ月目の実績レポートで全数字を公開しています。

副業ブログの本質は「読者に価値ある記事を届けること」です。WordPress への投稿作業、X への告知、管理表の更新は、記事の価値を生み出す工程ではありません。だから自動化していいのです。

Make の無料プランなら費用もゼロです。まずはシナリオ 1（スプレッドシート → WordPress 自動投稿）だけでも試してみてください。手元のスプレッドシートに 1 行書くだけで WordPress に下書きが生まれる体験は、自動化の第一歩として最適です。X自動投稿のモジュール廃止後の代替手段はMake→X自動投稿の代替手段3選で詳しく解説しています。また、Make以外にもPC操作レベルで「面倒」を潰すテクニックをSE歴20年の業務自動化術にまとめています。GASを使えばGmailの情報をNotebookLMに自動集約することもでき、手順はGAS×NotebookLMメール集約の実装手順で解説しています。