複数のブログとSNSの更新が止まっていないかを一覧で確認する方法｜投稿の仕組みには触らず「最後に更新された日」だけを外から読む監視の作り方

店舗ごとのブログ、本部の自社メディア、ECサイトのお知らせ、Googleビジネスプロフィール、Threads。事業が広がるほど「更新する場所」は増えていきます。それぞれに担当者や自動投稿の仕組みがあり、個別には動いているはずなのに、全体として「今どれが止まっているのか」を誰も言えない。多店舗の店舗ビジネスやWEB担当者から、こうした相談を受けることが増えました。

結論から書きます。更新先が増えたときに最初に作るべきものは、新しい投稿ツールではなく、「投稿先の一覧」と「それぞれの最後に更新された日」を並べた1枚の画面です。 投稿している仕組み（自動投稿のプログラム・担当者の手作業・外注先）には手を入れず、外から誰でも見られる公開情報だけを読んで、最終更新日を並べます。これだけで「止まっている場所」は一目で分かります。

この記事では、その監視を作るときの考え方と手順を、実際に41か所の更新先を並べて分かったことを交えて整理します。

結論：投稿の仕組みは触らず、「最後に更新された日」だけを外から読む

作るものは次の3点だけです。

1. 投稿先の台帳。 何という媒体で、どのURLで、誰（どの仕組み）が投稿していて、どれくらいの頻度で更新されるはずなのかを1行ずつ持ちます。
2. 最終更新日の読み取り。 各投稿先の公開情報（記事一覧のAPIやフィード）を読んで「いちばん新しい投稿の日付」を取ります。読むだけで、書き込みはしません。
3. 判定。 「最後の投稿から何日経ったか」を「期待している更新間隔」と比べ、超えていれば「遅延」と表示します。

ポイントは、投稿する側の仕組みを一切変えないことです。すでに動いている自動投稿や、担当者が続けている手作業は、そのまま動かします。監視は「結果として公開されたもの」だけを見ます。

なぜ投稿の仕組み側に手を入れないのか

更新先が多い状態で「投稿を一元化するツール」を作ろうとすると、既存の仕組みを全部そのツールに載せ替えることになります。これは失敗しやすい進め方です。理由は3つあります。

第一に、動いているものを止めるリスクです。店舗ブログの自動投稿、SNSの定期投稿、外注先の手作業。それぞれに設定や認証があり、載せ替えの途中で1つでも切れると、今まで動いていたものが止まります。「管理を楽にするため」に始めた作業で、更新が止まるのは本末転倒です。

第二に、投稿先ごとに仕組みが違うことです。WordPressで動くブログ、Shopifyのブログ、noteのような外部サービス、Googleビジネスプロフィール。投稿の方法もAPIの有無もバラバラで、1つのツールにまとめようとすると、いちばん扱いにくい媒体に全体が引きずられます。

第三に、そもそも困っているのは「投稿できないこと」ではなく「止まっていることに気づけないこと」だからです。困りごとの正体が「見えない」なら、必要なのは「見える化」であって「投稿の統合」ではありません。

以前の記事「自動処理の監視は「最後に成功した時刻」を見る」で、1つの自動処理を監視するには「失敗の検知」より「成功の鮮度」を見るのが確実だと書きました。本稿はその考え方を、多数の投稿先に横展開する話です。1つ1つの仕組みの中身を見るのではなく、公開された成果物の日付を並べます。

台帳に持つ項目

投稿先の台帳は、最初は次の項目があれば十分です。

項目	内容	例
名前	投稿先の呼び名	○○店ブログ、本部メディア、ECお知らせ
グループ	店舗ブログ／自社メディア／EC／SNS など	店舗ブログ
URL	公開されているサイトの入口	サイトのトップURL
読み取り方法	WordPress／フィード／手入力	WordPress
期待する更新間隔	何日以内に1本は出るはずか	30日
投稿している仕組み	自動投稿の名前、担当者、外注先	毎日10時の自動投稿
テーマ・文字数・画像の有無	その媒体で決めている投稿の型	店舗ネタ／1,200字／画像あり

この中で、後から効いてくるのが「投稿している仕組み」の欄です。止まっていると分かったとき、次に知りたいのは「誰に（どの仕組みに）聞けばいいか」です。台帳にこの欄がないと、止まっている場所は分かっても、直しに行く先が分かりません。

「期待する更新間隔」は、最初は仮の値で構いません。店舗ブログなら30日、本部メディアなら7日、SNSなら3日、というように媒体の性質から置きます。実際に並べてみて、厳しすぎる・緩すぎると分かったら直します。

