毎月のサイト更新で画像を何枚も間違えたので、確認専用の管理画面を作った話

情報サイトを運営していると、記事を書くことより、

「毎月正しく更新し続けること」

の方が難しくなることがあります。

うにラボで運営している「ABCクッキング攻略ノート」では、毎月、

• キャンペーン
• 料理メニュー
• パンメニュー
• ケーキメニュー
• 料金シミュレーター
• 入会費用
• 月別記事

などを更新しています。

最初のうちは、その都度必要な画像や情報を確認しながら更新していました。

ところが2026年3月の更新で、複数のメニュー画像を取り違えました。

1枚ではありません。

確認してみると、かなりいろいろ間違っていました。

そこで、単に画像を差し替えて終わるのではなく、

月次更新そのものを確認しやすい仕組みに変える

ことにしました。

実際に間違えていた画像

当時確認できた誤りには、こんなものがありました。

料理のBメニューには、本来とは違うOメニューの画像が入っていました。

パンでは、

• シーズンメニューにDisney系の別画像
• タブレットメニューに別のパン画像

が入っていました。

ケーキでも、

• シーズンメニューにプロモーション画像
• タブレットメニューに別のケーキ画像

が使われていました。

Gitの修正履歴にも、これらの誤画像をまとめて直した記録が残っています。

公開ページだけ見ていると、

「画像は表示されている」

ので、システム上は正常です。

404にもなりません。

ビルドも通ります。

でも、内容としては間違っています。

ここが厄介でした。

TypeScriptもbuildも、この間違いは見つけてくれない

普段の開発では、

npx tsc --noEmit

や、

npm run build

で確認できます。

コードの型がおかしい。

存在しない変数を使っている。

ビルドできない。

こういった問題なら検知できます。

でも、

「この海老マヨの記事に、この写真で合っているか」

はTypeScriptには分かりません。

ファイルパスが正しければ正常です。

つまり、コンテンツサイトでは、

技術的に正常なことと、情報が正しいことは別

です。

これは料金や制度のファクトチェックと同じ問題でした。

ファイル名だけを見ながら確認するのがつらかった

メニュー画像には、

• cook_a
• cook_b
• cook_c
• cook_o
• cook_t

のような区分があります。

さらにパンやケーキにも、

• シーズン
• タブレット
• 月限定

などがあります。

これを、

「このファイル名はどの料理だっけ？」

と一つずつ確認するのはかなり面倒です。

しかも毎月あります。

そこで、

人間が見て確認しやすい形に一度整理する

ことにしました。

スクレイピングした素材を、そのまま公開しない

現在の月次更新では、まず公式情報から取得した素材やページを保存します。

ただ、取得したものをそのまま公開ディレクトリへ置くのではなく、

一度、

• 料理
• パン
• ケーキ
• キャンペーン

などに整理します。

3月の改善時には、スクレイピングした素材の中から正しい画像を確認し、整理用ディレクトリへ分類しました。

料理ならA・B・C・O・T。

パンならシーズン・タブレット。

ケーキも同様です。

この段階で、

「取得したファイル」から「意味の分かるコンテンツ」へ変換する

イメージです。

menus.jsonで「画像と料理名」を対応させた

さらに、画像ファイルだけではなく、

data/menus.json

に月ごとのメニュー情報を持たせました。

たとえば料理なら、

• A menu
• メニュー名
• 使用する画像

をセットで管理します。

パンやケーキについても同じです。

こうすると、

「cook_b.jpg が存在する」

だけではなく、

「この画像は、このメニュー名として扱う」

という対応関係をデータとして確認できます。

これでもまだ完全ではありません。

JSONの対応自体を間違える可能性があるからです。

そこで、さらにもう一段確認できるようにしました。

内部確認専用の /admin/[yyyymm] を作った

作ったのが、

/admin/202603

のような月別確認ページです。

これは一般ユーザー向けの管理画面ではありません。

自分たちが月次更新を確認するためだけの画面です。

画面を開くと、その月の、

• キャンペーン
• 料理メニュー
• パンメニュー
• ケーキメニュー

