【ITニュース解説】The Search Box Is the Most Expensive Feature Nobody Asked For

システム開発において、ユーザーが日常的に使う「検索ボックス」は、見た目以上に複雑で、実は非常に開発コストがかかる機能であることを知っているだろうか。ある企業が、物流顧客のオペレーションマネージャーから「電話番号を一つ入力するだけで、その顧客に関わるすべての情報を表示してほしい」というシンプルな要望を受けた。当時、製品には多数のリストビューがあり、それぞれにフィルター機能があったが、マネージャーは「どのテーブルに情報があるかを知らなければ検索できないのはなぜか」と問いかけたのだ。この「グローバル検索ボックス」は8ヶ月かけて開発され、その年で最も費用のかかる機能となったが、当初の要件定義書には一切記載されていなかった。

なぜ「検索ボックス」がそれほど高価になるのか、その核心には「フィルター」と「検索」の本質的な違いがある。これらはスクリーンショット上では似て見えるが、システムアーキテクチャレベルでは全く異なるものだ。フィルターは「構造化された質問」と言える。ユーザーは「ステータスがペンディング」「作成日が月曜日以降」「担当者が自分のチーム内」といった具体的な条件（フィールド名、演算子、値）をすでに知っている。システムはこれを受け、既存のクエリエンジンを使って容易にデータを絞り込むことができる。プラットフォーム上の多くの画面にフィルター機能があるのは、このように入力が明確だからだ。

一方、検索ボックスは「非構造化された質問」である。ユーザーが入力するのは「句読点が間違った電話番号の一部」「別言語で書かれた会社名の半分」「写真から読み取った請求書番号」「どのスキーマにも存在しない人物のニックネーム」といった断片的な情報だ。システムは、どのフィールドを探すべきか、どのように比較すべきか、そして「どれくらい似ていれば一致とみなすか」を判断しなければならない。答えの形は、実際に検索結果が出るまで誰にもわからないのだ。この違いがあるため、検索機能は開発計画段階でその真の複雑さが見過ごされやすい。「既存のグリッドにチェックボックスを追加するフィルター」も「テキスト入力欄とLIKEクエリによる検索」も、どちらも数日の作業のように聞こえるが、実際に数日で終わるのはフィルターの方だけである。

さらに、検索の対象となるデータには大きく分けて三つの種類（コーパス）があることを理解する必要がある。一つ目は「レコード」で、ユーザーが開いたことのないものも含め、すべてのアプリケーションのすべてのテーブルのすべての行が該当する。二つ目は「メタデータ」で、フィールド名、フォーム名、ワークフロー定義など、システム自体を定義するデータだ。開発者自身が半年前に作ったものだが名前を思い出せない、といったものを探す際に利用され、これはレコードとは異なる方法で検索される。三つ目は「非構造化コンテンツ」で、添付ファイル、スキャンされた請求書、コメント、チャット履歴など、定型的な構造を持たないデータがこれに当たる。ユーザーは一つの検索ボックスに何かを入力する際、これら三つの違いを区別しない。しかし、システム側では、これら三つのデータソースに対してそれぞれ異なる単語分割器（トークナイザー）、異なる権限ルール、異なる保持ポリシー、そして文書あたりの処理コストが大きく異なるため、一つの検索ボックスで正確な結果を返すためには、これらすべての違いを解決しなければならない。

検索機能におけるもう一つの大きな課題は「権限管理」である。検索インデックスを構築するということは、元々データを保持していた「記録システム」からデータをコピーし、元のシステムの権限モデルについて何も知らない「別のシステム」にデータを置くことを意味する。もしこのインデックスが「このユーザーは何を見ることを許可されているか」という問いに答えられないと、検索ボックスは情報漏洩の効率的なツールになりかねない。一度のクエリで、結果はランキングされ、ページ分けされ、ハイライトされて表示されてしまうからだ。この問題を解決するには、主に二つの方法がある。一つは「クエリ時フィルタリング」で、検索リクエストの際に権限ロジックを適用する方法だ。これは安全だが、検索処理のパフォーマンスに影響を与える。もう一つは「インデックス自体をスコープ化する」方法で、インデックス構築時にユーザーの権限に基づいたデータのみを格納する。これは高速だが、テナント、ロール、部署、レコード所有権など、複数の要素を組み合わせた複雑な権限モデルに対応しようとすると、インデックスの分割が非常に難しくなる。さらに、検索結果の件数（例えば「12件の結果があります」という表示）や、ユーザーがアクセス権のないフィールド内のマッチ箇所をハイライトして表示する「スニペット」も、情報開示につながるリスクがある。

