私はふだん、新しいタイプの現象に旧来の世界のたとえを無理に当てはめようとする、よくある習慣があまり好きではありません。なので、いま自分がまさにその「罪」を犯そうとしていることを許してほしいのですが、なぜプロンプト作成は プロンプトデザイン と呼ばれるべきで、ウェブデザインになぞらえられるべきなのか、その理由を述べたいと思います。

私はプロンプト作成を「時間制約のある人間とのコミュニケーション」として捉えています。LLM 特有のテクニック（とくに chain-of-thought）はたしかに有用ですが、性能を改善するうえで、もっとも有効な方法のひとつは、実は「極めて明確で高品質な指示を書くこと」だと感じています。これは、明確で簡潔な文章のほうが人間にも理解しやすいのとまったく同じです。

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

したがって、動的な入力を伴う明確なコミュニケーションとしてのプロンプト作成 が、最も正確な表現だと感じています。

では、「動的な入力に対して、明確にコミュニケーションする」ことを扱う別の分野は何でしょうか。ウェブデザインです。

共通点を挙げてみましょう。プロンプト作成とウェブデザインはどちらも:

1. 明瞭さが求められ、コミュニケーションが第一の目的である。

2. 文章や雑誌レイアウトとは異なり、動的なコンテンツに対応する必要がある。

3. コンテンツを異なるサイズに適応させる必要がある — ウェブデザインでは画面サイズ、プロンプト作成ではコンテキストウィンドウ。

プロンプト作成とウェブデザインの両方をやってきた経験から、開発者としての自分の好みも、この 2 つでよく似ていると感じています。

1. 実際のプロンプトを見ること が極めて重要である、という点です。これは、レンダリングされたウェブサイトを見ること が重要なのとまったく同じです。HTML と CSS のレンダリングを頭の中でシミュレートしなければならない状況では、私はウェブサイトをデザインできません。同様に、すべての入力変数を埋め込んだプロンプトのレンダリング結果を見ずに、良くて明確なプロンプトを書くのはとても難しいのです。

2. たとえば、"Hi ${username} ${message}" というプロンプトは、一見それなりに見えるかもしれませんが、実際にレンダリングしてみると、ユーザー名がメッセージに紛れてしまうことに気づきます。

3. 合成可能なコンポーネントは、プロンプト作成とウェブデザインのどちらにおいても有用です。

4. 両方とも、命令的より宣言的であるほうが望ましいです。すべての HTML 要素を document.createElement の呼び出しで生成しているウェブサイトは、変更するのが非常に大変です。同様に、str += "..." を延々と連ねたプロンプトは、読んだり変更したりするのがすぐに手に負えなくなります。

5. どちらにおいても、ときどき「ピクセルパーフェクト」を目指したくなります。能力の低いモデル（GPT-3.5 など）に対してプロンプトを作るときには、余計な改行やフォーマットの乱れが一切ないようにしたくなりますし、ウェブサイトをデザインするときも、すべてのピクセルが重要になる瞬間があります。

LLM エージェントについては、このアナロジーをさらに押し進めることができます。エージェントのプロンプト作成は、エージェントに対してインタラクティブなウェブサイトを構築することだと見なせます。エージェントは関数呼び出しをすることで「ボタンをクリック」でき、そしてウェブサイトがボタンクリックに応じて再レンダリングされるのと同様に、プロンプトも関数呼び出しに応じて再レンダリングされます。

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

1. プロンプト作成はいまのところテキストだけを扱います（今のところは！）。

2. キャッシュの扱い方が異なります。とくにエージェント向けでは、プロンプトの後半だけを変更することで再レンダリングを安く済ませたい、という要件があります。ウェブにも「キャッシュを最適化したい」という似たような話はありますが、本質的にはかなり別種のチャレンジだと思います。

それでも、ここまでの類似点から、私はプロンプト作成は プロンプトデザイン と呼ばれるべきであり、プロンプトエンジニアリング ではないと確信するようになりました。プロンプトを書くという行為は ウェブサイトをデザインする感覚とほとんど同じ であり、ならば呼び名も同じであるべきだと思うのです。

このプロンプトデザインの視点から、私は Priompt という、React ライクな JSX ベースのプロンプトデザインライブラリを作りました。

#Priompt v0.1: プロンプトデザインライブラリの最初の試み

Priompt は、モダンな Web デザインの原則に着想を得た、プロンプトデザインライブラリの最初の試みです。私たちは Cursor の社内でこれを使っており、とても気に入っています。

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

Priompt には（とても急いで作られた）プレビューサイトも用意されており、実際のデータ上でプロンプトをプレビューできます。アプリケーションを開発するときは、各リクエストでコンポーネントに入ってくるシリアライズされた props をログに記録できます。そのうえで、想定外の挙動を見つけたときには、Priompt のプレビューに行き、実際のプロンプトを確認し、ソースコードを変更して、実際のリクエストと同じ props を使った状態でプロンプトを更新できます。私たちは、この仕組みによってプロンプトの反復がしやすくなると感じています。

もし試してみたら、ぜひ感想を教えてください！同じ方向性の新しいアイデアも見てみたいですし、あるいは「お前は完全に間違っているし、プロンプトデザインなんてバカげている」と言われるのでも構いません :)。

#注意点

モデルは急速に進化しており、それに合わせてプロンプトの工夫の仕方も変えていかざるを得ません。そうした前提のうえで、プロンプトデザイン という捉え方にはいくつか注意点があると考えています。

1. ピクセル単位で完璧なデザインは GPT-4 にとってさほど重要ではなく、おそらく GPT-4.5 以降のモデルでは完全に時代遅れになるでしょう。

2. 長コンテキストモデルの最近のトレンドを外挿すると、コンテキストウィンドウの制約はなくなるかもしれません。とはいえ、私はそこまで確信しているわけではありません。

3. OpenAI は、開発者がプロンプトを細かく制御できる余地を徐々に減らす方向に動いているように見えます。1 年後には「プロンプト」という概念自体がなくなり、API 呼び出しでは生の入力とインストラクションだけを渡す形になっている可能性もあります。このコントロール低減の流れは、チャット形式の導入から始まり、最近発表された function calling（関数呼び出し機能）でも続いています。

4. キャッシュがプロンプト設計において最も重要な要素のひとつである可能性もあり、その場合はもはやデザインというよりエンジニアリングに近い話になってきます。

5. そもそもプロンプトデザインというレイヤー自体が低すぎて、本来はより高レベルなフレームワークやコンパイラ（例: langchain）に任せるべきなのかもしれません。これは正しいかもしれませんが、LLM があまりに速いペースで変化している現状では、個人的にはできるだけ生のモデルに近いところにいたいと考えています。

#最後にどうしてもお伝えしたいこと

…というのも、あなたと一緒に働きたいからです: Cursor では、AI ファーストのコードエディタである Cursor を開発しています。もしあなたがプロンプトデザインやコーディング向けの LLM、美しいプロダクトづくりにワクワクするなら、ぜひ arvid@cursor.com までメールをください。私たちはサンフランシスコにいる 5 人のチームで、メンバーは全員本当に優秀です。そして、コーディングの未来を一緒につくっていく、数名の優れたエンジニアやデザイナーに加わってもらいたいと考えています。