結論：大玉ほど差分確認を厚くする
大玉では変更ファイル、sitemap、内部リンク、公開URLを確認します。中玉は対象を絞り、小玉は差分を軽く確認します。
rollback視点
公開後に問題が出た時に戻せるよう、バックアップ先、変更ファイル、追加URLを報告します。
Secrets禁止
GitHub token、SSH鍵、.env、FTP情報の実値は記事や依頼文に出しません。
大玉・中玉・小玉：サイズ分けの実際の基準
Codexへの依頼を大玉・中玉・小玉に分ける基準は、作業の難しさではなく「人間の確認にかかる時間」です。AIの作業時間はサイズが大きくても勝手に進みますが、確認時間は人間の拘束時間なので、ここを基準にすると運用が現実的になります。
| サイズ | 目安 | GitHubでの管理 | 例 |
|---|---|---|---|
| 小玉 | 確認5分以内・1〜2ファイル | 差分をさっと見てmerge | 誤字修正、リンク1本差し替え |
| 中玉 | 確認15分・数ファイル | PRの変更一覧→差分→表示確認の3点セット | ページ1本追加、セクション改修 |
| 大玉 | 確認30分以上・多数ファイル | 着手前に分割を検討。やるならbranch必須＋段階確認 | 全ページ共通部分の変更、サイト構造の変更 |
大玉をそのまま投げない：分割の考え方
確認しきれない差分は、確認していないのと同じです。大玉作業は「1PRで全部」ではなく、「まず1ページで試す小玉→問題なければ残りを中玉数回に分けて展開」という形に割ると、各段階の差分が読める量に収まります。時間はかかるように見えますが、大玉PRで事故が起きた時の切り戻しコストを考えれば、分割の方が結果的に速く終わります。Codexへの指示も「全〇〇ページのうち、まず△△だけ修正して停止・報告」と段階指定する形が安全です。
codexguide.jpへの導線
作業サイズ設計はcodexguide.jpの本命記事に集約します。
関連ページ
確認した公式情報
このページは公式ページではありません。最新仕様、install方法、料金、使用上限は必ず公式情報で確認してください。
FAQ
Pro 200にしたら毎回たくさんページを作っていいですか？
以前より攻めやすくなりますが、毎回大玉にする必要はありません。親ハブ級だけ大玉にし、子ページや既存補強は中玉・小玉で進めます。
オーダーが長いのは悪いことですか？
悪いとは限りません。長いオーダーには、触ってはいけないもの、停止条件、確認項目が含まれており、事故防止の役割があります。
中玉オーダーは何に向いていますか？
既存親ハブの子ページ、Search Console反応語の刈り取り、本命1URL＋少数横展開に向いています。
小玉オーダーは何に使いますか？
既存ページ補強、内部リンク追加、FAQ追加、公開確認、軽いSEO補強に向いています。