DifyでSEO記事作成を自動化｜WordPressへの下書き投稿まで解説

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO CREATREE合同会社の代表社員。生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。

著者

藤村 隼人

CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。

DifyのWorkflowでLLM・画像生成・Code・HTTP Requestノードを組み、WordPress REST APIへ「status=draft（下書き）」でPOSTすれば、本文からアイキャッチ画像までを自動生成し、公開判断だけを人が担う運用がつくれます。本記事では自動化範囲の線引き、WordPress側の認証準備、ノードの設計順序、投稿失敗や誤公開の典型パターン、公開前チェックの体制設計までを実務手順として整理します。

結論：ゴールは「全自動公開」ではなく「下書きまでの完全自動化」

Dify×WordPressの自動化で狙うべき到達点は、キーワード入力から本文生成、アイキャッチ生成、下書き投稿までを機械が完了させ、ファクトチェックと公開操作だけを人が担う状態です。生成AIには事実に見える誤り（ハルシネーション）を出力する性質があり、もっともらしい表現に紛れるため人が見抜きにくいとされています。そのため、公開の直前に人の判断点を1つ残す設計が現実的な落としどころになります。

公開されているDifyのSEO記事生成ワークフロー例でも、生成結果はWordPressに新規の下書き投稿として作成し、最終レビューに回す構成が取られています。「下書きで止める」は特殊な抑制策ではなく、実装として一般的な形だと捉えて差し支えありません。

着手前に決めておく判断基準

自動化範囲と人の担当範囲を先に文書化する

1. 目的を「工数削減」か「記事量産」かで明示する。どちらでも公開判断は人に残す前提を先に固定する。
2. 機械の担当範囲（構成生成・本文生成・画像生成・下書き投稿）と人の担当範囲（事実確認・出典確認・公開操作）を1枚の文書に書き出す。
3. チェック担当者と確認手順を決める。担当者が確保できない場合は自動化範囲を構成案生成までに縮小する。
4. その後にDify Workflowの構築へ着手する。

失敗する典型は2つです。公開判断まで自動化して未確認の数値や存在しない出典が公開されるケースと、チェック担当者を決めずに構築を始めて下書きが放置されるケースです。医療・金融など専門性や法規制の影響が大きい領域では、自動化範囲を構成案生成までに絞る判断も取り得ます。個別の法令要件の判断は本記事の範囲外であり、該当領域では専門家の確認を前提としてください。

ChatGPT単体ではなくDifyのWorkflowを使う理由

ChatGPTは単発の対話と探索に強く、Difyは再現性・構造化・チーム運用に強い設計です。SEO記事を継続的に出す運用では、テンプレート化、変数化、条件分岐、外部APIへの書き込みが必要になるため、仕組み化のフェーズではDifyが適します。逆にプロンプトが固まっていない探索段階でWorkflowを組むと手戻りが大きくなります。

観点	ChatGPT単体	Dify Workflow
出力の再現性	毎回の手動指示に依存する	テンプレートと変数で安定させやすい
条件分岐	対応しにくい	分岐ノードで設計できる
モデルの使い分け	基本的に固定	用途ごとにモデルを指定できる
外部システムへの書き込み	単体では想定しない	HTTP Requestノードで実行できる
他メンバーへの配布	個人の使い方に依存	入力欄と選択肢を用意して渡せる

どちらを選ぶかの判断基準

• 同じ処理を月に何本繰り返すか。単発・不定形ならChatGPT、定型を反復するならDify。
• 自分以外の人に触らせるか。触らせるなら、入力欄と選択肢を用意して渡せるDifyが向く。
• 外部システムへ書き込む必要があるか。WordPressへの投稿まで含めるならDifyのHTTP Requestノードが必要になる。

移行タイミングの見極め

プロンプトの型が2〜3本の記事で安定してからWorkflow化するのが、手戻りを抑える順序です。月に数本かつ入稿も自分1人で完結する規模であれば、ChatGPT＋手動入稿のほうが総工数が小さい場合もあります。「Difyを使うこと」自体が目的化し、対話で足りる作業まで作り込んで運用負荷が増えるのは避けたい失敗です。

Difyを選ぶ実務的な理由

