商品ページの見出し案を受け取ることと、その見出しをサイトのファイルへ反映することは別の仕事です。
Codexは、作業環境の中でファイルを読み、変更し、検証する用途に使えます。
便利さを活かすには、作業場所と任せる操作を先に揃える必要があります。
このレッスンでは、架空の商品案内を例に、相談と実作業を区別し、最初の依頼を設計します。
この記事で学ぶこと
- 回答と実作業の終点を分ける
- 現状確認から検証までをつなぐ
- 人が評価できる範囲から始める
回答から成果物までを区別する
チャットで文章の候補を得た段階では、既存のサイトは変わっていません。
人が採用案を選び、ファイルへ貼り付け、表示を確認する工程が残っています。
Codexへ実作業を依頼する場合は、その工程の一部を任せられます。
ただし、使える道具や対象は、環境と権限によって異なります。
すべての場所で同じ操作ができるとは限りません。
例えば「商品の説明を分かりやすくして」という相談なら、改善案を会話で返すこともできます。
「指定ページの見出しを修正し、変更内容を確認する」という依頼なら、ファイルの編集を含みます。
どちらも文章の改善ですが、後者は保存済みの成果物へ影響します。
作業開始前に、提案だけか編集までかを分けます。
最初の依頼には、成果物の形を添えてください。
「見出し案を3つ」「指定ファイルの変更」「検証結果を添えた下書き」では完了状態が違います。
実装できたことと公開されたことも同じではありません。
何が手元に残れば仕事が終わるかを明示すると、AIと人が同じ終点に向かえます。
依頼する段階が曖昧なら、成果の置き場所から考える方法があります。
候補を比較したいなら会話、既存ページへ採用済みの文言を反映したいならファイルです。
複数案を全部実装する必要はありません。
案を決める判断と反映する作業を分けることで、試行に使う時間と変更範囲を抑えられます。
リポジトリを仕事場として理解する
リポジトリは、ファイルと変更履歴を管理する単位です。
Webサイトなら、画面を作るコード、文章、画像、設定、確認用の仕組みなどが含まれます。
Codexへ渡す仕事場を選ぶときは、どのプロジェクトかを確かめます。
名前が似た別案件や、本番の運用資料と取り違えないことが必要です。
架空の研修サイトで「問い合わせボタンの文言を直す」なら、サイトの説明資料と対象画面が入口になります。
作業に関係のない会計資料や顧客一覧まで含める必要はありません。
一方で、対象ファイルだけを抜き出すと表示の仕組みが分からない場合もあります。
必要な背景を残しながら、今回の対象を限定します。
作業場所がローカルか、隔離された作業環境かによっても、見えるファイルや使える道具は変わります。
表示されている場所と実際の対象を確認し、成果物の保存先を把握します。
環境を理解せずに「パソコンに保存したはず」と判断すると、別の場所の古いファイルを見てしまうことがあります。
保存先も依頼の一部として扱います。
仕事場を渡すときは、既存の未完了作業がないかも確認します。
途中の変更があれば、今回の依頼で触れてよいかを区別します。
Codexが見る差分がすべて今回の作業とは限りません。
開始状態の一覧を残しておくと、終了後に自分の依頼で生じた変更を見分ける手掛かりになります。
読む・変える・確かめるを分ける
作業は、現状を読む、必要な部分を変える、結果を確かめるという3段階に分けると理解しやすくなります。
現状を読む段階では、対象の仕組みと既存のルールを把握します。
変更段階では、依頼に必要な範囲を編集します。
検証段階では、変更した場所と影響を受ける利用場面を確認します。
例えばボタンの文言を「送信」から「資料を請求する」へ変えるなら、表示場所と実際の動作を最初に確認します。
単に文字列を置き換えると、別のフォームにも同じ表現が出るかもしれません。
共有されている部品なのか、特定ページだけの文言なのかで変更対象が変わります。
小さな修正にも現状確認の意味があります。
依頼では、この3段階を必要な詳しさで示します。
「まず対象を特定し、表示文言だけを変更し、リンク先と狭い画面の表示を確認する」という形です。
最初から特定の実装方法を決めつけず、守る動作と成果を伝えます。
既存の仕組みに合わせて進めてもらうことで、不要な作り直しを減らせます。
工程の途中で分からない点が出た場合は、問題の種類を示してもらいます。
対象ファイルが不明、仕様が未定、検証環境がない場合では次の行動が違います。
単に作業できないと報告するより、不足する情報と進められる範囲を分ければ、人が必要な材料だけを追加できます。
任せる判断の範囲を定める
Codexにファイル編集を任せても、商品の条件や事業上の約束を自由に変更してよいわけではありません。
文言を短くする判断と、料金を変更する判断は別です。
どの情報を確定事項として扱い、何を提案として返すかを分けます。
担当者が決める条件は、根拠とともに渡す必要があります。
架空の研修ページで「誰でも受講できます」と書く前に、対象年齢や事前準備の条件があるかを確かめます。
Codexは条件の矛盾や不足を探す補助には使えますが、組織として許可していない約束を確定する役割ではありません。
不明な部分は確認事項へ置き、見た目を整えるために埋めない指示にします。
公開や外部送信についても、既に許可された範囲を確認します。
下書きの修正だけを依頼した場合、公開まで含めたことにはなりません。
反対に、明確に許可した通常作業を毎回止める必要はありません。
判断の境界を決めることで、必要な確認だけを残し、作業を前へ進められます。
判断を任せる場合も、基準を渡すことが必要です。
候補の中から短い見出しを選ぶなら、対象読者と必要な情報を示します。
担当者の好みを過去の会話から推測させるより、使う場面に合う条件を明示します。
任せた判断の理由を成果物と一緒に確認すると、次回の依頼へ活かせます。
最初の成果を自分で評価する
初回は、見た目と動作を自分で判断できる小さな修正を選びます。
成果を評価できない仕事を丸ごと任せると、報告の言葉だけで採用することになります。
ボタン文言なら、変更前後、遷移先、周囲の説明との整合を確認できます。
合格条件が明確な仕事ほど、使い方の学習に向いています。
作業後は変更ファイルを開き、差分を見ます。
差分は変更前後の違いです。
予定した文言以外に何が変わったかを確認し、理由が分からない変更は説明を求めます。
テストが成功した報告も、何を検証したかまで確かめます。
文章が正しいことと、コードが構文上問題ないことは別の確認です。
記録には、依頼内容、修正箇所、確認結果を短く残します。
次の依頼を良くする材料として、時間がかかった箇所や認識のずれも書きます。
うまくいかなかったら、操作を広げる前に入力や完成条件を見直します。
Codexを使うことを目的にせず、人が確認できる成果へ結び付けます。
最初の試行では、速さの評価を急がないようにします。
準備と確認の方法を学ぶ時間も含まれるためです。
操作の一巡が分かった後で、同じ程度の修正にかかる時間を比べます。
小さな成功を無条件に大きな仕事へ広げず、確認できる範囲を少しずつ増やすことが扱いやすい進め方です。
実践課題
実践課題：初回の依頼を設計する
つくるものは、練習用の商品ページへ出す依頼文です。
用意するのは、公開されていない架空のページと、変更したい文言です。
価格や公開設定は対象に含めず、読む・変える・確かめるが一巡する内容にします。
コードが読めなくても結果を判定できる範囲を選んでください。
- 対象ページと困りごとを指定する
- 提案だけかファイル編集までかを決める
- 維持する条件と変更範囲を書く
- 表示と動作の合格条件を3つ置く
架空の完成例：「資料請求ページのボタンを『資料を請求する』へ変更する。送信先と料金説明は維持する。変更ファイル、表示確認、未確認事項を報告する。本番公開は今回の対象に含めない。」
自己確認
- 対象と保存先が分かる
- 許可した操作が明確である
- 成果物から合否を判断できる
まとめ
Codexへ依頼するときは、提案、編集、検証、公開を区別します。
仕事場と完成状態を揃えれば、小さな修正から使い方を学べます。
次は、結果を自分で確かめられる題材で、練習用の作業場所を準備してください。
- 回答と実作業の終点を分ける
- 現状確認から検証までをつなぐ
- 人が評価できる範囲から始める
