公開したのは、本当に見せたいファイルだけ？

この記事の目次

AIと一緒に作ったテンプレートが完成しました。使い方の説明も書けた。あとはZIPにまとめて公開するだけです。

AIからは「公開用のファイルを作りました」と返ってきました。でも、その横には作業メモ、価格の下書き、テスト用のデータも置いてあります。

いま相手に届くのは、どのファイルでしょう。 手元のフォルダーがきれいでも、以前アップロードしたZIPが残っているかもしれません。反対に、必要な説明書が配布物に入っていないこともあります。

この記事は、AIで作ったサイト、資料、テンプレート、ZIPを初めて公開・販売する人に向けたものです。「注意して公開する」を、確かめられる小さな手順に変えていきます。

サイト・資料・ZIPを公開する前に**この箱に、届けたいものだけ入っている？**

作業フォルダーと、相手に届くものは別

作業する場所には、試行錯誤の途中のものも必要です。けれど、それをすべて届ける必要はありません。公開用には、見せると決めたものを選びます。

たとえば、説明書とサンプルだけを届けたいのに、フォルダー全体をZIPにすると、内部メモまで一緒に入ることがあります。Webサイトなら、公開対象のフォルダーやビルドの出力が、配信されるファイルの範囲を決めます。

作る場所と、届ける中身を分ける

作業用：4ファイル
説明書・サンプル・価格メモ・設定例がある。
試行錯誤の資料も置く場所
公開用：2ファイル
今回届ける説明書とサンプルだけを選ぶ。
guide.txt / sample.csv

本教材の架空例です。公開用フォルダーやZIPそのものを確認します。

AIへのお願いも、少し具体的にできます。

説明書とサンプルだけを公開用にまとめてください。作業メモと実データは含めません。含めたファイル名と、確認できていない点を教えてください。

ただし、返答は確認の出発点です。「含めていません」という説明だけで終えず、実際の公開用ファイルを自分でも確かめます。

箱に入れたものを、箱から確かめる

作業机を眺めるだけでは、箱の中は分かりません。公開するZIPや、実際に配信するフォルダーを確認対象にします。

入れてよいファイルから、公開用を作る

「いらないものを除く」方法は、知らないファイルが増えたときに見落とすことがあります。別の考え方として、入れてよいものを先に決める方法があります。allowlist（許可リスト）と呼ばれます。

次の例は、実際のフォルダーやZIPを操作しません。架空の4ファイルをメモリ上で用意して、公開用の2ファイルだけを選びます。本物のファイルを削除したり、外へ送ったりする処理はありません。

const workspace = new Map([
  ["guide.txt", "練習用ガイド"],
  ["sample.csv", "name\nExample"],
  ["pricing-notes.md", "架空の内部メモ"],
  [".env.example", "DEMO_ONLY"],
]);
const allowed = ["guide.txt", "sample.csv"];
function selectRelease(files, names) {
  if (names.some(name => !files.has(name))) {
    throw new Error("公開用ファイルが足りません");
  }
  return names.map(name => [name, files.get(name)]);
}
const release = selectRelease(workspace, allowed);
console.log("作業用:", workspace.size, "公開用:", release.length);
console.log(release.map(([name]) => name).join("\n"));

作業用: 4 公開用: 2
guide.txt
sample.csv

pricing-notes.mdは公開用に選ばれません。また、必要なguide.txtがなければ処理は止まります。「何かできた」だけでなく、「必要なものがそろった」ことも確認します。

必要なファイルを選び、足りなければ止める

含めるものを決める
説明書とサンプルを許可リストにする。
そろっているか確認
必要なファイルがなければ、公開用を作る処理を止める。
選んだ中身も読む
名前が正しくても、秘密や実データが入っていないか確かめる。

許可リストは範囲を絞る仕組みです。内容の安全性まで保証するものではありません。

許可リストも、安全の保証ではありません。guide.txtの中に本物の顧客名があれば、選んだファイルから漏れます。.env.exampleという名前でも、中身が本物のキーなら公開できません。ファイル名を選ぶ確認と、内容を読む確認は両方必要です。

販売用ZIPに、作業資料が混ざった報告

分類：事故の公表。 2026年10月22日公開のNeuralAlphaさんの配布ZIP確認の記事では、著者が自分の商品を購入して確認し、販売用ZIPに内部の作業資料が含まれていたと報告しています。

これは著者自身の報告であり、本教材がその販売物や漏えい範囲を独立に検証したものではありません。特定の販売サービス全体に同じ問題がある、という意味でもありません。

参考になるのは、作った側のフォルダーではなく、購入した側が受け取るファイルを確認したという点です。こちらの教材では、その視点を、販売に限らずサイト公開や資料配布にも使える形にしています。冒頭のテンプレートとコードは、本教材の架空例です。

