eコマース向けのインテリジェントな製品検索エンジン

Azure AI Bot Service

Azure AI Search

Az AI サービス

Azure SQL Database

Azure App Service

このシナリオ例では、専用の検索サービスを使用して、eコマース顧客の検索結果の関連性を大幅に高める方法を示します。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

ワークフロー

このシナリオでは、顧客が製品カタログを検索できる e コマース ソリューションについて説明します。

1. 顧客は、任意のデバイスから e コマース Web アプリケーション にアクセスします。
2. 製品カタログは、トランザクション処理用の Azure SQL データベース に保持されます。
3. Azure AI Search では、検索インデクサー を使用して、統合された変更追跡によって検索インデックスを自動的に最新の状態に保ちます。
4. 顧客の検索クエリは、AI Search サービスにオフロードされ、クエリが処理され、最も関連性の高い結果が返されます。
5. Web ベースの検索エクスペリエンスの代わりに、ソーシャル メディアまたはデジタル アシスタントから直接 会話ボットを使用して製品を検索し、検索クエリと結果を段階的に絞り込むこともできます。
6. 必要に応じて、スキルセット 機能を使用して、よりスマートな処理に人工知能を適用できます。

コンポーネント

• Azure App Service - Web Apps は、インフラストラクチャを管理することなく、自動スケーリングと高可用性を実現する Web アプリケーションをホストします。
• Azure SQL Database は、リレーショナル データ、JSON、空間、XML などの構造をサポートする、Microsoft Azure の汎用リレーショナル データベース管理サービスです。
• AI Search は、Web、モバイル、エンタープライズ アプリケーションのプライベートな異種コンテンツに対する豊富な検索エクスペリエンスを提供するクラウド ソリューションです。
• Azure AI Bot Service には、インテリジェント ボットを構築、テスト、デプロイ、管理するためのツールが用意されています。
• Azure AI サービス を すると、インテリジェント なアルゴリズムを使用して、自然なコミュニケーション方法を通じてユーザーのニーズを確認、聞き取り、話し、理解し、解釈できます。

選択肢

• たとえば、SQL Server のフルテキスト検索など、データベース内検索 機能を使用できますが、トランザクション ストアではクエリも処理されます (処理能力の必要性が高くなります)。また、データベース内の検索機能は制限されます。
• Azure Virtual Machines で Apache Lucene (AI Search が構築されている) オープンソースをホストすることもできますが、サービスとしてのインフラストラクチャ (IaaS) の管理に戻り、Ai Search が Lucene の上に提供する多くの機能の恩恵を受けることはできません。
• また、Azure Marketplace から Elasticsearch をデプロイすることも検討できます。これは、サードパーティ ベンダーの代替で対応できる検索製品ですが、この場合は IaaS ワークロードを実行しています。

データ層のその他のオプションは次のとおりです。

• Azure Cosmos DB - Microsoft のグローバル分散マルチモデル データベース。 Azure Cosmos DB には、MongoDB、Cassandra、Graph データ、単純なテーブル ストレージなどの他のデータ モデルを実行するためのプラットフォームが用意されています。 AI Search では、Azure Cosmos DB からのデータの直接インデックス作成もサポートされています。

シナリオの詳細

検索は、顧客が製品を検索して最終的に購入するための主要なメカニズムであり、検索結果が検索クエリの 意図 に関連していること、およびエンド ツー エンドの検索エクスペリエンスが、ほぼ瞬時の結果、言語分析、地理的位置照合、フィルター処理、ファセット、オートコンプリート、およびヒット強調表示を提供することで、検索の大手企業と一致することが不可欠になります。

SQL Server や SQL Database などのリレーショナル データベースに格納されている製品データを含む一般的な e コマース Web アプリケーションを想像してみてください。 検索クエリは、多くの場合、 クエリまたはフルテキスト検索 機能 使用してデータベース内で処理されます。 代わりに AI Search を使用することで、クエリ処理から運用データベースを解放し、顧客に可能な限り最高の検索エクスペリエンスを提供する実装が困難な機能を簡単に利用できます。 また、AI Search はサービスとしてのプラットフォーム (PaaS) コンポーネントであるため、インフラストラクチャの管理や検索の専門家になることについて心配する必要はありません。

