AIで作ったアプリに検索機能を追加する方法(ちゃんと見つけられるように)

そこそこ出来のいいAI製アプリなら、必ずぶつかる瞬間がある。それは、アプリが「いっぱいになる」瞬間だ。レシピが12件のうちは楽しかったレシピアプリも、300件になると面倒になる。顧客が8人のうちはすっきりしていたクライアント管理アプリも、200人になると延々スクロールする羽目になる。何も壊れてはいない。アプリが使われただけだ——それこそが本来の目的なのに——でも今や、人がやりたかったこと、つまり特定の一件を見つけることに、やたら時間がかかるようになってしまった。

それが、アプリに検索機能を追加すべきタイミングのサインだ——数文字打つだけで、長いリストが目当ての一件まで絞り込まれるボックスを追加すべきタイミング。検索が「かっこいいから」ではない。スクロールは「見つける」ことにはならないからだ。ここでは、作り込みすぎずに実装する方法を見ていこう。派手なバージョンは、たいてい最初の一手としては間違っている。

いつアプリに検索機能を追加すべきか?

サインは分かりやすい。スクロールが必要以上に時間がかかるようになる——リストはこぢんまりとした数件から数百件に膨れ上がり、ひとつの項目を見つけるには他のすべてをスクロールして通り過ぎなければならなくなる。何かが壊れたわけではない。アプリが使われただけだ——それこそが本来の目的なのに。

この問題の実例を挙げよう。あるドッグトリマーが、顧客管理用のアプリを作った——名前、犬の名前、犬種、ドライヤーを嫌がる犬についてのメモ。最初の数ヶ月は、ひと目で見渡せるすっきりしたリストだった。顧客が200人になる頃には、目の前にお客さんが立っている状態でアプリを開き、「ベラのママ」を見つけるために100人分の名前をスクロールしなければならなくなっていた。

アプリは彼女が求めた通りに動いていた。ただ、そのリストが「ひとつのものを見つける」ための手段としては使い物にならなくなっただけだ。検索が解決するのはまさにここだ——「見つかるまでスクロールする」を「数文字打てばそこにある」に変える。

注文、レシピ、顧客、商品、メモ——何であれリストを表示するアプリで、そのリストが増え続けているなら、いずれこの壁にぶつかる。朗報は、いちばんシンプルな最初のバージョンの検索機能で、ほとんどの人にとって十分解決できるということだ。

AI製アプリに検索機能を追加するには?

まずはフィルターボックスから始めよう——リストの上部に置くテキスト欄で、入力するとマッチしないものをすべて隠してくれるものだ。考えうる限り賢い「AI検索」から始める必要はない。これが最初のステップのすべてであり、ほとんどのアプリではこれだけで十分だ。

AIビルダーに検索機能を頼むとき、つい考えうる限り賢いバージョンを求めたくなる——意図を理解し、類義語にも対応し、関連度でランク付けする、というような。だが、それはこらえよう。賢いバージョンは動作が遅く、実行コストもかかり、正しく作るのも難しい。そして、ほぼ間違いなく今のあなたにはまだ必要ない。

「bella」と打てば、リストはベラたちだけに絞り込まれる。それだけだ。即座に動作し、実行コストはほぼゼロで、そして人々が「検索できるようにしたい」と言うとき、実際に思い描いているのはこれだ。

ビルダーには、まさにこう頼めばいい——「このリストの上に、入力した文字にマッチする項目に絞り込む検索ボックスを追加して」。それだけでプロジェクトが完結してしまうことがどれだけ多いか、きっと驚くはずだ。

検索は実際にどのフィールドを見るべきか?

検索対象にすべきなのは、探しているものを実際に特定できる2〜3個のフィールドだけであり、すべての項目のすべてのフィールドではない。これをビルダーに伝えることこそが、検索を「使えるもの」にするか「イライラするもの」にするかを分ける唯一の指示なのに、ほとんどの人はこれを省いてしまう。

デフォルトでは、ビルダーはすべて——すべての項目のすべてのフィールド——を検索対象にしてしまうことがある。徹底しているように聞こえるが、たいていの場合は逆効果だ。あの顧客リストを検索したとき、犬のサイズについてのメモ欄に「小型」という単語が入っていたせいでヒットしてしまう場面を想像してみてほしい。技術的には一致しているが、求めていたものとは違う結果をふるいにかける羽目になる。