「最後に更新された日」を外から読む方法

読み取りは、投稿先の種類ごとに「公開されている記事一覧」を使います。どれもログインは不要で、サイトに何も書き込みません。

投稿先の種類	読む場所	取れるもの
WordPressのブログ	記事一覧のAPI（wp-json）またはフィード（feed）	最新記事の日付・タイトル・URL
Shopifyのブログ	ブログURLの末尾に「.atom」を付けたフィード	最新記事の日付・タイトル
noteなど外部サービス	公開されているRSS	最新記事の日付・タイトル
Googleビジネスプロフィール・Threads	公開の読み取り口が無い	手入力欄で「最後に投稿した日」を管理

WordPressは、サイトによって読み取り口の場所が違います。標準の「wp-json」で読めるサイトもあれば、「/wp/」の下にWordPressがあるサイト、記事一覧のAPIが塞がれていてフィードしか読めないサイトもあります。1つの読み方に決め打ちせず、候補を順番に試して、最初に「記事の一覧として読めた」ものを採用する作りにしておくと、サイトごとの違いを吸収できます。

読み取りの頻度は、6時間に1回もあれば十分です。更新の遅延は「日」の単位で判断するものなので、分刻みで見る必要はありません。頻繁に読みすぎると相手のサーバーに負担をかけるだけです。

Googleビジネスプロフィールのように公開の読み取り口が無い媒体は、無理にAPI連携せず、まず手入力の欄を用意します。投稿した日を人が入れる形でも、「入っていない・古い」が一覧で見えるだけで、無いよりはるかに管理できます。

判定の基準：期待する間隔を超えたら「遅延」

判定は単純です。最終更新日から今日までの日数を数え、台帳の「期待する更新間隔」と比べます。

状態	条件
正常	最終更新からの日数が、期待する間隔以内
遅延	期待する間隔を超えている
遅延（投稿0件）	読み取りはできたが、公開されている記事が1本も無い
エラー	読み取り自体に失敗した（サイトが落ちている・読み取り口が変わった）
未入力	手入力の媒体で、日付がまだ入っていない

「投稿0件」を「エラー」ではなく「遅延」に分類しているのには理由があります。サイトは正常に動いているが記事が1本も無い、という状態は、読み取りの失敗ではなく更新の問題です。エラーに混ぜると「サイトを直す話」と「投稿を再開する話」が区別できなくなります。

日数の数え方も1つだけ決めておきます。時刻ではなく「日付の差」で数えることです。「30日以内」を時刻まで含めて厳密に計算すると、投稿時刻の数時間の差で判定が変わり、見るたびに結果が揺れます。日単位に丸めておけば、同じ日に何度見ても同じ結果になります。

実例：41か所を並べたら、動いていたのは2か所だった

名古屋の美容サロンFCの各店ブログ、自社メディア、制作を担当した美容室のブログ、ECサイトのお知らせ、SNSをあわせて、更新先の台帳を作って並べた実例です。読み取りは公開情報のみで、どのサイトにも書き込んでいません。

区分	件数
監視対象	41か所（自動読み取り35・手入力6）
正常	2か所
遅延	33か所
エラー	0か所

並べる前の感覚では「だいたい動いているはず」でした。並べた結果は、正常が2か所だけです。

内訳で最も大きかったのは、FCの各店ブログでした。23店のうち20店が、同じ日付の「年末のご挨拶」記事を最後に止まっていました。個別に見ていれば「この店は少し前に更新したな」で済んでいたものが、一覧にすると「全店が同じ日に止まっている」と分かります。止まり方が揃っているということは、店ごとの事情ではなく、全店共通の仕組み側で何かが起きたということです。原因を探す場所が一気に絞れました。

他にも、ECサイトのお知らせが約190日、別のECサイトのお知らせが約400日更新されていない、1店は2年以上前が最後、2件は公開記事が0本、といった状態が同時に見えました。どれも「知らなかった」のではなく「知る手段がなかった」状態です。

読み取りの実装自体は、Node.jsで小さなWebアプリを作り、SQLiteに台帳と読み取り結果を持たせた程度の規模です。同じ構成で4回読み取って結果が一致することを確かめてから運用に入れました。

なお、この一覧を作ってから3日後に再計測すると、正常が24か所、遅延が11か所に変わっていました。止まっていた店舗ブログに、順に記事が入り始めたためです。監視を作ると、次にやるべきことが「どこから直すか」に変わります。 41か所の全部を一度に動かす必要はなく、止まっている期間が長い順、影響が大きい順に手を付ければよいと分かるからです。

実装時に起こりうるつまずきと、先に入れておく対策

