AIサイトガイド
GitHub Secrets

GitHubでCodex作業をする時のSecrets管理

GitHubとCodexを組み合わせると、repoの修正、PR、レビュー、公開作業をまとめやすくなります。ただし、SecretsをrepoやPRに置かない設計が前提です。

GitHubに置かない情報

GitHub token、APIキー、SSH鍵、秘密鍵、.env、DB接続情報、FTP情報、Basic認証、管理画面ログイン、顧客情報、SQL dump、ログは、repo本文やPR本文に置きません。

private repoの注意

private repoは公開範囲を狭めますが、Secrets保管場所ではありません。共同編集者、連携アプリ、Actionsログ、フォーク、バックアップ、履歴に残る可能性を考えます。

.envと.example

.envの実ファイルはコミットしません。共有するなら、値を入れない.example形式で、必要な項目名と説明だけにします。gitignoreに入れるだけでなく、過去コミットに入っていないかも確認します。

Actions Secretsの使いどころ

GitHub Actionsで必要な値は、PR本文やワークフロー内に直書きせず、Secretsや環境側で扱います。ログに値が出ないようにし、必要以上の権限を持たせません。

push protectionとsecret scanning

GitHubには秘密情報の混入を検知する仕組みがあります。ただし検知に頼り切らず、コミット前に自分で差分と添付内容を確認します。検知された場合は、作業を止めて値の無効化や再発行を検討します。

Codexへの依頼文

Codexには、実値ではなくファイル名、環境変数名、役割、期待動作だけを伝えます。たとえば「Secretsに登録済みの値を参照する前提でワークフローを確認して」と表現します。

関連ページ

確認した公式情報

このページは公式ページではありません。最新仕様、install方法、料金、使用上限は必ず公式情報で確認してください。

FAQ

Codexに本物のAPIキーを貼ってもいいですか?

貼りません。必要な場合でも実値は伏せ、環境変数やSecretsに入っている前提だけを伝えます。

private repoならSecretsを置いても安全ですか?

private repoでも安全とは決めません。権限、履歴、Actionsログ、バックアップ、連携アプリまで確認が必要です。

すでに貼ってしまったら削除だけで十分ですか?

削除だけで十分とは限りません。作業を止め、関係者確認、再発行やローテーション、履歴やログの確認を行います。

記事内に例を出すときはどうしますか?

実在しそうな値は出さず、dummy-valueやexample-nameのような無効な表現にします。