毎月同じ画像を差し替えるページは、依頼せず自分で替えられるようにする｜管理画面に専用の差し替え口を作る構成と、依頼運用のままでよい場合の線引き

毎月1枚だけ画像を入れ替えたい。診療カレンダー、月替わりのキャンペーン告知、今月の営業日程。やることは毎回同じなのに、そのたびに制作会社へメールを送っている——という店舗・クリニックは少なくありません。

先に結論を書きます。月に1回以上くり返す差し替えは、汎用の編集画面を覚えてもらうのではなく、その作業専用の入力口を管理画面に1つ作るのが正解です。 入力項目は「対象年月」と「画像」だけに絞り、保存を押したら本番に出るところまでを一続きにします。

逆に、年1回以下しか起きない変更や、文章とレイアウトを一緒にいじる必要がある変更は、依頼運用のままにしておく方が事故が少ないです。この線引きを先に決めないまま「管理画面から触れるようにしてください」と頼むと、使われない機能が1つ増えて終わります。

この記事では、実際に毎月の画像差し替えを自社作業に移したクリニックサイトの構成を例に、作る側の設計と、発注側が指定すべき項目を書きます。

なぜ「WordPressの編集画面を覚える」では回らないのか

「管理画面から編集できます」と言われていても、月1回の作業が自社に定着しないのには理由があります。大きく3つです。

1. 画像がどこに入っているか探せない

トップページの画像1枚を替えるには、固定ページなのかテーマの画像なのか、ブロックの何番目なのかを特定する必要があります。月1回しか開かない画面では、毎回ゼロから探すことになります。

2. 画像をそのまま入れると重くなる

月次のカレンダーやチラシは、印刷用のPNGでもらうことがよくあります。実例では1枚311KBの未圧縮PNGでした。ページに載る画像を素のまま積み上げていけば、表示速度に効いてきます。「アップロードする前に軽くしてください」という依頼を、毎月やってもらうのは現実的ではありません。

3. 1枚入れるとレイアウトが動くことがある

画像の高さが変わる、もしくは2枚構成になる月があると、その下にある要素の位置が変わります。デザインを座標で組んでいるページでは、ここが最も壊れやすい場所です。

この3つは担当者のパソコン習熟度の問題ではなく、画面の作り方の問題です。だから直すのは運用手順ではなく、入力口の側です。

実例：毎月の診療カレンダーを3手で替えられるようにした

診療科が2つあるクリニックのサイトで、トップページに毎月の診療カレンダー画像を載せています。従来は制作側が毎月差し替えていました。

この運用で起きるのは、画像はもう手元にあるのに、ページだけが取り残されるという状態です。実際にあったのは、クリニック側が当月のお知らせ投稿に新しいカレンダー画像を入れていたのに、トップページだけ前月のまま残っていたケースです。画像は存在している、依頼は出ていない、制作側は気づかない。誰も悪くないのに1か月古い情報が出続けます。

依頼を待つ構造そのものが原因なので、入力口を渡す形に変えました。現在の操作は3手です。

1. 管理画面の「診療カレンダー」を開く
2. 対象年月と画像を選ぶ（診療科ごとに1枚ずつ）
3. 「保存してホームページに反映する」を押す

押してから本番に出るまでは約40秒。月次の作業としてはこれで終わりです。

専用の差し替え口を作るときの設計6点

1. 入力項目は2つまでに絞る

「対象年月」と「画像」。これ以上増やすと、月1回の作業で毎回迷う場所が生まれます。タイトルや説明文を同時に編集させたくなりますが、それは別の画面の仕事です。

2. 2枚目以降は任意にして、空なら導線ごと消える作りにする

この案件では、途中の月からカレンダーが2枚構成（診療科ごとに1枚）に変わりました。運用を渡したあとに構成が変わるのは珍しくありません。

2枚目を空にしたら、その画像を指すリンクやセクションごと自動で消えるようにしておくと、1枚構成の月に戻っても何も作業が要りません。逆にここを作り込まずに出すと、「画像が無い月は空のボタンが残る」という見た目の事故が、運用を渡した後に発生します。

3. 画像の加工は受け取ってから自動でやる

アップロードされた画像をそのまま使わず、受け取った側で軽量化します。実例では311KBの未圧縮PNGを150KBのWebPへ自動変換しています。依頼者は印刷用データをそのまま入れてよい、という状態にするのが目的です。

このとき確認しておきたいのが、自動変換した画像が、それまで手作業で用意していた画像と同一になるかです。実際にファイルのハッシュ値が一致することを確かめてから切り替えると、見た目が変わるリスクをゼロにできます。

4. 画像の取得に失敗しても、サイトの更新を止めない

差し替えの仕組みは、サイト全体の公開処理の一部として動きます。ここで「画像が取れなかったので処理を中断」という作りにすると、カレンダー1枚の不調でサイト全体の更新が止まります。

取得に失敗したときは前回の値を残して正常終了するのが正解です。カレンダーが先月のままになるのは困りますが、サイト全体が更新できなくなるのはもっと困ります。被害の大きさで優先順位を決めます。

5. 同じ月の画像を訂正したときに、古い画像が残らないようにする

