想像してみてください。あなたは社内のアプリを使っています。人事ポータルかもしれませんし、顧客サポートのデータベース、あるいは従うべき社内規定が詰まった社内ウィキかもしれません。検索バーに質問を入力します。例えば顧客との会食の経費生産はどうすればいいの?といった具合です。エンターキーを押すと何が出てくるでしょうか?何も出てきません。あるいはもっと悪いことに、3年前の無関係なPDFがずらりと並び、入力した単語が少し含まれているだけの結果が表示されます。検索は私たちが毎日使うものです。しかし、そのほとんどがひどい出来です。ですが、実はそうある必要はないのです。もしアプリがあなたの問いかけを真に理解できたらどうでしょうか? Googleのように、完璧な単語を使わなくても正しい答えを見つけてくれる検索ができたらどうでしょう?今日はAzure iSearchについて解説します。それが一体何なのか、裏側でどう動いているのか、そしてなぜ現代のアプリの検索エンジンとして選ばれているのかを見ていきます。コーヒーを片手に早速始めましょう。なぜ検索は使いにくいのか、検索がなぜ失敗するのかを理解するには、ほとんどのアプリが実際に言っている方法を見る必要があります。従来の方法は、キーワード検索や語彙検索と呼ばれます。ボックスにノートPCと入力すると、システムはその単語を正確に含むすべての文書を探し出します。その仕組みの多くは、BM25というアルゴリズムを使用しています。複雑ではありませんが、独自の上手さがあります。BM25はいくつかの要素に基づいて結果をランク付けします。検索語が文書内にどれだけ頻繁に現れるか、文書の長さ、そしてデータセット全体でその検索語がどれほど珍しいか、といった要素です。これらを基に、どの文書が最も関連性が高いかを判定する、非常に洗練された単語カウンターだと考えてください。ここで問題が生じます。人間の言語は曖昧だからです。人は文書と同じ単語を使って質問するとは限りません。具体例を挙げましょう。ユーザーがサポートポータルにこう入力します。ビデオ通話中にノートPCがフリーズするキーワード検索は、ノートPC、フリーズ、ビデオ、通話、といった単語を含む文書を忠実に探します。

しかし、そのトピックに関する最適な記事のタイトルが、チーム会議中のシステムハングのトラブルシューティングだったらどうでしょう?あるいは、ドッキング中のノートPCにおけるCPUスロットリングの管理というタイトルだったら、キーワード検索ではそれらを完全に見逃してしまいます。なぜでしょうか?言葉が一致しないからです。革新的な問題はこれです。キーワード検索はスペルを理解します。文字のパターンは理解しますが、その意味は理解していないのです。結果として表示されるのは、文字は合っていても、中身は間違っていることが多いのです。では、単語の一致だけではこれほど多くの欠落が生じるなら、代わりとなる選択肢は何でしょうか?新しい手法、ベクトル検索。ベクトル検索は、これまでとは全く異なるやり方です。正確な単語の一致ではなく、意味で一致させるのです。抽象的に聞こえるかもしれませんので、詳しく解説しましょう。最もシンプルな定義はこれです。ベクトルとは、コンピュータが扱える形式で何かを表した数字のリストにすぎません。それだけです。ただの数字のリストです。エンベディングとは、テキストの意味を捉える特別な種類のベクトルです。文や段落、あるいは文書全体を、長い数字のリストへと変換するのです。コンピュータは単語そのものは理解しませんが、数字は理解します。わかりやすい例え話をしましょう。ベクトルを地図上の座標のように考えてみてください。地図では、似た場所は近くに配置されます。ベクトル空間でも、似た概念は近くに配置されるのです。Oのベクトルと、上のベクトルは近い位置にあります。関連する概念だからです。一方で、Oと、リンゴのベクトルは、遠く離れた位置にあります。コンピュータは、Oが人間にとって何を意味するかは知りませんが、その座標と他のあらゆる単語や文書の座標との距離を測ることはできます。いわば、アイデアのためのGPSのようなものです。システムは数字を見るだけで、概念同士がどれだけ離れているかを知ることができます。ベクトルを使って検索を行う際、システムはクエリをエンベディングに変換します。そして、自分のクエリに最も近いエンベディングを持つ文書を探し出します。

