Webサイトのお助け隊

SNSに投稿すると、連携ツールが拾ってWordPressにも記事が入る。最初のうちは便利に回っていたのに、しばらくすると「他社の記事をシェアしただけの投稿まで、自社の記事として一覧に並ぶ」といったズレが出てきます。ここで足りなくなっているのは処理の量ではなく、途中で落ちてしまった情報のほうです。同じ形の相談を受けて1か月かけて着地させた案件があるので、その判断の順序をそのまま書きます。ノーコードのまま粘るべき場面と、受け口を自分で作ったほうが早い場面は、はっきり分かれます。

データは中間で平坦になる

SNSと連携ツールとWordPressをつなぐ構成では、投稿は最終的に「タイトル」「本文」「URL」といった数個の文字列に均されてWordPressへ届きます。元の投稿が自分で書いたものだったのか、他サイトの記事にコメントを付けて共有したものだったのかという文脈は、この時点でどこにも残っていません。連携ツールが情報を捨てているというより、決まった形の箱に詰め替える以上、箱に無い項目は運べないという話です。

ここを理解しないまま「WordPress側で判定すればいい」と考えると、必ず行き詰まります。本文にURLが含まれていたらシェア扱い、といった当て推量のルールを書くことになり、例外が出るたびに条件を足すことになります。判定に必要な情報は、失われる前の場所、つまり上流で明示的にフィールドへ入れておく。これが原則です。連携ツールの側で送信するタイトルに種別を示す文字列を混ぜてしまえば、WordPress側は推測をやめて、その値を読むだけで済みます。

切り替えを決める4つの軸

ノーコードのままにするか、受け口を自作するかは、次の順で見ると迷いません。

一つめは、判定や分岐に必要な情報を上流で足せるかどうかです。足せるなら、まず足す。連携ツールの送信内容に1項目加えるだけで済む話を、受け側の実装で解決しようとすると工数が何倍にもなります。二つめは、届いたデータをそのまま使うのか、加工が要るのかです。外部ページのタイトルや画像を取りに行く、短縮URLを展開する、複数の値から1つを選ぶ、といった処理が入る時点で、ノーコードの守備範囲からは外れます。

三つめは、止まったときに気づける仕組みがあるかどうかです。連携ツールは、期限切れや連続エラーで自動的に停止することがあります。四つめが、テストを自分の手で作れるかどうか。相手のSNS投稿を待たないと検証できない構成にすると、動作確認のたびに待ち時間が発生します。実装より、この待ち時間のほうが期間を延ばします。

実際にあった案件：SNSの自動投稿を、記事として成立させる

相談の内容は、SNSの投稿がZapier経由でWordPressへ自動投稿される仕組みがすでにあり、そこに手を入れたいというものでした。やりたかったのは、自分の発信と、他サイトの記事を共有した投稿とで、記事の作り方を変えること。共有のときは元記事のタイトルと画像とURLを取ってきて、アイキャッチまで設定したい。参考サイトも提示されていました。

調査して分かったのは、WordPressに届いた時点で両者の区別が付かないということでした。本文の文字列と、末尾に付いたURLしかない。ここから何をもって共有と判断するかの定義を、実際のデータを見ながら作っては直すことになり、57通のやり取りで1か月ほどかかっています。振り返ると、着手前に何パターンか実際に投稿してもらい、WordPress側にどう入るかを先に観察しておけば、この往復は圧縮できました。

最終的な設計は、Zapier側で送るタイトルに区分を示す値を埋め込む形です。上流で情報を持たせれば、受け側は読むだけになります。あわせて「通常の投稿にはURLを載せない」という運用ルールも決めました。技術で100%解けないときに運用の制約を足すのは、逃げではなく設計の一部です。全部を実装で吸収しようとすると、例外のたびに条件が増えて誰も直せないコードになります。

加工の側でも細かい問題が出ました。共有された投稿には短縮URLが二重に入ることがあり、カードとして表示されるURLとリンク先のURLが混在します。「リンク先のURLが2重で入っている場合、サイト名のリンクのほうに反応してしまう」ため、タイトル末尾の短縮URLを採用するという割り切りで確定させました。外部ページからタイトルや画像を拾う処理は、外部サイトの情報を取得して業務に使う場合の設計と同じ注意が必要で、取得先の構造が変われば止まります。

