本番サイトを直接直した修正が次の更新で消えるとき｜元データと公開物が別の場所にある構成で起きる巻き戻りの構造と、急ぎで本番を触った後に必ず元データへ戻す手順

「先週直してもらった店名が、元の名前に戻っている」「追加したはずの見出しが消えた」。修正したこと自体は確かなのに、別の更新をしたタイミングで以前の状態へ戻ってしまう。こういう相談は、ホームページの運用ではよくあります。

結論から書きます。このとき壊れているのは修正ではなく、「どこを正（しょう）とするか」の取り決めです。 多くのサイトは、手元の「元データ」から公開用のファイルを組み立て、それをサーバーへ送る構成になっています。本番のファイルだけを直すと、次に元データから組み立て直した瞬間、古い材料で作った公開物が上から被さり、修正は消えます。

急ぎで本番を直接触ること自体は、実務ではあり得る判断です。問題は、その後の扱いです。正しい順番は次の3つです。

1. 本番を触る前に、このサイトの元データがどこにあるかを確認する
2. 本番を直した直後に、「元データのどこへ戻すか」の一覧を作って記録に残す
3. 元データへ戻し終えるまで、誰も組み立て直し（ビルド）をしない状態にしておく。戻せないなら、正を公開物側へ切り替えて旧い組み立て手順を封印する

弊社は名古屋でホームページ制作と、多店舗サイトの運用を行っています。この記事では、約25店舗の店舗サイトで店名変更を本番へ直接反映した例と、作業するパソコンが2台に分かれたLPの例をもとに、巻き戻りの構造と防ぎ方を整理します。

なぜ本番の修正が消えるのか

「元データ → 組み立て → 公開物」は一方通行

最近のホームページは、サーバー上のファイルを直接書いて作るより、次の流れで作られていることが多くなっています。

• 元データ：ページの部品、共通のデザイン、店舗ごとの設定ファイルなど。人が読んで編集する形
• 組み立て（ビルド）：元データを材料に、公開用のファイル一式を自動で生成する作業
• 公開物：組み立てで出てきたファイル。サーバーに置かれて訪問者が見るもの

この流れは一方通行です。元データを直して組み立てれば公開物は変わりますが、公開物を直しても元データには何も伝わりません。そのため、本番だけ直した状態で次に誰かが組み立てを実行すると、古い元データから作った公開物で本番が上書きされます。修正が「消えた」ように見えるのはこのためです。

しかも組み立ては、今回の修正とは無関係な作業のついでに走ります。「別のページの画像を差し替える」「料金表を一部直す」といった普段の更新でも、元データから全体を組み立て直す仕組みなら、以前の本番修正はまとめて巻き戻ります。

公開物から元データは作り直せない

「本番が新しいなら、本番をダウンロードして元データにすればいい」と考えたくなりますが、組み立て型のサイトではこれができません。組み立ての過程で、プログラムは読みやすさを捨てて1行に詰められ、部品の名前は短い記号に置き換えられ、複数のファイルが1つにまとめられます。公開物は「完成品」であって「設計図」ではないので、そこから元の部品へ戻すことは実用上できません。

以前の記事「手元のファイルを本番へ上げる前に「どちらが新しいか」を確かめる」では、本番のほうが新しければ本番から取り直す、という手順を紹介しました。これは本番と手元が同じ形のファイルである場合の話です。組み立て型のサイトでは取り直しが効かないため、本番で行った変更を人の手で元データへ移し直す必要があります。

起きやすい構成

構成	元データ	公開物	巻き戻りのきっかけ
組み立て型のサイト・LP	部品と設定ファイル	生成されたHTML・JavaScript	次の組み立て
WordPressの親テーマを直接編集	テーマ配布元	サーバー上のテーマ	テーマの更新
テンプレートから量産したLP	テンプレートと差し込み文言	各LPのHTML	テンプレートからの再生成
制作会社が手元で管理しているサイト	制作会社のパソコン	サーバー上のファイル	制作会社の次回更新

どの形でも、「本番で直した」と「元データで直した」が別の作業になる点は同じです。

実例1：約25店舗のサイトで店名を本番へ直接反映した

名古屋の美容サロンFCで運用している店舗サイトは、1つの共通テンプレートと、店舗ごとの設定ファイル（店名・住所・電話・予約URLなど）から、約25店舗分のサイトを組み立てる構成です。

ある店舗の店名を変更することになりました。ところが、元データは別のパソコンにしかなく、作業できるパソコンには手元に何もない状態でした。そこで、組み立てはせず、本番に置かれている公開物を直接書き換えて店名を反映しました。触った範囲は次のとおりです。

