SharePoint Server でクロールとフェデレーションを計画する
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
SharePoint Server で検索を実行できるようになる前に、検索できるようにするコンテンツをクロールまたはフェデレーションする必要があります。 コンテンツをクロールするときは、Search Service がクエリ (検索要求) の実行対象となる検索インデックスを作成します。 外部プロバイダー (Bing など) からの検索結果とローカルの検索インデックスからの検索結果を並べて表示するように検索システムを構成することもできます。 外部プロバイダーから検索結果を取得してローカルで結果を表示するこのプロセスを、フェデレーションと呼びます。
コンテンツ ソースを計画する
コンテンツ ソースとは、クロール対象となるホスト、クロールするコンテンツの種類 (SharePoint コンテンツ、ファイル共有など)、クロール スケジュール、クロールの深さなど、一連のクロール設定を定義したものです。
Search Service アプリケーションを作成すると、Search Service アプリケーションは自動的に事前構成されたコンテンツ ソースであるローカルの SharePoint サイトを用意します。 このコンテンツ ソースを使用して、Search Service アプリケーションに関連付けられた Web アプリケーションのすべての SharePoint コンテンツをクロールする方法を指定できます。
使用する種類が 1 種類のみのコンテンツの場合 (たとえば、すべてのコンテンツの種類が SharePoint サイトかファイル共有の場合)、1 つのコンテンツ ソースのみを定義することをご検討ください。 ただし、ホストごとにさまざまな種類のコンテンツや固有の要件がある場合は、複数のコンテンツ ソースを定義することをご検討ください。 追加のコンテンツ ソースの作成を計画するのは、次の作業を行う必要がある場合です。
ファイル共有や基幹業務アプリケーションのデータなど、さまざまな種類のコンテンツをクロールする。
コンテンツによってクロール スケジュールを変える。
クロールするコンテンツの量を制限または増やす。
さまざまなサイトをクロールするときに異なる優先順位を設定する。
ある種類のコンテンツを他のコンテンツより常に新しくしておく。
Search Service アプリケーションごとに多数のコンテンツ ソースを作成できますが、各コンテンツ ソースにはオーバーヘッドがあります。 そのため、クロール優先順位の違いやクロール スケジュールなど、他の運用要件を満たす範囲で、作成するコンテンツ ソースの数をなるべく少なくすることをお勧めします。 各コンテンツ ソースには最大で 100 個の開始アドレスを入れることができます。
さまざまな種類のコンテンツのクロールを計画する
1 つのコンテンツ ソースにつき 1 種類のコンテンツしかクロールできません。 たとえば、SharePoint サイトの開始アドレスを含んでいるコンテンツ ソースと、ファイル共有の開始アドレスを含んでいる別のコンテンツ ソースは作成できますが、SharePoint サイトとファイル共有両方の開始アドレスを含んでいる 1 つのコンテンツ ソースは作成できません。 次の表に、構成できるコンテンツ ソースの種類を示します。
| **この種のコンテンツ ソースを使用する | 対象のコンテンツ |
|---|---|
| SharePoint サイト | 同じファームの SharePoint サイト、または別々の SharePoint Server ファームの SharePoint サイト 同じファームまたは異なるSharePoint Server 2019の SharePoint サイト、SharePoint Server 2016、SharePoint Server 2013、SharePoint Server 2010、SharePoint Foundation 2010、または Microsoft Search Server 2010 ファーム。 同じファームの SharePoint サイト、または別々の Office SharePoint Server 2007、Windows SharePoint Services 3.0、Search Server 2008 ファームの SharePoint サイト。 |
| Web サイト | 組織で SharePoint サイトに配置されていないその他の Web コンテンツ。 インターネット上にある Web サイトのコンテンツ。 |
| ファイル共有 | 組織のファイル共有にあるコンテンツ。 セキュリティに関する注: Search Service がファイル共有をクロールする際、共有上のファイルのアクセス許可がそのファイルを含んでいるフォルダーのアクセス許可と異なる場合、ファイルのアクセス許可が優先され、セキュリティによる検索結果のトリミングに使われます。 そのため、適切なアイテムのみが検索結果に表示されるようにするには、ファイル共有上のファイルのアクセス許可が適切であることをご確認ください。 ファイルのアクセス許可が適切でない場合は、検索インデックスまたは検索結果から特定のアイテムを削除することができます。 詳細については、「 Delete items from the search index or from search results in SharePoint Server」をご覧ください。 |
| Exchange パブリック フォルダー | Exchange 2007 および Exchange Server 2010 のパブリック フォルダー。 |
| Lotus Notes | Lotus Notes データベースに格納されている電子メール メッセージ。 注: 他の種類のコンテンツ ソースとは異なり、Lotus Notes コンテンツ ソース オプションは、該当する必要なソフトウェアをインストールして構成するまでユーザー インターフェイスに表示されません。 詳細については、「 Configure and use the Lotus Notes connector for SharePoint Server」をご覧ください (SharePoint Server にも適用されます)。 |
| Documentum | EMC Documentum システムのコンテンツ。 メモ： 適切な前提条件ソフトウェアと Microsoft SharePoint Indexing Connector for Documentum をインストールして構成する前に、EMC Documentum コンテンツをクロールすることはできません。 詳細については、「 Configure and use the Documentum connector in SharePoint Server」をご覧ください (SharePoint Server にも適用されます)。 |
| 基幹業務データ | 基幹業務アプリケーションに保存されているビジネス データ。 |
| カスタム リポジトリ | カスタム コネクタがインストールされ登録されている場合に限りクロールできるコンテンツ ソース。 |
基幹業務データのコンテンツ ソース
ビジネス データのコンテンツ ソースでは、データをホストするアプリケーションが Business Data Connectivity サービス アプリケーションの Application Model で指定されていることが必要です。 Business Data Connectivity サービスに登録されているすべてのアプリケーションをクロールする 1 つのコンテンツ ソースを作成するか、個々のアプリケーションをクロールする個別のコンテンツ ソースを作成できます。 詳細については、「SharePoint 2013 の検索コネクタ フレームワーク」をご覧ください (この MSDN 記事は SharePoint Server にも適用されます)。
サイト コレクションへのビジネス データの統合を計画する人とコンテンツの計画作成プロセス全体に関わる人は、多くの場合、異なります。 そのため、ビジネス アプリケーションの管理者をコンテンツの計画作成チームに含めて、ビジネス アプリケーションのデータをコンテンツに統合する方法や、それをサイト コレクションの中で効果的に示す方法について、助言をもらえるようにしてください。
異なるスケジュールでコンテンツをクロールする
以下の理由から、さまざまなスケジュールでコンテンツ ソースを定義することをご検討ください。
ダウン タイムと使用率のピーク時に対応するため。
更新頻度が高いコンテンツをより頻繁にクロールするため。
高速サーバーに配置されているコンテンツとは別に、低速サーバーに配置されているコンテンツをクロールするため。
更新要求が多い場合に継続的に SharePoint コンテンツ ソースをクロールするため。 詳細については、「Manage continuous crawls in SharePoint Server」を参照してください。
フル クロールを行う理由
Search Service アプリケーションの管理者が 1 つ以上のコンテンツ ソースに対してフル クロールを行う理由には、以下のようなものが考えられます。
Search Service アプリケーションを作成したばかりで、事前構成されたコンテンツ ソースである [ ローカルの SharePoint サイト] がまだクロールされていない。
一部のコンテンツ ソースが新しく、まだクロールされていない。
Search Service アプリケーションの管理者がコンテンツ ソースを変更した。
ファーム内のサービスにソフトウェアの更新やサービス パックがインストールされた。 詳細については、そのソフトウェア更新またはサービス パックに関する指示をご覧ください。
Search Service アプリケーションの管理者またはサイト コレクションの管理者が、管理プロパティを追加または変更した。 新しい、または変更された管理プロパティを有効にするには、影響を受けるすべてのコンテンツ ソースのフル クロールが必要です。
前回ファイル共有がフル クロールされた後でそのファイル共有上のローカル グループに対して加えられた、セキュリティの変更を検出する。
増分クロールの連続的な失敗を解決する。 特定のコンテンツの増分クロールが連続して何回も失敗すると、影響を受けるコンテンツはシステムによって検索インデックスから除外されます。
クロール ルールが追加、削除、または変更された。
破損した検索インデックスを交換する。
既定のコンテンツ アクセス アカウントに割り当てられているユーザー アカウントのアクセス許可が変更された。
以下の場合、システムは、増分クロールまたは継続的クロールのスケジュールが設定されている場合でもフル クロールを行います。
検索管理者が前回のクロールを停止した。
コンテンツ データベースが修復された、またはファーム管理者がコンテンツ データベースを切断してから再接続した。
この Search Service アプリケーションからコンテンツ ソースのフル クロールが一度も実行されたことがない。
クロール データベースにクロール済みアドレスのエントリが含まれていない場合。 クロール済みのアイテムに関するエントリがクロール データベースに存在しないと、増分クロールは実行できません。
クロールするコンテンツの量を制限または増やす。
各コンテンツ ソースのプロパティで選択できるオプションは、選択したコンテンツ ソースの種類によって異なります。 クロール設定オプションを使用して、クロールするコンテンツの量を制限したり、増やしたりすることができます。 コンテンツ ソースごとに、開始アドレスをクロールするときの範囲を指定できます。 大部分のコンテンツ ソースでは、各開始アドレスから階層内のどのレベルの深さまでをクロールするかを指定できます。 この動作は、特定のコンテンツ ソースにあるすべての開始アドレスに適用されます。 一部のサイトをより深いレベルでクロールする必要がある場合、そのサイトを含んだ別のコンテンツ ソースを作成します。 次の表では、クロール設定オプションを構成するときのベスト プラクティスについて説明します。
| コンテンツ ソースの種類 | 条件 | 使用するクロール設定オプション |
|---|---|---|
| SharePoint サイト | サイト自体にあるコンテンツだけを対象とし、サブサイトにあるコンテンツは除外する場合。または、サブサイトにあるコンテンツを別のスケジュールでクロールする場合。 | 各開始アドレスから SharePoint サイトのみをクロールする。 |
| SharePoint サイト | サイト自体のコンテンツを対象とする場合。 または 同じスケジュールで開始アドレスの下にあるすべてのコンテンツをクロールする場合。 |
各開始アドレスから、ホスト名下にあるすべてをクロールする。 |
| Web サイト | リンク先のサイトで入手できるコンテンツに関連性がないと考えられる場合。 | 各開始アドレスのサーバー内のみをクロールする。 |
| Web サイト | 関連するコンテンツが最初のページにだけ配置されている場合。 | 各開始アドレスの最初のページのみをクロールする。 |
| Web サイト | 開始アドレスにあるリンクをクロールする深さを制限する場合。 | カスタム - ページの深さおよびサーバー ホップの数を指定。 注: 密接につながっているサイトの場合、小さい数から始めることをお勧めします。4 つ以上のページの深さまたはサーバー ホップを指定すると、インターネット全体がクロールされる可能性があります。 |
| ファイル共有 Exchange パブリック フォルダー |
サブフォルダーで入手できるコンテンツに関連性がないと考えられる場合。 | 各開始アドレスのフォルダーのみをクロールする。 |
| ファイル共有 Exchange パブリック フォルダー |
サブフォルダーのコンテンツに関連性があると考えられる場合。 | 各開始アドレスのフォルダーとすべてのサブフォルダーをクロールする。 |
| ビジネス データ | BDC Metadata Store に登録されているすべてのアプリケーションに関連するコンテンツが含まれている場合。 | BDC Metadata Store 全体をクロールする。 |
| ビジネス データ | BDC Metadata Store に登録されている一部のアプリケーションに関連するコンテンツが含まれている場合。 または 一部のアプリケーションを別のスケジュールでクロールるす場合。 |
選択したアプリケーションをクロールする。 |
コネクタを計画する
クローラーでは、コネクタ (以前のバージョンの SharePoint Server では、プロトコル ハンドラーと呼ぶ) を使ってコンテンツを取得し、インデックスを作成します。 最もよく使われるプロトコルの場合、SharePoint Server により適切なコネクタが提供され、自動的に使われます。 既定で提供されていないコネクタを必要とするコンテンツをクロールする場合は、サード パーティのコネクタをインストールするか、カスタム コネクタを作成する必要があります。 既定でインストールされるコネクタのリストについては、「Default connectors in SharePoint Server」をご覧ください (SharePoint Server にも適用されます)。
コンテンツ ソースを計画するときのその他の考慮事項
SharePoint サイトなど、同じ種類のコンテンツ リポジトリを使う場合、コンテンツ ソースを 1 つにするか複数にするかの判断は、管理上の考慮事項と大きく関係しています。 管理を簡単にするために、コンテンツ ソース、クロール ルール、およびクロール スケジュールを管理者が更新しやすい方法で、コンテンツ ソースを構成します。
同じ Search Service アプリケーションで複数のコンテンツ ソースを使用して同じ開始アドレスをクロールすることはできません。 たとえば、特定のコンテンツ ソースを使用してサイト コレクションとそのすべてのサブサイトをクロールする場合、別のコンテンツ ソースを使用して別のスケジュールでそのサブサイトのいずれかを個別にクロールすることはできません。
管理者は、コンテンツ ソースを頻繁に更新します。 コンテンツ ソースを変更するには、そのコンテンツ ソースのフル クロールが必要です。 したがって、コンテンツ ソースを個別に作成しておけば、必要に応じて複数のフル クロールを同時に実行でき、さらに特定のコンテンツ ソースのフル クロールを行う場合の所要時間が短くなります。
クロールを最適化するためのクロール ルールを計画する
クロール ルールは、Search Service アプリケーションのすべてのコンテンツ リソースに適用されます。 クロール ルールを特定の 1 つの URL または URL のセットに適用して、次の処理を実行できます。
1 つ以上の URL を除外して、無関係なコンテンツがクロールされないようにする。 これにより、サーバー リソースとネットワーク トラフィックの使用が低減します。
URL 自体をクロールしないで URL のリンクをクロールする。 このオプションは、サイトに関連するコンテンツのリンクがあり、そのリンクを含んでいるページには関連する情報がない場合に便利です。
複合 URL をクロールできるようにする。 このオプションを使用すると、疑問符を使用して指定されたクエリ パラメーターを含んでいる URL をクロールできます。 サイトによっては、これらの URL に関連するコンテンツがない可能性があります。 複合 URL によって無関係なサイトにリダイレクトされることが多いので、複合 URL から入手できるコンテンツに関連性があることがわかっているサイトに対してのみこのオプションを有効にすることをお勧めします。
SharePoint サイトのコンテンツを HTTP ページとしてクロールできるようにする。 このオプションを使用すると、検索システムは、ファイアウォールの内側にある SharePoint サイトをクロールしたり、クロールされるサイトがクローラー (検索トポロジのクロール コンポーネント) によって使用される Web サービスへのアクセスを制限したりするシナリオでクロールできます。
既定のコンテンツ アクセス アカウント、別のコンテンツ アクセス アカウント、クライアント証明書のうち、指定した URL のクロールに使用するものを指定する。
コンテンツのクロールではリソースと帯域幅が消費されるので、関連性のない可能性がある大量のコンテンツではなく、関連性があることがわかっている少量のコンテンツを対象とすることをお勧めします。 初期展開後、クエリとクロール ログを確認して、コンテンツ ソースとクロール ルールを調整して、関連性を向上し、対象のコンテンツを増やすことができます。
クローラーの認証を計画する
クローラーがコンテンツ ソースに指定されている開始アドレスにアクセスするとき、そのクローラーは、そのコンテンツをホストするサーバーの認証を受け、アクセスを許可される必要があります。 既定では、既定のコンテンツ アクセス アカウントが使用されます。 または、クロール ルールを使用して、特定のコンテンツをクロールするときに使用する別のコンテンツ アクセス アカウントを指定できます。 既定のコンテンツ アクセス アカウントを使用する場合でも、クロール ルールで指定した別のコンテンツ アクセス アカウントを使用する場合でも、使用するコンテンツ アクセス アカウントには、クロール対象のすべてのコンテンツに対する読み取りアクセス許可が必要です。 コンテンツ アクセス アカウントに読み取りアクセス許可がない場合は、コンテンツはクロールされず、インデックスも作成されないので、クエリに使用できません。
クロール対象コンテンツのほとんどにアクセスできるアカウントを既定のコンテンツ アクセス アカウントとして指定することをお勧めします。 セキュリティ上の理由から別のコンテンツ アクセス アカウントが必要な場合にだけ、それ以外のコンテンツ アクセス アカウントを使用します。
計画するコンテンツ ソースごとに、既定のコンテンツ アクセス アカウントではアクセスできない開始アドレスを特定し、その開始アドレスのクロール ルールを追加することを計画します。
重要
既定のコンテンツ アクセス アカウントまたはその他のコンテンツ アクセス アカウントに使用するドメイン アカウントは、クロールする Web アプリケーションに関連付けられているアプリケーション プールによって使用されるドメイン アカウントと同じにならないようにしてください。 同じドメイン アカウントを使用した場合、SharePoint サイトの非公開コンテンツおよび SharePoint サイトにあるファイルのマイナー バージョン (つまり、履歴) がクロールされ、そのインデックスが作成される可能性があります。
もう 1 つ重要な点は、クローラーはホスト サーバーと同じ認証プロトコルを使用する必要があるということです。 既定では、クローラーは NTLM を使用して認証を行います。 必要に応じて、別の認証プロトコルを使用するようにクローラーを構成できます。
クレーム ベース認証を使用している場合は、クロール対象のすべての Web アプリケーションで Windows 認証が有効になっていることを確認します。
コンテンツ処理を計画する
クローラーは、コンテンツ ソースで指定されたコンテンツ リポジトリをクロールし、クロールした項目のコンテンツやメタデータをコンテンツ処理コンポーネントに送り込みます。 コンテンツ処理コンポーネントは、クロールされたプロパティを読み込み、解析して、プロパティを検索管理データベースに報告します。
検索スキーマを編集すると、クロールされたプロパティを管理プロパティにマップし、プロパティ設定を構成できます。 コンテンツ処理コンポーネントは、この検索スキーマを読み込み、マップの実行に使用します。 検索インデックスには、管理プロパティのみが含まれます。 管理プロパティは、たとえば絞り込み条件の作成に使用できます。 詳細については、「SharePoint Server の検索スキーマの概要」をご覧ください。
ファイルの種類を含めるまたは除外する
検索インデックスには任意の種類のファイルのコンテンツを含めることができます。 しかし、コンテンツのインデックスを作成するには、まずコンテンツをクロール コンポーネントによってクロールしてから、コンテンツ処理コンポーネントによって解析する必要があります。 クロール コンポーネントによってクロールできるファイルは、ファイル名の拡張子が [ファイルの種類の管理] ページでファイル名拡張子の一覧に含まれているものだけです。 クロールされたファイルのコンテンツをコンテンツ処理コンポーネントが解析できるのは、以下の場合だけです。
コンテンツ処理コンポーネントにファイル形式を解析できる形式ハンドラーがある場合。
そのファイル形式とファイル名拡張子を備えたファイルの解析が有効になっている場合。
コンテンツ処理コンポーネントがファイルを解析できない場合は、検索インデックスにはファイル名などのファイルのプロパティだけが含まれます。
既定では、SharePoint Server は多くの種類のファイルについてこれらの条件を満たしており、追加の形式ハンドラーをインストールしなくてもそれらのファイルの種類をクロールおよび解析できます。 ファイルの種類の概要については、「Default crawled file name extensions and parsed file types in SharePoint Server」をご覧ください。
注:
SharePoint Server が解析できるファイル形式の初期コレクションは、iFilter と呼ばれるサードパーティ製のフィルター ベースの形式ハンドラーを追加することによって拡張できます。 サードパーティ製の iFilter は組み込みの形式ハンドラーをオーバーライドすることはできません。
[ファイルの種類の管理] ページに ない ファイルの種類のコンテンツ リポジトリからコンテンツを検索インデックスに含める予定の場合は、以下を確認してください。
ファイルの種類をクロールするには、そのファイルの種類を [ファイの種類の管理] ページに追加します。
ファイルの種類を解析するには:
その形式の形式ハンドラーが SharePoint Server にない場合は、Search Service アプリケーション内でコンテンツ処理コンポーネントをホストする各サーバーに、そのファイル形式のサードパーティ製のフィルター ベースの形式ハンドラーをインストールします。
Search Service アプリケーション内でコンテンツ処理コンポーネントをホストする各サーバーで、そのファイル形式およびファイル名拡張子の解析を有効にします。
詳細については、「Add or remove a file type from the search index in SharePoint Server」をご覧ください。
(カスタムの) エンティティ抽出機能の使用を計画する
本文のテキスト、ドキュメントのタイトルなどの非構造化コンテンツで "エンティティ" を検索するように検索システムを構成できます。 これらのエンティティは、製品名などの語や句です。 検索するエンティティを指定するために、独自の辞書を作成して展開できます。
抽出されたエンティティは、個別の管理プロパティとして検索インデックスに格納され、検索可能、クエリ可能、取得可能、並べ替え可能、絞り込み可能になるように自動的に構成されます。 検索の絞り込み条件でこれらのプロパティを使用して、たとえば、ユーザーによる検索結果のフィルター処理を支援できます。
企業の場合、SharePoint Server が提供する、あらかじめ作成された企業用の抽出辞書を使用できます。
さらに、カスタム エンティティ抽出ディクショナリの形式で、いくつかの種類のカスタム エンティティ抽出器をデプロイできます。 これらのディクショナリは、Microsoft PowerShell を使用してデプロイします。 これらの辞書のエントリ (1 つまたは複数の単語) は、大文字と小文字を区別または大文字と小文字を区別しない方法で、コンテンツ内の単語または単語の一部に一致します。 詳細については、「SharePoint Server でカスタム エンティティ抽出を作成および展開する」を参照してください。
| カスタムのエンティティ抽出/辞書 | 説明 |
|---|---|
| 完全一致抽出 | 大文字小文字が区別されない、最大 5 つの辞書です。 たとえば、エントリ "anchor" は "Anchor" に一致しますが "anchorage" には一致しません。 |
| 部分一致抽出 | 大文字小文字が区別されない、最大 5 つの辞書です。 たとえば、エントリ "anchor" は "anchor"、"Anchor" に一致し、"anchorage" の一部に一致します。 |
| 完全一致抽出 (大文字小文字区別) | 大文字小文字が区別され、最大 1 つの辞書です。 たとえば、エントリ "anchor" は "anchor" に一致しますが、"Anchor"、"Anchorage" には一致しません。 |
| 部分一致抽出 (大文字小文字区別) | 大文字小文字が区別され、最大 1 つの辞書です。 たとえば、エントリ "anchor" は "anchor" と "anchorage" の一部に一致しますが、"Anchor" には一致しません。 |
検索先とフェデレーションについて
SharePoint Server では、検索先を使用して、検索結果の取得先となるプロバイダーの URL、結果の取得に使用するためのプロトコル、および他の関連設定を指定します。 たとえば、事前構成された既定の検索先は [ ローカル SharePoint の結果] です。
検索結果の取得先となる外部検索プロバイダー (リモート検索エンジンやフィードなど) を指定する検索先を追加できます。 これは、フェデレーションと呼ばれます。
フェデレーションについて
フェデレーションを使用すると、ユーザーはローカル ファームのサーバーによってクロールされていないコンテンツを検索して取得できます。 たとえば、フェデレーションによって、Bing などの Web 検索プロバイダーからの検索結果を得ることができ、場合によってはクロールするアクセス権のない個人用データ セットからの検索結果も取得できます。
フェデレーションは、地理的に分散している組織が様々な場所のコンテンツへの検索アクセス権を提供しようとしている状況で、場所ごとに独自の検索インデックスがある場合にも優れたソリューションとなり得ます。 それぞれの場所は独自のインデックスに基づいて検索結果を提供するため、単一の統合されたインデックスをビルドしてアクセスする、集中管理型の検索サービスを展開する必要はありません。 これに関連し、フェデレーションにより以下のような利点がもたらされます。
低帯域幅要件 - 地理的に分散している組織では、大量のリモート コンテンツのクロールとインデックス作成に必要な高いネットワーク帯域幅がない可能性があります。 組織がフェデレーションを使用する場合、検索のためにワイド エリア ネットワークを介して転送されるメイン データは、フェデレーションされた各コンテンツ リポジトリーからの検索結果セットだけになります。
検索結果の鮮度 - 組織内の各部門は、一元化された検索展開で組織全体のすべてのコンテンツをクロールできるよりも、ローカル コンテンツをより迅速にクロールできます。
部門検索のばらつき - 組織がフェデレーションを使用する場合、組織内の各部門が独自の検索環境を提供および制御できます。 部門ごとに、それぞれのユーザー エクスペリエンスや検索コネクタを使用するなどして、独自の要件と設定に合わせて検索を調整できます。 集中管理型の検索ポータルではそのようなバリエーションを持たせることはできません。
検索インデックスのサイズが制限 されている - 地理的に分散された大規模な組織には、何百万ものドキュメントが含まれます。 組織が単一の統合された検索インデックスを持つのは、そうした大規模なインデックスをサポートするインフラストラクチャが必要になる可能性があるため、実際的ではありません。 フェデレーションを使用すると、各部門のユーザーは 1 回の検索実行により、組織内の小規模な複数の検索インデックス間に分散している関連コンテンツを検出できます。
フェデレーションでの検索先の使用
SharePoint Server でフェデレーションを使用するには、[検索先の追加] ページまたは [検索先の編集] ページにある [プロトコル] セクションで以下のいずれかのプロトコルを選択します。
| 選択するプロトコル | フェデレーションされた検索結果を取得する対象となるプロバイダー |
|---|---|
| リモートの SharePoint | 別の SharePoint Server ファームの検索サービスのインデックス |
| OpenSearch 1.0/1.1 | Bing など OpenSearch プロトコルを使用する外部検索エンジンまたはフィード |
| Exchange | Exchange Server 2013 |
注:
[検索先の追加] ページまたは [検索先の編集] ページで前述の表に示されているいずれかのプロトコルを選択する場合、対象ページで関連する他のフィールドも記入し、検索先を指定する必要があります。
関連項目
SharePoint Server の検索に関する結果ソースの概要
SharePoint Server の検索に関する結果ソースを構成する
Manage crawling in SharePoint Server
Default connectors in SharePoint Server