Codexへの最初の依頼はこう書く：コーディングプロンプトの実践例

要約： 「自分でうまく作って」より「この入力でこの結果を出して」の方が作業基準を立てやすくなります。最初の依頼には解決する問題と確認方法を併記してください。

1. 依頼前に完成した場面を定める

コーディングを任せる前に、利用者がどの画面で何をできるべきか一文で書いてみてください。「検索改善」は方向で、「検索結果がなければ空画面の代わりに案内を表示する」は確認可能な動作です。後者があれば変更後に結果を比べられます。

OpenAIのCodexプロンプト案内も、希望動作、関連コードや再現手順、維持条件、検証方法を重視します。ここでの例は架空のブログ検索へ原則を適用した独自の例です。全項目を形式的に埋めるより、結果を変え得る情報に集中してください。

2. 四つの情報を短く伝える

問題： 不便なことと発生時点を書きます。場所： 関連画面やファイルを伝えます。条件： 変えてはいけない機能を指定します。検証： 何を確認すれば完了かを書きます。この四つで小作業を始めるには十分な場合が多くあります。

例えば「モバイル検索がおかしい」だけでは入力欄サイズ、検索速度、結果表示のどの問題か分かりにくくなります。「携帯電話の幅で検索ボタンが折り返され入力欄と重なる」のように観察を書いてください。原因が不確かなら「CSS問題」と断定する必要はありません。症状と推測を分けると調査の余地ができます。

3. コピーして直す最初の依頼例

블로그 검색 화면에서 결과가 0개일 때 안내가 없습니다.
검색어가 입력되어 있고 결과가 없으면
'검색 결과가 없습니다. 다른 검색어를 입력해 보세요.'를 보여 주세요.
검색어가 비어 있으면 기존 화면을 유지해 주세요.
대상은 src/search 폴더이며, API 응답 형식은 바꾸지 마세요.
기존 테스트 방식에 맞춰 필요한 검증을 수행해 주세요.
완료 후 변경 파일, 확인한 동작, 실행 명령과 결과를 알려 주세요.
직접 확인하지 못한 사항은 별도로 표시해 주세요.

この例の要点は案内の長さではなく、空の検索語と結果0件を分けたことです。条件を落とすと最初のページ表示から「結果なし」が出る場合があります。境界事例を一、二個入れると意図をより正確に伝えられます。

4. 後続依頼は観察した差だけ伝える

初回結果が期待と違えば依頼全体の再送より差を伝えてください。「検索中にも結果なしが一瞬出ます。読み込み中は非表示にし、応答後だけ表示して」のように新観察を伝えると次の修正基準が明確です。

自分で変更した場合はその事実も知らせるとよいでしょう。「案内文は私が変えました。その文言を維持し表示条件だけ修正して」のように現在状態を基準に依頼してください。以前の会話の姿より実ファイルが優先です。修正直後はキャッシュやサーバー状態で古い画面を見ていないかも確認が必要です。

5. 作業がずれた際のチェックリスト

• 範囲が広がったか？ 検索画面以外の変更ファイルの必要性を説明させます。
• 実行と提案を混ぜたか？ 実行済みコマンドと実行方法案内を分けさせます。
• 環境で行き詰まったか？ 必要ツール、アクセス不能パス、インストール失敗のどれか確認します。
• 成功基準が曖昧か？ 正常検索、0件、読み込み中など比較事例を具体化します。

権限問題で実行できない場合は即座にコードの誤りと結論づけないでください。逆にコマンド実行だけで希望動作が検証済みでもありません。「確認した事例と残ったもの」が回答から読める必要があります。判断しにくければ、各変更が元依頼のどの条件を解決するか対応づけるよう頼んでください。

6. 検索画面の状態を表にして依頼する

画面機能で正常結果だけを説明すると重要状態が抜けます。検索なら初回、入力だけ、応答待ち、結果なし、サーバー失敗が異なります。小さな「結果なし」追加でも状態を分けると検索中の誤表示を減らせます。下は架空ブログの要件例で、実製品の方針へ変更する必要があります。

状態	表示内容	避ける結果
検索前	既存の案内画面	初めから結果なし表示
要求中	既存の読み込み表示	空の結果の案内が先に出る
成功・結果あり	検索結果の一覧	古い結果と新しい結果の混在
成功・結果0件	結果なしの案内	エラーのように表示
要求失敗	失敗の案内と再試行方法	正常な空の結果と誤解

表の後は基準が不明な欄だけ決めれば十分です。例えば空白だけなら要求しないか以前の結果を維持するか定めてください。入力ごとに検索する画面とボタンで要求する画面も異なります。既存方法があれば維持と書けばよいでしょう。利用者視点の状態表は実装コードを先に指定せず希望動作を正確に伝える方法です。

7. 小作業と大作業で依頼の構成を変える

すぐ実装するのに適した小さな依頼

검색 결과 없음 안내를 구현해 주세요.
완료된 응답이 성공이고 결과 배열이 비었을 때만 표시합니다.
요청 중·요청 실패·아직 검색하지 않은 상태에서는 표시하지 않습니다.
기존 로딩과 오류 안내, API 형식, 검색 실행 시점은 유지하세요.
프로젝트의 기존 스타일과 테스트 도구를 사용하세요.
새 라이브러리 추가가 필요한지 먼저 현재 코드에서 판단하세요.
변경 내용과 상태별 검증 근거를 정리해 주세요.

