Codexに機能を任せる前に範囲を定める：入力・出力・完了条件の例

Codexへの機能依頼の完了基準

手順1	ユーザーの行動を定義
手順2	入力範囲を決定
手順3	出力形式を決定
手順4	変更の境界を記録
手順5	正常・境界・失敗を検証

読む順序を整理した説明図です。実際のプログラム画面や測定結果ではありません。

Codexに「アプリにダウンロード機能を入れて」と頼むと目標は伝わりますが、どのデータをどの形式で受け取り、どこまで変えるかは残ります。空欄が多いと結果を見て再修正する部分が増えます。長い指示を無条件に書くより、入力・出力・完了条件を具体的に決めることが依頼に役立ちます。

本記事は簡単なCSVエクスポートを架空例に、依頼範囲の整理方法を説明します。実プロジェクトの修正や実行記録ではありません。ファイル名と画面名は説明用なので、自分のコード構造と要件に合わせて変更する必要があります。

1. 作業目標をユーザーの行動で表す

「エクスポート実装」より「ユーザーが一覧画面から現在の検索結果をCSVファイルで取得できるようにする」と書きます。利用者と行動を含めると目的が明確になります。内部構造を先に指定するより必要な行動を説明し、既定構造があれば関連ファイルと既存動作を追加で伝えてください。

OpenAIの公式プロンプト案内は目標、文脈、出力、境界を必要な分だけ提供するよう説明し、Codex依頼には希望動作と関連コードまたは再現手順、重要制約、検証方法を含めるよう案内しています。本記事の様式はその原則をCSV例へ適用したもので、固定の注文文や特別なキーワードが必須の形式ではありません。

目標には必要な理由も一文で記します。「運用担当者が検索結果を別の表でレビューする」という説明があれば、列名と日付表示の重要性が分かります。ただし理由だけ示して結果形式を省くとレビュー基準は残りません。目的と実際の出力条件を併せて決める必要があります。

2. 入力範囲を先に定める

CSVの入力を全データ、現在のフィルター結果、表示中の一ページのどれにするか決めます。この三つは大きく異なる結果になります。ユーザーが「検索結果」と考える範囲を文章にし、並べ替えとフィルターを反映するかも書きます。画面では20件なのに1,000件を取得するかを、Codexに勝手に推定させない方がよいでしょう。

架空要件を「現在選んだ検索条件に合う結果全体、現在の並び順を維持」とします。ページ別にデータを読み込む構造なら、画面の配列をコピーする実装だけでは不足かもしれません。関連データ要求とページ処理も確認する必要があるため、既存検索経路を調べ変更範囲を提案するようCodexへ依頼できます。

入力の例外も書きます。空結果では空ファイルを作るか、列見出しだけ作るか、案内を出すか決めます。選択項目だけを出す機能なら選択0件の動作も必要です。事前に条件を書けば、開発後に「この場合は？」と再質問する手間を減らせます。

要件項目	架空の例	不明確な場合の問題
対象データ	フィルターに合う結果全体	一ページと全結果を混同
順序	現在選択した並び順を維持	画面とファイルの順序が違う
列	名前・状態・作成日	不要な内部識別情報を含む
空の結果	案内を表示しファイルは生成しない	空ファイルがエラーに見える
時点	エクスポート依頼時点の検索条件	フィルター変更中に結果が混ざる

3. 出力形式は読者が確認できる水準で定める

出力名、文字コード、列名と順序、日付形式、空値表示を決めます。CSVにはカンマ、引用符、改行を含む値があり得るため、単純な文字列連結ですべて正しく保存できるとは仮定しません。開くプログラムを伝えると互換性確認の基準を作れます。

架空条件は「最初の行に韓国語の列名、日付はYYYY-MM-DD、欠損値は空欄、カンマ・引用符・改行を含む値を保持」と書けます。これらは検証可能です。必須ライブラリの制約がなければ、既存の方法と依存方針を調べて実装を選ぶよう任せるのが自然です。

数値に見える識別子は慎重に扱います。「0012」が数値化され先頭0を失わないよう要件を決めます。CSVを開くプログラムの自動解釈も影響するため、元の文字列と表示結果を区別して確認する必要があります。必要な識別子保持法は使用プログラムと形式に合わせて決めます。

4. 変える場所と維持する場所を別々に記録する

