安全管理
GitHubのpublicとprivateの違い
public repositoryとprivate repositoryの違い、共有範囲、秘密情報を入れない考え方を整理します。
このページでわかること
- publicとprivateで「誰に何が見えるか」の正確な違い
- どちらを選ぶべきかの判断基準
- privateでも秘密情報を直書きしてはいけない理由
- 後から公開範囲を変更する時の注意
最初に結論
publicは「世界中の誰でもコードと履歴を見られる」、privateは「自分と招待した人だけ見られる」設定です。迷ったらprivateで作るのが安全です。後からpublicに変えることはできますが、その時点で全履歴が公開されるため、「過去のcommitに秘密情報が混ざっていないか」を確認してからでないと危険です。公開は一方通行に近い操作だと考えてください。
private repositoryでも機密情報を入れてよいわけではありません
GitHubのprivate repositoryは公開範囲を限定できますが、APIキー、トークン、認証情報、顧客情報、未公開資料などを安全に保存する場所という意味ではありません。共有設定、権限、将来の公開、誤操作の可能性があるため、秘密情報はリポジトリ本文には入れない前提で考えるのが安全です。
- public / private の違いは公開範囲の違いであり、秘密情報の保存許可ではない
- コード、README、HTML、ログ、レポートにAPIキーやtokenの実値を書かない
- privateでも共有メンバー、外部連携、将来の公開変更を確認する
private repositoryの注意点 と Secrets・APIキーの注意 も合わせて確認してください。
初心者向け説明
重要な誤解が1つあります。「privateなら秘密情報を置いてよい」は間違いです。privateでも、collaboratorや連携ツール、将来の公開設定変更を通じて情報が見える可能性があります。APIキーやパスワードは、公開範囲に関係なくリポジトリに入れないのが原則です。また、GitHub Pagesでサイトを公開する場合、「サイトは公開・リポジトリはprivate」という組み合わせも可能で（プランによる）、ホームページ運営ではこの構成が実用的です。
向いている使い方
- 練習・学習用のリポジトリをprivateで気軽に作る
- サイトの公開はGitHub Pages、ソース管理はprivateで分ける
- 成果物を見せたい時だけ、履歴を確認した上でpublicにする
注意が必要な使い方
- 「とりあえずpublic」で作らない（迷ったらprivate）
- public化の前に全履歴の秘密情報チェックを行う
- privateでも秘密情報の直書きはしない
CodexやChatGPTと組み合わせる場合
CodexやClaude Codeに新しいリポジトリを作らせる時は、指示にpublic/privateの指定を明示してください。AI任せにすると意図しない公開設定で作られる可能性があります。既存リポジトリの公開範囲も、AI連携を始める前に一度確認しておくと安心です。
秘密情報・APIキー・パスワード・個人情報の注意
APIキー、パスワード、秘密鍵、FTP資格情報、DB情報、メール設定、個人情報は、HTML、README、ログ、レポート、GitHubの差分に出さない前提で扱います。
関連ページ
FAQ
GitHubのpublicとprivateの違いは初心者でも確認できますか？
はい。専門用語を覚える前に、何を確認すればよいかを優先して整理しています。
CodexやChatGPTを使う場合も同じ考え方ですか？
基本は同じです。自動化できる部分が増えても、差分確認、秘密情報確認、公開前確認は人間側で見ます。
秘密情報が混ざったかもしれない時はどうしますか？
commitやpushを急がず、対象ファイル、公開範囲、履歴への混入有無を確認します。必要に応じてキーやパスワードを無効化します。
GitHubの機能や画面は変わりますか？
変わる可能性があります。重要な判断や最新仕様はGitHub側の情報も確認してください。
このカテゴリの親ハブ
関連ページをまとめて確認する場合は、初心者ハブ から読み進められます。
選ぶ基準は「見せたいか」ではない
publicとprivateの選択は、見せたいかどうかではなく見られて困るものが入っているかで決めてください。
- 困るものが入っている — private。ただし、そもそも入れない方法を先に考える
- 困るものが無い — どちらでもよい。公開すると発見される機会が増えます
- 判断がつかない — private。判断できるまで公開しない
1番目の但し書きが重要です。認証情報を入れたままprivateにするより、入れない仕組みにするほうが安全です。公開範囲は最後の防御であって、最初の対策ではありません。
後から切り替える時に起きること
途中で変更する場合、方向によって影響が違います。
- public → private — 新しく見られることは防げますが、すでに複製された分は戻せません
- private → public — 履歴を含めて全部が公開されます。過去に入れて後から消した情報も辿れます
2番目が最も事故になりやすい操作です。公開へ切り替える前に、履歴の中に認証情報が含まれていないかを確認してください。今のファイルを見るだけでは足りません。
判断に迷った時の進め方
決めきれない場合、次の順で考えると整理できます。
- 入れる予定のものを書き出す — コード、設定、資料、画像
- その中に、外に出て困るものがあるか見る
- あるなら、それを外に置く方法を考える — 別の管理方法にできないか
- それでも入るなら private にする
3番目を飛ばさないでください。「privateだから入れてよい」と考えると、守るべきものが増え続けます。置かなくて済むものは、最初から置かないほうが管理が楽になります。
公開範囲の詳細は公開範囲のページ、全体像はprivateリポジトリのページで扱っています。
public / privateを選ぶ前に見るポイント
public repositoryは誰でも見られる前提、private repositoryはアクセスできる人が制限される前提です。ただしprivateでも安全が保証されるわけではないため、秘密情報を入れない考え方は同じです。
- publicは検索や共有に向くが、誰でも見られる
- privateは共有範囲を制限できるが、権限管理が必要
- どちらでもAPIキー、.env、ログ、バックアップは入れない
- 共有メンバーや外部連携の範囲を確認する
関連ページ
GitHubリポジトリの基本に戻る
public / private の違いを読む前に、リポジトリとは何か、README、branch、commit、Pull Request の関係を整理したい場合は、リポジトリの基本ページも参考にしてください。
GitHubは GPT → Codex → GitHub → GPT の流れで使うと分かりやすいです
CodexやAIを使って作業する場合でも、GitHubの公開範囲は人間が確認する必要があります。public にするか private にするかは、コードや資料に秘密情報が含まれないかを見てから判断します。
private repository・公開範囲・秘密情報の確認
GitHubでCodex作業やサイト管理を進める時は、private/public、見える人、Secrets、APIキー、GitHub Desktopでの差分確認をセットで見ます。private repositoryでも機密情報をそのまま保存してよいわけではありません。
GitHubリポジトリ全体から見る
このページの内容は、リポジトリ名、公開範囲、private/public、branch、Pull Request、Secrets、GitHub Desktop、Codex連携まで含めて確認すると安全です。
リポジトリ設定の全体像へ戻る
公開範囲、権限、branch、Secrets、Pages、Danger Zoneは、単独ではなくリポジトリ全体の設定として見ます。
GitHub Desktopで差分を見る流れへ戻る
Codex作業後は、報告書だけで判断せず、GitHub DesktopのChangesとDiffを確認してからcommitやpushを判断します。
AI時代のGitHubセキュリティ確認
AIコーディング後は、Secrets、APIキー、.env、PR、diff、private repositoryの扱いを確認します。
AI時代のGitHub Secrets実用チェック
Claude Mythos / ミュトスのようにAIの能力が話題になるほど、GitHubではSecrets、private repository、PR確認を厚く見る必要があります。private repositoryでも秘密情報を直書きしない前提で確認します。
| 場所 | 注意点 | 人間が確認すること |
|---|---|---|
| public repository | 公開前提で扱う | Secrets実値、.env、ログ、設定ファイル |
| private repository | 非公開でも秘密情報直書きは避ける | 権限、履歴、PR、共有範囲 |
| GitHub Secrets | 値をAIに見せない | 名前、利用範囲、漏えい時の無効化 |
| AIコーディング | 意図しないファイル変更に注意 | PR、diff、main直push回避 |
- Secrets実値をcommitしていない。
- .envをcommitしていない。
- private repositoryだから安全と思い込んでいない。
- AIが意図しないファイルを触っていない。
- main直pushしていない。
攻撃方法ではなく防御確認として扱う
この補足は攻撃方法ではなく、防御・公開前チェック・Secrets管理の確認です。AIに脆弱性悪用手順を聞かない、攻撃コードを書かせない、APIキーやtoken、Secrets、.env、DB情報を渡さない、という前提で扱います。
GitHub private の公開範囲はどこまで見える？
private repository は、基本的に権限を持つユーザーだけが見られるリポジトリとして扱います。ただし、招待したメンバー、Organization、連携アプリ、GitHub Actions、Secrets、外部AIツールなど、見える範囲や使える範囲は設定によって変わります。
private だから何を置いても安全、とは考えません。APIキー、token、.env、DB接続情報、GitHub Secrets実値はリポジトリに直書きせず、AIやCodex、GitHub Copilotに見せる範囲も別に確認します。
| 種類 | 誰が見られるか | 注意すること | 秘密情報の扱い | AIに見せる時の注意 |
|---|---|---|---|---|
| Public repository | 公開されている範囲で誰でも見られる | 公開前提で差分を見る | 絶対に直書きしない | 公開情報だけを前提にする |
| Private repository | 権限を持つ人が見られる | メンバー、連携、将来の公開変更に注意 | 直書きしない | AIへ見せる前に実値を伏せる |
| Organization repository | 組織設定と権限による | チーム権限と外部連携を確認 | Secrets実値をREADMEへ書かない | 会社情報や顧客情報を分ける |
| Fork | 元リポジトリと設定に注意 | 公開範囲や履歴の扱いを確認 | 秘密情報を含めない | 不要な履歴を渡さない |
| GitHub Pages | 公開サイトとして見える可能性がある | HTMLや画像の公開状態を確認 | 設定値を埋め込まない | 公開してよい内容だけにする |
| GitHub Actions | ワークフローと権限による | ログや権限を確認 | Secretsは実値をログへ出さない | AIにログ全文を貼らない |
| GitHub Secrets | 値そのものは見せない前提で扱う | 名前、利用範囲、漏えい時の無効化を確認 | 実値を本文に出さない | 相談時はダミー値に置き換える |
Private repositoryでも機密情報を直書きしない
- private でもメンバーや連携設定次第で見える範囲が広がります。
- 誤ってpublicに変更するリスクもあります。
- GitHub Copilot、Codex、外部AIツールにコードを見せる時は秘密情報を伏せます。
- Secretsは実値を本文、README、HTML、スクリーンショットに書きません。
- .envやDB接続情報をcommitしません。
GitHubはバックアップなのかを整理する
GitHubは単なるバックアップではなく、diff、PR確認、rollbackに強い変更履歴つきコード図書館として考えると、Codex作業やAIサイト群の安全管理につながります。
GitHubの公開範囲で検索した人が最初に見ること
GitHubの公開範囲を確認する時は、public か private かだけで判断しない方が安全です。誰が見られるか、誰が変更できるか、どのファイルが含まれるか、AIや外部連携にどこまで見せるかをセットで確認します。
- public / private の選択が目的に合っている
- 共有メンバー、Organization、外部連携の範囲を確認している
- README、HTML、ログ、バックアップに機密情報を書いていない
- APIキー、トークン、パスワード、秘密鍵、
.env、DB情報を含めていない - CodexやAIで作業した後に、差分とPull Requestを人間が確認している
公開範囲に迷う場合は、まず リポジトリの基本、private repositoryの注意、SecretsやAPIキーの注意 を順番に確認してください。
GitHubのprivate repositoryなら機密情報を保存しても大丈夫ですか？
private repositoryでも、共有メンバー、権限、外部連携、履歴、将来の公開変更の影響があります。APIキー、パスワード、秘密鍵、.env、DB情報、顧客情報などは入れない前提で管理する方が安全です。
GitHubの公開範囲はどこを確認すればよいですか？
public / private の設定だけでなく、共有メンバー、Organization、外部連携、Pull Request、Actionsログ、含まれているファイルを確認します。公開してよい内容かどうかは、ファイル単位でも見る必要があります。
public にする前に最低限見ることは何ですか？
APIキー、トークン、パスワード、秘密鍵、.env、DB接続情報、個人情報、顧客情報、ログ、バックアップが含まれていないかを確認します。不安がある時は、公開前に 秘密情報チェックの基本 も確認します。
GitHub Copilot・AI credits・CLI作業の確認導線
private repoでも、AIに認証情報を渡したりrepoへ秘密情報を入れたりしてよいわけではありません。
publicとprivateの違いを初心者向けに整理
github private public 違い、github 公開範囲の検索意図に合わせて、public repositoryとprivate repositoryを、見える人、共同編集、秘密情報の扱いで比較します。
このページでできること
- publicは公開される前提、privateはアクセス権を持つ人に絞る前提で考えます。
- privateでも、招待した人、チーム、組織管理者などが見られる場合があります。
- 秘密情報の保存場所としてprivate repositoryを使うのではなく、Secretsや外部の安全な管理方法を確認します。
| 項目 | 見ること | 初心者の注意点 |
|---|---|---|
| Public | 公開前提のコードやドキュメント | 検索、fork、clone、権利表示に注意 |
| Private | 公開範囲を絞った作業 | 権限者には見える。秘密情報は直接置かない |
| 変更時 | public/privateの切替 | fork、Pages、Actions、外部連携の影響確認 |
commit前・公開前チェックリスト
- publicにしてよい内容だけが入っているか
- privateにしても見える人を確認したか
- READMEや履歴に秘密情報がないか
- 公開範囲変更前にバックアップと影響範囲を確認したか
公式情報で確認すること
公開範囲、権限、Secrets、GitHub Desktop、Copilot関連の仕様や制限は変わる可能性があります。2026年6月11日確認の公開情報を確認し、このページでは固定仕様として断定しません。