Help:CirrusSearch/ja

で情報を見つけるための最も速い方法は直接探すことです. ページにボックスがあります.

CirrusSearch（シーラスサーチ）は MediaWiki の拡張機能で、既定の MediaWiki 検索よりも強化された検索機能を提供するためにElasticsearchを使っています. ウィキメディア財団は、ウィキメディアプロジェクト群のすべてのサイトにシーラスサーチを使っています. このページではシーラスサーチの機能を説明します. 疑問がここで解消しない際には遠慮なくトークページでお尋ねください. 誰かがお答えします.

MediaWiki 拡張機能の情報は、 を参照してください.

ウィキデータでの使用については、をご参照ください.



使い方
キーワード（単語）やキーフレーズ（句）を入力し、Enter や Return キーを押します. あるいは、虫眼鏡アイコン、または「検索」ボタン、（設定により）「表示」ボタンをクリックしてください. 入力文字と同じ名前のページが存在すれば、直接そのページを表示します. 見つからない場合には、ウィキのすべてのページを検索し、検索項に合致する記事の一覧を表示するか、合致する記事が存在しないことを知らせます.

検索ボックスに入力せずに「」ボタンをクリックすると、追加の検索オプションがある「Special:Search」に移動します（この検索オプションは、検索結果の画面でも常に利用できます）

検索対象を特定の 名前空間、たとえば   ページのみから探すように指定すると役に立つことがあります. そうするには、その名前空間のチェックボックスをオンにします.



改良点
CirusSearch は、標準の MediaWiki 検索と比較して、主に以下の3つの改良点があります:


 * さまざま言語での検索への対応を改善
 * 検索インデックスの更新の高速化. これにより記事に加えられた変更が大幅に高速に検索結果に反映されるようになります.
 * テンプレートの展開. つまり、テンプレートからすべての内容が検索結果に反映されるようになります.



検索インデックスの更新頻度
検索インデックスへの更新はほぼリアルタイムで適用されます. ページを変更するとすぐに、それが検索結果に現れるはずです. テンプレートへの変更は、そのテンプレートを参照読み込みしている記事に反映されるまでに数分かかるはずです. テンプレートへの変更はジョブ・キューを使用するため、パフォーマンスは変化する場合があります. 記事に対して空編集を行うことで強制的に反映させることが可能ですが、うまくいっていれば特に必要ないはずです.



検索候補の表示
検索ボックスに入力するとドロップダウンで表示される候補のページは、記事の品質の大まかな評価順に並んでいます. その候補の選別には、内部リンクされている数、ページサイズ、外部リンクの数、見出しの数、リダイレクトの数が考慮されます. 検索候補はスキップでき、クエリは検索結果ページに直接移動します. クエリの前に、半角チルダ を追加してください. 例えば、"~Frida Kahlo"です. 検索サジェスチョンはその後も表示されますが、Enter キーを押すと検索結果ページへ飛びます.

言語によっては、アクサンやダイアクリティカルマーク（発音区別符号）がオンになります. 詳細は言語ごとに特定されます.



全文検索
「全文検索」は「インデックス検索」です. すべてのページはウィキ・データベースに格納されており、リダイレクトページではないページにある全ての単語は、実質、そのウィキの全文をインデックスにした検索データベースに格納されています. それぞれの知られた単語はそれが見つかったページの一覧としてインデックス化されているので、ある単語の検索は、単一レコードを調べるのと同じくらい速いです. さらにいかなる文言の変更も数秒以内に検索インデックスに反映されます.

ウィキの「全文検索」のインデックスは多数あり、必要な検索のさまざまなタイプに対応しています. ウィキテキスト全体に対して、インデックスを個別の目的ごとに付与し、それに基づいて解析するため、あらゆる方法で柔軟に利用できます. インデックスの例をあげます.


 * 「補助」テキスト ‐ HTML属性 class=searchaux で分類された、ハットノートやキャプション、目次および任意のウィキテキストが含まれます.
 * 「Lead-in」テキスト ‐ ページの上部と最初の見出しの間にあるウィキテキストです.
 * 「カテゴリ」テキスト ‐ ページ最下部の一覧をインデックス化します.
 * テンプレートがインデックス化されます. テンプレートの参照読み込みされた単語が変更された場合、それを参照読み込みしているすべてのページが更新されます. （ジョブキューによっては時間がかかります. ）テンプレートが呼び出すサブテンプレートが変更された場合、インデックスが更新されます.
 * FileやMediaの名前空間に格納されたドキュメントの内容も、インデックス化するようになりました. 数千のフォーマットが認識されます.

この機能は多言語で提供されていますが、すべての言語での対応が望まれています. 現在サポートしている言語の一覧は外部サイトelasticsearch.orgにあります. パッチや要望の連絡先は投稿の説明文書を参照してください. Elasticsearch が対象としない言語は、外部第三者のオープンソースなライブラリを使って対応します.

CirrusSearchはクエリを最適化して実行します. 結果のタイトルは関連性によって重み付けされ、20件ずつ検索結果ページに出力します. 記事から抜粋したり、検索項を太字で強調したりします.

検索結果には、しばしばさまざまな予備的な報告が付いています. 「クエリの修正候補」（スペル修正）を示す場合や、どうしても結果が見つからなかった場合には「○○に対する検索結果」（クエリの修正）と（ユーザー指定のクエリの）「代わりに○○を検索」と表示します.

その他の検索機能の要素：


 * ナビゲーション提案はリンク元の数によって並べ替えられます.
 * チルダ文字 から始めると、ページランキングも維持するような方法でナビゲーションや提案を無効化します.
 * 文字のスマートマッチング ‐ 外字（キーボードにない文字）をキーボード文字に正規化します（または「折りたたむ」）.
 * マッチする単語や句は検索結果のページにおいて太字で強調されます. 強調表示器が見た目を分析する一方で、検索インデックス分析器が実際にページを見つけるので、両者が100％同期しない可能性があります（特に正規表現の場合）. 強調表示器がインデックス分析器よりも正確に一致することも不正確なこともあります.



単語、句、および修飾子
基本的な検索項は、単語（ワード）または「引用符〈"〉で囲んだ句（フレーズ）」です. 詳細は言語ごとに、特にスペースを使わない言語では様々ですが、検索は典型的には以下のものを「単語」と認識します：


 * 一連の数字
 * 一連のレター（訳注：数字、記号ではない文字）
 * txt2regex のように、レターと数字の間で遷移する部分語（サブワード）
 * キャメルケースを使ったcompoundName（複合語）内の部分語

