SharePoint Online のドキュメント ライブラリでカスタムサイト列を作ったのに、ライブラリ上部の検索ボックスではまったくヒットしない……という相談はとても多いです。本記事では「なぜヒットしないのか」という仕組みの解説から、検索スキーマの具体的な設定手順、さらに現実的な運用パターン（PnP Modern Search や Power Automate 併用）まで、実務でそのまま使えるレベルで詳しく整理します。
ドキュメント ライブラリの検索ボックスでカスタムサイト列がヒットしない理由
まず状況を整理します。よくある質問は次のようなものです。
- ドキュメント ライブラリの検索ボックスに値を入力しても、作成したカスタムサイト列の値がヒットしない
- ライブラリの検索ボックスは、どうも既定の管理プロパティしか見ていないように感じる
- 「サイトの上部検索（Microsoft Search）と同じ仕組みなら、検索スキーマで拡張できるのでは？」と試したが想定どおり動かない
- 最終的なゴールは、カスタムサイト列の値を検索で引っかかるようにしたい（できればライブラリ内で完結したい）
結論から言うと、カスタムサイト列を検索のインデックスに載せることは可能ですが、ライブラリ上部の検索ボックスだけで柔軟にプロパティ検索を行うには限界がある、というのが現状の仕様です。そのため、基本方針は次のようになります。
- カスタムサイト列を クロール済みプロパティ → 管理プロパティ にマッピングして検索対象に載せる
- 検索条件をうまく使いたいなら、サイト全体検索や専用の検索ページ（PnP Modern Search など）を用意する
- 「ライブラリ内の検索ボックスだけで完結」が必須の場合は、フィルター・ビュー・同期列など、別のアプローチを検討する
検索ボックスの種類と対象範囲
SharePoint Online では、見た目は似ていても検索の種類が複数あり、対象範囲やカスタマイズ性が異なります。まずはここをきちんと整理しておきましょう。
| 検索の種類 | 表示される場所 | 主な対象 | カスタム列の扱い |
|---|---|---|---|
| ライブラリ検索（モダン） | ドキュメント ライブラリの上部 | 主にそのライブラリ内のアイテム | 既定の管理プロパティが中心。カスタム列はそのままでは対象外になることがある |
| サイト検索（Microsoft Search） | SharePoint サイトの上部（タイトル横） | サイト内のコンテンツ全体 | 検索スキーマでマッピングした管理プロパティを使った検索が可能 |
| 専用検索ページ（カスタム） | 検索専用のページ（検索結果 Web パーツ、PnP Modern Search 等） | テナント／サイトコレクション／任意スコープ | クエリテンプレートなどで柔軟に管理プロパティを利用可能 |
この記事では、「カスタムサイト列を検索対象に載せる」という根本の設定と、その後どう使うか（ライブラリ検索・サイト検索・カスタム検索画面）の両方を扱います。
カスタムサイト列を検索対象にする仕組みの全体像
SharePoint 検索で列を検索可能にするには、次の3段階を押さえる必要があります。
- ライブラリを検索対象に含め、クロール対象として認識させる
- クロール済みプロパティ（自動生成）を、管理プロパティ（検索に使えるプロパティ）にマッピングする
- 必要に応じて、管理プロパティをクエリ（検索条件）や表示に利用する
特に重要なのは、カスタム列に対応するクロール済みプロパティ名を特定し、どの管理プロパティにマッピングするかを決める部分です。これをやらないと、その列の値は検索インデックスにうまく載らず、検索結果からは見えないままになります。
最短で効果が出やすい設定手順（推奨ルート）
ライブラリを検索対象にし、再インデックスを実行する
まず、そもそもライブラリ自体が検索対象に含まれているかを確認します。
- 対象のドキュメント ライブラリを開く
- 右上の歯車アイコンから「ライブラリの設定」を開く
- 「詳細設定」をクリックする
- 「検索」で、「このドキュメント ライブラリのアイテムを検索結果に表示する」を「はい」に設定
- 同じ画面の下部にある「このドキュメント ライブラリを再インデックスする」をクリック
この操作により、ライブラリ全体の再クロールが行われ、検索インデックスが更新されます。スキーマ設定を変更したあとにも必ず再インデックスが必要になるので、手順として覚えておきましょう。
カスタムサイト列の内部名を確認する
次に、対象となるカスタムサイト列の「内部名」を確認します。表示名と内部名が異なるのが SharePoint のよくある落とし穴です。
一般的な例は次のようなイメージです。
| 列の表示名 | 列の内部名 | 想定されるクロール済みプロパティ |
|---|---|---|
| 案件番号 | Anken_x0020_No | ows_Anken_x0020_No |
| 顧客名 | CustomerName | ows_CustomerName |
| 案件カテゴリ（用語セット列） | ProjectCategory | owstaxId_ProjectCategory |
内部名の確認方法の一例は次のとおりです。
- ライブラリの「ライブラリの設定」を開く
- 「列」の一覧から対象の列名をクリックする
- ブラウザのアドレスバーを確認し、URL の
Field=の後ろにある値が内部名
文字列列の場合、クロール済みプロパティ名は通常 ows_内部名 となります。
管理メタデータ列（用語セット列）の場合は、owstaxId_内部名 という別の名前になるので注意してください。
検索スキーマでクロール済みプロパティを管理プロパティにマッピングする
ここが一番重要なステップです。SharePoint 管理センターで検索スキーマを編集し、クロール済みプロパティと管理プロパティを結びつけます。
検索スキーマ画面を開く
- Microsoft 365 管理センターから「SharePoint 管理センター」を開く
- 左ペインから「その他の機能」→「検索」→「開く」
- 「検索スキーマ」をクリック
テナント全体に影響するため、可能であればサイト コレクションの検索スキーマ側で設定するのがおすすめです。サイト コレクション単位の検索スキーマでも、同様の画面・手順で設定できます。
クロール済みプロパティを探す
- 検索スキーマで「クロール済みプロパティ」を選択
- 検索ボックスに
ows_内部名（例：ows_Anken_x0020_No）を入力して検索 - 対象のクロール済みプロパティが見つかったら選択する
もしうまく見つからない場合は、ライブラリの再インデックスを行ったうえでしばらく時間を置き、再度検索してみてください。
管理プロパティとのマッピング方針
クロール済みプロパティが特定できたら、どの管理プロパティにマッピングするかを決めます。一般的な方針は次の2つです。
- RefinableString00/01…などの空きを再利用する（簡便・共用）
- 新規に管理プロパティを作成し、用途専用にする（推奨）
RefinableString 系を使うと、検索結果の絞り込み（Refiner）や並べ替えにも利用しやすいですが、どの列をどの番号に割り当てたかの管理が必要です。一方で、プロジェクト専用の管理プロパティを作ると、設定が分かりやすくなり、後から見ても迷いにくくなります。
管理プロパティの設定ポイント
管理プロパティには多くのチェックボックスがありますが、意味を知っておかないと「検索できるようにしたつもりでできていない」という事態になりがちです。代表的な項目をまとめると次のとおりです。
| 設定項目 | 意味 | 典型的な使い方 |
|---|---|---|
| Queryable（クエリ可能） | プロパティ名:値 という形式で検索条件に使える | 特定列を条件に絞り込みたい場合は必須 |
| Retrievable（取得可能） | 検索結果のフィールドとして値を取得できる | 検索結果画面に値を表示したい場合に必須 |
| Searchable（全文検索対象） | キーワード検索の対象としてコンテンツ インデックスに追加される | フリーワード検索でこの列の値もヒットさせたい場合に有効（対応している型のみ） |
| Refinable（絞り込み可能） | 検索結果の左ペインに絞り込み条件として表示できる | 「案件番号」「部門」などで検索結果を絞り込みたい場合 |
| Sortable（並べ替え可能） | 検索結果をそのプロパティで昇順／降順に並べ替えできる | 「更新日」「金額」「案件番号」などで並べたい場合 |
最低限、次の設定を意識するとよいでしょう。
- 検索条件として使う → Queryable を有効
- 検索結果に表示したい → Retrievable を有効
- フリーワード検索で拾いたい → 可能であれば Searchable も有効
設定後は保存し、再びライブラリ側で「このドキュメント ライブラリを再インデックスする」を実行しておきます。
動作確認：管理プロパティを使った検索
インデックスの更新が完了したら、サイトの上部検索（Microsoft Search）または検索結果ページで、次のようなクエリを試してみます。
RefinableString00:"A-12345"- 独自プロパティ名を付けた場合は
AnkenNo:"A-12345"のように検索
期待した結果が表示されれば、カスタムサイト列が検索インデックスに載ったことが確認できます。検索結果にプロパティ値を表示したい場合は、そのプロパティが Retrievable として設定されているかを必ず確認してください。
ライブラリ内の検索ボックスでの限界と現実的な使い方
ここまでで「カスタムサイト列を検索インデックスに載せる」ことはできました。しかし、ライブラリ上部の検索ボックスが、それらの管理プロパティを自由に使わせてくれるわけではない点が注意ポイントです。
モダンなライブラリ検索は、一般ユーザー向けに簡易なキーワード検索として設計されており、内部的には既定の管理プロパティ中心に検索が行われます。任意の管理プロパティをクエリとして指定したり、UI をカスタマイズして追加することはできません。
そのため、次のような割り切りが現実的です。
- ライブラリ内では、基本的にフリーワード検索＋列フィルター＋ビューで運用する
- 管理プロパティを活かした高度な検索は、サイト検索（Microsoft Search）や専用の検索ページで提供する
どうしてもライブラリ内の検索ボックスだけで完結させたい場合は、後述の「代替案」として Power Automate で既定の列に値をコピーする方法などを組み合わせて対応します。
ライブラリ内での使い勝手を上げるテクニック
「インデックス付きの列」でフィルター性能を上げる
SharePoint には「検索インデックス」とは別に、ビューのフィルターを高速化するための「インデックス付きの列」の仕組みがあります。カスタムサイト列に対してこれを有効化しておくと、大量アイテムのライブラリでもフィルターの反応が良くなります。
- ライブラリの設定を開く
- 「インデックス付きの列」をクリック
- 「新しいインデックスを作成」を選択し、よく使うカスタム列を選んで保存
特に、次のような列はインデックスの候補になります。
- 案件番号、文書番号
- 顧客名、部門名
- ステータス、進捗
- 日付系の列（受付日、期限など）
インデックス付きの列は、あくまで「ビューのフィルターや並べ替えを高速化する仕組み」であり、検索インデックスとは別物です。ただし実務上は、「検索ボックスで探す」よりも「列でフィルターする」方がユーザーにとって直感的なことも多く、ビュー＋列フィルターを使いこなすことが結果的に検索体験の向上につながるケースもよくあります。
保存ビューで「よく使う切り口」をテンプレート化する
SharePoint のビュー機能を活用し、次のようなビューをあらかじめ用意しておくと、ライブラリ内での検索体験がぐっと快適になります。
- 「自分の案件」ビュー：作成者＝現在のユーザー、ステータス≠完了
- 「今月期限」ビュー：期限列が今月の範囲に入るアイテム
- 「重要顧客」ビュー：顧客カテゴリ列が「重要顧客」に一致
ビューのフィルター条件には、先ほどの「インデックス付きの列」を優先的に利用するとパフォーマンス面でも安心です。
PnP Modern Search で高度な検索画面をノーコードで作る
カスタムサイト列を活かした「ちゃんとした検索画面」を用意したい場合、PnP Modern Search の Web パーツを使うのが非常に現実的です。テナント アプリ カタログにソリューションを導入すれば、PowerShell やコードを書くことなく高機能な検索 UI を構成できます。
PnP Modern Search でできること
- 検索ボックス Web パーツと、検索結果 Web パーツをページ上に設置できる
- クエリ テンプレートで、特定ライブラリだけを対象にしたり、特定の管理プロパティに条件をかけることが可能
- 検索結果のレイアウトを、カード・表形式・カスタム HTMLなどで柔軟に作り込める
- RefinableString 等の管理プロパティを 絞り込みフィルターとして表示できる
たとえば、次のような構成が考えられます。
| Web パーツ | 役割 | カスタマイズ例 |
|---|---|---|
| Search Box | キーワード入力欄 | 既定クエリに Path:"対象ライブラリの URL" を含め、特定ライブラリに限定 |
| Search Results | 検索結果表示 | 列として「タイトル」「案件番号（管理プロパティ）」「顧客名」「更新日」を表示 |
| Search Filters | 絞り込み UI | 案件ステータス、顧客カテゴリなどの管理プロパティをフィルターとして提供 |
この構成により、ライブラリ検索の限界を回避しつつ、カスタムサイト列を活かした「業務用検索画面」を提供できます。エンドユーザーは、ライブラリに直接入らなくても「案件検索ページ」にアクセスするだけで必要な資料を探せるようになります。
設定でつまずきやすいポイントとチェックリスト
実際の運用現場でよくあるトラブルと、その確認ポイントをまとめておきます。
| 症状 | 想定される原因 | 確認・対処ポイント |
|---|---|---|
| カスタム列の値が検索でまったくヒットしない | クロール済みプロパティ→管理プロパティのマッピングがされていない | 検索スキーマで ows_内部名 を検索し、適切な管理プロパティにマッピングされているか確認 |
| 一部の列だけヒットしない | 列の型が特殊（管理メタデータ列など） | owstaxId_内部名 など、型に応じたクロール済みプロパティを確認 |
| 検索結果には出ているが値が表示されない | 管理プロパティで Retrievable が有効になっていない | 管理プロパティの設定画面で Retrievable がチェックされているか確認 |
| プロパティ検索（プロパティ名:値）が効かない | 管理プロパティで Queryable が有効になっていない | Queryable にチェックが入っているか確認し、再インデックスを実施 |
| 検索結果に出るはずのアイテムが一部だけ出ない | 権限トリミングによる非表示 | 対象ユーザーにライブラリへの閲覧権限があるか確認 |
| 設定変更後も結果が変わらない | 再インデックス未実行、もしくは反映待ち | ライブラリの再インデックスを実行し、時間をおいてから再度確認 |
特に、管理プロパティの設定変更後は必ずライブラリの再インデックスが必要であること、そしてインデックス更新にはタイムラグがあることを忘れないようにしてください。
要件別の現実的な落としどころ
「技術的にできるかどうか」と「運用として現実的かどうか」は別問題です。よくある要件パターンごとに、現場でおすすめしやすい解決策を整理します。
パターン1：ライブラリ内でそこそこ快適に絞り込みたい
要件：
- 対象は特定のドキュメント ライブラリだけ
- ユーザーは主にそのライブラリを直接開く
- 「完璧な検索」よりも「とりあえず探せればよい」が優先
おすすめ構成：
- カスタムサイト列を作成し、インデックス付きの列に設定
- よく使う切り口ごとの保存ビューを用意
- ライブラリの検索ボックスは、あくまで補助的なフリーワード検索として使用
このパターンでは、検索スキーマの調整は「将来的にサイト全体から探したくなったとき」に備える程度でも十分です。
パターン2：サイト全体・複数ライブラリをまたいで横断検索したい
要件：
- 案件関連のドキュメント ライブラリが複数あり、横断的に検索したい
- カスタムサイト列（案件番号、顧客名など）は共通で使っている
おすすめ構成：
- 共通のカスタムサイト列をサイト コレクション レベルで定義
- その列に対応するクロール済みプロパティを、共通の管理プロパティ（例：AnkenNo）にマッピング
- サイト上部の Microsoft Search で、
AnkenNo:"A-12345"のように検索可能にする - 可能なら、PnP Modern Search で「案件検索ページ」を1ページ用意し、そこから横断検索できるようにする
このパターンでは、検索スキーマの設計が情報基盤そのものになるため、台帳などでどの列をどの管理プロパティにマッピングしたか管理しておくことを強くおすすめします。
パターン3：どうしても「ライブラリの検索ボックスだけ」で完結させたい
要件：
- ユーザーに「専用検索ページ」に移動してもらう運用が難しい
- 教育コストをかけたくないため、ライブラリ上部の検索ボックスだけで済ませたい
この場合、仕様上の限界はあるものの、次のような妥協案が取られることがあります。
- Power Automate で値を既定列に同期する
- 例：カスタム列「案件番号」の値を、アイテム作成・更新時にタイトル列（Title）へコピー
- タイトル列は既定で検索対象になりやすく、ライブラリ検索でもヒットしやすい
- ファイル名に識別子を含める運用
- 「A-12345_XXXXXX.docx」のように、ファイル名の先頭に案件番号を付与するルールを徹底
- ユーザーは案件番号で検索ボックスに入力するだけでファイルを探せる
厳密にはメタデータ検索のメリットは落ちますが、「ユーザーの行動を大きく変えずに実現できる」という意味では有効な選択肢です。
実践例：案件管理ライブラリでの設定手順
最後に、具体的なサンプルとして「案件管理」ライブラリを想定した設定例を紹介します。
前提条件
- サイト名：営業案件サイト
- ドキュメント ライブラリ名：案件管理
- 主なカスタムサイト列
- 案件番号（単一行テキスト）※内部名：AnkenNo
- 顧客名（単一行テキスト）※内部名：CustomerName
- 案件ステータス（選択列）※内部名：Status
- 案件カテゴリ（管理メタデータ列）※内部名：ProjectCategory
ステップ1：ライブラリ設定
- 「案件番号」「顧客名」「案件ステータス」「案件カテゴリ」の4列をサイト列として作成し、「案件管理」ライブラリに追加
- 「案件番号」「顧客名」「案件ステータス」をインデックス付きの列に設定
- ライブラリを検索結果に表示する設定にし、「再インデックス」を実行
ステップ2：クロール済みプロパティの確認
検索スキーマ（できればサイト コレクションのスキーマ）で、次のクロール済みプロパティを確認します。
| 列 | 推定クロール済みプロパティ | 型のイメージ |
|---|---|---|
| 案件番号 | ows_AnkenNo | 文字列 |
| 顧客名 | ows_CustomerName | 文字列 |
| 案件ステータス | ows_Status | 文字列（選択値） |
| 案件カテゴリ | owstaxId_ProjectCategory | 管理メタデータ（用語セット） |
ステップ3：管理プロパティへのマッピング
次のような管理プロパティを用意し、それぞれクロール済みプロパティをマッピングします。
| 管理プロパティ名（例） | 型 | マッピングするクロール済みプロパティ | 主な設定 |
|---|---|---|---|
| AnkenNo | Text | ows_AnkenNo | Queryable, Retrievable（必要なら Searchable） |
| CustomerNameManaged | Text | ows_CustomerName | Queryable, Retrievable, Refinable |
| ProjectStatus | Text | ows_Status | Queryable, Retrievable, Refinable |
| ProjectCategoryTax | Text | owstaxId_ProjectCategory | Queryable, Retrievable, Refinable |
保存後、「案件管理」ライブラリをもう一度再インデックスします。
ステップ4：検索の利用例
インデックスの更新が完了すると、サイト上部の検索ボックスやカスタム検索ページで次のような検索ができるようになります。
- 案件番号で検索：
AnkenNo:"A-2024-001" - 顧客名で検索：
CustomerNameManaged:"株式会社サンプル" - 進行中案件だけ：
ProjectStatus:進行中 - カテゴリと状態を組み合わせ：
ProjectCategoryTax:"重要案件" ProjectStatus:進行中
PnP Modern Search を併用する場合は、Search Results Web パーツのレイアウトにこれらの管理プロパティをバインドし、「案件番号」「顧客名」「ステータス」「カテゴリ」をカード形式で表示すると、ユーザーにとって非常に分かりやすい検索画面になります。
まとめ：カスタムサイト列を検索で活かすための要点
ここまでのポイントを整理します。
- カスタムサイト列を検索対象にするには、必ずクロール済みプロパティから管理プロパティへのマッピングが必要
- 文字列列のクロール済みプロパティは、基本的に
ows_内部名（管理メタデータ列はowstaxId_内部名） - 管理プロパティでは、少なくとも Queryable / Retrievable を有効にし、必要に応じて Searchable / Refinable / Sortable を設定する
- 設定変更後は必ずライブラリの再インデックスを実行し、反映までの時間差を考慮する
- モダンなライブラリ検索には仕様上の制約があるため、サイト検索や PnP Modern Search などの専用検索ページを組み合わせる方が実務的
- どうしてもライブラリ検索だけで完結させたい場合は、Power Automate で既定の検索対象列（タイトルやファイル名など）に値を同期するといった妥協案もある
SharePoint の検索は少し取っつきにくい反面、一度「クロール済みプロパティ → 管理プロパティ → 検索 UI」という流れを理解してしまえば、業務ごとに最適な検索体験を設計できる強力な仕組みです。まずは小さなライブラリから試し、うまくいったパターンをテンプレート化して、チームや組織全体に横展開していくのがおすすめです。
コメント