潜在的なユース ケース

このソリューションは小売業界向けに最適化されています。

関連するその他のユース ケースは次のとおりです。

• ユーザーの物理的な場所の近くに不動産の登録情報または店舗を見つける (施設と不動産業界の場合)。
• ニュース サイトで記事を検索したり、スポーツの結果を探したりすると、最近の 情報 (スポーツ、メディア、エンターテイメント業界向け) の が高くなります。
• ポリシー作成者や公証など、ドキュメント中心の 組織 大規模なリポジトリを検索します。

最終的に、何らかの形の検索機能を備える アプリケーションを すると、専用の検索サービスを利用できます。

考慮 事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Frameworkの に関するページを参照してください。

スケーラビリティ

AI Search サービスの 価格レベルの は、主に 容量計画 に使用されます。これは、取得する最大ストレージと、プロビジョニングできるパーティションとレプリカの数が定義されているためです。 パーティション では、より多くのドキュメントのインデックス作成と書き込みスループットの向上が可能になりますが、レプリカ 1 秒あたりのクエリ数 (QPS) と高可用性が向上します。

パーティションとレプリカの数は動的に変更できますが、価格レベルを変更することはできません。 そのため、ターゲット ワークロードに適したレベルを慎重に検討する必要があります。 レベルを変更する必要がある場合は、新しいサービスを並べてプロビジョニングし、そこでインデックスを再読み込みする必要があります。その時点で、新しいサービスでアプリケーションをポイントできます。

可用性

AI Search では、99.9% 可用性サービス レベル アグリーメント (SLA) が提供され、少なくとも 2 つのレプリカがある場合は 読み取り (つまりクエリ)、少なくとも 3 つのレプリカがある場合は 更新 (つまり、検索インデックスの更新) が行われます。 そのため、顧客が確実に検索 できるようにする場合は少なくとも 2 つのレプリカをプロビジョニングし、インデックス に対する実際の 変更も高可用性操作と見なす必要がある場合は 3 つをプロビジョニングする必要があります。

ダウンタイムなしでインデックスに重大な変更を加える必要がある場合 (データ型の変更、フィールドの削除、名前変更など)、インデックスを再構築する必要があります。 サービス レベルの変更と同様に、これは新しいインデックスを作成し、それをデータと共にリポジトリし、新しいインデックスを指すアプリケーションを更新することを意味します。

安全

AI Search は、多くの セキュリティとデータプライバシーの標準に準拠しているため、ほとんどの業界で使用できます。

サービスへのアクセスをセキュリティで保護するには、Azure ロールベースのアクセス制御 (RBAC) を使用するか、API キー接続します。

Azure RBAC は、Microsoft Entra ID と統合される Azure ロールを使用するため、使用することをお勧めします。 Azure ロールを使用する場合は、Azure リソースのマネージド IDなどのパスワードレス認証方法を使用することもできます。

API キーには、すべてのコンテンツ操作に対してフル アクセスを提供する 管理キーと、検索インデックスのドキュメント コレクションへの読み取り専用アクセスを提供する クエリ キーが含まれます。 特に、Web ブラウザーで実行されているスクリプトなどのエンド ユーザー デバイスが検索を実行する場合は、管理者キーではなくクエリ キーを使用するようにインデックスを更新する必要のないアプリケーションを設定する必要があります。

また、プライベート エンドポイントを介して公開 することで、ネットワーク レベルで AI Search サービスへのアクセスをセキュリティで保護することもできます。

検索の関連性

eコマース アプリケーションの成功度は、検索結果の顧客との関連性によって大きく異なります。 ユーザー調査に基づいて最適な結果を提供するように検索サービスを慎重に調整するか、検索トラフィック分析 に依存して顧客の検索パターンを理解することで、データに基づいて意思決定を行うことができます。

検索サービスを調整する一般的な方法は次のとおりです。