変更範囲は関連画面、データ処理、エクスポート関数など必要部分で定めます。維持事項は既存検索動作、画面デザインの主要構造、他形式、アクセス権など具体的に書きます。「既存機能を維持」だけでは重要動作が十分に伝わらない場合があります。

「一覧の検索・並べ替え・ページ移動は維持し、CSVボタンと必要処理だけ追加」と書けばレビュー基準ができます。性能や権限へ影響するサーバー変更が必要なら、理由と範囲を確認するよう頼めます。既存ファイルの存在と既存要件の充足は異なるため、実コードの文脈を調べる必要があります。

共同作業では修正中のファイルと担当範囲を伝えます。Codexが他の人の変更を戻さないよう、現在状態を確認して必要部分だけ修正するよう依頼してください。一機能を任せても無関係な整理、全体書式変更、依存更新まで同時に行う必要はありません。

5. 完了条件を正常・境界・失敗例に分ける

正常例は予想どおり処理される入力です。境界例は空結果、一件、大量結果、特殊文字を含む値など範囲の端に近い状況です。失敗例はデータ要求失敗やファイル生成失敗などです。大量のテストを書くより、ユーザー機能が実際に壊れ得る条件を選ぶことが重要です。

CSV例では「フィルター結果とファイル行が一致」「カンマと改行を含む名前を保持」「空結果に所定の案内」「既存検索を維持」を確認できます。目視や関連テストで確認できますが、テストファイルができただけで全条件を確認済みとは結論付けません。

実行可能環境かも確認します。テストコマンドと必要依存をCodexに確認させ、実際の実行コマンドと結果の報告を依頼します。環境制限で行えない検証は未実行と示す必要があります。コード読解の推論、テスト実行、実画面確認を分けると結果の信頼範囲が分かります。

検証種類	架空の入力	完了判断
正常	一般テキスト項目が複数	列と行が要件に一致
境界	空結果・一件	事前に定めた案内と出力
特殊値	カンマ・引用符・改行・先頭0	値の損失や行の分裂がない
失敗	検索要求の失敗	混乱するファイルの代わりに明確な状態案内
回帰	既存の検索・並べ替え・ページ移動	元の動作の維持を確認

6. すぐ修正して使える依頼例

説明用の依頼文は次のとおりです。「一覧画面にCSVエクスポートを追加してください。現在フィルターの全結果を現在の並び順で出力します。列は名前・状態・作成日で、空結果は案内だけ表示します。カンマ・引用符・改行のある値と識別子の先頭0を保持します。既存検索とページ移動は維持します。関連コードから確認し、必要変更と検証を行った後、実際の確認結果を伝えてください。」

実プロジェクトでは関連画面・パス、データ構造、既定のテストコマンドを加えます。知らないパスを作って書く必要はありません。「関連経路を探し構造を説明してから変更して」と調査を任せられます。変更理由、主要ファイル、検証結果、残る制限を短く報告するよう頼めばレビューしやすくなります。

新条件が生じたら既存条件も維持するか伝えます。「ファイル名に日付を入れて」は既定の列、空結果、特殊値保持を置き換える要求ではありません。逆に要件を変更するなら廃止条件を明示する必要があります。小修正が積み重なるほど、最終基準を一か所へ整理するとよいでしょう。

7. 結果を受け取る際の確認点

変更説明が要求動作と結び付くか確認します。全データを出すと主張するなら、実際にページを超える結果を扱うか、どこで並び順を保つか調べられます。全内部コードを理解する必要はありませんが、要件ごとに確認位置と検証結果が結び付いている必要があります。

作業前後に重要例を同条件で比較すると役立ちます。架空CSVを開いて行数、列順、特殊値を確認します。実データ検証では公開してはいけない情報を試験ファイルへ入れないよう資料を選びます。レビュー後は完了条件の充足項目と残りを区別し、次の修正を決めてください。

良い依頼は長文競争ではありません。入力範囲、結果形式、保存動作、確認例がつながると、作業依頼と結果レビューが容易になります。Codexが実プロジェクトを調べる余地を残しつつ、読者に必要な結果を具体的に定めることが要点です。

公式資料と確認範囲

• OpenAI：Codexへのプロンプト
• OpenAI：Codex Cloud

資料確認日：2026年10月5日。AIが公式資料を確認して作成しました。本文の架空の事例と計算例は実際のユーザー記録や実験結果ではありません。サービス条件・メニュー・公開資料は変わり得るため、必要条件は現在の公式案内で確認します。