コンテンツをクロールするための計画を立てる (Search Server 2008)

更新日: 2008年9月

適用対象: Microsoft Search Server 2008

 

トピックの最終更新日: 2015-03-09

この記事の内容 :

• コンテンツのクロールとインデックス作成について

• クロールするコンテンツのソースを指定する

• コンテンツ ソースを計画する

• 認証を計画する

• プロトコル ハンドラを計画する

• クロールの影響の管理を計画する

• クロール ルールを計画する

• ファーム レベルで管理される検索設定を計画する

• さまざまな言語でコンテンツのインデックスを作成する

この記事は、Microsoft Search Server 2008 がどのようにコンテンツのクロールとインデックス作成を行うかを説明することによって、検索サービスの管理者による、コンテンツのクロールの計画を支援することを目的としています。詳細については、「検索サービス管理者を追加または削除する (Search Server 2008)」を参照してください。

エンド ユーザーが Search Server 2008 のエンタープライズ検索機能の利点を活用できるようになるには、クエリの対象となるコンテンツが事前にクロールされる必要があります。

この記事の目的に沿うために、コンテンツは、Web ページ、Microsoft Office Word 文書、ビジネス データ、電子メールのメッセージ ファイルなど、クロール可能なアイテムとします。

コンテンツのクロールを計画する際は、次の点を考慮する必要があります。

• コンテンツが物理的に存在している場所。

• コンテンツの一部が種類の異なるソース (ファイル共有、SharePoint サイト、Web サイトなど) に格納されているかどうか。

• ソースに格納されているすべてのコンテンツをクロールするか、一部のみをクロールするか。

• クロールするコンテンツを構成するファイルの種類。

• コンテンツをクロールする時期と頻度。

• コンテンツのセキュリティ保護の方法。

この記事の情報を、以上の項目の確認と、クロールするコンテンツの選択、そのコンテンツのクロールを実行する方法および時期の計画の策定に活用してください。

コンテンツのクロールとインデックス作成について

コンテンツのクロールとインデックス作成は、システムがコンテンツとそのプロパティ (メタデータとも呼ばれます) にアクセスして解析し、検索クエリ サービスの実行に使用されるコンテンツ インデックスを構築するプロセスです。

コンテンツのクロールが正常に実行されると、個々のファイル、またはコンテンツの内容が、クローラによりアクセスされ、読み取られます。これらのファイルのキーワードとメタデータは、コンテンツ インデックス (単にインデックスとも呼ばれます) に保存されます。インデックスは、インデックス サーバーのファイル システムに保存されるキーワードと、検索データベースに保存されるメタデータで構成されます。キーワード、メタデータ、およびコンテンツがクロールされたソースの URL について、それらの間のマッピングがシステムにより維持されます。

検索サービスには、共有サービス プロバイダ (SSP) が関連付けられ、コンテンツのインデックスを作成するための特定のサーバーが割り当てられます。2007 Office リリースのサーバー製品では、SSP を複数使用できるため、コンテンツ インデックスを複数使用できますが、それとは異なり、Search Server 2008 では SSP が 1 つに制限されているため、使用できるコンテンツ インデックスは 1 つのみです。

クロールするコンテンツのソースを指定する

組織のサーバー ファーム内の SharePoint サイトにある全コンテンツをクロールすることのみが求められる場合がよくあります。その場合、サーバー ファーム内のサイト コレクションはすべて既定のコンテンツ ソースを使用してクロールできるため、クロール対象のコンテンツ ソースを指定する必要がなくなります。既定のコンテンツ ソースの詳細については、この記事の「コンテンツ ソースを計画する」を参照してください。

また、ファイル共有、インターネット上の Web サイトなど、サーバー ファーム外のコンテンツをクロールすることが求められる場合もよくあります。Search Server 2008 では、他の Windows SharePoint Services ファーム、Web サイト、ファイル共有、Microsoft Exchange パブリック フォルダ、および IBM Lotus Notes サーバーでホスティングされているコンテンツについて、クロールとインデックス作成を実行できます。このため、検索クエリで利用できるコンテンツの量が大幅に増加します。

ただし、一部のサイト コレクションに保存されているコンテンツが検索結果に対応しない場合があるため、サーバー ファーム内のすべてのサイト コレクションをクロールすることは基本的に避けてください。その場合、次のどちらかまたは両方の操作を行う必要があります。

• クロールする必要のないサイト コレクションの URL を書き留めておきます。既定のコンテンツ ソースを使用する場合、クロールしないサイト コレクションの開始アドレスが既定のコンテンツ ソースに含まれていないことを確認する必要があります。

• クロールする必要のないサイト コレクションの個別の開始アドレスを書き留めておきます。新しいコンテンツ ソースを作成してこのコンテンツのクロールに使用する場合、その開始アドレスを調べておく必要があります。どのような場合にコンテンツ ソースを使用するのかの詳細については、この記事の「コンテンツ ソースを計画する」を参照してください。

コンテンツ ソースを計画する

コンテンツをクロールするには、コンテンツが置かれている場所と、コンテンツがホスティングされているサーバーの種類を調べる必要があります。これらの情報を収集した後で、検索サービスの管理者はコンテンツ ソースを 1 つ以上作成できます。これらのコンテンツ ソースからクローラに、次の情報が提供されます。

• クロールするコンテンツの種類。たとえば、SharePoint サイトやファイル共有。

• クロールを開始する開始アドレス。

• クロール時に使用される動作の種類。たとえば、開始アドレスからのクロールの深さや、許容されるサーバー ホップ数。

