WordPress×Makeカスタムフィールド一括登録｜X投稿を自動化する実装手順

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取得まで完了させてください。

なぜカスタムフィールドで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 の値が含まれていることを確認してください。

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選の実践ガイドを参照してください。