• スコアリング プロファイルを使用、クエリに一致したフィールド、データの最近の情報、ユーザーとの地理的距離などに基づいて、検索結果の関連性に影響を与えます。
• 高度 自然言語処理スタックを使用してクエリをより適切に解釈する、Microsoft が提供する言語アナライザー を使用します。
• カスタム アナライザー 使用して、製品が正しく検出されることを確認します。特に、製品のメーカーやモデルなどの言語ベース以外の情報を検索する場合。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の柱の概要」を参照してください。

このシナリオの実行コストを調べるには、前述のすべてのサービスがコスト計算ツールで事前に構成されています。 特定のユース ケースの価格がどのように変化するかを確認するには、予想される使用量に合わせて適切な変数を変更します。

処理するトラフィックの量に基づいて、次のサンプル コスト プロファイルを検討してください。

• Small: このプロファイルでは、1 つの Standard S1 Web アプリを使用して Web サイトをホストし、Azure AI Bot Service の Free レベル、1 つの Basic 検索サービス、Standard S2 SQL Database をホストします。
• 中: このプロファイルは、Web アプリを Standard S3 層の 2 つのインスタンスにスケールアップし、検索サービスを Standard S1 層にアップグレードし、Standard S6 SQL Database を使用します。
• 大きな: このプロファイルでは、Premium P2V2 Web アプリの 4 つのインスタンスを使用し、Azure AI Bot Service を Standard S1 レベル (Premium チャネルでは 1.000.000 メッセージ) にアップグレードし、Standard S3 検索サービスと Premium P6 SQL Database の 2 つのユニットを使用します。

このシナリオをデプロイする

このシナリオのバージョンをデプロイするには、ジョブ検索 Web サイトを実行する .NET サンプル アプリケーションを提供する、この のチュートリアル に従います。 これまでに説明した AI 検索機能の大部分を示します。

貢献

この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。

プリンシパルの作成者:

• Jelle Druyts |プリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

AI Search の詳細については、ドキュメント センターの にアクセスするか、サンプルを確認してください。

他の Azure コンポーネントの詳細については、次のリソースを参照してください。

• Azure SQL Database とは
• App Service の概要
• Azure AI Bot Service のドキュメント を する
• Azure AI サービスとは

関連リソース

• コンテンツベースのレコメンデーション システム を構築する

このシナリオ例では、専用の検索サービスを使用して、eコマース顧客の検索結果の関連性を大幅に高める方法を示します。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

ワークフロー

このシナリオでは、顧客が製品カタログを検索できる e コマース ソリューションについて説明します。

1. 顧客は、任意のデバイスから e コマース Web アプリケーション にアクセスします。
2. 製品カタログは、トランザクション処理用の Azure SQL データベース に保持されます。
3. Azure AI Search では、検索インデクサー を使用して、統合された変更追跡によって検索インデックスを自動的に最新の状態に保ちます。
4. 顧客の検索クエリは、AI Search サービスにオフロードされ、クエリが処理され、最も関連性の高い結果が返されます。
5. Web ベースの検索エクスペリエンスの代わりに、ソーシャル メディアまたはデジタル アシスタントから直接 会話ボットを使用して製品を検索し、検索クエリと結果を段階的に絞り込むこともできます。
6. 必要に応じて、スキルセット 機能を使用して、よりスマートな処理に人工知能を適用できます。

コンポーネント

• Azure App Service - Web Apps は、インフラストラクチャを管理することなく、自動スケーリングと高可用性を実現する Web アプリケーションをホストします。
• Azure SQL Database は、リレーショナル データ、JSON、空間、XML などの構造をサポートする、Microsoft Azure の汎用リレーショナル データベース管理サービスです。
• AI Search は、Web、モバイル、エンタープライズ アプリケーションのプライベートな異種コンテンツに対する豊富な検索エクスペリエンスを提供するクラウド ソリューションです。
• Azure AI Bot Service には、インテリジェント ボットを構築、テスト、デプロイ、管理するためのツールが用意されています。
• Azure AI サービス を すると、インテリジェント なアルゴリズムを使用して、自然なコミュニケーション方法を通じてユーザーのニーズを確認、聞き取り、話し、理解し、解釈できます。

選択肢

