Adobe Acrobat Sign でのテキスト検索

概要

Acrobat Sign を使用すると、複雑な検索をおこなって、ユーザーの契約書内のコンテンツを検索できます。「管理」ページにある検索バーは、選択したコンテンツソースに対して指定された文字列と一致するすべてのトランザクションを返します。

  • 「自分の契約書」が表示されている場合は、自分のコンテンツが検索対象になります。共有アカウントが表示されている場合は、共有アカウントのコンテンツが検索対象になります。

以下のフィールドのコンテンツでは、トランザクションの作成/更新時にインデックスが作成されます。

  • タイトル - 契約書のタイトル。
  • メモ - 参加者が取った、他の人には見えない私的な契約書のメモ。
  • メッセージ - この参加者に表示されるメッセージのリスト(パブリックメッセージとプライベートメッセージを含む)。
  • 元のファイル名 - 契約書に関連付けられたアップロード済みファイルの元の名前。
  • 電子メール - 受信者(CC を含む)または送信者の電子メールアドレス。
  • 氏名 - 受信者(CC を含む)または送信者の氏名。
  • 役職名 - 受信者(CC を含む)または社内の送信者の役職名。
  • 会社名 - 受信者(CC を含む)または送信者の会社名または組織名。
  • 受信者グループ名 - 受信者が所属できる臨時の契約書グループ名。
  • テキストフィールドコンテンツ - フォーム内のユーザーが入力するテキストフィールドのコンテンツ。
  • 共有者の氏名 - 契約書の共有者の氏名。非共有の場合、これはユーザーの名前です。
  • 共有者の受信者グループ名 - 契約書の共有者の受信者グループ名。非共有の場合、これはユーザーの受信者グループの名前です。
  • 外部 ID - 送信者が契約書に割り当てた ID。任意の形式を使用できますが、通常は「<groupID>:<ID>」の形式です。 外部 ID は、契約書作成 API への呼び出しで渡されます。
  • 外部グループ ID - 送信者が契約書に割り当てたグループ ID。任意の形式を使用できます。通常、外部 ID のプレフィックスとして使用されます。外部グループ ID は、契約書作成 API への呼び出しで渡されます。外部グループ ID パラメーターを設定する場合は、外部 ID を設定する必要があります。
  • トランザクション ID - 作成時に Acrobat Sign によって契約書に割り当てられた ID。

テキスト検索の仕組み

