DifyとWordPressを連携して自動投稿する方法｜非エンジニアの実装ログ

本文にダブルクォートや改行が含まれる場合、JSON文字列として正しくエスケープされていないとGASで SyntaxError になります。対処法は、HTTPノードの直前にCodeノードを挟んでエスケープ処理を行うことです。

function main({ title, content }) {
  return {
    title_safe:   JSON.stringify(title   || "").slice(1, -1),
    content_safe: JSON.stringify(content || "").slice(1, -1)
  };
}

このCodeノードの出力変数 title_safe と content_safe をHTTPノードのbodyに使います。

STEP5：テスト実行で確認する

設定が完了したらDifyのワークフローを1回実行して、WordPressの管理画面に下書き記事が追加されることを確認します。

確認すべきポイントは4つです。

• WordPressに下書き記事が追加されているか
• タイトルと本文が文字化けしていないか
• 本文の改行が正しく反映されているか
• ステータスが 下書き になっているか

最初のテストは必ず1記事だけにしてください。問題があっても1記事なら修正が簡単ですが、30記事を一気に実行すると修正コストが大きくなります。

実際に詰まったポイント

3つの詰まりポイントはいずれも「知っていれば防げた」タイプです。同じ状況になったときの参考にしてください。

403エラー：DifyのIPがブロックされていた

最初のテストで即座に403エラーが出ました。エラーログを確認すると 403 Forbidden という内容でした。

原因はエックスサーバーが海外IPからのアクセスを制限していたことです。DifyのサーバーはIPが海外に分類されるため、直接WordPressのREST APIを叩くとブロックされます。

解決策がGAS中継です。Googleのサーバーはエックスサーバーにブロックされないため、DifyからGASにPOSTして、GASがWordPressに代理でリクエストを送る構造にしました。詳細な設定手順とGASのコード全体は[DifyとWordPressを自動連携した実装ログ](https://bizinets.life/dify-wordpress-gas-403-log)にまとめています。

JSONエラー：本文のエスケープ不足

GAS側でリクエストを受け取ったときに SyntaxError: Unexpected token が発生しました。

原因はLLMが生成した記事本文にダブルクォートと改行が含まれており、JSON文字列として不正な状態になっていたことです。LLMは指示に忠実ですが、生成物を「JSONに入れる」意識はありません。

解決策はSTEP4で説明したCodeノードによるエスケープ処理です。JSON.stringify() で一度文字列化してから前後の " を除去する方法が一番確実でした。

文字化け・改行問題：Gutenberg形式への対応

WordPressに記事が保存されたものの、本文が改行されず1行の長い文章になっていました。

原因はWordPressのブロックエディタ（Gutenberg）が専用のコメント構文を使う仕様だったことです。通常のHTMLタグだけでは正しく表示されません。

<!-- wp:paragraph --><p>テキスト</p><!-- /wp:paragraph -->
<!-- wp:heading {"level":2} --><h2>見出し</h2><!-- /wp:heading -->

解決策はLLMノードのプロンプトに「Gutenberg形式のブロック構文で出力してください」と指示することです。サンプルのフォーマットをプロンプトに含めると出力が安定します。

改善ポイント（実運用）

動くようになったあと、運用を通じて改善したことが2つあります。

完全自動にしなかった理由

最初は「生成 → 即公開」の完全自動化を目指していました。しかし実際に動かしてみると、LLMの出力品質にムラがあることが分かりました。

3記事に1回程度、見出し構造が崩れていたり、文体が途中で変わったりする記事が混じります。自動公開にしていたら、品質の低い記事がそのまま公開されていたことになります。

下書きで止めることで「確認 → 微調整 → 公開」の3ステップを維持できています。AIが作った下書きを人間が確認してから公開する、この設計が今の品質担保の仕組みです。

下書き運用のメリット

下書き運用には品質担保以外のメリットもあります。

内部リンクの追加やSEOメタ情報の確認は、公開前に人間が行う方が精度が高いです。また、Difyで生成した本文に対して「この部分は事実と違う」「このデータは古い」という確認が必要なケースも出てきます。AIが苦手な部分を人間が補う役割分担として、下書き運用はちょうど良いバランスだと感じています。

この構成を応用するとできること

DifyとWordPressの連携が動くと、応用の幅が広がります。実際に検討・実装したものを紹介します。

記事の量産については、Difyのイテレーション機能を使えばキーワードリストから複数記事を一括生成できます。ただし量産した場合でも下書き確認は省かない運用にしています。

SNS連携については、WordPressに投稿完了したタイミングでGAS経由でX（旧Twitter）への投稿文も生成・保存する仕組みを追加できます。

データ管理については、GASとGoogleスプレッドシートを組み合わせることで、生成した記事のキーワード・投稿日・ステータスを一元管理できます。重複コンテンツの防止にもなります。

まとめ

DifyとWordPressの自動投稿連携は、非エンジニアでも構築できます。ただし「Difyから直接POST」ではなく、GAS中継が必要になる環境（エックスサーバー等）があることを知っておくと詰まりが少なくなります。

今日できる一歩は「WordPressのApplication Passwordを発行して、REST APIにcurlでリクエストを送ってみること」です。これが通れば連携の土台ができたことになります。

重要なのは完成度より「まず動かすこと」です。最初は下書き投稿だけに絞り、動いてから機能を足す順番で進めることをおすすめします。

AIを使った仕組みを「作る」だけでなく、「どう設計して成果につなげるか」については、bizinets.biz の[サイト設計思想](https://bizinets.biz/site-design-philosophy/)で体系的に解説しています。