• クロールの頻度。

このセクションでは、組織で必要なコンテンツ ソースの計画に役立つ内容を説明します。

既定のコンテンツ ソースは、"ローカルの Office SharePoint Server サイト" と呼ばれます。検索サービスの管理者は、このコンテンツ ソースを使用して、サーバー ファーム内のすべてのコンテンツをクロールし、インデックスを作成できます。既定では、Search Server 2008 によって、ファーム内の各サイト コレクションのトップレベル サイトの開始アドレス (この場合は URL) が既定のコンテンツ ソースに追加されます。

組織によっては、既定のコンテンツ ソースを使用してサイト コレクションの全サイトをクロールするだけで検索の要件が満たされる場合もあります。しかし、多くの場合、コンテンツ ソースを追加する必要があります。

追加のコンテンツ ソースを作成する理由としては、次のようなものがあります。

• 異なる種類のコンテンツをクロールする必要がある。

• 他のコンテンツとは異なるスケジュールで一部のコンテンツをクロールする必要がある。

• クロールするコンテンツの量を限定または増大する必要がある。

検索サービスの管理者は最大 500 個のコンテンツ ソースを作成でき、各コンテンツ ソースには最大 500 個の開始アドレスを含めることができます。管理をできるだけ簡単にするため、作成するコンテンツ ソースの数を必要最小限にしてください。

さまざまな種類のコンテンツをクロールする

クロールできるのは、コンテンツ ソースごとに 1 種類のみです。つまり、SharePoint サイトの URL を含むコンテンツ ソースと、ファイル共有の URL を含む別のコンテンツ ソースを作成できますが、SharePoint サイトとファイル共有の両方の URL を含む単一のコンテンツ ソースを作成することはできません。次の表に、構成できるコンテンツ ソースの種類を示します。

