Codexで
実ファイル確認から
始めた実践ログ

今回やった作業

Codexで対象URLを修正する前に、実際にそのURLを出力しているファイルを確認する作業を整理しました。URLの見た目からファイル名を想像して修正するのではなく、実ファイルと読み込み経路を確認してから進めます。

対象URL、index、controller、parts、router、共通部品の関係を確認し、どこを触るべきか、どこは触らないべきかを報告させる流れにしました。

作業前の状態

修正したい対象URLがあり、一見すると特定のファイルが出力していそうに見えました。しかし、実際にはindex、controller、parts、routerを通って表示が組み立てられている可能性がありました。

想定ファイルに決め打ちすると、修正が反映されないだけでなく、別ページの表示を壊すことがあります。修正前の実ファイル確認が必要でした。

作業前に問題だったこと

公開中サイトでは、URLとファイルが1対1で対応していないことがあります。特にPHPサイトやコード版サイトでは、ルーティングやcontroller、parts読み込みでページが構成されることがあります。

想定ファイルを直接編集しても、公開URLには反映されない場合があります。逆に、共通partsを触ることで対象外ページへ影響が出る可能性もあります。

Codexに任せたこと

Codexには、対象URLの確認、実ファイル探索、index確認、controller確認、parts確認、router確認、読み込み位置確認を任せる想定にしました。

修正対象候補を整理したうえで、どのファイルが何を担当しているか、どこを触るべきか、どこは触らないべきかを修正前に報告させます。

人間が判断したこと

人間が判断したのは、対象URLからファイル名を決め打ちしないことです。実ファイル確認を先に行い、controllerやpartsの関係を把握してから修正します。

不明なまま実装しないことも重要です。調査で分からない場合は、修正に進まず、確認できた範囲と不明点を報告させます。

実際に使った指示文の考え方

指示文では、対象URLを出力している実ファイルを確認することを最初に置きます。index、controller、parts、routerを確認し、読み込み位置を把握してから修正案を出すようにします。

また、共通header、footer、カード部品、DB、cron、設定ファイルを触らないことも明示します。修正前の調査と実装を分けることで、事故を減らせます。

うまくいった点

実ファイル確認から始めることで、修正対象を外すリスクを減らせます。どのファイルがページ本体で、どのファイルが共通部品かを分けて理解できます。

Codexの報告にも、触るファイルと触らないファイルを分けて書かせやすくなります。レビューする人間にとっても、変更範囲が見えやすくなります。

詰まった点・危なかった点

危なかったのは、URL名と似たファイルを見つけた段階で修正を始めることです。そのファイルが実際に読み込まれていなければ、変更しても公開ページに出ません。

もう一つは、共通partsを対象ページ専用だと思い込むことです。共通部品を触ると、複数ページに影響する可能性があります。

作業後に確認したこと

作業後は、対象URLを確認し、実ファイルを特定し、index、controller、parts、router、読み込み位置を整理したことを報告します。

実装に進む場合は、php -l、公開URL 200 OK、公開HTML出力、対象外ページへの影響確認も次の確認項目にします。

次から使える指示文テンプレート

確認チェックリスト

• 対象URLを確認
• 実ファイルを特定
• indexを確認
• controllerを確認
• partsを確認
• routerを確認
• 読み込み位置を確認
• 修正前に報告
• 想定ファイルに決め打ちしていない

関連する使い方ガイド

今回の判断は、小さな修正に見えても事故防止に効く確認です。公開前チェック、内部リンク確認、robots確認、作業報告の型と組み合わせると、Codex作業の安全度を上げやすくなります。

注意書き

この記事は、Codex作業で起きやすい小さな判断を一般化した実践ログ型ガイドです。特定サイトの内部事情、実在案件の固有情報、秘密情報は扱っていません。

UI、内部リンク、robots meta、実ファイル確認はいずれも小さな確認に見えますが、公開中サイトでは事故防止に直結します。修正を広げすぎず、確認結果を報告に残すことを重視しています。