外から読むだけの仕組みは単純ですが、実際に多数のサイトを相手にすると、読み取りの細部でつまずきます。想定される4点と、設計の段階で入れておく対策です。

1. 「応答は正常なのに中身が記事一覧ではない」ケースがある。 表示部分を別の仕組みで組み、WordPressを裏側に置いているサイトでは、記事一覧のAPIのURLにアクセスすると、正常応答でありながら中身は通常のページ（HTML）が返ってくることがあります。「応答が正常だったから読めた」と判定すると、記事が0件と誤認します。読めたかどうかは、応答の成否ではなく「中身が記事の一覧として解釈できたか」で判定し、解釈できなければ次の候補（別のURLやフィード）に進む作りにします。

2. 日付の時刻帯（タイムゾーン）が揃わない。 WordPressのAPIは、投稿日を「時刻帯の情報が無いローカル時刻」と「世界標準時」の2種類で返します。前者をそのまま日付として扱うと、サーバーの設定によって9時間ずれます。日付は世界標準時の方を取って保存し、表示するときに日本時間へ直します。SNSやフィードも同様で、保存の形式を1つに統一しておくと、後で並べ替えたときに順序が崩れません。

3. 更新日が取れないサイトがある。 記事一覧のAPIもフィードも無く、サイトマップにも更新日が入っていない、というサイトは実際にあります。ここに時間をかけるより、そのサイトは「手入力」の枠に回し、他の34か所を先に動かす方が、全体の管理は早く始まります。

4. 期待する間隔が仮のままになる。 SNSやGoogleビジネスプロフィールのように、投稿ペースが決まっていない媒体は、期待する間隔も仮置きになります。仮であることを台帳の備考に書いておかないと、後から見た人が「3日以内が正式な決まり」と誤解します。仮の値には「仮」と書く。それだけで運用の混乱は避けられます。

いずれも、監視の仕組みを壊すほどの問題ではありません。ただ、対策を後回しにすると「一覧には出ているが数字が合わない」状態になり、一覧そのものが信用されなくなります。監視は信用されなければ見られず、見られなければ無いのと同じです。

手順：明日からできる4ステップ

ステップ1：更新先を全部書き出す。 店舗ブログ、自社メディア、EC、SNS、Googleビジネスプロフィール、外部サービス。「うちの更新先は何か所あるか」を即答できないなら、まずこれだけで価値があります。この段階では表計算ソフトの1枚で十分です。

ステップ2：それぞれの「最後に更新された日」を手で調べて埋める。 各サイトを開いて最新記事の日付を写します。41か所でも1時間あれば終わります。ここで初めて「止まっている場所」が見えます。自動化はこの後です。

ステップ3：期待する間隔を仮置きし、超えているものに印を付ける。 店舗ブログ30日、メディア7日、SNS3日、のように置きます。印が付いた場所について「誰が（どの仕組みが）投稿しているか」を台帳に書きます。ここで書けない場所があれば、それは止まっていることに誰も気づけない場所です。

ステップ4：自動で読める場所から自動化する。 WordPress・Shopify・RSSは外から読めます。制作会社や保守会社に頼む場合は、「各サイトの最新記事の日付を、外から読んで一覧にしてほしい。投稿の仕組みは変えないでほしい」とそのまま伝えれば通じます。読めない媒体は手入力の欄を残します。

順番が大事です。ステップ2の手作業を飛ばして自動化から入ると、「何を読むべきか」が定まらないまま作ることになり、読み取りの細部で止まります。手で1回やると、どのサイトが読みにくいかが先に分かります。

まとめ

• 更新先が増えたとき、最初に作るのは投稿ツールではなく「投稿先の一覧」と「最後に更新された日」を並べた画面
• 投稿している仕組みには手を入れず、公開されている記事一覧やフィードを外から読むだけにする
• 判定は「最終更新からの日数」と「期待する間隔」の比較。投稿0件は遅延、読み取り失敗はエラーと分けて表示する
• 41か所を並べた実例では、正常は2か所だった。20店が同じ日付で止まっていることが分かり、原因の場所が絞れた
• 読み取りは「応答の成否」ではなく「記事一覧として読めたか」で判定し、日付は世界標準時で保存する
• 期待する間隔が仮なら「仮」と書く。一覧は信用されて初めて機能する

多店舗のホームページや自動投稿の仕組みは、店舗が増えてもホームページが崩れない作り方やGBPの最新情報投稿をブログ連動で自動化する運用でも扱っています。「どれが止まっているか分からない」状態の整理から相談したい方は、お問い合わせからご連絡ください。