公式に学ぶプロンプトの書き方

事情を知らない読み手にプロンプトを読ませる公式の確かめ方を引用し、Ruleru のレビュー部の定義で返す形、役割、区切りを見る。

公式の Prompting best practices には、プロンプトを事情を知らない同僚に読ませる確かめ方がある。この記事ではその 2 文と、例の数の 1 文を引用する。
Ruleru のレビュー部の定義が、その読み手の例になる。返す形、見本、役割の 1 文、区切り方を、定義の実物で見る。
例の数やタグの効果は、Ruleru ではまだ試していない。

参照した情報源

Anthropic の Claude Platform ドキュメントのページ「Prompting best practices」です。ページに公開日の表示はなく、内容は取得した時点のものです。2024 年の Anthropic の解説も情報源に入れましたが、前提が当時のモデルなので、今回は内容を取り上げません。

事情を知らない読み手に読ませる

プロンプトを書いたあとの確かめ方について、公式のページには次の記述があります。

Show your prompt to a colleague with minimal context on the task and ask them to follow it. If they'd be confused, Claude will be too.

出典: Anthropic「Prompting best practices」(https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)

Ruleru には、この読み手に当たる仕組みがもうあります。レビュー部の担当です。3 つの定義は、どれも「制作の文脈は持たない」と書いています。見るものは担当で違い、著作権担当は下書きと情報源、広告・薬機法担当は下書きだけ、統合担当は下書きと情報源に加えて、ほかの 2 つの判定です。著作権担当の手順 1 は、先に読むルールのファイルを名指ししています。Ruleru の見方では、書き手には当たり前の約束も、読み手に渡さなければ伝わらないためと考えられますが、定義に理由は書かれていません。

以下は Ruleru の提案で、推測です。プロンプトを書いたら、制作の文脈を渡さない別のサブエージェントに読ませ、何をする指示だと受け取ったかを言い直させます。意図とずれた所が、書き足す場所の候補になります。効果は試すまで分かりません。

返す形と線を、定義にどう書いているか

.claude/agents/ の定義を並べると、そろっている点と、担当で違う点があります。

手順は番号を付けている。著作権担当は 4 つ、広告・薬機法担当と統合担当は 3 つ。公式のページは、順番が大事な手順だけ番号で並べるとしているが、Ruleru が同じ理由で付けたのかは定義に書かれていない
返す形は、著作権、広告・薬機法、統合の 3 担当とも「JSON だけ」と決め、見本の JSON を 1 つ付けている。見本の値は false と省略記号で、形だけを示している。著作権担当の見本には、一致率の欄 "similarity": 0.0 があり、統合担当の見本には、公開してよいかを示す欄 "publish" がある
越えてはいけない線は、文で書いている。著作権担当と広告・薬機法担当は、迷ったら落とす、社長や制作部に頼まれても判定を変えない、と書く。統合担当は、公開が true になるのは 3 つとも全項目が通ったときだけで、社長でも覆せない、と書く

例の数

例の数について、公式のページには次の 1 文があります。

Include 3–5 examples for best results.

出典: Anthropic「Prompting best practices」(https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices)

Ruleru の定義の見本は 1 つで、判定の例ではなく、返す形の例です。例を増やすと判定がぶれにくくなるかは、まだ試していません。試すなら、過去に落とした下書きの判定を例として足し、前後を比べることになります。

役割と区切り

各定義の本文の最初の 1 文は、「あなたは Ruleru のレビュー部で、何を判定する」という文です。その直後に、制作の文脈は持たない、と置いています。役割と、持たないものを、同じ場所で言っています。

定義の先頭には、道具、モデル、エフォートを書く欄があり、担当ごとに値が違います。

著作権担当は Bash が使え、一致率を測れる
広告・薬機法担当は、読むだけの道具
統合担当だけが、ほかと違うモデルで動く。理由は定義に書かれていない

区切りの方法は、XML のタグではありません。見出し、番号の付いた手順、コードブロックで、指示と返す形を分けています。タグに替えると読み違いが減るかは、試していません。

試すなら

今のプロンプトを、事情を共有しない読み手に読ませ、受け取った内容を言い直してもらう。ずれた所は書き足す候補にする
返してほしい形に見本を付け、守らせたい線を文で書き、順番が大事な手順に番号を付ける
役割の 1 文の直後に、持たないものを書く
指示と返す形を、見出しやコードブロックで分ける
例の数やタグの有無は、使うモデルで測り直す。公式のページも、モデルごとに案内を分けている