単なる語彙ではなく、意味を共有する意味的に近いものを見つけ出すのです。例えば、ノートPCがフリーズした際のトラブルシューティングを探しているとしましょう。キーワード検索では、フリーズやハングアップといった言葉を正確に入力する必要があります。しかしベクトル検索なら、コンピュータが何度も固まると入力しても正しい文書が見つかります。これこそが、意味を理解する力なのです。先ほどの検索例に戻りましょう。ユーザーがノートPCが頻繁にフリーズすると入力します。ベクトル検索なら、クエリにその単語が含まれていなくても、チーム会議中のシステムハングに関する記事を提示できます。なぜでしょうか?ベクトル空間において、システムハングとコンピュータのフリーズの意味が非常に近いためです。これらの概念は、あの地図上で近くに位置しているのです。システムは正確な単語にはこだわらず、あなたの意味を汲み取ります。これがブレイクスルーです。コンピュータが単なるスペルではなく、意図を理解し始めるのです。キーワード検索では完全に見逃してしまうような回答を見つけ出します。しかし、ベクトル検索にも弱点はあります。どうしても必要な完全一致を見逃してしまうことがあるのです。技術者が、X87570のような特定のエラーコードを検索する場合、ベクトル検索ではそのコードを解説した正確なドキュメントではなく、ディスクエラーやファイルシステムの破損に関するドキュメントが優先されてしまうことがあります。正確さを犠牲にして文脈の理解を優先しているのです。つまり、2つの方法があるわけです。キーワード検索は正確性に優れています。正確な用語、製品ID、契約番号を見つけるのに最適です。ベクトル検索は意味の理解に優れています。適切な言葉を使わなくても正しい答えを見つけ出してくれます。それぞれに盲点があります。そこで、ある当然の疑問が浮かびます。両方のアプローチを組み合わせて、いいとこ取りをすることはできないでしょうか?それがハイブリッド検索というブレイクスルーです。ハイブリッド検索こそが、両者の長所を兼ね備えた手法です。キーワード検索とベクトル検索を同時に実行し、その結果を1つのランキングリストに統合します。

どちらか一方を選ぶのではなく、RRF、レシプロカルランクフュージョンと呼ばれる手法を用いています。仕組みは以下の通りです。RRFは、各ドキュメントがキーワード検索とベクトル検索の結果でそれぞれ何位にランク付けされているかを確認します。そして、それらを合わせたスコアを算出します。両方で高く評価されたドキュメントは、順位が引き上げられます。2人の専門家の意見を聞いて、平均を取るようなものです。どちらか一方だけよりも、最終的な回答の信頼性が高まります。キーワード検索とベクトル検索では根本的に強みが異なるため、この組み合わせが重要になります。キーワード検索は、完全一致に優れています。製品ID、契約番号、固有名称、エラーコードなどを探す際に頼りになります。正確で予測可能です。ベクトル検索は、意味的な類似性に優れており、正確な言葉が含まれていなくても、クエリと意味を共有するドキュメントを見つけ出します。これらを合わせることで、互いの盲点を補い合えるのです。システムは、単一のクエリで完全一致と概念的な一致の両方を捉えます。これこそが真の力です。これは単なる理論上の話ではありません。エンタープライズ向けのハイブリッド検索に関する調査では、データセットに応じて70から80%の検索精度が得られることが示されています。これは、ベクトル検索単体と比較して約15から20ポイント高い数値です。この違いは大きく、実際のビジネス成果として現れています。会計プラットフォームのゼロ、お礼にあげましょう。彼らはコベオという企業を通じて、カスタマーサポートにハイブリッド検索を導入しました。導入から3ヶ月以内に、セルフサービスによる解決率が20%向上しました。顧客はサポートに連絡することなく、自分で答えを見つける機会が増えたのです。同じケーススタディ内の他社では、サポート案件の解決までの時間が最大40%短縮されました。つまり、エージェントは正しい情報をより早く見つけ、顧客はより迅速に回答を得られ、サポートコストも削減されたということです。これは単なる便利な機能ではなく、利益に直接貢献する測定可能なインパクトなのです。