• 公開中のJavaScript 3本に含まれる店名・英字表記
• ページの見出し情報（タイトル、説明文、SNS共有用の情報、検索エンジン向けの構造化データ、アクセス解析に送る店名）
• その店舗の「店舗一覧」ページ
• 他の約25店舗それぞれの「店舗一覧」ページに載っている、この店のカード
• ブログ部分（WordPress）の店名・サイト名の設定値

作業前にはサーバー上に変更前の一式と、全店舗分の店舗一覧ページのバックアップを取り、JavaScriptは別のファイル名で置いて参照先だけを切り替えました。旧いファイルを残しておけば、参照を戻すだけで切り戻せます。反映後は、スマートフォンとパソコンの2つの画面幅で5ページずつ、タイトルとヘッダーの店名、エラーが出ていないことを確認しています。

ここまでで本番は正しい状態になりました。ただし、この時点で元データは旧い店名のままです。この状態で起こりうることを整理すると、次のようになります。

• 元データのあるパソコンでこの店舗を組み立て直すと、店名が旧い名前に戻る
• この店舗とは関係ない別の店舗を組み立てて、店舗一覧ページを一緒に送ると、その店舗の一覧に載っているカードだけ旧い店名に戻る
• 同じ日に全店舗へ追加した新しいセクションも同じ方法で入れていたため、組み立て直した店舗からそのセクションが消える

特に2つ目は気づきにくい巻き戻りです。店名を変えた店舗のサイトは触っていないのに、別の店舗の更新をきっかけに、そちらのページの表記だけが古くなります。店舗が多いほど、どこで古い表記が復活したのかを追うのは難しくなります。

そのため、本番へ反映した時点で、元データ側で直すべき場所を一覧にして記録に残しました。店名1つの変更でも、戻す先は6か所に分かれていました。

戻す先	内容
その店舗の設定ファイル	店名・英字表記
その店舗のページの見出し情報	タイトル・説明文・構造化データ一式
その店舗の店舗一覧ページ	カードの表記
全店共通の店舗一覧のひな形	カードの店名
店舗一覧を生成するプログラム	この店舗だけに入っていた特別な表記の扱い
新店舗を作るプログラム	店舗の初期値

本番で触った場所と、元データで直す場所は一致しません。本番では1か所に見えても、元データでは複数の材料に分かれていることが普通です。記録の段階で戻す先を具体的に書いておかないと、後から「どこを直せばいいか」を調べ直すことになります。

実例2：作業するパソコンが2台に分かれたLP

もう1つは、教育系のお客様から受託しているLPです。組み立て用の作業フォルダと、それを完成品にまとめる仕組みは1台目のパソコンにありました。修正指示（文言まわり16項目、スマートフォンでの配置2件、目次の復活、追加セクション）が届いたとき、手元にあったのは2台目のパソコンと、完成品の一式だけで、1台目へ接続することもできませんでした。

そこで、完成品を直接編集して修正を仕上げました。この結果、正しい版は2台目の完成品側にあり、1台目の作業フォルダは修正前の版のまま、という状態になります。1台目で組み立てを実行すれば、修正はすべて消えます。

このケースでは、次の2段階で扱いを決めました。

• 修正直後：1台目へ戻すための手順書を作り、両方のパソコンから読める共有フォルダに、修正後の一式と一緒に置いた。記録には「1台目で組み立てると修正が消える」と明記した
• 本番公開の時点：元データへ戻す代わりに、正しい版を「2台目の完成品フォルダ（直接編集する運用）」に切り替え、1台目での組み立ては禁止と記録に書いた

2つ目の判断が大事です。元データへ戻すのが本来の形ですが、戻す作業のほうが大きい場合や、今後も直接編集で運用するほうが合理的な場合は、正を公開物側へ移し、旧い組み立て手順を使わないと決めるのも正しい選択です。避けるべきなのは、どちらとも決めないまま両方が残っている状態です。

急ぎで本番を触ったときの手順

手順1：触る前に「元データはどこか」を答えられるか確かめる

本番のファイルを開く前に、次の2つを確認します。

• このサイトは組み立て型か（サーバー上のファイルを直接書いて作っているのか、別の場所から生成して送っているのか）
• 組み立て型なら、元データはどのパソコン・どのフォルダにあるか

ここを答えられないまま本番を直すと、後で戻す先が分からなくなります。答えられない場合は、急ぎでも本番修正の前に、まず制作担当へ確認するのが安全です。