「ストップワード」はあまりにも一般的などの理由で無視されます (英語の a、the 他). ストップワードの一覧は言語ごとに固有であり、またストップワードのない言語もあります. 指定した検索項は（ページ上に描画された）コンテンツとマッチさせます. そうではなくウィキテキストとマッチさせるには、 insource 検索パラメータを使います（下記の節参照）. それぞれの検索パラメータは独自のインデックスを持ち、指定された項を独自の方法で解釈します.

単語、句、パラメータ、およびパラメータへの入力の間のスペーシングには、ホワイトスペース文字およびグレースペース文字をいくつでも含めることができます. 「グレースペース文字」とはアルファベットではないすべての文字 ~!@#$%^&_+-={}|[]\:";'<>?,./ のことです. グレースペース文字とホワイトスペース文字の混合文字列は、「グレースペース」であり、大きなひとつの単語境界として扱われます. グレースペースはインデックスを作成し、クエリを解釈する方法です.

例外が2件あります. 1)「 embedded:colon 」 は1単語（埋め込まれたコロンはレターとして扱われます）. 2）「 1,2,3 」のように埋め込まれたカンマ「, 」は数字として扱われます. グレースペース文字は、クエリ構文により、修飾子の文字として解釈できる場合を除き無視されます.

修飾子とは「 ~ * \? - " ! 」のことです. 構文のどの位置にあるかにより、項、パラメータ、クエリ全体のいずれかを修飾します. 単語および句を修飾するものは、ワイルドカードと近似(proximity)検索、あいまい(fuzzy)検索です. パラメータごとに修飾子が異なる場合もあるものの、一般原則は次のとおりです：


 * fuzzy-word または fuzzy-phrase 検索はチルダ  文字（および程度を示す数字）を接尾辞に使用することができます.
 * チルダ  文字をクエリの最初の項の接頭辞に使うと、いかなる可能なナビゲーションでもなく検索結果を表示することを保証します.
 * 単語内のワイルドカード文字は、1文字に対しては (エスケープされた) 疑問符 \? を、ゼロ文字以上に対してはアスタリスク文字 * を使うことができます.
 * 真理・論理は AND および OR を解釈できますが、 パラメータはできません. AND および OR 演算子は現在のところ、伝統的な真理・論理のやり方で機能しないことに注意してください！ 詳細は 論理演算子 を参照してください.
 * 真理・論理は接頭辞として項に与えられた - や ! を理解し、項の通常の意味を「一致する」match から「除外する」exclude に入れ替えます.


 * 単語を引用符で囲むと、「完全一致句」検索になります. パラメータに対して、複数の単語の入力を区切るためにも必要とされます.
 * 語幹解釈 (stemming) は自動処理されますが、無効化するには「完全一致句」検索を使います.

句検索は、検索エンジンにさまざまなヒントを与えて実行します. そのヒントの与え方にはそれぞれ副作用があり、単語の組み合わせに対する検索結果の許容範囲が異なります. greyspace、camelCase、あるいはtxt2numberに対するヒントは：


 * words-joined_by_greyspace(characters) または wordsJoinedByCamelCaseCharacters を与えると words joined by …… characters が、そのままの形式またはグレースペース形式で見つかります.
 * txt2number は または にマッチします.
 * ストップワードはgrey_space またはcamelCase 句の境界文字（周辺）に対して有効化されます. the 、 of 、および a を使う例では、テキスト 内で the_invisible_hand_of_a が にマッチします.

普遍的に知られていない単語が句で無視されると、「○○の代わりに検索」のレポートが発動します.

以下の種類の句マッチングのそれぞれのものは、前のものの許容範囲を広げます：


 * 「引用符で囲んだ」「完全一致句」はグレースペース（でのマッチ）を許容します. 「 "exact_phrase" 」あるいは「 "exact phrase" 」を与えると「 」にマッチします.
 * greyspace_phraseにより語幹解釈およびストップワードのチェックが始まります.
 * 「 CamelCase 」を与えると、すべて小文字を許容して、追加で「 」がマッチします. なぜならば、CirrusSearchはマッチングにおいてケースセンシティブではない（大文字と小文字を区別しない）からです. CamelCase マッチングはすべての言語に対して有効ではないことに注意してください.

パラメータによってはグレースペース句を解釈するものの、「 」などのようなその他のパラメータは、通常の「引用符で囲んだ句」のみを解釈します.

語幹解釈は大文字と小文字を区別しない（ケース・インセンシティブ）ことにご注意ください.

「完全一致句」検索は embedded:colon のように埋め込まれたコロンの文字をレターとして解釈しましたが、 embedded_underscore のように埋め込まれたアンダースコアの文字はレターとして解釈しなかったことに注意してください. 数字の羅列内の半角カンマ, の文字にも似たような事象が発生します.

CirrusSearchは「完全一致句」の文脈（insource パラメータの文脈を含む）で を与えると、 、 、あるいは にはマッチしませんが、 にだけはマッチします.

それ以外は、 CirrusSearch に対して単語はレター、数字、あるいはその2つの組み合わせであり、大文字小文字は無関係であることを覚えておいてください.

一般的な単語検索では空白文字を採用して語幹解釈を積極的に行い、同じ単語がグレースペース文字またはキャメルケースで結合されているときには、句および部分語に対して積極的になります.

"of" あるいは "the" のような一般的な単語がグレースペース句に含まれているときには、これらは無視され、より積極的にマッチするようになります.

A greyspace_phrase search term, or a camelCase, or a txt2number term, match the signified words interchangeably. You can use any of those three forms. Now camelcase matches camelCase because Search is not case sensitive, but camelCase matches camelcase because camelCase is more aggressive. Like the rest of Search, subword "words" are not case-sensitive. By comparison the "exact phrase" is greyspace oriented and ignores numeric or letter-case transitions, and stemming. "Quoted phrases" are not case sensitive.

From the table we can surmise that the basic search parser_function -"parser function" is the sum of the basic searches  and.