文字列「A simple fish」を検索する場合

  • Acrobat Sign では、スペースを区切り文字として使用して文字列を「トークン化」します。上の文字列は、Asimplefish の 3 つのトークンに分割されます。
    • 文字列クエリの文字は、文字、数字、区切り文字の 3 種類のいずれかに属します。
    • 区切り文字として扱われる文字(空白以外)は、 ~ ` ! @ # $ % ^ & * ( ) - + = { } [ ] | \ . , : ; " ' < > ? / です。
      • ピリオド、コロン、アポストロフィは、そのシンボルの前後の文字が同じタイプの場合、トークンの一部として残ります。
      • クエリ文字列全体を囲む引用符は区切り文字ではなく、リテラル文字列値(語句)を指定します。
      • クエリ文字列内の引用符は区切り記号でありリテラル文字列値は指定しません
  • 大文字小文字の区別はなくなります。例:asimplefish
  • 検索では、各トークンのフルテキストをインデックス値と一致させようとします。
    • 契約書タイトル」のトークン化がより複雑になります(下記参照)。
  • 包括的」検索が使用され、この検索では、1 つ以上の検索フィールドで 1 つ以上のトークンに一致するすべての契約書が返されるデータセットに含まれます。
    • 返されたデータセットは、関連性スコアによってソートされ、最も関連性の高い検索結果が先頭に表示されます。

「契約書タイトル」フィールド

前述したように、主にコンテキスト区切り文字(明示的な文字ではなく)でトークン化するカスタマイズされたトークナイザーが追加されたため、「契約書タイトル」フィールドでは高度なトークン化が行われます。このカスタムトークナイザーは、次の点で標準とは異なります。

  • プレフィックストークン(最大 10 文字)が生成されます。プレフィックストークンは、任意の標準トークンの増分文字列です。例:標準トークンが fish の場合、増分トークンは ffifis、および fish です。
    • これにより、トークンの最初の文字から始まる部分的な文字列を検索できます。
    • 文字列の中間の一致は無視されます。例:rent の検索は apparently とは一致しません。
  • 英数字以外の文字でトークンを分割します。例:文字列 Super_Duper はトークン Super Duper を生成します。
    • 標準トークナイザーでは、アンダースコアは区切り文字ではありません
  • トークンを大文字と小文字の変化で分割します。例:文字列 PowerShot は、トークン PowerShot を生成します。
  • トークンを文字と数字の変化で分割します。例:文字列 XL500 は、トークン XL500 を生成します。
  • 各トークンから先頭または末尾の区切り文字を削除します。例:文字列 XL---42+'Autocoder は、トークン XL42Autocoder を生成します。
  • 各トークンの末尾から英語の所有('s)を削除します。例:文字列 Dave's は、トークン Dave を生成します。

標準トークナイザーとカスタムトークナイザーの組み合わせにより、完全トークン文字列(標準トークナイザーによる)とプレフィックストークン(カスタムトークナイザーによる)を検索できます。引き続き、区切り記号にまたがるプレフィックストークンは照合しません

例:My_NDA という名前の契約書がある場合

  • 標準のトークナイザーは、my_nda のようなトークンを生成します。
  • カスタムトークナイザーは、一連のトークンとして、mmynndnda、my_、my_n、my_nd、my_nda を生成します。

例 2:XL500 という名前の契約書がある場合

  • 標準のトークナイザーは、xl500 のようなトークンを生成します。
  • カスタムトークナイザーは、一連のトークンとして、xl500、x、xl、5、50、500、xl5、xl50 を生成します。

特殊なクエリ構文での検索

上記のセクションで説明したように、契約書の検索では、契約書の検索可能なすべてのフィールドの近似一致が実行されます。検索可能なフィールドコンテンツはトークン化され、そのトークンはクエリ時にクエリ文字列と照合されます。契約書の検索ではまた、これらのトークンに対して最大 10 文字のプレフィックス一致が実行されます。契約書に一致するトークンが 1 つ以上見つかった場合、その契約書が検索結果に表示されます。  検索結果は、関連性スコアによってソートされ、最も関連性の高い検索結果が先頭に表示されます。

ただし、フィールド値全体の一致、フィールド値からの語句の一致、特定のトークンを含まない契約書の検索、同時に複数のトークンを含む契約書の検索(語句ではない)は、特別な構文を使用しないと実行できません。Sign Generic Query Language(SGQL)は、特別な構文を必要とするこれらの機能に対する顧客のニーズに対応するために開発されました。

予約文字と予約語

SGQL には 7 つの予約文字があります。

*

(

\

"

'

これらの予約文字は演算子として使用され、検索クエリの言語機能を定義します。予約文字を正しく使用しないと、構文エラーが返されます。 

予約文字を検索クエリの通常の文字として使用するには、これらの文字をエスケープする必要があります。例えば、検索クエリー

\( \"bea\:u\*ful\"\\ \)

では、すべての予約文字がエスケープされ、通常の文字として扱われます。

SGQL には、演算子用の 3 つの予約語もあります。

AND

OR

NOT

演算子は大文字にする必要があります。演算子を検索クエリで通常のトークンとして使用するには、二重引用符で囲む必要があります。次に例を示します。

foo "AND" bar

語句一致

「通常の近似一致」クエリは、いずれかのトークンがフィールドに出現する場合に一致します(必ずしもすべてではない)。複数のトークンが同時に出現する必要がないため、トークンの順序は重要ではなくなります。

検索可能な 1 つ以上のフィールドの大文字と小文字を区別しない完全一致語句検索が必要な場合は、語句一致クエリを使用する必要があります。これにより、複数のトークンが同じフィールドに出現し、これらのトークンが引用符内で指定された順序で出現する場合に一致させることができます。

語句一致クエリの構文形式:

"<phrase_match_query>"

  または 

'<phrase_match_query>'

クエリ構文が語句一致クエリ構文の規則に従わない場合、検索では、検索可能なすべてのフィールドで通常の近似一致クエリが実行されます。

例えば、次のクエリ

"Study Group"

は、検索可能なフィールドのいずれかに「study group」という語句を含む契約に一致します。このクエリでは、「study - group」という語句は一致しません。これは、「Study Group」と比較した場合、大文字と小文字を区別しない完全一致のフレーズではないためです。

語句の一致は、検索クエリ内の任意の場所に置くことができます。例えば、

title: ( math AND "course materials" AND "study group" )

は、タイトル「Course materials for MATH 101 Study Group」に一致します。このタイトルには、キーワード「MATH」と語句「Course Materials」および「Study Group」が含まれているためです。

フィールド名のプレフィックス

フィールド名のプレフィックスクエリは、ユーザーの契約書の特定のフィールドを 1 つのみ検索する場合に使用する必要があります。

フィールド名のプレフィックスクエリには、フィールド名のプレフィックスの後に検索クエリが続く必要があります。フィールド名のプレフィックスクエリの構文形式:

<field_name>:<query>

フィールド名のプレフィックスは、トークンの前、またはクエリの括弧で囲まれた部分の前に表示できます。例えば、次の検索クエリ

title: ( Hello AND "Beautiful World" AND "My World" )

ではすべてのトークンが「契約書タイトル」フィールドと照合されます。

次の検索クエリ

title: Hello AND "Beautiful World" AND "My World" 

では単語「Hello」のみがフィールド名のプレフィックスを含み、この単語のみが契約書タイトルフィールドと照合されます。残りの単語と語句は、検索可能なすべてのフィールドと照合されます。

<field_name> を指定しない場合、語句一致でサポートされているすべてのフィールドが照会されます。指定した場合は、<field_name> フィールドのみが照会されます。 

クエリ構文がフィールド名のプレフィックスクエリ構文の規則に従わない場合、契約書の検索では、クエリ全体が検索クエリとして使用され、検索可能なすべてのフィールドが検索されます。 

フィールド名のプレフィックスクエリの例:

title: ( Hello World )

では、契約書のタイトルを含むフィールドに対してのみ、検索が実行されます。

フィールド名のプレフィックスクエリでサポートされるプレフィックスのリストを次に示します。フィールド名のプレフィックスでは、大文字と小文字が区別されます。

フィールドコンテンツ

 文字列クエリフィールド名のプレフィックス

フィールドコンテンツの説明

タイトル

title*

契約書のタイトル。

注意

note

参加者が取った、他の人には見えない私的な契約書のメモ。

メッセージ

message

この参加者に表示されるメッセージのリスト(パブリックメッセージとプライベートメッセージの両方を含む)。

元のファイル名

originalFileName

契約書に関連付けられたアップロード済みファイルの元の名前。

電子メール

email**

受信者(CC を含む)または送信者の電子メールアドレス。

氏名

fullName***

受信者(CC を含む)または送信者の氏名。

役職名

jobTitle

受信者(CC を含む)または社内の送信者の役職名。

会社名

companyName

受信者(CC を含む)または送信者の会社名または組織名。

受信者グループ名

recipientGroupName

受信者が所属できる臨時の契約書グループ名。

テキストフィールドコンテンツ

textFieldContent

フォーム内のユーザーが入力するテキストフィールドのコンテンツ。

共有者の氏名 sharerFullName 契約書の共有者の氏名。非共有の場合、これはユーザーの名前です。
共有者の受信者グループ名 sharerRecipientGroupName 契約書の共有者の受信者グループ名。非共有の場合、これはユーザーの受信者グループの名前です。
外部 ID

externalId

送信者が契約書に割り当てた ID。任意の形式を使用できますが、通常は「<groupID>:<ID>」の形式です。外部 ID は、契約書作成 API への呼び出しで渡されます。

外部グループ ID

externalGroupId

送信者が契約書に割り当てたグループ ID。任意の形式を使用できます。通常、外部 ID のプレフィックスとして使用されます。 外部グループ ID は、契約書作成 API への呼び出しで渡されます。外部グループ ID パラメーターを設定する場合は、外部 ID を設定する必要があります。

トランザクション ID agreementId 契約書の作成時に Acrobat Sign によって契約書に割り当てられた ID。

下位互換性を確保するため、一部のフィールド名のプレフィックスには、元のフィールド名のプレフィックスと同じ機能を持つエイリアスがあります。これらのエイリアスは廃止され、最終的に削除されます。

  * フィールド名プレフィックス「name」は「title」の代わりに使用できます。

 ** フィールド名プレフィックス「participantEmail」は「email」の代わりに使用できます。  

*** フィールド名プレフィックス「participantName」は「fullName」の代わりに使用できます。

ワイルドカード

ワイルドカード(アスタリスク *)を使用すると、トークン内のプレフィックスの一致の後に無制限の文字数を続けることができます。ワイルドカードの拡張は、実行時に発生する負荷の高い操作となるため、この機能を使用するには、次の構文規則に従う必要があります。

  • 先頭のワイルドカードは使用できません。
  • トークンの途中にワイルドカードを使用することはできません。
  • ワイルドカード拡張演算子を持つトークンには、フィールド名のプレフィックスが必須です。
  • 1 つのクエリでワイルドカード演算子を複数回使用することはできません。
  • ワイルドカード拡張を含むクエリでは、実行時間が 5 秒を超えるとタイムアウトエラーが返されます。

例えば、次のクエリ

title:myh*

では次のタイトルフィールドのトークンと一致します。

myhost

および

ワイルドカード拡張は負荷の高い操作です。誤って使用すると、多くのシステムリソースを消費し、検索結果が表示されるまで長い時間を要することがあります。このような問題を回避するために、SGQL にはワイルドカードの使用に関する制限があり、最も負荷の高い、リソースを消費するユースケースは排除されています。トークンがより具体的であるほど、検索がより効率的になります。特定の単語や語句の検索は、常に、ワイルドカードを使用した検索よりも効率的です。

ブール式

SGQL では、ブール演算子 AND、OR、NOT のほか、括弧を使用してこれらの演算子をグループ化できます。演算子は大文字にする必要があります。

OR 演算子は常にトークン間で暗黙的に使用されます。例えば、

foo bar

foo OR bar

と同じです。明確な理由から OR 演算子を含める場合を除き、OR 演算子を指定する必要はありません。

NOT 演算子は、NOT の直後のトークンにのみ適用されます。NOT 演算子を複数のトークンに適用するには、これらのトークンを括弧で囲む必要があります。

次の表は、ブール式が評価される順序を示しています。

順序

検索コマンド

1 括弧内の式
2 NOT 句
3 OR 句
4 AND 句

次の表は、グループ化演算子(括弧)が指定されていない場合に、演算子の優先順位を説明する、意味的に同等のクエリの例です。

検索クエリ 同等の書き換えられた検索クエリ コメント
foo AND bar baz foo AND ( bar OR baz ) 演算子 OR は暗黙的であり、明確な理由から追加する場合を除き、使用しないでください。 
foo NOT bar baz foo OR ( NOT bar ) OR baz 演算子 NOT は、次に続くトークンまたはクエリの括弧内の部分に適用されます。
foo NOT bar baz AND xyz ( foo OR ( NOT bar ) OR baz ) AND xyz
title: ( Hello AND "Beautiful World" "My World" ) title:Hello AND ( title:"Beautiful World" OR title:"My World" ) フィールド名のプレフィックスは、次に続くトークンまたはクエリの括弧内の部分に適用されます。
title: Hello AND note: "Beautiful World" "My World" title:Hello AND ( note:"Beautiful World" OR "My World" )  「My World」という語句は、検索可能なすべてのフィールドと照合されます。 

 Adobe

ヘルプをすばやく簡単に入手

新規ユーザーの場合

Adobe MAX 2025

Adobe MAX Japan
クリエイターの祭典

2025 年 2 月 13 日
東京ビッグサイト