SharePoint Server でのクロールのベスト プラクティス
適用対象:
2016 2019 Subscription Edition 
SharePoint in Microsoft 365
SharePoint Server でのクロールのベスト プラクティスについて説明します。
検索システムは、コンテンツをクロールして、ユーザーが検索クエリに対して実行できる検索インデックスを作成します。 この記事には、クロールを最も効果的に管理する方法に関する提案が含まれています。
Microsoft 365 で SharePoint のクロールとインデックス再作成を手動で要求する方法について説明します。
既定のコンテンツ アクセス アカウントを使用してほとんどのコンテンツをクロールする
既定のコンテンツ アクセス アカウントは、クロールに既定で使用する SharePoint Server Search サービスに指定するドメイン アカウントです。 簡単にするため、このアカウントを使用して、できるだけ多くのコンテンツ (コンテンツ ソースによって指定) をクロールすることをお勧めします。 既定のコンテンツ アクセス アカウントを変更するには、「 SharePoint Server でクロールする既定のアカウントを変更する」を参照してください。
特定の URL をクロールするために既定のコンテンツ アクセス アカウントを使用できない場合 (たとえば、セキュリティ上の理由で)、クロール ルールを作成して、クローラーを認証するために以下のいずれかを代わりに指定します。
別のコンテンツ アクセス アカウント
クライアント証明書
フォームの資格情報
クロール用のクッキー
匿名アクセス
詳細については、「 SharePoint Server でのクロール ルールの管理」を参照してください。
コンテンツ ソースを効果的に使用する
コンテンツ ソースは、次の各コンポーネントを指定するために使用する Search サービス アプリケーションのオプションのセットです。
クロールする 1 つ以上の開始アドレス。
開始アドレス内のコンテンツの種類 (SharePoint Server サイト、ファイル共有、基幹業務データなど)。 コンテンツ ソースでクロールするコンテンツの種類を 1 つだけ指定できます。 たとえば、1 つのコンテンツ ソースを使用して SharePoint Server サイトをクロールし、別のコンテンツ ソースを使用してファイル共有をクロールします。
コンテンツ ソースが指定するすべてのコンテンツ リポジトリに適用されるフル クロールまたは増分クロールのクロール スケジュールとクロール優先度。
検索サービス アプリケーションを作成すると、検索システムは、 ローカルの SharePoint サイトという名前の 1 つのコンテンツ ソースを自動的に作成および構成します。 この構成済みのコンテンツ ソースは、ユーザー プロファイルをクロールしたり、Search サービス アプリケーションが関連付けられている Web アプリケーション内のすべての SharePoint Server サイトをクロールしたりするためのものです。 このコンテンツ ソースを使用して、SharePoint Server 2007 ファーム、SharePoint Server 2010 ファーム、SharePoint Server 2013 ファーム、その他の SharePoint Server ファームなど、他の SharePoint Server ファーム内のコンテンツをクロールすることもできます。
次のいずれかのタスクを実行する場合は、追加のコンテンツ ソースを作成します。
その他の種類のコンテンツをクロールする
クロールするコンテンツの量を制限または増加する
特定のコンテンツをより多くまたは少なくクロールする
特定のコンテンツをクロールするための異なる優先順位を設定します (この要件は、完全クロールと増分クロールには適用されますが、継続的クロールには適用されません)。
さまざまなスケジュールで特定のコンテンツをクロールする (この要件はフル クロールと増分クロールには適用されますが、継続的クロールには適用されません)
ただし、管理をできるだけ簡単にするために、作成および使用するコンテンツ ソースの数を制限することをお勧めします。
コンテンツ ソースを使用してクロールをスケジュールする
構成済みのコンテンツ ソース のローカル SharePoint サイト を編集して、クロール スケジュールを指定できます。既定ではクロール スケジュールは指定されません。 コンテンツ ソースの場合は、クロールを手動で開始できますが、増分クロールをスケジュールするか、コンテンツが定期的にクロールされるように継続的クロールを有効にすることをお勧めします。
以下のような理由で異なるスケジュールでコンテンツをクロールする場合、別のコンテンツ ソースを使用することを検討してください。
サーバーのダウン タイムとサーバー使用率のピーク時に対応するため。
高速サーバーにホストされているコンテンツとは別に、低速サーバーにホストされているコンテンツをクロールするため。
より頻繁に更新されるコンテンツのクロール頻度を上げるため。
コンテンツをクロールすると、コンテンツをホストするサーバーのパフォーマンスを低下させる場合があります。 この影響は、ホスト サーバーに負荷を処理するための十分なリソース (特に CPU と RAM) があるかどうかによって異なります。 そのため、クロールのスケジュールを計画するときに、以下のベスト プラクティスを考慮してください。
コンテンツをホストするサーバーが使用可能なとき、またサーバー リソースの需要が低いときに、各コンテンツ ソースのクロールをスケジュールします。
クロール サーバーとホスト サーバーの負荷が時間的に分散されるようにクロール スケジュールをずらします。 クロール ログを確認することにより、各コンテンツ ソースの標準的なクロールにかかる時間を理解するにつれて、この方法でクロール スケジュールを最適化できるようになります。 詳細については、「SharePoint Server で検索診断を表示する」の「クロール ログ」を参照してください。
必要な場合にのみ、フル クロールを実行します。 詳細については、「SharePoint Server でのクロールとフェデレーションの計画」でフル クロールを実行する理由に関するページを参照してください。 クロール ルールの作成など、フル クロールを有効にする必要がある管理上の変更については、次のフル クロールの直前に変更を実行して、余分なフル クロールが不要になるようにします。 詳細については、「 SharePoint Server でのクロール ルールの管理」を参照してください。
SharePoint Server サイトをクロールする前にユーザー プロファイルをクロールする
既定では、ファームにおける最初の検索サービス アプリケーションで、事前構成されたコンテンツ ソースである ローカルの SharePoint サイトには、少なくとも以下の 2 つの開始アドレスが含まれます。
https://webAppUrlは、既存の Web アプリケーションに対して指定された既定のゾーン URL をクロールするためのです。sps3s://myWebAppUrlは、ユーザー プロファイルのクロール用です。
ただし、"People Search" をデプロイする場合は、スタート アドレス sps3s://myWebAppUrl 用に別のコンテンツ ソースを作成し、そのコンテンツ ソースのクロールを最初に実行することをお勧めします。 クロール実行の理由は、クロールが完了すると、検索システムによってリストが生成され、ユーザーの名前が標準化されるためです。 そのため、1 つの検索結果セットでユーザーの名前のフォームが異なる場合、そのユーザーのすべての結果が 1 つのグループ ( 結果ブロックと呼ばれます) に表示されます。 たとえば、検索クエリ "Anne Weiler" では、Anne Weiler または A によって作成されたすべてのドキュメントが表示されます。Weiler またはエイリアス AnneW は、"Documents by Anne Weiler" というラベルの付いた結果ブロックに表示できます。 同様に、これらの ID によって作成されたすべてのドキュメントは、"Author" がカテゴリの 1 つである場合、絞り込みパネルの見出し "Anne Weiler" の下に表示できます。
ユーザー プロファイルをクロールし、SharePoint Server サイトをクロールするには
この手順を実行するユーザー アカウントが、構成する Search Service アプリケーションの管理者であることを確認します。
「SharePoint Server でユーザー検索を展開する」の手順に従います。 これらの手順の一環として、次のタスクを実行します。
Create a content source that is only for crawling user profiles (the profile store). You might give that content source a name such as People. 新しいコンテンツ ソースの [ スタート アドレス] セクションに「
sps3s:// myWebAppUrl」と入力します。ここで、myWebAppUrlは個人用サイト ホストの URL です。作成した People コンテンツ ソースのクロールを開始します。
構成済みのコンテンツ ソースのローカル SharePoint サイトから開始アドレス
sps3s://myWebAppUrlを削除します。
「人」コンテンツ ソースのクロールが終了した後、約 2 時間待機します。
コンテンツ ソース 「 ローカルの SharePoint サイト」の最初のフル クロールを開始します。
継続的クロールを使用して検索結果が最新であることを確認する
[継続的クロールを有効にする ] は、 SharePoint サイトの種類のコンテンツ ソースを追加または編集するときに選択できるクロール スケジュール オプションです。 継続的クロールは、前回のクロール以降に追加、変更、または削除されたコンテンツをクロールします。 継続的クロールは、定義済みの時間間隔で開始されます。 既定の間隔は 15 分ごとにですが、Microsoft PowerShell を使用して、継続的クロールをより短い間隔で実行するように設定できます。 継続的クロールは頻繁に行われるため、頻繁に更新される SharePoint Server コンテンツの場合でも、検索インデックスの鮮度を確保するのに役立ちます。 また、増分クロールまたはフル クロールは、特定のアイテムに対してエラーを返す複数のクロール試行によって遅延されますが、継続的クロールでは、エラーを繰り返し返し返すアイテムが処理または再試行されないため、他のコンテンツをクロールし、インデックスの鮮度に影響する可能性があります。 このようなエラーは、継続的クロールが有効になっているコンテンツ ソースに対して 4 時間ごとに自動的に実行される "クリーンアップ" 増分クロール中に再試行されます。 増分クロール中にエラーが返され続けるアイテムは、今後の増分クロール中に再試行されますが、エラーが解決されるまで、継続的クロールによって取得されることはありません。
1 つの継続的クロールには、継続的クロールが有効にされている検索サービス アプリケーションのすべてのコンテンツ ソースが含まれます。 同様に、継続的クロールの間隔は、継続的クロールが有効にされている検索サービス アプリケーションのすべてのコンテンツ ソースに適用されます。 詳細については、「Manage continuous crawls in SharePoint Server」を参照してください。
継続的クロールは、クローラーおよびクロール ターゲットで負荷を高めます。 このリソース消費量の増加に応じて計画およびスケール アウトしていることを確認してください。 大きなコンテンツ ソースで継続的クロールを有効にする場合、それぞれに対して 1 つ以上のフロントエンド サーバーをクロールの専用ターゲットとして構成することをお勧めします。 詳細については、「クロールの負荷を管理する (SharePoint Server 2010)」を参照してください。
クロール ルールを使用して不適切なコンテンツをクロール対象から除外する
クロールの実行は、リソースと帯域幅を消費するため、初期展開の間、関連がないものも含まれる大きなコンテンツのクロールを実行する代わりに、関連があると分かっている少量のコンテンツをクロールした方が良い場合があります。 クロールするコンテンツの量を制限するため、以下の理由でクロール ルールを作成できます。
1 つ以上の URL を除外して、無関係なコンテンツがクロールされないようにするため。
URL 自体をクロールしないで URL のリンクをクロールするため。 この配置は、関連するコンテンツが含まれていないが、関連するコンテンツへのリンクがあるサイトに役立ちます。
既定では、クローラーは複雑な URL に従いません。これは疑問符を含む URL に続けて追加のパラメーターが続きます。たとえば、 http://contoso/page.aspx?x=y. クローラーが複雑な URL に従えるようにした場合、この配置により、クローラーは予想以上に多くの URL を収集する可能性があります。 この過剰な同化により、クローラーは不要なリンクを収集し、クロール データベースに冗長リンクを入力し、インデックスが大きくなる可能性があります。
これらの対策は、サーバー リソースとネットワーク トラフィックの使用を減らすのに役立ち、検索結果の関連性を高めることができます。 最初のデプロイ後、クエリとクロール ログを確認し、必要に応じてコンテンツ ソースとクロール ルールを調整して、より多くのコンテンツを含めることができます。 詳細については、「 SharePoint Server でのクロール ルールの管理」を参照してください。
SharePoint Server Web アプリケーションの既定のゾーンをクロールする
SharePoint Server Web アプリケーションの既定のゾーンをクロールすると、クエリ プロセッサは自動的にマップされ、クエリが実行される代替アクセス マッピング (AAM) ゾーンを基準にした検索結果 URL が返されます。 この設定により、ユーザーは検索結果を簡単に表示して開くようになります。
ただし、既定ゾーン以外の Web アプリケーションのゾーンをクロールする場合、クエリ プロセッサは、クエリが実行される AAM ゾーンに関連付けられるように検索結果の URL をマップしません。 代わりに、検索結果の URL は、クロールされた既定以外のゾーンを基準とします。 この設定により、ユーザーは検索結果をすぐに表示または開けることができない場合があります。
たとえば、WebApp1 という名前の Web アプリケーションに次の AAM があるとします。
| 既定値 | パブリック URL | 認証プロバイダー |
|---|---|---|
| 既定値 | https://contoso |
Windows 認証: NTLM |
| エクストラネット | https://fabrikam |
フォーム ベース認証 |
| イントラネット | http://fabrikam |
Windows 認証: NTLM |
次に、既定のゾーン https://contosoクロールするとします。 ユーザーが https://contoso/searchresults.aspxからクエリを実行すると、WebApp1 からの結果の URL はすべて https://contosoを基準とするため、 https://contoso/ _path_/ _result_.aspx形式になります。
同様に、クエリがエクストラネット ゾーンから発信される場合(この場合、WebApp1 からの https://fabrikam/searchresults.aspx—results はすべて https://fabrikamを基準とするため、 https://fabrikam/ _path_/ _result_.aspx形式になります。
上記の両方の場合、クエリの場所と検索結果の URL 間のゾーンの整合性のため、ユーザーは、別のゾーンの異なるセキュリティ コンテキストに変更する必要なしに、簡単に検索結果を表示したり開いたりできます。
ただし、代わりに、イントラネット ゾーンなどの既定以外のゾーンをクロールすると http://fabrikam。 この場合、任意のゾーンからのクエリの場合、WebApp1 からの結果の URL は、クロールされた既定以外のゾーンに対して常に相対的になります。 つまり、 https://contoso/searchresults.aspx、 https://fabrikam/searchresults.aspx、または http://fabrikam/searchresults.aspx からのクエリでは、クロールされた既定以外のゾーンで始まる検索結果 URL が生成されるため、http://fabrikam/ _path_/ _result_.aspx という形式になります。 この設定により、次のような予期しない動作や問題のある動作が発生する可能性があります。
ユーザーが検索結果を開こうとすると、そのユーザーにはない資格情報を求めるプロンプトが表示される場合があります。 たとえば、エクストラネット ゾーンでフォーム ベース認証されたユーザーには、Windows 認証の資格情報がない場合があります。
WebApp1 からの結果は HTTP を使用しますが、ユーザーはエクストラネット ゾーンから
https://fabrikam/searchresults.aspxで検索する場合があります。 このユーザーによる検索操作は、結果でセキュリティで保護されたソケット 層 (SSL) 暗号化を使用しないため、セキュリティに影響を与える可能性があります。絞り込み条件が、クロールした URL ではなく既定ゾーンのパブリック URL をフィルター処理するため、その条件が正しく機能しない場合があります。 この不適切なフィルター処理は、インデックス内の URL ベースのプロパティが、クロールされた既定以外の URL を基準とするためです。
SharePoint Server クロール ターゲットに対するクロールの影響を減らす
次のタスクを実行すると、SharePoint Server クロール ターゲット (つまり、SharePoint Server フロントエンド Web サーバー) に対するクロールの影響を軽減できます。
小規模な SharePoint Server 環境の場合は、すべてのクロール トラフィックを 1 つの SharePoint Server フロントエンド Web サーバーにリダイレクトします。 大規模な環境では、フロント エンド Web サーバーの特定のグループにすべてのクロール トラフィックをリダイレクトします。 クロール リダイレクトのこのパターンにより、クローラは、Web ページとコンテンツをアクティブ ユーザーにレンダリングして提供するために使用されているのと同じリソースを使用できなくなります。
Microsoft SQL Server での検索データベースの使用を制限することにより、クローラーがクロール中に SQL Server の共有ディスクおよびプロセッサ リソースを使用しないようにできます。
詳細については、「クロールの負荷を管理する (SharePoint Server 2010)」を参照してください。
クローラーの影響ルールを使用してクロールの影響を制限する
クローラーの影響を制限するために、[Search_service_application_name: 検索管理] ページから使用できる、クローラーの影響ルールを作成することもできます。 クローラーの影響ルールは、クローラーが開始アドレスからコンテンツを要求する頻度、または開始アドレスの範囲を指定します。 特に、クローラーの影響ルールは、要求と要求の間で待機することなく URL から一度に指定したドキュメント数を要求するか、または URL から一度に 1 つのドキュメントを要求して、要求と要求の間で指定した時間を待機します。 各クローラーの影響ルールは、すべてのクロール コンポーネントに適用されます。
組織内のサーバーに対して、既知のサーバーのパフォーマンスと容量に基づいてクローラーの影響ルールを設定できます。 ただし、外部サイトではこの設定ができない場合があります。 そのため、多すぎる量のコンテンツを要求することにより、または多すぎる頻度でコンテンツを要求することにより、外部サーバーに対してリソースを意図せずに過度に使用してしまう場合があります。 このコンテンツの使用率が高い場合、外部サーバーの管理者は、それらのリポジトリをクロールすることが困難または不可能になるように、サーバー アクセスを制限する可能性があります。 そのため、インデックスの鮮度が要件を満たしていることを確認するために十分な頻度で十分なコンテンツをクロールしながら、クローラーの影響ルールを外部サーバーにできるだけ影響を与えないように設定します。
アクセス許可に対して個々のユーザーではなく Active Directory グループを使用する
ユーザーまたはグループがサイトでさまざまなアクティビティを実行する機能は、割り当てるアクセス許可レベルによって決まります。 サイトのアクセス許可に対してユーザーを個別に追加または削除する場合、または SharePoint Server グループを使用してサイトのアクセス許可を指定し、グループのメンバーシップを変更する場合、クローラーは "セキュリティ専用クロール" を実行する必要があります。これにより、検索インデックス内のすべての影響を受ける項目が更新され、変更が反映されます。 同様に、別のユーザーまたは SharePoint Server グループで Web アプリケーション ポリシーを追加または更新すると、そのポリシーの対象となるすべてのコンテンツのクロールがトリガーされます。 これによりクロールの負荷が増加し、検索結果の鮮度が低下する可能性があります。 そのため、サイトのアクセス許可を指定するには、Active Directory Domain Services (AD DS) グループを使用することをお勧めします。これらのグループでは、検索インデックス内の影響を受ける項目をクローラーが更新する必要がないためです。
2 番目のクロール コンポーネントを追加してフォールト トレランスを提供する
Search サービス アプリケーションを作成すると、既定の検索トポロジには 1 つのクロール コンポーネントが含まれます。 クロール コンポーネントは、コンテンツ リポジトリからアイテムを取得し、クロール コンポーネントをホストするサーバーにアイテムをダウンロードし、アイテムと関連するメタデータをコンテンツ処理コンポーネントに渡し、関連するクロール データベースにクロール関連の情報を追加します。 フォールト トレランスを提供する 2 つ目のクロール コンポーネントを追加できます。 1 つのクロール コンポーネントが使用できなくなった場合、残りのクロール コンポーネントはすべてのクロールを引き継ぐことになります。 ほとんどの SharePoint Server ファームでは、合計 2 つのクロール コンポーネントで十分です。
詳細については、次の記事を参照してください。
環境リソースを管理してクロールのパフォーマンスを向上させる
クローラーがコンテンツをクロールし、コンテンツをクロール サーバー (クロール コンポーネントをホストするサーバー) にダウンロードして、コンテンツをコンテンツ処理コンポーネントにフィードする際に、いくつかの要因がパフォーマンスに悪影響を及ぼす場合があります。 クロールのパフォーマンスを向上させるには、次のタスクを実行します。
| 次の潜在的なパフォーマンスのボトルネックに対処するには | 以下のソリューションを実装します |
|---|---|
| クロールされるサーバーからの応答時間が遅い | 追加の CPU と RAM、およびより高速のディスク I/O を提供します |
| 低いネットワーク帯域幅 | 各クロール サーバーに 1 つまたは 2 つの 1 ギガビット/秒のネットワーク アダプターをインストールする |
| コンテンツ処理 | 追加のコンテンツ処理コンポーネントを提供し、各コンテンツ処理コンポーネントに追加 CPU リソースを提供します |
| インデックス コンポーネントによる処理の低下 | インデックス コンポーネントをホストするサーバーに I/O リソースを追加します |
詳細については、次のリソースを参照してください。
検索トポロジを変更する前にアクティブなクロールがないことを確認する
検索トポロジへの変更を開始する前に、進行中のクロールがないことを確認するようにお勧めします。 進行中のクロールが存在すると、トポロジの変更を順調に実行できない可能性があります。
必要に応じて、フル クロールまたは増分クロールを手動で一時停止または停止し、継続的クロールを無効にすることができます。 詳細については、次の記事を参照してください。
注:
クロールを一時停止すると、クロール コンポーネントへの参照が検索管理データベースの MSSCrawlComponentsState テーブルに残ってしまうという欠点があります。 This can cause a problem if you want to remove any crawl components (say, because you want to remove a server that hosts those components from the farm). ただし、クロールを停止すると、 MSSCrawlComponentsState テーブル内のクロール コンポーネントへの参照が削除されます。 Therefore, if you want to remove crawl components, it is better to stop crawls than to pause crawls.
クロールが進行中でないことを確認するには、[ _Search_service_application_name_: Manage Content Sources ] ページで、各コンテンツ ソースの [状態] フィールドの値が [アイドル] または [ 一時停止] になっていることを確認します。 (When a crawl is completed, or when you stop a crawl, the value in the Status field for the content source will change to Idle.)
ファームからホストを削除する前にクロール コンポーネントをクロール ホストから削除する
サーバーがクロール コンポーネントをホストしている場合、ファームからそのサーバーを削除すると、検索システムがコンテンツをクロールできなくしてしまう場合があります。 そのため、ファームからクロール ホストを削除する前に、次のタスクを実行することを強くお勧めします。
アクティブなクロールがないことを確認します。
詳細については、前のセクション「検索トポロジを変更する前にアクティブなクロールがないことを確認する」を参照してください。
そのホストにあるクロール コンポーネントを削除または移動します。
詳細については、次のリソースを参照してください。
SharePoint Server で検索コンポーネントを管理するで検索コンポーネントを削除するか、検索コンポーネントを移動する
クロール構成を変更した後、または更新プログラムを適用した後に、クロールおよびクエリの機能をテストする
構成を変更した後、または更新プログラムを適用した後に、サーバー ファームでクロールおよびクエリの機能をテストすることをお勧めします。 以下の手順は、そのようなテストを実行する簡単な方法の例です。
クロールとクエリ機能をテストするには
この手順を実行するユーザー アカウントが、構成する Search Service アプリケーションの管理者であることを確認します。
このテストのために一時的に使用するコンテンツ ソースを作成します。
新しいコンテンツ ソースの [ 開始アドレス] セクションにある [ 以下に開始アドレスを入力してください (1 行に 1 アドレス)] ボックスで、インデックスに存在しないいくつかのアイテム (たとえば、ファイル共有に存在するいくつかの TXT ファイル) を含む開始アドレスを指定します。 詳細については、「 SharePoint Server でコンテンツ ソースを追加、編集、または削除する」を参照してください。
そのコンテンツ ソースのフル クロールを開始します。
詳細については、「Start, pause, resume, or stop a crawl in SharePoint Server」を参照してください。 クロールが完了すると、[
_Search_service_application_name_: Manage Content Sources] ページで、コンテンツ ソースの [状態] 列の値が [アイドル] になります。 ( [状態 ] 列を更新するには、[更新] をクリックして [コンテンツ ソースの管理] ページを 更新します)。クロールが完了したら、検索センターに移動し、それらのファイルを検索する検索クエリを実行します。
展開に検索センターがまだない場合は、「 SharePoint Server で検索センター サイトを作成する」を参照してください。
テストが完了したら、一時的なコンテンツ ソースを削除します。
この操作により、テストが完了した後に検索結果に表示されないように、そのコンテンツ ソースで指定された項目が検索インデックスから削除されます。
クロール ログとクロール正常性レポートを使用して問題を診断する
クロール ログは、クロールされたコンテンツの状態に関する情報を追跡します。 このログには、コンテンツ ソース、ホスト、エラー、データベース、URL、および履歴のビューが含まれます。 たとえば、このログを使用して、コンテンツ ソースの最後に正常に実行されたクロールの時間、クロールされたコンテンツが正常にインデックスに追加されたかどうか、クロール ルールのために除外されたかどうか、またはエラーのためにクロールが失敗したかどうかを判別できます。
クロール正常性レポートによって、クロールの頻度、クロールの待機時間、クロールの最新状態、コンテンツの処理、CPU とメモリの負荷、継続的クロール、およびクロール キューに関する詳細情報が提供されます。
クロール ログおよびクロール正常性レポートを使用して、検索機能に関する問題を診断できます。 診断情報から、それらがコンテンツ ソース、クロール ルール、クローラーの影響ルール、クロール コンポーネント、クロール データベースなどの要素を調整するのに役立つかどうかを判断できます。
詳細については、「 SharePoint Server で検索診断を表示する」を参照してください。