検索ボックスは、データベースの問題に見えて、実は「言語の問題」を抱えている。例えば、中国語には単語を区切るためのスペースがないため、中国語のテキストを処理する単語分割パイプラインは英語とは全く異なり、しかも一つのインデックス内で両言語が共存する必要がある。これは、多くの顧客が同じ日に両方の言語で入力するからだ。N-gramという手法は単語分割の問題を解決するが、同時に「ノイズ問題」を引き起こすことがある。また、ある言語での語幹処理は、別の言語では効果がない。さらに、「単語ではないもの」、例えば注文番号、納税者番号、電話番号なども大きな課題だ。これらはテキストとして単語分割されるべきではなく、正規化され識別子としてインデックス化されるべきだ。人々は「138 0013 8000」のようにスペースを挟んで入力しても、システムがそのスペースを許容して正しい番号を見つけてくれることを期待するからだ。どのような正規化ルールを適用するかは、技術的な問題であると同時に、製品としての意思決定が求められる部分であり、誰かが明確に責任を持って文書化する必要がある。

検索は「第2の記録システム」であるため、昨日は存在しなかった「データの一貫性の問題」を引き起こす。データベースへの書き込みとインデックスへの書き込みは別々に行われるため、検索結果は多かれ少なかれ「結果整合性」を持つことになる。ユーザーはデータを保存した直後に検索でそのデータが見つかることを期待するが、30秒経っても見つからなければ「データが失われた」と認識し、バグとして報告するだろう。そのため、インターフェース上で「データの古さの許容範囲」を明示し、それを維持する必要がある。既存顧客への検索機能の導入も容易ではない。数千万件のレコードを持つ顧客に対して検索を有効にするのは、単なる設定変更ではなく、データ移行期間を伴う「バックフィルプロジェクト」となる。また、マルチテナント環境では、新しいテナントが追加されるたびに新しいインデックスが必要となり、テナントの準備プロセスの一部にインデックスの準備が組み込まれる。同様に、テナントの削除時にはインデックスからも関連データを削除する必要がある。検索レイヤーで削除要求に応えられない場合、それは単なる機能の欠落ではなく、「コンプライアンス違反」につながる重大な問題となる。

最近では、AIエージェントがテーブルをクエリする際に、検索機能の重要性がさらに高まっている。AIエージェントは情報を閲覧するのではなく、検索を行い、返された結果を読み取り、それに基づいて行動する。もし検索が間違った顧客情報を返した場合、AIエージェントは自信を持って間違った情報を記録してしまう。以前は、検索の品質はユーザーの忍耐の問題だったが、今やそれは自動化への入力となり、ビジネス上の意思決定に直結する。ランキングのバグは、誰も見ていないところで下されるビジネス上の意思決定のバグとなるのだ。

こうした課題に対し、いくつかの変更が加えられた。まず、検索を単なるテキスト入力としてではなく、独自のレイテンシ目標や鮮度目標を持つ「独立したサブシステム」として扱い、それに見合った予算を割り当てるようにした。メタデータの検索とレコードの検索は、それぞれ異なるライフサイクルを持つため分離された。これにより、どちらの検索も高速化された。権限解決はインデックスへのアクセスよりも前に行われるようになり、インデックスがユーザーが見るべきデータを決定することはない。また、アクセス権のないフィールドをハイライトしてしまうパスも削除された。正規化ルールはクエリビルダー内に埋め込むのではなく、メタデータとして宣言されるようになった。そして、6つのもっともらしい結果の中から「どれが正しいか」を選ぶ判断はビジネス上の判断であり、クエリチューニングの問題ではないという理由から、ランキングの調整は製品オーナーの責任とされた。

最終的に、検索ボックスは「最も高価な機能」でありながら「最も正直な機能」であるという結論に至った。フィルター機能は、ドロップダウンをクリックし、行が絞り込まれる様子を見るだけで、誰もが納得する美しいデモができる。しかし、検索はデモが難しい。何かを入力し、システムがそれを知っているか知らないか、その一瞬でデータモデル、権限、そして内部の配管構造まですべてをさらけ出してしまうからだ。多くの人がレポート機能を求めたが、本当に必要な「実際の仕事」について説明したのは、検索機能を要望したオペレーションマネージャーだけだった。プラットフォームの価値は、何を表示できるかではなく、「何を見つけられるか」によって判断されるのである。