AIに仕事を頼むとき、「適切に分類してください」と書いてしまうことがあります。読む側の解釈次第で結果が変わる書き方です。
依頼文5件で数えたところ、曖昧な語は6個ありました。書き直すと0個になりますが、それだけでは結果を確かめられません。判定できる条件が要ります。
依頼文5件を実際に測りました。曖昧語は6個から0個になりますが、判定できる条件を足して初めて0件から5件になります。
プロンプト設計で何を直すべきかを、実際の依頼文で測りました。用意したのは実務で書かれがちな依頼文5件と、その書き直しです。
測り方は2つです。解釈が分かれる語の数と、機械で判定できる条件が含まれるか。どちらも本当に実行して数えています。
ただし検出は語の一覧と正規表現による粗い判定で、文の意味を読んでいるわけではありません。目安として見てください。
// 読み手によって解釈が変わる語。判定の基準にならない const VAGUE = [ '適切に', '必要に応じて', 'なるべく', 'できるだけ', 'いい感じに', 'しっかり', '丁寧に', '分かりやすく', '簡潔に', 'ある程度', ]; // 機械で判定できる手がかり。数値・単位・件数・形式 const CONCRETE = /(\d+\s*(件|文字|行|個|日|円|%|秒|つ|列|種類)|JSON|CSV|以内|以上|以下|必ず|禁止|一致するか|昇順|降順|のみ)/;
依頼文 曖昧語 判定条件 問い合わせ内容を適切に分類してください 1個 なし 議事録をなるべく簡潔にまとめてください 2個 なし 必要に応じて担当者に連絡してください 1個 なし 請求書の内容をしっかり確認してください 1個 なし データを分かりやすく整理してください 1個 なし 曖昧語の合計 書き直す前: 6個 書き直した後: 0個 判定条件を含む件数 書き直す前: 0 / 5 書き直した後: 5 / 5 文字数の合計 書き直す前: 93文字 書き直した後: 234文字(2.5倍)
5件すべてに曖昧な語が入っていました。しかも判定できる条件はどれにも含まれていません。
ここが要点です。「適切に分類してください」から「適切に」を消しても、「分類してください」になるだけで、何をどう分ければ正しいのかは分かりません。
書き直した文では、分類先を4つ列挙し、返す形も指定しています。ここまで書いて初めて、返ってきた結果が正しいかを機械で確かめられます。
4番目を忘れがちです。「連絡してください」と書くと、本当に送信されることがあります。書き直した文では「送信はしないでください」を明記しました。
代償は文の長さです。93文字が234文字になりました。2.5倍です。この分は依頼のたびに毎回送られます。
曖昧語を消すのは入口。判定できる条件が入って初めて確かめられる。
As the term implies, the primary focus of prompt engineering is how to write effective prompts, particularly system prompts.原文Anthropic Engineering「Effective context engineering for AI agents」 この内容の有効期限2027-02-17
依頼文を、結果を確かめられる形に組み立てる作業です。書き方の工夫というより、条件の書き出しに近くなります。
プロンプト設計は、AIへの依頼文を組み立てる作業です。Anthropicも、その主眼は効果的なプロンプト、とりわけ毎回送る指示をどう書くかにあるとしています。
実際にやることは、書き方の工夫というより条件の書き出しに近い作業です。何を入力とし、何を返させ、どうなっていれば正しいのか。ここを決めます。
前の節で書き直した文を見ると分かります。うまい言い回しを探したのではなく、分類先を列挙し、件数を決め、形式を指定しただけです。
書き方の基準も示されています。明確で、単純で直接的な言葉を使い、相手にとってちょうどよい粒度で示すべきだという整理です。
細かすぎても抽象的すぎても効きません。1手ずつ全部指示すれば自由が消え、抽象的に書けば解釈が分かれます。
プロンプト設計はいくつかの手法の総称でもあります。毎回送る指示の書き方はシステムプロンプトの記事、例で形を示す方法はFew-shotの記事、途中の考えを出させる方法はChain of Thoughtの記事で扱っています。
測ってみて目立ったのは、やってほしいことは書くのに、やってほしくないことは書かないという傾向でした。「必要に応じて担当者に連絡してください」は、本当に送信されうる書き方です。編集部では、外部に影響が出る操作について必ず「しないでください」を明記するようにしています。
System prompts should be extremely clear and use simple, direct language that presents ideas at the right altitude for the agent.原文Anthropic Engineering「Effective context engineering for AI agents」 この内容の有効期限2027-02-17
結果を機械で確かめられるところまでです。それを超えて書き足しても、送信量が増えるだけになります。
プロンプト設計で迷うのは分量です。基準は1つで、返ってきた結果が正しいかを確かめられるかになります。
Anthropicは、期待する動作を完全に示せる最小限の情報を目指すべきだとしています。短ければよいのでも、詳しければよいのでもありません。
前の節で2.5倍になったのは、判定条件を足したぶんです。それを超えて丁寧に書き足しても、確かめられる範囲は広がりません。
判定できる条件を書いたら、実際に判定する処理も書いてください。書いただけでは守られたかどうか分かりません。
返す形を決めたなら形式を検査する、件数を決めたなら数を数える。この検査の置き方はガードレールの記事で、返す形を宣言する方法はFunction callingの記事で扱っています。
4番目に注意してください。1回あたりの正解率が50%を切っていると、回数を増やすほど悪くなります。詳しくは自己整合性の記事で扱っています。
確かめられるところまで。それ以上は送信量が増えるだけ。
Regardless of how you decide to structure your system prompt, you should be striving for the minimal set of information that fully outlines your expected behavior.原文Anthropic Engineering「Effective context engineering for AI agents」 この内容の有効期限2027-02-17
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る