SharePointのドキュメントライブラリだけでなく、サイトページやリスト項目までAzure AI Searchに取り込みたい場合、今回の「SharePoint in Microsoft 365 indexer supports ASPX pages and Lists」は重要な更新です。結論から言うと、Azure AI SearchのSharePoint in Microsoft 365 indexerが、従来のドキュメントライブラリに加えて、SharePoint ListsとモダンASPXサイトページをインデックス対象にできるようになりました。ただしPublic Previewであり、OneDrive自体はデータソースとしてサポート対象外です。検証環境で、認証方式・権限・ACL同期・インデックス設計を確認してから展開する必要があります。(Microsoft Learn)
まず結論：SharePoint indexerの対象が「文書」から「ページ・リスト」へ広がる
今回の変更で、Azure AI SearchのSharePoint in Microsoft 365 indexerは、次のようなSharePointコンテンツを扱えるようになります。
| 対象コンテンツ | これまでの主な扱い | 今回のポイント |
|---|---|---|
| ドキュメントライブラリ | インデックス対象 | 引き続き対象 |
| SharePoint Lists | 新たにプレビュー対応 | リスト列をフィールドとしてマッピング可能 |
| モダンASPXサイトページ | 新たにプレビュー対応 | サイトページ本文を検索対象にできる |
| ドキュメント・リスト・ページの混在 | 新たにプレビュー対応 | allSiteContentで単一インデクサーにまとめられる |
| サブサイト配下のコンテンツ | 条件付きで対応 | includeSubsites=trueを指定して対象化できる |
Microsoft Learnでは、SharePoint Lists、ASPX site pages、混在コンテンツ、サブサイト横断のインデックス作成が、2026-05-01-preview REST APIからプレビュー機能として提供されると説明されています。(Microsoft Learn)
特に影響が大きいのは、SharePointを「ファイル置き場」ではなく「業務ナレッジ基盤」として使っている組織です。たとえば、以下のような情報をAzure AI SearchやRAGアプリケーションの検索対象に含めやすくなります。
| 活用シーン | インデックス対象にしたい情報 |
|---|---|
| 社内ポータル検索 | ニュース投稿、部門ページ、手順ページ |
| 問い合わせ対応AI | FAQリスト、申請ルール、対応履歴リスト |
| 営業・サポートナレッジ | 商品情報リスト、提案資料、サイトページ |
| 情シス向け検索 | 障害対応手順、台帳リスト、運用マニュアル |
| Copilot/RAG検証 | SharePoint上のテキスト情報と権限情報 |
これまでリストやサイトページを検索基盤に入れるには、Microsoft Graph APIやLogic Appsなどで独自に取得・変換する構成を検討する場面がありました。今回のプレビューにより、標準のSharePoint indexerを軸にした構成の選択肢が広がります。
対象サービスはSharePoint中心。OneDrive対応と誤解しない
今回の更新は「SharePoint / OneDrive」文脈で語られることがありますが、実装上の主役はSharePoint in Microsoft 365です。Microsoft Learnの前提条件では、SharePoint in Microsoft 365クラウドサービスが対象であり、OneDriveはサポートされるデータソースではないと明記されています。(Microsoft Learn)
そのため、管理者は次のように整理すると判断しやすくなります。
| 観点 | 判断 |
|---|---|
| SharePointサイトのドキュメントライブラリ | 対象 |
| SharePoint Lists | プレビューで対象 |
| SharePointのモダンASPXサイトページ | プレビューで対象 |
| OneDrive for Business個人領域 | この更新だけで直接対象になるわけではない |
| OneDrive同期済みのローカルファイル | Azure AI SearchのSharePoint indexer対象ではない |
| Teamsに紐づくSharePointサイト | SharePointサイトとして設計次第で対象になり得る |
OneDrive内の個人ファイルまで含めた横断検索を想定している場合は、今回のSharePoint indexerだけで要件を満たせるとは限りません。対象サイト、権限、データ保持方針を確認し、SharePointサイト側に集約すべき情報と、個人領域に残す情報を分けて考える必要があります。
何が変わるのか：技術的な変更点
今回のPublic Previewで押さえるべき変更点は、大きく5つあります。
SharePoint Listsをインデックス化できる
SharePoint Listsは、allSiteListsを使うことでサイト内のリスト項目をインデックス対象にできます。また、ドキュメントライブラリやサイトページとまとめて扱う場合はallSiteContentを使用します。リスト列はSharePoint列名と同じソースフィールドとして公開され、Azure AI Searchのフィールドへマッピングできます。(Microsoft Learn)
たとえば、商品マスタのようなSharePointリストに次の列がある場合を考えます。
| SharePointリスト列 | Azure AI Search側の用途例 |
|---|---|
| Title | 商品名、FAQタイトル、申請名 |
| Category | 絞り込み用カテゴリ |
| Price | 数値フィルターや並び替え |
| InStock | 在庫有無、公開可否、状態管理 |
リストの内容は単なる全文検索対象にするだけでなく、フィールド検索・フィルター・ファセット・RAGの根拠データとして使いやすくなります。
モダンASPXサイトページをインデックス化できる
SharePointのモダンサイトページは、社内ポータル、部門ページ、ナレッジ記事、手順ページなどで多く使われています。今回の更新では、allSitePagesを指定することでサイトページを対象化できます。ドキュメントやリストと混在させる場合はallSiteContentを使います。(Microsoft Learn)
実務上は、PDFやWordに閉じた検索よりも、サイトページを含めたほうがユーザーの検索満足度が上がるケースがあります。理由は、社内ポータルの最新情報や運用手順が、添付ファイルではなくページ本文として管理されていることが多いためです。
混在コンテンツを単一インデクサーで扱える
allSiteContentを使うと、ドキュメントライブラリ、SharePoint Lists、ASPXサイトページを単一のインデクサーでまとめて扱えます。これにより、「ファイル検索用」「リスト検索用」「ページ検索用」と別々のパイプラインを持つよりも、構成をシンプルにできます。(Microsoft Learn)
ただし、混在コンテンツではインデックス設計が雑だと検索品質が落ちます。ドキュメント、リスト項目、ページではメタデータや本文構造が異なるため、contentTypeやURL、最終更新日、カテゴリなどを使って絞り込みやランキングを調整できるようにしておくことが重要です。
リスト・ページ・混在コンテンツではキー項目に注意が必要
ドキュメントライブラリ中心の構成と、リスト・ページ・混在コンテンツ中心の構成では、推奨されるキー項目が異なります。ドキュメントライブラリではmetadata_spo_site_library_item_id、リスト・ページ・混在コンテンツではmetadata_spo_site_asset_item_idを使います。後者は自動マッピングされないため、明示的なfieldMappingsが必要です。(Microsoft Learn)
| コンテナー種別 | 推奨キー |
|---|---|
defaultSiteLibrary | metadata_spo_site_library_item_id |
allSiteLibraries | metadata_spo_site_library_item_id |
useQueryでライブラリ・フォルダー指定 | metadata_spo_site_library_item_id |
allSiteLists | metadata_spo_site_asset_item_id |
allSitePages | metadata_spo_site_asset_item_id |
allSiteContent | metadata_spo_site_asset_item_id |
既存のSharePoint indexer構成を拡張する場合、ここを見落とすと「リストやページを追加したのにキー衝突・マッピング不備で期待どおり登録されない」というトラブルにつながります。
ACLと権限メタデータの扱いも拡張される
2026-05-01-previewでは、リスト項目やASPXサイトページにもACL取り込みが拡張されています。加えて、ユニーク権限を持つアイテムのACL変更は、各インデクサー実行時に増分検出されます。(Microsoft Learn)
ただし、SharePointの権限モデルを完全にそのまま扱えると考えるのは危険です。プレビューのACLサポートには制限があり、親スコープの権限変更など、一部の変更は自動検出されず明示的な再同期が必要です。(Microsoft Learn)
管理者が最初に確認すべき影響範囲
今回の変更は、単に「検索対象が増える」だけではありません。検索対象が増えるほど、取り込む情報量、権限リスク、インデックス設計、運用監視の重要性が高まります。
対象サイトと対象コンテンツを棚卸しする
最初にやるべきことは、技術設定ではなく対象範囲の整理です。以下のように、どのSharePointサイトを検索対象にするのかを明確にします。
| 確認項目 | 判断基準 |
|---|---|
| 対象サイト | 全社ポータル、部門サイト、Teams連携サイトなど |
| 対象コンテンツ | 文書、リスト、ページのどれを含めるか |
| サブサイト | includeSubsites=trueで含める必要があるか |
| 除外対象 | 下書き、アーカイブ、機密性の高いリスト |
| 更新頻度 | 日次でよいか、短い間隔が必要か |
| 利用目的 | 社内検索、RAG、FAQボット、管理者検索など |
失敗しやすいのは、「とりあえず全部入れる」進め方です。検索対象が広すぎると、不要な古いページやメンテナンス用リストまで検索結果に出る可能性があります。まずは利用頻度が高く、権限設計が比較的シンプルなサイトから検証するのが現実的です。
Public Previewであることを前提にする
SharePoint in Microsoft 365 indexer自体はプレビュー機能であり、Microsoft Learnではプレビュー機能は本番ワークロードに推奨されず、一般提供が保証されるものではないと説明されています。(Microsoft Learn)
また、Azure AI Searchのプレビュー機能はSLAなしで提供され、将来的に破壊的変更が入る可能性があります。プレビューREST APIを使うコードは、新しいAPIバージョンへの更新を前提にしておく必要があります。(Microsoft Learn)
本番環境で使う場合でも、いきなり業務クリティカルな検索基盤に組み込むのではなく、次のような段階的な導入が安全です。
| フェーズ | やること |
|---|---|
| 検証 | 代表的なSharePointサイトでリスト・ページの取り込みを確認 |
| 限定展開 | 特定部門や限定ユーザー向けに検索UIを提供 |
| 権限検証 | 権限差分、ACL同期、検索結果の出し分けを確認 |
| 運用設計 | エラー監視、再同期手順、APIバージョン追随方針を決める |
| 本格展開判断 | Preview制限を受け入れられる用途に限定して展開 |
Microsoft Entraアプリ登録と権限の確認ポイント
SharePoint in Microsoft 365 indexerは、Microsoft Entraアプリケーション登録を使ってSharePointへ接続します。認証にはアプリケーション権限または委任権限を使えますが、用途によって必要な権限と認証方式が変わります。(Microsoft Learn)
標準的なインデックス作成ではFiles.Read.AllとSites.Read.Allを確認する
ドキュメントライブラリ、リスト、ASPXページをACLなしでインデックス化する場合、Microsoft GraphのFiles.Read.AllとSites.Read.Allのアプリケーション権限が基本になります。リスト、ASPXページ、混在コンテンツのインデックス作成では、クライアントシークレットまたはフェデレーション資格情報を使えます。(Microsoft Learn)
ただし、アプリケーション権限を使うと、インデクサーはサービスコンテキストでSharePointにアクセスします。つまり、対象サイトの読み取りを広く許可する設計になりやすく、テナント管理者の同意や監査が重要です。
ACL取り込みを使う場合は権限要件が重くなる
ACL取り込みを有効にする場合、必要な権限はより強くなります。たとえば、リスト項目やASPXページのACL、SharePointサイトグループを考慮する場合は、Microsoft GraphとSharePoint APIの両方でSites.FullControl.AllまたはSites.Selectedが関係し、フェデレーション資格情報が必要になるシナリオがあります。(Microsoft Learn)
| シナリオ | 確認すべきポイント |
|---|---|
| ACLなしでリスト・ページを取り込む | Files.Read.All、Sites.Read.All |
| ドキュメントのACLを取り込む | Sites.FullControl.AllまたはSites.Selectedの要否 |
| リスト項目のACLを取り込む | User.Read.AllやSharePoint API権限の要否 |
| ASPXページのACLを取り込む | フェデレーション資格情報の要否 |
| SharePointサイトグループを尊重する | spg:プレフィックス、sharePointConnectorAppRegistration、サイトURLフィールド |
権限は「動けばよい」ではなく、「最小権限で、対象サイトを明示できるか」を基準に設計してください。Sites.Selectedを使う場合は、対象SharePointサイトごとにアプリへ明示的なアクセス許可を付与しないとインデクサーが失敗します。(Microsoft Learn)
開発者が確認すべきインデックス設計
開発者は、対象コンテンツが増えたことでインデックススキーマを見直す必要があります。特に、リストとページはドキュメントとは性質が違います。
コンテンツ種別を判別できるフィールドを用意する
リスト項目、ASPXページ、ドキュメントが同じインデックスに入る場合、検索結果側でコンテンツ種別を判別できないとUIが使いにくくなります。
最低限、次のようなフィールドを用意しておくと実装しやすくなります。
| フィールド例 | 用途 |
|---|---|
id | Azure AI Searchのキー |
content | 本文またはリスト内容 |
title | 表示タイトル |
url | SharePoint上のリンク |
contentType | document、listItem、sitePageなどの識別 |
lastModified | 更新日の表示・並び替え |
siteId | サイト単位の絞り込み |
category | 部門、業務カテゴリ、リスト列の絞り込み |
sourceType | RAGや検索UIでの出典表示 |
検索結果に「これはページなのか、リスト項目なのか、ファイルなのか」が表示されないと、ユーザーはクリック前に判断できません。RAGでも、回答の根拠として提示するときに出典種別が分かる設計にしておくと信頼性が上がります。
リスト列は全文検索だけでなく構造化フィールドとして使う
SharePoint Listsは、列情報を持つ構造化データです。すべてをcontentに詰め込むだけでは、リストの良さを活かせません。Microsoft Learnでは、SharePointリストの各列が同名のソースフィールドとして公開され、フィールドマッピングでAzure AI Search側のフィールドへ対応付けられると説明されています。(Microsoft Learn)
たとえば、問い合わせFAQリストなら、次のように設計できます。
| SharePoint列 | Azure AI Searchフィールド | 使い道 |
|---|---|---|
Title | questionTitle | 検索結果タイトル |
Answer | content | 本文検索・RAG回答生成 |
Category | category | 部門・業務別フィルター |
Status | status | 公開済みだけ表示 |
LastReviewed | lastReviewed | 古い回答の除外・警告 |
この設計にしておくと、「公開済みのFAQだけ検索」「経理カテゴリだけ検索」「レビュー日が古い回答をメンテナンス対象にする」といった運用がしやすくなります。
チャンク化する場合はACLフィールドを各チャンクへ持たせる
RAG用途では、Text Splitなどで文書やページをチャンク化する構成が一般的です。このとき、ACLフィールドを親ドキュメントにだけ持たせると、チャンク単位の検索結果に権限情報が乗らず、検索時の権限制御が期待どおり働かない可能性があります。
Microsoft Learnでは、チャンク化したシナリオでは各チャンクにACLフィールドを投影する必要があり、projectionMode: skipIndexingParentDocumentsを使う場合はインデクサーの通常のフィールドマッピングではなく、indexProjections側でACLメタデータをマッピングする必要があると説明されています。(Microsoft Learn)
RAGアプリを作る場合は、次の確認が必須です。
| 確認項目 | 見落とした場合のリスク |
|---|---|
チャンクごとにUserIdsを保持しているか | 権限フィルターが効かない |
チャンクごとにGroupIdsを保持しているか | グループ権限の検索結果が不正確になる |
| SharePointサイトグループ用のURL情報を保持しているか | spg:グループ解決ができない |
| 検証時だけACLフィールドを取得可能にしているか | 値の確認ができない |
| 本番ではACLフィールドを非表示にしているか | 権限メタデータ露出のリスク |
移行・展開時に注意すべき落とし穴
既存のSharePoint indexerを使っている環境では、「既存インデクサーにリストとページを追加すれば終わり」と考えないほうが安全です。特に以下の点でトラブルが起きやすくなります。
既存インデックスのキー設計が合わない
既存のインデックスがドキュメントライブラリ前提でmetadata_spo_site_library_item_idをキーにしている場合、リスト・ページ・混在コンテンツ用のmetadata_spo_site_asset_item_idへの対応が必要です。キー項目の変更は既存データや検索UIにも影響するため、既存インデックスを直接変更するより、新しい検証用インデックスを作って比較するほうが安全です。
サイトページの品質が検索品質に直結する
ASPXサイトページを検索対象にすると、社内ポータルのページ品質がそのまま検索品質に影響します。古い案内、重複ページ、下書きに近いページ、メンテナンスされていない部門ページが多いと、検索結果が濁ります。
展開前に、次のようなコンテンツ整理を行うと効果的です。
| 整理対象 | 対応例 |
|---|---|
| 古いニュースページ | アーカイブ扱いにして除外対象にする |
| 重複した手順ページ | 正本ページへ統合する |
| 部門独自の非公式FAQ | 公開可否を見直す |
| 下書き相当のページ | 検索対象サイトから外す |
| リンク切れページ | 更新または削除する |
検索システム側でランキングを調整するより、まずSharePoint側の情報設計を整えたほうが効果が出るケースは多くあります。
権限変更がすぐ反映されるとは限らない
ACL変更のうち、ユニーク権限を持つアイテムの変更はインデクサー実行時に増分検出されます。一方で、サイト、ライブラリ、リスト、フォルダーといった親スコープの権限変更は自動検出されず、/resyncでpermissionsを指定するなどの明示的な更新が必要です。(Microsoft Learn)
| 権限変更の種類 | 自動検出 | 推奨対応 |
|---|---|---|
| 個別ファイル・リスト項目・ページのユニーク権限変更 | あり | 次回インデクサー実行を確認 |
| コンテンツ本文の変更 | あり | 次回インデクサー実行を確認 |
| サイト・ライブラリ・リスト・フォルダーの親権限変更 | なし | /resyncまたは/resetdocsを検討 |
| 既存インデクサーへACL取り込みを後から追加 | なし | ACLのバックフィルが必要 |
権限変更直後に古いACLで検索結果が出ると、情報漏えいリスクにつながります。権限運用が頻繁なサイトを対象にする場合は、再同期手順を運用マニュアルに入れておきましょう。
条件付きアクセスやネットワーク制約にも注意する
SharePoint in Microsoft 365 indexerには、セキュリティ面の制限もあります。Microsoft Learnでは、プライベートエンドポイント非対応、Microsoft Entra ID Conditional Accessが有効なテナント非対応などの制限が記載されています。(Microsoft Learn)
ゼロトラスト方針が厳しい組織ほど、ここは事前確認が必要です。検証環境で動いた構成が、本番テナントの条件付きアクセスやネットワーク制限で失敗する可能性があります。
管理者・開発者向けチェックリスト
展開前には、次のチェックリストを使って確認すると抜け漏れを減らせます。
| 区分 | チェック項目 |
|---|---|
| 対象範囲 | 対象SharePointサイト、リスト、ページ、ライブラリを明確にした |
| OneDrive | OneDrive個人領域を直接対象にする前提で設計していない |
| API | 2026-05-01-previewを使う前提を確認した |
| Preview | 本番利用可否、SLA、破壊的変更のリスクを関係者に説明した |
| 権限 | Microsoft Entraアプリ登録と管理者同意を確認した |
| 最小権限 | Sites.Selectedを使う場合のサイト単位の許可を確認した |
| キー設計 | リスト・ページ用にmetadata_spo_site_asset_item_idをマッピングした |
| リスト列 | 必要な列を検索・フィルター・表示用フィールドへ分けた |
| ACL | ACL取り込みの要否と制限を確認した |
| チャンク化 | RAG用チャンクにもACLフィールドを持たせた |
| 再同期 | 権限変更時の/resyncや/resetdocs手順を用意した |
| 監視 | インデクサー失敗、未処理ドキュメント、権限不整合を確認する方法を決めた |
どのような組織が優先して検証すべきか
今回のPublic Previewは、すべてのSharePoint利用組織がすぐ導入すべき機能というより、SharePoint上のナレッジ活用を強化したい組織が優先して検証すべき更新です。
特に次のような組織では、検証価値が高いです。
| 組織・チーム | 検証する価値 |
|---|---|
| 社内検索をAzure AI Searchで構築している | 検索対象をページ・リストまで広げられる |
| SharePointポータルに業務ナレッジが多い | ポータル本文を検索・RAGに活用しやすい |
| FAQや台帳をSharePoint Listsで管理している | リスト列を構造化データとして使える |
| Copilot/RAGアプリを内製している | SharePoint上のテキスト情報をより広く取り込める |
| 権限を重視する大企業 | ACL同期や権限制御の実装検証ができる |
一方で、SharePointの権限が複雑すぎる、条件付きアクセスが厳しい、Preview機能を本番で使えない、OneDrive個人領域の横断検索が主目的、といった場合は、今回の機能だけで要件を満たせるか慎重に見極める必要があります。
Microsoftは、SharePointデータを使ったカスタムCopilotやRAGアプリを本番用途で構築する場合、要件によってはremote SharePoint knowledge sourceやCopilot Studioなども検討するよう説明しています。Azure AI Searchにデータを複製する構成が常に最適とは限りません。(Microsoft Learn)
次に取るべき行動
今回のSharePoint in Microsoft 365 indexerの更新は、SharePoint上の「ファイル以外の業務情報」を検索・AI活用に取り込むための大きな一歩です。特に、SharePoint ListsとASPXサイトページをAzure AI Searchに取り込めるようになったことで、社内ポータル、FAQ、台帳、手順ページを横断的に検索する構成が作りやすくなります。
ただし、Public Previewであること、OneDriveが直接のデータソースではないこと、ACLや親権限変更の同期に制限があることは必ず押さえてください。まずは小さなSharePointサイトを選び、リスト・ページ・ドキュメントを含む検証用インデックスを作成します。そのうえで、検索結果の品質、権限制御、再同期手順、APIバージョン追随の運用まで確認してから、対象サイトを広げるのが現実的です。
コメント