このページで整理すること
- private repositoryとは
- privateでも秘密情報を入れない
- Secrets、APIキー、.envの注意
- 公開範囲と権限
- githubguide.jpで詳しく確認する
Codexでできること
Codexは、GitHub作業で確認したい観点を整理したり、PRやdiffを見る時のチェックリストを作ったり、release noteを読む時の確認項目を並べたりする補助に使えます。どのrepoを対象にするか、どのファイルを触るか、どのファイルを触らないかを文章にしてから渡すと、作業範囲が明確になります。
Codexだけに任せないこと
CodexがGitHubを何でも自動操作できるとは考えません。PRのマージ、releaseの採用、private/publicの判断、Secretsや.envの扱い、公式情報の確認は人間が行います。特に認証情報やトークンを貼り付けて相談する使い方は避けてください。
GitHubで確認すること
GitHubでは、repository、branch、diff、PR、release、private/public、Secretsの扱いを分けて見ます。Codexの報告だけで終わらせず、GitHub上の差分と公開範囲を確認してから次の作業に進みます。
privateにしても守られないもの
リポジトリをprivateにすると安心しがちですが、privateが守るのは「第三者が見にいけないこと」だけです。次のものは守られません。
| 対象 | privateで守られるか | 理由 |
|---|---|---|
| 第三者からの閲覧 | 守られる | これがprivateの本来の役割 |
| 誤ってpublicに変えた場合 | 守られない | 設定を戻しても、その間に取得された可能性は消えない |
| 認証情報を書き込んだ履歴 | 守られない | publicに変わった瞬間に履歴ごと公開される |
| アクセス権を渡した相手 | 守られない | 招待した相手には全履歴が見える |
| 誤って別の場所へコピーした場合 | 守られない | コピー先の公開設定に依存する |
つまり、privateは「うっかり公開した時の保険」にはなりません。認証情報は、privateであっても最初からファイルに書かない運用が必要です。一度履歴に入ると、後からファイルを消しても履歴には残り続けます。
publicとprivateの選び方
どちらにするかは、中身の性質で決めます。迷った時の基準を整理します。
- 公開サイトのHTMLやCSS：どのみち公開されている内容なので、publicでも実害は少ない。ただし作業途中の下書きが混ざるならprivateが無難です。
- 業務や顧客に関わるもの：private一択です。契約上の制約がある場合もあります。
- 設定ファイルや運用手順：サーバー構成が推測できる情報を含むため、privateが安全です。
- 迷った場合：privateで始めます。後からpublicへ変えるのは簡単ですが、逆は取り返しがつきません。
最後の項目が実務的な原則です。公開は一方通行だと考えてください。publicにした時点で、内容が取得されている可能性が生まれ、privateに戻してもその事実は変わりません。
秘密情報・公開範囲の注意
private repositoryでも秘密情報を入れてよいわけではありません。APIキー、トークン、SSHキー、.env、顧客情報、社内情報、サーバーパス、認証情報は公開・共有前に伏せます。GitHub公式ロゴ、Octocat、公式画像もこのページ群では使いません。
関連ページ
FAQ
CodexにGitHubのトークンを貼ってもいいですか？
貼らないでください。Personal Access Token、APIキー、Secret、SSHキー、認証情報はCodexに入力しない方が安全です。
private repositoryなら秘密情報を入れても安全ですか？
いいえ。privateでも共有範囲や権限、履歴、誤公開のリスクがあります。Secretsや.envの中身をそのまま置かないよう確認します。
CodexだけでPRをレビューできますか？
Codexは確認観点の整理に使えますが、最終レビューやマージ判断は人間が行います。