このページで分かること
Codex報告書を、作業名、変更ファイル、触っていないファイル、確認結果、停止条件、次作業で整理する方法です。
使う場面
Codex作業後の報告が増え、何が終わったか分かりにくくなった時に使います。
管理の考え方
報告書の整理は「あとで読む自分」のための作業です。作業直後は全部覚えていても、1週間後に不具合が出た時に頼れるのは報告書だけです。「いつ・何を・どこまで確認したか」を後から即答できる形が、良い報告書の条件です。
| 原則 | 具体的には | 守らないと起きること |
|---|---|---|
| 作業名を先頭に置く | 「20260801_トップページ修正」のように日付+内容で統一 | 報告書が溜まった時に目的のものを探せない |
| 変更ファイルと触っていないファイルを分ける | 「変更した」だけでなく「触っていないことを確認した」も明記させる | 後日の不具合時に、容疑ファイルの範囲を絞れない |
| HTTPやSEO確認結果を残す | 確認したURLとステータス、SEOタグの状態を記録 | 「確認したはず」が記憶頼みになり、再確認のやり直しが発生 |
| 停止条件該当の有無を書く | 該当なしでも「停止条件該当なし」と一行書かせる | 停止すべき場面をスルーしたのか、本当に問題なかったのか区別できない |
| 次作業を短く書く | 「次は〇〇の確認」と1行で引き継ぐ | 次回セッションの立ち上がりに前回の読み直しから始めることになる |
報告書の形式は毎回同じにするのが最大のコツです。形式が揃っていれば、差分だけ読めばよくなり、読む時間も書かせる指示も短くなります。
よくある失敗
- 変更ファイルだけ見て公開確認を忘れる
- 触っていないファイルを確認しない
- 未確認事項を完了扱いにする
- 次作業が長すぎる
Codexに頼む時の指示例
Codex報告書を整理してください。作業名、変更ファイル、触っていないファイル、確認結果、停止条件、未確認事項、次作業に分けて要約してください。確認チェックリスト
- 作業名がある
- 変更ファイルがある
- 確認結果がある
- 未確認事項がある
- 次作業がある
停止条件
- 報告書と公開状態が違う
- 確認結果がない
- 停止条件が不明
- 未確認事項を無視している
報告書フォーマットのサンプル
毎回この形式で書かせると、後から読む時に迷いません。
作業名：20260804_トップページニュース欄更新
変更ファイル：index.html
触っていないファイル：news/配下、sitemap.xml
確認結果：本番URLで新しい日付表示を確認、200 OK
停止条件該当：なし
未確認事項：なし
次作業：残りの薄いページの増量を継続報告書をどこに残すか
報告書は受け取って読んで終わりにすると、必要な時に探せません。残し方には現実的な選択肢があります。
| 残し方 | 向いている場面 | 弱点 |
|---|---|---|
| やり取りの履歴のまま | 単発の作業 | 会話が増えると探せなくなる |
| 作業ごとにファイルで保存 | 継続的に運用する場合 | 保存する手間がかかる |
| 1つのファイルに追記 | 日々の作業を追う場合 | 長くなると目的の箇所を探しにくい |
| 変更履歴と紐づける | コードやサイトを扱う場合 | 仕組みの用意が必要 |
どれを選ぶにしても、作業名に日付を入れておくだけで探しやすさが大きく変わります。「トップページ修正」より「20260806_トップページ修正」の方が、数か月後に目的のものを見つけられます。
報告書を次に活かす
報告書の価値は、その場の確認だけではありません。溜まってくると別の使い道が出てきます。
- 同じ作業を繰り返す時のテンプレート：過去の指示文をそのまま再利用できます。
- 不具合の原因調査：いつ何を変えたかが分かれば、問題の発生時期と照合できます。
- 失敗パターンの把握：同じ理由で止まっている作業が複数あれば、依頼の仕方に問題があります。
- 公開できる記事の素材：固有名詞を伏せて一般化すれば、同じ作業をする人の役に立つ内容になります。
特に3番目は、報告書を溜めてから振り返って初めて見えるものです。1回ごとの報告では気づけないパターンが、並べると見えてきます。月に一度でも過去の報告を眺める時間があると、依頼の質が上がります。