• 用途ごとにLLMモデルを切り替えられ、構成生成と本文生成で使い分けられる。
• 変数と条件分岐によって、出力形式を毎回指示し直さずに安定させられる。
• HTTP Requestノードで外部システムへ書き込めるため、生成から入稿までを1本の流れにできる。

WordPress側の準備｜アプリケーションパスワードと権限設計

DifyからWordPressへ投稿するには、管理画面のログインパスワードではなく「アプリケーションパスワード」を発行し、HTTP Basic認証の形式でREST APIへ渡します。この機能はWordPress 5.6以降で利用でき、発行にはHTTPSが必要です。権限は投稿作成に必要な範囲に絞り、用途ごとにパスワードを分けます。

アプリケーションパスワードは通常のログインパスワードとは別物で、管理画面へのログインには使えません。アプリケーション単位で発行でき、不要になれば個別に破棄できるため、漏洩時の影響範囲を局所化できる点が運用上の利点です。

準備段階で確認する判断基準

• 自サイトが自前設置版（WordPress.org）かWordPress.comか。手順と前提条件が分岐する。
• サイトがHTTPS化されているか。未対応の場合は発行画面自体が利用できない。
• 自動投稿専用ユーザーを作るか、既存ユーザーに紐づけるか。運用者が複数いるなら専用ユーザーを用意する。

発行手順（自前設置のWordPressの場合）

1. 管理画面にログインし、「ユーザー」から対象ユーザーの編集画面（またはプロフィール）を開く。
2. 画面下部の「アプリケーションパスワード」欄に、用途がわかる名称（例：Dify記事自動投稿）を入力する。
3. 「新しいアプリケーションパスワードを追加」をクリックする。
4. 表示されたパスワードを控える。再表示されない前提で管理し、Dify側のシークレット設定に格納する。

権限とセキュリティの考え方

• 運用者が複数いる場合は自動投稿専用ユーザーを作り、記事作成に必要な権限に絞る。
• 用途別にパスワードを分け、問題発生時は該当パスワードのみ破棄して復旧できる状態にする。
• パスワードを平文でプロンプト本文やノードのメモ欄に書かない。

つまずきやすい失敗条件は、HTTPS未対応で発行できない、対象ユーザーに投稿権限がなく401・403系で止まる、通常のログインパスワードをAPIに使ってしまう、レンタルサーバー側で国外からのREST APIアクセスが制限されており外部サービスからの投稿が拒否される、の4点です。とくに最後の点は認証設定自体が正しくても失敗するため、サーバー側の制限有無を先に確認しておくと切り分けが速くなります。

Dify Workflowのノード構成｜本文生成からアイキャッチ紐付けまで

基本形は「START（キーワード入力）→ LLM（構成）→ LLM（本文）→ 画像生成 → Code（整形とボディ組立）→ HTTP Request①（画像アップロード）→ HTTP Request②（記事作成 status=draft）→ HTTP Request③（アイキャッチ紐付け）→ END」です。最大のつまずきは、アイキャッチの設定が記事作成とは別リクエストになる点にあります。JSONレスポンスからの値の抽出は、LLMのプロンプト任せにせずCodeノードで行うほうが安定します。

設計時に押さえる判断基準

LLMノード：構成生成と本文生成を分ける

1つのプロンプトで構成と本文を同時に出すと、文字数不足や見出しレベルの崩れが起きやすくなります。まず構成を確定させ、次に見出し単位で本文を生成する二段構えにします。プロンプトには命令・文脈・入力・出力の4要素を入れ、とくに出力条件（見出しレベル、文字数目安、禁止表現、出典の扱い）を明示します。曖昧な指示や誘導的な指示は、誤情報が混入する要因として整理されています。

画像生成ノード：記事内容からアイキャッチを作る

タイトルと本文からキーワードを抽出し、画像生成用の指示文を作ってから画像生成ノードへ渡すと、記事と無関係な画像が出る確率を下げられます。実装例でも「テキスト解析・キーワード抽出 → 指示文作成 → 画像生成」という3ステップ構成が用いられています。画像内に日本語テキストを入れたい場合はモデルの描画精度が結果を左右しますが、雰囲気画像で足りる用途ならモデル選定の影響は小さくなります。

