Codexに作業を頼むときの依頼文：目的・対象・確認方法を伝える

Codexへの依頼では、細かい操作を全部指定するよりも、「何を完成させたいか」「どのファイルを対象にするか」「どう確かめるか」を揃えると、結果を判断しやすくなります。ここでは、ブログや文章の更新に使える依頼の組み立て方を紹介します。

この記事の例文は編集部の提案です。特定のモデルで成功率を測った実験結果ではありません。Codexの利用開始については公式クイックスタートとWindowsでの始め方をご覧ください。

毎回共通で伝える読者像や編集ルールは、ブログ用AGENTS.mdのひな形へまとめられます。このページの依頼文には、今回の対象と完成条件を残します。

実際のブログ更新にこの依頼文を使う場合は、原稿・確認日・公開状態を管理する流れを合わせて読むと、終了条件を決めやすくなります。

完成した状態を一文で書く

依頼文に迷ったら、次の4項目をメモしてから文章にしてみてください。すべてを長く書く必要はありません。

例えば「原稿を読みやすくする」が目的、「guide.md」が対象、「URLと画像」は残すもの、「意味とリンクを確かめる」が確認方法です。下の例文で、それぞれを自分の作業に置き換えられます。

「この記事をよくして」だけでは、読みやすさ、情報の更新、検索流入の改善のどれを優先するのか分かりません。例えば「初めて使うWindowsユーザーが、導入して最初の依頼を送れる記事にする」と書けば、確認する範囲が見えてきます。

読者にしてほしいことが決まると、削る段落と補う説明も判断しやすくなります。文字数を増やすことそのものを完成条件にしないのがポイントです。

対象と残すものを指定する

同じタイトルの記事が複数ある場合は、タイトルだけでなくファイルやURLを示します。既存画像、公開日、URLなど、継続したい資産も書いておきます。

対象は「Windowsでの始め方」の原稿です。
初めて使う人が準備から最初の依頼まで進められる内容へ更新してください。
既存URLとアイキャッチは継続してください。
古い記述は公式資料で確認し、確認できない点を断定しないでください。

調査と書き直しを一つの依頼に含める

調査結果を別のサービスに貼り直す前提にせず、参照先の確認から原稿の保存までを同じ作業で扱う形にできます。下の例は運用の設計例であり、利用環境で使える検索・ファイル操作の範囲は別途確認してください。

まず現在の本文と公式資料を照合してください。
矛盾している箇所を直し、参照URLと確認日を原稿に残してください。
体験していないことを「試しました」と書かないでください。
更新後は内部リンクと、説明した手順の前後関係も点検してください。

終了時の報告を決める

長い作業ログより、「何が変わったか」「何を確かめたか」「何が未確認か」があると次へ進みやすくなります。

終了時は、変更したファイル、主な修正点、確認結果、残っている問題を報告してください。
記事ファイルを保存したことと、公開サイトへ反映したことを分けて説明してください。

うまくいかなかったら条件を一つずつ直す

次回も使える依頼文のひな形

角括弧の部分を自分の作業に置き換えて使ってください。対象の原稿が分からないときは、最初に「候補を一覧にして、まだ変更しないで」と頼めます。

目的：[誰が何をできる状態にしたいか]
対象：[原稿のファイル名、またはURL]
残すもの：[URL、画像、必要な説明など]
確認方法：[意味の保持、リンク、表示など]

対象が見つからない場合は、推測で別のファイルを変更せず知らせてください。
終わったら、変更した内容・確認できたこと・未確認のことを報告してください。

報告を受け取ったら、対象ファイルが合っているか、残すものが維持されているか、指定した確認が行われたかを見ます。未確認の項目が残っていれば、その項目を指定して追加の確認を頼んでください。

説明が専門的すぎたなら読者像を補います。本文はよくても操作を再現できなければ、対象OSやアプリの画面を具体化します。修正のたびに依頼全体を書き換えるより、どこが期待と違ったかを一つずつ伝えると、判断の基準が保てます。

継続運用では、この共通条件をプロジェクトの運用メモに残します。ブログ記事を更新する流れでは、原稿・確認日・公開状態をどう分けるかを説明します。

作業が終わった後は、変更内容の確認と一部だけ戻す手順で、依頼どおりかを点検できます。