数字で問い合わせをすると、以下のことがわかるでしょう：


 * Plan9 あるは Plan_9 は以下のいずれにもマッチします： 、 、 、 、
 * "plan9" は  にのみマッチします（大文字と小文字は区別しない）
 * Plan*9 は  あるいは  にマッチします.

アスタリスク * ワイルドカードはレンダーされた単語内のレターおよび数字の文字列にマッチしますが、開始文字には決してマッチしません. 1文字以上が * 文字の前になければなりません.


 * * が数字群にマッチするとき、コンマは数字の一部とみなされますが、小数点はグレースペース文字とみなされ、2つの数字群に区切ります.
 * 「完全一致句」の中では、 * はワイルドカード文字ではなく、グレースペース文字として扱われ、したがって単語を区切ります.

\? ワイルドカードは1つのレターまたは数字を表します; *\? も受け入れられますが、 \?* は認識されません.

ワイルドカードは基本的な単語、句、およびinsource検索に対するものであり、（いくつかの）高度な正規表現検索（後述）の代替にもなるかもしれません.

単語または句のあとにチルダ ~ 文字を置くとあいまい検索が有効化されます.


 * 句(phrase)に対しては、完全一致句(exact phrase)よりも、近似な(proximal)単語群が許容されるので近似(proximity)検索と呼ばれます.
 * 例えば、 "exact one two phrase"~2 は にマッチします.
 * 単語に対しては、余分な文字または変更された文字を意味します.
 * 句に対しては、あいまい検索は余分な単語をいくつ含めて良いか示す数が必須ですが、単語に対しては、あいまい検索は小数を持つことができ、 word~0.5 （ word~.5 ）を既定とし、この場合には最大で2つのレターを入れ替え、変更、または追加できるものの、先頭の2つのレターは常に除外します.
 * 近似的な句に対しては、大きな数字を適用できますが、「費用のかかる」（遅い）検索になります.
 * wordに対しては、 word~2 が編集距離 2 で最もあいまい（既定）、 word~1 のときに最もあいまいさが小さく、そして word~0 はまったくあいまいでなくなります.

For the closeness value necessary to match in reverse (right to left) order, count and discard all the extra words, then add twice the total count of remaining words minus one. (In other words, add twice the number of segments). For the full proximity algorithm, see Elasticsearch slop.

引用符は語幹解釈をオフにしますが、 "but appending"~ のようにチルダを付加すると語幹解釈を再開します.

insource検索
Insource検索は、あるページでレンダリングされたひとつの「単語」を見つけるために使用することもできますが、あらゆる句を見つけるのに役立ちます - MediaWikiマークアップ（別名ウィキコード）を含め、リダイレクトを除くあらゆるページを検索することができます. ここでいう「句」は、グレースペースを完全に無視します. 例えば、 insource: "state state autocollapse" は にマッチします.

Insource complements itself. On the one hand it has full text search for any word in the wikitext, instantly. On the other hand it can process a regexp search for any string of characters. Regexes scan all the textual characters in a given list of pages; they don't have a word index to speed things up, and the process is interrupted if it runs for more than twenty seconds. 正規表現はクエリの最後に実行され、不必要な文字レベルのスキャンを制限するようになっており、あらゆる正規表現クエリはスキャンする必要がある文書の数を制限するために他の検索項を含めるべきです. しばしば正規表現クエリ insource:/arg/ に追加する最善の候補となるのは insource:arg です. ここで、 arg は同一（かつワイルドカードを使わない）です.

正規表現の構文は insource: スペースなし、それから /regexp/ です（他にスペースを禁じるパラメータはありません. insource:/regexp/ 以外のパラメータはコロンのあとにスペースを許容します. ）

Insourceインデックス検索と正規表現検索の役割は多くの側面で似ています：


 * どちらもウィキテキストのみを検索します.
 * どちらも参照読み込みによって「ソースされている」ものを見つけません.
 * どちらも語幹解釈、あいまい、あるいは近似検索をしません.
 * どちらも最小限の結果を求め、どちらも他の条項を伴うとより速く動作します.

しかしインデックス化された検索はすべてグレースペースを無視します; ワイルドカードはグレースペースにマッチしないので、正規表現が「任意かつすべて」の文字の完全一致文字列、例えば連続する2つのスペース、を見つける唯一の方法です. 正規表現は、文字通りの文字列に簡単にマッチングさせたり（基本的な、初心者向けの使い方）、メタ文字表現によるマッチングを可能にしたりする（高度な使い方）、全く異なる分類のウィキ上の検索ツールです. 後述の#正規表現検索をご参照ください.



接頭辞と名前空間
検索では、名前空間の項は初期の検索ドメインを指定するために機能します. ウィキ全体を検索する代わりに、既定では標準名前空間（標準空間）を検索対象とします.

検索ボックスのクエリからは単一の名前空間のみ設定できます. 接頭辞パラメータの、最初もしくは最後の項です.

各検索結果ページ、Special:Searchの上部に現われる検索バーにある高度な検索枠から2個以上の名前空間を入力して検索することができます. ここで検索ドメインを、名前空間のプロファイルとして、設定することができます. このときの名前空間の一覧は、将来の検索時に1ページ目に表示され、検索結果の検索対象ドメインがわかります. この設定を解除するには、既定の名前空間 (丸カッコ内に表示) を選択、「記憶」を選んで「検索」ボタンを押します.

The search bar graphically sets and indicates a search domain. "Content pages" (mainspace), "Multimedia" (File), "Everything" (all plus File), "Translations", etc., are hyperlinks that can activate the query in that domain, and then indicate this by going inactive (dark). But the query will override the search bar. 名前空間または prefix がクエリで使われたとき、検索バーのアクティベーションと表示は誤解を招くかもしれないので、検索バーと検索ボックスは検索ドメインを設定する相互排他的な（補完的でない）方法です.

名前空間項は検索バーより優先され、prefix 項は名前空間より優先されます.

名前空間の名前を入力するか、  を入力するか、標準空間に対して     コロンを入力します. All は File 名前空間を含みません. File はコモンズに保持されている PDFのようなメディアコンテンツを含み、これはすべてインデックス化されていて検索可能です.

File が関係するとき、名前空間修飾子  が効果を持ち、それ以外のときは無視されます.

名前空間のエイリアス（別名）は受け入れられます.

検索パラメータと同様に、 local および all は小文字でなければなりません. 名前空間の名前は大文字と小文字を区別しません（ケース・インセンシティブ）.

