はじめに
SharePoint Online（SPO）でサイトを運用していると、複数のリストに散らばっているアイテムを1箇所に集約して表示したいというご要望をいただくことがあります。
サードパーティ製のWebパーツや Power Apps / PnP Modern Search などを使えば自由度の高い実装が可能ですが、プロジェクトのセキュリティ制約や運用の保守性を考えると、「まずは標準機能のみで実現したい」というケースも多いのではないでしょうか。
そこで今回採用したのが、SharePointの標準Webパーツである「強調表示されたコンテンツWebパーツ（Highlighted Content Web Part : HCWP）」です。
この記事では、強調表示されたコンテンツWebパーツの「カスタムクエリ」を活用して複数リストのアイテムを集約表示させる具体的な設定方法と工夫した点、そして実装中に直面した「添付ファイルによる更新日時の挙動の違い」についてまとめます。
複数のリストのアイテムを集約表示させる方法
「強調表示されたコンテンツ」Webパーツの標準UI（簡易フィルター）だけでは、特定の複数リストのみをターゲットに絞り込んだり、複雑な条件でフィルタリングしたりすることができません。
そこで「カスタムクエリ（KQL: Keyword Query Language）」を活用します。
今回は特定のリストのアイテムであること、かつ各リストに共通する「区分」列が特定の値であることを条件に指定する必要がありました。
1. カスタムクエリでのフィルター指定方法
Webパーツのプロパティ設定で以下のように設定します。
- クエリの選択: カスタムクエリ
- ソース: このサイト
- クエリテキスト（KQL）:
contentclass:"STS_ListItem" AND Path:"https://yourtenant.sharepoint.com/sites/yoursite/Lists/info_*" AND RefinableStringXX="テキスト"
このように Path プロパティを使って対象のリストを指定し、管理プロパティ（RefinableString00 など）を組み合わせることで、意図したアイテムのみを抽出できます。
2. カスタムクエリの制限と工夫したポイント
KQLの利用においては、文字数制限や検索インデックスの仕様を考慮した設計が必要です。
① リストURLの命名規則とワイルドカード検索
集約したいリストが20、30個など多数存在する場合、すべてのURLを OR で繋ぐとクエリが長くなり、上限値の2,048文字を超過するリスクがあります。また管理も煩雑になります。
そのため、対象となるリストを作成する際にURL（内部名）へ命名規則を設けました。
- 例：
info_company,info_system,info_salse
クエリ側では以下のように前方一致（ワイルドカード *）を使用することで、クエリをシンプルに保ちつつ、将来的にリストが増えた場合でも自動的に集約対象に含めることが可能になります。
Path:https://yourtenant.sharepoint.com/sites/yoursite/Lists/info_*
KQLのワイルドカード (*) は "前方一致 (プレフィックス一致)" のみをサポートしています。文字列の先頭や途中に * を置く部分一致 (例：*info*) はサポートされておりません。
② 管理プロパティ適用のコツ
カスタム列（選択肢列やテキスト列など）でフィルターをかける場合は、列を作成するだけではKQLから検索できません。
「サイトの設定」 >「検索」>「スキーマ」から、該当のクロールされたプロパティ（ows_列の内部名）を管理プロパティ（RefinableStringXX や RefinableDateXX など）にマッピングする必要があります。
※ テナント全体で利用する場合は、SharePoint管理センターの「検索」>「検索スキーマの管理」から同様の設定を行うことも可能です
※ マッピング後は、再クロール（インデックス再作成）が行われるまで反映に時間がかかる点に注意してください
表示についての誤算（仕様の壁）
集約表示自体は問題なく構築できたのですが、実際の投稿データを追加する過程で想定外の現象（誤算）が発生しました。
1. 添付ファイルが存在すると「更新日時」が変わってしまう問題
SharePointのリストアイテムにファイルを添付した場合、強調表示されたコンテンツWebパーツ上に表示される「日付（更新日時）」に、アイテム本体の更新日ではなく、添付ファイルが保持している最終更新日が表示されてしまう現象が発生しました。
【発生した挙動】
- アイテムA: 2026/09/20 に作成・更新（添付ファイルなし） → Webパーツ上には「2026/09/20」と表示される（正常）
-
アイテムB: 2026/09/20 に作成・更新（2020年に作成された古いPDFを添付） → Webパーツ上には**「2020/xx/xx」**と表示されてしまう
なぜそうなるか、の詳細については解明できていませんが、仕様上、リストアイテムにファイルが添付された際に、強調表示されたコンテンツ Web パーツでの表示に参照する "検索インデックスの最終更新日時 (LastModifiedTime)" に添付したファイルの更新日時が格納されてしまう挙動となるようです。
2. Webパーツ上の「並び順」の選択肢（LastModifiedTime と LastModifiedTimeForRetention）
標準の範囲では更新日時の表示を改善することができないため、せめてアイテムの並び順だけでもリストアイテム自体の更新日時順に並べられないかと考えました。
Webパーツ上の並び替えの選択肢には、「最終更新日時順」が用意されています。
一見これを選択すれば良いように見えますが、この場合の制御対象は「LastModifiedTime」となるため、リストアイテム自体の更新日時順で並べることはできません。
そのため、ここでも管理プロパティを利用しました。
選択肢から「管理プロパティ（降順）」を指定し、管理プロパティの検索で mod を入力して候補に表示される LastModifiedTimeForRetention を選択します。
LastModifiedTimeForRetention を指定することで、Webパーツ上の更新日時の日付の表示はバラバラになってしまうものの、リストアイテムが更新された順番にアイテムを並べることができました。
まとめ
これまであまり利用する機会がなかった強調表示されたコンテンツWebパーツですが、今回の件で機能上の制限を知ることができ、またどのような場面で使うべきかなど色々と考えることができました。
管理上、リストが複数管理になってしまうことは起こりうると思いますので、事前にお客様のご要望をしっかりとキャッチしてカスタマイズも視野に入れた設計が必要になると感じました。
SharePoint活用の何かしらのヒントになれば幸いです。
参考情報
- 強調表示されたコンテンツの Web パーツを使用する
https://support.microsoft.com/ja-jp/sharepoint/pages-in-sharepoint/use-the-highlighted-content-web-part - キーワード照会言語 (KeyQL) 構文リファレンス
https://learn.microsoft.com/ja-jp/sharepoint/dev/general-development/keyword-query-language-kql-syntax-reference