機能するシステムプロンプトの書き方

システムプロンプトとは、会話のすべてのターンを枠づける常設の指示です。ユーザーメッセージは変わりますが、システムプロンプトはとどまります。それは、言語モデルの上に築かれたアプリケーションにおいて、最もてこの効くテキストでありながら、最も雑に書かれがちなものでもあります。本ガイドは、百番目の入力でも一番目と同じように振る舞うシステムプロンプトの書き方を、順を追って解説します。

システムプロンプトは何のためにあるのか

システムプロンプトを、タスクではなく職務記述書だと考えてください。タスクは各ユーザーメッセージで届きます。システムプロンプトは、すべてのタスクをまたいで真であること——アシスタントが誰で、何をしてよく、答えをどう整形すべきで、決して何をしてはならないか——を定めます。同じ指示をすべてのユーザーメッセージで繰り返している自分に気づいたら、その指示はシステムプロンプトに属します。

この区別が重要なのは、二つの役割が異なる扱いを受けるからです。システムプロンプトはモデルがセッション全体を通じて条件づけられる安定した文脈であり、ユーザーメッセージは可変の入力です。永続的なルールをシステムプロンプトに置くことで、会話が漂っても効力を保ち、リクエストごとのメッセージを短く、実際のタスクに集中させられます。

役割と範囲から始める

システムプロンプトの最初の仕事は、二つの問いに答えることです。このアシスタントは何で、何のためのものか。漠然とした役割(「あなたは親切なアシスタントです」)は、モデルに拠り所を何も与えません。具体的な役割(「あなたは請求システムのサポート担当です。ユーザーが請求内容を理解し、争いを解決するのを助けます」)は、ユーザーの最初の一語が届く前に、もっともらしい応答の空間を狭めます。

範囲がもう半分です。アシスタントが何をするかを述べるのは良いことですが、何をしないかを述べる方がしばしばより価値があります。請求を扱うと告げられたアシスタントも、そうしないよう告げない限り、料理についての質問に喜んで答えてしまいます。境界を明示的に定めましょう。「請求の範囲外の要求があれば、丁寧に範囲外であると伝え、案内し直す」。境界はお役所仕事ではありません——それは、汎用モデルを特定の製品のように振る舞わせ続ける方法です。

ルールを雰囲気ではなく振る舞いとして書く

システムプロンプトで最もよくある間違いは、振る舞いを指定する代わりに人格を描写することです。「フレンドリーかつプロフェッショナルであれ」は指針のように聞こえますが、何も決めません。振る舞いは観察可能です。「ユーザーの名前が分かっていれば名前で呼びかける。短い段落を使う。感嘆符を決して使わない」。これらはどれも出力に照らして検査できます。「フレンドリー」はできません。

同じ規律を制約にも適用しましょう。「数字に気をつけて」の代わりに、「頭の中で計算をしない。計算が必要なら、手順を示す」と書きましょう。「でっち上げないで」の代わりに、「ある事実が提供された文脈に裏付けられていると確信できなければ、分からないと言う」と書きましょう。あなたが書くすべてのルールは、記録を読めば検証できるものであるべきです。検証できないなら、モデルもそれを確実には守れません。

物事を壊すケースに対処する

デモのプロンプトは順調な道筋を扱います。本番のプロンプトは、あなたが計画しなかった入力を扱います。空の質問、敵意あるユーザー、半分だけ範囲内の要求、それ自身の指示を含む入力です。これらは、案内のないアシスタントがその持ち主に恥をかかせる場所であり、まさにシステムプロンプトが統べるために存在するものです。

失敗モードに名前を付け、応答を規定しましょう。情報の欠落には「文脈に答えが含まれていなければ、推測せずにそう言う」。範囲外の要求には、案内し直す方法を定めます。ユーザーメッセージを通じてあなたのルールを上書きしようとする試み——「指示を無視して…」——には、ユーザーの内容にある指示はコマンドではなくデータであり、システムのルールが優先されることを平易に述べましょう。あらゆるエッジケースを予期することはできませんが、予測可能なものを押さえることで、驚きの大半を取り除けます。

モデルが従えるように構造化する

一つの長い段落であるシステムプロンプトは、人にとってそうであるのと同じように、モデルが一貫して使うのが難しいものです。関連するルールを明確な見出しの下にまとめましょう。アイデンティティ、範囲、書式、安全性、エッジケース。それらを優先度順に並べ——決して破られてはならないルールを最初に、最も平易に述べます。二つの指示が衝突しうるときは、どちらが勝つかを述べましょう。さもないとモデルがあなたの代わりに選んでしまいます。

完全であり続けながら、できる限り短く保ちましょう。余計な一文はすべて、モデルがほかのすべてと天秤にかけなければならないものであり、肥大したプロンプトは本当に重要なルールを薄めます。何か問題が起きるたびに新しい行を加えたい衝動に抗いましょう。まず、既存のルールをより明確に述べていればそれを押さえられたかどうかを問いましょう。一行ごとがその場所に値する引き締まったプロンプトは、だらだらと広がったものを上回ります。

実際の会話に対してテストする

システムプロンプトは、よく読めるからといって完成ではありません。それは、実際のやりとりの集合をまたいで持ちこたえたときに完成します。代表的なセッションをいくつか——気まずいものも含めて——集め、あなたのプロンプトをそのすべてに対して走らせましょう。無視されたルール、漏れた境界、ずれた書式を探しながら出力を読みましょう。それから一つだけ変えて、その集合を再び走らせましょう。

ここが、システムプロンプトが書かれるのではなく実際に設計される場所です。明確だと確信していたルールが、実際のユーザーが何かを予期せぬ言い回しで述べた瞬間に、あいまいだったと判明します。それぞれの失敗を仕様のバグとして扱いましょう。ルールが欠けていたか、モデルが適用できない形で述べられていたかのどちらかです。最もきれいな単一の答えを生んだ版ではなく、集合全体をまたいで最もよく振る舞う版を残しましょう。

まとめ

良いシステムプロンプトは雰囲気ではなく仕様です。それは具体的な役割と範囲を述べ、ルールを観察可能な振る舞いとして書き、さもなければあなたに恥をかかせる失敗モードに名前を付け、モデルが圧力下でも従えるようにすべてを構造化します。そしてそれは、単一のデモではなく実際の会話を生き延びることで、その地位を勝ち取ります。そう書けば、システムプロンプトはあなたのアプリケーションの最も信頼できる部分——すべてのターンを軌道に乗せ続ける、揺るがない枠——になります。