ライフスタイル

目的が伝わる依頼の書き方

よい依頼は成果、背景、制約、完了条件を明確にします。「ページを改善」だけでは速度、見た目、操作性のどれか分かりません。まず観察できる動作へ言い換えます。

読了目安 12 分 · 操作 20 分

作業の流れを表す図です。製品画面の画像ではありません。
画像:Mokaair (© Mokaair)
総目次へ:Codex 学習ガイド:全記事の目次

入門 · Desktop / mobile / CLI / VS Code / JetBrains / cloud

この記事の目次
  1. このレッスンの到達点
  2. 繰り返せる開始状態を用意する
  3. 手順 1:曖昧な依頼の不足を見つける
  4. 手順 2:実行できる依頼を書く
  5. 手順 3:回答の長さより成果で判断する
  6. 結果が違うときは再現例を補う
  7. 三つのよくある問題と修正
  8. 追加練習、復元、出典

このレッスンの到達点

繰り返せる開始状態を用意する

教材の expected を新しい codex-prompt-lab にコピーし、前回の変更済みコピーを使いません。五ファイルを確認し、index.html の New task、Add task、Read the project README を探します。この三つの表示文字が今回の資料で、プロジェクト全体を会話に貼る必要はありません。

と同じ表示方法を使えます。Windows は py -m http.server 4173 --bind 127.0.0.1、macOS/Linux は python3 -m http.server 4173 --bind 127.0.0.1 をコピー内で実行し、http://127.0.0.1:4173 を開きます。Git は不要ですが、比較や復元用の原本を残してください。

手順 1:曖昧な依頼の不足を見つける

「フォームを良くして」だけでは対象者、問題、変更範囲、完了条件が分かりません。色、項目、ボタン、データ構造、不要なパッケージまで変わるかもしれません。誤操作というより依頼の解釈が広すぎる場合があります。「初めて来た人が小さなタスクを一件追加できると分かる」など利用者の成果を先に示します。

目標、現状の資料、制約、検証条件を補います。毎回四見出しが必須という意味ではなく、情報漏れの確認です。文言変更は数行で足り、多数ファイルの機能追加なら背景や段階計画が必要になります。専門的に見せるための不要な役割設定、ツール一覧、根拠のない時間指定は追加しません。

手順 2:実行できる依頼を書く

次を codex-prompt-lab の Codex タスクへ送り、OS のシェルには入力しません。一つの HTML と二つの文字変更を指定し、ラベル、イベント、データ形式を維持して実際の確認を求めます。New task は見える入力ラベルとして残し、すべての文言を同じ語に変えるわけではありません。

自然言語の依頼:練習プロジェクトの Codex タスクに貼り付ける · text
Goal: make the existing todo form wording clearer for a first-time visitor.
Context: this folder is the unchanged Small Steps expected practice version.
In index.html only:
- Change the submit button text from "Add task" to "Save task".
- Change the input placeholder to "Plan one small step".
Keep the visible "New task" label, input id/name, maxlength, required attribute,
button type, JavaScript behavior, stored data and all other files unchanged.
Do not install packages or deploy anything.
Validate by adding Read, completing it, checking Completed, and refreshing.
Check that whitespace-only input does not create a task.
Run node --test core.test.mjs. If browser checks are unavailable, list them as not run.
Report the exact changed strings, files and evidence.

既にファイルにある背景は読ませ、履歴全体より正確なファイル名を渡します。実画面に Add task がなければ原版かを先に確認してください。異なる開始状態へ無理に依頼を当てはめたり、全ファイルの似た文を一括置換させたりしません。再現可能性の出発点は状態の一致です。

手順 3:回答の長さより成果で判断する

完了後の index.html はボタン文言と placeholder だけが変わり、New task と入力の関連、type="submit"、id、name、maxlength、required は残るはずです。他四ファイルも原版と比べ、余分な構造変更がないか見ます。回答が短くても正しい差分と検証があれば十分です。長い説明は存在しない変更や結果の代わりになりません。

HTTP 表示で Read を追加・完了し、Completed と再読込後の保存を確認します。空白では追加されず、Tab で入力と送信に移れることも変更前と同じであるべきです。文言が正しくても送信不能なら不合格で、次の依頼では「使いにくい」だけでなく実際の症状を説明します。

結果が違うときは再現例を補う

Save task は正しいのに placeholder が古い場合、保存と再読込を確認してから次の追補を送ります。正しい部分、現状、期待を分け、ページ全体の再作成を求めません。途中で要件を変えたなら、前の条件を何で置き換えるか示し、矛盾する二条件を残さないでください。

