プロンプトには、あえて余白を残す

私はときどき、一本の記事や一連の会話、あるいはまだ整理もしていない資料の山を Agent に渡して、一言だけ尋ねる。

結局のところ、これは何なのか？

Prompt Engineering の基準から見れば、この問いはほとんどすべてが失格だ。役割を指定していない。手順も定めていない。出力形式もない。そもそも「これ」が何を指すのかさえ明らかではない。

受け取った Agent も困る。求められているのが要約なのか、批評なのか、主張の抽出なのか分からない。だから自分で探るしかない。筆者が本当に気にしているのは何か。どの言葉が単なる包装なのか。複数の資料を貫く一本の線はあるのか。これ以上削れないところまで削ったとき、最後に残る判断は何か。

不思議なことに、こうしたプロンプトのほうが、ときに面白い答えを返してくる。

曖昧さが明確さより本質的に優れているからではない。難しさの正体が、まだ問いを明確に言葉にできないこと自体にある仕事も存在するからだ。

最初から次のように指示したとする。

この記事を「背景」「問題」「原因」「解決策」「示唆」の五つに分けて要約してください。

Agent はもちろん、より安定した結果を出すだろう。しかしその時点で、私は記事に何が書かれているかを先回りして決めている。Agent がするのは、資料を五つの箱に詰めることだけだ。筆者がそもそも「問題―原因―解決策」という物語を書いていなくても、それらしい形に整えることはできる。

プロンプトが具体的であるほど、制御は強くなる。だが、その制御の中には、問いを立てた側の盲点も潜んでいるかもしれない。

私たちは、良いプロンプトを完全な設計図のように考えがちだ。目的、手順、形式、基準をあらかじめ書き切り、Agent は図面どおりに作業する。これは、答えのおおよその形がすでに分かっている仕事に向いている。コードの一部を修正する、契約書から項目を抜き出す、データを表にまとめる、といった仕事だ。

しかし、施工ではなく探索が必要な仕事もある。

初めて読む記事を理解する。あるプロダクトが本当に解決している問題を見極める。議論がなぜいつもすれ違うのかを読み解く。あるいは、自分がぼんやり気にしているものの正体を突き止める。こうした仕事には、まだ地図がない。プロンプトを完成させすぎることは、探索を始める前に、こっそり偽の地図を描いてしまうことでもある。

「結局のところ、これは何なのか？」は曖昧に見える。だが実際には、重要な仕事の一部を Agent に委ねている。問いに答えるだけでなく、問いそのものを定義してみるという仕事だ。

ここで役に立つのは、曖昧さそのものではない。探索をやり直せることだ。

Agent はまず、一つの解釈を持ち帰る。納得できなければ、どこが違うかを伝えればいい。筆者に同調しすぎている。主張を言い換えただけで、なぜそうなるのかを説明していない。表面上の主張は捉えているが、その背後にある利害を見落としている。そう伝えれば、Agent は別の方向を試せる。何度か往復して初めて、最初に自分が本当は何を尋ねたかったのかが見えてくることもある。

プロンプトは、一度で正しく書かなければならない仕様書ではなくなる。最初に差し込む探針のようなものだ。まず中の様子を確かめ、返ってきた反応に応じて向きを変える。

ただし、「気に入らなければ直させればいい」という話は、聞こえるほど簡単ではない。

最初の答えはアンカーになる。Agent が資料を一度「効率の問題」と解釈すると、さらに掘り下げるよう求めても、効率が悪くなる原因をより深く探すだけかもしれない。人間も同じだ。十分になめらかな説明が一つ現れると、それが多くの解釈のうちの一つにすぎないことを忘れやすい。

だから最初の方向が違っていたとき、「もう少し深く」と言い続けても、たいていは役に立たない。元の枠組みから本当に離れさせるほうがよい。

先ほどの説明はいったん捨ててください。互いに競合する三つの解釈を示し、それぞれが何を説明でき、何を見落とすのかを述べてください。

修正は、同じ道をそのまま進むことだ。再解釈は、分かれ道で別の道を選ぶことだ。

もちろん、すべての仕事にこの方法が向いているわけではない。

Agent が本番環境を変更する、顧客にメールを送る、医療上の助言をする、あるいは取り消せない取引を実行するなら、まず自由に探索させて、問題があれば後で直すというわけにはいかない。最初の結果が、すでに代償を生む可能性があるからだ。目的、権限、境界、受け入れ基準を事前に明確にしなければならない。

あえて曖昧さを残せるのは、コストが低く、やり直しができ、結果を確認でき、しかも人間が良し悪しを判断できる仕事だ。執筆、読解、調査、プロダクト探索は、多くの場合この範囲に入る。実行、約束、高リスクの意思決定は、通常ここには入らない。

だから私は今、「経路を指定しないこと」と「責任を曖昧にすること」を分けて考えるようにしている。

良いオープンエンドなプロンプトは、Agent に考え方を指示しなくても、十分な材料を渡すことができる。予想外の答えを許しながら、根拠を示すよう求めることができる。正解をひとまず定義せず、複数の解釈を競わせることもできる。

たとえば、「結局のところ、これは何なのか？」の後に、次の一文を加える。

筆者の言い分に沿って、すぐに要約しないでください。まず核となりうる主張をいくつか挙げ、資料に照らして一つずつ検証してください。最後に、最も確信が持てない点を教えてください。

これでもまだ余白は残っている。だが、その空白は手抜きから生まれたものではない。探索のために、意図して空けてある。

私たちはこれまで、Agent が意図を理解できないことを恐れ、プロンプトをどんどん長くしてきた。だが、ときに本当に恐れるべきなのは、まだ自分でも理解していないのに早々と言葉にしてしまった意図を、Agent が正確すぎるほど実行することだ。

プロンプトは、あらかじめ答えの形を収めておく必要はない。

ときには Agent を問題の前に立たせて、こう言うだけでいい。

まずは中を見てきて。