The prefix: parameter matches any number of first-characters of all pagenames in one namespace. When the first letters match a namespace name and colon, the search domain changes.

Given a namespace only, prefix will match all its pagenames. Given one character only, it cannot be - dash or ' quote or " double quote. The last character cannot be a colon.

For pagenames that match, their subpage titles match by definition.

The prefix parameter does not allow a space before a namespace, but allows whitespace before a pagename.

The prefix parameter goes at the end so that pagename characters may contain " quotation marks.

The Translate extension creates a sort of "language namespace", of translated versions of a page. But unlike namespace or prefix, which create the initial search domain, the inlanguage parameter is a filter of it. (See the next section.)



検索インデックスからコンテンツを除外する
コンテンツを検索インデックスから除外するには を加えます. すると CirrusSearch は検索インデックスで当該のコンテンツを無視する指示を受けます（さらに詳しくはを参照してください. ）

さらにコンテンツは  を追加することによって、補助的な情報としてマークすることができます. これによって CirrusSearch に、そのコンテンツをメインテキストフィールドから、検索および抜粋表示についての優先度が低い補助フィールドへ移動させるよう指示します. この区別は、画像のサムネイルの解説、「関連項目」セクション、などの項目に対して使われます.

フィルター
A filter will have multiple instances, or negated instances, or it can run as a standalone filtering a search domain. A query is formed as terms that filter a search domain.

Adding another word, phrase, or parameter filters more. A highly refined search result may have very many Y/N filters when every page in the results will be addressed. (In this case ranking is largely irrelevant.) Filtering applies critically to adding a regex term; you want as few pages as possible before adding a regex (because it can never have a prepared index for its search).

A namespace is a specified search domain but not a filter because a namespace will not run standalone. A prefix will negate so it is a filter. The search parameters below are filters for which there may be multiple instances.

Insource (covered above) is also a filter, but insource:/regexp/ is not a filter. Filters and all other search parameters are lowercase. (Namespaces are an exception, being case insensitive.)



タイトル内、カテゴリ内
単語および句の検索は、ページのタイトルとマッチし、ページ下部のカテゴリ欄ともマッチします. しかし、これらのパラメータで、タイトルのみ またはカテゴリのみを選択することができます.
 * cow*
 * タイトルまたは本文が cow から始まる単語を含む記事を見つけます
 * intitle:foo
 * タイトルが foo を含む記事を見つけます. foo に対する語幹解釈が有効化されています.
 * intitle:"fine line"
 * タイトルが fine lineを含む記事を見つけます. 語幹解釈は無効化されています.
 * intitle:foo bar
 * タイトルが foo を含み、タイトルまたは本文が bar を含む記事を見つけます.
 * -intitle:foo bar
 * タイトルが foo を含まず、タイトルまたは本文が bar を含む記事を見つけます.
 * incategory:Music
 * Category:Music に属する記事を見つけます
 * incategory:"music history"
 * Category:Music_history に属する記事を見つけます
 * incategory:"musicals" incategory:"1920"
 * Category:Musicals および Category:1920 の両方に属する記事を見つけます
 * -incategory:"musicals" incategory:"1920"
 * Category:Musicals には属さないが、 Category:1920 には属する記事を見つけます

Intitle および incategory は古い検索パラメータです. Incategory はもはやいかなるサブカテゴリも自動的に検索しませんが、複数のカテゴリページ名を手動で追加することができます.

以降、 intitle に対して正規表現検索がサポートされています：
 * intitle:/regex/, intitle:/regex/i

#正規表現検索で書かれているすべてのことは、警告を含めて、これらの検索に対しても有効です.

Deepcategory
詳細カテゴリ検索ではカテゴリおよびすべての下位カテゴリが検索対象です. ツリーの深さは現在5段階（設定可能）、カテゴリ数は256個（設定可能）でそれぞれ制限されています. ディープサーチはWDQSのSPARQLカテゴリサービスを使用します. キーワードはdeepcategory またはdeepcat です. 例:


 * deepcat:"musicals"
 * Category:Musicalsまたはいずれかの下位カテゴリにある記事を探す

以前そのパラメータを実装していた DeepCat ガジェットは2020年1月に廃止されました.

いくつかの deepcat 検索は不完全な結果を返すことに注意してください. 詳細はバグ を参照してください.

Linksto
Linksto はリンク先のコンテンツではなく名前で指定した内部リンクを探します. 入力はカノニカルで、大文字と小文字を区別する（ケース・センシティブな）、ページの名前です. レターケース（大文字か小文字か）にいかなる改変も加えずに、コンテンツページのタイトル行に正確にマッチしなければなりません. (例えばのように、{ {FULLPAGENAME}}とマッチしなければなりません. )

Linksto はリダイレクトを探しません. テンプレートによって作られたときでも、[ [wikilinks]]のみを探します. URL がたとえ内部ウィキリンクであっても、それにより生成されたリンクは探しません.

"Help:Searching"や"H:S"が"Help:Cirrus Search"に対するリダイレクトである場合、内部リンクすべてを見つける方法は以下のとおりです：
 * 1) linksto: "Help:Cirrus Search"
 * 2) linksto: Help:Searching
 * 3) linksto: H:S

は"CirrusSearch"に言及しているけれど、内部リンクされていない記事を見つけます.

Hastemplate
でテンプレートの使用を指定できます. カノニカルなページ名を入力すると、そのテンプレートのすべての使用例を見つけますが、そのテンプレートへのリダイレクトのうちいずれかのページ名を使うとその名前のみを見つけます. 名前空間の別名は受け入れ、大文字化は完全に無視され、リダイレクトを見つけ、すべてがひとつの名前検索に入ります. （比較 boost-template 既定の名前空間なし; linksto 名前空間名の別名なし、大文字小文字を区別、リダイレクトなし; intitle リダイレクトなし. ）

Hastemplate finds secondary (or meta-template) usage on a page: it searches the post-expansion inclusion. This is the same philosophy as for words and phrases from a template, but here it's for templates from a template. The page will be listed as having that content even though that content is not seen in the wikitext.


 * hastemplate: "quality image", finds "Template:Quality image" usage in your default search domain (namespaces).
 * hastemplate: portal:contents/tocnavbar, finds mainspace usage of a "Contents/TOCnavbar" template in the Portal namespace.

