手元のファイルを本番へ上げる前に「どちらが新しいか」を確かめる｜更新日時で版を見分ける手順と、消さずに反映するやり方

ホームページや業務ツールに手を入れるとき、手元のパソコンにあるファイルを直してからサーバーへ上げる。ごく普通の流れです。ただしこの流れには、作業内容とは無関係に成立してしまう事故がひとつあります。手元のファイルが、本番より古いという状態です。

結論から書きます。本番へ上げる前に確かめるのは、自分が直した箇所ではありません。本番側に、自分の手元より新しいファイルが1つでもあるかどうかです。1つでもあれば、その時点で送るのをやめます。先に本番から取り直し、取り直した版の上で直してから送る。この順番を守るだけで、他の人が積み上げた更新を消してしまう事故は起きません。

弊社は名古屋でホームページ制作と、店舗向けの業務ツール開発・運用を行っています。この記事は、複数の担当者・複数のパソコンから同じサイトやツールを触る現場で実際に使っている確認手順をまとめたものです。専門的な用語はできるだけ避け、制作会社に任せている経営者の方が「発注時に何を言えばいいか」まで分かる形で書きます。

なぜ手元のファイルが古くなるのか

「自分が最後に触ったのだから、手元が最新に決まっている」——この前提が崩れる場面は、思っているより多くあります。

崩れる場面	何が起きているか
作業するパソコンが2台以上ある	事務所のデスクトップで直した内容が、持ち歩くノートには戻ってこない
制作会社や外注が本番を直接触る	「ちょっと直しておきました」がサーバー上だけで完結する
別の担当者が管理画面から編集した	ファイルではなく管理画面側で内容が変わっている
急ぎの修正をサーバー上で直接行った	緊急対応のときほど、手元へ戻す作業が後回しになる

厄介なのは、古いファイルは見た目がまったく正常だという点です。開いても壊れていません。手元で動かしても普通に動きます。動作確認のテストを流しても通ります。ただしそれは、古い確認手順が古いファイルに対して通っただけで、本番に入っている新しい機能のことは何も見ていません。

つまり「手元で確認したから大丈夫」は、この事故に対しては何の根拠にもなりません。確認すべき対象が手元ではなく本番側にあるからです。

起こりうる被害の大きさ

弊社が運用している、店舗の口コミ収集システムでの例です。機能を追加しようとした際、手を付ける前に本番側のファイルの更新日時を調べたところ、次の状態でした。

	最終更新
手元の作業フォルダ	約1か月前で停止
本番サーバー	前日まで更新あり

このシステムはバージョン管理（履歴を残す仕組み）を入れていない時期のもので、差分も履歴も出ません。もし更新日時を見ずに手元の版を送っていれば、その1か月のあいだに本番へ入っていた改修がまとめて消えていました。アンケート完了画面の改修、個人情報の取り扱い表記、管理画面の刷新、契約プランごとの機能制御。どれも作り直しになりますし、何が消えたのかを思い出すところから始めることになります。

被害は「消えたこと」より「消えたと気づけないこと」のほうが深刻です。送った直後に画面は正常に表示されますから、その場では成功に見えます。数日後に店舗から「この前まであった画面がなくなった」と言われて初めて分かる、という順番になります。

上げる前に行う5つの手順

手順1：本番側に「自分より新しいファイル」がないか数える

まず、自分の手元のフォルダが最後に更新された日を確認します。次に本番側で、その日より後に更新されたファイルの数を調べます。数が0なら手元が最新、1以上あれば手元は古い、という単純な判定です。

サーバーにコマンドで接続できる場合は、次のような形で一覧を出せます。

find /本番のフォルダ -type f -newermt "2026-09-01" | head -50

FTPソフトしか使えない場合でも、サーバー側のフォルダを更新日時の降順で並べ替えれば同じことが分かります。日付の列を一度も見ていない状態で上書きを始めない、というのが守るべき線です。

手順2：1つでもあれば送らず、本番から取り直す

新しいファイルが見つかったら、その日に送る予定だった作業は一旦止めます。やることは、本番の一式を手元へダウンロードし直し、新しく取り直した版の上で改めて修正を当てることです。

このとき、古いほうのフォルダはそのまま残さないでください。名前を変えるか、中に「このフォルダは古い版です。使わないこと」と書いたファイルを1枚置きます。フォルダが2つ並んでいると、後日別の作業で必ず古いほうを開きます。人の注意力ではなく、開いた瞬間に分かる仕掛けで防ぎます。

手順3：取り直した版が「本当に正しい版か」を数字で確かめる

ダウンロードが途中で切れていたり、別のフォルダを取ってきていたりすることがあります。取り直した直後に、数で一致を確認します。

• 動作確認の自動テストがあるなら実行し、件数が前回の作業記録と一致するかを見る
• テストがないサイトなら、ページ数・記事数・画像の枚数などをサーバー側と手元で突き合わせる

「テストが通った」ではなく「59件中59件成功で、前回の記録と同じ59件だった」まで見ると、正しい版を取れたと言い切れます。

手順4：送る前に、両方向の差分を出して中身を読む

修正が終わったら、いきなり送らずに送らずに差分だけ表示する確認を行います。転送ソフトにはたいてい、実際には転送せず「何が変わるか」だけを出す機能があります。

見る方向は2つです。

方向	何を確かめるか
手元 → 本番	自分が直したファイルだけが対象になっているか。覚えのないファイルが混ざっていないか
本番 → 手元	本番側にだけ存在する新しい変更が残っていないか（手順1の再確認）

ここで「削除」と表示される項目があれば、必ず中身を確認してください。自分が作った覚えのないファイルの削除は、ほぼすべて事故です。

手順5：差分だけ送る。「同期して余分を消す」機能は使わない

