商品紹介の記事を公開したあと、掲載情報や画像を直すたびに、提供元とWordPressの管理画面を行き来していませんか。
更新する記事が一つなら、それほど困らないかもしれません。ところが記事が増えると、「どの記事を直すのか探す」「情報を写す」「画像を選ぶ」「保存して見直す」という作業を、対象の数だけ繰り返すことになります。
この記事では、外部サービスの商品情報を取得し、対応するWordPressの記事へ反映するn8nの仕組みを、実際に修正して試した内容を紹介します。単に情報を送るだけでなく、画像の取り違えを防ぐこと、更新後に読み直すこと、失敗した対象を一覧に残すことまで扱いました。
こんな方に向けた記事です
- WordPressで商品紹介サイトなどを運営し、同じ種類の情報を繰り返し更新している方。
- 自動化に興味はあるものの、自分の更新作業で何を任せられるのか分からない方。
- 制作を依頼する前に、必要な準備と確認事項を整理したい方。
読み終えると、自分の更新作業を自動化する候補にできるか判断し、「どの記事の、何を、どう更新するか」を依頼・試作に使えるメモにまとめられます。 後半には記入例と、一件から試すための確認手順を載せました。
ここでは、画面操作をそのまま再現する設定手順ではなく、完成までに決めることと確認することを説明します。接続先によって設定は異なりますが、専門用語を覚える前に、作るものの中身を整理できます。
今回の実施範囲
自分用の既存フローの未公開版を修正し、テストデータで動きを確認した記録です。公開中のフローは変更していません。本番の記事更新、作業時間の削減効果、顧客案件での成果を示すものではありません。本文の「木製マグカップ」は、仕組みを説明するための架空の商品です。
今回作ったのは「記事を書く仕組み」ではなく「既存記事を更新する仕組み」
まず、何を自動化したのかを整理します。
今回扱ったのは、すでにWordPressにある記事です。外部サービスから商品情報を取り直し、その商品に対応する記事を探して、決めた情報と画像を更新する流れを見直しました。AIに新しい紹介記事を丸ごと書かせる話ではありません。
n8nは、このように複数のサービスの間の処理をつなぐ道具です。WordPress向けには記事の取得・更新などの機能が用意されています。ただし、「どの外部情報と、どの記事を組み合わせるか」「画像が正しいか」といった判断条件は、使う仕組みに合わせて設計する必要があります。 公式ドキュメント1
図1：情報を取得して終わりではなく、保存された内容の確認と結果の一覧までをつなぐ。実際の管理画面ではなく、処理を説明する図です。
手で行っていた作業のうち、何を任せるのか
提供元の情報を開く
- 仕組みに持たせる処理：決めた方法で商品情報を取得する
- 人が決める・確認すること：利用条件、取得できる項目、情報の正しさ
対応する記事を探す
- 仕組みに持たせる処理：商品を識別する情報で照合する
- 人が決める・確認すること：商品と記事の対応ルール
掲載情報と画像を直す
- 仕組みに持たせる処理：指定した項目を更新する
- 人が決める・確認すること：上書きしてよい部分、残す文章
保存後に見直す
- 仕組みに持たせる処理：保存された識別情報や画像を読み直す
- 人が決める・確認すること：読者に見える文章・レイアウトの確認
できなかった対象を調べる
- 仕組みに持たせる処理：成功・失敗・見送りと理由をまとめる
- 人が決める・確認すること：原因の調査、再実行するかの判断
「自動化すると全部見なくてよい」ということではありません。毎回同じ順番で行う作業を任せ、判断が必要な箇所を人の作業として残す形です。
商品一つで考えると、更新する場所が分かりやすい
例えば、外部サービスに「商品番号A001・木製マグカップ」という商品があり、自分のWordPressにも、その商品を紹介する記事があるとします。
記事には、提供元から転記した商品情報のほかに、自分で書いた使用感も載っています。ここで商品情報を取り直すからといって、使用感まで書き換える必要はありません。
自動化を考えるときは、対象の記事を選ぶことと、その記事のどこを変えるかを分けて決めます。
図2：架空の商品を使った更新範囲の例。青は更新候補、灰色は残す部分です。本文を分けて保護できるかは、実際の記事の保存方法に合わせて確認します。
記事名が似ているだけでは、更新先を決めない
「木製マグカップ」と「木製マグカップ・大」が並んでいたら、名前だけでは取り違えるかもしれません。
今回の修正では、元の情報に含まれる商品などの識別情報を使い、WordPress側の対象との対応を確認するようにしました。途中の処理でデータの順番が変わっても、並び順だけで記事と画像を組み合わせないためです。
事務作業に置き換えるなら、書類の上から順に相手を決めるのではなく、受付番号を見て渡す相手を確かめる変更です。途中で一件が抜けても、次の商品へ画像をずらして渡さないようにします。
自分のサイトで試す場合も、「商品番号が記事のどこに保存されているか」「同じ番号の記事が複数ないか」を先に調べます。照合に使える情報がなければ、そこを整理してからでないと安全に更新できません。
自分で書いた文章は、更新対象から外す
これは今回の仕組みを別のサイトで使う場合の、設計上の確認事項です。
商品情報とレビューが本文の中に混ざっているなら、まずどこまでを自動更新するのかを決めます。「商品情報欄だけ変える」「画像だけ変える」「本文のレビューは触らない」といった範囲です。
記事全体を置き換える方が処理としては単純でも、その方法が自分のサイトに合うとは限りません。消したくない文章を先に挙げておくことが、更新項目を決める近道になります。
実際に直したのは、画像・保存後の確認・失敗時の扱い
既存の流れに対して、主に次の点を修正しました。
同じ画像があれば、登録し直さずに使う
更新のたびに画像を登録すると、WordPressの画像一覧に同じものが増えるおそれがあります。
今回は、取得元の画像と、すでにWordPressにある画像の中身を照合し、一致していれば既存画像を再利用するようにしました。名前が同じという理由だけで選ぶのではなく、画像そのものの対応を確認するためです。
反対に、画像の不一致が解消していない状態では、記事の書き換えへ進まないようにしています。商品情報が正しくても、別の商品の写真が載ってしまえば、そのまま公開できないからです。
なお、この照合や再利用は、WordPressへの接続だけで自動的に備わるものではありません。今回のフローで追加・調整した処理です。
「保存できた」という返事の後に、もう一度読む
データを送って正常終了になっても、それだけで確認を終えないようにしました。
更新した記事を読み直し、対象を識別する情報と設定された画像が、意図したものに対応しているかを確認します。手作業で保存ボタンを押したあと、記事を開き直して確かめる工程に当たります。
ただし、データの照合と、見た目の確認は別です。画像の切れ方、文章の読みやすさ、スマートフォンでの表示まで、同じ確認で分かるわけではありません。本番で使い始める際には、読者が見るページの確認も残します。
一件失敗したら、理由を残して次へ進む
まとめて更新するときは、途中の一件が失敗した後の動きも必要です。
今回は一件ずつ処理し、失敗した対象は理由とともに記録して、その後の対象へ進む形にしました。最後に成功・失敗・処理を見送った対象をまとめます。
もう一つ気をつけたのが、失敗表示の直後に、無条件で同じ書き込みを繰り返さないことです。保存先では処理が済んでいるのに、応答だけが届かなかった可能性もあります。画像の二重登録や同じ更新の繰り返しを避けるため、画像の登録と記事の書き込みでは、安全でない自動再試行を外しました。
この進め方は、一件ごとに独立して更新できる今回の処理に合わせたものです。複数の更新が全部そろわないと困る仕事なら、途中で止める設計が必要な場合もあります。
テストでは、うまくいかないデータも混ぜた
修正後は、処理の部品ごとのテストに加え、n8n上でもテストデータを使って実行しました。
見たかったのは、正常な一件が流れることだけではありません。画像が違う場合に止まれるか、途中で失敗しても次の対象へ進めるかを確認しています。
図3：未公開版を使った模擬テストで確認した動き。本番の記事を更新した結果ではありません。
正しい既存画像がある
- 確認した結果：同じ画像を登録し直さず再利用した
- この確認を入れる理由：重複した画像を増やさないため
画像が一致しない
- 確認した結果：不一致のまま記事を書き換えなかった
- この確認を入れる理由：別商品の画像を載せないため
途中の一件が失敗する
- 確認した結果：失敗を記録し、後続の対象へ進んだ
- この確認を入れる理由：一件の問題と全体の進行を分けるため
ここまでが今回確認できた結果です。本番の記事を使った確認や公開は行っていないため、「何件を何分で更新できた」「更新ミスがなくなった」という効果までは出していません。
一方で、試す前に決めておくべきことは明確になりました。正常な場合の動きだけでなく、一致しない、見つからない、途中で失敗する場合にどうするかまで、更新の条件として用意しておく必要があります。
自分のサイトで始める前に、用意するもの
いきなりn8nの設定画面を開くより、次の情報をそろえた方が、作れるかどうかを判断しやすくなります。
1．取得してよい情報と、その受け取り方
外部サービスが、データを受け渡すための窓口であるAPIや、ファイルでの出力を用意しているかを確認します。
ブラウザで見える情報が、そのまま自動取得・転載してよい情報とは限りません。利用条件、画像の使用条件、取得回数の制限を先に確認してください。取得方法によって、n8nで必要な処理も変わります。
また、すでに使っているプラグインやサービスに同期機能があれば、それで十分な場合もあります。年に数回、少数の記事を直すだけなら、手作業や一括編集の方が扱いやすいかもしれません。n8nを使うこと自体を目的にしない方が、余計な運用を増やさずに済みます。
2．商品と記事を結び付ける情報
商品番号など、両方のデータを照合できるものを確認します。
その番号がない、一つの商品に複数の記事がある、古い番号と新しい番号が混在している、といった場合は、先に対応表を作ります。「名前を見れば分かる」という状態を、そのまま自動化のルールにはしません。
3．n8nとWordPressへ接続できる環境
n8nを動かす環境と、WordPressへ必要な操作を許可する認証情報が要ります。WordPressの構成によって認証方法が異なり、対応する環境ではアプリケーションパスワードなどを使用します。接続設定にはサイトのURLやユーザー情報も必要です。 公式ドキュメント2
認証情報は公開記事や依頼文に貼り付けず、接続設定の中で安全に扱います。また、フローのファイルを受け取るだけでは動きません。自分のサイトに合った接続と設定が必要です。
4．元に戻す準備と、失敗したときの担当
実データを書き換える前に、バックアップや検証用の環境を用意します。記事本文だけでなく、今回変更する項目の元の値も確認できるようにします。
失敗の一覧を出しても、それを見る人がいなければ放置されます。「誰が結果を見るか」「どの失敗なら再実行するか」「対応できないときは止めるか」も決めておきます。
まず一件で試すなら、この順番で確認する
以下は、今回の修正内容をもとにした、導入時の進め方です。今回の作業で、本番環境のこの手順をすべて完了したという意味ではありません。
手順1：更新対象を一つ選び、変更前を残す
最初は、対象を一件に絞ります。可能なら本番とは分けた環境に、確認用の記事を用意します。
商品番号、記事のURL、現在の情報、設定中の画像を控えます。更新後に比較できるように、必要な画面と値を残してください。複数をまとめて試すのは、一件の対応が確認できてからです。
手順2：まだ書き込まず、取得した内容を見る
情報を取得できることと、記事を更新してよいことは別です。
まずは取得した商品番号、掲載情報、画像を確認します。項目が空になっていないか、別の商品ではないか、画像が利用できるものかを見ます。この段階では、WordPressの記事を書き換えないようにします。
手順3：更新先と、変更する項目を照合する
取得した商品が、予定した一件の記事と結び付いているかを確かめます。
併せて、変更予定の項目を一覧にします。レビュー本文や独自の説明など、変更しない部分も並べると、上書き範囲の認識違いを防ぎやすくなります。
手順4：検証用の記事を更新し、保存後の値と表示を見る
指定した項目だけを更新し、その記事を読み直します。
商品番号と画像の対応、更新した情報に加え、変更しないはずの文章が残っているかも確認します。管理画面だけでなく、読者が見る表示でも確かめます。
手順5：失敗する条件と、もう一度実行した場合を試す
正しいデータだけで終わらせず、対応する記事がない場合や、画像が一致しない場合も検証対象にします。ここは、今回確認した三つのケースに加えて、導入先でも確認しておきたい項目です。
同じデータでもう一度実行したときに、記事や画像が重複しないかも確認します。結果の一覧を見て、成功した対象と調べるべき対象を区別できる状態にします。
この確認を通す前に、定期実行や大量の対象へ広げるのは避けます。定期的に動かす設定は、更新内容と失敗時の扱いが確認できた後の段階です。
依頼や試作に使える「更新仕様メモ」の記入例
専門用語で仕様書を書く必要はありません。まずは、自分が普段行っている作業を、次の形にまとめてみてください。
何をしたいか
提供元の情報を、自分の商品紹介記事へ反映したい
最初に試す対象
商品番号A001に対応する、検証用の記事一件
情報の取得元
利用条件を確認した外部サービス。取得方法は別途確認
記事を探す手掛かり
記事側にも保存してある商品番号
変えたい部分
指定の商品情報欄と商品画像
変えない部分
自分で書いた使用感、独自の見出しや説明
情報が合わない場合
その記事を更新せず、理由を一覧に残す
更新後の確認
商品番号、情報、画像、残す文章、ページの表示
人が行うこと
結果の確認、失敗の調査、公開してよいかの判断
まだ分からないこと
接続方法、保存項目、バックアップの戻し方
分からない欄は、無理に埋めず「未確認」として構いません。その欄を調べることが、次の作業になります。
依頼する場合も、このメモがあれば、「サイトを全部自動化したい」ではなく、何を完成させたいかを具体的に伝えられます。対応範囲だけでなく、接続設定、納品後の修正、失敗時の対応が含まれるかも確認してください。
実行前に確認すること
- 取得・画像利用の条件を確認した。
- 商品と記事を取り違えない照合方法がある。
- 更新する項目と、変更しない部分を分けた。
- バックアップと検証場所を用意した。
- 一件の保存後に、データと表示を確認した。
- 不一致や失敗を、結果の一覧から見つけられる。
- 結果を見る人と、問題があったときの対応を決めた。
よくある疑問
AIを使わないとできませんか？
今回の中心は、決まった情報を取得し、対応する記事へ渡し、結果を確認する処理です。文章生成のAIを使うことは必須ではありません。決まった項目を写す仕事と、文章の下書きを作る仕事は分けて考えます。
WordPressなら、どんな記事でも同じように更新できますか？
同じとは限りません。商品情報が本文、追加の入力欄、プラグイン独自の項目のどこに入っているかで、読み書きする方法が変わります。今回の記事は、WooCommerceの在庫や注文を同期した実績を説明するものでもありません。
自動化すれば、確認の手間はなくなりますか？
なくなりません。機械で照合する部分を増やしても、表示の確認、取得元の仕様変更、認証の期限切れなどへの対応は残ります。導入費用だけでなく、n8nの実行環境や外部サービスの利用料、維持する手間も含めて判断します。
操作に詳しくなくても、始められますか？
この記事の更新仕様メモは、普段の作業が分かれば整理できます。一方、実際の接続と更新処理の作成には設定が必要です。自分で試す範囲と、制作を依頼する範囲を分けるためにも、まず一件分の更新内容をまとめることをおすすめします。
最初にすることは、更新したい記事を一件選ぶこと
今回の修正では、情報をWordPressへ送る処理だけでなく、商品と画像の対応、保存後の確認、失敗の記録までを見直しました。テストでは、画像の再利用、不一致時の書き込み停止、一件の失敗後の続行を確認しています。
自分のサイトで検討するなら、まず、最近手で直した記事を一件選んでください。「何を見て」「どの記事の」「どの部分を変えたか」を、更新仕様メモに書き出します。
その作業が毎回同じルールで繰り返され、情報の利用条件と記事との対応を確認できるなら、自動化を試す候補になります。逆に、毎回判断が違う部分は人に残す。その区別ができれば、何を作るべきかを、n8nの設定を始める前に決められます。