For installations with the Translate extension, hastemplate searches get interference wherever Template:Translatable template name wraps the template name of a translatable template. Use insource instead.

Inlanguage
inlanguage は翻訳拡張機能のインストールとの併用では、高度な検索やページカウントにとって重要です.


 * inlanguage: 言語コード

の指定により、検索結果をその言語に限定します.

例えば


 * そのウィキにあるすべての日本語ページを数えるには
 * all: inlanguage: ja


 * ヘルプ名前空間にあるページでドイツ語とスペイン語を除くには
 * help: -inlanguage: de -inlanguage: es


 * 英語が基本言語であるときに、翻訳を無視するには、次を追加
 * inlanguage:en

Contentmodel
contentmodel: キーワードにより、検索範囲を特定のコンテンツモデルのページに制限することができます. Content handlersの使えるモデルを示します. 例：


 * JSON ページのみ表示：
 * contentmodel:json

subpageof
下位ページを検出.
 * subpageof: 親ページ

例


 * CirrusSearch の下位ページをすべて検出.
 * subpageof:CirrusSearch


 * 親ページ名にスペースが含まれる場合は二重引用符を使う.


 * subpageof:"Requests for comment"

Articletopic
The articletopic: keyword allows filtering search results by topic. For possible topics see. E.g. articletopic:books will filter the search results to articles about books. articletopic:books|films will filter to articles about books or films. articletopic:books articletopic:films will filter to articles which are about both books and films.