ここが重要なポイントです。ハイブリッド検索は、単なる便利なアップグレードや機能リストの項目の一つではなく、測定可能なほど優れたものです。精度が向上し、再現率が高まり、より良いユーザー成果をもたらします。このアプローチの組み合わせこそが、現代のアプリケーションにおいてAzure iSearchを強力なものにしている理由です。しかし、この組み合わせによって実現するもう一つの技術があり、現在大きな注目を集めています。それが、ラグと呼ばれるものです。それでは、ラグについてお話ししましょう。ラグは、リトリーバルオーグメンテッドジェネレーション、原作拡張生成の略称です。少し難しい言葉ですが、最もシンプルな定義はこうです。AIアシスタントが学習に使用されていない情報にアクセスできるようにするフレームワークです。GPTのような大規模言語モデルは歴史や科学、プログラミングには詳しいですが、あなたの会社の社内文書ポリシー、顧客履歴、あるいはチームが従う特定の業務手順については知りません。多くの人は、そうした社内知識をそのままモデルに詰め込めば良いと考えがちです。しかし、それではうまくいきません。コストがかかりますし、更新も困難だからです。ラグはこの問題を懸命な方法で解決します。すべてをモデルに詰め込む代わりに、誰かが質問した瞬間にナレッジベースから関連情報を検索するのです。ユーザーのクエリを受け取り、社内データを検索して最も関連性の高いドキュメントを見つけ、そのコンテキストを元の質問と一緒にLLMに入力します。すると、LLMはあなたのデータに基づいた回答を生成します。これこそが魔法のような仕組みなのです。Azure iSearchは、その方程式における検索の半分を担っています。LLMが正確に回答できるよう、適切なドキュメントを見つけ出すエンジンなのです。強固な検索レイヤーがなければ、ラグシステムの性能は見つけ出すドキュメントの質に依存してしまいます。ここでハイブリッド検索が進化を発揮します。ラグのクエリは多くの場合自然言語の質問であり、答えは全く異なる用語が使われたドキュメントの中にあることが多いためです。

その違いを如実に示すいくつかの数字をご紹介しましょう。エンタープライズ検索に関する調査では、ハイブリッドラグフレームワークはキーワード検索のみと比較して、トップ系の検索精度が18倍から25倍に向上しました。ワークフローのタスク完了精度は21倍に向上しました。つまり、ハイブリッド検索を使用したラグシステムでサポートされている場合、ユーザーが複雑なタスクを成功させる可能性が飛躍的に高まったということです。全体として、適切に実装されたラグシステムは検索精度を平均85%向上させることができ、一部の専門領域では99%に近い精度に達します。また、LLMは独自の推測ではなく検索されたコンテキストに基づいて回答を生成するため、ラグシステムではハルシネーション、誤情報の発生が約40%減少しました。これこそが、Azure iSearchがAIエージェントやコパイロットを構築する上で不可欠である理由です。それは、ビジネスの現場においてLLMを信頼できるものにする、根拠に基づいた事実検索を提供するからです。正確に質問に答え、情報源を引用する必要があるアシスタントを構築する場合、ハイブリッド検索とラグを組み合わせたアーキテクチャが最適です。つまり、ハイブリッド検索とラグは強力な組み合わせなのです。しかし、これは実際にはどのようなものなのでしょうか。現実世界への影響です。では、実際にどこで活用されているのでしょうか。いくつか例を挙げてみましょう。eコマースはおそらく最も身近な例です。顧客が検索バーに快適なランニングシューズと入力したとします。製品リストには、マーケティングチームが選んだクッション性のある運動靴と記載されているかもしれません。キーワード検索だけでは、この一致を見逃してしまいます。Azure iSearchなら、システムが文脈から快適とクッション性がほぼ同じ意味であることを理解します。言葉が一致しなくても、正しい製品を提示できるのです。これによって、顧客は不満を感じてサイトを離れることなく、欲しいものを見つけることができます。カスタマーサポートポータルでも同様です。顧客がサブスクリプションを解約するには?と入力したと想像してください。

