Enterprise Vault™ Veritas Information Classifier を使用した分類
- このマニュアルについて
- 分類のための Enterprise Vault の準備
- Veritas Information Classifier ポリシーの設定
- Enterprise Vault 分類ポリシーの定義と適用
- テストモードでの分類の実行
- スマートパーティションを使用した分類
- 付録 A. カスタムフィールドの検索に使う Enterprise Vault のプロパティ
- 付録 B. 分類に使う PowerShell cmdlet
- cmdlet の分類について
- Disable-EVClassification
- Get-EVClassificationPolicy
- Get-EVClassificationStatus
- Get-EVClassificationTestMode
- Get-EVClassificationVICTags
- Initialize-EVClassificationVIC
- Set-EVClassificationVICFIPSMode
- New-EVClassificationPolicy
- Remove-EVClassificationPolicy
- Set-EVClassificationPolicy
- Set-EVClassificationTestMode
- 付録 C. 分類キャッシュフォルダ
- 付録 D. FCI 分類から Veritas Information Classifier への移行
- 付録 E. 監視とトラブルシューティング
ポリシー条件について
条件は、Veritas で一致と判断されるために、アイテムが満たす必要がある基準を指定します。ポリシーには任意の数の条件を含めることができます。
このトピックでは次の情報について説明します:
すべての条件を次の基本的な形式で示す必要があります:
プロパティ、演算子、値
たとえば、次の条件の場合は、「Content」がプロパティ、「contains text」が演算子、「Stocks」が値になります。
プロパティは、評価するアイテムの部分または特性 (コンテンツ、タイトル、更新日、ファイルサイズなど) を指定します。リストからプロパティを選択すると、選択したプロパティに合わせて、他の 2 つのフィールドのオプションが変わります。たとえば、更新日プロパティを選択した場合、他のフィールドには、1 つ以上の日付を設定するためのオプションが表示されます。「Content」などのプロパティを選択した場合は、次の演算子を使用できます。
contains text
matches regex
matches pattern
is similar to
contains exact data match in
language is
contains entity
sentiment score
各条件の右側で、Veritas で一致と判断されるためにアイテムが基準を満たす必要がある最小回数を指定できます。
組織で使用しているさまざまなアプリケーションにより、アイテムに対するカスタムプロパティ情報が追加されることがあり、これらの分類が必要になります。たとえば、Enterprise Vault がアイテムを処理する場合、アイテムのメタデータのプロパティに情報をポピュレートし、この情報をアーカイブ済みアイテムとともに格納します。情報とは、具体的には Enterprise Vault がアイテムをアーカイブした日付、付帯する添付ファイルの個数などです。
特に関心のあるプロパティの名前を知っている場合、ポリシー条件のカスタムフィールドとしてその名前を入力できます。
ポリシーの作成時に、プロパティリストに必要なプロパティがない場合は、カスタムプロパティフィールドを使用して新しいプロパティを作成できます。
新しいプロパティを作成するには、ポリシーの作成時または編集時に次のようにカスタムプロパティフィールドを使用します。
- トピックポリシーの作成に記載されている手順に従って、他のフィールドを設定します。
- ［Conditions］セクションの［Property］ドロップダウンリストで、［Custom date field］、［Custom number field］、［Custom string field］のいずれかのカスタムプロパティフィールドを選択します。
- 新しいカスタムプロパティの名前を指定します。
メモ:
カスタムプロパティの名前は、Apache TIKA などのテキスト抽出エンジンで識別されるメタデータプロパティ名と同じものにする必要があります。Veritas Enterprise Vault の場合、カスタムプロパティ名にはいずれかのインデックスプロパティの名前を指定する必要があります。
- 残りのポリシー作成手順を完了します。
新しいカスタムプロパティを持つ新しいポリシーが作成されます。
UI のプロパティリストにカスタムプロパティを追加するには、Veritas の YAML ファイルを使用します。
YAML ファイルの metadataDefinitions セクションには、以下のように、プロパティリストにあるすべての既存プロパティの一覧が示されています。
次の表に、既存プロパティのデータ構造を示します。
|
プロパティ項目 |
説明 |
|---|---|
|
name |
Apache TIKA などのテキスト抽出エンジンで認識されるメタデータプロパティを指定します。 Veritas Enterprise Vault の場合は、キャプチャ済みのインデックスプロパティを指定します。 |
|
displayName |
UI のプロパティリストに表示されるプロパティ名 (「タイトル」など)。 |
|
type |
関連付けられているプロパティの種類 (文字列、日時、数値など)。 |
|
aliases |
displayName にマップする追加のメタデータプロパティを指定します。 |
ポリシー条件ページの UI でこのプロパティを利用できるようにする方法
- 前の表で示した新しいプロパティの詳細を、YAML の metadataDefinitions セクションに追加します。
- 各アプリケーションの Veritas サービスを再起動します。
分類用に提出するアイテム内で特定の単語またはフレーズを検索する条件を設定する際には、次のガイドラインを確認してください。
複数の単語またはフレーズを検索するには、それぞれを個別の行に指定します。アイテムが条件を満たすには、リスト内に 1 つの単語またはフレーズのみを含める必要があります。
指定した単語またはフレーズに大文字と小文字の違いも含めて完全に一致するもののみを検索するには、［Match Case］を選択します。
指定した単語またはフレーズが他の単語やフレーズの一部である場合を検索するには、［String Match］を選択します。たとえば、このオプションを選択した場合、「enter」は、「enters」、「entertainment」、「carpenter」と一致します。このオプションを選択しない場合、「enter」は「enter」とのみ一致します。
同様に、［String Match］を選択した場合、「call me」というフレーズは、「call media」、「recall meeting」と一致しますが、「surgically mend」とは一致しません。
2 つの単語間の近接演算子 NEAR と BEFORE は、同じ行で指定できます。たとえば、「tax NEAR/10 reform」は、「tax」と「reform」の間に 10 文字以下の単語が含まれる場合に一致します。「sales BEFORE/5 report」 は、「sales」が「report」の前にあり、これらの単語の間に 5 文字以下の単語がある場合に一致します。どちらの場合も、数値が必須になります。
メモ:
テーブルや表計算ワークシートなどのフォーマット済みデータを評価するときに、これらの近接演算子が予想どおりに機能しない可能性があります。このデータを分類する前に実行する変換処理は、表のセルの順序を入れ替える可能性があります。たとえば、表計算ワークシートのセルに sales という単語が含まれ、そのセルの右隣のセルに report という単語があるとします。これは、sales BEFORE/5 report 演算子と一致しますが、変換処理によりこれら 2 つの単語が入れ替えられて、表計算ワークシートが変換された後は一致しないことがあります。
単語とフレーズにはアスタリスク (*) と疑問符 (?) のワイルドカード文字を含めることができます。単語の一部としてアスタリスクを含めると、ゼロ個以上の文字と一致します。アスタリスクを単独で指定すると、1 つの単語に一致します。疑問符 (?) は 1 文字に一致します。次に例を示します。
「stock*」は、「stock」、「stocks」、「stockings」と一致します。
「*ock」は、「stock」、「clock」と一致します。
「*ock*」は、「stock」、「clocks」と一致します。
「??ock」は、「stock」、「clock」と一致しますが、「dock」とは一致しません。
「sell * stock」は、「sell the stock」、「sell some stock」と一致しますが、「sell stock」とは一致しません。
ワイルドカードを NEAR 演算子や BEFORE 演算子と組み合せて使用できます。次に例を示します。
「s?l? BEFORE/1 stock*」は、「sold the stock」、「sell stocks」、「sale of stockings」と一致します。
ポリシー条件の基準を評価するときに特定の単語またはフレーズを除外するには、［Exclude Match］を選択します。
このオプションを選択する際は、含める用語だけでなく、一致条件から除外する用語を定義することもできます。
たとえば、文書に次のようなサンプルテキストが含まれているとします: 「Admin: There is a spoofing activity detected. Bob: Can you help me locate a spoofed account for spoofed email account?」。ヒットさせたいのは「spoof, spoofed, spoofing」のみで、「spoofed email account, an email spoof」は除外します。このようなシナリオでは、次のサンプルイメージに示すように、含める語のフィールドに「spoof, spoofed, spoofing」というキーワードを指定し、除外する語のフィールドに「spoofed email account, an email spoof」を指定します。
除外ポリシー条件の制限事項
このフィールドでは、キーワードベースの除外のみが許可されます。つまり、除外する語の入力フィールドはキーワードのみを受け入れ、正規表現やパターンなどは受け入れません。
キーワードベースの除外は、除外する語の中に、包める語がすべて含まれているシナリオでのみ機能します。
グループレベル条件の近接オプションは、基になる条件のいずれかに除外する要素がある場合、グループに対しては使用できません。
除外ポリシー条件を使用するには、???を参照してください。
正規表現 (regex) は、通常の文字 (a から z までの文字など) とメタ文字と呼ばれる特殊文字から成るテキストのパターンです。パターンとは、テキストを検索するときに照合する 1 つ以上の文字列です。たとえば、次の正規表現はすべての Visa カード番号で一連の数を照合します。
\b4[0-9]{12}(?:[0-9]{3})?\b正規表現は Perl の正規表現の構文に従う必要があります。
この構文について詳しくは、Veritas のヘルプを参照してください。
https://regex101.com で入手できる無料のオンラインツールを使用して、正規表現を作成およびテストすると便利です。このツールでは、正規表現を入力するとその正規表現の説明が表示され、正規表現と入力したテスト文字列で一致するものがすべて一覧に表示されます。デフォルトの正規表現の種類である pcre (php) は、Veritas と互換性があります。
メモ:
正規表現との一致の検索は、特定の単語やフレーズを検索するよりもかなり時間がかかります。両方の種類の一致が互いに近接しているインスタンスを検索すると、パフォーマンスを大幅に向上させることができます。それには、正規表現の条件と特定の語句を検索する［contains text］条件の両方を含む［All of］という条件グループを設定して、必要な一致の近接度を指定します。Veritas は、最初に［contains text］条件を評価して、次に正規表現の一致を検索します。
パターンの一致では、選択されたアイテムプロパティを、既存の Veritas パターンと比較して評価します。選択したパターンによっては、受け入れる信頼度を設定できます。信頼度を高くすると、数は少ないが関連性のより高い一致が得られる可能性があります。
組み込みパターンを使用するポリシーをテストしたときに期待した結果を得られなかった場合は、次の点を確認してください。
テストアイテムがパターンの信頼度を満たしていることを確認することが重要です。たとえば Credit Card Policy は、デフォルトでは中程度の信頼度または高い信頼度が設定されている「Credit/Debit Card Number」パターンと一致するコンテンツを検索します。中程度の信頼度の要件を満たすには、コンテンツに次のいずれかが含まれている必要があります。
区切り文字で分けられたクレジットカード番号 (数値の間にスペースまたはダッシュが含まれている)
区切り文字で分けられていないクレジットカード番号と 1 つ以上のクレジットカードキーワード (AMEX、Visa など) の両方
区切り文字で分けられていないクレジットカード番号は含まれているが、クレジットカードキーワードが含まれていないアイテムは、要件を満たしていないことになります。
［Show details］をクリックしてテスト結果を表示した後、［Test classification results］ウィンドウで一致の一部またはすべてがハイライトされないことがあります。これは、特定のパターンでのみ発生する既知の問題です。この問題は Veritas の今後のバージョンで修正される予定です。
パターン照合を使用して重要なデータを特定する多くの分類手法とは異なり、完全データ一致 (EDM) は、保護する必要がある実際のデータが検出されると分類応答をトリガします。正確なデータで照合することにより、誤検知率が低下し、自動分類の精度が大幅に向上します。EDM は、指紋方式を使用して、データベースやテーブルの抽出データを CSV または TXT 形式のソースファイルとして提供します。テーブルが取り込まれ、1 行の 1 つ以上の列が近接して検出されたときに一致を示すルールが作成されます。EDM は、表内に保持されている個別の顧客データ、従業員データ、その他の重要なデータリポジトリの識別が必要な場合に最適です。
完全データ一致を使用して情報を分類する方法
設定オプションを設定しソース文書 (通常は、データベースなどのデータストアからエクスポートした目的のフィールドを含む) を指定して、EDM パターンを作成します。「完全データ一致ベースのパターンを作成する方法」を参照してください。
EDM ベースの分類に使用する任意のポリシーで、作成した EDM パターンを使用します。
YAML を使用して、完全なデータ一致を有効または無効にできます。
完全データ一致機能を使用すると、データベースから特定のデータセットを検出できます。たとえば、従業員のレコードを検出できます。1 つ以上のフィールドやオプションのフィールドについて、設定した近接値に従って照合できます。データベースレコードなどの大規模なデータセットとすべての言語のテキストをサポートし、格納されたデータをハッシュ化することでデータを保護します。完全データ一致を使用する主なメリットは、(パターンベースの照合と異なり) データとの完全な一致を照合することで誤検知を抑えられることです。
たとえば、分類対象の文書に次のコンテンツが含まれているとします。
Name: Teresa M. Brown
Employee ID: 624828
この文書を、次の EDM ソース文書に対して照合します。
この場合、一致がトリガされます。
完全データ一致には次のメリットがあります。
データベースから特定のデータセットを検出できます。たとえば、従業員のレコードを検出できます。
データの組み合わせの照合がサポートされます。たとえば、1 つ以上のフィールドやオプションのフィールドについて、設定した近接値に従って照合を行えます。
データベースレコードなどの大規模なデータセットがサポートされます。
格納データをハッシュ化することでデータの保護を実現できます。
リモート分類サーバーで、(分類に必要な) 完全データ一致ルールパックを自動的に同期します。手動での操作は必要ありません。
テナント固有のパターン、ポリシー、タグに類似したメカニズムを使用して、完全データ一致ルールパックファイルのファイル暗号化をサポートします。
ポリシーの設定時における、完全データ一致タイプポリシー条件についての最小/最大の処置をサポートします。
あらゆる言語のテキストがサポートされます。
完全データ一致パターンを使用してポリシーを作成する方法
- 前述の説明に従って、ポリシーの作成手順または編集手順の冒頭部分を進めます。
- 演算子のリストボックスで［contains exact data match in］を選択し、このボックスの横にある値リストボックスで目的の完全データ一致パターンを選択します。
メモ:
［Conditions］に、ポリシーの設定時における、完全データ一致タイプポリシー条件についての最小/最大の処置のサポートが追加されます。キーワード一致については、正確な数またはそれ以上の数を指定できます。1 より大きい値を選択すると、［Exclude repeats］チェックボックスが表示されます。このチェックボックスを選択すると、重複しない一致が表示されます。
たとえば、2 枚以上のクレジットカードという条件では、1 つの文書に 2 つの異なるクレジットカードが必要です。
- ［Save］をクリックします。
EDM ベースのポリシーに対して文書のテストを行うと、Veritas に結果が表示されます。また、一致する行の最初の列が強調表示されます。
例 1:
ソース文書のコンテンツが次のとおりであるとします。
完全データ一致オプションを次のように設定します。
|
名前 |
値 |
|---|---|
|
First row contains column headers |
Yes |
|
Column delimiter |
, |
|
Perform hashing to secure data fields |
No |
|
Use case-sensitive matching |
No |
|
Proximity for matches |
200 |
|
Minimum columns to match |
2 |
|
All columns |
Not selected |
また、テスト対象文書のコンテンツが次のとおりであるとします。
分類結果には、2 件のレコード (Stuart と James) に対する一致が表示されます。
例 2:
前の例と同じソース文書とテスト対象文書について、［最小列数］値を次のように 3 に設定します。
|
名前 |
値 |
|---|---|
|
First row contains column headers |
Yes |
|
Column delimiter |
, |
|
Perform hashing to secure data fields |
No |
|
Use case-sensitive matching |
No |
|
Proximity for matches |
200 |
|
Minimum columns to match |
3 |
|
All columns |
Not selected |
分類結果には、1 件のレコード (Stuart) に対する一致が表示されます。これは、テスト対象文書には最初のレコードの 3 フィールドがすべて含まれているためです。
例 3:
前の例と同じソース文書とテスト対象文書について、［近接］値を次のように 50 に設定します。
|
名前 |
値 |
|---|---|
|
First row contains column headers |
Yes |
|
Column delimiter |
, |
|
Perform hashing to secure data fields |
No |
|
Use case-sensitive matching |
No |
|
Proximity for matches |
50 |
|
Minimum columns to match |
3 |
|
All columns |
Not selected |
この場合、指定した近接距離である 50 文字以内に目的の単語が存在していません。そのため、結果には一致が表示されません。
完全データ一致ベースのポリシーの分類パフォーマンスは、次の要因によって決まります。
照合対象のレコードの数
フィールドの数とフィールドのサイズ
分類するデータ
一致の数
近接と列の一致が見つかりました
計算ハードウェアと利用可能なリソース
ポリシーの照合を特定の言語のアイテムに制限する条件を設定できます。たとえば、主要な言語がフランス語であるアイテムを検索するには次のような条件を設定します。
言語のリストに［Multiple languages detected］というオプションがあります。このオプションは、2 つ以上の言語を含むアイテムと一致します。
Veritas が主要な言語を特定できないためにアイテムを無視することを防ぐには、［Or Primary Language Unknown］を選択します。Veritas でアイテムの主要な言語を特定できない最も一般的な理由は、アイテムのコンテンツが非常に少ないことです。
ポリシーの照合をユーザー名または場所を含むコンテンツに制限する条件を設定できます。
メモ:
「contains entity」条件は、Veritas アプリケーションの実行時に nlp-service-0.1.6.jar を使用する場合にのみ利用可能です。また、固有表現認識 (NER) は英語でのみ利用可能です。
たとえば、ユーザー名を含むコンテンツを検索するには、次のような条件を設定します。
メモ:
固有表現認識 (NER) は、通常の分類に比べ、より多くの時間とリソースを消費します。NER は大規模な文書 (特に 10 MB を超える文書) には適していません。
分類されたアイテムごとのリスクスコアとリスクレベルが、この情報を使用するアプリケーションに送信されます。この情報を使用するアプリケーションでは、この情報を分析でき、リスクスコアまたはリスクレベル (またはその両方) に基づくアイテムの並べ替え、フィルタ、検索、レポートなどの機能をサポートできます。リスクレベルについて理解することで、データ管理、レビュー、制御にかける労力を最適化できます。リスクが最も高いアイテムに対するアクティビティとリソースを優先することをお勧めします。
リスクスコアとリスクレベルは、パターンまたはポリシー条件のヒット数に基づきます。ヒット数が多いアイテムは高リスクに分類されます。ヒット数が少ないアイテムは低リスクに分類されます。
YAML ファイルでは、以前使用されていた lowerRiskRuleNameParts パラメータは非推奨になり、lowRiskUpperLimit、mediumRiskUpperLimit、highRiskUpperLimit の 3 つの新しいパラメータが追加されています。これらのパラメータは、リスクスコア値に基づいてさまざまなリスクレベル定義を制御します。この設定は、低、中、高のリスクレベルのリスクスコア範囲の上限を定義します。
lowRiskUpperLimit - ゼロまたはゼロより大きい値を指定できます。デフォルトでは、2 に設定されています。
mediumRiskUpperLimit - ゼロ以外の正の整数を指定できます。ただし、lowRiskUpperLimit 値より大きくする必要があります。デフォルトでは、5 に設定されています。
highRiskUpperLimit - ゼロ以外の正の整数を指定できます。ただし、mediumRiskUpperLimit 値より大きくする必要があります。デフォルトでは、10 に設定されています。
この設定は、低、中、高のリスクレベルのリスクスコア範囲の上限を定義します。
|
条件 |
リスクレベル |
|---|---|
|
リスクスコア > highRiskUpperLimit |
最高 |
|
highRiskUpperLimit >= リスクスコア > mediumRiskUpperLimit |
高 |
|
mediumRiskUpperLimit >= リスクスコア > lowRiskUpperLimit |
中 |
|
lowRiskUpperLimit >= リスクスコア >= 1 |
低 |
|
リスクスコア = 0 |
リスクなし |
分類 API 応答のリスクスコアとリスクレベルの情報
次の条件が満たされた場合にのみ、分類応答の一部としてリスク情報が送信されます。
分類要求で matchDetailLevel が LOW、MEDIUM、HIGH のいずれかに設定されている
アイテムに、リスクスコアに基づいたいくつかのリスクと、リスクレベル制限の設定が YAML ファイルにある
リスクスコアの計算
重要である可能性のあるコンテンツについてのリスク計算は、パターンまたはポリシー条件、およびポリシーリスクの重みに対するヒットの度合いに基づいて行われます。
メモ:
デフォルトでは、すべてのカスタムポリシーおよびほとんどの組み込みポリシーで、リスクの重みの値は 1 として設定されます。サブスクリプションポリシーとすべての言語検出ポリシーのリスクの重みは、デフォルトで 0 に設定されています。
次の例を考えてみます。文書には次の分類結果があります。
ポリシー
分類結果
|
ポリシー名 |
パターン名 (一致数) |
リスクの重み |
|---|---|---|
|
Policy-1 |
Pattern-A (2)、Pattern-B (3) |
2 |
|
Policy-2 |
Pattern-B (2)、Pattern-C (1) |
0 |
|
Policy-3 |
Pattern-C (3)、Pattern D (5) |
1 |
|
Policy-4 |
Pattern-C (1)、Pattern E (1) |
5 |
一意のポリシー照合テーブル
次の表に、リスクスコア計算のサンプルシナリオを示します。
|
パターン名 |
一致数 |
元のポリシー |
リスクの重み |
|---|---|---|---|
|
Pattern-A |
2 |
Policy-1 |
2 |
|
Pattern-B |
3 |
Policy-1 |
2 |
|
Pattern-C |
3 |
Policy-3 |
1 |
|
Pattern-D |
5 |
Policy-3 |
1 |
|
Pattern-E |
1 |
Policy-4 |
5 |
リスクスコアを計算するため、一意のポリシー照合テーブルに示すように、アイテムのパターンヒットが複数のポリシーにあった場合に備えて、リスクの重みが最も高いポリシーが考慮されます。
リスクスコアは、各ポリシーの一致数とリスクの重みの掛け算の合計で算出されます。次の手順では、リスクスコア計算のステップレベルの処理について説明します。
手順 1: 一致数にリスクレベルを掛けます。
手順 2: 一意のルール一致テーブル内のすべての行に対して手順 1 を繰り返します。
手順 3: 手順 2 の結果を追加します。
リスクスコア = 2*2 + 3*2 + 3*1 + 5*1 + 1*5
= 4 + 6 + 3 + 5 + 5
= 23
リスクレベル
リスクは、リスクスコアに応じて異なるリスクレベルに分類され、ポリシー条件についてセクションで説明されています。
上記の例では、リスクスコアは 21 です。したがって、リスクはリスクレベル「最高」に分類されます。
リスクスコアの実態と制限事項:
感情スコアまたは固有表現に基づくポリシー条件のヒット数は、リスクスコアに影響しません。
アイテムの合計リスクスコアに対する貢献度は、サブスクリプションポリシーと言語検出ポリシーのリスクの重みがデフォルトでゼロであるため、ゼロになります。
言語検出ポリシーのヒットが原因で、アナライザの概要ページとアナライザの PDF レポートの［最も一般的な重要なデータ］の結果でいくつかの不一致が見られる場合があります。アナライザの概要ページの結果は正確です。
次のポリシー条件はリスクスコアに影響します。
コンテンツ
タイトル
作成者
コンテンツタイプ
受信者
更新日
作成日
機密性
カテゴリ
サイズ (バイト)
カスタム日付フィールド
カスタム数値フィールド
カスタム文字列フィールド
条件のセットをグループ化し、その条件グループを他の条件グループ内に入れ子にすることができます。選択したグループ演算子によって、アイテムが一致と判断されるためにそのグループ内の条件のすべてを満たす必要があるか、一部を満たす必要があるか、どの条件も満たさない必要があるかが決まります。次のグループ演算子を使用できます。
All of。アイテムは指定した条件すべてを満たす必要があります。
Any of。アイテムは指定した条件の少なくとも 1 つを満たす必要があります。
None of。アイテムは指定した条件のいずれも満たさない必要があります。
メモ:
［All of］グループ内に［None of］グループを入れ子にして、特定の条件に一致し、特定の条件に一致しないものを除外する検索を行うことができます。たとえば、「(条件 X AND 条件 Y) BUT NOT 条件 Z」で適切な結果を得るには、［All of］グループに X 条件と Y 条件、入れ子にした［None of］グループに Z 条件を指定します。
n or more of。アイテムは指定した数の条件を満たす必要があります。
［All of］グループの場合にのみ、各条件が指定した文字数内に出現する場合を検索することができます。たとえば、次の条件グループでは、「Goodbye」という単語が「Hello」という単語の 20 文字以内に出現する場合を検索します。
テキスト文字列「You say Goodbye and I say Hello」は、「Hello」の最初の文字と「Goodbye」の最初の文字の間が 20 文字より少ないため、これらの条件と一致します。同様に、テキスト文字列「You say Hello and I say Goodbye」も、2 つの単語の終わりの間の文字数が 20 文字を下回るため、一致します。どちらの場合も、スペースが文字としてカウントされます。
メモ:
［within nn characters］近接検索を実行する場合は、同じ検索語を複数の条件で重複して使用しないように注意してください。たとえば、1 つ目の条件で「Fred」、「Sue」、「Bob」という名前を検索するように定義し、2 つ目の条件で「Joe」、「Bob」、「Sarah」を検索するように定義したとします。この場合、「Bob」の単一のインスタンスを含むアイテムが、これらの条件を満たすことになります。
［from the first condition］オプションを選択するのではなく、［in a sliding window］を選択できます。このオプションでは、指定した数の連続する文字列内で条件が一致する場合を探します。たとえば、「Goodbye」という単語が「Hello」という単語から連続した 20 文字内に出現する場合を検索する条件グループの場合、「You say Goodbye and I say Hello」は一致しません。「Goodbye」という単語の開始時点から「Hello」という単語の終了時点までが 23 文字あるためです。