• たとえば、SQL Server のフルテキスト検索など、データベース内検索 機能を使用できますが、トランザクション ストアではクエリも処理されます (処理能力の必要性が高くなります)。また、データベース内の検索機能は制限されます。
• Azure Virtual Machines で Apache Lucene (AI Search が構築されている) オープンソースをホストすることもできますが、サービスとしてのインフラストラクチャ (IaaS) の管理に戻り、Ai Search が Lucene の上に提供する多くの機能の恩恵を受けることはできません。
• また、Azure Marketplace から Elasticsearch をデプロイすることも検討できます。これは、サードパーティ ベンダーの代替で対応できる検索製品ですが、この場合は IaaS ワークロードを実行しています。

データ層のその他のオプションは次のとおりです。

• Azure Cosmos DB - Microsoft のグローバル分散マルチモデル データベース。 Azure Cosmos DB には、MongoDB、Cassandra、Graph データ、単純なテーブル ストレージなどの他のデータ モデルを実行するためのプラットフォームが用意されています。 AI Search では、Azure Cosmos DB からのデータの直接インデックス作成もサポートされています。

シナリオの詳細

検索は、顧客が製品を検索して最終的に購入するための主要なメカニズムであり、検索結果が検索クエリの 意図 に関連していること、およびエンド ツー エンドの検索エクスペリエンスが、ほぼ瞬時の結果、言語分析、地理的位置照合、フィルター処理、ファセット、オートコンプリート、およびヒット強調表示を提供することで、検索の大手企業と一致することが不可欠になります。

SQL Server や SQL Database などのリレーショナル データベースに格納されている製品データを含む一般的な e コマース Web アプリケーションを想像してみてください。 検索クエリは、多くの場合、 クエリまたはフルテキスト検索 機能 使用してデータベース内で処理されます。 代わりに AI Search を使用することで、クエリ処理から運用データベースを解放し、顧客に可能な限り最高の検索エクスペリエンスを提供する実装が困難な機能を簡単に利用できます。 また、AI Search はサービスとしてのプラットフォーム (PaaS) コンポーネントであるため、インフラストラクチャの管理や検索の専門家になることについて心配する必要はありません。

潜在的なユース ケース

このソリューションは小売業界向けに最適化されています。

関連するその他のユース ケースは次のとおりです。

• ユーザーの物理的な場所の近くに不動産の登録情報または店舗を見つける (施設と不動産業界の場合)。
• ニュース サイトで記事を検索したり、スポーツの結果を探したりすると、最近の 情報 (スポーツ、メディア、エンターテイメント業界向け) の が高くなります。
• ポリシー作成者や公証など、ドキュメント中心の 組織 大規模なリポジトリを検索します。

最終的に、何らかの形の検索機能を備える アプリケーションを すると、専用の検索サービスを利用できます。

考慮 事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Frameworkの に関するページを参照してください。

スケーラビリティ

AI Search サービスの 価格レベルの は、主に 容量計画 に使用されます。これは、取得する最大ストレージと、プロビジョニングできるパーティションとレプリカの数が定義されているためです。 パーティション では、より多くのドキュメントのインデックス作成と書き込みスループットの向上が可能になりますが、レプリカ 1 秒あたりのクエリ数 (QPS) と高可用性が向上します。

パーティションとレプリカの数は動的に変更できますが、価格レベルを変更することはできません。 そのため、ターゲット ワークロードに適したレベルを慎重に検討する必要があります。 レベルを変更する必要がある場合は、新しいサービスを並べてプロビジョニングし、そこでインデックスを再読み込みする必要があります。その時点で、新しいサービスでアプリケーションをポイントできます。

可用性

AI Search では、99.9% 可用性サービス レベル アグリーメント (SLA) が提供され、少なくとも 2 つのレプリカがある場合は 読み取り (つまりクエリ)、少なくとも 3 つのレプリカがある場合は 更新 (つまり、検索インデックスの更新) が行われます。 そのため、顧客が確実に検索 できるようにする場合は少なくとも 2 つのレプリカをプロビジョニングし、インデックス に対する実際の 変更も高可用性操作と見なす必要がある場合は 3 つをプロビジョニングする必要があります。

