デジタル商品の「直したのに届かない」事故はなぜ起きるのか

原本と配布ファイルという二つの場所

デジタル商品をダウンロード販売する構成では、多くの場合ファイルが二箇所に存在します。ひとつは作る・直す場所である原本フォルダ、もうひとつは購入者がダウンロードするページに置かれた配布フォルダです。この二つは手作業でコピーして揃えるのが一般的で、片方を直しても、もう片方には自動的に反映されません。

サイト側の配布ファイルを差し替えた場合は、サイトのデプロイという作業も別に必要になります。原本を直した・配布側を差し替えた・サイトに反映した、という三つの作業がすべて終わって初めて、購入者に正しいファイルが届きます。どれか一つが抜けても、事故としては同じ「直したのに届かない」という結果になります。

緊急修正は配る側で直しがち

もう一つの理由は、緊急の不具合修正が起きやすい場所と、正として扱うべき場所が一致していないことです。購入者から不具合の報告が入ると、対応が早いのは配布ファイルを直接開いて直すことです。原本フォルダを経由せずに配布側だけを直せば、その場では解決します。

問題は、この「配布側だけの修正」が記録に残らないことです。原本フォルダは古いまま、版番号も変わらないまま、配布ファイルだけが新しくなります。次に原本から配布ファイルを作り直す機会が来たとき、この事実を覚えていなければ、配布側だけにあった修正は消えます。

展開済みフォルダという「第三の場所」に注意する

デジタル商品の管理には、原本フォルダと配布フォルダに加えて、もうひとつ場所が増えることがあります。ZIPを開いて中身を確認・編集するために展開した作業用フォルダです。この展開済みフォルダを「正しい原本」だと思い込んで作業すると、古いコードを直すことになります。

実際に2026-08-19に行った点検では、配布している全ZIPのSHA-256ハッシュ値は一致していました。ところがそのとき、原本フォルダにあった展開済みディレクトリは配布ZIPより古く、2ファイルにずれがありました。ZIPの中身に合わせてディレクトリ側を同期し直すことで解消しています。

この経験からわかるのは、ハッシュ値で確認すべき対象を「ZIPファイルそのもの」に固定しておく必要があるということです。展開済みのディレクトリは作業のたびに古くなりうる中間産物であり、正として扱う場所を増やすほど、どこが最新かを見失いやすくなります。

ハッシュ値で原本と配布ファイルを突合する

ハッシュ値は、ファイルの中身から計算される固定長の文字列です。中身が1文字でも違えば別の値になるため、目で見比べなくても「同じファイルかどうか」を機械で判定できます。本記事ではSHA-256という方式を使っています。

名前でなく中身で対応を取る

原本と配布のどのファイルが対応するかを、ファイル名だけで判断すると誤ります。実際の点検で一致していた例のひとつは、原本側と配布側でファイル名が異なっていました。原本は版番号のない名前、配布側は版番号「v1.2」を付けた名前です。

ファイル名で照合すると、この2つは「対応なし」に見えます。しかしSHA-256ハッシュ値で照合すると、中身は完全に一致していました。原本と配布の対応関係は、名前ではなく中身のハッシュ値で取るべきものだとわかります。

2026-09-24の実測結果

2026-09-24に、配布している全ZIP 7ファイルについて、原本フォルダのファイルとSHA-256ハッシュ値で突合しました。結果は、7ファイルのうち4ファイルが原本と一致、3ファイルが不一致でした。

不一致だった3ファイルは、いずれもGASツールのモール別バージョンで、ファイル名はどれも同じ「v1.2」でした。それぞれのZIP内ファイル数は43〜46本で、そのうち中身が違っていたのは各3〜4本、残りの40〜42本は一致していました。ZIP単位で見ると不一致でも、中身のファイル単位まで下りると、実際に違っていたのはごく一部です。

違っていたファイルはすべてスクリプト本体で、バッチ処理・順位取得・共通ロジックを担うファイルでした。配布側のファイル日付は2026-08-29、原本側のファイル日付は2026-07-03〜2026-08-19でした。つまり2026-08-29に配布側だけへ修正が入り、原本は古いまま、版番号「v1.2」も上げられていませんでした。

