人に使ってもらう前に

バイブコーディングで作ったものは、必ず公開する必要はありません。自分だけで使うものに、公開操作や公開URLの確認は不要です。ただし、後で他の人に使ってもらう可能性があるなら、秘密情報、権限、入力範囲、戻し方を最初から分けておくと広げやすくなります。

まず、誰が使うかを決める

利用範囲	主に確認すること	目安
練習（継続利用しない）	目的どおり小さく動くか、要件外の機能が増えていないか	手元やプレビューだけで試す。
自分だけで使う（継続利用する）	秘密情報を外部へ送らないか、壊れたとき戻れるか、記録から再開できるか	あとで再開できる状態にする。公開手順や公開URLの確認は不要。
他の人に使ってもらう（特定の人）	説明、権限、入力、データ、エラー、外部操作、停止方法	相手が使い方と、問題が起きたときに止める方法を確認できる状態にする。
一般公開する	公開先・配布先、公開対象を特定する情報、その成果物で定めたQA（品質確認）、権利、停止・撤回	知らない人が使っても問題が起きにくい状態にする。

最初から分けておくもの

秘密情報と設定

APIキー、トークン、個人情報、内部資料を成果物へ直接書かず、必要な設定と分けます。

必要な権限

読む場所、書く場所、実行できる操作を必要な範囲だけにします。

入力と実行範囲

何を受け取り、何を変更し、どこへ送る可能性があるかを決めます。

データと記録

保存する内容、ログに残る内容、削除や再開に必要な記録を確認します。

エラー表示とログ

失敗理由は分かるようにし、秘密情報や内部パスは表示しません。

戻し方と停止方法

問題が起きたときに止める操作と、直前の状態へ戻す候補を用意します。

作ったものに合わせて追加する

成果物	追加して見るもの
ウェブサイト	リンク、スマホ表示、画像や引用の権利、404、アクセシビリティ
ウェブツール	ログイン、権限、入力値、データ分離、API、削除、バックアップ
スキル	読み書きするファイル、実行コマンド、外部送信、必要な前提、失敗時の扱い
エージェント	自動実行の範囲、外部サービス、確認が必要な操作、秘密情報、停止条件、ログ

ここからは、特定の人への共有と一般公開に共通する確認です。

他の人に使ってもらうなら

説明だけで安全と判断せず、成果物と実際の動きを確認します。分からない項目が残るなら、他の人へ渡さず自分用の検証に止めます。

入っている内容

• 個人情報、APIキー、トークン、内部資料名が入っていないか
• 画像、名前、会社名がある場合は、他の人に渡してよいものだけになっているか
• 元資料、下書き、開発用ファイルが成果物や配布物へ意図せず入っていないか
• AIが作った文章、設定、処理内容を確認したか

実際の表示・操作・実行結果

• 使い始める場所が分かり、画面または実行結果を確認できるか
• リンク、ボタン、コマンドなど主要な操作を試せるか
• 画面がある場合は、スマホ幅で文字や表がはみ出していないか
• エラーや権限がないときに、次の行動が分かるか

戻し方

• 直前に動いていた状態を保存したか
• 使うのを止める方法や、前の状態に戻す候補を確認したか
• 問題が起きたときに相談する人と、相談用メモの形を決めたか
• 修正履歴や作業記録を残したか

見ること	確認する理由
APIキーを直接書いていないか	見える場所に置くと、第三者に使われる可能性がある。
秘密情報を設定と分けているか	ブラウザで動くコードに含めた値は見えることがある。秘密APIキーはサーバー側やアクセス制御された場所で扱う。
ログインと権限を分けているか	ログインできることと、全部を見てよいことは別。
利用者ごとのデータが混ざらないか	他の人の情報が見える事故を防ぐ。
入力値を確認しているか	空欄、長すぎる文字、想定外の値で壊れるのを防ぐ。
エラー時に秘密情報が表示されないか	ログや画面に内部情報が出ることがある。
依存パッケージを確認したか	古い依存や危険な依存をそのまま使わない。
削除、バックアップ、問い合わせ先があるか	問題が起きたときに止めて戻りやすくする。

AIへの頼み方