コンテンツ ソースの種類	含まれるコンテンツの種類
SharePoint サイト	同じファームの SharePoint サイト、または別の Office SharePoint Server 2007 ファーム、Windows SharePoint Services 3.0 ファーム、あるいは Search Server 2008 ファームの SharePoint サイト Microsoft Office SharePoint Portal Server 2003 または Windows SharePoint Services 2.0 の SharePoint サイト 注意 Office SharePoint Server 2007、Windows SharePoint Services 3.0、または Search Server 2008 上の SharePoint サイトをクロールする場合と異なり、古いバージョンの SharePoint 製品とテクノロジからサイト コレクションのすべてのサブサイトを自動的にクロールすることはできません。したがって、古いバージョンから SharePoint サイトをクロールする場合、クロールする各トップレベル サイトおよび各サブサイトの URL を指定する必要があります。 Microsoft Office SharePoint Portal Server 2003 ファームのサイト ディレクトリで指定されたサイトは、ポータル サイトのクロール時にクロールされます。サイト ディレクトリの詳細については、「About the Site Directory (英語)」(https://go.microsoft.com/fwlink/?linkid=88227&clcid=0x411) を参照してください。
Web サイト	SharePoint サイトにはない組織内の他の Web コンテンツ インターネット上の Web サイトのコンテンツ
ファイル共有	組織内のファイル共有のコンテンツ
Lotus Notes	Lotus Notes データベースに保存されている電子メール メッセージ 注意 他の種類のコンテンツ ソースとは異なり、適切な前提ソフトウェアがインストールされて構成されるまで、[Lotus Notes] コンテンツ ソース オプションはユーザー インターフェイスに表示されません。詳細については、「Lotus Notes のクロール用に検索サーバーを構成する (Search Server 2008)」を参照してください。
Exchange パブリック フォルダ	Exchange Server コンテンツ

異なるスケジュールでコンテンツをクロールする

検索サービスの管理者は、多くの場合、一部のコンテンツを他のコンテンツよりも頻繁にクロールするかどうかを判断する必要があります。クロールするコンテンツのボリュームが増えれば増えるほど、異なるソースからコンテンツをクロールする可能性が高くなります。これらのソースは種類が同じ場合もあれば異なる場合もあり、それぞれ処理速度が異なるサーバーでホスティングされている可能性があります。

このような要因から、新しいコンテンツ ソースを追加して、さまざまなコンテンツ ソースを別々にクロールする必要性が高くなります。

主に次の理由で、コンテンツを異なるスケジュールでクロールします。

• ダウンタイムやピーク使用時間に対応するため。

• 頻繁に更新されるコンテンツのクロール頻度を高めるため。

• 処理の速いホスト サーバーでクロールするコンテンツとは別に、処理の遅いホスト サーバーでホスティングされているコンテンツをクロールするため。

多くの場合、Search Server 2008 を展開して一定の期間運用した後でなければ、こうした情報をすべて判断することはできません。これらの判断の一部は、計画時ではなく、運用フェーズで行われます。ただし、計画時にこれらの要因を考慮し、把握している情報に基づいてクロール スケジュールを計画できるようにすることをお勧めします。

以下の 2 つのセクションでは、異なるスケジュールで行うコンテンツのクロールについて詳しく説明します。

ダウンタイムとピーク使用時間

クロール対象のコンテンツをホストするサーバーのダウンタイムとピーク使用時間を考慮します。たとえば、サーバー ファームの外部にあり、多数のサーバーでホストされているコンテンツをクロールする場合、サーバーごとのバックアップ スケジュールが異なり、ピーク使用時間もそれぞれ異なることが考えられます。一般に、サーバー ファーム外部のサーバーの管理は制御できません。そのため、クロール対象のコンテンツをホストするサーバーの管理者とクロールについて調整し、ダウンタイムまたはピーク使用時にサーバー上のコンテンツをクロールしないようにする必要があります。

一般的なシナリオとして、組織の管理下にないコンテンツが、SharePoint サイト上のコンテンツに関連している場合があります。そのような場合、コンテンツの開始アドレスを既存のコンテンツ ソースに追加することも、外部コンテンツ用の新しいコンテンツ ソースを作成することもできます。外部サイトの可用性は変動が大きいため、外部コンテンツごとに個別のコンテンツ ソースを追加すると便利です。そうすることで、他のコンテンツ ソースとは異なる時間に外部コンテンツのコンテンツ ソースをクロールできます。各サイトの可用性に合ったクロール スケジュールに基づいて、外部コンテンツを更新できます。

頻繁に更新されるコンテンツ

クロール スケジュールを計画する際には、一般的に、コンテンツの一部のソースが他よりも頻繁に更新されることを考慮します。たとえば、一部のサイト コレクションや外部ソースのコンテンツが金曜日にしか更新されないことがわかれば、週 1 回よりも頻繁にコンテンツをクロールすることはリソースの無駄遣いになります。一方、月曜日から金曜日まで継続的に更新され、土曜日と日曜日には通常更新されないサイト コレクションがサーバー ファームに含まれているとします。この場合、平日の各曜日は数回クロールし、週末には 1 ～ 2 回のみクロールすることが考えられます。

環境内のサイト コレクションにコンテンツが保存される方法に従って、各 Web アプリケーションの各サイト コレクションに対応する追加のコンテンツ ソースを作成できます。たとえば、サイト コレクションにアーカイブ済み情報のみが保存される場合、頻繁に更新されるコンテンツが保存されているサイト コレクションをクロールするときほど頻繁にコンテンツをクロールする必要はありません。この場合、アーカイブ サイトはもう一方のコンテンツほど頻繁にクロールする必要がないため、この 2 つのサイト コレクションを別々のスケジュールに基づいてクロールできるように、別々のコンテンツ ソースを使用してクロールする必要があります。

フル クロールおよび増分クロールのスケジュール

共有サービスの管理者は、各コンテンツ ソースに別々にクロール スケジュールを構成できます。コンテンツ ソースごとに、フル クロールを実行する時間と増分クロールを実行する時間を別々に指定できます。特定のコンテンツ ソースに対して増分クロールを実行するには、その前にフル クロールを実行する必要があることに注意してください。まだクロールされていないコンテンツに対して増分クロールを指定した場合は、フル クロールが実行されます。

検索サービスを実行するサーバーと、クロール対象のコンテンツをホスティングするサーバーについて、それらの可用性、パフォーマンス、および帯域幅を考慮して、クロール スケジュールを計画することをお勧めします。

クロール スケジュールを計画する際は、次のベスト プラクティスを考慮してください。

• コンテンツをホスティングするサーバーについて、その可用性の類似点と、許容される全体的なリソース使用率に基づいて、コンテンツ ソースの開始アドレスをグループ化します。

• コンテンツをホスティングするサーバーが利用でき、サーバーのリソースの要求が低くなっている時間帯に、各コンテンツ ソースの増分クロールをスケジュールします。

• ファーム内のサーバーの負荷が時間的に分散されるようにクロール スケジュールをずらします。

• フル クロールは、次のセクションの一覧にある理由で必要になる場合にのみスケジュールします。フル クロールは増分クロールよりも低い頻度で行うことをお勧めします。

• フル クロールが必要になる管理上の変更は、計画されているフル クロールのスケジュールの直前に行われるようにスケジュールします。たとえば、次回のフル クロールのスケジュールの前にクロール ルールの作成をスケジュールし、追加のフル クロールが必要にならないようにします。

• クロールの同時実行は、クロールを実行するインデックス サーバーの性能に応じて行います。通常は、クロール スケジュールをずらして、インデックス サーバーが同時に複数のコンテンツ ソースを使用してクロールしないようにすることをお勧めします。パフォーマンスを最適化するため、コンテンツ ソースのクロール スケジュールをずらすことをお勧めします。インデックス サーバーおよびコンテンツをホスティングするサーバーのパフォーマンスによって、クロールを同時実行できる上限が決まります。各コンテンツ ソースのクロール実行時間の傾向を把握しながら、時間をかけてクロール スケジュールの方針を定めることができます。

フル クロールを実行する理由

検索サービス管理者がフル クロールを実行する理由には、次のようなものがあります。

• ファーム内のサーバーに 1 つ以上の修正プログラムまたはサービス パックがインストールされたため。詳細については、修正プログラムまたはサービス パックのドキュメントを参照してください。

• 検索サービス管理者が新しい管理プロパティを追加したため。

• Windows SharePoint Services 3.0 サイトの ASPX ページのインデックスを再作成するため。

  注意

  Windows SharePoint Services 3.0 サイトの ASPX ページが変更されると、クローラは発見できなくなります。そのため、個別のリスト アイテムが削除されると、増分クロールではビューやホーム ページのインデックスが再作成されません。ASPX ファイルを含むサイトのフル クロールを定期的に実行することで、ページのインデックスが確実に再作成されるようにすることをお勧めします。

• ファイル共有の最後のフル クロールの後にファイル共有に対して行われたセキュリティ変更を検出するため。

• 増分クロールの連続する障害を解決するため。まれに、リポジトリ内の任意のレベルで増分クロールに 100 回連続で失敗すると、インデックス サーバーにより、影響を受けるコンテンツがインデックスから削除されることがあります。

• クロール ルールが追加、削除、または変更されたため。

• 破損したインデックスを修復するため。

• 検索サービス管理者が 1 つ以上のサーバー名マッピングを作成した。

• 既定のコンテンツ アクセス アカウントにアカウントが割り当てられたか、クロール ルールが変更された。

以下の状況では、増分クロールが要求された場合にも、システムによってフル クロールが行われます。

• 検索サービス管理者が直前のクロールを停止した。

• コンテンツ データベースが復元された。

  注意

  Microsoft Office サーバー製品インフラストラクチャ更新プログラム を実行している場合は、stsadm コマンドライン ツールの復元操作を使用して、コンテンツ データベースの復元によってフル クロールが行われるかどうかを変更できます。

• ファーム管理者がコンテンツ データベースを切断し、再接続した。

• サイトのフル クロールが一度も実行されたことがない。

• 変更ログには、クロール中のアドレスのエントリが含まれません。クロール中のアイテムの変更ログにエントリが含まれていないと、増分クロールは実行されません。

• 既定のコンテンツ アクセス アカウントにアカウントが割り当てられたか、クロール ルールが変更された。

• 破損したインデックスを修復する必要がある。

  破損の重大度によっては、インデックス内で破損が検出されたときにフル クロールが試行される場合があります。

初期展開の後、ファーム内のサーバー、およびコンテンツをホスティングしているサーバーのパフォーマンスと容量に応じて、スケジュールを調整できます。

クロールするコンテンツの量を制限または増加させる

各コンテンツ ソースについて、そのコンテンツ ソース内の開始アドレスをクロールする範囲を選択できます。また、クロールの動作 (クロール設定) も指定できます。特定のコンテンツについて選択できるオプションは、選択したコンテンツの種類によって異なります。しかし、ほとんどのオプションは、コンテンツ ソースに指定されているそれぞれの開始アドレスから、どの階層レベルの深さまでクロールするかを指定するものです。この動作は、特定のコンテンツ ソース内のすべての開始アドレスに適用されることに注意してください。一部のサイトだけを深いレベルまでクロールする必要がある場合には、そのサイトを含むコンテンツ ソースを新たに作成します。

各コンテンツ ソースのプロパティで使用できるオプションは、選択したコンテンツ ソースの種類によって異なります。次の表に、各コンテンツ ソースの種類に対応するクロールの設定オプションを示します。

コンテンツ ソースの種類	クロール設定オプション
SharePoint サイト	各開始アドレスに対応するホスト名の下にあるものすべて 各開始アドレスの SharePoint サイトのみ
Web サイト	各開始アドレスのサーバー内のみ 各開始アドレスの先頭ページのみ カスタム - ページの深さおよびサーバー ホップ数を指定 注意 このオプションの既定の設定では、ページの深さおよびサーバー ホップは無制限です。
ファイル共有	各開始アドレスのフォルダおよびすべてのサブフォルダ 各開始アドレスのフォルダのみ
Exchange パブリック フォルダ	各開始アドレスのフォルダおよびすべてのサブフォルダ 各開始アドレスのフォルダのみ

前の表で示したように、共有サービスの管理者はクロール設定オプションを使用することで、クロールするコンテンツの量を制限したり、増やしたりできます。

次の表に、クロール設定オプションを構成する際のベスト プラクティスを示します。

コンテンツ ソースの種類	目的	使用するクロール設定オプション
SharePoint サイト	サイト自体のコンテンツを含める または サブサイトで利用可能なコンテンツを含めない。または、それらを別のスケジュールでクロールする	各開始アドレスから SharePoint サイトのみをクロールする
SharePoint サイト	サイト自体のコンテンツを含める または 開始アドレスの下にあるすべてのコンテンツを同じスケジュールでクロールする	各開始アドレスから、ホスト名の下にあるすべてをクロールする
Web サイト	サイト自体のコンテンツが関連する または リンクされたサイトで利用できるコンテンツがあまり関連しない	各開始アドレスのサーバー内のみをクロールする
Web サイト	関連するコンテンツが最初のページだけにある	各開始アドレスの最初のページのみをクロールする
Web サイト	開始アドレスのリンクをクロールする深さを制限する	カスタム - ページの深さおよびサーバー ホップ数を指定 注意 接続の多いサイトでは、4 ページ以上の深さ、または 4 以上のサーバー ホップ数を指定すると、インターネット全体をクロールすることになる場合があるため、最初は小さい値を指定することをお勧めします。
ファイル共有 Exchange パブリック フォルダ	サブフォルダ内の利用可能なコンテンツがあまり関連しない	各開始アドレスのフォルダのみ
ファイル共有 Exchange パブリック フォルダ	サブフォルダ内のコンテンツが関連する可能性がある	各開始アドレスのフォルダとすべてのサブフォルダ

ファイルタイプ追加と IFilter を計画する

コンテンツがクロールされるのは、関連するファイル名拡張子がファイルタイプ追加リストに含まれており、そのファイル タイプをサポートするインデックス サーバーに IFilter がインストールされている場合に限られます。いくつかのファイル タイプは、初期インストール時に自動的に追加されます。初期展開でのコンテンツ ソースを計画するときは、クロールするコンテンツに未追加のファイル タイプが使用されているかどうかを調べてください。ファイル タイプが追加されていない場合は、展開時に [ファイルの種類の管理] ページでファイル タイプを追加し、そのファイル タイプをサポートする IFilter がインストールおよび登録されるようにする必要があります。

Search Server 2008 には複数の IFilter が用意されていますが、マイクロソフトやサードパーティ ベンダから、より多くの種類を入手できます。マイクロソフトから入手できる追加の IFilter をインストールして登録する方法の詳細については、「Search Server 2008 および SharePoint Server 2007 と Microsoft フィルタ Pack の登録方法」を参照してください。また、ソフトウェア開発者は、必要に応じて新しいファイル タイプに対応した IFilter を作成できます。

逆に、特定のファイルタイプをクロールから除外するには、そのファイルタイプに対応するファイル名拡張子をファイルタイプ追加リストから削除します。そうすることで、ファイル名にその拡張子が含まれるファイルがクロールから除外されます。

次の表に、既定でインストールされている IFilter でサポートされるファイルタイプと、既定で [ファイルの種類の管理] ページで有効になっているファイルタイプを示します。

ファイル名拡張子	既定の IFilter サポート	既定のファイルタイプ追加
ascx	○	○
asm	○	×
asp	○	○
aspx	○	○
bat	○	×
c	○	×
cmd	○	×
cpp	○	×
css	○	×
cxx	○	×
def	○	×
dic	○	×
doc	○	○
docm	○	○
docx	○	○
dot	○	○
eml	○	○
exch	×	○
h	○	×
hhc	○	×
hht	○	×
hpp	○	×
hta	○	×
htm	○	○
html	○	○
htw	○	×
htx	○	×
jhtml	×	○
jsp	×	○
lnk	○	×
mht	○	○
mhtml	○	○
mpx	○	×
msg	○	○
mspx	×	○
nsf	×	○
odc	○	○
one	×	×
php	×	○
pot	○	×
pps	○	×
ppt	○	○
pptm	○	○
pptx	○	○
pub	○	○
stm	○	×
tif	○	○
tiff	×	○
trf	○	×
txt	○	○
url	×	○
vdx	×	○
vsd	×	○
vss	×	○
vst	×	○
vsx	×	○
vtx	×	○
xlb	○	×
xlc	○	×
xls	○	○
xlsm	○	○
xlsx	○	○
xlt	○	×
xml	○	○

IFilters と Microsoft Office OneNote

Microsoft Office OneNote で使用されるファイル名拡張子 .one に対応する IFilter は提供されていません。ユーザーが Office OneNote ファイルのコンテンツを検索できるようにするには、OneNote 用の IFilter をインストールする必要があります。それには、次のどちらかの操作を実行する必要があります。

• Microsoft Office OneNote 2007 クライアント アプリケーションをインデックス サーバーにインストールします。

  Office OneNote 2007 に付属する IFilter は、Office OneNote 2003 と Office OneNote 2007 の両方のファイルをクロールするために使用できます。Office OneNote 2003 でインストールされる IFilter では、Office OneNote 2003 のファイルのみをクロールできます。

• Microsoft フィルタ パックをインストールおよび登録します。

  このフィルタ パックで提供される OneNote IFilter は、Office OneNote 2007 ファイルをクロールするためだけに使用できます。詳細については、「パック Microsoft フィルタの SharePoint サーバー 2007 と検索サーバー 2008 で登録方法」を参照してください。

クロール ルールを使用してコンテンツを制限または除外する

コンテンツ ソースに開始アドレスを追加し、既定の動作を指定した場合、クロール ルールを使用して除外しない限り、その開始アドレスの下にあるサブサイトまたはフォルダがすべてクロールされます。

クロール ルールの詳細については、後述の「クロール ルールを計画する」を参照してください。

コンテンツ ソースを計画する際のその他の考慮事項

複数のコンテンツ ソースを使用して、同じアドレスをクロールすることはできません。たとえば、特定のコンテンツ ソースを使用してサイト コレクションとそのサブサイトすべてをクロールする場合、別のコンテンツ ソースを使用して、1 つのサブサイトのみを別のスケジュールでクロールすることはできません。この制約に対応するには、サイトの一部を別にクロールする必要があります。次のシナリオで考えてみましょう。

Contoso 社の管理者が http://contoso をクロールするとします。このサイトにはサブサイトとして http://contoso/sites/site1 および http://contoso/sites/site2 が含まれています。http://contoso/sites/site2 は、他のサイトとは異なるスケジュールでクロールする必要があるとします。そのために、管理者は http://contoso と http://contoso/sites/site1 を 1 つのコンテンツ ソースに追加し、[各開始アドレスから SharePoint サイトのみをクロールする] という設定を選択します。次に、サブサイト http://contoso/sites/site2 を別のコンテンツ ソースに追加して、別のクロール スケジュールを指定します。

コンテンツ ソースの計画時には、クロール スケジュール以外にも検討する事項があります。たとえば、1 つのコンテンツ ソースに開始アドレスをまとめるか、それとも開始アドレスをクロールするためのコンテンツ ソースを新たに作成するかの判断は、多くの場合、管理者が下します。管理者は特定のコンテンツ ソースのフル更新が必要になるような変更を行うことがよくあります。コンテンツ ソースに変更を加えた場合、そのコンテンツ ソースをフル クロールする必要があります。管理を容易にするために、管理者がコンテンツ ソースの更新、クロール ルール、コンテンツのクロールを実行しやすくなるように、コンテンツ ソースを整理します。

コンテンツ ソースの概要

コンテンツ ソースを計画する際は、以下の点を考慮してください。

• コンテンツ ソースによっては、SharePoint サイト、SharePoint サイトではない Web サイト、ファイル共有、Exchange パブリック フォルダ、および Lotus Notes データベースのいずれかのコンテンツ タイプのクロールにしか使用できないものがあります。

• 検索サービスの管理者は最大 500 個のコンテンツ ソースを作成でき、各コンテンツ ソースには最大 500 個の開始アドレスを含めることができます。管理をできるだけ簡単にするため、作成するコンテンツ ソースの数を必要最小限に抑えてください。

• 特定のコンテンツ ソース内の各 URL が、同じコンテンツ ソース タイプであることが必要です。

• 特定のコンテンツ ソースについて、開始アドレスからクロールする深さを選択できます。この設定はコンテンツ ソース内のすべての開始アドレスに適用されます。開始アドレスをクロールする深さに関する選択肢は、選択したコンテンツ ソースの種類によって異なります。

• コンテンツ ソース全体に対してフル クロールまたは増分クロールをいつ実行するかをスケジュールできます。クロールのスケジュールの詳細については、後の「クロール ルールを計画する」を参照してください。

• 検索サービスの管理者は、既定のコンテンツ ソースの変更、他のコンテンツをクロールするための追加コンテンツ ソースの作成のどちらか、またはその両方を行うことができます。たとえば、異なるサーバー ファーム上のコンテンツもクロールするように既定のコンテンツ ソースを構成することも、新しいコンテンツ ソースを作成して他のコンテンツをクロールすることもできます。

• 組織で必要とされるすべてのコンテンツを効果的ににクロールするには、クロールするソースの種類や計画時点でのクロールの頻度に見合った数のコンテンツ ソースを使用します。

認証を計画する

コンテンツ ソースに指定されている開始アドレスにクローラがアクセスするとき、クローラはそのコンテンツをホスティングするサーバーの認証を受け、アクセスの許可を受ける必要があります。つまり、クローラで使用されるドメイン アカウントには、少なくともコンテンツに対する読み取り権限が必要になります。

既定のコンテンツ アクセス アカウントは、コンテンツ ソースをクロールするときに既定で使用されるアカウントです。このアカウントは検索サービスの管理者が指定します。または、クロール ルールを使用して、特定のコンテンツをクロールする際に使用するコンテンツ アクセス アカウントを別に指定することもできます。既定のコンテンツ アクセス アカウントを使用する場合でも、クロール ルールで指定される別のコンテンツ アクセス アカウントを使用する場合でも、使用するコンテンツ アクセス アカウントにはクロールするすべてのコンテンツに対する読み取りアクセスが必要です。読み取りアクセスがない場合、コンテンツはクロールされず、クエリで使用できません。

ほとんどのクロール対象コンテンツに最も広範にアクセスできる既定のコンテンツ アクセス アカウントを選択し、セキュリティ上の考慮から別のコンテンツ アクセス アカウントが必要な場合にのみ、それ以外のコンテンツ アクセス アカウントを使用することをお勧めします。既定のコンテンツ アクセス アカウントを使用して読み取ることができないコンテンツをクロールするために別のコンテンツ アクセス アカウントを作成する方法については、後述の「クロール ルールを計画する」を参照してください。

計画する各コンテンツ ソースについて、既定のコンテンツ アクセス アカウントでアクセスできない開始アドレスを特定し、そのような開始アドレスを含む URL パターンに対応するクロール ルールの追加を計画します。

コンテンツ アクセス アカウントを計画する際の考慮事項の詳細については、後述の「クロール ルールを計画する」を参照してください。

もう 1 つの重要な考慮事項は、クローラがホスト サーバーと同じ認証方法を使用する必要があることです。既定では、クローラは NTLM 認証を使用して認証を試みます。必要に応じて、別の認証方法を使用するようにクローラを構成できます。詳細については、「認証方法を計画する (Office SharePoint Server)」の「コンテンツのクロールの認証要件」を参照してください。この記事は Search Server 2008 にも関連があります。

プロトコル ハンドラを計画する

クロール対象のすべてのコンテンツで、そのコンテンツにアクセスするために、プロトコル ハンドラを使用する必要があります。Search Server 2008 には、一般的なインターネット プロトコルに対応するプロトコル ハンドラが用意されています。ただし、Search Server 2008 でインストールされないプロトコル ハンドラを必要とするコンテンツをクロールする場合、そのコンテンツをクロールする前にサードパーティまたはカスタムのプロトコル ハンドラをインストールする必要があります。

次の表に、既定でインストールされるプロトコル ハンドラを示します。

プロトコル ハンドラ	クロール対象
File	ファイル共有
http	Web サイト
https	SSL (Secure Sockets Layer) 経由の Web サイト
Notes	Lotus Notes データベース
Rb	Exchange パブリック フォルダ
Rbs	SSL 経由の Exchange パブリック フォルダ
Sps	Windows SharePoint Services 2.0 サーバー ファームからのユーザー プロファイル
Sps3	Windows SharePoint Services 3.0 サーバー ファームのみのユーザー プロファイルのクロール
Sps3s	SSL 経由の Windows SharePoint Services 3.0 サーバー ファームのみのユーザー プロファイルのクロール
Spsimport	ユーザー プロファイルのインポート
Spss	SSL 経由の Windows SharePoint Services 2.0 サーバー ファームからのユーザー プロファイルのインポート
Sts	Windows SharePoint Services 3.0 ルート URL (内部プロトコル)
Sts2	Windows SharePoint Services 2.0 サイト
Sts2s	SSL 経由の Windows SharePoint Services 2.0 サイト
Sts3	Windows SharePoint Services 3.0 サイト
Sts3s	SSL 経由の Windows SharePoint Services 3.0 サイト

クロールの影響の管理を計画する

コンテンツのクロールを実行すると、そのコンテンツをホスティングするサーバーのパフォーマンスが大幅に低下する可能性があります。この現象が特定のサーバーに及ぼす影響は、そのホスト サーバーの負荷と、通常使用時またはピーク使用時にサービス レベル アグリーメントを維持するためのリソース (特に CPU と RAM) が十分にあるかどうかによって変わります。

クローラ影響ルールによって、ファームの管理者はクロール対象サーバーに対するクローラの影響を管理できます。各クローラ影響ルールでは、単一の URL を指定するか、URL パスにワイルドカード文字を使用して、URL のブロックにこのルールを適用できます。次に、指定した URL に対して実行するページの同時要求の数を指定するか、一度にドキュメントを 1 つだけ要求し、次の要求まで指定した秒数だけ待機することを選択できます。

クローラ影響ルールを使用することで、アドレスのクロールに使用されるコンテンツ ソースに関係なく、特定の開始アドレスまたは開始アドレスの範囲 (サイト名とも呼ばれます) からのコンテンツをクローラが要求する頻度が減少または増加します。次の表に、ルールの追加時にサイト名で使用できるワイルドカード文字を示します。

使用するワイルドカード	結果
* (サイト名)	すべてのサイトにルールを適用します。
*.* (サイト名)	名前にドットを含むサイトにルールを適用します。
*.サイト名.com (サイト名)	サイト名.com ドメイン内のすべてのサイトにルールを適用します (例 : *.adventure-works.com)。
*.トップレベル ドメイン名 (サイト名)	サイト名の末尾が特定のトップレベル ドメイン名であるすべてのサイトにルールを適用します (例 : *.com、*.net)。
?	ルール内の 1 つの文字を置き換えます。たとえば、*.adventure-works?.com は、ドメイン内の adventure-works1.com、adventure-works2.com などのサイトすべてに適用されます。

特定のトップレベル ドメイン内のすべてのサイトに適用されるクローラ影響ルールを作成できます。たとえば、*.com を指定すると、アドレスの末尾が .com であるすべてのインターネットサイトに適用されます。たとえば、ポータル サイトの管理者が samples.microsoft.com のコンテンツ ソースを追加するとします。samples.microsoft.com について個別のクローラ影響ルールを追加していない限り、*.com のルールがこのサイトに適用されます。

他の管理者がクロールしている組織内のコンテンツについては、他の管理者と調整して、サーバーのパフォーマンスと容量に基づいてクローラ影響ルールを設定できます。外部サイトについては、このような調整はほとんどの場合行えません。外部サーバー上の大量のコンテンツを要求したり、頻繁に要求を行ったりすると、クロールで使用されるリソースや帯域幅が多すぎる場合には、要求先のサイトの管理者によって以後のアクセスが制限される可能性があります。そのため、より時間をかけてクロールすることがベスト プラクティスになります。これにより、関連性のあるコンテンツをクロールするためのアクセス権を失う危険性を軽減できます。

初期展開の際、他のサーバーへの影響ができるだけ小さくなるようにする一方で、クロールされたコンテンツの最新度を保てるほどの十分な頻度でクロールするように、クローラ影響ルールを設定します。

運用段階では、実態やクロール ログのデータに応じてクローラ影響ルールを調整できます。

クロール ルールを計画する

クロール ルールは、特定の URL またはワイルドカードで表される一連の URL (ルールの影響を受けるパスとも呼ばれます) に適用されます。クロール ルールを使用して、次の処理を実行できます。

• 1 つ以上の URL を除外することによって、関連性のないコンテンツのクロールを回避します。これによって、サーバー リソースやネットワーク トラフィックの使用が抑えられ、検索結果の関連性が向上します。

• URL 自体をクロールせずに、URL のリンクをクロールします。このオプションは、関連するコンテンツのリンクを含むサイトで、リンクを含んでいるページに、関連情報を含まないリンクが含まれている場合に便利です。

• 複雑な URL のクロールを可能にします。このオプションを実行すると、疑問符で指定されたクエリ パラメータを含む URL がクロールされます。サイトによって、このような URL には関連するコンテンツが含まれている場合と含まれていない場合があります。複雑な URL は関連のないサイトにリダイレクトされることが多いため、複雑な URL から利用できるコンテンツの関連性が高いことがわかっているサイトにのみこのオプションを有効にすることをお勧めします。

• SharePoint サイトのコンテンツを HTTP ページとしてクロールできるようにします。このオプションによって、インデックス サーバーはファイアウォールの背後にある SharePoint サイトや、クローラで使用される Web サービスへのアクセスを制限しているクロール対象サイトをクロールできるようになります。

• 指定した URL のクロールに、既定のコンテンツ アクセス アカウント、別のコンテンツ アクセス アカウント、またはクライアント証明書を使用するかどうかを指定します。

通常、特定のサイト アドレスのほとんどのコンテンツには関連性がありますが、サイト アドレスの下位にある特定のサブサイトや一連のサイトには関連性がないコンテンツが含まれます。不要な項目を除外するクロール ルールの作成対象となる URL の組み合わせを明確に選択することによって、検索サービスの管理者はインデックス内のコンテンツの関連性を最大化し、クロールのパフォーマンスに対する影響や検索データベースのサイズを最小限に抑えることができます。クロール ルールの作成による URL の除外は、特に、リソースの使用による影響を組織内のユーザーが管理できない外部コンテンツについて、その開始アドレスを計画する場合に便利です。

クロール ルールを作成するときには、パスに標準的なワイルドカード文字を使用できます。次に例を示します。

• http://server1/folder* には、http://server1/folder で始まる URL のすべての Web リソースが含まれます。

• *://*.txt には, .txt ファイル名拡張子を持つすべてのドキュメントが含まれます。

コンテンツのクロールではリソースと帯域幅が消費されるため、関連性のない可能性があるコンテンツを大量に含めるよりも、少量でも関連性があるとわかっているコンテンツを含めることをお勧めします。初期展開の後で、クエリ ログとクロール ログを調べ、より関連性のある、より多くのコンテンツが含まれるように、コンテンツ ソースとクロール ルールを調整できます。

別のコンテンツ アクセス アカウントを指定する

コンテンツを含めるためのクロール ルールについては、ルールに使用するコンテンツ アクセス アカウントを変更できます。クロール ルールで別のアカウントが指定されていない限り、既定のコンテンツ アクセス アカウントが使用されます。多くの場合、クロール ルールで別のコンテンツ アクセス アカウントを使用するのは、既定のコンテンツ アクセス アカウントでは一部の開始アドレスにアクセスできないときです。このような開始アドレスに対してクロール ルールを作成して、アクセス権のあるアカウントを指定できます。

ファーム レベルで管理される検索設定を計画する

コンテンツのクロール方法については、Search 管理レベルで構成される設定に加えて、ファーム レベルで管理されるいくつかの設定が影響を与えます。クロールを計画するときには、以下のファーム レベルの検索設定も考慮してください。

連絡先の電子メール アドレス : コンテンツをクロールすると、クロール対象のサーバーのリソースに影響します。コンテンツをクロールする前に、クロールがサーバーに悪影響を及ぼした場合にサーバー管理者が連絡できる、組織内の担当者の電子メール アドレスを構成設定で指定する必要があります。この電子メール アドレスは、クロールしているサーバーの管理者のログに表示されます。サーバーのパフォーマンスや帯域幅に対するクロールの影響が大きすぎるなどの問題が発生した場合に、サーバー管理者が担当者に連絡できます。

連絡先の電子メール アドレスは、必要な専門知識を持ち、要求に対して迅速に応答できる担当者の電子メール アドレスである必要があります。代わりに、厳密に監視される配布リストのエイリアスを連絡先の電子メール アドレスとして使用することもできます。クロールしたコンテンツが組織の内部に保存されるかどうかに関係なく、迅速に応答することが重要です。

プロキシ サーバー設定 : コンテンツをクロールするときに、プロキシ サーバーを使用するかどうかを選択できます。使用するプロキシ サーバーは、Search Server 2008 の展開のトポロジおよび組織内の他のサーバーのアーキテクチャに応じて決定します。

• タイムアウト設定 : タイムアウト設定では、他のサービスへの接続中に、検索サーバーが待機する時間を制限できます。

• SSL 設定 : SSL (Secure Sockets Layer) 設定は、コンテンツをクロールするために SSL 証明書が正確に一致している必要があるかどうかを決定します。

さまざまな言語でコンテンツのインデックスを作成する

クローラは、コンテンツのクロール時に、コンテンツを構成する個々の単語を判別します。単語がスペースで区切られる言語の場合、クローラは比較的簡単に単語を判別できます。それ以外の言語の場合、単語の境界を判別する処理が複雑になる可能性があります。

Search Server 2008 では、数多くの言語でコンテンツのクロールとインデックスを作成できるように、ワード ブレーカとステマが既定で組み込まれています。ワード ブレーカは、インデックス付き全文データで単語の境界を見つけます。一方、ステマは、動詞の活用形を見つけます。

次の表に示すいずれかの言語でクロールする場合、Search Server 2008 では、その言語に対応するワード ブレーカとステマが自動的に使用されます。アスタリスク (*) は、ステム機能が既定で有効であることを示します。

既定でサポートされる言語	既定でサポートされる言語
アラビア語	リトアニア語*
ベンガル語	マレー語
ブルガリア語*	マラヤーラム語*
カタロニア語	マラーティー語
クロアチア語	ノルウェー語 (ボークモール)
チェコ語*	ポーランド語*
デンマーク語	ポルトガル語
オランダ語	ポルトガル語 (ブラジル)
英語	パンジャーブ語
フィンランド語*	ルーマニア語*
フランス語*	ロシア語*
ドイツ語*	セルビア語 (キリル)*
ギリシャ語*	セルビア語 (ラテン)*
グジャラート語	スロバキア語*
ヘブライ語	スロベニア語*
ヒンディー語	スペイン語*
ハンガリー語*	スウェーデン語
アイスランド語*	タミール語*
インドネシア語	テルグ語*
イタリア語	タイ語
日本語	トルコ語*
カナラ語*	ウクライナ語*
韓国語	ウルドゥー語*
ラトビア語*	ベトナム語

サポートされていない言語でコンテンツのインデックスを作成する場合、クローラではニュートラル ブレーカが使用されます。ニュートラル ブレーカでは満足できる結果が得られない場合は、Search Server 2008 に対応したサードパーティのソリューションを試してみることができます。

関連項目

概念

フェデレーションを操作する (Search Server 2008)