Codeノード：本文整形とリクエストボディの組み立て

• 見出し構造のHTML化と、余分な記号・前置き文の除去。
• title、content、status、カテゴリなどをまとめたJSONの生成。
• 前段のレスポンスから必要なID等を確実に取り出す処理。

HTTP Requestのボディへ変数を直接流し込むより、Codeノードで整形してから渡すほうがエラーの切り分けが容易です。

HTTP Requestノード：3つのリクエストに分ける

1. メディアアップロード：生成した画像ファイルをPOSTで送信し、返却されたメディアIDを取得する。
2. 記事作成：title・content・status=draft・カテゴリ等をPOSTし、作成された投稿のIDを取得する。
3. アイキャッチ紐付け：作成した投稿に対し、取得済みのメディアIDをアイキャッチとして設定する更新リクエスト（部分更新はPATCH）を送る。

HTTP RequestノードはPOSTでの新規作成、PATCHでの部分更新、認証設定、ファイルのアップロードとダウンロードに対応しています。レスポンスのバイナリはファイル変数として扱われ、JSONやHTMLなどのテキストは通常のデータとして扱われます。初期設定では、cURLコマンドをインポートする機能を使うと手戻りを減らせます。

【編集部の見解】status=draft は変更禁止の固定値として扱う

編集部の見解として、ステータスは変数化せず固定値で持たせ、上流のLLM出力のゆれがステータス値に影響する余地を残さない設計にします。これは公式仕様上の制約ではなく、誤公開を防ぐための設計方針です。

この工程で起きやすい失敗は、ステータス指定を誤って公開状態で投稿される（最大の事故）、画像アップロードは成功したがメディアIDを次のリクエストへ渡せずアイキャッチが未設定になる、変数の受け渡し設定ミスでタイトルや本文が欠落した下書きが量産される、JSONのパースをLLM任せにして値が空になる、の4点です。画像を使わない運用なら画像生成とアップロードの2リクエストは省略できます。カテゴリやタグも記事作成のボディに含めて自動設定できますが、分類設計が固まっていない段階では手動設定に留めるほうが後戻りが少なくなります。

公開前チェック体制の設計｜誰が・何を・どの順で確認するか

下書きが生成された時点の記事は未完成として扱います。事実確認、出典確認、表現確認を人が通過させて初めて公開します。確認手法と確認責任者を事前に決めておくこと、そしてチェック項目を属人記憶ではなくリスト化することが、体制として機能させる条件です。可能であれば、生成プロンプトを書いた本人以外が確認者になる形が望ましい状態です。

レビューの進め方

1. 下書きの投稿ステータスとアイキャッチの設定状態を確認する。
2. 数値・統計・制度・固有名詞を一次発行元に当たって確認し、確認日を記録する。
3. 曖昧表現と根拠不在の記述を洗い出し、裏づけが取れないものは削除する。
4. タイトル・見出し構造・文字数が指示どおりかを確認する。
5. 差し戻すか公開するかを判断し、公開は人の操作で行う。

公開前チェックリスト

差し戻す判断基準

• 統計・法制度・固有名詞・引用のうち、一次発行元に当たれないものが残っている。
• 曖昧表現が複数箇所に残り、根拠を追跡できない。
• アイキャッチが記事内容と無関係、または投稿に紐付いていない。

公開されている対策の整理では、生成結果をそのまま使用しない方針の周知、確認手法と確認者の事前決定、出力への人的フィルター、規定やマニュアルの整備が挙げられています。加えて、別担当者による再確認や、生成に使ったAIとは別ツールでの比較検証といったダブルチェックも有効な手段とされています。運用が回り始めたら、発生した誤りの事例を記録し、プロンプトとチェックリストに反映する更新サイクルを持たせてください。

注意点：統計・法制度・固有名詞・引用は必ず一次発行元に当たり、当たれないものは記事から落とす運用にします。「もっともらしいが確認できない情報」を残したまま公開すると、自動化による工数削減分を、後の訂正対応で失うことになりかねません。

まとめ