Only mainspace articles belong into topics, and topics are only available on Wikipedias. Unlike other filters, articletopic also does page weighting: articles which are a stronger match for a topic will be higher in the search results (while articles which aren't about that subject at all will be removed from the result set completely).

Topic models are derived via machine learning from ORES. Any given article receives a score on dozens of different topics, and therefore may appear under different keywords. For instance, the article on Albert Einstein may appear as a "physics" article and a "biography" article. All Wikipedias have scores available -- some have local-language topic models that have coverage on all articles. Other languages do not have local ORES models, and are using English-language scores assigned to articles in the local language that also exist in English Wikipedia. The languages with such "cross-wiki" scores do not have 100% coverage -- depending on the language, it may only be something like 60% of articles that have topics available.

Topic-related search data is updated weekly, so recently created articles might not show up in topic-based search queries.

Pageid
pageid: キーワードは検索結果を指定したページIDの集合に制限します. これは手動検索ではあまり役に立ちません; ページの集合が指定した検索条件の集合にマッチするかどうかソフトウェアツールによって確認（例えば、キャッシュされた検索結果の再検証）をするために使うことができます.



ページの重み付け
Weighting determines snippet, suggestions, and page relevance. The normal weight is one. Additional weighting is given through multipliers.

クエリがただの単語群である場合、単語群にマッチするページは与えられた増幅（ブースト）の順序です. 任意の明示的な句を検索に追加するか、または特定の他の追加をすると、この「prefer phrase」機能は適用されません.

Morelike

 * morelike:page name 1|page name 2|...|page name n
 * 指定した記事と文章がもっとも似たものを探す.
 * morelike:wasp|bee|ant
 * Find articles about stinging insects.
 * morelike:template:search|template:regex|template:usage
 * Find templates about regex searching for template usage on the wiki.

morelike は「欲張りな」キーワードで、つまりは他の検索クエリと組み合わせることができません. 他の検索クエリを使いたい場合は、 morelikethis を検索で使ってください：


 * morelikethis:bee hastemplate:"featured article"
 * bees に関する記事で "featured article" テンプレートもあるものを見つけます.

morelike: クエリは入力記事で複数の単語を選ぶことによって機能し、選択された単語でクエリを実行します. 動作方法を調整するには、検索結果の URL に以下のパラメータを追加します:

これらの設定を永続化するには システム メッセージ で   をオーバーライドしてください.
 * cirrusMltMinDocFreq : 考慮すべき項に必要とされる（シャード毎の）文書の数の最小値.
 * cirrusMltMaxDocFreq : 考慮すべき項を持つ（シャード毎の）文書の数の最大値.
 * cirrusMltMaxQueryTerms : 考慮する項の数の最大値.
 * cirrusMltMinTermFreq : 考慮すべき項の文書への入力における出現回数の最小値. 小さいフィールド ( title ) に対してはこの値は1にすべきです.
 * cirrusMltMinWordLength : 考慮すべき項の長さの最小値. 既定値は 0.
 * cirrusMltMaxWordLength : 単語の長さの上限値. これを超える単語は無視される. 既定値は制限なし (0).
 * cirrusMltFields (コンマで区切った値のリスト): これらをフィールドとして使用. 許容フィールドは title 、 text 、 auxiliary_text 、 opening_text 、 headings 、 all.
 * cirrusMltUseFields ( | ): 使用するフィールドデータを限定. 既定値は : システムはクエリを構築するために   フィールドのコンテンツを抽出する.
 * cirrusMltPercentTermsToMatch : 一致する項のパーセント. 既定値は 0.3 (30 %)
 * 例:

Prefer-recent
クエリの任意の位置に prefer-recent: を追加するとページ順位付けの規則において、最近編集された記事に通常よりもやや大きく重みを付けます. Prefer-recent は既定の  並べ替え順を使用しているときのみ適用されます.

既定では、スコアを 60% のみ、160日という期間、ブーストするようになっており、クエリでは prefer-recent:0.6,160 と入力できます. これは他のページの順位づけ規則との共用がうまく働き、ほとんどの検索に向いています.

規則を操作するには: prefer-recent:boost,recent 技術上、"boost" とはスケール（計測対象）に対するスコアの比率を指し、"recent" は半減期 を日数で示します. 増幅とは通常の 乗数 ではなく、むしろ 指数関数的 な増幅を指します. 指数で使われる係数は最終編集からの時間です.

例えば


 * prefer-recent:,7

ページの増幅は作成後7日以上経過すると半減し、14日以上経過するとさらに半減し、といった具合です. 高度に洗練された検索結果における単純な「日付順並べ替え」に対しては、ページのランキングと増幅がほぼ無意味であり、単にスコア全体を増幅します.
 * prefer-recent:1,7 (weeks)
 * prefer-recent:1,1 (days)
 * prefer-recent:1,0.0007 (minutes)
 * prefer-recent:1,0.0001 (8.64 seconds)
 * prefer-recent:1,0.00001 (seconds)

増幅-テンプレート
ページに含まれるテンプレートに基づき、スコアを増幅することができます. 操作は直接、検索で を使うか メッセージを介してすべての検索に既定で適用します. 前者を指定すると は のコンテンツを置換します. 構文はやや風変わりですが、簡略性を重んじて選ばれました. prefer-recentと同じように、boost-templatesは既定の 並べ替え順を適用した場合に限定して適用されます. 例:


 * File:boost-templates:"Template:Quality Image|200%" incategory:china
 * China（中国）というカテゴリ内でファイルを検索し、良質な画像を最初に並べる.


 * File:boost-templates:"Template:Quality Image|200% Template:Low Quality|50%" incategory:china
 * China（中国）というカテゴリ内でファイルを検索し、良質な画像を最初に、質の低い画像を最後に並べる.


 * File:boost-templates:"Template:Quality Image|200% Template:Low Quality|50%" popcorn
 * popcorn（ポップコーン）に関するファイルを見つけ、良質な画像を最初に、質の低い画像を最後に並べる.   メッセージの使用によって、これは単に   と短縮できることを覚えておいてください.

パーセントの数値に小数点は使えません. 役に立たないのと、検索のスコアにはほぼ無関係だからです.

に関する警告：非常に巨大または小さなパーセンテージを追加した場合、全文のスコアリングに悪影響を及ぼす可能性があります. 例えば、英語版ウィキペディアで秀逸な記事を100万%に増幅したと考えてみてください. すると秀逸な記事で言及されている項の検索で、その項に正確にマッチするタイトルよりも前に秀逸な記事が見つかるようになってしまいます. 句のマッチも同様に異常になり、 で検索してもBrave New Worldについての記事の代わりに、それらの単語が散在している秀逸な記事が見つかるようになってしまいます.



正規表現検索
基本的なインデックス化された検索は、ページで視覚的に描画された単語群を見つけます. ハイフネーションや句読点のマークや括弧、スラッシュやその他の数学やコンピュータの記号は、単語群に対する単なる境界です. それらをインデックス化された検索に含めることはできません. たいていは利用者が望んでいる検索の挙動です. しかしながら、もっと精密な検索を利用したいことがときどきあります.

インデックスベースの検索の構文的欠陥を避けるために正規表現検索を使うことができます. ただし、正規表現のみを使用するクエリは非常に遅く、リソースを消費するため、正規表現の検索ドメインが1つ以上のインデックスベースの検索の結果に制限されるように、常にインデックスベースの検索と組み合わせるべきです.

An "exact string" regexp search is a basic search; it will simply "quote" the entire regexp, or "backslash-escape" all non-alphanumeric characters in the string. All regexp searches also require that the user develops a simple filter to generate the search domain for the regex engine to search (index based search domain marked bold, regexp part marked in italics):


 * insource:"debian.reproducible.net" insource:/debian\.reproducible\.net/
 * insource:"c:\program files (x86)" insource:/C\:\\Program Files \(x86\)/i
 * insource:"&lt;tag>{ {template}}&lt;/tag>" insource:/"&lt;tag>{ {template}}&lt;"\/"tag>"/
 * insource:"[ [title|link label]]'s" insource:/"[ [title|link label]]'s"/
 * insource:/regexp/ prefix:{ {FULLPAGENAME}}

最後の例はページ上のリンクから機能しますが、 { {FULLPAGENAME}} は検索ボックスでは機能しません.

例えば: Special:Search/insource:/regex/ prefix: とするとこのページ上の regex という項が見つかります.

名前空間および接頭辞が指定されていないクエリは、利用者の既定の検索ドメイン（検索結果ページ、つまり Special:Search で設定可能）を検索します. 一部の利用者は既定の検索ドメインを「すべての名前空間」つまりウィキ全体に指定しています. 大規模なウィキでこのような利用者がむき出しの正規表現検索を実行すると、おそらく検索を完了する前にタイムアウトが発生して処理に失敗します.

正規表現検索は実際に検索ドメイン内の各ページを1文字ずつ精査します. インデックス検索はそれとは対照的に、実際はウィキデータベースとは別に維持されるデータベースにいくつかのレコードを問い合わせることで、ほぼ即座に結果を提供します. そのため、insource://（あらゆる種類の正規表現）を使用するときには、他の検索語を追加して、正規表現検索ドメインをできるだけ制限することを検討してください. インデックスを使用する検索項は多くあるので、/regexp/に対して、即座により洗練された検索ドメインを提供できます. 一般的な効果の順に紹介します:


 * 引用符で囲んだ insource:""、スラッシュがなく文字をエスケープすることを除き正規表現の複製、理想的です.
 * intitle （正規表現検索なし）、 incategory、および linksto は素晴らしいフィルターです.
 * hastemplate: は非常に良いフィルターです.
 * "word1 word2 word3"、引用符ありまたはなし、は良いです.
 * namespace: は実際には役に立ちませんが、遅い正規表現検索の完遂を可能にするかもしれません.

むき出しの正規表現クエリをテストするには、テストパターンを記入したページを作成して、その完全なページ名に接頭辞パラメータprefixを使います. マッチは強調されます. （データベース内の）そのページおよびサブページを検索します.

正規表現検索の効率性向上に役立たない検索項は、morelike、 boost-template、prefer-recentなどのページスコア演算子です.

メタ文字
この節では正規表現検索でメタ文字をエスケープする方法を取上げます. メタ文字の実際の意味は構文の解説をご参照ください.

例:


 * to search a namespace, gauge the number of pages with a single term that is a namespace. This will list the number of pages in that namespace.
 * starting out to find again what you may have seen, like "wiki-link" or "(trans[in]clusion)" start with namespace and insource filters.



完全一致文字列で洗練する

 * "2 + 2 = 4"、 あるいは "site.org"のように、見たいもので進行中の検索プロセスを洗練することができます. これは理想的には正規表現の最良の使用法です. なぜならば、検索を洗練しつつ単一の正規表現の項として追加され、正規表現がクロールしなければならない限られた数のページがわかるからです.

完全一致文字列検索を意図し始めて構いませんが、次のことを心に留めておいてください：


 * 正規表現は描画されたテキストではなくウィキテキストのみを検索するので、マークアップ周りにいくつかの差異があり、スペース文字の数さえも厳密にマッチしなければなりません.
 * 付随するフィルターを適用する義務があります.
 * 正規表現のメタ文字をエスケープする方法を学ばねばなりません.

メタ文字をエスケープする方法は2つあります. どちらも有用なときがあり、文字列のエスケープにおいて並べて連結させる場合もあります.


 * \charでその1つをバックスラッシュエスケープ（訳注：日本語環境ではバックスラッシュではなく円マークで表示されることが多い）します. insource:/regexp/ は正規表現を区切るためにスラッシュ「/」を使います. /reg/exp/の入力はあいまいなので、/reg\/exp/と入力してください.
 * それらの文字列を"文字列"のように二重引用符で囲んでください. 文字をエスケープすることによって問題が発生する可能性がなく、その中に含まれている可能性のあるあらゆるメタ文字について、あらゆる文字をエスケープすることができるからです. 引用符でエスケープする方がきれいです.
 * 手法の混合はできませんが、連結はできます.

insource:/"regexp"/ を使って二重引用符エスケープをすると多くの種類の文字列を簡単に検索することができますが、二重引用符エスケープの中ではいかなるものもバックスラッシュ・エスケープすることができません.


 * の代わりに  とします
 * と  は同じです（文字通りのバックスラッシュ）
 * しかし  は常に失敗します.
 * そして  は場合によります. おそらく求めているであろう   ではなく、文字通り   が見つかります.

insource:/regexp/ にバックスラッシュ・エスケープ（訳注：日本語環境ではバックスラッシュではなく円マークで表示されることが多い）を使用すると区切り文字「"」と「/」をエスケープできるものの、メタ文字を考慮する必要があり、以下のいずれかによってエスケープします：


 * 区切り文字をマッチするには  を使ってください.
 * 区切り文字をマッチするには  を使ってください.
 * エスケープされたメタ文字は  となります.
 * 二重引用符でエスケープされた等価な表現は  です.

「"」と「/」を除きメタ文字を考慮に入れる必要なく、insource:/"regexp"/を使って基本的な文字列を見つける表現を作成する最も単純なアルゴリズムは：
 * 1)   を書き出します. （ /" 区切り "/ は表示していません. ）
 * 2)   を   で置き換えます（前の二重引用符を閉じ、連結し、引用符を再開します）.
 * 3)   を   で置き換えます（閉じ、連結、開く）.
 * 4)   となり、２つの手法の連結を示しています.

