Codex Guide

GitHub Issue / Codex

Codex作業をGitHub Issueで管理するには

GitHub Issueは、Codexに頼む作業内容や確認結果をまとめて残すための作業メモとして使えます。

このページは非公式の実践ガイドです。GitHub公式、OpenAI公式の代替ではありません。Issueは便利な作業メモですが、Issueを作るだけで安全になるわけではありません。

APIキー、パスワード、トークン、秘密鍵、DB情報、SSH情報、顧客情報、個人情報はIssueに書かず、main直push、無確認merge、本番deployは軽作業として扱わないでください。

まず一言でいうと

Issue管理の親ハブです。GitHub Issueは、Codexに頼む作業の目的、対象、やること、やらないこと、停止条件、確認結果を残す場所として使えます。

項目書くこと注意点
目的何をしたいかあいまいにしない
対象URLどのページか未作成URLに注意
対象ファイル触ってよいファイル範囲外を触らせない
やること作業内容箇条書きにする
やらないこと触らない範囲必ず書く
停止条件止める基準危険作業を防ぐ
報告形式どう報告するかシンク報告書形式など

GitHub Issueで書くこと

Issueには、目的、対象URL、対象ファイル、やること、やらないこと、停止条件、確認項目、報告形式を書きます。秘密情報の実値は書かず、必要なら一般化した表現に置き換えます。

目的:
対象URL:
対象ファイル:
やること:
やらないこと:
停止条件:
確認項目:
報告形式:
触らないファイル:
秘密情報チェック:

Codexで作業すること

CodexにはIssueの内容をもとに、対象範囲内の調査、実装、確認、報告を依頼します。DB、cron、.htaccess、認証情報、Search Console確認タグ、AdSenseコードが必要になりそうな時は停止条件として扱います。

PRや報告書とつなげること

  1. Issueで作業依頼を書く
  2. Codexが作業する
  3. PRで差分を見る
  4. Codex報告書を読む
  5. Issueに結果と未完了を戻す
  6. 必要ならwork-log素材にする

Issueに書く内容の粒度

Issueは自分用のメモでも、他人への依頼書でもなく、「後から読んでも作業を再開できる記録」です。次の3点が入っていれば十分で、それ以上の背景説明は不要です。

要素書き方の例抜けると起きること
今どうなっているか「/about/ のtitleが旧サイト名のまま」数日後に読んで、何が問題なのか思い出せない
どうなってほしいか「新サイト名に更新する」作業のゴールが人によってブレる
終わったと判断する条件「公開URLで新titleが表示される」「直したつもり」でIssueが閉じられる

特に3つ目の「終わったと判断する条件」は省略されがちですが、これがあるとIssueを閉じる判断が自動的に決まります。逆にこれが無いIssueは、閉じてよいのか分からないまま残り続けます。

やってはいけないこと

書かない情報理由
APIキー不正利用リスク
パスワードログイン悪用リスク
トークン認証情報
顧客名個人情報・契約リスク
サーバーパス内部情報
DB情報重要情報
SSH情報サーバー侵入リスク

FAQ

Issueを作ればCodex作業は安全になりますか？

Issueは作業範囲を整理する助けになりますが、それだけで安全になるわけではありません。PR差分、報告書、秘密情報、停止条件を確認します。

Issueに秘密情報を書いてよいですか？

書かないのが基本です。APIキー、パスワード、トークン、顧客情報、サーバー情報は伏せるか一般化します。

IssueとPRはどう違いますか？

Issueは作業依頼やタスク管理、PRは実際の変更差分を確認する場所として分けると分かりやすいです。

未完了タスクはどう扱いますか？

報告書からIssueへ戻し、次にやること、止めた理由、確認待ち項目として残します。