最初に、利用範囲と作ったものの種類を伝えます。確認が終わるまで、修正、外部送信、公開操作を始めさせません。

人に使ってもらう前の確認をしてください。
まだ修正、外部送信、公開操作はしないでください。

- 利用範囲: 自分だけ / 特定の人 / 一般公開
- 作ったもの: ウェブサイト / ウェブツール / スキル / エージェント

確認してほしいこと:
- 秘密情報や内部情報が混ざっていないか
- 必要以上に広い権限や外部操作がないか
- 入力、保存、エラー、ログの扱いに危ない点がないか
- 初めて使う人に必要な説明があるか
- 問題があったときに止める方法と戻す候補があるか
- 権利とアクセシビリティを、作ったものと想定する利用者に応じて確認したか

作ったものに合う確認:
- ウェブサイト: リンク、スマホ表示、画面表示
- ウェブツール: 画面、入力、権限、データ
- スキル: 読み書きするファイル、実行コマンド
- エージェント: 自動実行、外部操作、停止条件

- 一般公開する場合だけ、公開先・配布先、公開する版、停止・撤回方法を確認したか

問題がある場所、理由、直し方を分けてください。

他の人に渡してよいか迷うときは、秘密情報を伏せた相談用メモを作ります。

他の人に渡してよいか迷っています。
秘密情報は伏せたまま、別の人やAIに相談するためのメモを作ってください。

含めるもの:
- 何を使ってもらいたいか
- 誰が使う想定か
- まだ不安なこと
- 確認済みのこと
- 伏せた情報の種類
- 次に判断してほしいこと

一般公開する場合

一般公開では、公開方法にかかわらず、公開先または配布先、公開対象を特定する情報、確認結果、公開後の実利用、停止・撤回方法をつなげて確認します。

公開先または配布先

誰がアクセスまたは入手できる場所か、意図した公開範囲になっているかを確認します。

公開対象と確認結果

公開対象を特定する情報のうち、該当するものを記録します。例えば、版番号、commit（変更を記録した番号）、release（公開・配布する版）です。その成果物で定めたテスト、QA（品質確認）、build（公開用ファイルの生成）、検証の結果も記録します。

実際に使えるか

公開後のURL、インストール方法、配布物のうち、該当するものを使い、説明どおりに開始できるか確認します。

公開範囲に合うか

権利、個人情報、秘密情報、アクセシビリティ、必要な説明が公開範囲に合っているか確認します。

止め方と戻し方

問題が起きたときの公開停止、配布停止、無効化、前版への復帰方法を確認します。

ウェブサイトやウェブツールでは公開URL、主要導線、スマホ表示、認証・データ、deployment（公開反映）の状態を追加で確認します。スキルやエージェントでは配布元、version（配布版）、導入手順、必要権限、外部操作、無効化・撤回方法を追加で確認します。

ウェブサイトやウェブツールの公開先はGitHub Pagesに限りません。Vercel、GitHub Pages、または別のホスティングサービスから、成果物と想定する利用者に合うものを選びます。スキルやエージェントは、成果物と想定する利用者に合う配布先・配布方法を選びます。

例: GitHub Pagesの場合

GitHub Pagesは一般公開方法の一例です。公開先としてGitHub Pagesを選んだ場合に、版、QA、公開先、公開停止をどのようにつなげるかを示します。

GitHub Pagesは、リポジトリの中にある静的なページを公開URLとして見せる仕組みです。この例では一般公開を前提にするため、公開されたページや公開リポジトリに入っている内容は、ほかの人から見えるものとして扱います。GitHub Enterprise Cloudの組織では、非公開または内部リポジトリから公開する一部のプロジェクトサイトにアクセス制御を設定できる例外があります。利用できる条件はGitHub公式の Changing the visibility of your GitHub Pages site で確認します。

初回だけ: 公開元を設定する

Astroなどビルドが必要なサイトでは、GitHub Pagesの公開元に GitHub Actions を使えます。最新の設定方法はGitHub公式ドキュメントで確認します。

この例の build と deploy は、ビルド役・公開反映役のjob名の例です。実際のjob IDはworkflowごとに異なるため、名前だけでなく jobs.<job_id> の定義と処理内容を確認します。job IDの書き方は、GitHub公式の Workflow syntax for GitHub Actions で確認できます。

