GitHubを使い始める前に、危険がないか知っておきたい人。すでに使っていて、公開してよいか不安な人。プログラミングの知識は必要ありません。ブラウザの操作だけで進めます。ローカルのgitを使う部分は、コマンドと実際の出力を載せています。
「GitHubは安全？」「自分のファイルが他の人に見られない？」「間違えて変なものを上げたらどうなる？」
GitHubを使うときに気をつけるのは、主に3つです。アカウントを乗っ取られないこと。公開リポジトリに、パスワードやAPIキーなどの秘密の情報を入れないこと。公開と非公開を取り違えないこと。
とくに2つ目は、間違えて上げてしまうと、ファイルを消しただけでは取り返せません。ここでは、実際にファイルを上げて消し、履歴に残る様子を画面で見ます。GitHubが秘密の情報を止める画面や、上げてしまったキーを無効にする画面も、順に開きます。最後に、公開する前のチェックリストを付けました。
GitHubの危険性と守り方の早見表
| 危険 | 確かめた画面 | 守り方 |
|---|---|---|
| アカウントを乗っ取られる | 設定の「Password and authentication」に、二段階認証が「not enabled yet」と出る（手順2） | 二段階認証を設定する |
| 秘密の情報を公開してしまう | ファイルを消しても、消す前の変更に中身が残る（手順3） | 公開リポジトリには入れない。上げたときは、発行元で無効にする（手順5） |
| 公開設定を間違える | 公開はログインなしで中身が見え、非公開は「404」になる（手順1） | 公開する前に、中身を見直す。迷うなら非公開にする |
手順1 公開と非公開で誰に見えるか
リポジトリには、公開（Public）と非公開（Private）があります。ログインしていない人にどう見えるかを、同じリポジトリで比べます。
試験用リポジトリ「secret-test」を公開で作り（作り方はリポジトリの作り方）、ログインしていないブラウザでアドレスを開きました。右上に「Sign in」「Sign up」が出ていて、ログインしていない状態です。名前の横に「Public」と出て、ファイルの一覧も、READMEの中身も見えます。
リポジトリのトップの上の行にある「Settings」を押します。
Settingsの画面を一番下まで進めると、「Danger Zone」があります。一番上の行が「Change repository visibility」（公開の設定を変える）で、「This repository is currently public.」と出ています。右の「Change visibility」を押します。
「Change to private」と出るので押します。
確認の窓が3回出ます。1回目は、リポジトリ名と、星（0 stars）とウォッチ（0 watchers）の数が出て、「I want to make this repository private」のボタンがあります。
2回目は、影響の説明です。「Any custom Dependabot alert rules will be disabled unless GitHub Advanced Security is enabled for this repository.」「Current forks will remain public and will be detached from this repository.」「Advanced Security will be disabled.」の3つが出ます。「I have read and understand these effects」を押します。
3回目は、赤い文字の「Make this repository private」です。星とウォッチが0のこのリポジトリでは、入力欄は出ませんでした。押すと、非公開に切り替わります。
切り替えたあとにログイン中のブラウザで開くと、リポジトリ名の横に鍵の印が付いて、「Private」の表示も出ました。
同じアドレスを、ログインしていないブラウザで開きます。ファイルの一覧は出ず、「404」と「This is not the web page you are looking for.」（探しているページではありません）だけが出ました。
公開のままなら、ログインしていない人にも中身が見えます。非公開に切り替えると、見えなくなりました。見せたくないファイルが入っているなら、公開する前にリポジトリの中身を見直してください。
無料プランの範囲は、GitHubは無料で使える？で、料金ページの画面で確かめています。
手順2 アカウントを守る
アカウントを乗っ取られると、自分の名前でコードや設定を書き換えられてしまいます。守るための設定が、二段階認証です。設定の画面を開いて、現状を確かめます。
画面の右上の丸いアイコンを押しメニューの「Settings」を選びます。
設定の画面が開きます。左のメニューの「Access」の下に、「Password and authentication」があります。押します。
「Sign in methods」（ログインの方法）には、「Email」「Password」「Passkeys」「Google」「Apple」の5つが並びます。「Passkeys」の説明は「Passwordless sign-in with biometrics or security keys」（生体認証やセキュリティキーでの、パスワードなしのログイン）です。
その下の「Two-factor authentication」には、「Two-factor authentication is not enabled yet.」と出ています。説明には「Two-factor authentication adds an additional layer of security to your account by requiring more than just a password to sign in.」とあります。ログインにパスワードだけでなく、もう1つの確認を求めて、安全を1段高める仕組み、という意味です。
緑の「Enable two-factor authentication」を押すと、設定の画面が開きます。上に、1・2・3の3つの段階が並びます。
最初の段階は「Setup authenticator app」で、認証アプリでQRコードを読み取り、アプリに出たコードを入れます。入力欄には「XXXXXX」と例が出ています。QRコードは、画像では隠しています。下の「Alternative 2FA option」（別の方法）には、「SMS authentication」があり、携帯のショートメッセージでコードを受け取る方法です。
ここでは先へ進まず、設定の画面に戻りました。「Two-factor authentication is not enabled yet.」の表示は、そのままです。設定の手順は、別の記事（公開予定）で、続きの画面まで説明します。
手順3 秘密の情報を上げて消してみる
公開リポジトリに入れてはいけないのは、APIキーやパスワードなどの秘密の情報です。うっかり上げて、すぐに消したらどうなるのかを、試験用のリポジトリで試しました。上げた文字列は、本物ではない「API_KEY=dummy-key-1234567890」です。
リポジトリのトップで、「Code」の左の「+」を押し、「Create new file」を選びます。次の2枚は、別のリポジトリ（practice-third）で同じ操作をした画面です。
ファイル名の欄が開きます。
ファイル名に「.env」、中身に「API_KEY=dummy-key-1234567890」と入れて、右上の「Commit changes…」を押します。コミットの窓が開くので、「Commit changes」を押します。
リポジトリのトップに戻ると「.env」が増えています。
「.env」を開き右上の「…」を押します。
メニューの一番下の「Delete file」を選びます。
削除の画面が開き、「This file was deleted.」（このファイルは削除されました）と出ます。右上の「Commit changes…」を押します。
コミットの窓で、メッセージは「Delete .env」になっています。「Commit changes」を押します。
トップに戻ると、「.env」はなくなり、「README.md」だけが残っています。コミットの数は「3 Commits」に増えました。
「3 Commits」を押すと、コミットの履歴が開きます。「Delete .env」の下に、「Add API_KEY to .env file」と「Initial commit」が並んでいます。
「Add API_KEY to .env file」を開きます。
消したはずの「API_KEY=dummy-key-1234567890」が、緑の行で見えます。ファイルを消しても、ファイルを足した時点の変更が、履歴に残っています。ファイルを消しただけでは、秘密の情報は取り返せません。
本物のキーを上げたときは消したあとでも履歴に残っているものとして扱います。
手順4 GitHubが止めてくれる仕組みを見る
GitHubには、秘密の情報を上げる前に止める仕組みがあります。設定の画面と、実際に止まる画面を見ます。
設定の左のメニューを下へ進めると、「Security」の下に「Code security」があり、一番下には「Developer settings」があります（手順5で使います）。「Code security」を開きます。
「User」の欄に、「Push protection for yourself」があります。
説明は「Block commits that contain supported secrets across all public repositories on GitHub.」です。GitHub上のすべての公開リポジトリで、対応している秘密の情報を含むコミットを止める、という意味です。右のボタンは「Disable」（無効にする）と出ています。
公開リポジトリ（my-first-repo）の画面で、上の行の「Settings」を押し、左のメニューの「Advanced Security」を開きます。
画面を一番下まで進めます。
「Secret Protection」の説明は「Continuously monitor this repository to prevent secret exposures and protect credentials.」（秘密の情報の流出を防ぐため、このリポジトリを監視し続けます）です。「Push protection」は「On」で、説明は「Block pushes that contain supported secrets.」（対応している秘密の情報を含む送信を止めます）です。
非公開に切り替えた試験用リポジトリの、同じ「Advanced Security」の画面には、「Secret Protection」の欄は出ていませんでした。
実際に止まるかを試します。公開の試験用リポジトリで、手順3-1と同じ操作（「+」から「Create new file」）で、新しいファイル「config.txt」を作り、Stripeのキーの形をした、本物ではない文字列を入れました。「Commit changes…」を押し、コミットの窓で「Commit changes」を押します。
コミットは進まず「Secret scanning」の窓が開きました。
赤い帯には「Secret scanning found a Stripe API Key secret on line 1.」（1行目に、StripeのAPIキーが見つかりました）と出ています。窓には、秘密の情報が漏れるとできてしまうことが、4つ並びます。
- Verify the identity of this Stripe API Key secret（このキーの持ち主を確かめられる）
- Know which resources this secret can access（このキーで入れるものが分かる）
- Act on behalf of the secret’s owner（持ち主になりすませる）
- Push this secret to this repository without being blocked（止められずに、このリポジトリに送れる）
窓の下には、3つの選択肢が並びます。「It’s used in tests」（テストで使っている）、「It’s a false positive」（誤検知）、「I’ll fix it later」（あとで直す）です。選択肢の下には、説明も出ています。「It’s used in tests」には「The secret poses no risk. If anyone finds it, they cannot do any damage or gain access to sensitive information.」（このキーに危険はなく、見つかっても被害は出ない）。「I’ll fix it later」には「The secret is real, I understand the risk, and I will need to revoke it. This will open a security alert and notify admins of this repository.」（キーは本物で、危険を理解したうえで、あとで無効にする。セキュリティの警告が開き、このリポジトリの管理者に通知される）とあります。「Allow Secret」のボタンは、薄い色のままでした。どれも選ばずに「Cancel」を押しました。試験用リポジトリには「config.txt」が追加されず、コミットは「3 Commits」のままです（手順1-2の画像）。
手順5 上げてしまったキーを無効にする
本物のキーを上げてしまったときは、履歴に残るため、消すだけでは足りません。そのキーを発行したサービスの画面で、キーを無効にします。GitHubのトークンを例に、無効にする画面を見ます。ここで作るトークンは、試すためのものです。
設定の左のメニューの一番下の「Developer settings」（手順4-1の画像の②）を開き、左のメニューの「Personal access tokens」の「Tokens (classic)」を開きます。まだ作っていないので、「No personal access token created」と出ます。
「Generate new token」を押すと、2つ出ます。「Generate new token」（Fine-grained, repo-scoped）と、「Generate new token (classic)」（For general use）です。classicを選びます。
「Note」にトークンの名前、「Expiration」に期限を入れます。名前は「test-token-delete-me」にしました。
期限は、「7 days」「30 days」「60 days」「90 days」「Custom」「No expiration」から選べます。「7 days」を選びました。
「Select scopes」で、トークンにできることを選びます。「notifications」にチェックを付けて、一番下の「Generate token」を押します。
トークンができました。「Make sure to copy your personal access token now. You won’t be able to see it again!」（いまコピーしてください。もう一度は見られません）と出ます。トークンの文字列は、画像では隠しています。右の「Delete」が、無効にするボタンです。
「Delete」を押します。確認の窓が出ます。
窓には「Any applications or scripts using this token will no longer be able to access the GitHub API. You cannot undo this action.」とあります。このトークンを使っているアプリやスクリプトは、GitHub APIに入れなくなり、元には戻せない、という意味です。キーを無効にすると、そのキーを使っているものが止まることがあります。「I understand, delete this token」を押します。
トークンの行がなくなりました。上げてしまったキーを無効にする流れは、このとおり、発行元の画面で、そのキーを削除する形です。
手順6 .gitignoreで手元だけに置く
手元に置きたいファイル（.envなど）は、「.gitignore」というファイルに書くと、Gitが無視します。リポジトリを作る画面（開き方はリポジトリの作り方）にも、この設定があります。
説明は「.gitignore tells git which files not to track.」（どのファイルを管理しないかをgitに伝えます）です。ボタンを押すと、言語やツールごとのひな形の一覧が出ます。
実際の動きを、自分のパソコンのgitで確かめました。空のフォルダで「git init」をしたあと、「.env」と「README.md」を作った状態です。出力は、実際に出たものです。改行コードに関する警告の行は、省いています。
$ git status --short
?? .env
?? README.md「.env」が、まだ管理されていないファイル（先頭の「??」）として出ます。ここで、「.gitignore」に「.env」と書きます。
$ printf ".env\n" > .gitignore
$ git status --short
?? .gitignore
?? README.md
$ git check-ignore -v .env
.gitignore:1:.env .env「.env」が、一覧から消えました。「git check-ignore -v .env」で、「.gitignore」の1行目の「.env」で無視されている、と確かめられます。コミットしたあとのファイル一覧にも、「.env」は入りません。
$ git add .
$ git commit -m first
$ git ls-files
.gitignore
README.md先に「.env」をコミットしてから「.gitignore」に書いた場合は、効きません。別のフォルダ（「.env」だけを作ったフォルダ）で試すと、「.env」を書き換えたとき、「M」（変更あり）と出ました。
$ git status --short
M .env
?? .gitignoreすでに管理されているファイルは、「git rm –cached .env」で管理から外します。実行すると、「.env」は「D」（管理から外れる）に変わりました。フォルダの中身を見ると、「.env」は手元に残っています。
$ git rm --cached .env
$ git status --short
D .env
?? .gitignore
$ ls -a
.
..
.env
.git
.gitignoreただし、すでにGitHubに上げたあとなら、履歴には残っています（手順3）。上げる前に、「.gitignore」に書いておくことが大切です。
公開する前のチェックリスト
リポジトリを公開にする前に、次の項目を確かめます。印刷して使えます。
- アカウントに二段階認証を設定した
- パスワードを他のサービスと使い回していない
- 公開するリポジトリのファイルを1つずつ見直した
- コードや設定ファイルにAPIキー・パスワード・トークンが書かれていない
- .envなど手元だけに置くファイルは上げる前に.gitignoreに入れた
- READMEなどの説明に本物のキーを例として書いていない
- IssueやコメントなどにAPIキーを貼っていない
- 迷うものは公開せず非公開のままにした
- 非公開のリポジトリは見せる相手を確認した
- キーを上げてしまったら消すだけでなく発行元で無効にする
よくある質問
GitHubに置いたファイルは他の人に見られますか
公開リポジトリは、ログインしていない人にも見えました。非公開に切り替えたリポジトリは、ログインしていない人には「404」が出て、見えませんでした（手順1）。作るときに、どちらかを選びます。
間違えて上げたファイルをすぐ消せば安全ですか
安全とはいえません。ファイルを消しても、上げた時点のコミットを開くと、中身が見えました（手順3）。上げてしまったキーは、発行元で無効にします（手順5）。
秘密の情報を上げようとしたら止めてもらえますか
公開リポジトリでは、「Push protection」が「On」で、偽のStripeのキーを上げようとしたとき、コミットの途中で止まりました（手順4）。非公開に切り替えた試験用リポジトリの「Advanced Security」には、「Secret Protection」の欄が出ていませんでした。止めてもらえることを前提にせず、上げる前に自分で確かめます。
ChatGPTやClaude Codeで作ったコードをGitHubに上げるとき、気をつけることはありますか
コードの中に、APIキーやパスワードが直接書かれていないかを、上げる前に確かめます。この記事のチェックリストが使えます。
他の人が公開しているコードはダウンロードして使っても安全ですか
公開リポジトリのトップには、ファイルの一覧と、コミットの数、最後に更新された時刻が出ます（手順1の画像）。使う前に、ファイルの中身を自分で読んで確かめることが大切です。
次に知りたいこと
- GitHubが何かを知りたい → GitHubとは？何ができるのかを画面つきでわかりやすく解説
- 無料の範囲を知りたい → GitHubは無料で使える？
- アカウントを作りたい → GitHubアカウントの作り方【画像つき】登録からログイン確認まで
- 二段階認証を設定したい → GitHubの二段階認証の設定方法【画像つき】パソコンだけで認証アプリを使う手順
