Codexのエラー修正の頼み方｜再現手順と確認のコツ

こんにちは。AIあれこれ散歩道、運営者のもっちゃんです。

Codexにエラー修正を頼むときは、「動かない」だけでなく、何をしたら起きるか、本来どう動いてほしいか、どこまで直してよいかを渡すと進めやすくなります。エラー画面だけで原因を当ててもらうより、再現できる条件をそろえるのが近道です。

この記事では、エラー文の渡し方、画面の不具合の説明、修正後の確認、直らないときの切り分けを紹介します。コードの専門知識が少なくても、症状と期待する結果を整理するところから始められます。文例は編集部作成の練習用です。

Codexのエラー修正を頼む前に

エラー修正は、原因の名前を正しく言う必要はありません。あなたが見た事実を伝えるほうが役立ちます。推測は推測と分けて、修正前の状態を残してください。

症状と期待する動きを分ける

「検索が壊れている」より、「検索欄に東京と入力してボタンを押すと、結果が一件も表示されない。本来はタイトルに東京を含む項目を出したい」のほうが、確認する条件がはっきりします。

現状、期待、再現手順を別の欄にします。分からない箇所は「不明」で構いません。原因を断定して誤った場所へ誘導するより、起きていることを渡してください。

このプロジェクトの不具合を調査して修正してください。
症状：検索ボタンを押しても結果が空になる
再現手順：一覧を開く→「東京」と入力→検索を押す
期待する結果：タイトルに「東京」を含む項目が表示される
確認できた範囲：PCのブラウザ。スマホは未確認
変更範囲：原因に関係する最小限の箇所
完了条件：同じ手順で期待どおり動くことを確認し、
修正内容、確認したこと、未確認のことを報告する

原因の予想より、同じ症状を再現できる情報を渡す。最近ボタンの色を変えたとしても、それが原因とは限りません。直前の変更は参考として伝え、実際の原因はファイルやログで確認してもらいます。

エラー文は文字で渡す

画面にエラーが表示される場合は、その文をコピーして渡すと調べやすくなります。画像だけだと小さい文字や途中の行が読み取りにくいことがあるためです。発生した操作や実行したコマンドも添えます。

エラー文の前後にファイル名や行番号があれば残します。ただし、ログへ含まれる秘密値や個人情報は取り除いてください。必要な情報を消しすぎると切り分けにくくなるので、値を伏せつつ、どの種類の項目だったか分かるようにします。

操作：[起動コマンドや画面上の操作]
作業フォルダ：[対象プロジェクトの場所]
エラー文：
[秘密情報を除いたエラー全文]
最後に正常だった時点：[分かる範囲]
直前に変えたこと：[変更内容。不明なら不明]
このログだけで断定できない原因は、推測として分けてください。

ログが長いときは、最初に発生したエラーと、その前後を渡す方法もあります。末尾の「失敗しました」だけでは、原因となる行が抜けていることがあります。Codexが対象のログを読めるなら、ファイルを指定して確認してもらえます。

画面の不具合は範囲を示す

表示崩れなら、スクリーンショットと、どこがどう違うかの説明を組み合わせます。「デザインを直して」より、「右下のボタンが画面の外へはみ出す。ボタン全体を画面内へ収めたい」と書くほうが、目的が伝わります。

画面全体だけでなく、対象のページ、ウィンドウの幅、スクロール位置、押したボタンを添えます。スマホで起きるなら機種やブラウザが分かる範囲で記載します。PCを狭くした画面と、実際のスマホは同じ条件ではありません。

添付画像の、フォーム下部の送信ボタンを確認してください。
現在：幅390pxの表示で右端が切れている
期待：ボタン全体と文字が見える
残すもの：文章、色、入力項目、送信処理
確認：狭い幅と通常のPC幅の両方で確認してください。
画像に写っていない処理の不具合は、推測で変更しないでください。

画像は見た目の根拠になりますが、内部の処理や通信結果までは分かりません。表示が直っても送信が成功するとは限らないため、見た目と機能の完了条件を分けます。

修正前の変更を残しておく

修正前に、作業コピーや変更履歴で元の状態を残します。Gitはファイルの変更履歴を管理する仕組みです。使っているなら、作業中の差分を確認して、今回以外の変更を消さないようにします。

初心者なら、まず本番のフォルダを直接直すより、練習用コピーで試すと確認しやすくなります。ただし、コピーが古いまま本番へ戻すと新しい変更を失うので、どちらが原本かをはっきりさせてください。

既存の未保存・未コミットの変更を先に確認してください。
今回と無関係な変更を戻したり、上書きしたりしないでください。
原因に関係のない整理やファイルの移動は含めず、
不具合修正の差分を確認できる形で残してください。

