このページでわかること
private repoでCodexを使う前に確認する、権限、Secrets、社内情報、ログ出力、PR差分の注意点がわかります。
結論
CodexにGitHub実務を任せる時は、対象repo、branch、差分、Secrets、CI、PR本文を分けて確認します。main直push、危険操作、テスト無効化、private repoなら安全という考え方は避けます。
対象読者
CodexでGitHubのIssue、PR、レビュー、CI、branch、private repo、READMEやrelease noteを扱いたい人向けです。
Codexに任せやすいこと
危険語の抽出、差分確認、Secrets候補の洗い出し、報告書で伏せる情報の整理。
人間が確認すべきこと
APIキー、token、.env、SSH鍵、DB情報、顧客情報、未公開仕様が混ざっていないか。
GitHub作業での注意点
private repoは非公開でも、AIに渡す情報、CIログ、PR差分、権限範囲を分けて確認します。
やってはいけないこと
危険コマンド、force pushの安易な推奨、テスト無効化、Secretsやtokenのログ出力、社内コードや顧客情報の入力推奨は避けます。
STOP条件
Secretsが必要、権限変更が必要、顧客情報を扱う必要がある、ログに秘密情報が出た場合。
非公開でも、置いてよいものとよくないものがある
非公開の置き場だから何を入れてもよい、とはなりません。非公開が守るのは「誰が見られるか」であって、「その情報を持つ危険」ではありません。
| 非公開で守れること | 関係者以外がその場で読むこと |
|---|---|
| 非公開でも守れないこと | 公開範囲を後で変えたとき / 権限を持つ人が増えたとき / 記録に残った過去の内容 |
3つ目がとくに見落とされます。入れてしまったものは、後から消しても記録には残ります。「間違えて入れたので消した」では戻りません。だから入れる前に止めるしかありません。
接続情報や鍵の類は、記録に入れずに外側から渡す形にしてください。実行するときにだけ与える方式なら、記録には残りません。
認証情報を扱うときの実務
作業の道具が接続情報を必要とする場面は避けられません。扱い方を決めておけば、記録に残さずに済みます。
- 置き場所を1か所に決める。作業用のファイルの外に置き、そこから読ませます。あちこちに複製しない
- 実行するときにだけ渡す。その場限りの受け渡しにすれば、ファイルにも記録にも残りません
- 画面に出さない。確認のつもりで表示すると、作業ログに残ります
- 使い捨ての道具にも同じ規則を適用する。「1回だけだから」と直接書いたものが、まとめて記録に加えられて混ざります
4つ目が実際にいちばん起きます。本番用の道具より、その場で書いた検証用の処理のほうが危険です。規則を適用する対象から外れやすいためです。使い捨ての道具こそ、書き始める前に置き場所の規則を思い出してください。
FAQ
private repoなら安全ですか？
そうとは限りません。Secrets、権限、ログ、差分を確認します。
APIキーを貼ってよいですか？
貼りません。例としても入れない方が安全です。
社内コードは扱えますか？
権限とルールが必要です。機密情報を渡す前提にはしません。
PR差分では何を見ますか？
秘密情報、不要ファイル、権限変更、ログ出力を確認します。