実装はテーマではなくプラグインとして納めています。テーマの更新で消えず、テーマを乗り換えても機能が残るためです。もう一点、アイキャッチを自動設定するとテーマによっては本文の画像とアイキャッチで同じ画像が2枚並びます。これは仕様として先に伝えておくべき部分でした。

動かなくなったとき、最初に見る場所

この案件では「昨日から自動投稿が止まっている」という連絡が2回あり、2回とも連携ツール側のZapがオフになっていました。実装を疑って調べても何も出ません。SaaSをまたぐ連携で「急に動かなくなった」ときは、まず相手側のスイッチが入っているかを確認する。これがいちばん短い道です。運用している側が意図せず切ってしまうこともあれば、試用期間の終了やエラーの蓄積で自動的に止まることもあります。

次に見るのが、受け側に何か届いているかどうかです。届いていて処理で落ちているのか、そもそも届いていないのかで、調べる場所がまったく変わります。時間指定で動かしているならWordPressの定期処理も疑う対象で、WP-Cronが時間どおりに動かない理由は連携の遅延として現れることがあります。

それから、テスト手段を自分の側に用意しておくことです。この案件でも「投稿された履歴が無かったため確認ができませんでした」という待ちが何度も発生しました。管理画面から同じ形のデータを手で登録して動作を確認できるようにしておけば、相手の投稿を待たずに検証が進みます。実際、最後の確認は手動で作った投稿で行っています。細かい話ですが、プラグインのZIPをインストールしようとして PCLZIP_ERR_BAD_FORMAT が出る場合は、たいてい転送中の破損です。自分の環境で入れられるかを試せば切り分けられます。

ケース別に、どちらを選ぶか

連携ツールのままでよいのは、送られてくるデータの形が決まっていて、受け側で判断することがない場合です。フォームの回答を表計算に流す、通知を別のチャットへ転送する、といった用途はこれに当たります。上流にフィールドを足すだけで済むのは、分岐の条件が数個に収まり、その値を送信側で決められる場合。今回の案件はここに着地しました。

受け口を自作する判断になるのは、外部から取ってきた情報を加工する、保存先のデータ構造を自分で決めたい、連携元が今後増える、失敗を記録して再実行したい、といった要件が出たときです。特に連携元が増える見込みがあるなら、早い段階で受け口を1つに寄せたほうが、後の追加が設定作業だけで済みます。毎月の集計のように定型の出力が目的なら、数字を自動で出す仕組みの側から考えたほうが素直に組めることもあります。

判断の順序としては、まず上流を見る。上流で足せないと分かった時点で、受け口の自作を検討する。この順番を守るだけで、要らない実装をかなり減らせます。業務自動化の相談でも、最初に確認するのは「その判断に必要な情報は、どこまで遡れば残っているか」です。

よくある質問

連携ツールをやめて全部作り直すべきですか

やめる必要はありません。今回の案件も、SNSからWordPressへ運ぶ部分は連携ツールのまま残し、受け側の加工だけをプラグインにしています。運ぶ仕組みを作り直すと、認証や再送の面倒まで自前で抱えることになります。足りない部分だけを足すほうが、費用も運用の手間も小さく収まります。

連携が止まっても気づけないのが不安です

止まったこと自体を検知する仕組みは、受け側に置くのが確実です。一定時間データが届いていなければ通知する、という監視を1つ入れておけば、ツール側の停止も通信の失敗もまとめて拾えます。連携ツールの通知だけに頼ると、ツールが止まっているときは通知も来ません。

参考サイトと同じ動きにしてほしいと伝えれば作れますか

参考サイトがあること自体は助かりますが、そのサイトが使っているテーマや投稿タイプの前提が、依頼元のサイトと違うことがよくあります。今回の案件でも、参考サイトはカスタム投稿タイプを前提にした作りで、実際のサイトのテーマはその一覧表示に対応していませんでした。着手前に、参考サイトの前提と実サイトの差分を洗い出す時間を取ったほうが、結果的に早く終わります。