小さな例で完成条件を作る

結果が合っているか確認できる入力を用意します。たとえば数量と単価から合計を出す処理なら、数量2、単価500で1,000になる、という小さな例が使えます。

JavaScriptでは文字の「2」と「500」を足すと「2500」になります。計算したいのに文字をつないでいた場合は、表示の桁を直すだけでは解決しません。ここでは仕組みを理解するため、単純なサンプルを使います。

// 誤った例：文字を連結してしまう
const quantity = "2";
const unitPrice = "500";
const wrongTotal = quantity + unitPrice; // "2500"

// 数量×単価という仕様に合わせた例
const total = Number(quantity) * Number(unitPrice); // 1000

このサンプルの修正だけで本物の注文フォームが完成するわけではありません。空欄、負数、小数、税、丸め方は別の仕様です。「何を正しい結果とするか」を決めてから、必要な確認項目を足していきます。

Codexのエラー修正を確認する

修正後は、元の症状が消えたかと、周辺の動きが壊れていないかを確認します。「修正しました」という説明と、実際に確認した結果を分けて受け取ってください。

同じ操作をもう一度試す

最初に書いた再現手順を、同じ条件で試します。検索なら同じ検索語、フォームなら同じ入力を使います。修正前と条件を変えてしまうと、修正のおかげで直ったのか分からなくなります。

修正前の再現手順で、同じ入力を使って確認してください。
実行した操作、期待結果、実際の結果を報告してください。
環境の都合で実行できない場合は未実施とし、
コードを読んだだけの確認と、実際の動作確認を分けてください。

テストを実行した場合も、コマンド名だけではなく、成功したか、どの範囲が対象だったかを見ます。検索の自動テストが通っても、狭い画面の見た目まで確認できるとは限りません。

OpenAIの公式のプロンプト案内でも、必要な背景や期待する成果を伝え、結果を見て絞った修正を行う考え方が説明されています。この記事の再現票は、その考え方を不具合対応へ使う編集部の実務例です。（出典：OpenAI「Prompting」）

正常な場合と境界も見る

元の不具合を確認したら、影響しそうな隣の条件も少数選んで試します。検索なら「結果がある語」「結果がない語」「空欄」のように、処理が分かれるところを確認すると役立ちます。

合計計算なら、通常の数量に加え、空欄や0をどう扱うかを決めます。仕様が決まっていないのに、AIが都合のよい結果へ変更していないか見てください。「エラーを出さない」ために間違った値を黙って返す修正は、別の問題につながります。

直した箇所の成功と、使い方全体の成功を混同しない。全部を一度に確認できなくても、どこまで確かめたかが分かれば、次に確認する範囲を選べます。

直らないときは差を整理する

一度直しても同じ症状が残るなら、同じ指示を繰り返す前に、何が変わったかを整理します。修正したファイルが実際の画面へ反映されていない、別の作業コピーを見ている、再現条件が違う、といった可能性もあります。

同じ手順で症状が残っています。
前回の仮説、変更箇所、実際の確認結果を整理してください。
修正したファイルと実行中のファイルが同じかも確認。
次は一つの仮説だけを検証し、
失敗した変更を積み重ねる前に差分を見直してください。

原因が権限や外部サービスの停止なら、コード変更だけでは直りません。「コードの不具合」「設定・接続の問題」「仕様上の制限」を分けて、確認できない箇所を残します。解決したように見せるために、エラー表示だけを消す修正は避けましょう。

公開する前に差分を読む

修正後は、変えたファイルと理由を確認します。小さな表示修正のつもりが、送信処理や依存関係まで大きく変わっていたら、その必要性を確認してください。コードを細部まで読めなくても、変更範囲は説明してもらえます。

変更したファイルと、その変更が必要だった理由を、
専門用語を抑えて説明してください。
今回の症状と直接関係しない変更があれば分けて示してください。
確認済み・未確認・公開前に必要な確認を整理してください。

繰り返す決まりを残したいときは、CodexのAGENTS.mdの作り方へ整理できます。ただし、今回の不具合の長いログは共通ルールへ丸ごと入れず、別の作業記録へ残します。

正確な情報は公式サイトをご確認ください。支払い、個人情報、セキュリティに関わるシステムを変更する最終的な判断は専門家にご相談ください。見た目の不具合と、重要なデータを扱う不具合は、必要な確認の深さが違います。

Codexのエラー修正まとめ

まず今困っている症状を、現状、再現手順、期待結果の三つに分けて書いてみてください。そこへ変更範囲と完成条件を足すと、依頼文になります。修正後は最初と同じ操作を試し、実際に確認できた結果まで受け取ることが大切です。