手順2：変更前の一式を退避し、直した場所を控えながら作業する

本番を直すときは、変更前のファイルをサーバー内の別フォルダに日付付きで退避します。JavaScriptなど読み込まれるファイルは、同じ名前で上書きせず、別名で置いて参照先を切り替えると、切り戻しが参照を戻すだけで済みます。

作業中は、直した場所を一覧で控えます。この一覧は、そのまま次の手順で使う「戻す先リスト」の下書きになります。

手順3：直した直後に「戻す先リスト」を記録へ残す

本番修正が終わったら、その日のうちに次の3点を記録します。

• 本番で変更した内容と場所
• 元データ側で直すべきファイルの一覧（実例1の表のような形）
• 「元データ未反映。この状態で組み立てると○○が消える」という一文

最後の一文が、次に作業する人への警告になります。数日後に別の担当者、あるいは別の日の自分が組み立てを実行するとき、この一文を読んでいるかどうかで結果が分かれます。

手順4：戻し終えるまで、組み立てを実行させない

記録だけでは、読まれなければ止まりません。元データの作業フォルダ側にも、開いた瞬間に分かる印を置きます。

• 作業フォルダの一番上に「本番の方が新しい。○月○日の店名変更を移すまで組み立て禁止」と書いたファイルを置く
• 組み立ての手順書の先頭に同じ注意を書く
• 可能なら、組み立ての仕組み側で「本番に含まれる新しい店名が、元データに無ければ止まる」といった確認を入れる

人の注意力に頼らず、作業を始める場所に止まる理由を置くのがポイントです。

手順5：元データへ戻したら、組み立て結果と本番を突き合わせる

元データを直したら、組み立てた結果を本番へ送る前に、本番と比べます。本番で直した店名や追加したセクションが、組み立て結果にも入っているか。比べて差が無くなったことを確認して、はじめて「戻し完了」です。記録の「未反映」の一文も、ここで完了に書き換えます。

なお、送るときに「手元とサーバーを完全に同じ状態にする」同期機能を使うと、手元に無いファイルがサーバーから削除されることがあります。組み立て結果に含まれない検索対策用のファイルなどを消さないよう、変更したファイルだけを送る方法が安全です。

「戻す」か「正を切り替える」かの判断基準

状況	取るべき対応
今後も元データから組み立てて更新する	元データへ戻す（手順3〜5）
同じ元データから複数のサイトを作っている	元データへ戻す。放置すると他のサイトの更新で巻き戻る
組み立ての仕組みが手元に無い・今後使う予定が無い	正を公開物側へ切り替え、旧い組み立て手順を禁止と明記する
納品後は完成品を直接更新する運用になる	正を公開物側へ切り替え、完成品の置き場所を1か所に決める

判断に迷う場合は、「次に更新するとき、誰がどこから作業を始めるか」を考えると決めやすくなります。そこが元データなら戻す、完成品なら切り替える、です。

制作会社に任せている場合に確認しておくこと

ホームページの運用を外部に任せている場合、次の3つを聞いておくと、巻き戻りの多くは防げます。

1. このサイトは組み立て型ですか。元データはどこで管理していますか
2. 急ぎで本番を直接直した場合、元データへ戻すのは誰が、いつまでに行いますか
3. 担当者やパソコンが変わったとき、どこが正しい版かを示す記録はありますか

「直しておきました」の報告に、「元データにも反映済みです」まで含まれているかどうか。ここを確認する習慣があるだけで、以前の修正が静かに消える事故はかなり減ります。

まとめ

• 本番の修正が次の更新で消えるのは、サイトが元データから公開物を組み立てる構成で、元データ側が古いままだから
• 組み立て型のサイトは公開物から元データを作り直せない。本番の変更は人の手で元データへ移す必要がある
• 本番を触る前に元データの場所を確認し、直した直後に「戻す先リスト」と「組み立てると消える」という一文を記録に残す
• 戻し終えるまでは、作業フォルダ側にも組み立て禁止の印を置く。戻したら組み立て結果と本番を突き合わせて閉じる
• 戻すのが合理的でない場合は、正を公開物側へ切り替えて旧い手順を封印する。どちらとも決めないまま放置するのが最も危ない

多店舗サイトやLPの運用で、「前に直したはずの箇所が戻っている」ことが続いている場合は、修正の中身よりも、正しい版がどこにあるかの取り決めから見直すのが近道です。構成の確認や運用ルールの整理についてのご相談は、graciautoまでお気軽にお問い合わせください。