1. 公開したいリポジトリと、公開対象のbranchを決める。公開ワークフローがどのbranchへのpushで開始するか確認する。
2. GitHub Pagesの公開設定で、公開元が GitHub Actions になっていることを確認する。
3. 公開ワークフローで、ビルドを行うjobと公開反映を行うjobを特定する。公開反映役がビルド役の成功後に動くことを確認する。job名はworkflowごとに異なり、build と deploy は例として扱う。
4. 公開URLに秘密情報を置かない。この例は一般公開の静的サイトを扱うため、アクセス制御された共有場所とは考えない。

公開元の選び方は、GitHub公式の Configuring a publishing source for your GitHub Pages site で最新の手順を確認します。

毎回: 8ステップで公開を確認する

「pushできた」「URLが開いた」のどちらか一方だけでは公開完了にしません。ローカル成果物、対象commit、Actionsのビルド役と公開反映役のjob、公開URLを1本の記録で結びます。

1. 公開内容を確認する。 個人情報、APIキー、トークン、内部資料、公開できない引用や画像が入っていないことを確認する。
2. 手元でQAする。 そのサイトで定めたQAコマンドを実行し、結果を記録する。コマンドは package.json や README で確認する。失敗したら公開へ進まない。
3. 公開するcommitを固定する。 変更をcommitしたら、git rev-parse HEAD などで完全な commit SHA を取得し、公開対象branchと一緒に記録する。
4. 意図したbranchへpushする。 push先が公開対象branchと一致することを確認する。別branchへpushしただけなら、公開対象の更新とは扱わない。
5. 対象runを特定する。 Actionsのrun履歴から、branchとcommit SHAが手順3の記録に一致するrunを開き、その run URL を記録する。run履歴とログの確認方法は、GitHub公式の Viewing workflow run history で最新の手順を確認する。
6. ビルド役のjob成功を確認する。 対象runでビルドを行うjob（例: build）が成功し、別branch・別commitのrunを見ていないことをもう一度確認する。
7. 公開反映役のjob成功を確認する。 同じ対象runで公開反映を行うjob（例: deploy）が成功し、GitHub Pagesへのdeploymentが作成されたことを確認する。ビルド役または公開反映役のどちらかが失敗・待機中なら公開完了にしない。
8. 公開URLを実際に確認する。 deploymentが示す公開URLを開き、トップページ、主要リンク、スマホ幅、存在しないURLからの404導線を確認する。最後に確認時刻を記録する。

公開記録は、少なくとも次の形で残します。

# 公開記録

- 公開対象branch: main
- commit SHA: 0123456789abcdef0123456789abcdef01234567
- run URL: https://github.com/OWNER/REPOSITORY/actions/runs/RUN_ID
- build: success
- deploy: success
- 公開URL: https://OWNER.github.io/REPOSITORY/
- 公開URLの確認時刻: 2026-07-10 15:30 JST
- 実際に確認したページ: トップ、主要リンク、404
- 未解決: なし

branch、commit SHA、run URL、公開URLが同じ公開作業を指していない場合は、証拠がつながっていません。正しい対象runを探し直します。

問題が出たら公開を止める

公開後に秘密情報、権利上の問題、重大な表示崩れなどを見つけたら、まず公開URL、commit SHA、発見時刻、問題の内容を記録します。そのうえで、管理権限を持つ人が GitHub Pages の現在のdeploymentに対して Unpublish を実行します。操作名や条件は、GitHub公式の Unpublishing a GitHub Pages site で最新の手順を確認します。

Unpublishは現在のdeploymentを取り除き、公開URLを利用できない状態にする操作です。リポジトリ、ファイル、既存の設定を削除する操作ではありません。また、原因を修正して新しいdeploymentを成功させると、サイトは再び公開されます。

公開停止だけで問題のある履歴や秘密情報が消えたとは考えません。秘密情報なら失効・再発行、履歴からの除去が必要かの判断、修正版のQAを別に行います。

関連ページ

• チェックリスト
• うまく動かなくなったときの戻し方
• 作業記録の残し方