転送ソフトには、手元のフォルダとサーバーを完全に同じ状態にする同期機能があります。便利ですが、これは手元に無いファイルをサーバーから削除する動作を含みます。

弊社が運用している多店舗サイトでも、この落とし穴があります。ページを組み立てる仕組みが出力するファイル一式には、後から人の手でサーバーに置いた検索対策用のファイルが含まれていません。具体的には、検索エンジン向けに事前生成したページ一式、エラーページ、サイトの設定ファイル、各種アイコン画像です。完全同期をかけると、これらがまとめて消えます。店舗数が多いサイトなら、その店舗分すべてで消えます。

正しいやり方は、変更したファイルだけを指定して送ることです。古いファイルがサーバーに残りますが、どこからも読み込まれていなければ害はありません。「余計なものが残るのが気持ち悪い」という理由で完全同期を選ぶのは、消えて困るものと引き換えにする判断になります。

更新日時が当てにならない3つの場面

手順1で見る更新日時ですが、これ自体が嘘をつく場面があります。知っておかないと、確認したつもりで通り抜けてしまいます。

1つ目は、クラウド同期フォルダです。 iCloudやDropboxのような同期フォルダでは、ファイルの更新日時は「書き込んだ側の時刻」を保ったまま運ばれてきます。別のパソコンで昼に書かれたファイルが、同期の遅れで夕方に手元へ降りてくると、手元では「数時間前に更新済み」に見えているのに、実際にはたった今届いたばかりということが起こります。作業の途中でファイルの中身が入れ替わることも普通にあります。共有フォルダのファイルは、編集する直前にもう一度開き直すのが唯一の防御です。

2つ目は、転送時に日時が書き換わる場合です。 転送方法によっては、サーバー側のファイルの更新日時が「転送した時刻」になります。こうなると本来の更新時期が分からなくなるため、日時での比較は使えません。この場合はファイルサイズや中身の照合で判断します。

3つ目は、自動生成されるファイルです。 ページを組み立てる仕組みを動かすたび、中身が同じでもすべてのファイルの更新日時が新しくなります。「全部新しい」という表示は、この場合は何の情報にもなりません。

時間差でぶつかる「方針の衝突」にも同じ確認が要る

ファイルの新旧だけでなく、判断そのものが後から覆されることがあります。

典型的なのは、朝に記事へ追加した問い合わせ導線が、同じ日の夜の別作業でまとめて削除される、という形です。弊社では自社サイトの更新記録を日次で突き合わせており、この形の衝突を検知したことがあります。3本の記事から、それぞれ1,708字・733字・776字が消えていました。同時に作業していたわけではなく、8時間空いています。つまり後から作業した側が、前の作業の意図を知らないまま逆の判断をしたという形です。追加した理由は記録に残っていましたが、読まれていませんでした。

これはファイルの更新日時を見ても防げません。必要なのは、本番に手を入れる前に、その対象の直近の作業記録を読むという手順です。

• 同じページ・同じ設定について、直近数日に作業記録がないか確認する
• あれば、結論だけでなくそうした理由まで読む
• 理由を踏まえたうえで覆すなら問題ない。知らずに覆すのが事故
• 覆したときは、なぜ覆したかを記録に残す

制作会社に複数人で入ってもらっている場合や、社内の担当者とも並行して触っている場合は、この記録の有無が効いてきます。

制作会社に任せている場合に言っておくこと

自社で作業しない場合でも、発注側から一言伝えておくだけで防げます。見積もりや依頼のときに、次の4点を確認してください。

確認すること	確認の仕方
本番より古いファイルで上書きしない運用になっているか	「作業前に本番側の更新日時を確認していますか」と聞く
上書き前のバックアップを取っているか	「戻す手段はどう確保していますか」と聞く
完全同期で余分なファイルを消す運用をしていないか	「差分だけ送る形ですか」と聞く
他社・他担当が触った可能性を確認しているか	直近で誰が何を触ったかを共有する

特に、過去に他社が納品したサイトへ後から手を入れてもらう場合は要注意です。前の制作会社が入れた設定ファイルや検索対策のファイルが、新しい制作会社の作業フォルダには存在しません。完全同期をかけられると、そこで静かに消えます。「今あるものを消さないでください」と依頼書に一行入れておくだけで、確認の精度は変わります。

履歴を残す仕組みを入れておくのが根本策

ここまでの手順は、履歴を残す仕組み（バージョン管理）が無い場合の対処です。履歴が残っていれば、どちらが新しいか・何が変わったかは機械が答えてくれますし、消しても戻せます。

新しくサイトやツールを作る場面であれば、最初から履歴を残す形にしておくことを勧めます。後から入れることもできますが、その時点より前のことは分かりません。今あるものについては、少なくとも次の2つだけは決めておいてください。

1. どこが正本かを1か所に決める（多くの場合は本番サーバー）
2. 本番へ上げる前に本番側の更新日時を見るを作業手順に固定する

まとめ

• 上げる前に確かめるのは、自分の修正内容ではなく本番側に自分より新しいファイルがないか
• 1つでもあれば送らない。本番から取り直してからやり直す
• 取り直した版は、件数など数字で正しさを確かめる
• 送る前に両方向の差分を出し、「削除」と出る項目は必ず中身を見る
• 完全同期は使わず、変更したファイルだけを送る
• 更新日時は、クラウド同期・転送方法・自動生成の3つの場面で当てにならない
• ファイルの新旧だけでなく、直近の作業記録を読んでから本番を触る

古いファイルは、開いても正常に見えます。動かしても動きます。だからこそ、目視や勘ではなく、日付を数えるという機械的な1手順を作業の先頭に固定することが、いちばん確実な防ぎ方になります。

ホームページや業務ツールの運用・改修でお困りのことがあれば、お気軽にご相談ください。