Codexにエラー修正を頼む時の情報整理

Webサイトでエラーが出た時、Codexに「直して」とだけ頼むと、原因を探すところから時間がかかります。エラー文や直前に変更した内容を整理して渡すだけで、原因の切り分けがかなり進めやすくなります。

この記事では、PHPサイトやHTML/CSSの不具合をCodexに相談する前に、どんな情報を集めて、どんな形で渡せばよいかを初心者向けにまとめます。

エラー修正を頼む前の整理

症状、エラー文、直前の変更、対象ファイル、再現手順を順番にまとめます。

なぜ情報整理が大事なのか

エラー修正は、原因候補を減らす作業です。情報が少ないと、Codexは広い範囲を調べる必要があります。反対に、直前の変更やエラー文が分かると、見るべき場所を絞れます。

まず集める情報

難しく考えなくて大丈夫です。分かる範囲で、現状と直前の作業をメモします。

• エラーが出ているページURL
• エラー文の全文
• 画面が真っ白、500、404、表示崩れなどの症状
• 最後に変更したファイル
• 変更した目的
• いつから起きたか
• ローカルだけか、本番でも起きるか

基本の依頼文テンプレート

情報がそろったら、次の形でCodexに渡します。

次のエラーを調べて修正してください。

起きている症状：
エラーが出るURLまたはファイル：
表示されているエラー文：
直前に変更したこと：
変更したファイル：
期待している正しい状態：

お願いしたいこと：
- 原因を切り分ける
- 必要なファイルだけ修正する
- 変更前に関係する箇所を確認する
- PHP構文チェックをする
- ローカル表示で直ったか確認する
- 変更したファイルと理由を報告する

エラー文を貼る時の注意

エラー文は、一部だけではなく、できるだけそのまま貼ります。ファイル名、行番号、エラーの種類が原因調査のヒントになります。

エラー文は以下です。

（ここにエラー文をそのまま貼る）

補足：
- どの操作をした時に出たか：
- 何度試しても出るか：
- 直前に触ったファイル：
- 本番とローカルのどちらで出るか：

直前の変更を伝える

エラーは、直前に変更した場所が原因になっていることが多いです。覚えている範囲でよいので、何をしたかを書きます。

エラーが出る直前に、次の作業をしました。

作業した目的：
変更したファイル：
追加した内容：
削除した内容：
アップロードした場所：
作業後に起きた変化：

この変更が原因かどうかも含めて確認してください。

確認してよい範囲を指定する

Codexに頼む時は、どこまで見てよいかを伝えると安全です。関係ないファイルまで大きく変えないように、範囲を決めます。

確認してよい範囲は次の通りです。

優先して見てほしいファイル：
必要なら見てよいフォルダ：
触らないでほしいファイル：
変更してよい範囲：

条件：
- 関係ないデザイン変更はしない
- 大きな書き換えが必要な場合は先に理由を説明する
- 既存の動いている機能を壊さない
- 修正後に確認した内容を報告する

スクリーンショットが役立つ場合

表示崩れやボタンの位置ズレは、文章だけでは伝わりにくいことがあります。その場合は、スクリーンショットと一緒に「どこが変か」を言葉でも書きます。

• PCかスマホか
• ブラウザ名
• どの部分が崩れているか
• 本来どう見えてほしいか
• いつから崩れたか

調査だけ頼む依頼文

すぐに修正してよいか不安な時は、まず原因調査だけ頼むこともできます。

まず修正せずに、原因調査だけしてください。

症状：
エラー文：
直前の変更：
対象ページ：

お願いしたいこと：
- 原因候補を優先度順に出す
- 確認したファイルを報告する
- どの修正が必要そうか説明する
- まだファイルは変更しない
- 修正する場合の方針を短く提案する

Codexに頼む時の悪い例

次のような依頼だと、原因を探す手がかりが少なくなります。

• サイトが壊れたので直して
• なんかエラーが出た
• 昨日までは動いていた
• 全部見ていい感じに直して
• エラー文は分からないけど直して

チェックリスト

• エラーが出るページや操作を書いた
• エラー文をそのまま貼った
• 直前に変更した内容を書いた
• 期待する正しい状態を書いた
• 確認してよい範囲を指定した
• 触らないでほしいファイルを書いた
• 修正後の確認方法を頼んだ