追加の依頼:ボタンが正しく placeholder だけが違う場合に使用する · text
The button text is correct; preserve that change.
After saving and refreshing, the placeholder still reads "Read the project README".
Expected placeholder: "Plan one small step".
Inspect index.html and correct only the remaining placeholder mismatch.
Report the relevant diff and any verification you can actually perform.

大きな作業は で手順と不明点を整理できますが、計画は検証ではありません。テスト予定は結果ではなく、データ保持の約束も実物で確認します。ログインや同期の要否など構成を変える不足は、依存機能を作る前に答える方が手戻りを減らせます。

三つのよくある問題と修正

変更が多すぎれば「全面最適化」などを取り除き、指定ファイルと維持項目を示して無関係な差分だけ戻します。質問が続く場合は判断に影響する条件を答え、通常の字体や名前は既存スタイルに任せます。完了に証拠がなければ「完了」の言い換えではなく、実際の命令結果と未実施項目を求めます。

失敗が続くなら最小再現、エラー、最後の正常状態を残して一問題に絞り、無関係な履歴を毎回貼り直しません。長い作業はを使い、繰り返す規約は へ置き、各依頼は今回の変更に集中させます。

追加練習、復元、出典

追加練習は expected の新しいコピーから始めます。ボタンが Add task、placeholder が Read the project README であることを確認し、直前に変更したコピーは使いません。ボタンだけを Create task にし、このコピーの元の placeholder を保つ依頼を自分で書きます。index.html の変更文字列が一つだけであることを確認し、追加、空入力、再読み込みを再検証します。終了後は保存した expected 原本から各練習コピーの index.html を戻します。他のファイルは交換不要です。Python は Ctrl+C で停止します。Codex の会話を閉じてもファイル変更は戻りません。

依頼の原則は 2026-09-14 の公式 Prompting 文書で確認し、フォーム要件、入力、検証手順は独自に作成しました。英語入力例は各言語共通ですが、応答が逐語一致する保証はなく成果を検証します。次はやで再現入力と期待結果を使います。

依頼の要素今回の具体化
目標初めての利用者に分かるフォーム
資料expected の index.html
制約二つの文字だけ、データと動作を保持
検証追加、完了、空入力、再読込

07. 目的が伝わる依頼の書き方 — 作業の流れを表す図です。製品画面の画像ではありません。 Goal → Constraints → Acceptance
07. 目的が伝わる依頼の書き方 — 作業の流れを表す図です。製品画面の画像ではありません。 Goal → Constraints → Acceptance · 画像:Mokaair (© Mokaair)
詳しい説明を読む

Goal to Constraints to Acceptance

依頼文の練習結果。入力欄のヒントは Plan one small step。Save task ボタンに橙色のフォーカス枠が表示されています。
元の教材に本記事の指定変更を適用した参考成果。Windows / Edge 153.0.4234.32、2026-09-14 の実画像です。橙枠はキーボードフォーカスでデータは架空です。幅 390px のレスポンシブ表示で、実物のスマートフォン、Codex UI、モデル実行記録ではありません。 · 画像:Mokaair (© Mokaair)
依頼文の練習結果。入力欄のヒントは Plan one small step。Save task ボタンに橙色のフォーカス枠が表示されています。
元の教材に本記事の指定変更を適用した参考成果。Windows / Edge 153.0.4234.32、2026-09-14 の実画像です。橙枠はキーボードフォーカスでデータは架空です。幅 1280px のレスポンシブ表示で、実物のスマートフォン、Codex UI、モデル実行記録ではありません。 · 画像:Mokaair (© Mokaair)

総目次へ

  • ライフスタイル

    Codex 学習ガイド:全記事の目次

    導入と最初のタスクから MD の指示、高度な連携まで、60 レッスン・十単元を予定しています。習熟度、環境、目的、コマンドで次の記事を探せます。未公開の記事には状態を表示します。

  • ライフスタイル

    Worktree とタスクの分離

    Worktree は一つの Git リポジトリに別ブランチの作業場所を作ります。ファイルは分かれても DB、ポート、外部サービスは共有される場合があります。

  • ライフスタイル

    実践:小さな Web サイトを作る

    brief.md から Small Steps のタスクサイトを計画・制作し、追加、完了、削除、絞り込み、ローカル保存を実装します。HTML、CSS、データ関数、画面イベント、テストを分け、Node とブラウザーで検証して再起動・復元の手順を残します。

  • ライフスタイル

    使用量と効率:やり直しを減らす

    条件、モデル設定、時間、成果を記録し、不要な再試行と過剰な文脈を減らします。

最新の旅の情報・ガイド

出典

ライフスタイル