関連するポリシーには、サービス利用契約の終了というタイトルがついているかもしれません。ハイブリッド検索は、法律用語のキーワード一致でその文章を見つけるだけでなく、セマンティックな類似性によって、プランの早期終了に関するFAQも提示します。顧客は5つの異なる記事を探し回ることなく、包括的な回答を得ることができます。法務文書の検索もその一つです。弁護士は、正確な条項番号やセクションの参照に基づいて契約書を検索する必要があります。それは純粋なキーワード検索の領域ですが、同時に、表現が異なっていても異なる契約書間で類似した内容を見つける必要もあります。ハイブリッド検索はこれを単一のクエリで処理でき、規制の厳しい業界では、なぜその検索結果が表示されたのかを正確に追跡できることがコンプライアンス紙不可欠です。社内ナレッジベースも同様のメリットがあります。従業員が休暇規定を検索すると、公式の人事文書だけでなく、ホームチームからの繰り越し日数に関するメールや、社内イントラネットに投稿された最近の更新情報も表示されます。検索機能が、これらすべてが同じ質問に関連していることを理解しているのです。製造業はあまり目立ちませんが、強力な活用例です。技術者が検索インターフェースに、モーター加熱の修理と入力します。システムは機器マニュアルのトラブルシューティングセクションと、関連部品を示すスキャンされた図面を返します。図面が画像であっても、Azure iSearchはテキストコンテンツを抽出してインデックス化できるため、検索結果に表示されます。これらすべての例に共通するのは、非構造化データであるという点です。PDF、ワード文書メールのサポートチケット、スキャンされた画像などです。従来のデータベースクエリやキーワード検索は、このようなデータのために設計されたものではありませんでした。Azure iSearchはこの世界のために構築されており、詳しく調べるほど、ハイブリッド検索が単なる便利な機能ではないことが明確になります。これは現代のアプリケーション構築における基盤となる要素です。どのように各要素が組み合わさるのか。

では、内部では実際にどのように動作しているのでしょうか。Azure iSearchには、データソース、インデクサー、検索インデックスという3つの主要な構成要素があります。データソースとは、情報が格納されている場所です。BlobストレージやAzure SQLデータベース、Cosmos DB、あるいはSharePointなどが挙げられます。検索可能にする必要があるせいのデータです。整理されるのを待っている書類の山だと考えてください。インデクサーは、データソースからデータを読み取り、コンテンツを抽出し、設定したAIエンリッチメントを適用して、検索インデックスを構築するパイプラインです。わかりやすい例えを紹介します。図書館員が本でいっぱいの倉庫に入る様子を想像してください。すべての本を読み、詳細なメモを取り、重要なテーマや実態を特定し、すべてをカードカタログに整理します。その読み込みとメモ取りの作業がインデックス作成プロセスです。検索インデックスが、そのカードカタログに当たります。本そのものではありません。必要な情報をミリ秒単位で見つけ出せるように最適化された構造化システムなのです。クエリを入力したとき、システムは元のドキュメントに戻ってスキャンすることはありません。代わりに、すべてがどこにあるかをすでに把握しているインデックスを参照します。この事前の整理を、点置インデックスと呼びます。ドキュメントにどんな単語が含まれているかを保存するのではなく、単語ごとにそれが含まれるドキュメントのリストを保存します。

その結果、劇的な速度向上が実現します。データ量が増えるほど時間がかかる全ドキュメントのスキャンではなく、正しい場所に直接アクセスできます。数百万ものドキュメントがある場合、それは検索に数秒かかるか、数ミリ秒で済むかという決定的な違いとなります。これでAzure iSearchとは何か、主要コンポーネントがどう組み合わさるのか、そしてなぜハイブリッド検索が革新的なのかが理解できたはずです。最後に、これで実際に何ができるのかをいくつか見ていきましょう。まず、自分のデータを理解することです。SQLの製品テーブルやデータベースの顧客レコードなど、すでに構造化され、行と列が整理されたデータであれば、SQLで直接クエリを実行できます。Azure iSearchは非構造化テキストのために構築されています。PDF、メール、ワードドキュメント、サポートチケットなどが対象です。そこにこそ、真の価値があるのです。次に、ラグアプリケーションやAIアシスタントを構築するなら、ハイブリッド検索を備えたAzure iSearchが最適な検索エンジンとなります。正確性のためのキーワード一致と、文脈を理解するためのセマンティック検索の両方を提供します。その組み合わせにより、どちらか一方のアプローチよりも信頼性が高く、出典も示せる回答が得られます。3つ目は、設定を複雑にしすぎないことです。Azureポータルには、データインポートウィザードがあります。ブログストレージを接続し、いくつかの設定を行うだけで、インデクサーが最初のインデックスを作成してくれます。1時間もかからずに最初の検索を実行できるでしょう。以上が、Azure iSearchのわかりやすい解説です。乱雑で構造化されていない情報を、検索可能でAIが活用できる知識へと変えてくれます。ご視聴ありがとうございました。チャンネル登録をお願いします。また次回の動画でお会いしましょう。