角括弧記法で独自の文字クラスを作成すると、その中のメタ文字はエスケープもされます. 文字クラスパターンの中で文字通り右角括弧を対象とするには、バックスラッシュ・エスケープしなければならず、さもなくば右角括弧は文字クラスパターンの定義を閉じる区切り文字として解釈できます. 文字クラスの最初の位置では右角括弧もエスケープされます. 文字クラスの角括弧区切りの中では、ダッシュ文字も特別な意味（範囲）を持ちますが、右角括弧と同じようにして文字通りクラスに含めることができます. 例えば、これらのパターンは両方とも、ダッシュまたは右角括弧またはドットのいずれかの文字を対象とします： あるいは.

メタ文字を使う一般的な例については：


 * insource:"2+2=4" insource:/"2+2=4"/ は文字の間のスペースがゼロ個のものと共に、"2 + 2 = 4"にマッチします.
 * insource:"2 + 2 = 4" insource:/2 ?\+ ?2 ?= ?4\./ は間のスペースがゼロ個または1個のものとマッチします. 等号 = はメタ文字ではありませんが、プラス記号 + はメタ文字です.
 * insource:"[ [link|2\3?]]\" insource:/"[ [link|2\3?]]< "\/" tag>"/

標準的な正規表現のメタ文字と顕著に異なる点がいくつかあります：


 * あるいは  は改行にマッチするために予約されていません.  改行を含む文字列を検索するには、   のように検索してください. これは波括弧以外、その後に2つの波括弧、その後に波括弧、スペース、あるいはパイプを除く任意の2文字、その後に  タグを意味します.  検索において「を除く任意の文字」には改行を含みます.  この検索は以下の文字列にマッチするためだけに設計されたことに注意してください：


 * ドット . メタ文字は改行を含む任意の文字を表すので、 .* は複数行にわたりマッチします.
 * 範囲  は3つ以上の連続する改行文字におおよそマッチします.  かなり遅い検索となり、理論的には他の文字（例えば、タブや他の制御コード文字 0x00-0x1F）にマッチする可能性があることに注意してください.  しかし実際には典型的な記事の文章にこれらの他の文字が追加されることはないでしょう.
 * 番号記号 # は何か意味があり、エスケープしなければなりません.
 * ^ および $ は実装されていません. "grep" （行毎にグローバルな、正規表現、各行を出力）のように、各 insource:// は文書毎に「文書毎にグローバルな、正規表現、各文書を検索結果一覧」です.
 * および  は複数桁の数値的な範囲を   と同じようにサポートしますが、数字の文字の位置、あるいは各位置での範囲を考慮しないので、   が機能しますし、   でさえも機能します.



タイトルの正規表現
insource キーワードはページのソースの内容だけを検索します. タイトルで正規表現検索を実行するには intitle:/regex/ を使ってください.

<span id="Advanced_example">

高度な例
For example, using metacharacters to find the usage of a template called Val having, inside the template call, an unnamed parameter containing a possibly signed, three to four digit number, possibly surrounded by space characters, and on the same page, inside a template Val call, a named argument  having any allowable spaces around it, (it could be the same template call, or a separate one):



Note that the = sign in "fmt commas" is not needed but that adding it would not change the search results. 正規表現がクロールする各ページが可能な限り高いポテンシャルを持つように2件のフィルターを使用しているので高速です.

<span id="Geo_Search">

地理検索
ページに関連付けられている（最初の）座標に基づいて検索します. および  に依存します

制限値
特定の地理座標の近くにあるとわかっている事物のページに検索対象を限定することができます. 座標は、緯度と経度の組を直接指定することも、座標の元となるページ名を入力することもできます. 距離を制限したい場合は先頭に追加します. 例:


 * neartitle:"San Francisco"
 * neartitle:"100km,San Francisco"
 * nearcoord:37.77666667,-122.39
 * nearcoord:42km,37.77666667,-122.39

