Codexへの指示文に何を書く？個人ブログ運営で使っているタスク依頼テンプレート

Codexにブログ運営を頼み始めると、「指示文には何を書けばよいのか」と迷うことがあります。毎回細かく説明すると長くなります。一方で、短く書きすぎると、対象ファイルや公開範囲が曖昧になります。

私のブログ運営では、すべてのルールを毎回の依頼文へ詰め込んでいません。繰り返し守ってほしいことはAGENTS.mdへ、現在の状態はKnowledgeなどへ、そのタスクで変わる情報は依頼文へ分けています。

AGENTS.mdだけでは今回のタスクは決まらない

前回の記事では、AGENTS.mdをCodexに継続して守ってほしい作業ルールの置き場所として整理しました。たとえば、推測で事実を補わない、指定外のファイルを変更しない、公開操作を勝手に行わない、といった内容です。

CodexのAGENTS.mdには何を書く？個人ブログ運営での共通ルールとサイト固有ルールの分け方で紹介したように、AGENTS.mdは「どう動くか」を伝える場所です。

しかし、「今回は対象記事を作る」「このフォルダだけを変更する」「公開はしない」という情報は、タスクごとに変わります。これをAGENTS.mdへ入れると、次のタスクでは古い指示になってしまいます。

AGENTS.mdが作業の共通ルールなら、依頼文は今回の作業票です。この役割を分けると、長い説明を毎回書かなくても、今回の判断に必要な情報を残せます。

依頼文の最初にタスクを特定する

まず、どの作業を頼んでいるのかを特定できる情報を書きます。私の運用では、次の項目を冒頭に置きます。

項目	書く内容	曖昧にすると起きること
プロジェクト名	どのブログ・プロジェクトの作業か	別サイトのルールや情報を参照する可能性がある
タスク名	今回の作業を識別する名前	作業履歴や成果物との対応が分かりにくい
タスク種別	新規記事、レビュー、リライトなど	新規作成と既存記事の修正を取り違えやすい
貼り付け先	Codexの新規タスクか、既存タスクか	前提を引き継ぐ作業かどうかが曖昧になる

たとえば「ブログの記事を作ってください」だけでは、どのブログの、どの種類の記事か分かりません。記事番号やタスク名があると、作成したファイルや後の確認を追いやすくなります。

最初に「何の作業か」を固定すると、後の対象範囲や完了条件も書きやすくなります。

対象範囲と、実行前に必要な材料を書く

次に、作業の対象を限定します。対象サイトID、対象記事、対象ファイルやディレクトリを書きます。

記事作成なら「codex-blogの新規記事」と書くだけでなく、既存記事との関係、参照するKnowledge、近い形式のHTMLまで示します。OpenAI公式の案内でも、Codexへの依頼はGitHub Issueのように具体化し、必要に応じてファイルや関連資料を示す考え方が紹介されています。詳しくはOpenAI公式のCodex活用例を参照できます。

ただし、対象を細かく書くことと、関係するファイルをすべて列挙することは同じではありません。必要なファイルだけを指定し、残りはAGENTS.mdや既存の管理情報に従って確認してもらいます。

対象範囲を書く目的は、Codexに情報を増やすことではなく、触ってよい範囲を決めることです。対象外まで作業を広げてほしくない場合は、「変更しないファイル」や「今回は扱わない作業」も書きます。

やることと、やらないことを分ける

依頼文では、作業内容だけでなく、対象外の作業も明記しています。記事作成を頼む場合なら、本文と貼り付け用HTMLを作るのか、アイキャッチまで作るのか、公開後の同期まで行うのかを分けます。

私のブログ運営では、記事作成、レビュー、画像、公開、公開後同期を別の作業として扱うことがあります。今回の依頼で「記事本文とHTMLまで」と決めたなら、画像作成やはてなブログへの貼り付けは含めません。

「全部やってください」と書くと、Codexが作業を進められないというより、完了地点が複数になります。本文が完成した時点なのか、公開まで終えた時点なのか、公開後の台帳更新まで含むのかが分からなくなるためです。

