チャットボットにしない自然文検索の設計

自然文検索は、チャットボットとして設計したくなります。ユーザーが文章を書き、モデルが答え、画面全体が会話になります。

しかし、多くの業務プロダクトでは、それが最適とは限りません。買い手、運用担当者、社内チームは、フィルター、候補、信頼度、根拠、次のアクションを確認できるワークフローを必要とします。モデルは翻訳レイヤであって、目的地ではありません。目的地は依然として、ユーザーが期待する操作（並び替え、絞り込み、保存、共有、比較、実行）を備えたプロダクト画面です。

意図を操作できる形に変える

使えるAI検索では、モデルがどう解釈したかを見えるようにします。ユーザーが「交通の便が良く、明るく、家族向けのエリア」と入力したら、その文章から取り出した前提を表示します。

• 場所や移動時間の前提
• 物件や項目の属性
• 優先度
• 除外条件
• トレードオフ

これにより、結果を信頼する前にユーザーが修正できます。

ドメインを超えて成立する操作モデル:

1. 自由テキスト入力。 常に表示、隠さない。
2. 解析 → チップとして描画。 モデルの出力は構造化クエリとして結果上部に可視化。各チップは編集・削除・重み付け可能(必須、任意、除外)。
3. 曖昧性のソフトチップ。 「『明るい』を『南向きまたは最上階』として解釈中。クリックで変更」。
4. 理由付きの結果一覧。 各結果が「なぜマッチしたか」を表示:該当チップ、スコア内訳、最も近い不一致。
5. ワンクリック訂正。 「狭い部屋が多すぎる」→ floor_area_min チップが立つ。ユーザーはボットと議論せず、クエリを編集している。

要は、解釈のすべての部分が可視化され、名前を持ち、操作可能であること。モデルは難しい部分（雑然とした言語から構造化意図への変換）を担い、ユーザーは結果のコントロールを保ち続けます。

結果はプロダクトらしく見せる

AIは摩擦を減らすために使います。ただし、プロダクト全体には馴染みのある操作が必要です。地図、表、ダッシュボード、キュー、フィルター済みリストの方が、生成テキストだけより評価しやすいことが多くあります。

ドメイン適合の例:

• 不動産。 地図+カード+保存検索+チップフィルタ。多数の結果を比較するため、チャットは適合しない。
• 採用。 候補者テーブル+スコア+マッチ理由+ショートリストアクション。チャットでは比較ビューが失われる。
• 購買。 正規化スペックのカタログ+サプライヤースコア+RFQ一括追加。チャットは承認ワークフローを遅らせる。
• 社内管理。 フィルタ可能リスト+一括アクション+監査。チャットはアクション履歴を隠す。
• ナレッジ検索。 ここはチャット型が機能する数少ない領域。ただし引用とインライン根拠パネルで半分はプロダクトであるべき。

画面は次の3つに素早く答えるべきです。

• システムは何を理解したか
• その解釈からどんな結果が出たか
• ユーザーは何を変更または承認できるか

ユーザーが段落を読まないとどれかが答えられない設計は、チャットが多すぎます。

スプリント候補にする

自然文検索は、サンプルデータがあり、価値を見せやすい場合に良い初回スプリント候補になります。初版にすべてのランキングルールや連携は不要です。ユーザーが試せる1つの検索ジャーニーがあれば十分です。

実務的なスプリント計画:

• 1データセット、1ユーザー役割、1結果画面に絞る。 「候補者と物件も両方」は禁物。2つ目のジャーニーは2回目のスプリント。
• 手書きクエリから始める。 チップUIと結果ページを先に作り、決定論的なクエリで動かす。その後でLLMを差し込む。
• 厳格な構造化出力を使う。 JSON Schema、検証、失敗時の修復プロンプト。下流で自由形式テキストをパースしない。
• 評価セットを初日に作る。 30〜100件の実/現実的クエリ+期待される構造化解析結果。変更ごとにパーサーを通す。
• すべてログに残す。 入力、解析結果、ユーザーの事後編集、最初のクリックまでの時間、結果ゼロ率。

それだけで、より大きなプロダクト投資に進むべきかを判断できます。最初のスプリントは、後続が必要とする3つを生み出します:チームが信頼するパーサー、ユーザーが実際に編集するUI、リグレッションを捕まえる評価セット。これらがなければ「データセット拡大」は願望、あれば計画です。