増幅
あるいは指定した地理的領域の範囲内にあるページのスコアを増やすという方法があります. キーワードの先頭に boost- を追加することを除き、構文は制限値検索と同じです. これにより検索範囲のページのスコアを効率的に倍増し、近隣の検索結果を上位近くに配置する確率が高くなります.


 * boost-neartitle:"San Francisco"
 * boost-neartitle:"100km,San Francisco"
 * boost-nearcoord:37.77666667,-122.39
 * boost-nearcoord:42km,37.77666667,-122.39

<span id="File_properties_search">

ファイルの属性を検索
MediaWiki 1.28 以降、CirrusSearch は 名前空間でファイルの属性をインデックス化した検索をサポートしています. これには以下が含まれます：
 * ファイルのメディアの種類
 * MIME タイプ
 * サイズ
 * 幅と高さ
 * 解像度
 * ビット深度をサポートするファイルではビット深度

ファイルの種別
ファイルの種類で検索することによって、Office ドキュメント、動画、ラスター動画、ベクター画像などといった分類に応じたファイルを取得することができます. 現在、以下の分類が利用できます：



この一覧は将来的に拡張されるかもしれません. 関連情報は の を参照してください.

検索の構文例は、 filetype:{type}. 例:

filetype:video - すべての動画を探す

ファイルタイプ検索は大文字小文字を区別しません.

filemime
MIME 形式のファイル. 構文の記述：

filemime:{MIMEtype} - この MIME 形式のファイルを検索

引数を引用符ではさむと、完全一致検索を指定できます. 引用符がない場合、MIME タイプの要素の部分一致も適用されます.

例:


 * filemime:"image/png" - MIME 形式で  と完全一致するファイルを検索
 * filemime:pdf - PDF 文書をすべて検索
 * -filemime:pdf - PDF 形式の文書はすべて除外（Commonsに特異的）

The MIME 形式の検索では大文字と小文字は識別しません.

ファイルサイズ
キロバイト（キロバイトは 1024 バイトの意味）で指定したサイズのファイルを検索します. その構文は：


 * filesize:{number} または filesize:>{number} - サイズが指定した数値以上のファイル
 * filesize:<{number} - サイズが指定した数値以下のファイル
 * filesize:{number},{number} - サイズが指定した数値の間のファイル

例:


 * filesize:>20 または filesize:20 - 20KB 以上のファイル
 * filesize:<1024 - 1MB 以下のファイル
 * filesize:100,500 - サイズが100KB から 500KB のファイル

<span id="File_measures">

ファイルの大きさ
大きさを指定した検索が可能です. 幅、高さ、（高さ×幅の平方根として定義される）解像度、およびビット深度です. これらの属性を与えられていないファイルもあります. 構文は：


 * {measure}:{number} - 大きさが指定した数値と等しいファイル
 * {measure}:>{number} - 大きさが指定した数値以上のファイル
 * {measure}:<{number} - 大きさが指定した数値以下のファイル
 * {measure}:{number},{number} - 大きさが指定した数値の間のファイル

の値は次のいずれかに当たります.

filew または filewidth - 画像ファイルの幅

fileh または fileheight - 画像ファイルの高さ

fileres - 画像解像度（前述参照）

filebits - ファイルのビット深度

例:

filew:>800 fileh:>600 - 画像サイズが 800×600 ピクセル以上のファイル

filebits:16 - 色深度が16ビットの画像ファイル

fileheight:100,500 - 画像の高さが100 - 500 ピクセルのファイル

<span id="Wikibase_search">

ウィキベース検索
拡張機能は 複数の検索キーワードを指定し、特定のウィキベース項目を検索しやすくします. これはおよびその他のウィキベースのサイト群で利用でき、において構造化データで画像を検索する場合などに有用です. 詳細は を参照してください.

<span id="Cross-wiki_search_results">

ウィキ間検索の結果
ウィキペディアで検索しているときに、ウィキ間を横断して表示される場合がある結果が2種類あります.

プロジェクト間検索（ウィキ間検索、姉妹検索、あるいは姉妹プロジェクト検索ともいう）は、他プロジェクト（ウィクショナリー、ウィキソース、ウィキクオート、など）から追加の結果を、ウィキペディアの結果ページの側部に表示します. ほとんどのウィキペディアで姉妹プロジェクトとのプロジェクト間検索が利用可能です.

言語間検索（ブログ投稿ご参照）は、主な検索結果の下部に表示される他言語版ウィキペディアからの結果を指します. 言語間検索は という軽量言語検出器の大幅に改良および最適化されたバージョンを使っています. 言語間検索は現状、ウィキペディアのいくつかの言語版でのみ利用可能です（詳細は TextCat へのリンクをご参照ください）.

<span id="Explicit_sort_orders">

明示的な並べ替え順
既定の関連性に基づく並べ替えに加えて、CirrusSearchはその他いくつかの明示的な並べ替えを使って結果を提供することが可能です. 並べ替え順に 以外を指定すると、 や のようなスコアに影響する検索キーワードはすべて無効になります. キーワードはなおも構文解析されますが、効果はありません.

並べ替えの選択肢は MediaWiki API から利用でき、  パラメータを指定します.

手引き：

検索URLに を追加することによって、並べ替えのオプションを手動で設定することができます. 例えば、



'''有効な並べ替え順には以下を含みます. '''

<span id="Interface_for_advanced_options">

高度なオプション用インターフェース


AdvancedSearch拡張機能は検索ページに改良型のインターフェースを補い、前述のオプションを利用者にわかりやすく使えるようにします. 詳細はこちらのユーザーマニュアルを参照してください.

<span id="See_also">

関連項目

 * Completion Suggester - CirrusSearchの増分的な検索機能
 * — 定義、文脈、および検索に関連する用語へのリンク.
 * MWSearch の詳細はをご参照ください. 独自に検索拡張機能を備えていない多くのウィキで使われています.
 * MWSearch の詳細はをご参照ください. 独自に検索拡張機能を備えていない多くのウィキで使われています.

<span id="External_links">

外部リンク

 * From Lucene - クエリの概念を的確に解説
 * (as of 2017-12-06)
 * Extension:CirrusSearch/Profiles – インデックス化の様々な側面に影響を与える調整可能なパラメータのセット
 * Wikimedia blog articles related to search
 * WMF Global Search

<span id="Notes_and_references">