だからこそ、どのフィールドが重要かを具体的に指定しよう。あのトリマーの場合なら、顧客の名前と犬の名前だ——メモ欄でも、犬種でも、予約履歴でもない。レシピアプリなら、レシピのタイトルと、あれば主な材料であって、手順全文ではない。ビルダーにはこう伝えよう——「検索対象はタイトルと名前フィールドだけにして」。正しい2つのフィールドを検索するほうが、12個すべてを検索するより、いつだって優れている。

検索とフィルター、先に作るべきはどっち?

多くの場合、答えは「フィルター」だ。人が「検索」と呼ぶものの多くは実際には「これの一部だけを見せて」という要望であり、検索ボックスはそのための道具として適していない。ノンテクニカルなビルダーほど驚くポイントがここにある。

在庫を300点抱える転売業者は、たいてい文字を入力したいわけではない——「売却済み」「在庫あり」「今週出品」をタップしたいのだ。これがフィルター——すでに管理しているカテゴリーでリストを絞り込む、いくつかのボタンやドロップダウンのことだ。フィルターは検索より作るのが簡単なことが多く、日々の使い勝手も良い。なぜなら人は、名前でひとつのものを探し出すよりも、はるかに頻繁にステータスで一覧を眺めるからだ。

良い経験則はこうだ——「だいたいの名前は分かっている」場合には検索ボックスを、「この種類のものを見せて」という場合にはフィルターを追加する。あのドッグトリマーは、結局その両方を求めることになった——目の前にお客さんがいるときに名前ですぐ顧客に飛べる検索ボックスと、暇な午後に誰にメッセージを送るべきかひと目で分かる「トリミング予定超過」のフィルターだ。同じデータでも、そこへたどり着く方法はまったく異なる二通りがある。

どちらか一方しか先に作れないなら、実際に人がアプリをどう使っているかを観察しよう。「Xは全部どこ?」と繰り返し聞かれるなら、それは検索ボックスではなく、フィルターを求めているということだ。

検索で何も見つからなかったとき、何を表示すべきか?

シンプルで具体的なメッセージを表示しよう——たとえば「『zelda』に一致する顧客はいません。スペルを確認するか、検索をクリアしてください」といった具合に。真っ白な画面は「アプリが壊れた」と受け取られてしまう。壊れてなどいない、単に一致するものがなかっただけだ。だが、たいていの人はこれを想定し忘れる。

デフォルトではたいてい、画面が真っ白になるだけだ。だから、その「空の状態」に何を表示すべきかをビルダーに伝えておこう。その一文があるかないかで、ユーザーが「アプリが壊れている」と思うか、「自分が入力を間違えた」と思うかが変わってくる。

ついでに、検索をクリアして全リストに戻る方法もはっきり分かるようにしておこう。ボックスの中の小さな「×」でもいいし、「クリア」というリンクでもいい。抜け出せない検索の中で立ち往生してしまう人は、思っている以上に多い。

フィルターボックスではなくAI検索が必要になるのはどんなとき?

判断基準は感覚ではなく、2つの具体的なサインだ——タイプミスと、意味だ。人が「stephanie」と検索して「Stefanie」を見逃してしまうなら、近い綴りも許容する寛容なマッチングが必要だ——ビルダーには「スペルが多少違っていても結果が見つかる検索」を依頼しよう。そして、「billing」という単語を探すのではなく、本当に「請求まわりの問題についてのメモを見つけたい」というなら、それこそがAIを使った賢いタイプの検索だ——シンプルなボックスでは解決できない問題を解決してくれるなら、追加のコストと複雑さをかける価値がある。

ただし、そこから始めないこと。まずは絞り込みボックスから始め、タイプミスが問題になったら寛容なマッチングを加え、「単語を一致させる」だけでは足りなくなったときに初めて、賢いバージョンに手を伸ばす。ほとんどのアプリは、最初のステップより先に進む必要すらない。

だから、何かを作る前に、まず1週間、自分自身が自分のアプリをどう使うかを観察してみよう。何度もスクロールして探しているもの——顧客、注文、レシピ——それこそが検索ボックスの本来の役目だ。まずはその一点のために作れば、使う人のほとんどにとっての問題を解決したことになる。