読み方の1ポイント
目的、対象、確認項目を分けて読む
このページでは、Codex作業を安全に進めるための考え方を整理します。実行前に、対象、触らないもの、確認項目を分けて見ると迷いにくくなります。
このページも、全部を一度に覚えないとダメ？
必要なところから読めば大丈夫です。作業前に対象と停止条件、作業後に確認項目を見ると安全です。
Project separation
Codexプロジェクトを
分ける意味
Codexは、何でも細かく分ければよいわけではありません。前提が混ざる時だけ分け、単発作業はタスクやスレッドで扱う方が現実的です。
このページは非公式の実践ガイドです。プロジェクトやスレッドの仕様は変わる可能性があります。Codex作業後は人間が確認し、重要な判断も人間が行ってください。
結論：Codexプロジェクトは何でも分ければよいわけではない
Codex作業では、プロジェクトを増やすこと自体が目的ではありません。単発の確認や1ページ修正なら、既存の作業スレッドで十分なことが多いです。
細かい作業ごとにプロジェクトを作ると、どこで何をしたか分かりにくくなります。Codexでは、1タスク1目的、対象ファイル明確化、報告書確認の方が重要です。ただし、作業対象や権限が違う場合は、プロジェクトを分ける価値があります。
プロジェクトは、作業を増やすためではなく、前提を混ぜないために分けます。
単発作業ならプロジェクトを分けなくてもよい
作業範囲が小さく、前提が混ざりにくい場合は、毎回プロジェクトを分ける必要は少ないです。報告書で確認できるなら、プロジェクトを増やす方が管理コストになることもあります。
1ページの誤字修正、1つのHTMLの軽微修正、1つのCSS調整。
1ページの内部リンク確認、公開前チェック、sitemap掲載確認。
1つの報告書確認、Search Consoleの軽い確認。
プロジェクトを分ける意味がある場面
プロジェクトを分ける意味があるのは、作業の前提が違う場合です。サイト、リポジトリ、環境、権限、作業ルールが変わるなら、分ける価値があります。
| 分ける必要が低い | 分ける意味がある |
|---|---|
| 同じサイト内の1ページ修正 | 別サイト |
| 同じリポジトリ内の軽い確認 | 別リポジトリ |
| 単発の公開前チェック | 別チーム、別環境、別の権限ルール |
| 短時間で終わる確認作業 | 長期運用テーマ |
サイトが違うなら分ける意味がある
サイトが違うと、URL、ファイル構造、sitemap、robots、AdSense、Search Console、作業ルールが違います。同じプロジェクトに混ぜると、報告書や次オーダーが混乱しやすくなります。
サイトAの作業報告をサイトBの前提で読んでしまう危険もあります。基本は1サイト1プロジェクトが分かりやすいです。ただし、小さな単発確認だけなら、総合管理スレッドで扱う場合もあります。
| 良い例 | 悪い例 |
|---|---|
| サイトAプロジェクト、サイトBプロジェクト | 複数サイトをまとめて1プロジェクトにし、全報告書を混ぜる |
リポジトリが違うなら分ける意味がある
リポジトリが違うと、コード、ブランチ、PR、Secrets、Actions、運用ルールが違います。Codexが見る対象を間違えないためにも、リポジトリ単位で分けると安全です。
特にGitHub連携では、必要最小限のリポジトリだけ接続する考え方が大事です。複数リポジトリを同じ前提で扱わないようにしてください。重要情報や権限が関係する場合は、さらに慎重に扱います。
権限や重要情報の扱いが違うなら分ける意味がある
個人作業と業務作業では、扱える情報が違います。公開できるコードと公開できないコードもあります。APIキー、SSH鍵、DB情報、FTP情報、GitHub Token、Secrets などは混ぜないでください。
重要情報を扱う可能性がある作業は、プロジェクトやスレッドを分けるだけでなく、そもそも外に出せない情報を貼らないことが重要です。プロジェクトは重要情報の保管場所ではありません。
プロジェクトを分けても、外に出せない情報を貼ってよいわけではありません。ログイン情報や本番環境の情報は、CodexやChatGPTにそのまま貼らないでください。
作業ルールが違うなら分ける意味がある
サイト制作、GitHub運用、公開前チェック、実践ログ化では、それぞれ作業ルールが違います。触ってよいファイル、触ってはいけないファイル、停止条件が違う作業を1つに混ぜると危険です。
| 作業テーマ | 主なルール |
|---|---|
| サイト制作プロジェクト | HTML / CSS、公開前チェック、内部リンク |
| GitHub運用プロジェクト | PR確認、Secrets注意、ブランチ運用 |
| 実践ログ化プロジェクト | 報告書整理、匿名化、公開用表現 |
長期的に続く作業テーマなら、プロジェクトとして分ける意味があります。短期の1回作業なら、スレッドで十分です。
プロジェクトを分けすぎるデメリット
プロジェクトを増やしすぎると、どこに何を入れたか分からなくなります。似たプロジェクトが増え、同じ前提を何度も説明し、報告書が分散します。
現在地が分からなくなったり、総合判断がしにくくなったり、プロジェクトを整理すること自体が作業になることもあります。単発作業なのにプロジェクトを作ると、管理コストが増えます。
プロジェクトは増やせばよいものではありません。前提が混ざる時だけ分けるのが基本です。
現実的な分け方の目安
| 状況 | 分ける？ | 理由 |
|---|---|---|
| 1ページだけ修正 | 分けなくてよい | 単発タスクで十分 |
| 同じサイト内の複数作業 | 基本は同じプロジェクト | スレッドで作業単位を分ける |
| 別サイト | 分ける | URLやルールが違う |
| 別リポジトリ | 分ける | GitHub前提が違う |
| 業務用と個人用 | 分ける | 権限や情報の扱いが違う |
| 本番と実験 | 分けることを検討 | 影響範囲が違う |
| 短期の確認だけ | 分けなくてよい | 管理コストが高い |
| 長期運用テーマ | 分ける価値あり | 前提を残しやすい |
悪い分け方・良い分け方
| 悪い分け方 | 良い分け方 |
|---|---|
| 1ページ修正ごとにプロジェクトを作る | 1サイト1プロジェクト |
| 似た名前のプロジェクトを大量に作る | 1リポジトリ1プロジェクト |
| 複数サイトを1プロジェクトに混ぜる | 単発作業はスレッドで管理 |
| 重要情報を置くために分ける | 総合判断は総合管理スレッドで扱う |
| 報告書を別プロジェクトに貼る | 報告書は該当プロジェクトに戻す |
| 今どこが最新か分からなくなる | 現在地メモを残す |
Codexプロジェクト分け方チェックリスト
- これは単発作業ではないか
- 同じサイト内の作業ではないか
- 別サイトや別リポジトリか
- 権限や重要情報の扱いが違うか
- 作業ルールが違うか
- 長期的に続く作業か
- プロジェクトを増やす理由があるか
- スレッドで十分ではないか
- 報告書の戻し先が分かるか
- 現在地メモを残せるか
- 外に出せない情報を貼らない運用になっているか
- 最終判断は人間が行うか