依頼文で「やらないこと」を決めると、作業の完了地点も見えやすくなります。

公開・Git・はてなブログ操作の有無を明記する

ブログ運営では、ファイルを作る作業と、外部サービスへ反映する作業を分けています。依頼文には、はてなブログ上の操作、記事公開、Git操作の有無を明記します。

確認する操作	依頼文で決めること
はてなブログ	貼り付け、編集、公開を行うか
記事公開	未公開のdraftとして止めるか、公開準備までか
Git	差分確認だけか、commit・pushまで行うか
サブエージェント	使用するか。使用する場合は理由と範囲

これはCodexにできるかどうかを確認するためだけの項目ではありません。人間が判断する操作と、Codexに任せる操作の境界を、作業前に決めるために使っています。

私の現在の運用では、公開するかどうか、実体験が事実として正しいか、公開後の表示に問題がないかは人間が確認します。Codexに候補や下書きを作ってもらうことと、そのまま外部へ反映することは別です。

このように依頼の範囲を整理しておくと、外出中でも「まず原稿作成」のように短い指示を出せます。Codex Remoteをブログ運営で使っている実例では、スマホから記事作成や修正を依頼し、PCで詳細確認と公開判断を行う流れを紹介しています。

「公開しない」と書くことも、作業範囲を決める大切な指示です。人間が確認する地点を残す考え方は、ブログ運営でCodexに任せない作業でも詳しく整理しています。

実際に使っている依頼文を短くすると

今回のような新規記事作成の依頼を一般化すると、次のような形になります。実際の内部プロンプト全文やローカル環境の情報を公開する必要はありません。

## プロジェクト
個人ブログ運営プロジェクト

## タスク
新規記事作成｜Codexへのタスク依頼テンプレート

## 種別・対象
新規記事。対象サイトは運営中のブログ。
既存の関連記事と記事管理ルールを確認する。

## やること
読者向け本文と、はてなブログ貼り付け用HTMLを作成する。
継続ルール、現在状態、今回の依頼文の役割分担を説明する。

## やらないこと
はてなブログへの貼り付け・公開、画像作成、Git操作は行わない。
確認できない情報は事実として書かない。

## 完了条件
記事フォルダ、本文、HTML、公開前メモを作成する。
内部リンク、未確認事項、人間の確認点を報告する。

この例で重要なのは、決まった言い回しではありません。プロジェクト、対象、作業範囲、対象外、完了条件が見えることです。作業内容に応じて項目を減らしても構いません。

テンプレートは文章の型ではなく、判断に必要な項目の型として使っています。

長い依頼文を毎回作ることが目的ではない

情報を増やせば、いつでも作業がうまくいくとは限りません。重要な情報が長い文章の中に埋もれると、今回のタスクで判断すべきことが見えにくくなる場合もあります。

私の運用では、役割ごとに置き場所を分けています。

情報	主な置き場所
何度も守ってほしいルール	AGENTS.md
現在の公開状態や運用方針	Knowledge
過去の変更・判断	Weekly
次に行う作業	Next Actions
今回変わる対象・範囲・完了条件	タスク依頼文

依頼文は、ルールや現在状態の保管場所ではなく、今回の作業を特定するための入口です。不足する材料があるときは、Knowledgeや既存記事を参照先として指定し、確認できなかったことは「未確認」として残します。

まとめ

Codexへタスクを頼むときは、プロジェクト名やタスク名で作業を特定し、対象サイト・対象ファイル・必要な材料を示します。そのうえで、やること、やらないこと、公開・Git操作の有無、完了条件を決めます。

私のブログ運営での整理は、次の一文にまとめられます。

毎回の依頼文を長くすることが目的ではありません。Codexが判断すべき範囲と、人間が確認する範囲を先に分けることで、作業結果を確認しやすくしています。

書くべきなのは情報の量ではなく、今回の作業に必要な境界です。