をまとめて確認できます。

メニューについては、

料理名と画像を並べて表示

します。

これなら、

「Bメニューなのに写真が違う」

という問題を、ファイル名を見るよりはるかに見つけやすくなります。

実際の実装でも、campaigns.json と menus.json から対象月の情報を取得して、確認画面に一覧表示しています。

管理画面はGoogleには出さない

この確認画面は読者向けコンテンツではありません。

そのため、

noindex

にしています。

検索結果に、

「2026年3月 コンテンツ確認」

のような内部ページが出ても意味がないからです。

公開Webサイトの中に管理用ページを置く場合でも、

誰のためのページなのか

は分ける必要があります。

利用者向けページと、運営者向け確認ページは役割が違います。

8月には「確認する対象」自体がかなり増えていた

この仕組みを作ったあと、サイトはさらに大きくなりました。

2026年8月の月次更新では、

スクレイピング結果だけでなく、キャンペーンの詳細ページや引用根拠も保存しています。

そのうえで、

• campaigns.json
• menus.json
• キャンペーンの具体例
• 月次ページ
• 料金シミュレーター
• 入会費用
• 記事一覧
• 月別メニュー記事

などを更新しています。

つまり、

「8月になったので記事の日付だけ変える」

という更新ではありません。

今月の情報によって、サイト内のかなり多くの場所が影響を受けます。

月次更新で怖いのは「更新漏れ」

情報が増えてくると、画像間違いとは別の問題も出てきます。

あるページだけ先月のまま残る

という問題です。

たとえば、

TOPは8月。

キャンペーンページも8月。

でも料金シミュレーターには7月のキャンペーン条件が残っている。

これもユーザーから見れば誤情報です。

だから月次更新では、

「新しい情報を追加する」

だけではなく、

その情報が影響する場所を洗い出す

必要があります。

8月更新では、キャンペーンだけでなくシミュレーターや入会費用、記事一覧の月表示までまとめて変更しています。

「覚えて更新する」をやめる

最初は、

「ここも更新しなきゃ」

と人間が覚えていれば何とかなります。

でもサイトが大きくなるほど無理になります。

そこで少しずつ、

• データを一元管理する
• 更新手順を残す
• 根拠を保存する
• 確認画面を作る
• 人間が目で見る場所を集約する

という形に変えています。

完全自動化ではありません。

むしろ今回のようなコンテンツでは、

最後に人間が見る工程は残した方がいい

と思っています。

画像と料理名が合っているかのような確認は、人間の目の方が早いことも多いからです。

自動化したいのは「判断」より「準備」

月次更新を全部AIやプログラムに任せれば楽そうにも見えます。

でも、前回の記事で書いたように、AIが扱った情報に誤りが混ざることもあります。

そこで現在は、

人間が判断するための材料を揃える部分を自動化・構造化する

考え方に寄せています。

たとえば、

• スクレイピングで情報を集める。
• JSONへ整理する。
• 確認画面へ並べる。

そこまでは機械がかなり手伝えます。

そして、

• この画像は本当にこのメニューか
• このキャンペーン条件で合っているか
• 今月も継続しているのか

という部分を確認します。

人間の確認をなくすのではなく、

人間が確認しやすい状態まで持っていく

という使い方です。

小さな情報サイトでも、運用ツールを作る価値があった

内部確認ページを作ること自体は、読者には直接見えません。

SEO順位が上がる機能でもありません。

売上を直接生むページでもありません。

それでも、情報サイトではかなり価値がありました。

間違った情報や画像を公開すると、

あとで記事を増やす以上に修正コストがかかるからです。

特に毎月更新するサイトでは、

更新速度より、同じ品質で更新し続けられること

の方が重要になります。

ABCクッキング攻略ノートでは、実際に画像を複数取り違えたことをきっかけに、月別の内部確認画面を作りました。

失敗そのものは単純でした。

でも結果として、

「公開ページを作る仕組み」だけではなく、

「公開する前に正しいか確認する仕組み」

までサイトの一部として考えるようになりました。

これは、実際に運営してみないと気づきにくかった改善のひとつです。