私はふだん、新しい現象を旧来のものにたとえて説明する通俗的なやり方には及び腰です。ですので、これからまさにその“罪”を犯すことをお許しください。なぜ「プロンプト」を プロンプトデザイン と呼び、ウェブデザインになぞらえるべきかを論じます。

私はプロンプト作成を、時間制約のある人間とのコミュニケーションだと捉えています。LLM特有のテクニック（とりわけチェーン・オブ・ソート）は確かに有用ですが、パフォーマンスを向上させる最良の方法の一つは、非常に明確で高品質な指示を与えることだと実感しています。これは、明瞭さと簡潔さが実際の人間の理解にも役立つのと同じです。

明確なコミュニケーションとしてのプロンプト設計は、プロンプト作成を文章執筆のように聞こえさせます。しかし、私が行っているプロンプト作成の大半はパラメトリックで、複数の入力変数があり、それらに応じてプロンプトを動的に適応させる必要があります。

したがって、動的入力を前提とした明確なコミュニケーションとしてのプロンプトが、最も正確な表現に思われます。

変化する入力に対して、明確に伝えることを重視する分野は他に何でしょうか？Webデザインです。

共通点をすべて挙げてみましょう。プロンプト作成とウェブデザインはどちらも次の点で共通しています：

1. 明確さを重視し、コミュニケーションを主要な目的とすること;
2. 執筆や雑誌のレイアウトと異なり、動的なコンテンツに対応する必要がある；
3. コンテンツをさまざまなサイズに適応させる必要がある——ウェブデザインの画面サイズ、プロンプトのコンテキストウィンドウなど。

プロンプト作成とウェブデザインの両方に携わってきた私の経験では、どちらの分野でも開発者として似たような嗜好があることに気づきました。

1. 実際のプロンプトを見ることは、レンダリングされたウェブサイトを見ることと同じくらい極めて重要です。頭の中でHTMLやCSSのレンダリングをシミュレートしなければならない状況では、ウェブサイトを設計できません。同様に、すべての入力変数が埋め込まれたプロンプトのレンダリング結果を見ずに、良くて明快なプロンプトを書くのは本当に難しいのです。
   1. たとえば、プロンプト "Hi ${username} ${message}" は一見もっともらしく見えますが、実際にレンダリングしてみると、ユーザー名がメッセージに紛れてしまうことに気づくかもしれません。
2. コンポーザブルなコンポーネントは、プロンプト作成とウェブデザインの両方で有用です。
3. どちらにおいても宣言的アプローチのほうが命令的アプローチより優れています。すべてのHTML要素をdocument.createElementの呼び出しで生成しているサイトを変更するのは本当に大変です。同様に、str += "..."の長い連なりで構成されたプロンプトを読み書き・変更するのは、すぐに手に負えなくなります。
4. どちらの場合でも、「ピクセル単位の完璧さ」を求めることがあります。能力の低いモデル（GPT-3.5 など）にプロンプトを与える際は、不要な改行や細かな書式の乱れがないように気を配りますし、ウェブサイトをデザインする際には、時に1ピクセルまでが重要になります。

LLMエージェントについては、このアナロジーをさらに拡張できます。エージェントへのプロンプトは、関数呼び出しで「ボタンをクリック」でき、関数呼び出しに応じてプロンプトが再レンダリングされる、つまりボタンのクリックに応じてウェブサイトが再レンダリングされるのと同様に、エージェント向けのインタラクティブなウェブサイトを構築することだと捉えられます。

もちろん、プロンプト設計とウェブデザインには違いがあります。

1. プロンプト作成は（現時点では）テキストのみを対象とします。
2. キャッシュ戦略は異なります。特にエージェントにおいては、プロンプトの後半だけを変更して再レンダーを安価に抑える必要があります。ウェブ（サイトをキャッシュ最適化する）に表面的な類似はありますが、本質的にはまったく別の課題だと考えています。

それでも、こうした共通点から、プロンプトはプロンプトデザインと呼ぶべきで、プロンプトエンジニアリングではないと確信している。プロンプトを書くことはまさにウェブサイトをデザインするのと同じ感覚であり、名称もそれに合わせるのが妥当だ。

プロンプト設計という観点から着想を得て、私はReactのようなJSXベースのプロンプト設計ライブラリである Priompt を作りました。

Priompt v0.1: プロンプト設計ライブラリへの最初の試み

Priompt は、モダンなウェブデザインの原則に触発されたプロンプト・デザインのライブラリを作るための最初の試みです。私たちは Anysphere 社内で使用しており、とても気に入っています。

すべての抽象化が完全に正しいわけではないと思いますが、少なくともJSXは文字列テンプレートよりもはるかに使いやすくプロンプトを書ける方法だと確信しています。たとえば、プロンプトの一部を簡単にコメントアウトできるという単純なことだけでも、反復のサイクルを大幅に速くします。

Priompt には（非常に手早く作られた）プレビュー用のウェブサイトも付属しており、実データ上でプロンプトをプレビューできます。アプリケーションを開発する際は、各リクエストでコンポーネントに入ってくるシリアライズ済みの props をログ出力できます。そして予期しない挙動を見つけたら、Priompt のプレビューにアクセスして、該当するプロンプトを確認し、ソースコードを変更すると、実際のリクエストと同じ props でプロンプトが更新されます。これにより、プロンプトの反復改善が容易になることがわかりました。

もし試してみたら、ぜひ感想を教えてください！同じ方向性のアイデアを見るのも大歓迎ですし、「まったく見当違いで、プロンプト設計なんてばかげている」と言われるのでも構いません :)

注意事項

モデルは急速に進化しており、プロンプト技法も同様に変化せざるを得ません。そうした前提のもと、プロンプト設計という捉え方にはいくつか注意点があると思います。

1. ピクセル単位で完璧なデザインはGPT-4にとって重要ではなく、GPT-4.5以降のモデルではおそらく時代遅れになるでしょう。
2. 長文コンテキスト対応モデルの最近の傾向を外挿すれば、コンテキストウィンドウという制約は消えるかもしれません。とはいえ、私はまだ確信していません。
3. OpenAI は、開発者がプロンプトを制御できる範囲を段階的に小さくしていく方向に進んでいるように見受けられます。1 年後には「プロンプト」という概念自体がなくなり、API 呼び出しは生の入力とインストラクションだけを渡す形になる可能性もあります。こうしたコントロールの縮小傾向は、チャット形式の導入で始まり、最近発表された function calling にまで続いています。
4. キャッシュはプロンプト設計において最重要な要素のひとつである可能性があり、その場合、デザインというよりむしろエンジニアリングに近い響きになります。
5. プロンプト設計はレイヤーが低すぎる作業であり、より高レベルなフレームワークやコンパイラ（例：langchain）に任せるべきかもしれません。これは正しいかもしれませんが、LLMの変化が非常に速いことを踏まえると、私は個人的に可能な限り生のモデルに近いところで扱うことを好みます。

最後にひと言

…なぜなら、あなたと一緒に働きたいからです：Anysphereでは、AIファーストのコードエディタであるCursorを開発しています。プロンプト設計やコーディングのためのLLM、美しいプロダクトづくりにワクワクする方は、arvid@anysphere.coまでメールをください。私たちはサンフランシスコの5人のチームで、同僚は全員卓越しており、さらに数名の卓越した人材—コーダーおよびデザイナー—に加わっていただき、コーディングの未来を一緒に築いていきたいと考えています。