ダウンタイムなしでインデックスに重大な変更を加える必要がある場合 (データ型の変更、フィールドの削除、名前変更など)、インデックスを再構築する必要があります。 サービス レベルの変更と同様に、これは新しいインデックスを作成し、それをデータと共にリポジトリし、新しいインデックスを指すアプリケーションを更新することを意味します。

安全

AI Search は、多くの セキュリティとデータプライバシーの標準に準拠しているため、ほとんどの業界で使用できます。

サービスへのアクセスをセキュリティで保護するには、Azure ロールベースのアクセス制御 (RBAC) を使用するか、API キー接続します。

Azure RBAC は、Microsoft Entra ID と統合される Azure ロールを使用するため、使用することをお勧めします。 Azure ロールを使用する場合は、Azure リソースのマネージド IDなどのパスワードレス認証方法を使用することもできます。

API キーには、すべてのコンテンツ操作に対してフル アクセスを提供する 管理キーと、検索インデックスのドキュメント コレクションへの読み取り専用アクセスを提供する クエリ キーが含まれます。 特に、Web ブラウザーで実行されているスクリプトなどのエンド ユーザー デバイスが検索を実行する場合は、管理者キーではなくクエリ キーを使用するようにインデックスを更新する必要のないアプリケーションを設定する必要があります。

また、プライベート エンドポイントを介して公開 することで、ネットワーク レベルで AI Search サービスへのアクセスをセキュリティで保護することもできます。

検索の関連性

eコマース アプリケーションの成功度は、検索結果の顧客との関連性によって大きく異なります。 ユーザー調査に基づいて最適な結果を提供するように検索サービスを慎重に調整するか、検索トラフィック分析 に依存して顧客の検索パターンを理解することで、データに基づいて意思決定を行うことができます。

検索サービスを調整する一般的な方法は次のとおりです。

• スコアリング プロファイルを使用、クエリに一致したフィールド、データの最近の情報、ユーザーとの地理的距離などに基づいて、検索結果の関連性に影響を与えます。
• 高度 自然言語処理スタックを使用してクエリをより適切に解釈する、Microsoft が提供する言語アナライザー を使用します。
• カスタム アナライザー 使用して、製品が正しく検出されることを確認します。特に、製品のメーカーやモデルなどの言語ベース以外の情報を検索する場合。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の柱の概要」を参照してください。

このシナリオの実行コストを調べるには、前述のすべてのサービスがコスト計算ツールで事前に構成されています。 特定のユース ケースの価格がどのように変化するかを確認するには、予想される使用量に合わせて適切な変数を変更します。

処理するトラフィックの量に基づいて、次のサンプル コスト プロファイルを検討してください。

• Small: このプロファイルでは、1 つの Standard S1 Web アプリを使用して Web サイトをホストし、Azure AI Bot Service の Free レベル、1 つの Basic 検索サービス、Standard S2 SQL Database をホストします。
• 中: このプロファイルは、Web アプリを Standard S3 層の 2 つのインスタンスにスケールアップし、検索サービスを Standard S1 層にアップグレードし、Standard S6 SQL Database を使用します。
• 大きな: このプロファイルでは、Premium P2V2 Web アプリの 4 つのインスタンスを使用し、Azure AI Bot Service を Standard S1 レベル (Premium チャネルでは 1.000.000 メッセージ) にアップグレードし、Standard S3 検索サービスと Premium P6 SQL Database の 2 つのユニットを使用します。

このシナリオをデプロイする

このシナリオのバージョンをデプロイするには、ジョブ検索 Web サイトを実行する .NET サンプル アプリケーションを提供する、この のチュートリアル に従います。 これまでに説明した AI 検索機能の大部分を示します。

貢献

この記事は Microsoft によって管理されています。 もともとは次の共同作成者によって作成されました。

プリンシパルの作成者:

• Jelle Druyts |プリンシパル カスタマー エンジニア

非公開の LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次の手順

AI Search の詳細については、ドキュメント センターの にアクセスするか、サンプルを確認してください。

他の Azure コンポーネントの詳細については、次のリソースを参照してください。

• Azure SQL Database とは
• App Service の概要
• Azure AI Bot Service のドキュメント を する
• Azure AI サービスとは

関連リソース

• コンテンツベースのレコメンデーション システム を構築する