「日付を間違えたので同じ月の画像を差し替えた」という訂正は必ず起きます。ファイル名が同じだと、閲覧者のブラウザが前の画像を表示し続けることがあります。画像のURLに更新ごとに変わる番号を付けておくと、訂正がその場で反映されます。

6. レイアウトが動く場合は「ずらす量」を変数にする

デザインを座標で指定しているページに要素を足すと、それ以降を全部ずらす必要が出ます。実例では、カレンダーの下に146pxのバナーを入れたかったのに、次の見出しまでの隙間が86pxしかなく、以降の要素を100px繰り下げました。

この種の作業は、直接数値を書き換えると元に戻せなくなります。ずらす量を変数にしておき、「ずらし量を0にしたとき、変更前と完全に一致する」ことを確認できる形で実装するのが安全です。実例では座標130個のハッシュ値が変更前と完全一致することを確認しています。

さらに、2枚目の画像が無い月はずらしも戻るようにしておきます。でないと、バナーが消えた月に100pxの空白だけが残ります。

反映経路は2つ持たせる

保存を押したら即座に反映される仕組み（保存時の処理）だけに頼ると、将来その処理がサーバー側の設定変更で動かなくなったときに、「保存しても永久に反映されない」という無言の穴が残ります。保存は成功し、画面上はエラーも出ず、本番だけ変わらない。これが一番気づきにくい壊れ方です。

対策は、定期的に走る処理の側でも差し替え内容を見に行くようにしておくことです。余分に1回処理が走るだけで、出力は同じです。冗長に見えますが、これは「前月のまま残る」という最初の問題がそのまま再発するのを構造的に防ぐための保険です。

実装方式は2つあり、失敗の出方が違う

WordPressでこの種の管理画面を足すには、通常のプラグインとして入れる方法と、強制的に読み込まれる形（mu-plugins）で置く方法があります。どちらを選ぶかは、壊れたときの挙動で決めます。

方式	構文エラー時の挙動	向いているもの
通常のプラグイン	有効化しようとした時点で失敗し、サイトと管理画面は無傷	管理画面の追加、入力フォーム
強制読み込み（mu-plugins）	管理画面ごと白画面になり、画面から停止できない	止まると困る常時処理

強制読み込み側は「管理画面から無効化できない」ことが利点でも弱点でもあります。画面から止められない場所にコードを置くなら、編集のたびに構文チェックを通す運用とセットにする必要があります。そこまでの運用を約束できないなら、通常のプラグインに置いて「最悪でも有効化に失敗するだけ」の状態にしておく方が安全です。

専用口を作るか、依頼のままにするか

すべてを自社作業に移す必要はありません。判断は次の表で足ります。

条件	判断
月1回以上くり返す／更新に期日がある	専用の差し替え口を作る
入力が「画像1枚」「数値1つ」のように定型	専用の差し替え口を作る
年1回以下しか起きない	依頼のままでよい
文章・レイアウト・構成を一緒に変える	依頼のままでよい（崩れたときに戻せる人が必要）
差し替えを間違えると法的・医療的な誤情報になる	専用口＋公開前の確認者を必ず置く

とくに3行目は重要です。使う頻度が低い機能は、作っても使い方を忘れます。 年1回の作業のために管理画面を覚え直すより、メール1本で依頼する方が速いのが実態です。

渡す前に必ず確認する2つのこと

1. 実際に1回「保存」を押して反映されるところまで見る

コードが正しく、APIの応答も正常で、それでも画面上のボタンが動かないケースはあります。押していない機能は、納品していないのと同じです。ログイン権限の都合で制作側が押せない場合は、クライアントに1回押してもらい、その裏で処理が走ったことを制作側がログで確認するという段取りまで含めて納品にします。

2. 差し替える画像が「メディアライブラリから選べる」状態か

画像がテーマの中に直接置かれているサイトでは、管理画面の画像選択に出てきません。実際に、メディアライブラリが完全に空（画像フォルダ自体が無い）というサイトもあります。この場合は、専用口を作る前に画像をメディアライブラリ側へ移す作業が先に必要です。見積の段階で、ここを確認せずに「管理画面から差し替え可に」と約束すると、想定していなかった移行作業が後から出てきます。

まとめ

• 月1回以上くり返す画像差し替えは、汎用の編集画面を覚えさせるのではなく、専用の入力口を1つ作る
• 入力項目は「対象年月」と「画像」に絞る。3手で終わる形を目標にする
• 画像の軽量化は受け取った側で自動化する。切り替え前に、手作業版と同一になることを確認する
• 取得に失敗してもサイト全体の更新は止めない。被害の大きさで優先順位を決める
• レイアウトが動くなら、ずらす量を変数にして「0にすれば変更前と一致する」状態で実装する
• 反映経路は2つ持たせる。保存できるのに反映されないが最も気づきにくい壊れ方
• 年1回以下の変更・文章とレイアウトを一緒に変える変更は、依頼運用のままでよい
• 渡す前に、実際に保存を1回押す。画像がメディアライブラリから選べるかを確認する

1回あたりの手間は小さくても、くり返す作業は放置されやすく、放置された結果は「1か月古い情報が出続ける」という形で表に出ます。くり返す作業を見つけたら、人の手順を増やす前に入力口の形を変える——この順番で考えると、運用は軽くなります。