読み方の1ポイント
目的、対象、確認項目を分けて読む
このページでは、Codex作業を安全に進めるための考え方を整理します。実行前に、対象、触らないもの、確認項目を分けて見ると迷いにくくなります。
このページも、全部を一度に覚えないとダメ？
必要なところから読めば大丈夫です。作業前に対象と停止条件、作業後に確認項目を見ると安全です。
Projects for Codex work
Codex作業での
プロジェクトの使い方
Codex作業では、どのサイト、どのファイル、どのオーダー、どの報告書かを混ぜないことが大切です。プロジェクトを作業対象ごとの管理部屋として使うと、前提や次回候補を整理しやすくなります。
このページは非公式の実践ガイドです。プロジェクトやスレッドの仕様は変わる可能性があります。Codex作業後は人間が確認し、重要な判断も人間が行ってください。
Codex作業ではプロジェクト管理が重要
Codex作業では、ファイル、リンク、SEOタグ、sitemap、GitHubなど具体的な対象があります。作業の前提が混ざると、別ページのルールを別サイトに使ったり、古い報告書をもとに次の作業を出したりする原因になります。
プロジェクトを使うと、作業対象ごとの前提を保ちやすくなります。ただし、プロジェクトだけで安全になるわけではありません。変更後の確認、公開状態の確認、次に進むかどうかの判断は人間が行います。
プロジェクトは作業対象ごとの管理部屋
プロジェクトは、サイトやリポジトリなど作業対象ごとの管理部屋として使います。細かい作業ごとに増やすのではなく、長く続く対象ごとに分けるのが基本です。
小規模情報サイト、AI活用ガイドサイト、公開前チェック改善など。
GitHub運用、PR確認、README整理など。
社内ドキュメント、作業ルール整備、実践ログ化など。
スレッドは1つの作業・報告を扱う場所
スレッドは、1つのCodexオーダー、1つの報告書確認、1つの公開前チェックのように、作業単位で分けます。1つのスレッドにすべての報告書を貼ると、どの作業の結果か分からなくなります。
- トップページ導線確認スレッド
- 公開前チェック再検証スレッド
- GitHub PRレビュー確認スレッド
- Search Console初動クエリ確認スレッド
- 内部リンク改善スレッド
プロジェクトに置くとよいもの
プロジェクトには、Codexへ渡す前提や繰り返し使うルールを置きます。毎回同じ説明をしなくて済むように、必要な情報だけを整理しておきます。
| 置くもの | 目的 |
|---|---|
| 接続ブロック | 作業対象や前提を毎回確認しやすくする。 |
| サイト方針 | 文章の方向性や触ってよい範囲をそろえる。 |
| 作業ルール | 変更禁止ファイル、停止条件、確認項目を明確にする。 |
| Codexオーダー | よく使う依頼文を再利用しやすくする。 |
| 報告書テンプレート | 変更ファイル、未確認事項、停止条件を毎回確認する。 |
| 公開前チェックリスト | 200 OK、SEOタグ、noindex、内部リンクなどを確認する。 |
| 実践ログ化候補 | 次の記事素材や再利用できる指示文を残す。 |
置かないもの
ログイン情報、APIキー、SSH鍵、DB接続情報、FTP接続情報、個人に関わる情報、社外に出せない情報は置かないでください。
Codexオーダーと報告書の置き場所
Codexオーダーは作業スレッドで管理し、Codex報告書も同じ作業スレッドに戻します。総合管理スレッドには要点だけ戻すと、細かい報告で埋まりにくくなります。
- プロジェクト作業対象の前提を置く
- 作業スレッド今回の作業を扱う
- Codexオーダー対象と禁止事項を指定する
- Codex報告書同じスレッドに戻す
- ChatGPTで判定変更ファイルと未確認事項を見る
- 次回候補へ整理次の作業に分ける
複数サイトを進める時のプロジェクト分け
複数サイトを同時に進める場合は、サイトごとにプロジェクトを分けます。Codex画面もサイトごとに分け、報告書も該当プロジェクトのスレッドに貼ります。全体方針だけ別の総合管理スレッドで扱います。
| 場所 | 扱う内容 |
|---|---|
| 総合管理プロジェクト | 全体方針、優先順位、保留する作業。 |
| サイトAプロジェクト | サイトAのCodex報告、次オーダー、公開前チェック。 |
| サイトBプロジェクト | サイトBのCodex報告、次オーダー、公開前チェック。 |
同じサイト内では作業を重ねすぎないことも大切です。1つの報告書を見てから次の作業へ進む方が、原因追跡しやすくなります。
思いついた作業を次回候補にする方法
作業中に思いついたことは捨てなくてよいです。ただし、今のCodex作業に混ぜません。まずプロジェクト内の次回候補として残し、報告書を見てから次オーダーにします。
| 分類 | 扱い |
|---|---|
| A すぐ実行してよい | 報告書確認後、次の小さな作業として出す。 |
| B 反応や確認後に実行 | Search Console反応や公開確認を見てから判断する。 |
| C 後回し | 今の作業には混ぜず、別スレッドで扱う。 |
| D 保留 | 目的や対象があいまいなものは実装しない。 |
プロジェクトを作りすぎないためのルール
- 1サイト1プロジェクトを基本にする
- 細かい作業ごとにプロジェクトを作らない
- 細かい作業はスレッドで分ける
- 似たプロジェクトを増やさない
- プロジェクト名は具体的にする
- 完了した作業は現在地メモにまとめる
- 使わないプロジェクトは増やし続けない
やってはいけないプロジェクト運用
この運用は避ける
- 複数サイトを1プロジェクトに混ぜる
- 1つのスレッドに全作業の報告書を貼る
- 実在するサイト名や重要情報を公開用記事へ転用する
- ログイン情報や接続情報をプロジェクトに置く
- Codex報告書を別サイトのスレッドに貼る
- Search Console判断と実装作業を同じ流れで混ぜる
- プロジェクトを作りすぎて現在地が分からなくなる
- 人間確認なしに次々と公開反映する
Codexプロジェクト管理チェックリスト
- 作業対象ごとにプロジェクトを分けている
- スレッドは作業単位で分けている
- Codex報告書を貼る場所が決まっている
- 接続ブロックがある
- 触ってはいけないファイルを明記している
- 停止条件を入れている
- ログイン情報や重要情報を置いていない
- 思いつきは次回候補にしている
- Search Console反応後に判断するものを分けている
- 最終判断は人間が行う