自分の公開では、3つの視点で確かめる

一人の個人開発でも、確認する役割を切り替えます。自分が作り手だから知っている前提を、いったん外すためです。

作る人：何を含めると決めたか

公開するファイルの一覧を決め、サンプルデータは架空の内容にします。説明書のスクリーンショット、文書のコメントや変更履歴など、本文以外にも情報が残っていないかを見ます。必要なライセンス表示や利用条件も含めます。

AIに任せるなら、作業フォルダー全体をコピーする依頼より、含める範囲を明示する依頼にします。実際の作成方法は、使うビルド・圧縮・配布ツールの公式資料で確かめます。

公開する人：どのファイルを置いたか

アップロードしたファイル、対象の公開先、版を確認します。サイトなら、公開フォルダー・生成結果・デプロイ対象を見ます。たとえばGitHub Pagesでは、サイトを構成する静的ファイルが配信対象になります。GitHub公式：GitHub Pagesについて

更新時には、古い版や別の共有リンクも確認します。新しいZIPに差し替えたことと、以前のファイルへアクセスできないことは、別の確認です。

受け取る人：実際に何が届くか

自分の管理画面のプレビューだけでなく、利用者と同じリンクや権限で開きます。販売ならサービスが用意したテスト購入などを使い、不要な本番決済を避けます。

自分が作った配布物を受け取り、ファイル一覧と内容、説明書どおりに始められるかを確認します。サンプルを動かす場合も、まず設定やコードを読み、ダミー値で確かめます。不明な配布元の実行ファイルは開かず、自分の作った配布物で確認します。

最後は、受け取る人の入口から

作成した公開用ファイル
選んだ内容と、必要な説明がそろっているか。
アップロードした公開物
公開先・版・権限が合っているか。
利用者が受け取ったもの
利用者のリンクで開き、一覧と中身を確かめる。

管理画面のプレビューと、利用者が受け取る結果を分けて確認します。

名前と中身と公開先を、別々に確かめる

同じ名前のZIPでも、中身が同じとは限りません。また、中身が同じでも、それを公開してよいとは限りません。

3つの「合っている」を確かめる

範囲が合う
含めると決めた一覧と、実際のファイルが一致する。
内容が公開に適する
秘密・実データ・権利の問題がないか確認する。
届くものが合う
配布先から受け取り、意図した版か照合する。

同一性の照合だけでは、公開してよい内容かどうかまでは分かりません。

慣れてきたら、チェックサムなどでアップロード前後のファイルが同じか照合する方法もあります。ただし、同じであることは「安全な内容である」「配布元が信頼できる」という保証ではありません。誤って秘密を含めたファイルでも、そのままなら同じ値になります。

「届いた」と「見せていい」を分けよう

ファイルが届くこと、必要なものがそろうこと、公開してよい内容であること。どれか一つだけでは足りません。小さく分けると、AIに頼む確認も具体的になります。

公開前に、ここまで確かめる

含める範囲： 公開するファイルの一覧と実物を照らし、作業メモや実データが混ざっていないことを確認した。
内容： 設定値・文書の履歴・スクリーンショットを含め、秘密や個人情報、第三者の素材の扱いを確認した。
必要なもの： 説明書・サンプル・利用条件がそろい、説明どおりに始められることを確かめた。
配布経路： 公開先と版を確認し、利用者の入口から受け取ったものを見た。
更新時： 古い公開物と共有リンクの扱い、差し替え・停止の担当と手順を決めた。

見つかったときは、公開先と秘密を分けて対応

意図しないファイルが見つかったら、まず配布・公開を止める、または公開範囲を狭める手順を確認します。秘密のキーが含まれていた場合は、ファイルを差し替えるだけでは不十分です。発行元で失効・再発行し、利用履歴を確認します。

すでに誰かが受け取った写しまで回収できたとは限りません。配布先、公開期間、含まれた情報を、実際の値を再掲せずに整理します。個人情報や仕事の情報なら、関係する担当者へ連絡します。

詳しい初動は異常時の対応へ。問題が見つからなかったら、サービス全体の公開前チェックで、ログイン・料金・復旧も含めて確認しましょう。

一次資料と参考記事

情報確認日：2026年10月24日。公開範囲やテスト手順は、利用するサービスの公式資料で確認してください。

NeuralAlphaさん：配布ZIP確認の報告 — 著者自身による販売物の確認と改善の一次報告。事例の着想元であり、本文の架空例・図・演習は本教材用に作成しました。
GitHub公式：GitHub Pagesについて — 静的サイトとして配信されるファイルの仕組み。
GitHub公式：機密データをリポジトリから削除する — 認証情報の失効・再発行、公開後の写しへの注意。

書いた人