読み方の1ポイント
目的、対象、確認項目を分けて読む
このページでは、Codex作業を安全に進めるための考え方を整理します。実行前に、対象、触らないもの、確認項目を分けて見ると迷いにくくなります。
このページも、全部を一度に覚えないとダメ？
必要なところから読めば大丈夫です。作業前に対象と停止条件、作業後に確認項目を見ると安全です。
今回やった作業
ランキング型サイトで、DB構造や集計処理を変えず、既存のレビュー数や評価などの表示だけを整理してランキングらしさを改善した流れを一般化します。
今回の作業では、表示や本文を改善するだけでなく、触らないものを守ることを重視しました。公開中サイトでは、SEOタグ、広告タグ、DB、cron、設定ファイルを意図せず変更すると、本文修正以上に大きな影響が出ることがあります。
作業前の状態
作業前は、カード一覧やランキングページは存在していました。既存データとしてレビュー数や評価が使える可能性がありましたが、DB変更やcron変更は避けたい状態でした。表示だけで改善できる範囲を見極める必要がありました。
作業前の段階では、作業対象と対象外を分ける必要がありました。Codexに任せる範囲を明確にしないと、目的達成のために周辺ファイルまで触る可能性があります。特にhead内タグ、広告script、設定ファイル、DBやcronは通常作業から切り離して扱う方が安全です。
作業前に問題だったこと
ランキング表示を改善しようとすると、新しいテーブルやスコア、集計処理を追加したくなることがあります。しかしDB変更は影響範囲が大きく、通常の表示改善と同時に行うと切り分けが難しくなります。まずは既存データでできる表示改善から進める方が安全な場合があります。
Codex作業で大事なのは、作業を進めることだけではありません。何を変更しないか、どこで停止するか、変更していないことをどう報告するかを先に決めることで、レビューしやすくなり、事故の切り分けもしやすくなります。
Codexに任せたこと
Codexには、既存表示データの確認、レビュー数や評価の有無確認、DB変更なしで表示できる範囲の整理、ページ表示時の重い集計がないか確認、既存列を使った表示案、公開HTML確認、DB変更なしの報告を任せました。
あわせて、公開HTMLで確認できるものは公開HTMLで確認し、変更ファイル、作成ファイル、触っていないファイルを報告書に分けて書くようにしました。確認していないものは確認済みと書かず、必要になった場合は停止して報告する条件も入れました。
人間が判断したこと
人間側では、DB変更なしで進めること、新規テーブルを作らないこと、既存列で表示できるものを使うこと、重い処理を追加しないこと、表示改善とDB設計変更を分けることを判断しました。
人間側で判断するのは、作業の範囲と停止条件です。Codexは実ファイル確認や公開HTML確認に向いていますが、広告タグやDB、cron、設定ファイルを触ってよいかどうかは、人間が先に決める必要があります。
実際に使った指示文の考え方
指示文では、変更してよいファイル、触らないファイル、禁止事項、停止条件、報告書形式を先に書きました。特に、canonical、robots、AdSenseタグ、Search Console確認タグ、DB、cron、.htaccess、robots.txt、ads.txtは触らない対象として明示しました。
うまくいった点
うまくいった点は、変更内容だけでなく維持確認を報告に入れたことです。何を変えたかだけでなく、何を変えていないかが分かると、後から確認する人が安心して差分を読めます。安全確認の項目を固定化すると、次回以降のCodexオーダーにも使い回せます。
詰まった点・危なかった点
- 変更してよい範囲を書かない
- 触らないファイルを書かない
- head内のタグ維持を確認しない
- DB変更なしを報告しない
- 広告タグ変更なしを報告しない
危なかったのは、作業対象外を明記せずに進めてしまうことです。本文修正やカード改善のつもりでも、テンプレートやheadに触るとSEOタグや広告タグへ影響する可能性があります。禁止事項は細かいほど安心材料になります。
作業後に確認したこと
作業後は、公開URLが200 OKであること、canonicalが自己URLであること、robotsがindex,followであること、noindexメタがないこと、広告タグが維持されていること、DBやcronや設定ファイルを変更していないこと、報告書に触っていないものが明記されていることを確認します。
次から使える指示文テンプレート
以下は、SEOタグ維持や禁止事項をCodexへ明確に渡す時に使えるテンプレートです。
以下の公開中サイトで、ランキング表示をDB変更なしで改善できるか確認してください。
新規テーブル作成、DBカラム追加、cron変更、重い集計追加は行わないでください。
既存データとして表示可能なレビュー数、評価、順位、更新日などを確認し、既存列だけで見せ方を改善する案を出してください。
作業後は、DB変更なし、cron変更なし、ページ表示時の重い処理追加なしを報告してください。確認チェックリスト
安全確認では、変更したことと変更していないことを分けて見ることが重要です。
- DB変更なし
- cron変更なし
- 新規テーブルなし
- 既存列を使った
- 重い集計なし
- 表示だけ改善
- 公開HTMLで確認
- 報告書でDB変更なし明記
- 影響範囲を小さくした
関連する使い方ガイド
注意書き
この記事は、実際の作業を一般化してまとめた実践ログ型ガイドです。具体的な案件名、内部情報、サーバーパス、秘密情報は掲載していません。
安全確認は、作業を止めるためではなく、作業範囲を明確にして公開後の事故を減らすためのものです。必要な変更が出た場合は、通常作業に混ぜず、別オーダーとして扱う方が安全です。