結論だけ先に。MakeとWordPressの連携で必要なのは「アプリケーションパスワードの発行」と「REST APIの開放」の2つだけです。この2つさえ通れば、記事の自動下書きまで一直線。逆に、つまずく人の9割はこの2つのどちらかで止まっています。
私はこのブログの記事生成をMake.comで組んで運用していました。キーワードを渡すとAIが記事を書き、WordPressに下書きが届いている——その仕組みの、WordPress側の接続部分を4ステップで解説します。
そもそも何ができるのか
MakeのWordPressモジュールでは、投稿の作成・更新・取得、カテゴリやタグの操作などが自動化できます。よく使われる形は3方向。
- 外→WordPress(投稿系):AIが生成した記事を下書き投稿する。スプレッドシートの原稿を記事化する
- WordPress→外(告知系):記事を公開したら、XやLINEに自動で告知を流す
- メンテ系:古い記事の一覧を取得してリライト候補をリスト化する
この記事では、一番需要のある「AI記事→自動下書き」を軸に進めます。全体の設計思想(なぜ公開まで自動化しないか等)は別記事「ブログ自動化のやり方」で書いたので、ここでは接続の実務に集中します。
ステップ1:WordPressでアプリケーションパスワードを発行する
MakeがWordPressに投稿するには、専用の鍵が要ります。それがアプリケーションパスワード。普段のログインパスワードとは別に発行する、外部ツール専用の合鍵です。
店舗(WordPress)の正面玄関の鍵は渡さず、搬入口の合鍵だけ渡す——そんなイメージで捉えてください。万一漏れてもその合鍵だけ無効化すればよく、本体のパスワードは無事。この仕組みがあるおかげで、外部連携が安全にできます。
発行手順:
- WordPress管理画面 → ユーザー → プロフィール を開く
- 下のほうにある「アプリケーションパスワード」欄で、名前(「Make」など)を入力して「新しいアプリケーションパスワードを追加」
- 表示された英数字の列をコピーして控える(この画面を閉じると二度と表示されません)
パスワードはスペース区切りで表示されますが、スペースは含めても除いても動くのが一般的です。私は除いた形で登録していました。
ステップ2:サーバー側のREST API制限を確認する(最重要)
白状すると、私が連携で一番時間を溶かしたのはMakeの設定ではなくここでした。
WordPressの外部連携はREST APIという窓口を通ります。ところが、日本の主要レンタルサーバーの一部は、セキュリティ対策としてこの窓口を初期状態で制限しています。私が使っているエックスサーバーがまさにそれで、Make側の設定は完璧なのに401エラー(認証拒否)が返り続ける。原因がサーバー側だと気づくまで、設定画面を何往復もしました。
エックスサーバーの場合:サーバーパネル → WordPressセキュリティ設定 → 対象ドメインを選択 → 「REST APIアクセス制限」をOFFにする。これだけです。他のサーバーでも同様のセキュリティ設定がある場合があるので、「サーバー名+REST API 制限」で調べてみてください。
Makeの設定をいくら見直しても401が消えないときは、サーバー側を疑う。この順番を知っているだけで、数時間の遠回りが消えます。
ステップ3:MakeでWordPressの接続を作る
ここまで来れば、あとは流れ作業です。
- Makeのシナリオ画面でWordPressモジュール(Create a Post)を追加
- Connection欄で「Add」を押す
- 接続情報を入力:サイトのURL(https://から)、WordPressのユーザー名、そしてステップ1で控えたアプリケーションパスワード
- 保存して、エラーが出なければ接続成功
ここで通らない場合の原因は、だいたい次の3つ。①URLの末尾やhttpsの書き間違い、②パスワードのコピーミス、③ステップ2のREST API制限が残っている。順に潰せば通ります。
ステップ4:シナリオを組む(AI記事→下書き投稿)
私が運用していた構成を簡略化すると、こうなります。
- Google Sheetsモジュール:キーワードリストからpendingの行を1件取得
- AIモジュール(ClaudeやChatGPT):キーワードを渡して記事本文をHTMLで生成
- WordPressモジュール(Create a Post):タイトルと本文をマッピングし、StatusをDraft(下書き)に設定
- Google Sheetsモジュール:処理済みの行をdoneに更新
肝はStatusの設定です。初期値のままだと即公開になる設定もあり得るので、必ずDraftを明示する。AIの原稿は料金の古さや事実誤りが混ざるため、公開前の人間チェックを挟む前提で組むのが安全です。実際、私の運用でも「下書きで受けて、朝5〜10分チェックして公開」が定着していました。
マッピングの注意点
- 本文はHTMLで渡す:AIへの指示で「HTMLタグで出力」と指定しておくと、WordPressのコードエディタにそのまま入る形になります。Markdownで渡すと記号がそのまま表示されて崩れます
- カテゴリはID指定:カテゴリ欄は名前ではなくID番号で指定する仕様が一般的です。管理画面のカテゴリ一覧でIDを確認しておきます
- アイキャッチは手動が現実的:画像のアップロードと紐付けまで自動化もできますが、手数のわりに品質が安定しません。意外とここは手動のほうが速い、というのが運用した実感です
つまずきやすいポイントまとめ
- 401エラー:サーバーのREST API制限(ステップ2)か、パスワードの入力ミス
- 記事が途中で切れる:AIモジュールの最大トークン設定が小さい。8000程度まで上げる
- 本文が崩れる:AIの出力形式がHTMLになっていない
- 勝手に公開された:StatusのDraft指定漏れ
- クレジットの消費が想定より速い:シナリオのテスト実行も本番同様に消費します。テスト時は処理を1件に絞る
他の選択肢との違い(軽く)
WordPressの自動投稿には、WordPress内のプラグインで完結させる道もあります。予約投稿や定型の自動化ならプラグインで十分。ただし「スプレッドシートやAI、外部サービスとまたいで流れを組む」ならMakeの領域です。ZapierでもWordPress連携は組めますが、タスク課金なので毎日回す用途では割高になりがち——このあたりの料金構造は別記事(n8n vs Zapier)で書いたとおりです。
よくある質問
無料プランのMakeでも運用できますか?
できます。私の構成(4モジュール前後を1日1回)で月の消費は150〜300クレジット程度。無料枠の月1,000で十分収まっていました。15分おきの監視のような組み方をしなければ、無料圏内です。
公開まで全自動にはできないのですか?
技術的にはStatusをPublishにするだけで可能です。ただ、AI原稿の事実確認なしでの公開はおすすめしません。下書き+5分チェックの折衷が、品質と時短の一番いいバランスだと運用して感じました。
ローカル環境やBasic認証付きのサイトでも接続できますか?
Makeはインターネット経由でアクセスするため、外部から見えないローカル環境には接続できません。Basic認証がかかっているサイトも追加設定が必要になります。公開済みの本番サイトでの利用が基本です。
セキュリティが心配です。危なくないですか?
アプリケーションパスワードは権限が絞られた専用の鍵で、不要になれば個別に削除できます。運用のコツは2つ。Make専用のパスワードとして発行すること(使い回さない)、そして連携をやめるときは必ずWordPress側で削除すること。この2点を守れば、一般的なブログ運用のリスク水準に収まります。
まとめ:最初の1本は「下書きが届く」だけで成功
接続の成否は、派手な自動化ができたかではなく、WordPressの下書き一覧にMake経由の記事が1本現れたかどうかで判定してください。それが見えたら、配管は通っています。あとはAIへの指示を磨くだけで、仕組みは勝手に育ちます。
私の場合、初めて下書きが自動で届いた朝のことは今でも覚えています。ブログ運営が「書く作業」から「仕上げる作業」に変わった瞬間でした。合鍵の発行から始めて、まず1本、届かせてみてください。
※本リンクはアフィリエイトリンクです。 Make.com(※アフィリエイトリンクです)


コメント