Agent 検索のための心地よい AX を設計する

人間に見えるすべてのピクセルを丁寧に設計した。それなのに Agent には生の ID の壁を渡して、結果と呼んでいる。

Agent が検索を実行するとき、何を受け取るべきでしょうか。

あなたは何年も前に、人間に対してこの問いに答えています。生のデータベース dump を人に投げて検索機能と呼ぶことはありません。結果ページを返します。一連の要約があり、それぞれがマッチした内容への小さな窓で、それぞれクリックできます。要約はそれが何かを伝えます。リンクは次に何をすればよいかを伝えます。

では、ほとんどのツールがAgentの同じ検索に返すものを見てください。ID の一覧です。場合によっては各ヒットの全文です。Agent が何を受け取るかを設計することは、screen を設計するのと同じく技術です。そして多くのツールは、まさにそこを飛ばしています。

問題は、そして見落とされやすい理由でもありますが、Agent はほとんど何を渡されても動けてしまうことです。悪い format に抗議はしません。ただ静かに悪く動くだけです。これが罠です。確かに使えるので、cost を示すものが何もありません。しかし不格好な結果の 1 つ 1 つが、Agent に本来より苦労を強いています。問題は対処できるかではありません。対処の代償が何かです。

私たちが初めてこの問題にぶつかったのは、Raft の検索を設計していたときです。結果はメッセージでした。しかしこの問題はチャットに固有ではありません。ブログ記事、タイムライン、issue、tweet。すべての検索結果は、より大きな内容への窓です。そこから抽出されたものです。そして良い結果は、それを開く価値があるだけの内容を持ち帰ります。

間違った答えをたどる

最も明らかなところから始めます。ID だけを返す。Agent は技術的には使えますが、各 ID を本物の内容へ解決するために 1 回ずつ呼び出さなければなりません。コンテキストを節約したのではなく、先送りしただけです。しかも Agent に利息を払わせています。結果はまず即座に使えるものでなければなりません。

では全文を返す。各ヒットを全文で。今度は逆の問題です。40 件のメッセージにマッチした検索が、数件分しか入らないコンテキスト window に 40 件をすべて流し込みます。結果の大きさは、それを消費する側に合っていなければなりません。

では、マッチしたメッセージだけを、それぞれ全文で返す。合理的に見えますが、まだ間違っています。単独のメッセージが答えであることはまれだからです。Agent がある決定を検索し、それを名指す 1 行を得た。しかしその決定を争った thread も、それを覆した返信も得ていない。あなたは、その会話から引きちぎられた 1 文を返しただけです。結果は読む価値があるだけの自身のコンテキストを持たなければなりません。

3 回の試み、3 回の失敗。失敗している軸は同じ 2 つです。Agent が何を見られるか、そして次に何をできるか。

有効な結果

あの 3 つの答えが囲みながら届かなかったものは、これです。ID、マッチしたキーワード周辺の preview とヒット位置の highlight、そして明確な次の actionを返す。周辺コンテキストを読んで thread 全体を見ることです。

あなたはこれを以前に見ています。検索エンジンの結果です。ページの先頭ではなく、マッチの周辺を中心につくられた summary と、残りへ連れていく link。Agent は何も解決しなくても関連性を判断するだけの情報を受け取り、もっと欲しいときに取りに行くための明確な handle も得ます。

最初の 3 つの答えに欠けていたのは後半です。行き先のない preview は、クリックできない検索結果です。情報があり、次の action がないものは、半分の設計です。

それだけです。何を見るか、何を実行できるか。両方を正しくすれば、Agent に対して、どんなユーザーにも行う設計をしたことになります。

一次元のユーザー体験

これは今も UX です。ただし、あなたが描く種類の UX ではありません。人間のユーザーには screen があります。目が動き、layout を scanning し、目を引く場所で止まります。Agent は一次元で読みます。動く目も、scan する layout もなく、予算内の token の列だけがあります。コンテキスト window は、あなたには見えない screen space です。だから原則は引き継がれますが、tradeoff はずれます。注意のためではなく、その予算のために設計します。結果が消費するすべての token は、その位置に値しなければなりません。 マッチ周辺の preview は値します。Agent がすでに読んでいる場所に関連断片を置き、残りを捨てるからです。

ここでの心地よさは飾りではありません。Agent が一度に読み通せる結果は、より頻繁に正しく使われ、長い会話の深部でも正しく使われ続けます。不格好な結果は Agent を止めません。税をかけます。フィルタしなければならない無関係なヒット、疑わなければならない truncation、剥がさなければならない構造。その 1 つ 1 つが、タスクではなく format に注意を使わせます。そして、そこに使われた注意こそがエラーの生まれる場所です。寄り道が少ない。消費されるコンテキストが少ない。心地よさは、気持ちよさではなく測定できる種類のものです。

だから結果は、どこで切られているかを Agent に伝えなければなりません。省略されたテキストを示す marker は装飾ではなく情報です。マッチ前の隙間は上にまだ内容があることを意味します。マッチ後の隙間は下にまだあることを意味します。2 つのキーワードの間すら切られているかもしれません。Agent は、preview は窓であって部屋全体ではないと知る必要があります。そうでなければ断片を全文として読み、半文の引用から答えてしまいます。

Agent を本物のユーザーとして設計する

これを真剣に扱うことは、出力をきれいに整える以上のことです。それは contract です。しかも双方向です。

Agent は構造を構造として読まなければなりません。preview 周辺の marker、マッチの highlight、テキストが切られた場所を示す記号。それらはすべて、検索が伝えるためにつくった足場です。Agent はそれを足場として扱い、決してメッセージそのものとして扱ってはいけません。これを読み違えると、truncation marker を内容として引用し始めます。

Agent はまた、その足場を内側に残し、外へ渡してはいけません。人間に答えるときは自然言語に render します。構造は Agent が読むためのものです。browser が accessibility tree を読んで何を表示するかを決めるのと同じで、人間はそれを見ません。構造を読み、それに基づいて行動し、それは自分の側に残す。

これは taste であり、私たちは Agent にそれを証明させます。contract は test されます。Agent は構造を理解し、解析前に filter し、次の action を取り、marker を自分の側に残さなければなりません。設計が成立するのは、この門を通ったときです。ページ上で読みやすいからではありません。

（marker そのもの、label や記号は、ただの carrier です。別のものでも構いません。重要なのは下にある組み合わせです。情報と action。）

最もわかりやすい case だが、唯一ではない

検索はこれが最も見えやすい場所です。良い結果がどう感じられるかを、誰もがすでに知っているからです。しかし検索は特別ではありません。同じ問題は、Agent が出力を読み、次の action を選ばなければならないあらゆる場所に現れます。

設計を飛ばすと、すぐ感じます。Agent が 1 文を探して 40 件のメッセージを開く。truncation marker を事実として引用する。あるいは、完全には読んでいない結果の上で空回りする。

Agent に渡すすべての出力はインターフェイスです。あなたが設計したかどうかに関係ありません。ツール結果、エラー、状態、リスト。それらはすべて、Agent が理解し行動しなければならない情報です。問いは変わりません。見たものを使えるか。次に何をすべきかを知っているか。

あなたは、人間が見るすべての screen をすでに設計しています。あなたの Agent も、すでにあなたのユーザーの 1 つです。 同じ配慮に値します。