Dify×WordPressのSEO記事自動化は、生成から下書き投稿までを機械に任せ、事実確認と公開操作を人に残す設計で運用が安定します。技術的な難所はアイキャッチの紐付けが別リクエストになる点と、認証・権限まわりの前提条件です。着手順序を守れば、構築時の手戻りは大きく減らせます。

1. 自動化範囲と人の担当範囲を文書化し、公開判断者を決める。
2. WordPress側でアプリケーションパスワードを発行し、権限とHTTPS、サーバーのAPI制限を確認する。
3. Dify Workflowを構成生成・本文生成・画像生成・整形・3本のHTTP Requestに分けて組み、ノード単体でテストする。
4. status=draft を固定値にしたうえでテスト投稿し、下書きとアイキャッチの状態を目視確認する。
5. 公開前チェックリストを運用に載せ、発生した誤りをプロンプトとリストへ反映する。

下書きまでの自動化は仕組みで解決できますが、公開判断とファクトチェックの体制設計は各社の運用体制に依存します。自社サイトに合わせたワークフロー設計、WordPress連携、公開前チェック体制の整備については、CREATREEへご相談ください。

関連記事

• 完全自動化を急ぐほど、AI導入はなぜ失敗しやすいのか：下書き後に人の確認を残す理由を整理します。
• AI格差を生むのは、モデル性能ではなく業務設計力である：ツール導入前に必要な業務設計を考えます。
• AIエージェント時代のサイト設計は「ページ」から「意図」へ変わる：AIがWebを扱う際の情報設計を深掘りします。

よくある質問

なぜ自動公開ではなく下書き保存で止めるべきなのですか

生成AIは事実に見える誤情報を出力する性質があり、実在しない統計や商品名が資料に混入した事例が報告されています。公開まで自動化すると、その誤りが読者に届いたあとで訂正する形になり、信用の回復に要する労力が自動化の削減効果を上回る可能性があります。公開されているDifyのSEO記事ワークフロー例でも、生成結果は下書きとして作成し最終レビューに回す構成が採られています。

アプリケーションパスワードはどう発行し、どの権限が必要ですか

WordPress 5.6以降であれば、管理画面の「ユーザー」から対象ユーザーの編集画面を開き、アプリケーションパスワード欄に用途名を入力して追加します。発行にはHTTPSが必要です。権限は記事作成に必要な範囲に絞り、運用者が複数いる場合は自動投稿専用ユーザーを用意します。WordPress.comでは2段階認証の設定が前提となるなど手順が異なるため、着手時点の管理画面で確認してください。

生成画像をアイキャッチに設定するには、どのノードをどの順で組みますか

画像生成ノードで作成した画像を、HTTP Requestノードでメディアとしてアップロードし、返却されたメディアIDを取得します。次に記事作成のリクエストを送り、作成された投稿IDを受け取ります。最後に、その投稿へメディアIDをアイキャッチとして設定する更新リクエストを送ります。IDの受け渡しはCodeノードで抽出すると安定します。

投稿がエラーになる、または意図せず公開される場合はどこを確認しますか

エラー時は、認証情報が正しく設定されているか、対象ユーザーに投稿権限があるか、サーバー側で国外からのREST APIアクセスが制限されていないかを順に確認します。誤公開の場合は、ステータス値がどこで決まっているかを追い、変数経由になっていれば固定値へ変更します。切り分けはノード単体のテスト実行で1つずつ行うのが確実です。

ChatGPT単体ではなくDifyを使う必然性はどこにありますか

同じ処理を繰り返す運用に落とし込む段階で差が出ます。Difyはテンプレートと変数で出力を安定させ、条件分岐やモデル切替を設計でき、HTTP Requestで外部システムへ書き込めます。自分以外のメンバーに入力欄付きで渡せる点も運用上の利点です。逆にプロンプトが固まっていない探索段階では、ChatGPTで型を作ってからWorkflow化するほうが手戻りが少なくなります。

参考情報・出典

著者プロフィール

この著者の記事一覧へ

著者 藤村 隼人 CREATREE合同会社 代表社員／NSJAPAN CDO

HAL名古屋卒業後、マーケティング会社を経てCREATREE合同会社を設立。代表社員として、生成AI導入、AI業務自動化、UI/UX設計を横断し、構想から実装・運用改善まで支援。NSJAPANではCDOを務める。