このまま放置すると、次に原本から配布ZIPを作り直した瞬間に、2026-08-29の修正だけが消えます。しかも版番号が同じ「v1.2」のままなので、購入者からも運営側からも、どちらの「v1.2」を持っているのかを区別する手立てがありません。

不一致を見つけたときの直し方の順序

ハッシュ値の突合で不一致が見つかった後の作業は、順番を決めておくと迷いません。

  • どちらが新しいかを、ファイルの更新日付と中身の差分の両方で判定する
  • 新しいと判定した側の内容を、正として原本フォルダへ反映する
  • 版番号を1つ上げる（同じ番号のまま配布を続けない）
  • 版番号を含む参照箇所をすべて更新する
  • 更新済みの原本から配布ZIPを作り直し、サイトへ反映する
  • 反映後に、原本と配布のハッシュ値を再度突合して一致を確認する

原本と配布のどちらか一方だけを「新しい」と決めつけないことも重要です。今回のケースでは配布側が新しく原本が古い状態でしたが、逆に原本側だけ直していて配布側への反映を忘れているケースも起こり得ます。日付と中身の両方を見て判定します。

旧版のファイルを削除せずに残す判断をした場合は、残す理由を記録しておきます。理由が記録されていないと、次に見る人が「消してよいものか」を毎回判断し直すことになります。

版番号とリンク切れ・旧版残留を防ぐ運用

ファイル名に版番号を入れて管理している場合、版を上げると更新が必要な箇所が複数あります。実際の配布ファイルでは、販売ページの原稿・教材本文の各パート・同梱物の一覧（マニフェスト）・ダウンロードページのリンクとラベルの4種類が対象になっています。

これとは別に、公開済みの販売記事本文は、販売プラットフォーム上で手作業で直す必要があります。原本のファイルだけを直しても、この参照箇所が古い版番号のまま残っていれば、購入者が見るページと実際の配布ファイルの版がずれます。

旧版のファイルがサーバー上に残り続ける問題も確認しています。配布フォルダには、ゲートページのリンク先である最新版v1.4とは別に、旧版であるv1.3のZIPも残っていました。リンク自体は最新版だけを指していますが、旧ファイルは削除されずにサーバー上に置かれたままでした。

リンクが最新版を指していれば、通常の購入導線では旧版は表に出ません。ただし、直接URLを知っている場合や検索エンジンに拾われた場合など、意図しない経路で旧版に到達する可能性は残ります。残す判断をするなら理由を、削除するなら削除したことを、それぞれ記録しておく必要があります。

自動化してよい範囲と人が判断する範囲

ここまでの作業のうち、機械的に自動化できる範囲と、人が判断すべき範囲は分けて考えます。

自動化できる範囲は次の3つです。

  • 原本フォルダと配布フォルダの全ファイルについて、SHA-256ハッシュ値を並べて突合すること
  • ハッシュ値が不一致だったZIPについて、中身をファイル単位まで比較し、どのファイルがどちらで新しいかを日付と差分で洗い出すこと
  • 版番号を含む参照箇所（販売ページ原稿・教材本文・同梱物一覧・ダウンロードページ）をキーワードで検索し、更新漏れの候補を一覧化すること

ZIPファイルは中身が同じでも、作り直しただけでハッシュ値が変わることがあります。ZIP単位の突合だけで「不一致=中身が違う」と判断せず、中身のファイル単位まで下りて比較する工程まで含めて自動化する必要があります。

一方で、次の3つは人が判断する範囲として残します。

  • 原本と配布のどちらを正として扱うか（新しい側の修正が本当に正しいかは、日付だけでは決まりません）
  • 版番号をどう付け替えるか（どの程度の修正で番号を上げるかの判断）
  • 購入者への告知が必要かどうか（すでに古い版を渡してしまった購入者がいる場合）

機械が担うのは「どこが違うか」を漏れなく見つけることまでです。「どちらが正しいか」「誰にどう伝えるか」は、商品の中身を理解している人が判断する部分として切り分けておきます。