この依頼は希望行動と維持条件を分けます。「新ライブラリ禁止」だけを強く書くと既存コードでは無理な問題も強引に実装する場合があります。現在構成で可能か判断させ、不要依存を避ける理由を説明する方がよいでしょう。全実装選択を指定するより製品の重要な結果を先に書いてください。

選択肢のある作業は調査から始める

검색어 자동 완성 기능을 추가하려고 합니다.
현재 검색 실행 방식, 데이터 크기, 관련 화면 구조를 조사해 주세요.
클라이언트 검색과 서버 검색 중 현재 프로젝트에 맞는 선택지를 비교하세요.
선택지마다 수정 범위, 필요한 데이터, 검증 방법을 설명하세요.
사용자 입력 전송 방식이나 API 변경이 필요한 결정은 분명히 표시하세요.
아직 구현하지 말고 현재 자료로 판단할 수 없는 조건을 남겨 주세요.

自動補完など設計が変わり得る作業はデータの位置と大きさを知らず実装すると後で範囲が広がります。先に選択肢を調べ方向を決めて実装へ移ってください。逆に一行の文言修正に長い設計文書は不要です。難しさより「未決定の条件の数」を基準に調査段階を選べます。

8. 結果が誤った際の四つの後続依頼

初回結果が違えば不満より観察差を送ってください。画面、入力、動作順があれば再現しやすくなります。「動きません」では保存とメッセージ問題を分けられなくても、「ボタン直後に結果なしが出て応答後に一覧へ変わる」は表示条件の調査手掛かりです。

표시 조건 보완:
검색 버튼을 누른 직후 빈 결과 문구가 먼저 나타납니다.
요청 중에는 기존 로딩만 보이도록 표시 조건을 조정하세요.
이미 바뀐 안내 문구와 정상 결과 목록은 유지하세요.

범위 보완:
검색 화면 수정 외에 공통 레이아웃도 바뀌었습니다.
공통 변경이 이번 요구사항에 필요한 이유를 설명하세요.
필요하지 않은 변경만 분리해 되돌리는 방안을 제시하세요.
다른 사람이 만든 변경은 보존하세요.

검증 보완:
테스트 통과라고 보고했지만 실행 명령이 없습니다.
실제로 실행한 명령과 결과를 알려 주세요.
실행하지 않았다면 미실행으로 정정하고 가능한 검증을 수행하세요.

현재 파일 보완:
안내 문구는 제가 방금 수정했습니다.
현재 파일의 문구를 기준으로 표시 조건만 보완하세요.
이전 답변의 문구로 덮어쓰지 마세요.

各後続依頼は一つの差へ集中します。文言、状態、デザイン、形式を一度に再依頼すると以前のどの修正が誤りか追跡しにくくなります。まず動作を直し、後に文言と画面整理を別段階で任せてもよいでしょう。復元は全ファイルを戻すより無関係な変更を分けさせ、現在作業を保全する必要があります。

9. 実際の完了報告を読み、次を決める

よい報告は要求と根拠を結び付けます。「三ファイル変更」だけでは検索前状態の維持が分かりません。状態ごとのコードと検証の対応を要約させてください。下の形式をコピーすると実施済みと残りを分けやすくなります。

결과를 다음 표 형식으로 정리해 주세요.
요구사항 | 대응 파일 또는 로직 | 실제 확인한 근거 | 남은 확인
검색 전 화면 유지
요청 중 빈 결과 문구 숨김
성공 응답의 결과 0개 안내
요청 실패 시 기존 오류 안내 유지
정상 검색 결과 유지
검증 명령은 실제 실행한 것만 적고, 실패와 미실행을 구분하세요.

実コマンドが失敗すればログの最初の原因で次を定めます。「コマンドなし」は環境やツール、「期待文言と実際が違う」は動作や期待値の問題かもしれません。同じ「テスト失敗」にしないでください。コード差分が読みにくければ変更条件を簡単な文と入力例で説明させられます。

画面機能は自動検証と直接使用の両方が必要な場合があります。直接確認ではページを開き検索前を見て、結果ありとなしの検索語を順に入力します。要求失敗はプロジェクトのテストや開発用模擬応答で確認するとよいでしょう。実サービスのネットワークや運用データを任意で変える方法を基本手順にする必要はありません。

最後は今回新しく分かった事実だけ次へ引き継いでください。関連ファイルと検証コマンドが確定したら長い背景を再説明する必要はありません。全条件を永続規則にもせず、反復する約束はAGENTS.md、特定機能の要求は依頼や記録へ分ければ簡潔になります。

10. よくある質問

プロンプトは長く書く必要がありますか？ 長さより結果を変える情報が重要です。小修正は数文で始め必要な文脈を後から補って構いません。

全ファイルを指定する必要がありますか？ 分かる関連位置から伝えてください。不明なら画面名と再現手順を渡し調査を依頼できます。

毎回計画から受け取るべきですか？ 大きな範囲や設計の選択があると計画は有用です。単純な文言修正に長い計画は不要ですが、説明だけか実修正かは常に明確にするとよいでしょう。

公式の出典と確認日： OpenAI公式文書：プロンプト。2026年10月3日確認。例のパスとコマンドは自分のプロジェクトに合わせて調整してください。